Implementierung und Optimierung eines Token Passing ... · Anforderungen und Prämissen . . . . . ....

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


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


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.

4

Teil I.

Literatur

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


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


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


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.


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.


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.


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


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


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


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.


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


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


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.

33

Teil II.

Das Protokoll WiLDToken

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


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.


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.


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


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.


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.


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.


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


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.


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


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.


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


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.


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-


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:


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


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


(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


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


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


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)


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


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


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

80

Teil III.

Evaluierung und Diskussion

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


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.


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


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.


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

http://www.radiotap.org/

http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/

http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/

http://www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html

http://www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html

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.

http://www.campsmur.cat/files/mac80211_intro.pdf

http://www.campsmur.cat/files/mac80211_intro.pdf

https://iperf.fr/

http://wow.eecs.berkeley.edu/WTRP/

http://wow.eecs.berkeley.edu/WTRP/

http://events.linuxfoundation.org/sites/events/files/slides/OVS-LinuxCon%202013.pdf

http://events.linuxfoundation.org/sites/events/files/slides/OVS-LinuxCon%202013.pdf

http://lartc.org/lartc.html#LARTC.QDISC

http://lartc.org/lartc.html#LARTC.QDISC

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

https://www.gns3.com/

https://wireless.wiki.kernel.org/en/developers/documentation

https://wireless.wiki.kernel.org/en/developers/documentation

http://wireless.kernel.org/en/users/Drivers

http://wireless.kernel.org/en/users/Drivers

https://wireless.wiki.kernel.org/en/developers/documentation/glossary

https://wireless.wiki.kernel.org/en/developers/documentation/glossary

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

https://n40lab.wordpress.com/2013/05/04/openvswitch-setting-a-bandwidth-limit/



https://mentor.ieee.org/802.11/dcn/03/11-03-0845-01-000n-11-03-0845-00-000n-receiver-sensitivity-tables-mimo-ofdm.ppt



https://www.nsnam.org/docs/release/3.24/doxygen/_trace_source_list.html

https://www.nsnam.org/docs/release/3.24/doxygen/_trace_source_list.html

https://www.nsnam.org/bugzilla/show_bug.cgi?id=2224

https://www.nsnam.org/docs/release/3.24/models/html/

https://www.nsnam.org/docs/release/3.24/models/html/

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.

https://www.nsnam.org/docs/release/3.24/models/html/wifi-design.html

https://www.nsnam.org/docs/release/3.24/models/html/wifi-design.html

https://www.nsnam.org/overview/publications/

https://www.nsnam.org/overview/publications/

https://www.nsnam.org/docs/manual/html/tracing.html

https://www.nsnam.org/docs/manual/html/tracing.html

https://www.nsnam.org/news/ns-3-25-released/

https://www.nsnam.org/news/ns-3-25-released/

http://openvswitch.org/

http://www.isi.edu/nsnam/ns/

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.

http://de.riverbed.com/products/performance-management-control/opnet.html

http://de.riverbed.com/products/performance-management-control/opnet.html

http://tetcos.com/netsim_gen.html

http://www.revolutionwifi.net/revolutionwifi/2014/09/wi-fi-snr-to-mcs-data-rate-mapping.html

http://www.revolutionwifi.net/revolutionwifi/2014/09/wi-fi-snr-to-mcs-data-rate-mapping.html

https://indico.cern.ch/event/376098/contribution/24/attachments/749534/1028288/OVS-rv_20150602_v1.pdf



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

Implementierung und Optimierung eines Token Passing ... · Anforderungen und Prämissen . . . . . ....

Documents

Transcript of Implementierung und Optimierung eines Token Passing ... · Anforderungen und Prämissen . . . . . ....