Post on 18-Sep-2018
Implementierung und Optimierungeines Token Passing-basierten
Medienzugriffs für IEEE802.11n-basierte
Drahtlos-Langstrecken-Punkt-zu-Punkt-Verbindungen
von
Martin Chauchet
Erstprüfer: Prof. Dr. Karl JonasZweitprüfer: Prof. Dr. Stefan BöhmerBetreuer: M. Sc. Michael RademacherEingereicht am: 29. April 2016
Persönliche Erklärung
Erklärung
Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbst angefertigt habe;
die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht. Die Arbeit wurde bisher keiner Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
Troisdorf, (29. April 2016)
(Martin Chauchet)
Inhaltsverzeichnis I
Inhaltsverzeichnis
Abbildungsverzeichnis IV
Tabellenverzeichnis VI
Abkürzungsverzeichnis VII
1. Einleitung 1
I. Literatur 4
2. Grundlagen 52.1. WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Bitübertragungsschicht . . . . . . . . . . . . . . . . . . . . . . 52.1.2. Medienzugriffsschicht . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Wahlfreier Medienzugriff . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Langstrecken-Punkt-zu-Punkt-Verbindungen . . . . . . . . . . . . . . . 142.4. Gesteuerter Medienzugriff . . . . . . . . . . . . . . . . . . . . . . . . 17
3. Stand der Forschung 203.1. Gesteuerter Medienzugriff für IEEE 802.11 . . . . . . . . . . . . . . . 203.2. Token Passing für IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 223.3. Token Passing für IEEE 802.11 WiLD PtP . . . . . . . . . . . . . . . . 273.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
II. Das Protokoll WiLDToken 33
4. Entwurf des Protokolls 344.1. Anforderungen und Prämissen . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1. Prämissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.2. Leistungsfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . 354.1.3. Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.4. Fehlertoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.5. Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Protokollablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.1. Datenfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2. Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.3. Timing-Parameter . . . . . . . . . . . . . . . . . . . . . . . . 474.2.4. Aggregierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.5. Empfangsbestätigung . . . . . . . . . . . . . . . . . . . . . . . 51
II
4.3. Frame-Formate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.1. Sync-Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.2. Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.3. Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5. Mathematisches Modell 545.1. Modellbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.2. Leistungsabschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Implementierung 596.1. Implementierungsoptionen . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.1. Eigenständiges Kernelmodul . . . . . . . . . . . . . . . . . . . 596.1.2. Linux Kernel Packet Scheduler/Traffic Control . . . . . . . . . 616.1.3. OpenFlow und Open vSwitch . . . . . . . . . . . . . . . . . . 626.1.4. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1.5. Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2. Simulation mit ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.2.1. Einführung in ns-3 . . . . . . . . . . . . . . . . . . . . . . . . 666.2.2. Wifi-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 676.2.3. Langstrecken-Punkt-zu-Punkt-Verbindungen . . . . . . . . . . 69
6.3. Architektur der Implementierung . . . . . . . . . . . . . . . . . . . . . 706.4. Implementierungsdetails . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4.1. Hinzufügen der WiLDToken-Frames . . . . . . . . . . . . . . 736.4.2. Änderungen am unteren MAC . . . . . . . . . . . . . . . . . . 746.4.3. MAC High . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.4.4. Queue-Management . . . . . . . . . . . . . . . . . . . . . . . 766.4.5. Kanalzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
III. Evaluierung und Diskussion 80
7. Evaluierung 817.1. Messgrößen und -parameter . . . . . . . . . . . . . . . . . . . . . . . 81
7.1.1. Messparameter . . . . . . . . . . . . . . . . . . . . . . . . . . 817.1.2. Messgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2. Messdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2.1. Verkehrsgenerierung . . . . . . . . . . . . . . . . . . . . . . . 867.2.2. Datenerhebung . . . . . . . . . . . . . . . . . . . . . . . . . . 877.2.3. Szenarienbildung . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3. Szenario 1: Synchronisierung und Token-Austausch . . . . . . . . . . . 897.4. Szenario 2: Entwicklung der Datenrate bei steigender Distanz . . . . . . 907.5. Szenario 3: Entwicklung der Latenz bei steigender Linksättigung . . . . 957.6. Szenario 4: Zusicherung von Fairness über Zeit . . . . . . . . . . . . . 98
III
7.7. Szenario 5: Entwicklung der Datenrate und des Paketverlusts bei sinken-dem Rauschabstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.8. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8. Zusammenfassung und Ausblick 104
A. Anhang 116A.1. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116A.2. Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.3. Listings und Quellcode-Auszüge . . . . . . . . . . . . . . . . . . . . . 120
A.3.1. Mathematisches Modell . . . . . . . . . . . . . . . . . . . . . 120A.3.2. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 123
Abbildungsverzeichnis IV
Abbildungsverzeichnis
1.1. Beispiel für ein vermaschtes Langstrecken-Funknetzwerk . . . . . . . . 1
2.1. IEEE 802.11: Komponenten (AP, STA, BSS, DS) . . . . . . . . . . . . 8
2.2. IEEE 802.3: Kopfdaten-Format . . . . . . . . . . . . . . . . . . . . . . 8
2.3. IEEE 802.11: Kopfdaten-Format . . . . . . . . . . . . . . . . . . . . . 8
2.4. ALOHA: Kollision und Übertragungswiederholungen . . . . . . . . . . 10
2.5. IEEE 802.11: Distributed Coordination Function (DCF) - Grundlagen . 12
2.6. IEEE 802.11: Aggregierung auf MSDU- und MPDU-Ebene . . . . . . 13
2.7. IEEE 802.11: Paketfluss der Bestätigungsframes . . . . . . . . . . . . . 15
2.8. IEEE 802.11: Ablauf Distributed Coordination Function . . . . . . . . 17
2.9. Token Ring: Knoten mit Token sendet Daten auf den Ring . . . . . . . 19
3.1. IEEE 802.11n: MAC-Architektur . . . . . . . . . . . . . . . . . . . . . 21
3.2. SoftToken: Kommunikationsablauf zwischen den Stationen . . . . . . . 26
3.3. 2P: Protokolldetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4. JazzyMAC: Überlappende Übertragung . . . . . . . . . . . . . . . . . 30
4.1. Vergleich: Queueing in DCF und WiLDToken ohne QoS . . . . . . . . 41
4.2. WiLDToken: Zustandsautomat . . . . . . . . . . . . . . . . . . . . . . 43
4.3. WiLDToken: Datenfluss zwischen den Stationen . . . . . . . . . . . . . 44
4.4. WiLDToken: Einfluss der Ausbreitungsverzögerung . . . . . . . . . . . 49
4.5. WiLDToken: Struktur einer A-MPDU . . . . . . . . . . . . . . . . . . 50
6.1. TC: Einordnung im Linux-Netzwerkstack . . . . . . . . . . . . . . . . 61
6.2. TC: Filter und Queueing Disciplines . . . . . . . . . . . . . . . . . . . 61
6.3. SDN: Aufbau und Architektur . . . . . . . . . . . . . . . . . . . . . . 63
6.4. ns-3: Architektur des Wifi-Moduls . . . . . . . . . . . . . . . . . . . . 67
6.5. 802.11: Datenrate und Zeitschlitzlänge über Distanz, Modell und Simu-
lation in ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.6. WiLDToken: Architektur in ns-3 . . . . . . . . . . . . . . . . . . . . . 72
6.7. ns-3: Helper-Klassen für Wifi und WiLDToken . . . . . . . . . . . . . 72
7.1. ns-3: FlowMonitor-Architektur . . . . . . . . . . . . . . . . . . . . . . 87
7.2. WiLDToken: Synchronisierungsvorgang in ns-3-Simulation . . . . . . . 89
7.3. WiLDToken: Aufbau der A-MPDU in PCAP-Trace . . . . . . . . . . . 90
7.4. Szenario 2a: Datenrate über Distanz, Modell und Simulation in ns-3 von
DCF und WiLDToken . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.5. Szenario 2b: Datenrate über Distanz und Aggregierungsstufe, Simulati-
on von DCF und WiLDToken in ns-3 . . . . . . . . . . . . . . . . . . . 92
7.6. Szenario 2c: Datenrate über Distanz und Paketgröße, Simulation von
DCF und WiLDToken in ns-3 . . . . . . . . . . . . . . . . . . . . . . . 93
Abbildungsverzeichnis V
7.7. Szenario 2d: Datenrate über Distanz für TCP und UDP, Simulation von
DCF und WiLDToken in ns-3 . . . . . . . . . . . . . . . . . . . . . . . 95
7.8. Szenario 3a: Latenz und Jitter über Applikationsdatenrate, Simulation
von DCF und WiLDToken in ns-3 . . . . . . . . . . . . . . . . . . . . 96
7.9. Szenario 3b: Histogramm die Latenz für DCF und WiLDToken . . . . . 98
7.10. Szenario 4a: Fairness zwischen DCF und WiLDToken in ns-3 . . . . . . 99
7.11. Szenario 4b: Linkratio zwischen DCF und WiLDToken in ns-3 . . . . . 100
7.12. Szenario 5: Durchsatz und Paketverlust über Rauschabstand zwischen
DCF und WiLDToken in ns-3 . . . . . . . . . . . . . . . . . . . . . . . 101
8.1. Vergleich Queueing der EDCA und WiLDToken mit QoS . . . . . . . . 106
A.1. WiLDToken: Erweiterung der Vererbungshierarchie von ns3::WifiMac 117
A.2. WiLDToken: UML-Klassendiagramme weiterer WiLDToken-Klassen . 118
A.3. WiLDToken: UML-Klassendiagramm der Architektur . . . . . . . . . . 119
Tabellenverzeichnis VI
Tabellenverzeichnis
2.1. IEEE 802.11: Bruttodatenrate bei 20 MHz Kanalbreite und einem Spa-
tial Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. WiLDToken: Übersicht über Sendelimititierungen . . . . . . . . . . . . 44
4.2. WiLDToken: Übersicht über die verschiedenen Frame-Typen . . . . . . 53
7.1. Simulation: Applikationen zur Datenerzeugung . . . . . . . . . . . . . 86
A.1. EDCA-Standard-Parameter-Satz . . . . . . . . . . . . . . . . . . . . . 116
A.2. WildToken: Festlegung der QoS-Parameter (nach eigener Darstellung) . 116
Abkürzungsverzeichnis VII
AC Access Category
AIFS Arbitration Interframe Space
A-MPDU Aggregated MPDU
AP Access Point
BE Best Effort
BER Bit Error Rate
BK Background
BSS Basic Service Set
CAPEX Capital Expenditure
CCA Common Channel Assignment
CFP Contention Free Period
COTS Customer Off-The-Shelf
CP Contention Period
CSMA Carrier Sense Multiple Access
CSMA/CA Carrier Sense Multiple Access/Collision Avoidance
CSMA/CD Carrier Sense Multiple Access/Collision Detection
CSV Comma Separated Values
CW Contention Window
DCF Distributed Coordination Function
DIFS DCF Interframe Space
DS Distribution System
DSSS Direct Sequence Spread Spectrum
EDCA Enhanced Distributed Channel Access
EIRP Equivalent Isotropically Radiated Power
FCS Frame Check Sequence
FEC Forward Error Correction
FHSS Frequency Hopping Spread Spectrum
FIFO First-In-First-Out
FOSS Free and Open Source Software
GI Guard Interval
HCCA HCF Controlled Channel Access
HCF Hybrid Coordination Function
HTB Hierarchical Token Bucket
IBSS Independent Basic Service Set
ISM Industrial, Scientific and Medical
ITU-R ITU Radiocommunication Sector
MAC Media Access Control
MCS Modulation and Coding Scheme
MIMO Multiple Input Multiple Output
Abkürzungsverzeichnis VIII
MLME MAC Layer Management Entity
MPDU MAC Protocol Data Unit
MSDU MAC Service Data Unit
OFDM Orthogonal Frequency-Division Multiplexing
OPEX Operational Expenditure
PCAP Packet Capture
PCF Point Coordination Function
PCI Protocol Control Information
PER Packet Error Rate
PHY Physical Layer
PtMP Point-to-Multipoint
PSK Pre Shared Key
QAM Quadratur-Amplituden-Modulation
QDisc Queueing Discipline
QoS Quality of Service
RTT Round Trip Time
SC-WMN Single Channel Wireless Mesh Network
SDU Service Data Unit
SDN Software Defined Network
SDWMN Software Defined Wireless Mesh Network
SIFS Short Interframe Space
SINR Signal-to-Noise-plus-Interference Ratio
STA Station
SynOP Synchronous Operations
TBF Token Bucket Filter
TCP Transmission Control Protocol
TC Traffic Control
TDMA Time Division Multiple Access
TSm Traffic Separation Mechanism
TXOP Transmit opportunity
UDP User Datagram Protocol
VI Video
VoIP Voice over Internet Protocol
VoIP Voice-over-IP
VO Voice
VTP Virtual Token Passing
WISP Wireless Internet Service Provider
WiLD WiFi based Long Distance
WMM Wi-Fi Multimedia
Abkürzungsverzeichnis IX
WMN Wireless Mesh Network
WTR Wireless Token Ring
WTRP Wireless Token Ring Protocol
Einleitung 1
1. Einleitung
Langstrecken-Punkt-zu-Punkt-Verbindungen stellen für Wireless Internet Service Provi-
der (WISP) eine kostengünstige Alternative dar, um ländliche oder abgelegene Gegenden
mit einer Internetanbindung zu versorgen. Insbesondere die Verwendung von handels-
üblichen Hardware- und Softwarekomponenten (Customer Off-The-Shelf (COTS)) und
offenen Kommunikationsprotokollen wie IEEE 802.11 ermöglichen eine Senkung der
initialen Kapitalaufwendungen (Capital Expenditure (CAPEX)) im Vergleich zur teu-
ren Verlegung von unterirdischen Datenkabeln. Auch für die Vernetzung von Unterneh-
mensstandorten und Außendienststellen bilden so genannte WiFi based Long Distan-
ce (WiLD)-Mesh-Netzwerke eine probate Alternative zur Anmietung teurer Darkfiber-
Strecken. Abbildung 1.1 zeigt beispielhaft die Topologie eines solchen vermaschten
Netzwerks auf der Basis von Langstrecken-Punkt-zu-Punkt-Verbindungen.
Abbildung 1.1: Beispiel für ein vermaschtes Funknetzwerk mit Langstrecken-Punkt-zu-Punkt-Verbindungen (nach eigener Darstellung).
IEEE 802.11, im Folgenden auch WLAN oder WiFi genannt, operiert in den unlizenzier-
ten ISM-Bändern um 2,4 GHz und 5 GHz und steht somit möglicherweise zeitweise in
einer Konkurrenzsituation mit anderen Teilnehmern innerhalb dieser beiden Frequenz-
bänder. Daher ist ein Medienzugriffsverfahren obligatorisch, das diese Konkurrenzsi-
tuation reguliert. Dies wird für IEEE 802.11 durch das Medienzugriffsprotokoll DCF
umgesetzt.
Die DCF implementiert einen wahlfreien Mehrfachmedienzugriff mit Trägerüberwa-
chung und Kollisionsvermeidung (Carrier Sense Multiple Access/Collision Avoidance
(CSMA/CA))([IEE12b, S. 818ff.]), ähnlich dem in Ethernet verwendeten Carrier Sense
Einleitung 2
Multiple Access/Collision Detection (CSMA/CD). Da Überschneidungen von Übertra-
gungen unterschiedlicher Stationen aufgrund der Ausbreitung von elektromagnetischen
Wellen im freien Raum nicht notwendigerweise immer einwandfrei zu erkennen sind,
sorgt ein zufallsbestimmter Backoff-Algorithmus für eine weitestgehende Vermeidung
dieser Kollisionen ([TW12, S. 354f.]). Alle beteiligten Stationen warten einen zufällig
gewählten Zeitraum ab, bis sie mit ihrer Übertragung beginnen. Die Entscheidung über
die Größe des Zufallsraumes ist ein Kompromiss zwischen Kollisionsfreiheit auf der
einen und Wartezeit und somit Latenz auf der anderen Seite.
Wie sich allerdings gezeigt hat, sind insbesondere diese Teile des Protokolls nicht opti-
mal für Langstrecken-Punkt-zu-Punkt-Verbindungen geeignet. Durch die oftmals großen
Distanzen von mehreren Dutzend Kilometern entstehen trotz Übertragung mit annähern-
der Lichtgeschwindigkeit entsprechend lange Signallaufzeiten. Das erfordert eine An-
passung von Timing-Mechanismen, beispielsweise der maximalen Wartezeit für Emp-
fangsbestätigung. Daneben ist auch die Wahl des Zufallsfensters für die Kollisionsver-
meidung zu berücksichtigen. Bei genau zwei beteiligten Stationen liegt ein optimaler
Wert hierfür um etwa den Faktor 4 bis 8 niedriger als im Standard vorgesehen. Die opti-
male Wahl der Parameter ist in [Rad15] beschrieben worden.
Folglich ist ein Einsatz der DCF als Medienzugriffsprotokoll auf Langstrecken-Punkt-
zu-Punkt-Verbindungen ohne Anpassungen nicht unbedingt als sinnvoll zu erachten.
Stattdessen sollte diskutiert werden, ob ein anders geartetes Protokoll einen adäquaten
Medienzugriff für diesen speziellen Anwendungsfall zur Verfügung stellen kann, wie
bereits in einem vorangegangenen Projekt geschehen (siehe [Cha15]).
Wie in diesem Projekt bereits vorgeschlagen, erscheint der Einsatz eines Token Passing-
basierten Protokolls als vielversprechende Alternative. In welcher Phase, beziehungs-
weise welchem Übertragungsmodus (Senden/Empfangen), sich eine Station gerade be-
findet, ist auch mit der DCF bekannt. Allerdings ist aufgrund der Zufallsfunktion nicht
bestimmbar, in welcher Phase die Station im nächsten Kommunikationsabschnitt sein
wird. Da nur genau zwei Stationen an der Übertragung beteiligt sind, kann mit einem
geeigneten Protokoll in jeder der beiden Stationen vorgehalten werden, wie diese Ver-
teilung im nächsten Abschnitt erfolgt. Die Randomisierung der DCF wird also durch
Determinismus ersetzt.
Anstatt nach jeder Übertragung das Medium abzuhören, ob es auch wirklich frei und da-
mit die vorherige Kommunikation beendet ist, erfolgt die Signalisierung in diesem Fall
über ein definiertes Datenpaket, den so genannten Token. Da jeder Station zu jedem Zeit-
punkt bewusst ist, ob sie berechtigt ist zu senden oder nicht - zum Beispiel über einen
Zustandsautomaten - werden Kollisionen zwischen den Beteiligten a priori ausgeschlos-
Einleitung 3
sen. Token Passing Protokolle gelten aufgrund dieses Mechanismus als kollisionsfreie
Protokolle (siehe hierzu [TW12, S. 317ff.]).
Ziel der vorliegenden Arbeit ist die Implementierung und Leistungserhebung eines To-
ken Passing-basierten Medienzugriffs für IEEE 802.11n-basierte Langstreckenfunkver-
bindungen. Dazu werden in Kapitel 2 zunächst die Grundlagen zu WLAN, Langstre-
ckenverbindungen und Medienzugriffsprotokollen aufgearbeitet. Weiterhin wird aufge-
zeigt, warum das Medienzugriffsverfahren CSMA/CA in der Standard-Konfiguration für
den Einsatz auf Langstrecken-Punkt-zu-Punkt-Verbindungen ungeeignet ist. In Kapitel 3
wird der Stand der Forschung aufgearbeitet und existierende Token Passing-Protokolle
für IEEE 802.11 vorgestellt. Anschließend wird im Kapitel 4 die Funktionsweise des
Protokolls ”WiLDToken” beschrieben und seine Merkmale mit geeigneten Methoden
modelliert. Um die Leistungsfähigkeit des Protokolls zu demonstrieren, wird eine Im-
plementierung innerhalb der Simulationsumgebung ns-3 durchgeführt und in Kapitel 6
dokumentiert. Zuvor werden ausgewählte Implementierungsoptionen erläutert und dis-
kutiert. Anhand einer Messkampagne wird evaluiert, inwieweit eine Leistungssteigerung
erzielt werden kann. Messkampagne und Ergebnisse werden in Kapitel 7 vorgestellt und
diskutiert.
Grundlagen 5
2. Grundlagen
In der vorangegangenen Einleitung wurde die grundsätzliche Funktionsweise von WLAN
und des zugehörigen Medienzugriffsprotokolls CSMA/CA bereits angedeutet. Die Grund-
lagen hierzu sollen in diesem Kapitel vertieft werden. Dazu wird auch die Entwick-
lung der Protokollfamilie CSMA aus der Reihe der Protokolle mit wahlfreiem Medi-
enzugriff vorgestellt. Im zweiten Drittel liegt der Fokus auf der Charakterisierung von
Langstrecken-Punkt-zu-Punkt-Verbindungen und deren Eigenschaften. Hieraus sollen
Anforderungen für das in Kapitel 4 zu entwickelnde Protokoll formuliert werden. Der
letzte Teil des Kapitels enthält als Vorarbeit auf das nächste Kapitel eine Übersicht über
grundlegende Protokolle mit gesteuertem Medienzugriff.
2.1. WLAN
WLAN wurde als Erweiterung der herkömmlichen kabelgebundenen Distributionssys-
teme (DS) entwickelt. Obwohl in der Ursprungsform etwa ein Jahrzehnt vor der Smart-
phone- und Tablet-Revolution entworfen, ist es die Basis für deren sinnvolle Integration
in Heim- und Unternehmensnetzwerke.
2.1.1. Bitübertragungsschicht
Die Bitübertragungsschicht bildet die tatsächliche Übertragung der Daten als elektro-
magnetische Wellen ab. Hier werden auch physikalische Spezifikationen des Mediums
und der Steckverbinder für Kabel oder Antennen festgelegt. Für WLAN bedeutet dies
unter anderem die Hinterlegung der Begriffe Kanal, Modulation und Kodierung sowie
Mehrwegeausbreitung mit der entsprechenden Bedeutung.
Kanäle Als Kanal wird ein Frequenzband fester Breite um eine Mittenfrequenz herum
verwendet. In der ursprünglichen Fassung von 1997 beträgt die Bandbreite ausschließ-
lich 20 MHz. Diese wurde auch bei den Erweiterungen a, b und g beibehalten. Mit IEEE
802.11n kam die Möglichkeit hinzu, über einen zweiten angrenzenden 20 MHz-Kanal
die Bandbreite auf 40 MHz erweitern zu können. Hierbei fungiert einer der beiden Kanä-
le als Primär-, der andere als Sekundärkanal (vgl. [IEE12b, S. 1738]). Zusätzlich zu 20
und 40 MHz erlaubt IEEE 802.11ac nochmals eine Erweiterung auf 80 oder 160 MHz
Kanalbreite ([IEE13]). In den verwendeten Industrial, Scientific and Medical (ISM)-
Bändern um 2,4 und 5 GHz stehen bei einer Kanalbandbreite 3 respektive 19 über-
lappungsfreie Kanäle zur Verfügung, deren Nutzbarkeit durch die jeweilige nationale
Regulierungsbehörde weiter beschränkt werden kann (siehe [IEE12b, S. 1141,1566]).
Grundlagen 6
Mehrwegeausbreitung und MIMO Durch Objekte und Hindernisse in der Betrieb-
sumgebung eines Basic Service Set (BSS) entstehen zwangsläufig Reflexionen und da-
mit unterschiedliche Signallaufzeiten von Quelle zu Ziel. Bis IEEE 802.11a/b/g wurde
diese Mehrwegeausbreitung genutzt, um über Antennendiversität beim Empfang die An-
tenne mit der besten Signalqualität auszuwählen. Mit IEEE 802.11n und ac wurde diese
Antennendiversität um Multiple Input Multiple Output (MIMO)-Funktionalität zur Un-
terscheidung mehrerer räumlich getrennter Datenströme, so genannter Spatial Streams,
ergänzt. Weiterführende Informationen hierzu finden sich in [Rec12, S. 256,291]. Für
Langstrecken-Punkt-zu-Punkt-Verbindungen können kreuzpolarisierte Antennen verwen-
det werden, um über MIMO eine Steigerung der Datenrate zu erreichen (siehe [RKJ14]).
Modulation und Kodierung Die Bruttodatenrate eines einzelnen Spatial Streams ist
unter anderem direkt abhängig von der Wahl der Modulation, der Kodierung und des
Schutz-Intervals (Guard Interval (GI)) und wird für die Berechnung der Datenrate in der
mathematischen Modellierung von WiLDToken in Kapitel 5 benötigt.
Als verfügbare Modulationsverfahren wurden mit IEEE 802.11 und den Erweiterungen
a, b und g zunächst binäre und quartiäre Phasenmodulation sowie Quadratur-Amplituden-
Modulation (QAM) mit 16 Punkten (16-QAM) festgelegt. Später wurden mit 11n noch
64-QAM und mit 11ac 256-QAM hinzugefügt. Während der Kanalkodierung werden
zur Fehlerkorrektur in jeden Frame Datenredundanzen mit einem wählbaren Faktor zwi-
schen 1/2 und 5/6 eingefügt.
Tabelle 2.1: IEEE 802.11: Bruttodatenrate bei 20 MHz Kanalbreite und einem Spatial Stream(nach Tabelle 20-29 ([IEE12b, S. 1771]))
MCSIndex Modulation R NBPSCS(iSS) NSD NCBPS NDBPS
Data rate (Mbit/s)800 ns GI 400 ns GI
0 BPSK 1/2 1 52 52 26 6.5 7.21 QPSK 1/2 2 52 104 52 13.0 14.42 QPSK 3/4 2 52 104 78 19.5 21.73 16-QAM 1/2 4 52 208 104 26.0 28.94 16-QAM 3/4 4 52 208 156 39.0 43.35 64-QAM 2/3 6 52 312 208 52.0 57.86 64-QAM 3/4 6 52 312 234 58.5 65.07 64-QAM 5/6 6 52 312 260 65.0 72.2
Anmerkungen: R: Fehlerkodierungsrate, NBPSCS(iSS): Anzahl kodierter Bits pro OFDM-Träger undSpatial Stream, NSD: Anzahl komplexer Datenwerte pro OFDM-Symbol pro Stream,NCBPS: Anzahl kodierte Bits pro OFDM-Symbol, NDBPS: Anzahl Datenbits proOFDM-Symbol
Als Schutz vor Interferenzen wurden in IEEE 802.11 und 11b zunächst Frequency Hop-
ping Spread Spectrum (FHSS) und Direct Sequence Spread Spectrum (DSSS) einge-
führt. Seit IEEE 802.11a und g wird hingegen ausschließlich Orthogonal Frequency-
Division Multiplexing (OFDM) mit 53 Unterträgern (57 mit 11n/ac) verwendet, da-
von vier als 4 Pilot- und 48 als Nutzdatenträger. Dadurch ist es möglich, den Einfluss
Grundlagen 7
schmalbandiger Störeinflüsse zu verringern. Ein Schutzinterval (GI) trennt die einzel-
nen OFDM-Symbole voneinander und stellt sicher, dass diese vom Empfänger korrekt
interpretiert werden können. Durch die geeignete Wahl dieses Intervals ist ein Trade-
off zwischen Störresistenz (langes GI (800ns)) und hoher Datenrate (kurzes GI (400ns))
möglich ([IEE12b, S. 1669ff.]). Tabelle 2.1 zeigt beispielhaft die aus den verschiedenen
Modulationsstufen resultierende Bruttodatenrate für einen räumlichen Datenstrom (Spa-
tial Streams). Weitere Informationen hierzu können bei Rech ([Rec12, S. 262f.]) sowie
direkt im Standard ([IEE12b, S. 1583ff.]) gefunden werden.
Carrier Sensing IEEE 802.11 operiert innerhalb der auch anderen Benutzern frei zu-
gänglichen ISM-Bänder. Die zuständige Standardisierungsinstitution ITU Radiocommu-
nication Sector (ITU-R) verlangt dabei in ihren Vorgaben, dass Funkdienste in diesen
Bändern Störeinflüsse von entsprechenden industriellen, wissenschaftlichen oder medi-
zinischen Applikationen akzeptieren müssen ([IR12, S. 65]). Im Gegenzug dazu haben
die Administratoren dieser Anwendungen die Störeinflüsse dafür möglichst gering und
innerhalb der zugewiesenen Bänder zu halten ([IR12, S. 228]). Daher führt WLAN vor
jeder Übertragung Carrier Sensing durch.
2.1.2. Medienzugri�sschicht
Die Medienzugriffsschicht steuert den Zugriff auf das Medium, im Falle von WLAN
die oben beschriebenen ISM-Bänder. Hierbei kann es zu einer Konkurrenzsituation zwi-
schen zwei unabhängigen WLAN-Kommunikationsstrukturen oder zwischen WLAN-
Teilnehmern und einem weiteren Sekundärnutzer kommen.
Service Set: BSS, IBSS und ESS Zu diesem Zweck werden die Teilnehmer einer
WLAN-Zelle in einem so genannten Service Set gruppiert. Unter dem Begriff Service
Set werden in IEEE 802.11 verschiedene Arten von Funktionseinheiten zusammenge-
fasst (siehe auch [IEE12b, S. 45ff]). Dabei stellt das BSS die kleinstmögliche Funkti-
onseinheit dar. Ein BSS besteht aus mindestens zwei Stationen und kann entweder meh-
rere unabhängige Teilnehmer vernetzen (Independent Basic Service Set (IBSS)/Adhoc-
Modus) oder im Infrastruktur-Modus von einem zentralen Management- und Zugangs-
punkt (Access Point (AP)) aufgespannt werden.
Abbildung 2.1 zeigt ein Beispielnetzwerk bestehend aus den verschiedenen beschriebe-
nen Komponenten. In der Mitte bildet ein kabelgebundenes Netzwerk (Distribution Sys-
tem (DS)) das Rückgrat der Anordnung, an dessen Rand zwei APs, STA 2 und STA 3,
Grundlagen 8
Abbildung 2.1: IEEE 802.11: Komponenten (AP, STA, BSS, DS)(Quelle: [IEE12b, S. 47])
je eine BSS-Zelle aufspannen. In jeder dieser beiden Zellen befindet sich ein weiterer
Client (STA 1 respektive STA 4).
Kopfdaten In kabelgebundenen Distributionssystemen ist Ethernet (IEEE 802.3) als
Schicht-2-Protokoll weit verbreitet. Daher haben sich WLAN-Schnittstellen gegenüber
Protokollen höherer Schichten wie Ethernet-Schnittstellen zu verhalten ([IEE12b, S. 45])
und verwenden diesen gegenüber den zugehörigen Ethernet-Header (in Abbildung 2.2
zu sehen).
Abbildung 2.2: IEEE 802.3: Kopfdaten-Format (nach [IEE12a, S. 53])
In der Kommunikation zwischen den Stationen wird der durch die komplexere Proto-
kollstruktur deutlich umfangreichere in Abbildung 2.3 zu sehende WLAN-Header ver-
wendet.
Abbildung 2.3: IEEE 802.11: Kopfdaten-Format (Quelle: [IEE12b, S. 381])
Beiden Header-Formaten ist die Verwendung von zwei Adressfeldern zur Spezifizie-
rung von Sender und Empfänger sowie einer Frame Check Sequence (FCS) zur Erken-
nung von Übertragungsfehlern gemein. Der WLAN-Header verfügt weiterhin je nach
Betriebsmodus (siehe auch [Eng05]) mindestens über ein drittes und optional über ein
viertes Adressfeld sowie über eine Reihe weiterer Felder für zusätzliche Informationen.
Grundlagen 9
Der Typ des WLAN-Frames wird dabei über die Felder Type und Subtype des Frame
Control-Felds festgelegt.
Über das Duration/ID-Feld wird die Dauer der Datenübertragung für das virtuelle Car-
rier Sensing der Medienzugriffsschicht angezeigt. Für eine eindeutige Identifizierung
jedes gesendeten Frames sorgt das Sequence-Control-Feld über eine fortlaufend inkre-
mentierte Sequenznummer (siehe [Rec12, S. 185]). Das QoS-Control-Feld dient, wie der
Name bereits andeutet, zur Zuordnung eines Frames beziehungsweise der darin enthalte-
nen Nutzdaten zu einer Verkehrsklasse. Abhängig von Typ und Subtyp des Frames sind
dabei unterschiedliche Belegungen der einzelnen Bits vorgesehen. Das HT-Control-Feld
als letztes Feld im IEEE 802.11-MAC-Header steuert erweiterte Protokollfunktionen
wie Sounding1 für QoS-Data- und Control-Wrapper-Frames.
Weitere Informationen hierzu können in [IEE12b], Seite 389ff. respektive 394ff. gefun-
den werden. Die beschriebene Struktur von Ethernet- und WLAN-Header wird für den
Entwurf des Token- Passing-Protokolls WiLDToken in Kapitel 4 benötigt.
2.2. Wahlfreier Medienzugri�
Als Medienzugriffsverfahren mit wahlfreiem Zugriff bezeichnet Kerner ([Ker95]) Pro-
tokolle, bei denen die an ein gemeinsam genutztes Medium angeschlossenen Stationen
unabhängig voneinander entscheiden, wann ein Zugriff auf das Medium aus ihrer Sicht
möglich und regulär ist. Dabei haben sie keine Kenntnisse über die Absichten der ande-
ren Stationen, da Kontrollinformationen gar nicht oder nur eingeschränkt ausgetauscht
werden. Somit kann beziehungsweise muss nicht jede Station für alle anderen Teilneh-
mer deren Status nachhalten. Dies vereinfacht die softwareseitige Implementierung der
Protokolle und verringert die zur Laufzeit belegten Ressourcen. Die Kommunikation
wird jedoch anfällig für Kollisionen, da zwei Stationen gleichzeitig entscheiden könnten
mit der Übertragung zu beginnen.
Die Protokollfamilie Carrier Sense Multiple Access (CSMA) ist ein Beispiel für Proto-
kolle mit wahlfreiem Medienzugriff. Einen Überblick über die historische Entwicklung
dieser Protokollfamilie bis hin zum bei IEEE 802.11 verwendeten CSMA/CA soll der
folgende Abschnitt geben.
ALOHA Durch seine verteilte geografische Struktur - eine langgezogene Inselkette
im Pazifik - entstand auf Hawaii in den 70er Jahren das Bedürfnis einer Vernetzung von
Benutzern auf den vielen Nebeninseln mit dem Zentralrechner auf der Hauptinsel O’ahu.
1Durchmessen des Kanals auf Physical Layer (PHY)-Ebene, siehe [IEE12b, S. 20,942f.]
Grundlagen 10
Dazu wurde das funkbasierte ALOHAnet aufgebaut und als Medienzugriffssteuerung
das ALOHA-Protokoll entwickelt (siehe hierzu [Abr70] ebenso wie [Ker95] S. 406f,
[TW12] S. 309ff., [Kau07] S. 335).
Reines ALOHA erlaubt zunächst allen Benutzern zu senden, wenn sie Daten übertragen
wollen. Folglich ist die Wahrscheinlichkeit für Kollisionen hoch, jeder Sender muss die-
se über einen Bestätigungsmechanismus erkennen. Falls eine Kollision aufgetreten ist,
wartet der Sender eine zufällig gewählte Zeit und sendet erneut.
Abbildung 2.4: ALOHA: Kollision und Übertragungswiederholungen (Quelle: [Abr70])
Slotted ALOHA erfordert einen in Zeitschlitze aufgeteilten Kanal. Jede Übertragung
darf dann nur zu Beginn eines Zeitschlitzes beginnen. Eine zuverlässige Synchronisation
der Zeitrahmen ist also notwendig. Bei Kollision greift die gleiche Backoff-Funktionalität
wie bei reinem ALOHA.
Es handelt sich zwar um ein vergleichsweise primitives Protokoll, was sich durch eine
maximale Kanalauslastung von e−1 zeigt. Dennoch bildet es die Basis der anderen in
diesem Abschnitt beschriebene Protokolle, denn es ist ӟbertragbar auf jedes Medium,
in dem nicht koordinierte Benutzer um die Benutzung eines einzelnen gemeinsamen
Kanals konkurrieren” ([TW12, S. 309]).
Grundlagen 11
CSMA Bei klassischem CSMA handelt es sich um ein Mehrfachzugriff-Protokoll mit
Trägerprüfung (vgl. [TW12, S. 314f.], [Ker95, S. 407f.]). Eine eingehende Analyse er-
folgte beispielsweise durch Kleinrock und Tobagi in [KT+75].
Unter dem Oberbegriff CSMA werden die drei Varianten 1-persistentes, non-persistentes
und p-persistentes CSMA zusammengefasst. Die ersten beiden unterscheiden sich nur in
ihrem Carrier Sensing-Verhalten bei belegtem Medium. Während 1-persistentes CSMA
kontinuierlich neu prüft, ob das Medium immer noch belegt ist, wählt non-persistentes
CSMA einen zufälligen Backoff, innerhalb dessen es kein Carrier Sensing betreibt.
p-persistentes CSMA gilt für Kanäle mit Zeitschlitzen. Eine Station S entscheidet bei
freiem Medium mit einer Wahrscheinlichkeit p, ob sie mit der Übertragung beginnt,
oder mit 1− p bis zum nächsten Zeitschlitz wartet. Ansonsten ist das Verhalten analog
zu non-persistentem CSMA.
CSMA/CD In allen oben genannten Protokollvarianten von ALOHA und CSMA be-
enden sendende Stationen ihre Übertragungen auch im Kollisionsfall regulär. CSMA/CD
enthält im Gegenzug eine Erweiterung, die eine Erkennung von Kollisionen frühzeitig
erlaubt. Daraufhin kann die bereits kompromittierte Übertragung abgebrochen und mit
dem Erholungsprozess (Backoff) begonnen werden.
Hieraus resultiert eine zusätzliche Steigerung der Effizienz. Voraussetzung sind aller-
dings Vollduplex-fähige Übertragungsmodule. CSMA/CD wird beispielsweise auf Ether-
net eingesetzt (vgl. [TW12, S. 316f.], [Ker95, S. 409ff.]).
CSMA/CA Die bei WLAN eingesetzte Medienzugriffskontrolle basiert wie das bei
Ethernet eingesetzte CSMA/CD ebenfalls auf CSMA und wird neben der ausführlichen
Definition im IEEE-Standard ([IEE12b, S. 824ff]) auch von Tanenbaum und Wetherall
([TW12, S. 353ff.]) sowie Rech ([Rec12, S. 167ff.]) eingehend beschrieben. Die Funk-
schnittstellen sind hier in der Regel nur halbduplex-fähig. Das bedeutet, dass - im Ge-
genteil beispielsweise zu Ethernet und CSMA/CD - während eines Sendevorgangs nicht
mitgehört werden kann, ob gerade eine andere Station sendet. Je nach räumlicher Ver-
teilung der Funknetzknoten ist zudem nicht gewährleistet, dass alle beteiligten Stationen
im gegenseitigen Funkbereich liegen. Diese Problematik ist auch unter ”Hidden Station”
und ”Hidden Terminal” bekannt.
Daher ist die so genannte Distributed Coordination Function a priori auf die Vermeidung
von Kollisionen ausgerichtet. Alle Stationen verfügen über ein so genanntes Contention
Grundlagen 12
Window (CW), innerhalb dessen sie einen zufälligen Backoff würfeln. Dieser Wert be-
stimmt, wie lange die jeweilige sendewillige Station warten muss, bevor sie einen Sen-
deversuch auf dem Medium unternimmt. Der Zähler wird mit jedem freien Slot um 1
dekrementiert und, falls zwischendurch eine andere Datenübertragung erkannt wird, an-
gehalten. Wenn der Wert 0 erreicht, prüft die Station ein letztes Mal, ob das Medium
immer noch frei ist und sendet in diesem Fall ihren Rahmen. Falls der Rahmen er-
folgreich übertragen wurde (d.h. keine Kollision erkannt wird), wird eine Bestätigung
erwartet, andernfalls wird die obere Grenze des CW und somit auch der Zufallsraum
verdoppelt. Die bestätigende Station erhält über eine verkürzte Wartezeit zwischen den
Frames (Short Interframe Space (SIFS)) bevorzugte Sendeberechtigung.
(a) Standard-Zugriff (b) Back-off-Prozedur
Abbildung 2.5: IEEE 802.11: Distributed Coordination Function (DCF) - Grundlagen (Quelle:[IEE12b, S. 838f.])
Die Datenübertragung wird wiederholt, bis der Datenrahmen erfolgreich übertragen wur-
de oder die maximale Anzahl an Sendeversuchen (Retry Limit) erreicht wurde. Eine
untere und obere Schranke für die Obergrenze des CW sind durch CWmin und CWmax
gegeben.
Enhanced Distributed Channel Access Eine Erweiterung der DCF für Multime-
diaanwendungen (Wi-Fi Multimedia (WMM)) wurde in IEEE 802.11e vorgestellt. Der
so genannte Enhanced Distributed Channel Access (EDCA) erlaubt dabei die Verwen-
dung von vier statt bislang einer Sendewarteschlange. Diese können jeweils mit indi-
viduellen Parametern für das Contention Window versehen werden. Außerdem wurden
die Parameter Arbitration Interframe Space (AIFS) und Transmit opportunity (TXOP)
hinzugefügt. Sie bestimmen je Warteschlange die Wartezeit zwischen Frames sowie eine
maximale Belegungszeit des Mediums.
Damit lassen sich verschiedene Dienstgüte-Grade realisieren, beispielsweise indem eine
Warteschlange zwar bevorzugt behandelt wird (kleineres Contention Window), aber nur
eine geringe Sendezeit erhält (geringe TXOP). Im Standard sind die bereits angedeuteten
vier Sendewarteschlangen für die Verkehrsklassen Sprache und Video (Voice (VO) re-
spektive Video (VI)) sowie Hintergrundübertragung und ”Bestmöglich” (Background
Grundlagen 13
(BK), Best Effort (BE)) spezifiziert. EDCA wurde bei der Spezifizierung von IEEE
802.11n mit in diesen Standard aufgenommen.
Aggregierung Ein wesentlicher Faktor, mit dem bei IEEE 802.11e respektive 11n
eine deutliche Steigerung der Datenrate erreicht wurde, ist das Aggregieren mehrerer
Datenframes sowohl auf MAC Service Data Unit (MSDU)- als auch auf MAC Protocol
Data Unit (MPDU)-Ebene. Im Gegensatz zu einzelnen MPDUs kann dann ohne Unter-
brechung durch die ansonsten notwendigen Contention-Phasen zwischen den aggregier-
ten Frames gesendet werden. Folglich steigt die Auslastung des Mediums.
Hierbei werden zwei Ebenen der Aggregierung unterschieden. Bei der MSDU-Aggre-
gierung werden mehrere Schicht-2-Dienstdateneinheiten (Service Data Unit (SDU)) zu
einer größeren SDU zusammengefasst. Dabei wird auf den umfangreichen WLAN-Hea-
der verzichtet und stattdessen ein verkleinerter A-MSDU-Header verwendet (siehe [IEE12b,
S. 416]). Durch die geringere Größe des Headers (14 Byte gegenüber 26 Byte, jeweils
ohne LLC) ist diese Form der Aggregierung sehr effizient. Die maximale Größe einer
A-MSDU beträgt 7935 Byte (vgl. [IEE12b, S. 382]).
(a) A-MPDU-Aggregierung (b) A-MSDU-Aggregierung
Abbildung 2.6: IEEE 802.11: Aggregierung auf MSDU- und MPDU-Ebene (Quelle: [IEE12b, S.416f.,812f.])
Im Gegensatz dazu sammelt die MPDU-Aggregierung mehrere bereits mit WLAN-
Header versehene MPDUs in einer Aggregated MPDU (A-MPDU). Ein entsprechender
Subframe-Header sowie bis zu drei Padding dienen dabei als Delimiter zwischen den
einzelnen A-MPDU-Subframes. Die Größe einer A-MPDU ist dabei auf maximal 64
MPDUs oder 65535 Byte beschränkt (siehe hierzu [IEE12b, S. 812f.]). Außerdem ist in
der Erweiterung IEEE 802.11j festgehalten, dass eine Belegung des Mediums durch ei-
neStation (STA) ohne zwischenzeitliches Carrier Sensing maximal 4 Millisekunden am
Stück erfolgen darf ([IEE04, S. 32]). Die Größe der A-MPDUs ist damit auch abhängig
von der durch Modulation and Coding Scheme (MCS) und Schutzintervall festgelegten
Grundlagen 14
Datenrate und kann insbesondere bei niedrigen Datenraten auch deutlich kürzer ausfal-
len.
Block Acknowledgements Interferenzen und andere Störeinflüsse (Long/Short Term
Fading) können zum Verlust einzelner Datenpakete führen. Um dies aufzufangen ist in
802.11 eine Bestätigungsfunktion vorgesehen, bei eingehende Pakete gegenüber dem
Sender bestätigt werden. Bei ausbleibender Bestätigung kann dieser eine erneute Über-
tragung des unbrauchbar gewordenen Pakets veranlassen. Außerdem wurden mit IEEE
802.11e die Möglichkeit hinzugefügt, die Bestätigungen auch blockweise zusammen-
zufassen. Dies wird als Block Acknowledgement (Block Ack oder BAck) bezeichnet.
Maximal lassen sich auf diese Weise 64 MPDUs auf einmal bestätigen ([IEE12b, S.
411]).
Unterschieden wird hierbei zwischen normaler (Basic Block Ack) und komprimierter
Bestätigung (Compressed Block Ack). In der normalen Variante enthält das Bestäti-
gungspaket eine Bitmap von 64 mal 16 Bit Größe. Dadurch lassen sich 64 individuelle
Frames anhand ihrer Sequenznummern bestätigen. Im Gegensatz dazu sieht der Bestä-
tigungsframe der komprimierten Bestätigung nur eine 64 * 1 Bit große Bitmap vor. Zu-
sätzlich wird eine Startsequenznummer angegeben. Die Kombination aus Bitmap und
Startsequenznummer dient zur Identifizierung der einzelnen Pakete. Dadurch werden
zwar 15 mal 64 Bit bei der Übertragung eingespart. Im Gegenzug lassen sich aber so nur
Pakete effizient bestätigen, die fortlaufende Sequenznummern haben.
Durch die Konsolidierung dieser 64 Bestätigungsframes in ein einziges Block Ack Fra-
me wird eine erhebliche Menge an Sendezeit eingespart, wie Abbildung 2.7 zeigt. Block
Acknowledgements werden individuell zwischen Sender und Empfänger über Block
Ack Requests ausgehandelt ([IEE12b, S. 391f.]).
Anhand der im Bestätigungspaket übermittelten Informationen kann die sendende Stati-
on verlorene oder unbrauchbar gewordene Pakete identifizieren und erneut übermitteln.
Dadurch wird die Zuverlässigkeit des Protokolls erhöht.
2.3. Langstrecken-Punkt-zu-Punkt-Verbindungen
In der Einleitung wurde bereits darauf eingegangen, dass die Charakteristika der hier
betrachteten Langstrecken-Punkt-zu-Punkt-Funkverbindungen sich von denen eines üb-
lichen WLAN-Nahbereichsnetzes unterscheiden. Diese besonderen Anforderungen sol-
len im kommenden Abschnitt genauer beleuchtet werden. Sie dienen auch als Grundlage
für den Entwurf des Protokolls im nächsten Kapitel.
Grundlagen 15
Sender Receiver
Data
ACK
Data
ACK
Data
ACK
(a) Ohne Block Acknowledgements
Sender Receiver
Data
Data
Data
Block ACK
(b) Mit Block Acknowledgements
Abbildung 2.7: IEEE 802.11: Paketfluss der Bestätigungsframes ohne bzw. mit blockweiser Be-stätigung
Punkt-zu-Punkt-Aspekte In einer regulären WLAN-Funkzelle mit einer unbekann-
ten Teilnehmerzahl (STAs) kann aufgrund des der Unabhängigkeit der einzelnen STA
keine Vorhersage des Medienzugriffs getroffen werden. Über die implementierte Medi-
enzugriffskontrolle muss lediglich dafür gesorgt werden, dass keine oder wenige Kol-
lisionen entstehen. Das wird bei WLAN - wie in Abschnitt 2.2 erläutert - über einen
randomisierten Backoff gewährleistet. In der Arbeit von Rademacher wurde bereits eine
Optimierung der Werte der DCF für IEEE 802.11n vorgestellt (siehe [Rad15, S. 82]).
Wie dort zu lesen ist, liegt das Optimum hier bei 7≤CWmin ≤ 15. Durch den verkleiner-
ten Zufallsraum steigt allerdings folglich die Kollisionswahrscheinlichkeit.
Im Gegensatz dazu ist bei einer Punkt-zu-Punkt-Verbindung die Anzahl der Teilnehmer
nicht beliebig, sondern auf zwei (A,B) festgelegt. Dadurch erhält die Kommunikation
zwischen diesen beiden Stationen einen deterministischen Charakter: Aus ihrem eige-
nen Zustand kann jede der beiden STAs schließen, in welchem Zustand sich die jeweils
andere STA befindet. Folglich gilt: Falls STA A nicht sendet, muss B das Senderecht
innehaben und umgekehrt. Dann muss A warten, bis B die Übertragung beendet. Aus
Fairnessgründen wird angenommen, dass beide Stationen abwechselnd senden (dürfen).
Sofern B das Ende der Übertragung ausreichend signalisiert, kann A sofort nach dem
Empfangen dieser Signalisierung mit dem Senden beginnen. Die randomisierte Backoff-
Funktion zur Kollisionsvermeidung ist somit wie bereits weiter oben besprochen obso-
Grundlagen 16
let.
Weiteres Optimierungspotenzial ist in der Bestätigungsfunktion zu finden. Im regulären
Betrieb mit mehreren (> 2) STAs verschickt jeweils die STA, an die eine Übertragung
adressiert war, bei erfolgreicher Übertragung einen Bestätigungsframe an den Sender.
Dieser markiert das Ende der Übertragung zwischen jenen zwei STAs und eröffnet für
alle sendewilligen Teilnehmer den Wettbewerb um das Medium (siehe hierzu auch Ab-
bildung 2.5a). Bei zwei beteiligten Stationen könnte diese Bestätigung an den nächsten
Datenframe in Umkehrrichtung gehangen werden (so genannte Piggyback Acknowled-
gements). Dadurch würde die verkürzte Wartezeit vor dem Versenden der Bestätigung
(SIFS) und die zugehörige Übertragungszeit inklusive Ausbreitungsverzögerung hinfäl-
lig.
Langstrecken-Aspekte Neben den erläuterten Punkt-zu-Punkt-Aspekten spielt die
Distanz bei Langstrecken-Punkt-zu-Punkt-Verbindungen eine übergeordnete Rolle. Die
als Träger verwendeten elektromagnetischen Wellen breiten sich mit annähernder Licht-
geschwindigkeit (300m/µs) aus. Daraus ergibt sich eine distanzabhängige Ausbreitungs-
verzögerung von tProp = 1µs/300m, die jedoch erst bei großen Distanzen von einigen
Kilometern an Relevanz gewinnt.
Der WLAN-Standard berücksichtigt diese Ausbreitungsverzögerung bei der Berech-
nung der Länge der Zeitschlitze (Slot Time) und des Timeouts der Empfangsbestäti-
gung (ACK Timeout). Protokoll-intern wird hierbei mit einer maximalen Verzögerung
von 1µs gerechnet ([IEE12b, S. 873, 1487]). Daraus ergibt sich eine maximale Distanz
von (siehe oben) d = 1µs ∗ 300m/µs = 300m. Bei größeren Distanzen erreicht folg-
lich die Empfangsbestätigung ihr Ziel nicht rechtzeitig vor Ablauf des entsprechenden
Timeout-Mechanismus. Dadurch kommt es zu unnötigen Übertragungswiederholungen
und einem Einbruch der Nutzdatenrate.
Wie in der Arbeit von Rademacher gezeigt wurde, ist eine distanzabhängige Anpassung
der Ausbreitungsverzögerung in der WLAN-Medienzugriffsschicht notwendig. Die An-
zahl der Übertragungswiederholungen lässt sich so reduzieren ([Rad15, S. 12]).
Neben dem Timeout der Empfangsbestätigung wird allerdings auch die Slotzeit erhöht,
wie in Abbildung 2.8 zu sehen ist. Dadurch wächst der Anteil des Contention Window
an der im Vorabschnitt beschriebenen gesamten Übertragung. Durch die größeren Slot-
und damit Backoffzeiten sinkt die Effizienz gegenpber einem Medienzugriffsprotokoll,
das auf einen solchen Mechanismus verzichtet.
Grundlagen 17
(a) Normale Verbindungen
(b) Langstrecken-Verbindungen
Abbildung 2.8: IEEE 802.11: Ablauf Distributed Coordination Function (Quelle: [Rad15, S. 37])
Motivation Wie vermutet wird, ist das Optimierungpotenzial bezüglich Datenrate und
Latenz mit dem Standard-Medienzugriffsprotokoll DCF beziehungsweise EDCA wei-
testgehend ausgeschöpft. Das Contention Window kann nicht weiter verkleinert werden,
ohne die Wahrscheinlichkeit für Kollisionen zu erhöhen und damit die Datenrate zu sen-
ken. Außerdem kann durch den randomisierten Backoff keine zuverlässige Zusicherung
von Sendeanteilen zwischen den Stationen erfolgen. Auch eine Zusicherung von Dienst-
güteparametern ist nur propabalistisch möglich.
Daher scheint es sinnvoll, über einen alternativen Medienzugriff zu diskutieren. Insbe-
sondere bei den betrachteten Punkt-zu-Punkt-Verbindungen bietet sich ein gesteuerter
Medienzugriff an. Mithilfe dessen kann deterministisch reguliert werden, welcher Teil-
nehmen zu welchem Zeitpunkt senden darf. Außerdem lassen sich über Zuteilung be-
stimmter Slotlängen Bandbreitenanteile zusichern. Über einen deterministischen Scheduling-
Algorithmus wäre es außerdem möglich, bestimmte Verkehrsklassen prädestiniert zu be-
vorzugen.
2.4. Gesteuerter Medienzugri�
Im Gegensatz zum wahlfreien wird beim gesteuerten Medienzugriff die Reihenfolge
und Dauer der Medienbelegung zu Beginn oder während der Kommunikation explizit
ausgehandelt. Dadurch kann im Idealfall die Auslastung des Mediums und somit die Ef-
fizienz maximiert werden. Durch die vorbestimmte Zuteilung sind entsprechende Proto-
kolle abgesehen von externen Störeinflüssen außerdem kollisionsfrei, wie Kerner angibt
([Ker95, S. 404]). Andererseits impliziert diese Art des Zugriffs aufgrund der Abstim-
mung der Stationen einen hohen Koordinationsaufwand. Beispielsweise müssen Algo-
Grundlagen 18
rithmen zur Berechnung von Slotbelegungen und/oder andere umfassende Verwaltungs-
Mechanismen (beispielsweise zum Ringmanagement) entwickelt und implementiert wer-
den.
Kerner ([Ker95, S. 404]) unterscheidet zentral und verteilt gesteuerten Zugriff. Bei Pro-
tokollen mit verteiltem Zugriff wird die Belegung des Mediums zwischen den einzelnen
Stationen ausgehandelt, bei zentral gesteuerten Protokollen übernimmt eine prädesti-
nierte Master-Station diese Funktion. Die zwei beziehungsweise drei im Folgenden er-
läuterten Verfahren zum gesteuerten Medienzugriff, Slotted Ring und Token Ring/Bus,
genießen zwar heute keine praktische Relevanz mehr, sind dennoch Grundlage für wei-
tere in dieser Arbeit betrachtete Protokolle.
Slotted Ring
Kerner beschreibt in [Ker95, S. 413f.] ab Seite 413 das so genannte Slotted Ring-Verfah-
ren. Dabei sind alle beteiligten Stationen in einer Ringtopologie miteinander verbunden.
Auf dem Ring werden von einer Monitorstation Zeitschlitze (Slots) eingerichtet, die
grundsätzlich von jeder Station genutzt werden können. Wenn eine Station Daten ver-
senden will, wartet sie auf einen freie Zeitschlitz und markiert diese als belegt. Dann legt
sie die Adress- und Nutzdaten in die jeweils dafür vorgesehenen Bereiche ab und gibt
den Slot wieder auf den Ring. Die empfangenden Stationen prüfen jeden belegten Slot,
ob er an sie adressiert ist. In diesem Fall kopieren sie die Daten vom Ring und bestätigen
über dedizierte Flags im Slot den Empfang der Daten. Die sendende Station markiert
den Slot anschließend wieder als frei und nimmt die Nutzdaten vom Ring.
Wie Kerner anmerkt, sei dieses Verfahren vergleichsweise einfach zu realisieren und
erziele auch bei hoher Auslastung noch gute Ergebnisse, da bei n Slots auf dem Ring
auch n Stationen parallel übertragen könnten ([Ker95, S. 414]).
Token Ring/Bus
Bekannter als der Slotted Ring sind die beiden Token-Passing-Verfahren Token Ring
([IEE98]) und Token Bus ([IEE90]). Sie werden beispielsweise von Tanenbaum ([TW12,
S. 319ff.]) und Kerner ([Ker95, S. 414ff., 440ff.]) eingehend erläutert.
Grundsätzlich arbeitet der Token Ring (spezifiziert in IEEE 802.5) ähnlich dem Slotted
Ring. Eine Monitorstation sorgt dafür, dass initial ein als frei markiertes Token auf dem
Ring zur Verfügung steht. Sendewillige Stationen können dieses Token vom Ring neh-
men und stattdessen ihre eigenen Daten auf diesen legen (siehe Abbildung 2.9. Wenn
die sendende Station ihre eigenen Daten wieder empfängt, kann sie davon ausgehen,
Grundlagen 19
Abbildung 2.9: Token Ring: Knoten mit Token sendet Daten auf den Ring (nach eigener Darstel-lung)
dass alle anderen Stationen Gelegenheit hatten, die Daten zu empfangen. Sie nimmt die
Daten vom Ring und gibt stattdessen den Token wieder frei. Da immer nur eine Station
gleichzeitig senden kann, ist dieses Verfahren kollisionsfrei.
Für das Token Bus-Verfahren wurde der Token Passing-Mechanismus auf die Bus-Topo-
logie übertragen und im Standard IEEE 802.4 spezifiziert. Durch eine feste Reihenfolge
der an den Bus angeschlossenen Stationen wird über die physikalische Bustopologie ein
logischer Ring gelegt. Jeder Station ist dabei ihr jeweiliger Vorgänger und Nachfolger
bekannt. Das Management des logischen Rings, beispielsweise das Einfügen und Ent-
fernen von Stationen, erfolgt über eigene Verwaltungsframes. Ebenso ist der Token ein
dediziertes Frame.
Der Token Bus vereint die Vorteile einer Bus-Topologie (einfacher Aufbau, günstig) mit
der Kollisionsfreiheit eines Token Passing-Verfahrens. Allerdings erhöht die Verwaltung
von Ring und Token die Komplexität der Implementierung.
Stand der Forschung 20
3. Stand der Forschung
Wie im vorherigen Kapitel erläutert wurde, stellt eine Medienzugriffssteuerung für eine
Medium mit mehreren konkurrierenden Stationen sicher, dass das Risiko von Kollisio-
nen durch überlappende Übertragungen minimiert oder vollständig eliminiert wird, ab-
hängig davon, welche Art Medienzugriff eingesetzt wird. Im zweiten Teil wurden die
beiden Token Passing-basierten Verfahren Token Ring und Token Bus vor- und deren
Vor- und Nachteile gegenüber Protokollen mit wahlfreiem Medienzugriff herausgestellt.
Im Zuge dessen wurden insbesondere wurde die Kollisionsfreiheit von gesteuerten Me-
dienzugriffsverfahren hervorgehoben.
Auch für WLAN im Allgemeinen und WLAN-basierte Langstrecken-Punkt-zu-Punkt-
Verbindungen wurden diese Vorteile bereits erkannt und verschiedene Protokolle mit
gesteuertem Medienzugriff implementiert und vorgestellt. In diesem Kapitel wird dies-
bezüglich der Stand der Forschung aufgearbeitet und ausgewählte Protokolle mit ihrer
grundsätzliche Funktionsweise beschrieben.
3.1. Gesteuerter Medienzugri� für IEEE 802.11
Der Ansatz einer gesteuerte Medienzugriffskontrolle für 802.11 zu implementieren wur-
de bereits im Standard IEEE 802.11 aufgegriffen. Hier wurde mit der Point Coordination
Function (PCF) bereits eine Master-Slave-Zugriffssteuerung für den Infrastrukturmodus
beschrieben ([IEE12b, S. 819]). Allerdings wird diese aufgrund mangelnder Koordina-
tionsfähigkeit mit anderen Sekundärnutzern des Mediums nur selten implementiert, wie
Tanenbaum anmerkt ([TW12, S. 355]). Daher haben sich beispielsweise die Autoren um
Rao in [RS05] mit einer alternativen Lösung beschäftigt. Beide Protokolle werden in
diesem Abschnitt kurz in ihrer Funktionsweise erläutert und die Besonderheiten heraus-
gestellt.
PCF/HCF
Die PCF ist wie erläutert ein im Standard IEEE 802.11 spezifizierter Betriebsmodus für
WLANs (siehe auch [Rec12, S. 240ff.]). Dabei nimmt im Infrastrukturmodus der AP
als designierte Station (Point Coordinator) zeitweise die alleinige Kontrolle über den
Medienzugriff. Der aus der DCF bekannte Wettbewerb um das Medium wird hier als
Contention-Phase (Contention Period (CP)) bezeichnet und wechselt sich mit einer so
genannten Contention-freien Phase (Contention Free Period (CFP)) ab, innerhalb derer
der AP einzelnen Stationen gezielt das Senderecht einräumt und wieder entzieht. Der
Stand der Forschung 21
Abbildung 3.1: IEEE 802.11n: MAC-Architektur (Quelle: [IEE12b, S. 818, Abbildung 9-1])
fortwährende Wechsel zwischen CP und CFP ist notwendig, um fremde Teilnehmer auf
dem ISM-Band zu berücksichtigen. Die Implementierung der PCF ist allerdings laut
Angabe im Standard optional und wird infolgedessen nur selten umgesetzt ([TW12, S.
355]). Da ein Access Point als Point Coordinator benötigt wird, ist eine Umsetzung in
anderen Betriebsmodi (IBSS, Mesh) nicht möglich (siehe auch [IEE12b, S. 819]).
Die Hybrid Coordination Function (HCF) vereint PCF, EDCA sowie die HCF Controlled
Channel Access (HCCA), die Dienstgüte-Implementierung für die CFP, unter einem
Dach, wie Abbildung 3.1 zeigt (siehe auch [IEE12b, S. 818, 873ff.]). Sie wurde ebenfalls
in der Erweiterung IEEE 802.11e vorgestellt und in 11n übernommen. Access Points,
auf denen die HCF vollständig umgesetzt wurde, können mit dem Zertifikat ”WMM
Scheduled Access” versehen werden (vgl. [SVR+08].
Overlay MAC Layer
Als alternativer gesteuerter Medienzugriff für WLANs wurde der Overlay MAC Layer
von Rao und anderen entwickelt und in [RS05] vorgestellt. Er fügt sich oberhalb der
regulären Medienzugriffsschicht, also auch der DCF ein (Overlay). Das hat den Vorteil,
dass er sich ohne betriebssystemseitige Anpassungen in den bestehenden Netzwerkstack
integrieren lässt. Der Overlay MAC Layer arbeitet nach dem Prinzip des Zeitmultiplex
(Time Division Multiple Access (TDMA)) und soll in Multihop-Netzwerken dazu die-
nen, ”Fairness und Vorhersagbarkeit zu garantieren” ([RS05, S. 1]).
Dabei wird das Medium in Zeitschlitze gleicher Größe eingeteilt, deren jeweilige Gren-
zen lose unter den Stationen synchronisiert werden. Das ist notwendig, damit jede Sta-
tion weiß, wann der ihr zugeteilte Zeitschlitz beginnt und endet. Als Quelle dient dabei
ein vorher bestimmter Führungsknoten (leader node). Alle anderen Stationen errechnen
aus einem Timestamp dieses Führungsknotens und der geschätzten Einweg-Latenz ihren
Stand der Forschung 22
eigenen Taktversatz und korrigieren entsprechend. Durch die lose Synchronisation wer-
den aufwendige Mechanismen wie dedizierte Netzwerke oder GPS-Uhren vermieden,
die andernfalls notwendig wären, um eine exakte Synchronisation der Uhren der Statio-
nen herzustellen. Die lose Synchronisation ist nach Aussage der Autoren ausreichend,
da vergleichsweise große Zeitschlitze von 10 Paketen á 1500 Byte Länge verwendet
werden.
Als besondere Herausforderung stellen die Autoren den Entwurf des Algorithmus her-
aus, der die Zuweisung der Zeitschlitze vornimmt. Ausgangssituation sei, dass alle Sta-
tionen des Netzwerks sich gegenseitig stören, folglich immer nur eine Station gleichzei-
tig senden kann. Alle Stationen kennen ihre 1-Hop-Nachbarn und kalkulieren zu Beginn
eines Slots mittels einer Pseudo-Hash-Funktion, ob sie berechtigt sind, diesen Slot zu
belegen. Andernfalls ist diese Berechnung zu Beginn des nächsten Slots zu wiederho-
len.
Der Overlay MAC Layer adressiert nicht die hier betrachteten Langstrecken-Punkt-zu-
Punkt-Verbindungen, sondern versucht, Fairness unter den Stationen in einer regulären
WLAN-Zelle herzustellen und Kollisionen zu minimieren. Wie die Ausführungen und
Messungen der Autoren zeigen, werden diese Anforderungen weitestgehend erfüllt. Al-
lerdings unterscheidet sich die Anforderungen des Einsatzszenarios deutlich von denen
in dieser Arbeit formulierten.
3.2. Token Passing für IEEE 802.11
Wie die Autoren in [WB01] und [PKH01] gezeigt haben sowie nach eigener Beobach-
tung des Autors ist das Verhalten der DCF aufgrund der randomisierten Kollisionsver-
meidung keinesfalls vorhersagbar. Kurzfristig und punktuell betrachtet wird das Medi-
um zwischen den beteiligten Stationen nicht fair aufgeteilt und die Sendezeiten können
unterschiedlich lang ausfallen ([Erg02, S. 2]). Aufgrund der Eigenschaften, die Token
Passing-basierte Medienzugriffsverfahren mit sich bringen (Determinismus, Fairness),
wurden bereits einige Versuche unternommen, Token Passing auf WLAN zu portieren.
Damit sollen die zuvor genannten Nachteile ausgeglichen beziehungsweise aufgehoben
werden. Im folgenden Abschnitt sollen einige Verfahren erläutert und deren unterschied-
liche Motivationen und Herangehensweisen aufgezeigt werden.
Wireless Token Ring Protocol
Das Wireless Token Ring Protocol (WTRP) wurde 2001/2002 von den beiden Berkeley-
Absolventen Duke Lee und Mustafa Ergen im Rahmen ihrer jeweiligen Master-Thesis
Stand der Forschung 23
entwickelt und vorgestellt ([Lee01] respektive [Erg02]). Eine weitere Vorstellung als
Konferenzpublikationen sowie eine Analyse der Leistungsfähigkeit erfolgten in [ELSV04]
beziehungsweise [ELSV03].
Wireless Token Ring adressiert die bereits genannten Probleme Fairness und Determinis-
mus. Ebenso werden Dienstgüte-Aspekte wie begrenzte Latenz und zugesicherte Anteile
an der Datenrate angesprochen. In Aufbau und Funktionsweise ist entgegen der Namens-
gebung eine Orientierung des Protokolls an Token Bus (IEEE 802.4) zu beobachten, da
beide Protokolle auf einem Shared Medium agieren müssen. Wie beim Token Bus wird
bei Wireless Token Ring (WTR) über dieses geteilte Medium ein logischer Ring gelegt,
indem jeder Station ihre jeweiligen Vorgänger und Nachfolger mitgeteilt werden. Da-
durch ergibt sich ein doppelt verketteter Ring, anhand dessen die Sendeberechtigung in
Form eines Token von Station zu Station weitergereicht wird.
Für die Verwaltung dieser virtuellen Ringtopologie, also das Hinzufügen und Entfernen
von Stationen an beliebiger Stelle, sehen die beiden Autoren eigene Kontrollnachrichten
vor. Diese sollen auch dazu dienen, verschiedene Fehlersituationen im laufenden Betrieb
beheben zu können, beispielsweise einen lediglich teilweise vermaschten Topologiegra-
phen.
Zu diesem Zweck pflegt der auf jedem Knoten laufende Connectivity Manager eine so
genannte ”Connectivity Table”, in der zu jedem Hop des Tokens die passende Station
festgehalten wird. Anhand einer fortlaufend inkrementierten Sequenznummer im Token-
Paket kann ein Knoten auch Hops erkennen, die außerhalb seiner Empfangsreichweite
liegen. Dadurch kann er zumindest feststellen, wie viele Knoten am Ring beteiligt sind,
auch wenn er nicht alle Knoten sehen kann. Verlässt nun eine Station den Ring, die vor-
her als ”Brücke” zwischen zwei nicht direkt verbundenen Stationen fungiert hat, entsteht
eine Lücke im Ring. Anhand der Connectivity Table können die Knoten links und rechts
der Lücke nun den Ring wieder schließen. Eine genaue Erläuterung hierzu inklusive der
Bei- und Austrittsprozesse findet sich in [LAP+01].
Auf der Webseite der zugehörigen Forschungsgruppe ([Gro]) sind eine Implementierung
von WTR für den Linux-Kernel sowie weitere Werkzeuge rund um das WTR-Protokoll
wie beispielsweise ein Simulator zu finden. Die letzte Aktualisierung auf der Webseite
ist im Jahr 2004 vorgenommen worden, seitdem wurde das Protokoll scheinbar nicht
mehr gepflegt. Daher kann angenommen werden, dass eine Funktionalität auf einem
aktuellen Unterbau bestehend aus einem modernen Linux-Kernel und Hochleistungs-
WLAN-Karten für IEEE 802.11n respektive IEEE 802.11ac nicht ohne umfangreiche
Modifikationen gegeben ist.
Stand der Forschung 24
Virtual Token Passing
Entworfen und vorgestellt von Moares et al. in [MVPF07], stellt das Virtual Token Pas-
sing (VTP) eine Token Passing-Implementierung für Echtzeitverkehr dar, wie er bei-
spielsweise in Industrie- und Steuerungsanlagen eingesetzt wird. Die Autoren halten da-
bei das durch die bei WLAN verwendeten ISM-Frequenzbänder implizierte Prinzip einer
”offenen Kommunikationsumgebung” hoch, d.h. ”jeder neue Teilnehmer kann das Me-
dium benutzen und seine eigenen Kommunkationskanäle aufspannen. Als Konsequenz
kann die Belastung des Mediums weder vorhergesagt noch zur Laufzeit kontrolliert wer-
den.” ([MVPF07, S. 1]). Externe, nicht am virtuellen Ring beteiligte Stationen können
also nicht ohne weiteres von der Mediennutzung ausgeschlossen werden, sondern müs-
sen ebenfalls die Chance erhalten, in einem Wettbewerb Zugriff auf das Medium erlan-
gen und so ihre Nachrichten versenden zu können.
Auf dem Medium konkurrieren folglich Echtzeitteilnehmer (RT) und Standard-Stationen
(ST). Dabei kann auch auf einer RT-Station gleichzeitig Echtzeit- und normaler Ver-
kehr stattfinden. Vor dem Hintergrund von EDCA (802.11e) wird der Echtzeitverkehr
als neue Dienstgüteklasse dargestellt. Ein Kategorisierungsmechanismus (Traffic Sepa-
ration Mechanism (TSm)) unterscheidet Echtzeit- von normalem Verkehr und erlaubt
ersterem den Vortritt. Im Falle von Kollision zwischen RT- und ST-Stationen verwendet
der ST-Teilnehmer das Standard-Backoff-Schema nach DCF beziehungsweise EDCA.
Die RT-Station sendet ihren Echtzeitverkehr im Gegensatz dazu mit der höchstmögli-
chen EDCA-Zugriffsklasse. Die Parameter für Ober- und Untergrenze des Contention
Window werden dabei jeweils auf 0 und AIFS auf 2 gesetzt. Die RT-Station gewinnt in
der Folge in der deutlichen Mehrzahl der Fälle den Wettbewerb um das Medium.
In einer Konkurrenzsituation zwischen zwei RT-Stationen entstehen allerdings weiterhin
Kollisionen. Hierfür beinhaltet VTP eine Token Passing-Prozedur, die diese Sendever-
langen koordiniert und einen Token entlang eines virtuellen Ringes von Station zu Sta-
tion weiterreicht. Die RT-Station, die den Token hält, besitzt das exklusive Senderecht
für Echtzeitverkehr. Betrachtet wird eine sogenannte Prozessgruppe G mit np Stationen
L = NA1,NA2, ...NANP. NAi ist gleichzeitig die Station in G selber und die Stations-ID
als Adresse für den virtuellen Ring. Jede Station führt außerdem einen Adress-Zähler
(ACo) für einen virtuellen Token, der in L zirkuliert.
Sollte der Fall auftreten, dass eine RT-Station den Token hält, aber keine Echtzeitdaten
zu senden hat, erlaubt sie ST-Stationen den regulären Zugriff über EDCA, bis die T XOP
der aktiven RT-Station erreicht ist und sie den Token weiterreichen muss. Wie sich zeigt,
kann auch in großen Umgebungen durch diesen Mechanismus ein stabiles Paket-Delay
(1-2ms) für Echtzeitverkehr erreicht werden, nahezu unabhängig von der tatsächlichen
Netzwerklast.
Stand der Forschung 25
Die Ringverwaltung wurde durch die Autoren zunächst nur statisch angelegt, später wur-
de das Protokoll jedoch um entsprechende Verwaltungsnachrichten ergänzt. VTP un-
terscheidet danach die Nachrichtentypen msg.{REMOVE, JOIN, ADD, UPDATE, HB,
RT}. Mit JOIN, ADD und UPDATE kann eine Station in den virtuellen Ring aufgenom-
men und mit REMOVE wieder entfernt werden. HB sind Heartbeat-Nachrichten und RT
bezeichnet den regulären Echtzeitverkehr.
Der Austritt aus dem Ring wird entweder durch die betreffende RT-Station eigenständig
über eine msg.REMOVE-Nachricht (Autonomer Remove) gestartet, oder, falls diese im
Falle eines Station Crash dazu nicht mehr in der in der Lage ist, durch die Ringverwal-
tung.
Als Vorteil geben die Autoren an, dass aufgrund der beschriebenen Ringverwaltung der
Ring im Falle von Inkonsistenzen im Gegensatz zu anderen Token Passing-Verfahren
nicht von Grund auf neu aufgebaut werden müsse. Auch hätten die Verwaltungsmecha-
nismen nur einen vernachlässigbaren Einfluss auf die Leistungsfähigkeit des Rings. Wie
WTRP konzentriert sich VTP auf die Zugriffsregelung in herkömmlichen Nahbereichs-
WLAN-Zellen. Vermaschte Langstrecken-Netze werden nicht explizit adressiert.
U.S. Patent 6,795,418 B2
Im US-Patent 6,795,418 B2 ([Cho04]) wurde von Sunghyun Choi ein Medienzugriffs-
verfahren patentiert, das nach Aussage des Autors einen Hybriden aus Zeitmultiplex,
Token Passing und Polling darstellt. Den Hauptteil der Funktionsweise nimmt dabei das
Zeitmultiplexverfahren ein. Das Medium wird in Zeitschlitze gleicher Größe eingeteilt
und von einem prädestinierten Master-Knoten anhand eines festgelegten Algorithmus an
die beteiligten Stationen verteilt. Diese Zuordnung wird, neben weiteren Informationen
für beitrittswillige Stationen, zu Beginn einer Senderunde vom Master-Knoten in einem
protokolleigenen Beacon-Frame verteilt. Über den Algorithmus selbst konnte in dem
zitierten Patent nichts gefunden werden.
Als Ergänzung zum Zeitmultiplex sieht das Verfahren zusätzlich einen Token Passing-
und einen Polling-Mechanismus vor, um die Auslastung des Mediums zu erhöhen. Ein
vorzeitiges Übertragungsende wird durch die betreffende Station durch Versenden ei-
nes Token-Frames signalisiert. Da allen Stationen durch den Beacon-Frame ihre Slot-
Zuordnung und damit auch ihre Vorgänger und Nachfolger bekannt sind, kann die nächs-
te Station bereits früher mit ihrer Übertragung beginnen. Es kann allerdings vorkom-
men, dass der nächste Teilnehmer außerhalb der Sendereichweite der Station ist, die
den Token versendet hat. In diesem Fall übernimmt der Master-Knoten eine Art Relay-
Funktion: Er kann die Nachfolgestation aktiv fragen (Polling), ob sie sendebereit ist.
Stand der Forschung 26
Mithilfe des beschriebenen Polling-Mechanismus wird diese Variante des Hidden Terminal-
Problems (siehe [TW12, S. 327f.]) umgangen. Durch die Verwendung eines Zeitmultiplex-
basierten Verfahrens ist - wie bereits weiter oben beschrieben - eine enge zeitliche
Synchronisation zwischen den Stationen notwendig. Wie beziehungsweise mit welchen
Werkzeugen diese durchgeführt werden soll, verschweigt das Patent.
SoftToken
Wie Lucas Eznarriaga und seine Co-Autoren feststellen, bietet EDCA nur propabalis-
tische Garantien, die bei Szenarien mit hoher Netzwerklast nicht mehr zutreffen. Da-
her stellen Eznarriaga et al. SoftToken ([ESB+13]) als Ansatz vor, um Dienstgüte für
WLAN-Verkehr garantieren zu können, einschließlich einer Implementierung als Ker-
nelmodul zwischen Layer 2 und 3. Nach Angabe der Autoren seien keine Firmware-
Modifikationen notwendig und die Kontrolle erfolge über ein interaktives Userspace-
Werkzeug ([ESB+13, S. 4]).
Zur Einordnung von SoftToken ziehen die Autoren einen Vergleich mit WTRP. WTRP
arbeitet als verteiltes Protokoll, SoftToken hingegen zentralistisch in einer Master-Slave-
Architektur. Es wird kein virtueller Ring gebildet. Stattdessen übernimmt die Master-
Station - im Infrastruktur-Modus der Zugangspunkt, im Adhoc-Modus ein beliebiger
Knoten - die Koordination, vergleichbar mit der Contention Free Phase im PCF-Betrieb.
Abbildung 3.2: SoftToken: Kommunikationsablauf zwischen den Stationen (Quelle: [ESB+13])
Anhand einer festgelegten Reihenfolge sendet der Master eine Token-Request-Nachricht
an seine Slave-Knoten. Für jeden Knoten und jede Verkehrsklasse hält er eine separate
Stand der Forschung 27
Queue vor. Im Token Request signalisiert er dem Slave, wie viele Daten dieser je Ver-
kehrsklasse (also Queue) übermitteln darf. Als Antwort nach der Übertragung sendet
der Slave eine Token Response-Nachricht, um deren Ende anzuzeigen. Dieser enthält -
analog zum Token Request - Informationen darüber, wie viele Daten je Queue übermit-
telt wurden und wie viel verbleibt. Der Master kann nun seinerseits Daten übertragen
oder per Token Request-Nachricht dem nächsten Slave-Knoten Sendeberechtigung er-
teilen.
Die Evaluierung der Autoren zeigt, dass IEEE 802.11a in einer Zwei-Knoten-Umgebung
bessere Ergebnisse für die Nutzdatenrate liefert als SoftToken, allerdings einhergehend
mit im Vergleich deutlich höherem Paketverlust. Ein weiterer Vorteil von SoftToken ist
ein bei bidirektionalem Verkehr stabiles Verhältnis zwischen Down- und Uplink. Die
RTT ist für Echtzeitverkehr (VoIP) ebenfalls stabil.
3.3. Token Passing für IEEE 802.11 WiLD PtP
Im vorigen Abschnitt wurden Protokolle vorgestellt, die einen Token Passing-Mecha-
nismus auf herkömmlichen WLAN-Funknetzen (Kurzstrecke, Punkt-zu-Multipunkt) als
Medienzugriffskontrolle implementiert haben, um allen beteiligten Stationen einen fai-
ren Zugriff auf das Medium zu ermöglichen. Ähnliche Protokolle für Langstrecken-
Punkt-zu-Punkt-Verbindungen existieren ebenfalls und werden mit ihren Eigenschaften
und einschließlich der Motivation der Entwickler im folgenden Abschnitt erläutert.
2P
In großen Mesh-Netzwerken kann es notwendig sein, dass mangels ausreichend freier
Kanäle mehrere Funkmodule eines Knotens auf der gleichen Frequenz operieren müs-
sen. Das führt zwangsläufig zu (Selbst-)Interferenzen, falls keine Koordinierung der Mo-
dule stattfindet, selbst für den Fall, dass stark gebündelte Richtantennen eingesetzt wer-
den. Letztere strahlen nicht nur in entlang der Hauptkeule, sondern verfügen in der Regel
aufgrund ihres Aufbaus auch über Seitenkeulen (side lobes), die in andere Richtungen
zeigen (vgl. hierzu auch [Rec12, S. 334]).
Daher ist es erforderlich, die Funkmodule untereinander zu koordinieren, um die Sende-
und Empfangsphasen zu synchronisieren (SynTX, SynRX). Dies wird auch als Synchronous
Operations (SynOP) bezeichnet. Bhaskaran Raman und Kameswari Chebrolu haben
hierzu das Protokoll 2P entworfen und in [RC05] vorgestellt.
Wenn alle Funkmodule eines Knotens senden, sollten die zugehörigen Nachbarknoten
im Empfangsmodus sein und umgekehrt (siehe Abbildung 3.3a). Auch beim Wechsel
Stand der Forschung 28
(a) Synchrone Operation (b) Zustandsautomat
Abbildung 3.3: 2P: Protokolldetails (Quelle: [RC05])
von einem Modus in den anderen müssen die Module auf den Nachbarknoten mit wech-
seln. Die Menge der Knoten lässt sich folglich in zwei komplementäre Teilmengen un-
terteilen, der Topologiegraph muss bipartit sein. Jeder Knoten, auf dem 2P installiert ist,
unterhält zu diesem Zweck einen Zustandsautomaten mit den zwei Zuständen SynTX
und SynRX wie in Abbildung 3.3b gezeigt. Dieser startet im Sendemodus und verweilt
solange in diesem, bis B Bytes gesendet wurden. Ein ”Marker-Paket” getauftes Token
leitet den Wechsel in den Empfangszustand ein. Dieser wird solange gehalten, bis erneut
ein Marker-Paket vom Link-Nachbar empfangen oder ein Timeout erreicht wurde.
Für die Netzwerktopologie werden von den Entwicklern zwei Restriktionen aufgestellt,
zum einen bezüglich der bereits erwähnten Bipartität, zum anderen regelt eine ”power
constraint”, welche Sendeleistung eine Funkschnittstelle zwecks Vermeidung von Inter-
Link-Interferenzen maximal verwenden darf. Zur Erzeugung einer passenden Topolo-
gie wird außerdem ein heuristischer Algorithmus angegeben. Unter der Einschränkung,
dass keine Wegefindung über mehrere Pfade stattfinden soll, ist eine Baumstruktur aus-
reichend und trivialerweise bipartit. Weitere Links können aus Redundanzgründen ein-
gefügt werden, verbleiben aber inaktiv. Der Algorithmus erstellt stufenweise einen auf-
spannenden Unterbaum und verwendet dabei drei Heuristiken:
• H1: Links minimaler Länger verwenden: Längere Links können aufgrund ihrer
Länge mit mehr Links in der Umgebung interferieren als kurze.
• H2: Spitze Winkel zwischen Links vermeiden: Die Seitenkeulen sind nach Beob-
achtung der Autoren bei größerem Winkel geringer
• H3: Hop Count reduzieren: Vermeide tiefe Bäume, da mit jedem Hop die Latenz
steigt
Alternativ wird die Netzwerktopologie in mehrere bipartite Untergraphen aufgeteilt, auf
denen mehrere 2P-Instanzen auf unterschiedlichen Kanälen operieren.
Stand der Forschung 29
Neben einer Simulation verwenden die Autoren eine Testbed-Implementierung, um die
Leistungsfähigkeit von 2P zu beurteilen. Das Testbed besteht aus zum Veröffentlichungs-
zeitpunkt aktuellen Hardware- und Softwarekomponenten, unter anderem WLAN-Schnitt-
stellenkarten mit Prism2-Chipsatz und einem modifizierter HostAP auf einem Linux mit
Kernel 2.4.
2P adressiert mit der Konzentration auf den SynOP-Betrieb bei Einkanal-Betrieb eine
ähnliche, aber etwas andere als die in dieser Arbeit verfolgte Problemstellung. Die ge-
gebene Implementierung ist zudem veraltet und nicht ohne Anpassungen auf aktuelle
Hardware und Software portierbar. Verkehrsgüte wird ebenfalls nicht angesprochen.
JazzyMAC
Sergiu Nedevschi hatte im Jahr 2007 als Coautor von Rabin Patra mit WiLDNet ([PNS+07])
bereits eine verbesserte Variante von 2P auf der Basis eines herkömmlichen Zeitmultiplex-
Verfahrens vorgestellt. Im Jahr 2008 folgte die Veröffentlichung des Protokolls Jazzy-
MAC ([NPS+08]), das die auch oben schon aufgezeigten Nachteile ausgleichen und
damit erneut eine Verbesserung von 2P darstellen soll.
Es handelt sich dabei wie 2P um ein Token Passing-basiertes Einkanal-SynOP-Protokoll
für vermaschte Langstrecken-Punkt-zu-Punkt-Verbindungen. Wie zuvor ist der Entwurf
des Protokoll nicht auf einen einzelnen Link fokussiert. Stattdessen wird versucht, eine
optimale Lösung für das gesamte Netzwerk zu finden.
Konkret soll eine Verbesserung durch folgende Hauptmerkmale erreicht werden:
• Überlappende Übertragungen: Angenommen, zwei Knoten A,B sind benachbart
und A beendet seine Übertragung vor dem Ende des Übertragungsschlitzes, dann
kann B für nicht interferierende Links schon mit dem Senden beginnen, obwohl
A ebenfalls noch in der SynTX-Phase ist.
• Adaptive Sendeschlitzlängen: Jeder Knoten kann pro Link die Slotlänge variabel
an das vor Ort gemessenen und/oder geschätzte Verkehrsaufkommen anpassen.
Hieraus soll eine effizientere Nutzung der Übertragungszeit und damit eine Erhö-
hung des Durchsatz resultieren. Außerdem erhoffen sich die Autoren hiervon eine
größere Flexibilität bezüglich des Kompromisses zwischen Durchsatz und Latenz.
• Unterstützung beliebiger Topologien: Statt lediglich einen Unterbaum zu errech-
nen (trivialerweise bipartit) und so potenziell viele Links nicht zu berücksichtigen,
errechnet JazzyMAC über einen Maximalen Schnitt einen maximalen bipartiten
Untergraphen.
Stand der Forschung 30
Da JazzyMAC überlappende Übertragungen unterstützt, reicht der einfache SynOP-
Mechanismus von 2P nicht mehr aus. Um dennoch einen konsistenten und kollisions-
freien Betrieb zu ermöglichen, haben die Autoren vier Regeln aufgestellt:
1. Token-Austausch: Jeder Token besitzt über eine Timeout-Zeit (ttimeout) einen Gül-
tigkeitsstempel in der Zukunft. Empfängt eine Station den Token zum Zeitpunkt
t, darf sie erst zu t + ttimeout mit dem Senden beginnen.
2. Modus: Jeder Knoten kann nur global, also für alle Links in SynTX wechseln,
wenn er einen Token empfängt. Das heißt, er kann also erst dann in den SynTX-
Modus wechseln, wenn er für alle seine Links gleichzeitig den Token hält. Glei-
ches gilt für den Wechsel nach SynRX.
3. Übertragung: Ein Knoten A kann auf einem Link AB nur senden, wenn er (1) im
Modus SynTX ist und (2) den Token für den Link hält und dieser gültig ist.
4. Zeitschlitz: Jeder Knoten kann pro Link niemals am Stück länger übertragen als
tmax.
Abbildung 3.4: JazzyMAC: Überlappende Übertragung (Quelle: [NPS+08])
Die genaue Funktionsweise der überlappenden Übertragung mit Token-Transfers wird
noch einmal in Abbildung 3.4 grafisch aufgearbeitet. Auf der linken Seite ist eine Bei-
spieltopologie mit drei Knoten (A,B,C) zu sehen. Die Topologie ist vollvermascht und
daher trivialerweise nicht bipartit. Auf der rechten Seite sind die Übertragungsrichtun-
gen und -modi jeweils der Links und Knoten dargestellt. Der zeitliche Verlauf ist in der
Senkrechten aufgetragen.
Initial hält Knoten A die Token für die Links AB und AC und Knoten B hält den Token
Stand der Forschung 31
für den Link AC. A hält die Knoten für alle seine Verbindungen und kann daher in den
Sendemodus wechseln, da er davon ausgehen kann, dass alle seine Nachbarn im Emp-
fangsmodus sind. A sendet gleichzeitig auf beiden Links, allerdings ist die Übertragung
auf der Strecke A↔ B früher (t = 15) zu Ende. Folglich erhält B den Token für A↔ B
und kann, obwohl A noch in SynTX ist, ebenfalls mit dem Senden beginnen, da er die
Token für alle seine Links hält. C ist somit der einzige Knoten, der in SynRX verbleibt.
Sobald A mit seiner Übertragung an C fertig ist und den Token überstellt hat, kann C in
den Sendemodus gehen und an A Daten übertragen. Zu B darf er erst senden, wenn dieser
den Token zu t = 60 übergeben hat. Entsprechend setzt sich die Übertragung fort.
Bei JazzyMAC handelt es sich zwar um ein verteilt agierendes Protokoll, da jeder Kno-
ten und jedes durch einen Link verbundenes Knotenpärchen unabhängig von den jeweils
anderen Knoten respektive Knotenpärchen agieren. Beim Bootstrapping des Protokolls
wird allerdings durch einen zentralen Algorithmus eine initiale Tokenzuweisung für je-
den Link errechnet, da eine verteilte Berechnung unter Umständen zu Blockierungen
oder Unfairness führen könnte. Dieser muss ein Ergebnis liefern, dass die Anforderun-
gen Blockierungsfreiheit und Unfairness-Freiheit (von den Autoren als ”starvation free”
bezeichnet) erfüllt und zudem für jeden Link über eine untere Schranke für die minima-
le Sendezeit jedes der beiden Knoten sowie eine obere Schranke für die Latenz verfügt.
Die Erfüllung dieser Anforderungen wird von den Autoren in der Veröffentlichung auch
bewiesen.
Die Evaluierung der Autoren zeigt eine Überlegenheit in puncto Durchsatz und Latenz
im Vergleich zu anderen Zeitmultiplex-Langstrecken-Punkt-zu-Punkt-Protokollen. Al-
lerdings unterwirft sich JazzyMAC wie 2P dem reinen Einkanal-Betrieb und den damit
einhergehenden Beschränkungen (SynOP). Zudem steht ein Vergleich mit IEEE 802.11n
noch aus.
3.4. Zusammenfassung
2P und JazzyMAC haben als Multi-Radio-Single-Channel-Protokolle eine andere Moti-
vation als hier gefordert, namentlich die Synchrone Operation bei Betrieb des gesamten
Netzwerkes über nur einen Funkkanal. Die Koordintation der einzelnen Stationen besetzt
also eine wichtige Rolle beim Entwurf und Betrieb des Protokolls. Im vorliegenden Fall
ist eine Koordination über das gesamtes Netzwerk nicht notwendig, da für diese Arbeit,
wie in den Prämissen im folgenden Abschnitt beschrieben, eine interferenzfreie Kanal-
zuweisung vorausgesetzt wird. Außerdem ist denkbar, dass ein Token Passing-Protokoll
je nach Anforderung nur auf einem Teil der Punkt-zu-Punkt-Verbindungen eines ver-
maschten Netzwerkes eingesetzt wird. Allerdings finden sich in beiden Protokollen wie
übrigens auch in SoftToken viele sinnvolle Lösungen für Teilprobleme, beispielsweise
Stand der Forschung 32
die Verbindungswiederherstellung von 2P und JazzyMAC, die in ähnlicher Form bereits
schon im vorangegangenen Masterprojekt des Autors umgesetzt wurde.
Auch WTR und VTP sind ebenfalls vielversprechende Verfahren. Ein aufwändiges Ring-
management, gemeinsames Hauptmerkmal der beiden Protokolle, ist aus Sicht des Au-
tors bei Punkt-zu-Punkt-Verbindungen nicht notwendig, da lediglich zwei Stationen be-
teiligt sind.
Alle vorgestellten Protokolle wurden vor der Standardisierung von IEEE 802.11n ver-
öffentlicht. Daher bleiben einige relevante Neuerungen, die die Steigerung des Durch-
satzes betreffen, nicht berücksichtigt, beispielsweise Framme Aggregation und Block
Acknowledgements. Insofern ist zu diskutieren, ob eine Leistungssteigerung durch ein
neues Token Passing-Protokoll erreicht werden kann und falls ja, wie hoch der zu erwar-
tende Gewinn ausfällt.
Entwurf des Protokolls 34
4. Entwurf des Protokolls
Im vorangegangenen Kapitel 3 wurde der Stand der Forschung der Medienzugriffspro-
tokolle mit gesteuertem sowie mit Token Passing-basiertem Zugriff für IEEE 802.11
insbesondere für Langstrecken-Punkt-zu-Punkt-Verbindungen aufgezeigt. Wie ebenfalls
erläutert wurde, unterscheiden sich die verschiedenen Ansätze und Motivationen, die
zum Entwurf dieser Protokolle geführt haben, von den in dieser Arbeit formulierten An-
forderungen.
Im vorliegenden Kapitel wird auf Basis dieser Anforderungen ein optimiertes Protokoll
mit der Bezeichnung WiLDToken entwickelt und vorgestellt. WiLDToken soll dabei oh-
ne Beschränkung durch externe Einflussfaktoren (Hard-/Software-Abhängigkeiten, ...)
geplant werden und sich transparent in die bestehende Architektur von 802.11 einfü-
gen. Dabei wird auch aufgezeigt, wie die einzelnen Teile des Protokolls die erwarteten
Optimierungen erreichen sollen.
4.1. Anforderungen und Prämissen
Vor der Entwicklung des Protokolls werden im folgenden Abschnitt zunächst die oben
beschriebenen Anforderungen verfeinert, um einen Ausgangs- und Bezugspunkt für den
Entwurf von WiLDToken zu setzen.
4.1.1. Prämissen
In Kapitel 3.3 wurden bereits die Protokolle 2P und JazzyMAC als Token Passing-
basierte Protokolle für WLAN-Langstrecken-Punkt-zu-Punkt-Verbindungen vorgestellt.
Deren Hauptzweck ist nach Angaben der Autoren die Vermeidung von Inter-Link-Inter-
ferenzen in vermaschten Funknetzen, in denen alle Stationen den gleichen Kanal ver-
wenden (Single Channel Wireless Mesh Network (SC-WMN)). Durch eine entsprechen-
de Synchronisation der Knoten soll so eine Stabilisierung und Optimierung der Daten-
rate erreicht werden.
Durch die Ausweitung auf das 5-Gigahertz-Band mit 802.11a stehen allerdings ausrei-
chend Kanäle zur Verfügung. Daher wird als Prämisse eine weitestgehend interferenz-
freie Kanalzuweisung auf allen Links des betrachteten Wireless Mesh Network (WMN)
vorausgesetzt. Abgesehen von externen Einflussfaktoren wie anderen Sekundärnutzern
Entwurf des Protokolls 35
des Frequenzbandes sollten sich damit beide Stationen eines Punkt-zu-Punkt-Links ge-
meinsam in einer eigenen Funkzelle befinden. Das Problem der Kanalzuweisung ist kei-
neswegs trivial und lässt sich beispielsweise auf das Kantenfärbungsproblem für un-
gerichtete Graphen abbilden (vgl. [Kar72, S. 85-103]). Entsprechende Lösungsansät-
ze werden beispielsweise von Alicherry, Bhatia und Li ([ABL05]) oder Ramachandran
([RBRAB06]) vorgestellt.
Da eine interferenzfreie Kanalzuweisung vorausgesetzt wird, ist eine Fokussierung auf
SynOP zur Vermeidung von Inter-Link-Interferenzen für die vorliegende Arbeit nicht
mehr notwendig. Daher stellen die beiden oben genannten Protokolle allenfalls eine er-
gänzende Quelle für Anregungen im Protokollentwurf dar.
4.1.2. Leistungsfähigkeit
Die Leistungsoptimierung für WLAN-basierte Langstrecken-Punkt-zu-Punkt-Verbindun-
gen durch Implementierung eines Token Passing-Protokolls stellt den Fokus der vorlie-
genden Arbeit dar. Entsprechend werden im folgenden Abschnitt Anforderungen an die
Leistungsfähigkeit des Protokolls WiLDToken formuliert.
Datenrate Beim Einsatz als Backhaul-Link innerhalb eines WMN ist die verfügba-
re Datenrate für WISP ein aus Betriebskostensicht ausschlaggebender Faktor. Je höher
die Datenrate einer Verbindung, desto mehr Endnutzer lassen sich über diese anbin-
den. Entsprechend sinken die Betriebskosten (Operational Expenditure (OPEX)) für den
WISP.
In der Arbeit von Rademacher (vgl. [Rad15]) wurde durch eine adäquate Wahl des Con-
tention Windows sowie der Anpassung protokollinterner Timings (ACK Timeout, Slot
Time) bereits eine Steigerung der Datenrate für Punkt-zu-Punkt-Langstreckenverbindun-
gen erreicht. Wie dort gezeigt wurde, werden diese Timings maßgeblich durch die län-
gere Signallaufzeit beziehungsweise Ausbreitungsverzögerung bei Langstreckenverbin-
dungen beeinflusst.
Durch Wegfall der Contention-Phase, an der die Timings maßgeblich beteiligt sind, die
Kollisionsfreiheit des Token Passing-Protokolls sowie Piggybacking der Empfangsbe-
stätigung soll die erwünschte Steigerung der Effizienz und damit auch der Datenrate
gerade bei großen Distanzen erreicht werden.
Entwurf des Protokolls 36
Verzögerung und Jitter Insbesondere für Anwendungen mit Anforderungen an die
Dienstgüte (QoS) wie Echtzeit-Sprach- oder Videokommunikation ist die Latenz als
Summe der Verarbeitungs- und Ausbreitungszeiten einer Übertragungseinheit (Packet)
von der Quelle zum Ziel ausschlaggebend. Die internationale Telekommunikationsunion
ITU-T erklärt Echtzeitkommunikation bei Latenzen über 250 ms als eingeschränkt und
bei mehr als 400 ms als unbrauchbar ([IT00, S. 2f.]). Auch große Schwankungen in der
Latenz (Jitter) gelten laut ITU-T als Störfaktor und ”sollten vor der Wiedergabe für den
Benutzer” mit geeigneten Maßnahmen entfernt werden (vgl. [IT00, S. 7]).
Wie Jörg Rech bemerkt, ist die Latenz ebenfalls relevant für die Überlastkontrolle von
TCP. Letztere könnte eine beispielsweise durch Retransmissions erhöhte Latenz als
”Verstopfung (...) interpretieren” und damit unnötigerweise ebenfalls Retransmissions
auf der Transportschicht veranlassen ([Rec12, 449ff.]). Im Quality of Service (QoS)-
Tutorial zu 802.11 stellen Smith et al. fest, dass bei Daten gleicher Verkehrsklasse we-
der ”Bandbreite” noch Latenz, Jitter oder überhaupt eine Zugriffsberechtigung auf das
Medium garantiert werden können ([SVR+08, S. 12]). Ausschlaggebend hierfür ist der
wahlfreie, randomisierte Medienzugriff der EDCA, bei dem keine Koordinierung der
Stationen (untereinander) stattfindet.
Beim Ansatz der DCF-Optimierung ist wie beschrieben eine distanzabhängige Vergröße-
rung der Slotzeiten notwendig. Da je Sendevorgang im Schnitt mehr als ein Contention-
Slot gewartet werden muss, geht die Ausbreitungsverzögerung hier mehrfach in die La-
tenz ein. Der Einsatz eines Token Passing-Protokolls wie WiLDToken erfordert hingegen
keine distanzabhängigen Anpassungen der Slotzeit, daher ist die Ausbreitungsverzöge-
rung hier im Idealfall nur einmal in der Latenz enthalten. Folglich ist zu erwarten, dass
Latenz und Jitter geringer und stabiler ausfallen.
Fairness und Linkasymmetrie Als Fairness zwischen den Stationen ist die Auf-
teilung der zur Verfügung stehenden Übertragungskapazität zu gleichen Teilen auf die
beiden Knoten der Punkt-zu-Punkt-Verbindung zu bezeichnen. Im Normalfall, das heißt
ohne gezielte Verschiebung der Aufteilung aus Gründen der Verkehrsoptimierung, sollte
jede der beiden Stationen gleich viel Sendezeit erhalten. Voraussetzung ist, dass beide
Stationen ausreichend Daten sendebereit haben.
Die DCF kann allerdings aufgrund der Zufallskomponente keine deterministische Zusi-
cherung für einen bestimmten Zeitraum liefern, sondern lediglich einen Erwartungswert
für t → ∞. Für einen bestimmten Zeitabschnitt kann es daher durchaus zu ungewollten
Verschiebungen der Linksymmetrie zugunsten eines der beiden Knoten kommen, wenn
eine der beiden DCF-Entitäten eine Reihe niedriger oder hoher Backoff-Zeiten würfelt.
Entwurf des Protokolls 37
Die DCF kann folglich, obwohl langfristig Fairness entsteht, kurzfristig unfair agieren,
wie bereits in einer vorangegangen Arbeit beobachtet wurde ([Cha15, S. 39ff.]).
Dort wurde ebenfalls angedeutet, dass eine Token Passing-basierte Lösung Fairness zwi-
schen beiden Stationen garantieren kann. Das wird durch auf beiden Seiten identisch
gesetzte Sendelimits für die Token-Weitergabe erreicht.
Wie in der Einleitung beschrieben, ist unter anderem die Optimierung von 802.11 für den
Einsatz auf kabellosen Backhaul-Verbindungen die Motivation für diese Arbeit. Damit
sollen ländliche und abgelegene Regionen eine Internet-Anbindung erhalten. Üblicher-
weise weist der Verkehr zwischen Endkunden und Backbone-Netz ein asymmetrisches
Verkehrsverhalten auf (vgl. beispielsweise ADSL); für den Downstream ist in der Regel
ein breites Band und somit eine höhere Datenrate vorgesehen als für den Upstream.
Durch gezielte Anpassung der Token-Sendelimits kann das Verhältnis der beiden Daten-
ströme (Hin- und Rückrichtung) verschoben und so gezielt eine Asymmetrie des Links
erzeugt werden. Dies wurde ebenfalls bereits in [Cha15, S. 39ff.] gezeigt. Dadurch kann
der Link an das Verkehrsverhalten angepasst werden. Durch den Einsatz eines adaptiven
Algorithmus könnte flexibel ohne zusätzliche Einwirkungen von außen auf Änderungen
des Verkehrsverhaltens reagiert werden.
Das im Abschnitt 4.2 beschriebene Token-Passing Protokoll WiLDToken soll also für
Fairness zwischen den beiden Stationen auf der Punkt-zu-Punkt-Verbindung sorgen.
Weiterhin soll eine Anpassung der Linksymmetrie an das Verkehrsverhalten auf dem
Link möglich sein.
Dienstgüte Üblicherweise werden auf einer Verbindung der Schicht 2 nicht nur Pa-
kete eines einzigen Dienstes beziehungsweise einer einzigen Verkehrsklasse übertra-
gen. Stattdessen teilen sich mehrere Dienste der oberen Schichten die gleiche Schicht
2-Verbindung. Unter Umständen ist es notwendig, dass einzelne Dienste über die Zusi-
cherung von Dienstgüte-Merkmalen (QoS) bevorzugt behandelt werden.
Zu diesem Zweck wurde mit IEEE 802.11e EDCA vorgestellt. EDCA unterscheidet ver-
schiedene (insgesamt vier) Verkehrsklassen für Sprache, Video, Hintergrund- sowie Best
Effort-Verkehr. Diese residieren innerhalb der EDCA-Protokollentität als eine Art paral-
leler und voneinander unabhängige DCF-Warteschlangen mit individuellen Einstellun-
gen für Contention Window, TXOP und AIFS. Die Abstufung der Dienstgüte erfolgt da-
bei über genau diese unterschiedlichen Parametrisierungen, die Zuordnung der einzelnen
Datenframes über ihre Klassifizierung im Ethernet-Header (DiffServ) (vgl. [IEE12b, S.
820f.]).
Entwurf des Protokolls 38
Mit WiLDToken wird, wie bereits oben besprochen, der gesamte Teil der Medienzu-
griffsschicht, der die DCF und EDCA enthält, durch ein Token Passing-Protokoll er-
setzt. Um trotzdem weiterhin QoS anbieten zu können, wird folglich ein alternativer
Mechanismus benötigt. Dieser kann beispielsweise die Klassifizierungs- und Priorisie-
rungsvorgaben von EDCA aufgreifen und an das Token Passing-Verfahren anpassen.
4.1.3. Verwaltung
Eine wesentliche Charakterisik von 802.11 bzw. der DCF im Speziellen ist die Verwen-
dung des wahlfreien Medienzugriffverfahrens CSMA/CA. Durch die Wahlfreiheit des
Verfahrens ist auf den einzelnen Knoten keine besondere Intelligenz zur Koordinierung
der Medienzugriffe nötig. Dies ist sicher auch in Teilen der Tatsache geschuldet, dass
802.11 auf dem lizenzfreien ISM-Bändern mit einer unbekannten Anzahl an anderen
Sekundärnutzern einigermaßen fair um das Medium konkurrieren muss. Um dennoch
eine Assoziierung mehrerer Stationen realisieren zu können, wurde auf übergeordneter
Ebene das Konzept des Basic Service Set eingefügt.
Beim Austausch der DCF gegen ein gesteuertes Medienzugriffsverfahren wie Token Pas-
sing wird die gerade beschriebene Randomisierung gegen eine gezielte Koordinierung
der Medienzugiffe unter den einzelnen Stationen ausgetauscht. Das zustandslose CS-
MA/CA wird durch eine zustandsbehaftete Protokollentität ersetzt.
Verbindungsauf- und abbau Um beide Stationen des betrachteten Punkt-zu-Punkt-
Links jeweils in einen definierten, abgestimmten Zustand zu versetzen, ist folglich eine
initiale Synchronisierung notwendig. Diese stellt sicher, dass sich beide Stationen in
einem Status befinden, der den vorher festgelegten Regeln (Zustandsautomat) nicht wi-
derspricht.
Ein weiterer Zweck dieser Synchronisierung ist, dass die zwischen den beiden Stationen
ausgetauschten Token-Pakete nur von den richtigen Teilnehmern ausgewertet werden.
Diese Feststellung muss sich gegen die Überlegung wehren, ob eine reine Schicht-2a-
Funktionalität nicht ausreichend wäre, da Stationen alleine auf dem Link kommunizie-
ren. Dennoch kann in der Realität der Fall auftreten, dass (obwohl dieses oben in den
Prämissen ausgeschlossen wurde) wider Erwarten eine dritte Token Passing-Station mit-
hört. Die wechselseitig versendeten Token können hier zu unvorhersehbarem Verhalten
führen. Dieser Fehlerfall kann durch eine initiale Synchronisation respektive Assoziie-
rung der beiden Stationen abgefangen werden.
Entwurf des Protokolls 39
Die Synchronsierung auf dieser niedrigen Ebene ersetzt allerdings nicht die Bildung
eines BSS im Adhoc- oder Infrastruktur-Modus. Dieses erfüllt weitere Verwaltungszwe-
cke, beispielsweise Verschlüsselung und Authentifizierung.
Kon�guration zur Laufzeit Im laufenden Betrieb kann es notwendig sein, gezielt
Protokollparameter anzupassen. Hierzu zählt das Einstellen von Sendelimits ebenso wie
eine Justierung der Linksymmetrie oder QoS-Einstellungen.
Zu diesem Zweck sollte das Protokoll eine Schnittstelle vorsehen, über die solche Än-
derungen zur Laufzeit eingespielt und wirksam gemacht werden können. Ebenso ist zu
entscheiden, ob die geänderten Parameter aus der Laufzeitkonfiguration (Running Con-
fig) persistent in die Grundkonfiguration (Startup Config) übernommen werden sollen.
4.1.4. Fehlertoleranz
Neben seiner Leistungsfähigkeit ist ein weiteres Merkmal eines Protokolls seine Tole-
ranz gegenüber extrinsischen und intrinsischen Fehlern. Hierbei spielt insbesondere die
Art und Weise, wie eine solche Fehlersituation aufgelöst, das heißt bereinigt oder kom-
pensiert wird, eine Rolle. Im Folgenden werden zwei wesentliche Fehlersituationen, der
Verlust von Daten- respektive Verwaltungspaketen, beschrieben und ihre Bereinigung in
802.11 und WiLDToken aufgeschlüsselt.
Verlust von Datenpaketen Um eine vergleichbare Effizienz wie WLAN zu errei-
chen, ist es für WiLDToken unumgänglich, einen blockweisen Bestätigungsmechanis-
mus einzusetzen. Das Bestätigungspaket ist außerdem verhältnismäßig klein (14 Byte
Header zuzüglich 64 Bit Bitmap bei Compressed Block Ack), zusammen mit den durch
die Ausbreitungsverzögerung bedingt langen Wartezeiten ergibt sich eine geringe Medi-
enauslastung. Um die Auslastung weiter zu erhöhen, kann folglich über eine effizientere
Gestaltung dieses Mechanismus, beispielsweise über Piggybacking, nachgedacht wer-
den.
Verlust von Verwaltungspaketen Nicht nur Daten-, sondern auch Verwaltungspa-
kete können durch die diversen Störeinflüsse verloren gehen oder korrumpiert werden.
Durch diesen Verlust gerät die Synchronisation der beiden Knoten, also die Abstimmung
der Zustandsautomaten, in eine Schieflage. Der sendende Knoten hat seinen Token ab-
gegeben und besitzt folglich keine Sendeberechtigung mehr. Auf der anderen Seite hat
der empfangende Knoten keinen Token erhalten, hat also auch keine Möglichkeit, den
Verlust des Tokens anzuzeigen.
Entwurf des Protokolls 40
Diese Fehlersituation muss durch eine Fallback-Möglichkeit aufgefangen werden. Eine
Möglichkeit wäre, dass der Sender den Token nicht verwirft, ehe eine Bestätigung durch
den Empfänger erfolgt ist. In diesem Fall halten allerdings beide Knoten temporär einen
Token. Eindeutigkeit, wer die Sendeberechtigung hat, ist so nicht mehr gegeben.
Weitaus konservativer ist hingegen die Verwendung eines Fallback-Zustands. Falls der
sendende Knoten feststellt, dass der Token verloren gegangen ist, beispielsweise durch
Ausbleiben einer Bestätigung, geht er davon aus, dass die Verbindung nicht mehr syn-
chron ist. Gleiches gilt für den empfangenden Knoten: Stellt dieser fest, dass innerhalb
eines vorgegebenen Zeitraums kein Token empfangen wurde, muss auch er davon aus-
gehen, dass die Verbindung korrumpiert wurde. Als Konsequenz muss der Synchronisa-
tionsvorgang neu angestoßen werden.
Ein Nachteil dieser Methode ist, dass während der erneuten Synchronisation der Link
nicht für Datenübertragungen zur Verfügung steht. Außerdem müssen je nach Umset-
zung bereits gesendete Pakete erneut verschickt werden.
4.1.5. Sicherheit
Im Vergleich zu kabelgebundenen Verbindungen, bei denen ein direkter physischer Zu-
gang zum Medium notwendig ist, lassen sich drahtlose Übertragungen deutlich einfacher
abhören oder kompromittieren. Dadurch ist insbesondere die Vertraulichkeit der übertra-
genen Daten gefährdet. Als wirksamer Schutz gegen dieses Abhören kann auf die Daten
ein Verschlüsselungsalgorithmus angewendet werden, dessen Geheimnis nur Sender und
Empfänger bekannt ist.
Eine solche Verschlüsselung wird bei WLAN in verschiedenen Formen bereits seit län-
gerem unterstützt. Das Geheimnis kann dabei entweder im Vorhinein (Pre Shared Key
(PSK)) festgelegt und den Beteiligten bekannt gegeben als auch zwischen AP und Client
individuell ausgehandelt werden (802.1X/Radius).
Insbesondere für Langstrecken-Punkt-zu-Punkt-Verbindungen, die als Backhaul-Link
eingesetzt werden sollen, ist Sicherheit ein kritischer Faktor. Die Verbindung dient in
diesem Fall als Transportmittel für die aggregierten Datenströme mehrerer individueller
Nutzer, die auch persönliche Daten enthalten können.
Daher ist die Frage zu beantworten, ob und wie diese Sicherheit auch mit dem neu zu
entwerfenden Protokoll gewährleistet werden kann. Als Argumentation kann hier ange-
führt werden, dass mit dem optimierten Protokoll WiLDToken ausschließlich der Teil
des MAC-Layers ersetzt werden soll, der den eigentlichen Medienzugriff regelt. Die
Verschlüsselung liegt oberhalb des Medienzugriffs und sollte daher transparent sein.
Entwurf des Protokolls 41
(a) DCF (nach [IEE12b, S. 874]) (b) WiLDToken (nach eigener Darstellung)
Abbildung 4.1: Vergleich: Queueing in DCF und WiLDToken ohne QoS
4.2. Protokollablauf
Nachdem alle Prämissen und Anforderungen an das Protokoll formuliert sind, werden in
den folgenden beiden Abschnitten 4.2 und 4.3 die Details von WiLDToken erarbeitet.
Ausgangspunkt für Abschnitt 4.2 ist eine einzelne WiLDToken-Protokollinstanz. Diese
Protokollentität arbeitet als einer von zwei Endpunkten einer Verbindung und hält für
diese jeweils die Konfiguration und den aktuellen Zustand vor. Daher handelt es sich bei
WiLDToken um ein zustandsorientiertes Protokoll.
In diesem Abschnitt werden zunächst die internen Abläufe innerhalb der Protokollenti-
tät sowie der Datenfluss durch den Protokollstapel beschrieben. Dabei werden auch die
zugehörigen Timings und notwendige Merkmale wie Aggregierung und Empfangsbe-
stätigung angesprochen.
4.2.1. Daten�uss
Wie in Teilabbildung 4.1a gezeigt, werden in IEEE 802.11 ohne Dienstgüte-Erweiterung
alle ausgehenden Pakete zunächst in einer FIFO-Warteschlange (Transmit Queue) zwi-
schengespeichert. Sobald die zugehörige DCF-Entität das Senderecht gewonnen hat,
werden der Queue solange Pakete entnommen, bis eins der festgelegten Limits (4 ms/64
KiByte/64 MPDUs) erreicht ist. Alle nicht übertragenen Pakete werden bis zum nächsten
Gewinn der Sendeberechtigung gespeichert. Der eingehende Verkehr wird auf Verwal-
tungspakete überprüft. Diese werden durch die zugehörigen Protokoll-Teilfunktionen
ausgewertet. Datenpakete werden ausgepackt und an die nächsthöhere Schicht weiterge-
reicht.
Entwurf des Protokolls 42
Teilabbildung 4.1b zeigt, dass auch WiLDToken in Grundform auf die gleiche Weise ar-
beitet. Ausgehende Pakete werden in einer Warteschlange gesammelt, bis der Knoten auf
dem zugehörigen Link die Sendeberechtigung erhält. Danach werden der Queue solange
Pakete entnommen, bis das zuvor festgelegte Sendelimit (TXOP, vgl. Abschnitt 4.2.3)
erreicht ist.
Alle eingehenden Pakete werden zusätzlich auf Signalisierungspakete (Token) geprüft.
Diese werden aus dem Paketstrom ausgegliedert. Falls zusätzliche Verwaltungsinforma-
tionen enthalten sind, werden diese ausgewertet. Anhand dessen kann die Protokollenti-
tät beispielsweise ihre Timings und ihr Verhalten entsprechend anpassen.
4.2.2. Zustandsautomat
Für die formale Modellierung von Protokollabläufen sind Zustandsautomaten ein ge-
eignetes Mittel. Alle Zustände und Übergänge lassen sich auf diese Weise präzise und
eindeutig darstellen. Beispielhaft hierfür kann das Zustandsmodell von TCP ([Pos81, S.
23]) genannt werden. Im Folgenden wird der Protokollablauf des hier vorgestellten Pro-
tokolls WiLDToken als Zustandsautomat abgebildet.
Aus der Kommunikationsabfolge der Punkt-zu-Punkt-Verbindung ergeben sich für je-
de Protokollentität die zwei Grundzustände Senden (TX) und Empfangen (RX). Diese
Aufteilung der Grundfunktionalität hat sich bereits in dem in Abschnitt 3.3 vorgestellten
Protokoll 2P bewährt und ist diesem entlehnt. Neben diesen beiden Grundzuständen sind
weitere Hilfszustände notwendig, um das Protokoll flexibel und robust zu gestalten. Es
ist beispielsweise nicht sinnvoll, beim Start der Protokollentität unmittelbar in den Sen-
dezustand zu wechseln, da nicht bekannt ist, ob der Kommunikationspartner am anderen
Ende der Verbindung vorhanden und empfangsbereit ist.
Abbildung 4.2 zeigt den vollständigen Zustandsautomaten von WiLDToken inklusive
der beiden Haupt- und Hilfszustände.
Synchronisierungsphase (SYNC und WAIT) Jede Protokollentität startet im Zu-
stand SYNC als Ausgangspunkt der Synchronisierungsphase, die einen synchronen Zu-
stand mit dem Übertragungspartner am anderen Ende der Punkt-zu-Punkt-Verbindung
herstellen soll. Dieser ist zugleich Fallback-Zustand, falls während einer Übertragung
der Token verloren gehen oder durch Kollision oder Bitfehler unbrauchbar werden soll-
te. Wie beispielsweise bei TCP wird zwischen dem passiven und aktiven Eröffnen der
Synchronisierungsphase unterschieden.
Entwurf des Protokolls 43
Abbildung 4.2: WiLDToken: Zustandsautomat (nach eigener Darstellung)
Die passive Eröffnung der Synchronisierung wird durch den Empfang einer gültigen
Synchronisierungsanfrage (Sync-Requests) eingeleitet. Dieser wird mit einer Synchro-
nisierungsbestätigung (Sync-Reply) beantwortet. Durch den anschließenden Wechsel in
den Zustand RX ist die passive Synchronisierungsphase abgeschlossen und die Protokol-
lentität ist bereit, Datenpakete vom Partner zu empfangen.
Sollte nach einer festgelegten Verweildauer im Zustand SYNC (Sync-Timeout) kein Sync-
Request empfangen worden sein, beginnt durch Versenden eines solchen die aktive Er-
öffnung der Synchronisierung. Die korrekte Wahl des Sync-Timeout wird im Abschnitt
4.2.3 beschrieben. Im Folgezustand WAIT wartet die Protokollentität auf Antwort des
Partners in Form eines Sync-Reply. Trifft diese nicht innerhalb des oben beschriebenen
Receive-Timeout ein, wird zurück in den Zustand SYNC gewechselt. Andernfalls ist der
Synchonisierungsprozess abgeschlossen und mit dem Wechsel in den Sendezustand TX
beginnt der reguläre Betrieb des Zustandsautomaten, der wie oben beschrieben die bei-
den Zustände TX und RX beinhaltet.
Sendezustand (TX) Der Zustand TX ist einer der beiden Hauptzustände und bildet
unter anderem das Versenden der in der Sendewarteschlange gesammelten Datenpakete
ab. Er vereinigt die folgenden Unterfunktionen:
• Erzeugung eines Block Acknowledgements
• Behandlung von Sendewiederholungen
Entwurf des Protokolls 44
Abbildung 4.3: WiLDToken: Datenfluss zwischen den Stationen (nach eigener Darstellung)
• Abarbeiten der Sendewarteschlange
• Erzeugung eines Token-Frames
Den Beginn jeder regulären WiLDToken-Übertragung bildet ein Block Acknowledge-
ment. Die empfangende Protokollentität kann hieraus ermitteln, welche Frames im nächs-
ten Durchgang erneut gesendet werden müssen. Sollte der Zustandsautomat zuvor be-
reits im Zustand RX gewesen sein, wurde dort eine Liste der MDPUs erstellt, die korrekt
empfangen wurden. Andernfalls ist diese Liste in Form einer Bitmap leer. Sie dient nun
als Vorlage für die Generierung des Block Acknowledgements (siehe Abschnitt 4.2.5).
Anschließend werden die Sendewiederholungen abgearbeitet, die in der vorausgegange-
nen Empfangsphase in die entsprechende Warteschlange eingereiht wurden. Da die ma-
ximale Anzahl an MPDUs in einer A-MPDU auf 64 beschränkt ist (62 abzüglich Block
Ack und Token, vgl. [IEE12b, S. 906]), stehen bei einer großen Anzahl an Retransmis-
sions entsprechend weniger MPDUs für tatsächliche Nutzdaten zur Verfügung.
Tabelle 4.1: WiLDToken: Übersicht über Sendelimititierungen (nach eigener Darstellung)
MPDUs pro A-MPDU A-MPDU-Größe Sendezeit
64 ([IEE12b]) 65535 Bytes ([IEE12b, S.812])
4 ms ([IEE04, S. 32]),10 ms ([IEE12b, S. 1762])
802.11n 802.11n 802.11j, 802.11n
Unabhängig von Paket-größe, unterschiedlichePaketgröße bedeutetunterschiedlich großeA-MPDUs, Berücksich-tigung regulatorischerVorgaben
Unabhängig von Paketan-zahl, Berücksichtigung re-gulatorischer Vorgaben
Feste Länge, unabhän-gig von Paketgröße und-anzahl, abhängig vonModulation (PHY)
Im Hauptteil der Sendephase werden der Sendewarteschlange bis zum Erreichen des
vorgegebenen Sendelimits Pakete entnommen. Aus der Spezifikation von 802.11n so-
wie anhand regulatorischer Vorgaben ergeben sich für dieses Sendelimit verschiedene
Parameter, wie Tabelle 4.1 zeigt.
Entwurf des Protokolls 45
In WiLDToken wird eine Kombination aus den angeführten Sendelimits eingesetzt, wie
Algorithmus 4.1 zeigt. Das jeweils zuerst erreichte Limit löst das Versenden des Token
und damit den Wechsel in den Empfangszustand ab. Algorithmus 4.1 zeigt den vollstän-
digen Ablauf der Empfangsphase in Pseudocode.
Algorithmus 4.1 Sendezustand (TX)Require: SendQueue QSend , AggregationQueue QAgg, RetransmissionQueue QReT X , BlockAckBitmap
bAck1: maxByte := 65535,maxMPDU := 64,maxTime := 4 ms2: sentByte := 0,sentMPDU := 0,sentTime := 03:4: BlockAckPacket pbAck := GenerateBlockAck(bAck)5: QAgg→ Enqueue(pbAck)6: sentMPDU := sentMPDU +17: sentByte := sentByte+Size(pbAck)8: sentTime := sentTime+Duration(pbAck)9:
10: while QReT X has Packet pand sentMPDU < (maxMPDU−1)and (sentByte+Size(p))< (maxByte−30)and (sentTime+Duration(p))< (maxTime−Duration(30Byte)) do
11: QAgg→ Enqueue(p)12: sentMPDU := sentMPDU +113: sentByte := sentByte+Size(pbAck)14: sentTime := sentTime+Duration(pbAck)15: end while16:17: while QSend has Packet p
and sentMPDU < (maxMPDU−1)and (sentByte+Size(p))< (maxByte−30)and (sentTime+Duration(p))< (maxTime−Duration(30Byte)) do
18: QAgg→ Enqueue(p)19: QReT X → Enqueue(p)20: sentMPDU := sentMPDU +121: sentByte := sentByte+Size(pbAck)22: sentTime := sentTime+Duration(pbAck)23: end while24:25: TokenpToken := GenerateToken()26: QAgg→ Enqueue(pToken)27:28: AMPDU pagg := QAgg→ AggregateToAmpdu()29: ForwardDown(pAgg)30:31: SwitchState (RX)32: return
Für den Fall, dass vor dem Erreichen des Sendelimits keine Pakete mehr in der Sende-
warteschlange vorhanden sind, bieten sich die folgenden beiden Optionen an:
• Warten auf neue Daten, bis das Sendelimit erreicht ist
• Sofortige Weitergabe des Token
Entwurf des Protokolls 46
Wie der Algorithmus zeigt, wird in WiLDToken bei einer leeren Sendewarteschlange
durch Weitergabe des Token unmittelbar das Ende der Übertragung signalisiert. Unnö-
tige Wartezeiten und eine Unterauslastung des Mediums können auf diese Weise ver-
mieden werden. Dies geht allerdings möglicherweise zu Lasten der Fairness zwischen
den Knoten. Die erste Variante würde diese Fairness zwar garantieren. Allerdings würde
abhängig von der Ankommensrate der Pakete ein Teil der Sendezeit mit Warten belegt,
das Medium wäre in der Folge unterausgelastet.
Den abschließenden Übergang vom Sende- in den Empfangszustand initiiert die Ge-
nerierung und Übergabe des Tokens sowie die Aggregierung aller Pakete zu einer A-
MPDU (siehe Abschnitt 4.2.4).
Diese wird mit der zugehörigen Präambel versehen und an die darunterliegende Bit-
übertragungsschicht weitergereicht, nachdem durch ein Common Channel Assignment
(CCA) sichergestellt wurde, dass der Kanal nicht belegt ist. Dies ist notwendig, obwohl
das Token Passing-Verfahren kollisionsfrei ist, da das verwendete Frequenzband auch
für andere Applikationen freigegeben ist. Folglich können Interferenzen mit anderen Se-
kundärnutzern des Frequenzbandes nicht ausgeschlossen werden.
Empfangszustand (RX) Nachdem der Token als letzter Teil der A-MPDU erfolg-
reich versendet wurde, wechselt die Protokollentität in den Empfangszustand RX und
erwartet eingehende Frames des Partnerknotens. Für jeden eingehenden A-MPDU-Sub-
frame findet eine Prüfung statt, um welchen Typ es sich dabei handelt. Alle Frames
werden bereits durch die Bitübertragungsschicht anhand ihrer Prüfsumme auf Beschädi-
gung überprüft und, falls trotz Forward Error Correction (FEC) keine Reparatur möglich
war, entsprechend markiert.
Folgende Frametypen werden während einer WiLDToken-Übertragung verwendet (vgl.
[IEE12b, S. 382f, Table 8-1]):
• Type 00: Management (BSS: (Dis-)Assoc/(De-)Auth/...)
• Type 01: Block Acknowledgements
• Type 10: Daten/QoS-Daten
• Type 11: WiLDToken
Der Pseudocode in Algorithmus 4.2 zeigt die Prüfung und Weiterverarbeitung der ein-
gehenden Frames.
Wie dort zu sehen ist, werden beschädigte MPDUs verworfen, ohne weiter beachtet zu
werden. Unbeschädigte MPDUs werden anhand ihres Type-Feldes ausgewertet. Daten-
und Management-Frames werden an die nächsthöhere Schicht weitergereicht und ihre
Sequenznummer zwecks Bestätigung mit in die BlockAck-Bitmap aufgenommen.
Entwurf des Protokolls 47
Algorithmus 4.2 Empfangszustand (RX)Require: RetransmissionQueue QReT X , EmptyBlockAckBitmap bAck
while AMPDU pAgg has Packet p doif p→ IsError then
p→ Dropelse
if p→ IsManagement thenbAck→ Acknowledge(p)ForwardUp(p)
else if p→ IsBlockAck thenfor each AcknowledgedPacket pAck in p do
QReT X → Remove(pack)end for
else if p→ IsData thenbAck→ Acknowledge(p)ForwardUp(p)
else if p→ IsToken thenSwitchState(TX)
elsep→ Drop
end ifend if
end while
Anhand der im Block Acknowledgement enthaltenen BlockAck-Bitmap kann bestimmt
werden, welche zuvor gesendeten MPDUs unterwegs verloren gegangen sind und erneut
gesendet werden müssen. Details hierzu finden sich im Abschnitt 4.2.5.
Sobald ein Token-Paket empfangen wird, triggert dieses den Wechsel in den Sendezu-
stand. Auch eventuell enthaltene Verwaltungsinformationen werden extrahiert und wei-
terverarbeitet. Sollte über einen bestimmten Zeitraum kein Token empfangen worden
sein, wird angenommen, dass die Kommunikationsverbindung nicht mehr synchron ist.
Mit dem Wechsel in den Fallback-Zustand SYNC wird eine neue Synchronisierungspha-
se gestartet (siehe oben).
Der in Abbildung 4.2 angegebene Zustandsautomat sowie die formalen und textuellen
Beschreibungen bilden das Kernstück von WiLDToken. Durch die Hilfszustände und
zugehörigen Übergangsbedingungen sollte das Protokoll robust sein gegen auftretende
Fehler und Verlust von Daten- und Token-Frames. Ob diese Robustheit ausreichend ist,
muss sich in der Evaluierung zeigen.
4.2.3. Timing-Parameter
Ein fester Bestandteil bei der Modellierung eines Protokolls ist die Spezifizierung der
zugehörigen Timings. Im folgenden Abschnitt werden die zwei Timing-Parameter Sync-
Entwurf des Protokolls 48
Timeout und Receive-Timeout erläutert und ihre Berechnung offen gelegt.
Receive-Timeout Die Länge des Receive-Timeout ist aufgrund der Ausbreitungsge-
schwindigkeit elektromagnetischer Wellen direkt abhängig von der Distanz zwischen
den beiden Knoten. Sie setzt sich zusammen aus der Ausbreitungsverzögerung auf dem
Hinweg, der (geschätzten) Verarbeitungszeit im Zielknoten sowie der Ausbreitungsver-
zögerung auf dem Rückweg und der Verarbeitungszeit auf dem Quellknoten. Daraus
ergibt sich die Berechnung in Formel 1.
tTokenRcvTimeout = 2∗ (tPropagation + tProcess)+T XOPmax (1a)
Wobei die Ausbreitungszeit von der Distanz d zwischen den beiden Knoten abhängt:
tPropagation =dc=
d3∗108 m
s(1b)
Damit ergibt sich:
tReceiveTimeout = 2∗ ( d3∗108 m
s+2∗ tProcess)+T XOPmax (1c)
Da der Token immer am Ende einer Übertragung angehangen wird, ist zusätzlich die
maximale Sendedauer eines Übertragungsvorgangs (T XOPmax) mit einzubeziehen, wie
in Gleichung 1c zu sehen ist.
In 802.11 wurde der Begriff der Coverage Class eingeführt (vgl. [IEE12b, S. 873]). Die
distanzabhängige Anpassung der Protokoll-Timings wird damit in Intervallen zu je 1 µs
respektive 450m statt kontinuierlich erhöht.
cc = ddistance∗2300∗3
e (2)
Die Berechnung der Coverage Class bezieht dabei neben der Lichtgeschwindigkeit auch
den Rückweg mit ein, da die Distanz doppelt eingerechnet wird (Round Trip Time
(RTT)). Der zusätzliche Faktor ”3” spiegelt die Abstufung in 450m-Schritte wieder. Bei
der Berechnung der Zeitschlitzlänge ohne Anpassung ist der Initialwert für die Coverage
Class cc = 0.
Die Coverage Class kann ebenso bei der Berechnung des Receive-Timeouts eingesetzt
werden. Damit ändert sich Gleichung 1 wie folgt:
Entwurf des Protokolls 49
tReceiveTimeout = 3µs∗ cc+2∗ tProcess +T XOPmax (3)
Die Berechnung des Receive-Timeouts erfolgt nun analog zur Bildung des Acknowled-
gement Timeouts in IEEE 802.11n ([IEE12b, 873,1607]). Da WiLDToken keine auto-
matisierte Ermittlung des Receive-Timeouts vorsieht, muss dieses distanzabhängig von
außen konfiguriert werden.
Sync-Timeout Das Sync-Timeout (beziehungsweise das Ablaufen desselben) iniiert
im Zufallsautomaten wie bereits beschrieben den Übergang vom Zustand SYNC in den
Folgezustand WAIT und legt damit implizit fest, welcher der beiden Knoten während
der Synchronisierungsphase den aktiven respektive passiven Part einnimmt. Wie das
Receive-Timeout ist es abhängig von der distanzabhängigen Ausbreitungsverzögerung
zwischen den beiden Knoten: Je größer die Distanz zwischen den Knoten, desto größer
ist wiederum die Latenz eines ausgesandten Sync-Request. Abbildung 4.4 soll zeigen,
warum außerdem noch eine Zufallskomponente notwendig ist.
(a) Ohne Randomisierung (b) Mit Randomisierung
Abbildung 4.4: WiLDToken: Einfluss der Ausbreitungsverzögerung auf das Sync-Timeout (nacheigener Darstellung)
Zu Beginn oder nach Verlust der Synchronisation befinden sich beide Knoten im Zustand
SYNC. Es ist nicht festgelegt, welcher Knoten das initiale Senderecht erhält. Es herrschen
folglich die gleichen Bedingungen wie auf einer herkömmlichen DCF-basierten Verbin-
dung. Ohne weitere Maßnahmen kann nicht verhindert werden, dass auf beiden Knoten
das Sync-Timeout zeitgleich abläuft und in der Folge beide Knoten einen eigenen Sync-
Request absetzen und in WAIT wechseln. Wie Abbildung 4.4a zeigt, kommt es zu einer
Kollision der beiden Sync-Requests. Daher schlägt der Synchronisierungsvorgang nach
Ablauf des Receive-Timeouts fehl und beginnt von vorne.
Aus diesem Grund wird für den Sync-Timeout das aus der DCF bekannte zufallsba-
sierte Zugriffsverfahren verwendet. Dabei können die in [Rad15] ermittelten optimalen
Entwurf des Protokolls 50
Werte für das Contention Window als Zufallsraum genutzt werden, wie Algorithmus 4.3
zeigt.
Algorithmus 4.3 SwitchStateSync
Require: ContentionWindowSize cwopt
ContentionWindow cw := Rnd(cwopt)sync_timeout := cw∗ receive_timeoutSchedule(sync_timeout, InitTimeoutAction)
Das sync_timeout ergibt sich demnach aus der Multiplikation eines Zufallswertes (Rnd)
über cwopt mit dem im vorangegangenen Abschnitt beschrieben receive_timeout. Hier-
durch fließt die Distanzabhängigkeit in die Berechnung ein.
4.2.4. Aggregierung
Wie bereits beschrieben, dient Frame-Aggregierung bei IEEE 802.11n zur Steigerung
der Datenrate und Verbesserung der Medienauslastung.
Daher wird bei WiLDToken Frame-Aggregierung implementiert. Aus Transparenz- und
Kompatibilitätsgründen wird der bei IEEE 802.11 verwendete Mechanismus dabei wei-
testgehend beibehalten. Den Aufbau eines erzeugten WiLDToken-A-MPDU-Frames zeigt
Abbildung 4.5.
Abbildung 4.5: WiLDToken: Struktur einer A-MPDU (nach eigener Darstellung)
Es werden solange MPDUs zusammengefasst, bis entweder die maximale Größe in Byte,
64 MPDUs oder (modulationsabhängig) die maximale Sendezeit erreicht ist (siehe Ta-
belle 4.1). Da an einer WiLDToken-Verbindung lediglich zwei Stationen beteiligt sind,
dürfen auch Broadcast-Frames mit in die A-MPDU aggregiert werden.
Wie in der Beschreibung der Sendephase (4.1) zu sehen, werden alle in einer Runde zu
sendenden Pakete (inklusive Token und Block Ack) in einer Aggregationswarteschlan-
ge gesammelt. Sobald das Sendelimit erreicht ist, werden die gesammelten Pakete zu
einer A-MPDU zusammengefasst. Dabei erhält jedes Frame gemäß Standard einen 4
Byte großen A-MPDU-Header und gegebenenfalls ein Padding zwischen 0 und 3 Byte
Entwurf des Protokolls 51
(vgl. [IEE12b, S. 812f.]). Die fertig aggregierte A-MPDU wird anschließend an die Bit-
übertragungsschicht übergeben.
4.2.5. Empfangsbestätigung
Um den Verlust von Paketen durch Interferenzen oder andere Störeinflüsse zu kompen-
sieren, sieht WiLDToken wie IEEE 802.11 auch einen Bestätigungsmechanismus über
eine entsprechende Bitmap (64 ∗ 16Bit/64 ∗ 1Bit) vor (vgl. [IEE12b, S. 904ff.]). Dazu
ist es nötig, alle während des Sendevorgangs übermittelten Pakete vorzuhalten, um die-
se gegebenenfalls erneut übermitteln zu können. Dabei sollen selektiv nur die Pakete
wiederholt gesendet werden, die tatsächlich unbrauchbar wurden.
In WiLDToken wird der in IEEE 802.11n verwendete Block Ack-Mechanismus wei-
testgehend weiterverwendet. Hierbei ist abzuwägen, ob die Bestätigung weiterhin als
dediziertes Frame versendet oder aber ”piggyback” in die nächste A-MPDU integriert
werden soll wie bereits in der PCF vorgesehen (vgl. [IEE12b, S. 852]). Damit wer-
den überflüssige Kopfdaten vermieden und die Übertragung effizienter gestaltet. Da
jede WiLDToken-Station durchgehend die blockweise Bestätigung verwendet, ist die
Aushandlung des Block Acks wie in IEEE 802.11n vorgesehen folglich hinfällig (sie-
he [IEE12b, S. 904]).
4.3. Frame-Formate
Nachdem im vorigen Abschnitt der Protokollablauf innerhalb einer Protokollentität fest-
gelegt wurde, wird im Folgenden die Kommunikation zwischen zwei Protokollentitäten
beschrieben. Primär ist damit der genaue Aufbau der Frames gemeint, die zur Signali-
sierung zwischen den Stationen ausgetauscht werden.
Bei den ursprünglichen Token Passing-Protokollen IEEE 802.4 und IEEE 802.5 (Token
Ring/Bus) ist das Token eine festgelegte Bitfolge, die anhand der festgelegten physi-
kalischen oder logischen Ringtopologie weitergereicht wird. Für WiLDToken soll eine
Lösung gefunden werden, die sich weitestgehend kompatibel zum bisherigen Standard
realisieren lässt. Dabei eröffnen sich mehrere Möglichkeiten.
Eine äußerst effiziente Lösung bestünde beispielsweise darin, als Token ein festgelegtes
Bit im WLAN-Header zu verwenden. Ist das Bit gesetzt, wird damit die Übergabe des
Token angezeigt. Diese Lösung birgt allerdings auch einige Nachteile. Eine Schwierig-
keit besteht darin, zunächst ein ungenutztes Bit im Header zu identifizieren. Weiterhin
muss dann das zugehörige Paket nach der abgeschlossenen Paketierung verändert und
Entwurf des Protokolls 52
damit eventuell Prüfsummen neu berechnet werden. Außerdem ist es nicht möglich, wei-
tere Informationen zwischen den Knoten auszutauschen oder mehr als einen Frame-Typ
zu definieren, wie es etwa für die Synchronisationsphase notwendig ist.
Alternativ dazu kann der Token in einem eigenen Frame übermittelt werden. Dieses Ver-
fahren ist zwar möglicherweise ineffizient, da ein vollständiger zusätzlicher WLAN-
Header mit 26 Byte übertragen werden muss. Diese Lösung birgt aber den Vorteil, dass
erweiterte Protokollfunktionen auch nachträglich noch eingebaut werden können. Zu
diesem Zweck wird die bislang ungenutzte Belegung 0b11 (”Reserved”) des 2-Bit-
Felds ”Type” innerhalb des Frame Control-Felds verwendet, für das bislang lediglich
die Kombinationen 0b00 (”Management”), 0b01 (”Control”) und 0b10 (”Data”) defi-
niert sind ([IEE12b, S. 382f., Tabelle 8-1]). WiLDToken-Frames werden folglich von
anderen WLAN-Stationen ignoriert.
Allen drei im Folgenden beschriebenen Frame-Subtypen ist gemein, dass sie die Partner-
schaft zwischen den Knoten über die durch die übergeordnete Zell-Assoziation (Adhoc/-
Managed) vorgegebene BSSID identifizieren. Es wird kein neues Assoziierungsmerkmal
ausgehandelt.
4.3.1. Sync-Frames
Für die Synchronisierungsphase zu Beginn und auch nach dem Verlust eines Token im
laufenden Betrieb spielen die Synchronisierungspakete Sync-Reqest und Sync-Reply eine
entscheidende Rolle. Ihre Aufgabe ist es, zwischen den beiden beteiligten Stationen zu
vermitteln und die Zustandsautomaten auf einen gemeinsamen Stand zu bringen.
Sync-Request Mit dem Synchronization Request zeigt eine WiLDToken-Station an,
dass sie bereit ist, sich mit einem Partner zu synchronisieren. Zu diesem Zweck muss
sie ihre eigene und die Zellenadresse (BSSID) übermitteln. Da der Partner noch nicht
bekannt ist, reicht hier als Adressierung die Schicht-2-Broadcast-Adresse aus. Das Type-
Feld ist wie oben beschrieben auf 0b11 gesetzt, das Subtype-Feld erhält den Wert 0b1000.
Die anderen Felder werden entsprechend ihrer üblichen Belegung gefüllt. Damit ist der
Sync-Request ähnlich aufgebaut wie die in IEEE 802.11 spezifizierten Beacon Frames
(vgl. [IEE12b, S. 383,418,975]).
Sync-Reply Die Antwort eines synchronisierungswilligen Partners auf einen Sync-
Request ist der Sync-Reply. Da der Partner gezielt auf einen Frame antwortet, ist ihm die
Entwurf des Protokolls 53
Empfängeradresse bekannt. Daher kann der Header analog zu einem üblichen WLAN-
Header ausgefüllt werden. Wie beim Sync-Request wird das Type-Feld auf 0b11 gesetzt,
der Subtype in diesem Fall auf 0b1001.
4.3.2. Token
Der Token ist für den regulären Betrieb der wichtigste der drei spezifizierten Frame-
Typen, da er die Signalisierung, also die Übergabe der Sendeberechtigung zwischen
den beiden Stationen übernimmt. Der Aufbau ist vergleichbar mit dem des Sync-Reply,
allerdings wird das Subtype-Feld auf 0b0000 gesetzt, in Anlehnung an den 802.11-
Frametyp/-subtyp ”Data/Data”. Mit diesem einfachen Token-Frame ist bereits eine aus-
reichende Signalisierung gegeben. Allerdings können im Nutzdatenbereich des Frames
noch weitere Verwaltungsinformationen übertragen werden, mit denen die Knoten über
den Status ihres Partners informiert werden können.
4.3.3. Übersicht
Damit sind die verschiedenen Frame-Typen hinreichend beschrieben. Tabelle 4.2 zeigt
die Belegung der Header-Felder noch einmal im Überblick.
Tabelle 4.2: WiLDToken: Übersicht über die verschiedenen Frame-Typen und ihre Felderbele-gung (nach eigener Darstellung)
Frame-Typ
Type Subtype Address 1 Address 2 Address 3 Payload
Sync-Request
0b11 0b1000 Broadcast Self BSSID Keine
Sync-Reply
0b11 0b1001 Partner Self BSSID Keine
Token 0b11 0b0000 Partner Self BSSID Verwaltungs-daten (opt.)
Da von den 24 = 16 möglichen Belegungen des Subtype-Feldes lediglich drei verwen-
det werden, ist genug Spielraum für künftige Erweiterungen durch neue Frame-Typen
vorhanden.
Mathematisches Modell 54
5. Mathematisches Modell
In vorangegangenen Kapitel wurde detailliert die Funktionsweise des neuen Protokolls
WiLDToken vorgestellt. Anhand dieser Angaben folgt in diesem Abschnitt eine rudi-
mentäre mathematische Modellierung, um vor der Implementierung im nächsten Kapitel
eine initiale Abschätzung des erwarteten Leistungsgewinns zu erhalten. Als Grundlage
hierzu dienen die Arbeiten von Bianchi ([Bia00]) und Rademacher ([Rad15]).
5.1. Modellbildung
In den beiden genannten Arbeiten steht die Bildung eines mathematischen Modells für
DCF beziehungsweise EDCA einschließlich einer Leistungsanalyse im Fokus. Ein we-
sentlicher Teil bei der Erstellung der Modelle ist dabei die Betrachtung der Gewinn-
wahrscheinlichkeiten der einzelnen Stationen für das Contention-Window aufgrund des
Zufallselements in beiden verwandten Medienzugriffsverfahren EDCA und DCF. Diese
Betrachtung ist für WiLDToken nicht notwendig, da es sich hierbei um ein gesteuertes
und somit deterministisches Protokoll handelt.
Wie Rademacher zeigt ([Rad15, S. 38ff.]), gilt die Zusammensetzung der Sendezeit für
eine einzelne MPDU nach 802.11a:
TMPDU = TPREAM +TPLPC +NSY M(LMAC−HDR +Payload,MCS)∗TSY M (4)
Für A-MPDU-Aggregierung wird Gleichung 4 um die Zusammensetzung der Subframes
aus Payload und A-MPDU-Delimiter erweitert (vgl. [Rad15, S. 39 ]):
TAMPDU = TPREAM +TPLCP +NSY M(NB ∗ (LMAC−HDR +Payload +4),MCS)∗TSY M (5)
Von der maximal verfügbaren A-MPDU-Größe gehen noch die Größe des Headers und
des Block-ACK-Pakets ab. Daher errechnen sich die beiden Größen NB wie folgt (vgl.
[Rad15, S. 39]):
NB−calc =
⌊(213+i)− (LTOKEN +LBACK)
PAY LOAD+LMAC−HDR
⌋,∀i ∈ {−3, ...0, ...3} (6)
Für das 4 ms-Sendelimit erfolgt die Berechnung über die Bruttodatenrate (vgl. [Rad15,
S. 39]):
Mathematisches Modell 55
NB−4ms =
⌊(4[ms]∗MCS[Bps])/8− (LTOKEN +LBACK)
PAY LOAD+LMAC−HDR
⌋(7)
Um zu bestimmen, welches der beiden Sendelimits die Anzahl der Subframes je A-
MPDU festlegt, wird über diese beiden das Minimum ermittelt (vgl. [Rad15, S. 39]):
NB = min(NB−4ms,NB−calc) (8)
Die Gleichungen 6 bis 8 (Quelle: [Rad15, S. 39]) zeigen die maximale Größe einer A-
MPDU nach IEEE 802.11n. Dies sind je nach Aggregierungsfaktor i zwischen 210 und
216 Byte oder eine Dauer von 4ms auf dem Medium. Außerdem dürfen maximal 64 A-
MPDUs aggregiert werden, inklusive Token- und Block-ACK-Frame. Diese sind also
bei der Berechnung der Anzahl der A-MPDU-Subframes entsprechend zu berücksichti-
gen:
NB = min(min(NB−4ms,NB−calc),62) (9)
Aus dem in Abbildung 4.5 beschriebenen A-MPDU-Aufbau ergibt sich für Formel 5
folgende Änderung (wegen der Übersichtlichkeit aufgeteilt):
Ltot = (LAMPDU−HDR +LBACK)
+NB ∗ (LAMPDU−HDR +LMAC−HDR +Payload)
+(LAMPDU−HDR +LTOKEN)
(10a)
TAMPDU = TPREAM +TPLCP +NSY M(Ltot ,MCS)∗TSY M (10b)
Für eine ganze Übertragung inklusive Ausbreitungsverzögerung und SIFS ergibt sich
damit (gemäß Darstellung in Abbildung 4.3):
TT X = TSIFS +TAMPDU +TPROP(d) (11)
Unter Einbeziehung der Ausbreitungsverzögerung TPROP:
TPROP(d) =d[m]
3∗108[ms ]
(12)
Mathematisches Modell 56
Während der Übertragung können durch Interferenzen oder andere Störeinflüsse Bitfeh-
ler auftreten. Ein Teil davon ist durch FEC behebbar, aber nicht alle. Die Prüfsumme
(FCS), die jeder Frame besitzt, ermöglicht die Erkennung gekippter Bits. Dehlerhafte
Frames können somit durch selektive Bestätigung (Block ACK) neu übertragen werden.
Die Bitfehlerrate nach FEC (Bit Error Rate (BER)) dient als Wahrscheinlichkeitsmaß für
diese Bitfehler und liegt für drahtlose Verbindungen abhängig vom Rauschabstand etwa
bei 10−5 bis 10−3 (vgl. [Rec12, S. 449]).
Für ein Paket der Länge L Bit kann daher die Paketfehlerrate entsprechend bestimmt
werden (vgl. [Rad15, Gl. 52]):
PER = 1− (1−BER)L (13)
Anhand der Paketfehlerrate kann errechnet werden, welcher Anteil der Payload einer
WiLDToken-A-MPDU (abzüglich ACK und Token) tatsächlich für Nutzdatenüberta-
gung verwendet werden kann und wie viel im Schnitt für Retransmissions eingeplant
werden muss.
NB−real = bNB ∗ (1−PER)c (14)
Der Anteil an Nutzdaten an einer Übertragung kann für einen Flow folgendermaßen
bestimmt werden:
ωNutz =NSY M(NB−real ∗Payload,MCS)∗TSY M
TT X(15)
Bei symmetrischer Konfiguration der Sendelimits auf beiden Konten kann die Gesamt-
datenrate damit wie folgt errechnet werden:
Datenrate = ωNutz ∗MCS[Mbps] (16)
Bei asymmetrischen Sendelimits oder für den Fall, dass ein Flow nicht vollständig ge-
sättigt ist, muss die Betrachtung entsprechend erweitert werden:
ωNutz =NSY M((NB−real−Flow1 +NB−real−Flow2)∗Payload,MCS)∗TSY M
TT X−Flow1 +TT X−Flow2(17)
Hierbei handelt es sich lediglich um eine grobe Betrachtung zur Abschätzung der Leis-
tung. Es werden beispielsweise keine unterschiedlichen Paketgrößen berücksichtigt. Die
Mathematisches Modell 57
Ende-zu-Ende-Latenz ist die Summe aus Übertragungsdauer und Verarbeitungszeit auf
den Knoten an beiden Seiten des Links. Da letztere nicht bekannt ist und als konstant
angenommen werden kann, wird sie in den Berechnungen nicht berücksichtigt. Folglich
wird als Latenz TLat = TT X angenommen.
5.2. Leistungsabschätzung
Zur Veranschaulichung und Erzeugung von Vergleichsdaten für die Evaluierung von
WiLDToken in Kapitel 7, wurde über die oben aufgeführten Berechnungen eine script-
basierte Berechnung mit User Datagram Protocol (UDP) als Transportprotokoll erstellt.
Zur Berechnung wurde vom Autor die Sprache VBScript (siehe [Sch10]) eingesetzt, da
aufgrund beruflicher Tätigkeiten hinreichende Erfahrungen mit dieser Sprache vorhan-
den sind. Da es sich außerdem um eine Scriptsprache mit leicht zugänglichem (da im
Betriebssystem enthaltenen) Interpreter2 handelt, ist die Erstellung, Modifikation und
Ausführung ohne umfangreiche Entwicklungsumgebung möglich3. Der Quellcode zu
dieser Simulation findet sich in Listing A.1 im Anhang.
Die Berechnung wurde ausgehend von einer Kanalbreite von 20 MHz und MCS 7 bei
langem Schutzintervall durchgeführt. Hiermit ergibt sich aus Tabelle 2.1 eine Brutto-
datenrate von 65 MBit/s. Als Extrema wurden für die Distanz die Werte 100 m und
50 km eingesetzt, innerhalb derer WiLD-Links sich üblicherweise bewegen. Für die
DCF wurde die höchste Aggregierungsstufe (1016− 1 = 65535Byte), für WiLDToken
ein ebensolches Sendelimit angenommen. Beiden gemeinsam ist die beschriebene zeit-
liche Beschränkung auf 4 ms. Die Paketgröße beträgt 1450 Byte.
Die Werte für die DCF sind den CSV-Dateien zu [Rad15] entnommen. Hieraus ergeben
sich die folgenden Ergebnisse für Nutzdatenrate und Latenz:
DCF
DRDCF (100m) = 54,1MBit/s (18)
DRDCF (50km) = 33,3MBit/s (19)
WiLDToken
DRWT (100m) = 62,7MBit/s (20)
DRWT (50km) = 60,1MBit/s (21)
Ausgehend von den absoluten Zahlen ist bereits eine Leistungssteigerung insbesondere
bei großen Distanzen feststellbar. Bei 65 MBit/s Bruttodatenrate (s.o.) ergibt sich so-
mit ein Wirkungsgrad zwischen 83,2 und 51,2% für die DCF sowie zwischen 96,5 und
92,5% mit WiLDToken (siehe Gleichungen 22 bis 25).
2Windows Scripting Host, https://msdn.microsoft.com/de-de/library/ms950396.aspx3verglichen beispielsweise mit MatLab oder einer komplexeren Programmiersprache wie C/C++
Mathematisches Modell 58
ηDCF (100m) =54,1MBit/s65MBit/s
≈ 0,832 (22)
ηDCF (50km) =33,3MBit/s65MBit/s
≈ 0,512 (23)
ηWT (100m) =62,7MBit/s65MBit/s
≈ 0,965 (24)
ηWT (50km) =60,1MBit/s65MBit/s
≈ 0,925 (25)
Zur theoretischen Erfassung der Leistungssteigerung wird die Differenz zwischen WiLD-
Token und DCF im Verhältnis zur mit der DCF erzielten Nutzdatenrate betrachtet:
ηDCF (100m) =62,7MBit/s54,1MBit/s
−1≈ 0,159 (26) ηDCF (50km) =60,1MBit/s33,3MBit/s
−1≈ 0,804 (27)
Es kann also eine distanzabhängige Steigerung der Nutzdatenrate zwischen 16 und 80%
Prozent erwartet werden. Bei einer errechneten Übertragungsdauer der A-MPDU von
3,87 s steigt die Verzögerung wie erwartet linear mit der Ausbreitungsverzögerung von
zu Beginn 3,88 ms auf 4,05 ms. Die Differenz
∆t = 4,0508ms−3,8845ms = 0,1663ms (28)
entspricht dabei in etwa der Ausbreitungsverzögerung bei 50 Kilometern Distanz (ab-
züglich der ersten 100 Meter),
tProp(50km) =(50−0,1)∗104
3∗10−5 =4,93∗10−1 = 0,163 (29)
Wie auch zu sehen ist, sinkt die Nutzdatenrate mit steigender Bitfehlerrate (BER), da
je A-MPDU mehr Platz durch Retransmissions belegt wird. Bei 100 Metern liegt die
durchschnittliche Datenrate bei einer BER von 10−6 und 10−5 (in der Abbildung nicht
gezeigt) immerhin noch bei 59,7 Mbit/s. Bei BER = 10−4 sind es noch 53,8 MBit/s und
bei BER = 10−3 sinkt die Datenrate auf etwa 12 MBit/s, bezogen auf eine A-MPDU-
Größe von 21 Subframes á 1450 Byte Payload (4 ms/65535 Byte Sendelimit).
Implementierung 59
6. Implementierung
In Kapitel 4 wurde das Protokoll WiLDToken beschrieben und seine Funktionsweise
detailliert herausgearbeitet. Dabei wurden zunächst die unterschiedlichen Anforderun-
gen an ein solches Token Passing-Protokoll für WLAN-basierte Langstrecken-Punkt-zu-
Punkt-Verbindungen erhoben. Anschließend wurden die einzelnen Teilfunktionalitäten
wie Zustandsautomat, Verwaltungsframes und Aggregierung spezifiziert. Eine initiale
Leistungsabschätzung von WiLDToken im Vergleich zur DCF wurde in Kapitel 5 durch-
geführt.
Dieses Kapitel widmet sich infolgedessen der Implementierung des Protokolls. Zunächst
werden dazu verschiedene Implementierungsmöglichkeiten einschließlich ihrer Vor- und
Nachteile aufgezeigt. Im Wesentlichen kann hier zwischen der Umsetzung auf einem
realen Testbed und der Simulation durch eine entsprechende Simulationsumgebung dif-
ferenziert werden. Im Anschluss wird die Implementierung beschrieben, deren Struktur
sich an der bestehenden ns-3-Architektur für WiFi orientiert. Insbesondere auf die Um-
setzung der im Vorkapitel beschriebenen Teilbereiche Verwaltungsframes, Zustandsau-
tomat, Aggregierung sowie Empfangsbestätigung wird bei den Ausführungen eingegan-
gen.
6.1. Implementierungsoptionen
Wie Wehrle (siehe [WGG10, S. V]) beschreibt, bieten sich für die Leistungs- und Verhal-
tensevaluierung von Kommunikationssystemen, Protokollen und Algorithmen die fol-
genden Methoden an:
1. Experimente mit realen Systemen oder Prototypen
2. Mathematische Analyse
3. Simulation
In diesem Abschnitt werden verschiedene Methoden vorgestellt, die im Vorfeld und im
Verlauf der Arbeit an der vorliegenden Thesis analysiert wurden. Dabei sollen jeweils
die Vor- und Nachteile der einzelnen Methoden herausgestellt und abschließend anhand
eines zusammenfassenden Vergleichs eine adäquate Methodik ausgewählt werden.
6.1.1. Eigenständiges Kernelmodul
Aufbauend auf der Arbeit von Rademacher ([Rad15]) und ausgehend vom Praxisbezug
des Themas offeriert sich eine Implementierung auf einem Testbed aus handelsüblichen
Implementierung 60
Hardware-Komponenten (COTS), auf denen als Betriebssystem eine geeignete Linux-
Distribution (beispielsweise OpenWRT, Voyage, Debian, ...) arbeitet.
Der Linux Wireless Stack unterscheidet mit Full- und SoftMAC zwei unterschiedlich
umfangreiche respektive umgesetzte Implementierungen der Medienzugriffsschicht. Bei
einer FullMAC-Implementierung enthält die Firmware der Karte alle für den Medienzu-
griff notwendigen Funktionen (MLME), also die Medienzugriffskontrolle DCF genau-
so wie das Carrier Sensing. Der größere Funktionsumfang erhöht die Komplexität der
Firmware und erfordert auf den Schnittstellenkarten eine höhere Rechenleistung. Der
Karten-Hersteller muss außerdem alle Protokollfunktionen selbst implementieren, auch
solche, die nicht hardwarespezifisch sind ([Ker15c]).
Aus dieser Situation heraus wurde die SoftMAC-Architektur entworfen, um eine herstel-
lerübergreifende Vereinheitlichung der Firmware- und Treiberstruktur zu erzielen. Diese
sieht eine Aufteilung der Funktionalitäten zwischen Kartenfirmware und -Treiber sowie
dem Linux-Wireless-Stack vor. Mediennahe, hardwareabhängige Funktionen (d.h. Car-
rier Sensing, Integritätsprüfung, ggf. Acknowledgements) verbleiben in der Firmware
der Karte. Der Linux-Wireless-Stack übernimmt die übergreifende MAC Layer Mana-
gement Entity (MLME) und deren Subfunktionen wie DCF und EDCA. Weiterführen-
de Informationen können der offiziellen Internetseite der Arbeitsgruppe ”Wireless” des
Linux-Kernels entnommen werden (siehe [Ker15a, Ker15b]). Außerdem beschäftigen
sich die Autoren um Vipin (in [VS10]) beziehungsweise Günther (in [GLMC14]) und
Camps-Mur (in [CM11]) mit der Analyse von Free and Open Source Software (FOSS)-
WLAN-Treibern für Linux.
Um die in Kapitel 4 beschriebene WiLDToken-Funktionalität hardwarenah in den Pro-
tokollstack zu integrieren, stellt ein eigenständiges Linux-Kernelmodul mit einem Pseu-
dointerface als Schnittstelle zur Vermittlungsschicht eine potentielle Lösung dar. Die
Funktionalität des SoftMAC würde dabei weitestgehend umgangen, indem die WLAN-
Schnittstelle im Monitor-Modus betrieben und Pakete via Raw Frame Injection 4 gesen-
det und empfangen werden.
Vorteile Als Vorteil dieser Implementierungsmethode ist primär die Relevanz für den
Einsatz in realen WiLD-Mesh-Netzwerken anzuführen. Eine funktionierende Implemen-
tierung könnte dazu dienen, bei der Versorgung des ländlichen Raums mit Breitband-
Internetzugängen eine für die zugehörigen WISPs und Endkunden wichtige Leistungs-
optimierung zu erzielen, vorausgesetzt das Protokoll ist in der Lage, eine solche zu lie-
fern.
4Raw Frame Injection erlaubt das beliebige Senden von Paketen über die Funkschnittstelle, indem dieseim Monitor-Modus via Radiotap-Header angesprochen wird (siehe [Ber11]
Implementierung 61
Nachteile Im Vorfeld der vorliegenden Thesis und in deren Verlauf wurde die Funk-
tionsweise des Treibermoduls ”ath9k” untersucht. Im Mittelpunkt stand die Eignung für
eine Realimplementierung von WiLDToken. Hierbei stellte sich als problematisch her-
aus, dass die oben beschriebene teilweise Implementierung der Medienzugriffsschicht in
der Firmware der WLAN-Karte Änderungen an einigen relevanten Funktionen wie der
DCF verhindert, wie in [GLMC14] geschildert.
Folglich wäre eine Implementierung als Overlay auf dem bestehenden Medienzugriff
notwendig, wie beispielsweise in [ESB+13] gezeigt. Der erwartete Leistungsgewinn
fällt damit durch die trotzdem notwendige Anpassung der Protokolltimings geringer
aus, auch wenn das Contention Window durch CWmin = CWmax = 1 weitestgehend
eliminiert wird. Die Erfahrungen des Autors zeigen zudem, dass der Implementierungs-
aufwand aufgrund von unzureichender Dokumentation nur schwer abzuschätzen ist.
6.1.2. Linux Kernel Packet Scheduler/Tra�c Control
Als Alternative zu einer eigenen Kernelmodul-Implementierung bietet sich die Verwen-
dung des Linux Kernel Packet Scheduler und Traffic Control (TC) an. Die in diesem Ab-
schnitt verwendeten Informationen sind den Veröffentlichungen [Alm99,Bro06,Hub12]
entnommen.
Abbildung 6.1: TC: Einordnung im Linux-Netzwerkstack (Quelle: [Alm99])
TC wird unter Linux als Werkzeug für Traffic Shaping und Priorisierung genutzt. Es bie-
tet die Möglichkeit, Datenströme zu separieren und unterschiedlich zu behandeln. Letz-
teres wird über so genannte Queueing Discipline (QDisc)s realisiert, denen bestimmte
Queueing-Mechanismen wie First-In-First-Out (FIFO) oder Token Bucket Filter (TBF)
zugewiesen werden (siehe Abbildung 6.2).
Abbildung 6.2: TC: Filter und Queueing Disciplines (Quelle: [Alm99])
Implementierung 62
TC beziehungsweise der Kernel Packet Scheduler agieren innerhalb des Linux-Netz-
werkstacks und stehen damit allen Netzwerkschnittstellen zur Verfügung. Da TC für
WLAN-Schnittstellen allerdings über dem Wireless Stack mit Soft- und FullMAC liegt,
handelt es sich bei einer WiLDToken-Implementierung auf dieser Basis um eine Overlay-
Lösung wie auch im Vorabschnitt beschrieben.
Für die Implementierung der Übergänge zwischen Sende- und Empfangsphase kann
dabei eine TBF-QDisc verwendet werden. Zum Anhalten des Verkehrs wird die Da-
tenrate des TBF auf 0 gesetzt, zum Freigeben des Verkehrs entsprechend wieder auf
einen möglichst hohen Wert. Netfilter kann dazu genutzt werden, eingehende Frames
auf Signalisierungsdaten zu überprüfen. Da sich WLAN-Schnittstellen gegenüber hö-
heren Schichten als Ethernet-Schnittstellen ausgeben ([IEE12b, S. 45]), können die in
Kapitel 4 beschriebenen Frame-Formate nicht verwendet werden. Diese setzen direkten
Zugriff auf den IEEE802.11-Header voraus. Weiterhin fehlt die logische Verknüpfung
zwischen dem Ausgliedern der Signalisierungsdaten mithilfe der Netfilter-Hooks und
dem Freigeben der Queues durch den TBF.
Vorteile Hauptvorteil dieser Lösung ist die Verwendung vorhandener, bereits im Ker-
nel implementierter Standard-Elemente. Durch die Abstraktion der WLAN-Schnittstellen
als Ethernet-Interface ist diese Lösung zudem unabhängig von der zugrunde liegenden
Hardware und auch für künftige WLAN-Standards ohne umfangreiche Anpassungen an-
wendbar.
Nachteile Wie bereits genannt, fehlt ein wesentlicher Teil, der die Verknüpfung zwi-
schen eingehenden Signalsierungsdaten und dem Freigeben der Sendewarteschlange
herstellt. Da es sich hierbei um ein nachvollziehbar zeitkritisches Problem handelt, ist für
diese Lösung die Erstellung eines Kernelmoduls ebenfalls notwendig. Da keine beliebi-
gen WLAN-Frames versendet werden können, muss die Funktionalität des bestehenden
MAC-Layers genutzt werden. Da es sich auch hier um eine Overlay-Lösug handelt, ist
der bereits oben beschriebene Overhead samt Distanzanpassung unvermeidlich.
6.1.3. OpenFlow und Open vSwitch
OpenFlow und Open vSwitch sind zwei Schlagwörter, die im Zusammenhang mit Soft-
ware Defined Network fallen. Letzteres vereint Techniken zur Netzwerkvirtualisierung
und führt eine Trennung zwischen Netzwerkprotokollen beziehungsweise -anwendungen
Implementierung 63
(Applications) sowie Steuerungs- (Control Plane) und Weiterleitungsschicht (Forwar-
ding Plane) ein. Ziel ist es, das Netzwerk intelligenter zu gestalten und mit einem ”Netz-
werkbetriebssystem” zu versehen, innerhalb dessen Applikationen das Verhalten des
Netzwerkes (Routing, Switching, ...) durch Paketmanipulation und -weiterleitung steu-
ern. Ein wesentlicher Bestandteil ist dabei die Abstraktion zwischen Applikation und
Control Plane (Northbound Interface) sowie Control Plane und Forwarding Plane (South-
bound Interface) (siehe auch [MAB+08, Gro13] und Abbildung 6.3).
Abbildung 6.3: SDN: Aufbau und Architektur (Quelle: [Fou12])
OpenFlow ist ein Software Defined Network (SDN)-Protokoll und dient auf dem South-
bound Interface zur Kommunikation zwischen Controller (bildet die Control Plane) und
SDN-Switch (bildet die Forwarding Plane). OpenFlow ist aktuell in Version 1.4 spe-
zifiziert und verfügbar sowie ein De-facto-Industriestandard der OpenFlow Foundation
(vgl. [MAB+08]). Der Open vSwitch ist eine Open-Source-Software-Implementierung
eines OpenFlow fähigen Switches und für Linux-artige Betriebssysteme verfügbar (sie-
he [PPA+09, Ope, Gro13]). Um die Relevanz von WiLDToken für Software Defined
Wireless Mesh Network (SDWMN)-Netzwerke zu steigern, ist eine Möglichkeit die Im-
plementierung via OpenFlow und als Applikation auf dem Controller.
Die im vorigen Abschnitt festgehaltene Implementierung via TBF kann hier wieder
aufgegriffen werden, da Open vSwitch ebenfalls über eine Hierarchical Token Bucket
(HTB)-Implementierung verfügt (siehe [Voi15, Lab13]). Über entsprechend parametri-
sierte Flows (beispielsweise Felder im IP-/MAC-Header) ist die Ausgliederung und Wei-
terleitung der Signalisierungsframes an die zu implementierende WiLDToken-Applika-
tion auf dem Controller möglich, welche die Freigabe des HTB steuert. Der letzte offene
Punkt (Erzeugen beziehungsweise Verändern von Signalisierungspaketen) lässt sich mit
Open vSwitch nicht realisieren, da dieser offenbar nicht in der Lage ist, eigenständig
Pakete zu erzeugen.
Implementierung 64
Vorteile Für diese Methode spricht die Ausrichtung auf das als Zukunftstechnolo-
gie angepriesene ([Gro13, Fou12]) Software Defined Networking, das eine zentralisier-
te Steuerung der einzelnen WiLDToken-Links durch eine entsprechende Controller-
Applikation ermöglicht. Die im Vorabschnitt monierte fehlende Verknüpfungslogik zwi-
schen Signalisierung und Queue-Freigabe kann dabei durch diese Applikation abgebil-
det werden.
Nachteile Der größte Nachteil wurde bereits weiter oben angeführt: Mithilfe des Open
vSwitch lassen sich offenbar keine eigenständigen Pakete erzeugen, daher müssen Si-
gnalisierungsdaten auf andere Weise an ausgehenden Paketen angebracht werden. Da
es sich hierbei wie bei Traffic Control/Netfilter auch um eine Overlay-Methode handelt,
kann als Träger für diese Signalisierung lediglich der Ethernet-Header verwendet wer-
den, mit den oben bereits diskutierten Nachteilen.
6.1.4. Simulation
Als Simulation bezeichnen Banks et al. ([BCNN84, S. 3f.]) eine Abbildung oder ”Imi-
tation der Funktionalität eines realen Prozesses oder Systems über Zeit”. Dabei werde
eine ”künstliche Geschichte des realen Systems erzeugt und anschließend beobachtet”.
Kernstück der Simulation ist die ”Entwicklung eines Simulationsmodells (...), das übli-
cherweise aus einem Satz von Annahmen über die Funktionsweise des Systems besteht”
( [BCNN84]). Dies wird auch von Kahlert aufgegriffen, der als Vorteile der Simulation
technischer Systeme primär Zeit- und Kostenersparnisse anführt ([Kah13, S. 18ff.]).
Auch für die Erprobung von Netzwerkstrukturen, -komponenten oder -protokollen im
wissenschaftlichen wie wirtschaftlichen Kontext stellt Simulation eine erprobte Methode
dar. Zu diesem Zweck existieren diverse Simulationsumgebungen mit unterschiedlichen
Zielsetzungen und Methoden. Die folgende Liste führt einige Simulationsumgebungen
auf, erhebt allerdings keinen Anspruch auf Vollständigkeit. Einen umfangreichen Über-
blick über Netzwerksimulation, geeignete Werkzeuge und Methodiken geben Wehrle et
al. in [WGG10].
Mit Emulation/Virtualisierung:
• GNS3 ([Inc])
• MiniNet ([LHM10])
• Cisco Packet Tracer ([Cis])
Eventbasiert:
• ns-3 ([HLR+08])
Implementierung 65
• OPNET ([Cha99, Riv])
• NetSim ([Tet])
• GloMoSim ([ZBG98], veraltet)
Wie die Autoren um Kurkowski in [KCC05] festgestellt haben, wurde in drei von vier
Veröffentlichungen im Rahmen der MobiHoc-Konferenzen zu Analysezwecken die Me-
thode Simulation eingesetzt. Dabei war ns-2 mit 43,8% die am häufigsten eingesetzte
Simulationsumgebung.
Vorteile Netzwerksimulation bietet als wesentlichen, inhärenten Vorteil die Abstrak-
tion durch Bildung eines beschreibenden Modells, bei dem unwesentliche und nachran-
gige Details vernachlässigt werden können. Zugleich ermöglicht diese Modellbildung
eine Konzentration auf wesentliche Merkmale. Durch die Nachbildung in mathemati-
schen Ausdrücken oder Quellcode und damit verbunden die Eliminierung externer Ein-
flussfaktoren ist zudem eine gute Reproduzierbarkeit von Ergebnissen gegeben. Da im
Gegensatz zu einer Realimplementierung kein Testbed bereitgestellt werden muss, kann
zudem der CAPEX reduziert werden (siehe auch [Kah13, S. 18f.]).
Im vorliegenden Fall ermöglicht die Simulation die Auflösung der oben beschriebenen
Hardware- und Software-Abhängigkeiten. WiLDToken kann wie in Kapitel 4 beschrie-
ben implementiert werden, ohne Einschränkungen durch ein reales Testbed in Kauf neh-
men zu müssen. Im Hinblick auf die Evaluierung in Kapitel 7 ermöglicht Simulation
außerdem eine flexible Wahl der Evaluierungstopologie und -parameter.
Nachteile Bei der Simulation eines Netzwerkprotokolls oder einer Netzwerktopolo-
gie mit einem der hier vorgestellten Werkzeuge handelt es sich primär um eine theore-
tische Betrachtung unter Laborbedingungen. Es können also nur bedingt Rückschlüsse
auf das Verhalten innerhalb einer realen Testumgebung gezogen werden. Mit der Festle-
gung auf eine Simulationsumgebung werden auch gegebenenfalls durch diese induzierte
Einschränkungen in Kauf genommen.
Dadurch, dass die Architektur der einzelnen Simulationsumgebungen, insbesondere der
WLAN-Implementierungen, noch erarbeitet werden muss, ist der tatsächliche Imple-
mentierungsaufwand für WiLDToken schwer zu beziffern.
6.1.5. Bewertung
Auf Basis der genannten Vor- und Nachteile der einzelnen Methoden fällt die Wahl für
die weitere Implementierung auf die Netzwerksimulation. Durch die Abstraktion des
Implementierung 66
Problems entfallen Hardware- und Software-Abhängigkeiten wie die Implementierung
der DCF in der Firmware der WLAN-Karten. Diese die hätten andernfalls bei einer Real-
Implementierung zu einer Erhöhung der Komplexität oder unzureichenden Abbildung
der WiLDToken-Spezifikation, beispielsweise durch eine Overlay-Implementierung, ge-
führt.
6.2. Simulation mit ns-3
Der folgende Abschnitt gibt einen kurzen Einblick in die Grundlagen der Netzwerk-
simulation und die Funktionsweise des Netzwerksimulators ns-3. Im Hinblick auf die
Implementierung von WiLDToken als alternative Medienzugriffskontrolle für 802.11
wird dabei unter anderem die Architektur der WiFi-Modellierung betrachtet. Abschlie-
ßend wird auf die Modellierung von WLAN-basierten Langstrecken-Punkt-zu-Punkt-
Verbindungen als Ausgangspunkt für die in Kapitel 7 durchgeführte Evaluierung einge-
gangen.
6.2.1. Einführung in ns-3
Bei ns-3 handelt es sich um eine ereignisbasierte Simulationsumgebung, die auf C++ und
Python basiert (siehe auch [HLR+08]). Als Nachfolger von ns-2 ([oSCISII]) umfasst
der Funktionsumfang neben WLAN unter anderem Modelle für Antennen, Gebäude,
IPv4/v6, CSMA- und Punkt-zu-Punkt-Schnittstellen, LTE, Mobilität und OpenFlow, wie
der Dokumentation (siehe [nP15c]) zu entnehmen ist.
Für die Verwendung von ns-3 als Simulationsumgebung für die vorliegende Thesis spre-
chen diverse Gründe. ns-3 ist quelloffen und kann durch die Lizenzierung unter der
GPLv2 frei verwendet und weiterentwickelt werden. Neben diversen Veröffentlichun-
gen, die sich mit der Entwicklung von ns-3 beschäftigen (unter anderem [HLR+08,
CFR09,RH10,PBM11]), werden auf der Seite des Projekts ([nP16a]) 227 Publikationen
gelistet, die ns-3 einsetzen (Stand: 30.03.2016). Eine entsprechende wissenschaftliche
Relevanz kann folglich nicht abgestritten werden. ns-3 unterliegt außerdem einer konti-
nuierlichen Weiterentwicklung. So wurde die unmittelbar vor Beginn der vorliegenden
Arbeit veröffentlichte Version 3.24 bereits durch den Nachfolger 3.25 abgelöst, die ei-
nige ausstehende Funktionalitäten (MIMO, 80/160MHz Kanalbreite, ...) mitbringt (vgl.
[nP16c]).
Die Hauptaufgabe von GNS3 und Packet Tracer ist die Simulation realer Netzwerke
und Komponenten, vornehmlich der Hersteller Cisco und Juniper. MiniNet hingegen ist
Implementierung 67
auf SDN-Netze ausgelegt. Der Anwendungsbereich dieser drei Simulationsumgebungen
unterscheidet sich folglich von ns-3 und dem vorliegenden Anwendungsfall.
OPNET und NetSim sind zwar grundsätzlich für die hardwarenahe Simulation von WLAN-
Verbindungen in dem benötigten Umfang geeignet, aber proprietär und kostenpflichtig5.
Es ist nicht abzusehen, wie gut Modifikationen möglich und mit der Lizenzvereinbarung
vereinbar sind. Im Gegensatz dazu ist ns-3 quelloffen und kann somit beliebig modifi-
ziert und um eigene Elemente erweitert werden.
6.2.2. Wi�-Architektur
Innerhalb von ns-3 liegt die WLAN-Funktionalität in einem eigenständigen Modul mit
der Bezeichnung ”wifi”, im Verzeichnis src/wifi/ des ns-3-Quellcodes zu finden. Ab-
bildung 6.4 zeigt die wesentlichen Bestandteile der Modularchitektur, die in weiten Tei-
len in der Online-Dokumentation ( [nP15d]) beschrieben ist. Zu sehen sind die Schichten
2 bis 0, die Schnittstelle zur darüber liegenden Vermittlungsschicht bildet die Wrapper-
Klasse WifiNetDevice mit den Methoden Send und ForwardUp.
Abbildung 6.4: ns-3: Architektur des Wifi-Moduls (Quelle: [nP15d])
Für den MAC-Layer unterscheiden die Entwickler dabei zwischen der unteren/mittleren
und oberen Medienzugriffsschicht ( [nP15d]). In der oberen Medienzugriffsschicht (Up-
per MAC, MAC High) sind die Wifi-Betriebsmodi (AP/STA/Adhoc) mit den zugehöri-
5Riverbed bietet allerdings für OPNET ein Universitäts-Programm an(http://de.riverbed.com/products/performance-management-control/network-performance-management/network-simulation.html#Modeler_University_Program).
Implementierung 68
gen Zustandsautomaten und die zeit-unkritischen Funktionen wie Beacon-Generierung
und Probing implementiert. Hierbei handelt es sich um die Funktionen, die im Linux-
SoftMAC-Stack (siehe Abschnitt 6.1.1) vom SoftMAC-Kernelmodul (MLME) über-
nommen werden.
Die untere und mittlere Medienzugriffsschicht (MAC Low/Middle) enthält hingegen
hardware-nahe oder zeitkritische Teilfunktionen wie Medienzugriff (EDCA/DCF), virtu-
elles Carrier Sensing (RTS/CTS) und Empfangsbestätigung (ACK). In SoftMAC werden
diese Funktionalitäten zusammen mit der Bitübertragungsschicht zumindest teilweise in
der Firmware der WLAN-Karten implementiert (vgl. [GLMC14]).
PHY- und Kanal-Modelle Die Bitübertragungsschicht (PHY) besteht in ns-3 im
Wesentlichen aus einem Modell ([nP15d]), das unter dem Akronym ”YANS” (Yet Ano-
ther Network Simulator) in [LH06] vorgestellt wird. Die zugehörigen Klassen sind ns3::
WifiPhy und ns3::YansWifiPhy als Kindklasse.
Jedes empfangene Paket wird durch den PHY anhand eines probabilistischen Fehlermo-
dells bewertet. Entsprechend wird das Paket entweder als korrekt oder fehlerhaft an die
nächsthöhere Schicht weitergeleitet. Die Bewertung erfolgt dabei anhand des Rauschab-
stands (Signal-to-Noise-plus-Interference Ratio (SINR)) und abhängig von der gewähl-
ten Modulation und dem Zustand der modellierten Funkschnittstelle (RX/TX/IDLE/S-
WITCHING).
Einschränkungen Für die in der vorliegenden Arbeit verwendete Version 3.24 hält
die Dokumentation folgende Einschränkungen fest (vgl. [nP15d]):
Nicht unterstützt:
• 802.11n MIMO
• 802.11n/ac MIMO
• 802.11n/ac Beamforming
• Empfang der PLCP-Präambel (nicht modelliert)
• PHY_RXSTART
• 802.11e TXOP
• Slotlänge 9µs in 802.11g
Eingeschränkt unterstützt:
• Adaptive Rate Selection (nicht in 802.11n/ac, hier nur Constant Rate)
• BSSBasicRateSet für 802.11b (wird mit 1-2 Mbit/s angenommen)
• BSSBasicRateSet für 802.11a/g (wird mit 6-12-24 Mbit/s angenommen)
• RTS/CTS und ACK (nicht als HT-Frames)
Implementierung 69
Wie bereits angemerkt, wurde ns-3.24 am 24.03.2016 bereits durch die Folgeversion
3.25 abgelöst. Die zugehörigen Release-Notes ([nP16c]) gibt für 802.11n/ac die Unter-
stützung von MIMO, adaptive Rate-Control, breitere Kanäle und Abwärtskompatibilität
zwischen 802.11n/ac-Accesspoints und Legacy-Stationen.
6.2.3. Langstrecken-Punkt-zu-Punkt-Verbindungen
Für die spätere Evaluierung der unten beschriebenen WiLDToken-Implementierung in
Kapitel 7 wird zunächst zum Vergleich die Simulation einer Langstreckenfunkverbin-
dung mit DCF nach [Rad15] in ns-3 benötigt. Ausgehend von einer einfachen IBSS-
Topologie mit zwei Teilnehmern wurden für diese Simulation die Protokolltimings ent-
sprechend angepasst. Der vollständige Quellcode der Simulation findet sich im Anhang.
Um die Herangehensweise zu veranschaulichen, werden im Folgenden dennoch exem-
plarisch ausgewählte Teile des Quellcodes gezeigt.
Folgende Werte sind nach [Rad15] distanzabhängig zu setzen:
• Propagation Delay:
tPropDelay =dc=
d[m]
3∗108[m/s](30)
• Ack Timeout:
tACKTimeout = tPropDelay +SIFS+ tACK + tPropDelay (31a)
Obere Abschätzung für ACK-Frame (14 Byte) bei niedrigster Datenrate (1Mbit/s):
tACK =14∗8Bit1MBit/s
= 112µs (31b)
Damit ergibt sich für den ACK Timeout insgesamt:
tACKTimeout = 2∗ tPropDelay +16µs+112µs (31c)
• Basic Block ACK Timeout und Compressed Block ACK Timeout
• Zeitschlitzgröße:
tSlot = tMACPHY Delay + tPropDelay = 9µs+ tPropDelay (32)
• DCF Interframe Space:
tDIFS = tSIFS +2∗ tSlot (33)
Die Berechnung der einzelnen Parameter erfolgt dabei in der Simulation über Hilfs-
funktionen, wie beispielhaft in Listing A.2 im Anhang gezeigt. Zentraler Anlaufpunkt
Implementierung 70
sind dabei die beiden Methoden calcPropDelay(double distance) und calcCoverage-
Class(double distance). Anhand der Coverage Class und des Propagation Delay lassen
sich alle anderen abhängigen Werte bestimmen.
Die errechneten Parameter werden der Simulation anschließend über die Methode Con-
fig::Set() übergeben, hier exemplarisch in Listing 6.1 gezeigt. Über die gezeigte Syn-
tax /NodeList/*/DeviceList/*/$ns3::WifiNetDevice/ werden automatisch alle
in der Simulation verwendeten Wifi-Schnittstellen angesprochen. Um eine bestimmte
Schnittstelle zu konfigurieren, können die Platzhalter * durch die entsprechende Knoten-
und Schnittstellennummer ersetzt werden. Alternativ kann ein Zugriff über die Node-
und Interface-Container erfolgen.
Listing 6.1: Auszug aus der ns-3-Simulation für Langstrecken-Punkt-zu-Punkt-Verbindungen(point-to-point_11n.cc): Setzen der Timing-Parameter
508 . . .509 / / Once i n s t a l l i s done , we o v e r w r i t e t h e s t a n d a r d t i m i n g v a l u e s i f d e s i r e d !510 Conf ig : : S e t ( " / NodeLi s t / * / D e v i c e L i s t / * / $ns3 : : Wi f iNe tDev ice / Phy / ChannelWidth " , U i n t e g e r V a l u e (
c h a n n e l w i d t h ) ) ;511 Conf ig : : S e t ( " / NodeLi s t / * / D e v i c e L i s t / * / $ns3 : : Wi f iNe tDev ice / Mac / S l o t " , TimeValue ( MicroSeconds (
c a l c S l o t T i m e ( d i s t a n c e ) ) ) ) ;512 . . .
Wie sich zeigt, existiert im aktuellen Release 3.24.1 ein Fehler, der im Zusammenhang
mit A-MPDUs auftritt (Bug 2224, siehe [nP15b]). Ein Patch hierzu existiert zwar, behob
das Problem jedoch nicht endgültig, sporadische Fehler traten immer wieder auf. Bessere
Ergebnisse lieferte der Entwicklerzweig von ns-3 (ns-3-dev).
Die Abbildung 6.5 zeigt die Simulation im Vergleich mit dem mathematischen Modell
von Rademacher ([Rad15]) für die Aggregierungsstufen −3, 0 und 3. Wie zu sehen ist,
liegen die Kurven für die Datenrate in allen drei gezeigten Aggregationsstufen wie er-
wartet in weiten Teilen aufeinander. Die im Vergleich zum Modell zackige Struktur der
Simulationskurven ist durch die Zufallscharakteristik der DCF zu begründen. Die mini-
malen Diskrepanzen zwischen Simulation und Modell lassen durch eventuelle margina-
le Unterschiede in den konfigurierten Protokolltimings erklären. Die signifikanten Leis-
tungszugewinne mit zunehmender Aggregierungsstufe machen die Relevanz der Einfüh-
rung der MSDU- und MPDU-Aggregierung mit IEEE 802.11e/n und die Verwendung in
WiLDToken deutlich.
6.3. Architektur der Implementierung
Die Dokumentation des Wifi-Modells enthält bereits Hilfestellungen für Veränderungen
an den einzelnen Quellcodeteilen, da ”Modifikationen (...) ein gebräuchlicher Bestand-
teil der Forschung” seien (vgl. [nP15d]). Für die Implementierung von WiLDToken
Implementierung 71
0 10 20 30 40 500
20
40
60
Distanz (km)
Dat
enra
te(M
bit/s
)
0
100
200
300
400
500
Slot
Tim
e(µ
s)
Modell, Agg.=3 ns-3, Agg.=3Modell, Agg.=0 ns-3, Agg.=0Modell, Agg.=-3 ns-3, Agg.=-3
Slot Time
Abbildung 6.5: 802.11: Datenrate und Zeitschlitzlänge über Distanz, mathematisches Modellnach [Rad15] (rot) und Simulation in ns-3 (blau), 20 MHz, MCS7, bidirektio-nal, langes GI (nach eigener Darstellung)
erscheinen dabei insbesondere die folgenden von den Entwicklern beschriebenen Vor-
gehensweisen relevant:
1. Hinzufügen oder Verändern von Frames oder Headern: wifi-mac-header.*
2. Veränderungen am unteren MAC, beispielsweise die Verarbeitung neuer/modifi-
zierter Controlframes (RTS/CTS/ACK/Block ACK): mac-low.* (MacLow::ReceiveOk)
3. Veränderungen am oberen MAC, beispielsweise die Verarbeitung/Generierung neu-
er Verwaltungsframes (Beacon/Probe): regular-wifi-mac.*, sta-wifi-mac.*, ap-wifi-
mac.* oder adhoc-wifi-mac.*
4. Queue-Management: dca-txop.* und edca-txop-n.*
5. Kanalzugriff: dcf-manager.*
6. ...
Um eine bessere Strukturierung und Verständlichkeit zu erzielen, orientiert sich die Be-
schreibung der Implementierungsdetails im folgenden Unterkapitel 6.4 an der angeführ-
ten Auflistung.
Die Verwendung der in ns-3 als HT betitelten 802.11-Funktionen wie höherwertige Mo-
dulationsraten (MCS) und Aggregierung setzt die Verwendung des HT-MACs voraus.
Dieser basiert auf den mit 802.11e eingeführten QoS-Erweiterungen. Obwohl WiLDTo-
ken in der Ursprungsform keine Dienstgüte-Unterstützung vorsieht, kann diese in der
Implementierung bereits vorbereitet werden. Daraus ergibt sich die in Abbildung 6.6
Implementierung 72
gezeigte Architektur (siehe auch Abbildung A.3 im Anhang):
Abbildung 6.6: WiLDToken: Architektur in ns-3 (nach eigener Darstellung)
Dargestellt sind die beteiligten Klassen und ihre Interaktion untereinander über die ge-
zeigten Schnittstellenfunktionen. ns3::WtWifiMac fungiert wie die Geschwisterklasse
ns3::RegularWifiMac als Umbrella-Klasse und aggregiert die einzelnen Bestandteile
wie ns3::WtManager, den MAC Middle inklusive der unterschiedlichen Instanzen von
ns3::WtTxop sowie den MAC Low. Alle beschriebenen Klassen und der zugehörige
Quellcode finden sich in Auszügen im Anhang beziehungsweise vollständig auf dem
beiliegenden Datenträger und im Github-Repository6.
Helper Die beschriebenen Helper-Klassen unterhalb von src/wifi/helper dienen
dazu, dem Simulanten den Umgang mit dem Wifi-Modell durch vorgefertigte Konfigu-
rationsparametersätze zu erleichtern.
(a) Wifi-Helper (b) WiLDToken-Helper
Abbildung 6.7: ns-3: Helper-Klassen für Wifi und WiLDToken (nach eigener Darstellung)
6https://git.fslab.de/mchauc2s/WiLDToken
Implementierung 73
Für die Implementierung von WiLDToken wurden basierend auf den bestehenden Helper-
Klassen neue Helper angelegt. Die Abhängigkeitsstruktur und Funktionsweise bleibt da-
bei unverändert.
6.4. Implementierungsdetails
Der folgende Abschnitt beschreibt zusammenfassend die wesentlichen Implementie-
rungsdetails, insbesondere die Umsetzung des Zustandsautomaten, der Aggregierung
und der Bestätigungsfunktion. Zur besseren Darstellung ergänzen Quellcodebeispiele in
Form von Listings im Fließtext die Beschreibungen, wann immer es sinnvoll erscheint.
Weitere Listings finden sich im Anhang A.3.
6.4.1. Hinzufügen der WiLDToken-Frames
Im folgenden Abschnitt wird die Implementierung der WiLDToken-Verwaltungspakete
Sync-Request, Sync-Reply und Token beschrieben, insbesondere die Integration in vor-
handene ns-3-Datenstrukturen und die Belegung der Header- und Adressfelder wie in
Tabelle 4.2 beschrieben.
Enumeration enum Wi�MacType Die Enumeration enum WifiMacType enthält
alle WiFi-Pakettypen und -subtypen und wird um die WiLDToken-Frametypen Sync-
Request, Sync-Reply und Token (hier DATA) erweitert (siehe Listing A.3). Die Enumerati-
on wird insbesondere von der im Folgenden beschriebenen Klasse ns3::WifiMacHeader
verwendet, daher ist die beschriebene Anpassung notwendig.
Klasse ns3::Wi�MacHeader Die Darstellung von WLAN-Pakete in ns-3 besteht aus
zwei Teilen: ns3::Packet bildet die von der Vermittlungsschicht übergebene SDU oder
Payload und ns3::WifiMacHeader die Protocol Control Information (PCI) beziehungs-
weise den Header. Die Struktur von ns3::WifiMacHeader entspricht dabei der des IE-
EE 802.11-Headers mit den zugehörigen Feldern (Version, Type/Subtype, Address 1 bis
3) und Flags. Für die Implementierung von WiLDToken ist die Erweiterung dieser Klas-
se um die WiLDToken-Headerformate notwendig.
Bei der Erzeugung eines Headers wird dessen Typ durch Aufruf der Funktion SetType
(header_type ) festgelegt. Diese setzt die Felder Type und Subtype entsprechend ihrer
für diesen Typ zugewiesenen Belegungen (siehe [IEE12b, S. 382f., Tabelle 8-1]). Hier
wurden auch die in Tabelle 4.2 gezeigten Belegungen für diese Felder eingefügt (siehe
Listing A.4 im Anhang).
Implementierung 74
6.4.2. Änderungen am unteren MAC
Der folgende Abschnitt beschreibt die Implementierung der A-MPDU-Aggregierung
und blockweisen Bestätigung (Block Acknowledgements). Beide sind in der Klasse
ns3::WtMacLow implementiert, erweitert durch die Hilfsklassen ns3::AmpduAggre-
gator/ns3::AmpduStandardAggregator respektive ns3::WtBlockAckManager.
Klasse ns3::MacLow Die Ableitung von Kindklassen ist in ns3::MacLow nicht di-
rekt vorgesehen. Bei der Ausnutzung von Polymorphie werden geerbte Methoden in C++
im Gegensatz zu beispielsweise Java nicht implizit durch die gleichnamige Methode der
Kindklasse überschrieben, wenn sie nicht als virtual deklariert sind. Dies ist jedoch not-
wendig, wenn die Funktionalität von ns3::MacLow für WiLDToken angepasst werden
muss, die ursprüngliche Klasse jedoch nicht modifiziert werden und Kompatibilität ge-
genüber dem PHY erhalten bleiben soll. Daher wurden die Methoden in ns3::MacLow
in virtuelle Methoden umgewandelt. Das Konzept der virtuellen Methoden wird bei-
spielsweise von Wolf in [Wol14], Kapitel 9.7 erläutert.
Klasse ns3::WtMacLow (A-MPDU-)Aggregierung und Block Acknowledgements
sowie Retransmissions sind in ns3::WtMacLow implementiert. Für die Aggregierung
fungiert eine Instanz von ns3::WifiMacQueue als Aggregationswarteschlange, in die
alle zum Versenden weitergereichten Pakete eingereiht werden, auch Retransmissions,
Block-ACK- und Management-Frames (siehe auch Abbildung A.2b).
Die Reihenfolge, in der die Frames eingereiht und damit zu einer A-MPDU aggregiert
werden, ergibt sich durch die Reihenfolge der Abarbeitung während der Sendephase in
WtManager::NotifyWtFrameReceived() (siehe Listing A.20. Der letzte Frame ist in
jedem Fall ein WiLDToken-Frame und löst die Aggregierung sowie das Versenden der
A-MPDU über die Funktion WtMacLow::SendDataPacket() aus (siehe Listing A.7 im
Anhang).
Wie eine Analyse des Quellcodes gezeigt hat, findet der Versand der einzelnen Fra-
mes in ns-3 nicht über die künstliche Erzeugung von OFDM-Symbolen statt. Statt-
dessen wird für jedes Packet-Objekt die Dauer bis zum Versand über die Übertra-
gungsdauer der vorangegangenen Pakete (delay += m_phy→CalculateTxDuration)
berechnet und über Simulator::Schedule() ein Timer mit der Callback-Funktion
WtMacLow::SendPacket() erzeugt. Letztere reicht den Frame an den PHY weiter.
Die MPDU-Referenznummer wird dabei fortlaufend inkrementiert und beim Versen-
den ebenfalls übergeben. Weitere Informationen zum Empfang der Frames sowie zu den
Retransmissions sind in den Listings A.8 und A.9 zu finden.
Implementierung 75
Klasse ns3::WtBlockAckManager Jedes versendete Paket, das kein Verwaltungs-
oder Block-ACK-Frame ist, wird zudem für eventuelle Retransmissionen in einem Block-
ACK-Manager gespeichert (siehe Listing A.6). Bei der Verarbeitung des Block-ACK-
Frames der Gegenstelle werden die bestätigten Pakete aus dem Block-ACK-Manager
entfernt. Die verbleibenden Pakete bilden die Basis der Retransmission-Abwicklung.
Ursprünglich interagiert die Block-ACK-Manager-Klasse ns3::BlockAckManager mit
den EDCA- oder DCF-TXOPs auf der Grundlage von Block-ACK-Agreements.
Da WiLDToken grundsätzlich auf Block-Acknowledgement aufbaut, sind keine ent-
sprechenden Vereinbarungen notwendig. Außerdem findet WiLDToken-Block-ACK in
ns3::MacLow und nicht in den TXOPs statt. Daher wurde ns3::WtBlockAckmanager
als Kindklasse abgeleitet und angepasst (siehe Abbildung A.2d im Anhang). Dieser wer-
tet die in den Block-ACKs übermittelte Bitmap aus und entfernt die bestätigten Pakete
aus der Retransmission-Queue. Die in der Warteschlange verbleibenden Pakete werden
bei der nächsten Übertragung als Retransmissions abgearbeitet und erneut versendet.
6.4.3. MAC High
Die Klasse ns3::WifiMac repräsentiert eine generische Vorlage für verschiedene Arten
des Wifi-Medienzugriffs. Die ns-3-Wifi-Architektur sieht eine einfache Vererbungsfolge
mit der Kindklasse ns3::RegularWifiMac vor. Diese implementiert mit ihren weiteren
Bestandteilen (siehe Abschnitt 6.2.2) einen DCF-basierten Medienzugriff.
Um zwischen DCF und WiLDtoken zu differenzieren und eine abgeschlossene und den-
noch kompatible Umgebung zu schaffen, wurde mit ns3::WtWifiMac und den Kindern
ns3::AdhocWtMac, ns3::ApWtMac und ns3::StaWtMac eine zweite Vererbungslinie
aufgebaut, wie Abbildung A.1 im Anhang zeigt.
Klasse ns3::WtWi�Mac Die Klasse ns3::WtWifiMac beinhaltet im Vergleich zu
ihrer Geschwisterklasse ns3::RegularWifiMac nicht viele neue Funktionalitäten. Sie
repräsentiert, wie in der Architektur in Abbildung 6.6 gezeigt, als abstrakte Klasse die
gesamte MAC-Funktionseinheit. Ihre Hauptaufgabe ist die Instantiierung der einzel-
nen MAC-Bestandteile und deren Verknüpfung über Callback-Funktionen, wie in Lis-
ting A.11 gezeigt wird.
Abschließend wird der Einsprungspunkt für den in Abschnitt 6.4.5 beschriebenen Zu-
standsautomaten durch Einplanen des initialen Sync-Timeouts gesetzt. Um die Sende-
limits von außen konfigurieren zu können, wurden als zweite Änderung zwei neue Ei-
genschaften SendLimitByte und SendLimitTime hinzugefügt, mit Standardeinstellungen
Implementierung 76
versehen und mit den entsprechenden Getter-und Setter-Methoden verknüpft (siehe Lis-
ting 6.2))
Listing 6.2: Auszug aus ns3::WtWifiMac (src/wifi/model/wt-wifi-mac.cc): Attribute für Sendeli-mits
620 . . .621 . A d d A t t r i b u t e ( " SendLimi tBy te " , " Number o f b y t e s t o send u n t i l t o k e n i s p a s s e d on t o p e e r " ,622 U i n t e g e r V a l u e ( 6 5 5 3 5 ) ,623 MakeUin tege rAcces so r (&WtWifiMac : : Se tSendLimi tBy te ,624 &WtWifiMac : : Ge tSendLimi tBy te )
,625 MakeUintegerChecker < u i n t 3 2 _ t > ( ) )626 . A d d A t t r i b u t e ( " SendLimitTime " , "Maximum t ime s t a t i o n can occupy t h e medium "627 " t o send d a t a u n t i l t o k e n i s p a s s e d on t o p e e r " ,628 TimeValue ( M i l l i S e c o n d s ( 4 ) ) ,629 MakeTimeAccessor (&WtWifiMac : : Se tSendLimi tTime ,630 &WtWifiMac : : GetSendLimitTime ) ,631 MakeTimeChecker ( MicroSeconds ( 1 0 0 ) , M i l l i S e c o n d s ( 1 0 ) ) )632 . . .
Das Ausgliedern von WiLDToken-Frames (Sync-Request/-Reply und Token) obliegt eben-
falls der Klasse ns3::WtWifiMac und findet in der Methode WtWifiMac::Receive()
statt, die als Callback für ns3::MacRxMiddle fungiert. WtWifiMac::Receive() ist
in src/wifi/model/wt-wifi-mac.h als virtual definiert und wird von den Kindern
überschrieben, um Management-Frames (Beacons, Probe Requests/Responses, ...) ver-
arbeiten zu können. Unbekannte Pakete werden dann an die Mutterklasse weitergereicht.
Daher ist es ausreichend, die Ausgliederung der WiLDToken-Frames hier zu implemen-
tieren (siehe Listing A.13).
Klassen ns3::AdhocWtMac, ns3::ApWtMac und ns3::StaWtMac Die Klassen
ns3::AdhocWtMac, ns3::ApWtMac und ns3::StaWtMac erben als Kindklassen von der
Elternklasse ns3::WtWifiMac. Ihre grundsätzliche Funktion unterscheidet sich nicht
von der der Geschwisterklassen ns3::AdhocWifiMac, ns3::ApWifiMac und ns3::
StaWifiMac. Abgesehen von der Namensänderung sind keine WiLDToken-spezifischen
Anpassungen notwendig. Daher wird auf eine umfangreiche Beschreibung an dieser
Stelle verzichtet.
6.4.4. Queue-Management
Der Pfad der Pakete durch den MAC unterscheidet sich zwischen ns-3-Wifi- und WiLD-
Token-Architektur im Wesentlichen durch den veränderten Queueing- und Medienzu-
griffsmechanismus. Die Schnittstellen zu den darüber und darunter liegenden Schichten
ändern sich aufgrund der Erweiterung der Vererbung nicht.
Ausgehende Pakete werden von WtWifiMac::Enqueue() beziehungsweise den ent-
sprechenden Implementierungen der Kindklassen entgegengenommen und an WtTxop::
Implementierung 77
Enqueue() weitergereicht. Bei Freigabe durch ns3::WtManager fließen die Pakete
über WtMacLow::StartTransmission() in den ns3::WtMacLow, wo Aggregierung
und Block-ACK-Abwicklung stattfinden, bevor sie als A-MPDU an den PHY überge-
ben werden.
Eingehende Pakete werden vom PHY an WtMacLow::ReceiveOK() (beziehungsweise
WtMacLow::ReceiveError()) übergeben und vom ns3::WtMacLow deaggregiert und
durch die Block-ACK-Abwicklung gereicht. Control-Frames werden hier bereits ausge-
gliedert. Daten- und Management-Frames gehen durch ns3::MacRxMiddle an ns3::
WtWifiMac und werden von WtWifiMac::Receive() entgegen genommen (siehe Ab-
schnitt 6.4.3).
Klasse ns3::WtTxop Die Klasse ns3::WtTxop leitet sich aus den beiden regulä-
ren Klassen ns3::DcaTxop und ns3::EdcaTxopN ab. Wie diese beiden beinhaltet sie
die notwendige Logik, um Pakete in einer Sendewarteschlange zwischenzuspeichern.
Als Warteschlange dient dabei allen dreien ein Objekt der Klasse ns3::WifiMacQueue
(siehe auch Abbildung A.2c).
Ursprünglich sitzt der Dequeueing-Mechanismus in ns3::MacLow, wie eine Analyse
des Quellcodes ergeben hat. Die TXOP (DcaTxop oder EdcaTxop) gewinnt den Wett-
bewerb um das Medium und darf ein Paket nach unten weiterreichen. ns3::MacLow
nimmt dieses entgegen und entnimmt dann aus der gleichen Sendewartschlange (=Ver-
kehrsklasse) solange Pakete an den gleichen Empfänger, bis die maximale Größe der
A-MPDU erreicht ist.
In ns-3-WiLDToken findet eine Verlagerung der Intelligenz statt: Die jeweils sendebe-
rechtigte Entität von ns3::WtTxop erhält für T XOPQ Zugriff, das heißt, sie darf bis
zum Erreichen ihrer Sendelimits Pakete aus der Queue entnehmen und an ns3::WtMac-
Low weiterreichen. Entsprechende Zählervariablen halten die Erreichung des Sendeli-
mits nach.
Die eigentliche Dequeueing-Logik liegt in der Funktion WtTxop::NotifyAccessGran-
ted(), die von ns3::WtManager aufgerufen wird, um der betreffenden ns3::WtTxop
Zugriff zu gewähren (siehe Listing A.14). Da die Pakete bereits im MAC High mit den
entsprechenden Kopfdaten versehen werden, wird an dieser Stelle lediglich die Sequenz-
nummer eingefügt und das Paket an den WtMacLow weitergereicht. Die Übergabe an
ns3::WtMacLow erfolgt über die Schnittstellenfunktion WtMacLow:: StartTransmission().
Obwohl die Erzeugung der WiLDToken-Management-Pakete in ns3::WtMacLow pas-
sender wäre, ist diese derzeit noch in ns3:WtTxop implementiert, da an dieser Stel-
le alle benötigten Abhängigkeiten aufgelöst sind, insbesondere die Verknüpfung mit
Implementierung 78
ns3::MacTxMiddle zur konsistenten Erzeugung konsekutiver Sequenznummern. An-
hand der in Abschnitt 6.4.1 gezeigten WiLDToken-Header-Definitionen werden die ent-
sprechenden Sync- und Token-Pakete generiert und direkt an ns3::WtMacLow weiterge-
reicht.
Die Belegung der Adressfelder erfolgt dabei anhand von Tabelle 4.2. Es folgen Sequenz-
nummer, Fragmentierungsoptionen und Sendeparameter. Da es sich um Verwaltungspa-
kete handelt, wird zudem das Flag NoRetry gesetzt. Abschließend erfolgt die Übergabe
an den WtMacLow über WtMacLow::StartTransmission(). Die Erzeugung der Fra-
mes wird in Listing A.15 bis A.17 im Anhang gezeigt.
Klasse ns3::MacRxMiddle In ns-3 sorgt die Klasse ns3::MacRxMiddle für die
Weiterleitung empfangener Daten- und Management-Frames aus dem MAC Low an den
MAC High (Control frames werden bereits im MAC Low ausgewertet). Damit auch
WiLDToken-Frames weitergeleitet werden, sind entsprechende Erweiterungen notwen-
dig (siehe Listing A.10 im Anhang). Im vorliegenden Fall betrifft dies eine Prüffunktion
(NSASSERT), mit der sichergestellt wird, dass lediglich Daten- und Management-Frames
an ns3::WtWifiMac weitergereicht werden. Mithilfe von NSASSERT können an belie-
biger Stelle im Programm Variablen auf Konformität mit bestimmten Vorgaben geprüft
werden.
6.4.5. Kanalzugri�
Im Folgenden wird die Implementierung des Zustandsautomaten beschrieben, der im
Wesentlichen den Kanalzugriff steuert und den bei der DCF verwendeten Zufalls-Backoff-
Mechanismus ersetzt. Diese besteht im Wesentlichen aus der Klasse ns3::WtManager.
Der initiale Einsprungpunkt in den Zustandsautomaten wird im Konstruktor ns3::Wt-
WifiMac bei der Instantiierung des WtManager-Objekts gesetzt.
Klasse ns3::WtManager Wie in der Geschwisterklasse ns3::DcfManager ist auch
in ns3::WtManager die eigentliche Medienzugriffskontrolle in Form des in Abbildung 4.2
gezeigten Zustandsautomaten umgesetzt (siehe auch Abbildung A.2a). Die Implemen-
tierung des Zustandsautomaten gliedert sich in zwei Teile: Zustandspersistenz und Tran-
sitionslogik.
Die Zustandspersistenz realisiert die Abbildung der möglichen Zustände des Zustands-
automaten (SYNC,WAIT,TX,RX) und des jeweils aktuellen Zustands. Ersteres wird durch
eine Enumeration (enum) WtFsmState umgesetzt, wie Listing 6.3 zeigt. Der aktuelle Zu-
stand wird in einer entsprechenden Variable dieses Typs festgehalten.
Implementierung 79
Listing 6.3: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.h): Liste der Zustände desAutomaten (enum WtFsmState)
175 . . .176 p r i v a t e :177178 enum WtFsmState179 {180 SYNC,181 WAIT,182 TX,183 RX,184 } ;185 . . .
Sync- und Receive-Timeout sind über das ns-3-interne Scheduling-System Simulator::
Schedule implementiert. Über diese können Ereignisse des Datentyps ns3::EventId
über Simulator::Schedule für ein bestimmtes Zeitintervall (ns3::Time) im Voraus ein-
geplant werden (Simulator::Schedule).
Die Transitionen SYNC → WAIT sowie RX,WAIT → SYNC mit den zugehörigen Ak-
tionen (beispielsweise das Erzeugen des Sync-Requests) werden nach Ablauf der jewei-
ligen Timeouts durch Aufruf entsprechender Callback-Methoden ausgelöst (siehe auch
Listings A.18 und A.19 im Anhang).
Die Implementierung der verbleibenden Übergänge WAIT → TX, RX → TX und TX →RX erfolgt in der Benachrichtigungsfunktion NotifyWtFrameReceived. Diese dient als
Callback-Funktion für empfangene WiLDToken-Management-Frames. Abhängig vom
empfangenen Frame-Typ sowie weiterer Randbedingungen erfolgen die einzelnen Zu-
standsübergänge. Mit dem Versenden des neu generierten Token erfolgt der Übergang
TX → RX. Außerdem wird der Receive-Timeout neu eingeplant. Details sind in den
Listings A.20 bis A.22 zu finden.
In der Funktion WtManager::DoGrantAccess() (siehe Listing A.23) wird den einge-
richteten Sendewarteschlangen (ns3::WtTxop) nacheinander Zugriff auf das Medium
gewährt. Die Sendewarteschlangen liegen in Form eines Vektors (std::vector<WtTxop *>)
vor. Mithilfe eines Iterators (const_iterator) wird dieser durchlaufen und für jede
Sendewarteschlange (ns3::WtTxop) deren Funktion WtTxop::NotifyAccessGranted()
aufgerufen. Die Warteschlangen werden dabei vom Konstruktor der Umbrella-Klasse
ns3::WtWifiMac bereits in der Reihenfolge ihrer QoS-Priorität erzeugt und dem Vek-
tor hinzugefügt. Wie in der ursprünglichen Konfiguration werden auch bei WiLDToken
alle Sendewarteschlangen (Nqos und Qos) eingerichtet. Das Attribut ”QosSupported”
entscheidet schließlich darüber, welche genutzt werden.
Evaluierung 81
7. Evaluierung
Im vorangegangenen Kapitel 6 wurde die Implementierung von WiLDToken innerhalb
des Netzwerksimulators ns-3 beschrieben. Hierfür wurden zunächst die verschiedenen
Implementierungsmethoden vorgestellt und Simulation als geeignete Methode ausge-
wählt. Anschließend wurde die Wahl von ns-3 als Simulationswerkzeug begründet und
die Architektur und Implementierungsdetails von WiLDToken erläutert.
Zur Feststellung der Leistungsfähigkeit des Protokolls WiLDToken und seiner Imple-
mentierung werden in diesem Kapitel die Durchführung und Bewertung der Evaluie-
rung beschrieben. Im Sinne einer strukturierten Herangehensweise werden zunächst die
Messgrößen und -variablen identifiziert und die Vorgehensweise bei der Erhebung der
Daten einschließlich der Datenquellen beschrieben. Den Hauptteil des Kapitels nimmt
die Durchführung und Auswertung der Messungen anhand entworfener Szenarien ein.
Das Kapitel schließt mit einer zusammenfassenden Diskussion der Ergebnisse.
7.1. Messgröÿen und -parameter
Wie beispielsweise Kahlert beschreibt, ist das Ziel bei der Analyse eines Systems ”die
Bestimmung der Abhängigkeit der Ausgangsgrößen des Systems von seinen Eingangs-
größen” ([Kah13, S. 15f.]). Im vorliegenden Fall bildet die Simulation von WiLDTo-
ken das System mit Eingangsgrößen wie Distanz und Modulation und Ausgangsgrößen
wie beispielsweise Datenrate oder Latenz. Die zugehörigen Eingangsgrößen (Messpa-
rameter) und Ausgangsgrößen (Messgrößen) werden in diesem Abschnitt erfasst und
beschrieben.
7.1.1. Messparameter
Dieser Abschnitt widmet sich der Identifikation und Quantifizierung von Messparame-
tern für die Evaluierung von WiLDToken. Es wird betrachtet, welche Rolle die identifi-
zierten Parameter spielen und welche Auswirkungen auf die Ausgangsgrößen zu erwar-
ten sind. Außerdem wird erarbeitet, innerhalb welcher Wertebereiche eine Variation der
Parameter stattfinden soll.
Distanz Die Distanz zwischen den Knoten stellt im Kontext von Langstrecken-Punkt-
zu-Punkt-Verbindungen einen, wenn nicht sogar den wichtigsten Parameter dar. Wie
die Ausführungen und mathematischen Modellierungen in Kapitel 4 zeigen, bewirkt die
Evaluierung 82
Erhöhung der Distanz eine größere Ausbreitungsverzögerung und damit verringerten
Durchsatz sowie erhöhte Latenz.
WiLD-Links überspannen üblicherweise, wie eingangs erwähnt, Distanzen zwischen
wenigen hundert und mehreren Dutzend Kilometern. Daher werden für Messungen mit
variabler Distanz als untere beziehungsweise obere Schranke für die Distanz 100 Me-
ter respektive 50 km festgelegt. Für Messungen mit fixer Distanz wird exemplarisch ein
Link mit 12 km Länge angenommen.
Transportprotokoll Aufgrund des Paketaufbaus und des unterschiedlichen Verhal-
tens von Transmission Control Protocol (TCP) und UDP spielt auch die Wahl des Trans-
portprotokolls eine Rolle bei der Leistungsbewertung. Durch den im Vergleich zu UDP
komplexeren TCP-Header ergibt sich dort ein größerer Overhead. Während UDP-Test-
applikationen wie ns3::UdpClientApplication oder iperf ([DEM+]) den Link mit
der konfigurierten Datenrate ”fluten”, messen die TCP-internen Verkehrskontrollmecha-
nismen (Slow Start, Congestion Control) diesen aus und bestimmen die nötigen Parame-
ter selbst.
Die Auswirkungen beim Einsatz von TCP auf WLAN-Verbindungen werden beispiels-
weise von Rech ([Rec12, S. 449f.]) behandelt. Wie der Autor dort unter anderem an-
merkt, werden durch die Übertragungssicherung verursachte Retransmissions und da-
mit einhergehende erhöhte Paketlatenzen von TCP unter Umständen als Congestion in-
terpretiert und führen zu zusätzlichen Übertragungswiederholungen in der Transport-
schicht. Sofern nicht anders vermerkt, werden alle unten beschriebenen Szenarien mit
UDP unter Inkaufnahme der damit verbundenen Vor- und Nachteile durchgeführt.
Paketgröÿe Die Paketgröße der Transportschicht-Applikation stellt ebenfalls eine Mess-
variable dar. Kleinere Pakete bedeuten mehr Overhead und folglich eine verringerte Da-
tenrate. Je nach Paketgröße wird außerdem unter Umständen die Grenze von 64 Subfra-
mes pro A-MPDU erreicht, bevor die anderen Sendelimits erreicht sind. Dies kann in
einer Untersaturierung des Mediums resultieren und in der Folge die Datenrate ebenfalls
reduzieren.
Die Paketgröße beträgt im vorliegenden Fall, sofern nicht anders angegeben, 1450 Byte
Transportschicht-Nutzlast. Zuzüglich der Header von Transport- und Vermittlungsschicht
ergibt sich so eine MAC-Nutzlast von 1478 respektive 1490 Byte (UDP/TCP).
Evaluierung 83
Applikationsdatenrate/Linksättigung Die Applikationsdatenrate wird auf Trans-
portprotokollebene festgelegt und beschreibt die Menge an Daten, mit der die entspre-
chende Applikation (beispielsweise ns3::UdpClient, iperf) den Link bedient. Eine hö-
here Applikationsdatenrate führt zu einer höheren Linksättigung bis hin zur Übersätti-
gung, falls die Applikationsdatenrate die Nutzdatenrate des Links übersteigt. Im Fall ei-
ner Linkübersättigung ist ein Ansteigen der Latenz zu erwarten, da die durchschnittliche
Paketankunftsrate höher ist als die durchschnittliche Bedienrate. Infolgedessen nimmt
die Anzahl der Pakete in der Warteschlange stetig zu. Das Sättigungsverhalten ist ab-
hängig vom Transportprotokoll (siehe oben).
Sendelimit Zeit/Daten Der Belegungsanteil einer WiLDToken-STA wird implizit
über das Sendelimit festgelegt. Es kann daher angenommen werden, dass ein größeres
Sendelimit in der Folge eine höhere Datenrate bewirkt. Dieser Parameter ist insbesonde-
re für die Analyse der Fairness zwischen den beiden Partizipanten relevant.
Vorgabe für diesen Wert sind die bereits mehrfach erwähnten 4 ms aus [IEE04] bezie-
hungsweise 65535 Byte aus [IEE12b]. Der Wertebereich liegt für Messungen mit varia-
blem Sendelimit zwischen 100 µs und 10 ms respektive 1023 und 65535 Byte.
Emp�ndlichkeit/Rauschabstand Um einen korrekten Empfang zu gewährleisten,
ist beim Empfänger ausreichend Signalstärke und Rauschabstand (SINR) notwendig.
Höherwertige Modulierungen stellen dabei gleichsam höhere Anforderungen an die-
se Parameter, um die OFDM-Symbole korrekt interpretieren zu können. Eine genaue
Übersicht ist auf Basis der Angaben im Standard ( [IEE12b, S. 1534, 1580, 1612, 1647,
1744] und [IEE13, S. 306ff.]) durch von Nagy beziehungsweise Mahadevappa aufge-
stellt worden (siehe [vN14, MtB03]). Unzureichende Signalstärke oder Rauschabstand
haben direkten Einfluss auf die Bitfehlerrate und damit auch auf den Durchsatz.
PHY-Parameter: Modulierung, Bandbreite, MIMO Die Wahl der Parameter für
Bitübertragungsschicht und Übertragungskanal hat ebenfalls Einfluss auf die unten be-
schriebenen Messgrößen. Wie Tabelle 2.1 zeigt, ist unter anderem die Nutzdatenrate di-
rekt abhängig von der primär durch Modulierung, Bandbreite und Nutzung von MIMO
bestimmten Bruttodatenrate. Um die Bitfehlerrate konstant zu halten, ist außerdem bei
höherwertigen Modulationsstufen ein größerer Rauschabstand (SINR) notwendig, da an-
sonsten aufgrund steigender Übertragungswiederholungen Datenrate und Latenz eben-
falls negativ beeinflusst werden.
Evaluierung 84
Die Wahl der PHY-Parameter wird durch ns-3 bereits eingeschränkt, da letzteres in der
eingesetzten Version 3.24 lediglich einen räumlichen Datenstrom und somit kein MIMO
unterstützt (siehe Abschnitt 6.2).
Die Auswirkungen bei Änderung der Kanalbandbreite stellen sowohl bei DCF als auch
bei WiLDToken durch die Verdopplung der OFDM-Subkanäle einen linearen Einfluss-
faktor für die Brutto- und somit auch für die Nettodatenrate dar, ebenso wie die Verwen-
dung des kurzen statt des langen Schutzintervalls (siehe Tabelle 2.1). Insbesondere bei
WiLD-Verbindungen ist die Verwendung des langen Schutzintervalls ratsam, um bei mit
steigender Distanz zunehmendem Aufweichen der Symbolgrenzen eine bessere Tren-
nung der einzelnen Symbole zu ermöglichen.
Sofern nicht anders angegeben, erfolgen die Versuche mit einer Modulation von MCS 7
bei langem Schutzintervall und einer Kanalbreite von 20 MHz.
7.1.2. Messgröÿen
Neben den im Vorabschnitt beschriebenen Messvariablen als Eingangsgrößen bilden die
Messgrößen den zweiten Teil der Betrachtung im Rahmen der Evaluierung. Der folgen-
de Abschnitt dient dazu, die verschiedenen Messgrößen zu definieren und zu beschrei-
ben.
Durchsatz/Datenrate Als Durchsatz beziehungsweise Nutzdatenrate wird die Ende-
zu-Ende-Datenrate auf Applikationsebene (also Schicht 4 beziehungsweise 7) betrach-
tet. Damit wird ersichtlich, welche Datenrate Upper Layer-Protokollen und realen Ap-
plikationen von der Transportschicht tatsächlich zur Verfügung gestellt wird.
Latenz Wie beim Durchsatz wird auch die Latenz Ende-zu-Ende auf Applikations-
ebene erhoben. Das bedeutet, dass auch die Verweildauer der Frames in der Sendewarte-
schlange in die Latenz einbezogen wird. Infolgedessen ist zu erwarten, dass die Latenz
bei übersättigtem Link überproportional stark ansteigt.
Sendeanteil Der Sendeanteil spiegelt den jeweiligen Anteil βSTA der beiden Stationen
an der Gesamtdatenrate als Summe der Einzeldatenraten (DRSTA) wider:
βSTAn =DRSTAn
DRSTA1 +DRSTA2,n ∈ {1,2} (34)
Evaluierung 85
Daher handelt es sich hierbei um eine dimensionslose Messgröße mit dem Wertebereich
0≤ βSTAn ≤ 1, die im Sekundenintervall erhoben wird.
Paketverlustrate Die Paketverlustrate als Messgröße repräsentiert durch Kollisionen
oder Bitfehlerrate korrumpierte oder durch Replays wiederholt übertragene Frames, die
von PHY respektive MAC verworfen werden, bezogen auf die Summe der insgesamt
übertragenen Pakete. Zu unterscheiden sind hierbei:
• PHY-Drops: Pakete, die durch Kollisionen oder BER beschädigt wurden
• MAC-Drops: Pakete, die im Media Access Control (MAC) nach Weiterleitung
durch den PHY MAC verworfen wurden
Zur Erfassung stellt ns-3 die beiden Trace-Sources PhyRxDrop und MacRxDrop bereit
(siehe [nP15a]). Da es sich bei WiLDToken im Gegensatz zur DCF um ein kollisi-
onsfreies Medienzugriffsprotokoll handelt, ist zu erwarten, dass PHY-Drops dort nur
aufgrund unzureichender Signalstärke oder durch Bitfehler auftreten. MAC-Drops wur-
den während der Vorarbeiten zu den Simulationen weder bei der DCF- noch bei der
WiLDToken-Simulation beobachtet.
Token-Verlustrate Analog zur Paketverlustrate gibt die Token-Verlustrate als Ab-
hängige der Bitfehlerrate Aufschluss darüber, wie häufig eine Synchronisation zwischen
den beteiligten Stationen stattgefunden hat. Als Datenquelle dient eine eigens implemen-
tierte Trace Source (TokenLoss), die beim Auslösen des Receive-Timeouts getriggert
wird. Eine hohe Token-Verlustrate deutet auf eine schlechte Linkqualität oder instabile
Stationen hin.
7.2. Messdurchführung
In diesem Abschnitt werden die Erfassung und Verarbeitung der Daten sowie die Versuchs-
und Auswertungsbedingungen dokumentiert. In der Simulation wird eine übliche Lang-
strecken-Punkt-zu-Punkt-Verbindung zwischen zwei WLAN-Knoten ohne Beeinträch-
tigung von Sichtverbindung oder Fresnelzone simuliert. Das 5GHz-Band stellt ausrei-
chend überlappungsfreie Übertragungskanäle bereit und bildet daher eine gute Basis
für vermaschte Funknetze mit einer großen Anzahl benachbarter Verbindungen. Daher
wird in der Simulation ein Kanal (Kanal 54 bei 5270 MHz) aus diesem Frequenzband
verwendet. Um die Sendeleistung innerhalb der gesetzlichen Regulationsvorgaben zu
halten (1W EIRP), findet eine entsprechende distanzabhängige Anpassung des Anten-
nengewinns und der Sendeleistung der WLAN-Karte statt.
Evaluierung 86
Um eine flexible Parametrisierung der Simulation zu ermöglichen, ist eine Exposition
der oben beschriebenen Messvariablen durch die Bereitstellung entsprechender Kom-
mandozeilenparameter vorgesehen.
Sofern nicht anders angegeben, beträgt die Simulationsdauer der unten beschriebenen
Szenarien 12 Sekunden, davon 2 Sekunden Leerlauf und 10 Sekunden Datenübertra-
gung. Die Erhebung der Daten beginnt mit dem Start der Applikation bei t = 2 Sekunden.
Die Messdauer von 10 Sekunden wurde als Kompromiss zwischen der insbesondere bei
komplexen Szenarien langen Gesamtsimulationsdauer (teilweise mehrere Tage für ein
Szenario) und einer aussagekräftigen Datenbasis gewählt. Bei einer Messdauer von 10
Sekunden und einer geschätzten durchschnittlichen Übertragungsdauer von etwa 10 ms
einschließlich Ausbreitungsverzögerung und Contention Window finden in diesem Zeit-
raum etwa 1000 Contention-Verfahren beziehungsweise Token-Handover statt. Damit
sollte eine ausreichende Datenbasis gewährleistet sein.
Um für die beteiligten Pseudozufallsfunktionen die statistische Streuung zu mitteln und
Messfehler auszuschließen, werden alle Versuche fünfmal wiederholt. Über die Ergeb-
nisse der einzelnen Versuchsdurchführungen wird der Mittelwert gebildet. Ein entspre-
chendes Script findet sich auf dem beiliegenden Datenträger.
7.2.1. Verkehrsgenerierung
Als Quelle für die benötigten Nutzdaten werden die in Tabelle 7.1 gezeigten ns-3-Appli-
kationen mit ihren zugehörigen Helper-Klassen verwendet, die die Konfiguration der
Applikationsdatenrate über die Angabe der Paketgröße und des Paketintervalls vorse-
hen.
Tabelle 7.1: Simulation: Applikationen zur Datenerzeugung (TCP und UDP) (nach eigener Dar-stellung)
Transportprotokoll Client Server
UDP ns3::UDPClient ns3::UDPServer
TCPns3::OnOffApplication ns3::PacketSink
ns3::TcpSocketFactory
Sofern nicht anders angegeben, erfolgen alle Messungen im Rahmen der unten erstellten
Szenarien mit bidirektionalem Verkehr, um das Verkehrsverhalten auf einem Backhaul-
Link rudimentär nachzubilden. Zu diesem Zweck wird auf beiden Teilnehmern je eine
Client- und Serverapplikation installiert. Sofern nicht anders angegeben, wird für die
Szenarien eine Applikationsdatenrate von 33 MBit/s bidirektional (in Summe 66 MBit/s)
konfiguriert.
Evaluierung 87
7.2.2. Datenerhebung
ns-3 stellt verschiedene Methoden zur Verfügung, um zur Laufzeit einer Simulation oder
zu deren Ende Leistungsdaten zu erfassen und persistent zu speichern. Im Folgenden
werden die Werkzeuge FlowMonitor, Trace Sources und Packet Capture (PCAP) im
Kontext der Evaluierung von WiLDToken beschrieben.
FlowMonitor Mit dem FlowMonitor steht in ns-3 ein Framework für die Erfassung
und Verarbeitung von Leistungsdaten bereit. FlowMonitor wurde von Carneiro in [CFR09]
vorgestellt und beschrieben. Daher wird an dieser Stelle auf eine detaillierte Beschrei-
bung verzichtet.
Leistungsmetriken werden in FlowMonitor auf Basis von TCP/UDP- und IP-Verbin-
dungen erhoben. Beispiele für solche Leistungsmetriken sind unter anderem gesendete
und empfangene Pakete und Bytes sowie durchschnittliche Latenz und Jitter. Als inter-
ne Datenquelle dienen dabei applikationsspezifische FlowProbes. Die einzelnen Flows
werden bei der Auswertung über einen FlowClassifier differenziert. Abbildung 7.1
zeigt die Architektur von FlowMonitor.
Abbildung 7.1: ns-3: FlowMonitor-Architektur (Quelle [CFR09])
In der WiLDToken-Simulation (siehe beiliegender Datenträger) wird FlowMonitor ver-
wendet, um auf Applikationsebene Leistungsdaten wie gesendete und empfangene Pake-
te, Durchsatz und Verzögerung je Flow sowie in Summe zu erfassen. Zu diesem Zweck
enthält die Simulation eine eigene Auswertungsmethode am Simulationsende, mit de-
ren Hilfe die nötigen Berechnungen durchgeführt werden. Die Daten werden entweder
ausführlich oder im CSV-Format in der Konsole ausgegeben und bei entsprechendem
Parameter persistent in einer Textdatei gespeichert.
Evaluierung 88
Außerdem wird FlowMonitor in Kombination mit Simulator::Schedule() verwen-
det, um für die Erhebung der Fairness den sekündlichen Durchsatz aufzuzeichnen. Hier-
zu wurde eine Methode mit pseudo-rekursiven Aufruf von Simulator::Schedule()
und CSV-Ausgabe erstellt (siehe ebenfalls Simulation im Anhang).
Trace Sources Als weitere Datenquelle werden die von ns-3 zur Verfügung gestellten
Trace Sources genutzt (siehe [nP15a]), insbesondere die Trace Sources MacTxDrop,
PhyTxDrop, PhyRxDrop und MacRxDrop (siehe ”Paketverlustrate” weiter oben). Die
Auswertung erfolgt über zu implementierende Trace Sink-Methoden (siehe [nP16b]).
Quellen und Senken werden über das Config-Subsystem miteinander verknüpft.
PCAP ns-3 bietet Netzwerkgeräten über eine entsprechende ”facility” die Möglich-
keit, Paket-Captures im PCAP-Format zu erzeugen ([nP16b]). Die in der Simulation ver-
wendeten ns3::WifiNetDevices nutzen diese Möglichkeit, die sich entweder global
mit helper.EnablePcapAll(prefix ) oder für einzelne Geräte oder Knoten aktivie-
ren lässt (helper.EnablePcap (prefix, device )). Die PCAP-Traces werden ver-
wendet, um die Funktionsweise der Sync-Operation sowie den Aufbau der A-MPDUs
zu veranschaulichen.
7.2.3. Szenarienbildung
Um eine zielführende und effektive Erhebung der Leistungsfähigkeit zu ermöglichen,
werden aus der oben beschriebenen Vielzahl an Messparametern und -größen gezielt
Kombinationen ausgewählt und in Szenarien gruppiert. Diese sollen die tatsächlichen
Einsatzbedingungen möglichst realistisch reflektieren.
Die Ergebnisse der Evaluierung werden mithilfe geeigneter Darstellungsformen (bei-
spielsweise Linien- oder Balkendiagramme) veranschaulicht. Sofern nicht anders ange-
geben, wird für die Diagrammdarstellungen die folgende Farbkodierung verwendet:
• Rot: DCF (mathematisches Modell)
• Blau: DCF (Simulation in ns-3)
• Orange: WiLDToken (mathematisches Modell)
• Lila: WiLDToken (Simulation in ns-3)
Die Diagramme wurden mit pgfplot aus den von der Simulation erstellten CSV-Dateien
generiert. Für die Konvertierung der Daten sowie die Berechnung des Durchschnitts be-
ziehungsweise der Minima/Maxima über die Versuchsdurchläufe wurden entsprechende
Scripte erstellt.
Evaluierung 89
7.3. Szenario 1: Synchronisierung und Token-Austausch
Dieses Szenario dient der Validierung des in Abschnitt 4.2.2 beziehungsweise Abbil-
dung 4.2 beschriebenen Ablaufs des Synchronisierungsvorgangs. Hierzu zählt auch eine
anschauliche Darstellung des Aufbaus der WiLDToken-Verwaltungspakete sowie der
von WiLDToken erzeugten A-MPDUs anhand von PCAP-Traces der Simulation.
In Abbildung 7.2 wird der Ablauf eines Sync-Requests als Auszug des PCAP-Traces
gezeigt. Die weiß markieren Pakete in Teilabbildung 7.2a stellen die Abfolge Sync-
Request, Sync-Reply und Token dar. Die Teilabbildungen 7.2b bis 7.2c beinhalten die
Header-Formate für die genannten Verwaltungspakete. Wie dort zu sehen, entsprechen
die Belegungen der Felder Type und Subtype den in Tabelle 4.2 angegebenen Belegun-
gen.
(a) Synchronisierungs-Vorgang
(b) Sync-Request
(c) Token(d) Sync-Reply
Abbildung 7.2: WiLDToken: Synchronisierungsvorgang inkl. Darstellung der Header-Formatefür Sync-Request/-Reply und Token (nach eigener Darstellung)
Der PCAP-Trace stammt hierbei von dem Knoten, der die aktive Synchronisierung durch-
laufen und den Sync-Request generiert hat. Dies ist dem Radiotap-Header des Sync-
Reply zu entnehmen, innerhalb dessen beispielsweise über die Felder SSI und Channel
Frequency angezeigt wird, dass es sich um einen empfangenen und nicht um einen ge-
sendeten Frame handelt.
Der Aufbau einer A-MPDU wird im PCAP-Trace in Abbildung 7.3 gezeigt. Zu sehen ist
eine Abfolge von Paketen, beginnend mit einem Block Acknowledgement und gefolgt
von einigen regulären Daten-Frames. Der Abschluss der A-MPDU wird durch einen
Token-Frame gebildet. Dies entspricht dem in Abbildung 4.5 beschriebenen Aufbau.
Evaluierung 90
Abbildung 7.3: WiLDToken: Aufbau der A-MPDU in PCAP-Trace (nach eigener Darstellung)
7.4. Szenario 2: Entwicklung der Datenrate bei steigender Distanz
Um den insbesondere bei großen Distanzen erwarteten Leistungsgewinn von WiLD-
Token aufzuzeigen, wird in Szenario 2 das Verhalten von WiLDToken und DCF bei
steigender Link-Distanz evaluiert. Hierzu wird in Szenario 2a zunächst das in Kapitel 5
aufgestellte Modell mit entsprechenden Simulationen mit ns-3 bei maximaler Aggregie-
rung (Agg.-Faktor 3) beziehungsweise maximalem Sendelimit untermauert. Anschlie-
ßend dient Szenario 2b dem Vergleich zwischen DCF- und WiLDToken-Simulation un-
ter Berücksichtigung verschiedener Aggregierungsstufen (Agg.-Faktor i ∈ {−3,0,3})beziehungsweise Sendelimits (n Byte, n ∈ {1023,8191,65535}).
Szenario 2a Abbildung 7.4 zeigt für Szenario 2a den Vergleich zwischen den mathe-
matischen Modellen und Simulationen für die DCF und ns-3. Für die DCF wurde der
Vergleich zwischen Modell und Simulation bereits in Abschnitt 6.2.3 diskutiert. Daher
wird im Folgenden nur auf den Vergleich zwischen Modell und Simulation für WiLD-
Token eingegangen.
Wie die Abbildung zeigt, liegt der Durchsatz für die Simulation mit ns-3 für WiLDToken
leicht unter der Prognose des mathematischen Modells. Die Simulation erreicht bei 100
Metern eine Nutzdatenrate von 61,525 MBit/s (58,4 MBit/s für 50 km) im Vergleich
zu 62,71 MBit/s (60,1 MBit/s) im Modell. Dies entspricht einer relativen Abweichung
von
δWT−ns3(100m) = 1− 61,5MBit/s62,7MBit/s
≈ 0,019 δWT−ns3(50km) = 1− 58,4Mbit/s60,1MBit/s
≈ 0,028
Der Grund für diese Abweichung kann in der Implementierung selbst zu suchen sein und
beispielsweise durch die Einbettung von WiLDToken in den komplexen ns-3-Netzwerkstack
Evaluierung 91
0 10 20 30 40 500
20
40
60
Distanz (km)
Dat
enra
te(M
bit/s
)
DCF (Modell) DCF (ns-3)Token (Modell) Token (ns-3)
Abbildung 7.4: Szenario 2a: Datenrate über Distanz, Modell und Simulation in ns-3 von DCF(rot/blau) und WiLDToken (orange/lila) (20 MHz, MCS7, 4ms, Long GI,Agg.=3) (nach eigener Darstellung)
oder durch das Zusammenspiel der einzelnen Implementierungskomponenten verursacht
werden. Da es sich aber um eine geringe Abweichung handelt, ist diese nicht ausschlag-
gebend für das Ergebnis des Leistungsvergleichs, da der in Abschnitt 5.2 prognostizierte
Leistungsgewinn dennoch erzielt wurde.
Im Vergleich dazu fällt der Leistungsverlust für die DCF deutlicher aus: Bei maximaler
Aggregierung erreicht die DCF bei 100 m 56,2 MBit/s, bei 50 km 31,7 MBit/s. Damit
ergibt sich der Leistungsverlust über die gemessene Distanz von 50 km wie folgt:
δWT = 1− 58,4MBit/s61,5MBit/s
≈ 0,05 δDCF = 1− 31,7Mbit/s56,2MBit/s
≈ 0,435
Somit bewegt sich der Leistungsverlust über die Distanz für WiLDToken im mittleren
einstelligen Prozentbereich, während die DCF über 50 km etwa 44% ihrer Leistung ein-
büßt.
Szenario 2b Um den Leistungsunterschied zwischen DCF und WiLDToken auch bei
variierenden Aggregationsstufen respektive Sendelimits zu verdeutlichen, zeigt Abbil-
dung 7.5 Durchläufe für beide Protokolle mit den in der Messdurchführung beschriebe-
nen Aggregierungsfaktoren.
Die verschiedenen Sendelimits für WiLDToken äußern sich wie zu beobachten in einer
Reduktion der Nutzdatenrate. Bei 100 m wird bei maximalem Sendelimit eine Nutzda-
tenrate von 61,5 Mbit/s erreicht, bei 50 km verbleiben 58,4 MBit/s. Bei einem Sendelimit
Evaluierung 92
0 10 20 30 40 500
20
40
60
Distanz (km)
Dat
enra
te(M
bit/s
)
DCF, Agg.=3 DCF, Agg.=0 DCF, Agg.=-3Token, 65535 Byte Token, 8191 Byte Token, 1023 Byte
Abbildung 7.5: Szenario 2b: Datenrate über Distanz und Aggregierungsstufe, Simulation vonDCF (blau) und WiLDToken (lila) in ns-3 (20 MHz, MCS7, 4ms, Long GI) (nacheigener Darstellung)
von 8191 Byte reduzieren sich diese auf 59,5 respektive 52,2 MBit/s, für 1023 Byte auf
47,2 beziehungsweise 28,3 MBit/s. Damit ergibt sich eine Leistungsdifferenz von
δWT−8191Byte(100m) = 1− 59,5MBit/s61,5MBit/s
≈ 0,033
δWT−8191Byte(50km) = 1− 52,2MBit/s58,4MBit/s
≈ 0,106
δWT−1023Byte(100m) = 1− 47,2MBit/s61,5MBit/s
≈ 0,233
δWT−1023Byte(50km) = 1− 28,3MBit/s58,4MBit/s
≈ 0,515
Der Leistungsverlust der DCF im Vergleich dazu:
δDCF−Agg0(100m) = 1− 47,9MBit/s56,2MBit/s
≈ 0,147
δDCF−Agg0(50km) = 1− 14MBit/s31,7MBit/s
≈ 0,558
δDCF−Agg−3(100m) = 1− 32,9MBit/s56,2MBit/s
≈ 0,415
δDCF−Agg−3(50km) = 1− 2,43MBit/s31,7MBit/s
≈ 0,923
Im indirekten Vergleich fallen also die Leistungsverluste der DCF zwischen den Aggre-
gierungsstufen hinweg mit Werten zwischen 14,7 und 92,3% deutlich stärker aus als bei
WiLDToken. Ebenfalls deutlich zu sehen ist die konstante Leistungsdifferenz zwischen
WiLDToken und DCF über die verschiedenen Aggregationsstufen hinweg. Im direkten
Vergleich kann durch Einsatz von WiLDToken somit ein deutlicher Leistungsgewinn
Evaluierung 93
erzielt werden:
δDCF−WT−Agg3(100m) =61,5MBit/s56,2MBit/s
−1≈ 0,094
δDCF−WT−Agg0(100m) =59,5MBit/s47,9MBit/s
−1≈ 0,242
δDCF−WT−Agg−3(100m) =47,2MBit/s32,9MBit/s
−1≈ 0,435
δDCF−WT−Agg3(50km) =58,4MBit/s31,7MBit/s
−1≈ 0,842
δDCF−WT−Agg0(50km) =52,2MBit/s14MBit/s
−1≈ 2,73
δDCF−WT−Agg−3(50km) =28,3MBit/s2,43MBit/s
−1≈ 11,5
Entsprechend den Erwartungen fällt der Leistungsgewinn mit WiLDToken insbesondere
bei großen Distanzen deutlicher aus. So lässt sich die Nutzdatenrate bei kleinster Ag-
gregierungsstufe beziehungsweise kleinstem Sendelimit um den Faktor 11, bei größter
Aggregierung um 84% steigern. Dies verdeutlicht den erzielten Leistungsgewinn durch
den Einsatz von WiLDToken.
Szenario 2c Szenario 2c greift den Einfluss der Paketgröße auf den Durchsatz auf.
Hierzu werden in Abhängigkeit von der Distanz die Paketgrößen 100 Byte, 800 Byte
und 1450 Byte als Messvariable verwendet. Die angegebenen Paketgrößen werden als
Durchschnittgrößen interpretiert. Es wird erwartet, dass kleine Pakete aufgrund des schlech-
teren Verhältnisses zwischen Kopf- und Nutzdaten zu einer geringeren Nutzdatenrate
führen.
0 10 20 30 40 500
20
40
60
Distanz (km)
Dat
enra
te(M
bit/s
)
DCF, 1450 Byte 800 Byte 100 ByteToken, 1450 Byte 800 Byte 100 Byte
Abbildung 7.6: Szenario 2c: Datenrate über Distanz und Paketgröße, Simulation in ns-3 von DCF(blau) und WiLDToken (lila) (20 MHz, MCS7, 4ms, Long GI,Agg.=3) (nacheigener Darstellung)
Die Versuchsergebnisse des Szenarios sind in Abbildung 7.6 dargestellt. Wie dort zu
Evaluierung 94
sehen ist, kann auch bei kleineren Paketgrößen durch den Einsatz von WiLDToken eine
deutliche Steigerung der Nutzdatenrate erzielt werden.
Unter Verwendung der DCF kann für die Paketgrößen 800 und 100 Byte ein deutlich
Einbruch der Datenrate auf wenige MBit/s bei etwa 32 km beziehungsweise 3,5 km
beobachtet werden. Ein Grund hierfür ist nicht offensichtlich und konnte im Rahmen
der weiteren Versuche nicht ausfindig gemacht werden.
Hervorzuheben ist ebenfalls der Unterschied zwischen 800 und 1450 Byte Paketgröße
mit WiLDToken. Bei MCS 7 und 20 MHz Kanalbreite beträgt die maximale A-MPDU-
Größe für ein Sendelimit von 4 ms etwa 32500 Byte. In einer kurzen Überschlagsrech-
nung ergibt sich somit je Paketgröße für die Anzahl der MPDUs pro A-MPDU:
NB(1450Byte) =⌊
32500Byte1450+58Byte
⌋≈ 21 NB(800Byte) =
⌊32500Byte
800+58Byte
⌋≈ 37
Der zu beobachtende Leistungsunterschied zwischen den beiden Paketgrößen ist also
auf das höhere Verhältnis zwischen Kopf- und Nutzdaten ηNutz bei einer Paketgröße von
1450 Byte zurückzuführen:
ηNutz(1450Byte) =1450Byte
1450+58Byte≈ 0,962 ηNutz(800Byte) =
800Byte800+58Byte
≈ 0,932
Szenario 2d Der Einfluss des Transportprotokolls auf die Datenrate wird in Szena-
rio 2d herausgestellt. Hierzu wird das bereits weiter oben verdeutlichte unterschiedliche
Verhalten von TCP und UDP über entsprechende Versuchsläufe mit maximalem Sen-
delimit (65535 Byte, 4 ms) untersucht. Abbildung 7.7 zeigt den direkten Vergleich der
Nutzdatenrate für die beiden Transportprotokolle.
Die Nutzdatenrate von TCP liegt in beiden Fällen deutlich unter dem mit UDP erzielten
Durchsatz, was zum einen auf den Overhead durch den größeren Header, zum anderen
auf das unterschiedliche Übertragungsverhalten von TCP zurückzuführen ist. Dennoch
zeigt TCP mit WiLDToken ein lineares beziehungsweise leicht logarithmisches Verhal-
ten wie UDP. Die Datenrate fällt dabei um den Faktor
ηWT−TCP(100m) =54,9MBit/s61,5MBit/s
≈ 0,892 ηWT−TCP(50km) =50,1MBit/s58,4MBit/s
≈ 0,857
geringer aus.
Die Datenrate von TCP auf der DCF bricht hingegen von zu Beginn etwa 51,2 MBit/s
ab etwa 3,5 km deutlich auf 24,8 MBit/s ein, verläuft dann allerdings in Stufen loga-
rithmisch weiter bis 3,42 MBit/s bei 50 km. Vermutlich führen mit steigender Distanz
kollisionsbedingter Paketverlust, Übertragungswiederholungen und damit steigende La-
tenzen dazu, dass die abnehmende Verbindungsqualität durch TCP als Überlastung inter-
pretiert wird und daher unnötige Übertragungswiederholungen auf der Transportschicht
veranlasst werden (siehe nächster Abschnitt und [Rec12, S. 449f.]).
Evaluierung 95
0 10 20 30 40 500
20
40
60
Distanz (km)
Dat
enra
te(M
bit/s
)
DCF (TCP) DCF (UDP)Token (TCP) Token (UDP)
Abbildung 7.7: [Szenario 2d: Datenrate über Distanz für TCP- und UDP-Verkehr, Simulationvon DCF (blau) und WiLDToken (lila) in ns-3 (20 MHz, MCS7, 4ms, Long GI,Agg.=3) (nach eigener Darstellung)
Insgesamt kann festgestellt werden, dass durch den Einsatz von WiLDToken in der Si-
mulation die Nutzdatenrate in Abhängigkeit von der Distanz im Vergleich zur DCF deut-
lich gesteigert werden konnte. Insbesondere beim Einsatz von TCP als Transportproto-
koll trägt WiLDToken dazu bei, den Durchsatz signifikant zu steigern.
7.5. Szenario 3: Entwicklung der Latenz bei steigender
Linksättigung
Eine Verbesserung und Stabilisierung der Latenz wurde in Kapitel 4.1 ebenfalls als Leis-
tungsanforderung festgelegt. Wie sich während der Versuchsdurchführungen unter Ver-
wendung von UDP gezeigt hat, gestaltet sich eine zuverlässige Messung der Ende-zu-
Ende-Latenz als problematisch. Um die maximale Nutzdatenrate zu ermitteln, wird der
Link in den Versuchen durch eine adäquate Wahl der Applikationsdatenrate übersättigt.
Somit entsteht ein Ungleichgewicht zwischen Ankunft- und Bedienrate der Sendewarte-
schlangen, in dessen Folge der Einfluss der Ausbreitungsverzögerung auf die überpro-
portional steigende Latenz schwindet.
Szenario 3a Um dennoch eine Aussage über die Auswirkungen der Distanz auf die
Verzögerung treffen zu können, wird in Szenario 3a die Auswirkung der Linksättigung
auf die Latenz durch Steigerung der Applikationsdatenrate bis hin zur Linkübersättigung
Evaluierung 96
erhoben. Hierzu wird die Applikationsdatenrate für beide Teilnehmer schrittweise um 1
MBit/s von 1 bis 33 MBit/s erhöht. Bei einer Applikationsdatenrate von 2 ∗ 33 = 66
MBit/s und einer Bruttodatenrate von 65 MBit/s (20 MHz, MCS7, Long GI) ist eine
Übersättigung des Links erreicht. Als Nebenbetrachtung wird auch das Verhalten des
Jitters erhoben und dargestellt. Es wird erwartet, dass aufgrund der nahezu konstanten
Datenaustauschrate sowohl Jitter als auch Latenz durch WiLDToken stabilisiert werden
können und letzteres somit für Echtzeitanwendungen besser geeignet ist.
Ausgehend von den Beobachtungen im vorherigen Abschnitt zeigt Abbildung 7.8 die
Ende-zu-Ende-Latenz in Abhängigkeit von der Linksättigung beziehungsweise Appli-
kationsdatenrate. Für die Darstellung der Latenz wurde eine logarithmische Achsenska-
lierung gewählt, um die Entwicklung der Plots zu verdeutlichen.
0 10 20 30 40 50 60 7010−1
100
101
102
103
Datenrate (MBit/s)
Lat
enz
(ms)
0 10 20 30 40 50 60 700
2
4
6
8
10
Datenrate (MBit/s)
Jitte
r(m
s)
Latenz (DCF), 50km 12kmLatenz (Token), 50km 12km
Jitter (DCF), 50km 12kmJitter (Token), 50km 12km
Abbildung 7.8: Szenario 3a: Latenz und Jitter über Applikationsdatenrate, Simulation von DCF(blau/cyan) und WiLDToken (lila/violett) in ns-3 (MCS 7, 20 MHz, 4 ms, LongGI) (nach eigener Darstellung)
Wie zu beobachten ist, verhält sich die Latenz für WiLDToken weitestgehend konstant
und bleibt bis zur Erreichung einer dezidierten Linksättigung (wie im Plot zu sehen et-
wa 40 Mbit/s) unter einer Millisekunde. Bezogen auf die Bruttodatenrate von 65 MBit/s
entspricht dies etwa einer Sättigung von 61,5% sowohl für 12 als auch für 50 km Di-
stanz. Im Gegensatz dazu ist zu beobachten, dass die Latenz unter Verwendung der DCF
bei steigender Applikationsdatenrate ebenfalls stetig (über 5 ms bei 50% Linksättigung)
steigt. Dies ist auf den in Abbildung 2.8 gezeigten Einfluss der Ausbreitungsverzöge-
rung auf das Backoff-Verfahren und die Kollisionen zurückzuführen. Beiden Verfahren
(DCF und WiLDToken) ist gemein, dass die Latenz ab Erreichen einer kritischen Links-
Evaluierung 97
ättigung überproportional ansteigt, da die Ankunftsrate der Sendewartschlange größer
wird als die Bedienrate und somit die Zahl der Pakete in der Queue stetig steigt. Die
entsprechend markanten Punkte werden im Diagramm durch die gepunkteten Hilfslini-
en angedeutet. Folglich kann durch den Einsatz von WiLDToken die Latenz des Links
auslastungs- und distanzabhängig zwischen Faktor 4 (12 km) und 10 (50 km) gesenkt
werden.
Außerdem ermöglicht WiLDToken eine Verbesserung des Jitters, wie ebenfalls Abbil-
dung 7.8 zu entnehmen ist. Der durchschnittliche Jitter schwankt mit WiLDToken, liegt
aber nahezu unabhängig von Linksättigung und Distanz um 500 µs. Eine Stabilisierung
auf etwa 350 µs bei Erreichen der Linksättigung für beide Versuchsdistanzen lässt sich
durch eine konstante Bedienrate bedingt durch bis zum Sendelimit gefüllte A-MPDUs
begründen.
Im Gegensatz hierzu ist mit DCF für den Jitter ein sowohl distanz- als auch sättigungsab-
hängiges Verhalten zu beobachten. Der Jitter beginnt bei geringer Applikationsdatenrate
bei 6,27 ms für 50 km respektive 1,32 ms für 12 km, vermutlich verursacht durch kleine
A-MPDUs und hierdurch häufig stattfindende Contention-Verfahren, nimmt allerdings
mit steigender Linksättigug stetig ab. Eine Stabilisierung bei etwa 690 µs für 50 km
und 500 µs für 12 km ist mit der gleichen Begründung wie bei WiLDToken zu beob-
achten. Die durch die höhere Ausbreitungsverzögerung bei 50 km steigende Kollisions-
wahrscheinlichkeit trägt vermutlich zu einer erhöhten Retransmissionrate und folglich
zu einer Erhöhung des Jitters bei.
Der Grund für die Differenz zwischen beiden Verfahren ist der bei WiLDToken fehlende
Contention-Mechanismus, der durch wechselnde Contention-Window-Größen eine Va-
riabilität der Latenz verursacht und somit zu einer Erhöhung des Jitters beiträgt. Durch
die Stabilisierung des Jitters trägt WiLDToken zu einer besseren Eignung der Links für
Echtzeitdaten bei.
Szenario 3b Um diese Stabilisierung von Jitter und Latenz weiter zu vertiefen, wird
in Szenario 3b die Verteilung der Latenz betrachtet. Hierzu werden für einen statischen
Link mit 12 km Länge über die XML-Exportfunktion von FlowMon entsprechende Hi-
stogramme erstellt. Die Datenrate wurde im Experiment so gewählt, dass der Link knapp
unterhalb der Sättigung arbeitet.
Abbildung 7.9 zeigt die Verteilung der Latenz im Vergleich zwischen WiLDToken und
DCF. Deutlich zu erkennen sind die Erhebungen der Latenzen mit DCF bei t1 = 11,
t2 = 52, t3 = 91 sowie t4 = 132. Diese sind auf das exponentielle Backoff zurückzufüh-
ren. Dabei bewegt sich die Latenz zwischen 0 und knapp über 200 ms. Im Gegensatz
dazu kann für die Latenz mit WiLDToken in einem deutlich begrenzteren Zeitbereich
Evaluierung 98
0 50 100 150 2000
100
200
300
400
500
600
700
800
900
1,000
Zeit (ms)
Pake
teDCF (Delay) WiLDToken (Delay)
Abbildung 7.9: Szenario 3b: Histogramm über die Latenz für DCF (blau) und WiLDToken (lila)(20 MHz, MCS7, 4ms, Long GI, Agg.=3, 12km) (nach eigener Darstellung)
zwischen 0 und 67 ms eine weitestgehende Normalverteilung beobachtet werden. Die-
se beiden Feststellungen bestätigen die in Szenario 3a beobachteten unterschiedlichen
Verhaltensweisen des Jitter.
7.6. Szenario 4: Zusicherung von Fairness über Zeit
In Szenario 4 wird die Fairness zwischen den Stationen unter Verwendung von DCF re-
spektive WiLDToken betrachtet. Dies soll die weiter oben beziehungsweise in [Cha15]
bereits aufgestellte Vermutung respektive Beobachtung untermauern, dass sich über einen
Token Passing-Mechanismus garantierte Fairness zwischen den Stationen herstellen lässt.
Die Versuchsdurchführung besteht aus 5 Versuchsläufen über jeweils 62 s (2 s Leerlauf,
60 s Daten), bei denen im Sekundenintervall die benötigten Daten erhoben werden. Über
diese 5 Versuche werden Minima sowie Maxima ermittelt, um den Bewegungsspielraum
der Protokolle bezüglich der Fairness zu verdeutlichen.
Evaluierung 99
0 10 20 30 40 50 600.3
0.4
0.5
0.6
0.7
Zeit (s)
Ant
eil(
rel.)
DCF (A→ B) DCF (B→ A)Token (A→ B) Token (B→ A)
Abbildung 7.10: Szenario 4a: Fairness zwischen DCF (blau/cyan) und WiLDToken (lila/violett)in ns-3 (blau/lila). Sendelimit 4 ms beidseitig, MCS7, 20 MHz, Long GI, 12km.
Szenario 4a Für Szenario 4a werden auf beiden Stationen gleiche Sendelimits (65535
Byte, 4 ms (=̂ 32500 Byte bei MCS7)) beziehungsweise Aggregierungsstufen (1016)
konfiguriert. Die Messungen erfolgen wie oben beschrieben bei 12 km Distanz, 20 MHz
Kanalbreite, MCS7 und langem GI sowie einer Applikationsdatenrate von 33 MBit/s.
Die beschriebene Betrachtung der Fairness zwischen den beiden Stationen ist in Abbil-
dung 7.10 dargestellt.
Wie zu erkennen ist, variieren die Belegungsanteile der beiden Datenströme unter Ver-
wendung der DCF deutlich zwischen einem relativen Anteil von 0,4 und 0,6, wobei die
Variationen aufgrund der Teilnehmerzahl von zwei symmetrisch sind. Dies ist auf die
zufallsgesteuerte Backoff-Funktion der DCF zurückzuführen. Die Schwankungen im-
plizieren einen negativen Einfluss auf die für Echtzeitanwendungen wie Voice-over-IP
(VoIP) kritischen Parameter Latenz und Jitter (siehe Betrachtung im vorherigen Szena-
rio). Im Vergleich damit sind mit WiLDToken die Anteile lediglich minimalen Schwan-
kungen unterworfen und bleiben nahezu konstant bei etwa 0,5. Die in Szenario 3 festge-
stellte Stabilisierung von Latenz und Jitter durch den Einsatz von WiLDToken ist durch
diese konstante Zusicherung von Sendeanteilen zu begründen.
Szenario 4b Wie bereits beschrieben, kann WiLDToken auch zur gezielten Zuteilung
von Belegungsanteilen des Mediums verwendet werden, beispielsweise für Lastkom-
pensationen oder Verkehrsplanung. In Szenario 4b wird bei gleichen Anfangsbedingun-
Evaluierung 100
0 10 20 30 40 50 600.2
0.3
0.4
0.5
0.6
0.7
0.8
Zeit (s)
Ant
eil(
rel.)
DCF (A→ B) DCF (B→ A)Token (A→ B) Token (B→ A)
Abbildung 7.11: Szenario 4b: Linkratio zwischen DCF (blau/cyan) und WiLDToken (lila/violett)in ns-3 (blau/lila). MCS7, 20 MHz, Long GI, 12 km.
gen wie in Szenario 4a durch eine Halbierung des Sendelimits für eine STA nach 30
s der Datenphase ein Verhältnis der Sendelimits von 2:1 erzeugt, um die Zusicherung
von Sendeanteilen zu veranschaulichen. Als Applikationsdatenrate wird hier 65 MBit/s
verwendet.
Abbildung 7.11 zeigt die Messresultate dieses Szenarios. Deutlich zu sehen ist die Ände-
rung des Sendelimits zum Zeitpunkt t = 30s, die zu einer Verschiebung der Sendeanteile
sowohl für DCF als auch für WiLDToken führt. Die durch die neuen Sendelimits erwar-
teten Sendeanteile werden durch die eingezeichneten Hilfslinien angedeutet.
Zu beobachten ist, dass sich mit WiLDToken die beiden Datenströme unmittelbar nach
der Aktivierung der neuen Sendelimits an diese anpassen. Aus den Messdaten kann für
30s≤ t ≤ 60s eine durchschnittliche Datenrate von etwa 40,1 MBit/s für A→ B und 19,8
MBit/s für B→ A ermittelt werden, für die DCF im gleichen Zeitraum 34,1 respektive
19,2 MBit/s. Damit ergeben sich folgende Sendeanteile β :
βWT−AB =40,1MBit/s
40,1+19,8MBit/s≈ 0,669
βWT−BA =19,8MBit/s
40,1+19,8MBit/s≈ 0,331
βDCF−AB = 1− 34,1Mbit/s34,1+19,2MBit/s
≈ 0,639
βDCF−BA(50km) = 1− 19,2Mbit/s34,1+19,2MBit/s
≈ 0,361
Wie die errechneten Sendeanteile zeigen, kann durch den Einsatz von WiLDToken ei-
ne zuverlässige Zuweisung von Sendeanteilen vorgenommen werden. Beim Einsatz der
DCF ist zwar durch die Konfiguration unterschiedlicher Aggregierungsfaktoren eben-
falls eine Abstufung der Belegungsanteile vorgenommen worden. Die Nutzdatenrate
Evaluierung 101
26283032340
20
40
60
SINR (dB)
Dat
enra
te(M
bit/s
)
26283032340
20
40
60
80
100
Pake
tver
lust
(%)
DCF (Durchsatz) Token (Durchsatz)DCF (Paketverlustrate) Token (Paketverlustrate)
Abbildung 7.12: Szenario 5: Durchsatz und Paketverlust über Rauschabstand zwischen DCF(blau/cyan) und WiLDToken (lila/violett) in ns-3. Sendelimit 4 ms bzw. Agg.=3,MCS7, 20 MHz, Long GI, 12 km.
beider Datenströme ist dennoch den bereits festgestellten Variationen durch die Zufalls-
Backoff-Funktion unterworfen. Auch können die Sendeanteile nicht mit der gleichen
Zuverlässigkeit wie mit WiLDToken zugesichert werden.
7.7. Szenario 5: Entwicklung der Datenrate und des Paketverlusts
bei sinkendem Rauschabstand
Die Bestimmung der Bit- beziehungsweise Paketfehlerrate für einen WLAN-Kanal er-
folgt in ns-3 in der PHY-Implementierung über den Rauschabstand, der für jedes einge-
hende Paket bestimmt und aus dem über einen Interferenz-Helper die Packet Error Ra-
te (PER) errechnet wird. Das Paket wird dem MAC als fehlerhaft empfangen gemeldet,
wenn eine Zufallsvariable den durch die PER vorgegebenen Schwellwert überschrei-
tet7.
Szenario 5 soll den Einfluss von BER/PER auf die Datenrate und den Paketverlust ver-
anschaulichen. Hierzu wird der Rauschabstand von 35 dB schrittweise in Intervallen von
0,1 dB auf 25 dB reduziert. Bei diesem Rauschabstand ist eine zuverlässige Verwendung
des Modulationsschemas MCS 7 nicht mehr möglich (siehe [vN14]).
7Siehe Implementierungsdetails für ns3::YansWifiPhy (YansWifiPhy::StartReceivePacket(),https://www.nsnam.org/doxygen/yans-wifi-phy_8cc_source.html#l00734)
Evaluierung 102
Die Versuchsergebnisse für dieses Szenario sind in Abbildung 7.12 aufgetragen. Wie
dort zu sehen ist, bleibt die Nutzdatenrate sowohl für DCF als auch für WiLDToken bis
zu einem Rauschabstand von etwa 30,2 dB weitestgehend stabil und bricht danach mit
abnehmendem Rauschabstand kontinuierlich ein. Dies korreliert mit einer stetig steigen-
den Paketverlustrate ab etwa 29,5 dB. Interessant ist hierbei die Beobachtung, dass die
Datenrate mit WiLDToken deutlich steiler abfällt als unter der Verwendung der DCF.
Dies ist auf wiederholt auftretende Synchronisierungsphasen zurückzuführen, innerhalb
derer kein Datenverkehr stattfindet.
Es fällt auf, dass die Paketverlustrate der DCF selbst bei ausreichendem Rauschabstand
bei etwa 10 Prozent liegt. Dies ist auf Kollisionen im Wettbewerb um das Medium zwi-
schen den beiden Stationen zurückzuführen. Im Gegensatz dazu erleidet die Kommuni-
kation mit WiLDToken keinerlei Paketverluste, da es sich hierbei um ein gesteuertes und
damit kollisionsfreies Medienzugriffsverfahren handelt (siehe [Ker95, ]).
Es ist weiterhin zu beobachten, dass die Paketverlustrate bei der DCF deutlich stärker
steigt als bei WiLDToken. Dies ist vermutlich ebenfalls auf zunehmende Kollisionen
im Contention-Verfahren zurückzuführen. Interessanterweise sinkt die Paketverlustrate
nach Erreichen eines kritischen Punktes wieder. Vermutlich ist dies auf völlige Einstel-
lung der Kommunikation zurückzuführen und widerspricht den Erwartungen des Autors,
einer Paketverlustrate von 100 Prozent.
7.8. Diskussion
Die in diesem Kapitel durchgeführte Evaluierung zeigt, dass durch die Verwendung von
WiLDToken in einer Vielzahl der betrachteten Szenarien gegenüber der DCF eine deutli-
che Steigerung der Leistungsfähigkeit erreicht werden kann. Insbesondere für große Di-
stanzen ist eine Verbesserung der Nutzdatenrate unabhängig von Aggregierungsfaktor,
Paketgröße und verwendetem Transportprotokoll feststellbar, wie in Szenario 2 beschrie-
ben. Dies ist auf den fehlenden Wettbewerb um das Medium und die deterministische
Kommunikationsstruktur zurückzuführen.
Da infolgedessen keine distanzabhängige Anpassung der am Contention-Verfahren be-
teiligten Protokolltimings mehr notwendig ist, lässt sich mit WiLDToken zudem eine
Stabilisierung der Latenz erreichen. Diese ist außerdem keinen Schwankungen mehr
durch wechselnde Contention-Windows mehr unterworfen. Dies führt zu einer Stabili-
sierung des Jitters und in direkter Folge zu einer besseren Eignung der Verbindung für
Echtzeitkommunikation, beispielsweise Voice-over-IP-Verkehr.
Szenario 4 zeigt die Zusicherung von Sendeanteilen, über die aus Gründen der Verkehrs-
optimierung im Gegensatz zur DCF eine zuverlässige Zusicherung von Nutzdatenraten
Evaluierung 103
oder eine gezielte Verschiebung der Linksymmetrie möglich ist. Dies kommt beispiels-
weise dann zum Tragen, wenn aufgrund der Verkehrscharakteristik eine solche asymme-
trische Anbindung üblich oder notwendig ist (vgl. übliche Endkundenanbindungen über
ADSL/VDSL).
Zusammenfassung und Ausblick 104
8. Zusammenfassung und Ausblick
Als Zielsetzung der vorliegenden Arbeit wird in der Einleitung die Entwicklung, Imple-
mentierung und Evaluierung eines Token Passing-Protokolls für Langstrecken-Punkt-
zu-Punkt-Verbindungen nach IEEE 802.11n im Hinblick auf eine Leistungssteigerung
der Datenrate und Latenz angegeben. Zu diesem Zweck wird das Protokoll WiLDToken
entworfen und in der Netzwerksimulationsumgebung ns-3 implementiert.
Nachdem in der Einleitung die Bedeutung von WLAN-basierten Langstrecken-Punkt-
zu-Punkt-Verbindungen für die Internetversorgung im ländlichen Raum hervorgehoben
wurde, werden in Kapitel 2 die Grundlagen zu Medienzugriffen für IEEE 802.11 und
gesteuerten Medienzugriffen aufgearbeitet. Dies betrifft die Entwicklung und Funkti-
onsweise von CSMA/CA als Medienzugriffsverfahren hinter DCF und EDCA ebenso
wie Token Ring und Token Bus als Prototypen aktueller Token Passing-Verfahren.
Letztere werden in Kapitel 3 im Rahmen des Stands der Forschung für gesteuerte Me-
dienzugriffe für 802.11, insbesondere für Langstrecken-Punkt-zu-Punkt-Verbindungen,
vorgestellt. Hierzu zählt beispielsweise die im Standard [IEE12b] bereits beschriebene
PCF ebenso wie WTRP und VTP als alternative Verfahren für Nahbereichs-Punkt-zu-
Multipunkt-Verbindungen ebenso wie 2P und JazzyMAC für Langstrecken-Links. Die
Funktionsweise der benannten Protokolle wurde dargestellt und die Relevanz für die
vorliegende Arbeit bewertet.
Diese Bewertung dient als Grundlage für den in Kapitel 4 beschriebenen Entwurf von
WiLDToken. Formell und informell werden die einzelnen Bestandteile wie Zustandsau-
tomat, Frame- und Header-Formate, die Vorgehensweise bei Retransmissions und Block
Acknowledgements sowie Aggregierung beschrieben. Außerdem erfolgt in Kapitel 5 ei-
ne rudimentäre mathematische Modellierung einschließlich eines initialen Leistungsver-
gleichs mit dem aus [Rad15] bekannten Modell der DCF. Hierbei zeichnet sich bereits
ab, dass bezüglich der Nutzdatenrate eine theoretische Leistungssteigerung zwischen 15
und 80 Prozent zu erwarten ist.
Kapitel 6 beschreibt die Implementierung von WiLDToken, nachdem zunächst ein Über-
blick über die unterschiedlichen Implementierungsoptionen gegeben wurde, abgeschlos-
sen durch eine kurze Bewertung. Aufgrund dieser Einschätzung wird Netzwerksimu-
lation als geeignete Implementierungsmethode ausgewählt, gefolgt von einer Einfüh-
rung in die Grundlagen der Simulation sowie der Netzwerksimulation mit ns-3. Um
Vergleichswerte zu erhalten, wurde zunächst eine Modellierung von WLAN-basierten
WiLD-PtP-Links erstellt und eine Validierung anhand des Modells aus [Rad15] durch-
geführt. Anschließend wurde die Implementierung und deren Integration in ns-3 be-
schrieben. Ein besonderes Augenmerk lag hierbei auf der Gesamtarchitektur und den
Zusammenfassung und Ausblick 105
in der Entwurfsphase hervorgehobenen Teilaspekten Zustandsautomat, Aggregierung,
Synchronisierung, blockweiser Bestätigung und Retransmissions.
Die Evaluierung dieser WiLDToken-Implementierung findet in Kapitel 7 statt. Dazu
werden zunächst die Messvariablen und -größen identifiziert und die Versuchsdurch-
führung beschrieben. Danach erfolgt die Durchführung der Leistungserhebung und -
bewertung von WiLDToken im direkten Vergleich mit der Langstrecken-WLAN-Simu-
lation aus Kapitel 6 anhand ausgewählter Bewertungsszenarien. Wie sich dort gezeigt
hat, ist durch den Einsatz von WiLDToken eine distanzabhängige Steigerung der Daten-
rate zwischen 15 und 80 Prozent möglich. Auch eine Reduzierung der Latenz sowie eine
Stabilisierung des Jitters aufgrund der deterministischen und kollisionsfreien Kommu-
nikation ist zu beobachten. Da es sich bei WiLDToken um ein kollisionsfreies Protokoll
handelt, fallen zudem gegenüber der DCF keine durch Kollisionen ausgelösten Über-
tragungswiederholungen an. Es ist allerdings zu beobachten, dass die DCF sich unter
erschwerten Übertragungsbedingen (sinkender Rauschabstand) unter Umständen stabi-
ler verhält als WiLDToken.
Folglich wird durch den Entwurf und die Implementierung von WiLDToken aufbauend
auf bereits vorgestellten Token Passing-Verfahren für IEEE 802.11-basierte Langstrecken-
Punkt-zu-Punkt-Verbindungen eine Möglichkeit geschaffen, die Leistungsfähigkeit die-
ser Verbindungen insbesondere für große Distanzen zu verbessern. Damit wurde die zu
Beginn der vorliegenden Arbeit aufgestellte Fragestellung nach Verbesserungspotential
zufriedenstellend beantwortet.
Zu berücksichtigen ist bei der Betrachtung der Messergebnisse allerdings der mit Lang-
strecken-Punkt-zu-Punkt-Verbindungen in Multi Radio-Multi Channel-WMNs stark ein-
geschränkte Anwendungsbereich, für den WiLDToken entwickelt wurde. Die Unterstüt-
zung von mehr als zwei Stationen in einer Point-to-Multipoint (PtMP)- oder Mesh-
Topologie setzt eine deutlich komplexere Ringverwaltung wie beispielsweise in VTP
oder WTRP voraus. Infolgedessen ist mit einem erhöhten Implementierungs- und Kon-
figurationsaufwand für jede Station auszugehen. Für die für WLAN übliche Anwendung
in Kurzstrecken-Punkt-zu-Multipunkt-Topologien bilden die in IEEE 802.11 respekti-
ve 802.11e/n spezifizierten Verfahren DCF beziehungsweise EDCA einen hinreichend
guten Kompromiss zwischen Leistungsfähigkeit, Kollisionsvermeidung und Protokoll-
komplexität. Für Echtzeitanwendungen in diesem Szenario sollte die Implementierung
der PCF verstärkt vorangetrieben werden.
Zusammenfassung und Ausblick 106
Zukünftige Arbeiten
Auch nach der Fertigstellung der vorliegenden Arbeit bietet WiLDToken Potenzial für
künftige Arbeiten. Einen möglichen Ansatz hierfür stellt die Portierung auf ns-3.25 und
die in dieser Version neu hinzugekommenen Funktionen dar. Dies betrifft unter ande-
rem die Unterstützung von MIMO und breiteren Kanälen (siehe [nP16c]. In diesem Zu-
sammenhang steht auch die Portierung auf 802.11ac als Basistechnologie für WiLDTo-
ken und die damit verbundene Steigerung der Datenrate durch höherwertige Modulation
(256-QAM).
Weitere Möglichkeiten sind Erweiterungen beispielsweise um Dienstgüte-Unterstützung
oder adaptive Linksymmetrie. Vorschläge zu den entsprechenden Verfahren wurden be-
reits im Laufe dieser Arbeit erarbeitet, allerdings aus diversen Gründen nicht mit in die
Implementierung aufgenommen und sollen als Abschluss an dieser Stelle kurz vorge-
stellt werden.
Dienstgüte-Unterstützung
Als Erweiterung sieht WiLDToken Dienstgüte-Unterstützung ähnlich wie bei EDCA
mit vier verschieden priorisierten Dienstgüte-Klassen respektive Sendewarteschlangen
(Sprache (VO), Video (VI), Best Effort (BE), Hintergrunddaten (BK)) vor. Abbildung 8.1
zeigt den Aufbau für WiLDToken im direkten Vergleich mit EDCA (vgl. Darstellung in
Abbildung 6.6).
(a) DCF (nach [IEE12b, S. 874, Abb. 9-19]) (b) WiLDToken (nach eigener Darstellung)
Abbildung 8.1: Vergleich Queueing der EDCA und WiLDToken mit QoS
Im Gegensatz zu EDCA agieren die vier Sendewarteschlangen allerdings nicht unabhän-
gig voneinander, sondern werden von einem prioritätsbasierten Scheduling-Mechanismus
Zusammenfassung und Ausblick 107
kontrolliert und gesteuert. Zu diesem Zweck erhält jede Sendewarteschlange Q zwei Ei-
genschaften, die durch den Priority Scheduler ausgewertet werden:
• Priorität PQ: Die Priorität PQ ∈ 0...3,Pi 6= Pj legt fest, in welcher Reihenfolge
die Sendewarteschlangen abgearbeitet werden. Dabei gilt 0 als höchste und 3 als
niedrigste Priorität.
• Sendeanteil T XOPQ: Über den Sendeanteil wird bestimmt, welchen Anteil die
Sendewarteschlange an einer Token-A-MPDU erhält.
Durch die abschließende Aggregierung der unterschiedlichen Verkehrsklassen entsteht
eine so genannte Multi-TID-A-MPDU. Durch die durch PQ vorgegebene feste Reihen-
folge wird eine Konkurrenzsituation unter den Sendewarteschlangen unterbunden. Es
können keine internen Kollisionen entstehen, die von einem Virtual Collision Handler
aufgefangen werden müssten.
Die Festlegung des Sendeanteils T XOPQ je A-MPDU kann entweder relativ zur A-
MPDU-Größe oder absolut erfolgen. Im ersten Fall ändert sich der Anteil, den jede Ver-
kehrsklasse erhält, mit der Größe der A-MPDU. Dadurch wird zwischen allen Verkehrs-
klassen ein gewisser Grad an Fairness gewährleistet, da bei sinkender A-MPDU-Größe
keine Sendewarteschlange zugunsten einer höher priorisierten auf ihre Sendeanteile ver-
zichten muss. Im zweiten Fall garantiert ein fixer Wert in Byte oder Millisekunden einen
größenunabhängigen Anteil an der A-MPDU. Dies bedingt allerdings unter Umständen
den Wegfall von Verkehrsklassen niedrigerer Priorität bei A-MPDUs geringerer Größe,
falls ihnen kein adäquater Anteil gewährt werden kann. In EDCA legt die Größe von
Contention Window und AIFSN die Priorisierung der Queues fest (siehe Tabelle A.1).
Aus diesen wird die in Tabelle A.2 angegebene Priorisierung für WiLDToken-QoS be-
stimmt. Die Berechnung findet sich ebenfalls im Anhang (siehe Gleichung 36).
Sollten in einer QoS-Sendewarteschlange nicht genügend Daten vorhanden sein, um
T XOPQ vollständig auszufüllen, wird der unverbrauchte Teil in einen Guthaben-Topf
überführt, aus dem sich nachfolgende, niedriger priorisierte Klassen bedienen können.
Damit soll eine unnötige Untersättigung des Mediums vermieden werden.
Eine abschließende Bewertung, inwieweit die beschriebene QoS-Implementierung der
EDCA ebenbürtig ist, übersteigt an dieser Stelle den Rahmen der Arbeit. Aus den Beob-
achtungen in dieser Arbeit kann allerdings davon ausgegangen werden, dass den einzel-
nen Verkehrsklassen durch den festgelegten Aufbau der Multi-TID-A-MPDU entspre-
chend eine Priorisierung und ein Sendeanteil zugesichert werden kann. Weiterhin kön-
nen die Erkenntnisse aus der Evaluierung bezüglich Latenz und Jitter auf die Dienstgüte-
Unterstützung übertragen werden.
Zusammenfassung und Ausblick 108
Adaptive-Linksymmetrie
Wie in Kapitel 7 bereits angedeutet, kann eine asymmetrische Belastung des Links aus
Sicht der Verkehrsoptimierung notwendig sein, wenn dies dem tatsächlichen Nutzungs-
verhalten entspricht (beispielsweise Internetanbindungen für Endkunden) oder zu einer
gezielten Entlastung des Netzes beiträgt. Dabei kann die Anpassung der Symmetrie an-
hand errechneter Verkehrskennzahlen statisch vorgegeben werden, beispielsweise wenn
eine Aufteilung entgegen dem tatsächlichen Verkehrsaufkommen erforderlich ist, oder
durch einen adaptiven Algorithmus gesteuert werden. Beiden Varianten ist allerdings
gemein, dass sie nur bei gesättigtem Link sinnvoll einsetzbar sind. Bei Normallast, das
heißt wenn die Ankunftrate der Sendewarteschlangen geringer ist als die Entnahmerate,
ist das Protokoll selbstregulierend, da der Token abgegeben wird, sobald die Sendewar-
teschlange leer ist.
Im Protokoll WiLDToken sind beide Varianten vorgesehen. Die Verschiebung der Sym-
metrie erfolgt dabei über die Anpassung der Sendelimits (T XOP) für eine oder beide
Stationen. Entsprechende Konfigurationsschnittstellen (Getter/Setter-Methoden) ermög-
lichen zur Laufzeit das Einstellen und Abfragen dieser Limits sowie den Wechsel von
statischer zu adaptiver Linksymmetrie und zurück. Weiterhin ist ein Statusaustausch
zwischen den Knoten über die Queue-Länge oder durchschnittliche Ankunftsrate not-
wendig, anhand dessen eine Errechnung des Verkehrsaufkommens und eine entspre-
chende Adaption der Sendeanteile durchgeführt wird. Für die Übermittlung der notwen-
digen Informationen wird das bislang ungenutzte Nutzdatenfeld des Tokens verwen-
det.
T XOPk(t) = (1−β )∗T XOPk(t−1)+β ∗ γk ∗T XOPmax (35a)
Mit
γk = min
qlkql′k
1(35b)
Gleichung 35 zeigt die Berechnung der Sendeanteile für beide beteiligten Knoten k ∈{A,B}. Zunächst wird der Belegungsanteil γk anhand der eigenen und der übermittel-
ten Queuelänge qlk,qlk′ ermittelt. Anschließend wird über den ermittelten Wert und 1
das Minimum gebildet, damit T XOPk(t) maximal T XOPmax = 4ms groß werden kann
([IEE04]). Um den Einfluss kurzzeitiger Lastspitzen abzufangen, wird außerdem ein Ge-
wichtungsfaktor β eingeführt, anhand dessen die neuen in die bisherigen Verkehrsinfor-
mationen eingerechnet werden. Als Ausgangswert kann beispielsweise β = 0.1 gesetzt
werden. So geht der neue Sendeanteil in den Durchschnitt über die letzten 10 Runden
ein.
Literatur 109
Literatur
[ABL05] M. Alicherry, R. Bhatia, and L. E. Li. Joint channel assignment and rou-ting for throughput optimization in multi-radio wireless mesh networks. InProceedings of the 11th annual international conference on Mobile com-puting and networking, pages 58–72. ACM, 2005.
[Abr70] N. Abramson. THE ALOHA SYSTEM: another alternative for computercommunications. In Proceedings of the November 17-19, 1970, fall jointcomputer conference, pages 281–285. ACM, 1970.
[Alm99] W. Almesberger. Linux network traffic control–implementation overview.In 5th Annual Linux Expo, pages 153–164, 1999. LCA-CONF-1999-012.
[BCNN84] J. Banks, J. S. Carson, B. L. Nelson, and D. M. Nicol. Discrete-eventsystem simulation. Pearson, 1984.
[Ber11] J. Berg. Radiotap - De facto standard for 802.11 frame injection and re-ception. http://www.radiotap.org/, March 2011. [Online, zuletztabgerufen am 07.04.2016].
[Bia00] G. Bianchi. Performance analysis of the IEEE 802.11 distributed coor-dination function. Selected Areas in Communications, IEEE Journal on,18(3):535–547, 2000.
[Bro06] M. A. Brown. Traffic Control HOWTO. http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/, October 2006. [Online, zu-letzt abgerufen am 29.03.2015].
[CFR09] G. Carneiro, P. Fortuna, and M. Ricardo. Flowmonitor: a network mo-nitoring framework for the network simulator 3 (ns-3). In Proceedingsof the Fourth International ICST Conference on Performance EvaluationMethodologies and Tools, page 1. ICST (Institute for Computer Sciences,Social-Informatics and Telecommunications Engineering), 2009.
[Cha99] X. Chang. Network simulations with OPNET. In Proceedings of the31st conference on Winter simulation: Simulation—a bridge to the future-Volume 1, pages 307–314. ACM, 1999.
[Cha15] M. Chauchet. Implementierung und Evaluierung von Token- und FDMA-basierten MAC-Layer-Protokollen für 802.11. Hochschule Bonn-Rhein-Sieg, 2015. Masterprojekt im Studiengang MCS.
[Cho04] S. Choi. Wireless MAC protocol based on a hybrid combination of slotallocation, token passing, and polling for isochronous traffic, September2004. US Patent 6,795,418.
[Cis] Cisco. Cisco Packet Tracer. http://www.cisco.com/web/learning/
netacad/course_catalog/PacketTracer.html. [Online, zuletzt ab-gerufen am 30.03.2015].
Literatur 110
[CM11] D. Camps-Mur. Linux Wi-Fi open source drivers - mac80211,ath9k/ath5k. http://www.campsmur.cat/files/mac80211_intro.
pdf, 2011. [Online, zuletzt abgerufen am 01.03.2015].
[DEM+] J. Dugan, S. Elliott, B. A. Mah, J. Poskanzer, and K. Prabhu. Iperf - TheTCP/UDP Bandwidth Measurement Tool. https://iperf.fr/. [Online,zuletzt abgerufen am 11.04.2016].
[ELSV03] M. Ergen, D. Lee, R. Sengupta, and P. Varaiya. Wireless token ringprotocol-performance comparison with IEEE 802.11. In Computers andCommunication, 2003.(ISCC 2003). Proceedings. Eighth IEEE Interna-tional Symposium on, pages 710–715. IEEE, 2003.
[ELSV04] M. Ergen, D. Lee, R. Sengupta, and P. Varaiya. WTRP-wireless token ringprotocol. Vehicular Technology, IEEE Transactions on, 53(6):1863–1881,2004.
[Eng05] D. Engwer. WDS clarifications. IEEE, Submission, pages 802–11, 2005.
[Erg02] M. Ergen. WTRP - Wireless Token Ring Protocol. Master’s thesis, Uni-versity of California, Berkeley, CA, 2002.
[ESB+13] L. Eznarriaga, C. Senguly, N. Bayer, J. I. Moreno, P. Lozano, andM. Simón. Experiences with SoftToken: a token-based coordination layerfor WLANs. International Journal of Communication Systems, 2013.
[Fou12] O. N. Foundation. Software-defined networking: The new norm for net-works. ONF White Paper, 2012.
[GLMC14] S. M. Gunther, M. Leclaire, J. Michaelis, and G. Carle. Analysis of in-jection capabilities and media access of IEEE 802.11 hardware in moni-tor mode. In Network Operations and Management Symposium (NOMS),2014 IEEE, pages 1–9. IEEE, 2014.
[Gro] B. W. Group. Wireless Token Ring Protocol. http://wow.eecs.
berkeley.edu/WTRP/. [Online, zuletzt abgerufen am 01.03.2015].
[Gro13] J. Gross. Programmable Networking with Open vSwitch.http://events.linuxfoundation.org/sites/events/files/
slides/OVS-LinuxCon%202013.pdf, June 2013. [Online, zuletztabgerufen am 09.04.2016].
[HLR+08] T. R. Henderson, M. Lacage, G. F. Riley, C. Dowell, and J. Kopena. Net-work simulations with the ns-3 simulator. SIGCOMM demonstration, 14,2008.
[Hub12] B. Hubert. Linux Advanced Routing & Traffic Control HOWTO. http:
//lartc.org/lartc.html#LARTC.QDISC, May 2012. [Online, zuletztabgerufen am 29.03.2015].
[IEE90] IEEE. Part 4: Token-Passing bus access method and Physical Layer spe-cifications (ANSI/IEEE Std 802.4-1990). Institute of Electrical and Elec-tronics Engineers, Inc., May 1990.
Literatur 111
[IEE98] IEEE. Part 5: Token ring access method and Physical Layer specificati-ons (ANSI/IEEE Std 802.5-1998E). Institute of Electrical and ElectronicsEngineers, Inc., May 1998.
[IEE04] IEEE. Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) Specifications Amendment 7: 4.9 GHz–5 GHz Operation in Japan.Institute of Electrical and Electronics Engineers, Inc., March 2004.
[IEE12a] IEEE. IEEE Standard for Ethernet - Section 1 (IEEE Std 802.3-2012).Institute of Electrical and Electronics Engineers, Inc., December 2012.
[IEE12b] IEEE. Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) Specifications (ANSI/IEEE Std 802.11, 2012 Edition). Institute ofElectrical and Electronics Engineers, Inc., March 2012.
[IEE13] IEEE. Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY) Specifications (ANSI/IEEE Std 802.11, 2013 Edition). Institute ofElectrical and Electronics Engineers, Inc., March 2013.
[Inc] G. T. Inc. Graphical Network Simulator 3. https://www.gns3.com/.[Online, zuletzt abgerufen am 30.03.2015].
[IR12] ITU-R. Radio Regulations Articles - Edition of 2012. InternationalTelecommunication Union Radiocommunication Sector (ITU-R), August2012.
[IT00] I. T. S. S. (ITU-T). ITU-T Recommendation G. 114: One-Way Transmis-sion Time. ITU-T May, 2000.
[Kah13] J. Kahlert. Simulation technischer Systeme: eine beispielorientierte Ein-führung. Springer-Verlag, 2013.
[Kar72] R. M. Karp. Reducibility among combinatorial problems. Springer, 1972.
[Kau07] F.-J. Kauffels. Grundlagen der Netzwerktechnik (6. Auflg.). mitp, Heidel-berg, 2007.
[KCC05] S. Kurkowski, T. Camp, and M. Colagrosso. MANET simulation studies:the incredibles. ACM SIGMOBILE Mobile Computing and Communicati-ons Review, 9(4):50–61, 2005.
[Ker95] H. Kerner. Rechnernetze nach OSI (3. Auflg.). Addison-Wesley, Bonn,1995.
[Ker15a] Kernel.org. Linux Wireless Developer Documentation. https:
//wireless.wiki.kernel.org/en/developers/documentation,2015. [Online, zuletzt abgerufen am 22.04.2016].
[Ker15b] Kernel.org. Linux Wireless Drivers. http://wireless.kernel.org/
en/users/Drivers, 2015. [Online, zuletzt abgerufen am 01.03.2016].
[Ker15c] Kernel.org. Linux Wireless Glossary. https://wireless.wiki.
kernel.org/en/developers/documentation/glossary, 2015. [On-line, zuletzt abgerufen am 01.03.2016].
Literatur 112
[KT+75] L. Kleinrock, F. Tobagi, et al. Packet switching in radio channels: Part I–Carrier sense multiple-access modes and their throughput-delay characte-ristics. Communications, IEEE Transactions on, 23(12):1400–1416, 1975.
[Lab13] A. Labs. Open vSwitch – Setting A Bandwidth Limit. https:
//n40lab.wordpress.com/2013/05/04/openvswitch-setting-a-
bandwidth-limit/, 2013. [Online, zuletzt abgerufen am 07.04.2016].
[LAP+01] D. Lee, R. Attias, A. Puri, R. Sengupta, S. Tripakis, and P. Varaiya. Awireless token ring protocol for intelligent transportation systems. In In-telligent Transportation Systems, 2001. Proceedings. 2001 IEEE, pages1152–1157. IEEE, 2001.
[Lee01] D. Lee. WTRP - Wireless Token Ring Protocol. Master’s thesis, Universityof California, Berkeley, CA, 2001.
[LH06] M. Lacage and T. R. Henderson. Yet another network simulator. In Procee-ding from the 2006 workshop on ns-2: the IP network simulator, page 12.ACM, 2006.
[LHM10] B. Lantz, B. Heller, and N. McKeown. A network in a laptop: rapid pro-totyping for software-defined networks. In Proceedings of the 9th ACMSIGCOMM Workshop on Hot Topics in Networks, page 19. ACM, 2010.
[MAB+08] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, and J. Turner. OpenFlow: enabling innovation incampus networks. ACM SIGCOMM Computer Communication Review,38(2):69–74, 2008.
[MtB03] R. Mahadevappa and S. ten Brink. Receiver Sensitivity Tables for MIMO-OFDM 802.11n. https://mentor.ieee.org/802.11/dcn/03/11-
03-0845-01-000n-11-03-0845-00-000n-receiver-sensitivity-
tables-mimo-ofdm.ppt, 2003. [Online, zuletzt abgerufen am11.04.2016].
[MVPF07] R. Moraes, F. Vasques, P. Portugal, and J. A. Fonseca. VTP-CSMA:A virtual token passing approach for real-time communication in IEEE802.11 wireless networks. Industrial Informatics, IEEE Transactions on,3(3):215–224, 2007.
[nP15a] ns 3 Project. ns-3.24 All Trace Sources. https://www.nsnam.org/
docs/release/3.24/doxygen/_trace_source_list.html, 2015.[Online, zuletzt abgerufen am 11.04.2016].
[nP15b] ns 3 Project. ns-3.24 Bug 2224 - scope of GetAmpduExist() in EdcaT-xopN. https://www.nsnam.org/bugzilla/show_bug.cgi?id=2224,2015. [Online, zuletzt abgerufen am 30.03.2016].
[nP15c] ns 3 Project. ns-3.24 Model Library. https://www.nsnam.org/docs/
release/3.24/models/html/, 2015. [Online, zuletzt abgerufen am30.03.2016].
Literatur 113
[nP15d] ns 3 Project. ns-3.24 WiFi Module Design Documentation.https://www.nsnam.org/docs/release/3.24/models/html/wifi-
design.html, 2015. [Online, zuletzt abgerufen am 30.03.2016].
[nP16a] ns 3 Project. ns-3 Publications. https://www.nsnam.org/overview/
publications/, 2016. [Online, zuletzt abgerufen am 30.03.2016].
[nP16b] ns 3 Project. ns-3 Tracing. https://www.nsnam.org/docs/manual/
html/tracing.html, 2016. [Online, zuletzt abgerufen am 13.04.2016].
[nP16c] ns 3 Project. ns-3.25 released. https://www.nsnam.org/news/ns-3-
25-released/, March 2016. [Online, zuletzt abgerufen am 30.03.2016].
[NPS+08] S. Nedevschi, R. K. Patra, S. Surana, S. Ratnasamy, L. Subramanian, andE. Brewer. An adaptive, high performance mac for long-distance multihopwireless networks. In Proceedings of the 14th ACM international confe-rence on Mobile computing and networking, pages 259–270. ACM, 2008.
[Ope] Open vSwitch. Open vSwitch Homepage. http://openvswitch.org/.[Online, zuletzt abgerufen am 01.03.2016].
[oSCISII] U. of Southern California Information Science Institute (ISI). The Net-work Simulator - ns-2. http://www.isi.edu/nsnam/ns/. [Online, zu-letzt abgerufen am 30.03.2015].
[PBM11] G. Piro, N. Baldo, and M. Miozzo. An LTE module for the ns-3 networksimulator. In Proceedings of the 4th International ICST Conference on Si-mulation Tools and Techniques, pages 415–422. ICST (Institute for Com-puter Sciences, Social-Informatics and Telecommunications Engineering),2011.
[PKH01] T. Pagtzis, P. Kirstein, and S. Hailes. Operational and fairness issues withconnection-less traffic over IEEE802. 11b. In Communications, 2001. ICC2001. IEEE International Conference on, volume 6, pages 1905–1913. IE-EE, 2001.
[PNS+07] R. K. Patra, S. Nedevschi, S. Surana, A. Sheth, L. Subramanian, and E. A.Brewer. WiLDNet: Design and Implementation of High Performance WiFiBased Long Distance Networks. In NSDI, volume 1, page 1, 2007.
[Pos81] J. Postel. Transmission control protocol (RFC 793). IETF, RFC, 1981.
[PPA+09] B. Pfaff, J. Pettit, K. Amidon, M. Casado, T. Koponen, and S. Shenker.Extending Networking into the Virtualization Layer. In Hotnets, 2009.
[Rad15] M. Rademacher. Performance estimation and optimization of the IE-EE802. 11 MAC layer for long distance point-to-point links. HochschuleBonn-Rhein-Sieg, 2015.
[RBRAB06] K. N. Ramachandran, E. M. Belding-Royer, K. C. Almeroth, and M. M.Buddhikot. Interference-Aware Channel Assignment in Multi-Radio Wi-reless Mesh Networks. In Infocom, volume 6, pages 1–12, 2006.
Literatur 114
[RC05] B. Raman and K. Chebrolu. Design and evaluation of a new MAC protocolfor long-distance 802.11 mesh networks. In Proceedings of the 11th annu-al international conference on Mobile computing and networking, pages156–169. ACM, 2005.
[Rec12] J. Rech. Wireless LANs - 802.11-WLAN-Technologie und praktische Um-setzung im Detail (4. Auflg.). Heise Zeitschriften-Verlag, Hannover, 2012.
[RH10] G. F. Riley and T. R. Henderson. The ns-3 network simulator. In Modelingand Tools for Network Simulation, pages 15–34. Springer, 2010.
[Riv] Riverbed. OpNet. http://de.riverbed.com/products/
performance-management-control/opnet.html. [Online, zuletztabgerufen am 30.03.2016].
[RKJ14] M. Rademacher, M. Kretschmer, and K. Jonas. Exploiting IEEE802.11n MIMO Technology for Cost-Effective Broadband Back-Hauling. Ine-Infrastructure and e-Services for Developing Countries, pages 1–11.Springer, 2014.
[RS05] A. Rao and I. Stoica. An overlay MAC layer for 802.11 networks. InProceedings of the 3rd international conference on Mobile systems, appli-cations, and services, pages 135–148. ACM, 2005.
[Sch10] H. Schwichtenberg. Windows Scripting: automatisierte Systemadministra-tion mit dem Windows Script Host und der Windows PowerShell. PearsonDeutschland GmbH, 2010.
[SVR+08] G. Smith, G. Venkatesan, E. Rouss, O. Aboul-Magd, A. Ashley, N. Kakani,and B. Hart. 802.11 QoS Tutorial. IEEE doc.: IEEE, 802(08):1214–02,2008.
[Tet] Tetcos. NetSim v9. http://tetcos.com/netsim_gen.html. [Online,zuletzt abgerufen am 30.03.2016].
[TW12] A. S. Tanenbau and D. J. Wetherall. Computernetzwerke (5. Auflg.). Pear-son, München, 2012.
[vN14] A. von Nagy. Wi-Fi SNR to MCS Data Rate Mapping Refe-rence. http://www.revolutionwifi.net/revolutionwifi/2014/
09/wi-fi-snr-to-mcs-data-rate-mapping.html, September 2014.[Online, zuletzt abgerufen am 11.04.2016].
[Voi15] R. Voicu. Traffic shaping with OVS and SDN. https://indico.
cern.ch/event/376098/contribution/24/attachments/749534/
1028288/OVS-rv_20150602_v1.pdf, June 2015. [Online, zuletztabgerufen am 09.04.2016].
[VS10] M. Vipin and S. Srikanth. Analysis of open source drivers for IEEE 802.11WLANs. In Wireless Communication and Sensor Computing, 2010. ICW-CSC 2010. International Conference on, pages 1–5. IEEE, 2010.
Literatur 115
[WB01] Y. Wang and B. Bensaou. Achieving fairness in IEEE 802.11 DFWMACwith variable packet lengths. In Global Telecommunications Conference,2001. GLOBECOM’01. IEEE, volume 6, pages 3588–3593. IEEE, 2001.
[WGG10] K. Wehrle, M. Günes, and J. Gross. Modeling and tools for network simu-lation. Springer Science & Business Media, 2010.
[Wol14] J. Wolf. C++: Das umfassende Handbuch. 3., aktualisierte Auflage. Gali-leo Press, 2014.
[ZBG98] X. Zeng, R. Bagrodia, and M. Gerla. GloMoSim: a library for parallel si-mulation of large-scale wireless networks. In Parallel and Distributed Si-mulation, 1998. PADS 98. Proceedings. Twelfth Workshop on, pages 154–161. IEEE, 1998.
Anhang 116
A. Anhang
A.1. Tabellen
QoS-Parameter für WiLDToken Berechnung der QoS-Parameter für WiLDTokenanhand der Default-Parameter für EDCA, siehe Tabelle A.1.
Tabelle A.1: EDCA-Standard-Parameter-Satz (nach [IEE12b, Tabelle 8-105])
AC CWmin† CWmax‡ AIFSNTXOP limit
(HR)DSSSPHYs
OFDM/ERP/HT PHYs
OtherPHYs
AC_BK 15 1023 7 0 0 0AC_BE 15 1023 3 0 0 0AC_VI 7 15 2 6,016ms 3,008ms 0AC_VO 3 7 2 3,264ms 1,504ms 0
Anmerkungen: † : CWmin = 15,‡ : CWmax = 1023 (für HT PHYs, siehe [IEE12b, S. 1761f., Tabelle 20-25])
Für AC_VO (Bezugsgröße für TXOP: 10 ms ([IEE12b, S. 1762, Tabelle 20-25])):
T XOPWT−VO =T XOPEDCA−VO
T XOPmax=
1.504[ms]10[ms]
≈ 0.15 (36a)
Für AC_VI:
T XOPWT−V I =T XOPEDCA−V I
T XOPmax=
3.008[ms]10[ms]
≈ 0.30 (36b)
Für AC_BE und AC_BK sind keine Vorgaben für TXOP angegeben. Weiterhin sindCWmin und CWmax bei beiden ebenfalls identisch. In diesem Fall dient AIFSN (größerbedeutet weniger Anteil) als Anhaltspunkt. Der verbleibende Teil (0.55 oder 55%) wirdfolgendermaßen aufgeteilt:
T XOPWT−BE = 0.55∗ (1− AIFSNEDCA−BE
AIFSNEDCA−BE +AIFSNEDCA−BK)≈ 0.385 (36c)
Und für
T XOPWT−BE = 0.55∗ (1− AIFSNEDCA−BK
AIFSNEDCA−BE +AIFSNEDCA−BK)≈ 0.165 (36d)
Tabelle A.2: WildToken: Festlegung der QoS-Parameter (nach eigener Darstellung)
Access Category (AC) Prio TXOP limit (EDCA) TXOPQ (WildToken)
AC_BK 3 0 0.165AC_BE 2 0 0.385AC_VI 1 3.008 0.30AC_VO 0 1.504 ms 0.15
Anhang 117
A.2. Klassendiagramme
<<abstract>>WifiMac
+ Enqueue (packet: Ptr<const Packet>, to: Mac48Address)+ GetAddress (): const Mac48Address+ SetAddress (Mac48Address address)+ GetBssid (): const Mac48Address+ SetSsid (ssid: Ssid)
<<abstract>>RegularWifiMac
<<abstract>>WtWifiMac
# *m_rxMiddle: MacRxMiddle# *m_txMiddle: MacTxMiddle# m_low: Ptr<WtMacLow># *m_wtManager: WtManager# m_phy: Ptr<WifiPhy># m_forwardUp: ForwardUpCallback# m_ssid: Ssid# Ptr<WtTxop> m_wtTxopNqos;# typedef std::map<AcIndex,Ptr<WtTxop> > WtTxops
+ Enqueue (packet: Ptr<const Packet>, to:Mac48Address)# Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)+ GetAddress (): Mac48Address+ SetAddress (Mac48Address address)+ GetBssid (): Mac48Address+ SetSsid (ssid: Ssid)
AdhocWtMac
+ Enqueue (packet: Ptr<const Packet>, to:Mac48Address)- Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)
ApWtMac- m_beaconTxop: Ptr<WtTxop>- m_beaconInterval: Time- m_enableBeaconGeneration: bool- m_beaconEvent: EventId
+ Enqueue (packet: Ptr<const Packet>, to:Mac48Address)- Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)+ SetBeaconInterval (interval: Time)+ GetBeaconInterval (): const Time+ StartBeaconing ()- SendProbeResp (to: Mac48Address)- SendAssocResp (to: Mac48Address, suc-cess: bool)- SendOneBeacon ()
StaWtMac- m_state: enum MacState- m_probeRequestTimeout: Time- m_assocRequestTimeout: Time- m_activeProbing: bool
+ Enqueue (packet: Ptr<const Packet>, to:Mac48Address)- Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)+ SetMaxMissedBeacons (missed:uint32_t)+ SetProbeRequestTimeout (timeout: Ti-me)+ SetAssocRequestTimeout (timeout: Ti-me)
Abbildung A.1: WiLDToken: Erweiterung der Vererbungshierarchie von ns3::WifiMac (nacheigener Darstellung)
Anhang 118
WtManager- m_wtTxops: typedef std::vector<WtTxop *>- m_state: enum WtFsmState- m_receiveTimeout: EventId- m_syncTimeout: EventId- m_receiveTimeoutTime: Time- m_sendLimitByte: uint32_t- m_sendLimitTime: Time- m_mac: WtWifiMac*- m_low: Ptr<WtMacLow>- m_peer: Mac48Address
+ NotifyReceiveTimeout()+ NotifyWtFrameReceived()+ NotifySyncTimeout()+ ScheduleReceiveTimeout()+ ScheduleSyncTimeout()+ SetSendLimitByte (sendLimitByte: uint32_t)+ GetSendLimitByte (): uint32_t+ SetSendLimitTime (sendLimitTime: Time)+ GetSendLimitTime (): Time+ SetReceiveTimeout (recvTimeout: Time)- DoGrantAccess ()- HandleToken (packet: Ptr<Packet>)
(a) ns3::WtManager
WtMacLow- *m_bAckManager: WtBlockAckManager- m_reTxMpdus: uint32_t- m_reTxBytes: uint8_t- m_reTxTime: Time- m_aggregateQueue: Ptr<WifiMacQueue>
+ StartTransmission (packet: Ptr<const Packet>,hdr: const WifiMacHeader*, parameters: MacLow-TransmissionParameters, *listener: MacLowTrans-missionListener)+ HandleRetransmissions ()+ ReceiveOk (packet: Ptr<Packet>, rxSnr: double,txVector: WifiTxVector, preamble: WifiPreamble,ampduSubframe: bool)+ ReceiveError (packet: Ptr<const Packet>, rxSnr:double)+ GetRetxBytes (): uint32_t+ GetRetxTime (): Time+ GetRetxPackets (): uint8_t+ ForwardDown (packet: Ptr<const Packet>, *hdr:const WifiMacHeader, txVector: WifiTxVector, pre-amble: WifiPreamble)+ SendPacket (packet: Ptr<const Packet>, txVector:WifiTxVector, preamble: WifiPreamble, packetType:uint8_t, mpduReferenceNumber: uint32_t)
(b) ns3::WtMacLowWtTxop
- *m_manager: WtManager- m_queue: Ptr<WifiMacQueue>- *m_rng: RandomStream- m_sendLimitByte: uint32_t- m_sendLimitTime: Time- m_sendLimitPackets: uint8_t- m_bytesSent: uint32_t- m_packetsSent: uint8_t- m_timeSent: Time
+ GenSyncReq()+ GenSyncReply(peer: Mac48Address)+ GenDataToken(peer: Mac48Address)+ NotifyAccessGranted ()+ SetAccessCategory (ac: enum AcIndex)+ Queue (packet: Ptr<const Packet>, &hdr: constWifiMacHeader)
(c) ns3::WtTxop
WtBlockAckManager- Item: struct- m_storedPackets: typedef std::list<Item> Packet-Queue
+ StorePacket (packet: Ptr<const Packet>, &hdr:const WifiMacHeader, tStamp: Time)+ NotifyGotBlockAck (*blockAck: const Ctrl-BAckResponseHeader, recipient: Mac48Address,txMode: WifiMode)+ HasPackets (): const bool+ GetNBufferedPackets (): const uint32_t+ GetNextPacket (WifiMacHeader &hdr): Ptr<constPacket>- CleanupBuffers ()
(d) ns3::WtBlockAckManager
Abbildung A.2: WiLDToken: UML-Klassendiagramme weiterer WiLDToken-Klassen (nach ei-gener Darstellung)
Anhang
119
WtWifiMac
+ Enqueue (packet: Ptr<const Packet>, to:Mac48Address)# Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)
AdhocWtMac
ApWtMac
StaWtMac
WtManager- m_state: enum WtFsmState
+ NotifyWtFrameReceived()- DoGrantAccess ()
WtTxop- m_queue: Ptr<WifiMacQueue>
+ NotifyAccessGranted ()+ Queue (packet: Ptr<const Packet>, &hdr:const WifiMacHeader)
MacRxMiddle
+ Receive (packet: Ptr<Packet>, *hdr:const WifiMacHeader)- IsDuplicate (hdr: const WifiMacHeader*,*originator: OriginatorRxStatus): constbool- HandleFragments (packet: Ptr<Packet>,hdr: const WifiMacHeader*, *originator:OriginatorRxStatus): Ptr<Packet>
MacTxMiddle
+ GetNextSequenceNumberfor (*hdr: constWifiMacHeader): uint16_t
WtMacLow- m_aggregateQueue: Ptr<WifiMacQueue>
+ ReceiveOk (packet: Ptr<Packet>, rxSnr:double, txVector: WifiTxVector, preamble:WifiPreamble, ampduSubframe: bool)+ ReceiveError (packet: Ptr<const Packet>,rxSnr: double)
WtBlockAckManager
+ StorePacket (packet: Ptr<const Packet>,&hdr: const WifiMacHeader, tStamp: Ti-me)+ GetNextPacket (WifiMacHeader &hdr):Ptr<const Packet>
1
1..n
1
1
1
1
11..n
11..n
1
1
1
Abbildung A.3: WiLDToken: UML-Klassendiagramm der Architektur, Darstellung der Klassen mit ausgewählten Methoden und Eigenschaften (nach eigenerDarstellung)
Anhang 120
A.3. Listings und Quellcode-Auszüge
A.3.1. Mathematisches Modell
Listing A.1: Berechnung des mathematischen Modells (siehe Abschnitt 5.1) (WildToken-Sim.vbs)
1 ’ ***********************************************************************************************2 ’ *3 ’ * C o p y r i g h t ( c ) 2016 MARTIN CHAUCHET4 ’ *5 ’ * T h i s program i s f r e e s o f t w a r e ; you can r e d i s t r i b u t e i t and / or m od i f y6 ’ * i t under t h e t e r m s o f t h e GNU Genera l P u b l i c L i c e n s e v e r s i o n 2 as7 ’ * p u b l i s h e d by t h e Free S o f t w a r e Founda t ion ;8 ’ *9 ’ * T h i s program i s d i s t r i b u t e d i n t h e hope t h a t i t w i l l be u s e f u l ,
10 ’ * b u t WITHOUT ANY WARRANTY; w i t h o u t even t h e i m p l i e d w ar r a n t y o f11 ’ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See t h e12 ’ * GNU Genera l P u b l i c L i c e n s e f o r more d e t a i l s .13 ’ *14 ’ * You s h o u l d have r e c e i v e d a copy o f t h e GNU Genera l P u b l i c L i c e n s e15 ’ * a long w i t h t h i s program ; i f not , w r i t e t o t h e Free S o f t w a r e16 ’ * Foundat ion , I n c . , 59 Temple Place , S u i t e 330 , Boston , MA 02111−1307 USA17 ’ *18 ’ * Au thor : Mar t in Chauchet <m a r t i n . chauche t@in f . h−b r s . de19 ’ *20 ’ *21 ’ *22 ’ * S i m u l a t i o n e n v i r o n m e n t f o r t h e WiLDToken m a t h e m a t i c a l m od e l l d e s c r i b e d i n23 ’ * t h e au thor ’ s Master ’ s t h e s i s p u b l i s h e d i n 2016 . For f u r t h e r i n f o r m a t i o n ,24 ’ * p l e a s e s e e men t ioned t h e s i s or use t h e au thor ’ s e m a i l a d d r e s s f o r c o n t a c t i n g .25 ’ *26 ’ ***********************************************************************************************27 ’ # Enable e x p l i c i t d e c l a r a t i o n o f v a r i a b l e s and c o n s t a n t s28 Option E x p l i c i t2930 ’ # V a r i a b l e d e c l a r a t i o n : d i s t a n c e , F i l e S y s t e m o b j e c t , pa th t o l o g f i l e , l o g f i l e o b j e c t31 Dim objFSO , s t r O u t F i l e , o b j O u t F i l e , MCSbps ( 8 , 2 ) , NDBPS32 Dim d , MCS, GI , BER, i , Payload , t3334 ’ # C o n s t a n t s f o r f i l e s y s t e m a c c e s s : f i l e o p e r a t i o n modes35 Const ForRead = 136 Const F o r W r i t e = 237 Const ForAppend = 83839 ’ # S i m u l a t i o n v a r i a b l e s40 d =12000 ’ D i s t a n c e i n me ter41 MCS = 7 ’ Modu la t ion and cod in g scheme42 GI = 0 ’ Guard I n t e r v a l , 0 = long , 1 = s h o r t43 BER = 0.000001 ’ B i t Error r a t e44 i = 3 ’A−MPDU a g g r e g a t i o n f a c t o r 2^(13+ i )45 t = 0 .004 ’Max Ampdu t r a n s m i s s i o n t i m e46 Pay load = 1450 ’ Payload s i z e i n b y t e47 s t r O u t F i l e = " math−t h r o u g h p u t−d i s t a n c e− t e s t . c sv " ’ Path t o L o g f i l e4849 ’ # Enable or d i s a b l e v e r b o s e o u t p u t50 ’~ Cons t VERBOSE = True51 Const VERBOSE = F a l s e5253 ’ # Enable or d i s a b l e Outpu t t o f i l e54 ’~ Cons t T o F i l e = f a l s e55 Const T o F i l e = t r u e5657 ’ # From here : C o n s t a n t s f o r below c a l c u l a t i o n s , i . e . t i m i n g s ,58 ’ # f rame and header s i z e s , s i m u l a t i o n p a r a m e t e r s e t c59 ’ # header s i z e s i n b y t e60 Const LMACHDR = 26 ’ IEEE802 . 1 1 MAC Header l e n g t h i n b y t e61 Const LLLCHDR = 8 ’ IEEE802 . 1 1 LLC header l e n g t h i n b y t e62 Const LIPHDR = 20 ’ I n t e r n e t P r o t o c o l v4 header l e n g t h i n b y t e63 Const LAMPDUHDR = 4 ’A−MPDU d e l i m i t e r l e n g t h i n b y t e64 Const LTOKEN = 26 ’ WiLDToken frame l e n g t h i n b y t e65 Const LBACK = 150 ’ B a s i c B lock Ack l e n g t h i n b y t e6667 ’ # Timing Parame te r s68 Const TPREAM = 0.000016 ’ Preamble l e n g t h : 16mus69 Const TPLCP = 0.000004 ’PLCP l n g t h : 4mus70 Const TSYM = 0.000004 ’ Symbol l e n g t h : 4mus ( long GI )71 Const TSIFS = 0 .000016 ’ S h o r t i n t e r f r a m e space : 16mus w i t h 802 .11 n 5GHz7273 ’ # S e t u p s i m u l a t i o n env i ronmen t , i n i t i a l i z e o b j e c t s e t c74 Se tup7576 ’ # W r i t e n i c e o u t p u t header77 WScr ip t . S tdOut . W r i t e L i n e " ********************************** "78 WScr ip t . S tdOut . W r i t e L i n e " ** Net Throughput C a l c u l a t i o n ** "79 WScr ip t . S tdOut . W r i t e L i n e " ********************************** "80 WScr ip t . S tdOut . W r i t e L i n e
Anhang 121
81 WScr ip t . S tdOut . W r i t e L i n e " Params : "82 WScr ip t . S tdOut . W r i t e L i n e " PAYLOAD: " & PAYLOAD83 WScr ip t . S tdOut . W r i t e L i n e " MCS: " & MCS84 WScr ip t . S tdOut . W r i t e L i n e " SHORTGI : " & GI85 WScr ip t . S tdOut . W r i t e L i n e " DISTANCE : " & d86 WScr ip t . S tdOut . W r i t e L i n e " BER: " & BER87 WScr ip t . S tdOut . W r i t e L i n e88 WScr ip t . S tdOut . W r i t e L i n e " S i m u l a t i o n Co ns t s : "89 WScr ip t . S tdOut . W r i t e L i n e " LMACHDR: " & LMACHDR90 WScr ip t . S tdOut . W r i t e L i n e " LLLCHDR: " & LLLCHDR91 WScr ip t . S tdOut . W r i t e L i n e " LIPHDR : " & LIPHDR92 WScr ip t . S tdOut . W r i t e L i n e " LAMPDUHDR: " & LAMPDUHDR93 WScr ip t . S tdOut . W r i t e L i n e " LTOKEN: " & LTOKEN94 WScr ip t . S tdOut . W r i t e L i n e " LBACK: " & LBACK95 WScr ip t . S tdOut . W r i t e L i n e96 WScr ip t . S tdOut . W r i t e L i n e " R e s u l t s : "97 WScr ip t . S tdOut . W r i t e L i n e98 W s c r i p t . S tdOut . W r i t e L i n e " d i s t a n c e , pay load , r x D a t a r a t e , d e l a y "99
100 ’ # I f we want v e r b o s e debugg ing o u t p u t , t h e n do s i n g l e run over 12km101 i f (VERBOSE) Then102 Ca lcThroughpu t d , Pay load103 Else104 ’ # E l s e i n s e r t d e s i r e d s i m u l a t i o n here105 ’ # run t h r o u g h p u t over d i s t a n c e from 100m t o 50km106 f o r d=100 TO 50000 STEP 100107 Ca lcThroughpu t d , Pay load108 Next109110 ’ # w i t h d i f f e r e n t p a y l o a d s from 50 t o 1450 b y t e i n s t e p s o f 100 b y t e s111 ’~ f o r pay load =50 TO 1450 STEP 100112 ’~ CalcThroughpu t d , Payload113 ’~ Nex t114 End i f115116 ’ # Tear down s i m u l a t i o n e n v i r o n m e n t117 Teardown118119 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++120 ’+ Func t ion−header121 ’+ \ b r i e f T h i s i s our main s i m u l a t i o n f u n c t i o n . Throughput c a l c u l a t i o n t a k e s122 ’+ p l a c e w i t h i n t h i s f u n c t i o n , a l s o d e l a y e s t i m a t i o n .123 ’+ Throughout i s c a l c u l a t e d s t e p by s t e p as d e s c i b e d i n s e c t i o n124 ’+ 4 . 4 o f t h e a c c o r d i n g Master ’ s t h e s i s .125 ’+ \ param d The d i s t a n c e be tween t h e two nodes126 ’+ \ param Payload The Payload s i z e127 ’+ \ r e t u r n D a t a r a t e128 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++129 Funct ion CalcThroughpu t ( d , Pay load )130 ’ # V a r i a b l e d e c l a r a t i o n s131 ’ # NB f o r each maxAMpdusize , 4ms and w i t h BER132 Dim NBcalc , NB4ms , NB, NBreal133 ’ # c a l c u l a t i o n h e l p e r v a r i a b l e s134 Dim Lto t , TAMPDU, TTX, PER , wNutz , NetDR135136 ’ # C a l c u l a t e t h e number o f MPDUs t o f i t i n t h e g i v e n maxAmpduSize i n d i c a t e d by e x p o n e n t i137 NBcalc = F l o o r ( ( ( 2 ^ ( 1 3 + i ) )−(LTOKEN+LBACK) ) / (PAYLOAD+(LMACHDR+LLLCHDR+LIPHDR ) ) )138 ’ # C a l c u l a t e t h e number o f MPDUs t o f i t i n t h e g i v e n maximum t r a n s m i s s i o n t i m e t139 NB4ms = F l o o r ( ( ( t * MCSbps (MCS, GI ) / 8 )−(LTOKEN+LBACK) ) / (PAYLOAD+(LMACHDR+LLLCHDR+LIPHDR ) ) )140 ’ # C a l c u l a t e t h e minimum o f t h o s e two and t h e l i m i t o f 64−2=62 MPDUs per WiLDToken AMPDU141 NB = min ( min (NB4ms , NBcalc ) , 6 2 )142143 ’ # I f we demand v e r b o s e o u t p u t t h e n p r i n t t h e c o r r e s p o n d i n g v a l u e s144 I f (VERBOSE) Then145 w s c r i p t . S tdOut . W r i t e L i n e " NBcalc = " & NBcalc146 w s c r i p t . S tdOut . W r i t e L i n e " NB4ms = " & NB4ms147 w s c r i p t . S tdOut . W r i t e L i n e " NB = " & NB148 End i f149150 ’ # C a l c u l a t e t h e o v e r a l l AMPDU l e n g t h151 L t o t = (LAMPDUHDR+LBACK) + NB * (LAMPDUHDR + LMACHDR + Pay load ) + (LAMPDUHDR+LTOKEN)152153 ’ # c a l c u l a t e t h e AMPDU t r a n s m i s s i o n t i m e by summing up t h e preamble and p l c p t r a n s m i s s i o n
t i m e w i t h number o f symbo l s m u l t i p l i e d w i t h symbol d u r a t i o n154 TAMPDU = TPREAM + TPLCP + NSYM( Lto t ,MCS) * TSYM155156 ’ # C a l c u l a t e o v e r a l l t r a n s m i s s i o n t i m e w i t h SIFS and P r o p a g a t i o n d e l a y157 TTX = TSIFS + TAMPDU + TPROP( d )158159 ’ # I f we demand v e r b o s e o u t p u t t h e n p r i n t t h e c o r r e s p o n d i n g v a l u e s160 I f (VERBOSE) Then161 w s c r i p t . S tdOut . W r i t e L i n e " L t o t = " & L t o t162 w s c r i p t . S tdOut . W r i t e L i n e " TAMPDU = " & TAMPDU163 w s c r i p t . S tdOut . W r i t e L i n e " TTX = " & TTX*1000*1000 & " mus "164 End i f165166 ’ # c a l c u l a t e Pa ck e t e r r o r r a t e from B i t e r r o r r a t e f o r g i v e n Payload l e n g t h167 PER = 1−((1−BER) ^ (PAYLOAD+(LMACHDR+LLLCHDR+LIPHDR ) ) )168 ’ # c a l c u l a t e n e t u s a b l e number o f MPDUs w i t h i n AMPDU by s u b s t r a c t i n g p r e v i o u s l y f a u l t y ,
r e t r a n s m i t t e d p a c k e t s169 NBreal= F l o o r (NB * (1−PER) )
Anhang 122
170171 ’ # I f we demand v e r b o s e o u t p u t t h e n p r i n t t h e c o r r e s p o n d i n g v a l u e s172 I f (VERBOSE) Then173 w s c r i p t . S tdOut . W r i t e L i n e " BER = " & BER174 w s c r i p t . S tdOut . W r i t e L i n e " PER = " & PER175 w s c r i p t . S tdOut . W r i t e L i n e " NBreal = " & NBreal176 End i f177178 ’ # c a l c u l a t e e f f i c i e n c y o f p r o t o c o l , i . e . medium s a t u r a t i o n by d i v i d i n g t i m e used f o r n e t
t r a f f i c by o v e r a l l t r a n s m i s s i o n t i m e179 wNutz = (NSYM( NBreal * Payload ,MCS) * TSYM) / ( TTX)180 ’ # c a l c u l a t e n e t t o d a t a r a t e181 NetDR = MCSbps (MCS, GI ) * (2* NSYM( NBreal * Payload ,MCS) * TSYM) / ( 2 *TTX) / 1 0 0 0 / 1 0 0 0182183 ’ # I f we demand v e r b o s e o u t p u t t h e n p r i n t t h e c o r r e s p o n d i n g v a l u e s184 I f (VERBOSE) Then185 w s c r i p t . S tdOut . W r i t e L i n e " wNutz = " & wNutz186 w s c r i p t . S tdOut . W r i t e L i n e " NetDR = " & NetDr187 End i f188189 ’ # P r i n t c a l c u l a t e d v a l u e s i n c s v s t y l e ( we have t o d e a l w i t h german c o l o n )190 w s c r i p t . S tdOut . W r i t e L i n e Rep lace ( Cstr ( d / 1 0 0 0 ) , " , " , " . " ) & " , " & Pay load & " , " & Rep lace ( CStr (
NetDr ) , " , " , " . " ) & " , " & Rep lace ( CStr (TTX*1000) , " , " , " . " )191 I f ( T o F i l e ) Then192 ’ # i f we want t o o u t p u t t o f i l e ( s t i l l have t o d e a l w i t h german c o l o n )193 o b j O u t F i l e . W r i t e L i n e Rep lace ( Cstr ( d / 1 0 0 0 ) , " , " , " . " ) & " , " & Pay load & " , " & Rep lace (
CStr ( NetDr ) , " , " , " . " ) & " , " & Rep lace ( CStr (TTX*1000) , " , " , " . " )194 End i f195 ’ # R e t u r n c a l c u l a t e d t h r o u g h o u t f o r f u r t h e r use196 Ca lcThroughpu t = NetDR197 End Funct ion198199200 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++201 ’+ Func t ion−Header202 ’+ \ b r i e f C a l c u l a t e Number o f OFDM symbo l s needed t o t r a n s m i t203 ’+ g i v e n amount o f da ta204 ’+ \ param L Payload l e n g t h205 ’+ \ param MCS The MCS we use206 ’+ \ r e t u r n Number o f Symbols207 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++208 Funct ion NSYM ( L ,MCS)209 NSYM=(L*8+22) /NDBPS(MCS)210 End Funct ion211212 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++213 ’+ Func t ion−Header214 ’+ \ b r i e f C a l c u l a t e P r o p a g a t i o n Delay215 ’+ \ param d d i s t a n c e216 ’+ \ r e t u r n P r o g a g a t i o n d e l a y217 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++218 Funct ion TPROP( d )219 TPROP = d / ( 3 * 1 0 ^ 8 )220 End Funct ion221222 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++223 ’+ Func t ion−Header224 ’+ \ b r i e f C e i l i n g f u n c t i o n s i n c e V B s c r i p t does n o t have such b a s i c s t u f f225 ’+ \ param Number number t o c e i l226 ’+ \ r e t u r n C e i l e d Number227 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++228 Funct ion C e i l ( Number )229 C e i l = I n t ( Number )230 i f C e i l <> Number then231 C e i l = C e i l + 1232 end i f233 End Funct ion234235 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++236 ’+ Func t ion−Header237 ’+ \ b r i e f F l o o r i n g f u n c t i o n s i n c e V B s c r i p t does n o t have such b a s i c s t u f f238 ’+ \ param Number number t o c e i l239 ’+ \ r e t u r n F loored Number240 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++241 Funct ion F l o o r ( Number )242 F l o o r = I n t ( Number )243 End Funct ion244245 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++246 ’+ Func t ion−Header247 ’+ \ b r i e f Maximum f u n c t i o n s i n d V B s c r i p t does no have such b a s i c s t u f f248 ’+ \ param a comparable a249 ’+ \ param b comparable b250 ’+ \ r e t u r n Maximum o f a and b251 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++252 Funct ion Max( a , b )253 Max = a254 I f b > a then Max = b255 End Funct ion256257 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anhang 123
258 ’+ Func t ion−Header259 ’+ \ b r i e f Minimum f u n c t i o n s i n d V B s c r i p t does no have such b a s i c s t u f f260 ’+ \ param a comparable a261 ’+ \ param b comparable b262 ’+ \ r e t u r n Minimum o f a and b263 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++264 Funct ion Min ( a , b )265 Min = a266 I f b < a then Min = b267 End Funct ion268269 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++270 ’+ Func t ion−Header271 ’+ \ b r i e f S e t u p s i m u l a t i o n env i ronmen t , i . e . i n i t i a l i z i n g g l o b a l v a r i a b l e s ,272 ’+ o b j e c t s and h e l p e r a r r a y s273 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++274 Funct ion Se tup275 Set objFSO = CreateObject ( " S c r i p t i n g . F i l e S y s t e m O b j e c t " )276 ’ # He lper Array f o r MCS t o d a t a r a t e c o n v e r s i o n277 MCSbps ( 0 , 0 ) = 6500000278 MCSbps ( 0 , 1 ) = 7200000279 MCSbps ( 1 , 0 ) = 13000000280 MCSbps ( 1 , 1 ) = 15000000281 MCSbps ( 2 , 0 ) = 19500000282 MCSbps ( 2 , 1 ) = 21700000283 MCSbps ( 3 , 0 ) = 26000000284 MCSbps ( 3 , 1 ) = 28900000285 MCSbps ( 4 , 0 ) = 39000000286 MCSbps ( 4 , 1 ) = 43300000287 MCSbps ( 5 , 0 ) = 52000000288 MCSbps ( 5 , 1 ) = 57800000289 MCSbps ( 6 , 0 ) = 58500000290 MCSbps ( 6 , 1 ) = 65000000291 MCSbps ( 7 , 0 ) = 65000000292 MCSbps ( 7 , 1 ) = 72200000293294 NDBPS = Array ( 2 6 , 5 2 , 7 8 , 1 0 4 , 1 5 6 , 2 0 8 , 2 3 4 , 2 6 0 ) ’ He lper a r r a y o f B i t s per OFDM Symbol f o r MCS 0
t o 7295296 I f ( T o F i l e ) Then297 Set o b j O u t F i l e = objFSO . O p e n T e x t F i l e ( s t r O u t F i l e , ForWri te , t r u e )298 o b j O u t F i l e . W r i t e L i n e " d i s t a n c e , pay load , r x D a t a r a t e , d e l a y "299 End i f300 End Funct ion301302 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++303 ’+ Func t ion−Header304 ’+ \ b r i e f Tear down s i m u l a t i o n env i ronmen t , i . e . d e i n i t i a l i z i n g o b j e c t s305 ’++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++306 Funct ion Teardown307 o b j O u t F i l e . Close308 Set o b j F i l e = Noth ing309 Set objFSO = Noth ing310 End Funct ion
A.3.2. Implementierung
Listing A.2: Auszug aus der ns-3-Simulation für Langstrecken-Punkt-zu-Punkt-Verbindungen(point-to-point_11n.cc): Timing-Berechnung
77 . . .78 / * **********************************************************************************************79 * Timing C a l c u l a t i o n s , s e e h t t p : / / www. a i r−s t r e am . org / t e c h n i c a l / ack−t i m e o u t s−and−e f f e c t s −
d i s t a n c e− l i n k s f o r f u r t h e r i n f o r m a t i o n80 * ACK Timeout = A i r P r o p a g a t i o n Time ( max ) + SIFS + Time t o t r a n s m i t 14 b y t e ACK frame [14 * 8
/ b i t r a t e i n Mbps ] + A i r P r o p a g a t i o n Time ( max )81 * S l o t t i m e = MAC and PHY d e l a y s + 3* Coverage C l a s s82 * DIFS = SIFS + 2 * S l o t t i m e83 * B a s i c B l o c k A c k T i m e o u t ( c a l c u l a t i o n pending , a p p r o x i m a t e d by 2* AckTimeout )84 * CompressedBlockAckTimeout ( c a l c u l a t i o n pending , a p p r o x i m a t e d by 2* AckTimeout )85 ********************************************************************************************** * /86 i n t c a l c P r o p D e l a y ( double d i s t a n c e ) {87 double c = 3 0 0 0 0 0 0 0 0 . 0 ; / / Speed o f l i g h t [m/ s ]88 double propDelay = ( d i s t a n c e / c ) ; / / D i v i d e d i s t a n c e by speed t o g e t t i m e89 propDelay *= ( 1 0 0 0 . 0 * 1 0 0 0 . 0 ) ; / / Re tu r n m i c r o s e c o n d s90 re turn ( i n t ) ( s t d : : c e i l ( p ropDelay ) ) ;91 }9293 i n t c a l c C o v e r a g e C l a s s ( double d i s t a n c e ) {94 double propDelay = ( d i s t a n c e * 2 . 0 / 3 0 0 . 0 / 3 . 0 ) ; / / D i v i d e d i s t a n c e by speed t o g e t t i m e95 re turn ( i n t ) ( s t d : : c e i l ( p ropDelay ) ) ;96 }9798 i n t c a l c S l o t T i m e ( double d i s t a n c e ) {
Anhang 124
99 re turn 9 + 3 * c a l c C o v e r a g e C l a s s ( d i s t a n c e ) ;100 }101 . . .
Hinzufügen der WiLDToken-Frames
Listing A.3: Auszug aus enum WifiMacType (src/wifi/model/wifi-mac-header.h)71 . . .72 enum WifiMacType73 {74 . . .75 WT_MAC_SYNC_REQ,76 WT_MAC_SYNC_REPL,77 WT_MAC_DATA,78 } ;79 . . .
Listing A.4: Auszug aus ns3::WifiMacHeader (src/wifi/model/wifi-mac-header.cc): SetType313 . . .314 void315 WifiMacHeader : : Se tType ( enum WifiMacType t y p e )316 {317 sw i t ch ( t y p e )318 {319 . . .320 case WT_MAC_SYNC_REQ:321 m_c t r lType = 3 ; / / 0b11322 m _ c t r l S u b t y p e = 8 ; / / 0 b1000323 break ;324 case WT_MAC_SYNC_REPL:325 m_c t r lType = 3 ; / / 0b11326 m _ c t r l S u b t y p e = 9 ; / / 0 b1001327 break ;328 case WT_MAC_DATA:329 m_c t r lType = 3 ; / / 0b11330 m _ c t r l S u b t y p e = 0 ; / / 0 b0000331 break ;332 }333 . . .
Änderungen am MAC Low
Listing A.5: Auszug aus ns3::WtMacLow (src/wifi/model/wt-mac-low.cc): StartTransmission476 . . .477 void478 WtMacLow : : S t a r t T r a n s m i s s i o n ( P t r < c o n s t Packe t > packe t ,479 c o n s t WifiMacHeader * hdr ,480 MacLowTransmiss ionParamete r s params ,481 MacLowTransmis s ionL i s t ene r * l i s t e n e r )482 {483 NS_LOG_FUNCTION ( t h i s << p a c k e t << hdr << params << l i s t e n e r ) ;484 / *485 * T h i s method i s c a l l e d by any WtTxop i n o r d e r t o s t a r t p a c k e t t r a n s m i s s i o n486 * f o r i n d i v i d u a l p a c k e t s . U n l i k e t h e o r i g i n a l i n t e n t i o n o f t h i s f u n c t i o n i n MacLow ,487 * WtMacLow does n o t t a k e over c o n t r o l ove r t h e d e q u e u e i n g p r o c e s s . The l a t t e r488 * i s s o l e l y hand led by t h e i n d i v i d u a l WtTxops a f t e r t h e y have been g r a n t e d a c c e s s by t h e
WtManager489 * /490 / / f i r s t o f a l l , make t h e fo rwarded p a c k e t t h e c u r r e n t one491 m _ c u r r e n t P a c k e t = packe t−>Copy ( ) ;492 / / same t h i n g f o r t h e header493 m_cur ren tHdr = * hdr ;494 / / c a n c e l a l l t i m i n g e v e n t s ( j u s t r ema inder o f mother c l a s s )495 C a n c e l A l l E v e n t s ( ) ;496 m _ l i s t e n e r = l i s t e n e r ;497 m_txParams = params ;498499 / / Per form MPDU a g g r e g a t i o n i f p o s s i b l e500 m_ampdu = IsAmpdu ( m _ c u r r e n t P a c k e t , m_cur ren tHdr ) ;501 i f ( m_ampdu )502 {503 AmpduTag ampdu ;504 m _ c u r r e n t P a c k e t−>PeekPacke tTag ( ampdu ) ;505 i f ( ampdu . GetNoOfMpdus ( ) > 1 && ! hdr−>IsWt ( ) )506 {
Anhang 125
507 m_txParams . EnableCompressedBlockAck ( ) ;508 }509 }510 . . .
Listing A.6: Auszug aus ns3::WtMacLow (src/wifi/model/wt-mac-low.cc): StartTransmission(Forts.)
509 . . .510 i f ( m_cur ren tHdr . I sQosData ( ) )511 {512 / / I f we have a new frame . . .513 i f ( ! m_cur ren tHdr . I s R e t r y ( ) )514 {515 / / Add i t t o B lock Ack Manager . . .516 Time m_cur r en tPacke tT imes t amp ;517 m_bAckManager−>S t o r e P a c k e t ( m _ c u r r e n t P a c k e t , m_curren tHdr ,518 m_cur r en tPacke tT imes t amp ) ;519 }520 }521 . . .
Listing A.7: Auszug aus ns3::WtMacLow (src/wifi/model/wt-mac-low.cc): StartTransmission(Forts.)
519 . . .520 / / S t a r t A−MPDU t r a n s m i s s i o n521 i f ( hdr−>IsWt ( ) )522 {523 SendDa taPacke t ( ) ;524 }525 }526 . . .
Listing A.8: Auszug aus ns3::WtMacLow (src/wifi/model/wt-mac-low.cc): ReceiveOk (Daten-und WiLDToken-Frames)
728 . . .729 e l s e i f ( hdr . GetAddr1 ( ) == m _se l f | | hd r . GetAddr1 ( ) . I sGroup ( ) )730 {731 m_s ta t ionManager−>ReportRxOk ( hdr . GetAddr2 ( ) , &hdr , rxSnr , t x V e c t o r . GetMode ( ) ) ;732733 W i f i M a c T r a i l e r f c s ;734 packe t−>RemoveTra i l e r ( f c s ) ;735736 / / T h i s i s a p a c k e t we want t o acknowledge737 i f ( ! hdr . IsWt ( ) )738 {739 u i n t 1 6 _ t seqNumber = hdr . GetSequenceNumber ( ) ;740741 i f ( m_isF i r s tMpdu )742 {743 m_bAckCache . I n i t ( seqNumber , 64) ;744 m_isF i r s tMpdu = f a l s e ;745 }746 / / I n s e r t f rame seq Number i n B lock Ack Cache747 m_bAckCache . UpdateWithMpdu(& hdr ) ;748 }749 e l s e750 {751 / / Genera te B lock Ack and Enqueue i n t o m_aggregateQueue752 GenBlockAck ( hdr . GetAddr2 ( ) ) ;753 / / L a s t MPDU o f frame i s Wt , so n e x t t i m e we have f i r s t MPDU754 m_isF i r s tMpdu = t rue ;755 }756757 / / f o rward up t o macrxmidd le758 m_rxCa l lback ( packe t , &hdr ) ;759 }760 . . .
Listing A.9: Auszug aus ns3::WtMacLow (src/wifi/model/wt-mac-low.cc): HandleRetransmissi-ons
Anhang 126
545 . . .546 void547 WtMacLow : : H a n d l e R e t r a n s m i s s i o n s ( void )548 {549 NS_LOG_FUNCTION ( t h i s ) ;550 m_reTxBytes = 0 ;551 m_reTxTime = Seconds ( 0 ) ;552 m_reTxMpdus = 0 ;553554 whi le ( m_bAckManager−>H a s P a c k e t s ( ) )555 {556 P t r < c o n s t Packe t > p a c k e t = m_bAckManager−>Ge tNex tPacke t ( m_cur ren tHdr ) ;557 i f ( p a c k e t != 0 )558 {559 m _ c u r r e n t P a c k e t = packe t−>Copy ( ) ;560561 / / Per form MPDU a g g r e g a t i o n i f p o s s i b l e562 m_ampdu = IsAmpdu ( m _ c u r r e n t P a c k e t , m_cur ren tHdr ) ;563 i f ( m_ampdu )564 {565 AmpduTag ampdu ;566 m _ c u r r e n t P a c k e t−>PeekPacke tTag ( ampdu ) ;567568 MacLowTransmiss ionParamete r s params ;569 params . D i s a b l e O v e r r i d e D u r a t i o n I d ( ) ;570 m_reTxBytes += m _ c u r r e n t P a c k e t−>G e t S i z e ( ) ;571 m_reTxTime += C a l c u l a t e T r a n s m i s s i o n T i m e ( m _ c u r r e n t P a c k e t , &
m_currentHdr , params ) ; ;572 m_reTxMpdus ++;573 }574 }575 }576 }577 . . .
Mac High
Listing A.10: Auszug aus ns3::MacRxMiddle (src/wifi/model/mac-rx-middle.cc): Receive300 . . .301 void302 MacRxMiddle : : Rece ive ( P t r < Packe t > packe t , c o n s t WifiMacHeader * hdr )303 {304 NS_LOG_FUNCTION ( p a c k e t << hdr ) ;305 NS_ASSERT ( hdr−>I s D a t a ( ) | | hdr−>IsMgt ( ) | | hdr−>IsWt ( ) ) ;306 . . .
Listing A.11: Auszug aus ns3::WtWifiMac (src/wifi/model/wt-wifi-mac.cc): Konstruktor41 . . .42 WtWifiMac : : WtWifiMac ( )43 {44 NS_LOG_FUNCTION ( t h i s ) ;45 m_rxMiddle = new MacRxMiddle ( ) ;46 m_rxMiddle−>S e t F o r w a r d C a l l b a c k ( MakeCal lback (&WtWifiMac : : Receive , t h i s ) ) ;4748 m_txMiddle = new MacTxMiddle ( ) ;4950 m_low = C r e a t e O b j e c t <WtMacLow> ( ) ;51 m_low−>S e t R x C a l l b a c k ( MakeCal lback (&MacRxMiddle : : Receive , m_rxMiddle ) ) ;5253 m_wtManager = new WtManager ( t h i s ) ;54 m_wtManager−>S e t u p L o w L i s t e n e r ( m_low ) ;55 m_wtManager−>S e t S e n d L i m i t B y t e ( m_sendLimi tByte ) ;56 m_wtManager−>SetSendLimi tT ime ( m_sendLimitTime ) ;5758 m_wtTxopNqos = C r e a t e O b j e c t <WtTxop> ( ) ;59 m_wtTxopNqos−>SetLow ( m_low ) ;60 m_wtTxopNqos−>SetManager ( m_wtManager ) ;61 m_wtTxopNqos−>SetTxMiddle ( m_txMiddle ) ;62 m_wtTxopNqos−>SetTxOkCal lback ( MakeCal lback (&WtWifiMac : : TxOk , t h i s ) ) ;63 m_wtTxopNqos−>S e t T x F a i l e d C a l l b a c k ( MakeCal lback (&WtWifiMac : : TxFa i l ed , t h i s ) ) ;6465 / / C o n s t r u c t t h e QoS Txops . The o r d e r i n g i s i m p o r t a n t − h i g h e s t66 / / p r i o r i t y ( Tab le 9−1 UP−to−AC mapping ; IEEE 802.11−2012) must be c r e a t e d67 / / f i r s t .68 SetupWtTxopQueue (AC_VO) ;69 SetupWtTxopQueue ( AC_VI ) ;70 SetupWtTxopQueue (AC_BE) ;71 SetupWtTxopQueue (AC_BK) ;72 m_wtManager−>Schedu leSyncTimeou t ( ) ;73 }74 . . .
Anhang 127
Listing A.12: Auszug aus ns3::WtWifiMac (src/wifi/model/wt-wifi-mac.cc): Getter- und Setter-Methoden für Sendelimits
414 . . .415 void416 WtWifiMac : : S e t S e n d L i m i t B y t e ( u i n t 3 2 _ t s e n d L i m i t B y t e )417 {418 m_wtManager−>S e t S e n d L i m i t B y t e ( m_sendLimi tByte ) ;419 }420421 u i n t 3 2 _ t422 WtWifiMac : : Ge tSendLimi tBy te ( void ) c o n s t423 {424 re turn m_wtManager−>GetSendLimi tBy te ;425 }426427 void428 WtWifiMac : : Se tSendLimi tT ime ( Time sendLimi tT ime )429 {430 m_wtManager−>SetSendLimi tT ime ( m_sendLimitTime ) ;431 }432433 Time434 WtWifiMac : : GetSendLimitTime ( void ) c o n s t435 {436 re turn m_wtManager−>GetSendLimitTime ;437 }438 . . .
Listing A.13: Auszug aus ns3::WtWifiMac (src/wifi/model/wt-wifi-mac.cc): Weiterreichen vonWiLDToken-Frames an den WtManager
460 . . .461 void462 WtWifiMac : : Rece ive ( P t r < Packe t > packe t , c o n s t WifiMacHeader * hdr )463 {464 NS_LOG_FUNCTION ( t h i s << p a c k e t << hdr ) ;465466 Mac48Address t o = hdr−>GetAddr1 ( ) ;467 Mac48Address from = hdr−>GetAddr2 ( ) ;468469 / / Handle WildToken f r am es f i r s t , s i n c e t h e y may be a d d r e s s e d t o b r o a d c a s t . . .470 i f ( hdr−>IsWt ( ) )471 {472 m_wtManager−>Not i fyWtFrameRece ived ( packe t , hdr ) ;473 re turn ;474 }475 . . .
Queue-Management
Listing A.14: Auszug aus ns3::WtTxop (src/wifi/model/wt-txop.cc): NotifyAccessGranted368 . . .369 void370 WtTxop : : N o t i f y A c c e s s G r a n t e d ( void )371 {372 NS_LOG_FUNCTION ( t h i s ) ;373374 m _ c u r r e n t P a c k e t = 0 ;375 m_by tesSen t = 0 ;376 m_packe t sSen t = 0 ;377 m_t imeSent = Seconds ( 0 ) ;378379 / / As long as t h e send l i m i t i s n o t reached y e t and we s t i l l have p a c k e t s l e f t i n t h e Queue380 whi le ( m_by tesSen t < m_sendLimi tByte381 && m_timeSent < m_sendLimitTime382 && m_packe t sSen t < m _ s e n d L i m i t P a c k e t s383 && ! m_queue−>IsEmpty ( ) )384 {385386 m _ c u r r e n t P a c k e t = m_queue−>D e q u e u e F i r s t A v a i l a b l e (& m_curren tHdr ,
m_cur ren tPacke tT imes tamp , m _ q o s B l o c k e d D e s t i n a t i o n s ) ;387 NS_ASSERT ( m _ c u r r e n t P a c k e t != 0 ) ;388389 u i n t 1 6 _ t s e q u e n c e = m_txMiddle−>GetNextSequenceNumberfor (& m_cur ren tHdr ) ;390 m_cur ren tHdr . SetSequenceNumber ( s e q u e n c e ) ;391 . . .
Listing A.15: Auszug aus ns3::WtTxop (src/wifi/model/wt-txop.cc): GenSyncReq
Anhang 128
560 . . .561 void562 WtTxop : : GenSyncReq ( void )563 {564 / / Cr ea t e new W i f i Header . . .565 WifiMacHeader hdr ;566 / / . . w i t h Type Sync R e q u e s t567 hdr . Se tType (WT_MAC_SYNC_REQ) ;568 / / . . . As B r o a d c a s t569 hdr . SetAddr1 ( Mac48Address : : G e t B r o a d c a s t ( ) ) ;570 / / . . . w i t h my a d d r e s s as s o u r c e571 hdr . SetAddr2 ( m_low−>GetAddress ( ) ) ;572 / / . . . and my BSSID as BSSID573 hdr . SetAddr3 ( m_low−>G e t B s s i d ( ) ) ;574 / / . . . as D S I n t e r n a l f rame ( FromDS=0 ,ToDS=0)575 hdr . SetDsNotFrom ( ) ;576 hdr . SetDsNotTo ( ) ;577 / / . . and empty Payload578 P t r < Packe t > p a c k e t = Crea t e < Packe t > ( ) ;579580 / / A s s i g n Sequence Number581 u i n t 1 6 _ t s e q u e n c e = GetNextSequenceNumberfor (& hdr ) ;582 hdr . SetSequenceNumber ( s e q u e n c e ) ;583 / / I s f i r s t and o n l y f r a g m e n t584 hdr . SetFragmentNumber ( 0 ) ;585 hdr . SetNoMoreFragments ( ) ;586 / / Do n o t r e t r y t h i s f rame587 hdr . Se tNoRet ry ( ) ;588589 / / Cr ea t e new Low t r a n s m i s s i o n p a r a m e t e r s590 MacLowTransmiss ionParamete r s params ;591 params . D i s a b l e O v e r r i d e D u r a t i o n I d ( ) ;592 params . D i s a b l e R t s ( ) ;593 params . Disab leAck ( ) ;594 params . D i s a b l e N e x t D a t a ( ) ;595 / / And s t a r t t r a n s m i s s i o n t o MacLow596 m_low−> S t a r t T r a n s m i s s i o n ( packe t , &hdr , params , m _ t r a n s m i s s i o n L i s t e n e r ) ;597 }598 . . .
Listing A.16: Auszug aus ns3::WtTxop (src/wifi/model/wt-txop.cc): GenSyncRepl556 . . .557 void558 WtTxop : : GenSyncReply ( Mac48Address p e e r )559 {560 / / Cr ea t e new W i f i Header . . .561 WifiMacHeader hdr ;562 / / . . w i t h Type Sync Rep ly563 hdr . Se tType (WT_MAC_SYNC_REPL) ;564 / / . . . w i t h peer a d d r e s s as d e s t i n a t i o n565 hdr . SetAddr1 ( p e e r ) ;566 / / . . . w i t h my a d d r e s s as s o u r c e567 hdr . SetAddr2 ( m_low−>GetAddress ( ) ) ;568 / / . . . and my BSSID as BSSID569 hdr . SetAddr3 ( m_low−>G e t B s s i d ( ) ) ;570 / / . . . as D S I n t e r n a l f rame ( FromDS=0 ,ToDS=0)571 hdr . SetDsNotFrom ( ) ;572 hdr . SetDsNotTo ( ) ;573 / / . . and empty Payload574 P t r < Packe t > p a c k e t = Crea t e < Packe t > ( ) ;575 . . .
Listing A.17: Auszug aus ns3::WtTxop (src/wifi/model/wt-txop.cc): GenDataToken594 . . .595 void596 WtTxop : : GenDataToken ( Mac48Address p e e r )597 {598 / / Cr ea t e new W i f i Header . . .599 WifiMacHeader hdr ;600 / / . . . w i t h Type Data Token601 hdr . Se tType (WT_MAC_DATA) ;602 / / . . . w i t h peer a d d r e s s as d e s t i n a t i o n603 hdr . SetAddr1 ( p e e r ) ;604 / / . . . w i t h my a d d r e s s as s o u r c e605 hdr . SetAddr2 ( m_low−>GetAddress ( ) ) ;606 / / . . . w i t h my BSSID as BSSID607 hdr . SetAddr3 ( m_low−>G e t B s s i d ( ) ) ;608 / / . . . as D S I n t e r n a l f rame ( FromDS=0 ,ToDS=0)609 hdr . SetDsNotFrom ( ) ;610 hdr . SetDsNotTo ( ) ;611 / / . . and empty Payload612 P t r < Packe t > p a c k e t = Crea t e < Packe t > ( ) ;613 . . .
Anhang 129
Kanalzugri�
Listing A.18: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Einplanen vonSync- und Receive-Timeout
262 . . .263 void264 WtManager : : S c h e d u l e R e c e i v e T i m e o u t ( )265 {266 / / T imeout i s n o t s c h e d u l e d , c r e a t e new s c h e d u l e f o r R e c e i v e Timeout267 i f ( ! ( m_rece iveT imeou t . I sRunn ing ( ) ) )268 m_rece iveT imeou t = S i m u l a t o r : : S c h e d u l e ( MicroSeconds ( m_rece iveTimeoutUs ) , &WtManager : :
N o t i f y R e c e i v e T i m e o u t , t h i s ) ;269 }270271 void272 WtManager : : Schedu leSyncTimeou t ( )273 {274 / / Genera te Random I n t be tween 0 and CW s i z e , ana loge t o DCF B a c k o f f275 u i n t 3 2 _ t rnd = m_rng−>GetNext ( 0 , 15) ;276277 / / T imeout i s n o t s c h e d u l e d , c r e a t e new s c h e d u l e f o r Sync Timeout278 i f ( ! ( m_syncTimeout . I sRunn ing ( ) ) )279 m_syncTimeout = S i m u l a t o r : : S c h e d u l e ( MicroSeconds ( m_rece iveTimeoutUs * rnd ) , &
WtManager : : Not i fySyncTimeout , t h i s ) ;280 }281282 void283 WtManager : : R e s c h e d u l e R e c e i v e T i m e o u t ( )284 {285 / / F i r s t , c a n c e l t h i s t i m e o u t286 Cance lRece iveT imeou t ( ) ;287 / / Then , r e s c h e d u l e i t w i t h t h e o r i g i n a l s c h e d u l e f u n c t i o n288 S c h e d u l e R e c e i v e T i m e o u t ( ) ;289 }290291 void292 WtManager : : Cance lRece iveT imeou t ( )293 {294 / / i f t h e t i m e o u t i s n o t e x p i r e d y e t ( s t i l l r u n n i n g ) , c a n c e l i t295 i f ( ! ( m_rece iveT imeou t . I s E x p i r e d ( ) ) )296 m_rece iveT imeou t . Cance l ( ) ;297 }298299 void300 WtManager : : Cance lSyncTimeout ( )301 {302 / / I f t h e t i m e o u t i s n o t e x p i r e d y e t ( s t i l l r u n n i n g ) , c a n c e l i t303 i f ( ! ( m_syncTimeout . I s E x p i r e d ( ) ) )304 m_syncTimeout . Cance l ( ) ;305 }306 . . .
Listing A.19: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Receive-Timeout-Benachrichtigung
372 . . .373 void374 WtManager : : N o t i f y R e c e i v e T i m e o u t ( )375 {376 i f ( m _ s t a t e == RX | | m _ s t a t e == WAIT)377 {378 m _ s t a t e = SYNC;379 Schedu leSyncTimeou t ( ) ;380 }381 }382 . . .
Listing A.20: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Sync-Request/-Reply- und Token-Empfang
306 . . .307 void308 WtManager : : Not i fyWtFrameRece ived ( P t r < Packe t > packe t , c o n s t WifiMacHeader * hdr )309 {310 NS_LOG_FUNCTION ( t h i s << hdr ) ;311 i f ( hdr−>GetType ( ) == WT_MAC_DATA && hdr−>GetAddr2 ( ) == m_peer )312 {313 / / We o n l y a c c e p t Token f r am es i n RX s t a t e314 i f ( m _ s t a t e == RX)315 {316 / / Cancel r u n n i n g R e c e i v e Timeout317 Cance lRece iveT imeou t ( ) ;318 / / S w i t c h t o TX s t a t e
Anhang 130
319 m _ s t a t e = TX;320 / / Handle p a c k e t s t o r e t r a n s m i t321 m_low−>H a n d l e R e t r a n s m i s s i o n s ( ) ;322 / / ha nd l e t h i s Token ( f o r QoS purposes , n o t r e a l l y imp lemen ted f o r now )323 HandleToken ( p a c k e t ) ;324 / / Grant A cc es s t o WtTxops325 DoGrantAccess ( ) ;326327 / / Genera te Token f o r our peer328 WtTxop* txop = *m_wtTxops . b e g i n ( ) ;329 txop−>GenDataToken ( m_peer ) ;330331 / / S c h e d u l e R e c e i v e Timeout332 S c h e d u l e R e c e i v e T i m e o u t ( ) ;333 / / S w i t c h t o RX s t a t e334 m _ s t a t e = RX;335 }336 }337 . . .
Listing A.21: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Sync-Request/-Reply- und Token-Empfang (Forts.)
336 . . .337 e l s e i f ( hdr−>GetType ( ) == WT_MAC_SYNC_REQ)338 {339 / / We o n l y a c c e p t Sync R e q u e s t s i f we are i n sync s t a t e ( s e e s t a t e machine )340 i f ( m _ s t a t e == SYNC)341 {342 / / Thus we need t o c a n c e l our own Sync Timeout343 Cance lSyncTimeout ( ) ;344 / / We a c c e p t our new peer345 m_peer = hdr−>GetAddr2 ( ) ;346347 / / Genera te Sync Rep ly348 WtTxop* txop = *m_wtTxops . b e g i n ( ) ;349 txop−>GenSyncReply ( hdr−>GetAddr2 ( ) ) ;350 / / And s c h e d u l e R e c e i v e Timeout351 S c h e d u l e R e c e i v e T i m e o u t ( ) ;352 / / S w i t c h t o RX s t a t e353 m _ s t a t e = RX;354 }355 }356 . . .
Listing A.22: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Sync-Request/-Reply- und Token-Empfang (Forts.)
336 . . .337 e l s e i f ( hdr−>GetType ( ) == WT_MAC_SYNC_REPL)338 {339 / / We o n l y a c c e p t Sync R e p l y s i n WAIT s t a t e340 i f ( m _ s t a t e == WAIT)341 {342 / / Cancel our own r e c e i v e t i m e o u t s i n c e we have r e c e i v e d t h e r e p l y w i t h i n
t i m e343 Cance lRece iveT imeou t ( ) ;344 / / We a c c e p t our new peer345 m_peer = hdr−>GetAddr2 ( ) ;346347 / / S w i t c h t o TX s t a t e348 m _ s t a t e = TX;349 / / Handle p a c k e t s t o r e t r a n s m i t350 m_low−>H a n d l e R e t r a n s m i s s i o n s ( ) ;351 / / ha nd l e t h i s Token ( f o r QoS purposes , n o t r e a l l y imp lemen ted f o r now )352 HandleToken ( p a c k e t ) ;353 / / Grant A cc es s t o WtTxops354 DoGrantAccess ( ) ;355356 / / Genera te Token f o r our peer357 WtTxop* txop = *m_wtTxops . b e g i n ( ) ;358 txop−>GenDataToken ( m_peer ) ;359360 / / S c h e d u l e R e c e i v e Timeout361 S c h e d u l e R e c e i v e T i m e o u t ( ) ;362 / / S w i t c h t o RX s t a t e363 m _ s t a t e = RX;364 }365 }366 }367 . . .
Anhang 131
Listing A.23: Auszug aus ns3::WtManager (src/wifi/model/wt-manager.cc): Zugriff gewähren(DoGrantAccess)
416 . . .417 void418 WtManager : : DoGrantAccess ( void )419 {420 NS_LOG_FUNCTION ( t h i s ) ;421422 f o r ( WtTxops : : c o n s t _ i t e r a t o r i = m_wtTxops . b e g i n ( ) ; i != m_wtTxops . end ( ) ; i ++)423 {424 WtTxop * txop = * i ;425 P t r <WifiMacQueue > queue = txop−>GetQueue ( ) ;426 i f ( ! ( queue−>IsEmpty ( ) ) )427 {428 txop−>N o t i f y A c c e s s G r a n t e d ( ) ;429 }430 }431 }432 . . .