ieee 802.11e getoetst: parameteroptimalisatie voor...

Faculteit Ingenieurswetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

IEEE 802.11e getoetst: parameteroptimalisatie voor

videodiensten in een draadloze thuisomgeving

door

Koen VERBEECK

Promotoren: Prof. Dr. Ir. B. DHOEDT

Prof. Dr. Ir. F. DE TURCK

Scriptiebegeleider: Ir. W. HAERICK

Scriptie ingediend tot het behalen van de academische graad van

burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2006–2007

i

Woord vooraf

Een thesis op je eentje maken is geen sinecure en op heel deze spannende reis doorheen het

laatste academiejaar heb ik op een aantal mensen kunnen rekenen.

Eerst en vooral wil ik mijn thesisbegeleider Wouter Haerick bedanken, die het ganse jaar door

klaarstond om me met raad en daad bij te staan in het gigantische doolhof dat thesis heet.

Verder bedank ik zeker nog Peter Vandenberghe om zijn tips en trukjes die me het leven een

pak makkelijker maakten. Zijn scriptjes hebben in mijn thesis een tweede leven gevonden en hij

heeft me geholpen met mijn eerste bescheiden stapjes in Linux (damn you, Linux!). Dan dank

ik ook nog de andere mensen van de vakgroep Intec die me op tijd en stond konden helpen met

een probleem.

Verder wil ik zeker mijn ouders en mijn vriendin Sarra in de bloemetjes zetten voor hun niet-

aflatende steun, geduld en geloof.

Ten slotte bedank ik mijn vrienden, in het bijzonder Pierre, Kevin, Maarten en Pieter Jan voor

hun kommaneuken, hun tips en hun goede raad. Pieter Jan krijgt een eervolle vermelding als

’assistent-LATEX-prutser’.

Koen Verbeeck 30 mei 2007

ii

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van

de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek-

king tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit

deze scriptie.”

Koen Verbeeck 30 mei 2007

iii

IEEE 802.11e getoetst:parameteroptimalisatie voor videodiensten

in een draadloze thuisomgevingdoor

Koen VERBEECK

Scriptie ingediend tot het behalen van de academische graad vanburgerlijk ingenieur in de computerwetenschappen

Academiejaar 2006–2007

Promotoren: Prof. Dr. Ir. B. DHOEDT

Prof. Dr. Ir. F. DE TURCK

Scriptiebegeleider: Ir. W. HAERICK

Samenvatting

Aan de ene kant wordt draadloze Internettoegang steeds populairder en heeft dit ondertussenzijn ingang gevonden bij de markt van de thuisgebruikers. Aan de andere kant neemt mediacontent meer en meer aan belang toe. Talloze websites bieden filmpjes aan die in tegenstellingtot vroeger niet meer op de computer opgeslagen worden, maar rechtstreeks gestreamd wordenvan de website. Tegelijkertijd maakt digitale televisie zijn opmars en het is nog maar een kleinestap om het televisietoestel draadloos te verbinden met het internet. Door het gebrek aan Qua-lity of Service kan echter de kwaliteit niet altijd gegarandeerd worden.

Om hiervoor een oplossing te bieden werd de IEEE 802.11e standaard ontworpen die QoS in-troduceert in draadloze netwerken. Deze standaard heeft echter zijn tekortkomingen en is zeeralgemeen gehouden. Deze thesis zoekt dan ook naar een optimalisatie van deze standaard, inhet specifieke geval voor video in een draadloze thuisomgeving. Het resultaat is een aantal opti-male parameterwaarden voor enkele specifieke scenario’s. Tenslotte werd ook een visie opgesteldwaarin uitgezet wordt wat men juist met deze optimalisatie kan doen.

Trefwoorden

IEEE 802.11e, wireless network, Quality of Service, WME/WMM, Video, Multimedia Content,MAC layer

IEEE 802.11e tested: parameter optimization forvideoservices in a wireless home network

Koen Verbeeck

Supervisor(s): Bart Dhoedt, Filip De Turck, Wouter Haerick

Abstract—Wireless Internet access is becoming more and more popular.On the other hand, so is media content. Due to the lack of Quality of Ser-vice in WiFi, there are no guarantees on the quality of the delivered media.Therefore the standard IEEE 802.11e was created, which introduces QoSin wireless Internet. But this standard has its shortcomings and is kept verygeneral. This thesis is a search for optimization of the 802.11e standard, inthe specific situation of video services in a wireless home network.

Keywords— IEEE 802.11e, wireless network, Quality of Service,WME/WMM, Video, Multimedia Content, MAC layer

I. INTRODUCTION

WIFI is conquering the market of home networking, due toits simple installation and low cost. Also, media con-

tent such as digital television is growing more and more rapidlyover the Internet. Legacy 802.11 has no support for Quality ofService (QoS), so quality of the delivered media can not be guar-anteed. That’s why the IEEE 802.11e standard has been created,which introduces QoS in wireless networks. We shall describeshortly how 802.11e works.

802.11e introduces the hybrid coordination function (HCF)for QoS support. This function defines two medium accessmechanisms: enhanced distributed channel access (EDCA),this enhances the legacy DCF, and HCF controlled channelaccess (HCCA). HCCA improves and enhances both DCF andPCF [1]. In practice, 802.11g is enhanced with EDCA and iscalled WME or WMM.

The QoS support in EDCA is provided with the introductionof four access categories – Background (BK), Best Effort (BE),Video and Voice – and multiple back-off entities. MSDUs aredelivered by parallel backoff entities within one 802.11e station,where backoff entities are prioritized using AC-specific con-tention parameters, called EDCA parameter set. By carefullychoosing the parameters, the standard forces different levels ofQoS to the ACs.

But the standard is kept very general and has some shortcom-ings. This thesis searches for an optimization of videoservices,in an home network where WME, the implementation of IEEE802.11e, is deployed.

II. SCENARIOS

Four scenarios were adopted for testing and are described inthe following sections.

A. Scenario 1

The first scenario is interesting for testing purposes, to mea-sure the influences of the different parameters.

Department of Informationtechnology, Ghent University (UGent), Gent, Bel-gium. E-mail: [email protected] .

There is a constant stream of 10 Mbit/s BE traffic in one di-rection and in the other direction a video stream, which is in-cremented with 3 Mbit/s every 10s. With this scenario, one cantest the maximal throughput of the network and see how manyvideo’s the network can handle at the same time.

Only the results gathered before the congestion of the networkare taken into account, so conclusions can be made on reliabledata.

B. Scenario 2

This scenario imitates the most common situation in a homenetwork: one video stream of 3 Mbit/s in one direction and a BEstream in the other. This resembles the situation where someonefor example is watching digital television and another person issending e-mails.

In this scenario, throughput is of less importance than delayand jitter.

C. Scenario 3

Here scenario 2 is expanded with an additional video stream,flowing in the same direction as the BE stream. This can re-semble a situation where someone is sending an e-mail and twoother persons are having a videoconference. Throughput willalso be of less importance here.

D. Scenario 4

This scenario expands scenario 2 with an additional voicestream, flowing in the same direction as the video stream. Thisresembles having a phone call with VoIP while watching avideo. Again, throughput is of less importance, but this time,the voice stream has to be taken into account. Efforts to im-prove video are not allowed to have negative effects on the voicestream.

III. METHODS

The testing network, used in this thesis is shown in figure 1.We have two STAs, on which the software Rude&Crude is in-stalled [2]. Rude sends UDP packets and Crude captures thosepackets and generates statistics. In a configuration file one canspecify what those packets must look like and how fast theyshould be transmitted. Rude has an important feature: with asimple command one can set the TOS field in the IP header. Thevalue of this field gives the AC in which the packet belongs.Thus, by setting the TOS field according to the AC of Video,one can imitate a video stream with Rude&Crude.

For testing purposes, another STA is monitoring the network.Furthermore, an access point is used that connects all the

STAs. The tests were done twice: once with a 3Com AP and

once with a Gigabyte Technology AP. This way the hardwaredependence of WME could be investigated.

Fig. 1. The testing network used in this thesis.

For our optimization, the following parameters from theEDCA set were used: CWmin, CWmax and AIFS. These pa-rameters are changed for every scenario in the exact same way:first the contention window from the AC Video is shrinked. Sec-ondly, we enlarge the contention window from the AC BE is en-larged. Next the AIFS of Video is set to one – for AC as wellfor STA – and the AIFS of BE is incremented. Then the AIFSof Video is set to default and the AIFS of BE is incremented.

Subsequently, the results are visually compared for everystep, hereby finding the optimal value for a scenario. Finally,the optimal values are combined in order to see if a better resultcan be obtained than the most optimal value on its own.

IV. RESULTS

Table I and table II show the results of our tests, first for the3Com AP, then for the Gigabyte AP. As the two tables are notthe same, it has been shown that there is a hardware dependence.

TABLE IOVERVIEW OF THE RESULTS FOR THE 3COM AP.

Scenario Optimale value(set)1 CWmin BE=5, CWmax BE=102 AIFS BE = 73 AIFS BE=7, AIFS VI=14 VI: Cwmin=2, Cwmax=3

TABLE IIOVERVIEW OF THE RESULTS FOR THE GIGABYTE AP.

Scenario Optimal value(set)1 BE: CWmin=6, CWmax=10, AIFS=72 Cwmin VI=1, Cwmax VI=2, AIFS BE=53 BE: Cwmin=6, Cwmax=10, AIFS=74 AIFS BE = 5

In theory, the highest values of a parameter (or the lowest insome cases) should be the most optimal. E.g. when the con-

tention window of Video is at its smallest, better results shouldbe achieved, but this is not the case. This can be explained bythe fact that when a contention window is very narrow, there arelikely to be more collisions, hence less throughput and more de-lay. Another example is where the AIFS of BE is set to be 7.If BE has to wait long to access the medium, then Video has anenormeous advantage. But, as can be seen in the tables, it isn’talway AIFS=7 that produces the best results.

Even stronger, the combinations of various optimal valuesdon’t always provide better results.

V. CONCLUSIONS

The efforts made in the different tests resulted the following:optimal values were found for every scenario. Furthermore, thehardware dependence of IEEE 802.11e was investigated: differ-ent results for the 3Com AP and the Gigabyte AP were found.

These results can be used to create a dynamic access point.This AP detects in which scenario it is and adjusts its parametersaccordingly. This way the best performance can be obtained atany time.

One can also use these results to replace the default values ofWME, thus creating an access point adapted to a specific sce-nario. Or the higher layers in the protocolstack can use these re-sults to communicate their preferences to the wireless netwerk,using TSPEC.

Further research should include more combinations of param-eters, more scenarios and even more APs. Only by doing thisone can achieve a robust model for the dynamic access point.

ACKNOWLEDGMENTS

The author would like to thank Wouter Haerick and PeterVandenberghe for their guidance and many suggestions duringthe making of this thesis.

REFERENCES

[1] Stefan Mangold, Sunghyun Choi, Guido Hiertz, Ole Klein,Bernhard Walke, “Analysis of IEEE 802.11e for QoS sup-port in wireless LANs,” IEEE Wireless Communications,vol. 10, no. 6, pp. 40–50, 2003.

[2] Juha Laine, Sampo Saaristo, Rui Prior, “Rude & Crude,”http://rude.sourceforge.net/, website.

vi

Afkortingen

AC Access Category

ACK Acknowledgement

AIFS(N) Arbitrary Interframe Space (Number)

AP Access Point

BE Best Effort

BK Background

BSS Basic Service Set

CAP Controlled Access Phase

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

CFP Contention Free Period

CP Contention Period

CW Contention Window

DCF Distributed Coordination Function

DIFS DCF Interframe Space

DTIM Delivery Traffic Indication Message

EDCA Enhanced Distributed Channel Access

FCS Frame Check Sequence

HCCA HCF Controled Channel Access

HCF Hybrid Coordination Function

MAC Medium Access Control

MSC Message Sequence Chart

MSDU MAC Service Data Unit

NAV Network Allocation Vector

PC Point Coordinator

vii

PCF Point Coordination Function

PHY Physical layer

PIFS PCF Interframe Space

QAP QoS enhanced AP

QBSS QoS enhanced BSS

QoS Quality of Service

QSTA QoS enhanced STA

RTS/CTS Request To Send/Clear To Send

SAP Service Access Point

SIFS Short Interframe Space

SME Station Management Entity

STA Station

TBTT Target Beacon Transmission Time

TSPEC Traffic Specification

TXOP Transmission Opportunity

VI Video

VO Voice

WiFi Wireless Fidelity

WLAN Wireless LAN

WME Wireless Multimedia Extensions

WMM WiFi Multimedia

INHOUDSOPGAVE viii

Inhoudsopgave

Woord vooraf i

Overzicht iii

English abstract iv

Afkortingen vi

1 Inleiding 1

1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Opbouw van het thesisboek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 QoS met IEEE 802.11e 4

2.1 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Intserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Diffserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 802.11 MAC Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 DCF - De basis access methode . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 PCF voor gecontroleerde toegang . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 QoS beperkingen in de originele 802.11 MAC . . . . . . . . . . . . . . . . 12

2.3 QoS ondersteuningen in IEEE 802.11e . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 EDCA voor ondersteuning van prioritair trafiek . . . . . . . . . . . . . . . 14

2.3.2 HCCA ondersteuning voor geparametriseerd trafiek . . . . . . . . . . . . 16

2.3.3 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

INHOUDSOPGAVE ix

3 Methodiek 19

3.1 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.3 Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Testscenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.3 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.4 Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3 Meetmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Resultaten 28

4.1 Inleidende meting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Aanpassen CW Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.2 Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.3 Aanpassen AIFS BE (video: AIFS = 1) . . . . . . . . . . . . . . . . . . . 34

4.2.4 Aanpassen AIFS BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.5 Vergelijken van de optimale waarden . . . . . . . . . . . . . . . . . . . . . 35

4.2.6 Combineren van de optimale waarden . . . . . . . . . . . . . . . . . . . . 35

4.2.7 Figuren scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


4.3.2 Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43






4.4 Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


4.4.2 Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

INHOUDSOPGAVE x






4.5 Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


4.5.2 Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.5.3 Aanpassen AIFS BE (video: 1) . . . . . . . . . . . . . . . . . . . . . . . . 64





5 Besluit 73

5.1 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Toekomstvisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.3 Verder verloop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A Extra informatie IEEE 802.11e 77

A.1 Verbeterde efficientie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.2 Trafiek specificaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.3 Extra meting: Video vs BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

B Het uitvoeren van een meting 80

C Inhoud van de CD-ROM 84

Lijst van figuren 86

Lijst van tabellen 91

Bibliografie 92

INLEIDING 1

Hoofdstuk 1

Inleiding

1.1 Probleemstelling

De laatste jaren is WiFi aan een enorme opmars bezig in het marktsegment van netwerken bij de

thuisgebruiker. Door de eenvoudige installatie opteren steeds meer mensen voor een draadloos

netwerk. Met de komst van nieuwe standaarden (zoals de 802.11e en 802.11n standaard) worden

draadloze verbindingen steeds sneller en betrouwbaarder. Verwacht wordt dan ook dat Wifi zijn

opmars zal verder zetten en op termijn misschien Wired Ethernet helemaal gaat vervangen.

Hoewel vandaag de dag een draadloze verbinding voldoende betrouwbaar is voor toegang tot het

Internet, ontstaan er problemen wanneer men media content wil ontvangen. Bij het ontvangen

van dit soort data is de pakket delay (vertraging) immers zeer kritisch. Door het gebrek aan

Quality of Service (QoS) in draadloze netwerken laat de kwaliteit van bvb. video vaak te wensen

over.

Als oplossing werd de IEEE 802.11e standaard in het leven geroepen. Deze standaard voldoet

aan de verwachtingen (zie bijvoorbeeld [16], [29],[2], [17] en A.3), maar is echter zeer algemeen

gehouden om met alle problemen te kunnen omgaan. Daardoor gaan er situaties ontstaan waar

de aanpak niet optimaal zal zijn. Verder zijn er een aantal beperkingen aan de standaard:

er kan maar een beperkt aantal flows ondersteund worden (vanwege schaalbaarheid, [14]), de

prioriteiten worden niet deterministisch bepaald, er is nog throughput asymmetry aanwezig en

de standaard is enorm gevoelig voor de keuze van de parameters.

1.2 Doelstellingen 2

1.2 Doelstellingen

In deze thesis gaan we de 802.11e standaard, in toepassingen de EDCA-implementatie (zie 2.3.1)

die WMM (WiFi Multimedia) of WME (Wireless Multimedia Extensions) genoemd wordt, aan-

passen om optimalisaties te bekomen voor specifieke scenario’s. De IEEE 802.11e standaard is

in feite een uitbreiding van de IEEE 802.11 standaard. In praktijk vind men dus de 802.11g

standaard die uitgebreid is met WME, de feitelijke implementatie van 802.11e. Met het oog op

