IEEE e getoetst: parameteroptimalisatie voor videodiensten in een draadloze thuisomgeving

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

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:


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 nietaflatende 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 kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking 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 thuisomgeving door Koen VERBEECK Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2006–2007 Promotoren:


Scriptiebegeleider:

Ir. W. HAERICK

Samenvatting Aan de ene kant wordt draadloze Internettoegang steeds populairder en heeft dit ondertussen zijn ingang gevonden bij de markt van de thuisgebruikers. Aan de andere kant neemt media content meer en meer aan belang toe. Talloze websites bieden filmpjes aan die in tegenstelling tot vroeger niet meer op de computer opgeslagen worden, maar rechtstreeks gestreamd worden van de website. Tegelijkertijd maakt digitale televisie zijn opmars en het is nog maar een kleine stap om het televisietoestel draadloos te verbinden met het internet. Door het gebrek aan Quality 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 introduceert in draadloze netwerken. Deze standaard heeft echter zijn tekortkomingen en is zeer algemeen gehouden. Deze thesis zoekt dan ook naar een optimalisatie van deze standaard, in het specifieke geval voor video in een draadloze thuisomgeving. Het resultaat is een aantal optimale parameterwaarden voor enkele specifieke scenario’s. Tenslotte werd ook een visie opgesteld waarin 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 for videoservices 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 Service in WiFi, there are no guarantees on the quality of the delivered media. Therefore the standard IEEE 802.11e was created, which introduces QoS in wireless Internet. But this standard has its shortcomings and is kept very general. This thesis is a search for optimization of the 802.11e standard, in the 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. I NTRODUCTION

W

IFI is conquering the market of home networking, due to its simple installation and low cost. Also, media content such as digital television is growing more and more rapidly over the Internet. Legacy 802.11 has no support for Quality of Service (QoS), so quality of the delivered media can not be guaranteed. That’s why the IEEE 802.11e standard has been created, which introduces QoS in wireless networks. We shall describe shortly how 802.11e works. 802.11e introduces the hybrid coordination function (HCF) for QoS support. This function defines two medium access mechanisms: enhanced distributed channel access (EDCA), this enhances the legacy DCF, and HCF controlled channel access (HCCA). HCCA improves and enhances both DCF and PCF [1]. In practice, 802.11g is enhanced with EDCA and is called WME or WMM. The QoS support in EDCA is provided with the introduction of four access categories – Background (BK), Best Effort (BE), Video and Voice – and multiple back-off entities. MSDUs are delivered by parallel backoff entities within one 802.11e station, where backoff entities are prioritized using AC-specific contention parameters, called EDCA parameter set. By carefully choosing the parameters, the standard forces different levels of QoS to the ACs. But the standard is kept very general and has some shortcomings. This thesis searches for an optimization of videoservices, in an home network where WME, the implementation of IEEE 802.11e, is deployed. II. S CENARIOS Four scenarios were adopted for testing and are described in the following sections. A. Scenario 1 The first scenario is interesting for testing purposes, to measure the influences of the different parameters. Department of Informationtechnology, Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

There is a constant stream of 10 Mbit/s BE traffic in one direction and in the other direction a video stream, which is incremented with 3 Mbit/s every 10s. With this scenario, one can test the maximal throughput of the network and see how many video’s the network can handle at the same time. Only the results gathered before the congestion of the network are taken into account, so conclusions can be made on reliable data. B. Scenario 2 This scenario imitates the most common situation in a home network: one video stream of 3 Mbit/s in one direction and a BE stream in the other. This resembles the situation where someone for example is watching digital television and another person is sending e-mails. In this scenario, throughput is of less importance than delay and 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 resemble a situation where someone is sending an e-mail and two other persons are having a videoconference. Throughput will also be of less importance here. D. Scenario 4 This scenario expands scenario 2 with an additional voice stream, flowing in the same direction as the video stream. This resembles having a phone call with VoIP while watching a video. Again, throughput is of less importance, but this time, the voice stream has to be taken into account. Efforts to improve video are not allowed to have negative effects on the voice stream. III. M ETHODS The testing network, used in this thesis is shown in figure 1. We have two STAs, on which the software Rude&Crude is installed [2]. Rude sends UDP packets and Crude captures those packets and generates statistics. In a configuration file one can specify what those packets must look like and how fast they should be transmitted. Rude has an important feature: with a simple command one can set the TOS field in the IP header. The value 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 hardware dependence of WME could be investigated.

tention window of Video is at its smallest, better results should be achieved, but this is not the case. This can be explained by the fact that when a contention window is very narrow, there are likely to be more collisions, hence less throughput and more delay. 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 an enormeous advantage. But, as can be seen in the tables, it isn’t alway AIFS=7 that produces the best results. Even stronger, the combinations of various optimal values don’t always provide better results. V. C ONCLUSIONS

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

