• Non ci sono risultati.

CAPITOLO IX CONCLUSIONI

N/A
N/A
Protected

Academic year: 2021

Condividi "CAPITOLO IX CONCLUSIONI"

Copied!
18
0
0

Testo completo

(1)

CAPITOLO IX

CONCLUSIONI

I numerosi vincoli che rendono una Rete di Sensori diversa dalle tradizio-nali Reti di Calcolatori determinano l’esigenza di creare una Architettura di Rete dedicata ed i relativi protocolli. Nell’ambito di questa Tesi è stata pro-gettata una Architettura che permette, tramite l’utilizzo di un approccio

cross-layered, la cooperazione tra protocolli appartenenti a layer diversi. All’interno dell’Architettura sono stati progettati e valutati tramite simula-zioni un protocollo per lo Scheduling delle comunicazioni tra Nodi Sensore ed uno per la creazione ed il mantenimento di un Albero di Routing. Tali protocolli sono stati progettati per venire in contro alle esigenze di scalabi-lità e di risparmio energetico di una Rete di Sensori. Infatti il consumo e-nergetico risulta il vincolo maggiore di una Rete di questo tipo ed in parti-colare l’attività di comunicazione è quella che influisce maggiormente sul tempo di vita di un Nodo Sensore.

Il primo protocollo permette ai nodi di una Rete di Sensori di risparmiare energia concentrando le comunicazioni con i vicini in istanti prestabiliti. Negli altri istanti ciascun nodo può essere messo nello stato di power down con conseguente risparmio dal punto di vista energetico. Tale proto-collo sfrutta la periodicità delle applicazioni di monitoring e prende in con-siderazione anche le frequenti variazioni topologiche che possono verifi-carsi in una rete di Sensori e la variabilità delle applicazioni stesse.

L’altro protocollo tiene conto del limitato raggio di comunicazione dei Nodi Sensore e quindi del fatto che una rete di Sensori è di fatto una rete multi-hop : ciascun nodo non può comunicare direttamente con il nodo Sink ma deve affidarsi ad altri nodi Router. Tale protocollo permette la creazione

(2)

IX Conclusioni Samuele Bachini

ed il mantenimento di un Albero di Routing. In questo modo si evita di ef-fettuare un flooding delle informazioni. Ogni nodo è a conoscenza del pa-dre a cui fare riferimento per le comunicazioni con il Nodo Sink e, analo-gamente, degli eventuali nodi figlio di cui si deve far carico. La costruzione di tale albero è effettuata tenendo di conto sia del numero di hop di distan-za dal nodo Sink sia del livello energetico dei nodi. Inoltre, nella costruzio-ne dell’albero di Routing si cerca di effettuare un bilanciamento del carico sui Nodi Sensore in modo da diminuire la congestione nella rete. Il proto-collo è progettato per gestire la “precarietà” di una Rete di Sensori preve-dendo degli aggiustamenti locali della topologia dell’albero nel caso di ca-duta di un nodo, di aggiunta di nuovi nodi o di nodi in difficoltà energeti-che.

Dalle simulazioni effettuate è stato rilevato che tale protocollo riesce effet-tivamente a bilanciare il consumo energetico dei nodi della rete.

Oltre a dati statistici di tipo energetico sono stati presi in considerazione anche aspetti strutturali dell’albero di Routing come il numero di livelli dell’Albero di Routing, il numero di figli ed il numero di discendenti asso-ciati ad ogni nodo. In particolare si nota come per tutte le simulazioni effet-tuate il numero di livelli dell’Albero tende ad aumentare negli ultimi giorni di vita della rete a causa della caduta di alcuni nodi che rende inaccessibili alcuni path utilizzati precedentemente. Sono state prese in considerazione due tipologie di rete: quella in cui tutti i nodi inizialmente si trovano con lo stesso livello energetico e quella in cui la rete risulta sbilanciata dal punto di vista energetico. In quest’ultimo caso abbiamo visto come i nodi a mino-re energia inizialmente ricoprano il ruolo di foglia a discapito di quelli ad energia maggiore. Man mano che il tempo di vita della rete avanza l’energia tra i nodi tende a bilanciarsi e quindi tutti i nodi tornano a ricoprire il ruolo di Nodo Router spartendosi in modo equo l’attività di forwarding. Dalle simulazioni risulta evidente anche che i nodi vicino al Sink consu-mano di più rispetto agli altri. In futuro sarebbe interessante lo sviluppo di un protocollo complementare che comprenda la possibilità di variare la

(3)

