Breedbandverkeer in draadloze netwerken

Breedbandverkeer in draadloze netwerken
Douterloigne Koen Pareit Daan Werbrouck Steven Willems Tom De volledige titel van het project is: “Studie van breedband dataverkeer in IP-gebaseerde mobiele en draadloze netwerken.” Deze titel is misschien te lang om op een slide weer te geven…

Overzicht Probleemstelling en doel Aanpak, planning en opvolging
Synchronisatie testopstelling en simulatie Studie van het probleem TV-DRR-algoritme: een overzicht Resultaten met het algoritme

Probleemstelling sterke groei van draadloze communicatie:
Gsm Laptop Pda nood aan protocol: IEEE WLAN = protocol dat het gebruik van het medium ‘lucht’ voorschrijft De afgelopen jaren is er een explosieve groei van mobiele telefonie (gsm-gebruik). [mogelijke vraag aan het publiek: “Wie heeft er een gsm?” en “Wie had er 5 jaar terug al een gsm?”  explosieve groei van draadloze toepassingen in de laatste 5 jaar] Draadloze communicatie wordt ook steeds meer toegepast in computernetwerken. Het grote probleem is dat alle computers hetzelfde medium, lucht, gebruiken. Er is dus een protocol nodig dat voorschrijft hoe deze communicatie gebeurt, i.e. hoe het medium gedeeld wordt tussen de PC’s. Een gekend voorbeeld van zo’n datalinklaagprotocol (cf Communicatienetwerken) is Ethernet. Ook daar worden regels in acht genomen om goede communicatie te garanderen (zoals CSMA/CD, exponential backoff). Het protocol voor draadloze communicatie dat wij moeten testen is het IEEE WLAN, een protocol dat nog niet helemaal op punt staat.

802.11 WLAN: een overzicht gelijkaardig aan Ethernet:
CSMA = testen op beschikbaarheid van medium exponential backoff toch verschillen wegens: “hidden node” … Het is niet de bedoeling om hier het volledige Wireless LAN protocol uit te leggen. We halen alleen enkele principes aan die specifiek zijn voor het protocol. In computernetwerken werdt het protocol Ethernet uitvoerig bekeken. Men zou zich kunnen afvragen waarom dit protocol ook niet geschikt is voor draadloze communicatie. Om het belang van een specifiek protocol aan te duiden beschouwen we 2 problemen die bestaan bij dergelijke draadloze communicatie die we niet terugvinden bij ethernet.

802.11 WLAN: een overzicht Hidden Node: A  B C  B
C ziet communicatie tss A en B niet  COLLISION Het eerste probleem is het zogenaamde “hidden-node” probleem waarbij fysieke obstakels de oorzaak zijn van storingen in de communicatie. Stel dat knoop A wil communiceren met B. Ook knoop C wil met B communiceren, maar C ziet omwille van een obstakel de aan de gang zijnde communicatie tussen A en B niet. Daarom zal C denken dat het medium vrij is en verzendt bijgevolg zijn frames. De communicatie loopt slecht af: er zijn botsingen (collisions).

WLAN: een overzicht Ethernet: Collision Detection (CD) vs : Collision Avoidance (CA) botsingen worden voorkomen a.d.h.v. een extra frameveld  geeft informatie over de benodigde zendtijd Deze twee problemen kunnen met redelijk grote waarschijnlijkheid optreden. Daarom besloten de ontwerpers van het protocol om geen Collision Detection te implementeren, maar wel Collision Avoidance. CA houdt in dat men probeert om collisions te voorkomen in plaatst van ze te accepteren en de gevolgen ervan te moeten herstellen. CA wordt geïmplementeerd door een extra frameveld waarin het verzendende station expliciet aangeeft hoe lang deze het frame zal verzenden via het kanaal. Aan de hand van deze waarde bepalen de overige stations die willen gaan verzenden de minimale wachttijd.

Doel van het project 802.11 WLAN staat nog niet op punt
implementeren van een algoritme dat wel eerlijk de bandbreedte verdeelt: TV-DRR-algoritme Het WLAN protocol staat dus duidelijk nog niet volledig op punt. De doelstelling van ons project is dan ook om een aangepast protocol te ontwikkelen en te evalueren. Dit doen we door een algoritme aan het protocol toe te voegen, waarover later meer. Ons aangepast protocol zou dan wel in staat moeten zijn om de bandbreedte eerlijk te verdelen over alle knopen in het draadloos netwerk.

