UNIVERSITA DEGLI STUDI DI PARMA

UNIVERSITA DEGLI STUDI DI PARMA FACOLTÀ DI INGEGNERIA Dipartimento di Ingegneria dell informazione SIMULAZIONE DEL MODELLO ENHANCED DISTRIBUTED COORDINATION FUNCTION (EDCF) TRAMITE NS-2 SISTEMI MULTIMEDIALI (A.A. 2004-2005) Redazione Andrea Alfieri Dario Lodi Rizzini Supervisione Prof. Francesco Zanichelli 1

Sommario Sommario...2 Capitolo 1 Introduzione al futuro standard 802.11e...3 1.1 Sintesi delle caretteristiche principali del futuro standard 802.11e...3 1.1.1 Il DCF dello standard IEEE 802.11...3 1.1.2 Point Coordination Function nel 802.11 basilare...4 1.1.3 Limiti del PCF...6 1.1.4 Il meccanismo di supporto alla QoS del 802.11e...6 1.1.5 Enhanced Distributed Coordination Function (ECDF)...6 1.1.6 Hybrid Coordination Function (HCF)...9 1.2 Wi-Fi Multimedia (WMM)...10 Capitolo 2 Presentazione di NS-2 e delle estensioni per supportare IEEE 802.11e...14 2.1 Introduzione ad NS-2...14 2.2 Il modello IEEE 802.11e EDCF per ns-2...19 2.3 Lo script OTcl della simulazione e gli strumenti di analisi dei risultati...22 2.4 Risultati delle simulazioni...25 2.4.1 Trasmissione in Downlink...26 2.4.2 Trasmissione in Uplink...29 2.4.3 Ritardo...37 2.4.4 Scenari con traffico bidirezionale...38 Bibliografia...43 2

Capitolo 1 Introduzione al futuro standard 802.11e In questa breve relazione vengono discusse le caratteristiche principali del futuro standard IEEE 802.11e il cui scopo è fornire meccanismi di supporto per la Quality of Service (QoS) nelle WLAN. Sebbene il gruppo che si occupa della definizione dello standard sia al lavoro dal 2001, non sono ancora stati prodotti documenti ufficiali di dominio pubblico 1 Per questa ragione quelle che utilizzeremo non sono fonti ufficiali, ma articoli di osservatori e ricercatori [3] che seguono da vicino il processo di standardizzazione del IEEE 802.11e. Al termine del capitolo è discusso uno standard industriale, il Wi-Fi Multimedia (WMM), proposto anche per accelerare la conclusioni del comitato di standardizzazione e che propone soluzioni di QoS ispirate analoghe a quelle di IEEE 802.11e. 1.1 Sintesi delle caretteristiche principali del futuro standard 802.11e 1.1.1 Il DCF dello standard IEEE 802.11 Per poter comprendere la principale novità introdotta dallo standard 802.11e, l Enhanced Distributed Coordination Function (EDCF), occorre richiamare brevemente la Distributed Coordination Function (DCF) così come viene descritta nello standard 802.11 di base. Il DCF adotta uno schema listen-before-talk basato sui meccanismi di Carrier Sense Multiple Access (CSMA) e di Collision Avoidance (CA). In particolare la CSMA consiste nella verifica da parte di ciascuna stazione della presenza di segnale sulla rete per assicurarsi che il canale sia libero, dopo di che viene inviato un MAC Service Data Units (MSDUs). Con il solo CSMA è però possibile che due stazioni trovino contemporaneamente libero il canale dando luogo ad una collisione. Per tale ragione la CA prevede una procedura di backoff preliminare: ogni stazione che deve effettuare una trasmissione attende per un tempo casuale di durata minima pari al DCF InterFrame Space (DIFS), che è di 34 us nel 802.11a. Il tempo di attesa ulteriore deve essere multiplo dello slot-time (9 us nel 802.11a). Ogni stazione memorizza la propria Contention Window (CW) che mantiene il numero di slot che deve attendere prima di riprendere a trasmettere. Per segnalare una trasmissione corretta il ricevitore invia un acknowledgement (ACK). Se la trasmissione fallisce il CW viene raddoppiato riducendo così la probabilità di una collisione. 1 Esiste una pagina ufficiale con i link ai draft rilasciati, la http://grouper.ieee.org/groups/802/11/letterballots.html, ma l accesso ai draft è consentito solo ai membri del gruppo IEEE per la standardizzazione. 3

Figura 1 Esempio di trasmissione fra la stazione 2 e la stazione 1 con il meccanismo RTS/CTS. La stazione 6 non riesce a ricevere l RTS della 2, ma inizializza comunque il NAV con le informazioni del CTS trasmesso dalla 1. Per ridurre l overhead dovuto per esempio alla frammentazione di pacchetti di strati superiori e che vengono trasmessi in sequenza, l 802.11 definisce un meccanismo opzionale di Request-to- Send/Clear-to-Send (RTS/CTS). In sostanza prima il trasmettitore invia un frame RTS seguito da un CTS ricevitore. RTS e CTS contengono le informazioni su quanto tempo intercorrerà fra l attuale frame di dati (ossia MSDU) e quello successivo. Ciascuna stazione mantiene un timer, il Network Allocation Vector (NAV), che contiene le informazioni trasmesse dai frame RTS e CTS. Tra ciascun messaggio scambiato da trasmettitore e ricevitore è previsto un periodo idle detto Short InterFrame Space (SIFS) fissato a 16 us dal 802.11a. In Figura 1 è riportato un esempio di trasmissione con RTS/CTS. 1.1.2 Point Coordination Function nel 802.11 basilare Lo standard 802.11 di base definisce già una funzionalità per supportare servizi con scadenze temporali: si tratta della Point Coordination Function (PCF), che consente di fissare priorità di accesso diverse per le stazioni della rete grazie al coordinamento garantito da una stazione detta Point Coordinator (PC), tipicamente coincidente con l Access Point (AP). Il PCF ha maggiore priorità della funzione DCF esaminato nel precedente paragrafo e tale priorità è garantita dal fatto che il tempo minimo di attesa del PCF, detto PCF InterFrame Space (PIFS), è minore del DIFS essendo di soli 25 us (802.11a); si badi che il PIFS è comunque maggiore del SIFS. 4