posizione del nodo Sink durante la vita della rete in modo da prolungare la durata della rete omogeneizzando il consumo energetico tra tutti i nodi. Altro aspetto su cui sarebbe interessante lavorare in futuro è di completare l’Architettura di Rete sviluppando altri protocolli appena accennati in que-sta Tesi.

(4)

Ringraziamenti Samuele Bachini

RINGRAZIAMENTI

Ringraziamenti doverosi vanno innanzitutto a tutti coloro che, durante questi ultimi otto mesi, mi hanno seguito ed aiutato nell’attività di ricerca che ho esposto in questa Tesi. In particolare voglio esprimere gratitudine verso il Prof. Giuseppe Anastasi , l’Ing. Andrea Passarella, il Dr. Giovanni Mainetto, il Dr. Marco Conti e il Dr. Enrico Gregori.

Inoltre colgo l’occasione per ringraziare tutti i miei amici ed i miei familiari che mi sono sempre stati vicino durante questi anni di Università.

Un ricordo particolare va infine ad Andrea D. , amico e compagno di studi che ci ha lasciato nel Settembre 2002.

(5)

APPENDICE A

TinyOS

[Hill 03, Madden TinyDB, Hill 00]

TinyOS è un sistema operativo che mette a disposizione del programmatore un insieme di componenti per gestire l’ hardware dei sensori. Il sistema è stato sviluppato utilizzando il linguaggio di basso livello nesC (simile al C).

Il TinyOS non fornisce le caratteristiche tradizionali dei sistemi operativi come ad esempio lo scheduling ; non ha un kernel , non ha un memory management e non e’ multi-thread.

TinyOS e’ quindi una sorta di libreria che fornisce un certo numero di astrazioni tra cui :

- radio stack : per spedire , ricevere , gestire pacchetti via radio

- sensor reading : per acquisire dati dai sensori , calibrare e configurare i sensori

- syncronize clock : per sincronizzare i clock dei sensori in modo che i timer negli scheduler funzionino correttamente

- power management features: permettono di mettere il sensore in uno stato di basso consumo energetico e di ‘svegliarlo’ al momento opportuno

- manage Flash-memory : permette di gestire la memoria con un’interfaccia file system-like

- localization of neighbour nodes : permette di localizzare i nodi vicini emettendo suoni o ultrasuoni e misurando il “tempo di volo”

TinyOS usa un’esecuzione basata sugli eventi. Infatti, il modello ad eventi permette una grande efficienza, alti livelli di concorrenza e un uso ridotto dello spazio di memoria. Un approccio basato sui thread richiede invece che lo spazio per lo stack sia preallocato per ogni esecuzione ( quindi

(6)

Appendici Samuele Bachini

necessita di maggiore memoria ) e un supporto multitasking per il cambio di contesto.

In nesC le funzioni possono essere di 3 tipi : command , event e task ( co-mandi, eventi e task).

I comandi richiedono l’inizio di qualche azione ( es: ‘rileva la temperatura corrente ’ ) ; gli eventi segnalano che un’azione è completata o che un cer-to evencer-to si e’ verificacer-to ( es: ‘the current light level is X’). Gli eventi sono spesso associati al processore tramite interrupt di basso livello: per questo motivo spesso possono fare preemption sui comandi ( è possibile anche il viceversa ma e’ molto meno frequente in pratica ).

Per permettere lunghe computazioni, TinyOS fornisce un meccanismo d’esecuzione chiamato task. Un task è un contesto d’esecuzione che gira in background fino al completamento e senza interferire con gli altri eventi di sistema.

Proprietà dei task:

• Un task non può essere interrotto da altri tasks • Un task può essere interrotto da eventi

• Gli eventi sono gestiti in modo atomico

Attualmente il task scheduling è realizzato tramite un semplice scheduler FIFO: sebbene sia possibile implementare efficientemente task-scheduler

a priorità è comunque insolito avere più task contemporaneamente pronti all’esecuzione e quindi una coda FIFO risulta adeguata per le applicazioni presenti in una sensor network.

TinyOS component model

Il TinyOS è realizzato tramite un modello a componenti in modo da per-mettere una efficiente modularità e composizione; infatti un modello a componenti permette ad uno sviluppatore di applicazioni di combinare in modo semplice componenti indipendenti e creare una configurazione spe-cifica per l’applicazione.

(7)

Figura A.1: TinyOS Component Model

(8)

Appendici Samuele Bachini

Ciascun componente è definito tramite un set di comandi e eventi che formano la sua interfaccia (Figura A.2).

I componenti forniscono o implementano certe interfacce che definiscono pubblicamente le funzioni contenute nei componenti stessi. I componenti possono anche richiedere interfacce ; in tale caso devono essere connessi ( wiring ) a un altro componente che fornisce interfacce.

