Technische Universität Ilmenau Fakultät für

Transcrição

Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Diplomarbeit
Untersuchung der Eignung verschiedener
Mobilkommunikationstechnologien für Voice-over-IP
vorgelegt von:
eingereicht am:
Eckhart Helmuth Wittstock
11. 9. 2006
geboren am:
Studiengang:
Studienrichtung:
Wirtschaftsingenieurwesen
Telekommunikations- und
Informationstechnik
Anfertigung im Fachgebiet:
Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Verantwortlicher Professor:
Wissenschaftlicher Betreuer:
Prof. Dr. rer. nat. habil. Jochen Seitz
Dipl.-Ing. Yevgeniy Yeryomin
Danksagung
Ich bedanke mich bei Dipl.-Ing. Yevgeniy Yeryomin und Prof. Dr. Jochen Seitz für die
Betreuung meiner Arbeit.
Ich danke vor allem meiner Familie. Meinem Vater für seine Unterstützung und
seinen Glauben an mich in allen Lebenslagen. Meinen Geschwister, die immer für mich
da waren. Dorothea Hübner, ohne die ich diese Arbeit niemals geschrieben hätte.
Kurzfassung
Vor dem Hintergrund zunehmender Bedeutung von VoIP und drahtloser Internetzugänge rückt die IP-Telefonie über Funktechnologien immer mehr in das Interesse der
Öffentlichkeit.
Diese Arbeit widmet sich primär der Untersuchung von Funktechnologien hinsichtlich ihrer Eignung für die IP-Telefonie.
Dazu werden in einem ersten Teil die den ausgewählten Technologien zugrundeliegenden Standards erörtert, um die Eignung einer Technologie theoretisch bestimmen
zu können. Im zweiten Teil der Arbeit wird die Eignung von WLAN und Bluetooth
anhand von Praxistests überprüft. Für diesen Zweck werden RTP-Paketströme ähnlich einem VoIP-Gespräch erzeugt und wesentliche Parameter bestimmt. Der dritte
Teil widmet sich der Ermittlung der anfallenden Kosten, zum einen durch die Tarife
der Anbieter von Funkzugängen, zum anderen durch die Geräteanschaffungen, die zu
tätigen sind.
Im Ergebnis liefert diese Arbeit einen umfassenden Überblick über die betrachteten
Technologien und ihre Eignung. Zusammengefasst werden die Erkenntnisse aus den einzelnen Teilen in einer Software, die auf Benutzereingaben hin eine optimale Technologie
für drahtlose VoIP-Gespräche empfiehlt.
Die Untersuchungen kennzeichnen WLAN und zukünftig auch WiMAX als besonders
geeignet für die Übertragung von VoIP-Daten. Die Mobilfunktechnologien erweisen sich
als weniger gut geeignet, zum einen aus technischen Gründen, zum anderen aufgrund
zu hoher Kosten.
Abstract
As Voice-over-IP and wireless Internet access gain momentum, wireless IP-Telephony
stirs more and more public interest.
This thesis examines the suitability of wireless technologies for VoIP communication.
In the first section, the underlying standards of selected technologies are evaluated
on a theoretical basis as to how well they are suited for the purpose. The second section
describes practical measurements that have been made using WLAN and Bluetooth
devices. Essential network parameters have been determined through the generation
and measurement of RTP packet streams. In the third section of the study, the costs
of Internet access and required equipment are evaluated.
In conclusion, this work provides a comprehensive overview of the selected technologies. The results have been condensed into a software that asks for the individual
circumstances and then recommends the most suitable technology for VoIP. The results indicate that WLAN and, for future use, WiMAX are particularly suited, rather
than the current mobile phone networks.
Inhaltsverzeichnis
i
Inhaltsverzeichnis
1 Einführung
1.1 Motivation und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Sprachqualität . . . . . . . . . . . . . . .
2.1.2 Sprachcodierung . . . . . . . . . . . . .
2.1.2.1 Einflussfaktoren . . . . . . . .
2.1.2.2 Codecs . . . . . . . . . . . . .
2.1.3 Protokolle . . . . . . . . . . . . . . . . .
2.1.3.1 Übertragung des Sprachsignals
2.1.3.2 Signalisierungsprotokolle . . . .
2.1.4 Quality of Service . . . . . . . . . . . . .
2.1.4.1 Parameter . . . . . . . . . . . .
2.1.4.2 Zusammenfassung . . . . . . .
2.1.5 Resultierende Anforderungen . . . . . .
2.2 IP über Funkstrecken . . . . . . . . . . . . . . .
3 Mobilkommunikationstechnologien
3.1 Einleitung und Übersicht . . . .
3.2 Bluetooth . . . . . . . . . . . .
3.2.1 Funktionsweise . . . . .
3.2.2 Bluetooth-Protokollstack
3.2.3 Relevante Profile . . . .
3.2.4 Eignung für VoIP . . . .
3.3 WLAN . . . . . . . . . . . . . .
3.3.1 Funktionsweise . . . . .
3.3.1.1 PHY-Layer . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
5
6
7
8
10
12
15
19
19
20
21
22
.
.
.
.
.
.
.
.
.
24
24
25
25
26
30
31
32
33
33
Diplomarbeit Eckhart Helmuth Wittstock
Inhaltsverzeichnis
3.4
3.5
3.6
3.7
ii
3.3.1.2 MAC-Layer 802.11 . . . . . . . . . . . . . . . . . . . .
3.3.1.3 MAC-Layer 802.11e - Quality of Service Enhancements
3.3.2 Eignung für VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Bitrate und Delay . . . . . . . . . . . . . . . . . . . .
3.3.2.2 Wissenschaftliche Arbeiten . . . . . . . . . . . . . . .
GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1.1 Struktur des GPRS-Netzes . . . . . . . . . . . . . . .
3.4.1.2 GPRS-Protokollstack . . . . . . . . . . . . . . . . . . .
3.4.1.3 GPRS-Dienste . . . . . . . . . . . . . . . . . . . . . .
3.4.2 EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 Eignung für VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1.1 Quality of Service . . . . . . . . . . . . . . . . . . . .
3.5.1.2 IP-Übertragung . . . . . . . . . . . . . . . . . . . . . .
3.5.2 HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.3 Eignung für VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.1 PHY-Layer . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.2 MAC-Layer . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1.3 802.16e . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Eignung für VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Vergleich ausgewählter Technologien
4.1 Einleitung und Übersicht . . . . .
4.2 Zielsetzung und Vorgehen . . . .
4.3 Versuchsumgebung . . . . . . . .
4.3.1 Hardware . . . . . . . . .
4.3.2 Software . . . . . . . . . .
4.3.2.1 hrPING . . . .
4.3.2.2 netio . . . . . .
4.3.2.3 rtp-tools . . . .
4.3.2.4 SIPp . . . . . .
anhand von Praxistests
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
38
39
39
43
44
45
45
46
50
51
51
53
55
58
59
60
61
62
63
63
66
67
67
69
70
70
70
72
73
74
74
74
74
74
Inhaltsverzeichnis
4.4
4.5
iii
4.3.2.5 Wireshark . . . . . . . .
4.3.2.6 TrafMeter . . . . . . . .
4.3.2.7 Bandwidth Monitor Pro
4.3.3 Messungen . . . . . . . . . . . . . .
4.3.3.1 Vorbereitende Messungen
4.3.3.2 RTP-Ströme . . . . . . .
Auswertung . . . . . . . . . . . . . . . . .
4.4.1 Round-Trip-Time (RTT) . . . . . .
4.4.2 Paketverluste . . . . . . . . . . . .
4.4.3 Jitter . . . . . . . . . . . . . . . . .
4.4.4 Datenrate . . . . . . . . . . . . . .
4.4.5 Jitter-Puffer . . . . . . . . . . . . .
Ergebnisse . . . . . . . . . . . . . . . . . .
4.5.1 Test hrPING . . . . . . . . . . . .
4.5.2 RTP-Verkehr . . . . . . . . . . . .
4.5.2.1 Round-Trip-Time . . . . .
4.5.2.2 Jitter . . . . . . . . . . .
4.5.2.3 Paketverluste . . . . . . .
4.5.2.4 Datenrate . . . . . . . . .
4.5.3 Zusammenfassung . . . . . . . . . .
5 Kostenanalyse
5.1 Einleitung und Übersicht . . . . . . . .
5.2 Laufende Kosten . . . . . . . . . . . .
5.2.1 Mobilfunktarife . . . . . . . . .
5.2.1.1 Zeittarifoptionen . . .
5.2.1.2 Volumentarifoptionen
5.2.2 WLAN-Tarife . . . . . . . . . .
5.2.3 WiMAX-Tarife . . . . . . . . .
5.2.4 Vergleich . . . . . . . . . . . . .
5.3 Anschaffungskosten . . . . . . . . . . .
5.3.1 Bluetooth . . . . . . . . . . . .
5.3.2 WLAN . . . . . . . . . . . . . .
5.3.3 Mobilfunk . . . . . . . . . . . .
5.3.4 Endgeräte für drahtloses VoIP .
5.4 Zusammenfassung . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
75
75
75
75
75
76
77
77
77
78
78
78
78
78
79
79
79
80
81
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
82
82
83
83
84
85
86
86
87
88
88
89
89
90
Inhaltsverzeichnis
iv
6 Programm zur Auswahl einer optimalen Technologie
6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . .
6.2 Anforderungen . . . . . . . . . . . . . . . . . . . .
6.3 Konzept . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Umsetzung . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Benutzerschnittstelle . . . . . . . . . . . . .
6.4.2 Daten . . . . . . . . . . . . . . . . . . . . .
6.4.3 Funktionalität . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
91
91
91
92
92
92
94
7 Zusammenfassung und Ausblick
96
Literaturverzeichnis
99
Abbildungsverzeichnis
111
Tabellenverzeichnis
112
Abkürzungsverzeichnis und Formelzeichen
114
DVD-Verzeichnis
120
Erklärung
121
1 Einführung
1
1 Einführung
Die Entwicklung und Verbreitung von Voice-over-IP (VoIP) ist in den letzten Jahren
so rasant angestiegen, dass es sich nicht nur bei Netzbetreibern und Unternehmen der
Informationstechnologie (IT), sondern auch branchenübergreifend bei Unternehmen
sowie in Privathaushalten etabliert.
In der Literatur ist der Begriff VoIP nicht immer eindeutig definiert. Manche Autoren
unterscheiden zwischen VoIP, Internettelefonie und IP-Telefonie [HeRV02] in der Form,
als dass sie unter VoIP allgemein Übertragung von Sprachdaten über IP-Netze verstehen, unter Internettelefonie das Nutzen des Internets zum Herstellen und Übertragen
eines Telefongespräches und unter IP-Telefonie das Herstellen einer hochqualitativen
Telefonverbindung zwischen zwei Endgeräten an einem IP-Netz.
In dieser Arbeit wird der Begriff VoIP allgemein als das Herstellen einer Telefonverbindung über ein IP-basiertes Netz verstanden.
1.1 Motivation und Zielsetzung
Angespornt durch die rasante Verbreitung von IP-Telefonie und drahtlosen Netzen im
privaten Bereich, entstand der Wunsch nach einem Vergleich der bestehenden und
potentiell neuen drahtlosen Systeme, über die IP-Telefonie möglich ist.
In Privathaushalten existieren schon jetzt häufig drahtlose Netze z.B. nach IEEE
802.11 WLAN. Auch in öffentlichen Einrichtungen, z.B. an Flughäfen, in Hotels oder
im Innenstadtbereich finden diese immer größere Verbreitung. Weiterhin ist besonders
bei Handys, Personal Digital Assistants (PDA) und ähnlichen Geräten der BluetoothStandard weit verbreitet und erhält neue Funktionalitäten, wie z.B. die Steuerung eines
Rechners mit Hilfe eines Mobiltelefons.
Weiterer Beweggrund dieser Arbeit ist die rasche Entwicklung des digitalen Mobilfunknetzes der dritten Generation. Als signifikantes Beispiel sei hier auf die geltenden
Lizenzauflagen hingewiesen, die es den beteiligten Unternehmen seit dem 31.12.2005
ermöglichen, mehr als die Hälfte der Bevölkerung über UMTS zu erreichen.
1 Einführung
2
In den aktuellen Angeboten der Mobilfunkprovider finden sich verschiedene Möglichkeiten des Aufbaus von Datenverbindungen auf IP-Basis. Über die digitalen Mobilfunknetze der zweiten und dritten Generation können Übertragungsgeschwindigkeiten
bis zu 1,8 MBit/s erreicht werden. Weiteres Indiz für die rasante Entwicklung ist das
Angebot von Datenflatrates, so dass der Gedanke nahe liegt, die kostenintensiven Mobilfunkgespräche durch IP-Telefonie über das Datennetz zu ersetzen.
Ziel dieser Arbeit ist es, einen Überblick über die zur Zeit verfügbaren Technologien
zur drahtlosen Übertragung von VoIP-Gesprächen zu geben und die damit zusammenhängenden Kostenaspekte zu analysieren. Diese Daten sollen die Grundlage für eine
selbst erstellte Software bilden, die nach Eingabe verschiedener Parameter eine für den
jeweiligen Anwendungsfall geeignete Technologie empfiehlt.
1.2 Vorgehensweise
Nach umfangreicher Recherche der einschlägigen Fachliteratur werden die für VoIP in
Frage kommenden Technologien ermittelt und unter verschiedenen, für die Übertragung von Sprachdaten wichtigen Aspekten, beleuchtet. Hinzu kommt die Ermittlung
der Kostenparameter verfügbarer Endgeräte und Access Points. In einem weiteren
Schritt werden diese Technologien in Praxistests auf ihre Tauglichkeit bezüglich der
Sprachübermittlung überprüft. Die Ergebnisse der theoretischen Recherche sowie der
praktisch durchgeführten Tests münden in ein Softwareprogramm, welches darüber
Auskunft geben soll, welche Technologie unter bestimmten Rahmenbedingungen für
den jeweiligen Einsatz sinnvoll ist.
2 Grundlagen
3
2 Grundlagen
In diesem Kapitel wird das Verfahren der Sprachübertragung über ein IP-Netzwerk
erläutert. Besondere Beachtung finden dabei Aspekte, die die Kommunikation über
drahtlose Netze beeinflussen.
2.1 VoIP
Das herkömmliche Telefonnetz arbeitet leitungsorientiert, d.h. es stellt dem Anwender
für die Dauer seines Gespräches einen Kanal fester und damit garantierter Bandbreite zur Verfügung. Da auf diesem Kanal nicht zu jedem Zeitpunkt in beide Richtungen Sprach- oder Steuerdaten übertragen werden, wird die vorhandene Bandbreite
nicht ökonomisch effizient ausgenutzt. Anders ist es bei paketorientierten Netzen wie
einem IP-Netz. Daten werden nach Bedarf in Paketen gesendet und nach der best
”
effort“-Methode zum Ziel geroutet. Dabei besteht ohne Implementierung von Quality
of Service (QoS)-Mechanismen kein Einfluss auf den Weg oder die Zeitverzögerung der
Pakete bis zu ihrem Ziel.
VoIP ist Sprachtelefonie über ein paketbasiertes IP-Netzwerk. Die Verbindung kann
dabei zwischen verschiedenen Endgeräten aufgebaut werden, z.B. Laptops, VoIP-Telefonen oder PDAs. Der Austausch der eigentlichen Sprachdaten findet direkt zwischen
den Endgeräten statt, getrennt von den Signalisierungsdaten, die meistens noch dritte
Instanzen benutzen. Abbildung 2.1 zeigt den prinzipiellen Aufbau eines Gesprächs.
Die Verbindung wird dabei über die Internetprotokollarchitektur aufgebaut (siehe
Abschnitt 2.1.3). Signalisierung und Sprachdaten werden getrennt über verschiedene
Protokolle übertragen. Die verwendeten Signalisierungsprotokolle sind im Großteil der
Fälle das Session Initiation Protocol (SIP) oder H.323, sie werden über UDP/IP oder
TCP/IP transportiert. Die Sprachdaten werden meistens über das für Echtzeitanwendungen gedachte Realtime Transfer Protocol (RTP)-Protokoll bewegt, das auf UDP/IP
aufsetzt.
Die Übertragung der Sprachdaten umfasst die fünf Schritte Aufnahme des Audiosignals, AD-Wandlung, Codierung, Paketierung und Pakettransfer. Im Empfänger werden
2 Grundlagen
4
Abbildung 2.1: VoIP-Gespräch [Eigene Darstellung]
diese Schritte in umgekehrter Reihenfolge durchlaufen, mit dem Unterschied, dass die
Daten vor dem Decodieren in einem Pufferspeicher zwischengespeichert werden, der
zur Kompensation der Laufzeitunterschiede der Pakete dient. Diese Vorgänge sind in
Abbildung 2.2 schematisch dargestellt.
Sprachqualität
Sprecher
Zuhörer
Sprachsignal
Sprachsignal
Aufnahme
A/D Wandlung
Wiedergabe
D/A Wandlung
PCM Signal
Codierung
PCM Signal
Voice Activity Detection
Discontinous Transmission
Loss Concealment
Datenpakete
Puffer
Datenpakete
Paketierung
RTP/UDP/IP
Depaketierung
RTP/UDP/IP
IP Pakete
Übertragung
Decodierung
IP Pakete
Delay, Jitter, Paketverluste
Frames
Übertragung
Frames
IP Netz mit drahtloser Verbindung
Abbildung 2.2: VoIP-Sprachdatenstrom [Eigene Darstellung]
Dem Schema aus Abbildung 2.2 folgend, sollen in diesem Kapitel die relevanten
Grundlagen von VoIP erläutert werden. Dazu werden zunächst Verfahren zur Ermittlung der Sprachqualität erläutert, um anschließend auf den Einfluss der Sprachcodierung einzugehen. Danach werden die allgemein verwendeten Protokolle für die Signalisierung und den Transfer der Daten beschrieben. Abschließend werden die dieser Arbeit
zugrunde liegenden QoS-Parameter zur Beurteilung verschiedener drahtloser Techno-
2 Grundlagen
5
logien und die bei Funkübertragung auftretenden Effekte erläutert.
2.1.1 Sprachqualität
Bei paketbasierter Telefonie hängt die Sprachqualität neben den Eigenschaften der
Sprachcodecs (Kapitel 2.1.2) im Wesentlichen von den statistischen Effekten des Paketnetzwerkes, der Verzögerung (Delay) sowie der Schwankung der Verzögerungszeiten
(Jitter) der einzelnen Pakete und dem Umfang und der Art der auftretenden Paketverluste (packet loss) ab. Die Bewertung der Sprachqualität einer Kommunikationsverbindung ist von der menschlichen Wahrnehmung abhängig, man unterscheidet zur
Bestimmung subjektive und objektive (rechnerische) Verfahren, die im Folgenden beschrieben werden.
Subjektive Verfahren arbeiten mit Versuchspersonen, deren Aufgabe es ist, die
von ihnen wahrgenommene Qualität einer Verbindung zu bewerten. Das am weitesten
verbreitete Verfahren basiert auf der Empfehlung P.800 [ITU-96c] der International
Telecommunications Union (ITU) und arbeitet mit einer subjektiven Bewertungsskala,
dem Mean Opinion Score (MOS). Gemessen wird mit Werten von eins bis fünf, die in
Tabelle 2.1 aufgeführt sind. Einen MOS-Wert von 4.0 bezeichnet man als toll quality“,
”
nach der von der Festnetztelefonie mindestens erwarteten Sprachqualität.
MOS
1
2
3
4
5
Bewertung
Bad
Poor
Fair
Good
Excellent
Tabelle 2.1: Mean Opinion Score [ITU-96c, S.11]
Die Ergebnisse des Tests sind, neben der individuellen Einschätzung der teilnehmenden Personen, vor allem von der umgebenden Situation abhängig, zuverlässige
Aussagen sind somit nur möglich, wenn das gesamte Spektrum der Randparameter
bekannt ist. Trotz dieses Nachteils kann nur über subjektive Verfahren ein endgültiges
Urteil über die wahrgenommene Sprachqualität gefällt werden, da trotz aller wissenschaftlicher Erkenntnis die Modelle der rechnerischen Verfahren nur Näherungen an
die Wirklichkeit bleiben.
Diese objektiven Verfahren besitzen den Vorteil, dass sie einfacher und kostengünstiger sind. Zwei verbreitete und von der ITU standardisierte Verfahren werden in
2 Grundlagen
6
den folgenden Abschnitten beschrieben. Zum einen der Perceptual Evaluation of Speech
Quality (PESQ)-Algorithmus [ITU-01c] und zum anderen das E-Model [ITU-05].
PESQ
Der PESQ-Algorithmus gibt einen Voraussagewert für die Bewertung schmalbandiger
Sprachkommunikation an. Dazu wird das Originalsignal und das über eine Teststrecke
übermittelte Signal mit Hilfe eines Wahrnehmungsmodells verglichen. Der Algorithmus liefert im Ergebnis MOS-ähnliche Werte im Bereich von -0.5 bis 4.5, was den
normalen Ergebnissen eines subjektiven Tests mit MOS-Werten entspricht. PESQ liefert laut P.862 [ITU-01c] gute Ergebnisse, sowohl mit PCM-Codecs als auch mit CELPbasierten oder Hybridcodecs. Bei Übertragungs- und Paketverlusten, unterschiedlichen
Laufzeiten und unter dem Einfluss von Störgeräuschen ist der Algorithmus ebenfalls
gut geeignet. Für andere Fälle wie z.B. Vocoder für kleine Bitraten, digitale Stille oder
Hörerecho funktioniert PESQ nicht und müsste dementsprechend modifiziert werden.
Das E-Model
Das E-Model [ITU-05] ist ein Computermodell für den Einsatz bei der Planung von
Übertragungswegen. Es berechnet aus einer Vielzahl von Faktoren wie Delay, Echo,
Lautstärke etc. den so genannten R-Wert. Dieser bewegt sich im Rahmen von 0-100,
wobei 100 die beste Qualität und 70 die untere Grenze für Telefongespräche, die so
genannte toll quality“ darstellt. Laut Spezifikation kann der R-Wert in MOS umge”
rechnet werden, ein R-Wert von 0 entspricht dabei einem MOS von 1 und ein R-Wert
von 100 einem MOS von 4,5. Eine umfangreiche Analyse des E-Modells findet sich in
[Möll00].
2.1.2 Sprachcodierung
Die digitale Codierung der Sprache spielt bei VoIP eine wesentliche Rolle, da sich die
verwendeten Codecs stark im Hinblick auf die Sprachqualität und die verursachten
Verzögerungszeiten unterscheiden.
Ein Codec (zusammengesetzt aus den englischen Begriffen coder und decoder) ist
ein Programm oder Verfahren, das Signale digital codiert und decodiert. Grundlage
für die Sprachübertragung bildet der von der ITU standardisierte G.711-Codec, der
aus einem analogen bandbegrenzten Signal (300 Hz - 3,4 kHz) ein digitales Signal mit
einer Bitrate von 64 kBit/s erzeugt. Alle anderen Codecs bauen auf dieser Pulse Code
Modulation (PCM)-Codierung auf.
2 Grundlagen
7
Da Sprachcodecs für den Transport der menschlichen Sprache ausgelegt sind, tauchen
Probleme bei der Übertragung von nichtsprachlichen Signalen auf. Davon betroffen
sind vor allem der Faxverkehr und Dual Tone Multiple Frequency (DTMF)-Signale. Die
Signalisierungsprotokolle und die ITU-Empfehlung T.38 bieten verschiedene Lösungen
an.
Im folgenden Kapitel werden zuerst die maßgeblichen Faktoren erläutert, um anschließend die wichtigsten augenblicklich verwendeten Codecs vorzustellen. Die weit
verbreitete Open Source Software Asterisk unterstützt beispielsweise die Codecs G.711,
G.723, GSM, G.726, G.729, ADPCM, slin, lpc10, iLBC und Speex.
2.1.2.1 Einflussfaktoren
IP-Netzwerke haben eine begrenzte maximale Übertragungsrate, hinzu kommen die
variable Laufzeit und der Verlust von Paketen. Ein für VoIP optimal geeigneter Codec
verbindet beste Sprachqualität mit geringer Bitrate, geringem Einfluss auf die Paketlaufzeit und hoher Kompensationsfähigkeit im Falle von Paketverlusten. Im Verlauf
dieser Arbeit wird sich zeigen, dass die existierenden Möglichkeiten immer einen Kompromiss darstellen - ein Codec, der in allen Fällen optimal arbeitet, existiert nicht.
Bei der Auswahl des Codecs spielt die Bitrate eine große Rolle. Die im ISDN verwendete PCM-Codierung ergibt eine Bitrate des Datensignals von 64 kBit/s und legt
damit die Obergrenze für die in der Telefonie verwendeten schmalbandigen Sprachsignale fest. Andere Codecs erreichen mit mathematischen Kompressionsverfahren erheblich
geringere Bitraten, meist auf Kosten der Verarbeitungszeit und der Sprachqualität.
Aufbauend auf dem digitalen PCM-Signal, wenden die meisten in der IP-Telefonie
gebräuchlichen Codecs ihre Kompressionsalgorithmen auf eine fixe Anzahl von PCMWerten an, einen block. Das Ergebnis einer Kompressionsoperation ist ein Frame. Dabei
müssen Codecs, die nach bestimmten Verfahren wie Code-book Excited Linear Predictive Coding (CELP) arbeiten (z.B. G.729), nicht nur den aktuellen block berücksichtigen,
sondern auch Teile des nachfolgenden. Diese zu berücksichtigende Zeit wird look-ahead
genannt. Die Bitrate wird entscheidend dadurch beeinflusst, wieviele Frames in einem
IP-Paket transportiert werden. Der G.729-Codec komprimiert blocks von 10 ms Länge;
um die Bitrateneffizienz zu verbessern, werden meistens zwei Frames in einem Paket
verschickt.
Um die durchschnittliche Bitrate zu verringern, wird oft Voice Acitivity Detection
(VAD) verwendet, ein Verfahren, das Sprachpausen detektiert und während dieser keine oder weniger Daten generiert. Dieses Verfahren wird als Discontinous Transmission
(DTX) bezeichnet. Im weiteren Verlauf der Arbeit ist mit VAD immer auch DTX
2 Grundlagen
8
gemeint. Um den Beginn beziehungsweise das Ende der Gesprächspause zu erkennen,
muss der Codec eine bestimmte Zeitspanne zwischenspeichern, diese erhöht die Verzögerung beim Transport der Pakete. In diesem Zusammenhang spielt wiederum die
menschliche Wahrnehmung eine wichtige Rolle. Ein völliger Wegfall der Hintergrundgeräusche, die in jedem Telefongespräch vorhanden sind, irritiert den Kommunikationspartner. Weiterentwickelte Codecs haben deshalb die Möglichkeit, während der Gesprächspausen eine minimale Datenmenge zu übertragen, aus denen der Empfänger
dann mit Hilfe bisheriger Daten ein ähnliches Hintergrundgeräusch regenerieren kann.
Dieses wird Comfort Noise Generation (CNG) genannt.
Alle Verzögerungen, die durch die Kompression und den damit im Zusammenhang
stehenden Abläufen verursacht werden, fasst man als coder-related processing delay
zusammen. Messwerte für die unterschiedlichen Codecs finden sich in [ITU-03a].
In einem IP-Netzwerk gehen Pakete verloren (packet loss). Oft passiert dies aufgrund
der Überlastung eines Knotenpunktes oder - besonders bei drahtlosen Verbindungen
- durch schlechte Kanalqualität. Die Folge davon ist, dass nicht nur einzelne Pakete
verlorengehen, sondern es treten gehäufte Verluste auf, so dass mehrere hintereinander
gesendete Pakete verlorengehen (burst loss). Als weitere wichtige Eigenschaft eines
Sprachcodecs ist deshalb die Robustheit des resultierenden Signals gegen den Verlust
einzelner oder mehrerer Pakete hintereinander zu nennen. In der ITU-Empfehlung
G.113 [ITU-01b] finden sich Werte für verschiedene Codecs. Das Verfahren, fehlende
Audiodaten durch mathematische Verfahren zu tarnen, heißt Packet Loss Concealment
(PLC).
Als letzter Aspekt sei an dieser Stelle auf den urheberrechtlichen Schutz verwiesen.
Für viele Patente der verwendeten Verfahren fallen Lizenzgebühren an, was die Kosten
für den Gebrauch der entsprechenden Codecs erheblich erhöhen kann.
2.1.2.2 Codecs
G.711 - ITU-T Der G.711-Codec [ITU-88] ist bekannt aus dem ISDN, er codiert den
Frequenzbereich zwischen 300 Hz und 3,4 kHz, der mit einer Rate von 8 kHz abgetastet
wird, über eine nichtlineare Kennlinie in ein 64 kBit/s Signal. Jeder Wert wird dabei
mit einem Byte codiert, so ergeben sich 8000 Samples * 8 Bit = 64 kBit/s, die Rahmenlänge beträgt 125 µs. Die nichtlinearen Kennlinien dienen dazu, die Auflösung der
Lautstärke an das menschliche Ohr anzupassen. In den USA bzw. Japan findet dabei
mit der sogenannten µ-Kennlinie eine andere Kennlinie Verwendung als in Europa und
bei internationalen Verbindungen (a-Kennlinie). Sie unterscheiden sich allerdings nur
marginal. Der MOS-Wert für den G.711 wird allgemein mit 4,1 angegeben.
2 Grundlagen
9
G.723.1 - ITU-T Dieser Codec [ITU-96a] benutzt eine Rahmenlänge von 30 ms und
einen look-ahead von 7,5 ms. Es gibt zwei Operationsmodi (5,3 kBit/s und 6,4 kBit/s),
zwischen denen gewechselt werden kann. Dieser Codec überträgt DTMF-Signale nicht
einwandfrei, auch das Versenden von Faxen ist nicht möglich. Er erreicht einen MOSWert von 3,7 im 5,3 kBit/s Modus und 3,9 im 6,4 kBit/s Modus. G.723.1 unterstützt
VAD und CNG durch das Übertragen von 4-Byte-Rahmen (1,1 kBit/s) während der
Gesprächspausen.
Zu G.723.1 tragen eine Reihe von Patenten bei, die sich im Besitz unterschiedlicher
Firmen befinden. Für den Einsatz ist eine Lizenz erforderlich.
G.726 - ITU-T G.726 [ITU-90] benutzt ein Verfahren genannt Adaptive Differential
Pulse Code Modulation (ADPCM), um einen G.711-Bitstrom zu codieren. Die resultierende Bitraten können 16, 24, 32 oder 40 kBit/s sein. Wie bei G.711 beträgt die
Rahmenlänge 125 µs, es gibt keinen look-ahead und somit keine zusätzlich durch den
Codec verursachte Verzögerung. G.726 erreicht einen MOS-Wert von 3,85.
G.729 - ITU-T G.729 [ITU-96b] ist ein sehr beliebter Codec für VoIP und benutzt
ein Verfahren, das Conjugate Structure Algebraic Code-Excited Linear Prediction (CSACELP) genannt wird. Er codiert 10 ms Sprache in einem 80 Bit Rahmen mit einer
resultierenden Bitrate von 8 kBit/s, bei einem MOS-Wert um die 4,0. Der Codec benötigt einen look-ahead von 5 ms. Unterstützung für VAD, DTX und CNG ist gegeben,
in einer Sprachpause werden dann 15 Bit lange Rahmen gesendet, wenn sich das Hintergrundgeräusch verändert. Auch dieser Codec beruht auf vielen Patenten verschiedener
Firmen, seine Nutzung ist an eine Lizenz gekoppelt.
GSM Full Rate - ETSI SMG Der als Special Mobile Group (SMG) bezeichnete Teil
des European Telecommunications Standardization Institute (ETSI) hat die Codecs für
das Global System for Mobile Communications (GSM)-Mobiltelefonnetz standardisiert.
Dazu gehört der täglich in jedem GSM-Telefon benutzte Codec GSM 06.10 [3rd 06],
der nach der Methode Regular Pulse Excitation - Long Term Prediction (RPE-LTP)
funktioniert. Er codiert einen Sprachrahmen von 20 ms ohne look-ahead mit einer
Bitrate von 13 kBit/s und erreicht dabei einen MOS-Wert knapp unterhalb von 3,7. Das
Patent gehört Philips, für Mobiltelefonanwendungen ist der Codec lizenzfrei nutzbar.
GSM Half-rate - ETSI SMG Der Codec 06.20 [3rd 06] benutzt Vector Sum-Excited
Linear Prediction (VSELP), um die Bitrate bei nahezu gleichbleibender Sprachqualität
2 Grundlagen
10
zu halbieren. Sprachrahmen von 20 ms werden mit Hilfe eines look-aheads von 4,4 ms
in einer Bitrate von 5,6 kBit/s codiert.
GSM enhanced full rate (EFR) - ETSI SMG Der GSM 06.60 [3rd 06] genannte
Codec ist unter optimalen Bedingungen qualitativ besser als der G.726. Er basiert auf
dem CELP-Verfahren und codiert 20 ms Rahmen mit einer Rate von 12,2 kBit/s, VAD
und DTX werden unterstützt.
Speex Speex ist ein Open Source Codec, der nach dem CELP-Verfahren funktioniert.
Er liefert beim Codieren von 20 ms Rahmen variable Bitraten von 2,15 bis 24,6 kBit/s
und besitzt einen look-ahead von 10 ms. Dieser Codec erreicht einen MOS-Wert von
ca. 3,7 [RäTo05].
Internet Low Bitrate Codec (iLBC) Der von Global IP Sound entwickelte iLBCCodec [IETF04] benutzt einen blockunabhängigen Linear-Prediction Coding (LPC)Algorithmus, der bei gleicher bis besserer Qualität als der G.729-Codec eine bessere
Resistenz gegen Paketverluste aufweist. Er codiert Rahmen von 30 ms bzw. 20 ms
Länge und erreicht eine Rate von ca. 13,3 kBit/s bzw. 15,2 kBit/s. Der Codec ist frei
verfügbar.
AMR - ITU-T Der Codec für das UMTS-Netz ist der Advanced Multi-Rate (AMR)
Codec (siehe TS 26.017 [3rd 06]). Er arbeitet mit acht unterschiedlichen Bitraten zwischen 4,75 und 12,2 kBit/s, wobei nach jedem 20 ms Rahmen die Codierung gewechselt
werden kann. Er unterstützt VAD, DTX und CNG. Die Qualität und Codierung entspricht im besten Fall (12,2 kBit/s) dem eines EFR-GSM Codecs.
Zusammenfassende Übersicht Tabelle 2.2 fasst die erläuterten Codecs zusammen
und stellt ihre wichtigsten Parameter gegenüber. Die MOS-Werte sind den Übersichten
in [Cisc06] und [ITU-03a, Anhang A] entnommen.
2.1.3 Protokolle
Eine VoIP-Verbindung benutzt unterschiedliche Protokolle für Signalisierung und Übertragung der eigentlichen Sprachdaten. Abbildung 2.3 zeigt die verwendeten Protokolle
auf den einzelnen Schichten in Relation zum ISO/OSI-Schichtenmodell und dem Modell der Defense Advanced Research Project Agency (DARPA).
2 Grundlagen
Codec
Verfahren
G.711
PCM
G.723.1
MP-ACELP
MP-MLQ
G.726
ADPCM
G.729
CS-ACELP
GSM FR
RPE-LTP
GSM HR
VSELP
GSM EFR
CD-ACELP
iLBC
LPC
Speex
CELP
11
MOS
Rahmen
(ms)
0,125
look-ahead
(ms)
0
VAD
Lizenz
4,1
Bitrate
(kBit/s)
64
nein
nein
3,65/3,9
5,3/6,4
30
7,5
ja
ja
3,85(32)
16/24/32/64
0,125
0
nein
nein
3,92
8
10
5
ja
ja
3,7
13
20
0
nein
ja
5,6
20
4,4
nein
ja
12,2
20
0
ja
ja
3,8
15,2/13,3
20/30
0
nein
nein
ca. 3,7
2,15-24,6
20
10
ja
Open Source
Tabelle 2.2: Übersicht Sprachcodecs
ISO/OSI
DARPA
Internet
Application
Applikation z.B. SIP Client
Presentation
Application
SIP/H.323
Session
Transport
Transport
RTP/RTCP
TCP/UDP
Network
Data Link
Physical
Internet
IP
Network
Interface
Ethernet/WLAN/WIMAX
Abbildung 2.3: Verwendete Protokolle in Relation zum ISO/OSI- und DARPA-Modell
[Eigene Darstellung]
Verbreitete Protokolle für die Signalisierung sind das SIP und das Multimedia-Kommunikationsprotokoll H.323, auf die im zweiten Abschnitt eingegangen wird. Zur Sprachübertragung wird üblicherweise das Realtime Transfer Protocol (RTP) benutzt, das auf
dem User Datagram Protocol (UDP) sowie IP aufsetzt. Der Beschreibung dieser Pro-
2 Grundlagen
12
tokolle widmet sich der folgende Abschnitt.
2.1.3.1 Übertragung des Sprachsignals
Im Folgenden sollen die Grundlagen der einzelnen Protokolle erklärt werden, ohne zu
weit ins Detail zu gehen.
Internetprotokoll (IP) Im Allgemeinen wird heutzutage IP [IETF81] in der Version 4
verwendet, obwohl die schon länger spezifizierte Version 6 erhebliche Vorteile bezüglich
der Priorisierung von Datenpaketen und der Sicherheit aufweist.
IP ist ein verbindungsloses Protokoll in der Schicht 3 (Netzwerkschicht) des ISO/OSIModells und wird daher gemeinhin als Routingprotokoll bezeichnet. Neben anderen
Informationen enthält der Protokollheader vor allem die Ziel- und Sendeadresse und
das Type of Service (ToS)-Feld. Über dieses Feld können QoS-Mechanismen gesteuert
werden.
Das IPv4 fügt den VoIP-Datenpaketen einen zusätzlichen Header von 20 Byte hinzu,
in der Version 6 sind es sogar 40 Byte.
Transmission Control Protocol (TCP) Die Signalisierung bei VoIP findet gemeinhin
über TCP/IP statt, da TCP [IETF80a] einen bestätigten und flusskontrollierten Dienst
für die zuverlässige Übermittlung von Daten bietet. Ein TCP-Header ist minimal 20
Byte lang.
User Datagram Protocol (UDP) Das UDP [IETF80b] ist ein einfaches, verbindungsloses Protokoll der Schicht 4 und zeichnet sich vor allem durch den minimalen Overhead
aus, den es einem Paket hinzufügt. Im Gegensatz zum Transmission Control Protocol
(TCP), dem anderen weit verbreiteten Protokoll der Schicht 4, verfügt es über keinerlei
Mechanismen, die zuverlässigen Transport gewährleisten. Der Header ist sehr einfach
aufgebaut und fügt den VoIP-Daten 8 Byte hinzu.
Aufgrund des einfachen Aufbaus und der Tatsache, dass es bei Multimediadatenströmen weniger auf Paketverluste als auf Schnelligkeit und Größe ankommt, findet bei
VoIP in der Regel UDP in Verbindung mit RTP Verwendung.
Als Alternative für fehlerbehaftete Übertragungswege ist noch UDPlite (RFC 3828)
zu nennen. Dieses funktioniert ähnlich wie UDP, unterstützt aber Anwendungen, die
auch von teilweise korrekt übertragenen Paketen profitieren. Es findet im Großteil der
Fälle keine Verwendung.
2 Grundlagen
13
Realtime Transfer Protocol (RTP) Das RTP [IETF03b] wird zur Übertragung
von verzögerungsempfindlichem Verkehr über Paketnetzwerke eingesetzt. Es setzt auf
UDP/IP auf. Der RTP-Header erweitert die Informationen aus den Headern der darunterliegenden Protokolle im Wesentlichen um Sequenznummer und Zeitstempel, die
für Echtzeitanwendungen wichtig sind. Die Benutzung von RTP wird in Profilen spezifiziert, beispielsweise dem Audio-Video-Profil (RFC 3551). Der RTP-Header hat üblicherweise eine Länge von 12 Byte und ist folgendermaßen aufgebaut (vgl. Abbildung
2.4).
V P X
M Payload type
CC
Sequence number
Timestamp
Synchronization source identifier (SSRC)
Contributing source identifier (CSRC)
Size
Profile-dependent
Data
1
32
Abbildung 2.4: RTP-Header [IETF03b]
V(ersion): die RTP-Version, aktuell Version 2;
P: Padding bit, zeigt an, ob die Nutzlast ergänzt wurde;
X: Extension bit, zeigt an, ob Erweiterungen vorhanden sind;
CC: gibt an, wieviele Contributing Source Identifier (CSRC) dem Header folgen,
üblicherweise sind das null;
M: Marker bit, hat verschiedene Verwendungen, die im RTP-Profil definiert wer-
den; H.225.0 setzt das Bit für Codecs die VAD unterstützen;
Payload type: gibt die Art der Nutzdaten an und wird von der Anwendung oder
dem RTP-Profil festgelegt; im Folgenden sind einige Typzuweisungen aufgeführt,
welche von SIP und H.225 benutzt werden:
– 0 = PCM, µ-law
– 8 = PCM, a-law
– 9 = G.722
– 4 = G.723
2 Grundlagen
14
– 15 = G.728
– 18 = G.729;
Sequence number und Timestamp: Eine fortlaufende Nummer wird jedem RTP-
Paket zugewiesen, damit der Empfänger die Reihenfolge ordnen kann; hinzu
kommt eine eindeutige Zeitangabe, um Größen wie Jitter und Delay berechnen
zu können;
Synchronization source identifier (SSRC): identifiziert den Sender eines RTP-
Paketstroms;
Contributing source identifier (CSRC): identifiziert die z.B. durch einen RTP-
Mixer hinzugefügten RTP-Paketströme.
sRTP ist die verschlüsselte Version des RTP-Protokolls, es benutzt den Advanced
Encryption Standard (AES). Nähere Informationen hierzu finden sich in [Bada05].
Realtime Control Protocol (RTCP) Eine RTP-Sitzung benutzt zwei UDP-Ports,
einen geraden für den RTP-Verkehr und den darauffolgenden ungeraden für die RTCPNachrichten. Das RTCP-Protokoll liefert verschiedene Informationen, vor allem über
die Qualität der Verbindung.
Zur Unterstützung der IP-Telefonie ist das RTCP erweitert worden. Das neue Protokoll RTCP Extended Reports (RTCP XR) [IETF03c] liefert zusätzliche Informationen
über den R-Faktor, MOS-Werte und PLC. Unterstützt wird dieses Protokoll bislang
nur von den Firmen Telchemy und Psytechnics, wobei bereits Lizenzen an Hersteller
von VoIP-Client-Software vergeben werden.
Headerkomprimierung Bei Datenverbindungen mit geringen Datenraten (z.B. bei
Funkverbindungen) ist eine effiziente Übermittlung nicht zuletzt aus wirtschaftlichen
Gründen wünschenswert. Der Protokolloverhead fällt bei VoIP-Verkehr besonders ins
Gewicht, da die Pakete relativ klein sind (z.B. G.711-Sprachcodec mit 160 Byte, G.729Sprachcodec mit 20 Byte). Zu diesen Nutzdaten kommt der Paketkopf, der bei Übertragung über RTP, UDP und IP insgesamt 40 Byte groß ist. Zur Effizienzsteigerung
gibt es verschiedene Verfahren die Protokollheader zu komprimieren.
Mittels cRTP [IETF99b] ist es möglich, entweder nur den Header des RTP-Pakets
oder den gesamten IP/UDP/RTP-Header auf zwei bis vier Byte zu reduzieren. Die
Erweiterung dieses Standards ist das Verfahren Enhanced cRTP (ECRTP) [IETF03a],
2 Grundlagen
15
das die Nachteile von cRTP bei Paketverlusten und langen Laufzeiten teilweise kompensieren kann. Die Robust Header Compression (ROHC) [IETF01] reduziert die
RTP/UDP/IP-Header typischerweise auf ein bis drei Byte und ist besonders gut für
verlustreiche Verbindungen geeignet.
2.1.3.2 Signalisierungsprotokolle
Bei VoIP werden je nach Hersteller der Geräte oder der Software verschiedene Signalisierungsprotokolle verwendet. In diesem Abschnitt werden die wichtigsten vorgestellt, es
sei allerdings darauf hingewiesen, dass neben den standardisierten Protokollen auch
proprietäre Protokolle existieren, auf welche in dieser Arbeit nicht näher eingegangen
wird. Das berühmteste Beispiel ist sicherlich Skype, das weltweit über 100 Millionen
registrierte Benutzer hat [Skyp06].
Das im Augenblick am meisten erwähnte und auch in vielen Endgeräten implementierte Protokoll ist SIP. Sehr bekannt, allerdings im Zusammenhang mit VoIP nicht so
häufig genannt, ist das Protokoll für paketbasierte Multimediadienste H.323. Es gibt
noch weitere Signalisierungsprotokolle, die im VoIP-Bereich Einsatz finden, aber nicht
in einer End-to-End-Verbindung verwendet werden. Diese Protokolle sind Steuerungsprotokolle für Media- und Signalisierungsgateways, sie steuern die oft sehr komplexen
Verbindungsabläufe. Typische Vertreter hierfür sind das Media Gateway Control Protocol (MGCP) oder Megaco/H.248, auf die in dieser Arbeit nicht näher eingegangen
wird.
Die Open Source Software Asterisk unterstützt beispielsweise SIP, H.323, MGCP,
das Skinny Client Control Protocol (SCCP) und das Asterisk-eigene Protokoll InterAsterisk Exchange (IAX). Eine sehr gute Übersicht der Signalisierungsprotokolle befindet sich in [HePG05].
Session Initiation Protocol (SIP) Das SIP [IETF02a] in der aktuellen Version 2.0
ist eine Dachspezifikation, die ihrerseits auf einige andere Spezifikationen verweist. Die
wichtigsten seien im Folgenden genannt:
RFC 3262 [IETF02b]: Reliability of Provisional Responses in Session Initiation
Protocol, beschreibt die Zusammenarbeit von SIP mit dem Telefonnetzwerk;
RFC 3263 [IETF02c]: Session Initiation Protocol (SIP): Locating SIP Servers,
beschreibt das Auffinden von SIP-Servern;
2 Grundlagen
16
RFC 3264 [IETF02d]: An Offer/Answer Model with Session Description Protocol
(SDP); hier wird die Nutzung von SDP für die Aushandlung der Kommunikationsparameter wie z.B. verwendeter Codec, Ziel und Transportprotokoll beschrieben,
sowohl zu Beginn als auch während einer Sitzung;
RFC 3265: Session Initiation Protocol (SIP)-specific Event Notification; dieses
RFC beschreibt, wie DTMF-Signale zu transportieren sind, ist aber eigentlich
für Instant Messaging vorgesehen;
RFC 3266 [IETF02e]: Support for IPv6 in Session Description Protocol (SDP),
Enthält die Unterstützung für IPv6.
Obwohl SIP im Bereich der IP-Telefonie sehr verbreitet ist, beschreibt es allgemein
die Etablierung einer Sitzung, beispielsweise auch für Multimediaanwendungen oder
Computerspiele. Ziel der Konzeption war ein möglichst einfaches und schnelles Protokoll, was dazu führte, dass die verschiedenen Schichten nicht klar getrennt wurden
[HePG05, S.159 ff].
Grundsätzlich kommuniziert SIP über transactions, die mit der HTTP/1.1 Syntax
codiert werden. Dabei ist eine transaction eine Anfrage (request), die bestimmte Aktionen (actions) und Antworten (responses) verlangt, bis hin zu einer finalen Antwort.
Dabei heißt der Initiator einer solchen transaction immer SIP-Client, der antwortende
Teil SIP-Server.
SIP-Adressen werden Uniform Resource Identifier (URI) genannt, definiert in RFC
2396. Generell hat ein solcher URI die Form sip:user:password@host:port;uri-parameters?headers. Ein Beispiel wäre der URI sip:[email protected], wobei 3228177 der
Benutzername ist und sipgate.de der Hostname.
Ein einfacher Dialog zwischen zwei Endsystemen (vom SIP-RFC user agents genannt), im Beispiel gekennzeichnet mit Christiane und Stefan, gestaltet sich wie in
Abbildung 2.5 dargestellt.
Der INVITE request zeigt an, dass Christiane zu Stefan eine Verbindung aufbauen
möchte, normalerweise werden alle verbindungsrelevanten Parameter übergeben. Darauf folgt von Stefan eine provisional response um anzuzeigen, dass der user agent
das ankommende Gespräch signalisiert. Die final response (200 OK) signalisiert das
Zustandekommen der Session mit den für Stefan relevanten Parametern. Das ACK
stellt eine einfache Bestätigung der final response dar. Nach der final response wird
die RTP-Verbindung etabliert, es können Daten ausgetauscht werden. Die Verbindung
wird durch ein bestätigtes BYE request beendet.
2 Grundlagen
17
Abbildung 2.5: SIP-Dialog [Eigene Darstellung]
SIP kennt viele Möglichkeiten für die Handhabung von Verbindungen. Die wichtigsten Elemente, die dabei benutzt werden, sind hier kurz erläutert.
Zunächst gibt es den registrar. Ein registrar ist ein Server, der auf REGISTER
requests antwortet, er übernimmt die Auflösung der URI in eine IP-Adresse.
Ein proxy server sollte im Idealfall möglichst transparent sein hinsichtlich der gesendeten Nachrichten und diese nur in sehr begrenztem Ausmaß verändern. Er kann allerdings weitaus mehr tun, beispielsweise Benutzer authentifizieren, Adressen auflösen
oder Verbindungen beenden. Je nach Grad der Einflussnahme auf die SIP-Nachrichten
unterscheidet man zwischen einem stateless proxy, einem stateful proxy und einem
back-to-back user agent.
Ein stateless proxy leitet im Prinzip nur SIP-Nachrichten weiter, die Informationen
erhält er aus dem Header der Nachricht selbst. Er verfolgt den Status eines Gespräches
nicht, ganz im Gegensatz zu einem stateful proxy. Dieser nimmt den Status einer Verbindung wahr und kann deshalb bestimmte Aufgaben übernehmen, wie beispielsweise
die Auswahl einer alternativen Verbindungsroute oder Abrechnungsaufgaben. Für weitergehende Aufgaben findet der back-to-back user agent Verwendung, der sich für
den Anrufer und den Angerufenen wie ein user agent verhält und deshalb nicht denselben Restriktionen unterworfen ist wie die vorher beschriebenen SIP-Proxies. Beispiele
für solche weitergehenden Anwendungen sind Anwendungen in der Geschäftstelefonie.
Nähere Informationen zum SIP-Protokoll können in [TrWe05] nachgelesen werden.
H.323 H.323 [ITU-03b] ist ein Protokoll, das Multimediakommunikation zwischen
einem oder mehreren Teilnehmern über ein paketbasiertes Netzwerk ermöglicht. Dabei
2 Grundlagen
18
muss dieses Netzwerk nicht zwingend ein IP-Netzwerk sein, die Spezifikation gilt auch
für Internetwork Packet Exchange (IPX) und Asynchronous Transfer Mode (ATM).
Seit der ersten Version des Protokolls, die für lokale Netzwerke gedacht war und aus
der Netmeeting Anwendung des Windows Betriebssystems bekannt ist, hat sich die
Spezifikation ständig weiterentwickelt.
H.323 umfasst nicht nur ein Protokoll, sondern ist eine Dachspezifikation für verschiedene zusammengehörige Protokolle, die alle miteinander im Zusammenhang stehen. Die
wichtigsten sind H.255 (ITU) und H.245 (ITU).
Der Ablauf der Kommunikation sei an einem Beispiel mit zwei PCs mit H.323-Clients
erklärt: Wenn die IP-Adresse der Gegenstelle bekannt ist, gibt der Benutzer die Adresse
und seinen Verbindungswunsch ein. Daraufhin baut der Client mit der Gegenseite eine
TCP-Verbindung nach H.225 auf, es werden zum Aufbau der Verbindung Nachrichten
nach Q.931 (ITU) verschickt. Üblicherweise wird diese Verbindung auf Port 1720 (well
known port) initiiert. Bei erfolgreicher Verbindung wird eine zweite TCP-Verbindung
nach H.245 aufgebaut, diese dient zum Auf- und Abbau und der Steuerung der Medienkanäle. Über den Kontrollkanal werden die Medienkanäle vereinbart und aufgebaut,
wobei der Verkehr über RTP/UDP abgewickelt wird. Der Abbau der Verbindung funktioniert reziprok.
Für den Fall einer unbekannten IP-Adresse oder um erweiterte Möglichkeiten des
Protokolls zu nutzen, gibt es den Gatekeeper. Beim Start einer H.323-Software sucht
der Client zunächst nach dem für ihn vorgesehenen Gatekeeper, um sich im Erfolgsfall
zu authentifizieren. Für den Kommunikationsaufbau mit dem Gatekeeper existieren
zwei unterschiedliche Modi. Im direct mode dient der Gatekeeper nur als eine Art Verzeichnisdienst, der Client meldet den Verbindungswunsch an, er fragt den Gatekeeper
nach der IP-Adresse der Gegenstelle, dieser antwortet, eventuell nach Rückfrage bei
dem Gatekeeper der Gegenstelle. Es folgt ein Verbindungsaufbau wie oben beschrieben, die beiden TCP-Verbindungen und die RTP/UDP-Verbindungen werden direkt
zwischen den Clients aufgebaut. Beim Beenden der Verbindung muss das Ende der Verbindung zwingend an den Gatekeeper gemeldet werden, da eine Verbindung nicht nur
direkt zu einem Client hergestellt werden kann, sondern auch z.B. zu einem IP/PSTNGateway (Public Switched Telephone Network ). Der Gatekeeper übernimmt auch die
Verwaltung der auf diesem Gateway zur Verfügung stehenden Ressourcen.
Im routed mode wird der Signalisierungsverkehr, die beiden TCP-Verbindungen nach
H.225 und H.245, über die Gatekeeper abgewickelt. Lediglich die Medienströme werden direkt zwischen den Clients etabliert. Aus diesem Sachverhalt ergeben sich mehrere
Vorteile. Als wichtigste seien hier genannt, dass der Gatekeeper die Signalisierungsinfor-
2 Grundlagen
19
mationen auswerten und auf sie reagieren kann (z.B. bei einem abgelehnten Gespräch
Q.850-Release-Codes auswerten). Auch das Accounting und die Sicherheit der übermittelten Informationen wird dadurch verbessert, selbst bei einer Informationsübertragung
über mehrere Gatekeeper hinweg.
2.1.4 Quality of Service
Die Sprachqualität wird wesentlich durch die Eigenschaften des Netzwerks bestimmt.
Im Einzelnen sind das die verfügbare Bitrate, die Verzögerung der Pakete (Delay), die
Abweichung der Ankunftszeiten der Pakete (Jitter) und Paketverluste (packet loss).
Um eine zufriedenstellende Sprachqualität zu erreichen, sollten Laufzeiten, Jitter und
Paketverluste möglichst minimiert werden. Der Schwerpunkt sollte auf den geringen
Laufzeiten liegen, da VoIP-Gespräche robuster auf den Verlust von Paketen als auf
lange Laufzeiten reagieren (siehe Kapitel 2.1.2). In den nächsten Abschnitten sollen
die genannten Parameter näher betrachtet werden.
2.1.4.1 Parameter
Bitrate Die mögliche Bitrate über eine drahtlose Verbindung muss groß genug sein,
um den Strom an Sprachpaketen mit dem Protokolloverhead, verursacht durch die
IP/UDP/RTP-Header und den Overhead der Technologie, zu übertragen.
Bei Sprachcodierung mit G.729 entstehen 10 ms Frames mit jeweils 10 Byte. Wenn
man einen Frame pro IP-Paket (40 Byte Header) überträgt, erhält man eine resultierende Datenrate von 40 kBit/s. Bei Verwendung von zwei Frames pro Paket ergibt sich
eine Bitrate von 24 kBit/s, auf Kosten der Latenz eines weiteren Rahmens (10 ms).
Drei Frames pro Paket ergeben eine Bitrate von 18,6 kBit/s, mit einer zusätzlichen
Verzögerung von 20 ms.
Sprachcodierung mit G.711 würde bei Transport von 10 ms Sprache in einem Paket
eine Bitrate von 96 kBit/s ergeben, bei 20 ms Sprache pro Paket wären es 80 kBit/s.
Um die Mindestbitrate abzuschätzen, wird ein Codec mit einer niedrigen Datenrate
gewählt (z.B. G.723.1). Zusätzlich werden die IP/UDP/RTP-Header mit cRTP komprimiert (siehe Abschnitt 2.1.3.1). Damit ergibt sich eine Bitrate von nur 6,4 kBit/s.
Hinzu kommt der durch die verwendete Übertragungstechnologie hervorgerufene Overhead.
Die Wahl der Anzahl der Frames für einen Codec ist immer ein Kompromiss zwischen
großer Datenrate und hoher Latenz.
2 Grundlagen
20
Delay Mit Verzögerung (Delay) oder Latenzzeit ist in diesem Zusammenhang das so
genannte end-to-end-Delay gemeint, das alle Verzögerungen einer Übertragung beinhaltet. Neben dem coder-related-Delay (siehe Abschnitt 2.1.2) entstehen Verzögerungen
durch die Verarbeitung im Protokollstapel, die Übertragung durch das Netzwerk und
durch Puffer.
Die ITU-Empfehlung G.114 [ITU-03a] setzt den Maßstab für die Gesamtverzögerung
von VoIP auf Basis des E-Model, wie in folgender Tabelle 2.3 dargestellt.
Verzögerung
< 150 ms
150 - 400 ms
< 400 ms
Sprachqualität
Gute Qualität
Akzeptable Qualität
Schlechte Qualität
Tabelle 2.3: G.114 - Verzögerung und Sprachqualität [ITU-03a, S.2]
Jitter Jitter ist die statistische Abweichung bei der Ankunftszeit der Pakete, die
durch den Transfer über das IP-Netzwerk verursacht wird. Im Zusammenhang mit
drahtlosen Netzen wird Jitter hauptsächlich durch nötige Wiederübertragungen von
verloren gegangenen Paketen verursacht.
Der Jitter beeinflusst die Kommunikation in folgender Weise: Eine Pufferung der
Pakete ist notwendig, um den Jitter zu kompensieren und die Pakete, falls nötig, wieder
in die richtige Reihenfolge zu bringen [Hard03, S. 17]. Da ein solcher Puffer (JitterPuffer) die Informationen zwischenspeichert, trägt er automatisch zur Verzögerung bei.
Je größer also der Jitter ist, desto größer muss der Jitter-Puffer dimensioniert werden
und desto länger wird auch die Gesamtverzögerung. Moderne Codecs unterstützen das
dynamische Anpassen dieses Puffers, um die Verzögerung möglichst gering zu halten.
Packet loss Der Paketverlust (packet loss) kennzeichnet die Anzahl der verloren
gegangenen Pakete in einer Kommunikationsverbindung. Dabei spielt es eine Rolle,
ob der Verlust von Paketen verteilt oder stoßartig auftritt. Eine VoIP-Verbindung ist
oftmals in der Lage, eine gewisse Menge an Paketverlusten zu kompensieren, meistens
durch in den Codecs integrierte Methoden (PLC, siehe Abschnitt 2.1.2).
2.1.4.2 Zusammenfassung
Wie aus den Erläuterungen hervorgeht, sind nicht alle QoS-Größen gemeinsam optimierbar. Um möglichst geringe Latenzwerte zu erreichen, wäre es vorteilhaft, möglichst
kurze Pakete zu versenden, die mit einem Codec komprimiert sind, der möglichst kurze
2 Grundlagen
21
Sprachabschnitte komprimiert und keine Zeit für look-ahead benötigt. Diese Codecs
besitzen aber eine relativ hohe Datenrate. Hinzu kommt, dass der Protokolloverhead
mit der Menge der pro Zeiteinheit übertragenen Pakete wächst. Um eine effiziente
Nutzung der vorhandenen Übertragungskapazität zu ermöglichen, sind dagegen große
Pakete mit stark komprimierenden Codecs wünschenswert. Neben der schlechteren
Sprachqualität wird die Latenzzeit sehr groß. Das Optimum ist somit ein Kompromiss
zwischen Datenrate und Latenzzeit. Zu berücksichtigen sind in dieser Arbeit vor allem
Verzögerungen und der Overhead, der durch die drahtlosen Technologien verursacht
wird.
2.1.5 Resultierende Anforderungen
Aus dem Vorangegangenen wird ersichtlich, dass die paketbasierte Sprachkommunikation von vielen Faktoren abhängt. Die daraus resultierenden Anforderungen an eine
drahtlose Übertragungstechnologie sind folgende:
Bitrate: Die Übertragungstechnologie muss eine ausreichende Datenrate zur Ver-
fügung stellen können. Die aus der Bitrate des verwendeten Codecs und der zusätzlichen Headerinformationen der RTP/UDP/IP-Pakete resultierende Bitrate
muss problemlos übertragen werden können. Bei gleichzeitiger Übertragung mehrerer Gespräche oder anderer Datenverbindungen muss die Datenrate zur Verfügung stehen. Aus vorhergehenden Betrachtungen ergeben sich auf Netzwerkebene
Bitraten für ein VoIP-Gespräch zwischen 96 kBit/s (G.711 - 10 ms frames) und
6,4 kBit/s (G.723.1 - 30 ms frames).
Delay: Zielwert für die Verzögerung ist laut G.114 [ITU-03a] ein Wert von weniger
als 150 ms, Werte unter 400 ms sind noch akzeptabel, alles darüber hinaus ist
für eine Sprachkommunikation nicht geeignet.
Jitter: Die ITU-T empfiehlt einen Wert von weniger als einer Millisekunde [ITU-01a]
nach Verwendung eines Jitter-Puffers.
Packet loss: Der Verlust von Paketen kann oftmals von den Codecs kompensiert
werden. Die Robustheit der Codecs unterscheidet sich. Der Verlust von mehreren
Paketen hintereinander ist besonders problematisch. Die Empfehlung der ITU-T
[ITU-01a] setzt den Sollwert auf weniger als 3% Packetverlustrate fest, obwohl
einige Codecs höhere Verluste kompensieren können.
2 Grundlagen
22
2.2 IP über Funkstrecken
Drahtlose Netze arbeiten meistens mit einer zentralen Basisstation, die eine Funkzelle
aufspannt. An diesem Sender melden sich die Endgeräte an und tauschen Daten aus.
Bei der Signalausbreitung treten verschiedene Effekte auf, die kurz erläutert werden
sollen:
Dämpfung: Die empfangene Leistung nimmt mit dem Quadrat der Entfernung zur
Basisstation ab. Die Dämpfung kann zusätzlich durch Umwelteinflüsse wie Regen,
Nebel oder Hindernisse wie Bäume oder Mauern vergrößert werden. Generell
gilt, dass niedrigere Frequenzen Objekte besser durchdringen können als höhere
Frequenzen.
Abschattung: Das Signal wird von einem Objekt vollkommen absorbiert.
Reflexion: Gebäude oder andere Hindernisse können das Signal reflektieren. Die-
ser Effekt wird ausgenutzt bei Verbindungen, bei denen kein Sichtkontakt besteht.
Brechung/Refraktion: Der Weg des Signals wird bei unterschiedlich dichten Aus-
breitungsmedien in seiner Richtung verändert.
Beugung: Ähnlich wie Licht wird das Signal beispielsweise an einer Kante oder
einem Berggipfel gebeugt.
Streuung: An Objekten, die etwa dieselbe Größe wie die Wellenlänge des Signals
haben, kann Streuung auftreten, d.h. das Signal wird in mehrere schwächere
Signale aufgespaltet.
Eines der größten aus diesen Effekten enstehenden Probleme ist die Mehrwegeausbreitung. Dadurch, dass sich das Signal auf verschiedenen Wegen ausbreitet, wird der
gesendete Impuls am Empfänger breiter. Funktechnologien verwenden zur Verminderung dieses Effektes Schutzzeiten; reichen diese nicht aus, kommt es zur Intersymbolinterferenz (ISI). Ein weiteres Problem, das besonders bei sich bewegenden Empfängern
auftritt, ist das Fading. Dabei kommt es zur Überlagerung einzelner Signalanteile, so
dass die empfangene Leistung stark variiert. Man unterscheidet dabei längerfristigen
Signalschwund (long term fading) von kurzfristigen Änderungen (fast fading).
Neben diesen physikalischen Effekten wird die Qualität des Übertragungsweges von
Störquellen beeinflusst, beispielsweise Funksignale aus Nachbarzellen oder die Überlagerung von Signalen zweier Endgeräte in einer Zelle.
2 Grundlagen
23
Diesen vielfältigen Faktoren versuchen moderne Technologien mit verschiedenen Mechanismen entgegenzuwirken. Zum einen kann ein geeignetes Übertragungsverfahren
wie CDMA oder OFDM den Einfluss dieser Faktoren vermindern. Zum anderen nutzen
Funknetze in ihrer Codierung Methoden zur Forward Error Correction (FEC) und die
Verteilung zusammengehöriger Daten auf unterschiedliche Funkblöcke (Interleaving),
um Übertragungsfehler korrigieren zu können. Außerdem verwenden die meisten Funknetze ein sehr präzises System der Leistungssteuerung, um zu vermeiden, dass sich
starke und schwache Sender gegenseitig stören.
24
3.1 Einleitung und Übersicht
In diesem Kapitel werden ausgewählte Mobilfunktechnologien hinsichtlich ihrer Eignung für die Übertragung von VoIP-Gesprächen betrachtet. Dazu wird zunächst die
Funktionsweise beschrieben, um anschließend eine Abschätzung über die zu erwartenden Verzögerungszeiten und die Anzahl der maximal möglichen Verbindungen geben
zu können. Bei der Beschreibung wird ausschließlich auf Aspekte der Funkübertragung
eingegangen, die einen Einfluss auf die VoIP-Parameter haben. Effekte eines eventuell
vorhandenen Kernnetzes werden nicht berücksichtigt.
Die Auswahl beschränkt sich auf verbreitete Technologien. Übertragungsverfahren,
die auf Leitungsvermittlung beruhen, wie beispielsweise GSM oder High-Speed CircuitSwitched Data (HSCSD), werden ausgeschlossen. VoIP-Gespräche über diese Verfahren
sind eventuell möglich, nutzen aber die Effizienz der Paketvermittlung nicht aus.
Allgemein werden drahtlose Datennetze nach Reichweite und Verwendungszweck in
die Kategorien Personal Area Network (PAN), Local Area Network (LAN), Metropolitan Area Network (MAN) und Wide Area Network (WAN) eingeteilt. Ein PAN ist ein
Netz mit geringer Reichweite, das beispielsweise eine Wohnung umfasst. Ein LAN kann
einen größeren Umfang haben, z.B. den Campus einer Universität oder ein Firmennetz.
Dabei gibt der Name schon darüber Auskunft, dass dieses Netz nicht mehr nur zum
persönlichen Gebrauch bestimmt ist. Die nächste Stufe stellt das MAN dar, das ganze
Städte umfassen kann, gefolgt von dem WAN, das alle größeren Netze umfasst.
VoIP über eine drahtlose Verbindung beinhaltet immer den Transport von IP-Paketen.
Es sollte beachtet werden, dass die Möglichkeit, das Sprachsignal drahtlos zu einer Basisstation zu übertragen und dann in der Basis erst in Pakete zu konvertieren, häufig
genutzt wird. Dafür eingesetzte Verfahren sind vor allem Bluetooth im verbindungsorientierten Modus und die Digital Enhanced Cordless Telecommunications (DECT)Technologie.
Als Vertreter der Datennetze werden im Folgenden Bluetooth, Wireless LAN (WLAN)
und, aufgrund des augenblicklichen Interesses, Worldwide Interoperability for Microwa-
25
ve Access (WiMAX) betrachtet. Daneben erfolgt auch eine Analyse der Mobilfunknetze,
die sich von reinen Sprachtelefonienetzen hin zu Datennetzen entwickeln.
3.2 Bluetooth
Bluetooth ist ein Industriestandard für eine Funktechnologie zum Aufbau von Piconetzen (Netze geringer Reichweite) und arbeitet im ISM-Band bei 2,4 GHz. Die Funktionsweise der unteren Schichten ist von der IEEE im Standard 802.15.1 [IEEE05b] definiert.
Der Bluetooth-Standard [SIG04] wird von der Bluetooth Special Interest Group (SIG)
verwaltet, einem Konsortium verschiedener Unternehmen, dem unter anderem IBM,
Intel, Microsoft und Nokia angehören.
Ursprünglich war die Bluetooth-Technologie gedacht für den Ersatz von Kabeln zwischen verschiedenen Endgeräten auf kurze Distanzen bis etwa 10 m (Wireless Personal
Area Network (WPAN)). Sie erlaubt die Übermittlung von Sprache und Daten. Bluetooth wird eingesetzt für die drahtlose Verbindung von Rechnern, PDAs, Handys und
Headsets, sowie von Peripheriegeräten. Während die Standards Protokolle und Aufbau
dieser Technologie festlegen, beschreiben Profile, wie diese zusammen benutzt werden,
um einen bestimmten Zweck zu erfüllen.
Für den Transport von IP-Paketen gibt es mehrere Möglichkeiten. Zum einen besteht die Möglichkeit, eine Point-to-Point (P2P)-Verbindung über eine emulierte serielle Schnittstelle herzustellen (LAN Access Profil), zum anderen spezifiziert ein relativ
neues Profil die Kapselung von IP-Paketen durch die Emulation einer Ethernetschnittstelle. Dieses Personal Area Network (PAN)-Profil wird vorrangig betrachtet, da es
einen geringen Protokolloverhead verursacht und Vorteile bei der Weiterleitung der
Pakete bietet.
Weiterhin findet im VoIP-Bereich das Headset Profile (HSP) Anwendung, das es erlaubt, ein Headset an ein beliebiges Gerät zu koppeln. Das Cordless Telephony Profile
(CTP) verbindet ein bluetoothfähiges Handy als mobiles Endgerät mit einer Basisstation ähnlich dem DECT-System. Allerdings sind zum Zeitpunkt der Entstehung dieser
Arbeit keine Endgeräte auf dem Markt erhältlich, die dieses Profil unterstützen. Die
Firma IVT [IVT 06] hat mit dem Modell IVT CTP-GSM 0100 eines angekündigt.
3.2.1 Funktionsweise
Die Bluetooth-Spezifikation liegt aktuell in der Version 2.0 mit der Erweiterung für
Enhanced Data Rates (EDR) vor. Diese Version erreicht eine Bruttobitrate von 3
26
MBit/s, während vorhergehende Versionen nur mit 1 MBit/s Bruttobitrate kommunizieren. Weit verbreitet sind ältere Bluetooth-Versionen bei Geräten, die keine hohe
Datenrate benötigen.
Kommunizierende Bluetooth-Geräte bilden ein Piconetz, das initierende Gerät einer
Verbindung nimmt die Rolle des Masters ein, der den Zugriff auf den Kanal kontrolliert. Beteiligte Geräte werden anhand ihrer Hardwareadresse identifiziert. Es können
bis zu 256 Geräte (Slaves) an einem Piconetz teilnehmen, nur sieben Geräte können
gleichzeitig eine Verbindung zum Master unterhalten. Um unterschiedlichen Anforderungen Rechnung zu tragen, kann das Verhältnis Master-Slave getauscht werden. Alle
teilnehmenden Geräte werden durch eine 8 Bit ID-Kennung identifiziert, aktive Geräte
erhalten eine Zusatzkennung bestehend aus 3 Bit. Bluetooth-Geräte können gleichzeitig an mehreren Piconetzen teilnehmen und so ein vermaschtes Netzwerk entstehen
lassen (Scatternet). Diese Option wird in dieser Arbeit nicht betrachtet.
Die maximale Datenrate eines Bluetooth-Kanals (Version 1.2) beträgt 723,2 kBit/s,
bzw. 2178,1 kBit/s in der Version 2.0 mit EDR [SIG04]. Es sind asynchrone und synchrone Verbindungen möglich, die Spezifikation trennt in leitungsvermittelte Sprachübertragung und paketvermittelte Datenverbindungen.
3.2.2 Bluetooth-Protokollstack
Der Bluetooth-Protokollstack hält sich nur begrenzt an die Schichtendefinition des
ISO/OSI-Modells, die Schichten übernehmen zum Teil Aufgaben unterschiedlicher OSISchichten. Der Stack ist in Abbildung 3.1 dargestellt.
Abbildung 3.1: Bluetooth-Stack nach [SIG04, S.21]
27
Die unteren Schichten bis zum Host Controller Interface (HCI) werden normalerweise in Hardware implementiert.
Radio Layer Bluetooth verwendet im ISM-Band 2,4 GHz Kanäle mit einer Bandbreite von einem MHz. Das eingesetzte Duplexverfahren ist Time Division Duplex (TDD),
die Übertragungen vom Master- zum Slave-Gerät (Downlink) sind zeitlich getrennt
von den Übertragungen in die entgegengesetzte Richtung (Uplink). Eingesetzte Modulationsverfahren sind Gaussian Freqency Shift Keying (GFSK) für niedrige Übertragungsgeschwindigkeiten, sowie Differential Quarternary Phase Shift Keying (DQPSK)
und 8 Phase Shift Keying (8PSK) für das EDR-Verfahren. Damit können mittels EDR
2 Bit/Symbol (Bruttobitrate 2 MBit/s) bzw. 3 Bit/Symbol (Bruttobitrate 3 MBit/s)
übertragen werden. Der Kanal wird in Zeitschlitze (TDD) von je 625 µs Dauer unterteilt, in denen die Datenrahmen übertragen werden. Von einem Sender können mehrere
Zeitschlitze hintereinander belegt werden.
Um gegen Störungen resistent zu sein, benutzt Bluetooth Frequency Hopping Spread
Spectrum (FHSS), nach jeder zusammenhängenden Übertragung wird auf einen anderen der 79 zur Verfügung stehenden Kanäle gewechselt. Um breitbandigen Störungen
wie beispielsweise durch WLAN entgegen zu wirken, wurde mit der Version 1.2 das
Adaptive Frequency Hopping (AFH) eingeführt. Diese Funktion erlaubt es dem Master,
auf den Kanälen eine Kanalabschätzung bezüglich der Übertragungsfähigkeit durchzuführen und daraus eine Tabelle zu generieren, die für das FHSS Verwendung findet.
Die Spezifikation kennt drei Leistungsklassen von Bluetooth-Sendern, die sich durch
ihre Sendeleistung und damit durch ihre Reichweite unterscheiden (siehe Tabelle 3.1).
Leistungsklasse
Class 1
Class 2
Class 3
Max. Sendeleistung
100 mW
2,5 mW
1 mW
Reichweite
ca. 100 m
ca. 30 m
ca. 10m
Tabelle 3.1: Bluetooth-Leistungsklassen [SIG04, S.31]
Baseband Layer Der Baseband Layer setzt auf der physikalischen Schicht auf und
übernimmt typische Aufgaben eines Schicht-2-Protokolls, unter anderem das Verpacken der Pakete in zur Übertragung geeignete Frames (framing). Hier bietet Bluetooth
drei verschiedene Typen von Rahmen (Frames): Asynchronous Connectionless (ACL),
Synchronous Connection Orientated (SCO) und Enhanced SCO (eSCO).
28
Normalerweise werden alle Paketdaten über ACL-Frames übertragen, der einen, drei
oder fünf Zeitschlitze umfassen kann. Ein ACL-Frame besteht aus einem Accesscode
(68-72 Bit), einem Header (54 Bit), der verschiedene Informationen wie Adresse, Packettyp u.a. enthält und einer Nutzlast. Diese Nutzlast besitzt einen weiteren Header (8-16
Bit) und ein Prüfsummenfeld (CRC) von 16 Bit, um die Datenintegrität feststellen
zu können. Die Daten werden optional mit Forward Error Correction (FEC) übertragen. Die maximale Nutzlast eines ACL-Frames ohne Nutzlastkopf und CRC sind 339
Byte bzw. 1021 Byte (EDR). Es wird unterschieden in symmetrische Verbindungen,
die in beide Richtungen dieselbe Datenrate zur Verfügung stellen und asymmetrische
Verbindungen. VoIP benötigt ohne den Einsatz von VAD dieselbe Bandbreite in beide
Richtungen.
ACL Pakettyp Payload Header Datenbits/
Bit
Paket
DM1
8
136
DH1
8
216
DM3
16
968
DH3
16
1464
DM5
16
1792
DH5
16
2712
2-DH1
16
432
2-DH3
16
2936
2-DH5
16
5432
3-DH1
16
664
3-DH3
16
4416
3-DH5
16
8168
Datenrate
(kBit/s)
108,8
172,8
258,1
390,4
286,7
433,9
345,6
782,9
869,7
531,2
1177,6
1306,9
Tabelle 3.2: Symmetrische ACL-Verbindungen [Morr02, S. 176]
Die Bezeichnung der Rahmen bestimmt die Parameter - D steht für Data, M und
H für Medium (2/3 FEC) bzw. High Rate (keine FEC). Die Zahl am Anfang der
Bezeichung gibt die Bruttodatenrate an (1,2 oder 3 MBit/s), die Zahl am Ende der
Bezeichnung gibt die Anzahl der belegten Zeitschlitze an.
Daneben stellt Bluetooth für Sprachübertragung synchrone verbindungsorientierte Kanäle zur Verfügung. Bei der Übertragung über einen SCO-Kanal werden zwischen Master- und Slavegerät in regelmäßigen Intervallen Frames übertragen, so dass
die resultierende Bitrate genau 64 kBit/s entspricht. Es können maximal drei SCOVerbindungen je Master betrieben und aufrechterhalten werden. Um neuen Anforderungen z.B. durch Audio-Streaming zu entsprechen, wurden mit Version 1.2 eSCO-Kanäle
eingeführt, die ebenfalls mit fester Bandbreite und regelmäßiger Übertragung arbeiten,
29
aber eine vorher vereinbarte Bandbreite bis zu 864 kBit/s (unter Einsatz von EDR)
besitzen.
SCO-Frames enthalten immer 30 Byte Nutzlast, die auch mit FEC verwendet werden
können, so dass beispielsweise 10 Byte Daten mit 20 Byte FEC übertragen werden. Eine
Prüfsumme wird in SCO-Frames nicht gebildet.
Zur Kontrolle des Medienzugriffs wird vom Master ein Polling-Mechanismus eingesetzt, der die aktiven Clients abfragt, ob ein Sendewunsch besteht. Falls ein ACL-Frame
nicht korrekt übertragen wurde, wird über ein Automatic Repeat Request (ARQ) eine
Wiederübertragung eingeleitet. Abhängig davon, ob die vorhandene logische Verbindung ein User asynchronous (UA)-Kanal oder eine User isochronous (UI)-Kanal ist,
wird das Paket solange wiederholt (UA), bis es korrekt übertragen ist oder eine andere Protokollschicht die Wiederübertragung unterbricht. Bei UI-Verbindungen wird nur
eine bestimmte Zeitspanne lang versucht, den Rahmen neu zu übertragen.
Link Manager Die nächsthöhere Schicht ist der Link Manager, der für den Aufbau,
Abbau und die Verwaltung der Verbindungen zuständig ist. Dabei wird ein Zustandsmodell verwendet, das hier nicht näher beschrieben wird. Weiterführende Informationen
finden sich in [SIG04] und [Mull01].
Host Controller Interface (HCI) Das HCI ist bei den meisten Bluetooth-Geräten
der Schnittpunkt zwischen Hard- und Software. Ausnahme bilden beispielsweise Headsets, die alle Funktionen in Form von Hardware enthalten. Über diese Schnittstelle
werden Daten und Kommandos zwischen den oberen und unteren Protokollschichten
ausgetauscht. Als Schnittstellentypen kommen Universal Serial Bus (USB), Universal
Asynchronous Receiver and Transmitter (UART) und Secure Digital (SD) in Frage
[SIG06].
Logical Link Control and Adaption Protocol (L2CAP) Die Hauptaufgaben der
L2CAP-Schicht [SIG04, S.997ff.] sind die Verwaltung logischer Verbindungen und die
eventuelle Segmentierung der Pakete darüberliegender Schichten. Daneben erlaubt das
L2CAP-Protokoll auch die Vereinbarung von QoS-Parametern bei der Etablierung einer ACL-Verbindung. Wenn nicht im default-Modus nach der best-effort“-Methode
”
gesendet wird, können für die Garantie von QoS-Parametern Vereinbarungen über die
benötigte Bandbreite, die Spitzenbandbreite, die maximale Latenzzeit von der Generierung eines L2CAP-Paketes bis zu dessen Übertragung und über benötigte Puffer
ausgetauscht werden. Außerdem kann eine Zeit vereinbart werden, nach der die Pakete
30
verworfen werden, wenn der Übertragungsversuch fehlschlägt. Die Einhaltung dieser
Parameter wird über die Steuerung des Medienzugriffs erreicht.
SDP/RFCOMM/BNEP Auf der L2CAP-Schicht setzt eine Schicht auf, die verschiedene Protokolle unterstützt. Die wichtigsten sind das Service Discovery Protocol (SDP),
das einem Endgerät dazu dient, angebotene Dienste aufzufinden. Das Radio Frequency Comport Emulation (RFCOMM) Protokoll emuliert eine serielle Schnittstelle. Zur
IP-Paketübermittlung dient auf derselben Schicht auch das Bluetooth Network Encapsulation Protocol (BNEP) [SIG03a].
3.2.3 Relevante Profile
Für die Betrachtungen innerhalb dieser Arbeit sind im Wesentlichen zwei Profile relevant, zum einen das Personal Area Network (PAN)-Profil [SIG03b] und zum anderen
das CTP-Profil [SIG01]. Das PAN-Profil emuliert eine Ethernet-Schnittstelle, um den
Zugang zu einem LAN zu ermöglichen. Dabei werden die Daten, im betrachteten Fall
IP-Pakete, über das BNEP transportiert. Vorteil dieses Profils gegenüber beispielsweise
einer P2P-Verbindung, die über RFCOMM aufgebaut wird, ist - neben dem geringeren Overhead - die Transparenz des Transports im Hinblick auf Paketübermittlung
nach IEEE 802.3. Die L2CAP-Schicht entpricht aus Sicht des BNEP einer Medium
Access Control (MAC)-Schicht. Die IP-Pakete werden bei Übergabe über die virtuelle Ethernetschnittstelle mit einem Ethernetheader (14 Byte) versehen. Das BNEP
[SIG03a] ersetzt diesen Header durch einen eigenen, der in der Regel zwischen 3 und
17 Byte lang ist. Diese Pakete werden an die L2CAP-Schicht übergeben. Dort erhalten
sie einen weiteren Header zur Kennzeichnung der logischen Verbindung (Logical Link
Control (LLC): 4 Byte) und werden über die unteren Schichten übertragen.
Abbildung 3.2: Beispielhafter ACL-Rahmen mit VoIP-Daten [Eigene Darstellung]
Das CTP dient dazu, bluetoothfähigen Handys und anderen geeigneten Endgeräten
den Zugriff auf Telefondienste in einem Netzwerk über eine Basisstation zu ermöglichen.
Dabei werden die Sprachdaten über einen SCO-Kanal transportiert. Für diese Betrachtungen ist das Profil nur insofern relevant, als dass es Gespräche über eine VoIP-fähige
31
Basisstation ermöglicht. Der IP-Transport allerdings beginnt in diesem Falle erst in
der Basisstation.
3.2.4 Eignung für VoIP
Der Protokolloverhead bei der Übertragung von IP-Paketen ist beträchtlich. Die Nutzlast eines ACL-Paketes setzt sich beispielhaft für die Codecs G.711 und G.729 wie folgt
zusammen:
Sprachdaten: 160 Byte (G.711) oder 20 Byte (G.729);
RTP/UDP/IP-Header: 40 Byte, komprimiert nach cRTP, wird mit 2 Byte be-
rechnet;
BNEP-Encapsulation: Der BNEP-Header ist je nach Art der Kapselung zwischen
3 und 17 Byte lang;
LLC-Header: 4 Byte.
Bei Übertragung von Sprachpaketen der Länge 20 ms erhält man einen Protokolloverhead von 61 Byte (ohne cRTP) und 7 Byte (mit cRTP und Ethernet-Kompression
(BNEP)) pro Sprachdatenpaket. Daraus resultiert eine Bruttobitrate von 88,4 kBit/s
bzw. 66,8 kBit/s (cRTP bzw. kein cRTP) für den G.711-Codec und 32,4 kBit/s bzw.
19,8 kBit/s für den G.729-Codec.
Ausgegangen wird von optimalen Kanalbedingungen, es entstehen keine Fehler, Wiederübertragungen finden nicht statt. Damit ergibt sich unter der Voraussetzung, dass
keinerlei andere Daten übertragen werden und die IP-Pakete optimal auf ACL-Pakete
abgebildet werden, eine maximale Anzahl von 4 / 6 Gesprächen bei G.711 und 13 /
21 Gesprächen bei Verwendung des G.729 und der Bluetooth-Version 1.2. Bei Verwendung des EDR-Verfahrens ergibt sich entsprechend maximal die dreifache Anzahl an
möglichen Gesprächen.
Diese Zahlen werden in der Praxis nicht zu erreichen sein, zeigen aber deutlich, wie
leistungsfähig die Bluetooth-Technologie nicht zuletzt durch die eingesetzten Kompressionsverfahren ist.
Die Latenzeit eines über Bluetooth übertragenen IP-Paketes lässt sich theoretisch
nicht bestimmen. Die minimale Übertragungszeit eines ACL-Paketes lässt sich berechnen, indem man die Anzahl der benötigten Zeitschlitze mit der Dauer eines Zeitschlitzes multipliziert. Die Steuerung des Medienzugriffs durch das Mastergerät, die Qualität
32
des Kanals und konkurrierende Übertragungen können die Latenzzeiten sehr viel höher
werden lassen.
Huang und Boucouvalas haben sich in [HuBo05] mittels Analyse und Simulationen
intensiv mit der Latenzzeit von ACL-Paketen beschäftigt. Ihre Ergebnisse zeigen, dass
im Idealfall Latenzzeiten kleiner als 20 ms zu erreichen sind, schlechte Kanalbedingungen und eine höhere Anzahl an beteiligten Stationen diese aber schnell größer werden
lassen.
Kapoor et al. [KCLG02] haben in ihren Arbeiten Simulationen und Versuche mit
der Sprachübertragung über ACL-Verbindungen durchgeführt. Ihre Tests haben eine
mittlere Latenzzeit der Pakete von 15,39 ms ergeben.
Vorteile von Bluetooth für die Übertragung von VoIP-Verkehr sind die Implementierung von QoS-Mechanismen in der L2CAP-Schicht und der geringe Energieverbrauch
der Endgeräte. Nachteilig anzusetzen sind die geringe Bitrate und die geringe Reichweite. Handover-Prozeduren werden von Bluetooth nicht unterstützt.
3.3 WLAN
WLAN, oft auch als drahtloses Ethernet bezeichnet, wird vorwiegend zur kabellosen
Vernetzung von Rechnern in Heim- oder Firmennetzwerken eingesetzt. Dabei weicht
WLAN nur in der Spezifikation der MAC- und PHY-Schicht von den anderen Technologien der 802-Standardreihe ab. Diese Schichten sind von der IEEE in 802.11 standardisiert worden.
Die Standards unterscheiden sich vorwiegend durch die unterschiedlichen Übertragungsraten von 1 - 54 MBit/s und das verwendete Frequenzband, hinzu kommen Erweiterungen. Am weitesten verbreitet sind zum heutigen Zeitpunkt Netze nach 802.11b
und 802.11g.
IEEE
802.11a
802.11b
802.11g
802.11e
802.11i
802.11h
Band/Bezeichung
5 GHz ISM
2,4 GHz ISM
2,4 GHz ISM
QoS Enhancements
Security Enhancements
Spectrum and Transmit Power
Management Extensions in Europe
Übertragungsraten
6-54 MBit/s
1-11 MBit/s
6-54 MBit/s
Tabelle 3.3: IEEE WLAN-Standards
Der Ursprungsstandard 802.11 [IEEE99a] arbeitet im 2,4 GHz Band mit Übertra-
33
gungsraten von 1-2 MBit/s. Darauf aufbauend wurde der 802.11b Standard [IEEE99c]
für höhere Datenraten bis 11 MBit/s spezifiziert. Der weitere Bedarf an Datenübertragungskapazität führte zu Geschwindigkeiten bis zu 54 MBit/s im 2,4 GHz Band
(802.11g [IEEE03]) und im 5 GHz Band (802.11a [IEEE99b]).
WLAN kennt zwei Methoden zur Vernetzung. Der Infrastrukturmodus setzt immer
einen zentralen Zugangspunkt (Access Point (AP)) voraus, der die beteiligten Geräte
mit einem Netzwerk verbindet. Alle beteiligten Stationen in einer solchen Funkzelle
werden nach 802.11 als Basic Service Set (BSS) bezeichnet. Im Ad-hoc-Modus dagegen
kommunizieren die beteiligten Geräte direkt miteinander. In dieser Arbeit wird nur der
Infrastrukturmodus betrachtet, da dieser für die Herstellung einer Internetverbindung
am ehesten geeignet ist.
Im Hinblick auf VoIP ist WLAN vor allem deshalb interessant, da es seit Anfang
des Jahres 2006 mobile Endgeräte (siehe Abschnitt 5.3.4) gibt, die den Sprachdatentransport mittels IP über WLAN direkt unterstützen. Damit verbunden ist ein hohes
Aufkommen an Software und Marketingmaßnahmen, um IP-Telefonie in Privathaushalten mittels WLAN nutzbar zu machen.
Der 802.11 Standard definiert eine MAC- und mehrere Varianten der PHY-Schicht für
WLAN. Relativ zum ISO/OSI-Modell setzt sich die Schicht 2 (Datalink) bei WLAN
aus der Logical Link Control (LLC) und der Medium Access Control (MAC) zusammen,
wie in Abbildung 3.3 dargestellt. Die Schichten und ihre Funktionen im Hinblick auf
VoIP-Verkehr werden im Folgenden kurz beschrieben, um anschließend auf die QoSErweiterungen im Standard 802.11e [IEEE05a] einzugehen.
3.3.1.1 PHY-Layer
Die von der grundlegenden Spezifikation genannten drei Übertragungsverfahren für
WLAN sind FHSS (siehe Abschnitt 3.2), Direct Sequence Spread Spectrum (DSSS)
und Infrarot. Diese Arbeit befasst sich nur mit den verwendeten Verfahren für die
verbreiteten Standards 802.11a, 802.11b und 802.11g.
Die Basis der Übertragung nach 802.11b ist das DSSS-Verfahren. Es ermöglicht mittels Differential Binary PSK (DBPSK) eine Datenrate von 1 MBit/s und mittels Differential Quarternary PSK (DQPSK) eine Datenrate von 2 MBit/s. Der Frequenzbereich
wird dabei in 13 Kanäle von 22 MHz Bandbreite und einem Kanalmittenabstand von 5
MHz unterteilt. Der Abstand sollte eigentlich 30 MHz betragen, ist aber von der ETSI
34
Abbildung 3.3: WLAN-Stack [Eigene Darstellung]
nur mit 5 MHz festgelegt worden, so dass sich nicht alle 13 Kanäle parallel nutzen
lassen. Die Datenraten von 11 MBit/s bzw. 5,5 MBit/s werden durch Kombination
mit Complementary Code Keying (CCK) erreicht, hier werden pro Symbol 4 bzw. 8
Bit bei einer gleichbleibenden Symbolrate von 1,375 MSymbolen/s übertragen.
Ein Rahmen setzt sich immer aus einer Präambel, die der Synchronisierung dient,
einem Header und den eigentlichen Daten zusammen. Ein Teil dieses Headers gehört
zum Physical Layer Convergence Protocol (PLCP), das die Daten der darüberliegenden
Schicht an die PHY-Layer anpasst. Um die Abwärtskompatibilität zu gewährleisten,
werden bei 802.11b Header und Präambel des Datenframes immer mit der Grunddatenrate von 1 MBit/s übertragen. Um den Geschwindigkeitsverlust dadurch nicht allzu
groß werden zu lassen, kann eine zeitlich verkürzte Version (short preamble) benutzt
werden. Der normale Header mit Präambel hat eine Zeitdauer von 192 µs, die verkürzte
Version dauert 96 µs.
Die 802.11a und 802.11g Standards verwenden Orthogonal Frequency Division Multiplexing (OFDM), um Daten mit höheren Raten zu übertragen. Dabei wird der Kanal
in 53 Unterkanäle unterteilt, von denen 48 zur Übertragung von Daten genutzt werden.
Durch die auf den einzelnen Trägern eingesetzten Modulationsverfahren BPSK, QPSK,
16-QAM (Quadraturamplitudenmodulation) und 64-QAM ergeben sich bei einer Symbolrate von 0,25 MSymbole/s die entsprechenden Datenraten (siehe Tabelle 3.4). Durch
FEC verursachte Redundanz wird die Nutzdatenrate verringert. Mit der Einführung
von 802.11g unterscheidet man auf der Ebene der Physical Layer zwischen der Extended Rate Physical Layer (ERP), der die Verfahren höherer Datenraten umfasst und
der non-ERP Layer, der die DSSS/CCK-Verfahren von 1-11 MBit/s vereint.
Modulation
BPSK
BPSK
QPSK
QPSK
16-QAM
16-QAM
64-QAM
64-QAM
Bits/
Unterkanal
1
1
2
2
4
4
6
6
35
Bits/
OFDM-Symbol
48
48
96
96
192
192
288
288
FEC
Code-Rate
1/2
3/4
1/2
3/4
1/2
3/4
2/3
3/4
Datenbits/
OFDM-Symbol
24
36
48
72
96
144
192
216
Datenrate
6 MBit/s
9 MBit/s
12 MBit/s
18 MBit/s
24 MBit/s
36 MBit/s
48 MBit/s
54 MBit/s
Tabelle 3.4: OFDM-Datenraten [Rech04, S.108]
3.3.1.2 MAC-Layer 802.11
Die Hauptaufgaben der MAC-Schicht sind die Steuerung des Kanalzugriffs und das
Segmentieren bzw. Wiederzusammensetzen der Dateneinheiten anderer Schichten.
Der WLAN-Kanal ist ein geteiltes Medium, bei dem ein gleichzeitiger Zugriff meh8. State of the Art
rerer Stationen nicht möglich ist. Aus diesem Grund spezifiziert der 802.11 Standard
[IEEE99a] auf der MAC-Ebene Zugriffsverfahren: zum einen den dezentralen Ansatz
der Distribution Coordination Function (DCF) und zum anderen als zentrales Verfahren die Point Coordination Function (PCF). Bei letzterer übernimmt der Access Point
die Kontrolle des Medienzugriffs und damit kann dieses Verfahren nur im Infrastrukturmodus eingesetzt werden. Laut 802.11 ist die Implementierung der PCF optional.
Wenn sie benutzt wird, unterscheidet man Zeitspannen, in denen die DCF für den
Zugriff auf den Kanal zuständig ist (Contention Period (CP)) von denen, in denen
die PCF zuständig ist (Contention-free Period (CFP)), siehe Abbildung 3.4. Der AcFigure 8.1.: The IEEE 802.11 standard covering the media access control (MAC) and the
(PHY) layer.
cess Point sendetphysical
regelmäßig
Frames aus, die Informationen über das Netz enthalten
The Physical Layer (PHY) of the original IEEE 802.11 standard included either
(Beacon Frames).theÜber
diese Signalisierungsrahmen
wirdhopping
dem spread
Netz spectrum
angezeigt, welches
direct sequence
spread spectrum (DSSS), frequency
(FHSS) or infrared (IR) pulse modulation.
Zugriffsverfahren aktiv ist.
IEEE 802.2
Logical Link Control (LLC)
OSI
Data Link
IEEE 802.11
Media Access Control
Frequency
Hopping
Spread
Spectrum
Direct
Sequence
Spread
Spectrum
MAC
Infrared
PHY
PHY
OSI
Physical
Figure 8.2.: Superframe structure in IEEE 802.11 [134].
Abbildung 3.4: Zugriffsperioden auf den WLAN-Kanal aus [Hoen05, S.136]
Die MAC-Schicht fügt den Dateneinheiten einen Header von 10-34 Byte Länge und
IEEE 802.2
Logical Link Control (LLC)
OSI
Data Link
IEEE 802.11
Media Access Control
MAC
Frequency
Hopping
Spread
Spectrum
Direct
Sequence
Spread
Spectrum
Infrared
PHY
36
PHY
OSI
Physical
eine 4 Byte lange Prüfsumme (Frame Check Sequence (FCS)) hinzu.
Distribution Coordination Function (DCF) Die DCF implementiert in Anlehnung
Figure
The IEEE 802.11 standard
coveringSense
the media
access Access
control with
(MAC)
and the Avoian
die 8.1.:
Ethernet-Spezifikation
ein Carrier
Multiple
Collision
physical (PHY) layer.
dance (CSMA/CA)-Verfahren.
Dabei
wird
von IEEE
der sendewilligen
ob
The Physical Layer (PHY)
of the
original
802.11 standardStation
included geprüft,
either
direct
spectrum
(DSSS),
hopping
spectrumbegondas Mediumthe
frei
ist. sequence
Bei nichtspread
belegtem
Kanal
wirdfrequency
danach erst
die spread
Übertragung
(FHSS) or infrared (IR) pulse modulation.
nen. Die Station berücksichtigt zusätzlich die Headerinformationen vorangegangener
Frames über die Dauer derselben. Aus diesen Informationen wird ein Timer gebildet,
der Network Allocation Vector (NAV), der eine zusätzliche Aussage darüber trifft, wann
das Medium wieder frei ist.
Um der drahtlosen Natur des Netzes Rechnung zu tragen, wird jeder übertragene Frame mit einer Empfangsbestätigung (acknowledge, kurz ACK) bestätigt. Bleibt
diese aus, wird der Frame nach einer zufällig gewählten Wartezeit erneut übertragen
(retransmission). Bei weiteren Fehlschlägen steigt die Wartezeit (back-off) schrittweise
bis zu einem bestimmten Wert an. Nochmals übertragen werden nur Frames, die an
einen einzelnen Empfänger
gerichtet sind
(unicast),
solche,
Figure 8.2.: Superframe
structure
in IEEEnicht
802.11
[134]. die mehrere Adressaten (broadcast und multicast) besitzen.
Figure 8.3.: Interframe space relationships in IEEE 802.11.
Abbildung 3.5: Zusammenhang der Zeitabstände aus [Hoen05, S.136]
Priorisierung von bestimmten Frames realisiert die DCF mit Hilfe unterschiedlicher
136
zeitlicher
Abstände zweier aufeinanderfolgender Frames (Interframe Space (IFS)). Die
Zusammenhänge sind in Abbildung 3.5 grafisch dargestellt. Man unterscheidet der
Länge nach folgende Zeitabstände:
Der Short Interframe Space (SIFS) bildet den Mindestabstand. Frames, die nach
SIFS gesendet werden, haben hohe Priorität und sind beispielsweise ACK-Frames.
Point Interframe Space (PIFS) wird nur bei Verwendung der PCF benutzt und
stellt einen bevorzugten Medienzugriff zur Verfügung.
37
Der Distribution Interframe Space (DIFS) ist der für die DCF benutzte Min-
destabstand für die Sendung von Daten- und Managementframes.
Der Extended Interframe Space (EIFS) wird benutzt, falls die Übertragung eines
Rahmens aufgrund von Fehlern abgebrochen wird.
Tabelle 3.5 zeigt eine Übersicht der Zeitkonstanten in den verschiedenen PHY-Schichten.
WLAN-Standard
802.11b
802.11g mixed mode
802.11g
802.11a
SlotTime
20
20
9
9
SIFS
10
10
10+6
16
DIFS
50
50
34
34
PIFS
30
30
25
25
Tabelle 3.5: Zeitkonstanten in µs [Gast05, S.275 ff.]
Eine sendewillige Station startet nach Ablauf der DIFS die back-off-Prozedur, die
dafür sorgen soll, dass nicht alle Stationen gleichzeitig zu senden beginnen. Dazu wird
die back-off-Zeit berechnet, die sich aus Backof f T ime = SlotT ime ∗ Random[0, CW ]
ergibt. Es wird ein zufälliger Wert zwischen 0 und CW (contention window) gewählt,
der mit der vom Übertragungsverfahren abhängigen SlotTime (siehe Tabelle 3.5) multipliziert wird. Die obere Grenze ist dabei am Anfang CWmin = 7. Falls der Übermittlungsversuch nicht erfolgreich ist, das heißt kein ACK-Frame empfangen wird, versucht
die Station weiterhin, den Rahmen mit einem verdoppelten Wert der back-off-Zeit zu
übertragen. Der maximale Wert, den CW dabei erreichen kann liegt bei CWmax = 255.
Ein bekanntes Problem, das zu Leistungseinbußen bei Verwendung der DCF führt,
ist das Hidden Station“-Problem. Dabei nimmt eine Station im WLAN den von ei”
ner anderen Station verursachten Verkehr nicht wahr, weil sie sich außerhalb ihrer
Reichweite befindet. Beide haben allerdings Kontakt zum AP. Diese Situation führt
zu Kollisionen, da die Stationen das Medium auch dann für verfügbar halten, wenn
die andere gerade sendet. Um diesen Effekt zu vermeiden, definiert der Standard die
optionale Nutzung des RTS/CTS-Mechanismus (ready to send/clear to send). Die sendewillige Station übermittelt ihren Sendewunsch und die Länge der zu übertragenden
Daten in einem RTS-Frame an den AP, der bei Verfügbarkeit des Mediums mit einem
CTS-Frame antwortet. Da alle Stationen den CTS-Frame empfangen, können sie ihr
Sendeverhalten darauf abstimmen.
Point Coordination Function (PCF) Wie oben bereits beschrieben, sieht der Standard die PCF als zentrale Zugriffsverwaltung auf das Medium vor, die auch zusammen
38
mit der DCF verwendet werden kann. Ihre Implementierung ist optional. Bei diesem
Verfahren koordiniert der Point Coordinator (PC), der im Access Point integriert ist,
über Poll-Frames den Zugriff der einzelnen Stationen. Die Übertragung von zeitkritischem Sprachverkehr ist nur bedingt möglich ([Rech04, S.231] und [Hoen05, S.137]).
Interessant ist, dass die PCF den direkten Austausch von Daten zwischen den Stationen erlaubt, ohne dabei den AP als Verkehrsknotenpunkt benutzen zu müssen.
Abhilfe bei der Priorisierung von Daten schafft der WLAN-Standard 802.11e, auf
den im Folgenden eingegangen wird.
3.3.1.3 MAC-Layer 802.11e - Quality of Service Enhancements
Um die Übertragung von zeitkritischen Daten über ein drahtloses Netz zu ermöglichen, hat die IEEE im November 2005 den Standard 802.11e [IEEE05a] verabschiedet.
Der Standard unterstützt die Priorisierung von Daten mit Hilfe von vier Zugriffskategorien (Access Categories (AC)) [MCHK+ 03] und führt zwei neue Zugriffsverfahren
ein. Die Enhanced Distribution Coordination Function (EDCF) und die Hybrid Coordination Function (HCF) werden im Nachfolgenden beschrieben. In der Nomenklatur
von 802.11e wird eine Funkzelle als QBSS (QoS Basic Service Set) bezeichnet, die
verwaltende Station als Hybrid Controller (HC).
Enhanced Distribution Coordination Function (EDCF) Die EDCF definiert vier
verschiedene ACs, die sich innerhalb einer Station wie eigene Stationen verhalten. Während einer CP erhält jede AC Zugriff auf das Medium, definiert als TXOP (transmission
opportunity). Der Zugriff bei freiem Medium erfolgt über verschiedene back-off-Zeiten,
ähnlich der DCF mit angepassten Prioritäten. Dazu wird ein neuer IS eingeführt, der
Arbitration Interframe Space (AIFS). Nach dem Ablauf eines Timers der Länge des
AIFS starten die Stationen ihre back-off-Prozedur (siehe 3.3.1.2). Der AIFS ist für die
ACs unterschiedlich definiert, so dass die höchstpriorisierte AC den kürzesten AIFS
hat, minimal kann er der DIFS entsprechen.
Die in Abschnitt 3.3.1.2 beschriebenen back-off-Prozeduren werden dabei an die Priorität der AC angepasst, das bedeutet die Kategorie mit der höchsten Priorität erhält
den kleinsten Wert von CW. Die Werte für CWmin liegen für 802.11a und 802.11g
bei 15 und für 802.11b bei 31, der höchste Wert bei CWmax = 1023. Durch 802.11e
ändert sich CWmin entsprechend der Prioritäten auf 0 bis 255, der Maximalwert von
CWmax = 1023 bleibt derselbe. Beim Fehlschlagen einer Übertragung wird der CWWert nicht einfach verdoppelt, sondern gehorcht der Formel CWneu = ((CWalt +1)∗P F ,
wobei PF (Persistence Factor ) ein Faktor zwischen 1 und 16 ist, der dazu dient, eine
39
Kollision zu verhindern. Da innerhalb einer Station mehrere ACs in verschiedenen Warteschlangen verwaltet werden, besteht die Möglichkeit, dass zwei ACs zur selben Zeit
ihre back-off-Zeit beenden und senden wollen. In diesem Fall entscheidet ein interner
Scheduler nach Priorität, welcher TC die TXOP zugewiesen wird.
EDCF-TXOP-Bursting Um die Übertragung kleiner Pakete zu verbessern, sieht der
802.11e Standard die Möglichkeit des EDCF-TXOP-Burstings vor. Dabei erhält eine
Station vom HC die Erlaubnis, solange Frames zu übertragen, bis das TXOPlimit
(Zeitlimit) abgelaufen ist. Dieses Limit wird in den Beacon Frames bekannt gegeben.
Hybrid Coordination Function (HCF) Bei der HCF handelt es sich analog zur
PCF um das zentralisierte Zugriffsverfahren für 802.11e. Sie kontrolliert über PollingMechanismen den Medienzugriff nach den QoS-Anforderungen in der CP und CFP.
Diese Funktion wird hier nicht näher betrachtet, da laut [Hoen05, S. 139] die einfachere EDCF für die Sprachübertragung ausreicht.
Dieser Abschnitt widmet sich im Wesentlichen der Analyse der technologiebedingten
Einflüsse auf die Anforderungsparameter Bitrate und Delay. Die Parameter Jitter und
packet loss sind durch eine theoretische Betrachtung nicht evaluierbar, an dieser Stelle
müssen Messungen erfolgen. Um dieser Tatsache gerecht zu werden, wird im Anschluss
auf relevante wissenschaftliche Arbeiten und ihre Ergebnisse eingegangen.
3.3.2.1 Bitrate und Delay
Bei der Übertragung von IP-Paketen über WLAN-Netze entsteht protokollbedingt ein
großer Overhead. Die erzielbare Nutzbitrate ist stark abhängig von Art, Anzahl und
Größe der zu versendenden Pakete. Im Folgenden wird die erzielbare Nutzbitrate analytisch bestimmt, um daraus Folgerungen über die Anzahl der maximal übertragbaren
VoIP-Gespräche ziehen zu können.
Beispielhaft betrachtet werden nach G.711 (64 kBit/s) und G.729 (8 kBit/s) kodierte
Audiodatenströme, die jeweils 20 ms Sprachdaten pro Paket übertragen. Der G.711
liefert hohe Sprachqualität mit der höchsten im VoIP-Bereich Verwendung findenden
Datenrate, der G.729-Codec liefert gute Sprachqualität bei relativ niedriger Datenrate.
Die Übertragung von Sprachpaketen in der Länge von 20 ms ist ein guter Kompromiss
40
zwischen Ausnutzung der Bandbreite und entstehenden Verzögerungen (vgl. Abschnitt
2.1.4.1).
Für die überschlagsweise Berechnung der Nutzbitrate orientiert sich diese Arbeit an
den Erläuterungen von [Gast05, S.575ff.] und [Rech04, S.333ff.].
Ein WLAN-Frame, der ein VoIP-Paket enthält, setzt sich unter Verwendung von
802.11b folgendermaßen zusammen:
18 Byte lange Präambel, die mit 1 MBit/s übertragen wird: 144 µs;
6 Byte langer physical layer convergence protocol (PLCP)-Header, der mit 1
MBit/s übertragen wird: 48 µs;
34 Byte MAC-Header und Prüfsumme (FCS), die mit 11 MBit/s übertragen
werden: 24,7 µs;
8 Byte LLC- und Subnetwork Access Protocol (SNAP)-Header, die mit 11 MBit/s
übertragen werden: 5,8 µs;
40 Byte RTP/UDP/IP-Header, die mit 11 MBit/s übertragen werden: 29,1 µs;
20 Byte (G.729) bzw. 160 Byte (G.711) Nutzlast, die mit 11 MBit/s übertragen
werden: 14,5 µs bzw. 116,4 µs;
Interframe Space (SIFS): 10 µs.
Daraus ergibt sich eine Übertragungszeit von 387,4 µs für den G.729-Frame und
489,3 µs für den G.711-Frame. Hinzu kommt die Empfangsbestätigung für den Frame,
die sich folgendermaßen zusammensetzt:
18 Byte Präambel und 6 Byte PLCP, die mit 1 MBit/s übertragen werden: 192
µs;
14 Byte ACK-Frame, der mit 11 MBit/s übertragen wird: 10,2 µs;
Interframe Space (DIFS): 50 µs.
Für die Übertragung des ACK-Frames ergibt sich eine Übertragungszeit von 252,2
µs, für den gesamten Vorgang von 630,2 µs (G.711) bzw. 528,4 µs (G.729). Während
dieser Zeit werden 20 Byte (G.729) bzw. 160 Byte (G.711) Nutzdaten übertragen, für
die Nettodatenrate ergibt sich somit (160Byte ∗ 8Bit/Byte)/630, 2µs= 2, 03M Bit/s
bzw. (20Byte ∗ 8Bit/Byte)/528, 4µs= 303kBit/s.
41
Diese simple Rechnung am Beispiel 802.11b lässt eine ganze Reihe Faktoren außer
Acht. Übertragungsbedingungen, die eventuell eine Neuübertragung eines Frames nötig
werden lassen, finden keine Berücksichtigung. Weiterhin wird das Senden von Beaconund anderen Management-Frames sowie konkurrierender Verkehr auf dem Medium
ebenso wie die back-off Zeit nicht berücksichtigt. Trotzdem gibt diese Rechnung einen
Anhaltspunkt für die Leistungsfähigkeit der WLAN-Technologie bei der Übertragung
von VoIP-Verkehr. Die nachfolgenden Tabellen 3.6 und 3.7 zeigen gesammelt die Werte
für die betrachteten WLAN-Standards.
Um die Wirkung von Optimierungen zu erkennen, wurden die Rechnungen zusätzlich
mit cRTP (siehe Abschnitt 2.1.3.1) und dem Short Preamble Format, das bei 802.11b
und 802.11g möglich ist, durchgeführt. cRTP kann die RTP/UDP/IP-Header zusammenhängender Pakete auf 2 bzw. 4 Byte reduzieren, für die Rechnung wird von 2 Byte
ausgegangen.
Frame
Bestandteil
Länge
Byte
Zeit (Datenrate)
802.11b
µs (MBit/s)
max. 8 Bit/Symbol
116,4 (11)
14,5 (11)
29,1 (11)
1,5 (11)
144 (1)
48 (1)
96
Zeit (Datenrate)
802.11bg
µs (MBit/s)
max. 216 Bit/Symbol
23,7 (54)
3,0 (54)
5,9 (54)
0,3 (54)
144 (1)
48 (1)
96
G.711 (20 ms)
160
G.729 (20 ms)
20
RTP/UDP/IP
40
mit cRTP
2
Präambel
18
PLCP Header
6
Short Preamble
15
(PLCP + Präambel)
MAC und FCS
34
24,7 (11)
5 (54)
LLC und SNAP
8
5,8 (11)
1,2 (54)
SIFS
10
16
ACK-Frame ges.
38
252,2
246
Summe (G.711)
630,2
490
Summe (G.729)
528,4
470
mit Header Kompression (cRTP) und Short Präambel
Summe (G.711)
506,6
390
Summe (G.729)
404,7
370
Tabelle 3.6: Dauer der Elemente bei Transmission über WLAN 802.11b und 802.11g
mixed mode (802.11bg)
Die maximalen Datenraten weichen von der Summe der Einzelzeiten ab, da immer
eine bestimmte Bitzahl pro Symbol übertragen wird. Aus der in Tabelle 3.6 und 3.7
kalkulierten Dauer der einzelnen Pakete, lässt sich einfach die maximal zur Verfügung
stehende Datenrate für die Übertragung von Sprachdaten berechnen. Die Anzahl der
42
pro Sekunde übertragbaren Pakete multipliziert mit der Menge der enthaltenen Sprachdaten ergeben die Werte aus Tabelle 3.8.
Frame
Bestandteil
G.711 (20 ms)
G.729 (20 ms)
RTP/UDP/IP
mit cRTP
Präambel
PBLC Header
MAC und FCS
LLC und SNAP
SIFS
ACK-Frame ges.
Summe (G.711)
Summe (G.729)
mit cRTP
Summe (G.711)
Summe (G.729)
Länge
Byte
160
20
40
2
34
8
Zeit (DR)
802.11a/g
µs (MBit/s)
24 (54)
4 (54)
8 (54)
4 (54)
16
4
8 (54)
4 (54)
16
58
130
110
126
106
Tabelle 3.7: Dauer der Elemente bei Transmission über WLAN 802.11a/g
Codec
Datenrate Datenrate Datenrate
802.11b
802.11bg
802.11a/g
MBit/s
MBit/s
MBit/s
G.711 2,03
2,612
9,846
G.729 0,303
0,340
1,455
mit Header Kompression (cRTP) und Short Präambel
G.711 2,527
3,282
10,159
G.729 0,395
0,432
1,509
Tabelle 3.8: Maximal mögliche Datenraten für den Transport von Audiodaten über
WLAN 802.11b, 802.11bg mixed mode und 802.11a/g
Aufgrund dieser Betrachtung lässt sich die Anzahl der maximal möglichen Gespräche
unter oben angeführten Einschränkungen errechnen. Ausgegangen wird von Sprachpaketen der Länge 20 ms, das heißt jede Sekunde werden 50 Frames sowohl im Up- als
auch im Downlink verschickt, wenn kein VAD (siehe Abschnitt 2.1.2) zum Einsatz
kommt. Daraus ergeben sich die Maximalwerte aus Tabelle 3.9.
Wie in Tabelle 3.8 gut zu erkennen, ist die Wirkung der unterschiedlichen Datenraten der Audiocodecs bei der Übertragung über WLAN bei weitem nicht so groß
WLAN-Standard
802.11b
802.11b mit Kompression
802.11g mixed mode
802.11g mixed mode mit Kompression
802.11a/g
802.11a/g mit Kompression
43
G.711
15
19
20
25
79
79
G.729
18
24
21
27
90
94
Tabelle 3.9: Maximale Anzahl gleichzeitiger Gespräche
wie denkbar. Genauso verhält es sich mit der optional möglichen Komprimierung der
RTP/UDP/IP-Header.
Die Ergebnisse der Tabelle 3.9 sind nur als Grenzwert zu betrachten. Die Latenzzeit
entspricht minimal der benötigten Zeit zur Übertragung, kann aber durch schlechte
Kanalbedingungen oder wie in [MCHK+ 03] gezeigt, durch die Anzahl der beteiligten
Stationen schnell größer werden.
3.3.2.2 Wissenschaftliche Arbeiten
VoIP über WLAN ist ein häufig erörtertes Thema in der Literatur. Wissenschaftliche
Veröffentlichungen konzentrieren sich auf Kapazitäts- und Parameterbetrachtungen,
die Nutzung von QoS-Mechanismen und Probleme, die beim Wechsel zu anderen Funknetzen entstehen.
Hole und Tobagi [HoTo04] untersuchen per Simulation die maximale Anzahl übertragbarer VoIP-Gespräche über 802.11b. Dazu bestimmen sie zuerst die theoretische
Obergrenze bei verschiedenen Paketgrößen - ähnlich wie im obigen Abschnitt - unter
zusätzlicher Berücksichtigung der zufälligen back-off-Zeit. Dadurch erhalten sie Ergebnisse, die etwas unter den Werten aus Tabelle 3.9 liegen. Der für den G.711-Codec
ermittelte Wert liegt bei 12 simultanen Gesprächen, für den G.729-Codec bei 14 Gesprächen. Weiterhin wird per Simulation die Anzahl der maximal möglichen Gespräche bei
tolerablem Qualitätsverlust und unter verschiedenen Rahmenbedingungen bestimmt.
Auch Wiethoelter [Wiet05] analysiert die Kapazität eines WLANs bei Gebrauch
verschiedener Datenraten und führt ein neues Konzept der virtuellen Nutzung ein, um
die Zusammenhänge zu analysieren.
Garg und Kappes führen in [GaKa03] experimentelle Untersuchungen über die maximale Anzahl von VoIP-Gesprächen in 802.11b-Netzen durch. Sie kommen auf sechs
gleichzeitig führbare Gespräche (G.711, 10 ms Paketgröße).
Nunes und Severiano nehmen in ihren Masterarbeiten [Seve04] und [Nune04] um-
44
fangreiche Praxistests mit 802.11b vor. Ihre Versuche finden sowohl im ad-hoc-Modus
als auch im Infrastrukturmodus statt und beziehen viele Parameter wie Störungen,
Entfernungen und Hintergrundverkehr mit ein.
Hoene betrachtet in [Hoen05] unter anderem die Sprachqualität von VoIP über
WLAN-Verbindungen mit Hilfe von Simulationen. In seiner Arbeit schlägt er die unterschiedliche Behandlung von Sprachpaketen bei der Übertragung hinsichtlich ihrer
Wichtigkeit für das Sprachsignal vor.
Garg et al. analysieren in [GKCT02] die Kapazität eines Netzes nach 802.11b mit
802.11e-Unterstützung für die Übertragung von VoIP-Gesprächen. Sie errechnen eine
maximale Anzahl von 15 Gesprächen bei Verwendung des G.711-Codecs und 34 Gesprächen bei Verwendung des G.729-Codecs.
3.4 GPRS
Der General Packet Radio Service (GPRS) ist eine Erweiterung des digitalen Mobilfunknetzes Global System for Mobile Communications (GSM). Dieses wird nach dem
analogen Mobilfunknetz als das Netz der zweiten Generation (2G) bezeichnet, während GPRS allgemein als 2.5G-Netz bezeichnet wird. Leitungsvermittelte Datenübertragungsdienste wie sie GSM bietet, auch mit Kanalbündelung in Form von High-Speed
Circuit Switched Data (HSCSD), werden in dieser Arbeit nicht betrachtet, zum einen
aus Kostengründen seitens des Endverbrauchers, zum anderen, weil eine Leitungsvermittlung die durch VoIP entstehenden Vorteile wieder zunichte macht.
Eine Erweiterung des GPRS-Systems zur Erhöhung der Datenrate ist Enhanced
GPRS (EGPRS), das auf der EDGE-Technologie (Enhanced Data Rates for GSM Evolution) beruht. Die Standardisierung ist dabei von der ETSI auf das 3rd Generation
Partnership Project (3GPP), einer Zusammenarbeit verschiedener Gremien, übergegangen und wird dort unter dem Namen GSM EDGE Radio Access Network (GERAN)
weitergeführt.
Der Standard zerfällt in viele Einzeldokumente, die beständig weiterentwickelt werden. Sie sind alle auf den Internetseiten des 3GPP zu finden [3rd 06].
Eine Übersicht dieser Technologien findet sich in Tabelle 3.10.
Technologie
Generation
max. Datenrate
GSM
2
9,6-14,4 kBit/s
HSCSD GPRS
EDGE
2
2.5
2.75
115,2
171,2 kBit/s 473,6 kBit/s
Tabelle 3.10: Übersicht GSM-basierende Technologien
45
In diesem Kapitel wird zunächst auf die Funktionsweise von GPRS unter Berücksichtigung der für den IP-Transport relevanten Aspekte eingegangen, um darauf aufbauend
die Eignung für VoIP zu analysieren. Eine gute Übersicht über diese Technologie findet
sich in [Saut04].
GPRS stellt, basierend auf der Nutzung des GSM-Zeit- und Frequenzmultiplexsystems,
paketbasierte Datenübertragungsdienste mit verschiedenen Datenraten und Dienstgüten zur Verfügung.
3.4.1.1 Struktur des GPRS-Netzes
Um die effektive Nutzung von paketvermittelten Diensten möglich zu machen, wurde
das bestehende GSM-Netz um mehrere Komponenten erweitert (siehe Abbildung 3.6).
BSC
SGSN
MSC/VLR
GGSN
Abbildung 3.6: GPRS-Komponenten im GSM-Netz nach [Schi03, S.11]
Im Wesentlichen handelt es sich dabei um den Serving GPRS Support Node (SGSN)
und den Gateway GPRS Support Node (GGSN). Der SGSN stellt die Funktionen zur
Paketweiterleitung für die einzelnen Endgeräte, auch Mobile Station (MS) genannt,
bereit, ähnlich wie es das Mobile Switching Center (MSC) für die GSM-Dienste tut.
Dazu gehören auch Funktionen zur Nutzerbeglaubigung, Abrechnung und Verschlüsselung der Pakete. Der SGSN stellt dabei über den Base Station Controller (BSC), der
die Funkverbindungen über die Base Transceiver Stations (BTS) verwaltet, die Verbindung zum Endgerät her. Der GGSN stellt die Verbindung des GPRS-Netzes zu anderen
Netzen her, beispielsweise dem Internet oder GPRS-Netzen anderer Betreiber. Dabei
46
umfasst er Funktionen wie Adressierung, Verschlüsselung und Filterung von Paketen.
SGSN und GGSN kommunizieren untereinander über ein IP-Netz.
3.4.1.2 GPRS-Protokollstack
Der GPRS-Protokollstack definiert die verwendeten Protokolle der beteiligten Subsysteme (siehe Abbildung 3.7), die den reibungslosen Transfer von der MS und dem
externen Netz gewährleisten sollen.
Transport Layer
(e.g. UDP)
Network
Layer
Network Layer
(e.g. IP)
Network Layer
(e.g. IP)
Data Link
Layer
Physical
Layer
Physical Link
Layer
Physical Link
Layer
Physical
RF Layer
Physical
RF Layer
Um
Gb
Gn
Abbildung 3.7: GPRS-Protokollstack nach [TaBo02, S.62]
Funkschnittstelle
Die Funkschnittstelle ist in [ETSI00a] beschrieben. GPRS verwendet 200 kHz breite
Kanäle in den Frequenzbändern um 900 bzw. 1800 MHz, in denen die Daten mit GMSK
übertragen werden. Dabei sind die Kanäle in Up- und Downlink-Richtung frequenzmäßig getrennt (FDD). Im GSM-900 stehen 124 Kanäle zur Verfügung, im DCS-1800 sind
es 374, die unter den Diensteanbietern aufgeteilt sind.
Multiplexing Die GPRS-Multiplexstruktur basiert auf Time Division Multiple Access
(TDMA). Jeder Funkkanal wird in 4,615 ms lange Zeitrahmen unterteilt, die jeweils
acht Zeitschlitze von 15/26 ms Länge enthalten. In diesen Zeitschlitzen werden Datenbursts gesendet, die eine unterschiedliche Anzahl an Nutzdatenbits enthalten können.
Die Zeitschlitze werden in einer übergeordneten Struktur im so genannten Multiframe
von 420 ms Dauer mit jeweils 52 Zeitschlitzen zusammengefasst (siehe Abbildung 3.8).
Dabei gehören nicht zeitlich aufeinanderfolgende Zeitschlitze zu einem 52-Multiframe,
sondern jeweils der n-te Zeitschlitz eines TDMA-Rahmens. Es existieren acht Multiframes, pro Zeitschlitz einer. Die Übertragung basiert auf RLC/MAC-Funkblöcken
47
(siehe Abschnitt 3.4.1.2), die sich über jeweils vier Zeitschlitze eines Multiframes erstrecken. Ein Funkblock wird immer in vier aufeinanderfolgenden Zeitschlitzen eines
52-Multiframes übermittelt, ein Multiframe trägt 12 Funkblöcke. Die übrigen vier Zeitschlitze eines Multiframes werden zur Übermittlung von Kontrollframes verwendet.
Die Übertragung eines Funkblocks dauert folglich mindestens vier TDMA-Rahmen,
im Ergebnis 4 ∗ 4, 615ms = 18, 464ms.
Timeslot (8 per Frame)
Timeslot (length)
Burst (amount of data send in one timeslot)
Timeslot No. 2 (PDCH No. 2)
Timeslot Number x
0 1
3 4 5 6 7
TDMA Frame
4,615 ms
TDMA Frame
(4 per Radio Block)
0,577 ms
Radio Block
Radio Block
Multiframe (included Idle Frame)
4,615 ms
Idle Frame
Multiframe
0
10
20
30
40
50
4,615 ms
18,46 ms
240 ms
Abbildung 3.8: GPRS-Multiframestruktur nach [TaBo02, S.61]
Kanalstruktur GPRS verwendet eine Vielzahl verschiedener Kanäle. Dabei werden
die logischen Kanäle höherer Schichten auf die physikalischen Kanäle der Funkschnittstelle abgebildet. Es wird unterschieden in Kanäle mit Allgemeinzugriff (Common
Channels) und einer bestimmten Station zugewiesene Kanäle (Dedicated Channels).
Des Weiteren wird in Kontrollkanäle und Datenkanäle differenziert.
Zum Transport von Paketdaten wird auf der physischen Ebene der Packet Data
Channel (PDCH) genutzt, der genau einem Zeitschlitz zugeordnet ist. Auf diesen können mehrere logische Packet Data Traffic Channel (PDTCH) gemultiplext werden. Die
notwendigen logischen Kontrollkanäle werden normalerweise ebenfalls gemeinsam auf
einen PDCH abgebildet.
Prinzipien GPRS verwendet an der Funkschnittstelle zwei wichtige Prinzipien: das
Master-Slave-Konzept und Kapazitätszuweisung auf Anforderung.
48
Das Master-Slave-Konzept bezieht sich auf die Abbildung logischer auf physische
Kanäle. Die logischen Kontrollkanäle werden im GPRS-System auf einen PDCH eines
Zeitschlitzes abgebildet. Die übrigen PDCHs auf anderen Zeitschlitzen operieren als
Slaves der Kontrollkanäle und dienen zum Datentransport.
Die Funkressourcen in einer Funkzelle müssen zwischen allen Nutzern, gleich ob sie
Daten- oder Sprachdienste nutzen, geteilt werden. Das Netzwerk entscheidet dabei,
ob bei einer Anforderung nach Übertragungskapazität diese auch zur Verfügung gestellt wird. Dabei werden die Ressourcen nur für die benötigte Dauer der Übertragung
bereitgestellt.
Kanalcodierung GPRS umfasst vier verschiedene Verfahren zur Codierung von Funkblöcken, die unterschiedlich robust gegen Übertragungsfehler sind. Sie sind in Tabelle
3.11 dargestellt. Dabei unterscheiden sich diese durch die unterschiedliche Verwendung
von Faltungscodes und Punktierung, was sich in unterschiedlichen Datenraten und
Fehleranfälligkeit äußert. Zur Erhöhung der Datenraten kann mehr als ein Zeitschlitz
in den TDMA-Rahmen zur Übertragung verwendet werden, dies muss vom Endgerät
unterstützt werden (Multislotfähigkeit).
Schema Codierrate
CS-1
CS-2
CS-3
CS-4
1/2
≈ 2/3
≈ 3/4
1
RLC Nutzlast [Bit] max.
1 TS
181
9,05
268
13,4
312
15,6
428
21,4
Nutzdatenrate
2 TS 4 TS
18,1 36,2
26,8 53,6
31,2 62,4
42,8 85,6
[kBit/s]
8 TS
72,4
107,2
124,8
171,2
Tabelle 3.11: Codierschemata bei GPRS [TaBo02, S.60]
Die Codierung wird immer auf einem RLC/MAC-Funkblock ausgeführt, der stets
eine codierte Länge von 456 Bit hat. Dieser Block wird durch Interleaving auf vier
normale Bursts verteilt, so dass jeder Burst eine Länge von 114 Bit hat. Die Menge der
übertragbaren Daten pro RLC/MAC-Funkblock variiert je nach Codierung und liegt
zwischen 181 und 428 Bit.
Protokolle höherer Schichten
Für diese Arbeit wird nur der Fall von IP als Protokoll der externen Vermittlungsschicht
betrachtet. Die die Funkverbindung betreffenden Protokolle werden im Folgenden kurz
erklärt.
49
Service Network Dependent Convergence Protocol (SNDCP) [ETSI01a] Die
Hauptaufgaben des SNDCP sind das Multiplexen von verschiedenen Packet Data Protocols (PDP), das Komprimieren der Daten und/oder der Paketheader, die Segmentierung der IP-Pakete für die LLC-Schicht und das Puffern von Paketen im SGSN.
Headerkomprimierung ist allerdings nur für den IP-Header nach [IETF99a] verfügbar.
Die Länge des SNDCP-Headers beträgt entweder 2, 4 oder 5 Byte. Die Segmentierung
und die Länge des Headers sind von den Parametern der LLC-Schicht abhängig.
Logical Link Control (LLC) [ETSI01c] Die LLC dient der Verbindungssteuerung
zwischen MS und SGSN. Zu den Aufgaben der Schicht gehören die Bereitstellung und
Verwaltung logischer Verbindungen, Flusskontrolle und Fehlererkennung. Sie hat einen
bestätigten und einen unbestätigten Modus, der in den protected und in den unprotected mode unterteilt wird. LLC-Dateneinheiten sind mit einer Prüfsumme versehen
(Frame Checksum (FCS)).
Im unbestätigten Modus werden nach Übertragung als fehlerhaft erkannte Pakete
verworfen. Die Prüfsumme kann entweder das ganze Paket umfassen (protected mode) oder nur den Paketheader (unprotected mode). Im bestätigten Modus muss der
Empfänger die Ankunft eines Paketes quittieren, sonst wird es neu übertragen.
Die LLC unterstützt mehrere logische Verbindungen gleichzeitig, die durch einen
Temporary Logical Link Identifier (TLLI) gekennzeichnet sind. Der Protokollheader
besteht aus 1 Byte Adressinformation und bis zu 36 Byte Kontrollinformation (üblich
sind 1-3 Byte), hinzu kommt eine 3 Byte große Prüfsumme am Ende des Paketes. Die
Nutzlast kann 140 bis 1520 Byte umfassen.
Radio Link Control/Medium Access Control (RLC/MAC) [ETSI01b] Die RLCSchicht stellt eine zuverlässige Verbindung zwischen MS und BSS her, während die
MAC-Schicht den Medienzugriff verwaltet. Die Aufgaben der RLC-Schicht sind die Segmentierung der LLC-Pakete in RLC-Datenblöcke, die Segmentierung von RLC/MACKontrollblöcken und die Fehlerkorrektur.
Ein RLC/MAC-Block besteht aus einem MAC-Header (1 Byte), einem RLC-Header
variabler Länge (2-3 Byte), einem Datenfeld und spare bits. Damit ergeben sich geringere Raten für den eigentlichen Datentransport als die in Tabelle 3.11 dargestellten.
Die Größe der RLC-Blöcke mit den entsprechenden Datenraten sind in Tabelle 3.12
dargestellt.
RLC unterstützt einen bestätigten und einen unbestätigten Modus. Im bestätigten
Modus liefert es eine zuverlässige Verbindung mittels ARQ-Verfahren. Im unbestätig-
Schema RLC-Datenfeld
[Byte]
CS-1
20
CS-2
30
CS-3
36
CS-4
50
Spare Bits
[Bit]
0
7
3
7
50
RLC/MAC-Block
[Bit]
181
268
312
428
Nutzdatenrate
[kBit/s]
8
12
14,4
20
Tabelle 3.12: Größe der RLC-Blöcke [Stuc03, S.43]
ten Modus werden ebenfalls ACK/NACK-Nachrichten ausgetauscht, es erfolgt keine
erneute Übertragung.
Die MAC-Schicht kontrolliert den Zugriff auf den Funkkanal mittels Temporary Block
Flows (TBFs). Einem TBF sind bestimmte Ressourcen in Form eines oder mehrerer
PDCHs zugewiesen. Der TBF existiert nur für die Dauer der Übertragung, er wird im
Uplink über einen Kanal mit Zufallszugriff nach dem slotted-ALOHA-Prinzip eingerichtet. Die Disposition ankommender Pakete ist ebenfalls Aufgabe der MAC-Schicht,
die Implementierung ist allerdings freigestellt.
3.4.1.3 GPRS-Dienste
GPRS spezifiziert End-to-End-Trägerdienste mit den Serviceparametern Dienstpriorität, Verzögerung, Zuverlässigkeit, Spitzendurchsatz und mittlerer Durchsatz in [ETSI00b]
und [ETSI02b], welche im Folgenden kurz erläutert werden:
Dienstpriorität: stellt drei Prioritätsklassen relativ zu anderen Diensten bereit;
Verzögerung: spezifiziert die maximale mittlere Verzögerung und die in 95% aller
Datenübertragungen maximal erlaubte Verzögerung; in der niedrigsten Verzögerungsklasse ist eine maximale mittlere Verzögerung von 0,5 s und eine 95%
Verzögerung von 1,5 s genannt;
Zuverlässigkeit: spezifiziert die Klasse der Zuverlässigkeit anhand von Paketfeh-
lern und -verlusten. Für Echtzeitdienste mit Paketverlusttoleranz (VoIP) wird
die LLC und RLC im unbestätigten Modus betrieben;
Spitzendurchsatz und mittlerer Durchsatz: geben Klassen für die Durchsatzwerte
an.
Eine MS, die eine Paketdatenverbindung aufbauen möchte, aktiviert einen (Packet
Data Protocol (PDP))-Kontext, der die Parameter für die Kommunikation festlegt.
Dazu gehören auch die QoS-Parameter.
51
3.4.2 EGPRS
Die Erweiterung von GPRS zur Erhöhung der Datenraten beruht auf der EDGETechnologie. Diese Verbesserung wird im Wesentlichen durch die Verwendung eines
anderen Modulationsverfahrens erreicht, statt GMSK wird 8PSK eingesetzt. Pro Symbol können damit statt einem Bit drei Bit übertragen werden. Außerdem unterstützt
EGPRS den Wechsel zwischen verschiedenen Modulations- und Codierungsverfahren
(Adaptive Modulation and Coding (AMC)), zusammenfassend dargestellt in Tabelle
3.13. Durch den Einsatz einer neuen ARQ-Funktion des Typs II wird die Wiederübertragung von Funkblöcken verbessert und der Durchsatz optimiert. Ein normaler
EGPRS-Burst transportiert 346 Bit Nutzdaten.
Schema
Modulation
Codierrate
MCS-9
MCS-8
MCS-7
MCS-6
MCS-5
MCS-4
MCS-3
MCS-2
MCS-1
8PSK
8PSK
8PSK
8PSK
8PSK
GMSK
GMSK
GMSK
GMSK
0,36
0,36
0,36
1/3
1/3
0,53
0,53
0,53
0,53
RLC
Blöcke
2
2
2
1
1
1
1
1
1
Bruttodaten/
Funkblock [Bit]
2*592
2*544
2*448
592
448
352
296
224
176
Datenrate/
Zeitschlitz [kBit/s]
59,2
54,4
44,8
29,6
22,4
17,6
14,8
11,2
8,8
Tabelle 3.13: Codierschemata bei EGPRS [Schi03, S.32]
Die höherwertigen Codierschemata bei EGPRS verwenden zwei RLC-Blöcke mit
einem gemeinsamen Header. Die beiden Blöcke werden nicht mehr auf vier Bursts
verteilt sondern jeder Funkblock auf zwei Bursts. Der Header wird über alle vier Bursts
verteilt.
Mittels GPRS übertragende Datenpakete durchlaufen den Protokollstapel gemäß Abschnitt 3.4.1.2. Dabei addieren sich zu den eigentlichen Sprachdaten die Protokollheader der einzelnen Schichten. SNDCP und LLC werden für die Übertragung von
Echtzeitdaten im unbestätigten Modus betrieben [ETSI02b, S.89].
Sprachdaten: 160 Byte (G.711) oder 20 Byte (G.729);
RTP/UDP/IP-Header: 40 Byte, kann von SNDCP auf 2 Byte komprimiert wer-
den;
52
SNDCP-Header: 4 Byte im unbestätigten Modus;
LLC-Header und FCS: 3 Byte FCS, 1 Byte Adressfeld, 2 Byte für die Verwendung
von Unconfirmed Information (UI)-Rahmen im unbestätigten Modus.
In der Summe ergeben sich damit für den G.711-Codec 210 Byte unkomprimiert
pro Paket (84 kBit/s) und 172 Byte pro Paket (68,8 kBit/s) unter Anwendung der
Kompression. Für den G.729-Codec ergeben sich unkomprimiert 70 Byte pro Paket
(28 kBit/s) und 32 Byte pro Paket (12,8 kBit/s) komprimiert. Für einen zweiseitigen
Sprachverkehr ergeben sich die Datenraten 56 kBit/s (G.729) und 25,6 kBit/s (G.729
mit Kompression).
Diese Datenraten müssen von der RLC-Schicht bereitgestellt werden. Aus den Tabellen 3.11 und 3.13 lässt sich leicht die maximal mögliche Anzahl an VoIP-Gesprächen
berechnen. Bei Betrachtung des G.729-Codecs mit komprimierter Übertragung kann
bei Nutzung zweier Zeitschlitze ein Gespräch übertragen werden, bei Verwendung von
vier Zeitschlitzen sind es drei Gespräche. Die Verwendung von EGPRS würde die Zahl
auf ein (ein Zeitschlitz) bzw. neun (vier Zeitschlitze) gleichzeitige Gespräche steigern.
Der Transfer eines Gespräches (G.729-komprimiert) ist nur mit CS-3/4 über einen
Zeitschlitz möglich, das ganze Paket kann in einem RLC/MAC-Funkblock übertragen werden. Damit ergibt sich die minimale Verzögerungszeit von 18,464 ms (siehe
Abschnitt 3.4.1.2).
Zu dieser technologiebedingten Verzögerungszeit addieren sich die Zeiten, die durch
die Bearbeitung und Pufferung der Daten auf dem Weg durch den Protokollstapel
entstehen. Eine weitere sehr wesentliche Zeitkomponente ist die benötigte Zeit zur
Ressourcenallokation [Schi03, S.81].
Falls eine MS eine anstehende Übertragung hat, so schickt sie über den Packet Random Access Channel (PRACH) eine entsprechende Nachricht an das BSS. In dieser
übermittelt sie ihre Multislotfähigkeiten und ob sie einen ein- oder zweiphasigen Verbindungsaufbau wünscht. Das BSS kann in der Antwort über den Packet Access Grant
Channel (PAGCH) der MS entweder direkt Funkressourcen zuweisen (einphasiger Aufbau) oder eine Rückfrage nach Ressourcen und Dienstgüte stellen, die dann ebenfalls
mit Zuweisung von Kapazitäten endet (zweiphasiger Aufbau). Die dritte Möglichkeit
ist der Aufschub des Verbindungswunsches, was beispielsweise bei hoher Netzauslastung passieren kann. Die Ressourcen können entweder fest zugewiesen werden oder
dynamisch, um wechselndem Verkehrsaufkommen Rechnung zu tragen. Der Verbrauch
von Kapazitäten in dieser Form wird demnach vom BSS mit Hilfe von TBFs verwaltet.
Nach erfolgter Datenübertragung wird der TBF wieder abgebaut. Vom festgelegten
53
Auftrittsmuster des PRACH ist im Wesentlichen die Wartezeit abhängig, die eine MS
auf eine Datenübertragung warten muss [Schi03, S.81].
Im Downlink gestaltet sich das Verfahren sehr viel einfacher. Eine im BSS anstehende Übertragung von Daten wird der MS über den Packet Common Control Channel
(PCCCH) signalisiert, dabei werden die verwendeten Kanäle angegeben. Daraufhin
beginnt das BSS, die Daten zu senden und die Verbindung wird nach positiver Bestätigung durch die MS wieder abgebaut. Auch hier ist die Zeitverzögerung abhängig von
der Häufigkeit des Auftretens dieses Kanals und seiner Kapazität.
Diese Werte sind nur Abschätzungen, es werden weder zusätzliche Datenübertragungen (beispielsweise zur Kontrolle und Steuerung) berücksichtigt, noch die Anzahl
der vom Mobilfunkprovider zur Verfügung gestellten Paketkanäle oder die verwendete
Multislotstruktur.
Chen und Goodman entwickeln in [ChGo04] ein analytisches Modell, um Latenzzeiten und Durchsatz von GPRS-Verbindungen zu bestimmen. Ihr Modell setzt die
Zuweisungszeit von Ressourcen mit der Übertragungszeit von zwei Funkblöcken an.
Im Ergebnis würde das für diese Betrachtungen eine Verzögerungszeit von minimal
55,4 ms bedeuten.
3.5 UMTS
Das Universal Mobile Communication System (UMTS) ist ein Mobilfunkstandard der
3. Generation (3G), der dem IMT-2000 Standard der ITU genügt. Ursprünglich von
der ETSI spezifiziert, wird der Standard heute von dem 3rd Generation Partnership
Project (3GPP) gepflegt und weiterentwickelt. Die Standards sind unter [3rd 06] als
Download verfügbar. Eine gute Übersicht des UMTS-Systems findet sich in [WaAS02]
und in [KALN+ 05].
Der Hauptunterschied zwischen UMTS und den Mobilfunknetzen der zweiten Generation besteht in der Nutzung von Wideband-CDMA (W-CDMA) auf der Funkschnittstelle, das erheblich höhere Datenraten ermöglicht. Schnellere Datenraten in Kombination mit anderen weiterentwickelten Technologien machen Videotelefonie, schnelle
mobile Internetzugänge, Streaminganwendungen und vieles andere möglich.
Man unterscheidet bei UMTS verschiedene Zellgrößen, die unterschiedliche Kennwerte haben (siehe [ITU-99]):
Pikozellen: Zellen von etwa 60 m Durchmesser, mit einer maximalen Datenrate
von 2 MBit/s bei einer maximalen Bewegungsgeschwindigkeit von 10 km/h;
54
Mikrozellen: besitzen eine Größe von ca. 1 km und erlauben Datenraten bis 384
kBit/s bei Geschwindigkeiten bis 120 km/h;
Makrozellen: in einem Durchmesser von etwa 2 km können Datenraten bis 144
kBit/s bei Höchstgeschwindigkeiten von 500 km/h erreicht werden;
Weltzellen: definierte Weltzellen decken einen großen Bereich ab und benutzen
beispielsweise einen Funkzugang über Satelliten.
Der Ausbau des UMTS-Netzes und auch der Spezifikationen gestaltet sich in mehreren Phasen. Der UMTS-Aufbau in der ersten Phase wurde durch das Release 99
(R99) [ETSI04b] spezifiziert und umfasste im Wesentlichen die neue Funkschnittstelle,
während das drahtgebundene Kernnetz (Core Network (CN)) weiterhin auf der GSMArchitektur beruhte. Hinzu kam das UMTS Radio Access Network (UTRAN), das die
drahtlose Verbindung zu dem bei UMTS User Equipment (UE) genannten Endgerät
herstellt.
Abbildung 3.9: UMTS-Netzstruktur aus [Tekt06, S.2]
Die Elemente, die die Funkverbindung aufbauen, heißen im UTRAN nicht mehr
BTSs sondern Node Bs. Diese sind nicht mehr an einen BSC gekoppelt, dessen Aufgaben werden von dem Radio Network Controller (RNC) übernommen. Die Aufgaben des
Funkzugriffs werden im Funkzugriffsnetzwerk (Radio Access Network (RAN), auch Radio Network Subsystem (RNS) genannt, gekapselt. Im Anschluss daran unterscheidet
UMTS in das GSM-basierte Circuit-Switched Core Network (CS CN) und die oben
erläuterten Elemente des GPRS-Netzwerkes als das Packet-Switched (PS CN). Die
55
Standards sehen das UTRAN jedoch nicht als alleiniges Funkzugriffsnetzwerk vor, sondern berücksichtigen auch das GSM-Netz in der Erweiterung GERAN und alternative
Technologien wie beispielsweise WLAN. Der Prozess ist in dieser Hinsicht allerdings
noch nicht abgeschlossen.
Das auf R99 folgende Release 4 [ETSI04a] sieht als einen ersten Schritt zu einem konvergenten Netzwerk vor, die Signalisierung und den Datentransport im circuit-switched
CN zu trennen. Die Funktionalität des Mobile Switching Center (MSC) wird aufgespaltet in den MSC-Server, der die Kontrolle des Kanals übernimmt und den von ihm
gesteuerten Media-Gateway, über den der Datenstrom transportiert wird.
Das Release 5 [ETSI03] sieht die komplette Umstellung der Transportmechanismen
auf ein paketbasiertes IP-Netzwerk vor, in dem IPv6 auf jeden Fall implementiert sein
muss. Die Nutzung von IPv4 ist optional. Die Struktur von Release 4 wird dabei ergänzt durch das IP Multimedia Subsystem (IMS), das zur Kontrolle der Medienströme
dient. Zur Steuerung der Verbindungen wurde vom Standardisierungsgremium das SIP
ausgewählt (vgl. Abschnitt 2.1.3.2). In dieser Spezifikation ist auch die mittlerweile verfügbare Erweiterung des UMTS-Netzes High-Speed Downlink Paket Access (HSDPA)
beschrieben.
Das noch nicht vollständig fertiggestellte Release 6 sieht alternative Funkzugriffstechnologien zum Anschluss an das CN vor.
Die von einem Mobilfunkgerät übermittelten Daten werden über das Funknetzwerk
transportiert und dann über das CN des Mobilfunkproviders zu ihrem Bestimmungsort
weitergeleitet. Dabei kann der interne Transport sehr unterschiedlich aussehen, je nach
Implementierung und Entwicklungsstand des Netzes. Im Mittelpunkt der vorliegenden
Betrachtungen steht das Funknetzwerk, im Falle von UMTS das UTRAN, vor allem
weil es in Bezug auf die erreichbare Datenrate den Engpass darstellt. Die Struktur des
UTRAN ist in Abbildung 3.10 in der Übersicht dargestellt.
Das Radio Network Subsystem (RNS) besteht aus Node Bs und einem zentralen
Radio Network Controller (RNC).
In Deutschland wird auf der Funkschnittstelle das Übertragungsverfahren W-CDMA
mit FDD eingesetzt. Dabei werden Uplink und Downlink zwei getrennte Frequenzbänder mit einer Bandbreite von jeweils 5 MHz zugewiesen, die effektiv verwendete Bandbreite ist kleiner. Bei diesem CDMA-Verfahren werden unterschiedliche Codes benutzt,
um Zellen, Nutzer und Kanäle zu trennen.
56
Abbildung 3.10: UTRAN-Struktur nach [ETSI05b, S.14]
Der Standard sieht auch eine TDD-Variante des W-CDMA-Systems vor. In der
Grundvariante wird das UMTS allerdings mit FDD betrieben. TDD-Erweiterungen
sind für Pikozellen und stark asymmetrischen Verkehr vorgesehen, da sich hier durch
die flexible Verteilung von Zeitschlitzen Effizienzvorteile realisieren lassen. Im weiteren
Verlauf der Erläuterungen wird das FDD-System zugrunde gelegt.
Es finden unterschiedlich lange Spreizcodes Verwendung, Tabelle 3.14 gibt eine Übersicht. Das verwendete Modulationsverfahren ist QPSK, bei einer festen Chiprate von
3,84 MChip/s.
Spreizfaktor
Symbolrate
[KSymbole/s]
512 (nur Downlink) 7.5
256
15
128
30
64
60
32
120
16
240
8
480
4
960
max. Bitrate
[kBit/s]
15
30
60
120
240
480
960
1920
Tabelle 3.14: Spreizcodes und resultierende Datenraten [HoTo02, S.108]
W-CDMA arbeitet mit Rahmen der Länge 10 ms, die in 15 Zeitschlitze von 2/3
ms unterteilt sind. Ein Rahmen überträgt demzufolge 38.400 Chips, 2.560 Chips pro
Zeitschlitz.
Da beim CDMA-Verfahren alle Teilnehmer dieselbe Frequenz nutzen, ist die Kapazität einer Funkzelle nicht durch die verfügbaren Zeit- oder Frequenzbereiche begrenzt, sondern durch Interferenzen. Jeder Nutzer trägt durch seine Übertragung zur
Verschlechterung des Signals der anderen Nutzer bei. Wird der Signal to Interference
57
Ratio (SIR) so schlecht, dass eine Wiederherstellung des Signals nicht mehr möglich
ist, ist die Kapazitätsgrenze erreicht.
Daten und Signalisierungsinformationen werden über die komplexe Protokollarchitektur des UTRAN transportiert, die in Abbildung 3.11 gezeigt ist.
Abbildung 3.11: UTRAN-Protokollarchitektur aus [ETSI05a, S.12]
Die PHY-Schicht bietet der L2/MAC-Schicht die Nutzung von Transportkanälen
an. Dabei werden die verschiedenen Arten von Transportkanälen unterschieden nach
gemeinsam genutzten Kanälen (Common Channels) und einem bestimmten Nutzer zugewiesenen Kanälen (Dedicated Channel (DCH)). Neben den DCH können auch Common Channels zur Übertragung von Nutzdaten verwendet werden. Datenpakete, die
über Transportkanäle ausgetauscht werden, heißen Transportblöcke. Diese Transportblöcke werden in bestimmten Intervallen übertragen, dem Transmission Time Interval
(TTI). Dieses kann unterschiedlich lang sein, es beträgt immer ein Vielfaches der Rahmenlänge von 10 ms. Für DCH definiert die PHY-Schicht Transportformate, in denen
die Codierung, die Bitrate und die Abbildung auf physische Kanäle festgelegt ist. Bei
Kanälen mit variabler Bitrate gibt es unterschiedliche Formate, zwischen denen gewechselt wird, man spricht von einem Transportformat-Set. Hauptaufgabe der PHY-Schicht
ist das Multiplexen der Transportkanäle.
Die L2/MAC-Schicht bietet der L2/Radio Link Control (RLC)-Schicht logische Kanä-
58
le an, welche die Art des Datentransfers definieren. Dabei wird zwischen Kontrollkanälen (control channels) und Datenkanälen (traffic channels) unterschieden. Hauptaufgabe der MAC-Schicht ist demzufolge das Multiplexen der Dateneinheiten höherer
Schichten auf Transportkanäle unter Berücksichtigung von Prioritäten.
Die RLC-Schicht bietet drei Arten von Datenübertragungsdiensten an: transparente,
bestätigte und unbestätigte Übertragung. Sie ist zuständig für Segmentierung, Fehlerkorrektur und Flusskontrolle.
Die Verwaltung der Funkressourcen übernimmt die Radio Resource Control (RRC).
Sie richtet die Funkträgerdienste ein und ist für die Konfiguration von PHY-, MACund RLC-Schicht zuständig.
Der Transport von IP-Paketen wird über das L2/Packet Data Convergence Protocol
(PDCP) abgewickelt. Diese Schicht ist im Wesentlichen für die Komprimierung der
Header nach [IETF99a] oder [IETF01] zuständig.
3.5.1.1 Quality of Service
Der UMTS-Trägerdienst ist an bestimmte QoS-Parameter gebunden. Ein Trägerdienst
(bearer service) stellt die Möglichkeiten der Informationsübermittlung zwischen zwei
Zugangspunkten zur Verfügung (siehe Abbildung 3.12). Die beiden Referenzpunkte
Terminal Equipment (TE) und Mobile Termination (MT) sind im Endgerät (Mobiltelefon) integriert. Zur Garantie der QoS-Parameter greift der UMTS bearer service
dabei auf die Dienste niederer Schichten, wie den Funkträgerdienst und den core network bearer service zurück.
UMTS definiert vier QoS-Klassen (TS 123.107 [3rd 06]):
Conversational class: Für diese Klasse ist eine geringe Latenzzeit und geringe
Abweichung von derselben festgelegt, die von der menschlichen Wahrnehmung für
Audio- und Videokommunikation abhängig ist. Dies beinhaltet Telefonie, VoIP
und Videotelefonie.
Streaming class: Diese Klasse ist für Audio- und Videostreaminganwendungen
gedacht. Die Verzögerungszeit ist nicht so eng begrenzt, die stete Lieferung der
Daten muss gewährleistet sein.
Interactive class: Gedacht für Webbrowsing und Datenbankzugriffe;
Background class: Niedrigste Priorität.
59
Abbildung 3.12: UMTS-Dienstearchitektur nach [ETSI02a, S.10]
3.5.1.2 IP-Übertragung
Der Aufbau einer IP-Verbindung zu einem Ziel im Internet verläuft mit UMTS ähnlich
wie bei GPRS. Es wird zuerst ein PDP-Kontext aktiviert, der eine Reihe von Einstellungen, unter anderem auch die geforderten QoS-Parameter für die Verbindungen
festlegt. Die IP-Pakete werden dann über verschiedene Protokolle bis zum Internetgateway (GGSN) übertragen sowie analog in die Downlink-Richtung (siehe Abbildung
3.13).
Higher layer
Application
Network layer
IP,
PPP,
OSP
Physical layer
Relay
PSCP GTP-U
RLC UDP/IP
MAC
AAL5
PHY
ATM
PSCP
RLC
MAC
PHY
Uu
OSI Model
UE
Relay
GTP-U GTP-U
UDP/IP UDP/IP
AAL5
L2
ATM
L1
Iu-PS
UTRAN
IP,
PPP,
OSP
GTP-U
UDP/IP
L2
L1
Gn
3G-SGSN
Gi
3G-GGSN
Abbildung 3.13: UMTS-Protokollstack nach [TaBo02, S.100]
Zur Übertragung über die Funkschnittstelle durchlaufen die IP-Pakete den Protokollstapel. Dabei bestehen in den einzelnen Schichten verschiedene Möglichkeiten, die
sich auf die Größe des Paketes auswirken [TaBo02, S.100 ff.]:
60
In der PDCP-Schicht kann eine Headerkompression des RTP/UDP/IP-Headers
durchgeführt werden, nach RFC 3095 ergibt sich damit ein Header mit durchschnittlich 2 Byte (siehe Abschnitt 2.1.3.1), zusätzlich wird bei Anwendung der
Kompression ein PDCP-Header von einem Byte angefügt.
Wie oben geschildert, hat die RLC-Schicht unterschiedliche Betriebsmodi. Im
transparenten Modus werden die Pakete ohne zusätzlichen Header weitergeleitet.
Falls die Übertragung im bestätigten oder unbestätigten Modus erfolgt, wird ein
RLC-Header von 1-4 Byte Größe hinzugefügt.
Auch die MAC-Schicht unterstützt einen transparenten Modus ohne zusätzliche
Headerinformationen. Ansonsten wird ein bis zu 5 Byte großer MAC-Header
vorangesetzt.
data packet
TCP
TCP Header (20)
IP
IP Header (20)
PDCP
RLC
MAC
PHY
PDCP 0-1
RLC Hdr
1-(3)
MAC Hdr
0-5
RLC Data Block
Transport Block
Abbildung 3.14: Transport von IP-Daten nach [TaBo02, S.107]
3.5.2 HSDPA
Der High-Speed Downlink Packet Access (HSDPA) ist eine Erweiterung des UTRAN
für höhere Datenraten, die im Release 5 spezifiziert wird. HSDPA ist dabei nur für den
Downlink konzipiert und realisiert die Übertragung auf einem Downlink Shared Channel (DSCH), einem gemeinsam genutzten Kanal im TDMA-Modus. Um die höheren
Datenraten zu erreichen, werden für HSDPA mehrere neue Methoden eingesetzt, die
im Folgenden kurz erklärt werden sollen.
Adaptive Modulation and Coding (AMC) Zusätzlich zur QPSK-Modulation unterstützt HSDPA auch 16QAM und kann damit die doppelte Anzahl an Bits pro
61
Zeiteinheit übertragen. Weiterhin erlaubt AMC eine Anpassung der Modulation und
Codierung an die wechselnden Kanalverhältnisse, ähnlich der EDGE-Technologie bei
GRPS.
HSDPA arbeitet nicht mit den 10 ms TTI wie UMTS, sondern verwendet kürzere Intervalle von 2 ms Länge (Short TTI (STTI)), die dementsprechend nur drei Zeitschlitze
mit jeweils 2.560 Chips enthalten. Das dient vor allem dazu, die Zeit bei Wiederübertragungen zu vermindern, die nicht mehr von der RLC-Schicht im RNC gesteuert werden,
sondern als Teil der MAC-Schicht in den Node B implementiert werden.
Multicode Operation HSDPA arbeitet immer mit einem Spreizfaktor von 16, es
können maximal 15 verschiedene Codes an die beteiligten Endgeräte vergeben werden.
Dadurch sind bei paralleler Verwendung aller Codes Datenraten bis 14,4 MBit/s theoretisch möglich, von den Providern werden derzeit 1,8 MBit/s als Maximum angeboten.
Diese Rate würde der Verwendung von fünf Spreizcodes bei einem Zugriff auf jedes
zweite STTI entsprechen [HoTo02, S.292].
HSDPA unterstützt alle Qualitätsklassen außer der Conversational Class. Anwendungen für diese Klasse werden über einen DCH transportiert. Dementsprechend bietet
HSDPA auch keine unterbrechungsfreien Handovermechanismen für den Echtzeitdatenverkehr.
UMTS legt die verfügbare Bitrate auf der RLC-Schicht fest. Die maximale im derzeitigen Netz angebotene Datenrate sind 384 kBit/s. Damit würde sich bei eingesetzter Headerkompression und der Benutzung des unbestätigten Modus der RLC-Schicht (2 Byte
pro Paket) pro VoIP-Gespräch eine Datenrate von 132 kBit/s (G.711) und 20 kBit/s
(G.729) ergeben, es wären 2 bzw. 19 Gespräche über eine Datenverbindung theoretisch
möglich. Dieser Wert gilt nur unter idealen Bedingungen und ist stark abhängig von
der jeweilig anbieterspezifischen Implementation der Standards. Der im Vergleich zu
den bisher betrachteten Technologien recht hohe Wert erklärt sich dadurch, dass der
UMTS-Protokollstack daraufhin optimiert wurde, einen möglichst geringen Overhead
zu verursachen. Die vom System benutzte Datenrate wird durch den Overhead der unter der RLC-Layer liegenden Schichten, zusätzliche Signalisierungsinformationen und
anderen Mechanismen erheblich größer sein als 384 kBit/s. Hierfür eine Abschätzung
abzugeben ist aufgrund der Komplexität dieses Systems und der Implementierungsspielräume durch die Hersteller nicht möglich.
62
Für die Latenzzeit können für VoIP-Gespräche die Richtwerte aus der QoS-Spezifikation herangezogen werden. Bei einer Übertragung des Datenstroms über die Conversational Class sind in [ETSI02a, S.26] maximale Latenzwerte für den UMTS-Trägerdienst
von 100 ms und für den Funkträgerdienst von 80 ms angegeben (siehe Abbildung 3.12).
Diese Werte sind für die Übertragung von VoIP-Gesprächen geeignet. Die zu klärende
Frage ist allerdings, ob der UMTS-Provider das Herstellen von Datenverbindungen in
Conversational Class-Qualität gestattet. Typische Werte für die Nutzung von Paketübertragung werden in [HoTo02, S. 255] mit 40-350 ms für den Funkträgerdienst und
150 ms für den Weg durch UMTS-Architektur bis zum Internetgateway inklusive Verarbeitungszeit angegeben. Das absolute theoretische Minimum an Latenzzeit bei idealen
Bedingungen und ohne Einrechnung der Verarbeitungszeit entspricht dem TTI, da ein
Block zur Übertragung erst vollständig im PHY-Layer empfangen werden muss.
Im UMTS-System sind die Handover-Mechanismen sehr ausgereift. Es ist ein unterbrechungsfreier Wechsel zwischen den Funkzellen des UMTS-Netzes und des GSMNetzes möglich. Die Integration von Handover-Mechanismen für den Wechsel von anderen Zugriffsnetzen wie beispielsweise WLAN zu UMTS ist für das nächste Release
des Standards geplant.
3.6 WiMAX
Der WiMAX-Standard ist ein relativ neuer Industriestandard für die Datenübertragung mit hohen Bitraten im MAN-Bereich, der auf den IEEE 802.16 Standards und in
der neuen Version auch auf dem europäischen ETSI-HiperMAN [Euro06] beruht. WiMAX wird von einer Unternehmensgruppe, dem WiMAX-Forum [WiMA06b] gepflegt.
Die IEEE spezifiziert die unteren Schichten im Grundstandard 802.16, eine Erweiterung 802.16-2004, auch 802.16d [IEEE04] genannt und die Erweiterung für mobile
Endgeräte 802.16e [IEEE05c]. Eine Übersicht findet sich in Tabelle 3.15. Der Standard
ist in [Ohrt05] gut beschrieben.
Spezifikation
Frequenzbereich
Kanal
Bitrate
Zellradius
Bandbreite
Mobilität
802.16
10-66 GHz
LOS
32-134 MBit/s
2-5 km
20,25,28 MHz
fix
802.16-2004
2.5-11GHz
NLOS
bis 75 MBit/s
5-8 max.50 km
1.25-20MHz
fix und portabel
802.16e
2.5-6 GHz
NLOS
bis 15 MBit/s
5-8 km
1.25-20MHz
mobil(bis ca. 70 km/h), roaming
Tabelle 3.15: Kerndaten WiMAX [O’Sh04]
63
Die WiMAX-Struktur geht immer von einer Basisstation (BS) aus, auf die das Endgerät Subscriber Station zugreift. Dabei übernimmt die BS die zentrale Kontrolle des
Funkkanals.
Analog zu den anderen Funkübertragungsverfahren der 802.xx Standardisierungsreihe, baut auch dieser Standard auf einem ähnlichen Schichtenmodell auf. Die Unterteilung der spezifizierten Schichten MAC und PHY ist in Abbildung 3.15 dargestellt.
Abbildung 3.15: 802.16 Referenz-Modell aus [IEEE04]
3.6.1.1 PHY-Layer
Der 802.16d-Standard spezifiziert fünf Varianten der PHY-Layer, ihre Unterscheidungsmerkmale sind in Tabelle 3.16 übersichtlich dargestellt. Die Funkübertragungsvarianten
unterscheiden sich nach den benutzten Trägersignalen in Single Carrier (SC), OFDM,
Orthogonal Frequency Division Multiple Access (OFDMA) und High Speed Unlicensed
Metro Area Network (HUMAN). Während für den Betrieb im hohen Freqenzbereich
mit Sichtkontakt (Line of Sight (LOS)) nur eine Einzelträgerübertragung spezifiziert
ist, gilt es für den Bereich von 2-11 GHz eine Einzelträger- und drei OFDM-Varianten
zu unterscheiden. OFDM wird im Point-to-Multipoint (P2M)-Betrieb eingesetzt, da es
für die störungsfreie Übertragung zu vielen verschiedenen Endgeräten besonders gut
geeignet ist. Das OFDMA, das im neuen Standard für mobile Endgeräte [IEEE05c]
noch erweitert wird, arbeitet wie OFDM, mit dem Unterschied, dass die Unterträger
benutzerspezifisch in Unterkanäle gruppiert werden können. Für eine genauere Übersicht siehe [Wima06a]. Der 802.16-Standard lässt offen, ob der Duplex-Betrieb als TDD
64
oder FDD realisiert wird.
Bezeichnung
Wireless MAN
Wireless MAN
Wireless MAN
Wireless MAN
Wireless MAN
SC
SCa
OFDM
OFDMA
HUMAN
Funktion
P2P
P2P
P2M
P2M
P2M
LOS/NLOS
LOS
NLOS
NLOS
NLOS
NLOS
Frequenzband
10-66 GHz
2-11 GHz
2-11 GHz
2-11 GHz
2-11 GHz
Duplex
TDD, FDD
TDD FDD
TDD FDD
TDD FDD
TDD
Tabelle 3.16: Varianten der PHY-Layer in 802.16d
Die für diese Arbeit interessanten Verfahren sind OFDM und OFDMA, da hier vor
allem der Endzugang mit mobilen und portablen Geräten betrachtet wird. WirelessMAN-OFDM spezifiziert 256 Unterträger, der Zugriff verschiedener Stationen erfolgt
über TDMA. Anders bei OFDMA, hier werden den Stationen jeweils eine Anzahl der
2.048 Unterträger zugewiesen, über die sie gleichzeitig senden können. Bei den Herstellern scheint sich die reine OFDM-Variante durchzusetzen [GWAC05, S. 2], auf die sich
die folgenden Betrachtungen beschränken. Diese Tendenz lässt sich aus der Tatsache
ableiten, dass die bislang vom WiMAX-Forum beschriebenen Profile nur diesen Standard umfassen. Die Profile spezifizieren ähnlich wie bei Bluetooth genauer, in welchem
Frequenzband und mit welchen Parametern gearbeitet wird. Von den 256 Unterträgern
werden 192 für den reinen Datentransport genutzt, während die übrigen Steuererfordernissen dienen. Die Bandbreite kann laut Standard zwischen 1,25 MHz und 20 MHz
variiert werden, allerdings gibt das WiMAX-Forum auch hier feste Werte vor.
Wie im WLAN-Standard gibt es auch bei WiMAX verschiedene Modulationsarten
mit unterschiedlich großer FEC, zwischen denen abhängig von Reichweite und Kanaleigenschaften gewechselt werden kann. Die möglichen Modulationsarten und Datenraten
bei einer Bandbreite von 7 MHz (angelehnt an das vorgesehene Profil) zeigt Tabelle
3.17 in der Übersicht.
Rate ID Modulation Codierung Datenbits/
Symbol
0
BPSK
1/2
0,5
1
QPSK
1/2
1
2
QPSK
3/4
1,5
3
16QAM
1/2
2
4
16QAM
3/4
3
5
64QAM
2/3
4
6
64QAM
3/4
4,5
Datenbits/
OFDM-Symbol
96
192
288
384
576
768
864
Datenrate
MBit/s
2,92
5,82
8,73
11,64
17,45
23,27
26,18
Tabelle 3.17: OFDM-Datenraten bei 7 MHZ Bandbreite nach [IEEE04]
65
Die OFDM-PHY-Schicht arbeitet auf der Basis von Frames, im TDD-Modus enthält
ein solcher Frame einen Downlink- und einen Uplinkteil. Abbildung 3.16 gibt eine
Übersicht über die Zusammensetzung eines solchen Frames.
Abbildung 3.16: Schematischer Aufbau eines OFDM-TDD-Frames aus [IEEE04]
Je nach Konfiguration kann ein Frame die Dauer 2,5, 4, 5, 8, 10, 12,5 oder 20 ms
haben. Der Frame beginnt mit einer Präambel zu Synchronisationszwecken. Dann wird
ein Frame Control Header (FCH) übermittelt, der Informationen über die nachfolgenden Datenbursts enthält. Diese werden entsprechend einem Burstprofil übertragen und
enthalten immer eine ganze Zahl von OFDM-Symbolen. Direkt nach dem FCH gibt
es einen reservierten Bereich im Frame, der für die Übertragung von hochpriorisierten
Daten (UGS, siehe Abschnitt 3.6.1.2) genutzt wird.
Als weiteren optionalen Bestandteil enthält der Standard die Anleitung zur Nutzung
von Adaptive Antenna Systems (AAS). Mit Hilfe mehrerer Antennen wird das Signal
in genau eine Richtung (beam forming) gelenkt und in andere Richtungen gleichzeitig
durch Interferenz ausgelöscht. Damit ist in einem Ausbau der WiMAX-Netze auch
Spatial Division Multiple Access (SDMA) möglich. Der Standard sieht Rückmeldungen
der Subscriber Stations zur Steuerung der Antennensysteme vor.
66
3.6.1.2 MAC-Layer
Die MAC-Schicht [IEEE04] ist so aufgebaut, dass sie vielen gleichzeitigen Nutzern mit
unterschiedlichen QoS-Anforderungen auf einem Kanal gerecht werden kann.
Wie aus Abbildung 3.15 ersichtlich, zerfällt die MAC-Schicht in verschiedene Unterschichten, die Service-Specific Convergence Sublayer (CS), die Common Part Sublayer
(MAC-CPS) und die security sublayer. Die CS ist für die Abbildung der verschiedenen
Transportprotokolle wie IP oder ATM auf die MAC-Schicht zuständig, während sich
die CPS unabhängig davon um Fragmentierung und Segmentierung der übergebenen
Service Data Units (SDU) in Protocol Data Units (PDU) kümmert. Außerdem obliegt
ihr die Disposition, die Kontrolle des QoS und die Durchführung von Wiederübertragungen mittels ARQ (falls erforderlich). Der Standard definiert eine Vielzahl von
Mechanismen, um Bandbreite zu reservieren und Verkehr zu priorisieren, die Details
der Disposition und Reservierung werden den Herstellern überlassen.
Die MAC-Schicht unterstützt sowohl Zeit- als auch Frequenzduplex. Sie arbeitet
verbindungsorientiert und ordnet den Verbindungen direkt QoS-Parameter wie Latenz,
maximalen Jitter und benötigte Bandbreite zu.
Es werden folgenden QoS-Klassen unterschieden:
Unsolicited Grant Services (UGS): für Dienste mit konstanter Bitrate wie T1-
Emulation oder VoIP mit konstanter Bitrate (ohne VAD);
Real-Time Polling Services (rtPS): für Dienste mit variabler Bitrate und periodi-
schem Auftreten von Paketen wie VoIP mit VAD;
Non Real-Time Polling Services (nrtPS): Für Dienste mit keinerlei Delay-Erfor-
dernissen und variablem Auftreten von Bandbreitenanforderungen wie z.B. FTP;
Best-Effort (BE): für Dienste ohne besondere Anforderungen, beispielsweise der
Abruf von HTML-Seiten.
UGS-Verbindungen müssen bei der BS keine Bandbreite anfordern. Sobald die Verbindung eingerichtet ist, werden die erforderlichen Ressourcen automatisch bereitgestellt. Ansonsten werden die benötigten Mittel durch Polling- oder Wettbewerbsmechanismen bereitgestellt [EMSW02].
Weiterhin werden zwei Arten von Subscriber Stations hinsichtlich der Festlegung
von QoS-Parametern unterschieden. Für die einen werden QoS-Parameter insgesamt
festgelegt, für die anderen pro Datenverbindung.
67
3.6.1.3 802.16e
Die im letzten Jahr ratifizierte Standarderweiterung 802.16e [IEEE05c] verbessert die
Unterstützung für mobile Endgeräte im Frequenzbereich unter 6 GHz. Da eine andere
Funktechnologie verwendet wird, ist es genau genommen ein neuer Standard, der nicht
zum ursprünglichen 802.16 Standard kompatibel ist.
Der neue Funkstandard heißt Scalable OFDMA (SOFDMA) und ermöglicht die Nutzung einer variablen Bandbreite durch Veränderung der Fast Fourier Transform (FFT)
bei konstanter Symbolrate und gleichem Kanalabstand der Unterträger [GWAC05]. Zusätzliche Verbesserungen betreffen die Bereiche Empfangsverbesserungen durch Multiple Input Multiple Output (MIMO) und AAS, das Handoff für den Wechsel zwischen
Basisstationen, erweiterte Energiesparmodi und verbesserte Sicherheitsmechanismen
[Wima05].
Das QoS-System entspricht im Wesentlichem dem des Grundstandards, es wurde
eine QoS-Klasse hinzugefügt, die Extended Real-Time Polling Service (ErtPS). Sie
unterscheidet sich durch zusätzlich festlegbare Jitter-Grenzen von rtPS und ist damit
gut geeignet für die Übertragung von VoIP-Gesprächen mit Voice Activity Detection.
Zertifizierte Endgeräte sind für diese Technologie noch nicht erhältlich, allerdings
existieren bereits seit Mai 2006 Chipsätze von Altera [WiMA06c].
Aus mehreren Gründen ist es nicht möglich, eine allgemein gültige Aussage über die für
VoIP-Gespräche zur Verfügung stehende Nettodatenrate zu machen. Zum einen lässt
der Standard viele Wahlmöglichkeiten und Implementierungsspielräume, beispielsweise
bei der Art der verwendeten Physical Layer, dem Einsatz verschiedener Antennenkonfigurationen oder der Implementierung bestimmter Mechanismen. Zum anderen ist
nicht klar, welche Trägerfrequenzen mit welcher Bandbreite benutzt werden (können).
In den WiMAX-Profilen sind bislang für Europa Frequenzbänder um die 3,5 GHz bzw.
5,7 GHz für die Verwendung mit OFDM im P2M Betrieb spezifiziert. Die vorgesehenen Kanalbandbreiten sind 3,5 MHz und 7 MHz (TDD oder FDD) für den unteren
Frequenzbereich und 10 MHz (nur TDD) für den oberen Frequenzbereich. Die Bundesnetzagentur rollt das Vergabeverfahren für den ersten Bereich neu auf, da sich im
ersten Anlauf zu viele Bewerber fanden [Bund06].
Eine grobe Überschlagsrechnung für die Leistungsfähigkeit der WiMAX-Technologie
zur Übertragung von VoIP-Daten gestaltet sich wie folgt: Ausgehend von dem in
Deutschland angedachten Frequenzband mit 7 MHz Bandbreite im TDD-Modus, er-
68
reicht man eine maximale Datenrate von 26,18 MBit/s bei Einsatz der 64QAM. Angenommen, es wird eine Framelänge von 10 ms eingesetzt mit nur einer einzigen Subscriber Station, so ergibt sich nach Abzug der Zeiten zwischen Up- und Downlinkteil
(1µs), der Präambel (drei Symbole) und des FCH (1 Symbol) eine Übertragungsrate
pro Frame von 299 Symbolen mit jeweils 864 Bit [Agil05]. In der MAC-Convergence
Layer wird die optionale Headerunterdrückung genutzt, so dass sich die resultierende
MAC-PDU aus den eigentlichen VoIP-Daten mit RTP/UDP zusammensetzt (180 bzw.
40 Byte), dem Packet Header Supression (PHS)-Header (ein Byte) und dem MACHeader (sechs Byte). Damit ergibt sich eine Größe von 187 Byte (G.711) bzw. 47 Byte
(G.729), für die Übertragung würde man somit zwei bzw. ein Symbol benötigen. Da
die Framelänge 10 ms beträgt, stehen 29.900 Symbole pro Sekunde zur Verfügung, für
eine G.711-VoIP-Verbindung werden 200 Symbole/s benötigt, es ergibt sich eine maximale Anzahl von 149 gleichzeitig zu führenden Gesprächen bei optimalen Bedingungen.
Für den G.729-Codec ergibt sich analog eine maximale Anzahl von 299 Gesprächen.
Diese Beispielrechnung berücksichtigt weder den Verkehr von Steuerdaten, noch das
Auftreten von Wiederübertragungen und geht außerdem von optimalen Kanalbedingungen aus. Zudem werden durch die Technologie mögliche Optimierungen wie IPHeaderunterdrückung und direkter Transport von IP-Paketen über die MAC-CS mit
einkalkuliert. Trotz dieser gravierenden Einschränkungen zeigt diese Beispielrechnung
doch deutlich die Leistungsfähigkeit der WiMAX-Technologie auf.
Allgemein lässt sich feststellen, dass der Overhead bei der Übertragung von Sprachdaten erheblich kleiner ausfällt, als bei der Verwendung von WLAN. Die Spezifikation
sieht für die Übertragung von IP-Paketen eine eigene MAC-Konvergenzschicht vor,
die Komprimierung von RTP/UDP/IP-Headern nach RFC 3545 oder RFC 3095 (nur
IEEE 802.16e) bzw. die Übertragung mit unterdrückten IP-Headern wird unterstützt.
Durch die eingesetzte Technologie ist das Übertragungsverfahren im Ganzen effektiver
als die bisher betrachteten Verfahren.
Die implementierten QoS-Mechanismen wirken sich positiv auf die Latenzzeiten aus.
Wenn der VoIP-Verkehr über die UGS-Prioritätsklasse transportiert wird, steht die benötigte Bandbreite mit den entsprechenden Vorgaben für maximalen Jitter und Latenz
garantiert zur Verfügung. Die untere Grenze der Latenz hängt von der Länge und Zusammenstellung des Übertragungsrahmens ab, da im Downlink erst der entsprechende
Burst empfangen werden muss bzw. im Uplink sich der Burst auch erst am Ende des
Rahmens befinden kann.
69
3.7 Zusammenfassung
In den vorangegangenen Abschnitten wurden die Unterschiede der einzelnen Technologien bezüglich ihrer Implementierung erläutert. Für die Betrachtungen innerhalb
dieser Arbeit sind vor allem die Latenzzeit und die maximal mögliche Anzahl von
VoIP-Gesprächen ausschlaggebend.
Im Hinblick auf die minimale Latenzzeit eines Paketes ordnen sich WiMAX und
WLAN mit theoretischen Werten von unter 1 ms deutlich vor Bluetooth und den
Mobilfunktechnologien ein. Letztere haben technologiebedingt bereits Mindestverzögerungen von ca. 20 ms (GPRS) oder die Grenzwerte für die QoS-Mechanismen sind
entsprechend hoch angesetzt (UMTS). Die Literaturquellen geben Latenzzeiten von
55,4 ms - 600 ms für die Übertragung an, so dass eine Eignung fraglich ist und im
Einzelfall durch praktische Versuche nachgewiesen werden muss.
Bei der Zahl der theoretisch maximal möglichen Gespräche sind die Mobilfunktechnologie aufgrund geringer Datenraten nicht sehr leistungsfähig. Selbst die Einführung
von HSDPA stellt keine Verbesserung dar, lediglich im Downlink können bessere Raten
erzielt werden.
Technisch ist WiMAX allen anderen betrachteten Technologien überlegen, besonders durch die konsequente Implementierung von QoS-Mechanismen. Es stehen allerdings noch keine Geräte zur Verfügung, die Lizenzvergabe ist noch nicht abgeschlossen.
WLAN dagegen ist gut geeignet, hat allerdings gegenüber WiMAX den Nachteil der
geringeren Reichweite.
4 Vergleich ausgewählter Technologien anhand von Praxistests
70
4 Vergleich ausgewählter
Technologien anhand von
Praxistests
Um die Leistungsfähigkeit von drahtlosen Datenübertragungstechnologien im Hinblick
auf die Übertragung von VoIP-Gesprächen zu überprüfen und mit den in Kapitel 3 gesammelten Erkenntnissen zu vergleichen, wurden im Rahmen dieser Arbeit Praxistests
durchgeführt. Die Tests konzentrierten sich auf die Fähigkeit der jeweiligen Technologie,
Ströme von RTP-Paketen zu übertragen, da dies für die Sprachqualität ausschlaggebend ist. Dazu wurde unter Verwendung frei verfügbarer Software eine Testumgebung
entworfen, in der wesentliche Parameter der Paketübertragung gemessen werden können. In den Praxistests wurden die Funktechnologien WLAN 802.11g, sowohl im abwärtskompatiblen Modus als auch im reinen g-Betrieb und Bluetooth (Version 1.2) verwendet. Entgegen dem ursprünglichen Vorhaben, konnte die Übertragung über GPRS
nicht getestet werden, die Messumgebung verhielt sich instabil. Darüber hinaus ergaben vorbereitende Messungen Round-Trip-Times (RTTs) von 856 ms (G.711) bzw. 909
ms (G.729), die über einem Wert von 150 ms in einer Richtung, respektive 300 ms RTT
hinausgehen (vgl. Abschnitt 2.1.1).
Die verwendeten Skripte und Messdaten finden sich auf der dieser Arbeit beiliegenden DVD.
4.2 Zielsetzung und Vorgehen
Ziel der Praxistests war die Beurteilung von drahtlosen Technologien hinsichtlich ihrer
Eignung, in einer realitätsnahen Umgebung VoIP-Gespräche zu einem mobilen Endgerät zu übertragen.
71
Im Hinblick auf den Transport über ein paketbasiertes Netz ist die Übertragung der
Sprachdaten mittels des RTP-Protokolls als der kritische Teil anzusehen. Im Gegensatz zum Signalisierungsverkehr reagiert die Sprachqualität empfindlich auf schlechte
Netzwerkparameter wie lange Laufzeiten, Abweichungen von der Laufzeit und Paketverluste.
Parameter Die zu messenden Parameter sind die Latenzzeit, der Jitter, die auftretenden Paketverluste und die Datenrate für VoIP-Verkehr.
Um die Laufzeit eines Paketes zwischen zwei Computern zu ermitteln, ist es unabdingbar, dass die Systemzeit auf beiden Geräten exakt übereinstimmt. Die beste
Methode dieses ohne zusätzliche Hardware zu erreichen, ist dabei die Verwendung
des Network Time Protocol (NTP). Dabei synchronisiert ein im Hintergrund laufender
Dienst auf dem Computer regelmäßig die Systemzeit mit einem Zeitgeber im Internet.
In Anbetracht der erwarteten Mindestlaufzeiten der Pakete von etwa einer Millisekunde, ist die geforderte Präzision an die Zeitsynchronisierung sehr hoch. Vorbereitende Messungen ergaben, dass NTP nicht in der Lage ist, auf mobilen Endgeräten die
Zeitabweichung in den erforderlichen Grenzen zu halten.
Somit schied die Möglichkeit der direkten Messung von Paketlaufzeiten zwischen
zwei Rechnern aus. Als Alternative zur Beurteilung der Fähigkeit der untersuchten
Technologien RTP-Verkehr zu transportieren, wurde die Round-Trip-Time (RTT) herangezogen. Die RTT gibt die Zeitspanne an, die ein Paket von Rechner A zu Rechner
B und zurück benötigt. Anhand der RTT ist es möglich, die Eignung einer Technologie zu beurteilen, allerdings ist das Verhältnis der Zeiten für Hin- und Rückweg des
Paketes nicht zu ermitteln. Wie in Kapitel 3 beschrieben, werden sich aufgrund der
unterschiedlichen Zugriffsverfahren Unterschiede in den Laufzeiten zeigen.
Wie in Abschnitt 2.1.1 dargestellt, ist für eine gute Sprachqualität eine Verzögerung
vom Mund des Sprechers bis hin zum Ohr des Zuhörers von weniger als 150 ms erforderlich, eine Zeitspanne bis 400 ms ist akzeptabel. Die im Abschnitt 2.1.2 beschriebenen
Verzögerungen durch die Komprimierung und Dekomprimierung der Sprache kosten je
nach verwendetem Codec unterschiedlich viel Zeit. Diese Verzögerung kann laut ITU-T
Standard G.114 [ITU-03a] bis zu 97,5 ms (G.723.1) betragen und reduziert die Zeit,
die einem Paket für seinen Weg zum Ziel zur Verfügung steht.
Modellierung von VoIP-Gesprächen VoIP-Verkehr sollte für die Tests ursprünglich
mit Hilfe von VoIP-Clients hergestellt werden. Da dem Autor aber kein skriptfähiges Programm zur Verfügung stand, das automatisierte Messungen ermöglicht hätte,
72
musste eine andere Lösung gefunden werden. Tests mit frei verfügbaren Verkehrsgeneratoren, die in der Lage sind, VoIP-Verkehr zu erzeugen (beispielsweise [Univ06],
[Cand06] oder [Sour06]) zeigten, dass sich diese nicht eignen. Im Endeffekt musste auf
die Einbeziehung des Signalisierungsverkehrs verzichtet und auf einfache, frei verfügbare Programme zur Generierung von RTP-Strömen zurückgegriffen werden.
Da auch Programme zur Analyse von Paketströmen während vorhergehender Testmessungen bei der Beurteilung Schwächen offenbarten, wurden die Versuche mit Hilfe
von Matlab-Skripten ausgewertet.
4.3 Versuchsumgebung
Um möglichst realistische Ergebnisse zu erzielen, fanden die Messungen für die vorliegende Arbeit in einer Wohnumgebung statt. Das verwendete mobile Endgerät ist
ein Laptop, auf dem als Betriebssystem Windows XP Professional installiert ist. Die
Entscheidung für die Verwendung von Windows XP Professional auf dem mobilen
Endgerät wurde bewusst getroffen, da die meisten für VoIP geeigneten Endgeräte eine
Version des Betriebssystemes Microsoft Windows verwenden. Die Messungen erfolgten zwischen dem mobilen Endgerät und einem zweiten Rechner (Server), auf dem sich
als Betriebssystem Gentoo Linux 2.6.16 befindet.
Das Versuchsszenario stellt sich wie in Abbildung 4.1 dar.
Laptop
Funkstrecke
Accesspoint
LAN
Linux Server
Ethernet
Dumpcap
Aufzeichnung
RTP Strom
Rtpsend
Generiert
RTP-Strom
Dumpcap
Aufzeichnung
RTP Strom
RTP-Pakete mit Audiodaten
RTP-Pakete mit Audiodaten
SIPp
Reflektiert RTPPakete
Abbildung 4.1: Aufbau der Messumgebung [Eigene Darstellung]
Die Verwendung eines Infrastrukturszenarios, in dem sich zwischen Access Point und
Server noch eine kurze Ethernetverbindung befindet, wurde absichtlich gewählt. Zum
einen kommt diese Konfiguration einem in Wirklichkeit eingesetzten Netz näher als
beispielsweise zwei mit WLAN-Adaptern ausgestattete Laptops. Zum anderen ist der
73
Einfluss der Ethernetübertragung so gering, dass davon ausgegangen werden kann, dass
die Netzwerkparameter in der Hauptsache von der Funkstrecke beeinflusst werden.
Messungen wurden für WLAN sowohl im reinen 802.11g-Betriebsmodus als auch im
abwärtskompatiblen Modus 802.11bg und für Bluetooth v1.2 durchgeführt. Für jede
Technologie fanden Versuche an drei verschiedenen Positionen statt. Auf Position 1
wurde der Laptop in direkter Sichtverbindung zwei Meter vom Access Point entfernt
platziert. An dieser Position sollten optimale Empfangsbedingungen herrschen. Position 2 befand sich ca. 5 m entfernt in einem anderen Raum, dabei befanden sich zwei
Stahlbetonwände zwischen Laptop und AP. Für Position 3 wurde der Access Point
außen am Gebäude angebracht, in einer Höhe von ca. 10 m. Der Laptop befand sich
während der Messung ebenerdig in direkter Sichtverbindung ca. 100 m entfernt.
Damit ergaben sich folgende acht Kombinationen, in denen jeweils RTP-Ströme
entsprechend verschiedenen Codecs erzeugt wurden.
Situation
Position 1
Position 2
Position 3
WLAN 802.11g
G.711/G.729
G.711/G.729
G.711/G.729
WLAN 802.11bg
G.711/G.729
G.711/G.729
G.711/G.729
Bluetooth v1.2
G.711/G.729
G.711/G.729
kein Empfang
Tabelle 4.1: Kombinationen von Positionen und Technologien
4.3.1 Hardware
Das im Szenario verwendete Endgerät ist ein Laptop Anima 3200 der Firma Wortmann
AG, die verbaute CPU ist ein AMD Mobile Sempron 3000+.
Für die WLAN-Messungen stand ein Access Point Linksys WAG54v2 zur Verfügung,
der die Standards 802.11b und 802.11g unterstützt. Zum Empfang am Endgerät kam
eine PCMCIA-Karte Netgear WAG511, basierend auf dem Atheros Chipsatz zum
Einsatz. Auch diese unterstützt die Standards 802.11b und 802.11g.
Der Access Point für die Bluetooth-Messungen ist ein Anycom AP-2002, der Bluetooth v1.2 unterstützt. Dieses ist ein Class 1 Gerät, das PAN-Profil wird unterstützt.
Am mobilen Endgerät kam ein USB-Bluetooth Empfänger Trust BT-180 zum Einsatz,
der Bluetooth-Version 2.0 und 1.2 unterstützt.
Mit allen Geräten wurden jeweils die aktuellen vom Hersteller zur Verfügung gestellten Treiber- bzw. Firmwareversionen verwendet.
74
4.3.2 Software
4.3.2.1 hrPING
Das Programm PING sendet ICMP Echo Requests“ an einen entfernten Rechner, der
”
daraufhin mit Echo Response“-Paketen antwortet. Das Programm misst die Laufzeit
”
einer solchen Anfrage. Da die zeitliche Auflösung des mit Microsoft Windows mitgelieferten PING-Programmes sehr grob ist (Laufzeiten kleiner als 10 ms werden nicht
näher aufgelöst), wurde bei diesen Messungen das frei erhältliche Programm hrPING
v2.26 von der cfos Software GmbH [cfos06] verwendet. Das Programm greift zur Zeitmessung auf den Prozessortakt zu und ist somit erheblich präziser.
4.3.2.2 netio
Das von Kai Uwe Rommel entwickelte Programm netio v1.26 [ARS 06] ist eine ClientServer-Applikation zur Messung des maximal möglichen Netzwerkdurchsatzes. Es unterstützt Messungen sowohl mit UDP oder TCP und verschiedene Paketgrößen.
4.3.2.3 rtp-tools
Zur Generation von RTP-Strömen wurde das von der Universität Columbia entwickelte
Programm rtpsend verwendet. Dieses gehört zu einem Satz von Programmen, den
rtptools v1.18 [Colu06], die zum Test von RTP-Verbindungen dienen. Rtpsend kann
aus einer Textdatei mit Paketdaten einen RTP-Strom generieren.
4.3.2.4 SIPp
SIPp [Sour06] ist eine unter der GNU General Public License veröffentlichte Open
Source Software, die zur Generierung und zum Test von SIP-Verbindungen dient. Mittlerweile werden auch in begrenztem Umfang Medienströme unterstützt. Bei den betrachteten Tests kam SIPp in der Version 1.1 als Reflektor für RTP-Pakete zum
Einsatz.
4.3.2.5 Wireshark
Wireshark [Wire06] ist ein ebenfalls unter der GNU General Public License veröffentlichter Protokollanalysator. Der Netzwerkverkehr auf einer Netzwerkschnittstelle kann
abgefangen und gespeichert werden. Wireshark bietet sehr umfangreiche Möglichkeiten zur Auswertung verschiedener Protokolle. In den Praxistests kamen die Kommando-
75
zeilenprogramme dumpcap und tshark Version 0.99.2 zur Aufzeichnung, Filterung
und Konvertierung der Pakete zum Einsatz.
4.3.2.6 TrafMeter
TrafMeter 6.4 ist ein Programm der Firma LastBit Software, das es erlaubt, den
Datendurchsatz über eine Netzwerkschnittstelle ständig zu analysieren. Bei den im
Rahmen dieser Arbeit durchgeführten Messungen wurde es verwendet, um eine zusätzliche Angabe über die Datenrate der Verbindung zu ermitteln. Verwendet wurde die
Testversion des Programms.
4.3.2.7 Bandwidth Monitor Pro
Das Programm Bandwidth Monitor Pro [Sind06] in der Version 1.30 erlaubt ebenfalls die Messung der Datenrate des Verkehrs, der über eine bestimmte Schnittstelle
verursacht wird. Zur Messung wurde die kostenlos erhältliche Testversion benutzt.
4.3.3 Messungen
4.3.3.1 Vorbereitende Messungen
Zur Bestimmung der Leistungsfähigkeit der Funktechnologien wurden bei jeder Technologie-/Positionskombination vorher die Laufzeiten von Paketen der Größe von G.711bzw. G.729-Sprachpaketen mittels hrPING (siehe Abschnitt 4.3.2.1) gemessen. Desweiteren wurden zwischen Laptop und Server Messungen mit Hilfe der Software netio
(Abschnitt 4.3.2.2) durchgeführt, um den Durchsatz der Verbindung bei einer bestimmten Paketgröße zu ermitteln. Die Messungen mit netio lieferten unbrauchbare Ergebnisse, deshalb wird auf diese Messungen im Weiteren nicht eingegangen.
4.3.3.2 RTP-Ströme
Für jede Messung wurde auf dem Laptop mittels rtpsend aus einer Konfigurationsdatei ein Strom von RTP-Paketen erzeugt und an den Server gesendet. Die beiden verwendeten Konfigurationsdateien waren so angelegt, dass ihre Kennwerte den RTP-Strömen
eines VoIP-Gespräches unter Verwendung eines G.711- und eines G.729-Codec entsprachen. Headerkomprimierung oder Voice-Activity-Detection fanden keine Berücksichtigung. In beiden Fällen wurden 20 ms als Codierungsintervall gewählt, da dieser Wert
einen guten Kompromiss zwischen Datenrateneffizienz und geringer Latenzzeit dar-
76
stellt. Die erzeugten RTP-Ströme enthielten jeweils 4.001 Pakete, entsprechend einem
80 Sekunden langen Telefonat.
Auf dem Server lief das Programm SIPp (siehe Abschnitt 4.3.2.4), das bei den
betrachteten Messungen lediglich dazu diente, die RTP-Pakete zu reflektieren.
Dieser Aufbau verursacht einen gegenseitigen RTP-Strom zwischen den beteiligten
Rechnern, der dem eines VoIP-Gespräches entspricht. Es wurden für jede Technologie/Positionskombination (siehe Tabelle 4.1) 50 RTP-Ströme erzeugt.
Sowohl auf dem Server als auch auf dem Laptop wurden die Pakete mittels dumpcap (siehe Abschnitt 4.3.2.5) aufgezeichnet. Dabei wurde auf dem Laptop jede Einzelmessung getrennt gespeichert. Auf dem Server wurden dagegen alle 50 zusammengehörige Paketströme in einer Datei gespeichert.
Für die Messungen wurden, soweit möglich, Batchdateien erstellt, um die Vorgänge weitestgehend zu automatisieren. Diese Dateien finden sich auf der dieser Arbeit
beiliegenden DVD.
4.4 Auswertung
Um auswertbare Daten zu erhalten, wurden die Daten der Paketköpfe zunächst mittels
tshark in lesbare Textdateien konvertiert. Diese Textdateien konnten dann mittels
Matlab-Skripten ausgewertet werden. Zum besseren Verständnis sollen die einzelnen
Skripte hier kurz erklärt werden.
auswert.m: Wertet jeweils 50 zusammengehörige, auf dem Laptop gespeicherte
Messungen bezüglich Latenz, Jitter und Paketverlusten aus und schreibt die Ergebnisse in eine Excel-Datei;
auswert server.m: Wertet jeweils 50 zusammengehörige, auf dem Server gespei-
cherte Messungen aus und speichert die Ergebnisse in eine Excel-Datei;
packet info.m: Bestimmt für eine Messung die mittlere Latenz und die Paketver-
luste;
packet jitter.m: Berechnet für jeweils einen Paketstrom den mittleren Jitter (zur
Berechnung siehe Abschnitt 4.4.3);
read pcap.m: Liest die Daten einer Messung in eine Matrix ein;
77
read pcap raw.m: Liest die Daten von 50 Messungen auf dem Server ein. Dieses
ist notwendig, da der Server alle 50 Messungen hintereinander in einer Datei
speichert;
convert2daten.m: Konvertiert die mit read pcap raw.m eingelesenen Daten in
Einzelmessungen, die dann wiederum mit packet info.m bzw. packet jitter.m ausgewertet werden können;
packet jitter jp.m: Liefert Jitter und Latenzzeit für alle Pakete, deren Jitter
einen bestimmten Wert nicht überschreitet. Damit soll das Verhalten eines JitterPuffers simuliert werden.
Die Endauswertung der Messungen erfolgte mittels Excel-Dateien. Wie die einzelnen Kennwerte berechnet wurden, wird in den folgenden Abschnitt erläutert.
4.4.1 Round-Trip-Time (RTT)
Die RTT wurde aus den Zeitstempeln der Paketaufzeichnung auf dem Laptop errechnet. Die Pakete wurden anhand ihrer Sequenznummer identifiziert, so konnte die Zeit
ermittelt werden, die das Paket für Hin- und Rückweg benötigte. Als Korrektur wurde
die Zeitdifferenz zwischen Ankunft und Versand auf dem Server abgezogen.
4.4.2 Paketverluste
Die Paketverluste wurden anhand der Sequenznummern sowohl aus den Messdaten auf
dem Server als auch auf dem Laptop berechnet. Dadurch war es möglich, die Zahl der
verlorengegangenen Pakete sowohl auf dem Weg zum Server hin als auch zum Laptop
zurück zu bestimmen.
4.4.3 Jitter
Die Jitter-Werte wurden aus der Abweichung der Ankunftszeit jeweils zweier Pakete
aufeinanderfolgender Sequenznummern bestimmt. Die Sollankunftszeit wurde, anders
als in RFC 3550 [IETF03b] beschrieben, mit der Länge der Sprachsamples (20 ms)
angesetzt. Im Falle eines realen VoIP-Gesprächs ist der Codec nach Ablauf dieser Zeitspanne auf das nächste Paket angewiesen, um ein unterbrechungsfreies Sprachsignal zu
garantieren. Wie in Abschnitt 2.1.2 beschrieben, fängt ein Jitter-Puffer die Abweichungen bis zu einem bestimmten Wert auf, allerdings dürfen die Abweichungen nicht zu
groß werden.
78
4.4.4 Datenrate
Die Datenraten wurden rechnerisch aus den aufgezeichneten Paketströmen bestimmt.
Des Weiteren wurden die Datenrate während der Messungen mit Hilfe der Programme
TrafMeter und Bandwidth Monitor Pro ermittelt.
4.4.5 Jitter-Puffer
Bei einem realen VoIP-Gespräch werden Pakete verworfen, deren Laufzeitabweichungen nicht durch den Jitter-Puffer kompensiert werden können. Deshalb wurde eine
zweite Auswertung der Messdaten für einen fiktiven Jitter-Puffer angefertigt. Dessen
Größe betrug für die vom Server empfangenen Ströme 20 ms und für die am Laptop
empfangenen Ströme 40 ms (da sich die Werte für ein einzelnes Paket aufaddieren
können). Pakete, deren Jitter größer war, wurden bei der Kalkulation von RTT und
Jitter nicht berücksichtigt und als zusätzliche Verluste gewertet.
4.5 Ergebnisse
4.5.1 Test hrPING
Vorbereitend wurden wie beschrieben für jede Positions-/Technologiekombination jeweils 2.000 Tests mit hrPING durchgeführt. Dabei wurden die Tests entsprechend
später verwendeter Codecs mit 60 Byte bzw. 200 Byte großen Paketen durchgeführt.
Es ergaben sich im Mittel die in Tabelle 4.2 dargestellten Werte für die RTT.
Situation
WLAN 802.11g (60 Byte)
WLAN 802.11g (200 Byte)
WLAN 802.11bg (60 Byte)
WLAN 802.11bg (200 Byte)
Bluetooth (60 Byte)
Bluetooth (200 Byte)
Position 1 Position 2 Position 3
3,25
2,94
2,44
3,53
3,59
4,37
1,9
3,39
2,29
1,46
3,13
2,86
37,01
45,51
kein Empfang
37,47
45,87
kein Empfang
Tabelle 4.2: RTT in ms mittels hrPING
4.5.2 RTP-Verkehr
Den eigentlichen Kern der Praxistests bildeten die Generierung und Auswertung von
RTP-Strömen wie in Abschnitt 4.3.3.2 beschrieben.
79
4.5.2.1 Round-Trip-Time
Die Messungen ergaben die in Tabelle 4.3 dargestellten Werte, die Ergebnisse sind über
jeweils 50 Messungen gemittelt.
Situation
WLAN 802.11g G.711
1,99
1,80
4,12
WLAN 802.11g G.729
1,69
1,56
1,84
WLAN 802.11bg G.711 2,02
1,82
2,19
WLAN 802.11bg G.729 1,70
1,64
1,83
Bluetooth G.711
691,44
843,82
kein Empfang
Bluetooth G.729
36,08
38,19
kein Empfang
mit fiktivem Jitter-Puffer
WLAN 802.11g G.711
1,89
1,67
4,14
WLAN 802.11g G.729
1,59
1,43
1,78
WLAN 802.11bg G.711 1,88
1,69
2,11
WLAN 802.11bg G.729 1,62
1,57
1,72
Bluetooth G.711
653,37
843,68
kein Empfang
Bluetooth G.729
35,55
37,78
kein Empfang
Tabelle 4.3: RTP-Ströme: RTT in ms
Die Ergebnisse für die WLAN-Technologie liegen im erwarteten Bereich. Es fällt auf,
dass sich offensichtlich die Länge der Pakete minimal auswirkt und die RTT mit zunehmender Entfernung größer wird. Für Bluetooth ergeben sich dagegen höhere Werte,
besonders der G.711-Codec liefert RTTs, die für VoIP-Verkehr nicht mehr geeignet
sind.
Die zusätzliche Auswertung mit fiktivem Jitter-Puffer liefert erwartungsgemäß kleinere Latenzzeiten, die allerdings sehr dicht an den Messwerten ohne Jitter-Puffer liegen.
4.5.2.2 Jitter
Die mittleren Jitter-Werte der Messungen sind in den Tabellen 4.4 und 4.5 getrennt für
den Strom vom Laptop zum Server und für den beim Laptop ankommenden Paketstrom
aufgezeichnet. Die letzteren Jitter-Werte beinhalten die des Uplinks.
4.5.2.3 Paketverluste
Die Paketverlustraten für die WLAN-Technologie blieben alle unter einem Grenzwert
von 3%, selbst unter Berücksichtigung des Einflusses eines Jitter-Puffers, der in der
Auswertung alle Pakete mit mehr als 20 ms Jitter verwirft. Anders Bluetooth: für den
G.711 erreichte die Technologie im Downlink Verlustraten von über 10%. Die Tabellen
80
Situation
WLAN 802.11g G.711
6,61
0,86
2,53
WLAN 802.11g G.729
6,61
0,87
1,04
WLAN 802.11bg G.711 6,90
0,86
1,00
WLAN 802.11bg G.729 6,60
6,66
0,93
Bluetooth G.711
3,28
4,27
kein Empfang
Bluetooth G.729
8,38
3,00
kein Empfang
WLAN 802.11g G.711
6,43
0,70
2,53
WLAN 802.11g G.729
6,43
0,71
1,04
WLAN 802.11bg G.711 6,63
0,71
1,00
WLAN 802.11bg G.729 6,43
6,47
0,93
Bluetooth G.711
3,18
3,61
kein Empfang
Bluetooth G.729
7,67
2,94
kein Empfang
Tabelle 4.4: RTP-Ströme Laptop-Server: Jitter in ms
Situation
WLAN 802.11g G.711
6,61
1,12
2,82
WLAN 802.11g G.729
6,66
1,13
1,34
WLAN 802.11bg G.711 6,98
1,12
1,30
WLAN 802.11bg G.729 6,66
6,70
1,24
Bluetooth G.711
4,96
4,31
kein Empfang
Bluetooth G.729
9,06
6,42
kein Empfang
WLAN 802.11g G.711
6,57
1,00
2,53
WLAN 802.11g G.729
6,57
1,01
1,04
WLAN 802.11bg G.711 6,85
1,01
1,00
WLAN 802.11bg G.729 6,57
6,63
0,93
Bluetooth G.711
4,41
3,58
kein Empfang
Bluetooth G.729
8,54
5,97
kein Empfang
Tabelle 4.5: RTP-Ströme am Laptop ankommend: Jitter in ms
4.6 und 4.7 zeigen die Werte unter Einbezug des fiktiven Jitter-Puffers, da diese ein
realistischeres Bild erlauben.
4.5.2.4 Datenrate
Die Datenrate wurde für jeden Versuch zum einen rechnerisch aus den vorliegenden
Paketdaten bestimmt, zum anderen zusätzlich mit TrafMeter und Bandwidth Monitor Pro gemessen. Es ergaben sich die erwarteten Datenraten von 80 kBit/s (G.711)
bzw. 24 kBit/s (G.729) mit kleinen Abweichungen. Bei auftretenden Paketverlusten
Situation
WLAN 802.11g G.711
WLAN 802.11g G.729
WLAN 802.11bg G.711
WLAN 802.11bg G.729
Bluetooth G.711
Bluetooth G.729
81
0,41
0,04
1,30
0,41
0,37
0,45
0,90
0,34
0,42
0,40
0,49
0,40
0,29
2,12
kein Empfang
1,88
0,21
kein Empfang
Tabelle 4.6: Paketverluste in % für den Paketstrom Laptop-Server
Situation
WLAN 802.11g G.711
WLAN 802.11g G.729
WLAN 802.11bg G.711
WLAN 802.11bg G.729
Bluetooth G.711
Bluetooth G.729
0,44
0,33
0,45
0,44
0,32
0,35
0,41
0,31
0,35
0,43
0,46
0,46
12,08
16,76
kein Empfang
0,66
0,83
kein Empfang
Tabelle 4.7: Paketverluste in % für den Paketstrom Server-Laptop
fiel die Datenrate um einen entsprechenden Wert.
4.5.3 Zusammenfassung
Die vorbereitenden Messungen mit hrPING lieferten im Hinblick auf die Endergebnisse leider nicht die erwarteten Anhaltspunkte für die Leistungsfähigkeit der Technologien. Im Vergleich zu den Messungen der RTP-Ströme fielen die Werte durchweg zu
hoch aus.
Die eigentlichen Kernmessungen bescheinigen WLAN in allen Varianten und in unterschiedlichen Entfernungen eine gute Eignung für VoIP-Verkehr. Bei einer RTT um
2 ms sind Einweglatenzzeiten von 1 ms realistisch, was selbst unter Berücksichtigung
der Jitter-Werte noch einen großen Puffer für den Transport durch den Rest des Netzwerkes lässt, um eine gute Sprachqualität zu erreichen. Bei Bluetooth hat sich der
Transport von Sprachdaten mittels des G.711-Codecs aufgrund der Paketverlustraten
und RTTs als ungeeignet erwiesen, mittels niederbitratiger Codecs lässt sich aber auch
hier durchaus Sprache transportieren.
5 Kostenanalyse
82
5 Kostenanalyse
In diesem Kapitel wird ein Überblick über die zu erwartenden Kosten bei Verwendung
einer drahtlosen Technologie für VoIP-Gespräche gegeben. Der Abschnitt 5.2 konzentriert sich dabei auf die variablen Kosten, die auf den Endnutzer durch die angebotenen
Tarife zukommen. Im Abschnitt 5.3 wird auf die Anschaffungskosten eingegangen, die
durch die Investition in geeignete Geräte entstehen. Dabei ist zu unterscheiden zwischen
einem nicht öffentlichen Funkzugang, wie er beispielsweise durch drahtlose Firmenoder Heimnetze besteht und öffentlich angebotenen Zugängen, hinter denen üblicherweise eine Betreibergesellschaft steht. Ein Funkzugang beispielsweise über WLAN im
Heimnetz, das dann über einen DSL-Zugang mit dem Internet verbunden wird, ist
für den Nutzer, von den Anschaffungskosten abgesehen, nur mit Kosten für den Internetzugang verbunden. Dieser wird üblicherweise nicht ausschließlich für VoIP genutzt.
Die folgenden Betrachtungen beschränken sich auf drahtlose Verbindungen, die von
Unternehmen öffentlich angeboten werden.
5.2 Laufende Kosten
Grundsätzlich lassen sich die angebotenen Funkzugänge nach Technologie und Art des
Tarifs differenzieren. Übliche Arten von angebotenen Tarifen sind Zeittarife, bei denen
das Entgelt nach Nutzungsdauer des Zugangs erhoben wird, Volumentarife, die nach
übertragenem Datenvolumen abgerechnet werden und Flatrates, bei denen gegen Zahlung einer Gebühr zu jeder Zeit soviel Netzwerkverkehr wie gewünscht, oder technisch
möglich, verursacht werden kann.
Um die Tarife im Hinblick auf VoIP mit den richtigen Kosten zu bewerten, werden
sie im Folgenden anhand der bislang verwendeten Beispiele eines G.711- und eines
G.729-Datenstroms mit 20 ms Abstand der Sprachsamples verglichen. VAD und Headerkompression werden nicht berücksichtigt.
5 Kostenanalyse
83
Da Bluetooth in seiner Reichweite sehr begrenzt ist, gibt es keine Anbieter, die
Zugänge anbieten.
5.2.1 Mobilfunktarife
Unter Mobilfunk soll im Folgenden der Funkzugang über die GSM- und UMTS-Netze,
die Erweiterungen durch EDGE und HSDPA beinhaltend, verstanden werden. In die
Kostenbetrachtungen wurden die vier großen Mobilfunkprovider in Deutschland TMobile [T-Mo06], Vodafone [Voda06], E-Plus [E-Pl06] und O2 [O2 G06] einbezogen.
Die Tarifinformationen finden sich jeweils auf den Webseiten der Unternehmen.
Alle Anbieter stellen ein breites Spektrum an Tarifoptionen bereit, die entweder eigene Datentarife darstellen oder zu bestehenden Verträgen zubuchbare Optionen sind.
Für ihre Flatrates bzw. Tarife mit hohem Freivolumen untersagen die Anbieter - abgesehen von Vodafone - die Nutzung von VoIP. Die ausgeschlossenen Tarife, zu denen
alle Flatrates gehören, werden deshalb nicht weiter betrachtet.
Die Netze der Anbieter sind unterschiedlich weit ausgebaut. Tabelle 5.1 gibt einen
Überblick darüber, welche Technologien von welchen Unternehmen angeboten werden.
Anbieter
T-Mobile
Vodafone
E-Plus
O2
Technologien
GPRS, EGPRS, UMTS, HSDPA, WLAN
GPRS, UMTS, HSDPA, WLAN
GPRS, UMTS, WLAN
GPRS, UMTS, WLAN
Tabelle 5.1: Angebotene Technologien der Mobilfunkprovider in Deutschland
5.2.1.1 Zeittarifoptionen
Die Zeittarife sind in der Regel mit allen verfügbaren Technologien nutzbar. Sie enthalten eine bestimmte Zahl an Freiminuten, wird der Netzzugang länger als diese Inklusivdauer benötigt, steigen die Preise pro Minute rapide an. Tabelle 5.2 gibt einen
Überblick über die Angebote. Der Minutenpreis bezieht sich dabei auf die im Tarif
enthaltene Zeit.
Der Vodafone Zuhause Tarif kann dabei nur in einem bestimmten Bereich, meistens
um die Wohnadresse herum, genutzt werden. Die von den Unternehmen angebotenen
Tarife, die lediglich WLAN beinhalten, sind unter Abschnitt 5.2.2 mit aufgeführt.
5 Kostenanalyse
84
Anbieter
Tarifoption
Inklusivminuten
Abrechnungsintervall
T-Mobile
T-Mobile
Vodafone
Vodafone
Vodafone
O2
Data Time 120
Data Time 600
Time L
Time XL
Zuhause Zeit
Surf@Home
120 min.
600 min.
120 min.
1440 min.
3600 min.
-
10 min.
10 min.
10 min.
10 min.
10 min.
1 min.
Kosten/min
(Cent)
8,33
5
8,22
2,42
0,83
3
Tabelle 5.2: Angebotene Zeittarife für Datenverkehr
5.2.1.2 Volumentarifoptionen
Die in einen Mobilfunkvertrag integrierten Datenoptionen sind meistens Volumentarife,
die zur gelegentlichen Nutzung des Netzzuganges oder zur Übertragung beispielsweise
von MMS-Nachrichten dienen. In Deutschland angebotenen Volumentarife zeigt Tabelle 5.3 in der Übersicht.
Für die Übertragung von VoIP-Gesprächen mittels G.711- bzw. G.729-Codecs (20
ms Sprachsamples) wurden Minutenpreise berechnet. Die Datenraten wurden um 5%
erhöht, um die durch etwaigen Signalisierungsverkehr entstehenden Kosten zu berücksichtigen. Damit ergeben sich Datenraten von 10,5 kByte/s (G.711) bzw. 3,15 kByte/s
(G.729). Bei Berücksichtigung des Duplexverkehrs ergeben sich 1260 kByte/min (G.711)
bzw. 378 kByte/min (G.729).
Anbieter
Tarifoption
T-Mobile
T-Mobile
T-Mobile
T-Mobile
T-Mobile
Vodafone
Vodafone
Vodafone
Vodafone
Vodafone
Vodafone
Vodafone
E-Plus
E-Plus
O2
O2
Data 5
Data 30
Data 150
Data für Vertrag
Data für CombiCardTeens
Volume PDA
Volume L
Volume XL
Volume FairFlat
Volume by Call
CallYa GPRS
Zuhause Volume
Free & Easy GPRS
GPRS für Vertrag
Loop GPRS
GPRS für Vertrag
Inkl.
MB
5
30
150
30
200
400
5000
5000
-
Intervall
kByte
10
100
100
10
10
100
100
100
100
10
10
1000
1
1
10
10
Kosten/min
G.711
126 Ct
42 Ct
25,2 Ct
11,34 ¿
23,94 ¿
41,42 Ct
12,42 Ct
10,96 Ct
1,24 Ct
23,94 ¿
36,54 ¿
0,76 Ct
11,34 ¿
7,56 ¿
12,60 ¿
11,68 ¿
Kosten/min
G.729
37,8 Ct
12,6 Ct
7,56 Ct
3,40 ¿
7,18 ¿
124,24 Ct
3,73 Ct
3,29 Ct
0,37 Ct
7,18 ¿
10,96 ¿
0,23 Ct
3,40 ¿
2,27 ¿
3,78 ¿
3,50 ¿
Tabelle 5.3: Angebotene Volumentarife für Datenverkehr
5 Kostenanalyse
85
5.2.2 WLAN-Tarife
Neben den Mobilfunkprovidern bieten auch andere Unternehmen Internetzugänge über
WLAN an. Tabelle 5.4 gibt eine Übersicht über die Unternehmen, die mehr als 100
Hotspots laut [BSP 06] zur Verfügung stellen. WLAN-Tarife sind üblicherweise Zeittarife, die meistens nach dem sogenannten Parkuhrprinzip“ funktionieren. Das bedeutet,
”
dass vom ersten Anmelden an der Zugang für die erworbene Zeitspanne nutzbar ist.
Die Internetseite [BSP 06] listet viele Hotspots mit ihren Betreibern auf. Neben
11.291 kostenpflichtigen Angeboten, finden sich hier auch 344 kostenlose WLAN-Zugänge. Des Weiteren bietet beispielsweise AOL seinen Vertragskunden zusätzlich die Nutzung der AOL-Hotspots ohne weiteres Entgelt an.
Anbieter
Tarif
Inklusiv
Abrechnung
Kosten/min
(Cent)
T-Mobile
HotSpot 180
180 min. 1 min.
5,55
T-Mobile
HotSpot 600
600 min. 1 min.
4,17
T-Mobile
HotSpot 6000
6000 min. 1 min.
1,5
Vodafone
WLAN 30
30 min.
Parkuhr
13,17
Vodafone
WLAN 120
120 min. Parkuhr
8,29
E-Plus
WLAN für Vertrag 30 min.
1 min.
0,12
O2
WLAN für Vertrag 30 min.
Parkuhr
13,17
O2
Voucher 30
30 min.
Parkuhr
16,67
O2
Voucher 120
120 min. Parkuhr
8,33
T-Com
Hotspot Pass 15
15 min.
Parkuhr
13,33
T-Com
Hotspot Pass 60
60 min.
Parkuhr
13,33
T-Com
Hotspot Pass 180
180 min. Parkuhr
7,77
T-Com
Hotspot Pass 24h
1440 min. Parkuhr
1,25
Swisscom Eurospot WLAN 30
30 min.
Parkuhr
15
Swisscom Eurospot WLAN 120
120 min. Parkuhr
7,92
Swisscom Eurospot WLAN 24h
1440 min. Parkuhr
1,70
AOL Europe
Flatrate
4.99 ¿/Monat AOL Europe
WLAN 60
60 min.
Parkuhr
3,33
Kabel Deutschland Flatrate
9.90 ¿/Monat BerlinNet GmbH
WLAN 3h
180 min. Parkuhr
5,5
BerlinNet GmbH
WLAN 5h
300 min. Parkuhr
4,97
BerlinNet GmbH
WLAN 10h
600 min. Parkuhr
4,15
BerlinNet GmbH
Flatrate Woche
180 min. 39 ¿/Woche
BerlinNet GmbH
Flatrate Monat
59 ¿/Monat
Tabelle 5.4: WLAN-Tarife
5 Kostenanalyse
86
5.2.3 WiMAX-Tarife
Der Betrieb eines WiMAX-Netzes bedarf der Genehmigung durch die Bundesnetzagentur, das Vergabeverfahren ist zum jetzigen Zeitpunkt (August 2006) noch nicht abgeschlossen. Trotz dieser Tatsache gibt es in Deutschland bereits drei Unternehmen,
die Funkzugänge kombiniert über WiMAX und WLAN anbieten. Der Frequenzbereich
in dem WiMAX arbeitet, war ursprünglich für die Nutzung der Wireless Local Loop
(WLL) Technologie vorgesehen. Unternehmen, die sich im Besitz von Lizenzen für den
Betrieb von WLL befinden, können über einen Änderungsantrag auch WiMAX nutzen,
bevor das Vergabeverfahren abgeschlossen ist.
Die beiden Unternehmen Deutsche Breitbanddienste GmbH (DBD) [Deut06] und
Televersa Online GmbH [Tele06] bieten verschiedene Flatrates an, die sich durch die
erreichbare Bandbreite unterscheiden. Daneben offeriert die DBD auch Volumentarife,
die in Tabelle 5.5 gelistet sind. Arcor bietet in Kaiserlautern WiMAX-Zugänge für
einen Flatratetarif an [Arco06]. In dieser Betrachtung wird auf die Kosten von FlatrateAngeboten nicht weiter eingegangen, da sie üblicherweise nicht ausschließlich für VoIP
genutzt werden.
Anbieter
Tarif
DBD
DBD
DBD
DBD
DBD
DBD
DSLonair
DSLonair
DSLonair
DSLonair
DSLonair
DSLonair
Inkl.
Basic
Classic
Premium
Business Basic
Business Professional
Business Premium
1500 MB
5000 MB
10 GB
20 GB
20 GB
20 GB
Kosten
Euro
26,94 ¿
34,94 ¿
39,94 ¿
132,18 ¿
277,18 ¿
335,18 ¿
Cent/min
G.711
8,33
0,88
0,50
0,83
1,75
2,11
Cent/min
G.729
0,68
0,26
0,15
0,25
0,52
0,64
Tabelle 5.5: WiMAX-Volumentarife
5.2.4 Vergleich
Bei aktuellen Mobilfunkverträgen fallen Gesprächsgebühren von mindestens 14 Cent
pro Minute an [Bo-M06]. Vor diesem Hintergrund erscheinen einige der angebotenen
Tarife der Mobilfunkunternehmen attraktiv, da sie günstiger sind. Zeittarife allerdings
rechnen häufig in Intervallen von 10 Minuten ab, was den Kostenvorteil bei kurzen
Gesprächen wieder zunichte macht. Die Volumentarife sind meist zu teuer, selbst bei
Verwendung eines niederbitratigen Codecs wie dem G.729 sind nur wenige Tarife für
den durchschnittlichen Endverbraucher günstiger. Für teure Telefonate allerdings (z.B.
5 Kostenanalyse
87
ins Ausland) kann sich ein VoIP-Gespräch über einen Datenzugang bei einem Mobilfunkanbieter lohnen.
Es sind bei Datenzugängen über Mobilfunknetze höhere Latenzzeiten zu erwarten
(siehe Kapitel 3) und dadurch verminderte Sprachqualität. Es ist ungewiss, ob die Anbieter weiterhin VoIP-Verkehr über ihre Datenverbindungen zulassen, Vodafone kündigt an, ab dem 8.7.2007 VoIP-Nutzung technisch zu unterbinden [Voda06].
Die Nutzung von WLAN ist dagegen eine ernstzunehmende Alternative zur Telefonie
über ein Mobilfunknetz, solange ein geeigneter Tarif gewählt wird. Die Nutzung eines
der verbreiteten Parkuhrtarife“ ist denkbar ungeeignet.
”
Auch WiMAX weckt große Erwartungen, vor allem da die Reichweite einer WiMAXStation größer als die eines WLAN-Access Points ist. Es sind allerdings keine Endgeräte
oder Adapter verfügbar.
Abschließend soll auf ein aktuelles Angebot der T-Com eingegangen werden, T-One
[T-Co06]. Das Unternehmen bietet ein Dual-Mode“-Mobiltelefon an, mit dem sich so”
wohl über WLAN als auch über GSM telefonieren lässt. Im Privathaushalt wird damit
drahtlos über einen Festnetzanschluss (der Telekom) oder über einen DSL-Anschluss
(der T-Com) telefoniert. Für den Gebrauch im Mobilfunknetz ist ein Vertrag nötig,
der etwa den gängigen Mobilfunkverträgen entspricht (T-Mobile). Für die Nutzung
an WLAN-Hotspots (T-Com) lässt sich eine Flatrate erwerben. Abgesehen von der
Nutzung am Hotspot, bietet dieses Angebot damit keinerlei Ersparnis.
5.3 Anschaffungskosten
Um drahtlose IP-Telefonie zu ermöglichen, bedarf es eines Funkzugangs, bestehend aus
einem Zugangspunkt und einem (mobilen) Endgerät mit entsprechender Sende- und
Empfangseinheit. Sofern kein Gerät zur Verfügung steht, das bereits ein Funkmodul
integriert hat, wird ein Adapter für die betreffende Technologie benötigt.
Im Falle von WLAN oder Bluetooth ist die eigene Bereitstellung eines Zugangspunktes zum Beispiel in der eigenen Wohnung möglich, der dann beispielsweise über eine
DSL-Leitung an das Internet angeschlossen wird. Für WiMAX und die Mobilfunknetze
stellt ein Betreiber den Zugang bereit, diese Technologien arbeiten in lizensierten Frequenzbändern. Obwohl für WiMAX schon Endgeräte existieren [WiMA06b] und sich
im Einsatz befinden, sind auf dem deutschen Markt noch keine zu erwerben.
Das einfachste geeignete Endgerät wäre ein Laptop, daneben sind noch weitere denkbar, wie beispielsweise PDAs mit VoIP-Funktion, Mobiltelefone, die VoIP unterstützen
oder speziell konstruierte Geräte. Die folgenden Betrachtungen werden sich auf Ge-
5 Kostenanalyse
88
räte zum Anschluss an Laptops und auf für drahtlose IP-Telefonie gebaute Geräte
konzentrieren. Der Frage nachzugehen, inwieweit Smartphones oder PDAs für VoIPTelefonate geeignet sind, sprengt den Rahmen dieser Arbeit.
Zur Ermittlung der Preise der folgenden Abschnitte wurden die Angebote dreier großer Unternehmen verglichen, im Einzelnen sind das die K&M-Elektronik AG
[K&M06], die Mindfactory AG [Mind06] und die computeruniverse.net GmbH [comp06].
5.3.1 Bluetooth
Access Points Auf dem deutschen Markt sind, durch die Dominanz der WLANTechnologie, wenige Bluetooth-Access Points erhältlich. Ein Bluetooth-AP kostet zwischen 30,17 ¿ und 174,95 ¿. Am verbreitetsten sind Geräte von Anycom und D-Link.
Bluetooth-Adapter Das Angebot an Bluetooth-Adaptern auf dem deutschen Markt
ist sehr vielfältig. Der Großteil ist mit einer USB-Schnittstelle versehen, es sind auch
Empfänger im Compact Flash (CF)-Format für den Einsatz in PDAs zu bekommen.
Die Preise für Geräte, die Bluetooth-Spezifikation 1.1 unterstützen, liegen zwischen
26,50 ¿ und 72,90 ¿ mit USB-Anschluss. CF-Adapter kosten zwischen 29 ¿ und 68,90
¿. USB-Adapter für Bluetooth Version 1.2 liegen preislich zwischen 14,79 ¿ und 30,62
¿, für Version 2.0 EDR zwischen 15,79 ¿ und 43,29 ¿. CF-Karten wurden von den
betrachteten Anbietern für diese Versionen nicht angeboten.
5.3.2 WLAN
Access Points Entsprechend der derzeitigen Nachfrage ist das Angebot an WLANAccess Points sehr groß. Nach unterstützter Spezifikation ergab die Auswertung der
Angebote die folgenden Preise. Ein AP, der lediglich IEEE 802.11b unterstützt, kostet
zwischen 45 ¿ und 695 ¿, Varianten, die für 802.11g und 802.11b zertifiziert sind,
liegen preislich zwischen 37 ¿ und 1212 ¿. Access Points, die sowohl im 2,4 GHz Band
als auch im 5 GHz Band arbeiten, also zusätzlich 802.11a unterstützen, sind teurer,
der Preisrahmen bewegt sich zwischen 118 ¿ und 1283 ¿.
Der Großteil der angebotenen Access Points kostet zwischen 40 ¿ und 100 ¿. Höherpreisige Geräte sind meistens für den Einsatz in größeren Netzwerken gedacht und
bieten dafür angepasste Zusatzleistungen oder erlauben höheren Datendurchsatz durch
Verwendung proprietärer Technologien. Beispiele dafür sind der SuperG-Modus, der
von Atheros Chipsätzen unterstützt wird oder MIMO-Verfahren.
5 Kostenanalyse
89
WLAN-Adapter Einen Vergleich der Preise von WLAN-Adaptern mit verschiedenen
Schnittstellen für die verschiedenen WLAN-Standards gibt Tabelle 5.6. Wie bei den
WLAN-Access Points sind Adapter teurer, die höhere Datenraten aufgrund proprietärer Technologien zulassen.
Technologie/
Schnittstelle
802.11abg / PCI
802.11abg / Mini-PCI
802.11abg / USB
802.11abg / PCMCIA
802.11bg / PCI
802.11bg / Mini-PCI
802.11bg / USB
802.11bg / PCMCIA
802.11bg / CF
802.11b / Mini-PCI
802.11b / USB
802.11b / PCMCIA
802.11b / CF
günstigster Preis
Euro
72,00
31,00
52,14
24,86
18,90
24,00
15,99
12,79
90,50
26,90
17,90
16,00
70,00
höchster Preis
Euro
97,50
31,00
98,50
91,00
58,90
29,50
59,00
68,90
90,50
61,50
17,90
52,90
70,00
Tabelle 5.6: Kosten für WLAN-Adapter
5.3.3 Mobilfunk
Für den Datenzugang über ihre Netze bieten die Mobilfunkprovider Steckkarten mit
PCMCIA-Schnittstelle an. Beim Abschluss eines Datenvertrages werden die Geräte
subventioniert für Preise zwischen 0,86 ¿ und 49,95 ¿ je nach Ausstattung abgegeben.
Ohne Vertrag kosten sie zwischen 344,74 ¿und 474,05 ¿.
Neben dem Kauf einer solchen Karte besteht die Möglichkeit, eine Datenverbindung
über ein bereits vorhandenes Mobiltelefon aufzubauen, das dazu an das gewünschte
Endgerät gekoppelt werden muss.
5.3.4 Endgeräte für drahtloses VoIP
Seit kurzem sind auf dem deutschen Markt Geräte erhältlich, die speziell für den Einsatz von drahtloser IP-Telefonie gedacht sind. Es handelt sich dabei ausschließlich um
Telefone, die die Kommunikation über WLAN ermöglichen. Hinzu kommen sogenannte
Dual-Mode“-Telefone, die sowohl VoIP-Gespräche über WLAN erlauben, als auch das
”
Telefonieren über das GSM-Netz.
5 Kostenanalyse
90
Die T-Com bietet mit dem T-One ein solches Gerät an (siehe Abschnitt 5.2.4). Es
ist an einen T-Com-Tarif gebunden, ermöglicht aber die Telefonie über WLAN. Im
privaten Bereich kann die WLAN-Telefonie über einen Access Point und einen DSLAnschluss genutzt werden oder über eine spezielle Basisstation, die das VoIP-Gespräch
für einen Festnetzanschluss umsetzt. Außerhalb des Haushaltes kann über das GSMNetz von T-Mobile telefoniert werden oder über WLAN an einem der Hotspots der
T-Com.
Tabelle 5.7 liefert einen Überblick über die Geräte, die ohne Vertragsbindung erhältlich sind. Die Informationen sind den Webseiten [sipg06], [Mind06], [Noki06] und
[BUG 06] entnommen.
Hersteller
Modell
Technologie
UTStarcom
UTStarcom
Siemens
Zyxel
Netgear
Edgecore
Nokia
Nokia
F3000
F1000G
SL 75
P200Wv2
SPH-101GRS
WM4201
E60
E70
802.11b,g / SIP
802.11b,g / SIP
802.11b,g / SIP
802.11b / SIP
802.11b,g / Skype
802.11b,g / Skype
802.11g / GSM / SIP
802.11g / GSM / SIP
Preis
Euro
199,00
139,00
179,00
168,90
217,01
166,99
449,00
529,00
Anbieter
sipgate
sipgate
sipgate
BUG Computer AG
Mindfactory
Mindfactory
Nokia
Nokia
Tabelle 5.7: WLAN-Telefone
5.4 Zusammenfassung
Wie bereits in Abschnitt 5.2.4 subsummiert, lohnt sich der Einsatz von VoIP aus tariflicher Sicht oft lediglich über WLAN, in Zukunft eventuell auch über WiMAX. Die
Preise der Endgeräte für WLAN sind im Vergleich niedrig, zudem wächst der Markt für
Endgeräte, die speziell für VoWLAN ausgelegt sind, stetig an. Aufgrund der geringeren
Reichweite, keinerlei Angeboten von Zugängen in öffentlichen Räumen und ähnlichen
Gerätepreisen, wird der Bluetooth-Technologie keinerlei Bedeutung zugesprochen.
91
6 Programm zur Auswahl einer
optimalen Technologie
6.1 Einleitung
Die Ergebnisse der vorangehenden Kapitel sollen durch Entwicklung einer Software
praktisch nutzbar gemacht werden. Dieses Kapitel beschreibt zunächst die Anforderungen an das Programm, um dann in den folgenden Abschnitten auf das Programmkonzept und die Umsetzung einzugehen.
6.2 Anforderungen
Das Programm soll für einen Nutzer in einer bestimmten Situation die beste drahtlose
Technologie ermitteln, um VoIP-Gespräche führen zu können. Dazu soll der Benutzer
aus Listen, die ihm zur Verfügung stehenden Funkzugänge und die in Frage kommenden
Tarife auswählen. Im Ergebnis liefert die Software die Technologie, die für den Zugang
des Nutzers am besten geeignet ist.
6.3 Konzept
Um die Anforderungen in ein schlüssiges Programm umzusetzen, sind einige Vorüberlegungen nötig.
Die Wahl einer optimalen Technologie muss sich, wie aus Kapitel 2 und 3 ersichtlich,
primär an den technologieeigenen Parametern orientieren. Der wichtigste ist die Latenzzeit, da sich diese direkt auf die Sprachqualität auswirkt. Zusätzlich muss aber berücksichtigt werden, dass nur eine begrenzte Anzahl an Gesprächen über einen Funkkanal
übertragbar ist und dass sich QoS-Mechanismen positiv auf die Sprachqualität auswirken. Die maximal mögliche Zahl an Gesprächen hängt nicht direkt mit der verfügbaren
Datenrate zusammen (siehe Kapitel 3 und 4), sondern Aspekte der Übertragungsverfahren spielen eine wesentliche Rolle. Die Praxistests in Kapitel 4 haben gezeigt, dass die
92
theoretisch bestimmte maximale Gesprächsanzahl nicht mit den praktischen Ergebnissen übereinstimmt. Als logische Konsequenz ergibt sich die Speicherung der möglichen
Gespräche für jeden verfügbaren Sprachcodec innerhalb des Programmes.
Im Zusammenhang gibt es damit zwei Möglichkeiten für die Auswahl. Zum einen
kann die beste Technologie für den günstigsten verfügbaren Tarif gewählt werden, zum
anderen kann für die beste Technologie nach oben genannten Parametern der günstigste
Tarif ermittelt werden. Das Programm sollte also an dieser Stelle eine Möglichkeit
vorsehen, diese beiden Optionen zu unterscheiden.
6.4 Umsetzung
Das Programm wurde in der Programmiersprache C# unter Zuhilfenahme der Entwicklungsumgebung Microsoft Visual Studio 2005 geschrieben.
6.4.1 Benutzerschnittstelle
Die Benutzerschnittstelle des Programms stellt Abbildung 6.1 dar. Sie ist mittels vier
Registerkarten in Bereiche aufgeteilt, zwischen denen durch Anklicken umgeschaltet
werden kann. Die erste Registerkarte Technologien“ zeigt mögliche Zugangstechnologi”
en an, diese können ausgewählt werden. Die zweite Registerkarte Parameter“ erlaubt
”
das Konfigurieren der Gesprächsparameter, wie Anzahl der gleichzeitig zu führenden
Gespräche, verwendeter Sprachcodec und die Länge der Sprachsamples. Außerdem
kann der Bewegungsradius um den Access Point festgelegt werden, in dem die Telefonate stattfinden sollen und ob die Auswahl der Technologie primär nach Kosten oder
Sprachqualität erfolgen soll (siehe Abschnitt 6.3). Registerkarte Tarife“ zeigt die zu
”
den gewählten Technologien passenden Tarife mit den Kosten an, die bei den gewählten Parametern pro Minute entstehen würden. Werden Tarife ausgewählt und existiert
eine Technologie, die allen gesetzten Parametern gerecht wird, so zeigt die vierte Registerkarte Empfehlung“ das Ergebnis an.
”
6.4.2 Daten
Die Daten mit den entsprechenden Methoden sind in mehrerer Klassen gekapselt, die
kurz erläutert werden sollen.
Gespraech.cs Die Klasse Gespraech enthält die Daten der Sprachcodecs, im einzelnen den Namen des Codecs, die verfügbaren Sprachrahmengrößen und die Paketgröße
93
Abbildung 6.1: Benutzeroberfläche [Eigene Darstellung]
für ein 10 ms Sprachsample. Die wichtigste Methode Datarate gibt die resultierende
Datenrate der auf Registerkarte Parameter“ ausgewählten Eigenschaften zurück. Die
”
Methoden Get codecs() und Codec times() geben jeweils die Namen der implementierten Sprachcodecs und ihre Sprachrahmengrößen zurück.
TechnologieDatum.cs Die Klasse TechnologieDatum fasst die Eigenschaften einer
Technologie zusammen und stellt Methoden für den Zugriff auf die Variablen bereit.
Neben beschreibenden Eigenschaften wie dem Namen und Typ der Technologie sowie der angegebenen Datenrate, enthält diese Klasse auch die für die Technologieauswahl wesentlichen Werte. Dazu gehören die Latenzzeit und die Reichweite eines Access
Points sowie die maximal möglichen Gespräche für jeden Codec und einen Qualitätsindex. Für Erweiterungen des Programmes wäre es sinnvoll, nicht nur die maximale
Gesprächsanzahl zu speichern, sondern auch andere Werte wie Paketrate und Headerkompression oder VAD zu berücksichtigen. Da aber aus dieser Arbeit nur Messwerte für
eine Paketrate von 50 Paketen/s vorliegen, wurde die Erweiterung nicht implementiert.
Der Qualitätsindex soll als Maßstab für implementierte QoS-Verfahren und Störungssicherheit gewertet werden, um Technologien mit gleichen Paketlaufzeiten zu differenzieren. Beispielsweise unterscheiden sich 802.11a und 802.11g nicht durch ihre Latenzzeiten, da aber im 5 GHz Band mehr Kanäle zur Verfügung stehen, die sich nicht
gegenseitig beeinflussen, wurde ein höherer Qualitätsindex gewählt. Zur Auswertung
kann bei einem Objekt des Typs TechnologieDatum der boolean Wert aktiv gesetzt
94
werden.
Die eingetragenen Werte beruhen auf Schätzungen, die aus den Messungen resultieren.
Technologien.cs Technologien verwaltet ein Array von Daten des Typs TechnologieDatum. Neben der Initialisierung stellt es Methoden für den Zugriff auf die einzelnen
Elemente und deren Werte bereit. Die wichtigste Methode GetBestTech() liefert die
nach den Gesichtspunkten Latenzzeit, Qualitätsindex und Datenrate beste Technologie
unter den aktivierten Technologien. Die Auswahl wird dabei auf die Technologietypen
in einer übergebenden Zeichenkette beschränkt. Die Klassen GespraechComparer.cs,
LatencyComparer.cs und QualityComparer.cs stellen dabei Schnittstellen für die Sortierung der Technologien bereit.
TarifDatum.cs Analog zur Klasse TechnologieDatum enthält TarifDatum Eigenschaften und Methoden eines Tarifs. Dazu zählen der Name des Tarifs und das anbietende
Unternehmen, die verwendete Technologie, der Tariftyp, die variablen Kosten und die
Kosten pro Minute. Auch hier kann über einen boolean Wert gesteuert werden, ob der
betreffende Tarif in den Auswertungen zu berücksichtigen ist. Neben Methoden für
den Zugriff auf die einzelnen Variablen ist die entscheidende Methode GetKostmin().
Diese liefert anhand der übergebenen Datenrate die Kosten pro Minute für ein VoIPGespräch zurück und setzt die Variable kost min neu. Die Datenrate als Grundlage
für die Kostenberechnung bei Volumentarifen wird hier um 5% erhöht, um dem anfallenden Signalisierungsverkehr Rechnung zu tragen. Eine überladene Version dieser
Methode gibt das Ergebnis als Zeichenkette zurück.
TarifDaten.cs Ähnlich wie Technologien verwaltet auch TarifDaten ein Array aus
Objekten des Typs TarifDatum. Mittels der Methode lesen können die Tarifdaten aus
der Textdatei (tarife.txt) ausgelesen und das Array initialisiert werden. Die übrigen
Methoden stellen die benötigten Zugriffe auf interne Werte und Objekte zur Verfügung.
6.4.3 Funktionalität
Die Funktion zur Bestimmung der optimalen Technologie ist in der Methode Auswert()
der Klasse Form1 enthalten. In einem ersten Schritt werden alle in Registerkarte Tech”
nologien“ ausgewählte Technologien, die die Anforderungen bezüglich Reichweite und
Gesprächsanzahl von Registerkarte Parameter“ erfüllen, aktiviert.
”
95
Der zweite Schritt besteht darin, die aus der Liste auf Registerkarte Tarife“ ausge”
wählten Tarife in ein Array zu speichern und nach Kosten pro Minute zu sortieren. Die
Kosten entsprechen den gewählten Gesprächsparametern.
Der dritte und letzte Schritt bestimmt die optimale Technologie nach Kosten oder
Sprachqualität, wie auf Registerkarte Parameter“ ausgewählt. Für ein Kostenopti”
mum wird zuerst der billigste Tarif bestimmt, um dann für die Technologien, die für
diesen verfügbar sind, die beste zu ermitteln. Das geschieht mit Hilfe der Methode
GetBestTech() der Klasse Technologien (siehe 6.4.2). Steht die Sprachqualität bei der
Auswahl im Vordergrund, wird zunächst die beste Technologie ermittelt und danach
der günstigste Tarif, der für diese verfügbar ist.
96
VoIP gewinnt durch Kostenvorteile sowohl bei den Nutzern als auch bei den Netzbetreibern zunehmend an Bedeutung. Gleichermaßen besteht der Wunsch nach mobiler
Kommunikation, jederzeit und überall erreichbar zu sein, was an der rasanten Entwicklung des Mobilfunkmarktes abzulesen ist. Dabei geht der Trend weg von reinen
Sprachdiensten hin zu Datendiensten, die beispielsweise Instant Messaging (IM) oder
Videotelefonie erlauben.
Vor diesem Hintergrund hat sich die vorliegende Arbeit zum Ziel gesetzt, die Eignung
von Funkübertragungstechnologien für VoIP zu untersuchen. Damit wären gleichzeitig
die Bedürfnisse nach mobiler und kosteneffizienter Kommunikation erfüllt.
Die untersuchten Technologien wurden unter verschiedenen Gesichtspunkten betrachtet. Im ersten Teil der Arbeit wurden die zugehörigen Standards untersucht, um eine
Aussage über die maximal mögliche Anzahl an gleichzeitigen Gesprächen und den Einfluss auf die Sprachqualität treffen zu können. Die Mobilfunktechnologien sind dabei
schwierig zu beurteilen, da die Standards den Hersteller weite Implementierungsspielräume lassen.
Der zweite Teil überprüfte anhand von Praxistests die Leistungsfähigkeit von Bluetooth und WLAN bezüglich der Übertragung von VoIP-Gesprächen. Nachdem es nicht
möglich war, realen VoIP-Verkehr zu erzeugen, wurden für die Messungen RTP-Ströme
erzeugt, die einem IP-Telefonat entsprechen. Zur Beurteilung wurden die Round-TripTimes, Jitter, Paketverluste und die Datenrate bestimmt für Telefonate mit dem G.711und G.729-Codec. Das benutzte Messverfahren eignet sich, um weitere Technologien
zu untersuchen oder die geschilderten Untersuchungen mit veränderten Parametern
weiterzuführen.
Im dritten Teil wurden die Technologien unter Kostenaspekten betrachtet. Es wurden die Minutenpreise für den Zugang über verschiedene Technologien berechnet. Weiterhin wurden die Kosten zur Anschaffung von Geräten zur Nutzung eines Zugangs
erörtert.
Die Erkenntnisse aus den drei Teilen wurden abschließend in einer Software miteinander verknüpft, deren Aufgabe es ist, unter wählbaren Rahmenbedinungen eine
97
optimale Technologie für VoIP zu empfehlen.
Im Rahmen der Betrachtungen erwies sich dabei WLAN unter den nutzbaren Technologien als die am besten geeignete, sowohl unter technologischen als auch unter
Kostenaspekten.
Aufgrund des rasanten Entwicklung von Funktechnologien kommt man nicht umhin
einen Blick in die Zukunft zu werfen. Die WiMAX-Technologie befindet sich noch in
den Kinderschuhen, ist WLAN aber technisch deutlich überlegen. Die Möglichkeiten
WiMAX mit mobilen Endgeräten zu nutzen sind vorgesehen, nicht ausschließlich als
drahtloses DSL, wie es im Augenblick vermarktet wird. Auf der anderen Seite sehen die
Standards der Mobilfunknetze die Möglichkeit der Erweiterung derselben vor, um die
Angebote mit günstigen Zugängen mit hohen Datenraten zu ergänzen. Hierfür kommen
sowohl WLAN als auch WiMAX in Frage.
Abschließend kann festgehalten werden, dass bei einem sich beständig verändernden Markt das Nutzerverhalten nur schwer abzusehen ist. Die Zukunft der drahtlosen
IP-Telefonie liegt somit nicht zuletzt in den Händen der Anbieter, entwickelnden Unternehmen und Lizenzinhaber.
98
Anhang
99
[3rd 06]
3rd Generation Partnership Project, http://www.3gpp.org. Webseite,
Juni 2006.
[Agil05]
Agilent Technologies, http://www.agilent.com/find/wimax. Agilent
Wimax Frequency and Time Parameter Table, Januar 2005. Abruf am
21.2.2006.
[Arco06]
Arcor AG & Co.KG, http://www.arcor.de/content/presseservice/
presse-mitteilungen/2005/31870047.html. Arcor startet in Kaiserlautern schnelles Internet über Funktechnik, Juni 2006. Abruf am
3.3.2006.
[ARS 06]
ARS Computer und Consulting GmbH, http://www.ars.de/ars/ars.
nsf/docs/netio. NETIO Benchmark, Februar 2006.
[Bada05]
Anatol Badach. Voice over IP - Die Technik. Carl Hanser Verlag München Wien. 2. Auflage, 2005.
[Bo-M06]
Bo-Mobile GmbH, http://www.handytarife.de. Handy Tarifvergleich,
August 2006. Abruf am 4.9.2006.
[BSP 06]
BSP Internet Solutions, http://www.hotspots-in-deutschland.de.
Hotspots Verzeichnis, August 2006. Abruf am 12.8.2006.
[BUG 06]
BUG Computer Components AG, http://www.ebug-europe.com. Webseite, September 2006. Abruf am 4.9.2006.
[Bund06]
Bundesnetzagentur, http://www.bundesnetzagentur.de. Bundesnetzagentur Webseite, Juni 2006.
[Cand06]
Candela Technologies, http://www.candelatech.com. LANForge Fire,
Februar 2006. Abruf am 23.5.2006.
[cfos06]
cfos Software GmbH, http://www.cfos.de. Juli 2006.
100
[ChGo04]
Xiaohua Chen und David J. Goodman. Theoretical Analysis of GPRS
Throughput and Delay. In Proc. IEEE Int. Conference on Communications (ICC), 2004.
[Cisc06]
Cisco Systems Inc., http://www.cisco.com/warp/public/788/voip/
codec_complexity.html#mos. Understanding Codecs, Mai 2006. Abruf
am 14.3.2006.
[Colu06]
Columbia University, http://www.cs.columbia.edu/IRT/software/
rtptools/. RTP Tools - Webseite, Juni 2006.
[comp06]
computeruniverse.net GmbH, http://www.computeruniverse.net.
computeruniverse.net Webseite, September 2006. Abruf am 4.9.2006.
[Deut06]
Deutsche Breitband Dienste GmbH, http://www.dbd-breitband.de.
August 2006. Abruf am 24.8.2006.
[E-Pl06]
E-Plus, http://www.eplus.de. Juni 2006. Abruf am 14.7.2006.
[EMSW02]
Carl Eklund, Roger B. Marks, Kenneth L. Stanwood und Stanley Wang.
IEEE Standard 802.16: A Technical Overview of the WirelessMAN Air Interface for Broadband Wireless Access. IEEE Communications Magazine,
Juni 2002, S. 98–107.
[ETSI00a]
ETSI (Hrsg.). Physical Layer on the radio path; General description.
European Telecommunications Standards Institute, Nr. 8.4.0 Release 99
der Digital cellular telecommunications systeme (Phase 2+), ETSI, Juli
2000.
[ETSI00b]
ETSI (Hrsg.). TS 101 113 Service description; Stage 1. European Telecommunications Standards Institute, Nr. 7.5.0 Release 98 der Digital
cellular telecommunications systeme (Phase 2+);General Packet Radio
Service (GPRS), ETSI, Juli 2000.
[ETSI01a]
ETSI (Hrsg.). TS 101 297 Subnetwork Dependent Convergence Protocol (SNDCP). European Telecommunications Standards Institute, Nr.
8.2.0 Release 99 der Digital cellular telecommunications systeme (Phase 2+);General Packet Radio Service (GPRS), ETSI, September 2001.
[ETSI01b]
ETSI (Hrsg.). TS 101 349 Mobile Station (MS) - Base Station
System (BSS) interface; Radio Link Control/Medium Access Control
101
(RLC/MAC) protocol. European Telecommunications Standards Institute, Nr. 8.9.0 Release 99 der Digital cellular telecommunications systeme
(Phase 2+); General Packet Radio Service (GPRS), ETSI, April 2001.
[ETSI01c]
ETSI (Hrsg.). TS 101 351 Logical Link Control (LLC) layer specification. European Telecommunications Standards Institute, Nr. 8.2.0 Release
99 der Digital cellular telecommunications systeme (Phase 2+);General
Packet Radio Service (GPRS), ETSI, September 2001.
[ETSI02a]
ETSI (Hrsg.). Quality of Service (QoS) concept and architecture. European Telecommunications Standards Institute, Nr. TS 23.107 version 4.6.0 Release 4 der Universal Mobile Telecommunications System
(UMTS), ETSI, Dezember 2002.
[ETSI02b]
ETSI (Hrsg.). TS 101 344 Service description; Stage 2. European Telecommunications Standards Institute, Nr. 7.9.0 Release 98 der Digital
cellular telecommunications systeme (Phase 2+);General Packet Radio
Service (GPRS), ETSI, September 2002.
[ETSI03]
ETSI (Hrsg.). Overview of 3GPP Release 5. European Telecommunications Standards Institute, Universal Mobile Telecommunications System
(UMTS), ETSI, September 2003.
[ETSI04a]
(UMTS), ETSI, Juni 2004.
[ETSI04b]
(UMTS), ETSI, Juni 2004.
[ETSI05a]
ETSI (Hrsg.). Radio interface protocol architecture(3GPP). European
Telecommunications Standards Institute, Nr. TS 25.301 version 5.6.0 Release 5 der Universal Mobile Telecommunications System (UMTS), ETSI,
September 2005.
[ETSI05b]
ETSI (Hrsg.). UTRAN overall description. European Telecommunications Standards Institute, Nr. TS 25.401 version 4.6.0 Release 4 der Universal Mobile Telecommunications System (UMTS), ETSI, Juni 2005.
102
[Euro06]
European Telecommunications Standards Institute, http://www.etsi.
org. ETSI Webseite, September 2006.
[GaKa03]
Sachin Garg und Martin Kappes. An Experimental Study of Throughput
for UDP and VoIP Traffic in IEEE 802.11b Networks. Proceedings of the
IEEE Wireless Communications and Networking Conference, 2003.
[Gast05]
Matthew S. Gast. 802.11 Wireless Networks: The Definitive Guide.
O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472. 2. Auflage, 2005.
[GKCT02]
Sachin Garg, Martin Kappes, Dongyan Chen und Kishor S. Trivedi. Supporting VoIP Traffic in IEEE 802.11 WLAN with Enhanced Medium
Access Control (MAC) for Quality of Service. Tech Report - Avaya Labs,
2002.
[GWAC05]
Arunabha Ghosh, David R. Wolter, Jeffrey G. Andrews und Runhua
Chen. Broadband Wireless Access with WiMax/8O2.16: Current Performance Benchmarks and Future. IEEE Communications Magazine, Februar 2005, S. 129–136.
[Hard03]
William C. Hardy. VoIP service quality : measuring and evaluating packetswitched voice. McGraw-Hill, Two Penn Plaza, New York, NY 10121-2298.
1. Auflage, 2003.
[HePG05]
Olivier Hersent, Jean-Pierre Petit und David Gurle. IP Telephony. John
Wiley and Sons, The Atrium, Southern Gate, Chichester, West Sussex,
PO19 8SQ, England. 1. Auflage, 2005.
[HeRV02]
Matthias Hein, Michael Reisner und Dr. Antje Voß. Voice over IP Sprach-Daten-Konvergenz richtig nutzen. Francis’ Verlag GmbH, 85586
Pöring. 2002.
[Hoen05]
Christian Hoene. Internet Telephony over wireless links. Dissertation,
Technische Universität Berlin, 2005.
[HoTo02]
Harri Holma und Antti Toskala. WCDMA for UMTS. John Wiley &
Sons, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ,
England. 2. Auflage, 2002.
103
[HoTo04]
David P. Hole und Fouad A. Tobagi. Capacity of an IEEE 802.11b Wireless LAN Supporting VoIP. In Proc. IEEE Int. Conference on Communications (ICC), 2004.
[HuBo05]
Pi Huang und A.C. Boucouvalas. Delay Analysis for Bluetooth Baseband
ACL Packets. PG Net 2005 6th Annual PostGraduate Symposium, Juni
2005.
[IEEE99a]
IEEE (Hrsg.). 802.11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications. Institute of Electrical and Electronics Engineers, IEEE Standard for Information technology, IEEE, 1999.
[IEEE99b]
IEEE (Hrsg.). 802.11a: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications - High-speed physical layer in
the 5 GHz Band. Institute of Electrical and Electronics Engineers, IEEE
Standard for Information technology, IEEE, 1999.
[IEEE99c]
IEEE (Hrsg.). 802.11b: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications - Higher Speed Physical Layer
Extension in the 2,4 GHz Band. Institute of Electrical and Electronics
Engineers, IEEE Standard for Information technology, IEEE, 1999.
[IEEE03]
IEEE (Hrsg.). 802.11g: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications - Further Higer Data Rate Extension in the 2,4 GHz Band. Institute of Electrical and Electronics Engineers, IEEE Standard for Information technology, IEEE, 2003.
[IEEE04]
IEEE (Hrsg.). 802.16: Air Interface for Fixed Broadband Wireless Access
Systems. Institute of Electrical and Electronics Engineers, IEEE Standard
for Local and Metropolitan Area Networks, IEEE, 2004.
[IEEE05a]
IEEE (Hrsg.). 802.11e: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications - Medium Access Control
(MAC) Quality of Service Enhancements. Institute of Electrical and
Electronics Engineers, IEEE Standard for Information technology, IEEE,
2005.
[IEEE05b]
IEEE (Hrsg.). 802.15.1: Wireless medium access control (MAC) and
physical layer specifications (PHY) for wireless personal area networks
104
(WPAN). Institute of Electrical and Electronics Engineers, IEEE Standard for Information technology, IEEE, 2005.
[IEEE05c]
IEEE (Hrsg.). 802.16: Air Interface for Fixed Broadband Wireless Access
Systems; Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed Bands. Institute
of Electrical and Electronics Engineers, IEEE Standard for Local and
Metropolitan Area Networks, IEEE, 2005.
[IETF80a]
IETF (Hrsg.). RFC 761: TCP - Transmission Control Protocol. Internet
Engineering Task Force, Network Working Group, Januar 1980. http:
//www.ietf.org/rfc/rfc761.txt.
[IETF80b]
IETF (Hrsg.). RFC 768: UDP - User Datagram Protocol. Internet Engineering Task Force, Network Working Group, August 1980. http:
[IETF81]
IETF (Hrsg.). RFC 791: IP - Internet Protocol. Internet Engineering
Task Force, Network Working Group, September 1981. http://www.
ietf.org/rfc/rfc791.txt.
[IETF99a]
IETF (Hrsg.). RFC 2507: IP Header Compression. Internet Engineering
Task Force, Network Working Group, Februar 1999. http://www.ietf.
org/rfc/rfc2507.txt.
[IETF99b]
IETF (Hrsg.). RFC 2508: Compressing IP/UDP/RTP Headers for LowSpeed Serial Links. Internet Engineering Task Force, Network Working
Group, Februar 1999. http://www.ietf.org/rfc/rfc2508.txt.
[IETF01]
IETF (Hrsg.). RFC 3095: RObust Header Compression (ROHC). Internet
Engineering Task Force, Network Working Group, Juli 2001. http://
www.ietf.org/rfc/rfc3095.txt.
[IETF02a]
IETF (Hrsg.). RFC 3261: SIP - Session Initiation Protocol. Internet
Engineering Task Force, Network Working Group, Juni 2002. http://
www.ietf.org/rfc/rfc3261.txt.
[IETF02b]
IETF (Hrsg.). RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). Internet Engineering Task Force, Network
Working Group, Juni 2002. http://www.ietf.org/rfc/rfc3262.txt.
105
[IETF02c]
IETF (Hrsg.). RFC 3263: Session Initiation Protocol (SIP): Locating SIP
Servers. Internet Engineering Task Force, Network Working Group, Juni
2002. http://www.ietf.org/rfc/rfc3263.txt.
[IETF02d]
IETF (Hrsg.). RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP). Internet Engineering Task Force, Network Working Group, Juni 2002. http://www.ietf.org/rfc/rfc3264.txt.
[IETF02e]
IETF (Hrsg.). RFC 3266: Support for IPv6 in Session Description Protocol (SDP). Internet Engineering Task Force, Network Working Group,
Juni 2002. http://www.ietf.org/rfc/rfc3266.txt.
[IETF03a]
IETF (Hrsg.). RFC 3545: Enhanced Compressed RTP (CRTP) for Links
with High Delay, Packet Loss and Reordering. Internet Engineering Task
Force, Network Working Group, Juli 2003. http://www.ietf.org/rfc/
rfc3545.txt.
[IETF03b]
IETF (Hrsg.). RFC 3550: RTP: A Transport Protocol for Real-Time
Applications. Internet Engineering Task Force, Network Working Group,
Juli 2003. http://www.ietf.org/rfc/rfc3550.txt.
[IETF03c]
IETF (Hrsg.). RFC 3611: RTP Control Protocol Extended Reports (RTCP XR). Internet Engineering Task Force, Network Working Group, November 2003. http://www.ietf.org/rfc/rfc3611.txt.
[IETF04]
IETF (Hrsg.). RFC 3951: Internet Low Bit Rate Codec (iLBC). Internet
Engineering Task Force, Network Working Group, Dezember 2004. http:
[ITU-88]
ITU-T (Hrsg.). Recommendation G.711 - Pulse Code Modulation (PCM)
of voice frequencies. International Telecommunication Union, General
aspects of digital transmission systems, November 1988.
[ITU-90]
ITU-T (Hrsg.). Recommendation G.726 - 40,32,24,16 kbit/s Adaptive
differential pulse code modulation (ADPCM). International Telecommunication Union, General aspects of digital transmission systems; Terminal
equipment, Dezember 1990.
[ITU-96a]
ITU-T (Hrsg.). Recommendation G.723.1 - Dual rate speech coder for
multimedia communications transmitting at 5.3 and 6.3 kbit/s. Interna-
106
tional Telecommunication Union, General aspects of digital transmission
systems, März 1996.
[ITU-96b]
ITU-T (Hrsg.).
Recommendation G.729 - Coding of speech at 8
kbit/s using conjugate-structure algebraic-code-excited-linear-prediction
(CS-ACELP). International Telecommunication Union, Transmission Systems and Media, Digital Systems and Networks, März 1996.
[ITU-96c]
ITU-T (Hrsg.). Recommendation P.800 - Methods for subjective determination of transmission quality. International Telecommunication Union,
Telephone Transmission Quality, August 1996.
[ITU-99]
ITU-T (Hrsg.). Recommendation G.1701 - Framework for IMT-2000
networks. International Telecommunication Union, Transmission systems
and media, digital systems and networks, März 1999.
[ITU-01a]
ITU-T (Hrsg.). Recommendation G.1010 - End-user multimedia QoS categories. International Telecommunication Union, Transmission systems
and media, digital systems and networks, November 2001.
[ITU-01b]
ITU-T (Hrsg.). Recommendation G.113 - Transmission impairments due
to speech processing. International Telecommunication Union, Transmission systems and media, digital systems and networks, Februar 2001.
[ITU-01c]
ITU-T (Hrsg.). Recommendation P.862 - Perceptual evaluation of speech
quality (PESQ), an objective method for end-to-end speech quality assessment of narrow band telephone networks and speech codecs. International Telecommunication Union, Telephone Transmission Quality, Februar
2001.
[ITU-03a]
ITU-T (Hrsg.). Recommendation G.114 - One-Way transmission time.
International Telecommunication Union, Transmission systems and media, digital systems and networks, Mai 2003.
[ITU-03b]
ITU-T (Hrsg.). Recommendation H.323 - Packet-based multimedia communications systems. International Telecommunication Union, Audiovisual and multimedia systems, Juli 2003.
[ITU-05]
ITU-T (Hrsg.). Recommendation G.107 - The E-model, a computational
model for use in transmission planning. International Telecommunication
107
Union, Transmission Systems and Media, Digital Systems and Networks,
März 2005.
[IVT 06]
IVT Corporation, http://www.ivtcorporation.com/products/ctp/
index.php. IVT CTP-GSM Phone 0100, September 2006. Abruf am
14.6.2006.
[KALN+ 05] Heikki Kaaranen, Ari Ahtiainen, Lauri Laitinen, Siamäk Naghian und
Valtteri Niemi. UMTS Networks - Architecture, Mobility and Services.
John Wiley and Sons, Inc.,111 River Street, Hoboken, NJ 07030, USA.
2. Auflage, 2005.
[KCLG02]
Rohit Kapoor, Ling-Jyh Chen, Yeng-Zhong Lee und Mario Gerla. Bluetooth: Carrying voice over ACL Links. Mobile and Wireless Communications Networks (MWCN), September 2002.
[K&M06]
K&M Elektronik AG, http://www.kmelektronik.de. KM Elektronik
Webseite, September 2006. Abruf 4.9.2006.
[MCHK+ 03] Stefan Mangold, Sunghyun Choi, Guido R. Hiertz, Ole Klein und Bernhard Walke. Analysis of IEEE 802.11e for QoS Support in Wireless LANs.
IEEE Wireless Communications, Dezember 2003.
[Mind06]
Mindfactory AG, http://www.mindfactory.de. September 2006. Abruf
am 4.9.2006.
[Möll00]
Sebastian Möller. Assessment and Prediction of Speech Quality in Telecommunications. Kluwer Academic Publishers, P.O.Box 17, 3300 AA
Dordrecht, The Netherlands. 2000.
[Morr02]
Robert Morrow. Bluetooth - operation and use. Professional. McGrawHill, Two Penn Plaza, New York, NY 10121-2298. 1. Auflage, 2002.
[Mull01]
Nathan J. Muller. Bluetooth. Mobile Media. MITP-Verlag GmbH, Bonn.
1. Auflage, 2001.
[Noki06]
Nokia GmbH, http://www.nokia.de. Nokia Deutschland Webseite, September 2006. Abruf 4.9.2006.
[Nune04]
Victor Nunes. VoIP quality aspects in 802.11b Networks. Diplomarbeit,
Royal Institute of Technology, Stockholm, Sweden, 2004.
108
[O2 G06]
O2 Germany, http://www.o2-online.de.
14.7.2006.
Juni 2006.
Abruf am
[Ohrt05]
Frank Ohrtman. WiMAX Handbook - Building 802.16 Wireless Networks. McGraw-Hill Communications. McGraw-Hill, New York. 1. Auflage, 2005.
[O’Sh04]
Dan O’Shea. Why Wimax will rule.
http://www.telephonyonline.com.
[Rech04]
Jörg Rech. Wireless LANs. Heise Zeitschriften Verlag GmbH & Co. KG,
Hannover. 1. Auflage, 2004.
[RäTo05]
Anssi Rämö und Henri Toukomaa. On comparing speech quality of various narrow- and wideband speech codecs. Proceedings of the Eigth International Symposium on Signal Processing and Its Applications Band 2,
August 2005, S. 603–606.
[Saut04]
Martin Sauter. Grundkurs Mobile Kommunikationssysteme. Friedr. Vieweg und Sohn Verlag/GWV Fachverlage GmbH, Wiesbaden. 1. Auflage,
2004.
[Schi03]
Andreas Schieder. Echtzeitdienste in paketvermittelten Mobilfunknetzen. Dissertation, Rheinisch-Westfälische Technische Hochschule Aachen,
2003.
[Seve04]
Juan Carlos Martin Severiano. IEEE 802.11b MAC Layer’s influence on
VoIP quality parameters. Diplomarbeit, Royal Institute of Technology,
Stockholm, Sweden, 2004.
[SIG01]
Bluetooth SIG (Hrsg.). Cordless Telephony Profile. Bluetooth SIG, Februar 2001. http://www.bluetooth.com.
[SIG03a]
Bluetooth SIG (Hrsg.). Bluetooth Network Encapsulation Protocol
(BNEP) Specification. Bluetooth SIG, Februar 2003. http://www.
bluetooth.com.
[SIG03b]
Bluetooth SIG (Hrsg.). Personal Area Networking Profile. Bluetooth SIG,
Februar 2003. http://www.bluetooth.com.
[SIG04]
Bluetooth SIG (Hrsg.). Specification of the Bluetooth System. Bluetooth
SIG, November 2004. http://www.bluetooth.com.
Telephony, Mai 2004, S. 4–9.
109
[SIG06]
Bluetooth SIG (Hrsg.). Specification of the Bluetooth System - Host
Controller Interface. Bluetooth SIG, Nr. 4, Januar 2006. http://www.
bluetooth.com.
[Sind06]
Sindre Helleseth, http://www.bandwidthmonitorpro.com. Bandwidth
Monitor Pro, Juni 2006.
[sipg06]
sipgate / indigo networks GmbH, http://www.sipgate.de. September
2006. Abruf am 4.9.2006.
[Skyp06]
Skype Limited, http://about.skype.com/2006/04/.
100 million users, April 2006. Abruf am 8.9.2006.
[Sour06]
Sourceforge, http://sipp.sourceforge.net. SIPp, Februar 2006.
[Stuc03]
Peter Stuckmann. The GSM evolution: mobile packet data services. John
Wiley & Sons, The Atrium, Southern Gate, Chichester, West Sussex,
PO19 8SQ, England. 2003.
[T-Co06]
T-Com, http://www.t-one.de. T-One, September 2006. Abruf am
6.9.2006.
[T-Mo06]
T-Mobile, http://www.t-mobile.de. Juni 2006. Abruf am 14.7.2006.
[TaBo02]
Manfred Taferner und Ernst Bonek. Wireless Internet Access over GSM
and UMTS. Springer-Verlag, Berlin. 2002.
[Tekt06]
Tektronix, Inc., http://www.tek.com/site/ps/2F-15356/pdfs/2FW_
15356.pdf. K1297-G20 Protocol Tester, September 2006. Abruf am
3.9.2006.
[Tele06]
Televersa GmbH, http://www.televersa.com. August 2006. Abruf am
24.8.2006.
[TrWe05]
Ulrich Trick und Frank Weber. SIP, TCP/IP und Telekommunikationsnetze. Oldenbourg Wissenschaftsverlag GmbH, München. 2005.
[Univ06]
Universita’ degli Studi di Napoli, http://www.grid.unina.it/
software/ITG. D-ITG, Distributed Internet Traffic Generator, Mai
2006. Abruf am 12.4.2006.
[Voda06]
Vodafone, http://www.vodafone.de. Juni 2006. Abruf am 14.7.2006.
Skype achieves
110
[WaAS02]
Bernhard Walke, Marc Peter Althoff und Peter Seidenberg. UMTS - Ein
Kurs. J. Schlembach Fachverlag, Weil der Stadt. 2. Auflage, 2002.
[Wiet05]
Sven Wiethoelter. Virtual Utilization and VoIP Capacity of WLANs Supporting a Mix of Data Rates. Technischer Bericht, Technical University
Berlin, September 2005.
[Wima05]
Wimax Forum. Fixed, nomadic, portable and mobile applications for
802.16-2004 and 802.16e WiMAX networks, November 2005.
[Wima06a]
Wimax Forum, http://www.wimaxforum.org. Mobile WiMAX - Part I:
A Technical Overview and Performance Evaluation, Juni 2006.
[WiMA06b] WiMAX Forum, http://www.wimaxforum.org. WiMAX Forum Webseite, Juni 2006. Abruf am 3.8.2006.
[WiMA06c] WiMAX News, http://www.wimaxxed.com/wimaxxed_news/20060516/
altera_and_sequ.html. Wimaxxed, Mai 2006. Abruf am 24.5.2006.
[Wire06]
Wireshark, http://www.wireshark.org. Juni 2006.
111
2.1
2.2
2.3
2.4
2.5
VoIP-Gespräch . . . . .
VoIP-Sprachdatenstrom
Verwendete Protokolle in
RTP-Header . . . . . . .
SIP-Dialog . . . . . . . .
. . . . .
. . . . .
Relation
. . . . .
. . . . .
. . . . . . . . . . .
. . . . . . . . . . .
zum ISO/OSI- und
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
DARPA-Modell
. . . . . . . . . .
. . . . . . . . . .
4
4
11
13
17
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
Bluetooth Protokollstack . . . . . . . .
ACL-Rahmen . . . . . . . . . . . . . .
WLAN-Stack . . . . . . . . . . . . . .
Zugriffsperioden für den WLAN-Kanal
Zeitabstände DCF-PCF . . . . . . . .
GPRS-Komponenten . . . . . . . . . .
GPRS-Protokollstack . . . . . . . . . .
GPRS-Multiframestruktur . . . . . . .
UMTS-Netzstruktur . . . . . . . . . .
UTRAN-Struktur . . . . . . . . . . . .
UTRAN-Protokollarchitektur . . . . .
UMTS-Dienstearchitektur . . . . . . .
UMTS-Protokollstack . . . . . . . . . .
Transport von IP-Daten . . . . . . . .
802.16-Referenz-Modell . . . . . . . . .
WiMAX OFDM-TDD-Frame . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
30
34
35
36
45
46
47
54
56
57
59
59
60
63
65
4.1
Aufbau der Messumgebung . . . . . . . . . . . . . . . . . . . . . . . . .
72
6.1
Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
112
Tabellenverzeichnis
2.1
2.2
2.3
Mean Opinion Score . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht Sprachcodecs . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.114 - Verzögerung und Sprachqualität . . . . . . . . . . . . . . . . .
5
11
20
3.1
3.2
3.3
3.4
3.5
3.6
27
28
32
35
37
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
Bluetooth-Leistungsklassen . . . . . . . . . . . . . . . . . . . . . . . . .
Symmetrische ACL-Verbindungen . . . . . . . . . . . . . . . . . . . . .
IEEE WLAN-Standards . . . . . . . . . . . . . . . . . . . . . . . . . .
OFDM-Datenraten für WLAN . . . . . . . . . . . . . . . . . . . . . . .
WLAN-Zeitkonstanten . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dauer der Elemente bei Transmission über WLAN 802.11b und 802.11g
mixed mode (802.11bg) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dauer der Elemente bei Transmission über WLAN 802.11a/g . . . . . .
Maximal mögliche Datenraten für den Transport von Audiodaten über
WLAN 802.11b, 802.11bg mixed mode und 802.11a/g . . . . . . . . . .
Maximale Gesprächsanzahl WLAN . . . . . . . . . . . . . . . . . . . .
Übersicht GSM-basierende Technologien . . . . . . . . . . . . . . . . .
Codierschemata bei GPRS . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS - Größe der RLC-Blöcke . . . . . . . . . . . . . . . . . . . . . .
EGPRS-Codierschemata . . . . . . . . . . . . . . . . . . . . . . . . . .
Spreizcodes und resultierende Datenraten . . . . . . . . . . . . . . . . .
Kerndaten WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Varianten der PHY-Layer in 802.16d . . . . . . . . . . . . . . . . . . .
OFDM-Datenraten WiMAX . . . . . . . . . . . . . . . . . . . . . . . .
4.1
4.2
4.3
4.4
4.5
Kombinationen von Positionen und Technologien
RTT in ms mittels hrPING . . . . . . . . . . . .
RTP-Ströme: RTT in ms . . . . . . . . . . . . . .
RTP-Ströme Laptop-Server: Jitter in ms . . . . .
RTP-Ströme am Laptop ankommend: Jitter in ms
73
78
79
80
80
3.7
3.8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
42
42
43
44
48
50
51
56
62
64
64
Tabellenverzeichnis
113
4.6
4.7
Paketverluste in % für den Paketstrom Laptop-Server . . . . . . . . . .
Paketverluste in % für den Paketstrom Server-Laptop . . . . . . . . . .
81
81
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Angebotene Technologien der Mobilfunkprovider
Angebotene Zeittarife für Datenverkehr . . . . .
Angebotene Volumentarife für Datenverkehr . .
WLAN-Tarife . . . . . . . . . . . . . . . . . . .
WiMAX-Volumentarife . . . . . . . . . . . . . .
Kosten für WLAN-Adapter . . . . . . . . . . .
WLAN-Telefone . . . . . . . . . . . . . . . . . .
83
84
84
85
86
89
90
in Deutschland
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
Abkürzungsverzeichnis und
Formelzeichen
3GPP . . . . . . . . . . . . . .
8PSK . . . . . . . . . . . . . .
AAS . . . . . . . . . . . . . . .
AC . . . . . . . . . . . . . . . . .
ACL . . . . . . . . . . . . . . .
ADPCM . . . . . . . . . . .
AES . . . . . . . . . . . . . . .
AFH . . . . . . . . . . . . . . .
AIFS . . . . . . . . . . . . . . .
AMC . . . . . . . . . . . . . . .
AMR . . . . . . . . . . . . . . .
AP . . . . . . . . . . . . . . . . .
ARQ . . . . . . . . . . . . . . .
ATM . . . . . . . . . . . . . . .
BCS . . . . . . . . . . . . . . .
BNEP . . . . . . . . . . . . . .
BPSK . . . . . . . . . . . . . .
BS . . . . . . . . . . . . . . . . .
BSC . . . . . . . . . . . . . . .
BSS . . . . . . . . . . . . . . . .
BSSGP . . . . . . . . . . . . .
BTS . . . . . . . . . . . . . . .
CCK . . . . . . . . . . . . . . .
CDMA . . . . . . . . . . . . .
CELP . . . . . . . . . . . . . .
CFP . . . . . . . . . . . . . . .
CN . . . . . . . . . . . . . . . . .
3rd Generation Partnership Project
8 PSK
Adaptive Antenna System
Access Category
Asynchronous Connection-Less
Adaptive Differential Pulse Code Modulation
Advanced Encryption Standard
Adaptive Frequency Hopping
Arbitration Interf rame Space
Adaptive Modulation and Coding
Advanced Multirate Coder
Access Point
Automatic Repeat Request
Asynchronous Transfer Mode
Block Check Sequence
Bluetooth Network Encapsulation Protocol
Binary Phase Shift Keying
Base Station
Base Station Controller
Base Station Subsystem
BSS GPRS Application Protocol
Base Transceiver Station
Complementary Code Keying
Code Division Multiple Access
Code-book Excited Linear Predictive Coding
Contention Free Period
Core Network
CNG . . . . . . . . . . . . . . .
CP . . . . . . . . . . . . . . . . .
CPS . . . . . . . . . . . . . . . .
CRC . . . . . . . . . . . . . . .
cRTP . . . . . . . . . . . . . .
CS . . . . . . . . . . . . . . . . .
CSMA/CD . . . . . . . . .
CSRC . . . . . . . . . . . . . .
CTP . . . . . . . . . . . . . . .
CW . . . . . . . . . . . . . . . .
DARPA . . . . . . . . . . . .
DBPSK . . . . . . . . . . . .
DCF . . . . . . . . . . . . . . .
DCH . . . . . . . . . . . . . . .
DECT . . . . . . . . . . . . .
DIFS . . . . . . . . . . . . . . .
DQPSK . . . . . . . . . . . .
DSCH . . . . . . . . . . . . . .
DSSS . . . . . . . . . . . . . .
DTMF . . . . . . . . . . . . .
DTX . . . . . . . . . . . . . . .
ECRTP . . . . . . . . . . . .
EDCF . . . . . . . . . . . . . .
EDGE . . . . . . . . . . . . .
EDR . . . . . . . . . . . . . . .
EIFS . . . . . . . . . . . . . . .
EIRP . . . . . . . . . . . . . .
eSCO . . . . . . . . . . . . . .
ETSI . . . . . . . . . . . . . . .
FCH . . . . . . . . . . . . . . .
FDD . . . . . . . . . . . . . . .
FEC . . . . . . . . . . . . . . .
FEC . . . . . . . . . . . . . . .
FFT . . . . . . . . . . . . . . .
FHSS . . . . . . . . . . . . . .
GAP . . . . . . . . . . . . . . .
115
Comfort Noise Generation
Contention Period
Common Part Sublayer
Cyclic Redundancy Check
compressed RTP
Circuit Switched
Carrier Sense Multiple Access with Collision Detection
Contributing Source (RTP)
Cordless Telephony Profile
Contention Window
Defense Advanced Research Projects Agency
Differential Binary PSK
Distribution Coordination Function
Dedicated Channel
Digital Enhanced Cordless Telecommunications
Distribution Interf rame Space
Differential Qarternary PSK
Download Shared Channel
Direct Sequence Spread Spectrum
Dual-Tone Multi-Frequency
Discontinous Transmission
Enhanced cRTP
Enhanced DCF
Enhanced Data Rates for GSM Evolution
Enhanced Data Rates
Extended Interf rame Space
Equivalent Isotropic Radiation Power
enhanced SCO
European Telecommunications Standardization Iinstitute
Frame Control Header
Frequency Division Duplex
Forward Error Correction
Forward Error Correction
Fast Fourier Transform
Frequency Hopping Spread Spectrum
Generic Access Profile
GC . . . . . . . . . . . . . . . . .
GERAN . . . . . . . . . . . .
GFSK . . . . . . . . . . . . . .
GGSN . . . . . . . . . . . . .
GPRS . . . . . . . . . . . . . .
GSM . . . . . . . . . . . . . . .
GTP . . . . . . . . . . . . . . .
HC . . . . . . . . . . . . . . . . .
HCF . . . . . . . . . . . . . . .
HCI . . . . . . . . . . . . . . . .
HFP . . . . . . . . . . . . . . .
HSCSD . . . . . . . . . . . .
HSDPA . . . . . . . . . . . .
IAX . . . . . . . . . . . . . . . .
IEEE . . . . . . . . . . . . . . .
IFS . . . . . . . . . . . . . . . .
iLBC . . . . . . . . . . . . . . .
IMS . . . . . . . . . . . . . . . .
IP . . . . . . . . . . . . . . . . . .
IPX . . . . . . . . . . . . . . . .
ISDN . . . . . . . . . . . . . .
ISM . . . . . . . . . . . . . . . .
ITU . . . . . . . . . . . . . . . .
L2CAP . . . . . . . . . . . . .
LAN . . . . . . . . . . . . . . .
LOS . . . . . . . . . . . . . . . .
LPC . . . . . . . . . . . . . . .
MAC . . . . . . . . . . . . . . .
MAN . . . . . . . . . . . . . .
MGCP . . . . . . . . . . . . .
MIMO . . . . . . . . . . . . .
MOS . . . . . . . . . . . . . . .
MS . . . . . . . . . . . . . . . . .
MSC . . . . . . . . . . . . . . .
MT . . . . . . . . . . . . . . . .
NAV . . . . . . . . . . . . . . .
116
Gateway Controller (H.323)
GSM EDGE Radio Access Network
Gaussian Frequency Shift Keying
Gateway GPRS Support Node
General Packet Radio Service
Global System for Mobile Communications
GPRS Tunneling Protocol
Hybrid Controller
Hybrid Coordination Function
Host Controller Interface
Hands-f ree Profile
High-Speed Circuit Switched Data
High-Speed Downlink Packet Access
Inter-Asterisk Exchange
Institute of Electrical and Electronics Engineers
Interf rame Space
internet Low Bitrate Codec
IP Multimedia Subsystem
Internet Protocol
Internetwork Packet Exchange
Integrated Services Digital Network
Industrial Medical Scientific
International Telecommunications Union
Logical Link Control and Adaption Protocol
Local Area Network
Line of Sight
Linear-Prediction Coding
Medium Access Control
Metropolitan Area Network
Media Gateway Control Protocol
Multiple In Multiple Out
Mean Opinion Score
Mobile Station
Mobile Switching Center
Mobile Termination
Network Allocation Vector
NTP . . . . . . . . . . . . . . .
OFDM . . . . . . . . . . . . .
P2M . . . . . . . . . . . . . . .
P2P . . . . . . . . . . . . . . . .
PACCH . . . . . . . . . . . .
PAGCH . . . . . . . . . . . .
PAN . . . . . . . . . . . . . . .
PC . . . . . . . . . . . . . . . . .
PC . . . . . . . . . . . . . . . . .
PCCCH . . . . . . . . . . . .
PCF . . . . . . . . . . . . . . .
PCM . . . . . . . . . . . . . . .
PDA . . . . . . . . . . . . . . .
PDCH . . . . . . . . . . . . .
PDCP . . . . . . . . . . . . . .
PDP . . . . . . . . . . . . . . .
PDTCH . . . . . . . . . . . .
PDU . . . . . . . . . . . . . . .
PESQ . . . . . . . . . . . . . .
PHS . . . . . . . . . . . . . . .
PIFS . . . . . . . . . . . . . . .
PLC . . . . . . . . . . . . . . .
PLCP . . . . . . . . . . . . . .
PRACH . . . . . . . . . . . .
PS . . . . . . . . . . . . . . . . .
PSK . . . . . . . . . . . . . . .
PSTN . . . . . . . . . . . . . .
QAM . . . . . . . . . . . . . .
QBSS . . . . . . . . . . . . . .
QoS . . . . . . . . . . . . . . . .
RAN . . . . . . . . . . . . . . .
RFCOMM . . . . . . . . .
RLC . . . . . . . . . . . . . . .
RNC . . . . . . . . . . . . . . .
RNS . . . . . . . . . . . . . . .
ROHC . . . . . . . . . . . . .
117
Network Time Protocol
Orthogonal Frequency Division Multiplexing
Point to Multipoint
Point to Point
Packet Associated Control Channel
Packet Access Grant Channel
Personal Area Network
Personal Computer
Point Coordinator
Packet Common Control Channel
Point Coordination Function
Pulse Code Modulation
Personal Digital Assistant
Packet Data Channel
Packet Data Convergence Protocol
Packet Data Protocol
Packet Data Traffic Channel
Protocol Data Unit
Perceptual Evalutation of Speech Quality
Packet Header Suppression
Point Interf rame Space
Packet Loss Concealment
Physical Layer Convergence Protocol
Packet Random Access Channel
Packet Switched
Phase Shift Keying
Public Switched Telephone Network
Quadrature Amplitude Modulation
QoS BSS
Quality of Service
Radio Access Network
Radio Frequency COMport Emulation
Radio Link Control
Radio Network Controller
Radio Network Subsystem
Robust Header Compression
RPE-LTP . . . . . . . . . .
RRC . . . . . . . . . . . . . . .
RTCP . . . . . . . . . . . . . .
RTCP XR . . . . . . . . . .
RTP . . . . . . . . . . . . . . .
RTS/CTS . . . . . . . . . .
RTT . . . . . . . . . . . . . . .
SC . . . . . . . . . . . . . . . . .
SCCP . . . . . . . . . . . . . .
SCO . . . . . . . . . . . . . . .
SD . . . . . . . . . . . . . . . . .
SDMA . . . . . . . . . . . . .
SDP . . . . . . . . . . . . . . .
SDP . . . . . . . . . . . . . . .
SDU . . . . . . . . . . . . . . .
SGSN . . . . . . . . . . . . . .
SIFS . . . . . . . . . . . . . . .
SIG . . . . . . . . . . . . . . . .
SIP . . . . . . . . . . . . . . . .
SIR . . . . . . . . . . . . . . . .
SMG . . . . . . . . . . . . . . .
SNAP . . . . . . . . . . . . . .
SNDCP . . . . . . . . . . . .
SSRC . . . . . . . . . . . . . .
TBF . . . . . . . . . . . . . . .
TC . . . . . . . . . . . . . . . . .
TCP . . . . . . . . . . . . . . .
TDD . . . . . . . . . . . . . . .
TDMA . . . . . . . . . . . . .
TE . . . . . . . . . . . . . . . . .
TFI . . . . . . . . . . . . . . . .
TLLI . . . . . . . . . . . . . . .
ToS . . . . . . . . . . . . . . . .
TTI . . . . . . . . . . . . . . . .
TXOP . . . . . . . . . . . . .
UA . . . . . . . . . . . . . . . . .
118
Regular Pulse Excitation - Long Term Prediction
Radio Resource Control
Real-time Transfer Control Protocol
RTCP Extended Reports
Realtime Transfer Protocol
Ready to Send / Clear to Send
Round Trip Time
Single Carrier
Skinny Client Control Protocol
Synchronous Connection Orientated
Secure Digital
Space Division Multiple Access
Service Discovery Protocol
Session Description Protocol
Service Data Unit
Serving GPRS Support Node
Short Interf rame Space
Special Interest Group
Session Initiation Protocol
Signal to Interference Ratio
Special Mobile Group
SubNetwork Access Protocol
Service Network Dependent Convergence Protocol
Synchronization Source (RTP)
Temporary Block Flow
Traffic Category
Transmission Control Protocol
Time Division Duplex
Time Division Multiple Access
Terminal Equipment
Temporary Flow Identity
Temporary Logical Link Identifier
Type of Service
Transmission Time Interval
Transmission Opportunity
User Asynchronous
UART . . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . .
UE . . . . . . . . . . . . . . . . .
UI . . . . . . . . . . . . . . . . .
UMTS . . . . . . . . . . . . .
URI . . . . . . . . . . . . . . . .
USB . . . . . . . . . . . . . . .
USF . . . . . . . . . . . . . . . .
UTRAN . . . . . . . . . . . .
VAD . . . . . . . . . . . . . . .
VoATM . . . . . . . . . . . .
VoFR . . . . . . . . . . . . . .
VoIP . . . . . . . . . . . . . . .
VSELP . . . . . . . . . . . . .
WAN . . . . . . . . . . . . . .
WLAN . . . . . . . . . . . . .
WPAN . . . . . . . . . . . . .
119
Universal Asynchronous Receiver and Transmitter
User Datagram Protocol
User Equipment
User Isynchronous
Universal Mobile Telecommunications System
Uniform Ressource Identifier
Universal Serial Bus
Uplink State Flag
UMTS Terrestial RAN
Voice Activity Detection
Voice over ATM
Voice over FrameRelay
Voice-over-IP
Vector Sum-exited Linear Prediction
Wide Area Network
Wireless LAN
Wireless Personal Area Network
DVD-Verzeichnis
120
DVD-Verzeichnis
Verzeichnis
\Arbeit
Diplomarbeit im Pdf-Format
\Messungen
Dateien der Messungen
\Messungen\Auswertskripte
Skripte für die Auswertung der Messungen
\Messungen\Auswertskripte\Konvertierung
Skripte für die Konvertierung der Rohdaten
\Messungen\Auswertskripte\Matlab
Skripte für die Auswertung der konvertierten Daten
\Messungen\Auswertungen
Excel-Dateien der Messauswertung
\Messungen\Daten
Rohdaten und konvertierte Daten der Messungen
\Messungen\Messskripte
Skripte zur automatisierten Messung
\Messungen\Messskripte\Batchdateien
Skripte zur automatisierten Messung - Batchdateien
\Messungen\Messskripte\RTP Konfigurationsdateien
Konfigurationsdateien für rtpsend
\Programm\Wireless Decision Support
Quelldateien der Software
\Programm\Wireless Decision Support\Microsoft .NET 2.0 Runtime
Microsoft .NET 2.0 Laufzeitumgebung
\Programm\Wireless Decision Support\Wireless Decision Support\bin\Debug
Ausführbare Version (Voraussetzung Microsoft .NET 2.0 Laufzeitumgebung ist installiert)
Erklärung
121
Erklärung
Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten
Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen
noch nicht vorgelegt worden.
Ilmenau, den 10. 09. 2006
Eckhart Helmuth Wittstock

Technische Universität Ilmenau Fakultät für

Transcrição

Documentos relacionados

Beitrittserklärung - FK Hansa Wittstock

Fretzdorf 05.cdr

TSV Uetersen FC Dossow Hansa Wittstock S

Neue gamona Netzwerkseite zu RF Online

Heydt 1 Berlin Tiergarten

Die drei Blockaden - Saskia Anders

Richtlinie für das Verfassen von Industrie

Tourenplan zum Ausdrucken

aber nicht unsere HÃ¤user Gucci Schuhe Herren

Erster Lauf zur Waldeck-Frankenberger Laufcup