For our optimization, the following parameters from the EDCA set were used: CWmin, CWmax and AIFS. These parameters are changed for every scenario in the exact same way: first the contention window from the AC Video is shrinked. Secondly, we enlarge the contention window from the AC BE is enlarged. Next the AIFS of Video is set to one – for AC as well for STA – and the AIFS of BE is incremented. Then the AIFS of Video is set to default and the AIFS of BE is incremented. Subsequently, the results are visually compared for every step, hereby finding the optimal value for a scenario. Finally, the optimal values are combined in order to see if a better result can be obtained than the most optimal value on its own. IV. R ESULTS Table I and table II show the results of our tests, first for the 3Com AP, then for the Gigabyte AP. As the two tables are not the same, it has been shown that there is a hardware dependence. TABLE I OVERVIEW OF THE RESULTS FOR THE 3C OM AP.

Scenario 1 2 3 4

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

TABLE II OVERVIEW OF THE RESULTS FOR THE G IGABYTE AP.

Scenario 1 2 3 4

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

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

The efforts made in the different tests resulted the following: optimal values were found for every scenario. Furthermore, the hardware dependence of IEEE 802.11e was investigated: different 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 parameters accordingly. This way the best performance can be obtained at any time. One can also use these results to replace the default values of WME, thus creating an access point adapted to a specific scenario. Or the higher layers in the protocolstack can use these results to communicate their preferences to the wireless netwerk, using TSPEC. Further research should include more combinations of parameters, more scenarios and even more APs. Only by doing this one can achieve a robust model for the dynamic access point. ACKNOWLEDGMENTS The author would like to thank Wouter Haerick and Peter Vandenberghe for their guidance and many suggestions during the making of this thesis. R EFERENCES [1] Stefan Mangold, Sunghyun Choi, Guido Hiertz, Ole Klein, Bernhard Walke, “Analysis of IEEE 802.11e for QoS support 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 2.1

2.2

2.3

4

Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Intserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Diffserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

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

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

3 Methodiek 3.1

3.2

3.3

ix

19

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.1.1

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.1.2

Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.1.3

Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

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

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

Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.3.1


43

4.3.2

Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.3.3


43

4.3.4


44

4.3.5


44

4.3.6


45

4.3.7


45

Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.4.1


52

4.4.2

Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.3

4.4

INHOUDSOPGAVE

4.5

x

4.4.3


53

4.4.4


53

4.4.5


53

4.4.6


54

4.4.7


54

Scenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.5.1


64

4.5.2

Aanpassen CW BE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.5.3

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

64

4.5.4


65

4.5.5


65

4.5.6


65

4.5.7


66

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 efficiëntie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

1.2

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, aanpassen 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: één 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 kwantitieve 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, vermindert 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 prioriteiten 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. Bijvoorbeeld: 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 cliënt van de laag aan te bieden (nl. hogere protocollagen) en om eerlijke toegang tot het gedeelde draadloze medium te controleren [20], [5]. De MAC laag zelf is één 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


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


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 initiëren, 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 contention 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).


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


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,


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 beëindigd. 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

2.2.3

12

QoS beperkingen in de originele 802.11 MAC

DCF heeft geen enkele voorziening om QoS te ondersteunen. Alle data wordt op een first come 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 én 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 beperkingen. 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 requirements 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


13

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 coördinatiefunctie, 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 parameters. 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


14

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 efficiëntie 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 één 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 vrijkomen 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


15

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:

AIF S[AC] = SIF S + AIF SN [AC] ∗ slottijd, AIF SN [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.


16

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

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 coördinator (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 initiëren, 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


17

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

18

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 besproken 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 parameters 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

3.1 Testopstelling

21

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 creëren. 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 beëindigd 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.

3.1 Testopstelling

22

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. Computerklokken 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 NTPserver op te nemen in het netwerk. Deze server draait op een desktop PC, die zijn eigen systeemklok 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 crudeScript. 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 voorkomen. 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 schommelend 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 doorgestuurde 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 BEverkeer. 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

3.2.4

25

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 parameters CWmin, CWmax en AIFS voor staan: wanneer een backoff entiteit (elk toestel heeft er 4, waarvan elk één 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 aanvaardbare 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 scenario 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 verifiëren 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. • Verifiëren 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 gewenste 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 gelijkaardige 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 liggen 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.


30

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


31

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). Zoals 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 werkelijke 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 kunnen 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 realtime 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 delay 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 opmerkelijk 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 defaultwaarden, 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

4.2.5

35

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 optimale 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, rechts het Gigabyte 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, rechts het Gigabyte 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

4.3

43

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.

4.3.1

Aanpassen CW Video

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.

4.3.2

Aanpassen CW BE

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.

4.3.3


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.

4.3.4

Aanpassen AIFS BE

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.

4.3.5


Tabel 4.2 geeft een overzicht van de optimale waarde per parameter, voor dit scenario. Tabel 4.2: Overzicht van de optimale waarde per parameter, scenario 2.

Parameter


Gigabyte

CW Video

CWmin: 2, CWmax: 4

CWmin: 1, CWmax: 2

CW BE

CWmin: 5, CWmax: 10

CWmin: 6, CWmax: 10

AIFS BE (video:1)

6

5

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

4.3.6

45


Na combineren van de verschillende optimale waarden bekomen we voor het 3Com AP figuur 4.29. Hieruit blijkt dat het combineren van waarden voor het 3Com AP weer geen betere 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 laagste 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.7

Figuren scenario 2


4.3 Scenario 2

46

Figuur 4.20: Het resultaat van het aanpassen van het CW van video qua delay. Links het 3Com AP, rechts het Gigabyte 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, rechts het Gigabyte 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 3Com AP, rechts het Gigabyte AP.

Figuur 4.25: Het resultaat van het aanpassen van het AIFS van BE (video:1) qua jitter. Links het 3Com AP, rechts het Gigabyte AP.

4.3 Scenario 2

49

Figuur 4.26: Het resultaat van het aanpassen van het AIFS van BE qua delay. Links het 3Com AP, rechts het Gigabyte 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

4.4

52

Scenario 3

Voor informatie over de configuratie van dit scenario wordt verwezen naar 3.2.3. In de figuren 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.

4.4.1

Aanpassen CW Video

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

4.4.2

Aanpassen CW BE

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.

4.4.3


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.

4.4.4

Aanpassen AIFS BE

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.

4.4.5



Parameter


Gigabyte

CW Video

CWmin: 2, CWmax: 4

Default

CW BE

CWmin: 6, CWmax: 10

CWmin: 6, CWmax: 10

AIFS BE (video:1)

7

5

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.

4.4.6


Het combineren van de optimale waarden levert bij het 3Com AP geen extra winst op, zoals weergegeven 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.7

Figuren scenario 3


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 het 3Com AP, rechts het Gigabyte AP.

4.4 Scenario 3

56

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

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 AP. Links voor stroom 1, rechts voor stroom 2.

Figuur 4.39: 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

59

Figuur 4.40: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

Figuur 4.41: Het resultaat van het aanpassen van het AIFS BE (video: 1) qua jitter, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

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 1, rechts voor stroom 2.

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 1, rechts voor stroom 2.

4.4 Scenario 3

62

Figuur 4.46: Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links voor stroom 1, rechts voor stroom 2.

Figuur 4.47: Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

4.4 Scenario 3

63

Figuur 4.48: Het combineren van de optimale waarden qua jitter, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

4.5 Scenario 4

4.5

64

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.

4.5.1

Aanpassen CW Video

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 eerstgenoemde is de waardeset {Cwmin: 2, Cwmax: 3} het meest optimaal, omdat deze voor Video én 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.

4.5.2

Aanpassen CW BE

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 CDROM). De waardeset {AIFS BE = 4, Video = 1} is het meest efficiënt voor het Gigabyte AP.

4.5 Scenario 4

4.5.4

65

Aanpassen AIFS BE

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.

4.5.5



Parameter


Gigabyte

CW Video

CWmin: 2, CWmax: 3

CWmin: 1, CWmax: 3

CW BE

CWmin: 6, CWmax: 10

CWmin: 5, CWmax: 10

AIFS BE (video:1)

6

4

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.

4.5.6


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

4.5.7

66

Figuren scenario 4

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. Links voor Video, rechts voor Voice.

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. Links voor Video, rechts voor Voice.

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 voor Video, rechts voor Voice.

Figuur 4.56: Het resultaat van het aanpassen van het AIFS BE voor het Gigabyte AP, qua delay. Links voor Video, rechts voor Voice.

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 optimale 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 bekomen 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 één 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 hardware, 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 één 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 mogelijkheid 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 televisie. 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 parameterset 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 gebruikersgemak bij draadloze netwerken.

5.3 Verder verloop

76

Iets minder spectaculair is dat men in de parameterset de defaultwaarden vervangt door één of meerdere optimale waarden. Men bekomt dan een AP of STA dat gespecialiseert is in videodiensten. 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 videoconferencing 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 verschillende 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 automatiseerbaar 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 effici¨ entie

802.11e biedt meerdere mechanismen aan om de efficiëntie te verhogen, waarvan er hier kort twee besproken worden.

Block Acknowledgement Dit laat een backoff entiteit toe om een aantal MSDUs opeenvolgend te verzenden gedurende één 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 hogere lagen QoS protocollen (zoals IntServ en DiffServ) en de 802.11e channel access functions [13]. TSPEC beschrijft karakteristieken van trafiekstromen zoals data rate, pakketgrootte, vertraging 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 onderhandelingen, 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

A.3

79

Extra meting: Video vs BE

Deze sectie behandelt een extra meting, die verricht werd om te verifiëren 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 statistieken 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.


81

Een ander probleem: de beacon frames Bij het Gigabyte AP heeft men twee schermen om parameters 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.


82

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 IPheader niet gezet worden. Het optie-argument -s duidt aan dat er een configuratiescript gebruikt wordt.

Nadat Rude gedaan heeft met pakketten sturen, beëindig 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.


83

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

• Hoe men de netwerkinterfaces juist moet instellen voor het gebruikte testnetwerk. • Hoe men NTP moet configureren. Ook een aanrader.

85

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

2.4

10

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

2.7

16

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

4.2

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

4.3

29

30

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

31

LIJST VAN FIGUREN

4.4

87

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

4.7

Het resultaat van het aanpassen van het CW van video qua delay. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8

37

Het resultaat van het aanpassen van het CW van BE qua throughput. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . . . .

4.9

36

37

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 het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . .

39

4.12 Het resultaat van het aanpassen van het AIFS van BE qua throughput. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . .

39

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

40

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

42

4.19 De data rate gegeneert in scenario 2. . . . . . . . . . . . . . . . . . . . . . . . . .

45

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

46

LIJST VAN FIGUREN

88

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

46

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

47

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 het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . .

48

4.25 Het resultaat van het aanpassen van het AIFS van BE (video:1) qua jitter. Links het 3Com AP, rechts het Gigabyte AP. . . . . . . . . . . . . . . . . . . . . . . . .

48

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

49

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.31 De data rate gegeneert in scenario 3. . . . . . . . . . . . . . . . . . . . . . . . . .

54

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

LIJST VAN FIGUREN

89

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

4.38 Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

. . . . . . . . . . . . .

58

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

58

4.40 Het resultaat van het aanpassen van het AIFS BE (video: 1) qua delay, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

. . . . . . . . . . . . .

59

4.41 Het resultaat van het aanpassen van het AIFS BE (video: 1) qua jitter, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2.

. . . . . . . . . . . . .

59

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 voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.46 Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . .

62

4.47 Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . .

62

4.48 Het combineren van de optimale waarden qua jitter, voor het Gigabyte AP. Links voor stroom 1, rechts voor stroom 2. . . . . . . . . . . . . . . . . . . . . . . . . .

63

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 delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . .

67

4.52 Het resultaat van het aanpassen van het CW van BE voor het Gigabyte AP, qua delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . .

67

LIJST VAN FIGUREN

90

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 delay. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . .

69

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 voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

4.60 Het combineren van de optimale waarden qua jitter, voor het 3com AP. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

4.61 Het combineren van de optimale waarden qua delay, voor het Gigabyte AP. Links voor Video, rechts voor Voice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

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

4.2


44

4.3


53

4.4


65

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. Productspecificatie. [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. Commsdesign, 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

http://www.phptr.com/articles/article.asp?p=26023&rl=1, 2002.

I

-

internals.

BIBLIOGRAFIE

[11] Mark

Santkuyl.

93

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 Lothar

Mangold,

Sunghyun

Stibor.

IEEE

Choi, 802.11e

Peter Wireless

May,

Ole

LAN

for

Klein,

Guido

Quality

of

Hiertz, 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 ContentionBased Channel Access (EDCF) Performance Evaluation. http://wireless.cs.jhu.edu/classpapers/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-0411, 2004. http://www.tkn.tu-berlin.de/publications/papers/wiethoelter paper2.pdf. [18] Gigabyte Technology. Gigabyte GN-BR02G AirCruiser Mach G Router. http://tw.gigabyte.com/Products/Communication/Products Spec.aspx?ProductID=2213&ProductName=GNBR02G. Productspecificatie. [19] Gigabyte Technology. Gigabyte GN-WM01GT AirCruiser Mach G Notebook Adapter. http://tw.giga-byte.com/Products/Communication/Products Spec.aspx?ProductID=990. Productspecificatie. [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. Afstudeerwerk, 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 communications, 22(10):2095–2106, 2004.

IEEE e getoetst: parameteroptimalisatie voor videodiensten in een draadloze thuisomgeving

Recommend Documents