Aanpak Opsplitsing in 2 delen: testen van breedbandverkeer
implementeren “eerlijk” algoritme Ons project wordt opgesplitst in twee delen die na elkaar zullen worden afgewerkt. Per deel wordt het werk opgesplitst in 2 groepjes (van elk 2 personen): testopstelling vs. simulatie. In het eerste deel wordt het WLAN protocol getest door parameters zoals de packet size, bitrate, fragmentatie… te variëren. Bedoeling is om de “fairness” van het protocol te bekijken. De resultaten zullen aantonen dat het standaard IEEE protocol er niet in slaagt om de totale bandbreedte eerlijk te verdelen tussen meerdere draadloze toestellen (is ons op voorhand al verteld). Daarom zullen we daarna een algoritme implementeren die zo’n fairness wel min of meer garandeert. testopstelling vs. simulatie

Aanpak We hebben in beide delen onze groep opgesplitst in twee: twee mensen houden zich het hele project bezig met de simulatie, de andere twee testen de werkelijke opstelling. De testopstelling bestaat uit 4 computers. Hiervan zijn 3 computers draadloos met elkaar verbonden met een WLAN kaart. De 4e computer dient om de 3 testpc’s aan te sturen en is verbonden via een controlenetwerk. De simulatie gebeurt met het programma OPNET. De simulatie moet uiteraard een getrouwe weergave zijn van de realiteit, zijnde de testopstelling. Daartoe kunnen vele parameters worden ingesteld; voor de hand liggende parameters (zoals hoe sterk moet het signaal zijn of hoe ver staan de PC’s van elkaar) en complexere parameters die specifiek zijn aan WLAN (waar we dan ook niet dieper op in gaan).

Planning en opvolging (klik om verder te gaan en de figuur zal naar links opschuiven en het deel van de planning tonen dat niet op de slide kon)

Synchronisatie testopstelling en simulatie
simulatie brengt fout in opstelling aan het licht In de eerste presentatie was dit ons eerste resultaat. De testopstelling en simulatie kwamen nog niet echt overeen. Uiteindelijk bleek dat de drivers van een netwerkkaart niet goed ingesteld waren, zodat de testopstelling verkeerde resultaten opleverde. De resultaten met de juiste drivers komen wel overeen met de simulatie; dit is een mooie controle van ons simulatiemodel.

Studie van het probleem
Principe: clients genereren verschillend verkeer SERVER Wireless domain In de testopstelling zaten we met het probleem dat we geen acces-point hadden. De pc’s waren met elkaar verbonden in ad-hoc mode. In de specificatie van het protocol (en ook in de specificatie van het algoritme) ging men er echter wel van uit dat er een acces point was. We moesten dus een creatieve oplossing vinden. Om de oneerlijkheid vast te stellen maken we gebruik van deze opstelling: 1 Server en 2 Clients die tegelijkertijd verkeer genereren. We zorgen er dan voor dat verschillende parameters zoals pakketgrootte, transmissiesnelheden etc variëren, zodanig dat we kunnen zien wat de oorzaak is van de oneerlijke verdeling van de bandbreedte. CLIENT 1 CLIENT 2

Studie van het probleem
testopstelling: bestandsoverdracht door Iperf simulatie: zelfde opstelling uitbreiding naar andere situaties Voor alle testen zullen we het netwerktool iperf gebruiken (text-based want geen x-host op de testpc’s). We hebben een testopstelling van 3 pc’s ter beschikking waarin we de testen kunnen uitvoeren. We simuleren dezelfde opstelling nog eens in OPNET (simulatieprogramma) en hierin kunnen we de testen gemakkelijk uitbreiden naar meerdere pc’s en/of andere situaties.

