Scopul acestui laborator este de a înțelege conceptul de Carrier-Sensing în 802.11 și de a compara mecanismele fizic și virtual de a testa prezența purtătoarei.

Carrier Sense la nivel fizic este folosit atunci când un nod care vrea să transmită mai întâi evaluează starea canalului. Dacă energia detectată este peste un anumit prag, numit Carrier sense threshold, canalul este declarat ocupat, iar nodul trebuie să aștepte. Altfel, canalul este considerat liber, și nodul poate începe transmisia.

În contrast, CS virtual folosește indicațiile NAV (Network Allocation Vector) pentru a estima cât timp este mediul ocupat. În principiu, o stație recepționează toate cadrele, inclusiv cele care nu îi sunt adresate explicit. Fiecare cadru conține în câmpul Duration din antetul 802.11 o estimare a duratei conversației din care face parte. Bibliografie pentru NAV: Sec 7.5.1 din Perahia - Next generation wireless

Vedeți mai jos o captura a unui pachet wifi - unde vedem câmpul Duration

Un mod explicit de rezervare a mediului se face prin intermefdiul pachetelor RTS/CTS. Emițătorul trimite RTS, iar receptorul răspunde cu CTS. În pașii 3 și 4 se transmit datele și confirmarea ACK în modul obișnuit. Diferența este acum că nodurile vecine au ocazia să estimeze durata conversației în 4 pași prin citirea câmpului Duration fie din RTS, fie din CTS.

Mai multe explicații despre RTS/CTS puteți citi:

• pe mrnccview
• Sec 7.5.1.1 RTS/CTS frame exchange din Perahia - Next generation wireless

În ns2 se folosește următorul pseudocod pentru recepția cadrelor de la distanța d în condițiile în care mai poate apărea un cadru de la distanța d1:

recepție(d)
{ 
   if(alt_cadru(d1) && (d1 < CS)){
       if(P(d) - P(d1) >= 10dB)
           captură()
       else
           coliziune()
   } else { 
       recepție OK...
   }
}

Pentru experimente se consideră topologia din dreapta. Nodul A transmite pachete cu flux constant CBR către nodul B, iar D transmite către C. Descărcați scriptul twoflows.tcl care primește următorii parametri:

ns twoflows.tcl -RTSthresh {RTS_Threshold} \
     -CSthresh {carrier-sense threshold} \
     -dist {x} \
     -sendingRate {rate}

Cadrele cu lungime mai mare decât RTSthresh vor folosi RTS/CTS. Prin setarea acestui parametru la o valoare mare (3000) se dezactivează RTS/CTS. Setând acest parametru la 1 garantează folosirea RTS/CTS pentru toate cadrele. În scriptul furnizat se folosesc parametrii CSThresh_ și RXThresh_ pentru nivelele de putere în wați pentru CS și recepție respectiv. Setările de bază în ns2 corespund la 250m pentru recepție, și 550m pentru CS. În acest laborator nu vom schimba nivelul pragului de recepție, ci doar pe cel de CS, folosind parametrul din linia de comandă. Astfel, CSThresh=250m corespunde dezactivării CS fizic. Pentru a obține nivelele de putere corespunzând diverselor distanțe, se poate folosi utilitarul

/opt/ns/ns-2.34/indep-utils/propagation/threshold -m TwoRayGround [distanță_metri]

cu modelul TwoRayGround și păstrând toți ceilalți parametri la valorile default. Unele dintre aceste valori sunt deja calculate în scriptul twoflows.tcl (sunt comentate).

Pentru fiecare valoare CSThresh, rulați simularea dezactivând RTS/CTS pentru valori x=100m, 200m, 300m, si pentru fiecare valoare CSThresh corespunzătoare distanțelor 250m, 300m, 400m, 550m. Atenție, scriptul cere valoarea CSThresh în watți, nu în dBm, și nici în metri. $$ 1mW = 10^{-6}W\\ dBm = 10\log_{10}{mW} \\ mW =10^{\frac{dBm}{10}} $$

În utilitarul POSIX bc, aceste formule se pot exprima astfel:

student@isrm-vm:~$ dBm=24
# atenție: bc nu acceptă formatul IEEE 3.5e-7 acceptat de tcl/C++
student@isrm-vm:~$ mW=3.5*10^-7 
student@isrm-vm:~$ echo "e($dBm/10*l(10))" | bc -l 
# adică 24dBm = 1258.92mW (1.25892W)
student@isrm-vm:~$ echo "10*l($mW)/l(10)" | bc -l
# adică 3.5e-7mW = -64.5dBm  