Il PCF prevede una suddivisione del tempo in superframe, che a sua volta è costituito da un Contention Free Period (CFP) e da Contention Period (CP). Durante il CFP è attivo il PCF, mentre nel CP è consentito il normale svolgimento del DCF. Il superframe ha inizio con il cosiddetto beacon frame e contiene le informazioni necessarie per sincronizzare i timer locali delle stazioni. Il tempo intercorrente fra due beacon frame è in genere regolare e pertanto ogni stazione è in grado di prevedere l istante in cui arriverà il prossimo beacon frame detto target beacon transition time (TBTT). Durante il CFP non ci sono contese per l accesso poiché ogni operazione è regolata dal PC effettuando polling su ciascuna stazione. Poiché anche il PC può inviare dati alle stazioni, il messaggio di polling (CF-Poll) può essere combinato con il data frame da trasmettere. Similmente la stazione segnalata risponde con un aknowledgement CF-ACK che può essere combinato con un data frame. Ogni CFP termina con un CF-End. Durante il CFP ogni stazione, prima di inviare un frame, attende un tempo pari al SIFS. In Figura 2 è riportato un esempio del funzionamento del PCF. Figura 2 Esempio di operazioni del PCF. La stazione 1 è il PC ed invia CF-Poll, combinati o meno con un data frame, alla 2. La stazione 2 risponde con un CF-ACK, combinato o meno con un data-frame. Le altre stazioni inizializzano il loro NAV per l intero CFP. 5

1.1.3 Limiti del PCF Il PCF discusso nel precedente paragrafo ha come scopo principale supportare servizi che pongono dei limiti al ritardo nell inoltro del frame. Tale obiettivo è stato raggiunto solo parzialmente. Citiamo nel seguito alcuni dei problemi non risolti. 1) Nella precedente discussione si è supposto di poter conoscere con certezza il TBTT, ma il beacon potrebbe essere soggetto ad un ritardo essendo sconosciuta la durata delle operazioni di polling. Il beacon potrebbe essere quindi trasmesso dopo il TBTT consentendo alle stazioni che avrebbero dovuto trasmettere entro il TBTT di superare il bound. Alcune simulazioni di caso peggiore mettono in evidenza la possibilità di ritardi pari anche a 250 us. 2) Se è vero che il polling fornisce garanzie sull ordine con cui i frame sono trasmessi, nulla si può dire in merito ai tempi della trasmissione in polling. C è infatti solo un limite di 2304 sulle dimensioni del frame, che può raggiungere i 2312 se criptato, ma il dato può essere frammentato in più frame. 3) È possibile che una stazione perda il precedente beacon e quindi non sia in grado di impostare il TBTT ed anzi non sia neppure al corrente dell inizio di un CFP. Tale stazione non sospenderà quindi le operazioni di DFC. 1.1.4 Il meccanismo di supporto alla QoS del 802.11e Lo scopo dello standard IEEE 802.11e è sopperire i limiti riscontrati in precedenza per supportare la QoS. Esso introduce due nuove funzionalità: la Enhanced Distributed Coordination Function (ECDF) e la Hybrid Coordination Function (HCF). Le stazioni che supportano 802.11e sono dette enhanced ed appartengono allo stesso QoS-supporting Basic Service Set (QBSS). Tra queste è possibile prevedere una stazione (tipicamente è l AP) che operi come controllore centralizzato e che viene definita Hybrid Coordinator (HC). Anche nell 802.11e i superframes sono suddivisi in CP e CFP. L ECDF è attivo soltanto durante il CP, mentre HCF opera in entrambe le fasi. 1.1.5 Enhanced Distributed Coordination Function (ECDF) Il supporto per la QoS è realizzato introducendo delle classi di servizio, che nello standard sono denominate Traffic Categories (TCs). La differenziazione del livello di servizio degli MSDU appartenenti alle diverse TC è implementata attraverso una diversa parametrizzazione. 6

In particolare durante il CP ciascuna stazione, dopo aver appurato che il canale è libero, contende con le altre stazioni la Transmission Opportunity (TXOP) attendendo per un intervallo di tempo detto Arbitration InterFrame Space (AIFS). L AIFS ha durata minima pari al DIFS e può essere aumentato sulla base della TC di appartenenza. Dopo aver atteso l AIFS ha inizio il backoff di durata casuale compresa fra [1, CW+1]; un altro dei parametri dipedenti dalla TC è la durata minima del CW, la CWmin[TC]. La Figura 3 sintetizza la parametrizzazione in funzione della classe di servizio. Nel caso in cui il canale risulti occupato il CDF prevede che il CW venga raddoppiato. L ECDF invece ricalcola il CW utilizzando il Persistent Factor PF[TC], dipendente anch esso dalla TC, secondo la relazione seguente. newcw[tc] >= ((oldcw[tc] + 1) * PF[TC]) + 1 Ponendo PF = 2 si ottiene la stessa relazione prevista dal CDF. Ad ogni modo viene fissato un valore massimo CWmax[TC] per il CW dipendente dalla TC. Sintetizzando quindi è possibile definire la priorità degli MSDU operando sui seguenti parametri: AIFS[TC], CWmin[TC], PF[TC] e CWmax[TC] (opzionale). Un aspetto innovativo dell ECDF consiste nella possibilità di gestire all interno di ogni stazione fino ad 8 code virtuali corrispondenti a diverse TC. Tale stazione deve quindi implementare una funzionalità di scheduling interna e deve essere in grado di evitare collisioni virtuali come illustrato in Figura 4. Figura 3 Schema dei backoff dipendenti dalla TC. 7

Figura 4 Backoff virtuale per 8 TC. Una caratteristica importante del MAC di IEEE 802.11e è la TXOP, definita come l intervallo di tempo in cui una stazione ha il diritto di iniziare la trasmissione. Essa può essere allocata in due modi: tramite competizione (EDCF-TXOP), come illustrato in precedenza, o tramite HCF (polled- TXOP). Figura 5 Funzionamento del Contention Free Burst (CFB): entro la TXOP la stazione può effettuare una trasmissione multipla di pacchetti senza essere interrotto da altre stazioni. La durata di un EDCF-TXOP è limitata dalla massima TXOP che si può assicurare ponendo dei limiti sulla TXOP che vengono comunicati dalla stazione che ha assunto il controllo della stazione. Una novità molto importante dell EDCF rispetto al semplice DCF è la possibilità di introdurre un meccanismo di Contetion Free Burst (CFB) simile a quello assicurato dal PCF visto in precedenza 8

ma ottenuto in modo distribuito. Una stazione può infatti entro il limite sulla TXOP può trasmettere anche più di un pacchetto senza subire contention da parte delle altre stazioni. Questo diventa possibile poichè il tempo di attesa fra una trasmissione ed un altra è pari al SIFS e non all AIFS. L assenza di contesa dovrebbe permettere di migliorare le prestazioni complessive della rete diminuendo le collisioni e tutto senza coordinazione centralizzata. Invece la durata di un polled-txop può essere assicurata invece da un HC una volta che è stata dichiarata nel poll frame. Nel seguito viene appunto discussa questa ulteriore funzionalità. 1.1.6 Hybrid Coordination Function (HCF) HCF estende le regole di accesso di EDCF consentendo al Hibrid Coordinator (HC) di allocare TXOP. In modo simile al Point Coordinator (PC) del PCF, HC si assicura il canale attendendo per un tempo compreso tra PIFS e DIFS e dunque inferiore al tempo di attesa degli altri frame che è comunque maggiore di DIFS. Durante il CP, essendo attive sia EDCF sia HCF, il TXOP può essere assicurato ad una stazione o dopo una attesa pari ad AIFS + backoff o tramite un poll frame speciale, il QoS CF-Poll, inviato dal HC dopo una attesa di PIFS senza backoff. Durante il CFP l unico modo per assicurate il TXOP è tramite QoS CF-Poll. Infatti le stazioni non provano ad accedere al canale per tutto il CFP e pertanto l unica stazione che ne fa uso è HC. La fine di CFP è definita da un messaggio di CF-End inviato da HC o tramite le informazioni fissate nel beacon frame. In Figura 6 è illustrato un esempio di funzionamento di HCF. Figura 6 Esempio di funzionamento di HCF in un superframe. 9