Ciascun componente è formato da 4 parti (Figura A.2).: • Un set di command handler

• Un set di event handler

• Un incapsulate private data frame che rappresenta lo stato interno dei componenti

• Un insieme di task

Per ciascun componente devono essere dichiarati i comandi che usa e gli eventi che segnala ad altri componenti: attraverso questa dichiarazione è possibile creare un grafo modulare dei componenti; i componenti di più al-to livello inviano comandi ai componenti dei livelli più bassi i quali, a loro volta, inviano segnali ai componenti dei livelli più alti.

I comandi sono delle richieste non bloccanti fatte ai componenti dei livelli inferiori: di solito un command deposita parametri di richiesta nel frame e attiva l’esecuzione di un task.

Un comando può anche invocare altri commandi verso i livelli inferiori ma comunque deve sempre prevedere un feedback al suo chiamante in cui vengono ritornate le informazioni di stato.

Gli eventi (inviati dai componenti di livello inferiore) invocano gli event handler oppure, nel caso di componenti direttamente connessi all’hardware, al posto degli eventi vengono inviati degli interrupt.

I task possono chiamare lower level command, higher level signal e sche-dulare altri task nel component.

In generale è possibile suddividere i component in tre categorie:

• Hardware abstractions: mappano l’hardware nel TinyOS compo-nent model. Di solito esportano comandi all’hardware sottostante e gestiscono gli interrupt. Un esempio è l’RFM radio component

(9)

Figura A.3:RFM radio component

• Syntetic Hardware:: simulano il comportamento dell’esecuzione dell’hardware sottostante e estendono le funzionalità simulando il comportamento di funzioni hw avanzate (ad esempio implementano funzioni di trasformazione del tipo bit-to-byte)

• Hight level software: realizzano task specifici dell’applicazione (control, routing, data transmission, calculation on data, data ag-gregation …)

AM communication paradigm

Una parte fondamentale del TinyOS è il modello di comunicazione che supporta: il modello di comunicazione usato è basato sui messaggi attivi.

Comandi per mani-polare i pin di I/O dell’RFM trasceiver

Segnali (cioè interrupt) ricevuti dalla radio e che riguardano la

trasmissio-Contiene ad esem-pio il current bit rate o informazioni ri-guardanti lo stato attuale del trasceiver

(10)

Appendici Samuele Bachini

Ogni active message contiene il nome dell’handler dell’application level

che deve essere invocato (nel nodo destinatario) ed un payload dati in cui vengono passati gli argomenti.

L’handler, che va in esecuzione sul nodo destinatario non appena arriva un messaggio, ha due compiti:

• estrarre il messaggio dal network

• integrare i dati nella computazione o inviare un messaggio di rispo-sta

Il network è modellato come una pipeline con un bufferaggio minimo per i messaggi.

Per prevenire la congestione della rete e per assicurare buone perfor-mance i message handler devono essere capaci di andare in esecuzione velocemente ed in modo asincrono.

Il modello basato sulla chiamata dei message handler permette al si-stema di sovrapporre la comunicazione con altre attività (es. interagire con i sensori o eseguire altre applicazioni).

Il modello a messaggi attivi può essere visto come un modello distribuito a eventi in cui i nodi del network si inviano tra loro eventi. Affinché il modello di comunicazione basato sui messaggi attivi sia efficiente è necessario che il sistema fornisca alcune primitive:

• trasmissione di tipo best-effort dei messaggi e acknoledgment

• indirizzamento • dispatch

con queste primitive è possibile, da parte del developper, costruire qual-siasi tipo di applicazione.

(11)

APPENDICE B

TinyDB & TinyOS

Alcuni componenti di TinyDB servono a coprire le mancanze di TinyOS; inoltre 3 componenti di TinyOS sono riprogettati in TinyDB :

• Schelude communication: il TinyOS fornisce un meccanismo di scheduling ma TinyDB e’ in grado di esplorare la semantica della query e quindi conoscere il sample period per settare la schedulazione in maniera semplice

• Syncronization : con le conoscenze del livello applicativo e’ possibile sincronizzare i nodi senza causare comportamenti scorretti

• Power management : TinyOS fornisce un meccanismo per mettere il sensore in uno stato di basso consumo ma a livello di OS non c’e’ conoscenza di quando si ha bisogno di energia ; infatti la natura periodica delle query rende molto facile gestire l’energia a livello applicativo

Inoltre alcuni componenti del TinyOS sono replicati in TinyDB mediante il

(12)

Appendici Samuele Bachini

APPENDICE C

Sintassi TinyDB

SELECT clause

