Capitolo 3 -

(1)

(2)

Capitolo 3

-

Prove UDP in 802.11b e 802.11g

3.1 Introduzione

Lo scopo che ci siamo prefissi in questo lavoro di tesi è stato quello di testare un collegamento wireless in ambiente marino, andando a confrontare gli attuali standard 802.11b e 802.11g. Abbiamo effettuato prove di traffico simulato UDP e TCP, per capire l'influenza dell'ambiente esterno sulle prestazioni del collegamento 802.11, mettendo in relazione le statistiche di traffico con il rapporto Segnale Rumore.

(3)

3.2 Descrizione delle prove

Figura_3. 1

Per le prove abbiamo usato due pc, un portatite e un fisso, entambi con Linux Debian GNU come sistema operativo, un kernel 2.4.27 con l'aggiunta di una “pach” per poter usare il programma Magnet, un tool che permette di raccogliere le statistiche proprie del TCP, una scheda wireless pci Netgear WG311, un Bridge Wireless Cisco Aironet 1300 Series , e due antenne con un buon guadagno per cercare di effettuare le prove a langa distanza.

Andiamo ora a vedere in dettaglio la configurazione due terminali. Computer A:

computer portatile con Linux Debian GNU, kernel ricompilato alla versione 2.4.27 con la patch Magnet, con una scheda di rete ethernet con indirizzo 192.168.100.29 collegato al Cisco Aironet 1300 la cui antenna è stata posizionata sul tetto di un edificio ( Mariteleradar ).

(4)

Figura_3. 2

(5)

Il Cisco Aironet 1300 viene collegato all' antenna tramite l'attacco “RTC” e tramite due connettori riceve l'alimentazione e i comandi di controllo dal Power Injector, che viene collegato all' alimentazione e al pc tramita l' attacco ethernet. Il Cisco Aironet è stato configurato come Access Point ( nella pagina web di configurazione si imposta come rootAP), variando la configurazione da 802.11b a 802.11g a seconda delle prove, lasciando sempre la potenza in trasmissione al massimo, cioè a 100mW. Per evitare che un client accidentale 802.11b si potesse associare all'AP in modalità 802.11g, è stata usata durante la prova una chiave WEP e il filtraggio dell'indirizzo MAC mettendo quello della scheda Netgear all'altro capo del test. Computer B:

Posizionato a bordo di una unità navale, questo pc Desktop con sistema operativo Linux DebianGNU, kernel ricompilato alla versione 2.4.27 con la patch Magnet, con una scheda wireless pci Netgear WG311 con indirizzo 192.168.100.71, che supporta entrambi gli standard di nostro interesse, sia 802.11b che 802.11g; la nostra volontà era quella di provare fino a che distanza massima il link avesse funzionato; per far ciò avevamo bisogno di guadagno in antenna, maggiore rispetto alle normali pmcia, per cui si è scelto una scheda pci con un attacco tale da poterla connettera a una antenna adatta allo scopo. Il problema successivo è stato quello di trovare una scheda che fosse compatibile con Linux Debian. Abbiamo aggirato

l'ostacolo trovando sul sito

http://ndiswrapper.sourceforge.net/phpwiki/index.php/List una lista di schede che funzionano con Linux Debian tramite il programma ndiswrapper , http://ndiswrapper.sourceforge.net/ , che sfrutta i driver di Windows forniti insieme alla scheda e li fa utilizzare a Linux permettendo cosi il corretto funzionamento della scheda.

(6)

ndiswrapper -i nome_driver

per verificare che i driver siano correttamente caricati e che sia riconosciuto l'hardware si digita

ndiswrapper -l

poi si carica il modulo della scheda in questo modo modprobe ndiswrapper

Ora andiamo ad impostare i parametri della nostra scheda tramite i Wireless Tools,

che dobbiamo preventivamente aver installati,

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html,

iwconfig wlan0 mode infrastructure essid pippo ifconfig wlan0 192.168.100.71 up

Il primo comando per selezionare la modalità di funzionameto della scheda e il suo essid, il secondo per assegnargli un indirizzo. Al posto dell'antenna di dotazione della Netgear è stata usata una antenna omnidirezionale della Cisco con le seguenti caratteristiche:

(7)

(8)

3.3 Prima Prova : Traffico UDP con standard 802.11b

Lo scopo è quello di mettere in relazione le statistiche di canale con il Throught raggiunto. Sul computer B abbiamo usato un programma scritto in C , QLINK, che estrae i dati relativi alla qualità del collegamento (Timestamp, Link Quality, Signal Level e Noise Level) che vengono memorizzati dal sistema nel file / proc/net/wireless. Il codice in questione è riportato interamente nell’Appendice i). Per il modo in cui i driver della scheda wireless calcolano i parametri si vede che un aumento del Link Quality è sinonimo di peggioramento delle condizioni del collegamento, tanto che nelle prove userò il nome di Degradation Signal(DS).

3.3.a Impostazioni pc e programmi usati

Considerando il canale in cui avviene la propagazione simmetrico, vado a prendere le statistiche di canale sullo stesso computer su cui ricevo i pacchetti UDP;

siano andati a generare il traffico UDP dal computer a terra , tramite il programma Mgen ( http://mgen.pf.itd.nrl.navy.mil/) , andando poi a ricevere i pacchetti con il pc posto sull'unità in mare tramite lo sniffer Tcpdump (http://www.tcpdump.org/). Per saturare il link e testare il canale ho usato degli script di Mgen (in Appendice) tali da saturare gli 11Mbps e i 54Mbps teorici dello standard 802.11b e 802.11g per andare poi a vedere il Goodput che si riesce ad avere.

Dal pc a terra spedisco pacchetti di varie dimensioni (poichè cio influirà notevolmente sul valore del rate trasmissivo)da 128, 512, 1024, 1472 Byte in questo modo:

(9)

dove le XXXX stanno al posto della dimensione del pacchetto che voglio inviare. Il file di configurazione usato per Mgen è udp-11M-XXXX cosi composto:

0.0 ON 1 UDP DST 192.168.100.71/11000 PERIODIC [yyyy xxxx] 60.0 OFF 1

ossia all'istante 0.0 attiva il flusso 1 con destinazione 192.168.100.71 sulla porta 11000 con la caratteristica di inviare xxxx byte ogni yyyy secondi.

Sul pc a bordo, prima che iniziasse il flusso di dati andavo ad avviare Tcpdump

tcpdump -i wlan0 -s 1500 -w Ascolto_11M_xxxx

creando il file di uscita Ascolto_11M_xxxx, che subirà ulteriori elaborazioni per poter essere utilizzato ai miei scopi. Contemporaneamente andavo ad attivare altri due programmi :

● il programma QLINK

./ QLINK > qualita_11M_xxxx

che mi crea lo script qualita_11M_xxxx in cui vengono raccolte in quattro colonne, rispettivamente il Timestamp, Il Degradation Link , Il Signal Livel e il Noise Livel.

● mgen in modalità ricezione

./mgen input Ascolto > /dev/null

in modo che il ricevitore si mettesse in acolto sulla porta prestabilita (in questo caso la 11000) e convogliasse i dati ricevuti in /dev/null.

(10)

1024, 1472 andavo a ripetere la procedura sopra descritta. A questo punto si va ad elaborare i dati grezzi in possesso per poter tirerne fuori le caratteristi che interessano.

tcpdump -nttv -r Ascolto_11M_xxxx > ricevuti_11M_xxx

Cosi si fa in modo che con le opzioni -n non venga convertito l'indirizzo ip in nome, -tt stampa il contrassegno temporale (Timestanp) non formattato su ogni riga, -v incrementa il numero di informazioni in uscita, -r utilizza il file specificato come input per i dati da filtrare, il cui output viene mandato in ricevuti_11M_xxxx.

Utilizzando degli script in linguaggio awk , vado a filtrare lo script ottenuto

awk -f el_udp_azzera.awk < ricevuti_11M_xxxx > ricevuti_azzerati_11M_xxxx ottenendo un nuovo file di configurazione composto da due colonne: nella prima ci sono i Timestamp che partono da zero, visto che il primo valore del primo udp l'ho messo nel el_udp_azzera.awk ( in Appendice [n] ), e una seconda colonna composta dalla dimensione dei pacchetti in questione. Questo stesso valore di Timestamp lo uso nel azzera_qualita per far si che le caratteristiche che tiriamo fuori tramite QLINK abbiano lo stesso istante di partenza del rate che successivamente troveremo, per poter mettere in relazione la qualità del canale con il rate trasmissiovo che si riesce ad avere.

awk -f azzera_qualita.awk < qualita_11M_xxxx > qualita_azzerata_11M_xxxx

ottenendo quattro colonne con la prima i tempi, la seconda il Degradation Link, Signal livel, Noise Livel per poter poi facilmente ottenerne un grafico tramite gnuplot , http://www.gnuplot.info/ .

(11)

aggrega.awk passandogli la dimensione dei pacchetti e la finestra temporale

awk -f aggrega.awk t=y size=xxxx

< ricevuti_azzerati_11M_xxxx > rate_11M_xxxx

ottenendo due colonne, il timestamp e il rate che si è raggiunto durante la trasmissione, che poi si possono facilmente graficare con gnuplot.

3.3.b Risultati teorici UDP per lo standard 802.11b

[a]

Figura_3. 5

Figura_3. 6

L' analisi seguente ha lo scopo di determinare il massimo goodput teorico raggiungibile da una singola stazione che genera traffico UDP. Per questo scopo, si devono tener presenti i valori temporali della trasmissioni di un pacchetto, dalla sorgente al destinatario, seguito dal successivo pacchetto ACK. Poiché il campo Data contiene un numero di intestazioni (headers), è semplice capire che solo una

(12)

porzione del data rate è dedicata alla trasmissione di dati a livello utente.

Parametri

Value

Notes

Slot Time 20 µsec

SIFS 10 µsec

DIFS 50 µsec (SIFS+2 Slot Time)

CWmin 31 (results in 620 µsec)

CWmax 1023 (results in 20,46 msec)

Tabella 3.1

La tabella presenta i valori dei parametri del livello fisico per lo standard 802.11b. Il tempo di Backoff è un periodo di tempo randomico, uguale a R volte Slot Time, dove R è una variabile randomica presa da una distribuzione uniforme sull'intervallo [0,CW], e CW sta per Contention Window.

Il valore di CW è un intero che può assumere un numero finito di valori nella fascia CWmin Cwmax, i quali sono definiti dallo standard per ogni physical layer, e i loro valori per DSSS sono nella tabella di sopra. All'inizio il valore di CW è impostato a CWmin, e assume il 2n-1 ( dove n varia tra 5 e 10 ) ogni volta che c'è un fallimento nella trasmissione di un DATA frame, identificato dall'assenza del ACK entro un determinato timeout. Per calcolare il limite superiore di unsistema 802.11b, si considera di avere una sola stazione (STA) trasmittente. Questa ipotesi implica che non ci sono collisioni e, cosi, CW è uguale a CWmin attraverso la trasmissione di quella serie di pacchetti. Il MEAN valore del periodo di Backoff è uguale a SlotTime*CWmin/2, dove R è una variabile uniformemente distribuita.

Si giunge a questa definizione dell'efficenza del rate:

= TDATA

TDATASIFSTACKDIFS

CW_min

2 ∗SlotTime

(13)

dovuto a incapsulazione solo uguale a 46,5 µsec ( per la trasmissione di 11Mbps) più 192 µsec ( per la trasmissione 1Mbps PLCP ). L'impatto di questo overhead è senzadubbio notevole poichè riduce le dimensioni del blocco UserData.

L'ultimo valore nella prima equazione da determinare è TACK. Un frame ACK è lungo 14 Bytes, trasmesso a 1 o 2 Mbps ( il più basso tra questi valori e il NIC data rate), più un PLCP physical header uguale ( in dimensioni e in rate trasmissivo) a quello del frame dati. Il tempo totale di trasmissione TACK è cosi uguale a 56+192 µsec, supponendo di avere un rate trasmissivo di 2Mbps o più. Sostituendo tutti i valori il risultato dell'efficenza del rate assume l'espressione ( nel caso 11Mbps ):

= UserData [ Bit ] 11  UserData [ Bit ] 11 46.5192105619250310 = UserData[ Bit ] UserData[ Bit ]9421.5= UserData[ Bit ] UserData[ Bit ]1178

Figura_3. 7

Il

(14)

massimo goodput raggiungibile a livello utente è cosi uguale a NIC data rate (11Mbps nel nostro caso) moltiplicato per efficenza di rate. Il grafico di sopra mostra il comportamento . Il grafico mostra il comportamento del goodput per i 4 rate disponibili nello standard 802.11b in funzione della dimensione del paylod, da 0 fino al massimo permesso dalle reti 802.11b, che è 2312 Byte (Maximum MAC Payload) meno Bytes of UDP+IP+LLC headers L'espressione generale del goodput raggiungibile come funzione del NIC Data Rate (DR) è riportata nell'equazione,

GoodputDR=DR UserData Byte UserDataByteKDR

dove i parametri sono riportati in tabella:

Data rate (DR) 1 2 5,5 11

KDR 114 214 589 1178

Tabella 3.2

La causa principale di una riduzione del goodput rispetto al valore nominale è dovuto al preambolo e l'intestazione del PLCP, che sono sempre trasmessi al data rate più basso (1 Mbps), e perciò è particolarmente importante quando la trasmissione dei dati viene fatta ai data rate più elevati. Per ridurre questa degradazione, l'emendamento supplementare b allo standard 802.11b, ha introdotto, come opzionale, il concetto di PLCP corto, che dimezza il tempo necessario per tale header.Inoltre , in una rete a infrastruttura, una ultima causa di degrado è dovuta a l'occupazione del canale da parte dei beacons di trasmissione degli Access point. Normalmente il tempo di ripetizione di due beacon è circa 100msec, cosi la riduzione di performance a causa di ciò è limitata.

(15)

3.4 Risultati Prove Traffico UDP a 250 metri in 802.11b

Sulla base delle considerazioni fatte in 3.3b, sono andato a verificare il rate che effettivamente si riesce a raggiungere tra due terminali wireless 802.11b posti a una distanza di circa 250m in mare.

Le prove sono state effettuate per diverse tipologie di pacchetti:

➢ Pacchetti da 128 byte

Il rate trasmissivo teorico lo si evince dalla formula :

Goodput DR=DR UserData Byte UserData ByteKDR

= 11∗128

1281178 = 1.078 Mbps

Nelle prove sperimentali si è arrivati ad avere il seguente valore

(16)

Durante i 60 sec di traffico UDP, si ha avuto un rate trasmissivo medio di 666 Kbps, il 61,78% del valore teorico. Questo risultato è causato da alcuni picchi del Degradation Link (DL), intorno ai 5 sec della Fig 3.8 si vedono due picchi del DL che abbassano notevolmente il rate fino a farlo oscillare intorno ai 400 Kbps fino ai 20 sec; intorno ai 40 sec c'è un altra notevole diminuzione del rate per alcuni picchi del DL.

➢ Pacchetti da 512 byte

Goodput DR=DR UserData Byte

UserData ByteKDR =

11∗512

5121178 = 3.332 Mbps

Nelle prove sperimentali si è ottenuto:

Durante i 60 sec di traffico UDP, si ha avuto un rate trasmissivo medio di circa 2.601 Mbps, cioè il 78,05% di quello teorico. Si nota intorno ai 10 sec un brusco abbassamento del rate, a causa di tre picchi molto ampi del DL. Intorno ai 40 sec si vede una repentina flessione del rate dovuto ad un costante aumento del DL.

(17)

➢ Pacchetti 1024

11∗1024

10241178 = 5.115 Mbps

Il valore teorico è 5.115 Mbps e nelle prove si è trovato un rate medio di 2,5 Mbps pari al 48% del valore teorico.

Figura_3. 10

Si vede che nei primi 10 sec si ha un abbassamento del rate a causa dei un progressivo innalzamento del DL.

(18)

➢ Pacchetti 1472 Byte

11∗1472

14721178 = 6,11 Mbps

Nelle prove si è avuto un rate trasmissivo medio di 2,48 Mbps pari al 67,92% del valore nominale.

Figura_3. 11

Tra i 18 e i 25 sec si ha che il rate cala a 0 come conseguenza di valori alti del Dl intorno ai 10 sec e 15 sec.

(19)

3.5 Risultati Prove Traffico UDP a 400 metri in 802.11b

➢ Pacchetti da 128 Byte

Figura_3. 12

Il rate medio trovato è di 668 Kbps, ossia il 63,35% del valore teorico. Questo perchè si nota un rate molto basso tra i 5 e 15 sec .

(20)

Intorno ai 20 sec il rate va a 0 a causa di un valore elevato e costante del DL. Stessa cosa tra i 2 sec e i 35 sec, per poi oscillare intorno al valore di circa 2.3Mbps, per poi subire una brusca ricaduta intorno ai 58 sec per un picco del DL.

➢ Pacchetti 1024

Figura_3. 14

Nelle prove si è avuto un rate medio di 2.344 Mbps, pari al 45,85% del valore teorico. Il rate si mantiene intorno ai 4Mbps per i primi 30 sec, per poi annullarsi tra i 30 e 42 sec per un elevato e costante valore del DL.

➢ Pacchetti 1472 Nella prova si è avuto un Rate medio di 2,48 Mbps, cioè il 40,58% del valore teorico.

(21)

3.6 Riassunto risultati 802.11b

Packet Size Valor Medio Teorico delGoodput(Mbps) Rate Medio Prove 250m (Mbps) Percentuale del valore Teorico (250m) Rate Medio Prove 400m (Mbps) Percentuale del valore Teorico (400m) 128 1,078 0,666 61,78% 0,683 63,35% 512 3,332 2,601 78,06% 1,605 48,16% 1024 5,115 2,5 48,87% 2,344 45,82% 1472 6,11 4,15 67,92% 2,48 40,58% Tabella 3.3 Figura_3. 16

Questi valori cosi bassi del rate sono da ricondurre principalmente a due fattori: ➢ Multipath

➢ Disallineamento tra antenne

Degli effetti dannosi del Multipath ho parlato a sufficenza nel Capitolo 2.

Per quanto riguarda il punto 2, bisogna tener presente che il piano su cui si trovava l'antenna in mare non è fisso, ma subisce delle variazione dovute al movimento di

(22)

rollio e beccheggio della nave (rispettivamente oscillazione intorno all'asse longitudinale e trasversale). L' antenna utilizzata non è omnidirezionale, per avere un maggior guadagno nella speranza di poter raggiungere maggiori distanze la scelta è ricaduta su questo tipo di antenna (Fig 3.5), lo è solo sul piano orizzontale, perciò a causa del moto ondoso, le due antenne si trovavano ad essere disallineate .

3.6 Risultati Prove Traffico UDP a 250 metri in 802.11g

➢ Pacchetti 128

Abbiamo avuto un rate medio di 10,08 Mbps. ➢ Pacchetti 512

Figura_3. 17

(23)

Il valormedio del rate è stato di 21,85 Mbps,. ➢ Pacchetti da 1024 Byte

Si è raggiunto un rate medio di 21,85 Mbps. ➢ Pacchetti da 1472 Byte

Si ha un rate medio di 23,09 Mbps.

(24)

3.7 Risultati Prove Traffico UDP a 400 metri in 802.11g

Figura_3. 20

Abbiamo riscontrato un rate medio di 10 Mbps. ➢ Pacchetti 512

(25)

Il rate medio è stato di soli 7,98 Mbps .

➢ Pacchetti 1024

Figura_3. 22

Abbiamo riscontrato un rate medio di 18,58Mbps e si può vedere che un imprevisto innalzamento del DL intorno ai 6 secondi provoca un oscillazione del rate a valori intorno ai 15Mbps, per poi tornare intorno ai 25Mbps solo intorno ai 15secondi. ➢ Pacchetti 1472

Il rate medio riscontrato è stato di 23,82 Mbps. Figura_3. 23