Diplomarbeit - TU Ilmenau

Technische Universität Ilmenau 

Fakultät für Elektrotechnik und 

Informationstechnik 

O2(Germany) 

Access Engineering 

Diplomarbeit 

Optimierung paketvermittelter Dienste in 

UMTS-Mobilfunknetzen 

Am Beispiel des Netzes von O2(Germany) 

Inventarisierungsnummer: 2007-01-15 / 009 / II01 / 2115 

vorgelegt von: Andreas Herz 

eingereicht am: 28. 11. 2006 

geboren am: 

Studiengang: Ingenieurinformatik 

Studienrichtung: Telekommunikations- und 

Messtechnik 

Anfertigung im Fachgebiet: Kommunikationsnetze 

Fakultät für Elektrotechnik und Informationstechnik 

Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz 

Wissenschaftlicher Betreuer: Dipl.-Ing. Yevgeniy Yeryomin 

Betrieblicher Betreuer: Dipl.-Ing. Bernd Bergmann

Kurzfassung 

Die Diplomarbeit ist bei der Firma O2(Germany) GmbH & Co. OHG in München 

entstanden und wurde von Prof. Dr. rer. nat. habil. Jochen Seitz vom Institut für 

Informationstechnik an der Technischen Universität Ilmenau betreut. 

Die vorliegende Arbeit behandelt Optimierungskonzepte in paketvermittelten UMTS- 

Mobilfunknetzen. Diese sind aus verschiedenen Tests und Analysen des bestehenden 

UMTS-Netzes von O2(Germany) hervorgegangen. Anschließend werden die Konzepte 

diskutiert und in dem UMTS-Netz von O2(Germany) getestet.

Abstract 

This diploma thesis is originated at the company O2(Germany) GmbH & Co. OHG in 

Munich and was supervised by Prof. Dr. rer. nat. habil. Jochen Seitz from the Faculty 

of Electrical Engineering and Information Technology at the Technical University Il- 

menau. 

The objective of the thesis is to identify and analyse the methodology on how to optimi- 

se packet-switched UMTS Mobile Networks. The development of these methodologies 

will be based upon tests and analysis undertaken upon the existing O2(Germany) 

UMTS Network. After that the methodology/ies will be discussed and tested in the 

real network of O2(Germany).

Inhaltsverzeichnis i 

Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Motivation & Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Historie O2(Germany) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.3 Historie Paketvermittlung . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.4 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2 Grundlagen 4 

2.1 Paketvermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.2 Protokolle und Anwendungen . . . . . . . . . . . . . . . . . . . . . . . 5 

2.2.1 IP - Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2.2 NAT - Network Address Translation . . . . . . . . . . . . . . . 7 

2.2.3 RTT - Round Trip Time . . . . . . . . . . . . . . . . . . . . . . 8 

2.2.4 TCP - Transmission Control Protocol . . . . . . . . . . . . . . . 8 

2.2.5 UDP - User Datagramm Protocol . . . . . . . . . . . . . . . . . 9 

2.2.6 HTTP - HyperText Transfer Protocol . . . . . . . . . . . . . . . 9 

2.2.7 FTP - File Transfer Protocol . . . . . . . . . . . . . . . . . . . . 9 

2.2.8 VoIP - Voice over IP . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.9 Videostreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.3 QoS - Quality of Service (nach 3GPP 22.959) . . . . . . . . . . . . . . 11 

2.3.1 QoS in IP-basierten Netzen . . . . . . . . . . . . . . . . . . . . 11 

2.3.2 Realisierung in IP-basierten Netzen . . . . . . . . . . . . . . . . 12 

2.4 UMTS - Universal Mobile Telecommunication System - Grundlagen . . 13 

2.4.1 UTRAN - UMTS Terrestrial Radio Access Network . . . . . . . 13 

2.4.2 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.4.3 Kanäle in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.4.4 Protokollmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.4.5 QoS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2007-01-15 / 009 / II01 / 2115 Diplomarbeit Andreas Herz

Inhaltsverzeichnis ii 

2.5 PDP - Packet Data Protocol . . . . . . . . . . . . . . . . . . . . . . . . 24 

2.5.1 Inaktiver Zustand (”INACTIVE”) . . . . . . . . . . . . . . . . . 24 

2.5.2 Aktiver Zustand (”ACTIVE”) . . . . . . . . . . . . . . . . . . . 25 

2.5.3 PDP-Kontext-Aktivierung und -Deaktivierung . . . . . . . . . . 25 

2.5.4 APN - Access Point Name . . . . . . . . . . . . . . . . . . . . . 27 

2.6 Momentansituation UMTS-Netz O2(Germany) . . . . . . . . . . . . . . 27 

2.7 HSDPA - High Speed Downlink Packet Access . . . . . . . . . . . . . . 29 

3 Testumgebungen für paketvermittelte Dienste in UMTS 32 

3.1 Optimierungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.1.1 Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.1.2 Übertragungsdauer . . . . . . . . . . . . . . . . . . . . . . . . . 33 

3.1.3 Anzahl an empfangenen Paketen . . . . . . . . . . . . . . . . . 33 

3.1.4 Übertragungswiederholungen . . . . . . . . . . . . . . . . . . . 34 

3.2 Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.2.1 Verwendete Hardware . . . . . . . . . . . . . . . . . . . . . . . 34 

3.2.2 Verwendete Software . . . . . . . . . . . . . . . . . . . . . . . . 35 

3.3 Kriterien der Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

3.4 Messszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

3.4.1 Standort der Messung . . . . . . . . . . . . . . . . . . . . . . . 42 

3.4.2 Beschreibung des Ablaufs der Messungen . . . . . . . . . . . . . 43 

3.5 Auswertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4 Optimierungskonzepte 52 

4.1 Anpassung der TCP/IP Einstellungen (Endgerät) . . . . . . . . . . . . 52 

4.2 Dynamischer Upgrade des RAB (Uu-Schnittstelle) . . . . . . . . . . . . 53 

4.3 Parameteroptimierung (RNC) . . . . . . . . . . . . . . . . . . . . . . . 55 

4.4 Aktivierung der ”Streaming”-Klasse (HLR) . . . . . . . . . . . . . . . . 56 

4.5 Applikationspezifische Komprimierung (Gi-Schnittstelle) . . . . . . . . 56 

4.6 Network Address Translation (Gi-Schnittstelle) . . . . . . . . . . . . . 58 

5 Implementierung 60 

5.1 Anpassung der TCP/IP Einstellungen (Endgerät) . . . . . . . . . . . . 60 

5.1.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

5.1.2 Windows-Registrierungs-Einträge . . . . . . . . . . . . . . . . . 61 

5.1.3 Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

5.1.4 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 


Inhaltsverzeichnis iii 

5.1.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

5.2 Dynamischer Upgrade des RAB (Uu-Schnittstelle) . . . . . . . . . . . . 67 


5.2.2 Verwendete Parameter . . . . . . . . . . . . . . . . . . . . . . . 67 

5.2.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

5.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

5.3 Parameteroptimierung (RNC) . . . . . . . . . . . . . . . . . . . . . . . 71 


5.3.2 Parametereinstellungen . . . . . . . . . . . . . . . . . . . . . . . 71 

5.3.3 Testbed-Analysen . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

5.3.4 Erste Live-Netz-Messung . . . . . . . . . . . . . . . . . . . . . . 83 

5.3.5 Zweite Live-Netz-Messung . . . . . . . . . . . . . . . . . . . . . 89 

5.3.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

5.4 Aktivierung der ”Streaming”-Klasse (HLR) . . . . . . . . . . . . . . . . 93 


5.4.2 Parametereinstellungen . . . . . . . . . . . . . . . . . . . . . . . 93 

5.4.3 Testbed-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

5.4.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 

6 Zusammenfassung / Ausblick 100 

Literaturverzeichnis 102 

Abbildungsverzeichnis 105 

Tabellenverzeichnis 108 

Abkürzungsverzeichnis 109 

Thesen zur Diplomarbeit 112 

Erklärung 113 



1 Einleitung 

1.1 Motivation & Aufgabenstellung 

In der schnelllebigen Zeit wachsender Mobilfunknetze und immer höherer Datendurch- 

sätze an der Luftschnittstelle steigen die Anforderungen an das Mobilfunknetz stetig. 

Auch auf dem Gebiet Universal Mobile Telecommunications System (UMTS) kommt 

es zu immer höheren Anforderungen seitens der Kunden. Diese Anforderungen be- 

ziehen sich vermehrt auf die Nutzung von mobilen Datendiensten. Ein Beispiel sind 

multimediale Anwendungen, welche überall von Kunden uneingeschränkt genutzt wer- 

den wollen. Dafür stehen in den zellularen Netzwerken ausgefeilte Algorithmen zur 

Verfügung. In dieser Diplomarbeit sollen Optimierungskonzepte für paketvermittelte 

Dienste erarbeitet und soweit möglich in das bestehende Netz implementiert werden. 

Die Arbeit wird mit O2(Germany), einem der großen Mobilfunknetzanbieter Deutsch- 

lands, durchgeführt. 

1.2 Historie O2(Germany) 

Die VIAG Interkom befand sich seit ihrer Gründung 1995 im Besitz der VIAG (spä- 

ter: E.ON) mit 45 %, BritishTelecom (BT) mit ebenfalls 45 % sowie des norwegischen 

Telekommunikationsunternehmens Telenor. 1997 zog das heutige O2(Germany) ander- 

en Mobilfunknetzbetreibern (Telekom, E-Plus) nach und erwarb Lizenzen im E-Netz. 

Im Jahr 2000 übernahm BT das Unternehmen vollständig, nachdem sich E.ON aus 

dem Telekommunikationsbereich zurückzog. Im Zuge der Strategie einer Abtrennung 

des Mobilfunks aus dem übrigen Geschäftsbereich spaltete sich BT im Jahr 2001 in 

die Unternehmen BT Ignite (Festnetz) sowie mmO2 (Mobilfunk). Auch im deutschen 

Tochterunternehmen VIAG Interkom wurde diese Trennung vollzogen und das Fest- 

netzgeschäft an British Telecom verkauft. Im Jahr 2002 wurden in der Folge die Namen 

der aus VIAG Interkom entstandenen Unternehmen an die der jeweiligen Mutter an- 

gepasst. Um Verwechslungen mit dessen D2-Netz zu vermeiden, verständigte man sich 

mit Vodafone darauf, in Deutschland nur die Schreibweisen O2 oder o2 zu verwenden. 



Abbildung 1.1: O2(Germany) heute 

Das von O2(Germany) betriebene Global System for Mobile Communciations (GSM) 

1800-Mobilfunknetz befindet sich seit Herbst 1998 in kommerzieller Nutzung. Im Jahr 

2000 kaufte Viag Interkom eine UMTS Lizenz für 16,52 Milliarden DM und beginnt 

2004 mit der kommerziellen Vermarktung von UMTS. Die O2(Germany) GmbH &Co. 

OHG (ehemals VIAG Interkom) ist mit über 11 Millionen Kunden (Stand: November 

2006) der viertgrößte Mobilfunknetzbetreiber in Deutschland. [Wiki06c] 

1.3 Historie Paketvermittlung 

Der gesamte Telefonverkehr beginnend mit den ersten Telefonaten bis hin zu UMTS 

ist leitungsvermittelt, d.h. dass ankommende Gespräche auf eine Leitung (im Festnetz) 

oder einem Kanal (Frequenz oder Zeit im Mobilfunknetz) durchgeschaltet werden. 

Während der gesamten Gesprächsdauer wird die Ressource von diesem Teilnehmer 

belegt und ist somit für andere potentielle Nutzer blockiert. 

Donald Watts Davies entwickelte seit 1963 die Methode der Paketvermittlung, wie 

sie heute im gesamten Internetverkehr genutzt wird [Wiki06a]. Dieses Prinzip wird 

auch in den Datendiensten von GSM und UMTS verwendet. Dabei werden einzelne 

Datenströme in kleinere Pakete unterteilt und Informationen über den Bestimmungs- 

ort angehängt. Somit sind Ressourcen nur für sehr kurze Zeiträume blockiert. Router 

übernehmen dann in dem paketvermittelten Netz die Ressourcenverwaltung. Weitere 

paketvermittelte Netze sind z.B. Internet, Local Area Network (LAN) oder Asynchro- 

nous Transfer Mode (ATM). Im Vergleich zur Leitungsvermittlung ist zu erkennen, 

dass die Verzögerungszeiten durch die Größe der Pakete klein bleiben und somit das 

Netz effektiver ausgelastet ist, die Ressourcen werden besser verteilt und Übertragungs- 

fehler können schnell erkannt und behoben werden. Sollte es zu Ausfällen innerhalb 



der Route geben kann der Datenstrom umgelenkt werden. [Wiki06d] 

Des Weiteren müssen alle Teilnehmer die gleichen Netzwerkprotokolle benutzen, da 

eine Kommunikation sonst nicht möglich ist. Ein weiteres Problem ist die Garantie ei- 

ner bestimmten Bandbreite, da diese großen Schwankungen aufgrund unterschiedlicher 

Verkehrslast unterliegt. Es kann nur mit Hilfe von Quality of Service (QoS) Parame- 

tern eine bestimmte Bandbreite garantiert werden, so dass am Router, im Falle eines 

Paketstaus, Prioritäten in den einzelnen Paketen entscheiden, ob das Paket verworfen 

(niedrige Priorität) oder als nächstes gesendet wird (hohe Priorität). Auf diese Weise 

erhält man indirekt eine zugesicherte Bandbreite, welche auch null betragen kann. 

Die Untersuchung und Optimierung dieser paketvermittelten Datendienste im UMTS- 

Netz von O2(Germany) soll Inhalt dieser Arbeit sein. 

1.4 Gliederung 

Die Gliederung der Arbeit ist so aufgebaut wie die Optimierung des UMTS-Netzes 

von O2(Germany), sie beginnt mit der Analyse des bestehenden Netzes [ab Seite 32]. 

Anschließend werden verschiedene Optimierungskonzepte aus den Analysen entwickelt 

und vorgestellt [ab Seite 52]. Das vielversprechendste Konzept wird ausgewählt und 

soweit möglich im Live-Netz getestet. Die Resultate werden dokumentiert und analy- 

siert [ab Seite 60]. Es wird eine entsprechende Änderung im Live-Netz vorgeschlagen. 

Die Zusammenfassung und ein Ausblick auf evtl. Folgearbeiten ist ab Seite 100 nach- 

zulesen. 



2 Grundlagen 

Allgemein wurde von O2(Germany) folgende Literatur bereitgestellt, welche als Grund- 

lagen für UMTS und die Optimierung verwendet wurden: [Laih02], [Holm00], [Mish04], 

[Krüg04] und [Cast04]. 

2.1 Paketvermittlung 

Die Paketvermittlung ist ein spezielles Verfahren der Speichervermittlung in Netzwerk- 

en und erfährt eine immer stärkere Nutzung als die Leitungsvermittlung. Bei leitungs- 

vermittelten Verbindungen wird eine Leitung für einen Benutzer reserviert. Während 

dieser Zeit kann die Leitung von keinem anderen genutzt werden, selbst wenn die 

Leitung nicht vom Nutzer benutzt wird (z.B. bei Sprache: Sprachpausen). Bei der Pa- 

ketvermittlung wird der Übertragungskanal nicht exklusiv reserviert, sondern kann von 

mehreren Verbindungen (und somit Nutzern) quasi gleichzeitig genutzt werden, so dass 

im Falle einer Sprachpause die Leitung anderweitig benutzt werden kann. 

Bei der Paketvermittlung, so wie sie in modernen Netzwerken genutzt wird, wird kei- 

ne spezielle Route ausgewählt, sondern nach jedem Abschnitt erneut über die Route 

entschieden. Diese Aufgaben übernehmen die Router im Netzwerk, in ihnen sind aktu- 

elle Informationen über naheliegende Router gespeichert, so dass entschieden werden 

kann, welches der kürzeste Weg ist. Da jedes Paket so theoretisch einen anderen Weg 

nehmen kann, müssen die Pakete nummeriert werden, um sie am Empfänger wieder 

in die richtige Reihenfolge zu sortieren. Weiterhin existieren auch verbindungsorien- 

tierte Paketvermittlungen, z.B. ATM. Bei ATM wird eine festgelegte Route genutzt, 

über welche die Pakete gesendet werden. Dabei müssen die Pakete nicht nummeriert 

werden. 

Mit Hilfe der Paketvermittlung kann eine bessere Auslastung des Netzwerkes erreicht 

werden und die Wartezeiten bleiben für die Benutzer im Allgemeinen kleiner. Über- 

tragungsfehler können schnell behoben werden, da diese schon in einzelnen Paketen 

erkannt werden. 

Die Paketvermittlung wird auch in den Datendiensten in UMTS-Netzen eingesetzt, 



wie z. B. bei Videostreaming, Web-Browsing oder Voice over IP (VoIP). Da in den 

UMTS-Netzen, die Luftschnittstelle nicht auf die gleiche Weise kontrolliert werden 

kann, wie Leitungen in einem LAN, ist es schwierig hier QoS-Parameter zu verwen- 

den. Eine bestimmte Bandbreite kann nie garantiert werden, da die Luftschnittstelle 

unbeeinflussbaren, natürlichen Einwirkungen unterliegt (Reflektionen, Streuung, etc.). 

Eine Möglichkeit ist die Reservierung von verfügbaren Ressourcen für bestimmte Nut- 

zergruppen. Wenn diese Reservierung ins Netz integriert ist, gibt es eine Einteilung 

der Nutzer nach Vertrag, Umsatz und anderen Punkten, welche vom Management ei- 

ner Firma festgelegt werden. Diese Nutzer werden in Bronze-, Silber- und Goldkunden 

unterteilt. Kommt z.B. ein Goldkunde (mit zugesicherten 384 kbit/s) in eine Zelle, in 

welcher drei Bronzekunden (zwei mit 384 kbit/s und einer mit 128 kbit/s) surfen, wer- 

den all Bronzekunden auf 128 kbit/s abgestuft oder eventuell einer von ihnen geblockt. 

Im Sinne des Images einer Firma wird allerdings erst die Geschwindigkeit reduziert, 

bevor ein Kunde komplett blockiert wird. Der Goldkunde erhält so die vereinbarten 

384 kbit/s. 

Nutzt man Paketvermittlung, müssen verschiedene Anforderungen für Applikatio- 

nen spezifiziert werden. So existieren verschiedene Echtzeitanwendungen, die andere 

Anforderungen an ein paketvermitteltes Netz stellen, als Anwendungen, die nicht in 

Echtzeit ablaufen. So macht es beispielsweise keinen Sinn bei einem Videostreaming 

fehlerhafte Pakete neu zu übertragen. [Barn88] [Stev03] 

2.2 Protokolle und Anwendungen 

Service Data Unit (SDU) & Protocol Data Unit (PDU) 

Eine PDU ist ein Datenblock, der vom Sender zum Empfänger gesendet wird. Beim 

Sender werden auf jeder Schicht N (z.B. OSI Referenz Modell) Kontrollinformationen 

(engl. Header) hinzugefügt, diese bilden, zusammen mit den zu übertragenden Daten, 

die neue PDU dieser Schicht, PDU(N). Die nächste Schicht N-1 bietet den Dienst die 

PDU(N) zu übertragen, die PDU(N) wird auf der Schicht N-1 SDU(N-1) genannt. 

PDU(N) = SDU(N-1) 

PDU(N) = PCI(N) + SDU(N) + Trailer(N) 

Protocol Control Information (PCI) und Footer sind dabei die Informationen, welche 

zusätzliche Informationen enthalten (z.B. Header). 



Am Empfänger werden diese Kontroll- und Verwaltungsinformationen, auf der ent- 

sprechenden Schicht, ausgewertet und entfernt. 

Payload Unit (PU) 

Da die Übertragung großer Pakete störanfälliger ist als die Übertragung mehrerer klei- 

ner Pakete (Übertragungswiederholungen), werden die SDUs / PDUs vom Radio Link 

Control (RLC)-Protokoll [Kap. 2.4.4] in kleinere Einheiten zerlegt, den PU. Diese wer- 

den als Datenströme physisch übertragen und bilden somit die kleinste Einheit der 

paketvermittelten Netze. 

Stehen beispielsweise zwei SDUs zum Übertragen an, kann es vorkommen, dass in 

einer PU Daten von beiden SDUs vorhanden sind. Sollte dieses Paket fehlerhaft sein, 

kann es vorkommen, dass beide SDUs komplett neu übertragen werden müssen. 

2.2.1 IP - Internet Protocol 

Abbildung 2.1: Protokollübersicht 

Das Internet Protocol (IP) ist ein weit verbreitetes Netzwerkprotokoll in Computer- 

netzwerken. Es befindet sich auf der Vermittlungsschicht im OSI-Modell und auf der 

Internet-Schicht im TCP/IP-Modell [Abb. 2.1]. Es bildet die Grundlage vom Inter- 

net. [Stev03] 

Die Schicht des IP-Protokolls ist die erste Schicht, welche unabhängig vom Übertra- 

gungsmedium ist. Jeder Computer bekommt eine IP-Adresse und eine Subnetzmaske 

zugewiesen, damit ist es möglich, logische Einheiten innerhalb eines Netzwerkes zu 

gruppieren. So können einzelne Computer in einem großen Netzwerk adressiert wer- 

den. 

IP Version 4 (IPv4), bestehend aus 32 bit Adressen, ist das zurzeit im Internet 

verwendete Protokoll. Hier werden vier Blöcke, jeder besteht aus 8 Bit, verwendet um 

die IP-Adresse festzulegen: z.B. 142.48.122.82. 

Theoretisch ist es mit IPv4 möglich 4.294.967.296 Computer zu adressieren. Durch 

die Vergabe von Subnetzen an Firmen, Universitäten etc. wird die Anzahl aber deutlich 



beschränkt, so dass andere Lösungen gefunden werden mussten. Es wurden Adress- 

Bereiche definiert, welche jeder privat verwenden kann. Geht man über das privaten 

Netzwerk hinaus, in das Internet, benötigt man eine andere IP-Adresse um Verwechs- 

lungen zu vermeiden. Somit benötigt man ein Verfahren, mit welchen es möglich ist, 

die IP-Adressen zwischen den privaten und den öffentlichen Netzen umzuschreiben. 

Für diese Umsetzung wird Network Address Translation (NAT) verwendet. 

Mit IP Version 6 (IPv6) wird NAT nicht mehr benötigt, da 2 128 IP-Adressen zu 

Verfügung stehen (128 bit Adressen). [Losh04] 

2.2.2 NAT - Network Address Translation 

NAT wurde eingeführt, um die knappen Ressourcen der IPv4 Adressen besser auszu- 

nutzen und verschiedene Netzwerke im Internet, oder auch Netzwerke in Netzwerken, 

zu verbinden. 

Funktionsweise 

NAT läuft als Dienst auf einem Router, einer Firewall oder einem eigenständigen Ge- 

rät und wird an einem Übergang zwischen Netzen durchgeführt. Es gibt zwei Arten 

Abbildung 2.2: Beispiel Source NAT 

von NAT-Umsetzung, Source NAT [Abb. 2.2], bei welcher die Quell-IP-Adresse umge- 

setzt wird und die Destination NAT, bei welcher die Ziel-IP-Adresse umgesetzt wird. 

Bei der Umsetzung werden immer freie öffentliche IP-Adressen zugewiesen, welche an- 

schließend wieder freigegeben werden können. 

Die am häufigsten verwendete NAT-Art ist ”Symmetric NAT”. [Wiki06b] 

Bei der NAT werden die IP-Adressen in den Paketen umgeschrieben, was zu Proble- 

men bei Verschlüsselungsverfahren führt, da sich beispielsweise eine andere Prüfsumme 

ergeben kann. 



2.2.3 RTT - Round Trip Time 

Die Zeit, welche ein Daten- 

paket benötigt um von einer 

Quelle zum Ziel und zurück 

zu kommen, wird als Round 

Trip Time (RTT) bezeichnet. 

Je nach Netzwerk können 

die RTTs unterschiedlich aus- 

fallen. So wird die RTT in ei- 

nem LAN, welches mit Ka- 

beln vernetzt ist, wesentlich 

schneller sein, als in einem Mo- 

bilfunknetzwerk, in dem die 

Pakete über die Luftschnitt- 

stelle übertragen werden müs- 

sen (z.B.: Abb. 2.3). 

Abbildung 2.3: Vergleich RTT, R99 und HSDPA 

[Yang05] 

2.2.4 TCP - Transmission Control Protocol 

Das Transmission Control Protocol (TCP) ist das am weitesten verbreitete verbin- 

dungsorientierte Transportprotokoll. Es ist Teil der Internetprotokollfamilie, der Grund- 

lage des Internets. Durch TCP ist eine Kommunikation verschiedener Rechner unter- 

einander erst möglich, da die Art und Weise der Kommunikation in TCP standardisiert 

ist. Es ist vergleichbar mit der Einigung auf eine Sprache, welche für alle verständlich 

ist. TCP setzt auf IP auf, weshalb man auch oft vom TCP/IP-Protokoll redet. TCP 

sitzt auf Schicht 4 des ISO/OSI Referenzmodells [Bild 2.1]. Die Adressierung bei TCP 

läuft über IP-Adresse und Portnummer. [Tane05] 

Der Vorteil von TCP ist die Möglichkeit Paketverluste durch entsprechende Algo- 

rithmen festzustellen und diese Pakete neu zu übertragen. Einer der bekanntesten 

Algorithmen in diesem Zusammenhang ist der 3-Wege-Handshake [Wiki06e]. Des Wei- 

teren sind in TCP auch Algorithmen implementiert um z.B. Netzwerküberlastungen 

zu verhindern. 

TCP wird als Transportmedium, neben vielen anderen Diensten, auch für das World 

Wide Web (WWW) (z.B. Hypertext Transfer Transport Protocol (HTTP)), für E-Mail 

Dienste und für File Transfer Protocol (FTP) eingesetzt. [Post81] [Jaco92] 



2.2.5 UDP - User Datagramm Protocol 

User Datagramm Protocol (UDP) ist im Gegensatz zu TCP ein verbindungsloses Pro- 