1.2 Wi-Fi Multimedia (WMM) Le funzioni realizzate dalla Quality of Service (QoS) stanno affermandosi come un requisito chiave nelle reti Wi-Fi per supportare le applicazioni multimediali ed una gestione avanzata del traffico in ogni segmento di mercato: residenziale, enterprise e di pubblico accesso. Le tradizionali reti Wi-Fi forniscono uguale possibilità di accesso al mezzo di trasporto fisico per tutti i dispositivi connessi. Quando il traffico presente supera la banda disponibile, il troughput per tutti i flussi viene così ridotto, senza tenere in considerazione i tipi di dato che stanno viaggiando in rete. Tuttavia, mentre un ritardo di un secondo nell'inviare un job da un computer verso una stampante non viene percepito dall'utente, una latenza anche inferiore può disturbare seriamente una chiamata di tipo VoIP o la visione di uno streaming video. Quindi un accesso senza priorità, di tipo best effort, si coniuga bene con applicazioni di tipo posta elettronica, FTP, accesso ad Internet, ma non è sicuramente adatto per effettuare ad esempio streaming di musica o video, traffico vocale o giochi interattivi: tali applicazioni hanno degli stretti requisiti riguardo al troughput e ai tempi di latenza. Per questo il traffico proveniente da diverse applicazioni deve essere gestito attraverso meccanismi di tipo QoS. La Wi-Fi Alliance per questo ha sviluppato le specifiche WMM (Wi-Fi Multimedia ) ed un programma che certifica le funzionalità di tipo QoS offerte nelle reti Wi-Fi. Categorie d'accesso (AC) WMM definisce quattro categorie di accesso derivate dalla specifica 802.11d, che corrispondono a quattro livelli di priorità (tabella 1). Mentre le quattro AC sono state designate per specifiche tipologie di traffico (voce, video, best effort e traffico a bassa priorità), le specifiche WMM lasciano il gestore della rete libero di decidere l'ordine di priorità fra le calssi. WMM specifica inoltre un protocollo di comunicazione tra l'access Point (AP) ed i client per specificare le politiche di accesso ai servizi di QoS e per inviare richieste da parte dei terminali. 10

La figura 1 mostra il comportamento della WMM fra flussi di traffico che si contendono la banda disponibile. Nel primo grafico viene data priorità allo stream di tipo video rispetto agli altri. Durante i primi dieci secondi entrambi i traffici hanno abbastanza risorse disponibili; l'introduzione di un terzo stream fa sì che la domanda di banda superi quella diponibile. WMM dà allora al traffico video una priorità maggiore in modo che abbia le risorse necessarie. Nel secondo grafico la WMM non è abilitata e per questo i tre stream hanno uguale accesso al mezzo di trasporto e vengono penalizzati in ugual misura. Presentazione delle operazioni WMM 11

WMM è una estensione del meccanismo Distributed Coordination Function (DCF) basato sul protocollo CSMA/CA il quale fornisce priorità uguale per tutti i dispositivi e si basa sull'algoritmo di tipo best effort, listen before talk. Ogni client calcola un tempo casuale di backoff ed al termine può trasmettere solo se non vi sono altri utenti che stanno sfruttando il canale. In questo modo tutti hanno l'opportunità di utilizzare il mezzo di trasporto fisico, ma in condizioni di alto traffico la rete si sovraccarica e le prestazioni di tutti i dispositivi degradano in ugual misura. Con le quattro categorie di accesso mostrate in precedenza, la WMM va incontro all'inadeguatezza del DCF nel supportare traffico multimediale.gli access point WMM inoltre possono coesistere con dispositivi non abilitati a gestire la WMM in quanto ai pacchetti da questi generati viene assegnata la categoria di tipo best effort. Come mostrato in figura, i pacchetti generati dalle applicazioni sono suddivisi in quattro code fra loro indipendenti (una per ogni AC). Vi è poi un meccanismo che evita le collisioni interne il quale si va ad aggiungere all'altro per risolvere le collisioni esterne e determinare a quale client deve essere garantita l'opportunità di trasmettere (TXOP). L'algoritmo per la gestione delle collisioni che è responsabile della prioritizzazione del traffico è di tipo probabilistico e di basa su due parametri temporali: 1. il minimo intervallo fra i frame, Arbitrary Inter-Frame Space Number (AIFSN); 2. la Contention Window (CW), detta anche attesa casuale di backoff. Questi valori sono più piccoli all'aumentare della priorità del traffico. Per ogni AC, il periodo di backoff è calcolato come la somma dell'aifsn e di un numero casuale compreso fra zero e CW. Il valore di CW non è costante ma dipende dal tempo. All'inizio la lunghezza della Contention Window dipende da AC: ogni volta che si ha una collisione tale valore è raddoppiato fino a che non 12

si raggiunge un limite fissato anch'esso dalla AC. La Access Category con il CW più basso è quella che guadagna il TXOP. Una volta che il client ha ottenuto la TXOP, questi è autorizzato a trasmettere per un tempo che dipende dalla AC e dal bit rate consentito dal livello fisico. 13

Capitolo 2 Presentazione di NS-2 e delle estensioni per supportare IEEE 802.11e In questo capitolo vengono descritte le principali caratteristiche di NS-2 (Network Simulator 2), un simulatori di reti ampiamente diffuso ed impiegato in particolare per testare i protocolli di rete. Successivamente viene introdotta una estensione alla versione base scritta per supportare l EDCF e vengono presentati i risultati delle simulazioni. 2.1 Introduzione ad NS-2 NS-2 è un simulatore di reti sviluppato da un gruppo misto di ricercatori della Berkeley University, dell Information Sciences Institute (ISI) e del Palo Alto Research Center (PARK) della Xerox e liberamente scaricabile presso http://www.isi.edu/nsnam/ns/. In generale i simulatori di rete possono essere classificati [4] sulla base di 4 modelli a seconda che il sistema sia a tempo continuo o discreto e che la verifica sullo stato del sistema avvenga in istanti regolari oppure sia innescata da un evento. In Figura 7 sono riportati i 4 modelli cui facciamo riferimento. Figura 7 I 4 modelli di simulatori di rete. Più precisamente possiamo chiarire meglio le quattro caratteristiche citate. 14

