Laborator 10: Multiple MCS

Laborator 10: Multiple MCS

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

Topologia din script folosteste standardul 802.11g contine nodurile WiFi 0,1,2,3,4 astfel:

Nodul 0 funcționează ca AP și emite la 12Mbps, iar celelalte noduri sunt clienți cu legături uplink de 6Mbps. Sunt definite patru fluxuri UDP 1→3, 2→4, 4→0, 0→4, toate cu pachete de 1460 de octeți.

Distanțele de la clienți la AP sunt de 5 m, RTS este dezactivat.

Scriptul necesită următorii parametri pe linia de comandă:

–rate13=<rate> indică rata oferită pentru fluxul 1→3
–rate24=<rate> indică rata oferită pentru fluxul 2→4
–rate40=<rate> indică rata oferită pentru fluxul 4→0
–rate04=<rate> indică rata oferită pentru fluxul 0→4

Exemplu de rulare:

./waf --run "lab10 --rate13=1000000 --rate24=1000000 --rate40=0 --rate04=0 --packetSize=1460 --simTime=100"

Valorile implicite pentru parametrii de mai sus sunt:

int rate13 = 7000000;
int rate24 = 7000000;
int rate40 = 7000000;
int rate04 = 0;

Există momentan o limitare in script care nu permite simultan 2 flow-uri către nodul 4. Deci rate 2→4 și rate 0→4 nu pot avea simultan valori diferite de 0.

[01] Capacitatea maxima in aer

Să se calculeze capacitatea maximă a aerului în bps si pps pentru fluxurile 0→4 si 4→0 luate în izolare. Cât durează transmiterea unui cadru de la stații (in cazul fluxului 4→0)? Dar de la AP (in cazul fluxului 0→4)?

Pentru a calcula capacitatea maxima a aerului, rata de transmisie a fluxului UDP trebuie sa fie cel putin egala cu valorea MCS-ului, iar dimensiunea pachetului cat mai mare e.g. 1460 bytes.

De asemenea, rulati cu simTime=100 secunde pentru a crea echitate pe termen lung.

Conversia din bps (bits per second) în pps (packets per second) se face după formula:

$ BPS = PPS \cdot (packetSize \cdot 8 ) $ bits

Pentru fluxul 0 → 4:

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=0 --rate24=0 --rate40=0 --rate04=13000000 --packetSize=1460 --simTime=100"
Waf: Entering directory `/home/student/ns-3-dev/build'
Waf: Leaving directory `/home/student/ns-3-dev/build'
Build commands will be stored in build/compile_commands.json
'build' finished successfully (43.162s)
[UDP TRAFFIC] src=0 dst=4 rate=13000000bps
Flow 1 (10.1.1.1 -> 10.1.1.5)
  Tx Packets: 109743
  Tx Bytes:   163297584
  TxOffered:  13.2496 Mbps
  Rx Packets: 81973
  Rx Bytes:   121975824
  lostPackets:   26669
  Throughput: 9.89682 Mbps

Obținem:

9.89682 Mbps
Folosim formula mentionata mai sus pentru a obține pps: 9.896 * 10^6 / (1460 * 8) = 847 pps
Un cadru durează: 1000/847 → aproximativ 1.18 milisecunde
Daca ati rulat cu PCAP tracing activat, putem sa ne uitam si in fișierul lab10-multirate-4-0.pcap. Luăm orice pachet UDP din el și ne uităm la câmpul duration din 802.11 radio information si observăm valoarea 1040 microsecunde, deci 1.04 milisecunde (apropiata de valoarea obtinuta prin calcul).

Pentru fluxul 4 → 0:

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=0 --rate24=0 --rate40=13000000 --rate04=0 --packetSize=1460 --simTime=100"
Waf: Entering directory `/home/student/ns-3-dev/build'
Waf: Leaving directory `/home/student/ns-3-dev/build'
Build commands will be stored in build/compile_commands.json
'build' finished successfully (3.607s)
[UDP TRAFFIC] src=4 dst=0 rate=13000000bps
Flow 1 (10.1.1.5 -> 10.1.1.1)
  Tx Packets: 110188
  Tx Bytes:   163959744
  TxOffered:  13.2496 Mbps
  Rx Packets: 44222
  Rx Bytes:   65802336
  lostPackets:   64865
  Throughput: 5.31748 Mbps

Obținem:

5.31748 Mbps
Folosim formula mentionata mai sus pentru a obține pps: 5.317 * 10^6 / (1460 * 8) = 455 pps
Un cadru durează: 1000/455 → aproximativ 2.19 milisecunde
Daca ati rulat cu PCAP tracing activat, putem sa ne uitam si in fișierul lab10-multirate-4-4.pcap. Luăm orice pachet UDP din el și ne uităm la câmpul duration din 802.11 radio information si observăm valoarea 2056 microsecunde, deci 2.05 milisecunde (apropiata de valoarea obtinuta prin calcul).

[02] Capacitatea maxima in aer end-to-end

[02a] Throughput end-to-end

Dacă doar fluxul 0 (1→3) este activ, ce throughput se obține end to end?

Comunicarea din cadrul fluxului 0 se face intre 2 statii si este intermediata de AP. Statia 1 va transmite catre AP cu MCS-ul de 6Mbps in timp ce AP-ul va transmite catre statia 3 cu MCS-ul de 12Mbps.

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=13000000 --rate24=0 --rate40=0 --rate04=0 --packetSize=1460 --simTime=100"
Waf: Entering directory `/home/student/ns-3-dev/build'
Waf: Leaving directory `/home/student/ns-3-dev/build'
Build commands will be stored in build/compile_commands.json
'build' finished successfully (3.499s)
[UDP TRAFFIC] src=1 dst=3 rate=13000000bps
Flow 1 (10.1.1.2 -> 10.1.1.4)
  Tx Packets: 109854
  Tx Bytes:   163462752
  TxOffered:  13.2494 Mbps
  Rx Packets: 27983
  Rx Bytes:   41638704
  lostPackets:   80771
  Throughput: 3.37501 Mbps

Avem 3.375 * 10^6 / (1460 * 8) = 289 pps.

[02b] Rata de coliziuni

Care este rata coliziunilor (cps)? Cât durează o coliziune?

Pentru a vedea cate coliziuni avem, rulati scriptul in maniera urmatoare:

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=13000000 --rate24=0 --rate40=0 --rate04=0 --packetSize=1460 --simTime=100 --enableChannelAccessManagerLogging=true" 2>&1 | grep "medium is busy: collision" | wc -l
736

Motivul pentru care nu ne folosim de statisticile de MacTxDropCount, PhyTxDropCount sau PhyRxDropCount este pentru ca acestea contorizeaza si alte cauze de drop de pachete pe langa coliziuni. In schimb, ne folosim de logurile interne ChannelAccessManager ale ns3 pentru a numara coliziunile. Mai precis, vom numara liniile care contin urmatoarea structura de cuvinte: medium is busy: collision.

Vom obtine 736 coliziuni pe parcursul a 100 de secunde ceea ce inseamna o rata de coliziuni de aproximativ 7 cps.

Deoarece toate dispozitive sunt în CS, nu avem terminale ascunse, iar coliziunile sunt cauzate de fereastra de contenție. Avem 2 transmițători: AP și stația 1, ce emit cadre de lungimi diferite. O coliziune durează până la sfârșitul cadrului cel mai lung (802.11 nu are CSMA/CD). Astfel, durata coliziunilor dintr-o secunda este: 2.19 ms * 7 = 15.33 ms ceea ce inseamna ca dintr-o secunda (1000 ms), 1.53% din timp este irosit de coliziuni.

[02c] Justificarea ratei de coliziuni

Pentru a vedea daca valoarea ratei de coliziuni este (aproximativ) corecta, trebuie sa vedem care este compozitia cadrelor in aer. Altfel spus, trebuie să aflăm câte cadre din fiecare tip se află în aer într-o secundă.

Fiecare emițător câștigă aceleași oportunități de transmisie pe termen lung (reminder de la laboratorul de echitate). Acest lucru inseamna ca fiecare emitator va emite x cadre pe secundă, dar fiecare îl ține ocupat în funcție de MCS folosit: (6Mbps, 12Mbps) $ R_1 = 455pps, R_2 = 847pps$. În plus mai avem și C coliziuni pe secundă.

Exprimarea matematica a ideii de mai sus este urmatoarea: $$ \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$ $$ x = \left(1-\frac{C}{R_1}\right)\frac{R_1R_2}{R_1+R_2} = \frac{{R_2}({R_1} - {C})}{R_1+R_2} = 291 pps$$.

