-
Technische Universität Mü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 Funktionalität
bieten, welche weit überdie Grenzen von reinen
Kommunikationsdiensten hinausgeht. Besonders oft wird dabei
dieMöglichkeit der Navigation gewünscht. Da diese Smartphones
fast ausnahmslos mit GlobalPositioning System (GPS) Empfängern
ausgestattet sind, gibt es für die Wegfindung unterfreiem Himmel
schon viele und gute Programme. Innerhalb von Gebäuden ist der
Emp-fang von GPS-Signalen praktisch kaum möglich. Deshalb liefert
dieses satellitengestützesVerfahren innerhalb von Gebäuden keine,
oder nur sehr schlechte, Ergebnisse. Da es aberauch in großen und
unbekannten Bauwerken für ortsfremde Personen oft schwer ist,
Räumeund vereinbarte Treffpunkte zu finden, soll hier Abhilfe
geschaffen werden.
Damit das geplante System auf bereits verfügbaren Smartphones
eingesetzt werden kann,muss fü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 für
Kommunikation – und nicht füreine Positionsbestimmung – ausgelegt
ist, muss erst eine Möglichkeit geschaffen werdenum aus den WLAN
Signalen eine Position zu bestimmen.Damit handelsübliche
Mobiltelefone verwendet werden können, ist eine Analyse
derWLAN-Signale lediglich auf der Software-Ebene möglich. Das
heißt, eine direkte elek-tronische Signalverarbeitung ist nicht
möglich und es können nur jene Parameter desWLAN-Signals
herangezogen werden, die durch das Smartphone ausgewertet und
überSoftware zugänglich sind. Des Weiteren verändern sich die
Empfangsbedingungen derWLAN-Signale gerade innerhalb von Gebäuden
mit der Zeit und dem Ort sehr stark. Die-se beiden Faktoren
bedingen einen Ansatz, der mit diesen Einschränkungen umgehen
kannund dennoch brauchbare Ergebnisse liefert.In dieser Arbeit soll
dafü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 durchgeführt, wird diese Messung mit denen in derDatenbank
verglichen. Die genaue Position kann dann über unterschiedliche
Methoden be-stimmt werden. Als einfachstes Verfahren kann die
Position der Messung mit der größtenÜbereinstimmung als
Schätzung der unbekannten Position dienen.
Im Rahmen dieser Arbeit sollen zunächst die Charakteristika der
WLAN-Signale und derMessung der Signale mit Smartphones ermittelt
werden. Dies soll die Grundlage liefernfür eine Beispielumsetzung
eines Systems zur Positionsbestimmung. Das System soll auseiner
Applikation fü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
-
4
-
Inhaltsverzeichnis
Inhaltsverzeichnis 5
1 Einleitung 91.1 Ortsbestimmung unter freiem Himmel . . . . . .
. . . . . . . . . . . . . . 91.2 Motivation für Ortsbestimmung in
Gebäuden . . . . . . . . . . . . . . . . 9
1.2.1 Mö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 Empfangsstärke . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 182.2.7 Fingerprinting . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 19
3 Bestehende Fingerprinting Systeme 213.1 Cisco RF
Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 213.2 awiloc . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 23
4 Signalstärkenmessung in WLANs 254.1 WLAN Logging Application
. . . . . . . . . . . . . . . . . . . . . . . . . . 254.2
Nutzungsabhängigkeit . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 264.3 Zeitliche Abhängigkeiten . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 274.4 Abhängigkeit von
unterschiedlichen Gerä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 Abhö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
Anwendungsoberflä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 Veränderter Positionsbestimmungsalgorithmus . . . . . . . .
. . . . . . . . 61
7 Zusammenfassung 637.1 Rückblick . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 637.2 Ausblick . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
A Nachrichtenformate und Fehlernummern 67A.1 Rauminformationen
in Kartennummer auflö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 Gerä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
-
8
-
Kapitel 1
Einleitung
1.1 Ortsbestimmung unter freiem Himmel
Die Ortsbestimmung war und ist der wichtigste Grundstein für
die Navigation zu Lande,zu Wasser und in der Luft. In den letzten
Jahrzehnten haben sich dafür elektronische,satelliten-gestützte
Systeme durchgesetzt. Diese Systeme benutzen Satelliten, welche
dieErde umkreisen und permanent ein Funksignal zur Erde senden. Da
die Empfänger aufder Erdoberfläche das Signal von mehr als einen
Satelliten empfangen, können sie so ihrePosition berechnen. Als
Vertreter ist das heute am häufigsten eingesetzte Global
Positio-ning System (GPS), das noch im Aufbau befindliche
europäische Galileo und das russischeGLONASS zu nennen [1].Für
Anwendung auf Smartphones ist heute praktisch ausschließlich GPS
relevant. GPSEmpfänger sind in der überwiegenden Anzahl der heute
erhältlichen Smartphones ver-baut [2]. Dadurch wurde es zu einem
Quasistandard für die Ortsbestimmung im Freien.Damit der Benutzer
nicht nur lediglich seine Position mitgeteilt bekommt, die in
Koordi-naten ausgedrückt für fast alle Benutzer wenig
aussagekräftig ist, gibt es eine Vielzahl anProgrammen, welche die
Position auf einer Karte der Umgebung darstellen. Diese Pro-gramme
sind für alle gängigen Plattformen der Smartphones erhältlich
[3]. Der Großteildieser Software geht über eine reine Anzeige der
via GPS bestimmten Position weit hin-aus. So ist die Wegfindung zu
einem frei wählbaren Ort, Aufzeichnung des zurü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 für den Benutzer zu finden.
Sokönnen beispielsweise Sehenswürdigkeiten, Geschäfte,
Restaurants und vieles mehr darinverzeichnet sein [3].
1.2 Motivation für Ortsbestimmung in Gebäuden
Da das Angebot an Informationen zur aktuellen Position wie
erläutert sehr groß ist, erwar-ten sich die Benutzer nun auch
ähnliche Angebote innerhalb von Gebä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 Mögliche Anwendungen
Für genaue Ortsbestimmungen innerhalb von Gebäuden wäre
beispielsweise das Verfolgenvon autonomen Transportfahrzeugen in
Produktionsstätten eine mögliche Anwendung. Indem Umfeld dieser
Arbeit soll jedoch eine Beschränkung auf Smartphone-basierte
Sze-narien gelten. Aber auch mit dieser Einschränkung gibt es eine
Vielzahl an möglichenEinsatzszenarien. Jeder der sich schon mal in
einem unbekannten und großen Gebäudezu Recht finden musste, kann
den Wunsch nach einer Navigationshilfe verstehen. Mit
derMöglichkeit der Positionsbestimmung innerhalb von Gebäuden
kann zum Beispiel ortsfrem-den Personen ein Navigationsdienst
angeboten werden. Aber auch ohne der Möglichkeitder Wegfindung,
und damit verbundenen vollständigen Navigation, gibt es denkbare
An-wendungen. So kann dem Benutzer der Raum genannt werden, in dem
er sich geradebefindet. Mit dieser Information können wiederum
weitere wichtige Hinweise verknüpftsein. Diese könnten im
universitären Umfeld zum Beispiel der Raumbelegungsplan oderin
einem Museum kann das eine Erklärung zu den ausgestellten
Gegenständen im Raumsein [4].
1.2.2 Verfahren und Methoden
Die Idee der Ortsbestimmung in Gebäuden ist natürlich nicht
neu. Es wurden deshalbauch schon verschiedenste Verfahren
entwickelt. An dieser Stelle sollen nun Beispiele dafürvorgestellt
werden. Da in dieser Arbeit im weiteren Verlauf mit einem auf
Wireless LocalArea Networks (WLAN, hier synonym für Netze nach dem
Standard IEEE 802.11a, b,g oder n) basierenden Ansatz gearbeitet
wird, sollen zuvor noch Beispiele für Verfahrengenannt werden, die
anders arbeiten. Es gibt natü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 ü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 Wände, angebracht.
Siestrahlen nun in periodischen Abständen sowohl ein Funk-, als
auch ein Ultraschallsignalab. Der Empfänger kann aus dem
Laufzeitunterschied der beiden Signalen die Abstände
-
1.2 Motivation für Ortsbestimmung in Gebä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 Empfängers berechenbar.Das
System besitzt den Vorteil, dass das Stockwerk und der Raum mit
Sicherheit bestimm-bar sind, denn die Schallwellen können keine
Wände oder Decken überwinden. Nachtei-lig wirkt sich aus, dass
eine spezielle Sendeinfrastruktur aufgebaut werden muss; ebensosind
die Empfänger speziell angepasste Geräte. Des Weiteren können
auch Gengenständeoder Personen die Ultraschallwellen abschirmen
und so die Systemfunktionalität beein-trächtigen [5, 6].
UbiSense
Die Firma UbiSense vertreibt ein Ortsbestimmungssystem auf Basis
von Funkwellen. Dabeiwerden Empfänger im Raum an bekannten
Positionen verteilt und untereinander verbun-den. Die mobile
Einheit dient als Sender. Diese bekommt über einen Funkkanal im
2,4GHzBand die Aufforderung einen Ultrabreitbandimpuls im 6-8GHz
Bereich abzusetzen. Dieuntereinander vernetzten Empfänger kö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 für große Anlagen mit sehr vielen mobilen
Teilnehmern geeignet.Im Vergleich zum Ansatz mit Ultraschall sind
Funkwellen nicht auf direkte Verbindungenangewiesen. Es können
aber in dem hier gewählten, sehr hohen Frequenzbereich,
schongrößere metallische Objekte Probleme bereiten. Dieses System
ist auch auf eigene Hard-ware für Sender und Empfänger
angewiesen. Die nötige Verkabelung der fest installiertenStationen
ist auch zusätzlich als Nachteil zu werten [6].
Nutzung bestehender Infrastruktur – WLAN Lokalisierung
Fü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
Überlegungen ist esnatürlich klar, dass nur jene genutzt werden,
die auch ohne rechtliche Einschränkungenempfangen werden dürfen.
Denkbar wäre also die Verwendung von beispielsweise
Radio,Fernsehen, Mobilfunk und WLAN. Da diese Funknetze bereits in
hoher Dichte aufgebautsind, wird keine zusätzliche Infrastruktur
benötigt. Des Weiteren sind heutige Smart-phones bereits mit einem
Empfänger für einige dieser Netze ausgestattet. Ebenso
bietenSmartphones heute schon nennenswerte Rechenleistung [7],
welche die Ausführung vonLokationsprogrammen auf ihnen erlauben.
Damit kann auf die Entwicklung von eigenerHardware vollständig
verzichtet werden, und die Aufgabe ist gänzlich durch Software
erle-
-
12 Kapitel 1 Einleitung
digbar.Die größten Vorteile dieses Ansatzes sind, dass
keinerlei Kosten für den Aufbau einer Infra-struktur anfallen und
dass handelsübliche Smartphones als mobile Station
herangezogenwerden können. Dadurch ist schnell und günstig ein
Lokalisierungssystem installierbar. Je-doch sind die hierzu quasi
zweckentfremdeten Netze nie für eine Lokalisierung von
Gerätengedacht gewesen. Deshalb ergibt sich natü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 esmö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. Über diese soll der
Benutzer die Möglichkeit haben, seine aktuelle Positionü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 Gebäudes wieder dem Benutzer zupräsentieren.
Die Berechnungen im Hintergrund zur Erfü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 nötigen Infor-mationen fü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.
Für den Benutzersoll ein Smartphone genügen um diese Aktionen
durchführen zu kö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 fü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 Möglichkeit geben,
dass eine Karte des Raumes im Gebäude angefordertwerden kann.
Diese Anforderung kann entweder über eine manuelle Eingabe von
Gebäude,Stockwerk und Raum, oder über das Lesen eines QR-Codes
erfolgen. Als QR-Codes sinddabei die bereits an den Tü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 übermitteln kö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
wählbarerKommentar eingegeben werden kö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 Erdoberflä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 lauffähig sein; dabei
soll Android-Version 2.1 und höher unterstützt werden.Für das
Lesen von QR-Codes soll auf Googles ZXing zurückgegriffen
werden.Die Smartphone-Applikation hat mit dem Server des Systems
über das Hypertext TransferProtocol (HTTP) zu kommunizieren. Der
Server soll anhand eines Java Servlets auf einemApache Tomcat
Server der Version 6 implementiert werden.Für die benötigte
Datenbank des Systems ist eine MySQL-Datanbank zu verwenden.Die
Karten für die Darstellung der Position des Benutzers sollen ü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.
-
14
-
Kapitel 2
Positionsbestimmung in Funknetzen
In diesem Kapitel sollen die nötigen Verfahren und Praktiken
vorgestellt werden, welche zurPositionsbestimmung in Funknetzen
dienen kö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 erläutert werden. Diese dient als Grundlage fü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 Verfügung. Access-Points werden auch
als Basisstationen bezeichnet. Eshandelt sich dabei um spezielle
Geräte, welche eine Umsetzung der Kommunikation vondrahtgebunden
auf drahtlos vornehmen. Diese Access-Points bieten nun anderen
Teilneh-mern in ihrer Umgebung die Möglichkeit, auf das Kernnetz
zuzugreifen. Die Reichweitesolcher Access-Points ist allerdings
beschränkt. Um damit große Gebäude flächendeckendversorgen zu
können, werden nun mehr als eine Basisstation benö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. Fü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 für jeden Access-Point in diesemWLAN eine BSSID.
Aus den einzelnen BSSs ergibt sich eine Art zellulares Netz, das
sichüber ein Gebäude erstreckt. Damit sich an den Grenzen der
Zellen, die jeweils von einemanderen Access-Point versorgt werden,
keine Störungen ergeben, operieren diese in
anderenFrequenzbereichen, sogenannten Kanälen. Durch Nutzung
unterschiedlicher Frequenzen istes auch möglich mehr als einen
Access-Point auf der gleichen Position zu haben.
MancheBasisstationen kö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 können,
beispielsweise auf Grund von sicherheitstechni-schen Überlegungen
[8].
Alle Geräte, die von einem Access-Point bedient werden, teilen
sich die Luftschnittstelle alsgemeinsames Medium. Damit dennoch
eine gezielte Kommunikation möglich ist, muss eineAdressierung
vorliegen. Jedes Endgerät und auch jeder Access-Point verfügt
deshalb übereine weltweit eindeutige Adresse, die sogenannte
Medium Access Control Adresse, kurzMAC-Adresse. Sie wird benötigt,
um eine Kommunikation mit eindeutiger Quelle und Zielaufzubauen.
Ebenso wird die MAC-Adresse der entsprechenden Basisstation, meist
auchals BSSID des jeweiligen BSS, gewählt [8].
2.2 Verfahren zur Positionsbestimmung
In diesem Abschnitt werden nun verschiedenste Verfahren zur
Ortsbestimmung vorgestellt.Nicht alle dieser Ansätze eignen sich
für eine Anwendung bei Positionsbestimmung imWLAN, sollen aber
hier dennoch für die technischen Mö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 Endgerät gerade
kommuniziert. Diese Zelle ist durch den Access-Point,welcher die
mobilen Geräte darin bedient, bestimmt. Die Ermittlung der Zelle
durch dasEndgerä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. Über eine
zentrale Datenbank, in dieMAC-Adressen der Access-Points mit ihrem
dazugehörigen Standort verzeichnet sind, lässtsich nun die
Position des Clients bestimmen [9].
Hier erkennt man sehr schnell, dass die Genauigkeit der
Positionsbestimmung mit der Zell-größe einhergeht. Da die
Funkzellen jedoch auch in Gebäuden bei günstigen
Verhältnissenbis zu 25m Ausdehnung haben können, ist das
Verfahren nur sehr ungenau [10]. Aufgrundder Einfachheit in der
Umsetzung ist es jedoch nicht ganz von der Hand zu weisen. Füreine
bessere Genauigkeit gäbe es die Möglichkeit, dieses
Lokalisierungsverfahren in Kombi-nation mit anderen Verfahren
einzusetzen. Hier könnte mit COO bereits eine Eingrenzungdes
möglichen Gebietes für andere genauere Verfahren gefunden werden,
die dann lediglicheinen kleineren Suchbereich abdecken
mü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 Gerät ausschlaggebend ist.
Das Signal wird von festenBasisstation zur mobilen Einheit
gesendet. Bei diesem Verfahren werden genaue, und inallen Stationen
synchrone Zeitgeber benötigt. So kann dann die Ausbreitungszeit
einesSignals bestimmt werden. Die Sendezeit kann auf das Signal
moduliert sein, oder sie istdem Empfänger a priori bekannt. Dann
ist aus Ankunftszeit, die der Empfänger selbstmisst, und der
Sendezeit, die Dauer bestimmbar, die das Signal zur Ausbreitung
gebrauchthat. Unter einer Annahme für die
Ausbreitungsgeschwindigkeit ist die zurückgelegteStrecke des
Signals berechenbar. Wenn die Entfernung zu mehreren bekannten
Punktenermittelt wurde, ist daraus die absolute Position durch das
Verfahren der Triangulationberechenbar [9]. Für eine hohe
Genauigkeit dieses Verfahrens sind präzise Zeitmessungennötig. Um
einen Fehler von weniger als 1m zu erzielen, dü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 fü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 mü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 Übertragungszeiten
proportional zu den Entfernungen sind [9, 11].
Auch wenn bei diesem Verfahren nun noch die Basisstationen
untereinander zeitsynchronarbeiten mü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 fü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
eingeführt, was im Englischen als
”Round Trip Time
of Flight“, kurz RTOF, bezeichnet wird. Dabei geht vom mobilen
Gerät ein Signal aus.Dieses wird dann am festen Empfänger wieder
zurückgesandt. So muss nun nur noch diemobile Einheit die Zeit
messen, bis das Signal wieder bei ihm angekommen ist. Aber auch
-
18 Kapitel 2 Positionsbestimmung in Funknetzen
diese Messung muss, wie bei der Messung der Ankunftszeit, sehr
genau erfolgen, denn eswird wieder über die
Ausbreitungsgeschwindigkeit der Abstand ermittelt und dann
mittelsTriangulation die tatsächliche Position. Ebenfalls geht die
unbekannte Zeit als Fehler ein,die der Empfänger benötigt, um das
Signal wieder zurü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 Größe für die
Positionsbestimmung. Durch mehre-re gerichtete Antennen an den
Basisstationen kö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
abhä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 Empfangsstärke
Bei der Messung der Empfangsstärke, im Englischen”Received
Signal Strength“, kurz RSS,
wird von der Tatsache Gebrauch gemacht, dass die Signalstärke
mit zunehmender Entfer-nung abnimmt. Ist die Sendeleistung bekannt,
so kann über die gemessene Empfangsleis-tung der Abstand berechnet
werden. Aus den Abständen zu verschiedenen, feststehendenSendern
kann die mobile Station dann wieder ihre Position bestimmen [9, 11,
12].
Dieses Verfahren ist grundsätzlich für die Verwendung mit
Smartphones und WLAN-Infrastruktur geeignet. Zu bedenken ist dabei
aber, dass Smartphones nicht primär fürdie Messung der
Empfangsstärke von WLAN-Signalen gebaut sind und dies deshalb
nurmit bedingter Genauigkeit möglich ist. Ebenso müssen nicht
alle Access-Points mit dervollen Leistung senden. Ist die
Sendeleistung aber unbekannt, dann ist kein
vernünftigerRückschluss auf die Entfernung mehr möglich. Von
Bahl et al. [12] wird gezeigt, dass so einSystem funktionieren
kann, aber mit einigen Einschränkungen der Genauigkeit zu
kämpfenhat. Im übernächsten Kapitel werden auch noch Messungen
vorgestellt, die die Proble-matik der unterschiedlichen
Empfangsstärken zwischen verschieden Smartphone-Modellenund
Abhängigkeiten der Signalstärke mit der Zeit aufzeigen.
-
2.3 Zusammenfassung 19
2.2.7 Fingerprinting
Mit Fingerprinting wird ein Verfahren bezeichnet, welches die
Schwächen der Entfernungs-bestimmung über die Signalstärke
überwinden soll. Dabei wird die Arbeit in zwei Teil-schritte
unterteilt. Im ersten Schritt wird eine Datenbank aufgebaut. Dazu
werden anbekannten Positionen die verfügbaren WLANs mit ihren
Daten ermittelt und gemeinsammit der Ortsinformation in der
Datenbank gespeichert. Diese Phase sollte sinnvollerweisevor dem
eigentlichen Betrieb des Systems durchgeführt werden. Diese
Datenbasis entschei-det später über die Leistungsfä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 Lösung
die Position mit der besten Übereinstimmung gewählt wer-den.
Komplexere Ansätze, wie Interpolation und ähnliches ist auch
möglich. Im Deutschenwird Fingerprinting oft mit
Signalstärkenmustererkennung bzw. mit Positionsbestimmungdurch
Signalstärkenmustervergleich ü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 Möglichkeit zur
Positionsbestimmung mitFunksignalen gibt, so scheiden die meisten
Aufgrund der Anforderungen an spezielleHardware aus, wenn nur die
bestehende Infrastruktur und handelsübliche Smartphonesverwendet
werden sollen. Die mit diesen Einschränkungen noch möglichen
Ansätze aufZellbasis, der Empfangsstärke und Fingerprinting
sollten aber dennoch ausreichen um einsolches System in Betrieb
nehmen zu können. Als Vorteil gegenüber anderen Verfahrenergibt
sich das mögliche Einsparungspotenzial, da bereits vorhandene
Infrastruktur undAusstattung verwendet werden kann. Dem gegenüber
steht der Nachteil, dass wederWLAN noch Smartphones für
Positionsbestimmung geplant oder konstruiert worden sind.Um mit
diesen Nachteilen dennoch vernünftige Ergebnisse zu erreichen,
muss bei derEntwicklung des Systems besonders auf Methoden geachtet
werden, welche die Nachteilekompensieren können.Als
vielversprechendster Ansatz gilt dabei Fingerprinting. Dies hängt
auch damitzusammen, dass hier die beiden anderen Verfahren, also
Zelllokalisierung und Si-gnalstärkenlokalisation, auch
integrierbar sind. Die Zelllokalisierung ist dabei immerinhärent
enthalten. Eine Zelle ist jedoch nun nicht mehr eine Funkzelle,
sondern einGebiet, in dem eine Referenzmessung gültig ist. Damit
sind die Zellgrößen abhängigvon der Anzahl der Messungen
skalierbar und die Genauigkeit des Verfahrens in einembestimmten
Bereich steuerbar. Die Lokalisierung auf Signalstärkenbasis kann
dazu
-
20 Kapitel 2 Positionsbestimmung in Funknetzen
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 fü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 über dieses System sind
in [9] dargeboten. Der große Vorteil dieses Systems bestehtdarin,
dass alle Funktionalitäten in den Geräten der Netzarchitektur
enthalten sind. Dieeinzelnen mobilen Geräte im Netz benötigen
keinerlei Änderungen an Hard- oder Software.Damit ergibt sich
allerdings auch die Möglichkeit, Benutzer und ihre Geräte ohne
derenWissen zu verfolgen. Vorteilhaft daran ist jedoch, dass nun
sämtliche Geräte, die über ei-ne WLAN-Anbindung verfügen,
lokalisiert werden können. Sogenannte WLAN-Tags, alsokleine WLAN
taugliche Sensoren, stehen hier besonders im Mittelpunkt. Diese
Sensorenkönnen auf bewegten Objekten angebracht werden und
übermitteln dann Sensordaten perWLAN. Ebenso kann nun über die
Positionsbestimmung der Weg der Objekte nachvollzo-gen werden.
Cisco bietet mit dem Produkt auch die Möglichkeit, spezielle
Informationendieser WLAN-Tags direkt über das Fingerprinting
System auszulesen. Als Beispiel wäreder Batteriestand zu nennen.
Dies funktioniert dann aber nur über eigene Nachrichten,welche das
WLAN-Tag unterstützen muss. Ein Nachteil ist natürlich, dass die
Funktiona-lität in den Komponenten der Netzarchitektur
implementiert ist. Deshalb müssen eigenenAccess-Points und
Netzwerkserver eingesetzt werden.Um die Positionsinformationen
messen zu können, werden die Access-Points herangezo-gen. Diese
werden über das Lightweight Access Point Protocol (LWAPP)
kontrolliert. Umeine Positionsbestimmung durchzuführen, muss das
Signal eines mobilen Teilnehmers vonmindestens drei Basisstationen
empfangen werden. Die Access-Points leiten die
nötigenInformationen (MAC-Adresse des Senders, MAC-Adresse des
Access-Points, Empfangs-schnittstelle und Signalstärke) an den
Wireless LAN Controller (WLC) weiter. WLCs die-
21
-
22 Kapitel 3 Bestehende Fingerprinting Systeme
nen eigentlich zur Koordination der Access-Points, übernehmen
hier aber auch eine Rollebei der Ortsbestimmung. Die WLCs
akquirieren Daten von den durch sie bedienten Basis-stationen.
Darüber in der Hierarchie folgt der wichtigste Teil des Systems,
das sogenannteWLAN Location Appliance. Darin werden alle Daten
gesammelt und die Positionen dereinzelnen Geräte berechnet. Das
WLAN Location Appliance kann die Information über dieermittelten
Aufenthaltsorte über verschiedene Schnittstellen (Emails, Syslog,
SOAP/XMLund SNMP TRAP) an andere Dienste weitergeben.Das WLAN
Location Appliance arbeitet zur Positionsbestimmung grundsätzlich
nach demFingerprinting Verfahren. Es muss also zuerst eine
Lernphase absolviert werden, bevor dasSystem vollständig
einsetzbar ist. Für eine bessere Genauigkeit bei der
Ortsbestimmungwird ein Verfahren angewandt, welches weit über
reines Fingerprinting hinausgeht. Ausden Daten der Lernphase wird
ein Modell der Signalstärke berechnet. Dieses Modell gibtfür
jeden WLAN-Kanal und über das ganze abgedeckte Gebiet eine
Verteilung der Emp-fangsstä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
durchgefü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 Geräte lokalisieren,
wobei auch mehrere WLAN Loca-tion Appliances kombiniert werden
können, um noch mehr mobile Stationen verfolgen zukö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 Leistungsfähigkeitdes Cisco RF
Fingerprinting Systems. Dabei wird aber eine Positionsbestimmung in
denStraßen von Trondheim durchgeführt. Das Fingerprinting System
war jedoch zum Zeit-punkt der Untersuchung nicht fü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 mäßige Genauigkeiten bei der
Trefferquote der Po-sition. So wurde für unbewegte mobile
Stationen ein maximaler Fehler von bis zu 90m, beibewegten bis zu
200m ermittelt. Bei bewegten Stationen ergibt sich aber das
Phä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 benötigt, sondern es können bestehende
WLAN-, GSM- und UMTS-Netzeverwendet werden. Ebenso sind für den
Betrieb keine eigenen Server notwendig, sondernes werden alle
Berechnungen direkt am Smartphone durchgeführt. Als großer Vorteil
desSystems ist zu werten, dass weder ein Server benötigt wird,
noch Änderungen an derInfrastruktur nötig sind. So wird die
Einführung des Systems einfach und kostengünstig.Als Genauigkeit
des Systems werden durchschnittlich 1 - 5m innerhalb, und 10m
außerhalbvon Gebäuden angegeben.Wie bei jedem Fingerprinting
System müssen auch hier zuerst Testdaten gesammeltwerden. Aus
diesen Daten wird dann eine Karte erstellt, welche die zu
erwartendenEmpfangsstärken im Gebäude wiedergibt. Diese Karte
wird mit der Positionsbestim-mungssoftware auf die einzelnen
Geräte verteilt. Jedes Smartphone kann dann vollkommenautark seine
Position bestimmen. Dieser Ansatz hat den Vorteil, dass die
sensiblen Positi-onsdaten nie das Gerät des Benutzers verlassen,
und ist somit aus datenschutztechnischenGründen sehr vorteilhaft.
Nachteilig wirkt sich natürlich aus, dass bei Änderungen in
denWLAN-Referenzdaten alle Smartphones auf den neuesten Stand
gebracht werden mü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
Museumsführer,der durch die Positionsinformation relevante
Hinweise bezüglich der ausgestellten Objekteliefert. Ein anderes
System ist MobileWALK. Es richtet sich besonders an Fußgänger
imstädtischen Bereich, sowohl innerhalb als auch außerhalb von
Gebäuden [17].
-
24
-
Kapitel 4
Signalstärkenmessung in WLANs
Dieser Abschnitt soll die tatsächlichen Bedingungen in aktiven
WLANs aufzeigen. Umdas durchführen zu können, wurde ein Programm
entwickelt, welches die aktuellen Si-gnalstä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 tatsächlichen Bedingungen in WLANs aufzeichnen zu
kö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 führt dann selbständig in einem einstellbaren
Intervall eine Messung allerverfügbaren WLANs durch, bis der
Benutzer die Aufzeichnung wieder stoppt. Alle ermit-telten
Messdaten werden in einer Datei gespeichert, so dass diese später
ausgewertet wer-den können. WLog zeichnet nur Daten auf, welche
über Androidschnittstellen verfügbarsind. Dazu wird über das
Android Application Programming Interface (API), also
dieProgrammierschnittstelle, auf diese Daten zugegriffen, wie durch
die Android Program-mierschnittstelle [18] beschrieben. Für jedes
Netzwerk sind folgende Daten verfü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 Empfangsstärke im Bereich von -1 bis -99dBm.
• Capabilities: Beschreibt die Verschlüsselungsmethode, die
genutzt wird.
Im Anschluss werden nun einige der ermittelten Daten
vorgestellt. Die Auswertung be-schränkt sich auf eine Diskussion
der Empfangsstärke. Ziel ist es zu zeigen, von welchenEinflüssen
die Empfangsstärke beeinflusst wird und wodurch sich damit
Probleme für Lo-kalisierung mit dem Fingerprinting-Verfahren
ergeben.
25
-
26 Kapitel 4 Signalstärkenmessung in WLANs
Die bei den Messungen verwendeten Geräte sind im Anhang B mir
ihren Seriennummernaufgelistet.
4.2 Nutzungsabhängigkeit
Mit dieser Messung soll die Abhängigkeit der Signalstärke von
der Kommunikationsakti-vität im entsprechenden WLAN gezeigt
werden. Bei der Durchfü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 wä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 Nachbarkanäle. Die Signalstä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 wä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 Signalstärke bei unterschiedlicher
Anzahl an Geräten imWLAN. Im Abschnitt mit geringen Schwankungen
(45 Minuten bis 2 Stun-den 10 Minuten) war das Smartphone der
einzige Teilnehmer im WLAN.
gnalstärke von der Anzahl der Nutzer im Netzwerk abhängt.
Optisch sind die Bereiche klarunterscheidbar. Es gibt aber auch
große Schwankungen, wenn das Smartphone alleine im
-
4.3 Zeitliche Abhängigkeiten 27
WLAN ist, wobei diese jedoch um einiges seltener sind. Weitere
Einflüsse wie die Personenim Raum, Verdeckungen durch
Gegenstände, usw. werden hier nicht behandelt. Einigesdavon wurde
von Kaemarungsi et al. [19] beschrieben. Für die
Positionsbestimmung stehenaber keine eigenen WLANs zur Verfügung,
sondern diese werden unterschiedlich stark fürnormale
Kommunikationszwecke genutzt. Deshalb muss das System mit den
dargestelltenSchwankungen umgehen können.
4.3 Zeitliche Abhängigkeiten
In Abbildung 4.2 ist eine Messung im Hörsaal Z999 am
Stammgelände der TU Münchengezeigt. Für die Messung wurde das
Smartphone (siehe Tabelle B.3 auf Seite 74) benutzt.Die Messung
wurde während einer Lehrveranstaltung durchgefü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 Abhängigkeit des Pegels über der
Zeit festzustellen. Die Schwan-kungen des Empfangspegels um ±10dBm
ist erkennbar. Die Schwankung über der Zeitist unerwünscht, da
diese die Abhängigkeit der Signalstärke vom Aufenthaltsort
verfälscht.Diese starken Schwankungen des Pegels müssen bei der
Auslegung eines Ortsbestimmungs-systems durch eventuelle
Korrekturen berücksichtigt werden.
-
28 Kapitel 4 Signalstärkenmessung in WLANs
4.4 Abhängigkeit von unterschiedlichen Gerä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 über eine
Stunde eine Messung der vorhandenen WLANs durchführen. In
dieserZeit wurde keines der beiden Geräte bewegt. In die
Auswertung wurden alle Netzwerkeaufgenommen, welche zumindest
einmal von einem der beiden Geräte ermittelt wurden.Die Messung
fand im Hörsaal 0999 am Stammgelände der TU München statt. Fü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
ausgewählt. Um eineReihung zu ermöglichen, sind die einzelnen
WLANs alphabetisch nach der MAC-Adressedes Access-Points sortiert.
Ist ein drahtloses Netzwerk nicht erkannt worden, so wurde
derStrafwert -120dBm für den Pegel vergeben. In Abbildung 4.3
erkennt man nun ein Muster,welches sich mit gewisser Ähnlichkeit
bei dem Diagramm beider Smartphones zu erkennengibt. Die gemessenen
Pegel für ein WLAN und einen Zeitpunkt können von Gerät zuGerät
unterschiedlich sein. Es ist hier sogar mehrmals der Extremfall
sichtbar, bei welchenein Netzwerk nur von einem Gerät erkannt wird
und vom zweiten Gerät nicht. Die imvorherigen Kapitel besprochene
Abhä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 Abhängigkeit von unterschiedlichen Geräten 29
kraft. Die teilweise großen Unterschiede in den Empfangsstärken
zwischen den verwendetenGeräten wird auch von Kaemarungsi [20]
beschrieben. Um dennoch mit einer möglichstgroßen Anzahl von
verschiedenen Geräten im System gute Ergebnisse zu erzielen, wird
vonVaupel et al. [21] eine Kalibrierung der einzelnen Teilnehmer
vorgeschlagen.
-
30
-
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, wä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 beschrä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 Änderungen daran sind fü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 funktionsfä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 Gebä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: Übersicht des Gesamtsystems zur
Positionsbestimmung. Die KomponentenSmartphone (Client), Server,
Datenquellen (TUM Roomfinder und MySQLDatenbank) und die
Datenflü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 gewünschten Daten enthalten, odersie ist
eine Fehlermeldung. Fehlererkennung und ggf. eine Korrektur für
die übertragenenNachrichten wird den Protokollen in den
Kommunikationsschichten darunter überlassenbzw. wird von diesen
erwartet. Client und Server kommunizieren über das Hyper
TextTransfer Protocoll (HTTP). Im HTTP gibt es mehrere Nachrichten
die übertragen werdenkö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 können Namen-Werte-Paare
als Parame-ter übertragen. Die POST-Nachrichten sind speziell
dafür gedacht und kö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 angehängt [22]. Auch
wenn dieBeschränkung der URL-Länge auf 256 Zeichen heute
praktisch nicht mehr existiert, so istein sehr langer URL aufgrund
von vielen Namen-Werte-Paaren doch nicht wü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
aufgeführt, werden diese Namen-Werte-Paare – egal ob in einer GET-
oder POST-Nachricht – genutzt, um Informationen vom Client zum
Server zu übertragen. Die Nach-richten des HTTP-Protokolls werden
mit dem Unicode Transformation Format 8 (UTF-8)repräsentiert. Das
Content Type Formate ist demnach text/plain;charset=UTF-8.Insgesamt
gibt es fü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 ü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
reinenBestätigung nach dem Speichern einer Position am Server
(siehe 5.1.2). Es ist auchmöglich, dass die Antwort des Servers
ein Bild einer Gebäudekarte ist. Diese wird direktin der Antwort
ü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 über fehlende
oder falsche Parameter in der Anfrage. Mit 404 wird gemeldet,dass
der angeforderte Inhalt nicht gefunden werden konnte. Über den
Code 500 wird derClient über einen internen Fehler bei der
Programmverarbeitung im Server informiert.
5.1.2 Nachrichten
Nachfolgend werden nun die einzelnen Nachrichten erläutert. Der
genaue Aufbau jederNachricht ist im Anhang A aufgelistet.
Rauminformationen in Kartennummer auflösen
Bei dieser Nachricht schickt der Client das Gebäude, Stockwerk
die Raumnummer undoptional auch den gewünschten Maßstab an den
Server. Der Server muss daraufhin diepassenden Karten suchen. Jede
Karte wird über eine eindeutige Nummer verwaltet. DerServer
antwortet mit der Kartennummer und den tatsächlichen Maßstab der
Karte odermit einer Fehlernummer. Das genaue Nachrichtenformat ist
in der Tabelle A.1 auf derSeite 67 angegeben.
-
34 Kapitel 5 Systemimplementierung
Kartenbild zur Kartennummer anfordern
Mit dieser Nachricht kann der Client das Bild einer Karte vom
Server anfordern. DasBild wird über die eindeutige Nummer der
Karte angesprochen. Bei einer erfolgreichenAnfrage wird das
entsprechende Bild direkt als Antwort übertragen; bei einem Fehler
wirddie Fehlernummer zurü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 verknüpft
und wie dieses ü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 vollständig, wird die Posi-tion am Server
gespeichert und dieser antwortet mit einer Bestätigung der
Speicherung.Diese Bestätigung ist kein Namen-Wert-Paar. Da es nur
eine positive Bestätigung gibt– eine negative wird durch
Fehlernummern übermittelt – reicht hier der
Parameternamevollkommen aus. Diese Nachricht ist damit eine
Ausnahme vom ü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 ü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
Über die Fehlernummern wird der Client ü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-gulä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
eingeführt, da die reine Nummer für den Menschen nicht sehr
aussa-gekräftig ist, wenn er nicht die Tabelle der Fehlernummern
zur Hand hat. Sie dient alsohauptsächlich als Hilfe für den
Entwickler.
5.1.4 Abhörsicherheit
Alle Nachrichten werden im Klartext übertragen und sind damit
für jeden lesbar. Umdennoch ein Maß an Vertraulichkeit zu
erhalten, wird die HTTP Kommunikation mit demTransport Layer
Security (TLS) Protokoll geschü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 ausgeführt. Der Client kommuniziert nunüber HTTPS mit
einem Apache Web Server. Dieser Apache Server ist lokal mit dem
ServletContainer verbunden und tauscht die Daten mit diesem über
HTTP aus. Somit ist derkritische Teil der Verbindung über den
offenen Teil des Netzwerkes mit HTTPS geschütztund die
unverschlüsselte Kommunikation findet nur in einem geschützten
lokalen Bereichstatt.
5.2 Server
5.2.1 Serverarchitektur
Die Abbildung 5.2 zeigt die einzelnen Softwareteile des Servers.
Der Server ist vollständigin Java programmiert. Das Servlet stellt
die Schnittstelle zum Kommunikationsprotokolldar. Es nimmt die
Anfragen entgegen und beantwortet diese. Um die Anfragen
beantwor-ten zu können, werden Daten von anderen Quellen
benötigt. Auf diese wird vom Servletaus ü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 darüber
liegenden Teilen Funktionen zur Verfügung. Er soll
einevollständige Loslösung von der Datenquelle ermöglichen. Der
Adapter bietet den höherenSchichten Methoden an, welche diese
verwenden. Diese Methoden bilden eine allgemeineSchnittstelle. So
muss die höhere Schicht nicht mehr wissen wie die Datenquelle
realisiertist. Alle fü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 darüber
merkt von
-
36 Kapitel 5 Systemimplementierung
dieser Änderung nichts. Ein Connector-Adapter-Paar existiert
fü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 Gebäudekarteaufgeteilt. Auf dem Datenbankserver
gibt es eine Datenbank für WLAN-Daten und eine für Kartendaten.
Die TUM Roomfinder API wird zumBezug der Kartenbilder genutzt.
die das Servlet zugreifen muss. Ü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 für den Zugriff auf die Datenbank
der Koordinatentransfor-mationsmatrizen bestimmt. Diese Matrizen
werden benötigt, um die Pixel-Koordinatender Karten in
Weltkoordinaten umzurechnen.
In den nachfolgenden Abschnitten wird nun eine Komponente nach
der anderen beschriebenund erklä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
ausgewählte Teile vorgestellt, die entweder besonders
-
5.2 Server 37
interessant sind oder eine gesonderte Erklärung benö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 – verknüpft mitdem Ort der Messung – aufnehmen kö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
Datensätze verweisen direkt oderindirekt darauf.
mit der entsprechenden Position gespeichert werden. Jede Tabelle
besitzt einen automa-tisch generierten Primärschlüssel. Dieser
ist mit dem Tabellennamen und der Präfix idbezeichnet. Die
Spaltennamen sind so gewählt, dass diese den Parameternamen des
Kom-munikationsprotokolls entsprechen. Die zentrale Tabelle ist mit
sample benannt und bilden
-
38 Kapitel 5 Systemimplementierung
den Einstiegspunkt in die Datensätze. In sample werden alle
Einträge eines Datensatzeszusammengefü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 über Re-lation mit der Haupttabelle sample
verknü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 gehö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 Empfangsstärke (level) und
dieverwendete Verschlüsselung (capabilities).Jede Messung an einer
gegebenen Position ist durch ein Gerät ausgeführt worden.
DieHard- (hardware) und Software (software) dieses Gerätes ist in
der Tabelle device ge-speichert. Jede Messung ist genau einem
Gerät zugeordnet, aber ein Gerät kann beliebigviele Messungen
durchführen.Die Tabelle user enthält die Benutzer des Systems.
Ein Benutzer kann beliebig viele Da-tensätze speichern, jedoch
gehö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 verknüpft.Die gespeicherten Koordinaten
stehen mit dem Raum im Gebäude (location) in Verbin-dung. Ein Raum
ist durch die Gebäudenummer (building), das Stockwerk (floor)
unddie Raumnummer (room) charakterisiert. Für jedem Raum im
Gebä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 Gebäudekarten
existieren, in Koordinatenim WGS 84 umzurechnen werden 3 ×
3-Matrizen benö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 Primärschlüssel;
idmatrix für die Tabelle matrix und idvalue fü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 für diese Kartennummer
gibt. Zu jeder Matrix gehören nun neun Zahlen,welche die Einträge
in der Matrix darstellen. Umgekehrt gehört jeder Eintrag zu
genau
-
5.2 Server 39
Abbildung 5.4: Zu sehen ist das einfache Schema der
Kartendatenbank mit lediglich zweiTabellen. Über die Einträge
matrix kann die Existenz einer Matrix inder Datenbank ermittelt
werden, während value die eigentlichen Datenenthält.
einer Matrix. Die Einträ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. Gültige Werte sind demnach für die3×3-Matrix:
11, 12, 13 für die erste Zeile, 21, 22, 23 für die zweite Zeile
und 31, 32, 33 fürdie dritte Zeile. Diese Art der Kodierung wurde
gewählt, da so später ein automatisiertesSortieren und Auslesen
der Werte möglich wird.
5.2.4 TUM Roomfinder API
Die TUM Roomfinder API [25] stellt eine Möglichkeit zur
Verfügung, um auf Architektur-daten der TU-Gebäude zuzugreifen.
Der Zugriff erfolgt ü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 über die Methoden wurde aus derTUM Roomfinder
Dokumentation [25] entnommen.
getRoomMaps( r id ) – Über diese Methode wird eine Liste aller
Karten für einen Raumangefordert. Der Raum wird über den String r
id bestimmt. Dieser String ist im For-mat Raumnummer@Gebäudenummer
anzugeben. So ist beispielsweise der Raum
”Z999“ im
Gebäude”9“ des Stammgeländes mit Z999@0509 zu bezeichnen,
wobei
”05“ das Stamm-
gelände und”09“ das Gebäude
”9“ bezeichnen. Wichtig ist hier, dass Buchstaben in den
Raumnummern immer als Großbuchstaben geschrieben werden
mü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
-
40 Kapitel 5 Systemimplementierung
die Breite und Hö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 verknü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 müssen dieUmsetzung der
Daten zwischen der Repräsentation, welche für die Daten in der
Daten-quelle gewählt ist, und jener, die in Java verwendet wird,
durchführen.Im folgenden Teil sind die Aufgaben der einzelnen
Connectors kurz aufgeführt. Wichtigebzw. komplexe Funktionen darin
werden beispielhaft erklärt; fü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 auszuführen
undliefert das Ergebnis dieser Befehle schon als Daten,
repräsentiert durch entsprechende Java-Datentypen. Dadurch wird
die Kommunikation mit der Datenbank erheblich vereinfacht.Es bleibt
für den DbConnector als Hauptaufgabe nur die Daten per SQL-Befehl
zu lesenbzw. zu speichern. Ausgewählte Beispiele von diesen
SQL-Befehlen aus diesem Bereichwerden hier nun vorgestellt.
Verknüpfen der Tabellen – Bei dem Betrachten des Datenmodells
in Abbildung 5.3wird klar, dass viele Abfragen Daten aus mehreren
Tabelle beziehen. Durch die gewähltenKardinalitä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
Primär- oder Fremdschlüssel.
Suchen von passenden Fingerprints – Eine problematische
Fragestellung war zu Be-ginn, wie schnell die richtigen
Fingerprints gefunden werden kö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 übereinstimmen,
-
5.2 Server 41
desto größer ist die Relevanz des Fingerprints. Es ist jedoch
auch möglich, dass selbst Mes-sungen, die am selben Ort
durchgefü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 aufgeführten BSSIDs ist. Nun
wird für jedes dieser Netz-werke noch der Primärschlüssel der
Messung angeführt, zu welcher diese BSSID gehören.Durch zählen,
wie oft der Primärschlüssel eines Fingerprints nun vorkommt, ist
die Anzahlder ü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. Dafü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 zurück, die angibt, an welcher Stelle in der
Liste die Referenz gefunden wurde. Wurdedie Referenz nicht
gefunden, so wird eine Null zurückgegeben. Hat die Vergleichsliste
alsonur einen Eintrag, bekommen wir eine Null oder eine Eins als
Ergebnis. Wird jetzt aufBasis dieses Ergebnisses sortiert, so
können wird jene Resultate bevorzugen, welche denReferenzstring
enthalten haben.
Mehrfachzuordnungen – Die Vorgehensweise bei diesem Problem soll
anhand eines Bei-spiels verdeutlicht werden, gilt aber für alle
Orte des Auftretens sinngemäß. Als Beispielwird die Zuordnung des
Benutzernamens zum Fingerprint gewählt. Ein Benutzer kannbeliebig
viele Fingerprints in der Datenbank speichern. Es ist aber nicht
notwendig, jedesMal dabei den Benutzernamen neu zu speichern; es
wird über den Primärschlüssel immerwieder auf den gleichen Namen
verwiesen. Aus diesem Grund muss der Primärschlüsseldes
verwendeten Benutzernamens bekannt sein. Dieser wird aber nicht
außerhalb der Da-tenbank gespeichert. So muss der Primärschlü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 verknü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 Einträ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 lä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 über den
MySQL Connector/J zum MySQL Ser-
-
42 Kapitel 5 Systemimplementierung
ver aus.
MapConnector
Der MapConnector verwendet die Apache XML-RPC Bibliothek [27] um
auf die Methodender TUM Roomfinder API zuzugreifen. Fü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
überArrays vom Typ Object. Dies gilt auch dann, wenn nur ein
Parameter übertragenwird; dann hat das Array auch nur einen
Eintrag. Im Fall der Antwort der MethodegetRoomMaps( r id ) (siehe
Seite 40) wird fü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 zurü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
unterstü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 Verfügung, ü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 möglich.
DbAdapter
Der DbAdapter bietet dem Servlet zwei Methoden an und benutzt
zur Ausführung die-ser die vom DbConnector bereitgestellten
Methoden. Zum Einen kö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 Ü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 Übereinstimmung zu finden, wird der euklidische
Abstand der Messungenberechnet. Dazu wird die gemessene
Signalstärke der Basisstationen als Abstandsmaß ver-wendet. Ist
ein WLAN nicht vorhanden, wird fü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 Schätzwert der richtigen Positionverwendet.
MapDbAdapter
Die Klasse MapDbAdapter hat die Aufgabe, die
technologiespezifischen Excpetions zu ver-bergen und in neutrale
umzusetzen. Diese Eingeschränktheit kommt daher, dass die
Klassenur die Koordinatentransformationsmatrix einliest und auch
diese Funktion nicht direktdem Servlet, sondern dem MapAdapter zur
Verfü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 für den gewünschten Raum wird hier die Karte mit
dem Maßstab gesucht, der demgewünschten am nächsten kommt.
5.2.7 Servlet
Das Servlet ist die zentrale Stelle in der Hierarchie des
Servers. Es startet die Ausführungaller anderen Programmteile. Der
Tomcat Servlet Container [29] dient zur Ausfü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 können, muss dasServlet auf
die von den Adaptern angebotenen Methoden zurückgreifen.Die
Anfragen an das Servlet werden über HTTP POST- und GET Methoden
gestellt (sie-he Kapitel 5.1). Fü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 Mö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 können
nurZeichenketten übertragen werden, welche an dieser Stelle wieder
in Java Datentypen (int,
-
44 Kapitel 5 Systemimplementierung
double, etc.) gewandelt werden. Die auf diese Art eingelesenen
Werte werden nun an dieentsprechende Adaptermethode übergeben.
Diese generiert entweder aus ihrer Datenquelleeine entsprechende
Antwort, oder – wenn dies nicht möglich ist – wird ein Fehler oder
dasFehlen einer Information über eine passende Exception gemeldet.
Das Servlet muss nundie durch den Adapter gelieferte Information an
den Client zurückschicken. Sollte eineException aufgetreten sein,
so wird diese in die entsprechende Fehlernummer ü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 gelöst wird. Das Kapitel ist in drei Teile
gegliedert. Im ersten Teil werden dieeinzelnen Komponenten des
Android Programms vorgestellt. Der zweite Teil beschäftigtsich mit
dem Zusammenspiel dieser Klassen und der dritte Teil wirft einen
Blick auf dieBenutzeroberflä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. Fü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 wären dies Klassen vom Typ Activity. Dabei handelt es
sich um Klassen, diegrafische Oberflächen fü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 für die Erfüllung ihrer
Funktionen.
MapActivity
Dies ist die Hauptklasse des Programms und stellt auch den
Hauptbildschirm dar. Hierlaufen alle Informationen zusammen und
werden entsprechend dargestellt. Für die Dar-stellung der
Gebäudekarte wird auf die Komponente MapView zurü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
Benutzeroberfläche zu sehen. Als einerdieser Teile der Oberfläche
sei noch das Optionsmenü erwähnt, über das die vom
Benutzergewünschten Aktionen gestartet werden können.
MapView
MapView zeigt das Bild der Karte und bietet eine Zoom-Funktion
für diese. Der Benutzererhält durch diese Klasse auch die
Mö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
übergeben. Auf diese Art könnenalle Positionsangaben in WGS 84
Koordinaten an MapView geliefert werden und müssennur innerhalb
von MapView in Pixelkoordinaten gehalten werden.
ServerConnectionService
Über das Service kann die MapActivity Anfragen an den Server
schicken. Das Servicefü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 Rückmeldung vom Server existiert, oder
dieser nichtgeantwortet hat, wird die MapActivity vom Service
wieder verständigt.Die praktische Umsetzung dieser einfachen
Ü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, damitspäter die Activity eine Verbindung zum
Service herstellen kann. Um die Kommuni-kation tatsächlich
auszuführen, wird vom ServerConnectionService auf die
KlasseHttpConnector zurückgegriffen. In diese Klasse sind die
eigentlichen HTTP Anfragenausgelagert.
WifiScanManager
Mit Hilfe des WifiScanManagers kann auf die
Android-Systemfunktionen für die Steue-rung der WLAN-Schnittstelle
zugriffen werden. In diesem Zusammenhang werden davonnur wenige
Funktionen benötigt. Es kann überprüft werden, ob das WLAN-Modul
amSma