de snel groeiende markt van de digitale televisie is er gekozen voor scenario’s die zich situeren in

een draadloos thuisnetwerk waar verschillende multimediacontents aangeboden worden. Er zijn

verschillende eindstations aanwezig: een of meerdere PC’s, een telefoon die VoIP ondersteunt

en een tv-toestel dat digitale televisie ontvangt.

Figuur 1.1: Het thuisnetwerk dat model staat in deze thesis

Figuur 1.1 toont een mogelijke configuratie van het thuisnetwerk. De laptops kunnen zowel

video, spraak als best effort verkeer (bijvoorbeeld FTP, HTTP, ) ontvangen, terwijl de telefoon

alleen spraak ontvangt en het televisietoestel alleen video. Belangrijk om op te merken is dat

enkel het aantal QoS streams van tel is en niet het aantal toestellen.

We gaan dus in de 802.11e standaard enkele hendels zoeken, die ons toelaten het toekennen van

de prioriteiten van het verkeer te beınvloeden. Enkele voorbeelden van zulke hendels zijn: het

aantal access categories, het contention window en het arbitrary interframe space number. Al

deze termen worden verklaard in het inleidende hoofdstuk over 802.11. Door het aanpassen van

deze hendels kan onze situatie verbeterd worden, wat gestaafd zal worden met metingen. Verder

zal ook onderzocht worden of bij het wijzigen van de hendels een negatieve impact is op andere

1.3 Opbouw van het thesisboek 3

situaties. Aldus zullen we een optimalisatie trachten te bekomen voor de uitgekozen scenario’s.

Voor meer informatie over deze scenario’s wordt verwezen naar 3.2.

1.3 Opbouw van het thesisboek

• Hoofdstuk 2: QoS met IEEE 802.11e

In dit hoofdstuk worden begrippen uitgelegd die belangrijk zijn voor het begrijpen van deze

thesis. Verder wordt ook de 802.11 standaard uit de doeken gedaan, net als de 802.11e

standaard.

• Hoofdstuk 3: Methodiek

In dit hoofdstuk wordt de testopstelling besproken. Daarna worden de testscenario’s en

de wijze waarop de metingen worden aangepakt toegelicht.

• Hoofdstuk 4: Resultaten

In dit hoofdstuk worden de resultaten van de metingen getoond en besproken.

• Hoofdstuk 5: Besluit

In dit laatste hoofdstuk worden de eindconclusies gegeven. Verder wordt er gekeken naar

wat er nog uitgebreid en verbeterd kan worden.

QOS MET IEEE 802.11E 4

Hoofdstuk 2

QoS met IEEE 802.11e

2.1 Quality of Service

De term Quality of Service (QoS) wordt gebruikt om uit te drukken wat de kwalititeit is van

een geleverde dienst. Dit doet men aan de hand van een verzameling van kwalitatieve en kwan-

titieve karakteristieken, welke een stroom trafiek die een bepaalde dienst vervoert, beschrijven

[26]. Voorbeelden van deze karakteristieken zijn throughput, jitter, pakketgrootte, vertraging,

prioriteit enz.

Aan QoS in bedrade netwerken wordt minder aandacht besteed, omdat de bandbreedte enorm

hoog kan liggen en het aantal fouten in de fysieke laag enorm klein is.

Draadloze systemen hebben echter te kampen met zeer grote overhead op pakketten. Zo kan

32% van het datadebiet door pakketfragmentatie, interframe spacing (zie 2.2.1) en MAC-level

acknowledgement geconsumeerd worden. Wanneer RTS/CTS (zie 2.2) gebruikt wordt, kan dit

oplopen tot 50% van het datadebiet, wat resulteert in een gelimiteerde bandbreedte.

Verder is de bandbreedte van het draadloze medium gelimiteerd. De beschikbare bandbreedte

is de laatste jaren enorm toegenomen, maar heeft nog niet het volume van bedrade netwerken

bereikt.

De kwaliteit van de meeste multimediadiensten, waaronder audio- en videotransmissie, vermin-

dert drastisch als de vertraging (delay) een bepaalde waarde overschrijdt. Dit is een serieuze

tekortkoming die 802.11 verhindert om nieuwe markten in de multimediadiensten te penetreren.

Daardoor stelde de 802.11e Task Group enkele verbeteringen voor in de MAC laag.

2.1 Quality of Service 5

Voor het bedrade netwerk zijn er twee architecturen voorhanden die QoS ondersteunen en pri-

oriteiten kunnen toekennen aan trafiek: IETF’s Integrated Services (IntServ) en Differentiated

Services (DiffServ). We zullen beide architecturen kort bespreken.

2.1.1 Intserv

IntServ definieert een flow van trafiek als een onderscheidbare trafiekstroom van datagrammen

van een unieke zender naar een unieke ontvanger [24]. Met andere woorden, de architectuur

behandelt elke trafiekstroom in het netwerk apart. De zender en ontvanger zijn ontstaan door

een enkele activiteit van een gebruiker en ze vereisen dezelfde QoS. Het achterliggende idee van

IntServ is dat elke router deze architectuur implementeert en dat applicaties die gebruik willen

maken van QoS een individuele reservatie moeten maken. Men maakt gebruik van een signaling

protocol, zoals RSVP, om deze reservatie tot stand te brengen. Flow specificaties beschrijven

dan hoe deze reservatie er moet uitzien.

IntServ biedt een zeer hoge precisie aan om resources te alloceren, maar heeft wel te kampen

met problemen i.v.m. schaalbaarheid. Dit wordt veroorzaakt door de soft state voor elke flow

die in elke router doorheen het pad bijgehouden moet worden. Dit betekent dat elke router op

het pad informatie moet bijhouden voor elke flow, wat veel overhead met zich meebrengt.

2.1.2 Diffserv

DiffServ daarentegen maakt geen gebruik van signalisatie per flow en consumeert dan ook geen

resources in de router per flow.

Het protocol alloceert verschillende niveaus van service aan verschillende groepen van gebruikers

[22]. Dit betekent dat al het verkeer in klassen met verschillende QoS parameters onderverdeeld

wordt. Hierdoor moet alleen in de edge routers een status bijgehouden worden. In deze routers

worden dan de datagrammen geclassificeerd naargelang de service klasse waarin ze thuishoren.

Eens het datagram in het DiffServ-domein is, zal deze door alle routers dezelfde behandeling

krijgen die past bij de categorie van service die door de edge router werd aangeduid. Bijvoor-

beeld: men maakt een klasse ’goed’, ’middelmatig’ en ’slecht’ aan. Men geeft vervolgens al

het verkeer een label waarop staat in welke klasse ze horen. Het verkeer wordt dan behandeld

naargelang de klasse waar ze toe behoren.

2.2 802.11 MAC Layer 6

DiffServ is een schaalbaar protocol, maar kan de precisie niet bereiken die IntServ wel haalt.

Daarom noemt men DiffServ een coarse-grained en IntServ een fine-grained mechanisme.

2.2 802.11 MAC Layer

Het doel van de 802.11 MAC laag is om betrouwbare dataoverdracht aan de client van de laag

aan te bieden (nl. hogere protocollagen) en om eerlijke toegang tot het gedeelde draadloze me-

dium te controleren [20], [5]. De MAC laag zelf is een van de twee sublagen van de datalink

laag. Voor meer verduidelijking verwijs ik naar figuur 2.1 en naar [27].

Figuur 2.1: De protocol stack

We beschouwen een infrastructuur (basic service set of BSS) opgebouwd uit een access point

(AP) en een aantal draadloze stations (STAs) geassocieerd met het AP. Zie figuur 2.2 voor een

voorbeeld.

Om de betrouwbare dataoverdracht te garanderen definieert 802.11 een frame exchange protocol.

De minimale overdracht bestaat uit 2 frames: een frame van de bron naar de ontvanger (MAC

service data unit of MSDU), het feitelijke dataframe, en een bevestiging (acknowledgment of

ACK) van ontvanger naar bron. Bij elk frame dat door de MAC ontvangen wordt, gebeurt er

2.2 802.11 MAC Layer 7

Figuur 2.2: BSS met AP en verschillende STAs

een controle van de frame check sequence (FCS) om fouten veroorzaakt door de transmissie –

bijvoorbeeld door ruis op het kanaal – te ontdekken. Bij het uitblijven van een ACK wordt het

frame opnieuw verzonden.

Bij deze basisoverdracht kan ook nog het optionele request to send/clear to send (RTS/CTS)

mechanisme toegevoegd worden. Hierdoor verkrijgt men een meer robuust protocol en het lost

problemen op zoals het ’hidden node problem’ [6].

Dit probleem komt voor wanneer STAs niet op de hoogte zijn van elkaars bestaan, bijvoorbeeld

door ruis of een grote afstand. Laten we als voorbeeld nemen dat STA A en STA B verbonden

zijn met een AP. STA A weet niet dat STA B bestaat en kan dus een transmissie starten terwijl

B al bezig is met het verzenden van datagrammen (of vice versa). Hoogstwaarschijnlijk zal

deze situatie een botsing (collision) op het kanaal veroorzaken waardoor beide STAs hun frames

moeten herzenden. Met RTS/CTS zal deze botsing echter niet plaatsvinden. STA B zal een

RTS verzenden en een CTS ontvangen (net zoals STA A) van de AP. De tijdswaarde in de CTS

zal STA A lang genoeg tegenhouden zodat STA B het frame kan verzenden.

RTS/CTS kan dus de prestatie van een netwerk verbetereren en het aantal collisies beperken

indien verborgen STAs aanwezig zijn. Dit gaat wel gepaard met een stijging van de overhead.

Alle frames bevatten tijdsinformatie over de lengte van de MSDU/ACK transmissie. De om-

liggende STAs kunnen, gebaseerd op deze informatie, een interne timer updaten. Deze timer,

network allocation vector (NAV) wordt gebruikt om alle communicatie stop te zetten totdat de

NAV verlopen is.

2.2 802.11 MAC Layer 8

De 802.11 standaard specificeert twee channel access functies: distributed coordination function

(DCF) en point coordination function (PCF). Beide functies worden in volgende paragrafen

besproken.

2.2.1 DCF - De basis access methode

De DCF laat het delen van het draadloze medium tussen compatibele toestellen op de fysieke

laag toe. Het opereert als een listen-before-talk schema, wat in de praktijk neerkomt op het

gebruik van een Carrier sense multiple access with collision avoidance (CSMA/CA) protocol.

Dit mechanisme is verplicht voor alle STAs.

Carrier sense multiple access

Een STA bepaalt individueel wanneer het draadloze medium betreden wordt. Hierdoor wordt het

beslissingsproces gedistribueerd over alle STAs. Een MSDU van onbepaalde lengte zal verstuurd

worden (’talk’) wanneer gedetecteerd wordt dat er geen andere transmissies plaatsvinden op het

draadloze medium (’listen’). Als twee of meerdere STAs op hetzelfde moment het kanaal als

idle detecteren, kunnen ze tegelijkertijd een transmissie initieren, waardoor onvermijdelijk een

botsing zal plaatsvinden.

Collision Avoidance

Om de kans op botsingen te verminderen past de DCF een collision avoidance schema toe, waar

de STAs een zogenaamde backoff procedure uitvoeren voordat ze een transmissie beginnen.

Na het detecteren van het kanaal als leeg (idle) voor een minimale duratie, DCF interframe

space (DIFS, 34 s in 802.11a) genaamd, blijft een STA luisteren naar het kanaal gedurende een

additionele random tijd (backoff time).

Een transmissie wordt enkel begonnen als het kanaal tijdens deze backoff periode ongebruikt

blijft. De duratie van dit interval wordt individueel voor elk STA bepaald, als een meervoud van

een slottijd (9 µs in 802.11a). Het bereik van waarden voor de backoff tijd noemt men het conten-

tion window en hangt af van vorige pogingen tot retransmissie. Zo zal deze verdubbeld worden

na een gefaalde transmissie tot deze de maximale waarde CWmax bereikt heeft. Aangezien

alle STAs werken met dezelfde startwaarde CWmin, hebben ze dus ook dezelfde medium access

prioriteit in DCF. Bijvoorbeeld: stel dat CWmin = 2 en CWmax = 6. De eerste maal dat er een

backoff uitgevoerd moet worden zal men moeten kiezen uit een interval tussen 0 en 3 (=22− 1).

2.2 802.11 MAC Layer 9

Als een transmissie faalt, (door een botsing bijvoorbeeld) zal dit interval verdubbelen: men moet

kiezen tussen 0 en 7 (=23 − 1) slottijden. Het interval blijft niet onbeperkt stijgen, maar krijgt

uiteindelijk een plafond bepaalt door CWmax. In dit voorbeeld is dit dus het interval van 0 tot

63 (26 − 1). Als men CWmax bereikt heeft kan men dus maar maximaal 63 slottijden wachten.

Wanneer een succesvolle transmissie is geıniteerd, wordt het interval teruggebracht naar CWmin.

Wanneer het kanaal gebruikt wordt door andere transmissies of interferentie tijdens het aftellen

van de backoff counter, stopt het STA met aftellen en stelt de medium access uit totdat het

kanaal voor een DIFS ongebruikt blijft. Na dit uitstel wordt gewoon verder gegaan met het

aftellen.

Na elke succesvolle transmissie initieert het STA een nieuwe random backoff, zelfs als er geen

MSDU klaarstaat om verzonden te worden. Dit noemt men de post-backoff, omdat deze backoff

plaatsvindt na een transmissie i.p.v. ervoor. De post-backoff garandeert dat er altijd 1 random

backoff zit tussen twee opeenvolgende transmissies en is dus belangrijk voor het garanderen van

een vlotte werking van DCF.

Tussen opeenvolgende frames in de sequentie van RTS, CTS, MPDU en ACK frames wordt een

short interframe space (SIFS, 16 µs in 802.11a) ingelast. SIFS is korter dan DIFS, waardoor

ACK altijd de hoogtste prioriteit krijgt om toegang te verkrijgen tot het draadloze medium.

Dit verzekert dat geen enkel STA een uitwisseling van frames kan onderbreken door een nieuwe

transmissie te beginnen.

Wanneer het RTS/CTS mechanisme gebruikt wordt, zetten de STAs hun interne timer, de NAV

(zie pagina 7). De waarde wordt bepaald door de duurtijd, vermeld in de RTS/CTS frames. Dit

geeft aan hoe lang het draadloze medium bezet is. Wanneer een STA een frame wil verzenden,

gaat deze eerst na of de NAV nul is. Indien niet, moet er eerst gewacht worden tot de NAV de

waarde nul bereikt heeft.

Men kan het CSMA/CA protocol beter begrijpen als we een vergelijking trekken met het verga-

deren. Een aantal mensen zit rond een tafel om te vergaderen. Wanneer iemand merkt dat het

een tijdje stil is geweest (het kanaal is idle) zal deze willen beginnen met praten. Wanneer deze

persoon begint met babbelen hangt af van persoon tot persoon (back-off). De ene zal immers

2.2 802.11 MAC Layer 10

Figuur 2.3: Interframe spaces en backoff procedures met random contention window size. Hier heeft

het STA een CW = CWmin (15 slots) en een random backoff time van 12 slots.

wat langer wachten dan de andere. Een andere persoon kan echter net op hetzelfde moment

ook beginnen te praten (collision). De twee personen praten dus door elkaar. Nadat ze gedaan

hebben zullen ze dan ook merken dat niemand hen verstaan heeft (uitblijven van een ACK).

Als iemand gedaan heeft met spreken, dan wacht deze persoon eventjes (post-backoff), zodat hij

niet constant aan het woord is en de vergadering wat vlotter kan verlopen.

DCF heeft geen mechanismen om QoS te ondersteunen en is dus een best effort channel access

methode. Figuur 2.3 illustreert het principe van een random backoff procedure.

2.2.2 PCF voor gecontroleerde toegang

802.11 gebruikt het optionele PCF om QoS te ondersteunen voor tijdgerelateerde diensten. PCF

voorziet mechanismen voor prioritaire toegang tot het draadloze medium en wordt centraal

beheerd door een STA, point coordinator (PC) genaamd. Dit STA is typisch de AP zelf.

802.11 definieert twee perioden tussen twee opeenvolgende delivery traffic indication message

(DTIM) beacon frames: contention free period (CFP) en contention period (CP). PCF wordt

gebruikt om toegang tot het medium te verkrijgen tijdens CFP, terwijl DCF gebruikt wordt

tijdens CP. Een CP moet van een zodanige minimale lengte zijn dat er op zijn minst 1 frame

uitwisseling kan plaatsvinden, met als voorwaarden dat dit frame de maximale grootte heeft en

dat men werkt met de traagste transmissietijd onder DCF.

DTIM beacon frames worden gebruikt door de PC om de start van een CFP aan te geven,

2.2 802.11 MAC Layer 11

om synchronisatie van de lokale timers te bekomen en om protocolgerelateerde parameters door

