technische universit¨at ilmenau fakult¨at fu¨r elektrotechnik und...

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.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.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.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


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


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


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.


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.



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



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.



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.



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.



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.



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-



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



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



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-



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.


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



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-



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.



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.


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



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.



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



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



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.




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.


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]



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.



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.



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.



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-



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



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.



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



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.



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



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.



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.



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.



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.



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.



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



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



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.



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



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.



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.



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-



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.



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.



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



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-



tragen, ohne zusatzliche Kosten zu verursachen. MS1 zahlt nur den Preis fur einen

GPRS-Datenblock.



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-



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.



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.



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.



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( ) ;



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.



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.



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.



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.



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



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-



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.



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.



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.



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.



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



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.



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-



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.



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.



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



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.



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



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



ihre Vorteile ausspielen konnen. Zusammenfassend und abschließend kann festgehalten

werden, dass die Einsatzmoglichkeiten des Systems nahezu unbegrenzt sind.


72

Anhang


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):


connect to [80.187.80.220] from erf9-d932f56f.pool.mediaWays.net [217.5

0.245.111] 41769

A.1.2 Vodafone








RX bytes:962 (962.0 b) TX bytes:515 (515.0 b)


A Messungen 74

Ausgabe von nc -lvp 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








RX bytes:4459 (4.3 KiB) TX bytes:4030 (3.9 KiB)

Ausgabe von nc -lvp 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


time=771 ms


time=692 ms


time=692 ms


time=700 ms


time=690 ms


time=692 ms


time=687 ms



A Messungen 75

time=706 ms


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











--- google.de ping statistics ---


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


=691 ms


=707 ms


=713 ms


=752 ms


=693 ms


=687 ms


=693 ms



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 ---


rtt min/avg/max/mdev = 687.721/702.365/752.690/18.701 ms


B Applikation 77

B Applikation

B.1 Klassendiagramme

B.1.1 Application Framework

.


B Applikation 78

B.1.2 Zustandsautomat

.


B Applikation 79

B.1.3 Kommunikationsklassen


B Applikation 80


B Applikation 81


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


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) ;


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


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


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 ( ) ;


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


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 ;


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 {


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 ( ) ;


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 ”) ) ;


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


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


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 {


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


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 ( )


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 ) ;


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 ) ;


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


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


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


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


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


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


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 }



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


http://www.ethereal.com/

http://netcat.sourceforge.net/

http://www.s60.com/devices

http://www.uiq.com/uiqphones

http://www.heise.de/mobil/newsticker/meldung/64774




http://www.teltarif.de/arch/2006/kw10/s20746.html

http://www.teltarif.de/arch/2006/kw10/s20746.html

http://www.symbian.com/developer/sdks/index.asp

http://www.ietf.org/rfc/rfc1122.txt


[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


http://nutss.gforge.cis.cornell.edu/pub/draft-guha-STUNT-00.txt


http://www.itu.int/itudoc/itu-t/workshop/enum/010_pp7.ppt



http://www.forum.nokia.com/main/1,6566,1_43_50_10,00.html

http://www.forum.nokia.com/main/1,6566,1_43_50_10,00.html

http://research.nokia.com/research/projects/mobile-web-server/index.html

http://research.nokia.com/research/projects/mobile-web-server/index.html

http://sw.nokia.com/id/19397f28-e130-452a-8d0c-be67eb532cfe/S60_Platform_FAQ_v1_6_en.pdf

http://sw.nokia.com/id/19397f28-e130-452a-8d0c-be67eb532cfe/S60_Platform_FAQ_v1_6_en.pdf






[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







http://turtiainen.dna.fi/GPRS-HOWTO

http://de.wikipedia.org/w/index.php?title=High_Speed_Uplink_Packet_Access&oldid=13912544

http://de.wikipedia.org/w/index.php?title=High_Speed_Uplink_Packet_Access&oldid=13912544

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


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


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



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



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



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


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.



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.



technische universit¨at ilmenau fakult¨at fu¨r elektrotechnik und...

Documents