POLITECNICO DI MILANO

V Facoltà di Ingegneria

Corso di laurea in Ingegneria delle Telecomunicazioni

Dipartimento di Elettronica e Informazione

Integrazione e implementazione dei livelli di rete e MAC

per reti di sensori su piattaforma TinyOS

Relatore: Prof. Antonio Capone

Correlatore: Ing. Stefano Melzi

Tesi di Laurea di:

Carmelo Cascone

Matricola 677574

Anno Accademico 2008/2009

i

Indice

Indice i

Elenco delle figure iii

Elenco delle tabelle v

1 INTRODUZIONE 1

1.1 Progetto AIM e struttura del sistema .........................................................2 1.1.1 Gateway............................................................................................3 1.1.2 Energy Management Device .............................................................4 1.1.3 Interfaccia utente ..............................................................................5 1.1.4 Profilo utente ....................................................................................5 1.1.5 Rete di sensori ..................................................................................7

2 ANALISI DELLO STATO DELL’ARTE 9

2.1 Reti di sensori wireless ................................................................................9 2.1.1 Topologie ........................................................................................ 10 2.1.2 Applicazioni .................................................................................... 11

2.2 Protocolli di livello MAC .......................................................................... 12 2.2.1 Standard IEEE 802.15.4 ................................................................. 13 2.2.2 Altri protocolli MAC ...................................................................... 20

3 PIATTAFORME HARDWARE E SOFTWARE UTILIZZATE 22

3.1 TinyOS...................................................................................................... 22

3.2 Nesc........................................................................................................... 23 3.2.1 Comandi ed Eventi ......................................................................... 24 3.2.2 Task ................................................................................................ 25 3.2.3 Interfacce e Componenti ................................................................. 26

3.3 MICAz....................................................................................................... 27

4 INTEGRAZIONE 29

4.1 MobiWSN.................................................................................................. 29 4.1.1 Architettura Generale ..................................................................... 29

ii

Livello di Rete e Protocollo di Routing ...................................... 31 Livello Middleware ................................................................... 32

4.1.2 Implementazione MobiWSN sulla rete di sensori............................ 33 Livello Network........................................................................ 34 Livello Group .......................................................................... 35 Livello Middleware................................................................... 35

4.2 Verifica di fattibilità.................................................................................. 37

4.3 Vantaggi apportati .................................................................................... 42

4.4 TKN15.4.................................................................................................... 44 4.4.1 Componenti dell’architettura.......................................................... 45 4.4.2 Definizione delle interfacce.............................................................. 47

5 IMPLEMENTAZIONE 50

5.1 Struttura originaria del livello di rete MobiWSN...................................... 52

5.2 ForwardingManager154P .......................................................................... 54

5.3 StartManager154P..................................................................................... 60

6 CONCLUSIONI 64

Bibliografia 66

Ringraziamenti 68

iii

Elenco delle figure

Figura 1.1 Architettura AIM...................................................................................... 3

Figura 1.2 Esempio di distribuzione di probabilità, per ogni giorno della settimana,

che l'utente sia in casa ........................................................................................ 6

Figura 1.3 Esempi di topologia ad albero e mesh ....................................................... 8

Figura 2.1 Topologie di rete ..................................................................................... 10

Figura 2.2 Topologie di rete Star e Peer-To-Peer..................................................... 14

Figura 2.3 Struttura della trama dati IEEE 802.15.4............................................... 20

Figura 3.1 Hardware utilizzato ................................................................................. 27

Figura 4.1 Ipotesi di architettura d'integrazione MobiWSN .................................... 30

Figura 4.2 Architettura di rete MobiWSN ............................................................... 32

Figura 4.3 Componenti principali del lato sensori dell'architettura MobiWSN........ 34

Figura 4.4 Struttura messaggio IEP ......................................................................... 36

Figura 4.5 Topologia di rete prevista dal protocollo HAT ....................................... 38

Figura 4.6 Struttura generica di una rete WPAN organizzata secondo una topologia di tipo cluster-tree............................................................................................. 39

Figura 4.7 Netwok Header e dettaglio del Control Field.......................................... 40

Figura 4.8 Formato della trama MAC 802.15.4 ....................................................... 41

Figura 4.9 Architettura del TKN15.4....................................................................... 45

Figura 5.1 Architettura di partenza del livello di rete.............................................. 53

Figura 5.2 Dettaglio dei collegamenti del componente ForwardingManagerP prima dell’adattamento al livello MAC 802.15.4 ......................................................... 55

Figura 5.3 Dettaglio dei collegamenti del componente ForwardingManager154P dopo

l’adattamento al livello MAC 802.15.4.............................................................. 56

Figura 5.4 Sequenza di comandi nel caso di (a) invio e (b) ricezione di un pacchetto

.......................................................................................................................... 59

iv

Figura 5.5 Sequenza di comandi all'avvio del PAN coordinator............................... 61

Figura 5.6 Sequenza di comandi all'avvio di un dispositivo semplice....................... 62

v

Elenco delle tabelle

Tabella 3-1 Sintassi di dichiarazione e invocazione di un comando in NesC............ 24

Tabella 3-2 Sintassi di dichiarazione e segnalazione di un evento in NesC .............. 25

Tabella 3-3 Sintassi di dichiarazione e invocazione di un task in NesC ................... 26

Tabella 4-1 Componenti del TKN15.4...................................................................... 46

Tabella 4-2 Dichiarazione delle interfacce MCPS-DATA e MLME-BEACON-NOTIFY............................................................................................................ 47

Tabella 4-3 Interfacce di livello fisico del TKN154................................................... 49

Tabella 5-1 Dichiarazione dell'interfaccia Forward .................................................. 54

Tabella 5-2 Dichiarazione del comando forward dell’interfaccia Forward154........... 57

1

Capitolo 1

Introduzione

Lo scopo di questo lavoro di tesi è analizzare e valutare le possibili soluzioni d’integrazione e implementazione dei livelli di rete e MAC per reti di sensori a se-

conda di una specifica necessità funzionale. Alla base di questo studio vi è il Proget-to AIM, progetto che si occupa di creare una nuova architettura hardware e softwa-

re in grado di modellizare, visualizzare e gestire il consumo di energia in ambito do-mestico. Tra le tecnologie alla base del progetto AIM, che verrà a breve illustrato

nel dettaglio, vi sono anche le reti di sensori, con requisiti topologici e funzionali ben definiti.

Il lavoro è organizzato dapprima in una panoramica sull’intera architettura del progetto AIM, descrivendo nel dettaglio l’utilizzo che si fa delle reti di sensori e le caratteristiche che queste devono presentare. Dopo una breve rassegna sulle Wireless

Sensor Network (WSN) si passerà ad una introduzione dello standard IEEE 802.15.4, esaminando in particolare la specifica del protocollo di livello MAC, che

vedremo essere il protocollo scelto per il nostro scopo. Da qui, dopo un’introduzione sulle piattaforme hardware e software che verranno utilizzate si passerà al lavoro ve-

ro e proprio di analisi, verifica della fattibilità e implementazione della soluzione proposta. Soluzione che consiste nell’integrazione tra il protocollo MAC 802.15.4 e il

livello di rete esistente dell’architettura MobiWSN. MobiWSN è un progetto del la-boratorio ANTLab del Politecnico di Milano, nato con la volontà di realizzare

l’integrazione e l’interconnessione a livello applicativo di una o più reti wireless di sensori. Questa particolare architettura risulta essere molto utile allo scopo di gestire la rete di sensori utilizzata per monitorare l’ambiente domestico che il progetto AIM

si pone di controllare.

2

Come vedremo alla fine, nonostante venga dimostrato come sia possibile

un’integrazione tra il livello di rete dell’architettura MobiWSN e il protocollo di li-vello MAC 802.15.4, si concluderà affermando che questo lavoro è tutt’altro che

semplice, ma gli enormi vantaggi che ne conseguono, soprattutto in termini di ri-sparmio energetico, giustificano a pieno tutto l’impegno necessario.

Proprio per la particolare complessità del lavoro richiesto, soprattutto conside-rando il tempo necessario per la realizzazione pratica di tutta la soluzione

d’integrazione, il lavoro d’implementazione svolto in questa tesi rappresenta solo il punto di partenza per l’integrazione ottimale dello standard IEEE 802.15.4

nell’architettura in esame. Risulta invece di particolare importanza il minuzioso la-voro di analisi e verifica dei vincoli progettuali, che, aggiunto alla parte implementa-tiva già realizzata, permette di definire le varie fasi di sviluppo necessarie per rag-

giungere l’obbiettivo di questa tesi.

1.1 Progetto AIM e struttura del sistema

Il progetto AIM[1] mira all’ottimizzazione del consumo energetico di un’abitazione monitorando e gestendo tutti i consumi dei vari elettrodomestici e dispositivi pre-senti all'interno dell'abitazione. Il progetto AIM pone maggiore attenzione sui con-

sumi generati da tre differenti tipologie di dispositivi: elettrodomestici, audio/video e apparecchiature per le comunicazioni. L’obiettivo del risparmio energetico si ottiene

attraverso un monitoraggio continuo dei consumi e delle attività delle persone pre-senti nell’ambiente che permette di impostare in modo automatico i vari dispositivi

secondo le necessità dell'utente. Tutto ciò permette di ottimizzare i consumi al fine di ottenere abitazioni eco-sostenibili.

L’architettura che permette tutto ciò è composta da sei parti fondamentali: il Ga-

teway, il EMD (Energy Management Device), la rete domestica, gli utenti e gli elet-trodomestici. La rete AIM si occupa di collegare le reti interne ed esterne

all’abitazione al fine di fornire applicazioni specifiche, che permettano l’utilizzo dei vari servizi offerti dall’abitazione stessa, a tre categorie di utenza: gli utenti della ca-

sa, gli operatori della rete e l’ente che fornisce l’energia.

3

Per realizzare ciò il progetto AIM si serve dell’architettura descritta in Figura 1.1

nella quale si notano le parti fondamentali dell’AIM System Logic, che è il cuore di tutta l’architettura: l’AIM Gateway, che permette l’interconnessione tra la rete in-

terna ed esterna, e l’Energy Management Device che mette a disposizione le varie funzioni che permettono di monitorare e risparmiare energia. Gli utenti del servizio

AIM possono utilizzare i servizi offerti all’interno dell’abitazione utilizzando l'inter-faccia offerta dal “AIM System Logic” con la possibilità di monitorare i consumi e

ottimizzare l'utilizzo dei dispositivi. Gli utenti della rete esterna possono accedere ad una parte delle informazioni riguardanti i consumi energetici dell'abitazione e posso-

