Studienarbeit - uni-passau.de · Creation of a WiFi Indoor Localization platform using Android Mobile phones of today { often so called smart phones { o er a functionality that goes

Technische Universität München

FachgebietVerteilte Multimodale Informationsverarbeitung

Prof. Dr. Matthias Kranz

Studienarbeit

Konzeption und Aufbau einer WiFi IndoorLokalisierungsplattform mit Android

Autor: Heimo Gerald Gursch

Betreuer: Dipl.-Ing.(Univ.) Luis RoalterBeginn: 01.04.2011Abgabe: 30.09.2011

Kurzfassung

Heutige Smartphones sind Mobiltelefone, die eine Funktionalität bieten, welche weit überdie Grenzen von reinen Kommunikationsdiensten hinausgeht. Besonders oft wird dabei dieMöglichkeit der Navigation gewünscht. Da diese Smartphones fast ausnahmslos mit GlobalPositioning System (GPS) Empfängern ausgestattet sind, gibt es für die Wegfindung unterfreiem Himmel schon viele und gute Programme. Innerhalb von Gebäuden ist der Emp-fang von GPS-Signalen praktisch kaum möglich. Deshalb liefert dieses satellitengestützesVerfahren innerhalb von Gebäuden keine, oder nur sehr schlechte, Ergebnisse. Da es aberauch in großen und unbekannten Bauwerken für ortsfremde Personen oft schwer ist, Räumeund vereinbarte Treffpunkte zu finden, soll hier Abhilfe geschaffen werden.

Damit das geplante System auf bereits verfügbaren Smartphones eingesetzt werden kann,muss für die Positionsbestimmung ein bestehender Dienst quasi zweckentfremdet werden.Dazu wird die Infrastruktur der Drahtlosen lokalen Netzwerke (Wireless Local Area Net-work, WLAN) benutzt. Da diese Infrastruktur jedoch für Kommunikation – und nicht füreine Positionsbestimmung – ausgelegt ist, muss erst eine Möglichkeit geschaffen werdenum aus den WLAN Signalen eine Position zu bestimmen.Damit handelsübliche Mobiltelefone verwendet werden können, ist eine Analyse derWLAN-Signale lediglich auf der Software-Ebene möglich. Das heißt, eine direkte elek-tronische Signalverarbeitung ist nicht möglich und es können nur jene Parameter desWLAN-Signals herangezogen werden, die durch das Smartphone ausgewertet und überSoftware zugänglich sind. Des Weiteren verändern sich die Empfangsbedingungen derWLAN-Signale gerade innerhalb von Gebäuden mit der Zeit und dem Ort sehr stark. Die-se beiden Faktoren bedingen einen Ansatz, der mit diesen Einschränkungen umgehen kannund dennoch brauchbare Ergebnisse liefert.In dieser Arbeit soll dafür mit dem sog. Verfahren des

”Fingerprintings“ gearbeitet werden.

Dabei werden zuerst an bekannten Positionen die WLAN-Signale gemessen und gemeinsammit dem Ort der Messung in einer zentralen Datenbank gespeichert. Wird nun an einemunbekannten Ort eine WLAN Messung durchgeführt, wird diese Messung mit denen in derDatenbank verglichen. Die genaue Position kann dann über unterschiedliche Methoden be-stimmt werden. Als einfachstes Verfahren kann die Position der Messung mit der größtenÜbereinstimmung als Schätzung der unbekannten Position dienen.

Im Rahmen dieser Arbeit sollen zunächst die Charakteristika der WLAN-Signale und derMessung der Signale mit Smartphones ermittelt werden. Dies soll die Grundlage liefernfür eine Beispielumsetzung eines Systems zur Positionsbestimmung. Das System soll auseiner Applikation für Smartphones, einer zentralen Datenbank und einem Server, der dieApplikation mit der Datenbank verbindet, bestehen. Die Arbeit soll zeigen, wie ein solchesSystem realisiert, und was vom fertigen System erwartet werden kann.

2

Abstract

Creation of a WiFi Indoor Localization platform using Android

Mobile phones of today – often so called smart phones – offer a functionality that goesbeyond the classical communication services. Many users desire a navigational programon their phones. For open-air usage nearly all smart phones have a Global PositioningSystem (GPS) receiver and matching navigation software is also available. If the phone isused in a building, the GPS signal received there is very weak, often useless. People whoare new to big buildings would desire a service, which works in-door as well as the GPSsystem outside. Therefore a better solution for indoor navigation is desirable.

This new system for indoor use should be useable on current smart phones. To achievethis goal a service currently used has to be adopted and used for navigational purposes.In this case we make use of the infrastructure of the widely used wireless local area net-works (WLAN). To be able to use unmodified smart phones, the WLAN signals cannotbe processed electronically. Only the information about the signal can be used, that isaccessible by software. Furthermore vary the receiving conditions for WLAN signals withtime and the receiving positions. These two facts demand a method that can work in suchconditions and is capable of delivering valid results.In this thesis the method “fingerprinting” is chosen. At this fingerprinting approach asample of the WLAN signals is taken at a known position. This sample is called the finger-print for this position. The fingerprint and its corresponding positions are then stored on acentral database. If a user wants to determine his position, the fingerprint of the unknownlocation is compared to the samples in the database. To estimate the correct position ofthe unknown fingerprint, several methods are possible. The simplest way is to choose theposition of the fingerprint which fits best to the unknown sample.

The first goal of this thesis is to determine the characteristics of the WLAN signal mea-surement with smart phones. That should be the basis for an example implementation ofa fingerprinting system. This system should consist of the application for the smart phone,the fingerprint database and the server application. The server application is responsiblefor connecting the software on the smart phone with the database. In this thesis we willshow how such a system can be implemented and what results can be expected.

3

Inhaltsverzeichnis

Inhaltsverzeichnis 5

1 Einleitung 91.1 Ortsbestimmung unter freiem Himmel . . . . . . . . . . . . . . . . . . . . 91.2 Motivation für Ortsbestimmung in Gebäuden . . . . . . . . . . . . . . . . 9

1.2.1 Mögliche Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Verfahren und Methoden . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Abgrenzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.1 Ziele dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 131.3.3 Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 13

2 Positionsbestimmung in Funknetzen 152.1 Aufbau von drahtlosen lokalen Netzwerken . . . . . . . . . . . . . . . . . . 152.2 Verfahren zur Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Lokalisierung auf Zellbasis . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Ankunftszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Modifiziertes Ankunftszeitverfahren . . . . . . . . . . . . . . . . . . 172.2.4 Umlaufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.5 Winkelbasiertes Verfahren . . . . . . . . . . . . . . . . . . . . . . . 182.2.6 Empfangsstärke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.7 Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Bestehende Fingerprinting Systeme 213.1 Cisco RF Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 awiloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Signalstärkenmessung in WLANs 254.1 WLAN Logging Application . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Nutzungsabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Zeitliche Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Abhängigkeit von unterschiedlichen Geräten . . . . . . . . . . . . . . . . . 28

5

6 INHALTSVERZEICHNIS

5 Systemimplementierung 315.1 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.1 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2 Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.3 Fehlernummer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.1.4 Abhörsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.1 Serverarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.2 WLAN-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.3 Kartendatenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.4 TUM Roomfinder API . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.5 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.6 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.7 Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.1 Programmteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.2 Programminterne Kommunikation . . . . . . . . . . . . . . . . . . . 465.3.3 Anwendungsoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Systemtest 556.1 Stockwerkerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1.1 Versuchsanordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.1.2 Versuchsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Raumerkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2.1 Versuchsanordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2.2 Versuchsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3 Positionsbestimmung innerhalb eines Raumes . . . . . . . . . . . . . . . . 596.3.1 Versuchsanordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.2 Versuchsergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.4 Veränderter Positionsbestimmungsalgorithmus . . . . . . . . . . . . . . . . 61

7 Zusammenfassung 637.1 Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

A Nachrichtenformate und Fehlernummern 67A.1 Rauminformationen in Kartennummer auflösen . . . . . . . . . . . . . . . 67A.2 Kartenbild zur Kartennummer anfordern . . . . . . . . . . . . . . . . . . . 68A.3 Koordinatentransformationsmatrix anfordern . . . . . . . . . . . . . . . . . 68A.4 Speichern einer Position am Server . . . . . . . . . . . . . . . . . . . . . . 69A.5 Anfordern einer Position vom Server . . . . . . . . . . . . . . . . . . . . . 70A.6 Fehlernummern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

INHALTSVERZEICHNIS 7

B Verwendete Geräte und Software 73B.1 WLAN Basisstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73B.2 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

B.2.1 LG P990 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73B.2.2 Google Nexus S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74B.2.3 Sony Ericsson XPERIA mini . . . . . . . . . . . . . . . . . . . . . . 74B.2.4 Point of View Tab-Tegra 10-1 . . . . . . . . . . . . . . . . . . . . . 74

B.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Abbildungsverzeichnis 77

Tabellenverzeichnis 79

Literaturverzeichnis 81

Kapitel 1

Einleitung

1.1 Ortsbestimmung unter freiem Himmel

Die Ortsbestimmung war und ist der wichtigste Grundstein für die Navigation zu Lande,zu Wasser und in der Luft. In den letzten Jahrzehnten haben sich dafür elektronische,satelliten-gestützte Systeme durchgesetzt. Diese Systeme benutzen Satelliten, welche dieErde umkreisen und permanent ein Funksignal zur Erde senden. Da die Empfänger aufder Erdoberfläche das Signal von mehr als einen Satelliten empfangen, können sie so ihrePosition berechnen. Als Vertreter ist das heute am häufigsten eingesetzte Global Positio-ning System (GPS), das noch im Aufbau befindliche europäische Galileo und das russischeGLONASS zu nennen [1].Für Anwendung auf Smartphones ist heute praktisch ausschließlich GPS relevant. GPSEmpfänger sind in der überwiegenden Anzahl der heute erhältlichen Smartphones ver-baut [2]. Dadurch wurde es zu einem Quasistandard für die Ortsbestimmung im Freien.Damit der Benutzer nicht nur lediglich seine Position mitgeteilt bekommt, die in Koordi-naten ausgedrückt für fast alle Benutzer wenig aussagekräftig ist, gibt es eine Vielzahl anProgrammen, welche die Position auf einer Karte der Umgebung darstellen. Diese Pro-gramme sind für alle gängigen Plattformen der Smartphones erhältlich [3]. Der Großteildieser Software geht über eine reine Anzeige der via GPS bestimmten Position weit hin-aus. So ist die Wegfindung zu einem frei wählbaren Ort, Aufzeichnung des zurückgelegtenWeges und Messung von der Bewegungsgeschwindigkeit ein Bestandteil der meisten die-ser Programme. Ebenfalls ist das verwendete Kartenmaterial nicht mehr eine klassischeLandkarte; es sind darin umfangreiche Zusatzinformationen für den Benutzer zu finden. Sokönnen beispielsweise Sehenswürdigkeiten, Geschäfte, Restaurants und vieles mehr darinverzeichnet sein [3].

1.2 Motivation für Ortsbestimmung in Gebäuden

Da das Angebot an Informationen zur aktuellen Position wie erläutert sehr groß ist, erwar-ten sich die Benutzer nun auch ähnliche Angebote innerhalb von Gebäuden. Dies ist jedoch

9

10 Kapitel 1 Einleitung

nicht die alleinige Motivation. Ebenso sind zahlreiche andere Anwendungen denkbar. Hiersollen nun exemplarisch einige wenige davon beschrieben werden.

1.2.1 Mögliche Anwendungen

Für genaue Ortsbestimmungen innerhalb von Gebäuden wäre beispielsweise das Verfolgenvon autonomen Transportfahrzeugen in Produktionsstätten eine mögliche Anwendung. Indem Umfeld dieser Arbeit soll jedoch eine Beschränkung auf Smartphone-basierte Sze-narien gelten. Aber auch mit dieser Einschränkung gibt es eine Vielzahl an möglichenEinsatzszenarien. Jeder der sich schon mal in einem unbekannten und großen Gebäudezu Recht finden musste, kann den Wunsch nach einer Navigationshilfe verstehen. Mit derMöglichkeit der Positionsbestimmung innerhalb von Gebäuden kann zum Beispiel ortsfrem-den Personen ein Navigationsdienst angeboten werden. Aber auch ohne der Möglichkeitder Wegfindung, und damit verbundenen vollständigen Navigation, gibt es denkbare An-wendungen. So kann dem Benutzer der Raum genannt werden, in dem er sich geradebefindet. Mit dieser Information können wiederum weitere wichtige Hinweise verknüpftsein. Diese könnten im universitären Umfeld zum Beispiel der Raumbelegungsplan oderin einem Museum kann das eine Erklärung zu den ausgestellten Gegenständen im Raumsein [4].

1.2.2 Verfahren und Methoden

Die Idee der Ortsbestimmung in Gebäuden ist natürlich nicht neu. Es wurden deshalbauch schon verschiedenste Verfahren entwickelt. An dieser Stelle sollen nun Beispiele dafürvorgestellt werden. Da in dieser Arbeit im weiteren Verlauf mit einem auf Wireless LocalArea Networks (WLAN, hier synonym für Netze nach dem Standard IEEE 802.11a, b,g oder n) basierenden Ansatz gearbeitet wird, sollen zuvor noch Beispiele für Verfahrengenannt werden, die anders arbeiten. Es gibt natürlich auch dabei wieder eine Vielzahlan Methoden auf die dies zutrifft. Hier sollen jedoch nur beispielhaft solche genannt wer-den, die sich gut eignen, um die Vor- und Nachteile der Ortsbestimmung über WLANaufzuzeigen.

Cricket

Das sogenannte Cricket Location System verwendet viele im Raum verteilte Sender. Diesesenden sowohl ein akustisches Signal, im Ultraschallbereich, als auch ein Funksignal aus.Die Sender werden an bekannten Orten, meist der Decke oder Wände, angebracht. Siestrahlen nun in periodischen Abständen sowohl ein Funk-, als auch ein Ultraschallsignalab. Der Empfänger kann aus dem Laufzeitunterschied der beiden Signalen die Abstände

1.2 Motivation für Ortsbestimmung in Gebäuden 11

zu den einzelnen Sendern errechnen. Dabei wird davon ausgegangen, dass sich Funkwel-len im Vergleich zu Schallwellen quasi unendlich schnell ausbreiten. So kann durch eineMessung der Zeit zwischen dem Eintreffen der Funk- und den Schallwellen die Entfernungzum Sender bestimmt werden. Aus den bekannten Positionen der einzelnen Sender ist dieLage des Empfängers berechenbar.Das System besitzt den Vorteil, dass das Stockwerk und der Raum mit Sicherheit bestimm-bar sind, denn die Schallwellen können keine Wände oder Decken überwinden. Nachtei-lig wirkt sich aus, dass eine spezielle Sendeinfrastruktur aufgebaut werden muss; ebensosind die Empfänger speziell angepasste Geräte. Des Weiteren können auch Gengenständeoder Personen die Ultraschallwellen abschirmen und so die Systemfunktionalität beein-trächtigen [5, 6].

UbiSense

Die Firma UbiSense vertreibt ein Ortsbestimmungssystem auf Basis von Funkwellen. Dabeiwerden Empfänger im Raum an bekannten Positionen verteilt und untereinander verbun-den. Die mobile Einheit dient als Sender. Diese bekommt über einen Funkkanal im 2,4GHzBand die Aufforderung einen Ultrabreitbandimpuls im 6-8GHz Bereich abzusetzen. Dieuntereinander vernetzten Empfänger können dann aus dem Winkel und der Zeit des Ein-treffens des Impulses die Position des mobilen Senders bestimmen.Dieses System zeichnet sich durch eine sehr hohe Genauigkeit in der Positionsbestimmungaus. Ebenso ist es auch für große Anlagen mit sehr vielen mobilen Teilnehmern geeignet.Im Vergleich zum Ansatz mit Ultraschall sind Funkwellen nicht auf direkte Verbindungenangewiesen. Es können aber in dem hier gewählten, sehr hohen Frequenzbereich, schongrößere metallische Objekte Probleme bereiten. Dieses System ist auch auf eigene Hard-ware für Sender und Empfänger angewiesen. Die nötige Verkabelung der fest installiertenStationen ist auch zusätzlich als Nachteil zu werten [6].

Nutzung bestehender Infrastruktur – WLAN Lokalisierung

Für die Nutzung zur Lokalisierung haben die bisher vorgestellten Systeme den Nachteil,dass eine feststehende Infrastruktur aufgebaut werden muss. Dies kann umgangen werden,wenn bestehende Funksysteme verwendet werden. Aus juristischen Überlegungen ist esnatürlich klar, dass nur jene genutzt werden, die auch ohne rechtliche Einschränkungenempfangen werden dürfen. Denkbar wäre also die Verwendung von beispielsweise Radio,Fernsehen, Mobilfunk und WLAN. Da diese Funknetze bereits in hoher Dichte aufgebautsind, wird keine zusätzliche Infrastruktur benötigt. Des Weiteren sind heutige Smart-phones bereits mit einem Empfänger für einige dieser Netze ausgestattet. Ebenso bietenSmartphones heute schon nennenswerte Rechenleistung [7], welche die Ausführung vonLokationsprogrammen auf ihnen erlauben. Damit kann auf die Entwicklung von eigenerHardware vollständig verzichtet werden, und die Aufgabe ist gänzlich durch Software erle-

12 Kapitel 1 Einleitung

digbar.Die größten Vorteile dieses Ansatzes sind, dass keinerlei Kosten für den Aufbau einer Infra-struktur anfallen und dass handelsübliche Smartphones als mobile Station herangezogenwerden können. Dadurch ist schnell und günstig ein Lokalisierungssystem installierbar. Je-doch sind die hierzu quasi zweckentfremdeten Netze nie für eine Lokalisierung von Gerätengedacht gewesen. Deshalb ergibt sich natürlich ein Nachteil, der besonders in der Genau-igkeit der Positionsbestimmung schlagend wird. Erst durch die Kombination von mehr alseinem Netz, also z.B. WLAN und Mobilfunknetzen ergeben sich genauere Ergebnisse [6].

1.3 Abgrenzung der Arbeit

In diesem Abschnitt soll die genaue Aufgabenstellung festgelegt werden, welche in dieserArbeit behandelt wird.

1.3.1 Ziele dieser Arbeit

Mit dieser Arbeit soll ein System zur Ortsbestimmung mittels der bestehenden WLAN In-frastruktur aufgebaut werden. Dazu wird in zwei Schritten vorgegangen. Im ersten Schrittsoll auf die Grundlagen von Fingerprinting eingegangen werden. Im Zuge dessen gilt esmögliche Probleme aufzuzeigen und Varianzen in den Bedingungen, die aufgrund der Ei-genarten der Positionsbestimmung mit WLAN entstehen, aufzudecken.Basierend auf diesen Erkenntnissen des ersten Schrittes, ist im zweiten Schritt ein Systemzur Ortsbestimmung mittels WLAN zu entwickeln. Dieses System soll im Wesentlichen auszwei Teilen bestehen. Ein Teil ist eine Anwendung, welche die Schnittstelle zum Benut-zer darstellt. Über diese soll der Benutzer die Möglichkeit haben, seine aktuelle Positionüber das System ermitteln zu lassen. Die Positionsbestimmung wird dabei anhand derdrahtlosen Netzwerke am aktuellen Aufenthaltsort des Benutzers ermittelt. Die vom Sys-tem bestimmte Position ist dann auf einer Karte des Gebäudes wieder dem Benutzer zupräsentieren. Die Berechnungen im Hintergrund zur Erfüllung dieser Anforderung, ist dieAufgabe des zweiten Teils. Dieser kann als zentraler Server gesehen werden, zu dem dieBenutzeranwendungen eine Verbindung aufbauen. Dieser Server besteht aus einem Kom-munikationsteil, der mit den Benutzeranwendungen kommuniziert, aus einem Logikteil,der die Position des Benutzers bestimmt und einem Datenbankteil, der die nötigen Infor-mationen für die Ortsbestimmung beinhaltet. Im fertigen System soll der Benutzer alsoseine Position auf einer Karte dargestellt bekommen, wobei die Position aus einer Messungder drahtlosen Netzwerke am Standpunkt des Benutzers ermittelt wird. Für den Benutzersoll ein Smartphone genügen um diese Aktionen durchführen zu können.

1.3 Abgrenzung der Arbeit 13

1.3.2 Funktionale Anforderungen

Hier sollen nun die genauen Aufgaben genannt werden, welche das System am Ende fürden Benutzer bereitzustellen hat. Die Anforderungen beziehen sich nur auf das System zurPositionsbestimmung, nicht aber auf den restlichen Teil der Arbeit.Der Benutzer soll in der Lage sein einen Namen einzugeben, der ihn im System identifi-ziert. Es muss die Möglichkeit geben, dass eine Karte des Raumes im Gebäude angefordertwerden kann. Diese Anforderung kann entweder über eine manuelle Eingabe von Gebäude,Stockwerk und Raum, oder über das Lesen eines QR-Codes erfolgen. Als QR-Codes sinddabei die bereits an den Türschildern des Lehrstuhls angebrachten Codes zu verwenden.Auf der daraufhin dem Benutzer gezeigten Karte, muss der Benutzer seine aktuelle Positi-on markieren und dem Server übermitteln können. Auf diese Weise kann eine Datenbankmit WLAN-Daten und bekannten Positionen aufgebaut werden. Sendet der Benutzer ei-ne Mitteilung mit WLAN-Daten und Position an den Server, so muss ein frei wählbarerKommentar eingegeben werden können. Ebenso ist die aktuelle Zeit, zu der die Mitteilunggemacht wurde, zu speichern. Das System muss in der Lage sein den auf der Karte mar-kierten Ort in Koordinaten auf der Erdoberfläche umzusetzen.Kennt der Benutzer seinen aktuellen Aufenthaltsort nicht, so muss dieser Ort vom Systemermittelt werden. Dazu sind die aktuellen WLAN-Daten an der Position des Benutzerszu verwenden. Anschließend soll die bestimmte Position auf einer Karte dem Benutzerangezeigt werden.

1.3.3 Nicht-Funktionale Anforderungen

Auch diese nicht-funktionalen Anforderungen beziehen sich lediglich auf das System zurOrtsbestimmung, nicht aber auf die ganze Arbeit.Die Applikation, mit der der Benutzer mit dem System interagiert, soll auf Android Smart-phones lauffähig sein; dabei soll Android-Version 2.1 und höher unterstützt werden.Für das Lesen von QR-Codes soll auf Googles ZXing zurückgegriffen werden.Die Smartphone-Applikation hat mit dem Server des Systems über das Hypertext TransferProtocol (HTTP) zu kommunizieren. Der Server soll anhand eines Java Servlets auf einemApache Tomcat Server der Version 6 implementiert werden.Für die benötigte Datenbank des Systems ist eine MySQL-Datanbank zu verwenden.Die Karten für die Darstellung der Position des Benutzers sollen über die TUM RoomfinderAPI bezogen werden.Das fertige System ist auf den Servern des

”Fachgebiet Verteilte Multimodale Informati-

onsverarbeitung“ zu installieren und in Betrieb zu nehmen.

Kapitel 2

Positionsbestimmung in Funknetzen

In diesem Kapitel sollen die nötigen Verfahren und Praktiken vorgestellt werden, welche zurPositionsbestimmung in Funknetzen dienen können. Diese Methoden sollen zuerst auf ihrejeweilige Funktionsweise und der damit verbundenen Voraussetzung untersucht werden.Anhand dieser Analyse wird klar, welche Verfahren zum Einsatz bei der Ortsbestimmungmit Hilfe von WLAN geeignet sind und welche nicht. Davor soll kurz die Funktionsweiseaktueller drahtloser Netze erläutert werden. Diese dient als Grundlage für die Beurteilungder einzelnen Verfahren zur Ortsbestimmung.

2.1 Aufbau von drahtlosen lokalen Netzwerken

Drahtlose lokale Netze folgen alle einem Aufbauprinzip. Das Kernnetz, welches zum Bei-spiel an Servern, anderen Rechnern oder auch dem Internet angeschlossen ist, ist in al-ler Regel ein drahtgebundenes Netz. Dieses Netz stellt dann Zugangspunkte, sogenannteAccess-Points zur Verfügung. Access-Points werden auch als Basisstationen bezeichnet. Eshandelt sich dabei um spezielle Geräte, welche eine Umsetzung der Kommunikation vondrahtgebunden auf drahtlos vornehmen. Diese Access-Points bieten nun anderen Teilneh-mern in ihrer Umgebung die Möglichkeit, auf das Kernnetz zuzugreifen. Die Reichweitesolcher Access-Points ist allerdings beschränkt. Um damit große Gebäude flächendeckendversorgen zu können, werden nun mehr als eine Basisstation benötigt. Das Gebiet, welchesvon einer Basisstation versorgt wird, bezeichnet man auch als Basic Service Set (BSS). Umdiese Gebiete eindeutig zu identifizieren, gibt es die BSSID. Für die Unterscheidung ganzerWLANs wird der Service Set Identifier (SSID) verwendet, welcher quasi als WLAN-Namezu verstehen ist. Ein WLAN hat also einen SSID und für jeden Access-Point in diesemWLAN eine BSSID. Aus den einzelnen BSSs ergibt sich eine Art zellulares Netz, das sichüber ein Gebäude erstreckt. Damit sich an den Grenzen der Zellen, die jeweils von einemanderen Access-Point versorgt werden, keine Störungen ergeben, operieren diese in anderenFrequenzbereichen, sogenannten Kanälen. Durch Nutzung unterschiedlicher Frequenzen istes auch möglich mehr als einen Access-Point auf der gleichen Position zu haben. MancheBasisstationen können auch mehrere WLANs gleichzeitig anbieten. Dadurch kann eine

15

16 Kapitel 2 Positionsbestimmung in Funknetzen

Trennung verschiedener Netze erreicht werden. Dies wird oft verwendet um eine Isolierungzwischen Benutzer vornehmen zu können, beispielsweise auf Grund von sicherheitstechni-schen Überlegungen [8].

Alle Geräte, die von einem Access-Point bedient werden, teilen sich die Luftschnittstelle alsgemeinsames Medium. Damit dennoch eine gezielte Kommunikation möglich ist, muss eineAdressierung vorliegen. Jedes Endgerät und auch jeder Access-Point verfügt deshalb übereine weltweit eindeutige Adresse, die sogenannte Medium Access Control Adresse, kurzMAC-Adresse. Sie wird benötigt, um eine Kommunikation mit eindeutiger Quelle und Zielaufzubauen. Ebenso wird die MAC-Adresse der entsprechenden Basisstation, meist auchals BSSID des jeweiligen BSS, gewählt [8].

2.2 Verfahren zur Positionsbestimmung

In diesem Abschnitt werden nun verschiedenste Verfahren zur Ortsbestimmung vorgestellt.Nicht alle dieser Ansätze eignen sich für eine Anwendung bei Positionsbestimmung imWLAN, sollen aber hier dennoch für die technischen Möglichkeiten als Beispiel dienen.

2.2.1 Lokalisierung auf Zellbasis

Diese Methode, im Englischen als”Cell of Origin“ bezeichnet, kurz COO, kann als das

einfachste dieser Verfahren angesehen werden. Dabei wird lediglich die Zelle bestimmt,in welcher das Endgerät gerade kommuniziert. Diese Zelle ist durch den Access-Point,welcher die mobilen Geräte darin bedient, bestimmt. Die Ermittlung der Zelle durch dasEndgerät ist sehr einfach, da nur der Access-Point erkannt werden muss. Dieser ist sehrleicht anhand seiner MAC-Adresse erkennbar. Die Adresse muss dem Client bekannt sein,damit er mit der Basisstation kommunizieren kann. Über eine zentrale Datenbank, in dieMAC-Adressen der Access-Points mit ihrem dazugehörigen Standort verzeichnet sind, lässtsich nun die Position des Clients bestimmen [9].

Hier erkennt man sehr schnell, dass die Genauigkeit der Positionsbestimmung mit der Zell-größe einhergeht. Da die Funkzellen jedoch auch in Gebäuden bei günstigen Verhältnissenbis zu 25m Ausdehnung haben können, ist das Verfahren nur sehr ungenau [10]. Aufgrundder Einfachheit in der Umsetzung ist es jedoch nicht ganz von der Hand zu weisen. Füreine bessere Genauigkeit gäbe es die Möglichkeit, dieses Lokalisierungsverfahren in Kombi-nation mit anderen Verfahren einzusetzen. Hier könnte mit COO bereits eine Eingrenzungdes möglichen Gebietes für andere genauere Verfahren gefunden werden, die dann lediglicheinen kleineren Suchbereich abdecken müssten.

2.2 Verfahren zur Positionsbestimmung 17

2.2.2 Ankunftszeit

Im Englischen als”Time of Arrival“, kurz TOA, wird ein Verfahren bezeichnet, bei dem

die Ankunftszeit eines Signales am Gerät ausschlaggebend ist. Das Signal wird von festenBasisstation zur mobilen Einheit gesendet. Bei diesem Verfahren werden genaue, und inallen Stationen synchrone Zeitgeber benötigt. So kann dann die Ausbreitungszeit einesSignals bestimmt werden. Die Sendezeit kann auf das Signal moduliert sein, oder sie istdem Empfänger a priori bekannt. Dann ist aus Ankunftszeit, die der Empfänger selbstmisst, und der Sendezeit, die Dauer bestimmbar, die das Signal zur Ausbreitung gebrauchthat. Unter einer Annahme für die Ausbreitungsgeschwindigkeit ist die zurückgelegteStrecke des Signals berechenbar. Wenn die Entfernung zu mehreren bekannten Punktenermittelt wurde, ist daraus die absolute Position durch das Verfahren der Triangulationberechenbar [9]. Für eine hohe Genauigkeit dieses Verfahrens sind präzise Zeitmessungennötig. Um einen Fehler von weniger als 1m zu erzielen, dürfen die einzelnen Zeitgeber nurum 1ns abweichen [11].

Die strikten Anforderungen an die Zeitmessung und Synchronisierung der einzelnen Zeit-geber, in den mobilen und den fixen Stationen, macht dieses Verfahren für den Einsatz aufSmartphones unbrauchbar.

2.2.3 Modifiziertes Ankunftszeitverfahren

Damit die Zeitbasis nicht auf den mobilen Einheiten und den Basisstationen synchrongehalten werden muss, gibt es das im englischen als

”Time Difference of Arrival“, kurz

TDOA, bezeichnete Verfahren. Dabei wird ein Signal von der mobilen Station ausgesandt.Die Basisstationen müssen nun untereinander verbunden sein und die Unterschiede in derAnkunftszeit ermitteln. Die absoluten Zeiten sind hier nicht von Belangen, da die Unter-schiede in den Übertragungszeiten proportional zu den Entfernungen sind [9, 11].

Auch wenn bei diesem Verfahren nun noch die Basisstationen untereinander zeitsynchronarbeiten müssen und die mobile Station nicht mehr, so bleiben die Anforderungen an dieMessung der Zeit gleich wie bei dem nicht modifizierten Ankunftszeitverfahren, dem TOA.Damit scheidet es auch für den Einsatz bei Smartphones und WLAN-Infrastruktur aus.

2.2.4 Umlaufzeit

Damit die Anforderung der Synchronisierung der einzelnen Uhren entfallen kann, wurdedas Verfahren der Umlaufzeitmessung eingeführt, was im Englischen als

”Round Trip Time

of Flight“, kurz RTOF, bezeichnet wird. Dabei geht vom mobilen Gerät ein Signal aus.Dieses wird dann am festen Empfänger wieder zurückgesandt. So muss nun nur noch diemobile Einheit die Zeit messen, bis das Signal wieder bei ihm angekommen ist. Aber auch


diese Messung muss, wie bei der Messung der Ankunftszeit, sehr genau erfolgen, denn eswird wieder über die Ausbreitungsgeschwindigkeit der Abstand ermittelt und dann mittelsTriangulation die tatsächliche Position. Ebenfalls geht die unbekannte Zeit als Fehler ein,die der Empfänger benötigt, um das Signal wieder zurückzusenden [11].

Auch dieses Verfahren ist aufgrund der strengen Anforderung an die Zeitmessung nicht mitSmartphones umzusetzen.

2.2.5 Winkelbasiertes Verfahren

Bei diesem Verfahren, im Englischen wird es als”Angel of Arrival“, kurz AOA, bezeichnet,

ist der Winkel die ausschlaggebende Größe für die Positionsbestimmung. Durch mehre-re gerichtete Antennen an den Basisstationen können diese den Winkel bestimmen, auswelchen das Signal von der mobilen Station eingetroffen ist. Das Verfahren ist in sei-ner Genauigkeit durch die Anzahl der verwendeten Antennen und der zur Bestimmungverwendeten Anzahl von Basisstationen abhängig [9, 11].

Da bei der WLAN-Infrastruktur meist keine, oder nur sehr grob gerichtete Antennen ein-gesetzt werden, ist dieses Verfahren dort nicht anwendbar.

2.2.6 Empfangsstärke

Bei der Messung der Empfangsstärke, im Englischen”Received Signal Strength“, kurz RSS,

wird von der Tatsache Gebrauch gemacht, dass die Signalstärke mit zunehmender Entfer-nung abnimmt. Ist die Sendeleistung bekannt, so kann über die gemessene Empfangsleis-tung der Abstand berechnet werden. Aus den Abständen zu verschiedenen, feststehendenSendern kann die mobile Station dann wieder ihre Position bestimmen [9, 11, 12].

Dieses Verfahren ist grundsätzlich für die Verwendung mit Smartphones und WLAN-Infrastruktur geeignet. Zu bedenken ist dabei aber, dass Smartphones nicht primär fürdie Messung der Empfangsstärke von WLAN-Signalen gebaut sind und dies deshalb nurmit bedingter Genauigkeit möglich ist. Ebenso müssen nicht alle Access-Points mit dervollen Leistung senden. Ist die Sendeleistung aber unbekannt, dann ist kein vernünftigerRückschluss auf die Entfernung mehr möglich. Von Bahl et al. [12] wird gezeigt, dass so einSystem funktionieren kann, aber mit einigen Einschränkungen der Genauigkeit zu kämpfenhat. Im übernächsten Kapitel werden auch noch Messungen vorgestellt, die die Proble-matik der unterschiedlichen Empfangsstärken zwischen verschieden Smartphone-Modellenund Abhängigkeiten der Signalstärke mit der Zeit aufzeigen.

2.3 Zusammenfassung 19

2.2.7 Fingerprinting

Mit Fingerprinting wird ein Verfahren bezeichnet, welches die Schwächen der Entfernungs-bestimmung über die Signalstärke überwinden soll. Dabei wird die Arbeit in zwei Teil-schritte unterteilt. Im ersten Schritt wird eine Datenbank aufgebaut. Dazu werden anbekannten Positionen die verfügbaren WLANs mit ihren Daten ermittelt und gemeinsammit der Ortsinformation in der Datenbank gespeichert. Diese Phase sollte sinnvollerweisevor dem eigentlichen Betrieb des Systems durchgeführt werden. Diese Datenbasis entschei-det später über die Leistungsfähigkeit des Systems. In der zweiten Phase, dem eigentlichenBetrieb, werden die Messungen der WLAN Signale an einem unbekannten Ort mit der Da-tenbank verglichen. Wie nun die gesuchte Position genau ermittelt wird, ist unterschiedlich.Es kann als einfachste Lösung die Position mit der besten Übereinstimmung gewählt wer-den. Komplexere Ansätze, wie Interpolation und ähnliches ist auch möglich. Im Deutschenwird Fingerprinting oft mit Signalstärkenmustererkennung bzw. mit Positionsbestimmungdurch Signalstärkenmustervergleich übersetzt [9, 11–13].

Es ist noch festzuhalten, dass dieses Verfahren keineswegs lediglich mit WLAN Anwendungfindet. Auch in Verbindung mit Global System for Mobile Communications Netzen (GSM-Netzen) ist diese Vorgehensweise anwendbar [14].

2.3 Zusammenfassung

Auch wenn es eine große Anzahl prinzipieller Möglichkeit zur Positionsbestimmung mitFunksignalen gibt, so scheiden die meisten Aufgrund der Anforderungen an spezielleHardware aus, wenn nur die bestehende Infrastruktur und handelsübliche Smartphonesverwendet werden sollen. Die mit diesen Einschränkungen noch möglichen Ansätze aufZellbasis, der Empfangsstärke und Fingerprinting sollten aber dennoch ausreichen um einsolches System in Betrieb nehmen zu können. Als Vorteil gegenüber anderen Verfahrenergibt sich das mögliche Einsparungspotenzial, da bereits vorhandene Infrastruktur undAusstattung verwendet werden kann. Dem gegenüber steht der Nachteil, dass wederWLAN noch Smartphones für Positionsbestimmung geplant oder konstruiert worden sind.Um mit diesen Nachteilen dennoch vernünftige Ergebnisse zu erreichen, muss bei derEntwicklung des Systems besonders auf Methoden geachtet werden, welche die Nachteilekompensieren können.Als vielversprechendster Ansatz gilt dabei Fingerprinting. Dies hängt auch damitzusammen, dass hier die beiden anderen Verfahren, also Zelllokalisierung und Si-gnalstärkenlokalisation, auch integrierbar sind. Die Zelllokalisierung ist dabei immerinhärent enthalten. Eine Zelle ist jedoch nun nicht mehr eine Funkzelle, sondern einGebiet, in dem eine Referenzmessung gültig ist. Damit sind die Zellgrößen abhängigvon der Anzahl der Messungen skalierbar und die Genauigkeit des Verfahrens in einembestimmten Bereich steuerbar. Die Lokalisierung auf Signalstärkenbasis kann dazu


herangezogen werden, um zwischen zwei Referenzmessung eine Position zu interpolierenund so eine bessere Genauigkeit zu erhalten [4].

Kapitel 3

Bestehende Fingerprinting Systeme

Das große Potenzial des Fingerprintings führte auch dazu, dass bereits mehrere solcherSysteme implementiert wurden. Dieses Kapitel soll zwei bestehende Fingerprinting Sys-teme vorstellen. Dabei werden die Eigenschaften dieser Systeme herausgestrichen, welchesie besonders auszeichnen.

3.1 Cisco RF Fingerprinting

Die Firma Cisco bietet ein komplettes System zur Positionsbestimmung an. Die Informa-tionen über dieses System sind in [9] dargeboten. Der große Vorteil dieses Systems bestehtdarin, dass alle Funktionalitäten in den Geräten der Netzarchitektur enthalten sind. Dieeinzelnen mobilen Geräte im Netz benötigen keinerlei Änderungen an Hard- oder Software.Damit ergibt sich allerdings auch die Möglichkeit, Benutzer und ihre Geräte ohne derenWissen zu verfolgen. Vorteilhaft daran ist jedoch, dass nun sämtliche Geräte, die über ei-ne WLAN-Anbindung verfügen, lokalisiert werden können. Sogenannte WLAN-Tags, alsokleine WLAN taugliche Sensoren, stehen hier besonders im Mittelpunkt. Diese Sensorenkönnen auf bewegten Objekten angebracht werden und übermitteln dann Sensordaten perWLAN. Ebenso kann nun über die Positionsbestimmung der Weg der Objekte nachvollzo-gen werden. Cisco bietet mit dem Produkt auch die Möglichkeit, spezielle Informationendieser WLAN-Tags direkt über das Fingerprinting System auszulesen. Als Beispiel wäreder Batteriestand zu nennen. Dies funktioniert dann aber nur über eigene Nachrichten,welche das WLAN-Tag unterstützen muss. Ein Nachteil ist natürlich, dass die Funktiona-lität in den Komponenten der Netzarchitektur implementiert ist. Deshalb müssen eigenenAccess-Points und Netzwerkserver eingesetzt werden.Um die Positionsinformationen messen zu können, werden die Access-Points herangezo-gen. Diese werden über das Lightweight Access Point Protocol (LWAPP) kontrolliert. Umeine Positionsbestimmung durchzuführen, muss das Signal eines mobilen Teilnehmers vonmindestens drei Basisstationen empfangen werden. Die Access-Points leiten die nötigenInformationen (MAC-Adresse des Senders, MAC-Adresse des Access-Points, Empfangs-schnittstelle und Signalstärke) an den Wireless LAN Controller (WLC) weiter. WLCs die-

21

22 Kapitel 3 Bestehende Fingerprinting Systeme

nen eigentlich zur Koordination der Access-Points, übernehmen hier aber auch eine Rollebei der Ortsbestimmung. Die WLCs akquirieren Daten von den durch sie bedienten Basis-stationen. Darüber in der Hierarchie folgt der wichtigste Teil des Systems, das sogenannteWLAN Location Appliance. Darin werden alle Daten gesammelt und die Positionen dereinzelnen Geräte berechnet. Das WLAN Location Appliance kann die Information über dieermittelten Aufenthaltsorte über verschiedene Schnittstellen (Emails, Syslog, SOAP/XMLund SNMP TRAP) an andere Dienste weitergeben.Das WLAN Location Appliance arbeitet zur Positionsbestimmung grundsätzlich nach demFingerprinting Verfahren. Es muss also zuerst eine Lernphase absolviert werden, bevor dasSystem vollständig einsetzbar ist. Für eine bessere Genauigkeit bei der Ortsbestimmungwird ein Verfahren angewandt, welches weit über reines Fingerprinting hinausgeht. Ausden Daten der Lernphase wird ein Modell der Signalstärke berechnet. Dieses Modell gibtfür jeden WLAN-Kanal und über das ganze abgedeckte Gebiet eine Verteilung der Emp-fangsstärke wieder. Die Berechnung des Modells ist der eigentliche Aufwand des Systemsund die einzelnen Algorithmen zur Modellrechnung sind auch nicht offengelegt. Die Po-sitionsbestimmung wird anhand einer Mustererkennung durchgeführt. Die gemessenenWLAN-Daten werden mit dem Modell verglichen und danach die Position mit der gerings-ten Abweichung als gesuchter Aufenthaltsort ermittelt. Ein WLAN Location Appliancekann auf diese Weise bis zu 2500 Geräte lokalisieren, wobei auch mehrere WLAN Loca-tion Appliances kombiniert werden können, um noch mehr mobile Stationen verfolgen zukönnen.

Die Genauigkeit der Ortsbestimmung wird von Cisco selbst mit ¡10m in neunzig Prozent derAnfragen angeben [9]. Moen et al. [15] untersuchten die Genauigkeit und Leistungsfähigkeitdes Cisco RF Fingerprinting Systems. Dabei wird aber eine Positionsbestimmung in denStraßen von Trondheim durchgeführt. Das Fingerprinting System war jedoch zum Zeit-punkt der Untersuchung nicht für den Betrieb unter freiem Himmel ausgelegt. DiesesAnwendungsfeld wurde von Cisco erst nach dieser Untersuchung mit neuen Versionen an-geboten. Deshalb ergeben sich auch nur mäßige Genauigkeiten bei der Trefferquote der Po-sition. So wurde für unbewegte mobile Stationen ein maximaler Fehler von bis zu 90m, beibewegten bis zu 200m ermittelt. Bei bewegten Stationen ergibt sich aber das Phänomen,dass sich der Fehler mit der Zeit, und somit der fortschreitenden Bewegung, reduziert.So konnten dann einzelne Positionen auf bis zu 9m genau bestimmt werden, wobei derdurchschnittliche Fehler immer noch 50m betrug.

3.2 awiloc 23

3.2 awiloc

Von der Frauhenhofer-Gesellschaft wurde das sogenannte awiloc System entwickelt [13].Dabei handelt es sich ebenfalls um ein System, welches mit dem Fingerprinting Verfahrenarbeitet, wenn auch die Systemarchitektur anders ist. Bei awiloc wird keine angepassteInfrastruktur benötigt, sondern es können bestehende WLAN-, GSM- und UMTS-Netzeverwendet werden. Ebenso sind für den Betrieb keine eigenen Server notwendig, sondernes werden alle Berechnungen direkt am Smartphone durchgeführt. Als großer Vorteil desSystems ist zu werten, dass weder ein Server benötigt wird, noch Änderungen an derInfrastruktur nötig sind. So wird die Einführung des Systems einfach und kostengünstig.Als Genauigkeit des Systems werden durchschnittlich 1 - 5m innerhalb, und 10m außerhalbvon Gebäuden angegeben.Wie bei jedem Fingerprinting System müssen auch hier zuerst Testdaten gesammeltwerden. Aus diesen Daten wird dann eine Karte erstellt, welche die zu erwartendenEmpfangsstärken im Gebäude wiedergibt. Diese Karte wird mit der Positionsbestim-mungssoftware auf die einzelnen Geräte verteilt. Jedes Smartphone kann dann vollkommenautark seine Position bestimmen. Dieser Ansatz hat den Vorteil, dass die sensiblen Positi-onsdaten nie das Gerät des Benutzers verlassen, und ist somit aus datenschutztechnischenGründen sehr vorteilhaft. Nachteilig wirkt sich natürlich aus, dass bei Änderungen in denWLAN-Referenzdaten alle Smartphones auf den neuesten Stand gebracht werden müssen.Da dies schwer zu exekutieren sein kann, ist dies ein eindeutiger Nachteil dieses Ansatzes.Es ist eine wichtige Eigenschaft, dass awiloc lediglich die Aufgabe der Positionsbestim-mung erledigt. Was mit der Ortsinformation dann weiter geschieht, ist eine andere Frage.Deshalb wird awiloc mit anderen Programmen zusammen verwendet. Dabei ist beispiels-weise art2guide [16] zu nennen. Art2guide bietet dem Benutzer einen Museumsführer,der durch die Positionsinformation relevante Hinweise bezüglich der ausgestellten Objekteliefert. Ein anderes System ist MobileWALK. Es richtet sich besonders an Fußgänger imstädtischen Bereich, sowohl innerhalb als auch außerhalb von Gebäuden [17].

Kapitel 4

Signalstärkenmessung in WLANs

Dieser Abschnitt soll die tatsächlichen Bedingungen in aktiven WLANs aufzeigen. Umdas durchführen zu können, wurde ein Programm entwickelt, welches die aktuellen Si-gnalstärken aufnimmt und speichert. In diesem Kapitel soll zuerst dieses Programm vor-gestellt und danach die damit ermittelten Ergebnisse besprochen werden.

4.1 WLAN Logging Application

Um die tatsächlichen Bedingungen in WLANs aufzeichnen zu können, wurde ein eigenesAndroid Programm erstellt. Dieses Programm ist als WLAN Logging Application (Wlog)bezeichnet. Diese Applikation ist sehr einfach; der Benutzer kann die Aufzeichnung star-ten und Wlog führt dann selbständig in einem einstellbaren Intervall eine Messung allerverfügbaren WLANs durch, bis der Benutzer die Aufzeichnung wieder stoppt. Alle ermit-telten Messdaten werden in einer Datei gespeichert, so dass diese später ausgewertet wer-den können. WLog zeichnet nur Daten auf, welche über Androidschnittstellen verfügbarsind. Dazu wird über das Android Application Programming Interface (API), also dieProgrammierschnittstelle, auf diese Daten zugegriffen, wie durch die Android Program-mierschnittstelle [18] beschrieben. Für jedes Netzwerk sind folgende Daten verfügbar:

• SSID: Die SSID des WLANs.

• BSSID: Die BSSID des Access-Points, bzw. des BSS.

• Frequency: Der von diesem Netzwerk benutze Kanal, in MHz angegeben.

• Level: Die Empfangsstärke im Bereich von -1 bis -99dBm.

• Capabilities: Beschreibt die Verschlüsselungsmethode, die genutzt wird.

Im Anschluss werden nun einige der ermittelten Daten vorgestellt. Die Auswertung be-schränkt sich auf eine Diskussion der Empfangsstärke. Ziel ist es zu zeigen, von welchenEinflüssen die Empfangsstärke beeinflusst wird und wodurch sich damit Probleme für Lo-kalisierung mit dem Fingerprinting-Verfahren ergeben.

25

26 Kapitel 4 Signalstärkenmessung in WLANs

Die bei den Messungen verwendeten Geräte sind im Anhang B mir ihren Seriennummernaufgelistet.

4.2 Nutzungsabhängigkeit

Mit dieser Messung soll die Abhängigkeit der Signalstärke von der Kommunikationsakti-vität im entsprechenden WLAN gezeigt werden. Bei der Durchführung wurde die Basis-station (siehe Tabelle B.1 auf Seite 73) gemeinsam mit dem Smartphone (siehe Tabelle B.3auf Seite 74) verwendet. Sowohl Access-Point als auch Smartphone wurden während derMessung nicht bewegt und hatten somit immer einen konstanten Abstand zueinander. Dashier gemessene Netzwerk ist auf Kanal 13 betrieben worden. Die Tabelle 4.1 zeigt die Bele-gung der Nachbarkanäle. Die Signalstärkenmessung ist in Abbildung 4.1 dargestellt. Vom

Kanal 1 2 3 4 5 6 7 8 9 10 11 12 13Anzahl nur

der 3-5 0-2 0-1 0-3 0-2 2-3 1 0-1 0-2 1-2 0-1 1-4 gemessenesBasisstation Netzwerk

Tabelle 4.1: Anzahl der aktiven Basisstationen während der Messung

Beginn der Messung an, bis ca. 45 Minuten nach dem Beginn, teilte sich das Smartphonemit anderen Teilnehmern das Netzwerk. Von da, an bis ca. 2 Stunden und 10 Minutennach Beginn, war das Smartphone der alleinige Nutzer des WLANs. Danach waren wiederandere Nutzer auch im Netzwerk. Deutlich zu erkennen ist, dass die Schwankung der Si-

Abbildung 4.1: Verlauf der Signalstärke bei unterschiedlicher Anzahl an Geräten imWLAN. Im Abschnitt mit geringen Schwankungen (45 Minuten bis 2 Stun-den 10 Minuten) war das Smartphone der einzige Teilnehmer im WLAN.

gnalstärke von der Anzahl der Nutzer im Netzwerk abhängt. Optisch sind die Bereiche klarunterscheidbar. Es gibt aber auch große Schwankungen, wenn das Smartphone alleine im

4.3 Zeitliche Abhängigkeiten 27

WLAN ist, wobei diese jedoch um einiges seltener sind. Weitere Einflüsse wie die Personenim Raum, Verdeckungen durch Gegenstände, usw. werden hier nicht behandelt. Einigesdavon wurde von Kaemarungsi et al. [19] beschrieben. Für die Positionsbestimmung stehenaber keine eigenen WLANs zur Verfügung, sondern diese werden unterschiedlich stark fürnormale Kommunikationszwecke genutzt. Deshalb muss das System mit den dargestelltenSchwankungen umgehen können.

4.3 Zeitliche Abhängigkeiten

In Abbildung 4.2 ist eine Messung im Hörsaal Z999 am Stammgelände der TU Münchengezeigt. Für die Messung wurde das Smartphone (siehe Tabelle B.3 auf Seite 74) benutzt.Die Messung wurde während einer Lehrveranstaltung durchgeführt. Das Smartphone wur-de im Verlauf der Aufnahme nicht bewegt. Bei dieser Messung wurden zwei Basisstationenerkannt, die jeweils vier WLANs bedienen. Die Darstellung zeigt anschaulich, dass dieSignale eines Access-Points besser zu empfangen sind als die des anderen.

Abbildung 4.2: Gezeigt ist der Verlauf der Empfangspegel von zwei Access-Points, die je-weils vier WLANs bereitstellen. Zu erkennen sind Pegelschwankungen mitbis zu ±10dBm.

Des Weiteren ist eine klare Abhängigkeit des Pegels über der Zeit festzustellen. Die Schwan-kungen des Empfangspegels um ±10dBm ist erkennbar. Die Schwankung über der Zeitist unerwünscht, da diese die Abhängigkeit der Signalstärke vom Aufenthaltsort verfälscht.Diese starken Schwankungen des Pegels müssen bei der Auslegung eines Ortsbestimmungs-systems durch eventuelle Korrekturen berücksichtigt werden.

28 Kapitel 4 Signalstärkenmessung in WLANs

4.4 Abhängigkeit von unterschiedlichen Geräten

Bei dieser Messung wurden die Smartphones von LG (siehe Tabelle B.2 Seite 73) und Sony(siehe Tabelle B.4 auf Seite 74) verwendet. Sie wurden direkt nebeneinander positioniertund sollten über eine Stunde eine Messung der vorhandenen WLANs durchführen. In dieserZeit wurde keines der beiden Geräte bewegt. In die Auswertung wurden alle Netzwerkeaufgenommen, welche zumindest einmal von einem der beiden Geräte ermittelt wurden.Die Messung fand im Hörsaal 0999 am Stammgelände der TU München statt. Für das

Abbildung 4.3: Balkendiagramm der Empfangspegel von 26 verschieden WLANs zu jeweilsvier verschiedenen Zeitpunkten.

Diagramm wurden die vier Zeitpunkte 0, 20, 40 und 60 Minuten ausgewählt. Um eineReihung zu ermöglichen, sind die einzelnen WLANs alphabetisch nach der MAC-Adressedes Access-Points sortiert. Ist ein drahtloses Netzwerk nicht erkannt worden, so wurde derStrafwert -120dBm für den Pegel vergeben. In Abbildung 4.3 erkennt man nun ein Muster,welches sich mit gewisser Ähnlichkeit bei dem Diagramm beider Smartphones zu erkennengibt. Die gemessenen Pegel für ein WLAN und einen Zeitpunkt können von Gerät zuGerät unterschiedlich sein. Es ist hier sogar mehrmals der Extremfall sichtbar, bei welchenein Netzwerk nur von einem Gerät erkannt wird und vom zweiten Gerät nicht. Die imvorherigen Kapitel besprochene Abhängigkeit von der Zeit ist auch hier wieder erkennbar.Die vier Balken, welche unmittelbar nebeneinander stehen und den Empfangspegel einesNetzwerkes zu den vier unterschiedlichen Zeiten darstellen, zeigen die Unterschiede in derZeit. Ebenso tritt hier auch der Extremfall auf, dass ein WLAN zu einem Zeitpunktgemessen werden konnte und zu einem anderen Zeitpunkt nicht.

Auch diese Untersuchung zeigt, dass bei dem Vergleich der Messungen mehr auf eine ArtMustererkennung gesetzt werden muss. Die einzelnen Pegel sind nur von geringer Aussage-

4.4 Abhängigkeit von unterschiedlichen Geräten 29

kraft. Die teilweise großen Unterschiede in den Empfangsstärken zwischen den verwendetenGeräten wird auch von Kaemarungsi [20] beschrieben. Um dennoch mit einer möglichstgroßen Anzahl von verschiedenen Geräten im System gute Ergebnisse zu erzielen, wird vonVaupel et al. [21] eine Kalibrierung der einzelnen Teilnehmer vorgeschlagen.

Kapitel 5

Systemimplementierung

In diesem Abschnitt wird die Umsetzung des Ortsbestimmungssystems beschrieben. DasKapitel wird in drei Teile unterteilt. Dabei wird im ersten Teil auf das Kommunikations-protokoll eingegangen, siehe Abschnitt 5.1 ab Seite 32. Im Anschluss daran wird der Serverbeschrieben, siehe 5.2 ab Seite 35. Dessen Aufgabe ist die Positionsbestimmung, währendder Client nur eine Benutzerschnittstelle darstellt. Diese Aufteilung hat mehrere Vorteile.Die gesamte Rechenaufgabe der Positionsbestimmung ist auf dem Server verlagert, wasdie Smartphones entlastet und deren beschränkte Akkuleistung schont. Der Server ist dieeinzige Instanz, die direkten Zugriff auf die Datenbank hat, von der es auch nur eine gibt.Damit ist die Datenbasis leichter zu pflegen und Änderungen daran sind für alle Benutzergleichzeitig abrufbar. Als Nachteil ist zu vermerken, dass der zentrale Server einen konzen-trierten Ausfallspunkt bildet. Ist der Server bzw. die Datenbank nicht erreichbar, so istdas gesamte System nicht funktionsfähig. Deshalb muss der Server in der Lage sein, einegroße Zahl von Clients zu bedienen. Der Client selbst wird im dritten und letzten Teil desKapitels beschrieben siehe 5.3 ab der Seite 44. Die Abbildung 5.1 zeigt eine schematischeDarstellung des Gesamtsystems. Der Funktionsumfang des Servers wird durch mehrereTeilsysteme verwirklicht. Der Teil, welcher die Anfragen der Clients entgegennimmt unddie Anfragen beantwortet, ist als Java Servlet realisiert. In dem Kapitel 5.2 wird ebenso aufdie eigens erstelle Datenbank zur Speicherung der WLAN-Daten eingegangen. Der TUMRoomfinder wird verwendet, um die Karten der Gebäude zu beziehen; es wird lediglich dieKommunikation mit diesem kurz beschrieben.

31

32 Kapitel 5 Systemimplementierung

Smartphone

MySQL Datenbank

Server

TUM Roomfinder

LRZ Netzwerk

Abbildung 5.1: Übersicht des Gesamtsystems zur Positionsbestimmung. Die KomponentenSmartphone (Client), Server, Datenquellen (TUM Roomfinder und MySQLDatenbank) und die Datenflüsse zwischen diesen sind zu sehen.

5.1 Kommunikationsprotokoll

Das entwickelte Protokoll ist recht einfach. Jede Kommunikation wird vom Client ausangestoßen. Dieser sendet eine Anfrage an den Server. Der Server schickt darauf eineAntwort. Die Antwort kann entweder die vom Client gewünschten Daten enthalten, odersie ist eine Fehlermeldung. Fehlererkennung und ggf. eine Korrektur für die übertragenenNachrichten wird den Protokollen in den Kommunikationsschichten darunter überlassenbzw. wird von diesen erwartet. Client und Server kommunizieren über das Hyper TextTransfer Protocoll (HTTP). Im HTTP gibt es mehrere Nachrichten die übertragen werdenkönnen [22]. Hier werden nur die beiden Nachrichten POST und GET verwendet. Auf diesenNachrichten setzt das hier entwickelte Protokoll auf.

5.1.1 Nachrichtenformat

Sowohl POST- als auch GET-Nachrichten können Namen-Werte-Paare als Parame-ter übertragen. Die POST-Nachrichten sind speziell dafür gedacht und können einefast unendlich große Anzahl an solchen Paaren aufnehmen [22]. Bei den GET-Nachrichten werden diese Paare an den Uniform Resource Locator (URL) in derForm www.server.com?name1=wert1&name2=wert2 angehängt [22]. Auch wenn dieBeschränkung der URL-Länge auf 256 Zeichen heute praktisch nicht mehr existiert, so istein sehr langer URL aufgrund von vielen Namen-Werte-Paaren doch nicht wünschenswert.Aus diesem Grund wird die GET-Nachricht nur dann verwendet, wenn es lediglich zweiNamen-Wert-Paare in der Anfrage gibt. Bei allen Mitteilungen mit mehr als zwei

5.1 Kommunikationsprotokoll 33

Parametern wird dann die POST-Nachricht genutzt.Wie bereits aufgeführt, werden diese Namen-Werte-Paare – egal ob in einer GET- oder POST-Nachricht – genutzt, um Informationen vom Client zum Server zu übertragen. Die Nach-richten des HTTP-Protokolls werden mit dem Unicode Transformation Format 8 (UTF-8)repräsentiert. Das Content Type Formate ist demnach text/plain;charset=UTF-8.Insgesamt gibt es fünf verschiedene Nachrichten. Damit der Server diese unterscheidenkann, hat jede Meldung ein Namen-Wert-Paar mit dem Namen type. Der Wert diesesParameters gibt dann an, um welche Nachricht es sich handelt.Auch die Antworten des Servers haben ein festgelegtes Format. Die Antworten im HTTPsind einfache zeilenweise Textausgaben. Jeglicher Text in den Antworten ist wiederUTF-8 codiert (Content Type: text/plain;charset=UTF-8). Um die Daten zum Clientzu übertragen, wird nun in jede Zeile ein Namen-Wert-Paar geschrieben. Diese Paaresind nach dem Format name:wert kodiert. Von diesem Format gibt es zwei Ausnahmen.Die eine ist bei der Meldung eines Fehlers (siehe 5.1.3) und die andere ist bei der reinenBestätigung nach dem Speichern einer Position am Server (siehe 5.1.2). Es ist auchmöglich, dass die Antwort des Servers ein Bild einer Gebäudekarte ist. Diese wird direktin der Antwort übertragen; sie ist damit kein Text mehr. In diesem Fall ist also dasBild die Antwort. Es wird im Content-Type image/png als Portable Network Graphicsgesendet.Damit der Client feststellen kann, ob seine Anfrage erfolgreich beantwortet wurde, werdendie HTTP Statuscodes verwendet. Dabei entspricht der Code 200 einer erfolgreichenAbarbeitung und weist auf eine Antwort mit dem angeforderten Inhalt hin. Der Code 400informiert über fehlende oder falsche Parameter in der Anfrage. Mit 404 wird gemeldet,dass der angeforderte Inhalt nicht gefunden werden konnte. Über den Code 500 wird derClient über einen internen Fehler bei der Programmverarbeitung im Server informiert.

5.1.2 Nachrichten

Nachfolgend werden nun die einzelnen Nachrichten erläutert. Der genaue Aufbau jederNachricht ist im Anhang A aufgelistet.

Rauminformationen in Kartennummer auflösen

Bei dieser Nachricht schickt der Client das Gebäude, Stockwerk die Raumnummer undoptional auch den gewünschten Maßstab an den Server. Der Server muss daraufhin diepassenden Karten suchen. Jede Karte wird über eine eindeutige Nummer verwaltet. DerServer antwortet mit der Kartennummer und den tatsächlichen Maßstab der Karte odermit einer Fehlernummer. Das genaue Nachrichtenformat ist in der Tabelle A.1 auf derSeite 67 angegeben.


Kartenbild zur Kartennummer anfordern

Mit dieser Nachricht kann der Client das Bild einer Karte vom Server anfordern. DasBild wird über die eindeutige Nummer der Karte angesprochen. Bei einer erfolgreichenAnfrage wird das entsprechende Bild direkt als Antwort übertragen; bei einem Fehler wirddie Fehlernummer zurückgeschickt. Das genaue Nachrichtenformat ist in der Tabelle A.2auf der Seite 68 angegeben.

Koordinatentransformationsmatrix anfordern

Diese Nachricht fordert die Koordinatentransformationsmatrix vom Server an. Die Matrixist mit dem Bild einer Karte fest verknüpft und wie dieses über die eindeutige Nummerder Karte abzurufen. Die Matrix besitzt drei Zeilen und drei Spalten. Diese neun Zahlenwerden als Ergebnis an den Client geschickt bzw. im Fehlerfall eine entsprechende Fehler-nummer. Das genaue Nachrichtenformat ist in der Tabelle A.3 auf der Seite 68 angegeben.

Speichern einer Position am Server

Bei dieser Nachricht sendet der Benutzer seine genaue Position und die Daten aller WLANsan dieser bekannten Stelle an den Server. Ist diese Mitteilung vollständig, wird die Posi-tion am Server gespeichert und dieser antwortet mit einer Bestätigung der Speicherung.Diese Bestätigung ist kein Namen-Wert-Paar. Da es nur eine positive Bestätigung gibt– eine negative wird durch Fehlernummern übermittelt – reicht hier der Parameternamevollkommen aus. Diese Nachricht ist damit eine Ausnahme vom üblichen Antwortformat.Das genaue Nachrichtenformat ist in der Tabelle A.4 auf der Seite 69 angegeben.

Anfordern einer Position vom Server

Mit dieser Nachricht sendet der Client die Informationen über alle WLANs an seiner unbe-kannten Position an den Server. Anhand dieser Daten muss der Server dann die Positionermitteln. Die Ortsinformation, also der vom Server bestimmte Aufenthaltsort oder eineFehlermeldung, ist dann anschließend die Antwort des Servers. Das genaue Nachrichten-format ist in der Tabelle A.5 auf der Seite 70 angegeben.

5.1.3 Fehlernummer

Über die Fehlernummern wird der Client über den aufgetretenen Fehler informiert. AlleNummern sind in der Tabelle A.6 auf der Seite 71 aufgelistet. Dort ist der Fehler ebenfallsgenau beschrieben.

5.2 Server 35

Auch die Fehlernachrichten vom Server zum Client bilden eine Ausnahme vom den re-gulären Antworten des Servers. Die Antwort ist in zwei Zeilen aufgeteilt. Die erste Zeileentspricht dem normalen Format von name:wert. Der Name ist dabei immer error:. DerWert ist dann die Fehlernummer in Hexadezimaldarstellung. Die zweite Zeile unterschei-det sich von diesem Format. Sie ist eine Fehlerbeschreibung in englischer Sprache. DieseBeschreibung wurde eingeführt, da die reine Nummer für den Menschen nicht sehr aussa-gekräftig ist, wenn er nicht die Tabelle der Fehlernummern zur Hand hat. Sie dient alsohauptsächlich als Hilfe für den Entwickler.

5.1.4 Abhörsicherheit

Alle Nachrichten werden im Klartext übertragen und sind damit für jeden lesbar. Umdennoch ein Maß an Vertraulichkeit zu erhalten, wird die HTTP Kommunikation mit demTransport Layer Security (TLS) Protokoll geschützt; es entsteht eine Hypertext TransferProtocol Secure (HTTPS) Verbindung. Das Servlet merkt von all dem aber nichts. Es wirdweiter wie gehabt in seinem Servlet Container ausgeführt. Der Client kommuniziert nunüber HTTPS mit einem Apache Web Server. Dieser Apache Server ist lokal mit dem ServletContainer verbunden und tauscht die Daten mit diesem über HTTP aus. Somit ist derkritische Teil der Verbindung über den offenen Teil des Netzwerkes mit HTTPS geschütztund die unverschlüsselte Kommunikation findet nur in einem geschützten lokalen Bereichstatt.

5.2 Server

5.2.1 Serverarchitektur

Die Abbildung 5.2 zeigt die einzelnen Softwareteile des Servers. Der Server ist vollständigin Java programmiert. Das Servlet stellt die Schnittstelle zum Kommunikationsprotokolldar. Es nimmt die Anfragen entgegen und beantwortet diese. Um die Anfragen beantwor-ten zu können, werden Daten von anderen Quellen benötigt. Auf diese wird vom Servletaus über einen Adapter und einen Connector zugegriffen. Die Aufgabe des Connectorsist dabei die Herstellung der Verbindung mit der betreffenden Resource und das Lesenbzw. Schreiben von Daten der Ressource. Der Adapter hingegen ist eine Abstraktions-schicht und stellt den darüber liegenden Teilen Funktionen zur Verfügung. Er soll einevollständige Loslösung von der Datenquelle ermöglichen. Der Adapter bietet den höherenSchichten Methoden an, welche diese verwenden. Diese Methoden bilden eine allgemeineSchnittstelle. So muss die höhere Schicht nicht mehr wissen wie die Datenquelle realisiertist. Alle für diese Ressource spezifischen Aufgaben und Eigenschaften werden vom Adapterverborgen. Auf diese Art kann die Datenquelle auch einfach ausgetauscht werden. Es istdann der Connector und der Adapter anzupassen, jedoch die Schicht darüber merkt von


dieser Änderung nichts. Ein Connector-Adapter-Paar existiert für jede Datenquelle, auf

Servlet Container

WLAN-DB

Servlet

Gebäudekarten

MapAdapter

MapConnector

MapDbAdapter

MapDbConnector

DbAdapter

DbConnector

SQL-DB

WLAN-Daten KartendatenTUM Roomfinger API

Abbildung 5.2: Zu sehen ist die Softwarearchitektur des Servers. Die in Java implementier-te Software ist in die Pakete Servlet, WLAN-Datenbank und Gebäudekarteaufgeteilt. Auf dem Datenbankserver gibt es eine Datenbank für WLAN-Daten und eine für Kartendaten. Die TUM Roomfinder API wird zumBezug der Kartenbilder genutzt.

die das Servlet zugreifen muss. Über eines dieser Paare ist der Zugriff auf die Datenbankmit den WLAN-Daten realisiert (DbAdapter und DbConnector). Ein zweites Paar stelltdie Verbindung zum TUM Roomfinder her (MapAdapter und MapConnector). Das letzteConnector-Adapter-Paar ist für den Zugriff auf die Datenbank der Koordinatentransfor-mationsmatrizen bestimmt. Diese Matrizen werden benötigt, um die Pixel-Koordinatender Karten in Weltkoordinaten umzurechnen.

In den nachfolgenden Abschnitten wird nun eine Komponente nach der anderen beschriebenund erklärt. Dabei wird in der Hierarchie von unten nach oben vorgegangen. Das heißt, eswird bei den Datenquellen begonnen und mit dem Servlet geendet. Diese Beschreibungensollen einen Einblick in die Funktion und das Zusammenspiel der jeweiligen Komponentengeben. Die Auswahl an den vorgestellten Details wurde nach dem Entwicklungsaufwandhinter diesen getroffen. Die komplette Implementierung kann im dokumentierten Quellcodeeingesehen werden, hier werden nur ausgewählte Teile vorgestellt, die entweder besonders

5.2 Server 37

interessant sind oder eine gesonderte Erklärung benötigen.

5.2.2 WLAN-Datenbank

Hier handelt es sich um eine relationale Datenbank, die mit MySQL [23] realisiert ist.Die WLAN-Datenbank teilt sich mit der Kartendatenbank zwar einen MySQL-Server, istaber vollkommen getrennt realisiert. Der Aufbau der WLAN-Datenbank ist in der Abbil-dung 5.3 dargestellt. Diese Datenbank soll die Messungen der WLANs – verknüpft mitdem Ort der Messung – aufnehmen können. Das Schema der Datenbank wurde bis zurdritten Normalform [24] normalisiert. In dieser Datenbank sollen nun alle WLAN-Daten

Abbildung 5.3: Gezeigt ist das Schema der WLAN-Datenbank. Die Tabelle sample istals Einstiegspunkt zu sehen, alle anderen Datensätze verweisen direkt oderindirekt darauf.

mit der entsprechenden Position gespeichert werden. Jede Tabelle besitzt einen automa-tisch generierten Primärschlüssel. Dieser ist mit dem Tabellennamen und der Präfix idbezeichnet. Die Spaltennamen sind so gewählt, dass diese den Parameternamen des Kom-munikationsprotokolls entsprechen. Die zentrale Tabelle ist mit sample benannt und bilden


den Einstiegspunkt in die Datensätze. In sample werden alle Einträge eines Datensatzeszusammengeführt. In der Tabelle sample selbst ist nur der Zeitpunkt der WLAN-Messung(in der Spalte timestamp) und ein Kommentar zum Datensatz (in der Spalte comment)gespeichert. Alle anderen Daten werden in den restlichen Tabellen gehalten und über Re-lation mit der Haupttabelle sample verknüpft.Bei jeder Position ist zumindest eines oder mehrere WLANs ermittelt worden. Deshalbhat jeder Eintrag in sample ein oder mehrere Korrespondenzen in der Tabelle network.Umgekehrt hat aber jedes gemessene Netzwerk genau eine Messung zu der es gehört. Innetwork werden die gemessenen Werte eines jeden WLANs gespeichert. Dies sind derName des Netzwerkes (ssid), die BSS in diesem Netzwerk (bssid), die Frequenz auf derdas WLAN betrieben wird (frequency), die gemessene Empfangsstärke (level) und dieverwendete Verschlüsselung (capabilities).Jede Messung an einer gegebenen Position ist durch ein Gerät ausgeführt worden. DieHard- (hardware) und Software (software) dieses Gerätes ist in der Tabelle device ge-speichert. Jede Messung ist genau einem Gerät zugeordnet, aber ein Gerät kann beliebigviele Messungen durchführen.Die Tabelle user enthält die Benutzer des Systems. Ein Benutzer kann beliebig viele Da-tensätze speichern, jedoch gehört zu jedem Datensatz genau einen Benutzer, der diesengespeichert hat.Die Tabelle coordinate speichert eine Position im WGS 84 Koordinaten (longitude,latitude, altitude) mit der Genauigkeit dieser Messung in cm (accuracy). An einerPosition kann es beliebig viele Messungen geben, jedoch ist eine Messung immer mit genaueinem Ort verknüpft.Die gespeicherten Koordinaten stehen mit dem Raum im Gebäude (location) in Verbin-dung. Ein Raum ist durch die Gebäudenummer (building), das Stockwerk (floor) unddie Raumnummer (room) charakterisiert. Für jedem Raum im Gebäude existieren vieleKoordinaten, die unterschiedliche Positionen im Raum beschreiben, aber pro Koordinategibt es nur einen passenden Raum.

5.2.3 Kartendatenbank

Um die Pixelkoordinaten, die auf dem Bild der Gebäudekarten existieren, in Koordinatenim WGS 84 umzurechnen werden 3 × 3-Matrizen benötigt. Diese Matrizen sind im Vor-aus berechnet und in der Datenbank gespeichert. Auch diese Datenbank ist mit MySQLrealisiert und wird auf den gleichen Server wie die WLAN-Datenbank betrieben. Das ver-wendete Datenbankschema entspricht auch mindestens der dritten Normalform. In dieserDatenbank gibt es nur zwei Tabellen, matrix und value. Jede Tabelle besitzt einen au-tomatisch generierten Primärschlüssel; idmatrix für die Tabelle matrix und idvalue fürdie Tabelle value. Jeder Karte ist eine eindeutige Nummer zugeordnet. Diese Nummer istin matrix gespeichert. Durch eine Suche in dieser Tabelle kann also bestimmt werden, obes eine Matrix für diese Kartennummer gibt. Zu jeder Matrix gehören nun neun Zahlen,welche die Einträge in der Matrix darstellen. Umgekehrt gehört jeder Eintrag zu genau

5.2 Server 39

Abbildung 5.4: Zu sehen ist das einfache Schema der Kartendatenbank mit lediglich zweiTabellen. Über die Einträge matrix kann die Existenz einer Matrix inder Datenbank ermittelt werden, während value die eigentlichen Datenenthält.

einer Matrix. Die Einträge sind in der Tabelle value in der Spalte value gespeichert.Die Spalte cell beinhaltet die Angabe zu welcher Position in der Matrix der Wert passt.Dabei ist in cell immer eine zweistellige Zahl gespeichert, wobei jede Stelle eins, zwei oderdrei sein kann. Die erste Stelle gibt dabei die Zeile und die zweite Stelle die Spalte derPosition an, an welcher der Wert in der Matrix steht. Gültige Werte sind demnach für die3×3-Matrix: 11, 12, 13 für die erste Zeile, 21, 22, 23 für die zweite Zeile und 31, 32, 33 fürdie dritte Zeile. Diese Art der Kodierung wurde gewählt, da so später ein automatisiertesSortieren und Auslesen der Werte möglich wird.

5.2.4 TUM Roomfinder API

Die TUM Roomfinder API [25] stellt eine Möglichkeit zur Verfügung, um auf Architektur-daten der TU-Gebäude zuzugreifen. Der Zugriff erfolgt über Extensible Markup LanguageRemote Procedure Call (XML-RPC), eine Technik um Methoden auf dem RoomfinderServer aufzurufen. Es wird eine Vielzahl an Methoden angeboten. Hier werden aber nurzwei davon in Anspruch genommen. Die Information über die Methoden wurde aus derTUM Roomfinder Dokumentation [25] entnommen.

getRoomMaps( r id ) – Über diese Methode wird eine Liste aller Karten für einen Raumangefordert. Der Raum wird über den String r id bestimmt. Dieser String ist im For-mat Raumnummer@Gebäudenummer anzugeben. So ist beispielsweise der Raum

”Z999“ im

Gebäude”9“ des Stammgeländes mit Z999@0509 zu bezeichnen, wobei

”05“ das Stamm-

gelände und”09“ das Gebäude

”9“ bezeichnen. Wichtig ist hier, dass Buchstaben in den

Raumnummern immer als Großbuchstaben geschrieben werden müssen.Als Antwort wird eine Liste an Kartendaten geliefert. Ein Listenelement beinhaltet denMaßstab der Karte, die eindeutige Nummer der Karte, eine textuelle Beschreibung, sowie


die Breite und Höhe der Karte in Pixel. Die Angabe des Maßstabs erfolgt als einfacheZahl, das heißt der Maßstab

”1:2000“ wird als 2000 angegeben.

getMapImage( m id ) – Die Methode liefert das Bild, welches mit der eindeutigen Kar-tennummer m id verknüpft ist.Die Antwort vom Server beinhaltet zwei Felder. Das erste Feld ist das Bild in Base64codierter Form. Der zweite Teil ist ein String, welcher den Content Type angibt, beispiels-weise image/gif.

5.2.5 Connectors

Die Aufgabe der Connectors ist es, eine Verbindung mit den darunterliegenden Datenquel-len herzustellen und Daten von diesen zu lesen bzw. in diese zu schreiben. Sie müssen dieUmsetzung der Daten zwischen der Repräsentation, welche für die Daten in der Daten-quelle gewählt ist, und jener, die in Java verwendet wird, durchführen.Im folgenden Teil sind die Aufgaben der einzelnen Connectors kurz aufgeführt. Wichtigebzw. komplexe Funktionen darin werden beispielhaft erklärt; für Details wird hier aberauf den kommentierten Quellcode verwiesen.

DbConnector

Der DbConnector stellt die Verbindung zur WLAN-Datenbank her. Dabei wird der MySQLConnector/J [26] benutzt. Dieser baut die Verbindung zum MySQL Server auf, erlaubtes Structured Query Language- (SQL) Befehle [24] auf der Datenbank auszuführen undliefert das Ergebnis dieser Befehle schon als Daten, repräsentiert durch entsprechende Java-Datentypen. Dadurch wird die Kommunikation mit der Datenbank erheblich vereinfacht.Es bleibt für den DbConnector als Hauptaufgabe nur die Daten per SQL-Befehl zu lesenbzw. zu speichern. Ausgewählte Beispiele von diesen SQL-Befehlen aus diesem Bereichwerden hier nun vorgestellt.

Verknüpfen der Tabellen – Bei dem Betrachten des Datenmodells in Abbildung 5.3wird klar, dass viele Abfragen Daten aus mehreren Tabelle beziehen. Durch die gewähltenKardinalitäten kann dies jedoch stark vereinfacht werden. Es wird hier immer nur dersogenannte Inner-Join (auch Equi-Join) verwendet. Dieser verbindet zwei Tabellen immerdann, wenn in den gemeinsamen Spalten die Werte gleich sind. Die gemeinsamen Spaltensind hier immer Primär- oder Fremdschlüssel.

Suchen von passenden Fingerprints – Eine problematische Fragestellung war zu Be-ginn, wie schnell die richtigen Fingerprints gefunden werden können. Ein Fingerprint istdann relevant, wenn er zumindest bei einem Netzwerk die gleiche BSSID aufweist, also esmindestens einen gemeinsamen Access-Point gibt. Je mehr Basisstationen übereinstimmen,

5.2 Server 41

desto größer ist die Relevanz des Fingerprints. Es ist jedoch auch möglich, dass selbst Mes-sungen, die am selben Ort durchgeführt wurden, nicht immer die exakt gleichen Basissta-tionen aufweisen (wie in Kapitel 4 gezeigt). Diesem Problem wird mit der IN-Anweisungbegegnet. Dieser Anweisung wird eine Liste der BSSIDs im Fingerprint gegeben. DieAnweisung bindet nun alle Netzwerke in das Ergebnis mit ein, bei denen die BSSIDgleich einer der in der Liste aufgeführten BSSIDs ist. Nun wird für jedes dieser Netz-werke noch der Primärschlüssel der Messung angeführt, zu welcher diese BSSID gehören.Durch zählen, wie oft der Primärschlüssel eines Fingerprints nun vorkommt, ist die Anzahlder übereinstimmenden Netzwerke je Fingerprint ermittelt.Ebenso soll eine Bevorzugung im Ergebnis der neueren Daten erzielt werden. Da bei jedemFingerprint die Zeit der Messung gespeichert ist, kann damit leicht eine Sortierung vor-genommen werden. Schwieriger ist es, die Treffer zu bevorzugen, welche mit der gleichenSoft- bzw. Hardware erzeugt worden sind. Dafür wird die FIELD()-Funktion herangezo-gen. Diese nimmt als Argument eine Liste von Zeichenketten auf. Die erste Zeichenketteist dabei die Referenz, die restlichen sind die Vergleichswerte. Die Funktion gibt nun eineZahl zurück, die angibt, an welcher Stelle in der Liste die Referenz gefunden wurde. Wurdedie Referenz nicht gefunden, so wird eine Null zurückgegeben. Hat die Vergleichsliste alsonur einen Eintrag, bekommen wir eine Null oder eine Eins als Ergebnis. Wird jetzt aufBasis dieses Ergebnisses sortiert, so können wird jene Resultate bevorzugen, welche denReferenzstring enthalten haben.

Mehrfachzuordnungen – Die Vorgehensweise bei diesem Problem soll anhand eines Bei-spiels verdeutlicht werden, gilt aber für alle Orte des Auftretens sinngemäß. Als Beispielwird die Zuordnung des Benutzernamens zum Fingerprint gewählt. Ein Benutzer kannbeliebig viele Fingerprints in der Datenbank speichern. Es ist aber nicht notwendig, jedesMal dabei den Benutzernamen neu zu speichern; es wird über den Primärschlüssel immerwieder auf den gleichen Namen verwiesen. Aus diesem Grund muss der Primärschlüsseldes verwendeten Benutzernamens bekannt sein. Dieser wird aber nicht außerhalb der Da-tenbank gespeichert. So muss der Primärschlüssel des entsprechenden Benutzernamens vordem Speichern eines Datensatzes gesucht werden. Wird er gefunden, so existiert der Ein-trag bereits und er kann mit den restlichen Daten verknüpft werden. Wird kein passenderEintrag gefunden, so wird er neu erstellt. Dies sollte in der Regel aber der seltenere Fallsein, da der Benutzer ja meist mehrere Einträge unter seinem Namen ablegt. Deshalb istder Regelfall nur eine Suche und schnell erledigt. Lediglich bei der ersten Eingabe in dieDatenbank muss nach einer nicht erfolgreichen Suche noch der neue Eintrag gespeichertwerden; dies dauert länger.

MapDbConnector

Der MapDbConnector liest die Werte der Koordinatentransformationsmatrizen aus der Kar-tendatenbank aus und stellt die Verbindung zu dieser Datenbank her. Der MapDbConnectorkommt somit mit einem reinen Lesezugriff über den MySQL Connector/J zum MySQL Ser-


ver aus.

MapConnector

Der MapConnector verwendet die Apache XML-RPC Bibliothek [27] um auf die Methodender TUM Roomfinder API zuzugreifen. Für die Kommunikation wird keine dauerhafteVerbindung aufgebaut, sondern es werden nur bei Bedarf Daten mit dem Server ausge-tauscht.Der Apache XML-RPC Client kommuniziert mit dem MapConnector ausschließlich überArrays vom Typ Object. Dies gilt auch dann, wenn nur ein Parameter übertragenwird; dann hat das Array auch nur einen Eintrag. Im Fall der Antwort der MethodegetRoomMaps( r id ) (siehe Seite 40) wird für jede gefundene Karte eine Liste von Wer-ten returniert. Hier liefert der XML-RPC Client ein Array bei dem jedes Element noch einweiteres Array ist, also ein Array of Arrays. Der MapConnector muss nun die zu sendendenDaten in Arrays und die empfangenen Daten in den entsprechenden Daten- bzw. Objekt-typ wandeln. Das Bild der Karte wird als Base64 codiert geliefert. Um es wieder zurückins Bildformat zu wandeln, ist die Apache Commons Codec Bibliothek [28] in Verwendung.

5.2.6 Adapter

Das Ziel der Adapter ist es, die benutzte Technologie der darunterliegenden Schichten zuverbergen. Dies ist notwendig, damit das Servlet nicht die verwendeten Technologien derDatenquellen unterstützen muss. Die Adapter sind also als Abstraktion von den Daten-quellen zu verstehen. So werden die aufgetretenen Excpetions, welche technologiespezifischsind, durch allgemeinere Exceptions ersetzt (z.B. SQLException durch DbExcption). DieAdapter stellen dem Servlet Methoden zur Verfügung, über die das Servlet auf die Datender darunterliegenden Schichten zugreifen kann. Durch diese Abstraktion ist der Austauscheiner Datenquelle bzw. der Umstieg auf eine andere Technologie leicht möglich.

DbAdapter

Der DbAdapter bietet dem Servlet zwei Methoden an und benutzt zur Ausführung die-ser die vom DbConnector bereitgestellten Methoden. Zum Einen können die Daten einesFingerprints in der Datenbank gespeichert werden, also die WLAN-Messung mit der ent-sprechenden Position, Benutzername und Kommentar. Zum Anderen gibt es die Funktion,die Position eines unbekannten Fingerprints zu bestimmen. Dazu werden passende Finger-prints in der Datenbank gesucht. Nun muss entschieden werden, welcher dieser Fingerprintsdie beste Übereinstimmung mit dem Fingerprint der gesuchten Position hat. Durch dieSuche in der Datenbank sind bereits die gefunden, welche aufgrund der BSSIDs, verwende-ter Hard- bzw. Software am besten passen und am aktuellsten sind. Um nun die Messung

5.2 Server 43

mit der besten Übereinstimmung zu finden, wird der euklidische Abstand der Messungenberechnet. Dazu wird die gemessene Signalstärke der Basisstationen als Abstandsmaß ver-wendet. Ist ein WLAN nicht vorhanden, wird für dieses WLAN der Pegel zu -100dBmangenommen. Auf diese Art kann ein Abstandsmaß errechnet werden. Die Position desFingerprints mit dem geringsten Abstand wird dann als Schätzwert der richtigen Positionverwendet.

MapDbAdapter

Die Klasse MapDbAdapter hat die Aufgabe, die technologiespezifischen Excpetions zu ver-bergen und in neutrale umzusetzen. Diese Eingeschränktheit kommt daher, dass die Klassenur die Koordinatentransformationsmatrix einliest und auch diese Funktion nicht direktdem Servlet, sondern dem MapAdapter zur Verfügung stellt.

MapAdapter

Der MapAdapter dient in erste Linie dazu die technologiespezifischen Exceptions desMapAdapter zu verbergen. Die Suche nach einem Bild und der Koordinatentransforma-tionsmatrix werden hier nur gekapselt. Bei der Suche nach der passenden Kartennum-mer für den gewünschten Raum wird hier die Karte mit dem Maßstab gesucht, der demgewünschten am nächsten kommt.

5.2.7 Servlet

Das Servlet ist die zentrale Stelle in der Hierarchie des Servers. Es startet die Ausführungaller anderen Programmteile. Der Tomcat Servlet Container [29] dient zur Ausführung desServlet. Die HTTP Anfragen der Clients werden vom Tomcat Server entgegengenommenund an das Servlet geleitet. Das Servlet generiert die Antwort, die vom Tomcat Serverwieder an den Client gesandt wird. Um die Antworten generieren zu können, muss dasServlet auf die von den Adaptern angebotenen Methoden zurückgreifen.Die Anfragen an das Servlet werden über HTTP POST- und GET Methoden gestellt (sie-he Kapitel 5.1). Für die Beantwortung dieser Anfragen ruft der Servlet Container diedoPost()- bzw. doGet()-Methode des Servlets auf. In diesen Methoden wird dann derTyp der Anfrage bestimmt und die dementsprechende Methode aufgerufen, um die Anfragezu bearbeiten. In den einzelnen Methoden, in denen eine Anforderung eigentlich abgear-beitet wird, werden zuerst die Parameter der Anforderung eingelesen. Dies geschieht mitHilfe der Klasse ParameterParser, welche die Möglichkeit bietet, die immer als Namen-Wert-Paare geschickten Parameter in Variablen zu lesen. Dabei wird auch eine Typen-konvertierung vorgenommen, denn in den Parametern der HTTP-Anfragen können nurZeichenketten übertragen werden, welche an dieser Stelle wieder in Java Datentypen (int,


double, etc.) gewandelt werden. Die auf diese Art eingelesenen Werte werden nun an dieentsprechende Adaptermethode übergeben. Diese generiert entweder aus ihrer Datenquelleeine entsprechende Antwort, oder – wenn dies nicht möglich ist – wird ein Fehler oder dasFehlen einer Information über eine passende Exception gemeldet. Das Servlet muss nundie durch den Adapter gelieferte Information an den Client zurückschicken. Sollte eineException aufgetreten sein, so wird diese in die entsprechende Fehlernummer übersetztund die Fehlernachricht an den Client geschickt.

5.3 Client

Der Client ist ein Android Programm, welches die Eingaben des Benutzers entgegenneh-men und an den Server weiterleiten muss, sowie die Antworten des Servers wieder demBenutzer darzustellen hat. Im Laufe dieses Abschnitts soll dargestellt werden, wie dieseAufgabe gelöst wird. Das Kapitel ist in drei Teile gegliedert. Im ersten Teil werden dieeinzelnen Komponenten des Android Programms vorgestellt. Der zweite Teil beschäftigtsich mit dem Zusammenspiel dieser Klassen und der dritte Teil wirft einen Blick auf dieBenutzeroberfläche des Programms.Es gilt noch anzumerken, dass der Programmaufbau und die Umsetzung stark durch dasBuch [30] inspiriert wurde.

5.3.1 Programmteile

Hier werden nun einige wichtige Programmkomponenten vorgestellt. In diesem Fall sindKomponenten immer mit Java Klassen gleichzusetzten. Genau beschrieben werden indiesem Abschnitt nur jene, die eine zentrale Rolle in der Programmlogik spielen. Für dierestlichen Klassen wird auf den kommentierten Quellcode verwiesen.Neben den Klassen, welche sich in den Aufgaben und der Architektur nicht von normalenJava-Klassen unterscheiden, gibt es in dieser Implementierung zwei besondere Klassen,welche in dieser Form nur im Zusammenhang mit Android-Anwendungen existieren. Zumersten wären dies Klassen vom Typ Activity. Dabei handelt es sich um Klassen, diegrafische Oberflächen für den Benutzer erstellen. Zum zweiten sind Klassen vom TypService zu nennen. Diese Klassen arbeiten in eigenen Threads im Hintergrund und bietenden Activity-Klassen die notwendigen Daten für die Erfüllung ihrer Funktionen.

MapActivity

Dies ist die Hauptklasse des Programms und stellt auch den Hauptbildschirm dar. Hierlaufen alle Informationen zusammen und werden entsprechend dargestellt. Für die Dar-stellung der Gebäudekarte wird auf die Komponente MapView zurückgegriffen, welche die

5.3 Client 45

Bilder der Karten anzeigen kann. MapActivity selbst ist mehr als Container und Bin-deglied zwischen den einzelnen Komponenten der Benutzeroberfläche zu sehen. Als einerdieser Teile der Oberfläche sei noch das Optionsmenü erwähnt, über das die vom Benutzergewünschten Aktionen gestartet werden können.

MapView

MapView zeigt das Bild der Karte und bietet eine Zoom-Funktion für diese. Der Benutzererhält durch diese Klasse auch die Möglichkeit seinen aktuelle Aufenthaltsort zu markieren.Die vom Server ermittelte Position wird von MapView in der Karte vermerkt. Die Koor-dinatentransformationsmatrix wird ebenso an MapView übergeben. Auf diese Art könnenalle Positionsangaben in WGS 84 Koordinaten an MapView geliefert werden und müssennur innerhalb von MapView in Pixelkoordinaten gehalten werden.

ServerConnectionService

Über das Service kann die MapActivity Anfragen an den Server schicken. Das Serviceführt diese Anfragen in einem eigenen Thread durch. So kann die MapActivity weiterhinEingaben des Benutzers entgegennehmen, da ihr Thread nicht mit der Bearbeitung derAnfrage belegt wird. Erst wenn eine Rückmeldung vom Server existiert, oder dieser nichtgeantwortet hat, wird die MapActivity vom Service wieder verständigt.Die praktische Umsetzung dieser einfachen Überlegung sieht allerdings et-was schwieriger aus. Die vom ServerConnectionService angebotenen Me-thoden sind im Interface IServerConnectionService festgelegt. Die KlasseServerConnectionServiceImpl implementiert dann diese Methoden in ihrer inter-nen Subklasse ServerConnectionServiceBinder. Der Binder ist notwendig, damitspäter die Activity eine Verbindung zum Service herstellen kann. Um die Kommuni-kation tatsächlich auszuführen, wird vom ServerConnectionService auf die KlasseHttpConnector zurückgegriffen. In diese Klasse sind die eigentlichen HTTP Anfragenausgelagert.

WifiScanManager

Mit Hilfe des WifiScanManagers kann auf die Android-Systemfunktionen für die Steue-rung der WLAN-Schnittstelle zugriffen werden. In diesem Zusammenhang werden davonnur wenige Funktionen benötigt. Es kann überprüft werden, ob das WLAN-Modul amSma

Documents

Studienarbeit - uni-passau.de · Creation of a WiFi Indoor Localization platform using Android Mobile phones of today { often so called smart phones { o er a functionality that goes