te sturen. Elk STA weet wanneer het volgende beacon frame toekomt. Deze punten in de tijd

noemt men target beacon transmission times of TBTTs en worden aangekondigd door het vorige

beacon frame.

Gedurende de CFP is er geen contention, maar worden de STAs gepolled door de PC. Deze

regelt transmissies naar en/of van individuele STAs. De PC gaat dus STAs vragen of ze een

transmissie willen beginnen. Door een STA meerdere keren tijdens een CFP te bevragen kan de

PC dit STA dus meer voorrang geven.

De PC krijgt toegang tot het medium na een PCF interframe space (PIFS, 25 µs in 802.11a)

die begint na een TBTT. PIFS is korter dan DIFS, maar langer dan SIFS. Hierdoor krijgt PCF

een hogere prioriteit dan DCF, maar kan dan wel geen gestarte DCF transmissies onderbreken.

Wanneer de AP geen antwoord krijgt van een polled STA na PIFS, gaat de AP over naar een

volgend STA of de CFP wordt beeindigd. Na de CFP vindt de CP plaats, waar de verschillende

STAs toegang tot het medium proberen te verkrijgen via DCF. In figuur 2.4 vindt men een

voorbeeld van een PCF operatie.

Figuur 2.4: Een voorbeeld van een PCF operatie. Station 1 is de PC en polls station 2. Station 3

ontvangt het beacon frame en stelt zijn NAV in op de gehele CFP.

PCF dwingt QoS af door verkeer met lage prioriteit niet te laten zenden tijdens de CFP. Dit

wordt bereikt door PIFS kleiner te kiezen dan DIFS. PCF heeft echter serieuze tekortkomingen.

Deze worden besproken worden in de volgende paragraaf.

2.3 QoS ondersteuningen in IEEE 802.11e 12

2.2.3 QoS beperkingen in de originele 802.11 MAC

DCF heeft geen enkele voorziening om QoS te ondersteunen. Alle data wordt op een first co-

me first serve, best-effort manier behandeld. Hierdoor wordt een asymmetrie tussen uplink en

downlink bekomen, omdat de AP dezelfde prioriteit heeft als de andere STAs, maar wel een veel

hogere throughput requirement heeft. Beschouw het volgende voorbeeld: STA A en STA B zijn

met elkaar verbonden via een AP. Als A trafiek stuurt naar B, dan passeert dit via het AP. A

moet dus enkel verzenden en B moet enkel ontvangen. Maar het AP moet het trafiek van A

ontvangen en versturen naar B. Als B dan nog eens trafiek naar A stuurt, moet het AP het

trafiek van A en B versturen en ontvangen. Hierdoor onstaat dus een asymmetrie tussen STAs

en AP.

Hoewel PCF ontworpen was om tijdgerelateerde trafiek te ondersteunen, zijn er toch veel be-

perkingen. Deze zijn als volgt:

• Onvoorspelbare vertragingen van de beacon frames. Dit resulteert in significant kleinere

CFP’s.

• Ongekende transmissietijden van polled STAs. Dit maakt het voor de PC moeilijk om het

polling schema te voorspellen en te controleren voor de rest van de CFP.

• Ontbreken van een management interface om PCF operaties, zoals polling, op te zetten en

te controleren. Hierdoor is het onmogelijk om een policy omtrent PCF op te zetten naar

de eisen van protocollen uit de hogere lagen, zoals IntServ en DiffServ.

• Ontbreken van een mechanisme waarin STAs hun QoS requirements kunnen communiceren

naar de PC toe. Dit is nochtans essentieel om de prestatie van het polling algoritme te

kunnen optimaliseren.

• Geen mogelijkheid om nieuw/extra verkeer te weigeren (Admission Control).

We kunnen dus stellen dat zowel DCF als PCF onvoldoende zijn om trafiek met QoS require-

ments te ondersteunen.

2.3 QoS ondersteuningen in IEEE 802.11e

IEEE 802.11e definieert een extensie van de IEEE 802.11 standaard. Deze extensie brengt enkele

verbetering aan in de MAC-laag. Deze verbeteringen onderscheiden QoS STAs (QSTAs) van


niet-QoS STAs en een QoS access point (QAP) van een niet-QoS access point. Deze features

worden gezamenlijk QoS faciliteit genoemd.

Er zijn twee functionele hoofdblokken gedefinieerd: de channel access functions en de traffic

specification (TSPEC) management. Voor eerstgenoemde is er een nieuwe coordinatiefunctie,

nl. de hybrid coordination function (HCF) die enkel in QoS basic service sets (QBSS) gebruikt

wordt. HCF heeft twee modi operandi: de enhanced distributed channel access (EDCA) is een

’contention-based channel access function’ dat concurrent samenwerkt met de HCF controlled

channel access (HCCA), gebaseerd op een polling mechanisme dat gecontroleerd wordt door

de hybrid coordinator (HC). Deze bevindt zich meestal in de QAP. EDCA verbetert DCF en

breidt deze uit. HCCA doet hetzelfde voor PCF. EDCA is ontworpen om prioritiare trafiek

te ondersteunen zoals DiffServ, terwijl HCCA geparametriseerd trafiek ondersteunt gelijkaardig

aan IntServ.

Het basisconcept van deze toegangsfuncties is de transmission opportunity (TXOP). Een TXOP

is een gelimiteerd tijdsinterval waarin een QSTA toegestaan wordt om een aantal frames te

verzenden. De TXOP wordt gedefinieerd door een starttijd en een maximale duurtijd. Als

een TXOP verkregen wordt tijdens EDCA, dan noemt men deze een EDCA-TXOP. Analoog

verkrijgen wij een HCCA (polled) TXOP. De TXOP lost het probleem op van de ongekende

transmissietijden dat bestaat bij PCF.

De duurtijd van een EDCA-TXOP wordt gecontroleerd door de QAP en wordt gedistribueerd

naar de niet-AP QSTAs in de beacon frames samen met de andere EDCA gerelateerde parame-

ters. Een dergelijke parameter is bijvoorbeeld de TXOP-limiet, die de lengte limiteert (gebruikt

in de hele QBSS). Deze parameter laat controle over de maximale tijd dat een STA het medium

gebruikt voor MSDU-verkeer toe en is daarom een belangrijk middel om MSDU vertragingen

te controleren. De duurtijd van een HCCA (polled) TXOP wordt direct aan de niet-AP QSTA

gegeven door de HC als deel van een QOS CF-Poll (contention free-poll) frame, welke de HCCA

(polled) TXOP toekent.

EDCA wordt enkel tijdens de CP gebruikt, terwijl HCCA theoretisch tijdens CFP en CP kan

opereren. De standaard raadt echter aan HCCA enkel tijdens CP te gebruiken. Dit komt vooral


door de complexiteit van implementatie om polling door CF-Poll en QoS CF-Poll tegelijkertijd

te laten gebeuren.

In 802.11e wordt op MAC-niveau de ACK optioneel. Dit impliceert dat de betrouwbaarheid

van ’niet-ACK’ trafiek gereduceerd wordt, maar het verbetert wel de algemene efficientie van de

MAC voor tijdgevoelige trafiek, zoals VoIP, waar de data een zekere strikte levensduur heeft.

2.3.1 EDCA voor ondersteuning van prioritair trafiek

De ondersteuning voor QoS in EDCA wordt voorzien door de introductie van access categories

(ACs), die men kan vergelijken met de verschillen klassen in Diffserv, en meerdere onafhankelijke

backoff entiteiten. MSDUs worden geleverd door parallelle backoff entiteiten in een QSTA, waar

deze prioritair zijn door AC-specifieke contention parameters, de EDCA parameter set genaamd.

Er zijn 4 ACs, dus bestaan er in elk QSTA 4 backoff entiteiten, met elk hun eigen parameterset

en hun eigen queue.

De ACs zijn gelabeld naargelang hun doelapplicatie: AC VO (voice), AC VI (video), AC BE

(best effort) en AC BK (background). De parameter set definieert de prioriteiten in medium

toegang door individuele parameters te veranderen, waarvan de belangrijkste hieronder vermeld

zijn:

• Arbitrary inter-frame space number (AIFSN): het minimale tijdsinterval tussen het vrij-

komen van het medium en de start van de verzending van een frame.

• CW: een random nummer wordt getrokken uit dit interval voor het backoff mechanisme.

• TXOP-limiet: de maximale duratie waarin een QSTA kan verzenden nadat deze een TXOP

verkregen heeft.

Figuur 2.5 toont een overzicht van de verschillende ACs.

Wanneer data toekomt, classificeert 802.11e deze eerst in de passende AC en duwt dan de nieuwe

MSDU in de bijhorende AC transmissiequeue. MSDUs van verschillende ACs vechten dan intern

voor de EDCA-TXOP. Een backoff entiteit start met het aftellen van de backoff-counter na

detectie van een leeg kanaal voor een duurtijd gedefinieerd door de arbitration interframe space


Figuur 2.5: Een 802.11 STA en een 802.11e STA met 4 ACs in 1 station

(AIFS[AC]). Deze duurtijd is minstens DIFS en kan vergroot worden met behulp van volgende

formule:

AIFS[AC] = SIFS + AIFSN [AC] ∗ slottijd,AIFSN [AC] ≥ 2 (2.1)

De minimum grootte van het CW, CWmin[AC], is een andere AC-afhankelijke parameter. De

backoff procedure is gelijkaardig aan degene in DCF en de AC met de kleinste backoff wint de

interne competitie.

De winnende AC moet dan extern strijden voor het draadloze medium. In 802.11e is de externe

contention niet significant gewijzigd t.o.v. DCF. Alleen zijn de deferral (als het medium tijdens

de backoff bezet wordt, stopt het STA met aftellen en stelt de toegang tot het medium uit tot

het kanaal ongebruikt is voor een duurtijd DIFS) en de backoff variabel en zijn de waarden

hiervan bepaald naargelang de passende AC.


Figuur 2.6: In EDCA strijden meerdere backoff entiteiten voor toegang tot het medium met verschil-

lende prioriteiten in parallel. De vroegst mogelijke toegangstijd na een bezet medium is

DIFS.

Door de AC parameters gepast te kiezen kan men de trafiekprestatie van verschillende ACs

optimaliseren (wat we dus doen in deze thesis) en trafiekprioriteiten invoeren waardoor QoS

afgedwongen wordt. Dit vereist een centrale coordinator (QAP) om een gemeenschappelijke

verzameling van AC parameters te onderhouden om zo eerlijkheid in de toegang tot het medium

te garanderen voor alle QSTAs in de QBSS. In figuur 2.6 wordt het hele concept nog eens

verduidelijkt.

2.3.2 HCCA ondersteuning voor geparametriseerd trafiek

HCCA erft sommige regels van PCF en introduceert vele uitbreidingen. Gelijkaardig aan PCF

voorziet HCCA gepollede toegang tot het draadloze medium. Daarentegen kan QoS polling

plaatsvinden tijdens CP en het plannen van pakketten is gebaseerd op de toegekende TSPECs.

Een TXOP kan bekomen worden bij de HC via de controlled medium access. De HC mag

TXOPs aan zichzelf toekennen om MSDU leveringen te initieren, nadat het kanaal ongebruikt

gedetecteerd is voor een duratie PIFS en zonder backoff. Om de HC hogere prioriteit te geven

dan DCF en EDCA, moet AIFSN zo gekozen worden dat de vroegste toegang tot het medium


Figuur 2.7: Een voorbeeld van een 802.11e superframe (CP + CFP) waar de HC TXOPs toekent in CP

en CFP

voor EDCA DIFS is voor elke AC.

Gedurende CP begint elke TXOP wanneer het kanaal beschikbaar is onder de regels van EDCA

of wanneer een backoff entiteit een polling frame ontvangt (QoS CF-Poll) van de HC. Dit frame

van de HC kan verzonden worden na een PIFS idle periode zonder backoff.

Gedurende CFP is de starttijd en duratie van elke TXOP gespecificieerd door de HC, alweer door

het gebruik van QoS CF-Poll frames. Tijdens de CFP kunnen backoff entiteiten niet beginnen

met pogingen om toegang tot het medium te verkrijgen zonder dat ze expliciet gepolled zijn.

Een polled QSTA kan gedurende een polled TXOP meerdere frames met een SIFS tussen twee

opeenvolgende frames verzenden, zolang de duratie van de gehele frameuitwisseling niet langer

duurt dan de TXOP limiet. Geen enkele backoff entiteit zendt over de TBTT. Dat wil zeggen

dat een frameuitwisseling enkel gestart wordt indien deze compleet afgehandeld kan worden voor

de volgende TBTT. Dit reduceert de verwachte beacon delay, wat een tekortkoming was bij PCF.

HCCA dwingt QoS af door EDCA uit te breiden door STAs expliciet te pollen op basis van de

TSPECs (zie A.2). Dit laat de hoogste prioriteit toe om toegang te verkrijgen tot het medium.

Dit kan zowel tijdens CFP als CP, wat in contrast is met PCF. De HC krijgt de hoogste prioriteit

door AIFSN[AC] gepast te kiezen, zoals eerder besproken.

Zie figuur 2.7 voor een voorbeeld van een superframe.


2.3.3 Overzicht

Als afsluiter van dit hoofdstuk vatten we alle mechanismen om QoS af te dwingen samen in

tabel 2.1.

Tabel 2.1: Overzicht QoS mechanismen.

Channel Access Function Hoe wordt QoS afgedwongen?

DCF Niet

PCF Verkeer met lage prioriteit mag niet zenden tijdens CFP.

Dit verkrijgt men door PIFS kleiner te maken dan DIFS.

Echter serieuze tekortkomingen.

EDCA Probabalistische priorisatie door de AC parameters gepast

te kiezen. Hierdoor zal verkeer met hoge prioriteit

makkelijker toegang verkrijgen tot het medium.

HCCA Uitbreiden van EDCA door expliciet te pollen op basis

van TSPECs, zowel tijdens CFP als CP.

Voor meer informatie over dit onderwerp wordt verwezen naar: [12], [13], [23], [15], [7], [14] en

appendix A.

METHODIEK 19

Hoofdstuk 3

Methodiek

3.1 Testopstelling

Voor het uitvoeren van de testen en metingen werd een testopstelling toegewezen die nu bespro-

ken zal worden, zowel op het gebied van hardware-, software- en netwerkconfiguratie.

3.1.1 Hardware

De testopstelling bestaat uit twee desktopPC’s, een laptop en een wireless AP. Op de desktops

staat het besturingssysteem Ubuntu (een Linux-distributie), terwijl op de laptop een dualboot

geınstalleerd staat van Ubuntu en Windows XP.

Het is belangrijk om te weten met welke hardware men werkt, omdat de 802.11e standaard enkel

beschrijft hoe deze globaal gezien werkt, maar niet hoe deze geımplementeerd moet worden. Dit

is om concurrentie toe te laten tussen de verschillende fabrikanten, waardoor er dus een verschil

kan optreden tussen de prestaties van verschillende netwerkkaarten.

De desktops beschikken over een wireless ethernet PCI kaart, beide van het merk 3Com [3]. De

laptop beschiktover een kaart van Gigabyte Technology [19]. Alle kaarten zijn voorzien van de

Atheros chipset. Om de kaarten in Ubuntu aan te sturen werd gekozen voor het open-source

MadWifi [9]. Deze driver, specifiek voor kaarten met een Atheros chipset, laat toe om de para-

meters voor WME te configureren. Met het oog op verdere toepassingen is het ook nuttig dat

men deze driver kan aanpassen aan persoonlijke behoeften.

We voorzien twee APs, om zo de afhankelijkheid van de hardware in te calculeren in de metingen.

3.1 Testopstelling 20

Figuur 3.1: Het configuratiescherm voor QoS van het 3Com AP.

Deze APs zijn tevens van de merken 3Com en Gigabyte Technology [4],[18]. We merken op

dat het Gigabyte Technology AP in feite een router is, met ingebouwde wireless AP. Beide

APs hebben de mogelijkheid om via een browser in te loggen in een configuratiemenu, waar

men parameters van WME per AC kan instellen. Figuur 3.1 toont zo’n configuratiescherm.

De parameters die men kan instellen zijn: het minimale en maximale contention window, het

AIFS en de TXOP. Verder kan men ook nog het ACK-policy en admission control per AC

aan- of uitschakelen. Deze parameters zullen we echter niet verder beschouwen, aangezien de

implementaties ofwel nog niet ondersteund zijn ofwel onvoldoende tot zelfs niet gedocumenteerd

zijn [1].

3.1.2 Software

Om de metingen uit te voeren, wordt gebruik gemaakt van enkele tools, die nu kort toegelicht

zullen worden.

Rude&Crude

Op de twee desktop PCs werden de opensource meettools Rude&Crude v0.70 [8] geınstalleerd.

Rude is een meettool die UDP-verkeer genereert aan de hand van een configuratiescript dat de

