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

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

i
 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

ii
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

iii
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

iv
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

v
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.

1
 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.

2
 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

3
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

4
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-

5
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

6
 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

7
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

8
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

9
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

10
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-

11
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.

12
 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

13
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);

14
 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.

15
 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

16
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-

17
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:

18
 - 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;

19
 - 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-

20
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].

21
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.

22
 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.

23
 - 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-

24
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-

25
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-

26
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-

27
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.

28
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-

29
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

30
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).

31
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

32
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.

33
 Middleware

Group

Network

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.

34
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

35
 - 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

36
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).

37
 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

38
 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

39
 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

40
 $%&'()*+,-&*-*./&'$(*%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+:
Osservando in Figura 4.4 si nota come la massima dimensione dell’header di livel-
!"#"$%&'(')*+%,-.%/)*0'%/1)0*2
lo network è di 8 Byte a cui segue un payload di lunghezza variabile fino ad un mas-
D,(*>?@*5)-6(*5%)6-+*/.*0%6C%.(4*%5*-*>2EA*-*>?@*C-=$%-4A*-&4*-*>;E:*D,(*5/($4.*%5*+,(*>2E*-CC(-)
simo stabilito dalla costante NWK_PAYLOAD_LENGTH.
/&*-*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!:

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

;)-6( L(N8(&0( P(.+/&-+/%& P(.+/&-+/%& L%8)0( L%8)0( ?8F/$/-)= ;)-6( ;@L

@%&+)%$ O869() 1?O ?44)(.. 1?O ?44)(.. L(08)/+= 1-=$%-4
Q4(&+/5/() Q4(&+/5/() 2(-4()
?44)(../&'*5/($4.

>2E >?@ >;E

1-=$%-4

34?:)'%@$A&'(')*+%,-.%/)*0'%/1)0*2
Figura 4.8 Formato della trama MAC 802.15.4

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

Esaminando adesso il formato della trama MAC 802.15.4 (Figura 4.5) notiamo
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:
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
63#%&'
di 20*7(Byte e 8un Auxiliary
/ -
Security .
Header 97:
di 14 Byte, )*7)) )(7)8
dei 127 Byte )/7)-
di lunghezza
massima
;)-6( dell’intera trama rimangono
L(08)/+= ;)-6( ?0R: a disposizione
1?O*QP E(.()<(4delP(.+:
payload 88 Byte,L%8)0(
;)-6( che corri-
D=C( M&-9$(4 1(&4/&' E(N8(.+ @%6C)(../%& ?44)(../&' S()./%& ?44)(../&'
spondono alla lunghezza massima della trama di livello network. Alla luce di questi >%4( >%4(

dati si arriva subito a34?:)'%@#A31)0*2%1/%2B'%3)*0'%.1(2)1+%/4'+5

calcolare che per rispettare questo vincolo la dimensione del
payload di livello network, e quindi il valore della costante
!"#"$"$"$%3)*0'%678'%9:;/4'+5
NWK_PAYLOAD_LENGTH, dovrà essere inferiore a 80 Byte. Questa costante è al
D,(* ;)-6(* D=C(* .895/($4* /.* "* 9/+.* /&* $(&'+,* -&4* .,-$$* 9(* .(+* +%* %&(* %5* +,(* &%&)(.()<(4* <-$8(.* $/.+(4* /&
momento
D-9$( JK: 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
!"#"$"$"#%<'=:)427%>(*;+'5%9:;/4'+5
127 Byte.
D,(*L(08)/+=*M&-9$(4*.895/($4*/.*!*9/+*/&*$(&'+,A*-&4*/+*.,-$$*9(*.(+*+%*%&(*/5*+,(*5)-6(*/.*C)%+(0+(4*9=*+,(
Alla luce di quanto esaminato fin’ora si può concludere affermando che è possibile
>?@*.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*/.*.(+*+%*%&(:
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
!"# 2>?@ABCD$&E&)((/&!"""*&3FF&ABCD$G&AHGHAIH%*
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-

41
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

42
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.

43
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).

44
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

45
 Componenti Funzioni [Primitive IEEE 802.15.4 fornite]
AssociateP associazione al PAN [MLME-ASSOCIATE,MLME-COMM-STATUS]
BeaconTransmitP trasmissione periodica dei beacon [MLME-START]
Beacon-SynchronizeP sincronizzazione [MLME-SYNC(-LOSS), MLME-BEACON-NOTIFY]
CoordBroadcastP trasmissione di trame broadcast del coordinator
CoordRealignmentP comandi di riallineamento [MLME-ORPHAN, MLME-COMM-STATUS]
DataP accodamento trame dati per l’invio [MCPS-DATA, MCPS-PURGE]
DisassociateP disassociazione dal PAN [MLME-DISASSOCIATE]
DispatchQueueP coda d’invio per le trame dati/command
DispatchSlottedCsmaP tx/rx trame durante CAP (non include l’algoritmo CSMA-CA)
DispatchUnslottedCsmaP tx/rx trame in scenari beacon-less (excluding the CSMA-CA algorithm)
IndirectTxP gestione delle trasmissioni dati indirette
PibP gestione del informazioni del PIB [MLME-RESET, MLME-GET, MLME-SET]
PollP richiesta dati ad un coordinator [MLME-POLL]
PromiscuousModeP attiva/disattiva promiscuous mode
Radio-ClientC virtualizzazione accesso a RadioControlP
RadioControlImplP gestisce l’accesso alla radio
RadioControlP configurazione per RadioControlImplP
RxEnableP attivazione della radio durante i perdiodi di inattività [MLME-RX-ENABLE]
ScanP scansione dei canali radio [MLME-SCAN]
SimpleTransferArbiterP gestione della “resource radio”
TKN154BeaconEnabledP MAC configurazione usata in beacon-enabled PAN
TKN154NonBeaconEnabledP 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.

46
 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

47
 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.

48
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

49
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-

50
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-

51
 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.

52
 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

53
 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.

54
 Configurazione Generica
NetworkP Configurazione
Componente
Collegamento Interfaccia
Forward;
Packet;
StdControl

SplitControl
ForwardingManagerP ActiveMessageC

AMSend; Receive;
Packet; Packet;

AMSenderC AMReceiverC

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.

55
 Configurazione Generica
NetworkP Configurazione
Componente

Forward154; Collegamento Interfaccia

Packet;
StdControl

SplitControl
ForwardingManager154P StartManager154P

MLME_RESET;
MLME_START;
MLME_ASSOCIATE;
MLME_COMM_STATUS;
MLME_SET;
MCPS_DATA
MLME_GET;
MLME_SCAN;
MLME_SYNC;
MLME_BEACON_NOTIFY;
MLME_SYNC_LOSS

Ieee802154BeaconEnabledC

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.

56
 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:

57
 - 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

58
 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).

Forwarding- Ieee802154-
NetworkP
Manager154P BeaconEnabledC

Forward.forward
MCPS_DATA.request DATA

ACK

MCPS_DATA.confirm
Forward.forwardDone

(a) Originator

Ieee802154- Forwarding-
NetworkP
BeaconEnabledC Manager154P

DATA

ACK MCPS_DATA.indication

Forward.received

(b) Recipient

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.

59
 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-

60
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.

Forwarding- Ieee802154-
StartManager154P
Manager154P BeaconEnabledC

SplitControl.start
MLME_RESET.request

MLME_RESET.confirm

MLME_SET.request

MLME_SET.confirm

MLME_START.request Beacon

MLME_START.confirm
SplitControl.startDone
Association
Request

MLME_ASSOCIATE.indication

Association
MLME_ASSOCIATE.response Response

Acknowledgement

MLME_COMM_STATUS.indication

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:

61
 - 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().

Ieee802154- Forwarding-
StartManager154P
BeaconEnabledC Manager154P

SplitControl.start
MLME_RESET.request

MLME_RESET.confirm

Beacon MLME_SCAN.request

MLME_SCAN.confirm

Association
Request MLME_ASSOCIATE.request

Association
Response

Acknowledgement MLME_ASSOCIATE.confirm
SplitControl.startDone

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

62
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.

63
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-

64
 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.

65
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.

66
[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.

67