download tesi - MobiLab - Università degli Studi di Napoli Federico II
download tesi - MobiLab - Università degli Studi di Napoli Federico II
download tesi - MobiLab - Università degli Studi di Napoli Federico II
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
a<br />
Facoltà <strong>di</strong> Ingegneria<br />
Corso <strong>di</strong> <strong>Stu<strong>di</strong></strong> in Ingegneria Informatica<br />
Tesi <strong>di</strong> laurea<br />
Progetto e valutazione <strong>di</strong> algoritmi per<br />
la raccolta dati affidabile su reti <strong>di</strong><br />
sensori senza cavo<br />
Anno Accademico<br />
2005/2006<br />
Relatore<br />
Ch.mo Prof. Stefano RUSSO<br />
Correlatore<br />
Ing. Marcello CINQUE<br />
Can<strong>di</strong>dato<br />
Salvatore Falsino<br />
matr. 885/42
Ai miei genitori<br />
La <strong>di</strong>fficoltà attira l ' uomo <strong>di</strong> carattere, perché affrontandola si realizza<br />
(Charles De Gaulle)
INDICE<br />
INTRODUZIONE........................................................................................ 1<br />
1. RETI DI SENSORI SENZA CAVO....................................................... 3<br />
1.1 LE WIRELESS SENSOR NETWORK..................................................................3<br />
1.2 DIFFERENZA TRA RETI DI SENSORI E RETI AD HOC ..................................5<br />
1.3 ARCHITETTURA DELLA RETE.........................................................................6<br />
1.4 DESCRIZIONE DEI NODI SENSORI ..................................................................8<br />
1.4.1 Sensing Module ..............................................................................................8<br />
1.4.2 Unità <strong>di</strong> elaborazione.....................................................................................9<br />
1.4.3 Unità <strong>di</strong> comunicazione................................................................................10<br />
1.4.4 Alimentazione...............................................................................................10<br />
1.5 PARAMETRI DI PROGETTO ............................................................................11<br />
1.5.1 Consumo energetico.....................................................................................12<br />
1.5.2 Costo ............................................................................................................14<br />
1.5.3 Connettività ..................................................................................................14<br />
1.5.4 Topologia della rete .....................................................................................15<br />
1.5.5 Dimensioni e posizionamento dei no<strong>di</strong>.........................................................16<br />
1.5.6 Mobilità ........................................................................................................16<br />
1.5.7 Scalabilità.....................................................................................................17<br />
1.5.8 Sicurezza ......................................................................................................17<br />
1.5.9 Affidabilità....................................................................................................18<br />
1.6 PROTOCOLLI DI COMUNICAZIONE..............................................................18<br />
1.6.1 Livello Fisico................................................................................................18<br />
1.6.2 Livello data-link ...........................................................................................19<br />
1.6.3 Livello <strong>di</strong> rete ...............................................................................................21<br />
1.7 I SISTEMI OPERATIVI E LE RETI DI SENSORI..............................................25<br />
1.7.1 Introduzione a TinyOS..................................................................................27<br />
1.7.2 Introduzione a NesC.....................................................................................31<br />
1.8 LE PIATTAFORME HARDWARE ....................................................................33<br />
1.8.1 Sensori per Mica2 ........................................................................................36<br />
1.9 APPLICAZIONI ..................................................................................................38<br />
2. AFFIDABILITÀ NELLE RETI DI SENSORI SENZA CAVO ........ 42<br />
2.1 IL CONCETTO DI AFFIDABILITA’ .................................................................42<br />
2.2 AFFIDABILITA’ IN RETI DI SENSORI SENZA CAVO ..................................44<br />
2.2.1 Il problema della copertura ............................................................................46<br />
2.3 AFFIDABILITA’: STATO DELL’ARTE............................................................49<br />
2.4 AMBIENTI DI SIMULAZIONE .........................................................................51<br />
2.4.1 Il Simulatore Tossim........................................................................................55<br />
2.5 OSSERVAZIONI.................................................................................................57<br />
I
3. ALGORITMI PER LA RACCOLTA DATI AFFIDABILE ............. 59<br />
3.1 CONSIDERAZIONI GENERALI ED OBIETTIVI.............................................59<br />
3.2 ALGORITMI DI DATA GATHERING...............................................................60<br />
3.3 INTERAZIONE TRA I NODI: IL PROTOCOLLO MULTIHOP........................62<br />
3.4 CLUSTERING IN UNA WSN.............................................................................65<br />
3.5 CLUSTERING: STATO DELL’ARTE................................................................68<br />
3.6 APPROCCIO PROPOSTO PER IL CLUSTERING ............................................72<br />
3.6.1 Procedura <strong>di</strong> elezione del leader..................................................................74<br />
3.7 ALGORITMI DI TRASPORTO AFFIDABILE..................................................75<br />
3.8 APPROCCIO PROPOSTO PER IL TRASPORTO AFFIDABILE DELLE<br />
MISURAZIONI ...................................................................................................79<br />
3.9 CLUSTERING E LEADER ELECTION .............................................................82<br />
4. VALUTAZIONE COMPARATIVA DEGLI ALGORITMI............. 85<br />
4.1 OBIETTIVI..........................................................................................................85<br />
4.2 DATA GATHERING BASE................................................................................86<br />
4.3 DATA GATHERING AFFIDABILE...................................................................91<br />
4.4 DATA GATHERING CON CLUSTER ...............................................................95<br />
4.5 DATA GATHERING CON CLUSTERING E PROTOCOLLO AFFIDABILE 100<br />
4.6 OVERLAY NETWORK ....................................................................................103<br />
CONCLUSIONI .................................................................................................................107<br />
BIBLIOGRAFIA..................................................................................................................109<br />
<strong>II</strong>
INDICE DELLE FIGURE<br />
Figura 1.1: Architettura <strong>di</strong> una WSN .....................................................................................7<br />
Figura 1.2: Componenti hardware <strong>di</strong> un nodo sensori............................................................8<br />
Figura 1.3 : Modello a strati <strong>di</strong> TinyOS ...............................................................................29<br />
Figura 1.4: Rappresentazione <strong>di</strong> un componente TinyOS....................................................31<br />
Figura 1.5: Mica2.................................................................................................................33<br />
Figura 1.6: Mica2DOT.........................................................................................................34<br />
Figura 1.7: Architettura del progetto Great Duck Island......................................................39<br />
Figura 2.1: Architettura WSN per rilevazione incen<strong>di</strong>o.......................................................47<br />
Figura 3.1: Scenario tipico <strong>di</strong> una rete <strong>di</strong> sensori wireless: i coman<strong>di</strong> sono inoltrati in<br />
modalità broadcast mentre le misurazioni recapitate al nodo sink tramite<br />
protocollo multihop............................................................................................61<br />
Figura 3.2: Configurazione <strong>di</strong> Multihop Router ..................................................................63<br />
Figura 3.3: Organizzazione in cluster della rete...................................................................66<br />
Figura 3.4: Architettura protocollo RMST...........................................................................77<br />
Figura 3.5: Rete composta da otto <strong>di</strong>spositivi sensori..........................................................81<br />
Figura 3.6: Rete organizzata in 3 cluster senza procedura <strong>di</strong> elezione <strong>di</strong> cluster-head.........82<br />
Figura 3.7: Organizzazione in cluster della rete con cluster-head........................................83<br />
Figura 4.1: Architettura della rete in Tinyviz.......................................................................87<br />
Figura 4.2: Stralcio del file <strong>di</strong> configurazione della prima simulazione...............................88<br />
Figura 4.3: Evento metodo ReceiveMeasure attivato sul nodo sink alla ricezione della<br />
misurazione ........................................................................................................89<br />
Figura 4.4: Andamento % della ricezione delle misurazioni al crescere del numero <strong>di</strong><br />
no<strong>di</strong>.......... ..........................................................................................................90<br />
Figura 4.5: Andamento % della ricezione delle misurazioni con utilizzo della plugin<br />
TinySan ..............................................................................................................91<br />
Figura 4.6: Stralcio procedura seguita dal nodo sink per assicurarsi la ricezione delle<br />
misurazioni da parte dei no<strong>di</strong> sensori ................................................................92<br />
Figura 4.7: Confronto percentuali copertura con uso protocollo affidabile e non<br />
affidabile ............................................................................................................93<br />
Figura 4.8: Andamento della vita me<strong>di</strong>a dei singoli sensori nel caso <strong>di</strong> utilizzo <strong>di</strong> un<br />
protocollo <strong>di</strong> comunicazione affidabile confrontato con il caso <strong>di</strong> utilizzo<br />
<strong>di</strong> un protocollo <strong>di</strong> tipo best-effort......................................................................94<br />
Figura 4.9: Confronto consumo energetico dei singoli no<strong>di</strong> ................................................94<br />
Figura 4.10: Rete organizzata in cluster...............................................................................96<br />
Figura 4.11: Procedura <strong>di</strong> invio <strong>di</strong> un messaggio Master.....................................................97<br />
Figura 4.12: Procedura seguita dai no<strong>di</strong> alla ricezione <strong>di</strong> un master_msg ...........................98<br />
Figura 4.13: Confronto copertura con uso protocoolo affidabile e non affidabile ...............99<br />
Figura 4.14: Guadagno energetico con rete organizzata in cluster.......................................99<br />
Figura 4.15: Analisi comparativa <strong>degli</strong> algoritmi...............................................................101<br />
Figura 4.16: Elezione eseguita ciclicamente o all’esaurimento energetico <strong>di</strong> un nodo ......102<br />
Figura 4.17: Overlay Network ...........................................................................................104<br />
Figura 4.18: Impatto del modulo ra<strong>di</strong>o sulla vita <strong>di</strong> un sensore .........................................105<br />
<strong>II</strong>I
INDICE DELLE TABELLE<br />
Tabella 1-1: Alcune caratteristiche della piattaforma Mica2 .............................................35<br />
Tabella 1-2: Tabella comparativa delle prestazioni <strong>di</strong> mica2 e mica 2 dot ........................35<br />
Tabella 1-3: Schede <strong>di</strong>sponibili per piattaforma MICA .....................................................37<br />
Tabella 3-1: Schema riassuntivo dei protocolli <strong>di</strong> trasporto affidabili................................79<br />
Tabella 4-1: Caratteristiche della simulazione n°1..............................................................87<br />
Tabella 4-2: Caratteristiche della simulazione n°2..............................................................91<br />
Tabella 4-3: Caratteristiche della simulazione n°3 con rete organizzata in cluster .............95<br />
Tabella 4-4: Caratteristiche della simulazione n°4 con rete organizzata in cluster e uso<br />
protocollo <strong>di</strong> recapito affidabile.................................................................... 100<br />
IV
Ringraziamenti<br />
Eccomi qua, alla fine <strong>di</strong> un percorso, al raggiungimento <strong>di</strong> un sogno tanto<br />
desiderato. Molte sono le persone a cui vorrei esprimere tutta la mia<br />
gratitu<strong>di</strong>ne.<br />
Un grazie particolare al professore Stefano Russo, non solo per avermi dato<br />
l’opportunità <strong>di</strong> far parte <strong>di</strong> un gruppo davvero fantastico, ma per i consigli<br />
dati, molto importanti per la mia crescita professionale.<br />
Grazie anche al professore Domenico Cotroneo, per la sua <strong>di</strong>sponibilità e<br />
cor<strong>tesi</strong>a nel chiarire ogni mio dubbio; grazie Marcello, i tuoi ottimi consigli<br />
sono stati fondamentali per portare a termine il lavoro, grazie per tutto il<br />
tempo che mi hai de<strong>di</strong>cato e per il tuo aiuto nella stesura <strong>di</strong> questa <strong>tesi</strong>;<br />
grazie anche a te Lelio valido punto <strong>di</strong> confronto.<br />
Grazie mamma, grazie papà per tutto il vostro sostegno e incoraggiamento a<br />
dare sempre il massimo, per avermi dato la possibilità <strong>di</strong> proseguire i miei<br />
stu<strong>di</strong> nella serenità più totale, grazie per tutto ciò che avete fatto e che ora<br />
non ricordo…vi voglio bene! Grazie Clemente, fratello e miglior amico, per<br />
i tuoi consigli nei momenti in cui avevo bisogno <strong>di</strong> supporto…ti sono<br />
riconoscente!<br />
Un pensiero particolare va a tutti i miei familiari e anche a coloro i quali non<br />
possono gioire con me in questo giorno.<br />
Un dolcissimo grazie va ad Antonietta, mi hai “sopportato” nei momenti in<br />
cui la tensione era alta e mi hai offerto un valido supporto morale: sei<br />
importante!<br />
Infine grazie a tutti i miei amici universitari e non (evito <strong>di</strong> fare l’elenco<br />
perché sicuramente <strong>di</strong>menticherei qualcuno), ognuno dei quali è stato<br />
importante, a suo modo, nella mia vita.<br />
V<br />
Salvatore
Introduzione<br />
Negli ultimi anni lo sviluppo delle tecnologie hardware ha reso possibile la<br />
realizzazione <strong>di</strong> <strong>di</strong>spositivi sempre più potenti e miniaturizzati. Questo<br />
progresso tecnologico, insieme a quello riguardante le comunicazioni senza<br />
fili, ha costituito la base per una nuova prospettiva tecnologica <strong>di</strong> successo:<br />
le reti <strong>di</strong> sensore senza filo (WSN).<br />
La chiave del successo delle WSN è da ricercare nella loro versatilità, nel<br />
basso costo dei no<strong>di</strong> sensore e nelle loro alte doti <strong>di</strong> auto- riconfigurabilità.<br />
Queste peculiarità hanno proiettato le WSN in <strong>di</strong>versi scenari applicativi,<br />
alcuni dei quali con stringenti requisiti <strong>di</strong> affidabilità come le WSN per la<br />
teleme<strong>di</strong>cina e per alcune applicazioni militari.<br />
Attualmente si sta indagando su come gestire in maniera più efficiente il<br />
consumo energetico dei no<strong>di</strong> sensori in modo da aumentare l’autonomia<br />
della rete e in particolare come instradare in modo ottimo le comunicazioni<br />
dal sensore all’utilizzatore, come raccoglierle, memorizzare e rappresentare<br />
con la minima occupazione <strong>di</strong> memoria le informazioni raccolte.<br />
In particolare, la necessità <strong>di</strong> avere algoritmi <strong>di</strong> raccolta dati affidabili,<br />
energeticamente efficienti, risulta essere una esigenza molto <strong>di</strong>ffusa in<br />
quanto è alla base per il monitoraggio e/o controllo <strong>di</strong> fenomeni fisici per un<br />
vasto arco temporale.<br />
Questo lavoro <strong>di</strong> <strong>tesi</strong> ha come obiettivo la progettazione e valutazione <strong>di</strong> una<br />
soluzione <strong>di</strong> compromesso (trade off) tra algoritmi energeticamente<br />
efficienti e specifici requisiti <strong>di</strong> affidabilità come la consegna <strong>di</strong> una quantità<br />
significativa <strong>di</strong> misurazioni e copertura dell’area da monitorare.<br />
1
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Il lavoro si articola in quattro capitoli <strong>di</strong> cui nel seguito si fornisce una breve<br />
descrizione.<br />
Il capitolo 1 introduce brevemente alcuni concetti sulle Wireless Sensor<br />
Networks. Vengono fornite alcune importanti definizioni e aspetti salienti<br />
che le contrad<strong>di</strong>stinguono. Si precede poi con la <strong>di</strong>scussione dei parametri<br />
da considerare nella progettazione e delle possibili applicazioni <strong>di</strong> una WSN<br />
fornendo alcuni concetti <strong>di</strong> base per la comprensione del presente lavoro <strong>di</strong><br />
<strong>tesi</strong>.<br />
Il capitolo 2 fornisce un’introduzione al concetto <strong>di</strong> affidabilità nell’ambito<br />
delle reti <strong>di</strong> sensori senza cavo proponendo un’analisi <strong>di</strong> alcuni lavori<br />
presenti in letteratura. Vengono inoltre presentati alcuni dei più importanti<br />
ambienti <strong>di</strong> simulazione per WSN, soffermandosi sulle principali<br />
caratteristiche <strong>di</strong> questi ultimi.<br />
Il capitolo 3 propone una dettagliata analisi sulle strategie <strong>di</strong> clustering e sui<br />
protocolli per la consegna affidabile <strong>di</strong> informazioni al nodo sink. Viene<br />
inoltre proposto un approccio basato sull’utilizzo combinato <strong>di</strong> strategie <strong>di</strong><br />
clustering, procedure <strong>di</strong> leader election e protocolli affidabili per la raccolta<br />
dati al fine <strong>di</strong> ottenere una soluzione che sia un buon compromesso tra un<br />
consumo energetico dei no<strong>di</strong> sensori e ben precisi requisiti <strong>di</strong> affidabilità<br />
come la copertura dell’area da monitorare e la consegna <strong>di</strong> una quantità<br />
significativa <strong>di</strong> misurazioni.<br />
In conclusione il capitolo 4 fornisce una analisi comparativa <strong>degli</strong> algoritmi<br />
proposti nel precedente capitolo al fine <strong>di</strong> valutarne gli effettivi benefici in<br />
termini <strong>di</strong> aumento della autonomia dei no<strong>di</strong> sensori. Viene inoltre proposta<br />
una interessante via <strong>di</strong> sviluppo che, attraverso la ristrutturazione del<br />
protocollo <strong>di</strong> routing e l’utilizzo <strong>di</strong> una piattaforma hardware che consenta<br />
lo spegnimento selettivo (da co<strong>di</strong>ce) dei moduli ra<strong>di</strong>o, permette <strong>di</strong> ottenere<br />
significativi vantaggi nell’autonomia della rete.<br />
2
Capitolo 1<br />
Reti <strong>di</strong> sensori senza cavo<br />
1.1 LE WIRELESS SENSOR NETWORK<br />
I rapi<strong>di</strong> progressi nella progettazione <strong>di</strong> sistemi microelettromeccanici<br />
(MEMS) e a ra<strong>di</strong>o frequenze (RF) hanno favorito un repentino sviluppo <strong>di</strong><br />
“no<strong>di</strong> sensori”, termine generico con cui si in<strong>di</strong>ca un insieme <strong>di</strong> <strong>di</strong>spositivi<br />
estremamente versatili e dalle <strong>di</strong>mensioni generalmente ridotte, dotati della<br />
capacità <strong>di</strong> comunicare a breve <strong>di</strong>stanza. L’interconnessione <strong>di</strong> tali “no<strong>di</strong><br />
sensori” per mezzo <strong>di</strong> tecnologie ra<strong>di</strong>o, unitamente allo sviluppo <strong>di</strong> una<br />
architettura protocollare che consenta la cooperazione tra le <strong>di</strong>verse entità,<br />
non fa altro che amplificare, in modo esponenziale, la capacità dei singoli<br />
<strong>di</strong>spositivi dando il via allo sviluppo <strong>di</strong> un insieme vastissimo <strong>di</strong> nuove<br />
applicazioni.<br />
Questo concetto è alla base delle reti <strong>di</strong> sensori, note in letteratura con il<br />
nome <strong>di</strong> Wireless Sensor Network (WSN) il cui obiettivo è l’utilizzo <strong>di</strong> un<br />
numero abbastanza elevato <strong>di</strong> sensori, organizzati in un sistema intelligente<br />
<strong>di</strong> gestione e <strong>di</strong> rilevazione. I benefici introdotti dalle WSN possono essere<br />
riassunti in:<br />
� Facile <strong>di</strong>slocazione: la copertura dei tra<strong>di</strong>zionali macrosensori<br />
cablati è limitata a certe aree a causa dei vincoli imposti dal costo e<br />
3
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
dalla posa, rigorosamente ad opera <strong>di</strong> personale specializzato. In<br />
contrasto, le WSNs possono contenere un grande numero <strong>di</strong> no<strong>di</strong><br />
fisicamente separati. Anche se la copertura ra<strong>di</strong>o fornita da un<br />
singolo nodo è ridotta, no<strong>di</strong> densamente <strong>di</strong>stribuiti possono lavorare<br />
simultaneamente e in maniera cooperativa così da estendere la<br />
copertura dell’intera rete; inoltre i sensori possono essere<br />
letteralmente paracadutati in zone avverse [28];<br />
� Ridondanza naturale: una densa <strong>di</strong>slocazione dei sensori senza filo<br />
e la correlazione tra dati <strong>di</strong> no<strong>di</strong> vicini in una specifica area rende le<br />
WSN molto più flessibili rispetto alle classiche reti <strong>di</strong> sensori cablati.<br />
In caso <strong>di</strong> fallimento <strong>di</strong> uno dei no<strong>di</strong>, la rete riesce a reagire molto<br />
bene grazie alla forte ridondanza spaziale che caratterizza le WSN<br />
cosa che invece non sarebbe proponibile nelle reti <strong>di</strong> macrosensori.<br />
Inoltre, la possibilità <strong>di</strong> poter raggiungere <strong>di</strong>versi no<strong>di</strong> <strong>di</strong>rettamente<br />
(poiché posizionati in una area <strong>di</strong> raggio minore <strong>di</strong> quello <strong>di</strong><br />
trasmissione) garantisce una ridondanza anche nei possibili cammini<br />
verso la destinazione<br />
� Accuratezza: anche se i macrosensori possono fornire misure con<br />
una maggiore precisione rispetto ad un microsensore, la grande<br />
quantità <strong>di</strong> dati collezionati da una moltitu<strong>di</strong>ne <strong>di</strong> minuscoli sensori<br />
riflette meglio le caratteristiche della realtà. Inoltre, adottando<br />
appositi algoritmi <strong>di</strong> cooperazione tra no<strong>di</strong> è possibile abbattere il<br />
rumore <strong>di</strong> misura incorrelato e incrementare la componente comune.<br />
� Costo: E’ previsto che le WSN siano molto meno costose rispetto<br />
alle reti <strong>di</strong> macrosensori: basti pensare che il solo costo del cablaggio<br />
sia per la trasmissione delle misure che per l’alimentazione dei<br />
sensori, a volte raggiunge costi molto superiori a quelli dei soli no<strong>di</strong>.<br />
4
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
1.2 DIFFERENZA TRA RETI DI SENSORI E RETI AD<br />
HOC<br />
Le Wireless Sensor Network sono considerate come dei particolari casi <strong>di</strong><br />
reti ad hoc dette “Mobile Ad-hoc NETworks” (MANET) [2] però bisogna<br />
evidenziare che seppur con<strong>di</strong>vidono molti elementi con esse molte sono<br />
anche le <strong>di</strong>fferenze e specificità che hanno suscitato una particolare<br />
attenzione della ricerca [3]. È importante quin<strong>di</strong> evidenziare le <strong>di</strong>fferenza<br />
tra le comuni reti ad-hoc e le reti <strong>di</strong> sensori in termini <strong>di</strong>:<br />
� SCALABILITA’: perché il numero <strong>di</strong> no<strong>di</strong> che compongono una rete<br />
<strong>di</strong> sensori può essere <strong>di</strong> <strong>di</strong>versi or<strong>di</strong>ni <strong>di</strong> grandezza superiore rispetto<br />
quello <strong>di</strong> una rete tra<strong>di</strong>zionale, inoltre la densità dei no<strong>di</strong> nelle<br />
vicinanze del fenomeno da rilevare può risultare molto elevata;<br />
� FLUSSO DI COMUNICAZIONE: in quanto nelle tra<strong>di</strong>zionali WSN<br />
il flusso è fortemente asimmetrico, ovvero tutti i no<strong>di</strong> inviano i dati<br />
raccolti all’interfaccia con l’utilizzatore, cosa che <strong>di</strong> solito non<br />
accade nelle reti ad-hoc dove si pre<strong>di</strong>ligono le comunicazioni tra i<br />
singoli no<strong>di</strong> (peer-to-peer);<br />
� CAPACITA’ ENERGETICHE E DI CALCOLO: che nelle WSN sono<br />
estremamente limitate e che risultano essere un vincolo progettuale e<br />
quin<strong>di</strong> da tenere debitamente in conto nella progettazione<br />
dell’architettura della rete.<br />
� FAULT-TOLERANCE: in quanto i no<strong>di</strong> <strong>di</strong> una wireless sensor<br />
network possono essere molto spesso soggetti a guasti.<br />
� CENTRALITA’ DEI DATI: in quanto le informazioni originate da un<br />
nodo generalmente non sono <strong>di</strong> fondamentale importanza per la<br />
missione della rete: l’utente finale è più interessato ad avere una<br />
5
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
visione d’insieme del sistema; quin<strong>di</strong> se un no<strong>di</strong> si guasta è molto<br />
probabile che ciò non influenzi significativamente le prestazioni<br />
globali del sistema, grazie alla ridondanza caratteristica delle WSN.<br />
1.3 ARCHITETTURA DELLA RETE<br />
Una rete <strong>di</strong> sensori è un insieme, eventualmente eterogeneo, <strong>di</strong> no<strong>di</strong> sensore<br />
che forma una predeterminata topologia. I no<strong>di</strong> sensore possono essere<br />
equipaggiati con <strong>di</strong>spositivi in grado <strong>di</strong> rilevare una grande varietà <strong>di</strong><br />
con<strong>di</strong>zioni ambientali, come temperatura, umi<strong>di</strong>tà, movimento dei veicoli,<br />
luminosità, pressione, livello <strong>di</strong> rumore, presenza o assenza <strong>di</strong> certi tipi <strong>di</strong><br />
oggetti, grado <strong>di</strong> stress meccanico, valori istantanei <strong>di</strong> velocità, <strong>di</strong>rezione e<br />
<strong>di</strong>mensioni <strong>di</strong> un oggetto.<br />
Gli elementi della rete sono collocati all’interno dell’area da monitorare, o<br />
comunque nelle imme<strong>di</strong>ate vicinanze. Solitamente si associa ogni nodo a un<br />
oggetto, una persona, un animale o un luogo determinante per lo stu<strong>di</strong>o del<br />
fenomeno che si desidera osservare. Tipicamente non è prevista nessuna<br />
infrastruttura fissa a cui si possano appoggiare i no<strong>di</strong>, per questo <strong>di</strong> parla <strong>di</strong><br />
reti “ad-hoc”, che possono essere centralizzate se tutte le comunicazioni<br />
sono <strong>di</strong>rette ad un unico nodo che elabora le informazioni raccolte, oppure<br />
<strong>di</strong>stribuite se i no<strong>di</strong> hanno capacità e intelligenza sufficienti a elaborare i<br />
dati autonomamente. La Figura 1.1 mostra come un messaggio attraversi la<br />
rete attraverso un routing multihop da un nodo generico fino al sink, il nodo<br />
de<strong>di</strong>cato alla raccolta de dati, a cui può essere <strong>di</strong>rettamente collegato<br />
l’elaboratore dell’utente oppure un’interfaccia con altre WSN o altre reti<br />
eterogenee (per esempio Internet).<br />
6
Figura 1.1: Architettura <strong>di</strong> una WSN<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
È inoltre possibile prevedere più stazioni <strong>di</strong> raccolta dati interme<strong>di</strong>e,<br />
eventualmente anche mobili, come ad esempio un utente dotato <strong>di</strong> PDA<br />
(Personal Digital Assistant), oppure un aereo in volo.<br />
Attraverso il percorso inverso l’utente, me<strong>di</strong>ante l’applicazione <strong>di</strong> gestione<br />
della rete, è in grado <strong>di</strong> inviare coman<strong>di</strong> ad ogni nodo della WSN. Se oltre<br />
ad essere equipaggiati con sensori, i no<strong>di</strong> <strong>di</strong>spongono anche <strong>di</strong> attuatori si<br />
parla <strong>di</strong> Wireless Sensor and Actor Network (WSAN). A partire dalle<br />
informazioni raccolte dal mondo che li circonda, i sensori sono in grado <strong>di</strong><br />
decidere come agire per mo<strong>di</strong>ficare l’ambiente in cui si trovano tramite gli<br />
attuatori. Non necessariamente tutti i no<strong>di</strong> <strong>di</strong> una WSAN sono forniti <strong>di</strong><br />
attuatori che implicano un più alto consumo <strong>di</strong> energia e una maggior<br />
complessità <strong>di</strong> rispondere rapidamente ad un evento per pilotare<br />
tempestivamente l’attuatore.<br />
7
1.4 DESCRIZIONE DEI NODI SENSORI<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Esistono <strong>di</strong>verse piattaforme hardware <strong>di</strong> no<strong>di</strong> per WSN, in Figura 1.2 viene<br />
mostrato lo schema generale nel quale è possibile rintracciare cinque<br />
elementi fondamentali: uno o più sensori della grandezza fisica da rilevare<br />
(trasduttore), un trasmettitore per la comunicazione e lo scambio dei dati<br />
(ra<strong>di</strong>o), un'unità <strong>di</strong> elaborazione <strong>di</strong>gitale della grandezza misurata che<br />
sovrintende anche alla comunicazione ra<strong>di</strong>o (unità <strong>di</strong> elaborazione e<br />
controllo), un sistema <strong>di</strong> alimentazione autonomo (power management) e,<br />
in infine, uno o più attuatori.<br />
1.4.1 Sensing Module<br />
Comunemente col termine sensore si in<strong>di</strong>ca l’intero nodo <strong>di</strong> una WSN. In<br />
questo contesto però in<strong>di</strong>cheremo con il termine sensore l’hardware <strong>di</strong> cui è<br />
dotato un nodo per trasformare la grandezza fisica acquisita in un segnale<br />
elettrico che possa essere elaborato (trasduttore).<br />
Un nodo può <strong>di</strong>sporre <strong>di</strong> più sensori, anche <strong>di</strong> grandezze fisiche <strong>di</strong>verse,<br />
che sono strettamente legate alla specifica applicazione; si possono avere ad<br />
esempio sensori <strong>di</strong> luminosità, pressione, temperatura, prossimità. La<br />
maggior parte dei sensori, prevede inoltre la presenza <strong>di</strong> un blocco <strong>di</strong><br />
conversione analogica-<strong>di</strong>gitale (ADC, Analog to Digital Converter), da<br />
Figura 1.2: Componenti hardware <strong>di</strong> un nodo sensori<br />
8
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
utilizzare durante la fase <strong>di</strong> acquisizione del segnale. Il tipo <strong>di</strong> elaborazione<br />
da effettuare <strong>di</strong>pende dalla grandezza fisica rilevata e influisce <strong>di</strong>rettamente<br />
sui consumi: si pensi ad esempio <strong>di</strong> dover <strong>di</strong>gitalizzare un particolare<br />
segnale analogico: la rapi<strong>di</strong>tà con cui varia determina la velocità <strong>di</strong><br />
campionamento necessaria per acquisirlo correttamente, mentre la sua<br />
<strong>di</strong>namica e la precisione con cui lo si vuol rappresentare stabiliscono il<br />
numero <strong>di</strong> bit della parola associata ad ogni campione. All’aumentare della<br />
velocità <strong>di</strong> campionamento e del numero <strong>di</strong> bit del convertitore analogico<br />
<strong>di</strong>gitale, si ha un incremento dei consumi.<br />
1.4.2 Unità <strong>di</strong> elaborazione<br />
La presenza <strong>di</strong> una CPU permette <strong>di</strong> dotare il nodo delle capacità<br />
elaborative per gestire le comunicazioni e le grandezze misurate. Il ruolo<br />
della CPU può essere svolto da <strong>di</strong>verse tipologie <strong>di</strong> circuiti logici.<br />
Comunemente la scelta ricade su un microcontrollore a basso consumo, ma<br />
è possibile impiegare anche un FPGA (Field Programmable Gate Array), un<br />
DSP (Digital Signal Processing) o un ASIC(Application Specific Integrated<br />
Circuit). Un compito tipico del microprocessore in queste piattaforme è la<br />
verifica dell’effettiva necessità <strong>di</strong> utilizzare le risorse: per preservare la<br />
carica della batteria il nodo deve <strong>di</strong>sattivare tutti i <strong>di</strong>spositivi come chip<br />
ra<strong>di</strong>o, timer, oscillatori, ogni volta che questi non sono in<strong>di</strong>spensabili per le<br />
attività del nodo stesso. La gestione dei tempi e delle modalità del passaggio<br />
dallo stato a basso consumo a quello <strong>di</strong> attività dei vari componenti è<br />
affidata al microprocessore.<br />
Il microprocessore è spesso integrato con alcuni blocchi <strong>di</strong> memoria ROM e<br />
RAM utilizzati per ospitare il co<strong>di</strong>ce eseguibile del sistema operativo e<br />
dell’applicazione, nonché i dati acquisiti dai sensori ed elaborati<br />
dall’applicazione. La gestione e l’utilizzo delle memorie è una fonte <strong>di</strong><br />
consumo energetico, pertanto i blocchi <strong>di</strong> memoria integrati hanno capacità<br />
9
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
ridotte, limitate a poche decine <strong>di</strong> kbyte e la loro <strong>di</strong>mensione, in termini <strong>di</strong><br />
capacità <strong>di</strong> immagazzinare dati, non va sovrastimata. Alcune piattaforme,<br />
tuttavia, possono essere dotate <strong>di</strong> memorie Flash aggiuntive, connesse al<br />
microprocessore per mezzo <strong>di</strong> interfacce seriali. Queste memorie,<br />
solitamente <strong>di</strong> capacità superiore rispetto alle memorie integrate con il<br />
microprocessore, possono essere utilizzate per contenere parametri per la<br />
configurazione del nodo o altri dati. Chiaramente, l’utilizzo delle memorie<br />
aggiuntive aumenta la potenzialità del nodo, ma influisce negativamente,<br />
come già detto, sui consumi energetici.<br />
1.4.3 Unità <strong>di</strong> comunicazione<br />
Per garantire la connettività tra i no<strong>di</strong> <strong>di</strong> una WSN è possibile adottare<br />
<strong>di</strong>verse strategie. Tipicamente la connessione è realizzata via ra<strong>di</strong>o, anche se<br />
per alcune particolari applicazioni sono <strong>di</strong>sponibili soluzioni alternative che<br />
impieghino ultrasuoni o comunicazioni ottiche. Solitamente tra tutti i<br />
componenti del nodo, il chip ra<strong>di</strong>o è il <strong>di</strong>spositivo che consuma la maggior<br />
parte dell'energia. Per ridurre il costo e il consumo energetico dei no<strong>di</strong>, si<br />
utilizzano tipicamente modulazioni ben consolidate e <strong>di</strong> bassa complessità,<br />
a <strong>di</strong>scapito della capacità trasmissiva che è spesso limitata a qualche decina<br />
<strong>di</strong> kbit/s. Per limitare ulteriormente il costo finale del <strong>di</strong>spositivo, la<br />
modulazione ra<strong>di</strong>o avviene normalmente nelle bande comprese tra gli 868-<br />
870 MHz o nelle bande ISM (Industrial ScientificMe<strong>di</strong>cal) attorno ai 900<br />
MHz e ai 2,4 GHz, per le quali non è richiesta licenza governativa.<br />
1.4.4 Alimentazione<br />
Data l’impossibilità <strong>di</strong> usufruire <strong>di</strong> una rete <strong>di</strong> <strong>di</strong>stribuzione dell’energia, è<br />
necessario che ciascun elemento della WSN sia equipaggiato con un sistema<br />
autonomo <strong>di</strong> alimentazione. Attualmente l’unica soluzione <strong>di</strong>ffusa è data<br />
10
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
dall’utilizzo <strong>di</strong> pile elettrochimiche, il cui sviluppo tecnologico non ha visto<br />
notevoli incrementi nell’ultimo ventennio; ecco perchè la progettazione<br />
delle reti <strong>di</strong> sensori è centrata sul risparmio energetico. Fonti <strong>di</strong> energia<br />
alternative sono argomento <strong>di</strong> ricerca ma, come riportato in Tab. 1.1, al<br />
momento non sono ancora in grado <strong>di</strong> rimpiazzare l’alimentazione a<br />
batterie; l’unica strategia applicabile per ora è lo spegnimento selettivo dei<br />
no<strong>di</strong> per la maggior parte del tempo, in modo da ridurre il consumo <strong>di</strong><br />
potenza me<strong>di</strong>o. Promettente è la combinazione data da energia solare ed<br />
elettrochimica, in cui l’energia elettrica prodotta dalle celle fotovoltaiche<br />
esposte alla luce del sole, va a ricaricare una batteria tampone che il nodo<br />
utilizza in assenza <strong>di</strong> luce.<br />
1.5 PARAMETRI DI PROGETTO<br />
Le WSN sono state concepite al fine <strong>di</strong> rilevare delle informazioni<br />
dall’ambiente circostante e <strong>di</strong> inviarle presso un centro specializzato che<br />
elabori queste informazioni. Le reti <strong>di</strong> sensori wireless possono essere<br />
<strong>di</strong>slocate anche in ambienti particolarmente ostili o comunque in ambienti in<br />
Sorgente <strong>di</strong> energia Trasduttore Potenza Svantaggi<br />
Conversione <strong>di</strong>retta da<br />
camminata<br />
Piezoelettrico 5W<br />
Elevato rumore E.M. ed<br />
elevato ingombro<br />
Utilizzabile solo durante<br />
Solare Cella fotovoltaica 20mW le ore del giorno e<br />
abbastanza costosa<br />
Campo magnetico Induttore 1.5 mW Scarsa potenza erogabile<br />
Vibrazioni Bobina mobile 400 mW<br />
Necessità <strong>di</strong> vibrazioni per<br />
essere attivato<br />
Vibrazioni ad alta<br />
frequenza<br />
MEMS e bobina<br />
mobile<br />
100 mW<br />
Necessità <strong>di</strong> vibrazioni per<br />
essere attivato<br />
Campo a ra<strong>di</strong>o<br />
frequenza<br />
Antenna 5 mW - Scarsa potenza erogabile<br />
Tabella 4-1: Fonti energetiche alternative<br />
11
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
cui un intervento <strong>di</strong> manutenzione da parte dell’uomo potrebbe risultare<br />
impossibile (si pensi ad esempio ad una <strong>di</strong>slocazione <strong>di</strong> no<strong>di</strong> in un bosco<br />
attraverso l’ausilio <strong>di</strong> un aereo).<br />
Questo primo esempio ci fa già comprendere come le caratteristiche <strong>di</strong> una<br />
rete <strong>di</strong> sensori siano strettamente legate al reale impiego che se ne deve fare,<br />
infatti ogni specifica applicazione richiede che la WSN abbia delle proprietà<br />
particolari; questo naturalmente limita fortemente la portabilità e riusabilità<br />
delle rete in contesti <strong>di</strong>fferenti (al contrario delle tra<strong>di</strong>zionali reti ad-hoc) e<br />
si paga anche in termini <strong>di</strong> complessità <strong>di</strong> progettazione e tempi <strong>di</strong> sviluppo.<br />
Gli aspetti da considerare sono molteplici [3], <strong>di</strong> seguito si prenderanno in<br />
considerazione i principali parametri da tenere in considerazione nella fase<br />
<strong>di</strong> progettazione <strong>di</strong> una Wireless Sensor Network.<br />
1.5.1 Consumo energetico<br />
La vita <strong>di</strong> un sensore è legata principalmente alla durata della batteria.<br />
Inoltre, la riserva <strong>di</strong> energia posseduta da un sensore risulta essere<br />
estremamente ridotta, e molto spesso <strong>di</strong>fficile da rifornire. Ciò implica<br />
l’introduzione <strong>di</strong> appositi meccanismi che preservino la durata delle batterie,<br />
se possibile, fino ad alcuni anni, massimizzando l’invio delle informazioni<br />
dall’ambiente in cui si è scelto <strong>di</strong> installare la WSN. In questa logica lo<br />
scopo principale da perseguire, che del resto è una vera e propria sfida<br />
tecnologica per questi sistemi, è la riduzione del consumo <strong>di</strong> potenza. La<br />
richiesta <strong>di</strong> potenza va quin<strong>di</strong> minimizzata ad ogni livello <strong>di</strong> sviluppo, sia a<br />
livello hardware che software al fine <strong>di</strong> ottenere le prestazioni energetiche<br />
desiderate. Il consumo energetico può essere sud<strong>di</strong>viso in due punti<br />
fondamentali: comunicazione ed elaborazione dati in tempo reale.<br />
• COMUNICAZIONE:<br />
Un sensore spende la maggior parte dell’energia nelle fasi <strong>di</strong><br />
comunicazione, che comprendono sia la trasmissione che la ricezione dei<br />
12
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
dati. A corto raggio, trasmettere e ricevere dati comporta pressoché lo stesso<br />
consumo <strong>di</strong> potenza, ma in generale è la trasmissione <strong>di</strong> dati che necessita<br />
maggiore energia. In tale caso non si deve considerare solo il consumo <strong>di</strong><br />
potenza attiva, ma anche la potenza <strong>di</strong> “avvio” della trasmissione, in quanto<br />
questa fase ha dei tempi non trascurabili. Basti pensare che non appena le<br />
<strong>di</strong>mensioni del pacchetto da trasmettere <strong>di</strong>minuiscono, tale potenza tende<br />
ad<strong>di</strong>rittura a dominare sulla potenza attiva. Di conseguenza, non si può<br />
considerare un trasmettitore solo nella fase ON o OFF, perchè una buona<br />
parte <strong>di</strong> potenza viene spesa nel momento in cui si accende. La potenza Pc<br />
spesa da una ra<strong>di</strong>o può essere sintetizzata dalla seguente formula:<br />
[ P T + T ) + P ( T ) ] + N [ P ( R R ) ]<br />
P C = NT<br />
T ( on st out on R R on + st<br />
dove PT e PR rappresentano la potenza consumata nel trasmettere e ricevere,<br />
Pout la potenza <strong>di</strong> uscita dal trasmettitore, Ton e Ron il tempo in cui il<br />
trasmettitore e il ricevitore sono nella fase ON, Tst e Rst il tempo in cui il<br />
trasmettitore e ricevitore sono nella fase <strong>di</strong> avvio e NT NR il tempo in cui il<br />
trasmettitore e il ricevitore è attivo per unità <strong>di</strong> tempo. Tipicamente, per<br />
trasmettitori a basso consumo <strong>di</strong> potenza, PT e PR assumono valori<br />
dell’or<strong>di</strong>ne dei 20 dBm e Pout attorno agli 0 dBm. In conclusione, il<br />
progetto <strong>di</strong> una rete <strong>di</strong> sensori e la scelta del protocollo utilizzato sono<br />
influenzati da considerazioni sulla potenza.<br />
• ELABORAZIONE DATI IN TEMPO REALE<br />
Nonostante l’energia spesa nell’elaborazione dei dati sia significativamente<br />
inferiore a quella spesa per la loro trasmissione, è comunque un’ aspetto<br />
cruciale ridurre al minimo l’elaborazione dei dati sia per risparmiare<br />
energia, sia per abbassare il tempo in cui i sensori processano i dati. Ogni<br />
nodo deve perciò essere costruito in modo da avere varie abilità<br />
computazionali ed essere in grado <strong>di</strong> interagire con i sensori vicini.<br />
13
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
<strong>Stu<strong>di</strong></strong> specifici, effettuati su CMOS usati in regime <strong>di</strong>gitale, hanno portato<br />
alla seguente formula che permette <strong>di</strong> calcolare approssimativamente la<br />
potenza Pp spesa nell’elaborazione dei dati:<br />
P p<br />
2<br />
= CV dd f<br />
Vdd<br />
+ Vdd<br />
I 0 exp( VT<br />
)<br />
n<br />
dove C è la capacità totale del carico pilotato dall’elettronica, Vdd è il<br />
voltaggio <strong>di</strong> alimentazione ed f la frequenza me<strong>di</strong>a <strong>di</strong> commutazione. Da<br />
notare inoltre che il secondo termine in<strong>di</strong>ca la potenza spesa a causa della<br />
<strong>di</strong>spersione <strong>di</strong> corrente.<br />
1.5.2 Costo<br />
È in<strong>di</strong>spensabile che l’utilizzo della WSN sia economicamente conveniente<br />
rispetto a soluzioni alternative; d’altro canto solo una produzione <strong>di</strong> massa<br />
dei sensori può abbatterne i costi e incentivarne l’utilizzo. La speranza è che<br />
entro pochi anni il costo <strong>di</strong> un nodo non superi il dollaro, ma attualmente si<br />
è ancora lontani da questa previsione: infatti il costo del Bluetooth, il<br />
<strong>di</strong>spositivo ra<strong>di</strong>o attualmente più economico, si aggira intorno ai cinque<br />
dollari. Si deve poi considerare che un nodo possa <strong>di</strong>sporre anche <strong>di</strong> altre<br />
dotazioni come GPS (Global Positioning System), alimentatori e attuatori<br />
che ne fanno aumentare il costo. Piuttosto <strong>di</strong> sostenere costi <strong>di</strong><br />
manutenzione talvolta si preferisce smettere <strong>di</strong> utilizzare i no<strong>di</strong> che si<br />
guastano, il che risulta economicamente più conveniente se ciò non limita<br />
eccessivamente la connettività.<br />
1.5.3 Connettività<br />
La capacità dei no<strong>di</strong> <strong>di</strong> comunicare fra loro definisce la connettività. Una<br />
rete in cui ogni nodo può comunicare con qualunque altro, anche attraverso<br />
multihop (non <strong>di</strong>rettamente ma me<strong>di</strong>ante altri no<strong>di</strong> che fungono da ponte), si<br />
14
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
<strong>di</strong>ce connessa. In una WSN, tuttavia, questo tipo <strong>di</strong> connettività non è<br />
garantito, in quanto i no<strong>di</strong> passano lunghi perio<strong>di</strong> in stato <strong>di</strong> inattività (sleep)<br />
al fine <strong>di</strong> risparmiare energia, risultando raggiungibili solo in determinati<br />
intervalli <strong>di</strong> tempo. Inoltre, alcuni no<strong>di</strong> possono risultare permanentemente<br />
<strong>di</strong>sconnessi a causa <strong>di</strong> un guasto o esaurimento delle riserve energetiche. In<br />
questo caso si ha una rete partizionata e si parla <strong>di</strong> connettività a<br />
intermittenza che deve essere attentamente considerata nella progettazione<br />
dei protocolli <strong>di</strong> comunicazione e dei meccanismi <strong>di</strong> inoltro dei dati che<br />
devono quin<strong>di</strong> risultare robusti al partizionamento temporaneo e alle<br />
variazioni topologiche della rete e alla per<strong>di</strong>ta dei dati. Infine se un nodo<br />
resta per la maggior parte del tempo isolato e può comunicare solo<br />
raramente si parla <strong>di</strong> comunicazione spora<strong>di</strong>ca.<br />
1.5.4 Topologia della rete<br />
La topologia <strong>di</strong> una rete <strong>di</strong> sensori è soggetta a continui cambiamenti dovuti<br />
a fattori casuali e a imprevisti, come possono essere danneggiamento ed<br />
esaurimento energetico. Inoltre tale topologia varia anche per il fatto che<br />
non tutti i no<strong>di</strong> sono funzionanti nello stesso istante, ma alcuni sono tenuti<br />
in uno stato <strong>di</strong> basso consumo <strong>di</strong> energia. In tale stato il transceiver del nodo<br />
non è attivo e questo si traduce da un lato in un certo risparmio <strong>di</strong> energia,<br />
dall’altro nel fatto che il sensore non è connesso alla rete. Questo comporta<br />
una <strong>di</strong>minuzione della capacità <strong>di</strong> copertura e della connettività della rete. Il<br />
compromesso tra questi due parametri e il risparmio energetico è noto come<br />
topology management. L’evoluzione della topologia <strong>di</strong> una rete si può<br />
riassumere in tre fasi:<br />
1) Schieramento: i no<strong>di</strong> sono <strong>di</strong>stribuiti casualmente<br />
nell’ambiente (anche se possono essere presenti tecniche <strong>di</strong><br />
15
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
posizionamento stu<strong>di</strong>ate per ridurre le interferenze o per<br />
avvantaggiare l’auto-organizzazione dei no<strong>di</strong>);<br />
2) Post-schieramento: la topologia della rete cambia a causa dello<br />
spostamento, della <strong>di</strong>struzione o dell’esaurimento dell’energia<br />
dei no<strong>di</strong>;<br />
3) Rischieramento: i no<strong>di</strong> non più funzionanti vengono sostituiti<br />
da altri.<br />
1.5.5 Dimensioni e posizionamento dei no<strong>di</strong><br />
Per poter essere posizionati negli ambienti più <strong>di</strong>sparati è necessario che i<br />
no<strong>di</strong> siano <strong>di</strong> piccole <strong>di</strong>mensioni e leggeri, cosa non semplice per la<br />
presenza <strong>di</strong> componenti non facilmente integrabili come batteria e antenna. I<br />
no<strong>di</strong> inoltre, possono essere installati in posizioni specifiche, o possono<br />
essere <strong>di</strong>stribuiti in maniera casuale a ricoprire tutto un territorio. Per varie<br />
ragioni i no<strong>di</strong> possono essere rimpiazzati, o se ne possono aggiungere altri<br />
influenzando così la localizzazione, la densità e la topologia della rete.<br />
Riguardo la densità dei no<strong>di</strong> viene definita in mo<strong>di</strong> <strong>di</strong>versi: in termini <strong>di</strong><br />
numero <strong>di</strong> no<strong>di</strong> nell’area considerata oppure come rapporto fra il numero <strong>di</strong><br />
no<strong>di</strong> all’interno dell’intera rete e la superficie della regione su cui è<br />
<strong>di</strong>stribuita la rete. La <strong>di</strong>mensione della rete influenza l’affidabilità e<br />
l’accuratezza <strong>degli</strong> algoritmi <strong>di</strong> elaborazione.<br />
1.5.6 Mobilità<br />
In alcuni casi tutti i sensori della rete, o solo alcuni, possono spostarsi o<br />
essere parte <strong>di</strong> un <strong>di</strong>spositivo mobile: si parla in questo caso <strong>di</strong> MANET<br />
(Mobile Ad-hoc NETwork). In genere le WSN sono caratterizzate da un<br />
basso grado <strong>di</strong> mobilità. Velocità <strong>di</strong> spostamento e grado <strong>di</strong> mobilità<br />
influiscono sulla progettazione dei protocolli, in particolar modo quelli<br />
<strong>di</strong>stribuiti.<br />
16
1.5.7 Scalabilità<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
La scalabilità in<strong>di</strong>ca la capacità che ha una rete <strong>di</strong> garantire un degrado<br />
lineare delle prestazioni al crescere del numero <strong>di</strong> no<strong>di</strong> <strong>di</strong> cui è composta.<br />
Per analizzare correttamente questo parametro si deve fare riferimento alla<br />
densità dei no<strong>di</strong> nella rete:<br />
NπR<br />
μ ( R)<br />
=<br />
A<br />
dove N rappresenta il numero dei no<strong>di</strong>, R il raggio <strong>di</strong> trasmissione, A la<br />
superficie in cui la rete opera, e μ(R) rappresenta il numero me<strong>di</strong>o <strong>di</strong> no<strong>di</strong><br />
che si trovano entro la portata <strong>di</strong> un sensore.<br />
1.5.8 Sicurezza<br />
Una WSN può essere soggetta a molteplici attacchi, quali:<br />
� appropriamento delle informazioni scambiate fra i no<strong>di</strong>, da parte<br />
<strong>di</strong> un ascoltatore esterno in grado <strong>di</strong> ricevere le comunicazioni<br />
scambiate non crittografate;<br />
� sostituzione <strong>di</strong> un nodo, che dopo essere stato sottratto alla rete,<br />
manomesso e reinserito può rendere accessibile a un ascoltatore<br />
esterno le chiavi <strong>di</strong> crittografia <strong>di</strong> messaggi <strong>di</strong> livello più alto;<br />
� inserimento <strong>di</strong> un nodo fasullo, non appartenente alla rete ma che<br />
la rete stessa invece riconosce come proprio e che può inoltrare<br />
false informazioni nella WSN o bloccare il passaggio <strong>di</strong><br />
informazioni autentiche;<br />
� nodo malfunzionante, che può immettere nella rete informazioni<br />
non corrette che si propagano nella WSN;<br />
� corruzione del messaggio, può avvenire se un intruso si inserisce<br />
nella comunicazione fra i no<strong>di</strong> tentando <strong>di</strong> danneggiare<br />
l’integrità del messaggio, mo<strong>di</strong>ficandolo;<br />
17<br />
2
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
� negazione del servizio, avviene in <strong>di</strong>versi mo<strong>di</strong> ad esempio<br />
creando continue collisioni nelle trasmissioni ra<strong>di</strong>o, riducendo le<br />
risorse della rete o alterando il routing;<br />
� analisi del traffico, attraverso lo stu<strong>di</strong>o della parte <strong>di</strong> dati<br />
trasmessi senza crittografia, consente <strong>di</strong> rendere inutilizzabile la<br />
rete.<br />
1.5.9 Affidabilità<br />
Nell’ambito specifico delle reti <strong>di</strong> sensori senza cavo il concetto <strong>di</strong><br />
affidabilità si formalizza come la capacità che deve avere una rete <strong>di</strong><br />
conservare le proprie funzionalità in<strong>di</strong>pendentemente dall’eventuale guasto<br />
<strong>di</strong> qualche sensore o semplicemente da una trasmissione fallita. Attualmente<br />
il requisito <strong>di</strong> affidabilità, in una WSN, ha assunto un ruolo <strong>di</strong> primo livello<br />
e influenza non poco il progetto dell’intera architettura del sistema, uno<br />
stu<strong>di</strong>o approfon<strong>di</strong>to sarà portato avanti nel capitolo 2.<br />
1.6 PROTOCOLLI DI COMUNICAZIONE<br />
I protocolli <strong>di</strong> comunicazione rappresentano una delle aree <strong>di</strong> ricerca più<br />
attive nell'ambito delle reti <strong>di</strong> sensori. I maggiori sforzi si sono concentrati<br />
nella realizzazione <strong>di</strong> protocolli MAC efficienti dal punto <strong>di</strong> vista<br />
energetico e <strong>di</strong> protocolli <strong>di</strong> routing che offrano soluzioni efficaci per tutte<br />
le esigenze. Dei livelli <strong>di</strong> cui è composto il modello ISO/OSI, quelli<br />
coinvolti nella progettazione <strong>di</strong> protocolli <strong>di</strong> rete per una rete <strong>di</strong> sensori<br />
sono il livello fisico, il livello data-link ed il livello <strong>di</strong> rete, <strong>di</strong> cui ne daremo<br />
una breve descrizione nei successivi sottoparagrafi.<br />
1.6.1 Livello Fisico<br />
18
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Il livello fisico si occupa <strong>di</strong> impostare la frequenza, <strong>di</strong> generare la portante e<br />
del riconoscimento del segnale e infine della modulazione e co<strong>di</strong>fica dei<br />
dati. Ma rispetto alle classiche trasmissioni ra<strong>di</strong>o, in questo caso il<br />
principale problema è come trasmettere i dati spendendo la quantità minima<br />
<strong>di</strong> energia, tenendo conto <strong>di</strong> tutti i costi collegati (overhead, etc).<br />
Molti lavori si concentrano sulla modulazione efficiente del segnale dal<br />
punto <strong>di</strong> vista energetico [4] [5].<br />
1.6.2 Livello data-link<br />
Il livello data-link è responsabile della multiplazione dei flussi <strong>di</strong> dati, del<br />
riconoscimento dei frame, del controllo dell'accesso al mezzo e del controllo<br />
dell'errore. Di questi aspetti forse il più interessante è la progettazione del<br />
protocollo MAC [6].<br />
Gli obiettivi del MAC sono i seguenti:<br />
� Ridurre le collisioni. Se due o più no<strong>di</strong> trasmettono<br />
contemporaneamente sullo stesso canale ra<strong>di</strong>o, i loro messaggi<br />
interferiscono reciprocamente e in ricezione non è possibile<br />
ricostruirli; si deve quin<strong>di</strong> programmare una ritrasmissione in istanti<br />
<strong>di</strong>fferenti per tentare nuovamente l’inoltro del messaggio.<br />
Ritrasmettere più volte lo stesso pacchetto comporta un notevole<br />
<strong>di</strong>spen<strong>di</strong>o d’energia che, come già esposto, i no<strong>di</strong> devono evitare. A<br />
tal fine può essere conveniente sud<strong>di</strong>videre il canale in più<br />
sottocanali,utilizzabili contemporaneamente per ridurre i conflitti <strong>di</strong><br />
accesso al mezzo; le soluzioni più <strong>di</strong>ffuse sfruttano la <strong>di</strong>versità<br />
temporale (TDMA, Time Division Multiple Access), in frequenza<br />
(FDMA, Frequency Division Multiple Access) <strong>di</strong> co<strong>di</strong>fica (CDMA,<br />
Code Division Multiple Access) e con ascolto della portante<br />
(CSMA/CA, Carrier Sense Multiple Access / collision avoidance).<br />
Dato l’elevato numero <strong>di</strong> no<strong>di</strong> che compongono una rete non è<br />
19
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
possibile de<strong>di</strong>care un sottocanale per ogni collegamento punto-<br />
punto, le risorse per la comunicazione devono essere quin<strong>di</strong><br />
riallocabili più volte all’interno della rete. Come vedremo, questo<br />
aspetto sarà un limite progettuale non <strong>di</strong> poco conto per la scelta <strong>di</strong><br />
algoritmi <strong>di</strong> comunicazione affidabili.<br />
� Utilizzare algoritmi adattativi per il supporto della mobilità. Alcune<br />
applicazioni richiedono <strong>di</strong> poter gestire in modo semplice no<strong>di</strong> che si<br />
muovono all’interno della rete; tale problematica può essere trattata<br />
nella ipo<strong>tesi</strong> semplificativa <strong>di</strong> no<strong>di</strong> a bassa mobilità, dato che le<br />
con<strong>di</strong>zioni d’impiego delle reti <strong>di</strong> sensori non richiedono <strong>di</strong><br />
effettuare rapi<strong>di</strong> spostamenti. Un nodo in movimento può aver<br />
bisogno della riallocazione <strong>di</strong>namica dei canali se questi sono già<br />
utilizzati dai no<strong>di</strong> a cui si avvicina; inoltre anche a questi ultimi, per<br />
lo stesso motivo, può essere necessario cambiare i canali riservati.<br />
Per poter effettuare queste riconfigurazioni della rete, i no<strong>di</strong> fissi<br />
nelle vicinanze del nodo mobile, devono essere sempre attivi, o<br />
comunque risvegliabili con un segnale <strong>di</strong> wake up, in modo da<br />
creare una zona limitrofa al nodo mobile che gli garantisca in ogni<br />
momento la connettività.<br />
� Ridurre l’overhead. Oltre alle informazioni legate all’applicazione,<br />
in ogni pacchetto i no<strong>di</strong> inseriscono dati necessari alla gestione della<br />
comunicazione, pur essendo in<strong>di</strong>spensabili questi bit aggiuntivi<br />
comportano un <strong>di</strong>spen<strong>di</strong>o <strong>di</strong> energia. Per ridurre i consumi e<br />
aumentare la durata dei no<strong>di</strong>, è necessario limitare il numero <strong>di</strong><br />
informazioni scambiate senza compromettere le funzionalità della<br />
rete; ad esempio si <strong>di</strong>minuisce il numero <strong>di</strong> pacchetti riservati<br />
esclusivamente alla gestione ra<strong>di</strong>o, i quali sono privi del campo dati<br />
(payload) e quin<strong>di</strong> determinano uno spreco <strong>di</strong> risorse.<br />
20
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
� Tenere spento il più a lungo possibile il chip ra<strong>di</strong>o. Dato che la ra<strong>di</strong>o<br />
è il componente col maggior consumo energetico, è evidente che<br />
appena non è più richiesto il suo utilizzo essa sia <strong>di</strong>sattivata.<br />
1.6.3 Livello <strong>di</strong> rete<br />
Compito del livello <strong>di</strong> rete è gestire l’in<strong>di</strong>rizzamento e l’instradamento dei<br />
messaggi.<br />
Tenendo presente che l’obiettivo <strong>di</strong> una WSN è in maggior parte <strong>di</strong><br />
monitorare e tenere sotto controllo un fenomeno fisico, attraverso<br />
rilevazioni perio<strong>di</strong>che effettuate dai sensori, se questi dati venissero<br />
instradati nella rete senza alcun accorgimento, si verificherebbe un traffico<br />
elevato, con informazioni ripetitive ed inutili, che provocherebbero<br />
congestioni e soprattutto una drastica riduzione del tempo <strong>di</strong> vita della rete.<br />
Al fine <strong>di</strong> evitare questo problema urge una attenta progettazione e scelta<br />
del particolare algoritmo <strong>di</strong> routing da utilizzare.<br />
Lo scambio d’informazioni fra no<strong>di</strong> remoti, ovvero non nel reciproco raggio<br />
<strong>di</strong> copertura, avviene attraverso il transito per altri no<strong>di</strong> interme<strong>di</strong> finchè il<br />
messaggio non giunge a destinazione; si parla in questo caso <strong>di</strong> percorso<br />
multihop. Questo meccanismo richiede in genere la conoscenza della<br />
posizione relativa tra i no<strong>di</strong> che può essere memorizzata in vari mo<strong>di</strong>,<br />
definendo tipologie <strong>di</strong> protocolli <strong>di</strong>fferenti:<br />
� Proattiva (Proactive). Durante la fase <strong>di</strong> inizializzazione della rete<br />
si memorizzano in tabelle dette Look Up Table (LUT) tutti i<br />
cammini a peso minimo fra ogni coppia <strong>di</strong> no<strong>di</strong>. La creazione <strong>di</strong><br />
queste tabelle è un’operazione che richiede molta energia poiché, per<br />
realizzarla tutti i no<strong>di</strong> della WSN devono essere attivi e scambiare<br />
messaggi tra loro, per questo le tabelle vengono successivamente<br />
aggiornate solo in caso <strong>di</strong> malfunzionamento <strong>di</strong> qualche nodo. Le<br />
21
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
<strong>di</strong>mensioni <strong>di</strong> queste tabelle crescono rapidamente all’aumentare del<br />
numero dei no<strong>di</strong> e la loro memorizzazione richiede quin<strong>di</strong> memorie<br />
<strong>di</strong> gran<strong>di</strong> <strong>di</strong>mensioni, che implicano un considerevole consumo <strong>di</strong><br />
energia. Questi protocolli cercano <strong>di</strong> mantenere lo stato delle proprie<br />
tabelle il più aggiornato possibile, anche in mancanza <strong>di</strong> un effettivo<br />
utilizzo della rete. Esempi <strong>di</strong> questa classe <strong>di</strong> protocolli <strong>di</strong> routing<br />
sono:<br />
• DSDV (Highly Dynamic Destination-Sequenced Distance<br />
Vector routing protocol);<br />
• HSLS (Hazy Sighted Link State routing protocol);<br />
• OLSR (Optimized Link State Routing Protocol);<br />
• STAR (Source Tree Adaptive routing protocol).<br />
� Reattiva (Reactive). Il cammino a costo minimo viene in<strong>di</strong>viduato<br />
solamente quando è realmente necessario, questo consente <strong>di</strong> non<br />
dover memorizzare gran<strong>di</strong> tabelle poiché il percorso ottimale viene<br />
selezionato <strong>di</strong>namicamente tramite l’invio <strong>di</strong> dati. La ricerca del<br />
cammino migliore impiega la ra<strong>di</strong>o per un tempo considerevole, il<br />
che influisce negativamente sui consumi <strong>di</strong> potenza ma permette <strong>di</strong><br />
non dover impiegare memorie <strong>di</strong> gran<strong>di</strong> <strong>di</strong>mensioni. Un esempio <strong>di</strong><br />
questa classe <strong>di</strong> protocolli <strong>di</strong> routing può essere trovato in [7] dove<br />
Karp et al. presentano il Greedy Perimeter Stateless Routing<br />
(GPSR), un nuovo protocollo <strong>di</strong> routing per reti wireless a<br />
datagrammi. In GPSR viene utilizzata la posizione del router e della<br />
destinazione dei pacchetti per decidere il percorso <strong>di</strong> inoltro. Le<br />
uniche informazioni utilizzate riguardano i router e i vicini nella<br />
topologia della rete.<br />
� Tecniche ibride. L’utilizzo combinato delle due tecniche precedenti,<br />
permette la determinazione del cammino minimo nel momento <strong>di</strong><br />
22
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
effettivo bisogno quando si devono trasmettere messaggi, ma è poi<br />
possibile memorizzare il percorso in LUT <strong>di</strong> <strong>di</strong>mensioni limitate per<br />
un riutilizzo futuro. In questo modo si <strong>di</strong>spone dei vantaggi <strong>di</strong><br />
entrambe le strategie, riducendo le per<strong>di</strong>te <strong>di</strong> prestazioni tipiche dei<br />
singoli meto<strong>di</strong> considerati separatamente. Esempi <strong>di</strong> tecniche ibride<br />
per il routing possono essere trovati in tutti gli algoritmi Ant [8]. Gli<br />
algoritmi Ant sono una classe <strong>di</strong> agenti basati su algoritmi <strong>di</strong> routing<br />
che modellano il comportamento delle formiche. Le formiche sono,<br />
infatti, capaci <strong>di</strong> trovare il percorso più breve tra il formicaio e un<br />
punto del terreno in cui vi sia del cibo. L'aspetto interessante e<br />
curioso è che sono in grado <strong>di</strong> farlo senza informazioni visive (le<br />
formiche <strong>di</strong> molte specie sono infatti cieche), ma utilizzando segnali<br />
"odorosi". Quando una formica ha trovato del cibo, ritorna al<br />
formicaio depositando sul terreno una certa quantità <strong>di</strong> una sostanza<br />
chimica detta feromone. La <strong>di</strong>rezione del cammino <strong>di</strong> una formica<br />
<strong>di</strong>pende dalla quantità <strong>di</strong> feromone che essa percepisce: dove la<br />
concentrazione è più forte, è più probabile che la formica si <strong>di</strong>riga.<br />
Nel tempo le tracce <strong>di</strong> feromone sul terreno evaporano ed,<br />
eventualmente, sono rinforzate dal passaggio <strong>di</strong> altre formiche. Ora<br />
entra in gioco un meccanismo molto importante chiamato<br />
retroazione positiva: più formiche scelgono un percorso, più forte<br />
sarà la concentrazione <strong>di</strong> feromone e quin<strong>di</strong> ancora più formiche<br />
saranno richiamate sullo stesso percorso. Perciò, dopo una prima<br />
fase <strong>di</strong> transitorio in cui le formiche scelgono <strong>di</strong>rezioni <strong>di</strong>verse, si<br />
arriva ad una situazione stazionaria in cui la maggior parte delle<br />
formiche segue uno stesso percorso. Siccome il feromone evapora<br />
nel tempo, il percorso più breve sarà quello scelto alla fine dal<br />
"sistema formiche".<br />
23
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Analogamente gli agenti viaggiano nella rete co<strong>di</strong>ficando la qualità<br />
del cammino visitato e lasciando questa informazione nell’ultimo<br />
nodo attraversato. In ogni nodo un agente sceglie la prossima<br />
destinazione in maniera probabilistica ma comunque polarizzata<br />
verso il migliore dei cammini già noti. Questa tecnica risulta essere<br />
molto veloce per l’esplorazione <strong>di</strong> buoni percorsi e inoltre in questo<br />
modo si riescono facilmente a trovare buoni cammini alternativi in<br />
caso del fallimento <strong>di</strong> uno dei no<strong>di</strong> sull’albero <strong>di</strong> routing, proprio<br />
perchè ad ogni nodo l’agente cerca sempre un cammino intorno alla<br />
precedente soluzione (buona).<br />
Per completezza riportiamo <strong>di</strong> seguito anche altri protocolli <strong>di</strong> routing non<br />
basati sul para<strong>di</strong>gma del multihop:<br />
� FLOODING: è una vecchia tecnica dove un nodo che riceve<br />
dati o pacchetti li ritrasmette in modo broadcast (a meno che<br />
il pacchetto non abbia raggiunto un numero massimo <strong>di</strong> hop<br />
o che il nodo stesso sia la destinazione del pacchetto). Il<br />
floo<strong>di</strong>ng [3] è una tecnica reattiva e che non richiede un<br />
mantenimento della topologia ma presenta alcuni problemi<br />
che vanno risolti in fase <strong>di</strong> implementazione:<br />
i. Implosion: situazione in cui i duplicati <strong>di</strong> un<br />
messaggio siano inviati allo stesso nodo;<br />
ii. Overlap: quando due no<strong>di</strong> con<strong>di</strong>vidono la stessa<br />
regione <strong>di</strong> osservazione entrambi potrebbero rilevare<br />
gli stessi stimoli e quin<strong>di</strong> i no<strong>di</strong> vicini ricevono<br />
messaggi duplicati;<br />
iii. Resource Blindness: questo protocollo non tiene<br />
conto della risorsa energia <strong>di</strong>sponibile;<br />
� GOSSIPPING: è una variante del floo<strong>di</strong>ng solo che i no<strong>di</strong><br />
non usano il broadcast ma inviano i pacchetti ad un solo nodo<br />
24
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
selezionato in modo random tra tutti i vicini [3]. Così si evita<br />
il problema <strong>di</strong> implosione ma si impiega molto più tempo per<br />
propagare un messaggio a tutti i no<strong>di</strong>.<br />
� ENERGY EFFICIENT ROUTE: il percorso che viene<br />
seguito è quello più efficiente dal punto <strong>di</strong> vista energetico<br />
� LEACH (Low Energy Adaptive Clustering Hierarchy): è un<br />
protocollo basato sul clustering [10] che minimizza la<br />
<strong>di</strong>ssipazione <strong>di</strong> energia in una rete <strong>di</strong> sensori. Lo scopo <strong>di</strong><br />
questo protocollo è quello <strong>di</strong> scegliere in maniera random<br />
alcuni no<strong>di</strong> ed eleggerli a capo-cluster. Gli altri no<strong>di</strong>, invece<br />
si associano ad un cluster in modo da minimizzare la<br />
<strong>di</strong>ssipazione <strong>di</strong> energia. In questo modo il capo cluster riceve<br />
ed aggrega i dati dei no<strong>di</strong> appartenenti al cluster prima <strong>di</strong><br />
inviare questi alla stazione base. Dopo un certo periodo <strong>di</strong><br />
tempo la rete entra nuovamente in fase <strong>di</strong> setup e inizia<br />
nuovamente la fase <strong>di</strong> selezione dei capo- cluster.<br />
1.7 I SISTEMI OPERATIVI E LE RETI DI SENSORI<br />
Le caratteristiche delle reti <strong>di</strong> sensori in relazione alla progettazione <strong>di</strong> un<br />
sistema operativo devono essere adeguatamente tenute in considerazione.<br />
Uno <strong>degli</strong> aspetti più evidenti delle reti <strong>di</strong> sensori sono le ridotte <strong>di</strong>mensioni<br />
della piattaforma hardware e la scarsa <strong>di</strong>sponibilità <strong>di</strong> energia. Questi fattori<br />
influiscono sulla capacità <strong>di</strong> elaborazione del sistema, sulla quantità <strong>di</strong><br />
informazioni che è possibile scambiare e sulla capacità <strong>di</strong> comunicare con<br />
l'esterno. Il software sviluppato per le reti <strong>di</strong> sensori dovrà essere perciò<br />
molto semplice, per evitare operazioni inutili, e poco ingombrante in termini<br />
<strong>di</strong> occupazione <strong>di</strong> memoria.<br />
25
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Le reti <strong>di</strong> sensori sono soggette a continue sollecitazioni. Si pensi ad<br />
esempio alla quantità <strong>di</strong> pacchetti che ogni nodo deve trattare, sia perchè ha<br />
la necessità <strong>di</strong> inviare le informazioni raccolte, sia perchè la rete comunica<br />
secondo un protocollo multi-hop. Inoltre l'ambiente esterno deve essere<br />
continuamente monitorato e la rete, per poter garantite i servizi essenziali,<br />
deve continuamente scambiarsi delle informazioni <strong>di</strong> “servizio" (si pensi al<br />
problema della mobilità o a quello della sincronizzazione temporale). In<br />
pratica il sistema deve gestire una quantità non trascurabile <strong>di</strong> eventi nel<br />
modo più veloce possibile, per evitare <strong>di</strong> perdere informazioni preziose,<br />
però il livello <strong>di</strong> parallelismo insito in questo tipo <strong>di</strong> sistemi è molto basso<br />
rispetto ai sistemi convenzionali. Questo è dovuto principalmente alle<br />
limitazioni fisiche dei no<strong>di</strong> (bassa capacità <strong>di</strong> elaborazione, poca memoria,<br />
etc.) quin<strong>di</strong> si preferisce sfruttare le poche risorse per effettuare le<br />
operazioni essenziali. Come abbiamo già visto, le reti <strong>di</strong> sensori possono<br />
essere utilizzate in numerose applicazioni, <strong>di</strong>fferenti tra loro. Queste<br />
richiedono in molti casi dell'hardware de<strong>di</strong>cato e quin<strong>di</strong> sono necessarie<br />
delle reimplementazioni dello stesso software per adeguarlo ai <strong>di</strong>versi<br />
<strong>di</strong>spositivi. Tuttavia, se il software viene sviluppato seguendo il criterio <strong>di</strong><br />
modularità, non sono necessarie complete reimplementazioni <strong>di</strong><br />
un'applicazione ma dovrebbe essere sufficiente sostituire alcuni moduli per<br />
ottenere il medesimo risultato. Lo stesso problema sorge quando ad esempio<br />
si vuole sostituire un protocollo all'interno <strong>di</strong> un applicazione. In generale<br />
quin<strong>di</strong>, si dovrebbe progettare un sistema operativo in grado <strong>di</strong> adattarsi<br />
facilmente a tutti i cambiamenti tecnologici, sia hardware che software. I<br />
no<strong>di</strong> in alcune applicazioni si trovano a lavorare in ambienti critici che ne<br />
potrebbero alterare il funzionamento. Questi possono guastarsi o rimanere<br />
bloccati quin<strong>di</strong> è necessario sviluppare applicazioni tolleranti ai guasti.<br />
Anche il sistema operativo deve fare la sua parte, cioè deve supportare<br />
26
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
eventuali guasti dei <strong>di</strong>spositivi e favorire lo sviluppo <strong>di</strong> applicazioni<br />
affidabili e <strong>di</strong>stribuite, in conclusione deve garantire operazioni robuste.<br />
Per completezza ricor<strong>di</strong>amo che in letteratura si <strong>di</strong>stinguono principalmente<br />
due approcci allo sviluppo <strong>di</strong> sistemi operativi per reti <strong>di</strong> sensori senza cavo:<br />
o Sviluppare un sistema i cui componenti vengono compilati assieme<br />
all'applicazione (esempio TinyOs).<br />
o Sviluppare un sistema che includa i tra<strong>di</strong>zionali strati software dei<br />
sistemi general purpose in versione ridotta (esempio MANTIS [23])<br />
Riguardo il primo approccio, questo, <strong>di</strong> fatto, consente che una sola<br />
applicazione sia in esecuzione in un dato momento; tuttavia tale sistema<br />
permette <strong>di</strong> avere bassissimi consumi. Lo svantaggio però derivante da tale<br />
approccio è la limitata versalità e i seri vincoli <strong>di</strong> riconfigurabilità<br />
dell'applicazione.<br />
Riguardo invece il secondo approccio, risulta in questo caso <strong>di</strong>fficile tenere i<br />
consumi e le risorse impiegate sotto controllo, ma si guadagna in versatilità,<br />
potendo eseguire più applicazioni contemporaneamente.<br />
1.7.1 Introduzione a TinyOS<br />
TinyOS è un sistema operativo open-source, sviluppato dalla University of<br />
California at Berkeley. Data la possibilità <strong>di</strong> mo<strong>di</strong>ficare il co<strong>di</strong>ce, questo<br />
sistema operativo è <strong>di</strong>ventato la piattaforma <strong>di</strong> sviluppo per ogni soluzione<br />
proposta nel campo delle reti <strong>di</strong> sensori. In effetti grossi contributi sono<br />
stati forniti dalla comunità <strong>di</strong> sviluppatori, lo testimonia la lunga lista <strong>di</strong><br />
progetti attivi relativi a tutti campi della ricerca, da protocolli per<br />
l'instradamento dei pacchetti alla localizzazione, dalla realizzazione <strong>di</strong> un<br />
interfaccia grafica per lo sviluppo delle applicazioni all'estensione del<br />
27
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
compilatore ncc per il supporto <strong>di</strong> nuove piattaforme hardware (come la<br />
piattaforma 8051) 1 .<br />
TinyOS è stato progettato principalmente per le reti <strong>di</strong> sensori ed adotta<br />
soluzioni molto semplici ed efficienti, al fine <strong>di</strong> ridurre al massimo i<br />
consumi <strong>di</strong> energia. Infatti TinyOS non possiede un nucleo ma permette<br />
l'accesso <strong>di</strong>retto all'hardware, inoltre sparisce il concetto <strong>di</strong> processore<br />
virtuale per evitare i cambi <strong>di</strong> contesto, e quello <strong>di</strong> memoria virtuale: la<br />
memoria viene infatti considerata come un unico e lineare spazio fisico, che<br />
viene assegnato alle applicazioni a tempo <strong>di</strong> compilazione. In pratica viene<br />
eliminato qualsiasi tipo <strong>di</strong> overhead, poiché nelle reti <strong>di</strong> sensori questo<br />
causa un’inutile <strong>di</strong>spersione <strong>di</strong> energia senza portare tangibili vantaggi.<br />
Queste scelte impattano <strong>di</strong>rettamente sull'architettura che risulta molto<br />
compatta e ben si sposa con le <strong>di</strong>mensioni ridotte della memoria che è<br />
dell’or<strong>di</strong>ne <strong>di</strong> pochi KB.<br />
Lo scopo <strong>di</strong>chiarato dei progettisti <strong>di</strong> TinyOS era infatti quello <strong>di</strong>:<br />
1. ridurre i consumi <strong>di</strong> energia;<br />
2. ridurre il carico computazionale e le <strong>di</strong>mensioni del sistema<br />
operativo;<br />
3. supportare intensive richieste <strong>di</strong> operazioni che devono essere svolte<br />
concorrentemente e in maniera tale da raggiungere un alto livello<br />
robustezza ed un efficiente modularità.<br />
Per sod<strong>di</strong>sfare il requisito della modularità, TinyOS favorisce lo sviluppo <strong>di</strong><br />
una serie <strong>di</strong> piccoli componenti, ognuno con un ben precisa funzione, che<br />
realizza un qualche aspetto dell'hardware del sistema o <strong>di</strong> un'applicazione.<br />
Ogni componente poi, definisce un interfaccia che garantisce la riusabilità<br />
del componente ed eventualmente la sua sostituzione.<br />
1 http://tinyos.cvs.sourceforge.net/tinyos/<br />
28
Figura 1.3 : Modello a strati <strong>di</strong> TinyOS<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Guardando il modello a strati del sistema operativo (figura 1.3), possiamo<br />
intuire come sia facilitato lo sviluppo <strong>di</strong> applicazioni me<strong>di</strong>ante il riutilizzo<br />
dei componenti esistenti.<br />
TinyOS è stato implementato seguendo il modello ad eventi. Nei<br />
tra<strong>di</strong>zionali modelli infatti, è necessario allocare un certa quantità <strong>di</strong><br />
memoria sullo stack per ogni attività in esecuzione e inoltre, il sistema è<br />
soggetto a frequenti commutazioni <strong>di</strong> contesto per servire ogni tipo <strong>di</strong><br />
richiesta, come l'invio <strong>di</strong> pacchetti, la lettura <strong>di</strong> un dato su un sensore, etc.<br />
Poiché i no<strong>di</strong> non <strong>di</strong>spongono <strong>di</strong> grosse quantità <strong>di</strong> memoria il modello ad<br />
eventi ben si ad<strong>di</strong>ce ad un sistema continuamente sollecitato, in quanto<br />
utilizza il microprocessore nella maniera più efficiente possibile. Non sono<br />
permesse con<strong>di</strong>zioni <strong>di</strong> stallo né attese attive che sprecherebbero energia<br />
inutilmente. Quando invece non ci sono attività da eseguire il sistema mette<br />
a riposo il microprocessore che viene risvegliato all'arrivo <strong>di</strong> un evento.<br />
1.7.1.1 Caratteristiche tipiche<br />
Le caratteristiche tipiche del TinyOs si possono riassumere nei seguenti<br />
punti:<br />
• Architettura basata su componenti<br />
29
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Una applicazione è composta da uno o più componenti che possono<br />
<strong>di</strong>alogare tra loro facendo uso <strong>di</strong> due set <strong>di</strong> funzioni: i coman<strong>di</strong> e gli<br />
eventi. TinyOs mette a <strong>di</strong>sposizione del programmatore un set <strong>di</strong><br />
componenti standard. Un'applicazione può connettere tali<br />
componenti utilizzando delle specifiche <strong>di</strong> legame che sono<br />
in<strong>di</strong>pendenti dall'effettiva implementazione. Ogni componente<br />
inoltre contiene un'area dati chiamata frame, la quale viene allocata<br />
staticamente (figura 1.4).<br />
• Operazioni in <strong>di</strong>verse fasi<br />
La richiesta <strong>di</strong> una data operazione e il suo completamento sono due<br />
funzioni <strong>di</strong>stinte. I coman<strong>di</strong> tipicamente richiedono l'esecuzione <strong>di</strong><br />
un'operazione: quando questa termina, viene generato un evento che<br />
segnala all'applicazione il termine dell'operazione richiesta. Un<br />
esempio tipico è l'invio <strong>di</strong> un pacchetto: l'applicazione invoca il<br />
comando send per iniziare la trasmissione e il componente <strong>di</strong><br />
comunicazione segnala l'evento sendDone quando l'operazione è<br />
terminata. Esistono anche coman<strong>di</strong> al cui termine non è richiamato<br />
alcun evento (ad esempio l'accensione <strong>di</strong> un LED).<br />
• Concorrenza:<br />
Il TinyOs può eseguire un solo programma alla volta, tipicamente<br />
formato da più componenti. Ci sono due tipi <strong>di</strong> thread: task ed<br />
eventi hardware. I primi sono funzioni la cui esecuzione può essere<br />
ritardata: essi vengono eseguiti in or<strong>di</strong>ne secondo una coda FIFO.<br />
Gli eventi hardware hanno priorità massima e bloccano qualsiasi<br />
esecuzione in corso. Possono dunque nascere situazioni <strong>di</strong> data race<br />
(ad esempio l’aggiornamento <strong>di</strong> una variabile)<br />
• Active Messages<br />
Active messages è la tecnologia <strong>di</strong> rete utilizzata da TinyOs. Questo<br />
sistema permette <strong>di</strong> inviare messaggi a tutti o a un singolo nodo tra i<br />
30
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 1.4: Rappresentazione <strong>di</strong> un componente TinyOS<br />
vicini (eventuali protocolli <strong>di</strong> routing vengono implementati ad un<br />
livello superiore, quin<strong>di</strong> Active messages contiene solo un<br />
meccanismo <strong>di</strong> in<strong>di</strong>rizzamento verso i no<strong>di</strong> vicini). Ogni pacchetto<br />
spe<strong>di</strong>to contiene l'identificazione <strong>di</strong> un handler da richiamare sulla<br />
macchina <strong>di</strong> destinazione e il payload dei dati. Il principale<br />
svantaggio dell'approccio è che tutti i no<strong>di</strong> comunicanti devono<br />
avere lo stesso software o come minimo implementare un<br />
componente che definisca lo stesso handler.<br />
1.7.2 Introduzione a NesC<br />
NesC è il linguaggio <strong>di</strong> programmazione usato in ambiente TinyOs. La sua<br />
sintassi è molto simile al classico C con alcune <strong>di</strong>fferenze: supporta il<br />
modello <strong>di</strong> concorrenza del TinyOs e permette <strong>di</strong> collegare, strutturare<br />
componenti software. NesC permette ai programmatori <strong>di</strong> sviluppare<br />
componenti che possano essere facilmente assemblati tra loro.<br />
Le caratteristiche basilari del NesC possono essere così riassunte:<br />
1. nesC è una estensione del C: C produce co<strong>di</strong>ce efficiente per tutti i<br />
processori che vengono <strong>di</strong> solito usati nelle reti <strong>di</strong> sensori; fornisce<br />
31
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
tutte le caratteristiche necessarie per comunicare con l'hardware e<br />
l'interazione con co<strong>di</strong>ce già esistente è semplificata. Inoltre è un<br />
linguaggio molto conosciuto. D'altra parte però, C non aiuta molto a<br />
scrivere co<strong>di</strong>ce strutturato privo <strong>di</strong> errori. Il nesC garantisce più<br />
modularità grazie ad una sintassi molto ridotta e dà la possibilità <strong>di</strong><br />
strutturare i componenti collegandoli tra loro.<br />
2. Analisi <strong>di</strong> tutto il programma: I programmi nesC, in fase <strong>di</strong><br />
compilazione, vengono analizzati nella loro interezza per ottenere<br />
una sicurezza maggiore e per rendere possibile l'ottimizzazione. Di<br />
conseguenza, non esiste la possibilità <strong>di</strong> compiere compilazioni<br />
separate. D'altra parte i programmi scritti in nesC sono molto<br />
leggeri e <strong>di</strong> conseguenza la compilazione risulta comunque veloce.<br />
3. nesC è un linguaggio “statico”: Non esiste la possibilità <strong>di</strong> allocare<br />
memoria <strong>di</strong>namicamente. Questa restrizione rende più facile e<br />
accurata l'analisi del programma in fase <strong>di</strong> debug.<br />
4. nesC riflette la struttura del TinyOs: nesC è basato sul concetto<br />
<strong>di</strong> componente e supporta appieno il modello <strong>di</strong> concorrenza del<br />
TinyOs. Inoltre il TinyOs è stato completamente programmato in<br />
nesC. Nel momento in cui un'applicazione viene compilata, i<br />
componenti <strong>di</strong> TinyOs vengono compilati insieme ad essa e il<br />
risultato costituisce l'intero software del sensore. Questo approccio<br />
porta ad un ingente risparmio energetico; tuttavia la versatilità viene<br />
notevolmente limitata, non è possibile installare più applicazioni<br />
in<strong>di</strong>pendenti nello stesso sensore.<br />
32
1.8 LE PIATTAFORME HARDWARE<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Come già accennato nel paragrafo 1.4 le piattaforme hardware sono <strong>di</strong>verse,<br />
in questo paragrafo ci concentreremo in particolare su Mica2 e Mica2dot<br />
entrambe sviluppate dai ricercatori della University of California in Berkley.<br />
I no<strong>di</strong> sensore Mica2 sono equipaggiati con 512 KB <strong>di</strong> memoria flash per<br />
memorizzare in modo permanente i dati raccolti e <strong>di</strong>spongono <strong>di</strong> un<br />
connettore a 51-pin per l'aggiunta <strong>di</strong> un espansione (attuatori, <strong>di</strong>spositivi<br />
sensori, etc). Possiedono un clock esterno a 32 kHz che il sistema<br />
operativo, in questo caso TinyOS, utilizza per sincronizzarsi con i vicini a<br />
meno <strong>di</strong> +/- 1 ms e per assicurarsi che questi siano attivi ed in grado <strong>di</strong><br />
ascoltare le trasmissioni.<br />
I no<strong>di</strong> Mica2 possiedono tre led, uno rosso uno giallo e uno verde, che<br />
possono essere comandati via programma e utilizzati per visualizzare una<br />
qualche informazione <strong>di</strong> stato. Infine entrambe le piattaforme forniscono un<br />
collegamento seriale (sullo stesso connettore a 51-pin) per i trasferimenti <strong>di</strong><br />
dati e l'installazione delle applicazioni su ciascun nodo.<br />
Figura 1.5: Mica2<br />
33
Figura 1.6: Mica2DOT<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Il processore montato sulla piattaforma Mica è un Atmel ATMega128 AVR.<br />
AVR è un architettura Harvard a 8-bit con una memoria separata per le<br />
istruzioni e per i dati. I microcontrollori AVR supportano lo stato active e<br />
quello sleep.<br />
Per quanto riguarda il sistema <strong>di</strong> comunicazione ra<strong>di</strong>o utilizzato questo è un<br />
Chipcom CC1000 progettato per applicazioni che richiedono un basso<br />
consumo <strong>di</strong> energia ed è in grado <strong>di</strong> comunicare da pochi metri fino a<br />
centinaia <strong>di</strong> metri. Utilizza la co<strong>di</strong>fica Manchester e la modulazione FSK,<br />
supporta bande <strong>di</strong> frequenza a 315, 433, 868 e 915Mhz. Il sistema ra<strong>di</strong>o<br />
può lavorare in quattro <strong>di</strong>stinte modalità: transmit, receive, idle e sleep.<br />
Questo significa che mentre trasmette non è in grado <strong>di</strong> ascoltare eventuali<br />
trasmissioni da parte <strong>di</strong> altri no<strong>di</strong>, quin<strong>di</strong> le collisioni, se avvengono , non<br />
sono riconosciute. In effetti il protocollo MAC utilizzato è del tipo<br />
CSMA/CA.<br />
Nella tabella 1-2 si riportano alcune caratteristiche della piattaforma Mica2.<br />
Un’analisi esaustiva delle prestazioni <strong>di</strong> questi sensori viene riportata in [24]<br />
e comprende la tabella 1-3 riassuntiva delle prestazioni dei Mote mica2 e<br />
mica2dot.<br />
34
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Component Rate Strtup Time Current consumption<br />
CPU Active 4 MHz N/A 4.6 mA<br />
CPU Idle 4 MHz 1 us 2.4 mA<br />
CPU Suspend 32 kHz 4 ms 10 uA<br />
Ra<strong>di</strong>o Transmit 40 kHz 30 ms 12 mA<br />
Ra<strong>di</strong>o Receive 40 MHz 30 ms 3.6 mA<br />
Photo 2 kHz 10 ms 1.235 mA<br />
I2C Temp 2 Hz 500 ms 0.150 mA<br />
Pressare 10 Hz 500 ms 0.010 mA<br />
Press Temp 10 Hz 500 ms 0.010 mA<br />
Humi<strong>di</strong>ty 500 Hz 500 ms 0.775 mA<br />
Thermopile 2000 Hz 200 ms 0.170 mA<br />
Thermistor 2000 Hz 10 ms 0.126 mA<br />
Tabella 1-5: Alcune caratteristiche della piattaforma Mica2<br />
Mica 2 Mica2dot<br />
AVAILABLE THROUGHPUT 4.6 Kbps 4.6 Kbps<br />
POWER CONSUMPTION<br />
Reception 16 mA 12 mA<br />
Transmission 18 mA 14 mA<br />
Computation (processor only) 8 mA 8 mA<br />
Power down mode 10 uA 10 uA<br />
TRASMISSION RANGE<br />
With mormal weather con<strong>di</strong>tion 55 m 135 m<br />
With fog, rain 10 m<br />
With maximun tx power (normal weather con<strong>di</strong>tion) 70 m 230 m<br />
Minimum ground <strong>di</strong>stance 1 m 1 m<br />
Minimum horizontal <strong>di</strong>stance 50 cm 50 cm<br />
CARRIER SENSING RANGE 275 m<br />
Tabella 1-6: Tabella comparativa delle prestazioni <strong>di</strong> mica2 e mica 2 dot<br />
35
1.8.1 Sensori per Mica2<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
La modularità che sta alla base del progetto <strong>di</strong> questa piattaforma ha<br />
permesso la realizzazione <strong>di</strong> numerose schede <strong>di</strong> sensori <strong>di</strong> vario tipo. La<br />
scheda <strong>di</strong> riferimento per i no<strong>di</strong> tipo Mica2 è la Mica Sensorboard<br />
(MTS300CA), una scheda molto flessibile dalle varie modalità <strong>di</strong> utilizzo.<br />
Questa scheda infatti può essere impiegata per applicazioni che includono il<br />
rilevamento della presenza <strong>di</strong> veicoli, l'analisi <strong>di</strong> movimenti sismici, il<br />
riconoscimento <strong>di</strong> oggetti in movimento, la localizzazione ed altre<br />
applicazioni. Il resto del paragrafo analizza i dettagli <strong>di</strong> tale scheda.<br />
Microfono<br />
Il microfono può avere due principali usi:<br />
• localizzazione acustica<br />
• registrazione e misurazione dei suoni<br />
La localizzazione acustica è una possibilità offerta da questa scheda che può<br />
risultare molto utile. Il funzionamento è il seguente: un nodo invia un<br />
pacchetto via ra<strong>di</strong>o e contemporaneamente emette un suono tramite un<br />
segnalatore (<strong>di</strong>sponibile sulla scheda), un nodo vicino, all'arrivo del<br />
pacchetto, azzera un contatore che poi incrementa con una certa frequenza.<br />
Il contatore viene incrementato fino a quando lo stesso nodo non avverte il<br />
segnale acustico. A questo punto, moltiplicando il valore del contatore per la<br />
frequenza <strong>di</strong> incremento, si ottiene all'incirca l'intervallo <strong>di</strong> tempo occorso al<br />
segnale acustico per raggiungere il destinatario. Conoscendo quin<strong>di</strong> il<br />
valore della velocità del suono si ottiene in modo approssimato la <strong>di</strong>stanza<br />
tra due no<strong>di</strong>.<br />
Segnalatore<br />
Questo <strong>di</strong>spositivo è in grado <strong>di</strong> emettere un unico suono alla frequenza <strong>di</strong> 4<br />
kHz e viene utilizzato principalmente nella localizzazione dei no<strong>di</strong>.<br />
Luce e temperatura<br />
36
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Questa scheda <strong>di</strong>spone <strong>di</strong> sensori in grado <strong>di</strong> misurare la quantità <strong>di</strong> luce<br />
nell'ambiente e la temperatura. I sensore della luce è semplicemente una<br />
fotocellula CdSe. La massima sensibilità <strong>di</strong> questa fotocellula permette <strong>di</strong><br />
rilevare raggi <strong>di</strong> luce fino ad una lunghezza d'onda pari a 690 nm. Il<br />
termistore invece è un Panasonic ERT-J1VR103J ed è in grado <strong>di</strong> rilevare<br />
temperature che vanno da -40 a 70 °C.<br />
Accelerometro a 2-Assi<br />
L'accelerometro è un <strong>di</strong>spositivo MEMS a 2-assi ed è in grado <strong>di</strong> rilevare<br />
accelerazioni fino a ±2 g. E’ utilizzabile per rilevare movimenti, vibrazioni<br />
e/o misurazioni sismiche.<br />
Magnetometro a 2-Assi<br />
I sensore è un Honeywell HNC1002. Il magnetometro può misurare il<br />
campo magnetico terrestre ed altri piccoli campi. Un applicazione in cui può<br />
essere impiegato è il rilevamento della presenza <strong>di</strong> veicoli.<br />
TIPO DESCRIZIONE<br />
MTS101 Monta un termistore <strong>di</strong> precisione e sensori <strong>di</strong> luminosità, ed è utilizzabile<br />
in varie aree<br />
MTS300/ MTS310 Supporta una grande varietà <strong>di</strong> sensori per MICA e MICA2<br />
MDA500 Fornisce una interfaccia flessibile per collegamenti con no<strong>di</strong> <strong>di</strong> tipo<br />
MICA2DOT<br />
MTS400/420 È in grado <strong>di</strong> effettuare il monitoraggio ambientale ed eventualmente può<br />
essere montato un GPS (MICA2)<br />
MDA300 È in grado <strong>di</strong> acquisire dati e monitorare l’ambiente (MICA2)<br />
MTS510 Supporta sensori <strong>di</strong> luce, accelerazione ed un microfono (MICA2DOT)<br />
MEP401 Moduli per luce, umi<strong>di</strong>tà e pressione barometrica e temperatura (MICA2)<br />
MEP500 Modulo per temperatura e umi<strong>di</strong>tà (MICA2DOT)<br />
Tabella 1-7: Schede <strong>di</strong>sponibili per piattaforma MICA<br />
37
1.9 APPLICAZIONI<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Le applicazioni delle reti <strong>di</strong> sensori sono svariate e con<strong>di</strong>zionano i no<strong>di</strong><br />
stessi che possono essere dotati <strong>di</strong> sensori completamente <strong>di</strong>versi. E’<br />
possibile, come accennato prima, misurare una vastissima gamma <strong>di</strong><br />
grandezze fisiche come l’umi<strong>di</strong>tà, la pressione, la temperatura, il suono,<br />
l’intensità luminosa, le <strong>di</strong>mensioni <strong>di</strong> un oggetto, la presenza <strong>di</strong> oggetti in<br />
movimento e anche la loro accelerazione.<br />
I sensori, grazie alle ridotte <strong>di</strong>mensioni, si adattano bene a strutture ostili e<br />
inaccessibili. Inoltre grazie al loro elevato numero, risulta particolarmente<br />
facile monitorare grandezze in aree relativamente ampie.<br />
Le reti <strong>di</strong> sensori ai giorni nostri sono utilizzati in svariati campi come per<br />
esempio l’ambiente, la me<strong>di</strong>cina, per uso domestico (domotica) e per<br />
applicazioni militari e commerciali.<br />
o Ambiente<br />
Alcune applicazioni riguardano l'osservazione <strong>degli</strong> spostamenti <strong>di</strong><br />
animali, uccelli, specie marine, insetti; il monitoraggio delle con<strong>di</strong>zioni<br />
ambientali a cui sono sottoposte le colture e gli allevamenti <strong>di</strong> bestiame;<br />
il riconoscimento <strong>degli</strong> incen<strong>di</strong> boschivi; la ricerca metereologica e<br />
geofisica; il riconoscimento delle inondazioni; la mappatura della<br />
biocomplessità <strong>di</strong> un ambiente; lo stu<strong>di</strong>o dell'inquinamento. Alcune<br />
implementazioni <strong>di</strong> questi esempi li troviamo nel sistema per il<br />
riconoscimento delle inondazioni denominato ALERT [14], utilizzato<br />
negli Stati Uniti; nella mappatura della biocomplessità, con il sistema<br />
installato nella James Reserve in Southern California [15];<br />
nell'osservazione <strong>degli</strong> spostamenti <strong>degli</strong> uccelli migratori, con il<br />
progetto denominato Great Duck Island Habitat Monitoring [16],[17] del<br />
quale viene riportata l’architettura generale in figura 1.7 (fonte:<br />
http://www.greatduckisland.net/ ).<br />
38
o Applicazioni militari<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 1.7: Architettura del progetto Great Duck Island<br />
Le reti <strong>di</strong> sensori possono essere parte integrante dei sistemi militari <strong>di</strong><br />
comando, controllo, comunicazione, elaborazione, intelligence,<br />
sorveglianza, riconoscimento ed in<strong>di</strong>viduazione. La rapi<strong>di</strong>tà <strong>di</strong><br />
collocazione, l'auto-organizzazione e la tolleranza ai guasti sono<br />
caratteristiche che rendono queste reti particolarmente adatte<br />
all'impiego in campo militare. Dal momento che i no<strong>di</strong> possono<br />
popolare densamente una qualsiasi area ed hanno un costo ridotto, la<br />
<strong>di</strong>struzione <strong>di</strong> alcuni no<strong>di</strong> in seguito ad un azione ostile non ne inibisce<br />
il funzionamento globale. Alcune applicazioni sono il monitoraggio<br />
delle forze alleate; il riconoscimento del nemico; l'in<strong>di</strong>viduazione <strong>degli</strong><br />
obbiettivi; la sorveglianza <strong>di</strong> intere aree; il riconoscimento e<br />
l'in<strong>di</strong>viduazione <strong>di</strong> attacchi nucleari, biologici e chimici.<br />
39
o Sanità<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Alcune applicazioni nella sanità sono: la realizzazione <strong>di</strong> interfacce per i<br />
<strong>di</strong>sabili; il monitoraggio integrato dei pazienti; la somministrazione <strong>di</strong><br />
farmaci negli ospedali; il telemonitoraggio dei dati fisiologici <strong>di</strong> un<br />
in<strong>di</strong>viduo; il tracciamento e il monitoraggio dei pazienti e del personale<br />
me<strong>di</strong>co negli ospedali. Un esempio <strong>di</strong> telemonitoraggio dei dati<br />
fisiologici <strong>di</strong> un paziente è dato dal sistema Health Smart Home,<br />
realizzato dalla Facoltà <strong>di</strong> me<strong>di</strong>cina <strong>di</strong> Grenoble - Francia [18].<br />
o Uso domestico<br />
Un ambiente in grado <strong>di</strong> riconoscere l’utente presente al suo interno può<br />
pre<strong>di</strong>sporre tutta una serie <strong>di</strong> servizi personalizzati <strong>di</strong>fferenti a seconda<br />
<strong>di</strong> chi è l’ospite, inoltre i no<strong>di</strong> sensore possono essere inseriti negli<br />
apparecchi elettrici, come forni a microonde, frigoriferi, VCR [19].<br />
Questi possono interagire tra loro e con una rete esterna, via internet o<br />
via satellite e permettono all'utente <strong>di</strong> comandare facilmente gli<br />
elettrodomestici a <strong>di</strong>stanza. Più in generale, le reti <strong>di</strong> sensori possono<br />
essere utilizzate per realizzare ambienti intelligenti non solo in casa ma<br />
anche negli uffici. Un esempio è il Residential Laboratory della Georgia<br />
Institute of Tecnology [20]. Gli obbiettivi <strong>di</strong> questo laboratorio sono<br />
l'affidabilità, la persistenza e la trasparenza dell'automazione.<br />
o Applicazioni commerciali<br />
Altre possibili applicazioni sono: la realizzazione <strong>di</strong> tastiere virtuali;<br />
l'analisi del comportamento dei materiali sottoposti a stress meccanico,<br />
la qualità <strong>di</strong> un prodotto; guida e controllo dei robot nelle industrie<br />
automatizzate.<br />
Ma anche il monitoraggio dell’aria all’interno <strong>degli</strong> uffici può essere<br />
eseguito per esempio con una rete <strong>di</strong> sensori. Il flusso <strong>di</strong> aria<br />
40
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
con<strong>di</strong>zionata è controllato in maniera centralizzata; l’uso dei sensori può<br />
portare ad una riduzione del consumo <strong>di</strong> energia.<br />
Altre applicazioni infine in ambito commerciale sono:<br />
• guida e controllo <strong>di</strong> robot nei processi industriali;<br />
• rilevazione <strong>di</strong> furti d’auto entro una determinata area geografica non<br />
troppo estesa;<br />
• la verifica delle categorie e della qualità <strong>di</strong> vari articoli presenti in<br />
un grande magazzino;<br />
• controllo del traffico tramite reti <strong>di</strong> sensori.<br />
41
Capitolo 2<br />
Affidabilità nelle reti <strong>di</strong> sensori senza cavo<br />
2.1 IL CONCETTO DI AFFIDABILITA’<br />
L’esigenza <strong>di</strong> ottenere particolari requisiti <strong>di</strong> affidabilità dai sistemi risulta<br />
essere sempre più un argomento <strong>di</strong> primaria importanza e ha portato a<br />
continue rivisitazioni del concetto <strong>di</strong> dependability. Nel 1982 Laprie<br />
definiva la dependability <strong>di</strong> un sistema come: “...the ability of a system to<br />
accomplish the tasks (or,equivalently, to provide the service) which are<br />
expected to it” , mentre nel 2001 sempre Laprie la ridefinì come<br />
“...the ability to deliver service that can justifiably be trusted ” per poi<br />
infine definire nel 2004 la dependability <strong>di</strong> un sistema come: “...ability to<br />
avoid service failures that are more frequent and more severe than<br />
acceptable” ovvero l'abilità <strong>di</strong> un sistema <strong>di</strong> fornire un servizio che può<br />
essere considerato "fidato" in maniera giustificata.<br />
In realtà il termine va inteso come un insieme <strong>di</strong> attributi <strong>di</strong> qualità<br />
(dependability attributes) che assumono singolarmente un’enfasi relativa<br />
alla natura del sistema cui si riferiscono e al particolare contesto applicativo:<br />
42
� Availability<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
L’availability è sinteticamente definita come la probabilità che un<br />
sistema sia pronto a fornire il servizio in un certo istante t, ovvero:<br />
A=P(!Failure at t)<br />
Più esplicitamente un sistema è available in un dato istante t se è in<br />
grado <strong>di</strong> fornire un servizio corretto.<br />
� Reliability<br />
La reliability R(t) è la misura della continuità <strong>di</strong> un servizio ovvero la<br />
misura dell’intervallo <strong>di</strong> tempo in cui viene fornito un servizio corretto:<br />
� Safety<br />
R(t)=P(!Failure in (0,t))<br />
Per safety si intende generalmente l’assenza <strong>di</strong> con<strong>di</strong>zioni <strong>di</strong><br />
funzionamento che possano portare il sistema a danneggiare gli utenti<br />
e/o l’ambiente in cui opera. Dal punto <strong>di</strong> vista matematico la safety S(t)<br />
è la probabilità che non vi siano guasti catastrofici in [0,t].<br />
S(t)= P (!CatastrophicFailures in [0,t])<br />
È chiaro che il concetto <strong>di</strong> safety risulta relativo alla soggettiva<br />
valutazione dei rischi e dell’entità dei danni provocati dal sistema.<br />
� Performability<br />
La performability è una metrica introdotta per valutare le prestazioni del<br />
sistema in caso <strong>di</strong> guasto.<br />
� Mantainability<br />
La mantainability M(t) è definita come la capacità <strong>di</strong> un sistema <strong>di</strong><br />
essere sottoposto a mo<strong>di</strong>fiche e riparazioni, ovvero <strong>di</strong> poter essere<br />
facilmente ripristinato in seguito al verificarsi <strong>di</strong> un guasto.<br />
43
� Security<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
La security è definita come l’assenza <strong>di</strong> manipolazioni improprie e<br />
accessi non autorizzati al sistema. Più in dettaglio un sistema sicuro è un<br />
sistema in cui coesistono gli attributi <strong>di</strong> availability (riadattata alla<br />
<strong>di</strong>sponibilità del sistema solo verso utenti autorizzati), confidentiality<br />
(prevenzione della <strong>di</strong>ffusione non autorizzata delle informazioni) e<br />
integrità (prevenzione <strong>di</strong> alterazioni improprie dello stato del sistema.<br />
2.2 AFFIDABILITA’ IN RETI DI SENSORI SENZA CAVO<br />
Nell’ambito specifico delle reti <strong>di</strong> sensori senza cavo il concetto <strong>di</strong><br />
affidabilità si formalizza come la capacità che deve avere una rete <strong>di</strong><br />
conservare le proprie funzionalità in<strong>di</strong>pendentemente dall’eventuale guasto<br />
<strong>di</strong> qualche sensore o semplicemente da una trasmissione fallita.<br />
Un nodo, ad esempio, può <strong>di</strong>ventare inutilizzabile a causa dell’esaurimento<br />
della batteria o per danni fisici subiti nell’ambiente operativo.<br />
L’affidabilità riveste un ruolo sempre più importante nella progettazione<br />
delle Wireless Sensor Network visto che queste sono sempre più utilizzate in<br />
applicazioni mission critical come: rilevazione <strong>di</strong> intrusioni, applicazioni<br />
militari, etc. Il suo stu<strong>di</strong>o è reso, però, complicato da più fattori, già<br />
analizzati nei paragrafi precedenti come:<br />
• la limitatezza delle risorse sia energetiche che <strong>di</strong> memorizzazione e<br />
<strong>di</strong> computazione dei no<strong>di</strong>;<br />
• limitata robustezza fisica dei sensori che assume un ruolo non <strong>di</strong><br />
poco rilievo visto che le WSN vengono spesso utilizzate in ambienti<br />
esterni avversi e persino estremi;<br />
• la casualità della topologia della rete.<br />
44
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Relativamente alla fase <strong>di</strong> progettazione <strong>di</strong> una Wireless Sensor Network gli<br />
aspetti su cui incide l’affidabilità e che quin<strong>di</strong> devono essere debitamente<br />
presi in considerazione sono:<br />
1. Coverage & Deployment: con il quale si cerca <strong>di</strong> stimare un numero<br />
sufficiente <strong>di</strong> no<strong>di</strong> sensori affinché un evento possa essere esaminato<br />
nella sua totalità. Al tempo stesso con questo aspetto si cerca <strong>di</strong><br />
stabilire in che modo effettuare una misura accurata dei dati<br />
osservati e in che modo effettuare il deployment dei no<strong>di</strong> per la<br />
conformazione della rete.<br />
2. Information accurancy: con il quale ci si concentra principalmente<br />
sulla modalità <strong>di</strong> classificazione dei dati raccolti e sulla definizione<br />
<strong>di</strong> strategie per il trattamento delle misurazioni non accurate.<br />
3. Dependable data trasport: aspetto con il quale si definiscono<br />
strategie per assicurare il recapito delle misurazioni al centro<br />
raccolta. In particolare si definiscono strategie per combattere errori<br />
<strong>di</strong> trasmissione, <strong>di</strong> omissione e <strong>di</strong> congestione<br />
Spesso fornire un certo livello <strong>di</strong> affidabilità risulta arduo, soprattutto in<br />
alcuni campi applicativi. Ad esempio il monitoraggio <strong>di</strong> strutture <strong>di</strong>namiche<br />
[1], richiede alti requisiti <strong>di</strong> affidabilità, che devono ben amalgamarsi con i<br />
comuni attributi <strong>di</strong> efficienza energetica, scalabilità e autoconfigurazione<br />
tipici <strong>di</strong> una WSN. In particolare si può avere necessità <strong>di</strong>:<br />
� una fine sincronizzazione temporale;<br />
� minimizzare l’intervento umano sulla rete.<br />
� una copertura minima dell’area da monitorare;<br />
Riguardo il primo aspetto questo risulta importante al fine <strong>di</strong> <strong>di</strong>sporre <strong>di</strong> una<br />
caratterizzazione temporale precisa del fenomeno osservato. Questo<br />
requisito può essere rilassato nel caso in cui si considera una struttura della<br />
rete in cui i no<strong>di</strong> sensori sono organizzati in cluster in quanto si potrebbe<br />
richiedere la sincronizzazione per ogni cluster e non dell’intera rete.<br />
45
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Riguardo il secondo requisito questo risulta sempre più dominante nelle<br />
attuali installazioni <strong>di</strong> Wireless Sensor Network. L’intervento umano,<br />
spesso limitato alla sola sostituzione delle batterie dei no<strong>di</strong>, o alla<br />
sostituzione <strong>di</strong> un nodo malfunzionante può risultare spesso improponibile<br />
(in caso <strong>di</strong> reti in scenari avversi) o estremamente costoso e per questo deve<br />
essere ridotto quanto più è possibile al minimo. Tecniche che cercano <strong>di</strong><br />
sod<strong>di</strong>sfare questa necessità sono basate sull’utilizzo <strong>di</strong> strategie <strong>di</strong> “load<br />
balancing” e <strong>di</strong> “incremento della vita delle batterie”.<br />
Il terzo aspetto, infine, è inteso come la possibilità <strong>di</strong> avere a <strong>di</strong>sposizione<br />
un minimo ammontare <strong>di</strong> misurazioni al fine <strong>di</strong> poter avere una<br />
caratterizzazione completa del fenomeno che si sta analizzando e sarà<br />
analizzato in dettaglio nel successivo paragrafo.<br />
2.2.1 Il problema della copertura<br />
Per comprendere bene cosa si intende per problema <strong>di</strong> copertura si può<br />
immaginare uno scenario in cui si hanno a <strong>di</strong>sposizione n sensori,<br />
organizzati in un cluster, con i quali bisogna effettuare il monitoraggio <strong>di</strong> un<br />
ponte al fine <strong>di</strong> effettuarne una analisi delle vibrazioni. Un requisito<br />
potrebbe essere avere almeno k
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Un esempio ,che vede uno scenario composto da una rete <strong>di</strong> sensori<br />
utilizzata per il monitoraggio <strong>di</strong> <strong>di</strong>sastri ambientali come gli incen<strong>di</strong>,<br />
chiarisce ancora meglio come la copertura può essere fondamentale per la<br />
definizione della dependability <strong>di</strong> un sistema. Una visione dell’architettura è<br />
mostrata in figura 2.1. In questo caso è necessario per far scattare l’allarme<br />
<strong>di</strong> incen<strong>di</strong>o, che almeno un numero significativo <strong>di</strong> sensori mi forniscano<br />
misurazioni <strong>di</strong> temperature elevate e che quin<strong>di</strong> si abbia una adeguata<br />
copertura delle varie zone da monitorare. È chiaro che per avere una chiara<br />
<strong>di</strong>namica della temperatura nel tempo è necessario che i vari sensori siano<br />
sincronizzati tra <strong>di</strong> loro ed inoltre che siano dotati <strong>di</strong> un modulo in grado <strong>di</strong><br />
portare avanti una procedura <strong>di</strong> localizzazione se si suppone che questi siano<br />
<strong>di</strong>sposti in maniera casuale nell’ambiente (tramite lancio attraverso un<br />
Figura 2.1: Architettura WSN per rilevazione incen<strong>di</strong>o<br />
47
aereo).<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
In letteratura il problema della copertura è stato trattato secondo vari punti<br />
<strong>di</strong> vista. Per esempio l’ ”Art Gallery Problem” si concentra sul determinare<br />
il numero <strong>di</strong> controllori necessari per coprire una galleria d’arte in modo tale<br />
che ogni punto <strong>di</strong> essa sia monitorata almeno da un controllore. Questo<br />
problema è stato <strong>di</strong>mostrato essere risolvibile in uno spazio 2D ma si è<br />
mostrato <strong>di</strong> tipo NP-hard se è esteso ad uno spazio 3D [66]. Il lavoro <strong>di</strong><br />
Meguer<strong>di</strong>chian et al. [67] definisce invece una metrica per la copertura dei<br />
sensori denominata sorveglianza (surveillance) utilizzabile come misura<br />
della qualità del servizio <strong>di</strong> una particolare rete <strong>di</strong> sensori senza cavo.<br />
Lo stesso problema della copertura è <strong>di</strong>rettamente collegato al risparmio<br />
energetico dei no<strong>di</strong>, infatti moltissimi lavori in letteratura sono de<strong>di</strong>cati a<br />
questa tematica e in particolare al problema dello scheduling ottimale<br />
dell’accensione dei no<strong>di</strong> sensori al fine <strong>di</strong> preservare l’energia. Questi lavori<br />
si basano sul concetto <strong>di</strong> spegnere selettivamente i no<strong>di</strong> sensori senza però<br />
inficiare sulla copertura totale che deve essere fornita.<br />
In [68] propone una euristica per selezionare sets <strong>di</strong> sensori mutuamente<br />
esclusivi per provvedere a una completa copertura dell’area da monitorare.<br />
Sempre basandosi sullo spegnimento dei no<strong>di</strong> [71] propone uno schema<br />
molto interessante basato su un algoritmo <strong>di</strong> controllo della densità al fine <strong>di</strong><br />
porre in uno stato <strong>di</strong> sleep alcuni sensori che appartengono ad aree popolate<br />
densamente, in modo da assicurare una lunga vita alla rete. I no<strong>di</strong> in<br />
sleeping mode sono poi risvegliati perio<strong>di</strong>camente e non fanno altro che<br />
controllare se devono sopperire a fallimenti <strong>di</strong> no<strong>di</strong> vicini. Risulta chiaro<br />
come la frequenza del risveglio venga settata in modo tale da essere un<br />
giusto compromesso tra la densità <strong>di</strong> no<strong>di</strong> desiderata e consumo energetico.<br />
gli autori riescono a <strong>di</strong>mostrare che un tale schema estende il periodo <strong>di</strong> vita<br />
della rete secondo una proporzione lineare rispetto al numero <strong>di</strong> no<strong>di</strong><br />
utilizzati, usando circa l’1% del totale dell’energia consumata e resistendo al<br />
48
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
38% <strong>di</strong> fallimenti dei no<strong>di</strong>. Un altro schema <strong>di</strong> scheduling atto a preservare<br />
la copertura <strong>di</strong> una rete viene proposto da Tian et al. [69] dove l’analisi è<br />
incentrata sul determinare quali no<strong>di</strong> possono essere spenti e quando devono<br />
essere risvegliati.<br />
2.3 AFFIDABILITA’: STATO DELL’ARTE<br />
Molti sono gli stu<strong>di</strong> presenti in letteratura che sono de<strong>di</strong>cati alla affidabilità<br />
nelle reti <strong>di</strong> sensori senza cavo. Un primo esempio è il lavoro <strong>di</strong> Basile et al.<br />
[38] dove sono analizzate e proposte strategie al fine <strong>di</strong> costruire reti<br />
wireless e reti ad-hoc affidabili e sicure. Il fulcro del lavoro è sulla nozione<br />
<strong>di</strong> inner-circle consistency, ovvero la cooperazione tra i no<strong>di</strong> locali viene<br />
sfruttata al fine <strong>di</strong> neutralizzare errori e attacchi alla sorgente in modo tale<br />
da evitare che questi si possano propagare in tutta la rete. Come strumento<br />
per la valutazione delle strategie proposte si considera un modello dei<br />
fallimenti in cui le possibili cause <strong>di</strong> fallimento sono i crashing o i<br />
Byzantine behavior. Insieme al modello dei fallimenti viene utilizzato anche<br />
un modello della rete in cui si adottano sia tecniche statistiche sulla<br />
clusterizzazione che tecniche orientate al rispetto della security.<br />
Gli effetti sollevati dal fallimento <strong>di</strong> un singolo nodo sullo stato <strong>di</strong><br />
funzionamento <strong>di</strong> una WSN sono invece analizzati nel lavoro <strong>di</strong> Shakkottai<br />
et al. [39]. In questo contesto è stato in<strong>di</strong>viduato un limite superiore alla<br />
probabilità che tutti i no<strong>di</strong> siano connessi e tutta l’area della rete sia coperta,<br />
questo nell’ipo<strong>tesi</strong> che i no<strong>di</strong> siano uniformemente <strong>di</strong>stribuiti sul suolo e che<br />
la probabilità <strong>di</strong> fallimento sia anch’essa uniforme in tutta la rete. Viene<br />
inoltre ricavata una con<strong>di</strong>zione necessaria e sufficiente affinché la rete<br />
continui a coprire l’intera area (nonostante l’inaffidabilità dei no<strong>di</strong> che la<br />
compongono) e viene anche ricavata la minima probabilità <strong>di</strong><br />
funzionamento <strong>di</strong> un nodo al <strong>di</strong> là della quale la “copertura” dell’area non è<br />
49
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
più garantita. Un aspetto non contemplato dal lavoro è però come la<br />
connettività sia influenzata dalla morte <strong>di</strong> no<strong>di</strong> faulty o con batterie scariche,<br />
ipo<strong>tesi</strong> in cui non varrebbe più l’assunzione <strong>di</strong> densità uniforme della rete.<br />
Un modello <strong>di</strong> reliability è poi fornito in [40] e [41]. In [40] sono presentati<br />
alcuni modelli a catene <strong>di</strong> Markow per <strong>di</strong>verse tipologie <strong>di</strong> sensori. La<br />
reliability viene calcolata per <strong>di</strong>versi “failure rate” e poi i modelli sono<br />
comparati in termini <strong>di</strong> costo e della <strong>di</strong>stribuzione cumulativa e me<strong>di</strong>a della<br />
funzione <strong>di</strong> reliability. Arricchisce il lavoro anche un’analisi comparativa<br />
della reliability della rete con<strong>di</strong>zionata all’utilizzo <strong>di</strong> tecniche <strong>di</strong> ridondanza<br />
spaziale o <strong>di</strong> co<strong>di</strong>ci ECC (error correcting code)<br />
In [41] Iyengar et al. focalizzano l’attenzione sulle misure <strong>di</strong> reliability per<br />
WSN, fornendo anche delle stime sul minimo e massimo ritardo nella<br />
consegna <strong>di</strong> un messaggio <strong>di</strong> un nodo verso il sink. Viene adottato all’uopo<br />
un modello a grafo probabilistico per rappresentare la rete, dove le<br />
probabilità (<strong>di</strong> per<strong>di</strong>ta <strong>di</strong> pacchetti) sono ricavate da stime sul tasso <strong>di</strong><br />
fallimento dei sensori. Viene definita la reliability <strong>di</strong> una WSN come la<br />
probabilità che esista un cammino tra il sink e almeno un unico nodo<br />
funzionante del cluster: adottando questa definizione viene <strong>di</strong>mostrato<br />
come per reti <strong>di</strong> topologia arbitraria, la soluzione del modello <strong>di</strong> affidabilità<br />
considerato rappresenti un problema <strong>di</strong> complessità non polinomiale, tranne<br />
che per un caso particolare analizzato, per cui vengono fornite anche delle<br />
misure ottenute tramite simulazione.<br />
In [42] Gupta e Kumar analizzano l’impatto della connettività sulla<br />
reliability della rete. A tale scopo viene analizzano il comportamento <strong>di</strong> una<br />
WSN organizzata in clusters, attraverso un fault model in cui vengono<br />
considerati solo i fallimenti del gateway relativi all’esaurimento delle<br />
batterie e a fallimenti del modulo ra<strong>di</strong>o: questi ultimi dovuti sia a guasti<br />
hardware che a fallimenti <strong>di</strong> no<strong>di</strong> nel suo range operativo. Tutti i fallimenti<br />
considerati sono <strong>di</strong> durata permanente. In base a questo modello dei<br />
50
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
fallimenti, viene proposto un meccanismo <strong>di</strong> recupero basato sul consenso<br />
tra i gateway ancora funzionanti. Per testare la copertura della strategia<br />
proposta, viene adottata una tecnica <strong>di</strong> iniezione dei guasti simulata, tramite<br />
la quale viene <strong>di</strong>mostrato che l’approccio fornisce un miglioramento<br />
considerevole sulla stabilità del sistema riducendo l’overhead della riclusterizzazione<br />
e della riorganizzazione della rete. Il lavoro fornisce anche<br />
un’analisi teorica sulla soglia del range ra<strong>di</strong>o che garantisce la connettività<br />
tra no<strong>di</strong> <strong>di</strong> una rete <strong>di</strong>slocata casualmente, utilizzando un modello<br />
matematico.<br />
Infine, uno stu<strong>di</strong>o, sull’impatto <strong>di</strong> fenomeni <strong>di</strong> invecchiamento dei no<strong>di</strong><br />
sulla reliability della rete, è sviluppato da Krishmachari [43] dove viene<br />
analizzata la correlazione tra la durata della vita <strong>di</strong> ogni nodo e il suo<br />
consumo energetico in rispetto <strong>di</strong> alcune metriche <strong>di</strong> affidabilità come il<br />
Mean Time To Failure. Risultati interessanti sono forniti in merito alle<br />
misure relative all’impatto delle strategie <strong>di</strong> data aggregation sulla durata<br />
della vita <strong>di</strong> un nodo.<br />
2.4 AMBIENTI DI SIMULAZIONE<br />
Questo paragrafo si pone l’obiettivo <strong>di</strong> effettuare una carrellata dei vari<br />
ambienti <strong>di</strong> simulazione per l’analisi <strong>di</strong> reti <strong>di</strong> sensori senza cavo con<br />
particolare attenzione rivolta agli strumenti forniti dai vari ambienti per una<br />
caratterizzazione completa della rete emulata al fine <strong>di</strong> poterli sfruttare per<br />
ricavare parametri per l’analisi dell’affidabilità.<br />
Esaminare il comportamento <strong>di</strong> un sistema a tutti i livelli è necessario per<br />
raggiungere il massimo grado <strong>di</strong> accuratezza, infatti spesso un approccio<br />
basato sulla simulazione <strong>di</strong> algoritmi e protocolli <strong>di</strong> rete risulta inefficiente e<br />
questa inefficienza si accentua soprattutto in una Wireless Sensor Network<br />
51
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
dove i protocolli e le applicazioni possono interagire tra <strong>di</strong> loro facendo<br />
annullare il concetto <strong>di</strong> stratificazione [25].<br />
Emstar, insieme a Tossim è stato uno dei primi simulatori esplicitamente<br />
progettati per le reti <strong>di</strong> sensori senza cavo, questo è framework concepito per<br />
stu<strong>di</strong>are due tipi <strong>di</strong> WSN [29][30]: quelle costituite da sensori Microservers<br />
con architettura a 32-bit, che fanno uso tipicamente <strong>di</strong> sistema operativo<br />
Linux, e quelle composte da sensori Mica a 8-bit, che sfruttano il sistema<br />
operativo TinyOs. Emstar consente <strong>di</strong> stu<strong>di</strong>are l’esecuzione <strong>di</strong> applicazioni<br />
<strong>di</strong> entrambi i tipi secondo varie modalità d’uso rese <strong>di</strong>sponibili all’utente; è<br />
chiaro che l’emulazione sarà richiesta solo per le applicazioni destinate ai<br />
sensori Mica, mentre quelle per i Microservers sono normali applicazioni<br />
Linux che non necessitano <strong>di</strong> essere emulate. L’ambiente <strong>di</strong> simulazione<br />
offre anche una serie <strong>di</strong> servizi utili per creare applicazioni Linux, come vari<br />
algoritmi <strong>di</strong> routing (tra i quali il Direct Diffusion, che si occupa <strong>di</strong> inviare<br />
messaggi solo a gruppi <strong>di</strong> no<strong>di</strong> interessati, utile per effettuare query mirate<br />
all’interno della rete <strong>di</strong> sensori), un servizio <strong>di</strong> localizzazione che i sensori<br />
possono adoperare per costruire e mantenere aggiornata in maniera<br />
<strong>di</strong>namica la topologia della rete circostante, un servizio <strong>di</strong> sincronizzazione<br />
tempo virtuale/reale in<strong>di</strong>spensabile nelle simulazioni ibride, ed altri ancora.<br />
Purtroppo non viene simulato l’uso del sensore, né il consumo energetico, e<br />
queste sono delle pecche abbastanza importanti in un emulatore che si<br />
prefigge lo scopo <strong>di</strong> stu<strong>di</strong>are il funzionamento dei sensori a basso livello.<br />
Atemu è un simulatore del comportamento dell’intero hardware dei sensori,<br />
che usa come input il binario eseguibile dell’applicazione [31]. I sensori<br />
simulati sono quelli delle famiglie Atmel e Mica con processore AVR; una<br />
delle possibilità più interessanti <strong>di</strong> Atemu è quella <strong>di</strong> poter definire<br />
l’hardware dei sensori su cui eseguire le applicazioni. Il comportamento<br />
della rete può essere più che mai eterogeneo, decidendo sia le applicazioni<br />
52
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
che l’architettura hardware <strong>di</strong> ciascun nodo o gruppo <strong>di</strong> no<strong>di</strong> della rete, ed<br />
in<strong>di</strong>candone la posizione in modo da decidere la topologia della rete a<br />
piacimento (secondo un semplice modello 3D). L’utilizzo <strong>di</strong> Atemu è<br />
soprattutto in ambito <strong>di</strong> debugging, visto la possibilità <strong>di</strong> poter tenere sotto<br />
controllo, in ogni step della simulazione, lo stato <strong>di</strong> ciascun sensore (valore<br />
dei registri interni, uso della memoria, istruzione corrente, messaggi inviati<br />
e ricevuti). Anche in Atemu non esiste alcun modello del consumo<br />
energetico dei sensori della rete, e non è prevista nessun meccanismo per<br />
l’analisi dell’affidabilità.<br />
Avrora è un emulatore scritto in Java che simula il comportamento<br />
dell’intero hardware dei sensori, eseguendo il co<strong>di</strong>ce del programma in<br />
linguaggio assemblativo [32]. I sensori simulati sono quelli delle famiglie<br />
Atmel e Mica, dotati <strong>di</strong> processore AVR. La principale <strong>di</strong>fferenza con<br />
Atemu consiste nel fatto che Avrora è un simulatore ad eventi, e non tempo<br />
continuo. Non viene simulato il funzionamento dei sensori quando essi sono<br />
in sleep, saltando <strong>di</strong>rettamente al prossimo evento nella coda d’attesa <strong>di</strong> quel<br />
sensore che ne provoca il risveglio ed il funzionamento. A questo si<br />
accompagna il fatto che ogni nodo viene simulato in un thread a parte dal<br />
simulatore, il che consente <strong>di</strong> velocizzare ulteriormente la simulazione,<br />
anche se ciò pone il delicato problema della sincronizzazione <strong>degli</strong> eventi<br />
che riguardano no<strong>di</strong> <strong>di</strong>versi.<br />
Ns-2 [33], Glomosim [34] e Opnet [35] sono simulatori <strong>di</strong> rete, adattati o<br />
implementati per le WSN. Sono progettati per simulare specificamente lo<br />
strato <strong>di</strong> rete dello stack <strong>di</strong> comunicazione. Ns-2 non supporta in maniera<br />
nativa le WNS, ma esistono delle estensioni che forniscono all’ambiente <strong>di</strong><br />
simulazione le capacità <strong>di</strong> simulare un canale trasmissivo wireless.<br />
Glomosim è stato progettato specificamente per supportare reti wireless e<br />
mette a <strong>di</strong>sposizione un ottimo modello <strong>di</strong> propagazione ra<strong>di</strong>o. Opnet è un<br />
53
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
simulatore standar<strong>di</strong>zzato in ambito industriale e commerciale molto simile<br />
a ns-2. Opnet viene fornito con un modulo che simula la propagazione RF e<br />
interferenze, ma non supporta in maniera nativa le WSN.<br />
SensorSim [36] nasce come modulo aggiuntivo per ns-2. Sviluppato dai<br />
laboratori <strong>di</strong> ricerca UCLA2. SensorSim racchiude alcuni interessanti<br />
caratteristiche tra cui un modello dell’attività sensoristica, un modello della<br />
batteria per il consumo energerico dei no<strong>di</strong>, un leggero stack protocollare<br />
appositamente progettato per le WSN e un modulo per la simulazione che<br />
consente l’interazione attraverso dei reali sensori, per una simulazione<br />
‘ibrida’.<br />
J-Sim [37], è un ambiente <strong>di</strong> simulazione scritto in Java, con front-end in<br />
Tcl, sviluppato prendendo ispirazione da Ns-2 e dalla sua estensione<br />
Sensorsim. E’ realizzato secondo il para<strong>di</strong>gma della programmazione a<br />
componenti; costituisce un framework per la simulazione <strong>di</strong> reti <strong>di</strong><br />
calcolatori in generale, wired e wireless, con in particolare un supporto<br />
de<strong>di</strong>cato alle WSN ispirato <strong>di</strong>rettamente a Sensorsim; implementa<br />
funzionalità in maniera più completa rispetto a Ns-2, come ad esempio la<br />
simulazione ibrida, che può essere condotta in varie modalità.<br />
Shawn [58] è un simulatore orientato agli algoritmi, che offre all’utente un<br />
ambiente <strong>di</strong> supporto in cui può scrivere in linguaggio C++ l’algoritmo che<br />
desidera eseguire su ciascun nodo della rete. Oltre a decidere l’algoritmo<br />
che andrà in esecuzione sui no<strong>di</strong> della rete in maniera omogenea, si possono<br />
stabilire alcune caratteristiche della simulazione, come il modello<br />
topologico (a scelta tra quelli esistenti), la posizione dei no<strong>di</strong>, il modello <strong>di</strong><br />
trasmissione dei messaggi sui link tra no<strong>di</strong> a<strong>di</strong>acenti.<br />
Algosensim [59] ,alla stregua <strong>di</strong> Shawn, è un simulatore orientato agli<br />
algoritmi. È scritto in Java e l’ambiente <strong>di</strong> simulazione viene configurato<br />
me<strong>di</strong>ante la scrittura <strong>di</strong> files XML. Al momento è <strong>di</strong>sponibile solo una<br />
54
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
versione alpha, anche se il framework del simulatore è stato completamente<br />
sviluppato così come buona parte delle classi.<br />
Omnet++ [60], infine, è un simulatore scritto in C++ secondo il para<strong>di</strong>gma<br />
della programmazione basata sui componenti, che usa il linguaggio Ned per<br />
la configurazione della simulazione. Anche se sul sito ufficiale è <strong>di</strong>chiarata<br />
l’esistenza <strong>di</strong> progetti per la simulazione <strong>di</strong> reti Internet, anche con elementi<br />
wireless, ed eventualmente WSN, per il momento tali estensioni sono<br />
assenti. La struttura del simulatore è sostanzialmente simile a quella <strong>di</strong> altri<br />
simulatori come Ns-2 e J-Sim. La <strong>di</strong>fferenza principale sta nel maggior<br />
livello <strong>di</strong> astrazione, nel minor numero <strong>di</strong> funzionalità offerte e nella<br />
maggiore semplicità della simulazione. In Omnet++ non esistono librerie <strong>di</strong><br />
componenti che implementano ciascuno strato dello stack protocollare del<br />
software <strong>di</strong> rete; il simulatore è concepito per una rappresentazione molto<br />
più astratta dei no<strong>di</strong> della rete, che nella maggior parte dei casi avviene<br />
tramite un unico componente, o un insieme <strong>di</strong> pochi componenti interni, che<br />
si occupano unicamente <strong>di</strong> descrivere come il nodo in questione gestisce la<br />
ricetrasmissione <strong>di</strong> messaggi.<br />
2.4.1 Il Simulatore Tossim<br />
TOSSIM [26], [27] è un simulatore ad eventi che consente <strong>di</strong> effettuare il<br />
debugging e l’analisi <strong>di</strong> un’applicazione per TinyOS, semplicemente<br />
compilandola per la piattaforma PC, anziché per l’hardware del sensore (ad<br />
esempio mica). Naturalmente TOSSIM non simula il mondo reale, ma fa<br />
una serie <strong>di</strong> semplificazioni che permettono <strong>di</strong> mantenerne la scalabilità,<br />
senza pregiu<strong>di</strong>carne tuttavia l’accuratezza dei risultati. Le caratteristiche<br />
principali sono le seguenti:<br />
55
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
� TOSSIM simula il comportamento <strong>di</strong> TinyOS a basso livello, in<br />
particolare simula la comunicazione fra no<strong>di</strong> a livello <strong>di</strong> bit e tutti<br />
gli interrupt <strong>di</strong> sistema;<br />
� gli interrupt sono temporizzati con precisione, mentre i tempi <strong>di</strong><br />
esecuzione non vengono simulati (dal punto <strong>di</strong> vista del simulatore<br />
un pezzo <strong>di</strong> co<strong>di</strong>ce viene eseguito istantaneamente);<br />
� la propagazione dei segnali ra<strong>di</strong>o non viene simulata; i collegamenti<br />
fisici sono modellati attraverso un grafo che in<strong>di</strong>ca per ogni coppia<br />
<strong>di</strong> no<strong>di</strong> la probabilità <strong>di</strong> errore sul bit (0 significa perfetta<br />
connettività, 1 connettività assente);<br />
� non viene simulato il comportamento della batteria ma viene solo<br />
quantificata l’energia consumata da ciascun nodo.<br />
� in TOSSIM un interrupt non può interrompere il co<strong>di</strong>ce attualmente<br />
in esecuzione, come invece è possibile nei mote reali;<br />
� in TOSSIM tutti i no<strong>di</strong> sensori devono necessariamente eseguire la<br />
stessa applicazione.<br />
Il debugging delle applicazioni viene fatto generalmente inserendo nel<br />
co<strong>di</strong>ce delle chiamate alla funzione dbg, la quale consente appunto <strong>di</strong><br />
inviare stringhe <strong>di</strong> testo al simulatore, specificandone anche il tipo.<br />
TOSSIM durante l’esecuzione legge questi messaggi <strong>di</strong> debug e mostra<br />
all’utente solo quelli del tipo corretto, specificato tramite la variabile<br />
d’ambiente DBG.<br />
Per quanto riguarda la comunicazione wireless, il simulatore fornisce due<br />
modelli del mezzo ra<strong>di</strong>o:<br />
• il modello simple;<br />
• il modello lossy.<br />
In entrambi i casi i segnali possono in un certo istante assumere solo i valori<br />
zero o uno e non hanno associata una informazione sull’intensità. Il<br />
modello simple si comporta come se i no<strong>di</strong> fossero posizionati in una<br />
56
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
singola cella, per cui tutti i bit trasmessi sono ricevuti senza errori da tutti i<br />
sensori presenti. Anche se non ci sono errori <strong>di</strong> trasmissione si possono<br />
comunque avere collisioni se due o più <strong>di</strong>spositivi trasmettono<br />
contemporaneamente, portando alla corruzione dei dati.<br />
Il modello lossy, più utilizzato in pratica, connette tutti i no<strong>di</strong> in un grafo<br />
orientato, in cui ogni arco in<strong>di</strong>ca la probabilità che un bit trasmesso venga<br />
ricevuto invertito. Se ad esempio all’arco (a, b) è associato il valore 0.01<br />
significa che ogni bit trasmesso da a ha l’1% <strong>di</strong> probabilità <strong>di</strong> essere<br />
ricevuto corrotto da b. Questo modello consente quin<strong>di</strong> <strong>di</strong> simulare<br />
topologie più complesse in cui non tutti i no<strong>di</strong> sono connessi tra loro,<br />
permette <strong>di</strong> avere connessioni asimmetriche e <strong>di</strong> valutare le conseguenze<br />
delle interferenze. Il grafo può essere specificato fornendo al simulatore un<br />
file contenente i valori del bit-error-rate per ogni coppia <strong>di</strong> sensori; esiste<br />
anche la possibilità <strong>di</strong> generare il file attraverso lo strumento LossyBuilder,<br />
che costruisce il grafo basandosi sulla topologia e su dati sperimentali<br />
ottenuti dagli sviluppatori.<br />
2.5 OSSERVAZIONI<br />
I vari simulatori analizzati nel paragrafo precedente, focalizzano la loro<br />
attenzione su varie peculiarità delle WSN, ma nessuno <strong>di</strong> essi è in grado <strong>di</strong><br />
fornire delle misure <strong>di</strong> dependability della rete e/o dei no<strong>di</strong>. Questa è una<br />
forte limitazione in quanto le WSN sono al giorno d’oggi utilizzate in<br />
svariati ambiti dove sono richiesti parametri <strong>di</strong> affidabilità del tutto<br />
<strong>di</strong>fferenti tra <strong>di</strong> loro. Infatti, come si è potuto constatare, le applicazioni<br />
scritte per reti WSN sono fortemente legate al contesto nel quale sono<br />
utilizzate e per questo sarebbe utile avere un meccanismo per la valutazione<br />
della dependability già in fase <strong>di</strong> progettazione.<br />
Tra i vari simulatori analizzati, in questo lavoro <strong>di</strong> <strong>tesi</strong>, si è scelto <strong>di</strong><br />
utilizzare Tossim. La possibilità <strong>di</strong> poter eseguire le applicazioni tinyOS su<br />
57
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
un normale PC, invece che su un <strong>di</strong>spositivo mote reale, ha sicuramente<br />
influito positivamente sulla scelta, in quanto è possibile testare e analizzare<br />
un’applicazione per reti <strong>di</strong> sensori in un ambiente controllato e ripetibile. Un<br />
altro vantaggio evidente offerto da questo framework, a <strong>di</strong>fferenza <strong>di</strong> altri<br />
simili come Emstar, è la possibilità <strong>di</strong> riutilizzare il co<strong>di</strong>ce per eseguirlo<br />
<strong>di</strong>rettamente su un <strong>di</strong>spositivo mote reale senza effettuarne nessuna<br />
mo<strong>di</strong>fica. Infatti altri simulatori come Emstar prevedono che non venga<br />
eseguito il file binario che andrà sui sensori veri e propri ma una versione<br />
<strong>di</strong>fferente del co<strong>di</strong>ce, la quale non prevede simulazione del consumo<br />
energetico né gestione delle interruzioni hardware, schedulando tutti gli<br />
eventi come una serie <strong>di</strong> tasks <strong>di</strong> breve durata che vengono eseguiti in<br />
sequenza uno dopo l’altro.<br />
Altro punto a favore <strong>di</strong> Tossim è sicuramente la qualità e quantità della<br />
documentazione e il grosso interesse della comunità <strong>di</strong> sviluppatori <strong>di</strong> WSN<br />
per questo framework proprio per le caratteristiche succitate.<br />
58
Capitolo 3<br />
Algoritmi per la raccolta dati affidabile<br />
3.1 CONSIDERAZIONI GENERALI ED OBIETTIVI<br />
Come già messo in evidenza nel paragrafo 1.9 l’ambito <strong>di</strong> applicazione<br />
delle reti <strong>di</strong> sensori senza cavo è molto vasto. L’obiettivo <strong>di</strong> questa <strong>tesi</strong> è <strong>di</strong><br />
progettare e valutare algoritmi per la raccolta dati affidabile.<br />
Il contesto specifico all’interno del quale si colloca il lavoro è il<br />
monitoraggio <strong>di</strong> una struttura <strong>di</strong>namica, ovvero il monitoraggio dello stato<br />
<strong>di</strong> salute <strong>di</strong> una struttura attraverso un apposita rete <strong>di</strong> sensori che possa<br />
essere in grado <strong>di</strong> fornire mappe <strong>di</strong> deformazione, <strong>di</strong>stribuzioni <strong>di</strong><br />
temperatura, misure <strong>di</strong> vibrazione e identificazione e localizzazione <strong>di</strong> danni<br />
interni alla struttura. Attualmente i sistemi sviluppati sono basati su reti<br />
“single-hop” cablate cioè su reti nelle quali si fa l’ipo<strong>tesi</strong> che ogni sensore<br />
sia in grado <strong>di</strong> comunicare con un nodo atto all’acquisizione delle<br />
misurazioni attraverso l’utilizzo <strong>di</strong> un canale cablato. Questi sistemi sono <strong>di</strong><br />
solito composti da un numero basso <strong>di</strong> <strong>di</strong>spositivi sensori e presentano<br />
problemi come gli elevati costi <strong>di</strong> installazione e il rumore elettromagnetico,<br />
non trascurabile quando vengono utilizzati cavi <strong>di</strong> trasmissione lunghi<br />
(superiori ai 100m). Ciò comporta degrado delle misurazioni e<br />
59
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
sovra-voltaggi che possono causare guasti agli stessi <strong>di</strong>spositivi. Le reti <strong>di</strong><br />
sensori senza cavo vengono in aiuto proprio per risolvere problemi come<br />
questi in quanto prevedono l’eliminazione dei cavi e provvedono all’uso <strong>di</strong><br />
segnali <strong>di</strong>gitali che sono meno soggetti ad interferenze e sovra-voltaggi.<br />
D’altronde le WSN introducono una nuova serie <strong>di</strong> problemi dovuti alle<br />
caratteristiche del mezzo wireless attraverso cui avvengono le<br />
comunicazioni dei no<strong>di</strong> e all’esaurimento delle riserve energetiche dei<br />
singoli no<strong>di</strong>.<br />
Di conseguenza la fase <strong>di</strong> sviluppo si arricchisce <strong>di</strong> nuove tematiche e<br />
requisiti che vanno ad aggiungersi a quelli base per formare uno scenario in<br />
cui è necessario avere:<br />
1. una raccolta affidabile <strong>di</strong> un numero sufficiente <strong>di</strong> misurazioni in<br />
una vasta area;<br />
2. sincronizzazione delle misurazioni;<br />
3. utilizzo <strong>di</strong> protocolli <strong>di</strong> raccolta dati energeticamente efficienti;<br />
4. minimizzazione dell’intervento umano;<br />
In questo lavoro <strong>di</strong> <strong>tesi</strong> si focalizzerà l’attenzione soprattutto sui punti 1 e 3<br />
tralasciando il problema della sincronizzazione delle misurazioni.<br />
3.2 ALGORITMI DI DATA GATHERING<br />
Con il termine Data Gathering si intende una famiglia <strong>di</strong> algoritmi, usati<br />
tipicamente in applicazioni <strong>di</strong> tipo monitoring, per raccogliere dati<br />
globalmente e trasmetterli al nodo base in gergo denominato nodo sink.<br />
Lo scenario è quello <strong>di</strong> una rete <strong>di</strong> sensori, con una certa struttura, <strong>di</strong> cui si<br />
conosce la localizzazione <strong>di</strong> ogni singolo nodo e dove si ipotizza che ogni<br />
nodo sia in grado <strong>di</strong> comunicare in multi-hop con qualsiasi altro nodo della<br />
rete e quin<strong>di</strong> anche <strong>di</strong>rettamente con il nodo sink (figura 3.1).<br />
60
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 3.1: Scenario tipico <strong>di</strong> una rete <strong>di</strong> sensori wireless: i coman<strong>di</strong> sono<br />
inoltrati in modalità broadcast mentre le misurazioni recapitate al<br />
nodo sink tramite protocollo multihop<br />
Questo genere <strong>di</strong> algoritmi cercano un modo efficiente, in termini <strong>di</strong> vita<br />
globale della rete, per raccogliere i dati e renderli <strong>di</strong>sponibili al nodo base.<br />
Molto spesso si ipotizza che ogni nodo abbia anche la possibilità <strong>di</strong> fondere<br />
e aggregare le informazioni ricevute, ed eventualmente instradarle seguendo<br />
un percorso, variabile nel tempo, che sfrutta i no<strong>di</strong> che ad esempio sono<br />
dotati <strong>di</strong> maggiore energia residua. Queste tecniche sono molto utilizzate e<br />
permettono la riduzione dell’informazione trasmessa mentre questa viaggia<br />
all’interno della rete e sono denominate: Data aggregation e data fusion.<br />
Entrambe evitano lo spreco <strong>di</strong> risorse (come la banda e l’energia) e cercano<br />
<strong>di</strong> limitare il traffico che transita nella rete. L’idea principale consiste<br />
nell’unire in un unico pacchetto inviato l’informazioni proveniente da più<br />
no<strong>di</strong> prima <strong>di</strong> inoltrarla verso la destinazione, aumentando l’efficienza delle<br />
trasmissioni quando i dati da trasmettere sono pochi. Differenti strategie <strong>di</strong><br />
data fusion e aggregation richiedono <strong>di</strong>verse risorse e possono determinare<br />
variazioni nel routing.<br />
61
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
In letteratura [11] il problema del Data Gathering viene analiticamente<br />
formalizzato come un problema <strong>di</strong> programmazione lineare che prende il<br />
nome <strong>di</strong> MLDA (Maximum lifetime data gathering). Per reti ad elevato<br />
numero <strong>di</strong> sensori è evidente come l’utilizzo <strong>di</strong> normali tecniche per<br />
risolvere la PL risulti troppo oneroso in termini computazionali. Proprio per<br />
ovviare a questo problema ultimamente si è andato sempre più sviluppando<br />
un approccio clustering- based che nel caso dell’MLDA da una soluzione<br />
euristica al problema, garantendo nel worst-case complessità polinomiale in<br />
n, dove con n si in<strong>di</strong>ca il numero <strong>di</strong> sensori della rete. L’idea è quella <strong>di</strong><br />
sud<strong>di</strong>videre la rete in m cluster, cercando quanto più <strong>di</strong> in<strong>di</strong>viduare delle<br />
zone in cui i sensori si attestano su simili con<strong>di</strong>zioni misurate, ad esempio<br />
“zona a temperatura compresa fra 50° C e 80° C, oppure “zona a bassa<br />
luminosità”, etc. Questo concetto verrà dettagliatamente ripreso nel<br />
paragrafo 3.4.<br />
3.3 INTERAZIONE TRA I NODI: IL PROTOCOLLO<br />
MULTIHOP<br />
Il problema <strong>di</strong> avere una vasta area da monitorare nella quale si devono far<br />
pervenire le misurazioni ad un nodo base (sink) può essere una grossa<br />
limitazione nel caso in cui non si abbiano a <strong>di</strong>sposizione <strong>degli</strong> adeguati<br />
protocolli <strong>di</strong> rete. La soluzione come gia si è accennato nel paragrafo 1.6.3 è<br />
l’utilizzo del protocollo multihop che consente ai no<strong>di</strong> sensore all’esterno<br />
del raggio <strong>di</strong> azione del ricetrasmettitore dalla stazione base <strong>di</strong> trasmettere i<br />
dati ai no<strong>di</strong> sensore vicini, i quali a turno inoltreranno i dati fino alla<br />
stazione base. Il processo <strong>di</strong> inoltro potrebbe coinvolgere anche molti no<strong>di</strong><br />
sensori ma le informazioni potrebbero comunque giungere a destinazione<br />
nel caso in cui non si verifichino collisioni.<br />
La versione 1.1.x e successive <strong>di</strong> TinyOs includono delle librerie <strong>di</strong><br />
62
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
componenti che forniscono un routing multi-hop realizzato appositamente<br />
per le reti <strong>di</strong> sensori wireless: l’implementazione, contenuta all’interno della<br />
cartella $TOSROOT/tos/lib/Route impiega l’algoritmo dello shortest<br />
path first con una singola destinazione, rappresentata dalla stazione base<br />
(nodo con identificativo univoco 0), svolgendo una stima dei collegamenti.<br />
L’inoltro dei dati e i meccanismi <strong>di</strong> routing sono implementati in due<br />
<strong>di</strong>versi componenti (MultiHopEngineM e MultiHopLEPSM) con<br />
una singola interfaccia (MultiHopRouter), che li collega, al fine <strong>di</strong><br />
permettere una più facile integrazione <strong>di</strong> ulteriori schemi <strong>di</strong> routing in<br />
futuro (figura 3.2). MultiHopEngineM stabilisce la logica <strong>di</strong> movimento<br />
generale dei pacchetti per le funzionalità che riguardono il routing<br />
multihop. Tramite RouteSelect il modulo in<strong>di</strong>vidua il next-hop nel<br />
cammino <strong>di</strong> routing ed invia i pacchetti utilizzando la porta SendMsg.<br />
MultiHopLEPSM fornisce:<br />
� meccanismi per la stima dei collegamenti e per la selezione del nodo<br />
genitore (Link Estimation Parent Selection);<br />
� strumenti per monitorare il traffico ricevuto da un nodo;<br />
� primitive per la ricezione/trasmissione dei messaggi <strong>di</strong> update e<br />
Figura 3.2: Configurazione <strong>di</strong> Multihop Router<br />
63
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
delle informazioni <strong>di</strong> routing <strong>di</strong>rettamente dai no<strong>di</strong> vicini tramite la<br />
porta Snoop. Le informazioni accumulate sono poi utilizzate per la<br />
scelta del next-hop. La procedura <strong>di</strong> inoltro dei messaggi <strong>di</strong><br />
aggiornamento dei cammini è perio<strong>di</strong>ca (ogni 10 sec) così come<br />
quella <strong>di</strong> rielaborazione delle informazioni ricevute (50 sec).<br />
Infine la configurazione MultiHopRouter connette i due moduli<br />
suddetti e la configurazione importa le porte fornite dalle funzioni<br />
Receive, Send, Intercept Snoop. La porta fornita da<br />
SendMsg, invece, è collegata ai componenti della libreria QueuedSend la<br />
quale è impiegata per la gestione della coda dei pacchetti, sia che essi siano<br />
stati originati localmente dal nodo sensore sia che essi siano stati inoltrati da<br />
altri no<strong>di</strong>.<br />
L’utilizzo del protocollo multihop risulta essere una buona soluzione per<br />
scenari in cui bisogna effettuare il monitoraggio <strong>di</strong> vaste aree, però va anche<br />
evidenziato che è la soluzione più semplice possibile, e <strong>di</strong> conseguenza<br />
presenta alcuni svantaggi come ad esempio il recapito <strong>di</strong> tutte le<br />
misurazioni. Infatti i link RF delle comunicazioni wireless sono affetti dal<br />
problema dell’interferenza, che nella maggior parte dei casi è dovuto alla<br />
collisione <strong>di</strong> pacchetti che viaggiano nell’etere. Ciò causa per<strong>di</strong>ta <strong>di</strong><br />
misurazioni e <strong>di</strong> conseguenza per<strong>di</strong>ta <strong>di</strong> informazione relativa ad una zona<br />
monitorata. Due sono quin<strong>di</strong> gli aspetti che debbono essere trattati:<br />
1. utilizzo <strong>di</strong> approcci <strong>tesi</strong> ad evitare zone <strong>di</strong> non copertura;<br />
2. utilizzo <strong>di</strong> tecniche per il recapito affidabile delle informazioni.<br />
Nel prossimo paragrafo si tratterà in particolare il punto 1 mentre il 2 punto<br />
sarà dettagliato nel paragrafo 3.7<br />
64
3.4 CLUSTERING IN UNA WSN<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Dato l’elevato numero <strong>di</strong> sensori che compongono la rete, può risultare<br />
conveniente per molte applicazioni raggruppare i no<strong>di</strong> in cluster (ve<strong>di</strong> figura<br />
3.3), ed eleggere per ciascuno gruppo un super-nodo, detto cluster-head.<br />
In questa accezione la raccolta <strong>di</strong> informazione può essere intesa in due<br />
mo<strong>di</strong> <strong>di</strong>fferenti:<br />
1. come la collezione delle varie misure effettuate dai no<strong>di</strong> appartenenti<br />
allo stesso cluster, le quali vengono recapitate al nodo sink tramite il<br />
cluster-head in quanto questo può, ad esempio, essere quello che<br />
impiega la minor quantità <strong>di</strong> energia per il recapito delle<br />
informazioni;<br />
2. come raccolta della misurazione da parte del solo cluster-head.<br />
Questa è la soluzione proposta e in questo caso lo schema assume<br />
più un significato orientato al “load balancing”, visto che si mantiene<br />
attivo un solo sensore per cluster e con adeguate tecniche <strong>di</strong> elezione<br />
del cluster-head si può introdurre una politica <strong>di</strong> risparmio energia<br />
grazie all’accensione/spegnimento selettivo dei vari no<strong>di</strong> del gruppo.<br />
L’utilizzo dello schema “cluster-based” permette all’intero gruppo<br />
appartenente allo stesso cluster <strong>di</strong> essere identificato con il medesimo<br />
in<strong>di</strong>rizzo; questa tecnica ha quin<strong>di</strong> il vantaggio <strong>di</strong> ridurre il numero <strong>di</strong><br />
in<strong>di</strong>rizzi fisici da allocare mantenendo la possibilità <strong>di</strong> in<strong>di</strong>viduare<br />
univocamente una parte della rete, inoltre si riducono i messaggi inviati che<br />
non devono essere più ripetuti per ogni nodo appartenete al cluster, e si<br />
riesce ad aumentare la ridondanza della rete e la risoluzione della misura<br />
effettuata. Una organizzazione del genere affronta il problema della non<br />
copertura <strong>di</strong> determinate zone nel corso <strong>di</strong> una procedura <strong>di</strong> monitoraggio;<br />
infatti in ambito locale al cluster è applicato il concetto <strong>di</strong> ridondanza. La<br />
stessa struttura può essere iterata su più livelli creando cluster <strong>di</strong> cluster,<br />
65
Figura 3.3: Organizzazione in cluster della rete<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
fino a raggiungere il sink, il nodo <strong>di</strong> raccolta <strong>di</strong> tutte le informazioni e<br />
d’interfaccia con reti esterne o con l’utente finale. La scelta del cluster head<br />
può essere casuale, o può tener conto delle risorse dei singoli no<strong>di</strong>,<br />
pre<strong>di</strong>ligendo come cluster head quello dotato <strong>di</strong> maggiore energia e meno<br />
impegnato in comunicazioni ra<strong>di</strong>o; infatti è evidente che il ruolo <strong>di</strong> cluster<br />
head richieda maggiori funzionalità, le quali coincidono con un più elevato<br />
consumo <strong>di</strong> potenza.<br />
È chiaro che è anche possibile assegnare perio<strong>di</strong>camente il compito <strong>di</strong> capo<br />
cluster a no<strong>di</strong> <strong>di</strong>fferenti, che in momenti <strong>di</strong>versi risultino i più idonei a<br />
farsene carico.<br />
Riepilogando partizionare in cluster una rete <strong>di</strong> sensori wireless può servire<br />
sia in applicazioni <strong>di</strong> tipo Data gathering dove è richiesta una sud<strong>di</strong>visione<br />
in aree ciascuna delle quali corrisponde, quanto più è possibile ad una certa<br />
con<strong>di</strong>zione ambientale, sia nel Direct Diffusion per eleggere una gerarchia<br />
<strong>di</strong> no<strong>di</strong> più importanti, detti sempre cluster-head [12], e delegare poi a questi<br />
66
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
il compito <strong>di</strong> inoltrare l’interest nella rete, al posto <strong>di</strong> usare un banale<br />
floo<strong>di</strong>ng.<br />
Il clustering può essere effettuato con due approcci <strong>di</strong>versi:<br />
Clustering centralizzato: l’algoritmo <strong>di</strong> clustering gira sul nodo base della<br />
rete. La con<strong>di</strong>zione necessaria è che il nodo base riceva tutti i dati dai<br />
sensori. È evidente come questa tecnica vada a collidere con il concetto <strong>di</strong><br />
aggregazione, che tende a non far giungere al nodo base i dati relativi a tutti<br />
i sensori, bensì solo i pacchetti <strong>di</strong> informazioni fuse e concentrate.<br />
Clustering <strong>di</strong>stribuito: è <strong>di</strong> gran lunga il più usato per supportare tecniche<br />
<strong>di</strong> Data aggregation, Data gathering [11], e Direct <strong>di</strong>ffussion [12]. Il<br />
compito <strong>di</strong> partizionare in cluster viene decentralizzato e viene <strong>di</strong>stribuito<br />
su ogni nodo. Uno <strong>degli</strong> algoritmi <strong>di</strong> clustering <strong>di</strong>stribuito più noto è il<br />
DEM (Distributed Expectation Maximization [13]). Lo scopo è quello <strong>di</strong><br />
avere una partizione in cluster sempre aggiornata dei sensori, in base a delle<br />
con<strong>di</strong>zioni particolari che si verificano nell’ambiente. Si assume che ogni<br />
nodo della rete rilevi dei dati (o <strong>degli</strong> eventi) che possono essere descritti da<br />
un insieme <strong>di</strong> con<strong>di</strong>zioni elementari. L’algoritmo produce una stima della<br />
densità dei sensori per ciascuna <strong>di</strong> queste con<strong>di</strong>zioni e rende quin<strong>di</strong><br />
possibile la clusterizzazione. Le elaborazioni avvengono localmente al<br />
nodo, non è necessario quin<strong>di</strong> che i dati rilevati vengano inoltrati ad una<br />
stazione centrale che effettua i calcoli. Inoltre l’algoritmo non richiede che i<br />
sensori si scambino i dati effettivamente rilevati, ma solamente piccoli set<br />
<strong>di</strong> dati statistici <strong>di</strong> aggiornamento. Un altro vantaggio <strong>degli</strong> algoritmi DEM<br />
è che non producono trasmissioni simultanee; in altri termini è garantito<br />
che, ad ogni intervallo temporale, l’algoritmo scambia uno e un solo<br />
67
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
pacchetto <strong>di</strong> aggiornamento fra due no<strong>di</strong> (ad uno o più vicinati <strong>di</strong> <strong>di</strong>stanza).<br />
Questa scarsa necessità <strong>di</strong> comunicazione rende l’algoritmo molto poco<br />
pesante a livello <strong>di</strong> traffico introdotto sulla rete e quin<strong>di</strong> risulta facilmente<br />
integrabile in qualsiasi applicazione che prevede una partizione in cluster o<br />
una stima della densità.<br />
3.5 CLUSTERING: STATO DELL’ARTE<br />
Molti sono gli stu<strong>di</strong> presenti in letteratura de<strong>di</strong>cati al clustering <strong>di</strong> reti <strong>di</strong><br />
sensori senza cavo e questi possono essere classificati in base all’approccio<br />
seguito per effettuare proprio la procedura <strong>di</strong> clustering. In particolare<br />
verranno trattati algoritmi basati su criteri <strong>di</strong> prossimità, potenza<br />
trasmissiva, numero <strong>di</strong> hop (k-hop clustering), budget-based<br />
Un primo lavoro è quello <strong>di</strong> Heinzelman et al [10] che propongono il<br />
protocollo LEACH (Low Energy Adaptive Clustering Hierarchy)<br />
appositamente ideato per applicazioni atte al monitoraggio ambientale.<br />
L’approccio sul quale si basa il protocollo è fondato sulle seguenti 2<br />
assunzioni: (i) esiste un'unica base station con la quale tutti i sensori<br />
vogliono comunicare; (ii) tutti i sensori hanno la possibilità <strong>di</strong> comunicare<br />
<strong>di</strong>rettamente con la base station. Al fine <strong>di</strong> riguardare il consumo energetico<br />
dei no<strong>di</strong> il protocollo LEACH seleziona un numero p <strong>di</strong> sensori che fungono<br />
da cluster-head, dove p è un parametro che deve essere esaminato dal punto<br />
<strong>di</strong> vista ingegneristico a priori. I cluster-heads comunicano <strong>di</strong>rettamente con<br />
la base station e gli altri no<strong>di</strong> inoltrano le proprie misurazioni attraverso i<br />
cluster-heads (tipicamente quello più vicino a loro). Al fine <strong>di</strong> <strong>di</strong>stribuire<br />
equamente il consumo energetico dei no<strong>di</strong> il protocollo LEACH implementa<br />
una procedura <strong>di</strong> load-balancing che permette ai vari no<strong>di</strong> <strong>di</strong> <strong>di</strong>ventare<br />
cluster-heads in <strong>di</strong>fferenti istanti temporali. Si prevede inoltre che un nodo<br />
68
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
possa essere rieletto solo quando tutti i restanti can<strong>di</strong>dati sono già stati eletti<br />
almeno una volta. I risultati a cui Heinzelman et al giungono mostrano che il<br />
protocollo LEACH riduce l’energia associata alla comunicazione <strong>di</strong> circa<br />
otto volte rispetto alla trasmissione <strong>di</strong>retta (<strong>di</strong>rect-transmission) e inoltre che<br />
la durata energetica del primo nodo ad esaurirsi aumenta <strong>di</strong> circa 8 volte<br />
rispetto al caso in cui è usato <strong>di</strong>rect-transmission, mentre l’ultimo nodo si<br />
esaurisce circa 3 volte dopo l’esaurimento dell’ultimo nodo negli altri<br />
protocolli.<br />
Lindsey et al. [44] proseguendo dai risultati ottenuti con il protocollo<br />
LEACH proposero PEGASIS (Power-Efficient GAthering in Sensor<br />
Information Systems), un protocollo in cui i no<strong>di</strong> trasmettono le<br />
informazioni al loro vicino più vicino e i messaggi sono trasmessi alla base<br />
station basandosi su uno schema a catena. Il protocollo PEGASIS si è<br />
<strong>di</strong>mostrato più robusto rispetto al LEACH nei riguar<strong>di</strong> dei fallimenti dei<br />
no<strong>di</strong>.<br />
Subramanian e Katz [45] propongono invece delle linee guida per la<br />
progettazione <strong>di</strong> reti <strong>di</strong> sensori auto-organizzanti in cluster. Viene posta<br />
enfasi sull’importanza <strong>di</strong> implementare una struttura gerarchica al fine <strong>di</strong><br />
ridurre la complessità del routing per ogni nodo, in particolare viene<br />
suggerito un approccio per il clustering nei quali i no<strong>di</strong> “beginner”<br />
(iniziatori) inviano un “solicitation message” a tutti i no<strong>di</strong> che possono<br />
ascoltarli. In ogni round dell’algoritmo gli iniziatori incrementano la loro<br />
potenza trasmissiva e il processo <strong>di</strong> clustering continua fin quando il numero<br />
dei no<strong>di</strong> che rispondono sono compresi tra limite min e max <strong>di</strong> no<strong>di</strong> per<br />
cluster.<br />
L’approccio utilizzato da Subramanian e Katz è molto simile all’<br />
“Expan<strong>di</strong>ng Ring” <strong>di</strong> Ramamoorthy et al [46], fatta eccezione per il fatto<br />
che i no<strong>di</strong> “beginner”ora non incrementano la loro potenza trasmissivo ma il<br />
numero <strong>di</strong> hop. Facciamo notare però che questo tipo <strong>di</strong> approccio può avere<br />
69
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
una complessità nel caso peggiore molto alta in quanto <strong>di</strong>pende dal numero<br />
totale <strong>di</strong> sensori presenti nella rete più che dallo specifico limite sulla<br />
<strong>di</strong>mensione del cluster.<br />
Una soluzione alternativa alla realizzazione <strong>di</strong> cluster con limitate<br />
<strong>di</strong>mensioni e con un overhead <strong>di</strong> messaggi basso è l’approccio budget-based<br />
clustering. In questo tipo <strong>di</strong> algoritmi al nodo iniziatore (cluster-head) è<br />
assegnato un budget iniziale. Il cluster-head inizia col <strong>di</strong>stribuire il proprio<br />
budget ai suoi vicini i quali a loro volta fanno lo stesso fin quando il budget<br />
non è esaurito. Questo tipo <strong>di</strong> approccio permette una crescita dei vari<br />
cluster basandosi su decisioni locali al nodo ed evitando <strong>di</strong> coinvolgere i<br />
cluster head in ogni round, <strong>di</strong>minuendo in questo modo l’overhead dei<br />
messaggi. Controllando quin<strong>di</strong> il budget allocato per la formazione del<br />
cluster si è in grado <strong>di</strong> controllare il numero superiore alla <strong>di</strong>mensione del<br />
cluster. Krishnan e Starobinski [47] propongono due algoritmi per budgetbased<br />
clustering: rapid e persistent. Entrambi astraggono dal numero e dalla<br />
<strong>di</strong>slocazione delle base station nella rete e non considerando l’assunzione<br />
della connettività <strong>di</strong>retta (molto utile quando si considerano scenari reali nei<br />
quali ci sono da considerare possibili ostacoli durante la trasmissione). Il<br />
lavoro si pone <strong>di</strong> tener in considerazione: (i) l’efficienza dei messaggi che è<br />
cruciale per mantenere limitati i requisiti <strong>di</strong> banda e il consumo energetico<br />
dei sensori, (ii) la necessità <strong>di</strong> avere <strong>di</strong>mensioni dei cluster limitate in modo<br />
da avere un impatto favorevole sulle performance dei protocolli <strong>di</strong> routing e,<br />
(iii) scelta <strong>di</strong> adeguati budget per la procedura <strong>di</strong> clustering al fine <strong>di</strong><br />
controllare le <strong>di</strong>mensioni e il numero <strong>di</strong> cluster prodotti.<br />
Una evoluzione allo stu<strong>di</strong>o <strong>di</strong> Krishnan e Starobinski è proposto da<br />
Tzevelekas et al [48] dove è descritta una metodologia intelligente <strong>di</strong><br />
<strong>di</strong>stribuzione dei budget ai vicini. L’idea è quella <strong>di</strong> far si che i no<strong>di</strong> possano<br />
tenere in considerazione le caratteristiche dei propri vicini al fine <strong>di</strong> stabilire<br />
politiche per la <strong>di</strong>stribuzione del budgets.<br />
70
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
In [49] viene proposto un algoritmo intelligente per lo sviluppo <strong>di</strong> reti <strong>di</strong><br />
sensori wireless organizzate in cluster ed energeticamente efficienti, nel<br />
quale ogni nodo sensore decide se effettuare l’operazione <strong>di</strong> “join” a un<br />
cluster o se restare in uno stato <strong>di</strong> funzionamento peer to peer basando la sua<br />
scelta sulla densità dei sensori nell’area e sul suo livello energetico.<br />
Il lavoro proposto da Guo [50], invece, pone l’attenzione sullo sviluppo <strong>di</strong><br />
un metodo <strong>di</strong> formazione <strong>di</strong> cluster efficiente dal punto <strong>di</strong> vista dei costi.<br />
Tuttavia il metodo agisce posizionando “sentinelle” (cluster head CH) al<br />
centro <strong>di</strong> ogni cluster e assume che la topologia della rete e del numero <strong>di</strong><br />
cluster presenti sia nota.<br />
Il protocollo <strong>di</strong>stribuito HEED proposto in [51] , assume <strong>di</strong> eleggere i<br />
cluster heads in base alla loro energia residua e non tenendo conto della<br />
<strong>di</strong>stribuzione dei no<strong>di</strong>. Infatti HEED presuppone che la <strong>di</strong>stribuzione dei<br />
no<strong>di</strong> sensori nella rete sia uniforme. Questo approccio però presenta<br />
l’evidente problema che si possa verificare una situazione nella quale tutti i<br />
cluster head sono localizzati in una regione specifica della rete considerata.<br />
Altri lavori come [52,53,54] si sono invece incentrati su k-hop clustering<br />
algorithm <strong>di</strong>sinteressandosi però <strong>di</strong> considerare la completa totalità dei<br />
vincoli riguardanti la formazione dei cluster, infatti in [52,53] si considera<br />
solo il vincolo relativo al numero <strong>di</strong> no<strong>di</strong> all’interno del cluster mentre in<br />
[54] ci si basa solo sul cluster-ra<strong>di</strong>us. Più in particolare in [53] si<br />
presuppone che un nodo possa essere incluso in un numero costante <strong>di</strong><br />
cluster e che l’intersezione <strong>di</strong> due cluster possa includere un piccolo numero<br />
<strong>di</strong> no<strong>di</strong>.<br />
Bejerano [55] basa invece la sud<strong>di</strong>visione in cluster della rete su un<br />
algoritmo <strong>di</strong> approssimazione polinomiale in modo da avere un numero<br />
minimo <strong>di</strong> cluster <strong>di</strong>sgiunti. Al fine <strong>di</strong> considerare il problema del clustering<br />
e al tempo stesso rispettare i vincoli <strong>di</strong> QOS, Bejerano propone <strong>di</strong><br />
sud<strong>di</strong>videre il problema in due parti. Il primo mira a ricercare il minimo<br />
71
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
numero <strong>di</strong> cluster <strong>di</strong>sgiunti che contengono tutti i no<strong>di</strong> della rete sempre nel<br />
rispetto <strong>di</strong> un estremo superiore al cluster ra<strong>di</strong>us. Il secondo invece propone<br />
<strong>di</strong> considerare uno spanning tree in ogni cluster e <strong>di</strong> prevedere che i cluster<br />
che violano il vincolo <strong>di</strong> carico max e <strong>di</strong> cluster size vengano ulteriormente<br />
sud<strong>di</strong>visi in sottocluster. Si assume in questa accezione che ogni nodo abbia<br />
un peso (rappresentante la sua richiesta <strong>di</strong> banda) e che il totale <strong>di</strong> pesi <strong>di</strong><br />
tutti i cluster sia limitato. Infine viene introdotto un meccanismo per<br />
massimizzare il throughput <strong>di</strong> ogni cluster senza violare i requisiti <strong>di</strong> QOS.<br />
Infine Aoun e Boutaba [56], analizzano il problema del clustering sottoposto<br />
a limiti superiori per quanto riguarda la latenza e il consumo <strong>di</strong> energia dei<br />
no<strong>di</strong> interme<strong>di</strong>. Il lavoro complementa i lavori precedenti <strong>di</strong> Bejerano e<br />
Gupta in quanto tiene in conto anche del problema della formazione dei<br />
cluster (nel rispetto <strong>di</strong> un limite superiore sul cluster-ra<strong>di</strong>us, sulla<br />
<strong>di</strong>mensione del cluster e sul traffico trasmesso) e della scelta dei vari<br />
cluster-head. In particolare ogni cluster sarà dotato <strong>di</strong> un nodo che fingerà<br />
da gateway verso il nodo base e servirà quin<strong>di</strong> i no<strong>di</strong> presenti all’interno del<br />
cluster. Il lavoro prevede che ogni nodo sia associato ad un gateway e che<br />
possa sceglierne un altro in caso <strong>di</strong> “path failure”.<br />
3.6 APPROCCIO PROPOSTO PER IL CLUSTERING<br />
Dai precedenti paragrafi è emerso come il clustering risulta un’ottima<br />
soluzione per implementazione <strong>di</strong> strategie <strong>di</strong> fault-tolerance e anche per la<br />
gestione del problema della copertura <strong>di</strong> zone monitorate. Dal paragrafo 3.5<br />
si è potuto constatare anche come molti sono stati gli stu<strong>di</strong> atti<br />
all’in<strong>di</strong>viduazione <strong>di</strong> protocolli energeticamente efficienti per il clustering.<br />
In questo lavoro <strong>di</strong> <strong>tesi</strong> l’esigenza <strong>di</strong> aumentare quanto più possibile la vita<br />
<strong>di</strong> una rete è particolarmente sentita e per questo si è pensato <strong>di</strong> sfruttare il<br />
protocollo <strong>di</strong> clustering unitamente al para<strong>di</strong>gma <strong>di</strong> leader-election<br />
perio<strong>di</strong>co all’interno <strong>di</strong> ogni cluster. Questo approccio sembra avvicinarsi<br />
72
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
molto al protocollo PEGASIS proposto da Lindsey et al. [44] , ma presenta<br />
una interpretazione del tutto <strong>di</strong>versa del concetto <strong>di</strong> cluster-head. Per<br />
chiarezza consideriamo una WSN dotata <strong>di</strong> un nodo sink e <strong>di</strong> un cluster A e<br />
un cluster B, dove con X0…Xn-1 in<strong>di</strong>chiamo i mote appartenenti al cluster A<br />
e con Y0…Ym-1 i mote appartenenti al cluster B. Supponiamo che i no<strong>di</strong> X0<br />
e Y0 siano rispettivamente i cluster-head. Secondo Lindsey i no<strong>di</strong> X0 e Y0<br />
saranno rispettivamente quelli che dovranno incaricarsi dell’inoltro delle<br />
misurazioni effettuate dagli altri mote all’interno del cluster (cioè dei no<strong>di</strong><br />
X1..Xn-1 e Y1…Yn-1 rispettivamente), in altri termini fungono da interme<strong>di</strong>ari<br />
tra i sensori appartenenti al cluster A e cluster B e il nodo sink. In questa<br />
accezione la scelta <strong>di</strong> avere una procedura <strong>di</strong> leader-election perio<strong>di</strong>ca è<br />
nell’ottica <strong>di</strong> scegliere <strong>di</strong>namicamente il nodo dotato <strong>di</strong> uno “stato <strong>di</strong> salute”<br />
migliore e in grado <strong>di</strong> comunicare con il nodo sink nel modo<br />
energeticamente più efficiente.<br />
In questo lavoro <strong>di</strong> <strong>tesi</strong> questo concetto viene ulteriormente estremizzato<br />
considerando il cluster-head come l’unico nodo delegato alla misurazione<br />
durante un ciclo <strong>di</strong> monitoraggio. In questo caso quin<strong>di</strong> i no<strong>di</strong> X1..Xn-1 e<br />
Y1..Yn-1 non saranno soggetti al carico computazionale dovuto alla<br />
procedura <strong>di</strong> misurazione e avranno solo un ruolo passivo all’interno della<br />
rete. Più in particolare si possono prevedere due scenari: un primo in cui i<br />
suddetti no<strong>di</strong> svolgeranno le usuali azioni atte al forwar<strong>di</strong>ng dei pacchetti<br />
provenienti dagli altri no<strong>di</strong> e all’aggiornamento delle tabelle <strong>di</strong> routing per il<br />
funzionamento del protocollo multihop., e un secondo in cui i no<strong>di</strong> sono<br />
completamente spenti e saranno previste procedure <strong>di</strong> risveglio solo per<br />
partecipare alla procedura <strong>di</strong> elezione <strong>di</strong> un nuovo leader. Riguardo la<br />
procedura <strong>di</strong> leader-election, risulta chiaro, in questo caso, che è intesa<br />
maggiormente nell’ottica <strong>di</strong> load-balancing e potrà essere sviluppata in<br />
qualsiasi modo e quin<strong>di</strong> sia seguendo un para<strong>di</strong>gma che mira a eguagliare i<br />
tempi <strong>di</strong> carico dei vari mote, sia seguendo un para<strong>di</strong>gma che mira a rendere<br />
73
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
il consumo energetico dei mote all’interno dello stesso cluster quanto più<br />
uniforme possibile.<br />
3.6.1 Procedura <strong>di</strong> elezione del leader<br />
Riguardo la procedura <strong>di</strong> leader-election la rete è stata addestrata seguendo<br />
sostanzialmente due linee guida:<br />
1. chi effettua l’elezione;<br />
2. intervallo temporale in cui un nodo è cluster head<br />
Dalla combinazione delle due possono essere ricavati quattro scenari<br />
<strong>di</strong>versi, in particolare una prima soluzione ha previsto <strong>di</strong> delegare la<br />
procedura <strong>di</strong> elezione ai no<strong>di</strong> del cluster prevedendo un rate perio<strong>di</strong>co <strong>di</strong><br />
attivazione della procedura per l’elezione <strong>di</strong> un nuovo leader. Una seconda,<br />
invece, ha previsto un algoritmo centralizzato dove è il nodo sink a decidere<br />
il futuro leader <strong>di</strong> un cluster e prevedendo una nuova elezione solo nel<br />
momento in cui un nodo leader ha esaurito le proprie riserve energetiche.<br />
Riguardo la prima soluzione l’algoritmo <strong>di</strong> elezione <strong>di</strong>stribuito scelto<br />
all’interno del cluster è stato una sorta <strong>di</strong> election ring opportunamente<br />
mo<strong>di</strong>ficato per adattarsi al meglio alle caratteristiche delle reti <strong>di</strong> sensori<br />
senza cavo. Ovvero si prevede che ogni cluster sia organizzato in un anello<br />
logico dove ogni nodo sensore <strong>di</strong>venta cluster-head nel caso in cui abbia un<br />
token che gli può essere stato assegnato dall’inizio o ceduto da un altro nodo<br />
sensore. L’algoritmo è stato preferito rispetto all’algoritmo <strong>di</strong> Garcia Molina<br />
(algoritmo del prepotente o del bully), soprattutto per il basso carico<br />
computazionale della procedura <strong>di</strong> elezione. Volendo essere più precisi in<br />
questo caso la procedura <strong>di</strong> elezione è ridotta al minimo ma ciò ben si sposa<br />
con l’obiettivo <strong>di</strong> evitare quanto più è possibile sprechi <strong>di</strong> energia e<br />
<strong>di</strong>stribuire quanto più è possibile il carico tra i no<strong>di</strong> sensori. La gestione <strong>di</strong><br />
no<strong>di</strong> che esauriscono le proprie riserve energetiche e <strong>di</strong> fallimenti nelle<br />
74
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
comunicazioni possono essere gestite in maniera efficiente tramite varie<br />
politiche. La situazione che potrebbe verificarsi è quella in cui il nodo<br />
can<strong>di</strong>dato a <strong>di</strong>ventare il prossimo cluster-head sia non raggiungibile o a<br />
causa <strong>di</strong> una degradazione del collegamento o a causa del suo esaurimento<br />
energetico. In questi due casi il nodo che attualmente riveste il ruolo <strong>di</strong><br />
leader può avere sia un approccio ottimistico e quin<strong>di</strong> rimanere ancora<br />
leader per un altro ciclo <strong>di</strong> misurazione (tentando poi <strong>di</strong> ricontattarlo nella<br />
successiva fase <strong>di</strong> elezione) o tentare <strong>di</strong> contattare il prossimo nodo<br />
dell’anello logico, ancora attivo. Riguardo la scelta del nuovo cluster-head<br />
ovvero del sensore a cui cedere il token si possono immaginare algoritmi<br />
che scelgano in base allo stato <strong>di</strong> salute generale dei vari no<strong>di</strong>, rifacendosi in<br />
generale a PEGASIS o HEED, però anche se ciò tiene maggiormente in<br />
conto lo stato <strong>di</strong> “salute” generale del cluster, dall’altro si ha un notevole<br />
incremento dei messaggi che i vari no<strong>di</strong> sensori devono scambiarsi al fine <strong>di</strong><br />
poter prendere una decisione.<br />
La seconda soluzione prevede invece che sia il nodo sink a <strong>di</strong>stribuire i<br />
token. In questo caso si presuppone che il nodo delegato al ruolo <strong>di</strong> leader<br />
resti lo stesso fino al suo esaurimento energetico, dopo<strong>di</strong>chè sarà sempre il<br />
nodo sink ad eleggerne un altro.<br />
3.7 ALGORITMI DI TRASPORTO AFFIDABILE<br />
Fino ad ora è si sono presi in considerazione aspetti quali il clustering e<br />
l’elezione al fine <strong>di</strong> aumentare la vita me<strong>di</strong>a della rete però non è stato<br />
ancora trattato il problema <strong>di</strong> avere un protocollo <strong>di</strong> trasporto che sia<br />
affidabile e che quin<strong>di</strong> si incarichi del recapito affidabile delle misurazioni<br />
presso il nodo sink.<br />
Il problema <strong>di</strong> avere una trasmissione affidabile tra no<strong>di</strong> sensori remoti<br />
anche in presenza <strong>di</strong> più passi <strong>di</strong> comunicazione (multihop), <strong>di</strong> errori sui<br />
canali, <strong>di</strong> collisioni e <strong>di</strong> congestione ha le seguenti <strong>di</strong>mensioni:<br />
75
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
1. trasmissione <strong>di</strong> : pacchetti singoli vs blocchi <strong>di</strong> pacchetti vs stream<br />
<strong>di</strong> pacchetti in quanto il recapito affidabile <strong>di</strong> singoli pacchetti può<br />
essere importante ad esempio per dati aggregati, quello <strong>di</strong> blocchi<br />
adatto per applicazioni che usano meccanismi <strong>di</strong> <strong>di</strong>sseminazione <strong>di</strong><br />
query nella rete, mentre quello <strong>di</strong> stream adatto per applicazioni col<br />
compito <strong>di</strong> consegna perio<strong>di</strong>che <strong>di</strong> gruppi <strong>di</strong> misurazioni<br />
2. recapito garantito vs recapito stocastico in quanto per alcune<br />
applicazioni può essere necessario un alto livello <strong>di</strong> affidabilità,<br />
come le query <strong>di</strong>stribuite, ect mentre altre possono anche tollerare<br />
per<strong>di</strong>te purchè contenute in un certo range (ad esempio quando<br />
molti sensori provvedono ad inviare misurazioni correlate tra <strong>di</strong><br />
loro);<br />
3. dai no<strong>di</strong> sensori al sink vs dal nodo sink ai sensori e in questo<br />
caso si parla <strong>di</strong> “forward path” quando il flusso è quello che parte<br />
dai no<strong>di</strong> e arriva al Sink e <strong>di</strong> “reverse path” quando il flusso<br />
interessa i dati inviati dal sink verso i no<strong>di</strong> della rete.<br />
Il “Reliable Multi-Segment Transport” (RMST) proposto da Heidemann et<br />
al. [61] e il “Pump Slowly, Fetch Quickly” (PSFQ) <strong>di</strong> Wan et al. [62]<br />
realizzano un protocollo <strong>di</strong> trasporto per il recapito al sink <strong>di</strong> blocchi <strong>di</strong><br />
pacchetti. L’RMST fu progettato per essere utilizzato unitamente al <strong>di</strong>rect<br />
<strong>di</strong>ffusion [63] e prevede uno schema <strong>di</strong> recapito dei pacchetti <strong>di</strong> tipo “endto-end”.<br />
Il protocollo è basato su l’utilizzo selettivo <strong>di</strong> messaggi NACK e<br />
può essere usato secondo due schemi: “caching mode” e “non caching<br />
mode”. Secondo il primo schema un numero <strong>di</strong> no<strong>di</strong> lungo un percorso, ad<br />
esempio quello utilizzato dal <strong>di</strong>rect <strong>di</strong>ffusion per recapitare i dati al nodo<br />
sink, sono denominati come “RMST node”. Ogni RSMT node provvede a<br />
memorizzare in cache i frammenti <strong>di</strong> dati che compongono il flusso <strong>di</strong><br />
comunicazione, e a mantenere un timer associato ad ogni flusso <strong>di</strong><br />
comunicazione. Quando un frammento non è ricevuto prima che il timer sia<br />
76
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 3.4: Architettura protocollo RMST<br />
scaduto viene inviato un NACK sul percorso e il primo RMST node che ha<br />
l’informazione richiesta provvede a ritrasmetterla. Il sink in questo caso<br />
agisce come ultimo RMST node e risulta essere l’unico se si utilizza la<br />
modalità non caching. Gli svantaggi <strong>di</strong> questo tipo <strong>di</strong> protocollo sono<br />
principalmente legati: 1) al meccanismo <strong>di</strong> caching che richiede un<br />
significativo overhead in termini <strong>di</strong> potenza <strong>di</strong>ssipata per le operazioni <strong>di</strong><br />
mantenimento e 2) al problema <strong>di</strong> essere legati al <strong>di</strong>rect <strong>di</strong>ffusion.<br />
Il protocollo PSFQ proposto da Wan et al.[62] è molto simile al RMST solo<br />
che opera sul “reverse path” ovvero da sink a no<strong>di</strong> sensore e comprende tre<br />
funzioni:<br />
1. trasmissione dei messaggi velocemente (operazione <strong>di</strong> pump)<br />
2. recupero veloce da errori <strong>di</strong> trasmissione (operazione <strong>di</strong> fetch)<br />
3. monitoraggio dello stato selettivo (operazione <strong>di</strong> report).<br />
Ogni nodo interme<strong>di</strong>o mantiene i dati in una cache; quando viene ricevuto<br />
un pacchetto il nodo controlla il contenuto confrontandolo con quelli<br />
contenuti in cache e vengono scartati i duplicati. Se il pacchetto ricevuto<br />
non era contenuto in cache allora significa che è nuovo, <strong>di</strong> conseguenza<br />
viene decrementato il campo TTL e viene inoltrato ai vicini nel caso in cui il<br />
TTL non sia uguale a zero e non vi siano salti nei numeri <strong>di</strong> sequenza dei<br />
pacchetti. Nel caso in cui è rilevato un salto nei numeri <strong>di</strong> sequenza allora il<br />
77
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
nodo effettua una operazione <strong>di</strong> fetch richiedendo una ritrasmissione ai no<strong>di</strong><br />
vicini. Anche questo protocollo risulta molto oneroso in termini <strong>di</strong> potenza<br />
<strong>di</strong>ssipata e inoltre presenta anche un grosso inconveniente, in quanto la<br />
reliability hop by hop non garantisce la reliability end-to-end.<br />
Lo schema sviluppato nel protocollo GARUDA [64] molto simile al PSFQ è<br />
mirato al trasporto affidabile <strong>di</strong> blocchi <strong>di</strong> dati dal nodo sink a tutti gli altri<br />
sensori o a una parte significativa della rete. Questo protocollo usa uno<br />
schema basato su messaggi <strong>di</strong> NACK e fa molta attenzione che il primo<br />
pacchetto <strong>di</strong> un blocco sia recapitato in modo affidabile a tutti i sensori. In<br />
questo modo viene risolto il problema <strong>degli</strong> schemi basati sui messaggi<br />
NACK ovvero i destinatari devono ricevere almeno un pacchetto del blocco<br />
affinché possano accorgersi delle per<strong>di</strong>te <strong>di</strong> ulteriori pacchetti.<br />
I protocolli fino ad ora descritti sono stati concepiti per assicurare una<br />
affidabilità <strong>di</strong> tipo end to end a livello <strong>di</strong> pacchetti. Akyil<strong>di</strong>z, invece propone<br />
ESRT (Event to Sink Reliable Transport) un protocollo per gestire la<br />
reliability sulla forward path <strong>di</strong> tipo end to end orientata invece a stream <strong>di</strong><br />
pacchetti e in particolare quin<strong>di</strong> agli eventi che vengono monitorati in una<br />
rete <strong>di</strong> sensori senza cavo. La conoscenza su un fenomeno viene calcolata<br />
basandosi sul numero <strong>di</strong> pacchetti ricevuti; definendo con r il numero <strong>di</strong><br />
pacchetti ricevuti in un intervallo <strong>di</strong> decisione e con R il numero <strong>di</strong> pacchetti<br />
richiesti per poter definire che l’osservazione dell’evento è “reliable” allora<br />
possiamo <strong>di</strong>re che se r>R allora la rilevazione dell’evento può essere<br />
definita come affidabile dal punto <strong>di</strong> vista della trasmissione delle<br />
misurazioni. Nel caso in cui r
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
RMST GARUDA PSFQ ESRT<br />
Direzione Sensor to sink Sink to sensor Sink to sensor Sensor to sink<br />
Orientamento Pacchetto blocco pacchetto stream<br />
Stile Hop-by-hop Hop-by-hop Hop-by-hop End-to-end<br />
Uso <strong>di</strong> NACK Si Si Si No<br />
Risparmio<br />
energetico<br />
- - - Si<br />
Recupero<br />
per<strong>di</strong>te<br />
Si Si Si -<br />
Uso <strong>di</strong> cache Si Si Si -<br />
Controllo della<br />
congestione<br />
no no no si<br />
Tabella 3-1:Schema riassuntivo dei protocolli <strong>di</strong> trasporto affidabili<br />
nuova frequenza con cui i no<strong>di</strong> sensori dovranno recapitare le loro<br />
informazioni sia influenzata dallo stato generale della rete. Maggiori<br />
informazioni su un esempio <strong>di</strong> protocollo appositamente progettato per il<br />
controllo della congestione sul “forward path” si possono reperire in [65]<br />
dove è presentato CODA (Congestion Detection and Avoidance).<br />
Uno schema riassuntivo dei protocolli analizzati viene riportato nella tabella<br />
3-1.<br />
3.8 APPROCCIO PROPOSTO PER IL TRASPORTO<br />
AFFIDABILE DELLE MISURAZIONI<br />
Anche se sono stati proposti molti protocolli per raggiungere affidabilità<br />
nella trasmissione delle informazioni in reti <strong>di</strong> sensori senza cavo, nessuno<br />
<strong>di</strong> essi è stato standar<strong>di</strong>zzato. Del resto anche questi protocolli sono molto<br />
suscettibili all’applicazione nella quale questi vengono utilizzati e <strong>di</strong><br />
conseguenza risulta <strong>di</strong>fficile effettuare una scelta che sia definitiva per ogni<br />
ambito applicativo. Ritornando ai requisiti espressi nel paragrafo 3.1,<br />
bisogna naturalmente tener conto nella scelta della necessità <strong>di</strong> avere un<br />
79
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
protocollo <strong>di</strong> consegna dei dati energeticamente efficiente. Dalla tabella 3.1<br />
risulta chiaro che l’unico protocollo che tiene conto del risparmio energetico<br />
è il protocollo ESRT (per stream <strong>di</strong> pacchetti) il quale si basa sull’idea <strong>di</strong><br />
poter cambiare la frequenza con cui i no<strong>di</strong> sensori recapitano le<br />
informazioni al nodo sink. Tenendo conto che il fine del lavoro è la<br />
valutazione <strong>di</strong> protocolli energeticamente efficienti e riuscire ad ottenere<br />
metriche per la valutazione complessiva della dependability del sistema, si è<br />
deciso <strong>di</strong> ricorrere a un semplice protocollo <strong>di</strong> tipo end-to-end in cui<br />
venissero utilizzati un numero minimo <strong>di</strong> trasmissioni <strong>di</strong> pacchetti al fine <strong>di</strong><br />
limitare al minimo il consumo energetico dei mote.<br />
L’idea <strong>di</strong> seguire un tale approccio è del resto giustificata in quanto non è<br />
detto che in ogni trasmissione vi siano per<strong>di</strong>te quin<strong>di</strong> può risultare utile<br />
dotare il nodo sink della intelligenza sufficiente per effettuare una<br />
operazione <strong>di</strong> monitoraggio dello stato della rete basandosi unicamente sui<br />
pacchetti ricevuti in instanti precedenti dai no<strong>di</strong> sensori. Sarà compito<br />
quin<strong>di</strong> del nodo sink provvedere all’inoltro delle richieste <strong>di</strong> ritrasmissione<br />
<strong>di</strong>rette ai sensori dai quali non ha ricevuto nessuna risposta in quanto sarà<br />
esso stesso ad avere una chiara situazione della copertura raggiunta in ogni<br />
ciclo <strong>di</strong> misurazione.<br />
Secondo questo para<strong>di</strong>gma i no<strong>di</strong> sensori sono semplicemente ridotti ad<br />
entità passive che effettuano cicli <strong>di</strong> misurazione su richiesta e provvedono<br />
all’inoltro delle misurazioni al nodo sink. Rispetto quin<strong>di</strong> ai protocolli<br />
accennati nel precedente paragrafo non dovranno gestire nessuna cache<br />
interna e non dovranno monitorare lo stato della rete. L’unica informazione<br />
conservata dai sensori sarà la stima dell’ultima misurazione effettuata, al<br />
fine <strong>di</strong> poterla rispe<strong>di</strong>re nel caso in cui arrivi una richiesta <strong>di</strong> ritrasmissione<br />
da parte del nodo sink.<br />
Per essere più chiari sulla <strong>di</strong>namica dell’algoritmo consideriamo lo scenario<br />
<strong>di</strong> figura 3.5. La rete risulta composta da 8 no<strong>di</strong> sensori atti al monitoraggio<br />
80
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 3.5: Rete composta da otto <strong>di</strong>spositivi sensori<br />
<strong>di</strong> una particolare zona. Tutti i no<strong>di</strong> sensori effettueranno la misurazione su<br />
richiesta del nodo sink e provvederanno all’invio della misura. Il sink<br />
quin<strong>di</strong>, in assenza <strong>di</strong> collisioni, errori <strong>di</strong> trasmissioni, ect, riceverà un totale<br />
<strong>di</strong> 8 misurazioni con copertura della rete al 100%. A questo punto<br />
consideriamo le situazioni anomale che possono occorrere:<br />
1. Trasmissione fallita a causa <strong>di</strong> collisioni, pacchetti corrotti, ect.;<br />
2. Esaurimento energetico del <strong>di</strong>spositivo che causa una non<br />
trasmissione della misurazione.<br />
Riguardo il primo problema il protocollo proposto prevede <strong>di</strong> attivare una<br />
procedura <strong>di</strong> recupero <strong>di</strong> eventuali per<strong>di</strong>te <strong>di</strong> informazioni effettuando un<br />
massimo numero <strong>di</strong> tentativi (NRO_MAX_REQUEST_COVERAGE) per cercare <strong>di</strong><br />
raggiungere la copertura della rete dopo i quali la copertura completa<br />
fallisce.<br />
Il secondo problema, invece non viene risolto e risulta essere gravoso nei<br />
confronti delle operazioni <strong>di</strong> monitoraggio soprattutto se si è previsto<br />
l’utilizzo <strong>di</strong> un unico sensore per la rilevazione <strong>di</strong> una grandezza <strong>di</strong><br />
interesse.<br />
81
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 3.6: Rete organizzata in 3 cluster senza procedura <strong>di</strong> elezione <strong>di</strong> cluster-head<br />
3.9 CLUSTERING E LEADER ELECTION<br />
In merito all’esaurimento energetico <strong>di</strong> un <strong>di</strong>spositivo che causa una non<br />
trasmissione delle misurazioni, un approccio basato sulla organizzazione in<br />
cluster della rete può venire in aiuto.<br />
Consideriamo lo scenario <strong>di</strong> figura 3.6 in cui la rete risulta organizzata in 3<br />
cluster: A, B e C rispettivamente <strong>di</strong> 3,3 e 2 no<strong>di</strong> sensori dove non è prevista<br />
nessuna procedura <strong>di</strong> leader election (§ 3.6.1), cioè tutti i no<strong>di</strong> sensori<br />
effettueranno la misurazione su richiesta del nodo sink e provvederanno<br />
all’invio. Il sink quin<strong>di</strong>, in assenza <strong>di</strong> collisioni, errori <strong>di</strong> trasmissioni, ect,<br />
riceverà un totale <strong>di</strong> 8 misurazioni afferenti ai tre cluster con copertura della<br />
rete al 100%.<br />
Poiché la clusterizzazione (§ 3.4) prevede <strong>di</strong> sud<strong>di</strong>videre l’area da<br />
monitorare in zone <strong>di</strong> interesse, si può affermare che nel caso <strong>di</strong> ricezione<br />
<strong>di</strong> almeno n=1 misurazioni per cluster la copertura globale della rete è<br />
raggiunta e quin<strong>di</strong> non sorgono problemi né per il punto 1 né per il punto 2<br />
menzionati nel precedente paragrafo. Si può concludere affermando che si<br />
hanno a <strong>di</strong>sposizione un margine <strong>di</strong> 2 non recapiti <strong>di</strong> misurazioni per i<br />
cluster A e B e <strong>di</strong> uno per il cluster C al fine <strong>di</strong> ottenere una completa<br />
copertura della rete senza “overhead” aggiuntivi dovuti a trasmissioni <strong>di</strong><br />
82
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
pacchetti nella rete per avviare l’operazione <strong>di</strong> richiesta <strong>di</strong> ritrasmissioni.<br />
Scendendo più in dettaglio sulla <strong>di</strong>namica dell’approccio viene previsto un<br />
massimo numero <strong>di</strong> tentativi (NRO_MAX_REQUEST_COVERAGE) a <strong>di</strong>sposizione<br />
del nodo sink per cercare <strong>di</strong> raggiungere la copertura della rete dopo i quali<br />
la copertura completa fallisce. Questo semplice scenario mette in luce ancor<br />
<strong>di</strong> più come il concetto <strong>di</strong> “clusterizzazione” risulta essere alla base per<br />
l’implemetazione <strong>di</strong> strategie <strong>di</strong> tolleranza <strong>di</strong> guasti sia transienti che<br />
permanenti e come ci venga in aiuto soprattutto per “rilassare” il requisito <strong>di</strong><br />
avere un trasporto affidabile. Infatti l’utilizzo <strong>di</strong> un protocollo come l’ESRT<br />
o simili avrebbe imme<strong>di</strong>atamente attivato meccanismi <strong>di</strong> ritrasmissione con<br />
il coinvolgimento <strong>di</strong> tutti i no<strong>di</strong> che componevano il “transmission path”.<br />
Ciò avrebbe portato ad un overhead in termini <strong>di</strong> banda e energia spesa<br />
anche se la copertura della rete era stata comunque raggiunta.<br />
Detto ciò analizziamo ora il caso <strong>di</strong> figura 3.7 ovvero lo scenario che vede<br />
una rete organizzata in cluster in cui in ogni cluster viene applicata la<br />
procedura <strong>di</strong> leader election (§ 3.6.1). La situazione in questo caso è un po’<br />
più complessa in quanto saranno interessati da misurazioni solo i relativi<br />
cluster-head e non più tutti i <strong>di</strong>spositivi che fanno parte del cluster e quin<strong>di</strong><br />
<strong>di</strong>minuisce il margine <strong>di</strong> errori <strong>di</strong> trasmissioni che si possono tollerare prima<br />
Figura 3.7: Organizzazione in cluster della rete con cluster-head<br />
83
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
<strong>di</strong> dover ricorrere a ritrasmissioni ( e quin<strong>di</strong> ad un overhead aggiuntivo).<br />
Questo ultimo scenario risulta essere un ottimo trade-off tra la necessità <strong>di</strong><br />
ridurre al minimo le possibilità <strong>di</strong> congestione della rete e implementare<br />
politiche mirate al risparmio energetico dei no<strong>di</strong>.<br />
84
Capitolo 4<br />
Valutazione comparativa <strong>degli</strong> algoritmi<br />
4.1 OBIETTIVI<br />
L’obiettivo <strong>di</strong> questo capitolo è effettuare una analisi comparativa dei<br />
protocolli proposti nel precedente capitolo per il problema del trasporto su<br />
reti <strong>di</strong> sensori senza cavo. Il tool <strong>di</strong> sviluppo utilizzato per i vari test è stato<br />
Tossim Tinyviz.<br />
Le caratteristiche che si prenderanno in considerazione durante le<br />
simulazioni che verranno testate saranno principalmente:<br />
1. Il numero <strong>di</strong> no<strong>di</strong> che costituiscono la rete (tipicamente da 9 a 18<br />
no<strong>di</strong> sensori);<br />
2. il protocollo <strong>di</strong> trasporto utilizzato per il recapito delle misurazioni<br />
nel percorso dai sensori al nodo sink (forward path);<br />
3. la topologia della rete (organizzata in cluster o non organizzata in<br />
cluster)<br />
e si andrà a verificare come il variare delle caratteristiche impatti su:<br />
o copertura raggiunta;<br />
o consumo energetico dei no<strong>di</strong>.<br />
Obiettivo interessante è riuscire a comprendere per i vari scenari che<br />
verranno testati come la copertura della rete è influenzata dal numero <strong>di</strong><br />
85
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
<strong>di</strong>spositivi utilizzati al fine <strong>di</strong> trovare un “trade-off” tra costi <strong>di</strong> realizzazione<br />
della rete e percentuale <strong>di</strong> copertura che si vuole raggiungere. A tutto ciò è<br />
poi aggiunto l’esigenza <strong>di</strong> ottenere soluzioni che possano aumentare il più<br />
possibile la durata me<strong>di</strong>a della vita <strong>di</strong> una rete <strong>di</strong> sensori senza cavo ovvero<br />
soluzioni che mirino ad un consumo minimo delle risorse energetiche dei<br />
no<strong>di</strong>.<br />
Per caratterizzare al meglio le misure ottenute dalla simulazione si è deciso<br />
<strong>di</strong> analizzare i parametri suddetti in due possibili scenari:<br />
1) con l’utilizzo della plugin Tinysan [70] che offre sia la possibilità <strong>di</strong><br />
simulare la qualità dei link (simulando aleatorità nella probabilità <strong>di</strong><br />
consegna dei pacchetti) che la possibilità <strong>di</strong> avere una stima del<br />
consumo energetico dei no<strong>di</strong>;<br />
2) senza l’utilizzo della plugin Tinysan.<br />
Il secondo scenario naturalmente presenta delle limitazioni però risulta<br />
essere utile soprattutto per capire la scalabilità della rete, all’aumentare del<br />
numero si sensori utilizzati e in particolar modo quanto l’aumento dei<br />
sensori impatti sulla copertura raggiunta. Infatti con l’uso della plugin<br />
Tinysan si ottiene una aleatorietà nelle probabilità <strong>di</strong> consegna dei pacchetti<br />
(a causa del cambiamento delle probabilità sui link <strong>di</strong> comunicazione) che<br />
non permette <strong>di</strong> avere uno scenario unico dove poter effettuare i vari test in<br />
modo univoco. Quin<strong>di</strong> con la combinazione dei due approcci possono<br />
essere esaminati sia il problema delle collisioni dovute a trasmissioni<br />
contemporanee dei no<strong>di</strong>, sia la per<strong>di</strong>ta dei pacchetti dovuta alla qualità dei<br />
link tra i sensori che costituiscono la rete.<br />
4.2 DATA GATHERING BASE<br />
Lo scenario comune che è la base delle varie simulazioni effettuate prevede<br />
il monitoraggio <strong>di</strong> un’area attraverso il tool <strong>di</strong> simulazione per reti <strong>di</strong> sensori<br />
86
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
NOME PROGETTO Simple_Data_Gathering<br />
OBIETTIVI Il nodo con ID 0 è incaricato della raccolta<br />
dati da tutti gli altri sensori nella rete.<br />
PROTOCOLLO DI TRASPORTO<br />
USATO<br />
Best-effort<br />
TOPOLOGIA DELLA RETE Non previsto uso <strong>di</strong> cluster<br />
Tabella 4-1: Caratteristiche della simulazione n°1<br />
senza cavo Tossim. Si suppone che le richieste <strong>di</strong> misurazione vengano<br />
effettuate dal nodo base (sink) con una certa frequenza perio<strong>di</strong>ca che può<br />
essere sincrona con il clock locale del nodo sink o eventualmente asincrona<br />
nel caso in cui si provveda all’implementazione <strong>di</strong> una interfaccia che<br />
consenta all’operatore umano <strong>di</strong> inoltrare a proprio piacimento richieste <strong>di</strong><br />
misurazioni. Le caratteristiche principali della simulazione sono riportate in<br />
tabella 4.1. Supponiamo, che i sensori siano <strong>di</strong>slocati nell’area <strong>di</strong> cui si<br />
vuole effettuare una analisi, in modo tale da avere un solo sensore per ogni<br />
zona dalla quale si esige una misura. La possibile architettura della rete è<br />
Figura 4.1: Architettura della rete in Tinyviz<br />
87
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
mostrata in figura 4.1 dove si in<strong>di</strong>viduano 9 no<strong>di</strong> sensori, <strong>di</strong> cui quello con<br />
id pari a 0 (nodo più a destra) è il nodo sink mentre gli altri sono i no<strong>di</strong><br />
addetti alle misurazioni. Le linee punto punto in grigio rappresentano i<br />
collegamenti che godono <strong>di</strong> una probabilità <strong>di</strong> per<strong>di</strong>ta dei pacchetti inferiore<br />
al 30%, mentre quelli in rosso collegamenti con probabilità compresa tra il<br />
30% e il 70%. Risulta chiaro, dalle caratteristiche esposte in tabella 4.1, che<br />
per avere una completa caratterizzazione dell’evento monitorato è<br />
necessario che ogni sensore recapiti la propria misurazione/i al nodo sink,<br />
quin<strong>di</strong> una per<strong>di</strong>ta <strong>di</strong> pacchetto dovuta alla congestione della rete o alla<br />
bassa qualità del link tra i no<strong>di</strong> causerà una situazione in cui il nodo sink<br />
non avrà a <strong>di</strong>sposizione tutte le informazioni necessarie al monitoraggio<br />
della zona interessata.<br />
Riguardo lo schema implementativo dell’applicazione questo risulta essere<br />
molto semplice e uno stralcio del file <strong>di</strong> configurazione è presentato in<br />
configuration Simple_Data_Gathering {}<br />
implementation {<br />
components Main, SurgeM, TimerC, LedsC, NoLeds, Photo, RandomLFSR,<br />
GenericCommPromiscuous as Comm, Bcast, MultiHopRouter as<br />
multihopM, QueuedSend, Sounder;<br />
....<br />
SurgeM.TimerControlCoverage -> TimerC.Timer[unique("Timer")];<br />
SurgeM.MeasureTimer -> TimerC.Timer[unique("Timer")];<br />
SurgeM.RouteControl -> multihopM;<br />
SurgeM.Send->multihopM.Send[AM_SURGEMSG];<br />
multihopM.ReceiveMsg[AM_SURGEMSG]->Comm.ReceiveMsg[AM_SURGEMSG];<br />
//Per mandare e ricevere messaggi <strong>di</strong> misurazione<br />
SurgeM.SendMeasureMsg -> Comm.SendMsg[AM_MEASUREMSG];<br />
SurgeM.ReceiveMeasureMsg -> Comm.ReceiveMsg[AM_MEASUREMSG];<br />
//usato dal sink per ricevere le misure<br />
SurgeM.ReceiveMeasure -> Comm.ReceiveMsg[AM_SURGEMSG];<br />
Figura 4.2: Stralcio del file <strong>di</strong> configurazione della prima simulazione<br />
88<br />
1<br />
3<br />
2
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
event TOS_MsgPtr ReceiveMeasure.receive(TOS_MsgPtr receivedMessage) {<br />
int i;<br />
if(TOS_LOCAL_ADDRESS==0 && receivedMessage->addr==0x7e)<br />
{<br />
SurgeMsg * payload;<br />
payload2 = (TOS_MHopMsg *)receivedMessage->data;<br />
payload = (SurgeMsg *)payload2->data;<br />
dbg(DBG_TEMP," Msr DAL NODO: %d \n",payload2->originaddr);<br />
for(i=0;irea<strong>di</strong>ng[i]);<br />
setCoverage();<br />
}<br />
return receivedMessage;<br />
}<br />
Figura 4.3: Evento ReceiveMeasure attivato sul nodo sink alla ricezione della<br />
misurazione<br />
figura 4.2 attraverso il quale si possono comprendere i componenti che<br />
costituiscono l’applicazione e come sono legati tra <strong>di</strong> loro. Di particolare<br />
interesse sono i due Timer (riquadro 1) utilizzati: MeasureTimer e<br />
TimerControlCoverage. Il primo timer temporizza le richieste <strong>di</strong><br />
misurazioni effettuate dal nodo sink, mentre il secondo viene sempre<br />
attivato dal nodo sink e serve per effettuare il controllo della copertura<br />
ottenuta sulla rete. Nel riquadro 2 sono invece evidenziati i collegamenti<br />
utili all’utilizzo del protocollo multihop, mentre il riquadro 3 mette in luce i<br />
collegamenti con i componenti che gestiscono la comunicazione tra i no<strong>di</strong>.<br />
In figura 4.3 viene invece mostrata l’implementazione dell’ evento<br />
ReceiveMeasure attivato dal nodo sink ad ogni ricezione <strong>di</strong> un messaggio <strong>di</strong><br />
misurazione dai no<strong>di</strong> sensori. Le operazioni svolte alla ricezione sono 2:<br />
o Estrazione della misurazione/i dal pacchetto dati ricevuto;<br />
o Settaggio della copertura raggiunta al fine <strong>di</strong> avere statistiche<br />
relative ai no<strong>di</strong> che hanno risposto alle richieste <strong>di</strong> monitoraggio<br />
(metodo setCoverage).<br />
Un primo test è stato condotto al fine <strong>di</strong> comprendere quanto il numero dei<br />
sensori utilizzati influisse sulla copertura raggiunta. Si è quin<strong>di</strong> seguito<br />
89
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 4.4: Andamento % della ricezione delle misurazioni<br />
al crescere del numero <strong>di</strong> no<strong>di</strong>.<br />
l’approccio 2 illustrato nel paragrafo 4.1 (ovvero si tralascia l’utilizzo della<br />
plugin TinySan); i risultati ottenuti hanno mostrato una copertura totale<br />
della zona monitorata nel 94% delle misurazioni usando un numero <strong>di</strong> no<strong>di</strong><br />
pari a 9. La percentuale <strong>di</strong> raggiungimento <strong>di</strong> una completa caratterizzazione<br />
del fenomeno va poi decrescendo linearmente all’aumentare dei no<strong>di</strong> sensori<br />
come illustrato in figura 4.4. Con questo test si comprende come<br />
all’aumentare del numero <strong>di</strong> no<strong>di</strong> aumenti la probabilità <strong>di</strong> collisione dei<br />
pacchetti dovuto a congestione della rete e quin<strong>di</strong> come sia più facile avere<br />
per<strong>di</strong>te <strong>di</strong> informazioni al nodo sink.<br />
Se consideriamo invece l’approccio 1 (§ 4.1) che prevede l’utilizzo della<br />
plugin Tinysan si può notare come la percentuale <strong>di</strong> corretta ricezione delle<br />
misurazioni presso il nodo sink, in ogni ciclo <strong>di</strong> misurazione, cominci a<br />
<strong>di</strong>ventare molto più bassa. Infatti secondo questa metodologia la possibilità<br />
che la misurazione venga trasmessa correttamente al nodo sink <strong>di</strong>pende non<br />
solo dalla possibile congestione della rete ma anche dalla probabilità<br />
intrinseca <strong>di</strong> trasmissione sul singolo link simulata appunto con l’utilizzo<br />
della plugin TinySan. Come si può osservare in figura 4.5, ad eccezione del<br />
caso con 12 sensori in cui la % <strong>di</strong> corretta ricezione aumenta rispetto al caso<br />
90
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 4.5: Andamento % della ricezione delle misurazioni<br />
con utilizzo della plugin TinySan.<br />
precedente, l’andamento segue prettamente una funzione lineare decrescente<br />
al crescere del numero <strong>di</strong> no<strong>di</strong> utilizzati all’interno della rete. È chiaro che i<br />
dati sono puramente statistici e <strong>di</strong>pendono molto dalla funzione che<br />
caratterizza la qualità trasmissiva del link attraverso cui avviene la<br />
comunicazione sul singolo canale e dalle rotte scelte dai sensori per inoltrare<br />
le misurazioni al nodo sink.<br />
4.3 DATA GATHERING AFFIDABILE<br />
Partendo dalla applicazione descritta nel paragrafo 4.2 viene ora<br />
implementato uno schema <strong>di</strong> comunicazione affidabile per il recapito delle<br />
misurazioni al nodo sink (in tabella 4.2 sono riportate le caratteristiche alla<br />
NOME PROGETTO Reliable_Data_Gathering<br />
OBIETTIVI Il sink è incaricato della raccolta dati da tutti<br />
gli altri sensori nella rete.<br />
PROTOCOLLO DI TRASPORTO<br />
USATO<br />
Affidabile end-to-end (max 2 ritrasmissioni)<br />
TOPOLOGIA DELLA RETE Non previsto uso <strong>di</strong> cluster<br />
Tabella 4-2: Caratteristiche della simulazione n°2<br />
91
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
base della seconda simulazione). Lo sviluppo della applicazione ha ricalcato<br />
l’approccio descritto nel paragrafo 9 e in figura 4.6 viene riportato uno<br />
stralcio della procedura seguita dal nodo sink per assicurarsi <strong>di</strong> ricevere le<br />
misurazioni dai no<strong>di</strong> sensori.<br />
Come si può intuire scatta un controllo del livello <strong>di</strong> copertura (riquadro 1)<br />
che mira ad in<strong>di</strong>viduare i no<strong>di</strong> che non sono stati in grado <strong>di</strong> recapitare le<br />
loro informazioni al nodo sink e nel caso in cui non si è ancora raggiunto il<br />
numero massimo <strong>di</strong> richieste possibili per ricercare una copertura completa<br />
della rete (riquadro 2) si provvede ad una nuova richiesta <strong>di</strong> misurazione. Il<br />
protocollo opera secondo uno schema <strong>di</strong> ritrasmissione end-to-end ma è<br />
attivato solo nel momento in cui il nodo sink si accorge <strong>di</strong> non avere a<br />
<strong>di</strong>sposizione misurazioni provenienti da determinati no<strong>di</strong> sensori; la<br />
event result_t TimerControlCoverage.fired() {<br />
…//<strong>di</strong>chiarazioni iniziali omissis<br />
//controllo livello <strong>di</strong> copertura<br />
for(i=1;iunavailable_mote[i]=FALSE;<br />
if(!measure_coverage[i]){ //compongo la nuova richiesta<br />
payload_cov->unavailable_mote[i]=TRUE; must_send=TRUE; }<br />
}<br />
//significa che ho trovato cluster non coperti dalla misurazione<br />
if(must_send && max_request_coveragevalue=SpecificMeasure; count_msg++;<br />
if(count_msg==0xFFFF) count_msg=1;<br />
payload_cov->count = count_msg;<br />
if(call SendMeasureMsg.send(TOS_BCAST_ADDR, sizeof(Measure_Msg),<br />
&message)!=SUCCESS)<br />
dbg(DBG_TEMP, "FALLITO\n"); }<br />
elseif(must_send&&max_request_coverage>=NRO_MAX_REQUEST_COVERAGE)<br />
{FailedCoverage++; max_request_coverage=0; }<br />
else if(!must_send)<br />
{max_request_coverage=0; }<br />
return SUCCESS;<br />
}<br />
Figura 4.6: Stralcio procedura seguita dal nodo sink per assicurarsi la ricezione<br />
delle misurazioni da parte dei no<strong>di</strong> sensori<br />
92<br />
1<br />
2<br />
3
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 4.7: Confronto percentuali copertura con uso<br />
protocollo affidabile e non affidabile.<br />
richiesta viene inoltrata in broadcast però è <strong>di</strong>retta ai soli no<strong>di</strong> che avevano<br />
fallito l’invio nel corrente ciclo <strong>di</strong> misurazione (<strong>di</strong>scriminati con un campo<br />
nel messaggio inviato). Il riquadro 3 invece mostra il caso in cui si<br />
raggiunge il numero massimo <strong>di</strong> richieste per sod<strong>di</strong>sfare la copertura e<br />
quin<strong>di</strong> si provvede a rinunciare al tentativo <strong>di</strong> raggiungere il nodo. Questo<br />
ultimo caso risulta importante in quanto può capitare che un determinato<br />
sensore si ritrovi ad essere isolato o abbia esaurito le proprie risorse<br />
energetiche, una tale situazione non deve quin<strong>di</strong> impe<strong>di</strong>re al nodo sink <strong>di</strong><br />
continuare con la raccolta <strong>di</strong> informazioni dagli altri no<strong>di</strong>.<br />
Concentrandoci sui risultati ottenuti (figura 4.7), un approccio <strong>di</strong> questo<br />
tipo, evidenzia un netto miglioramento sulla percentuale <strong>di</strong> copertura, anche<br />
portando in conto l’utilizzo della plugin Tinysan, infatti sia con una rete<br />
composta da 9 no<strong>di</strong> sensori che da 12 no<strong>di</strong> sensori si ottiene sempre, in ogni<br />
ciclo <strong>di</strong> misurazione, una copertura completa della zona monitorata. Questo<br />
risulta essere già un buon risultato e mette in evidenzia come le possibili<br />
per<strong>di</strong>te <strong>di</strong> pacchetto dovute o a collisioni o a errori sul canale trasmissivo<br />
93
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 4.8 : Andamento della vita me<strong>di</strong>a dei singoli sensori nel caso <strong>di</strong><br />
utilizzo <strong>di</strong> un protocollo <strong>di</strong> comunicazione affidabile<br />
confrontato con il caso <strong>di</strong> utilizzo <strong>di</strong> un protocollo <strong>di</strong> tipo<br />
best-effort<br />
sono ben recuperate con l’approccio proposto anche nel caso in cui si<br />
prevedono solo un NRO_MAX_REQUEST_COVERAGE (ovvero numero <strong>di</strong><br />
richieste <strong>di</strong> ritrasmissione) pari a 2.<br />
Passando ora a considerare il punto <strong>di</strong> vista energetico risulta chiaro che<br />
abbiamo un peggioramento e ciò è dovuto all’overhead in seguito alla<br />
ritrasmissione dei messaggi contenenti le misurazioni stesse. In figura 4.8<br />
viene mostrato l’andamento della vita me<strong>di</strong>a dei singoli sensori facenti parte<br />
della rete messi a confronto a seconda che sia previsto l’utilizzo <strong>di</strong> un<br />
protocollo <strong>di</strong> recapito delle misurazioni affidabile o meno. In figura 4.9 vi è<br />
Figura 4.9: Confronto consumo energetico dei singoli no<strong>di</strong><br />
94
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
un analogo confronto però basato sul consumo me<strong>di</strong>o <strong>di</strong> energia dei sensori<br />
espresso in mJ/sec. I risultati della simulazione (rete composta da 9 no<strong>di</strong>)<br />
hanno evidenziato un lieve peggioramento (0.0015 % caso peggiore)della<br />
vita me<strong>di</strong>a dei sensori nel caso in cui venga utilizzato un protocollo basato<br />
su ritrasmissioni end-to-end. Questo risultato è dovuto al fatto che per il<br />
recupero delle misurazioni non pervenute sono risultati necessari l’inoltro <strong>di</strong><br />
rispettivamente 30 nuove richieste <strong>di</strong> misurazioni da parte del nodo sink a<br />
cui sono corrisposte un totale <strong>di</strong> 45 nuove ritrasmissioni <strong>di</strong> pacchetti<br />
contenenti le informazioni monitorate. Il fatto <strong>di</strong> avere un numero maggiore<br />
<strong>di</strong> ritrasmissioni rispetto alle richieste effettuate è dovuto alla necessità <strong>di</strong><br />
più tentare più volte <strong>di</strong> raggiungere la copertura totale dell’area monitorata.<br />
4.4 DATA GATHERING CON CLUSTER<br />
Gli stu<strong>di</strong> esposti nel paragrafo 3.5 e il relativo approccio proposto nel<br />
paragrafo 3.6 hanno messo in evidenzia come il concetto <strong>di</strong> clustering <strong>di</strong> una<br />
rete <strong>di</strong> sensori possa favorire una migliore gestione delle risorse energetiche<br />
dei no<strong>di</strong>. risulta quin<strong>di</strong> interessante instrumentare una nuova simulazione le<br />
cui caratteristiche principali sono esplicitate in tabella 4.3. Consideriamo<br />
una rete <strong>di</strong> sensori organizzata in 3 cluster: A,B,C (figura 4.10), in cui ogni<br />
cluster elegge ogni ELECTION_TIMER_RATE un leader (cluster-head)<br />
che si fa carico <strong>di</strong> rispondere alle richieste <strong>di</strong> misurazioni effettuate dal nodo<br />
sink. Nel caso proposto i cluster heads iniziali sono i no<strong>di</strong> 1,4,7<br />
rispettivamente per i 3 cluster in considerazione.<br />
NOME PROGETTO Cluster_Base_Data_Gathering<br />
OBIETTIVI Il nodo con ID 0 è incaricato della raccolta<br />
dati da tutti gli altri sensori nella rete.<br />
PROTOCOLLO DI TRASPORTO<br />
USATO<br />
Best-effort<br />
TOPOLOGIA DELLA RETE Uso <strong>di</strong> cluster<br />
Tabella 4-3: Caratteristiche della simulazione n°3 con rete organizzata in<br />
cluster<br />
95
Figura 4.10: Rete organizzata in cluster<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
La procedura <strong>di</strong> elezione <strong>di</strong> un nuovo leader, come abbiamo accennato,<br />
avviene con un rate prefissato e viene iniziata dal nodo che riveste al tempo<br />
dell’elezione il ruolo <strong>di</strong> leader del cluster. Più in particolare esso provvede a<br />
scegliere con la procedura SceltaMaster() il successivo leader e poi si<br />
interessa <strong>di</strong> comunicare ad esso che è stato eletto. La procedura <strong>di</strong> invio <strong>di</strong><br />
un messaggio al successivo master è illustrata in figura 4.11. Analizzando<br />
essa in dettaglio si può notare che il nodo sensore che è cluster-head,<br />
compone un Master_msg e lo invia al nodo designato ad essere il nuovo<br />
cluster head (riquadro 1); contemporaneamente attiva un timer per l’attesa<br />
<strong>di</strong> un ack da parte del sensore contattato, al fine <strong>di</strong> garantire che il nodo è<br />
stato effettivamente eletto. Infatti si potrebbe verificare che il nodo da<br />
eleggere leader sia temporaneamente non raggiungibile tramite<br />
96
}<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
task void SendMasterMessage()<br />
{Master_Msg * payload; payload = (Master_Msg *)master_message.data;<br />
payload->becomeMaster =TRUE; payload->id actual master=TOS LOCAL ADDRESS;<br />
if(NroSen<strong>di</strong>ngnext_master=designed_address; atomic rcv_ack=FALSE;<br />
//mando messaggio a nuovo master<br />
if(call SendMasterMsg.send(designed_address, sizeof(Master_Msg),<br />
&master_message)!=FAIL)<br />
{NroSen<strong>di</strong>ng++;<br />
//Attivo timer e aspetto ack PER 5SEC (ack timer).<br />
call TimerAck.start(TIMER_ONE_SHOT, ACK_TIMER); }<br />
else { NroSen<strong>di</strong>ng++; post SendMasterMessage();}<br />
}<br />
else<br />
{dbg(DBG_TEMP,"Rimango master - %d -\n",TOS_LOCAL_ADDRESS);<br />
NroSen<strong>di</strong>ng=0; Risveglio=NroAck;<br />
dbg(DBG_TEMP, "IMCLUSTERHEAD\n"); }<br />
2<br />
Figura 4.11: Procedura <strong>di</strong> invio <strong>di</strong> un messaggio Master<br />
comunicazione ra<strong>di</strong>o, oppure che esso abbia esaurito le sue riserve<br />
energetiche e quin<strong>di</strong> non sia eleggibile. In questo caso si prevede che, dopo<br />
un NRO_MAX_SENDING (riquadro 2), il nodo opti per rimanere cluster-<br />
head. (chiaramente questa procedura può essere variata e più in dettaglio si<br />
può prevedere che si contatti il nodo successivo nell’anello logico formato<br />
dai no<strong>di</strong> sensori appartenenti allo stesso cluster). Riguardo le azioni svolte<br />
dai no<strong>di</strong> che ricevono un messaggio <strong>di</strong> elezione queste sono esplicitate in<br />
figura 4.12. Lo scenario banale prevede che i no<strong>di</strong> che ricevono un<br />
messaggio master_msg compongano un messaggio <strong>di</strong> ack e lo inviano al<br />
vecchio leader. Nel caso in cui si verifichi una per<strong>di</strong>ta <strong>di</strong> un messaggio <strong>di</strong><br />
ack (riquadro 2) l’evento viene isolato e gestito facilmente in quanto il nodo<br />
si sarà già settato a master e quin<strong>di</strong> la ricezione <strong>di</strong> un nuovo messaggio<br />
97<br />
1
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
event TOS_MsgPtr ReceiveMasterMsg.receive(TOS_MsgPtr receivedMessage) {<br />
//cioe' se si è attivato il timer per partecipare a una nuova elezione<br />
if(!sleep)<br />
{…<strong>di</strong>chiarazioni iniziali omissis…<br />
if(!master)<br />
{if(payload->next_master==TOS_LOCAL_ADDRESS)<br />
{if(payload->becomeMaster)<br />
{ack->source_address=TOS_LOCAL_ADDRESS;<br />
ack->dest_address=payload->id_actual_master;<br />
actual_master=payload->id_actual_master;<br />
if(call SendAck.send(TOS_BCAST_ADDR,<br />
sizeof(Ack_Msg),&ack_message)==SUCCESS)<br />
{ NroAck++; atomic master=TRUE; atomic rcv_ack=FALSE;<br />
call Election_Control.Remove_election_phase();<br />
call Election_Control.Set_master();<br />
dbg(DBG_TEMP, "IMCLUSTERHEAD\n");<br />
}<br />
}}}<br />
// per<strong>di</strong>ta <strong>di</strong> un ack significa che mi ero settato master e il mio ack si è perso<br />
else {ack->retrasmission=TRUE;<br />
call SendAck.send(TOS_BCAST_ADDR, sizeof(Ack_Msg),&ack_message );<br />
}}<br />
Figura 4.12: Procedura seguita dai no<strong>di</strong> alla ricezione <strong>di</strong> un master_msg<br />
master_msg sarà segno <strong>di</strong> una trasmissione non andata a buon fine.<br />
Passiamo ora ad analizzare i risultati che sono stati ottenuti con l’utilizzo <strong>di</strong><br />
una rete organizzata in cluster. In figura 4.13 sono mostrati i risultati, in<br />
termini <strong>di</strong> copertura, ottenuta per una simulazione su una rete che faccia uso<br />
<strong>di</strong> uno schema clusterizzato e <strong>di</strong> uno schema non clusterizzato nel caso<br />
siano utilizzati 9 no<strong>di</strong> sensori e non si faccia uso <strong>di</strong> un protocollo affidabile<br />
per il recapito delle misurazioni al nodo sink. Come si può notare la<br />
percentuale <strong>di</strong> cicli <strong>di</strong> misurazioni che hanno ottenuto una copertura totale<br />
della rete è più elevato rispetto alla analoga simulazione del paragrafo 4.3.<br />
Del resto il risultato è ovvio visto che avendo un solo sensore attivo per<br />
cluster <strong>di</strong>minuisce la probabilità <strong>di</strong> collisioni nella consegna delle<br />
informazioni monitorate (a causa della congestione della rete).<br />
98<br />
1<br />
2
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
Figura 4.13: Confronto copertura con uso protocollo<br />
affidabile e non affidabile<br />
Dal punto <strong>di</strong> vista energetico, invece il guadagno che si ottiene con l’uso <strong>di</strong><br />
una rete organizzata in cluster risulta abbastanza evidente (ve<strong>di</strong> figura 4.14).<br />
Del resto ciò risulta abbastanza intuitivo in quanto il carico dei no<strong>di</strong> sarà ora<br />
<strong>di</strong>stribuito nel tempo su tutti i no<strong>di</strong> appartenenti allo stesso cluster<br />
implementando così una strategia <strong>di</strong> load balancing. Dal grafico si nota<br />
come la vita me<strong>di</strong>a dei sensori in una rete organizzata in cluster sia<br />
Figura 4.14: Guadagno energetico con rete organizzata in cluster<br />
99
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
aumentata; l’aumento è <strong>di</strong> circa il 7% nel caso in cui si prevede un numero<br />
<strong>di</strong>spositivi per cluster pari a 2 (cluster C <strong>di</strong>spositivi 7 e 8) e arriva ad un 9%<br />
se si prevede l’utilizzo <strong>di</strong> 3 no<strong>di</strong> sensori per cluster. L’incremento <strong>di</strong><br />
autonomia della rete continua a crescere se si prevede un utilizzo <strong>di</strong> cluster<br />
abbastanza numerosi e si è potuto riscontrare che con l’uso <strong>di</strong> un numero <strong>di</strong><br />
7 <strong>di</strong>spositivi per cluster si arriva ad una vita me<strong>di</strong>a stimata per i sensori <strong>di</strong><br />
circa 260 h raggiungendo quin<strong>di</strong> un incremento rispetto alla rete non<br />
organizzata in cluster <strong>di</strong> circa il 13%. Il risultato risulta interessante in<br />
quando adottando strategie <strong>di</strong> questo tipo si possono ottenere architetture <strong>di</strong><br />
monitoraggio che riescano a sod<strong>di</strong>sfare vincoli stringenti relativi alla durata<br />
della rete.<br />
4.5 DATA GATHERING CON CLUSTERING E<br />
PROTOCOLLO AFFIDABILE<br />
Fino ad ora abbiamo effettuato una analisi che ha messo in evidenzia come<br />
l’utilizzo <strong>di</strong> reti organizzate in cluster porti miglioramenti all’incremento<br />
della vita me<strong>di</strong>a dei singoli no<strong>di</strong>, ora non ci resta che analizzare così come<br />
fatto nel paragrafo 4.3, le performance <strong>di</strong> una rete nel momento in cui si<br />
introduce il concetto <strong>di</strong> affidabilità nei confronti del recapito delle<br />
misurazioni; le caratteristiche principali <strong>di</strong> questa nuova simulazione sono<br />
esposte in tabella 4.4. I risultati che sono emersi hanno evidenziato un<br />
NOME PROGETTO Reliable_Cluster_Base_Data_Gathering<br />
OBIETTIVI Il nodo con ID 0 è incaricato della raccolta<br />
dati da tutti gli altri sensori nella rete.<br />
PROTOCOLLO DI TRASPORTO<br />
USATO<br />
Affidabile end-to-end (max 2 ritrasmissioni)<br />
TOPOLOGIA DELLA RETE Previsto uso <strong>di</strong> cluster<br />
Tabella 4-4: Caratteristiche della simulazione n°4 con rete organizzata in<br />
cluster e uso protocollo <strong>di</strong> recapito affidabile<br />
100
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
peggioramento, come è lecito aspettarsi, per quanto riguarda la vita me<strong>di</strong>a<br />
dei singoli no<strong>di</strong> causato sempre dalla maggior quantità <strong>di</strong> energia che è<br />
spesa per le ritrasmissioni necessarie al recupero <strong>di</strong> eventuali fallimenti nel<br />
recapito dei pacchetti. Anche in questo caso, così come riscontrato nella<br />
simulazione esposta nel paragrafo 4.3 il protocollo end to end si mostra<br />
essere molto leggero introducendo un decremento della vita me<strong>di</strong>a dei<br />
singoli sensori molto trascurabile a testimonianza del fatto che la sua<br />
attivazione solo nei momenti in cui abbiamo per<strong>di</strong>te è un buon approccio<br />
per ovviare ai problemi relativi alla congestione della rete e alla scarsa<br />
qualità dei singoli link <strong>di</strong> comunicazione. Per avere una analisi completa dei<br />
protocolli <strong>di</strong>scussi nei paragrafi precedenti, in figura 4.15 è riportato, una<br />
comparazione tra le vite me<strong>di</strong>e dei vari <strong>di</strong>spositivi in base alla topologia <strong>di</strong><br />
rete utilizzata e allo schema adottato per la ricezione delle informazioni<br />
presso il nodo sink. Il risultato ottenuto risulta essere abbastanza intuitivo,<br />
infatti come si può notare la vita me<strong>di</strong>a per i <strong>di</strong>spositivi più elevata, a cui<br />
corrisponde quin<strong>di</strong> un <strong>di</strong>spen<strong>di</strong>o energetico me<strong>di</strong>o più basso, è stata<br />
riscontrata nella simulazione con una rete organizzata in cluster. Il<br />
peggioramento nel caso in cui la topologia della rete non sia organizzata in<br />
Figura 4.15: Analisi comparativa <strong>degli</strong> algoritmi<br />
101
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
cluster è abbastanza accentuata soprattutto nei riguar<strong>di</strong> della simulazione<br />
riportata nel paragrafo 4.3. Di conseguenza possiamo affermare che<br />
l’utilizzo <strong>di</strong> una strategia che vede l’organizzazione in cluster della rete<br />
comporta comunque una miglioria per quanto riguarda la durata me<strong>di</strong>a della<br />
vita della rete. Fino ad ora gli approcci che sono stati presentati relativi al<br />
clustering sono stati tutti incentrati sull’uso <strong>di</strong> un meccanismo <strong>di</strong> elezione<br />
che andava attivato ogni ELECTION_TIMER_RATE. Un interessante<br />
scenario da valutare è quello in cui l’elezione del leader sia effettuata solo<br />
nel momento in cui il <strong>di</strong>spositivo sensore che funge da leader esaurisce la<br />
propria carica energetica. L’obiettivo <strong>di</strong> instrumentare una simulazione <strong>di</strong><br />
questo genere è volta ad in<strong>di</strong>viduare se può essere più conveniente, per la<br />
vita me<strong>di</strong>a <strong>di</strong> una rete, portare all’esaurimento i no<strong>di</strong> che sono stati designati<br />
a leader del cluster e quin<strong>di</strong> ridurre in questo caso al minimo le procedure<br />
stesse <strong>di</strong> elezione. Da una analisi dei risultati in figura 4.16 si può<br />
concludere che i no<strong>di</strong> che sono stati designati ad essere leader fin quando<br />
possibile risultano avere una vita me<strong>di</strong>a stimata inferiore <strong>di</strong> circa 20h,<br />
mentre gli altri no<strong>di</strong> registrano un aumento <strong>di</strong> 10h <strong>di</strong> autonomia. Ciò<br />
significa che, detto con ci il tempo <strong>di</strong> esaurimento del nodo i-esimo, al lordo<br />
della procedura <strong>di</strong> elezione, al tempo c1=c4=c7 (~230 h) i no<strong>di</strong> capo cluster<br />
Figura 4.16: Elezione eseguita ciclicamente o all’esaurimento<br />
energetico <strong>di</strong> un nodo<br />
102
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
saranno esauriti e i restanti no<strong>di</strong> che fino a quell’istante avevano fornito una<br />
funzionalità semplicemente <strong>di</strong> forwar<strong>di</strong>ng dei pacchetti, avranno una<br />
autonomia residua pari a c2-c1 (~30 h). A questo punto bisognerebbe<br />
calcolare quante ore <strong>di</strong> autonomia resterebbero ai nuovi cluster head, ma il<br />
calcolo <strong>di</strong> tale autonomia non è permesso dalla plugin in maniera analitica.<br />
Dal punto <strong>di</strong> vista intuitivo però si dovrebbe riscontrare effettivamente un<br />
guadagno, in quanto avremo una procedura <strong>di</strong> elezione che verrà attivata<br />
solo nel momento in cui si sarà esaurita la riserva energetica <strong>di</strong> un nodo.<br />
Facciamo però notare che una procedura <strong>di</strong> questo genere prevede che il<br />
nodo sink si accorga della “morte” <strong>di</strong> un nodo solo quando ormai la<br />
procedura <strong>di</strong> misurazione è stata lanciata; ciò quin<strong>di</strong> causa una per<strong>di</strong>ta <strong>di</strong><br />
informazione non rime<strong>di</strong>abile. È chiaro che potrebbero essere sviluppate<br />
procedure che mirino a indagare sullo “stato <strong>di</strong> salute” in termini energetici<br />
dei singoli no<strong>di</strong>, ma operazioni <strong>di</strong> questo tipo porterebbero ad un consumo<br />
energetico aggiuntivo per il recapito <strong>di</strong> queste informazioni al nodo sink.<br />
4.6 OVERLAY NETWORK<br />
Tutte le simulazioni che sono state condotte nei paragrafi precedenti hanno<br />
portato a risultati, in termini <strong>di</strong> energia me<strong>di</strong>a <strong>di</strong>ssipata dai vari no<strong>di</strong> (quin<strong>di</strong><br />
vita stimata residua), che <strong>di</strong>pendono fortemente:<br />
1. dall’uso del protocollo multihop<br />
2. dal ruolo dei no<strong>di</strong> che non rivestono il ruolo <strong>di</strong> leader del cluster.<br />
Relativamente al punto 2 un <strong>di</strong>spositivo sensore in ogni istante funge<br />
comunque da nodo forwarder dei pacchetti al fine <strong>di</strong> poter contribuire al<br />
recapito delle informazioni al nodo sink e un siffatto funzionamento,<br />
comporta quin<strong>di</strong> la necessità che il modulo ra<strong>di</strong>o <strong>di</strong> ogni sensore sia sempre<br />
attivo, causando un <strong>di</strong>spen<strong>di</strong>o energetico che influisce fortemente sulla vita<br />
totale della rete.<br />
103
Figura 4.17: Overlay Network<br />
Da queste osservazioni se ci poniamo nelle ipo<strong>tesi</strong>:<br />
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
� che i <strong>di</strong>spositivi possano essere programmati per non partecipare<br />
continuamente al protocollo multihop e che possano effettuare una<br />
operazione <strong>di</strong> join al protocollo solo nel momento in cui rivestono il<br />
ruolo <strong>di</strong> leader del cluster;<br />
� che i <strong>di</strong>spositivi non leader possano essere in uno stato <strong>di</strong> power save<br />
e provvedano all’accensione del modulo ra<strong>di</strong>o solo in alcuni<br />
intervalli <strong>di</strong> tempo;<br />
� che il grafo dei collegamenti tra i no<strong>di</strong> sensori sia fortemente<br />
connesso;<br />
allora la soluzione che prevede la costruzione <strong>di</strong> una overlay network (figura<br />
4.17) potrà portare significativi vantaggi dal punto <strong>di</strong> vista dell’incremento<br />
della vita della rete. Infatti, anche se in questo caso abbiamo una limitazione<br />
dal punto <strong>di</strong> vista topologico, i vari sensori che non sono leader sono in uno<br />
stato risparmi energetico e quin<strong>di</strong> non consumeranno risorse energetiche<br />
104
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
dovute al mantenimento del modulo ra<strong>di</strong>o acceso e all’inoltro dei vari<br />
pacchetti. Di conseguenza lo scenario che si presenta è quello <strong>di</strong> una rete in<br />
cui gli unici no<strong>di</strong> che sono coinvolti in procedure <strong>di</strong> inoltro <strong>di</strong> misurazioni<br />
sono i leader <strong>di</strong> ogni cluster, mentre gli altri sono dormienti. In tale<br />
con<strong>di</strong>zione quin<strong>di</strong> otterremo globalmente un risparmio energetico ingente<br />
grazie allo stato sleep del modulo ra<strong>di</strong>o. Questa assunzione, del resto, è<br />
giustificata anche analiticamente dai risultati ottenuti dalla simulazione sulla<br />
vita me<strong>di</strong>a <strong>di</strong> un sensore (figura 4.18) che hanno mostrato un netto<br />
abbattimento dell’autonomia dei <strong>di</strong>spositivi nel caso in cui sia previsto<br />
l’utilizzo del modulo ra<strong>di</strong>o per la trasmissione <strong>di</strong> misurazioni. Volendo<br />
quin<strong>di</strong> stimare la vita me<strong>di</strong>a della rete potremmo <strong>di</strong>re che nel caso in cui<br />
consideriamo tutti cluster formati da n <strong>di</strong>spositivi:<br />
lifetime _ cluster _ head + ( n −1)<br />
* lifetime _ no _ ra<strong>di</strong>o<br />
vitame<strong>di</strong>a =<br />
n<br />
Dove lifetime_cluster_head rappresenta l’autonomia del sensore nel<br />
momento in cui è attivo il modulo ra<strong>di</strong>o, mentre lifetime_no_ra<strong>di</strong>o è<br />
l’autonomia del sensore nel momento in cui non è attivo il modulo ra<strong>di</strong>o.<br />
Infatti nel caso in cui si considera una rete organizzata in cluster ciascuno<br />
composto da n=3 no<strong>di</strong> sensori, la formazione <strong>di</strong> overlay network implicherà<br />
vita me<strong>di</strong>a stimata [h]<br />
Impatto del modulo ra<strong>di</strong>o sulla vita me<strong>di</strong>a <strong>di</strong> un<br />
sensore<br />
700,00<br />
600,00<br />
500,00<br />
400,00<br />
300,00<br />
200,00<br />
100,00<br />
0,00<br />
modulo ra<strong>di</strong>o attivo<br />
modulo ra<strong>di</strong>o spento<br />
Figura 4.18: Impatto del modulo ra<strong>di</strong>o sulla vita <strong>di</strong><br />
un sensore<br />
105
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
che ogni nodo sensore sia con il modulo ra<strong>di</strong>o acceso per 1/3 della sua vita e<br />
per i 2/3 spento. Ciò implica che essendo lifetime_cluster_head=249h e<br />
lifetime_no_ra<strong>di</strong>o=658h allora avremo una vita me<strong>di</strong>a stimata che si attesta<br />
sulle 521h che risulta essere più del doppio della stima nel caso in cui non si<br />
ricorra allo spegnimento del modulo ra<strong>di</strong>o.<br />
In conclusione l’idea <strong>di</strong> creare una overlay network e <strong>di</strong> mo<strong>di</strong>ficare il<br />
protocollo multihop in modo tale da costruire nuove tabelle <strong>di</strong> routing ogni<br />
volta che si ha un cambiamento dei leader del cluster risulta essere una<br />
buona prospettiva per lo sviluppo <strong>di</strong> reti <strong>di</strong> sensori con particolari esigenze<br />
<strong>di</strong> longevità.<br />
106
Conclusioni<br />
Il presente lavoro <strong>di</strong> <strong>tesi</strong> nasce dall’esigenza <strong>di</strong> riuscire ad ottenere<br />
architetture <strong>di</strong> reti <strong>di</strong> sensori senza cavo con particolari esigenze <strong>di</strong><br />
affidabilità nella consegna delle misurazioni e minimizzazione del consumo<br />
energetico dei stessi sensori. Essendo i due requisiti in contrasto tra loro è<br />
necessario valutare se può essere in<strong>di</strong>viduata per via sperimentale una<br />
soluzione <strong>di</strong> compromesso (trade- off).<br />
Dopo uno stu<strong>di</strong>o attento della letteratura in merito ai protocolli <strong>di</strong><br />
clusterizzazione e <strong>di</strong> consegna affidabile delle misurazioni, si è proposto un<br />
nuovo modo <strong>di</strong> intendere il ruolo <strong>di</strong> leader del cluster, non più delegato a<br />
gateway tra i no<strong>di</strong> sensori del cluster e il nodo sink, bensì come l’unica<br />
entità incaricata dell’azione <strong>di</strong> monitoraggio della grandezza fisica relativa<br />
all’evento che si vuole analizzare. Attraverso poi delle strategie <strong>di</strong> leader<br />
election perio<strong>di</strong>co all’interno <strong>di</strong> ogni cluster è stato possibile implementare<br />
load balancing al fine <strong>di</strong> ottenere un consumo energetico uniforme e<br />
garantire quin<strong>di</strong> una ripartizione del carico tra i vari sensori afferenti ai<br />
cluster.<br />
I risultati sperimentali, ottenuti con l’ausilio del simulatore ad eventi <strong>di</strong>screti<br />
TOSSIM, hanno mostrato un guadagno <strong>di</strong> circa il 9% nella autonomia dei<br />
no<strong>di</strong> sensori nel caso in cui si prevedano cluster con solo 3 <strong>di</strong>spositivi<br />
(risulta chiaro che all’aumentare del numero <strong>di</strong> <strong>di</strong>spositivi previsti per<br />
cluster aumenterà anche il guadagno dal punto <strong>di</strong> vista energetico e quin<strong>di</strong><br />
l’autonomia della rete). Riguardo la consegna affidabile i risultati hanno<br />
107
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
evidenziato che, una strategia che preveda il recupero delle misurazioni,<br />
basato su richieste <strong>di</strong> trasmissioni che vengono inoltrate dal nodo sink solo<br />
in caso <strong>di</strong> reale per<strong>di</strong>ta, è una buona soluzione <strong>di</strong> trade off tra recapito <strong>di</strong> una<br />
definita quantità <strong>di</strong> informazione sull’evento monitorato e minimizzazione<br />
dei consumi energetici dei no<strong>di</strong> sensori. Infatti l’impatto sulla vita <strong>di</strong> un<br />
siffatto protocollo è risultato essere molto basso.<br />
In seguito all’utilizzo <strong>di</strong> TOSSIM, non è stato possibile indagare in maniera<br />
sistematica e precisa sul guadagno che si otterrebbe se i no<strong>di</strong> sensori che<br />
non fungono da cluster-head fossero completamente spenti. Questa strategia<br />
prevede vincoli dal punto <strong>di</strong> vista topologico (è necessario che il grafo<br />
formato dai no<strong>di</strong> sensori sia fortemente connesso pena la non raggiungibilità<br />
delle misurazioni rilevate al nodo sink) ma da una semplice analisi emerge<br />
che potrebbe portare ad un raddoppio della vita me<strong>di</strong>a <strong>di</strong> una rete, quin<strong>di</strong><br />
sarebbe molto interessante investigare su questo punto in quanto<br />
permetterebbe la realizzazione <strong>di</strong> reti <strong>di</strong> sensori con particolari esigenze <strong>di</strong><br />
longevità.<br />
108
Bibliografia<br />
[1] M. Cinque, D. Cotroneo, G. De Caro, and M. Pelella. Reliability requirements of<br />
wireless sensor networks for dynamic structural monitoring. International<br />
Conference on Dependable Systems and Networks (DSN),2006.<br />
[2] C. Perkins, Ad Hoc Networks, Ad<strong>di</strong>son-Wesley, Rea<strong>di</strong>ng, MA, 2000.<br />
[3] I.F.Akyil<strong>di</strong>z, W.Su, Y.Sankarasubramaniam and E.Cayirci, A Survery on Sensor<br />
Networks, IEEE Communications Magazine, August 2002, pages 102-114, 393-442<br />
[4] A. Y. Wang, S. H. Cho, C. G. So<strong>di</strong>ni, and A. P. MAC for Asymmetric RF<br />
Microsensor Systems. In Intl. Symp. on Low Power Electronics and Chandrakasan.<br />
Energy Efficient Modulation and Design, August 2001.<br />
[5] C. Schurgers, O. Aberthorne, and M. B. Srivastava. Modulation Scaling for Energy<br />
Aware Communication System In Intl. Symp. on Low Power Electronics and Design,<br />
August 2001.<br />
[6] Wei Ye, John Heidemann, Me<strong>di</strong>um Access Control in Wireless Sensor Networks,<br />
USC/ISI TECHNICAL REPORT ISI-TR-580, October 2003<br />
[7] Brad Karp and H. T. Kung. Gpsr: greedy perimeter stateless routing for wireless<br />
networks. In MobiCom ’00: Procee<strong>di</strong>ngs of the 6th annual international conference<br />
on Mobile computing and networking, pages 243–254, New York, NY, USA, 2000.<br />
ACM Press.<br />
[8] Devika Subramanian, Peter Druschel, and Johnny Chen. Ants and reinforcement<br />
learning: A case study in routing in dynamic networks. In IJCAI (2), 1997.<br />
[10] W. R. Heinzelman, A. Chandrakasan, and H. Balakrishnan, Energy - efficient<br />
communication protocol for wireless microsensor networks, Proc. 33rd Hawaii Int'l.<br />
Conf. Sys. Sci.,pp. 3005- 3014, Jan.2000.<br />
[11] Konstantinos Kalpakis, Koustuv Dasgupta and Parag Namjoshi Efficient algorithms<br />
for maximum lifetime data gathering and aggregation in wireless sensor networks<br />
,2002.<br />
[12] Supriyo Chatterjea and Paul Havinga A Dynamic Data Aggregation Scheme for<br />
Wireless Sensor Networks.<br />
[13] R. Nowak. Distributed EM algorithms for density estimation and clustering in<br />
sensor networks. IEEE Trans. on Sig. Proc., 51(8), August 2003.<br />
[14] http://www.alertsystems.org.<br />
109
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
[15] A. Cerpa, J. Elson, M. Hamilton, J. Zhao, Habitat monitoring: application driver for<br />
wireless communications technology, ACM SIGCOMM'2000, Costa Rica, April<br />
2001.<br />
[16] http://www.greatduckisland.net/<br />
[17] G. R. Polastre, “Design and Implementation of Wireless Sensor Networks for<br />
Habitat Monitoring ”, Master <strong>di</strong>ssertation, Dept. of Elec. Eng., UCB, Spring 2003.<br />
[18] N. Noury, T. Herve, V. Rialle, G. Virone, E. Mercier, G. Morey, A. Moro, T.<br />
Porcheron, Monitoring behavior in home using a smart fall sensor, IEEE-EMBS<br />
Special Topic Conference on Microtechnologies in Me<strong>di</strong>cine and Biology, October<br />
2000, pp. 607-610.<br />
[19] E.M. Petriu, N.D. Georganas, D.C. Petriu, D. Makrakis,V.Z. Groza, Sensor-based<br />
information appliances, IEEE Instrumentation and Measurement Magazine<br />
(December 2000) 31-35.<br />
[20] I.A. Essa, Ubiquitous sensing for smart and aware environments, IEEE Personal<br />
Communications (October 2000).<br />
[21] TinyOS: An open source operating system for WSN - www.tinyos.net.<br />
[22] R. Von Behren M. Welsh E. Brewer D. Gay, P. Levis and D. Culler. “The nesC<br />
Language: A Holistic Approach to Networked Embedded Systems”. In Procee<strong>di</strong>ngs<br />
of Programming Language Design and Implementation (PLDI) 2003, June 2003.<br />
[23] H. Abrach, J. Carlson, H. Dai, J. Rose, A. Sheth, B. Shucker, and R.Han. MANTIS:<br />
System support for multimodal networks of in-situ sensors. In Proc. 2nd ACM Intl.<br />
Workshop on Wireless Sensor Networks and Applications (WSNA), San Diego,<br />
CA, September 2003.<br />
[24] G. Ananstasi, M. Conti, A. Falchi, E. Fragori e A. Passerella: Performance<br />
Measurements of Mote Sensor networks. ACM/IEEE International Symposium on<br />
Modeling, Analysis and Simulation of Wireless and Mobile System, pp. 174-181,<br />
ACM Press, 2004.<br />
[25] D. D. Clark and D. L. Tennenhouse. Architectural Considerations for a New<br />
Generation of Protocols. In Procee<strong>di</strong>ngs of SIGCOMM, September 1990.<br />
[26] Philip Levis and Nelson Lee. TOSSIM: A simulator for TinyOS networks, November<br />
14 2003.<br />
[27] Philip Levis, Nelson Lee, MattWelsh, and David E. Culler. TOSSIM: accurate and<br />
scalable simulation of entire TinyOS applications. In SenSys, pages 126–137, 2003.<br />
[28] Alan Mainwaring, Joseph Polastre, Robert Szewczyk, David Culler, and John<br />
Anderson. Wireless sensor networks for habitat monitoring.<br />
110
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
[29] J. Elson, S. Bien, N. Busek, V. Bychkovskiy, A. Cerpa, D. Ganesan, L. Girod, B.<br />
Greenstein, T. Schoellhammer, T. Stathopoulos, D. Estrin, 2003 “Emstar: an<br />
environment for developing wireless embedded systems software”<br />
[30] L. Girod, J. Elson, A. Cerpa, T. Stathopoulos, Nithya Ramanathan, D. Estrin<br />
“Emstar: a software environment for developing and deploying wireless sensor<br />
networks”<br />
[31] Jonathan Polley, Dionysys Blazakis, Jonathan McGee, Dan Rusk, John S. Baras<br />
“Atemu: a fine-grained sensor network simulator”.<br />
[32] Ben L. Titzer, Daniel K. Lee, Jens Palsberg “Avrora: scalable sensor network<br />
simulation with precise timing”.<br />
[33] ISI. The network simulator 2 ns-2. http://www.isi.edu/nsnam/nsidenx.html, 2002.<br />
[34] Xiang Zeng, Rajive Bagro<strong>di</strong>a, and Mario Gerla. Glomosim: A library for parallel<br />
simulation of large-scale wireless networks. In Workshop on Parallel and<br />
Distributed Simulation, pages 154–161, 1998.<br />
[35] Y. Huang, J. Huang, L. Hester, A. Allen, O. Andric, P. Chen, and B. O’Dea. Opnet<br />
simulation of a multi-hop self-organizing wireless sensor network.<br />
[36] A. Savvides S. Park and M. B. Srivastava. Sensorsim: a simulation framework for<br />
sensor networks. In Procee<strong>di</strong>ngs of the 3rd ACM international workshop on<br />
Modeling, analysis and simulation of wireless and mobile systems, pages 104–111,<br />
Boston, MA USA.<br />
[37] Ahmed Sobeih, Wei-Peng Chen, Jennifer C. Hou, Lu-Chuan Kung, Ning Li, Hyuk<br />
Lim, Hung-Ying Tyan, Honghai Zhang “J-Sim: a simulation and emulation<br />
environment for wireless sensor networks”<br />
[38] Clau<strong>di</strong>o Basile, Zbigniew Kalbarczyk, and Ravi K. Iyer. Neutralization of errors and<br />
attacks in wireless ad hoc networks. In International Conference on Dependable<br />
Systems and Networks(DSN), 2005.<br />
[39] S. Shakkottai, R. Srikant, and N. Shroff. Unreliable sensor grids: Coverage,<br />
connectivity and <strong>di</strong>ameter. In IEEE INFOCOM2003, pages 241–250, 2003.<br />
[40] D. Bein, V. Jolly, B. Kumar, and S. Latifi. Reliability modeling in wireless sensor<br />
networks. International Journal of Information Technology, Vol. 11 No. 2, 2004.<br />
[41] Hosam M. F. AboElFotoh, S. S. Iyengar, and Krishnendu Chakrabarty. Computing<br />
reliability and message delay for cooperative wireless <strong>di</strong>stributed sensor networks<br />
subject to random failures. IEEE TRANSACTIONS ON RELIABILITY, 54(1),<br />
MARCH 2005.<br />
[42] G. Gupta and M. Younis. Fault-tolerant clustering of wireless sensor networks.<br />
IEEE, 2003.<br />
[43] Jae-Joon Lee, Bhaskar Krishnamachari, and C.-C. Jay Kuo. Impact of energy<br />
depletion and reliability on wireless sensor network connectivity, 2005.<br />
111
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
[44] S. Lindsey and C. S. Raghavendra. PEGASIS: Power-efficient gathering in sensor<br />
information systems. In Procee<strong>di</strong>ngs of the IEEE Aerospace Conference, March<br />
2002.<br />
[45] L. Subramanian and R.H. Katz, “An architecture for buil<strong>di</strong>ng self-configurable<br />
systems”, Procee<strong>di</strong>ngs of the 1st ACM international symposium on Mobile ad hoc<br />
networking and computing, pp. 63–73, Boston, MA, USA, 2000.<br />
[46] C. V. Ramamoorthy, A. Bhide, and J. Srivastava, “Reliable clustering techniques for<br />
large, mobile packet ra<strong>di</strong>o networks”, Procee<strong>di</strong>ngs of the 6 th Annual Joint<br />
Conference of the IEEE Computer and Communications Societies (INFOCOM ’87),<br />
San Francisco, CA, USA, 1:218–226, 31 March–2 April 1987.<br />
[47] R. Krishnan and D. Starobinski, Efficient clustering algorithms for self organizing<br />
wireless sensor networks,. Ad Hoc Networks, vol. 4, no. 1, pp. 36.59, January 2006.<br />
[48] Leonidas Tzevelekas, Ziviani Towards Potential-Based Clustering forWireless<br />
Sensor Networks CoNEXT’05, October 24.27, 2005, Toulouse, France.<br />
[49] Malka Halgamuge, Siddeswara Mayura Guru and Andrew Jennings; Energy efficient<br />
Cluster Formation in wireless sensor networks, International conference on<br />
telecommunications ICT 2003, IEEE Press.<br />
[50] Yuon Guo, Janise Mcnair, Cost Efficient Cluster Formation for wireless sensor<br />
networks, Proc. of CITSA 2004, Orlando, FL, July 2004.<br />
[51] Ossama Younis and Sonia Fahmy, HEED: A hybrid energy efficient, <strong>di</strong>stributed<br />
clustering apparoach for Ad-hoc sensor networks, IEEE Transactions on Mobile<br />
Computing, Oct.-Dec. 2004, Volume: 3, Issue: 4, p.p. 366 - 379.<br />
[52] G. Gupta and M. Younis, Load-Balanced Clustering in Wireless Sensor Networks,<br />
IEEE International conference on communications, Anchorage, Alaska, 2003.<br />
[53] S. Banerjee and S. Khuller, A Clustering Scheme for Hierarchical Control in Multihop<br />
Wireless Networks, INFOCOM, 2001.<br />
[54] A. Antis, R. Prakash, T. Vuong, and D. Huynh, Max-Min d-Cluster Formation in<br />
Wireless Ad Hoc Networks, IEEE INFOCOM, 2000.<br />
[55] Y. Bejerano, Efficient Integration of Multihop Wireless and Wired Networks with<br />
QoS Constraints, IEEE/ACM Transactions on Networking, 2004.<br />
[56] B. Aoun, R. Boutaba, Clustering in WSN with latency and Energy Consumption<br />
constraints, Journal of Network and Systems Management, Vol. 14, No. 3,<br />
September 2006<br />
[57] Mudasser Iqbal, Iqbal Gondal and Laurence Dooley An Energy-Aware Dynamic<br />
Clustering Algorithm for Load Balancing in Wireless Sensor Networks JOURNAL<br />
OF COMMUNICATIONS, VOL. 1, NO. 3, JUNE 2006<br />
112
Progetto e valutazione <strong>di</strong> algoritmi per la raccolta<br />
dati affidabili su reti <strong>di</strong> sensori senza cavo<br />
[58] A. Kroller, D. Pfisterer, C. Buschmann, S.P. Fekete, S. Fischer, “Shawn: A new<br />
approach to simulating wireless sensor networks”, 2005<br />
[59] http://tcs.unige.ch/doku.php/code/algosensim/overview<br />
[60] C. Mallanda, A. Suri, V. Kunchakarra, S.S. Iyengar, “Simulating wireless sensor<br />
networks with Omnet++”, 2005<br />
[61] Fred Stann and John Heidemann. RMST: Reliable Data Transport in Sensor<br />
Networks. 1st IEEE International Workshop on Sensor Net Protocols and<br />
Applications, 2003<br />
[62] C. Wan, A. Campbell, L. Krishnahmurthy. PSFQ: A Reliable Transport Mechanism<br />
for Wireless Sensor Networks. ACM International Workshop on Wireless Sensor<br />
Networks and Applications, Atlanta, Georgia, Sept 2002.<br />
[63] C. Intanagonwiwat, R. Govindan, D. Estrin, j. Heidmann and F. Silva “Direct<br />
Diffusion for wireless sensor network” IEEE/ACM Transactions on Networking,<br />
vol.11, pp 2-16, Feb 2003<br />
[64] Seung-Jong Park, Ramanuja Vedantham, Raghupathy Sivakumar and Ian F.<br />
Akyil<strong>di</strong>z A scalable approach for reliable downstream data delivery in wireless<br />
sensor networks in the Procee<strong>di</strong>ngs of ACM International Symposium on Mobile Ad<br />
hoc Networking and Computing (MOBIHOC), Japan, May 2004.<br />
[65] Chieh-Yih Wan, Shane B. Eisenman, Andrew T. Campbell, “CODA: Congestion<br />
Detection and Avoidance in Sensor Networks”, in procee<strong>di</strong>ngs of First ACM<br />
Conference on Embedded Networked Sensor Systems (SenSys 2003), November<br />
2003.<br />
[66] J.O’Rourke. Computational geometry column 15. Int’l Journal of Computational<br />
Geometry and Application, 2(2):217-217,1992.<br />
[67] Seapahn Meguer<strong>di</strong>chian, Farinaz Koushanfar, Miodrag Potkonjak, Mani B.<br />
Srivastava, Coverage Problems in Wireless Ad-hoc Sensor Networks, in IEEE<br />
INFOCOM, pages 1380-1387, 2001<br />
[68] S. Slijepcevic, M. Potkonjak, Power Efficient Organization of Wireless Sensor<br />
Networks, In IEEE Int’l Conf. on Communications (ICC) pages 472-476, 2001.<br />
[69] Tian, Georganas, A Coverage-Preserving Node Scheduling Scheme for Large<br />
Wireless Sensor Networks ACM Int’l Workshop on WSNA, 2002<br />
[70] Catello Di Martino, Valutazione dell'affidabilità <strong>di</strong> Reti <strong>di</strong> Sensori senza cavo,<br />
Università <strong>degli</strong> stu<strong>di</strong>o <strong>di</strong> <strong>Napoli</strong> <strong>Federico</strong> <strong>II</strong>, Ottobre 2005<br />
[71] Fan Ye, Gary Zhong, Jesse Cheng, Songwu Lu, Lixia Zhang PEAS: A Robust<br />
Energy Conserving Protocol for Long-lived SensorNetworks, In Int’l Conf. on<br />
Distributed Conputing System (ICDCS), 2003<br />
113