tokoll. UDP sitzt auf der gleichen Schicht wie TCP, auf ISO/OSI Schicht 4 [Bild 2.1]. 

Die Aufgabe von UDP ist, zu übertragende Daten der richtigen Anwendung zukommen 

zu lassen. Dies geschieht wie bei TCP mit Hilfe von IP-Adresse und Portnummer. Dies 

wird auch als Anwendungsmultiplexen bezeichnet. Im Unterschied zu TCP, sind hier 

verschiedene Algorithmen nicht integriert (z.B. 3-Wege-Handshake), so dass verlorene 

Pakete nicht erneut übertragen werden. 

UDP wird dann verwendet, wenn Übertragungswiederholungen keinerlei Information 

beinhalten, z.B. bei der Echtzeitübertragung von Sprache. [Post80] 

2.2.6 HTTP - HyperText Transfer Protocol 

HTTP ist ein Transportprotokoll, um Webseiten (Bilder, Dateien, Texte o.ä.) abzuru- 

fen. HTTP sitzt auf ISO/OSI Schicht 7, ist somit aus Sicht des Netzes eine Anwendung 

[Bild 2.1]. Wenn auf einer Webseite ein Link zu einer Uniform Resource Locator (URL) 

aktiviert wird, z.B. http://www.beispiel.de/index.html, so wird an den entfernten Host 

www.beispiel.de die Anfrage geschickt, die Ressource index.html zurückzusenden. Dazu 

wird als erstes der Name des Hosts mit Hilfe des DNS-Protokolls (Domain Name Sys- 

tem) in eine IP-Adresse umgewandelt. Über das TCP-Protokoll auf den Standard-Port 

80 des HTTP Servers wird zur Übertragung ein HTTP-GET (Anforderung) gesen- 

det. [Bern96] [Fiel99] [Gour02] 

2.2.7 FTP - File Transfer Protocol 

FTP ist ein Netzwerkprotokoll, welches ausschließlich für die Übertragung von einzel- 

nen oder mehreren Dateien (aufgeteilt auf Pakete) zuständig ist. Wie schon HTTP 

ist auch FTP auf Schicht 7 ISO/OSI angesiedelt und wird somit als Anwendung be- 

trachtet [Bild 2.1]. Der Standard-Port für FTP ist 21, über ihn können Dateien vom 

Server zum Client (Download) und vom Client zum Server (Upload) übertragen wer- 

den. Der Zugriff auf Dateien eines FTP-Servers erfolgt typischerweise erst nach einer 

Authentifizierung. Für die Steuerung der Übertragung und für die eigentliche Übertra- 

gung von Dateien verwendet FTP zwei getrennte Verbindungen. Diese Verbindungen 

werden über TCP aufgebaut. [Post85] 



2.2.8 VoIP - Voice over IP 

”Voice over IP”, wie der Name schon sagt, wird mit VoIP Sprache über ein IP-basiertes 

Netz übertragen. Wie auch bei der klassischen Sprachübertragung beginnt es für den 

Nutzer mit einem Verbindungsaufbau, gefolgt von der Gesprächsübertragung und dem 

Verbindungsabbau. Im Gegensatz zur klassischen Telefonie wird aber keine Leitung 

vermittelt, sondern die Paketvermittlung (Kapitel 2.1) genutzt. [Bada05] 


Da VoIP auf IP basiert, müssen die IP-Adressen der Teilnehmer bekannt sein. Diese 

werden im Internet nicht statisch vergeben, sondern dynamisch zugewiesen, z.B. durch 

verschiedene Zugangspunkte des Nutzers (Arbeitscomputer, Heimcomputer, Mobile 

unterwegs, ...). Zurzeit wird beim Registrieren eines Nutzers (mit Endgerät) auf einem 

Server die IP-Adresse unter einen ausgewählten Nutzernamen gespeichert. Über diesen 

Nutzernamen kann dann ein Gespräch zum gewünschten Teilnehmer aufgebaut werden. 

Es können zur Sprachübertragung verschiedene Codecs verwendet werden. Die Co- 

decs unterscheiden sich durch unterschiedliche Komprimierung und somit in der ver- 

wendeten Bandbreite und der Sprachqualität. Je weniger Bandbreite vorhanden ist, 

bzw. genutzt wird, desto schlechter wird die Sprachqualität. Die Codecs können von 

Nutzer meist selbst, seiner Verbindung entsprechend, eingestellt werden. 

Zur Übertragung der Daten wird UDP (2.2.5) verwendet, da es keinen Sinn macht 

Pakete erneut zu übertragen. Da die empfangenen Pakete sofort an den Nutzer weiter- 

geleitet werden, um eine ”fließende Sprache” zu erreichen, würden wiederholte Pakete 

zu Störungen führen und keinerlei Information für den Nutzer beinhalten. 

Anwendungen 

Die Server, auf denen die IP-Adresse unter einem Nutzernamen gespeichert ist, zählt 

als Dienstleistung, die z.B. von Skype angeboten wird. Auch ist es mittlerweile möglich 

aus dem klassischen Festnetz die VoIP-Teilnehmer zu erreichen. Möglich ist dies durch 

die Vergabe von Ortsrufnummern an die VoIP-Teilnehmer. [Bada06] 

2.2.9 Videostreaming 

Videostreaming, auch als Streaming Video bekannt, bezeichnet das gleichzeitige Emp- 

fangen und Wiedergeben einer Videodatei. Diese Form der Dienstleistung ähnelt bei- 

spielsweise dem Fernsehen und dem Radio als Broadcast-Technologien. [Aust04] 



Werden aktuelle Sendungen im Fernsehen über einen Videostreaming auf den Com- 

puter übertragen und wiedergegeben, spricht man von einem Direktstrom (engl. Live- 

stream). 


Wie auch VoIP verwendet Videostreaming UDP. Für die Wiedergabe von Videostre- 

ams wird eine entsprechende Software benötigt (z.B. Real Networks Player). Da die 

Daten im Internet verschiedenen Einflüssen, wie z.B. Laufzeitschwankungen, unterlie- 

gen, muss die Software ankommende Pakete vor der Wiedergabe puffern, um so eine 

unterbrechungsfreie Wiedergabe zu ermöglichen. Dadurch entsteht eine typische Ver- 

zögerung bei der Wiedergabe von einigen Sekunden. 

Zwingend notwendig ist es, dass die Kodierung des Videos unterhalb der verfügbaren 

Bandbreite des Netzes liegt, so dass Daten mindestens genauso schnell Empfangen wie 

wiedergegeben werden können. Typischerweise hängt die empfangene Ton- und Bild- 

qualität von der Qualität des Ausgangsmaterials, der Kodierung und der verfügbaren 

Bandbreite ab. 

Anwendungen 

Neben den bereits erwähnten ”Real Networks Player”, stehen auch andere Programme 

zur Verfügung, welche sich meist durch die unterschiedliche Kodierung auszeichnen. 

Videostreaming findet bei dem ”WebTV” eine Anwendung, bei welcher Fernsehpro- 

gramme live ins Internet übertragen werden. 

2.3 QoS - Quality of Service (nach 3GPP 22.959) 

QoS bezeichnet eine vereinbarte Güte von Diensten. Diese wird durch verschiedene Pa- 

rameter festgelegt, welche sich je nach verwendeten Kommunikationsstandard ändern 

können. QoS-Daten werden immer gesammelt und ausgewertet. QoS soll hier nur für 

IP-basierte Netze erläutert werden. [Scha03] 

2.3.1 QoS in IP-basierten Netzen 

Neben zusätzlichen Parametern für das IP-basierte Netz werden auch QoS-Parameter, 

welche für leitungsvermittelten Verkehr verwendet werden, genutzt (Falschverbindung, 

Blockierung, Verbindungsabbruch). 



QoS-Parameter in IP-basierten Netzen 

Die folgenden Parameter werden bei unterschiedlichen Diensten anders gewichtet, so 

wird z.B. bei Nicht-Echtzeitanwendungen der Durchsatz der entscheidende Parameter 

sein und der Jitter keine große Rolle spielen. 

• Latenz: die Verzögerung einer Ende-zu-Ende Übertragung 

• Jitter: die Schwankung der Latenz 

• Verlustrate: die Wahrscheinlichkeit für den Verlust von Datenpaketen 

• Durchsatz: übertragene Daten gemittelt über eine Zeiteinheit (meist Sekunde) 

Bei Echtzeitanwendungen liegt die Priorität auf der Latenz, dem Jitter und der 

Verlustrate, da diese maßgeblich die Sprach- und / oder Videoqualität beeinflussen. 

2.3.2 Realisierung in IP-basierten Netzen 

Um QoS zu gewährleisten, kann theoretisch eine 

• Priorisierung der Datenpakete 

• Bandbreitenreservierung 

• Bandbreitenlimitierung 

• Paketoptimierung 

vorgenommen werden. Praktisch gesehen existieren nur wenige technische Möglichkei- 

ten um, QoS zu gewährleisten. 

• Anmeldung anstehender Datenflüsse bei allen aktiven Netzwerkkomponenten 

(Router etc.). Damit ist es möglich eine gewisse Bandbreite zu reservieren. 

• Priorisierung von Datenpaketen, so dass Pakete mit hoher Priorisierung bevor- 

zugt werden. 

Die Priorisierung von Paketen kann in Mobilfunknetzen vom Netzbetreiber festgelegt 

werden. So können Kunden mit höheren Monatsumsatz höher eingestuft werden und 

so einer besseren QoS unterliegen. 



2.4 UMTS - Universal Mobile Telecommunication 

System - Grundlagen 

Abbildung 2.4: UMTS Netzaufbau 

In Abbildung 2.4 ist der grundsätzliche strukturelle Aufbau eines UMTS-Netzes zu 

sehen, beginnend vom User Equipment (UE) bis hin zum Core Network. Betrachtet 

wird das Netz zunächst abstrakt. Die User Equipment Domain beinhaltet das UE 

inklusive USIM. Die Access Network Domain beinhaltet das UMTS Terrestrial Radio 

Access Network (UTRAN) und die Core Network Domain das Core Network. [Lesc02] 

2.4.1 UTRAN - UMTS Terrestrial Radio Access Network 

Abbildung 2.5: UTRAN 



Das UTRAN [Abb. 2.5] bestehend aus Radio Network Controller (RNC) und no- 

deB bildet zusammen mit dem UE den Funknetzteil des UMTS-Netzes. Das UTRAN 

muss die Funkverbindung mit dem UE herstellen und Daten mit dem Core Network 

austauschen. Des Weiteren soll das UTRAN das Handling von paketorientierten und 

leitungsorientierten Datendiensten optimieren. ATM-Links sind die Transportmecha- 

nismen der Iub-, Iur- und Iu-Schnittstelle, also zwischen den einzelnen Komponenten 

des UTRAN. [Sieg97] 

nodeB: 

Ein nodeB besteht aus einer Zelle (Pico, Makro), in der sich das UE aufhält und ist 

mit der Base Transceiver Station (BTS) von GSM vergleichbar. Abgesehen davon, dass 

UMTS andere Frequenzen und Verschlüsselungen benutzt, können die UMTS-Zellen 

ihre Größe verändern. Dies geschieht abhängig von der aktuellen Verkehrslast, je mehr 

Nutzer in einer Zelle sind umso kleiner wird diese. Die nodeB kommunizieren über die 

Iub-Schnittstelle mit einem RNC. Zu den Aufgaben des nodeB gehören: 

• Kanalkodierung 

• Interleaving 

• Ratenanpassung 

• Kodierung und Dekodierung mit zugewiesenen Spreizfaktor 

• Kodierung mit Scrambling Code (SC) 

• Modulation auf HF-Trägerfrequenz oder Demodulation 

RNC - Radio Network Controller: 

Im RNC laufen alle Informationen angeschlossener nodeBs zusammen. In der ursprüng- 

lichen UMTS-Architektur (R99) werden hier, zwischen RNC und UE, Qualitätsrück- 

schlüsse (engl. quality feedback) gezogen und die Zellgröße des nodeBs angepasst. In 

neueren Architekturen, wird dieser Mechanismus in den nodeB verlegt, um schnellere 

Zellgrößenveränderungen zu erreichen. Die Aufgaben des RNC umfassen: 

• Regelung der Sendeleistung aller Funkverbindungen von allen angeschlossenen 

nodeBs 

• Zuweisung und Verwaltung der Codes für die Kanäle 



• Terminierung des Radio Resource Control (RRC)-Protokolls 

• Admission Control (Vermeidung von Überlastsituationen) 

• Congestion Control (Stabilität bei Überlastsituation) 

• Ausführung der Funktionen des Serving-RNC, Drift-RNC und Control-RNC 

• Makrodiversität / Handover 

RNCs können über die Iur-Schnittstelle untereinander kommunizieren und verlassen 

das UTRAN über die Iu-Schnittstelle. Es gibt zwei Arten von Iu-Schnittstellen: Iu- 

CS (leitungsvermittelt) ist die Verbindung der RNCs zum Mobile Service Switching 

Center (MSC) des GSM-Netzes und Iu-PS ist die Verbindung zum Serving GPRS 

Support Node (SGSN) des paketvermittelten Netzes, welches aus dem ursprünglichen 

General Packet Radio Service (GPRS)-Netz stammt. 

User Equipment (UE) 

Als UE wird all das bezeichnet, was sich am Ende einer Verbindungsstrecke befinden 

kann, also nicht nur Handys, sondern auch PCMCIA-Karte für den Laptop, UMTS- 

Karten für den Computer oder die Surf@HomeBox. Netztechnisch gesehen sitzt hinter 

dem UE noch das Universal Subscriber Identity Module (USIM) verbunden über die 

Gu-Schnittstelle. 

Das UE muss im Falle eines Verbindungswunsches diesen an die nächst höhere In- 

stanz senden (nodeB) und sich Ressourcen zuteilen lassen. Aufgaben des UE sind: 

• Open Loop Power Control bei Verbindungswunsch 

• Anmeldung in ein Netzwerk bei Anschalten des UEs 

• Kodierung und Dekodierung mit entsprechenden SC 

• Kodierung und Dekodierung mit Spreizfaktor 

Über die Luftschnittstelle (Uu) kommuniziert das UE mit dem nodeB über die RRC 

/ RLC Protokolle [Kap. 2.4.4]. Alle anderen Protokolle werden aufgesetzt. 



2.4.2 Core Network 

Das Core Network setzt sich aus dem bereits vorhandenen Strukturen des GSM- / 

GPRS-Netzes und neuen Strukturen für paketvermittelte Netze zusammen, da auch 

aus dem paketvermittelten Netz Telefonieren in das leitungsvermittelte Netz möglich 

sein soll. Das UMTS Core Network ist komplett als paketvermitteltes Netz aufgebaut 

[Abb. 2.6]. Die wichtigsten Komponenten des Core Networks sind: 

EIR - Equipment Information Register 

Abbildung 2.6: Core Network 

Das Equipment Information Register (EIR) ist die Einheit im GSM-Netz, welche für 

das Speichern der International Mobile Equipment Identities (IMEI) verantwortlich ist. 

Dieses Register enthält auch die ”Black List”, auf welcher IMEIs von Mobiles enthalten 

sind, welche gestohlen oder als unsicher eingestuft wurden. 

HLR - Home Location Register 

Im Home Location Register (HLR) werden zentral die wichtigsten, vom Nutzer selbst 

nicht veränderbaren Informationen der Nutzer gespeichert. Hier werden auch gebuchte 

Profile gespeichert (Anrufweiterleitung, gesperrte Dienste, usw.). Das HLR enthält 

zusätzlich einen Verweis auf das Visitor Location Register (VLR), in welchen ein UE 

sich aktuell aufhält oder zuletzt aufgehalten hat (sollte das UE abgeschaltet sein). 



VLR - Visitor Location Register 

Hier werden Informationen wie Location Area Identity (LAI), Temporary Mobile Sub- 

scriber Identity (TMSI), eine Kopie aller verfügbarer Dienste des Nutzers aus dem 

HLR und Sicherheitsdaten für Authentifizierung abgespeichert. Die Daten eines Nut- 

zers wandern mit dem UE mit und werden von VLR zu VLR übertragen. 

3G-SGSN - 3G-Serving GPRS Support Node 

Im 3G-SGSN laufen Mobility und Session Management ab, es stellt Authentifizie- 

rungsprozeduren und routet Daten mit Hilfe des GPRS Tunneling Protocol (GTP). 

Der 3G-SGSN kann aktuelle Standorte von Teilnehmern aus dem HLR anfordern. 

Daten können auch über SS7 to IP Gateway (SIG) geroutet werden, SIG ist die 

Schnittstelle zwischen den leitungsvermittelten Netzwerkkomponenten (verwenden Si- 

gnaling System 7 (SS7)) und den Komponenten im IP-Netzwerk. 

SGSN - Serving GPRS Support Node 

Der SGSN hat die Aufgabe ein geografisches Gebiet zu versorgen. Zu seinen Aufgaben 

gehören die Mobilität der paketvermittelten Teilnehmer und die Authentifizierung (Si- 

cherheit). Er speichert die aktuelle Position der Teilnehmer und leitet Informationen 

aus dem Internet weiter. Der SGSN ist auch für die Gebührenerfassung der internen 

Netzwerkressourcen zuständig, um die Teilnehmer entsprechend abzurechnen. 

AuC - Authentication Center 

Das Authentication Center (AuC) speichert alle Mobilteilnehmer, so kann die Inter- 

national Mobile Subscriber Identity (IMSI) überprüft werden und verschlüsselt über 

die Uu-Schnittstelle kommuniziert werden. Die Daten zur Authentifizierung und Ver- 

schlüsselung werden über das HLR zum VLR, MSC und SGSN übertragen. 

GGSN - Gateway GPRS Support Node 

Der Gateway GPRS Support Node (GGSN) ist der paketvermittelte Knoten, welcher 

die Übergänge in externe Datennetze realisiert. Pakete aus dem Internet werden hier 

in Container (PDUs) gepackt und so durch das Core Network getunnelt. 

Andere Komponenten des Core Networks sind nicht speziell für das Mobilfunknetz 

definiert (Dynamic Host Configuration Protocol (DHCP), Domain Name System DNS 



etc.) und können in entsprechender Literatur nachgelesen werden. [Schä02] [Liu03] 

2.4.3 Kanäle in UMTS 

In Abbildung 2.7 sind die ver- 

schiedenen Zustände zu sehen, 

in denen sich ein UE befinden 

kann, wenn es mit dem UTRAN 

auf RRC-Ebene verbunden ist 

(UMTS Terrestrial Radio Access 

(UTRA) RRC Connected Zu- 

stand). Die verschiedenen Kanä- 

le wurden eingeführt, um für die 

verschiedenen Zustände der UEs 

die verfügbaren Ressourcen bes- 

ser auszunutzen. So kann ein UE 

welches einen Download (z.B. 

Webseite) bereits getätigt hat, 

in einen Zustand wechseln, in 

dem es die Ressource für den 

Download nicht belegt, aber sie 

jederzeit schnell wieder zurück- 

Abbildung 2.7: UTRA RRC Zustände 

bekommt, sollte es diese brauchen. Im Folgendem sollen die verwendeten Kanäle be- 

schrieben werden. 

Idle Zustand 

Das UE hält sich in einer Zelle auf und ist in dem Netzwerk registriert. Das UE nutzt 

soweit keine Ressourcen. Wenn nun der Nutzer eine Datei aus dem Internet oder eine 

Webseite herunterladen will, wird eine RRC-Verbindung zwischen dem UE und dem 

RNC aufgebaut. Das UE wechselt in den Zustand CELL DCH. 

Dedicated Channel (DCH) 

Der DCH ist ein dedizierter physischer Kanal für den Up- und Downlink, der dem UE 

im Zustand CELL DCH zugewiesen wird. Das UE wechselt damit in einen aktiven 

Zustand [Kapitel 2.5.2] und der Standort des UEs ist nun auf Zellebene bekannt. Das 



UE kann hier rein dedizierte Transportkanäle, geteilte Transportkanäle im Up- und 

Downlink oder eine Kombination dieser Transportkanäle nutzen. 

Forward Access Channel (FACH) 

Im CELL FACH Zustand ist dem UE kein physischer Kanal zugewiesen. Das UE be- 

obachtet den FACH ununterbrochen im Downlink. Im Uplink kann dem UE ein ein- 

facher oder geteilter Transport Kanal (z.B. Random Access Channel (RACH)) zuge- 

wiesen werden. Dieser kann vom UE jederzeit, abhängig vom Zugriffsverfahren des 

jeweiligen Kanals, genutzt werden. Die Position des UEs ist auf UTRAN-Ebene be- 

kannt, ausgehend von der letzen Zelle in der sich das UE aufgehalten hat. 

Paging Channel (PCH) 

Das UE kann sich in zwei Zuständen befinden (CELL PCH oder URA PCH), in wel- 

chem es den PCH, mit Hilfe des zugewiesenen Paging Indicator Channel (PICH), 

beobachtet. 

CELL PCH 

In diesen Zustand ist dem UE wieder kein physischer Kanal zugewiesen. Eine Aktivität 

im Uplink ist nicht möglich. Die Position des UEs ist auf Zell-Ebene bekannt, ausgehend 

von der letzten Zelle, in welcher sich das UE im CELL FACH Zustand befand. 

URA PCH 

Wie im CELL PCH ist auch hier dem UE kein physischer Kanal zugewiesen. Der 

Unterschied zum CELL PCH besteht darin, dass die Position des UE, nur noch auf 

UTRAN-Ebene bekannt ist, ausgehend von dem letzen UTRAN Registration Area 

(URA) Update im CELL FACH Zustand. 

2.4.4 Protokollmodell 

Der Überblick über die Protokollarchitektur [Abb. 2.8] stellt nur den paketvermittelten 

Teil des Netzes dar. Auf die Architektur des leitungsvermittelten Teil wird an dieser 

Stelle nicht eingegangen. 

Aufgrund der Komplexität des UMTS-Netzes ist es verständlicher die komplette 

Architektur, so wie dargestellt, nicht im Zusammenhang zu betrachten, sondern die 

Architektur aufgabenspezifisch zu trennen. So wird nach Control-, User-, Transport- 



Abbildung 2.8: UMTS Architektur (Paketvermittlung) 

und Common Plain aufgeteilt. Beinahe jede Schnittstelle hat ein eigenes Protokollm- 

odell. 

Betrachtet man das Protokollmodell, lässt sich erkennen, dass zwei offenbar verschie- 

dene IP-Protokolle verwendet werden. Es handelt sich aber um das gleiche Protokoll. 

Das Protokoll, welches auf einer höheren Schicht liegt, wird verpackt und durch das 

UMTS-Netz ”getunnelt”. Dies geschieht durch das GTP Protokoll. Das unterhalb lie- 

gende IP-Protokoll wird für den Transport und Adressierung innerhalb des UMTS- 

Netzes genutzt. Das GTU-P Protokoll läuft bis zum nodeB, wo dann entsprechende 

Protokolle der Funkschnittstelle übernehmen und eine Verpackung der IP-Adresse nicht 

mehr nötig ist. [Tech02] 

Radio Link Control (RLC) 

Schicht 2, direkt über der physischen Schicht, wird aufgeteilt in RLC und Medium 

Access Control (MAC). Die Schicht ist für die Wahl der Transport Formates zuständig 

(Übertragungsgeschwindigkeit, Kanalkodierung, etc.). 

RLC kann in zwei Arten verwendet werden: Acknowledge Mode (AM) und Unack- 

nowledge Mode (UM). 



RLC Unacknowledge & Acknowledge Mode 

Funktionen Unacknowledge & Acknowledge Mode: 

• Segmentierung und Zusammenfügen: Mit dieser Funktion werden die PDUs 

mit variabler Länge in kleine PU unterteilt. Diese werden auch als RLC-PDU 

bezeichnet. Im Umkehrschluss werden die PUs am Empfänger wieder zu PDUs 

zusammengesetzt. 

• Padding: Sollte eine PU nicht der Standardgröße entsprechen, da keine weiteren, 

zu übertragenen PDUs vorhanden sind, werden mit dieser Funktion Nullen an 

die PU angehängt. 

• Transport von Nutzdaten: Übertragung der Nutzdaten zwischen RLC-Diensten. 

• Vielfach-Detektion: Sollte eine PU durch Reflektionen oder Streuung mehrfach 

empfangen werden, soll dies detektiert werden. So soll sichergestellt werden, dass 

keine doppelten PDUs an die nächsthöhere Schicht geliefert werden. 

• Flusskontrolle: Erlaubt dem RLC-Empfänger den Durchsatz für gesendete Da- 

ten vom RLC-Sender zu regulieren. So sollen Lastsituationen verhindert werden. 

• Protokoll für Fehlererkennung und -korrektur: Erkennt Fehler bei der Aus- 

führung des RLC-Protokolls und korrigiert diese. 

• Verschlüsselung: Verschlüsselung wird zur Vermeidung unautorisierter Zugriffe 

auf Daten genutzt. Diese Funktion kann gewählt werden. 

• Aussetzen und Wiederaufnahme: Mit dieser Funktion kann die Datenüber- 

tragung ausgesetzt und wieder aufgenommen werden. 

Nur im Acknowledge Mode: 

• Fehlerkorrektur: Fehlerkorrektur durch Übertragungswiederholungen fehler- 

hafter oder gescheiterter Übertragungen. 

• Reihenfolge der PDUs: Nach dem Zusammenfügen der PUs zu PDUs, soll die 

richtige Reihenfolge beim Übergeben an die höhere Schicht beachtet werden. 

Nur im Unacknowledge Mode: 

• Kontrolle der Sequenznummern: Diese Funktion garantiert die Integrität 

der zusammengefügten PDUs und bietet eine Fehlererkennung. 



Radio Resource Control (RRC) 

RRC kontrolliert die Funkressourcen und reagiert mit Hilfe der physischen Schicht auf 

Veränderungen. RRC kann verschiedene Parameter der physischen Schicht anpassen, 

z.B. Kodierungsparameter des Kanals. Umgekehrt kann die physische Schicht auch 

Informationen an das RRC-Protokoll senden, umso schnell auf evtl. Verschlechterung 