karakteristieken van de gegenereerde stroom beschrijft. Crude is de complementaire tool die de


Tabel 3.1: Mapping van TOS-waarden naar Access Categories

TOS AC

0x00 Best Effort

0x08 Background

0x28 Video

0xe0 Voice

pakketten gegenereerd door Rude ontvangt en op basis van data, meegegeven door Rude, een

aantal karakteristieken zoals vertraging, throughput en jitter in een statistiek giet.

Omdat Crude met een zeer lange commandline opgestart moet worden (men moet namelijk alle

IDs van de flows meegeven), werd een script ontwikkeld om het gebruiksgemak te verhogen. Dit

script, crudeScript, wordt meegegeven bij de documentatie van deze thesis. Verder werd gebruik

gemaakt van twee scripts uit [21] om de statistieken, gegenereerd door Crude, gemakkelijker te

kunnen verwerken en om snel configuratiescripts voor Rude te creeren. Beide scripts werden

aangepast aan de noden van deze thesis.

Belangrijk is dat men in het configuratiescript van Rude voor elke stroom het TOS-veld (Type

of Service) in de IP-header kan instellen. De bestaande implementaties van WME gebruiken

immers dit veld om aan te geven tot welke AC een pakket behoort. Er kunnen meerdere

hexadecimale waarden overeenkomen met een AC, maar in deze thesis werd slechts 1 mapping

gebruikt van TOS naar AC, die in tabel 3.1 wordt weergegeven. Er moet opgemerkt worden

dat Rude als root uitgevoerd moet worden, anders worden de TOS velden niet gezet. Tevens

moet Crude handmatig met ctrl+c beeindigd worden, wat het automatiseren van metingen

bemoeilijkt. Voor meer uitleg over Rude&Crude wordt verwezen naar de appendix.

Wireshark

Wireshark, het vroegere Ethereal [28], is een network protocol analyzer. Deze software maakt

het mogelijk om op een opgegeven netwerkinterface alle pakketten op te vangen. Deze kunnen

dan gefilterd en geanalyseerd worden. Dit programma werd op de laptop geınstalleerd om

bijvoorbeeld na te gaan of pakketten verzonden door Rude&Crude wel degelijk tot een bepaalde

AC behoren en of de mapping van TOS naar een bepaalde AC correct is. Net zoals Rude moet

Wireshark als root uitgevoerd worden.


Figuur 3.2: Het testnetwerk dat in deze thesis gebruikt wordt om metingen uit te voeren.

3.1.3 Netwerk

Met ’veiligheid’ in het achterhoofd is er gekozen om van het testnetwerk een afzonderlijk netwerk

te maken, zoals aangegeven in figuur 3.2. Slechts 1 desktop PC had toegang tot het internet, met

een interface die geen deel uitmaakt van het testnetwerk. Verder werd op het AP MAC-filtering

ingeschakeld.

Alle kaarten staan geconfigureerd als 802.11g, waarop WME al dan niet is ingeschakeld. De

twee desktop PC’s genereren trafiek met Rude&Crude, dat steeds via het AP gaat. Om met

Wireshark pakketten te kunnen opvangen en analyseren is de laptop ingesteld als monitor. Alle

machines kregen een vast IP-adres toegekend, dit om de metingen gemakkelijker te kunnen

automatiseren.

Ten slotte werd op het AP telkens een vast kanaal gekozen om over te zenden (namelijk kanaal

10). Dit om interferentie met andere draadloze netwerken te verminderen. Verder heeft het 3Com

AP de vervelende eigenschap om van kanaal te veranderen telkens een parameter veranderd

wordt, waardoor de connectie met de STAs verloren kan gaan. Dit probleem werd dus opgelost

door een vast kanaal in te stellen.

3.2 Testscenario’s 23

NTP

In het netwerk werd van NTP (Network Time Protocol, [25]) gebruik gemaakt. Dit protocol

zorgt voor de synchronisatie van de systeemklokken van computers in een netwerk. Compu-

terklokken zijn namelijk niet perfect, waardoor ze na een tijdje gaan driften ten opzichte van

een perfecte klok. Elke klok doet dit met een verschillende snelheid, zodat computerklokken

steeds meer van elkaar gaan verschillen. Dit heeft een zeer nefast effect op de meetresultaten:

de verkregen waarden voor delay zijn geheel onbetrouwbaar. De delay kan bijvoorbeeld waarden

aannemen van meer dan enkele seconden, wat onwaarschijnlijk lijkt voor een testnetwerk op deze

schaal. Verder kunnen er ook negatieve waarden optreden voor de delay, veroorzaakt door slecht

gesynchroniseerde klokken. Dit is fysisch onmogelijk.

Omdat er geen internetverbinding aanwezig is in het testnetwerk, werd geopteerd om een NTP-

server op te nemen in het netwerk. Deze server draait op een desktop PC, die zijn eigen sys-

teemklok als referentie neemt. De andere desktop PC synchroniseert telkens bij het begin van

een meting met een expliciete query naar de server. Deze query werd opgenomen in crude-

Script. Deze oplossing heeft twee voordelen: ten eerste minimaliseert men de NTP-overhead en

wordt er geen NTP-verkeer tijdens de meting verstuurd. Ten tweede zijn de klokken steeds juist

gesynchroniseerd aan het begin van een meting.

3.2 Testscenario’s

Voor deze thesis werden 4 testscenario’s uitgedacht en getest. Hierbij werd rekening gehouden

met de relevantie van de scenario’s, met andere woorden: zijn ze interessant genoeg om conclusies

uit te trekken en komen ze overeen met een situatie die in een thuisnetwerk kan voorkomen?

3.2.1 Scenario 1

Dit scenario is vooral interessant om de effecten veroorzaakt door het wijzigen van parameters

waar te nemen. Hier wordt nagebootst dat om de 10 seconden een nieuw filmpje geopend wordt,

terwijl de al aanwezige filmpjes verder blijven spelen. Elk filmpje wordt verstuurd tegen een

datarate van 3 Mbit/s. Tegen deze snelheid is de kwaliteit immers ruimschoots voldoende. Op

de achtergrond loopt een constante stroom van best effort-verkeer, tegen een rate van 10 Mbit/s.

Zo kunnen we makkelijk nagaan welke parameters geschikt zijn om zoveel mogelijk filmpjes on-

3.2 Testscenario’s 24

geschonden door het draadloos netwerk te sturen.

Na een tijdje is het netwerk verzadigd en worden de metingen, vanwege de onvoorspelbaarheid,

minder interessant. In verdere beschouwingen zullen we dan ook vooral rekening houden met

de meetresultaten voor het tijdstip van verzadiging. Deze opmerking geldt trouwens voor alle

volgende scenario’s.

3.2.2 Scenario 2

In dit scenario wordt een situatie nagebootst die in een thuisnetwerk het meeste zal voorko-

men. Er wordt een filmpje gedownload (of men kijkt naar digitale televisie). Tegelijkertijd is er

BE-verkeer dat in de tegenovergestelde richting loopt, waarvan de rate incrementeel verhoogd

wordt. Het filmpje is weer constant 3 Mbit/s, terwijl het BE-verkeer om de 5 seconden met 0,8

Mbit/s vermeerderd wordt, startend vanaf 0 Mbit/s.

Hier verwachten we dat de throughput meestal ongeveer hetzelfde zal blijven, namelijk schom-

melend rond het gemiddelde van 3 Mbit/s. In dit scenario zullen we dus vooral naar delay en

jitter moeten kijken om na te gaan of er verbetering is opgetreden in de kwaliteit van het door-

gestuurde filmpje. Deze laatste twee parameters kunnen immers een grote invloed uitoefenen

op de subjectieve waarneming van de kwaliteit van een filmpje, zeker in real-time applicaties.

Delay is de vertraging dat een pakket ondervindt, vanaf het moment dat deze verstuurd wordt

tot het moment dat deze aankomt. Een belangrijke factor in delay is de queuedelay, met name

de vertraging dat een pakket ondervindt omdat deze in een bepaalde buffer gestockeerd wordt

alvorens verzonden te worden. Jitter is de variatie in de tijd tussen de aankomst van 2 pakketten.

Er kunnen verschillende oorzaken zijn, zoals netwerkcongestie, herroutering of het driften van

klokken [11]. Een oplossing voor dit probleem is het gebruik van een geschikte buffer.

3.2.3 Scenario 3

Dit scenario breidt scenario 2 uit: men voegt een filmpje toe, dat hetzelfde pad volgt als het BE-

verkeer. We hebben dus twee filmjes, elk 3 Mbit/s, die in tegenovergestelde richting afgespeeld

worden. Het BE-verkeer blijft dezelfde karakteristieken behouden.

Ook hier wordt verwacht dat throughput geen bepalende rol zal spelen, maar dat we weer delay

en jitter zullen moeten vergelijken om tot conclusies te komen.

3.3 Meetmethode 25

3.2.4 Scenario 4

Tenslotte hebben we als laatste scenario weer een uitbreiding van scenario 2: nu voegt men een

voice stream toe, dat hetzelfde pad volgt als het filmpje. Dit komt overeen met een situatie

waarin iemand die een film bekijkt, opgebeld wordt met VoIP. Dit telefoongesprek, tegen een

datarate van 64 kbps, vindt plaats middenin het filmpje, zodat overgangsverschijnselen tussen

scenario 2 en scenario 4 waargenomen kunnen worden.

Weer zullen we naar delay en jitter moeten kijken om onze conclusies te trekken, maar nu zullen

we ook rekening moeten houden met de karakteristieken van de voice stream. Het zou immers

kunnen dat de keuze van bepaalde parameters nadelige gevolgen heeft voor de voice stream.

Er kan dus een trade-off ontstaan tussen gunstige gevolgen voor de video stream en nadelige

gevolgen voor het telefoongesprek.

3.3 Meetmethode

Elk scenario wordt op dezelfde manier aangepakt: allereerst is er een meting met de default

parameters, die beschreven staan in tabel 3.2, zowel voor het AP als voor het STA. Indien er

een verschillende waarde optreedt, dan staat de eerste voor het AP en het tweede voor het STA.

De waarden voor TXOP zijn niet opgenomen in de tabel, aangezien deze niet aangepast worden

in deze thesis.

Tabel 3.2: Default waarden van WME voor AP en STA

AC Type Min. CW Max. CW AIFS

(2x, x van 0-10) (2x, x van 0-10) (0-15)

AC BE 4 6/10 3

AC BK 4 10 7

AC VI 3 4 1/2

AC VO 2 3 1/2

Daarna vinden 4 metingen plaats, waar we de parameters AIFS en het contention window van

Video of Best Effort aanpassen. Laten we voor de duidelijkheid kort herhalen waar de para-

meters CWmin, CWmax en AIFS voor staan: wanneer een backoff entiteit (elk toestel heeft er

4, waarvan elk een overeenstemt met een AC) een backoff uitvoert, wacht deze eerst een vast

aantal slottijden. Dit aantal wordt bepaald door het AIFS en is afhankelijk van de AC. Dan kiest

3.3 Meetmethode 26

deze entiteit een random waarde, die in een interval ligt bepaald door de parameters CWmin en

CWmax. Ten slotte wacht de entiteit het aantal slottijden bepaald door de gekozen waarden.

Zie 2.2.1 voor meer uitleg.

Ten eerste verkleinen we het contention window van AC Video in deze volgorde: (2,4) → (2,3)

→ (1,3) → (1,2), waarbij het eerste cijfer CWmin voorstelt en het tweede cijfer CWmax. Bij

het tweede koppel valt de AC van Video samen met deze van Voice.

Dan vergroten we het contention window van AC BE als volgt: (4,10) → (5,10) → (6,10). Dit

doen we uiteraard nadat we de parameters van Video terug op de default waarden gezet hebben.

We laten het CWmin van BE slechts tot 6 stijgen, omdat we het BE-verkeer niet al te nadelig

willen beınvloeden. Er moet immers nog altijd BE-verkeer mogelijk zijn.

Vervolgens zetten we het AIFS van AC Video op 1 (zowel in het AP als in de STAs) en laten we

het AIFS van AC BE stijgen, van 3 tot en met 7. Bij deze laatste waarde valt de AC van BE

samen met deze van BK. Ten slotte herhalen we de derde meting, maar met het AIFS van AC

Video in het AP op 1 en in de STAs op 2. Het aanpassen van deze parameters gebeurt voor het

AP via de browser, voor de STAs via de consule met het commando iwpriv. Meer informatie

hierover in appendix B.

Voor elke parameter worden de verschillende instellingen met elkaar vergeleken op basis van

throughput, delay of jitter of een combinatie van voorgaande, om zo de optimale waarde voor

elke parameter te bepalen. Deze karakteristieken hebben een grote invloed op de kwaliteit van

video. Gezien de aard van videostromen kan pakketverlies een belangrijke factor zijn. Omdat

videopakketten met UDP verstuurd worden, zijn er geen retransmissies. Het kan dus dramatisch

zijn als het pakketverlies een bepaalde drempel overschrijdt. Pakketverlies wordt nochtans in

deze thesis meestal niet in beschouwing genomen, zoals uitgelegd in 4.2.1 en 4.3. Een tweede

belangrijke factor voor video is throughput dat gegarandeerd moet kunnen worden om tot aan-

vaardbare kwaliteit te komen. Vervolgens hebben we delay en jitter die deels opgevangen kunnen

worden als men de juiste buffers heeft, maar toch aan belang winnen bij real-timetoepassingen

[10].

Welke karakteristieken we gaan gebruiken om te vergelijken hangt dus af van het specifieke sce-

nario of situatie. In scenario 4 zal bijvoorbeeld nooit rekening worden gehouden met throughput,

3.3 Meetmethode 27

aangezien deze voor Video en Voice nagenoeg constant is. In bepaalde situaties kan men een

gegronde beslissing nemen door alleen naar delay te kijken, terwijl in andere situaties men ook

naar jitter zal moeten kijken.

Vervolgens worden alle optimale waarden met elkaar vergeleken om te verifieren welke waarde het

meeste effect heeft op de trafiekkarakteristieken. Dan worden alle optimale waarden met elkaar

gecombineerd. Zo kunnen we nagaan of een bepaalde combinatie toch geen betere resultaten

haalt dan de eerder gevonden optimale waarden.

RESULTATEN 28

Hoofdstuk 4

Resultaten

4.1 Inleidende meting

Allereerst werd voor beide APs een inleidende meting gehouden. Deze test houdt het volgende

in. Men genereert met Rude&Crude een datastroom met een pakketgrootte van 1000 bytes,

startend met een debiet van nul pakketten per seconde. Vervolgens wordt dit debiet telkens

na een bepaald tijdsinterval met een constante factor verhoogd. Als men het debiet dus zou

uitzetten op een grafiek, bekomt men een lineaire functie, evenredig met de tijd. Deze meting

voert men uit voor elke klasse, met de default parameters van WME en voor de situatie waar

geen QoS aanwezig is.

Deze meting had enkele doelen:

• Nagaan wat de maximale throughput is die men in de testopstelling kan bereiken.

• Verifieren welke impact WME heeft op datastromen.

• Vertrouwd geraken met de werkwijze om metingen uit te voeren.

• Controleren met Wireshark of het instellen van het TOS-veld met Rude&Crude het ge-

wenste effect bereikt.

• Controleren met Wireshark of de pakket rate gegenereert door Rude effectief gehaald

wordt.

Links op figuur 4.1 is de grafiek die men bekomt op het 3Com AP. De blauwe lijn is de theoretische

throughput, die men bekomt bij oneindige capaciteit. Wanneer er weinig verkeer is in het

4.1 Inleidende meting 29

netwerk, zullen de curves van de klassen dicht bij dit theoretisch maximum aanleunen of zelfs

samenvallen. Echter, door de toenemende load op het netwerk zullen de datastromen in de

praktijk een plafond bereiken.

Dit is duidelijk te zien in figuur 4.1. Zoals verwacht ligt deze van BK het laagst, gevolgd door

BE. Vervolgens hebben we de curve die de situatie voorstelt wanneer er geen QoS aanwezig is.

Hier bekomt men dus een hogere throughput dan de klassen met lage prioriteit wanneer QoS

wel is ingeschakeld. Uiteindelijk hebben we de curves van Video en Voice, die een gelijkaardi-

ge throughput behalen. Er moet wel opgemerkt worden dat de default parameters van Voice

afgestemd zijn op andere trafiekkarakteristieken. In de realiteit heeft men bij Voice namelijk

pakketten van beperkte omvang (120 bytes), tegen een veel lagere datarate (ongeveer 64 kbps),

terwijl men hier met grote pakketten werkt tegen een veel hogere snelheid.

Figuur 4.1: Het resultaat van de inleidende meting qua throughput. Links het 3Com AP, rechts het

Gigabyte AP.

Bij het Gigabyte AP bekomen we een gelijkaardige figuur (zie rechts op figuur 4.1). Hier lig-

