• Standardul IEEE 802.11 - secțiunile 10.3, 10.3.2.1 - 10.3.2.5
• Next Generation Wireless - secțiunea 7.3.

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:

• $aSlotTime$ - durata altor IFS (inter-frame spacing) este egală cu SIFS plus un număr de slot times. Propagarea cadrelor la nivel de PHY poate cauza ca unele stații să vadă limita terminării unui cadru (frame) la un alt moment de timp decât altele. Aici intervine rolul aSlotTime - se alege o valoare suficient de mare prin care toate stațiile participante la comunicația Wifi să detecteze preambulele de PHY ale stațiilor vecine. Pe parcursul fiecărui aSlotTime stațiile stau în modul receptor și așteaptă finalizarea propagării cadrelor pe aer. aSlotTime e o valoare dependentă de tipul de PHY (DSSS, OFDM, ERP etc.) și, în general, pentru protocoalele 802.11a/g/n găsim valoarea de 9 microsecunde. Figura de mai jos vă arată pentru diferite tipuri de cadre wifi (management - beacon, probe request, date, ack la nivel de wifi) cum se face spațierea pe aer:

• $Random()$ - o funcție care întoarce un număr pseudorandom distribuit uniform în intervalul $[0, CW]$.
  • $CW$ - este contention window, un număr întreg care poate lua valori în intervalul $[aCWmin, aCWmax]$. Cele două valori depind de tipul de PHY. În standardul IEEE 802.11 găsim atât aSlotTime, cât și aCWmin și aCWmax în tabele care depind de tipul de PHY: tabelul 15-5 ne dă valori pentru PHY de tipul DSSS (întâlnit la 802.11b), tabelul 17-21 ne dă pentru OFDM, tabelul 18-5 pentru ERP. În acest laborator vom simula cu niște valori alese de noi pentru 802.11b care are PHY de tip DSSS.

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.

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

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:

• ns numărul de surse
• nd numărul de destinații
• minCw pentru a indica limita minima a ferestrei de arbitraj/contenție
• maxCw pentru a indica limita maxima a ferestrei de arbitraj/contenție
• enableRtsCts pentru a activa mecanismul de RTS/CTS

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

• sent_agt - numărul total de pachete trimise toate nodurile transmițătoare (ns). Pentru a obține această statistică s-a folosit mecanismul de flow monitor din ns-3
• recv_agt - numărul total de pachete recepționate cu succes de către toate nodurile destinație (nd), statistică obținută tot cu flow monitor
• col_cbr - numărul total de coliziuni care au avut loc pe parcursul traficului UDP schimbat între noduri. Această statistică e obținută din mecanismul de tracing al ns pe WifiDevice:

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:

• PhyTxDrop: Trace source indicating a packet has been dropped by the device during transmission
• PhyRxDrop: Trace source indicating a packet has been dropped by the device during reception
• MacTxDrop: A packet has been dropped in the MAC layer before transmission.

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.

• sent_mac, recv_mac - pachete recepționate la nivel MAC (care au ajuns mai sus în stiva nodului, dar poate stiva a decis să îl arunce - e.g. adresă IP greșită). Aceștia sunt obținuți tot din mecanismul de tracing al WifiDevice din ns-3:
  • MacRx: A packet has been received by this device, has been passed up from the physical layer and is being forwarded up the local protocol stack. This is a non-promiscuous trace.
  • MacTx: A packet has been received from higher layers and is being processed in preparation for queueing for transmission.
• udpAverageThroughput - debitul mediu cumulat pentru toate flow-urile care au schimbat pachete

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:

• total pachete livrate la destinație (recv_agt)

• rata CBR livrată la destinație [Mbps] (recv_agt * payload_size * 8 / (25 * 10**6))

• probabilitatea de livrare (PDR) la nivel agent (recv_agt / sent_agt)

• probabilitatea de livrare (PDR) la nivel MAC (recv_mac / sent_mac)

• numărul de pachete unice de date emise de MAC (sent_mac)

• numărul de pachete unice de date emise de agent (sent_agt)

• numărul de coliziuni pe secundă [pps] (col_cbr)

• numărul de retransmisiuni per cadru (sent_mac / recv_agt)

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:

• ce s-a întâmplat cu coliziunile? Comentați.
• de ce pachete UDP emise de MAC arată similar cu cele de capacitate? (o explicație este că o dată capturat aerul, pachetul reușește mereu să fie transmis.)

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"

Raspundeti la urmatoarele intrebari:

• de ce numărul de cadre emise în aer este mai mare decât la pachete mari?
• cât durează un cadru de date?

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:

• care este capacitatea rețelei în cadre/secundă? Dar în bps? Pentru a valida acest rezultat examinați în script rata folosită la nivelul fizic, parametrii UDP (CBR) și dimensiunea pachetelor.

./waf --run "lab7-8-cw --ns=1 --nd=1 --minCw=15 --maxCw=1023 --pcap=false --enableRtsCts=false --udpRate=11000000"

• ce tendințe ați observat? Există o dimensiune optimă CW pentru fiecare populație de rețea? Ce relație există între dimensiunea optimă și populația rețelei?

• puteți prezice ce se va întâmpla dacă încercați să rulați acest script pentru ns = nr = 50 și CW de 802.11b (CW=15-1023)? Explicați și apoi rulați:

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

• rata de livrare la nivel UDP nu atinge mereu 100%. Cum este totuși posibilă ocuparea capacității maxime a aerului?
• numărul de cadre emise de MAC (Layer 2) este mai mare decât numărul de pachete generate de agentul UDP (packet sink din setup_udp_traffic). De ce?
• probabilitatea de livrare la MAC este șansa unui pachet de a supraviețui în aer. Când aceasta este 1, suntem în situația ideală. De ce rata livrării la agentul UDP se comportă radical diferit pentru populația 4 (ns=nr=4) față de celelalte populații?
• care este numărul de încercări per pachet obținut de standardul 802.11? Comentați.