thesis - LMU München

INSTITUT FÜR INFORMATIK
DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN
Diplomarbeit
Konzeption und Implementierung
einer Location-based Push-Architektur
für mobile Navigationsdienste
Matthias Röckl
Aufgabensteller: Prof. Dr. Claudia Linnhoff-Popien
Betreuer:
Dr. Axel Küpper
Georg Treu
Christian Birle
Abgabetermin: 20. Juni 2005
2
INSTITUT FÜR INFORMATIK
DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN
Diplomarbeit
Konzeption und Implementierung
einer Location-based Push-Architektur
für mobile Navigationsdienste
Matthias Röckl
Aufgabensteller: Prof. Dr. Claudia Linnhoff-Popien
Betreuer:
Dr. Axel Küpper
Georg Treu
Christian Birle
Abgabetermin: 20. Juni 2005
Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
München, den 20. Juni 2005
..........................................
(Unterschrift des Kandidaten)
Zusammenfassung
Auf dem Weg zur 3. Mobilfunkgeneration treten neben Sprachdiensten auch immer mehr Datendienste in
den Vordergrund. Sie unterstützen den Menschen in vielen speziellen, aber auch alltäglichen Aufgaben.
Eine dieser alltäglichen Aufgaben des Menschen, mit der er tagtäglich konfrontiert wird, ist die Navigation. Ihre Historie reicht weit in die menschliche Geschichte zurück. Die moderne Informationstechnik
kann heutzutage tatkräftige Unterstützung für die Navigation bieten. Als Schlagwort ist an dieser Stelle der Location-based Service zu nennen, mit dessen Hilfe Ortsinformationen des Nutzers in den Dienst
einfließen. Dies ermöglicht die Realisierung mobiler Navigationsdienste.
Ziel dieser Arbeit ist die Konzeption und Implementierung eines mobilen Navigationsdienstes für
Mountain-Bike-Touren. Mountain-Bike-Navigationsdienste unterscheiden sich durch einige Besonderheiten von Fahrzeug- oder Fußgängernavigationsdiensten und stellen deshalb eine interessante Herausforderung dar. Besonderer Fokus wird dabei auf die zugrunde liegende Architektur dieses Dienstes gelegt.
Ein wichtiger Aspekt ist die Bereitstellung von Navigationsinformationen ohne explizite Anforderung des
Nutzers, was zu Location-based Push-Services führt. Zur Umsetzung dieser Art mobiler Dienste wird in
der Architektur auf unterschiedliche Verteilungen der Architektur eingegangen und eine Analyse der Vorund Nachteile durchgeführt. Resultat des Entwicklungsprozesses ist eine Architektur, die sich durch hohe
Dynamik, große Flexibilität und breite Anwendbarkeit auszeichnet.
Um die Funktionsfähigkeit des Navigationsdienstes und der zugrunde liegenden Architektur zu belegen,
wurde im Rahmen dieser Arbeit ein Prototyp dieses Dienstes implementiert und getestet. Die erzielten
Ergebnisse zeigen, dass diese Art von Diensten möglich sind und durch die entwickelte Architektur sehr
komfortabel umgesetzt werden können. Unter anderem legt diese Arbeit also einen Grundstein für weitere Location-based Push-Services, die womöglich die zukünftige Entwicklung der lang ersehnten Killer
”
Applikation“ vorantreiben werden.
2
Inhaltsverzeichnis
Inhaltsverzeichnis
i
Abbildungsverzeichnis
iv
Tabellenverzeichnis
vi
1
Motivation
1
1.1
Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Mobile Navigationsdienste
4
2.1
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Navigationshistorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
Menschliche Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.3
Navigationsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Mobile Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
Location-based Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.3
Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.4
Routendienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
Demonstrator: MoBiLe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.1
Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.2
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.2
2.3
3 Stand der Technik mobiler Navigationsdienste
3.1
24
Ortungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.1
Cell Of Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.2
Enhanced Observed Time Difference . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.3
Global Positioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
i
3.2
3.3
3.4
4
Weitere Ortungsverfahren und Klassifikationen . . . . . . . . . . . . . . . . . . .
29
3.1.5
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Mobile Programmierplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.1
Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.2
J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.2.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Unterstützung für verteilte Push-Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3.1
Push-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3.2
Location-based Push-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Bestehende Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.4.1
Forschungsprojekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.4.2
Kommerzielle Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Architektur
46
4.1
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.1.1
Generelle Architekturkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.1.2
Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.1.3
Schichtenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.1.4
Middleware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2.1
Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2.2
Initiierungsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.2.3
Dienstausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.2.4
Präsentationsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2.5
Dienstpräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3.1
Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.3.2
Verteilungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.3.3
Auswirkung auf mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . .
64
4.2
4.3
5
3.1.4
Implementierung
67
5.1
Ortungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.2
Endgeräteplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.3
Weiterer Hard- und Softwareeinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4
Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4.1
Inter-LBPS-Schichtenkommunikation . . . . . . . . . . . . . . . . . . . . . . . .
72
5.4.2
Plattformunabhängigkeit der Schichten . . . . . . . . . . . . . . . . . . . . . . .
74
5.5
5.6
6
75
5.5.1
Ortsinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.5.2
Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5.3
Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.5.4
Initiierungsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.5.5
Navigationsdienst MoBiLe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.5.6
Präsentationsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.5.7
Dienstpräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
Konfigurationskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Evaluierung
86
6.1
Evaluierung der Implementierung und Technologie . . . . . . . . . . . . . . . . . . . . .
86
6.1.1
Probleme von GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
6.1.2
Inhärente Probleme von J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.1.3
Probleme mobiler Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
6.1.4
Probleme beim Routeneinstieg . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
6.1.5
Probleme mit Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.1.6
Probleme beim Verlassen der Route . . . . . . . . . . . . . . . . . . . . . . . . .
89
Versuchsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
6.2
7
Umsetzung der LBPS-Schichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schlussfolgerung und Ausblick
A Routendienst
93
97
A.1 Digitale geografische Datenbestände . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
A.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
A.2.1 OpenMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
A.2.2 Routenerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.2.3 Routenbereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.3.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.3.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.3.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.4 RouteServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.4 Evaluierung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Literaturverzeichnis
107
Abbildungsverzeichnis
2.1
Pull- und Push-Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
Beispiele für Push/Pull-Services mit/ohne Ortsabhängigkeit . . . . . . . . . . . . . . . . .
13
2.3
Pfadnetzwerk und Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4
Rollen im Bereich der LBSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1
Ortung mittels Cell Identity (a) mit Laufzeitmessung (b) mit AoA (c) mit Laufzeitmessung
und AoA (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Enhanced Observed Time Difference (E-OTD) . . . . . . . . . . . . . . . . . . . . . . .
26
3.3
Aufbau des GPS-Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4
Mobile Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.5
Überblick über die Java 2 Editionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.6
Mobile Plattform für Grafikdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.7
Garmin eTrex und Magellan SporTrak . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1
Klassifikation anhand Kohärenzkriterium . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.2
Schichtenaufbau der LBPS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.3
Middleware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4
LBPS-Architektur mit mehreren Applikationen . . . . . . . . . . . . . . . . . . . . . . .
50
4.5
Aktionskreis um Aktionspunkt mit Aktionsradius r . . . . . . . . . . . . . . . . . . . . .
53
4.6
Genordeter Kartenausschnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.7
Gegenüberstellung lokaler und entfernter Dienstausführung bei Connectivity und (Pre-)Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.8
Netzlast der Luftschnittstelle bei lokaler oder verteilter Dienstausführung . . . . . . . . .
65
5.1
Fortuna Clip-On Bluetooth GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5.2
Nokia 6630 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.3
Verteilungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.4
Dynamic Connection Framework (DCF) . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.5
Vereinfachtes Klassendiagramm des DCF . . . . . . . . . . . . . . . . . . . . . . . . . .
74
iv
5.6
Überblick über Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.7
Klassendiagramm der eingesetzten Ortsinformationen . . . . . . . . . . . . . . . . . . . .
77
5.8
Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.9
Ellipsoidischer Abstand der Punkte P1 und P2 . . . . . . . . . . . . . . . . . . . . . . . .
81
5.10 Abstand der Punkte P1 und P2 auf dem Längenkreis . . . . . . . . . . . . . . . . . . . .
82
5.11 Abstand der Punkte P1 und P2 auf dem Breitenkreis . . . . . . . . . . . . . . . . . . . .
83
5.12 Beispiele der Konfigurationsoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.13 Konfigurationskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.14 Zustandsdiagramm der Konfigurationsoberfläche . . . . . . . . . . . . . . . . . . . . . .
85
6.1
Mountain-Bike-Tour am Taubenberg . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
7.1
Stark vereinfachter Aufbau des UMTS-Netzes (Release 5) . . . . . . . . . . . . . . . . .
94
A.1 Model-View-Controller (MVC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.2 MVC-Architektur des Routendienstes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.3 Screenshot der grafischen Oberfläche des Routendienstes . . . . . . . . . . . . . . . . . . 103
A.4 Spezifikation der Austrittsrichtung aus Aktionspunkt . . . . . . . . . . . . . . . . . . . . 104
Tabellenverzeichnis
3.1
Kommerzielle mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2
Eigenschaften kommerzieller mobiler Navigationsdienste . . . . . . . . . . . . . . . . . .
45
4.1
Darstellungsformen in allozentrischer/egozentrischer Perspektive . . . . . . . . . . . . . .
59
vi
Kapitel 1
Motivation
1.1 Problembeschreibung
Die Ära des Mobile Distributed Computing“ [SAW 94, Schi 95, BuTu , TavS 03] zeichnet sich durch ei”
ne wachsende Anzahl mobiler, vernetzter Endgeräte aus. Diese Endgeräte können aufgrund der Mobilität
überall mitgeführt werden und sind überall nutzbar. Daten können über Ad-hoc- oder Infrastrukturnetze,
die auf verschiedensten Technologien basieren können, drahtlos ausgetauscht werden und sind dadurch an
vielen Orten einsetzbar.
Beispiele mobiler Endgeräte sind Mobiltelefone. Ursprünglich war ihre Aufgabe, Sprachdaten zwischen
unterschiedlichen Geräten (wahlweise mobil oder stationär) zu übertragen. Auf dem Weg zur dritten Mobilfunkgeneration tritt neben der Nutzung von Sprachdiensten auch die Nutzung von Datendiensten in
Erscheinung. Viele Mobiltelefone wurden deshalb bereits in ihrer Funktionalität stark erweitert, um die
Voraussetzung für diese Dienste zu ermöglichen.
So boten erste Mobiltelefone oft nur ein kleines, segmentbasiertes, einfarbiges Display zur Darstellung
von alphanumerischen Zeichen und geringe Rechenleistung sowie wenig Speicher. Für die reine Nutzung
von Sprachdiensten waren diese Endgeräte vollkommen ausreichend, doch leider auf derartige Dienste
beschränkt. Moderne Mobiltelefone der heutigen Zeit verfügen hingegen oft über größere, grafische, mehrfarbige Displays, die aufwändige Darstellungen zulassen. Ermöglicht wird dies außerdem durch relativ
leistungsstarke Prozessoren und verhältnismäßig großen Speicher. Desweiteren bieten sie Zugang zu drahtlosen Metropolitan Area Networks (MANs) wie es zum Beispiel durch das Universal Mobile Telecommunications System (UMTS) betrieben wird. Zusätzlich ermöglichen offene Plattformen die dynamische Integration von Softwarekomponenten von Drittanbietern. Dadurch können verschiedenste Dienste auf dem
mobilen Endgerät angeboten werden, die durch die Vernetzung eine Vielzahl an Informationen bei der
Ausführung heranziehen können. Mittels dieser Dienste ist es möglich, den Menschen in den unterschiedlichsten Lebenslagen zu unterstützen. Anwendungsgebiete sind zum Beispiel die Verwaltung von Terminen
oder das Versenden und Empfangen von Nachrichten. Aber auch die Umsetzung komplexerer Dienste wie
zum Beispiel Navigationsdienste werden möglich.
Navigationsdienste unterstützen den Menschen bei der Wegfindung. Dabei werden vor allem zwei Verfahren der Dienstnutzung unterschieden. Diese sind die gewöhnliche Pull-Interaktion, bei der der Nutzer
den Dienst aktiv anstößt, und die Push-Interaktion (vgl. [3gp d, FrZd 96, Pars 04]). Dabei wird der Dienst
automatisch angestoßen, wenn ein Zustand erreicht wird, der das Zustellen von Navigationsinformationen
nötig macht. Dieser Zustand kann zum Beispiel an einer Straßenkreuzung eintreten, falls der Nutzer einer
totalen oder partiellen Ortsunkenntnis unterliegt.
Durch das automatische Bereitstellen dieser Navigationsinformationen durch Navigationsdienste auf mobilen Endgeräten wird eine effiziente und vor allem effektive Bewegung des Menschen erleichtert. Ein
Mitführen von Routenbeschreibungen, wie beispielsweise Landkarten, und eine Abbildung der daraus gewonnenen Informationen auf die Realität ist dabei überflüssig. Mobile Navigationsdienste treten bereits in
1
2
KAPITEL 1. MOTIVATION
einigen Bereichen vermehrt in Erscheinung. Besonders ist hier die Kraftfahrzeugnavigation zu nennen, die
in den letzten Jahren stark an Attraktivität gewonnen hat. Ein anderer Bereich, der bisher wenig Aufmerksamkeit erlangt hat, ist die Navigation von Fahrradfahrern.
Entsprechende Routen verlaufen häufig in Regionen, die dem Fahrradfahrer wenig oder gar nicht bekannt
sind. Bisher galt das Mitführen von physischen Routenbeschreibungen, meist in Form von Landkarten, als
die einzige Möglichkeit, um sich zurecht zu finden. Mobile Navigationsdienste, die speziell auf dieses Anwendungsgebiet zugeschnitten sind, können den Nutzer in hohem Maße bei der Wegfindung unterstützen
und bieten ihm daher einen interessanten Mehrwert. Durch die Push-Interaktion wird kein Eingriff des
Nutzers mehr benötigt, um den Dienst anzustoßen. Eine automatische Bereitstellung der Navigationsinformationen trägt wesentlich zur effizienten Bewegung bei, da der Nutzer von der Entscheidungskompetenz
über die Relevanz von Initiierungszuständen entlastet wird. Dies ist vor allem bei der Fahrradnavigation
von Interesse, da hier eine Vielzahl an Zuständen, die eine Navigation nötig machen, auftreten können.
Desweiteren ist bei der Fahrradnavigation der bereits hohe kognitive Aufwand für die Fortbewegung in
Betracht zu ziehen. Dieser muss adäquat durch den mobilen Navigationsdienst umgesetzt werden.
1.2 Aufgabenstellung
Ziel dieser Arbeit ist es, einen mobilen Navigationsdienst für Fahrradfahrer zu entwickeln. Im Speziellen
sollen Mountain-Biker betrachtet werden, da diese sich durch einige Besonderheiten, wie stark fluktuierende Geschwindigkeiten, von normalen Fahrradfahrern differenzieren. Dadurch müssen neben den Problemen der herkömmlichen Fahrradnavigation auch die Besonderheiten im Bereich des Mountain-Bike-Sports
betrachtet werden. Besonders von Interesse ist in dieser Arbeit die Architektur, die dem Navigationsdienst
zugrunde liegt. Aufgrund der Push-Interaktion und des Bezugs auf Ortsinformationen des Dienstnutzers
wird diese im Folgenden mit dem Begriff Location-based Push-Architektur bezeichnet. Um die Anwendbarkeit dieser Architektur zu demonstrieren, soll ein Prototyp des Mountain-Bike-Navigationsdienstes erstellt und unter realen Bedingungen getestet werden.
1.3 Aufbau der Arbeit
Diese Arbeit gliedert sich in sieben Kapitel und einen Anhang. Das erste Kapitel liefert eine Motivation für
diese Arbeit und eine kurze Zusammenfassung des Inhaltes.
In Kapitel 2 wird detaillierter auf die Navigation eingegangen. Zu Beginn wird eine kurze Einführung in
die Kunst der Navigation gegeben und anhand der Geschichte der Navigation deren Ursprung aufgezeigt.
Neben der Beschreibung des menschlichen Navigationsprozesses werden wesentliche Probleme bei der
Navigation für den Menschen angesprochen. Die moderne Informationstechnik kann einen entscheidenden
Beitrag zur Lösung dieses Problems liefern. Im Folgenden wird deshalb auf mobile Navigationsdienste eingegangen. Diese werden der Obermenge der Location-based Services, im Speziellen den Location-based
Push-Services, zugeordnet. Anschließend erfolgt eine detaillierte Analyse der mobilen Navigationsdienste.
Hier stehen vor allem die Route als essentieller Bestandteil der Wegfindung und deren Operationalisierung
in dieser Arbeit im Vordergrund. In diesem Zusammenhang ergibt sich die Notwendigkeit von Routendiensten, die darauf folgend kurz beschrieben werden. Schließlich endet dieses Kapitel mit der Anforderungsanalyse des speziellen Navigationsdienstes für Mountain-Biker. Dessen Konzeption und Implementierung
wird in den nachfolgenden Kapiteln erörtert. Hier steht vor allem die Architektur, die diesem Dienst zugrunde liegt, im Vordergrund, da sie der wesentlichen Zielsetzung dieser Arbeit entspricht und die entscheidende Innovation liefert.
Um den derzeitigen Stand der Technik und Forschung in Bezug auf Konzeption und Implementierung des
Navigationsdienstes in Betracht zu ziehen, erfolgt in Kapitel 3 eine Übersicht über Technologien, Forschungsprojekte und bestehende Dienste, die sich in diesem Zusammenhang durch hohe Relevanz auszeichnen. Das Kapitel beginnt mit einigen ausgewählten Ortungsverfahren und deren Umsetzung in vorhandenen Systemen. Nachfolgend wird auf einige mobile Programmierplattformen eingegangen, mit deren
1.3. AUFBAU DER ARBEIT
3
Hilfe eine Implementierung des Navigationsdienstes ermöglicht wird. Dabei liegt der Fokus auf J2ME als
modular aufgebaute, moderne, objektorientierte Laufzeitumgebung mit verschiedenen Erweiterungen, die
die Arbeit auf dem mobilen Endgerät wesentlich erleichtern. Desweiteren beschreibt dieses Kapitel einige
ausgewählte Forschungsprojekte, die ähnliche Dienste und Probleme behandeln und bei der Konzeption des Navigationsdienstes maßgeblich beteiligt waren. Das Kapitel endet mit einer Analyse bestehender
kommerzieller Navigationsdienste aus verschiedenen Bereichen.
Den Schwerpunkt dieser Arbeit stellt Kapitel 4 dar. Darin wird die Architektur des Navigationsdienstes
sukzessiv erarbeitet. Vor allem der modulare Aufbau der Location-based Push-Architektur steht hier im
Vordergrund. Der erste Teil dieses Kapitels ist deshalb einer möglichst detaillierten Analyse und Beschreibung der einzelnen Module gewidmet. Um sich nicht bereits im Vorhinein einzelnen zugrunde liegenden
Technologien zu unterwerfen, erfolgt die Architekturkonzeption unabhängig von diesen Technologien. Die
für die Realisierung eingesetzten Technologien kommen erst bei der Implementierung zum tragen und werden deshalb erst dort konkretisiert. Der zweite Teil dieses Kapitels behandelt die Verteilung der einzelnen
Module auf Entitäten eines möglichst allgemeingültigen mobilen Systems. An der Wahl der optimalen Verteilung sind einige Einflussgrößen maßgeblich beteiligt. Diese werden dort genauer untersucht und die Vorund Nachteile einzelner Verteilungsalternativen betrachtet.
Die gewonnen Resultate der Architekturkonzeption und Verteilungsanalyse stellen die Basis der in Kapitel
5 beschriebenen Implementierung des Mountain-Bike-Navigationsdienstes dar. Dieses Kapitel beginnt mit
der Wahl der eingesetzten Technologien für Ortung, Programmierung und dazu nötigen Hardwarekomponenten. Danach erfolgt ein kurzer Einblick in einige Implementierungsdetails des Dienstes, die sich durch
hohe Relevanz bzw. entscheidende Lösungsansätze auszeichnen. Im Besonderen ist hier wieder die Implementierung der Location-based Push-Architektur anzuführen. Hierfür strukturiert sich dieser Abschnitt
durch die bereits angeführten Module der Architektur. Einige Diagramme veranschaulichen hierbei die
komplexen Zusammenhänge.
Eine Evaluierung der Implementierung schließt sich in Kapitel 6 an. Dabei wird auf Probleme bei der
Implementierung und ersten Testversuchen des Prototyps eingegangen. Soweit möglich, werden Lösungsvorschläge für die erkannten Probleme angegeben. Einige anfängliche Probleme des Prototyp wurden im
Laufe dieser Arbeit gelöst und in einer zweiten Testreihe nochmals evaluiert. Dieses Kapitel liefert dadurch
wichtige Erkenntnisgewinne für die Umsetzung mobiler Navigationsdienste.
Eine Zusammenfassung der Resultate dieser Arbeit erfolgt in Kapitel 7. Abschließend wird ein Ausblick
für Erweiterungen des Navigationsdienstes und vor allem der Location-based Push-Architektur gegeben.
Zur vollen Funktionsfähigkeit des Navigationsdienstes ist desweiteren ein Routendienst, der die Bereitstellung, Verwaltung und Generierung von Routen handhabt, nötig. Dieser wird im Anhang A beschrieben.
Der Routendienst wurde nicht in den Hauptteil der Arbeit integriert, da er keine obligatorische Position in
der Location-based Push-Architektur einnimmt und nur als Erweiterung des Navigationsdienstes für die
komfortable Handhabung der Routen dient. In diesem Sinne stellt der Routendienst eine externe Komponente der Location-based Push-Architektur dar und wird deshalb erst im Anhang beschrieben. Der Anhang
ist in ähnlicher Art und Weise aufgebaut wie der Hauptteil der Arbeit. Dementsprechend beginnt er mit
einer Gegenüberstellung verschiedener digitaler Datenbestände für Pfadinformationen, die einen Basisbestandteil der Routenerzeugung einnehmen. Im Folgenden wird die Architektur des Routendienstes und der
zugrunde liegenden Software beschrieben und anhand einiger Aspekte der Implementierung die Umsetzung erläutert. Einige Screenshots zeigen hierbei die grafische Benutzerschnittstelle der Routenerstellung.
Schließlich endet der Anhang mit einer Evaluation des Routendienstes und einem kurzen Ausblick.
Kapitel 2
Mobile Navigationsdienste
2.1 Navigation
Der Begriff der Navigation ist im Allgemeinen jedem Menschen bekannt, doch was sich genau dahinter
verbirgt, wird oft nur oberflächlich erkannt. Obwohl jeder Mensch tagtäglich die Navigation nutzt, um von
Ort A zu Ort B zu gelangen, fällt es auf den ersten Blick schwer, die Navigation zu beschreiben oder sie
zu erklären. Das erste Kapitel dieser Arbeit soll daher einen Einblick in die Kunst der Navigation bieten.
Dazu ist der Anfang dieses Kapitels der Geschichte und dem allgemeinen Orientierungsproblem, das die
Navigation nötig macht, gewidmet. Darauf folgend wird erläutert, inwiefern mobile Dienste die Navigation
für den Menschen erleichtern können, und eine Beispielanwendung beschrieben, die den Einsatz und die
Realisierbarkeit derartiger mobiler Navigationsdienste zeigen wird.
2.1.1
Navigationshistorie
Erste Erscheinungen des Navigationsbegriffs traten bereits weit vor Christi Geburt auf. Hauptzweck war
zu dieser Zeit die Orientierung zu Wasser (vgl. [Logs 92, wik ]. Auch der Begriff der Navigation ist in diesem Zusammenhang entstanden. Das Wort Navigation“ hat seinem Ursprung in der lateinischen Sprache
”
und setzt sich aus den beiden Wörtern navis“ (Schiff) und agere“ (führen) zusammen. Unter Navigation
”
”
verstand man demnach alles, was dazu nötig war, ein Schiff zu führen. Dazu zählte das richtige Setzen der
Segel, das Umschiffen von Hindernissen und natürlich das zielgerichtete Fortbewegen auf See zur Erreichung des Zielhafens.
Anfänglich orientierten sich die Seefahrer dazu an markanten Punkten an Land, den so genannten Landmarken, die sie vom Wasser aus erkennen konnten. Um sich auch auf offener See orientieren zu können, setzten
sie später ein anderes Verfahren zur Positionsbestimmung ein. Dazu gingen sie von ihrem Heimathafen
aus und bestimmten aus Bewegungsrichtung (z.B. ermittelt anhand von Himmelskörpern), Geschwindigkeit (z.B. ermittelt mit Hilfe eines Logs) und Zeitdauer ihre gegisste Position. Man nennt diese Art der
Navigation, deren Ortung auf dem Ausgangsort, der Bewegungsrichtung und der zurückgelegten Strecke
(berechnet aus Geschwindigkeit und Fahrzeit) aufbaut, Koppelnavigation oder engl. Dead Reckoning 1 .
Die Koppelnavigation galt lange Zeit als die einzige Art der Navigation. Nachteil war die fehlende Genauigkeit der Positionsbestimmung. Ausschlaggebend für die teilweise sehr hohe Genauigkeitsbeeinträchtigung waren Akkumulationsfehler. Durch sie resultierten aus anfänglich geringen Messfehlern signifikante
Abweichungen von der tatsächlichen Position zu späteren Zeitpunkten. Obwohl stetig Neuerungen die
Messverfahren verbesserten, ließ die Genauigkeit dieser Technik viele Jahrhunderte sehr zu wünschen
übrig. Eine entscheidende Entwicklung war die Erfindung des Magnetkompasses im 11. Jahrhundert in
1 Dead
Reckoning ist eine Kurzform für Deduced Reckoning
4
2.1. NAVIGATION
5
China. Er ermöglichte eine weitaus genauere Ermittlung der Bewegungsrichtung und somit geringere Akkumulationsfehler. Allerdings wurde diese Genauigkeitsverbesserung nicht in der Nähe der Pole erreicht,
da die magnetischen Pole von den geografischen Polen abweichen (Deklination) und dadurch das Ergebnis
stark verfälscht wird.
Nachdem für lange Zeit keine Genauigkeitssteigerung in der Koppelnavigation erreicht wurde, entwickelte
sich im 17. Jahrhundert ein alternativer Lösungsansatz mit Hilfe der Lateration. Mit Lateration wird das
Messen des Abstandes zu mehreren Referenzpunkten bezeichnet. Hilfswerkzeuge zur Messung des Abstandes waren zu dieser Zeit die Winkelmessinstrumente Oktant und Sextant. Mit Hilfe dieser Geräte war
es möglich, den Winkel zwischen dem Horizont und einem Himmelskörper (z.b. Sonne, Mond, Sterne) zu
messen und daraus den Abstand zum Zenitpunkt, auch Bildpunkt genannt (fiktiver Punkt auf der Erdoberfläche, auf dem der Himmelskörper senkrecht steht), zu berechnen. Anhand eines Nachschlagewerkes, dem
so genannten Almanach, konnte man die Koordinaten des Zenitpunktes ablesen und so seine Position auf
einer Kreislinie festlegen. Durch mehrmaliges Messen ließ sich so die aktuelle Position bestimmen.
Die Lateration ebnete einige Jahrhunderte später auch den Weg zur Satellitennavigation. Nicht nur aufgrund
der sehr viel genaueren Ortung, gilt die Satellitennavigation als eine der wichtigsten Errungenschaften der
heutigen Navigation. Sie hat außerdem den entscheidenden Vorteil, dass sie bei richtiger Konstellation der
Satelliten auf der ganzen Welt zu jeder Zeit mit einer relativ konstanten Fehlergröße verfügbar ist. Bekannte satellitenbasierte Ortungsverfahren sind das US-amerikanische Global Positioning Systems (GPS)
[off a], das russische Global’naya Navigatsionnaya Sputnikovaya Sistema (GLONASS) [glo b] der ehemaligen UdSSR und das europäische Galileo [gal ]. Das derzeit am häufigsten eingesetzte System ist GPS.
Eine genauere Betrachtung von GPS folgt in Kapitel 3.1.
Wie diese Historie zeigte, ist die Navigation nichts neues in der Geschichte der Menschheit. Doch zeigt
sie in der heutigen Zeit eine stetig wachsende Nachfrage innerhalb verschiedenster Anwendungsgebiete.
Egal ob auf dem Boden, in der Luft oder zur See ist Mobilität ein entscheidendes Schlagwort unserer Zeit.
Dabei bewegt sich der Mensch in den verschiedensten Arten fort. Er geht zu Fuß, fährt mit dem Auto, mit
der Bahn, mit dem Schiff oder fliegt mit dem Flugzeug. Durch die erhöhte Unkenntnis über den aktuellen Aufenthaltsort und geografische Zusammenhänge erhält die Navigation einen erhöhten Stellenwert in
seinem Leben.
2.1.2
Menschliche Navigation
Nachdem nun die Geschichte und das stetige Interesse der Menschheit an der Navigation gezeigt wurden, bleibt die Frage offen, was Navigation überhaupt bedeutet. [Mont ] bezeichnet die Navigation als
coordinated and goal-directed movement“. Dabei unterscheidet er strikt zwischen Lokomotion“ und
”
”
Wegfindung“. Als Lokomotion (engl. Locomotion) wird die Bewegung bezeichnet, die sich aufgrund
”
der Wahrnehmung des unmittelbaren Umfeldes intuitiv ergibt. Die Lokomotion ist demnach für die eigentliche Fortbewegung verantwortlich. Sie koordiniert die Bewegung, um das Gleichgewicht zu halten,
zu beschleunigen und abzubremsen oder Hindernisse zu umgehen. Dabei werden aktive Bewegungsarten
wie Gehen, Laufen oder Rennen über Mischformen wie Radfahren oder Autofahren bis hin zu passiven
Bewegungsarten wie Zug- oder Busfahren unterstützt. Die einzelnen Bewegungsarten werden durch die
Wahrnehmungen verschiedener Sensoren koordiniert. Für die Lokomotion trägt vor allem die Wahrnehmung von visuellen, akustischen, kinästhetischen und vestibulären Signalen durch die menschlichen Sinnesorgane dazu bei unbeschadet von A nach B zu gelangen. Die Reaktion auf diese Signale sorgt dafür,
beim Gehen nicht zu stolpern oder beim Radfahren das Gleichgewicht halten zu können.
Im Gegensatz zur Lokomotion, der intuitive Prozesse zugrunde liegen, zeichnet sich die Wegfindung (engl.
Wayfinding) im Normalfall durch ein höheres Maß an Kognition aus. [Mont ] bezeichnet die Wegfindung
als planning and decision-making activities that allow goal-directed locomotion coordinated to the di”
stal as well as local surrounds“. Anders als die Lokomotion ist die Wegfindung nicht auf das unmittelbare Umfeld beschränkt. Die Wegfindung ist primär für die Planung und Entscheidung der Bewegung im
weiteren Umfeld des Subjektes verantwortlich. Das weitere oder mittelbare Umfeld wird oft unter dem
Begriff Large-scale environment“ benutzt. Es kann nicht direkt durch Sensoren wahrgenommen werden
”
und benötigt daher Hintergrundinformationen. Diese Hintergrundinformationen sind zuvor angeeignetes
Wissen wie zum Beispiel kognitive Karten [Tolm 48] (internes Wissen) oder physisches Kartenmaterial
6
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
(externes Wissen), sowie verschiedenste Arten von Routenbeschreibungen (intern sowie extern).
All diese Informationen führen zum deklarativen Wissen, im Gegensatz zum nicht-deklarativen Wissen,
welches zur Lokomotion eingesetzt wird. Deklaratives Wissen ist Wissen, dessen Inhalt eindeutig beschreibbar ist und dessen Verarbeitung kognitive Prozesse verlangt. Zum deklarativen Wissen zählt beispielsweise das Wissen über geografische Gegebenheiten oder Routenwissen. Aufgrund der kognitiven
Prozesse in der Verarbeitung des deklarativen Wissens verlangt die Wegfindung einen erhöhten Grad an
Aufmerksamkeit. Je nach Ausprägung des deklarativen Wissens kann der Grad der Aufmerksamkeit variieren. Kognitive Karten zeichnen sich beispielsweise durch ein relativ geringes Aufmerksamkeitsverlangen
aus, da sie nur stark schematisierte, topologische Repräsentationen der realen Welt sind und somit unnötige
Informationen ausblenden und sich auf relevante inhaltliche Zusammenhänge beschränken. Dagegen legt
physisches Kartenmaterial im Normalfall höhere Aufmerksamkeit zugrunde. Vor allem wenn die Karte
nicht orientiert ist, muss im Zuge der Navigation eine Umorientierung, d.h. eine Umsetzung der Richtungen der Karte auf die Richtungen der Realität erfolgen. Diese Umsetzung erzeugt eine Aufwandssteigerung
der kognitiven Prozesse.
Dies zeigt, dass der kognitive Aufwand, der durch die Wegfindung entsteht, abhängig von der subjektiven
Qualität des Wissens ist (vgl. [BBKL ]). Ein zweites entscheidendes Problem ist natürlich, ob ein derartiges Wissen überhaupt verfügbar ist, bzw. verfügbar gemacht werden kann. An diesen zwei Punkten greift
die moderne Informationstechnik ein. Durch sie ist es möglich, zu jeder Zeit an jedem Ort qualitativ hochwertige Informationen bereitzustellen. Sie bietet eine Lösung für das Wissensdefizit und eine Reduktion
der kognitiven Prozesse durch qualitativ hochwertige, deklarative Informationen, die die Wegfindung betreffen. Diese Arbeit beschäftigt sich deshalb nur mit dem Problem der Wegfindung, die im Folgenden mit
dem Wort Navigation“ gleichgesetzt wird.
”
2.1.3
Navigationsprozess
Die Geschichte der Navigation hat bereits gezeigt, dass die verschiedenen Arten der Navigation sich
größtenteils durch die Art ihrer Ortung unterscheiden. Beispiele hierfür sind die Sichtnavigation, die traditionelle Koppelnavigation oder die Satellitennavigation. Alle drei Arten unterscheiden sich wesentlich in
der Art ihrer Ortung. Zwar ist die Ortung ein entscheidender Aspekt der Navigation, sie ist allerdings kein
Synonym für die Navigation, obwohl dies häufig so verwendet wird.
Innerhalb des Navigationsprozesses fallen aber weitere Schritte an, die für eine erfolgreiche Navigation
unabdingbar sind. Einen Einstieg in den Navigationsprozess sollen die folgenden zwei Beispiele liefern:
Auf dem Weg von A nach B kommt Person E auf ihrem Fahrrad an eine T-Kreuzung. Da sich E nicht
auskennt, hält sie an und holt eine Straßenkarte der Region hervor. Darin sucht sie die Kreuzung, die sie
anhand des Namens identifiziert. Um zu ihrem Ziel zu gelangen, muss E in die Hauptstraße einbiegen. E
betrachtet die Straßennamen, erkennt die Hauptstraße und begibt sich in die Richtung ihres Ziels.
Durch die schlechte Straßenbeschaffenheit verliert E das Gleichgeweicht auf ihrem Rad. Als ihr Unterbewusstsein bemerkt, dass sich ihr Schwerpunkt zu weit rechts befindet, wird ihr intuitiv klar, dass sie
dem entgegenwirken muss. Dazu macht sie eine Ausgleichsbewegung und erlangt daraufhin langsam ihr
Gleichgewicht wieder.
Beide Beispiele beschreiben einen Navigationsprozess. Während sich das erste Beispiel auf die Wegfindung bezieht, behandelt das zweite Beispiel die Lokomotion. Beide Beispiele beschäftigen sich mit der
grundlegenden Frage: Wo befinde ich mich?“ Eine Antwort dafür gibt die Ortung, die als Resultat Ortsin”
formationen liefert. Anschließend, aber nicht zwingend nach jeder Ortung, stellt sich dann die Frage Wo
”
muss ich hin?“ Zur Beantwortung muss die zukünftige Bewegungsrichtung bestimmt werden. Dies erfolgt
durch die Routenführung. Letztlich stellt sich die Frage Wie setze ich dies in die Realität um?“ Dazu muss
”
die zukünftige Bewegungsrichtung noch auf die reale Umgebung abgebildet werden.
Dieses Kapitel befasst sich mit eben diesen Fragestellungen. Dazu erfolgt eine genauere Betrachtung des
Navigationsprozesses und dessen Teilprozesse Ortung, Routenführung und Abbildung.
2.1. NAVIGATION
7
Ortung
Als Ortung bezeichnet man allgemein die Bestimmung von Ortsinformationen. Eine der wichtigsten Ortsinformationen ist die Position. Unter Position (lat. positio = Stellung, Lage) einer Person oder eines Ge”
genstandes versteht man die Stelle, an der sich die Person bzw. der Gegenstand befindet“ [wik ]. Durch
die Position kann das Objekt in den geografischen Raum eingeordnet werden. Positionen können unterschiedliche Ausdehnungen und Formen besitzen und demnach ein einzelner Punkt bis hin zu einer weit
ausgedehnten Fläche oder sogar ein Raum sein.
Zur Operationalisierung von Positionen braucht man eine Beschreibung dieser Position. Um verschiedene
Positionen zu vergleichen und mit diesen in eindeutiger Weise arbeiten zu können, muss diese Positionsbeschreibung an mindestens einen eindeutigen Punkt, einen Referenzpunkt, gebunden werden. Folglich
kann die Position eines Objektes am Münchner Marienplatz beispielsweise mit am Münchner Rathaus“
”
beschrieben werden. Als Referenzpunkt wurde in diesem Fall das Rathaus von München gewählt, auf das
eindeutig Bezug genommen werden kann. Allgemein sind Referenzpunkte reale oder fiktive Orte, die eine eindeutige Position im Raum einnehmen. Dazu müssen sie von anderen Orten unterscheidbar sein. Das
Münchner Rathaus stellt einen eindeutigen realen Ort in der Münchner Innenstadt dar, der sich von anderen
Orten eindeutig unterscheidet. Ein Beispiel für einen fiktiven Ort stellt der oben vorgestellte Zenitpunkt dar.
Er ist der Ort auf der Erdoberfläche, auf dem zu einem bestimmten Zeitpunkt ein Himmelskörper senkrecht
steht und ist dadurch eindeutig unterscheidbar von jedem anderen Ort.
Ein weiterer wichtigerer eindeutiger Referenzpunkt ist der Masseschwerpunkt der Erde, das so genannte
Geozentrum. Das World Geodetic System 1984 (WGS84)-Datum oder das European Terrestrial Reference
System 1989 (ETRS89)-Datum mit dem Rotationsellipsoiden Geodetic Reference System 1980 (GRS80)
nutzen als Referenzpunkt das Geozentrum der Erde (vgl. [wgs ]). Andere Beispiele, deren Referenzpunkt
leicht vom Masseschwerpunkt der Erde verschoben ist, sind Datums 2 , die auf lokale Rotationsellipsoide
aufbauen, wie der in Deutschland bekannte Bessel-Ellipsoid.
Durch die Festlegung dieses Referenzpunktes ist es nun möglich, eine Position mit diesem Referenzpunkt gleichzusetzen. Natürlich ist die Ausdruckskraft einer derartigen Positionsbeschreibung noch sehr
rudimentär. Was in vielen Fällen noch benötigt wird, ist die Möglichkeit, Entfernungs- und/oder Richtungsrelationen zu diesen Referenzpunkten angeben zu können. Ein vom Menschen oft verwendetes zweidimensionales Richtungsrelationensystem stellen die Ausdrücke vor“, rechts von“, hinter“ und links
”
”
”
”
von“ dar. Durch sie lässt sich nun die bereits angeführte Position auf dem Marienplatz mit vor dem
”
Münchner Rathaus“ ausdrücken. Derartige Relationen, die abhängig vom Betrachtungswinkel sind, gelten als egozentrisch. Im Gegensatz dazu sind allozentrische (oder geozentrische) Positionsbeschreibungen
unabhängig vom Betrachtungswinkel, da sie zu einer allgemeingültigen Richtung referenziert sind (vgl.
[Klat 04, Mont ]). Ein Beispiel hierfür ist das Relationensystem nördlich“, östlich“, südlich“, west”
”
”
”
lich“. Obiges Beispiel mit allozentrischer Positionsbeschreibung lautet wie folgt: Person XY ist westlich
”
vom Münchner Rathaus“. Für eine eindeutige Positionsbeschreibung muss an dieser Stelle noch der Abstand zwischen der Position und dem Referenzpunkt angeben werden.
Im Bereich der Geodäsie werden Datums, durch die unter anderem Referenzpunkte spezifiziert werden,
durch Koordinatensysteme erweitert, um die Relation zwischen Referenzpunkt und Position zu beschreiben. Zusammen ergibt sich das so genannte Koordinatenreferenzsystem [Nico 03]. Im Wesentlichen existieren zwei Arten von Koordinatensystemen in der dreidimensionalen Geodäsie: kartesische und ellipsoidische Koordinatensysteme (auch bekannt als geodätische Koordinatensysteme). In ellipsoidischen Koordinatensystemen werden Positionen durch so genannte LLA-Werte (Latitude-Longitude-Altitude-Werte)
angegeben.
Eine Position auf der Erde kann durch ihren Breitengrad und ihren Längengrad eindeutig bestimmt werden. Als Längengrade oder Längenkreise (oder Meridiane) werden hierbei die Kreise um die Erde durch
beide Pole bezeichnet. Jeder Längenkreis hat daher den gleichen Umfang. Breitengrade oder Breitenkreise sind parallele Kreise zum Äquator. Sie haben im Unterschied zu den Längenkreisen unterschiedliche
Umfänge. Sollen auch Positionen über- oder unterhalb der Erdoberfläche beschreibbar sein, muss zusätzlich der Abstand vom Referenzpunkt angegeben werden. LLA-Werte beschreiben genau diese Werte. Der
Latitudenwert definiert den Breitengrad, auf dem sich die Position befindet, meist durch Angabe des Win2 geodätisches
Datum, Mz. geodätische Datums
8
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
kels zwischen dem Äquator, dem Referenzpunkt und dem Breitengrad innerhalb eines Längenkreises. Der
Longitudenwert definiert den Längengrad, auf dem sich die Position befindet, meist durch Angabe des
Winkels zwischen einem Nullmeridian, dem Referenzpunkt und dem Längengrad innerhalb eines Breitengrades. Schließlich bestimmt die Altitude den Abstand zwischen der Position und dem Referenzpunkt.
Durch diese drei Werte in Verbindung mit dem im Datum spezifizierten Referenzpunkt kann eine Position
eindeutig beschrieben werden.
In kartesischen Koordinatensystemen hingegen werden Koordinaten durch XYZ-Werte angegeben. Dies
sind die Abstände zwischen dem Referenzpunkt und der Position entsprechend jeder Achse (X-, Y-, ZAchse) des dreidimensionalen Koordinatensystems.
Die Positionsbeschreibungen zu Referenzpunkten wie Münchner Marienplatz“ werden oft als semantische
”
Positionsbeschreibungen bezeichnet (vgl. [Roth 03]). Übliches Referenzsystem ist das bereits beschriebene
Richtungsrelationensystem (vor, rechts von, hinter, links von). Demgegenüber werden Positionsbeschreibungen zu Referenzpunkten wie dem Geozentrum der Erde als physische Positionsbeschreibungen bezeichnet. Als Referenzsystem kommen hier meist Koordinatenreferenzsysteme zum Einsatz.
Die vorangegangenen Absätze zeigten einen kurzen Einblick in die Geodäsie, die im Rahmen dieser Arbeit als Grundlage für das Verständnis örtlicher Zusammenhänge dienen soll. Für genauere Betrachtungen
muss an dieser Stelle auf [geo 84, Küpp 05] verwiesen werden, da dies den Rahmen dieser Arbeit sprengen
würde. Schließlich bleibt noch die Frage offen, wie nun die Relation zwischen der Position und dem Referenzpunkt bestimmt werden kann. Dazu existieren verschiedenste Verfahren basierend auf Abstands- und
Winkelmessungen zwischen der Position und dem Referenzpunkt oder anderen fixen Punkten, deren Positionen bereits bekannt sind (vgl. [HiBo 01, Küpp 05]). Die Verfahren unterscheiden sich im Wesentlichen
durch die Anzahl der nötigen Messungen und dem der Messung zu Grunde liegenden Observable“. Auf ei”
ner zweidimensionalen Fläche sind beispielsweise drei Abstandsmessungen zwischen der Position und drei
nicht-kollinearen fixen Punkten ausreichend, um die Position eindeutig zu bestimmen. Genauso möglich
ist allerdings eine Winkelmessung zwischen Position und Referenzpunkt bezüglich einer Referenzrichtung und eine Abstandsmessung zwischen Position und Referenzpunkt (oder fixem Punkt). Die Messung
kann dabei auf verschiedensten Signalen wie Radiowellen, Ultraschall, Lichtwellen, sowie kinästhetischen
oder vestibulären Signalen basieren. Letztendlich wird aus dieser Messung auf verschiedenste Arten der
Abstand oder die Richtung gewonnen. Beispielsweise kann der Abstand durch die Signalabschwächung,
durch einfache Integration der Geschwindigkeit oder zweifache Integration der Beschleunigung nach der
Zeit ermittelt werden.
Neben der Position ist die Ausrichtung (oder Orientierung) eine zweite wichtige Art von Ortsinformation.
Die Ausrichtung eines Objektes kann nur für Objekte, die eine Ausrichtung besitzen, angegeben werden.
Der Mensch als Beispiel kann sich durch mehrere Ausrichtungen auszeichnen. Diese sind beispielsweise
die Blickrichtung oder die Bewegungsrichtung, die nicht zwangsläufig gleichwertig sein müssen, jedoch
bei Ungleichheit zu schweren Unfällen führen können. Zur Operationalisierung der Ausrichtung gibt es wie
bei der Position verschiedene Beschreibungen. Basis ist wie bei der Position eine Referenzrichtung. Die
Ausrichtung kann dann mittels des Winkels zwischen der Richtung und der Referenzrichtung beschrieben
werden. Die Beschreibung einer Ausrichtung ist in der Regel allozentrisch oder egozentrisch zu einer anderen Ausrichtung, da eine egozentrische Beschreibung, die als Referenzrichtung eben diese Ausrichtung
nutzt, immer einen Winkel von 0 Grad besäße (vgl. [Klat 04]). Eine Beschreibung der Bewegungsrichtung
kann so zum Beispiel 30◦ gegenüber der allozentrischen Richtung Norden sein oder 215◦ gegenüber der
egozentrischen Blickrichtung.
Durch die Lokomotion verändern sich in der Regel die Ortsinformationen. Nimmt man alle Ortsinformationen zusammen und beschreibt dadurch einen Zustand, werden durch die Lokomotion Zustandsübergänge durchgeführt (vgl. [Kuip 00]). Dabei lösen bestimmte Zustände bzw. Zustandsübergänge
die Routenführung aus. Etwas anschaulicher kann dies an der menschlichen Navigation gezeigt werden.
Bewegt sich ein Mensch auf einem Straßennetzwerk und erreicht durch die Lokomotion die Kreuzung
K1 aus südlicher Richtung, so kann sein Zustand durch die Ortung zum Beispiel durch (K1 , N ord) beschrieben werden, wobei K1 seine Position und N ord seine Bewegungsrichtung angibt. Da dieser Zustand
für ihn die Frage Wo muss ich hin?“ aufwirft, wird daraufhin die Wegfindung angestoßen, die ihn wie
”
im einleitenden Beispiel dazu bringt eine physische Karte aufzuschlagen und dort ausgehend von seinen
derzeitigen Ortsinformationen den weiteren Routenverlauf zu studieren. Die Wegfindung kann aber auch
aufgrund eines Zustandsüberganges angestoßen werden. Ein Beispiel hierfür ist, dass Zurücklegen einer
2.1. NAVIGATION
9
bestimmten Menge von Zustandsübergängen. Ausgehend von dieser Menge wird die Routenführung angestoßen.
Die Ortung ist also nicht nur für die Bestimmung von Ortsinformationen verantwortlich, sondern übernimmt auch die Aufgabe bei Eintritt bestimmter Zustände bzw. Zustandsübergänge, die Routenführung
anzustoßen.
Routenführung
Die Routenführung bestimmt dann anhand von Routeninformationen die in Zukunft einzuschlagende Richtung. [Pass 92] bezeichnet diesen Vorgang als Decision Making. Anhand der Route wird die Entscheidung
über die zukünftige Bewegungsrichtung getroffen. Eine Route stellt zur aktuellen Position Informationen
für den weiteren Routenverlauf bereit. Ist die aktuelle Position nicht in der Route spezifiziert, muss gegebenenfalls eine andere Route herangezogen werden, bzw. bestimmt werden.
Eine übliche Routendarstellung für die menschlichen Navigation, ist die Integration in Landkarten. Als
Ausgangspunkt dient eine isolierende, statische Projektion der Realität auf eine zweidimensionale Ebene
(vgl. [Beck 02]). Eine der wichtigsten Projektionsart ist die Transversale Mercator Projektion, die z.B. beim
UTM- und beim Gauß-Krüger-Koordinatensystem zum Einsatz kommt. Um eine möglichst originalgetreue
Abbildung der Realität zu erzeugen, spielt neben der Wahl des Projektionsverfahrens der Karteninhalt eine entscheidende Rolle. Eine allumfassende Darstellung der Realität würde zwangsläufig zu einer Karte,
die so groß ist wie die Realität selbst führen, wie es Jorge Luis Borges in Of Exactitude in Science“
”
[BoCa 46] anschaulich beschreibt. Es muss eine geeignete Selektion des Inhaltes vorgenommen werden.
Welche Informationen in der Landkarte enthalten sind, ist wesentlich von der Art der Landkarte abhängig.
Topografische Landkarten beispielsweise beschränken sich auf die Darstellung der natürlichen Erdoberfläche. Sie dienen als Basis für viele weitere Landkartenarten, die sich beispielsweise durch Hinzunahme
der Landesgrenzen, Bebauungen oder klimatischer Aspekte auszeichnen.
Schließlich wird basierend auf dieser verkleinerten und vereinfachten Abbildung der Realität die Route in
Form von Wegstrecken innerhalb einer Landkarte dargestellt. Eine Wegstrecke ist hierbei ein Linienzug,
der durch diverse Zwischenpunkte den Start- mit dem Zielpunkt verbindet, wobei Start- und Zielpunkt sowie Zwischenpunkte identisch sein können. Zusammen mit der zu Grunde liegenden Landkarte führt diese
Wegstrecke zu einer vollwertigen Routenbeschreibung. Durch die Ortung kann die Position auf diesem Linienzug erkannt und anhand des weiteren Routenverlaufs die einzuschlagende Richtung bestimmt werden.
Eine genauere Betrachtung von Routen erfolgt in Kapitel 2.2.
Abbildung
Schließlich muss eine Abbildung der aus dem Routenverlauf ersichtlichen zukünftigen Bewegungsrichtung
in die Realität erfolgen. Je nach Art der Routenbeschreibung kann dieser Schritt des Navigationsprozesses trivial bis sehr komplex werden. Aus obiger Routenbeschreibung mittels einer Kartendarstellung kann
die zukünftige Bewegungsrichtung anhand von Straßennamen erkannt und auf die Realität abgebildet werden. Dazu liest der Navigator aus der Karte ab, dass er in Richtung seines Ziels gelangt, wenn er an der
nächsten Kreuzung in die Hauptstraße einbiegt. Mit diesem Wissen betrachtet er seine Umgebung, erkennt
die Hauptstraße und kann so das aus der Routenbeschreibung erworbene Wissen auf die Realität abbilden.
Anschließend folgt die eigentliche Umsetzung der zukünftigen Bewegungsrichtung durch die Lokomotion.
[Pass 92] bezeichnet diesen letzten Schritt der Umsetzung als Decision Execution.
Zusammenfassung
Dieses Kapitel zeigte nun wie ein Navigationsprozess ablaufen kann. Dabei wurde eine Routenbeschreibung innerhalb einer Karte gewählt. Aber es existieren auch andere Routenbeschreibungen, die bei der
menschlichen Navigation zum Einsatz kommen. Ein Beispiel sind imperative Routenbeschreibungen. Ein
Ausschnitt einer imperativen Routenbeschreibung könnte folgendermaßen aussehen: ... dann gehe die
”
10
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
Hauptstraße Richtung Norden und biege die zweite mögliche Straße rechts ab. Anschließend musst du
nach 250 Metern links abbiegen und ...“ . Dieses Beispiel zeigt bereits anschaulich, dass der Navigationsprozess sich als sehr komplex herausstellen kann. Erhält man eine derartige Routenbeschreibung, so stellt
sich als erstes die Frage, wo überhaupt die Hauptstraße verläuft. Angenommen man erkennt dies anhand
eines Straßenschildes, so stellt sich dann die Frage in welcher Richtung sich Norden befindet. Desweiteren
ist von Interesse was eine mögliche Straße ist und wie weit 250 Meter sind. Wie man hier erkennt, kann
ein derart kurzes Routenfragment bereits eine Vielzahl an Problemen hervorbringen, deren Lösung durch
technische Unterstützung dem Menschen einen großen Mehrwert bieten kann.
2.2 Mobile Navigationsdienste
2.2.1
Mobile Dienste
In der Ära des Ubiquitous Computing“ [Weis 91] ist der Mensch von einer Vielzahl an intelligenten
”
Geräten umgeben, die ihm seinen Alltag erleichtern. Geräte wie Mobiltelefone, Personal Digital Assistants
(PDAs) und Notebooks gehören in der heutigen Zeit zur ständigen Ausstattung vieler Menschen. Diese
Geräte werden erweitert durch Desktop-PCs im Büro und zu Hause, intelligente Fahrzeuge oder sogar
intelligenten Staub. All dies macht es möglich zu jeder Zeit an jedem Ort den Zugriff auf jegliche Informationen (z.B. Fahrpläne, Wettervorhersagen, Telefonnummern) und jegliche Anwendungen (z.B. Auktionen,
Photoentwicklung, Kommunikationsverbindung) zu ermöglichen. Egal, ob zu Hause auf dem Desktop-PC
oder unterwegs auf dem Mobiltelefon, können Informationen abgefragt oder Anwendungen genutzt werden (vgl. [SAW 94, Schi 95, BuTu , RuKr 03]).
Diese Informationen und Anwendungen werden von Diensten (engl. Services) bereitgestellt. [Stra 03] definiert einen Dienst als eindeutig identifizierbare Instanz, die für die Beschaffung von Informationen oder
”
für die Ausführung von Aktionen mit spezifischen Merkmalen verantwortlich ist“. Dabei kann zwischen
Carrier Services und Highlevel Services unterschieden werden (vgl. [SLPR 03, Röck 03]). Carrier Services
stellen im Wesentlichen Funktionen zur Datenübertragung bereit. Beispiele für Carrier Services sind der
Short Message Service (SMS), der General Packet Radio Service (GPRS) oder auch diverse Datenübertragungsdienste für drahtgebundene Netze. Highlevel Services nutzen Carrier Services, um ihr Anwendungsoder Informationsangebot verfügbar zu machen. Beispiele für Highlevel Services sind Fahrplanauskunfts-,
Photoentwicklungs- und Navigationsdienste. Sie stellen Highlevel-Informationen“ wie Ab- und Ankunfts”
daten von Bussen, Flugzeugen, etc., Navigationsinformationen und die Funktion der Photoentwicklung
(vgl. [Röck 03, SLPR 03]) bereit. Die Datenübertragung wird durch die Carrier Services übernommen.
Diese Arbeit beschäftigt sich ausschließlich mit Highlevel Services und bezeichnet mit den Ausdrücken
Dienst“ oder Service“ deshalb in der Regel Highlevel Services.
”
”
Durch die Entwicklung von mobilen Endgeräten wie Mobiltelefonen, PDAs, Notebooks ist es nun möglich,
diese Art von Diensten nicht nur zuhause oder im Büro zu nutzen, sondern an jedem beliebigen Ort. Dienste, die in dieser Weise genutzt werden können, nennt man mobile Dienste. Oft unterscheidet man hierbei
noch zwischen Portabilität und echter Mobilität, wobei Portabilität einer nomadischer Dienstnutzung unterliegt, während echte Mobilität eine kontinuierliche Dienstnutzung garantiert.
2.2.2
Location-based Services
Eine besondere Art der mobilen Highlevel Services sind so genannte Location-based Services (LBSs).
Wie der Name bereits erahnen lässt, handelt es sich hierbei um Dienste, die eine erhöhte Aufmerksamkeit
auf den örtlichen Kontext legen. In der Literatur findet man eine Vielzahl an Definitionen, die LBSs anhand
verschiedenster Gesichtspunkte charakterisieren. Beispielsweise beschreibt die GSM Association LBSs als
services that use the location of a target for adding value to the service“ [gsm 03]. In dieser Definition
”
zeichnet sich ein LBS also dadurch aus, dass der Wert des Dienstes durch den Ort generiert wird. Fraglich ist an dieser Stelle, was der Wert eines Dienstes ist und wie der Ort diesen Wert beeinflusst. Das 3rd
Generation Partnership Project (3GPP) definiert den LBS als a service provided by a service provider
”
2.2. MOBILE NAVIGATIONSDIENSTE
11
that utilizes the available location information of the terminal“ [3gp 04]. In dieser Definition sind LBSs
Dienste, die sich Ortsinformationen des Endgerätes zunutze machen. Dabei werden ausschließlich Ortsinformationen des Endgerätes, auf dem der Dienst genutzt wird, in Betracht gezogen.
Bevor nun eine Definition für LBSs gegeben werden kann, die die entscheidenden Aspekte dieser Arbeit
beinhaltet, müssen noch einige grundsätzliche Fragestellungen im Umfeld von Diensten geklärt werden.
Diese betreffen die Interaktion zwischen Dienstnutzer und Dienstanbieter.
Pull-/Push-Interaktionsmuster
Dienstnutzer und Dienstanbieter zeichnen sich durch unterschiedliche Informationsverteilungen aus.
Der Dienstnutzer hat Interesse an Informationen des Dienstanbieters. Dazu tauschen Dienstnutzer und
Dienstanbieter Nachrichten aus. Nach [Andr 91, Umar 97] wird eine Interaktion zwischen Dienstnutzer
(als Client-Komponente) und Dienstanbieter (als Server-Komponente) durch eine vom Client initiierte Anfrage angestoßen. Bei Erhalt der Anfrage führt der Server den von ihm bereitgestellten Dienst aus und
sendet daraufhin das Ergebnis des Dienstaufrufs als Antwort an den Client zurück. Diese Antwort kann
entweder das Ergebnis des Dienstaufrufs oder eine Fehlermeldung wie Dienst derzeit nicht verfügbar“
”
sein. Meist handelt es sich dabei um eine synchrone Kommunikation, da der Client solange blockiert ist bis
eine Antwort auf seine Anfrage eingetroffen ist. Im Normalfall erhält der Client auf seine Anfrage genau
eine Antwort. In manchen Fällen ist es auch möglich, keine oder mehrere Antworten auf eine Anfrage zu
bekommen. Dies soll hier aber nicht weiter behandelt werden.
Dienste, die sich durch eine derartige Interaktion auszeichnen, nennt man Pull-Dienste (vgl. [3gp d,
FrZd 96, Pars 04]). Charakteristisch für Pull-Dienste ist, dass eine Dienstausführung und die daraus resultierende Antwort des Anbieters grundsätzlich durch eine Anfrage des Nutzers initiiert werden. Demzufolge bezeichent [Andr 91] den Dienstnutzer als Triggering Process und den Dienstanbieter als Reactive
Process, da der Dienstnutzer die Interaktion initiiert und der Dienstanbieter auf diese Initiierung reagiert.
Der Nutzer nimmt also eine aktive Position in diesem Szenario ein. Er steuert aktiv die Ausführung des
Dienstes an und erhält daraufhin eine entsprechende Antwort.
Ein alltägliches Beispiel ist die Nutzung des World Wide Web (WWW) mit Hilfe der GET-Methode des Hyper Text Transfer Protocols (HTTP) [Fiel 99]. HTTP GET basiert auf dem so genannten Request-ResponseProtokoll. Das heißt, es wird eine Anfrage vom Dienstnutzer an den Dienstanbieter und daraufhin genau
eine Antwort vom Dienstanbieter an den Dienstnutzer gesendet. In der Antwort ist in der Regel eine Webseite, ein Bild oder Musik enthalten. Für jede Antwort, die genau eine dieser Ressourcen enthält, muss eine
explizite HTTP-Anfrage vom Nutzer an den Anbieter gestellt werden.
Ein ähnliches Beispiel stellen Directory Services wie Telefonbuch- oder Fahrplan-Dienste dar. Durch eine Anfrage an einen Dienstanbieter, der solche Dienste bereitstellt, erhält man Telefonbucheinträge oder
Informationen über Abfahrtszeiten. Integriert man in die Dienstausführung Ortsinformationen, so lassen
sich zum Beispiel ortsabhängige Fahrplandienste realisieren, die als Ergebnis die Abfahrtszeiten der naheliegenden öffentlichen Verkehrsmittel liefern. Ergänzend hierzu ergeben sich so genannte Finder-Dienste.
Unter Finder-Diensten versteht man Dienste, die die Suche nach bestimmten Örtlichkeiten erleichtern. Als
bekanntes Beispiel gilt der Restaurant-Finder, mit dessen Hilfe das nächstgelegene Restaurant ausfindig
gemacht werden kann.
Eine wesentlich andere Interaktion erfolgt bei den so genannten Push-Diensten [3gp d]. Bei diesen
Diensten wird die Ausführung des Dienstes durch ein Ereignis ausgelöst, das nicht einer expliziten Nutzeranfrage entspricht (vgl. [elb , FrZd 96]). Ereignisse in diesem Zusammenhang sind zum Beispiel konkrete Uhrzeiten, zu denen eine Dienstausführung angestoßen wird, oder die automatische Benachrichtigung
bei Eintreffen einer Email. Meist werden derartige Dienste durch das Publish-Subscribe-Muster realisiert,
d.h. der Nutzer stellt einmal eine Anfrage, registriert sich dadurch beim Dienstanbieter für ein bestimmtes
Ereignis und erhält daraufhin bei jedem Eintreten des Ereignisses eine Antwort. Oft handelt es sich bei
dieser Art von Diensten um eine asynchrone Kommunikation. Beispiele sind im Bereich der AbonnementServices zu finden. Hier registriert man sich für ein spezielles Thema, z.B. Aktienkurse, Nachrichten oder
Wetterberichte, und erhält bei bestimmten Veränderungen des jeweiligen Themas eine Mitteilung auf sein
Mobiltelefon. Ein weiteres Beispiel sind Email-Push-Dienste, die durch die Blackberry Push-Architektur
[bla ] verwirklicht werden. Die Architektur sorgt dafür, dass bei Eintreffen einer neuen Email automatisch
12
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
eine Kopie dieser Email an das speziell dafür vorgesehene mobile Endgerät gesendet wird. Dadurch erhält
der Nutzer stets ohne eigenes Zutun die neuesten Emails, was besonders für geschäftliche Anwendungszwecke vorteilhaft ist.
Mit der Integration von Ortsinformationen in die Dienstausführung lassen sich zusätzliche ortsabhängige
Themen anbieten. So ist es möglich, dass sich ein Nutzer über Veränderungen der Wetterlage informieren lässt. Interessante Veränderungen sind für ihn allerdings nur Wetterlageänderungen in einer gewissen
Nähe zu ihm. Deshalb muss bei der Dienstausführung eine Selektion der Informationen anhand der aktuellen Position durchgeführt werden. Ein weiteres Beispiel stellt ein ortsbasierter Email-Push-Dienst dar.
Die Emailzustellung wird hier nicht durch das Eintreffen der Email ausgelöst, sondern zusätzlich durch die
örtliche Relevanz der Email. So werden Emails an die Firmenadresse bei örtlicher Nähe zum Büro automatisch zugestellt, Emails an die Privatadresse erhält der Nutzer nur zuhause.
Ein anderes Beispiel findet man im Bereich des Mobile-Advertising (m-Advertising) [elb ]. M-Advertising
bezeichnet Dienste, die Werbung mittels mobilen Endgeräten an potenzielle Kunden verteilen. Potenzielle Kunden im Bereich des direkten Vertriebs zeichnen sich unter anderem dadurch aus, dass sie sich in
der Nähe des Verkaufsstandorts befinden. Bei m-Advertising-Diensten muss demnach eine ortsabhängige
Initiierung erfolgen. Ein Beispieldienst könnte folgendermaßen ablaufen: Sobald der Nutzer in die Nähe
des Verkaufsstandorts kommt und den m-Advertising-Dienst aktiviert hat, erhält er eine Werbebotschaft
auf seinem Mobiltelefon. Zusätzlich ist in der Werbebotschaft ein Gutschein über 10 % Rabatt, um dem
Nutzer den Dienst attraktiver zu machen (vgl. [elb ]).
Dienstnutzer
Dienstnutzer
Dienstanbieter
Dienstanbieter
Pull
Push
Abbildung 2.1: Pull- und Push-Szenario
Der wesentliche Unterschied zwischen Pull- und Push-Diensten besteht demnach darin, dass bei PullDiensten die Dienstausführung durch den Nutzer initiiert wird, wohingegen bei Push-Diensten der
Dienstanbieter ohne Einwirkung des Nutzers die Dienstausführung anstößt. Der Nutzer nimmt also bei
ersterem eher eine aktive Position ein, wohingegen er bei zweiterem eher als passiv charakterisiert werden
kann. Ähnlich hierzu werden Push-Dienste auch oft als proaktiv, Pull-Dienste als reaktiv deklariert, wobei
natürlich beide auf bestimmte Ereignisse reagieren.
Wie die Beispiele bereits zeigten, kann die Aktion der Initiierung durch verschiedenste Ereignisse ausgelöst
und an verschiedenste Bedingungen geknüpft werden. Derartige Konstrukte sind bereits im Datenbankbereich und im Bereich der kontextsensitiven Dienste vorhanden. Bei kontextsensitiven Diensten (vgl. hierzu
[StLP 03, AAH+ 97, Stra 03, Schi 95, SAW 94, DeAb 99]) spricht man von Context-Triggered Actions
[ChKo 00, SAW 94, Schi 95], d.h. die Aktionen werden aufgrund von Kontextveränderungen ausgelöst. Im
Bereich der Location-based Services handelt es sich bei den Kontextveränderungen um Änderungen der
Ortsinformationen. Aktionen, die auf derartige Veränderungen reagieren, werden deshalb als LocationTriggered Actions bezeichnet. Push-Dienste, deren Initiierung auf Location-Triggered Actions beruht,
zählt man dementsprechend zu den Location-based Push-Services (LBPSs) (vgl. [PSM 01, Fuch 02]).
Location-based Pull-Services reagieren im Gegensatz zu den Location-based Push-Services nicht auf
Location-Triggered Actions, sondern werden durch den Nutzer initiiert. Die Ortsabhängigkeit fällt bei diesen Diensten in die Dienstausführung.
Es gibt also zwei Bereiche, in denen Ortsinformationen Einfluss auf den Dienst haben können. Diese sind
die Dienstinitiierung und die Dienstausführung. Während Pull-Services Ortsabhängigkeit nur in der Dienstausführung zulassen, besteht die Möglichkeit bei Push-Diensten Ortsinformationen in die Dienstinitiierung
13
2.2. MOBILE NAVIGATIONSDIENSTE
und Dienstausführung einzubringen.
Die Beispiele dieses Kapitels sind unter den Gesichtspunkten der Initiierung und Ausführung mit und ohne
Ortsabhängigkeit in Abbildung 2.2 nochmals dargestellt.
Initiation
Execution
Pull
Conventional
Push
Location-based
Push
Conventional
Execution
Directory Services
Abo-Services
M-Advertising
Restaurant Finder
Weather Warning
Service
Navigation Service
Location-based
Execution
Abbildung 2.2: Beispiele für Push/Pull-Services mit/ohne Ortsabhängigkeit
Definition
Mit dieser Erkenntnis kann nun in Anlehnung an [gsm 03, 3gp 04, Maea 04, RuKr 03] eine Definition für
LBSs gegeben werden, die den hier geforderten Ansprüchen genügt:
Ein Location-based Service ist ein Dienst, dessen Initiierung und/oder Ausführung Ortsinformationen relevanter Entitäten nutzt.
Eine Entität wird in diesem Zusammenhang als relevant bzgl. einer Aufgabe bezeichnet, wenn ihr örtlicher
Zustand den Ablauf der Aufgabe beeinflusst (vgl. [StLP 03]). Der örtliche Zustand einer Entität wird durch
Ortsinformationen beschrieben und ist ein wesentlicher Bestandteil der Initiierung und/oder Ausführung
des Dienstes.
Angelehnt an Deys Definition von Kontext [DeAb 99] sind Ortsinformationen alle Informationen, die dazu
genutzt werden können, um die örtliche Situation einer Entität zu beschreiben. Dazu zählen neben den
bereits angesprochenen primären Ortsinformationen Position und Ausrichtung, sekundäre oder abgeleitete
Ortsinformationen wie Geschwindigkeit und Beschleunigung (vgl. [Klat 04, KLEC 03]).
Beispiele für LBSs findet man in der Verkehrstelematik, im Flottenmanagement und in der Logistik, im
Bereich mobiler Spiele, im mobilen Marketing (mCommerce und mAdvertising), bei Mautsystemen und
in einer Vielzahl weiterer Bereiche. Um einige konkrete Beispiele zu nennen, ist in Deutschland seit 2004
ein ortsbasiertes Mautsystem für Lastwagen in Funktion, das eine Gebührenerhebung abhängig von der
tatsächlich erbrachten Fahrleistung ermöglicht (vgl. [tol ]). Ein anderes Beispiel ist der TAXI-Service des
Mobilfunkanbieters O2 [o2 ]. Dieser verbindet einen Anruf an eine global gültige Telefonnummer direkt
zu einer ortsnahen Taxizentrale. Ein Beispiel für ein mobiles Spiel ist das japanische Community-Spiel
MOGI [mog ]. Jeder Spieler von MOGI muss innerhalb eines Stadtgebietes virtuelle Gegenstände finden.
Ziel ist es bestimmte Kollektionen der Gegenstände zu sammeln. Auf dem Display des mobilen Endgerätes
sehen die Spieler ihre eigene Position, die virtuellen Schätze, sowie die Positionen andere Mitspieler.
Die Zahl der real eingesetzten LBSs zeigte in den vergangenen Jahren ein stetiges aber langsames Wachstum. Den Zusatz der Killer Applikation“, wie LBSs in der Literatur desöfteren betitelt werden, haben sie
”
noch lange nicht erlangt.
2.2.3
Navigationsdienste
Die in Abbildung 2.2 dargestellten Beispiele zeigen LBSs, die sich anhand der Ortsbasiertheit in Initiierung und Ausführung unterscheiden. Ein Beispiel für Dienste, die sich durch ortsbasierte Initiierung sowie
ortsbasierte Ausführung auszeichnen können, sind Navigationsdienste.
Navigationsdienste sind Dienste, die den Nutzer bei der Planung und Entscheidung für die zielgerichtete
14
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
Fortbewegung vor allem im mittelbaren Umfeld des Dienstnutzers unterstützen. Dazu stellen Navigationsdienste dem Nutzer Informationen bereit, mit deren Hilfe er von seinem Standort über eine bestimmte
Route zu einem Zielort gelangt, so genannte Navigationsinformationen. Diese Informationen sollen das
Unwissen des Dienstnutzers über seinen aktuellen Aufenthaltsort und den weiteren Routenverlauf kompensieren. Sie können in verschiedensten grafischen, textuellen oder verbalen Darstellungsformen dem
Nutzer präsentiert werden. Im weiteren Sinne werden unter Navigationsdiensten auch Dienste verstanden,
mit der Aufgabe dem Dienstnutzer Informationen über die verschiedenen Ziele und Routen zu diesen Zielen zur Verfügung zu stellen, sowie weiterführende Dienste, wie die Suche nach Points-Of-Interest (PoI)
[PARA 02]. Navigationsdienste im weiteren Sinne beinhalten oft auch Funktionen, die eigentlich Routendiensten zugeschrieben werden. Dazu zählen Aufgaben wie die Betrachtung, die Bearbeitung und die
Akquisition von Routen. Eine genauere Analyse von Routendiensten erfolgt später in diesem Kapitel.
Aufgabe der Navigationsdienste im engeren Sinne ist es demnach, den Nutzer durch qualitativ hochwertige deklarative Navigationsinformationen bei der Wegfindung zu unterstützen. Ein Aspekt, um Navigationsinformationen als qualitativ hochwertig für das subjektive Empfinden einzustufen, ist die zeitliche
Komponente des Auftretens der Navigationsinformationen. Navigationsinformationen sollten immer dann
zugestellt werden, wenn der Nutzer den größtmöglichen Nutzen daraus ziehen kann. Dazu darf der Nutzer
einerseits keiner ständigen Informationsflut ausgesetzt sein und andererseits nicht bei Bedarf nach Navigationsinformationen im Stich gelassen werden. Entscheidend für den richtigen Zeitpunkt der Zustellung
sind die Ortsinformationen des Dienstnutzers. Navigationsinformationen sind dann sinnvoll, wenn sich der
Nutzer an einer Position befindet, an der er eine Richtungsänderung durchführen muss, wobei alternative
Richtungen möglich wären.
In dieser Situation kann der Nutzer selbst die Dienstausführung starten und somit Navigationsinformationen aktiv anfordern. Der Nutzer tritt damit in die Rolle des Dienstinitiierers. Das Interaktionsmuster
entspricht den Location-based Pull-Services. Der Nutzer fragt aktiv nach der Unterstützung durch den Navigationsdienst. Er wird den Dienst dann anstoßen, wenn er eine Entscheidung über seine weitere Bewegung treffen muss oder möchte. Innerhalb von Straßennetzen werden diese Zustände an Straßenkreuzungen
eintreten. Um keinen Abbiegevorgang zu verpassen, muss er im Grunde genommen an jeder Straßenkreuzung die Dienstausführung anstoßen, obwohl viele dieser Straßenkreuzungen keine Änderung der Bewegungsrichtung nach sich ziehen. Der Dienst wird also weitaus öfter initiiert als dies nötig wäre. Aus der
unnötigen Dienstinitiierung folgt die Zustellung von Navigationsinformationen, die keine Richtungsänderung beschreiben. Weitaus komplexer wird die Nutzerinitiierung außerhalb von Straßennetzen. Hier kann
der Nutzer nicht mehr an seiner physischen Umgebung erkennen, wann eine Dienstinitiierung auszulösen
ist.
Vor allem für diese Umgebungen, aber auch für straßengebundene Umgebungen, ist der Einsatz von
Dienstinitiierungen auch ohne Einwirkung des Nutzers unumgänglich. Dies führt zu Location-based PushServices. Die Location-Triggered Actions stoßen hierbei bei Eintreten von Zuständen, an denen eine
Dienstnutzung als sinnvoll erscheint, die Dienstausführung an. Durch geschickte Wahl der Initiierungsvorschriften werden nur genau dann Navigationsinformationen zugestellt, wenn der Nutzer den größtmöglichen Nutzen daraus zieht. Das bedeutet, dass eine Dienstinitiierung genau dann durchgeführt wird, wenn
der Nutzer eine Richtungsänderung einleiten muss, wobei eine alternative Richtung möglich wäre. Die
Komplexität der automatischen Dienstinitiierung ergibt sich aus der Spezifikation der Initiierungsvorschrift. Diese kann sich vor allem bei Hinzunahme diverser Einflussgrößen und Verknüpfungen dieser
Einflussgrößen stark verkomplizieren.
Im Bereich der LBSs handelt es sich bei den maßgeblichen Einflussgrößen um Ortsinformationen. Prinzipiell können aber auch andere Informationen in der Dienstinitiierung beteiligt sein. Solange es jedoch
nicht möglich ist, die Gedanken des Nutzers zu lesen, können die Initiierungsvorschriften keine Initiierung
anhand der spontanen Bedürfnisse des Nutzers nach Navigationsinformationen durchführen. Deshalb sollte zusätzlich zum Push-Interaktionsmuster auch ein Pull-basierter Ansatz verwirklicht werden. Dadurch
kann der Nutzer, wann immer er das Bedürfnis verspürt, Navigationsinformationen anzufordern, aktiv die
Dienstinitiierung ansteuern. Desweiteren kann es vorkommen, dass eine automatische Initiierung nicht einsetzbar ist, zum Beispiel wenn keine Ortsinformationen des Nutzers zur Verfügung stehen. In diesem Fall
muss es möglich, den Dienst durch den Nutzer zu initiieren. Pull-Interaktionen dieser Art werden derzeit
von einigen kommerziellen mobilen Navigationsdiensten eingesetzt (z.B. von [b2m , o2 , jam ]). Diese Arbeit bezieht sich jedoch nur auf Location-based Push-Services.
2.2. MOBILE NAVIGATIONSDIENSTE
15
Ortsinformationen können aber nicht nur für die ortsabhängige Initiierung eingesetzt werden. Ursprünglich sind sie vor allem in der Dienstausführung von Interesse. Dienste wie der Restaurant-Finder, der TAXIService, der ortsbasierte Wetterwarndienst nutzen innerhalb der Dienstausführung, d.h. bei der eigentlichen
Mehrwertgenerierung, Ortsinformationen, um den Dienst den örtlichen Nutzerbedürfnissen anzupassen
(wie eben genannte Beispiele) oder gar eine ganz neue Art von Diensten anzubieten. Ein Dienst, der ohne Ortsinformationen in der Dienstausführung nicht denkbar ist, ist der Navigationsdienst. Erst durch die
Möglichkeit Ortsinformationen innerhalb von Diensten zu nutzen, ergeben sich die Voraussetzungen für
Navigationsdienste.
Innerhalb der Ausführung von Navigationsdiensten werden Ortsinformationen dazu eingesetzt, die aktuelle
Position des Nutzers festzustellen, um ihm anhand der Route Navigationsinformationen für seine zukünftige Bewegungsrichtung zu liefern. Gegebenenfalls können sich diese Ortsinformationen von den Ortsinformationen, die zur Initiierung nötig waren, unterscheiden. In der Navigation ist dies zum Beispiel dadurch
gegeben, dass zur Initiierung hauptsächlich Positionsinformationen zum Einsatz kommen, die Ausführung
aber zusätzliche Ortsinformationen wie Blickrichtung oder Bewegungsrichtung nutzen kann, um die Navigationsinformation daran anzupassen.
Neben der zeitlichen Komponente, die für das subjektive Empfinden der Navigationsinformationen eine
Rolle spielt, ist die inhaltliche Komponente der Information der zweite entscheidende Aspekt für qualitativ hochwertige Navigationsinformationen. Dies spiegelt sich in der Zeit der Aufnahme der Informationen
und der Verarbeitungszeit wider (vgl. [BKK 01, Kray 03]). Die Aufnahmezeit ist das Zeitintervall, das der
Nutzer benötigt, um die dargestellten Informationen zu erkennen und wahrzunehmen, und die Verarbeitungszeit entspricht dem Zeitintervall für das Verstehen der aufgenommen Informationen.
Vergleicht man grafische, verbale und textuelle Navigationsinformationen anhand dieser Zeiten, wird folgendes Resultat erzielt. Die Aufnahmezeit für grafische Navigationsinformationen hängt stark vom Detailgrad der Grafik ab. Einfache Pfeildarstellungen, die aus einem einzigen Pfeil bestehen, können sehr schnell
aufgenommen werden. Je mehr Informationen zusätzlich in der Grafik enthalten sind (Windrose, Straßennamen, Straßen, Geländeformen, etc), desto länger wird die Aufnahmezeit. Verbale und textuelle Navigationsinformationen haben eine relativ ähnliche Aufnahmezeit, beziehen sich aber auf unterschiedliche Sinne.
Für sie gilt ebenfalls, dass die Aufnahmezeit steigt, je mehr Details enthalten sind. Die Verarbeitungszeit
grafischer Navigationsinformationen hängt stark von den dargestellten Informationen ab und inwieweit der
Nutzer mit der Informationsdarstellung vertraut ist. So kann ein durchschnittlicher Nutzer egozentrische
Pfeildarstellungen zur Bewegungsrichtung leicht verarbeiten. In der allozentrischen Perspektive wird bei
einem durchschnittlichen Nutzer jedoch weit mehr an Verarbeitungszeit benötigt. Für textuelle und verbale
Navigationsinformationen hängt die Verarbeitungszeit ebenso wesentlich von der Perspektive ab. Durch
die egozentrische Perspektive referenziert zur Bewegungsrichtung des Nutzers kann die Verarbeitungszeit
im Gegensatz zur allozentrischen Perspektive signifikant reduziert werden.
Welche der Darstellungsformen die geringsten Aufnahme- und Verarbeitungszeiten aufweist, hängt stark
vom Kontext des Einsatzes ab. Vor allem die Art der Fortbewegung, die Fähigkeiten und Einschränkungen
des Nutzers und äußere Einflüsse, wie die Sonneneinstrahlung auf das Display oder die Geräuschkulisse
spielen eine entscheidende Rolle in der Bewertung. Insgesamt gilt: Je hochwertiger die Navigationsinformationen sind, desto geringer ist die Aufnahmezeit und die Verarbeitungszeit für den Nutzer. Diese Zeiten
können natürlich von Nutzer zu Nutzer bzw. von Kontext zu Kontext unterschiedlich ausfallen.
Zur Bereitstellung der Navigationsinformationen übernehmen Navigationsdienste die Teilprozesse Ortung,
Routenführung und Abbildung der Wegfindung. Teilergebnisse (z.B. Ortsinformationen der Ortung) sind
dabei für den Nutzer nicht von Interesse. Ihn interessiert letztendlich nur das Gesamtergebnis aller drei Teilprozesse, die Navigationsinformation. Manche Navigationsdienste lassen einzelne Teilprozesse der Navigation außen vor. Diese müssen dann vom Nutzer übernommen werden. Wird beispielsweise keine Ortung
implementiert, muss der Nutzer manuell Ortsinformationen in die Navigation einbringen. Andere Navigationsdienste (besser als Ortungsdienst bezeichnet) liefern nur Ortsinformationen, die der Nutzer dann für
die Routenführung und Umsetzung einsetzen kann. Dazu benutzt er zum Beispiel eine physische Karte und
bestimmt aus den Ortsinformationen die in Zukunft einzuschlagende Richtung. Auch der letzte Teilprozess
der Navigation, die Abbildung der zukünftigen Bewegungsrichtung auf die umgebende Realität, wird von
vielen Navigationsdiensten kaum oder gar nicht realisiert. Oft werden dem Nutzer nur abstrakte Routeninformationen präsentiert, deren Abbildung in die Realität von ihm selbst übernommen werden muss.
Ein wesentlicher Bestandteil der Wegfindung, der innerhalb aller drei Teilprozesse in verschiedenen For-
16
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
men zum Einsatz kommt, sind Routen. Obwohl der Begriff der Route jedem bekannt sein dürfte, werden
darunter oft die unterschiedlichsten Dinge verstanden. Im Folgenden wird deshalb anhand einer abstrakten
Routenbeschreibung (angelehnt an [Klip 03]) der Begriff der Route definiert.
Routenbeschreibungen
Im vorigen Kapitel wurde bereits eine Routenbeschreibung basierend auf einer Landkarte angesprochen.
Während diese Darstellung für den Menschen gut verständlich und praktisch einsetzbar ist, können
Routendienste und Navigationsdienste mit dieser Darstellung vorerst wenig anfangen. Ist es aber möglich
aus dem Kartenmaterial eindeutige Positionsinformationen entnehmen zu können (z.B. durch georeferenziertes Kartenmaterial) sind die Routeninformationen auch für Routen- und Navigationsdienste nutzbar
(vgl. Anhang A).
Die für die Navigation wesentlichen Inhalte von Karten (als Abbildung der Realität) sind Pfade. Nach
[Mont ] sind Pfade lineare, physische Gegebenheiten, die zur Fortbewegung genutzt werden. Dazu
zählen Wege, Straßen, Autobahnen, etc. Pfade sind ungebunden und besitzen keinen festen Anfangsbzw. Endpunkt. Demgegenüber definiert [Mont ] Routen als lineare Bewegungsmuster. Diese Bewegungsmuster können mit den Pfaden übereinstimmen, müssen aber nicht. Routen sind gebunden und
besitzen einen Anfangs- (Start) und einen Endpunkt (Ziel). Durch Aneinanderreihen von Pfaden erhält
man ein Pfadnetzwerk (vgl. [Klip 03]). Alle Punkte dieses Pfadnetzwerkes, an denen sich mindestens
drei Pfade berühren, nennt man Kreuzungspunkte. Verläuft eine Route über einen Kreuzungspunkt, so
wird dieser Kreuzungspunkt als Entscheidungspunkt (oder Decision Points (DP) [Klip 03] oder Place
[WKBH 00]) bezeichnet. Entscheidungspunkte entsprechen also den Punkten der Route, an denen eine
Richtungsänderung möglich ist, ohne das Pfadnetzwerk zu verlassen. [Klip 03] unterscheidet desweiteren
Entscheidungspunkte daran, ob an ihnen eine Richtungsänderung durchgeführt wird (DP + ) oder nicht
(DP − ). DP + -Entscheidungspunkte werden in dieser Arbeit als Aktionspunkte bezeichnet. Die Menge
der Aktionspunkte ist eine Teilmenge der Menge der Entscheidungspunkte.
Eine Route ergibt sich demnach aus einer geordneten Liste an Entscheidungspunkten DP , wobei jedes
Element aus DP = {dp1 , ..., dpn } einen eindeutigen Identifikator und eine Menge an möglichen
Richtungen {d1 , ..., dk } mit k > 2 definiert. Für jeden Entscheidungspunkt steht zusätzlich die Richtung
do ∈ {f1 , ..., dk }, mit der der Entscheidungspunkt verlassen wird, fest. Die Liste A ⊂ DP der Aktionspunkte erhält man durch Selektion der Liste aller Entscheidungspunkte mit der Selektionsvorschrift
di 6= do , wobei di ∈ {d1 , ..., dk } die Richtung spezifiziert, mit der der Entscheidungspunkt betreten wird.
Abbildung 2.3 zeigt ein Pfadnetzwerk mit einer darauf definierten Route. P1 stellt den Startpunkt, P11
den Zielpunkt der Route dar. Das Pfadnetzwerk enthält 8 Kreuzungspunkte (P2 , P3 , P4 , P6 , P7 , P8 , P9
und P11 ), wobei von diesen 8 Kreuzungspunkten 4 Entscheidungspunkte (P2 , P3 , P8 und P7 ) sind. Die 4
Entscheidungspunkte beinhalten 3 Aktionspunkte (P2 , P8 und P7 ).
Prinzipiell sind nur Aktionspunkte maßgeblich für die Navigation, da diese die relevanten Richtungsänderungen enthalten. Unterstützend können natürlich auch alle Entscheidungspunkte herangezogen werden.
Eine ausreichende Routenbeschreibung innerhalb eines Pfadnetzwerkes wird demnach durch eine geordnete Liste von Aktionspunkten erreicht. Für jeden Aktionspunkt muss dabei die Position bekannt
sein und ein Hinweis auf die Erreichung des nächsten Aktionspunktes vorliegen. Dieser Hinweis kann
verschiedenste Formen annehmen. Eine Möglichkeit ist die Angabe der Richtung do , die die Richtung
des Austritts aus dem Aktionspunkt spezifiziert. Die Richtungsangabe gibt dabei nicht zwingend die
Richtung des nächsten Aktionspunktes an, sie bestimmt nur die Richtung, die zum nächsten Aktionspunkt
führt. Führt die Richtung beispielsweise auf eine gebogene Straße ohne weitere Aktionspunkte, so ist
die Richtung des nächsten Aktionspunktes ungleich der Richtungsangabe, die der aktuelle Aktionspunkt
liefert (vgl. Aktionspunkt P2 in Abb. 2.3). Die Angabe der Richtung kann sowohl in allozentrischer oder
in egozentrischer Perspektive geschehen. Bei Annahme einer genordeten Abbildung 2.3 wäre eine allozentrische Richtungsangabe zum Beispiel die Richtung Norden“. Eine egozentrische Richtungsangabe
”
zur Bewegungsrichtung als Referenzrichtung stellt zum Beispiel die Richtung Links“ dar. Möglich wären
”
hier natürlich auch Winkelangaben zwischen einer allozentrischen oder egozentrischen Referenzrichtung
17
2.2. MOBILE NAVIGATIONSDIENSTE
P0
P1
P2
P5
P6
P7
P10
P11
P3
P4
P8
P9
P12
Abbildung 2.3: Pfadnetzwerk und Route
und der Austrittsrichtung (vgl. [RöLa 02]).
Anzumerken ist hierzu noch, dass Aktionspunkte nicht zwingend Richtungsangaben als Hinweise liefern
müssen. Denkbar ist zum Beispiel auch, jeden Aktionspunkt mit einer bildlichen Darstellung des nächsten
Aktionspunktes auszustatten. Dadurch erhält man eine Abfolge von Bildern, die die Route beschreibt. Derartige Beschreibungen findet man beispielsweise in Schatzkarten. Aktionspunkte fallen hier ausschließlich
auf Landmarken, wie Berge, Gewässer oder Palmen.
Rollen
Im Bereich der LBSs und im Speziellen bei Navigationsdiensten als ein Repräsentator für LBSs werden von
den beteiligten Parteien verschiedene Rollen angenommen. Rollen beschreiben in diesem Zusammenhang
the named specific behavior of an entity participating in a particular context“ [uml 03]. This allows crea”
”
ting a special perspective on business process“ [CST 04]. Eine Rolle beschreibt demnach ein bestimmtes
Verhalten einer Entität innerhalb eines Geschäftsprozesses. Zwei Rollen traten bereits vermehrt in dieser
Arbeit auf. Diese sind der Dienstnutzer und der Dienstanbieter. In deren Umfeld existieren aber noch einige weitere Rollen wie zum Beispiel Inhalteanbieter verschiedenster Inhalte, Location Provider, Zielobjekte
oder Netzbetreiber (vgl. [gsm 03]). Abbildung 2.4 zeigt diese Rollen und ihre Verbindung mit dem LBS
bzw. Navigationsdienst.
Dienstnutzer und Dienstanbieter
In jedem Dienstumfeld treten mindestens zwei Rollen hervor. Diese sind der Dienstanbieter (Service
Provider), der den LBS bereitstellt und der Dienstnutzer (Requestor), der den angebotenen Dienst nutzt.
Dabei herrscht zwischen Dienstnutzer und Dienstanbieter eine unterschiedliche Informationsverteilung in
Bezug auf die zu bewältigende Aufgabe. Der Dienstnutzer hat wenig oder kein Wissen über seine aktuelle Position und den Routenverlauf und braucht deshalb Unterstützung durch den Navigationsdienst. Der
Dienstanbieter hingegen kann dem Nutzer abhängig von seiner aktuellen Position Navigationsinformationen liefern, die ihm die Wegfindung entlang einer Route erleichtern.
18
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
Requestor
Location
Technology
Provider
LBS
Map Server
Feature
Server
Target
Location Provider
Service
Provider
Route Server
Content Provider
Abbildung 2.4: Rollen im Bereich der LBSs
Inhalteanbieter
Um den LBS anbieten zu können, sind oft neben den eigentlichen Ortsinformationen weitere Informationen
nötig. Sie werden durch Dienste der so genannten Inhalteanbieter (Content Provider) bereitgestellt. Beispiele für derartige Dienste sind nach [Maea 04] Directory Services (z.B. Point-Of-Interest-Informationen),
Location Utility Services (z.B. (Reverse) Geocoding), Route Services (Routenbeschreibungen) und Presentation Services (z.B. Kartenmaterial). Alle diese Beispiele zeichnen sich dadurch aus, dass sie in irgendeiner Art und Weise in Bezug zu Ortsinformationen stehen. Inhalte können aber auch komplett frei
von Ortsinformationen sein. So stellen zum Beispiel Aktienkurse, Telefonnmmern oder Produktkataloge
ortsunabhängige Inhalte dar. Insgesamt gibt es ein breites Spektrum an Inhalten, die für LBSs von Interesse sind. Inhalteanbieter für Navigationsdienste sind zum Beispiel Wettervorhersagedienste oder Directory
Services und der Routendienst mit dem wichtigsten Inhalt, nämlich der Route.
Location Provider
Die Entität, deren Ortsinformationen für den LBS als relevant gelten, nimmt die Rolle eines Zielobjektes
(Target) an. Bezogen auf eine Dienstnutzung kann es ein oder mehrere Zielobjekte geben, je nach Art und
Konfiguration des LBS. Im Falle von Navigationsdiensten gibt es nur ein Zielobjekt, welches in der Regel
mit der Entität des Dienstnutzers übereinstimmt.
Verantwortlich für die Technologie der Ortung ist der so genannte Location Technology Provider. Um die
Ortsinformationen eines Zielobjektes zu bestimmen, gibt es verschiedenste Verfahren. Je nach Ortungsverfahren verfügt nach einer erfolgreichen Ortung entweder der Location Technology Provider oder das
Zielobjekt über die Ortsinformationen (vgl. dazu netz- und endgerätebasierte Ortungsverfahren). Deshalb
werden diese beiden Rollen zusammen durch den Location Provider repräsentiert. Der Location Provider
stellt demnach Ortsinformationen in einem bestimmten Koordinatenreferenzsystem mit einer bestimmten
Genauigkeit und Präzision und einer bestimmten Verzögerung zur Verfügung. Da in dieser Arbeit nicht
auf die spezifischen Eigenheiten der Ortungsverfahren eingegangen wird, stellt der Location Provider die
entscheidende Rolle für die Bestimmung der Ortsinformationen dar. Die Zusammensetzung ergibt sich implizit durch das eingesetzte Ortungsverfahren. Für eine genauere Analyse des Ortungsverfahrens müssen
die Rollen Location Technology Provider und Target detaillierter untersucht werden, um deren Einfluss auf
den Geschäftsprozess der Navigation zu konkretisieren.
2.2. MOBILE NAVIGATIONSDIENSTE
19
Netzbetreiber
Die letzte Rolle, aber keinesfalls weniger wichtig, ist der Netzbetreiber (Network Operator). Der Netzbetreiber ist verantwortlich für die Kommunikation zwischen den beteiligten Rollen. Dabei betreibt er
drahtlose sowie drahtgebunde Netze, die auf verschiedensten Technologien basieren können.
2.2.4
Routendienste
In Verbindung mit Navigationsdiensten ist noch eine weitere Art von Diensten von Interesse. Diese wird
oft als Teil des Navigationsdienstes gesehen, soll aber in dieser Arbeit aufgrund der Aufgabendivergenz
getrennt betrachtet werden. Dabei handelt es sich um Routendienste, die die zur Navigation nötigen Routen bereitstellen. Navigationsdienste der Wegfindung sind zwingend an Routen gebunden und setzen sie
als Basiskonstrukt ein. Jedoch benötigen reine Navigationsdienste keinerlei Funktionalität zur Verwaltung,
Bearbeitung und Erstellung von Routen. Diese Aufgabe wird durch Routendienste erfüllt.
Um für den Navigationsdienst zugreifbar zu sein, werden Routen vom Routendienst an einer Schnittstelle
bereitgestellt. Je nach Anwendungszweck können Routen unterschiedlich beschrieben werden. Beispielsweise können sie, wie bereits dargestellt, aus einer geordneten Liste von Aktionspunkten bestehen. Neben
diesem Beispiel gibt es eine Vielzahl weiterer alternativer Beschreibungsformen. Diese Routenbeschreibungen können entweder statisch abgelegt werden, oder sie werden dynamisch bei jeder Abfrage generiert.
Während statische Routen einmal definiert werden und dann für längere Zeit im Routendienst verweilen,
werden dynamische Routen bei jeder Anfrage neu erstellt.
Sollen dynamische Routen vom Routendienst angefordert werden, muss die Anfrage Informationen über
den Verlauf der Route enthalten. Zumindest müssen Start- und Zielpunkt festgelegt werden. Im Normalfall gibt es eine Vielzahl an Routen, die zwischen Start- und Zielpunkt liegen. Deshalb müssen zusätzlich
zur Angabe von Start- und Zielpunkt noch weitere Einschränkungen getroffen werden, um eine eindeutige
Route liefern zu können. Diese Einschränkungen können zum Beispiel Wegpunkte darstellen. Wegpunkte
definieren Punkte, die auf der Route zwischen Start- und Zielpunkt liegen müssen. Zur dynamischen Generierung der Route muss der Routendienst diese Wegpunkte in die Routenbestimmung mit einbeziehen. Oft
liefert die Angabe von Wegpunkten aber immer noch keine eindeutige Route. Andere oder zusätzliche Einschränkungen sind Angaben zur Länge der Route. Dadurch kann zum Beispiel spezifiziert werden, dass die
Route zwischen 20 und 30 Kilometer lang sein soll, oder dass aus der Menge aller Routen, die den Startmit dem Zielpunkt verbinden (und ggf. Wegpunkte), die Route ausgewählt werden soll, die die kürzeste
Länge besitzt. Für die direkte Bestimmung von Routen mit der kürzesten Länge werden in Pfadnetzwerken oft Algorithmen zum Beispiel von Dijkstra oder Bellmann-Ford eingesetzt (vgl. [Maea 04]). Neben
den Einschränkungen der Länge der Route, existieren noch einige weitere Parameter, die zur Auswahl
eingesetzt werden können. Diese sind beispielsweise die Fahrzeit (z.B. schnellste Route), die Pfadcharakteristika (z.B. Feldwege, Radwege), die Routenumgebung (z.B. im Wald, schöne Aussicht), Eingrenzung
von Regionen (z.B. nur in Bayern), etc. Eine letztendliche Auswahl kann auch durch den Dienstnutzer
selbst erfolgen, der sich durch die gezielte Wahl einer Route aus der Menge aller möglichen Routen die
favorisierte Route aussucht.
Für die dynamische Generierung von Routen innerhalb eines Pfadnetzwerkes werden hohe Anforderungen
an die zugrunde liegenden Daten über das Pfadnetzwerk gestellt. Die Informationen zu allen möglichen
Pfaden mit deren genauer Position und Eigenschaften wie Einbahnstraße, Autobahn, etc. müssen stets korrekt und aktuell sein. Derartige Daten werden zum Beispiel von der Firma NAVTEQ [nav ] vertrieben und
in vielen derzeitigen Navigationsdiensten eingesetzt.
Statische Routen werden einmal generiert und werden dann vom Routendienst über längere Zeit zur
Verfügung gestellt. Ihre Start- und Zielpunkte, Wegpunkte, Länge, Pfadcharakteristika, etc. sind während
ihrer ganzen Lebenszeit fest und können nicht verändert werden. Meist entspricht eine statische Route den
Anforderungen einer Vielzahl an Nutzern. Beispiele sind Stadtbesichtigungsrouten oder Radtouren.
Routendienste für statische Routen brauchen neben der Funktion Routen zu verwalten, auch die Möglichkeit Routen zu erstellen. Dies kann auf verschiedenste Arten geschehen. Bietet der Routendienst auch die
Funktion der dynamischen Routengenerierung an, können dynamisch generierte Routen beispielsweise in
statische Routen umgewandelt werden, um langfristig zur Verfügung zu stehen. Eine andere Möglichkeit
20
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
ist, eine grafische Routenerstellung zu ermöglichen. Durch die sequentielle Wahl von Aktionspunkten innerhalb eines Kartenausschnitts, kann so eine Route generiert werden. Eine weitere Möglichkeit stellt die
automatische Erzeugung durch Befahren der Route dar. Hierbei wird die Route durch eine stetige Ortung
bei der Bewegung erzeugt.
Wie bereits beschrieben werden Routendienste oft in Navigationsdienste integriert. Prinzipiell sind Routendienst und Navigationsdienst aber nicht fest miteinander gekoppelt. Das heißt einerseits, dass es Routendienste ohne Navigationsdienste geben kann und andererseits Navigationsdienste ohne Routendienste. So
kommen zum Beispiel Navigationsdienste, die nicht auf die Wegfindung, sondern auf die Lokomotion ausgerichtet sind, ohne Routendienste aus. Demgegenüber kann ein Routendienst allein zur Speicherung und
Verwaltung von Routen genutzt werden und dadurch keine Inhalte für Navigationsdienste liefern. Navigationsdienst und Routendienst stellen demnach zwei vollkommen unterschiedliche Diensttypen dar. Während
der Navigationsdienst den Nutzer bei der Wegfindung unterstützt, ist die Funktion des Routendienstes, die
Verwaltung, Bearbeitung und Erstellung von Routen.
Dementsprechend können Navigations- und Routendienste auf dem selben Gerät oder aber auch auf unterschiedlichen Geräten angesiedelt werden. Läuft der Routendienst auf dem selben Gerät wie der Navigationsdienst, so spricht man von Onboard-Lösungen (vgl. [Nieb 04, Zieg 04, Hell 04, act ]). Läuft der
Routendienst andererseits auf einem anderen Gerät spricht man von einer so genannten Offboard-Lösung.
Diese Begriffe werden in der Literatur aber auch in anderen Zusammenhängen genutzt. Der Begriff On/Offboard wird zum Beispiel in [PARA 02] verwendet, um die Verteiltheit von einzelnen Komponenten des
Navigationsdienstes auf Geräte auszudrücken. In dieser Arbeit werden die Begriffe Onboard/Offboard im
Zusammenhang mit der Verteiltheit von Navigationsdienst und Routendienst verwendet.
2.3 Demonstrator: MoBiLe
Im Rahmen dieser Arbeit soll ein Prototyp eines mobilen Navigationsdienstes angefertigt werden. Als
Anwendungsgebiet soll das Mountain-Biken dienen. Der Prototyp des Mountain Bike Leaders (MoBiLe)
muss deshalb die Besonderheiten des Mountain-Bike-Sports speziell in Betracht ziehen. Dazu gehört vor
allem der Betrieb auf kleinen Straßen, Feldwegen und Trampelpfaden“ innerhalb bergiger Regionen und
”
große Schwankungen in der Fortbewegungsgeschwindigkeit. Diese Punkte unterscheideen den MoBiLe
wesentlich von der Fußgängernavigation oder der Fahrzeugnavigation.
Dieses Kapitel geht zu allererst auf einige Use-Cases ein, die Anwendungsfälle des Systems demonstrieren
sollen und Einfluss auf die folgenden Kapitel haben. Danach werden aus diesen Use-Cases funktionale
sowie nicht-funktionale Anforderungen an das System abgeleitet.
2.3.1
Anwendungsfälle
Use Case 1: Routenerstellung
Routen, die beim Mountain-Biken Anwendung finden, sind in der Regel statisch. Zur Erstellung dieser
Routen soll es möglich sein, zuhause auf einem stationären Gerät mit großem Display und guten Eingabemöglichkeiten Routen grafisch zu generieren. Dazu präsentiert der Routendienst dem Nutzer einen Kartenausschnitt, dessen Darstellungsbereich, Größe und Vergrößerungsfaktor frei gewählt werden können.
Zusätzlich bietet ihm der Routendienst die Möglichkeit, Aktionspunkte durch Mausklicks zu setzen und
die dort durchzuführenden Richtungsänderungen zu adjustieren. Ein zweites Fenster zeigt ihm die Aktionspunkte und die Richtungsänderungen in der Reihenfolge der Generierung. Innerhalb dieses Fensters
ist es möglich, einzelne Aktionspunkte wieder zu löschen oder deren Richtungsänderung zu verändern.
Wurden alle Aktionspunkte erfolgreich gesetzt, kann die Route im System abgelegt werden. Innerhalb dieses Vorgangs kann der Nutzer zusätzliche Annotationen wie Name oder Schwierigkeitsgrad an die Route
anhängen. Durch das Speichern der Route, kann diese später wieder geladen und weiter bearbeitet werden.
Schließlich ist die Route durch die Veröffentlichung für den Navigationsdienst abrufbar.
2.3. DEMONSTRATOR: MOBILE
21
Use Case 2: Routenauswahl
Durch Starten des Navigationsdienstes auf dem mobilen Endgerät, wird dem Nutzer eine grafische Oberfläche angezeigt, in der er die wesentlichen Einstellungen vornehmen und die Navigation starten kann. Ein
Konfigurationspunkt ist die Auswahl der Route. Zur Routensuche kann der Nutzer die Charakteristika für
die gewünschte Route spezifizieren. Diese sind mindestens der Name der Route, die Region, der Schwierigkeitsgrad und die Länge (absolut oder Intervallangabe). Weitere Charakteristika können Erstellungsdatum
der Routen, Aktualität der Routen (z.B. die innerhalb eines bestimmten Zeitraumes bereits genutzt wurden), oder Nähe zum Aufenthaltsort sein. Wird ein Charakteristikum nicht belegt, so wird dieses nicht zur
Auswahl herangezogen. Das bedeutet, falls keine Einschränkungen zur Route gemacht wurden, werden alle
verfügbaren Routen angezeigt. Zu jeder Route können weitere Informationen eingeblendet werden. Diese
Informationen beinhalten mindestens die Gesamtlänge der Route, den Abfahrtsort, den Schwierigkeitsgrad
und die zu bewältigenden Höhenmeter. Nach der Routenauswahl kann die Navigation direkt gestartet werden. Zuvor kann der Nutzer aber noch in den Einstellungen die favorisierte Darstellungsform wählen und
andere Konfigurationen des MoBiLe durchführen.
Use Case 3: Navigation
Durch Starten der Navigation wird der Nutzer zur Bestätigung der Route und der damit verbundenen Ortung
aufgefordert. Erklärt er sich damit einverstanden, wird die Ortung aktiviert und bei Erreichen des Abfahrtsortes eine erste Navigationsinformation präsentiert. Diese kann aufgrund verschiedener Einflussfaktoren
(Verfügbarkeit von Ortsinformationen, Verbindungsgeschwindigkeit, Nutzerpräferenzen, etc.) unterschiedlich ausfallen. Mögliche Darstellungsformen sind verbale, textuelle oder grafische Präsentationen. Folgt
der Nutzer dieser Navigationsinformation, wird er bei Erreichen des nächsten Aktionspunktes automatisch
über die Richtungsänderung informiert. Diese Navigationsinformation muss zum richtigen Zeitpunkt dem
Nutzer zugestellt werden und soll sich durch geringe Aufnahme- und Verarbeitungszeit auszeichnen. Das
Erreichen des Ziels wird durch eine letzte Meldung bekannt gegeben, bevor sich die Navigation beendet.
2.3.2
Anforderungen
Funktionale Anforderungen
Funktionale Anforderungen ergeben sich aus den oben genannten Anwendungsfällen. Im Wesentlichen
sind diese die Routenerstellung, die Routenauswahl und die Navigation. Während die Routenerstellung
vom Routendienst bereitgestellt wird, werden Routenauswahl und Navigation vom Navigationsdienst dem
Nutzer zur Verfügung gestellt. Obwohl die Routenauswahl im Grunde genommen alleine vom Routendienst
abhängt, soll diese vom Navigationsdienst angeboten werden, der die Routen dann vom Routendienst bezieht. Dies hat folgende Gründe. Der Navigationsdienst verfügt im Gegensatz zum Routendienst über nutzerspezifische Daten für die Routenauswahl, die nicht direkt an den Routendienst weitergeleitet werden
sollten. Dabei handelt es sich zum Beispiel um die Position des Nutzers, die zur Auswahl herangezogen
werden kann. Außerdem kann der Navigationsdienst in Verbindung zu mehreren Routendiensten stehen,
um sein Angebot zu erweitern. Für den Nutzer bleiben so die Anzahl und Funktionalitätsunterschiede der
Routendienste verschattet.
Die funktionalen Anforderungen der drei Anwendungsfälle Routenerstellung, Routenauswahl sowie der
Navigation sind im Folgenden stichpunktartig zusammengefasst. Sie definieren die Funktionalität, die
durch das System bereitgestellt werden soll.
Use Case 1: Routenerstellung
• Grafische Präsentation von Kartenmaterial in verschiedenen Vergrößerungen
• Definition von Aktionspunkten (Position und Richtungsänderung) auf Kartenhintergrund
22
KAPITEL 2. MOBILE NAVIGATIONSDIENSTE
• Löschen von Aktionspunkten
• Ändern von Aktionspunkten (Richtungsänderung)
• Annotation von Informationen wie Name, Schwierigkeitsgrad, Gesamtlänge oder Höhenmeter
• Persistentes Ablegen von Routen
• Laden bestehender Routen und Anzeige vor Kartenhintergrund
• Bereitstellen der Routen für Navigation
Use Case 2: Routenauswahl
• Selektion der Routen anhand vordefinierter Charakteristika
• Detaillierte Anzeige von Routenannotationen
• Auswahl einer Route
Use Case 3: Navigation
• Start- und Unterbrechungsmöglichkeit der Navigation
• Einstellung von favorisierten Darstellungsformen
• Frühzeitige automatische Benachrichtigung über bevorstehende Richtungsänderung an Aktionspunkten
• Geringe Aufnahme- und Verarbeitungszeiten der Navigationsinformationen
• Wiederholung von verpassten Navigationsinformationen
• Benachrichtigung bei Erreichen des Ziels
Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen geben Eigenschaften und Einschränkungen bezüglich der Leistung, Qualität oder Einflussfaktoren technischer, normativer oder kultureller Art. Dabei beziehen sie sich nicht auf
einzelne Funktionen, sondern auf die Funktionalität des kompletten Systems. Im Folgenden werden einige
nicht-funktionale Anforderungen an den MoBiLe-Service aufgezählt und kurz beschrieben:
Nutzbarkeit (Usability)
• Die Bedienung der grafischen Oberfläche soll einfach und klar verständlich sein. Dies gilt sowohl
auf dem stationären wie auf dem mobilen Gerät. Vor allem auf dem mobilen Endgerät muss auf
die Einschränkungen wie dem kleinen Display und den beschränkten Eingabemöglichkeiten geachtet werden. Dazu muss eine intuitive Menüführung existieren, die die Navigation durch die Menüs
anhand weniger Tastendrücke erlaubt.
• Einstellungen, die über längere Zeit konstant bleiben, sollen persistent gespeichert werden, um nicht
jedes mal erneut eingegeben werden zu müssen.
• Darstellungen auf dem mobilen Endgerät, wie zum Beispiel Navigationsinformationen, sollen ohne
Scrollen erkennbar sein. Außerdem sollen sie klar und intuitiv verständlich sein.
2.3. DEMONSTRATOR: MOBILE
23
Reaktionszeit
• Das gesamte System soll geringen Reaktionszeiten unterliegen. Dies betrifft die Subsysteme, sowie die Kommunikationsstruktur zum Datenaustausch zwischen den Subsystemen. Vor allem in der
Navigation führen lange Reaktionszeiten zu einer Verfälschung des Ergebnisses.
Ressourcenverbrauch
• Das mobile Endgerät unterliegt beschränkten Ressourcen bezüglich des Speicherplatzes und der Rechenleistung. Auf dem Endgerät muss deshalb sparsam mit diesen Ressourcen umgegangen werden
und wenn möglich eine Auslagerung der Daten, bzw. Berechnungen, erfolgen.
• Die WAN-Verbindungen zwischen mobilem Endgerät und Infrastruktur sind meist teuer in der Nutzung. Deshalb soll das System sparsam im Einsatz dieser Verbindungen umgehen.
• Der Nutzer besitzt ebenfalls nur eine beschränkte Ressourcenkapazität für die Aufnahme und Verarbeitung von Informationen (kognitive Ressourcen) [BKK 01]. Alle dem Nutzer präsentierten Informationen sollen deshalb so wenig kognitive Ressourcen verbrauchen wie möglich.
Erweiterbarkeit/Substituierbarkeit
• Einzelne Teile des Gesamtsystems sollen leicht ersetzbar sein. So soll zum Beispiel leicht ein anderes
Ortungsverfahren verwendet oder sogar eine andere Applikation innerhalb des LBPSs verwirklicht
werden können. Selbiges gilt für neue Darstellungsformen. Um Abhängigkeiten zu vermeiden, ist
eine geringe Kopplung zwischen Subsystemen nötig.
• Außerdem müssen feste Schnittstellen zwischen Subsystemen bestehen, um diese einfach ersetzen
bzw. erweitern zu können.
Praktikabilität
• Um MoBiLe real einsetzen zu können, dürfen nur existierende Technologien eingesetzt werden. Dies
gilt vor allem für Ortungsverfahren und Kommunikationsverbindungen.
Kapitel 3
Stand der Technik mobiler
Navigationsdienste
Dieses Kapitel ist dem Stand der Technik und Forschung im Bereich der mobilen Navigationsdienste gewidmet. Um einen Überblick über die bestehenden Technologien, sowie bereits existierende Systeme und
Konzepte zu geben, wurden einige Beispiele ausgewählt, an denen Funktionsweisen, Unterschiede, Vorund Nachteile sowie Praktikabilität diskutiert werden. Natürlich ist dies keine vollständige Liste, sondern
beschränkt sich auf die Beispiele, die sich als sehr repräsentativ herausgestellt haben oder sich durch hohe
Relevanz für diese Arbeit auszeichnen.
Das Kapitel beginnt mit verschiedenen Techniken der Ortung und deren Umsetzung in bestehenden Ortungssystemen. Anschließend folgt eine Einführung und Gegenüberstellung offener mobiler Plattformen
und deren Unterstützung für Anforderungen des MoBiLe-Service. Bevor das Kapitel mit einer Beschreibung existierender kommerzieller Navigationssysteme endet, werden einige Forschungsprojekte vorgestellt, die sich mit Themen im Bereich der Navigationsdienste auseinandersetzen.
3.1 Ortungssysteme
Dieses Kapitel gibt einen Einblick in bestehende Ortungssysteme, die zum Zeitpunkt dieser Arbeit mögliche Lösungen für die Bestimmung von Ortsinformationen darstellen. Dazu wird das Kapitel nur kurz auf
den Aufbau, die Funktionsweise und Zweckmäßigkeit dieser Systeme im Bereich der mobilen Navigation
eingehen. Für eine genauere Betrachtung wird auf [gsm 03, DFGS 05, Küpp 05, LPKü 04] verwiesen.
3.1.1
Cell Of Origin
Durch den Aufbau des GSM-Netzes seit Anfang der 90er Jahre besitzt die Bundesrepublik Deutschland
heute eine fast flächendeckende Infrastruktur an Basisstationen (vgl. [gsm ]), die es an beinahe jedem Ort
ermöglicht, Telefonate zu führen oder Daten auszutauschen. Dazu muss sich der Nutzer in unmittelbarer
Nähe zu einer dieser Basisstationen befinden. Jeder Basisstation kann durch ihren Betreiber eine eindeutige
Position zugeordnet werden. Ist der Nutzer an dieser Basisstation eingebucht“, so kann seine Position mit
”
einer Genauigkeit von der maximalen Reichweite der Basisstation, d.h. dem Radius der Zelle, berechnet
werden. Dieses Verfahren, in dem die Position des Nutzers mit der Position der eingebuchten Zelle gleichgesetzt wird, nennt man Cell of Origin oder Cell Identity (vgl. Abb. 3.1 a).
Die Genauigkeit der Positionsbestimmung hängt damit von der Größe der Zelle ab. Eine Zelle des GSMNetzes hat einen maximalen Radius von 35 Kilometern. Damit kann eine Genauigkeit von schlechtestenfalls 35 Kilometern erlangt werden. Wenn überhaupt, sind derart große Zellen nur in sehr ländlichen Regio24
25
3.1. ORTUNGSSYSTEME
a)
b)
c)
d)
Abbildung 3.1: Ortung mittels Cell Identity (a) mit Laufzeitmessung (b) mit AoA (c) mit Laufzeitmessung
und AoA (d)
nen zu finden. Innerhalb von Städten kann in der Regel eine Genauigkeit bis zu 250 Meter erzielt werden.
Dadurch ist in städtischen Gebieten bereits durch dieses einfache Verfahren eine relativ exakte Ortung
möglich. Der Einsatzort des MoBiLe ist aber eher in ländlichen Regionen mit wenig Basisstationen zu sehen. Dadurch können in der Regel nur noch Genauigkeiten im Kilometerbereich erzielt werden. Dies reicht
keinesfalls für die hier angestrebte Navigation aus.
Eine Möglichkeit um die Genauigkeit des CoO-Verfahrens zu verbessern, ist die Betrachtung des Winkels
zwischen Nutzer und Basisstation. Derartige Verfahren sind auch unter dem Namen Angle of Arrival (AoA)
bekannt. In Verbindung mit dem CoO-Verfahren, kann dadurch der Aufenthaltsort des Nutzers weiter eingeschränkt werden.
Das AoA-Verfahren kann auch in GSM-Netzen eingesetzt werden, da hier meist statt omnidirektionalen
Antennen sektorisierte Antennen verwendet werden. Diese strahlen nur einen bestimmten Sektor aus und
sind deshalb nur innerhalb dieses Sektors empfangbar. Kommen sektorisierte Antennen bei der Positionsbestimmung zum Einsatz, so kann die Position des Nutzers auf diesen Sektor eingeschränkt werden (vgl.
Abb. 3.1 c). Im GSM-Netz kann bei der Positionsbestimmung mittels Cell Identity und sektorisierten Antennen eine Genauigkeitssteigerung erzielt werden. Für den Einsatz in Navigationsdiensten ist aber auch
diese Genauigkeit noch nicht akzeptabel.
Ein anderes Vorgehen, um den Aufenthaltsort des Nutzers innerhalb einer Zelle einzugrenzen, ist der Einsatz von Laufzeitmessungen. Hier wird durch Messung der Signallaufzeit zwischen Sender und Empfänger
versucht, Rückschlüsse auf dessen Position ziehen zu können. In Verbindung mit CoO-Verfahren erhält
man somit einen Ring um die Basisstation, in dem sich der Nutzer aufhält (vgl. Abb. 3.1 b).
Im GSM-Netz ist eine ungefähre Signallaufzeit durch den Timing Advance (TA) bestimmbar. Der TA wurde eingeführt, um die Signalverzögerung bei der Datenübertragung zu kompensieren, kann bei der Positionsbestimmung mit dem CoO-Verfahren aber genutzt werden, um den Aufenthaltsort des Nutzers weiter
einzuschränken. Der TA ist in 63 diskrete Werte quantisiert, die bei einer maximalen Zellgröße von 35
km eine Breite von ca. 500 Metern aufweisen. Dadurch kann die Position des Nutzers auf einem Ring um
die Basisstation mit einer Breite von ca. 500 Metern bestimmt werden. Je weiter sich der Nutzer von der
Basisstation wegbewegt, desto ungenauer wird die Positionsbestimmung, da sich die Aufenthaltsfläche des
Nutzers vergrößert. Für die Anwendung in Navigationsdiensten für ländliche Regionen stellt dieses Verfahren deshalb keine akzeptable Lösung dar.
Der Problematik der Laufzeitmessung, kann durch den Einsatz des AoA-Verfahrens entgegengewirkt werden. Durch Abstands- und Winkelmessung zugleich wird der Aufenthaltsort des Nutzers auf ein Ringsegment reduziert (vgl. Abb. 3.1 d). Dadurch kann bei der Anwendung im GSM-Netz je nach Grad der Antennensektorisierung die Genauigkeit weiter gesteigert werden. Obwohl diese beiden Erweiterungen des
26
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
CoO-Verfahrens die Genauigkeit der Positionsbestimmung stark verbessern, reicht dies für den MoBiLeService nicht aus. Vor allem ist es nicht möglich, eine konstante Genauigkeit anzugeben, da die Genauigkeit
des Verfahrens mit höherer Entfernung zur Basisstation zunimmt.
3.1.2
Enhanced Observed Time Difference
Ein Verfahren, das dieser Problematik weniger stark ausgesetzt ist, ist das Enhanced Observed Time Difference (E-OTD) Verfahren. Es ermittelt die Position anhand der hyperbolischen Trilateration. Ähnlich wie
bereits beschrieben basiert E-OTD auf der Messung von Signallaufzeiten. Jedoch steht hier nicht die Signalverzögerung zwischen Senden und Empfangen im Vordergrund, sondern die Differenz zwischen dem
Empfangen von zwei Signalen, die von unterschiedlichen Basisstationen gleichzeitig ausgesandt werden.
Vorteilhaft ist an dieser Strategie, dass die Basisstationen und das zu positionierende Endgerät nicht zeitlich
synchronisiert sein müssen. Es reicht aus, wenn die Basisstationen untereinander synchronisiert sind bzw.
die Asynchronität ermittelbar ist.
Abbildung 3.2: Enhanced Observed Time Difference (E-OTD)
Im praktischen Einsatz funktioniert das E-OTD-Verfahren folgendermaßen. Das Endgerät misst die Zeitdifferenz zwischen dem Eintreffen der Signale zweier Basisstationen. Durch Hinzunahme des Gangunterschieds der Uhren der beiden Basisstationen, der von der Location Measurement Unit (LMU) geliefert
wird, kann nun die Position auf einer Hyperbel, die zwischen den beiden Basisstationen verläuft, berechnet
werden (vgl. Abb. 3.2). Wird dieser Vorgang zu einer dritten Basisstation wiederholt, schneiden sich die
Hyperbeln in einem Punkt, welcher der Position des Endgerätes entspricht.
Mittels des E-OTD-Verfahrens können Genauigkeiten unter 100 Metern erzielt werden. Leider setzt das
Verfahren einerseits eine Erweiterung des Endgerätes und andererseits der bestehenden Infrastruktur (Integration von LMUs) voraus, was hierzulande noch nicht geschehen ist. Außerdem sind zur Positionsbestimmung mindestens drei Basisstationen notwendig, in deren Empfangsbereich sich das Endgerät während der
Positionsbestimmung befindet. In städtischen Regionen stellt dies kein ernsthaftes Problem dar. In ländlichen Regionen ist eine derartige Konstellation jedoch oft rar. Aus diesen Gründen ist die Positionsbestimmung mittels E-OTD leider nicht wie gewünscht einsatzfähig und kommt deshalb für Navigationsdienste
nicht in Frage.
3.1. ORTUNGSSYSTEME
3.1.3
27
Global Positioning System
Das Global Positioning System (GPS) [off b, hof 93, Logs 92, kow , Zogg 02], das auch als NAVigation System with Time And Ranging (NAVSTAR) bekannt ist, ist ein satellitengestütztes Ortungssystem des
Departments of Defense (DoD) der USA. Es wurde ab den 70er Jahren für den militärischen Gebrauch
entwickelt, ist aber seit den 80er Jahren auch für den zivilen Gebrauch, jedoch nur unter Einschränkungen, zugelassen. Die zivile Nutzung beschränkt sich auf den so genannten Standard Positioning Service
(SPS). Für die militärische Nutzung existiert zusätzlich der Precise Positioning Service (PPS), der eine
wesentlich höhere Genauigkeit als der SPS aufweist, aber nur durch militärische Empfangsgeräte wahrgenommen wird. Die Positionsbestimmung bei GPS basiert auf der satellitenbasierten Trilateration, also
der Abstandsmessung zu mindestens drei Satelliten, deren Position im Raum eindeutig bestimmbar ist. Zur
letztendlichen Positionsbestimmung ist ein vierter Satellit notwendig, um den Gangunterschied zwischen
den Uhren der Satelliten und des Empfängers auszugleichen.
GPS setzt sich aus drei Segmenten zusammen: dem Nutzersegment (User Segment), dem Raumsegment
(Space Segment) und dem Kontroll- und Steuerungssegment (Control Segment). Das Raumsegment besteht zum Zeitpunkt dieser Arbeit aus 29 Satelliten (vgl. [off b]). Prinzipiell reichen aber schon 24 Satelliten aus, um das System ordnungsgemäß zu betreiben. Jeweils vier Satelliten befinden sich auf einem der
sechs kreisförmigen Medium Earth Orbits (MEO). Jeder dieser Orbits hat einen Inklinationswinkel von 55
◦
und ist um 60 ◦ zu seinen Nachbarorbits versetzt. Der Radius des Orbits beträgt 26.560 km. Folglich
beträgt der Abstand eines Satelliten zur Erdoberfläche 20.200 km und jeder Satellit braucht dadurch knapp
12 Stunden, um die Erde zu umrunden.
Jeder der derzeit 17 Typ-II- und Typ-IIA-Satelliten ist mit zwei Cäsium- und zwei Rubidium-Atomuhren
ausgestattet. Die neueren Satelliten des Typs-IIR (derzeit 12) haben drei Rubidium-Atomuhren. Durch die
äußerst exakten Uhren kann die Laufzeit eines elektromagnetischen Signals, welches von den Satelliten
ausgestrahlt und vom GPS-Empfänger wahrgenommen wird, gemessen werden. Da die Geschwindigkeit
des Signals relativ genau bestimmbar ist (annähernd Lichtgeschwindigkeit), wird eine Berechnung des Abstandes zwischen Satellit und Empfänger möglich.
Dazu sendet jeder Satellit auf der L1- (1575,42 MHz) und der L2-Frequenz (1227,60 MHz) ein elektromagnetisches Signal aus. Die L2-Frequenz wird ausschließlich für PPS genutzt. Die L1-Frequenz wird sowohl
für PPS als auch für SPS eingesetzt. Der Mehrfachzugriff der 29 Satelliten auf die L1- bzw. L2-Trägerfrequenz erfolgt mittels Code Division Multiple Access (CDMA). Um einerseits die Signale unterschiedlicher
Satelliten und andererseits überlagerte Signale, die durch die Mehrwegeausbreitung entstanden sind, exakt
trennen zu können, werden als Pseudo-Random-Noise-Codes (PRN-Codes) Gold-Codes eingesetzt, da diese sowohl eine gute Kreuzkorrelation als auch eine gute Autokorrelation aufweisen. Die PRN-Codes für
SPS sind auch unter dem Namen Coarse Acquisition Code (C/A-Code) bekannt und haben je eine Länge
von 1023 Chips. Der C/A-Code wird mit einer Datenrate von 1,023 MBit/s übertragen und wiederholt sich
so jede Millisekunde. Der P-Code (Code des PPS) hat eine Länge von über 2 · 1014 Chips und wird mit
einer Datenrate von 10,23 MBit/s übertragen. Folglich liegt die Wiederholungsrate des P-Codes bei ca. 266
Tagen.
Die Daten, die mittels dieser Codes gespreizt werden, sind unter anderem Uhrenkorrekturwerte, genauere
Informationen zu den Bahndaten des sendenden Satelliten (Ephemeriden) und grobe Informationen zu den
Bahndaten aller Satelliten (Almanach). Diese Nutzdaten werden mit einer Datenrate von 50 Bit/s gesendet.
Insgesamt werden also die Nutzdaten eines Satelliten mit dem PRN-Code gespreizt und dann auf die L1Trägerwelle mittels Quadrature Phase Shift Keying (QPSK) aufmoduliert. Das übertragende Signal enthält
damit die in Abbildung 3.3 dargestellten Informationen.
Das Nutzersegment beinhaltet alle Empfangsgeräte sowohl für SPS als auch für PPS. Empfangsgeräte
unterscheiden sich einerseits durch ihre Ausmaße, Funktionalität, Ausstattung, Leistungsaufnahme, etc.,
andererseits haben verschiedene Geräte auch meist Unterschiede in der Genauigkeit und der Präzision der
Positionsbestimmung, der Verzögerung für die erste Positionsbestimmung (Time-To-First-Fix (TTFF)), der
minimalen Empfangsstärke, der Anzahl der parallel empfangbaren Satelliten, etc.
Um nun die Entfernung zwischen Satellit und Empfänger im SPS zu bestimmen, muss die Zeitdifferenz
zwischen Senden und Empfangen des Signals berechnet werden, um daraus Rückschlüsse auf den Abstand
führen zu können. Das Signal trifft aufgrund der endlichen Signalausbreitungsgeschwindigkeit mit einer
28
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Nutzdaten
x dBm
Gespreiztes Signal
y dBm
Moduliertes Signal
z dBm
Abbildung 3.3: Aufbau des GPS-Signals
bestimmten Verzögerung beim Empfänger ein. Durch die gute Kreuzkorrelation der PRN-Codes kann aus
dem Signal eindeutig das spezielle Signal des sendenden Satelliten herausgefiltert werden. Durch die gute
Autokorrelation der PRN-Codes kann die Verzögerung des Signaleintreffens bestimmt werden. Je nachdem, wie genau der Prozess der Autokorrelation durchgeführt werden kann, variiert die Genauigkeit der
Positionsbestimmung. Arbeitet der Prozess beispielsweise nur auf ganze Chiplängen, kann eine maximale Genauigkeit von ca. 300 Metern (∼
= Lichtgeschwindigkeit (≈ 3 · 105 m/ms) · Zeitdauer eines Chips
1
( 1023 ms)) erreicht werden. Dies entspricht der Länge eines einzelnen Chips. Gängige GPS-Empfänger
führen den Autokorrelationsprozess auf Bruchteile von Chips aus und können so wesentlich höhere Genauigkeiten erreichen. Zusätzlich kann zur Positionsbestimmung die Phasenverschiebung des modulierten
Signals herangezogen werden, um die Genauigkeit weiter zu steigern.
Aus dem Resultat dieses Prozesses, den so genannten Pseudo Ranges zu mindestens drei Satelliten, muss
nun die Position des Empfängers bestimmt werden. Dazu sind weitere Informationen nötig, die in den
Nutzdaten enthalten sind. Diese sind die Uhrenkorrekturwerte, die Ephemeriden und der Almanach. Unter
Berücksichtigung dieser Nutzdaten kann aus den Pseudo Ranges die reale Position des Nutzers bestimmt
werden.
Das Kontroll- und Steuerungssegment besteht aus einer Master Control Station in Colorado, USA, und
vier weiteren Monitorstationen auf Hawaii, den Ascension Islands, Diego Garcia und Kwajalein. Die Monitorstationen erheben Messdaten und senden sie an die Master Control Station, die diese Daten auswertet,
gegebenenfalls Fehlfunktionen feststellt und dann Korrekturdaten mit Hilfe der Monitorstationen an die
Satelliten sendet.
DGPS
Das Signal, das von den Satelliten ausgestrahlt wird, muss auf dem Weg zur Erde verschiedene Luftschichten durchqueren. Durch die ionosphärische und troposphärische Refraktion wird das Signal je nach Grad
der Ionisierung unterschiedlich stark abgebremst und abgelenkt. Dem Signal kann deshalb keine konstante
Geschwindigkeit und zurückgelegte Distanz zugeordnet werden. Durch differentielle Korrektur wird versucht, diese Unterschiede durch Korrekturwerte auszugleichen. Dazu werden Abweichungen der Messwerte von realen Positionen anderer Empfänger benutzt. Je nachdem, ob die Korrekturdaten von Bodenstationen oder Satelliten gesendet werden, spricht man von Land-based DGPS oder Satellite Based Augmentation System (SBAS). Existierende SBAS sind das Wide Area Augmentation System (WAAS), das speziell auf
Nordamerika ausgerichtet ist, der European Geostationary Navigation Overlay Service (EGNOS) innerhalb
Europas und das japanische Multifunctional Transport Satellite-based Augmentation System (MSAS).
A-GPS
Das eintreffende Signal kann vom Empfänger auf drei verschiedenen Ebenen betrachtet werden (vgl. Abb.
3.3). Während das gespreizte Signal bereits bei einer Signalstärke von y dBm entspreizt werden kann,
3.1. ORTUNGSSYSTEME
29
sind Nutzdaten erst ab einer Signalstärke von x dBm 1 erkennbar. Außerdem ist die Übertragungsrate der
Nutzdaten mit 50 Bit/s sehr gering und eine sequenzielle Übertragung aller Nutzdaten würde deshalb bis
zu 12,5 Minuten in Anspruch nehmen. An diesen beiden Problemen greift das so genannte Assisted-GPS
(A-GPS) an. Durch das Bereitstellen von Assistenzdaten, die im Wesentlichen die Nutzdaten enthalten,
werden folgende Vorteile erzielt (vgl. [glo a, Chun 03]:
1. Die TTFF wird drastisch herabgesetzt, da die Nutzdaten nicht über die Satelliten übertragen werden
müssen und weitere Informationen wie Näherungswerte der aktuellen Position bereits erste Anhaltspunkte für den First Fix“ geben.
”
2. Die Verfügbarkeit des Systems wird erhöht, da bereits eine Signalstärke von y dBm ausreicht, um
das Signal zu entspreizen. Eine Dekodierung der Nutzdaten ist dazu nicht mehr nötig.
3. Die Genauigkeit der Positionsbestimmung wird verbessert, da auch Satelliten zur Positionsbestimmung herangezogen werden können, die ohne Assistenzdaten nicht nutzbar wären.
4. Der Energieverbrauch kann verringert werden, da Assistenzdaten nicht dekodiert werden müssen
und die rechenintensive TTFF herabgesetzt wird.
In den Assistenzdaten sind unter anderem die Ephemeriden, Doppler-Frequenzen, Uhrzeit und Näherungswerte der aktuellen Position enthalten. Sie können beispielsweise über Kanäle der Mobilkommunikationsnetze (z.B. SMS-Broadcast, GPRS, etc.) oder spezielle Broadcastnetze bereitgestellt werden. Über diese
Kanäle werden sie vom Endgerät empfangen und zur Positionsberechnung eingesetzt. Alternativ zu diesem Verfahren, bekannt als mobile-based A-GPS, kann die Positionsberechnung auch extern, z.B. in der
Mobilkommunikationsinfrastruktur, durchgeführt werden. Dieses Verfahren ist bekannt als mobile-assisted
A-GPS und hat den Vorteil, dass komplexe Operationen der Positionsberechnung nicht mehr auf dem Endgerät stattfinden und dadurch vor allem der Energieverbrauch weiter sinkt. Nachteilig ist, dass keine autonome Positionsbestimmung auf dem GPS-Empfänger mehr möglich ist.
3.1.4
Weitere Ortungsverfahren und Klassifikationen
Die hier vorgestellten Ortungsverfahren stellen nur eine repräsentative Teilmenge aller Ortungsverfahren
dar. Weitere Ortungsverfahren sind zum Beispiel Uplink Time Difference of Arrival (UL-TDoA), Observed
Time Difference of Arrival (OTDoA), Fingerprinting (z.B. mit Wireless LAN), Scene Analysis, Proximity
Sensing (z.B. mit RFID-Tags) oder auch Kombinationen dieser Verfahren.
Kategorien dieser Ortungsverfahren lassen sich anhand verschiedenster Gesichtspunkte bilden. Beispielsweise werden Ortungsverfahren prinzipiell nach ihrer Anwendbarkeit innerhalb (Indoor) und außerhalb
(Outdoor) von Gebäuden unterschieden. Ein Beispiel für Outdoor-Ortungsverfahren ist das herkömmliche
GPS. Ein Indoor-Verfahren wird zum Beispiel bei der Ortung mittels RFID-Tags eingesetzt. Einige Ortungsverfahren können aber sowohl innerhalb als auch außerhalb von Gebäuden eingesetzt werden. Dazu
zählen (bis zu einem gewissen Maße) Ortungsverfahren von Mobilfunknetzen oder A-GPS.
Die Differenzierung von Indoor- und Outdoor-Ortungsverfahren hängt wesentlich vom eingesetzten Observable (vgl. Kapitel 2.1) ab. Beispiele für Observables sind Ultraschall- oder Infrarotwellen, Signale des
Mobilfunks (z.B. aus GSM oder UMTS) oder Signale des 2,4 GHz ISM-Bandes (z.B. Wireless LAN oder
Bluetooth). Je nach Wellenlänge werden diese Signale von festen Gegenständen unterschiedlich stark reflektiert und können so mehr oder weniger weit in Gebäude eindringen. Infrarotwellen werden zum Beispiel
von festen Gegenständen vollständig reflektiert, Funkwellen des 2,4 GHz ISM-Bandes hingegen können
feste Gegenstände teilweise durchdringen.
Desweiteren unterscheiden sich die verschiedenen Ortungsverfahren in der Art, wie die Signale zur Bestimmung der Ortsinformationen eingesetzt werden. Eine einfache Art basiert auf der Signalabschwächung. Die
Entscheidungsregel, ob ein Signal empfangbar ist oder nicht, reicht hier aus, um die ungefähre Position zu
bestimmen. Dieses Art wird beispielsweise beim CoO-Verfahren eingesetzt. Desweiteren kann dabei der
Grad der Signalabschwächung bei der Bestimmung der Ortsinformationen herangezogen werden. Meist
ist diese Art aufgrund der Mehrwegeausbreitung nicht sinnvoll einsetzbar. Eine weitere Möglichkeit ist die
1 Die
Werte für x und y sind von Empfänger zu Empfänger unterschiedlich und wurden deshalb durch Variablen ausgedrückt
30
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Laufzeitmessung bzw. Laufzeitunterschiedsmessung des Signals. Letzteres wird beispielsweise bei E-OTD
eingesetzt.
Diese Art des Signaleinsatzes kann für unterschiedliche Methodiken der Ortung verwendet werden. Hier
sind vor allem die Trilateration, die zum Beispiel bei GPS eingesetzt wird, und die Triangulation, die Winkelberechnungen zur Bestimmung der Ortsinformationen heranzieht, zu nennen.
Eine weitere Unterteilung kann anhand der Verteilung von Sender und Empfänger des Observables erfolgen. Sendet beispielsweise das Zielobjekt (vgl. Kapitel 2.2) ein Signal aus und der Location Technology
Provider empfängt das Signal und bestimmt darauf den Ort des Zielobjektes, so spricht man von einem
netzbasierten Ortungsverfahren. Sendet hingegen der Location Technology Provider das Signal aus und das
Zielobjekt empfängt das Signal und wertet es aus, so handelt es sich um ein endgerätebasiertes Ortungsverfahren. GPS ist deshalb zu den endgerätebasierten Ortungsverfahren zu zählen, da das Signal nicht vom
Zielobjekt ausgesendet wird. Stattdessen empfängt das Zielobjekt das Signal und bestimmt daraus die nötigen Ortsinformationen. Das CoO-Verfahren in GSM ist demgegenüber ein netzbasiertes Ortungsverfahren,
da das für die Ortung genutzte Signal vom Zielobjekt (= mobiles Endgerät) gesendet wird und von der
Basisstation (bzw. deren Backoffice), die die Ortungstechnologie bereitstellt, empfangen wird. Dort erfolgt
auch die Bestimmung der Ortsinformationen. Problem der netzbasierten Ortungsverfahren ist, dass Ortsinformationen des Zielobjektes nicht durch das Zielobjekt bestimmt werden und so ein Missbrauch dieser
Informationen stattfinden könnte. Anders ist dies bei den endgerätebasierten Ortungsverfahren, da hier das
Zielobjekt seine Ortsinformationen selbst bestimmt und so über den weiteren Gebrauch selbst entscheiden
kann.
An dieser Stelle kann eine weitere Unterscheidung getroffen werden. Empfängt das Zielobjekt bei endgerätebasierter Ortung das Ortungssignal, leitet die gewonnen Informationen aber an den Location Technology Provider weiter, um diese Informationen auszuwerten, so spricht man von endgeräteassistierenden
Ortungsverfahren, da diese zwar das Signal empfangen, aber keine Auswertung durchführen. Diese Art
der Ortung findet beispielsweise bei mobile-assisted A-GPS statt. Analoges gilt für den netzbasierten Fall.
Diese Konstellation tritt jedoch in der Regel nicht ein.
3.1.5
Zusammenfassung
Zusammenfassend kann gesagt werden, dass derzeit nur GPS und dessen Erweiterungen eine adäquate Positionsbestimmung für Navigationsdienste liefern können. Dies liegt hauptsächlich an der sehr guten und
recht konstanten Genauigkeit, der globalen Verfügbarkeit und der Möglichkeit Positionen im dreidimensionalen Raum zu bestimmen. Letzteres kann vor allem bei Navigationsdiensten eine entscheidende Rolle
spielen.
Neben GPS wird in den nächsten Jahren das ebenfalls satellitenbasierte Ortungssystem Galileo [gal ,
Simo 05] aufgebaut. Das Raumsegment wird aus zusätzlichen 30 Satelliten bestehen, verteilt auf drei Orbits in einer Höhe von 23.200 Kilometern. Diese strahlen Signale auf Frequenzen des E- und L-Bandes
aus. Der Signalaufbau ist ähnlich zu GPS. Wesentliche Vorzüge von Galileo im Gegensatz zu GPS werden
die Dienstgarantien und die Abrechnungsmöglichkeit sein. Eines der entscheidenden Argumente für Galileo war aber sicherlich, die Monopolstellung von GPS zu brechen. Erste funktionsfähige Versionen des
Galileo-Systems werden voraussichtlich im Jahr 2008 einsetzbar sein.
3.2 Mobile Programmierplattformen
Mobile Dienste zeichnen sich durch die Nutzbarkeit auf mobilen Endgeräten aus. Dazu muss das Endgerät
bestimmte Eigenschaften besitzen, die es dem Dienst zur Verfügung stellt. Diese sind Ein- und Ausgabemöglichkeiten zur Kommunikation mit dem Nutzer, Sende- und Empfangseinheiten zur Kommunikation
mit anderen Systemen, die Fähigkeit komplexe Programme auszuführen, etc. Um diese Eigenschaften des
Endgerätes für den Dienst zu nutzen, muss es Zugriffsmöglichkeiten darauf geben. Offene Plattformen auf
dem Endgerät ermöglichen diesen Zugriff für Anwendungen von Drittanbietern.
3.2. MOBILE PROGRAMMIERPLATTFORMEN
31
Applikation (z.B. MoBiLe)
Laufzeitumgebung
(z.B. Java)
Betriebssystem (z.B. Symbian)
Hardware (z.B. ARM)
Abbildung 3.4: Mobile Plattform
Im Wesentlichen ist eine Plattform auf einem mobilen Endgerät, wie in Abbildung 3.4 dargestelllt, aufgebaut. Basis ist die Hardware, die sich aus einer Recheneinheit, persistentem sowie volatilem Speicher,
Ein- und Ausgabegeräten, Sende- und Empfangseinheiten, etc. zusammensetzt. So gut wie jedes mobile
Endgerät verfügt über diese Bauteile. Die Ausprägung und Anzahl der Bauteile ist aber von Gerät zu Gerät
unterschiedlich. PDAs beispielsweise verfügen meist über einen für ihre Größe relativ leistungsstarken Prozessor und entsprechendem Speicher. Das Display zeichnet sich oft durch hohe Farbtiefe und gleichzeitiger
Eingabemöglichkeit durch Berührung aus (Touch-Screen). Als Sende- und Empfangseinheit dient häufig
lediglich eine Dockingstation, sowie eine Infrarot- und Bluetooth-Funkeinheit.
Mobiltelefone hingegen haben derzeit noch einen weniger rechenstarken Prozessor mit weniger Speicher,
kleinere Farbdisplays und eine ITU-T One-Hand-Tastatur. Dazu kommen in der Regel mehrere Sendeund Empfangseinrichtungen für Personal Area Networks (PAN) wie Bluetooth oder Infrarot, Local Area
Networks (LAN) wie IEEE802.11 und Metropolitan Area Networks (MAN) wie GSM oder UMTS mit
verschiedensten Frequenzen. Wie man sieht, gibt es bereits große Unterschiede bei den Mobiltelefonen
bezüglich deren Eigenschaften und Fähigkeiten. Durch Bezeichnungen wie Smartphone wird deshalb versucht, Kategorien innerhalb der Klasse der Mobiltelefone zu bilden. Leider sind derartige Bezeichnungen
nur schlecht gegeneinander abgegrenzt. Aufgrund der rasanten Entwicklung in diesem Bereich wird sich
auch in Zukunft diese Klasse durch wachsende Heterogenität auszeichnen.
Der Zugriff auf die Endgeräteeigenschaften wird durch das Betriebssystem geregelt. Viele Betriebssysteme
für mobile Endgeräte sind dabei so konzipiert, dass sie auf verschiedenste Hardware aufsetzen können und
eine Abstraktionsschicht für darüber liegende Schichten bilden. Frühere, aber auch der Großteil der heutigen mobilen Endgeräte nutzen proprietäre geschlossene Betriebssysteme. Dadurch ist es nicht möglich,
Anwendungen in das System zu integrieren, auszuführen oder Änderungen durchzuführen ohne tiefe Eingriffe in das System. Oft muss sogar das komplette Betriebssystem ersetzt werden. Entwicklungen der
letzten Jahre brachten allerdings einige offene 2 Betriebssysteme hervor. Dazu zählen Palm OS, Windows
CE, Symbian OS und möglicherweise in der Zukunft auch (Embedded) Linux (vgl. [VAL+ 01]). Diese
Betriebssysteme lassen es zu, Anwendungen von Drittanbietern zu integrieren und auszuführen. Auf das
Betriebssystem Symbian OS wird nachfolgend detaillierter eingegangen.
Die Laufzeitumgebung ist ein weiteres Abstraktionslevel von mobilen Plattformen. Laufzeitumgebungen
existieren meist für verschiedene Betriebssysteme und stellen eine betriebssystemunabhängige Funktionsmenge bereit. Diese kann durch Anwendungen von Drittanbietern genutzt werden. Ein Beispiel einer Laufzeitumgebung für mobile Endgeräte ist Java2 Microedition (J2ME). Auf J2ME wird später in diesem Kapitel genauer eingegangen.
3.2.1
Symbian OS
Aus der Heterogenität der kleinen mobilen Endgeräte heraus, entwickelt die Firma Symbian [sym ] (entstanden aus Ericsson, Nokia, Motorola, Psion) seit 1998 ein Betriebssystem namens Symbian OS für eben
diese Endgeräte. Es basiert auf dem Betriebssystem EPOC, welches von Psion für Handhelds entwickelt
2
offen“ bezeichnet hier nicht open-source, sondern dass eine API und Integrationsmöglichkeit für Anwendungen existiert
”
32
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
wurde. Durch Anpassung und Weiterentwicklung entstand daraus Symbian OS. Derzeit existiert Version
9 des Betriebssystems und die Anzahl der mit Symbian OS ausgestatteten Mobiltelefone beläuft sich auf
derzeit 23 Modelle. Es wird aber prognostiziert, dass die Anzahl der mit Symbian OS betriebenen Mobiltelefone in Zukunft weiter ansteigen wird. [sym ] beschreibt sein Betriebssystem als “advanced, open, standard operating system [...] for data-enabled mobile phones“. Es ist speziell für ubiquitäre, kleine, mobile
Endgeräte entworfen worden, die sich durch temporäre Netzverbindungen und Heterogenität auszeichnen
und die Integration von Applikationen von Drittanbietern erlauben sollen.
Symbian ist ein sehr robustes 32-Bit Multithreaded-Multitasking-Realtime-Betriebssystem. Es ist größtenteils in objektorientiertem C++ geschrieben und stellt eine native API in C++ bereit. Dadurch ist es möglich,
sehr effiziente Applikationen zu schreiben. Gegenüber Laufzeitumgebungen bietet die native API einen
höheren Funktionsumfang und direkten Zugriff auf Ressourcen. Symbian OS stellt daher ein sehr umfangreiches, fortschrittliches, offenes Betriebssystem dar, das Drittanbietern ein breites Spektrum an Anwendungen ermöglicht.
3.2.2
J2ME
Neben der nativen API stellt Symbian OS derzeit auch eine Laufzeitumgebung für J2ME bereit. Die
J2ME-Laufzeitumgebung wird aber auch von einigen anderen offenen Betriebssystemen und sogar von
proprietären Betriebssystemen der meisten Hersteller angeboten. J2ME ist eine der drei existierenden Editionen der Java2 Plattform (vgl. [jav , Stra 05] und Abb. 3.5):
• Java2 Standard Edition (J2SE): J2SE stellt eine Laufzeitumgebung mit einer Menge an APIs für
Desktop-Applikationen zur Verfügung. Desweiteren wird eine Kernmenge an Funktionen für alle
anderen Editionen definiert.
• Java2 Enterprise Edition (J2EE): J2EE erweitert J2SE um eine skalierbare, transaktionsorientierte
und datenbankbezogene Funktionsmenge für Enterprise-Applikationen.
• Java2 Micro Edition (J2ME): J2ME definiert mehrere Laufzeitumgebungen und APIs für kleine,
ressourcenbeschränkte Endgeräte wie PDAs, Mobiltelefone, Set-top-Boxen, etc.
Optionale
Pakete
Optionale
Pakete
Optionale
Pakete
J2EE
JVM
J2SE
Personal
Profile
Optionale
Pakete
Foundation
Profile
MIDP
CDC
JVM
CLDC
JVM
KVM
J2ME
Abbildung 3.5: Überblick über die Java 2 Editionen
Grundlage jeder Java-Edition ist die Virtual Machine (VM). Im Zusammenhang mit J2ME sind zwei Ausprägungen von VMs von Bedeutung. Dabei handelt es sich um die klassische Java VM (JVM) und die
3.2. MOBILE PROGRAMMIERPLATTFORMEN
33
KVM. Das K“ der KVM deutet auf den Speicherverbrauch hin, der sich im Kilobytebereich bewegt.
”
Abhängig von der Geräteart benötigt sie derzeit gerade einmal einen Speicherplatz von 50-80 Kilobyte.
Aufgrund der Inhomogenität der kleinen Endgeräte, setzt sich J2ME aus drei einzelnen modularen Elementen zusammen. Diese sind die so genannten Configurations, Profiles und optionale Pakete.
Configurations spezifizieren die Basisfunktionalität für eine bezüglich bestimmter Eigenschaften homogene Menge von Endgeräten. Diese Eigenschaften beinhalten die Größe des Speichers, Netzwerkverbindungen, Displaygröße und Eingabemöglichkeiten. Die Funktionalität der Configurations setzt sich aus der
Funktionalität der VM und der Basisbibliotheken zusammen. Derzeit existiert im Bereich der KVM nur
eine Configuration, die so genannte Connected Limited Device Configuration (CLDC). Für höherwertige
Geräte mit klassischer JVM gibt es außerdem noch die Connected Device Configuration (CDC). Zu diesen
Geräten zählen hauptsächlich PDAs oder Set-Top-Boxen. Geräte mit KVM sind hingegen meist höheren
Restriktionen unterlegen. Dabei handelt es sich zum Beispiel um Mobiltelefone.
Derzeit existieren zwei Versionen der CLDC. Diese sind CLDC 1.0 [cld a] und CLDC 1.1 [cld b]. Die
minimalen Anforderungen an das Endgerät für CLDC 1.0 sind im Folgenden aufgelistet:
• 160-512 Kilobyte Speicher (volatil sowie persistent)
• Verschiedene Netzwerkverbindungen, oft drahtlos & nicht verlässlich
• 96 x 54 Pixel Display mit 1 Bit Farbtiefe
• ITU-T Onehand-Tastatur oder Touch-Screen
Der Funktionsumfang, der durch CLDC bereitgestellt wird, ist eingeschränkt gegenüber dem Funktionsumfang in J2SE. Diese Beschränkungen beruhen einerseits auf den restriktiven Ressourcen der kleinen
Endgeräte und andererseits auf Sicherheitsaspekten. Die wichtigsten Einschränkungen der CLDC 1.0 sind
im Folgenden aufgelistet:
• Keine Fließkommazahlenunterstützung
• Beschränkte Fehlerbehandlung für Run-time-Errors
• Kein Java Native Interface
• Keine nutzerspezifischen ClassLoader
• Keine Reflection API
• Keine Objektserialisierung
• Keine Weak-References
Im Dezember 2002 wurde eine neue Version der CLDC (CLDC 1.1) veröffentlicht, die durch den JSR-139
spezifiziert wird. Die wesentlichen Neuerungen in CLDC 1.1 sind:
• Fließkommazahlenunterstützung
• Unterstützung von Weak-References
Hauptsächlich aufgrund der Fließkommaarithmetik haben sich die Anforderungen an den minimalen Speicherplatz von 160 auf 192 Kilobyte erhöht.
Aufsetzend auf die Funktionalität der Configurations, erweitern die Profiles die Laufzeitumgebung um eine Menge an High-Level-Funktionen wie das Life-Cycle-Management, das User Interface (UI) und den
Zugriff auf gerätespezifische Funktionen. Ein Profile kann nur in Verbindung mit einer bestimmten Configuration genutzt werden. Beispiele für ein Profile für CDC sind das Foundation Profile und das darauf
aufsetzende Personal Profile. Ein entsprechendes Profile für CLDC ist das Mobile Information Device Profile (MIDP).
MIDP existiert derzeit in zwei Versionen, MIDP 1.0 [mid a] und MIDP 2.0 [mid b]. MIDP setzt als UI das
speziell auf kleine Endgeräte mit wenig Rechenleistung ausgerichtete Liquid Crystal Display UI (LCDUI)
ein. Als Verbindungsprotokoll ist in MIDP 1.0 nur HTTP obligatorisch.
Seit November 2002 existiert eine neue Version von MIDP (MIDP 2.0). Sie unterscheidet sich im Wesentlichen von MIDP 1.0 durch folgende Punkte:
34
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
• Neues Verbindungsprotokoll: HTTPS
• MIDP Media API
• Game API
• Push Registry
• Zugriff auf Record-Stores anderer MIDlets
• Over-The-Air User Initiated Provisioning
• PKI-Unterstützung
Anwendungen in J2ME unter CLDC und MIDP werden in so genannten MIDlets verfasst. MIDlets ähneln
dem Konzept der Applets, die bereits in J2SE eingesetzt wurden. Wesentliche Unterschiede ergeben sich
in der Art des UI. Während J2SE auf das Abstract Window Toolkit (AWT) und Swing setzt, nutzt J2ME das
LCDUI, welches eine geringe Teilmenge der Funktionalität von AWT und Swing umsetzt. Dadurch ist es
aber besonders für mobile Endgeräte mit hohen Ressourcenbeschränkungen geeignet.
Ein weiterer Punkt, in dem sich J2ME von J2SE unterscheidet, ist der Zugriff auf Netzwerkverbindungen. In J2SE stehen hierfür verschiedenste Klassen aus den Packages java.io und java.lang zur
Verfügung. Um eine spezielle Netzwerkverbindung zu initialisieren, wird ein entsprechendes Objekt erzeugt. Aufgrund der hohen Heterogenität der mobilen Endgeräte bezüglich der Netzverbindungen ist dieser Ansatz in J2ME nicht sinnvoll umsetzbar. Deshalb wurde in J2ME ein neuer Ansatz entwickelt, der
nicht dieser Problematik unterliegt. Dies ist das so genannte Generic Connection Framework (GCF). Die
Initialisierung jeder Netzwerkverbindung erfolgt über die Klasse Connector. Anhand der angegebenen
Adresse und der Verfügbarkeit von Low-Level“-Netzwerkverbindungen (je nach Endgerätefunktionalität)
”
wählt das GCF die entsprechende Connection-Klasse aus. Durch die Hinzunahme weiterer Verbindungstypen und der entsprechenden Connection-Klasse kann das GCF leicht erweitert werden.
Aufbauend auf das Profile gibt es eine Menge optionaler Pakete. Welche Pakete verfügbar sind, hängt im
Wesentlichen von der Ausstattung des Endgerätes ab. Besitzt das Endgerät zum Beispiel eine BluetoothSchnittstelle und das Betriebssystem ermöglicht den Zugriff auf diese Schnittstelle, kann das Paket Java
APIs for Bluetooth Wireless Technology (JABWT) [jab ] als optionales Paket integriert werden.
JABWT JABWT stellt eine API für die Geräte- und Dienstsuche, das Gerätemanagement und die Gerätekommunikation bereit. Für die Geräte- und Dienstsuche dient der so genannte DiscoveryAgent, der
mittels Callback-Funktion über gefundene Geräte und Dienste informiert. Mit Hilfe des Gerätemanagements können Statusabfragen und Konfigurationen der eigenen Bluetooth-Schnittstelle sowie entfernter
Bluetooth-Geräte durchgeführt werden. Konfigurationsmöglichkeiten beziehen sich auf die Authentifizierung, Autorisierung und Verschlüsselung. Statusabfragen können für die maximale Anzahl paralleler Verbindungen, Adressen, Sichtbarkeit für andere Geräte, Versionen, etc. erfolgen. Die Gerätekommunikation
basiert auf dem Logical Link Control and Adaptation Layer Protocol (L2CAP). Um dieses innerhalb von
J2ME wie gewohnt zu nutzen, werden durch JABWT eine Menge neuer Verbindungsprotokolle in das GCF
eingefügt. Diese stellen Client- sowie Serverfunktionalitäten zur Verfügung.
JABWT wird derzeit von einigen wenigen Mobiltelefonen angeboten. Die Zahl der JABWT-unterstützenden Geräte steigt aber stetig an.
LAPI Vor allem für den Einsatz in LBSs existiert ein optionales Paket, das die Verwendung von Ortsinformationen erleichtern soll. Dieses Paket ist die Location API (LAPI) [lap 03]. Die LAPI wurde konzipiert,
um innerhalb eines MIDlets leichten Zugriff auf Ortsinformationen des Endgerätes zu erlangen. Dabei ist
das eingesetzte Ortungsverfahren unerheblich.
Die zentrale Komponente der LAPI ist der LocationProvider. Ein Objekt vom Typ LocationProvider liefert eine bestimmte Art von Ortsinformationen. Bei der Anforderung von Ortsinformationen
können durch die Spezifikation von Kriterien (Criteria) die Genauigkeit, der Energieverbrauch, die
entstehenden Kosten, etc. der Positionsbestimmung eingeschränkt werden. Der LocationProvider
35
3.2. MOBILE PROGRAMMIERPLATTFORMEN
ist eine abstrakte Klasse, die eine Menge abstrakter und nicht-abstrakter Methoden besitzt. Eine nichtabstrakte Methode ist beispielsweise getInstance, mit der eine Instanz eines LocationProviders
angefordert wird, die bestimmte Kriterien erfüllt. Außerdem kann durch die nicht-abstrakte Methode addProximityListener eine automatische Benachrichtigung bei Erreichen einer bestimmten Nähe zu einer festen Koordinate hinzugefügt werden. Abstrakte Methoden sind unter anderem getLocation, um
die aktuelle Position abzufragen, getState, um den aktuellen Zustand des LocationProviders zu
bestimmen, und setLocationListener, um den LocationProvider für periodischen Aktualisierungen zu konfigurieren. Letztere liefert Ortsinformationen asynchron über ein Callback-Verfahren. Dazu
wird der setLocationListener-Methode als Parameter ein Objekt vom Typ LocationListener
angehängt. Nach Ablauf des Zeitintervalls erfolgt eine Aktualisierung der Ortsinformationen, indem die
Methode locationUpdated auf diesem Objekt aufgerufen wird.
Ähnliches gilt für die oben erwähnte Registrierung der ProximityListener. Hier wird automatich die
Methode proximityEvent des ProximityListeners bei örtlicher Nähe zu einer festen Referenzkoordinate aufgerufen. Die Nähe wird durch die Angabe des Abstandes zwischen aktueller Koordinate und
Refernzkoordinate in Metern spezifiziert. Eine derartige Ereignissteuerung könnte für den MoBiLe-Service
eingesetzt werden. Dadurch würde ein Ereignis ausgelöst, sobald sich der Nutzer in die Nähe eines Aktionspunktes bewegt, und daraufhin eine Navigationsinformation bereitgestellt. Probleme für den MoBiLeService ergeben sich durch die stark schwankenden Geschwindigkeiten des Nutzers. Eine optimale Wahl
der Abstandsangabe ist hierbei schwer möglich. Eine Lösung, die den Anforderungen des MoBiLe-Service
entspricht, wird in Kapitel 4 vorgestellt.
Um die LAPI für den Gebrauch mit einem externen GPS-Empfänger einzusetzen, muss ein LocationProvider, der die Anbindung an den GPS-Empfänger verwaltet und Ortsinformationen in die gewünschte Form bringt, abgeleitet werden. Hierbei erfolgt durch die LAPI leider keine Unterstützung. Insgesamt
ergäbe die Erweiterung der LAPI für den MoBiLe-Service einen erheblichen Aufwand, der in keiner Relation zum erbrachten Mehrwert steht.
Außerdem wird die LAPI derzeit leider nur von wenigen Endgeräten unterstützt. Um den Demonstrator ohne komplexe Veränderungen auf verschiedenen Endgeräten betreiben zu können, wurde die LAPI deshalb
und aus den oben genannten Gründen in dieser Arbeit nicht eingesetzt.
Application
TinyLine
SVG
M3G
OpenGL ES
Graphics
Engine
MMAPI
SVGAPI
MIDP
CLDC
KVM
Abbildung 3.6: Mobile Plattform für Grafikdarstellung
MMAPI Auch für die Arbeit mit Multimediainhalten stellt J2ME standardmäßige, sowie erweiterte Unterstützung durch optionale Pakete, bereit. Während MIDP 1.0 nur die Darstellung von Bildern ermöglicht,
erweitert MDIP 2.0 die Medienfähigkeit um die Funktion zum Abspielen von Audiodateien. Die Unterstützung weiterer Medien und erhöhte Funktionalität liefert das optionale Paket Mobile Media API
(MMAPI) [mma ]. Die MMAPI besteht im Wesentlichen aus vier Komponenten. Diese sind Manager,
Player, Control und DataSource. Mit diesen Komponenten kann unabhängig von der Art des Mediums gearbeitet werden. Egal ob es sich um Audiodateien im WAV- oder MP3-Format, Rastergrafikdateien im JPEG- oder GIF-Format oder Videodateien im MPEG- oder AVI-Format handelt, bietet die MMAPI
identische Zugriffsmethoden. Dadurch ist der Zugriff auf die Medien unabhängig vom zugrunde liegenden
36
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Endgerät, das verschiedenste Medientypen unterstützen kann.
SVG-APIs Zur Unterstützung von Vektorgrafikdateien gibt es ein optionales Paket namens Scalable
2D Vector Graphics API (SVGAPI) [svg ]. Damit ist es möglich, Vektorgrafiken im SVG-Tiny-Format
des W3C [Ande 03a] auf dem Display von mobilen Endgeräten anzuzeigen. SVG Tiny (SVGT) ist eines
der beiden Mobile Profiles [Ande 03a] des SVG 1.1 Standards [Ande 03b] und speziell auf ressourcenbeschränkte mobile Endgeräte ausgerichtet. Grafiken im SVG-Format sind besonders gut geeignet zur Darstellung von grafischen Objekten, die sich hauptsächlich aus Linien zusammensetzen wie zum Beispiel
einfache Landkarten (vgl. [Wald 03]). Vorteile gegenüber Rastergrafiken bestehen in der guten Skalierbarkeit, dem geringen Speicherplatzverbrauch, der einfachen Transformation der Objekte und dem einfachen
Zugriff auf Objekte (vgl. [Beck 02]).
Derzeit wird SVGAPI nur von einigen wenigen mobilen Endgeräten unterstützt. Eine Möglichkeit, um
SVG-Grafiken auch auf anderen Endgeräten darstellen zu können, wird durch das Projekt TinyLine SVG
[tin ] erreicht. TinyLine SVG bietet eine Highlevel- sowie Lowlevel-API zum Erstellen, Bearbeiten und
Darstellen von SVG-Grafiken. Dazu benötigt TinyLine SVG mindestens MIDP 2.0.
Voraussichtlich werden Vektorgrafiken aufgrund der oben genannten Vorteile in Zukunft vermehrt im Bereich der mobilen Endgeräte eingesetzt. Ein Einsatzzweck könnte zum Beispiel die grafische Präsentation
von Navigationsinformationen sein.
M3GAPI Zur Unterstützung von dreidimensionalen Grafikobjekten existiert das optionale Paket Mobile
3D Graphics API (M3GAPI) [m3g ]. Die M3GAPI kann in zwei verschiedenen Modi genutzt werden.
Diese sind der Retained Mode und der Immediate Mode. Im Retained Mode steht eine Highlevel-API zur
Verfügung, mit der auf einfache Weise mit 3D-Grafikobjekten, virtuellen Kameras und Licht gearbeitet
werden kann. Der Immediate Mode stellt eine Lowlevel-API bereit und ermöglicht so das direkte Zeichnen
von 3D-Objekten. Der Immediate Mode ist auf OpenGL ES [ope a] angepasst, welches auf Endgeräte
mit speziellem Grafikprozessor ausgerichtet ist. Der Mascot-Capsule [mas ] ist ein Grafikprozessor, der
bereits in einigen Mobiltelefonen zu finden ist. Zusammen mit OpenGL ES oder MMAPI ermöglicht dieser
bereits relativ aufwändige 3D-Darstellungen. Derzeit verfügen bereits auf einigen Mobiltelefonen über die
M3GAPI.
Einen Überblick über die vorgestellten APIs zur Unterstützung grafischer Medien zeigt Abbildung 3.6.
3.2.3
Zusammenfassung
Diese kurze Einführung in J2ME zeigte die wesentlichen Eigenschaften und Neuerungen gegenüber J2SE,
sowie einige für Navigationsdienste relevante Punkte. Für eine genauere Betrachtung von J2ME wird auf
[jav , Schm 04, Stra 05] verwiesen. Gegenüber Anwendungen für die native Schnittstelle von Symbian OS
zeigen sich Anwendungen für J2ME wesentlich ineffizienter und dadurch langsamer in der Ausführung.
Auch der Funktionsumfang von J2ME ist meist eingeschränkt gegenüber Symbian OS. Jedoch glänzt J2ME
bis auf wenige Ausnahmen durch seine Plattformunabhängigkeit und seine bereits sehr gute Unterstützung
in vielen Bereichen. Daher bietet J2ME eine gegenüber Symbian OS nicht zu vernachlässigende mobile
Programmierplattform, die sicherlich auch in Zukunft vermehrt zum Einsatz kommen wird.
3.3 Unterstützung für verteilte Push-Dienste
Der Navigationsdienst, der in dieser Arbeit entwickelt wird, soll in Form eines LBPSs realisiert werden.
Für den Fall eines verteilten LBPSs müssen zwischen den verteilten Komponenten Protokolle eingesetzt
werden, die dieses Pushing unterstützen. Hierzu gibt es einige Protokolle, die vorzugsweise im Bereich des
Mobilfunks zum Einsatz kommen. Desweiteren existieren einige Protokolle der Anwendungsschicht, die
3.3. UNTERSTÜTZUNG FÜR VERTEILTE PUSH-DIENSTE
37
spezielle für den Austausch von Ortsinformationen entwickelt wurden und zumindest partiell die Kommunikation zwischen verteilten Komponenten von LBPSs in Betracht ziehen. Im Folgenden wird eine kurze
Einführung in diese Protokolle gegeben.
3.3.1
Push-Protokolle
SMS
Der Short Message Service (SMS) [3gp c] ist Anfang der 90er Jahre entstanden und heutzutage der meist
gebrauchteste Dienst zum Austausch von Kurznachrichten im Mobilfunknetz. Die Übertragung von SMSNachrichten erfolgt über Signalisierungskanäle. Die Zustellung von Nachrichten wird durch das SMS Center (SMSC) geregelt und wird durch Pushing realisiert. D.h. dass SMS-Nachrichten nicht vom Nutzer abgerufen werden, sondern bei Verfügbarkeit automatisch zugestellt werden. Diese Art der Datenübertragung
könnte prinzipiell auch für die Kommunikation in der verteilten Varianten des LBPSs eingesetzt werden.
Vorteile sind nach [Tosi 03] die Standardisierung und die gute Unterstützung auch beim Roaming in Fremdnetze. Nachteile sind jedoch, dass eine SMS-Nachricht nur 160 alphanumerische Zeichen enthalten kann.
Es ist daher keine akzeptable Übertragung von Bildern, Audio und Video möglich. Da diese Medien aber
bei der Realisierung des MoBiLe-Service zum Einsatz kommen, stellt SMS kein anwendbares Protokoll
für die verteilte Kommunikation bei LBPSs dar.
MMS
Im Gegensatz zu SMS stellt der Multimedia Messaging Service (MMS) die Möglichkeit bereit, verschiedenste Medien zu übertragen. MMS gilt als Nachfolger von SMS und hat eine ähnliche Funktionsweise.
Die Zustellung der Nachrichten erfolgt durch das MMS Center (MMSC) und Nachrichten werden ebenfalls
nicht explizit vom Nutzer abgefragt, sondern durch einen Push-Mechanismus dem Nutzer zur Verfügung
gestellt. Die Übertragung von MMS-Nachrichten basiert jedoch nicht wie SMS auf der Nutzung von Signalisierungskanälen. MMS-Nachrichten werden in der Regel mittels des Wireless Application Protocol (WAP)
[wap a] übertragen. Zu übertragende Medien können Text, Grafiken (z.B. im GIF- oder PNG-Format), Audio (z.B. im MIDI-Format) oder Video (z.B. im H.263- oder MPEG4-Format) sein. Da gegenüber SMS
MMS bisher weniger gut unterstützt wird und ernsthafte Probleme in der Kompatibilität hat, ist MMS für
die Realisierung des MoBiLe-Service kein anwendbares Protokoll für die verteilte Kommunikation.
WAP Push
Eine dritte Alternative steht durch WAP Push [wap b] zur Verfügung. WAP Push ist ein speziell für PushDienste vorgesehenes Konzept von WAP. Die WAP Push Architektur besteht im Wesentlichen aus zwei
Komponenten. Diese sind der Push Initiator (PI) und der Push Proxy Gateway (PPG). Der PI ist dafür
zuständig, den Push-Vorgang anzustoßen. Der PPG übertragt daraufhin den Inhalt mittels des Push OverThe-Air Protocol an das mobile Endgerät. PI und PPG kommunizieren über das Push Access Protocol
(PAP). Das PAP wird in einen HTTP1.1 POST-Aufruf eingebettet. Die eigentliche Nachricht, die aus einem Service Indicator (SI) oder einem Service Load (SL) bestehen kann, wird ebenfalls in diesen Aufruf
integriert. Der SI ist dafür zuständig, dem Nutzer eine kurze Botschaft und einen Verweis auf weiterführende Informationen zu überbringen. SL kann hingegen dazu eingesetzt werden, automatisch weiterführende
Informationen auf das Endgerät zu laden und dort anzuzeigen.
Ein beispielhafter HTTP1.1 POST-Aufruf zwischen PI und PPG ist im Folgenden gegeben:
2
POST / HTTP/1.1
Host: localhost
Content-Type: multipart/related; boundary=asdlfkjiurw; type="application/xml"
4
--asdlfkjiurw
38
6
8
10
12
14
16
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Content-Type: application/xml
<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap productname="Testgateway">
<push-message push-id="test@test.de">
<address address-value="WAPPUSH=127.0.0.1/TYPE=USER@0.0.0.0" />
</push-message>
</pap>
--asdlfkjiurw
Content-Type: text/vnd.wap.si
18
20
22
24
26
28
<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://www.waptest.de/wml/pap/message.wml"
si-id="si-test@test.de">
Sie haben eine neue Nachricht!
</indication>
</si>
--asdlfkjiurw--
Ein Endgerät mit der IP 127.0.0.1 würde daraufhin in geräteabhängiger Form den Text Sie haben eine neue
”
Nachricht!“ darstellen und auf den Link http : //www.waptest.de/wml/pap/message.wml verweisen.
Diese Art des Pushings ermöglicht einen weitaus höheren Funktionsumfang als die oben beschriebenen
Verfahren mittels SMS oder MMS, ist aber wesentlich komplexer in der Handhabung und Implementierung.
Desweiteren lässt WAP Push nach [Tosi 03, PSM 01] keine echte Integration in Internetdienste zu und
unterliegt einigen Einschränkungen die durch zukünftige Technologien wesentlich verbessert werden.
SIP
Eine sehr innovative Push-Technologie ist durch das Session Initiation Protocol (SIP) [iet 99] einsetzbar. SIP ist ein Signalisierungsprotokoll der Anwendungsschicht, um Sitzungen zwischen zwei oder mehr
Teilnehmern zu erzeugen,zu modifizieren und zu beenden. Die Sitzungen beinhalten Internet Multimediakonferenzen, Internet-Sprachdienste und die Verteilung multimedialer Inhalte. Wesentliche Komponenten der SIP-Architektur sind der SIP Proxy und der SIP User Agent (SIP UA). SIP-Nachrichten haben
einen ähnlichen Aufbau wie HTTP-Nachrichten und sind ebenfalls textbasiert. SIP ist aber keinesfalls eine Erweiterung von HTTP. Transportprotokoll kann sowohl TCP als auch UDP sein. SIP-Methoden sind
zum Beispiel INVITE, ACK und REGISTER. Erweiterungen von SIP definieren zusätzliche Methoden.
[Tosi 03, PSM 01] beschreiben wie eine Architektur für das Pushing mittels SIP aussehen und funktionieren kann. Die Architekturen erfüllen die Anforderungen der 3GPP Push-Services (vgl. [3gp d, 3gp e].
SIP wird derzeit von Endgeräten und Infrastrukturkomponenten nur rudimentär unterstützt und ist deshalb
nur erschwert einsetzbar. Zukünftig wird die Nutzung voraussichtlich jedoch viele Vorteile bringen und die
Voraussetzungen für LBPSs weitestgehend erfüllen (vgl. hierzu auch Kapitel 7).
3.3.2
Location-based Push-Protokolle
MLP
Das Mobile Location Protocol (MLP) [mlp ] ist ein XML-basiertes, erweiterbares Protokoll der Anwendungsschicht. MLP standardisiert den Austausch von Ortsinformationen zwischen dem Location Provider
und dem Dienstanbieter, der mit Hilfe dieser Ortsinformationen den Dienst bereitstellt. Das Protokoll ist
3.4. BESTEHENDE NAVIGATIONSDIENSTE
39
unabhängig von der zugrunde liegenden Netzwerktechnologie und deshalb vielseitig einsetzbar.
MLP ist dreischichtig aufgebaut. Bei den Schichten handelt es sich um das Transport Layer, das Element
Layer und das Service Layer. Das Transport Layer ist für den Transport des XML-Inhaltes zuständig. Der
Standard schlägt hierfür Protokolle wie HTTP, WSP oder SOAP vor. Das Element Layer definiert allgemeine Elemente, die im Service Layer eingesetzt werden können. Schließlich definiert das Service Layer
eine Menge an Übertragungarten für den Ortsinformationsaustausch. Beispiele hierfür sind der Standard
Location Immediate Service (SLIS), der Standard Location Reporting Service (SLRS) und der Triggered
Location Reporting Service (TLRS). Jeder dieser Übertragungsarten spezifiziert eine bestimmte Semantik
in der Art der Kommunikation und eine Menge an Parametern für diesen Datenaustausch.
Der SLIS kann für die Abfrage von Ortsinformationen von einem oder mehreren Zielobjekten genutzt
werden. Er definiert drei Methoden, die dies verwirklichen sollen. Wichtige Parameter sind eindeutige
Identifikatoren für das Zielobjekt, Zeitstempel, geforderte Genauigkeiten sowie natürlich die eigentliche
Ortsinformation in einem bestimmten Datum und mit einer bestimmten Genauigkeit.
Der SLRS wird nicht für die Abfrage von Ortsinformationen eingesetzt. Hier informiert das Zielobjekt
selbstständig den Dienstanbieter über die aktuellen Ortsinformationen. Dazu wird nur eine Methode definiert, die als Parameter im Wesentlichen die Ortsinformation und einen Zeitstempel enthält.
Der TLRS kann dazu eingesetzt werden, um Ortsinformationen über ein Zielobjekt bei Eintritt bestimmter
Ereignisse zu erhalten. Derzeit ist das einzige Ereignis der Ablauf eines Zeitintervalls. Für die Zukunft
sollen aber auch Ereignisse bei Betreten oder Verlassen von Zonen und andere Ereignisse möglich sein.
Parameter für die fünf definierten Methoden sind zum Beispiel eindeutige Identifikatoren der Zielobjekte,
Zeitstempel, Gültigkeitszeiträume, geforderte Genauigkeiten, etc.
Um MLP für den MoBiLe-Service einzusetzen, sind grundlegende Erweiterungen durchzuführen, die den
Rahmen dieser Arbeit sprengen würden. Desweiteren ist die Datenmenge, die aus der Signalisierung entsteht, aufgrund der XML-Basis erheblich und würde so zu hohen Kosten und Verzögerungen führen.
Geopriv
Das Geopriv-Protokoll [geo 04] ist für den sicheren Austausch von Ortsinformationen zwischen dem Zielobjekt und dem Dienstanbieter entwickelt worden. Besonders im Vordergrund stehen in diesem Protokoll
sicherheitskritische Aspekte für verschiedenste Location-based Services, wie Navigationsdienste oder Notfalldienste. Ein wesentliches Element der Geopriv-Protokolls ist das Location Object (LO). Das LO enthält
die Ortsinformationen des Zielobjektes, ein Identifikator (oder Pseudonym) für das Zielobjekt, Zeitstempel
und sicherheitsrelevante Informationen.
Aufgrund von zeitlichen Restriktionen in dieser Arbeit wird innerhalb des MoBiLe-Service eine sicherheitskritische Betrachtung des Dienstes vorerst vernachlässigt. Der Einsatz von Geopriv ergibt deshalb
keinen großen Mehrwert für diese Arbeit und wird darum vermieden. Für zukünftige Versionen des Demonstrators ist der Einsatz jedoch durchaus möglich.
3.4 Bestehende Navigationsdienste
3.4.1
Forschungsprojekte
Die letzten Jahre brachten im Bereich der mobilen Navigationsdienste einige interessante Forschungsprojekte hervor. Während spezielle Navigationsdienste für Mountain-Biker bisher noch nicht betrachtet
wurden, trat vermehrt eine andere Art mobiler Navigationsdienste in den Vordergrund. Dabei handelt
es sich um mobile Touristenführer (Tour Guides). Sie basieren auf einer ähnlichen Zielsetzung wie der
MoBiLe-Service. Informationen über Forschungsprojekte in diesen Bereichen liefern neben den einzelnen
Forschungsgruppen auch [BCK 04, KrBa 03, ChKo 00].
40
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Cyberguide
Cyberguide [LKAA 96, AAH+ 97] ist einer der ersten mobilen Navigationsdienste. Entwickelt wurde er
von der Future Computing Environment (FCE) Gruppe am Georgia Institute of Technology. Seine Entstehung geht auf Forschungsaktivitäten im Bereich kontextsensitiver Dienste zurück, wobei bei Cyberguide
nur Ortsinformationen als Kontextinformationen genutzt werden.
Cyberguide besteht aus vier einzelnen unabhängigen Komponenten: das Kartensystem, das Informationssystem, das Ortungssystem und das Kommunikationssystem. Das Kartensystem generiert Karten mit Hilfe
des Informationssystems. Die Position des Nutzers wird durch das Ortungssystem geliefert und ebenfalls
in der Karte dargestellt. Bei Bedarf kann die Nutzerposition mittels Pushing bei einer Positionsveränderung
automatisch in der Karte aktualisiert werden. Das Informationssystem liefert Beschreibungen zu PoIs. Über
das Kommunikationssystem können Nachrichten ausgetauscht oder hinterlassen werden. Das Kommunikationssystem bietet auch die Möglichkeit, Nachrichten für alle registrierten Nutzer zu hinterlassen. Das
Ortungsverfahren liefert Ortsinformationen mit Hilfe von GPS oder an der Zimmerdecke montierten Infrarotsendern für den Betrieb innerhalb von Gebäuden.
Da das System nur bedingt Zugriff auf externe Informationen hat (nur durch lokale PANs), müssen alle für
die Navigation nötigen Informationen lokal auf dem Endgerät verfügbar sein. Dies schränkt die Erweiterbarkeit und Funktionalität des Systems stark ein.
Da das System keinerlei Routenwissen besitzt, kann eigentlich nicht von einem vollwertigen Navigationsdienst im Sinne dieser Arbeit gesprochen werden. Die eigentliche Routenführung wird vollständig auf den
Nutzer übertragen. Der einzige Vorteil für den Nutzer ist die automatische Positionsbestimmung und deren
Anzeige in der Karte. Eine Bezeichnung als Kartendienst mit Ortungsfunktion trifft die Funktionalität des
Cyberguides besser als die Bezeichnung als Navigationsdienst.
GUIDE
GUIDE [CDMF 00, CDM+ 00] ist ein Forschungsprojekt der Universität Lancaster. Ein Prototyp wurde
innerhalb Lancaster als mobiler Touristenführer eingesetzt. Der Dienst wird lokal auf einem Tablet-PC
oder PDA ausgeführt. Alle Informationen wie Ortsinformationen, PoI-Informationen oder Öffnungszeiten
von Museen, Kirchen, etc. werden durch WLAN-Netze auf das mobile Endgerät übertragen. Nachteil dieses Verfahrens sind die hohen Kosten und der hohe Aufwand zur Bereitstellung einer flächendeckenden
WLAN-Infrastruktur. Durch Caching auf dem mobilen Endgerät ist auch ein eingeschränkter Betrieb ohne
WLAN-Verbindung möglich. Dies setzt aber eine geschickte Prognose der in Zukunft benötigten Informationen voraus. Zur Präsentation dienen ausschließlich Kartenausschnitte, die an die aktuelle Position
angepasst sind.
LoL@
LoL@: Local Location Assistant [PKK , PUM 02, UPNM ] ist ein Projekt des Forschungszentrums Telekommunikation Wien mit dem Ziel der Entwicklung eines mobilen elektronischen Touristenführers für
die Wiener Innenstadt. LoL@ stellt dazu eine Menge vordefinierter Routen und die Möglichkeit, eigene
Routen zu planen, bereit. Neben der Navigation zwischen einzelnen PoIs und der Navigation von einem
beliebigen Standort zum Anfang der Route, kann der Nutzer detaillierte Informationen zu den PoIs abfragen.
LoL@ ist in einer 3-Tier-Struktur konzipiert, die die Präsentation und einen Teil der Dienstlogik auf dem
Endgerät implementiert, während der Großteil der Dienstlogik in der Infrastruktur liegt. Der Datenbestand
wird durch verschiedenste Datenbanken und durch das vom 3GPP spezifizierte Gateway Mobile Location
Center (GMLC) [3gp a] geliefert. Über das GMLC können Ortsinformationen des Nutzers abgefragt werden. Das GMLC abstrahiert das eingesetzte Ortungsverfahren, das durch einen hybriden Ansatz aus GPS
und Cell-Id realisiert wird. LoL@ wurde größtenteils in Java implementiert und nutzt HTTP als Verbindungsprotokoll, in dem die Medien in HTML oder WML eingebettet sind. Zur Präsentation dient in erster
3.4. BESTEHENDE NAVIGATIONSDIENSTE
41
Linie der Browser auf dem mobilen Endgerät, der Karteninhalte mit der eingezeichneten Route und zusätzlichen PoI-Informationen anzeigt.
Im Gegensatz zu LoL@ soll der MoBiLe-Service dieser Arbeit nicht auf die Kartendarstellung fokussiert
sein, sondern eine Vielzahl verschiedener Präsentationsformen unterstützen. Die Kartendarstellung tritt dabei eher in den Hintergrund, da sie für den Nutzer einen hohen kognitiven Aufwand mit sich bringt und nur
bedingt für die Mountain-Bike-Navigation geeignet ist.
Zusätzlich wird in LoL@ ein push-basierter Ansatz angedacht (vgl. [PSM 01]). Hierfür wird das GMLC
dazu veranlasst periodische Ortsinformationen an den Navigationsdienst zu senden. Dieser überprüft dann,
ob eine relevante Änderung der Ortsinformationen stattgefunden hat. Falls ja, wird eine Karte mit der aktuellen Position an das mobile Endgerät gesendet. Dieser Ansatz unterliegt dem Problem, dass die Prüfung,
ob es sich um eine relevante Veränderung der Ortsinformationen handelt, nicht an der Stelle durchgeführt
wird, an der die Ortsinformationen generiert werden. Dadurch müssen in erster Linie sehr viele Daten
übertragen werden und außerdem kann es vorkommen, dass Ortsinformationen übertragen werden, die
keine für die Dienstausführung relevanten Änderungen enthalten. Sinnvoll wäre deshalb die Prüfung in
Richtung der Generierung der Ortsinformationen zu verlagern.
Deep Map
Das Projekt Deep Map [MaZi 00, Mala 99, Kray 03] des European Media Lab ist ein mobiler Touristenführer der Stadt Heidelberg. Deep Map bietet dem Nutzer unter anderem Dienste wie Routenplanung,
Navigation oder Hotelbuchung an. Der Fokus fällt dabei vor allem auf die Nutzerinteraktion (z.B. durch den
Einsatz multilingualer Spracheingabemöglichkeiten) und die Informationsbereitstellung durch verschiedenste Datenbanken.
Die Architektur von Deep Map basiert auf einem Multiagentensystem. Deep Map betrachtet dabei
zwei Nutzungsvarianten, die die Verteiltheit der Agenten bestimmen. Diese sind der web-basierte Touristenführer für zuhause (Routenplanung, virtuelle Stadtbesichtigung, etc.) und der mobile Touristenführer
für unterwegs (Navigation, Bereitstellung diverser Informationen). Dazu sind die Agenten sowohl auf dem
mobilen Endgerät als auch auf stationären Rechnern lauffähig und interagieren über den Remote Procedure
Call (RPC) oder die Middleware CORBA.
Die Deep Map Architektur kann in drei Schichten eingeteilt werden, die aus verschiedensten Agenten aufgebaut sind. Diese Schichten sind das Interface-Layer für die Interaktion mit dem Nutzer, das CognitiveLayer für die Aufbereitung der Nutzerinteraktion und das Knowledge-Layer für die Verwaltung und
Bereitstellung verschiedenster Informationen. Einer der wichtigsten Agenten ist der SISTO-Agent (vgl.
[Kray 03]). Der SISTO-Agent übernimmt die zentrale Stelle des Gesamtsystems. Er ist verantwortlich für
das Routenmanagement, das (Reverse-)Geocoding, die Navigation, die Ortung, die Karteninteraktionen,
die Informationsakquisition und viele weitere Aufgaben.
Für die Ortung wird ein dreistufiger Ansatz genutzt, der zuerst prüft ob Ortsinformationen geliefert werden
können, gegebenenfalls dann den Cache nach zwischengespeicherten Ortsinformationen befragt und falls
nötig Ortsinformationen von Sensoren anfordert. Dieser Ansatz ist für eine pull-basierte Lösung konzipiert. Eine push-basierte Lösung wird durch die Integration von Location-Triggered Actions verwirklicht.
Für diese ist sowohl das Betreten sowie das Verlassen von Regionen als Initiierungsvorschrift angedacht.
Zusätzlich können Time-Triggered Actions und eine Kombination, so genannte Spatio-Temporal-Triggered
Actions, eingesetzt werden. Eine genauere Betrachtung der Initiierungsvorschriften, sowie der dafür vorgesehenen Agenten, erfolgt leider nicht.
Durch Time-Triggered Actions und die Auswertung von Ortsinformationen wird in Deep Map versucht,
die derzeitigen Bewegungsgründe des Nutzers zu bestimmen (z.B. Einkaufsbummel, Stadtbesichtigung).
Diese Art der Ortung greift weit in die Privatsphäre des Nutzers ein und muss deshalb mit höchster Vorsicht
behandelt werden.
Innerhalb des Prototyps von Deep Map kommunizieren verteilte Agenten über WLAN oder GSM. Die Ortung erfolgt in der Regel über (D-)GPS. Für die mobile Nutzung wird ein Wearable Computer“ eingesetzt,
”
der unter anderem aus einem Farbdisplay und einem Headset besteht. Ein Einsatz für herkömmliche mobile
Endgeräte ist nicht vorgesehen.
42
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Zusammenfassung
Leider unterliegen die meisten dieser Forschungsprojekte veralteten Annahmen. Eine oft gemachte Annahme ist zum Beispiel, die Funktionsunfähigkeit von GPS innerhalb von Gebäuden. Moderne GPSEmpfänger und vor allem A-GPS-Empfänger zeigen aber, dass eine Ortung mit GPS nicht nur unter
freiem Himmel stattfinden kann. GPS-Empfänger der nächsten Generation werden voraussichtlich sehr
verlässliche Ortsinformationen auch innerhalb von Gebäuden und sogar unter der Erde liefern können (vgl.
[glo a, sir ]).
Eine andere Annahme der Ortung ist, dass GPS-Empfänger unhandliche externe Geräte sind, die zur Ortung ständig mitgeführt werden müssen. Heutige externe GPS-Empfänger haben jedoch nur noch Ausmaße
von wenigen Zentimetern oder sind sogar in andere Geräte vollständig integriert. Aufgrund sicherheitspolitischer Anforderungen in den USA (E-911), Japan und Europa (E-112) kann sogar erwartet werden, dass
in Zukunft in einem Großteil der Mobiltelefone GPS-Empfänger integriert sein werden.
Einige Forschungsprojekte gehen von total unzuverlässigen MAN-Verbindungen aus. Die moderne Technik zeigt aber, dass diese Verbindungen bereits ein hohes Maß an Zuverlässigkeit liefern. Die Netzabdeckung innerhalb Deutschlands ist bereits nahe 100 Prozent (vgl. [gsm ]) und auch Regionen, die ursprünglich keine Netzabdeckung erhalten sollten, werden immer geringer. Als Beispiel kann die Luftfahrt
genannt werden. Voraussichtlich wird hier in wenigen Jahren auch innerhalb von Flugzeugen der Zugriff
auf MANs möglich sein.
Eine weitere Einschränkung der Forschungsprojekte ist, dass sie nicht auf die Anforderungen des MoBiLeServices ausgerichtet sind. Nur wenige gehen zum Beispiel auf die stark fluktuierende Geschwindigkeit
oder auf geringe Aufnahme- und Verarbeitungszeiten ein. Deshalb stellen die vorgestellten Projekte keine
adäquate Lösung für den MoBiLe-Service dar.
3.4.2
Kommerzielle Navigationsdienste
Neben diesen Forschungsprojekten brachten die letzten Jahre einige kommerzielle Navigationsdienste hervor. Besonders bekannt sind Navigationsgeräte für PKWs. Diese werden in der Regel fest in die Fahrzeuge
eingebaut und erfüllen nur den Zweck der Navigation. Ein weiteres Beispiel für Navigationsdienste, welche ebenfalls auf speziell dafür konzipierten Geräten genutzt werden, sind mobile Navigationsgeräte der
Firma Garmin oder Magellan. Sie sind hauptsächlich für sportliche Anwender wie zum Beispiel Wanderer
konzipiert. In letzter Zeit wurden ebenfalls einige Navigationsdienste auf den Markt gebracht, die nicht
nur auf speziell dafür ausgerichteten Geräten ausgeführt werden können. Geräte dieser Dienste sind zum
Beispiel Mobiltelefone oder PDAs.
Das folgende Kapitel zeigt einige dieser kommerziellen Navigationsdienste im Detail.
Navigationsdienste für dedizierte Geräte
Fahrzeugnavigationsgeräte Fahrzeugnavigationsgeräte sind dedizierte Geräte für die Navigation von
Fahrzeugen. Ihre Aufgabe ist es, den Fahrzeugführer durch Navigationsinformationen bei der Wegfindung
zu unterstützen. Die ersten Fahrzeugnavigationssysteme in Deutschland wurden von Bosch und Philipps
Mitte der 80er Jahre entwickelt (vgl. [Czom 00]. Heutzutage gibt es eine Vielzahl von Navigationsgeräten
verschiedenster Anbieter. Oft werden sie bereits bei der Fahrzeugproduktion integriert.
Die Ortung des Fahrzeugs erfolgt durch GPS. Da viele GPS-Empfänger aber derzeit noch keine verlässlichen Ortsinformationen innerhalb von Tunnels oder in anderen empfangsschwachen Gebieten liefern, wird
das Ortungssystem meist durch weitere Sensorinformationen unterstützt. Diese werden zum Beispiel durch
Radsensoren, durch das Tachosignal, durch einen traditionellen Kompass oder einen Kreiselkompass geliefert. Durch ein erweitertes Kalman-Filter können aus den unabhängig generierten Sensorinformationen
die benötigten reliablen Ortsinformationen erzeugt werden.
Fahrzeugnavigationssysteme beherrschen meist eine Präsentation von Navigationsinformationen mit Pfeilen, die durch die Angabe von Straßennamen und Entfernungen erweitert werden. Um den Fahrzeugführer
nicht unnötig abzulenken, ist in der Regel auch eine verbale Präsentation möglich. Zusätzlich bieten einige
3.4. BESTEHENDE NAVIGATIONSDIENSTE
43
Systeme eine Kartendarstellung an, die sich dynamisch mit der Bewegung verändert.
Routendienste für die Berechnung dynamisch generierter Routen sind bereits in den Navigationsgeräten
integriert (Onboard-Navigation). Die dazu nötigen Pfadinformationen befinden sich meist auf einer austauschbaren CD-ROM. Das Datenformat ist in der Regel im so genannten Geographic Data File (GDF)
Format [gdf 96] und wird zum Beispiel von NAVTEQ [nav ] geliefert. Dynamische Verkehrsinformationen
werden bei vielen Geräten über den Radio Data System Traffic Message Channel (RDS TMC-Kanal) in die
Routenberechnung mit einbezogen.
Leider sind derartige Systeme nur als bedingt mobil anzusehen, da sie nur eine Mobilität in Verbindung mit
dem Fahrzeug liefern. Sie können überall dort genutzt werden, wo eine Bewegung des Fahrzeugs möglich
ist. Erste Systeme, die ein einfaches Entfernen des Navigationssystems aus dem Fahrzeug erlauben, werden derzeit entwickelt. Eine Anwendung der Fahrzeugnavigationsgeräte ist aufgrund der unterschiedlichen
Anforderungen und Eigenschaften für den MoBiLe-Service nicht denkbar.
Mobile Navigationsgeräte Dedizierte echt-mobile“ Geräte zur Navigation zeichnen sich dadurch aus,
”
dass sie speziell für die mobile Navigation angefertigt wurden und nur zur Navigation genutzt werden
können. Hersteller sind zum Beispiel Garmin [gar ] oder Magellan [mag ] (vgl. Abb. 3.7). Die Geräte
verfügen über einen integrierten (D-)GPS-Empfänger und ein Display. Durch eine drahtgebundene Kommunikationsmöglichkeit lassen sich Routen in einem proprietären Datenformat auf das Endgerät laden.
Durch den integrierten GPS-Empfänger kann die Position innerhalb der Route bestimmt werden und dadurch der zukünftige Routenverlauf auf dem Display (z.B. in Pfeildarstellung) angezeigt werden. Zusätzliches Kartenmaterial ermöglicht eine Kartendarstellung.
Abbildung 3.7: Garmin eTrex und Magellan SporTrak
Durch ständige Ortung ist es außerdem möglich, Routen während der Bewegung aufzuzeichnen und diese
später wieder zu verwenden oder auf ein anderes Gerät zu übertragen. Zudem sind diese Geräte je nach
Anwendungszweck mit zusätzlichen Funktionen wie einem Kompass, einem Terminplaner oder Taschenrechner ausgestattet. Normalerweise besitzen sie aber keine drahtlose Kommunikationsmöglichkeit und
erlauben deshalb während des mobilen Einsatzes keine Aktualisierung des Datenbestandes und keine Beachtung dynamischer Informationen (z.B. Verkehrsinformationen).
Geräte, wie der Garmin eTrex oder der Magellan SporTrak, werden in heutiger Zeit vermehrt für das
Mountain-Biken eingesetzt. Nachteilig ist aber, dass sie meist einer sehr rigiden Navigation unterliegen
und deshalb keine Anpassung an verschiedene Transportarten erfolgen kann. Anforderungen des MoBiLeService werden nur bedingt umgesetzt. Dedizierte Navigationsgeräte haben außerdem einen weiteren
Nachteil. Aufgrund der Tatsache, dass viele Mountain-Biker für den Notfall ihr Mobiltelefon mitführen,
müssen bei der Navigation durch dedizierte Navigationsgeräte zwei Geräte transportiert werden, obwohl
im Grunde genommen heutige Mobiltelefone alle Anforderungen für Navigationsdienste erfüllen. Navigationsdienste für Mobiltelefone werden deshalb im folgenden Kapitel genauer betrachtet.
44
KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE
Navigationsdienste für Mobiltelefone/PDAs
Moderne Mobiltelefone zeichnen sich gegenüber ihren Vorgängern durch höhere Rechenleistung, mehr
Speicher, längere Akkulaufzeiten, etc. aus. Vor allem aber bieten sie eine immer größere Unterstützung zur
Integration für Anwendungen von Drittanbietern. Derzeit sind bereits einige Navigationsdienste für PDAs
oder Mobiltelefone auf dem Markt, die sich mehr oder weniger stark unterscheiden. Die bekanntesten Repräsentanten sind NavMe von b2motion, ActivePilot von Falk/Jentro, Mobile Navigator von Wayfinder,
Mobile 2005 von Route66 und Mobile 5 von TomTom (zur Übersicht vgl. [Zieg 04, Nieb 04, Hell 04] und
Tabelle 3.1 / 3.2).
Name
NavMe
ActivePilot
Mobile Navigator
Mobile 2005
Mobile 5
Hersteller
b2motion
Falk/Jentro
Wayfinder
Route 66
TomTom
Plattform
J2ME
J2ME mit CLDC1.0, MIDP2.0, JABWT, (LAPI)
Symbian
Symbian S60
Symbian S60 oder Windows Mobile
Tabelle 3.1: Kommerzielle mobile Navigationsdienste
Der NavMe [b2m ] ist ein Navigationsdienst von b2motion für Mobiltelefone und PDAs. Der Navigationsdienst läuft im Gegensatz zum Routendienst vollständig lokal auf dem mobilen Endgerät. Dies entspricht
einer Offboard-Lösung. Der Routendienst liefert dynamisch generierte Routen, deren Pfade von Webraska
[web ] geliefert werden. Zur Routenabfrage können PoIs aus 41 Rubriken (z.B. Tankstellen, Flughäfen,
Raststätten) verwendet werden. Die letzten fünf Routen können lokal als statische Routen gespeichert
werden. Zur Abfrage der Route wird entweder GPRS oder UMTS eingesetzt. Leider kann der Navigationsdienst nur über das spezielle GPS-Empfangsmodul eine automatische Ortung durchführen. Das GPSEmpfangsmodul kann aber nur bei Festeinbau in Fahrzeuge genutzt werden. Daraus ergibt sich eine pullbasierte Navigationslösung außerhalb von Fahrzeugen. Bei der Nutzung innerhalb von Fahrzeugen können
über das Autoradio dynamische Verkehrsinformationen über den RDS TMC-Kanal empfangen und in die
Routenwahl einbezogen werden.
Der ActivePilot [act ] von Falk/Jentro ist ein auf J2ME mit CLDC 1.0, MIDP 2.0 und JABWT aufbauender Navigationsdienst. Insgesamt (Code + Bilder/Sprachdaten) hat er eine Größe von ca. 750 Kilobyte
und kann zum Beispiel per GPRS auf das mobile Endgerät übertragen werden. Mit einem einfachen GPSEmpfänger mit Bluetooth-Schnittstelle kann über JABWT auf Ortsinformationen zurückgegriffen werden.
Der Navigationsdienst befindet sich komplett auf dem mobilen Endgerät, der Routendienst auf einem stationären Rechner (Offboard-Lösung). Der Routendienst liefert dynamisch generierte Routen, deren Pfade
von NAVTEQ [nav ] geliefert werden. Wie bei NavMe kann die Routenabfrage PoIs enthalten. Durch die
Routenabfrage wird aber keine komplette Route zum Navigationsdienst auf dem mobilen Endgerät übertragen, sondern immer nur Routensegmente. Diese werden jeweils dynamisch unter Einbeziehung von Verkehrsinformationen generiert. So ist gewährleistet, dass die Routensegmente an die aktuelle Verkehrslage
angepasst sind. Ausschlaggebend ist an dieser Stelle natürlich die Länge der Routensegmente. Zur Präsentation der Navigationsinformationen setzt der ActivePilot sowohl Sprache als auch eine 2D-Pfeildarstellung
(mit Zusatzinformationen) und seit der aktuellen Version auch eine 2D-Karte ein.
Der Navigationsdienst Mobile Navigator [mob ] von Wayfinder hat einen ähnlichen Funktionsumfang wie
der ActivePilot, basiert aber auf Symbian OS. Zusätzliche Funktionen sind die geschwindigkeitsabhängige
Kartenvergrößerung und die Möglichkeit Kartenmaterial bereits vor Routenantritt auf das mobile Endgerät
zu laden. Das Kartenmaterial kann zum Beispiel von einem stationären Rechner über eine Dockingstation oder mittels Bluetooth auf das mobile Endgerät übertragen werden. Dadurch spart sich der Nutzer
Gebühren bei der Routenauswahl, da das Kartenmaterial nicht über die GPRS-Verbindung übertragen werden muss.
Im Navigationsdienst Mobile 2005 [rou ] von Route 66 wurde eine Onboard-Lösung realisiert. Auf dem
mobilen Endgerät ist deshalb neben dem Navigationsdienst auch ein Routendienst integriert. Für die Speicherung aller Pfadinformationen für Deutschlands Straßen sowie 700.000 PoIs ist ein Speicherplatz von
256 Megabyte nötig. Die Daten stammen von NAVTEQ. Derzeit können nur Mobiltelefone mit einer extra
45
3.4. BESTEHENDE NAVIGATIONSDIENSTE
Name
NavMe
On-/Offboard
Offboard
Kommunikation
GPRS/UMTS
ActivePilot
Offboard
GPRS/UMTS
Mobile Navigator
Offboard
GSM/GPRS
Mobile 2005
Onboard
− (GPRS)
Mobile 5
Onboard
−
Präsentation
2D-Pfeil+
2D-Karte
Sprache
2D-Pfeil+
2D-Karte
Sprache
2D-Pfeil
2D-Karte
Sprache
2D-Pfeil+
2D-Karte
Pseudo-3D
Sprache
2D-Pfeil+
2D-Karte
Pseudo-3D
Tabelle 3.2: Eigenschaften kommerzieller mobiler Navigationsdienste
Speicherkarte derart viel Speicherplatz aufbringen. Mobile 2005 ist auf Mobiltelefonen mit Symbian Serie
60 ausführbar und beherrscht als Darstellungsformen zusätzlich zu der bereits genannten Pfeildarstellung
und Sprachausgabe auch die Möglichkeit Pseudo-3D-Karten darzustellen. Dabei kann der Blickwinkel frei
gewählt werden. Dynamische Verkehrsinformationen können via GPRS in die Routenberechnung integriert
werden.
Der Navigationsdienst Mobile 5 [tom ] von TomTom ist ähnlich aufgebaut wie der Mobile 2005. Er setzt
ebenfalls auf die Onboard-Lösung und benötigt dazu auch eine mindestens 256 Megabyte große Speicherkarte. Mobile 5 kann auf Mobiltelefonen mit Symbian Serie 60 und Windows Mobile eingesetzt werden.
Außerdem besitzt Mobile 5 eine spezielle Option für Radfahrer, die die Routengenerierung an die Anforderungen der Radfahrer anpasst.
Die oben beschriebenen mobilen Navigationsdienste für Mobiltelefone/PDAs zeigen bereits eine große
Funktionsvielfalt. Keines dieser Systeme beachtet aber die Anforderungen an den MoBiLe-Service. Manche Navigationsdienste ermöglichen zwar die Wahl des Transportmittels, verändern hierbei aber nur die
Routengenerierung. Einflüsse anderer Transportmittel ergeben sich aber nicht nur bei der Routengenerierung, sondern auch innerhalb des eigentlichen Navigationsprozesses. Dies wird leider von keinem der
genannten Navigationsdienste berücksichtigt.
Kapitel 4
Architektur
Das Kapitel Architektur“ behandelt die Konzeption des Location-based Push-Services. Aufgrund des Um”
fangs und der Komplexität des Gesamtsystems ist die Umsetzung in die Realität nicht als trivial anzusehen und benötigt deshalb eine detaillierte Planung der Architektur. Ziel dieses Kapitels ist es den Aufbau
des Systems mit all seinen Subsystemen, Abhängigkeiten der einzelnen Subsysteme, sowie Verteilung der
Subsysteme auf Hardwareentitäten, zu beschreiben. Außerdem soll vermittelt werden, wieso ein derartiger
Aufbau Sinn macht und wie sich einzelne Entscheidungen begründen lassen.
4.1 Aufbau
Eine Architektur beschreibt den strukturellen Aufbau eines Gesamtsystems. Während das Bauingenieurwesen sich um den Aufbau von Gebäuden, Straßen, etc. kümmert, ist die Aufgabe der Softwarearchitektur
die Konzeption eines komplexen Softwaresystems. Ein wesentlicher Schritt Softwaresysteme (aber auch
Systeme anderer Bereich) zu strukturieren, in einzelne Konzepte zu gliedern (vgl. [Dijk 76]) und sie so
begreifbar zu machen, ist die Klassifikation des Systems anhand bestimmter Klassifikationskriterien. Dieser Vorgang wird auch als Modularisierung bezeichnet und kann auf verschiedensten Abstraktionsstufen
erfolgen (vgl. [PCW 84]).
4.1.1
Generelle Architekturkonzepte
Auf einer hohen Abstraktionsstufe ist ein grundlegendes Klassifikationskriterium die Kohärenz. Dadurch
werden Module des Softwaresystems anhand ihrer semantisch-inhaltlichen Zusammengehörigkeit in Module eingeteilt. Nachfolgend werden angelehnt an [PCW 84, GaSh 93, MTSM 03] einige allgemeine Architekturkonzepte für diese Module kurz beschrieben.
Einer der wichtigsten Gründe für die Modularisierung und die daraus entstehenden Module ist als Se”
paration of Concerns“ [Dijk 76] bekannt. Die Modularisierung soll dazu dienen, ein komplexes, schwer
verständliches Gesamtsystem in einzelne einfacher verständliche Module aufzuspalten. Ziel ist es demnach, leicht verständliche Module zu schaffen, die unabhängig von anderen Modulen begreifbar sind (vgl.
[PCW 84]). Dazu ist eine geringe Kopplung zwischen den Modulen nötig. Eine geringe Kopplung wird
durch die Minimierung der Abhängigkeiten zwischen den einzelnen Modulen erzeugt. Abhängigkeiten
entstehen, wenn ein Modul über ein gewisses Grundwissen hinaus auf Wissen eines anderen Moduls angewiesen ist. Das Ergebnis der Modularisierung ist demnach optimal, wenn daraus eine Menge an stark
kohärenten Modulen mit geringer Kopplung resultiert.
Ein Vorteil der Modularisierung ist die Wiederverwendbarkeit der Module. Wiederverwendbarkeit bedeutet hierbei, dass einzelne Module innerhalb eines anderen Kontextes wieder eingesetzt werden können.
Dadurch wird eine Minimierung redundanter Funktionalität erzeugt. Außerdem wird die Fehlerrate gesenkt
46
47
4.1. AUFBAU
und Konsistenz gewahrt.
In direktem Zusammenhang mit der Wiederverwendbarkeit steht die Erweiterbarkeit. Durch die Modularisierung können Module nicht nur leicht wiederverwendet werden, sondern auch einfacher erweitert werden. Die Erweiterung der Funktionalität eines Moduls muss dadurch bei mehrfachem Auftreten nur einmal
durchgeführt werden. Wieder wird die Fehlerrate gesenkt und Konsistenz gewahrt. Außerdem können bei
Einhaltung der ursprünglichen Schnittstellen keine intermodularen Fehler durch die Erweiterung entstehen.
Ebenfalls in direktem Zusammenhang steht der Vorteil der Substituierbarkeit. Durch den modularen Aufbau können einzelne Module einfach ersetzt werden. Bedingung hierfür ist die Einhaltung der Schnittstellen
des ursprünglichen Moduls. Die Substituierbarkeit führt zu einer einfachen Anpassung des Gesamtsystems
durch das Ersetzen einzelner Module.
Dies führt zu einer hohen Flexibilität des Gesamtsystems. Durch Komposition einzelner Module kann das
Gesamtsystem sehr flexibel an Veränderungen angepasst werden. Anpassung betrifft dabei nicht das Gesamtsystem, sondern nur einzelne Module. Aus der Flexibilität folgt außerdem eine einfache Reaktion auf
Fehler, die meist nur einzelne Module betreffen.
Fehler innerhalb von Modulen können durch die Modularisierung einfacher gefunden und behoben werden. Die Modularisierung führt demnach auch zu einer verbesserten Wartbarkeit und Verlässlichkeit des
Gesamtsystems.
Um einzelne Module nicht im Vorhinein an spezielle Plattformen zu binden, ist eine plattformunabhängige
Umsetzung sinnvoll. So kann erst zu einem späterem Zeitpunkt oder gar zur Laufzeit entschieden werden,
auf welcher Plattform das Modul ausgeführt werden soll.
4.1.2
Modularisierung
Betrachtet man für die Modularisierung den in Kapitel 2.1 beschriebenen Navigationsprozess, so ergeben
sich hieraus drei funktionale Module. Ein Modul ist zuständig für die Ortung und Initiierung der Routenführung. Anhand der durch die Ortung gelieferten Ortsinformationen muss geprüft werden, ob eine
Routenführung angestoßen werden soll. Dieses Modul wird im Folgenden mit Dienstinitiierung bezeichnet.
Das zweite Modul ist für die Routenführung. Die Routenführung ist für die Generierung von Navigationsinformationen verantwortlich. Dazu wird aus einer Menge deklarativen Wissens (Routenwissen, Ortsinformationen des Nutzers, Nutzereigenschaften oder andere Kontextinformationen) eine Navigationsinformation generiert, die dem Nutzer die zum Zeitpunkt der Ausführung bestmögliche Orientierungshilfe
bereitstellt. Dieses Modul wird im Folgenden mit Dienstausführung bezeichnet.
Schließlich präsentiert ein drittes Modul die oben generierte Navigationsinformation dem Nutzer. Um sie
dem Nutzer zu übermitteln, muss sie in eine geeignete Form gebracht werden. Verschiedenste grafische
oder verbale Darstellungen sind Beispiele derartiger Präsentationsformen. Ziel ist, dem Nutzer die Information in einer Form zu übermitteln, die am bestmöglichen seinen derzeitigen Anforderungen entspricht.
Dieses Modul wird im Folgenden mit Dienstpräsentation bezeichnet.
Die Dienstinitiierung (Service Initiation), Dienstausführung (Service Application) und Dienstpräsentation
(Service Presentation) stellen die essentiellen Bestandteile der LBPS-Architektur dar (vgl. Abb. 4.1).
Service
Initiation
Service
Application
Service
Presentation
Abbildung 4.1: Klassifikation anhand Kohärenzkriterium
Vorteil des Aufbaus ist die strikte Modularisierung der Teilbausteine. Während sich die Dienstinitiierung
nur darum kümmert, den Dienst zum bestmöglichen Zeitpunkt anzustoßen, ist die Dienstausführung alleine für die Informationsgenerierung verantwortlich. Die Vermittlung der generierten Information übernimmt ausschließlich die Dienstpräsentation. Aus diesem Aufbau resultiert eine leichte Substituierbarkeit,
48
KAPITEL 4. ARCHITEKTUR
Erweiterbarkeit, Wartbarkeit der einzelnen Module, sowie hohe Flexibilität des Gesamtsystems.
4.1.3
Schichtenstruktur
Wie man bereits erkennen kann, ist es möglich, zwischen den einzelnen Modulen Abhängigkeitsrelationen anzugeben. Die Dienstinitiierung nutzt die Dienstausführung zur Generierung des Mehrwertes, und
die Dienstausführung nutzt die Dienstpräsentation, um dem Nutzer das Ergebnis zu übermitteln. Diese
Abhängigkeit beschreibt die reguläre Abhängigkeitsstruktur der Module. In Einzelfällen kann es auch
vorkommen, dass Abhängigkeiten entgegengesetzt ihrer ursprünglichen Richtung eintreten. So zum Beispiel, wenn die Dienstpräsentation eine bestimmte Information nicht verarbeiten kann und deshalb die
Dienstausführung nutzt, um alternative Informationen zu erhalten, oder die Dienstausführung die Dienstinitiierung nutzt, um die Initiierungsvorschrift zu ändern. Es existiert jedoch keine direkte gegenseitige
Abhängigkeit zwischen Dienstpräsentation und Dienstinitiierung.
Letztes Element in der beschriebenen Abhängigkeitsstruktur ist der Nutzer selbst. Er wartet während der
Dienstnutzung darauf, dass ihm Informationen zugestellt werden. Diese Aufgabe übernimmt die Dienstpräsentation. Sie nutzt die menschliche Wahrnehmung, um dem Nutzer die Informationen zu vermitteln,
die er sich durch die Dienstnutzung erhofft.
Ein derartiges Konzept, in dem einzelne Module in einem gerichteten, linearen Abhängigkeitsverhältnis
stehen, führt zu einer Schichtenstruktur (vgl. Abb. 4.2 und [BMR+ 96]). Eine Schicht (engl. Layer) in ihrer
ursprünglichen Form ist ein logischer Baustein, der einen Dienst einer darunter liegenden Schicht nutzt,
um so einen Dienst der darüber liegenden Schicht anzubieten (vgl. [GaSh 93]).
Presentation
Application
Initiation
Abbildung 4.2: Schichtenaufbau der LBPS-Architektur
Diese Sichtweise bezieht sich jedoch auf Pull-Dienste. Im Gegensatz dazu nutzen Push-Dienste, wie in
Kapitel 2.2 beschrieben, den Dienst einer darüber liegenden Schicht, um einen Dienst der darunter liegenden Schicht anzubieten. Im Fall der Navigationsdienste nutzt die Schicht der Dienstinitiierung die Schicht
der Dienstausführung und diese dann die Dienstpräsentation, um letztendlich mit Hilfe der menschlichen
Wahrnehmung dem Nutzer die Navigationsinformation zu übermitteln.
4.1.4
Middleware Integration
Im vorigen Kapitel wurde bereits beschrieben, dass innerhalb der Dienstpräsentation verschiedenste
Präsentationsformen zum tragen kommen können. Für die Navigation stehen hier zum Beispiel eine
grafische Pfeildarstellung, eine grafische Landkartendarstellung oder eine verbale Richtungsangabe zur
Verfügung. Die Schicht der Dienstpräsentation unterteilt sich deshalb in verschiedene unabhängige Präsentatoren, die spezifische Präsentationsformen verwirklichen. Mehrere Präsentatoren können dabei parallel
existieren. Innerhalb des Navigationsdienstes können dadurch grafische Richtungsanweisungen durch kongruente verbale Anweisungen unterstützt werden.
49
4.1. AUFBAU
Gleiches gilt für die Dienstinitiierung. Hier können diverse Initiatoren parallel existieren. Beispiele sind
positionsabhängige Initiatoren oder Initiatoren, die zusätzlich zu positionsabhängigen auch richtungsabhängige Initiierungsvorschriften verwalten können. Desweiteren können verschiedene Initiatoren mit unterschiedlichen Genauigkeiten und Verzögerungen arbeiten oder bestimmte Initiatoren nur für spezifische
Personengruppen einsetzbar sein. Möglich wäre an dieser Stelle natürlich auch die Initiierung bezüglich
jeglicher anderer Kontextinformation, wie Zeit, Wetter oder Ortskenntnis des Nutzers. Diese Art von Kontextinformationen soll hier allerdings nicht im Vordergrund stehen. Abbildung 4.3 a) zeigt eine Applikation
mit drei Präsentatoren und drei Initiatoren. Allgemein besteht zwischen Präsentatoren, Applikation und Initiator eine n:1:m-Beziehung. Darunter wird verstanden, dass die Navigationsapplikation n Präsentatoren
und m Initiatoren hat.
Aufgrund des Abhängigkeitsverhältnisses zwischen Dienstausführungsschicht und Dienstpräsentationsschicht muss die Dienstausführungsschicht wissen, welche Präsentatoren verfügbar sind, welche Eigenschaften diese besitzen und wie sie angesprochen werden. All diese Informationen bzw. Funktionen müssen
innerhalb der Dienstausführungsschicht verfügbar sein. Bei einer großen Anzahl an Präsentatoren erhöht
sich der Aufwand für den Zugriff auf die Dienstpräsentationsschicht innerhalb der Dienstausführungsschicht deshalb enorm.
Äquivalentes gilt für die Dienstinitiierungsschicht. Um Initiierungsvorschriften in den Initiatoren zu
ändern, greift die Dienstausführungsschicht entgegen der eigentlichen Abhängigkeitsstruktur auf die
Dienstinitiierungsschicht zu. Dazu braucht die Dienstausführungsschicht Kenntnis über alle verfügbaren
Initiatoren, deren Eigenschaften und deren Zugriffsmöglichkeiten. Wie bei der Dienstpräsentationsschicht
kann bei einer Vielzahl an Initiatoren ein enormer Aufwand für den Zugriff auf die Dienstinitiierungsschicht innerhalb der Dienstausführungsschicht entstehen.
a)
b)
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation
Presentation Middleware
Application
Application
Initiation Middleware
Initiation
Initiation
Initiation
Initiation
Initiation
Initiation
Abbildung 4.3: Middleware Integration
Zur Lösung dieses Problems dienen zwei zusätzliche Schichten, die als Middleware fungieren. Die
Initiierungsmiddleware (Initiation Middleware) liegt zwischen Dienstinitiierungsschicht und Dienstausführungsschicht und abstrahiert über die verschiedenen Initiatoren. Die Präsentationsmiddleware
(Presentation Middleware) liegt zwischen Dienstausführungsschicht und Dienstpräsentationsschicht und
abstrahiert verschiedene Präsentatoren (vgl. Abb. 4.3 b).
Aufgabe der Präsentationsmiddleware ist es, der Dienstausführungsschicht eine einheitliche Schnittstelle
für die Präsentation von Nutzerinformationen zu liefern. Die Kenntnis über entsprechende Präsentatoren
ist in der Präsentationsmiddleware gekapselt. Sie weiß, welche Präsentatoren derzeit verfügbar sind, welche Präsentationsformen diese darstellen können, welche sonstigen Restriktionen zu beachten sind und
wie auf die Präsentatoren zugegriffen werden kann. Die von der Dienstausführungsschicht übermittelten
Navigationsinformationen werden durch die Präsentationsmiddleware für die jeweilige Präsentationsform
angepasst und anschließend an die entsprechenden Präsentatoren übermittelt.
Werden von der Dienstausführungsschicht Initiierungsvorschriften, die die Dienstausführung auslösen
sollen, generiert, müssen diese an die entsprechenden Initiatoren verteilt werden. Diese Aufgabe übernimmt die Initiierungsmiddleware. Sie nimmt Initiierungsvorschriften entgegen, passt sie gegebenenfalls
den zuständigen Initiatoren an und übermittelt sie schließlich an diese. Dazu hat sie Kenntnis über alle
50
KAPITEL 4. ARCHITEKTUR
verfügbaren Initiatoren, deren Fähigkeiten, Eigenschaften und deren Zugriffsmöglichkeiten.
Ein weiterer Vorteil, der sich aus der Integration der Middlewareschichten ergibt, wird bei der Erweiterung
der Dienstausführungsschicht sichtbar. Prinzipiell ist diese nicht an Navigationsapplikationen gebunden.
Es ist ebenso gut möglich, andere Applikationen in der Dienstausführungsschicht zu platzieren. Denkbar
sind hier Dienste, wie der in Kapitel 2.2 vorgestellte ortsbasierte Email-Push-Dienst, der Emails nur bei
örtlicher Relevanz zustellt. Initiierungsvorschriften für einen derartigen Dienst müssten dann zum Beispiel
die Position des Büros spezifizieren und der entsprechende Initiator so die Dienstausführung bei örtlicher
Nähe zum Büro anstoßen. Die Applikation selektiert daraufhin alle Emails, die an die Firmenadresse gerichtet sind und teilt diese dem Nutzer mittels eines entsprechenden Präsentators mit. Insgesamt ergibt sich
so eine n:k:m-Beziehung zwischen Initiatoren, Applikationen und Präsentatoren. Abbildung 4.4 zeigt zwei
Applikationen, für deren Initiierung drei Initiatoren bereit stehen und deren Präsentation durch drei Präsentatoren ermöglicht wird.
Presentation
Presentation
Presentation
Presentation Middleware
Application
Application
Initiation Middleware
Initiation
Initiation
Initiation
Abbildung 4.4: LBPS-Architektur mit mehreren Applikationen
Diese Arbeit fokussiert Applikationen für die Navigation. Die Fähigkeit, andere Dienste wie den ortsbasierten Email-Push-Dienst auf einfache Art und Weise zu integrieren, zeigt aber, dass dieser Aufbau nicht
zwingend auf Navigationsdienste beschränkt ist, sondern ebenso eine Vielzahl anderer Push-Dienste mit
Hilfe der Architektur realisierbar ist.
4.2
Schichtenmodell
Dieses Kapitel beschreibt detailliert die im vorigen Kapitel identifizierten Schichten Dienstinitiierung, Initiierungsmiddleware, Dienstausführung, Präsentationsmiddleware und Dienstpräsentation in Hinblick auf
Navigationsdienste. Dabei soll hier nicht auf spezielle Ausprägungen der einzelnen Schichten eingegangen
werden, sondern allgemein die Funktionsweise der Schichten erörtert werden. Eine Betrachtung spezieller
Initiatoren, Präsentatoren, etc. folgt in Kapitel 5, in dem die Implementierung des Demonstrators beschrieben wird.
4.2.1
Dienstinitiierung
Wie bereits in vorigem Kapitel erwähnt wurde, ist die Dienstinitiierungsschicht die unterste Schicht dieses
Schichtenmodells und verantwortlich dafür, die Dienstausführung anzustoßen. Entscheidende Fragestellungen sind, was eine Dienstinitiierung ausmacht und wann diese durchzuführen ist. Ausschlaggebend sind auf
der einen Seite die in den Initiierungsvorschriften spezifizierten Anforderungen der Dienstausführung, d.h.
in diesem Fall der Navigationsapplikation, und andererseits die realen Gegenwerte dieser Anforderungen.
Die realen Werte werden durch physische oder logische Sensoren erfasst. Sensoren liefern zu bestimmten
4.2. SCHICHTENMODELL
51
Zeitpunkten oder kontinuierlich Messwerte. Im Rahmen dieser Arbeit werden diskrete Zeitpunkte vorausgesetzt, an denen Messwerte aktualisiert werden. Dies ist keine Beschränkung der Allgemeinheit, da eine
Diskretierung bei kontinuierlichen Aktualisierungen durch Abtastung des Messwertes zu diskreten Zeitpunkten erreicht werden kann. Die gemessenen Werte stehen dann den Anforderungen für die Initiierung
der Applikation gegenüber. Durch die Auswertung der Initiierungsvorschrift und der Messwerte wird bestimmt, ob die Dienstausführung initiiert werden soll oder nicht.
Hierbei besteht eine enge Kopplung zwischen Sensoren und der Komponente, die die Auswertung der
Initiierungsvorschriften durchführt. Andere Ansätze sehen an dieser Stelle eine sehr lose Kopplung und
separieren die Auswertungskomponente von den Sensoren. In diesem Zuge erfolgt eine Integration der
Auswertungskomponente in die Dienstausführungsschicht mit dem Resultat, dass bei einer hohen Aktualisierungsfrequenz der Sensorinformationen, diese in häufigen Abständen zur Auswertungskomponente
befördert werden müssen. Dadurch entsteht ein reger Informationsaustausch zwischen dem Sensormodul
und der Dienstausführungsschicht, die nun für die Auswertung zuständig ist. Oft ist ein intermodularer
Informationsaustausch aber mit Kosten verbunden und sollte deshalb vermieden werden.
Wird ein Informationsaustausch bei jeder Aktualisierung von Sensorinformationen angestoßen, ist dies oft
unnötig, da die Informationen nie zum Einsatz kommen, bzw. aus der Auswertung keine Dienstinitiierung erfolgt. Um dem entgegenzuwirken, wurden einige Strategien entwickelt, die diesen Informationsaustausch optimieren [LeRo 00, KüTr 05]. Im Bereich der Location-based Services sind diese Strategien unter
Location-Update-Strategien bekannt. Einige Beispiele sind zeitbasierte, distanzbasierte oder zonenbasierte
Location-Update-Strategien. Sie bewirken, dass der Informationensaustausch zwischen den Modulen nicht
mehr bei jeder Aktualisierung erfolgt, sondern nur noch wenn bestimmte Zeitpunkte erreicht werden, wenn
sich die Position um eine bestimmte Distanz verändert hat oder wenn eine Zone betreten oder verlassen
wird. Dadurch wird versucht, nur noch Sensorinformationen zur Dienstausführungsschicht zu befördern,
aus denen nach der Auswertung eine Dienstausführung resultiert.
Diese Arbeit versucht der Problematik aus dem Weg zu gehen, indem die Auswertungskomponente an die
Sensoren gekoppelt wird. Durch die enge Kopplung entfällt die Problematik des unnötigen intermodularen
Informationsaustausches, da sich der Informationsaustausch zwischen Sensoren und Auswertungskomponente nur innerhalb der Dienstinitiierungsschicht vollzieht (intramodularer Informationsaustausch). Alle
Aktualisierungen von Sensorinformationen werden an die Auswertungskomponente geliefert, die sich wie
die Sensoren innerhalb der Dienstinitiierungsschicht befindet. Folgt aus der Auswertung eine Dienstinitiierung, wird die Dienstausführungsschicht mittels einer Initiierungsnachricht darüber informiert. Dieser
Vorgang reduziert den intermodularen Informationsaustausch auf das Nötigste.
Durch diese Art der Initiierung ergibt sich ein weiterer Vorteil. Wird die Dienstausführung ohne Nutzung
von Ortsinformationen durchgeführt (z.B. ortsbasierter Email-Push-Dienst), werden zwischen den Sensoren und der Dienstausführung keinerlei Ortsinformationen ausgetauscht. Bei einer Dienstinitiierung innerhalb der Dienstausführungsschicht würden Ortsinformationen in die Dienstausführungsschicht befördert,
um den Dienst gegebenenfalls anzustoßen. Diese würden aber nicht bei der Dienstausführung eingesetzt,
was zu einem unnötigen Informationsaustausch führen würde. Diese Art von Diensten fallen in die Kategorie Location-based Push - Conventional Execution (vgl. Kapitel 2.2). Für diese Kategorie optimiert der
hier verfolgte Ansatz zudem die Menge an ausgetauschten Ortsinformationen.
Einen ähnlichen Aufbau verfolgt auch das Spatial Subscription Model von [CCR 03]. Dort werden Spatial
Predicates an so genannte Mobile Location Agents gesendet und von diesen ausgewertet. Mobile Location Agents stellen im Kontext dieser Arbeit Initiatoren dar. Werden die registrierten Prädikate erfüllt, so
erfolgt eine Benachrichtigung. Dies entspricht der Dienstinitiierung, die im Rahmen dieser Arbeit eingesetzt wird. Leider sind in [CCR 03] derzeit nur distanz- und zonenbasierte Spatial Predicates möglich,
welche zur Realisierung des MoBiLe-Service nicht ausreichen. Eine Analyse der Initiierungsvorschriften
des MoBiLe-Service wird im Folgenden behandelt.
Trigger
Initiierungsvorschriften spezifizieren Anforderungen für die Initiierung des Dienstes. Eine einfache Anforderungen für die Initiierung des Navigationsdienstes ist das Überlagern der Nutzerposition mit einem Aktionspunkt. Reale Messgrößen für die Nutzerposition können beispielsweise durch einen GPS-Empfänger
52
KAPITEL 4. ARCHITEKTUR
erzeugt werden. GPS-Empfänger führen in der Regel periodische Aktualisierungen, zum Beispiel in Sekundenintervallen, durch. Durch die Bewegung des Dienstnutzers verändert sich dessen Position bis die
Anforderungen der Dienstinitiierung mit der gemessenen Position übereinstimmen. Durch die Auswertung
der Initiierungsvorschrift und der Messwerte wird diese Konstellation automatisch erkannt und die Navigationsapplikation ohne Zutun des Nutzers angestoßen.
Derart einfache Anforderungen werden zum Beispiel in [Brow ] in Form von Notes eingesetzt. Durch Notes
werden sowohl Initiierungsvorschriften als auch Messgrößen definiert. Dazu werden wie bei den Spatial
Predicates von [CCR 03] Key-Value-Paare eingesetzt. Der Key gibt die Art der Messgröße und der Value
den Wert an, den diese Messgröße annimmt oder annehmen soll. Die Dienstinitiierung wird ausgelöst, wenn
gemessene Key-Value-Paare mit den Key-Value-Paaren der Initiierungsvorschrift übereinstimmen. Genauer gesagt, muss für jedes Feld F innerhalb eines Notes N, das den selben Namen wie eine Messgröße besitzt,
der Wert von F mit dem Wert des entsprechenden Messwertes übereinstimmen. Eine Übereinstimmung resultiert bei Gleichheit der beiden Werte oder falls der Messwert innerhalb des in der Initiierungsvorschrift
spezifizierten Intervalls liegt. Der Dienstinitiierungsnachricht werden zusätzlich alle Key-Value-Paare angehängt, die bei der Übereinstimmung nicht eingesetzt wurden. Ein Note der Initiierungsvorschrift kann
damit wie folgt aussehen (Beispiel aus [Brow ]):
<location> Westgate
<temperature> 10..30
<body> This is the Westgate
Stehen dieser Initiierungsvorschrift die folgenden Messwerte gegenüber:
<location> Westgate
<temperature> 25
wird die Dienstinitiierung mit diesem Key-Value-Paar ausgelöst:
<body> This is the Westgate
[Brow ]s Notes fanden in zahlreichen Projekten Anwendung, die sich von Touristenführern über ökologische bis hin zu archäologischen Anwendungen erstreckten. [Brow ] sieht in dieser einfachen Art der
Dienstinitiierung bereits ein sehr breites Feld an Anwendungsgebieten.
Probleme bei der Beschreibung von Initiierungsvorschriften mit Key-Value-Paaren treten jedoch auf, wenn
man komplexe Initiierungsvorschriften definieren will. Derartige komplexe Anforderungen können bei Navigationsdiensten auftreten. Es ist nämlich nicht praktikabel, nur bei einer exakten Übereinstimmung der
Nutzerposition mit dem Aktionspunkt den Dienst zu initiieren. Ein wesentlicher Nachteil ist, dass sich
der Nutzer, um eine Navigationsinformation zu erhalten, genau auf den definierten Aktionspunkt bewegen muss, was vor allem auch wegen der Ungenauigkeit der Messwerte in der Realität (vgl. Kapitel 3.1)
schwer realisierbar ist. Desweiteren besitzt dieser Ansatz auch eine beschränkte Sinnhaftigkeit, da eine
Navigationsinformation nicht erst genau an der Stelle des Aktionspunktes nötig ist, sondern bereits in einem gewissen Abstand davor, um vom Nutzer noch rechtzeitig wahrgenommen und umgesetzt werden zu
können. Der Aktionspunkt muss also um einen Aktionskreis erweitert werden (vgl. Abb. 4.5). Befindet
sich die Nutzerposition innerhalb dieses Aktionskreises, d.h. ist der Abstand zwischen Nutzerposition und
Aktionspunkt unterhalb eines bestimmten Schwellwertes, muss der Dienst initiiert werden.
Dies kann durch Key-Value-Paare nur bedingt umgesetzt werden. Problem ist, dass ein Key-Value-Paar nur
eine Messgröße mit einem bestimmten Wert oder Intervall spezifizieren kann. Zur Spezifikation von Aktionskreisen müssen innerhalb einer Anforderungsspezifikation mehrere Messgrößen in Betracht gezogen
werden. Entscheidend ist der Abstand zum Aktionskreismittelpunkt, d.h. die Relation zwischen Abstand
auf der x-Achse und dem Abstand auf der y-Achse. Dazu müssen neben Vergleichsoperationen mathematische Operationen auf die Messgrößen anwendbar sein. Durch das Zulassen mehrerer Messgrößen und
mathematischer Operationen innerhalb einer Anforderungsspezifikation wird eine stärkere Ausdruckskraft
erreicht. Der Aktionskreis mit dem Radius r um den Ursprung könnte so mittels folgendem Ausdruck
dargestellt werden (x bzw. y stellen den Abstand bzgl. der x- bzw. y-Achse zwischen Nutzer und Aktionskreismittelpunkt innerhalb eines kartesischen 2D-Koordinatensystems dar):
x2 + y 2 ≤ r2
53
4.2. SCHICHTENMODELL
r
Abbildung 4.5: Aktionskreis um Aktionspunkt mit Aktionsradius r
Jedoch stellt sich die Frage, wie groß der Radius r gewählt werden muss. Bei genauerer Betrachtung stellt
man fest, dass eine Vielzahl an Parametern für die Bestimmung des Radius herangezogen werden muss.
[ZiAr 02] nennt unter anderem das physische Befinden des Nutzers (abhängig von Alter, Fitness, etc.), das
Wetter (z.B. Regen, Schnee, Nebel), die Ortskenntnis des Nutzers, Umgebungsstruktur (z.B. bergig oder
flach, bebaut oder unbebaut) und die Steigung der Umgebung. Neben all diesen Einflussparametern, gibt
es eine noch nicht genannte Einflussgröße, die vor allem beim Mountain-Biken von Interesse ist. Dies ist
die Geschwindigkeit des Nutzers. Mountain-Biker sind stark fluktuierenden Geschwindigkeiten ausgesetzt.
Bergauf bewegen sie sich zeitweise mit weniger als 3 Stundenkilometern, bergab hingegen können über 60
Stundenkilometer erreicht werden. Die Dauer bis zum Erreichen des Aktionspunktes kann bei einem Radius von 5 Metern also zwischen 0,6 und 12 Sekunden annehmen. Während 0,6 Sekunden zur Wahrnehmung
und Umsetzung der Richtungsänderung in den meisten Fällen zu kurz sein dürfte, sind 12 Sekunden dafür
zu lange. t sei im Folgenden der Wert, der eine adäquate Dauer für die Wahrnehmung und Umsetzung
der Richtungsänderung repräsentiert. Die Lösung des Problems ist, den Radius des Aktionskreises an die
Fahrgeschwindigkeit v anzupassen. Folgender logischer Ausdruck setzt dies um:
x2 + y 2 ≤ (t · v)2
Der Ausdruck beschreibt einen Kreis, dessen Radius abhängig von der Geschwindigkeit v ist. Er macht
es möglich, dass die Informationen über die Richtungsänderung zu einem Zeitpunkt zugestellt werden,
der dem Nutzer den für ihn besten Nutzen bietet. In diesem Fall sind dies t Sekunden vor Erreichen des
Aktionspunktes. Nach Auflösen von x und y erhält man letztendlich den logischen Ausdruck, der den
Anforderungen des MoBiLe-Service entspricht:
(ux − ax )2 + (uy − ay )2 ≤ (t · v)2
Die Position des Aktionspunktes a wird hier durch (ax , ay ) und die Position des Nutzer durch (ux , uy )
beschrieben.
Befindet sich der Nutzer außerhalb des Aktionskreises, so liefert die Auswertung, dass der Ausdruck nicht
wahr ist. Wenn der Nutzer innerhalb des Aktionskreises ist, wird der Ausdruck als wahr ausgewertet. Doch
zu welchem Zeitpunkt muss der logische Ausdruck überhaupt ausgewertet werden? Eine Veränderung
der Auswertung kann nur bei einer Veränderung der Initiierungsvorschrift oder der Messwerte eintreten.
In diesem Szenario kann davon ausgegangen werden, dass die Initiierungsvorschrift relativ statisch ist
und die Messwerte demgegenüber häufigeren Änderungen unterliegen. Deshalb spielt die Veränderung der
Messwerte die entscheidende Rolle für den Zeitpunkt der Auswertung. [Brow ] bezeichnet diesen Fall, in
dem sich Messwerte wesentlich häufiger ändern als die Initiierungsvorschrift, als Information Filtering im
Gegensatz zu Information Retrieval.
Wie bereits beschrieben, werden Messwerte durch Sensoren generiert. Sie werden zu diskreten Zeitpunkten
von den Sensoren zur Verfügung gestellt. Eine vereinfachende Annahme dieser Arbeit ist, dass alle nötigen
Messwerte gleichzeitig bereitgestellt werden. Zu diesen Zeitpunkten kann eine Änderung bei der Auswertung des logischen Ausdrucks eintreten und dadurch eine Dienstinitiierung nötig werden. Folglich kann jede Veränderung von Messwerten eine Veränderung des Auswertungsergebnisses nach sich ziehen. Deshalb
müsste nach jeder Veränderung eines Messwertes der logische Ausdruck ausgewertet werden. Jedoch muss
54
KAPITEL 4. ARCHITEKTUR
nicht jede Veränderung von Messwerten für die Auswertung relevant sein. So sind zum Beispiel in obiger
Initiierungsvorschrift Sensoren vertreten, die Positions-, Geschwindigkeits- und Richtungsinformationen
liefern. Eine Veränderung von Richtungsinformationen zieht in Anbetracht des MoBiLe-Service keinerlei
relevanter Ereignisse nach sich und ist nicht im logischen Ausdruck enthalten. Für die Auswertung muss
eine Veränderung der Richtungsinformation nicht beachtet werden. Die Geschwindigkeit hingegen ist Bestandteil des logischen Ausdrucks. Eine Veränderung stellt aber für die Auswertung keine aktive Rolle dar,
da eine Veränderung der Geschwindigkeit des Dienstnutzers bei Navigationsdiensten in der Regel keine
direkten Auswirkungen auf die Dienstinitiierung hat. Ganz anders ist es bei den Positionsinformationen.
Verändert sich die Position des Nutzers, so kann es sein, dass er sich in den Aktionskreis bewegt hat und der
Dienst deshalb initiiert werden muss. Folglich muss nach einer Aktualisierung der Positionsinformationen
die Initiierungsvorschrift ausgewertet und darauf gegebenenfalls der Dienst initiiert werden.
Für Dienste der Kategorie Location-based Push - Conventional Execution (vgl. Kapitel 2.2) sind dann zur
Dienstausführung keine weiteren Ortsinformationen mehr nötig. Für die Kategorie Location-based Push Location-based Execution werden zur Dienstausführung jedoch Ortsinformationen benötigt. Diese müssen
nicht zwingend mit den Ortsinformationen, die für die Initiierung verantwortlich waren, übereinstimmen.
Werden sie aber von den Sensoren der Dienstinitiierung bereitgestellt, können sie von diesen abgefragt
oder analog zu [Brow ] bei der Dienstinitiierung mitgeliefert werden. [Brow ] liefert bei der Dienstinitiierung alle Key-Value-Paare mit, die für die Übereinstimmung der Initiierungsvorschrift mit den Messgrößen
nicht nötig waren. Problem dieses Ansatzes ist aber, dass manche Dienste genau die Werte benötigen, die
bei der Übereinstimmung relevant waren. Dies gilt vor allem bei komplexeren Bedingungen, bei denen
nicht direkt klar ist, welcher genaue Messwert die Übereinstimmung ausgelöst hat. Außerdem liefern Sensoren, wie GPS-Empfänger, eine Vielzahl an Messwerten (vgl. Kap. 3.1), von denen nur ein Bruchteil für
die Dienstausführung von Interesse ist. Als sinnvoll stellt sich an dieser Stelle deshalb eine detaillierte Angabe aller Messgrößen, die für die Dienstausführung benötigt werden, heraus. Diese werden dann an die
Initiierungsnachricht angehängt und sind so bei jeder Dienstausführung verfügbar.
Die in den letzten Absätzen definierten Aspekte für die Dienstinitiierung sind auch unter dem Begriff Trigger ([Brow , HLP , SAW 94]) bekannt.
ECA-Regeln
Desweiteren braucht man einen Mechanismus, der das abstrakte Konstrukt des Triggers operationalisierbar
macht. Die Ausdruckskraft von Key-Value-Paaren reicht an dieser Stelle nicht aus. Auch die in XML serialisierten Kontext-Trigger aus [SMLP ] sind für diesen Anwendungszweck nur bedingt geeignet, da ihnen
die Möglichkeit fehlt, relevante Messgrößen für den Auswertungszeitpunkt zu spezifizieren, und Aktionen
nicht an Trigger gebunden sind.
Ein Mechanismus aus einem ganz anderen Bereich sind ECA-Regeln [sql 99, HLP ]. ECA-Regeln stammen aus dem Bereich der Datenbanken und beschreiben Ereignisse (Events), bei deren Eintreten eine
Bedingung (Condition) ausgewertet und dann gegebenenfalls eine Aktion (Action) ausgeführt wird. ECARegeln bestehen demnach aus drei Teilen: den Ereignissen, der Bedingung und den Aktionen. Während
die Bedingung nur einmal auftritt, können Ereignisse und Aktionen in beliebiger Anzahl enthalten sein.
Ereignisse definieren die Menge an Messwerten, die bei einer Aktualisierung eine Auswertung der Bedingung nötig machen. Das heißt, dass sobald eine Aktualisierung der Messwerte erfolgt ist und der Messwert
ein Element der Ereignismenge ist, die Bedingung ausgewertet werden muss. Im Normalfall, jedoch nicht
zwingend, sind diese Messwerte als freie Variable in der Bedingung enthalten. So zum Beispiel bei der
Navigation: Wird eine Aktualisierung der Positionsinformationen durch den Sensor gemeldet, so wird in
der Bedingung geprüft, ob die Position innerhalb des Aktionskreises liegt.
Desweiteren muss in einer ECA-Regel die Bedingung angegeben werden, die maßgeblich für das Auslösen
der Aktion ist. Bedingungen werden hier durch logische Ausdrücke operationalisiert, die Variablen für
Messwerte besitzen. Jeder Variablen muss daher ein Typ zugeordnet werden, der dem Typ eines Messwertes entspricht. Liefert ein GPS-Empfänger Latitudenwerte im WGS84-Format und die Bedingung enthält
eine Variable mit eben diesem Typ, so muss die Variable in Folge der Auswertung durch den gelieferten Messwert ersetzt werden. Desweiteren können innerhalb des logischen Ausdrucks mathematische
Standardoperationen, wie die Addition, Subtraktion, Multiplikation und Division, und Vergleichsoperato-
4.2. SCHICHTENMODELL
55
ren, wie =, ! =, <, <=, > und >=, genutzt werden. Hilfreich sind außerdem weitere Operationen wie
Potenzieren und Radizieren, sowie trigonometrische Funktionen (Sinus, Kosinus, Tangens, Arcus-Sinus,
Arcus-Kosinus, Arcus-Tangens). Zur Verknüpfung einzelner logischer Ausdrücke sind Boole’sche Operatoren (AND, OR, NOT) sinnvoll. Die Auswertung der logischen Ausdrücke liefert entweder true oder
false. Eine gültige Bedingung ist beispielsweise
N OT (3 + 5/2 < sqrt(33 ))
Die Auswertung dieser Bedingung ergibt stets true. Eine Bedingung, die für den Demonstrator in Frage
kommt, ist die oben definierte Bedingung:
(ux − ax )2 + (uy − ay )2 < (t · v)2
Durch die Möglichkeit Bedingungen durch derartige Ausdrücke zu spezifizieren, lassen sich allerdings weit
mehr als diese Bedingung angeben. Einige Beispiele hierfür folgen später in dieser Arbeit.
Wurde eine Bedingung ausgewertet, muss danach geprüft werden, ob das Ergebnis eine Aktion nach sich
zieht. Dabei muss für jede Aktion festgelegt werden, ob sie bei einer wahren oder unwahren Bedingung
ausgeführt werden soll, und ob sie nur ein einziges Mal ausgeführt werden soll oder bei jeder Auswertung
mit diesem Resultat. Aktionen stellen in diesem Anwendungsszenario Dienstinitiierungen dar. So wird zum
Beispiel bei Eintreten obiger Bedingung (mit einem fest definierten Aktionspunkt) der MoBiLe-Service angestoßen. Gegebenenfalls benötigt dieser aber zur Ausführung Ortsinformationen des Dienstnutzers. Diese
können entweder von den Sensoren ex post abgefragt werden oder bereits bei der Dienstinitiierung mitgeliefert werden. Dazu muss es Aktionen geben, die es ermöglichen, eine Reihe von Messwerten an die
Dienstinitiierungsnachricht anzuhängen. Dass eine derartige Initiierung durchgeführt werden muss und
welche Messwerte angehängt werden sollen, muss in der jeweiligen ECA-Regel verankert werden.
Die zu Beginn dieses Kapitels vorgestellten Location-Updates, die keine Dienste initiieren, sondern eine
Aktualisierung von Sensorinformationen vornehmen, können ebenfalls mit ECA-Regeln spezifiziert werden. Oben aufgeführte Beispiele für Location-Updates sind simple, zeitbasierte/periodische, distanzbasierte
oder zonenbasierte Location-Updates. All diese Strategien sind auch auf ECA-Regeln abbildbar. So nutzen
simple Location-Updates, die bei jeder Veränderung der Sensorinformationen eine Aktualisierung anstoßen, Positionsinformationen als Ereignisse der ECA-Regeln. Die Bedingung ist grundsätzlich wahr und als
Aktion wird eine Dienstinitiierung mit angehängten Positionsinformationen spezifiziert. Folglich wird bei
jeder Aktualisierung der Sensorinformationen die Aktion, d.h. das Location-Update, ausgelöst.
Anders ist es bei den zeitbasierten/periodischen Triggern. Hier basiert das Ereignis nicht mehr auf Positionsinformationen, sondern auf Zeitinformationen. Durch Bedingungen werden Zeitpunkte bzw. Zeitintervalle, bei denen Location-Updates durchzuführen sind, festgelegt. An die Aktionen werden wieder
Positionsinformationen angehängt.
Distanzbasierte Trigger sind ähnlich zu den zeitbasierten/periodischen Triggern. Jedoch beinhalten Ereignisse hier Positionsinformationen und die in den Bedingungen spezifizierten Intervalle beziehen sich auf
Positionsinformationen und sind dementsprechend Distanzen. Verändern sich Positionsinformationen um
bestimmte Distanzen, so wird das Location-Update ausgelöst. Hier muss es innerhalb der ECA-Regeln
die Möglichkeit geben, auf Messwerte der letzten Aktion zugreifen zu können. Dies könnte zum Beispiel
innerhalb einer Aktion abgebildet werden, die die letzten Messwerte speichert und für zukünftige Bedingungen verfügbar macht.
[KüTr 05] geben schließlich noch zonenbasierte Trigger an. Die Ereignisse dieser Trigger basieren ebenfalls auf Positionsinformationen, Bedingungen hingegen definieren feste Zonen. Befinden sich die Positionsinformationen innerhalb dieser Zone, wird das Location-Update initiiert. Zonenbasierte Trigger lassen
sich also ebenfalls mit ECA-Regeln geeignet darstellen.
4.2.2
Initiierungsmiddleware
Um einerseits von der Dienstausführungsschicht generierte Trigger an adäquate Initiatoren zu verteilen und
andererseits Dienstinitiierungen entgegenzunehmen und dann die Dienstausführung anzustoßen, wurde
zwischen Dienstinitiierungsschicht und Dienstausführungsschicht eine Middlewareschicht integriert, die
Applikationen der Dienstausführungsschicht einen transparenten Zugriff auf die Initiatoren ermöglicht.
56
KAPITEL 4. ARCHITEKTUR
Gleiches gilt für den Zugriff von Initiatoren der Dienstinitiierungsschicht auf die entsprechende Applikation.
Die Initiierungsmiddleware übernimmt demnach die Kommunikation zwischen Dienstinitiierung und
Dienstausführung. Dazu kennt sie alle Initiatoren, deren Fähigkeiten und Schnittstellen. Will eine
Applikation einen Trigger setzen, so übergibt sie den Trigger an die Initiierungsmiddleware, welche
dann nach einem entsprechenden Initiator sucht und bei erfolgreicher Suche den Trigger an den Initiator
weiterleitet. Gegebenenfalls kann der Trigger auch entsprechend angepasst werden, um von einem
Initiator angenommen zu werden. So ist es zum Beispiel denkbar, dass der Trigger Positionsinformationen
im Gauß-Krüger-Format enthält, es aber nur einen Initiator für Positionsinformationen im WGS84Format gibt. Die Initiierungsmiddleware kann dann eine Umrechnung der Gauß-Krüger-Koordinaten in
WGS84-Koordinaten durchführen. Sind bei der Dienstinitiierung Messwerte in einem bestimmten Format
enthalten, zur Dienstausführung werden diese jedoch in einem anderen Format erwartet, so können sie
(falls möglich) ebenfalls in der Initiierungsmiddleware in das benötigte Format transformiert werden.
4.2.3
Dienstausführung
Die Dienstausführung ist für die eigentliche Mehrwertgenerierung verantwortlich. Sie kapselt die Dienstlogik und ist deshalb spezialisiert auf einen Geschäftsprozess. Bei der Dienstausführung wird aus einer
Menge an Eingabewerten ein Ausgabewert erzeugt und mittels der Dienstpräsentation dem Nutzer übermittelt. Angestoßen wird die Dienstausführung durch die Dienstinitiierung. Bei richtiger Wahl der Trigger
sorgt die Dienstinitiierung dafür, dass ein Dienst zum richtigen Zeitpunkt ausgeführt wird, was im Grunde
genommen schon einen deutlichen Mehrwert gegenüber der manuellen Dienstinitiierung durch den Nutzer
bei Pull-Diensten erzeugt.
Eine Applikation, die hier im Vordergrund stehen soll, ist die Navigationsapplikation. Sie übernimmt die
Aufgabe, dem Nutzer Navigationsinformationen zur Wegfindung bereitzustellen. Genau genommen übernimmt sie den Teilprozess Routenführung“. Dazu bestimmt sie aus den aktuellen Ortsinformationen und
”
der zugrunde liegenden Route die im Moment der Ausführung einzuschlagende Richtung. Damit dies an
den richtigen Positionen geschieht, setzt die Navigationsapplikation entsprechende Trigger, die relevante Anforderungen für die Dienstinitiierung spezifizieren, in der Dienstinitiierungsschicht ab, um dann im
richtigen Augenblick tätig zu werden. Wie diese Trigger erzeugt werden, soll im Folgenden behandelt
werden.
Triggergenerierung
In Kapitel 2.1 wurde bereits auf Routen eingegangen. Routen dienen als essentieller Eingabewert für die
Mehrwertgenerierung in Navigationsdiensten der Wegfindung. Während Navigationsdienste der Lokomotion nicht zwingend Routen als Basis der Mehrwertgenerierung benötigen, kann ein Navigationsdienst
für die Wegfindung nur mittels Routen ordnungsgemäß funktionieren. Routen werden von Routendiensten
erzeugt, verwaltet und bereitgestellt. Der im Rahmen dieser Arbeit konzipierte und implementierte Routendienst ist im Anhang A beschrieben. Er liefert an einer wohldefinierten Schnittstelle Routenbeschreibungen
in der Form einer geordneten Liste von Aktionspunkten, wobei jeder Aktionspunkt seine Koordinaten und
die Austrittsrichtung (vgl. Kapitel 2.1) kennt.
Ausgehend von der Routenbeschreibung, genauer gesagt von der geordneten Liste von Aktionspunkten,
werden die zu erzeugenden Trigger in der Form von ECA-Regeln abgeleitet. Wie Bedingungen dieser
Trigger aufgebaut sein können, wurde bereits in vorigem Kapitel angesprochen. Da das Betreten eines Aktionskreises nur durch die Veränderung des eigenen Standortes geschehen kann (oder das Verändern des
Aktionskreises, was vorerst ausgeschlossen wird), sind Ereignisse der ECA-Regeln Positionsveränderungen. Als Aktion wird die Dienstinitiierung genutzt.
Nachdem für jeden Aktionspunkt ein geeigneter Trigger erzeugt wurde, werden diese mittels der Initiierungsmiddleware an die Dienstinitiierungsschicht übergeben. Dieser Vorgang kann entweder vollständig in
einem Zug geschehen oder es wird nur ein einzelner Trigger oder eine Teilmenge an Triggern sukzessiv
4.2. SCHICHTENMODELL
57
übertragen. Letzteres hat den Vorteil, dass die Menge der (quasi-)parallel auszuwertenden Trigger in der
Dienstinitiierungsschicht besser gesteuert werden kann. Je nach Bedarf kann zum Beispiel nur der nächste
Trigger aus der Liste der Aktionspunkte in die Dienstinitiierungsschicht eingefügt werden. Zu Beginn der
Route ist demnach nur der Trigger des ersten Aktionspunktes vorhanden, bei Erreichen dieses Aktionspunktes wird dann der entsprechende Trigger durch den Trigger des in der Route folgenden Aktionspunktes ersetzt. Dadurch muss stets nur ein Trigger ausgewertet werden. Natürlich ist es auch möglich, anstatt
einzelner Trigger, Teilmengen der Trigger in die Dienstinitiierungsschicht einzufügen. Sinnvoll wäre hier
zum Beispiel, die n nächsten Trigger der Route zu wählen, um resistent gegen Verzögerungen innerhalb des
Systems zu sein und ein Überspringen einzelner Trigger zu ermöglichen. Nachteil dieses Verfahrens ist der
erhöhte Verwaltungsaufwand und Signalisierungsverkehr, der durch die vermehrt auftretenden Nachrichten
zum Setzen neuer Trigger zwischen Dienstausführungsschicht und Dienstinitiierungsschicht entsteht.
Routenführung
Nachdem die Trigger in der Dienstinitiierungsschicht eingefügt wurden, ist der Dienst bereit zur
Ausführung. Kommt es zur Dienstausführung, kann anhand der ID des Triggers, der die Dienstausführung
angestoßen hat, dieser eindeutig identifiziert werden. Durch die ID kann die Navigationsapplikation daraufhin feststellen, an welchem Aktionspunkt der Route sich der Dienstnutzer befindet, und die entsprechende
Navigationsinformation generieren. Hat die Navigationsapplikation die Route lokal vorliegen, so erhält sie
die entsprechende Richtungsänderung durch Suche des Aktionspunktes in der Routenbeschreibung. Verbleibt die Route innerhalb des Routendienstes, muss dieser kontaktiert werden, um die Richtungsänderung
für diesen Aktionspunkt zu erhalten. Ergebnis ist in beiden Fällen ein Hinweis auf die weiterführende Route. Dieser kann, wie bereits in Kapitel 2.2 dargestellt, zum Beispiel in Form der allozentrischen Austrittsrichtung aus dem Aktionspunkt vorliegen. Der im Anhang A beschriebene Routendienst liefert derartige
Hinweise in Form einer Winkelangabe zum geografischen Norden als Referenzrichtung.
Abbildung
Diese Winkelangabe liefert zwar einen eindeutigen Hinweis auf die weiterführende Route, ist aber für den
Menschen schwer in die Realität umzusetzen. Die Abbildung als Teilprozess der Navigation erleichtert
dem Menschen die Umsetzung in die Realität. Eine weitere Aufgabe der Navigationsdienste ist daher diese Abbildung. Dazu wird die abstrakte Information, die aus der Routenbeschreibung gewonnen wurde, in
eine Information abgebildet, die dem Nutzer präsentiert und leicht von ihm umgesetzt werden kann. Daraus ergeben sich zwei Betrachtungen der Abbildung. Erstere bezieht sich auf technische Gegebenheiten.
Hierunter fällt vor allem welche Präsentationsformen überhaupt technisch möglich sind und wie diese am
besten innerhalb eines Mediums aufbereitet werden. Die zweite Betrchtung bezieht sich auf die Reduktion
des kognitiven Aufwandes. Dazu zählt die Wahl der Darstellungsform, die für den Nutzer leicht aufzunehmen und zu verarbeiten ist, und die Aufbereitung des Inhaltes.
Die Aufgabe der Abbildung übernimmt sowohl die Dienstausführung, wie auch die Präsentationsmiddleware. Da die Präsentationsmiddleware Kenntnis über alle verfügbaren Präsentatoren und deren Eigenschaften besitzt, übernimmt diese Schicht die Abbildung anhand technischer Gegebenheiten. Die Abbildung anhand des kognitiven Aufwandes wird in der Dienstausführungsschicht durchgeführt. Da es sich meist um
spezifische Applikationen handelt, die für ihren Geschäftsprozess spezifische Darstellungsformen besitzen,
kann diese Abbildung nur innerhalb der Dienstausführungsschicht durchgeführt werden. Für die Abbildung
ist Detailwissen notwendig, welches nicht innerhalb anderer Schichten verfügbar ist und aufgrund der Menge, Komplexität und womöglich Vertraulichkeit auch nicht verfügbar gemacht werden kann. Zum Beispiel
hat eine Navigationsapplikation wesentlich andere kognitive Einflussfaktoren als der bereits erwähnte ortsbasierte Email-Push-Service. Während in der Navigationsapplikation versucht wird, eine Darstellung zu
wählen, deren Inhalt wenig kognitiven Aufwand für den Nutzer bedeutet, ist bei der ortsbasierten EmailPush-Applikation eine Beachtung des kognitiven Aufwandes relativ unwichtig.
Darstellungsformen, die im Bereich der Navigationsapplikation einen hohen Stellenwert besitzen, sind grafische (Kartenausschnitte oder Pfeildarstellungen), textuelle und verbale Darstellungen von Richtungsände-
58
KAPITEL 4. ARCHITEKTUR
rungen. Diese unterscheiden sich mehr oder weniger stark durch den bei der Wahrnehmung entstehenden
kognitiven Aufwand. Dieser Aufwand resultiert aus der Aufnahme und der Verarbeitung der Navigationsinformation. Verschiedene Darstellungsformen erzeugen unterschiedlich lange Aufnahme- und Verarbeitungszeiten. Diese sind jedoch von einer Vielzahl an Einflussgrößen abhängig. Darunter fallen zum Beispiel
die Art der Fortbewegung, die Fähigkeiten und Einschränkungen des Nutzers und äußere Einflüsse, wie die
Sonneneinstrahlung auf das Display oder die Geräuschkulisse. Nicht zu vergessen sind allerdings auch
grundlegende Einflussgrößen, wie das Vorhandensein von Informationen, die für eine spezifische Darstellung nötig sind, oder Präferenzen des Nutzers. Stehen beispielsweise keine Umgebungsinformationen zur
Verfügung, ist eine Kartendarstellung nicht möglich. Kann der Nutzer selbst zwischen den angebotenen
Darstellungsformen wählen, so sollte die Darstellungsform auf dessen Präferenzen abgestimmt werden.
Wenn der Nutzer beispielsweise eine Darstellung mittels eines Kartenausschnitts vorzieht, da er dadurch
zusätzliche Hintergrundinformationen über den Aktionspunkt erfährt, so sollte die Navigationsapplikation
natürlich diese Darstellungsform wählen. Die Darstellung ist jedoch nicht zwingend an eine einzige Form
gebunden. So kann zum Beispiel die verbale Darstellung durch eine grafische Pfeildarstellung unterstützt
werden, wie es bei Fahrzeugnavigationssystemen meist der Fall ist.
Bei jeder Darstellungsform sind desweiteren zwei Perspektiven möglich. Diese sind die allozentrische
und die egozentrische Perspektive (vgl. Kapitel 2.1). Wurde die Dienstausführung ohne weitere Messwerte angestoßen, so ist die allozentrische Perspektive obligatorisch, da keine Referenzrichtung des Nutzers
verfügbar ist und deshalb nur eine allgemeingültige Referenzrichtung, wie zum Beispiel der geografische
Norden, anwendbar ist.
Eine allozentrische Navigationsinformation ist zum Beispiel ein Kartenausschnitt wie in Abbildung 4.6c),
in dessen Mittelpunkt sich der Aktionspunkt befindet und auf dem die einzuschlagende Richtung markiert wurde. Durch die Dienstpräsentation erhält der Nutzer den Kartenausschnitt. Um die Navigationsanweisung aus dem Kartenausschnitt (roter Pfeil) umzusetzen, muss er die dargestellte Richtungsänderung
physisch oder logisch umorientieren. Physische Umorientierung bezeichnet in diesem Zusammenhang das
oft beobachtbare Drehen des Kartenausschnitts bis der Kartennorden physisch gegen den geografischen
Norden zeigt und dadurch die Navigationsanweisung direkt umsetzbar wird. Logisch bedeutet in diesem
Zusammenhang, dass die einzuschlagende Richtung aus der wahrgenommenen mentalen Karte entnommen wird.
b)
a)
c)
N
N
N
+
=
Abbildung 4.6: Genordeter Kartenausschnitt
Zur Minimierung der Verarbeitungszeit sollte deshalb bereits in der Navigationsapplikation eine Umorientierung erfolgen. Dazu muss die aktuelle Blickrichtung des Nutzers bei Betreten des Aktionskreises bekannt
sein. Da die Blickrichtung des Nutzers mit derzeitiger Technik schwer ermittelbar ist, wird diese durch die
meist ähnliche Bewegungsrichtung ersetzt. Um stets Kenntnis über die aktuelle Bewegungsrichtung beim
Eintreten in den Aktionskreis zu besitzen, wird diese in die Dienstinitiierungsaktion integriert. Dadurch
wird die aktuelle Bewegungsrichtung an jede Dienstinitiierung angehängt und die Navigationsapplikation
davon informiert.
Mit Hilfe der aktuellen Bewegungsrichtung kann nun zum Beispiel ein allozentrischer Kartenausschnitt
in einen egozentrischen Kartenausschnitt transformiert werden, der nicht mehr nach Norden ausgerichtet,
sondern an die Bewegungsrichtung des Nutzers angepasst ist. Dadurch kann der Nutzer die aufgezeigte
59
4.2. SCHICHTENMODELL
Richtungsänderung direkt in die Realität umsetzen und muss nicht mehr aufwändig eine Umorientierung
der Karte durchführen.
In diesem Kapitel wurden nun vier verschiedene Darstellungsformen (Karten-, Pfeil-, verbale und textuelle Darstellung) vorgestellt, die jeweils mit allozentrischer oder egozentrischer Perspektive präsentiert
werden können (vgl. Tabelle 4.2.3). Basis all dieser Darstellungen ist die Richtungsänderung, die an diesem Aktionspunkt durchgeführt werden muss. Für eine einfache textuelle und verbale Darstellung in allozentrischer Perspektive ist diese Richtungsänderung als Information ausreichend. Navigationsinformationen wie An der nächsten Möglichkeit Richtung Osten abbiegen“ können durch einfache Quantisierung
”
der Richtungsänderung in die Richtungssektoren {N orden, Osten, S üden, W esten} und bereits vordefinierte Text- oder Sprachkonstrukte generiert werden. Sollen detailliertere oder durch Umgebungswissen
angereicherte Navigationsinformationen erzeugt werden, müssen zusätzliche Informationen zum Beispiel
von Directory Services [Maea 04] integriert werden. Resultat sind Navigationsinformationen wie An der
”
nächsten Abzweigung Richtung Osten in die Hauptstraße einbiegen“.
Ähnliches gilt für die Pfeil- und Kartendarstellung, die sich im Wesentlichen durch das eingefügte Um-
Kartendarstellung
Pfeildarstellung
Verbale Darstellung
Textuelle Darstellung
Allozentrisch
Karte mit Norden als Referenzrichtung
Pfeil mit Norden als Referenzrichtung
An der nächsten Möglichkeit
”
Richtung Osten abbiegen“
An der nächsten Möglichkeit
”
Richtung Osten abbiegen“
Egozentrisch
Karte mit Bewegungsrichtung als
Referenzrichtung
Pfeil mit Bewegungsrichtung als
Referenzrichtung
An der nächsten Möglichkeit
”
rechts abbiegen“
An der nächsten Möglichkeit
”
rechts abbiegen“
Tabelle 4.1: Darstellungsformen in allozentrischer/egozentrischer Perspektive
gebungswissen unterscheiden. Pfeildarstellungen werden meist nur um Namen bestimmter Landmarken
erweitert. Obiges Beispiel würde in der Pfeildarstellung durch einen nach rechts gerichteten Pfeil, gegebenenfalls durch die Aufschrift Hauptstraße“, dargestellt. Zusätzlich muss ein Hinweis auf die Allozentrik
”
zum Beispiel durch den Buchstaben N“ für den geografischen Norden am oberen Bildrand erfolgen (vgl.
”
Abb. 4.6b). Im Unterschied dazu enthält die Kartendarstellung weitere Umgebungsinformationen, wie politische Grenzen, Bepflanzung oder Pfadnetzwerke (vgl. Abb. 4.6a). Diese Daten können in grafischer
Form zum Beispiel von Presentation Services [Maea 04] erlangt werden. Basierend auf dieser Grundlage
fügt man die Richtungsänderung in der Form der Pfeildarstellung hinzu (vgl. Abb. 4.6b) und erhält die
gewünschte Kartendarstellung (vgl. 4.6c).
Für die egozentrische Darstellung muss eine Richtungsanpassung der allozentrischen Richtung auf die
egozentrische Richtung erfolgen. Für die textuelle und verbale Darstellung bedeutet dies, dass die Richtungsinformation (in obigem Beispiel Osten“) in eine der egozentrischen Perspektive entsprechende Rich”
tungsinformation transformiert werden muss. Bewegt sich der Nutzer Richtung Norden, so ergibt sich für
obiges Beispiel die Navigationsinformation Die nächste Möglichkeit rechts abbiegen“.
”
Ähnliches gilt für die grafische Repräsentation mittels Landkarten oder Pfeilen. Die Richtungsinformation ist hier durch die Richtung der Grafik gegeben. Eine Anpassung an die egozentrische Richtung erfolgt
durch Drehen der Grafik bis die egozentrische Richtung nach oben zeigt.
Die hier angeführten Präsentationsformen sind nicht zwangsläufig vollständig, geben aber die in der Navigation typischen Präsentationsformen wieder.
4.2.4
Präsentationsmiddleware
Die durch die Dienstausführung generierten Darstellungen müssen daraufhin dem Nutzer präsentiert werden. Dazu besitzt ein Nutzer einen oder mehrere Präsentatoren, die die Präsentation eines oder mehrerer
Darstellungsmedien übernehmen. Damit sich die Dienstausführungsschicht nicht mit dem Zugriff und der
60
KAPITEL 4. ARCHITEKTUR
Verwaltung von diversen heterogenen Präsentatoren auseinandersetzen muss, wurde zwischen der Dienstausführungs- und Dienstpräsentationsschicht eine Middleware eingefügt, die den Applikationen der Dienstausführungsschicht einen transparenten Zugriff auf die Präsentatoren ermöglicht.
Innerhalb der Präsentationsmiddleware erfolgt die Abbildung anhand technischer Gegebenheiten. Dazu
spielen vor allem die Verfügbarkeit von Präsentatoren mit bestimmten Eigenschaften und die Verbindungscharakteristika eine entscheidende Rolle. Übergibt eine Applikation eine Menge an Darstellungen an die
Präsentationsmiddleware, wird überprüft, welche Präsentatoren verfügbar sind und ob diese die übergebenen Darstellungen unterstützen. Gegebenenfalls kann eine Transformation in einen anderen Medientyp erfolgen. Grundsätzlich ist dies nur innerhalb einer Darstellungsform möglich. In manchen Fällen kann auch
eine Transformation zwischen Darstellungsformen erfolgen. So kann zum Beispiel eine textuelle Darstellung gegebenenfalls in eine verbale Darstellung überführt werden. In der Regel ist es aber nicht möglich,
verbale Darstellungen in Kartendarstellungen zu transformieren, da für die Kartendarstellung weitere Informationen nötig sind.
Innerhalb einer Darstellungsform ist eine Transformation zwischen Medientypen in der Regel möglich.
Wird zum Beispiel eine verbale Darstellung im WAV-Format übergeben und es existiert nur ein Präsentator
für Medien im MP3-Format, so kann in der Präsentationsmiddleware eine Konvertierung von WAV nach
MP3 erfolgen.
Neben der Transformation zwischen verschiedenen Medientypen, kann in der Präsentationsmiddleware
auch eine Transformation innerhalb eines Medientyps erfolgen. Dies kann zum Beispiel dazu eingesetzt
werden, um eine Datenkompression - gegebenenfalls unter Qualitätsverlust - durchzuführen. Dies ist vor
allem sinnvoll, falls die Verbindung mit dem Initiator eine geringe Datenrate vorweist oder ihre Benutzung
mit hohen Kosten verbunden ist. Für die verbale Darstellung im MP3-Format kann im Zuge der Anpassung
beispielsweise eine Verringerung der Bitrate oder eine Kanalbündelung von Stereo auf Mono durchgeführt
werden.
Eine weitere Aufgabe der Präsentationsmiddleware ist die Anpassung der Medien an die Eigenschaften der
Präsentatoren. Eigenschaften der grafischen Darstellung sind beispielsweise die Größe des Displays, die
Auflösung, sowie die Farbtiefe (vgl. [BKKW ]). Die Präsentationsmiddleware ist dafür verantwortlich, das
Medium anhand dieser Eigenschaften anzupassen. Hierfür muss das grafische Medium skaliert und an die
darstellbare Auflösung und Farbtiefe angepasst werden.
4.2.5
Dienstpräsentation
Durch die Verteilung der Medien an die entsprechenden Präsentatoren, erreicht das darzustellende Medium letztendlich die Dienstpräsentationsschicht. Diese ist zuständig für die Präsentation der Medien. Wie
bereits beschrieben, sind grundlegende Präsentationsformen die verbale, die textuelle und die grafische
Präsentation. Die Medien einer Präsentationsform können desweiteren verschiedenste Medientypen besitzen. Medientypen für die grafische Darstellung sind unter anderem Bitmap (BMP), Portable Network
Graphics (PNG), Joint Photographic Expert Group (JPG), Graphics Interchange Format (GIF) oder Scalable Vector Graphics (SVG).
Während manche Initiatoren Medien in verschiedenen Medientypen darstellen können, sind andere Initiatoren auf einen Medientyp beschränkt. Kann ein Initiator deshalb das ihm zugesandte Medium nicht darstellen, so muss er die fehlgeschlagene Präsentation mit einer negativen Quittung bestätigen. Ist er hingegen
fähig das Medium erfolgreich zu präsentieren, wird dieses vom Nutzer wahrgenommen und entsprechend
interpretiert.
4.3 Verteilung
Das in vorherigem Kapitel vorgestellte Schichtenmodell untergliedert LBPSs in fünf logische Schichten.
Logische Schichten unterteilen ein Softwaresystem in logische Teilkomponenten. Aufbauend auf diesen
Schichten erfolgt nun eine Betrachtung der physischen Verteilung. Werden logische Schichten auf physi-
4.3. VERTEILUNG
61
sche Entitäten 1 verteilt, so spricht man von physischen Schichten (engl. Tiers) (vgl. [Warr 99]). Mögliche
bzw. unmögliche Verteilungen und Vor- und Nachteile einzelner Verteilungen werden in diesem Kapitel
behandelt.
Um die bereits vorgestellten Schichten auf Entitäten des Systems zu verteilen, muss zuallererst eine Bestandsaufnahme der zur Verfügung stehenden Entitäten erfolgen. Da die Architektur des Location-based
Push-Services und dessen Verteilung frei von der zugrunde liegende Technologie (z.B. Mobilfunkgeneration) entwickelt werden soll, werden in diesem Kapitel keine technologiespezifischen Eigenheiten des
Systems und dessen Entitäten betrachtet. An dieser Stelle ist deshalb eine allgemeine Betrachtung der im
Bereich der LBPSs relevanten Entitäten ausreichend.
4.3.1
Entitäten
Da die Dienstnutzung des mobilen Navigationsdienstes in der Regel von einem mobilen Endgerät aus
durchgeführt wird, stellt das mobile Endgerät eine erste Hardwareentität dar. Mobile Endgeräte sind
bestimmten Spezifika und Restriktionen, die aus ihrer Mobilität resultieren, unterlegen. Im Zeitalter des
Mobile Distributed Computing“ [SAW 94, Schi 95, BuTu , TavS 03] sind mobile Endgeräte meist über
”
die Luftschnittstelle mit einer Infrastruktur verbunden, die wiederum aus mehreren einzelnen Entitäten bestehen kann. Sie werden unter dem Begriff Infrastruktur zusammengefasst. Im Wesentlichen werden hier
also mobile Endgeräte und die Infrastruktur unterschieden.
Mobiles Endgerät
Ein mobiles Endgerät ist ein Gerät, dessen Funktionsfähigkeit nicht von stationären Gegebenheiten wie
Stromanschluss oder Netzwerkanschluss abhängt und deren Ausmaße und Gewicht einen einfachen Ortswechsel zulassen. Deshalb ist es möglich, das Gerät überall mitzuführen und überall zu nutzen. Im Gegensatz zu portablen Endgeräten ist die Funktionsfähigkeit auch während der Bewegung gegeben. Beispiele
für mobile Endgeräte sind Mobiltelefone, PDAs und eingeschränkt auch Notebooks.
Aus dem Nichtvorhandensein des stationären Stromanschlusses und den Einschränkungen bezüglich Ausmaße und Gewicht unterliegen mobile Endgeräte in der Regel einer geringeren Rechenleistung als die
korrespondierenden stationären Endgeräte. Selbiges gilt für den volatilen sowie persistenten Speicher.
Die geringen Ausmaße des mobilen Endgerätes erlauben außerdem keine komfortablen Ein- und Ausgabemöglichkeiten. Eingabemöglichkeiten ergeben sich meist nur durch eine ITU-T One-Hand-Tastatur oder
ein Touchscreen. Zur Ausgabe stehen meist kleine Displays und einfache Lautsprecher zur Verfügung.
Die drahtlosen Kommunikationsverbindungen zu MANs sind in der Regel teuer in der Benutzung, unterliegen meist niedrigeren Datenraten als die drahtgebundenen Netze und gelten als unverlässlich (vgl.
[BuTu , BCK 04, BKK 01, RuKr 03]).
Die rasante Entwicklung im Bereich der mobilen Endgeräte liefert zwar ständige Neuerungen und Verbesserungen, um diesen Einschränkungen entgegenzuwirken, jedoch können sie in naher Zukunft wohl nicht
gänzlich eliminiert werden.
Infrastruktur
Durch die Kommunikationsmöglichkeit über drahtlose Netze wird der Austausch von Daten mit anderen
mobilen Endgeräten (Ad-Hoc-Netze) oder einer Infrastruktur (Infrastrukturnetze) ermöglicht. Ersteres ist
in dieser Arbeit weniger von Interesse. Stattdessen spielen Infrastrukturnetze eine entscheidende Rolle
für die Verteilung der LBPS-Schichten. Komponenten der Infrastruktur unterliegen nicht den für mobile
Endgeräte inhärenten Einschränkungen. So sind Kommunikationsverbindungen innerhalb der Infrastruktur meist drahtgebunden und deshalb kostengünstiger, verlässlicher, schneller und leichter erweiterbar als
1 Entitäten bezeichnen in dieser Arbeit physische Einheiten, die die Ausführung bestimmter Prozesse zulassen. Eine Entität kann
sich aus einer oder mehreren Hardwarekomponenten zusammensetzen. Beispiel für eine Entität ist ein mobiles Endgerät, aber auch
ein Rechnercluster.
62
KAPITEL 4. ARCHITEKTUR
drahtlose Verbindungen. Desweiteren sind die Rechenleistung und der verfügbare Speicher von Infrastrukturkomponenten wesentlich leichter skalierbar als bei mobilen Endgeräten und Ausmaße und Gewicht der
Geräte sind unerheblich.
4.3.2
Verteilungsalternativen
Mittels der Kommunikationsmöglichkeit der mobilen Endgeräte mit Entitäten der Infrastruktur kann ein
Outsourcing einzelner Dienstschichten über Gerätegrenzen hinweg erfolgen. Es stellt sich die Frage,
welche Dienstschichten ein Outsourcing erlauben und welche Konstellationen Sinn machen.
Die Dienstpräsentation muss sich immer auf der Entität befinden, auf der auch die jeweilige Ausgabemöglichkeit vorhanden ist. Bei mobilen Navigationsdiensten ist dies das mobile Endgerät. Ähnliches
gilt für die Dienstinitiierung. Diese befindet sich auf der Entität, auf der die Sensorinformationen zur
Verfügung stehen. Bei einer netzwerkbasierten Ortung liegt die Dienstinitiierung demnach auf einer Entität
der Infrastruktur und bei einer endgerätebasierten Ortung (wie GPS) befindet sie sich auf dem mobilen
Endgerät. Werden mehrere Initiatoren parallel genutzt, ist es auch möglich, dass sich eine Teilmenge der
Initiatoren auf dem Endgerät und der Rest in der Infrastruktur befindet.
Die restlichen drei Schichten Initiierungsmiddleware, Dienstausführung und Präsentationsmiddleware
sind im Gegensatz zu den restlichen Schichten nicht an feste Ein- oder Ausgabemöglichkeiten gebunden.
Dadurch wird ein Outsourcing in die Infrastruktur möglich. Welche Einflussfaktoren ein Outsourcing
rechtfertigen oder widerlegen, wird im Folgenden erläutert.
Einflussfaktoren auf Verteilung
Ein großes Problem des Distributed Computing“ ist die Verteiltheit von Informationen. Während in
”
früheren Zeiten alle zur Dienstausführung nutzbaren Informationen lokal auf der Entität, auf der die Dienstausführung stattfindet, vorhanden waren, ist beim Distributed Computing“ ein weitaus größerer Horizont
”
der Informationsbeschaffung heranzuziehen. Informationen sind nicht mehr nur lokal abrufbar, sondern
können auf der ganzen Welt verteilt und von dort abrufbar sein. Einer der wichtigsten Schritte, der die
Verfügbarkeit von Informationen entscheidend gefördert hat, ist die Entwicklung des Internets. Durch das
Internet ist es möglich geworden, eine Vielzahl an Informationen weltweit zu nutzen.
Durch die Entwicklung des Mobile Distributed Computing“ [SAW 94, Schi 95] kommt zu diesen fest
”
verdrahteten Rechnern eine Menge mobiler Endgeräte, die sich durch drahtlose Verbindungen in das Netz
eingliedern. Die Gesamtheit der Informationsbeschaffer und -nutzer wird dadurch signifikant erweitert.
Eine Problematik für die Anbindung an das Informationsnetz“ ist die drahtlose Verbindung. Drahtlose
”
Verbindungen unterliegen, wie bereits beschrieben, geringeren Datenraten, eingeschränkter Verfügbarkeit
und beschränkter Verlässlichkeit. Außerdem sind sie oft teuer in der Nutzung. Zur Lösung dieses Problems
kann ein Ansatz verwendet werden, der in vielen Fällen zum Einsatz kommt, bei denen Informationen lokal
verfügbar gemacht werden müssen, wodurch Kosten (wie Netzlast, monetäre Nutzungskosten) entstehen.
Dieser Ansatz ist das Caching bzw. Precaching. Caching bezeichnet den Vorgang, Informationen lokal
zwischenzuspeichern, um sie bei einer erneuten Verwendung nicht wieder beschaffen zu müssen. Precaching bezeichnet den Vorgang, Informationen vor der eigentlichen Nutzung lokal verfügbar zu machen. So
kann einer später teuren oder unmöglichen Informationsbeschaffung vorgebeugt werden.
(Pre-)Caching ist jedoch nur in eingeschränktem Maße einsetzbar. Es muss dazu bekannt sein, welche Informationen in Zukunft benötigt werden. Je nach Art der Anwendung und Information ist dies mehr oder
weniger gut möglich. In einem Großteil der Fälle ist es jedoch überhaupt nicht möglich. Soll ein Dienst
zum Beispiel die Sonnentage für den nächsten Monat (pre-)cachen, so stellt dies voraussichtlich ein ernsthaftes Problem dar. Soll der Dienst allerdings nur die Stunden von Sonnenaufgang bis Sonnenuntergang
(pre-)cachen, so ist dies ohne große Einschränkungen möglich.
Zusammenfassend kann gesagt werden, dass die lokale Verfügbarkeit von verteilten Informationen im Mobile Distributed Computing zwei Faktoren determinieren. Diese sind die stetige Anbindung an das Infor”
mationsnetz“ (im Folgenden als Connectivity bezeichnet) und das (Pre-)Caching. Ist keines der beiden
63
4.3. VERTEILUNG
gegeben, so ist eine lokale Nutzung von nicht-lokalen Informationen nicht möglich. Ist keine akzeptable Connectivity gegeben, (Pre-)Caching jedoch möglich, so können Informationen vorab lokal verfügbar
gemacht werden und sind so bei späterem Gebrauch direkt nutzbar. Ist allerdings Connectivity gegeben,
(Pre-)Caching jedoch nicht möglich, so können Informationen bei Gebrauch direkt aus dem Informati”
onsnetz“ beschafft werden. Ist sowohl Connectivity als auch Precaching möglich, so kann in jedem Fall
auf Informationen zurückgegriffen werden, egal ob diese erst bei Gebrauch oder bereits zuvor beschafft
werden.
Bezüglich der Frage der Verteilung der Dienstausführung ergibt sich dadurch folgende Situation. Innerhalb der Dienstausführungsschicht wird aus einer Menge an Informationen ein wie auch immer gearteter
Mehrwert erzeugt. Alle Informationen müssen dazu der Dienstausführungsschicht zur Verfügung stehen.
Ist gute Connectivity gegeben, so kann die Dienstausführungsschicht alle Informationen bei Gebrauch direkt anfordern. Würde in diesem Fall die Dienstausführung auf dem mobilen Endgerät erfolgen, so müssten
alle Informationen über die Luftschnittstelle übertragen werden, um von ihrem ursprünglichen Ort auf das
mobile Endgerät zu gelangen. Bei einer großen Anzahl an Informationen können dadurch hohe Kosten
entstehen. Außerdem werden zur Dienstausführung oft hohe Anforderungen an Rechenleistung und Speicherplatz gestellt, die auf dem mobilen Endgerät nicht erfüllt werden können. Wird die Dienstausführung
jedoch innerhalb der Infrastruktur durchgeführt, kann ein Großteil der zur Ausführung nötigen Informationen direkt über drahtgebundene Verbindungen übertragen werden. Außerdem können die Anforderungen
an Rechenleistung und Speicherplatz in der Infrastruktur leichter erfüllt werden als auf dem mobilen Endgerät.
Lassen die Informationen andererseits ein (Pre-)Caching zu, so können die zur Ausführung nötigen Informationen bereits frühzeitig verfügbar gemacht werden. Für die lokale Dienstausführung auf dem mobilen
Endgerät hat dies zur Folge, dass auch bei einer Trennung der Connectivity die Dienstausführung durchgeführt werden kann, da die Informationen bereits zuvor durch (Pre-)Caching auf das mobile Endgerät
gebracht wurden. Dadurch erfährt der Dienst eine gewisse Autonomie. Er ist nicht mehr abhängig vom
Informationsnetz“ und wird dadurch nicht mehr durch die Connectivity und Ausfällen innerhalb des In”
”
formationsnetzes“ beeinflusst. Nachteil der lokalen Dienstausführung ist neben der beschränkten Rechenleistung der Speicherplatzverbrauch, der für das (Pre-)Caching benötigt wird.
Zusammenfassend lässt sich sagen, dass bei ausreichender Connectivity ein Outsourcing der Dienstausführungsschicht in die Infrastruktur sinnvoller erscheint als eine lokale Dienstausführung auf dem mobilen Endgerät. Wird von den Informationen ein (Pre-)Caching ermöglicht, scheint eine lokale Dienstausführung sinnvoller (vgl. Abb. 4.7). Bei ausreichender Connectivity und der Möglichkeit des (Pre-)Cachings kann sowohl die lokale wie die entfernte Dienstausführung oder eine Kombination beider eingesetzt werden.
Connectivity
vs.
(Pre-)Caching
Connectivity
Remote
(Pre-)Caching
Local
Abbildung 4.7: Gegenüberstellung lokaler und entfernter Dienstausführung bei Connectivity und (Pre-)Caching
Um Dienste innerhalb des in Abbildung 4.7 dargestellten Diagramms einordnen zu können, müssen speziell für diese Dienste die Ausprägungen von Connectivity und (Pre-)Caching betrachtet werden. Ob eine
64
KAPITEL 4. ARCHITEKTUR
Connectivity als ausreichend deklarierbar ist, entscheidet die Art des Dienstes. Ausreichend heißt dabei
keinesfalls, dass Informationen überall verfügbar sein müssen. Ausreichend bedeutet in diesem Zusammenhang bloß, dass die Informationen immer dann verfügbar sein müssen, wenn sie gerade gebraucht
werden. Der bereits desöfteren erwähnte ortsbasierte Email-Push-Dienst, der Emails entsprechend ihrer
örtlichen Relevanz (Büro oder zuhause) zustellt, braucht keine Informationen zu empfangenen Emails,
wenn der Nutzer sich nicht an den wohldefinierten Orten befindet. Sind an den diesen Orten die Informationen zugänglich, ist dies vollkommend ausreichend.
Ein (Pre-)Caching der Informationen wird möglich, wenn einerseits die Informationen dies zulassen und
andererseits das mobile Endgerät dies zulässt. Dazu muss es vor allem genug Speicherplatz zur Speicherung der Informationen bereitstellen. Informationen, die (Pre-)Caching zulassen, müssen vorhersehbar
sein. Die einfachste Form vorhersehbarer Informationen sind statische Informationen. Statische Informationen zeichnen sich dadurch aus, dass sie über ihre ganze Gültigkeitsdauer konstant sind. Beispiele sind
das Geburtsdatum einer Person, Positionen von Landmarken oder Postleitzahlen eines Postleitzahlenbereichs. Diese können bereits weit im Voraus auf dem mobilen Endgerät durch (Pre-)Caching verfügbar
gemacht werden. Nicht-statische Informationen, die aber trotzdem vorhersehbar sind, sind Informationen,
deren Werte sich nach einem vorhersehbaren Muster verändern. Beispiele sind Sonnenauf- und Sonnenuntergangszeitpunkte oder die Anzahl der Tage eines Jahres. Die dritte Möglichkeit vorhersehbarer Informationen, sind Informationen die eine mehr oder weniger verlässliche Schätzung zulassen. Dazu zählen
zum Beispiel die Verkehrsunfälle innerhalb eines Jahres oder die Niederschlagsmenge im Monat Juli. Aus
Betrachtungen der Vergangenheit lassen sich hier Schätzungen über das Verhalten in der Zukunft abgeben.
Meist sind diese Werte allerdings nur im Kollektiv gültig.
Anders ist dies bei nicht-vorhersehbaren Informationen. Für diese kann kein Wert in der Zukunft angegeben werden, weil sie sich nicht-deterministisch verändern und keine Schätzungen zulassen. Beispiele
derartiger Informationen sind präzise Wetterinformationen, längerfristige Verkehrsflussinformationen oder
Aktienkurse. Für derartige Informationen ist kein (Pre-)Caching möglich.
Ähnliche Resultate liefern auch [HLP , CDMF 00, PARA 02] in ihren Arbeiten. Nach [HLP ] ist ein Outsourcing der Dienstausführung sinnvoll, wenn nicht alle Informationen lokal verfügbar sind, Daten sich
häufig nichtdeterministisch ändern und nicht genügend Rechenleistung und Speicherplatz auf dem mobilen Endgerät verfügbar ist. [CDMF 00] stellt ein Outsourcing als sinnvoll dar, wenn das Endgerät nicht
über genügend Speicherplatz verfügt, um alle nötigen Informationen zu speichern und wenn verteilte unvorhersehbare Informationen zur Dienstausführung nötig sind. Nach [PARA 02] sprechen vor allem die
Notwendigkeit von aktuellen Informationen und die Beschränktheit der Rechenleistung und des Speicherplatzes auf dem mobilen Endgerät für das Outsourcing der Dienstausführung, wohingegen die Autonomie
und die eingeschränkte Connectivity an eine lokale Dienstausführung appellieren.
In [HLP ] wird zudem noch ein weiterer Grund genannt, der für ein Outsourcing der Dienstausführungsschicht spricht. Dies ist die einfache Anpassbarkeit der ausgelagerten Schichten. [HLP ] nennt hier die Adaption an verschiedene Ausprägungen terminalseitiger Schichten, die aus der Heterogenität der Endgeräte
entsteht. Allgemeiner kann hier gesagt werden, dass eine Veränderung in einer ausgelagerten Schicht viel
einfacher vollzogen werden kann als bei einer terminalbasierten Schicht, da eine ausgelagerte Schicht nur
einmal (ggf. mehrmals bei Replikation), eine terminalbasierte Schicht jedoch für jedes Terminal geändert
werden muss.
4.3.3
Auswirkung auf mobile Navigationsdienste
Betrachtet man nun das (Pre-)Caching der Informationen, die bei einem Navigationsdienst zum Einsatz
kommen, stellt man fest, dass (Pre-)Caching von einigen Annahmen abhängt. Die wichtigsten Informationen im Bereich der Navigationsdienste sind Routeninformationen. Diese können unterschiedliche Formen
annehmen (vgl. Kapitel 2.2) und unterschiedlich kodiert werden, müssen aber in jedem Fall bei den Navigationsdiensten der Wegfindung vorhanden sein.
Unterstellt man dem Nutzer ein deterministisches Bewegungsmuster entlang der vorgegebenen Route, so
kann die Route als statische Information angesehen werden und ein (Pre-Caching) wird möglich. Kommerzielle Dienste wie der NavMe oder der Mobile Navigator nutzen dies aus und laden alle Routeninformationen beim Start des Dienstes auf das mobile Endgerät. Der ActivePilot nutzt zwar ebenfalls (Pre-)Caching,
65
4.3. VERTEILUNG
lädt beim Start des Dienstes aber nur das erste Routensegment auf das mobile Endgerät. Nähert sich der
Nutzer dem Ende des Routensegments, wird automatisch das nächste Routensegment geladen. Um bei
einer leichten Routenabweichung noch Informationen liefern zu können, werden anstatt der direkten Routeninformationen meist korridorbasierte Routeninformationen, die zusätzlich das unmittelbare Umfeld der
Route beinhalten, eingesetzt.
Die in Kapitel 3.4 vorgestellten dedizierten Navigationsgeräte, sowie der Mobile 5 und der Mobile 2005,
die eine On-Board-Lösung für die Navigation nutzen, gehen diesen Schritt noch weiter und führen ein
(Pre-)Caching aller zur Routenberechnung nötigen Informationen über Städte, Straßen, etc. durch. Der
nötige Speicherplatz derartiger Dienste erhöht sich dadurch enorm im Gegensatz zu den Navigationsdiensten, die ausschließlich ein (Pre-)Caching der Routeninformationen durchführen. Für nicht vorhersehbare
Informationen, für die kein (Pre-)Caching möglich ist, nutzen einige Dienste zusätzlich die Connectivity zu Informationsnetzen“, um diese Informationen verfügbar zu machen. Fahrzeugnavigationssysteme
”
hören dazu den RDS TMC-Kanal nach Verkehrsinformationen ab. Andere nutzen Mobilkommunikationsnetze, um Verkehrsinformationen zu erhalten. Der Großteil der beschriebenen Dienste geht dabei von einer
unzureichenden Connectivity aus und nutzt deshalb soweit möglich (Pre-)Caching für die Informationsbeschaffung.
Geht man von einer ausreichenden Connectivity aus und nutzt (Pre-)Caching nur bedingt, so resultiert aus
dem Outsourcing der Dienstausführungsschicht eine höhere Netzlast zwischen Dienstinitiierung, Dienstausführung und Dienstpräsentation. Demgegenüber reduziert die Informationsbeschaffung die Netzlast der
drahtlosen Netze, da Informationen nicht mehr über die Luftschnittstelle übertragen werden müssen. Werden beispielsweise zur Generierung von Navigationsinformationen neben der Route alternative Routenvorschläge, Wetterinformationen, Sonnenauf- und Sonnenuntergangszeiten, Einkehrmöglichkeiten oder Verkehrsinformationen herangezogen, so müssen all diese Informationen bei einer terminalbasierten Dienstausführung über die Luftschnittstelle übertragen werden. Letztendlich ist das Resultat nach der Mehrwertgenerierung zum Beispiel ein einziger Pfeil, der dem Nutzer sagt, in welche Richtung er nun abbiegen
soll. Je mehr Informationen zur Generierung der Navigationsinformation nötig sind, desto höher wird der
Verkehr über die Luftschnittstelle (Over-The-Air-Traffic (OTA-Traffic)).
OTA-Traffic
Local
Remote
Menge nicht-lokaler Informationen
Abbildung 4.8: Netzlast der Luftschnittstelle bei lokaler oder verteilter Dienstausführung
Wird im Gegensatz dazu die Dienstausführungsschicht in die Infrastruktur ausgelagert und die gleiche
Menge an nicht-lokalen Informationen für die gleiche Navigationsinformation wie bei der lokalen Variante
eingesetzt, so muss nur die Navigationsinformation, d.h. der Pfeil, über die Luftschnittstelle übertragen
werden. Da die zur Generierung der Navigationsinformation nötigen Informationen nicht über die Luftschnittstelle übertragen werden, ist der OTA-Traffic unabhängig von der Anzahl der nötigen Informationen.
Abbildung 4.8 zeigt, dass bei einer niedrigen Menge nicht-lokaler Informationen bei lokaler Dienstausführung weniger Informationen über die Luftschnittstelle übertragen werden müssen als bei der verteilten Variante. Dies ist der Fall solange die Datengröße der nicht-lokalen Informationen die Datengröße
der Navigationsinformation nicht übersteigt. Sobald dies aber geschieht, wird bei der verteilten Variante
66
KAPITEL 4. ARCHITEKTUR
weniger OTA-Traffic verursacht als bei der lokalen Variante. Je mehr nicht-lokale Informationen benötigt
werden, desto größer wird diese Differenz. Je nach Menge nicht-lokaler Informationen muss hier also entschieden werden, welche Verteilungsalternative sich als sinnvoller erweist.
Kapitel 5
Implementierung
Im Rahmen dieser Arbeit wurde der in Kapitel 2.3 beschriebene MoBiLe-Service in die Realität umgesetzt.
Das Grundgerüst des Dienstes basiert auf den bereits beschriebenen Location-based Push-Services und der
in Kapitel 4 vorgestellten Architektur für derartige Dienste. Aus den zur Auswahl stehenden Technologien
für Ortung und Programmierung (vgl. Kapitel 3) wurden adäquate Technologien und deren unterstützende
Hardware ausgewählt, die für den MoBiLe-Service am geeignetsten erschienen. Außerdem musste eine
Wahl der Verteilung der einzelnen physischen LBPS-Schichten auf Entitäten erfolgen. Der Anfang dieses Kapitels ist diesen Entscheidungsfindungen gewidmet. Der darauf folgende Teil beschreibt wichtige
Aspekte der Implementierung. Leider würde eine vollständige Abhandlung aller Implementierungsdetails
den Rahmen dieser Arbeit sprengen. Deshalb werden nur einzelne Aspekte, die sich durch hohe Relevanz
oder entscheidende Lösungsansätze auszeichnen, hier vorgestellt.
5.1 Ortungssystem
Kapitel 3.1 zeigte bereits einige Ortungssysteme und deren Vor- und Nachteile. Aus den dort genannten
Argumenten, wie hohe Verfügbarkeit im ländlichen Bereich und hohe und relativ konstante Genauigkeit,
fiel die Entscheidung auf GPS. Dem Problem von GPS bezüglich der langen TTFF könnte mit A-GPS entgegengewirkt werden, wurde hier aber aufgrund des eingeschränkten zeitlichen Rahmens nicht umgesetzt.
Da es sich bei GPS um ein endgerätebasiertes Ortungsverfahren handelt, erfolgt die Bestimmung der Ortsinformationen auf dem mobilen Endgeräte. Bei der verteilten Variante des MoBiLe-Service hat diese Art
der Ortung den Nachteil, dass Signalisierungsdaten und gegebenenfalls Ortsinformationen über die Luftschnittstelle übertragen werden müssen. Dies wird in der Architektur aber relativ effizient umgesetzt und
verursacht so keine unnötigen Kosten.
Kriterien für die Wahl des GPS-Empfängers waren:
• Mobilität, d.h. keine Abhängigkeit von einer stationären Stromversorgung, externen Antenne oder
anderen Sensoren 1
• Kompatibilität mit dem Mobiltelefon (am besten durch drahtlose Verbindung)
• hohe Genauigkeit von ca. 10 Metern
• lange Akkulaufzeit (mind. 6 Stunden)
• A-GPS- und D-GPS-Funktionalität für evtl. spätere Integration
1 Obwohl viele GPS-Empfänger dies erfüllen, ist Mobilität keine zwingende Anforderung an GPS-Empfänger. Gegenbeispiele
hierfür liefern z.B. GPS-Empfänger für die Vermessung oder GPS-Empfänger für die Fahrzeugnavigation
67
68
KAPITEL 5. IMPLEMENTIERUNG
Fortuna Clip-On Bluetooth GPS Receiver
Ein GPS-Empfänger, der all diese Anforderungen erfüllt, ist der Fortuna Clip-On Bluetooth GPS Receiver
[for ]. Er ist ein mobiler GPS-Empfänger, der Ortsinformationen mittels des Bluetooth Serial Port Profile
(SPP) im NMEA0183-Format (Protokoll wird nachfolgend erläutert) übertragt. Der GPS-Empfänger arbeitet mit dem SiRF Star Ile/LP und SiRF Xtrac Chipsatz [sir ]. Er ist batteriebetrieben und hat eine Laufzeit
von ca. 8 Stunden. Durch seine geringe Größe (vgl. Abb. 5.1) lässt er sich leicht verstauen und ist deshalb
bestens geeignet, um ihn überall mitzuführen.
Abbildung 5.1: Fortuna Clip-On Bluetooth GPS Receiver
Durch die Erweiterung mit dem SiRF Xtrac Chipsatz kann er in zwei Modi betrieben werden. Diese sind
der Standard Modus (ST) und der SiRF Xtrac (XT) Modus. Durch den Betrieb im XT-Modus kann eine
wesentlich exaktere Positionsbestimmung durchgeführt werden. Diese ist sogar in weniger empfangsstarken Umgebungen möglich. Dadurch wird eine Ortung innerhalb von Gebäuden oder im Wald durchführbar.
Gegenüber dem ST-Modus reduziert der XT-Modus außerdem die Startzeiten. Im ST-Modus benötigt der
GPS-Empfänger durchschnittlich 0,1 Sekunden für die Wiederaufnahme der Positionierung bei kurzzeitigem Verbindungsabbruch, 8 Sekunden für den Heißstart, 38 Sekunden für den Warmstart und 45 Sekunden
für den Kaltstart. Im XT-Modus werden diese Werte um einige Sekunden verringert.
NMEA0183
Der Datenaustausch mit dem GPS-Empfänger basiert auf dem National Marine Electronics Association
(NMEA) [nme ] Protokoll. Das NMEA Protokoll wurde für den Datenaustausch zwischen verschiedensten
elektronischen Geräten (wie z.B. Mess-, Auswertungs-, Kontrollgeräte) der Marine entwickelt. Es kann
für 1-zu-1 oder 1-zu-n Verbindungen eingesetzt werden und spezifiziert Richtlinien sowohl für die Ebene
der Bitübertragung als auch der Nutzdatenübertragung. Die Übertragung erfolgt seriell und asynchron. Zur
Synchronisation wird jedem Zeichen - kodiert mittels 8-Bit ASCII - ein Startbit (0) vorangestellt und ein
Stopbit (1) angehängt. Heutzutage wird meist der NMEA-0183 Standard in der Version 2.x angewendet,
der auf dem EIA-422-Protokoll basiert und in der Regel den Datenaustausch mit einer Rate von 4800 Baud
vollzieht. Das neuere NMEA-2000 Protokoll beherrscht bereits Raten bis zu 38.400 Baud.
Auf Nutzdatenebene werden die Informationen in der Form von Datensätzen (Sentences) übertragen. Meist
werden Gruppen von Datensätzen mit einer Rate von einem Hertz vom GPS-Empfänger gesendet. Datensätze beginnen grundsätzlich mit dem Zeichen $, gefolgt von einer zweistelligen Sender-ID und einer
dreistelligen Satz-ID. Jeder Datensatz wird durch die beiden Zeichen Carriage-Return (CR) und LineFeed (LF) beendet. Dazwischen befinden sich die einzelnen mit Komma getrennten Informationen des
Datensatzes. Welche Informationen im Datensatz enthalten sind, ist abhängig von der Art des Datensatzes.
Durch den NMEA Standard sind einerseits feste Datensatzformate definiert, andererseits können aber auch
proprietäre Formate eingesetzt werden. Feste Datensätze im Bereich der Ortung sind beispielsweise der
Recommended Minimum Specific GPS/TRANSIT Data (RMC), Global Positioning System Fix Data (GGA)
5.2. ENDGERÄTEPLATTFORM
69
und Actual track made good and speed over ground (VTG). Ein RMC-Datensatz des Fortuna Clip-On
Bluetooth GPS-Empfängers hat zum Beispiel folgende Gestalt:
$GPRMC,101907.583,A,4806.4273,N,01135.9562,E,0.37,61.05,180305,,,A*51
Wobei die einzelnen Teildatensätze folgende Bedeutung haben:
• GP = Sender-ID (=GPS)
• RMC = Satz-ID
• 101907.583 = UTC-Zeit (10:19:07 Uhr)
• A = Status (A=Active, V=Void/Error)
• 4806.4273 = Latitude (48◦ 6, 42730 )
• N = Lat-Hemisphäre (N=North, S=South)
• 01135.9562 = Longitude (11◦ 35, 95620 )
• E = Lon-Hemisphäre (E=East, W=West)
• 0.37 = Geschwindigkeit über der Erdoberfläche in Knoten pro Stunde
• 61.05 = Kurs über der Erdoberfläche (rechtsweisende Gradangabe)
• 180305 = Datum (18.03.05)
•
= magnetische Deklination in Grad
•
= Richtung der magnetischen Deklination
• A = Modus (A=Autonomous, D=Differential, E=Estimated, N=Not-Valid, S=Simulator (erst ab Version 2.3)
• *51 = Prüfsumme
Enthält ein Teildatensatz keinen Wert, wird er einfach frei gelassen. Resultat sind zwei aufeinander folgende Kommas (siehe Beispiel: magnetische Deklination). Die Prüfsumme, bestehend aus zwei Hexadezimalzahlen, ergibt sich aus einer Exclusive OR (XOR) Operation über alle Zeichen, ausgenommen von $ und *.
Maximal kann ein Datensatz eine Länge von 82 Zeichen (inklusive $ und CR/LF) besitzen.
Der Fortuna Clip-On Bluetooth GPS-Empfänger liefert standardmäßig mit einer Frequenz von einem Hertz
die Datensätze GGA, GSA, RMC und VTG. Alle 5 Sekunden kommen ein oder mehrere GSV-Datensätze
hinzu.
5.2
Endgeräteplattform
Als Endgerät kommen bei der Umsetzung des MoBiLe-Service prinzipiell PDAs oder jegliche Art von
Mobiltelefonen in Frage. Entscheidend bei der Wahl der Hardware waren folgende Voraussetzungen:
• Mobilität, d.h. keine Abhängigkeit von stationärer Stromversorgung, etc.
• Kommunikationsmöglichkeit zu drahtlosen Infrastruktur-MANs, z.B. durch GSM, GPRS oder
UMTS
• Kommunikationsmöglichkeit zu drahtlosen PANs (vor allem Bluetooth zur Kommunikation mit dem
GPS-Empfänger)
• lange Akkulaufzeiten im ständigen Betrieb (mind. 6 Stunden)
• Eingabemöglichkeiten, z.B. über ITU-T-Onehand-Tastatur oder Touchscreen
• Ausgabemöglichkeiten für:
70
KAPITEL 5. IMPLEMENTIERUNG
– grafische Informationen: über Display mit mindestens 150x100 Pixel
– verbale Informationen: über Lautsprecher oder drahtgebundene/drahtlose Kopfhörer
Für die auf der Hardware zur Verfügung gestellte Programmierplattform sind folgende Voraussetzungen
maßgebend:
• Integrationsmöglichkeit von Drittanbieteranwendungen
• Unterstützung der von der Hardware bereitgestellten Kommunikations-, Ein- und Ausgabemöglichkeiten
• Unterstützung von Fließkommazahlen v.a. für Umgang mit Positionsinformationen
• wenig Speicher- und Energieverbrauch
Sinnvoll ist desweiteren, wenn bereits kompilierter Code sowohl auf der Plattform des mobilen Endgerätes
als auch auf der Plattform der Infrastrukturkomponente ausführbar ist. Dadurch kann kompilierter Code
sowohl auf dem mobilen Endgerät als auf der Plattform der Infrastrukturkomponente ausgeführt werden.
Dies ist vor allem zur Realisierung verschiedener Verteilungsalternativen sinnvoll. Bei einer Veränderung
der Verteilung muss dadurch keine Anpassung und Neukompilation des Quellcodes erfolgen.
Die Entscheidung der Programmierplattform fiel vor allem wegen der zugrunde liegenden Plattformunabhängigkeit auf J2ME. Auch wenn hier Effizienzeinbußen in Kauf genommen werden müssen, überwiegen die Vorteile, die sich durch J2ME ergeben.
J2MEs CLDC 1.0, das sich durch ein optionales Paket zur Emulation von Fließkommazahlen erweitern
lässt, litt dadurch an enormen Effizienzeinbußen. Innerhalb der Configurations fiel daher die Wahl auf
CLDC 1.1. Im Bereich der Profiles fiel die Wahl auf MIDP 2.0, da sich dieses durch eine bessere Medienunterstützung gegenüber MIDP 1.0 auszeichnet. Da CLDC 1.1 keine Unterstützung für BluetoothVerbindungen liefert, diese aber zur Anbindung des GPS-Empfängers obligatorisch sind, wird zusätzlich
JABWT benötigt.
Bei der Wahl des mobilen Endgerätes fiel die Entscheidung auf ein Mobiltelefon, da diese standardmäßig
über eine WAN-Verbindung verfügen. Außerdem ist die Marktpenetration von Mobiltelefonen wesentlich
höher als bei PDAs. Mobiltelefone bieten den Vorteil, dass auf Mountain-Bike-Touren kein zusätzliches
Gerät mitgeführt werden muss.
Unter anderem sind Mobiltelefone, die sowohl CLDC 1.1, MIDP 2.0 und JABWT bereitstellen, als auch die
oben genannten Prämissen an die Hardware erfüllen, das Siemens S65 und das Nokia 6630. Leider wurde
im praktischen Einsatz festgestellt, dass das Siemens S65 erhebliche Fehler und Spezifikationsabweichungen in der Bluetooth-Implementierung aufweist (vgl. Kapitel 6.1.3). Diese treten nicht nur in Verbindung
mit J2ME auf, sondern auch bei der gewöhnlichen Nutzung. Eine Erneuerung der Firmware stellte sich für
das zugrunde liegende Gerät als nicht trivial heraus und wurde deshalb vermieden. Als mobiles Endgerät
wurde daher das Nokia 6630 eingesetzt (vgl. Abb. 5.2).
Abbildung 5.2: Nokia 6630
71
5.3. WEITERER HARD- UND SOFTWAREEINSATZ
Das Nokia 6630 ist das erste Serie 60 WCDMA/EDGE Mobiltelefon von Nokia (vgl. [for 04, nok ]). Es
läuft unter Symbian OS 8.0a und stellt J2ME mit CLDC 1.1, MIDP 2.0, JTWI 1.0, WMA, MMAPI,
JABWT, Nokia UI API, FileConnection/PIM API und M3GAPI bereit. Auf WANs kann mittels GSM,
GPRS, EGPRS und WCDMA über die Frequenzen 900, 1800 und 1900 MHz zugegriffen werden. Im
Bereich der PANs verfügt es über eine Bluetooth-Schnittstelle. Das Display des Nokia 6630 hat eine
Auflösung von 176x208 Pixel mit 65.000 Farben. Auf dem Display und mittels des eingebauten Lautsprechers oder Headsets lassen sich verschiedenste Medien wie Grafiken im PNG-Format, Töne im MIDI-,
WAV-, MP3-Format, etc. und Videos im H.263-, MPEG4- und Realvideo-Format darstellen.
Durch diese Eigenschaften, die kompakten Ausmaße, das relativ geringe Gewicht und ausreichende Akkulaufzeit eignet sich das Nokia 6630 gut für die Realisierung des MoBiLe-Service. Bis auf die teilweise sehr
lange Start- und Reaktionszeit des Betriebssystems und der darauf installierten Applikationen, verhielt sich
das Nokia 6630 während der ganzen Arbeit entsprechend der Erwartungen und Spezifikationen.
5.3 Weiterer Hard- und Softwareeinsatz
Die Entwicklung des Demonstrators erfolgte unter MacOSX 10.2.8 auf einem Apple ibook2 mit der Entwicklungsumgebung Eclipse 3.0 M4 und Suns Java 1.4.1 01. Leider stellte sich heraus, dass derzeit unter
MacOSX 10.2.8 die Unterstützung für J2ME sehr rudimentär ist und nur unter erhöhtem Arbeitseinsatz
durchgeführt werden konnte. So mussten zum Beispiel die CLDC- und MIDP-Bibliotheken im Zuge der
Anpassung komplett neu übersetzt werden. In den letzten Monaten traten aber einige Projekte in Erscheinung, die eine Entwicklung von J2ME unter MacOSX vorantreiben wollen.
Als Application Server in der Infrastruktur kam ein Intel Pentium III mit 512 MB RAM zum Einsatz. Die
Wahl des Betriebssystems fiel auf FreeBSD (Release 5.3). FreeBSD ist ein freies open-source Betriebssystem und hat seinen Ursprung in 4.4BSD. Besonders bekannt ist FreeBSD für seine Schnelligkeit, Stabilität und vor allem Sicherheit. Kontinuierliche Updates machen FreeBSD zu einem der sichersten und leistungsfähigsten Betriebssysteme. Es eignet sich deshalb hervorragend für die Nutzung als Webserver oder
Application Server. In der verteilten Ausführung des MoBiLe-Service wurden die MoBiLe-Applikation
sowie die beiden Middlewareschichten auf diesem System betrieben.
5.4
Verteilung
a)
b)
Presentation
Mobile
Device
Presentation MW
Mobile
Device
Application
Presentation MW
Application
Server
Initiation MW
Initiation
Presentation
Application
Initiation MW
Mobile
Device
Initiation
Abbildung 5.3: Verteilungsalternativen
Für die Verteilung der Dienstschichten ergeben sich aus Kapitel 4.3 zwei sinnvolle Verteilungsalternativen. Ist ausreichende Connectivity gegeben, so kann eine verteilte Schichtenstruktur gewählt werden (vgl.
72
KAPITEL 5. IMPLEMENTIERUNG
Abb. 5.3b). Ist die Connectivity nicht ausreichend, ein (Pre-)Caching aber möglich, ist eine lokale Dienstausführung vorzuziehen (vgl. Abb. 5.3a). In der Implementierung sollen beide Ansätze umgesetzt werden.
Die beiden Ansätze sollen allerdings nicht durch zwei vollkommen getrennte Implementierungen realisiert
werden. Dazu müssen einerseits die Implementierung der LBPS-Schichten und andererseits die Implementierung der Kommunikation zwischen den Schichten dies unterstützen.
5.4.1
Inter-LBPS-Schichtenkommunikation
Zwei benachbarte Schichten können entweder innerhalb eines Systems (mobiles Endgerät oder Infrastruktur) oder auf getrennten Systemen angesiedelt werden. Damit diese Schichten innerhalb eines Systems
oder über Systemgrenzen hinaus Daten austauschen können, müssen die Schichten durch ein dynamisches
Verbindungskonstrukt interagieren. Native Methodenaufrufe sind hierfür nicht geeignet, da sie nur Methodenaufrufe innerhalb eines Systems zulassen. Socketverbindungen sind prinzipiell gut geeignet, um
Daten zwischen unterschiedlichen Systemen auszutauschen. Leider ist eine Verknüpfung mittels Socketverbindungen auf mobilen Endgeräten derzeitig nur unter Einbezug der Infrastruktur möglich (vgl. Kapitel
6.1.2).
Schicht A
DCF
Stub A
Native
Socket
Native
Socket
Stub B
Schicht B
Abbildung 5.4: Dynamic Connection Framework (DCF)
Deshalb wurde in diesem Zusammenhang eine Kombination aus nativen Methodenaufrufen und Methodenaufrufen über Socketverbindungen gewählt. Jedoch war ein Ziel, keine Codeanpassung für diese zwei
unterschiedlichen Arten des Methodenaufrufs durchführen zu müssen. Realisiert wurde dies durch einen
aus dem Bereich der Middleware bekannten Ansatz, die so genannten Stubs. Stubs verschatten den eigentlichen Methodenaufruf. Innerhalb der einzelnen Schichten erscheint ein Methodenaufruf als einfacher
nativer Methodenaufruf. Wie er jedoch in der Realität umgesetzt wird, bleibt dort verborgen.
Die Stubs stellen alle Methoden der korrespondierenden Schicht zur Verfügung. Der Stub verhält sich
also so, als wäre er die korrespondierende Schicht. Wird eine Methode innerhalb des Stubs aufgerufen,
prüft dieser, ob die korrespondierende Schicht lokal oder entfernt verfügbar ist, und ruft dann entsprechend dieser Gegebenheit die Methode auf der korrespondierenden Schicht auf. Dazu bleibt bei lokaler
Verfügbarkeit der native Methodenaufruf erhalten, bei entfernter Verfügbarkeit wird der Methodenaufruf
über eine Socketverbindung realisiert. Da über die Socketverbindung kein direkter nativer Methodenaufruf
in der korrespondierenden Schicht durchgeführt werden kann, verfügt die korrespondierende Schicht bei
Verteiltheit über einen äquivalenten Stub, der aus den über die Socketverbindung empfangenen Daten wieder native Methodenaufrufe generiert. Abbildung 5.4 zeigt das dynamische Verbindungskonstrukt (DCF)
für die zwei Schichten A und B. Prinzipiell ist das DCF-Konstrukt nicht an diese zwei Verbindungstypen
5.4. VERTEILUNG
73
gebunden, sondern kann durch die Integration verschiedenster Verbindungstypen beliebig erweitert werden.
Für die Kompatibilität zweier Schichten müssen diese ein gemeinsames Verständnis über die zwischen ihnen ausgetauschten Nachrichten (vgl. [VHT ]) besitzen. Dieses gemeinsame Verständnis bezieht sich auf
die Signatur, die Semantik und das Protokoll. Unter Signatur versteht man das gemeinsame Verständnis
bezüglich der Syntax. Ein syntaktisch gemeinsames Verständnis wird in der Regel durch die Einführung
von Interfaces erzielt. Interfaces beschreiben die von einer Komponente verstandenen Ausdrücke auf der
Ebene der Signatur. Sie definieren also die Syntax aller Ausdrücke, die von einer Komponente verstanden
werden.
Ein gemeinsames Verständnis auf der Ebene der Semantik wird dadurch erreicht, dass alle beteiligten Komponenten den Ausdrücken die gleiche Bedeutung zumessen. Durch die Angabe von Typen innerhalb eines
Interfaces wird ein gewisser Grad an Semantik für das gemeinsame Verständnis spezifiziert. So kann einem Parameter namens Position“, der noch keinerlei semantische Information enthält, durch die Angabe
”
des Typs WGS84Position“ die Bedeutung einer Positionsinformation georeferenziert zum WGS84-Datum
”
zugeordnet werden. Eine weitere Spezifikation auf der Ebene der Semantik wurde an dieser Stelle nicht
weiter fortgeführt.
Auf der Ebene des Protokolls muss ein gemeinsames Verständnis über die Reihenfolge der Ausdrücke erreicht werden. Angaben zur Reihenfolge von Parametern sind in den Interfaces enthalten. Die Reihenfolge
der einzelnen Methodenaufrufe wurde in der Implementierung nicht weiter beachtet, da es sich um eine
(beinahe) zustandslose Kommunikation handelt und so Reihenfolgen von Methodenaufrufen keine Rolle
spielen.
Ein großer Teil der Kompatibilitätsspezifikation wird demnach bereits durch Interfaces abgedeckt. Deshalb
wurden bei der Implementierung ausschließlich Interfaces für das gemeinsame Verständnis spezifiziert. Ein
Interface, welches das Verständnis der Dienstinitiierungschicht bzw. ihres Stubs für native Methodenaufrufe beschreibt, ist im Folgenden gegeben (in Form eines Java-Interfaces):
2
4
public interface InitiationInterface
{
void setTriggers(ECARule[] triggers);
void deleteTriggers(TID[] tIDs);
}
Entsprechend dieses Interfaces versteht die Dienstinitiierungsschicht bzw. deren nativer Stub zwei Methodenaufrufe namens setTriggers und deleteTriggers. Wobei setTriggers nachfolgend ein
Array aus einzelnen ECA-Regeln vom Typ ECARule erwartet und deleteTriggers ein Array aus
Trigger-IDs vom Typ TID.
Durch die Spezifikation dieser Interfaces und der Implementierung des Interfaces durch die entsprechende
Klasse bzw. die korrespondierenden Stubs des DCF wird Kompatibilität gewahrt. Ein Klassendiagramm
des DCF, das die Interfaces zweier Schichten enthält, ist in Abbildung 5.5 dargestellt.
Für die Methodenaufrufe über die Socketverbindung wurde ein proprietäres Übertragungsprotokoll 2 verwendet. Standardisierte Protokolle wie HTTP oder SMTP zeigten für diese Anwendung einen zu großen
Signalisierungsoverhead und wurden deshalb nicht eingesetzt. Das hier eingesetzte Übertragungsprotokoll
besteht im Wesentlichen aus dem in UTF-8 kodierten Methodennamen und den aneinander gereihten Parametern. Als Transportprotokoll wurde TCP eingesetzt.
Während bei nativen Methodenaufrufen in Java Objekte wie ECARule oder TID direkt (bzw. Zeiger
auf diese Objekte wegen Call-By-Value-Parameterübergabe) übergeben werden, kann diese Art der Parameterübergabe nicht für die Socketverbindung eingesetzt werden, da durch die verteilten Systeme kein
Shared-Memory vorhanden ist. Zur Übergabe der Parameter müssen diese in eine serialisierte Form gebracht und in dieser Form an den Empfänger übertragen werden. Aufgrund der Tatsache, dass J2ME mit
CLDC derzeit keine Objektserialisierung unterstützt, können nur primitive Datentypen (wie z.B. int,
double oder char) oder Objekte, die ausschließlich öffentlich zugängliche primitive Datentypen (wie
z.B. Arrays über primitive Datentypen, Wrapper-Klassen) oder serialisierbare Objekte enthalten, übertragen werden. Die Methoden zur Übertragung primitiver Datentypen und Character-Arrays werden von
2 Das Übertragungsprotokoll definiert die Form, in der Daten übertragen werden, und ist von [VHT ]s Protokollebene zu unterscheiden
74
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.5: Vereinfachtes Klassendiagramm des DCF
J2ME zur Verfügung gestellt. Zu implementieren war in diesem Zusammenhang deshalb nur noch die
Objektserialisierung, die Objekte auf primitive Datentypen abbildet. Dazu wurden jeder Klasse, die über
die Socketverbindung übertragen werden muss, die Methoden serialize und deserialize hinzugefügt, um die Objekte der Klasse serialisieren und deserialisieren zu können. Zur Serialisierung werden
alle Instanzvariablen des Objektes sowie in manchen Fällen Zusatzinformationen serialisiert. Handelt es
sich dabei ausschließlich um primitive Datentypen, so ist die Serialisierung damit abgeschlossen, und die
primitiven Datentypen können übertragen werden. Sind in den Instanzvariablen aber Objekte enthalten
(diese müssen nach obiger Bedingung serialisierbar sein), so muss ein weiterer Rekursionsschritt ausgelöst
werden, der die Serialisierung der Objekte durchführt.
Allgemein muss der Caller-Stub für Socketverbindungen so nur die Methode serialize auf das zu
übergebende Objekt aufrufen und der Callee-Stub mittels der Methode deserialize das Objekt aus
dem empfangenen Datenstrom wieder aufbauen. Dadurch wurde ein kongruentes Konstrukt zur Objektserialisierung in J2SE geschaffen.
5.4.2
Plattformunabhängigkeit der Schichten
Nachdem nun die Kompatibilität zwischen den einzelnen Schichten betrachtet wurde, muss desweiteren die Kompatibilität zu den darunter liegenden Schichten der Plattform analysiert werden (vgl. Abb.
5.5. UMSETZUNG DER LBPS-SCHICHTEN
75
3.4). Je nach Verteilung der Schichten verändert sich die darunter liegende Programmierplattform. Lokale Schichten nutzen J2ME, Schichten in der Infrastruktur J2SE (vgl. Kapitel 3.2). Ein dynamischer Ansatz, der abhängig von der zugrunde liegenden Verteilung die Kommunikation anpasst, wie bei der InterLBPS-Schichtenkommunikation, ist bei der Inter-Plattform-Schichtenkommunikation“ nur sehr umständ”
lich realisierbar. Da beide Plattformen sich im Grunde genommen sehr ähnlich sind und eine gemeinsame Funktionsschnittmenge besitzen, die einen großen Teil der Basisfunktionalität enthält und von beiden Plattformen unterstützt wird, wurde in der Implementierung der LBPS-Schichten versucht, sich auf
diese Funktionsschnittmenge zu beschränken. Bis auf die Klassen, die für die Netz- (java.net) und IOVerbindungen (java.io) zuständig sind gelang dies ohne großen Aufwand. Das Problem der Netz- und IOVerbindungsklassen wurde durch die Integration eines Adapterpaketes [me4 ] seitens der J2SE-Plattform,
das eine Transformation der J2ME-Verbindungsklassen auf die J2SE-Verbindungsklassen durchführt,
gelöst. Dadurch war es möglich, alle LBPS-Schichten auf der J2ME- oder der J2SE-Umgebung auszuführen.
5.5 Umsetzung der LBPS-Schichten
Dieses Kapitel zeigt einige Implementierungsdetails der LBPS-Schichten Dienstinitiierung, Initiierungsmiddleware, Dienstausführung, Präsentationsmiddleware und Dienstpräsentation. In der
Schicht der Dienstausführung dient die MoBiLe-Applikation der eigentlichen Mehrwertgenerierung
des Mountain-Bike-Navigationsdienstes. Für die entsprechenden Klassen wurde der Namensraum
de.vpe.mobile.application gewählt. Die Dienstinitiierung, die Initiierungsmiddleware, die Präsentationsmiddleware und die Dienstpräsentation stellen die Location-based Push-Architektur dar, die
der MoBiLe-Applikation die Push-Funktionalität zur Verfügung stellt. Die Klassen dieser Schichten sind folgenden Namensräumen zugeordnet: de.vpe.lbps.initiation, de.vpe.lbps.initiationmiddleware,
de.vpe.lbps.presentationmiddleware und de.vpe.lbps.presentation. Dabei gibt es einige Konstrukte, die innerhalb mehrerer Schichten auftreten. Dazu gehören zum Beispiel die Klassen, die zur Beschreibung von
Ortsinformationen dienen oder das Konzept der ECA-Regeln. Ihre Pakete wurden unter dem Namensraum
de.vpe.lbps.shared zusammengefasst (vgl. Abb. 5.6.
Im Folgenden wird kurz auf die Implementierung der einzelnen Schichten eingegangen. Da eine vollständige Abhandlung aller Implementierungsdetails den Rahmen dieser Arbeit sprengen würde, würden nur einige Aspekte aufgegriffen, die die Funktionsweise des Demonstrators veranschaulichen sollen. Eine Gliederung erfolgt anhand der einzelnen Schichten des Dienstes. Dabei werden einige Implementierungsdetails
aus dem Paket de.vpe.lbps.shared aufgrund der Relevanz innerhalb mehrerer Schichten der Beschreibung
der einzelnen Schichten vorangestellt.
5.5.1
Ortsinformationen
Da der Fortuna Clip-On Bluetooth GPS Receiver wie die meisten handelsüblichen GPS-Empfänger standardmäßig Positionsinformationen im WGS84-Datum ausdrückt und keine weiteren Datums notwendig
waren, wurde ausschließlich dieses Datum mit dem entsprechenden Format zur Kodierung von Positionsinformationen genutzt. Aufgrund der zeitlichen Restriktionen dieser Arbeit wurden nur zweidimensionale
Positionsinformationen auf der Erdoberfläche und keine Informationen zur Hemisphäre eingesetzt. Zur
Bestimmung der Bewegungsrichtung wurde neben der Position die Richtung als zweite primäre Ortsinformation benutzt. Schließlich kam für die frühzeitige Dienstinitiierung, abhängig von der Geschwindigkeit
des Nutzers, die sekundäre Ortsinformation Geschwindigkeit hinzu. Für die Implementierung ergaben sich
demnach drei verschiedene Ortsinformationen, wobei Latitude und Longitude der Position durch zwei getrennte Klassen behandelt wurden (vgl. Abb. 5.7.
76
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.6: Überblick über Paketstruktur
5.5.2
Trigger
Wichtige Softwarebausteine, die vor allem für die Dienstinitiierung von Interesse sind, sind die in Kapitel
4.2 vorgestellten Trigger. Wie bereits beschrieben, kann eine Operationalisierung durch ECA-Regeln erfolgen. Diese wurden auch für den Demonstrator gewählt. Im Speziellen handelt es sich hierbei um Locationbased ECA-Regeln. Im Gegensatz zu allgemeinen ECA-Regeln, sind Location-based ECA-Regeln auf die
ortsabhängige Initiierung ausgerichtet. Allgemein bestehen ECA-Regeln aus einer Menge von Ereignissen,
einer Bedingung und einer Menge von Aktionen. Für Location-based ECA-Regeln stellen Ereignisse jegliche Art von Ortsinformationen dar und Bedingungen können als freie Variablen lediglich Variablen von
der Typklasse der Ortsinformationen enthalten. Aktionen sind zuständig für die eigentliche Initiierung des
Dienstes und können zusätzlich Ortsinformationen enthalten.
Jede ECA-Regel muss mindestens diese drei Elemente besitzen. Da sich Trigger von Dienst zu Dienst
unterscheiden können und auch innerhalb eines Dienstes unterschiedliche Trigger zur Anwendung kommen können, müssen diese dynamisch konfigurierbar sein. Das bedeutet, dass sie nicht durch ein festes
Konstrukt umsetzbar sind, sondern die Ereignisse, Bedingungen und Aktionen für jeden Trigger frei definiert werden können. In vielen Fällen, jedoch nicht zwingend, werden diese Trigger innerhalb der Dienstausführungsschicht generiert. Diese hat meist alle nötigen Informationen, die für die Generierung der Trigger notwendig sind. Sie weiß, welche Ereignisse für die Auswertung relevant sind, wie die Bedingung
gestaltet sein muss und welche Form die Aktionen haben müssen. All diese Informationen sind zur Generierung der Trigger wichtig und müssen innerhalb der ECA-Regeln dynamisch konfigurierbar sein.
Eine sinnvolle Lösung zur Implementierung dieser ECA-Regeln ist deshalb, alle Informationen und Funktionen für den Trigger innerhalb des Triggers zu kapseln und eine Zugriffsmethode, z.B. updateSpatialInformation(SpatialInformation[] si), zu definieren, die dem Trigger neue Ortsinformationen übergibt. Der Trigger überprüft dann selbstständig, ob die neuen Ortsinformationen eine Auswertung der Bedingung nötig machen. Falls ja, wird die Bedingung ausgewertet und gegebenenfalls eine
Aktion ausgelöst. Der Initiator hat so nur die Aufgabe, bei Verfügbarkeit neuer Ortsinformationen die up-
5.5. UMSETZUNG DER LBPS-SCHICHTEN
77
Abbildung 5.7: Klassendiagramm der eingesetzten Ortsinformationen
dateSpatialInformation-Methode des Triggers aufzurufen. Alle restlichen Schritte übernimmt der
Trigger selbst. Dadurch sind alle für diesen Trigger relevanten Informationen und Funktionen innerhalb des
Triggers gekapselt und der Initiator benötigt kein Wissen über die Trigger außer deren standardisierte Zugriffsmethode.
Da der Classloader von J2ME nur das Laden von Klassen zulässt, die zum Installationszeitpunkt in der
MIDlet-Suite enthalten sind (vgl. Kapitel 3.2), müssen alle für die Anwendung nötigen ECA-Regeln bereits zum Installationszeitpunkt existieren. Dies führt auf den ersten Blick zu einer starken Einschränkung
der Anwendbarkeit, vor allem in Bezug auf eine Vielzahl verschiedener LBPSs. Bereits zum Installationszeitpunkt muss bekannt sein, welche Art von Triggern jemals innerhalb des Systems eingesetzt werden,
um sie alle in der MIDlet-Suite zu integrieren. Lösung dieses Problems stellt eine generische ECA-Regel
dar, deren Ausprägungen sich nur durch die Belegung der Instanzvariablen unterscheidet. Diese generische
ECA-Regel kann bereits zum Installationszeitpunkt in die MIDlet-Suite integriert werden. Einzelne Ausprägungen der ECA-Regeln ergeben sich dann durch Belegung der Instanzvariablen.
Die generische ECA-Regel muss als Instanzvariablen mindestens die dynamisch konfigurierbaren Elemente Ereignisse, Bedingung und Aktionen enthalten. Erweiterte ECA-Regeln können natürlich weitere
Konfigurationsmöglichkeiten unterstützen, wie die Spezifikation von Gedächtnisstufen oder Detriggering
(vgl. [Brow ]). In der Implementierung dieser Arbeit wurde aber nur die einfache Variante der generischen
ECA-Regel eingesetzt, da diese die Funktionsfähigkeit bereits ausreichend demonstriert.
Bei der Anwendung der Location-based Push-Architektur unter Verteiltheit, müssen Objekte der ECARegeln über Systemgrenzen hinaus übertragen werden. Dazu ist eine Serialisierung einzelner ECA-Regeln
nötig. Wie bereits oben beschrieben, wird nur eine Objektserialisierung von Objekten, die ausschließlich
serialisierbare Instanzvariablen enthalten, unterstützt. Dazu müssen alle Instanzvariablen aus primitiven
Datentypen, bzw. aus serialisierbaren Objekten bestehen.
Da Ereignisse nur beschreiben, welchen Typ die Ortsinformationen haben müssen, die die Auswertung der
Bedingung nötig machen, reicht hier eine Angabe der oben beschriebenen Typklasse der Ortsinformation
aus. Sie bestehen demnach aus einer Menge an Ortsinformationstypen. Ortsinformationstypen enthalten
nur ihren Namen, der als String (bzw. Array aus Charactern) serialisierbar ist.
Um die Bedingung in eine serialisierbare Form zu bringen, wurde eine String-Repräsentation der Bedingung gewählt. Zur Auswertung dient eine Java-Bibliothek namens JEPLite (Java Expression Parser Lite)
[Kola ]. Obwohl diese für J2SE konzipiert wurde, war eine Anpassung an J2ME unter Verlust einer geringen Funktionsmenge möglich. JEPLite ist eine vereinfachte Version von JEP [Funk ]. JEPLite stellt einen
etwas geringeren Funktionsumfang als JEP bereit, zeigt sich deshalb aber effizienter in der Auswertung und
geringer in der Größe, was sich positiv auf die Anwendung auf mobilen Endgeräten auswirkt. JEP sowie
JEPLite stellen Funktionen zum Parsen und Auswerten von mathematischen Ausdrücken innerhalb von
Strings zur Verfügung. Diese Ausdrücke können mathematische Operatoren wie die Addition, Substrakti-
78
KAPITEL 5. IMPLEMENTIERUNG
on, Multiplikation und Division, sowie die Potenz-, Wurzel- und Modulo-Funktion enthalten. Desweiteren
können Boole’sche Operatoren, wie das Boole’sche AND, das Boole’sche OR und das Boole’sche NOT
und mathematische Konstanten wie Pi und die Euler’sche Zahl genutzt werden. Nach der Anpassung auf
J2ME blieben außerdem noch die trigonometrischen Funktionen Sinus, Kosinus und Tangens bestehen.
Mit dem gelieferten Funktionsumfang ließen sich alle für dieses Anwendungsszenario nötigen Bedingungen umsetzen.
Aktionen stehen in zwei Varianten zur Verfügung, die für das Anwendungsszenario ausreichend sind.
Diese sind InitiateAction und InitiatePiggyBackingDataAction. Während erstere ausschließlich zur reinen Dienstinitiierung gedacht ist, lässt die InitiatePiggyBackingDataAction
das Anhängen von Ortsinformationen zu. Die Ortsinformationen werden dann, falls verfügbar, an die Initiierungsnachricht angehängt.
Durch das hier beschriebene Konzept der ECA-Regeln konnten alle Anforderungen wie gewünscht umgesetzt werden. Durch seine Dynamik ermöglicht dieser Ansatz hierüber hinaus sogar einen Einsatz in
weitaus mehr Anwendungen als nur dem MoBiLe-Service.
5.5.3
Dienstinitiierung
Die Dienstinitiierungsschicht ist zuständig für die Anwendung der oben beschriebenen ECA-Regeln. Ausreichend für die Implementierung des MoBiLe-Service ist vorerst ein einziger Initiator für Ortsinformationen, die durch den GPS-Empfänger geliefert werden. Dazu erhält der Initiator periodisch Ortsinformationen vom GPS-Empfänger durch eine Callback-Operation mit einer ähnlichen Umsetzung wie in der LAPI
(vgl. Kapitel 3.2). Zwischen Initiator und GPS-Empfänger dient ein Parser zur Generierung der Ortsinformationsobjekte. Der Parser extrahiert dazu die Position (Latitude und Longitude), die Bewegungsrichtung
und die Geschwindigkeit aus dem RMC- und dem VTG-Datensatz des NMEA-Protokolls und baut daraus
oben beschriebene Ortsinformationsobjekte auf.
Wurden dem Initiator bereits Trigger zugeteilt, so ruft dieser bei jeder Aktualisierung der Ortsinformationen die updateSpatialInformation-Methode jedes einzelnen Triggers auf. Der Trigger wertet
dann, wenn es sich um eine relevante Ortsinformation handelt, die Bedingung aus und sucht entsprechende
Aktionen. Eine direkte Ausführung der Aktionen soll innerhalb des Triggers nicht möglich sein, da dieser
ansonsten Kenntnis über die korrespondierende Initiierungsmiddleware benötigen würde, diese aber dem
Trigger verborgen bleiben soll. Deshalb gibt der Trigger durch den Aufruf der updateSpatialInformation-Methode alle durchzuführenden Aktionen zurück, die dann vom Initiator ausgeführt werden.
Abbildung 5.8 zeigt das vereinfachte Klassendiagramm der Dienstinitiierungsschicht.
5.5.4
Initiierungsmiddleware
In der Initiierungsmiddleware wird der gegenseitige Zugriff der Dienstinitiierungsschicht und der Dienstausführungsschicht verwaltet. Der Verbindungsaufbau wird dabei von der Dienstausführungsschicht angestoßen. Im Normalfall wird eine Applikation zu Beginn einer Interaktion die zur Initiierung nötigen Trigger
in der Dienstinitiierungsschicht anmelden. Deshalb übergibt sie die nötigen Trigger an die Initiierungsmiddleware, welche Kenntnis über alle derzeit zur Verfügung stehenden Initiatoren besitzt. Jeder Initiator
muss sich dazu bei der Initiierungsmiddleware registrieren. Bestandteil der Anmeldung ist die Menge an
Ortsinformationen, die dieser Initiator durch Sensoren verwaltet. Die Initiierungsmiddleware legt die Informationen zu den Sensoren und zur Verbindung mit dem Initiator in einer geeigneten Speicherstruktur
ab, um so bei Bedarf darauf zurückgreifen zu können.
Will nun eine Applikation Trigger auf Initiatoren verteilen und übergibt sie in diesem Schritt an die Initiierungsmiddleware, so sucht diese nach geeigneten Initiatoren in der Menge aller registrierten Initiatoren. Ist
die Suche erfolgreich, übergibt sie dem jeweiligen Initiator über die abgespeicherte Verbindung den oder
die Trigger. Falls für einen Trigger kein entsprechender Initiator verfügbar ist, erhält die Applikation eine
negative Quittung.
Bei einer späteren Initiierung ruft der Initiator die Methode initiate mit seiner ID, der ID des gefeuerten Triggers und angehängten Ortsinformationen im Falle der InitiatePiggyBackingDataAction
5.5. UMSETZUNG DER LBPS-SCHICHTEN
79
Abbildung 5.8: Dienstinitiierung
auf. Die Initiierungsmiddleware leitet die Initiierung dann an die entsprechende Applikation weiter.
5.5.5
Navigationsdienst MoBiLe
Die Dienstausführungsschicht stellt in dieser Arbeit die MoBiLe-Applikation dar. Sie entspricht dem Kern
des MoBiLe-Service und ist somit für die eigentliche Navigation verantwortlich. Ohne große Anpassung
lässt die Implementierung aber auch andere LBPSs parallel zum MoBiLe-Service zu. Derartige Dienste
können zum Beispiel der ortsabhängige Email-Push-Dienst sein. Dieser wird aber im Folgenden nicht
weiter behandelt.
Darstellungsformen
Die MoBiLe-Applikation generiert Navigationsinformationen, die sich durch qualitativ hochwertigen Informationsgehalt auszeichnen, und so vom Nutzer einen möglichst geringen kognitiven Aufwand verlangen. Eine diesen Anforderungen entsprechende Darstellung ist die egozentrische Pfeildarstellung. Sie besteht aus einem einzigen Pfeil und keinen Informationen über ortsnahe Landmarken wie die Kartendarstellung. Dadurch ist sie nur in einem äußerst geringen Umfeld gültig, zeichnet sich aber demgegenüber
dadurch aus, dass sie keinerlei unnötigen Informationsgehalt enthält. Durch die Egozentrik referenziert zur
Bewegungsrichtung muss der Nutzer keine Umorientierung der Darstellung durchführen. Grundsätzlich
stehen der Applikation durch die Routenbeschreibung aber nur allozentrische Routeninformationen zur
Verfügung. Zur Transformation der allozentrischen Darstellung in die egozentrische Darstellung muss die
Applikation Kenntnis über die aktuelle Bewegungsrichtung des Nutzers besitzen. Ist diese nicht verfügbar,
wird keine Transformation durchgeführt, dafür aber die Allozentrik in der Darstellung markiert.
Problem aller grafischen Darstellungen ist, dass sie zur Wahrnehmung die Aufmerksamkeit des mensch-
80
KAPITEL 5. IMPLEMENTIERUNG
lichen Sehsinnes benötigen. Während dies bei geringen Geschwindigkeiten (z.B. bei Fußgängern) kein
Problem darstellt, kann eine ausschließlich visuelle Wahrnehmung bei hohen Geschwindigkeiten meist
nicht angewendet werden, da der Sehsinn bereits für die Koordination der Bewegung benötigt wird. Deshalb setzt die Applikation eine weitere Darstellungsform ein, die auf ein anderes menschliches Sinnesorgan
gerichtet ist. Zusätzlich zur visuellen Wahrnehmung wird die akustische Wahrnehmung genutzt. Dazu generiert die Applikation eine verbale Darstellung der Navigationsinformation. Sie beinhaltet ausschließlich
egozentrische Navigationsinformationen (referenziert zur Bewegungsrichtung). Dafür wurde die einzuschlagende egozentrische Richtung in zwei Bereiche quantisiert. Der rechtsweisende Bereich deckt das
Intervall 1◦ − 179◦ und der linksweisende Bereich das Intervall 181◦ − 359◦ gegenüber der Bewegungsrichtung ab.
Die verbale Darstellung präsentiert eine gröbere Navigationsinformation als die korrespondierende grafische Darstellung, ermöglicht aber eine Wahrnehmung der Navigationsinformation ohne Gebrauch der
visuellen Sinnesorgane, die bereits für die Bewegung benötigt werden. Die verbale Darstellung gilt eher
als unterstützend, während die grafische Darstellung als primäre Darstellungsform gilt.
Routen
Die entscheidende Information, die zur Generierung der Navigationsinformation dient, ist die Route.
Die Operationalisierung der Route basiert auf der in Kapitel 2.2 vorgestellten Routenbeschreibung mittels Aktionspunkten. Dementsprechend besteht eine Route aus einer geordneten Liste aus Aktionspunkten. Jeder Aktionspunkt besitzt eine Position und eine an diesem Aktionspunkt einzuschlagende Richtung. Zusätzlich muss es die Möglichkeit geben, Routen durch Beschreibungen wie Name der Route, Schwierigkeitsgrad, Länge der Route, zu überwindende Höhenmeter, etc. zu annotieren. Da Art und
Menge dieser Annotationen sich von Route zu Route unterscheiden können, wurde hier eine Klasse
(de.vpe.lbps.shared.route.RouteProperty) geschaffen, die beliebige Key-Value-Paare enthalten kann. Jeder Route können beliebig viele dieser RoutePropertys angehängt werden. Die ebenfalls in der Route enthaltenen Aktionspunkte werden durch die oben genannten Positionsinformationen
beschrieben. Außerdem besitzen sie eine Richtungsinformation, um die einzuschlagende Richtung zu deklarieren.
Routeninformationen werden von Routendiensten bereitgestellt. Die Implementierung eines einfachen
Routendienstes, der eine grafische Routenerstellung zulässt, ist im Anhang A beschrieben. Dieser Routendienst stellt entweder komplette Routen, die Annotationen von Routen oder die Aktionspunkte von Routen
an einer wohldefinierten Schnittstelle bereit. Diese können vom Navigationsdienst dort abgerufen werden.
Generierung der Initiierungsvorschrift
Zu Beginn einer Navigation generiert die Navigationsapplikation aus den Aktionspunkten der Route die
oben beschriebenen ECA-Regeln. Pro Aktionspunkt wird eine ECA-Regel erzeugt. Da für die Navigation
relevante Zustände nur durch eine Positionsveränderung eintreten können, sind Ereignisse jeder ECARegel vom Typ Latitude und Longitude. Die Bedingung, die bei Eintritt des Ereignisses ausgewertet werden
soll, entspricht im Grunde genommen der Bedingung, die bereits in Kapitel 4.2 erarbeitet wurde:
(ux − ax )2 + (uy − ay )2 ≤ (t · v)2
Für t zeigte sich in der Realität ein Wert von 4 Sekunden als ausreichend lang, um die Navigationsinformation aufzunehmen und zu verarbeiten, und andererseits als kurz genug, um Zweideutigkeiten in der
Wegewahl zu vermeiden. Die praktische Nutzung des Fortuna Clip-On Bluetooth GPS Receivers zeigte,
dass eine Abweichung der realen Position und der gemessenen Position von bis zu ∼ 10 Metern erreicht
wird. Um dieser Ungenauigkeit entgegenzuwirken, musste der Radius des Aktionskreises um diese 10
Meter erweitert werden. In der Bedingung wurde dies durch Hinzunahme einer Konstanten in die Radiusberechnung erreicht:
(ux − ax )2 + (uy − ay )2 ≤ (4 · v + 10)2
5.5. UMSETZUNG DER LBPS-SCHICHTEN
81
Abbildung 5.9: Ellipsoidischer Abstand der Punkte P1 und P2
Diese Bedingung bezieht sich jedoch auf ein kartesisches, ebenes Koordinatensystem. Zur Berechnung
des Abstandes auf einer Ellipsoidenoberfläche 3 muss in der Betrachtung die Oberflächenkrümmung hinzugezogen werden (vgl. Abb. 5.9). Positionsinformationen stehen durch den Fortuna Clip-On Bluetooth
GPS Receiver in Form von LLA-Werten zum WGS84-Datum, d.h. in ellipsoidischen Koordinaten, bereit.
Ausgehend von der Position des Aktionspunktes und des Nutzers auf der Ellipsoidenoberfläche muss eine
Umrechnung auf den ellipsoidischen Abstand dieser Punkte erfolgen. Dazu werden getrennt die Abstände
auf dem Längenkreis und dem Breitenkreis bestimmt und dann daraus der Abstand zwischen den beiden
Punkten ermittelt.
Wie bereits in Kapitel 2.1 beschrieben wurde, gibt der Latitudenwert den Winkel zwischen Äquator, dem
Referenzpunkt und dem Breitengrad innerhalb eines Längenkreises an. Für die Berechnung des Abstandes
zwischen Nutzer und Aktionspunkt auf dem Längenkreis muss die Bogensegmentlänge bestimmt werden.
Da alle Längenkreise den gleichen Umfang besitzen, reicht die Umrechnung mittels eines konstanten Faktors aus. Hierbei entspricht eine Bogenminute einer Bogensegmentlänge von 1.852.276 Metern (≈ eine
nautische Meile) bei einem Meridianumfang von 40.009.153 Metern. Abbildung 5.10 zeigt den Abstand
auf dem Meridian lat∆ von P1 und P2 , die durch lat1 und lat2 beschrieben werden.
Etwas schwieriger ist die Berechnung des Abstandes auf dem Breitenkreis, da die Breitenkreise keinen
konstanten Umfang besitzen. Je weiter weg sich der Breitenkreis vom Äquator befindet, desto geringer
wird sein Umfang. Der Umfang des Breitenkreises kann jedoch mit einer gewissen Toleranz relativ einfach
berechnet werden und entspricht dem Produkt aus dem Kosinus des Latitudenwertes mit dem Äquatorradius (= 40.076.592 Meter). Mit Hilfe des Umfangs kann nun der Abstand zwischen Nutzer und Aktionspunkt
auf dem Breitenkreis berechnet werden.
Diese Abstandsberechnung unterliegt einigen Vereinfachungen. Eine exakte Berechnung des Abstandes
(soweit dies überhaupt möglich ist) steht aber in keinem Verhältnis zur Verbesserung des Gesamtergebnisses, da die hier berechneten Werte sich bereits sehr nahe an der Realität bewegen und eine Verbesserung
nur unter sehr hohem Rechenaufwand erzielt würde.
Insgesamt ergibt sich somit folgender logischer Ausdruck (Latituden- und Longitudenwerte in Dezimalgradangaben):
((ulat − alat ) · 1.852.276)2 + ((ulon − alon ) · cos(alat · 40.076.592)2 ≤ (4 · v + 10)2
Als Aktion wurde die InitiatePiggyBackingDataAction, die die aktuelle Bewegungsrichtung
an die Dienstinitiierung anhängt, gewählt. Für jeden Aktionspunkt muss nun eine ECA-Regel mit den hier
beschriebenen Ereignissen, Bedingungen und Aktionen erzeugt und der Initiierungsmiddleware übergeben
werden.
3 Zur
Vereinfachung wird in dieser Arbeit die Erde als Ellipsoid betrachtet
82
KAPITEL 5. IMPLEMENTIERUNG
P2
Meridian
lat2
lat1
latδ
lat∆
P1
Äquator
Abbildung 5.10: Abstand der Punkte P1 und P2 auf dem Längenkreis
Routenführung
Wird durch die Dienstinitiierungsschicht die Dienstausführung angestoßen, wird anhand der Route und
beliebiger anderer Informationen die Navigationsinformation in den oben beschriebenen Darstellungsformen generiert. Mindestens ist dazu der aktuelle Aktionspunkt mit der einzuschlagenden Richtung nötig.
Die Identifikation dieses Aktionspunktes erfolgt anhand der durch die Dienstinitiierung gelieferten ID des
gefeuerten Triggers. Die ID entspricht genau einem Aktionspunkt der Route. Die allozentrische Austrittsrichtung ist in diesem Aktionspunkt spezifiziert. Die Austrittsrichtung kann bereits zur Generierung der
allozentrischen Navigationsinformation genutzt werden. Wurde der Initiierung die Bewegungsrichtung des
Nutzers angehängt, kann darauf eine Umorientierung der Navigationsinformation erfolgen. Wurden alle
Navigationsinformationen erstellt, werden sie an die Präsentationsmiddleware übergeben.
5.5.6
Präsentationsmiddleware
Die Präsentationsmiddleware hat eine ähnliche Aufgabe wie die Initiierungsmiddleware. Sie verwaltet den
Zugriff der Dienstausführungsschicht auf die Dienstpräsentationsschicht. Dadurch benötigt die Dienstausführungsschicht keinerlei Kenntnis über die Fähigkeiten und Eigenschaften der einzelnen Präsentatoren.
Außerdem muss sie sich nicht um Kommunikationsdetails zu den Präsentatoren kümmern. Diese Aufgaben
übernimmt die Präsentationsmiddleware.
Jeder Präsentator meldet sich zu Beginn bei der Präsentationsmiddleware an. Die Anmeldung muss dabei
Informationen zu unterstützten Medienformaten und Charakteristika dieser Medien beinhalten. Unterstützt
der Präsentator zum Beispiel die Darstellung von Grafiken im PNG-Format, so sollte in den Charakteristika zumindest die Displaygröße enthalten sein. Dadurch kann die Präsentationsmiddleware die von der
Dienstausführungsschicht übergebenen grafischen Navigationsinformationen auf die Displaygröße anpassen. Analoges gilt für andere Darstellungsformen.
Die Präsentationsmiddleware legt alle Informationen zu unterstützten Medienformaten und Charakteristika, sowie Informationen über den Zugriff auf den Präsentator in einer geeigneten Datenstruktur ab.
Wird der Präsentationsmiddleware eine Navigationsinformation übergeben, überprüft sie, ob ein registrierter Präsentator existiert, der die Navigationsinformation darstellen kann. Gegebenenfalls kann hier eine
Transformation der Navigationsinformation zwischen verschiedenen Medienformaten erfolgen. Handelt es
sich um eine grafische Darstellung, erfolgt in jedem Fall eine Anpassung an die Displaygröße des Präsen-
83
5.5. UMSETZUNG DER LBPS-SCHICHTEN
Äquator
Parallele
long2
long1
longδ
P2
long∆
Nullmeridian
P1
Abbildung 5.11: Abstand der Punkte P1 und P2 auf dem Breitenkreis
tators. Gegebenenfalls folgen weitere Anpassungen an Farbtiefe, Farbwahl, etc. Abschließend übergibt die
Präsentationsmiddleware die Navigationsinformation an den entsprechenden Präsentator.
Da die Objektserialisierung keine Serialisierung von derartigen Medien zulässt und so keine Übergabe der
Navigationsinformation an den Präsentator bei Verteiltheit möglich ist, muss an dieser Stelle eine andere Technik eingesetzt werden. MIDP verfügt über die Möglichkeit Medien über Datenströme zu laden.
Dadurch können grafische Medien wie folgt geladen werden:
Image image =
Image.createImage(Connector.openInputStream(mediaAddress))
Für MIDP 2.0 lädt folgender Codebaustein verbale Medien:
Player player = Manager.createPlayer(mediaAddress)
Auf diese Weise ist es möglich, Medien zur Laufzeit auf das mobile Endgerät zu laden. Dieser Vorgang
muss aber vom mobilen Endgerät angestoßen werden. Deshalb wird von der Präsentationsmiddleware das
Medium zum Beispiel auf einem Webserver öffentlich zugänglich hinterlegt und dem Präsentator die URL,
unter der das Medium zugänglich ist, übergeben. Der Präsentator kann daraufhin das Medium laden und
darstellen.
5.5.7
Dienstpräsentation
Die Dienstpräsentation stellt Medien dar, welche ihr von der Dienstausführungsschicht überlassen wurden. Für den MoBiLe-Service wurden zwei Präsentatoren implementiert. Der RasterPresenter ist
zuständig für die Darstellung von Rastergrafiken im PNG-Format. PNG wurde als Format gewählt, da dies
derzeit das einzige für MIDP vorgeschriebene Grafikformat ist und so auf jedem Mobiltelefon mit MIDP
unterstützt wird. Der zweite Präsentator, der SoundPresenter, kann verschiedenste verbale Medien
abspielen. Die unterstützten Medienformate können von Endgerät zu Endgerät unterschiedlich sein.
Für die Dienstpräsentation kommen keine Anwendungen, die standardmäßig auf dem mobilen Endgerät
verfügbar sind, in Frage, da diese kein Pushing unterstützen. Standardanwendungen, wie ein InternetBrowser, der bereits auf den meisten mobilen Endgeräten vorhanden ist, arbeiten meist im RequestResponse-Modus und sind deshalb höchstens unterstützend einsetzbar.
84
KAPITEL 5. IMPLEMENTIERUNG
5.6 Konfigurationskomponente
Abbildung 5.12: Beispiele der Konfigurationsoberfläche
Die Location-based Push-Architektur ist durch die oben beschriebene Implementierung bereits voll funktionsfähig. Zur Steuerung, Kontrolle und Konfiguration, d.h. zur Auswahl von Routen, zur Auswahl von Darstellungsformen, zum Starten und Beenden der Navigation, etc. muss allerdings noch eine weitere Komponente hinzugefügt werden. Diese ermöglicht die Steuerung der Dienstinitiierungs-, der Dienstausführungsund der Dienstpräsentationsschicht (vgl. Abb. 5.13). Da eine Steuerung von Dienstinitiierungs- und Dienstpräsentationsschicht nur lokal auf dem mobilen Endgerät möglich sein soll, kann hierfür auf eine lokale
Steuerschnittstelle des Initiators und der Präsentatoren zugegriffen werden. Der Zugriff auf die Schnittstelle der Dienstausführung erfolgt über das DCF. Dadurch kann eine Steuerung über native Methodenaufrufe oder über eine Socketverbindung erfolgen. Durch die Implementierung weiterer Stubs, die zum Beispiel eine Unterstützung des HTTP-Protokolls ermöglichen, ist hier auch eine Konfiguration durch einen
Internet-Browser möglich. So kann die Route zum Beispiel von zuhause über den Internet-Browser eines
stationären Rechners mit großem Display betrachtet und ausgewählt werden und später durch einfaches
Starten des Dienstes auf dem mobilen Endgerät die Navigation zu dieser Route erfolgen.
Presentation
Configuration
Presentation MW
Application
Initiation MW
Initiation
Abbildung 5.13: Konfigurationskomponente
Präsentatoren des MoBiLe-Service enthalten zwei Steuermethoden, die das Starten und Stoppen des
Präsentators ermöglichen. Der Initiator besitzt ebenfalls diese Steuermethoden, sowie eine Kontrollmethode, die Aufschluss über den aktuellen Zustand des Initiators liefert. Der MoBiLe-Service besitzt auch
die genannten Steuermethoden und zusätzlich eine Menge an Konfigurationsmethoden:
• setPreferences zur Konfiguration von gewünschten Darstellungsformen, etc.
• getRoutes zur Anzeige von Routen mit bestimmten Annotationen (Name, Länge, etc.)
5.6. KONFIGURATIONSKOMPONENTE
85
• getRouteInfo zur Anzeige von detaillierten Routeninformationen zu einer Route
• selectRoute zur Auswahl einer Route
• getSelectedRoute zur Anzeige der gewählten Route
Zur Nutzung der Steuer-, Kontroll- und Konfigurationsschnittstelle wurde im Rahmen dieser Arbeit eine
grafische Oberfläche für MIDP entworfen, die dem Nutzer den Zugriff auf diese Schnittstelle ermöglicht
(vgl. Abb. 5.12). Ein Zustandsdiagramm, das den Ablauf der Steuerung, Kontrolle und Konfiguration zeigt,
ist in Abbildung 5.14 dargestellt.
Abbildung 5.14: Zustandsdiagramm der Konfigurationsoberfläche
Die Abbildung zeigt zusätzlich einige Zustände, die für die Konfiguration des DCF und der BluetoothVerbindung mit dem GPS-Empfänger nötig sind. Zur Konfiguration der Bluetooth-Verbindung wurde eine angepasste Version des von [blu ] bereitgestellten Werkzeugs zum Bluetooth-Device-Discovery und
Bluetooth-Service-Discovery eingesetzt.
Kapitel 6
Evaluierung
Im Rahmen dieser Arbeit wurde der MoBiLe-Service, dessen Implementierung im letzten Kapitel dargestellt wurde, realisiert und getestet. Dabei sind sowohl einige Schwächen in der Implementierung identifiziert worden, als auch Probleme in der zugrunde liegenden Technologie. Aufgedeckte Schwächen wurden,
falls möglich, in einer überarbeiteten Version des MoBiLe-Service behoben. Einige Probleme in genutzten
Technologien wurden in der Implementierung gelöst, bzw. umgangen. Im Rahmen dieser Arbeit konnten
allerdings auch einige dieser Probleme nicht oder nur marginal gelöst werden. Dieses Kapitel befasst sich
mit den aufgedeckten Schwächen der Implementierung und Problemen in zugrunde liegenden Technologien und gibt, soweit möglich, Lösungsvorschläge. Ein realer Einsatz des MoBiLe-Service innerhalb einer
Mountain-Bike-Tour wird am Ende dieses Kapitels evaluiert.
6.1 Evaluierung der Implementierung und Technologie
6.1.1
Probleme von GPS
Wie bereits in Kapitel 5.1 beschrieben, wurde zur Ortung des Nutzers der Fortuna Clip-On Bluetooth
GPS Receiver eingesetzt. Dieser GPS-Empfänger verfügt über zwei Modi, dem Standardmodus (ST) und
dem erweiterten Modus (XT). Für den MoBiLe-Service bietet der XT-Modus den entscheidenden Vorteil,
dass dieser einen Empfang auch in empfangsschwachen Gebieten, wie zum Beispiel im Wald, ermöglicht.
Außerdem liefert der GPS-Empfänger im XT-Modus bei Stillstand nur eine einzige Position zurück. Im
ST-Modus hingegen schwankt die Position in einem Umkreis von ca. 10 Metern um die reale Position. Um
dies zu verwirklichen, wird im XT-Modus der Stillstand erkannt und so die Position auf diesen Wert fixiert.
Leider wird eine Bewegung aus dieser Stillstandsphase erst sehr spät erkannt, so dass ein Übergang vom
Fixwert auf die reale Position erst stark verzögert erfolgt. Diese Tatsache kann die Funktionsfähigkeit des
MoBiLe-Service enorm einschränken.
Desweiteren reagiert der GPS-Empfänger im XT-Modus bei höheren Geschwindigkeiten verzögert auf Positionsveränderungen. Schon bei 10-20 km/h kann diese Verzögerung bemerkt werden und zu Verfälschungen der gemessenen Position führen. Obwohl bei niedrigen oder keinen Geschwindigkeiten der XT-Modus
genauere Positionen mit einer kürzeren Startzeit sogar in empfangsschwachen Gebieten liefert, ist ein Einsatz für den MoBiLe-Service, der auch höhere Geschwindigkeiten unterstützen muss, nicht möglich.
Die Nutzung des GPS-Empfängers im ST-Modus liefert ungenauere Positionsinformationen mit längeren
Startzeiten nur in empfangsstarken Regionen. Allerdings können akzeptable Werte auch bei höheren Geschwindigkeiten erzielt werden. Aus der Nutzung des ST-Modus resultieren aber leider folgende Probleme.
Die Positionsbestimmung im Wald ist teilweise stark eingeschränkt oder gar nicht möglich. Desweiteren
kann kein Stillstand erkannt werden, da der GPS-Empfänger durch die Ungenauigkeit der Positionsbestimmung von einer ständigen Bewegung ausgeht. Aufgrund der schwankenden Positionsinformationen
86
6.1. EVALUIERUNG DER IMPLEMENTIERUNG UND TECHNOLOGIE
87
im Stillstand liefert er deshalb immer eine geringe Geschwindigkeit und eine interpolierte Richtung. Diese
Richtungsinformation stimmt nicht mit der realen Richtung des GPS-Empfängers überein. Der XT-Modus
liefert bei erkanntem Stillstand hingegen keine Richtungsinformation. Somit kann vom MoBiLe-Service
erkannt werden, dass keine Bewegung durchgeführt wird und deshalb keine interpolierte Richtung bestimmbar ist. Daraufhin wird dem Nutzer eine allozentrische Navigationsinformation präsentiert. Im STModus kann dies nicht auf triviale Art und Weise erkannt werden.
Zur Lösung des Problems werden in der Implementierung Richtungsinformationen bei niedrigen Geschwindigkeiten automatisch vernichtet. So werden keine falschen Richtungsinformationen geliefert und
der MoBiLe-Service stellt keine falschen egozentrischen Navigationsinformationen zur Verfügung.
6.1.2
Inhärente Probleme von J2ME
Bereits im vorigen Kapitel wurde auf einige inhärente Probleme der J2ME-Plattform eingegangen. Diese sollen hier nochmals kurz zusammengefasst werden. Ein Problem war die Integration von dynamisch
generierten ECA-Regeln. Da der J2ME-Classloader nur das Laden von Standardklassen und Klassen der
MIDlet-Suite zulässt, können zur Laufzeit keine beliebigen ECA-Regeln geladen werden. Die Klasse der
ECA-Regel muss deshalb zum Installationszeitpunkt bereits in die MIDlet-Suite integriert werden. Lösung
des Problems war die generische ECA-Regel. Diese besitzt eine einzige Zugriffsmethode und alle Informationen des Triggers sind in Instanzvariablen enthalten.
Um die ECA-Regel über Netzwerkverbindungen zu übertragen, muss sie serialisiert werden. Leider unterstützt J2ME standardmäßig keine Objektserialisierung. Lösung war eine selbst entwickelte Objektserialisierung. Hierbei können primitive Datentypen, sowie Objekte, die aus primitiven Datentypen bestehen,
serialisiert werden. Dazu müssen alle Informationen durch primitive Datentypen darstellbar sein. Komplexe Bedingungen werden deshalb mittels Strings serialisiert. Hierdurch ist es nun möglich, ECA-Regeln
dynamisch zu konfigurieren und über Netzverbindungen zu übertragen, um sie für die Dienstinitiierung
einsetzen zu können.
Ein weiteres Problem, welches zwar nicht direkt durch J2ME entsteht, aber innerhalb der Programmierumgebung auftritt, ist das Öffnen lokaler Netzwerkverbindungen. Das Öffnen einer Netzwerkverbindung für paketvermittelte Datendienste wie GPRS ist nur in Verbindung mit Infrastrukturkomponenten
(SGSN/GGSN) möglich. Jedes Paket über diese lokale Netzwerkverbindung wird deshalb nicht lokal auf
dem Endgerät übertragen, sondern über den Umweg der Infrastruktur. Dadurch muss jedes Paket die Luftschnittstelle mit den bereits genannten Nachteilen überqueren. Eine lokale Kommunikation zwischen den
Schichten der Location-based Push-Architektur ist deshalb nicht über Netzwerkverbindungen möglich.
Lösung stellt das Dynamic Connection Framework (vgl. Kapitel 5.4) dar. Je nachdem, ob eine lokale oder
entfernte Kommunikation stattfinden soll, wählt das DCF entweder einen nativen Methodenaufruf oder
einen Methodenaufruf über eine Socketverbindung. Innerhalb der Schichten bleibt die Wahl der Verbindungsart durch Stubs verborgen. Zur Unterstützung weiterer Protokolle kann das DCF einfach erweitert
werden.
6.1.3
Probleme mobiler Endgeräte
Neben den bereits genannten Problemen sind bei der Implementierung auch einige Schwierigkeiten bei der
Nutzung der mobilen Endgeräte aufgetreten. Diese sind auf Spezifikationsabweichungen zurückzuführen.
Für einige Vorabtests kam das Sony Ericsson P900 zum Einsatz. Wie bereits in [Klin 04] festgestellt wurde, sind in einigen Softwareversionen des P900 Statusmeldungen bei der Gerätesuche mittels JABWT vertauscht. Dadurch wird bei erfolgreicher Gerätesuche grundsätzlich ein INQUIRY ERROR geliefert. Eine
ordnungsgemäße Implementierung der Gerätesuche ist deshalb nicht möglich. Eine Lösung des Problems
ist die Nichtbeachtung der Statusmeldungen.
Probleme, die im Zusammenhang mit der Implementierung auf dem Siemens S65 entstanden, waren Fehler bei der Bluetooth-Dienstsuche. Bei Hinzunahme bestimmter Attribute bei der Dienstsuche, liefert das
optionale Paket JABWT des S65 fehlerhafte ServiceRecords. Außerdem werden durch die J2MEPlattform auf dem S65 offene Ein-/Ausgabeströme über Bluetooth beim Beenden des MIDlets nicht auto-
88
KAPITEL 6. EVALUIERUNG
matisch geschlossen. Die Bluetooth-Schnittstelle steht danach, auch für Nicht-J2ME-Anwendungen, nicht
mehr zur Verfügung. Einzige Lösung ist hier der Neustart des Gerätes.
Neben den hier erwähnten Problemen mit Bluetooth in J2ME zeigte das S65 auch allgemeine Fehler in
der Bluetooth-Implementierung. So führte ein Bluetooth-Zugriff mittels OBEX-Browse zwangsläufig zum
Absturz des Systems. Außerdem wurden nur sehr geringe Datenraten über die Bluetooth-Schnittstelle erreicht, die selten 5 Kilobyte/s überschritten. Auch der Wechsel zum Siemens SK65 bot hier keine Lösung.
Erst durch den Einsatz des Nokia 6630 war eine ordnungsgemäße Nutzung der Bluetooth-Schnittstelle
möglich. Alle Zugriffe erfolgten so, wie sie in der Spezifikation festgehalten sind. Außerdem können mit
dem Nokia 6630 Datenraten bis zu 40 Kilobyte/s erreicht werden, was die Arbeit mit dem mobilen Endgerät sehr verbesserte.
6.1.4
Probleme beim Routeneinstieg
Erste Tests des MoBiLe-Service zeigten zwar die generelle Funktionsfähigkeit des Dienstes, lieferten aber
noch einige Kritikpunkte. So war es schwer, einen Routeneinstieg zu finden. Um an den Startpunkt der
Route zu gelangen, musste man die Umgebung nach dem ersten Aktionskreis absuchen, solange bis die
erste Navigationsinformation präsentiert wird.
Diese Problematik wurde durch das Einfügen eines weiteren Triggers gelöst. Dieser bietet beim Start des
Dienstes automatisch Hilfestellung zum Erreichen des Startpunktes der Route. Die Bedingung dieser ECARegel ist stets true. Dadurch wird die Aktion bei der ersten Auswertung ausgeführt. Als Aktion wurde
die InitiatePiggyBackingDataAction gewählt, an die die Position des Nutzers angehängt wird.
Dadurch erlangt die Navigationsapplikation die aktuelle Position des Nutzers und kann die Richtung bestimmen, in der der erste Aktionspunkt der Route zu finden ist. Die Berechnung der Richtung erfolgt durch
arctan( xy ), wobei x bzw. y die Differenz der aktuellen Position und des ersten Aktionspunktes bezüglich
der x-Achse bzw. y-Achse ist. Leider kann dieser Ausdruck unter J2ME nicht einfach ausgewertet werden,
da J2ME keine Arcusfunktionen unterstützt.
Lösung des Problems war eine Berechnung des Arcus-Tangens durch eine Taylorreihenapproximation.
Folgende Taylorreihe liefert im Intervall x ∈ [0; 1] eine Annäherung an den Arcus-Tangens:
arctan(x) =
∞
X
i=0
(−1)i
x2i+1
2i + 1
1
) angenähert werden. Da der ArcusFür das Intervall ]1; ∞[ kann der Arcus-Tangens durch π2 − arctan( |x|
Tangens punktsymmetrisch zum Ursprung ist, ergeben sich Werte für das Intervall ] − ∞; 0[ durch Punktspiegelung.
In der Implementierung des MoBiLe-Service wird für die Bestimmung des Arcus-Tangens folgende Methode benutzt:
2
4
6
8
10
12
public double arctan(double d)
{
if (d<0) return (-1)*arctan(d*(-1));
else
if (d>1) return Math.PI/2 - arctan(1/Math.abs(d));
else
{
double result = 0;
for (int i=0; i<loops; i++)
result += pow(-1,i)*pow(d,2*i+1)/(2*i+1);
return result;
}
}
Die Variable loops gibt an, wie viele Reihenglieder für die Approximation genutzt werden. Ein ausreichendes Ergebnis wird bereits mit fünf Reihengliedern erzielt. Da J2ME auch keine Potenzfunktion (ab )
standardmäßig zur Verfügung stellt, wurde eine triviale Potenzfunktion pow(a, b) selbst implementiert.
6.1. EVALUIERUNG DER IMPLEMENTIERUNG UND TECHNOLOGIE
89
Durch das Einfügen dieses Triggers kann der Nutzer den Routenstartpunkt wesentlich einfacher finden.
Desweiteren hilft eine Vergrößerung des Aktionskreisradius für den Startpunkt bei der Suche.
6.1.5
Probleme mit Connectivity
Ein weiteres Problem, das bereits in vorigen Kapiteln vermehrt angesprochen wurde, ist die Connectivity
zwischen mobilem Endgerät und der Infrastruktur. Kann aus einem beliebigen Grund die Verbindung zur
Infrastruktur bei Verteiltheit nicht mehr genutzt werden, kann keine Dienstinitiierung und folglich keine
Präsentation von Navigationsinformationen mehr erfolgen.
Zur Lösung des Problems kann dem Präsentator eine Default-Navigationsinformation vorab übergeben
werden, die bei nicht ausreichender Connectivity automatisch dargestellt wird. Für einen Präsentator für
grafische Darstellungsformen kann dies zum Beispiel eine Karte sein, die die komplette Route enthält.
Dadurch kann der Nutzer selbst eine Navigation durchführen. Dies ist zwar für ihn wesentlich aufwändiger,
aber immerhin noch möglich. Ohne diese Lösung könnte gar keine Navigationshilfe mehr bereitgestellt
werden.
6.1.6
Probleme beim Verlassen der Route
Die Routen des MoBiLe-Service beziehen sich einzig und allein auf Aktionspunkte. Informationen zu
Pfaden, die zwischen diesen Aktionspunkten verlaufen, wurden bisher völlig außer Acht gelassen. Für eine
funktionsfähige Navigation sind diese auch nicht notwendig. Dazu muss sich der Nutzer aber stets auf
den Pfaden zwischen den Aktionspunkten bewegen. Verlässt er aus irgendeinem Grund die Route, wird
keine Dienstinitiierung mehr durchgeführt und deshalb auch keine Navigationsinformation bereitgestellt.
Zur Lösung dieser Problematik existieren folgende Ansätze:
• Merkt der Nutzer selbst, dass er sich von der Route entfernt hat, so kann er mittels Pull-Verfahren
selbst Navigationsinformationen anfordern, die ihn auf seinem Weg zurück zur Route unterstützen.
• Innerhalb der Route können neben Informationen zu Aktionspunkten auch Informationen zu den Pfaden zwischen den Aktionspunkten vermerkt werden. Diese können zum Beispiel in Form einzelner
Streckenabschnitte (bei geraden Pfaden) oder in Form von Bezier-Kurven (bei gebogenen Pfaden)
aus vorhanden Pfadinformationen generiert werden. Durch zusätzliche Trigger können diese Pfadbeschreibungen in die Dienstinitiierungsschicht integriert werden. Entfernt sich der Nutzer daraufhin
um eine bestimmte Distanz von diesen Pfadbeschreibungen, wird der Dienst initiiert und eine Navigationsinformation bereitgestellt, die ihm den Weg zurück zur Route beschreibt. Dazu muss an
die Dienstinitiierung die Position des Nutzers angehängt werden. Schwierigkeiten in der Umsetzung
dieses Ansatzes entstehen, falls keine ausreichenden Pfadinformationen zur Verfügung stehen.
• Ein anderer Lösungsansatz ist daher die manuelle Korridorgenerierung bei der Routenerzeugung.
Möglich wäre hier zum Beispiel, dass der Nutzer bei der Erzeugung der Route Korridore definieren
kann, die nicht verlassen werden dürfen. Daraufhin ergibt sich ein ähnlicher Verlauf wie bereits bei
vorigem Punkt beschrieben wurde.
• Ein weiteres Konzept, das nicht auf die zweidimensionalen Pfade zurückgreift, ist die Definition von
Kontrollpunkten. Hierzu muss zum Beispiel bei der Routengenerierung alle 100 Meter ein Kontrollpunkt gesetzt werden. Überschreitet die Entfernung zu diesen Kontrollpunkten einen bestimmten
Schwellwert, wird eine Dienstinitiierung ausgelöst und der Nutzer auf die Route zurücknavigiert.
Die Definition der Kontrollpunkte kann bei der Routenerstellung erfolgen. Bei der grafischen Routenerstellung kann diese dadurch umgesetzt werden, dass der Nutzer zum Beispiel alle 100 Meter
einen Punkt (Aktionspunkt oder Kontrollpunkt) setzen muss.
Zur Lösung des Problems existieren eine Vielzahl an Ansätzen, die je nach Art des Dienstes und verfügbaren Informationen eingesetzt werden können.
90
KAPITEL 6. EVALUIERUNG
6.2 Versuchsergebnisse
Um den MoBiLe-Service auf Funktionsfähigkeit zu testen, wurde der Dienst einem realen Anwendungsszenario ausgesetzt. Dazu wurde eine Route mittels des im Anhang A dargestellten Routendienstes erstellt
und daraufhin die Navigation an dieser realen Route getestet. Die erstellte Route verläuft zwischen Fendtund Taubenberg im Süden Münchens (vgl. Abb. 6.1). Die Länge der Route beträgt 20,5 Kilometer und
verläuft über ca. 500 Höhenmeter. Bei einer Durchschnittsgeschwindigkeit von 15 km/h kann die Route
innerhalb von knapp 1,5 Stunden zurückgelegt werden.
Abbildung 6.1: Mountain-Bike-Tour am Taubenberg
Zu Beginn wurde die Route mit dem im Anhang beschriebenen Routendienst definiert. Insgesamt wurden
für die Routenbeschreibung 17 Aktionspunkte herangezogen. Die Definition erfolgte durch Anklicken auf
dem Kartenhintergrund und anschließendes Bestimmen der Austrittsrichtung. Durch die Veröffentlichung
stand sie für den MoBiLe-Service zur Verfügung. Als Startpunkt diente die Kirche von Mitterdarching.
Aufgrund des bereits zuvor durchgeführten Bluetooth-Discovery, konnte dieser Konfigurationsschritt des
LBPSs übersprungen werden. Für den Test wurde sowohl die lokale als auch die verteilte Variante des
Dienstes in zwei unterschiedlichen Durchgängen eingesetzt.
Der erste Durchgang erfolgte mit lokaler Dienstausführung, d.h. ohne Outsourcing der Dienstausführungsschicht. Nachdem dies in der allgemeinen LBPS-Konfiguration eingestellt wurde, konnte der MoBiLe-
6.2. VERSUCHSERGEBNISSE
91
Service gestartet werden. Anschließend wurde die zuvor definierte Route ausgewählt. Das Starten der Navigation führte nach einer Wartezeit von wenigen Sekunden zur ersten Navigationsinformation. Sie enthielt
einen Pfeil, der in die Richtung des Startpunktes zeigte. Der Einstieg in die Route durch oben beschriebenen Ansatz stellte sich als sehr nützlich und zielführend heraus.
Angekommen am Startpunkt der Route, erfolgte die Präsentation einer weiteren Navigationsinformation,
die aus einem Pfeil und einer verbalen Richtungsinformation bestand. Diese zeigte, wie erwartet, in die
Richtung der weiterführenden Route. Der darauf folgende Streckenabschnitt verlief teilweise im dichten
Wald. Obwohl hier Einschränkungen in der Ortung erwartet wurden, lieferte der GPS-Empfänger kontinuierlich relativ genaue Ortsinformationen. Demzufolge kam die Initiierung des Dienstes und die Präsentation der Navigationsinformation stets rechtzeitig zustande und zeigte die gewünschten Resultate. Die
Pfeildarstellung konnte gut wahrgenommen werden und zeigte meist in die richtige Richtung. An einigen
wenigen Aktionspunkten stimmte der Pfeil nicht genau mit der einzuschlagenden Richtung überein, ließ
die weiterführende Route aber trotzdem intuitiv erahnen. Auch die Geschwindigkeitsabhängigkeit für die
frühzeitige Dienstinitiierung zum Beispiel bei Bergabfahrten meisterte der MoBiLe-Service mit großem
Erfolg. So erschien eine Navigationsinformation bereits ca. 100 Meter vor dem Abbiegevorgang bei einer
Geschwindigkeit von ca. 40 km/h. Dadurch konnte frühzeitig der Bremsvorgang eingeleitet werden.
Die verbale Darstellung der Navigationsinformation unterstützte die Pfeildarstellung sehr zum Vorteil des
Nutzers. Dadurch war eine Navigation auch ohne ständiges Betrachten des Displays möglich. Leider ist die
Lautstärke des integrierten Lautsprechers des Nokia 6630 für diese Anwendung etwas leise, so dass Anweisungen meist nur partiell verstanden wurden. Durch den Blick auf die Pfeildarstellung konnten diese
Probleme aber behoben werden. Nach einer 1,5 stündigen Fahrt wurde schließlich wieder der Startpunkt
erreicht.
Ein weiterer Durchgang erfolgte mit der verteilten Alternative des MoBiLe-Service. Nachdem in der Konfiguration der Location-based Push-Architektur die IP-Adresse des Application Servers eingetragen wurde,
konnte der eigentliche MoBiLe-Service gestartet werden. Die Verbindung mit dem Application Server wurde daraufhin aufgebaut und eine Routenwahl konnte erfolgen. Die einzelnen Schritte der Routenwahl zeigten zwar merkliche Verzögerungen, die durch den Datenaustausch über die Luftschnittstelle resultierten,
konnten aber wie bei der lokalen Variante durchgeführt werden. Nachdem die Navigation gestartet wurde,
zeigte die Pfeildarstellung relativ zeitnah die Position des Startpunktes an. Die Navigation durch die Route
erfolgte ähnlich zur lokalen Variante. Teilweise konnte der Datenaustausch über die Luftschnittstelle durch
eine verzögerte Bereitstellung der Navigationsinformationen bemerkt werden. Eine rechtzeitige Benachrichtigung über Richtungsänderungen wurde aber trotzdem erzielt. Auch komplexe Aktionspunkte, die zum
Beispiel unter hohen Geschwindigkeiten erreicht werden, führten zu einer rechtzeitigen Benachrichtigung.
Leider war der Empfang zu örtlichen Basisstationen des Mobilfunknetzes an einer Stelle der Route so gering, dass ein Verbindungsabbruch erfolgte. Dadurch war keine ausreichende Connectivity mehr gegeben.
Eine Dienstinitiierung und folglich auch eine Bereitstellung von Navigationsinformationen war deshalb
nicht mehr möglich. Leider konnte dieser Verbindungsabbruch innerhalb des MIDlets nicht festgestellt und
deshalb keine geeignete Fehlerbehandlung eingeleitet werden. Eine Benachrichtigung des Nutzers konnte
so nicht erfolgen und eine Navigation schlug fehl. Einzigster Hinweis auf den Verbindungsabbruch war ein
Symbol am Displayrand, das Symbian OS dafür vorsieht.
Durch eine manuelle“ Wegfindung wurde kurze Zeit später wieder ein Gebiet erreicht, das den Empfang
”
möglich machte. Die Verbindung zum Application Server wurde daraufhin durch das Betriebssystem automatisch wieder aufgebaut und die Navigation konnte fortgeführt werden. Die Navigation über die restliche
Route verlief wie gewünscht.
Als Resultat dieses Versuchs ergibt sich also folgende Aussage. Die lokale Ausführung zeigte das
gewünschte Verhalten wie es in den Anforderungen spezifiziert wurde. Die Navigation war klar und intuitiv verständlich. Bis auf wenige leichte Abweichungen zeigte die Pfeildarstellung eine korrekte Richtung
an und wurde durch die verbale Darstellung sinnvoll unterstützt. Navigationsinformationen wurden stets
rechtzeitig präsentiert. Insgesamt war eine äußerst zufrieden stellende Navigation möglich, die dem Nutzer
dadurch einen hohen Mehrwert bot.
Für die verteilte Variante wurde leider festgestellt, dass die Connectivity für eine ordnungsgemäße Nutzung
nicht überall vorherrscht und deshalb nicht wie gefordert eingesetzt werden kann. Die lokale Variante ist
deshalb für derartige Navigationsdienste derzeit noch vorzuziehen. Wird in Zukunft jedoch der Empfang
des Mobilfunknetzes weiter ausgebaut, so stellt die verteilte Variante eine interessante Alternative dar. Die
92
KAPITEL 6. EVALUIERUNG
Versuchsergebnisse haben gezeigt, dass die Verzögerung, die durch die Übertragung über die Luftschnittstelle entsteht, für Navigationsdienste beinahe vernachlässigt werden kann. Auch die monetären Kosten, die
durch die Übertragung entstanden, hielten sich durch die geringe Menge an ausgetauschten Daten während
der Navigation sehr niedrig. Zukünftige Versuche werden daher zeigen, ob auch die verteilte Variante für
die Mountain-Bike-Navigation eingesetzt werden kann.
Kapitel 7
Schlussfolgerung und Ausblick
Zusammenfassend kann gesagt werden, dass der MoBiLe-Service die in Kapitel 2.3 erarbeiteten Anforderungen weitgehend erfüllt, und dass eine Architektur entworfen wurde, die derartige Dienste in komfortabler und effizienter Weise umsetzt. Natürlich können einige Aspekte identifiziert werden, die in diesem
Zusammenhang äußerst wichtig sind, aber aufgrund des zeitlichen Hintergrundes nicht behandelt werden
konnten. Dazu gehören vor allem sicherheitskritische Betrachtungen, da durch das eingesetzte TriggerKonzept Ortsinformationen des Nutzers freigegeben werden. Derartige Daten müssen jedoch mit äußerster
Vorsicht behandelt werden, damit kein Missbrauch erfolgen kann. Sie sollten deshalb besonders geschützt
werden. Lösungen sind an dieser Stelle zum Beispiel, dass nur autorisierten Applikationen die Integration der Trigger ermöglicht wird und der Nutzer über vorhandene Trigger genauestens informiert wird.
Desweiteren muss natürlich auch die Übertragung der Ortsinformationen gegen Abhören und Verfälschen
gesichert werden. Dazu stehen verschlüsselte Übertragungen (z.B. HTTPS), Verfahren zur Wahrung der
Integrität (z.B. Prüfsummen) und Anonymisierung zur Verfügung.
Ein weiterer Aspekt, auf den hier nicht genauer eingegangen wurde, ist der Einsatz der Mobilfunktechnologie. Die Konzeption der Architektur und vor allem die Verteilung der LBPS-Schichten auf Entitäten wurde
bisher nur reduziert auf zwei Entitäten betrachtet. Diese sind das mobile Endgerät und die Infrastruktur.
Jedoch besteht die Mobilkommunikationsinfrastruktur nicht aus einem einzigen Gerät, sondern aus einer
Vielzahl an Entitäten. Je nach Mobilfunkgeneration (z.B. GSM oder UMTS) und der Version (z.B. UMTS
Release 99) stehen verschiedene Entitäten zur Verfügung, die für die einzelnen LBPS-Schichten von Interesse sind. Beispiel hierfür ist das Gateway Mobile Location Center (GMLC) [3gp a], welches dafür
vorgesehen ist, Ortsinformationen für LBSs bereitzustellen. Mittels des GMLC soll eine Abstraktion über
verschiedenste Ortungsverfahren erfolgen und so eine einfache Verwirklichung von LBSs ermöglicht werden.
Eine weitere interessante Technologie ist das IP Multimedia Subsystem (IMS) [3gp b], das in Release 5
im UMTS-Infrastrukturnetz eingesetzt werden soll. IMS soll die Unterstützung von Sprachtelefonie sowie
Multimediadiensten in UMTS verbessern. Dazu positioniert sich IMS im paketvermittelten UMTS-Netz,
bildet darin aber ein klar abgegrenztes Subnetz. Zentrales Element des IMS ist das Call Session Control
Function (CSCF) (vgl. Abb. 7.1). Es kontrolliert und steuert IMS Sessions und steht deshalb in Interaktion mit vielen anderen Komponenten des UMTS-Netzes. Beispiel hierfür sind Application Server, auf
denen eigene Dienste oder Dienste von Drittanbietern zur Verfügung gestellt werden. Für den Austausch
von Nutzdaten zum und vom Public Switched Telephone Network (PSTN) hat es Einfluss auf den Media
Gateway (MGW). Zur Kommunikation mit dem mobilen Endgerät stehen Gateway GPRS Support Node
(GGSN) und Serving GPRS Support Node (SGSN) bereit. Innerhalb des UMTS-Netzes erfolgt eine strikte
Trennung zwischen Signalisierungsverkehr und Nutzdatenverkehr. Als Signalisierungsprotokoll wird SIP
(vgl. Kapitel 3.3) eingesetzt. Dabei fungiert das CSCF als SIP-Proxy.
Soll die Location-based Push-Architektur auf das UMTS-Netzes angewendet werden, so können bei der
Verteilung der einzelnen LBPS-Schichten die oben beschriebenen Entitäten des UMTS-Netz in Betracht
gezogen werden. Auch der Signalisierungsverkehr mittels SIP stellt eine interessante Alternative zu der
93
94
KAPITEL 7. SCHLUSSFOLGERUNG UND AUSBLICK
Application
Server
CSCF
SGSN
MGW
GGSN
externe
Netze
(Internet,
PSTN,...)
Nutzdaten
Signalisierungsdaten
Abbildung 7.1: Stark vereinfachter Aufbau des UMTS-Netzes (Release 5)
proprietären Kommunikation in der derzeitigen Location-based Push-Architektur dar und könnte in Zukunft deshalb darauf angepasst werden (vgl. hierzu auch [PSM 01, Tosi 03]).
All diese Betrachtungen bezüglich der derzeitigen bzw. zukünftigen Mobilfunktechnologie wurden in dieser Arbeit außer Acht gelassen, da sie vor allem in der heutigen Zeit einem stetigen Wandel unterliegen.
So ändern sich die Zusammensetzung und die Art der Kommunikation der Entitäten der Infrastruktur sehr
häufig und extrem schnell. Die grundsätzliche Funktionalität der einzelnen LBPS-Schichten und die Zweiteilung von mobilem Endgerät und Infrastruktur sind jedoch auch auf längere Zeit gültig. Dadurch zeigen
die Ergebnisse dieser Arbeit nicht nur einen kurzfristigen Charakter, sondern sind auch langfristig anwendbar.
Ein weiterer Punkt, der in dieser Arbeit nicht in Betracht gezogen wurde, sind 3D-Aspekte. Dies betrifft
einerseits die Positionierung und andererseits die Darstellung. Die Positionsbestimmung fand nur auf der
zweidimensionalen Erdoberfläche statt. Vor allem in der Zukunft werden 3D-Positionen jedoch sicherlich
eine entscheidende Rolle spielen. Ob dreidimensionale Betrachtungen der Nutzerposition beim MoBiLeService einen hohen Mehrwert bieten, muss noch im Einzelnen betrachtet werden und wird in dieser Arbeit
nicht weiter behandelt.
Obwohl 3D-Darstellungen in Navigationsdiensten vermehrt zum Einsatz kommen, wurde diesem Aspekt
hier nur wenig Beachtung geschenkt. 3D-Darstellungen bieten eine Vielzahl neuer Möglichkeiten, wie
3D-Walkthroughs [KLEC 03] entlang der Route, und neuartige Hilfestellungen für den Nutzer. Für den
MoBiLe-Service zeigten sich diese aber eher als störend, da die visuelle Aufnahmezeit der komplexen
dreidimensionalen Objekte teilweise stark ansteigt und diese deshalb für das Mountain-Biken weniger gut
geeignet sind.
Die Versuchsergebnisse aus Kapitel 6.2 haben gezeigt, dass die Anforderungen an den MoBiLe-Service
mit dem derzeitigen Prototyp weitgehend erfüllt wurden. Dabei ist zu bemerken, dass ein großer Teil
des Dienstes bereits durch die Location-based Push-Architektur abgedeckt wurde. Die Erweiterungen, um
letztendlich den MoBiLe-Service anzubieten, waren relativ gering und konnten in kurzer Zeit erfolgen.
Durch die Verallgemeinerung vieler eingesetzter Konzepte, wie den dynamisch konfigurierbaren Triggern
in Form von ECA-Regeln, können die Anforderungen einer Vielzahl von LBPSs abgedeckt werden. Der
Aufwand für die Implementierung verhält sich dadurch äußerst gering. Um zum Beispiel den ortsabhängigen Email-Push-Service anzubieten, der bereits vielfach erwähnt wurde, muss im Grunde genommen nur
eine Komponente zum Erzeugen der ECA-Regeln und eine Komponente für das Anfordern und Übergeben der Emails implementiert werden. Zusätzlich muss die Konfigurationskomponente angepasst werden,
wobei diese bereits auf eine einfache Erweiterung ausgelegt wurde und so Standardfunktionen wie das
Bluetooth-Discovery und die Wahl des Dienstes unangetastet bleiben können. Dadurch ist es möglich, in
kürzester Zeit verschiedene LBPSs anbieten zu können.
Stehen weitere Sensorinformationen zur Verfügung, kann die Location-based Push-Architektur außerdem
leicht um Dienstinitiierungen basierend auf diesen Sensorinformationen erweitert werden. Dazu muss
ein weiterer Initiator implementiert werden, der diese Sensorinformationen generiert, anfordert, verwal-
95
tet, Trigger aktualisiert und Aktionen ausführt. Stehen zum Beispiel Wetterinformationen zur Verfügung,
kann der MoBiLe-Service um wetterbasierte Trigger erweitert werden. Ein entsprechender Initiator kann
so den MoBiLe-Service anstoßen, falls die Regenwahrscheinlichkeit innerhalb des Routengebietes einen
Schwellwert übersteigt. Daraufhin kann der MoBiLe-Service dem Nutzer beispielsweise eine kürzere Alternativroute anbieten. Andere Beispiele für Trigger, die im Zusammenhang mit dem MoBiLe-Service
interessante Einflüsse haben, sind Trigger, die bei zeitnahem Sonnenuntergang den Dienst anstoßen, oder
bei steigender Ozonbelastung den Nutzer frühzeitig warnen. All diese Trigger können ohne komplizierte
Veränderungen der Architektur eingesetzt werden und interessante neue oder erweiterte Dienste anbieten.
In Zusammenhang mit dem wachsenden Angebot an mobilen Diensten werden derartige LBPSs in Zukunft
möglicherweise interessante Geschäftsprozesse abbilden. Vielleicht tragen sie zum Erreichen der lang ersehnten Killer Applikation“ der heutigen Zeit bei, die voraussichtlich nicht aus einer einzigen Anwendung
”
bestehen wird, sondern aus einer Vielzahl an Diensten, die den Nutzer bei seinen alltäglichen Aufgaben
hilfreich unterstützen.
96
KAPITEL 7. SCHLUSSFOLGERUNG UND AUSBLICK
Anhang A
Routendienst
Die wesentliche Grundlage der Wegfindung sind Routen. Definitionen zu Routen finden sich in Kapitel 2.2.
Zur Erzeugung, Verwaltung und Bereitstellung von Routen dienen Routendienste. In Kapitel 2.2 wurden
zwei wesentliche Arten von Routendiensten identifiziert. Diese liefern entweder statisch oder dynamisch
generierte Routen. Während dynamische Routen bei jeder Anfrage neu erzeugt werden, stehen statische
Routen meist für längere Zeit zur Verfügung und entsprechen den Bedürfnissen einer breiten Nutzergruppe.
Der hier beschriebene Routendienst soll Routen für den MoBiLe-Service liefern. Diese sollen sowohl für
den lokalen als auch für den verteilten MoBiLe-Service nutzbar sein. Dabei wird in dieser Arbeit nur ein
Routendienst, der auf einer Entität der Infrastruktur bereit steht, eingesetzt. Dies entspricht einer OffboardLösung. Dadurch kann der Routendienst auf einfache Art und Weise von verschiedenen Navigationsdiensten eingesetzt werden und große Mengen an Daten zur Routenerstellung hinzuziehen.
In der Regel sind Routen für das Mountain-Biken nicht wie bei der Fahrzeugnavigation dazu gedacht, über
eine beliebige Pfadfolge von Ort A nach Ort B zu gelangen. Die Routen zeichnen sich meist durch speziell
gewählte Pfadfolgen aus. Diese werden in der Regel von wenigen oder keinen motorisierten Fahrzeugen
benutzt, sind aber mit dem Mountain-Bike befahrbar. In manchen Fällen können aber auch nicht-befahrbare
Tragestrecken vorkommen. Außerdem haben sie meist eine mehr oder weniger starke Steigung (bis max. ∼
30 Prozent). Eine weitere Besonderheit ist, dass bis auf seltene Ausnahmen der Zielpunkt dem Startpunkt
entspricht. Die Route definiert also eine geschlossene Pfadfolge.
Die hier behandelten Routen werden deshalb nicht dynamisch bei jeder Anfrage generiert, sondern einmal
erzeugt und stehen dann für längere Zeit zur Verfügung. Eine Route kann damit vielfach genutzt werden.
Neben der Bereitstellung und Verwaltung der Routen soll der hier beschriebene Routendienst eine Erstellung von statischen Routen auf Basis einer grafischen Benutzerschnittstelle ermöglichen. Dazu muss der
Routendienst über digitale geografische Datenbestände verfügen. Das folgende Kapitel gibt einen Überblick über diese Kartenbestände verschiedener Hersteller. Im Anschluss wird die Architektur des Routendienstes beschrieben und eine kurze Einführung in die Implementierung gegeben. Abschließend folgt
eine Evaluierung der Resultate aus dem realen Einsatz des Routendienstes in Zusammenarbeit mit dem
MoBiLe-Service.
A.1
Digitale geografische Datenbestände
NAVTEQ NAVTEQ [nav ] ist neben Tele Atlas einer der führenden Anbieter digitaler Pfadinformationen für Deutschland. Seit 1993 bemüht sich das Unternehmen, alle Pfade innerhalb Deutschlands einerseits
durch Luftbildaufnahmen und andererseits durch reales Abfahren der Pfade zu erfassen (vgl. [GKW 04]).
Seit dem Jahr 2000 sind alle deutschen Straßen vollständig in den Daten enthalten. Derzeit wird der Bestand durch die Erfassung von Wegen erweitert. Zum Zeitpunkt dieser Arbeit beinhalten die NAVTEQ
Daten Pfade mit einer Gesamtlänge von etwas mehr als einer Million Kilometern.
97
98
ANHANG A. ROUTENDIENST
Neben den Positionen zum WGS84-Datum enthalten einzelne Pfadsegmente bis zu 160 Attribute (z.B. Namen, Hausnummern, Vorfahrtsregelungen, Abbiegeeinschränkungen, Geschwindigkeitsbeschränkungen).
Außerdem gibt mehr als 200.000 PoIs aus 44 Kategorien (z.B. Restaurants, Krankenhäuser, Tankstellen).
Die Summe aller Informationen ergibt so mehrere Gigabyte Daten, die von NAVTEQ kommerziell vertrieben werden. Aktualisierungen des Datenbestandes erfolgen in der Regel halbjährlich. Die Daten sind für 17
Länder in sieben Formaten erhältlich. Neben Westeuropa werden Pfadinformationen auch zu Nordamerika
und Regionen des Mittleren Ostens angeboten. Unterstützte Formate sind Shape, MapInfo Tab-File, Oracle
Spatial, SIF+, GDF 3.0, SDAL und RTM.
Tele Atlas Das Unternehmen Tele Atlas [tel ] bietet digitale Pfadinformationen für insgesamt 22 Länder
an. Darunter sind viele westeuropäische Länder, die USA sowie Kanada. Die Daten sind in den Formaten
GDF 3.0, Shape, Oracle Spatial, RMF, MapInfo Tab-File, ArcSDE SDX-File und ArcIMS Route Server
SDC-File erhältlich.
Hauptsächlich wurden die Tele Atlas Daten durch reales Abfahren der Pfade erzeugt. Aber auch Luftbildaufnahmen, Satellitenbilder und andere geografische Primär- und Sekundärdaten werden zur Datenerfassung eingesetzt. Durch die sehr fassettenreiche Datenerhebung garantiert Tele Atlas eine Genauigkeit der
Daten von 5-12 Metern. Eine Aktualisierung der Daten erfolgt halbjährlich.
Wie bei NAVTEQ können Pfadsegmente durch 150 Attribute (z.B. Namen, Hausnummern, Vorfahrtsregelungen) erweitert werden. Neben Pfadinformationen enthalten die Daten PoIs und Informationen zu
Flüssen und Seen, politischen Grenzen, Postleitzahlenbereiche, etc. Neben diesen Pfadinformationen liefert Tele Atlas dynamische Daten wie Verkehrsinformationen, Unfälle oder Baustellen.
PTV Ein weiterer wichtiger Lieferant von Pfadinformationen ist PTV [ptv ]. PTV zeichnet sich nicht
durch große Mengen eigener Pfadinformationen aus, sondern stellt verschiedenste Produkte, die sich in
irgend einer Art und Weise mit Mobilität beschäftigen, zur Verfügung. In diesem Sinne werden von PTV
Lösungen für modulare Technologieplattformen, Routing- und Mapping-Dienste und auch konkrete Dienste wie zum Beispiel ein Offboard-Navigationsdienst und eine Online-Mitfahrzentrale bereitgestellt. Dabei
liefert PTV nicht nur die Produkte, sondern auch Beratung, Hosting und Support dieser Produkte. Gleichzeitig vertreibt PTV aber auch digitale Inhalte. Diese beinhalten Verkehrsinformationen, Wetterinformationen, PoIs und digitale Pfadinformationen. Die digitalen Pfadinformationen bestehen aus Daten von NAVTEQ, Tele Atlas und AND [and ], sowie eigenen Datenbeständen. Der Gesamtdatenbestand umfasst alle
Länder Europas mit über 500.000 Orten und Pfadsegmente mit einer Gesamtlänge von ca. sechs Millionen
Kilometern.
ATKIS Neben den oben genannten Lieferanten digitaler Pfadinformationen werden digitale geografische Daten auch von Vermessungsämtern angeboten. Das Projekt ATKIS (Amtliches TopographischKartographisches Informationssystem) [atk ] der Arbeitsgemeinschaft der Vermessungsverwaltungen
(AdV) beschäftigt sich mit der Erfassung dieser Daten. Ziel von ATKIS ist die Erstellung einer digitalen Informationsbasis für topografische Geodaten der Bundesrepublik Deutschland. Die Umsetzung wurde
von der AdV an die Vermessungsämter der Länder übergeben, die per Gesetz dazu verpflichtet sind, das
Landesgebiet digital zu erfassen. Jedes Land erstellt deshalb ein zweidimensionales, vektorbasiertes, objektstrukturiertes und vom Nutzer erweiterbares Digitales Landschaftsmodell (DLM). Die im Basis-DLM
”
enthaltenen Objekte werden bestimmten Objektarten zugeordnet und durch ihre räumliche Lage, ihren geometrischen Typ (Punkt, Linie, Fläche), beschreibende Attribute (z. B. Straßenname, Fahrbahnbreite) und
Beziehungen zu anderen Objekten (Relationen) definiert“ [blv ]. Die Genauigkeit des Basis-DLM soll 510 Meter betragen. Aktualisierungen erfolgen mindestens alle drei Jahre. ATKIS sieht Anwendungsgebiete
der digitalen Karten unter anderem in den Bereichen Energie-, Forst- und Landwirtschaft, Landnutzungs-,
Regional- und Streckenplanung, Verkehrsnavigation, Transport sowie in der allgemeinen Freizeitgestaltung.
Das Bayrische Landesvermessungsamt liefert derzeit den ATKIS-Datenbestand in drei verschiedenen Formaten. Diese sind EDBS, DXF und Shape.
A.2. ARCHITEKTUR
A.2
99
Architektur
Bei dem in dieser Arbeit erstellten Routendienst steht die Erstellung von Routen mittels einer grafischen
Benutzeroberfläche im Vordergrund. Diese soll es möglich machen, auf einfache Art und Weise statische
Routen zu erzeugen. Die dazu einsetzbaren geografischen Datenbestände wurden bereits angesprochen.
Um diese in eine grafische Form für die Benutzeroberfläche zu überführen und darauf basierend die Erstellung der Route zu ermöglichen, soll dieses Kapitel eine Architektur entwerfen, mit deren Hilfe dies
umgesetzt werden kann. Der Großteil der Architektur wird dabei von dem Projekt OpenMap [ope b] bereitgestellt. OpenMap ist aus einem Forschungsprojekt in Zusammenarbeit mit der Defense Advanced Research Projects Agency (DARPA) des DoD entstanden. OpenMap wird heute von vielen staatlichen sowie
nicht-staatlichen Institutionen genutzt. Für diese Arbeit hat sich die Version 4.6.2 von OpenMap als äußerst
brauchbare Lösung für die Routenerstellung herausgestellt.
A.2.1
OpenMap
OpenMap ist in J2SE implementiert und Open-Source. Es besteht zum größten Teil aus Java Beans. Die
wesentlichen Java Beans sind der MapHandler, die MapBean und das Layer. Der MapHandler ist
die zentrale Komponente des Systems. Er ist das Verbindungsglied zu allen anderen Beans und ermöglicht
so die Interaktion zwischen allen Komponenten. Eine der entscheidenden Interaktionen findet zwischen der
MapBean und den Layers statt. Die MapBean ist für die grafische Anzeige der Karten verantwortlich.
Sie besitzt einige Operationen, um die Darstellung zu verändern. Zu diesen Operationen gehören Vergrößerung, Verkleinerung, Verschiebung, Aus-/Einblenden von Informationen, etc. Durch die MapBean
können Layers dargestellt werden. Sollen mehrere Layers dargestellt werden, veranlasst die MapBean
die Zeichnung der Layers in der spezifizierten Reihenfolge. So erhält man einen geschichteten Aufbau, in
dem einzelne Layers (=Schicht) individuelle Informationen einbringen. Diese Art der Darstellung zeigte
sich während der Arbeit als sehr flexibel und äußerst pragmatisch.
Jede der eingesetzten Schichten ist selbst verantwortlich für die Datenakquisition, Konstruktion und die
grafische Aufbereitung der Daten. Durch die Anzeige in der MapBean erhält jede Schicht die aktuelle
Projektion 1 . Dadurch kann die Schicht die darzustellenden Informationen für diese Projektion aufbereiten.
Darüber hinaus kann eine Schicht ihr eigenes Kontextmenü kreieren und auf Maus- und Tastatureingaben
reagieren.
OpenMap stellt bereits einige Schichten standardmäßig zur Verfügung. Dazu gehört beispielsweise das
CSVTiledImagePlugIn, zur Darstellung von einfachen Rastergrafiken. Diese müssen manuell georeferenziert werden. Dazu müssen die Koordinaten der Rastergrafik bekannt sein. Ein weiteres Layer ist
das ShapeLayer zur Darstellung von Karten im ESRI Shape Format.
ESRI Shape ESRI Shape ist ein standardisiertes Format zur Formalisierung von vektorbasierten, topografischen, digitalen Karten (vgl. [esr 98]). Es enthält einzelne Geoobjekte, die geografische Erscheinungen
(wie z.B. Pfade, Gewässer, Bebauungsflächen) repräsentieren. Geoobjekte enthalten nicht-topologische
Geometrie- und Attributinformationen und werden in drei Dateien abgelegt. Diese sind die Hauptdatei
(.shp), die Indexdatei (.shx) und die Attributtabelle (.dbf).
Die Hauptdatei besteht aus einem Header mit fester Länge und einer variablen Anzahl von Geoobjektbeschreibungen mit variabler Länge. Der Header der Hauptdatei enthält unter anderem Informationen über die
Dateilänge, die Version und den dargestellten Bereich. Jede Geoobjektbeschreibung hat wiederum einen
eigenen Header und eine variable Anzahl an Datensätzen. Im Header wird dem Geoobjekt eine fortlaufende Nummer und die Länge der Datensätze zuordnet. Datensätze des Geoobjekts können unterschiedliche Shape-Typen“ besitzen. Beispiele für Shape-Typen sind Points (Punkte bestehend aus X- und Y”
Koordinate), MultiPoints (Liste von Punkten), PolyLines (Liste von Liniensegmenten, die wiederum aus
1 OpenMap bezeichnet als Projektion nicht nur die Kartenprojektion, sondern zusätzlich den aktuellen Kartenmittelpunkt (in Latitude/Longitude), die Skalierung und die Höhe und Breite der Anzeige
100
ANHANG A. ROUTENDIENST
einer Liste von Punkten besteht) und Polygone (Liste von Ringen, die wiederum aus einer Liste von Punkten besteht).
Die Indexinformationen zu den Geoobjekten in der Indexdatei müssen die gleiche Reihenfolge haben wie
in der Hauptdatei. Zur schnelleren Suche von Geobjektbeschreibungen beinhaltet jede Indexinformation
den Offset des Geoobjekts in der Hauptdatei. Um die Indexinformation schnell auffinden zu können, haben
Indexinformationen eine konstante Länge.
Die Attributtabelle besteht aus Geoobjektattributen, wie zum Beispiel Namen, Straßenarten oder Geschwindigkeitsbeschränkungen, und Verweisen auf andere Attributtabellen. Die Anzahl und Art der Attribute hängt in der Regel von der Art des Geoobjektes ab. Um Attribute eindeutig Geoobjekten zuordnen
zu können, müssen die Attribute in der gleichen Reihenfolge wie die entsprechenden Geoobjekte in der
Hauptdatei angeordnet sein. Das Format der Attributtabelle ist das standardmäßige dBase-Format.
Meist werden Karten im ESRI Shape Format in Form einzelner Schichten mit bestimmten Informationen
angeboten. Informationen einer Schicht sind zum Beispiel Pfade, Gewässer, Siedlungsflächen, etc. Durch
geschickte Wahl dieser Schichten können wichtige Informationen eingeblendet und unwichtige Informationen ausgeblendet werden, um so keine Überflutung an Informationen in der Karte zu erzeugen.
OpenMap Viewer OpenMap liefert bereits eine vorkonfigurierte Anwendung mit dem Namen OpenMap
Viewer, der aus einer Zusammenstellung der oben genannten Java Beans besteht. Die Konfiguration erfolgt
innerhalb einer Textdatei, so dass ein Hinzufügen einzelner Schichten, Menükomponenten, Statuszeilen,
etc. ohne Neukompilierung des Systems durchgeführt werden kann. Die Konfiguration kann aber nicht zur
Laufzeit erfolgen. Neben den Java Beans sind im OpenMap Viewer viele weitere wichtige Klassen, Skripte,
Makefiles, etc. enthalten, die die Arbeit sehr erleichtern. Beispielsweise kann durch das Makefile direkt der
OpenMap Viewer in Form einer MacOSX-Applikation generiert werden oder mit Hilfe von Skripten die
Projektion von Karten im ESRI Shape Format betrachtet werden.
A.2.2
Routenerstellung
Mittels OpenMap ist es nun möglich, Karten in verschiedensten Formaten darzustellen. Ein Hauptziel
dieses Routendienstes ist aber, die Erstellung von Routen zu ermöglichen. Dazu kann auf einer weiteren
Schicht, die über der Karte dargestellt wird, die Erstellung der Routen erfolgen. Während die darunter
liegende Schicht als Daten Geoinformationen akquiriert, konstruiert und grafisch aufbereitet, sind die Informationen dieser Schicht Routen.
Den Anforderungen entsprechend soll es mehrere Eingabemöglichkeiten bei der Erstellung der Routen
geben. Einerseits sollen Aktionspunkte grafisch definiert werden können und andererseits auch in textueller Form veränderbar sein. Desweiteren gibt es eine dritte Eingabemöglichkeit für die Spezifikation der
Routenannotationen. Die Darstellung der Aktionspunkte erfolgt dementsprechend in grafischer Form und
in Form einer textbasierten Liste. Routenannotationen werden ebenfalls in Listenform dargestellt, wobei
diese speziell auf die Art der Annotation angepasst ist. Um durch die verschiedenen Ein- und Ausgabemöglichkeiten keine Inkonsistenzen bei der Routenerstellung zu erzeugen, ist es sinnvoll, nur eine zentrale Verwaltung der Route einzusetzen.
All diese Anforderungen werden durch das Konzept des Model-View-Controller (MVC) Designmusters
(vgl. [BMR+ 96]) abgebildet. Das MVC Designmuster trat erstmals in den 70er Jahren in der Programmiersprache Smalltalk80 in Erscheinung. Die MVC-Architektur basiert auf einer strikten Trennung der drei
Komponenten Model, View und Controller (vgl. Abb. A.1). Das Model verwaltet die Daten (hier z.B. Routen) und hält dafür eine interne Repräsentanz dieser Daten. Views sind verantwortlich für die Darstellung
der Daten. Dabei kann es verschiedenste Darstellungsformen der Daten geben. Für die Routendarstellung
soll hier eine grafische sowie eine textuelle Präsentation erfolgen. Controller kümmern sich um Ereignisse,
die eine Veränderung des Models nach sich ziehen. Diese Ereignisse werden meist durch den Nutzer ausgelöst. Innerhalb des Routendienstes ist ein Ereignis zum Beispiel das Klicken mit der Maus auf die Karte,
um einen Aktionspunkt zu setzen.
Um sowohl Views als auch Controller zu einem bestehenden Model hinzufügen zu können, sind das Model
und die Views/Controller nur einer geringen Kopplung ausgesetzt. Für die Views wird dies zum Beispiel
101
A.3. IMPLEMENTIERUNG
Controller
View
Model
Abbildung A.1: Model-View-Controller (MVC)
durch das Publish/Subscribe-Muster erlangt. Dazu meldet sich ein View bei dem korrespondierenden Model an (Subscribe), um daraufhin bei jeder Änderung des Datenbestandes über die Aktualisierung informiert
zu werden (Publish). Das Model merkt sich dabei nicht speziell, welcher View sich registriert hat, sondern
hält bloß eine Liste aller angemeldeten Views, die bei einer Veränderung informiert werden müssen. Jeder
View besitzt dazu eine Zugriffsmethode für die Aktualisierung.
A.2.3
Routenbereitstellung
Um die Routen für den Navigationsdienst zu erlangen, müssen sie an einer Schnittstelle des Routendienstes
zur Verfügung gestellt werden. Hierfür wurde eine Socketschnittstelle gewählt, so dass der Zugriff sowohl
durch Navigationsapplikationen auf dem mobilen Endgerät als auch durch ausgelagerte Navigationsapplikationen in der Infrastruktur erfolgen kann.
Für die Kommunikation zwischen Navigationsdienst und Routendienst wurde ein einfaches proprietäres
Protokoll gewählt, das analog zum bereits beschriebenen Protokoll innerhalb des MoBiLe-Service aufgebaut ist. Für die lokale Variante des MoBiLe-Service kann hierdurch unnötiger Datenverkehr über die
Luftschnittstelle, der durch die große Menge an Signalisierungsverkehr zum Beispiel bei HTTP oder SMTP
entsteht, verhindert werden. Der Routendienst beherrscht derzeit drei Zugriffsmethoden, die eingesetzt werden können, um gesamte Routen, Aktionspunkte von Routen oder deren Annotationen abzufragen. Diese
Methoden sind getRoute, getActionPoints und getAnnotations. Wird kein Parameter zu diesen Methoden angegeben, werden alle verfügbaren Informationen zurückgeliefert. Parameter können die
angeforderte Route genauer spezifizieren. Als Parameter kann die bereits in Kapitel 5.5 vorgestellte RouteProperty eingesetzt werden.
A.3
Implementierung
Wie genau die oben beschriebene Architektur in der Implementierung umgesetzt wurde, wird im Folgenden
behandelt. Hierbei wurden einige wichtige Details, wie zum Beispiel die Umsetzung der MVC-Architektur,
ausgewählt. Für eine vollständige Beschreibung wird auf den Quellcode des Routendienstes verwiesen.
A.3.1 Model
Das Model (RouteModel) der grafischen Routenerstellung ist verantwortlich für den Zugriff auf die
Route. Zur Beschreibung der Route wurde die bereits in Kapitel 5.5 dargestellte Form benutzt, die im
Wesentlichen aus einer geordneten Liste von Aktionspunkten mit einer bestimmten Position und einer
102
ANHANG A. ROUTENDIENST
einzuschlagenden Richtung besteht. Zusätzlich können zu jeder Route noch eine Menge an Annotationen hinzugefügt werden. In der Implementierung wurden als Annotationen nur der Name der Route, der
Schwierigkeitsgrad, die Länge der Route und die zu überwindenden Höhenmeter eingesetzt. Alle Zugriffe
auf die Route, unabhängig davon, ob es sich um lesende Zugriffe der Views oder schreibende Zugriffe
der Controller handelt, werden durch das Model durchgeführt. Dazu implementiert das RouteModel das
Interface Model, welches alle möglichen schreibenden Zugriffe spezifiziert. Über dieses Interface können
die verschiedenen Controller auf das RouteModel zugreifen. Die für den Zugriff implementierten Methoden sind:
• setRoute zum Setzen einer neuen Route
• addActionPoint zum Hinzufügen eines Aktionspunktes zur aktuellen Route
• removeActionPoint um Aktionspunkte aus der aktuellen Route zu entfernen
• setAnnotations um Annotationen an die aktuelle Route anzuhängen
• saveRoute um Routen persistent im Dateisystem abzuspeichern
Außerdem stellt das RouteModel die Methode addView bereit, um Views zu diesem Model hinzuzufügen. Bei jeder Veränderung der Route durch obige Zugriffsmethoden werden alle Views über die
Änderung informiert.
A.3.2 View
Zur Darstellung der aktuellen Route stehen dem Nutzer diverse Views für das RouteModel zur
Verfügung, die automatisch oder manuell eingeblendet werden (vgl. Abb. A.2).
RouteLayer
SaveRoute
MenuItem
ActionPoint
InfoPanel
Route
InfoPanel
RouteModel
LoadRoute
MenuItem
Abbildung A.2: MVC-Architektur des Routendienstes
A.3.2.1
Grafische Darstellung der Aktionspunkte
Der wichtigste View ist sicherlich die grafische Darstellung auf dem Kartenhintergrund. Die Karte wird
dabei durch eine darunter liegende Schicht angezeigt. Als digitaler Datenbestand wurden topografische
Karten im ESRI Shape Format gewählt, da diese über eine hohe Genauigkeit verfügen, einen gewissen
Grad an Semantik der enthaltenen Geoobjekte besitzen und mit einem sehr hohen Detailgrad in Deutschland angeboten werden. Die eingesetzten Karten stammen vom Bayrischen Landesvermessungsamt und
bestehen aus einer Menge einzelner Schichten. Als wichtige Schichten für die Erstellung von MountainBike-Touren stellten sich Schichten mit folgenden Informationen heraus (in aufsteigender Ordnung):
• Besiedlung: Darstellung von Siedlungsflächen
A.3. IMPLEMENTIERUNG
103
• Bepflanzung: Darstellung von Wäldern oder Baumgruppen
• Gewässer: Darstellung von Flüssen, Bächen und Seen
• Pfadinformationen: Darstellung von Straßen, Wegen, Plätzen, etc.
Die Geoobjekte der einzelnen Schichten können durch verschiedenfarbige Einfärbung visuell voneinander
getrennt werden. Für die Farbwahl wurden die in Deutschland gängigen Farben gewählt (Siedlung: orangebraun, Pflanzen: grün, Gewässer: blau, Pfadinformationen: schwarz). Dadurch kann der Nutzer ohne große
Vorkenntnis oder Betrachtung der Legende intuitiv den dargestellten Inhalt verstehen.
Überhalb dieser Schichten liegt das RouteLayer, das die Aktionspunkte als rote Kreise darstellt. Je
nach Stärke der Vergrößerung besitzt der Kreis unterschiedliche Radien bezüglich des zugrunde liegenden
Kartenmaterials, so dass er eine einheitliche Größe in der Darstellung besitzt. In unmittelbarem Umfeld des
Kreises ist außerdem die ID des Aktionspunktes zu finden, um eindeutig vom Nutzer identifiziert werden
zu können.
Ein Screenshot mit allen implementierten Views ist in Abbildung A.3 dargestellt.
Abbildung A.3: Screenshot der grafischen Oberfläche des Routendienstes
A.3.2.2
Textuelle Darstellung der Aktionspunkte
Neben der grafischen Darstellung der Aktionspunkte zeigt eine Listendarstellung die Aktionspunkte der aktuellen Route in aufsteigender Reihenfolge. Die Darstellung in textueller Form erfolgt erst nach manueller
Wahl eines entsprechenden Symbols in der Werkzeugleiste. Wird aus der Liste (javax.swing.JList)
ein Aktionspunkt ausgewählt, erscheint dessen ID sowie dessen Austrittsrichtung innerhalb des Fensters.
104
A.3.2.3
ANHANG A. ROUTENDIENST
Textuelle Darstellung der Route
Eine dritte Darstellung der Route präsentiert alle Annotationen der aktuellen Route und einige weitere
Informationen. Darstellbare Annotationen sind der Name der Route, der Schwierigkeitsgrad, die Länge
und die Anzahl der Höhenmeter. Je nach Art der Annotation erfolgt eine unterschiedliche Darstellung.
Name, Länge und Höhenmeter erscheinen in Textfeldern, wobei die Textfelder der Länge und Höhenmeter ausschließlich Dezimalzahlen darstellen können. Der Schwierigkeitsgrad wird durch eine javax.swing.JComboBox präsentiert, die Werte zwischen 1 und 5 enthalten kann. Desweiteren wird
für jede Route die interne ID angezeigt.
A.3.3
Controller
Eingabemöglichkeiten für die Route werden durch einige Controller des Routendienstes repräsentiert.
Meist sind diese an die Views gekoppelt. Es existieren aber auch einige Controller die keinem View
zugeordnet werden können (vgl. Abb. A.2.
A.3.3.1
Grafische Aktionspunktmanipulation
Innerhalb der grafischen Darstellung der Aktionspunkte kann durch einfaches Klicken mit der Maus ein
Aktionspunkt gesetzt werden. Bevor dieser in die Route übernommen wird, muss der Nutzer noch manuell die Austrittsrichtung bestimmen (vgl. Abb. A.4). Dazu werden ihm acht mögliche Sektoren bereitgestellt, die den Himmelsrichtungen N ord, N ordost, Ost, S üdost, S üd, S üdwest, W est, N ordwest entsprechen. Durch Anklicken kann der Nutzer die Austrittsrichtung spezifizieren. Wird an einer anderen
Stelle als der vorgeschlagenen Richtungen geklickt, wird der Vorgang abgebrochen. Daraufhin kann ein
anderer Aktionspunkt gesetzt werden.
Zur Wahrung der Flexibilität wurde bei der Routenbestimmung durch den Nutzer nicht auf Geoobjekte,
im Speziellen auf Pfadinformationen, eingegangen, obwohl dies prinzipiell möglich und sinnvoll ist. Pfadinformationen sind auf einfache Art und Weise aber nur in Vektorgrafiken zugänglich (vgl. [Beck 02]).
Um mit gleicher Technik auch Rastergrafiken einsetzen zu können, wurde die oben dargestellte Art der
Aktionspunkt- und Austrittsrichtungsbestimmung gewählt. Hierbei muss eine manuelle Wahl der Austrittsrichtung erfolgen.
Abbildung A.4: Spezifikation der Austrittsrichtung aus Aktionspunkt
A.4. EVALUIERUNG UND AUSBLICK
A.3.3.2
105
Textuelle Aktionspunktmanipulation
Die oben beschriebene textuelle Darstellung der Aktionspunkte ist gleichzeitig ein weiterer Controller.
Durch Auswahl eines Aktionspunktes aus der Liste wird dessen ID und Austrittsrichtung in einem Textfeld bzw. einer ComboBox angezeigt. Innerhalb des Textfeldes und der ComboBox können diese Werte
nachträglich verändert werden. Außerdem können einzelne Aktionspunkte an dieser Stelle entfernt werden.
A.3.3.3
Textuelle Annotationsmanipulation
Ähnlich wie bei der Darstellung der Aktionspunkte kann in der textuellen Darstellung der Routenannotationen das entsprechende RouteProperty geändert werden. Änderungen sind möglich für den Routennamen, den Schwierigkeitsgrad, die Länge und die Anzahl der Höhenmeter. Die interne ID der Route
sowie die Anzahl der Aktionspunkte können an dieser Stelle nicht verändert werden.
A.3.3.4
Routenspeicherung
Wurde die Route erfolgreich erstellt, kann sie im Dateisystem persistent abgelegt werden. Hierfür existiert
ein weiterer Controller, der durch das Menü gestartet werden kann. Wird er aufgerufen, so muss im Folgenden der Ort der Speicherung und der Dateiname festgelegt werden. Durch Bestätigung wird die Route über
das RouteModel unter dem Dateinamen abgelegt und kann so später wieder geladen werden. Außerdem
kann die Route ab der Speicherung für den Navigationsdienst zugänglich gemacht werden.
A.3.3.5
Routenwiederherstellung
Bereits abgespeicherte Routen können durch einen weiteren Menüpunkt wieder geladen werden. Dazu
muss der Nutzer die Datei, innerhalb der die Route abgelegt wurde, spezifizieren. Nach dem Ladevorgang
wird die geladene Route an das RouteModel übergeben. Das RouteModel führt daraufhin (wie bei
allen Änderungen) eine Aktualisierung der Views durch. Die Routenwiederherstellung und Routenspeicherung stellen nur Contoller dar und besitzen keine Views, da sie nur Operationen auf die Route, aber
keine Darstellung der Route durchführen.
A.3.4
RouteServer
Der RouteServer stellt die veröffentlichten Routen an einer Socketschnittstelle bereit. Auf diese
Socketschnittstelle kann der Navigationsdienst zugreifen. Dabei ist unwichtig, ob der Navigationsdienst
lokal oder verteilt ist. Für den Zugriff stehen die bereits beschriebenen Methoden zur Verfügung. Gestartet
und gestoppt wird der Routendienst durch einen Menüpunkt des OpenMap Viewers. Dabei kann angegeben
werden, welche Routen durch die Socketschnittstelle veröffentlicht werden sollen.
A.4
Evaluierung und Ausblick
Die Implementierung des Routendienstes hat gezeigt, dass eine Umsetzung auf der Basis von OpenMap
sehr komfortabel und zielführend ist. Die oben angeführten Aspekte ließen sich wie gewünscht umsetzen
und nutzen. So entstand ein Routendienst, der den gewünschten Anforderungen an die Routenerstellung,
-verwaltung und -bereitstellung weitgehend entgegenkommt.
Routen lassen sich auf eine nutzerfreundliche Art definieren und verändern, persistent speichern und später
wiederherstellen. Das zugrunde liegende Kartenmaterial präsentierte sich als äußerst detailreich und exakt
106
ANHANG A. ROUTENDIENST
in der Georeferenzierung. Für einige ausgewählte Testpunkte ergab sich nur ein geringer Messfehler zwischen Koordinaten der Karte und Koordinaten aus dem Fortuna Clip-On Bluetooth GPS Receiver.
Leider benötigt das vektorbasierte Kartenmaterial für die Darstellung relativ viel Rechenleistung, was bei
Vergrößerungen, Verschiebungen oder Bearbeitungen teilweise zu längeren Wartezeiten führte. Diese beliefen sich meist auf wenige Sekunden, die die Arbeit nur unwesentlich beeinträchtigten.
Möglicherweise können hier noch Effizienzsteigerungen zum Beispiel durch Caching erzielt werden. Wie
bereits angesprochen, kann in Erweiterungen des Routendienstes auch auf die Geoobjekte des ESRI Shape
eingegangen werden. Mögliche Vorteile ergeben sich zum Beispiel durch die automatische Bestimmung
der Austrittsrichtung und die Einfärbung relevanter Pfadsegmente. Dadurch wäre beispielsweise auch eine
automatische Bestimmung der Routenlänge und der Anzahl der Höhenmeter möglich. Desweiteren könnten mehrere Routen gleichzeitig eingeblendet und bearbeitet werden bzw. Alternativrouten zu einer Route
definierbar sein. Zusammenfassend kann gesagt werden, dass an die Weiterentwicklung des Routendienstes keine Grenzen gesetzt sind. Vorstellbar sind diverse Erweiterungen für verschiedenste Funktionen und
Eigenschaften. Die derzeitige Version des Routendienstes ist aber vollkommen ausreichend für die Erstellung, Verwaltung und Bereitstellung der Mountain-Bike-Routen und hat sich in der Praxis bereits als sehr
nützlich herausgestellt.
Literaturverzeichnis
[3gp a]
Gateway Mobile Location Center. Technischer Bericht 03.71, 3rd Generation Partnership
Project (3GPP).
[3gp b]
IP Multimedia Subsystem. Technischer Bericht 23.228, 3rd Generation Partnership Project
(3GPP).
[3gp c]
Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface. Technischer Bericht 24.011, 3rd Generation Partnership Project (3GPP).
[3gp d]
Push Service. Technischer Bericht 22.174, 3rd Generation Partnership Project (3GPP), März.
[3gp e]
Support of Push service. Technischer Bericht 23.974, 3rd Generation Partnership Project
(3GPP).
[3gp 04]
Functional stage 2 desctiption of Location Services (LCS). Technischer Bericht 23.271, 3rd
Generation Partnership Project (3GPP), 2004.
[AAH+ 97] A BOWD , G REGORY D., C HRISTOPHER G. ATKESON, JASON H ONG, S UE L ONG, ROB KO OPER und M IKE P INKERTON : Cyberguide: A Mobile Context-Aware Tour Guide. In: ACM
Wireless Networks, Seiten 421–433, 1997, citeseer.ist.psu.edu/abowd97cyberguide.html .
[act ]
Falk Active Pilot, http://www.activepilot.de .
[and ]
Automotive Navigation Data, http://www.and.com .
[Ande 03a] A NDERSSON , O LA: Mobile SVG Profiles: SVG Tiny and SVG Basic. Technischer Bericht,
W3C, 2003, http://www.w3.org/TR/SVGMobile/ .
[Ande 03b] A NDERSSON , O LA: Scalable Vector Graphics (SVG) 1.1. Technischer Bericht, W3C, 2003,
http://www.w3.org/TR/SVG11/ .
[Andr 91]
A NDREWS , G REGORY R.: Paradigms for Process Interaction in Distributed Programs.
1991.
[atk ]
Amtliches Topographisch-Kartographisches Informationssystem, http://www.atkis.de .
[b2m ]
B2Motion - NavMe, http://www.navme.de .
[BBKL ]
B UTZ , A NDREAS, J ÖRG BAUS, A NTONIO K R ÜGER und M ARCO L OHSE: A Hybrid Indoor
Navigation System. .
[BCK 04]
BAUS , J ÖRG, K EITH C HEVERST und C HRISTIAN K RAY: A Survey of Map-based Mobile
Guides. 2004.
[Beck 02]
B ECKERT, C HRISTIANE: Möglichkeiten der Beschaffung und Bereitstellung digitaler Karten
im Sondersammelgebiet. Technischer Bericht, DFG, 2002.
[BKK 01]
BAUS , J ÖRG, C HRISTIAN K RAY und A NTONIO K R ÜGER: Visualisation of route descriptions in resource-adaptive navigation aid. 2001.
107
108
LITERATURVERZEICHNIS
[BKKW ]
BAUS , J ÖRG, C HRISTIAN K RAY, A NTONIO K R ÜGER und W OLFGANG WAHLSTER: A
Resource-Adaptive Mobile Navigation System. .
[bla ]
Blackberry, http://www.blackberry.com .
[blu ]
Bluelet - Bluetooth GUI Component, http://www.benhui.net .
[blv ]
Bayrisches Landesvermessungsamt, http://www.blva.de .
[BMR+ 96] B USCHMANN , F RANK, R EGINE M EUNIER, H ANS ROHNERT, P ETER S OMMERLAD und
M ICHEAL S TAL: Pattern-oriented software architecture. John Wiley & Sons, 1996.
[BoCa 46]
B ORGES , J ORGE L UIS und A DOLFO B IOY C ASARES: Of Exactitude in Science. 1946,
www.kyb.tuebingen.mpg.de/bu/people/bs/borges.html .
[Brow ]
B ROWN ,
P.
J.:
Triggering
information
http://www.cs.kent.ac.uk/pubs/1998/591/content.html .
[BuTu ]
B URMAKIN , E UGENE M. und J UHA O. T UOMINEN: Development of mobile distributed
applications. .
[CCR 03]
C HEN , X IAOYAN, Y ING C HEN und FANGYAN R AO: An Efficient Spatial Publish/Subscribe
System for Intelligent Location-Based Services. 2003.
by
context.
,
[CDM+ 00] C HEVERST, K EITH, N IGEL DAVIES, K EITH M ITCHELL, A DRIAN F RIDAY und
C HRISTOS E FSTRATIOU: Developing a Context-aware Electronic Tourist Guide: Some Issues and Experiences.
In: Proceedings of CHI 2000, Netherlands, 2000. ,
http://www.guide.lancs.ac.uk/CHIpaper.pdf .
[CDMF 00] C HEVERST, K EITH, N IGEL DAVIES, K EITH M ITCHELL und A DRIAN F RIDAY: The Role of
Connectivity in Supporting Context-Sensitive Applications. 2000.
[ChKo 00]
C HEN , G UANLING und DAVID KOTZ: A Survey of Context-Aware Mobile Computing Research. 2000.
[Chun 03]
C HUNG , N G P ING: Positioning of Mobile Devices.
August 2003,
http://www.giscentrum.lu.se/www summeruniverstity/projects2003/PingChung.pdf .
[cld a]
Connected Limited Device Configuration 1.0. Technischer Bericht JSR-30, Java Community
Process (JCP).
[cld b]
Connected Limited Device Configuration 1.1. Technischer Bericht JSR-139, Java Community
Process (JCP).
[CST 04]
C AETANO , A RTUR, A NTONIO R ITO S ILVA und J OSE T RIBOLET: Using Roles To Specify
Business Object Collaborations. Technischer Bericht, 2004.
[Czom 00]
C ZOMMER , R ENATE: Leistungsfähigkeit fahrzeugautonomer Ortungsverfahren auf der Basis
von Map-Matching Techniken. Doktorarbeit, Universität Stuttgart, Dezember 2000.
[DeAb 99]
D EY, A NIND K. und G REGORY D. A BOWD: Towards a Better Understanding of Context
and Context-Awareness. 1999.
[DFGS 05]
D ÜRR , M ICHAEL, KORBINIAN F RANK, A NDREAS G IESEMANN und D OMINIK S CHMIDT:
Location Based Services. 2005.
[Dijk 76]
D IJKSTRA , E. W.: A Discipline of programming. Prentice Hall, New York, 1976.
[elb ]
European Location Based Advertising. http://www.yellowmap.com/mobile/elba.asp.
[esr 98]
ESRI Shapefile Technical Description. Technischer Bericht, ESRI, 1998.
[Fiel 99]
F IELDING: HTTP/1.1. Technischer Bericht, Internet Engineering Task Force (IETF), Juni
1999.
LITERATURVERZEICHNIS
109
[for ]
Fortuna, http://www.fortuna.com.tw .
[for 04]
Nokia 6630, Juni 2004, http://www.forum.nokia.com/main/0,6566,016-2219,00.html .
[FrZd 96]
F RANKLIN , M ICHAEL und S TAN Z DONIK: Dissemination-Based Information Systems. IEEE Data Engineering Bulletin, 19(3), September 1996.
[Fuch 02]
F UCHS , F LORIAN: Realizing Location-Based Push-Services on Mobile Devices, 2002.
[Funk ]
F UNK , NATHAN: Java Expression Parser, http://jep.sourceforge.net .
[gal ]
Galileo Joint Undertaking, http://www.galileoju.com .
[gar ]
Garmin, http://www.garmin.de .
[GaSh 93]
G ARLAN , DAVID und M ARY S HAW: An Introduction to Software Architecture. In: A MBRIO V. und G. T ORTORA (Herausgeber): Advances in Software Engineering and Knowledge
Engineering, New Jersey, 1993. World Scientific Publishing Company.
LA ,
[gdf 96]
Geographic Data Files (GDF). Technischer Bericht 14825:1996(E), International Standards
Organisation (ISO), 1996.
[geo 84]
Geodesy for the layman. Technischer Bericht DMA TR 80-003, Defense Mapping Agency,
Washington D C, 1984.
[geo 04]
Geopriv Requirements. Technischer Bericht RFC 3693, Internet Engineering Task Force
(IETF), 2004.
[GKW 04]
G RANDE , A NTJE, B IRGIT K RAUS und D OROTHEE W IEGAND: Standortbestimmung. CT
Magazin, (10), 2004.
[glo a]
Global Locate A-GPS, http://www.glocallocate.com/A-GPS/A-GPS-Frameset.htm .
[glo b]
Global’naya Navigatsionannaya Sputnikovaya Sistema, http://www.glonass-center.ru .
[gsm ]
GSM Coverage, http://www.gsmworld.com/roaming/gsminfo/cou de.shtml .
[gsm 03]
Location Based Services.
Technischer Bericht SE.23, GSM Association, 2003,
http://www.gsmworld.com/technology/applications/location.shtml .
[Hell 04]
H ELLMANN , W IEBKE: Völlig losgelöst ans Ziel.
Chip, November
http://www.chip.de/artikel/c1 artikel 12835281.html?tid1=20827&tid2=0 .
[HiBo 01]
H IGHTOWER , J EFFREY und G AETANO B ORIELLO: Location Sensing Techniques. 2001.
[HLP ]
H UANG , A NDREW C., B ENJAMIN C. L ING und S HANKAR P ONNEKANTI: Pervasive Computing: What Is It Good For? .
[hof 93]
GPS - Theory and Practice. Springer-Verlag Wien, 2 Auflage, 1993.
[iet 99]
Session Initiation Protocol. Technischer Bericht RFC 2543, Internet Engineering Task Force
(IETF), 1999.
[jab ]
Java APIs for Bluetooth Wireless Technology. Technischer Bericht JSR-82, Java Community
Process (JCP).
[jam ]
Jamba, http://www.jamba.de .
[jav ]
Java 2, http://java.sun.com .
[Klat 04]
K LATZKY, ROBERTA L.: Allocentric and Egocentric Spatial Representations: Definitions,
Distinctions, and Interconnections. 2004.
2004,
[KLEC 03] K RAY, C HRISTIAN, K ATRI L AAKSO, C HRISTIAN E LTING und VOLKER C OORS: Presenting Route Instructions on Mobile Devices. 2003.
110
LITERATURVERZEICHNIS
[Klin 04]
K LINGSHEIM , A NDRE N.: J2ME Bluetooth Programming. Diplomarbeit, Universtität Bergen, 2004.
[Klip 03]
K LIPPEL , A LEXANDER: Wayfinding Choremes - Conceptualizing Wayfinding and Route Direction Elements. Doktorarbeit, Universität Bremen, 2003.
[Kola ]
KOLAROFF , S TEPHEN: JEPLite - JEP enlited, http://jeplite.sourceforge.net .
[kow ]
GPS, http://www.kowoma.de/gps .
[Kray 03]
K RAY, C HRISTIAN: Situated Interaction on Spatial Topics. Doktorarbeit, Universität des
Saarlandes, 2003.
[KrBa 03]
K RAY, C HRISTIAN und J ÖRG BAUS: A survey of mobile guides. 2003.
[Kuip 00]
K UIPERS , B. J.: The spatial semantic hierarchy. In: Artificial Intelligence, Seiten 191–233,
2000.
[Küpp 05]
K ÜPPER , A XEL: LBS - Fundamentals and Operation. John Wiley & Sons, 2005.
[KüTr 05]
K ÜPPER , A XEL und G EORG T REU: From Location to Position Management: User Tracking
for Loction-based Services. 2005.
[lap 03]
Location API for J2ME. Technischer Bericht 179, Java Community Process (JCP), 2003.
[LeRo 00]
L EONHARDI , A LEXANDER und K URT ROTHERMEL: A Comparison of Protocols for Updating Location Information. 2000.
[LKAA 96] L ONG , S UE, ROB KOOPER, G REGORY D. A BOWD und C HRISTOPHER G. ATKESON: Rapid
Prototyping of Mobile Context-Aware Applications: The Cyberguide Case Study. In: Mobile
Computing and Networking, Seiten 97–107, 1996, citeseer.ist.psu.edu/long96rapid.html .
[Logs 92]
L OGSDON , T OM: The NAVSTAR Global Positioning System. Van Nostrand Reinhold, 1992.
[LPKü 04]
L INNHOFF -P OPIEN , C LAUDIA und A XEL K ÜPPER: Vorlesung: Location Based Services,
2004.
[m3g ]
Mobile 3D Graphics API for J2ME. Technischer Bericht JSR-184, Java Community Process
(JCP).
[Maea 04]
M ABROUK , M ARWA und ET AL .: OpenGIS Location Services (OpenLS): Core Services.
Technischer Bericht 03-006r3, Open GIS Consortium Inc., Januar 2004.
[mag ]
Magellan, http://www.magellangps.com .
[Mala 99]
M ALAKA , R AINER: Deep Map: The Multilingual Tourist Guide. 1999.
[mas ]
Mascot Capsule, http://www.mascotcapsule.com/ .
[MaZi 00]
M ALAKA , R AINER und A LEXANDER Z IPF: DEEP MAP - Challenging IT research in the
framework of a tourist information system. 2000.
[me4 ]
ME4SE, http://kobjects.sourceforge.net/me4se .
[mid a]
Mobile Information Device Profile 1.0. Technischer Bericht JSR-37, Java Community Process (JCP).
[mid b]
Mobile Information Device Profile 2.0. Technischer Bericht JSR-118, Java Community Process (JCP).
[mlp ]
Mobile Location Protocol. Technischer Bericht, Open Mobile Alliance (OMA).
[mma ]
Mobile Media API 1.1. Technischer Bericht JSR-135, Java Community Process (JCP).
[mob ]
Mobile Navigator. http://www.wayfinder.com.
[mog ]
MOGI, http://www.mogimogi.com .
LITERATURVERZEICHNIS
[Mont ]
111
M ONTELLO: Navigation. .
[MTSM 03] M C G OVERN , JAMES, S AMEER T YAGI, M ICHAEL S TEVENS und S UNIL M ATHEW: Java
Web Services Architecture. Morgan Kaufmann Publishers, 2003.
[nav ]
NAVTEQ, http://www.navteq.com .
[Nico 03]
N ICOLAI , ROEL: Spatial referencing by coordinates. Technischer Bericht, Open GIS Consortium Inc., Oktober 2003.
[Nieb 04]
N IEBISCH , F RANK L.: Smartphones weisen den Weg. Handelsblatt, Dezember 2004,
http://www.handelsblatt.com/pshb?fn=tt&sfn=go&id=87913 .
[nme ]
National Marine Electronics Association (NMEA), http://www.nmea.org .
[nok ]
Nokia 6630, http://www.nokia.com/nokia/0,,58708,00.html .
[o2 ]
O2, http://www.o2online.de .
[off a]
Navstar Global Positioning System, http://tycho.usno.navy.mil/gps.html .
[off b]
NAVSTAR GPS, ftp://tyscho.usno.navy.mil/pub/gps/gpsb2.txt .
[ope a]
OpenGL ES. Technischer Bericht.
[ope b]
OpenMap - Open Systems Mapping Technology, http://openmap.bbn.com .
[PARA 02]
PARAMOUNT: Client/Server Trade-Off. Technical Note Deliverable D7, 2002.
[Pars 04]
PARSONS , D.: The mobile future. In: Res. Lett. Inf. Math. Sci., Seiten 47–58, 2004.
[Pass 92]
PASSINI , R.: Wayfinding in architecture. Van Nostrand Reinhold Company, New York, 1992.
[PCW 84]
PARNAS , D. L., P. C. C LEMENTS und D. M. W EISS: The Modular Structure of Complex
Systems. 1984.
[PKK ]
P OSPISCHIL , G ÜNTHER, H ARALD K UNCZIER und A LEXANDER K UCHAR: LoL@: a
UMTS location based service. .
[PSM 01]
P OSPISCHIL , G ÜNTHER, J OHANNES S TADLER und I GOR M ILADINOVIC: A Locationbased Push Architecture using SIP. Denmark, September 2001. .
[ptv ]
PTV AG, http://www.ptv.de .
[PUM 02]
P OSPISCHIL , G ÜNTHER, M ARTINA U MLAUFT und E LKE M ICHLMAYR: Designing LoL@,
a Mobile Tourist Guide for UMTS. 2002.
[Röck 03]
R ÖCKL , M ATTHIAS: Highlevel Service Handover in einem kontextuellen Framework, 2003.
[RöLa 02]
R ÖFER , T. und A. L ANKENAU: Route-Based Robot Navigation. In: F REKSA , C. (Herausgeber): Künstliche Intelligenz - Themenheft Spatial Cognition, Seiten 29–31. Fachbereich 1
der Gesellschaft für Informatik e.V., 2002.
[Roth 03]
ROTH , J ÖRG: Flexible Positioning For Location-based Services. 2003.
[rou ]
Route 66. http://www.66.com.
[RuKr 03]
RUPNIK , ROK und M ARJAN K RISPER: The role of mobile applications in information systems. 2003.
[SAW 94]
S CHILIT, B ILL N., N ORMAN A DAMS und ROY WANT: Context-Aware Computing Applications. 1994.
[Schi 95]
S CHILIT, W ILLIAM N OAH: A System Architecture for Context-Aware Mobile Computing.
Doktorarbeit, Columbia University, 1995.
112
LITERATURVERZEICHNIS
[Schm 04]
S CHMATZ , K LAUS -D IETER: Java 2 Micro Edition - Entwicklung mobiler Anwendungen mit
CLDC und MIDP. Nummer 3-89864-271-2. dpunkt.verlag, April 2004.
[Simo 05]
S IMON , M URIEL: Galileo - The European Programme for Global Navigation Services. ESA
Publications Division, Niederlande, 2 Auflage, Januar 2005.
[sir ]
SIRF, http://www.sirf.com .
[SLPR 03]
S TRANG , T HOMAS, C LAUDIA L INNHOFF -P OPIEN und M ATTHIAS R ÖCKL: Highlevel Service Handover through a Contextual Framework. 2003.
[SMLP ]
S AMULOWITZ , M ICHAEL, F LORIAN M ICHAHELLES und C LAUDIA L INNHOFF -P OPIEN:
CAPEUS: An Architecture for Context-Aware Selection and Execution of Services. .
[sql 99]
Structured Query Language. Technischer Bericht SQL3, International Standards Organisation (ISO), 1999.
[StLP 03]
S TRANG , T HOMAS und C LAUDIA L INNHOFF -P OPIEN: Service-Interoperabilität auf Kontextebene. 2003.
[Stra 05]
S TRANG , T HOMAS: Vorlesung: Ubiquitous Services, Wintersemester 04/05.
[Stra 03]
S TRANG , T HOMAS: Service-Interoperabilität in Ubiquitous Computing Umgebungen. Doktorarbeit, Ludwig-Maximillians-Universität München, 2003.
[svg ]
Scalable 2D Vector Graphics API for J2ME. Technischer Bericht JSR-226, Java Community
Process (JCP).
[sym ]
Symbian OS, http://www.symbian.com .
[TavS 03]
TANENBAUM , A NDREW S. und M AARTEN VAN S TEEN: Distributed Systems. Prentice Hall,
März 2003.
[tel ]
Teleatlas, http://www.teleatlas.com .
[tin ]
TinyLine - Mobile SVG Software for J2ME, http://www.tinyline.com .
[tol ]
Toll Collect, http://www.toll-collect.de .
[Tolm 48]
T OLMAN , E DWARD C.: Cognitive maps in rats and men. Psychological Review, (55):189–
208, 1948.
[tom ]
Tom Tom Mobile 5, http://www.tomtom.com .
[Tosi 03]
T OSI , DAVIDE: An Advanced Architecture for Push Services. Technischer Bericht, Universita
degli Studi di Milano - Bicocca, 2003.
[Umar 97]
U MAR , A MJAD: Object-Oriented Client/Server Interent Environments. Prentice Hall, 1997.
[uml 03]
Unified Modeling Language Specification. Technischer Bericht, Object Management Group
(OMG), 2003.
[UPNM ]
U MLAUFT, M., G. P OSPISCHIL, G. N IKLFELD und E. M ICHLMAYR: LoL@, a Mobile Tourist Guide for UMTS. .
[VAL+ 01] V ÄRE , JANNE, N. A SOKAN, S HREEKANTH L AKSHMESHWAR, S YLVIE B RUNESSAUX und
C EDRIC C ARON: Report on the Review and Selection of Authentication and Security Techniques, Applicable Internet Technologies, Hardware Platforms, Mobile Phones and Internet
Terminals. Technischer Bericht, Nokia - VTT Information Technology - MATRA Systemes
& Information, 2001.
[VHT ]
VALLECILLO , A NTONIO, J UAN H ERNANDES und J OSE M. T ROYA: Component Interoperability. .
113
LITERATURVERZEICHNIS
[Wald 03]
WALDEN , M ARTIN: Towards the integration of vector map graphics in mobile environments.
Diplomarbeit, Lund Institute of Technology, 2003.
[wap a]
Wireless Application Protocol, http://wapforum.org .
[wap b]
Wireless Application Protocol Push Architecture, http://www1.wapforum.org/tech/terms.asp?doc=WAP250-PushArchOverview-20010703-a.pdf .
[Warr 99]
WARREN , I AN: The Renaissance of Legacy Systems. Springer, Januar 1999.
[web ]
Webraska, http://www.webraska.com .
[Weis 91]
W EISER , M ARK: The Computer for the Twenty-First Century. Scientific American, Seiten
94–100, 1991.
[wgs ]
World Geodetic System 1984, http://www.wgs84.com .
[wik ]
Wikipedia, http://www.wikipedia.de .
[WKBH 00] W ERNER , S., B. K RIEG -B R ÜCKNER und T. H ERRMANN: Modeling navigational knowledge by route graphs. In: Spatial cognition II. Integrating abstract theories, empirical studies,
formal methods, and practical applications, 2000.
[ZiAr 02]
Z IPF, A LEXANDER und H IDIR A RAS: Proactive Exploitation of the Spatial Context in LBS
through Interoperable Integration of GIS-Services with an Multi Agent System. 2002.
[Zieg 04]
Z IEGLER , P ETER -M ICHAEL: Routenplaner im Handy.
http://www.heise.de/mobil/artikel/50891 .
[Zogg 02]
Z OGG , J EAN -M ARIE: GPS Basics.
lab/usbgps/doc/gps basic.pdf .
Heise Online, Juli 2004,
u-blox, März 2002, http://www.ee.ucr.edu/ cr-