no inviare informazioni al sistema (ad esempio il costo dell'energia nelle diverse ore del giorno).

Figura 1.1 Architettura AIM

Tale architettura flessibile è stata adottata al fine di preservare la scalabilità del sistema stesso così da lasciare ampia libertà ai soggetti interessati (operatori, terze

parti e gli stessi utenti della casa) di sviluppare applicazioni di qualsiasi tipo per sal-vaguardare il risparmio energetico.

1.1.1 Gateway

Il Gateway ha la principale funzione di collegare la rete interna all'abitazione con i servizi esterni dell’operatore tramite protocollo IP. Oltre alla funzione

4

d’interconnessione può essere utilizzato dal sistema in maniera attiva e quindi in es-

so risiederà anche la logica. In quest’ultimo caso, quindi, il Gateway sarà provvisto d’interfacce di astrazione ad alto livello per la gestione della logica stessa da parte

degli utenti. Per far sì che il Gateway possa offrire i servizi descritti sopra, e il si-stema sia allo stesso tempo flessibile e scalabile, si è optato per un sistema con archi-

tettura open. La scelta per il progetto AIM è ricaduta sul Gateway ESTIA. questo Gateway

deve quindi ricoprire alcune funzionalità fondamentali del sistema:

- I vari elettrodomestici devono essere ordinati secondo le funzionalità e i vari programmi che offrono.

- Il sistema crea dei profili personali dei singoli utenti, nei quali sono salvati i

dati che permettono di definire le abitudini degli individui così da permettere al sistema stesso di offrire sempre servizi migliori e personalizzati anche per

quanto riguarda il risparmio energetico.

- L’utente deve avere la possibilità di visionare i vari dati riguardanti le abitu-dini degli individui. Inoltre l’utente deve avere la libertà di definire alcune so-

glie, per quanto riguarda i consumi, oppure può definire delle priorità fra i vari elettrodomestici e servizi offerti dal sistema. Quest’ultima possibilità è data

grazie a delle applicazioni che mettono in comunicazione diretto l’utente con l’EMD come spiegato nella sezione 1.1.2.

- I profili creati per i singoli utenti non possono essere visionabili dall’esterno;

quindi l’ente che fornisce l’energia, per esempio, non può accedere ai dati dei singoli utenti, che quindi saranno tutelati da una sorta di privacy per quanto

riguarda abitudini casalinghe e conseguenti consumi energetici, ma piuttosto avrà l’accesso ai dati dei consumi generali della struttura.

1.1.2 Energy Management Device

L’EMD svolge la funzione di monitorare e gestire l’energia. Il monitoraggio avviene tramite la misura costante dei consumi e il conseguente invio di tali dati all'”AIM

5

System Logic”. La gestione dell’energia avviene gestendo l'accensione, lo spegnimen-

to e la modalità di funzionamento (es. stand-by) dei dispositivi in modo intelligente. L’Energy Management Device può far parte integrante del singolo elettrodomestico,

può essere inserito all’intero del Gateway oppure può essere un dispositivo indipen-dente, come in Figura 1.1, svolgendo la funzione di connessione fra il gateway e i va-

ri elettrodomestici e servizi del sistema all’intero dell’abitazione.

1.1.3 Interfaccia utente

Gli utenti hanno accesso ai servizi AIM attraverso le varie applicazioni compatibili con qualsiasi tipo di terminale; quindi dall’edificio stesso possono utilizzare i termi-

nali all’interno dell’abitazione ma anche PDA o PC. Dall’esterno, invece, gli utenti si devono appoggiare a qualche operatore di rete che offre il servizio di accesso da

remoto, e anche in questo caso possono utilizzare PC e PDA. In alcuni casi, è possi-bile che lo stesso operatore che offre il servizio AIM garantisca la sicurezza del colle-

gamento da remoto e quindi dall’esterno. Solo in questi casi è possibile non avvalersi di operatori di terze parti ma sfruttare il servizio dall’interno e dall’esterno sempre

con lo stesso operatore di rete. L’interfaccia offerta sarà la stessa sia dall’interno sia dall’esterno per semplificare all’utente la gestione e il monitoraggio del servizio. Nel-

lo stesso tempo, però, il consorzio AIM dà la possibilità di sviluppare applicazioni che possano interagire con il sistema senza provocare impatti negativi sui protocolli del Gateway o comunque provocare malfunzionamenti ai meccanismi principali del

sistema. Infatti l’accesso ai servizi del Gateway sarà possibile solo attraverso delle

funzioni (API, Application Programming Interface) rese disponibili dal sistema.

1.1.4 Profilo utente

La creazione da parte del sistema dei profili degli utenti ha due funzioni principali:

un meccanismo di memorizzazione di alcuni eventi che possono caratterizzare il mo-do con cui l’utente interagisce con l’ambiente, per esempio le sue azioni più comuni e

le abitudini, e in secondo luogo, l'utilizzo di un algoritmo, che elaborando questi dati dell’utente, calcola le impostazioni del sistema di gestione dell’energia più appropria-

6

te alle esigenze dell’utente. Tale procedura, di memorizzazione e elaborazione dei da-

ti degli utenti, è finalizzata a sostituire alcune impostazioni del sistema basate su una interazione manuale dell’utente, con delle impostazioni automatiche che il si-

stema crea in automatico e che l’utente, ovviamente, può attivare e disattivare su richiesta. Questo processo interagirà con il sistema attraverso le stesse funzioni con

cui interagirebbe l’utente così da poter vedere il tutto come un plug-in del sistema stesso che l’utente può attivare e disattivare a piacimento. I dati raccolti dal sistema

per creare i profili sono salvati seguendo alcuni principi fondamentali:

- Presenza dell’utente in casa, o in particolari stanze, e conseguente utilizzo de-gli elettrodomestici che si trovano nell’ambiente.

- Giorni della settimana in cui l’utente è in casa e utilizza le varie apparecchia-

ture.

- Orari nei quali l’utente è presente e si serve del sistema e dei suoi servizi.

I dati raccolti secondo queste linee guida consentono di rappresentare la presenza e l’utilizzo degli elettrodomestici da parte dell’utente secondo una distribuzione di

probabilità. Per esempio si può calcolare con quale probabilità l’utente è in casa nel weekend e in quali ore, oppure che probabilità ha l’utente di utilizzare un particolare

elettrodomestico o due apparecchiature contemporaneamente. Un esempio di distri-buzione di probabilità, per ogni giorno della settimana, che l’utente sia presente

nell’abitazione può essere riassunta in Figura 1.2:

Figura 1.2 Esempio di distribuzione di probabilità, per ogni giorno della settimana, che l'utente sia in casa

7

Dopo questo studio probabilistico del sistema si può quindi definire il profilo dell’utente e impostare il risparmio energetico degli elettrodomestici seguendo le abi-

tudini dell’utente: quindi gli elettrodomestici saranno attivati quando è molto pro-babile che l’utente necessita di utilizzare quell’apparecchio in quel momento oppure,

al contrario, sarà inserita la modalità di stand-by. Il sistema prevede anche una sor-ta di feedback da parte dell’utente: ciò consiste in una richiesta manuale da parte

dell’individuo al sistema che provvederà a rivedere e modificare il proprio algoritmo, basato sul profilo utente.

1.1.5 Rete di sensori

La rete di sensori è una parte fondamentale di tutto il sistema perché permette di monitorare l’ambiente fornendo i dati che consentono di elaborare il profilo dell’utente. La rete raccoglie le informazioni sui comportamenti degli individui e la

loro interazione con i vari elettrodomestici permettendo così al sistema di elaborare le varie impostazioni automatiche che seguono le esigenze dell’utente. Inoltre la rete

di sensori monitora anche l’ambiente stesso fornendo dati fisici come temperatura, luce ecc., questi dati sono utilissimi al sistema per gestire automaticamente gli im-

pianti d’illuminazione, riscaldamento, condizionamento ecc. In futuro la rete di sen-sori può essere in grado anche di fornire un meccanismo di riconoscimento della per-sona che permette di personalizzare ancora di più i vari profili. La tecnologia adotta-

ta per queste reti di sensori è quella wireless IEEE 802.15.4, descritta nel paragrafo 2.2, che permette una maggiore flessibilità nel costruire la rete all’interno dello sce-

nario descritto pur mantenendo sempre un costo non elevato; tale tecnologia prevede una topologia multi–hop che può essere sia di tipo ad albero o mesh secondo lo sce-

nario in cui tale rete è adoperata. La piattaforma utilizzata per lo sviluppo dell'applicazione per il progetto AIM

prevede tre livelli gerarchici per il protocollo: livello fisico, middleware e routing. I dispositivi sensore possono essere di diverso tipo secondo quali funzionalità e quali

tipologia di sensore (luce, presenza etc.) sono richiesti dal sistema. Tutti questi dati

8

raccolti dalla rete sono inviati alla logica del sistema per essere elaborati e per la

creazione dei vari profili utente.

Figura 1.3 Esempi di topologia ad albero e mesh

9

Capitolo 2

Analisi dello stato dell’arte

2.1 Reti di sensori wireless

Una Rete di Sensori Wireless, spesso indicata con l’acronimo WSN (Wireless Sensor Network) è una rete formata da piccoli dispositivi, perfettamente autonomi, che co-operano nell’esecuzione di una qualche applicazione di raccolta informazioni di un

determinato fenomeno fisico. Solitamente i dispositivi che compongono la Rete di Sensori Wireless vengono denominati Nodi Sensore (Sensor Node). Questi dispositivi sono tipicamente dotati di specifici componenti hardware, detti trasduttori, in grado

di misurare opportune grandezze fisiche dall’ ambiente circostante (temperatura, pressione, intensità sonora, vibrazioni, umidità, moto, ecc.). Inoltre, sono dotati di

un dispositivo di comunicazione per trasmettere i dati acquisiti dai trasduttori. Le principali caratteristiche di una Rete di Sensori Wireless sono legate alla necessità di

funzionamento senza l’ ausilio di fili e di essere di dimensioni ridotte. Questo, in ge-nerale, significa che i dispositivi che compongono una Rete di Sensori presentano

una quantità di memoria limitata, nonché vincoli stringenti dal punto di vista dei consumi energetici e minori capacità di elaborazione e di comunicazione. Il problema

del risparmio energetico è una delle caratteristiche principali che vanno tenute in considerazione, in quanto, in condizioni di lavoro realistico, non è quasi mai possibile ricaricare o sostituire le batterie di un nodo sensore sia per motivi di costo che di ac-

cessibilità dei nodi stessi, in quanto potenzialmente disposti in ambienti difficilmente accessibili. Inoltre la topologia di una Rete di Sensori può cambiare frequentemente

sia per la potenziale mobilità dei singoli nodi sia per la probabilità di malfunziona-mento degli stessi. Infatti i nodi sensore sono intrinsecamente soggetti al fallimento,

inteso come malfunzionamento del dispositivo, in quanto potrebbero venire utilizzati in ambienti ostili; in questi contesti un singolo sensore deve poter essere danneggiato

10

o distrutto senza che ciò pregiudichi il funzionamento dell’ intera rete. Senza pensare

a queste applicazioni, che possono comunque essere considerate di nicchia, un nodo sensore potrebbe semplicemente cessare di funzionare a causa della mancanza di e-

nergia, ed anche in questo caso il corretto funzionamento della rete non deve venire pregiudicato.

2.1.1 Topologie

Figura 2.1 Topologie di rete

Gli aspetti inerenti alla topologia delle Reti di Sensori Wireless possono essere stu-

diati sotto due diversi aspetti: la topologia di rete, dove con questo termine si indica la posizione che i diversi dispositivi vengono ad occupare nello spazio, e le diverse ti-

pologie di rete da un punto di vista funzionale, e della possibilità di intercomunica-zione fra i diversi nodi. Per quel che concerne il posizionamento fisico dei dispositivi

è opportuno ricordare che uno dei vantaggi delle reti wireless risiede proprio nell’estrema libertà con la quale si possono collocare i nodi sensore. Proprio per que-sto è importante notare come la posizione relativa fra i diversi dispositivi possa evol-

vere nel tempo. Inoltre i nodi sensore possono anche essere essenzialmente statici, cioè posti in posizioni precise che non cambiano nel tempo, ma in ogni caso sono

soggetti al problema dello spegnimento a causa della mancanza di energia, ciò com-porta che anche questo tipo di dispositivi contribuisce all’evoluzione della topologia

di rete. Infine, è opportuno ricordare che un altro vantaggio delle WSN è la facilità con la quale queste possano essere integrate con l’aggiunta di nuovi dispositivi, an-

che questo contribuirà al cambiamento della topologia di rete. Tutte le osservazioni

11

fatte portano a valutare l’utilizzo di “topologie funzionali di rete” e di protocolli di

routing (protocolli di “instradamento”) che garantiscano l’affidabilità della rete an-che in corrispondenza di continui cambiamenti di posizione dei nodi e/o

all’aggiunta/rimozione dei nodi stessi. In prima approssimazione è possibile classifi-care le topologie di rete in tre diversi gruppi: reti a stella, reti mesh o peer-to-peer ed

infine reti ad albero. In Figura 2.1 sono schematizzate le strutture delle topologie di rete appena elen-

cate, nella prima si individua un nodo centrale dotato di funzionalità di coordinato-re, esso infatti viene definito coordinatore della rete o centro della rete a stella, tutti

gli altri nodi fanno riferimento a questo nodo centrale. Ciò implica che affinché due nodi possano comunicare fra loro è necessario che entrambi comunichino con il coor-dinatore della rete. Questa topologia risulta essere la più semplice implementabile,

poiché consente l’impiego di protocolli poco onerosi da un punto di vista computa-zionale per i nodi semplici. La topologia di rete stella però viene superata in funzio-

nalità dalle reti di tipo peer to peer o mesh, reti cioè in cui il ruolo del coordinatore non è essenziale poiché ogni dispositivo è in grado di connettersi con tutti gli altri.

In questo modo è possibile realizzare dei percorsi ridondanti che, da un lato, consen-tono di aumentare l’affidabilità della rete, ma dall’altro richiedono l’implementazione

di algoritmi di routing più complessi. Infine abbiamo la topologia ad albero in cui diversi cluster costituiti da gruppi di nodi possono “interconnettersi” in modo simile

a come avviene la diramazione delle foglie su un albero. Ciascun cluster, infatti, è dotato di un nodo principale che rappresenta il punto d’accesso per la sottorete in questione. Il vantaggio di questa topologia rispetto alle reti mesh è la riduzione dei

percorsi di comunicazione possibili e ciò consente lo sviluppo di sistemi di gestione meno complessi.

2.1.2 Applicazioni

Le Reti di Sensori sono, generalmente, suddivise in applicazioni di “sorveglianza o monitoraggio” e applicazioni di “controllo”. Ogni volta che la rete si occupa della so-

la raccolta di dati, parleremo di applicazione di “sorveglianza”. Si parlerà invece di applicazione di “controllo” quando la rete stessa avrà il compito di interagire in ma-

12

niera attiva con il fenomeno fisico che si sta analizzando. Gli ambiti in cui vengono

utilizzate le Reti di Sensori Wireless sono:

- Sorveglianza o monitoraggio

- Agricoltura

- Analisi ambientali: habitat; tracciamento di animali;

- Sorveglianza: edifici; infrastrutture;

- Sicurezza: rilevamento sismico; alluvioni; catastrofi naturali;

- Sorveglianza militare

- Ambito medico: sorveglianza anziani; salute; handicap;

- Controllo

- Gestione di inventari

- Gestione di emergenze

- Automazione: edifici residenziali; ufficio; in ambito industriale; fabbri-cazione;

2.2 Protocolli di livello MAC

Viene presentato in questo capitolo lo standard IEEE 802.15.4 [11] elaborato dalla IEEE e dalla ZigBee Alliance per reti di tipo Wireless Personal Area Network

(WPAN) a basso bit rate. Lo standard fa parte della famiglia IEEE 802.x che si oc-cupa di definire le specifiche dei due livelli inferiori della pila protocollare ISO-OSI: il

livello fisico e il livello datalink. La pila ISO-OSI è uno standard per l’interconnessione di calcolatori elaborato nel 1978 in cui viene modellizzato il siste-

ma di comunicazione attraverso 7 livelli protocollari, i cosiddetti layer, che racchiu-dono uno o più aspetti fra loro correlati della comunicazione fra due nodi di una re-te.

13

Il livello di cui ci occuperemo nel seguito è quello datalink. Questo permette il

trasferimento affidabile di dati attraverso il livello fisico, invia trame di dati con la necessaria sincronizzazione ed effettua un controllo degli errori e delle perdite di se-

gnale. Tutto ciò consente di far apparire, al livello superiore, il mezzo fisico come una linea di trasmissione esente da errori di trasmissione.

2.2.1 Standard IEEE 802.15.4

Lo standard IEEE 802.15.4[5] definisce le specifiche dei protocolli di livello fisico e MAC per reti di dispositivi wireless a basso bit-rate e a basso consumo energetico. I primi studi iniziarono nel 1998 quando si capì che gli standard Bluetooth e Wi-Fi

non erano adatti a soddisfare i requisiti di queste tipologie di reti. Nacque quindi la ZigBee Alliance, un consorzio industriale di aziende con lo scopo di promuovere lo

sviluppo e la standardizzazione di questa tecnologia. Poco dopo anche il comitato IEEE 802.15 definì un sottogruppo (.4) per lo studio di questo tipo di reti. La prima

versione della specifica IEEE 802.15.4 risale al 2003 e definisce i primi due livelli del-lo stack protocollare. La versione 1.0 della specifica ZigBee venne invece ratificata

nel dicembre 2004 e resa disponibile nel giugno del 2005. Attualmente l'IEEE si oc-cupa della standardizzazione dei livelli fisico e data-link mentre la ZigBee Alliance

provvede allo sviluppo del livello network e dei livelli applicativi superiori. La specifica prevede due tipologie di dispositivi: dispositivi Full-Function (FFD) e

dispositivi Reduced-Function (RFD). Un FFD può svolgere funzionalità di PAN co-

ordinator, di coordinator o di dispositivo semplice e può comunicare con RFD o altri FFD. Un RFD può svolgere solo le funzioni di dispositivo e può comunicare solo con

un FFD. Gli RFD sono pensati per svolgere compiti semplici quali interruttori, sen-sori passivi, con requisiti computazionali limitati. A seconda dei requisiti applicativi

una rete 802.15.4 può operare in due configurazioni distinte: una topologia a stella e una topologia peer-to-peer o mesh (figura 2.2).

Nella topologia a stella la comunicazione è regolata da un dispositivo FFD che svolge il ruolo di PAN Coordinator. La comunicazione avviene solamente fra singolo

dispositivo e PAN Coordinator, che è responsabile dell'inoltro di trame fra due di-spositivi. La topologia peer-to-peer prevede invece la possibilità per i dispositivi FFD

14

di comunicare direttamente con tutti i dispositivi all'interno del range di copertura.

La specifica prevede la possibilità di creare reti con instradamento multi-hop per l'i-noltro delle trame ma, poichè la specifica copre solo il livello fisico e il livello data-

link, la descrizione di queste funzionalità non è coperta dallo standard.

Figura 2.2 Topologie di rete Star e Peer-To-Peer

Il livello fisico prevede quattro diversi schemi di modulazione, in tre bande princi-pali di funzionamento:

- trasmissione a frequenza 868/ 915 MHz (868 MHz per l'Europa, 915 MHz per

gli Stati uniti) con codifica DSSS (Direct Sequence Spread Spectrum) e modu-lazione BPSK (Binary Phase Shift Keying);

- trasmissione a frequenza 2450 MHz (ISM) con codifica DSSS e modulazione

O-QPSK;

- trasmissione a frequenza 868/ 915 MHz con codifica DSSS e modulazione O-QPSK (Offset-Quadrature Phase Shift Keying);

- trasmissione a frequenza 868/ 915 MHz con codifica PSSS (Parallel Sequence

Spread Spectrum) e modulazione BPSK o ASK (Amplitude Shift Keying);

15

I primi due schemi di modulazione fanno parte della prima specifica (2003) e cor-

rispondono a bit rate di 20kb/s e 1 canale in banda 868 MHz, 40kb/s e l0 canali in banda 915MHz e 250kb/s e 16 canali in banda 2,4GHz. Gli ultimi due schemi di

modulazione sono stati aggiunti nelle revisioni successive della specifica per fornire bit rate a 250kb/s anche nelle bande 868 e 915 MHz. I livelli di potenza utilizzati

vanno da -32dBm a 0dBm.

Il livello MAC prevede due distinte modalità di funzionamento: una modalità be-acon-enabled in cui un nodo con funzione di PAN coordinator trasmette periodica-

mente trame di beacon e una modalità beacon-less che non prevede l’invio periodico di trame di beacon. Il beacon ha funzioni di sincronizzazione dei periodi di attività

dei dispositivi, di descrizione della struttura della supertrama sul canale ed è neces-sario per le procedure di network discovery. Nel caso in cui il PAN coordinator non

trasmetta la trama di beacon l'accesso al canale è senza alcun allineamento di trama o sincronizzazione fra i dispositivi e si basa sull’algoritmo CSMA-CA. CSMA/CA è

l'acronimo inglese di Carrier Sense Multiple Access with Collision Avoidance, ovvero accesso multiplo tramite rilevamento della portante che evita collisioni. Nel momen-

to in cui un dispositivo vuole tentare una trasmissione ascolta il canale (Listen-before-Transmit). Se il canale è occupato il dispositivo attiva un timer di durata ca-

suale (detto tempo di backoff) che viene decrementato solo durante i periodi di inat-tività del canale. Quando il timer arriva a zero il dispositivo fa un altro tentativo. Se il canale risulta libero lo "prenota" ed attende per un certo lasso di tempo. Se il ca-

nale continua ad essere libero (non ci sono state altre prenotazioni) trasmette. Un dispositivo che vuole trasmettere semplicemente controlla se il canale è libero me-

diante CCA (Clear Channel Assessment), un meccanismo che controlla il livello di energia del segnale ricevuto e decide se qualcuno sta trasmettendo oppure no, in

quest’ultimo caso comincia a trasmettere. Opzionalmente la trama trasmessa può essere riscontrata con una trama di ACK.

Nel caso in cui il PAN Coordinator trasmetta la trama di beacon (rete beacon-enabled) il metodo di accesso al canale segue un meccanismo di tipo CSMA-CA sud-diviso a slot. Il tempo sul canale è organizzato in supertrame separate dalla trasmis-sione di due beacon frame.

16

La figura 2.3 illustra la struttura di una supertrama. La supertrama è definita

dall'intervallo fra la trasmissione di un beacon frame e il successivo. All'interno di

essa distinguiamo un Inactive Period, durante il quale i dispositivi possono entrare

in modalità a basso consumo energetico spegnendo l'apparato radio, e un Active Pe-riod. Quest'ultimo è a sua volta suddiviso in 16 slot di uguale durata (indicata nel beacon frame). L'accesso al canale è CSMA-CA a slot. I dispositivi devono sincroniz-

zarsi con l'inizio di uno slot e completare le eventuali trasmissioni entro il termine dello stesso slot. Opzionalmente il PAN Coordinator può riservare una parte di slot

alla fine dell'Active-Period per applicazioni con particolari requisiti di banda. Il nu-mero e la configurazione di tali slot, detti GTS (Guarranted Time Slot) è indicato nel beacon frame e l'accesso è quindi privo di contesa (da cui la dicitura Contention

Free Period). Il trasferimento dati avviene secondo quatto possibili sequenze di

scambio di messaggi, due per reti beacon-enabled e due per reti beacon-less.

Figura 2.3 Struttura della supertrama IEEE 802.15.4

In particolare la figura 2.4 illustra lo scambio di messaggi originato da coordinator

e da dispositivo semplice nel caso di reti beacon-enabled. Il dispositivo che intende trasmettere una trama ad un coordinator attende la ricezione di un beacon frame al

quale si sincronizza. Il dispositivo trasmette quindi la trama utilizzando un accesso CSMA-CA a slot. Opzionalmente il coordinator può riscontrare la trama inviando una trama di acknowledgement. Nel caso sia il coordinator che intende trasmettere

una trama ad un dispositivo, specifica la presenza di una trama pendente nel beacon

17

frame. Il dispositivo invierà quindi una trama di data-request al coordinator (sempre

con accesso al canale suddiviso in slot). La trama dati verrà inviata usando un mec-canismo CSMA-CA a slot oppure, se possibile, immediatamente dopo la trama di

acknowledgment della trama di data-request. Il dispositivo può infine riscontrare a sua volta la trama dati ricevuta.

Figura 2.4 Modalità di trasferimento dati in reti beacon-enabled

Figura 2.5 Modalità di trasferimento dati in reti beacon-less

In reti beacon-less (figura 2.5) un dispositivo che voglia trasmettere una trama a un coordinator semplicemente effettua la trasmissione accedendo al canale con uno

schema CSMA-CA non suddiviso in slot. Il coordinator può, se richiesto, confermare la ricezione inviando una trama di acknowledgment. Solitamente un dispositivo non

coordinator per risparmiare energia può non essere attivo ed essere in uno stato di

power-safe, in questo caso per assicurarsi la possibilità di ricevere messaggi dal coor-

18

dinator invia periodicamente delle trame di data-request. Nel caso il coordinator ab-

bia una trama da trasmettere ad un dispositivo attende che il dispositivo (periodi-camente) trasmetta una trama di data-request (eventualmente confermata). Il coor-

dinator può quindi trasmettere la trama al dispositivo, il quale, se richiesto, invierà una trama di acknowledgment per conferma. Il coordinator può in alternativa indi-

care l'assenza di dati per il dispositivo nella trama di acknowledgment della data-request frame, oppure inviando una trama dati con payload di lunghezza nulla. L'ac-

cesso al canale è anche in questo caso CSMA-CA non suddiviso in slot. Il meccanismo di accesso al canale CSMA-CA è regolato nel modo seguente. Reti

non beacon-enabled usano come detto uno schema CSMA-CA senza slot. Ogni volta che un dispositivo intende trasmettere trame dati o di comando attende per un peri-odo di backoff casuale. Se al termine del periodo di backoff il canale è libero il dispo-sitivo trasmette la trama. Se il canale è occupato il dispositivo attende per un ulte-

riore periodo di backoff prima di ritentare l'accesso al canale. Le trame di acknowle-dgment sono trasmesse senza utilizzare il meccanismo CSMA-CA (cioè immediata-

mente dopo la ricezione e la verifica della trama ricevuta). Reti beacon-enabled uti-lizzano invece un meccanismo di accesso al canale CSMA-CA a slot, in cui gli slot di backoff sono temporalmente allineati con l'inizio della trasmissione del beacon frame