Repetați toate experimentele și pentru cazul în care RTS/CTS este activat pentru toate cadrele. Pentru fiecare situație, calulați debitul și numărul de pachete trimise/primite la nivel UDP. Folosiți indicațiile din laboratorul precedent pentru a sintetiza aceste statistici din fișierul trace rezultat în urma simulării. Din comenzile folosite în laboratorul trecut:

• numărul de pachete trimise la nivel UDP de către toate nodurile.

cat fișier.tr | grep AGT | grep ^s |grep cbr | wc -l

• Pentru a obţine numărul de pachete primite, aveţi posibilitatea să utilizaţi o comandă similară:

cat fișier.tr | grep AGT | grep ^r |grep cbr | wc -l

• numărul de pachete trimise în mediu de către toate nodurile.

cat fișier.tr | grep MAC | grep ^s |grep cbr | wc -l

• numărul global de pachete de date (CBR) care au intrat în coliziune.

cat fișier.tr | grep COL | grep ^d |grep cbr | wc -l

• Deasemenea, calculați numărul de coliziuni pentru date și pentru non-date. De exemplu, pentru a calcula coliziunile cadrelor care nu conțin date (CBR), folosiți

cat fișier.tr | grep COL | grep ^d |grep -v cbr | wc -l

Cumulați toate rezultatele fie în tabele, fie în grafuri cu bare. Încercați să explicați fiecare număr obținut.

IEEE 802.11 se bazează în principal pe două mecanisme pentru a combate interferența: CS la nivel fizic și la nivel virtual. În ce măsură sunt capabile aceste mecanisme de a rezolva conflictele dintre stații aflate în diverse configurații geometrice? În ns-2, un cadru este recepționat corect atunci când nivelul interferenței de la alte cadre este sub 10dB. Folosind utilitarul /opt/ns/ns-2.34/indep-utils/propagation/threshold, puteți calcula puterea recepționată la o anumită distanță. De exemplu, două cadre primite de la 200 metri și 200*sqrt(2) ($200 \cdot \sqrt{2}$) metri vor fi distruse, întrucât puterile sunt de 8.9e-10W respectiv 2.2e-10W. Pe de altă parte, dintre două cadre primite de la 200m și 360m, cel de la 200m va fi primit corect prin efectul de captură. La 355.7m avem exact 10dBm fata de 200m. Puteți folosi utilitare online pentru a lucra cu dBm.

Teorema lui Pitagora

echo "sqrt(200^2 + 300^2)" | bc -l 

Fiecare experiment este caracterizat de distanța x dintre nodurile B și D, și de distanța la care CS fizic este activ. Justificați valorile obținute pentru: debit, numărul de cadre trimise de MAC, numărul de coliziuni date, numărul de coliziuni non-date.

• Care este capacitatea maximă a canalului în pps (pachete/sec), bps (biți/sec)? ¹⁾
• Ce rată de transmisie folosiți pentru agentul UDP emitent? ²⁾
• În ce măsură schimbul RTS/CTS afectează capacitatea sistemului? ³⁾
• Explicați fiecare valoare obținută.
  • x=100m CS=250m (inactiv). Ce debit total ați obținut? De ce nu este maxim? ⁴⁾ De ce nu este 0 ⁵⁾?
  • x=100m CS=550m. Ce debit total ați obținut? De ce nu este maxim? De ce este exact ….? ⁶⁾
  • x=200m CS=250m (inactiv). Ce diferență cantitativă este față de cazurile precedente? Dar calitativă?
  • x=300m CS=400m. De ce există coliziuni?
  • Cu RTS: de ce exista cazuri in care mai avem coliziuni de date?
  • Atenție: sunt 3 geometrii (x=100, 200, 300) și 4 cercuri de CS (250/off, 300, 400, 500) - deci un total de 12 situații diferite. Justificați fiecare valoare obținută.

• Când este benefic CS virtual, și când CS fizic?
• În unele situatii se foloseste atât CS fizic, cât și virtual. Puteți garanta evitarea completă a coliziunilor atunci când ambele mecanisme sunt activate?
• Găsiți un exemplu de inechitate (CSThresh=?, x=?, debit=?)
• Refaceti xperimentele pentru cadre de dimensiune mica (32 de octeti). Ce se observa?
• Modificați topologia inițială pentru a avea A, B, C coliniare (D rămâne la fel). Rulați aceleași experimente și explicați coliziunile la RTS și la date.

Să considerăm topologi a din dreapta:

Distanțele AB, BC, AC, and CD sunt toate de 200m. Avem un obstacol între A și C care nu permite propagarea radio (greu de realizat în ns2, deoarece AD=346m). Care vor fi comportările celor două forme de CS în acest caz? Discutați fiecare schemă și estimați care se va comporta mai bine.

⁷⁾