der Funkverhältnisse zu reagieren. 

2.4.5 QoS-Architektur 

Dienste in einem Netzwerk sind Ende-zu-Ende Dienste, von einem Terminal Equipment 

(TE) zu einem anderen TE. Ein Ende-zu-Ende Dienst kann eine bestimmte QoS, für 

den Nutzer des Dienstes, anbieten. Der Nutzer entscheidet, ob er mit der angebotenen 

QoS zufrieden ist. 

Um in einem Netzwerk eine bestimmte QoS zu realisieren, wird ein Trägerdienst (zu 

engl. Bearer Service) benötigt, welcher klar definierte Eigenschaften und Funktionen 

eines Quell-Ziel-Dienstes besitzt. 

Um eine vereinbarte QoS zu erreichen, werden noch QoS-Klassen verwendet, welche 

die Übertragung beeinflussen. 

QoS-Klassen 

Für QoS in Mobilfunknetzen sind vier QoS-Klassen definiert worden. Für jede dieser 

Klassen sind andere QoS-Parameter wichtig, welche für diese Klassen repräsentativ 

sind. 

• Conversational für Sprachübertragung, Kommunikation (Telefonie). Da hier 

die Sprache direkt übertragen wird, liegt der Schwerpunkt auf geringer Latenz 

und geringem Jitter. Ansonsten kann es für Menschen zu Problemen beim Ver- 

stehen der übertragenen Sprache kommen. 

• Streaming für Dienste die mehrere Ziele haben. Der Schwerpunkt liegt hierbei 

auf der verfügbaren Bandbreite im Verhältnis zur Übertragungsgeschwindigkeit 

des Streams. Latenz und Jitter sind hierbei eher unkritisch, da am Empfänger, 

vor einer Wiedergabe, gepuffert wird. 

• Interactive für die Nutzung interaktiver Dienste. Die Schwerpunkte liegen hier 

ähnlich wie bei Background, allerdings bestehen höherer Anforderungen an die 

Latenz. So sollen Wartezeiten für die Dienstnutzung verhindert werden. 



• Background für Anwendungen im Hintergrund mit unkritischen Anforderun- 

gen. Legt wert auf geringe Fehlerrate und ist größtenteils unabhängig von Latenz, 

Jitter und Bandbreite. 

Die QoS-Parameter werden vom Netzbetreiber im Access Point Name (APN) festge- 

legt. Die Nutzer können dann, über die verschiedenen APNs, die gewünschte QoS- 

Klasse bekommen. Die Nutzung einer bestimmten QoS-Klasse als Dienst, muss für die 

USIM im HLR gespeichert sein. 

QoS-Ende-zu-Ende-Dienst 

Abbildung 2.9: UMTS QoS-Architektur 

In Abb. 2.9 wird der Aufbau der Trägerdienste dargestellt. Die Trägerdienste bauen 

auf die darunterliegende Trägerdienste auf. 

Die QoS für den Nutzer wird vom UMTS Bearer Service gestellt, welcher aus den 

Radio Access Bearer Service (RAB) und dem Core Network Bearer Service besteht. Die 

Aufteilung bietet die Möglichkeit, den UMTS Bearer Service für die unterschiedlichen 

Netztopologien (UTRAN, Core Network) zu optimieren. 



Radio Access Bearer (RAB) 

Der RAB bietet den Dienst an Daten (Nutz- und Signalisierungsdaten) vom UE zum 

Core Network zu übertragen. Dieser Dienst basiert auf Eigenschaften der Funkschnitt- 

stelle und ist für ein mobiles UE ausgelegt. 

Der RAB wiederum besteht aus einem Radio Bearer (RB) und einem RAN Access 

Bearer (RANAB), welche aus Sicht des RAB einen Dienst darstellen. 

Im RB ist der Transport von Daten über die Funkschnittstelle beschrieben. Unter 

dem RB befindet sich nur noch der Dienst zur physischen Übertragung der Daten über 

den Funkkanal. 

Core Network Bearer 

Dieser Dienst verbindet das Core Network (Iu-Schnittstelle) mit dem Core Network 

Gateway (Verbindung mit externen Netzen). Der Core Network Bearer soll das Core 

Network effizient kontrollieren und benutzen, um den vereinbarten UMTS Radio Bearer 

zu stellen. Das paketvermittelte Core Network bietet unterschiedliche Dienste, für die 

verschiedenen QoS-Anforderungen an. 

2.5 PDP - Packet Data Protocol 

Das Packet Data Protocol (PDP) wurde schon für GPRS im GSM-Netz verwendet und 

wurde in das UMTS-Netz übernommen. Die PDP-Adressen werden durch eine oder 

mehrere PDP-Kontexte im Mobile, im SGSN und im GGSN beschrieben. Die PDP- 

Kontexte können sich von einander unabhängig in einen von zwei Zuständen befinden 

(”INACTIVE”, Kap. [2.5.1] oder ”ACTIVE”, Kap. [2.5.2]). Der PDP-Kontext gibt an 

ob für eine bestimmte PDP-Adresse die Datenübertragung erlaubt ist oder nicht. Die 

Aktivierung und Deaktivierung des PDP-Kontextes kann unter Kap. 2.5.3 nachgelesen 

werden. 

2.5.1 Inaktiver Zustand (”INACTIVE”) 

Der inaktive Zustand [Abb. 2.10] beschreibt, dass die Datendienste für eine PDP- 

Adresse des Nutzers nicht aktiviert sind. In diesem Zustand enthält der PDP-Kontext 

keine Informationen über das Routing und Mapping von PDP-PDUs, welche zur PDP- 

Adresse des Nutzers gehören. Somit können keine Daten übertragen werden. Sollte ei- 

ne PDP-PDU an einen inaktiven Nutzer geschickt werden, gibt es zwei Möglichkeiten. 



Entweder der GGSN initiiert die netzseitige PDP-Kontext-Aktivierung für die PDP- 

Adresse des Nutzers oder die PDP-PDU wird an den Sender mit einer Fehlermeldung 

zurückgeschickt. Für die netzseitige Initiierung muss der GGSN die Berechtigung ha- 

ben. 

Möchte der Nutzer Daten versenden, startet das Mobile, mit Hilfe der PDP-Kontext- 

Aktivierung [Kap. 2.5.3], den Wechsel aus dem inaktiven in den aktiven Zustand. 

2.5.2 Aktiver Zustand (”ACTIVE”) 

Im aktiven Zustand [Abb. 

2.10] ist der PDP-Kontext für 

die PDP-Adresse des Nutzers 

im Mobile, SGSN und GGSN 

aktiviert. Der PDP-Kontext 

beinhaltet jetzt Informationen 

zum Routing und Mapping 

für die Übertragung von PDP- 

PDUs für die PDP-Adresse 

zwischen Mobile und GGSN. 

Der RAB muss für einen ak- 

tiven PDP-Kontext nicht ver- 

fügbar sein. Durch die PDP- 

Kontext-Deaktivierung [Kap. 

2.5.3] geschieht der Wechsel 

vom aktiven in den inaktiven Modus. 

Abbildung 2.10: PDU-Kontext Zustände 

2.5.3 PDP-Kontext-Aktivierung und -Deaktivierung 

PDP-Kontext-Aktivierung 

Der Ablauf der Aktivierung des PDP-Kontextes ist in Abb. 2.11 dargestellt. Als erstes 

wird vom Mobile aus eine Anforderung zur PDP-Kontext-Aktivierung an den SGSN 

geschickt (1). Der SGSN sendet daraufhin eine Anforderung an den GGSN den PDP- 

Kontext zu erstellen (2). Der GGSN erstellt einen neuen Eintrag in der PDP-Kontext- 

Tabelle. Der Eintrag erlaubt es dem GGSN PDP-PDUs zwischen dem SGSN und einen 

externen PDP-Netzwerk zu routen (2). Anschließend wird auf der Iu-Schnittstelle der 

RAB festgelegt (3). Der nächste Schritt ist optional, hierbei können über die Anfor- 



Abbildung 2.11: PDP-Kontext-Aktivierung 

derung eines Updates des PDP-Kontextes (4), z.b. veränderte QoS-Attribute an den 

GGSN übermitteln werden. Dem GGSN werden diese Änderungen mitgeteilt und vom 

SGSN bestätigt (5). Der SGSN fügt alle Informationen über Einstellungen, zusam- 

men mit der GGSN Adresse und dem Network Service Access Point Identifier (NSA- 

PI), in den PDP-Kontext ein. Des Weiteren werden zusätzliche Parameter hinzugefügt 

(z.B. Funkprioritäten), danach wird eine Bestätigung über die Aktivierung des PDP- 

Kontextes an das Mobile gesendet (6). Der SGSN ist nun in der Lage PDP-PDUs 

zwischen GGSN und Mobile zu routen. 

C1 und C2 sind Prozeduren die über das Abweisen oder das Akzeptieren des PDP- 

Kontext-Aufbaus entscheiden, nachzulesen in [3GPP03]. 

PDP-Kontext-Deaktivierung 

Bei der PDP-Kontext-Deaktivierung [Abb. 2.12] sendet das Mobile eine Anforderung, 

den PDP-Kontext zu deaktivieren, an den SGSN (1). Der SGSN teilt dem GGSN mit, 

dass er den Eintrag für das entsprechende Mobile aus seiner PDP-Kontext-Tabelle 

löschen soll (2). Der GGSN bestätigt die Löschung an den SGSN. Der SGSN bestätigt 

dem Mobile die Deaktivierung des PDP-Kontextes (3). Wenn zur der Zeit ein RAB für 

den PDP-Kontext existiert, würde dieser aufgelöst (4). 

Die PDP-Kontext-Deaktivierung kann auch vom SGSN oder vom GGSN angefordert 



Abbildung 2.12: PDP-Kontext-Deaktivierung 

werden, falls die Voraussetzungen (z.B. inaktives Mobile) dafür erfüllt sind. 

2.5.4 APN - Access Point Name 

Bei dem Aufbau eines PDP-Kontextes, muss ein APN gewählt werden. Der APN gibt 

an, mit welchem Netzwerk eine Verbindung hergestellt werden kann und die Einstel- 

lungen, welche für die Verbindung genutzt werden sollen. 

Der APN wird dann in einer DNS-Anfrage an das Netzwerk gesendet. Aus diesen 

Prozess, APN-Auflösung genannt, wird die IP-Adresse dem GGSN zurückgegeben, wel- 

chen der APN als Server nutzt. Nach dieser Prozedur kann der PDP-Kontext aktiviert 

werden. 

2.6 Momentansituation UMTS-Netz O2(Germany) 

Grundsätzlich ist das O2(Germany)-Netz nach dem Standard für UMTS-Netze aufge- 

baut. Es gibt einige interne spezifische Erweiterungen, die das Protokollmodell betref- 

fen, so muss zum Beispiel das Roaming zu T-Mobile speziell geregelt werden. 

O2(Germany) nutzt Nortel- und Nokia-Equipment. Das gesamte Backbone Core Net- 

work besteht aus Nortel Hardware. Das UTRAN besteht zum einen Teil aus Nokia- 

Hardware (Region West und Nord) und zum anderen Teil aus Nortel-Hardware (Region 

Ost und Süd) [Abb. 2.13]. Die Regionen sind somit auch unterschiedlich parametrisiert. 



Abbildung 2.13: Nortel und Nokia in den Regionen 

Aktuelle Ressourcenauslastung 

Um die aktuelle Leistungsfähigkeit des O2(Germany)-Netzes hinsichtlich des paketver- 

mittelten Verkehrs im UMTS-Netz abzuschätzen, müssen verschiedene Verallgemei- 

nerungen getroffen werden: Die Verkehrslast verteilt sich nicht gleichmäßig über das 

gesamte UMTS-Netz, sondern ist oft in Ballungszentren konzentriert, hier soll aber von 

einer gleichmäßigen Netzlast ausgegangen werden. Bei der Berechnung wird weiterhin 

angenommen, dass eine Durchnittskapazität von 500 kbit/s in den Zellen verfügbar 

ist, um die geplante Zellkapazität von O2(Germany) für die Kunden zu erreichen. Ver- 

gleicht man die aktuellen Juni-2006-Werte des paketvermittelten Verkehrs mit dem 

theoretischen Maximum (500 kbit/s mal Anzahl der vorhandenen Zellen), so beträgt 

die aktuelle Auslastung circa 5,8%. Somit ist eine potenziell verfügbare Leistungs- 

fähigkeit im UMTS-Netz von 94,2% ungenutzt. Betrachtet man die Datenrate pro 

Nutzer im Zusammenhang mit Anforderungen seitens verschiedener Anwendungen, 

stellt sich heraus, dass bei Nicht-Echtzeitanwendungen (FTP, HTTP) keine Probleme 

auftreten, da die benötigten Datenraten seitens der Anwendungen verfügbar sind. Bei 

Echtzeitanwendungen (Skype) entstehen auch keine Probleme, da die durchschnittliche 



Datenrate mit 20-50 kbit/s unter der verfügbaren Ressource liegt. Bei Videostreaming- 

Echtzeitanwendungen wird empfohlen die Streams von einem WAP-Portal zu downloa- 

den, da dort die Streams in angepasster Datenrate vorliegen. Bei den Streams aus dem 

Internet, welche eventuell mit höherer Datenrate senden, als dem UMTS-Benutzer zur 

Verfügung steht, wird ein unterbrechungsfreies Video nicht möglich sein. 

2.7 High Speed Downlink Packet Access (HSDPA) 

Abbildung 2.14: UMTS UTRAN Architektur für HSDPA [UMTS06] 

Das zurzeit verwendete UMTS-Release99 hat bei der Paketvermittlung drei große 

Probleme. Das erste Problem ist die langsame Anpassung der Datenrate an die Ge- 

gebenheiten der Funkschnittstelle (Funkverhältnisse); im Gegensatz zur schnellen An- 

passung des ”Power Control”. Auch die Granularität der verfügbaren Datenraten ist 

nicht ausreichend. 

Des Weiteren werden Teilnehmer zu langsam gescheduled. Werden sie inaktiv, wer- 

den Ressourcen erst nach einigen Sekunden frei gegeben. Auch dauert es eine gewisse 

Zeit, bis man diese Ressource wieder zur Verfügung gestellt bekommt, wenn man wieder 

aktiv wird. 

Durch die Verzögerung auf der Funkschnittstelle und protokollbedingte, wiederholte 

Übertragungen ergeben sich schlechte Übertragungen von kleinen Datenpaketen. 

Mit HSDPA sollen die Probleme deutlich verringert werden. Adaptive Modulation 

and Coding (AMC) soll zu schnellerer Datenratenadaption führen, ”Fast Scheduling” 

soll die Ressourcenverwaltung schneller machen, während mit Hilfe des Hybrid Auto- 

matic Request (HARQ) die Übertragungswiederholungen schneller übertragen werden 

sollen. 

In Abbildung 2.14 ist die UMTS Architektur zu sehen, wie sie mit HSDPA eingesetzt 

wird. [Holm06] 



AMC - Adaptive Modulation and Coding 

Im Downlink wird es einen neuen physikalischen Kanal geben, den High Speed Phy- 

sical Downlink Shared Channel (HS-PDSCH), welcher für die Datenübertragung aller 

HSDPA-Daten von Teilnehmern in einer Zelle genutzt wird. Mit Hilfe von AMC wird 

es möglich sein, die Modulation dynamisch den Funkverhältnissen anzupassen. Dies 

geschieht mit folgenden Parametern: 

• Auswahl der Modulation (Quadrature Phase Shift Keying (QPSK) oder 16 Qua- 

drature Amplitude Modulation (16-QAM)) 

• Zuweisung von 5, 10 oder 15 Kodes (SF = 16) 

• Auswahl der Transportblockgröße / Kodierungsrate 

Die Entscheidung ist abhängig von der aktuellen Kanalqualität, welche von dem Mobile 

gemessen und via High Speed Dedicated Physical Control Channel (HS-DPCCH) zum 

nodeB gesendet wird. 

Fast Scheduling 

Fast Scheduling soll die Belegung der Funkressourcen durch mehrere Teilnehmer opti- 

mieren. So soll nach jedem Time Transmission Interval (TTI) von 2 Millisekunden ms 

entschieden werden, welcher User bedient wird. Dennoch ist es möglich mehrere User 

innerhalb eines TTI zu bedienen, da beispielsweise 10 Codes im HS-DPCCH verfügbar 

sind und somit zwei User mit jeweils fünf Codes bedient werden können. 

Ein weiterer Kanal, High Speed Shared Control Channel (HS-SCCH) wird einge- 

führt um dem Teilnehmer zu signalisieren, dass Daten für ihn über den HS-PDSCH 

übertragen werden können. 

HARQ - Hybrid Automatic Request 

HARQ ist eine Weiterentwicklung des normales ARQ und bietet, speziell für drahtlose 

Kanäle, eine bessere Performance. Erreicht wird dies durch eine höhere Komplexität 

durch Fehlererkennung und fehlerkorrigierende Kodes (z.B. Turbo Kodes) 

Übertragungswiederholungen werden nun vom nodeB aus überwacht und durchge- 

führt, statt wie beim Release99 im RNC. Dadurch sollen die Übertragungswiederholun- 

gen schneller durchgeführt werden, da die RTT für diesen Kreislauf der Überwachung 

sinkt. 



HSDPA im O2(Germany)-Netz 

Zurzeit sind Dienste (z.B. TV-Stream) über HSDPA im Netz von O2(Germany) nicht 

möglich. Anfang des Jahres 2006 gab es reine Funktionalitätstests mit HSDPA, da- 

für wurden spezielle Zellen für HSDPA (4-QPSK) freigeschaltet. Diese waren nicht 

für die Kunden von O2(Germany) verfügbar, sondern wurden ausschließlich für Tests 

verwendet. Anfang des Jahres 2007 soll die Erweiterung für UMTS für Kunden von 

O2(Germany) in Deutschland zur Verfügung stehen. Für diese Arbeit gab es keine 

Möglichkeit Messung in HSDPA-Netzen durchzuführen, da HSDPA erst im Jahr 2007 

implementiert werden soll. 

Zur Zeit ist es als O2(Germany) Kunde möglich, über T-Mobile-Roaming HSDPA 

zu nutzen. 



3 Testumgebungen für 

paketvermittelte Dienste in UMTS 

Nachdem die Momentansituation des O2(Germany)-Netzes analysiert wurde, sollen 

nun Testmessungen zur Verifikation des aktuellen Zustandes durchgeführt werden. 

Hierbei kann aus Gründen der zur Verfügung stehenden Hilfsmittel nur die Uu-Schnitt- 

stelle gemessen werden. Im Weiteren soll der Messaufbau und die verwendeten Hilfs- 

mittel (Hardware und Software) erläutert werden, auch werden die zu messenden Kri- 

terien diskutiert. Anschließend werden die Messungen durchgeführt und die Ergebnisse 

analysiert. 

Mit Hilfe dieser Messungen soll vorhandenes Optimierungspotenzial eingeschätzt 

werden, um so Ansätze in Kapitel 4 entwickeln zu können. 

3.1 Optimierungskriterien 

Bei der Optimierung von UMTS-Netzen allgemein und speziell paketvermittelten Dienst- 

en in UMTS-Netzen, werden bestimmte Parameter benötigt, welche den Wirkungsgrad 

einer Optimierung bestimmen. Diese Parameter sollen klar und einfach aufzeigen, ob 

die Optimierung den gewünschten Erfolg gebracht hat. 

3.1.1 Durchsatz 

Der Nutzer baut mit dem Mobile eine Verbindung zum Internet, über das Mobil- 

funknetz, auf. Anschließend will dieser eine Datei aus dem Internet herunterladen. 

Umso schneller diese Datei übertragen wird, desto zufriedener ist der Nutzer. Aus der 

Sicht des Netzes und des Betreibers stehen bei schnellerer Übertragung, benötigte Res- 

sourcen besser zur Verfügung. Somit ist der Hauptparameter für die paketvermittelten 

Dienste der Durchsatz. 

Der Durchsatz wird in kbit/s gemessen und gibt an, wieviele Daten innerhalb einer 

bestimmten Zeit übertragen werden. Je mehr Daten übertragen wurden, desto höher 



der Durchsatz. 

Der Durchsatz wird immer in Bezug zum maximalen Durchsatz (z.B. 384 kbit/s 

RAB) und zum Referenzdurchsatz genommen, um so das Optimierungspotential einer 

Änderung zu bestimmen. Bei Videostreams, welche mit konstanter Bitrate übertragen 

werden, wird diese Bitrate als maximaler Durchsatz verwendet. 

Der maximale Durchsatz, je nach Anwendung und RAB, minus dem Durchsatz der 

Referenzmessung, ergibt das Optimierungspotenzial: 

Optimierung (%) = 

Änderung (kbit/s) - Referenzmessung (kbit/s) 

384 (kbit/s) - Referenzmessung (kbit/s) 

∗ 100% 

Das Ergebnis in % ist ein Wert der den Grad der Optimierung, in Bezug zur Referenz- 

messung angibt. 

3.1.2 Übertragungsdauer 

Die Übertragungsdauer ist prinzipiell der Parameter, der den Nutzer erreicht, da diese 

direkt messbar ist. Die Übertragungsdauer resultiert primär aus dem Durchsatz. Sollten 

allerdings viele Übertragungswiederholungen auftreten, wird sich die Übertragungs- 

dauer entsprechend der Zeit, welche benötigt wird die verlorenen Pakete erneut zu 

übertragen, verzögern. 

Die Zeitdauer wird von zwei unterschiedlichen Standpunkten betrachtet und gemes- 

sen. Einmal die Zeit vom ersten bis zum letzen empfangenen Paket (Zeitdauer) und 

einmal die Zeit, welche komplett benötigt wird, also für den Aufbau der Verbindung, 

den Download und den Abbau der Verbindung (Sitzungszeit). 

Die Übertragungsdauer soll in ms gemessen werden. Je weniger Zeit für die Übertra- 

gung benötigt wird, umso besser ist die Qualität des Netzes. 

3.1.3 Anzahl an empfangenen Paketen 

Die Anzahl der empfangenen Pakete gibt Aufschluss über die Größe der Pakete. Je 

kleiner die Pakete im Schnitt sind, desto mehr Pakete müssen übertragen werden. 

Hinzu kommen die Pakete, die wiederholt übertragen werden müssen. Werden mehr 

Pakete als bei vergleichbaren Übertragungen empfangen, ist davon auszugehen, dass 

viele Übertragungswiederholungen aufgetreten sind. 



3.1.4 Übertragungswiederholungen 

Bei der Übertragung einer Datei können Übertragungswiederholungen der Pakete auf- 

treten. Sollten diese Wiederholungen zu oft auftreten, wird der effektive Durchsatz 

gesenkt, was zu einer langsameren Übertragung der Datei führt. Diese wiederholten 

Übertragungen kommen zustande, wenn z.B. ein Stau auf der Übertragungsstrecke 

auftritt und das Paket verworfen wird. In einem Mobilfunknetz kann ein Paket auch 

durch die Übertragung über die Uu-Schnittstelle verloren gehen. 

3.2 Messaufbau 

In Abbildung 3.1 ist der strukturel- 

le Aufbau der Messungen zu erkennen. 

Das verwendete UE wird an einen Lap- 

top per Datenkabel angeschlossen. Das 

Mobile kann über die Uu-Schnittstelle 

und das UMTS-Netzwerk eine Daten- 

fernübertragung (DFÜ)-Verbindung auf- 

bauen und hat somit Zugriff auf das In- 

ternet (WWW). Da die Messdaten zur 

Auswertung vom Mobile selber gemes- 

sen werden, ist es damit auch nur mög- 

lich, die Uu-Schnittstelle zu erfassen. 

3.2.1 Verwendete Hardware 

Laptop - Acer Travelmate C300 

Abbildung 3.1: Messaufbau 

Als Messstation für die gesamten Messungen wird ein Acer Laptop genommen: 

Technische Daten: 

• TravelMate C301XCi 

• Intel Pentium M 1,5 GHz 

• Intel 855GME Chipsatz 

• 512MB DDR SDRAM 



• Betriebssystem: Windows XP Service Pack 2 

Auf diesem System wird die gesamte Mess- und Analysesoftware installiert, somit auch 

die Treiber für das Nokia Mobile. Dass alle Messungen auf diesen System durchgeführt 

werden sollen, ist in soweit wichtig, als dass der verwendete Rechner für Ethereal, bei 

allen Downloads, die gleiche Performance aufbieten sollen, um nutzbare Resultate aus 

Vergleichen zu ziehen. So nützt es nicht, wenn auf einem viel schwächeren System 

die gleiche Datei heruntergeladen wird, der Prozessor sich aber außer Stande sieht, 

die Daten so schnell zu verarbeiten wie sie an der Netzwerkschnittstelle ankommen. 

Betrachtet man dies rein subjektiv, wirkt es für den normalen Nutzer, als hätte er 

geringere Downloadraten. Dies soll vermieden werden. 

Nokia 6680 

Zuerst wurde in Betracht gezogen, mehrere 

Mobiles zu benutzen, aber aus Nichtverfügbar- 

keit anderer Mobiles fiel die Wahl auf das Nokia 

6680 [Abb. 3.2]. Es ist zur Zeit das Referenz- 

Mobile für Messungen von O2(Germany). Aus- 

gestattet mit einer aktuellen Messfirmware von 

Rohde&Schwarz ist das Mobile in der Lage, Da- 

ten der Uu-Schnittstelle zu erfassen und an den 

Rechner zu Romes (siehe Abschnitt ”Verwende- 

te Software”) zu übermitteln. Mit der von Roh- 

de&Schwarz installierten Messfirmware ist es mög- 

lich, ohne extra Rechner wichtige Daten aus dem 

Abbildung 3.2: Nokia 6680 

UMTS-Netz abzulesen. Hierzu ist ein Tool auf dem Mobile selber installiert. Dort kann 

man alle Daten (Cell ID, Location Area Code (LAC), Common Pilot Channel (CPICH), 

Zustand (State), etc.) über die aktive Zelle und auch über die Nachbarzellen abrufen. 

3.2.2 Verwendete Software 