(si veda la figura 2.3), e così anche gli slot dei dispositivi che ricevono il beacon-frame. Ogniqualvolta un dispositivo intende trasmettere una trama dati o di coman-

do nel CAP, si sincronizza sull'inizio del successivo slot di backoff, quindi attende un numero casuale di slot di backoff. Nel caso in cui al termine del periodo di attesa il

canale sia occupato il dispositivo attende per un nuovo numero casuale di slot di ba-ckoff. Se il canale è trovato libero il dispositivo inizia la trasmissione della trama all'inizio del successivo slot. Non seguono questo meccanismo di accesso al canale le

trame di acknowledgment e le trame di beacon. Di seguito viene descritta la struttu-ra di una trama dati.

Nella figura 2.6 si possono distinguere gli header di livello fisico e del sottolivello MAC. In particolare l'header del livello fisico è composto da un Synchronization He-

ader (SHR) e un PHY Header (PHR) che comprendono i campi seguenti:

19

- Preamble Sequence: è una sequenza di zeri utilizzata dal ricevitore per ottene-re sincronizzazione di chip e di simbolo. La sua lunghezza varia secondo lo

schema di modulazione utilizzato (nelle modulazioni a 2,4GHz è di 4Byte);

- Start Frame Delimiter: indica la fine dell’SHR e l'inizio del PHR. In tutte gli schemi di modulazione previsti eccetto le ASK (in cui è definito come simbolo speciale), l'SFD è una sequenza predefinita di 1 Byte di lunghezza;

- Frame Length: di 7 bit di lunghezza, indica il numero totale di byte contenuti nella PSDU (Physical Service Data Unit), cioè la lunghezza in byte della tra-ma di livello MAC;

- Reserved: 1 bit, riservato per usi futuri.

L'header del sottolivello MAC comprende invece un MAC Header (MHR) e un MAC Footer (MFR) con i campi seguenti:

- Frame Control (2 Byte): contiene diversi sottocampi con informazioni sul tipo di trama, formato dei campi di indirizzamento e altri flag. La tabella 2.1 mo-

stra la composizione del campo Frame Control;

- Sequence Number (1 Byte): contiene il numero di sequenza usato per associare la trama dati alla corrispondente trama di acknowledgment;

- Addressing Fields (da 4 a 20 Byte): è costituito dai campi per l'indirizzamento della sorgente (Source Address e/o Source PAN ID) e della destinazione (De-

stination Address e/ o Destination PAN ID) della trama. La modalità di indi-rizzamento utilizzata (indirizzi a 2 Byte o indirizzi IEEE a 8 Byte) e la pre-

senza di uno o entrambi i campi Source Address e Destination Address dipen-dono dalla specifica impostazione dei sotto campi Source Addressing Mode e Destination Addressing Mode del campo Frame Control;

- Auxiliary Security Header (10 o 14 Byte): specifica le informazioni necessarie per l'elaborazione delle informazioni di sicurezza associate alla trama (livello di sicurezza, cifratura del payload). È presente se il sottocampo Security Ena-bled è posto a 1;

20

- Frame Check Sequence (2 Byte): contiene un codice di controllo CRC a 16 bit, calcolato sull'MHR e sul MAC Payload.

Figura 2.3 Struttura della trama dati IEEE 802.15.4

E' da notare che la struttura della trama è variabile a seconda del tipo e delle

condizioni di funzionamento della rete. Un'ulteriore considerazione può essere fatta in merito alla sincronizzazione di reti

beacon-enabled. La specifica, come visto, definisce come la sincronizzazione debba avvenire a livello di singolo hop (cioè fra dispositivo semplice e coordinator che sono direttamente raggiungibili) e quindi per reti a stella. Nel caso di reti multi-hop con topologie ad albero o mesh non è definita alcuna metodologia per la trasmissione del

beacon-frame sulla rete e pertanto la sincronizzazione di reti multi-hop è ancora una problematica aperta.

2.2.2 Altri protocolli MAC

Lo standard IEEE 802.15.4 è stato studiato per essere utilizzato in reti WPAN gene-riche senza alcun riferimento ai dispositivi impiegati e alle applicazioni utilizzate. In

letteratura sono stati proposti dei protocolli MAC specificatamente pensati per esse-re impiegati nelle reti di sensori e quindi con caratteristiche specifiche relative ai di-spositivi e alle applicazioni per cui le reti di sensori vengono utilizzate. In questo

contesto infatti risulta essere di principale importanza il risparmio energetico e le li-mitate capacità di calcolo e memoria dei dispositivi, mentre altri aspetti come la la-

21

tenza nella consegna dei pacchetti e la suddivisione della banda in modo equo tra

tutti i dispositivi sono secondari. Gli approcci seguiti per ottenere dei miglioramenti nel consumo energetico sono

due: utilizzare dei protocolli MAC che prevedono la possibilità che vi siano collisioni e cercano di minimizzarle, oppure utilizzare protocolli di tipo TDMA che sincroniz-

zano i nodi della rete per eliminare le collisioni. Esempi di protocolli MAC con acces-so al mezzo casuale sono: T-MAC[9], S-MAC[18], B-MAC[6], C-MAC[7],

PAMAS[12]. Esempi di protocolli MAC di tipo TDMA sono invece: LEACH[19], TRAMA[17].

22

Capitolo 3

Piattaforme hardware e software utilizzate

3.1 TinyOS

TinyOS[15] è un sistema operativo open-source sviluppato dall’University of Califor-nia at Berkeley per lo sviluppo di applicazioni per Wireless Sensor Networks. A dif-ferenza dei classici sistemi operativi non possiede un nucleo (kernel) ma permette

l’accesso diretto ai componenti hardware. Inoltre, date le caratteristiche più evidenti delle WSN descritte nel Capitolo 2, opera occupando poca memoria e diminuendo il consumo della batteria.

L’accesso alla memoria avviene in modo lineare, assegnando lo spazio richiesto dalle applicazioni a tempo di compilazione, mentre i concetti di processore virtuale e

memoria virtuale non vengono implementati. La prima versione del sistema operativo è stata rilasciata nell’Ottobre del 2002 ed

è stata seguita da continui aggiornamenti fino alla versione 1.15 rilasciata nel Giu-gno 2005. Questa prima versione ha dimostrato però alcuni limiti dovuti alla strut-

tura non intuitiva e alla dipendenza troppo stretta di molti componenti che non permette il riutilizzo del codice.

Quindi, la necessità di avere a disposizione un sistema operativo più modulare ha portato allo sviluppo della versione 2.x, per la cui implementazione si è deciso di non utilizzare la versione 1.x come base ma di ridisegnarlo completamente per creare un

sistema completamente nuovo, adattabile a diverse piattaforme hardware, di più semplice comprensione e rapidamente modificabile.

In questo lavoro di tesi si è stata utilizzata la versione 2.1 del sistema operativo.

23

TinyOS è implementato in NesC un linguaggio di programmazione basato su una

logica a componenti creato per essere utilizzato nello lo sviluppo di applicazioni per sistemi embedded. Un sistema embedded, avendo delle funzionalità note già durante

lo sviluppo, potrà eseguirli grazie ad una combinazione hardware/software specifi-camente studiata per la tale applicazione riducendo lo spazio occupato ed il costo di

produzione.

3.2 Nesc

NesC[16] è un linguaggio di programmazione composto da una sintassi simile a quel-la del linguaggio C ed offre un sistema per creare ed assemblare componenti in modo modulare al fine di ottenere sistemi embedded robusti e facilmente modificabili.

Le caratteristiche principali di questo linguaggio sono:

- Separazione della costruzione e della composizione: lo sviluppo di

un’applicazione in NesC è effettuato assemblando un serie di componenti (pre-esistenti o scritti appositamente), costituiti da porzioni di codice che imple-

mentano le funzioni che verranno utilizzate per costruire l’applicazione, in modo da creare le relazioni tra le interfacce. Ogni componente, assemblato at-

traverso i file di configurazione, deve definire le specifiche del suo comporta-mento e implementare tali direttive.

- Specifiche del componente mediante interfacce: un componente deve dichiara-re sia le interfacce di altri blocchi che utilizza che quelle fornite da lui stesso,

queste ultime sono le operazioni implementate dal componente stesso e messe a disposizione agli altri. Dato che un’interfaccia descrive una serie di funzioni

(con eventuali parametri richiesti e/o restituiti) risulta molto più semplice riu-tilizzare porzioni di codice per sviluppare nuove applicazioni.

- Interfacce bidirezionali: ogni interfaccia specifica una serie di funzioni che de-vono essere implementate dal modulo che le fornisce ed un insieme di eventi

che devono essere gestiti dall’utilizzatore. Questo permette di realizzare opera-zioni complesse utilizzando una singola interfaccia.

24

- Staticità: il grafo che collega i componenti tra loro è statico e non può essere modificato durante l’esecuzione del programma. In questo modo è possibile ve-

locizzare l’esecuzione, irrobustire il codice e analizzare staticamente l’applicazione migliorando l’efficienza del compilatore.

- Concorrenza: il modello concorrenziale di NesC è compatibile con quello ca-ratteristico di TinyOS e consiste in processi che eseguono la loro attività con-

temporaneamente su dati condivisi.

Nel linguaggio NesC sono definiti tre tipi fondamentali di funzioni: i comandi, gli eventi e i task.