gen de curves echter veel dichter op elkaar en men behaalt lagere snelheden dan bij het 3Com

AP. Ter vergelijking: bij het 3Com AP ligt de maximum snelheid rond de 14 Mbit/s, bij het

Gigabyte AP slechts 11 Mbit/s (beide hebben dezelfde theoretische capaciteit). Opmerkelijk is

dat bij het Gigabyte AP de hoogste snelheden gehaald worden in de situatie zonder QoS. Dit in

tegenstelling met het 3Com AP, waar dit zoals verwacht Voice is. Verder daalt deze curve ook,

terwijl men kan verwachten dat deze ongeveer een constante blijft aanhouden.


Figuur 4.2 geeft de grafieken weer wanneer we de gemiddelde vertraging uitzetten in de tijd.

De typische vorm van een stapfunctie wordt veroorzaakt door de queuedelay in het AP. Men

ondervindt immers in het begin nauwelijks vertraging. Wanneer echter de datarate opgedreven

wordt, zullen de queues in het AP vollopen, waardoor de queuedelay significant wordt. Dit

verklaart de plotse stijgingen in de curves.

Beide grafieken zijn zeer gelijkaardig. Zo hebben bijvoorbeeld de ACs BK en BE de grootste

vertraging in elk AP. Toch kunnen we tussen beide grafieken enkele verschilpunten opmerken:

• In het Gigabyte AP bereiken alle ACs (uitgezonderd ’zonder QoS’, dat geen plateau be-

reikt) op ongeveer hetzelfde moment een volle queue. Bij het 3Com AP zit tussen de

klassen wat meer verschil.

• In het Gigabyte AP heeft Video gemiddeld gezien de kleinste vertraging, terwijl dit bij het

3Com AP Voice is. In theorie zou dit steeds Voice moeten zijn.

• Bij het 3Com AP heeft Video aanvankelijk een lagere delay dan de situatie zonder QoS,

wat gewenst is. Na een tijdje is dit echter niet meer zo. Bij het Gigabyte AP bemerken

we net het tegenovergestelde.

• Gemiddeld gezien heeft het 3Com AP een kleinere delay dan het Gigabyte AP.

Figuur 4.2: Het resultaat van de inleidende meting qua delay. Links het 3Com AP, rechts het Gigabyte

AP.


Vervolgens geeft figuur 4.3 het pakketverlies weer. Er kan een verband getrokken worden tussen

deze grafieken en de grafieken van throughput en delay. Het pakketverlies begint namelijk sterk

te stijgen wanneer de queue vol zit (een volle queue laat immers de nieuwe pakketten vallen). Zo-

als eerder gezegd, stijgt de delay dan naar de queuedelay en bereikt de throughput zijn ’plafond’.

Figuur 4.3: Het resultaat van de inleidende meting qua pakketverlies. Links het 3Com AP, rechts het

Gigabyte AP.

Figuur 4.4: Het resultaat van de inleidende meting qua jitter. Links het 3Com AP, rechts het Gigabyte

AP.

Ten slotte hebben we in figuur 4.4 de grafieken van de absolute maximale jitter. Uit deze

4.2 Scenario 1 32

grafieken kunnen nauwelijks conclusies getrokken worden, maar worden voor de volledigheid

toch weergegeven. We merken op dat de waarden behaald door de maximale jitter vrij laag zijn.

4.2 Scenario 1

Voor informatie over de configuratie van dit scenario wordt verwezen naar 3.2.1. De grafieken

in dit scenario lopen slechts tot op het moment dat er 75 seconden verstreken zijn - de werke-

lijke meting duurt 100 seconden - omdat op dit tijdstip het netwerk al enige tijd het punt van

verzadiging bereikt heeft en de meetresultaten dus minder betrouwbaar worden. De datarate

die gegenereert wordt door Rude staat weergegeven in figuur 4.5.

Wegens het grote aantal figuren worden deze slechts op het einde van het scenario weergegeven,

om zo de overzichtelijkheid te bewaren. Dit geldt ook voor alle volgende scenario’s. Alle grafieken

geven de karakteristieken van Video weer (throughput, delay of jitter), nooit voor Best Effort.

4.2.1 Aanpassen CW Video

De eerste parameter die aangepast wordt, is het contention window van de klasse Video. In

figuur 4.6 staan de resultaten weergegeven voor de bereikte throughput. Op 40 seconden kun-

nen we voor beide APs goed het resultaat zien van de verschillende waarden van de parameter:

er treedt differentiatie op tussen de verschillende stromen. Hierdoor kunnen we gemakkelijk

bepalen welke waarden optimaler zijn dan andere. De trapvorm is trouwens duidelijk zichtbaar

in de grafieken.

Het is opmerkelijk dat het 3Com AP een veel hogere throughput haalt dan het Gigabyte AP,

namelijk een verschil van ± 5 Mbit/s. Hiervoor levert het 3Com AP wel in aan delay, zoals

te zien in figuur 4.7. Dit AP haalt immers waarden tot boven de 100 ms, terwijl voor real-

time applicaties een maximum van ongeveer 125 - 250 ms verwacht wordt [10]. De delay ligt

dus nog binnen aanvaardbare grenzen, maar dit is enkel de delay veroorzaakt in de draadloze

thuisomgeving. In de realiteit moet ook nog de delay veroorzaakt tussen het thuisnetwerk en de

desbetreffende server meegerekend worden .

Bij het 3Com AP is de differentiatie duidelijk merkbaar vanaf 50 seconden, bij het Gigabyte AP

reeds vanaf 30 seconden, maar hier blijft de delay wel beneden de 60 ms.

4.2 Scenario 1 33

In tegenstelling tot wat men kan verwachten, krijgt men niet steeds lagere waarden voor de-

lay wanneer men het contention window verkleint. Neem als voorbeeld het Gigabyte AP: daar

hebben de twee kleinste waardensets (CWmin: 1, CWmax: 2 en CWmin: 1, CWmax: 3)

een hogere delay dan de default waarden. Dit verschijnsel kan men verklaren doordat er meer

collissions optreden wanneer men een kleiner contention window heeft. Men heeft dan immers

minder random waarden om uit te kiezen, waardoor vaker dezelfde back-off bekomen zal worden.

Uit de figuren van jitter kan men geen conclusies halen, dus worden deze hier niet opgenomen.

Indien gewenst, kunnen deze wel bekeken worden in het desbetreffende MS Excel-bestand op de

bijgevoegde CD-ROM. Er zijn voor dit scenario ook figuren gemaakt op basis van pakketverlies.

Aangezien deze geen extra informatie aanbrengen die beslissingen zouden kunnen beınvloeden

zijn ze niet opgenomen in het boek, maar wel in het MS Excel-bestand.

Als men figuur 4.6 en figuur 4.7 met elkaar vergelijkt, kunnen we concluderen dat voor het 3Com

AP de waardeset {CWmin:2, CWmax:3} en voor het Gigabyte AP de waardeset {CWmin:2,

CWmax:4} het beste resultaat oplevert.

4.2.2 Aanpassen CW BE

De volgende parameter is het contention window van de klasse Best Effort. Figuur 4.8 geeft de

resultaten weer voor throughput, figuur 4.9 voor delay.

Voor throughput behaalt het 3Com AP weer betere resultaten, maar haalt wel hogere waarden

voor delay. Opvallend is dat voor delay de grafieken sterk verschillen tussen de twee APs. Het

Gigabyte AP heeft een delay die eerst ongeveer constant blijft, dan een grote stap naar boven

neemt en dan weer ongeveer constant blijft. Een soort stapfunctie als het ware. Het 3Com AP

daarentegen heeft een grafiek waar de delay geleidelijk aan in trapvorm stijgt. Dit komst steeds

voor in alle figuren voor delay in dit scenario.

Net zoals bij de vorige parameter is er steeds weer een tijdstip waar de differentiatie tussen

de verschillende stromen zichtbaar wordt. Voor het Gigabyte AP is deze differentiatie wel

duidelijker dan bij het 3Com AP.

Na vergelijking tussen figuur 4.8 en figuur 4.9 stellen we vast dat voor het 3Com AP de waardeset

4.2 Scenario 1 34

{CWmin:5, CWmax:10} en voor het Gigabyte AP de waardeset {CWmin: 6, CWmax: 10} het

meest optimaal is. De grafieken van jitter bevestigen alleen maar deze beslissing en zijn dus

niet opgenomen. Voor het verdere verloop van deze thesis nemen we de conventie aan dat als

een grafiek niet opgenomen is, ze niet doorweegt op de beslissing welke waarde optimaal is, of

dat ze juist deze beslissing bevestigt. Ten slotte nog een kleine opmerking: het 3Com AP haalt

hogere waarden voor de maximale jitter dan het Gigabyte AP, in elke situatie in dit scenario.

4.2.3 Aanpassen AIFS BE (video: AIFS = 1)

Vervolgens passen we het AIFS van Best Effort aan, terwijl deze parameter voor Video op 1

staat, zowel voor STA als AP. De resultaten staan weergegeven in figuur 4.10 en figuur 4.11,

respectievelijk voor throughput en delay.

Volgende trend kan men in elke figuur van throughput waarnemen: na verzadiging bij het 3Com

AP zakt de throughput, terwijl deze bij het Gigabyte AP ongeveer constant blijft. Een opmer-

kelijk fenomeen is dat bij het 3Com AP de waarde AIFS BE = 6 slechtere resultaten oplevert

dan de default waarde, terwijl men toch wel zou verwachten dat deze juist beter zou scoren. De

praktijk komt blijkbaar niet altijd overeen met de theorie.

Voor het aanpassen van de parameter AIFS van BE (video: 1), vinden we volgende waardeset

als optimaal: {AIFS BE = 7, video = 1}, voor beide APs.

4.2.4 Aanpassen AIFS BE

Ten slotte passen we opnieuw het AIFS van BE aan, maar nu heeft het AIFS van Video de de-

faultwaarden, namelijk 1 voor AP en 2 voor STA. Figuur 4.12 en figuur 4.13 geven de resultaten

weer voor throughput en delay.

Het 3Com AP is minder voorspelbaar dan het Gigabyte AP. Zo zakt de delay niet volgens

toenemende AIFS, de delay voor (AIFS BE = 5) ligt bijvoorbeeld hoger dan die van (AIFS BE

= 4). Bij het Gigabyte AP is deze voorspelbaarheid wel aanwezig. De meest optimale waarde

is (AIFS BE = 6) voor het 3Com AP, terwijl deze voor het Gigabyte AP de waarde (AIFS BE

= 7) bedraagt, zoals verwacht.

4.2 Scenario 1 35

4.2.5 Vergelijken van de optimale waarden

Tabel 4.1 geeft een overzicht van de optimale waarde per parameter, voor dit scenario.

Tabel 4.1: Overzicht van de optimale waarde per parameter, scenario 1.

Parameter Optimale waarde

3Com Gigabyte

CW Video CWmin: 2, CWmax: 3 CWmin: 2, CWmax: 4

CW BE CWmin: 5, CWmax: 10 CWmin: 6, CWmax: 10

AIFS BE (video:1) 7 7

AIFS BE 6 7

Figuren 4.14 en 4.15 geven de stromen weer die geassocieerd zijn met de optimale waarden, om

deze makkelijker te kunnen vergelijken.

Uit deze figuren kunnen we afleiden dat voor het 3Com AP de waardeset {CWmin BE: 5,

CWmax BE:10} de meest optimale resultaten verkrijgt, voor het Gigabyte AP is dit de waarde

(AIFS BE = 7). Het is opmerkelijk dat bij het 3Com AP de delay vanaf een gegeven moment

voor alle waarden hoger wordt dan deze voor de defaultwaarden. Bij het Gigabyte AP is dit

niet het geval.

4.2.6 Combineren van de optimale waarden

Nu gaan we de optimale resultaten met elkaar gaan combineren. Vervolgens vergelijken we de

resultaten die we met deze combinaties bekomen hebben met de resultaten van de meest op-

timale waarde(set) uit 4.2.5. Zo kan er nagegaan worden dat het combineren van parameters

betere resultaten oplevert, of juist niet.

De resultaten voor het 3Com AP staan weergegeven in figuur 4.16. Hieruit kan duidelijk afgeleid

worden dat men met het combineren van de optimale waarden geen betere resultaten bekomt,

in tegenstelling tot wat men verwacht. De meest optimale parameter voor het 3Com AP, voor

scenario 1, is dus de waardeset {CWmin BE: 5, CWmax BE:10} .

Voor het Gigabyte AP staan de resultaten afgebeeld in figuur 4.17. We zien dat er bijna geen

verschil is tussen de waarde (AIFS BE = 7) uit 4.2.5 en de combinatie {CWmin BE:6, CWmax

4.2 Scenario 1 36

BE:10 ; AIFS BE = 7}. Daarom kijken we ook naar de grafiek voor jitter, om aldus te bepalen

welke waarden het beste zijn. Deze grafiek staat weergegeven in figuur 4.18. Hieruit leiden we af

dat de combinatie {CWmin BE:6, CWmax BE:10 ; AIFS BE = 7} het beste scoort, aangezien

hierbij de jitter het laagst is.

4.2.7 Figuren scenario 1

Figuur 4.5: De data rate gegeneert in scenario 1.

Figuur 4.6: Het resultaat van het aanpassen van het CW van video qua throughput. Links het 3Com

AP, rechts het Gigabyte AP.

4.2 Scenario 1 37

Figuur 4.7: Het resultaat van het aanpassen van het CW van video qua delay. Links het 3Com AP,

rechts het Gigabyte AP.

Figuur 4.8: Het resultaat van het aanpassen van het CW van BE qua throughput. Links het 3Com AP,


4.2 Scenario 1 38

Figuur 4.9: Het resultaat van het aanpassen van het CW van BE qua delay. Links het 3Com AP, rechts

het Gigabyte AP.

Figuur 4.10: Het resultaat van het aanpassen van het AIFS van BE (video:1) qua throughput. Links

het 3Com AP, rechts het Gigabyte AP.

4.2 Scenario 1 39

Figuur 4.11: Het resultaat van het aanpassen van het AIFS van BE (video:1) qua delay. Links het

3Com AP, rechts het Gigabyte AP.

Figuur 4.12: Het resultaat van het aanpassen van het AIFS van BE qua throughput. Links het 3Com

AP, rechts het Gigabyte AP.

4.2 Scenario 1 40

Figuur 4.13: Het resultaat van het aanpassen van het AIFS van BE qua delay. Links het 3Com AP,


Figuur 4.14: De optimale waarden gevonden voor scenario 1 voor het 3Com AP. Links de grafiek voor

throughput, rechts voor delay.

4.2 Scenario 1 41

Figuur 4.15: De optimale waarden gevonden voor scenario 1 voor het Gigabyte AP. Links de grafiek

voor throughput, rechts voor delay.

Figuur 4.16: Het combineren van optimale waarden van scenario 1 voor het 3Com AP. Links de grafiek

voor throughput, rechts voor delay.

4.2 Scenario 1 42

Figuur 4.17: Het combineren van optimale waarden van scenario 1 voor het Gigabyte AP. Links de

grafiek voor throughput, rechts voor delay.

Figuur 4.18: Het combineren van de optimale waarden uit scenario 1 qua jitter, voor het Gigabyte AP.

4.3 Scenario 2 43

4.3 Scenario 2

Voor informatie over de configuratie van dit scenario wordt verwezen naar 3.2.2. De grafieken

van throughput zijn van minimaal belang in dit scenario en worden dus niet weergegeven. Bij

de klasse Video komt pakketverlies in dit scenario slechts in zeer beperkte mate voor en wordt

dus niet in beschouwing genomen. Dit geldt ook voor scenario 3 en 4. De grafieken worden, net

zoals in scenario 1, slechts weergegeven tot het tijdstip dat er 75 seconden verstreken zijn, om

dezelfde redenen. De data rate, gegenereerd door Rude, staat voor dit scenario weergegeven in

figuur 4.19.


Figuur 4.20 bevat de resultaten voor het aanpassen van de parameter (CW Video). Bij het

3Com AP heeft de aanpassing van deze parameter meestal slechtere resultaten tot gevolg. Enkel

de waardeset {CWmin: 2, CWmax: 4} scoort beter dan de defaultwaarden.

Voor het Gigabyte AP liggen de zaken anders. Uit de grafiek voor delay kunnen we afleiden

dat de resultaten voor de waardeset {CWmin: 2, CWmax: 3} en {CWmin: 1, CWmax: 2} zeer

dicht bij elkaar liggen. Uit figuur 4.21, waar de resultaten voor jitter zijn afgebeeld, zien we dat

de resultaten voor deze waardesets weer dicht bij elkaar liggen, maar dat de waardeset {CWmin:

1, CWmax: 2} de laagste jitter heeft.


Het Gigabyte AP, waarvoor de resultaten voorspelbaar zijn, heeft de waardeset {CWmin: 6,

CWmax: 10} als het meest optimale, zoals te zien is in figuur 4.22.