Studie van het probleem (test 1)
In de standaard kan je al een transmissiesnelheden instellen in de netwerkkaarten. De keuze is beperkt tot 1, 2, 5.5 en 11 Mbps. Als we alle twee de clients een transmissiesnelheid geven van 11 Mbps(2 donkerblauwe grafieken) zien we dat ze alle twee evenveel bandbreedte krijgen. Als we nu de transmissiesnelheid verlagen op een van de stations dan verlaagt logisch gezien zijn bandbreedte. Maar bandbreedte van het andere station verlaagt ook.. Dit is niet echt “eerlijk” want de ene computer krijgt minder bandbreedte toegewezen doordat de andere een lagere transmissiesnelheid heeft. OORZAAK: tragere client houdt medium langer bezet, zodat snelle client minder toegangstijd krijgt

SERVER Genereert om de zoveel tijd verkeer met elke keer een andere packetsize Wireless domain Genereert altijd verkeer met constante packetsize Vaste packetsize Varierende packetsize Het rechtse workstation haalt 1 groot bestand op en zal gedurende de hele test verkeer genereren en dit met een constante packetsize. Het linkse workstation haalt een aantal kleinere bestanden op, maar elke keer met een andere packetsize. We laten deze packetsize varieren omdat we dachten dat dit een belangrijke parameter zou zijn voor eerlijkheid. CLIENT 1 CLIENT 2

Dit zijn de resultaten uit de testopstelling. constante verkeersstroom (blauw) Varierende verkeersstroom (rood) De bandbreedte wordt uitgezet tov de tijd. We laten packetgrootte van de varierende client langzaam oplopen. We zien dat als we kleinere packets doorsturen we minder bandbreedte krijgen. De totale bandbreedte zakt ook. Als we eerlijkheid implementeren verwachten we dat de pieken in de rode curves hoger komen te liggen. De blauwe curve zullen dan ook nog iets meer moeten zakken. Het algoritme moet eigenlijk een gegarandeerde minimale bandbreedte kunnen leveren onafhankelijk van de packetgrootte We zien ook dat als de 2 packetgroottes hetzelfde zijn dat de bandbreedte eerlijk verdeeld wordt.

Hier zijn nog eens dezelfde resultaten maar dan uit de simulatie. De resultaten komen weer vrij goed overeen,

-500 500 1000 1500 2000 2500 3000 3500 4000 10 20 30 40 50 60 time (s) Packetrate (packets/s) OORZAAK: In de simulatie hebben we ook nog eens het aantal packets gemeten. Hier zien we dat elk workstation evenveel packets mag versturen. Aangezien de ene veel kleiner packets verstuurt krijgt hij veel kleinere bandbreedte. De client met kleine packetgrootte zou dus meer toegangen tot het netwerk moeten krijgen dan de tweede client, opdat eerlijkheid.

TV DRR algoritme = time-varying Deficit Round Robin Concept:
Houdt tijd Tprev bij van laatste toegang tot netwerk Hoe langer geleden, hoe meer kans tot toegang Hoe kleiner de pakketgrootte, hoe meer kans Bepaalde bandbreedte BW wordt gegarandeerd Realisatie in 4 stappen in een lus

TV DRR algoritme: STAP 1 & 2
Q = BW * (Tcurr – Tprev) = BW * ΔT [bits/s*s = bits] Q = quantum, BW = gegarandeerde bandbreedte Stap 2: D = D + Q [bits] D = Deficit counter Stap 1: Hier definiëren we een quantum. Dit is een getal dat berekend wordt om ervoor te zorgen dat de kans tot toegang inderdaad groter wordt wanneer het lang geleden is dat je nog eens toegang gekregen hebt. Dit zien we doordat een verschil wordt gemaakt tussen de huidige tijd (current) en de vorige tijd (previous). Ook de gegarandeerde bandbreedte komt hier in voor: hoe groter die bandbreedte, hoe groter de kans tot toegang van het netwerk. Stap 2: Hier definiërne we een deficit counter. Deze wordt telkens upgedate met het quantum. Op die manier kunnen we informatie bijhouden over de geschiedenis van het netwerkverkeer.