3.2.1 Comandi ed Eventi

Un componente può richiedere i servizi offerti da un altro, attraverso i comandi che quest’ultimo mette a disposizione.

I comandi sono simili alle funzioni e possono essere richiamati dal modulo con la primitiva call fornendo dei parametri in ingresso e ottenendo un parametro in uscita.

Come mostrato in seguito, per utilizzare un comando non è necessario conoscere i dettagli implementativi, ma è sufficiente conoscere l’interfaccia di quel comando.

La sintassi per la chiamata e l’implementazione di un comando è la seguente:

tipo_di_dato command NomeInterfaccia.nomeComando(param_richiesti) { [implementazione] return parametro_restituito; } parametro = call NomeInterfaccia.nomeComando(param_richiesti);

Tabella 3-1 Sintassi di dichiarazione e invocazione di un comando in NesC

Gli eventi invece, che sono generati da un modulo e devono essere gestiti dall’applicazione che utilizza quel modulo, rappresentano dei veri e propri gestori delle interruzioni hardware. Le interruzioni possono essere provocate da fattori e-

25

sterni come la ricezione di un messaggio, o da cause interne come lo scadere di un

timer o l’invio di un pacchetto. La sintassi degli eventi è simile a quella dei comandi con la sola differenza che devono essere segnalati (dall’utilizzatore del modulo) tra-

mite la primitiva signal:

tipo_di_dato event NomeInterfaccia.nomeEvento(param_richiesti) { [implementazione] return parametro_restituito; } parametro = signal NomeInterfaccia.nomeComando(param_richiesti);

Tabella 3-2 Sintassi di dichiarazione e segnalazione di un evento in NesC

Il tipo di concorrenza dei comandi e degli eventi può essere di tipo:

- Asynchronous (async): i comandi o eventi di questo tipo possono essere gene-

rati da interrupt hardware e la loro esecuzione inizia non appena viene scate-nato l’interrupt interrompendo tutte le altre operazioni. L’esecuzione delle o-perazioni interrotte verrà ripresa una volta terminata l’esecuzione del comando

che ne ha generato il blocco dal punto in cui era stata interrotta. Un sistema che ha la capacità di interrompere l’esecuzione di un comando per eseguirne

un altro viene chiamato preemptive.

- Synchronous (sync): è il tipo di concorrenza di default. Questo tipo di funzioni non può gestire eventi generati da interrupt hardware ma può essere chiamata solo dai task. Anche questo tipo di funzione è di tipo preemptive e quindi

l’esecuzione può essere interrotta a causa della chiamata di un altro comando synchronous o asynchronous.

3.2.2 Task

I task sono porzioni di codice che vengono eseguite senza essere bloccate dalla chia-mata di un altro comando e sono atomici, cioè sono mutuamente esclusivi sulle atti-

26

vità in corso. Quando vengono chiamati non passano subito in esecuzione ma vengo-

no inviati ad uno scheduler che li accoda e li esegue uno alla volta. Se in un certo i-stante la coda delle attività da eseguire è vuota, lo scheduler mette in stato di sleep

il processore. Questo tipo di funzione ha la capacità di attivare comandi, generare eventi o ese-

guire altri task all’interno dello stesso componente. La sintassi per la chiamata di un task (tramite la primitiva post) e della sua implementazione è la seguente:

task void nomeTask(param_richiesti) { [implementazione] } post nomeTask(param_richiesti);

Tabella 3-3 Sintassi di dichiarazione e invocazione di un task in NesC

La possibilità di usare del codice di tipo non-preemptive, come i task, permette di

essere sicuri che non vi saranno situazioni di data-race, cioè situazioni in cui un co-mando che ha provocato la sospensione dell’esecuzione di un altro accede alle stesse variabili modificandole e provocando degli errori. Data la loro caratteristica i task

devono essere il più possibile brevi perché durante la loro esecuzione il sistema ope-rativo non può rispondere agli interrupt.

3.2.3 Interfacce e Componenti

Le interfacce sono particolari file in cui vengono descritte le funzioni che devono es-sere fornite dal modulo che dichiara di implementarle e gli eventi che devono essere

gestiti da chi le utilizza. Per la loro natura permettono di ottenere un codice molto modulare e facilmente modificabile e riutilizzabile. Le interfacce (interface) sono composte dal un elenco di funzioni e di eventi, ognuno con la descrizione dei para-

metri in ingresso ed in uscita. In NesC, un componente può provvedere (provides) o utilizzare (uses) un inter-

faccia e può essere di due tipi: modulo o configurazione. I moduli (module) imple-

27

mentano i comandi dichiarati nelle interfacce che esportano e gli eventi sollevati dai

componenti che vengono utilizzati mentre le configurazioni (configuration) definisco-no il modo in cui più componenti devono essere collegati e possono a loro volta for-

nire delle interfacce. Come è stato appena descritto, per realizzare un’applicazione occorre collegare i

moduli tramite dei file di configurazione cioè attuare un’operazione di Wiring dei Componenti. Questa soluzione, che e ha come risultato logico il grafo dei componen-

ti, può sembrare complessa ma ha il grande pregio di essere modulare e quindi di permettere il riuso del codice e garantire il principio di sostituibilità.

3.3 MICAz

I mote utilizzati in questa tesi sono chiamati MICAz (Figura 3.1(a)), prodotti da Crossbow Technology[11].

La Crossbow è un’azienda americana fondata nel 1995 che fornisce sistemi di sen-sori inerziali per l’aviazione e per applicazioni in ambito militare e si occupa di

commercializzare soluzioni complete per la realizzazione di WSN. Questa azienda è anche coinvolta nello sviluppo di TinyOS.

Figura 3.1 Hardware utilizzato

I MICAz hanno dimensioni di 58 x 32 x 7 millimetri, sono alimentati da 2 batte-

rie di tipo AA e possono essere equipaggiati con sensori di diverso tipo per misurare temperatura, pressione, accelerazione, luce, campi magnetici, ecc. Questi trasduttori

costruiti sfruttando le caratteristiche di diversi materiali che variano le loro caratte-

28

ristiche elettriche al variare delle condizioni ambientali ed il valore di tensione pro-

dotto da essi viene convertito in un valore binario da un ADC. La loro ricetrasmit-tente è costituita da un unico chip radio, CC2420, in grado di svolgere tutte le fun-

zioni di livello Fisico richieste dallo standard IEEE 802.15.4. Inoltre hanno tre led (rosso, giallo e verde) che, comandati dal programma in esecuzione, permettono un

veloce riscontro visivo utile per il debug. I sensori sono composti da un microproces-sore programmabile, un Atmel AT- Mega128L, che per poter elaborare i dati e svol-

gere le funzioni di richieste ha a disposizione 128 KByte di memoria programmabile riservata per l’installazione del software e 4 KByte di memoria riservata per le va-

riabili temporanee. Per poter programmare i MICAz si è utilizzata la scheda di pro-grammazione mostrate in Figura 4.1(b) collegata direttamente al PC tramite la por-ta USB.

Si può affermare quindi che, date le dimensioni non molto ridotte, il consumo e-nergetico piuttosto alto e le limitate risorse hardware, i MICAz si adattino meglio ad

essere oggetto di studio o impiegati in semplici applicazioni su piccola scala.

29

Capitolo 4

Integrazione

4.1 MobiWSN

Il progetto MobiWSN, sviluppato presso il laboratorio di ricerca sulle reti di teleco-municazioni del Politecnico di Milano AntLab e su cui si basa questo lavoro di tesi, è nato con la volontà di realizzare l’integrazione e l’interconnessione a livello appli-

cativo di una o più WSN. Con esso è nata l’idea di creare un middleware in grado di astrarre le complessità della gestione delle reti di sensori e fornire un insieme di ser-vizi di comunicazione ad alto livello che costituiscano una base per lo sviluppo di applicazioni in modo rapido e semplificato, impiegabili in diversi scenari. Fra questi,

le maggiori possibilità di impiego che si hanno oggi sono relative allo sviluppo di controllo e monitoraggio ambientale, nonché sistemi di controllo di ambienti critici,

industriali o domestici.

4.1.1 Architettura Generale Come mostrato in Figura 4.1, l’architettura su cui si fonda questa piattaforma si

suddivide in due diverse reti: di sensori e mesh.

Le Wireless Mesh Networks (WMN) sono reti a maglie implementate tramite una rete wireless locale. Una rete a maglie è una rete di comunicazione senza fili coopera-tiva costituita da un gran numero di nodi che fungono da ricevitori, trasmettitori e

ripetitori. L’architettura tipica di una WMN è composta da un’infrastruttura di ba-ckbone, nella quale un adeguato numero di nodi detti mesh router è organizzato in una rete magliata per fornire instradamento e consegna dei pacchetti trasmessi dai client. Alcuni mesh router svolgono anche funzioni di gateway verso altri nodi o ver-

30

so Internet, questa caratteristica fondamentale costituisce una notevole evoluzione

rispetto alle architetture di rete wireless attualmente più diffuse. Infrastrutture di questo tipo inoltre, sono relativamente economiche, molto adattabili e resistenti. I

nodi fungono da ripetitori per trasmettere il segnale dai nodi più vicini ai peer (nodi equivalenti); in questo modo si ottiene una rete capace di coprire grandi distanze, specialmente su aree di difficile accesso. Le reti a maglie possono includere dispositivi

sia fissi che mobili. L’architettura su cui si basa il middleware MobiWSN ipotizza che i nodi sensore

fisicamente connessi con i mesh router svolgano la funzione di PAN Coordinator per la rete di sensori a cui appartengono, e che siano pertanto punti di concentrazione

del traffico da e verso gli altri nodi che le compongono. I mesh router equipaggiati di un gateway per le reti di sensori forniranno le funzionalità per l’integrazione con la singola WSN, avendo quindi la possibilità di compiere operazioni quali l’esplorazione

della rete, la lettura di particolari misurazioni dai sensori e la configurazione dei mo-te stessi.

Figura 4.1 Ipotesi di architettura d'integrazione MobiWSN

31

Livello di Rete e Protocollo di Routing Le caratteristiche del livello di rete sono state definite ponendo come riferimento

le funzionalità richieste dal livello middleware ed i vincoli imposti dalle caratteristi-che dei nodi della rete di sensori. Le costrizioni principali a cui si deve sottostare so-no date dalla dimensione limitata del payload a livello MAC (imposta dallo standard IEEE 802.15.4 descritto nel Capitolo 2) e dal consumo di potenza dei dispositivi, che

deve essere per quanto possibile limitato. Tali vincoli hanno portato a fare alcune considerazioni sulla possibilità di comprimere l’header di livello rete e di utilizzare

alcuni accorgimenti che consentano di evitare la trasmissione di alcuni campi impli-citamente noti.

Infine, le principali caratteristiche che il livello di rete possiede sono:

- Consegna best-effort: non è richiesto al livello di rete di garantire la consegna

di un pacchetto di destinazione (demandata ai livelli superiori);

- Eliminazione dei pacchetti duplicati;

- Indirizzamento unicast e broadcast: a livello middleware deve essere possibile indirizzare un messaggio verso un nodo specifico, oppure inviarlo a tutti i

componenti della rete;

Per quanto riguarda la soluzione di un protocollo di instradamento, al fine di ot-timizzare il consumo di energia si è cercato di evitare il più possibile il ricorso a mes-

saggi di segnalazione inviati in broadcast, o peggio ancora in flooding. L'algoritmo sviluppato utilizzerà l’indirizzamento broadcast solo per procedure sporadiche, evi-

tando di congestionare la rete all’aumentare delle dimensioni della stessa e delle rela-zioni di traffico. Il punto di forza della soluzione è nell’implementazione di un rou-ting di tipo gerarchico. In questo modo ogni volta che un nuovo nodo deve entrare a

far parte della rete invierà in broadcast un messaggio di “associazione”: le varie ri-sposte ricevute permetteranno al nodo richiedente di selezionare la proposta di asso-

ciazione che ritiene migliore, sulla base di una metrica opportuna. Queste associazio-ni verranno memorizzate dai nodi “padre” in specifiche tabelle, i quali avranno la

possibilità di determinare l’indirizzo dei nodi a loro associati, strutturando la rete in una classica topologia ad albero (di cui ne è illustrato un esempio in Figura 4.2).

32

Ogni nodo della rete può svolgere le funzioni di padre, e quindi permettere ai nuovi

nodi di associarsi. Inoltre la metodologia di assegnamento degli indirizzi sviluppata, permette l’indirizzamento implicito del PAN Coordinator, consentendo di guadagna-

re un livello di indirizzi, ma soprattutto evitando la trasmissione di un indirizzo o-gniqualvolta un pacchetto è originato o destinato al PAN Coordinator. Completata

la procedura di associazione alla rete, i nodi possiedono tutte le informazioni neces-sarie per le operazioni di routing verso un qualsiasi altro nodo della rete.

Figura 4.2 Architettura di rete MobiWSN

Livello Middleware

In MobiWSN, i gateway utilizzano un particolare protocollo di comunicazione di alto livello che astrae le complessità e le differenti tecnologie di rete utilizzate, fornendo un insieme di primitive per la comunicazione e l’interazione con la rete di sensori.

Questo ulteriore protocollo costituisce la base per la realizzazione di un middleware

33

che fornisce una visione ad alto livello della rete di sensori interconnessa al nodo ga-

teway. Lo scopo di questo middleware è quello di fornire servizi di comunicazione e funzionalità evoluti per la realizzazione di applicazioni in modo rapido e semplifica-to.

Gli scenari applicativi per i quali l’architettura è destinata richiedono la realizza-zione per le reti di sensori di opportune funzionalità di base, quali l’accesso ai dispo-

sitivi di sensing di cui ogni componente è equipaggiato, la possibilità di effettuare operazioni di lettura/scrittura su uno o più sensori, il poter configurare i vari nodi per la trasmissione dei dati raccolti verso il PAN Coordinator della rete, ecc. Chia-

ramente, particolare attenzione in fase di sviluppo è stata posta anche nel realizzare il protocollo di comunicazione, al fine di ottimizzare il traffico fra i dispositivi della

rete di sensori ed il gateway. A prescindere dalle funzionalità fornite la soluzione possiede alcuni requisiti non

funzionali, fra i quali i più importanti sono sicuramente la scalabilità e

l’espandibilità. Infatti MobiWSN consente l’implementazione in modo rapido dei componenti per interfacciarsi verso i nuovi tipi di mote e/o sensori, e la possibilità

di sviluppare componenti aggiuntivi per la definizione di nuove funzionalità. Verrà ora posta particolare attenzione all’implementazione di MobiWSN sulla rete

di sensori, essendo questa la parte utilizzata per lo sviluppo del lavoro di questa tesi.

4.1.2 Implementazione MobiWSN sulla rete di sensori I dispositivi utilizzati nella rete di sensori hanno capacità computazionali limitate

e non consentono di utilizzare un modello di programmazione orientato agli oggetti, come Java o C++, per rappresentare mote e sensori. TinyOS (come descritto nei

precedenti paragrafi) fornisce un modello di sviluppo basato principalmente sulla de-finizione di interfacce, di moduli che forniscono o utilizzano queste interfacce e di

configurazioni, cioè componenti in grado di effettuare i collegamenti fra i vari modu-li. In questo scenario implementativo è perciò particolarmente interesse osservare la struttura e l’organizzazione dei componenti principali di cui MobiWSN si compone, i

cui collegamenti sono mostrati in una versione semplificata in Figura 4.3.

34

