Table of Contents

Laborator 07 - 08: 802.11 Contention Window

Bibliografie recomandată

Teorie/Recapitulare

Protocolul CSMA/CA a fost conceput pentru a reduce probabilitatea coliziunii între mai multe stații care accesează mediul wifi, în punctul în care coliziunile pot să apară cel mai probabil. Odată ce mediul devine liber (“idle medium”) și, apoi, devine imediat ocupat (“busy medium”) - indicație obținută de la funcția CS (carrier-sense), avem o probabilitate ridicată de coliziune deoarece mai multe stații au așteptat ca mediul să fie liber. Această situație necesită o procedură de random backoff pentru a rezolva conflictele de acces la mediu:

O stație care dorește să inițieze un transfer de cadre folosind DCF (Distributed Coordination Function) ca procedură de acces la mediu va folosi funcția de CS (carrier-sense) pentru a determina dacă mediul e busy sau idle. Dacă mediul e ocupat, stația trebuie să aștepte ca mediul să fie liber pentru o perioadă egală cu DIFS (ultimul cadru a fost recepționat fără întrerupere de mediu) sau mediul a fost liber fără întrerupere pentru o perioadă egală cu EIFS (Extended IFS). După DIFS sau EIFS, stația care vrea să transmită trebuie să genereze o perioadă de random backoff înainte de a își iniția transferul de cadru. Această perioadă e egală cu:

$BackoffTime = Random() \cdot aSlotTime$

Aici avem:

Ce facem la laborator

Scopul acestui laborator este de a investiga impactul dimensiunii ferestrei de arbitrare (contention window) asupra performanței protocolului IEEE 802.11. MAC-ul IEEE 802.11 prevede ca toate nodurile să aleagă un timp de așteptare aleator cuprins între zero şi CW (fereastra de arbitraj) şi aşteaptă numărul ales de sloturi înainte de a încerca să acceseze canalul. Inițial, CW este setat la CWMin (minim fereastra susținute de mărime). Cu toate acestea, atunci când există o coliziune, dimensiunea fereastrei este dublată, până la o valoare maximă: CWMax. Aceasta tehnică de randomizare şi scalare a ferestrei este folosită pentru a reduce coliziunile. În studiul nostru vom lua în considerare o variantă de 802.11 pt cazul în care mărimea ferestrei este fixă, şi anume CWMin = CWmax = CW. Deși nu se scalează fereastra, se folosește randomizarea.

Vom avea nevoie de o topologie în care pentru a studia efectul dimensiunii fereastrei vom folosi reţea de un hop atunci când toate nodurile sunt plasate într-un grup compact. În particular, vom considera o arie de 150x10m comună pentru toate nodurile. Fiecare sursă participă la o conversaţie, o destinaţie poate participa la mai multe.

Task-uri

[00a] Pregătirea laboratorului

Pe mașina virtuală aveți tot ce trebuie în /home/student/ns-3-dev.

Dacă lucrați pe alt dispozitiv trebuie să rulați comenzile: 

student@isrm-vm-2020:~$ git clone https://gitlab.com/nsnam/ns-3-dev.git
student@isrm-vm-2020:~$ cd ~/ns-3-dev
student@isrm-vm-2020:~/ns-3-dev$ git checkout -b ns-332-rel ns-3.32
student@isrm-vm-2020:~$ cd ~/ns-3-dev/examples
student@isrm-vm-2020:~/ns-3-dev/examples$ git clone https://github.com/isrm-lab/ns3-labs.git
student@isrm-vm-2020:~$ cd ~/ns-3-dev
student@isrm-vm-2020:~$ ./waf configure --build-profile=debug --enable-examples --enable-tests
student@isrm-vm-2020:~$ ./waf build -j4

Pentru a lansa aplicatia de Jupyter Notebook, rulati urmatoarea comanda: 

student@isrm-vm-2020:~$ jupyter-notebook

[00b] Rulare script si tracing

Pentru o topologie cu 4 noduri sursă, 4 noduri destinație, CW minim 15, CW maxim 1023 (parametrii default de 802.11g si fără PCAP tracing), trebuie sa rulam scriptul cu urmatorii parametrii: 

./waf --run "lab7-8-cw --ns=4 --nd=4 --minCw=15 --maxCw=1023 --pcap=false"

