Laborator 06: Algoritmi Adaptivi MCS

Obiectiv

Laboratorul trecut am studiat evoluția throughputului atunci când stația se îndepărtează de access point fără a apela la metode de compensare. În principiu am observat că scăderea este bruscă de la throughput maxim la 0. În acest laborator ne propunem să vedem cum poate nivelul de MAC să intervină în a compensa cât mai mult pierderile cauzate de mediu și de distanță. O metodă este adaptarea ratelor de TX (tx_rates sau MCS) în funcție de feedbackul primit pe recepție (RSSI - received signal strength indicator, virtual carrier sense, physical carrier sense).

Constelațiile/MCS bogate necesită putere mare, dar funcționează la distanță mai mică așa cum am putut deja observa la laboratorul trecut pentru 54Mbps. Vom vedea la acest laborator comportamentul diverselor constelații ale 802.11g și cum ne ajută anumiți algoritmii adaptivi.

Materiale ajutătoare

În acest laborator vom studia comportamentul a trei algoritmi adaptivi:

  • După cum am menționat mai sus layer-ul de MAC (nivelul legătură de date cum îl mai știți) își ia ca feedback RSSI (sau SNR - Signal to Noise Ratio) pentru a decide MCS-ul folosit la transmisie. Un algoritm destul de simplu care folosește un raport între SNR și BER (Bit Error Rate) este Ideal Rate control algorithm din ns-3, care este implementat conform descrierii din acest paper: mesh-mobicom01.pdf
  • AARF - Adaptive Automatic Rate Feedback (paper: aarf.pdf) - un algortim îmbunătățit al clasicului ARF publicat în 1997 de Bell Labs (paper aici: 06770930.pdf) și care a fost folosit în dongle-uri WiFi 802.11b de la acea vreme. Pe scurt acești algoritmi încearcă din start să folosească cel mai mare MCS suportat de ambii vorbitori iar după două eșecuri să micșoreze treptat. Într-un mod similar, dar cu o implementare proprietară, funcționează algoritmii iwl-mwm-rs din placile Wireless Intel (care au driverul iwlwifi), puteți vedea un paper aici: mswim_2019_1_.pdf. Implementarea AARF în simulatorul ns-3 este descrisă aici.
  • În kernelul de Linux, pentru plăcile care nu implementează în firmware off-loaded un algoritm adaptiv, există algoritmul Minstrel și este folosit de stiva WiFi de networking a Linux. Acest algoritm nu se bazează exclusiv pe feedback-ul RX-ului (e.g. RSSI cum menționam mai sus) ci încearcă să creeze un model statistic de variabile aleatoare care sunt determinate de: număr de biți transmiși, numărul de retransmisii ale unui pachet în aer deja planificat de DCF și probabilitatea estimată de succes a TX-ului în funcție de robustețea MCS-ului ales la acel moment. Minstrel încearcă toate ratele de TX posibile și le elimină pe cele care oferă rezultate proaste. Implementarea Minstrel în simulatorul ns-3 este descrisă aici.

Ce vom face la laborator

Vom folosi o simularea realizată în ns-3 de la laboratorul 5 și vom încerca să amânăm pierderile pachetelor cauzate de către îndepărtarea stației de access point prin adaptarea dinamică a MCS-ului folosită de algoritmii la nivel MAC descriși mai sus.

Taskuri

[00] Pregătirea laboratorului

Dacă vreți să creați folder nou pe calculatoarele voastre:

git clone https://gitlab.com/b12mihai1/ns-3-dev.git ~/ns-3-dev
cd ~/ns-3-dev
git checkout -b isrm_2020 remotes/origin/isrm_2020
git submodule init
git submodule update --remote --merge
git submodule foreach git pull origin master
./waf configure --build-profile=debug --enable-examples --enable-tests && ./waf build -j4

Dacă folosiți mașina virtuală:

student@isrm-vm:~$  cd ~/ns-3-dev

Verificați că sunteți pe branch-ul isrm_2020 din remote-ul https://gitlab.com/b12mihai1/ns-3-dev.git:

student@isrm-vm:~/ns-3-dev$ git remote -v
origin	https://gitlab.com/b12mihai1/ns-3-dev.git (fetch)
origin	https://gitlab.com/b12mihai1/ns-3-dev.git (push)
 
student@isrm-vm:~/ns-3-dev$ git branch -vv
* isrm_2020 5993ca379 [origin/isrm_2020] fix submodules to have https instead of ssh
  master    da1b41ed1 [origin/master] tcp: Ensure that congestion state is set after every notification