Romes 

Für den Ablauf der Messungen und das Erfassen wichtiger Parameter (Received Signal 

Code Power (RSCP), Ec/Io, Layer 3 Nachrichten) ist Romes zuständig. Romes wurde 

von Rohde&Schwarz entwickelt um komplexe Netze zu messen, zu analysieren und zu 

optimieren [Rohd06]. Es wird die aktuelle Version 3.53 von Romes verwendet (Stand: 



April 2006). 

Mit dieser Software ist es möglich Vorgänge reproduzierbar ablaufen zu lassen, wie 

z.B. einen Download über HTTP oder FTP. Dafür muss das Mobile auf dem Computer 

installiert sein, hierzu wurde der aktuelle Nokia-Treiber verwendet. Das Mobile wird 

über eine DFÜ-Verbindung des Rechners eine Netzwerkschnittstelle, mit Zugriff auf das 

Internet, bilden. Zusätzlich muss dafür in den Systemeigenschaften des Betriebssystems 

ein AT-Kommando (3GPP Spezifikation 27.007) eingegeben werden um das Modem 

zu initiieren: 

• AT+CGDCONT=1,’IP’,’surfo2’ 

• AT: spezifiziert hierbei die Aufrufung der AT-Kommandos 

• CGDCONT=: bezeichnet die Beschreibung des PDP-Kontextes 

• 1: bestimmte Definition des PDP-Kontextes 

• IP: spezifiziert den Typ des Protokolls (hier IPv4) 

• surfo2: Bezeichnung des APN 

Abbildung 3.3: Einbinden des Nokia 6680 

Nachdem das Mobile konfiguriert wurde, kann es von Romes eingebunden werden 

[Abb. 3.3]. Anschließend wird ein so genannter DQA in Romes erzeugt, mit welchem es 



Abbildung 3.4: DQA Einstellungen 

möglich ist verschiedene Dienste zu testen und den Ablauf dieser festzulegen [Abb. 3.4]. 

Dort wird auch der Server angegeben, bei welchem die Testdateien für die Messungen 

liegen. Hier wird ein Server von Rohde&Schwarz benutzt, auf welchem einfache Dateien 

in Standardgrößen liegen (64 kByte, 128 kByte, 256 kByte, ..., 16384 kByte). Über diese 

Software wird die ganze Messung gesteuert. 

Mit dem ”Start Measurement”-Button in der oberen Taskleiste wird die Messung ge- 

startet, also zuerst eine DFÜ-Verbindung aufgebaut, der PDP-Kontext aktiviert und 

die Verbindung hergestellt. Danach beginnt der Registrierungsvorgang auf den Test- 

server und anschließend wird die ausgewählte Datei heruntergeladen. Romes kann viele 

Informationen erfassen, dabei werden zum einen die paketvermittelten Informationen 

im Downlink und Uplink erfasst wie: 

• Aktueller Datendurchsatz 

• Mittlerer Datendurchsatz 

• Max. / Min. Datendurchsatz 

• QoS Report (z.B. wie viele gute Verbindungen insgesamt) 



• Layer-3-Nachrichten 

• Zeitdauer der Übertragung 

Zum Anderem werden funkspezifische Parameter erfasst wie: 

• Aktueller Zustand (CELL DCH, CELL FACH, etc.) 

• Radio Signal Strength Indicator (RSSI) 

• RSCP (vom CPICH) 

• Ec/Io (vom CPICH) 

• Traffic Channel: Block Error Rate (BLER) 

• Informationen über die gerade aktive Zelle (Cell ID, SC, LAC etc.) 

Da nicht alle Parameter gemessen werden können, sollen folgende Informationen zur 

weiteren Analyse aus Romes verwendet werden: 

• SC (und damit aktueller RAB) 

• Layer 3 Nachrichten um ”radioBearerReconfiguration” zu analysieren 

• RSCP 

• Durchsatz Parameter 

• Zeitdauer der Übertragung 

Ethereal, TcpTrace & jPlot 

Ethereal ist ein Freewaretool für die Analyse von Netzwerkverbindungen. [Bild 3.5] 

Mit dem Start einer Romes-Messung wird auch Ethereal manuell gestartet und erfasst 

den kompletten Paketverkehr über eine ausgewählte Schnittstelle. Mit Ethereal ist es 

möglich, jedes Paket einzeln zu untersuchen. Um die mit Ethereal gespeicherten Down- 

loads zu analysieren, wurde das Freeware-Programm ”tcptrace” genutzt. Tcptrace läuft 

unter Windows und kann mit verschiedenen Einstellungen gestartet werden. Tcptrace 

wertet jede TCP-Verbindung einzeln aus und speichert sie unter a b ∗ .xpl, c d ∗ .xpl, 

usw. ab. Die Ausgabe des Time Sequenz Graph (TSG) der ersten Verbindung (z.B. 

Upload) wäre dann a b tsg.xpl. Die Ausgaben, die verwendet werden, sind der TSG 

und der Throughput Graph. Mit diesen beiden Ausgaben wird nun ein UNIX-Ableger 



Abbildung 3.5: Ethereal 

von xPlot, jPlot gespeist. jPlot läuft unter Windows als Java Applikation. Es dient 

zur Visualisierung der mit tcptrace ausgewerteten TCP-Verbindungen [Abb. 3.6]. Um 

nicht für jede einzelne Ethereal-Datei eine neue Kommandozeile einzugeben, wird ein 

Batch-Datei mit tcptrace verwendet, welches bei Aufruf einer speziellen Endung z.B. 

mit ∗.tcp G die TSGs aller TCP-Verbindungen einer Ethereal-Datei ausgibt. Auch für 

jPlot wird eine Batch-Datei verwendet, diese ruft ein Javafenster auf und visualisiert 

die aktuellen Daten. 

Mit Hilfe von tcptrace sollen folgende Informationen aus den Ethereal-Dateien 

verwendet werden: 

• Anzahl wiederholter Übertragungen 

• Anzahl der Datenpakete 

• Daten aus dem TSG 

Aus der tcptrace Datei werden per Batch-Script bestimmte Zeilen (TSG-Pakete) ex- 

trahiert, so dass diese in eine Exceldatei übertragen werden können. Mit Excel ist es 

so zum Schluss möglich vergleichende Analysen zu machen. 



3.3 Kriterien der Szenarios 

Abbildung 3.6: jPlot Visualisierung 

Um nun die Messungen durchzuführen, müssen erstmal bestimmte Szenarien geschaf- 

fen werden. Es gibt zwei verschiedene Gruppen von Anwendungen, welche der Nutzer 

verwenden kann. Zum einen sind das die Echtzeitanwendungen (VoIP, Videostreaming) 

und zum anderen Anwendungen, die keine Echtzeit erfordern (HTTP, FTP). Im Fol- 

genden soll zunächst erklärt werden, welche Schlüssel-Parameter (so genannte Key 

Performance Indicator (KPI)) für welchen Typ wichtig sind, bzw. welche gemessen 

werden sollen. 

Echtzeitanwendungen 

Geht man von Echtzeitanwendungen aus, welche Daten über UDP, d.h. unbestätigt 

vom Server zum Client schicken, kann man den Durchsatz nur noch als zweitrangiges 

Kriterium werten. Datenraten bei zu übertragenden Videos sollten eine Kodierung auf- 

weisen, welche immer mit Abstand unterhalb des maximalen verfügbaren Durchsatzes 

liegt, um so evtl. Bursts ausgleichen zu können. Würde dies nicht so gemacht werden, 

könnte der Puffer des Clients voll laufen und das aktuelle Video stocken. Zurzeit wird 

an einem Messsystem gearbeitet (noch nicht einsatzbereit), mit welchem es möglich 

sein wird, gute Echtzeitauswertungen von Videostreams zu tätigen. Dieses Messsystem 



wird Software nutzen, bei der eine Original-Datei (liegt am Client und am Server vor) 

vom Server zum Client übertragen wird und anschließend der Client die übertrage- 

ne Datei mit der originalen Datei vergleicht und die Unterschiede feststellt. Auch die 

Bildqualität kann damit gemessen werden, da subjektive Qualitätseindrücke für exakte 

Messungen nicht von Vorteil sind. Da diese Möglichkeit der Messung für die Diplom- 

arbeit nicht bestand, wurde auf dem WAP-Portal eine mpeg4-Datei abgelegt, welche 

anschließend zu Messungen heruntergeladen werden soll. Somit kann die Dateigröße 

der heruntergeladenen Datei mit der originalen Datei verglichen werden und es ist es 

möglich, indirekt den Paketverlust zu errechnen. Ein weiteres Kriterium ist die Zeit- 

dauer, welche benötigt wird das Video abzuspielen, im Vergleich zur originalen Länge 

des Videos. Schlüsselparameter für Videostreaming-Messungen sind also: 

• Übertragene Datenmenge 

• Zeitdauer des Abspielens 

Neben den QoS-Parametern können natürlich auch die Funkparameter eine Rolle spie- 

len, aus diesem Grund werden folgende Parameter bei Echtzeitanwendungen gemessen: 

• RSCP 

• RAB / SC 

Bei den Messungen von VoIP wird der VoIP-Testserver angerufen der immer die glei- 

che Datei abspielt. Am Anfang werden mehrere Referenzmessungen gemacht, um die 

gesamte ankommende Datenmenge zu erfassen und so vergleichende Analysen möglich 

zu machen. Die Zeitdauer ist immer die gleiche. Schlüsselparameter sind somit: 

• Übertragene Datenmenge 

• RSCP 

• RAB / SC 

Nicht-Echtzeitanwendungen 

Zu den Nicht-Echtzeitanwendungen zählen HTTP und FTP. Da diese Anwendun- 

gen auf TCP aufsetzen, resultieren Paketverluste in Übertragungswiederholungen. Da 

durch Übertragungswiederholungen Pakete erneut gesendet werden müssen, wird so 

effektive Kapazität des Übertragungskanals geraubt. Demzufolge ist die Anzahl der 

Übertragungswiederholungen ein nicht unerhebliches Kriterium, da sie den effektiven 



Durchsatz verringert. Der Durchsatz wird direkt über die Ausgabe der Messung von 

Romes errechnet. Folgende Parameter werden für die Messung betrachtet: 

• Durchsatz 

• Anzahl Übertragungswiederholungen 

Auch werden wieder funkspezifische Parameter gemessen wie: 

• RSCP 

• RAB 

Die Optimierung der Nicht-Echtzeitanwendungen soll darin bestehen, den Durchsatz 

zu maximieren, bei gleichzeitiger Minimierung der Übertragungswiederholungen. 

3.4 Messszenario 

Im Folgenden soll erläutert werden, wie die ersten Messungen unternommen werden 

sollen und welche Szenarien betrachtet werden. Anschließend wird der Ablauf einer 

Messung geschildert, was man bei Romes und Ethereal beachten muss und welche 

Einstellungen für die Messung vorzunehmen sind. 

3.4.1 Standort der Messung 

Abbildung 3.7: Standard Messstrecke 



Für die Messungen wurden stationäre und mobile Szenarien betrachtet. Die ersten 

Messungen wurden stationär auf dem Campus von O2(Germany) durchgeführt. Mit 

diesen Messungen soll die Funktion des Messsystems verifiziert werden. Anschließend 

wurden auch Messfahrten in der nahen Umgebung des Campus’ von O2(Germany) 

unternommen, um die Auswirkungen der Funkübertragungsstrecke auf die Datenüber- 

tragung zu beobachten. Die Messungen zu Verifikation des Netzes wurden auf einer 

Standardstrecke durchgeführt [Bild 3.7]. Diese Route bietet eine Empfangsqualität im 

Bereich von -50 bis -60 dBm an den gut abgedeckten Positionen und geht an schlech- 

teren Positionen auf -90 bis -110 dBm zurück. Somit deckt diese Route schlechte und 

gute Empfangsqualitäten ab, damit soll ein Überblick über mögliche Zustände, in denen 

sich das Mobile befinden kann, gegeben sein. Den Zustand, dass keine Versorgung sei- 

tens UMTS vorhanden ist, wurde nicht betrachtet, da entweder das T-Mobile-Netzwerk 

die UMTS-Versorgung übernimmt oder das Mobile in das O2(Germany)-GSM-Netz zu- 

rückfällt. Da keine Informationen über das T-Mobile-Netzwerk für O2(Germany) zur 

Verfügung stehen, ist es nicht möglich evtl. Auffälligkeiten zu untersuchen. Das GSM- 

Netz soll nicht betrachtet werden. 

3.4.2 Beschreibung des Ablaufs der Messungen 

Abbildung 3.8: Romes GPS Views 



Abbildung 3.9: Romes UMTS Views 

Zur Vorbereitung der Messung wird Romes und Ethereal gestartet. In Romes wird 

ein Workspace erstellt (oder geladen), welcher die Mobiles enthält. Es werden Views 

(Fenster) erstellt in den die Datenübertragung, die UMTS-Netzparameter und die Ko- 

ordinaten (mit Hilfe von Global Positioning System (GPS)) zu sehen sind. [Abb. 3.8 - 

3.10] 

Anschließend wird für den DQA ein Ablauf spezifiziert, welche Datei soll von wo 

und über welches Protokoll heruntergeladen werden. In Romes sollen entsprechende 

Einstellungen vorgenommen werden [Abb. 3.4], um folgende Messungen nacheinander 

durchzuführen: 

TCP-basierende Messungen 

FTP-Download 

Es soll ein FTP-Download mit einer Datengröße von 512 kbyte durchgeführt werden. 

Die Datei liegt auf einem Server von Rohde&Schwarz vor. Anschließend soll ein Down- 

load von 8192 kbyte über FTP durchgeführt und damit die Übertragung großer Dateien 

getestet werden. Die letzte Messung mit FTP wird ein Upload sein. 64 kbyte sollen 

vom Client zum Server von Rohde&Schwarz übertragen werden. Diese Messungen sol- 



len zehnmal wiederholt werden. 

HTTP-Download 

Abbildung 3.10: Romes DQA Views 

Es soll vom gleichen Server, nun über HTTP, dieselbe 512 kbyte Datei heruntergeladen 

werden. Auch diese Messung soll zehnmal wiederholt werden. 

UDP-basierende Messungen 

Da sowohl HTTP als auch FTP auf TCP aufsetzen, ist es sehr einfach mit Ethereal 

diese Daten, auf die im Kapitel 3.1 beschriebene Weise, zu analysieren. Bei Videostrea- 

ming und VoIP, welche auf UDP aufsetzen wird folgende Messung ablaufen. 

Videostreaming 

Bei den ersten Videostream soll ein Livestream-Server aus dem Internet dienen. Dazu 

wurde der Livestream von www.Giga.de verwendet, dieser liefert einen Livemitschnitt 

des aktuellen Fernsehprogramms. Mit Hilfe von Romes wird die Abspielzeit des Streams 

(inklusive des Pufferns) auf 120 Sekunden begrenzt. 



Im weiteren Verlauf der Arbeit soll ein Videostream vom WAP-Portal von O2(Ger- 

many) verwendet werden. Dieses Video hat eine Abspielzeit von ca. 10 Minuten und 

ist mit 120 kbit/s kodiert (96 kbit/s Video und 24 kbit/s Ton). 

VoIP-Anwendung 

Für Voice over IP-Messungen wird das Programm Skype benutzt. Nach dem Start 

der Messung soll ein Skype-Testserver angerufen werden. Von der rufenden Seite aus 

werden keine Daten geschickt, so dass die Menge übertragener Pakete immer dieselbe 

ist. 

3.5 Auswertung der Ergebnisse 

Abbildung 3.11: Downgrade des RadioBearers 

Nachdem die Messungen durchgeführt wurden, können die ersten Aussagen über den 

Zustandes des Netzes getroffen werden. Das auffälligste bei den Messungen war ein 

plötzlicher Abfall des durchschnittlichen Durchsatzes. Wurden die Funkverhältnisse zu 

schlecht, gab es einen so genannten RAB Downgrade, durch diesen Downgrade wurde 

der Teilnehmer vom 384 kbit/s RAB auf den 128/s kbit RAB heruntergesetzt [Abb. 

3.11]. Von der Netzseite aus existiert dazwischen noch ein 256 kbit/s RAB, welcher 



Abbildung 3.12: Übertragungswiederholungen 

aber aufgrund interner Regelungen nicht genutzt. Es wurde festgestellt, dass im aktiven 

Zustand [Kap. 2.5.2] der RAB zwar auf einen niedrigeren wechseln kann, aber nicht 

wieder zurück wechselt, wenn die Funkverhältnisse es wieder zulassen würden. Um in 

den besseren RAB zurück zu wechseln, muss der Teilnehmer, respektive das Mobile in 

den inaktiven Zustand [Kap. 2.5.1] zurückkehren. 

Ein weiterer interessanter Aspekt, der beobachtet wurde, waren die Übertragungs- 

wiederholungen. Mit tcptrace lässt sich gut beobachten, ob eine wiederholte Übertra- 

gung schon empfangen wurde oder nicht. Die Mehrzahl ankommender Übertragungs- 

wiederholungen wurde das zweite Mal empfangen, was darauf schließen lässt, dass die 

Bestätigungen, die an den Server bei erfolgreicher Übertragung gesendet werden, nicht 

ankamen. Somit war bei der Messung der Uplink der wahrscheinlichste Auslöser für 

eine Übertragungswiederholung. Zu sehen sind schon empfangene Übertragungswie- 

derholungen an gelben vertikalen Strichen [Abb. 3.12]. 

Bei den Messungen des Videostreams wurde festgestellt, dass dieser nicht über UDP 

sondern über TCP läuft. Weitere Nachforschungen ergaben, dass die Firewall an der Gi- 

Schnittstelle die Ports für Videostreaming gesperrt hat. UDP macht eine Zurückstufung 

und überträgt den Stream dann mit Hilfe von TCP. Ein unterbrechungsfreies Video ist 

mit TCP nicht möglich. Somit wurden die Tests mit Videostreaming wiederholt. Dazu 

wurde ein 3gp auf das Wap-Portal gelegt, diese Datei kann per UDP heruntergeladen 

werden. 

In der Tabelle 3.1 ist eine übersichtliche Auswertung der verschiedenen Applikationen 

zu sehen. Folgende Kriterien wurden verwendet: 



Zeitdauer 

Die Zeitdauer wird mit Romes in ms bestimmt. Je schneller eine Datei heruntergeladen 

wurde, desto höher liegt der Durchsatz. 

• Minimum (Min): Gibt die geringste Zeitdauer an, die für den Down-/Upload 

einer Datei benötigt wurde. 

• Maximum (Max): Gibt die größte Zeitdauer an, welche für einen Down-/Upload 

einer Datei benötigt wurde. 

• Durchschnitt (Avg): Gibt den Mittelwert aller gemessenen Zeitdauern an. 

Durchsatz Downlink 

Gemittelt über jeweils 10 gleiche Szenarien soll der Durchsatz des Downlinks ermittelt 

werden. Durch den Durchsatz lassen sich Rückschlüsse auf den Zustand des Netzes 

und der Qualität der Verbindung ziehen. 

• Minimum (Min): Minimale Datenrate im Downlink. 

• Maximum (Max): Maximale Datenrate im Downlink. 

• Durchschnitt (Avg): Gibt die mittlere Datenrate für den Downlink an. Wird über 

alle Messungen eines Anwendungsfalls (z.B. FTP 512 kbyte Download) gemittelt. 

Durchsatz Uplink 

Gemittelt über jeweils 10 gleiche Szenarien soll der Durchsatz des Uplinks ermittelt 

werden. 

• Minimum (Min): Minimale Datenrate im Uplink. 

• Maximum (Max): Maximale Datenrate im Uplink. 

• Durchschnitt (Avg): Gibt die mittlere Datenrate für den Uplink an. Wird über 

alle Messungen eines Anwendungsfalls (z.B. FTP 64 kbyte Upload) gemittelt. 

Sitzungszeit 

Die Sitzungszeit gibt die Zeit an, welche vom Beginn einer Applikation (z.B. Login 

auf einen FTP Server) bis zum Ende (z.b. Trennen vom FTP Server) gemessen wird. 

Hiermit lassen sich allgemeine und vergleichende Aussagen über verschiedene Applika- 

tionen treffen. 



• Minimum (Min): Minimale Zeit vom Beginn einer Verbindung bis zum Ende. 

• Maximum (Max): Maximale Zeit vom Beginn einer Verbindung bis zum Ende. 

• Durchschnitt (Avg): Gibt die mittlere Zeit vom Beginn einer Verbindung bis zum 

Ende an. Wird über alle Messungen eines Anwendungsfalls (z.B. FTP 64 kbyte 

Upload) gemittelt. 

# Übertragungswiederholungen 

Die Anzahl der Übertragungswiederholungen wird mit tcptrace ausgewertet. Je mehr 

Übertragungswiederholungen auftreten, desto schlechter die Qualität der Verbindung. 

• Minimum (Min): Minimale Anzahl von Übertragungswiederholungen während 

einer Sitzung. 

• Maximum (Max): Maximale Anzahl von Übertragungswiederholungen während 

einer Sitzung. 

• Durchschnitt (Avg): Gemittelte Anzahl von Übertragungswiederholungen über 

zehn Sitzungen. 

# Pakete insgesamt 

Hier sollen alle ankommenden Pakete, exklusive der Übertragungswiederholungen, ge- 

zählt werden. So können Schwankungen in der Anzahl der Pakete erkannt werden und 

unter Umständen daraus resultierende längere Downloadzeiten ausgemacht werden. 

• Minimum (Min): Kleinste Anzahl an Paketen, die bei der Übertragung einer 

Datei gemessen wurden. 

• Maximum (Max): Maximale Anzahl an Paketen, die bei der Übertragung einer 

Datei gemessen wurde. 

• Durchschnitt (Avg): Die Anzahl der Pakete, die über alle zehn Übertragungen 

gemittelt wird. 

Dateigröße 

Soll bei UDP mit Hilfe von Ethereal errechnet werden. Durch die Dateigröße und die 

Informationen der Originaldatei können so Paketverluste ermittelt werden. 



• Minimum (Min): Gibt die kleinste empfangene Komplettgröße einer Datei an. 

Daraus kann der maximale Paketverlust errechnet werden. 

• Maximum (Max): Gibt die größte empfangene Komplettgröße einer Datei an. 

Daraus kann der kleinste Paketverlust errechnet werden, im Idealfall wäre dieser 

null. 

• Durchschnitt (Avg): Gibt die mittlere empfangene Größe und damit den mittle- 

ren Paketverlust einer Datei an. 

Entscheidungsmatrix 

Tabelle 3.1: Auswertung der Momentansituation 

Die Entscheidungsmatrix enthält alle Parameter, die getestet werden, zusammen mit 

den Anwendungen (FTP, HTTP, usw.) und den Optimierungskriterien (Durchsatz, 

Übertragungsdauer). Wenn beispielsweise zehn Parameter getestet wurden, bekommt 

die beste Änderung zehn Punkte, die zweitbeste Änderung neun usw., unter der Vor- 

aussetzung, dass die Änderungen besser sind als der Referenzwert (ohne Änderung). 

Alle Ergebnisse, die unter dem Referenzwert liegen bekommen null Punkte. 



Man kann einzelne Anwendungen auch Gewichtungen zuweisen, so werden beispiels- 

weise die Messungen der UDP-Anwendungen mit 1/2 gewertet, da durch die schlech- 

teren Messmöglichkeiten eine zu starke Abhängigkeit dieser Ergebnisse vermieden wer- 

den soll. Dagegen wird der das Herunterladen der 512 kbyte Datei von dem FTP-Server 

mit der Wichtung 2 versehen, da dies einem häufigen Anwendungsfall im Live-Netz 

entspricht. 



4 Optimierungskonzepte 

Hier sollen nun, beginnend vom Endgerät über das UTRAN bis zum Core Network, 

mögliche Optimierungsansätze analysiert werden. Dabei soll vor allen auf die Hinter- 

gründe der gewählten Ansätze und der theoretischen erreichbaren Ziele eingegangen 

werden. Soweit es die Ansätze zulassen, sollen diese in Bezug zu O2(Germany) gebracht 

werden. 

Bei den Ansätzen soll darauf geachtet werden, dass eine Optimierung des Netzes in 

Hinsicht auf die Kriterien (Durchsatz, Übertragungswiederholungen, Übertragungszeit 

und Anzahl empfangener Pakete) erfolgt. 

4.1 Anpassung der TCP/IP Einstellungen (Endgerät) 

Die TCP/IP-Einstellungen können in der Windows-Registrierung im Endgerät vorge- 

nommen werden. Darunter fallen z.B. Änderungen der MTU-Paketgröße, der maxi- 

malen TCP-Fenstergröße und der Überlebenszeit einzelner Pakete (Anzahl der Hops 

zwischen Knotenpunkten). 

Bei den Messungen wurde festgestellt, dass die Mehrzahl der Übertragungswieder- 

holungen zum zweiten Mal empfangen wurden. Dies lässt darauf schließen, dass die 

Bestätigungen im Upload den Server nicht erreichen. Aufgrund der niedrigen einge- 

stellten Fenstergröße und der fehlenden Bestätigungen über die bereits gesendeten Pa- 

kete ist die Fenstergröße null und es können keine Pakete mehr gesendet werden. Die 

Bestätigungen benötigen unter Umständen auch eine längere Zeit und da dies bei ser- 

verseitiger, kleiner Fenstergröße auch darin resultiert, dass keine Pakete mehr gesendet 

werden können, soll die Fenstergröße angehoben werden. So kann der Sender auch wei- 

terhin Pakete senden. Es soll untersucht werden, inwieweit sinnvollere Einstellungen 

als die von Windows vorgegebenen für ein UMTS-Mobilfunknetz verwendet werden 

können. 

Die Fenstergröße, welche von Windows vorgegeben wird, beträgt 16480 / 17520 

byte. An diese passen sich die Server an, welche Daten über TCP mit dem Nutzer 

austauschen. 



Umsetzung 

Um Veränderungen einer Übertragung aus dem UMTS-Netz festzustellen, soll die Fens- 

tergröße auf 35040 byte und auf 64240 byte gesetzt werden. Die TCP-Fenstergröße 