TV DRR algoritme: STAP 3 & 4
If (Psize < D) then SEND; D = D – Psize; Tprev = Tcurr; Stap 4: If (D > Dmax) then D = Dmin; Stap 3: De deficit counter stijgt dus steeds met een tijdsvariërende parameter Q. Wanneer die counter groter is dan de packetsize van het te versturen pakket, mag de client zenden. De deficit counter moet dan uiteraard verminderd worden met die pakketgrootte: de client heeft toegang gekregen tot het medium en de kans op een volgende toegang mag dus lager zijn. Ook het laatste tijdstip waarop gezonden werd, moet aangepast worden. Stap 4: Deze stap is noodzakelijk voor de goede werking van het algoritme. Wanneer een client om één of andere reden lange tijd niets heeft kunnen/willen zenden, dan zou die deficit counter heel groot worden (zie vorige slide). Wanneer hij dan opnieuw begint met zenden, start hij met een veel groter voordeel: zijn deficit counter is uiteraard veel groter dan de pakketten die hij moet verzenden. Hij zou lange tijd mogen blijven zenden. Vandaar dat er een bovengrens Dmin aanwezig is.

Resultaten met algoritme
Volledige implementatie in testopstelling niet mogelijk binnen tijdsbestek Wel mogelijk in de simulatie-omgeving Voor de implementatie van het algoritme in de testopstelling maakten we gebruik van het programma Click. Het algoritme zegt wel dat de aanpassing moet gebeuren in het protocol zelf, maar dit konden we niet doen omdat we te weinig kennis hebben om aanpassingen te doen in de kaarten zelf. Het programma Click zet eigenlijk een soort van "blokje" tussen de host en de WLAN kaart. Het probleem was dat hierdoor een te grote vertraging geïntroduceerd werd. In het algoritme moeten we namelijk de tijd weten waarop het pakket effectief op het kanaal gezet wordt. Dit konden we niet correct doen in Click (want we konden enkel het tijdstip bijhouden waarop het pakket naar de kaart gestuurd werd). In opnet ging dit wel aangezien we daar wel rechtstreeks aanpassingen aan het protocol konden doen. Alle resultaten die volgen komen dus uit opnet.

De grote linkse grafiek is het resultaat dat we met OPNET bekomen. De varierende client krijgt nu dus evenveel bandbreedte als de constante. Ter vergelijking werd rechtsboven nogmaals het oude resultaat opgenomen, zonder algoritme.

Hier zien we eens een vergelijkende grafiek van de varierende client De rode stippellijn is die zoals we reeds in ‘studie van het probleem’ behandeld hebben: de bandbreedte van de variërende client terwijl een client met constante pakketgrootte zendt, ZONDER TV-DRR De rode dunne lijn is de bandbreedte van de variërende client ZONDER dat een andere client met constante pakketgrootte zendt, ZONDER TV-DRR De rode dikke lijn is de bandbreedte van de variërende client terwijl een client met constante pakketgrootte zendt, MET TV-DRR

Hier zien we eens een vergelijkende grafiek van de constante client De blauwe stippellijn is die zoals we reeds in ‘studie van het probleem’ behandeld hebben: de bandbreedte van de constante client terwijl een client met varierende pakketgrootte zendt, ZONDER TV-DRR De blauwe dunne lijn is de bandbreedte van de constante client ZONDER dat een andere client met varierende pakketgrootte zendt, ZONDER TV-DRR De blauwe dikke lijn is de bandbreedte van de constante client terwijl een client met varierende pakketgrootte zendt, MET TV-DRR

Conclusie Volledige implementatie in testopstelling niet mogelijk binnen tijdsbestek Wel mogelijk in de simulatie-omgeving 2 oplossing aanbieden aan de “klant”: Goedkoper maar minder goed Duur (langere ontwikkelingstijd) maar beter Volledige implementatie niet mogelijk: firmware aanpassingen nodig 2 oplossingen aanbieden aan klant - goedkoper maar minder goed (de oplossing die we nu hadden) - duur maar beter (een rechtstreekse aanpassing in de firmware)

Bedankt voor uw aandacht
Vragen Bedankt voor uw aandacht Zijn er nog vragen ?

Breedbandverkeer in draadloze netwerken

Verwante presentaties

Presentatie over: "Breedbandverkeer in draadloze netwerken"— Transcript van de presentatie:

Verwante presentaties

Over het project

Feedback

Inloggen

Inloggen via een sociaal netwerk:

Breedbandverkeer in draadloze netwerken

Verwante presentaties

Presentatie over: "Breedbandverkeer in draadloze netwerken"— Transcript van de presentatie:

Verwante presentaties

Over het project

Feedback