Rulați următoarele comenzi pentru update-ul submodului din examples/ns3-labs:

student@isrm-vm:~/ns-3-dev$ git submodule update --remote --merge

Dacă cea de mai sus nu merge alternativ puteți încerca:

student@isrm-vm:~/ns-3-dev$ git submodule foreach git pull origin master

[01] Comparație între MCS-uri fixe versus distanță - trafic UDP

Rulați simularea cu parametrii impliciți schimbând doar phyRate. Folosim ConstantRateWifiManager. Exemplu de rulare pentru 6Mbps:

./waf --run "lab5 --apManager=ns3::ConstantRateWifiManager --phyRate=ErpOfdmRate6Mbps"

Salvați datele obținute, ne interesează să obținem o funcție throughput(distanță) pentru următoarele phyRate: ErpOfdmRate6Mbps, ErpOfdmRate12Mbps, ErpOfdmRate24Mbps, ErpOfdmRate54Mbps. Plotați datele obținute. Ce observăm? De ce credeți că se întâmplă așa?

MCS-urile mai slabe care nu pot înghesui mulți biți de informație într-un simbol sunt mai robuste pe distanțe lungi.

[02] Algoritmi adaptivi - trafic UDP

Păstrați datele obținute la task-ul anterior pentru a putea plota pe același grafic evoluția algoritmilor adaptivi în comparație cu constelațiile. Algoritmii adaptivi nu au nevoie de specificarea parametrului phyRate deoarece ei vor încerca să folosească cel mai bun MCS suportat de ambii vorbitori și îl vor regla treptat în funcție de signal strength și pierderi ale ACK-urilor de L2.

Rulare pentru cei trei algoritmi de interes:

./waf --run "lab5 --apManager=ns3::AarfWifiManager"
./waf --run "lab5 --apManager=ns3::MinstrelWifiManager"
./waf --run "lab5 --apManager=ns3::IdealWifiManager"

[03] Algoritmi adaptivi - evoluția în PCAP

Activați PCAP tracing pentru cei trei algoritmi adaptivi și reluați experimentele. Urmăriți evoluția parametrilor pentru pachetele de date (adica doar pachetele UDP):

  • Signal Strength
  • DataRate
./waf --run "lab5 --apManager=ns3::AarfWifiManager --pcap=true"
./waf --run "lab5 --apManager=ns3::MinstrelWifiManager  --pcap=true"
./waf --run "lab5 --apManager=ns3::IdealWifiManager --pcap=true"

Odata ce ati obtinut capturile, ne vom folosi de tshark pentru a extrage coloanele de timestamp, data rate si signal strength si vom realiza urmatoarele grafice: MCS (data rate) in functie de timestamp, signal strength in functie de timestamp.

Coloanele de interes pentru tshark sunt urmatoarele:

  • Signal Strength (pentru a selecta acest camp puteti folosi identificatorul wlan_radio.signal_dbm)
  • DataRate (pentru a selecta acest camp puteti folosi identificatorul wlan_radio.data_rate)
  • Timestamp (pentru a selecta acest camp puteti folosi identificatorul frame.time_epoch)

Vom extrage aceste coloane doar pentru pachetele UDP. In consecinta, va trebui sa aplicam un filtru: ip.proto == 17.

Pentru mai multe detalii legate de cum puteti parsa un fisier pcap cu tshark, puteti sa va uitati aici.

[04 - optional] Algoritmi adaptivi - trafic TCP

Ne amintim din laboratorul trecut comportamentul TCP cu ns3::ConstantRateWifiManager (deci cu rata fixată). Vom vedea comportamentul TCP-ului cu cei trei algoritmi adaptivi: Ideal, Minstrel și AARF. Exemplu de rulare:

./waf --run "lab5 --apManager=ns3::IdealWifiManager --isTcp=true"
./waf --run "lab5 --apManager=ns3::MinstrelWifiManager --isTcp=true"
./waf --run "lab5 --apManager=ns3::AarfWifiManager --isTcp=true"

Vom obține trei seturi de date pe care ne propunem să le plotăm pe același grafic (luăm datele din outputul simulării și facem tot o funcție throughput(distanță)).

Care algoritm se comportă mai bine în cazul TCP-ului? Care a avut rezultate proaste? Parcurgeți din nou teoria despre cei trei algoritmi și uitați-vă cu atenție pe grafice la comportamentul lor la pierderi (e.g. Minstrel coboară mai rapid la rate mici facând un fel de căutare binară).

isrm/laboratoare/new/06.txt · Last modified: 2020/03/30 22:11 by vlad.traista
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0