sollte vielfache der Segmentgröße betragen, welche sich aus der MTU-Größe minus 40 

(minimale Größe des TCP/IP Headers) zusammensetzt. 

Diese Änderung ist nicht vom UMTS-Netz an sich abhängig. Genauso wenig kann 

der Netzbetreiber, in diesem Falle O2(Germany), an diesen Einstellungen etwas än- 

dern. Es wäre möglich, die Änderungen in der Windows-Registrierung als Patch für 

Kunden zum Download anzubieten, dieser Patch kann dann die Einstellungen der 

TCP-Verbindungen für das UMTS-Netzes optimieren. 

Erwartungen / Probleme 

Mit einer erhöhten Fenstergröße wird erwartet, dass der Server länger Pakete senden 

kann und nicht auf verzögerte Bestätigungen bereits gesendeter Pakete warten muss. 

Somit sollte einer schnellere Übertragung stattfinden und die Zeitdauer eines Down- 

loads sinken. 

Da die TCP-Einstellungen für alle Verbindungen festgelegt werden, kann es zu Pro- 

blemen kommen, wenn das Endgerät auch in LANs und anderen Netzen genutzt wird, 

da dort andere RTTs vorliegen und so möglicherweise das Netz mit Daten überfüllt 

wird, obwohl ein Problem vorliegt. 

Um diese Registrierungsänderung zu bestätigen, muss der Rechner neu gestartet 

werden. Diese Optimierung ist nicht benutzerfreundlich, da ein gewisses Verständnis 

für die Änderungen in der Windows-Registrierung vorausgesetzt wird. 

4.2 Dynamischer Upgrade des RAB (Uu-Schnittstelle) 

Abbildung 4.1: Kein Upgrade des RAB 



Das größte Potenzial stellt der dynamische RAB Upgrade dar. Werden die Funk- 

verhältnisse für eine Übertragung über den 384 kbit/s RAB unzureichend, findet ein 

Downgrade des RAB auf 128 kbit/s statt. Das derzeitige Verhalten des Netzes zeigt, 

dass bei einer anschließenden Verbesserung der Funkverhältnisse, kein Wechsel zurück 

zu dem 384 kbit/s RAB stattfindet [Abb. 4.1], solange sich der Nutzer im aktiven 

Zustand [Kap. 2.5.2] befindet. Der Wechsel zurück zum 384 kbit/s RAB erfolgt erst, 

wenn der Nutzer zurück in den inaktiven Modus [Kap. 2.5.1] gewechselt ist. Nun soll 

der Wechsel zurück zum 384 kbit/s RAB auch während des aktiven Zustands möglich 

sein. 

Umsetzung 

Abbildung 4.2: Upgrade des RAB 

Das Ziel der Einführung des Upgrades des RAB ist in Abb. 4.2 zu erkennen. Es 

soll, nachdem ein Downgrade eines RAB stattgefunden hat, ein Upgrade stattfinden. 

Grundsätzlich werden für die Umsetzung die gleichen Parameter benötigt, welche für 

den Downgrade eines RAB zuständig sind. Das sind vor allem Timer die beim unter- 

schreiten bestimmter Grenzwerte, z.B. RSSI unter -100 dBm, gestartet werden und 

den Downgrade veranlassen, sollte der Grenzwert nach Ablauf des Timers immer noch 

unterschritten sein. Es müssen zusätzliche Parameter eingeführt werden, welche vor- 

geben von und zu welchen RAB ein Wechsel erlaubt ist, dies muss eindeutig definiert 

sein. 

Im UMTS-Netz von O2(Germany), wo der 384 kbit/s, der 128 kbit/s und niedrigere 

RAB genutzt werden, muss zwischen diesen der Upgrade geregelt sein. Vom 384 kbit/s 

RAB wird kein dynamischer Upgrade gefordert, da zur Zeit kein höherer RAB existiert. 

Auch ist es nicht nötig von einen höheren RAB einen Upgrade zu einen niedrigeren 

RAB zu erlauben. Vom 64 kbit/s RAB muss beispielsweise ein Upgrade zum 128 kbit/s 

RAB und zum 384/s kbit RAB erlaubt sein. 



Bei der Analyse des UMTS-Netzes von O2(Germany) stellte sich heraus, dass die 

Nortel Hardware prinzipiell schon über entsprechende Parameter verfügt um einen 

Upgrade zu erreichen, diese sind allerdings nicht eingestellt und werden nicht verwen- 

det. 


Es wird erwartet, dass durch eine Implementation des dynamischen Upgrades die Zeit- 

dauern von Datenübertragungen abnehmen. Das UMTS-Netz passt sich somit optimal 

an die gerade vorherrschenden Funkverhältnisse an. 

Probleme können bei der Einstellung der Timer und Grenzwerte auftreten, diese 

müsse so eingestellt werden, dass es zu keinen Dauerwechsel zwischen zwei RAB 

kommt. Dies kann mit Hilfe einer Hysterese erreicht werden. 

4.3 Parameteroptimierung (RNC) 

Bewegt man sich nun weiter Richtung Core Network, so stellt man fest, dass auch im 

RNC für die Verbindung zum Endgerät bestimmte Parameter im RLC-Protokoll geän- 

dert werden können. Die Parameter sind von Nortel voreingestellt und können, je nach 

Bedarf, dem Netz angepasst werden. Dort werden verschiedene Polling- (z. dt. Abruf 

oder Anforderung) Parameter, sowie auch Fenstergrößen für die Übertragung zwischen 

RNC und dem Endgerät festgelegt. Diese Parameter werden im RLCAcknowledgeMode 

vorgenommen. 

Umsetzung 

Es sollen die von Nortel vorgegebenen Werte mit denen verglichen werden, welche im 

Live-Netz eingespielt sind. Anschließend werden die Parameter bzgl. ihrer Aufgaben 

analysiert und dementsprechend verändert. Jeder Parameter, der zur Steigerung des 

Durchsatzes beim Download von Daten genutzt werden kann, soll untersucht werden. 


Durch die Parameteränderung soll untersucht werden, ob eine Steigerung des Durchsatz- 

es möglich ist. Probleme treten durch die große Anzahl an veränderbaren Parameter 

auf, so dass eine Vorauswahl getroffen werden muss. Diese Vorauswahl wird im Testbed 



von O2(Germany) stattfinden. Resultate aus den Ergebnissen sollen nach Möglichkeit 

auch im Live-Netz getestet und anschließend optimiert werden. 

4.4 Aktivierung der ”Streaming”-Klasse (HLR) 

Recherchen innerhalb des Netzes von O2(Germany) ergaben, dass nur zwei der vier 

verfügbaren QoS-Klassen genutzt werden, diese sind ”Interactive”und ”Background”[s. 

Kap. 2.4.5]. Interessant an dieser Stelle ist die ”Streaming”-Klasse, welche den Verkehr 

von Echtzeitverbindungen optimieren soll. 

Umsetzung 

Es soll die ”Streaming”-Klasse aktiviert und bzgl. UDP-Verkehr untersucht werden. 

Zusätzlich soll die Beeinflussung des TCP-Verkehrs, durch diese Klasse, getestet wer- 

den. 

Die QoS-Klasse wird in den Dienstgüteparametern eines APNs gespeichert und muss 

darüber hinaus noch für das UE freigeschaltet sein. 


Es wird erwartet, dass durch die Aktivierung der ”Streaming”-Klasse, die Anzahl der 

fehlerhaft übertragenen Dateien sinkt und die objektive Qualität der übertragenen 

Daten (Ton und Bild) steigt. 

Da der APN nicht, je nach Anwendung, automatisch angepasst werden kann, kön- 

nen Probleme bei normaler Sprachübertragung und TCP-Verkehr auftreten. Da bei 

der ”Streaming”-Klasse die Parameter Jitter und Latenz, wegen der Pufferung am 

Empfänger, nicht so wichtig sind, sind starke Störungen von Sprachübertragungen zu 

erwarten. 

4.5 Applikationspezifische Komprimierung 

(Gi-Schnittstelle) 

Bei der Suche nach Optimierungsansätzen liegt der Gedanke einer Komprimierung zur 

schnelleren Übertragung von Daten sehr nahe, da eine kleinere Datenmenge automa- 

tisch schneller übertragen wird. Wird das Paket am Empfänger wieder dekomprimiert, 



bekommt man einen subjektiv höheren Durchsatz, da man zwar die gleiche Dateimenge 

empfängt, diese aber in offenbar kürzerer Zeit. 

Umsetzung 

Geht man davon aus, dass ein Nutzer eine Textdatei aus dem Internet auf sein Mo- 

bile herunterlädt, dann wäre das einfachste Szenario die Datei direkt am Sender zu 

komprimieren, dies ist aber durch den Netzbetreiber des Mobilfunknetzes nicht beein- 

flussbar. Der Netzbetreiber kann die Größe der Datei frühestens an der Gi-Schnittstelle 

erfassen und nach Möglichkeit komprimieren. Die Komprimierung sollte zwischen der 

Gi-Schnittstelle und dem nodeB geschehen. Dabei gilt, je näher die Komprimierung 

an der Gi-Schnittstelle gemacht wird, desto besser wird das Ergebnis, da so kleine- 

re Datenmengen durch das gesamte Netz transportiert werden können. Somit soll die 

Komprimierung an der Gi-Schnittstelle erfolgen. 

Nachdem das Datenpaket aus dem Internet die Gi-Schnittstelle erreicht hat, muss 

es in ein Filter umgeleitet werden. Dieses Filter muss die entsprechende Dateiart des 

Paketes feststellen und dieses dementsprechend in einen Komprimierer leiten, der für 

diese Dateiart optimiert ist. So wird eine Textdatei ganz anders komprimiert als bei- 

spielsweise eine Tondatei. Das komprimierte Datenpaket soll dann weiter zum GGSN 

geschickt werden. 

Am Empfänger muss dann eine entsprechende Dekomprimierung stattfinden, wobei 

die Art der Komprimierung und die Dateiart in einem zusätzlichen Header mitgeliefert 

werden müssen. 


Grundsätzlich beinhaltet die Komprimierung ein großes Optimierungspotenzial, abzu- 

wägen hierbei ist die Dauer und der Aufwand der Komprimierung auf der Netzseite 

und auf der Nutzerseite durch das Mobile. Für die Komprimierung auf der Netzseite 

kann ein großer Rechner mit genügend Ressourcen verwendet werden, aber ein Pro- 

blem könnte auf der Nutzerseite auftreten. Da die Dekomprimierung (Nutzerseite) mit 

weniger Ressourcen dementsprechend mehr Zeit in Anspruch nimmt, könnte eine Datei 

dem Nutzer mit der Komprimierung später zur Verfügung stehen, als ohne Kompri- 

mierung. So muss entschieden werden ob eine Komprimierung vorgenommen, oder das 

Paket ohne durch einen entsprechenden Filter zu laufen zum Empfänger geleitet wird. 

Kriterien dabei wären z.B. die Größe der zu übertragenden Datei, die Dateiart aber 

auch Anforderungen seitens des Nutzers. Ist die zu übertragende Datei nur wenige Byte 



bis Kilobyte groß, kann eine Komprimierung die Zeitdauer der Übertragung sogar er- 

höhen, daher lohnt sich eine Komprimierung erst, wenn die Datei eine gewisse Größe 

überschreitet. Auch ist es nicht nötig, beispielsweise Bilder im Format Jpeg zu kom- 

primieren, da diese schon sehr gut komprimiert sind und eine weitere Komprimierung 

kaum Gewinn bringen kann. Allerdings kann man bei solchen Bilder die Auflösung 

und somit die Größe verändern, was aber in den Anforderungen des Nutzers liegt und 

dementsprechend abgefragt werden muss. 

Weiterhin wird erwartet, dass durch die Analyse der Dateien und das Umleiten in 

verschiedene Komprimierungsfilter eine globale Verzögerung auftritt. Dadurch beginnt 

der Datentransfer für den Nutzer subjektiv später als ohne Komprimierung. Hierbei 

kommt die Dateigröße stärker zum tragen, da somit aus Nutzersicht kleinere Dateien 

mit Komprimierung länger brauchen können als ohne. 

Fazit 

Diese Methode der Optimierung bietet eine hervorragende Möglichkeit, der Anpassung 

an verschiedene Anwendungen. 

Ein Hersteller ”byte-mobile” (www.bytemobile.com) beschäftigt sich, unter anderen 

mit dieser Art der Optimierung des Netzwerkes und bietet eine Lösung für Mobil- 

funknetze an. Da diese Software lizensiert ist und nur mit erheblichen Aufwand in ein 

bestehendes Netz integriert werden kann, konnte dies nicht im Rahmen dieser Diplom- 

arbeit untersucht werden. 

4.6 Network Address Translation (NAT), 

(Gi-Schnittstelle) 

Die Idee die bereits integrierte NAT zu optimieren besteht darin, zu untersuchen wo 

NAT vorgenommen wird welche Verzögerungen sie hervorruft und die Recherche einer 

sinnvollen Umsetzung für das Mobilfunknetzwerk. 

Umsetzung 

Zu allererst muss festgestellt werden, wie NAT zurzeit im Netz integriert ist. Es gibt 

verschiedene Möglichkeiten NAT zu integrieren. Eine davon ist die Integration als Be- 

standteil in den GGSN. Diese Methode raubt den GGSN Ressourcen und wird als nicht 

optimal angesehen. Besser ist es NAT als eigenständigen Rechner, aus Router, Daten- 



bank und Logik auf der Gi-Schnittstelle zu platzieren, so kann schnell und effizient eine 

Umsetzung stattfinden. 


Erwartet wird damit eine schnellere Umsetzung der Adressen und somit eine schnellere 

Übertragung von Einzelpaketen. Der Durchsatz soll steigen. Probleme sind dabei nicht 

zu erwarten. 

Fazit 

Nach einigen Recherchen innerhalb des Netzes, wurde festgestellt, dass NAT nicht im 

GGSN integriert ist, sondern als eigenständiges Gerät direkt auf der Gi-Schnittstelle 

sitzt. Somit besteht, im Sinne der Überlegungen zu NAT, kein Optimierungsbedarf. 



5 Implementierung 

Da O2(Germany) Region Süd (auch Standort München) nur Nortel-Hardware verwen- 

det, konnte die Implementierung der Konzepte nur für Nortel-Hardware vorgenommen 

werden. 

Die Ergebnisse können nicht ohne Tests auf die Nokia-Hardware übertragen werden. 

5.1 Anpassung der TCP/IP Einstellungen (Endgerät) 

Mit der Änderung der TCP/IP Einstellungen in der Windows-Registrierung, soll eine 

Verbesserung des Übertragungsverhaltens erreicht werden und der Durchsatz erhöht 

werden. 

Die vorgenommenen Änderungen sind nicht auf andere Betriebssysteme übertragbar 

und gelten nur für Windows Systeme (inkl. Windows Mobile). Alle Tests wurden auf 

den in Kap. 3.2.1 beschriebenen Laptop mit Windows XP Betriebssystem durchgeführt. 

Unter Linux können auch Änderungen in den TCP/IP Einstellungen vorgenommen 

werden. Eine Beschreibung der Parameter findet sich unter [Andr02]. 

5.1.1 Vorgehensweise 

Sollen die TCP/IP Einstellungen, hinsichtlich Fenstergröße geändert werden, müssen 

verschiedene Einträge in die Windows-Registrierung hinzugefügt werden. 

Wird die Fenstergröße verkleinert, werden die Abfragen nach Bestätigungen steigen 

und der Datenfluss wird gestört, bzw. es kommt zu Verzögerungen. Wird das Fenster 

zu groß gemacht, können die Daten einerseits ohne große Störung übertragen werden, 

andererseits, sollte es zu Problemen während einer Übertragung kommen, müssen viel 

mehr Daten erneut übertragen werden. Es muss eine Abwägung zwischen kleiner und 

großer Fenstergröße stattfinden. 

Zunächst soll eine Referenzmessung als Grundlage für spätere Vergleiche vorgenom- 

men werden. Anschließend werden die Einträge in der Windows-Registrierung konfi- 

guriert und Messungen mit verschiedenen Fenstergrößen durchgeführt. 



5.1.2 Windows-Registrierungs-Einträge 

Folgende Einträge sollen für die Veränderung in der Windows-Registrierung hinzuge- 

fügt werden. Diese Einträge sind Allgemein und gelten somit für alle evtl. Netzwerk- 

adapter. Die Einträge sind unter folgenden Schlüssel vorzunehmen: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

Es wurden mit Bedacht keine Veränderungen an der MTU-Größe getestet. Da für 

Veränderungen der MTU-Größe kein allgemeiner Registrierungsschlüssel verwendet 

werden kann, sondern der Schlüssel eines entsprechenden Netzwerkadapters verändert 

werden muss. 

Fenstergröße 

Die Fenstergröße (z. engl. WindowSize) stellt eine Anzahl von Bytes dar, welche ma- 

ximal unbestätigt übertragen werden können. Eine sinnvolle Einstellung wäre hierbei, 

die Fenstergröße als vielfaches der Maximum Segment Size MSS zu verwenden. Die 

MSS errechnet sich aus der MTU - 40 (bytes). Ein TCP/IP Header ist mindestens 40 

byte groß, so dass die MSS maximal 1460 byte groß ist, bei einer üblichen MTU-Größe 

von 1500 byte. 

GlobalMaxTcpWindowSize 

Dieser Schlüssel soll als DWORD in byte eingetragen werden und gibt die maxima- 

le, verwendbare Fenstergröße an. Der Schlüssel soll drei verschiedene Werte erhalten, 

welche getestet werden sollen: 17520, 35040 und 64240 byte. 

TcpWindowSize 

Die TcpWindowSize soll jeweils die gleichen Werte wie die GlobalMaxTcpWindowSize 

für die Tests verwenden: 17520, 35040 und 64240 byte. Dieser Schlüssel wird auch 

als DWORD eingetragen. Wenn die TcpWindowSize nicht gleich der GlobalMaxTcp- 

WindowSize entspricht, kann zwischen Server und Client eine Fenstergröße zwischen 

diesen beiden Werten ausgehandelt werden. 

Dieser Schlüssel könnte auch direkt unter einen ausgewählten Netzwerkadapter ein- 

getragen werden. In diesem Fall würde dann nur für diesen Netzwerkadapter die ein- 

getragene TcpWindowSize gelten. 



Tcp1323Opts 

Dieser Schlüssel wird benötigt um große Fenstergrößen zu unterstützen und wird genau- 

er in RFC 1323 beschrieben. Ohne diesen Parameter würde die maximale Fenstergröße 

auf 64 kbyte (65535 byte) beschränkt sein. Dieser Parameter wird nicht verwendet, da 

keine Fenstergrößen von mehr als 64 kbyte getestet werden. 

DefaultTTL 

Dieser Schlüssel legt fest wie lange ein Paket bestehen kann, bevor es verworfen wird. 

Der Wert des Schlüssel wird einmal für die maximale Anzahl an Hops verwendet und 

als direkte Zeit (in Sekunden). Sollte eines von beiden das Maximum erreicht haben, 

wird das Paket verworfen. 

Wenn der Wert zu hoch eingestellt ist, kann es zu lange dauern bis ein frühzeiti- 

ger Verlust eines Paketes festgestellt und dieses erneut übertragen wird. So kann es 

zu langen Verzögerungen in der Datenübertragung kommen. Sollte dagegen der Wert 

zu niedrig eingestellt sein, besteht die Möglichkeit, dass ein Paket einen bestimmten 

Empfänger nie erreicht. 

Standardmäßig ist dieser Wert auf 64 eingestellt und soll auch nicht verändert wer- 

den. Andere weit verbreitete Werte sind 32 und 128. 

EnablePMTUDiscovery 

Wenn der Wert dieses Schlüssels auf 1 steht wird die MTU Größe automatisch ein- 

gestellt. So wird der Beginn einer Übertragung leicht verzögert, da die MTU Größe 

für die Verbindung erst herausgefunden werden muss, so dass dieser Schlüssel erst bei 

größeren, zu fragmentierenden Datenmengen zum Wirken kommt. 

Eingestellt auf 0, wird die MTU Größe der gesendeten Pakete statisch auf 1500 byte 

gesetzt. 

Der Wert soll auf 1 eingestellt werden und evtl. Verbesserung bei großen Datenmen- 

gen untersucht werden. 

SackOpts 

Mit diesem Parameter kann man festlegen ob Selective Acknowledgement (SACK - 

Einzelbestätigungen über empfangene Pakete) genutzt werden, oder nicht. Bei einer 

hohen Fenstergröße empfiehlt es sich SACK zu erlauben. 

Für die Tests soll SACK verwendet werden. 



5.1.3 Durchführung 

Die Messung wird stationär im Campus-Gebäude von O2(Germany) durchgeführt. Sie 

soll an zwei Tagen durchgeführt werden, wobei die Messungen an beiden Tagen die 

gleichen sein sollen. So sollen evtl. äußere Einflüsse herausgerechnet werden können 

und das Ergebnis genauer machen. 

Zunächst wurde eine Messreihe für die Referenzmessung vorgenommen. Bei der Re- 

ferenzmessung sind keine Veränderungen in der Windows-Registrierung eingetragen. 

Bei dieser Messung wird eine 512 kbyte Datei von einem FTP-Server heruntergeladen. 

Das gleiche wird mit einer 8192 kbyte Datei, ebenfalls ein Download, wiederholt. Eine 

Messreihe besteht aus jeweils zehn Messungen. 

Nach den Messungen werden die Parameter, unter dem in Kap. 5.1.2 beschriebenen 

Schlüssel, in die Windows-Registrierung eingetragen und deren Werte eingestellt. Nun 

wird die Messung, wie oben beschrieben, wiederholt. Der Wert für die GlobalMaxTcp- 

WindowSize und die TcpWindowSize sind jeweils auf 17520 byte eingestellt. 

Für folgenden Messungen soll die Fenstergröße (GlobalMaxTcpWindowSize und Tcp- 

WindowSize) auf 35040 byte und auf 64240 byte gesetzt und die Messreihen wiederholt 

werden. 

5.1.4 Ergebnisse 

Wie an den Diagrammen zu erkennen, bewirken alle drei Veränderungen der Fenster- 

größe eine Verbesserung der Übertragungseigenschaften und somit eine Steigerung des 

Durchsatzes. 

Die Veränderung der Fenstergröße auf 17520 byte entspricht in etwa der Fenster- 

größe, welche ohne Veränderungen in der Windows-Registrierung gewählt wird, diese 

schwankt zwischen 16560 byte und 17520 byte. Da bei der Referenzmessungen im 

Durchschnitt jeder zweiter Download die Fenstergröße 16560 byte hatte, ist Anhand 

des Ergebnisses davon auszugehen, dass die geringfügige, konstante Erhöhung der Fens- 

tergröße auf 17520 byte eine Verbesserung der Datenübertragung bewirkt. Dieses Er- 

gebnis bestätigt sich auch in den Diagrammen. Der Durchsatz mit der Fenstergröße 

von 17520 byte fiel entsprechend geringfügig höher aus. 

Die Veränderung der Fenstergröße auf 35040 byte verbesserte das Übertragungsver- 

halten deutlich. Bei dem Download einer 512 kbyte Datei wurde die Übertragungszeit 

um ca. 0,7 Sekunden, auf 13,1 Sekunden verbessert und der Durchsatz stieg um ca. 

20% auf 313 kbit/s [Abb. 5.1]. Bei der Übertragung der größeren 8192 kbyte großen 

Datei verringerte sich die Übertragungszeit um ca. 15 Sekunden auf 194,7 Sekunden 



Abbildung 5.1: Ergebnis (512 kbyte 

DL) Änderung Fenstergröße, 

Durchsatz 



Durchsatz 

und der Durchsatz stieg um ca. 35% auf 337,2 kbit/s [Abb. 5.2]. Hier ist zu erkennen 

das der Parameter EnablePMTUDiscovery eine bessere Wirkung auf große Dateien hat. 

Im letzten Test wurde die Fenstergröße auf 64240 byte vergrößert. An den Ergeb- 

nissen ist zu erkennen, dass im Vergleich zu der Fenstergröße von 32520 byte eine 

Verschlechterung der Übertragungszeit und somit eine Verringerung des Durchsatzes 

auftritt. Dies kann dadurch zustande kommen, dass in Folge der langen RTT nicht 

auf mögliche Probleme reagiert werden kann und Pakete evtl. erneut übertragen wer- 

den müssen. Im Vergleich mit der Referenzmessung, ist dennoch eine Verbesserung zu 

erkennen. Die Übertragung der 512 kbyte Datei wird nur noch um ca. 14% und die 

Übertragung der 8192 kbyte Datei um ca. 21% verbessert. Tendenziell ist auch hier die 

Wirkung des Parameters EnablePMTUDiscovery zu erkennen. 

Wie an der niedrigen Schwankung an übertragenen Paketen und Übertragungswie- 

derholungen zu erkennen ist, können die Verbesserungen nicht daraus resultieren [Abb. 



Pakete 



Pakete 



Abbildung 5.5: Vergleich veränderter Fenstergrößen (512 kbyte DL) 

5.3, 5.4]. Auch die Funkverhältnisse sind konstant, was am RSCP Wert zu erkennen 

ist [Abb. 5.5, 5.6], was aufgrund der stationären Messung auch zu erwarten war. 

Optimierung in Prozent 

Bei der prozentualen Angabe der Optimierung der TCP/IP-Einstellungen, liegt der 

Durchsatz zu Grunde. Dieser ist repräsentativ für die allgemeine Verbesserung oder 

Verschlechterung der Übertragungseigenschaften. 

Tabelle 5.1: Optimierung in Prozent 

Man erkennt im Durchschnitt eine ca. 27%ige Verbesserung der Übertragungseigen- 

schaften für FTP-Downloads durch die Veränderung der Fenstergröße auf 35040 byte 

[Tab. 5.1]. 



5.1.5 Fazit 

Abbildung 5.6: Vergleich veränderter Fenstergrößen (8192 kbyte DL) 

Mit der Veränderungen der TCP/IP-Einstellungen in der Windows-Registrierung kann 

eine Verbesserung der Übertragungseigenschaften erreicht werden. 

