Capitolo 8
TEST E RISULTATI
Negli ultimi anni la ricerca sulle reti ad hoc ha prodotto molti risultati che sono stati validati principalmente attraverso l'uso delle simulazioni.
Nonostante i simulatori permettano di valutare le prestazioni in varie condizioni operative (ad esempio modi cando il numero di nodi o la mobilita), spesso si basano su ipotesi sempli cate che nascondono caratteristiche importanti del comportamento reale dei protocolli, come illustrato in [ABC04] e [LNT02]. Quindi, per ottenere misure delle prestazioni piu realistiche, e opportuno integrare gli studi svolti attraverso i simulatori con degli esperimenti basati su prototipi reali. Osserviamo, comunque, che non
e semplice organizzare ambienti di sperimentazione reali e quelli che si riesce ad allestire non possono che essere di dimensioni medio-piccole. Tuttavia la disponibilita di risultati sperimentali permette di valutare realisticamente le prestazioni del sistema sviluppato e ottenere dei riscontri sulla sua usabilita.
Attualmente, in letteratura, si trovano solo pochi studi svolti in ambienti ad hoc reali. Tra questi citiamo l'ambiente di sperimentazione APE [APE]
(realizzato presso l'Universita di Uppsala in Svezia) nel quale sono state svolte
prove sperimentali con reti ad hoc formate da piu di 30 nodi. Da questi
esperimenti sono emersi risultati interessanti, come illustrato in [GLNT],
che mostrano la necessita di consolidare la ricerca sulle reti ad hoc con la
sperimentazione delle soluzioni sviluppate in ambienti reali.
8.1 Ambiente di sperimentazione
Dunque, vista l'importanza della sperimentazione in un ambiente MANET reale, abbiamo deciso di organizzare un prototipo di rete ad hoc multihop nel quale e ettuare una serie di esperimenti allo scopo di validare la soluzione cross-layer descritta in questo lavoro di tesi.
8.1 Ambiente di sperimentazione
Prima di illustrare i risultati sperimentali ottenuti, e utile descrivere l'architettura dell'ambiente di sperimentazione e gli strumenti hardware utilizzati. Tutti gli esperimenti sono stati eseguiti all'interno di un edi cio dell'Area della Ricerca del CNR di Pisa (la cui mappa e illustrata in gura 8.1).
Figura 8.1: Mappa dell'edi cio in cui abbiamo svolto gli esperimenti
Tale edi cio ospita il Centro Elaborazione Dati (CED) e alcuni
laboratori di misure, dotati di varie strumentazioni. Le caratteristiche
strutturali dell'edi cio e la presenza di access point nelle vicinanze
in uenzano notevolmente la capacita di trasmissione dei nodi di una rete
wireless realizzata all'interno. Inoltre, nell'edi cio vi sono circa 30-40
persone che quotidianamente lavorano e si spostano da un ucio ad un
altro, determinando modi che continue e non predicibili alla capacita di
8.1 Ambiente di sperimentazione
trasmissione dei nodi e alla stabilita dei collegamenti. Tutto questo contribuisce a creare un ambiente di sperimentazione per reti MANET decisamente realistico.
Per poter realizzare uno scenario di rete ad hoc multihop in una piccola area geogra ca quale quella disponibile, abbiamo sfruttato le caratteristiche siche dell'edi cio (ad esempio le pareti in muratura) e le possibili interferenze (date dalla presenza nelle vicinanze di access point e strumenti di misurazione) per limitare la capacita di trasmissione dei nodi e ottenere collegamenti wireless realistici. Dunque la topologia iniziale dell'ambiente MANET realizzato e stata studiata tenendo conto dei vincoli ssati dall'ambiente circostante.
In tutti gli esperimenti svolti abbiamo utilizzato un insieme di computer portatili, equipaggiati con diversi tipi di schede wireless compatibili con lo standard IEEE 802.11b [IEE97]. Di seguito forniamo dei dettagli ulteriori sulle caratteristiche hardware dei PC utilizzati:
1. Nodo A
Modello: Compaq Evo N110
Processore: Intel Celeron - 550 Mhz
Scheda Wireless LAN: D-Link DWL 650 - 15 dBm
2. Nodi B,G
Modello: Siemens
Processore: Intel Pentium 4
Scheda Wireless LAN: D-Link DWL 650 - 15 dBm
3. Nodi C,D,F,H
Modello: IBM Thinkpad Serie R40 - Centrino Mobile Technology Processore: Intel Pentium M - 1300 Mhz
Scheda Wireless LAN: Scheda interna Intel Pro-wireless con driver
ipw2100
8.2 Veri ca funzionale
Figura 8.2: Topologia rete MANET utilizzata negli esperimenti
4. Nodo E
Modello: IBM Thinkpad Serie R40 Processore: Intel Pentium 4
Scheda Wireless LAN: D-Link DWL 650 - 15 dBm
8.2 Veri ca funzionale
Per poter e ettuare una veri ca funzionale dell'architettura sviluppata,
abbiamo realizzato una serie di esperimenti utilizzando una rete ad hoc
reale la cui topologia e illustrata in gura 8.2. Durante gli esperimenti
tutti i nodi sono stati sincronizzati ed e stato avviato su ciascuno di essi
il demone del routing [UNI]. In particolare, degli 8 nodi disponibili, soltanto
i nodi E,F,D,C,A ed H partecipano alla costruzione dell'overlay attraverso il
protocollo CrossROAD [Del05] mentre i nodi B e G eseguono esclusivamente
attivita di routing.
8.2 Veri ca funzionale
Di seguito descriviamo i 3 diversi tipi di esperimento che abbiamo realizzato:
Esperimento 1:
i nodi vengono disposti nella con gurazione rappresentata in gura 8.2.
Al tempo t=0 avviano il demone del routing (olsrd) esteso attraverso la libreria XL-plugin. Dopo aver avviato il routing, attendono 30 sec anche la rete si stabilizzi. Quindi avviano CrossROAD secondo la sequenza E,F,D,C,A,H con un intervallo di 10 sec l'uno dall'altro.
Esperimento 2:
tutti i nodi vengono disposti nella con gurazione rappresentata in gura 8.2. Al tempo t=0 avviano il demone del routing (olsrd) esteso attraverso la libreria XL-plugin. Dopo aver avviato il routing, attendono 30 sec anche la rete si stabilizzi. Quindi avviano CrossROAD secondo la sequenza E,F,D,C,A,H con un intervallo di 20 sec l'uno dall'altro.
Esperimento 3:
tutti i nodi vengono disposti nella con gurazione rappresentata in gura 8.2. Al tempo t=0 avviano il demone del routing (olsrd) esteso attraverso la libreria XL-plugin. Dopo aver avviato il routing, attendono 30 sec anche la rete si stabilizzi. Quindi avviano CrossROAD tutti contemporaneamente.
Ciascuno di questi esperimenti e stato ripetuto piu volte. In particolare,
attraverso gli esperimenti 1 e 2, abbiamo veri cato che l'overlay viene
costruito correttamente e i nodi ne entrano a far parte nel rispetto della
sequenza di attivazione di CrossROAD che abbiamo scelto. Nell'esperimento
3, invece, tutti i nodi avviano CrossROAD contemporaneamente e ciascuno
di essi entra nell'overlay non appena XL-plugin gli noti ca la presenza di
almeno un altro nodo. Infatti un nodo non conosce a priori quanti altri
parteciperanno all'overlay e, quindi, si limita ad attendere l'arrivo di almeno
un altro nodo. In ogni caso, quando l'applicazione genera un messaggio
da inviare nell'overlay, CrossROAD individua la "migliore destinazione"
8.3 Misure di throughput e ritardi
solo dopo aver veri cato la consistenza dell'overlay stesso, chiedendo ad XL-plugin l'elenco aggiornato dei nodi che lo costituiscono.
8.3 Misure di throughput e ritardi
Dopo aver veri cato la corretta funzionalita di CrossROAD, abbiamo e ettuato una serie di esperimenti per misurare l'overhead introdotto durante la costruzione e il mantenimento dell'overlay. In prima analisi abbiamo escluso il traco applicativo, misurando cos esclusivamente l'overhead necessario per la costruzione e il mantenimento dell'overlay. In particolare abbiamo ripetuto piu volte l'esperimento 1, ottenendo in tutti i casi dei risultati simili. Dopo aver e ettuato una media dei risultati ottenuti, abbiamo prodotto un gra co (riportato in gura 8.3) che mostra il throughput misurato nei nodi principali.
0 20 40 60 80 100 120
0 100 200 300 400 500 600
B/s
seconds
CrossROAD and XL-plugin on OLSR
node D node F node E node G node B
Figura 8.3: CrossROAD: Throughput riferito ai nodi principali
Come si vede in gura 8.3 i nodi B e G, che svolgono esclusivamente attivita di routing, determinano un traco quasi trascurabile (circa 50 Bps).
Inoltre anche gli altri nodi, che entrano a far parte dell'overlay con un ritardo
temporale di 10 sec gli uni dagli altri, introducono un overhead inferiore a
8.3 Misure di throughput e ritardi
100 Bps. Questi buoni risultati sono essenzialmente dovuti alla natura auto- organizzante di CrossROAD e alla sua completa indipendenza nel costruire e mantenere l'overlay grazie alle informazioni fornite da XL-plugin mediante un'interazione cross-layer.
Per poter confrontare le prestazioni di CrossROAD con quelle ottenute con il protocollo Pastry, abbiamo predisposto un nuovo esperimento utilizzando un'implementazione open source di tale protocollo, chiamata FreePastry [FRE] e posizionando i nodi secondo la stessa topologia dei precedenti esperimenti (illustrata in gura 8.2). Ricordiamo che, quando un nuovo nodo vuole entrare in una rete Pastry gia costituita, deve conoscere almeno un vicino sico gia presente nella rete stessa. In particolare FreePastry genera una connessione TCP verso tale vicino sico, per ottenere da esso le informazioni sulla topologia dell'overlay. Successivamente vengono stabilite delle ulteriori connessioni TCP verso i nuovi vicini logici allo scopo di mantenere aggiornate le strutture dati che rappresentano l'overlay. Inoltre FreePastry utilizza una procedura di interrogazione, basata sull'apertura di connessioni UDP, per scoprire lo stato dei vicini (procedura di polling).
Quindi, per la gestione dell'overlay, ogni nodo deve stabilire e mantenere nel tempo varie connessioni di rete e questo determina un notevole overhead, specialmente in scenari mobili, caratterizzati da frequenti cambiamenti di topologia.
Nell'esperimento svolto per valutare le prestazioni di FreePastry, abbiamo
avviato le istanze sui vari nodi secondo la sequenza: E,F,D,C,A,H. Il nodo
E, essendo il primo della sequenza, inizializza un nuovo overlay, mentre gli
altri nodi conoscono un altro vicino sico che fa gia parte dell'overlay e a
cui si possono collegare. In particolare F si collega all'overlay tramite E, D
tramite E, C tramite D, A tramite E ed H tramite F. Dopo aver ripetuto
piu volte l'esperimento, ottenendo in tutti i casi dei risultati simili, abbiamo
e ettuato una media degli stessi, producendo un gra co (riportato in gura
8.4) che mostra il throughput misurato nei nodi principali.
8.3 Misure di throughput e ritardi
0 5000 10000 15000 20000 25000 30000
0 50 100 150 200 250 300 350
B/s
seconds PASTRY on OLSR
node D node F node E node G node B
Figura 8.4: Pastry: throughput riferito ai nodi principali
Come si vede in gura 8.4, i nodi B e G che svolgono esclusivamente attivita di routing continuano a produrre un overhead del tutto trascurabile.
Al contrario, i nodi su cui funziona FreePastry e che costituiscono l'overlay determinano un overhead molto piu elevato di quello misurato in CrossROAD, con picchi di throughput dell'ordine di 15000-20000 Bps.
Tali picchi di traco corrispondono alle connessioni TCP e UDP utilizzate per inizializzare e mantenere le strutture dati per la gestione dell'overlay.
Il confronto del gra co 8.4 ed 8.3 mostra in modo evidente che la nostra soluzione, basata sull'interazione cross-layer tra CrossROAD e XL-plugin, non solo funziona correttamente ma permette di costruire e mantenere l'overlay con un overhead estremamente ridotto.
Per ottenere un giudizio piu completo sulla nuova soluzione prodotta, abbiamo deciso di valutare quanto tempo occorre per costruire l'overlay.
Quindi abbiamo eseguito 2 serie distinte degli esperimenti 1 e 3. In particolare nella prima serie di esperimenti il secondo nodo che costituisce l'overlay e stato scelto ad un hop di distanza dal primo mentre nella seconda serie di esperimenti e stato scelto un nodo a 3 hop di distanza.
Indichiamo come ritardo l'intervallo di tempo che passa dall'invio del
messaggio di PublishService da parte del secondo nodo alla noti ca della
8.4 Gestione del partizionamento della rete
Ritardi per la costruzione overlay Primo nodo Altri nodi Secondo nodo ad 1 hop di distanza 180 msec 40 msec
Secondo nodo a 3 hop di distanza 325 msec 30 msec
Tabella 8.1: Ritardi sperimentati da CrossROAD nella costruzione dell'overlay
lista dei partecipanti all'overlay al primo nodo. Come illustrato in tabella 8.1, il primo nodo dell'overlay sperimenta ritardi diversi a seconda della distanza sica dal secondo nodo. In particolare, quando si trova ad 1 hop di distanza dal secondo nodo, sperimenta un ritardo di 180 msec, mentre quando si trova a 3 hop di distanza il ritardo e pari a 325 msec . Tutti gli altri nodi sperimentano un ritardo di circa 30-40 msec poiche, quando avviano l'overlay, XL-plugin ha gia memorizzato nelle proprie strutture dati locali almeno un altro nodo che fornisce il servizio. Quindi, in questo caso, il ritardo e dovuto esclusivamente al tempo necessario per lo scambio di messaggi locale al nodo tra CrossROAD e XL-plugin.
I risultati ottenuti mettono in evidenza una caratteristica molto importante della soluzione software che abbiamo sviluppato: la rapidita con cui, all'avvio, ciascun nodo e in grado di rilevare la presenza degli altri partecipanti all'overlay. Infatti, dal momento che il messaggio di pubblicazione di un servizio (PublishService) viene mandato in rete non appena e pronto il successivo pacchetto di routing, il ritardo introdotto per poter acquisire informazioni sugli altri partecipanti all'overlay e inferiore rispetto a quello necessario per poter stabilire una o piu connessioni remote (come succede in FreePastry).
8.4 Gestione del partizionamento della rete
Per validare le funzionalita di CrossROAD con ulteriori risultati sperimentali,
abbiamo analizzato un possibile scenario di partizionamento della rete,
cercando di rilevare il comportamento di CrossROAD nella gestione
dell'overlay. Per realizzare questo tipo di esperimento abbiamo utilizzato
una diversa topologia di rete, illustrata in gura 8.5.
8.4 Gestione del partizionamento della rete
Figura 8.5: Topologia per studiare partizionamento della rete
La nuova rete utilizzata e costituita da 5 nodi e ciascuno di essi rientra esclusivamente nel raggio di trasmissione dei vicino immediatamente adiacente. Tutti i nodi avviano (al tempo t=0) il demone del routing (olsrd), esteso con XL-plugin. Dopo un'attesa di 30 sec, necessaria per stabilizzare la topologia della rete, i nodi della rete avviano CrossROAD con un ritardo di 10 sec l'uno dall'altro. Una volta che tutti i nodi sono correttamente connessi all'overlay, il nodo C inizia ad inviare, con un periodo pari a 1 sec, un messaggio applicativo con un dato valore della chiave. All'inizio tale valore risulta essere logicamente piu vicino all'identi cativo logico del nodo B. Dunque il nodo C inviera tale messaggio verso il nodo B. Poi, dopo circa 30 sec, il nodo C inizia a muoversi verso la posizione X con una velocita approssimativa di 1 m/s, determinando il seguente partizionamento della rete: i nodi A e B creano una rete ad hoc indipendente da quella creata dai nodi C,D ed E.
Avendo perso il collegamento tra B e C, l'interazione cross-layer tra CrossROAD e il protocollo di routing permette al nodo C di accorgersi del partizionamento della rete, rimuovendo i nodi A e B dall'overlay. Dunque i successivi messaggi, con lo stesso valore della chiave, saranno inviati dal nodo C verso la nuova destinazione logicamente piu vicina, ovvero il nodo D.
Dopo 2 minuti, il nodo C ritorna nella posizione iniziale, ristabilendo una
singola rete ad hoc.
8.4 Gestione del partizionamento della rete
E D B A
0 100 200 300 400 500 600
Nodes
seconds
Data Distribution in case of Network Partitioning node B node D
