Technische Universitat Ilmenau
Fakultat fur Elektrotechnik und Informationstechnik
Diplomarbeit
Konzipierung und Implementierung innovativerAnwendungen fur Handys unter Symbian OS
vorgelegt von: Frank Felgner
eingereicht am: 01. 10. 2005
geboren am:
Studiengang: Medientechnologie
Studienrichtung: Digitale Medien
Anfertigung im Fachgebiet: Kommunikationsnetze
Fakultat fur Elektrotechnik und Informationstechnik
Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz
Wissenschaftlicher Betreuer: Dipl.-Ing. Maik Debes
Danksagung
Zuerst mochte ich Herrn Prof. Dr. Jochen Seitz fur die Vergabe dieses interessanten
Themas danken.
Des Weiteren danke ich Herrn Dipl.-Ing. Maik Debes fur die tatkraftige und vorbild-
liche Unterstutzung und Betreuung wahrend der Bearbeitung dieses Diplomthemas.
Ebenso mochte ich Herrn Dipl.-Ing. Pavlo Krasovs`ky, Herrn German Blejman und
Herrn Jorge Robles fur die Anregungen und Ideen sowie die engagierte Mitarbeit in
dem Forschungsprojekt danken.
Mein Dank gebuhrt daruber hinaus all denen, die mir wahrend dieser Diplomarbeit
hilfreich zur Seite standen.
Ein ganz besonderer Dank gilt meinen Eltern, die mich wahrend des gesamten Stu-
diums tatkraftig unterstutzt und mir jede erdenkliche Hilfe haben zuteil werden lassen.
Ilmenau, den 31. 03. 2006 Frank Felgner
Kurzfassung
Die Entwicklung der Mobilfunk-Technologie schreitet stetig voran. Endgerate werden
kleiner und handlicher, aber sind dennoch leistungsfahiger. Mit dem Aufkommen der
MMS (Multimedia Messaging Service) schließlich wurde das Handy um multimedia-
le Fahigkeiten erweitert und erschloss einen Anwendungsbereich, der bisher anderen
Geraten vorbehalten war. Unterstutzt wird dieser Fortschritt zusatzlich durch das gro-
ßere Display und die besseren Video- sowie Audiofunktionen der Mobilgerate. Zudem
werden die Funknetze durch die zunehmende Konvergenz von Internet und Mobil-
funk immer breitbandiger. Es stellt sich nun die Frage, wie diese neuen Ressourcen
fur multimediale Anwendungen optimal zu nutzen und zu implementieren sind. Diese
Fragestellung ist Thema der vorliegenden Diplomarbeit. Es wird ein Konzept entwi-
ckelt und realisiert, welches das Versenden von multimedialen Daten zwischen zwei
Mobilgeraten ermoglicht.
Abstract
The development of the mobile radio technology constantly progresses. Mobile termi-
nals become smaller and easier to handle, but are nevertheless more efficient. Finally,
with the advent of the MMS (Multimedia Messaging Service) the mobile phone was
extended by multimedia capabilities and opened a field of application, which was re-
served to other devices so far. This progress is additionally supported by the larger
display sizes as well as the better video and audio functions of the mobile devices. Besi-
des, the radio networks become more broadband because of the increasing convergence
of Internet and mobile radio. Now the question arises, how these new resources are
used optimally for multimedia applications and how to implement them. This thesis
deals with this question. A concept is developed and implemented, which enables the
transmission of multimedia data between two mobile devices.
Inhaltsverzeichnis i
Inhaltsverzeichnis
1 Einleitung 1
2 Kommunikationsschnittstellen eines mobilen Endgerates 3
2.1 GSM – Global System for Mobile Communications . . . . . . . . . . . 3
2.1.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1.1 Mobilgerate . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1.2 Funksendesystem . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.3 Vermittlungssystem . . . . . . . . . . . . . . . . . . . 5
2.1.1.4 Betriebs- und Wartungssystem . . . . . . . . . . . . . 6
2.1.2 Multiplexverfahren . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2.1 Raummultiplexverfahren . . . . . . . . . . . . . . . . . 6
2.1.2.2 Frequenzmultiplexverfahren . . . . . . . . . . . . . . . 7
2.1.2.3 Zeitmultiplexverfahren . . . . . . . . . . . . . . . . . . 7
2.1.3 Logische Kanale in GSM . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1 Verkehrskanale . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.2 Signalisierungskanale . . . . . . . . . . . . . . . . . . . 9
2.1.4 Datenubertragung . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4.1 Circuit Switched Data – CSD . . . . . . . . . . . . . . 9
2.1.4.2 Internetzugang . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4.3 WAP – Wireless Application Protocol . . . . . . . . . 11
2.2 GPRS – General Packet Radio Service . . . . . . . . . . . . . . . . . . 12
2.2.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.1 Packet Control Unit – PCU . . . . . . . . . . . . . . . 13
2.2.1.2 Serving GPRS Support Node – SGSN . . . . . . . . . 14
2.2.1.3 Gateway GPRS Support Node – GGSN . . . . . . . . 14
2.2.2 Protokollarchitektur . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Datenubertragung . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.1 Zuweisung der IP-Adresse . . . . . . . . . . . . . . . . 17
2.2.3.2 Teilnehmeridentifikation . . . . . . . . . . . . . . . . . 19
Diplomarbeit Frank Felgner
Inhaltsverzeichnis ii
2.2.4 EDGE – Enhanced Data Rates for Global Evolution . . . . . . 19
2.3 UMTS – Universal Mobile Telecommunications System . . . . . . . . . 19
2.3.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Datenubertragung . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 WLAN – Wireless Local Area Network . . . . . . . . . . . . . . . . . . 22
3 Symbian OS – ein Betriebssystem fur Smartphones 23
3.1 Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Aufbau von Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Hardwareressourcen . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Systemkomponenten . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2.1 Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2.3 Anwendungskomponenten . . . . . . . . . . . . . . . . 27
3.2.3 Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.4 Ereignisbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.5 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Softwareentwicklung unter Symbian OS . . . . . . . . . . . . . . . . . . 28
3.3.1 Ubersicht der Dateien im Entwicklungsprozess . . . . . . . . . . 28
3.3.2 Besonderheiten bei Symbian OS . . . . . . . . . . . . . . . . . . 29
3.3.3 Namenskonventionen . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3.1 Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3.2 Variablen und Konstanten . . . . . . . . . . . . . . . . 30
3.3.3.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.4 Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Kommunikationskonzept 32
4.1 Multimedia-Ubertragungssysteme fur MS . . . . . . . . . . . . . . . . . 33
4.1.1 MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2 OBEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Auswahl der Kommunikationsschnittstelle . . . . . . . . . . . . . . . . 34
4.2.1 Festlegung der Kriterien . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2 Analyse der Schnittstellen . . . . . . . . . . . . . . . . . . . . . 35
4.2.2.1 Leitungsvermittelte Datenubertragung . . . . . . . . . 35
4.2.2.2 Paketvermittelte Datenubertragung . . . . . . . . . . . 36
4.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Diplomarbeit Frank Felgner
Inhaltsverzeichnis iii
4.3 Entwicklung des Kommunikationsprotokolles . . . . . . . . . . . . . . . 38
4.3.1 Transportprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2 Zuweisung von IP-Adresse zu MSISDN . . . . . . . . . . . . . . 39
4.3.2.1 Dynamischer DNS . . . . . . . . . . . . . . . . . . . . 39
4.3.2.2 Proprietarer Verzeichnisdienst . . . . . . . . . . . . . . 40
4.3.3 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3.1 Untersuchung der Netzprovider . . . . . . . . . . . . . 40
4.3.3.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3.3 VPN – Virtual Private Network . . . . . . . . . . . . . 42
4.3.4 Definition der Metadaten . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.1 Direkte Kommunikation . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Indirekte Kommunikation . . . . . . . . . . . . . . . . . . . . . 45
5 Praktische Umsetzung des Kommunikationskonzepts 47
5.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Auswahl der Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Applikationsentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1 Programmablauf . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.2 Ubersicht uber die programmierten Klassen . . . . . . . . . . . 49
5.3.3 Aktive Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.4 Klassen des Application Framework . . . . . . . . . . . . . . . . 54
5.3.4.1 CRecceAppUi . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.4.2 CRecceAppView . . . . . . . . . . . . . . . . . . . . . 56
5.3.5 Klasse fur den Zustandsautomat . . . . . . . . . . . . . . . . . . 56
5.3.5.1 CStateDirect . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.5.2 CStateIndirect . . . . . . . . . . . . . . . . . . . . . . 59
5.3.6 Kommunikationsklassen . . . . . . . . . . . . . . . . . . . . . . 60
5.3.6.1 CSocketEngine . . . . . . . . . . . . . . . . . . . . . . 60
5.3.6.2 CSocketWrite . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.6.3 CSocketRead . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.6.4 CTimeOutTimer . . . . . . . . . . . . . . . . . . . . . 62
5.3.7 Zusammenarbeit der Klassen uber Methodenaufrufe . . . . . . . 63
5.3.8 Anderungen an der Software der Kommunikationsteilnehmer . . 63
5.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.1 Aufbau eines Simulators . . . . . . . . . . . . . . . . . . . . . . 65
Diplomarbeit Frank Felgner
Inhaltsverzeichnis iv
5.4.2 Aufbau eines Demonstrators . . . . . . . . . . . . . . . . . . . . 66
5.5 Kritische Auseinandersetzung . . . . . . . . . . . . . . . . . . . . . . . 67
6 Zusammenfassung und Ausblick 69
A Messungen 73
A.1 NAT-Untersuchung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1.1 T-Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1.2 Vodafone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1.3 O2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.2 Bestimmung der Latenz . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B Applikation 77
B.1 Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.1.1 Application Framework . . . . . . . . . . . . . . . . . . . . . . . 77
B.1.2 Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.1.3 Kommunikationsklassen . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.3 Anderungen im Quellcode der Kommunikationspartner . . . . . . . . . 104
B.3.1 MS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C Inhalt der CD-ROM 106
Literaturverzeichnis 107
Abbildungsverzeichnis 110
Tabellenverzeichnis 111
Listings 112
Abkurzungsverzeichnis 113
Thesen zur Diplomarbeit 116
Erklarung 117
Diplomarbeit Frank Felgner
1 Einleitung 1
1 Einleitung
Die Mobilfunk-Technologie hat in den letzten Jahren einen enormen Wandel durchlau-
fen. Bedingt durch die zunehmende Verbreitung der Mobilgerate wurde der Ruf nach
immer schnelleren und leistungsfahigeren Funknetzen laut. Die analoge Technologie
wurde zugunsten des digitalen Netzes GSM (Global System for Mobile Communica-
tions) ausgetauscht und spater durch die paketvermittelnden Netze GPRS (General
Packet Radio Service) und UMTS (Universal Mobile Telecommunications System) er-
weitert resp. ersetzt. Internet und Mobilfunk konvergieren zudem. Zum einen gibt es
mit WAP (Wireless Application Protocol) speziell eine auf die Ubertragung mobiler
Internetinhalte ausgelegte Protokollarchitektur. Zum anderen nutzen die paketvermit-
telten Kernnetze zur Kommunikation untereinander die Internettechnologie.
Dank dieses Fortschritts war es nun auch unterwegs moglich, Internetinhalte abzu-
rufen. Doch auch die Entwicklung breitbandiger Internetanschlusse fur den privaten
Gebrauch schritt stetig voran und fuhrte zu neuen, multimedialen Anwendungen. Seit
Ende der 90er Jahre ist Multimedia deshalb der Motor fur mehrere Wirtschaftszweige.
Deswegen hielt auch auf dem Mobilfunk-Sektor die Multimedialitat schrittweise Ein-
zug. Die erste Verknupfung von audiovisuellen Inhalten wurde durch den MMS-Dienst
implementiert. Auf Seiten der Gerate gehort eine Kamera mittlerweile zum integralen
Bestandteil. Diese Gerate entwickeln sich rasant weiter: Sie werden klein und handli-
cher, aber dennoch leistungsfahiger, besitzen großere Displays und verfugen uber Mul-
timediafahigkeiten wie sie bisher nur von Desktop-Rechnern bekannt waren.
Die mobilen Gerate lassen sich in zwei Typen klassifizieren. Zum einen das Mobiltele-
fon, das umgangssprachlich Handy genannt wird. Zum anderen der PDA (Personal Di-
gital Assistant), der als tragbarer Minirechner fungiert. Waren die Grenzen bisher klar
definiert, so werden sie durch die neue Klasse Smartphone aufgeweicht. Ein Smartphone
ist der Definition nach ein Handy, welches PDA-Funktionen implementiert. Es verfugt
also einerseits uber die Moglichkeit, sich in ein Funknetz einzubuchen und Gesprache
oder Datenverbindungen durchzufuhren. Andererseits integriert es z.B. Terminplaner
und Burosoftware sowie die multimedialen Funktionalitaten eines PDA. Dabei nahert
es sich dem PDA sukzessive an und wird zukunftig als mobiles Buro fungieren.
Diplomarbeit Frank Felgner
1 Einleitung 2
Eine Moglichkeit zur Ubertragung von Dateien auf das Engerat erscheint daher
zwingend notwendig. Sei es, um ein wichtiges Dokument zu transferieren oder den
Entwurf fur ein Logo zu schicken – es kann jede Art von Daten ubertragen werden.
Die Technologie Blackberry der kanadischen Firma Research In Motion realisiert einen
Push-Dienst, welcher E-Mails und andere personliche Daten zu dem Empfanger schickt.
Fur den Konsumenten durften jedoch vorrangig audiovisuelle Daten interessant sein.
In der vorliegenden Diplomarbeit wird daher ein Konzept entwickelt, das multime-
diale Daten von einem Smartphone auf ein anderes mittels eines Push-Dienstes uber
eine beliebige Distanz ubertragen kann unter der Pramisse, dass dies unter optimaler
Nutzung der begrenzten Ressourcen des mobilen Endgerates geschieht. Des Weiteren
wird ein Kommunikationsweg uber einen Server realisiert werden, der bestimmte Da-
teien vorhalt. Die Smartphones wahlen Datei sowie Rufnummer des Empfangers und
der Server ladt die Datei anschließend auf das Smartphone des Empfangers hoch.
Das zweite Ziel dieser Diplomarbeit ist die praktische Umsetzung des Konzepts.
Dazu wird eine betriebssystemnahe Applikation entwickelt werden.
Zuerst werden in Kapitel 2 die Schnittstellen mobiler Endgerate erlautert und hin-
sichtlich ihrer Eignung fur Datenubertragung gepruft. Das Betriebssystem dieser Ge-
rate, speziell der Smartphones, wird in Kapitel 3 erklart. Im folgenden Kapitel 4 wird
nun das Kommunikationskonzept aufgestellt. Dessen Realisierung wird in Kapitel 5
beschrieben. Das letzte Kapitel 6 zieht das Fazit und gibt einen Ausblick.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 3
2 Kommunikationsschnittstellen eines
mobilen Endgerates
Es gibt vielfaltige Moglichkeiten der kabellosen Kommunikation fur mobile Endgera-
te. Als mobile Endgerate sind alle Gerate zu verstehen, die drahtlos an ein Netzwerk
angebunden sind. In diesem Kapitel werden die wichtigsten Mobilfunksysteme betrach-
tet und hinsichtlich ihrer Tauglichkeit fur Datenubertragung untersucht. Dabei wird
besonders ausfuhrlich auf GSM und GPRS eingegangen.
2.1 GSM – Global System for Mobile Communications
Mitte des letzten Jahrhunderts entstanden in Europa die ersten Mobilfunknetze. Sie
beruhten auf analoger Ubertragungstechnik, waren aufgrund ihrer nationalen Hetero-
genitat nicht kompatibel zueinander und machten durch ihre hohen Kosten die mobile
Technologie fur den Massenmarkt unattraktiv. Um diese Nachteile zu beseitigen, wurde
1982 die Groupe Special Mobile (GSM) bei der Europaischen Konferenz der Verwal-
tung fur Post und Fernmeldewesen (CEPT) mit dem Ziel eingerichtet, einen europaweit
einheitlichen Mobilfunkstandard zu schaffen, der kompatibel zu dem herkommlichen
offentlichen Telefonnetz ist. Nach der Eingliederung der GSM in das Europaische In-
stitut fur Telekommunikationsnormen (ETSI) wurden die Standards GSM 900 und
DCS 1800 (heute GSM 1800) verabschiedet, die ein vollstandig digitales Mobilfunknetz
beschreiben. Die GSM wurde spater umbenannt, die Abkurzung GSM blieb jedoch er-
halten und steht seitdem fur Global System for Mobile Communications. Mittlerweile
wird die Weiterentwicklung des GSM-Standards durch das 3rd Generation Partnership
Project 3GPP koordiniert.
2.1.1 Systemarchitektur
Das hierarchische GSM-System besteht aus den Mobilgeraten (Mobile Station, MS)
und dem fest installierten GSM-Netz, das sich wiederum in drei Teilsysteme einteilen
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 4
lasst, das Funksendesystem (Base Station Subsystem, BSS), das Vermittlungssystem
(Network and Switching Subsystem, NSS) sowie das Betriebs- und Wartungssystem
(Operation and Management Subsystem, OMS). Abbildung 2.1 zeigt den schemati-
schen Aufbau des GSM-Systems mit den relevantesten Elementen und Schnittstellen.
Abbildung 2.1: Systemarchitektur von GSM
2.1.1.1 Mobilgerate
Zum einen enthalt die MS die erforderlichen Hard- und Softwarekomponenten zur Kom-
munikation im GSM-Netz. Dieses Mobilgerat (Mobile Equipment, ME) ist durch die
IMEI (International Mobile Station Equipment Identity) international gekennzeichnet.
Zum anderen bildet erst die Verbindung des Gerates mit einer Chipkarte, dem SIM
(Subscriber Identity Module), die MS. Im SIM sind nutzerspezifische Daten gespei-
chert, die relevant fur die Teilnahme im GSM-Netz sind und das ME personalisieren.
Die wichtigsten permanent gespeicherten Informationen im SIM sind die IMSI (Inter-
national Mobile Subscriber Identity) und der Authentifizierungsschlussel Ki.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 5
2.1.1.2 Funksendesystem
Das BSS ubernimmt alle funktechnischen Aufgaben, die bei der Kommunikation der
MS mit dem GSM-Netz anfallen. Es besteht aus einem BSC (Base Station Controller)
und mehreren Basisstationen (Base Transceiver Station, BTS).
Mit Hilfe seiner Antennen bindet die BTS mehrere MS uber das Um- bzw. Air-
Interface an das GSM-Netzwerk an. Dabei ubernimmt es Aufgaben der untersten
Schicht, wie Kanalkodierung, Interleaving und Verschlusselung sowie Modulation und
Demodulation. Die Um-Schnittstelle stellt Mechanismen bereit, die den gleichzeitigen
Zugriff mehrerer MS auf eine BTS ermoglichen, siehe Abschnitt 2.1.2.
Alle BTS innerhalb des BSS sind uber das Abis-Interface an einen BSC gebunden.
Der BSC ist fur den Auf- und Abbau sowie die Aufrechterhaltung der Verbindung
samtlicher MS in seinem BSS zustandig.
[17] und [11] fuhren eine TRAU (Transcoding and Rate Adaptation Unit) als drittes
Netzelement. Laut Spezifikation ist die TRAU der BTS zuzuordnen, aus Effizienz- und
Kostengrunden wird sie jedoch in das noch vorzustellende MSC (Mobile (Services)
Switching Center) integriert. Der Grund dafur ist die Hauptaufgabe der TRAU: die
Sprachkompression von 64 kbit/s auf 16 kbit/s. Ist die TRAU in das MSC integriert,
sind fur die Strecke von MSC zu BTS nur schmalbandige Leitungen erforderlich.
2.1.1.3 Vermittlungssystem
Die Schnittstelle zwischen Funk- und Festnetz und damit das zentrale Element von
GSM ist das NSS. Es wird gebildet aus einem oder mehreren MSC sowie den Daten-
banken HLR (Home Location Register) und VLR (Visitor Location Register).
Das MSC ubernimmt die Vermittlung der Verbindungen zwischen den MS. Es kann
als digitale ISDN-Vermittlungsstelle mit Zusatzfunktionen verstanden werden, da es
neben den typischen Aufgaben eines Vermittlungsknotens auch fur das Mobilitatsma-
nagement zustandig ist. Die MSCs und BSCs sind untereinander uber die A-Schnittstelle
verbunden, ein Gateway MSC (GMSC) verfugt uber zusatzliche Schnittstellen zu ex-
ternen Netzwerken wie z.B. ISDN oder offentliche Datennetze.
Die wichtigste Datenbank in GSM ist das HLR, das alle relevanten Informatio-
nen uber die Teilnehmer zentral speichert. Diese Daten umfassen die Telefonnummer
(Mobile Subscriber International Service Directory Number, MSISDN), die nutzba-
ren Dienste sowie die auch auf der SIM hinterlegten Ki und IMSI. Zusatzlich werden
temporare Informationen im HLR abgelegt, die der Standortbestimmung dienen.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 6
Jedem MSC ist ein VLR zugeordnet, das die relevanten Informationen uber die MS
der MSC vorhalt. Sobald eine MS in das geographische Gebiet des MSC eintritt, werden
die Teilnehmerdaten vom HLR in das entsprechende VLR kopiert und aus dem alten
VLR geloscht. Dadurch wird eine zu haufige Aktualisierung und damit Uberlastung
des HLR vermieden.
2.1.1.4 Betriebs- und Wartungssystem
Der Vollstandigkeit halber sei das OMS erwahnt, das sich in drei Elemente gliedert. Das
OMC (Operation and Maintenance Center) uberwacht das Netzwerk und verwaltet es.
Mit dem HLR eng verbunden ist das AuC (Authentication Centre), das Sicherheits-
mechanismen zum Schutz der Teilnehmer bereitstellt. Im EIR (Equipment Identity
Register) schließlich sind alle IMEI fur einen bestimmten Netzbetreiber hinterlegt. Mit
Hilfe schwarzer Listen konnen gestohlen gemeldete MEs gezielt gesperrt werden.
2.1.2 Multiplexverfahren
GSM-Mobilfunknetze sind leitungsvermittelte Kommunikationsnetze, d.h. die Kom-
munikationsverbindung wird uber eine dedizierte Leitung zwischen den Teilnehmern
hergestellt. Diese Vorgehensweise ist identisch zu den drahtgebundenen Festnetzen mit
dem Unterschied, dass die Teilnehmer in einem Mobilfunknetz uber Funk angebun-
den sind. Damit es bei einem gleichzeitigen Zugriff auf das Ubertragungsmedium nicht
zu Interferenzen oder gar Verbindungsabbruchen kommt, setzt GSM aus der Ubertra-
gungstechnik bekannte Multiplexverfahren ein.
2.1.2.1 Raummultiplexverfahren
Das Raummultiplexverfahren (Space Division Multiple Access, SDMA) wird bei nahe-
zu allen Funknetzen eingesetzt. Dabei deckt jeder Sender einen bestimmten raumlichen
Bereich ab. In GSM bilden mehrere MS und eine BTS eine Funkzelle. Diese zellula-
re Infrastruktur ermoglicht die Wiederverwendung bestimmter Frequenzen in einem
geeigneten Abstand vom Sender. Abbildung 2.2 stellt schematisch ein zellenbasier-
tes Systems mit idealisierten hexagonalen Zellen anhand von zwei unterschiedlichen
Gruppierungen dar.[30] Jede Gruppierung enthalt disjunkte Sendefrequenzen aus der
zur Verfugung stehenden Bandbreite. Da innerhalb der Zelle nur wenig Frequenzbe-
reiche zur Verfugung stehen und damit die Anzahl der MS beschrankt ist, variiert die
Große der Zellen. In einer Großstadt wird der Zellradius daher kleiner gewahlt als in
landlichen Regionen.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 7
Abbildung 2.2: Zellulares Funksystem mit 3er-und 7er-Gruppierungen
Bewegt sich die MS wahrend einer bestehenden Verbindung in eine andere Zelle,
wird sie ohne Abbruch der Verbindung an die neue BTS durch den Handover-Vorgang
ubergeben. Eine Ubergabe kann auch auf Grund eines qualitativ schlechter werdenden
Signals oder zur besseren Verteilung der Netzlast stattfinden. Dazu fuhren MS und
BTS periodisch Messungen der Netzqualitat durch und schicken die Daten an das
BSC. GSM unterscheidet nach [30] mehrere Ubergabearten, bei denen je nach Bedarf
entweder BSC oder MSC das Handover initiieren.
2.1.2.2 Frequenzmultiplexverfahren
Beim Mehrfachzugriff durch Frequenzmultiplex (Frequency Division Multiple Access,
FDMA) wird das verfugbare Frequenzband in einzelne Frequenzkanale aufgeteilt. Bei
bidirektionaler Kommunikation werden zwei Kanale benotigt, einer fur die Kommu-
nikation der MS zur BTS (Uplink) und einer fur den umgekehrten Weg (Downlink).
Diese Trennung wird als Frequenzduplex (Frequency Division Duplex, FDD) bezeich-
net. In Deutschland steht GSM 900 jeweils ein Frequenzband mit 25 MHz Breite in
einem Abstand von 45 MHz zur Verfugung, das in 124 Frequenzkanale zu je 200 kHz
aufgeteilt wird. Fur den Uplink liegen die Kanale zwischen 890,2 und 915 MHz, fur
den Downlink wird das Frequenzband zwischen 935,2 und 960 MHz verwendet.
2.1.2.3 Zeitmultiplexverfahren
Das Zeitmultiplexverfahren (Time Division Multiple Access, TDMA) unterteilt den
Ubertragungskanal zeitlich in feste, sich wiederholende Zeitschlitze (engl.: Timeslots).
Jeder Teilnehmer bekommt dadurch nur zu einem bestimmten Zeitpunkt und fur eine
festgelegte Zeitspanne Zugriff auf den gemeinsamen Kanal.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 8
In GSM 900 wird TDMA auf den Frequenzkanal angewendet. Der 200 kHz breite
Kanal mit der Dauer von 4,615 ms wird in 8 Timeslots zu je 577 µs unterteilt. In
Abbildung 2.3 ist der durch die Anwendung von FDMA und TDMA resultierende
Rahmen dargestellt.[30]
Abbildung 2.3: TDMA-Rahmen in GSM
Um Kosten auf Seite der MS zu sparen, wurde festgelegt, dass die BSS ihre Infor-
mationen immer drei Zeitschlitze vor der MS ubertragt. Damit benotigt die MS nur
eine Antenne und muss nicht gleichzeitig senden und empfangen konnen.
2.1.3 Logische Kanale in GSM
Jeder physikalische Kanal kann durch seinen Zeitschlitz und die Tragerfrequenz be-
schrieben werden. Ein logischer Kanal bildet sich durch die Zuordnung zu einem physi-
kalischen Kanal, dabei konnen mehrere logische Kanale denselben physikalischen Kanal
nutzen. GSM definiert zwei grundlegende Arten logischer Kanale.
2.1.3.1 Verkehrskanale
Verkehrskanale (Traffic Channel, TCH) ubertragen alle Nutzdaten zwischen den Teil-
nehmern wie Sprache oder Daten. Es gibt zwei unterschiedliche Varianten des TCH,
den Full-Rate TCH (TCH/F) und den Half-Rate TCH (TCH/H). Ein TCH/F hat
eine Bruttodatenrate von 22,8 kbit/s, ein TCH/H entsprechend die Halfte. Die Uber-
tragung der digitalisierten Sprache erfordert bei Verwendung des Full Rate Codecs
(FR) 13 kbit/s, die verbleibende Bandbreite wird zur Fehlerkorrektur eingesetzt. Fort-
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 9
geschrittene Kompressionsverfahren erlauben geringere Datenraten und ermoglichen
damit die Ubertragung uber TCH/H.
Fur die Datenubertragung im GSM-Netz stehen verschiedene logische Kanale mit
unterschiedlichen Datenraten zur Verfugung, TCH/F4,8 mit 4,8 kbit/s, TCH/F9,6 mit
9,6 kbit/s und TCH/F14,4 mit 14,4 kbit/s. Die hohere Bandbreite wird dabei zu Lasten
der Fehlerkorrektur erreicht.
2.1.3.2 Signalisierungskanale
GSM verfugt uber eine Vielzahl von Signalisierungskanalen (Control Channel, CCH),
die dem Management des Funknetzes dienen. CCHs tauschen zwischen MS und BTS
in uni- oder bidirektionaler Richtung Informationen aus. Da CCH im weiteren Verlauf
der Arbeit keine wesentliche Rolle spielen, sei an dieser Stelle auf [29] verwiesen.
2.1.4 Datenubertragung
GSM stellt generell Tragerdienste (Bearer Services) und Teledienste (Teleservices) be-
reit. Teleservices beschreiben die anwendungsabhangige Kommunikation zwischen den
Nutzern unter Einsatz aller Schichten des ISO/OSI-Referenzmodells (International Or-
ganization for Standardization/Open Systems Interconnection). Dazu zahlen z.B. Tele-
fonie, SMS (Short Message Service) und Fax. Tragerdienste sind anwendungsunabhan-
gige Transportdienste, bei denen nur die untersten Schichten benotigt werden. Sie bie-
ten Moglichkeiten fur asynchrone und synchrone sowie leitungs- und paketvermittelte
Datenubertragung. Daruber hinaus konnen die Bearer Services im transparenten und
nichttransparenten Modus betrieben werden. Ein transparenter Tragerdienst benutzt
lediglich Funktionen der ersten Schicht des ISO/OSI-Modells, ein nichttransparenter
Tragerdienst benutzt Protokolle der Schichten 2 und 3.
2.1.4.1 Circuit Switched Data – CSD
Die leitungsvermittelte Datenubertragung (CSD) nutzt die Verkehrskanale TCH/F.
Damit wird fur die Datenubertragung ein exklusiver, bidirektionaler Kanal reserviert,
der eine konstante Verzogerungszeit zwischen Senden und Empfangen eines Daten-
blocks aufweist sowie eine konstante Bandbreite.
TCH/F9,6 stellt 9,6 kbit/s fur Nutzdaten und 2,4 kbit/s fur Signalisierungsinfor-
mationen zur Verfugung, TCH/F14,4 entsprechend 14,4 kbit/s und 0,1 kbit/s. Die
Differenz zu der Datenrate des TCH/F von 22,8 kbit/s wird im transparenten Modus
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 10
fur die FEC (Forward Error Correction) benutzt. In der TRAU werden dazu redun-
dante Informationen hinzugefugt und umgeordnet (engl.: Interleaving), so dass der
Empfanger fehlerhafte Ubertragung erkennt und u.U. korrigieren kann. Im nichttrans-
parenten Modus wird die Kommunikation zusatzlich zur FEC durch das Radio Link
Protocol (RLP) gesichert. Auf dem Weg von MS zu GMSC erfahrt die Datenrate hau-
figere Anpassungen, um auf die Datenrate der A-Schnittstelle von 64 kbit/s konvertiert
zu werden.
Eine Erweiterung von CSD ist High Speed Circuit Switched Data (HSCSD), dass
durch Kanalbundelung eine hohere Bandbreite erreicht. Dazu fordert die MS mehre-
re TCH/F an, belegt also mehr Ressourcen im TDMA-Rahmen. Die Zuordnung kann
asymmetrisch erfolgen, d.h. fur den Uplink konnen weniger Zeitschlitze verwendet wer-
den. Theoretisch konnte HSCSD alle acht Zeitschlitze eines TCH/F14,4 belegen und
wurde damit maximal 115,2 kbit/s erreichen. Praktisch ist die MS aber nicht in der
Lage, gleichzeitig zu senden und zu empfangen (siehe Abschnitt 2.1.2.3). Daher kon-
nen nur bis zu vier Zeitschlitze reserviert werden, die eine Datenrate von maximal
57,6 kbit/s realisieren.
2.1.4.2 Internetzugang
Die bisher beschriebenen Dienste verrichtet GSM auf den untersten Schichten des
ISO/OSI-Modells. Bei der transparenten Datenubertragung kommt nur Schicht 1 (Bit-
ubertragungsschicht) zum Einsatz. Um das Schicht-3-Protokoll IP (Internet Protocol)
als Voraussetzung fur internetbasierte Dienste zu nutzen, bedarf es eines Protokolls
oberhalb der physikalischen Schicht, das IP die benotigten Dienste zur Verfugung stellt.
Die beiden Protokolle SLIP (Serial Line Internet Protocol) und PPP (Point-to-Point
Protocol) konnen in der Schicht 2 (Sicherungsschicht) eingesetzt werden, um IP-Pakete
uber eine serielle Schnittstelle zu transportieren. Im Gegensatz zu SLIP, das nur IP
kapselt, unterstutzt PPP auch andere Netzwerkprotokolle.
Samtliche durch die IETF (Internet Engineering Task Force) im Request for Com-
ments RFC 1122 [9] definierte, auf IP aufbauende Protokolle des Internets lassen sich
somit auch auf der MS nutzen. Abbildung 2.4 stellt ein nach [34] und [17] entwickeltes,
vereinfachtes Schichtenmodell der Internetnutzung uber CSD dar, wobei der GMSC
die Verbindung zum Internet Service Provider (ISP) mittels V.90-Modem herstellt.
TCP (Transmission Control Protocol) ist als zuverlassiges, verbindungsorientiertes
Protokoll der Transportschicht durch RFC 793 [25] standardisiert. Die Zuverlassigkeit
wird u.a. durch Bestatigung jedes korrekt empfangenen Paketes erreicht. Bei Paketver-
lusten geht TCP davon aus, dass sie aufgrund einer Netzwerkuberlastung zuruckgestellt
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 11
Abbildung 2.4: Protokollarchitektur der leitungsvermittelten Internetnutzung uberGSM
wurden. Den Gegebenheiten einer drahtlosen Anbindung wird dies nur bedingt gerecht,
da hier temporare Verbindungsabbruche auftreten konnen. Des Weiteren erhoht sich
durch die Funkverbindung die Latenzzeit, fur echtzeitkritische Anwendungen ist TCP
uber GSM daher ungeeignet.
Die Anbindung an das paketvermittelte Datennetz X.25 spielt nur eine untergeord-
nete Rolle und bedarf keiner weiteren Betrachtung.
2.1.4.3 WAP – Wireless Application Protocol
WAP wurde mit dem Ziel entwickelt, Komponenten und Protokolle zu definieren,
die Internetinhalte auf mobilen Endgeraten darstellen. Neben der Anpassung an die
Mobilfunkumgebung, d.h. geringere Bandbreite, kleines Display, eingeschrankte Ein-
gabemoglichkeiten etc., spielte die Interoperabilitat mit bestehenden Systemen eine
wichtige Rolle. Die WAP-Architektur baut auf den verschiedenen Tragerdiensten auf,
WAP definiert keine bestimmte. Somit kann die Datenubertragung uber CSD, HSCSD
oder den noch vorzustellenden GPRS und UMTS erfolgen. Oberhalb des Bearer Service
orientiert sich die Architektur an der des Internets, d.h. die verwendeten Protokolle in
Transport-, Sicherheits-, Transaktions-, Sitzungs- und Applikationsschicht greifen auf
Internetstandards zuruck und erweitern sie.
Werden Webseiten von einer MS angefordert, ubersetzt ein WAP-Gateway die Seiten
in eine eigene Markup-Language, so sie denn nicht schon in dieser vorliegen.
Neben dem bekannten Pull-Prinzip, d.h. der Client ruft Informationen von dem Ser-
ver ab, definiert WAP auch einen Push-Dienst. Dabei initiiert ein Server den”Push“
und transferiert uber ein Gateway Inhalte zur MS. Als Tragerdienst fur die Ubertra-
gung von Gateway zur MS wird SMS verwendet, da dies die einzige Moglichkeit ist, die
MS zu jedem Zeitpunkt aus dem GSM-Netz zu erreichen. Typische Push-Inhalte sind
Nachrichten, Verkehrsmeldungen oder Borsendaten. Außerdem kann eine URI (Uni-
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 12
form Resource Identifier) enthalten sein, die vom Client automatisch oder erst nach
Bestatigung aufgerufen wird. Hierbei handelt es sich dann um einen Push-Pull-Dienst,
wie er beispielsweise bei MMS eingesetzt wird.
Die maximale Große einer Push-Nachricht ist auf die zulassige Große einer SMS
beschrankt. Uberschreitet die Nachricht die festgelegte Große, wird sie segmentiert in
mehreren SMS ubertragen.
2.2 GPRS – General Packet Radio Service
Durch die zunehmende Verbreitung des Internets Mitte der 90er Jahre wurden die
Nachteile der leitungsvermittelten Datenubertragung in GSM offensichtlich. Deshalb
wurde mit GPRS eine flexiblere und leistungsfahigere Datenubertragung eingefuhrt.
Der wesentliche Unterschied zu CSD besteht in der Art der Datenvermittlung, GPRS
transferiert die Daten paketvermittelt und lastet das Netz damit besser aus als CSD.
Im Gegensatz zur Leitungsvermittlung werden nur dann Ressourcen allokiert, wenn
Daten gesendet werden. Es besteht kein dedizierter Kanal, das Datenpaket wird uber
mehrere Netzknoten zum Empfanger geschickt. Dadurch konnen Datenrate und Ver-
zogerungszeit schwanken, fur die Datenubertragung ist das jedoch nicht von großem
Nachteil. Um trotzdem eine bestimmte Dienstgute (Quality of Service, QoS) zu garan-
tieren, wurden Parameter fur die Bestimmung der Netzqualitat eingefuhrt.
GPRS unterstutzt die”always-on“-Funktionalitat, d.h. die MS befindet sich standig
im GPRS-Netzwerk – die Abrechnung erfolgt daher meist nach dem ubertragenen
Volumen und nicht nach der benotigten Zeit.
2.2.1 Systemarchitektur
Die bekannte und in Abschnitt 2.1.1 vorgestellte GSM-Architektur wird fur GPRS
um die Packet Control Unit (PCU) sowie das GPRS-Kernnetz mit den Serving GPRS
Support Nodes (SGSN) und den Gateway GPRS Support Nodes (GGSN) erweitert –
siehe Abbildung 2.5.
GSM und GPRS existieren nebeneinander, ohne die Funktion des jeweils anderen
Netzwerkes zu beeintrachtigen. Dadurch wird es der MS ermoglicht, gleichzeitig GSM-
und GPRS-Dienste zu benutzen. Der GPRS Standard teilt die Endgerate dafur in drei
Klassen ein. MS der Klasse A konnen in beiden Netzen gleichzeitig aktiv sein, wah-
rend MS der Klasse C nur einen Dienst anbieten. Gerate der Klasse B konnen sowohl
bei GSM als auch bei GPRS angemeldet sein, aber konnen nicht gleichzeitig auf die
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 13
Abbildung 2.5: Systemarchitektur von GPRS
Dienste zugreifen. Empfangt die MS wahrend einer Datenubertragung via GPRS einen
Telefonanruf via GSM, wird die Datenubertragung unterbrochen und automatisch nach
Beendigung des Gesprachs wieder aufgenommen.[29]
2.2.1.1 Packet Control Unit – PCU
Im kanalvermittelten GSM-Netz wird der Handover bei aktiver Verbindung durch den
BSC bestimmt. Da bei GPRS nur dann Ressourcen belegt werden, wenn sie beno-
tigt werden, kann der BSC nur diffizil zwischen aktiven und nicht-aktiven Phasen
unterscheiden – die Entscheidung uber einen Handover erscheint nicht zweckmaßig. In
GPRS wird daher auf diesen Vorgang verzichtet und anstelle dessen das Cell Update
definiert.[17] Diese Aufgabe ubernimmt die PCU, die oftmals fester Bestandteil der
BSC ist, aber auch an BTS oder SGSN angeschlossen sein kann – je nach Position der
TRAU.
Das wird durch die zweite wichtige Funktion der PCU bedingt: Die Konvertierung
der von der SGSN kommenden Paketdaten in PCU-Rahmen, die dasselbe Format ha-
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 14
ben wie die TRAU-Rahmen und damit transparent von BSC zu BTS weitergeleitet
werden konnen.
2.2.1.2 Serving GPRS Support Node – SGSN
Der SGSN ist das Bindeglied zwischen Radionetzwerk und GPRS-Netzwerk. Er ist mit
mehreren PCUs verbunden und erledigt die Vermittlungsaufgaben innerhalb des Net-
zes. Er kann somit als Aquivalent des leitungsvermittelnden MSC angesehen werden.
Das MSC wird in GPRS nur noch fur die Signalisierung benutzt.
Die wichtigste Aufgabe des SGSN ist das Weiterleiten der von der PCU kommenden
Datenpakete an andere SGSNs oder den GGSN und umgekehrt. Fur die richtige Zu-
ordnung eines Datenpaketes zur MS hat der SGSN Zugriff auf das HLR. Als Transport-
protokoll zwischen den GSNs kommt IP zum Einsatz, womit der SGSN grundsatzlich
genauso arbeitet wie ein Router in einem IP-Netzwerk. Mit den PCU kommuniziert
der SGSN uber Frame Relay (FR).
Als weitere Aufgaben sind Verschlusselung, Datenkomprimierung, Gebuhrenerfas-
sung sowie Mobilitats- und Sitzungsmanagement (GPRS Mobility Management/Sessi-
on Management, GMM/SM) zu nennen. Fur das GMM/SM implementiert der SGSN
eine eigene Datenbank und verzichtet auf das VLR. Wichtige Funktionen des GMM
sind die GPRS-Attach-Prozedur, d.h. die Anmeldung der MS am GPRS-Netz und das
Update der Routingtabelle bei Zellwechsel.
Das SM ist zustandig fur die Verwaltung der PDP-Kontexte (Packet Data Protocol),
darauf wird in Abschnitt 2.2.3.1 eingegangen.
2.2.1.3 Gateway GPRS Support Node – GGSN
Die Verbindung zwischen externem Paketdatennetz (Public Data Network, PDN) und
GPRS-Netz stellt der GGSN her. Als PDN konnen IP- oder X.25-Netze zum Einsatz
kommen, hauptsachlich jedoch das Internet. Die GSN haben eigene IP-Adressen, daher
erscheint der GGSN vom PDN aus gesehen wie ein normaler Router.
Der GGSN ist fur die Vergabe eines PDP-Kontexts zustandig und ist anschließend fur
die MS der feste Bezugspunkt der Verbindung. Mit dem Wunsch nach Aktivierung des
PDP-Kontexts durch die MS werden dieser PDP-Adresse und einige Ubertragungs-
parameter wie QoS-Profile zugewiesen. Das wichtigste PDP ist IP, die Vergabe der
IP-Adresse ist Thema des Abschnitts 2.2.3.1.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 15
2.2.2 Protokollarchitektur
Abbildung 2.6 zeigt das Schichtenmodell fur GPRS. Wie in Abschnitt 2.1.4.2 beschrie-
ben, setzt IP in der Vermittlungsschicht auf den Protokollen der unteren Schichten auf,
auf die im Folgenden nicht naher eingegangen wird.
In der Sitzungsschicht liegt das GPRS Tunnelling Protocol (GTP), das sowohl auf
UDP (User Datagram Protocol) als auch TCP aufsetzen kann. Alle Daten im GPRS-
Kernnetz werden in GTP gekapselt ubertragen, um ein zu haufiges Aktualisieren der
Routingtabellen zu vermeiden. Bei Positionsanderung muss dem GGSN nur die IP-
Adresse des neuen SGSN mitgeteilt werden.[29]
Abbildung 2.6: Protokollarchitektur von GPRS [29]
Bei einer Ende-zu-Ende-Verbindung werden die IP-Pakete von der MS transparent
durch das GPRS-Netzwerk an den GGSN weitergeleitet und dem PDN ubergeben. Die
darunter liegende Infrastruktur ist dabei uninteressant. Auf dem umgekehrten Weg
leiten die PDN Pakete an den GGSN, der den der MS zugeordneten SGSN ermittelt
und uber diesen die Pakete zur MS schickt.[30]
Dabei erfahrt das IP-Paket durch Segmentierung sowie Umrahmung mit Header
und Footer standig Anderungen. Abbildung 2.7 stellt die Paketrahmen der einzelnen
Schichten auf Seite der MS dar.
2.2.3 Datenubertragung
Einerseits wird eine hohere Ubertragungsgeschwindigkeit bei GPRS durch das Multi-
plexen mehrerer Zeitschlitze erzielt. Effizienter ist jedoch der Einsatz neuer Kanalko-
dierungsverfahren, CS-1 (Coding Scheme) bis CS-4. Die Idee hinter den neuen Ver-
fahren ist eine adaptive Anpassung der FEC an die Signalqualitat. Dadurch wird die
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 16
Abbildung 2.7: Packet-Framing in der GRPS Protokollarchitektur [34]
Redundanz im 22,8 kbit/s schmalbandigen Kanal gesenkt und die Anzahl der Nutzda-
tenbits innerhalb des 456 Bit umfassenden TRAU-Rahmens erhoht. CS-1 hat die beste
Fehlerkorrektur, wahrend bei CS-4 keine FEC eingesetzt wird, dafur ist bei CS-4 der
Durchsatz am hochsten. Das passende Kodierschema wird durch die PCU kontrolliert.
Tabelle 2.1 gibt die wichtigsten Eckdaten der vier Kodierschemen wieder.
Kodier- Nutzdaten- Datenrate pro max. Datenrateschema bits Zeitschlitz (8 Zeitschlitze)
CS-1 160 9,05 kbit/s 72,4 kbit/sCS-2 240 13,4 kbit/s 107,2 kbit/sCS-3 288 15,6 kbit/s 124,8 kbit/sCS-4 400 21,4 kbit/s 171,2 kbit/s
Tabelle 2.1: GPRS Coding Schemes
Die tatsachlich zur Verfugung stehende Bandbreite ist allerdings um einiges geringer,
was den technischen Fahigkeiten der MS geschuldet ist. Da gleichzeitiges Empfangen
und Senden mit den wenigsten Geraten moglich ist, konnen maximal funf Zeitschlitze
belegt werden, die sich auf Down- und Uplink aufteilen. GPRS-fahige MS werden dazu
in 12 Gerateklassen eingeteilt, die in Tabelle 2.2 aufgefuhrt sind. Ein Gerat der Klasse 8
nutzt 4 Slots fur den Down- und 1 Slot fur den Uplink und kann somit bei Verwendung
von CS-2 53,6 kbit/s erreichen. Die Multislot-Klasse 10 bietet zusatzlich noch 1 Slot
in Uplink-Richtung, kann aber trotzdem nur maximal 5 Zeitschlitze allokieren.
Auf der Luftschnittstelle besitzt GPRS eigene logische Kanale. Das Pendant zu den
TCH stellen die unidirektionalen PDTCH (Packet Data Traffic Channel) dar, welche
die eigentlichen Nutzdaten ubertragen.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 17
Multislot- ZeitschlitzeKlasse Downlink Uplink Summe
1 1 1 22 2 1 33 2 2 34 3 1 45 2 2 46 3 2 47 3 3 48 4 1 59 3 2 510 4 2 511 4 3 512 4 4 5
Tabelle 2.2: GPRS Multislot-Klassen [17]
2.2.3.1 Zuweisung der IP-Adresse
Nach dem durchgefuhrten GPRS-Attach muss die MS einen PDP-Kontext beantragen,
um mit dem PDN Daten austauschen zu konnen. Parameter dieses Kontexts sind der
PDP-Typ, PDP-Adresse der MS, QoS-Profil, Auswahl eines NSAPI (Network Service
Access Point Identifier) und optionale Nennung eines Zugangspunktes (Access Point
Name, APN). Als PDP-Typ ist z.B. IPv4 moglich, die PDP-Adresse ist dann eine
IPv4- bzw. IP-Adresse. PDP-Adressen konnen neben der Zuweisung bei Aktivierung
des PDP-Kontexts auch statisch zugewiesen werden. Mit NSAPI wird es der MS theo-
retisch ermoglicht, bis zu 11 PDP-Kontexte gleichzeitig aktiviert zu haben und dadurch
parallel mehrere Dienste zu nutzen. Der APN schließlich gibt den als Zugangspunkt
dienenden GGSN an.
In Abbildung 2.8 ist der Aktivierungsablauf fur die Verbindung in das Internet dar-
gestellt. Die MS teilt dem SGSN mit der ersten Nachricht den Wunsch nach einem
PDP-Kontext mit und ubergibt ihm den gewunschten APN. Im Anschluss daran wer-
den Sicherheitsfunktionen wie Authentifikation des Teilnehmers durchgefuhrt. Falls
ihm der Zugang erlaubt ist, leitet der SGSN den PDP-Kontext an das zustandige
GGSN weiter. Teil dieser Nachricht ist der Tunnel Identifier (TID), die aus der IMSI
des Teilnehmers und der NSAPI zusammengesetzt wird. Der GGSN vergibt nun fur den
PDP-Kontext eine IP-Adresse und sendet diese an den SGSN zuruck. Daruber hinaus
erzeugt es einen Eintrag in seiner PDP-Kontexttabelle, um Pakete zwischen PDN und
SGSN routen zu konnen. Der SGSN aktualisiert ebenfalls seine PDP-Kontexttabelle
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 18
und teilt der MS die zugewiesene IP-Adresse mit. Wahrend der Aktivierungsprozedur
stimmen MS und SGSN sowie GGSN das QoS-Profil ab. Die MS kann die Aktivierung
daraufhin abbrechen, sollte ihr der QoS nicht genugen.
Abbildung 2.8: PDP-Kontextaktivierung
Bewegt sich die MS mit aktivem PDP-Kontext in das Gebiet eines neuen SGSN,
fordert der neue SGSN vom alten den PDP-Kontext an. Anschließend werden die
Routingtabellen aktualisiert, die der MS zugewiesene IP-Adresse bleibt dabei bestehen.
Der GGSN teilt u.U. der MS eine IP-Adresse aus dem fur private Zwecke reser-
vierten Adressbereich zu und bildet diese dann auf seine offentliche Adresse ab.[30] In
Tabelle 2.3 sind die in RFC 1918 [26] festgelegten privaten IP-Adressen aufgefuhrt.
Die so genannte NAT (Network Address Translation) ist ein in IP-Netzwerken hau-
fig eingesetztes Verfahren aufgrund der Knappheit der IP-Adressen, standardisiert in
RFC 3022 [31]. Zu beachten ist, dass Pakete mit privaten IP-Adressen nicht durch das
Internet geroutet werden.
Klasse IP-Adressbereich
A 10.0.0.0 - 10.255.255.255 (10.0.0.0/8)B 172.16.0.0 - 172.31.255.255 (172.16.0.0/12)C 192.168.0.0 - 192.168.255.255 (192.168.0.0/16)
Tabelle 2.3: Private IP-Adressbereiche
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 19
2.2.3.2 Teilnehmeridentifikation
Innerhalb des Netzwerkes werden die Datenpakete auf verschiedene Weise identifi-
ziert, dargestellt in 2.9. Auf der Abis-Schnittstelle wird der Teilnehmer durch den 3 Bit
langen TFI (Temporary Flow Identifier) adressiert, im Radio-Netzwerk durch die P-
TMSI (Packet-Temporary Mobile Subscriber Identity) und zwischen den GSN uber die
TID. [29]
Abbildung 2.9: Identifikation der Datenpakete eines Teilnehmers
2.2.4 EDGE – Enhanced Data Rates for Global Evolution
EDGE ist eine Weiterentwicklung von HSCSD und GPRS und ist damit sowohl fur
leitungs- als auch paketvermittelte Dienste geeignet. Durch einen Wechsel des Modula-
tionsverfahrens sowie neuen Coding Schemes erzielt EDGE eine Bruttodatenrate von
etwa 69 kbit/s pro GSM Kanal und 554 kbit/s bei Nutzung aller 8 Zeitschlitze. Die
Nettodatenrate liegt bei maximal 384 kbit/s.[33]
EDGE verwendet die gleichen Frequenzen wie GSM, aufgrund des neuen Modulati-
onsverfahrens bedarf es jedoch einer Anderung an MS und BSC, um EDGE einzusetzen.
In Deutschland hat sich EDGE noch nicht durchsetzen konnen, T-Mobile plant je-
doch laut Presseberichten den Einsatz.[7]
2.3 UMTS – Universal Mobile Telecommunications
System
UMTS zahlt zu Mobilfunknetzen der dritten Generation (3G), da es ahnlich wie sein
Vorganger GSM (2G) eine komplett neue Infrastruktur fur den Betrieb benotigt. So-
wohl GPRS und EDGE als auch HSCSD gelten als Zwischenschritt auf dem Weg zu
UMTS, das langfristig GSM als zellulares Mobilfunksystem ersetzen wird.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 20
2.3.1 Systemarchitektur
Wie GSM ist UMTS ein hierarchisches System. Das 3GPP hat mehrere Spezifikatio-
nen herausgegeben, wie die Netzarchitektur aufzubauen ist. So tragt der oftmals als
Release 99 referenzierte Standard dem Wunsch nach großer Kompatibilitat zu GSM
Rechnung. Das Kernnetz ist dem von GSM gleich, alle verwendeten Protokolle und
Schnittstellen sind bereits durch die Einfuhrung von GPRS spezifiziert worden.
Neu hinzugekommen ist das UMTS Terrestrial Radio Access Network (UTRAN),
das eine neue Radio-Schnittstelle definiert, die Datenraten bis zu 2 MBit/s ermogli-
chen soll.[34] Hierzu wird ein neues Mehrfachzugriffsverfahren (Wide Code Division
Multiple Access, W-CDMA) auf einer Frequenzbandbreite von 5 MHz realisiert. Als
Basisstation fungiert in UTRAN das Node B, mehrere davon sind an den Radio Net-
work Controller (RNC) angebunden und bilden gemeinsam mit ihm das Radio Network
Subsystem (RNS). Die RNS sind untereinander und mit dem Kernnetz verbunden. In
Abbildung 2.10 ist ein UMTS-Netzwerk dargestellt, dass UTRAN und GSM Zugriff
gestattet. Auf die Beschriftung der Schnittstellen der Steuerkanale wurde aus Grunden
der Ubersichtlichkeit verzichtet. Der RNC ist als Aquivalent zum BSC zu verstehen,
der Node B ist ahnlich der BTS.[30] Wenngleich in UMTS neue Aufgaben und Proto-
kolle fur die Netzelemente definiert wurden, wird darauf in dieser Arbeit nicht naher
eingegangen.
Als weitere Kernnetze standardisierte das 3GPP ATM- (Asynchronous Transfer Mo-
de) und IP-basierte Netze. Ab der zweiten Ausbauphase von UMTS, Release 2000,
werden die leitungsvermittelten Dienste uber ein PDN transportiert werden.
2.3.2 Datenubertragung
Im Wesentlichen ist die Datenubertragung in UMTS die Weiterentwicklung von GPRS.
UMTS definiert eine Vielzahl neuer physikalischer und logischer Kanale zur Datenuber-
tragung. Der in Abschnitt 2.3.1 genannte Durchsatz von 2 MBit/s ließ sich in der Praxis
noch nicht nachweisen, realistischer sind Datenraten bis zu 384 kbit/s.
Mit HSDPA (High Speed Downlink Packet Access) ist als Zwischenschritt zu 4G-
Mobilfunknetzen eine Erweiterung von UMTS verabschiedet worden, die unter La-
borbedingungen Transferraten von 14,4 MBit/s erreicht. In der Praxis sollen die ers-
ten Endgerate mit einer Spitzendatenrate von ca. 3,6 MBit/s aufwarten konnen. Das
breitbandigere Uplink-Pendant ist HSUPA (High Speed Uplink Packet Access), dessen
Spezifikation noch nicht abgeschlossen ist.[37]
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 21
Abbildung 2.10: Systemarchitektur von UMTS
2.4 Bluetooth
Bluetooth ist ein von der IEEE (Institute of Electrical and Electronics Engineers)
mit der Norm 802.15.1 verabschiedeter Standard fur die drahtlose Vernetzung von
Geraten uber kurze Distanz. Die Nutzung des lizenzfreien 2,4 GHz-Bands, periodische
Frequenzsprunge und eine Datenrate von 723,2 kbit/s zeichnen Bluetooth aus. Die
Ubertragungsrate konnte mit Bluetooth 2.0 auf 2,1 MBit/s nahezu verdreifacht werden.
Bei Bluetooth erfolgt die binare Datenubertragung uber eigens definierte Profile,
denen das OBEX-Protokoll (Object Exchange) zugrunde liegt.
Diplomarbeit Frank Felgner
2 Kommunikationsschnittstellen eines mobilen Endgerates 22
2.5 WLAN – Wireless Local Area Network
Der Industriestandard IEEE 802.11 beschreibt ein drahtloses LAN (Local Area Net-
work), das samtliche im LAN eingesetzten Techniken adaptiert. WLAN nutzt ebenfalls
das 2,4 GHz-Band, allerdings ist die Reichweite um ein vielfaches hoher als bei Blue-
tooth. Zudem liegt die Bandbreite mit bis zu 108 MBit/s in der Großenordnung von
Ethernet-LAN.
Fur Anpassungen an das WLAN musste das ISO/OSI-Referenzmodell in den unters-
ten zwei Schichten modifiziert werden, damit bleiben die oberen Schichten mit ihren
Protokollen und Schnittstellen erhalten. Um Daten zu transferieren, lassen sich die
Gerate Ad-hoc miteinander verbinden oder uber eine Infrastruktur an andere Netze
koppeln. Dabei steht die Nutzung der auf IP-basierenden Protokolle und Dienste im
Vordergrund.
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 23
3 Symbian OS – ein Betriebssystem
fur Smartphones
Im bisherigen Verlauf dieser Arbeit wurde die Definition eines mobilen Endgerates
allgemein gehalten. Die in Kapitel 2 behandelten Schnittstellen treffen somit auf eine
Vielzahl von Geraten zu. Im Folgenden bezeichnen sowohl mobiles Endgerat als auch
MS das Smartphone.
Als Smartphones werden diejenigen Gerate bezeichnet, die herkommliche Mobil-
telefone, d.h. Handys, um Funktionen eines PDA erweitern. Der großte Unterschied
zwischen Handy und Smartphone liegt im Betriebssystem. Wahrend es auf Handys
nur rudimentare Funktionen implementiert, benotigt ein Smartphone aufgrund seiner
komplexeren Hardware ein Betriebssystem ahnlich dem eines Rechners. Es soll stabil
und sicher laufen sowie sparsam mit den zur Verfugung stehenden Ressourcen umge-
hen. Entwicklern wird das Programmieren eigener Applikationen unter Einsatz aller
Funktionen des Betriebssystems ermoglicht, was bisher mit Java Anwendungen nur
eingeschrankt moglich war.
Das mit ca. 60% Marktanteil [6] erfolgreichste Betriebssystem ist Symbian OS, ein
Derivat des PDA-Betriebssystems EPOC. Eine eher untergeordnete Rolle spielen Win-
dows Mobile von Microsoft, PalmOS von Palm Source sowie Linux.
In diesem Kapitel wird auf die verschiedenen Versionen des Symbian OS eingegan-
gen, die Systemarchitektur erlautert und der Entwicklungsprozess eigener Software
veranschaulicht.
3.1 Versionen
Mit Symbian OS v6.0 wurde 2000 die erste eigene, offizielle Version von Symbian OS
veroffentlicht. Die hohe Versionsnummer ist durch das Vorgangerbetriebssystem EPOC
bedingt. Da die Entwicklung der Smartphones stetig voran schreitet und neue Anfor-
derungen an das Betriebssystem stellt, existieren unterschiedliche Versionen von Sym-
bian OS.
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 24
Smartphones mit der Version 6.1 konnen leitungsvermittelt in GSM- und HSCSD-
sowie paketvermittelt in GPRS-Systemen kommunizieren, unterstutzen OBEX und
verstehen Protokolle wie TCP/IP und WAP. Daruber hinaus sind eine Vielzahl von
Bild- und Audioformaten integraler Bestandteil.
Die Kommunikation mit EDGE sowie einigen 3G-Netzwerken ist in Version 7.0 ein-
gefuhrt worden. Weitere wichtige Neuerungen betreffen MMS und verbesserte Multi-
mediafahigkeiten wie z.B. die Unterstutzung von Videos. Version 7.0s integriert UMTS
sowie mehrere PDP-Kontexts.
In Version 8.0 wird der bisherige Kernel EKA1 durch EKA2 ersetzt, der bessere Echt-
zeitfahigkeit implementiert. Um die Abwartskompatibilitat zu gewahrleisten, werden
beide Versionen fortgefuhrt: EKA1 als 8.0a und EKA2 als 8.0b.
Symbian OS v9.1 enthalt erstmals Schutzmechanismen gegen schadliche Softwa-
re, verbessert die Bluetooth-Implementierung und unterstutzt nativ das Streaming-
Protokoll RTP (Realtime Transport Protocol). Als neue Kommunikationsschnittstelle
wird WLAN eingefuhrt.
3.2 Aufbau von Symbian OS
Die folgenden Abschnitte geben einen nach [35, 12] entwickelten Uberblick uber den
strukturellen Aufbau von Symbian OS, um die durch die begrenzten Ressourcen be-
dingten Einschrankungen gegenuber anderen Betriebssystemen besser darlegen zu kon-
nen.
3.2.1 Hardwareressourcen
Die Hardware von Smartphones besteht wie bei jedem Rechner aus Prozessor (CPU),
Speicher (RAM und ROM) und Ein-/Ausgabegeraten (I/O-Gerate) sowie der Strom-
quelle.
Symbian OS wurde fur eine 32-Bit CPU mit niedriger Taktrate und geringem Strom-
verbrauch entwickelt. Bisher verwendete Prozessoren sind CPUs der ARM-Architektur
(Acorn RISC Machine) mit Taktraten von 52 MHz bis 220 MHz.
Im ROM (Read Only Memory) sind Betriebssystem sowie Middleware und Anwen-
dungen enthalten, gangige Großen sind z.B. 12 MB und 16 MB. Unter Symbian OS
kann der Inhalt im ROM auf zwei Arten erreicht werden. Zum einen ist er auf direktem
Weg adressierbar, zum anderen sind die enthaltenen Daten als Datei uber den Lauf-
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 25
werksbuchstaben Z: erreichbar. Programme konnen dadurch direkt ausgefuhrt werden,
ohne vorher in den RAM (Read Access Memory) geladen zu werden.
Fur Smartphones typische RAM-Großen liegen zwischen 4 und 32 MB. Symbian OS
verwaltet den RAM je nach Bedarf einerseits als Arbeitsspeicher fur ausgefuhrte Pro-
gramme sowie den Kernel und andererseits uber den Laufwerksbuchstaben D: als RAM-
Disk.
Der Flash-Speicher des Smartphones steht als Laufwerk C: zur Verfugung. Er enthalt
nutzerspezifische Daten sowie Programme und Dateien.
Falls dieser nicht ausreicht, besitzen viele Smartphones mindestens einen Slot fur die
Aufnahme von Speicherkarten. Diese werden dann unter Symbian OS aufsteigend als
E: angesprochen. Weitere I/O-Gerate sind das Display, die Tastatur sowie alle außeren
Schnittstellen, die zum Teil in Kapitel 2 thematisiert wurden.
3.2.2 Systemkomponenten
Abbildung 3.1 stellt die Systemarchitektur von Symbian OS dar, die sich in die drei
Bereiche Basis, Middleware und Anwendungskomponenten gliedert.
Abbildung 3.1: Systemkomponenten von Symbian OS [12]
3.2.2.1 Basis
Die Basis des Symbian OS wird gebildet aus Geratetreibern, File- und Windows-Server
sowie E32, zu der Kernel und Benutzerbibliothek zahlen. E32 ist die zentrale Kompo-
nente des Systems. Der Kernel verwaltet die Hardwareressourcen und kontrolliert den
Zugriff anderer Anwendungen auf diese Ressourcen. Er besitzt die hochsten Privile-
gien im System und ist der am hochsten priorisierte Thread. Fur den Zugriff auf die
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 26
Ressourcen fuhrt die CPU die Routinen des Kernels im Kernel-Mode aus, Anwen-
dungen werden im User-Mode ausgefuhrt und haben keinen direkten Zugriff auf die
Hardware, sondern konnen nur uber den Kernel darauf zugreifen. Die Schnittstelle
zwischen Kernel- und User-Mode stellt die Benutzerbibliothek zur Verfugung.
Eine Besonderheit in Symbian OS ist das Client-Server-Framework. Der Server ver-
waltet eine oder mehrere Ressourcen und stellt dem Client seine Dienste uber eine
API-Schnittstelle (Application Programming Interface) bereit. Diese Trennung ermog-
licht die unterschiedliche Privilegierung von Server und Client, um hardwarenahe Pro-
grammierung zu erlauben, ohne die Integritat des Betriebssystems zu gefahrden. Die
wichtigsten Vertreter sind der File-Server fur Dateioperationen sowie der Windows-
Server fur die Verwaltung der Benutzereingaben und des Displays.
3.2.2.2 Middleware
Als Middleware werden in Symbian OS alle Komponenten verstanden, die anwen-
dungsunabhangige API-Schnittstellen zur Verfugung stellen. Dadurch bleibt die inter-
ne, komplexe Struktur des Systems verborgen, dem Entwickler wird das Erstellen von
Anwendungen erleichtert.
Das Application Framework ist eine der wichtigsten Komponenten, da es u.a. samt-
liche Elemente fur die grafische Benutzerfuhrung (Graphical User Interface, GUI) ent-
halt. Auf Symbian OS bauen zwei verschiedene Application Frameworks auf, UIQ von
UIQ Technology und Series 60 von Nokia. Zudem bauen Series 80 und Series 90 auf
Symbian OS auf. Da Series 80 jedoch fur Mobiltelefone mit vollstandiger Tastatur kon-
zipiert ist und damit uber die Definition eines Smartphones hinausgeht, wird auf eine
weitere Betrachtung verzichtet. Series 90 fallt durch sein großes Display ebenfalls in
eine andere Gattung von mobilen Geraten.
Series 60, auch S60 genannt, wird von Nokia in verschiedenen Varianten benutzt. Ta-
belle 3.1 gibt einen Uberblick uber die unterschiedlichen Versionen. Die in der Tabelle
angegebenen Feature Packs passen bestehende Editionen an neue Versionen von Sym-
bian OS an, d.h. erweitern sie um neue Funktionen.[23] UIQ setzt auf Symbian OS v7.0
auf.
UIQ und S60 unterscheiden sich im Erscheinungsbild. Displays von S60-Smartphones
haben mindestens eine Auflosung von 176x208 Pixel, ab Version 2.8 werden auch
240x320 und 352x416 unterstutzt. UIQ-Displays haben eine Große von 208x320 bzw.
240x320 Pixel. Sie sind fur die Eingabe per Stift optimiert, S60 unterstutzt die Steue-
rung uber die Zifferntastatur, Navigationskreuz und zwei Softkeys.
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 27
S60-Plattform Version Symbian OS
S60 1st Edition 1.0 v6.1S60 1st Edition Feature Pack 1 1.2 v6.1S60 2nd Edition 2.0 v7.0sS60 2nd Edition Feature Pack 1 2.1 v7.0sS60 2nd Edition Feature Pack 2 2.6 v8.0aS60 2nd Edition Feature Pack 3 2.8 v8.1aS60 3rd Edition 3.0 v9.0
Tabelle 3.1: Varianten der Series-60-Plattform
UIQ wird u.a. in den Smartphones von Sony und Motorola benutzt, Series 60 kommt
zusatzlich zu den Geraten von Nokia auch auf denen von Siemens und Samsung zum
Einsatz.
3.2.2.3 Anwendungskomponenten
Die Anwendungskomponenten befinden sich oberhalb der Middleware und beinhalten
die auf dem Smartphone installierten Anwendungen. Auch Java-Runtime ist bereits
integraler Bestandteil von Symbian OS. S60 und UIQ erhalten neben dem GUI bereits
eine Vielzahl von Applikationen, z.B. Organizer, Browser oder Medienbetrachter.
3.2.3 Speicherverwaltung
Beim Start einer Applikation unter Symbian OS wird ein neuer Prozess mit einem
Haupt-Thread kreiert. Wahrend der Laufzeit des Prozesses konnen weitere Threads
gestartet werden. Jeder Thread verfugt uber einen Stack mit einer initialen Große von
12 kB. Ein Wachsen des Stacks uber diese Grenze fuhrt zu einem Speicheruberlauf und
beendet den Thread sofort.
Bei dem Aufruf einer Unterroutine legt der Stack alle ubergebenen Parameter, lo-
kale Variablen sowie den Ruckgabewert ab und loscht diese bei Verlassen wieder. Fur
große Variablen und Objekte steht jedem Thread ein Heap von 2 MB Große bereit.
Das Allokieren und Deallokieren von Heap-Speicher unterliegt der Kontrolle des Pro-
grammierers.
3.2.4 Ereignisbehandlung
Die Entwicklung von grafischen Oberflachen erforderte ein Umdenken in der Software-
entwicklung. Statt bisher in bestimmten Situationen auf die Eingabe des Benutzers zu
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 28
agieren, musste nun auf eine bestimmte Eingabe des Benutzers entsprechend reagiert
werden. Diese Art der Software wird als ereignisgesteuert bezeichnet.
Symbian OS ist auf die effiziente Abwicklung von Ereignissen optimiert. Dafur stehen
dem Programmierer so genannte aktive Objekte (engl.: Active Objects) zur Verfugung.
Jedes aktive Objekt besitzt eine RunL()-Funktion, die aufgerufen wird, sobald ein
Ereignis eintritt, fur das das Objekt zustandig ist. Innerhalb der RunL()-Funktion wird
das Ereignis analysiert und darauf in geeigneter Weise reagiert. Die Abarbeitung hat
schnell zu erfolgen, so dass das aktive Objekt u.U. neue Ereignisse verarbeiten kann.
In der Praxis wird RunL() daher die Abarbeitung anderen Prozeduren ubertragen. Der
Abschnitt 5.3.3 erklart die Funktionsweise aktiver Objekte detaillierter.
3.2.5 Fehlerbehandlung
Symbian OS muss wie jedes Betriebssystem auf bestimmte Fehlersituationen reagieren.
Ist in dem Programm keine entsprechende Reaktion vorgesehen, sturzt es ab (engl.: pa-
nicked). Der Haupt-Thread wird geschlossen und gibt alle Ressourcen frei, was zum
Datenverlust fuhrt. Fehlersituationen sollten daher von dem Programm abgefangen
werden.
3.3 Softwareentwicklung unter Symbian OS
Um Software fur Symbian OS zu entwickeln, bietet Symbian unter [8] die Software De-
velopment Kits (SDK) seiner verschiedenen Versionen an. Ein SDK ist eine Sammlung
von Programmen und Werkzeugen, die dem Programmierer das Entwickeln von Soft-
ware ermoglicht. Zudem sind die API-Schnittstellen zu den einzelnen Komponenten
umfangreich dokumentiert. Dabei verfolgt das SDK ein modulares Konzept, so dass
der Programmierer nur die benotigten Module einbinden muss. Des Weiteren integriert
sich das SDK auch in gangige Entwicklungsumgebungen (Integrated Development En-
vironment, IDE).
Primar werden Anwendungen fur Symbian OS in der objektorientierten Program-
miersprache C++ geschrieben, aber auch Java, Python oder die Basic-ahnliche OPL
(Open Programming Language) sind mit einigen Funktionseinschrankungen moglich.
3.3.1 Ubersicht der Dateien im Entwicklungsprozess
Die wichtigsten Dateien im Entwicklungsprozess sind die Quellcodes. Bei C++ enden
sie auf .cpp fur den eigentlichen Programmcode oder auf .h fur die Klassendefinitionen.
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 29
Um die Definition von GUI-Elementen vom Quellcode zu separieren, existieren Res-
sourcedateien mit der Endung .rss. Damit wird eine flexiblere Anderung des GUI
sichergestellt, da zum einen die Anwendung nicht erneut kompiliert werden muss. Zum
anderen spart die Trennung Speicherplatz. Ein weiterer Vorteil ist die einfachere Uber-
setzung von Textinhalten in andere Sprachen.
Fur die einfache Lokalisierung einer Anwendung gibt es die .loc-Datei. Sie ent-
halt die notigen Definitionen, die vor dem Kompiliervorgang durch den Praprozessor
auf den Quellcode angewendet werden. Das Resultat ist eine Anwendung mit mehre-
ren Ressourcedateien, die dem Benutzer gestattet, bei der Installation die Sprache zu
wahlen.
Die .mmp-Datei ist von immenser Bedeutung fur den Ubersetzungsprozess. Sie ent-
halt alle wichtigen Informationen uber die Applikation; dazu zahlen verwendete Res-
sourcen und Bibliotheken, Zielpfad, Sprache sowie Anwendungstyp. Mogliche Typen
sind Anwendung mit GUI, Server oder Geratetreiber. Ferner definiert die .mmp-Datei
den aus drei 32-Bit-Werten bestehenden UID. Dabei identifiziert der dritte Wert der
Unique ID die Anwendung weltweit. Er kann kostenlos bei Symbian beantragt werden,
fur Testzwecke sind 0x01000000-0x0fffffff reserviert.
Nach der Kompilierung liegen die Quelldateien als .app, die Ressourcedateien als
.rsc vor. Die Package-Datei .pkg enthalt zusatzlich zu den Namen dieser Dateien die
Versionsnummer der Anwendung sowie die unterstutzten Sprachen.
Mithilfe der .pkg-Datei wird im letzten Schritt des Prozesses die Installationsdatei
mit der Endung .sis erzeugt, die auf das Smartphone geladen und installiert werden
kann.
Wahrend dieses Entwicklungsprozesses kommen diverse, mit dem SDK mitgelieferte
Programme zum Einsatz, die durch die IDE obsolet werden und daher nicht betrachtet
wurden. An dieser Stelle sei auf [10, 12] verwiesen.
3.3.2 Besonderheiten bei Symbian OS
Die Programme fur Symbian OS werden zwar auf einem Desktoprechner entwickelt,
laufen jedoch auf anderen Zielplattformen. Fur diese konnen drei verschiedene ausfuhr-
bare Dateien generiert werden – ARM4, ARMI und THUMB. THUMB verwendet ein
16-Bit-Befehlssatz und ist nicht kompatibel zu dem 32-Bit-Instruktionsset von ARM4.
Eine ARMI-Binardatei arbeitet mit beiden Befehlssatzen.[10]
Weitere Besonderheiten resultieren aus Abschnitt 3.2.3. Da die Gefahr gegeben ist,
dass die Große des Stacks bei haufigem Aufruf von Unterroutinen bzw. Funktionen
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 30
nicht ausreicht, werden in Symbian OS vorrangig Referenzen oder Pointer als Para-
meter ubergeben. Große Variablen und Objekte sollten wegen des nur 12 kB großen
Stacks auf den Heap abgelegt und im Quellcode uber Pointer referenziert werden. In
C++ geschieht die Allokierung mittels new und die Deallokierung uber delete. Ein
Pointer, der nach der Deallokierung noch auf dieses Objekt zeigt, ist ungultig und fuhrt
zum Absturz des Threads.
Strings und Binardaten verbrauchen viel Speicherplatz und sind umstandlich zu
verarbeiten. Deshalb stellt Symbian OS fur diese Datentypen so genannte Deskriptoren
bereit, die im ROM, Stack oder Heap liegen konnen. Deskriptoren sind speichereffizient,
komfortabel zu benutzen und vermeiden Speicheruberlaufe. Sie enthalten neben ihren
Daten auch deren Speicheradresse und Lange. Bei der Zeichenverarbeitung erleichtern
sie den Umgang mit Unicode, das von Symbian OS unterstutzt wird und 2 Byte pro
Zeichen belegt. Deskriptor-Klassen leiten sich von TDesC ab. Die im ROM liegenden
String-Deskriptoren werden uber das Makro _LIT (literal, dt.: wortlich) angelegt.
3.3.3 Namenskonventionen
Symbian OS legt einige Konventionen fur die im Quellcode verwendeten Namen fest,
die auch das SDK einhalt. API-Schnittstellen sind dadurch verstandlicher. Das Ein-
halten der Konventionen ist jedoch keine Bedingung fur ein erfolgreiches Ubersetzen
des Quellcodes.
3.3.3.1 Klassen
Klassen nutzen einen Prafix-Buchstaben, um ihre Funktion zu verdeutlichen. Tabel-
le 3.2 beschreibt diese.
Prafix Beschreibung
T Werteklasse, die wie ein Datentyp agiertC von CBase abgeleitete, Heap-allokierte KlasseR Server-Klasse, die auf Ressourcen des Betriebssystems zugreiftM Interface-Klasse, die Methoden anderer Klassen virtuell implementiert
Tabelle 3.2: Namenskonventionen in Symbian OS – Klassen
3.3.3.2 Variablen und Konstanten
Zur besseren Ubersichtlichkeit erhalten auch Variablen sowie Konstanten einen Prafix-
Buchstaben, diese sind in Tabelle 3.3 aufgefuhrt.
Diplomarbeit Frank Felgner
3 Symbian OS – ein Betriebssystem fur Smartphones 31
Prafix Beschreibung
K KonstanteE Konstante in einer Enumerationi Membervariable einer Klassea Argument bzw. Parameter, der einer Funktion ubergeben wird
kein Prafix lokale VariableGroßbuchstabe globale Variable
Tabelle 3.3: Namenskonventionen in Symbian OS – Variablen
3.3.3.3 Funktionen
Funktionsnamen konnen frei gewahlt werden. Da eine Klasse meist gekapselt ist, d.h. Zu-
griff auf ihre Membervariablen nur uber Methoden ermoglicht, sollte diesen entspre-
chend ihrer Funktion ein Set bzw. Get vorangestellt werden.
Eine Funktion, die wegen einer Fehlersituation aussteigen kann, wird in Symbian OS
durch das Anhangen eines L (leave, dt.: aussteigen) gekennzeichnet. Bei dem Ausstieg
verwaisen Heap-allokierte Ressourcen. Um diesen Speicherplatz wieder freizugeben,
stellt Symbian OS einen Cleanup-Stack zur Verfugung. Die dort liegenden Objekte
werden beim Ausstieg automatisch deallokiert. Nutzt eine Funktion diesen Cleanup-
Stack, wird das Kurzel LC angehangt.
Makros werden in Versalien geschrieben.
3.3.4 Emulator
Die Symbian-SDKs haben einen Emulator im Lieferumfang, der das Testen und De-
buggen von Applikationen auf der Entwicklungsplattform ermoglicht. Der Emulator
bildet die Umgebung des Smartphones nach, es sind sehr viele der in Abschnitt 3.2.2
genannten Komponenten vorhanden.
Die unter dem Emulator liegende x86-Architektur ist nicht kompatibel zur ARM-
Architektur, der Befehlssatz nicht so strikt. Dadurch konnen auf dem Emulator fehler-
frei funktionierende Applikationen auf dem Smartphone Fehler produzieren.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 32
4 Kommunikationskonzept
Das Ziel dieses Kapitels ist die Entwicklung eines Kommunikationskonzepts zur Uber-
tragung von multimedialen Inhalten zwischen zwei Smartphones mit Symbian OS und
folgenden Anforderungen. Die Daten sollen als Push-Dienst direkt zwischen den MS
ausgetauscht werden, dabei bezeichnet MS1 den Sender und MS2 den Empfanger. Zu-
dem soll eine indirekte Kommunikation realisiert werden. Anstelle von MS1 sendet
dann ein Server die multimedialen Daten an MS2. MS1 teilt dem Server dazu mit,
welche Daten er ubertragen soll.
Auf Empfangerseite soll keine Interaktion mit dem Benutzer stattfinden, MS2 nimmt
die Datei entgegen und verarbeitet sie bei erfolgreicher Ubertragung entsprechend.
Abbildung 4.1 stellt das zu realisierende Kommunikationssystem aus Anwendersicht
dar.
Abbildung 4.1: Das Kommunikationssystem aus Anwendersicht
In den folgenden Abschnitten werden zuerst die etablierten Systeme zur Ubertragung
von multimedialen Daten zwischen MS auf die genannten Anforderungen uberpruft.
Anschließend wird das Kommunikationskonzept anhand von noch festzulegenden Kri-
terien erstellt. Dabei werden mogliche Probleme erlautert und deren Losungen prasen-
tiert.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 33
4.1 Multimedia-Ubertragungssysteme fur MS
MS neuerer Generation verfugen uber zwei Moglichkeiten, multimediale Inhalte unter-
einander zu tauschen. Einerseits der Versand einer MMS und andererseits das Uber-
tragen von Daten uber Bluetooth. Die Betrachtung von Blackberry entfallt, da diese
Technologie primar fur den”Push“ von E-Mails genutzt wird. Zudem liegt das verwen-
dete Protokoll nicht offen.
4.1.1 MMS
MMS unterstutzt eine Vielzahl an Bilder-, Video- und Audioformaten.[14] Die Ver-
knupfung der Inhalte wird durch die Markup-Sprache SMIL (Synchronized Multimedia
Integration Language) definiert. MMS basiert auf IP und unterstutzt somit alle dar-
unter liegenden Bearer Services, wie CSD oder GPRS. Bei Nutzung von GPRS fuhrt
MS1 zum Senden einer MMS-Nachricht an MS2 die in Abschnitt 2.2.3.1 beschriebene
PDP Kontextaktivierung durch. Dafur steht ein eigener APN zur Verfugung. Anschlie-
ßend sendet MS1 die MMS uber die POST-Methode von HTTP (Hypertext Transfer
Protocol) zum MMS-Server (Multimedia Messaging Service Center, MMSC), der MS2
via WAP-Push uber die bereitliegende MMS benachrichtigt. MS2 holt die MMS uber
HTTP GET vom MMSC und stellt sie dar. Dies kann sowohl manuell durch Nutzerin-
teraktion als auch automatisch geschehen. MMS ist somit ein Push-Pull-Dienst und
von der Funktionalitat mit E-Mail vergleichbar.
Daruber hinaus ist MMS wie sein Vorganger SMS ein Store-and-forward System.
Der Benutzer von MS1 hat keine Kontrolle, wann seine Nachricht MS2 erreicht.[14]
Eine direkte Verbindung zwischen den MS ist nicht moglich.
Die maximale Große einer MMS ist derzeit 300 kB. Sie hangt vom jeweiligen Netz-
betreiber sowie von der verwendeten MS ab und kann demnach weit unter diesem Wert
liegen.
Innerhalb Deutschlands kostet der Versand einer MMS unabhangig von der Große
momentan 39 Cent, der Empfang ist kostenlos. Durch die Nutzung des eigenen APN
konnen die Netzbetreiber den Datenverkehr fur den MMS-Versand getrennt von dem
der Internetnutzung abrechnen.
Symbian OS ab Version 7.0 unterstutzt mit seinen APIs zwar MMS. Aufgrund der
genannten Einschrankungen erfullt MMS jedoch nicht die gestellten Anforderungen an
die Kommunikation.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 34
4.1.2 OBEX
Aufgrund der geringen Reichweite von maximal 100 m eignet sich OBEX bzw. Blue-
tooth nur fur eine Ad-hoc-Vernetzung, eine flachendeckende Verfugbarkeit ist nicht
gegeben. Bluetooth ist dadurch fur ortsbezogene und personalisierte Dienste prades-
tiniert. Sobald eine MS in die Reichweite eines fest installierten Bluetooth-Senders
kommt, werden die Multimedia-Daten auf diese MS ubertragen und dort verarbeitet.
Wie in Abschnitt 2.4 schon kurz aufgefuhrt, definieren Bluetooth-Profile den Da-
tenaustausch. Das benotigte Generic Object Exchange Profile wird von Symbian OS
unterstutzt.[21] Auch der Einsatz eines Servers zum Datentransfer ist mit verhaltnisma-
ßig geringen Anschaffungskosten moglich. Trotz der genannten Vorteile ist Bluetooth
fur das definierte Szenario eher ungeeignet, da die Kommunikation zwischen den MS
auch uber großere Distanzen stattfinden soll.
4.2 Auswahl der Kommunikationsschnittstelle
In Kapitel 2 wurden die Kommunikationsschnittstellen einer MS beschrieben, aus de-
nen in den folgenden Abschnitten anhand von mehreren Kriterien die geeigneteste
selektiert wird.
4.2.1 Festlegung der Kriterien
Es wird davon ausgegangen, dass MS2 zu jedem Zeitpunkt Daten empfangen bzw. MS1
Daten senden kann, d.h. sowohl eine gute Flachendeckung als auch die Verfugbarkeit
wahrend einer Gesprachsverbindung muss gegeben sein. Die Mobilitat der MS darf
zudem nicht eingeschrankt werden.
Ein weiteres wichtiges Kriterium ist die Geschwindigkeit, mit der die Daten ubertra-
gen werden. Auch wenn die Bandbreite nicht mit der zeitgemaßer Internetanschlusse
zu vergleichen ist, konnen Multimedia-Daten einen, fur die begrenzten Ressourcen der
MS, beachtlichen Umfang erzielen.
Die Interoperabilitat zwischen verschiedenen MS sowie Server sollten ebenso unter-
sucht werden. Hierbei spielen auch Flexibilitat und Erweiterbarkeit der eingesetzten
Technologien eine Rolle.
Damit muss sich zum einen der Push-Dienst realisieren lassen. Zum anderen muss
die Kommunikation zeitnah durchgefuhrt werden. Wenn MS1 die Daten sendet, soll
MS2 diese sofort empfangen.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 35
Zudem werden in die Auswertung die anfallenden Kosten eingehen. Dies betrifft feste
und variable Kosten gleichermaßen, sowohl fur die MS als auch fur den Server.
Symbian OS unterstutzt eine Vielzahl der Kommunikationsschnittstellen, fur die
Programmierung mussen deshalb die notwendigen APIs in dem SDK hinreichend do-
kumentiert sein.
4.2.2 Analyse der Schnittstellen
Der Verzicht auf Bluetooth wurde bereits in Abschnitt 4.1.2 diskutiert und durch die
aufgestellten Kriterien belegt. An dieser Stelle wird ebenso auf eine detaillierte Ana-
lyse des WLAN verzichtet. Die Grunde dafur sind die schlechte Flachendeckung und
die geringe Anzahl der unterstutzten MS, obgleich die große Bandbreite fur die Uber-
tragung multimedialer Daten pradestiniert ware. Zudem ist die API nur unzureichend
dokumentiert.
Als mogliche Kommunikationsschnittstellen verbleiben somit die leitungsvermittelte
Datenubertragung via CSD sowie die paketvermittelte Datenubertragung uber GPRS,
EDGE oder UMTS.
4.2.2.1 Leitungsvermittelte Datenubertragung
Bei der direkten Kommunikation wurde MS1 die Daten uber einen dedizierten Kanal an
MS2 ubertragen. Die Adressierung erfolgt uber die MSISDN von MS2, unterscheidet
sich somit nicht von dem Ruf zum Aufbau von Gesprachsverbindungen. Die Appli-
kation auf MS2 kann dann im Hintergrund den Datenruf annehmen und die Daten
empfangen. Symbian OS stellt dazu die notige API mit ETel bereit.
Die exklusive Verbindung garantiert eine konstante Bandbreite und eine konstan-
te Verzogerungszeit zwischen Senden und Empfangen der Datenblocke. Solange der
Datenstrom konstant ist, wird das Um-Interface effizient ausgelastet.
Allerdings erreicht GSM bzw. CSD keine hohen Datenraten, 1,2 kB/s mit TCH/F9,6
bzw. 1,8 kB/s mit TCH/F14,4 zu Lasten der Fehlerkorrektur. Schlechte Funkverbin-
dungen reduzieren diesen Wert zusatzlich. HSCSD kann durch Kanalbundelung zwar
theoretisch 57,6 kBit/s bzw. 7,2 kB/s erzielen, belegt aber zusatzliche Kapazitaten auf
der Luftschnittstelle.
Fur die indirekte Kommunikation wird der Server an das offentliche Festnetz an-
geschlossen. Das mogliche Szenario liefe wie folgt ab. MS1 initiiert einen Ruf an den
Server und ubertragt die relevanten Daten. Der Server beendet anschließend die Ver-
bindung zu MS1 und baut die dedizierte Verbindung zu MS2 auf. MS2 erhalt die
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 36
Daten demnach sowohl bei der direkten als auch bei der indirekten Kommunikation
uber einen Push-Dienst.
Nachteilig ist, dass nur ein dedizierter Kanal aufgebaut werden kann. D.h. wahrend
der Datenubertragung sind weder MS noch Server zur Durchfuhrung parallel statt-
findender Kommunikation im Stande. Damit ist MS2 auch nicht zu jedem Zeitpunkt
erreichbar. Neben der schlechten Flexibilitat ist zudem die Erweiterbarkeit des Systems
nicht gegeben. CSD bzw. HSCSD werden auch in Zukunft keine hoheren Datenraten
erzielen.
Die Abrechnung der ubertragenen Daten erfolgt nach der benotigten Zeit. MS2 ent-
stehen keine Kosten, MS1 und der Server zahlen den in ihrem Netz gultigen Minuten-
preis. Anschaffungskosten fallen nur auf Serverseite an.
4.2.2.2 Paketvermittelte Datenubertragung
Eine effizientere Nutzung der Luftschnittstelle wird durch die Paketvermittlung er-
reicht. Ressourcen werden nur dann belegt, wenn sie benotigt werden, d.h. wenn Daten
ubertragen werden. Die MS kann sich dadurch standig im Paketnetz befinden, ohne
Kapazitaten zu belegen. Dadurch ist zudem der fur CSD typische, lang andauernde
Verbindungsaufbau obsolet.
Da GPRS auf GSM aufbaut, ist eine sehr gute Flachendeckung gewahrleistet. UMTS
und EDGE bieten diese zum jetzigen Zeitpunkt noch nicht. Als verwendetes PDP hat
sich in den paketvermittelten Mobilfunknetzen IP durchgesetzt, um die Kompatibilitat
zum Internet zu gewahrleisten. Die Nutzung paketvermittelter Datenubertragung ist
somit flexibel und erweiterbar – 4G-Mobilfunknetze werden komplett auf IP basieren.
Zudem wird die Datenrate stetig ansteigen. Die Interoperabilitat ist eine der Starken
des paketorientierten Ansatzes. Es macht fur die MS keinen Unterschied, in welchem
Funknetz sich der Kommunikationspartner befindet.
GPRS ermoglicht parallel zum Datentransfer die Nutzung der GSM-Dienste, so es
die MS unterstutzt. UMTS und EDGE bieten ahnliche Funktionalitat. Ein weiterer
Vorteil des paketorientierten Ansatzes betrifft den Datenverlust bei Verbindungsab-
bruchen. Wahrend die leitungsvermittelte Datenubertragung durch schlechte Signal-
qualitat abgebrochen wird, wird die paketvermittelte nur unterbrochen. Sobald sich
die MS wieder an einer Zelle anmeldet, wird der Transfer der Pakete fortgesetzt.
Nachteilig wirkt sich die Paketvermittlung auf Bandbreite und Latenz aus. Da jedes
Paket einen anderen Weg durch das PDN wahlen kann, ist die Konstanz der beiden
Parameter nicht garantiert. Das PDN bietet jedoch verschiedene Mechanismen, um eine
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 37
hohe Netzqualitat sicherzustellen. Im Vergleich zur Leitungsvermittlung wird außerdem
Overhead pro gesendetem Paket erzeugt.
Durch die”always-on“-Funktionalitat erfolgt die Abrechnung ublicherweise nach dem
ubertragenen Volumen in Datenblocken, ein verbreiteter Preis sind 19 Cent pro 10 kB.
Zusatzlich bieten die Netzbetreiber in Deutschland Flatrates mit einem Inklusivvo-
lumen an, mit denen sich die Kosten senken lassen. Bei der direkten Kommunikation
zahlen MS1 und MS2 ihren jeweiligen Datenverkehr, bei der indirekten Kommunikation
fallen auf Serverseite keine weiteren Kosten an. Der Server kann problemlos mit diver-
sen MS gleichzeitig kommunizieren, ebenso wie MS1 theoretisch Daten zu mehreren
MS2 senden konnte.
4.2.3 Zusammenfassung
In Tabelle 4.1 ist die Bewertung der diskutierten Schnittstellen anhand einiger Kriterien
dargestellt. Dabei gibt die Downloadrate die theoretisch erzielbare Geschwindigkeit an,
die in der Praxis nicht erreicht wird. Trotzdem soll sie als Vergleichskriterium dienen.
Kriterium leitungsvermittelt paketvermitteltCSD HSCSD GPRS EDGE UMTS
Verfugbarkeit flachendeckend im Ausbauandere Dienste nutzbar sequentiell sequentiell/parallel parallelmax. Downloadrate (kbit/s) 14,4 115,2 171,2 384 384..2048Abrechnung nach... benotigter Zeit DatenvolumenKapazitatsauslastung fest flexibelDatenubertragung Push-Dienst Push- und Pull-Dienst moglichVerbindungsaufbau notwendig
”always-on“
Symbian OS v6.1 v7.0 v7.0s
Tabelle 4.1: Bewertung der Kommunikationsschnittstellen
Aufgrund der hohen Verfugbarkeit sowie der Flexibilitat und Erweiterbarkeit wird
GPRS als Kommunikationsschnittstelle und das Internet als PDN gewahlt. Gleichzeitig
wird ein System geschaffen, dass die hohen Datenraten von UMTS und EDGE nutzen
kann, wenn diese ihre letzte Ausbaustufe vollendet haben und flachendeckend verfugbar
sind.
Bei GPRS ist jedoch zu beachten, dass bei der direkten Kommunikation die maximal
erreichbare Geschwindigkeit von der Anzahl der Uplink-Zeitschlitze abhangt, siehe Ab-
schnitt 2.2.3. Eine MS1 der Multislot-Klasse 10 kann hochstens 2 Slots allokieren und
bei Verwendung von CS-2 eine maximale Ubertragungsrate von 26,8 kbit/s erzielen,
auch wenn MS2 theoretisch die Daten schneller empfangen konnte.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 38
4.3 Entwicklung des Kommunikationsprotokolles
Wie in Abschnitt 2.2.2 erlautert, lassen sich mit GPRS alle auf IP aufbauenden Pro-
tokolle verwenden. Ausgehend von dem Transportprotokoll wird in den folgenden Ab-
schnitten ein Protokoll entwickelt, dass den Anforderungen genugt. WAP ist ungeeig-
net, da es primar fur die Ubertragung von Internetinhalten auf mobile Gerate konzipiert
wurde.
4.3.1 Transportprotokoll
Als Transportprotokoll kommen das verbindungsorientierte TCP sowie das verbin-
dungslose UDP in Frage. Das UDP-Paket wird gemaß seiner Definition in RFC 768 [24]
ohne Verbindungsaufbau zum Empfanger geschickt. Eine Bestatigung des Empfangs
findet nicht statt. Dies impliziert zum einen, dass Pakete in anderer Reihenfolge ein-
treffen konnen als sie gesendet wurden. Zum anderen ist nicht garantiert, dass sie
uberhaupt ankommen. UDP hat einen geringen Protokoll-Overhead und eignet sich
fur zeitkritische Internetanwendungen wie Streaming, ist jedoch fur die Datenubertra-
gung zwischen zwei MS ungeeignet. Denn die Bestatigung uber den korrekten Empfang
ist von fundamentaler Bedeutung fur die Kommunikation.
TCP bietet die benotigten Sicherungsmechanismen, d.h. quittiert den Empfang des
Paketes und stellt sicher, dass die gesendeten Pakete in der richtigen Reihenfolge beim
Empfanger eintreffen. Die in Abschnitt 2.1.4.2 aufgefuhrten Probleme von TCP in
Funknetzen sind fur die gestellten Anforderungen nicht von Relevanz. Sie werden
ausfuhrlich in [34] analysiert. Ein nicht zu vernachlassigender Nachteil von TCP im
GPRS-Netz ist der Protokoll-Overhead, der pro Datenpaket zwischen 50 und 60 By-
tes betragen kann – siehe Abschnitt 2.2.2. Ein langes Datenpaket erzeugt durch seine
Segmentierung in kleinere LLC- und RLC/MAC-Rahmen signifikanten Overhead. Eine
Paketlange von 500 Bytes mit einem Overhead von ca. 50 Bytes hat demnach eine um
10 Prozent verminderte Nutzdatenrate. Trotzdem ist TCP als Transportprotokoll fur
die Kommunikation zwischen MS geeignet.
Etablierte Anwendungsprotokolle wie HTTP oder FTP (File Transfer Protocol) wer-
den nicht verwendet. FTP ware fur die Datenubertragung pradestiniert, scheidet je-
doch aufgrund der fehlenden Implementierung unter Symbian OS als Moglichkeit aus.
Die eigene Umsetzung eines Servers ware fur den Einsatzzweck zu aufwandig. HTTP-
Server sind hingegen in der Entwicklung, u.a. unter [22]. Ein Push-Dienst ließe sich
uber HTTP POST realisieren, der Overhead durch den Header ware immens. Zudem
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 39
ist HTTP ein zustandsloses Protokoll, d.h. der Client ist nicht persistent mit dem
Webserver verbunden.
Auf MS2 wird daher nur ein TCP-Socket geoffnet, das auf eingehende Verbindun-
gen wartet und die empfangenen Daten entsprechend verarbeitet. Dabei werden vor
den eigentlichen Nutzdaten noch deskriptive Daten ubertragen, die in Abschnitt 4.3.4
entwickelt werden. Fur MS2 ist es unbedeutend, ob die Kommunikation auf direktem
oder indirektem Weg erfolgt.
Der gewahlte TCP-Port fur diese Anwendung ist 7000, d.h. sowohl Server als auch
MS2 horen auf diesem Port.
4.3.2 Zuweisung von IP-Adresse zu MSISDN
Wahrend der Sitzung bleibt durch die Kapselung in GTP die IP-Adresse der MS gleich,
auch wenn sie die Funkzelle wechselt. Wollen sich die Kommunikationspartner zu MS2
verbinden, benotigen sie dessen IP-Adresse, haben jedoch nur dessen MSISDN. Die
Teilnehmer werden innerhalb des GPRS-Netzes unterschiedlich identifiziert, siehe Ab-
schnitt 2.2.3.2. Nur der GGSN kennt die IP-Adresse der MS, der SGSN nutzt bereits
die TID. Auf die Zuweisung von MSISDN zu IP-Adresse hat die MS keinen Zugriff.
Daher muss eine eigene Losung gefunden werden.
4.3.2.1 Dynamischer DNS
Das hierarchische Domain Name System (DNS) ist eines der wichtigsten Dienste im
Internet und zustandig fur die Translation von Hostnamen der Notation domain.tld
(Top Level Domain, TLD) in IP-Adressen. DNS Datenbanken sind in Resource Records
organisiert, u.a. der Address Record (A) mit der IP-Adresse der Domain und der Name
Server Record (NS) mit dem fur die Domain zustandigen, autorativen Nameserver.
Alle die Domain betreffenden DNS-Anfragen aus dem Internet werden an den NS
ubergeben. Dieser kann zusatzlich Subdomains der Notation subdomain.domain.tld
verwalten bzw. die Verwaltung anderen NS uberlassen.[20]
Somit ist es prinzipiell moglich, die MSISDN als Subdomain zu registrieren. D.h. MS2
sendet via GPRS seine MSISDN mittels z.B. HTTP POST an einen Webserver. Ein
Skript tragt anschließend die erhaltene IP-Adresse von MS2 mitsamt der MSISDN als
A-Record bei dem zustandigen NS-Server ein. Wenn MS1 und Server die IP-Adresse
von MSISDN.domain.tld abfragen, erhalten sie die der MS2.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 40
4.3.2.2 Proprietarer Verzeichnisdienst
Das im vorhergehenden Abschnitt beschriebene dynamische DNS erfordert eine spezi-
fische Netzwerk-Infrastruktur mit eigener Domain sowie Nameserver und ist daher fur
eine prototypische Implementierung noch nicht sinnvoll.
Die hier vorzustellende, proprietare Losung sieht ebenfalls den Einsatz eines eigenes
Servers fur die Zuordnung vor. MS2 sendet uber TCP seine MSISDN an diesen Server,
der diese zusammen mit der IP-Adresse in seiner Datenbank ablegt. Eine Abfrage nach
der IP-Adresse seitens der MS1 bzw. dem an der indirekten Kommunikation beteiligten
Server erfolgt ebenfalls uber die MSISDN. Zur Unterscheidung der Nachrichten wird
das MSB (Most Significant Bit) des ersten Zeichens genutzt. Ist es nicht gesetzt, dann
tragt der Server die MSISDN in seine Datenbank ein. Ist es gesetzt, so sendet er die
IP-Adresse.
Der gewahlte TCP-Port ist die 7001, um sowohl den Server fur die Zuordnung als
auch den Server fur die Multimedia-Daten physisch auf einem Rechner auszufuhren.
Die MSISDN wird in der E.164-Norm der ITU-T erwartet, d.h. mit vorangestelltem
Plus-Zeichen sowie Landercode.[18] Diese Notation legt eine maximale Lange fur die
Rufnummer von 15 Zeichen fest, entsprechend ergibt sich fur diese Nachricht eine Lange
von maximal 15 Bytes. Die IP-Adresse ist 4 Oktetts lang.
4.3.3 NAT
Abschnitt 2.2.3.1 hat die Problematik der Adressumsetzung via NAT erklart. In diesem
Abschnitt werden die Netzprovider T-Mobile, Vodafone und O2 hinsichtlich der Ver-
wendung privater IP-Adressen untersucht und mogliche Losungen des NAT-Problems
vorgestellt.
4.3.3.1 Untersuchung der Netzprovider
Der Versuchsaufbau gestaltete sich wie folgt. Eine MS wurde uber die Infrarotschnitt-
stelle an einen PC gekoppelt und als GPRS-Modem benutzt. Fur die Einwahl wur-
de das Programm pppd des Betriebssystems Linux eingesetzt, das die MS uber AT-
Kommandos steuert. Mittels AT+CGDCONT=CID,"IP","APN","",0,0 wird der PDP-
Kontext definiert, wobei CID durch die Nummer des in der MS eingerichteten GPRS-
Profil zu ersetzen ist – in diesem Versuch war sie 1. APN wird durch den Namen
des gewunschten APN substituiert. Der Verbindungsaufbau zu GPRS geschieht nun
uber das ATD-Kommando mit dem Wahlstring *99***CID#.[36] MS und PC wurden
entsprechend der Tabelle 4.2 konfiguriert.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 41
Parameter T-Mobile Vodafone O2
APN internet.t-d1.de web.vodafone.de internetBenutzername beliebigPasswort beliebigNameserver 193.254.160.1 139.7.30.125 195.182.96.28
Tabelle 4.2: GPRS Zugangsdaten
Das Kommando pon startete die GPRS-Verbindung. Informationen uber die zuge-
wiesene IP-Adresse lieferte ifconfig ppp0.
Um die externe IP-Adresse zu ermitteln, wurde auf einem Server im Internet das
Programm nc (Abk. fur netcat [2]) benutzt. Die Verwendung eines Webservers scheidet
aufgrund moglicher, vom Provider vorgegebener HTTP-Proxys aus. Mit dem Aufruf
nc -lvp 1024 wurde auf dem Server ein TCP-Socket auf Port 1024 geoffnet. Der PC
mit der MS konnektierte sich uber telnet ip 1024 zu diesem Socket. Die Ergebnisse
dieser Untersuchungen sind Tabelle 4.3 zu entnehmen, detaillierten Ausgaben finden
sich im Anhang.
T-Mobile Vodafone O2
IP-Adresse der MS 80.187.80.220 10.226.213.9 10.42.228.10IP-Adresse im Internet 80.187.80.220 80.226.172.223 82.113.121.0
Tabelle 4.3: Zugewiesene IP-Adressen im GPRS-Netz
Die Ergebnisse zeigen, dass außer T-Mobile alle Anbieter NAT einsetzen. Der letzte
Test sollte nun die Moglichkeit ausschließen, dass T-Mobile Verbindungen zu der MS
durch eine Firewall unterbindet. Dazu wurde auf dem PC mittels netcat ein TCP-
Socket auf dem zu verwendeten Port 7000 geoffnet und erfolgreich von einem Rechner
im Internet darauf konnektiert.
Als Konsequenz dieser Untersuchungen ergibt sich, dass unabhangig vom Anbieter
alle Teilnehmer Daten senden durfen, aber nur Teilnehmer des Providers T-Mobile als
MS2 fungieren konnen.
4.3.3.2 NAT Traversal
NAT Traversal ist der Oberbegriff fur Losungen zur Umgehung der NAT. Mit STUN
(Simple Traversal of UDP Through NATs) wurde durch RFC 3489 [28] ein Protokoll
standardisiert, dass NATs erkennen und u.U. umgehen kann. Die Gerate in dem pri-
vaten Netzwerk hinter der NAT melden sich dazu an einem STUN-Server an. Damit
erhalt dieser die offentliche IP-Adresse sowie den UDP-Quellport. Diese Informatio-
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 42
nen sendet er an den Client zuruck, der sie mit den lokal gespeicherten vergleicht und
dadurch weiß, ob seine Pakete uber eine NAT laufen und wie sie dabei verandert wer-
den. Variieren die lokalen Informationen von den durch STUN erlernten, tragt der
Client diese in den IP-Header ein und ist somit prinzipiell uber UDP aus dem Internet
erreichbar. STUN funktioniert jedoch nicht mit jedem NAT-Router.
STUNT (Simple Traversal of UDP Through NATs and TCP too) besitzt dieselbe
Funktionalitat und die gleichen Einschrankungen wie STUN fur TCP.[13]
Eine anderen Weg geht TURN (Traversal Using Relay NAT), das alle NAT-Typen
unterstutzt. Die Clients leiten dazu ihren Datenverkehr uber einen TURN-Server weiter
(engl.: relay).[27] Beide Methoden liegen der IETF als Entwurf vor, sind aber noch nicht
verabschiedet worden.
Symbian OS unterstutzt keine dieser Losungen nativ, daher wird auf die Losung des
NAT-Problems in der prototypischen Implementierung verzichtet.
4.3.3.3 VPN – Virtual Private Network
Eine weitere Losung des NAT-Problems ist die Verwendung eines VPN (Virtual Private
Network), das besonders fur einen geschlossenen Benutzerkreis wie Firmenmitarbeiter
eingesetzt werden konnte. Das VPN spannt ein privates Netzwerk uber ein offentliches
Netzwerk auf, die Kommunikationspartner kommunizieren anschließend uber dieses
VPN als waren sie physisch uber ein LAN miteinander verbunden. Ublicherweise wer-
den die ubertragenen Daten verschlusselt, angesichts des zusatzlichen Overheads im
Datenverkehr und der begrenzten Ressourcen der MS erscheint das jedoch weniger
sinnvoll. Des Weiteren ist der Schutzbedarf multimedialer Daten als gering einzustu-
fen, firmenspezifische Daten hingegen rechtfertigen eine Verschlusselung.
Fur die Kommunikation uber ein VPN bauen die beteiligen Endgerate einen Tun-
nel auf, uber den samtlicher Datenverkehr geleitet wird. Wurde dieses Szenario unter
den gegebenen Anforderungen eingesetzt, so terminiert der Tunnel auf der einen Seite
an einem Server im Internet und auf der anderen bei der MS. Alle an dem Server
angemeldeten MS befanden sich in einem Netzwerk und konnten untereinander kom-
munizieren. Der Vorteil dieser Methode ist, dass eine zentrale Infrastruktur vorliegt, die
das Management des Netzwerkes erheblich vereinfacht. Alle beteiligten Server waren
nur innerhalb des VPN erreichbar. Nachteilig wirkt sich der schon erwahnte Protokoll-
Overhead aus, der auch ohne Verschlusselung der Nutzdaten anfallt.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 43
4.3.4 Definition der Metadaten
Zusatzlich zu den Nutzdaten werden Metadaten verschickt. Diese enthalten mindestens
die Lange der ubertragenen Daten, so dass MS2 ein Ende der Ubertragung erkennen
kann. Dazu sind 32 Bit vorgesehen, die Daten bis zu 4 GB Große adressieren kon-
nen. Das ist als Zugestandnis an die fortschreitende Entwicklung von Datenrate und
Speicherkapazitat zu verstehen – realistisch erscheinendere 3 Oktetts fur 16 MB Lange
konnten bald nicht mehr ausreichend sein.
Weitere nutzliche Metadaten konnten der MIME-Typ der Daten (Multipurpose In-
ternet Mail Extensions), die Prufsumme, ein Zertifikat zur Bestimmung der Authen-
tizitat des Kommunikationspartners sowie mediale Metainformationen wie Bildgroße,
Auflosung, Videocodec etc. darstellen.
Die prototypische Implementierung wird jedoch nur das Lange-Feld benutzen. Da
MS2 den MIME-Typ bestimmen muss, um Manipulationen auszuschließen, erscheint
es weniger sinnvoll, diese Information zu senden. Auch auf die Prufsumme zur Sicher-
stellung der Integritat der ubertragenen Daten wird vorerst verzichtet, da die Kom-
munikation ungesichert ist und ein Angreifer diesen Wert ebenso wie die Daten leicht
andern konnte. Mediale Metainformationen konnen ebenso wie der MIME-Typ von
MS2 bestimmt werden.
Es wird davon ausgegangen, dass die Daten auf dem vorhandenen Speicher der MS2
nur temporar abgelegt werden. Daher wird kein Dateiname ubertragen. Das Protokoll
ließe sich jedoch dahingehend erweitern. Ein 1 Byte großes Feld gibt die Lange des
Dateinamen an, gefolgt von dem Dateinamen selbst.
Vor den Nutzdaten werden die Metadaten als eigenes TCP-Paket verschickt, wo-
durch sie sich auf Empfangerseite leichter auswerten lassen. Obgleich die ubertragenen
Informationen nur wenige Bytes umfassen, verursachen sie hohere Kosten, was in der
Abrechnung des GPRS-Datenverkehrs nach Datenblocken von 1 kB oder 10 kB Große
begrundet liegt.
4.4 Zusammenfassung
Dieser Abschnitt fasst die bisherigen Erkenntnisse zusammen und stellt das in Kapitel 5
umzusetzende Kommunikationskonzept fur den direkten und indirekten Kommunika-
tionsweg auf.
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 44
4.4.1 Direkte Kommunikation
MS2 offnet ein TCP-Socket auf Port 7000, bindet es an die vom GPRS-Netz zuge-
wiesene IP-Adresse und wartet auf Verbindungen. Zeitnah verbindet es sich zu dem
auf TCP-Port 7001 horenden Verzeichnisdienst und sendet ihm seine MSISDN. Die
Nachricht ist, bedingt durch die E.164-Notation, maximal 15 Zeichen lang, z.B. +491-
701234567. Der Server legt diese MSISDN zusammen mit der IPv4-Adresse in seiner
Datenbank ab.
Der Nutzer von MS1 wahlt die zu sendende Datei und die MSISDN des Empfangers.
Danach verbindet sich MS1 in das GPRS-Netz und konnektiert den Verzeichnisdienst.
Die gesendete Nachricht enthalt die MSISDN von MS2, wobei das MSB des ersten Zei-
chens auf 1 gesetzt ist, z.B. �491701234567 – das erste Zeichen ist ASCII-Code 171.
Der Server antwortet mit der in der Datenbank hinterlegten 4 Oktetts umfassenden
IPv4-Adresse von MS2. MS1 verbindet sich zu MS2 und initiiert die Datenubertra-
gung, angefangen mit dem 4 Byte umfassenden Lange-Feld. MS2 legt diese Daten als
temporare Datei auf einem Speichermedium ab. Sind alle Daten transferiert, terminiert
MS1 die Verbindung. MS2 ubergibt die erhaltene Datei an die assoziierte Applikation.
Abbildung 4.2 zeigt das entwickelte Kommunikationskonzept als UML-Diagramm.
Abbildung 4.2: Kommunikationskonzept – Direkte Kommunikation
Bei der direkten Kommunikation zahlen sowohl MS1 als auch MS2 fur das anfal-
lende Datenvolumen, denn die Netzanbieter unterscheiden nicht zwischen Up- und
Downstream. Auf Serverseite fallen keine Kosten an. Der Server muss uber eine feste
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 45
IP-Adresse bzw. Domainnamen sowie eine Standleitung in das Internet verfugen, um
permanent erreichbar zu sein.
4.4.2 Indirekte Kommunikation
Die Art der Kommunikation ist MS2 gleichgultig, d.h. sie fuhrt die Schritte der direkten
Kommunikation auch bei der indirekten in der selben Reihenfolge aus.
Der Server, der die Multimedia-Daten bereithalt, hort ebenfalls auf TCP-Port 7000.
Welche Dateien der Server anbietet, ist MS1 bekannt. Dessen Nutzer selektiert den
Empfanger sowie die zu sendende Datei aus einer Liste. MS1 bucht sich in das GPRS-
Netz ein, verbindet sich zu dem TCP-Socket des Servers und ubertragt die erforderli-
chen Informationen fur die Datenubertragung zwischen Server und MS2: eine 3 Bytes
umfassende ID der Datei sowie die MSISDN von MS2 in E.164-Schreibweise. Somit
betragt die Nachrichtenlange maximal 18 Bytes. Der Server erfragt anschließend bei
dem Verzeichnisdienst die IP-Adresse von MS2 und startet den Datentransfer. Eine
Notifikation von MS1 uber den Verlauf dieser Ubertragung ist nicht vorgesehen. Das
Kommunikationskonzept ist in Abbildung 4.3 dargestellt.
Abbildung 4.3: Kommunikationskonzept – Indirekte Kommunikation
Im vorliegenden Konzept liegen Server und Verzeichnisdienst physisch auf einem
Rechner. Der Server kann mehrere Dateien parallel an unterschiedliche MS2 uber-
Diplomarbeit Frank Felgner
4 Kommunikationskonzept 46
tragen, ohne zusatzliche Kosten zu verursachen. MS1 zahlt nur den Preis fur einen
GPRS-Datenblock.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 47
5 Praktische Umsetzung des
Kommunikationskonzepts
Dieses Kapitel beschaftigt sich mit der Programmierung des in Kapitel 4 entwickelten
Kommunikationskonzepts. Nach einer kurzen Einfuhrung in die Entwicklungsumge-
bung werden die benutzten Smartphones vorgestellt. Anschließend wird eine Applika-
tion fur MS1 konzipiert und programmiert. Die verwendete Programmiersprache ist
C++. Die Applikation wird zum Abschluss getestet, um ihre Funktionsweise zu veri-
fizieren und mogliche Probleme zu nennen.
5.1 Entwicklungsumgebung
Sowohl das SDK von Nokia als auch das von UIQ integrieren sich in die weitverbrei-
teten IDEs”Microsoft Visual Studio“ sowie
”Borland Builder“. Mit dem
”CodeWarrior
Development Studio for Symbian OS“ von Metrowerks ist speziell fur die Entwicklung
von mobilen Anwendungen unter Symbian OS eine leistungsfahige Umgebung geschaf-
fen worden. Sie unterstutzt die Zielplattformen ARM4, ARMI und THUMB sowie
WINSCW fur den Emulator. Metrowerks bietet den CodeWarrior in einer Personal
Edition fur 90 Tage zum kostenlosen Testen an. Die aktuelle Version 3.1 unterstutzt
alle Symbian OS Versionen ab v7.0 sowie die darauf aufbauenden SDKs.
Die Anwendungen konnen im Emulator uber einen leistungsfahigen Debugger ana-
lysiert werden, die Professional Edition unterstutzt zusatzlich das Debuggen auf dem
mobilen Endgerat. Ein Vorteil des Editors gegenuber dem anderer IDEs ist die Syn-
taxhervorhebung, die speziell auf die Namenskonventionen in Symbian OS angepasst
wurde – hierzu sei auf Abschnitt 3.3.3 verwiesen.
Das Erstellen neuer Projekte erleichtert der integrierte Application Wizard, der fur
den gewahlten Anwendungsfall die Basisklassen generiert und die notwendigen Biblio-
theken einbindet. Zu Beginn des Prozesses werden in dem Projektverzeichnis Unter-
verzeichnisse angelegt und spezifische Basisklassen sowie -dateien erzeugt. Projektde-
finitions-, Ressource- und Lokalisierungsdateien finden sich unterhalb des \group-
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 48
Verzeichnisses, Headerdateien unter \inc und in \source liegen die Quellcodedateien.
Diese enthalten ein einfaches”Hello World“-Beispiel, dass nach dem Kompilieren sofort
im Emulator lauffahig ist.
Mittlerweile hat Nokia den CodeWarrior ubernommen und entwickelt ihn als Car-
bide.c++ weiter, einer auf der Eclipse-IDE basierenden Plattform. [5] Die Version
Carbide.c++ Express ist kostenlos erhaltlich.
5.2 Auswahl der Smartphones
Auf dem Markt sind weitaus mehr Smartphones mit Series 60 denn UIQ erhaltlich,
bedingt durch Marktfuhrer Nokia. [3, 4] Deshalb fiel die Wahl der eingesetzten Gerate
auf das Nokia 6600, das Nokia 6630 sowie das Nokia 6670. In Tabelle 5.1 stehen sich
die Modelle gegenuber. Nokia 6630 und Nokia 6670 besitzen zudem bessere Multime-
diafahigkeiten als Nokia 6600, d.h. unterstutzen mehr Video- sowie Audiocodecs und
haben eine hohere Kameraauflosung.
Nokia 6600 Nokia 6630 Nokia 6670
CPU ARM9, 104 MHz ARM9, 220 MHz ARM9, 123 MHzFlash-ROM 6 MB 10 MB 8 MBRAM 16 MB 20 MB 16 MB
GPRS-Klasse B B BMultislot-Klasse 6 10 6Down-/Uplinkslots 3/1 bzw. 2/2 4/1 bzw. 3/2 3/1 bzw. 2/2EDGE –
√–
UMTS –√
–
Symbian OS v7.0s v8.0a v7.0sSeries 60 2.0 2.6 2.1
Tabelle 5.1: Ubersicht uber die benutzten Smartphones
Applikationen, welche fur das Nokia 6600 entwickelt wurden, laufen aufgrund der
Abwartskompatibilitat prinzipiell auch auf neueren Geraten. Es gibt jedoch Elemente,
die als veraltet gelten und in einer spateren Symbian-OS-Version entfernt werden. Diese
sind in der Dokumentation des SDK als deprecated (dt.: abgelehnt) gekennzeichnet und
auf ihren Einsatz sollte daher verzichtet werden. Da Nokia 6600 und Nokia 6670 weit-
gehend die gleichen APIs besitzen, werden sie zur Anwendungsentwicklung benutzt.
Das Nokia 6630 wird dann zusatzlich als Testgerat dienen.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 49
5.3 Applikationsentwicklung
Mit Hilfe des Application Wizard in CodeWarrior wurde ein neues Projekt namens
Recce kreiert, basierend auf der Vorlage fur S60-Anwendungen und mit einer UID aus
dem reservierten Bereich fur Testzwecke.
5.3.1 Programmablauf
Als Konsequenz aus dem Kommunikationskonzept ergibt sich fur MS1 der in Abbil-
dung 5.1 dargestellte, prinzipielle Programmablauf. Daraus ist ersichtlich, dass die
beiden Kommunikationsarten konvergieren. Eine Interaktion mit dem Benutzer ist nur
bei der Wahl der Kommunikationsart, der MSISDN des Empfangers und der Datei
resp. Datei-ID vonnoten. Es ist daher empfehlenswert, das GUI von den restlichen
Funktionseinheiten zu trennen. Dies erleichtert auch die Portierung auf andere Ober-
flachen, z.B. UIQ.
Neben der Umsetzung des Kommunikationskonzepts ergeben sich durch die Pro-
grammierung fur S60 weitere Anforderungen. Die Applikation ist Bestandteil eines
GUI und muss daher moglichst latenzfrei auf Eingaben des Benutzers reagieren. In Ab-
schnitt 3.2.4 wurde der Begriff der aktiven Objekte eingefuhrt, die nicht-praemptives
Multitasking und Multithreading ermoglichen. Sie erlauben dem Benutzer jederzeit die
Moglichkeit, aktiv in den Programmablauf einzugreifen.
5.3.2 Ubersicht uber die programmierten Klassen
Im Gegensatz zu Threads werden aktive Objekte asynchron verarbeitet. Um trotzdem
die definierte Reihenfolge der Aktionen einzuhalten, wird fur jede Kommunikationsart
ein Zustandsautomat (engl.: state machine) ebenso als aktives Objekt programmiert.
Er hat die Kontrolle uber den kompletten Programmablauf. Fur die direkte Kommu-
nikation heißt die Klasse CStateDirect, fur die indirekte CStateIndirect.
Beide Kommunikationswege nutzen eine gemeinsame Klasse, die den Verbindungsauf-
und -abbau zu einem TCP-Socket sowie Lese- und Schreiboperationen darauf aus-
fuhrt. Sie ist durch CSocketEngine implementiert, die wiederum auf CSocketWrite
und CSocketRead zugreift. Damit konnte ohne Anderungen der darauf aufbauenden
Architektur das Kommunikationsmedium geandert werden.
Schließlich kommen abstrakte Interface-Klassen zum Einsatz, die als Schnittstelle
zwischen zwei Klassen fungieren.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 50
Abbildung 5.1: Programmablauf der Applikation
Abbildung 5.2 stellt das Klassendiagramm von Recce dar. Auf die Aufnahme der
einzelnen Methoden und Attribute wurde aus Grunden der Ubersichtlichkeit verzichtet.
Die einzelnen Klassen werden in den folgenden Abschnitten vorgestellt.
In der objektorientierten Programmierung wird jedes Objekt durch new instanziiert.
Dazu existiert eine dem Klassennamen gleichnamige Methode: der Konstruktor. In
Symbian OS liegt das Objekt aufgrund seiner Große auf dem Heap. Ein Pointer auf
dieses Objekt ist im Cleanup-Stack gespeichert, um im Fehlerfall das Objekt vom
Heap entfernen zu konnen. Fur die Konstruktion steht der fehlertolerante Operator
new(ELeave) zur Verfugung, der zunachst Speicher fur ein temporares Objekt allokiert
und dieses im Erfolgsfall an das gewunschte Objekt ubergibt. Wahrend dieser Zeit kann
das Objekt noch nicht auf den Cleanup-Stack gelegt werden. Steigt new(ELeave) wegen
eines Fehlers aus, hinterlasst es ein Speicherleck.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 51
Abbildung 5.2: Das UML-Klassendiagramm
Der C++-Konstruktor darf jedoch nicht aussteigen. Da bei der Konstruktion ei-
nes Objekts meist andere Objekte initialisiert werden, die potentielle Fehlerquellen
darstellen, wird in [35] eine speziell an Symbian OS angepasste Konstruktionsmetho-
dik vorgeschlagen: die two-phase construction. Das Objekt wird allokiert und dessen
Zeiger mittels CleanupStack::PushL() auf den Cleanup-Stack gelegt. Die Funktion
ConstructL() komplettiert die Konstruktion. Sie enthalt alle Funktionsaufrufe, die im
Fehlerfall aussteigen konnen. In Listing 5.1 sind die relevanten Programmzeilen einer
Zwei-Phasen-Konstruktion anhand einer Klasse CX dargestellt, als Beispiel wird ein
Objekt iY der Klasse CY instanziiert.
Listing 5.1: Zwei-Phasen-Konstruktion
CX∗ CX: : NewL( ){
CX∗ s e l f = CX: : NewLC( ) ;
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 52
CleanupStack : : Pop( s e l f ) ;return s e l f ;
}
CX∗ CX: : NewLC( ){
CX∗ s e l f = new (ELeave ) CX;CleanupStack : : PushL( s e l f ) ;s e l f −>ConstructL ( ) ;return s e l f ;
}
void CX: : ConstructL ( ){
iY = CY: : NewL( ) ;}
CX:CX( ){}
Diese Form der Konstruktion wird in Recce bei allen eigens entwickelten Klassen
eingesetzt.
5.3.3 Aktive Objekte
Da alle Klassen aktive Objekte nutzen, sollen diese im Folgenden erklart werden. Das
aktive Objekt erbt von der Klasse CActive und registriert sich beim Active Sche-
duler durch Ubergabe einer Referenz auf sich selbst. Dies geschieht im Konstruktor
der Klasse mit dem Aufruf CActiveScheduler::Add(this), bei einer Zwei-Phasen-
Konstruktion in ConstructL(). Zusatzlich wird die Prioritat festgelegt, mit der das
aktive Objekt ausgefuhrt werden soll. Dazu steht ein Enumerations-Datentyp zur Ver-
fugung; der Standardwert ist die Konstante EPriorityStandard.
Uber SetActive() teilt das Objekt dem Scheduler mit, dass es eine Anfrage an
einen asynchronen Dienst gestellt hat und auf dessen Antwort wartet. Das Objekt hat
eine Membervariable iStatus vom Typ TRequestStatus, die zunachst auf KRequest-
Pending gesetzt wird. Komplettiert der Dienst, so gibt er das dem Scheduler bekannt.
Dieser pruft nun den Status aller bei ihm registrierten Objekte. Hat er einen anderen
Wert als KRequestPending, so ruft der Scheduler die RunL()-Funktion des aktiven
Objekts auf, markiert es als inaktiv und wartet auf das nachste Ereignis.
Zum Abbruch von Anfragen wird die Cancel()-Funktion von CActive genutzt, die
DoCancel() aufruft. Diese Methode muss das aktive Objekt implementieren. Zusatzlich
sollte der Destruktor immer Cancel() aufrufen, um alle ausstehenden Anfragen zu
terminieren.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 53
Ein einfaches Beispiel soll die Funktionsweise und Vorteile aktiver Objekte demons-
trieren. RTimer ist eine asynchrone Server-Klasse, die im Beispiel von timer instanziiert
wird. Uber die Methode After() wird eine Anfrage gestellt, die nach einer festgelegten
Zeit beantwortet wird. Der synchrone Ansatz sahe wie in Listing 5.2 dargestellt aus.
Die Applikation wurde in der Anweisung der letzten Zeile 10 Sekunden verharren und
auf die Komplettierung von RTimer warten; der laufende Thread ware blockiert.
Listing 5.2: Synchrone Abarbeitung eines Timers
RTimer t imer ;TRequestStatus s t a tu s ;. . .//RTimer erwar t e t d i e Ze i t in Mikrosekundent imer . After ( s tatus , 10000000) ;User : : WaitForRequest ( s t a tu s ) ;
Die asynchrone Programmierung geschieht uber eine Klasse CTimer, die von CActive
erbt. Listing 5.3 zeigt die relevanten Auszuge aus dem Quellcode. Wird eine Instanz
dieser Klasse aus einem Thread mittels StartTimer() aufgerufen, so blockiert er diesen
nicht.
Listing 5.3: Asynchrone Abarbeitung eines Timers
void CTimer : : ConstructL ( ){
CActiveScheduler : : Add( this ) ;}
void CTimer : : StartTimer ( ){
iTimer . After ( iS tatus , 10000000) ;SetAct ive ( ) ;
}
void CTimer : : RunL( ){
i f ( i S t a tu s==KErrNone ){
// f uh re d e f i n i e r t e Aktion aus}
}
Abbildung 5.3 stellt das zugehorige, vereinfachte Sequenzdiagramm des asynchronen
Timers dar.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 54
Abbildung 5.3: Sequenzdiagramm der asynchronen Verarbeitung
5.3.4 Klassen des Application Framework
Die Basisklassen einer S60-Anwendung werden durch das Application Framework be-
stimmt, die mit den wichtigsten Methoden in Abbildung 5.4 dargestellt sind. Der
Einstiegspunkt ist in der Datei Recce.cpp definiert: die Funktion NewApplication()
startet die Applikation und erzeugt eine neue Instanz der Klasse CRecceApplicati-
on. Das Framework ermittelt anschließend die UID der Applikation uber die Funktion
AppDllUid(), um zu prufen, ob bereits eine Instanz der Anwendung lauft, zu der es
gegebenenfalls wechseln kann.
Nun wird CreateDocument() aufgerufen, wodurch eine Klasse CRecceDocument uber
einen Zwei-Phasen-Konstruktor instanziiert wird. CRecceDocument bietet die Methode
CreateAppUiL() zur Erzeugung des User Interfaces der Anwendung. Das Framework
ruft diese Funktion auf und bekommt einen Zeiger auf CRecceAppUi zuruckgeliefert.
CRecceAppUi erbt von der Klasse CAknAppUi und enthalt alle Steuerungselemente fur
die Benutzerschnittstelle, z.B. Menus, Pop-Up-Meldungen etc. Dazu implementiert es
die Methode HandleCommandL(), die die in der Ressourcedatei festgelegten Komman-
dos verarbeitet. Daruber hinaus verarbeitet es samtliche Ereignisse, die der Benutzer
auslost.
Zum Schluss ruft das Framework die Methode Draw() der Klasse CRecceAppView auf
und zeichnet die grafische Oberflache. CRecceAppView enthalt alle Komponenten des
sichtbaren Anwendungsbereiches, die in der Funktion ComponentControl() aufgefuhrt
werden mussen.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 55
Abbildung 5.4: Basisklassen einer S60-Anwendung
5.3.4.1 CRecceAppUi
Die Ressourcedatei Recce.rss definiert fur den linken Softkey die Funktion Options,
fur den rechten Exit. Uber Options ist ein Menu aufrufbar, aus dem der Benutzer
die Art der Kommunikation selektieren kann. Die jeweilige Konstante ERecceDirect
bzw. ERecceIndirect wird in der Methode HandleCommandL() ausgewertet.
Der Benutzer wahlt nun aus dem Telefonbuch die Nummer des Empfangers. Dazu ist
in CRecceAppUi die Funktion PhoneNumberDialog() implementiert. In Symbian OS
werden die Kontakte standardmaßig in \system\data\contacts.cdb gespeichert. Se-
ries 60 bietet uber das API CPbkContactEngine eine eigene Engine an, die den Zugriff
auf diese Datenbank ermoglicht. Daruber hinaus stehen mit RPbkViewResourceFile
die benotigten Ressourcen zur Verfugung, um den Auswahldialog fur das Telefonbuch
zu erstellen. Der Dialog wird von CPbkSingleEntryFetchDlg instanziiert und uber
ExecuteLD() ausgefuhrt. Aus allen Kontakten der Datenbank kann ein Eintrag ge-
wahlt werden. Ein Kontakt kann uber mehrere MSISDN verfugen. Relevant ist jedoch
nur die Mobilfunknummer, die in dem dafur vorgesehenen Feld eingetragen sein muss.
Diese wird an den Deskriptor buffer ubergeben, wenn der Benutzer einen Kontakt
gewahlt hat. Der Deskriptor vom Typ TBuf hat eine Lange von 15 Zeichen. Liegt die
Rufnummer nicht in E.164-Notation vor, wird die fuhrende 0 durch +49 ersetzt. Zum
Schluss ubergibt PhoneNumberDialog() die MSISDN als Deskriptor an das Hauptpro-
gramm. Ist dessen Lange null, so besitzt der gewahlte Kontakt keine Mobilfunknummer
bzw. sie steht nicht im korrekten Feld. Dem Nutzer wird das uber eine Fehlermeldung
mitgeteilt.
Nach der Wahl der MSISDN wahlt der Nutzer bei der direkten Kommunikation die
zu sendende Datei. Das Dialogfenster wird uber die Ressource MEMORYSELECTIONDIALOG
definiert, die Verzeichnisse sind c:\nokia\ und e:\, so dass Dateien sowohl aus dem
Telefonspeicher als auch von der Speicherkarte gewahlt werden konnen. Ist keine Spei-
cherkarte vorhanden, wird nur der Inhalt des Telefonspeichers angezeigt. Aufgerufen
wird der Dialog uber die Methode RunSelectDlgLD() des API AknCommonDialogs.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 56
Der vollstandige Dateiname wird der Variable filename des Typs TFileName zugewie-
sen. Dieser bildet zusammen mit der MSISDN die Parameter der StartL()-Funktion
des Zustandsautomat CStateDirect, siehe Abschnitt 5.3.5.1
Fur die indirekte Kommunikation wird anstatt der Datei eine Datei-ID gewahlt.
In der Applikation ist diese als numerisches Eingabefeld implementiert. CAknNumber-
QueryDialog definiert die Methode ExecuteLD(), die den Dialog darstellt und die
Eingabe dem Integer fileID zuweist. Wie bei der direkten Kommunikation, wird die-
ser Wert zusammen mit der MSISDN dem Zustandsautomat CStateIndirect uber
die StartL()-Funktion ubergeben, siehe Abschnitt 5.3.5.2.
5.3.4.2 CRecceAppView
Als einzige Oberflachenkomponente besitzt Recce einen Statustext uber die Verbin-
dung. Dieser wird von CEikLabel instanziiert. Um die Anderung des Inhalts zu er-
leichtern, wurden die Strings in die Ressourcedatei ausgelagert. Die Einbindung zur
Laufzeit erfolgt uber die in Listing 5.4 angegebene Methodik.
Listing 5.4: Einbindung eines Ressourcen-Strings
HBufC∗ s tatusText ;s tatusText = iEikonEnv−>AllocReadResourceL (
R STATUS NOT CONNECTED) ;. . .delete s tatusText ;s tatusText=NULL;
Die Anderung des Texts obliegt der Methode PrintStatus(). Sie wird durch die
Interface-Klasse MViewNotifier anderen Klassen zur Verfugung gestellt. Ebenso wie
die Funktion PrintError(), die mittels des API CAknInformationNote einen Nach-
richtendialog realisiert, der den Benutzer uber aufgetretene Fehler informiert. Der in
Abschnitt 5.3.4.1 beschriebene Fehlerfall bei unbekannter MSISDN ist in Abbildung 5.5
dargestellt. Beide Funktionen erwarten als Parameter die Ressourcendefinition.
5.3.5 Klasse fur den Zustandsautomat
Der Zustandsautomat fuhrt trotz seiner asynchronen Abarbeitung eine festgelegte Fol-
ge von Aktionen durch. Dazu verfugt er uber einen Enumerations-Typ, der die mogli-
chen Zustande des Systems beinhaltet. Die Klassen CStateDirect sowie CStateIndi-
rect implementieren dafur den Typ TState, mit der sie die Membervariable iState
instanziieren. Bei Start des Zustandsautomat uber StartL() ist dieser Wert EIdle.
Nach der Initialisierung wird eine Anfrage an einen asynchronen Dienst gestellt, der
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 57
Abbildung 5.5: Fehlerdialog der Applikation (Screenshot des Emulators)
Zustand geandert und das Objekt mittels SetActive() aktiv gesetzt. Komplettiert der
asynchrone Dienst die Anfrage, fuhrt das Objekt die nachsten Anfrage durch, andert
erneut seinen Zustand und markiert sich wiederum als aktiv. Die Methode RunL()
implementiert dazu einen Vergleich der Membervariable iState.
Mit geringem Aufwand kann der Zustandsautomat um neue Zustande erweitert wer-
den, da notige Anderungen nur in TState abgelegt und in RunL() implementiert werden
mussen.
5.3.5.1 CStateDirect
Zu Beginn befindet sich der Zustandsautomat im Leerlauf. Die an StartL() uberge-
benen Parameter sind der Dateiname und die MSISDN des Empfangers. Da noch kein
fest installierter Verzeichnisdienst-Server zur Verfugung stand, wurde ein Dialog im-
plementiert, der dem Benutzer die Eingabe der IP-Adresse sowie des Port ermoglicht.
Anschließend wird die Datei im Lesemodus geoffnet. Hierzu sei auf das in Ab-
schnitt 3.2.2.1 vorgestellte Client-Server-Framework von Symbian OS verwiesen. Fur
alle Zugriffe auf die Ressourcen des Dateisystems steht der File-Server RFs bereit. Der
Client wird uber RFile implementiert. War das Offnen der Datei erfolgreich, werden
im nachsten Schritt IP-Adresse und Port an die Instanz der Kommunikationsklasse
CSocketEngine ubergeben, die in Abschnitt 5.3.6 beschrieben wird. Deren Methode
ConnectL() initiiert die Verbindung und komplettiert bei Erfolg den Status des Zu-
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 58
standsautomat, der dadurch den Zustand ELookingUp annimmt. Abbildung 5.6 stellt
den Zustandsautomat mit allen moglichen Konditionen dar.
Abbildung 5.6: Zustandsautomat der direkten Kommunikation
Es folgt das Senden der MSISDN uber die asynchrone Methode WriteL() der Kom-
munikationsklasse. Zuvor wird uber die logische ODER-Verknupfung das MSB des
ersten Zeichens gesetzt. Der Zustand ELookedUp, in welcher sich der Automat jetzt
befindet, ist ohne Funktion. Es wird der Empfang der IP-Adresse erwartet, allerdings
ist die Leseoperation in der Klasse CSocketEngine nicht asynchron implementiert – die
Grunde dafur erklart Abschnitt 5.3.6.3. Stattdessen ruft sie uber die Interface-Klasse
MStateNotifier die Methode CStateDirect::DataReceived() auf. Der ubergebene
Deskriptor von 4 Bytes Lange wird uber das Makro INET_ADDR zu einer IP-Adresse
gebildet, die Verbindung zum Verzeichnisdienst wird beendet und anschließend die
erhaltene IP-Adresse auf Port 7000 konnektiert.
Nun wird die Dateigroße uber einfache Bitoperationen in der in Listing 5.5 angege-
benen Methodik in 4 Oktetts zerlegt. Die Dateigroße vom Typ Integer wird uber die
UND-Operation mit allen gesetzten Bits eines Bytes verknupft und der erhaltene Wert
wird dem Deskriptor iBuffer zugewiesen. Anschließend wird das Integer 8 Bits nach
rechts geschoben und erneut uber die UND-Logik verknupft usw. Diese Vorgehensweise
ist notwendig, um exakt eine Lange von 4 Bytes zu erhalten, auch wenn die Dateigroße
diese nicht benotigt.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 59
Listing 5.5: Zerlegung der Dateigroße
TInt f i l e S i z e ;i F i l e . S i z e ( f i l e S i z e ) ;
iBu f f e r . Append ( ( TUint8 ) ( f i l e S i z e & 0xFF) ) ;iBu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 8) & 0xFF) ) ;iBu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 16) & 0xFF) ) ;iBu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 24) & 0xFF) ) ;
Der Automat befindet sich jetzt im Zustand ESend. Da der Inhalt einer Datei auf-
grund seiner Große nicht auf den Heap gespeichert werden kann, wird er portioniert
ubertragen. Der Deskriptor iBuffer stellt den Sendepuffer bereit. Er wird auf dem
Stack erzeugt und kann maximal 512 Zeichen aufnehmen. Da nur 8 Bit breite Bi-
nardaten und keine Unicode-Zeichen aufgenommen werden, wird er als Typ TBuf8
deklariert. Uber die fur asynchrone Klassen uberladene Methode RFile::Read() wird
dieser Puffer mit dem Inhalt der Datei vollstandig aufgefullt. Bei Komplettierung der
Anfrage erreicht der Zustandsautomat EReadFile, der den Puffer mittels CSocketEn-
gine::WriteL() ubertragt. War diese Operation erfolgreich, kehrt der Zustandsauto-
mat wieder in den Zustand ESend zuruck. Durch diese Schleife wird immer ein 512 Byte
großer Block der Datei gelesen und anschließend ubertragen. Das Ende der Datei ist
erreicht, wenn die Lange des Puffers nicht mehr gegeben ist. Die Verbindung wird
daraufhin terminiert.
Ist ein Zustand unbekannt oder war eine Anfrage nicht erfolgreich, d.h. iStatus
ungleich KErrNone, wird der Thread mit einer Panik abgebrochen.
Der Zustandsautomat instanziiert die Interface-Klasse MViewNotifier um die Sta-
tusanzeige mit Hilfe der Methode CRecceAppView::PrintStatus() verandern zu kon-
nen.
5.3.5.2 CStateIndirect
Der Zustandsautomat der indirekten Kommunikation ist genau wie der der direk-
ten Kommunikation aufgebaut, besitzt jedoch andere Zustande. Diese sind in Abbil-
dung 5.7 dargestellt. Nach dem Start offnet CStateIndirect zunachst einen Dialog
zur Eingabe von IP-Adresse sowie Port des Multimedia-Servers und schickt ihm an-
schließend die ubergebenen Parameter Datei-ID sowie MSISDN. Trotz der simplen
Operation wurde auch fur die indirekte Kommunikation ein Zustandsautomat entwor-
fen, um das gesamte Konzept einfacher erweitern zu konnen. Zum Beispiel konnte der
Server MS1 eine Kopie seiner Datenbank schicken, aus welcher MS1 die zu sendende
Datei wahlen kann.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 60
Abbildung 5.7: Zustandsautomat der indirekten Kommunikation
Die Methode CStateIndirect::DataReceived() ist zwar deklariert, aber nicht im-
plementiert, da das Kommunikationskonzept des indirekten Weges keinen Datenemp-
fang vorsieht.
5.3.6 Kommunikationsklassen
Fur die Nutzung von Sockets steht der Socket-Server in Form der Klasse RSocketServ
bereit, der Client wird mittels RSocket implementiert.
Der Verbindungsaufbau zu einem TCP-Socket lauft wie folgt ab. Zuerst wird ge-
pruft, ob bereits eine Route zu dem Zielrechner existiert. Falls nicht, ubernimmt das
Betriebssystem den Verbindungsaufbau in das Internet, d.h. der Nutzer wahlt wie
gewohnt den APN. Somit muss dieser Vorgang nicht explizit in der Anwendung im-
plementiert werden. Ein weiterer Vorteil ist, dass der benutzte Internetzugang nur von
der Konfiguration der MS abhangt und dadurch theoretisch auch CSD und HSCSD
unterstutzt wird.
Der Kern der vorliegenden Kommunikationsklassen ist CSocketEngine, Lese- und
Schreibvorgange werden uber CSocketRead bzw. CSocketWrite gehandhabt. Alle Klas-
sen sind autark von den anderen Teilen der Applikation, so dass sie unabhangig von
diesen benutzt und erweitert werden konnen. Zusatzliche Lese- und Schreiboperationen
sowie DNS-Abfragen lassen sich dadurch einfach integrieren. Auch der Austausch der
Kommunikationsklassen ist moglich.
5.3.6.1 CSocketEngine
Ein Objekt, welches CSocketEngine instanziiert, ruft zunachst den Konstruktor auf.
Dieser erzeugt das Lese- und Schreibobjekt und stellt die Verbindung zum Socket-
Server her. Anschließend muss mit Hilfe der Methoden SetIP() und SetPort() die
IP-Adresse sowie der Port gesetzt werden. Die Verbindung zu dieser Socket-Adresse
stellt die Methode ConnectL() her, die das API RSocket::Connect() nutzt.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 61
Da CSocketEngine selbst einen asynchronen Dienst anbietet, muss es die Anfra-
gen des anrufenden Objekts komplettieren. Zunachst wird der Status iStatus dieses
Objekts, d.h. des Zustandsautomat, auf KRequestPending gesetzt. Dazu deklariert
CSocketEngine einen Member iCallerStatus als Pointer auf TRequestStatus. Lis-
ting 5.6 demonstriert dieses Verfahren am Beispiel der ConnectL()-Methode.
Listing 5.6: Initialisierung des Status des anrufenden Objekts
void CSocketEngine : : ConnectL ( TRequestStatus& aStatus ){. . .
i C a l l e r S t a t u s=&aStatus ;aStatus=KRequestPending ;
. . .}
Die Klasse CSocketEngine verfugt ebenso wie der Zustandsautomat uber eine Enu-
meration zur Definition des eigenes Zustands, instanziiert durch iSocketStatus. Mo-
mentan kann dieser Member die Zustande”nicht verbunden“,
”Verbindungsaufbau“
sowie”verbunden“ annehmen. Sobald eine asynchrone Anfrage an RSocket fehlerfrei
beendet wird, komplettiert die in Listing 5.7 dargestellte Methode ChangeStatus()
den Status des anrufenden Objekts.
Listing 5.7: Komplettierung des Status eines aktiven Objekts
void CSocketEngine : : ChangeStatus ( TSocketStatus aSocketStatus ){
i Socke tS ta tu s=aSocketStatus ;i f ( iCa l l e r S t a t u s && aSocketStatus==EConnected ){
User : : RequestComplete ( iCa l l e rS t a tu s , KErrNone ) ;}
}
Konnte der Socket erfolgreich konnektiert werden, wird uber Aufruf der Methode
CSocketRead::IssueRead() die Leseklasse aktiv gesetzt. Damit wird das sofortige
Empfangen nach dem Verbindungsaufbau ermoglicht.
Die Methode WriteL() initiiert einen Schreibvorgang, d.h. ruft CSocketWrite::Is-
sueWriteL() auf. Um sowohl von synchronen wie asynchronen Objekten genutzt zu
werden, ist diese Methode ebenso wie die ConnectL()-Funktion uberladen. Wird als
Parameter ein TRequestStatus ubergeben, so wird die asynchrone Variante genutzt.
Uber Disconnect() schließlich wird der Socket geschlossen, die asynchronen Lese-
und Schreibobjekte werden uber ihre von CActive geerbte Methode Cancel() abge-
brochen.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 62
5.3.6.2 CSocketWrite
Die Klasse CSocketWrite nutzt die asynchrone Methode RSocket::Write(), um die
ihr ubergebenen Daten uber das Socket zu transferieren. Sobald wahrend eines laufen-
den Schreibvorgangs ein neuer initiiert wird, bricht der Socket-Client die Verbindung
ab. Die asynchrone Implementierung tragt dieser Anforderung Rechnung.
Uber den Member iBuffer ist der Sendepuffer implementiert, der bei Aufruf von
IssueWriteL() gefullt wird. Er wird beim erfolgreichen Schreibvorgang uber iBuf-
fer.Zero() geloscht.
Die Methode IssueWriteL() komplettiert ebenso wie CSocketEngine den Status
des anrufenden Objekts. Da CSocketEngine::Write() diesen transparent durchreicht,
wird der Status des Zustandsautomat geandert.
5.3.6.3 CSocketRead
Die Methode IssueRead() der Klasse CSocketRead ruft die asynchrone Funktion
RSocket::RecvOneOrMore() auf und setzt sich anschließend aktiv. Sobald Daten emp-
fangen werden, ruft RunL() uber die Interface-Klasse MSocketEngineNotifier die
Funktion DataReceived() auf und ubergibt ihr die erhaltenen Daten. Die Klasse
CSocketEngine implementiert diese Funktion und reicht die Daten anschließend an
den betreffenden Zustandsautomat weiter.
Diese Losung wurde der Komplettierung vorgezogen, damit sie nicht versehentlich
ausgelost wird und zu einem unerwarteten Verhalten fuhrt. Das sei anhand eines Bei-
spiels erklart. Angenommen, der direkte Zustandsautomat sendet eine Portion der
Datei und wartet auf die Antwort von CSocketWrite. Wurden jetzt unerwartet Da-
ten uber das Socket eintreffen, wurde CSocketRead die Komplettierung durchfuhren,
obwohl der Erfolg der Schreiboperation noch nicht bestatigt wurde. Ein neuer Schreib-
vorgang wurde nun unweigerlich zum Absturz des Socket-Servers und damit der Ap-
plikation fuhren.
5.3.6.4 CTimeOutTimer
In Abschnitt 5.3.3 wurde die Klasse CTimer als Demonstration aktiver Objekte vor-
gestellt. Das Symbian-SDK implementiert diese Klasse, von der CTimeOutTimer erbt.
CSocketEngine und CSocketWrite instanziieren ein Objekt dieser Klasse. Wird z.B. ei-
ne Verbindung initiiert, wird mittels After() der Timer gestartet. Ist die Verbin-
dungsaufnahme erfolgreich, wird der Timer uber Cancel() abgebrochen. Ansonsten
ruft die Klasse nach einer Zeit von 60 Sekunden die Methode TimeOut() uber den
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 63
Notifier MTimeOutNotifier auf. In den beiden Kommunikationsklassen ist diese Funk-
tion implementiert und bricht dort die Operation ab und komplettiert den Status des
Zustandsautomat mit KErrTimedOut.
5.3.7 Zusammenarbeit der Klassen uber Methodenaufrufe
Das Zusammenarbeiten der Klassen uber deren Methodenaufrufe soll anhand der Ver-
zeichnisdienstabfrage mit Hilfe des UML-Sequenzdiagramms in Abbildung 5.8 illus-
triert werden. Aus Grunden der Ubersichtlichkeit wurde auf die Klasse CTimeOutTimer
verzichtet. Die Statusanderungen von CStateDirect sind entsprechend markiert.
5.3.8 Anderungen an der Software der Kommunikationsteilnehmer
Parallel zur Recce-Applikation wurde im Rahmen eines Projekts die Software fur Server
und MS2 entwickelt. Diese Software musste noch leicht modifiziert werden, um das
Kommunikationskonzept zu verwirklichen.
Zuerst wurde die ursprunglich fur MS1 entwickelte Erkennung des Filetyps in den
Quellcode von MS2 ubertragen und entsprechend angepasst, d.h. die mit dem Filetyp
assoziierte Applikation wird sofort gestartet. Dazu benotigt die RApaLsSession-API
nur den Dateinamen. Die Nummer des Threads, in der die betreffende Anwendung
gestartet wird, wird als Thread-ID zuruckgegeben.
Der Server wurde fur jeden Kommunikationsweg einzeln umgesetzt. Bei der direkten
Kommunikation wird der Verzeichnisdienst gestartet, bei der indirekten fungiert der
Server zunachst als Verzeichnisdienst und anschließend als Multimedia-Server. Diese
recht unflexible Implementierung wurde derart geandert, dass der Verzeichnisdienst
aus dem Quellcode der Implementierung der indirekten Kommunikation entfernt wur-
de und der Multimedia-Server nun uber die lokale Schnittstelle den Verzeichnisdienst
abfragt, der fur die direkte Kommunikation entwickelt wurde. Somit verwalten die
Server je ein TCP-Socket und erlauben den gleichzeitigen Betrieb auf einem Rechner.
Zudem erfuhr das implementierte Protokoll bei den Kommunikationsteilnehmern
eine minimale Anderung. Als Kennung fur das Senden der MSISDN zu dem Verzeich-
nisdienst wurde ein Bit festgelegt, implementiert war jedoch ein Byte. Dies resultierte
noch aus den durchgefuhrten Tests des Protokolls, in denen die Kennung uber die
Tastatur eingegeben wurde.
Die Anderungen im jeweiligen Quellcode sind dem Anhang zu entnehmen.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 64
Abbildung 5.8: UML-Sequenzdiagramm der Verzeichnisdienstabfrage
5.4 Test
Am Schluss des Entwicklungsprozesses fand ein Funktionstest statt. Zunachst wurde
ein Simulator aufgebaut, um den gesendeten Datenverkehr zu analysieren und Over-
head sowie Latenz bestimmen zu konnnen. Alle Tests fanden bei sehr guter Qualitat
der Funkverbindung statt. Anschließend wurde die programmierte Applikation Rec-
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 65
ce zusammen mit den Servern sowie der Software der MS2 in einem Demonstrator
eingesetzt. Dieser sollte das Kommunikationskonzept verifizieren.
5.4.1 Aufbau eines Simulators
Das Programm Ethereal [1] kann den Datenverkehr auf einem Ethernet-Interface
analysieren, unterstutzt jedoch keine als Modem via PPP angesprochene MS. Daher
wurde die MS2 durch einen aus dem Internet uber Ethernet erreichbaren Rechner
ersetzt und ihre Funktion von dem Programm nc ubernommen, das mit den Optionen
-lp 7000 einen TCP-Socket auf Port 7000 offnet.
Zunachst erhielt der Verzeichnisdienst die IP-Adresse dieses Rechners, indem dieser
eine frei gewahlte MSISDN aus der Kontaktdatenbank von MS1 sendete. Nun initiierte
MS1 den Datentransfer einer 5.270 Byte großen Datei. Nach Abschluss dieser Uber-
tragung zeigte der GPRS-Zahler der MS1 704 Byte fur den Downstream und 5,89 kB
fur den Upstream. Damit ergibt sich insgesamt ein Overhead von ca. 20%.
Diese hohe Wert liegt im TCP-Protokoll begrundet. Allein beim Verbindungsauf-
und -abbau werden durch den Drei-Wege-Handshake je 3 Nachrichten ubertragen, die
je mindestens 40 Byte fur den IP- sowie TCP-Header benotigen. Zudem wird jedes
empfangene Paket bestatigt, was den Datenverkehr in Downlink-Richtung erklart. Be-
sonders der Overhead fur Pakete kurzer Nutzdatenlange ist beachtlich.
Die Latenz wurde mit Hilfe des ping-Programms bestimmt, das ICMP-Pakete (In-
ternet Control Message Protocol) an einen Host sendet und diese als Bestatigung emp-
fangt. Somit lasst sich die Round Trip Time (RTT) ermitteln, d.h. die Laufzeit des
Paketes zu dem Host und zuruck. Da die MS im Test nicht auf ICMP-Pakete antworte-
te, womoglich wegen eines Paketfilters, wurde sie als GPRS-Modem an einem Rechner
benutzt. Es wurden exemplarisch 10 ICMP-Pakete mit einer Große von 64 Bytes uber
den Provider O2 zur Bestimmung der RTT gesendet. Die in Tabelle 5.2 aufgefuhrten
Ergebnisse fur minimale, durchschnittliche sowie maximale RTT sollen nur als Indiz der
Latenz gelten, sie stellen keine fundierte Messung dar. Erkennbar ist, dass die Latenz
im oberen dreistelligen Millisekundenbereich liegt – siehe dazu auch [34]. Diese hohe
RTT hat jedoch keinen Einfluss auf die Datenubertragung, da TCP sich entsprechend
an die RTT anpasst.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 66
Host RTT min [ms] RTT avg [ms] RTT max [ms]
tu-ilmenau.de 686.704 731.329 991.375o2online.de 687.721 702.365 752.690google.de 754.714 903.904 1213.325
Tabelle 5.2: Ergebnisse der Latenzmessung
5.4.2 Aufbau eines Demonstrators
Im Folgenden wird der Aufbau eines Demonstrators beschrieben, der gemaß des Kom-
munikationskonzepts funktioniert. Mit dessen Hilfe werden anschließend einige Szena-
rien durchgefuhrt.
Die benotigten Programme sind der beigelegten CD-ROM aus dem Unterverzeichnis
\demonstrator zu entnehmen, die Dateinamen der betreffenden Applikationen gibt
Tabelle 5.3 wieder.
Funktion Dateiname
MS1 recce.sis
MS2 empfanger.sis
Multimedia-Server multimedia-server.exe
Verzeichnisdienst verzeichnisdienst.exe
Datenbankverwaltung datenbankverwaltung.exe
Tabelle 5.3: Dateinamen des Demonstrators
Die .sis-Dateien werden auf das Smartphone ubetragen und dort installiert. Zu
beachten ist, dass diese Anwendungen noch uber eine Test-UID verfugen, die bei ei-
nem kommerziellen Einsatz geandert werden sollte. Sende- und Empfangsapplikation
konnen auf allen in Abschnitt 5.2 vorgestellten Smartphones genutzt werden, ebenso
wie der Empfanger. Daruber hinaus sollten sie auch mit zukunftigen Symbian-OS-
Versionen zusammenarbeiten. Die Server benotigen einen Rechner mit Microsoft Win-
dows als Betriebssystem, getestet wurde Windows XP. Der Rechner muss uber einen
Internetzugang verfugen und Zugriff auf TCP-Port 7000 sowie 7001 gestatten. Da es
sich hierbei nicht um privilegierte Ports handelt, kann auch ein Nutzer ohne Adminis-
tratorrechte die Server ausfuhren. Anschließend konnen alle Kommunikationspartner
miteinander kommunizieren. Die Datenbankverwaltung des Multimedia-Servers erwar-
tet die Dateien in ihrem Verzeichnis, die Liste wird dabei durch Datenbank.txt vor-
gehalten. Es sind Neuaufnahme von Dateien sowie Anderungen bestehender Eintrage
implementiert, ein Loschen ist hingegen noch nicht moglich.
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 67
Alle vorgestellten Smartphones konnten bei der direkten Kommunikation miteinan-
der kommunizieren, dabei bestatigte sich jedoch das Ergebnis der in Abschnitt 4.3.3.1
durchgefuhrten Untersuchung bezuglich der Adressumsetzung mittels NAT. Zum Emp-
fang von Daten wird momentan T-Mobile zwingend vorausgesetzt.
Sobald MS2 eine Datei empfangen hat, stellte es sie dar. Des Weiteren konnten par-
allel zur GPRS-Verbindung GSM-Dienste genutzt werden, da alle Gerate in die GPRS-
Klasse B fallen. Hierbei wurde speziell die Klasse CTimeOutTimer der MS1 betrachtet.
Der enthaltene Timeout-Wert wurde zu Testzwecken auf 5 Sekunden heruntergesetzt.
Wahrend einer laufenden Ubertragung initiierte MS2 einen Gesprachsaufbau. Dabei
wurde die GPRS-Verbindung zuruck gestellt und der Anruf durchgefuhrt. Nach Been-
digung komplettierte der Transfer. Es ist allerdings nicht auszuschließen, dass dieses
Verhalten auf das geringe Datenvolumen zuruckzufuhren ist.
Ein weiteres Problem in Zusammenhang mit dieser Klasse tritt bei dem Verbin-
dungsaufbau der MS1 auf. Nach Offnen des Sockets wird der Timer gestartet und der
Nutzer kann aus einem Auswahldialog den APN wahlen. Hat er nach Ablauf des Timers
immer noch keine Wahl getroffen, wird der Vorgang mit einem Timeout abgebrochen,
obwohl kein Verbindungsaufbau stattgefunden hat.
Um einen Verbindungsabbruch zu simulieren, wurde MS2 wahrend der Ubertragung
ausgeschaltet. MS1 beendete daraufhin den Transfer. Da sich MS2 bei dem Ausschal-
ten aus dem GPRS-Netz abmeldet, wurde dieses Verhalten erwartet. Bei schlechter
Signalqualitat bzw. Funklochern sollte die Timeout-Klasse die Verbindung jedoch erst
nach Ablauf der Zeit beenden.
Ein weiteres Problem betrifft den Verzeichnisdienst. Sturzt er ab, ist die Liste mit der
Umsetzung von MSISDN in IP-Adresse verloren, da sie nur im Speicher vorgehalten
wird.
5.5 Kritische Auseinandersetzung
In diesem Kapitel wurde die Implementierung des Kommunikationskonzepts fur die
MS1 vorgestellt. Im Folgenden sollen die Vor- und Nachteile der Implementierung kurz
genannt werden.
Ein großer Vorteil ist der modulare Aufbau der Applikation. So konnen Kommunika-
tionsklasse oder GUI mit geringen Anderungen ausgetauscht werden. Auch eine Inte-
gration neuer Funktionen ist durch den Zustandsautomat leicht zu realisieren. Die Ver-
wendung asynchroner Klassen ermoglicht der Applikation die Abarbeitung im Hinter-
grund, um auf Eingaben des Benutzers zu reagieren. Zukunftige Klassen sollten daher
Diplomarbeit Frank Felgner
5 Praktische Umsetzung des Kommunikationskonzepts 68
ebenso asynchron implementiert werden. Zudem stellt die Zwei-Phasen-Konstruktion
einen ordnungsgemaßen Ausstieg aus der Konstruktion eines Objekts im Fehlerfall
sicher.
Als Nachteil ist die Speichernutzung des 512 Byte großen Sendepuffers zu nennen.
Der Deskriptor sollte den Speicher auf dem Heap und nicht auf dem Stack allokieren,
um zukunftigen Erweiterungen der Applikation um neue Objekte nicht entgegenzuste-
hen. Auch die Fehlerbehandlung ist nur rudimentar implementiert. Im Fehlerfall bricht
die Applikation mit einer entsprechenden Meldung ab, ohne nach einer anderen Losung
zu suchen.
Des Weiteren spielte die Sicherheit bisher nur eine untergeordnete Rolle. Fur MS1
ist diese Betrachtung zu vernachlassigen, allerdings ist MS2 auch ohne Datenubertra-
gung permanent uber TCP-Port 7000 erreichbar. Da es alle Dateien an die zustandige
Applikation ubergibt, konnte somit auch schadliche Software installiert werden. Der
Installation muss der Benutzer zwar erst zustimmen, nichtsdestotrotz ist es die großte
Schwachstelle des Systems.
Diplomarbeit Frank Felgner
6 Zusammenfassung und Ausblick 69
6 Zusammenfassung und Ausblick
Die Arbeit hat gezeigt, dass die in Mobilfunknetzen zur Verfugung stehende Technolo-
gie zur Ubertragung von multimedialen Inhalten ausreicht, aber die bisher eingesetzten
Technologien unzureichend sind, um Daten per Push-Dienst zu ubertragen. Daher wur-
de eine eigenes Konzept aufgestellt und dieses mit einer Applikation auf Symbian OS
verifiziert. Es wurde sowohl eine direkte Kommunikation als auch eine indirekte Kom-
munikation unter Einsatz eines Servers konzipiert.
Dazu nutzt das drahtlose Medium alle Vorteile der Kommunikation des drahtge-
bundenen Internets. Dies impliziert alle Sicherungsmechanismen des Transportproto-
kolls TCP zur Aufrechterhaltung der Verbindung. Da das auf IP aufbauende TCP
zum Einsatz kommt, konnen alle auf IP abschließenden Protokollarchitekturen genutzt
werden. Auch wenn die Wahl auf GPRS fiel, ist somit prinzipiell auch die Datenuber-
tragung uber (HS)CSD moglich. Der paketorientierte Ansatz gewahrleistet ferner die
flexible Erweiterbarkeit des Systems, um auch die neuen Netztechnologien EDGE und
UMTS nutzen zu konnen.
Im Laufe der Arbeit wurde das Problem der IP-Adressumsetzung uber NAT darge-
stellt sowie mogliche Losungen prasentiert. Die in der Theorie getroffenen Aussagen
haben sich in der Praxis bestatigt, so dass momentan nur Teilnehmer des Providers
T-Mobile Daten empfangen durfen. Die nachste Version der Software sollte eine der vor-
gestellten Losungen implementieren, um unabhangig von den Netzanbietern zu sein. Es
kann schließlich nicht definitiv ausgeschlossen werden, dass T-Mobile in naher Zukunft
ebenfalls die IP-Adressen per NAT umsetzt. Eine weitere Moglichkeit stellen Koopera-
tionsvertrage dar, in denen sich die Provider verpflichten, Zugriff auf Port 7000 sowie
7001 durch die NAT zu dem Empfanger zu leiten.
Ein weiteres Problem stellte die Umsetzung der MSISDN in eine IP-Adresse dar.
Weil der Zugriff auf einen entsprechenden Server nicht gegeben ist, wurde ein eigener
proprietarer Verzeichnisdienst konzipiert, der diese Umsetzung vornimmt. Auch hier
konnten entsprechende Vertrage mit den Providern u.U. Abhilfe schaffen. Nichtsdesto-
trotz ist die eigene Losung uber den dynamischen DNS zu praferien, um ebenso wie bei
NAT unabhangig vom Provider zu sein. Eine kombinierte Losung aus VPN und DNS
Diplomarbeit Frank Felgner
6 Zusammenfassung und Ausblick 70
erscheint am attraktivsten, wobei der DNS-Server nur innerhalb des VPN erreichbar
ist. Somit hatten nur die Teilnehmer des VPN Zugriff auf das System – ein Zuge-
standnis an die Sicherheit. Es ist hierbei jedoch vorher zu prufen, wieviel zusatzlichen
Overhead ein VPN erzeugen wurde.
Der Overhead, der durch TCP auf der Funkstrecke erzeugt wird, wurde wahrend
der Arbeit mehrmals erwahnt und entsprechend kritisiert. Er ist jedoch mit dem Kom-
munikationskonzept vereinbar, da trotz dem hoheren Datenvolumen und den dadurch
steigenden Kosten die Sicherung der Kommunikation gegeben ist.
Der schlechte Kosten-Nutzen-Faktor macht das System jedoch zur Zeit unattraktiv
fur den Endverbraucher. Wenn dieser unaufgefordert Daten erhalt und ihm dafur Kos-
ten in Rechnung gestellt werden, so wird er das System nicht lange benutzen. Abhilfe
konnten Traffic-Flatrates schaffen, aber auch hier ist der Kosten-Nutzer-Faktor noch
nicht befriedigend genug. Daher konnte uber entsprechende Vertrage mit den Providern
der Empfang kostenlos ermoglicht werden, so dass nur die Sendestation fur den Traffic
zahlen muss. Fraglich ist dann allerdings, wer fur den Traffic vom Multimedia-Server
zur Empfangerstation aufkommt.
Das aufgestellte Kommunikationskonzept wurde anschließend auf Symbian OS umge-
setzt. Zuvor wurde das Betriebssystem ausfuhrlich analysiert und die Einschrankungen
und begrenzten Ressourcen anhand der Architektur erklart. Bei der Programmierung
wurden diese Punkte berucksichtigt. So verfugen die Klassen uber eine Zwei-Phasen-
Konstruktion, um Speicherlecks bei der Konstruktion von Objekten zu vermeiden.
Daruber hinaus wurden sie asynchron implementiert, um die Nutzerinteraktion zu ge-
wahrleisten. Die modulare, autarke Implementierung der Klassen ermoglicht ferner ein
Austauschen und Erweitern einzelner Komponenten. Die Klassen wurden in einem
eigenen Abschnitt kritisch analysiert.
In einem Demonstrator wurde abschließend gezeigt, dass die entwickelte Applikation
mit den anderen Kommunikationsteilnehmern kooperiert.
Das Konzept wurde zwar primar fur den Einsatz multimedialer Daten entworfen und
umgesetzt, kann aber auch fur andere Datentypen genutzt werden. Im Folgenden soll
anhand einiger Beispiele die Funktionsvielfalt des Systems demonstriert werden. So
konnte das System in Konkurrenz zu Blackberry treten und einen E-Mail Push-Dienst
realisieren. Denkbar ware auch, dass die Sekretarin ihrem Chef uber dieses System
neue Termine auf das Smartphone ladt. Uber den indirekten Weg konnte ein Server
auf einer Konferenz relevante Dokumente an deren Teilnehmer verteilen. Auch loka-
tionsbezogene Dienste zu Marketingzwecken sind moglich, wenngleich auch nicht pri-
mares Einsatzgebiet, da hier aufgrund der lokalen Beschrankung andere Technologien
Diplomarbeit Frank Felgner
6 Zusammenfassung und Ausblick 71
ihre Vorteile ausspielen konnen. Zusammenfassend und abschließend kann festgehalten
werden, dass die Einsatzmoglichkeiten des Systems nahezu unbegrenzt sind.
Diplomarbeit Frank Felgner
72
Anhang
Diplomarbeit Frank Felgner
A Messungen 73
A Messungen
A.1 NAT-Untersuchung
A.1.1 T-Mobile
Ausgabe von ifconfig ppp0:
ppp0 Link encap:Point-to-Point Protocol
inet addr:80.187.80.220 P-t-P:10.6.6.6 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:160 (160.0 b) TX bytes:97 (97.0 b)
Ausgabe von nc -lvp 1024 (PC mit MS → Server):
listening on [any] 1024 ...
connect to [217.50.245.111] from tmo-080-220.customers.d1-online.com [8
0.187.80.220] 35276
Ausgabe von nc -lvp 7000 (Server → PC mit MS):
listening on [any] 7000 ...
connect to [80.187.80.220] from erf9-d932f56f.pool.mediaWays.net [217.5
0.245.111] 41769
A.1.2 Vodafone
Ausgabe von ifconfig ppp0:
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.226.213.9 P-t-P:10.6.6.6 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:962 (962.0 b) TX bytes:515 (515.0 b)
Diplomarbeit Frank Felgner
A Messungen 74
Ausgabe von nc -lvp 1024:
listening on [any] 1024 ...
connect to [217.50.245.111] from ip-80-226-172-223.vodafone-net.de [80.
226.172.223] 35278
A.1.3 O2
Ausgabe von ifconfig ppp0:
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.42.228.10 P-t-P:10.6.6.6 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:4459 (4.3 KiB) TX bytes:4030 (3.9 KiB)
Ausgabe von nc -lvp 1024:
listening on [any] 1024 ...
82.113.121.0: inverse host lookup failed: Unknown host
connect to [217.50.245.111] from (UNKNOWN) [82.113.121.0] 35287
A.2 Bestimmung der Latenz
PING tu-ilmenau.de (141.24.4.162) 56(84) bytes of data.
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=1 ttl=48
time=991 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=2 ttl=48
time=771 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=3 ttl=48
time=692 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=4 ttl=48
time=692 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=5 ttl=48
time=700 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=6 ttl=48
time=690 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=7 ttl=48
time=692 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=8 ttl=48
time=687 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=9 ttl=48
Diplomarbeit Frank Felgner
A Messungen 75
time=706 ms
64 bytes from wcms1.rz.tu-ilmenau.de (141.24.4.162): icmp_seq=10 ttl=48
time=686 ms
--- tu-ilmenau.de ping statistics ---
11 packets transmitted, 10 received, 9% packet loss, time 15469ms
rtt min/avg/max/mdev = 686.704/731.329/991.375/89.918 ms
PING google.de (216.239.39.104) 56(84) bytes of data.
64 bytes from 216.239.39.104: icmp_seq=1 ttl=236 time=1213 ms
64 bytes from 216.239.39.104: icmp_seq=2 ttl=236 time=928 ms
64 bytes from 216.239.39.104: icmp_seq=3 ttl=236 time=809 ms
64 bytes from 216.239.39.104: icmp_seq=4 ttl=236 time=1094 ms
64 bytes from 216.239.39.104: icmp_seq=5 ttl=236 time=810 ms
64 bytes from 216.239.39.104: icmp_seq=6 ttl=236 time=825 ms
64 bytes from 216.239.39.104: icmp_seq=7 ttl=236 time=929 ms
64 bytes from 216.239.39.104: icmp_seq=8 ttl=236 time=884 ms
64 bytes from 216.239.39.104: icmp_seq=9 ttl=236 time=820 ms
64 bytes from 216.239.39.104: icmp_seq=10 ttl=236 time=870 ms
64 bytes from 216.239.39.104: icmp_seq=11 ttl=236 time=754 ms
--- google.de ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 14563ms
rtt min/avg/max/mdev = 754.714/903.904/1213.325/130.651 ms, pipe 2
PING o2online.de (82.113.101.132) 56(84) bytes of data.
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=1 ttl=116 time
=690 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=2 ttl=116 time
=691 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=3 ttl=116 time
=707 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=4 ttl=116 time
=713 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=5 ttl=116 time
=752 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=6 ttl=116 time
=693 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=7 ttl=116 time
=687 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=8 ttl=116 time
=693 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=9 ttl=116 time
Diplomarbeit Frank Felgner
A Messungen 76
=688 ms
64 bytes from www.o2online.de (82.113.101.132): icmp_seq=10 ttl=116 tim
e=703 ms
--- o2online.de ping statistics ---
11 packets transmitted, 10 received, 9% packet loss, time 14482ms
rtt min/avg/max/mdev = 687.721/702.365/752.690/18.701 ms
Diplomarbeit Frank Felgner
B Applikation 77
B Applikation
B.1 Klassendiagramme
B.1.1 Application Framework
.
Diplomarbeit Frank Felgner
B Applikation 78
B.1.2 Zustandsautomat
.
Diplomarbeit Frank Felgner
B Applikation 79
B.1.3 Kommunikationsklassen
Diplomarbeit Frank Felgner
B Applikation 80
Diplomarbeit Frank Felgner
B Applikation 81
Diplomarbeit Frank Felgner
B Applikation 82
B.2 Quellcode
Listing B.1: Recce.pan
1 /∗ ====================================================================2 ∗ Fi l e : Recce . pan3 ∗ Created : 01/23/064 ∗ Author : Frank Felgner5 ∗ Copyright ( c ) : , A l l r i g h t s reserved6 ∗ ==================================================================== ∗/7
8 #ifndef RECCE PAN9 #define RECCE PAN
10
11 #include <e32std . h>12
13 LIT ( KSocketEnginePanic , ”CSocketEngine ”) ;14 LIT ( KSocketWritePanic , ”CSocketWrite ”) ;15 LIT ( KDirectStatePanic , ”CDirectState ”) ;16 LIT ( KIndirectStatePanic , ”CInd i r e c tS ta t e ”) ;17 LIT (KTimeoutTimerPanic , ”CTimeOutTimer”) ;18
19 /∗∗ Recce app l i c a t i on panic codes ∗/20 enum TReccePanics21 {22 ERecceBasicUi = 1 ,23 ESocketUnknownStatus ,24 EStateUnknownState25 } ;26
27 inl ine void Panic ( TReccePanics aReason )28 {29 LIT ( applicationName , ”Recce ”) ;30 User : : Panic ( applicationName , aReason ) ;31 }32
33 #endif // RECCE PAN
Listing B.2: Recce.hrh
1 /∗ ====================================================================2 ∗ Fi l e : Recce . hrh3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #ifndef Recce HRH8 #define Recce HRH9
10 /∗∗ Recce enumerate command codes ∗/11 enum TRecceIds12 {13 ERecceDirect = 1 , // s t a r t va lue must not be 014 ERecceIndirect ,15
16 ESocketOptionsIP ,17 ESocketOptionsPort ,18
19 EFileID20 } ;21
22
23 #endif // Recce HRH
Diplomarbeit Frank Felgner
B Applikation 83
Listing B.3: Recce.cpp
1 /∗ ====================================================================2 ∗ Fi l e : Recce . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include ”RecceAppl icat ion . h”8
9 // Create an app l i ca t i on , and return a po in t e r to i t10 EXPORT C CApaApplication∗ NewApplication ( )11 {12 return new CRecceApplicat ion ;13 }14
15 // DLL entry point , re turn tha t eve ry th ing i s ok16 GLDEF C TInt E32Dll ( TDllReason /∗aReason∗/ )17 {18 return KErrNone ;19 }
Listing B.4: RecceApplication.cpp
1 /∗ ====================================================================2 ∗ Fi l e : RecceAppl icat ion . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include ”RecceDocument . h”8 #include ”RecceAppl icat ion . h”9
10 // UID for the app l i ca t i on , t h i s shou ld correspond to the uid de f ined inthe mmp f i l e
11 stat ic const TUid KUidRecceApp = {0x08B374BE } ;12
13 CApaDocument∗ CRecceApplicat ion : : CreateDocumentL ( )14 {15 // Create an Recce document , and return a po in t e r to i t16 CApaDocument∗ document = CRecceDocument : : NewL(∗ this ) ;17 return document ;18 }19
20 TUid CRecceAppl icat ion : : AppDllUid ( ) const21 {22 // Return the UID for the Recce app l i c a t i on23 return KUidRecceApp ;24 }
Listing B.5: RecceDocument.cpp
1 /∗ ====================================================================2 ∗ Fi l e : RecceDocument . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include ”RecceAppUi . h”8 #include ”RecceDocument . h”9
10 // Standard Symbian OS cons t ruc t i on sequence11 CRecceDocument∗ CRecceDocument : : NewL( CEikAppl icat ion& aApp)12 {13 CRecceDocument∗ s e l f = NewLC(aApp) ;
Diplomarbeit Frank Felgner
B Applikation 84
14 CleanupStack : : Pop( s e l f ) ;15 return s e l f ;16 }17
18 CRecceDocument∗ CRecceDocument : : NewLC( CEikAppl icat ion& aApp)19 {20 CRecceDocument∗ s e l f = new (ELeave ) CRecceDocument (aApp) ;21 CleanupStack : : PushL( s e l f ) ;22 s e l f −>ConstructL ( ) ;23 return s e l f ;24 }25
26 void CRecceDocument : : ConstructL ( )27 {28 // no implementation requ i red29 }30
31 CRecceDocument : : CRecceDocument ( CEikAppl icat ion& aApp) : CAknDocument(aApp)32 {33 // no implementation requ i red34 }35
36 CRecceDocument : : ˜ CRecceDocument ( )37 {38 // no implementation requ i red39 }40
41 CEikAppUi∗ CRecceDocument : : CreateAppUiL ( )42 {43 // Create the app l i c a t i on user in t e r f a c e , and return a po in t e r to i t ,44 // the framework take s ownership o f t h i s o b j e c t45 CEikAppUi∗ appUi = new (ELeave ) CRecceAppUi ;46 return appUi ;47 }
Listing B.6: RecceAppui.cpp
1 /∗ ====================================================================2 ∗ Fi l e : RecceAppUi . cpp3 ∗ Author : Frank Felgner4 ∗ Copyright ( c ) : A l l r i g h t s reserved5 ∗ ==================================================================== ∗/6
7 //AVKON−Framework8 #include <avkon . hrh>9 #include <aknnotewrappers . h>
10 #include <aknquerydia log . h>11 #include <akncommondialogs . h>12
13 #include <Recce . rsg>14
15 // p ro j e c t s p e c i f i c16 #include ”Recce . pan ”17 #include ”RecceAppUi . h”18 #include ”RecceAppView . h”19 #include ”Recce . hrh ”20 #include ”Di r e c tS ta t e . h”21 #include ” I nd i r e c t S t a t e . h”22
23 // the se are a l l neccesary to choose a contac t24 #include <CPbkContactEngine . h>25 #include <CPbkContactItem . h>26 #include <CPbkFieldInfo . h>27 #include <CPbkSingleEntryFetchDlg . h>28 #include <RPbkViewResourceFile . h>29 #include <TPbkContactItemField . h>30
Diplomarbeit Frank Felgner
B Applikation 85
31 // ConstructL i s c a l l e d by the app l i c a t i on framework32 void CRecceAppUi : : ConstructL ( )33 {34 BaseConstructL ( ) ;35
36 //CreateView37 iAppView = CRecceAppView : : NewL( Cl ientRect ( ) ) ;38 AddToStackL ( iAppView ) ;39
40 // crea t e the s t a t e machines41 i S t a t e I n d i r e c t=CState Ind i r e c t : : NewL(∗ iAppView ) ;42 i S t a t eD i r e c t=CStateDirect : : NewL(∗ iAppView ) ;43 }44
45 CRecceAppUi : : CRecceAppUi ( )46 {47 // no implementation requ i red48 }49
50 CRecceAppUi : : ˜ CRecceAppUi ( )51 {52 i f ( iAppView )53 {54 RemoveFromStack ( iAppView ) ;55 delete iAppView ;56 iAppView = NULL;57 }58 }59
60 // handle any menu commands61 void CRecceAppUi : : HandleCommandL( TInt aCommand)62 {63 switch (aCommand)64 {65 case EEikCmdExit :66 case EAknSoftkeyExit :67 Exit ( ) ;68 break ;69
70 case ERecceDirect :71 {72 // d i r e c t communictaion was chosen73
74 // ge t the msisdn o f the r e c i p i e n t75 TBuf8<15> number=PhoneNumberDialog ( ) ;76 i f ( number . Length ( ) )77 {78 //run the f i l e choose d ia log , re turn the chosen f i l ename79 TFileName f i leName ;80 i f (AknCommonDialogs : : RunSelectDlgLD ( fi leName ,
R FILE SELECTION DIALOG) )81 {82 // s t a r t the s t a t e machine83 i S t a t eD i r e c t−>StartL ( fi leName , number ) ;84 }85 }86 else87 {88 iAppView−>Pr intError (R ERROR MISSING MOBILE NUMBER) ;89 }90 }91 break ;92
93 case ERecceInd i rect :94 {95 // i n d i r e c t communictaion was chosen96
97 // ge t the msisdn o f the r e c i p i e n t
Diplomarbeit Frank Felgner
B Applikation 86
98 TBuf8<15> number=PhoneNumberDialog ( ) ;99 i f ( number . Length ( ) )
100 {101 // c a l l d i a l o g to l e t user chose the f i l e ID the se rve r
shou ld send102 TInt f i l e ID =0;103 CAknNumberQueryDialog∗ f i l e IDD i a l o g = CAknNumberQueryDialog
: : NewL( f i l e ID , CAknTextQueryDialog : : ENoTone) ;104
105 i f ( f i l e IDDia l og−>ExecuteLD (R RECCE FILEID DIALOG) )106 {107 // s t a r t the s t a t e machine108 i S t a t e I nd i r e c t −>StartL (number , f i l e ID ) ;109 }110 }111 else112 {113 iAppView−>Pr intError (R ERROR MISSING MOBILE NUMBER) ;114 }115 }116
117 break ;118
119 default :120 Panic ( ERecceBasicUi ) ;121 break ;122 }123 }124
125
126 TBuf8<15> CRecceAppUi : : PhoneNumberDialog ( )127 {128 TBuf8<15> telephoneNumber ;129
130 // connect to the phonebook131 RPbkViewResourceFile phonebookResource (∗ ( CEikonEnv : : S t a t i c ( ) ) ) ;132
133 i f ( ! phonebookResource . IsOpen ( ) )134 {135 phonebookResource . OpenL ( ) ;136 }137
138 // i n s t a n t i a t e the contac t engine139 CPbkContactEngine∗ pbkContactEngine = CPbkContactEngine : : NewL( ) ;140
141 // bu i l d a s i n g l e entry d i a l o g142 CPbkSingleEntryFetchDlg : : TParams params ;143 params . iPbkEngine = pbkContactEngine ;144
145 // the d i a l o g appears here146 CPbkSingleEntryFetchDlg∗ f e t chDlg = CPbkSingleEntryFetchDlg : : NewL(
params ) ;147 fetchDlg−>SetMopParent ( this ) ;148 i f ( fetchDlg−>ExecuteLD ( ) )149 {150 // grab chosen contac t151 CPbkContactItem∗ contact = pbkContactEngine−>OpenContactL ( params .
i S e l e c t edEnt ry ) ;152
153 // search fo r the mobi le number f i e l d154 TPbkContactItemField∗ mobileNumber = contact−>FindFie ld (
EPbkFieldIdPhoneNumberMobile ) ;155 i f (mobileNumber != NULL)156 {157 TBuf<15> bu f f e r ;158 mobileNumber−>GetTextL ( bu f f e r ) ;159
160 bu f f e r . TrimAll ( ) ;
Diplomarbeit Frank Felgner
B Applikation 87
161
162 //163 //e.164−norm164 //165 // i f the country code i s not given , we assume the r e c i p i e n t i s
l o ca t ed in germany166 // ( t h i s shou ld be improved )167 i f ( bu f f e r . Locate ( ’+’ ) !=0 && bu f f e r . Locate ( ’ 0 ’ )==0)168 {169 LIT ( countryCode , ”+49”) ;170 bu f f e r . Replace (0 , 1 , countryCode ) ;171 }172
173 telephoneNumber . Copy( bu f f e r ) ;174 }175 }176
177 delete ( pbkContactEngine ) ;178 pbkContactEngine=NULL;179
180 phonebookResource . Close ( ) ;181
182 return telephoneNumber ;183 }
Listing B.7: RecceAppview.cpp
1 /∗ ====================================================================2 ∗ Fi l e : RecceAppView . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include <e i k l a b e l . h>8 #include <coemain . h>9 #include <aknnotewrappers . h>
10 #include <Recce . rsg>11
12 #include ”RecceAppView . h”13
14 // Standard cons t ruc t i on sequence15 CRecceAppView∗ CRecceAppView : : NewL( const TRect& aRect )16 {17 CRecceAppView∗ s e l f = CRecceAppView : : NewLC( aRect ) ;18 CleanupStack : : Pop( s e l f ) ;19 return s e l f ;20 }21
22 CRecceAppView∗ CRecceAppView : : NewLC( const TRect& aRect )23 {24 CRecceAppView∗ s e l f = new (ELeave ) CRecceAppView ;25 CleanupStack : : PushL( s e l f ) ;26 s e l f −>ConstructL ( aRect ) ;27 return s e l f ;28 }29
30 CRecceAppView : : CRecceAppView ( )31 {32 // no implementation requ i red33 }34
35 CRecceAppView : : ˜ CRecceAppView ( )36 {37 delete i S ta tu sLabe l ;38 i S ta tu sLabe l=NULL;39 }40
Diplomarbeit Frank Felgner
B Applikation 88
41 void CRecceAppView : : ConstructL ( const TRect& aRect )42 {43 // Create a window for t h i s a pp l i c a t i on view44 CreateWindowL ( ) ;45
46 // read ressource in to s t r i n g47 HBufC∗ s tatusText ;48 s tatusText = iEikonEnv−>AllocReadResourceL (R STATUS NOT CONNECTED) ;49
50 // t h i s l a b e l d i s p l a y s the s t a t u s51 i S ta tu sLabe l=new(ELeave ) CEikLabel ;52 iS tatusLabe l−>SetContainerWindowL (∗ this ) ;53 iS tatusLabe l−>SetTextL (∗ s tatusText ) ;54 iS tatusLabe l−>SetExtent ( TPoint (10 , 10) , TSize (150 , 20) ) ;55
56 delete s tatusText ;57 s tatusText=NULL;58
59 Pr intStatus (R STATUS NOT CONNECTED) ;60
61 // Set the windows s i z e62 SetRect ( aRect ) ;63
64 // Act i va te the window , which makes i t ready to be drawn65 ActivateL ( ) ;66 }67
68 TInt CRecceAppView : : CountComponentControls ( ) const69 {70 return 1 ;71 }72
73 CCoeControl∗ CRecceAppView : : ComponentControl ( TInt aIndex ) const74 {75 switch ( aIndex )76 {77 case 0 :78 return i S ta tu sLabe l ;79 default :80 return NULL;81 }82 }83
84 // Draw t h i s a pp l i c a t i on ’ s view to the screen85 void CRecceAppView : : Draw( const TRect& /∗aRect∗/ ) const86 {87 // Get the standard graph ic s con tex t88 CWindowGc& gc = SystemGc ( ) ;89
90 // Gets the con t ro l ’ s e x t en t91 TRect r e c t = Rect ( ) ;92
93 // Clears the screen94 gc . Clear ( r e c t ) ;95 }96
97 void CRecceAppView : : Pr intStatus ( const TInt& aResourceID )98 {99 // read ressource in to s t r i n g
100 HBufC∗ s tatusText ;101 s tatusText = iEikonEnv−>AllocReadResourceL ( aResourceID ) ;102
103 // s e t t e x t104 iS tatusLabe l−>SetTextL (∗ s tatusText ) ;105 //update the view106 iS tatusLabe l−>DrawDeferred ( ) ;107
108 delete s tatusText ;
Diplomarbeit Frank Felgner
B Applikation 89
109 s tatusText=NULL;110 }111
112
113 void CRecceAppView : : Pr intError ( const TInt& aResourceID )114 {115 // read ressource in to s t r i n g116 HBufC∗ errorText ;117 errorText = iEikonEnv−>AllocReadResourceL ( aResourceID ) ;118
119 // d i s p l a y a note120 CAknInformationNote∗ note = new (ELeave ) CAknInformationNote ;121 note−>ExecuteLD (∗ errorText ) ;122
123 delete errorText ;124 errorText=NULL;125 }
Listing B.8: DirectState.cpp
1 /∗ ====================================================================2 ∗ Fi l e : D i rec tS ta t e . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include <aknquerydia log . h>8 #include <Recce . rsg>9 #include ”Recce . pan ”
10
11 #include ”Di r e c tS ta t e . h”12 #include ”ViewNot i f i e r . h”13
14 //15 // CStateDirect16 //17
18 CStateDirect ∗ CStateDirect : : NewL( MViewNotif ier& aAppView)19 {20 CStateDirect ∗ s e l f=CStateDirect : : NewLC(aAppView) ;21 CleanupStack : : Pop( s e l f ) ;22 return s e l f ;23 }24
25 CStateDirect ∗ CStateDirect : : NewLC( MViewNotif ier& aAppView)26 {27 CStateDirect ∗ s e l f=new (ELeave ) CStateDirect (aAppView) ;28 CleanupStack : : PushL( s e l f ) ;29 s e l f −>ConstructL ( ) ;30 return s e l f ;31 }32
33 void CStateDirect : : ConstructL ( )34 {35 CActiveScheduler : : Add( this ) ;36
37 iSocketEngine=CSocketEngine : : NewL(∗ this ) ;38 }39
40 CStateDirect : : CStateDirect ( MViewNotif ier& aAppView) :41 CActive ( EPrior i tyStandard ) ,42 iAppView (aAppView)43 {44 }45
46 CStateDirect : : ˜ CStateDirect ( )47 {
Diplomarbeit Frank Felgner
B Applikation 90
48 Cancel ( ) ;49
50 delete iSocketEngine ;51 iSocketEngine=NULL;52 }53
54 void CStateDirect : : RunL( )55 {56 i f ( i S t a tu s==KErrNone )57 {58 switch ( i S t a t e )59 {60 case ELookingUp :61 {62 // connect to ”pseudo−dns ” was s u c c e s s f u l63
64 iAppView . Pr intStatus (R STATUS IP LOOKUP) ;65
66 // s e t the msb o f the f i r s t charac ter67 iRecipientNumber [0 ]= iRecipientNumber [ 0 ] | 0x80 ;68
69 // wr i t e the telephonnumber to socke t70 iSocketEngine−>WriteL ( iRecipientNumber , i S t a tu s ) ;71
72 //change s ta t e , s e t a c t i v e73 i S t a t e=ELookedUp ;74 SetAct ive ( ) ;75 }76 break ;77 case ELookedUp :78 //no implementation done , see da tarece i ved () below79 break ;80 case EConnected :81 // conenct to ms2 was s u c c e s s f u l82
83 iAppView . Pr intStatus (R STATUS CONNECTED) ;84
85 TInt f i l e S i z e ;86 i F i l e . S i z e ( f i l e S i z e ) ;87
88 // l eng t h o f the f i l e89 // necessary in order to have e x a c t l y ( ! ) 4 by t e s90 i Bu f f e r . Append ( ( TUint8 ) ( f i l e S i z e & 0xFF) ) ;91 i Bu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 8) & 0xFF) ) ;92 i Bu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 16) & 0xFF) ) ;93 i Bu f f e r . Append ( ( TUint8 ) ( ( f i l e S i z e >> 24) & 0xFF) ) ;94
95 iSocketEngine−>WriteL ( iBu f f e r , i S t a tu s ) ;96
97 //change s ta t e , s e t a c t i v e98 i S t a t e=ESend ;99 SetAct ive ( ) ;
100
101 iAppView . Pr intStatus (R STATUS SENDING) ;102
103 break ;104 case ESend :105 // wr i t i n g to socke t was s u c c e s s f u l106
107 // i f EOF i s reached , the b u f f e r s l eng t h i s not g iven108 i f ( iBu f f e r . Length ( ) )109 {110 // read 512 by t e s from the f i l e111 i F i l e . Read ( iBu f f e r , i S t a tu s ) ;112
113 //change s ta t e , s e t a c t i v e114 i S t a t e=EReadFile ;115 SetAct ive ( ) ;
Diplomarbeit Frank Felgner
B Applikation 91
116 }117 else118 {119 //EOF reached , cance l o b j e c t and diconnect socke t120 DoCancel ( ) ;121 iSocketEngine−>Disconnect ( ) ;122 }123
124 break ;125 case EReadFile :126 // reading o f 512 by t e s from the f i l e was s u c c e s s f u l127
128 // wr i t e the data to socke t129 iSocketEngine−>WriteL ( iBu f f e r , i S t a tu s ) ;130
131 //change s ta t e , s e t a c t i v e132 i S t a t e=ESend ;133 SetAct ive ( ) ;134
135 break ;136 default :137 User : : Panic ( KDirectStatePanic , EStateUnknownState ) ;138 break ;139 }140
141 }142 else i f ( i S t a tu s==KErrTimedOut )143 {144 // wr i t e operat ion timed out −> pr in t an error145 iAppView . Pr intStatus (R STATUS NOT CONNECTED) ;146 iAppView . Pr intError (R ERROR TIMEOUT) ;147 }148 else149 {150 User : : Panic ( KDirectStatePanic , i S t a tu s . Int ( ) ) ;151 }152 }153
154 void CStateDirect : : DoCancel ( )155 {156 iAppView . Pr intStatus (R STATUS NOT CONNECTED) ;157
158 i S t a t e=EIdle ;159
160 // c l o s e f i l e h a n d l e s161 i F i l e . Close ( ) ;162 i F sS e s s i on . Close ( ) ;163 }164
165 void CStateDirect : : StartL ( const TFileName& aFileName , const TBuf8<15>&aRecipientNumber )
166 {167 i f ( I sAc t i v e ( ) )168 {169 // panic i f the o b j e c t i s a l ready a c t i v e170 User : : Panic ( KDirectStatePanic , KErrInUse ) ;171 }172
173 iFileName=aFileName ;174 iRecipientNumber=aRecipientNumber ;175
176 // i n i t i a l s t a t e177 i S t a t e=EIdle ;178
179 // here s t a r t s the d i a l o g f o r en te r ing the ip and port o f the se rve r180 // cou ld be d e l e t e d i f a s u i t a b l e s e rve r with a s t a t i c ip address was
found181 TBuf<15> ipaddr ( L ( ”141 . 2 4 . 1 72 . 1 ”) ) ;
Diplomarbeit Frank Felgner
B Applikation 92
182 TInt port =7001;183
184 CAknMultiLineDataQueryDialog∗ opt ions = CAknMultiLineDataQueryDialog : :NewL( ipaddr , port ) ;
185 i f ( opt ions−>ExecuteLD (R RECCE DIRECT OPTIONS) )186 {187 // d i a l o g su c c e s s f u l , so connect to the f i l e −s e rve r and open the
f i l e188 User : : Leave I fEr ror ( iF sSe s s i on . Connect ( ) ) ;189 User : : Leave I fEr ror ( i F i l e . Open( iFsSes s i on , iFileName , EFileRead ) ) ;190
191 // s e t ip , por t and connect192 iSocketEngine−>SetIP ( ipaddr ) ;193 iSocketEngine−>SetPort ( port ) ;194 iSocketEngine−>ConnectL ( i S t a tu s ) ;195
196 // pr in t s t a t u s197 iAppView . Pr intStatus (R STATUS CONNECTING SERVER) ;198
199 //change s t a t e and s e t a c t i v e200 i S t a t e=ELookingUp ;201 SetAct ive ( ) ;202 }203 }204
205
206 //207 // S t a t eNo t i f i e r208 //209 void CStateDirect : : DataReceived ( const TDesC8& aBuf fe r )210 {211 // i s c a l l e d by CSocketRead when data a r r i v e s212
213 // checks i f the rece i v ed data i s 4 by t e s and i f we expec t to r e c e i v edata
214 i f ( aBuf f e r . Length ( )==4 && iS t a t e==ELookedUp)215 {216 // bu i l d the ip through INET ADDR macro217 //no v a l i d i t y check implemented ye t218 TUint32 ip = INET ADDR(( TUint8 ) aBuf fe r [ 0 ] , ( TUint8 ) aBuf fe r [ 1 ] , (
TUint8 ) aBuf f e r [ 2 ] , ( TUint8 ) aBuf f e r [ 3 ] ) ;219
220 // d i sconnec t ”pseudo−dns ”221 iSocketEngine−>Disconnect ( ) ;222
223 // pr in t a s t a t u s −− again224 iAppView . Pr intStatus (R STATUS CONNECTING IP) ;225
226 // connect ms2227 iSocketEngine−>SetIP ( ip ) ;228 iSocketEngine−>SetPort (7000) ;229 iSocketEngine−>ConnectL ( i S t a tu s ) ;230
231 //chane s t a t e and s e t a c t i v e232 i S t a t e=EConnected ;233 SetAct ive ( ) ;234 }235 }
Listing B.9: IndirectState.cpp
1 /∗ ====================================================================2 ∗ Fi l e : I n d i r e c t S t a t e . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
Diplomarbeit Frank Felgner
B Applikation 93
7 #include <aknquerydia log . h>8 #include <Recce . rsg>9 #include ”Recce . pan ”
10
11 #include ” I nd i r e c t S t a t e . h”12 #include ”ViewNot i f i e r . h”13
14
15 //16 // CSta te Ind i rec t17 //18
19 CState Ind i r e c t ∗ CState Ind i r e c t : : NewL( MViewNotif ier& aAppView)20 {21 CState Ind i r e c t ∗ s e l f=CState Ind i r e c t : : NewLC(aAppView) ;22 CleanupStack : : Pop( s e l f ) ;23 return s e l f ;24 }25
26 CState Ind i r e c t ∗ CState Ind i r e c t : : NewLC( MViewNotif ier& aAppView)27 {28 CState Ind i r e c t ∗ s e l f=new (ELeave ) CSta te Ind i r e c t (aAppView) ;29 CleanupStack : : PushL( s e l f ) ;30 s e l f −>ConstructL ( ) ;31 return s e l f ;32 }33
34 void CState Ind i r e c t : : ConstructL ( )35 {36 CActiveScheduler : : Add( this ) ;37
38 iSocketEngine=CSocketEngine : : NewL(∗ this ) ;39 }40
41 CState Ind i r e c t : : CSta t e Ind i r e c t ( MViewNotif ier& aAppView) :42 CActive ( EPrior i tyStandard ) ,43 iAppView (aAppView)44 {45 }46
47 CState Ind i r e c t : : ˜ CSta t e Ind i r e c t ( )48 {49 Cancel ( ) ;50
51 delete iSocketEngine ;52 iSocketEngine=NULL;53 }54
55 void CState Ind i r e c t : : RunL( )56 {57 i f ( i S t a tu s==KErrNone )58 {59 switch ( i S t a t e )60 {61 case EConnected :62 {63 // connect ion was s u c c e s s f u l64
65 // pr in t s t a t u s66 iAppView . Pr intStatus (R STATUS CONNECTED) ;67
68 TBuf8<18> bu f f e r ;69
70 // conver t s the ID in to a s t r ing ,71 // i t ’ s j u s t f o r c ompa t i b i l i t y purposes and72 // shou ld be d e l e t e d l a t e r73 bu f f e r . NumFixedWidth( iF i l e ID , EDecimal , 3) ;74
Diplomarbeit Frank Felgner
B Applikation 94
75 //append the r e c i p i e n t ’ s number76 bu f f e r . Append( iRecipientNumber ) ;77
78 // wr i t e the data to socke t79 iSocketEngine−>WriteL ( bu f f e r , i S t a tu s ) ;80
81 //change s t a t e and s e t a c t i v e82 i S t a t e=ESend ;83 SetAct ive ( ) ;84
85 break ;86 }87 case ESend :88 // sending was s u c c e s s f u l89
90 // d i sconnec t91 iSocketEngine−>Disconnect ( ) ;92
93 // pr in t s t a t u s94 iAppView . Pr intStatus (R STATUS NOT CONNECTED) ;95
96 // s e t i d l e97 i S t a t e=EIdle ;98
99 break ;100 default :101 User : : Panic ( KIndirectStatePanic , EStateUnknownState ) ;102 break ;103 }104
105 }106 else107 {108 User : : Panic ( KIndirectStatePanic , i S t a tu s . Int ( ) ) ;109 }110 }111
112 void CState Ind i r e c t : : DoCancel ( )113 {114 i S t a t e=EIdle ;115 }116
117 void CState Ind i r e c t : : StartL ( const TBuf8<15>& aRecipientNumber , const TInt&aFi le ID )
118 {119 i f ( I sAc t i v e ( ) )120 {121 // panic i f the o b j e c t i s a l ready a c t i v e122 User : : Panic ( KIndirectStatePanic , KErrInUse ) ;123 }124
125 iRecipientNumber=aRecipientNumber ;126 i F i l e ID=aFi le ID ;127
128 // i n i t i a l s t a t e129 i S t a t e=EIdle ;130
131 // here s t a r t s the d i a l o g f o r en te r ing the ip and port o f the se rve r132 // cou ld be d e l e t e d i f a s u i t a b l e s e rve r with a s t a t i c ip address was
found133 TBuf<15> ipaddr ( L ( ”141 . 2 4 . 1 72 . 1 ”) ) ;134 TInt port =7000;135
136 CAknMultiLineDataQueryDialog∗ opt ions = CAknMultiLineDataQueryDialog : :NewL( ipaddr , port ) ;
137
138 i f ( opt ions−>ExecuteLD (R RECCE DIRECT OPTIONS) )139 {
Diplomarbeit Frank Felgner
B Applikation 95
140 // d i a l o g su c c e s s f u l , so s e t the ipaddr and port and connect141 iSocketEngine−>SetIP ( ipaddr ) ;142 iSocketEngine−>SetPort ( port ) ;143 iSocketEngine−>ConnectL ( i S t a tu s ) ;144
145 // pr in t s t a t u s146 iAppView . Pr intStatus (R STATUS CONNECTING SERVER) ;147
148 //change s t a t e and s e t a c t i v e149 i S t a t e=EConnected ;150 SetAct ive ( ) ;151 }152 }153
154
155
156 //157 // No t i f i e r158 //159 void CState Ind i r e c t : : DataReceived ( const TDesC8& aBuf fe r )160 {161 // no implementation requ i red162 }
Listing B.10: SocketEngine.cpp
1 /∗ ====================================================================2 ∗ Fi l e : SocketEngine . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include ”Recce . pan ”8
9 #include ”SocketEngine . h”10 #include ”TimeOutTimer . h”11
12 //60 seconds t imeout13 const TInt CSocketEngine : : KTimeOut=60000000;14 const TInt CSocketWrite : : KTimeOut=60000000;15
16
17 //18 // CSocketEngine19 //20
21 CSocketEngine∗ CSocketEngine : : NewL( MStateNot i f i e r& aS t a t eNo t i f i e r )22 {23 CSocketEngine∗ s e l f=CSocketEngine : : NewLC( aS t a t eNo t i f i e r ) ;24 CleanupStack : : Pop( s e l f ) ;25 return s e l f ;26 }27
28
29 CSocketEngine∗ CSocketEngine : : NewLC( MStateNot i f i e r& aS t a t eNo t i f i e r )30 {31 CSocketEngine∗ s e l f=new (ELeave ) CSocketEngine ( aS t a t eNo t i f i e r ) ;32 CleanupStack : : PushL( s e l f ) ;33 s e l f −>ConstructL ( ) ;34 return s e l f ;35 }36
37
38 void CSocketEngine : : ConstructL ( )39 {40 ChangeStatus ( ENotConnected ) ;41
Diplomarbeit Frank Felgner
B Applikation 96
42 // i n s t a n t i a t e the t imeout t imer43 iTimer = CTimeOutTimer : : NewL(∗ this ) ;44
45 CActiveScheduler : : Add( this ) ;46
47 User : : Leave I fEr ror ( iSocke tSe rv . Connect ( ) ) ;48
49 // i n s t a n t i a t e the socke t c l a s s e s50 iSocketWrite = CSocketWrite : : NewL( iSocke t ) ;51 iSocketRead = CSocketRead : : NewL(∗ this , i Socke t ) ;52
53 }54
55
56 CSocketEngine : : CSocketEngine ( MStateNot i f i e r& aS t a t eNo t i f i e r ) :57 CActive ( EPrior i tyStandard ) ,58 i S t a t e N o t i f i e r ( a S t a t eNo t i f i e r )59 {60 }61
62
63 CSocketEngine : : ˜ CSocketEngine ( )64 {65 Cancel ( ) ;66
67 delete iSocketWrite ;68 iSocketWrite = NULL;69
70 delete iSocketRead ;71 iSocketRead = NULL;72
73 delete iTimer ;74 iTimer = NULL;75
76 i Socke tSe rv . Close ( ) ;77 }78
79
80 void CSocketEngine : : RunL( )81 {82 // cance l s the timeout−t imer83 iTimer−>Cancel ( ) ;84
85 switch ( i Socke tS ta tu s )86 {87 case EConnecting :88 // connect was s u c c e s s f u l89 i f ( i S t a tu s==KErrNone )90 {91 ChangeStatus ( EConnected ) ;92 // s t a r t read operat ion immediate ly93 Read ( ) ;94 }95 else96 {97 i Socke t . Close ( ) ;98 ChangeStatus ( ENotConnected ) ;99 }
100 break ;101
102 default :103 User : : Panic ( KSocketEnginePanic , ESocketUnknownStatus ) ;104 break ;105 }106 }107
108
109 void CSocketEngine : : DoCancel ( )
Diplomarbeit Frank Felgner
B Applikation 97
110 {111 iTimer−>Cancel ( ) ;112
113 i f ( i Socke tS ta tu s==EConnecting )114 {115 i Socke t . CancelConnect ( ) ;116 i Socke t . Close ( ) ;117 }118 else119 {120 User : : Panic ( KSocketEnginePanic , ESocketUnknownStatus ) ;121 }122
123 ChangeStatus ( ENotConnected ) ;124 }125
126 //127 // Methoden128 //129
130 TUint32 CSocketEngine : : GetIP ( )131 {132 return i IP ;133 }134
135
136 void CSocketEngine : : SetIP ( TUint32 aIP )137 {138 i IP=aIP ;139 i InetAddr . SetAddress ( i IP ) ;140 }141
142 void CSocketEngine : : SetIP ( const TDesC& aIP )143 {144 i InetAddr . Input ( aIP ) ;145 i IP=iInetAddr . Address ( ) ;146 }147
148
149 TUint16 CSocketEngine : : GetPort ( )150 {151 return iPor t ;152 }153
154
155 void CSocketEngine : : SetPort ( TUint16 aPort )156 {157 iPor t=aPort ;158 i InetAddr . SetPort ( iPor t ) ;159 }160
161
162 TInetAddr CSocketEngine : : GetInetAddr ( )163 {164 return i InetAddr ;165 }166
167
168 void CSocketEngine : : ConnectL ( )169 {170 i f ( i Socke tS ta tu s==ENotConnected )171 {172 // connect the socket−s e rve r and open a socke t173 User : : Leave I fEr ror ( iSocke t . Open( iSocketServ , KAfInet , KSockStream ,
KProtocolInetTcp ) ) ;174 i Socke t . Connect ( iInetAddr , i S t a tu s ) ;175
176 ChangeStatus ( EConnecting ) ;
Diplomarbeit Frank Felgner
B Applikation 98
177
178 // s t a r t t imer179 iTimer−>After (KTimeOut) ;180 SetAct ive ( ) ;181 }182 }183
184
185 //asynchrnous over load186 void CSocketEngine : : ConnectL ( TRequestStatus& aStatus )187 {188 i f ( i Socke tS ta tu s==ENotConnected )189 {190 // s e t s the reque s t o f the c a l l i n g o b j e c t to pending191 i C a l l e r S t a t u s=&aStatus ;192 aStatus=KRequestPending ;193
194 // connect the socket−s e rve r and open a socke t195 User : : Leave I fEr ror ( iSocke t . Open( iSocketServ , KAfInet , KSockStream ,
KProtocolInetTcp ) ) ;196 i Socke t . Connect ( iInetAddr , i S t a tu s ) ;197
198 ChangeStatus ( EConnecting ) ;199
200 // s t a r t t imer201 iTimer−>After (KTimeOut) ;202 SetAct ive ( ) ;203 }204 }205
206
207 void CSocketEngine : : Disconnect ( )208 {209 i f ( IsConnected ( ) )210 {211 // cance l s a l l s ocke t opera t ions and c l o s e s the socke t212 iSocketRead−>Cancel ( ) ;213 iSocketWrite−>Cancel ( ) ;214 i Socke t . Close ( ) ;215 ChangeStatus ( ENotConnected ) ;216 }217 }218
219
220 void CSocketEngine : : Read ( )221 {222 i f ( IsConnected ( ) && ! iSocketRead−>I sAc t i v e ( ) )223 {224 iSocketRead−>Star t ( ) ;225 }226 }227
228
229 void CSocketEngine : : WriteL ( const TDesC8& aBuf fe r )230 {231 i f ( IsConnected ( ) && ! iSocketWrite−>I sAc t i v e ( ) )232 {233 iSocketWrite−>IssueWriteL ( aBuf fe r ) ;234 }235 }236
237
238 //asynchronous over load239 void CSocketEngine : : WriteL ( const TDesC8& aBuffer , TRequestStatus& aStatus )240 {241 i f ( IsConnected ( ) && ! iSocketWrite−>I sAc t i v e ( ) )242 {243 iSocketWrite−>IssueWriteL ( aBuffer , aStatus ) ;
Diplomarbeit Frank Felgner
B Applikation 99
244 }245 }246
247
248 void CSocketEngine : : ChangeStatus ( TSocketStatus aSocketStatus )249 {250 i Socke tS ta tu s=aSocketStatus ;251 i f ( iCa l l e r S t a t u s && aSocketStatus==EConnected )252 {253 // complete the reque s t o f the c a l l i n g o b j e c t254 User : : RequestComplete ( iCa l l e rS t a tu s , KErrNone ) ;255 }256 }257
258
259 TBool CSocketEngine : : IsConnected ( )260 {261 i f ( i Socke tS ta tu s==EConnected )262 {263 return true ;264 }265 else266 {267 return fa l se ;268 }269 }270
271 //272 // Socke tEng ineNot i f i e r273 //274 void CSocketEngine : : DataReceived ( const TDesC8& aBuf fe r )275 {276 // n o t i f i e s the s t a t e machine about incoming data277 i S t a t e N o t i f i e r . DataReceived ( aBuf f e r ) ;278 }279
280 //281 //TimeOutNotif ier282 //283 void CSocketEngine : : TimeOut ( )284 {285 Cancel ( ) ;286 // completes the reque s t with a timeout287 User : : RequestComplete ( iCa l l e rS t a tu s , KErrTimedOut ) ;288 }289
290
291
292 //293 //CSocketWrite294 //295
296 CSocketWrite∗ CSocketWrite : : NewL( RSocket& aSocket )297 {298 CSocketWrite∗ s e l f = CSocketWrite : : NewLC( aSocket ) ;299 CleanupStack : : Pop( s e l f ) ;300 return s e l f ;301 }302
303
304 CSocketWrite∗ CSocketWrite : : NewLC( RSocket& aSocket )305 {306 CSocketWrite∗ s e l f = new (ELeave ) CSocketWrite ( aSocket ) ;307 CleanupStack : : PushL( s e l f ) ;308 s e l f −>ConstructL ( ) ;309 return s e l f ;310 }311
Diplomarbeit Frank Felgner
B Applikation 100
312
313 CSocketWrite : : CSocketWrite ( RSocket& aSocket ) :314 CActive ( EPrior i tyStandard ) ,315 i Socke t ( aSocket )316 {317 }318
319
320 CSocketWrite : : ˜ CSocketWrite ( )321 {322 Cancel ( ) ;323
324 delete iTimer ;325 iTimer = NULL;326 }327
328
329 void CSocketWrite : : ConstructL ( )330 {331 iTimer = CTimeOutTimer : : NewL(∗ this ) ;332
333 CActiveScheduler : : Add( this ) ;334 iWr i teStatus = EWaiting ;335 }336
337
338 void CSocketWrite : : DoCancel ( )339 {340 iTimer−>Cancel ( ) ;341
342 // cance l s ou t s tand ing wr i t e operat ion343 i Socke t . CancelWrite ( ) ;344 iWr i teStatus = EWaiting ;345 }346
347
348 void CSocketWrite : : IssueWriteL ( const TDesC8& aData )349 {350 i f ( ( iWr i teStatus != EWaiting ) && ( iWri teStatus != ESending ) )351 {352 User : : Leave (KErrNotReady ) ;353 }354
355 // wr i t e data to socke t356 i Bu f f e r . Append( aData ) ;357 i Socke t . Write ( iBu f f e r , i S t a tu s ) ;358
359 SetAct ive ( ) ;360 iWr i teStatus=ESending ;361
362 // s t a r t s t imer363 iTimer−>After (KTimeOut) ;364 }365
366
367 //asynchronous over load368 void CSocketWrite : : IssueWriteL ( const TDesC8& aData , TRequestStatus& aStatus
)369 {370 i f ( ( iWr i teStatus != EWaiting ) && ( iWri teStatus != ESending ) )371 {372 User : : Leave (KErrNotReady ) ;373 }374
375 // s e t s the reque s t o f the c a l l i n g o b j e c t to pending376 i C a l l e r S t a t u s=&aStatus ;377 ∗ i C a l l e r S t a t u s=KRequestPending ;378
Diplomarbeit Frank Felgner
B Applikation 101
379 // wr i t e data to socke t380 i Bu f f e r . Append( aData ) ;381 i Socke t . Write ( iBu f f e r , i S t a tu s ) ;382
383 SetAct ive ( ) ;384 iWr i teStatus=ESending ;385
386 // s t a r t s t imer387 iTimer−>After (KTimeOut) ;388 }389
390
391 void CSocketWrite : : RunL( )392 {393 i f ( i S t a tu s == KErrNone )394 {395 switch ( iWr i teStatus )396 {397 case ESending :398 // r i t i n g was s u c c e s s f u l399
400 // zero the b u f f e r401 i Bu f f e r . Zero ( ) ;402
403 // cance l the t imer404 iTimer−>Cancel ( ) ;405
406 //wait f o r the next wr i t e operat ion407 iWr i teStatus=EWaiting ;408 break ;409 default :410 User : : Panic ( KSocketWritePanic , ESocketUnknownStatus ) ;411 break ;412 } ;413 User : : RequestComplete ( iCa l l e rS t a tu s , KErrNone ) ;414 }415 else416 {417 User : : RequestComplete ( iCa l l e rS t a tu s , i S t a tu s . Int ( ) ) ;418 iWr i teStatus=EWaiting ;419 }420 }421
422 //423 //TimeOut424 //425 void CSocketWrite : : TimeOut ( )426 {427 Cancel ( ) ;428
429 // completes the reque s t o f the c a l l i n g o b j e c t wi th a timedout430 User : : RequestComplete ( iCa l l e rS t a tu s , KErrTimedOut ) ;431 }432
433
434
435 //436 // CSocketRead437 //438
439 CSocketRead∗ CSocketRead : : NewL( MSocketEngineNoti f ier& aSocketEng ineNot i f i e r, RSocket& aSocket )
440 {441 CSocketRead∗ s e l f = CSocketRead : : NewLC( aSocketEng ineNot i f i e r , aSocket ) ;442 CleanupStack : : Pop( s e l f ) ;443 return s e l f ;444 }445
Diplomarbeit Frank Felgner
B Applikation 102
446
447 CSocketRead∗ CSocketRead : : NewLC( MSocketEngineNot i f ier&aSocketEng ineNot i f i e r , RSocket& aSocket )
448 {449 CSocketRead∗ s e l f = new (ELeave ) CSocketRead ( aSocketEng ineNot i f i e r ,
aSocket ) ;450 CleanupStack : : PushL( s e l f ) ;451 s e l f −>ConstructL ( ) ;452 return s e l f ;453 }454
455
456 CSocketRead : : CSocketRead ( MSocketEngineNot i f ier& aSocketEng ineNot i f i e r ,RSocket& aSocket )
457 : CActive ( EPrior i tyStandard ) ,458 i S o ck e tEng in eNot i f i e r ( aSocke tEng ineNot i f i e r ) ,459 i Socke t ( aSocket )460 {461 }462
463
464 CSocketRead : : ˜ CSocketRead ( )465 {466 Cancel ( ) ;467 }468
469
470 void CSocketRead : : ConstructL ( )471 {472 CActiveScheduler : : Add( this ) ;473 }474
475
476 void CSocketRead : : DoCancel ( )477 {478 i Socke t . CancelRead ( ) ;479 }480
481
482 void CSocketRead : : RunL( )483 {484 switch ( i S t a tu s . Int ( ) )485 {486 case KErrNone :487 // data was rece i v ed488
489 // no t i f y the socke t eng ine490 i S o ck e tEng in eNot i f i e r . DataReceived ( iBu f f e r ) ;491
492 //wait f o r the next by t e s493 IssueRead ( ) ;494 break ;495 default :496 break ;497 }498 }499
500
501 void CSocketRead : : IssueRead ( )502 {503 i f ( ! I sAc t i v e ( ) )504 {505 // r e c e i v e some data506 i Socke t . RecvOneOrMore ( iBu f f e r , 0 , iS tatus , iSockXfrLength ) ;507 SetAct ive ( ) ;508 }509 }510
Diplomarbeit Frank Felgner
B Applikation 103
511
512 void CSocketRead : : S ta r t ( )513 {514 i f ( ! I sAc t i v e ( ) )515 {516 IssueRead ( ) ;517 }518 }
Listing B.11: TimeOutTimer.cpp
1 /∗ ====================================================================2 ∗ Fi l e : TimeOutTimer . cpp3 ∗4 ∗ Author : Frank Felgner5 ∗ ==================================================================== ∗/6
7 #include ”TimeOutTimer . h”8 #include ”TimeOutNoti f ier . h”9
10 #include ”Recce . pan ”11
12 //13 // CTimeOutTimer14 //15
16 CTimeOutTimer∗ CTimeOutTimer : : NewL( MTimeOutNotifier& aTimeOutNoti f ier )17 {18 CTimeOutTimer∗ s e l f = CTimeOutTimer : : NewLC( aTimeOutNoti f ier ) ;19 CleanupStack : : Pop( s e l f ) ;20 return s e l f ;21 }22
23
24 CTimeOutTimer∗ CTimeOutTimer : : NewLC( MTimeOutNotifier& aTimeOutNoti f ier )25 {26 CTimeOutTimer∗ s e l f = new (ELeave ) CTimeOutTimer ( aTimeOutNoti f ier ) ;27 CleanupStack : : PushL( s e l f ) ;28 s e l f −>ConstructL ( ) ;29 return s e l f ;30 }31
32
33 CTimeOutTimer : : CTimeOutTimer ( MTimeOutNotifier& aTimeOutNoti f ier )34 : CTimer ( EPrior i tyStandard ) ,35 iT imeOutNot i f i e r ( aTimeOutNoti f ier )36 {37 }38
39
40 CTimeOutTimer : : ˜ CTimeOutTimer ( )41 {42 }43
44
45 void CTimeOutTimer : : ConstructL ( )46 {47 CTimer : : ConstructL ( ) ;48 CActiveScheduler : : Add( this ) ;49 }50
51
52 void CTimeOutTimer : : RunL( )53 {54 i f ( i S t a tu s==KErrNone )55 {56 // timeout occured −> no t i f y the c a l l i n g c l a s s
Diplomarbeit Frank Felgner
B Applikation 104
57 iT imeOutNot i f i e r . TimeOut ( ) ;58 }59 else60 {61 User : : Panic (KTimeoutTimerPanic , i S t a tu s . Int ( ) ) ;62 }63 }
B.3 Anderungen im Quellcode derKommunikationspartner
B.3.1 MS2
Diese Anderungen wurden in der Methode Rx::RunL() der Datei Rx.cpp vorgenom-men.
1 RApaLsSession s e s s i o n ;2 User : : Leave I fEr ror ( s e s s i o n . Connect ( ) ) ;3 CleanupClosePushL ( s e s s i o n ) ;4 TThreadId threadID ;5 User : : Leave I fEr ror ( s e s s i o n . StartDocument ( iNameOfTempFile , threadID ) ) ;6 CleanupStack : : PopAndDestroy ( ) ;
B.3.2 Server
Die Datei DIREKTE_2.cpp wurde in der Funktion Erkennen_Amfang() in folgenderWeise geandert. Die auskommentierten Zeilen reprasentieren den alten Stand.
1 /∗2 i f ( strncmp ( Telefon mit Anfang , ”1” , 1 )==0) {3 s t r cpy ( Telefon mit Anfang , Telefon mit Anfang+1) ;4 re turn 1 ;5 }6 i f ( strncmp ( Telefon mit Anfang , ”0” , 1 )==0 ) {7 s t r cpy ( Telefon mit Anfang , Telefon mit Anfang+1) ;8 re turn 0 ;9 }
10 ∗/11
12 i f ( ( Tele fon mit Anfang [ 0 ] & 0x80 ) == 0) {13 return 0 ;14 }15 else i f ( ( Tele fon mit Anfang [ 0 ] & 0x80 ) == 0x80 ) {16 Tele fon mit Anfang [0 ]= Tele fon mit Anfang [ 0 ] & 0 x7f ;17 return 1 ;18 }
In der Datei INDIREKTE_2.cpp wurden die Funktionen Besorgen_IPB(), Erkennen_Amfang()und einstellen_ListeIPB() entfernt. Aus dem Hauptprogramm wurden alle den Ver-zeichnisdienst betreffenden Zeilen geloscht. Die Funktion lesenDateizumSenden2()
enthielt bereits Code fur das Senden uber eine Socketverbindung, wurde jedoch nichtbenutzt. Sie wurde in Besorgen_IPB() umbenannt und wie folgt modifiziert.
1 void Besorgen IPB (char Telefon B [ 5 0 ] ) {2
3 // p r i n z i p i e l l von lesenDateizumSenden2 ubernommen
Diplomarbeit Frank Felgner
B Applikation 105
4 SOCKET Socket Y ;5
6 struct sockaddr in addr ;7 addr . s i n f am i l y = AF INET ;8 addr . s i n p o r t = htons (7001) ;9 addr . s in addr . s addr = ine t addr ( ” 1 2 7 . 0 . 0 . 1 ”) ;
10
11 int wiev i e lma l e =20;12 NOCHMALZURUCK:13 Socket Y = socket (AF INET, SOCK STREAM, 0) ;14
15 i f ( Socket Y == INVALID SOCKET) {16 p r i n t f ( ”Fehler ! Das socke t kann n i cht aufgebaut werden ,um Daten zu
ubertragen .\ r \n\ r \n”) ;17 Sleep (4000) ;18 s can f ( ”%s ” , mul le imer ) ;19 e x i t (1 ) ;20 }21
22 i f ( connect ( Socket Y , ( struct sockaddr ∗) &addr , s izeof ( structsockaddr in ) ) != 0) {
23 Sleep (100) ;24 i f ( w i ev i e lma l e != 0) {25
26 wiev i e lma l e=wiev ie lmale −1;27 p r i n t f ( ” %d \ r \n” , w i ev i e lma l e ) ;28 goto NOCHMALZURUCK;29 }30
31 p r i n t f ( ”−−−−Die Verbindung konnte n i cht aufgebaut werden−−−\r \n”) ;32 Sleep (10000) ;33 s can f ( ”%s ” , mul le imer ) ;34 e x i t (1 ) ;35 }36
37 //Aufrufe zur Bestimmung der Dateigr oße wurden en t f e rn t38
39 //neue Implementierung ab h i e r40 Telefon B [0 ]= Telefon B [ 0 ] | 0x80 ;41
42 send ( Socket Y , Telefon B , s t r l e n ( Telefon B ) , 0) ;43 char buf [ 4 ] ;44 i f ( recv ( Socket Y , buf , 4 , 0) ) {45 int ip ;46 char i p s t r i n g [ 1 5 ] ;47 s p r i n t f ( i p s t r i n g , ”%d.%d.%d.%d” , ( byte ) buf [ 0 ] , ( byte ) buf [ 1 ] , (
byte ) buf [ 2 ] , ( byte ) buf [ 3 ] ) ;48 DatenIPBzumsenden=ine t addr ( i p s t r i n g ) ;49 }50
51 c l o s e s o c k e t ( Socket Y ) ;52
53 //DER AUSGANG DIESER FUNKTION IST DatenIPBzumsenden54 }
Diplomarbeit Frank Felgner
C Inhalt der CD-ROM 106
C Inhalt der CD-ROM
|-- README
|-- demonstrator
| |-- ms1
| | ‘-- recce.sis
| |-- ms2
| | ‘-- empfanger.sis
| |-- server
| | |-- Datenbank.txt
| | |-- datenbankverwaltung.exe
| | |-- fischersfritze.txt
| | |-- foto.jpg
| | |-- multimedia-server.exe
| | |-- pitufo000.txt
| | ‘-- ringout.wav
| ‘-- verzeichnisdienst
| ‘-- verzeichnisdienst.exe
|-- diplomarbeit.pdf
|-- diplomarbeit-tex
| |-- ...
|-- messungen
| |-- ethereal
| |-- nat
| | |-- ...
| ‘-- ping
|-- projekttreffen
| |-- ...
|-- sourcecode
| |-- Empfanger
| | |-- ...
| |-- Nueva carpeta
| | |-- ...
| ‘-- recce
| |-- ...
|-- thema.pdf
‘-- zwischenverteidigung
|-- ...
Diplomarbeit Frank Felgner
Literaturverzeichnis 107
Literaturverzeichnis
[1] Ethereal: A Network Protocol Analyzer. http://www.ethereal.com/. – OnlineRessource
[2] The GNU Netcat : Official Homepage. http://netcat.sourceforge.net/. –Online Ressource
[3] S60 – Devices. http://www.s60.com/devices, Abruf: 18. Marz 2006. – OnlineRessource
[4] UIQ Technology – UIQ Phones. http://www.uiq.com/uiqphones, Abruf:18. Marz 2006. – Online Ressource
[5] Heise Zeitschriftenverlag (Hrsg.): Nokia will Entwicklung fur Symbian OSfordern. Version: 11. Oktober 2005. http://www.heise.de/mobil/newsticker/meldung/64774, Abruf: 8. Februar 2006. – Online Ressource
[6] Heise Zeitschriftenverlag (Hrsg.): Studie: Symbian gewinnt Marktantei-le. Version: 27. April 2005. http://www.heise.de/mobil/newsticker/meldung/59047, Abruf: 16. November 2005. – Online Ressource
[7] Teltarif.de Onlineverlag (Hrsg.): Bestatigt: T-Mobile rustet GPRS-Netzmit EDGE auf. Version: 6. Marz 2006. http://www.teltarif.de/arch/2006/
kw10/s20746.html, Abruf: 10. Marz 2006. – Online Ressource
[8] Symbian (Hrsg.): Symbian: Developer: Software Development Kits.Version: 2006. http://www.symbian.com/developer/sdks/index.asp. –Online Ressource
[9] Braden, R. : RFC 1122, Requirements for Internet Hosts – CommunicationLayers. http://www.ietf.org/rfc/rfc1122.txt, October 1989
[10] Digital Information Architects Inc. (Hrsg.): Programming for the Series60 platform and Symbian OS. Chichester : Wiley, 2003 (Symbian Press). – ISBN0–470–84948–7
[11] Duque-Anton, M. ; Mildenberger, O. (Hrsg.): Mobilfunknetze : Grundlagen,Dienste und Protokolle. Braunschweig : Vieweg, 2002 (Vieweg Praxiswissen). –ISBN 3–528–03934–5
[12] Gerlicher, A. ; Rupp, S. : Symbian OS – eine Einfuhrung in die Anwendungs-entwicklung. Heidelberg : dpunkt-Verl., 2004. – ISBN 3–89864–285–2
Diplomarbeit Frank Felgner
Literaturverzeichnis 108
[13] Guha, S. ; Cornell, U. : STUNT – Simple Traversal of UDPThrough NATs and TCP too. http://nutss.gforge.cis.cornell.edu/pub/
draft-guha-STUNT-00.txt, 11. Dezember 2004
[14] Guthery, S. B. ; Cronin, M. J.: Developing MMS applications : multimedia mes-saging services for wireless networks. New York : McGraw-Hill, 2003 (McGraw-HillNetworking Professional). – ISBN 0–07–141178–X
[15] Harrison, R. u. a.: Symbian OS C++ for mobile phones. Bd. 1: Professionaldevelopment on constrained devices . Reprinted October 2004 with corrections.Chichester : Wiley, 2004 (Symbian Press). – ISBN 0–470–85611–4
[16] Harrison, R. u. a.: Symbian OS C++ for mobile phones. Bd. 2: Programmingwith extended functionality and advanced features . Chichester : Wiley, 2004 (Sym-bian Press). – ISBN 0–470–87108–3
[17] Heine, G. ; Sagkob, H. : GPRS-Gateway zu Mobilfunknetzen der 3. Generation: Eine praxisorientierte Einfuhrung in moderne Netzwerk-Zugangstechnologien.Poing : Franzis, 2001. – ISBN 3–7723–4553–0
[18] Isaksen, S. : E.164 : The international public telecommunication numbering plan.http://www.itu.int/itudoc/itu-t/workshop/enum/010_pp7.ppt, Mai 1997
[19] McDowall, I. : Programming PC connectivity applications for Symbian OS :smartphone synchronization and connectivity for enterprise and application de-velopers. Chichester : Wiley, 2005 (Symbian Press). – ISBN 0–470–09053–7
[20] Mockapetris, P. V.: RFC 1034, Domain names – concepts and facilities. http://www.ietf.org/rfc/rfc1034.txt, 1. November 1987
[21] Nokia: Bluetooth FAQ. Version: 10. Januar 2005. http://www.forum.nokia.
com/main/1,6566,1_43_50_10,00.html, Abruf: 5. Januar 2006. – Online Res-source
[22] Nokia: Mobile Web Server. Version: 2006. http://research.nokia.com/
research/projects/mobile-web-server/index.html, Abruf: 1. Marz 2006. –Online Ressource
[23] Nokia: S60 Platform: FAQ – Version 1.6. Version: 8. Januar2006. http://sw.nokia.com/id/19397f28-e130-452a-8d0c-be67eb532cfe/
S60_Platform_FAQ_v1_6_en.pdf. – Online Ressource
[24] Postel, J. : RFC 768, User Datagram Protocol. http://www.ietf.org/rfc/
rfc793.txt, August 1980
[25] Postel, J. : RFC 793, Transmission Control Protocol. http://www.ietf.org/
rfc/rfc793.txt, September 1981
Diplomarbeit Frank Felgner
Literaturverzeichnis 109
[26] Rekhter, Y. ; Moskowitz, B. ; Karrenberg, D. ; Groot, G. de ; Lear, E.: RFC 1918, Address Allocation for Private Internets. http://www.ietf.org/
rfc/rfc1918.txt, Februar 1996
[27] Rosenberg, J. ; Mahy, R. ; Huitema, C. : Traversal Using Relay NAT (TURN).http://nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.txt,9. September 2005
[28] Rosenberg, J. ; Weinberger, J. ; Huitema, C. ; Mahy, R. : RFC 3489, STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network AddressTranslators (NATs). http://www.ietf.org/rfc/rfc3489.txt, Marz 2003
[29] Sauter, M. : Grundkurs mobile Kommunikationssysteme : von UMTS, GSM undGRPS zu Wireless LAN und Bluetooth Piconetzen. Wiesbaden : Vieweg, 2004. –ISBN 3–528–05886–2
[30] Schiller, J. : Mobilkommunikation. 2., uberarb. Aufl. Munchen : PearsonStudium, 2003
[31] Srisuresh, P. ; Egevang, K. : RFC 3022, Traditional IP Network AddressTranslator (Traditional NAT). http://www.ietf.org/rfc/rfc3022.txt, Januar2001. – ersetzt RFC 1631
[32] Stichbury, J. : Symbian OS explained : effective C++ programming for smart-phones. Chichester : Wiley, 2005 (Symbian Press). – ISBN 0–470–02130–6
[33] Stuckmann, P. : The GSM Evolution : mobile packet data services. Chichester: John Wiley, 2003. – ISBN 0–470–84855–3
[34] Taferner, M. ; Bonek, E. : Wireless internet access over GSM and UMTS.Berlin : Springer, 2002 (Signals and Communication Technology). – ISBN 3–540–42551–9
[35] Tasker, M. u. a.: Professional Symbian programming : mobile solutions on theEPOC platform. Birmingham : Wrox Press, 2000 (Programmer to programmer).– ISBN 1–861003–03–X
[36] Turtiainen, E. ; Arkko, J. : Linux GPRS HOWTO. Version: 12. Marz 2002.http://turtiainen.dna.fi/GPRS-HOWTO, Abruf: 30. November 2005. – OnlineRessource
[37] Wikipedia: High Speed Uplink Packet Access. Version: 21. Februar2006. http://de.wikipedia.org/w/index.php?title=High_Speed_Uplink_
Packet_Access&oldid=13912544. – Online Ressource
Diplomarbeit Frank Felgner
Abbildungsverzeichnis 110
Abbildungsverzeichnis
2.1 Systemarchitektur von GSM . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Zellulares Funksystem mit 3er-und 7er-Gruppierungen . . . . . . . . . . 72.3 TDMA-Rahmen in GSM . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Protokollarchitektur der leitungsvermittelten Internetnutzung uber GSM 112.5 Systemarchitektur von GPRS . . . . . . . . . . . . . . . . . . . . . . . 132.6 Protokollarchitektur von GPRS . . . . . . . . . . . . . . . . . . . . . . 152.7 Packet-Framing in der GRPS Protokollarchitektur . . . . . . . . . . . . 162.8 PDP-Kontextaktivierung . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Identifikation der Datenpakete eines Teilnehmers . . . . . . . . . . . . . 192.10 Systemarchitektur von UMTS . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Systemkomponenten von Symbian OS . . . . . . . . . . . . . . . . . . . 25
4.1 Das Kommunikationssystem aus Anwendersicht . . . . . . . . . . . . . 324.2 Kommunikationskonzept – Direkte Kommunikation . . . . . . . . . . . 444.3 Kommunikationskonzept – Indirekte Kommunikation . . . . . . . . . . 45
5.1 Programmablauf der Applikation . . . . . . . . . . . . . . . . . . . . . 505.2 Das UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . 515.3 Sequenzdiagramm der asynchronen Verarbeitung . . . . . . . . . . . . . 545.4 Basisklassen einer S60-Anwendung . . . . . . . . . . . . . . . . . . . . 555.5 Fehlerdialog der Applikation . . . . . . . . . . . . . . . . . . . . . . . . 575.6 Zustandsautomat der direkten Kommunikation . . . . . . . . . . . . . . 585.7 Zustandsautomat der indirekten Kommunikation . . . . . . . . . . . . . 605.8 UML-Sequenzdiagramm der Verzeichnisdienstabfrage . . . . . . . . . . 64
Diplomarbeit Frank Felgner
Tabellenverzeichnis 111
Tabellenverzeichnis
2.1 GPRS Coding Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 GPRS Multislot-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Private IP-Adressbereiche . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Varianten der Series-60-Plattform . . . . . . . . . . . . . . . . . . . . . 273.2 Namenskonventionen in Symbian OS – Klassen . . . . . . . . . . . . . 303.3 Namenskonventionen in Symbian OS – Variablen . . . . . . . . . . . . 31
4.1 Bewertung der Kommunikationsschnittstellen . . . . . . . . . . . . . . 374.2 GPRS Zugangsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Zugewiesene IP-Adressen im GPRS-Netz . . . . . . . . . . . . . . . . . 41
5.1 Ubersicht uber die benutzten Smartphones . . . . . . . . . . . . . . . . 485.2 Ergebnisse der Latenzmessung . . . . . . . . . . . . . . . . . . . . . . . 665.3 Dateinamen des Demonstrators . . . . . . . . . . . . . . . . . . . . . . 66
Diplomarbeit Frank Felgner
Listings 112
Listings
5.1 Zwei-Phasen-Konstruktion . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Synchrone Abarbeitung eines Timers . . . . . . . . . . . . . . . . . . . 535.3 Asynchrone Abarbeitung eines Timers . . . . . . . . . . . . . . . . . . 535.4 Einbindung eines Ressourcen-Strings . . . . . . . . . . . . . . . . . . . 565.5 Zerlegung der Dateigroße . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6 Initialisierung des Status des anrufenden Objekts . . . . . . . . . . . . 615.7 Komplettierung des Status eines aktiven Objekts . . . . . . . . . . . . 61
Diplomarbeit Frank Felgner
Abkurzungsverzeichnis 113
Abkurzungsverzeichnis
3GPP . . . . . . . . . . . . . . 3rd Generation Partnership ProjectAPI . . . . . . . . . . . . . . . . Application Programming InterfaceAPN . . . . . . . . . . . . . . . Access Point NameARM . . . . . . . . . . . . . . . Acorn RISC MachineATM . . . . . . . . . . . . . . . Asynchronous Transfer ModeAuC . . . . . . . . . . . . . . . Authentication CenterBSC . . . . . . . . . . . . . . . Base Station ControllerBSS . . . . . . . . . . . . . . . . Base Station SubsystemBTS . . . . . . . . . . . . . . . Base Transceiver StationCCH . . . . . . . . . . . . . . . Control ChannelCEPT . . . . . . . . . . . . . . Conference Europeenne des Administrations des Postes et des
TelecommunicationsCS . . . . . . . . . . . . . . . . . Coding SchemeCSD . . . . . . . . . . . . . . . Circuit Switched DataDCS . . . . . . . . . . . . . . . Digital Cellular SystemDNS . . . . . . . . . . . . . . . Domain Name SystemEDGE . . . . . . . . . . . . . Enhanced Data Rates for Global EvolutionEIR . . . . . . . . . . . . . . . . Equipment Identity RegisterETSI . . . . . . . . . . . . . . . European Telecommunications Standards InstituteFDD . . . . . . . . . . . . . . . Frequency Division DuplexFDMA . . . . . . . . . . . . . Frequency Division Multiple AccessFEC . . . . . . . . . . . . . . . Forward Error CorrectionFR . . . . . . . . . . . . . . . . . Frame RelayFR . . . . . . . . . . . . . . . . . Full Rate CodecFTP . . . . . . . . . . . . . . . File Transfer ProtocolGGSN . . . . . . . . . . . . . Gateway GPRS Support NodeGMM/SM . . . . . . . . . . GPRS Mobility Management/Session ManagementGMSC . . . . . . . . . . . . . Gateway Mobile (Services) Switching CenterGPRS . . . . . . . . . . . . . . General Packet Radio ServiceGSM . . . . . . . . . . . . . . . Global System for Mobile CommunicationsGSN . . . . . . . . . . . . . . . GPRS Support NodeGTP . . . . . . . . . . . . . . . GPRS Tunnelling ProtocolGUI . . . . . . . . . . . . . . . . Graphical User InterfaceHLR . . . . . . . . . . . . . . . Home Location RegisterHSCSD . . . . . . . . . . . . High Speed Circuit Switched DataHSDPA . . . . . . . . . . . . High Speed Downlink Packet AccessHSUPA . . . . . . . . . . . . High Speed Uplink Packet AccessHTTP . . . . . . . . . . . . . Hypertext Transfer Protocol
Diplomarbeit Frank Felgner
Abkurzungsverzeichnis 114
ICMP . . . . . . . . . . . . . . Internet Control Message ProtocolIDE . . . . . . . . . . . . . . . . Integrated Development EnvironmentIEEE . . . . . . . . . . . . . . . Institute of Electrical and Electronics EngineersIETF . . . . . . . . . . . . . . . Internet Engineering Task ForceIMEI . . . . . . . . . . . . . . . International Mobile Station Equipment IdentityIMSI . . . . . . . . . . . . . . . International Mobile Subscriber IdentityIP . . . . . . . . . . . . . . . . . . Internet ProtocolISO . . . . . . . . . . . . . . . . International Organization for StandardizationISP . . . . . . . . . . . . . . . . Internet Service ProviderLAN . . . . . . . . . . . . . . . Local Area NetworkLSB . . . . . . . . . . . . . . . . Least Significant BitME . . . . . . . . . . . . . . . . Mobile EquipmentMIME . . . . . . . . . . . . . Multipurpose Internet Mail ExtensionsMMS . . . . . . . . . . . . . . . Multimedia Messaging ServiceMS . . . . . . . . . . . . . . . . . Mobile StationMSB . . . . . . . . . . . . . . . Most Significant BitMSC . . . . . . . . . . . . . . . Mobile (Services) Switching CenterMSISDN . . . . . . . . . . . Mobile Subscriber International Service Directory NumberNAT . . . . . . . . . . . . . . . Network Address TranslationNS . . . . . . . . . . . . . . . . . Name ServerNSS . . . . . . . . . . . . . . . . Network and Switching SubsystemOBEX . . . . . . . . . . . . . Object ExchangeOMC . . . . . . . . . . . . . . Operation and Maintenance CenterOMS . . . . . . . . . . . . . . . Operation and Management SubsystemOPL . . . . . . . . . . . . . . . Open Programming LanguageOSI . . . . . . . . . . . . . . . . Open Systems InterconnectionP-TMSI . . . . . . . . . . . . Packet-Temporary Mobile Subscriber IdentityPDA . . . . . . . . . . . . . . . Personal Digital AssistantPDN . . . . . . . . . . . . . . . Public Data NetworkPDP . . . . . . . . . . . . . . . Packet Data ProtocolPDTCH . . . . . . . . . . . . Packet Data Traffic ChannelPPP . . . . . . . . . . . . . . . Point-to-Point ProtocolQoS . . . . . . . . . . . . . . . . Quality of ServiceRAM . . . . . . . . . . . . . . . Read Access MemoryRFC . . . . . . . . . . . . . . . Request For CommentsRLP . . . . . . . . . . . . . . . Radio Link ProtocolRNC . . . . . . . . . . . . . . . Radio Network ControllerRNS . . . . . . . . . . . . . . . Radio Network SubsystemROM . . . . . . . . . . . . . . . Read Only MemoryRTP . . . . . . . . . . . . . . . Realtime Transport ProtocolRTT . . . . . . . . . . . . . . . Round Trip TimeSDK . . . . . . . . . . . . . . . Software Development KitSDMA . . . . . . . . . . . . . Space Division Multiple AccessSGSN . . . . . . . . . . . . . . Serving GPRS Support NodeSIM . . . . . . . . . . . . . . . . Subscriber Identity Module
Diplomarbeit Frank Felgner
Abkurzungsverzeichnis 115
SLIP . . . . . . . . . . . . . . . Serial Line Internet ProtocolSMIL . . . . . . . . . . . . . . Synchronized Multimedia Integration LanguageSMS . . . . . . . . . . . . . . . Short Message ServiceSTUN . . . . . . . . . . . . . . Simple Traversal of User Datagram Protocol Through Network
Address TranslatorsSTUNT . . . . . . . . . . . . Simple Traversal of UDP Through NATs and TCP tooTCH . . . . . . . . . . . . . . . Traffic ChannelTCH/F . . . . . . . . . . . . Traffic Channel/Full-RateTCH/H . . . . . . . . . . . . Traffic Channel/Half-RateTCP . . . . . . . . . . . . . . . Transmission Control ProtocolTDMA . . . . . . . . . . . . . Time Division Multiple AccessTFI . . . . . . . . . . . . . . . . Temporary Flow IdentifierTID . . . . . . . . . . . . . . . . Tunnel IdentifierTLD . . . . . . . . . . . . . . . Top Level DomainTRAU . . . . . . . . . . . . . Transcoding and Rate Adaptation UnitTURN . . . . . . . . . . . . . Traversal Using Relay NATUDP . . . . . . . . . . . . . . . User Datagram ProtocolUID . . . . . . . . . . . . . . . . Unique IDUMTS . . . . . . . . . . . . . Universal Mobile Telecommunications SystemURI . . . . . . . . . . . . . . . . Uniform Resource IdentifierUTRAN . . . . . . . . . . . . UMTS Terrestrial Radio Access NetworkVLR . . . . . . . . . . . . . . . Visitor Location RegisterVPN . . . . . . . . . . . . . . . Virtual Private NetworkW-CDMA . . . . . . . . . . Wide Code Division Multiple AccessWLAN . . . . . . . . . . . . . Wireless Local Area Network
Diplomarbeit Frank Felgner
Thesen zur Diplomarbeit 116
Thesen zur Diplomarbeit
1. Die heutige Mobilfunktechnologie ist fur die Ubertragung multimedialer Inhaltevia
”Push“ geeignet.
2. Mit der flachendeckenden Einfuhrung von UMTS werden die Multimediaange-bote fur mobile Endgerate stark zunehmen.
3. Das Internet wird integraler Bestandteil mobiler Endgerate werden.
4. Smartphones werden langfristig Mobiltelefone ersetzen.
5. Symbian OS bleibt durch seine offene Architektur das fuhrende Betriebssystemfur Smartphones.
6. Das konzipierte System ist erst attraktiv fur den Konsumenten, wenn ihm furden Datenempfang keine Kosten entstehen.
7. Die Losung des NAT-Problems ist von fundamentaler Bedeutung fur den kom-merziellen Erfolg des Systems.
Ilmenau, den 31. 03. 2006 Frank Felgner
Diplomarbeit Frank Felgner
Erklarung 117
Erklarung
Die vorliegende Arbeit habe ich selbststandig ohne Benutzung anderer als der ange-gebenen Quellen angefertigt. Alle Stellen, die wortlich oder sinngemaß aus veroffent-lichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit istin gleicher oder ahnlicher Form oder auszugsweise im Rahmen einer oder anderer Pru-fungen noch nicht vorgelegt worden.
Ilmenau, den 31. 03. 2006 Frank Felgner
Diplomarbeit Frank Felgner