Um das Ergebnis zu verifizieren, sollten weitere Tests stattfinden, diese sollten Datei- 

Upload, HTTP- und Echtzeitanwendungen umfassen. Des Weiteren können auch Mes- 

sungen mit verschiedenen Fenstergrößen in der Nähe des 35040 byte Fensters durch- 

geführt werden. So kann für verschiedene Anwendungen und allgemein eine optimale 

Fenstergröße bestimmt werden. Weitere Messungen konnten, aufgrund Zeitmangel und 

Nicht-Verfügbarkeit von Messmittel, für diese Arbeit nicht getätigt werden. 

Der Aufwand, die Parameter für die TCP/IP-Einstellungen einzeln einzugeben, ist 

für einen normalen Computer-Benutzer erheblich. Es ist möglich die Veränderungen 

in einen Windows-Registrierungspatch ∗.reg zu integrieren, so dass die Parameter mit 

Werten automatisch eingetragen werden. Allerdings wird ein Patch auf diese Weise 

niemals von O2(Germany) angeboten, da Konflikte mit anderen Anwendungen, welche 

nicht getestet wurden, nicht auszuschließen sind. Die daraus entstehenden Probleme 

mit den Nutzern sollen vermieden werden. 



5.2 Dynamischer Upgrade des RAB (Uu-Schnittstelle) 

Bei der Recherche nach Optimierungsmöglichkeiten fiel der Downgrade des aktiven 

RAB während des Downloads einer Datei am stärksten auf. Durch die Verschlechterung 

der Funkverhältnisse wechselte das Mobile vom 384 kbit/s RAB zum 128 kbit/s RAB. 

Die Datenrate sank und je nach Größe und Fortschritt der Datei wurde die Dauer des 

Downloads erheblich erhöht. Auch wenn die Funkverhältnisse nach kurzer Zeit wieder 

besser wurden, verblieb das Mobile im niedrigeren RAB. 

Es wurde nach der Möglichkeit gesucht, inwieweit ein dynamischer Upgrade eines 

RABs möglich ist. 


Bei der Recherche in den Nortel-Dokumenten fielen einige Parameter auf mit deren 

Hilfe es möglich ist, diesen dynamischen RAB Upgrade zu erwirken. Im Folgenden soll 

beschrieben werden, welche Parameter benötigt werden um einen dynamischen RAB 

Upgrade zu implementieren und umzusetzen. 

Es wird eine Messung im Testbed durchgeführt und die gewählten Parameter-Einstell- 

ungen erklärt. 

5.2.2 Verwendete Parameter 

Zunächst muss festgestellt werden, ob ein Upgrade des RAB möglich ist. Dazu müs- 

sen sich die Funkverhältnisse verbessert haben. Ist dies geschehen, kann der Upgrade 

auf einen bestimmten RAB erfolgen. Dieser RAB muss in dem aktuell, verwendeten 

RAB festgelegt werden. Bei den Einstellungen in Nortel werden dazu drei Parameter 

verwendet: 

isIrmSchedulingAllowed 

Legt fest, ob überhaupt ein Up- oder Downgrade für einen RAB erlaubt ist. 

isIrmSchedulingUpgradeAllowedFromThisUs 

Legt fest, ob von dem aktuellen RAB ein Upgrade erfolgen darf. 

isIrmSchedulingUpgradeAllowedToThisUs 

Legt fest, ob zu einem RAB ein Upgrade erfolgen darf. 



”Us (User Service)” bezeichnet hier die verschiedenen RAB, welche vom Nutzer als 

Dienst genutzt werden können. 

Nachdem vereinbart wurde, von und zu welchen RAB ein Upgrade erlaubt ist, müs- 

sen nun einzelne Grenzwerte festgelegt werden, also bei welchen Werten zu welchen 

RAB gewechselt werden kann. Geht man davon aus, dass die Funkverhältnisse lang- 

sam besser werden, kann es so zu ständigen Upgrades des RAB kommen, bis der höchste 

RAB erreicht ist. Dies kann umgangen werden, wenn z.B. die Grenzwerte für einen Up- 

grade hoch eingestellt werden, wobei dann die Dynamik des Upgrades verloren gehen 

kann. 

Bei Nortel wird es so gehandhabt, dass ein Upgrade nur nach einen Downgrade 

erlaubt ist und dann auch nur zu den vorherig verwendeten RAB. Somit kann man 

nur die Dienstgüte wiederbekommen, welche zu Beginn der Verbindung, in den QoS- 

Parametern, vereinbart wurde. 

Es werden grundsätzlich zwei Parameter benötigt, ein Grenzwert für die Funkver- 

hältnisse (z.B.: RSCP, Sendeleistung,...) und einen Timer, der bei Überschreitung des 

Grenzwertes startet. 

timeToTrigger 

Der Timer soll eine schnelles hin- und herspringen der RAB verhindern. Erst wenn 

der Timer abgelaufen ist und der Grenzwert immer noch überschritten ist, kann ein 

Upgrade durchgeführt werden. 

tresholdTransCodePower 

Als Grenzwert wird der tresholdTransCodePower verwendet. Nortel verwendet hier- 

für die Sendeleistung. Je höher die Sendeleistung eingestellt ist, desto schlechter sind 

die aktuellen Funkverhältnisse. Der Grenzwert muss also in dem Fall unterschritten 

werden um einen RAB Upgrade zu erwirken. 

Bei Nortel gibt es noch die Möglichkeit, nicht nur die Funkverhältnisse als Kriterium 

zu benutzen, sondern auch die Zelllast. Befinden sich mehrere Nutzer in einer Zelle, 

kommt es zu einem Downgrade des RAB einzelner Nutzer. Sollten sich nun einzelne 

Nutzer aus dieser Zelle heraus bewegen, kann auch hier wieder zum ursprünglichen 

RAB gewechselt werden. Bei den getätigten Messungen wird aber nur auf die Funk- 

verhältnisse eingegangen, da diese im Testbed gut veränderbar sind. 



Eingestellte Parameter 

Tabelle 5.2: Eingestellte Parameter für den dynamischen RAB Upgrade 

Getestet wird mit einer 8192 kbyte großen Datei. Der Download dieser Datei benötigt 

ca. 200 Sekunden, in dieser Zeit befindet sich das Mobile im aktiven Zustand und es 

können die notwendigen Messungen durchgeführt werden. 

Als erstes wird eine Referenz-Messung durchgeführt. So wird die Dämpfung des 

Kanals in 10 Sekunden-Abständen um 5 dB gedämpft. Nach sechs Schritten ist die 

kleinste noch messbare Dämpfung erreicht. Nach ca. 60 Sekunden gibt es einen RAB 

Downgrade auf den 128 kbit/s RAB. Es wird 45 Sekunden gewartet und die Dämpfung 

im gleichen Rhythmus wieder reduziert. 

Nachdem die Parameter entsprechend konfiguriert wurden, wird die Dämpfung in ca. 

10 Sekunden-Abständen um 5 dB erhöht, so dass die Sendeleistung nach 60 Sekunden 

den Grenzwert unterschreitet und wieder der RAB Downgrade stattfindet. Es wird 

wieder 45 Sekunden gewartet und die Dämpfung in 10 Sekunden-Intervallen verringert. 

5.2.3 Ergebnisse 

Abbildung 5.7: Dynamischer RAB Upgrade, 

Durchsatz 

Abbildung 5.8: Dynamischer RAB Upgrade, 

Zeitdauer 

In Abb. 5.9 ist zu erkennen das mit den veränderten Einstellungen, wie gewollt ein 

Update des RAB erwirkt wird. Die im getesteten Szenario erreichte Verkürzung der 



Abbildung 5.9: Zeitdauer einer Übertragung, mit und ohne dynamischen RAB Upgrade 

Übertragungszeit für den Download einer 8192 kbyte Datei beträgt 63,94% [Abb. 5.7, 

5.8]. 

Der RAB Upgrade macht nur Sinn, wenn die zu übertragende Datei eine bestimmte 

Größe hat. Sollte die Datei zu klein sein, würde der Upgrade kaum zum Tragen kommen 

und würde nur eine geringe oder gar keine Verbesserung bewirken, da kleine Dateien 

schneller heruntergeladen werden können und eine gewisse Zeit (Ablauf von Timern) 

für den Upgrade benötigt wird. Es macht also Sinn, den RAB Upgrade zu aktivieren, 

wenn Nutzer große Dateien (z.B. im Hintergrund) herunterladen. 

5.2.4 Fazit 

Im getesteten Anwendungsfall, dem Downgrade der Verbindung nach 60 Sekunden, 

bewirkt die Verwendung eines dynamischen RAB Upgrades eine ca. 64%ige Verkürzung 

der Zeit für den Download. 

Aus Sicht der Nutzer wäre, in dem gegebenen Anwendungsfall, ein dynamischer 

Upgrade sehr positiv, da die gewünschte Datei schneller heruntergeladen wäre. Aus 

Sicht des Netzes werden physikalische Ressourcen schneller wieder freigegeben und 

wären somit für andere Nutzer verfügbar. Eine Ressource wäre z.B. ein SC, der nun 

für andere Nutzer verwendet werden kann. 



Da der RAB Upgrade keine erkennbaren Nachteile hat, sollte er aktiviert werden um 

die gesamte Performance des Netzes zu verbessern. 

5.3 Parameteroptimierung (RNC) 


Da im Testbed von O2(Germany) ein Nortel RNC für Tests zur Verfügung steht, sollte 

in einigen Tests herausgefunden werden, inwieweit eine Optimierung der Parameter 

des RLC-Protokolls, zwischen RNC und Mobile, möglich sein kann. 

Nach den Testbed-Analysen wird eine Entscheidungsmatrix erstellt, mit welcher Hil- 

fe die erfolgversprechendsten Parameter ausgewählt werden. Mit diesen Parametern 

soll erneut getestet werden. 

5.3.2 Parametereinstellungen 

Tabelle 5.3: DlRlcAckMode Einstellungen 

Im Folgenden werden die Parameter erklärt, welche in den gesamten Tests verändert 

wurden. Dabei soll auf die Funktion der einzelnen Parameter eingegangen und die 

eingestellten Werte analysiert werden. Da die gesamten Parameter für jeden einzelnen 

RAB einzeln geändert werden können, sollen nur die Einstellungen der verwendeten 



RAB untersucht werden, des 384 kbit/s RAB im Downlink und des 64 kbit/s RAB im 

Uplink. 

Funktion der Parameter 

Die beiden Tabellen zeigen die aktuellen Einstellungen der RLC-Parameter für den 

DlRlcAckMode (Download RLC Acknowledge Mode) [Tab. 5.3] und den UlRlcAckMode 

(Upload RLC Acknowledge Mode) [Tab. 5.4]. Beide Parametersets entsprechen den 

aktuellen Einstellungen des Live-Netzes. 

rlcConfClass.rdnId 

Tabelle 5.4: UlRlcAckMode Einstellungen 

Dieser Wert gibt die Klasse an, in welcher die Parameter konfiguriert sind. Dieser 

Wert kann nicht geändert werden und wird dazu verwendet in der Nortel-Software die 

Einstellungen am richtigen RAB zu tätigen. Zur näheren Beschreibung der Klasse wird 

die userSpecificInfo genutzt. 

epctimer 

Dieser Timer kann nur verwendet werden, wenn er in höheren Schichten konfiguriert 

und verwendet wird. Mit ihm ist es möglich die RTT zu bestimmen. Ähnlich wie mit 



PING, wird hier nach dem Senden eines Status-Paketes ein Timer gestartet, der beim 

Empfangen einer Bestätigung gestoppt wird. 

Im Netz wird dieser Timer zurzeit nicht genutzt. Dieser Timer soll auch nicht ver- 

wendet werden. 

LastRetransPuPoll 

Wenn Pakete vom Sender zum Empfänger gesendet werden, werden diese im ”Re- 

Transmission”-Puffer gespeichert (Speicher für evtl. Übertragungswiederholungen). 

Kommt ein Paket am Empfänger an, wird ein positive Benachrichtigung an den 

Sender geschickt (”ACK”= Acknowledge) und das entsprechende Paket aus dem Puffer 

verworfen. 

Der Parameter lastRetransPuPoll kann nur die Werte TRUE oder FALSE annehmen. 

TRUE: 

Mit dem letzten Paket im ”Re-Transmission”-Puffer wird eine Anfrage geschickt 

(POLL), ob neue Pakete empfangen werden können. 

FALSE: 

Es wird keine Anfrage geschickt. 

Dieser Parameter steht aktuell auf FALSE. Es soll untersucht werden, ob durch die 

Übertragung der Anforderungen (POLL) in den Übertragungswiederholungen, eine Er- 

höhung des Durchsatzes beobachtet werden kann, da so nach Übertragungswiederho- 

lungen die Datenübertragung schnell fortgeführt werden kann. 

LastTransPuPoll 

Der Parameter lastTransPuPoll ist dem lastRetransPuPoll ähnlich. Hier wird die 

Anforderung mit dem letztem Paket der Übertragung aus dem ”Transmission”-Puffer 

verschickt. Im Gegensatz zum ”Re-Transmission”-Puffer, werden die gesendeten Pakete 

hier gleich nach dem Versenden verworfen, bleiben aber im ”Re-Transmission”-Puffer 

bestehen. 

Dieser Parameter ist auf TRUE gesetzt und soll nicht verändert werden. 

MaxData 

Gibt die maximale Anzahl für die Übertragungswiederholung einer PU an, bevor die 

entsprechende SDU dazu verworfen wird. Dieser Parameter wird durch eine ganze Zahl 



bestimmt, welche zwischen eins und vierzig liegen kann. 

Für den DL und den UL werden acht Wiederholungen, im 384 kbit/s RAB, zugelas- 

sen. Mit diesen Wert kann man sicher gehen, dass ein Problem vorliegt, welches nicht 

nur temporär ist. 

MaxNbrOfResetRetrans 

Damit wird die maximale Anzahl an Übertragungswiederholungen der ”Reset”-PDU 

angegeben. Die ”Reset”-PDU wird benutzt um alle Protokollzustände, -variablen und 

-timer zurückzusetzen. Damit wird eine Synchronisation erreicht. 

Dieser Parameter wird durch eine ganze Zahl zwischen 1 und 32 bestimmt. Er wird 

genauso wie maxData eingestellt. 

MisPuIndic 

Die vom Sender zum Empfänger übertragenen Pakete sind nummeriert. Sollte der 

Empfänger eine Paket vermissen, z.B. Empfang des ersten, des zweiten und anschlie- 

ßend des vierten Paketes, muss der Empfänger den Sender informieren, dass das dritte 

Paket vermisst wird. Dies kann auf zwei unterschiedlichen Arten geschehen. Entweder 

sendet der Empfänger eine Status-Benachrichtigung für jedes fehlende Paket einzeln 

oder es werden gesammelte Status-Benachrichtigungen erstellt. 

Der Parameter ist auf TRUE gestellt und übermittelt eine Benachrichtigung für jedes 

Paket einzeln. 

NbrOfPuBetweenPolling 

Dieser Parameter gibt an, in welchen Abständen der Sender den Empfänger abfragen 

soll, ob dieser neue Pakete empfangen kann. Die Abstände werden dabei durch die 

Anzahl der PUs bestimmt, welche übertragen werden. Dieser Parameter kann nur 

verwendet werden, wenn die Anfragen mit den PUs übertragen werden. 

Nach 128 PUs im Downlink und 64 PUs im Uplink, übermittelt der Sender ein 

Anfrage für neue Pakete. 

NbrOfSduBetweenPolling 

Genau wie bei NbrOfPuBetweenPolling wird auch hier der Abstand zwischen zwei 

Anforderungen durch die Anzahl von Paketeinheiten bestimmt. Hier sind es ganze 

SDUs, die bestimmt werden. Dieser Parameter kann nur verwendet werden, wenn die 

Anfragen mit einer SDU übertragen werden. 



Da die Anfragen z.Z. mit den PU übertragen werden, wird dieser Parameter nicht 

verwendet. 

PollingTimer 

Der PollingTimer, ist ein Timer, welcher den Zeitabstand in ms angibt, in der zwei 

Anfragen (Pollings) gesendet werden, unabhängig von Anfragen, welche anderweitig 

ausgelöst wurden. 

Dieser Timer steht auf 400 ms. Dies bedeutet, dass unter ungestörten Verhältnissen 

(keine Übertragungswiederholungen), nach der doppelten RTT eine neue Anforderung 

geschickt wird. 

PollWindow 

Beim Senden von Paketen wird die Fenstergröße verkleinert. Bei Erreichen einer be- 

stimmten Fenstergröße soll eine Anforderung an den Empfänger geschickt werden, so 

dass ein unterbrechungsfreies Übertragen gewährleistet werden kann. Der Parameter 

soll einen prozentualen Teil der gesamten Fenstergröße angeben, bei welcher die An- 

forderung ausgelöst wird. 

Der Parameter ist auf 80% der maximalen Fenstergröße (transmissionWindowSize) 

eingestellt. Ein größerer Wert würde dazu führen, dass Anforderungen zu spät geschickt 

werden und so evtl. keine Pakete übertragen werden können, was zu einen niedrigeren 

Durchsatz führt. 

ProhibitedPollingTimer 

Der prohibitedPollingTimer gibt die kleinste Zeit vor, in welcher keine Anforderung 

gesendet werden darf. Dieser Parameter sollte auch in Zusammenhang mit der RTT 

des Mobilfunknetzes betrachtet werden. 

Der Parameter ist mit 20 ms auf ca. ein Zehntel der RTT des Mobilfunknetzes ein- 

gestellt. Dies bedeutet, dass während einer RTT zehn Anforderungen gesendet werden 

können, bevor die erste Anforderung überhaupt beantwortet werden kann. 

ProhibitedStatusTimer 

Die ”Status”-Benachrichtigungen werden vom Empfänger an den Sender geschickt um 

den Erhalt eines oder mehrerer Pakete zu quittieren. Der prohibitedStatusTimer 

gibt an, in welchen minimalen Abständen diese Benachrichtigungen gesendet werden 

dürfen. 



Die eingestellten 200 ms entsprechen der RTT eines UMTS-Mobilfunknetzes. 

ReceptionWindowSize 

Gibt die maximale Anzahl an PU an, welche am Empfänger empfangen werden kann. 

Typischerweise entspricht die receptionWindowSize gleich der transmissionWindow- 

Size, so dass maximal soviele Pakete gesendet wie empfangen werden können. 

Die im Downlink eingestellten 768 (384 kbit/s RAB) und im Uplink eingestellten 256 

(64 kbit/s RAB) PU entsprechen einen Vielfachen, der jeweiligen minimalen Datenrate. 

ResetTimer 

Dieser Timer soll den Verlust der bestätigten ”Reset”-PU feststellen und diese erneut 

anfordern, um eine erneute Synchronisation zu gewährleisten. 

Der Timer ist auf 500 ms eingestellt, was das zweieinhalb-fache der RTT entspricht. 

Da eine maximale Anzahl an wiederholten Übertragungen festgelegt ist (maxNbrOfRe- 

setRetrans), wird damit sicher gegangen, dass die ”Reset”-PU mit großer Wahrschein- 

lichkeit verloren gegangen ist. 

TimerPollPeriod 

Dieser Timer soll dazu genutzt werden, periodisch Anforderungen zu senden. Wenn 

der Timer abgelaufen ist, soll er wieder zurückgesetzt werden. Der Timer soll auch 

zurückgesetzt werden, bei gleichzeitigem Senden einer neuen Anforderung, wenn Pakete 

zur Übertragung oder zur wiederholten Übertragung vorhanden sind. 

Dieser Timer wird zurzeit nicht genutzt. 

TimerStatPeriod 

Ähnlich wie der timerPollPeriod, gibt dieser Parameter die Möglichkeit, die ”Status”- 

Benachrichtigungen periodisch zu übertragen. Dieser Timer wird nur zurückgesetzt 

wenn eine ”Status”-Benachrichtigung übermittelt wurde. 

Der Wert dieses Parameters wird vom RRC festgelegt und übermittelt. 

TransmissionWindowSize 

Dieser Parameter gibt die Menge an PUs an, welche vom Sender maximal gesendet 

werden können. Ist diese Menge gesendet worden und noch keine Bestätigung vom 



Empfänger eingegangen, ist das Fenster null und es können keine Pakete mehr gesendet 

werden. 

Dieser Wert ist auf den selben Wert eingestellt wie die receptionWindowSize. 

UserSpecificInfo 

Dieser ”Wert” ist nur als Information für den Nutzer gedacht, welcher Änderungen 

vornehmen möchte, da hier die exakte Bezeichnung des RAB eingetragen ist. Somit 

können die Einstellungen spezifisch vorgenommen werden. 

Live-Netz 

Dieser Parameter wird bei den Messergebnissen verwendet, er stellt den Referenzwert 

ohne Änderung von Parametern dar. 

5.3.3 Testbed-Analysen 

Angleichung Live-Netz - Testbed 

Tabelle 5.5: Angleich Testbed - Live-Netz 

Zu Beginn der Tests musste eine Änderung relevanter Parameter im Testbed voll- 

zogen werden, um die Änderungen auch zum Live-Netz in Bezug bringen zu können. 

Die Tabelle zeigt die Änderungen, die getätigt wurden, um das Testbed dem Live-Netz 

anzupassen [Tab. 5.5]. Bei den Änderungen wurden nur Parameter des DlRlcAckMode 

und des UlRlcAckMode betrachtet, da diese Parametersets in den anschließenden Tests 

geändert werden sollen. Eine Änderung der gesamten Parameter des RNCs ist nicht 

nötig, da die Tests der einzelnen Parameter unabhängig von den anderen Parametern 

eine Änderung bewirken. 



Änderungen der Parameter 

Die folgenden beiden Tabellen [Tab. 5.6 und 5.7] zeigen die eingestellten und getesteten 

Parameteränderungen im Testbed. Der Wert in der ersten Zeile gibt an, welcher Pa- 

rameter eingestellt war und der Wert in der zweiten Reihe gibt an, welcher eingestellt 

werden soll. Es werden nur Änderungen der orange unterlegten Felder vorgenommen. 

Nachdem ein Parameter geändert wurde, wird dieser wieder auf seinen ursprüng- 

lichen Wert zurückgesetzt um ein Zusammenwirken verschiedener Parameter auszu- 

schließen. 

Tabelle 5.6: DlRlcAckMode Änderungen 

Tabelle 5.7: UlRlcAckMode Änderungen 



Parameteränderung: LastReTransPuPoll 

Erwartungen 

Änderung von FALSE auf TRUE auf dem 384 kbit/s RAB. Da so mit dem Verschicken 

einer Übertragungswiederholung die nächste Anforderung für Pakete versendet wird, 

wird erwartet, dass die Übertragungsrate geringfügig steigt. 

Ergebnisse 

Wie in Tab. 5.8 zu sehen, ist die Veränderung durch die Umstellung kaum zu erkennen. 

Dieser Parameter wird durch die Übertragungswiederholungen beeinflusst. Wenn mehr 

Übertragungswiederholungen gesendet werden müssen, ist davon auszugehen, dass die 

Veränderung eine Erhöhung des Durchsatzes bewirken. 

Parameteränderung: NbrOfPuBetweenPolling 

Erwartungen 

Änderung von 128 auf 64 für den 384 kbit/s RAB im Downlink. Durch die Änderung 

wird die Anforderung für neue PU häufiger gesendet. 

Ergebnisse 

Es wurde festgestellt, dass für einige Anwendungen (FTP, HTTP) das Resultat gering- 

fügig besser wurde und sich der Durchsatz leicht erhöhte. [Tab. 5.8] 

Parameteränderung: PollingTimer 

Erwartungen 

Durch die Änderung des PollingTimer von 400 auf 450 auf dem 384 kbit/s RAB im 

DlRlcAckMode und von 400 auf 300 auf dem 64 kbit/s RAB im UlRlcAckMode sollen 

die Anforderungen, entsprechend der Geschwindigkeit des RAB, angepasst werden. Es 

ist anzunehmen, dass die Hardware im nodeB die ankommenden Daten vom Mobile 

schneller verarbeiten kann, als umgekehrt. So wird dem Mobile im Downlink mehr Zeit 

gegeben. 

Ergebnisse 

Die Ergebnisse für der verschiedenen Anwendungen sind in Tabelle 5.8 zu sehen. Der 

PollingTimer bewirkt eine Verbesserung des Durchsatzes für die getesteten FTP- 



Verbindungen. 

Parameteränderung: ProhibitedPollingTimer 

Erwartungen 

Die hier getätigte Änderung von 20 ms auf 200 ms für den 384 kbit/s RAB im Down- 

link und den 64 kbit/s RAB im Uplink, soll eine Überflutung des Kanals verhindern. Da 

bei der aktuellen Einstellung theoretisch alle 20 ms Anforderungen geschickt werden 

können, die RTT im UMTS-Netz aber 200 ms beträgt, könnten zehn Anforderungen 

verschickt werden, bevor die Antwort der Ersten ankommen kann. Die Änderung soll 

den Kanal, den Sender und den Empfänger entlasten. Es wird weiterhin erwartet, dass 

durch die freigewordenen Ressourcen eine Erhöhung des Durchsatzes zu sehen sein 

wird. Die freigewordenen Ressourcen können auch für andere Verbindungen genutzt 

werden. 

Ergebnisse 

Es erfüllten sich die Erwartungen, so sind auch hier geringfügige Verbesserungen des 

Durchsatzes zu erkennen. Die Ergebnisse für alle Anwendungen sind in Tabelle 5.8 zu 

sehen. 

Parameteränderung: ProhibitedStatusTimer 

Erwartungen 

Die Veränderung von 200 ms auf 300 ms bewirkt, dass beim Sender mehr Datenpakete 

gleichzeitig bestätigt werden können. Somit wird Verkehrslast vom Kanal genommen, 

welche wiederum für Datenübertragung zur Verfügung steht. 

Ergebnisse 

In Tabelle 5.8 sind die Ergebnisse zu sehen. Auch hier sind wieder, bei bestimmten 

Anwendungen, geringfügige Erhöhungen des Durchsatzes zu erkennen. 