select-list={ agg(expr) ,attrs }

agg(expr)={AVG(par),MIN(attr),MAX(attr),COUNT(*)} Non sono supportate query annidate ( sub-SELECT ) Esempi:

• SELECT light , nodeid • SELECT COUNT(*) • SELECT AVG(volume)

FROM clause

[FROM sensors]

La proposizione FROM (opzionale ) deve specificare esattamente la ta-bella virtuale sensors

WHERE clause

La proposizione WHERE può contenere semplici espressioni aritmetiche. L’espressione aritmetica deve essere del tipo colonna op costante con op = { + , - , * , /,>,< }

Non sono supportati gli operatori OR e NOT e il costrutto LIKE di SQL

Esempi:

• WHERE light > 10 • WHERE (light/10=100)

(13)

GROUP-BY clause [GROUP BY gb-list]

Può essere specificato solo un attributo di grouping nella proposizione GROUP BY.

Non e’ supportata la rinominazione di colonne in gb-list ( operatore AS di SQL )

Esempi:

• GROUP BY room

HAVING clause

[HAVING having-list]]

L’espressione aritmetica deve essere del tipo colonna op costante con op = { + , - , * , /,>,< }

Esempi:

• HAVING (volume>5)

TRIGGER ACTION clause

TRIGGER ACTION command-name[(param)]]

Esempi:

• TRIGGER ACTION alarm() • TRIGGER ACTION SetSnd(512) • TRIGGER ACTION myaction()

EPOCH DURATION clause [EPOCH DURATION integer]

La epoch duration deve essere specificata in ms ; se non e’ specificato nessun valore viene assunta pari a 1024ms

Esempi:

• EPOCH DURATION 2000 EPOCH DURATION 1000 FOR 10000

(14)

Bibliografia Samuele Bachini

BIBLIOGRAFIA

[Akan 03]

Akan Ö. B., Su W., Vuran M. C., “Overview of Wireless Sensor Network Communication Protocols for Smart Environments”

[Akyildiz]

Y. Sankarasubramaniam, Ö. B. Akan, F. Akyildiz: “ESRT: Event to Sink Reliable Transport in Wireless Sensor Networks”, Georgia Institute of Technology, Atlanta, 2003.

[Akyildiz 02]

Akyildiz I.F., Su W., Sankarasubramaniam Y., Capirci E., “Wireless sensor networks:a survey”, Computer Networks, N. 38, 2002, pp. 393-442.

[Akyildiz 03]

I. F. Akyildiz, M. C. Vuran, O. B. Akan, "On Exploiting Spatial and Temporal Correlation in Wireless Sensor Networks," in Proc. WiOpt'04: Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks, pp. 71 -80, March 2004.

[Bonnet 00]

Philippe Bonnet, J. E. Gehrke, and Praveen Seshadri, “Querying the Physical World”, IEEE Personal Communications, Vol. 7, No. 5, pages 10-15.October 2000.

(15)

[Campbell 02]

Chieh-Yih Wan, Andrew Campbell, Lakshman Krishnamurthy, "PSFQ: A Reliable Transport Protocol For Wireless Sensor Networks", First Workshop on Sensor Networks and Applications (WSNA), September 2002, Atlanta, GA.

[Campbell 03]

C. Wan, S. B. Eisenman, A.T. Campbell, "CODA: Congestion Detection and Avoidance in Sensor Networks", ACM SenSys 2003.

[Chen]

B. Chen, K. Jamieson, H. Balakrishnan, R. Morris. Span, ”An energy­effcient coordination algorithm for topology maintenance in ad hoc wireless networks”. ACM Wireless Networks Journal, 8(5):481.494, September 2002.

[Conti 03]

M. Conti, S. Giordano, G. Maselli, G. Turi, ”Cross-Layering in Mobile Ad Hoc Networks’ Design: the MobileMAN Approach”, IIT-CNR,SUPSI, 2003.

[CrossBow]

User Manual: ”MPR - Mote Processor Radio Board,MIB - Mote Interface ,Programming Board User’s Manual MPR500CA, MPR510CA, MPR520CA,MPR400CB, MPR410CB, MPR420CB, MPR300CA, MPR310CA,MIB300CA, MIB500CA, MIB510CA, MIB600CA ”, Rev. A, December 2003. Document 7430-0021-05. [Elson]

J. Elson and D. Estrin, “Time Synchronization for Wireless Sensor Networks”. In Proceedings of the 2001 International Parallel and Distributed Processing Symposium (IPDPS), Workshop on Parallel

(16)

Bibliografia Samuele Bachini