Voor het 3Com AP halen we er ook de resultaten voor jitter bij, zoals te zien is in figuur 4.23. De

waardeset {CWmin: 5, CWmax: 10} haalt in het algemeen een lichtjes beter resultaat dan de

default waarden. Dit AP heeft, in tegenstelling tot het Gigabyte AP, onvoorspelbare resultaten,

die overigens vrij grillige figuren opleveren.


Figuur 4.24 geeft de resultaten weer voor delay, figuur 4.25 voor jitter. Beide APs hebben

resultaten die niet echt voldoen aan de verwachtingen. Men kan immers verwachten dat als men

4.3 Scenario 2 44

het Best Effort-verkeer systematisch langer laat wachten vooraleer dit verkeer over het kanaal

verzonden mag worden, dat de delay voor Video daalt naarmate het AIFS van BE hoger wordt.

In praktijk liggen de curves echter dicht bij elkaar en niet in de verwachte volgorde. Daarom

moet er ook naar jitter gekeken worden en komen we tot volgende optimale waardensets: {AIFS

BE = 6, video = 1} voor het 3Com AP en {AIFS BE = 5, video = 1} voor het Gigabyte AP.


Ten slotte passen we de parameter (AIFS BE) aan, met default waarden voor Video, waarvan

de resultaten te zien zijn in figuur 4.26. Met behulp van deze figuur vinden we dat de meest

optimale waarde (AIFS BE = 7) is voor het 3Com AP en (AIFS BE = 5) voor het Gigabyte

AP. De resultaten voor beide APs is weeral wat men niet zou verwachten. In theorie zou het

immers altijd de waarde (AIFS BE = 7) zijn.





3Com Gigabyte




AIFS BE 7 5

Figuren 4.27 en 4.28 geven een visualisatie van deze tabel, respectievelijk voor het 3Com AP

en het Gigabyte AP. Hieruit kunnen we afleiden dat de meeste optimale waarde voor het 3Com

AP (AIFS BE = 7) is en (AIFS BE = 5) voor het Gigabyte AP.

In tegenstelling tot scenario 1, komen beide APs nu vergelijkbare waarden uit voor delay en

jitter. Dit maakt het gemakkelijker om de APs later met elkaar te kunnen vergelijken. Deze

conclusie geldt ook voor scenario 3 en 4.

4.3 Scenario 2 45


Na combineren van de verschillende optimale waarden bekomen we voor het 3Com AP fi-

guur 4.29. Hieruit blijkt dat het combineren van waarden voor het 3Com AP weer geen be-

tere resultaten geeft, althans voor delay. Indien delay geminimaliseerd moet worden, dan is

(AIFS BE = 7) , de meest optimale waarde, zoals ook bevonden in 4.3.5. Indien echter de laag-

ste jitter dient gevonden te worden, dan is de waardeset {BE: Cwmin:5, Cwmax:10, AIFS=7}

het meest optimaal. In deze thesis beschouwen we het minimaliseren van delay als belangrijker.

Voor het Gigabyte AP verkrijgen we figuur 4.30, waaruit blijkt dat de delay geminimaliseerd

wordt voor de waardeset {Video: Cwmin:1, Cwmax:2; BE: AIFS=5} . Indien jitter belangrijker

zou zijn, dan kiest men beter voor de waardeset {Video: Cwmin:1, Cwmax:2; BE: Cwmin:6,

Cwmax:10}.



4.3 Scenario 2 46

Figuur 4.20: Het resultaat van het aanpassen van het CW van video qua delay. Links het 3Com AP,


Figuur 4.21: Het resultaat van het aanpassen van het CW van video qua jitter, voor het Gigabyte AP.

4.3 Scenario 2 47

Figuur 4.22: Het resultaat van het aanpassen van het CW van BE qua delay. Links het 3Com AP,


Figuur 4.23: Het resultaat van het aanpassen van het CW van BE qua jitter, voor het 3Com AP.

4.3 Scenario 2 48

Figuur 4.24: Het resultaat van het aanpassen van het AIFS van BE (video:1) qua delay. Links het


Figuur 4.25: Het resultaat van het aanpassen van het AIFS van BE (video:1) qua jitter. Links het


4.3 Scenario 2 49

Figuur 4.26: Het resultaat van het aanpassen van het AIFS van BE qua delay. Links het 3Com AP,


Figuur 4.27: De optimale waarden gevonden voor scenario 2 voor het 3Com AP. Links de grafiek voor

delay, rechts voor jitter.

4.3 Scenario 2 50

Figuur 4.28: De optimale waarden gevonden voor scenario 2 voor het Gigabyte AP. Links de grafiek

voor delay, rechts voor jitter.

Figuur 4.29: Het combineren van optimale waarden van scenario 2 voor het 3Com AP. Links de grafiek

voor delay, rechts voor jitter.

4.3 Scenario 2 51

Figuur 4.30: Het combineren van optimale waarden van scenario 2 voor het Gigabyte AP. Links de

grafiek voor delay, rechts voor jitter.

4.4 Scenario 3 52

4.4 Scenario 3

Voor informatie over de configuratie van dit scenario wordt verwezen naar 3.2.3. In de figu-

ren wordt met str1 verwezen naar stroom 1, de datastroom vertrekkend van het STA met IP

192.168.200.1 naar het STA met IP 192.168.200.3 (zie figuur 3.2 voor meer verduidelijking).

Met str2 wordt stroom 2 bedoeld, de datastroom in de omgekeerde richting. De figuren lopen

opnieuw maar tot 75 seconden, om dezelfde redenen die eerder zijn aangehaald. De data rate is

voor dit scenario weergegeven in figuur 4.31. In deze figuur valt natuurlijk de data rate voor de

twee videostromen tesamen.


Opvallend voor deze parameter in dit scenario is dat naarmate het contention window kleiner

wordt, de throughput zakt en dat delay en jitter enorm stijgen. Dit is vooral significant bij het

Gigabyte AP en in iets mindere mate bij het 3Com AP. Dit fenomeen, te zien in figuren 4.32,

4.33 en 4.34, is te verklaren dat door het kleine contention window er meer collissions zullen

optreden, vooral als er twee gelijkaardige stromen in tegengestelde richting zijn. Voor stroom 2

bekomen we gelijkaardige grafieken.

Het verschijnsel is zo sterk in het Gigabyte AP dat geen enkele nieuwe waardeset van de para-

meter betere resultaten afdwingt. De default waardeset is dus de meest optimale. Het 3Com AP

heeft daarentegen wel een optimale waardeset die verschilt van de defaultwaardeset, namelijk

{Cwmin: 2, Cwmax: 4}.


Het aanpassen van het contention window van BE gedraagt zich bij het 3Com AP al wat beter

voorspelbaar, zoals te zien in figuur 4.35. De waardeset {Cwmin: 5, Cwmax: 10} minimaliseert

de delay voor stroom 1, maar haalt slechtere resultaten bij stroom 2. Daarom wordt geopteerd

voor waardeset {Cwmin: 6, Cwmax: 10}, die voor beide stromen goede resultaten haalt.

Bij het Gigabyte AP hebben we hetzelfde scenario: waardeset {Cwmin: 5, Cwmax: 10} is beter

voor stroom 1, maar waardeset {Cwmin: 6, Cwmax: 10} is het best voor beide stromen (zie

figuur 4.36).

Beide APs gedragen zich in voor deze parameter vrij onvoorspelbaar. In theorie benadeelt de

4.4 Scenario 3 53

waardeset {Cwmin: 6, Cwmax: 10} het BE-verkeer in zo’n sterke mate, dat deze waardeset

steeds de beste resultaten zou moeten halen, in alle situaties. Ook in andere scenario’s komt het

voor dat de waardeset {Cwmin: 6, Cwmax: 10} niet het meest optimaal is.


In figuur 4.37 zien we de grafieken van het 3Com AP qua delay. Voor stroom 1 is de waarde

{AIFS BE = 5, video = 1} het meest optimaal, maar de waardeset {AIFS BE = 7, video = 1}

is voor beide stromen het meest optimaal.

Bij het Gigabyte AP bekomen we dat de waarde {AIFS BE = 5, video = 1} de beste resultaten

behaalt, zoals te zien is in figuur 4.38. Opmerkelijk is dat {AIFS BE = 7, video = 1} zulke

slechte resultaten haalt.


Figuur 4.39 geeft de grafieken weer van het 3Com AP, voor delay. Het is typerend voor dit

scenario dat een bepaalde waarde heel goed scoort voor de ene stroom, maar dan veel slechter

scoort voor de andere stroom. In dit geval is dat de waarde (AIFS BE = 7), die zeer goede

resultaten haalt voor stroom 1, maar slecht presteert bij stroom 2. We moeten dus steeds een

waarde zoeken die optimaal is voor beide stromen. Hier is dit de waarde (AIFS BE = 4).

Voor het Gigabyte AP bekomen we figuren 4.40 en 4.41, waaruit blijkt dat (AIFS BE = 7) de

meest optimale waarde is.





3Com Gigabyte

CW Video CWmin: 2, CWmax: 4 Default



AIFS BE 4 7

4.4 Scenario 3 54

De visualisatie van de tabel voor het 3Com AP is te zien in figuren 4.42 en 4.43. Hieruit kunnen

we besluiten dat de waardeset {AIFS BE = 7, video = 1} de meest optimale is voor scenario 3,

voor het 3Com AP. Voor het Gigabyte AP verkrijgen we figuur 4.44, waaruit we kunnen afleiden

dat de waardeset {Cwmin BE: 6, Cwmax BE: 10} de beste resultaten haalt ten opzichte van de

andere optimale waarden.


Het combineren van de optimale waarden levert bij het 3Com AP geen extra winst op, zoals weer-

gegeven in figuren 4.45 en 4.46. Dit wil zeggen dat de waardeset {AIFS BE = 7, video = 1} de

meest optimale is. Het combineren van optimale waarden geeft voor dit AP zeer grillige figuren.

Bij het Gigabyte AP krijgen we betere resultaten door het combineren van de optimale waarden:

de waardeset {BE: Cwmin: 6, Cwmax: 10, AIFS = 7} is globaal gezien het meest optimaal (zie

figuren 4.47 en 4.48). Bij dit AP zijn de grafieken voor het combineren van optimale waarden

veel vlakker.



4.4 Scenario 3 55

Figuur 4.32: Het resultaat van het aanpassen van het CW van video qua throughput, voor stroom 1.

Links het 3Com AP, rechts het Gigabyte AP.

Figuur 4.33: Het resultaat van het aanpassen van het CW van video qua delay, voor stroom 1. Links


4.4 Scenario 3 56

Figuur 4.34: Het resultaat van het aanpassen van het CW van video qua jitter, voor stroom 1. Links


Figuur 4.35: Het resultaat van het aanpassen van het CW van BE qua delay, voor het 3Com AP. Links

voor stroom 1, rechts voor stroom 2.

4.4 Scenario 3 57

Figuur 4.36: Het resultaat van het aanpassen van het CW van BE qua delay, voor het Gigabyte AP.

Links voor stroom 1, rechts voor stroom 2.

Figuur 4.37: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het 3Com

AP. Links voor stroom 1, rechts voor stroom 2.

4.4 Scenario 3 58

Figuur 4.38: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het Gigabyte


Figuur 4.39: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het 3Com


4.4 Scenario 3 59

Figuur 4.40: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het Gigabyte


Figuur 4.41: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua jitter, voor het Gigabyte


4.4 Scenario 3 60

Figuur 4.42: Het vergelijken van de optimale waarden qua delay, voor het 3com AP. Links voor stroom

1, rechts voor stroom 2.

Figuur 4.43: Het vergelijken van de optimale waarden qua jitter, voor het 3com AP. Links voor stroom


4.4 Scenario 3 61

Figuur 4.44: Het vergelijken van de optimale waarden qua delay, voor het Gigabyte AP. Links voor

stroom 1, rechts voor stroom 2.

Figuur 4.45: Het combineren van de optimale waarden qua delay, voor het 3com AP. Links voor stroom


4.4 Scenario 3 62

Figuur 4.46: Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links voor stroom


Figuur 4.47: Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links voor


4.4 Scenario 3 63

Figuur 4.48: Het combineren van de optimale waarden qua jitter, voor het Gigabyte AP. Links voor


4.5 Scenario 4 64

4.5 Scenario 4

Voor informatie over de configuratie van dit scenario wordt verwezen naar 3.2.4. In de titel van

de grafieken wordt met Video verwezen naar de video stream, terwijl er met Voice naar de voice

stream verwezen wordt, om zo de figuren duidelijk van elkaar te kunnen onderscheiden. Voor dit

scenario is er geen figuur waarin de data rate wordt weergegeven voorzien. De voice stream is

qua snelheid immers verwaarloosbaar ten opzichte van de video stream. Men bekomt dus figuur

4.19 uit scenario 2.


De resultaten die voortkomen uit het aanpassen van het contention window van Video staan

weergegeven in figuur 4.49 voor het 3Com AP en figuur 4.50 voor het Gigabyte AP. Bij eerstge-

noemde is de waardeset {Cwmin: 2, Cwmax: 3} het meest optimaal, omdat deze voor Video en

voor Voice de delay minimaliseert. Bij laatstgenoemde minimaliseert de waardeset {Cwmin: 1,

Cwmax: 3} de delay voor Video en zorgt deze voor geen noemenswaardige problemen bij Voice.

De grafieken van Video zijn meestal grilliger dan deze van Voice. Dit is te verklaren door de

verschillende trafiekeigenschappen van beide stromen.


Bij het aanpassen van het contention window van Best Effort verkrijgen we volgende figuren:

figuur 4.51 voor het 3Com AP en figuur 4.52 voor het Gigabyte AP. We krijgen respectievelijk

{Cwmin: 6, Cwmax: 10} en {Cwmin: 5, Cwmax: 10} als optimale waardesets.

4.5.3 Aanpassen AIFS BE (video: 1)

De grafieken voor het 3Com AP en het Gigabyte AP staan weergegeven in figuur 4.53 en figuur

4.54. De waardeset {AIFS BE = 6, Video = 1} geeft het beste resultaat voor het 3Com AP,

alhoewel de waardeset {AIFS BE = 7, Video = 1} ook optimaal lijkt te zijn. Deze waardeset

heeft echter slechtere resultaten voor de stroom Voice en voor jitter (zie grafieken op de CD-

ROM).

De waardeset {AIFS BE = 4, Video = 1} is het meest efficient voor het Gigabyte AP.

4.5 Scenario 4 65


Ten slotte passen we het AIFS BE, met de waarden van Video op default. Figuur 4.55 geeft de

resultaten weer voor het 3Com AP, figuur fig:sc4-AIFS-delay-giga voor het Gigabyte AP. Als

optimale waarde komen we (AIFS BE = 5) uit, voor beide APs.





3Com Gigabyte




AIFS BE 5 5

De visualisatie van tabel 4.4 is te zien in figuur 4.57 voor het 3Com AP en 4.58 voor het Gigabyte

AP. Uit deze figuren leiden we af dat voor het 3Com AP de waardeset {AIFS BE = 6, Video =

1} en voor het Gigabyte AP de waarde (AIFS BE = 5) het meest optimaal is.

Opmerkelijk is dat bij het Gigabyte AP de delay bij sommige grafieken sterk stijgt, terwijl de

delay bij het 3Com AP nagenoeg constant blijft.


Wanneer we de optimale resultaten uit 4.5.5 voor het 3Com AP combineren met elkaar, dan

krijgen we volgende resultaten: figuur 4.59 voor delay en figuur 4.60 voor jitter. Uit deze figuren

kunnen we afleiden dat de waardeset {VI: Cwmin: 2, Cwmax: 3; BE: Cwmin: 6, Cwmax: 10}

de meest optimale resultaten behaalt.

Voor het Gigabyte AP bekomen we figuur 4.61. Het is duidelijk dat (AIFS BE = 5) de meest

optimale waarde is voor scenario 4.

4.5 Scenario 4 66


Figuur 4.49: Het resultaat van het aanpassen van het CW van video voor het 3Com AP, qua delay.

Links voor Video, rechts voor Voice.

Figuur 4.50: Het resultaat van het aanpassen van het CW van video voor het Gigabyte AP, qua delay.


4.5 Scenario 4 67

Figuur 4.51: Het resultaat van het aanpassen van het CW van BE voor het 3Com AP, qua delay. Links

voor Video, rechts voor Voice.

Figuur 4.52: Het resultaat van het aanpassen van het CW van BE voor het Gigabyte AP, qua delay.


4.5 Scenario 4 68

Figuur 4.53: Het resultaat van het aanpassen van het AIFS BE (video: 1) voor het 3Com AP, qua

delay. Links voor Video, rechts voor Voice.

Figuur 4.54: Het resultaat van het aanpassen van het AIFS BE (video: 1) voor het Gigabyte AP, qua