Figura 4.3 Componenti principali del lato sensori dell'architettura MobiWSN

Livello Network

Tra i principali moduli che strutturano il livello di rete c'è un modulo, chiamato

ForwardingManagerP, il quale svolge la funzione di inoltro delle trame ricevute dal livello MAC sottostante e non destinate al nodo. Inoltre questo modulo svolge la

funzione aggiunta per il controllo della ricezione di pacchetti duplicati ed implemen-ta una coda per la memorizzazione dei pacchetti da inviare per la gestione degli er-

rori e dei conseguenti tentativi di ritrasmissione di un pacchetto. Questo componente costituisce la base per l’implementazione del livello di rete.

Il modulo NetworkP, nel quale sono dichiarate le primitive per l’invio di un mes-saggio, genera gli eventi di ricezione di pacchetti dai livelli inferiori. Per questo mo-

tivo il modulo utilizza i servizi forniti da NetworkManagerP, nel quale è implementa-to un protocollo di instradamento gerarchico basato sull’architettura ad albero scelta

(HAT, Hierarchical Addressing Tree). La gestione degli indirizzi di rete da assegnare

è realizzata nel modulo AddressP: in esso si implementano le regole di indirizzamen-to gerarchico descritte in precedenza e vengono definiti anche i possibili stati in cui un nodo può trovarsi nelle varie fasi di associazione alla rete. Il numero ed il valore di tali indirizzi è determinato da alcuni parametri che regolano i livelli di profondità

nell’albero in cui si trova il nodo.

Middleware

Group

Network

35

Livello Group

La parte alle associazioni dei nodi in gruppi di lavoro si basa principalmente sul mo-

dulo GroupManagerC, il quale fornisce le interfacce essenziali per l’invio dei messag-gi in multicast (indirizzati ad un particolare gruppo di nodi), per il recupero delle in-

formazioni di gruppo di ogni mote e per le aggregazioni ed il raggruppamento dei nodi.

L’aspetto relativo all’analisi dei meccanismi di scambio dei messaggio, nonché la loro struttura, oltre a quello relativo all’utilizzo e la gestione dei sensori sono stati

preziosi oggetti di studio per l’implementazione del sistema di rilevazione di presenza descritto in seguito, su cui questo lavoro di tesi si concentra.

Livello Middleware

In questo livello il modulo primario è sicuramente MiddlewareP, il quale fornisce la

logica principale per la gestione dei messaggi di alto livello. Inoltre, il collegamento

con la configurazione GroupC, garantisce l’interfacciamento ai componenti che im-plementano il livello network ed il protocollo di routing. Questo livello riceve i mes-

saggi da quello di rete (tramite il livello Group) e dalla porta seriale (cioè i messaggi provenienti dal gateway) ed in base al tipo di messaggio ricevuto richiama il relativo

componente di gestione dei messaggi di livello middleware, sia che essi siano messag-

gi di richiesta di invio delle informazioni sul nodo (MoteDiscovery), le relative rispo-

ste (MoteAnnoucement), la perdita di connessione con un vicino (MoteLoss) o mes-

saggi per le operazioni di lettura dai sensori di cui un mote è equipaggiato (Sensor-Read e SensorRead Response).

Il protocollo che gestisce lo scambio di informazioni fra la rete di sensori ed il ri-

spettivo gateway, chiamato IEP (Information Exchange Protocol), è un protocollo di tipo richiesta-risposta che definisce quattro principali tipologie di messaggi:

- Request: contenente una richiesta di informazioni

- Response: contenente una risposta ad una precedente richiesta

- Command: contenente una configurazione o un’operazione da eseguire

36

- Information: contenente informazioni destinate ad uno o più mote della rete.

La struttura dei messaggi del protocollo IEP, mostrata in Figura 5.4, è composta

dai campi:

- SourceId: identifica il mote sorgente

- DestinationId: identifica il destinatario

- GroupId: identifica il gruppo di mote a cui il messaggio è destinato (se pari a zero segnala che non è un messaggio di gruppo)

- MessageType: identifica il tipo di messaggio inviato (MoteDiscovery, MoteAn-noucement, MoteLoss, SensorRead o SensorReadResponse)

- MessageId: identifica univocamente il messaggio inviato

- CorrelationId: nel caso di risposte identifica la precedente richiesta

Figura 4.4 Struttura messaggio IEP

L’interazione con i sensori montati sui dispositivi di rete viene effettuata tramite

il modulo SensorManagerC, che fornisce l’interfaccia di accesso all’elenco e al tipo di sensori installati, oltre ad un’interfaccia generica per le operazioni di lettura dei pa-rametri misurati da un particolare sensore. Per le operazioni di sensing, i messaggi di

tipo SensorRead richiedono la lettura puntuale di un determinato sensore, specificato da un identificativo definito in modo statico per tutti i mote della rete, consentendo

37

così di inviare in rete un singolo messaggio anche nel caso sia necessaria la lettura di

un particolare sensore su tutti i nodi della rete.

4.2 Verifica di fattibilità

Lo scopo principale di questo lavoro è quello di adattare al livello network esistente dell’architettura MobiWSN un protocollo di livello MAC con caratteristiche specifi-che relative ai dispositivi e alle applicazioni per cui le reti di sensori vengono utiliz-

zate. In questo contesto infatti risulta essere di principale importanza il risparmio energetico e le limitate capacità di calcolo e memoria dei dispositivi.

TinyOS fornisce un’astrazione di base del livello MAC introducendo il concetto di

Active Message (AM), un pacchetto trasmesso ad un hop di distanza in modo non affidabile. Gli Active Message hanno un indirizzo di destinazione, vengono riscontra-

ti in modo sincrono (tranne ovviamente i pacchetti inviati in broadcast locale) e pos-sono avere un payload di lunghezza variabile. Active Message però esclude la gestio-

ne di problematiche quali il risparmio energetico tramite l’adozione di diversi stati di attività (sleep, active) che permettono l’accensione e lo spegnimento della radio in

istanti programmati in modo da ridurre al minimo il consumo di energia. Per questo si è reso necessario sostituire ad Active Message un protocollo di livello MAC più

avanzato, che includa anche una soluzione alla gestione di questo tipo di problemati-che.

Lo standard IEEE 802.15.4 è stato studiato per essere utilizzato in reti WPAN

generiche senza alcun riferimento ai dispositivi impiegati e alle applicazioni utilizza-

te, nel caso specifico dello scenario beacon-enabled esso oltre ad includere una ge-stione degli stati di attività della radio completamente automatica e trasparente ai

livelli superiori, che permette un notevole risparmio in termini di energia, consente di usufruire di una serie di funzionalità che si rivelano di notevole importanza per la

gestione di tutte le operazioni a livello network. La maggior parte delle problematiche d’integrazione riguardano l’adattabilità del

livello MAC 802.15.4 agli scopi del livello network. In questo caso il protocollo di routing utilizzato HAT prevede un’organizzazione della rete secondo una topologia

ad albero ad indirizzamento gerarchico (Figura 4.5).

38

Di seguito vengono illustrate le principale operazioni svolte dal livello MAC

802.15.4 per la creazione di una rete ad albero in uno scenario di tipo beacon-enabled.

Una rete WPAN IEEE 802.15.4 è composta principalmente da un PAN coordina-tor e da un serie di altri dispositivo ad esso associati. Il PAN coordinator è il gestore

primario della rete, è responsabile del processo di inizializzazione della rete e può es-sere alimentato da corrente. A seconda delle loro capacità e delle risorse disponibili i

dispositivi IEEE 802.15.4 possono essere full-function devices (FFD), in grado di

comunicare con qualsiasi tipo di dispositivo all’interno della rete, o reduced-function devices (RFD), in grado di comunicare solo con altri FFD. Per quanto riguardo la formazione della topologia di rete, lo standard IEEE 802.15.4 definisce i meccanismi a supporto del PAN coordinator nella selezione, all’avvio del dispositivo, del canale

radio da utilizzare, e una procedura, che permette agli altri dispositivi di unirsi alla rete. Un PAN coordinator che desideri creare una nuova rete sceglie, secondo una

logica che la specifica IEEE 802.15.4 non copre, il canale radio su cui effettuare tutte le successive operazioni.

Figura 4.5 Topologia di rete prevista dal protocollo HAT

39

Le operazioni fondamentali svolte da un qualsiasi altro dispositivo per trovare una

rete WPAN esistente e per unirsi ad essa sono riassunte come segue:

- Ricerca di tutte le reti WPAN disponibili attraverso una scansione di tutti i canali radio

- Scelta della rete WPAN a cui unirsi (la logica che porta alla selezione di una rete rispetto ad un’altra non è coperta dalla specifica IEEE 802.15.4)

- Avvio della procedura di associazione al PAN coordinator o un dispositivo

FFD già associato alla rete, che definiremo semplicemente coordinator.

Nel caso di una rete beacon-enabled tutti i dispositivi FFD, oltre al PAN coordi-nator, già associati alla rete trasmettono periodicamente delle trame di beacon che contengono tutte le informazioni necessarie per associarsi alla rete. Un dispositivo

che intende associarsi si mette in ascolto su tutti i canali radio e appena riceve una trama di beacon ne estrae tutte le informazioni necessarie. Una volta effettuata la

scansione di tutti i canali radio, una lista di tutte le reti WPAN disponibili è usata dal dispositivo per scegliere la rete con cui provare l’associazione. Scelta la rete il di-spositivo invia una richiesta di associazione al coordinator, il quale con un messaggio

di risposta accetta la richiesta di associazione e assegna, secondo una logica non de-finita dalla specifica, un indirizzo al dispositivo.

Figura 4.6 Struttura generica di una rete WPAN organizzata secondo una topologia di tipo cluster-tree

40

Il risultato di questa procedura è un serie di relazioni di associazione, tra un FFD

e un FFD o tra un FFD e un RFD, di tipo padre-figlio. Questa topologia generale è definita cluster-tree[3]. La totalità di queste associazioni forma un albero alla cui ra-

dice sta il PAN coordinator. I vari coordinator dei cluster, già associati al PAN co-ordinator o ad altri coordinator, formano a loro volta delle strutture ad albero più

semplici, ed agiscono come router di pacchetti dati tra dispositivi diversi. In questo modo ogni router rappresenta un punto di associazione alla rete per altri rou-

ter/coordinator e un numero di dispositivi finali (RFD) che non partecipano alle o-perazioni di instradamento.

In questo modo si ottiene una struttura ad albero che si adatta perfettamente alla topologia di rete richiesta dal livello network e che permette una gestione ottimale per l’instradamento dei pacchetti.

Dal punto di vista del livello MAC 802.15.4 l’unico vincolo a cui deve sottostare il livello network è dato dalla dimensione limitata del payload, che per la specifica

IEEE 802.15.4 è di 127 Byte, compreso l’header e il CRC. Requisito già garantito dalle specifiche progettuali del livello network esistente, che assicura, oltre ad una

particolare logica di compressione dell’header in favore di una maggiore disponibilità di byte per il payload, una dimensione della trama di rete minore della dimensione

massima concessa per il payload di livello MAC.

Figura 4.7 Netwok Header e dettaglio del Control Field

41

Osservando in Figura 4.4 si nota come la massima dimensione dell’header di livel-

lo network è di 8 Byte a cui segue un payload di lunghezza variabile fino ad un mas-

simo stabilito dalla costante NWK_PAYLOAD_LENGTH.

Figura 4.8 Formato della trama MAC 802.15.4

Esaminando adesso il formato della trama MAC 802.15.4 (Figura 4.5) notiamo

come la sua dimensione sia fortemente condizionata dalla dimensione dell’Addressing field e dell’Auxiliary Security Header. Nel caso peggiore, cioè con un Addressing field

di 20 Byte e un Auxiliary Security Header di 14 Byte, dei 127 Byte di lunghezza massima dell’intera trama rimangono a disposizione del payload 88 Byte, che corri-

spondono alla lunghezza massima della trama di livello network. Alla luce di questi dati si arriva subito a calcolare che per rispettare questo vincolo la dimensione del payload di livello network, e quindi il valore della costante

NWK_PAYLOAD_LENGTH, dovrà essere inferiore a 80 Byte. Questa costante è al momento fissata, per ragioni che non verranno illustrate in questo lavoro, a 50 Byte, il che garantisce sempre che l’intera trama di livello MAC sia inferiore al limite di

127 Byte. Alla luce di quanto esaminato fin’ora si può concludere affermando che è possibile

un’integrazione del livello MAC 802.15.4 con il livello network esistente poiché gli unici due requisiti progettuali sono ottemperati. Il primo, imposto dal livello di rete,

richiede un’analogia con il livello inferiore delle relazioni di associazione descritte dalla topologia di rete. Cioè bisogna che siano garantiti a livello MAC i canali di

comunicazione così come sono tracciati dal protocollo di routing HAT. E come ab-biamo dimostrato il meccanismo stesso delle associazioni tra i dispositivi e i coordi-

!"""#$%&'()*+,*-.)((/ 01230&345&6"781910!734&38"3&4"7:18;#<9387&+,*-=

!"# 2>?@ABCD$&E&)((/&!"""*&3FF&ABCD$G&AHGHAIH%*