Scriptul primește următorii parametrii: 

    CommandLine cmd;
    cmd.AddValue ("enableRtsCts", "RTS/CTS enabled", enableRtsCts);
    cmd.AddValue ("payloadSize", "Payload size in bytes", payloadSize);
    cmd.AddValue ("simulationTime", "Simulation time in seconds", simulationTime);
    cmd.AddValue ("pcap", "Enable/disable PCAP Tracing", pcapTracing);
    cmd.AddValue ("ns", "number of nodes source for transmission", ns);
    cmd.AddValue ("nd", "number of nodes destination for transmission", nd);
    cmd.AddValue ("minCw", "minimum contention window size", minCw);
    cmd.AddValue ("maxCw", "maximum contention window size", maxCw);
    cmd.AddValue ("phyRate", "Physical layer data rate (MCS)", phyRate);
    cmd.AddValue ("udpRate", "UDP TX desired delivered bitrate (bps)", udpRate);
    cmd.Parse (argc, argv);

Parametrii de interes (ce vor fi variați la acest laborator) sunt:

Tracing

Simularea ne va afișa la final următoarele valori: 

Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/MacTxDrop", MakeCallback(&MacTxDrop));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyRxDrop", MakeCallback(&PhyRxDrop));
Config::ConnectWithoutContext("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Phy/PhyTxDrop", MakeCallback(&PhyTxDrop));

Conform documentației ns avem:

Cei doi contori de PHY se pot referi la: o transmisiune eșuată la nivel fizic din cauza unei coliziuni care a avut loc sau o recepție greșită de preambule din cauza coliziunii care a cauzat detecție de energie, dar nu și decodare corectă a preambulelor de PHY. Contorul de MAC se referă la decizia algoritmului DCF de a nu transmite un pachet pentru că a fost detectată coliziune.

[01] Evolutia parametrilor in functie de CW

NU UITATI sa dati urmatoarele comenzi inainte de a porni la drum: 

cd /home/student/ns-3-dev/examples/ns3-labs
git pull

Rulaţi scriptul pentru ns si nd egale cu 4, 6, 7, 20, 40 (valori egale pentru ns si nd) și pentru CWMin si CWMax egale cu 3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095.

Din moment ce avem valori foarte mari pentru axa Ox (contention window), este indicat sa folosim scara logaritmica pentru axa Ox: 

axis.set_xscale('log')

Construiti grafice in care sa aratati evolutia cumulativa a urmatorilor parametri in functie de dimensiunea CW si comentati graficele:

Graficele și valorile aferente sunt obținute pentru simulationTime=30 secunde. Folosiți graficele ca “referință”, nu le folositi pentru a compara la “virgulă”.

[02] Evolutia parametrilor in functie de CW cu RTS/CTS

Repetați experimentele de la exercitiul 2 activând RTS/CTS si comentati graficele: 

./waf --run "lab7-8-cw --ns=4 --nd=4 --minCw=15 --maxCw=15 --pcap=false --enableRtsCts=true"

Raspundeti la urmatoarele intrebari:

[03] Evolutia parametrilor in functie de CW pentru pachete mici fara RTS/CTS

Repetați experimentele de la exercitiul 2 pentru pachete de 212 octeți (fără RTS/CTS). Comentati graficele. 

./waf --run "lab7-8-cw --ns=4 --nd=4 --minCw=15 --maxCw=15 --pcap=false --enableRtsCts=false --payloadSize=212"

Pentru calculul debitului UDP la livrare, tineti cont de noua dimensiune a payload-ului.

Raspundeti la urmatoarele intrebari:

[04][Bonus] Analiză

Această analiză vă permite să corelați mărimea CW şi dimensiunea/densitatea rețelei. Tendința poate sau nu să fie clară din cauza unor factori cum ar fi interferentele aparute odata cu creșterea densității populatiei etc. Încercați să răspundeți la următoarele întrebări cu privire la graficele obținute mai sus:

Se rulează cu nr = ns = 1, CW=15-1023, și cu o rată suficient de mare (ne asigurăm că phyRate și udpRate au aceleași valori)

  • phyRate - MCS-ul pachetelor de date
  • udpRate - cu ce rata cerem generatorului de pachete să genereze TX
./waf --run "lab7-8-cw --ns=1 --nd=1 --minCw=15 --maxCw=1023 --pcap=false --enableRtsCts=false --udpRate=11000000"

CW nu ar putea funcționa cu un CW fix, CW optim depinde de populație, trafic 

./waf --run "lab7-8-cw --ns=50 --nd=50 --minCw=15 --maxCw=1023"