Convertim pps in Mbps si o sa obtinem urmatoarea valoare: 291 * 1460 * 8 = 3.398 Mbps, consistent cu ce am obținut în simulare (3.375 Mbps).

Compozitia cadrelor din aer este urmatoarea:

Stația 1 ocupă PPS_FLUX_1_3 * DURATA_PACHET_TRIMIS_DE_STATIA_1 = 289 * 2.19 = 633 ms → 63% din timp
AP ocupă PPS_FLUX_1_3 * DURATA_PACHET_TRIMIS_DE_AP = 289 * 1.18 = 341 ms → 34% din timp
coliziuni, restul de 3% din timp (in simulare am obtinut 1.3 % din timp, o valoare relativ apropiata de 3%).
Coada de pachete este probabil mereu goală în AP și în creștere la stație, deoarece se generează mai mult decât se poate emite.

[03] Capacitatea maxima in aer cu 2 fluxuri end-to-end

[03a] Throughput, pps si cps

Ce valori de throughput, pps si cps obtinem atunci cand activam fluxurile 0 si 1 (1 → 3 si 2 → 4)?

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=13000000 --rate24=13000000 --rate40=0 --rate04=0 --packetSize=1460 --simTime=100" 
Waf: Entering directory `/home/student/ns-3-dev/build'
Waf: Leaving directory `/home/student/ns-3-dev/build'
Build commands will be stored in build/compile_commands.json
'build' finished successfully (3.503s)
[UDP TRAFFIC] src=1 dst=3 rate=13000000bps
[UDP TRAFFIC] src=2 dst=4 rate=13000000bps
Flow 1 (10.1.1.2 -> 10.1.1.4)
  Tx Packets: 109854
  Tx Bytes:   163462752
  TxOffered:  13.2507 Mbps
  Rx Packets: 8674
  Rx Bytes:   12906912
  lostPackets:   99500
  Throughput: 1.04626 Mbps
Flow 2 (10.1.1.3 -> 10.1.1.5)
  Tx Packets: 109743
  Tx Bytes:   163297584
  TxOffered:  13.252 Mbps
  Rx Packets: 8705
  Rx Bytes:   12953040
  lostPackets:   99417
  Throughput: 1.05117 Mbps

Pentru ambele fluxuri, obtinem un throughput de 1.05 Mbps ceea ce rezulta in 1.05 * 10^6 / (1460 * 8) pps = 90 pps.

Pentru a determina numarul de coliziuni, rulam:

student@isrm-vm:~/ns-3-dev$ ./waf --run "lab10 --rate13=13000000 --rate24=13000000 --rate40=0 --rate04=0 --packetSize=1460 --simTime=100 --enableChannelAccessManagerLogging=true" 2>&1 | grep "medium is busy: collision" | wc -l
887

Asadar, obtinem 887 coliziuni pe parcursul a 100 de secunde ⇒ 9 cps.

[03b] Justificarea ratei de coliziuni

Dacă se transmite un maximum de la fiecare sursă (1 și 2), AP-ul va avea de retransmis pentru ambele, dar nu câștigă mediul decât în 1/3 din arbitrări, deși cadrele lui sunt mai scurte.

$$ \frac{x}{R_1} + \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$

Ce este diferit față de cazul precedent este că toți cei trei emițători sunt saturați, AP-ul însă nu dirijează decât $ \frac{x}{2} $ pentru fiecare flux, iar restul este pierdut.

$$ x = \left(1 - \frac{C}{R_1}\right)\frac{R_1 R_2}{R_1+2 R_2} = \frac{{R_2}({R_1} - {C})}{R_1+2R_2} = 175 pps$$

Dar debitul obținut pentru fiecare flux este doar $x/2$ = 87pps, adică 1.01 Mbps.

Stația 1 ocupă 175 * 2.19 ms = 383.25 ms → 38.3% din timp
Stația 2 ocupă 175 * 2.19 ms = 383.25 ms → 38.3% din timp
AP ocupă 175 * 1.18 ms = 206.5 ms → 20.6% din timp
Coliziuni - 2.8% din timp (am obtinut anterior 1.9%, o valoare relativ apropiata de 2.8%)
In concluzie, 38.3% din timp este irosit pentru a transmite prin aer cadre care vor fi aruncate la AP!

[03c] Obținerea unui throughput mai mare

Cum obținem mai mult de 1.04Mbps + 1.04Mbps în experimentul de la 3b?

Table of Contents