Konzipierung eines FMC-Clients für mobile Endgeräte

Transcription

Konzipierung eines FMC-Clients
für mobile Endgeräte
Studienarbeit
Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
vorgelegt von
Guanzhou Lu
II03 34708
Betreuer:
Dipl.-Ing. Yevgeniy Yeryomin
Abgabedatum:
30,04,08
Inhaltsverzeichnis
1. Einleitung
4
1.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2. Ziel dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2. Grundlage
5
2.1. NGN-Next Generation Network . . . . . . . . . . . . . . . . . . . . . . .
5
2.2. IMS-IP Multimedia Subsystem
. . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1. IMS Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3. VoIP-Voice over Internet Protocol . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1. SIP-Session Initiation Protocol
. . . . . . . . . . . . . . . . . . .
8
2.3.2. SDP-Session Description Protocol . . . . . . . . . . . . . . . . . . 10
2.3.3. VoWLAN-Voice over WLAN . . . . . . . . . . . . . . . . . . . . . 10
2.4. FMC-Fixed-Mobile Convergence . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Was ist FMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Vorteile von FMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3. Technischer Status von FMC
3. FMC-Client
. . . . . . . . . . . . . . . . . . . . 13
15
3.1. Technische Realisierung von FMC-Client . . . . . . . . . . . . . . . . . . 15
3.1.1. UMA basierte FMC . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2.
IMS-VCC basierte FMC . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3. Vergleich UMA und IMS-VCC . . . . . . . . . . . . . . . . . . . . 20
3.2. Bestehende FMC-Lösungen von verschiedenen Firmen . . . . . . . . . . . 20
3.3. FMC-Clientarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Analyse der Anforderungen an FMC-Client . . . . . . . . . . . . . 26
3.3.2. Realisierungsmethoden gemäß Anforderungen . . . . . . . . . . . 28
3.3.3. VoIP-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.4. Clientkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4. Funktionsablauf des FMC-Clients . . . . . . . . . . . . . . . . . . . . . . 35
3.5. Anforderungen an Mobile Endgeräte und Betriebssysteme . . . . . . . . . 36
2
Inhaltsverzeichnis
3.5.1. Nötige APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4. APIs und Mobile Systeme
39
4.1. Analyse der angebotenen mobilen Endgeräten . . . . . . . . . . . . . . . 39
4.2. Untersuchung der Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1. Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2. Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3. Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.4. Linux OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.5. Analyse der Mobile Systemen . . . . . . . . . . . . . . . . . . . . 47
4.3. API-Application Programming Interface . . . . . . . . . . . . . . . . . . 47
4.3.1. APIs von Windows Mobile . . . . . . . . . . . . . . . . . . . . . . 48
4.3.2. APIs von Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.3. APIs von JavaME . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4. Realisierungen auf FMC-Client . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.1. Realisierungsumgebung und Tools . . . . . . . . . . . . . . . . . . 61
4.4.2. Entwicklungstools von Java ME . . . . . . . . . . . . . . . . . . . 61
4.4.3. Entwicklungsumgebung von Symbian . . . . . . . . . . . . . . . . 64
5. Fazit und Ausblick
65
Abbildungsverzeichnis
67
Tabellenverzeichnis
70
Literaturverzeichnis
71
3
1. Einleitung
1.1. Problemstellung
Das Thema der Konvergenz von Kommunikationsnetzen ist heutzutage aktuell wie nie
zuvor. Der Markt für Informations- und Kommunikationstechnologien unterliegt gegenwärtig einem strukturellen Wandel. Die klassischen Netze der Telekommunikation
wurden für die Übermittlung von spezifischen Daten wie Telefongespräche oder reine
Datenpakete geplant und implementiert. Der so genannte Next Generations Network
(NGN)- Trend strebt ein Zusammenführen von heterogenen Kommunikationsnetzen in
ein einheitliches IP-basiertes Netz an. Als ein Teil des NGN ist die Fixed Mobile Convergence (FMC) anzusehen. FMC verbindet Festnetze mit Mobilfunknetzen und versorgt
dabei die Nutzer mit einer besseren Mobilität und Flexibilität. FMC bringt eine Reihe
von Vorteilen auch für Unternehmen und Netzbetreiber mit. Momentan wird in unserem
Fachgebiet eine universelle netzbetreiberunabhängige FMC-Infrastruktur aufgebaut. Die
Hauptbestandteile dieses Systems sind der FMC-Client und der FMC-Server, die in
Zusammenarbeit eine für das Endgerät und das Kernnetz transparente Infrastruktur
bilden, die die Nutzer mit FMC-Diensten versorgt.
1.2. Ziel dieser Arbeit
Im Rahmen dieser Arbeit soll ein FMC-Client für mobile Dual-Mode Endegeräte konzipiert werden. Der FMC-Client soll die GSM- und WLAN-Schnittstelle überwachen
und steuern sowie die Sprache über die jeweilige Netzwerkschnittstelle je nach Umständen oder Nutzereinstellungen leiten. Der FMC-Client soll nahtlos die Sprache von einer
Schnittstelle zu einer anderen umleiten können und in der Lage sein, einen VoIP-Client
zu kontrollieren. Gleichzeitig sollen auch die passende Betriebssysteme und nötige APIs
untersucht und ausgefunden werden, damit der FMC-Client auf mobile Endegeräte integriert werden kann.
4
2. Grundlage
Bevor mit der Analyse der Problemstellung begonnen wird, findet im Folgenden eine
Vorstellung statt, vor welchem Hintergrund die Entwicklung des FMC-Clients erfolgen
kann. Dazu werden NGN und IMS vorgestellt werden, was die Entwicklungsrichtung des
FMC ist. Vorgestellt wird noch Voice over IP. VoIP mit dem Signalisierungsprotokoll
SIP ist dann Schlüsselfunktion für die Realisierung von FMC. Anschließende wird FMC
definiert und die technische Status von FMC kurz eingegangen.
2.1. NGN-Next Generation Network
Die Anforderungen an die Telekommunikationsnetze der Zukunft können mit Stichworten wie „Paketvermittlung “, „textbfMultimedia “, „Investitionsschutz “, „Netzintegration “, „Dienstgüte “, „Offenheit “, „nahtlose mobile Kommunikation “, „Sicherheit und
Datenschutz “ sowie „Anwenderfreundlichkeit “ umschrieben werden. Die meisten dieser
Punkte wurden und werden durch das Konzept Next Generations Network aufgegriffen
und im Hinblick auf eine technische Umsetzung präzisiert. [1]
Die NGN zeichnen sich aus durch:
• ein paketorientiertes Kernnetz für möglichst alle Dienste.
• Da darunter auch Echtzeitdienste wie Telefonie fallen, muss das Netz eine bestimmte Quality of Service (QoS) zur Verfügung stellen.
• Ein besonders wichtiger Punkt, sowohl im Hinblick auf die Kosten als auch die Offenheit für neue Dienste, ist die vollständige Trennung der Verbindungs-/Dienstesteuerung vom Nutzdatentransport.
• Gemäß dem NGN-Gedanken werden alle bestehenden, wichtigen Telekommunikationsnetze, vor allem auch die einen hohen Wert darstellenden, technisch unterschiedlichen Zugangsnetze mit integriert.
• Multimedia-Dienste und daraus resultierend entsprechend hohe Bitraten werden
unterstützt.
5
2. Grundlage
• Die Netzintegration hat nicht nur niedrige System- und Betriebskosten durch
einheitliche Technik, weitgehende Wiederverwendung vorhandener Infrastrukturen, optimale Verkehrsauslastung des Kernnetzes und übergreifendes einheitliches
Netzmanagement zum Ziel, sondern auch Mobilität.
• Integrierte Sicherheitsfunktionen sorgen für den Schutz der transferierten Daten
und des Netzes.
So sieht die Prinzipielle Struktur des NGNs in unterem Bild aus:
Abbildung 2.1.: Prinzipielle Struktur eines Next Generation Networks (NGN)
2.2. IMS-IP Multimedia Subsystem
Das IP Multimedia Substystem (IMS) wurde von 3GPP (3rd Generation Partnership
Project) eingeführt und standardisiert. IMS Dienste basieren auf dem Session Initiation
Protocol (SIP), welches von der IETF
1
entwickelt wurde. SIP kommt somit aus der
Internet-Welt und hat in der Entwicklung viel von Protokollen wie HTTP und SMTP
gelernt. IMS führt eine neue Technologie zur Verbindung unterschiedlicher Netzwerke
ein, und ermöglicht neue Konzepte für mobile Dienste.
1
Internet Engineering Task Force
6
2. Grundlage
IMS stellt ein Framework dar, welches diesen Ansprüchen gerecht wird. IMS integriert
bestehende Daten-, Sprach-, Text- und Videokommunikationsmöglichkeiten über ein einzelnes IP-Netzwerk und erlaubt so die Implementation von IP-basierten multimedialen
Diensten in Netzen der dritten Generation. So wird es möglich, multimediale Kommunikation und andere Anwendungen in IP-basierende mobile Netzwerke zu integrieren.
[2]
2.2.1. IMS Architektur
Die Architektur des IMS ist darauf ausgelegt, verschiedene Netzwelten miteinander zu
verbinden. Es gibt folgende Funktionskompnente:
• Call Session Control Function (CSCF) Die Call Session Control Functions
(CSCF) dienen der Registrierung von Endpunkten, und der weiteren Sitzungsverarbeitung. Der CSCF stellt Interfaces zur Kommunikation mit weiteren logischen
Einheiten des IMS zur Verfügung. Er kommuniziert mit dem Home Subscriber
Server (HSS), um hier auf Benutzerinformationen zugreifen zu können.
• Home Subscriber Server (HSS) Der Home Subscriber Server (HSS) ist die
Datenbank für die registrierten Benutzer. Er hält eine Liste von Funktionen und
Diensten, die der einzelne Benutzer beziehen kann. Er ist verantwortlich dafür, die
aktuelle Adresse des Benutzers (Roaming), unter der dieser zurzeit. erreichbar ist
(z.B. die IP Adresse), zu halten.
• Media Gateway Control Functions (MGCF) Die Media Gateway Control
Function (MGCF) stellt die Möglichkeit zur Zusammenarbeit des IMS Signaling
mit dem Signaling des Public Switched Telephone Networks (PSTN) zur Verfügung.
• Application Server(AS) Der AS kommuniziert mit den Media Servern um die
entsprechenden Gesprächssteuertöne abzurufen. Wenn das Gespräch in das analoge Netz geleitet werden muss, so instruiert der AS den MGCF mittels SIP, den
PSTN TDM Datenfluss in einen IP RTP Datenfluss umzuwandeln und an das
entsprechende IP-Telefon weiterzuleiten.
Das IMS-Framework ist ein mächtiges Instrument, um vor allem multimediale Dienste in
Netzwerken der dritten Generation anzubieten. Es ermöglicht die einfache Implementierung neuer Dienste mittels standardisierter Schnittstellen. Die Vorteile vom IMS liegen
7
2. Grundlage
Abbildung 2.2.: IMS Architektur
hier jedoch deutlich in der IP-basierten Kommunikation; es lassen sich auch bereits bestehende Netze (PSTN) integrieren, der volle Umfang wird jedoch erst dann erreicht
sein, wenn jegliche Kommunikation IP basiert ist. [2]
2.3. VoIP-Voice over Internet Protocol
Unter dem Begriff Voice over IP (VoIP) wird jegliche Übertragung von Sprache über ein
IP-basiertes Netzwerk verstanden. Hierzu wird auch häufig der Begriff Internettelefonie
verwendet. In der Art der Übertragung unterscheidet sich die IP-basierte Übertragung
von Audiodaten grundsätzlich von der herkömmlichen Übertragungstechnik. Hierbei
werden Sprachdaten digitalisiert und wie andere Daten (z.B. E-Mail, Bilder usw.) in
kleine Pakete aufgeteilt und unabhängig voneinander zum Ziel übertragen.
Im Verlauf dieses Sektions wird auf die Grundlagen der zwei wichtigsten Protokolle
bisschen eingegangen, die für die Durchführung dieser Arbeit von Bedeutung sind: SIP
für den Auf- und Abbau von Verbindungen und SDP zur Beschreibung der Sprachdaten
einer Verbindung.
2.3.1. SIP-Session Initiation Protocol
Das Session Initiation Protocol (SIP) wurde als Verbindungs- und Signalisierungsprotokoll zum Auf- und Abbau von Echzeitkommunikationverbindungen in IP-basierten
8
2. Grundlage
Netzwerken von der IETF entwickelt. Aktuell ist SIP im RFC
1
3261 spezifiziert. In
Verbindung mit dem Session Description Protocol bietet SIP die komplette Kommunikationsbasis für den Auf- und Abbau von Echtzeitverbindungen sowie für das Beherrschen einer bestehenden Verbindung. Dabei kann es sich um eine reine Punkt-zu-Punkt
Verbindung als auch um eine Konferenz mehrerer Teilnehmer handeln. Im Rahmen einer
solchen Kommunikation werden sowohl die Teilnehmer- und Signalisierungsinformationen, als auch die zur Codierung bzw. Decodierung eingesetzten Codecs übertragen. SIP
ist dabei einfach zu handhaben und übersichtlich.
Die grundlegenden SIP-Nachrichten sind:
• INVITE: Aufbau einer Session
• REGISTER : Registrierung der Benutzerinformationen
• ACK: Bestätigung der Nachrichten
• CANCEL: Abbruch der Verbindung
• BYE: Beendigung der Session
• OPTIONS: Abfrage von Informationen über Eigenschaften eines Teilnehmers ohne
vorherigen Verbindungsaufbau
Innerhalb eines SIP-Netzwerkes gibt es folgenden Systemkomponenten:
• SIP-User-Agent: IP-Telephone, PCs, Conference-Bridges/SIP-Gateways, das sind
Netzwerk-Knoten, die SIP-Sessions initiieren und terminieren können.
• SIP-Redirect-Server: Server, der SIP-Anfragen annimmt und eine neue Lokation
für die Anfrage retourniert.
• SIP-Stateless-Proxy: Server: der SIP-Anfragen bearbeitet und weiterreicht.
• SIP-(Forking)-Proxy Server: der SIP-Anfragen bearbeitet und weiterreicht.
• SIP-Registrar-Server: der SIP-Register-Anfragen bearbeitet, Abbildung von
Namen auf Adresse.
SIP Adresse
Um die Adressierung des Kommunikationspartners zu vereinfachen, nutzt SIP eine einzige eindeutige Adresse, um einen Nutzer bei der Kommunikation mit anderen Nutzern
oder Anwendungen zu identifizieren, zu registrieren und authentisieren.
1
Request for Comments
9
2. Grundlage
Der User-Teil kann der Name des Benutzers oder seine Telefonnummer sein.Dieser Teil
kann vom Benutzer frei gewählt werden.
Einige Beispiele:
• sip:maat@dc-server.edu
• sip:wolf@141.24.19.66
• sip:+49-171-9897897@141.24.19.66
SIP als Session Protokoll hat sich quasi schon als Standard der Zukunft durchgesetzt.
Dies liegt wohl vor allem an seiner Ähnlichkeit zum HTTP-Protokoll, welches es extrem
flexibel und einfach erscheinen lässt.
2.3.2. SDP-Session Description Protocol
Das Session Description Protocol wurde von der IETF spezifiziert (RFC 2327), um
die für den Aufbau einer Session nötigen Informationen wie z.B. Medientypen (Audio,
Video, Data) und Kontakt-Adressen (für die Übertragung der Sprachdaten) sowie die zu
verwendenden Codecs zu beschreiben. Das SDP kann zur Beschreibung von Sitzungen
aller Art im Internet verwendet werden. Es ist wie SIP ein text-basiertes Protokoll und
wird im Message-Body der SIP-Nachrichten übertragen.
Das SIP-Protokoll kann SDP-Nachrichten verarbeiten, da diese u.a. die Codierungen
und die Übertragungsparameter beinhalten. Eine INVITE-Nachricht enthält ein SDPFeld, welches die für die anrufende Partei akzeptablen Sitzungsparameter beinhaltet. In
der Antwort des Angerufenen werden seine Fähigkeiten beschrieben.[3]
2.3.3. VoWLAN-Voice over WLAN
Hinter VoWLAN verbirgt sich die Integration von Techniken wie VoIP, das Session
Initiation Protocol (SIP) und WLANs nach IEEE 1 802.11 in der Version 802.11e, das
Dienstgüten (QoS) unterstützt. VoWLAN ermöglicht VoIP Kommunikation in der WiFi-Netzwerk-Umgebung.
Voice-over-WLAN ist deshalb interessant, da sich damit mittels Laptop, PDA oder
WLAN-Telefon an jedem beliebigen WLAN-Hotspot oder Access-Point telefonieren lässt.
Damit überschreitet man erstmals die Grenze der schnurlosen Telefonie, die einen trotz
1
Institute of Electrical and Electronics Engineers
10
2. Grundlage
Funktechnik an einen festen Standort bindet. Nachteil ist natürlich, dass WLAN im Vergleich zu GSM oder UMTS nicht flächendeckend zu Verfügung steht. Eventuell müssen
an öffentlichen Hotspots Zugangsgebühren bezahlt werden, Der anfänglich angenommene Kostenvorteil ist dann schnell dahin.[4]
2.4. FMC-Fixed-Mobile Convergence
2.4.1. Was ist FMC
Die Verbreitung und Nutzung von Mobilgeräten ist seit ihrer Erfindung vor etwas mehr
als 20 Jahren exponentiell gestiegen. 2010 werden Schätzungen zufolge nahezu 80% der
erwachsenen Weltbevölkerung ein Mobilgerät besitzen. Bedeutender noch als der enorme Anstieg der Mobilfunkteilnehmer ist die stetig ansteigende Nutzungsdauer (MoU,
Minutes of Use) - häufig zu Lasten der herkömmlichen, preiswerteren Festnetztelefonie.
Der Trend zum Wechsel vom Festnetz- zum Mobiltelefon (FMS, Fixed-Mobile Substitution) ist nicht auf Kostengründe, sondern auf Bequemlichkeit zurückzuführen. Der
Lösungsweg ist dann FMC, der sogenannte Fixed-Mobile Convergence.
Das FMC-Konzept sorgt für einen transparenten Zugang zu Multimedia Applikationen
von einer Vielzahl von Endegeräten aus und bietet gleichzeitig ein Roaming zwischen
WLAN- und Handy-Netzen. FMC soll dem Teilnehmer ein konsistentes Nutzungserlebnis unabhängig von Standort und Tageszeit und ohne Dienstunterbrechung beim
Wechsel zwischen Fest- und Mobilfunknetz vermitteln. Ziel der FMC ist es, den Widerspruch aufgrund der Fragmentierung unserer Kommunikationskanäle aufzulösen und
mehrere Kanäle (Netzwerke) als einen einzigen Kanal erscheinen zu lassen, um damit
den eigentlichen Wert der Kommunikation wiederherzustellen - bessere Produktivität
und Erreichbarkeit. Die mögliche Ergänzung vorhandener Mobildienste durch innovative VoIP Fähigkeiten und kostengünstigen WLAN-Zugang ist sowohl für Unternehmen
als auch für Mobilnetzbetreiber von Interesse. FMC-Lösungen setzen die Verfügbarkeit
moderner „Dualmodus“-Handsets voraus. [5]
Es gibt zwei Entwicklungsrichtungen für FMC-Lösungen:
• SIP over Wi-Fi
• UMA-Unlicensed Mobile Access
Die zwei Techniken werden in den nächsten Kapitel noch genauer eingegangen. In dieser
Arbeit soll SIP over Wi-Fi verwendet werden.
11
2. Grundlage
Abbildung 2.3.: FMC-Struktur
2.4.2. Vorteile von FMC
Hauptmerkmale von FMC sind:
Endgeräte-Mobilität
Die Endegeräte-Mobilität erlaubt es dem Teilnehmer, sein persönliches Endgerät überallhin mitzunehmen und es dort zu benutzen, wo er sich gerade aufhält.
Dienste-Mobilität
Die Dienste-Mobilität stellt dem Telekommunikationsteilnehmer einen Satz konsistenter
Dienste zur Verfügung, und zwar unabhängig vom Endgerät, vom Zugangsnetz und dem
Aufenthaltsort.
persönliche Mobilität
Die persönliche Mobilität gewährleistet, dass der Teilnehmer überall unter einer Rufnummer zu erreichen ist. Letzteres umfasst das Roaming zwischen den verschiedenen
Netzen und die Bereitstellung derselben konsistenten Dienste in den verschiedenen Netzen. [14]
Wenn man von Spezifizierung betrachten, FMC bietet folgendes:
• ein Dualmodus-Gerät mit
• einer Nummer,
• einem Adressbuch und
• einer Voice-Mailbox,
• das immer die Netzverbindung zum günstigsten Preis nutzt.
12
2. Grundlage
Mit dem Einsatz von Dualmodus-Geräten macht FMC es möglich, im Büro, zu Hause
oder an einem öffentlichen Hotspot die kostengünstigere Highspeed-Verbindung und
unterwegs die Bequemlichkeit vorhandener Mobilfunknetze zu nutzen.
2.4.3. Technischer Status von FMC
Die Konvergez aller Telekommunikationsdienste auf Basis von IP ist schon kein neues
Thema. Carrier, Provider und Enterprises versuchen damit die auf einen Dienst zugeschnittene Infrastrukturen durch eine vereinheitlichte Netzinfrastruktur - für jede Anwendung - zu ersetzen. Dies resultiert heute in den Konvergenzsystemen von Sprache
und Daten in den Unternehmen (IP Telephonie), dem Angebot von Consumer VoIP
Services und den Digital Subscriber Line (DSL) Services der Carrier. Auf Basis von
FMC werden jetzt auch die Services der unterschiedlichen Kommunikationswelten (Mobilkommunikation und LAN-Kommunikation) vereinheitlicht. Hierzu wird ein Roaming
zwischen den Mobilfunknetzen und den WLANs in den Unternehmen implementiert. In
seiner endgültigen Form führt FMC die zur Verfügung stehenden Netze und die entsprechenden Managementfunktionen zusammen.[6]
Eine solche Migration erfolgt in der Regel in mehreren Schritten. Die Bereitstellung
der Konvergezservices durch die Carrier beginnt allgemein damit, dass der Carrier einfach nur seine Services bündelt. Erst in weiteren Migrationsschritten erfolgt die echte Integration der Netzinfrastrukturen und der Vereinheitlichung der Support- und
Managementfunktionen.[6]
Der erste Migrationsschritt beginnt mit der Bündelung der Services und lässt sich ohne jede Integration der bestehenden Netze realisieren. Hierbei werden nur die unterschiedlichen Kunden-Interfaces zusammengeführt (zentraler Ansprechpartner, integrierte Support- und Helpdesk-Funktionen und eine einheitliche Abrechnung für mobile- und
Standard-Services). Die Evolution in Richtung FMC Services durchläuft jedoch folgende
fünf Schritte:
Phase 1: Konvergenz der Netzinfrastruktur. Der Carrier konsolidiert seinen Sprachverkehr mit Hilfe von VoIP auf seinem IP WAN und die Enterprise beginnt mit der
Realisierung von IP Telefonie.
Phase 2: Integration von WLANs und Voice over WLAN in den Enterprises. Die flächendeckende WLAN Infrastruktur in den Unternehmen bietet den Netzbetreibern die
Möglichkeit, die mobilen Nutzer im Bereich der Datenkommunikation an das Unternehmensnetz anzubinden.
Phase 3: Einführung von FMC Services. Die Carriers bieten ihren Kunden die ersten
13
2. Grundlage
Abbildung 2.4.: Zeitliche Abfolge der Evolutionsschritte für FMC Services
FMC Services an indem die mobilen Nutzer mit der Möglichkeit zum problemlosen Roaming zwischen den Mobilfunknetzen und den in den Unternehmen installierten sprachfähigen WLANs ausgestattet werden. Hierzu werden Dual-Mode Handys oder mit Wi-Fi
und Mobilfunk ausgestattete PDAs genutzt.
Phase 4: Integration der mobilen und festgeschalteten Netzinfrastrukturen und der
Backoffice Systeme. Die FMC Carrier und deren Partner konsolidieren in diesem Stadium die Netzsignalisierung und die Backoffice Systeme indem die früher getrennt geführten Signalisierungskanäle vereinheitlicht werden.
Phase 5: Bereitstellung voll integrierter FMC Applikationen. Auf Basis einer vollständig integrierten Multimediainfrastruktur wird eine Unterstützung aller Informationtypen, Endegeräte und Zugangstechnologien möglich. Die FMC Provider konzentrieren
sich in dieser Phase auf die Entwicklung neuer Applikationen und Services. Die Provider sind in der Lage, die Services - Sprache, Audiokonferenzen, Video, Videokonferenzen,
Instant Messaging, eMail, Spiele, SIP-basiertes Conferencing und Collaboration, Videound Audio-Broadcasting - miteinander zu bündeln und individuell auf den Kunden zugeschnittene Applikationen bereitzustellen. [6]
14
3. FMC-Client
In diesem Kapitel geht es mehrheitlich um das Konzept des FMC-Clients und dazu die
entsprechende Realisierungsvorgänge und -methoden. Es gibt schon bestehende FMCSolution, die so genannte UMA basierte FMC und die IMS-VCC1 basierte FMC, die
eigene Vorteile haben. Gemäß der zwei Techniken haben viel Firmen verschiedene Lösungswege und Produkte entwickelt. Durch Vergleich und Analyse von FMC-Konzept
der jeweiligen Firmen soll die Anforderungen an des FMC-Clients hergestellt werden.
Das endegültige konzipierte FMC-Client soll in der Lage sein, die hergestellte Anforderungen aufzufüllen.
3.1. Technische Realisierung von FMC-Client
Für FMC-Client steht Dualmodus-Mobiltelefone zuerst daran. Ein Dualmodus-Telefon
ist ein Mobiltelefon, das außer Mobilfunk (GSM, CDMA, W-CDMA) auch IEEE 802.11Funk (WiFi) für die Sprach- und Datenkommunikation unterstützt. An festen Standorten - Büro und Campus, Hotspot und Wohnung - stellt das Gerät eine preiswerte
VoWLAN-Verbindung her. Wird das Signal schwächer, wird die Verbindung automatisch auf ein Mobilfunknetz mit größerer Reichweite verlegt. Dazu braucht man ein im
Dual-Mode-Gerät integriertes FMC-Client, um die von oben erwähnte Situationen zu
steuern.
Mit dem FMC-Client des Dual-Mode-Geräts können die Nutzer dann auf sämtliche Kommunikationskanäle und Message-Boxen zugreifen und ihre persönliche Kommunikationszentrale von jedem Ort der Welt aus steuern. Dabei geht es nicht nur um Funktionen wie
mobile E-Mail oder Instant Messaging. Viel wichtiger ist die mobile Präsenz-Funktion,
mit der der Nutzer unterwegs den persönlichen Präsenz-Status beziehungsweise seine
Erreichbarkeit einstellen kann.
1
Voice Call Continuity
15
3. FMC-Client
Die zurzeitige bestehende dual-mode Handover Technologie von FMC sind UMA und
IMS-VCC. UMA ist der globale 3GPP1 -Standard für die Zusammenführung von Mobilkommunikation und Wi-Fi, der Mobilfunkteilnehmern über Multi-Mode-Mobiltelefone
das Roaming und den Wechsel zwischen Mobilfunknetzen und WLANs ermöglicht. IMSVCC ist dann mehr in der Richtung IP Multimedia Service und die zukünftige mobile
Telefonie gedacht.
3.1.1. UMA basierte FMC
Unlicensed (unlizenziert) heißt in diesem Zusammenhang, dass weder Mobilfunkkunde noch Netzbetreiber Lizenzen für den Betrieb zahlen müssen, im Gegensatz zum
klassischen Mobilfunk, bei dem die Netzbetreiber Lizenzen für die GSM- oder UMTSFrequenzen haben müssen. UMA ist nicht eine einfache VoIP über WLAN/Bluetooth
Verbindung (VoWLAN), sondern der Standard erlaubt auch Handover und Roaming,
also die Übernahme von laufenden Gesprächen.
Bucht sich ein Endgerät in lizenzfreie Netze ein, zum Beispiel WLAN, dann wird die
Verbindung zum Kernnetz des Mobilfunkbetreibers über den Breitbandanschluss und
das Internet hergestellt. Dafür sind herkömmliche Access-Points, Router und Modems
ausreichend. Bei dieser Technik wird jedoch ein UMA Network Controller (UNC) benötigt, der in jedem WLAN präsent sein muss und vom Provider betrieben wird. Der
Vorteil für den Provider liegt darin, dass Mithilfe des Controllers die Authentifizierung
sowie Abrechung der Verbindungskosten problemlos möglich ist. Der Nachteil für den
Benutzer ist, dass er nicht frei in der Wahl des WLANs ist, sondern nur solche seines Providers benutzen kann. Mit UMA sollen bestimmte Qualitätsmerkmale für diese
lizenzfreien Netze sichergestellt werden.[7]
• Die UMA-Technik unterstützt die reibungslose Übergabe von Sprach- und Datenverbindungen zwischen GSM, GPRS und WLAN.
• Handys, die neben GSM und GPRS auch WLAN unterstützen und automatisch
auf einen Hotspot umschalten können. Handy-Nutzer sollen so automatisch über
das kostengünstigste Netz telefonieren.
• Für diese Technik ist zwingend ein WLAN-Chip mit sehr niedrigem Stromverbrauch. Auch muss für UMA ein Client auf dem UMA-Handy installiert sein.
1
3rd Generation Partnership Project
16
3. FMC-Client
UMA Network Controller (UNC)
Die Schlüsselkomponente von UMA ist der UMA Network Controller (UNC). Das UMC
hat folgende Funktionen:
• Unterstützung privaten Kommunikationen über IP Netzwerk zwischen MS und
das Service Provider Corenetzwerk.
• Anbieten Service wie Registration Redirection, um mit dem MS zu kontaktieren.
• Relay higher-layer-stations und GSM/GPRS Corenetzwerk Kontrolsignal.
• Emulation Paging, Handover und ähnliche Radio Access Prozedure für UMAN
Mobile Access.
• Anbieten standards-compliant A und Gb Interfaces.
Nachteile:
• Verwendung kein Session Initiation Protocol
• Einschränkung bei Unterstützung von Data Services
• UMA ist kein echte Voice over IP , sondern eine zu VoIP gleichberechtigte Technik
unter dem Sammelbegriff Voice-Konvergenz.
• Schlechte Erweiterbarkeit in Richtung von IMS-Service
3.1.2. IMS-VCC basierte FMC
Voice Call Continuity ist eine von 3GPP definierte Spezifikation. Es ist eine FMC Technologie und bietet Seamless Handover zischen dem cellularen Netzwerk und dem VoIP
unterstützenden Access Netzwerk.
Der Schlüsselkomponent von der Solution ist die Verwendung eines VCC ApplicationServers zu IMS-Netzwerk. Das Server steuert Session von VCC-Benutzer Seamless Handover zwischen WiFi und GSM. [8]
Vorteile:
• Unterstützung von IMS multimedia Services
• Seamless Handover von Voice-Call zwischen Circuit-switched Domain und IMS
• Seamless Integration mit anderen VoIP Netzwerke
17
3. FMC-Client
Abbildung 3.1.: VCC-Client Struktur
VCC-Client
Ein VCC-Client ist ein in Dual-Mode Handys installiertes Client-software, das IMS
basierte FMC-Service steuert. Die von 3GPP getellte Clientstruktur sieht so aus: Es
beteht aus folgende Hauptbestandteile:
• Network Domain Selector
• Network Domain Preferences
• Voice Call Control Function
• SIP PS Network Interface
• Mobile CS Network Interface
Network Domain Selector
• Verbindet direkt mit zwei Netzwerke Interfaces
• Entscheidet welche Domains registriert werden soll
• Entscheidet welche Netzwerk Domains nutzbar sind, um eine Verbindung zu initiieren
• Entscheidet wann Handover triggern während eine Verbindung soll
Network Domain Preferences
• Speichert die Informationen von Network-Domains
18
3. FMC-Client
• Arbeitet mit dem Network Domain Selector und Voice Call Contol Function zusammen
Voice Call Control Function
• Trägerfunktion von Originate oder Terminate Calls zwischen Netzwerk Interface
und User Interface
• Koordinierung des Handover von Calls zischen Netzwerke Domains
SIP PS Network Interface
• Netzwerk Interface von paket-switched Domain
Mobile CS Network Interface
• Netzwerk Interface von circuit-switched Domain
IMS-Client
IMS-Client ist eine umfassende Lösung für die Multimedia-Kommunikation über IPNetzwerke. Es bietet Funktionen wie IP-TV, Web-Service, Multimedia Services usw.
JSR-281 bringt schon alles durch standardisierte Java Technologie API zusammen.
NetFront IMS Client Package Ist eine umfassende Lösung für IMS-Anwendungen
NetFront IMS Client Package ist ein Software-Paket für die Multimedia-Kommunikation
über IP-Netzwerke. NetFront IMS Client Package bietet eine effiziente Lösung für die
Kommunikation zwischen Endanwendern, aber auch für den Zugriff auf Geräte oder
Dienstleistungen über Mobiltelefone der nächsten Generation. NetFront IMS Client
Package enthält SIP/Presence/PoC (Push-to-talk over Cellular)/IM (Instant Message)Module, die den 3GPP- und OMA (Open Mobile Alliance)-Standards entsprechen. NetFront IMS Client Package enthält außerdem eine große Vielfalt an Modulen, die FMC
(Fixed Mobile Convergence)-Dienste unterstützen, welche die mobile Welt mit der PC
Internet-Welt und der CE (Consumer Electronics/Verbraucherelektronik)-Welt integrieren. [9]
NetFront IMS Client Package ist ein integriertes Paket und enthält die folgenden Module:
• NetFront SIP Client: Das SIP-Modul, das ein Basisprotokoll für IMS-Kommunikation
darstellt. Enthält die User-Agent-Funktion auf der Grundlage der IETF RFCSpezifikation.
• NetFront Presence Client: Mit OMA übereinstimmendes Presence-Modul. Enthält
die Presence-Engine und API.
19
3. FMC-Client
• NetFront PoC Client: Mit OMA übereinstimmendes PoC-Modul. Enthält die PoCEngine und API.
• NetFront VoIP Client: VoIP-Engine, die den Standard-Voice-Codec unterstützt, z.
B. G.711, G.722 und AMR-WB (enthält API).
• NetFront IM Client: Mit OMA übereinstimmendes IM-Modul auf der Grundlage
von MSPR (Message Session Relay Protocol). Enthält die IM-Engine und API.
Erweiterbar für die Unterstützung von P2P-File-Sharing durch MSRP.
Die Vorteile von NetFront:
• Reduziert die Kosten und Zeit für das Portieren durch die gemeinsame Nutzung
der normalen Portierungsschicht von NetFront (SLIM Peer)
• Reduziert die erforderliche Gesamtspeichergröße durch die gemeinsame Nutzung
der NetFront-Bibliotheken, z. B. der XML- und HTTP-Bibliotheken
• Unterstützt die Integration mit anderen Anwendungen, inklusive NetFront Browser und Mailer-Anwendungen
3.1.3. Vergleich UMA und IMS-VCC
Die beide Techniken haben seine eigene Vorteile. Obwohl UMA einfach und leicht zu
realisieren ist, ist es keine langfristige Lösung wegen der Einschränkungen von seinem
QoS, Kapazität und non-SIP usw.
Das VCC unterstützt bidirektionale seamless Handover zwischen der IMS und CSDomains. Als Anwendung in der IMS-Domain, VCC ermöglicht viel andere IMS-Service
wie Multimedia, höhere Bandbreite usw. VCC ermöglicht noch die Benutzer zwischen
verschiedene Netzweke, wie CDMA, GSM, UMTS, PSTN, Breitband-Festnetz, WiFi
und WiMAX wechseln. Die bessere Erweiterbarkeit und Intergierbarkeit in der Richtung 3G zeigt, dass es der beste Lösungsweg, Dual Mode Handover zu implementieren.
Deshalb soll auch Konzept des FMC-Clients mehr in der Richtung IMS-VCC gehen.
3.2. Bestehende FMC-Lösungen von verschiedenen
Firmen
(1).Kineto
Kineto Wireless ist ein herausragender Innovator und führender Anbieter der UMA-
20
3. FMC-Client
Technologie (Unlicensed Mobile Access), des 3GPP-Standards für die Mobil-/Wi-FiKonvergenz. Mit einem UMA-Netzwerk können Mobilanbieter eine nahtlose, performante Nutzung von Voice-, Daten- und IMS-Diensten in Mobilfunk- und Wi-Fi-Netzen
ermöglichen. Als führender Anbieter von UMA-Technologie liefert Kineto Core-NetzLösungen über OEM-Partnerschaften mit großen Netzinfrastruktur-Anbietern. Kineto bietet darüber hinaus UMA-fähige Software, Entwicklungstools und Supportleistungen.
Kineto UNC Subsystems
Die individuelle Subsysteme von UNC bietet die spezielle Funktionen innerhalb UMA
an.
• Packet Data Gateway - PDG
Das PDG bietet sicheren Zugang zu Corenetzwerk aus dem öffentlichen IP-Netzen.
Es arbeitet mit dem AAA-Servers zusammen, um die Authentifizierung und Autorisierung durchzuführen.
• IP Network Controller - INC
Der IP Network Controller (INC) bedient sich als Softswitch in UNC Architektur.
Er verwaltet die Subscriber-Access zu allen Voice- und Data-Service.
• Media Gateway - MG (optional)
Das Media Gateway ist ein optionales Element von UMA und es ist nur im Einsatz
für Unterstützung von TDMA Interface
Kineto UMA/GAN Client
• Intergration in Dual Mode Device
• Integration in Radio Resource Schicht und Ermöglichung kompletten Service Transparenz
• Unterstützung 802.11 und Bluetooth Devices
• Initierung IP Tunnel über IP-Netzwerk, um mit UNC zu Kontaktieren
Zwei wichtige Module im Client sind dann IP Adaptor Module und Core Module.
• IP Adaptor Module
Der IP Adaptor Module befindet sich auf dem IP Subsystem. Er kontroliert den
IP Tunnel und übergibt die UMA Messages. Er bietet noch die Interface mit TCP,
UDP, Wi-Fi und Voice-Verbindung.
21
3. FMC-Client
• Core Module
Der Core Module befindet sich auf dem zellularen Subsystem und integriert mit
dem zellularen Baseband, er bietet dann UMA-Funktion und interagiert mit dem
zellularen RR/RLC/RRC Schichte.
Abbildung 3.2.: UMA-Client von Kineto
(2).FirstHand
Die FirstHand Technologies bietet eine enterprise-centric, fixed-mobile convergence (FMC)Lösung für Telefonie-Service im Unternehmen mit „single number “ nahtlose Konnektivität über Zell-und/oder WiFi-Netze. Die Lösung ermöglicht „Unternehmen-Kommunikation
überall “.
Diese FMC-Lösung beinhaltet ein Mobility Gateway und ein Mobile Client, das sogenannte Mobile Console UC.
Gateway Software
Das Mobility Gateway ist ein "Data Gatewayünd arbeitet mit dem Mobile Console UC
Sofware Client auf dem zellulare Netzwerke und Unternehmensnetzwerke zusammen.
Man kann durch Verwendung von der Web-basierten Benutzerinterface des Mobility
Gateways das Serverprozesse starten, stoppen und neu laden.
Client Software
Die FirstHand Mobile Console UC ist eine Unified Communications Mobile. Das Client
software wird auf ein Dual-Mode(WiFi/cellular) Endegerät(mit Windows Mobile 5 oder
6 als Betriebssystem ) instaliert und verwendet.
Merkmale:
• Session Mobilität
• Ereichbar mit einem Nummer
22
3. FMC-Client
• Presenz Status
• Spezielle Power-Saving Mode
• Manuelle und automatische Netzwerke-Selektion Mode
Anforderungen:
• Windows Mobile 5.0 und Symbian (Nokia, Ericsson devices)
• IP PBX (CPE or hosted)
• Dual Mode oder WiFi Device
• IEEE802.11 a/b/g Netzwerke
• CDMA/GSM
(3).Satelco AG
Teleserver Mobile Pro bindet jedes beliebige Mobiltelefon als Nebenstelle in das Firmennetz ein. Alle Büroanrufe können wahlweise am Mobil-, Festnetz oder IP-Telefon
angenommen bzw. initiiert werden.
Mobile Mitarbeiter sind somit unter einer einzigen Geschäftsnummer (Büro - Festnetznummer) erreichbar und handlungsfähig. Dabei stehen alle Komfortfunktionen der Nebenstelle auch am Mobiltelefon zur Verfügung.
Merkmale:
• Apparatewechsel während eines Gesprächs
• Alternative zu aufwändigen DECT-Lösungen
• Einbindung von privaten Handys
(4).Agito
Das RoamAnywhereTM Mobility Router und Agito RoamAnywhereTM Client bieten die
Lösung, wie die Mobile Devices zwischen WiFi und zellulare Netzwerke problemlos routen. Die Lösung beinhaltet ein Agito RoamAnywhereTM Mobility Router auf dem Netzwerk und RoamAnywhereTM Client auf dem Mobile Device.
Merkmale:
• Location-Aware Handover
• Common Sense Best Practices
• Batterie Ersparnis
• Enterprise PBX Integration
23
3. FMC-Client
Agito Networks RoamAnywhereTM Mobility Router
Das RoamAnywherTM Mobility Router bedient Mobilisierung von Voice und Data Appliktion für WLAN, Cellular, IP Telefonie und Location Technologie. Es verwendet
„patent-pending “ Lokation Technologie, um die Benutzer „in-building“ oder außerhalb
des zellularen Netzwerk genau zu determinieren.
Der RoamAnywhereTM Client
Der RoamAnywhereTM Client ist momentan von Nokia/Symbian Mobile Endegeräte unterstützt, Nokia eSeries und nSeries. Später wird auch von Windows Mobile 5 unterstützt.
(5).Comdasys
Das Comdasys FMC Solution besteht aus einem FMC Server und einem FMC Client.
Sie bieten eine Reihe Vorteile von FMC für die Benutzer.
Das Comdasys FMC Server
Das FMC Server ist ein all-in-one Netzwerkinstrument und beinhaltet ein Multi-Service
Router, ein Session Border Controller mit Sicherheitsverstärkung, QoS und FMC Voice
Applicationen. Das Server ist im Einsatz auf der zentralen Seite im Unternehmen oder
auf ein Service Provider. Es befindet sich auf dem Wireless Netzwerk zwischen WLAN
und SIP-Switch. Das Server steuert noch die die Sessions von mobile Endegeräte, egal
die im Unternehmen, zuhause oder auf dem zellularen Netzwerk sind.
Das Comdasys FMC Client
Das FMC Client ist ein Software, es integriert auf ein Mobile Device und arbeitet mit
dem FMC Server zusammen.
(6).Cicero Networks
Cicero Networks ist einer der führenden Anbieter von Lösungen für VoIP Fixed Mobile
Convergence, und es ist allgemein der Auffassung, dass diese ihre neuesten Produkt CiceroPhone treffen groß mit Smartphone-Nutzer und unterstützt seine erwartet, dass für
die anderen Marken des Smartphones kommt früher als später.
CiceroPhone ist ein Dual-Mode-FMC-Client für Smartphones PDAs und auch PCs, es
ermöglicht die nahtlose Roaming zwischen WLAN und Mobilfunk-Netze. Anrufe werden
automatisch über die beste verfügbare Netzwerk-, Wi-Fi oder zellulare die Schaffung
eines einheitlichen und sehr intuitive Benutzeroberfläche. Die eingebaute Intelligente
Routing-Regeln wird sichergestellt, dass Kosten und Qualität optimiert werden in allen
Situationen. In Zusätzlich ermöglicht CiceroPhone Routing-Entscheidungen zu optimieren am Mobilteil für bestimmte Nummern oder Nummernbereiche für spezifische Netze.
Merkmale:
24
3. FMC-Client
• Multi-Mode Softphone
• Interoperable Client Platform
• Wi-Fi/3G/Cellular roaming
• Automatisch Publik Hotspot Login
• Monitoring Wi-Fi/Cellular Signalstärke
• Aktivierende VCC
(7).Siemens AG
HiPath MobileConnect ist eine FMC-Anlage für Unternehmen, die Festnetz-VoIP,
VoWLAN und Mobilfunknetze nahtlos zusammenführt und vereinheitlicht. HiPath MobileConnect stellt heute auf dem Markt die umfassendste Erweiterung der Unternehmenskommunikation in das Mobilfunknetz dar. HiPath MobileConnect ist die einzige End-to-End-Lösung, die wirklich eine Rufnummer, eine Mailbox und nahtloses Roaming bereitstellt, für gesteigerte Produktivität, höheren Komfort und verringerte Netzkosten. Durch den Einsatz von HiPath MobileConnect in einer einzigen, einheitlichen
Kommunikations-Infrastruktur werden Aufwand und Komplexität von Verwaltung und
Management dramatisch verringert.[10]
HiPath MobileConnect basiert auf offenen Standards und kann praktisch bei jeder SIPbasierten IP-Telefonanlage, jedem WLAN und jedem Dual-Mode-Endgerät verwendet
werden. Siemens hat HiPath MobileConnect mit der IP-Kommunikationsplattform HiPath 8000, der HiPath Wireless-LAN-Lösung und ausgewählten Dual-Mode-Endgeräten
zertifiziert. Tests mit anderen Plattformen und Endgeräten werden gerade durchgeführt.[10]
HiPath MobileConnect besteht aus zwei Elementen:
MobileConnect Appliance
Die MobileConnect Appliance ist der IP-basierten Telefonanlage des Unternehmens und
dem Wireless LAN (WLAN) zwischengeschaltet. Sie überwacht kontinuierlich die DualMode-Endgeräte und steuert die Telefonate - unabhängig davon, ob sich die Nutzer
im Unternehmensnetz oder außerhalb des Unternehmensgeländes im öffentlichen Netz
befinden. Durch Identifizierung und Auswahl des günstigsten zur Verfügung stehenden
Netzes werden Telefonkosten gesenkt.
MobileConnect Client
Das Software Client befindet sich im Dual-Mode-Handset und arbeitet mit der MobileConnect Appliance-Box zusammen, um ein nahtloses Handover zwischen dem Wireless LAN des Unternehmens und dem Mobilfunknetz zu gewährleisten. Auf diese Weise
25
3. FMC-Client
können Telefonate, die beispielsweise beim Verlassen des Büros angefangen wurden,
auch nach Verlassen des Unternehmensgeländes weitergeführt werden, ohne dass die
Gesprächspartner vom Netzwechsel Notiz nehmen.
Funktionsweise
Die MobileConnect-Anlage befindet sich auf dem zentralen Firmennetz-werk neben der
SIP-Telefonanlage. Wenn ein Dualmode-Gerät, das die MobileConnect-Clientsoftware
installiert hat, das Firmen-WLAN erreicht, registriert sich das Gerät automatisch bei der
MobileConnect-Anlage, die wiederum den Benutzer als SIP-Client auf der Telefonanlage
des Unternehmens registriert. An diesem Punkt werden alle Anrufe vom oder an das Gerät des mobilen Benutzers als SIP-Anrufe unter Nutzung der WLAN-Infrastruktur durch
die Telefonanlage geroutet. Der MobileConnect-Client erkennt, wenn er den WLANAbdeckungs-bereich verlässt, und teilt der MobileConnect-Anlage mit, dass er in das
Mobilfunknetz wechselt. Ist der Benutzer während dieses Vorgangs in einem Gespräch,
initiiert die MobileConnect-Anlage einen Mobilfunkanruf an das Gerät des Benutzers,
und der Anruf wird transparent vom Firmennetz zum Mobilfunknetz übergeben. MobileConnect nutzt Anwesenheits-Informationen. Wenn ein mobiler Benutzer auf dem
Mobilfunknetz ist, erkennt die MobileConnect- Anlage den nicht lokalen Status des Benutzers und leitet daher ankommende Anrufe automatisch durch die Telefonanlage hinaus zum Mobilfunknetz. Auf diese Weise muss nur die Nummer des mobilen Benutzers
in der Telefonanlage des Unternehmens gewählt werden, um ihn jederzeit und überall
erreichen zu können.[10]
3.3. FMC-Clientarchitektur
FMC-Client als ein Teil von FMC-Netzwerk arbeitet mit dem FMC-Server zusammen.
Es wid in einem Dual-Mode Endgerät integriert. Das Client hat die Aufgabe, Handover
zwischen verschiedene Netzwerke zu steuern, Anrufe von entweder GSM oder VoWiFi zu
initiieren und zu beenden usw. Jetzt wird die Fähigkeiten, Funktionalitäten und Anforderungen untersucht und analysiert, eine Client-Struktur soll als Vorschlag hergestellt
werden.
3.3.1. Analyse der Anforderungen an FMC-Client
In den Subsection 3.1. und 3.2. werden bestehende Techniken von FMC besonders auf
dem Hinblick Clientseite und auch die FMC-Lösungen von verschiedenen Firmen vor-
26
3. FMC-Client
gestellt. Wie vorher schon erwähnt hat, das Konzept von FMC soll in der Richtung
IMS-VCC kommen. Deshalb soll das FMC-Client solche Anforderungen haben:
• Automatisch Dual Registration Mode, Automatisch Anmeldung an einer WLANZugangsschnittstelle
Mit Verwendung von dem Client soll das Endgerät in der Lage sein, gleichzeitig
in GSM Netzwerk-Domain und WiFi PS-Domain registriert werden kann.
• Internet Telefonie
Nachdem Registrierung in PS-Domain kann das Endgerät unter einem bestimmten
Funkbedingung Anrufe initiieren und beenden.
• Seamless Handover zwischen GSM und WiFi, manual/automatisch Netzwerkeselektionsfunktion
Das Endgerät soll außer GSM auch WiFi für die Sprach- und Datenkommunikation unterstützt. An festen Standorten - Büro und Campus, Hotspot und Wohnung - stellt das Gerät eine preiswerte VoWLAN-Verbindung her. Wird das Signal
schwächer, wird die Verbindung automatisch auf ein Mobilfunknetz mit größerer
Reichweite verlegt.
• Single Number Service
Mit dem Single Number Service sind Telefon, Fax und Voicebox jedes Benutzers
über eine einzige Rufnummer erreichbar. Eingehende Anrufe werden direkt an
den Empfänger geroutet oder - sollte dieser einmal nicht erreichbar sein - in sein
Voicemail-System.
Dort kann sich der Anrufer weitervermitteln lassen oder eine Nachricht hinterlassen. Die hinterlassenen Nachrichten können unabhängig von Ort und Endgerät
über den PC, Handy oder PDA abgerufen werden.
• Überwachung von Netzzugangsschnittstelle
Die Netzzugangsschnittstellen sollen von dem Client überwacht werden, damit ist
zu entscheiden, welche Netzwerke verwendbar sind.
• WLAN-Verbindung zu aktivieren und deaktivieren
Das Client kann sich selbe entscheiden, ob die WLAN-Verbindung aktiviert oder
deaktiviert werden soll.
• Verwendung von VoIP-Client
Mit Verwendung von VoIP-Client kann man auf einem WiFi-fähigen Endgerät
Zugriff auf die VoIP-Funktionen nehmen . D.h. , dem Nutzer erlaubt Gespräche
über das Internet zu führen.
27
3. FMC-Client
• Anrufe über Mobilfunknetz zu initiieren und zu beenden
Natürlich soll das Client auch in der Lage sein, die normal GSM-Service zu bieten.
3.3.2. Realisierungsmethoden gemäß Anforderungen
Um die entsprechende Anforderungen aufzufüllen, soll verschiedene Methoden und Techniken eingesetzt werden. Jetzt fasse ich alle Anforderungen zusammen:
• Überwachung von Netzzugangsschnittstelle
• Automatisch Anmeldung an einer WLAN-Zugangsschnittstelle
• WLAN-Verbindung zu aktivieren und deaktivieren
• Automatisch Dual Registration Mode
• Seamless Handover zwischen GSM und WiFi, manual/automatisch Netzwerkeselektionsfunktion
• Verwendung von VoIP-Client, Internet Telefonie
• Anrufe über Mobilfunknetz zu initiieren und zu beenden
1.Überwachung von Netzzugangsschnittstelle
Die Überwachung von Netzzugangsschnittstellen ist die Singnalstärke verantwortlich.
Dafür wird ein Received Signal Strength Indicator eingesetzt. Das RSSI stellt einen Indikator für die Empfangsfeldstärke von WLAN dar. Durch Verbindung mit einer Messinstrument wird die RSSI für verschiedene WLAN-Status angezeigt. Die Signalstärke
soll periodisch gemessen werden, um die WLAN-Status zu aktualisieren, damit ist zu
entscheiden, ob es verwendbar ist.
In dieser Situation ist WLAN-Status bei VCC gemäß Signal-Level in 4 State eingeteilt:
• 0: No WLAN signal, oder das MS ist noch nicht bei WLAN attached.
• 1: Signalstärke weniger als -85 dbM.
• 2: Signalstärke zwischen -85 dbM und -75 dbM.
• 3: Signalstärke größer als -75 dbM.
Durch periodische Messungen von WLAN-Signalstärke soll das MS(hier Dual-Mode
Endgerät) in 4 Status erkennen: ’No WLAN ’, ’WLAN Found ’, ’Losing WLAN ’,’WLAN
Stable’.
28
3. FMC-Client
2.WLAN-Verbindung zu aktivieren und deaktivieren
Nach der Messung von WLAN Signalstärke ist das Endgerät schon in der Lage zu entscheiden, die WLAN-Verbindung zu aktivieren bzw. Deaktivieren. Es gibt zwei grundlegende Fälle:
WLAN Stable
Unter WLAN Stable ist WLAN verwendbar, um Verbindung herzustellen. Jetzt kann
das Endgerät WLAN aktivieren.
No WLAN, WLAN Found, Losing WLAN
No WLAN bedeutet WLAN Signalstärke in der Stufe von 0. WLAN Found erhöht die
Signalstärke von Stufe 0 nach oben, aber es ist noch nicht stabile. Deshalb ist WLAN
noch nicht verwendbar. Losing WLAN sinkt die Signalstärke von 2 oder 3 nach unten,
Unter dieser Bedingung muss WLAN-Verbindung deaktiviert werden, um eine Sichere
Session zu garantieren.
3.Automatisch Anmeldung an einer WLAN-Zugangsschnittstelle
Damit das Handy mit dem Internet kommunizieren kann, ist eine Authentifizierung
nötig. 802.1X-Authentifikationsprotokoll ist dafür verantwortlich. Der Authentisierung
kann dabei benutzer- oder maschinenbezogen erfolgen.
Es setzt ebenfalls eine Zugangskontrolle für Benutzer, die sich mit dem Netzwerk verbinden, um. Die IEEE 802.1X-Architektur besteht aus drei funktionellen Einheiten:
Abbildung 3.3.: 801.11.x Authentifizierung
• dem Supplicant, der sich mit dem Netzwerk verbindet;
• dem Authenticator, der eine Zugangskontrolle bereit stellt;
29
3. FMC-Client
• dem Authentication Server, der Authentifizierungsentscheidungen trifft.
Der Detailablauf ist wie folgt:
1. Wenn ein Client (Supplicant) sich mit dem Netzwerk verbindet (Link up oder
Verbindungsaufbau zum Accesspoint) fragt der Switch bzw. Accesspoint (Authenticator) nach der Identität des Clients. Zu diesem Zeitpunkt ist nur eine Kommunikation zwischen Client und Switch bzw. Accesspoint möglich. Der Zugang
zum eigentlichen Netzwerk ist noch gesperrt. Die Kommunikation zwischen Client
und Switch erfolgt über das EAPoL (EAP over LAN) Protokoll, das auf der LLC
Ebene (der Client hat zu diesem Zeitpunkt ja noch keine IP Adresse) erfolgt.
2. Der Authentisierung zugrunde liegt das EAP (extensible authentication protocol)
Protokoll. EAP ist ein universelles Protokoll für viele verschiedene Authentisierungsverfahren. Das EAP Protokoll selbst führt keinerlei Authentisierung durch; es
dient nur dazu, einen standardisierten Authentisierungsvorgang zwischen dem Client und einem Radius Authentisierungsserver zu ermöglichen: welches Authentisierungsverfahren verwendet werden soll (PAP, CHAP, msCHAP-v2, TLS, PEAP,
TTLS mit Subvarianten etc.), können der Client und der Authentisierungsserver
vor der Durchführung der eigentlichen Authentisierung aushandeln. Der Authenticator (Switch oder Accesspoint) ist nur soweit an diesem Vorgang beteiligt, daß
er die EAPoL Nachrichten des Clients in Radiusanfragen (Radius Attribut/Value
Paare mit Hashberechnungen für Passwörter und Paketidentifikatoren) an die Radius Authentisierungsserver weiterleitet und umgekehrt.
3. Nach erfolgreicher Authentisierung öffnet der Authenticator dann den Netzzugang
und der Client kann seinen normalen Netzstart (DHCP Anfragen, Netzwerklogins
etc.) ausführen. Zudem können über Radius Replyattribute - falls der Authenticator das unterstützt - dem Benutzer bzw. Client bestimmte Netzwerkresourcen
(Bandbreite, VLAN, Filter etc.) zugeteilt werden. Verwendet man TLS, TTLS oder
PEAP als Authentisierungsverfahren, fällt für den WLAN Zugang unter 802.11i
als Nebenprodukt der Masterkey für den dynamischen Schlüsselaustausch zwischen
dem Client und dem Accesspoint ab. [11]
RADIUS
RADIUS (Remote Authentication Dial-In User Service) ist in der RFC17 2865 definiert
und ist ein Protokoll für die Remote User Authentifizierung, Authorisierung undAccounting (AAA).
Der Nachfolger von RADIUS ist der DIAMETER, der in der RFC 3588 definiert ist, der
aber durch seine geringe Verbreitung hier nicht weiter betrachtet wird.
30
3. FMC-Client
WEP
WEP ist ein Verschlüsselungsverfahren, um Netzwerke nach dem IEEE 802.11- Standard
zu schützen. Das Verfahren sollte die Daten, die über das WLAN geschickt werden, so
schützen, dass es mit der Sicherheit eines kabelgebundenen Netzwerkes vergleichbar ist.
WPA
Im Jahre 2003 wurde WPA als Nachfolger von WEP veröffentlicht, allerdings galt WPA
nur als Übergangslösung. Der Grund war, dass sich WEP als unsicher herausgestellt
hatte und sich die Verabschiedung des neuen Sicherheitsstandards IEEE 802.11i verzögerte.
TKIP
TKIP wurde für die Abwärtskompatibilität mit der damals existierenden Hardware entwickelt, wohingegen CCMP von Grund auf neuentwickelt wurde. TKIP setzt auf den
RC4-Algorithmus, wie bei WEP, mit einem sich temporär ändernden Schlüssel, einem
Message Integrity Check (MIC), auf und stellt mit Hilfe der MAC-Adresse des Senders
sicher, dass jede Nachricht seinen eigenen Verschlüsselungscode besitzt.
TKIP ist ein Verschlüsselungsprotokoll für den Einsatz in Funknetzten (WLAN). Die
Standards 802.1X und WPA nutzen TKIP für die Authentifizierung.
4.Seamless Handover zwischen GSM und WiFi, manual/automatisch Netzwerkeselektionsfunktion
Gegenseitige Seamless Handover ist eine der wichtigsten Funktionen von FMC. Durch
Verwendung der gemessenen Signalstärken und WLAN-Stuatus ist eine unterbrechungsfreie Handover zwischen WLAN und GSM gewährleistet. Auf diese Weise können Telefonate, die beispielsweise beim Verlassen des Büros angefangen wurden, auch nach
Verlassen des Unternehmensgeländes weitergeführt werden, ohne dass die Gesprächspartner vom Netzwechsel Notiz nehmen.
Es gibt drei Situationen, periodische Messungen von Signalstärke ist vorausgesetzt.
1. GSM => VoWLAN
Wenn WLAN-Status in WLAN Stable, d.h. , WLAN ist verwendbar, um eine
Session zu gewährleisten.
2. VoWLAN=>GSM
Wenn WLAN-Status von WLAN Stable in Losing WLAN läuft, leitet die Session
von VoWLAN nach GSM um.
3. Manuelle Einstellen auf GSM
Dieser Fall ist normalerweise bei Notruf oder nach Wunsch eingesetzt.
31
3. FMC-Client
5.Anrufe über Mobilfunknetz zu initiieren und zu beenden
Die Mobile Endegeräte haben selbstverständlich die Fähigkeit, Anrufe über Mobilfunknetz zu iniitieren und zu beenden. Es gibt zwei grundlegende Fälle:
1. Für Notruf
2. Wenn WLAN Signal sehr schwach oder in einer längeren Zeit nicht stabile ist
Durch Analyse der Anforderungen von FMC-Client und gemäß der entsprechende Realisierungen habe ich folgende Struktur als Vorschlag gebaut:
Abbildung 3.4.: FMC-Client-Architektur
32
3. FMC-Client
3.3.3. VoIP-Client
Es gibt schon viel bestehenden VoIP-Client, die SIP unterstützen können und damit
sind sie Internet-Telefonie fähig. Hier werden zwei bespielweise VoIP-Client vorgestellt.
WoizeTM
Das WoizeTM softphone ist ein SIP-basierter VoIP-Client für Windows Mobile Bereits seit
längerem ist für Woize auch ein Windows PocketPC- und Smartphone-Client erhältlich,
mit dem man auf einem WiFi-fähigen Endgerät Zugriff auf seine Woize-Kontakte und die
VoIP-Funktionen nehmen kann. Heute hat Woize als erster Dienstleister seiner Branche
bekannt gegeben, auch eine Symbian-Version für seine Clients bereitstellen zu wollen.
Die Symbian9.1-Version von Woize könnte insbesondere vor dem Hintergrund der neuen
Gerätepalette von Nokia interessant werden: zur Zeit erscheinen das 9300i und das
E61 der E-Series mit S60-Interfaces im Handel. Auch die für Sommer geplanten neuen
N-Series-Geräte und Sony Ericssons WLAN-fähiges P990i können dann vom WoizeClient profitieren: er ermöglicht die kostenlose Telefonie mit anderen Woize-Teilnehmern
- unabhängig davon, ob man am PC sitzt oder sich ein WiFi-Handy ans Ohr hält.
Anforderungen:
• Windows Mobile 5.0
• .NET Compact Framework 2.0
• 200 MHz processor
• WiFi
Fring
Fring sit ein Kostenloser Instant-Messaging- und VoIP-Client für Symbian und Windows
Mobile Die kostenlose Smartphone-Software unterstützt zudem die Kommunikation via
Skype, Google Talk, MSN Messenger, SIP und Twitter.
Vorteile von Fring:
• Fring ist Freeware.
• Sie können Ihre Kontakte günstiger anrufen (je nach Tarif, Provider und Datenvolumen) .
• Kostenlose Verbindungen per WLAN sind ebenfalls möglich.
fring ist eine kostenlose Applikation für mobile Endgeräte, die es dem Nutzer erlaubt
Gespräche über das Internet zu führen. Dabei nutzt fring neben UMTS und GPRS
auch WLAN. Des weiteren bündelt die Software verschiedene Instant Messenger und
33
3. FMC-Client
VoIP-Clients in einer zentralen Kontaktliste. Untertützt werden sowohl Google Talk als
auch MSN Messenger, Skype, verschiedene SIP-Dienstanbieter und Twitter. Doch nicht
nur Gespräche innerhalb der Software-Communities lassen sich führen, fring unterstützt
auch Weiterleitungen in andere Telefonnetze wie SkypeOut, und zeigt an, welche Personen gerade online sind.
3.3.4. Clientkomponente
Das Client besteht aus drei Funktionskompomente. Sie arbeiten sich miteinander zusammen, um die oben genannte Funktionalitäten durchzuführen.
1. Handover-Client
Handover-Client ist der Schlüsselteil von dem FMC-Client. Es besteht aus wiederum drei Kompomente:
• RSSI-Received Signal Strength Indicator
RSSI ist für Signalstärke zuständig. Die gemessene Signalstärke wird hier
angezeigt und weitergeleitet.
• ND(Network Domain)-Status
Hier speichert die Network Domain-Status von zurzeitige Netzwerke. Es gibt
vier Fälle zu wählen:
WLAN unavailable,
WLAN registered,
GSM unavailable,
GSM registered.
• ND-Selector
ND(Network Domain)-Selector entscheidet, welche Netzwerke zu verwenden.
Es gibt folgende Situationen zu wählen:
SIP PS over WLAN only,
SIP PS over WLAN preferred,
Mobile CS only,
Mobile CS preferred.
HO(Handover)-Trigger bekommt Anweisung von ND-Selector und schaltet
die Netzwerke zwischen WLAN und GSM um.
34
3. FMC-Client
2. PSCU-Packet Switched Control Unit PSCU beinhaltet ein VoIP-Client und
macht Funktionen von PS-Telefonie Service wie Initiation und Beenden von Verbindungen mit Verwendung von SIP.
3. CSCU-Circuit Switched Control Unit CSCU speichert die Availabilitäten
von cellularen Netzwerke und macht die Circuit Switched Telefonie Service
3.4. Funktionsablauf des FMC-Clients
Um eine Anrufe zu initiieren und zu beenden, wie das Bild gezeichnet ist, sind folgende
Schritte ausgeführt werden:
Abbildung 3.5.: Funktionsablauf von FMC-Client
1. Überwachung der Netzwerke
Vor dem Registrierung ist Überwachung von Netzwerke-Zugangsschnittstelle nötig. Der Zugang zum zellularen Netzwerk wird außerhalb des Clients überwacht.
Überwachung von Zugang zum WLAN wird die Signalstärke periodisch gemessen.
Die gemessene Signalstärke läßt sich in oben schon erwähnte 4 Stufe einzuteilen.
2. Überprüfung der Netzwerke-Verfügbarkeit
Das RSSI sendet die Value von Signalstärke zu ND-Status. Die 4 Stufen sind
mit dem 4 WLAN-Status gekoppelt und in ND-Status gespeichert. Für zellularen
35
3. FMC-Client
Netzwerk bekommt die ND-Status Informationen direkt von CSCU, z.B. GSM
unavailable oder GSM available.
3. Registrierung in WLAN/GSM
ND-Status hat Netzwerke-Info. von WLAN als WLAN stable, dann ist WLAN
schon registierungsfähig. Jetzt wird WLAN registered in ND-Status gespeichert.
Für GSM wird GSM registered gespeichert. Der Registrierungsvorgang ist fertig.
4. Anrufe über VoWLAN/GSM, zwischendurch gegenseitig Handover
Normalerweise soll in ND-Selector SIP PS over WLAN preferred eingesteilt. D.h.,
Anrufe über VoWLAN ist bevorzugt. Zum Handover gibt es drei grundsätzliche
Fälle:
WLAN=> GSM
ND-Status hat Information von RSSI bekommen, dass Signalstärke von WLAN
immer schwacher, und WLAN-Status steht für Losing WLAN. ND-Status sendet
WLAN unavailable zu ND-Selector, ND-Selector schaltet die Netzweke von SIP
PS over WLAN preferred nach Mobile CS preferred. HO(Handover)-Trigger schaltet die Anrufe von WLAN nach GSM.
GSM=> WLAN
ND-Status hat Information von RSSI bekommen, dass Signalstärke von WLAN
in einem stabilen Zustand gekommen ist, WLAN-Status steht für WLAN stable.
Nach der Registrierung sendet ND-Status WLAN registered zu ND-Selector, NDSelector schaltet die Netzweke von Mobile CS preferred nach SIP PS over WLAN
preferred. HO()-Trigger schaltet die Anrufe von GSM nach WLAN.
Um mehrmalige Umschaltung zwischen GSM und WLAN zu vermeiden, ist hier
das sogenannte Ping-Pong-Effekt zu berücksichtigen. Während WLAN Found and
Loosing WLAN ist deshalb WLAN nicht verwendbar.
Manuell
In diesem Fall besteht die Möglichkeit, Netzwerke manuell eingeteilt werden dürfen. Z.B. für Notruf kann man immer Mobile CS preferred einstellen.
5. Anrufe beenden
Eine jede zeitige Unterbrechung von Anrufe ist während Mobile CS Anrufe und
VoWLAN Anrufe möglich.
36
3. FMC-Client
3.5. Anforderungen an Mobile Endgeräte und
Betriebssysteme
Um der FMC-Client auf dem Endgerät funktionsstüchtig zu laufen, gibt es Anforderungen auf mobile Endgeräte und Betriebssysteme. In diesem Abschnitt wird untersucht,
welches Leistungsspektrum derzeit erhältliche mobile Endgeräte aufweisen, d.h. welche
Gegebenheiten in Bezug auf Speicherumfang, Prozessorgeschwindigkeit usw. vorzufinden sind.
Auf mobile Endgeräte:
• PDAs oder Smartphones Bei der Untersuchung der Marktgegebenheiten der Endgeräte und auch unterstützte Endegeräte von bestehenden FMC-Produkten hat
sich herausgestellt, das PDAs oder Smartphones für FMC-Client geeignet sind.
• Dual Mode von WiFi und GSM Endegeräte mit Dual Mode von WiFi und GSM
ist eine grundsetzliche Vorausetzung. Das ist selbstverständlich zu verstehen, Weil
der Client ohne Dual Mode kein Sinn mehr hat. Dazu braucht es eine integrierte
WLAN-Karte in Endegeräte.
• Prozessor und Speicher Prozessor und Speicher sind auch wichtige Faktoren für
lauffähigen FMC-Client. Es ist schwer zu begrenzen, was für ein Prozessor und
wieviel Arbeitsspeicher der Client braucht, aber aus Markt-untersuchung schlage
ich für ein Prozessor ab ARM 9 mit 200 MHz(oder Prozessor in gleicher Stufe von
Lauffähigkeit und Geschwindigkeit ) und Arbeitsspeicher ab 64 MB vor.
Auf Betriebssysteme:
• Integrierbarkeit und universell programmierbarkeit Die mobile Betriebssysteme
sollen gut Intergrierbarkeit universell programmierbarkeit für den FMC-Client haben. Sie sollen die vollständige Funktionalität des Endgeräts sicherstellen und kontrollieren daher alle unmittelbaren Funktionen von FMC-Client. Zusätzlich müssen
die Betriebsysteme noch eine offene Schnittstelle anbieten, damit die Entwickler
den Client problemlos auf Betriebssystem integrieren können.
• Unterstützung von Endegeräte Es ist auch sinnlos, wenn ein Betriebssystem wenige
Endgeräte auf dem Markt unterstützen kann.
• Unterstützung von SIP/VoIP VoIP Funktion mit SIP als Signalisierungsprotokoll
muss auch unterstützt werden.
37
3. FMC-Client
• Power Save Die Dual-Modus Endegeräte haben normalerweise immer BatterieProblem. Weil Verwendung von WLAN sehr energieaufwandig ist. Eine Lösungsvorschlag ist, U-APSD einzusetzen. U-APSD steht für Unscheduled Asynchronous
Power Save Delivery. Für einen längeren Einsatz von mobilen Telefonen für VoIP
verlängert U-APSD die Akku-Laufzeiten. Das Protokoll U-APSD ist eine Teilkomponente des Standards 802.11e.
3.5.1. Nötige APIs
Bisher habe ich den Struktur von dem FMC-Client konzipiert, und auch die Funktionalitäten sowie Funktionsablauf vorgestellt. Aber um den FMC-Client auf dem Endgerät
richtig laufen zu können, muss die Funktionen mit entsprechende APIs(Application Programming Interface) auf dem Endgerät implementiert werden. In dieser Arbeit soll auch
die nötige APIs gelistet werden. Das wird in Kapitel 4 genauer eingegangen.
38
Kapitel 3 beschreibt nun die Funktionalitäten und Struktur von dem FMC-Client. Um
den Client auf einem Endgerät laufen zu lassen, muss noch die nötige APIs ausgewählt
werden und entsprechende mobile Betriebssysteme untersucht werden. In diesem Kapitel werden dann eine Untersuchung und Analysierung über die anpassende mobile
Endgeräte und Betriebssysteme sowie die nötige APIs durchgeführt.
4.1. Analyse der angebotenen mobilen Endgeräten
Das Endgerät soll mindestens in der Lage sein:
• Dual Mode(GSM/WLAN) fähig,
• WLAN zu unterstützen,
• FMC-Service bieten kann,
• Relative höherer Prozessor und genug Speicher, um das FMC-Client laufen zu
lassen.
Unter solche Bedingung sind normal Handys ausgeschlossen. Das Client soll in Dual
Mode fähige Smartphones und PDAs implementiert werden.
Ein Dual-Mode-Handy ist Endgerät, das zwei vollkommen unterschiedliche Übertragungsverfahren, Standards und Netze unterstützt. Hier steht die Dual-Mode für GSM
und WLAN. Das Prinzip von Dual-Mode ist auch einfach. Wenn das Handy Verbindung
zum WLAN hat, kann der Benutzer kostengünstig übers Internet telefonieren. Auch an
öffentlichen Hotspots soll die VoIP-Telefonie so möglich sein. In Gebieten, in denen kein
WLAN zur Verfügung steht, verwendet das Handy das normale GSM-Netz.
Gemäß solecher Berücksichtigung sind folgende Handytypen gelistet:
39
Handy
Marke
Mobile System
Prozessor
Speicher
G900
Sony Ericsson
Symbian OS
Philips NMM Processor
160 MB
P1
Sony Ericsson
Symbian OS
160 MB
W960
Sony Ericsson
Symbian OS
128 MB
8120
BlackBerry
Eigenentwicklung
64 MB
8820
BlackBerry
Eigenentwicklung
64 MB
E60
Nokia
Symbian OS
ARM-926 220 MHz
64 MB
N95
Nokia
Symbian OS
ARM 11 332 MHz
64 MB
SGH-G810
Samsung
Symbian OS
ARM 11, 369 MHz
130MB
SGH-i780
Samsung
Windows Mobile 6
ARM 920T 624 MHz
128 MB
P3300 Ar-
HTC
Windows Mobile 5
TI OMAP 201MHz
128MB
S710 Vox
HTC
Windows Mobile 6
TI OMAP 850 201 MHz
64 MB
M536
ASUS
Windows Mobile 6 TI OMAP 450 MHz
Tabelle 4.1.: FMC-fähige Dual-Mode Endgeräte
temis
128 MB
Zwei typische Handys
E60
Das Nokia E60 Business-Smartphone unterstützt zahlreiche für den Unterneh-
menseinsatz optimierte Sprachfunktionen, u. a. Unterstützung für Konferenzgespräche
und Internet- Telefonie über WLAN. Zahlreiche Schnittstellen, Verbindungsmöglichkeiten, Mitteilungsoptionen und die breite Kompatibilität mit Office-Programmen ermöglichen auch unterwegs jederzeit den komfortablen Zugriff auf unternehmens- kritische
Daten.
Abbildung 4.1.: Nokia E60
• Unterstützung für UMTS-, EDGE- und Triband-Betrieb in GSM 900/1800/1900Netzen sowie Internet-Telefonie über WLAN
• Spezielle Taste zur schnellen Aktivierung der Sprachanwahl, der Sprachaufzeichnung und der Push-to-talk-Funktion (PoC)
40
• Kostengünstiger lokaler Zugriff auf Sprach- und Datenfunktionen über WLAN
• Sehr hochauflösendes Display zur optimalen Darstellung von Internet-Inhalten
• Automatischer Wechsel zwischen verschiedenen Netzen (z. B. WLAN, GSM/GPRS,
UMTS) ohne Neukonfiguration von Einstellungen. Diese Funktion benötigt keine
zusätzlichen Netzdienste, was eine breite Nutzung ermöglicht.
• Automatische und manuelle Netzwahl
• Bis zu 64 MByte großer interner Speicher
• Prozessor: ARM-926 220 MHz
• Betriebssystem: Symbian OS 9.1
BlackBerry Pearl 8120
Das BlackBerry Pearl Smartphone in Kombination mit
BlackBerry Enterprise Server stattet Anwender und IT-Manager von größeren Unternehmen oder Behörden mit modernster Sicherheit und leichterem Zugriff auf interne
Informationen aus.
Unabhängig davon, in welcher Branche Sie arbeiten: Wenn Sie einen wesentlichen Teil
Ihrer Arbeitszeit nicht am Schreibtisch verbringen, kommt es immer wieder vor, dass
Sie ausgerechnet die Ressourcen und Daten benötigen, auf die Sie nur vom Büro aus
Zugriff haben.
BlackBerry löst dieses Problem und sorgt gleichzeitig dafür, dass Sie über Ihr drahtloses
Gerät auch außerhalb des Büros und unterwegs ständig aktuelle Informationen erhalten.
Das BlackBerry Pearl 8120 Smartphone unterstützt Sie in allen Lebenslagen optimal.
Modernste Telefonfunktionen, Multimedia, Digitalkamera, Video-Aufnahme, WLANFähigkeit und ein erweiterbarer Speicher sind bereits im Lieferumfang enthalten.
Gerätefunktionen:
• WLAN-Support, damit Sie sich praktisch mit jedem WLAN-Netzwerk verbinden
können.
• Direkter Internet-Zugang über WLAN
• 64MB Flash-Speicher, plus Speichererweiterung mit einer MicroSD-Karte
• Bluetooth-Unterstützung zum freihändigen Telefonieren auf Reisen oder anderswo.
• SureType Tastatur-Technologie im QWERTZ-Layout zum schnellen Schreiben von
Text- und E-Mail-Nachrichten.
• Support für UMA/GAN
41
Abbildung 4.2.: blackberry8120
4.2. Untersuchung der Betriebssysteme
4.2.1. Windows Mobile
Windows Mobile ist ein Betriebssystem von Microsoft für mobile Geräte. Die aktuelle
Version der Windows Mobile-Reihe ist die Version 6.0, die auf den Windows CE 5.2Kernel basiert. Die Versionen Windows Mobile for Pocket PCs und Windows Mobile for
Smartphones enthalten angepasste Software für Pocket PCs und Smartphones. Heute
dominiert Windows Mobile den Markt für PDA und Smartphone Betriebssysteme.
Windows CE
Windows CE ist kein Betriebssystem im herkömmlichen Sinne, sondern eine Produkteplattform, mit der man eigene Betriebssysteme konstruieren kann. Im Grunde ist Windows CE ein „Baukasten “, bestehend aus hunderten von Softwarekomponenten und
einem „Platform Builder “. Dieses Tool kennt z.B. die Abhängigkeiten zwischen Komponenten und erleichtert den Zusammenbau eines lauffähigen Betriebssystems. Damit kann
man sich Betriebssysteme massschneidern, die von ein paar hundert Kilobyte Grösse für
ein „deeply embedded “ System ohne Benutzerschnittstelle bis zu einem umfangreichen
Multimediasystem reichen können. Die Komponenten bieten typischerweise Untermengen der Funktionen ihrer grossen Schwestern in Windows XP an. Es sind allerdings nicht
überall strikte Untermengen, im Detail kann es Unterschiede geben.
Windows CE existiert für verschiedene Prozessoren, darunter die stromsparenden ARM
Mikroprozessoren. Der Kernel von Windows CE bietet Unterstützung für "harteËchtzeitAnwendungen. Z.B. garantiert er, dass alle Kernel-Routinen in konstanter Zeit ausgeführt werden. Solche Garantien sind nötig, um in Steuerungsanwendungen ein deterministisches Zeitverhalten zu erreichen.[12]
Für Massenmarkt-Geräte wie PDA und Smartphones hat Microsoft deshalb spezifische
Minimalkonfigurationen definiert. Eine für PDA („Windows Mobile for Pocket PC “) und
42
eine für Smartphones („Windows Mobile for Smartphones “). Jeder Hardwarehersteller
hat die Freiheit, die normalen Windows Mobile Konfigurationen noch zu modifizieren.
Um eine Fragmentierung des Marktes aufgrund inkompatibler Binärformate für Anwendungsprogramme zu vermeiden, unterstützt Windows Mobile nur ARM-kompatible
Prozessoren.[12]
Das .NET Compact Framework
.NET ist eine Laufzeitumgebung und Standardbibliothek von Microsoft, vergleichbar
mit einer Java Virtual Machine. Teile dieser Bibliothek, sowie die parallel zu .NET
entwickelte Programmiersprache C# wurden von der ECMA-Organisation zu einer internationalen Norm erhoben.
Windows Mobile 6
Windows Mobile 6 wurde am 12. Februar 2007 auf der 3GSM-Messe in Barcelona offiziell
vorgestellt. Version 6 basiert auf Windows CE 5.2, welches in großen Teilen dem Kern
von Windows Mobile 5.0 gleicht. Das Design der Benutzeroberfläche ist an Windows
Vista angelehnt.
Wichtige Neuerungen:
• IP-Telefonie
• HTML-Unterstützung in Mails
• Integrierte Updatefunktion, Optimierung für den Abgleich mit Windows Vista
• Erweiterte Sicherheits-Features:
• Speicherkarten-Verschlüsselung (AES) und Notfall-Datenlöschung aus der Ferne
• Vereinfachte Verwaltung von Zertifikaten
4.2.2. Symbian OS
Symbian ist ein proprietäres Betriebssystem für Smartphones und PDAs. Symbian OS
bietet dem Programmierer eine umfangreiche Sammlung von API’s, Dienste und Gerätetreiber.
Die Haupteigenschaften von Symbian OS sind: [13]
• Integrierte multimode Mobiltelefonie - es verbindet die Fähigkeiten der EDV mit
der Mobiltelefonie
43
• Offene Anwendungsumgebung - es ermöglicht den Einsatz von Mobiltelefonen als
Plattform für Anwendungen und Dienste in einer Vielzahl von Sprachen und Inhalten.
• Offene Standards und Kompatibilität - Symbian OS stellt mit seiner flexiblen und
modularen Implementierung einen Kern von „application programming interfaces
“(APIs) bereit.
• Multitasking - Symbian OS basiert auf einer Micro-Kernel-Architektur und beinhaltet volles Multitasking und Multithreading. Alle Systemdienste wie Telefonie,
Netzwerk Middleware und Anwendungssysteme laufen als eigene Prozesse.
• Flexibles Benutzer-Schnittstellen Design - mit Hilfe eines flexiblen „graphical user
interface “ (GUI) Designs wird die Portierung von Anwendungen für Dritte erleichtert.
• Robustheit - Symbian OS unterstützt direkten Zugriff auf Benutzerdaten. Es gewährleistet Datenintegrität, selbst unter unsicheren Kommunikationsbedingungen
und Mangel an Speicher und Strom.
• Sicherheit. Symbian OS unterstützt Zertifizierungs- und Verschlüsselungsmechanismen
• Objektorientierten Architekturansatz. Symbian OS kann schnell an verschieden
Plattformen angepasst werden.
• Power Management. Bei Symbian OS besonders effizient
• Erweiterbar durch C++, Java, Phyton und Perl.
Architektur
Symbian OS verfügt über verschiedene Subsysteme für verschiedene Aufgaben. Zu diesen Systemen gehört das Basis-Subsystem, das den Rahmen für alle anderen Elemente
darstellt. Es beinhaltet den Kernel, die Benutzer-Bibliothek, die verschiedenen Gerätetreiber und den File- Server.
Weiterhin gibt es Subsysteme für Telefonie, Messaging, Multimedia und einiges andere mehr. Auf diese soll hier aber nicht weiter eingegangen werden. Im Folgenden soll
nur auf das Basis-Subsystem eingegangen werden, das den Kern des Betriebssystems
darstellt.Abbildung 4.3. zeigt einen allgemeinen Überblick über die Architektur von
Symbian OS v9.1. .
44
Abbildung 4.3.: Symbian OS Version 9.1 System model
Kernel
Symbian OS hat einen kompakten, multitasking- und multithreading- fähigen Kernel,
der sowohl monolithische als auch Mikrokernel-Eigenschaften vereint. Die Hauptaufgabe
ist das Verwalten der Privilegien.
Gerätetreiber
Stellen eine API für Anwendungen zur Verfügung, welche die Steuerung von Hardware
erlaubt, die nicht unbedingt notwendig für das Ausführen des Betriebssystems ist.
Anwendung
Eine Anwendung ist ein Programm, welches nur mit User-Mode-Privilegien läuft und in
der Regel eine graphische Oberfläche besitzt.
Server
Ein Server ist ein Programm ohne eine graphische Oberfläche.
4.2.3. Palm OS
Palm OS ist ein Mobile Betriebssystem für die Organizer der Palm-Serie sowie für Smartphones. Die Geräte wurden zuerst nur von der Firma Palm, die auch das Betriebssystem
entwickelte, hergestellt. Später wurden die beiden Gebiete aber auf die Tochterfirmen
PalmSource (Software) und PalmOne (Hardware) aufgeteilt. Im Jahr 2005 kaufte die
Firma PalmOne die Rechte am alten Namen zurück und benannte sich wieder in Palm
45
um. Auch Sony, Handspring, Garmin, Symbol und andere Hersteller lizenzierten Palm
OS und setzten es in ihren Geräten ein. Mittlerweile hat sich Sony allerdings vom PDAMarkt verabschiedet und Handspring wurde von Palm übernommen, sodass es eigentlich
kaum noch Geräte mit Palm OS von anderen Herstellern als Palm selbst gibt.[14]
Hauptmerkmale:
• Single-tasking + single-threading
• Echtzeitsystem (bedingt durch single-tasking)
• Kommunikation der Programme untereinander durch sogenannte Launch Codes
• Ereignisgesteuert - interaktiver Betrieb
Vorteile:
• Stromsparend durch 3 Betriebsarten, da meistens im Doze- oder Sleep-Modus
• Schnelle Reaktion auf Tastendruck, da nie ganz ausgeschaltet
• Gute Texterkennungsrate, da Benutzer mit Grafiti-Schrift schreibt
• Kostengünstig, da einfache Hardware, einfache Ausstattung
• Stabil, wegen einfacher Ausstattung und single-tasking
Nachteile:
• Der Benutzer muß die Grafiti-Shrift erlernen
• Kein Multitasking
• Kein virtueller Speicher: im worst case (wenn nicht genügend dynamischer Speicher
vorhanden ist)
• kann ein Programm nicht laufen
4.2.4. Linux OS
Das Open Source Betriebssystem Linux existiert in unterschiedlichsten Ausprägungen
auch für mobile Endgeräte. Technisch unterscheidet es sich nur sehr wenig von den Mechanismen und Schnittstellen gegenüber Linux auf großen Rechnern. Deshalb sind auch
viele der anerkannten Linux-Sicherheits-eigenschaften in den Ablegern in mobilen Endgeräten nutzbar.
Linux bietet ein Speicherverwaltungs-konzept und eine Multitasking-Prozessverwaltung.
Der Betrieb ist im Gegensatz zu den anderen vorgestellten Betriebssystemen nicht auf
46
einen Benutzer beschränkt, es können dagegen mehrere Ver-trauensbereiche für verschiedene Benutzer und Benutzerprofile geschaffen werden. Zudem stehen verschiedene Dateisysteme mit Zugriffsschutz zur Verfügung, Kryptografie wird sowohl vom Betriebsystemkern als auch von Anwendungsbibliotheken angeboten, Authentisierungsmechanismen und Zertifikatverwaltung existieren ebenso. Zur Erweiterbarkeit muss man
auf die Verfügbarkeit des Quelltextes und die Möglichkeit und dem Recht zu dessen Änderung hinweisen. Für den professio-nellen Einsatz bedeutet dies auch, dass man wegen
der Quellcodeoffenheit des Systems nicht nur auf Aussagen des Herstellers angewiesen
ist, sondern die Sicherheitsmechanismen direkt überprüfen könnte. [15]
4.2.5. Analyse der Mobile Systemen
Oben habe ich derzeitige eindeutig am weitesten verbreitete Betriebssystemen für PDA
und Smartphone vorgetellt, nähmlich: Symbian OS, Windows Mobile, Plam und Linux.
Nach einer Untersuchung des Instituts ABI Research besaßen 2006 die meisten weltweit
verkauften Smartphones ein Symbian Betriebssystem. Laut des Berichts hält Symbian
einen Marktanteil von etwa 73 Prozent, der vor allem durch Nokia gestützt wird. Danach kommt Windows Mobile und Linux.
In der Praxis sind allerdings nur wenige auf Palm und Linux basierte Geräte verfügbar und die Zahl der Anwendungen ist stark eingeschränkt. Deshalb habe ich die
Implementierungs-Mobilesystemen für Symbian und Windows Mobile gewählt.
4.3. API-Application Programming Interface
API ist eine Schnittstelle, die von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird. Oft wird dafür die Abkürzung API
(für engl. application programming interface, deutsch: „Schnittstelle zur Anwendungsprogrammierung “) verwendet. Im Gegensatz zu einer Binärschnittstelle (ABI) definiert
eine API nur die Verwendung der Schnittstellen auf Quelltextebene.
Neben dem Zugriff auf Datenbanken, die Hardware wie Festplatte oder Grafikkarte
kann eine API auch das Erstellen von Komponenten der grafischen Benutzeroberfläche
ermöglichen oder vereinfachen. Im weiteren Sinne wird die Schnittstelle jeder Bibliothek
(Library) als API bezeichnet.[16]
In dieser Arbeit soll die nötige APIs ausgefunden werden, um das FMC-Client im mobilen Endgerät laufen zu können. Die detailierte Funktionalitäten sollen mit entsprechenden APIs realisierte werden. In diesem Abschnitt werden APIs von Windows Mobile
47
und Symbian OS vorgestellt. J2ME ist bietet zahlreiche APIs für Mobile Endgeräte. Es
kann auf Windows Mobile und Symbian implementiert werden.
4.3.1. APIs von Windows Mobile
Das Smartphone-APIs von Windows Mobile ist basiert auf C++. Das Programmierungsmodell von Smartphone gliedert sich in Gruppen von interfaces, properties, methods,
functions, data types, and data structures. Jede Gruppe hat ihre eigene spezifische Funktionalität. Folgende sind Windows Mobile barsierte APIs für Smartphone.
Windows Mobile-basedSmartphone API:
• ActiveSync API
• Bluetooth API
• Connection Manager API
• Device Configuration API
• File and Application Management API
• Game API (GAPI)
• Home Screen API
• HTML Control API
• Messaging API (MAPI)
• MIDI API
• Pocket Outlook Object Model (POOM) API
• Object Exchange (OBEX) API
• Remote API (RAPI)
• Speech Recognizer API
• Telephony API
• User Interface API
• Vibrate API
• Voice Recorder Control API
48
Hier werden nur die APIs vorgetellt, die für unsere Spezialisierung nötig sind.
Connection Manager API
Das Connection Manager API verwendet zur Zentralisierung und Automatisierung der
Einrichtung und Verwaltet die Netzwerk-Verbindung auf ein Windows Mobile basiertes Endgerät. Das mobile Gerät verwendet Conection Manager zur Establisierung oder
Scheduling einer Netzwerk-Verbindung und verwaltet die Detailisierung der Verbindung.
Es gibt folgende Fnnktionalitätsteile in diesem API:
• Connection Manager API Functions
• Connection Manager API Structures
• Connection Manager API Constants
In den unteren Tabelle werden beispielweise die nützliche Function und Constant vorgestellt.
Connection Manager API Functions
Function
Beschreibung
ConnMgrConnectionStatus
Liefert den Status der aktuellen Verbindung.
ConnMgrEnumDestinations
Zählt der Liste der verfügbaren Netze.
ConnMgrEstablishConnection
Erzeugt eine Verbindung Anfrage.
ConnMgrSetConnectionPriority Ändert die Priorität der aktuellen Verbindung.
Tabelle 4.2.: Connection Manager API Functions
Connection Manager API Constants
Programmierungselement
Beschreibung
Connection Manager Priority Constants
Definieren die Priorität der Verbindung.
Connection Manager Status Constants
Beschreiben den momentanen Status
der Verbindung.
Tabelle 4.3.: Connection Manager API Constants
49
Connection Manager Priority Constants
Value
Beschreibung
CONNMGR_ PRIORITY_ VOICE
Höchste Priorität. Eine Voice Verbindung.
CONNMGR_ PRIORITY_ HIPRIBKGND
Hohe Priorität Hintergrund der Verbindung.
CONNMGR_ PRIORITY_ IDLEBKGND
Idle Priorität Hintergrund der Verbindung.
CONNMGR_ PRIORITY_ LOWBKGND
Niedrigste Priorität.
Tabelle 4.4.: Connection Manager Priority Constants
Connection Manager Status Constants
Value
Beschreibung
CONNMGR_
STATUS_
Die Verbindung wurde hergestellt.
STATUS_
Versucht eine Verbindung herzustellen.
CONNECTED
CONNMGR_
WAITINGCONNECTION
CONNMGR_
STATUS_
Aborting Verbindungsversuch.
WAITINGCONNECTIONABORT
CONNMGR_
STATUS_
Die Verbindung wird gerade getrennt.
WAITINGDISCONNECTION
CONNMGR_
STATUS_
Die Verbindung ist getrennt und kann nicht wiederhergestellt
CONNECTIONFAILED
werden.
CONNMGR_
User-Verbindung abgebrochen.
STATUS_
CONNECTIONCANCELED
CONNMGR_
STATUS_
Die Verbindung wird getrennt.
DISCONNECTED
Tabelle 4.5.: Connection Manager Status Constants
Extended TAPI
Das Extended TAPI erweitert Wireless-Funktionalitäten wie Abfragen der Signalstärke,
Auswahl des Mobilfunknetzes usw. ExTAPI arbeitet mit Telephony API (TAPI) und
nutzt alle der TAPI-Geräte.
In den unteren Tabelle werden beispielweie die nützliche Function und Constant vorge-
50
stellt.
Extended TAPI Constants
Constant
Beschreibung
Radio Presence
Zeigt die Radio-Anwesenheit.
Radio States
Identifiziert den Zustand der Radio-Hardware.
Registration Status
Identifiziert den Status der Registrierung des Geräts.
System Type
eigt die CDMA oder GSM Systemtypen.
Tabelle 4.6.: Extended TAPI Constants
Radio Presence
Value
Beschreibung
LINERADIOPRESENCE_ PRESENT
Ein Radio-Modul ist vorhanden.
LINERADIOPRESENCE_ NOTPRESENT
Es gibt keine Radio-Modul
auf dem Gerät.
Tabelle 4.7.: Radio Presence
Real-time Communications (RTC) Client API
Windows Embedded CE enthält ein Real-Time-Kommunikation (RTC) Client-API, das
Echtzeit-Kommunikation unterstützt. Das RTC-Client-API ermöglicht Anwendungen
wie PC-PC, PC-Telefon oder Telefon-TelefonVerbindungen, es unterstützt auch Instant
Messaging (IM)-Sessions über Internet Protokoll.
Windows Embedded CE beinhaltet die RTC API von Version 1.2 und bietet dazu folgende grundlegende Funktionalitäten:
• Initiation Text-messaging Sessions
• Empfängen der Präsenz-Information
• Unterstützung von SIP
• Unterstützung von Provisional Acknowledgement messages (PRACKs)
Die RTC-Client-API unterstützt von IETF entwickeltem Session Initiation Protocol
(SIP), Wenn eine Verbindung mit SIP hergestellt ist, verwendet die RTC-Client-API
das Real-Time Transport Protocol (RTP) zur Übertragung von Medien zwischen Users.
Real-time Communications Architektur
Das Windows Embedded CE RTC-Client-API beinhaltet die folgenden Protokoll-Stacks:
51
• Session Initiation Protocol (SIP)
• Real-Time Transport Protocol (RTP)
• PSTN/Internet (PINT) internetworking service
In den unteren Tabelle zeigt die teilweise RTC Client API Ierfaces mit entsprechende
Beschreibungen.
Programmierungselemente
Beschreibung
IRTCClient
Das interface repräsentiert das RTC Client
Objekt.
IRTCClientEvent
Das Interface ruft Informationen über Ereignisse vom Typ RTCE_ CLIENT. Diese
Art von Ereignisse gibt Änderungen in der
Präsenz-Status eines Clients.
IRTCPresenceDevice(in Windows Embed-
Das Interface ruft Informationen über
ded CE 6.0. nicht unterstützt)
Device-Präsenz .
IRTCSession
Das Interface repräsentiert ein SessionObjekt.IRTCClient::CreateSession
erzeugt die Session-Objekt.
IRTCSessionCallControl
Dieses Interface enthält Methoden, die
es ermöglichen, die Anwendung zur Implementierung traditioneller Call-ControlFunktionen wie hold, forward usw.
IRTCSessionDescriptionManager
Dieses Interface definiert ein Umsetzungverantwortliches Session Description Manager. Das Interface ermöglicht die Unterstützung von SIP bei RTC-Client-API
IRTCSIPEvent
Das interface erhältet das SIP Message.
IRTCSIPMessage
Dieses Interface ruft die Informationen über alle eingehenden SIP-NachrichtHeader.
IRTCClientPresence (in Windows Embed-
Das Interface beinhaltet alle Methoden
ded CE 6.0. nicht unterstützt)
und Eigenschaften im Bezug auf ClientPräsenz.
Tabelle 4.8.: Interface von RTC-Client
GUI API- Graphics, Windowing, and Events Subsystem (GWES)
52
GWES ist ein Interface zwischen dem Benutzer, der Applikation und dem Betriebssystem. Es unterstützt alle Elemente (Windows, Dialogboxen, etc.) mit welchem über ein
User Interface mit der Applikation interagiert werden kann.
Graphics, Windowing and Events Subsystem (GWES) Das Graphics, Windowing and
Events Subsystem wurde zusammengesetzt aus den Benutzer- und GDI- (Graphics Device Interface) Subsystemen von den Desktop-Versionen, dabei wurden die Event- und
Window-Manager unverändert übernommen. Das GDI-Subsystem wurde an die kleinere
Bedienoberfläche angepasst und in Multi-Platform GDI umbenannt. Das GWES Modul
ist die Schnittstelle zwischen dem Benutzer, den Applikationen und dem Betriebssystem. Es übersetzt die Eingabe des Benutzers über Tastatur, Touchscreen, Maus und
gibt die Befehle an die Applikationen bzw. das Betriebssystem weiter. Auf der anderen
Seite gibt es die Ausgabe der Applikationen an den Benutzer weiter indem es Fenster
erzeugt und Grafiken oder Text anzeigt. Alle Programme in Windows CE basieren auf
dem Fenster, sogar wenn kein Bildschirm benötigt wird. [18]
4.3.2. APIs von Symbian
Einer der großen Vorteil von Symbian OS liegt bei der Programmierung. Die Programmierung und Installation auf Endgeräten ist für jedermann offen, da die Programme
nicht einen Zertifizierungsprozess durchlaufen müssen. Dem Programmierer stehen verschiedene Programmiersprachen zur Verfügung. Die meisten verwendete Programmiersprachen sind C++ und Java ME. Die bieten zahlreiche APIs für Implementierung
entsprechende Funktionen auf Endgeräten.
Die meisten mobilen Geräte unterstützen Java. Hierbei läuft auf dem Gerät eine KVM,
welche Java-Midlets18 ausführen kann. Der Vorteil hierbei ist, daß die Midlets auf jedem
Java-fähigen Gerät laufen, auf dem die vom Midlet benutzten APIs implementiert sind.
Auch Symbian-Geräte haben in der Regel eine KVM, um Java-Programme ausführen
zu können. Die Entwicklung von Symbian mit C++ ist viel teuer als mit JavaME. Die
finanzieller Grund ist einer der wichtigste Faktor beim Wählen zwishcen C++ und JavaME. Im Vergleich mit C++ ist zwar auf JavaME basierte Symbian OS langsamer,
aber es ist noch akzeptierbar. Mit ungefähr 75% im Sinne von Geschwindigkeit kostet
JavaME bei Entwicklungszyklus nur weniger als 50% im Vergleich mit C++. Deshalb
gibt es auf dem Markt über 90% Symbian-Handys mit JavaME, und es gibt nur die jenige Endegeräte,die speziellle Funktionen haben,die bestens mit C++ entwickelt werden
können.
53
4.3.3. APIs von JavaME
Einleitung
Java Micro Edition ist die kleinste Plattform der Javaumgebung. Der Einsatzbereich
der Micro Edition liegt vorwiegend im Bereich der mobilen Applikationen und der Möglichkeit, Java Applikationen auch mit beschränkten Ressourcen zu nutzen.
Die Architektur der Java Micro Edition ist modular aufgebaut und läßt sich in vier
Schichten aufteilen. Die unterste Schicht bildet das Betriebssystem, z.B. Symbian OS,Windows
Mobile oder Linux. Auf die Betriebssytemebene setzt eine plattformabhängige Implementierung der virtuellen Maschine (KVM oder CVM) auf. Die darüberliegende dritte
Schicht bilden die Konfigurationen, die zusammen mit den in der obersten Schicht liegenden Profilen die Funktionalität der KVM/CVM beschreiben. [19]
Abbildung 4.4.: JavaME-Struktur
Konfigurationen
Konfigurationen beschreiben die Grundfunktionen der KVM/CVM für eine Klasse von
Geräten mit ähnlicher Leistungsfähigkeit. Eine Konfiguration umfasst eine virtuelle Maschine, Klassenbibliotheken und API’s, die auf die Eigenschaften dieser Geräte zugeschnitten sind.
Es existieren bisher zwei solcher Konfigurationen. Die Connected Limited Device Con-
54
figuration für Mobiltelefone, Pager und PDAs und die Connected Device Configuration
(CDC) für etwas leistungsfähigere Geräte, wie SetTop-Boxen, Bildtelefone und Spielekonsolen.
Auf den Konfigurationen setzen die Profile auf. Ein Profil spezifiziert je für eine Klasse
von Zielgeräten Java-API’s. Die Profile enthalten unter anderem die Klassen für die
Benutzerschnittstelle oder die persistente Datenhaltung. Profile können ineinander verschachtelt sein oder aufeinander aufbauen.
CDC-Connected Device Configuration
Die CDC (Connected Device Configuration) beinhaltet die komplette Java 2 Plattform
VM, die CVM (Customer Virtual Machine) und die minimal erforderlichen API Klassen
für das System. Für Applikationen wird zusätzlich ein Profil benötigt. Das „foundation
profile“, welches alle übrigen Klassen und APIs beinhaltet und bei Bedarf andere Profile
(z.B. für GUI) müssen auch eingebunden werden. CDC ist einer Superklasse von CLDC
und ist somit auch für CLDC Geräte einsetzbar.[17]
CLDC-Connected Limited Device Configuration
Diese Konfiguration geht auf die beschränkten Ressourcen von mobilen Kleinstgeräten
wie Handys, PDAs oder Pager ein. Sie setzt Speicher im Bereich von 128 bis 512 KB,
Batteriebetrieb und (falls vorhanden) eine Netzwerkverbindung von mindestens 9.600
BPS voraus. Bestandteil dieser Konfiguration ist die Kilo Virtual Machine (KVM), eine
virtuelle Maschine speziell für Geräte mit einem Hauptspeicher im Kilobyte-Bereich.
Das Ziel der CLDC ist die Unterstützung einer breiten Palette an Geräten, welche mit
sehr beschränkten Ressourcen auskommen müssen. Als grosser Vorteil der Java Technologie in portablen Geräten gilt das dynamische und sichere Verbreiten von interaktivem
Inhalt und Anwendungen über verschiedenartige Netzwerke. Die CLDC setzt außer der
minimalen Speicheranforderung keine besonderen Hardware-Anforderungen voraus. Die
Speicheranforderung besagt, dass die VM, die Konfigurationen, die Profile und die Applikationen innerhalb von 160-512kB Platz haben müssen. Die Softwareanforderungen
variieren genau so stark wie die Hardwareanforderungen. Einige Geräte werden über eine
vollständig implementierte JVM verfügen, während andere Geräte mit einem beschränkten Softwareumfang nur die notwendigen Klassen beinhalten. Die einzige Grundvoraussetzung für die Software ist ein minimales „host operating system“, falls nicht der Kernel
selbst die zu Grunde liegende Hardware verwalten kann. Das „host operating system“
muss weder keine getrennte Adressräume oder Prozesse verwalten können, noch braucht
es eine Echtzeitunterstützung. [17]
55
Profil
Profiles sind eine Menge von APIs, welche die Konfigurationen erweitern und in Kombination mit ihnen eine Anwendungsumgebung bilden. Mit der Auswahl eines Profiles
kann noch genauer auf die Fähigkeiten der Hardware des Geräts eingegangen werden.
Auf diese Weise wird vermieden, dass unbenutzte APIs unnötig Speicherplatz belegen.
Momentan liegen für die oben genannten Konfigurationen verschiedene Profile vor, die
sich in unterschiedlichen Stufen des Spezifikationsprozesses befinden. Für die Connected
Limited Device Configuration sind dies das Mobile Information Device Profil und das
PDA Profil. Das Foundation Profil, das Personal Profil und das RMI Profil liegen für
die Connected Device Configuration vor.[17]
Das MIDP ist das Mobile Information Device Profile und baut auf die CLDC auf. Üblicherweise wird dieses Profil in Mobiltelefonen, kleinen PDAs und interaktiven Pagern
verwendet.
MIDlets
Eine J2ME-Applikationen nennt man MIDlet, wenn Sie auf das MIDP aufsetzen. Zum
erstellen von MIDlets gibt es mehrere Möglichkeiten. Zum einen kann man Ktoolbar
(welches im WirelessToolkit von SUN enthalten ist) für die Automatisierung der Abläufe
verwenden, die einzelnen Schritte von Hand erledigen oder eine Entwicklungsumgebung
für J2ME verwenden. Im praktischen Teil meiner Diplomarbeit habe ich das WirelessToolkit verwendet, auf welches ich später noch genauer eingehen werde. [17]
Die grafische Benutzerschnittstelle (GUI)
Für die Darstellung von Informationen, Bildern und Formularen auf dem Display wird
das Package javax.microedition.lcdui benötigt. Alle darstellbaren Toplevel-Elemente implementieren das Interface Displayable. Diese Elemente nennt man Screens. Diese kann
man dem Display des Endgeräts zuordnen.
Optionale Pakete
Optionale Pakete dienen der Erweiterung von Funktionen, welche nicht durch das Profil
erfüllt werden. Da der Markt mobiler Geräte stark umkämpft ist, bauen die Hersteller
immer mehr Features und Innovationen in ihre Produkte ein. Diese müssen letztlich
auch über APIs zu erreichen sein, um die Leistungsmerkmale der Ablaufumgebung ausschöpfen zu können. Mit der zunehmenden Implementierung von Optionalen Paketen
in der Endgeräten schließt sich die Lücke zwischen nativen Anwendungen und MIDlets
56
in Bezug darauf, inwieweit sie die Leistungsmerkmale der Ablaufumgebung ausschöpfen
können.
Es gibt eine Fülle von optionalen Paketen, welche sich frei miteinander kombinieren
lassen. Vorteilhaft kommt dabei die Schichtenarchitektur der JavaME zum Tragen: Es
lassen sich beliebig viele Pakete oberhalb des Profils „andocken“. Da die Zugriffe topdown erfolgen, ist dem MIDP nicht bekannt, wie viele und welche optionale Pakete zum
Einsatz kommen. Die Anzahl der Kombinationen ist beträchtlich. Dies führt zu einer
Fragmentierung der Gerätefunktionen, schließlich integrieren die Hersteller nicht notwendigerweise alle dieselben Pakete. Da es im Zuständigkeitsbereich der Hersteller liegt,
die Implementierungen dieser Pakete, wie auch beim MIDP, zu übernehmen, entscheiden
diese, welche Pakete sie für implementierenswert halten. Daher entstand die Bestrebung,
mehrere optionale Pakete zu einem größeren Paket zusammenzulegen. Diese Initiative
wurde im Jahre 2004 im JSR-248 „Mobile Service Architecture“(MSA) beschlossen.[17]
JSR 248: Mobile Service Architecture
Die MSA lässt sich als Standardisierungsbemühung verstehen, um die Portabilität mobiler Java Anwendungen zu wahren. Auch lässt sie sich als Grundlage der nächsten
Generation Java-fähiger Mobiltelefone bezeichnen. Ziel ist neben der Zusammenlegung
auch, „Unklarheiten und Interpretationsspielräume in den Spezifikationen der optionalen
Pakete“ zu beseitigen, die ansonsten auch zu inkompatiblen Implementierungen hätten
führen können. JSR-248 definiert keine neuen APIs, sondern beschränkt sich zunächst
auf die Zusammenfassung altbekannter Funktionalität und definiert klare Verhaltensregeln für die Nutzung der eingebetteten Sub-JSRs.
Die MSA setzt sich im Wesentlichen aus folgenden Komponenten zusammen:
• Die Konfiguration CLDC1.1(JSR-139)
• Das Profil MIDP(JSR-118)
• Die JTWI 1.0 (JSR-185)
• Optionale Pakete in zahlreichen weiteren JSRs
JSR 209: AGUI
Die Advanced Graphics and User Interface (AGUI) Optional Package migriert die APIs
von J2SE platform zu J2ME platform.
Diese Package unfasst folgende Funktionen:
• Swing user interface toolkit
• Java 2D Graphics and Imaging
57
Abbildung 4.5.: Mobile Service Architecture
• Image I/O
• Input Method Framework
JSR 307: Network Mobility and Mobile Data API
Das JSR bietet API’s für die Initiierung und Steuerung von Daten-Sessions in einem
mobilen Gerät und Anwendungen, die die Kontrolle der Auswahl zwischen verschiedenen
Netzwerken.
Network Mobility API
Die Network Mobility API bietet eine Möglichkeit, welche Netzwerke verwendbar sind.
Es detektiert die Preferences von zurzeitige Netzwerken. Preferences bedeutet, das DualMode Endgerät kann eine bevorzugte Verbindung zwischen z.B. VoWLAN und Cellular
initieren.
Connection Preferences interfaces bietet die Funktionen wie Session Selection, Network
Attach, dazu beinhaltet die Funktionen folgendes:
• Welche Netzwerke sind verwendbar(WLAN vs Zellular)
• Welche Netzweke sind zu Attach zu wählen
58
• Einstellung von Netzwerken, Verwaltung der Netzwerke-Informationen
• Welche voice telephony Anbieter zu verwenden
• Welche IM-Protokolle zu verwenden
Package javax.microedition.mobiledata
Die mobiledata package bietet eine Reihe von Schnittstellen, die benutzt werden können
zu konfigurieren und zu steuern Daten Tagung Einrichtung.
Das Mobiledata package bietet Interface, die für Konfiguration und Steuerung von Session Establisierung veranwortlich sind. Die Methoden ermöglichen folgenden Anwendungen:
• Welche Netzwerke sind zu verwenden, um Verbindung herzustellen
• Konfiguration der Verbindung
• Auswahl von Zugriffstechnologie wie Cellular und WLAN
• Erhalten der Änderung von Connection Status
JSR 304: Mobile Telephony API version 2
Die Mobile Telephony API Version2 (MTA)-Spezifikation definiert Funktionen für die
Kontrolle der mobilen Telefonie und verwendet für Java-ME-Geräten.
Die Mobile Telephony API bietet folgende Funktionen:
• Session Initierung und Beendung
• Erhalten von ankommende Calls
• Steuerung von bestehenden Calls
• Erhalten der Änderung von Session-Status
• Erhalten der Änderung von Netzwerk-Status
• supplementary services wie multiparty calls und call forwarding
• Aktivierung/Deaktivierungvon supplementary services
• Unterstützung von VoIP
In folgenden Tabellen werden die Interface teilweise zusammengefasst.
Call
Diese Interface ist für Initierung und Akzeptierung von Anrufe verantwortlich.
59
Fields
Beschreibung
STATE_ IN_ PROGRESS
In diesem Zustand ist die Verbindungsanfrage an Netzwerk gesendet, Es gibt noch keine Rückmeldung von
Netzwerk.
STATE_ RECEIVED
Dieser Zustand zeigt einen eingehenden Anruf an
STATE_ ACTIVE.
Die Umsetzung ist für die Signalisierung verantwortlich.
STATE_ WAITING
Die Status wird durch einen Anruf, das ein neuen eingehenden Anruf repräsentiert, hervorgerufen . Der neue
eingehende Anruf ist in ein Warte-Status wegen ein
Exsistenz von einem oder mehrer anderen Anrufe in
STATE_ ACTIVE oder STATE_ ON_ HOLD.
Tabelle 4.9.: Interface von Call
NetworkStatus
Die NetworkStatus ermöglicht, der Anwendungen momentane NetworkStatus von TelefonieService in einem Gerät zu erhalten.
Fields
Beschreibung
STATE_ FULL_ SERVICE
Netzwerk-Status
mit
voller
Servie-
Abdeckung.
STATE_ LIMITED_ SERVICE
Netzwerk-Status mit beschränkter ServieAbdeckung. Z.B. nur Notruf
STATE_ OUT_ OF_ COVERAGE
Netzwerk-Status keiner Servie-Abdeckung.
STATE_ SEARCHING
Verfügbare Netzwerke werden gesucht
Tabelle 4.10.: Interface von NetworkStatus
JSR 180: SIP API for J2METM
Das in JSR-180 spezifizierte SIP API ist eine für die JavaME geeigenete Schnittstelle für die Implementierung von SIP-Client und -Server-Programmen. Die wesentlichen
Deklarationen sind SipClientConnection und SipServerConnection. Die Methode Connetor.open() aus dem Generic Connetion Framework liefert für URLs mit dem Schema sip
oder sips Instanzen dieser Interfaces.
4.4. Realisierungen auf FMC-Client
Nachdem im vorherigen Abschnitte die generelle Funktionalitäten und entsprechende
nötige APIs des FMC-Clients dargestellt wurde, werden in diesem Abschnitt die Reali-
60
sierungsvorschlag betrachtet. Für die Realisierung des FMC-Clients auf mobile Endgeräte wurden bereitgestellt:
• Nötige APIs
• Betriebssysteme
• Entwicklungstools
Da über 90% der Mobiletelefone JavaME unterstützt, lohnt es sich, diese Programmierumgebung genauer zu betrachten. Ca. 90% aller aufgeführten Mobiletelefone unterstützen das MIDP 2.0 Profil, 74% die CLDC 1.1 Konfiguration. Aus diesen Zahlen kann
geschlossen werden, dass die Programmierumgebung der Wahl für die Entwicklung des
mobilen Clients auf Mobiltelefonen JavaME fällt. Wie vorher schon erwähnt hat, hat
Symbian OS ein Marktanteil von etwa 73% , sind hier dann Betriebssystem Symbian
OS und APIs von JavaME für Umsetzung des FMC-Clients vorgeschlagen. Natürlich ist
ein anderer Weg möglich z.B. mit Windows Moblie und APIs von C++.
Nötige APIs
Die nötige APIs von JavaME mit entsprechenden Funktionen für FMC-Client werden
in nächsten Seite dargestellt.
4.4.1. Realisierungsumgebung und Tools
Unter einer integrierten Entwicklungsumgebung, abgekürzt IDE (engl.: Integrated Development Environment), versteht man eine Applikation, in welcher eine Programmierumgebung, z.B. in Form eines GUI (graphical user interface) builders, eines Text- bzw.
Code-Editors, mit einem zugehörigen Compiler, Interpreter und Debugger zusammengefasst sind. Durch das Zusammenführen der verschiedenen Funktionen in einem Programm und zusätzlich eingebundenen Hilfen soll so dem Softwareentwickler die Arbeit
erleichtert werden.
4.4.2. Entwicklungstools von Java ME
Während heutzutage eine Reihe von Entwicklungsumgebungen für die Programmiersprache Java zu Verfügung stehen, ließen die ersten wirklich gut funktionierenden und
umfassenderen IDEs (Integrated Development Environment) in den Anfangszeiten von
Java (JDK (Java Development Kit) 1.0 bzw 1.1) lange auf sich warten.
61
APIs
Funktionen
JSR 307: Network Mobility
Überwachung von Netzwerke;
and Mobile Data API
Weiterleiten der Netzwerke-Informationen an entsprechenden Anwendungen, z.B. Handover;
Netzwerk-Attachment;
Netzwerkauswahl.
JSR 304: Mobile Telephony
Session Initiierung und Beendung ;
API version 2
Erhalten von ankommende Anrufe;
Steuerung von bestehenden Anrufe;
Verwaltung der Verbindung von VoWLAN.
JSR 180: SIP API for
Unterstützung und Verbindung des SIP mit End-
J2METM
gerät.
JSR 209: AGUI
Input Method Framework;
Swing user interface toolkit;
Java 2D Graphics and Imaging.
Image I/O;
JSR 30:Connected Limited
Festlegung der Merkmale der Java Sprache und der
Device Configuration
Virtuelle Machine;
Netzverbindungen;
Input und Output auf dem Endgerät, Benutzerschnittstelle;
Ereignisbehandlung
JSR118: Mobile Informati-
Verarbeitung von Mediendaten;
on Device Profile
Steuerung des Applikationslebenszyklus;
Kommunikation;
Graphical User Interface ( GUI ).
Tabelle 4.11.: Nötige APIs für FMC-Client
62
Java ME Wireless Toolkit
Sun stellt ein aus mehreren Komponenten bestehendes Werkzeug zur Verfügung, mit
dem sehr leicht MIDlets ausprobiert werden können, das Java ME Wireless Toolkit,
abgekürzt WTK . Dieses Toolkit wird anschließend ebenfalls installiert. Bei der Installation wird die Existenz des JDKs vorausgesetzt. Falls das JDK eine modernere Version
als diejenige ist, mit der das Toolkit getestet worden ist, wird man bei der Installation
darauf hingewiesen. Wegen der Kompatibilität des Bytecodes sollten keine Schwierigkeiten zu erwarten sein - aber sie sind nicht auszuschließen, gerade bei dem großen Wechsel
von Java 1.4 nach Java 5.
Das Java 2 Platform Micro Edition (J2ME) Wireless Toolkit ist eine Plattform für
Entwickler, die eine Emulatorenumgebung, Dokumentation und Beispiele für die J2ME
liefert. So lassen sich Applikationen entwickeln, die auf CLDC/MIDP kompatiblen mobilen Endgeräten lauffähig sind.
Das Wireless Toolkit ist ein wichtiges Tool im Zusammenhang mit JavaME. Es ist deut-
Abbildung 4.6.: Wireless Toolkit von Sun
lich ersichtlich, dass die KToolbar den Entwicklungsprozess für J2ME-MIDlets durch die
grafische Bedienoberfläche erheblich vereinfacht. Zudem sind auch die Vorgänge für die
Kompilierung und Per-verifizierung problemlos zu machen. Über die Kommandozeile ist
dies zeitintensiv, mit der KToolbar kann es mit einen einzigen Klick komplett ausgeführt werden. Der Programmierer muß sich aber bewusst sein, dass die Source fehlerfrei
63
und sythaktisch korrekt sein muß. Mit den verschiedenen Emulatoren können die Applikationen bereits im Entwicklungsstudium simuliert werden, damit der Programmierer
bereits einen Eindruck über die Funktionsweise uns das Aussehen des Programmes machen kann.
Download
Das aktuelle Toolkit findet man auf der folgenden Adresse der Sun-Internetseite:
http://java.sun.com/products/j2mewtoolkit/
Es gibt noch viele weitere Toolkits, z.B.:
• Motorola SDK for J2ME
• Nokia Developer Suite 2.2 for J2ME
• Sony Ericsson J2ME SDK
4.4.3. Entwicklungsumgebung von Symbian
Symbian SDK werden sowohl von Symbian direkt als auch von den Herstellern der Endgeräte, wie zum Beispiel Nokia, angeboten. Sie enthalten verschiedene Hilfsprogramme
zum Erstellen von Symbian-Anwendungen sowie einen Emulator, um die Programme
auf einem Desktop-PC zu testen.
Die SDKs unterstützen direkt die Entwicklungsumgebungen Microsoft Visual C++,
Metrowerks CodeWarrior, sowie emphBorland Mobile Studio23. Sie bieten die bekannten Vorteile einer Entwicklungsumgebung wie Syntax- Highlighting, das Anzeigen von
Klassen oder das Kompilieren auf Tastendruck. Allerdings existieren zum Teil große Unterschiede in der Art der Integration der SDKs in die jeweilige IDE. Während in Visual
C++ lediglich ein Wizard integriert werden kann, der dabei hilft, das Grundgerüst einer
Anwendung zu erstellen, bietet das Mobile Studio von Borland deutlich mehr Komfort.
Neben der Verwaltung der Projektdateien (.mmp) besteht hier auch die Möglichkeit mit
wenigen Handgriffen aus der IDE heraus verschiedene Build-Targets auszuwählen, oder
auch GUI-Elemente leicht mit einigen Mausklicks zu erstellen.[19]
64
Wenn wir die momentane Entwicklung der Kommunikation betrachten, ist leicht zu
entscheiden, das FMC eine sehr gute Aussicht hat.
Abbildung 5.1.: Aussicht von FMC-Markt
Die Welt der Kommunikation befindet sich in einem radikalen Umbruch. Die Geschwindigkeit, mit der sich die Telekommunikation auf der ganzen Welt wandelt, ist schwindelerregend. Es fällt schwer zu glauben, dass eine Erfindung, die nicht einmal 20 Jahre
zurückliegt, in wenigen Jahren eine fast 80% Verbreitung unter der erwachsenen Weltbevölkerung finden konnte. Der Markt für Telekommunikationsdienste in Europa hat sich
seit seiner Liberalisierung sehr dynamisch entwickelt. Bis zum Ende des Jahrzehnts ist
allerdings eine Abschwächung des jahresdurchschnittlichen Wachstums auf den verschiedenen Märkten zu erwarten. Vor allem um die Marktanteilsverluste des Festnetzes zu
kompensieren, wird das Geschäft mit Breitbandanschlüssen als lukrativ angesehen. Mit
der gegenwärtigen Umstellung der gesamten Netzinfrastruktur auf die IP-Technik streben Netzbetreiber eine effizientere und kostengünstigere Bereitstellung von Diensten an.
Das endgültige Ziel von FMC ist es, Fest-, Mobilfunk- und Datennetze miteinander zu
vereinen und somit verschiedene Dienste über ein transparentes Netzwerk - genannt Next
65
Generation Network - zur Verfügung zu stellen. Das Zentrum aller Kommunikationsdienste wird dann eine einzige Plattform sein, basierend auf dem Internet-Protokoll.[20]
Das Ziel, die Entwicklung eines FMC-Clients auf dem mobilen Endgerät, ist endlich
ein VoIP-Telefonie fähiges Endgerät zu haben, damit die Benutzer gleich zeitig Mobilitätsbequemlichkeit und Kostengünstigkeit genießen können. In dieser Arbeit habe
ich ein Konzept von FMC-Client vorgestellt, um den Client auf mobile Endgeräte zu
implementieren. Am Anfang habe ich erstmal über den gesamte Begriff FMC vorstellt.
Dann wurde bestehende Lösungen auf dem Markt bisschen eingegangen. Hintergrund der
Techniken UMA und IMS-VCC habe ich einen Vorschlagskonzept für FMC-Client hergestellt. Anschließende werden die passende mobile Betriebssysteme und entsprechende
nötige APIs analysiert. Am Ende wird eine Implementierungsmöglichkeit vorgeschlagen.
Schade ist, aus zeitlichem Grund habe ich nicht so präzis auf die Umsetzung von FMCCient, APIs und Mobile Systeme eingegangen. Was noch mögliche Berücksichtigung bei
Implementierung sind, Baterie-Ersparnis, Zusammenarbeit mit FMC-Server, Integration
in PBX usw.
66
2.1. Prinzipielle Struktur eines Next Generation Networks (NGN) . . . . . . .
6
2.2. IMS Architektur
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. FMC-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Zeitliche Abfolge der Evolutionsschritte für FMC Services . . . . . . . . . 14
3.1. VCC-Client Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. UMA-Client von Kineto . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. 801.11.x Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4. FMC-Client-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5. Funktionsablauf von FMC-Client . . . . . . . . . . . . . . . . . . . . . . 35
4.1. Nokia E60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. blackberry8120 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3. Symbian OS Version 9.1 System model . . . . . . . . . . . . . . . . . . . 45
4.4. JavaME-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5. Mobile Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6. Wireless Toolkit von Sun . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1. Aussicht von FMC-Markt . . . . . . . . . . . . . . . . . . . . . . . . . . 65
67
Abkürzungsverzeichnis
API
Application Programming Interface
CLDC
Connected Limited Device Configuration
DSL
Digital Subscriber Line
EAP
Extensible Authentication Protocol
FMC
Fixed Mobile Convergence
GUI
Grafic User Interface
GSM
Global System for Mobile Communications
IDE
Integrated Development Environment
IETF
Internet Engineering Task Force
IM
Instant Messaging
IMS
IP Multimedia Subsystem
MIDP
Mobile Information Device Profile
NGN
Next Generation Network
PDA
Personal Digital Assistan
PSTN
Public Switched Telephone Network
RADIUS
Remote Authentication Dial-In User Service
QoS
Quality of Service
SDK
Software Developement Kit
SDP
Session Description Protocol
SIP
Session Initiation Protocol
TKIP
Temporal Key Integrity Protocol
U-APSD
Unscheduled Asynchronous Power Save Delivery
UMA
Unlicensed Mobile Access
UNC
UMA Network Controller
URI
Uniform Resource Identifier
VCC
Voice Call Continuity
VoIP
Voice over IP
WEP
Wired Equivalent Privacy
68
WPA
Wi-Fi Protected Access
3GPP
3rd Generation Partnership Project
69
Tabellenverzeichnis
4.1. FMC-fähige Dual-Mode Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2. Connection Manager API Functions . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3. Connection Manager API Constants . . . . . . . . . . . . . . . . . . . . . . . .
49
4.4. Connection Manager Priority Constants . . . . . . . . . . . . . . . . . . . . . .
50
4.5. Connection Manager Status Constants . . . . . . . . . . . . . . . . . . . . . . .
50
4.6. Extended TAPI Constants
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.7. Radio Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.8. Interface von RTC-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.9. Interface von Call
60
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10. Interface von NetworkStatus
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.11. Nötige APIs für FMC-Client
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
70
Literaturverzeichnis
[1] Next Generation Networks und UMTS, Ulrich Trick
[2] IP Multimedia Subsystem, Max Seifert, Henning Landwehr
[3] Entwicklung eines QoS-fähigen SIP-Client für das Nokia 770 Internet Tablet, Mohammed
Amine Lefqih
[4] http://www.elektronik-kompendium.de/sites/kom/0911011.htm
[5] http://www.computerpartner.at/cgi-bin/dynamic?id=20071127064443002& temp=4
[6] Die Konvergenz der Mobilfunknetze und der Festnetze bietet Carriern neue Wege zur
Differenzierung ihrer Geschäftsmodelle, Colubris
[7] http://www.elektronik-kompendium.de/sites/kom/1102201.htm
[8] Voice Call Handover Service, MobileIGNITE MoU Industry Group
[9] http://www.access-company.com/german/products/clientsuite/ims.html
[10] HiPath MobileConnect, Siemens
[11] http://www-wlan.uni-regensburg.de/8021x.html
[12] http://www.oberon.ch/pdf/Infoblatt_ 200506_ Windows_ Mobile_ 5.pdf
[13] OS für kleine Endgeräte:Symbian OS,Sven Walter
[14] http://de.wikipedia.org/wiki/
[15] http://www.bsi.bund.de/literat/doc/mobile/mobile_ endgeraete.pdf
[16] http://www.id.uzh.ch/dl/sw/sap/Portal_ Abkuerzungen_ Glossar.pdf
[17] J2MECDC/CLDC,Christoph Bürki,Tibor Dekany
[18] http://www.ceesar.ch/cms/upload/pdf/infotronic/08_ Laborbeschreibung.pdf
[19] Java für eingebettete Systeme,Jens Schwarz
[20] White Paper Next Generation Network, T-Systems
71

Konzipierung eines FMC-Clients für mobile Endgeräte

Transcription

Similar documents

Band 1 als PDF herunterladen

Programmempfehlungen für Februar 2013 – TV

Wi-Fi-Sicherheit – WEP, WPA und WPA2

Anonymisierter Beitrag des Teams Universität Bayreuth

Ein echter Familientisch. Ein echter Familientisch.

market - Calgary Stampede

FRITZ!Box 6360 Cable

Das bringt das neue Windows - IT

Vincenz Aktuell - St. Vincentius

1. Einführung - Fritz Dellsperger

wir herthaner

12 Leben in Friedrichshain erzählen für Generationen

FRITZ!Box 6490 Cable - MeinKabel

3B08

Die Internet-Protokollsuite -- Anwendungsorientierte Protokolle

louise bourgeois

WLAN Bridge W-011 Benutzerhandbuch

Benutzerhandbuch

Java 2 Micro Edition ( Java2ME )

Karstwanderweg Südharz

Wie können Digitalisierungsprojekte effektiver den Weg ins

Künstliche Intelligenz in Spielen - WAP