Parameteränderung: TransmissionWindowSize & ReceptionWindowsize 

Erwartungen 

Änderung von 768 auf 1024 für den 384 kbit/s RAB im DlRlcAckMode und von 256 

auf 512 für den 64 kbit/s RAB im UlRlcAckMode. Durch die hohe RTT des Mobil- 



funknetzes kann es vorkommen, dass eine Empfangsbestätigung stark verzögert oder 

unter Umständen gar nicht ankommt. Dadurch kann die Fenstergröße auf null sinken 

und keine weiteren Pakete können gesendet werden. Wenn man nun die Fenstergröße 

erhöht, können so Durchsatz-Einbrüche verhindert werden. 

Ergebnisse 

Die Erhöhung der Fenstergröße wurde nur für den Download der 512 kbyte und den 

Upload der 64 kbyte Datei getestet. Bei beiden Tests konnte keine klares Ergebnis 

festgestellt werden. Die Ergebnisse sind in Tabelle 5.8 eingetragen. 

Tabelle - Ergebnisse 

Tabelle 5.8: Ergebnisse der Messungen im Testbed von O2(Germany) 

Betrachtet man die Messungen, stellt man fest, dass keine Anwendung und / oder 

Parameteränderung ein aussagekräftiges Ergebnis liefert. Die Gründe hierfür liegen 

in dem Verhältnissen im Testbed, diese sind ideal. Es gibt keine Störungen, keine 

Interferenzen und somit z.B. eine geringe Wahrscheinlichkeit auf Übertragungswieder- 

holungen. Die Ergebnisse sollen somit grundlegend nur als Richtlinie für weitere Tests 

dienen. Dazu wird die Entscheidungsmatrix [Tab. 5.9] verwendet, an welcher sich, für 

die folgenden Messungen im Live-Netz, orientiert werden soll. 

Betrachtet man die Nicht-Echtzeitanwendungen, erkennt man, dass einige Parame- 

terveränderungen eine Änderung des Ergebnisses im Zehntel-Bereich einer Sekunde 

ausmachen (z.B. die Veränderungen ”FTP DL 512”). 



Bei den Echtzeitanwendungen (VoIP, Videostream), wurde aus Zeitgründen, die Mes- 

sung nach konstant zwei Minuten abgebrochen (durch Romes festgelegt). Die Ergebnis- 

se des Videostreams zeigen die gleichen positiven Veränderungen im Downlink durch 

den ProhibitedPollingTimer und den PollingTimer wie die anderen Anwendungen. 

Bei VoIP stellt scheinbar jede Parameterveränderung eine Verbesserung des Durchsatz- 

es dar. Der niedrige Wert der Referenz-Messung wurde daraufhin erneut im Testbed 

getestet, das Ergebnis blieb das gleiche. Weitere Tests im Live-Netz sollen dieses Er- 

gebnis verifizieren. 


Tabelle 5.9: Entscheidungsmatrix Testbed 

Mit Hilfe dieser Entscheidungsmatrix, sollen Parameter gewählt werden, welche in 

der folgenden Live-Netz-Messung weiterhin getestet werden sollen. Darunter fällt vor 

allem der ProhibitedPollingTimer und der PollingTimer, etwas schwächer fällt der 

Parameter NbrOfPuBetweenPolling aus, dieser wird auch in die Live-Netz-Messung 

mit einbezogen. Die gewählten Parameter sollen sowohl im Uplink als auch im Down- 

link, abweichend von den differierenden Ergebnis des Testbeds, im Live-Netz getestet 

werden. 



5.3.4 Erste Live-Netz-Messung 

Abbildung 5.10: Teststrecke Live-Tests 

Für die Live-Netz-Messungen musste mit Region Süd von O2(Germany) ein Abspra- 

che über den Termin und den Ort stattfinden. Die verwendete Zelle befindet sich in 

der Nähe des Ostbahnhofs von München (Stadtteil Perlach). Die ausgewählte Mess- 

strecke bietet konstante Funkverhältnisse und ist ausreichend kurz um alle benötigten 

Messungen innerhalb der vorgegebenen Zeitraums zu bewältigen [s. Abb. 5.10]. 

Auch bei diesen Messungen sollen immer nur einzelne Parameter geändert werden, 

so dass nicht zwei Parameter zur gleichen Zeit geändert sind. Jede Parameteränderung 

wird einzeln von der Region Süd vorgenommen. Die Änderungen werden per Telefon 

angewiesen. 


Die ausgewählten Änderungen sind der Entscheidungsmatrix [Tab. 5.9] der Testbed- 

Analysen zu entnehmen. Des Weiteren soll noch der Parameter MisPuIndic für die 

Messungen im Live-Netz verwendet werden. In den nachfolgenden Tabellen [Tab. 5.10 

und 5.11] sollen die verschiedene Einstellungen gezeigt werden. 



Ergebnisse 

Tabelle 5.10: DlRlcAckMode Änderungen für erste Live-Tests 

Tabelle 5.11: UlRlcAckMode Änderungen für erste Live-Tests 

Bei den nachfolgenden Analysen sind die Parameterveränderungen, zu Gunsten der 

Übersicht, mit Zahlen beschriftet, welche folgende Bedeutung haben: 

• 00: Ergebnis ohne Veränderung (Referenzmessung) 

• 01: (Downlink) MisPuIndic 

• 02: (Downlink) NbrOfPuBetweenPolling 

• 03: (Downlink) PollingTimer 

• 04: (Downlink) ProhibitedPollingTimer 

• 05: (Downlink) Transmission & ReceptionWindowSize 

• 06: (Uplink) MisPuIndic 

• 07: (Uplink) NbrOfPuBetweenPolling 

• 08: (Uplink) PollingTimer 

• 09: (Uplink) ProhibitedPollingTimer 

• 10: (Uplink) Transmission & ReceptionWindowSize 



Ergebnisse TCP-FTP und TCP-HTTP 

Abbildung 5.11: FTP 8192 kbyte (DL), 

Durchsatz 

Abbildung 5.13: FTP 64 kbyte (UL), 

Durchsatz 

Abbildung 5.12: FTP 512 kbyte (DL), 

Durchsatz 

Abbildung 5.14: HTTP 512 kbyte (DL), 

Durchsatz 

Es ist zu erkennen [Abb. 5.11 - 5.14], dass die Parameteränderungen 4 und 9 eine 

Verbesserung der Übertragung und des Durchsatzes bewirken, auch der Parameter 8 

enthält eine positive Veränderung. Die anderen Parameter bewirken bei den getesteten 

Anwendungen über FTP eine allgemeine Verschlechterung, bzw. unterscheiden sich 

diese Ergebnisse nicht stark von der Referenzmessung. 

Eine interessante Feststellung lässt sich bei dem ProhibitedPollingTimer beobach- 

ten, da eine Veränderung dieses Parameters im Downlink oder im Uplink eine Erhöhung 

des Durchsatzes bewirkt. Dies ist durch die geringere Anzahl an Anforderungen in dem 

Kanal möglich. 

Allgemein konnte eine Verbesserung der Nicht-Echtzeitanwendungen festgestellt wer- 

den. Die Ergebnisse in tabellarischer Übersicht sind unter Tabelle 5.12 zu finden. 



Ergebnisse UDP-VoIP und UDP-Streaming 

Abbildung 5.15: Durchsatz, Videostream Abbildung 5.16: Pakete, Videostream 

Bei der Betrachtung des Videostreaming-Durchsatzes [Abb. 5.15] konnten hinsicht- 

lich der getesteten Parameter keine Verbesserungen festgestellt werden. Allgemein ist 

zu erkennen, dass alle Ergebnisse stark in ihren Werten schwanken. Dies kann nur 

dadurch erklärt werden, dass nicht ausreichend viele Messungen mit Videostreaming 

durchgeführt wurden, um ein aussagekräftiges Ergebnis zu liefern. 

Es ist davon auszugehen, dass Paket- 

verluste auftraten, da diese aber nicht 

mit den vorhandenen Mitteln bestimm- 

bar waren, soll mit Hilfe der Anzahl 

ankommender Pakete [Abb. 5.16] even- 

tuell ein Zusammenhang, zwischen die- 

sen und den stark differierenden Durch- 

satz, gefunden werden. Bei jeder Mes- 

sung werden im Durchschnitt zwischen 

7000 und 8700 Pakete empfangen. Ein 

aussagekräftiger Zusammenhang, zwi- 

Abbildung 5.17: Pakete, Videostream 

schen der Anzahl empfangener Pakete und dem Durchsatz ist nicht herstellbar. Es 

ist zu sehen, dass der Durchsatz bei geringerer Anzahl empfangener Pakete niedriger 

wird. Allerdings trifft dies nicht auf alle Messungen zu (z.B.: Vgl. Parameter 02 und 

03). 

Auch aus den VoIP Daten (Skype) lassen sich nur wenige Informationen gewinnen. 

Denn genau wie bei dem Videostreaming schwanken die Ergebnisse zu stark, so dass 

die Wirkung der Parameterveränderung nicht hundertprozentig herausgefiltert werden 



Abbildung 5.18: VoIP (DL), Durchsatz Abbildung 5.19: VoIP (UL), Durchsatz 

kann [Abb. 5.18, 5.19]. Betrachtet man hier die Anzahl empfangener Pakete [Abb. 

5.17], im Zusammenhang mit dem gemessenen Durchsatz im Downlink, lässt sich eine 

Korrelation feststellen, allerdings reichen auch hier die gesammelten Daten nicht aus, 

um ein eindeutiges Ergebnis, hinsichtlich der vorgenommenen Parameteränderungen, 

zu erkennen. 

Hinsichtlich der Optimierung der Echtzeitanwendungen konnte mit Hilfe der getä- 

tigten Messungen kein aussagekräftiges Ergebnis gewonnen werden. Die Ergebnisse der 

gesamten Messung sind unter Tab. 5.12 zu finden. 

Ergebnisse der ersten Live-Netz-Messung 

Tabelle 5.12: Ergebnisse der ersten Live-Netz-Messung 



Diese Tabelle stellt eine Übersicht über die erste Messung im Live-Netz dar. Es 

sollen hier nur die Ergebnisse für die Durchsatz-Messung dargestellt werden, da diese 

repräsentativ für die gemessenen Kriterien sind. 

Wie hier gut zu erkennen ist, bewirkt der ProhibitedPollingTimer sowohl im Dow- 

nlink als auch im Uplink eine Verbesserung des Durchsatzes für die getesteten Anwen- 

dungen. Um die Ergebnisse besser deuten zu können, soll der Grad der Optimierung 

für die einzelnen Messungen, entsprechend der Parameteränderung, bestimmt werden. 



Die Tabelle 5.13 zeigt die prozentuale Optimierung einer Veränderung gegenüber 

dem Referenzwert an. Im Downlink können maximal 384 kbit/s zur Verfügung stehen 

und im Uplink 64 kbit/s. Für den Videostream wurde als Maximum die Kodierung des 

Videos ausgewählt, welche 120 kbit/s beträgt. Da bei den Tests mit VoIP keine feste 

Durchsatzrate feststellbar ist, wird die Optimierung hinsichtlich der Referenzmessung 

errechnet. 

Hier ist sehr gut zu erkennen, dass der ProhibitedPollingTimer eine Verbesserung 

der Nicht-Echtzeitanwendungen um ca. 18% bewirkt. Auch die Veränderung des Pol- 

lingTimer bewirkt eine 9%ige Verbesserung des Übertragungsverhaltens. Die höchste 

Steigerung wurde beim Download einer 512 kbyte Datei über FTP gemessen, Dort 

kam es durch die Veränderung des ProhibitedPollingTimer zu einer Verbesserung 

des Übertragungsverhaltens von 37,6%. 

Bei den Echtzeitanwendungen ist im Downlink auch eine Verbesserung des Übertra- 

gungsverhaltens zu erkennen, auch hier wird diese durch die Veränderung des Prohi- 



bitedPollingTimer hervorgerufen. 


Tabelle 5.14: Entscheidungsmatrix 

Aus den Ergebnisse der vorhergehenden Analysen soll wiederum eine Entscheidungs- 

matrix erstellt werden. Mit dessen Hilfe sollen die besten Parameter ausgewählt wer- 

den. Es wurden drei Parameter, der ProhibitedPollingTimer im Downlink und im 

Uplink und der PollingTimer im Uplink, ausgewählt, da diese ∼50% und mehr der 

maximalen erreichbaren Punkte erhielten. Diese drei Parameter [Tab. 5.14] sollen er- 

neut im Live-Netz getestet werden, um eine Verifizierung des Ergebnisses zu erlangen 

[Kapitel 5.3.5]. 

5.3.5 Zweite Live-Netz-Messung 


Die zu ändernden Parameter sind den Tabellen 5.15, 5.16 und 5.17, resultierend aus der 

Entscheidungsmatrix [Tab. 5.14] zu entnehmen. Diese Ergebnisse sollen nun verifiziert 

und einer aufbauenden Messung unterzogen werden. Bei der aufeinander aufbauenden 

Messung sollen die bereits geänderten Parameter nicht zurückgestellt werden. So soll 



gezeigt werden, ob alle Parameter zusammen eine bessere Optimierung bewirken, als 

die einzelnen Parameter für sich alleine. 

Messergebnisse 

Anhand des Downloads, einer 512 

kbyte Datei, über FTP sollen hier die 

Ergebnisse erläutert werden. Wie in 

Abb. 5.20 und 5.21 zu erkennen ist, 

bewirkt jede Veränderung eine Ver- 

besserung des Übertragungsverhaltens. 

Das diese Verbesserung unabhängig 

von der Anzahl empfangener Pakete 

ist, ist an Abb. 5.22 zu erkennen. Die 

Anzahl schwankt zwischen 365 und 

368 empfangenen Paketen. Weder diese 

Tabelle 5.15: Änderung 1 für Live-Test 



Abbildung 5.20: Durchsatz, FTP DL 512 

Schwankungen noch die Übertragungswiederholungen können das Ergebnis beeinflus- 

sen, da eine Veränderung der Anzahl von 367 auf 365 Pakete nicht zu einer Änderung 



Abbildung 5.21: Durchsatz, FTP DL 512 

Abbildung 5.22: Pakete, FTP DL 512 

von 280,8 kbit/s auf 320,4 kbit/s führen kann. Die Übertragung der 512 kbyte Datei 

wird um ca. 1,8 Sekunden verkürzt. 

Auch bei den Echtzeitanwendungen (Videostreaming) wirken sich die Parameterver- 

änderungen positiv auf das Übertragungsverhalten aus [Abb. 5.23]. Hier werden mit 

der Änderung 3 ca. 160000 byte mehr übertragen, als ohne die Änderung. Durch die frei 

gewordenen Ressourcen wird somit auch die Wahrscheinlichkeit für einen Paketverlust 

gesenkt. 

Eine gesamte Übersicht der Ergebnisse ist in der Tabelle 5.18 zu sehen. 

Abbildung 5.23: Vergleich empfangener Datenmenge, Videostreaming 



Ergebnisse 

Tabelle 5.18: Ergebnisse der zweiten Live-Netz-Messung 

Allgemein verbesserte sich das Übertragungsverhalten aller Anwendungen. Um eine 

bessere Übersicht der Ergebnisse zu bekommen, soll wiederum eine prozentuale Aus- 

wertung der Ergebnisse gemacht werden. 



Die aufeinander aufbauenden Messungen bewirken eine Verbesserung des Übertra- 

gungsverhaltens der Nicht-Echtzeitanwendungen um insgesamt 16% [Tab. 5.19]. Die 

stärkste Veränderung trat wieder bei dem Herunterladen einer Datei über FTP auf, 

dort wurde das Übertragungsverhalten um 38% verbessert. 

Bei den Echtzeitanwendungen konnte auch, gemessen an der gewählten Referenz, 

eine Verbesserung festgestellt werden. Bei VoIP wird bei der Berechnung der prozen- 

tualen Optimierung nur von der Referenzmessung ausgegangen. 



5.3.6 Fazit 

Anhand der gewonnenen Ergebnisse aus dem zweiten Live-Netz-Test wird empfoh- 

len, die Parameteränderungen dauerhaft in das Live-Netz von O2(Germany) zu inte- 

grieren. Aus den Ergebnissen lässt sich entnehmen, dass die Optimierung der Nicht- 

Echtzeitanwendungen vordergründig war, da hierfür bessere Messmittel zur Verfügung 

standen. Die Ergebnisse der Echtzeitanwendungen sind somit nur bedingt als Kriterien 

für der Güte der getätigten Optimierung anzusehen. 

Folgende Parameteränderungen wurden für die getesteten RAB vorgeschlagen [Tab. 

5.20]. Allgemein lassen sich diese Ergebnisse nicht auf die anderen RAB übertragen. 

Für die Verwendung der Werte auf anderen RAB wird empfohlen, diese Werte vorher 

zu verifizieren und evtl. anzupassen. 

Tabelle 5.20: Empfohlene Einstellungen 

5.4 Aktivierung der ”Streaming”-Klasse (HLR) 


Um die ”Streaming”-Klasse zu testen, muss ein entsprechender APN konfiguriert wer- 

den und es müssen entscheidende QoS-Parameter eingestellt werden (z.B.: Garantierte 

Bandbreite). Anschließend sollen im Testbed Messungen mit den gewählten Echtzeit- 

anwendungen gemacht werden. Es soll auch die Wirkung der Aktivierung dieser Ver- 

kehrsklasse auf die Nicht-Echtzeitanwendungen getestet werden. 

5.4.2 Parametereinstellungen 

Parameter des APN 

Für die Referenzmessung wird hier der APN ”internet-tb” genutzt, welcher wie folgt 

konfiguriert ist [Tab. 5.21]. In der zweiten Spalte sind die veränderten Parameter ein- 



getragen, welche den Spezifikationen der ”Streaming”-Klasse entsprechen und für den 

APN ”streaming-tb” konfiguriert wurden. 

Da für die Nortel Hardware nur ein 128 kbit/s RAB für die ”Streaming”-Klasse kon- 

figuriert werden kann, soll für den Referenz-RAB, auch ein 128 kbit/s RAB verwendet 

/ konfiguriert werden. 

Tabelle 5.21: Einstellung der APNs für die ”Streaming”-Klasse 

Allocation/Retention Priority 

Spezifiziert die Priorität bei der Zuweisung und Beibehaltung des RAB, gegenüber 

anderen RAB. Beide APNs besitzen hier die Priorität 2, werden also bei der Zuweisung 

und der Beibehaltung von RAB nicht einander bevorzugt. 

Traffic Class 

Die Verkehrsklasse an sich wird hier als Attribut hinzugefügt und gibt an für welche 

Anwendungen der RAB optimiert ist. 

Delivery Order 

Dieser Parameter zeigt an, ob die SDU-Pakete in der richtigen Reihenfolge eintreffen 

sollen (”YES”), oder nicht (”NO”). Bei beiden APNs wird keine korrekte Reihenfolge 

für den Empfang vorausgesetzt. 



Delivery of Erroneous SDU 

Gibt an ob eine SDU ausgeliefert werden soll, wenn Fehler in dieser festgestellt wurden 

(”YES”). Wenn die SDU nicht ausgeliefert werden soll, wird dieser Parameter auf ”NO” 

gesetzt. Die Einstellung für die beiden APNs ist gleich, fehlerhafte SDUs sollen nicht 

ausgeliefert werden. 

Maximum SDU Size 

Definiert die maximale Größe der SDUs. Beide APNs sind hier auf 1500 eingestellt, 

welches auch der Standardgröße der MTU-Paketgröße entspricht. Wird benötigt, damit 

das Netzwerk die ausgehandelte QoS erfüllen kann. 

Maximum Bit Rate for Uplink & Downlink 

Definiert die maximale Datenmenge, die während einer bestimmten Periode, geteilt 

durch die Länge der Periode, geliefert werden kann. Mit der Festlegung der maximalen 

Datenrate auf 128 für beide APNs im Downlink und im Uplink wird somit festgelegt, 

dass ein 128 kbit/s RAB verwendet wird. 

Residual Bit Error RateBER 

Definiert wie viele unerkannte Bitfehler in den ausgelieferten SDUs maximal enthalten 

sein dürfen, um die ausgehandelte QoS zu garantieren. Die Einstellung ist für beide 

APNs gleich und beträgt 10 −5 , was bedeutet, dass bei der Übertragung von 10 5 Bits 

höchstens 1 unerkannter Fehler auftreten darf. 

SDU Error Ratio 

Gibt die Anzahl von SDUs an, welche als verloren oder fehlerhaft erkannt wurden. Die 

Einstellung für beide APNs beträgt hier 10 −4 , was bedeutet, dass bei der Übertragung 

von 10 4 SDUs nur 1 SDU verloren gegangen oder als fehlerhaft detektiert werden darf. 

Transfer Delay 

Definiert die maximale Verzögerung von 95% einer SDU, um die ausgehandelte QoS ein- 

zuhalten. Die Einstellung für die ”Interactive”-Klasse beträgt hier null, dies bedeutet, 

dass keine Verzögerungszeit vorgegeben ist. Für diese Nicht-Streaming-Anwendungen 

können Pakete im Fall einer starken Verzögerung erneut übertragen werden. Bei den 



Streaming-Anwendungen, welche über UDP laufen, können keine Pakete erneut über- 

tragen werden, somit wird hier eine maximale Verzögerungszeit angegeben (4000 ms). 

Bei diesen Einstellungen wird von einer Pufferung am Empfänger ausgegangen. 

Traffic Handling Priority 

Hiermit wird festgelegt, wie entsprechende SDUs bei dem Transport, gegenüber ander- 

en SDUs, priorisiert werden. Die Priorität für die ”Streaming”-Klasse wird höher fest- 

gelegt, als die der ”Interactive”-Klasse. Somit wird in Lastsituationen der Streaming- 

Verkehr priorisiert um die geforderte Dienstgüte einzuhalten. 

Guaranteed Bit Rate for Uplink & Downlink 

Definiert die garantierte Datenmenge, welche während einer bestimmten Periode, ge- 

teilt durch die Länge der Periode, geliefert werden kann. Mit der Festlegung der Da- 

tenrate auf 128 für den ”Streaming”-Klasse APN im Uplink und im Downlink wird 

die festgelegte Übertragungsrate des RAB garantiert, um so die geforderte Dienstgüte 

einzuhalten. 

Der ”Interactive”-Klasse wird keine garantierte Bitrate zugesagt. Im Fall einer Über- 

lastsituation werden Anwendungen dieses APNs auf eine minimale Bitrate herunter- 

gesetzt oder unterbrochen. 

5.4.3 Testbed-Messung 

Es folgen die Analysen der Messungen, welche im Testbed durchgeführt wurden. Hier- 

bei soll, neben den Betrachtungen der Echtzeitanwendungen, auch die Nicht-Echtzeitan- 

wendungen mit betrachtet werden. Es soll herausgestellt werden, ob die ”Streaming”- 

Klasse die Nicht-Echtzeitanwendungen eventuell negativ beeinflussen. 

Ergebnisse für Nicht-Echtzeitanwendungen 

Betrachtet man hier die Ergebnisse für den Durchsatz der Nicht-Echtzeitanwendungen 

[Abb. 5.24], kann man durch die veränderte Verkehrsklasse keinen Unterschied feststel- 

len. Die festgestellten Unterschiede betragen weniger als 1% und sind somit vernach- 

lässigbar. 

Bei den getätigten Messungen hat die ”Streaming”-Klasse keine Auswirkungen auf 

die Nicht-Echtzeitanwendungen. Allerdings muss hierbei beachtet werden, dass die 

Tests unter idealen Bedingungen stattfanden und keinesfalls von einer Lastsituation 



Abbildung 5.24: Auswirkungen auf Nicht-Echtzeitanwendungen, Durchsatz 

ausgegangen werden kann. In der verwendeten Zelle im Testbed befindet sich nur das 

verwendete Mobile. 

Die Nicht-Echtzeitanwendungen werden unter den getesteten Umständen gleich prio- 

risiert, der APN ist der Gleiche. Es ist davon auszugehen, dass bei einer höheren Last 

die Nicht-Echtzeitanwendungen mit dem ”Streaming” APN, durch die höhere Priori- 

sierung, bessere Ergebnisse als mit dem ”Interactive” APN liefern. 

Ergebnisse für Echtzeitanwendungen 

Abbildung 5.25: Ergebnis Streaming, 

Durchsatz 

Abbildung 5.26: Ergebnis Streaming, Datenmenge 

Bei den Ergebnissen zu den Echtzeitanwendungen stellte sich eine starke Differenz 

zwischen dem Download eines Videos (Streaming) und der Sprachübertragung über 



VoIP heraus. Während die Veränderung der Verkehrsklasse bei dem Streaming eine 

Verbesserung bewirkte [Abb. 5.25 und 5.26], bewirkte es bei den Messung mit VoIP 

eine Verschlechterung [Abb. 5.27, 5.28, 5.29]. 

Bei VoIP wird sowohl der Uplink 

als auch der Downlink genutzt, bei 

Streaming typischerweise aber nur in 

eine Richtung gestreamt. Somit ist die 

Optimierung auch nur für Streaming- 

Anwendungen verwendbar, in welchen 

auch ein Puffer für die relativ hoch 

eingestellte Verzögerung existiert. Bei 

VoIP-Anwendungen wird nicht gepuf- 

fert, dort wäre eine zulässige Verzö- 

gerung von 4000 ms eine Störung für 

den Nutzer. 

Abbildung 5.28: Ergebnis VoIP, Durchsatz 

Downlink 

5.4.4 Fazit 

Abbildung 5.27: Ergebnis VoIP, Datenmenge 

Abbildung 5.29: Ergebnis VoIP, Durchsatz 

Uplink 

Prinzipiell ist es, unter den getesteten Umständen, für die Nicht-Echtzeitanwendungen 

nicht bedeutend, welche Verkehrsklasse eingestellt ist [Tab. 5.22]. Dies gilt für den Fall 

das keine Lastsituation auftritt, da diese mit den vorhandenen Mitteln nicht simuliert 

werden konnte. Bei einer Lastsituation ist davon auszugehen, dass durch die niedrigere 

