• Pentru cei curioși, mai ales pentru matematica din spate, recomandăm, pentru acest laborator, capitolul 2 din cartea Wireless Communications - Andrea Goldsmith
• Celor curioși cu privire la bazele mecanismelor de retransmisie din TCP recomandăm capitolul 21 din TCP Illustrated

Acest model calculează puterea la receptor după următoarea formulă descrisă în pagina ns-3

Atributele pe care le putem controla din ns-3 sunt: exponentul, distanța de referință la care atenuarea e calculată și atenuarea de referință.

Este la fel ca log distance însă folosește trei exponenți diferiți pentru “near, middle, far”. Este descris matematic aici. ns-3 ne oferă posibilitatea de a configura distanțele și exponenții pentru “near, middle, far” și atenuarea de referință.

Este o generalizare a modelului popular Rayleigh (îl găsiți și în Goldsmith - TODO pagina). Descrierea lui este aici, dar și în paper-ul scris de M. Nakagami: nakagami1960.pdf.

https://www.nsnam.org/doxygen/classns3_1_1_friis_propagation_loss_model.html#details

Ce arme are un transmițător la dispoziție pentru a combate acest fenomen:

• puterea de transmisie (măsurată de obicei în dbm - în PCAP-uri Wifi sau iwconfig este Tx Power)
• MCS-ul de transmisie - cu cât e mai prost cu atât e mai robust la shadowing, dar penalizarea e de performanță (nu vei avea throughput mare cu MCS mic)

Ce arme are un receptor la dispoziție pentru a combate acest fenomen:

• AGC (automatic gain control)
• capacitatea de a decoda un MCS mare (802.11ac a introdus LDPC coding - o tehnică mai bună de codare a datelor decât cele tradiționale)

Ce arme au atât transmițătorul, cât și receptorul pentru a combate ambele fenomene: MIMO (Multiple Input, Multiple Output) - folosirea de mai multe antene la transmisie și recepție (la 802.11ac avem un maxim de 4×4) și STBC (Space Time Block Coding) - o tehnică de a transmite mai multe copii ale unui stream de date pe mai multe antene pentru a asigura fiabilitatea datelor transmise. Cele două capabilități sunt advertised de AP (access point) în beacon, iar stațiile îi transmit AP-ului dacă le au în cadrul probe request-ului.

Vom folosi o simulare realizată în ns-3 care ne permite să schimbăm între 4 modele de propagare. Vom alege pe rand cate unul din modele.

Opțional/Bonus: Dacă vreți puteți modifica punctual codul sursă pentru a vă juca cu unii parametrii și a observa comportamentul modelului de propagare a semnalelor.

După aceasta ne vom concentra pe un singur model de propagare și vom vedea cum se comportă traficul TCP sau UDP în anumite condiții suplimentare ce nu țin de mediu.

1. citiți toate cerințele din secțiunea Task-uri de mai jos înainte de a decide un plan de măsurători. Strategia optimă este de a extrage mai mulți parametri în urma unei simulări pentru a putea răspunde mai multor cerințe.
2. decideți structura fișierului text care va conține datele din care se pot produce graficele cerute.
   • ce avem pe axele x, y?
   • ce reprezintă fiecare coloană?
   • ce parametri se pot obține ca o funcție de coloane? Exemplu $probabilitate_{livrare} = primite/trimise$
   • ce grafice au axe care nu corespund direct unoar coloane din fișierul generat? cum se pot obține acele axe?
3. prelucrați output-ul obtinut in urma rularilor succesive pentru a obține un fișier text de date intermediare cu semnificații clare pentru linii și coloane. Exemplu: fiecare linie e pentru o distanță, fiecare coloană e un counter de cadre sau un debit în Mbps

student@isrm:~$ git clone https://gitlab.com/b12mihai1/ns-3-dev.git
student@isrm:~$ cd ns-3-dev/
student@isrm:~/ns-3-dev$ git checkout -b isrm_2020 remotes/origin/isrm_2020
student@isrm:~/ns-3-dev$ git submodule update --init --recursive
student@isrm:~/ns-3-dev$ cd scratch/
student@isrm:~/ns-3-dev/scratch$ ln -s ../examples/ns3-labs/lab-05-06-mcs/lab5.cc lab5.cc
student@isrm:~/ns-3-dev/scratch$ cd ..
student@isrm:~/ns-3-dev$ ./waf configure --build-profile=debug --enable-examples --enable-tests && ./waf build -j4
student@isrm:~/ns-3-dev$ ./waf --run "lab5 --apManager=ns3::ConstantRateWifiManager --phyRate=ErpOfdmRate54Mbps --propagationModel=0"

Parametrii pe care simularea noastră îi primește:

cmd.AddValue("phyRate", "Wifi Phy Rate (MCS) for DATA Packets in case of constant wifi", phyRate);
cmd.AddValue("apManager", "Adaptive algorithm to be used", apManager);
cmd.AddValue("stepsSize", "How many meters each iteration STA goes away", stepsSize);
cmd.AddValue("steps", "How many different distances to try", steps);
cmd.AddValue("stepsTime", "Time on each step", stepsTime);
cmd.AddValue("isTcp", "If true is TCP traffic if false is UDP", isTcp);
cmd.AddValue("useRtsCts", "toggle usage of RTS/CTS", useRtsCts);
cmd.AddValue("propagationModel", "Pick propagation model, refer to enum class PropagationModel for values", propagationModel);
cmd.AddValue("pcap", "Enable/disable PCAP Tracing", pcapTracing);
cmd.AddValue("tries", "Max number of attempts to send frame (Short and Long Retry limit for station)", tries);

Pentru a realiza grafice, trebuie sa instalam si pachetele de Python:

student@isrm-vm-2020:~$ sudo apt-get update
student@isrm-vm-2020:~$ sudo apt-get install python3-pip
student@isrm-vm-2020:~$ pip3 install matplotlib jupyter
student@isrm-vm-2020:~$ sudo ln -s ~/.local/bin/jupyter-notebook /usr/bin/jupyter-notebook

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

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

Pentru acest task ne propunem să vedem evoluția throughputului în funcție de distanță. Implicit modelul pornește de la o distanță de 20 de metri între noduri și la fiecare secundă crește cu parametrul stepSize (implicit 5 metri). Scenariul din viața reală e simplu: un utilizator cu telefon conectat la un access point într-un mediu în care are clădiri, pereți, geamuri etc. și se deplasează în acest mediu în timp ce face video streaming.

AP-ul nu are algoritmi adaptivi, modelul este 802.11g așadar vom cere modelului să încerce cea mai mare rată suportată de acest standard - 54 Mbps. Modelul se schimbă prin setarea unui întreg conform schemei de mai jos:

enum PropagationModel {
  NAKAGAMI_3LOG = 0,
  LOG_DIST_LOSS = 1,
  THREE_LOG_DIST = 2,
  FRIIS = 3
};

Exemplu de rulare pentru Friis:

./waf --run "lab5 --apManager=ns3::ConstantRateWifiManager --phyRate=ErpOfdmRate54Mbps --propagationModel=3" 

Sarcina voastră este să plotați pe axa X distanța și pe axa Y throughput în Mbps - deci funcția throughput(distanță) pentru cele 4 modele prezentate mai sus în laborator.

Plotați packet delivery ratio la nivel fizic (tries=1) și la nivel MAC (tries=4,10) pentru distanțele implicite din model, pentru trafic UDP.

Pentru tries=1 alegeți ultimele două coloane pentru a contoriza pachetele trimise/primite - sunt extrase la nivel PHY. Pentru tries=4,10 alegeți penultimele două coloane pentru a contoriza pachetele trimise/primite - sunt extrase la nivel MAC.

/* STA long retry count - relevant for DATA packets - how many retransmits for DATA */
Config::SetDefault ("ns3::WifiRemoteStationManager::MaxSlrc", UintegerValue (tries));
/* STA short retry count - relevant for RTS/CTS - max number of attempts for RTS packets */
Config::SetDefault ("ns3::WifiRemoteStationManager::MaxSsrc", UintegerValue (tries));

Plotați capacitatea obținută de TCP pentru tries=1 la distanțe implicite din model. Justificați relația cu graficele precedente.

• De ce la tries=1 (nu se reîncearcă), TCP nu atinge capacitatea maximă chiar când canalul este perfect, de exemplu la 20 m?
• Activați RTS/CTS pentru acest caz (tries=1). De ce nu se îmbunătățește situația TCP-ului?

Plotați capacitatea obținută de TCP pentru tries=4, 10. Explicați diferențele față de comportarea UDP în același setup. Observație: Capacitatea TCP crește când reîncercările la nivel MAC ascund pierderile.

Bonus: Vă puteți adăuga trace pentru pachete pierdute la nivel MAC în simulare astfel (vedeți și documentația ns-3 - All TraceSources):

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

Pe callbackurile mai sus definiți două funcții simple care incrementează un contor global. Cu acest tracing: Analizați pachetele pierdute și justificați folosind timpii de emisie ai pachetelor.

Repetați experimentele cu TCP și UDP activând PCAP tracing. Urmăriți în PCAP momentul în care transmițătorul pachetelor de date UDP/TCP (adică AP-ul) nu mai primește ACK-urile de L2:

• Cum reacționează TCP în acel caz, dar UDP?
• Ce parametru observați că se schimbă în PCAP? Ce puteți spune despre puterea semnalului la recepție în acest caz?