delay. Links voor Video, rechts voor Voice.

4.5 Scenario 4 69

Figuur 4.55: Het resultaat van het aanpassen van het AIFS BE voor het 3Com AP, qua delay. Links


Figuur 4.56: Het resultaat van het aanpassen van het AIFS BE voor het Gigabyte AP, qua delay. Links


4.5 Scenario 4 70

Figuur 4.57: Het vergelijken van de optimale waarden qua delay, voor het 3com AP. Links voor Video,

rechts voor Voice.

Figuur 4.58: Het vergelijken van de optimale waarden qua delay, voor het Gigabyte AP. Links voor

Video, rechts voor Voice.

4.5 Scenario 4 71

Figuur 4.59: Het combineren van de optimale waarden qua delay, voor het 3com AP. Links voor Video,

rechts voor Voice.

Figuur 4.60: Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links voor Video,

rechts voor Voice.

4.5 Scenario 4 72

Figuur 4.61: Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links voor

Video, rechts voor Voice.

BESLUIT 73

Hoofdstuk 5

Besluit

5.1 Conclusies

Deze thesis tracht een optimalisatie te bekomen voor videodiensten in de specifieke situatie van

een draadloze thuisomgeving. Dit werd gerealiseerd door voor verschillende parameters een opti-

male waarde te gaan zoeken, waarmee throughput verbeterd kon worden en tegelijkertijd delay

en jitter geminimaliseerd kon worden. Deze optimale waarden werden vervolgens met elkaar

gecombineerd zodat we konden nagaan of een combinatie niet nog betere resultaten kon halen.

Vier scenario’s werden uitgewerkt die relevant waren voor onze thuisomgeving. Voor elk van

deze scenario’s werd een optimale waarde – of een combinatie van optimale waarden – gezocht,

waarvan in tabel 5.1 een overzicht wordt gegeven.

Tabel 5.1: Overzicht van de optimale waarden(sets) per scenario.

Scenario Optimale waarde(set)

3Com Gigabyte

1 CWmin BE=5, CWmax BE=10 CWmin BE=6, CWmax BE=10, AIFS BE=7

2 AIFS BE = 7 Cwmin VI=1, Cwmax VI=2, AIFS BE=5

3 AIFS BE=7, AIFS VI=1 BE: Cwmin=6, Cwmax=10, AIFS=7

4 VI: Cwmin=2, Cwmax=3 AIFS BE = 5

BE: Cwmin=6, Cwmax=10

5.1 Conclusies 74

Uit deze tabel kunnen verschillende conclusies getrokken worden. Ten eerste is de praktijk niet

altijd wat de theorie voorspelt. In theorie zouden altijd de waarden {CWmin VI:1, Cwmax VI:

2}, {CWmin BE:6, Cwmax BE: 10} en (AIFS BE=7) tot de meest optimale resultaten moeten

leiden. Met de combinatie van voorgaande waarden zou een nog beter resultaat moeten beko-

men worden. Echter, zoals te zien in tabel 5.1, was dit nooit het geval. De uiterste waarde

van een parameter leidde niet altijd tot de meest optimale resultaten en in sommige gevallen

verkregen we met het combineren van waarden slechtere resultaten dan in het geval van een

optimale waarde. De combinatie waarin alle optimale waarde gecombineerd werden, leidde zelfs

nooit tot een optimum.

Ten tweede werd aangetoond dat er wel degelijk een afhankelijkheid bestaat van het soort hard-

ware, aangezien voor elk AP andere optimale waarden bekomen werden voor de scenario’s. Het

was trouwens zelden dat beide APs dezelfde optimale waarde(set) hadden voor een parameter.

Er zijn ook enkele interessante verschillen gevonden tussen beide APs:

• Het 3Com AP haalt in scenario 1 een veel hogere throughput dan het Gigabyte AP, maar

levert wel in aan delay en jitter. Dit in tegenstelling met de inleidende metingen, waar het

3Com AP ook een hogere throughput haalde, maar waarbij de delay gemiddeld gezien wel

lager was dan die van het Gigabyte AP.

• Een ander verschijnsel dat in scenario 1 werd waargenomen, was dat de grafieken sterk

verschillen tussen beide APs. Het 3Com AP had voor delay een trapvormige grafiek,

terwijl het Gigabyte AP eerder een enkele stap had. Verder bleven bij het 3Com AP de

verschillende curves in een grafiek van throughput dicht bij elkaar. Bij het Gigabyte AP

trad er sneller sterke differentiatie op tussen de verschillende curves.

• In scenario 3 lijdt het Gigabyte AP sterk onder de wijzigingen van het contention window

van Video. Throughput zakt, terwijl delay en jitter omhoog schiet. Bij het 3Com AP is

dit veel minder het geval.

• De delay bij het Gigabyte AP stijgt meestal continu in scenario 4, terwijl deze bij het

3Com AP nagenoeg constant blijft.

Wanneer men de grafieken wat naderbij bekijkt, vooral voor scenario 2 tot 4, bemerkt men

dat delay slechts met enkele milliseconden zakt, soms zelfs maar met enkele tienden van een

5.2 Toekomstvisie 75

milliseconde. Men kan zich dan afvragen of dit wel de moeite waard is. Maar men moet zich

realiseren dat het thuisnetwerk slechts een klein stukje is van het pad dat video stream aflegt.

Men heeft immers ook nog het hele pad doorheen het bedrade netwerk naar de server toe,

waar de delay soms sterk kan oplopen. Het ’pingen’ naar een populaire site zoals YouTube

neemt bijvoorbeeld al 170ms in beslag. Verder moet men ook te allen kosten vermijden dat

het thuisnetwerk een soort van bottleneck gaat vormen. Elke milliseconde die men dus kan

afsnoepen, kan misschien gevolgen hebben voor de kwaliteit van een filmpje.

5.2 Toekomstvisie

Wat moet men nu aanvangen met al deze resultaten?

Men kan hiermee bijvoorbeeld een dynamisch access point construeren. In de logica van een AP

brengt men de optimale waarden in, gerangschikt per scenario. Dit AP moet dan de mogelijk-

heid hebben om te kunnen detecteren in welke situatie hij zich bevindt. Dan kan het AP zijn

parameterset updaten naar de gevonden situatie om zo beter te kunnen presteren. Tegelijkertijd

stuurt het AP de optimale waarden door met zijn beacon frames naar de STAs, die zich dan

aanpassen aan de situatie. Men verkrijgt dus een dynamisch draadloos netwerk, dat zijn QoS

aanpast naargelang de situatie die zich voordoet.

Een voorbeeld

In een draadloze thuisomgeving kijkt een gebruiker reeds een geruime tijd naar een film via digitale tele-

visie. Een andere gebruiker verstuurt op dat moment e-mails. We bevinden ons dus in scenario 2 en het

AP en de STAs hebben de optimale waarde(set) ingesteld die hoort bij dit scenario.

Plots gaat de telefoon, die met VoIP werkt. Het AP detecteert dit en stelt vast dat we ons nu in scenario

4 bevinden. Het AP past dus zijn parameterset aan en stuurt tegelijktijd met zijn beacon frames een

nieuwe parameterset door voor de STAs. De STAs ontvangen deze beacon frames en stellen hun para-

meterset bij. Na het telefoongesprek detecteert het AP dat het zich terug in scenario 2 bevindt en past

dus opnieuw zijn parameterset en beacon frames aan, waarna de STAs volgen.

Zo bekomt men dus voor elke situatie een optimaal resultaat, wat ten goede komt voor het gebruikersge-

mak bij draadloze netwerken.

5.3 Verder verloop 76

Iets minder spectaculair is dat men in de parameterset de defaultwaarden vervangt door een of

meerdere optimale waarden. Men bekomt dan een AP of STA dat gespecialiseert is in video-

diensten.

Ten slotte zou men deze resultaten ook kunnen gebruiken in de hogere lagen van de protocolstack.

Deze hogere lagen kunnen dan via TSPEC (zie A.2) hun voorkeuren meegeven aan het draadloze

netwerk.

5.3 Verder verloop

In deze thesis werd maar een beperkt aantal scenario’s getest. Men kan het onderzoek dus

uitbreiden naar meerdere scenario’s. Men zou ook andere situaties kunnen beschouwen dan de

draadloze thuisomgeving, bijvoorbeeld een draadloos netwerk in een bedrijf waar veel aan vi-

deoconferencing gedaan wordt. Aangezien bedrijven in de toekomst hoogstwaarschijnlijk gaan

overschakelen naar VoIP zal men dan ook meer rekening moeten houden met Voice.

Verder zou men nog meer parameters kunnen aanpassen, zoals het aan- of uitzetten van ACKs

en Admission Control en de TXOP-limiet. Hierdoor kan men ook meer combinaties van ver-

schillende optimale waarden testen, waardoor misschien nog betere resultaten bekomen kunnen

worden. Vervolgens zou men de metingen ook kunnen uitbreiden naar meerdere APs, gezien de

hardware-afhankelijkheid van de resultaten.

Ten slotte moet er werk gemaakt worden om de metingen meer reproduceerbaar en automati-

seerbaar te maken. Het neemt immers veel tijd in beslag om de metingen – zoals ze nu zijn – uit

te voeren en te verwerken. Misschien kan er om deze problemen te omzeilen uitgekeken worden

naar andere meettools.

In deze thesis werd er geen rekening gehouden met invloeden op het Best Effort verkeer, maar

deze kunnen gemakkelijk onderzocht worden omdat de meetresultaten van BE ook beschikbaar

zijn op de CD-ROM.

EXTRA INFORMATIE IEEE 802.11E 77

Bijlage A

Extra informatie IEEE 802.11e

A.1 Verbeterde efficientie

802.11e biedt meerdere mechanismen aan om de efficientie te verhogen, waarvan er hier kort

twee besproken worden.

Block Acknowledgement Dit laat een backoff entiteit toe om een aantal MSDUs opeenvol-

gend te verzenden gedurende een TXOP zonder individuele ACK frames. Aan het einde

van het blok, of in een latere TXOP, worden alle MSDUs bevestigd door een bitpatroon

in het block acknowledgement frame. Hierdoor wordt de overhead verminderd naar een

minimum van n ACK frame [7], [14].

Direct Link Protocol (DLP) Door dit protocol kan een backoff entiteit rechtstreeks met een

andere backoff entiteit in de QBSS communiceren zonder via de QAP te gaan. Hierdoor

valt de asymmetrie tussen uplink en downlink gedeeltelijk weg. Men noemt deze directe

communicatie in 802.11e de direct link (DiL) [7], [14].

A.2 Trafiek specificaties

TSPEC is het trafiekstroom management gedeelte dat de management link voorziet tussen ho-

gere lagen QoS protocollen (zoals IntServ en DiffServ) en de 802.11e channel access functions

[13]. TSPEC beschrijft karakteristieken van trafiekstromen zoals data rate, pakketgrootte, ver-

traging en service interval. TSPEC onderhandelingen tussen nabijgelegen MAC lagen voorziet

A.2 Trafiek specificaties 78

Figuur A.1: Typisch voorbeeld van een TSPEC onderhandeling

het mechanisme voor het controleren van toekennen, neerzetten, wijzigen en verwijderen van

trafiekstromen. Zie figuur A.1 voor een voorbeeld.

Trafiekstroom admission control is zeer belangrijk aangezien er gelimiteerde bandbreedte is in

het draadloze medium. Toegang tot de bandbreedte moet gecontroleerd worden opdat trafiek

congestie, die kan lijden tot verbreking van QoS en drastische degradatie van de throughput,

vermeden wordt.

QoS management frames, primitieven en procedures zijn gedefinieerd voor TSPEC onderhande-

lingen, welke altijd gestart worden door het station management entiteit (SME) van een QSTA,

en geaccepteerd of verworpen worden door de HC. TSPEC wordt gecommuniceerd aan de MAC

via de MAC layer management entity (MLME) service access point. Dit laat hogere lagen SW,

protocollen en applicaties toe om resources te alloceren in de MAC laag.

TSPEC lost enkele van de problemen van PCF op, met name het ontbreken van admission

control, management interface en de mogelijkheid dat STAs hun QoS requirements kunnen

doorgeven.

A.3 Extra meting: Video vs BE 79

A.3 Extra meting: Video vs BE

Deze sectie behandelt een extra meting, die verricht werd om te verifieren of IEEE 802.11e in

zijn opzet slaagt. Er wordt nagegaan of een video stream, verzonden tegen 3 Mbit/s, enig nadeel

ondervindt van een BE stream in de tegenovergestelde richting. Laatstgenoemde wordt om de

5 seconden met 0,8 Mbit/s verhoogd. Deze test vindt plaats op het 3Com AP.

De resultaten, voor throughput, staan beschreven in figuur A.2.

Figuur A.2: Een constante video stream wordt doorheen het netwerk gestuurd, terwijl een incrementele

BE stream in de tegenovergestelde richting stroomt.

Uit deze figuur is duidelijk op te maken dat de Video stream geen hinder ondervindt van de BE

stream, desondanks de hoge data rate van BE en het feit dat het netwerk na een tijdje verzadigd

is. De IEEE 802.11e standaard behaalt dus zijn doelstelling, namelijk een differentiatie invoeren

tussen de verschillende klassen.

HET UITVOEREN VAN EEN METING 80

Bijlage B

Het uitvoeren van een meting

Deze bijlage beschrijft stap voor stap hoe een meting uitgevoerd moet worden, voor beide APs.

Allereerst genereer je het configuratiescript van Rude, met behulp van het JAVA-programma

rudeScript [21] – als men dit uitvoert zonder argumenten wordt op het scherm uitgelegd hoe

men dit programma moet uitvoeren – en sla dit op in de directory waar het bestand rude staat.

Voor meer informatie over de configuratiescripts voor Rude wordt verwezen naar [8].

Vervolgens pas je de parameters het script crudeScript aan, dat zich in de directory van het

bestand crude. Deze parameters zijn: het aantal stromen dat Crude moet ontvangen en sta-

tistieken van moet genereren, het ID van de eerste flow en de naam van het bestand waar de

resultaten opgeslagen moeten worden. Dit script is gemaakt omdat het aansturen van Crude

met de commandline een lastige zaak is: men moet alle flowID’s meegeven waarvan een statistiek

van gemaakt moet worden. Men kan zich wel voorstellen dat dit een hele taak is als er meer

dan 100 flows zijn.

Dan stel je de parameters in van WME. Je begint met het AP, waar je inlogt met de browser

en de gewenste parameters ingeeft. Het Gigabyte AP heeft dan 5 seconden nodig om zich te

herconfigureren, wat getoond wordt met een handige teller. Het 3Com AP daarentegen gedraagt

zich daarin vrij stroef: soms herlaadt het browserscherm zich (zoals het moet), soms moet men

opnieuw inloggen op het AP en enkele keren valt zelfs de verbinding met het AP weg. De

waarden zijn wel altijd correct ingesteld, maar het maakt het wel moeilijk om metingen snel na

elkaar uit te voeren.


Een ander probleem: de beacon frames Bij het Gigabyte AP heeft men twee schermen om parame-

ters in te vullen: 1 voor AP (zichzelf dus) en 1 voor STA. Wanneer men dit voor STA invult, kan men

zien dat bij de STAs (dus op de desktop PCs) de parameterset deze waarden aanneemt. Maar het is de

parameterset AP die verandert, en niet die van STA (een desktop PC heeft immers twee parametersets:

1 voor AP en 1 voor STA, omdat een gewone desktop PC ook als AP kan functioneren). Wanneer men

met Wireshark de beacon frames controleert, ziet men een parameterset die niet degene is die ingesteld is

via de browser. Maar toch wijzigt het STA zijn parameterset naargelang de waarden die ingegeven zijn in

de browser. Sterker nog, het 3Com AP heeft deze twee schermen niet – men kan alleen de parameterset

AP aanpassen– en toch toont Wireshark dezelfde beacon frames als bij het Gigabyte AP (dus dezelfde

foute parameterset). Een mogelijke verklaring zou kunnen zijn dat bij Wireshark het beacon frame hard

gecodeerd is en dus fout wordt weergegeven.

Nu stel je de parameters in op de STAs. Dit doe je met het commando iwpriv, waarmee je eerst

kijkt of WME is ingeschakeld, waarbij ath0 de draadloze netwerkinterface is:

iwpriv ath0 get wmm

Dit commando geeft 1 terug als WME ingeschakeld is en 0 in het andere geval.

Vervolgens wijzig je de waarde van de parameter:

sudo iwpriv ath0 cwmin 2 1 2

Na ath0 komt de naam van de parameter die je wilt wijzigen. Dit kan zijn: cwmin, cwmax en

aifs. Het eerste cijfer duidt de klasse aan (0 voor BE en 2 voor VI), het middelste cijfer geeft aan

welke parameterset bedoeld wordt (0 voor AP, 1 voor STA) en het laatste cijfer staat tenslotte