and Distributed Computing Issues in Wireless Networks and Mobile Computing, April 2001, San Francisco, CA, USA, pp. 1965--1970. Also published as as UCLA Computer Science Technical Report 200028.

[Falchi]

A. Falchi: ” Sensor Netwroks: Performance Measurements with Motes Technology”, 2004.

[Feeney]

Laura Marie Feeney: “Energy Efficient Communication in Ad Hoc Wireless Networks” . Computer and Network Architectures Laboratory. Swedish Institute of Computer Science, 2003.

[Hill 00]

Jason Hill: “A Software Architecture Supporting Networked Sensors”, Research Project, UC, Berkeley, Fall 2000.

[Hill 03]

Jason Lester Hill: “System Architecture for Wireless Sensor Networks”, University of California, Berkeley, Spring 2003

[Intanagonwiwat]

C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks," ACM MobiCOM 2000.

[Jaikaeo]

C. Jaikaeo, C. Srisathapornphat, and C.-C. Shen, "Querying and Tasking in Sensor Networks", in SPIE's 14 th Annual International Symposium on Aerospace/Defense Sensing, Simulation, and Control, (Orlando, Florida), April 2000.

(17)

[Madden ACQP]

Samuel R. Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong, “The Design of an Acquisitional Query Processor for Sensor Networks”. SIGMOD, June 2003, San Diego, CA.

[Madden TAG]

Samuel R. Madden, Robert Szewczyk, Michael J. Franklin and David Culler, “Supporting Aggregate Queries Over Ad-Hoc Wireless Sensor Networks”. Workshop on Mobile Computing and Systems Applications, 2002.

[Madden Thesis]

Samuel R. Madden, “The Design and Evaluation of a Query Processing Architecture for Sensor Networks”, Ph.D. Thesis. UC Berkeley. Fall, 2003.

[Madden TinyDB]

S. Madden, J. Hellerstein, and W. Hong, “TinyDB: In-Network Query Processing in TinyOS”, Intel Research, IRB-TR-02-014, Oct. 1, 2002.

[Mills]

Mills, D.L.: ”Internet time synchronization: the Network Time Protocol”. IEEE. Trans. Communications, 1991. COM-39(10): p. 1482-1493.

[Polastre]

G. R. Polastre, “Design and Implementation of Wireless Sensor Networks for Habitat Monitoring”, Master dissertation, Dept. of Elec. Eng., UCB, Spring 2003.

(18)

Bibliografia Samuele Bachini

[Raghunathan 02]

Raghunathan V., Schurgers C., Park S., Srivastava M. B., “ Energy-Aware Wireless Microsensor Networks”, IEEE Signal Processing Magazine, March 2002.

[TinyDB]

Software Release. Web Site: http://telegraph.cs.berkeley.edu/tinydb [Woo]

Alec Woo, David E. Culler, “A transmission control scheme for media access in sensor networks”, Proceedings of the seventh annual international conference on Mobile computing and networking, July 2001.

[Zhang 03]

Yuecheng Zhang and Liang Cheng, “Cross-layer optimization for sensor networks”, New York Metro Area Networking Workshop 2003, New York City, NY, USA, September 12, 2003.

Figura

Figura A.1: TinyOS Component Model
Figura A.3:RFM radio component

Riferimenti

Documenti correlati

Per gli archi forward il valore α ij rappresenta quanto flusso posso ancora inviare lungo l’arco (i, j) ∈ A della rete originaria;. per gli archi backward il valore α ij

if (il pacchetto multicast è pervenuto attraverso il percorso unicast più breve tra il router e l’origine). then lo trasmette su tutti i propri collegamenti in uscita else

negotiations.  On  the  other  hand,  both  Schmidt  (2000)  and  Scharpf  (2011)  have  insisted  on  the  links  between  the  very  existence  of 

 SETTORIALITA’: grado in cui la rete si dimostra SETTORIALITA’: grado in cui la rete si dimostra suddivisibile in grappoli di legami distinti.. suddivisibile in grappoli di

Per trasferire un file usando il protocollo ftp occorre avere a disposizione un'applicazione ftp chiamata client ftp (ce ne sono diverse anche di tipo freeware) che viene

if (il pacchetto multicast è pervenuto attraverso il percorso unicast più breve tra il router e l’origine) then lo trasmette su tutti i propri collegamenti

La drammatica attualità degli infortuni lavorativi, delle malattie professionali e delle morti bianche (sul lavoro), impegna tutti i soggetti coinvolti nel mondo del lavoro

Il/La sottoscritto/a, inoltre, autorizza gli Enti Organizzatori del concorso, ai sensi della vigente normativa, al trattamento dei dati personali riportati in questo modello per i