Packet-driven: un simulatore è guidato dai pacchetti quando ogni pacchetto trasmesso genera un evento gestito dalla rete. Questo metodo riproduce il comportamento reale di una rete a pacchetti, ma ha lo svantaggio di produrre una mole notevole di dati. Fluid: un simulatore è fluido quando il traffico pacchetti è visto ad alto livello come un flusso continuo. Gli unici eventi considerati sono il cambio del valore del flusso. Questo modo di vedere una rete impone un dettagliato studio matematico della rete per verificare la validità di un tale modello e richiede attenzione quando si tratta l interazione fra flussi. Event-driven: un simulatore event-driven svolge l elaborazione esattamente in corrispondenza di ogni evento particolare del sistema come l invio o la ricezioni di pacchetti nelle reti packet-driven o il cambiamento dei parametri del flusso nelle reti fluide. Time-driven: un simulatore time-driven si risveglia solo in determinati istanti discreti ed elebora tutti gli eventi accaduti nel periodo tra l istante precedente e quello attuale. Con questo approccio concettualmente meno corretto di quello event-driven è più semplice la sincronizzazione e di conseguenza l elaborazione parallela. Sulla base di queste caratteristiche NS-2 è un simulatore event-driven e packet-driven e questo ha una forte incidenza sull output come vedremo al momento di analizzare i trace-file. Volendo essere precisi bisognerebbe dire che è event-driven nei limiti della precisione del timer: la classificazione event-driven vs time-driven è concettuale e di fatto tutte le implementazioni a basso livello sono time-driven. Figura 8 Struttura generale di NS-2: c è una corrispondenza uno-a-uno fra classi C++ e classi OTcl. 15

Più a basso livello NS-2 si presenta come un framework orientato agli oggetti scritto in C++ dotato di una interfaccia in OTcl, estensione ad oggetti del Tcl, un linguaggio di scripting discretamente diffuso su piattaforme Linux, rivolta agli utenti finali. L architettura prevede pertanto una duplice gerarchia di classi (vedere Figura 8): quella costituita da oggetti C++ che svolgono le operazioni basilari e la corrispondente interfaccia in OTcl per consentire la costruzione di scenari più o meno complessi all interno di un semplice script. In sostanza c è una corrispondenza uno-ad-uno fra oggetti OTcl ed oggetti C++. Nel seguito non ci addentreremo nella descrizione del codice C++ se non occasionalmente quando mostreremo rapidamente le classi base e le interfacce da estendere per implementare nuovi protocolli. Questo perché l applicazione è complessa ed in evoluzione abbastanza rapida e perché all utente che deve simulare un particolare scenario con oggetti già implementati è sufficiente conoscere gli oggetti OTcl ed i loro attributi. Per costruire una simulazione occorre definire alcuni elementi essenziali che elenchiamo qui di seguito. Simulator Trace Node Link Agent Application Il Simulator è l oggetto principale contenente tutti i dati della simulazione. Nella sintassi OTcl un simulatore viene inizializzato con l istruzione: set ns [new Simulator] Tutti gli attributi, i dati, gli altri oggetti della simulazione dovranno essere associati al simulatore con comandi: $ns elemento <attributi>. Normalmente si associa al Simulator un oggetto Trace che mantiene un le informazioni di ciascun evento che accade durante la simulazione e che tipicamente viene memorizzato in un trace file. La sintassi usuale con cui si richiede il mantenimento della traccia è la seguente: set f [open out.tr w] $ns trace-all $f Definite le componenti del sistema occorre definire la topologia della rete che si vuole simulare. La topologia è definita da un insieme di nodi e dalle connessioni fra i nodi. Gli oggetti nodi in vertià possono essere di due tipi: nodi fissi, adatti a descrivere una rete wired tradizionale, e nodi mobili, 16

pensati per fornire un modello per reti wireless. Nel primo caso è possibile dichiarare un nodo usando gli attributi di default e quindi con un semplice: set n0 [$ns node] Per definire nodi wireless occorre invece settare prima gli attributi del nodo come nell esempio che segue. $ns_ node-config -addresstype hierarchical n -adhocrouting AODV n -lltype LL n -mactype Mac/802_11 n -ifqtype Queue/DropTail/PriQueue n -ifqlen 50 n -anttype Antenna/OmniAntenna n -proptype Propagation/TwoRayGround n -phytype Phy/WirelessPhy n -topologyinstance $topo n -channel Channel/WirelessChannel n -agenttrace ON n -routertrace ON n -mactrace OFF n -movementtrace OFF Figura 9 Struttura interna della classe Link. Nel caso dei nodi fissi vanno inoltre specificate le connessioni dichiarando il tipo e vari parametri come ad esempio i nodi di partenza e di destinazione, la banda, il ritardo introdotto e le politiche di gestione della coda dei pacchetti (implementate con un oggetto gestore di coda, DropTail nell esempio): 17

$ns duplex-link $n0 $n2 5Mb 2ms DropTail Il link qui descritto in modo essenzialmente topologico rivela in realtà una certa complessità come si può ben vedere in Figura 9: alla classe link è associata una coda con le relative operazioni di accodamento (enqueue), estrazione dalla coda (dequeue) ed eliminazione dei pacchetti dalla coda quando il loro numero eccede una quantità fissata (da un parametro della DropTail). In realtà vengono anche modellati il comportamento fisico del collegamento e i ritardi che essa introduce. Nel caso dei nodi wireless ovviamente non ci sono delle connessioni, ma delle associazioni fra la stazione mobile e la stazione base. Figura 10 Struttura a strati di NS-2 per l instaurazione di stream di pacchetti fra nodo e nodo. La topologia non è sufficiente a definire il tipo e la quantità del traffico che viene trasmesso nella rete. Occorre infatti introdurre delle connessioni tramite oggetti Agenti (Figura 10) che definiscono anche il protocollo di trasporto adottato su quelle reti. Definire un agente e associarli ad un nodo è molto semplice come mostrano gli esempi. set tcp [new Agent/TCP] $ns attach-agent $node1 $tcp set udp [new Agent/UDP] $ns attach-agent $node2 $udp Gli Agenti definiscono il tipo della connessione ma non le modalità con cui vengono generati i pacchetti durante la simulazione. Occorre pertanto definire l Applicazione che genera i pacchetti. In generale il tipo dell applicazione è influenzata dall agente scelto: per esempio una applicazione FTP richiede un agente TCP. Vi sono diversi tipi di applicazione come FTP, Traffic/CBR, 18