$%&'()*+,-&*-*./&'$(*%0+(+*-)(*.(&+*+%*+,(*123*/&*+,(*%)4()*5)%6*+,(*%0+(+*0%&+-/&/&'*+,(*$%7(.+*&869()(4*9/+.+%*+,(*%0+(+*0%&+-/&/&'*+,(*,/',(.+*&869()(4*9/+.:

;%)*(<()=*>?@*5)-6(A*-$$*)(.()<(4*9/+.*.,-$$*9(*.(+*+%*B()%*8C%&*+)-&.6/../%&*-&4*.,-$$*9(*/'&%)(4*8C%&)(0(/C+:

!"#"$%&'(')*+%,-.%/)*0'%/1)0*2

D,(*>?@*5)-6(*5%)6-+*/.*0%6C%.(4*%5*-*>2EA*-*>?@*C-=$%-4A*-&4*-*>;E:*D,(*5/($4.*%5*+,(*>2E*-CC(-)/&*-*5/F(4*%)4()G*,%7(<()A*+,(*-44)(../&'*5/($4.*6-=*&%+*9(*/&0$84(4*/&*-$$*5)-6(.:*D,(*'(&()-$*>?@*5)-6(.,-$$*9(*5%)6-++(4*-.*/$$8.+)-+(4*/&*;/'8)( H!:

!"#"$"$%3)*0'%.1(2)1+%/4'+5

D,(*;)-6(*@%&+)%$*5/($4*/.*I*%0+(+.*/&*$(&'+,*-&4*0%&+-/&.*/&5%)6-+/%&*4(5/&/&'*+,(*5)-6(*+=C(A*-44)(../&'5/($4.A*-&4*%+,()*0%&+)%$*5$-'.:*D,(*;)-6(*@%&+)%$*5/($4*.,-$$*9(*5%)6-++(4*-.*/$$8.+)-+(4*/&*;/'8)( HI:

!"#"$"$"$%3)*0'%678'%9:;/4'+5

D,(* ;)-6(*D=C(* .895/($4* /.* "* 9/+.* /&* $(&'+,* -&4* .,-$$* 9(* .(+* +%* %&(* %5* +,(* &%&)(.()<(4* <-$8(.* $/.+(4* /&D-9$( JK:

!"#"$"$"#%<'=:)427%>(*;+'5%9:;/4'+5

D,(*L(08)/+=*M&-9$(4*.895/($4*/.*!*9/+*/&*$(&'+,A*-&4*/+*.,-$$*9(*.(+*+%*%&(*/5*+,(*5)-6(*/.*C)%+(0+(4*9=*+,(>?@*.89$-=()*-&4*.,-$$*9(*.(+*+%*B()%*%+,()7/.(:*D,(*?8F/$/-)=*L(08)/+=*2(-4()*5/($4*%5*+,(*>2E*.,-$$*9(C)(.(&+*%&$=*/5*+,(*L(08)/+=*M&-9$(4*.895/($4*/.*.(+*+%*%&(:

!"#$#%&'( ) *+( *+(+, *+( *+(+, *+-+.+)*+

)/ 0123145$ (

;)-6(@%&+)%$

L(N8(&0(O869()

P(.+/&-+/%&1?OQ4(&+/5/()

P(.+/&-+/%&?44)(..

L%8)0(1?OQ4(&+/5/()

L%8)0(?44)(..

?8F/$/-)=L(08)/+=2(-4()

;)-6(1-=$%-4

;@L

?44)(../&'*5/($4.

>2E >?@1-=$%-4

>;E

34?:)'%@$A&'(')*+%,-.%/)*0'%/1)0*2

63#%&'*7( 8 / - . 97: )*7)) )(7)8 )/7)-

;)-6(D=C(

L(08)/+=M&-9$(4

;)-6(1(&4/&'

?0R:E(N8(.+

1?O*QP@%6C)(../%&

E(.()<(4 P(.+:?44)(../&'>%4(

;)-6(S()./%&

L%8)0(?44)(../&'>%4(

34?:)'%@#A31)0*2%1/%2B'%3)*0'%.1(2)1+%/4'+5

42

nator garantisce la formazione di una topologia ad albero del tutto analoga a quella

richiesta. Il secondo vincolo, imposto dal livello inferiore, riguardo la dimensione massima dell’intera trama di livello MAC 802.154, fissata a 127 Byte è, come ab-

biamo visto, facilmente dimostrato essere sempre rispettato. A questo punto bisogna procedere con il lavoro d’implementazione vero e proprio

della soluzione proposta, lavoro tutt’altro che semplice ma ampiamente giustificato dai vantaggi che ne derivano.

4.3 Vantaggi apportati

Una volta verificata la possibilità di adattare il protocollo di livello MAC 802.15.4 al livello network esistente a discapito del più basilare Active Message si rende chiaro

come questa soluzione comporti principalmente 3 vantaggi:

- Gestione degli stati di attività della radio completamente automatica e inte-ramente trasparente per i livelli superiori.

- Procedure di associazione alla rete estremamente semplificate per il livello

network.

- Eliminata la necessità di aggiungere un ulteriore header alla trama di livello network per la gestione dei pacchetti duplicati tramite sequence number.

Il livello MAC 802.15.4 fornisce ai livelli superiori solo le primitive per la gestione della trasmissione/ricezione di trame dati e di tutte quelle operazioni di manteni-

mento della rete quali associazione al PAN coordinator, generazione dei beacon da parte dei coordinator, sincronizzazione alla supertrama etc. Esclude invece possibilità di controllo diretto della radio da parte dei livelli superiori. Questo poiché l’intera

gestione degli stati di attività e modalità di funzionamento (trasmissione/ricezione) è interamente regolata a livello fisico (radio driver) dalla specifica IEEE 802.15.4, che

programma l’accensione e lo spegnimento della radio in istanti ben definiti, solo

quando necessario. Come ad esempio nel caso di una rete beacon-enabled, i dispositi-vi associati e sincronizzati ad un coordinator accendono la radio in modalità ricezio-

ne solo negli istanti di beacon oppure utilizzano la radio in modalità di trasmissione

43

solo nel caso in cui vi sia effettivo bisogno di inviare dati al coordinator. Al contrario

invece del livello Active Message che non offre nessun meccanismo automatico di ge-stione della radio, la quale se non opportunamente controllata risiede costantemente

in stato di ricezione, con un derivante consumo smisurato di energia. L’utilizzo inve-ce di un meccanismo automatico di gestione della radio programmata, come specifi-

cato dallo standard IEEE 802.15.4, permette, in configurazioni particolari beacon-enabled con periodi di supertrama abbastanza lunghi, un consumo di energia ridot-tissimo, che garantisce al mote autonomia per mesi se non addirittura anni.

Com’è stato descritto nel paragrafo precedente, il meccanismo di associazione e le

relative relazioni padre-figlio che ne derivano permettono di costruire un topologia di rete perfettamente analoga a quella richiesta dal livello network. Questo permette di

utilizzare le risorse fornite dal livello MAC 802.15.4 per la gestione delle associazioni al livello superiore. Si può cioè eliminare dalla logica applicativa del protocollo di routing HAT tutta la parte relativa allo scambio di messaggi che regolano il processo

di associazione (Association Request, Association Response etc.) e sfruttare quella già implementata a livello MAC 802.15.4. In questo modo l’unico compito che viene

lasciato al protocollo di routing è la decisione del nodo a cui associarsi secondo una funzione di costo ben definita e richiedere al livello inferiore di completare il processo

di associazione. Per questo sarà dovere del livello MAC 802.15.4 fornire una lista di tutti i nodi sufficientemente vicini accompagnata dai relativi parametri necessari a

definire il costo del collegamento (es. distanza intesa come numero di hop dal PAN coordinator, qualità del canale in termini di SNR etc.).

Il livello network esistente implementa anche un meccanismo di soppressione dei pacchetti duplicati. La duplicazione di un pacchetto può avvenire nel caso in cui a livello MAC venga correttamente ricevuta la trama ma si verifichi un errore nella ri-

cezione dell’ACK. In questo caso è richiesto che i pacchetti duplicati vengano scarta-ti. Questo meccanismo è al momento realizzato utilizzando un piccolo header ag-

giuntivo di 1 Byte contenente un sequence number posto fra il livello network e il livello Active Message. Adottando il livello MAC 802.15.4 non risulta più necessario

aggiungere questo header intermedio in quanto è possibile utilizzare direttamente il sequence number della trama MAC 802.15.4.

44

4.4 TKN15.4

TKN15.4 è un’implementazione platform-indipendent del livello IEEE 802.15.4 MAC per la versione 2.1 del sistema operativo TinyOS sviluppata dal “Telecommunication

Networks Group” della “Technical University Berlin”[4]. Anche se il progetto è ancora in fase di sviluppo l’architettura del TKN15.4 forni-

sce un’implementazione della maggior parte della funzionalità descritte nello stan-

dard e definisce inoltre le interfacce di collegamento tra i livelli di rete, MAC e fisico (radio driver). Allo stato attuale dello sviluppo mancano le funzionalità di gestione

del GTS, i servizi di sicurezza, servizi di notifica/risoluzione dei conflitti del PAN ID e alcune opzioni del trasferimento dati indiretto. Il progetto si basa su tre obbiettivi

fondamentali: indipendenza dalla piattaforma (MICAz, TelosB, iMote etc.), modula-rità, estensibilità. Poiché l’implementazione del livello fisico dipende dalla piattafor-

ma/chip questa non è parte del progetto. I motivi che hanno portato alla scelta del TKN154 come implementazione di base

del livello 802.15.4 MAC per questo lavoro sono essenzialmente due:

- Esistono poche implementazioni open-source del livello 802.15.4 MAC su piat-taforma TinyOS 2.x e TKN154 rappresenta senza dubbio la migliore in qualità

di usabilità, completezza e documentazione a corredo. Un’altra implementa-zione nota è quella sviluppata come parte del progetto “Open ZigBee”[13],

progetto che si occupa di creare un’implementazione open-source di tutto lo stack protocollare ZigBee[20]. In contrasto al TKN154 open-ZB è costruito su un’architettura monolitica, in cui tutto il livello MAC è contenuto in un singo-

lo componente che inoltre non presenta alcun tipo di documentazione.

- TKN154 è stato recentemente scelto come base di partenza per il “TinyOS 15.4 WG”[14], working group il cui obbiettivo è quello di creare e mantenere

un’implementazione platform-indipendent fedele alla specifica IEEE 802.15.4-2006, disponibile su tutte le piattaforme supportate da TinyOS, incluso

TOSSIM (piattaforma di simulazione).

45

4.4.1 Componenti dell’architettura

Tutti i file (componenti, interfacce e configurazioni) necessari al funzionamento del TKN154 vengono forniti con il pacchetto di TinyOS 2.x e si trovano nella cartella /tos/lib/mac/tkn154/. La Figura 4.1 mostra una panoramica di tutti i componenti

principali (riquadri arrotondati) e delle interfacce (frecce) usate per scambiare le trame MAC attraverso i vari componenti.

Figura 4.9 Architettura del TKN15.4

46

Componenti Funzioni [Primitive IEEE 802.15.4 fornite] AssociateP BeaconTransmitP Beacon-SynchronizeP CoordBroadcastP CoordRealignmentP DataP DisassociateP DispatchQueueP DispatchSlottedCsmaP DispatchUnslottedCsmaP IndirectTxP PibP PollP PromiscuousModeP Radio-ClientC RadioControlImplP RadioControlP RxEnableP ScanP SimpleTransferArbiterP TKN154BeaconEnabledP TKN154NonBeaconEnabledP

associazione al PAN [MLME-ASSOCIATE,MLME-COMM-STATUS] trasmissione periodica dei beacon [MLME-START] sincronizzazione [MLME-SYNC(-LOSS), MLME-BEACON-NOTIFY] trasmissione di trame broadcast del coordinator comandi di riallineamento [MLME-ORPHAN, MLME-COMM-STATUS] accodamento trame dati per l’invio [MCPS-DATA, MCPS-PURGE] disassociazione dal PAN [MLME-DISASSOCIATE] coda d’invio per le trame dati/command tx/rx trame durante CAP (non include l’algoritmo CSMA-CA) tx/rx trame in scenari beacon-less (excluding the CSMA-CA algorithm) gestione delle trasmissioni dati indirette gestione del informazioni del PIB [MLME-RESET, MLME-GET, MLME-SET] richiesta dati ad un coordinator [MLME-POLL] attiva/disattiva promiscuous mode virtualizzazione accesso a RadioControlP gestisce l’accesso alla radio configurazione per RadioControlImplP attivazione della radio durante i perdiodi di inattività [MLME-RX-ENABLE] scansione dei canali radio [MLME-SCAN] gestione della “resource radio” MAC configurazione usata in beacon-enabled PAN MAC configurazione usata in beacon-less PAN

Tabella 4-1 Componenti del TKN15.4

In basso, il componente RadioControlP gestisce l’accesso alla radio, mentre i componenti in mezzo (riquadri grigio chiaro) rappresentano le differenti parti della

supertrama 802.15.4. BeaconTransmitP e BeaconSynchronizeP sono responsabili del-

la trasmissione e ricezione dei beacon, DispatchSlottedCsmaP gestisce la trasmissio-

ne/ricezione delle trame durante il CAP mentre i componenti NoCo-ordCfpP/NoDeviceCfpP sono responsabili del CFP. In uno scenario beacon-less la

struttura di supertrama non è utilizzata e questi componenti sono sostituiti da Di-spatchUnslottedCsmaP che è responsabile della trasmissione/ricezione delle trame in questa modalità.

I componenti in alto forniscono al livello superiore i restanti servizi di trasmissio-

ne/ricezione dati e di gestione, cioè implementano le primitive MCPS (MAC com-mon part sublayer) e MLME (MAC sublayer management entity) fondamentali per la gestione di operazioni quali l’associazione al PAN coordinator, la scansione dei ca-nali radio o l’invio diretto/indiretto di trame dati.

47

A seconda dello scenario (beacon-enabled/beacon-less) il livello superiore può ac-

cedere ai servizi di livello MAC attraverso le configurazioni TKN154BeaconEnabledP oppure TKN154NonBeaconEnabledP. Queste configurazioni sono responsabili del “wiring” dei vari componenti del TKN154 e forniscono al livello superiore tutte le in-

terfacce necessarie per la gestione del livello 802.15.4 MAC.

4.4.2 Definizione delle interfacce

La specifica 802.15.4 definisce 17 primitive per il livello MAC e 6 per il livello fisico.

TKN154 modifica leggermente le primitive di livello MAC per meglio adattarsi alla caratteristiche di TinyOS 2.

TinyOS 2.x non supporta l’allocazione di memoria dinamica poiché tutta la me-moria viene allocata al momento della compilazione, il che permette di generare co-dice maggiormente ottimizzato. Ciò vale anche per l’allocazione del buffer dei mes-

saggi: un componente che vuole inviare un pacchetto è responsabile dell’allocazione

di un buffer di tipo message_t, che è l’astrazione di TinyOS 2.x utilizzata dai proto-colli di livello network e superiori per rappresentare una trama dati. Conseguente-

mente TKN154 ri-adatta le primitive di livello MAC affinché supportino i buffer di

tipo message_t e le relative operazioni di swapping. Questo è di notevole importanza

per due primitive in particolare: MCPS-DATA e MLME-BEACON-NOTIFY.

interface MCPS_DATA { command ieee154_status_t request (message_t *frame, uint8_t payloadLen, uint8_t msduHandle, uint8_t TxOptionts); event void confirm (message_t *frame, uint8_t msduHandle, ieee154_status_t status, uint32_t Timestamp); event message_t* indication (message_t* frame); } interface MLME_BEACON_NOTIFY { event message_t* indication (message_t *beaconFrame); }

Tabella 4-2 Dichiarazione delle interfacce MCPS-DATA e MLME-BEACON-NOTIFY

48

In contrasto con le primitive descritte nella specifica IEEE 802.15.4, queste inter-

facce non trasportano esplicitamente informazioni di controllo (indirizzo sorgen-te/destinazione della trama, etc.). Piuttosto, queste informazioni sono contenute nel-

la trama di tipo message_t e possono essere configurate/recuperate attraverso delle

funzioni dedicate specificate nell’interfaccia IEEE154Frame, il che è in linea con la

politica con cui vengono trattate le astrazioni di tipo message_t in TinyOS 2.x. Tut-

te le altre primitive MLME/MCPS sono invece descritte esattamente dalle relative interfacce secondo la specifica IEEE 802.15.4, con un’eccezione: poiché solitamente è

più conveniente per il chiamante, le primitive MLME-GET/SET forniscono tanti comandi quanti sono i parametri da recuperare o impostare (non sono cioè split-

phase), inoltre l’accesso al payload del beacon in un coordinator non avviene attra-

verso il PIB (PAN Information Base) ma attraverso un’interfaccia separata

(IEEE154TxBeaconPayload). Per una migliore comprensione del ruolo di ognuna di queste primitive si faccia riferimento al paragrafo 5.3.

TKN15.4 richiede essenzialmente che il componente di gestione della radio (cioè il

protocollo di livello fisico) fornisca le seguenti 6 interfacce: RadioRx, RadioTx, Ra-dioOff, UnslottedCsmaCa, SlottedCsmaCa e EnergyDetection. Queste interfacce de-scrivono le seguenti operazioni: attivazione della radio in modalità ricezio-

ne/trasmissione; spegnimento della radio; trasmissione dati attraverso l’algoritmo (un)slotted CSMA-CA; rilevazione della massima energia di una dato canale radio

lungo un certo periodo di tempo.

49

interface RadioRx { async command error_t enableRx(uint32_t t0, uint32_t dt); async event void enableRxDone(); async command bool isReceiving(); event message t* received(message t *frame, const ieee154_timestamp_t *timestamp); } interface RadioTx { async command error_t transmit(ieee154_txframe_t *frame, const ieee154_timestamp_t *t0, uint32_t dt); async event void transmitDone(ieee154_txframe_t *frame, const ieee154_timestamp_t *timestamp, error_t result); } interface RadioOff { async command error_t off(); async event void offDone(); async command bool isOff(); } interface UnslottedCsmaCa{ async command error_t transmit(ieee154_txframe_t *frame, ieee154_csma_t *csma); async event void transmitDone(ieee154_txframe_t *frame, ieee154_csma_t *csma, bool ackPendingFlag, error_t result); } interface SlottedCsmaCa{ async command error_t transmit(ieee154_txframe_t *frame, ieee154_csma_t *csma, const ieee154_timestamp_t *slot0Time, uint32_t dtMax, bool resume, uint16_t remainingBackoff); async event void transmitDone(ieee154_txframe_t *frame, ieee154_csma_t *csma, bool ackPendingFlag, uint16_t remainingBackoff, error_t result); } interface EnergyDetection { command error_t start(uint32_t duration); event void done(error_t status, int8 t maxEnergyLevel); }

Tabella 4-3 Interfacce di livello fisico del TKN154

50

Capitolo 5

Implementazione

Partendo dall’analisi progettuale descritta nel capitolo precedente riguardo l’integrazione del protocollo di livello MAC 802.15.4, ci si concentra ora sulla parte

di lavoro che riguarda l’effettiva implementazione di quei moduli che permettono l’interazione tra i due livelli, approfondendo le funzioni contenute in ciascun compo-

nente e sottolineando le differenze rispetto all’organizzazione originale di tutta l’architettura del livello di rete esistente.

Il lavoro da me eseguito non permette al momento di ottenere un’integrazione to-tale del livello MAC 802.15.4, soprattutto per quanto riguarda la formazione di una

topologia di rete ad albero analoga a quella tracciata dal protocollo di routing HAT, requisito fondamentale per l’instradamento dei pacchetti nella rete. Questo lavoro si occupa dunque di ridefinire le logiche di inoltro dei pacchetti dal livello network a

quello MAC 802.15.4, implementato dall’architettura TKN154 illustrata nel capitolo precedente. La totale integrazione dei due strati richiederebbe una completa riscrit-

tura nel livello network, utilizzando in modo ottimale tutte le primitive offerte dal livello MAC 802.15.4 per la creazione dei nodi, la gestione delle procedure di associa-

zione e la conseguente istituzione dei canali di comunicazione parallela a quella dise-gnata dal protocollo di routing.

Il lavoro svolto si occupa della riscrittura del componente ForwardingManager, rinominato ForwardingManager154P, che svolge le operazioni di ricezione e invio ef-fettivo dei pacchetti di livello network tramite le primitive fornite dal livello MAC 802.15.4 con la relativa gestione delle code di ritrasmissione ed esclusione dei pac-

chetti duplicati. Dovendo testare l’effettivo funzionamento del componente, ma non potendo creare una topologia di rete complessa per i motivi elencati precedentemen-

te si è rilevato necessario creare un altro componente, StartManager154P, incaricato

alla creazione e al mantenimento di una rete IEEE 802.15.4 in modalità beacon-

51

enabled formata da un PAN coordinator è da un numero indefinito di dispositivi RFD.

Le principali difficoltà incontrate durante lo sviluppo della soluzione proposta de-rivano dall’impossibilità di eseguire procedure di debug avanzate, in quanto al mo-

mento la versione attuale TinyOS non permette la simulazione tramite TOSSIM di operazioni così a basso livello. TOSSIM è un tool di simulazione molto utile per il

debugging delle applicazioni sviluppate per TinyOS. Questo simulatore è stato però sviluppato ad alto livello per renderlo indipendente dalla piattaforma hardware uti-

lizzata. TOSSIM quindi fornisce un sistema di debugging per le applicazioni di alto livello ma risulta impossibile utilizzarlo per lo sviluppo dei moduli dei livelli inferiori

come appunto quello di cui si occupa questo lavoro di tesi. Gli unici strumenti di debugging che è stato possibile utilizzare per questo lavoro sono stati:

- Sistema di 3 led presente sui mote MICAz: come descritto al paragrafo 3.3 i

mote MICAz presentano un sistema di 3 led (rosso, verde, giallo) il cui con-

trollo è regolato dal componente LedsC, fornito da TinyOS, che permette di accender/spegnere ognuno dei 3 led durante l’esecuzione dell’applicazione. Questi vengono di solito usati per avere un immediato riscontro visivo delle

operazioni eseguite dal mote (es. accensione di un led al ricevimento di un pacchetto) ma come può essere facilmente intuibile questo rappresenta un me-

todo di debug non ottimale e “stressante”.

- Libreria PrintF: è pratica comune durante lo sviluppo di applicazioni desktop stampare a video su terminale una serie di stringhe per scopi quali il monito-raggio del valore assunto da alcune variabili durante l’esecuzione oppure

l’avvenuta operazione di una determinata sequenza di operazioni. La libreria

PrintF di TinyOS permette di usufruire di una situazione analoga sfruttando il collegamento dei mote al PC attraverso l’interfaccia seriale. I messaggi sono

scritti a video tramite l’invocazione della funzione printf(), che è identica a quella utilizzata in C, all’interno del codice stesso dell’applicazione. Questo rappresenta il più classico ma ancora efficace tra i vari metodi di debug,

l’unico svantaggio è che più sono le funzioni printf() invocate all’interno del codice NesC più aumenta la quantità di memoria RAM richiesta per il funzio-

52

namento del sistema. Ed in situazioni di simulazione di protocolli che fanno

utilizzo di code per i pacchetti da inviare, come in questo caso, questa è solita scarseggiare.

5.1 Struttura originaria del livello di rete MobiWSN

La Figura 5.1 illustra i moduli principali dell’implementazione e i collegamenti (wi-

rings) fra i diversi moduli del livello network (NWK) sui cui è stato effettuato il la-voro di adattamento del protocollo di livello MAC 802.15.4. Tutta la logica del livel-

lo network è implementata all’interno del componente NetworkP, il protocollo di

routing HAT è implementato nel modulo NetworkManagerP, mentre la gestione de-

gli indirizzi viene effettuata nel modulo AddressP. Il modulo NetworkP fornisce le primitive per l’invio di un pacchetto NWK e genera gli eventi di ricezione di pac-chetti dai livelli inferiori. Alla ricezione di un pacchetto confronta il Network Desti-nation Address presente nel pacchetto con l’indirizzo di rete del nodo e determina se

il pacchetto deve essere inoltrato. Per inviare o inoltrare pacchetti agli altri nodi Ne-tworkP fa uso del componente ForwardingManagerP che si occupa di gestire l’invio e la ricezione delle trame tramite il livello Active Message. Il componente implemen-ta una coda per la memorizzazione dei pacchetti da inviare al livello MAC, necessa-

ria per la gestione degli errori in trasmissione e dei tentativi di reinvio di un pac-chetto, più un meccanismo per il controllo della ricezione di pacchetti duplicati dal

livello MAC. Quest’ultima funzione è stata implementata attraverso una tabella

RecCache i cui record sono costituiti dall’indirizzo del nodo da cui il pacchetto è sta-to ricevuto e il sequence number del pacchetto ricevuto.

53

Figura 5.1 Architettura di partenza del livello di rete

Il modulo NetworkP utilizza le funzioni messe a disposizione dal componente For-wardingManagerP attraverso le primitive descritte dall’interfaccia Forward (Tabella 5-1):

- Forward.forward: comando utilizzato per inoltrare un pacchetto al livello MAC. I parametri in ingresso sono: l’indirizzo di destinazione del pacchetto; il

puntatore al buffer del pacchetto (di tipo message_t); la lunghezza del paylo-

ad del pacchetto; un parametro, client_id, utilizzato per discriminare il traffi-co di livello superiore generato (es. messaggi di servizio del protocollo di rou-ting) o indicare se il pacchetto, ricevuto precedentemente, è da inoltrare ad un

altro noto della rete (client_id = NWK_FWD). Inoltre il comando una volta

chiamato restituisce SUCCES se il messaggio è stato inoltrato correttamente

54

al livello inferiore, che provvederà all’effettiva trasmissione al nodo di destina-

zione, FAIL se si è verificato un errore e il pacchetto non è mai stato trasmes-so.

- Forward.forwardDone: evento che segnala l’avvenuta trasmissione di un pac-chetto. I parametri che restituisce sono: il puntatore al pacchetto precedente-mente inviato; l’esito della consegna (SUCCES o FAIL); il client_id.

- Forward.received: evento che segnala la ricezione di un pacchetto da parte di un altro nodo. I parametri che restituisce sono: il puntatore al pacchetto rice-

vuto, che si riferisce all’intera trama di livello MAC comprensiva anche del corrispondente header; il puntatore al payload, cioè il puntatore all’header del

livello network; la lunghezza del payload.

interface Forward { command error_t forward(am_addr_t dst_addr, message_t* msg, uint8_t len, uint8_t client_id); event void forwardDone(message_t* msg, error_t error, uint8_t client_id); event message_t* received(message_t* msg,void* payload, uint8_t len); }

Tabella 5-1 Dichiarazione dell'interfaccia Forward

5.2 ForwardingManager154P

In Figura 5.2 è possibile osservare in dettaglio parte della configurazione iniziale del

livello network esistente, con particolare evidenza al “wiring” tra il componente

ForwardingManagerP e i moduli forniti dal livello Active Message.

55

Figura 5.2 Dettaglio dei collegamenti del componente ForwardingManagerP prima dell’adattamento al livello MAC 802.15.4

L’obbiettivo del lavoro svolto è stato quello di sostituire ai moduli forniti dal li-vello Active Message gli equivalenti del livello MAC 802.15.4 lasciando immutata la

visione che il modulo NetworkP ha del ForwardingManagerP, cioè senza modificare

le interfacce fornite Forward, Packet e StdControl, di cui più avanti illustreremo le funzioni. In Figura 5.3 è possibile osservare in dettaglio la nuova configurazione scel-

ta per sfruttare il protocollo MAC 802.15.4.

NetworkP

ForwardingManagerP

Forward;Packet;

StdControl

AMSenderC AMReceiverC

ActiveMessageC

AMSend;Packet;

Receive;Packet;

SplitControl

Configurazione Generica

ConfigurazioneComponenteCollegamento Interfaccia

56

Figura 5.3 Dettaglio dei collegamenti del componente ForwardingManager154P dopo l’adattamento al livello MAC 802.15.4

Tralasciamo per ora il componente StartManagerP, che verrà illustrato nel para-grafo successivo, e partendo dal basso osserviamo la presenza della nuova configura-zione fornita dall’architettura TKN154 per la gestione completa di una rete IEEE

802.15.4 in modalità beacon-enabled, chiamata Ieee802154BeaconEnabledC. Questa

fornisce la primitiva MCPS_DATA, necessario per l’invio, il riscontro e la ricezione

dei pacchetti, al nuovo componente ForwardingManager154P, il quale a sua volta fornisce le stesse interfacce di prima al livello network ad eccezione dell’interfaccia

Forward154: questa presenta gli stessi comandi/eventi dell’interfaccia Forward (Ta-bella 5-1), a differenza del tipo di dato utilizzato per indicare l’indirizzo di destina-

zione usato durante la chiamata del comando forward. Infatti in configurazione Ac-

tive Message veniva utilizzato il tipo di dato am_addr_t mentre in configurazione

MAC 802.15.4 si è rivelato necessario sostituirlo con un iee-e154_macShortAddress_t, sostituzione che non stravolge l’intera logica applicativa

in quanto entrambi i tipi di dato si riferiscono ad un intero a 16 bit, cambia solo il nome.

NetworkP

ForwardingManager154P StartManager154P

Ieee802154BeaconEnabledC

Forward154;Packet;

StdControl

MCPS_DATA

SplitControl

MLME_RESET;MLME_START;

MLME_ASSOCIATE;MLME_COMM_STATUS;

MLME_SET;MLME_GET;

MLME_SCAN;MLME_SYNC;

MLME_BEACON_NOTIFY;MLME_SYNC_LOSS

Configurazione Generica

ConfigurazioneComponenteCollegamento Interfaccia

57

Verificato che la nuova configurazione non modifica le interfacce usate dal modulo

NetworkP concentriamo la nostra attenzione sull’implementazione del nuovo modulo

ForwardingManager154P e alla sequenza di operazioni necessarie per trasmettere e riceve un pacchetto dati.

Senza entrare nel dettaglio dell’implementazione, in quanto standard di tutta

l’architettura TinyOS, spieghiamo brevemente le funzioni svolte dalle interfacce Pa-cket e StdControl:

- Packet: fornisce al componente che la usa una serie di funzioni per la gestione

del tipo di trama utilizzato, in questo caso, dal ForwardingManager154P, cioè

trama MAC 802.15.4. Packet fornisce funzioni per l’accesso al payload, il cal-colo e l’impostazione della sua lunghezza e l’indicazione della sua dimensione massima possibile.

- StdControl: fornisce semplicemente due funzioni, start() e stop(), utilizzate per accendere o spegnere il componente stesso che la provvede.

Definite queste due interfacce non ci rimane che esaminare l’implementazione di

tutti i comandi e gli eventi generati dalla Forward154:

command error_t forward(ieee154_macShortAddress_t dst_addr, message_t* msg, uint8_t len, uint8_t client_id);

Tabella 5-2 Dichiarazione del comando forward dell’interfaccia Forward154

Forward154.forward() è l’unico comando dell’interfaccia (Tabella 5-2), serve a livelli superiori per inoltrare una trama al livello inferiore MAC 802.15.4 che provvederà

alla trasmissione vera e propria. Per regolare l’invio della trame ForwardingMana-ger154P implementa una particolare coda di trasmissione a seconda del tipo di pac-

chetto che si vuole inviare, specificato dal parametro client_id. I casi possibili sono:

58

- Il pacchetto non è stato generato dal nodo, ma questo ha solo il compito di inoltrarlo al nodo successivo: client_id assume il valore NWK_FWD.

- Il pacchetto è stato generato dal nodo: client_id assume un valore che indica il tipo di dati che trasporta il pacchetto. Al momento vengono distinte 4 tipo-logie di traffico:

o TREE_ROUTING

o GROUP_MANAGEMENT

o MIDDLEWARE

o FUNCTIONALITY

Nel caso di NWK_FWD il pacchetto viene inserito in una coda di dimensione

stabilita in fase di compilazione, negli altri casi ForwardingManager154P ammette l’invio del pacchetto solo se non è vi è già un pacchetto della stessa tipologia di traf-

fico in attesa di essere trasmesso, questo meccanismo permette di equilibrare il traf-fico generato dal nodo ed evitare che una qualche tipologia di traffico possa saturare

le risorse. L’operazione svolta dal comando forward() è proprio quella di stabilire la natura del pacchetto ed eventualmente di inserirlo nella coda d’invio. Il meccanismo

d’invio è poi affidato ad un task, chiamato per l’appunto sendTask(), il quale, invo-cato periodicamente da un timer automatico, nel caso in cui vi siano pacchetti nella

coda d’invio provvederà ad invocare la primitiva MCPS_DATA.request() per la tra-smissione del pacchetto secondo i meccanismi previsti dalla specifica IEEE 802.15.4.

In Tabella 4-2 è possibile osservare i parametri in ingresso al comando

MCPS_DATA.request():

- frame: il puntatore al pacchetto da inviare;

- payloadLen: la dimensione del payload del pacchetto da inviare;

- msduHandle: un parametro che serve ad identificare la trama all’interno della coda d’invio del livello MAC 802.15.4. Utilizzato nel caso si voglia annullare il

59

trasferimento di una trama, in quel caso si invocherà la primitiva

MCPS_PURGE.request() specificando il msduHandle della trama.

- TxOptions: opzioni di trasferimento che si desidera utilizzare (riscontro del pacchetto tramite ACK richiesto, invio in modalità GTS, trasferimento indi-retto nel caso in cui il nodo sorgente sia un coordinator e il destinatario sia ad esso associato).

Figura 5.4 Sequenza di comandi nel caso di (a) invio e (b) ricezione di un pacchetto

Una volta chiamata la MCPS_DATA.request() questa restituirà: il valore IEEE154_SUCCESS in caso di invio corretto del pacchetto altrimenti un’altro valo-re specifico dell’errore riscontrato.

Forward.forward

Forward.forwardDone

MCPS_DATA.request

MCPS_DATA.confirm

NetworkP Forwarding-Manager154P

Ieee802154-BeaconEnabledC

Ieee802154-BeaconEnabledC

Forwarding-Manager154P NetworkP

MCPS_DATA.indication

Forward.received

DATA

ACK

DATA

ACK

(a) Originator

(b) Recipient

60

In Figura 5.4 è possibile osservare un grafico che illustra l’ordine dei comandi e

degli eventi generati nel nodo sorgente (a) e di destinazione (b) una volta invocato

la Forward.forward(). Dopo la chiamata alla la MCPS_DATA.request() ci aspet-

tiamo che venga segnalato l’evento MCPS_DATA.confirm() che restituirà l’esito

dell’invio con un IEEE154_SUCCESS nel caso in cui viene ricevuto l’ACK del pac-chetto inviato, altrimenti un’altro valore specifico dell’errore riscontrato. Nel caso di

IEEE154_SUCCESS verrà segnalato l’evento Forward.forwardDone() con esito posi-

tivo altrimenti nel caso in cui la MCPS_DATA.confirm() dia esito negativo, specifi-cando che non è stato ricevuto l’ACK il sistema proverà ad inviare il pacchetto per

un massimo di tentativi predefinito, esauriti tutti i tentativi segnalerà l’evento For-ward.forwardDone() ai livelli superiori con esito negativo.

Il nodo di destinazione alla ricezione di un pacchetto genererà l’evento

MCPS_DATA.indication() il quale a sua volta segnalerà il corrispettivo For-ward.received(), consegnando ai livelli superiori il puntatore alla trama ricevuta, il puntatore al payload e la sua lunghezza.

5.3 StartManager154P

StartManger154P è il componente deputato alla creazione e al mantenimento della rete IEEE 802.15.4 necessaria per eseguire le operazioni d’invio e ricezione pacchetti

descritte del paragrafo precedente. Non potendo creare in questa prima fase del lavo-ro una topologia di rete complessa, come quella richiesta dal protocollo HAT, il

compito di questo modulo è quello di creare una topologia di rete a stella in modali-

tà beacon-enabled formata da un PAN coordinator che, una volta avviato, inizia a trasmettere le trame di beacon necessarie agli altri dispositivi per avanzare richieste

di associazione. Richieste che vengono automaticamente approvate dal PAN coordi-

nator. Una volta creata la rete viene generato l’evento SplitControl.startDone() che

segnala al ForwardinManager154P il completamento delle operazioni di inizializza-zione e quindi la possibilità di inviare messaggi tramite i meccanismi descritti nella

specifica IEEE 802.15.4. Questo componente risulta di particolare importanza per comprendere le modalità

di creazione di una rete IEEE 802.15.4 in modalità beacon-enabled. Verranno illu-

61

strate di seguito tutte le operazioni necessarie a partire dalla creazione del PAN co-

ordinator fino all’avvenuto compimento dell’operazione di associazione da parte di un dispositivo.

Figura 5.5 Sequenza di comandi all'avvio del PAN coordinator

La prima operazione eseguita dal modulo in questione al suo avvio, decretato

dall’invocazione da parte del ForwardingManager154P del comando SplitCon-tro.start(), è il controllo del parametro TOS_NODE_ID impostato al momento del-la compilazione, se questo è 0 allora il mote sarà il PAN coordinator della nostra re-

te. Osservando in Figura 5.5 notiamo come in questo caso la prime operazioni neces-sarie per l’impostazione dei parametri necessari sono i comandi:

SplitControl.start

SplitControl.startDone

MLME_RESET.request

MLME_RESET.confirm

Forwarding-Manager154P StartManager154P Ieee802154-

BeaconEnabledC

Beacon

MLME_SET.request

MLME_SET.confirm

MLME_START.request

MLME_START.confirm

Association Request

MLME_ASSOCIATE.indication

MLME_ASSOCIATE.responseAssociation Response

Acknowledgement

MLME_COMM_STATUS.indication

62

- MLME_RESET.request(): utilizzato per impostare tutti i parametri del livello MAC 802.15.4 (es. indirizzo del nodo, ID della rete PAN di appartenenza

etc.), contenuti nella PAN Information Base (PIB), ad un valore di default.

- MLME_SET.request(): utilizzato per impostare tutti i parametri del PIB se-condo i valori richiesti. In questo caso viene impostato l’indirizzo MAC del PAN coordinator, deciso in fase di compilazione.

Al termine dell’esecuzione di questi comandi, segnalata dal’evento confirm() di entrambe le primitive, il nodo inizia a trasmettere periodicamente trame di beacon

attraverso l’invocazione del comando MLME_START.request(), la cui avvenuta e-

secuzione è anche in questo caso segnalata dall’evento confirm().

Figura 5.6 Sequenza di comandi all'avvio di un dispositivo semplice

Con la trasmissione delle trame di beacon il PAN coordinator ha terminato tutte le operazioni necessarie all’avvio effettivo della rete IEEE 802.15.4, situazione che

viene immediatamente segnalata al ForwardingManager154P tramite la generazione

MLME_RESET.request

MLME_RESET.confirm

Ieee802154-BeaconEnabledC StartManager154P Forwarding-

Manager154P

AssociationRequest

MLME_SCAN.request

MLME_SCAN.confirm

MLME_ASSOCIATE.request

MLME_ASSOCIATE.confirm

AssociationResponse

Acknowledgement

SplitControl.start

SplitControl.startDone

Beacon

63

dell’evento SplitControl.startDone(). Il dispositivo è adesso pronto per l’invio di pac-chetti nella rete.

Ignoriamo per adesso il PAN coordinator e spostiamo la nostra attenzione alla Fi-gura 5.6, che descrive le operazioni compiute da un dispositivo semplice, cioè non il

PAN coordinator della nostra rete, appena avviato. Questo dopo aver eseguito la

MLME_RESET.request() descritta nel caso precedente, si mette in ascolto del cana-

le radio, attraverso l’invocazione della MLME_START.request(), alla ricerca di una trama di beacon da cui prelevare i dati necessari per eseguire la richiesta di associa-

zione. Alla ricezione del beacon, segnalata dall’evento MLME_SCAN.confirm(), vie-ne immediatamente effettuata la richiesta di associazione attraverso la

MLME_ASSOCIATE.request(). La richiesta viene ricevuta dal PAN coordinator at-

traverso la segnalazione dell’evento MLME_ASSOCIATE.indication(), e dopo aver assegnato un indirizzo al dispositivo richiedente, risponde con una

MLME_ASSOCIATE.response(). Il dispositivo richiedente allora segnalerà l’avvenuta approvazione della richiesta di associazione tramite una

MLME_ASSOCIATE.confirm() e provvederà a comunicare al PAN coordinator

l’esito positivo dell’operazione tramite un messaggio di Acknoledgment, alla ricezione del quale il PAN coordinator segnalerà l’effettiva esistenza del canale di comunica-

zione tramite la MLME_COMM_STATUS.indication(). Al completamento del pro-cesso di associazione anche il dispositivo è pronto per inviare pacchetti nella rete,

può quindi segnalare al ForwardingManager154P la corretta istituzione del collega-

mento tramite l’invocazione della SplitControl.startDone(). Il sistema è adesso pronto per lo scambio effettivo di trame dati da parte dei due

mote secondo i meccanismi descritti nella specifica IEEE 802.15.4 in uno scenario di

tipo beacon-enabled.

64

Conclusioni

Alla luce di quanto illustrato nell’analisi del Capito 4 riguardo le reali possibilità d’integrazione tra il livello network dell’architettura MobiWSN e il protocollo di li-

vello MAC 802.15.4, il lavoro d’implementazione svolto in questa tesi risulta essere solo il punto di partenza per l’attuazione globale della soluzione proposta.

Nonostante le difficoltà riscontrate nell’implementazione di questa soluzione, so-prattutto a causa della mancanza di un tool di simulazione/debugging adeguato allo

scopo, i vantaggi che ne derivano, soprattutto in termini di risparmio energetico, motivano la necessità di proseguire nell’opera d’implementazione.

Alla fine di tutto risulta quindi di particolare importanza il minuzioso lavoro di analisi e verifica di tutti i vincoli progettuali della soluzione proposta, permettendo di definire le varie fasi di sviluppo necessarie per raggiungere l’obbiettivo di questo

lavoro di tesi. Gli sviluppi futuri possibili risultano essere anche i punti necessari per realizzare

un’integrazione ottimale fra i due protocolli. Integrazione ottimale raggiunta con lo sfruttamento di tutte le risorse messe a disposizione dal protocollo MAC IEEE

802.15.4. I punti necessari per raggiungere questo risultato appaiono chiari essere i seguenti:

- Modifica del protocollo di routing attuale, in modo da sfruttare le informazioni ricevute dal livello inferiore riguardo i nodi sufficientemente vicini. Lasciare come unico compito quello di scegliere soltanto il nodo a cui associarsi, secon-

do una funzione di costo che sfrutterà i parametri ottenuti sia dal livello PHY 802.15.4 (es. qualità del canale radio in termini di SNR) sia dal livello MAC

802.15.4 (es. distanza in termini di hop dal PAN coordinator), e lasciare l’intera gestione della procedura d’associazione al livello MAC 802.15.4 che provvederà solo a confermare l’avvenuta associazione e l’eventuale dissociazio-

65

ne. Questo oltre a permettere un notevole risparmio in termini di memoria e

risorse computazionali (che si tramutano in consumo di energia), permette an-che un allineamento perfetto fra le topologie di rete tra i livello network e li-

vello MAC, consentendo così una gestione ottimizzata del protocollo di rou-ting.

- Utilizzo delle trame di beacon, necessarie per il mantenimento della sincroniz-

zazione tra i coordinator e i dispositivi associati, per gli scopi del livello network. Il livello network attuale spedisce periodicamente delle trame di ser-

vizio necessarie per il mantenimento della rete stessa. Si potrebbero includere queste informazioni di mantenimento all’interno del payload del beacon defini-

to dalla specifica IEEE 802.15.4. Evitando così di trasmettere ulteriori pac-chetti, con un conseguente risparmio di energia.

Inoltre per ottenere un reale aumento di autonomia dei sensori wireless dal punto

di vista energetico è necessario che sia implementata anche la gestione dello spegni-mento e accensione del’interfaccia radio secondo la specifica IEEE 802.15.4, che al

momento non è ancora realizzato dall’architettura TKN154. Però tra le motivazioni che hanno portato alla scelta del TKN154 c’è anche il fatto che è da poco stato scel-to come base di partenza per il TinyOS Working Group 15.4 (vedi paragrafo 4.4).

Questo fatto si è già tramutato essenzialmente in un maggiore interesse da parte di tutta la comunità scientifica nel realizzare una soluzione d’implementazione di tutta

la specifica IEEE 802.15.4. Poiché l’attuale stato di sviluppo dell’architettura

TKN154 e in particolare delle primitive di gestione e invio dati MLME ed MCPS che rappresentano anche gli unici punti di contatto con i livelli superiori, descrivono fe-

delmente i vincoli dettati dalla specifica di livello MAC 802.15.4, quando verrà fi-nalmente rilasciata l’implementazione dell’intero stack IEEE 802.15.4, il lavoro

d’integrazione svolto sul livello network di MobiWSN fino a quel momento non sarà vano in quanto le logiche implementate rispettano già la specifica IEEE 802.15.4.

66

Bibliografia [1] AIM - A novel architecture for modelling, virtualising and managing the

energy consumption of household appliances. 2009. <http://www.ict-aim.eu>. [2] David Gay, Philip Levis, David Culler, Eric Brewer. «nesC 1.1 Language

Reference Manual.» 5 2003. 2009 <http://nescc.sourceforge.net/papers/nesc-ref.pdf>.

[3] F. Cuomoa, S. Della Lunaa, E. Cipollonea, P. Todorovab, T. Suihkoc. «Topology formation in IEEE 802.15.4: cluster-tree characterization.» Sixth Annual IEEE International Conference on Pervasive Computing and Communications. 2008.

[4] Hauer, Jan-Hinrich. «TKN15.4: An IEEE 802.15.4 MAC Implementation for TinyOS 2.» TKN Technical Report Series TKN-08-003. Technical University Berlin, 2009.

[5] IEEE 802 Working Group. «IEEE std 802.15.4-2006, part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs).» Technical report. IEEE Computer Society, 2006.

[6] J. Polastre, J. Hill, and D. Culler. «Versatile low power media access for wireless sensor networks.» Proceedings of the 2nd international conference on Embedded networked sensor systems. 2004. 95-107.

[7] K. R. Chowdhury, N. Nandiraju, D. Cavalcanti, and D.P. Agrawal. «CMAC - a multi-channel energy efficient MAC for wireless sensor networks.» 2006.

[8] Kurtis Kredo II, Prasant Mohapatra. «Medium access control in wireless sensor networks.» Computer Networks (Elsevier) Journal 51 2007: 962-964.

[9] Langendoen, T. van Dam and K. «An adaptive energy-efficient MAC protocol for wireless sensor networks.» Proceedings of the first international conference on Embedded networked sensor systems. 2003. 171-180.

[10] Levis, Philip. «TinyOS Programming.» 6 2008. 2009 <http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf>.

[11] MICAz Wireless Module. 2009. <http://www.xbow.com>. [12] Raghavendra, S. Singh and CS. «PAMASpower aware multi-access protocol

with signalling for ad hoc networks.» ACM SIGCOMM Computer Communication Review, 28(3):5–26. 1998.

67

[13] Open-ZB - OpenSource ToolSet for IEEE 802.15.4 and ZigBee. 2009. <http://www.open-zb.net/>.

[14] «TinyOS 15.4 Working Group.» 2009. <http://sing.stanford.edu:8000/15.4_WG>.

[15] TinyOS Berkley University Operating System. 2009. <http://www.tinyos.net>.

[16] UC Berkeley WEBS Project. nesC: A Programming Language for Deeply Networked Systems. 2004. <http://nescc.sourceforge.net/>.

[17] V. Rajendran, K. Obraczka, and J.J. GarciaLunaAceves. Energyefficient, collisionfree medium access control for wireless sensor networks. Technical report. University of California. Santa Cruz, 2004.

[18] W. Ye, J. Heidemann, and D. Estrin. «An energy-efficient MAC protocol for wireless sensor networks.» wenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 3. INFOCOM 2002, 2002.

[19] Wendi Rabiner Heinzelman, Anantha Chandrakasan, and Hari Balakrishnan. «Energy-Efficient Communication Protocol for Wireless Microsensor Networks.» Proceedings of the 33rd Hawaii International Conference on System Sciences. 2000.

[20] Z.B. Alliance. Zigbee specification version 1.0. 2004.