voor de waarde die men toekent aan de parameter. Met het commando wlanconfig kijk je na of

onze instellingen effect hebben:

wlanconfig ath0 list wme

De output is een tabel waarin de waarden staan vermeld voor alle parameters en alle klassen,

zowel voor de AP-parameterset als de STA-parameterset.


Nu start je de feitelijke meting op. Begin met Crude, zodat er zeker geen pakketten verloren

gaan. Dit doe je met het commando

sudo ./crudeScript

Het uitvoeren van dit commando als root is enkel nodig als de NTP-query om de klokken te

synchroniseren opgenomen is in het script (zie bijhorende howto op de CD-ROM).

Dan start je Rude op met volgend commando

sudo ./rude -s configuratiescript

Dit commando moet zeker als root uitgevoerd worden, omdat anders de TOS-velden in de IP-

header niet gezet worden. Het optie-argument -s duidt aan dat er een configuratiescript gebruikt

wordt.

Nadat Rude gedaan heeft met pakketten sturen, beeindig je Crude handmatig met ctrl-c. In

de map \crude vinden we dan het bestand terug met de bestandsnaam die opgegeven was in

het script. In dit bestand vind je alle statistieken terug die Crude bijgehouden heeft, per flow.

Aangezien dit nogal onhandig is om in te geven naar een MS Excel-bestand, ga je dit bestand

dus eerst converteren naar een makkelijkere indeling. Dit doe je als volgt:

java crudeConv #stromen bestandsnaam1 bestandsnaam2

Eerst geef je het aantal flows mee dat Crude heeft opgevangen, dan de naam van het bestand

dat we willen converteren en tenslotte de naam van het nieuwe, geconverteerde bestand. Let op!

Soms vangt Crude geen enkel pakket van een flow op dat door Rude werd uitgezonden. Dit kan

zijn door congestie op het netwerk, door interferentie of omdat Rude gewoonweg de opdracht

had gekregen om nul pakketten per seconde te sturen voor die flow. Zulke flow heeft dan geen

statistiek maar enkel de mededeling dat er geen pakketten zijn opgevangen. Het programma

crudeConv kan hier echter niet mee om en genereert een foutmelding. Het is dus het beste om

zulke flows eerst uit het bestand te verwijderen.


Uiteindelijk heb je dus het geconverteerde bestand, waarvan de gegevens klaar zijn om in MS

Excel (of een andere spreadsheet) ingegeven te worden. Op naar de volgende meting!

INHOUD VAN DE CD-ROM 84

Bijlage C

Inhoud van de CD-ROM

Volgende bestanden zijn terug te vinden op de CD-ROM die bij deze thesis is bijgevoegd:

• Meetresultaten

Alle resultaten, opgedeeld per AP en scenario, in hun originele en geconverteerde vorm.

• MS Excel-bestanden

Alle MS Excel-bestanden gebruikt voor deze thesis. Dit zijn er 5 per AP. In deze bestanden

staan alle figuren die in dit boek opgenomen zijn, samen met nog extra figuren.

• Configuratiebestanden

De configuratiebestanden voor Rude.

• Scripts en programma’s

Alle scripts geschreven of geleend, tesamen met alle JAVA-programma’s die gebruikt zijn

in deze thesis.

Verder zijn er enkele How To’s opgenomen, die het leven wat gemakkelijker maakten:

• Een aantal installatieprocedures voor volgende programma’s: Rude&Crude, Wireshark,

VLC (een mediaspeler) en Iperf (een TCP meettool).

• Hoe de ATI-driver installeren om 1 van de beeldschermen zover te krijgen dat deze iets

grafisch weergeeft.

• Hoe men MadWifi moet upgraden. Een aanrader.

• Hoe men het commando’s scp en chmod uitvoert, om respectievelijk bestanden over het

netwerk te verzenden en om permissies te wijzigen.

INHOUD VAN DE CD-ROM 85

• Hoe men de netwerkinterfaces juist moet instellen voor het gebruikte testnetwerk.

• Hoe men NTP moet configureren. Ook een aanrader.

LIJST VAN FIGUREN 86

Lijst van figuren

1.1 Het thuisnetwerk dat model staat in deze thesis . . . . . . . . . . . . . . . . . . . 2

2.1 De protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 BSS met AP en verschillende STAs . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Interframe spaces en backoff procedures met random contention window size. Hier

heeft het STA een CW = CWmin (15 slots) en een random backoff time van 12

slots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Een voorbeeld van een PCF operatie. Station 1 is de PC en polls station 2.

Station 3 ontvangt het beacon frame en stelt zijn NAV in op de gehele CFP. . . . 11

2.5 Een 802.11 STA en een 802.11e STA met 4 ACs in 1 station . . . . . . . . . . . . 15

2.6 In EDCA strijden meerdere backoff entiteiten voor toegang tot het medium met

verschillende prioriteiten in parallel. De vroegst mogelijke toegangstijd na een

bezet medium is DIFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.7 Een voorbeeld van een 802.11e superframe (CP + CFP) waar de HC TXOPs

toekent in CP en CFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Het configuratiescherm voor QoS van het 3Com AP. . . . . . . . . . . . . . . . . 20

3.2 Het testnetwerk dat in deze thesis gebruikt wordt om metingen uit te voeren. . . 22

4.1 Het resultaat van de inleidende meting qua throughput. Links het 3Com AP,

rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Het resultaat van de inleidende meting qua delay. Links het 3Com AP, rechts het

Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Het resultaat van de inleidende meting qua pakketverlies. Links het 3Com AP,

rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31


4.4 Het resultaat van de inleidende meting qua jitter. Links het 3Com AP, rechts het

Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 De data rate gegeneert in scenario 1. . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 Het resultaat van het aanpassen van het CW van video qua throughput. Links

het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . 36

4.7 Het resultaat van het aanpassen van het CW van video qua delay. Links het

3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.8 Het resultaat van het aanpassen van het CW van BE qua throughput. Links het


4.9 Het resultaat van het aanpassen van het CW van BE qua delay. Links het 3Com

AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.10 Het resultaat van het aanpassen van het AIFS van BE (video:1) qua throughput.

Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . 38

4.11 Het resultaat van het aanpassen van het AIFS van BE (video:1) qua delay. Links


4.12 Het resultaat van het aanpassen van het AIFS van BE qua throughput. Links


4.13 Het resultaat van het aanpassen van het AIFS van BE qua delay. Links het 3Com


4.14 De optimale waarden gevonden voor scenario 1 voor het 3Com AP. Links de

grafiek voor throughput, rechts voor delay. . . . . . . . . . . . . . . . . . . . . . . 40

4.15 De optimale waarden gevonden voor scenario 1 voor het Gigabyte AP. Links de

grafiek voor throughput, rechts voor delay. . . . . . . . . . . . . . . . . . . . . . . 41

4.16 Het combineren van optimale waarden van scenario 1 voor het 3Com AP. Links

de grafiek voor throughput, rechts voor delay. . . . . . . . . . . . . . . . . . . . . 41

4.17 Het combineren van optimale waarden van scenario 1 voor het Gigabyte AP. Links

de grafiek voor throughput, rechts voor delay. . . . . . . . . . . . . . . . . . . . . 42

4.18 Het combineren van de optimale waarden uit scenario 1 qua jitter, voor het Gi-

gabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


4.20 Het resultaat van het aanpassen van het CW van video qua delay. Links het



4.21 Het resultaat van het aanpassen van het CW van video qua jitter, voor het Gi-

gabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.22 Het resultaat van het aanpassen van het CW van BE qua delay. Links het 3Com


4.23 Het resultaat van het aanpassen van het CW van BE qua jitter, voor het 3Com

AP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.24 Het resultaat van het aanpassen van het AIFS van BE (video:1) qua delay. Links


4.25 Het resultaat van het aanpassen van het AIFS van BE (video:1) qua jitter. Links


4.26 Het resultaat van het aanpassen van het AIFS van BE qua delay. Links het 3Com


4.27 De optimale waarden gevonden voor scenario 2 voor het 3Com AP. Links de

grafiek voor delay, rechts voor jitter. . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.28 De optimale waarden gevonden voor scenario 2 voor het Gigabyte AP. Links de

grafiek voor delay, rechts voor jitter. . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.29 Het combineren van optimale waarden van scenario 2 voor het 3Com AP. Links

de grafiek voor delay, rechts voor jitter. . . . . . . . . . . . . . . . . . . . . . . . 50

4.30 Het combineren van optimale waarden van scenario 2 voor het Gigabyte AP. Links

de grafiek voor delay, rechts voor jitter. . . . . . . . . . . . . . . . . . . . . . . . 51


4.32 Het resultaat van het aanpassen van het CW van video qua throughput, voor

stroom 1. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . 55

4.33 Het resultaat van het aanpassen van het CW van video qua delay, voor stroom

1. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . 55

4.34 Het resultaat van het aanpassen van het CW van video qua jitter, voor stroom

1. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . 56

4.35 Het resultaat van het aanpassen van het CW van BE qua delay, voor het 3Com

AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . 56

4.36 Het resultaat van het aanpassen van het CW van BE qua delay, voor het Gigabyte

AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . 57


4.37 Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het

3Com AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . 57


Gigabyte AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . 58


3Com AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . 58



4.41 Het resultaat van het aanpassen van het AIFS BE (video: 1) qua jitter, voor het


4.42 Het vergelijken van de optimale waarden qua delay, voor het 3com AP. Links voor

stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.43 Het vergelijken van de optimale waarden qua jitter, voor het 3com AP. Links voor

stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.44 Het vergelijken van de optimale waarden qua delay, voor het Gigabyte AP. Links

voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.45 Het combineren van de optimale waarden qua delay, voor het 3com AP. Links


4.46 Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links


4.47 Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links


4.48 Het combineren van de optimale waarden qua jitter, voor het Gigabyte AP. Links


4.49 Het resultaat van het aanpassen van het CW van video voor het 3Com AP, qua

delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . 66

4.50 Het resultaat van het aanpassen van het CW van video voor het Gigabyte AP,

qua delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . 66

4.51 Het resultaat van het aanpassen van het CW van BE voor het 3Com AP, qua


4.52 Het resultaat van het aanpassen van het CW van BE voor het Gigabyte AP, qua



4.53 Het resultaat van het aanpassen van het AIFS BE (video: 1) voor het 3Com AP,

qua delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . 68

4.54 Het resultaat van het aanpassen van het AIFS BE (video: 1) voor het Gigabyte

AP, qua delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . 68

4.55 Het resultaat van het aanpassen van het AIFS BE voor het 3Com AP, qua delay.

Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.56 Het resultaat van het aanpassen van het AIFS BE voor het Gigabyte AP, qua


4.57 Het vergelijken van de optimale waarden qua delay, voor het 3com AP. Links voor

Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.58 Het vergelijken van de optimale waarden qua delay, voor het Gigabyte AP. Links

voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.59 Het combineren van de optimale waarden qua delay, voor het 3com AP. Links


4.60 Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links


4.61 Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links


A.1 Typisch voorbeeld van een TSPEC onderhandeling . . . . . . . . . . . . . . . . . 78

A.2 Een constante video stream wordt doorheen het netwerk gestuurd, terwijl een

incrementele BE stream in de tegenovergestelde richting stroomt. . . . . . . . . . 79

LIJST VAN TABELLEN 91

Lijst van tabellen

2.1 Overzicht QoS mechanismen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Mapping van TOS-waarden naar Access Categories . . . . . . . . . . . . . . . . . 21

3.2 Default waarden van WME voor AP en STA . . . . . . . . . . . . . . . . . . . . 25

4.1 Overzicht van de optimale waarde per parameter, scenario 1. . . . . . . . . . . . 35




5.1 Overzicht van de optimale waarden(sets) per scenario. . . . . . . . . . . . . . . . 73

BIBLIOGRAFIE 92

Bibliografie

[1] 3Com Corporation. 3Com Wireless 7760 11 a/b/g PoE Access Point Manual, 10015003

Rev. AA edition, Maart 2006.

[2] Antonio Grilo, Mario Nunes. Performance evaluation of IEEE 802.11e.

http://citeseer.ist.psu.edu/grilo02performance.html.

[3] 3Com Corporation. 3Com Wireless 11a/b/g PCI Adapter.

http://www.3com.com/prod/nl BE EMEA/detail.jsp?tab=features&sku=3CRDAG675B.

Productspecificatie.

[4] 3Com Corporation. 3Com Wireless 7760 11a/b/g PoE Access Point.

http://www.3com.com/prod/nl BE EMEA/detail.jsp?tab=features&sku=3CRWE776075.


[5] Jim Geier. 802.11 MAC Layer Defined. http://www.wi-

fiplanet.com/tutorials/article.php/1216351, 2002.

[6] Jim Geier. Improving WLAN Performance with RTS/CTS. http://www.wi-

fiplanet.com/tutorials/article.php/1445641, 2002.

[7] Tim Godfrey. Inside 802.11e: Making QoS a Reality over WLAN Connections. Commsde-

sign, 2003. http://www.us.design-reuse.com/articles/article6865.html.

[8] Juha Laine, Sampo Saaristo, Rui Prior. Rude & Crude. http://rude.sourceforge.net/.

website.

[9] MadWifi. website. http://madwifi.org/. Multiband Atheros Driver for Wireless Fidelity.

[10] Sun Microsystems. Enterprise QoS: part I - internals.

http://www.phptr.com/articles/article.asp?p=26023&rl=1, 2002.

BIBLIOGRAFIE 93

[11] Mark Santkuyl. What is jitter? - a definition from whatis.com.

http://searchvoip.techtarget.com/sDefinition/0,290660,sid66 gci213534,00.html, 2005.

[12] Simon Chung, Kamila Piechota. Understanding the MAC impact of 802.11e: Part 1.

Commsdesign, 2003.

[13] Simon Chung, Kamila Piechota. Understanding the MAC impact of 802.11e: Part 2.

Commsdesign, 2003.

[14] Stefan Mangold, Sunghyun Choi, Guido Hiertz, Ole Klein, Bernhard Walke. Analysis of

IEEE 802.11e for QoS support in wireless LANs. IEEE Wireless Communications, 10(6):40–

50, 2003.

[15] Stefan Mangold, Sunghyun Choi, Peter May, Ole Klein, Guido Hiertz,

Lothar Stibor. IEEE 802.11e Wireless LAN for Quality of Service.

http://www.mwnl.snu.ac.kr/ schoi/publication/Conferences/02-EW.pdf.

[16] Sunghyun Choi, Javier del Prado, Sai Shankar, Stefan Mangold. IEEE 802.11e Contention-

Based Channel Access (EDCF) Performance Evaluation. http://wireless.cs.jhu.edu/class-

papers/802.11e-performance.pdf.

[17] S.Wietholter, C.Hoene, A.Wolisz. Perceptual Quality of Internet Telephony over IEEE

802.11e Supporting EDCF and Contention Free Bursting. TKN Technical Report TKN-04-

11, 2004. http://www.tkn.tu-berlin.de/publications/papers/wiethoelter paper2.pdf.

[18] Gigabyte Technology. Gigabyte GN-BR02G AirCruiser Mach G Router. http://tw.giga-

byte.com/Products/Communication/Products Spec.aspx?ProductID=2213&ProductName=GN-

BR02G. Productspecificatie.

[19] Gigabyte Technology. Gigabyte GN-WM01GT AirCruiser Mach G Notebook Adapter.

http://tw.giga-byte.com/Products/Communication/Products Spec.aspx?ProductID=990.


[20] Jean Tourrilhes. The MAC level (link layer). http://www.hpl.hp.com/personal/Jean Tourrilhes-

/Linux/Linux.Wireless.mac.html.

[21] Peter Vandenberghe. Ontwerp en Evaluatie van een Overlay QoS Routeer Platform. Af-

studeerwerk, UGent, 2004-2005. Gebruik van enkele scripts.

BIBLIOGRAFIE 94

[22] Wikipedia. Diffserv. http://en.wikipedia.org/wiki/Diffserv.

[23] Wikipedia. IEEE 802.11e. http://en.wikipedia.org/wiki/IEEE 802.11e.

[24] Wikipedia. Intserv. http://en.wikipedia.org/wiki/Intserv.

[25] Wikipedia. Network time protocol. http://en.wikipedia.org/wiki/Network Time Protocol.

[26] Wikipedia. Quality of service. http://nl.wikipedia.org/wiki/Quality of Service.

[27] Wikipedia. TCP/IP model. http://en.wikipedia.org/wiki/TCP/IP model.

[28] WireShark. website. http://www.wireshark.org/. Wireshark: The World’s Most Popular

Network Protocol Analyzer.

[29] Zhen-ning Kong, Danny H.K. Tsang, Brahim Bensaou. Performance Analysis of IEEE

802.11e Contention-Based Channel Access. IEEE Journal on selected areas in communica-

tions, 22(10):2095–2106, 2004.

ieee 802.11e getoetst: parameteroptimalisatie voor...

Documents