Traffic/Exponential 2 ed estendendo la classe C++ Application è possibile scriverne altre. L Applicazione viene poi associata ad un agente. set cbr [new Application/Traffic/CBR] $cbr attach-agent $udp0 Nell ambito di una simulazione una applicazione ha un tempo di inizio e un tempo di fine. Occorre quindi specificarli come segue. $ns at 1.2 "$cbr start" $ns at 2.2 "$cbr stop" Abbiamo così discusso nelle linee essenziali le informazioni che devono essere fornite dentro uno script OTcl per definire uno scenario. 2.2 Il modello IEEE 802.11e EDCF per ns-2 Nell ambito della simulazione con NS-2 dei meccanismi proposti dell IEEE 802.11e ed in particolare di EDCF vari gruppi di ricerca hanno implementato estensioni ai protocolli disponibili nella versione standard. Bisogna però aggiungere che in molti casi la qualità del software prodotto non è buona: quasi tutti i pacchetti sperimentati dipendono fortemente dalla particolare versione di NS-2 per cui sono stati sviluppati, in alcuni casi sono stati riscontrati errori di sintassi nel codice C++ (accettati comunque dalle versioni 2.9.x di g++) o errori di linking. Tra le cause di questa disomogeneità nel software va annoverata la macchinosità dell architettura di NS-2 basata su due distinti linguaggi che devono comunicare tra loro. Segnaliamo alcuni dei gruppi di ricerca che mettono a disposizione una implementazione di EDCF: Università di Stanford (http://mosquitonet.stanford.edu/software/802.11e/); INRIA (Institut National de Recherche en Informatique et en Automatique) presso http://www-sop.inria.fr/rodeo/personnel/qni/research.html; Technische Universität Berlin (http://www.tkn.tu-berlin.de/research/802.11e_ns2/ ). La scelta è forzatamente caduta sull ultima di queste implementazioni a causa dei già citati problemi di compilazione. Precisamente si tratta di una patch realizzata in particolare per la versione 2.26 di NS-2; noi abbiamo pertanto adottato la ns-allinone_2.6 3. Nel seguito descriviamo 2 La sintassi set oggetto [new Classe1/Classe2] già incontrata nelle righe di codice introdotte serve a definire un oggetto di classe Classe2 dove Classe2 eredita dalla classe Classe1. 3 La versione allinone è così chiamata perché contiene tutte le librerie particolari richieste da ns-2, per esempio tk/tcl e otcl. Anche su distribuzioni come la Ubuntu che includono una gestione affidabile dei pacchetti come quella garantita dall APT della Debian, l installazione di librerie può presentare dei problemi che la allinone risolve. 19

in dettaglio tutte le modifiche necessarie per installare il modello EDCF per chiarire alcuni passaggi non spiegati con sufficiente chiarezza nel README che accompagna il pacchetto e perché può essere istruttivo per conoscere meglio NS-2. Il modello EDCF fornito dalla Technische Universität Berlin è distribuito come pacchetto tgz contenente tre script Tcl e i file header con le relative implementazioni di 4 classi C++: dtail.h, dtail.cc: definiscono la classe DTail che eredita da Queue e che gestisce la coda dei pacchetti secondo le politiche di QoS supportate da IEEE 802.11e; è regolata da vari parametri come CWMin, CWMax, AIFS; mac-802_11e.h, mac-802_11e.h: la classe Mac802_11e estende Mac, ossia un Connector che esegue l invio e la ricezione di pacchetti a livello di data link; la responsabilità della gestione dei pacchetti ricade invece sull Handler della rete ossia di MacTimer_802_11e nel nostro caso; mac-timers_802_11e.h, mac-timers_802_11e.cc: definiscono ed implementano la classe MacTimer_802_11e, un Handler con la responsabilità di iniziare e terminare la simulazione e di gestire gli eventi (invio e ricezione dei pacchetti, drop della coda, ecc.); priq.h, priq.cc: la classe PriQ eredita da DTail definendo parametri specifici come il numero di classi di traffico ed i filtri sui pacchetti, ossia caratteristiche della specifico scenario che verrà simulato non definite dalla più generica DTail; ns-mobilenode_802_11e.tcl: è uno script Otcl che implementa la classe Node/MobileNode in modo alternativo alla classe Node/MobileNode fornita dalla versione ufficiale di NS-2; priority.tcl: mantiene i valori dei parametri delle diverse classi di traffico, precisamente PF, AIFS, CWMin, CWMax e TXOPLimit; multi_udpflows.tcl: è uno script di esempio da cui siamo partiti per realizzare gli scenari usati nelle nostre simulazioni. Il pacchetto contenente questi file va scompattato nella directory <directory di NS-2>/mac/802_11e. Affinchè i nuovi oggetti diventino parte del sistema occorre introdurre alcune modifiche ai seguenti file. 1. Makefile.in Prima di tutto occorre aggiungere la directory del pacchetto fra i percorsi in cui il compilatore va a cercare gli header file (aggiungere -I./mac/802_11e ad INCLUDES) e i file oggetto generati dai sorgenti della patch fra i target (aggiungere mac/802_11e/mac-802_11e.o, mac/802_11e/priq.o, mac/802_11e/d- 20

tail.o e mac/802_11e/mac-timers_802_11e.o alla varibile OBJ_CC). Bisogna poi escludere l implementazione ordinaria dei mobilenode.tcl eliminandola da NS_TCL_LIB per aggiungere invece i due script mac/802_11e/nsmobilenode_802_11e.tcl, mac/802_11e/priority.tcl descritti in precedenza. 2. tcl/lib/ns-lib.tcl La stessa operazione fatta per le librerie Tcl nel Makefile.in va ripetuta anche in questo caso: occorre escludere mobilenode.tcl ed inserire mac/802_11e/ns-mobilenode_802_11e.tcl, mac/802_11e/priority.tcl. 3. tcl/lib/ns-default.tcl Bisogna inserire i parametri di default degli oggetti DTail e di PriQ: Queue/DTail set drop_front_ false Queue/DTail set summarystats_ false Queue/DTail set queue_in_bytes_ false Queue/DTail set mean_pktsize_ 500 Queue/DTail/PriQ set Prefer_Routing_Protocols 1 Queue/DTail/PriQ set Max_Levels 4 Queue/DTail/PriQ set Levels 4 4. ns-mac.tcl Vanno qui indicati i parametri di default di un oggetto Mac/802_11e che coincidono con quelli di 802_11 eccetto che il flag per abilitare/disabilitare il Contention Free Burst (CFB). In particolare occorre aggiungere le seguenti righe: if [TclObject is-class Mac/802_11e] { # settings di MAC/802.11 contenuti in questo file Mac/802_11e set cfb_ 0 ;# disables CFB } Fatte queste modifiche è sufficiente ricompilare eseguendo./cofigure seguito dal comando make. La modifica dei parametri delle classi di traffico contenuti in priority.tcl, l abilitazione del CFB e più in generale di ogni script Tcl che non sia il semplice scenario richiede la compilazione. A questo punto per lanciare il proprio scenario definito dentro un Tcl basta poi digitare (purchè la variabile d ambiente PATH contenga anche il percorso dei binari di NS-2): ns mio_scenario.tcl. 21

2.3 Lo script OTcl della simulazione e gli strumenti di analisi dei risultati Per verificare l efficacia della simulazione abbiamo realizzato alcuni test basati sullo scenario discusso e verificato dal gruppo della Technische Universität Berlin e descritto in [1], il technical report che accompagna l estensione di NS-2 esaminata. La topologia della rete che viene simulata è semplice: essa prevede un access point (AP) ed un numero variabile di stazioni mobili che ricevono pacchetti UDP normalmente in downlink. Il risultato è in Figura 11. In verità come si può notare è prevista una piccola rete wired con un nodo sorgente che invia i pacchetti su di una tradizionale rete Ethernet. Le connessioni fisse hanno una banda di 11 Mbps, quelle wireless invece di 1.5 Mbps 4. MN(1) W(1) MN(2) BS(0) W(0) W(2) W(3) MN(n) Figura 11 Topologia della rete simulata. Al centro è collocato una stazione base (BS) circondato da un numero variabile di nodi mobili (MN). C è poi un tratto di rete su fili con nodi wired (W). Nel seguito riportiamo le istruzioni per la creazione dei nodi wired e mobili che non sono ancora state discusse: for {set i 0} {$i < $num_wired_nodes} {incr i} { set W($i) [$ns node 0.0.$i] puts "wired node $i created" } 4 Questi dati sono quelli fissati dai ricercatori dell Università di Berlino. 22

$ns node-config -wiredrouting OFF for {set i 0} {$i < $num_mobile_nodes} {incr i} { set wl_node_($i) [$ns node 1.0.[expr $i + 1]] $wl_node_($i) random-motion 0 puts "wireless node $i created..." $wl_node_($i) base-station [AddrParams addr2id [$BS(0) node-addr]] $wl_node_($i) set X_ [expr $i * 10] $wl_node_($i) set Y_ [expr $i * 10] $wl_node_($i) set Z_ 0.0 } Si noti che a ciascun nodo mobile è associato un indirizzo in formato proprietario 1.0.id_nodo. In modo analogo ciascun nodo wired ha un indirizzo nel formato 0.0.id_nodo. I pacchetti generati da una applicazione saranno identificati dall'indirizzo della sorgente e da quello della destinazione a cui si aggiunge una sorta di numero di porta ; per esempio un pacchetto avrà come sorgente 0.0.2.5, ossia l'applicazione 5 sul nodo 0.0.2, e destinazione 1.0.3.1, ossia l'applicazione 1 sul nodo 1.0.3. Un altro dato da considerare è l assenza di moto nel nodo. È infatti possibile simulare gli effetti del modo del nodo mobile descritti attraverso modelli di propagazione delle onde radio (tipicamente un canale con evanescenza veloce). Occorre specificare la posizione del mobile in quanto necessaria al modello fisico della rete che viene anch esso simulato da NS-2. La base station viene creata in modo analogo ad un nodo mobile con l unica differenza (vedi sotto) set BS(0) [$ns node 1.0.0] $BS(0) random-motion 0 puts "Base-Station node $bs_id created" #provide some co-ord (fixed) to base station node $BS(0) set X_ 1.0 $BS(0) set Y_ 2.0 $BS(0) set Z_ 0.0 $ns duplex-link $W(0) $BS(0) 10Mb 2ms DropTail Una volta creata la topologia della rete occorre associare un agente ad ogni connessione ed una applicazione ai nodi sorgente. for {set a 0} {$a < $num_mobile_nodes} {incr a} { set src_udp0($a) [new Agent/UDP] $src_udp0($a) set class_ 0 $src_udp0($a) set prio_ 0 set dst_udp0($a) [new Agent/Null] $ns attach-agent $W(1) $src_udp0($a) $ns attach-agent $wl_node_($a) $dst_udp0($a) 23

} set app($a) [new Application/Traffic/CBR] $app($a) attach-agent $src_udp0($a) $ns connect $src_udp0($a) $dst_udp0($a) $ns at 0.0 "$app($a) start"... Nel frammento di codice riportato sopra si può osservare la sintassi per dichiarare un agente UDP di classe 0 (nell implementazione in esame le classi sono quattro: 0, 1, 2 e 3 a priorità descrescente) e per aggiungere una applicazione di tipo constant bit rate (CBR). In verità nell esempio per ogni nodo wireless viene creata una connessione ed una applicazione che trasmette dati in downlink (dal nodo wired $W(1) alla stazione mobile $wl_node($a)); la scelta è in funzione dei test che illustreremo nel prossimo paragrafo. È possibile inoltre modificare i parametri standard del CBR imponendo la dimensione dei pacchetti e l intervallo di tempo fra la generazione di un pacchetto e del successivo. Per specificarlo basta inserire due linee di codice come le seguenti: $app2($a) set interval_ 0.00125 $app2($a) set packetsize_ 200 Abbiamo così discusso la topologia e le applicazioni che sono state utilizzate nei nostri test. Per conoscere ulteriori dettagli rimandiamo direttamente al codice dello script. Definito lo script per lanciare la simulazione è sufficiente digitare: ns nome_script.tcl. Il risultato è riportato sotto forma di trace file, in sostanza un file di log associato all oggetto Trace precedentemente descritto che riporta tutti gli eventi accaduti nel sistema. Una normale riga del trace di EDCF ha il seguente formato: event_id time src_id dst_id traff_type size ----- prior src_addr dst_addr seqno pkt_id Chiariamo il significato dei singoli campi. event_id: identifica il tipo di evento registrato con una sttringa di 1 carattere, tipicamente uguale a '+' (ingresso del pacchetto nella coda), '-' (uscita del pacchetto dalla coda), 'r' (pacchetto ricevuto), 'D' (drop, pacchetto scartato); time: il tempo, espresso in secondi, in cui l'evento è accaduto; src_id, dst_id: sono due interi che identificano il nodo sorgente e la destinazione; contengono la stessa informazione degli indirizzi ma con una rappresentazione più comoda per il simulatore; traff_type: identifica il tipo di traffico generato, per es. 'cbr', 'ftp', ecc.; size: la dimensione del pacchetto in ottetti; prior: la classe di traffico cui appartiene il pacchetto; 24

src_addr, dst_addr: gli indirizzi dei nodi sorgente e destinazione con indicazione del numero di porta come descritto in precedenza; seqno: il numero di sequenza del pacchetto nell'ambito della connessione cui appartiene; pkt_id: un intero che identifica il singolo pacchetto all'interno del sistema. Vi sono anche altri formati per il trace file, per esempio quello che segnala i pacchetti che vengono scartati ( D ), che però non sono stati considerati nella valutazione dei risultati. Una volta che il trace file è stato generato occorre uno strumento per interpretare i dati. Nell articolo [1] si fa riferimento ad AKAROA, uno strumento di analisi open source della University of Canterbury in Christchurch (New Zealand). Nella fase di compilazione abbiamo però riscontrato alcuni problemi inerenti a librerie non presenti nel sistema da noi usato. Per varie ragioni abbiamo preferito costruire ex novo un semplice parser del trace realizzato in Java. La scelta del linguaggio è dovuta alla presenza di classi adatte alla conversione stringhe-formato numerico, alla disponibilità di codice da riutilizzare, alla facilità d uso delle classi contenitore. L applicazione di parsing è costituita da 4 classi: TraceReader: è la classe principale che contiene il metodo main; Parser: è una classe che fornisce funzioni di supporto per il parsing; Settings: apre il trace file, costruisce la lista contenente istanze di Packet, attraversa tale lista per ottenere le informazioni sintetiche come la banda per classe di priorità o per singola connessione. Packet: contiene i dati inerenti al pacchetto ed alla sua storia all interno del sistema (indirizzo sorgente e destinazione, classe di traffico, tempi di inserimento e uscita dalla coda, tempo di ricezione). Una revisione dell applicazione per distinguere uplink e downlink ha portato alla introduzione di altre due classi: TraceClassifier: è la classe principale dell applicazione alternativa; PacketClassifier: distrimina meglio la banda associata ai differenti flussi. 2.4 Risultati delle simulazioni Nel precedente paragrafo è stata descritta la topologia della rete ed alcuni dettagli comuni agli script che è stati nelle prove e gli strumenti di analisi utilizzati. Ora ci occuperemo dei risultati delle simulazioni per esaminare le prestazioni dell EDCF e riscontrare eventuali carenze del modello. Il parametro maggiormente studiato è chiaramente la banda associata ad una determinata connessione o complessivamente riferita ad una classe di traffico al variare del numero di stazioni mobili disponibili. Nelle varie simulazioni sono state misurate le bande di connessioni in downlink 25

ed in uplink, attivando o disabilitando il Contest Free Burst (CFB), facendo variare il numero di classi di servizio impiegate (tipicamente 3 oppure 4 classi). Ciascuna classe di servizio è identificata dal valore assunto dai parametri variabili definiti da 802.11e EDCF e discussi in precedenza. Abbiamo adottato i parametri usati da [1] e riportati qui di seguito in Tabella 1. Classe 0 Classe 1 Classe 2 Classe 3 PF 2 2 2 2 AIFS 2 2 3 7 CWmin 7 15 31 31 CWmax 15 31 1023 1023 TXOP limit (sec) 0.003008 0.006016 0 0 Tabella 1 Valori dei parametri EDCF caratterizzanti ciascuna classe. I primi 4 sono espressi in slot temporali (durata 9 us), mentre l ultimo parametro, il limite sulla transmission opportunity (TXOP), è un tempo espresso in secondi. 2.4.1 Trasmissione in Downlink Le prime prove sono state delle trasmissioni in downlink o più precisamente dei flussi UDP aventi un unico nodo sorgente wired della rete descritta in precedenza ed un numero variabile di nodi mobili come destinazioni. Le motivazioni che ci portano a distinguere il traffico downlink da quello uplink sono diverse. In primo luogo scopriremo una effettiva differenza anche di banda nei due scenari a causa della presenza di una rete. Inoltre c è una sostanziale differenza di topologia per cui i meccanismi di QoS a livello 2 per reti wireless in downlink sono messi in atto dall unico nodo che trasmette, cioè l access point; questo rende per esempio inutile testare il CFB in downlink poiché si otterrebbero risultati identici con o senza il Contention Free Burst 5. Le sorgenti di traffico selezionate per questa come per quasi tutte le simulazioni è una Constant Bit Rate (CBR). Le ragioni di tale scelta, sebbene non sempre realistica, sono abbastanza scontate: è semplice, non legata a modelli probalistici come quello esponenziale e dunque i risultati sono anche maggiormente controllabili e le prove sono ripetibili. Negli scenari downlink come pure per gli altri, ove non specificato, il traffico è generato con i valori di default, ossia pacchetti di dimensione di 230 ottetti rilasciati ogni 5 ms corrispondente ad un bit rate di 368 kbps. L uniformità delle sorgenti consentirà anche di paragonare meglio situazioni con parametri differenti anche di poco. Potendo considerare lo streaming in downlink maggiormente controllabile è stato interessante testare anche trasmissioni senza QoS, ossia impiegando la Distributed Coordination Function (DCF) 5 In verità abbiamo provato anche il CFB in downlink ed abbiamo ottenuto risultati identici. 26

anziché l EDCF. I risultati sono riportati in Figura 12 e Figura 13. Come si nota, pur essendoci tre flussi UDP per ciascun nodo nessuno di essi è privilegiato. È interessante notare che fino a 8 nodi le richieste sono soddisfatte, oltre tutti i flussi sono penalizzati nello stesso modo. Figura 12 Banda per classe di priorità al variare del numero di nodi. I tre flussi associati a ciascun nodo sono completamente sovrapposti. 27

Figura 13 Banda per singolo nodo al variare del numero di nodi. Ogni nodo riceve tre stream distinti ma con banda identica e sovrapposta nel grafico. Proviamo allora l EDCF nello stesso scenario e introducendo effettive relazioni di priorità fra gli stream UDP usando tre marcature rispettivamente di classe 0, 1 e 2. I parametri EDCF delle varie classi sono quelli specificati nella Tabella 1. Figura 14 Banda per classe di traffico al variare del numero di nodi. È riportato anche il precdente risultato con DCF. I risultati delle bande sono riportate nei grafici di Figura 14 e di Figura 15. L andamento è praticamente lo stesso del caso precedente: oltre gli 8 nodi le richieste di banda non sono soddisfatte. A differenza del caso precedente però la banda non è la stessa per le varie classi. Per esempio la uno stream di classe 0 riesce ad ottenere la banda richiesta anche con 8 nodi ed in generale è favorita rispetto alle altre classi. Le performance di 1 e 2 sono invece inferiori di quelle ottenute precedentemente con DCF. È interessante notare che le differenze fra i vari livelli non sono particolarmente marcati; nel caso uplink la distribuzione della banda si rivelerà molto meno equa. 28

Figura 15 Banda per singolo nodo al variare del numero di nodi. È riportato anche il risultato di DCF. 2.4.2 Trasmissione in Uplink Le prove più significative sono state effettuate con connessioni in uplink: ad ogni nodo mobile sono state associate inizialmente 3 applicazioni che inviano pacchetti generati con bit rate costante ciascuna con diversa priorità. I parametri del generatore CBR non sono stai modificati e pertanto sono quelli di deafault, ossia pacchetti di 230 ottetti rilasciati ogni 5 ms. In Figura 16 è rappresentato l andamento della banda per ciascuna delle tre classi di traffico al variare del numero di nodi. Come si può vedere la classe 0, quella a priorità maggiore, domina le altre già in presenza di un limitato numero di stazioni mobili: la banda continua a crescere in modo monotono anche se non lineare. La banda rimasta per le classi 1 e 2 tende a decrescere con un andamento che ricorda una distribuzione di Poisson. In Figura 17 è invece riportata la banda media per ogni classe di servizio relativa ad un singolo nodo. 29

Figura 16 Banda associata ad una classe di servizio al variare del numero dei nodi per trasmissioni in uplink. Le classi di traffico impiegate sono 3. Figura 17 Banda per nodo relativa a 3 classi con trasmissione in uplink. 30

Se però aumentiamo il numero delle classi arrivando a testare 4 applicazioni contemporaneamente risulta più evidente (vedere la Figura 18) che aumentando il numero dei nodi la banda complessiva per classe diminuisce. Questo si può spiegare con l aumento del numero di collisioni: il meccanismo di prenotazione e di accesso alla risorsa produce un overhead crescente all aumentare dei nodi. I dati inerenti alla banda relativa al singolo nodo riportati in Figura 19 risultano più adatti al confronto delle due situazioni presentate in precedenza. Si può notare in primo luogo che un nodo di classe 0 o di classe 1 dispone circa della stessa banda sia in presenza di 3 o di 4 flussi quando esiste un solo nodo mobile (abbiamo infatti bande di 450 kbps e di 170 kbps rispettivamente in entrambi i casi). Sempre valutando il caso del singolo nodo mobile si nota che la presenza di un ulteriore flusso UDP con priorità 3 condiziona maggiormente la classe 2 che passa 50000 bps a 20000 bps circa; ciò si spiega notando che le due classi di taffico hanno lo stesso CWmin e CWmax. Complessivamente la presenza di un traffico aggiuntivo comporta, come è prevedibile, una più rapida riduzione della banda disponibile anche per il singolo nodo. Figura 18 Banda per classe di traffico al variare del numero di nodi con 4 classi di servizio e trasmissione in uplink. 31

4.5 5 x 105 Bandwidth for mobile node class 0 class 1 class 2 class 3 4 3.5 Bandwidth [bps] 3 2.5 2 1.5 1 0.5 0 0 1 2 3 4 5 6 7 8 9 10 Number of Mobile Nodes Figura 19 Banda per nodo al variare del numero di nodi con 4 classi di servizio. Figura 20 Banda per classe di traffico in uplink al variare del numero di nodi. Classi usate: 1, 2, 3. 32

Figura 21 Banda media per nodo in uplink al variare del numero di nodi. Classi usate: 1, 2, 3. Osservando i risultati ottenuti ci si è chiesti se il valore della banda per classe di traffico o per singolo nodo appartenente ad una classe di traffico dipenda dai parametri della classe. Più esplicitamente, cambia qualcosa se, trasmettendo tre stream per nodo con priorità differente, la priorità è ottenuta associando tali stream alle classi 1, 2 e 3 anziché alle classi 0, 1 e 2? Come abbiamo visto infatti sono i parametri EDCF a caratterizzare una determinata classe e dunque la priorità può essere ottenuta con un valore inferiore di AIFS piuttosto che con una riduzione delle contention window. Quella che emerge in Figura 20 e in Figura 21 è una situazione molto simile a quella descritta dalla Figura 16 e dalla Figura 17. Abbiamo sempre un flusso a priorità maggiore che domina sugli altri. Ciò che è diverso è il risultato più democratico che emerge nell ultimo test: l aumento del numero di nodi non porta ad una riduzione così marcata della banda per le classi a priorità minore. Abbiamo poi sperimentato gli effetti del meccanismo del Contest Free Burst (CFB) applicandolo allo scenario con tre stream per nodo con priorità rispettivamente pari a 0, 1 e 2. Vista la topologia scelta soltanto con trasmissioni in uplink è possibile evidenziare l eventuale efficacia del CFB, essendoci un unico nodo per il downlink a prenotare le risorse. I risultati sono riportati in Figura 22 e Figura 23. 33

Figura 22 Banda in uplink per classe di traffico con CFB attivo. Figura 23 Banda media per nodo appartenente ad una classe di traffico con CFB attivo. 34

Quel che si può notare è una distribuzione più fair della banda anche migliore rispetto a quella ottenuta sempre usando tre livelli di priorità ma con differenti classi di traffico. Ci preme a questo punto esaminare con maggior attenzione un dato: la riduzione della banda complessiva all aumentare del numero di nodi. Abbiamo già commentato qualitativamente i risultati ottenuti in Figura 18 e che riportiamo in Figura 24 in modo sintetico, attribuendo il calo all aumento di collisioni. Come si può vedere l overhead causato dalla contesa per l accesso alla risorsa incide in modo significativo specialmente quando si è prossimi a saturare la disponibilità di tale risorsa. 750000 700000 650000 600000 550000 500000 450000 400000 350000 300000 250000 200000 150000 100000 50000 0 Uplink bandwidth 1 2 3 4 5 6 7 8 9 Bandwidth [bps] Figura 24 Banda complessiva riferita allo scenario con 4 flussi per nodo (Figura 18). Ci è sembrato interessante allora verificare se il CFB, che ha già dimostrato di garantire un utilizzo più democratico della banda, possa essere una soluzione. In particolare confronteremo il guadagno che il CFB consente di ottenere quando la dimensione e la frequenza dei pacchetti varia nell ambito dello scenario rappresentato in Figura 22 e Figura 23: abbiamo quindi 3 flussi UDP per nodo con sorgenti che rilasciano pacchetti di 230 ottetti ogni 5 ms. La banda richiesta per sostenere tutto il traffico è di 3 (8 230 / 0.005) = 1104 kbps; chiaramente, non disponendo di tale risorsa, soltanto una parte dei pacchetti generati vengono trasmessi subito e precisamente quelli con maggior priorità. Introduciamo allora uno scenario più critico con flussi aventi caratteristiche differenti: il flusso di classe 0 è generato da sorgenti che emettono pacchetti di 80 ottetti ogni 625 µs, gli altri due di classe 1 e 2 generano invece pacchetti di 200 ottetti ogni 1.25 ms. La banda richiesta è allora pari a 3584 kbps, ossia 3 volte maggiore rispetto alla situazione precedente. Ma ciò che rende problematico lo scenario è che i pacchetti hanno dimensioni più ridotte e sono inviati con una frequenza molto maggiore: pertanto il numero di pacchetti è maggiore e così pure la contesa. È la situazione ideale per mettere in risalto l efficacia del CFB: consentendo l invio multiplo di pacchetti la banda complessiva sfruttata è addirittura maggiore rispetto al caso precedente. 35