This is an old revision of the document!
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).
În acest laborator vom studia comportamentul a trei algoritmi adaptivi:
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. 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.
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
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?
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"
Activați PCAP tracing pentru cei trei algoritmi adaptivi și reluați experimentele. Urmăriți evoluția parametrilor pentru pachetele de date (puneți filtru TODO de UDP):
./waf --run "lab5 --apManager=ns3::AarfWifiManager --isPcap=true" ./waf --run "lab5 --apManager=ns3::MinstrelWifiManager --isPcap=true" ./waf --run "lab5 --apManager=ns3::IdealWifiManager --isPcap=true"
TODO: task sa foloseasca tshark pentru a plota o funcție MCS(distanță) sau MCS(timestamp) și să compare cu taskul 2
Ne amintim laboratorul trecut comportamentul TCP cu ns3::ConstantRateWifiManager
(deci cu rata fixată) și un singur număr de reîncercări era foarte prost. Hai să repetăm experimentul pentru tries=1,4,7
și să vedem comportamentul TCP-ului cu cei trei algoritmi adaptivi: Ideal, Minstrel și AARF. Exemplu de rulare:
./waf --run "lab5 --apManager=ns3::IdealWifiManager --isTcp=true --tries=1" ./waf --run "lab5 --apManager=ns3::MinstrelWifiManager --isTcp=true --tries=1" ./waf --run "lab5 --apManager=ns3::AarfWifiManager --isTcp=true --tries=1"
Vom obține două 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 cu tries=1
, care a avut rezultate proaste . Parcurgeți din nou teoria despre cei doi 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ă).
Ce se întamplă atunci când tries=7
, cum se comportă cei doi algoritmi?