Priorisierung des ”Interactive” Verkehrs, die Ressourcen reduziert, Pakete verworfen 

und Verbindungen getrennt werden. 

Bei den Echtzeitanwendungen, welche auf Streaming basieren, macht es dagegen 




einen Unterschied, welche Verkehrsklasse verwendet werden soll. So ist bei reinem 

Streaming von Ton- und / oder Videodateien, die Einstellung des ”streaming-tb” vor- 

zuziehen, da dieser für Streaming-Anwendungen optimiert ist und auch bei Lastsitua- 

tionen eine bessere Übertragung gewährleisten wird. 

Eine Allgemeine Verwendung der ”Streaming”-Klasse wird nicht empfohlen. Da zum 

einen eine 6%ige Verbesserung nicht auschlaggebend ist und zum anderen verschiedene 

Anwendungen benutzt werden, welche mit dieser Verkehrsklasse nicht optimiert sind. 



6 Zusammenfassung / Ausblick 

Die Paketvermittlung gewinnt in der heutigen Zeit immer mehr an Bedeutung für 

Mobilfunknetze. Der Transport dieser Pakete wird durch Eigenschaften der Luftschnitt- 

stelle, Netzwerk- und Parametereinstellungen und durch Protokolle für die Übertra- 

gung beeinflusst. Abgesehen von der Luftschnittstelle, welche nicht veränderbar ist, 

kann man Parameter und Einstellungen ändern, um die Übertragung von Paketen zu 

optimieren. 

Abbildung 6.1: Übersicht über Endergebnisse der Konzepte 

Eine Optimierung innerhalb eines Mobilfunknetzes ist an verschiedenen Punkten 

möglich. Eine Möglichkeit ist die Anpassung der TCP/IP-Einstellungen im Endgerät 

(Laptop) des Nutzers. Hierbei wurde durch die Veränderung der Fenstergröße eine 

Verbesserung der Datenübertragung um bis zu 35% erreicht. Die Fenstergröße ist, da 

am Endgerät des Nutzers, nicht vom Mobilfunknetz aus veränderbar und kann nur von 

den Nutzern selber geändert werden. 

Eine weitere getestete Möglichkeit ist die Verwendung eines dynamischen RAB, wel- 

cher sich den äußeren Einflüssen der Funkschnittstelle besser anpasst und den RAB, je 

nach Zustand der Funkverhältnisse, wechseln kann. Die im Testbed getesteten Ergeb- 

nisse zeigen, dass bei dem generierten Szenario eine Verringerung der Download-Zeit 

um bis zu 64% möglich ist. Die Verwendung des dynamischen RAB ist die effektivste 

Möglichkeit, welche die Übertragung von großen Datenmengen in einem Mobilfunknetz 

optimieren kann, da sie sich am besten den unveränderbaren Parametern, den Funk- 

verhältnissen, anpasst. 



Die Veränderungen von Parametern im RLC-Protokoll führt auch zu einer Verbes- 

serung der Datenübertragung, im Einzelfall um bis zu 38%. Die Parameter wurden so 

geändert, dass sie den Gegebenheiten der Funkschnittstelle und allgemein dem Mobil- 

funknetz angepasst sind. Eine entsprechende Empfehlung für die Integration der ge- 

testeten Parameterveränderung wurde an O2(Germany) übermittelt. 

Durch die Verwendung eines APNs, in welcher die Verkehrsklasse ”Streaming” ver- 

wendet wird, konnte eine Verbesserung der Datenübertragung über Streaming um 6% 

festgestellt werden. Es wurden die Auswirkungen dieser Verkehrsklasse auch auf Nicht- 

Echtzeitanwendungen getestet, diese sind gering und damit vernachlässigbar. Die Ver- 

besserung der Übertragungseigenschaften mit dieser Verkehrsklasse ist zu gering, als 

dass sie eine verwertbare Verwendung für allgemeine Datenübertragung finden kann. 

Für reine Streaming-Anwendungen kann solch ein APN durchaus in Betracht gezogen 

werden. 

Das Ziel dieser Arbeit war die Herausstellung verschiedener Optimierungskonzepte, 

welche für ein Mobilfunknetz geeignet sind. Zusätzlich konnten noch einige der Kon- 

zepte im Testbed und / oder im Live-Netz von O2(Germany) getestet werden. Die 

Optimierung wurde dabei immer auf eine Erhöhung des Durchsatzes und somit einer 

Verringerung der Übertragungszeit ausgerichtet. 

Weiterführende Arbeiten können eines der Konzepte verwenden und eine tiefere, 

detailliertere Optimierung durchführen. Bei der Anpassung der TCP/IP-Einstellungen 

sollten für weitere Anwendungen (HTTP, Streaming, etc.) Tests durchgeführt, die Fens- 

tergröße in kleineren Schritten verändert und evtl. Einstellungen an der MTU-Größe 

vorgenommen werden. 



Literaturverzeichnis 

[3GPP03] 3GPP. 3GPP TS 23.078, September 2003. Technical Specification. 

[Andr02] Oskar Andreasson. Ipsysctl tutorial 1.0.4. Free Software Foundation, 2002. 

[Aust04] David Austerberry. The Technology of Video and Audio Streaming. Focal 

Press, Oktober 2004. ISBN 0240805801. 

[Bada05] Anatol Badach. Voice over IP - Die Technik. Grundlagen und Protokolle 

für Multimedia-Kommunikation. Hanser Fachbuchverlag, Juni 2005. ISBN 

3446403043. 

[Bada06] Anatol Badach. Voice over IP - Die Technik. Grundlagen, Protokolle, An- 

wendungen, Migration, Sicherheit. Hanser Fachbuchverlag, Oktober 2006. 

ISBN 3446406662. 

[Barn88] Richard und Sally Maynard-Smith Barnett. Packet Switched Networks: 

Theory and Practice. Sigma Press, August 1988. ISBN 1850580952. 

[Bern96] T. Berners-Lee. HyperText Transfer Protocol 1.0 (HTTP/1.0). RFC, Mai 

1996. 

[Cast04] Jonathan P. Castro. All IP in 3G CDMA Networks - The UMTS Infra- 

structure and Service Platforms for Future Mobile Systems. John Wiley & 

Sons, Ltd., September 2004. ISBN 0470853220. 

[Fiel99] R. Fielding. HyperText Transfer Protocol 1.1 (HTTP/1.1). RFC, Juni 

1999. 

[Gour02] David und Brian Totty Gourley. HTTP. The Definitive Guide. Understan- 

ding Web Internals. O’Reilly, Oktober 2002. ISBN 1565925092. 



[Holm00] Harri und Antti Toskala Holma. WCDMA for UMTS - Radio Access For 

Third Generation Mobile Communications. John Wiley & Sons, Ltd., Au- 

gust 2000. ISBN 0471720518. 

[Holm06] Harri und Antti Toskala Holma. HSDPA/HSUPA for UMTS. John Wiley 

and Sons Ltd., April 2006. ISBN 0470018844. 

[Jaco92] V. Jacobson. Transmission Control Protocol (TCP). RFC, Mai 1992. 

[Krüg04] Reinhold und Heinz Mellein Krüger. UMTS - Introduction and Measure- 

ment. Rohde&Schwarz GmbH&Co.KG, Juli 2004. 

[Laih02] Achim Wacker und Tomás Novosad Laiho, Jaana. Radio Network Planning 

and Optimisation for UMTS. John Wiley & Sons, Ltd., Januar 2002. ISBN 

0471486531. 

[Lesc02] Pierre Lescuyer. UMTS. Grundlagen, Architektur und Standard. Dpunkt 

Verlag, August 2002. ISBN 3898641414. 

[Liu03] Cricket Liu. DNS und BIND Kochbuch. O’Reilly, April 2003. ISBN 

3897213524. 

[Losh04] Pete Loshin. IPv6, Second Edition. Theory, Protocol, and Practice. Morgan 

Kaufmann, Januar 2004. ISBN 1558608109. 

[Mish04] Ajay R. Mishra. Fundamentals of Cellular Network Planning and Optimi- 

sation. John Wiley & Sons, Ltd., April 2004. ISBN 047086267-X. 

[Post80] Jon Postel. User Datagram Protocol (UDP). RFC, August 1980. 

[Post81] Jon Postel. Transmission Control Protocol (TCP). RFC, September 1981. 

[Post85] Jon Postel. File Transfer Protocol (FTP). RFC, Oktober 1985. 

[Rohd06] Rohde & Schwarz, http://www.rohde-schwarz.de. Romes, August 2006. 

[Schä02] Carsten Schäfer. Das DHCP-Handbuch. Ein Leitfaden zur Planung, Ein- 

führung und Administration von DHCP. Addison-Wesley, August 2002. 

ISBN 3827319048. 

[Scha03] A. Scharf. QoS in Netzen. Vde-Verlag, September 2003. ISBN 3800726424. 



[Sieg97] Gerd Siegmund. ATM - Die Technik. Hüthig, Oktober 1997. ISBN 

3778525417. 

[Stev03] W. Richard Stevens. TCP/IP. Hüthig Telekommunikation, September 

2003. ISBN 3826650425. 

[Tane05] Andrew S. Tanenbaum. Computerarchitektur. Struktur - Konzepte - Grund- 

lagen. Pearson Verlag, Dezember 2005. ISBN 3827371511. 

[Tech02] Technische Universität Ilmenau, http://www.tu-ilmenau.de/ 

fakia/fileadmin/template/startlA/ihss/dat/lehre/UMTS/ 

umts-architecture.pdf. UMTS-Architecure, November 2002. Fa- 

kultät für Integrierte Hard- und Softwaresysteme. 

[UMTS06] UMTSlink, www.umtslink.at. HSDPA UTRAN Architektur, August 2006. 

[Wiki06a] Wikipedia, http://de.wikipedia.org/wiki/Donald_Watts_Davies. Do- 

nald Watts Davies, Juni 2006. Die freie Enzyklopädie. 

[Wiki06b] Wikipedia, http://de.wikipedia.org/wiki/Network_Address_ 

Translation. Network Address Translation, November 2006. Die 

freie Enzyklopädie. 

[Wiki06c] Wikipedia, http://de.wikipedia.org/wiki/O2_plc. O2 plc, Juli 2006. 

Die freie Enzyklopädie. 

[Wiki06d] Wikipedia, http://de.wikipedia.org/wiki/Paketvermittlung. Paket- 

vermittlung, August 2006. Die freie Enzyklopädie. 

[Wiki06e] Wikipedia, http://de.wikipedia.org/wiki/Transmission_Control_ 

Protocol. Transport Control Protocol (TCP), August 2006. Die freie 

Enzyklopädie. 

[Yang05] Cristian Demetrescu und Samer Farthat Yang, Xue-Li. HSDPA Trial 

UA4.2 W33 Test Report. O2(Germany), Dezember 2005. 



Abbildungsverzeichnis 

1.1 O2(Germany) heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2.1 Protokollübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2 Beispiel Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.3 Vergleich RTT, R99 und HSDPA [Yang05] . . . . . . . . . . . . . . . . 8 

2.4 UMTS Netzaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.5 UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.6 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.7 UTRA RRC Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.8 UMTS Architektur (Paketvermittlung) . . . . . . . . . . . . . . . . . . 20 

2.9 UMTS QoS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.10 PDU-Kontext Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.11 PDP-Kontext-Aktivierung . . . . . . . . . . . . . . . . . . . . . . . . . 26 

2.12 PDP-Kontext-Deaktivierung . . . . . . . . . . . . . . . . . . . . . . . . 27 

2.13 Nortel und Nokia in den Regionen . . . . . . . . . . . . . . . . . . . . . 28 

2.14 UMTS UTRAN Architektur . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.1 Messaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.2 Nokia 6680 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

3.3 Einbinden des Nokia 6680 . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3.4 DQA Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.5 Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

3.6 jPlot Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

3.7 Standard Messstrecke . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

3.8 Romes GPS Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

3.9 Romes UMTS Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

3.10 Romes DQA Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

3.11 Downgrade des RadioBearers . . . . . . . . . . . . . . . . . . . . . . . 46 



3.12 Übertragungswiederholungen . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.1 Kein Upgrade des RAB . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

4.2 Upgrade des RAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

5.1 TCP/IP Anpassung, Ergebnis (512 kbyte DL) Änderung Fenstergröße, 

Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 


Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 


Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 


Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

5.5 TCP/IP Anpassung, Vergleich veränderter Fenstergrößen (512 kbyte DL) 65 

5.6 TCP/IP Anpassung, Vergleich veränderter Fenstergrößen (8192 kbyte 

DL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 

5.7 Dynamischer RAB Upgrade, Durchsatz . . . . . . . . . . . . . . . . . . 69 

5.8 Dynamischer RAB Upgrade, Zeitdauer . . . . . . . . . . . . . . . . . . 69 

5.9 Zeitdauer einer Übertragung, mit und ohne dynamischen RAB Upgrade 70 

5.10 Parameteroptimierung RNC, Teststrecke 1te Live-Tests . . . . . . . . . 83 

5.11 Parameteroptimierung RNC, 1ter Live Test, FTP 8192 kbyte (DL), 

Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.12 Parameteroptimierung RNC, 1ter Live Test, FTP 512 kbyte (DL), Durch- 

satz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.13 Parameteroptimierung RNC, 1ter Live Test, FTP 64 kbyte (UL), Durch- 

satz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.14 Parameteroptimierung RNC, 1ter Live Test, HTTP 512 kbyte (DL), 

Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.15 Parameteroptimierung RNC, 1ter Live Test, Durchsatz, Videostream . 86 

5.16 Parameteroptimierung RNC, 1ter Live Test, Pakete, Videostream . . . 86 

5.17 Parameteroptimierung RNC, 1ter Live Test, Anzahl Pakete, Videostream 86 

5.18 Parameteroptimierung RNC, 1ter Live Test, VoIP (DL), Durchsatz . . 87 

5.19 Parameteroptimierung RNC, 1ter Live Test, VoIP (UL), Durchsatz . . 87 

5.20 Parameteroptimierung RNC, 2ter Live Test, Durchsatz, FTP DL 512 . 90 

5.21 Parameteroptimierung RNC, 2ter Live Test, Durchsatz, FTP DL 512 . 91 

5.22 Parameteroptimierung RNC, 2ter Live Test, Pakete, FTP DL 512 . . . 91 



5.23 Parameteroptimierung RNC, 2ter Live Test, Vergleich empfangener Da- 

tenmenge, Videostreaming . . . . . . . . . . . . . . . . . . . . . . . . . 91 

5.24 Streaming Klasse, Auswirkungen auf Nicht-Echtzeitanwendungen, Durch- 

satz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 

5.25 Streaming Klasse, Ergebnis Streaming, Durchsatz . . . . . . . . . . . . 97 

5.26 Streaming Klasse, Ergebnis Streaming, Datenmenge . . . . . . . . . . . 97 

5.27 Streaming Klasse, Ergebnis VoIP, Datenmenge . . . . . . . . . . . . . . 98 

5.28 Streaming Klasse, Ergebnis VoIP, Durchsatz Downlink . . . . . . . . . 98 

5.29 Streaming Klasse, Ergebnis VoIP, Durchsatz Uplink . . . . . . . . . . . 98 

6.1 Übersicht über Endergebnisse der Konzepte . . . . . . . . . . . . . . . 100 


Tabellenverzeichnis 108 

Tabellenverzeichnis 

3.1 Auswertung der Momentansituation . . . . . . . . . . . . . . . . . . . . 50 

5.1 TCP/IP Anpassung, Optimierung in Prozent . . . . . . . . . . . . . . . 65 

5.2 Dynamischer RAB, Eingestellte Parameter . . . . . . . . . . . . . . . . 69 

5.3 Parameteroptimierung RNC, DlRlcAckMode Einstellungen . . . . . . . 71 

5.4 Parameteroptimierung RNC, UlRlcAckMode Einstellungen . . . . . . . 72 

5.5 Parameteroptimierung RNC, Angleich Testbed - Live-Netz . . . . . . . 77 

5.6 Parameteroptimierung RNC, DlRlcAckMode Änderungen . . . . . . . . 78 

5.7 Parameteroptimierung RNC, UlRlcAckMode Änderungen . . . . . . . . 78 

5.8 Parameteroptimierung RNC, Ergebnisse der Messungen . . . . . . . . . 81 

5.9 Parameteroptimierung RNC, Entscheidungsmatrix Testbed . . . . . . . 82 

5.10 Parameteroptimierung RNC, DlRlcAckMode Änderungen für 1ten Live- 

Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

5.11 Parameteroptimierung RNC, UlRlcAckMode Änderungen für 1ten Live- 

Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

5.12 Parameteroptimierung RNC, 1ter Live Test, Ergebnisse . . . . . . . . . 87 

5.13 Parameteroptimierung RNC, 1ter Live Test, Optimierung in Prozent . 88 

5.14 Parameteroptimierung RNC, 1ter Live Test, Entscheidungsmatrix . . . 89 

5.15 Parameteroptimierung RNC, 2ter Live Test, Änderung 1 . . . . . . . . 90 



5.18 Parameteroptimierung RNC, 2ter Live Test, Ergebnisse . . . . . . . . . 92 

5.19 Parameteroptimierung RNC, 2ter Live Test, Optimierung in Prozent . 92 

5.20 Parameteroptimierung RNC, 2ter Live Test, Empfohlene Einstellungen 93 

5.21 Streaming Klasse, Einstellung der APNs . . . . . . . . . . . . . . . . . 94 

5.22 Streaming Klasse, Optimierung in Prozent . . . . . . . . . . . . . . . . 99 



Abkürzungsverzeichnis 

3G-SGSN . . . . . . . . . . 3G- Serving GPRS Support Node 

AMC . . . . . . . . . . . . . . . Adaptive Modulation and Coding 

APN . . . . . . . . . . . . . . . Access Point Name 

ATM . . . . . . . . . . . . . . . Asynchronous Transfer Mode, 

Datenübertragungstechnik 

AuC . . . . . . . . . . . . . . . Authentication Center 

BER . . . . . . . . . . . . . . . Bit Error Rate 

BLER . . . . . . . . . . . . . . BLock Error Rate 

BT . . . . . . . . . . . . . . . . . British Telecom 

BTS . . . . . . . . . . . . . . . Base Transceiver Station, 

Funkschnittstelle im GSM-Netzwerk 

CPICH . . . . . . . . . . . . . Common PIlot CHannel 

DCH . . . . . . . . . . . . . . . Dedicated CHannel 

DFÜ . . . . . . . . . . . . . . . DatenFernÜbertragung 

DHCP . . . . . . . . . . . . . Dynamic Host Configuration Protocol 

DL . . . . . . . . . . . . . . . . . DownLoad 

DNS . . . . . . . . . . . . . . . Domain Name System 

EIR . . . . . . . . . . . . . . . . Equipment Information Register 

FACH . . . . . . . . . . . . . . Forward Access CHannel 

FTP . . . . . . . . . . . . . . . File Transfer Protocol, 

Netzwerkprotokoll zur Datenübertragung 

GGSN . . . . . . . . . . . . . Gateway GPRS Support Node 

GPRS . . . . . . . . . . . . . . General Packet Radio Service 

GPS . . . . . . . . . . . . . . . Global Positioning System 

GSM . . . . . . . . . . . . . . . Global System for Mobile Communications, 

2G Mobilfunksystem 

GTP . . . . . . . . . . . . . . . GPRS Tunneling Protocol 



HARQ . . . . . . . . . . . . . Hybrid Automatic ReQuest 

HLR . . . . . . . . . . . . . . . Home Location Register 

HS-DPCCH . . . . . . . . High Speed Dedicated Physical Control CHannel 

HS-PDSCH . . . . . . . . High Speed Physical Downlink Shared CHannel 

HS-SCCH . . . . . . . . . . High Speed Shared Control CHannel 

HSDPA . . . . . . . . . . . . High Speed Downlink Packet Access 

HTTP . . . . . . . . . . . . . HyperText Transfer Protocol, 

Protokoll zur Übertragung von Daten 

IMEI . . . . . . . . . . . . . . . International Mobile Equipment Identities 

IMSI . . . . . . . . . . . . . . . International Mobile Subscriber Identity 

IP . . . . . . . . . . . . . . . . . . Internet Protocol 

IPv4 . . . . . . . . . . . . . . . Internet Protokoll version4 

IPv6 . . . . . . . . . . . . . . . Internet Protokoll version6 

KPI . . . . . . . . . . . . . . . . Key Performance Indicator 

LAC . . . . . . . . . . . . . . . Location Area Code 

LAI . . . . . . . . . . . . . . . . Location Area Identity 

LAN . . . . . . . . . . . . . . . Local Area Network 

MAC . . . . . . . . . . . . . . . Medium Access Control 

MSC . . . . . . . . . . . . . . . Mobile Service Switching Center 

MSS . . . . . . . . . . . . . . . Maximum Segment Size 

MTU . . . . . . . . . . . . . . . Maximum Transmission Unit 

NAT . . . . . . . . . . . . . . . Network Address Translation 

NSAPI . . . . . . . . . . . . . Netscape Server Application Programming Interface 

PCH . . . . . . . . . . . . . . . Paging CHannel 

PCI . . . . . . . . . . . . . . . . Protocol Control Information 

PDP . . . . . . . . . . . . . . . Packet Data Protocol 

PDU . . . . . . . . . . . . . . . Protocol Data Unit 

PICH . . . . . . . . . . . . . . Paging Indicator CHannel 

PU . . . . . . . . . . . . . . . . . Payload Unit 

QAM . . . . . . . . . . . . . . Qquadrature Aamplitude Modulation 

QoS . . . . . . . . . . . . . . . . Quality of Service, 

Dienstgüte in Kommunikationsnetzen 

QPSK . . . . . . . . . . . . . . Qquadrature Phase Shift Keying 

RAB . . . . . . . . . . . . . . . Radio Access Bearer 

RACH . . . . . . . . . . . . . Random Access CHannel 

RAN . . . . . . . . . . . . . . . Radio Access Network 



RB . . . . . . . . . . . . . . . . . Radio Bearer 

RLC . . . . . . . . . . . . . . . Radio Link Control 

RNC . . . . . . . . . . . . . . . Radio Network Controller 

RRC . . . . . . . . . . . . . . . Radio Resource Control 

RSCP . . . . . . . . . . . . . . Received Signal Code Power 

RSSI . . . . . . . . . . . . . . . Radio Signal Strength Indicator 

SACK . . . . . . . . . . . . . . Selective ACKnowledgement 

SC . . . . . . . . . . . . . . . . . Scrambling Code 

SDU . . . . . . . . . . . . . . . Service Data Unit 

SGSN . . . . . . . . . . . . . . Serving GPRS Support Node 

SIG . . . . . . . . . . . . . . . . SS7 to IP Gateway 

SS7 . . . . . . . . . . . . . . . . Signaling System 7 

TCP . . . . . . . . . . . . . . . Transmission Control Protocol, 

TE . . . . . . . . . . . . . . . . . Terminal Equipment 

Protokoll zur Sicherung und zum Transport von Daten 

TMSI . . . . . . . . . . . . . . Temporary Mobile Subscriber Identity 

TSG . . . . . . . . . . . . . . . Time Sequenz Graph 

TTI . . . . . . . . . . . . . . . . Time Transmission Interval 

UDP . . . . . . . . . . . . . . . User Datagram Protocol, 

UE . . . . . . . . . . . . . . . . . User Equipment, 

verbindungsloses Transportprotokoll 

(Mobiles) UE 

UL . . . . . . . . . . . . . . . . . UpLoad 

UMTS . . . . . . . . . . . . . Universal Mobile Telecommunications System, 

3G Mobilfunksystem 

URA . . . . . . . . . . . . . . . UTRAN Registration Area 

URL . . . . . . . . . . . . . . . Univeral Resource Locator, 

definiert Ort einer Ressource im Netzwerk 

USIM . . . . . . . . . . . . . . Univeral Subscriber Identity Module 

UTRA . . . . . . . . . . . . . UMTS Terrestrial Radio Access 

UTRAN . . . . . . . . . . . . UMTS Terrestrial Radio Access Network, 

Funknetz im UMTS-Netzwerk 

VLR . . . . . . . . . . . . . . . Visitor Location Register 

VoIP . . . . . . . . . . . . . . . Voice over IP, 

Sprachübertragungstechnik 

WWW . . . . . . . . . . . . . World Wide Web 


Thesen zur Diplomarbeit 112 

Thesen zur Diplomarbeit 

1. Im aktuellen Zustand des Netzes von O2(Germany) sind 94,2% der verfügbaren 

Ressourcen für paketvermittelte Dienste ungenutzt. 

2. Eine Optimierung hinsichtlich Datenübertragung kann durch Veränderungen von 

Einstellungen am Endgerät und im Mobilfunknetz erreicht werden. 

3. Eine Verbesserung der Datenübertragung über FTP um 27% konnte durch die 

Optimierung der Fenstergröße in den TCP/IP-Einstellungen am Endgerät erzielt 

werden. 

4. Durch die Verwendung eines dynamischen RAB kann eine Verkürzung der Über- 

tragungszeit über FTP um 64% erreicht werden. 

5. Durch die Optimierung der RNC-Einstellungen des DlRlcAckMode und des Ul- 

RlcAckMode wurde eine allgemeine Verbesserung der Datenübertragung um 16% 

und für einzelne Anwendungen um bis zu 38% erreicht. 

6. Erreichte Verbesserung der Übertragungseigenschaften für Streaming-Anwendungen 

um 6% durch die Verwendung der Verkehrsklasse ”Streaming”. 

7. Weitere Optimierungsmöglichkeiten sind durch die Implementierung einer ap- 

plikationspezifischen Komprimierung gegeben. Die Komprimierung wird an der 

Gi-Schnittstelle vorgenommen und reduziert die zu übertragenden Daten, wo- 

durch der Durchsatz subjektiv erhöht wird. 

Ilmenau, den 28. 11. 2006 Andreas Herz 


Erklärung 113 

Erklärung 

Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der ange- 

gebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffent- 

lichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist 

in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prü- 

fungen noch nicht vorgelegt worden. 

Ilmenau, den 28. 11. 2006 Andreas Herz

Diplomarbeit - TU Ilmenau

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?