Laborator 03 - 04: Capacitatea mediului
Materiale ajutătoare
Teorie:
Despre modulațiile DSSS-CCK și OFDM - quick intro bun
aici
Despre comuncația la lower level MAC - quick intro
aici
studiu similar pentru a/g/n/ac, agregare
80211notes
Concepte
Modulație PHY - Modulația este un proces folosit în telecom prin care modificăm parametrii unui semnal cu scopul de a transmite informații. Dacă la radio am auzit de AM (modularea în amplitudine a semnalului) sau FM (modularea în frecvență a semnalului) în WiFi întâlnim preponderent DSSS (Direct Sequence Spread Spectrum), CCK (Complementary Code Keyring) și, cea mai modernă, inclusiv în tehnologia 802.11ac și 4G-LTE: OFDM (Orthogonal Frequency Division Multiplexing)
Cadrele (frame-urile) în wifi - vă veți tot lovi de conceptele astea fie prin curs, fie prin standard, fie chiar și prin kernelul de Linux:
Pachetele ETH/IP/UDP cu care suntem familiari circulă prin WiFi conform figurii de mai jos (valabil pentru orice standard) - în lumea wifi ele poartă numele de MSDU (MAC Service Data Unit)
Scop
Scopul acestui laborator este de a calcula capacitatea unui canal 802.11 pentru diverse standarde, în condiții ideale.
Vom face o analiză teoretică folosind temporizările, randomizările, și dimensiunile antetelor din standard, versus estimarea în simulator. Cazurile de interes sunt:
Introducere în tshark
Tshark este un wireshark pentru terminal. Are avantajul de a folosi limbajul wireshark pentru filtre (condițiile pot fi create în wireshark si apoi copiate cu copy/paste), dar în același timp oferă controlul afișarii la stdout.
Exemple filtre
tshark -T fields -e frame.time_epoch -e frame.number -e ip.src -r ./first-0-0.pcap '(ip.proto == 17) && (ip.src == 10.1.1.1)
'
fișierul .pcap este produs din simulare second.cc, sau dintr-un dump real
-T fields
indică câmpurile din pachete care se doresc printate
Colecție de câmpuri de interes:
opțiune pentru -e | semnificație |
frame.time_epoch | timpul de la începutul simulării |
frame.number | numărul cadrului |
ip.src | adresa IP sursă |
ip.id | IP identifier field |
ip.ttl | câmpul TTL din headerul de IP |
wlan.flags | câmpul flags din headerul WLAN |
wlan.seq | numărul de secvență WLAN |
wlan.fcs_good | cadrul WLAN este validat de câmpul FCS |
(ip.proto == 17) && (ip.src == 10.1.1.1)
indică condiția de filtrare a pachetelor din .pcap; folosește acelasi limbaj ca și wireshark
(udp.dstport == 9)
, doar cadrele către portul 9 (echo)
wlan.fc.type_subtype == 0x08
, filtrează cadrele de tip beacon (
)
wlan.fc.pwrmgt == 1
, filtrează cadrele de tip power management (
)
[03.01] Capacitatea ideală simulare
802.11b Antet PHY de 192biți trimis la MCS=1Mbps
802.11g Antet PHY de 16us + 24biți trimis la MCS=6Mbps
calculați durata unei tranzacții atomice de transmitere a unui cadru: DIFS, arbitraj, PHY header, MAC header, IP/UDP header, UDP Payload de x octeți, FCS, SIFS, ACK
atenție: MAC, IP,UDP,Payload, CRC și corp ACK se transmit prin aer la rata MCS, măsurată în bps
folosiți duratele temporizărilor specificate în standard, și dimensiunile antetelor PHY din schemele de mai sus
11b: slot=20, SIFS=10, DIFS=50
11g: slot=9, SIFS=10, DIFS=28
pentru început determinați durata în microsecunde a unei tranzacții (separat 11b și 11g)
scrieți funcția Throughput_11b(x) unde x este payload UDP, iar MCS(o constantă) ia valorile din standard 11b=1, 2, 5.5, 11
2)
scrieți funcția Throughput_11g(x) unde x este payload UDP, iar MCS ia valorile din standard 11g=6, 12, 36, 54
deduceți modul în care debitul obținut în Mbps depinde de MCS și de dimensiunea UDP payload
gnuplot> plot MCS=1, Throughput(x) w l t '1Mbps', MCS=2, Throughput(x) w l t '2Mbps', MCS=5.5, Throughput(x) …
realizați grafice pentru 802.11b (axa x: payload UDP; axa y: Throughput[Mbps])
realizați grafice pentru 802.11g (axa x: payload UDP; axa y: Throughput[Mbps])
[03.02] Capacitatea ideală simulare
Pentru un singur client, se vor repeta curbele de mai sus folosind ns-3. Modelul
lab3.cc configurează la (0,0) un AP și n-1 noduri plasate în vecinătatea sa. Traficul este generat de la AP către fiecare nod.
Pentru capacitatea ideală, folosim un AP, un client, trafic de tip UDP. Exepmlu de rulare de interes (cu parametrii de interes) pentru acest task:
./waf --run "lab3 --numberOfNodes=2 --payloadSize=1000 --dataRate=11Mbps --phyRate=DsssRate11Mbps"
numberOfNodes
reprezintă numărul total de noduri (inclusiv AP-ul).
Parametrul phyRate
(reprezinta MCS) va lua urmaoarele valori:
DsssRate1Mbps
DsssRate2Mbps
DsssRate5_5Mbps
DsssRate11Mbps
ErpOfdmRate6Mbps
ErpOfdmRate9Mbps
ErpOfdmRate12Mbps
ErpOfdmRate18Mbps
ErpOfdmRate24Mbps
ErpOfdmRate36Mbps
ErpOfdmRate48Mbps
ErpOfdmRate54Mbps
Parametrul dataRate
corespunde traficului trimis de aplicație în socketul UDP. Pe linia de comandă trebuie dați parametrii relevanți pentru dimensiunea pachetului și rata dorită de UDP.
Scopul acestui task este să repetați graficele precedente/teoretice folosind simularea în ns-3
. Puncte de evaluare pentru payloadSize
: 20, 50, 100, 500, 1000, 1500.
Puteți reduce timpii simulării folosind parametrul --simulationTime=1
De ce iterăm peste aceste packet size-uri? Iată câteva valori din trafic real:
VoIP ~ 20-300;
DNS, TCP~ 500; Ethernet MTU=1500; 802.11 Beacon=380
[03.03] Capacitatea ideală simulare - RTS/CTS activ
Repetați experimentele anterioare cu RTS/CTS activat. Ce impact are asupra pachetelor mari? Dar a celor mici? Activarea RTS/CTS o puteți face astfel pentru simulare:
./waf --run "lab3 --numberOfNodes=2 --payloadSize=1000 --dataRate=11Mbps --phyRate=DsssRate11Mbps --enableRtsCts=true"
Pentru
11n și 11ac situația este chiar mai gravă, iar soluția este agregarea de cadre.