Analisi e Implementazione Di Un Gateway Efficiente Per Wireless Sensor Networks

UNIVERSITÀ DEGLI STUDI DI PISA
Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Specialistica in Tecnologie Informatiche
Analisi e implementazione di un gateway

efficiente per Wireless Sensor Networks
Relatori: Controrelatore:
Prof. Stefano Chessa Prof. Vincenzo Ambriola
Ing. Claudio Borean
Candidato:
Alessandro Belleggia
ANNO ACCADEMICO 2006/2007

Ringraziamenti
Ai miei genitori perché sono le mie radici e le mie ali,
ai miei nonni per il loro premuroso sostegno,
alla mia ragazza perché insieme i sogni sono più vicini,
alla sua famiglia per l’affetto dimostrato,
al prezioso Pasquale per tutti questi anni fianco a fianco,
al carissimo Ubaldo per la sua costante presenza,
ad Andrea, Francesco e Raffaele per la loro sincera amicizia,
al mio tutor Claudio per la sua cordiale disponibilità,
e a tutto il gruppo WSN per l’importante esperienza vissuta a Torino,
GRAZIE!
Dedicato a mamma e papà.

Indice
1. Introduzione .......................................................................................................... 7
1.1. Scenario e obbiettivi ....................................................................................... 9
1.2. Riassunto .......................................................................................................10
2. Standard ZigBee ...................................................................................................12
2.1. Descrizione ....................................................................................................14
2.1.1. Caratteristiche .........................................................................................14
2.1.2. ZigBee vs Bluetooth................................................................................16
2.1.3. Applicazioni............................................................................................20
2.2. ZigBee 2004 ..................................................................................................24
2.2.1. Standard 802.15.4 ...................................................................................24
2.2.2. ZigBee Network Layer ............................................................................26
2.2.3. Application layer .....................................................................................30
2.2.4. Comunicazione tra le applicazioni ...........................................................31
2.3. ZigBee 2006 ..................................................................................................34
2.3.1. Formato del pacchetto ZCL .....................................................................40
3. Stima del traffico di un ZigBee Home Gateway ....................................................46
3.1. Scenario di monitoraggio remoto ...................................................................47
3.1.1. Remote control........................................................................................48
3.1.2. Caso d’uso ..............................................................................................51
3.2. Modello di traffico .........................................................................................53
3.2.1. Stima del numero di pacchetti inviati.......................................................55
3.3. Risultati e conclusioni ....................................................................................58
4. Gateway Reference Implementation .....................................................................60
4.1. Gateway Abstraction Layer ............................................................................63
4.1.1. “Management and Commissioning” ........................................................63
4.1.2. “Service discovery”.................................................................................64
4.1.3. “Service interface” ..................................................................................65
4.2. Gateway Device Object..................................................................................67
4.2.1. Device Discovery ...................................................................................67
4.2.2. Service Discovery ...................................................................................69
4.3. Applicazione ..................................................................................................71
4.3.1. Interfaccia grafica ...................................................................................71
4.3.2. Architettura applicativa ...........................................................................74
4.3.3. Implementazione .....................................................................................75
4.3.4. REST - Representational State Transfer ..................................................80
4.3.5. Gateway Information Base ......................................................................83
5. Conclusioni ..........................................................................................................86
5.1. Obiettivi raggiunti e futuri..............................................................................87
5.2. Esperienza .....................................................................................................88
6. Appendice ............................................................................................................89
6.1. Dongle Integration .........................................................................................89
6.2. Nodo BM.......................................................................................................90
6.3. Esempi di codice ............................................................................................92
6.3.1. OnBnClickedDeviceDiscovery................................................................92
6.3.2. OnBnClickedServiceDiscovery ...............................................................92
6.3.3. Discovery (richiesta proveniente dalla rete) .............................................92
3
6.3.4. ServerThread...........................................................................................93
6.3.5. Node .......................................................................................................96
7. Riferimenti ...........................................................................................................97
4
Indice delle figure
Figura 1 Logo ZigBee .................................................................................................12
Figura 2 Certificazioni ZigBee ....................................................................................13
Figura 3 Routing reattivo in una rete mesh ..................................................................16
Figura 4 Confronto tra lo stack ZigBee e lo stack Bluetooth ........................................17
Figura 5 Collocazione degli standard wireless in base a distanza e capacità tramissiva 18
Figura 6 Ambiti applicativi di ZigBee .........................................................................21
Figura 7 Home Automation .........................................................................................21
Figura 8 Industrial plant monitoring ............................................................................22
Figura 9 ZigBee stack..................................................................................................24
Figura 10 Tipologie di rete ..........................................................................................27
Figura 11 Tipologie di routing .....................................................................................28
Figura 12 Indirizzamento diretto..................................................................................32
Figura 13 Indirizzamento indiretto...............................................................................33
Figura 14 Rapporto tra ZigBee Cluster Library ZigBee Profile ....................................34
Figura 15 Schema di un cluster ....................................................................................37
Figura 16 Trasmissione dati.........................................................................................41
Figura 17 Tipi di una primitiva ....................................................................................41
Figura 18 Pacchetto APS e ZCL ..................................................................................43
Figura 19 Formato del comando "Read attributes" .......................................................43
Figura 20 Zig Bee Home Gateway...............................................................................46
Figura 21 Composizione tipica di una casa ..................................................................52
Figura 22 Frammento del foglio di calcolo ..................................................................53
Figura 23 Frammento con i risultati ottenuti ................................................................55
Figura 24 Visualizzazione del foglio di calcolo ottenuta nascondendo alcune colonne .57
Figura 25 Risultati .......................................................................................................58
Figura 26 Architettura di sistema .................................................................................60
Figura 27 Gateway stack .............................................................................................62
Figura 28 Diagrammi di flusso relativi alla Device Discovery .....................................69
Figura 29 Diagrammi di flusso relativi alla Service Discovery.....................................70
Figura 30 Dongle USB - ZigBee fornito da Integration................................................71
Figura 31 Interfaccia grafica ........................................................................................73
Figura 32 Architettura applicativa ...............................................................................74
Figura 33 Rappresetazione a oggetti ............................................................................76
Figura 34 Schema riassuntivo ......................................................................................80
Figura 35 Finestra del browser ....................................................................................82
Figura 36 Memorizzazione dei dati..............................................................................84
Figura 37 Documento XML ........................................................................................85
Figura 38 Gruppo del progetto WSN-C .......................................................................88
Figura 39 Due tipi di driver .........................................................................................89
Figura 40 Nodo BM MOD 01......................................................................................90
Figura 41 Scheda di prova BM ....................................................................................91
5
Indice delle tabelle
Tabella 1 Caratteristiche di ZigBee contro quelle di Bluetooth ....................................19
Tabella 2 Home Controls Stack Profile ........................................................................29
Tabella 3 Dispositivi previsti in Home Automation Profile ..........................................36
Tabella 4 Cluster supportati da On/Off Switch.............................................................37
Tabella 5 Cluster supportati da On/Off Light ...............................................................38
Tabella 6 Attributi del server del cluster On/Off ..........................................................38
Tabella 7 Comandi ricevuti dal server del cluster On/Off.............................................39
Tabella 8 Elenco dei comandi ZCL generici ................................................................44
Tabella 9 Cluster supportati da Remote control ...........................................................47
Tabella 10 Dispositivi interfacciabili con un Remote control .......................................49
Tabella 11 Node descriptor..........................................................................................64
Tabella 12 Power descriptor ........................................................................................64
Tabella 13 Simple descriptor .......................................................................................65
6
1. Introduzione
Il presente elaborato espone l’esperienza di tesi che ha avuto luogo a Torino da luglio a
dicembre 2006 presso un’importante azienda operante nel settore delle
telecomunicazioni. Quest’ultima indirizza importanti investimenti nella ricerca e
sviluppo e dedica particolare interesse alle Wireless Sensor Networks (in italiano “reti
di sensori senza fili”). Una WSN è un sistema complesso che nasce dalla cooperazione
tra diversi oggetti elementari, detti nodo sensore. Un nodo sensore è dispositivo
elettronico in grado di svolgere in modo autonomo un certo insieme di operazioni più o
meno complesse, di interagire con l'ambiente circostante e di cooperare con gli altri
nodi per mezzo di opportune interfacce di comunicazione senza fili. Tali nodi sono
equipaggiati di sensori (temperatura, umidità, accelerazione, presenza, ecc.) o attuatori
(interruttori, potenziometri, motori, ecc.), o di entrambe se necessario, e di una
interfaccia radio. I nodi sensori monitorano l'occorrenza di determinati eventi di
interesse nell'ambiente e comunicano queste informazioni, tramite gli altri nodi, al sink
(scarico o pozzo). I sink hanno il compito di raccogliere le informazioni, processarle e,
se opportuno, ritrasmetterle verso altre reti, svolgendo in tal caso il ruolo di gateway. Le
reti di sensori nascono per esigenze militari quando, durante la guerra fredda, furono
utilizzate per la prima volta dalla difesa americana per monitorare gli spostamenti dei
sottomarini sovietici [SOSUS]. Le moderne ricerche condotte sulle reti di sensori senza
fili iniziarono nel 1980 con le DNS (reti di sensori distribuiti) progettate dall'agenzia
governativa del Dipartimento della Difesa degli Stati Uniti, DARPA (Defence
Advanced Research Projects Agency). Al di là degli scopi militari, le WSN possono
essere utilizzate per monitorare aree a rischio (ad esempio rivelare tempestivamente
incendi boschivi), controllare impianti industriali e non ultimo per realizzare
un’interazione tra ambiente e persona, facendo in modo che l’ambiente reagisca e si
adattati alla presenza e alle esigenze dell’utente in modo automatico. Scenari futuristici,
inoltre, prevedono l'utilizzo delle WSN in ambito medico, attraverso l'impianto
nell'organismo di minuscoli nodi sensore in grado di monitorare i parametri vitali della
persona e somministrare la terapia farmacologica in modo autonomo, quando
necessario. Importanti progetti sono stati portati avanti da numerosi istituti universitari
di tutto il mondo e questo rende abbondante la letteratura in questo settore.
L’eterogeneità e la limitatezza delle risorse dei nodi sensori, in termini di energia,
7
potenza di calcolo e memoria, richiedono una progettazione accurata della struttura e
dei protocolli di gestione della WSN in relazione all'applicazione specifica da
realizzare. Il risultato è lo sviluppo di soluzioni precisamente disegnate per
l’applicazione per cui il sistema è concepito e difficilmente adattabili a scenari operativi
diversi. Queste caratteristiche ostacolano l’abbattimento dei tempi e dei costi di
sviluppo di nuove applicazioni per WSN, rallentando di conseguenza la crescita del
settore in ambito aziendale. Al fine di superare queste difficoltà oggettive, nel dicembre
2004, dopo due anni di lavoro, la ZigBee Alliance, una associazione di oltre un
centinaio di aziende, ha immesso sul mercato la prima una soluzione completa per reti
di sensori. Gli investitori nutrono la speranza che, sulla base dello standard ZigBee,
dispositivi di produttori diversi possano integrarsi tra loro in modo spontaneo in modo
da gettare le basi affinché questa tecnologia diventi pervasiva. In un futuro non troppo
lontano sarà possibile acquistare dei dispositivi con il marchio ZigBee direttamente dai
fornitori di materiale elettrico e attivare un sistema di monitoraggio e controllo senza
dover subire una fase di progettazione e senza dover prevedere l'installazione di cavi e
centraline di controllo all'interno dei muri o sotto i pavimenti flottanti. Se si pensa ad
apparecchi ambientali come per esempio le luci, gli interruttori, i telecomandi, i sensori
di presenza, le serrande automatiche, gli impianti di riscaldamento e raffreddamento, i
sensori di temperatura, i sistemi antintrusione, ecc. si comprende quanto le Wireless
Sensor Netwoks possano rivelarsi utili per tutto il mondo domestico, commerciale e
industriale, attualmente privo della possibilità di controllare in maniera così granulare le
infrastrutture basilari della propria realtà.
8
1.1. Scenario e obbiettivi
Il mercato delle reti di sensori presenta possibili interessi per l’operatore di
telecomunicazioni. Nell’ottica accennata nel precedente paragrafo, l’operatore confida
sulla possibilità di fornire l’accesso a tali reti. L’idea di business si fonda sul fatto che
uno sviluppatore di applicazioni per WSN, piuttosto che creare la propria applicazione
di controllo ex novo, si affidi alla piattaforma di servizio fornita dall’operatore di
telecomunicazioni per creare la propria piattaforma applicativa. Parte imprescindibile di
tale architettura è il gateway il quale permette all’operatore di interagire con la rete di
sensori necessariamente basata sullo standard ZigBee. Molteplici sono gli apparati a cui
è possibile affidare il compito di veicolare il traffico proveniente dalla WSN verso la
piattaforma di servizio e viceversa. In ambito domestico sono già presenti dispositivi
come il modem ADSL, il videotelefono o il set top box (il cosiddetto decoder per la
televisione via internet), tutti con capacità IP, ai quali non risulta difficile aggiungere la
funzionalità di accesso alle reti ZigBee. In questa maniera un utente domestico ha
l’opportunità di acquistare, anche in tempi diversi, i dispositivi marchiati ZigBee di
qualsiasi produttore, di installarli in casa, in alcuni casi senza l’intervento di un tecnico
specializzato, e di gestire la propria rete di sensori scegliendo la piattaforma applicativa
che meglio soddisfi le proprie esigenze. Questo utente apprezzerà particolarmente
scoprire che il suo videotelefono ha il marchio ZigBee e che quindi può svolgere la
funzione di gateway senza introdurre ulteriore dispositivo in casa. È in questa visione
che aderire ad uno standard comune diviene, per l’operatore, fondamentale. Nell’ultimo
anno i produttori di apparati conformi a ZigBee hanno sostanzialmente fatto esperienza
con la tecnologia: da queste esperienze sono nati alcuni miglioramenti di ZigBee che
sono stati integrati nella nuova versione delle specifiche. Quest’ultima differisce dalla
precedente per l’introduzione dei profili applicativi, per ognuno dei quali sono elencati i
dispositivi appartenenti e i messaggi che tali dispositivi si scambiano tra loro per
realizzare l’applicazione. La vasta copertura di ogni profilo assicura che nessuna
applicazione debba essere sviluppata ricorrendo solo a messaggi di tipo proprietario. Il
secondo capitolo sviluppa dettagliatamente lo standard ZigBee.
9
1.2. Riassunto
La prima parte dell’esperienza presso l’operatore di telecomunicazioni è stata

focalizzata allo studio della documentazione della prossima versione dello standard
ZigBee. Questa attività è risultata essere propedeutica alla parte centrale della tesi in
quanto è servita a generare un quadro abbastanza esaustivo del campo di impiego.
Come già detto, la prossima versione dello standard ZigBee mira ad uniformare lo
scambio dei messaggi tra i dispositivi più comunemente usati nei vari impieghi delle
Wireless Sensor Network. Per ogni profilo applicativo vengono elencati e descritti i
dispositivi di appartenenza. Il termine “dispositivo”, in inglese “device”, è inteso a
livello applicativo e questo permette di distinguere l’oggetto fisico dotato di radio sul
quale è possibile, invece, installare fino a 240 di questi dispositivi. La descrizione del
dispositivo definisce le funzionalità mediante l’indicazione dei cluster implementati. Un
cluster è il canale che permette di far comunicare le applicazioni e si divide in client
cluster e server cluster. La ZigBee Cluster Library definisce l’insieme di tali cluster e
per ognuno di questi indica il formato dei messaggi. Per una trattazione più esaustiva si
rimanda al secondo capitolo. Tale studio ha avuto come fine la modellizzazione del
traffico passante dal gateway di una rete ZigBee per uso domestico al fine di valutare
l’impatto e di capire come orientare il business dell’operatore di telecomunicazioni.
Esaminando il documento Home Automation Profile Specification, ricavandone i
dispositivi comandabili presenti in una casa e esplicitando i comandi impartibili, si è
prodotto un foglio di calcolo sul quale è possibile agire in maniera parametrica sia sulla
frequenza dei messaggi scambiati e sia sul numero dei dispositivi presenti per ricavarne
una misura del traffico. Il risultato ottenuto ha confermato le aspettative: il basso
impatto in termini di byte spinge ad orientare il business dell’operatore di
telecomunicazioni non sul traffico ma sul servizio offerto. Importante notare che questa
affermazione rimane valida solo per il profilo Home Automation in quanto potrebbe
non essere altrettanto vera analizzando profili diversi. Il terzo capitolo descrive
dettagliatamente tale lavoro. La parte centrale si è concentrata sullo sviluppo di un
prototipo di un gateway per reti ZigBee che si introduca nella rete in maniera non
invasiva, ne ricavi tutta l’informazione necessaria e eventualmente interagisca con i
singoli dispositivi. Tutto questo sfruttando l’interoperabilità tra i produttori di
10
dispositivi dovuta allo standard. Le due principali macro che il gateway fornisce sono
Device discovery (ricerca dei nodi) e Service discovery (ricerca dei sevizi) e tali
funzionalità sono state proposte al ZigBee Gateway Working Group (il gruppo interno a
ZigBee che si occupa di standardizzare il gateway). L’output delle macro precedenti è
restituito alla piattaforma di servizio mediante l’uso di un formalismo chiamato REST
(REpresentational State Transfer) che usa HTTP come trasporto dei dati e XML per la
loro rappresentazione. Il gatway permette anche alla piattaforma di servizio di interagire
con ogni singolo nodo mediante un formalismo tuttora in fase di definizione.
L’applicazione è stata sviluppata utilizzando Visual Studio .NET 2003 ed è stata scritta
in C++ in quanto la libreria di interfacciamento con il dispositivo ZigBee (un dongle
USB fornito da Integration) è strettamente legata a questo ambiente.
11
2. Standard ZigBee
ZigBee è il nome di un’alleanza commerciale nata per sviluppare prodotti affidabili, di
basso costo, con basso consumo energetico, senza fili, basati su di un standard aperto e
globale per il monitoraggio e il controllo di ambienti.
Figura 1 Logo ZigBee
Questo è il marchio tratto dal sito [ZigBee.org]: è evidente la volontà di creare uno
standard davvero efficace. Nelle applicazioni di monitoraggio e controllo sussiste la
possibilità di avere migliaia di dispositivi in uno spazio relativamente piccolo e ciò
rende necessaria l’adozione di un mezzo trasmissivo senza fili e di una alimentazione
tramite batteria. Altresì necessario è ridurre il consumo di energia per garantire un
autonomia apprezzabile. Non per ultimo occorre assicurare un basso costo del
ricetrasmettitore. Per soddisfare queste premesse lo standard ZigBee si basa sullo
standard IEEE 802.15.4 per implementare gli strati più bassi della sua pila protocollare.
Anche se spesso si tende a confondere ZigBee con IEEE 802.15.4 è bene iniziare la
descrizione introducendo una immagine che esponga i criteri di certificazione della
ZigBee Alliance. Il programma di certificazione ha lo scopo di classificare i prodotti in
base al grado di conformità allo standard ZigBee in modo da fornire chiarezza agli
utenti e al mercato. Esistono due diversi tipi di certificazione:
 ZigBee Compliant Platform, questa certificazione specifica che il livello fisico e

il MAC (medium access control) sono conformi a 802.15.4 e che il livello di rete
e il livello di supporto alle applicazioni è fedele alla specifica ZigBee.
 ZigBee Certified Products, questa certificazione specifica che il dispositivo è

conforme a ZigBee e l’applicazione residente appartiene ad un profilo
applicativo pubblico oppure ad un profilo applicativo privato.
12
Figura 2 Certificazioni ZigBee
Il primo livello di certificazione è indirizzato ai costruttori di semiconduttori, di moduli

e di sistemi integrati; il secondo, invece, è rivolto a chi acquista l’hardware dai primi e
sviluppa la soluzione applicativa per offrirla all’utente finale. I prodotti che rispettano il
secondo livello devono necessariamente rispettare il primo. Un prodotto ottiene il
livello ZigBee Certified Product superando uno dei seguenti due test:
 ZigBee Manufacturer Specific Profile Test Program, questo test dimostra che il
prodotto opera in un sistema chiuso ma è capace di coesistere con altri prodotti
ZigBee,
 Public Profile Test Program, questo test dimostra che il prodotto assicura
l’interoperabilità con altri prodotti ZigBee.
Un profilo applicativo è un insieme di applicazioni che condividono gli stessi messaggi

e usano gli stessi comandi per comunicare l’una con l’altra. La ZigBee Alliance fornisce
vari profili applicativi, chiamati Public Application Profiles , ognuno dei quali è
inerente ad uno specifico settore di mercato (Home Automation, Commercial Building
Automation, and Industrial Plant Monitoring, Telecom Applications, ecc.). In
alternativa ai profili pubblici, la ZigBee Alliance riconosce la possibilità a produttori di
13
usare dei profili privati, chiamati Manufacturer Specific Application Profiles, per
confezionare l’applicazione secondo le proprie necessità.
Riassumendo la ZigBee Alliance fornisce gli alti livelli della pila protocollare, i profili
applicativi, i test di conformità e di certificazione e il marchio.
2.1. Descrizione
Questo paragrafo affronta in maniera generale lo standard ZigBee e cerca di fornire una
visione globale per evitare di appesantire la descrizione con le specifiche tecniche.
2.1.1. Caratteristiche
ZigBee permette di produrre dispositivi a basso costo grazie alla semplicità del
protocollo da implementare che richiede limitate risorse hardware. In particolare è
possibile scegliere il tipo di nodo in base al ruolo che esso avrà nella rete. Nel paragrafo
successivo verrà introdotta la distinzione tra FFD (Full Function Device) e RFD
(Reduced Function Device).
ZigBee garantisce consumi limitati quando i nodi sono attivi in trasmissione/ricezione

e permette modalità di risparmio energetico (dieci volte inferiori ai periodi di attività),
in cui il nodo può essere messo in stato dormiente (sleep mode) e risvegliarsi, per
esempio in base ad un timer prestabilito; questo consente di avere tempi di vita dei
dispositivi medio-lunghi, che arrivano anche ad alcuni anni per quelle applicazioni in
cui il nodo ha un “tempo di attività” (duty cycle) basso: un esempio potrebbe essere una
rete di sensori distribuiti sul territorio per il monitoraggio di parametri ambientali, in cui
i nodi si risvegliano solo per il tempo necessario alla trasmissione dei campioni
prelevati.
ZigBee opera su frequenze libere della banda UHF (868 e 915 MHz) e ISM (2.4 GHz),
con velocità di trasmissione dati che arrivano al massimo a 250 kbit/s. Il raggio di
azione non supera le decine di metri su single-hop, ma si estende a chilometri se si
sfrutta il multi-hop, cioè la possibilità di far transitare l’informazione da un nodo
all’altro fino al nodo destinazione, che, non trovandosi nel raggio d’azione del nodo
sorgente, non può essere raggiunto direttamente.
ZigBee assicura la scalabilità permettendo la formazione di reti ad hoc

autoconfigurabili, in cui i nodi si uniscono ad una rete e scoprono in maniera automatica
14
il loro ruolo all’interno della rete stessa, e pervasive, con un numero di nodi molto
elevato (nominalmente fino a 65536). Sono previste diverse tipologie di reti che non si
limitano a semplici configurazioni a stella (star), ma supportano anche reti magliate
(mesh) e reti a tipologia mista (cluster tree). Queste tre tipologie di rete verranno
esaminate nei prossimi paragrafi.
ZigBee supporta l’utilizzo della tipologia di rete mesh che permette di massimizzare
l’affidabilità complessiva della rete, garantendo la possibilità di distribuire
l’informazione su percorsi diversi. L’instradamento dei messaggi è sempre possibile
anche quando la topologia della rete cambia a causa della perdita di un nodo. Questa
caratteristica deriva dalla capacità delle reti ad-hoc di essere auto configurabili. Le
quattro immagini sottostanti della figura 3 rappresentano in sequenza cosa accade
quando dei nodi scompaiono dalla rete.
Per fornire l’interoperabilità tra prodotti di fornitori diversi, la ZigBee Alliance

prevede la creazione di profili applicativi standard: il primo profilo che verrà
standardizzato sarà quello di automazione domestica per il controllo di impianti di
illuminazione, di riscaldamento e condizionamento e di altri sensori ed attuatori
utilizzabili in ambito residenziale. Per i dettagli vedere il paragrafo “Enhanced ZigBee
(2006)”
Dal punto di vista della sicurezza la protezione dei dati è garantita da algoritmi di
crittografia avanzati (AES a 128 bit) e da meccanismi di integrità e autenticazione per
proteggere il tutto da eventuali attacchi provenienti da dispositivi non autorizzati che
tentano di accedere alla rete o al contenuto informativo trasmesso. E’ definito anche un
concetto di Trust Center, per la gestione centralizzata della sicurezza, a livello di
politiche e aggiornamento delle chiavi crittografiche.
15
Figura 3 Routing reattivo in una rete mesh
2.1.2. ZigBee vs Bluetooth

Spesso si sente parlare di Bluetooth (IEEE 802.15.1) e di ZigBee come di due
tecnologie radio per reti wireless che si competono.
Bluetooth ha origine nel 1994 dall’esigenza di Ericsson di proporre accessori wireless

per la trasmissione vocale e per il trasferimento di dati digitali tra PC, telefoni e altri
dispositivi elettronici. Inizialmente la tecnologia Bluetooth è stata concepita per
sostituire i cavi di collegamento, ma poi si è affermata anche per realizzare piccole reti
locali in grado di riconfigurarsi automaticamente man mano che si presentano nuovi
dispositivi nell’area di copertura. I dispositivi hanno un raggio utile di comunicazione di
circa 10 m in linea d’aria (100 m con Bluetooth 2) che si riduce in presenza di ostacoli.
Bluetooth è stato pensato per connettere tra loro un numero limitato di dispositivi. Ogni
singola rete Bluetooth, detta piconet, è dinamica e gestisce autonomamente l’ingresso e
l’abbandono delle periferiche, ma ha una struttura master-slave che impone la presenza
di un’entità centrale, il master, con il compito di gestire le altre periferiche. In una
piconet non possono essere presenti più di sette slaves attivi per ogni istante di tempo
(esistono meccanismi per il cambio di stato degli slaves da ready a parked). Se si vuole
quindi creare una rete con più di otto dispositivi attivi contemporaneamente è necessario
16
unire più piconet, creando una scatternet, ad esempio creando una gerarchia di master o
facendo condividere a due o più masters uno stesso slave. Tali soluzioni sono
sconsigliate per l’elevata latenza di trasmissione. In confronto Zigbee prevede la
possibilità di connettere al più 65536 nodi attraverso un unico coordinatore di rete
utilizzando la modalità di indirizzamento ridotta.
Bluetooth è un protocollo complesso la cui implementazione occupa circa 250 KByte di

memoria, contro quella di Zigbee che ne richiede solo 28 KByte per la versione
completa e appena 4 KByte per la versione da usare sui dispositivi più elementari (gli
“end devices”). La sua complessità è in effetti legata alla possibilità di supportare
pienamente le trasmissioni bidirezionali real time che richiedono un bit rate abbastanza
elevato: la tipica applicazione è quella degli auricolari wireless. Nella figura 4 è
presente a lo sinistra stack ZigBee e a destra lo stack Bluetooth.
Figura 4 Confronto tra lo stack ZigBee e lo stack Bluetooth
ZigBee, d’altra parte, è ottimizzato per connettere un elevato numero di dispositivi che
comunicano sporadicamente tra di loro e che per le loro comunicazioni non necessitano
di banda elevata (ZigBee offre 250 Kbit/s, mentre Bluetooth arriva ad 1 Mbit/s). Inoltre,
le modeste prestazioni richieste ad una rete ZigBee permettono di avere una logica di
elaborazione meno costosa di Bluetooth.
Il seguente grafico rende l’idea dell’esatta collocazione di Zigbee e di Bluetooth

nell’ambito del wireless.
17
Figura 5 Collocazione degli standard wireless in base a distanza e capacità
tramissiva
I dispositivi Bluetooth hanno consumi paragonabili a quelli ZigBee quando la radio è

usata per ricevere o trasmismettere dati. La differenza si fa più marcata quando il
dispositivo entra in modalità parked per Bluetooth e in modalità sleep per ZigBee.
Infatti, i dispositivi Bluetooth, quando sono in modalità parked, devono continuare a
mantenersi sincronizzati con il master e questo implica comunque un dispendio di
energia. I dispositivi ZigBee, invece, non hanno bisogno di rimanere sincronizzati,
possono invece decidere di “svegliarsi” a loro piacimento. Questo vantaggio di ZigBee
sembra sottile ma, essendo i dispositivi ZigBee pensati per applicazioni con un tempo di
attività molto basso, questo vantaggio diventa enorme e permette durate di batteria
considerevoli, anche di anni. Viceversa, i dispositivi Bluetooth hanno la necessità di
ricaricare frequentemente la batteria.
Per quanto riguarda i tempi, Bluetooth impiega 3 s per unirsi alla rete, 20 s per il
riconoscimento di tutti i dispositivi, ma soli 2 ms per accedere al canale. ZigBee
garantisce tempi di risveglio e di enumerazione dei dispositivi in rete di circa 30 ms,
contro tempi di accesso al canale di 15 ms. La latenza impiegata da Bluetooth lo rende
inaccettabile per applicazioni di monitoraggio o attuazione.
Di seguito viene riportata una tabella in cui sono riassunte le caratteristiche dei due
standard a confronto.
18
Frequency 868 MHz (in Europa) 2.4 GHz
915 MHz (in America)
2.4 GHz (worldwide)
Range 10-100 m 10 m
Data rate 20 kbits/s 1Mbits/s

40 kbits/s
250 kbits/s
Network join time 30ms 3s
New slave enumeration 30ms 20s
Sleping slave changing to 15ms 3s

active
Active slave channel access 15ms 2ms
Power profile year days
Network topology ad-hoc, star, mesh, cluster ad-hoc, piconet

tree
Number of devices per <65000 <8

network
Protocol stack 28 KByte 250 KByte
Tabella 1 Caratteristiche di ZigBee contro quelle di Bluetooth
Le differenze principali di ZigBee rispetto alla tecnologia Bluetooth, si possono

riassumere nella realizzazione di dispositivi a minore dissipazione di energia e con più
efficienti caratteristiche di connettività di rete, intese come una veloce riconfigurabilità
della rete stessa nel caso di caduta o aggiunta di un nodo ed un maggior numero di
dispositivi connessi.
Un vantaggio fondamentale di ZigBee, rispetto al Bluetooth, è la sicurezza che viene

garantita a tutti i livelli della pila protocollare, abilitando anche servizi nell’ambito dei
pagamenti e delle transazioni private, in cui la protezione dei dati è cruciale.
19
Tra le periferiche per PC, come mouse e tastiere, Bluetooth ha scarso successo a causa
dei suoi elevati costi e complessità e Zigbee può essere considerato come un potenziale
concorrente perché è più economico e prolunga la durata delle batterie.
In definitiva, realizzazioni Bluethooth in semplici applicazioni, richiederebbero un costo

del singolo nodo potenzialmemente anche più elevato della periferica collegata (ad
esempio un sensore), il che risulterebbe decisamente anomalo; in aggiunta un consumo
di energia eccessivo penalizzerebbe tali sistemi in termini di praticità e di costo.
Per questi motivi, Bluetooth e ZigBee sono da considerarsi come due tecnologie
complementari, concepite per ambiti applicativi diversi.
2.1.3. Applicazioni
Il campo di applicazione è vastissimo sia in ambito “indoor” che “outdoor” e va dalla
domotica all’automazione industriale, dall'elettronica di consumo al Machine to
Machine (M2M), fino alle reti di sensori per il monitoraggio dell’ambiente. Nella figura
6 sono indicate le principali aree applicative, tra cui particolarmente interessanti sono
anche gli utilizzi nel settore dell’health-care per la teleassistenza ed il monitoraggio dei
pazienti in ambito bio-medicale, ma in generale per applicazioni in cui i sensori ZigBee
sono pensati per migliorare la qualità della vita di ciascun individuo.
20
Figura 6 Ambiti applicativi di ZigBee
I prodotti commerciali presenti in ambito domestico che possono usufruire della

tecnologia ZigBee per il settore Home Automation includono i dispositivi di
illuminazione, gli apparecchi di controllo dell’impianto di riscaldamento e
condizionamento, gli apparati di allarme antintrusione, i telecomandi dei sistemi di
intrattenimento, ecc. come già introdotto nei precedenti paragrafi.
Figura 7 Home Automation
21
In ambito Commercial building automation valgono circa le stesse idee che valgono
per l’home automation ma si immagina che questo settore sia quello che più di tutti
possa trarre benefici in termini non solo di possibilità di controllo dettagliato dei vari
sistemi ma soprattutto in ottica di risparmio energetico: basti pensare al risparmio in
termini di denaro dovuto alla capacità di controllore i sistemi di illuminazione, di
riscaldamento e condizionamento in base alla presenza fisica. Da non trascurare poi
l’opportunità di controllare gli accessi, i sistemi di sicurezza (antintrusione, antincendio,
ecc.).
I benefici della connettività semplice, economica, a basso consumo offerta dalla

tecnologia ZigBee può essere indirizzata anche verso applicazioni di Industrial plant
monitoring. Nel settore industriale questa tecnologia può introdurre miglioramenti
nella gestione dell’energia, della logistica e del tracciamento dei prodotti nonché nella
sicurezza e nel controllo degli accessi. ZigBee può anche essere impiegato per il
controllo degli impianti di produzione.
Figura 8 Industrial plant monitoring
Per non trascurare il motivo per cui sono nate le WSN, ZigBee prevede il profilo
applicativo Wireless sensor applications con il quale dettare le specifiche per il
monitoraggio ambientale, come boschi, aree agricole e urbane, o di strutture artificiali
come ponti, dighe, gallerie, edifici e monumenti artistici.
La ZigBee Alliance intende allargare lo standard per coprire i seguenti campi di

applicazione.
22
Il profilo applicativo Telecom Applications coprirà la necessità degli operatori di
telecomunicazioni di offrire nuovi servizi a valore a aggiunto (i cosiddetti Value Added
Service) basati su reti ZigBee. Casi d’uso che coinvolgono i terminali mobili possono
essere il controllo e il monitoraggio remoto della casa, la consegna di messaggi relativi
al contesto in cui ci si trova l’utente (sia di carattere informativo sia pubblicitario),
l’introduzione di nuove forme di pagamento elettronico, l’integrazione dei dispositivi
mobili con infrastrutture dedicate alla salute (trattate poche righe più avanti) e lo
sviluppo di nuovi giochi multiplayer.
Il profilo applicativo Automatic Meter Reading riguardarà l’ambito commerciale e

residenziale dove sarà possibile automatizzare la procedura di lettura dei contatori delle
forniture come acqua, corrente elettrica e gas, avvalendosi della tecnologia ZigBee per
raccogliere e trasferire tali dati alle centrali per l’analisi e la fatturazione dei consumi.
In futuro sarà possibile monitorare le funzioni vitali del corpo umano come l’attività
cardiaca o respiratoria mediante sensori sia per scopi terapeutici (monitoraggio dei
pazienti sia in ospedale sia in casa) sia per scopi sportivi (monitoraggio delle prestazioni
di un atleta): a tale fine ZigBee prevede uno specifico profilo chiamato Personal/home
health care.
Le previsioni annunciano che questo standard riguarderà anche il mondo

dell’automobile con un profilo Automotive: le principali applicazioni si dividono in
due sotto insiemi: il primo sottoinsieme contiene le applicazioni che usano la tecnologia
wireless per far comunicare i veicoli tra di loro (inter-vehicle comunication), il secondo
contiene le applicazioni che usano la tecnologia wireless per far comunicare i dispositivi
interni ad un veicolo (inter-vehicle comunication). Esempi del primo caso sono il
monitoraggio del traffico o di situazioni di pericolo, mentre del secondo caso sono il
collegamento dei dispositivi dell’auto per il controllo delle sue funzioni.
23
2.2. ZigBee 2004
Questo paragrafo è destinato a scendere maggiormente nel dettaglio dello standard. A
questo scopo si introduce direttamente l’immagine seguente che illustra la pila
protocollare ZigBee. I successivi sottoparagrafi analizzano i rispettivi livelli
concentrando l’attenzione sugli aspetti che hanno maggiore attinenza al lavoro di tesi
descritto nei capitoli 3 e 4.
Figura 9 ZigBee stack
2.2.1. Standard 802.15.4

Lo standard IEEE 802.15.4 è stato approvato nell’estate del 2003 e definisce il
protocollo di interconnessione, tramite comunicazione radio, tra diversi dispositivi
rientranti in una “Personal Area Network”. Esso definisce le specifiche del livello fisico
(PHY) e datalink (MAC) e si differenzia dal più popolare 802.11 (Wi-Fi) perché si
focalizza su reti a basso traffico dati e basso consumo energetico (meno di 1 mW)
denominate Low Rate Wireless Personal Area Network, LR-WPAN. Lo standard
24
802.15.4, infatti supporta data rate compresi tra 20 e 250 kbps in funzione di quale delle
tre differenti radio frequenze viene usata al livello PHY (868 MHz, 915 MHz o 2.4
GHz). Il livello fisico si occupa di attivare o disattivare il ricetrasmettitore, di
selezionare e controllare il canale, di trasmettere e ricevere i pacchetti di informazione
attraverso il mezzo fisico (l’hardware). Il livello datalink si occupa di generare i segnali
di sincronizzazione (beacons) se il dispositivo è coordinatore (più avanti è presente una
descrizione dei tipi di dispositivi previsti dallo standard), di gestire la connessione o
disconnessione alla rete, di eseguire l’algoritmo CSMA/CA per evitare le collisioni tra
dispositivi che vogliono accedere al canale nello stesso momento e di fornire bassa
latenza alle applicazioni che lo richiedono tramite l’uso dei GTS, ovvero degli slot
temporali ad accesso prioritario.
Una LR-WPAN può includere due diversi tipi di dispositivi: FFD (Full Function
Device) e RFD (Reduced Function Device). I dispositivi FFD implementano l’insieme
completo delle primitive del livello MAC, mentre gli RFD ne implementano solo una
versione ridotta, pensata per svolgere compiti elementari in modo da limitare le risorse
hardware necessarie. Un dispositivo FFD può dialogare con dispositivi di entrambe le
categorie, mentre un RFD può comunicare solo con un FFD. Una rete LR-WPAN
prevede la connessione sullo stesso canale fisico di almeno due dispositivi di cui almeno
uno deve essere un FFD per svolgere il compito di coordinatore della rete stessa. Un
dispositivo può eleggersi coordinatore semplicemente per essere il primo a comunicare
su un canale. E’ possibile anche che possano coesistere reti indipendenti nella stessa
regione di spazio operanti sullo stesso canale fisico. Allo scopo di evitare conflitti con
reti già precedentemente stabilite il coordinatore sceglie un identificatore di rete (PAN-
ID) grazie al quale è possibile gestire la comunicazione sia all’interno della stessa PAN,
sia tra PAN diverse. Ogni dispositivo interno alla rete possiede un indirizzo esteso a 64
bit detto “indirizzo MAC”.
Per la sincronizzazione lo standard prevede due modalità: "beacon mode”, se il

coordinatore invia in broadcast il beacon ad intervalli regolari, e “non-beacon mode”, se
il coordinatore trasmette il beacon in unicast ad ogni dispositivo che ne faccia richiesta.
Nel primo caso i nodi di tipo RFD possono entrare in sleeping mode tra una
segnalazione e la successiva. Nel secondo caso i routers devono rimanere sempre attivi
per ricevere i pacchetti dei nodi di tipo RFD che trasmettono solo quando necessario.
25
La modalità di formazione di una PAN rientra nel livello di rete (network layer)
previsto da ZigBee, per questo motivo si introduce il paragrafo successivo.
2.2.2. ZigBee Network Layer

I livelli della pila protocollare che seguono fanno parte della specifica dello standard
ZigBee. Ripartendo da quanto detto sullo standard 802.15.4 trattiamo ora i dispositivi
dal punto di vista del livello di rete. ZigBee prevede tre tipi di nodi (Logical Device
Types): ZigBee Coordinator (ZC), ZigBee Router (ZR), ZigBee End Device (ZED). Lo
ZigBee coordinator corrisponde al coordinatore di PAN già introdotto a livello MAC;
esso si occupa della formazione della rete: ogni dispositivo che vuole entrare a far parte
della rete effettua una richiesta alla quale, inizialmente, solo il ZC può rispondere.
Alcune tipologie di rete prevedono l’uso di ZigBee Router (denominato coordinatore
nella specifica IEEE 802.15.4); il loro compito è quello di instradare i messaggi che non
possono raggiungere la destinazione direttamente (multi-hop). Essi possono associarsi
direttamente al coordinatore oppure ad un loro simile precedentemente associato. Sia lo
ZC che il ZR devono necessariamente essere di tipo FDD. Lo ZigBee Coordinator ha
anche il compito di gestire la sicurezza (Trust Center) e ha la funzione di router. Gli
ZigBee End Devices, invece, sono nella maggior parte dei casi degli RFD e tipicamente
sono dispositivi attenti al consumo di energia (si pongono in sleeping mode per la
maggior parte del tempo) che non possono instradare i messaggi e che non permettono
l’associazione di altre entità alla rete.
Il processo di associazione di ognuno di questi dispositivi prevede l’assegnazione di un

indirizzo di rete a 16 bit (network address o short address) da utilizzare al posto
dell’indirizzo IEEE dell’802.15.4 per alleggerire la dimensione del pacchetto, diminuire
il tempo di trasmissione e aumentare di conseguenza la durata della batteria.
ZigBee supporta topologie di reti a stella, ad albero e a maglia. Le reti a stella sono
controllate dal coordinatore e non prevedono la presenza di router. Le reti ad albero,
dette anche cluster tree, hanno una struttura gerarchica con alla radice il coordinatore e
si avvalgono degli ZR per estendere la copertura attraverso l’instradamento multi-hop.
Le reti mesh sono organizzate in maniera decentralizzata: ogni ZigBee Router è
connesso ad uno o più ZigBee Routers o ZigBee End Devices.
26
Figura 10 Tipologie di rete
Le reti di tipo mesh non usano modalità di sincronizzazione (“non beacon mode”) che
garantisce alta dinamicità della rete e capacità di riassetto della topologia in tempi
contenuti. Le reti cluster tree invece adottano la modalità “beacon mode” e risultano più
efficienti dal punto di vista energetico. Tipicamente i router di una rete mesh devono
essere alimentati costantemente e sono in grado di memorizzare i pacchetti destinati ai
ZED a loro associati finché questi ultimi non si “svegliano”.
Il compito principale di questo livello è l’instradamento dei pacchetti (routing). Quando

un pacchetto raggiunge questo livello (sia esso proveniente dal basso o dall’alto della
pila protocollare), e la destinazione è diversa dal nodo stesso, il router controlla, tramite
la tabella dei vicini, se tale pacchetto deve raggiungere un nodo ad esso associato
direttamente (detto anche “figlio”). In caso positivo il pacchetto verrà recapitato appena
possibile, altrimenti si interroga se esiste un riga nella tabella di routing che corrisponda
con la destinazione. In caso positivo il pacchetto verrà inoltrato al nodo indicato nel
campo “next hop” di questa riga; in caso negativo, e se c’è ancora spazio disponibile
nella tabella di routing, si usa una versione semplificata del protocollo di routing Ad-
Hoc On Demand Distance Vector (AODV). Esso appartiene ai protocolli di routing
reattivi che forniscono la rotta su richiesta mediante la propagazione in broadcast di un
messaggio di “route request” alla quale il destinatario risponde in unicast con un
messaggio di “route reply”. Le potenziali rotte sono valutate in base ad una metrica di
costo e tutti i nodi attraversati dal messaggio di ritorno aggiornano la propria tabella.
Nel caso in cui non sia possibile generare una rotta usando l’AODV, si adotta la tecnica
27
del tree routing o instradamanto gerarchico. Questo si basa sull’algoritmo di
assegnamento degli “short address” chiamato Cskip che permette ad ogni device di
identificare velocemente se un particolare indirizzo si trova in un sottoalbero radicato in
uno dei sui figli oppure in una qualsiasi altra parte dell’intero joining tree.
Mesh routing
Tree routing
Figura 11 Tipologie di routing
Il principale beneficio del tree routing e la sua semplicità e il suo limitato uso di risorse.
Un router che usa questo algoritmo può svolgere la sua funzione semplicemente
guardando l’indirizzo di destinazione e scegliere se il successivo hop del pacchetto è
suo padre o uno dei suoi figli senza avere bisogno di memorizzare alcuna informazione.
Come conseguenza anche un router può essere implementato a basso costo e
mantenendo la conformità a ZigBee.
La specifica ZigBee offre la possibilità di configurare la rete scegliendo lo Stack Profile

più adatto all’area di applicazione: finora sono stati resi disponibili “Home Controls
Stack Profile”, “Building Automation Stack Profile” e “Plant Control Stack Profile”. Lo
stack profile può essere impostato dal coordinatore al momento di formazione della rete.
Ognuno di questi stack profile precisa i valori di alcuni parametri fondamentali come la
dimensione della rete, l’algoritmo di rounting impiegato, la dimensione delle tabelle di
routing e di binding (che verranno introdotte nel prossimo paragrafo) e la struttura dei
servizi di sicurezza. Tre sono i parametri di particolare interesse per il livello network:
la massima profondità della rete (nwkMaxDepth), il massimo numero di figli per router
(nwkMaxChildren) e il massimo numero di figli routers per router (nwkMaxRouters).
Congiuntamente questi valori determinano la struttura generale della rete. Lo scopo
28
degli Stack Profiles è, al solito, garantire l’interoperabilità tra dispositivi che aderiscono
allo stesso profilo. La tabella 2 che segue è stata presa dalla specifica ZigBee
[ZBSpec04] ed elenca i valori del Home Controls Stack Profile limitatamente al livello
network.
Tabella 2 Home Controls Stack Profile
Per concludere, questi punti riassumono i concetti base del livello network:
 Sono previsti tre tipi di dispositivi logici, ZigBee Coordinator, ZigBee Router e
ZigBee End Device.
 Si occupa di eseguire la formazione e la scoperta della rete.
 Si occupa dell’allocazione degli indirizzi.
 Si occupa dell’instradamento dei messaggi.
29
 Sono previsti degli Stack Profile che configurano la rete agendo su alcune
variabili.
2.2.3. Application layer

Come mostra la figura presente all’inizio del capitolo “2.2 ZigBee 2004” il livello
applicativo (APL) è formato dall’Application Support Sublayer (APS), il ZigBee
Device Object (ZDO) e da al massimo 240 Application Objects.
L’Application Support Sublayer è uno strato del livello applicativo che fornisce
principalmente due servizi: il trasporto dei messaggi applicativi tra due o più dispositivi,
attraverso l’interfaccia APS Data Entity, e la gestione del binding e di alcuni parametri
del livello APS stresso, tramite l’interfaccia APS Management Entity. La prima
interfaccia è disponibile sia agli Application Object, sia al ZigBee Device Object,
mentre la seconda è utilizzabile solo dallo ZDO.
Il ZigBee Device Object è una soluzione applicativa che ha il compito di inizializzare i

livelli dello stack ZigBee e di accogliere le richieste provenienti dagli Application
Objects per mezzo della ZDO Public Interface. Questa interfaccia presenta la possibilità
di effettuare la scoperta dei nodi della rete e delle loro funzionalità (device e service
discovery), la possibilità di stabilire un canale di trasmissione sicuro tra due dispositivi,
alcune funzionalità proprie del livello network e la gestione del binding. Il ZDO per
svolgere i suoi compiti si serve di due interfacce: APS Management Entity verso
l’Application Support Sublayer per quanto riguarda il binding e la gestione della
sicurezza e Network Layer Management Entity verso il livello di rete per quanto
riguarda l’inizializzazone del dispositivo, device e service discovery, ecc.
Gli Application Object si trovano alla posizione più alta della pila protocollare e sono
definiti dai produttori per implementare la propria applicazione. Ogni Application
Object è identificato tramite un indice, endpoint, che va da 1 a 240, usato
dall’Application Support Sublayer per la consegna di messaggi. Gli endpoint 0 e 255
vengono usati rispettivamente per indirizzare il ZDO e per la funzionalità di broadcast,
cioè per recapitare un messaggio a tutti gli Application Objects.
30
2.2.4. Comunicazione tra le applicazioni
Come descritto precedentemente, l’Application Support Sublayer fornisce il supporto
per far comunicare gli Application Object. In particolare, esso definisce la struttura di
comunicazione usata dalle applicazioni introducendo i concetti di Application Profile e
di Cluster.
Un Application Profile descrive una collezione di dispositivi impiegati per una specifica
applicazione ed espone lo schema di scambio di messaggi tra questi dispositivi. I
dispositivi che appartengono ad un Application Profile comunicano tra di loro per
mezzo dei Clusters. Un Cluster specifica l’insieme degli attributi e dei comandi
disponibili di un determinato dispositivo che lo implementa. Essi sono di ingresso (in)
se il dispositivo offre la funzionalità, di uscita (out) se il dispositivo può disporre della
funazionalità. Ogni Application Profile è identificato da un id e ogni cluster è
identificato da un id all’interno di un determinato Application Profile. La ZigBee
Alliance prevede l’esistenza di profili applicativi pubblici, cioè quelli rilasciati dallo
standard, e di profili privati, cioè quelli sviluppati dai produttori (si veda l’introduzione
di questo capitolo riguardo ai vari tipi di certificazione). Per esempio, nel profilo
applicativo Home Control Lighting esistono una serie di dispositivi di cui è determinato
il formato dei messaggi attraverso la specifica dei Clusters.
In figura è riportata una possibile conformazione di una primitiva rete: sono presenti
due dispositivi sui quali sono alloggiati diversi Application Object. Il primo device
contiene due interruttori, il secondo contiene quattro lampade e le frecce che collegano i
rispettivi Application Object rappresentano il canale di comunicazione (di cui l’origine
è il cluter out e la fine della freccia è il cluster in).
31
Figura 12 Indirizzamento diretto
Il meccanismo di indirizzamento si basa sulla conoscenza statica da parte degli

interruttori dell’indirizzo network (lo short address) e dell’endpoint delle lampade da
comandare oppure sulla possibilità di effettuare una device discovery della rete per
individuare le lampade. Questi meccanismi non permettono la possibilità di configurare
dinamicamente le associazioni e vincolano gli interruttori ad avere risorse, in termini di
memoria e capacità di calcolo, che non sono generalmente disponibili in quanto questi
dispositivi fanno parte della categoria degli End Device.
ZigBee risolve questi problemi introducendo l’indirizzamento indiretto per mezzo del
Binding. Il Binding consiste nel creare un collegamento logico tra un Application
Object e un altro Application Object grazie all’uso del concetto di cluster. In pratica
esiste una tabella di binding, residente nello ZigBee Coordinator, che tiene traccia delle
relazioni tra un cluster out di un AO e un cluster in di uno più AOs. La figura
rappresenta questa situazione: l’interruttore 1 invia il messaggio al coordinatore
specificano l’identificativo del profilo applicativo (profileID), l’identificativo del cluster
(clusterID), il suo indirizzo (sourceAddr) e il suo endpoint (sourceEP). Il coordinatore
accede alla binding table usando queste informazioni e ne trae gli indirizzi e gli
endpoints di destinazione che usa per spedire i messaggi (oppure il messaggio se il
destinatario è unico).
32
Figura 13 Indirizzamento indiretto
La gestione della tabella di binding avviene in genere con l’intervento dell’utente: in

fase di installazione è prevista la pressione di un pulsante per ogni dispositivo per il
quale si vuole effettuare il binding. Tali richieste perverranno al coordinatore che si
occuperà di aggiornare la tabella di binding controllando che tutti gli AO coinvolti
implementino lo stesso tipo di cluster. Come precedentemente visto, questa funzionalità
è offerta agli Application Object mediante alcune primitive della ZDO Public Interface.
33
2.3. ZigBee 2006
I dispositivi prodotti in conformità alla prima versione della specifica ZigBee sono
serviti sostanzialmente per fare esperienza con la tecnologia. Come esposto nel
precedente paragrafo, la versione 1.0 ha stabilito la struttura della pila protocollare e ha
delineato i principi di comunicazione dei moduli applicativi. Gli sviluppatori hanno
dovuto creare i propri profili applicativi privati in quanto l’unico profilo pubblico
presente al momento del rilascio della prima versione era Home Control Lighting che
riuniva alcuni dispositivi per l’illuminazione. Gli sforzi dell’alleanza sono proseguiti per
fornire le specifiche per altri profili applicativi (di cui è gia stata data una descrizione
nel paragrafo 2.1.3). Come scritto poche righe più in alto in questo capitolo, un
Application Profile è sostanzialmente un documento che presenta l’insieme e la
descrizione dei dispositivi relativi ad un certo ambito applicativo. Per ogni dispositivo
esso elenca e dettaglia i Cluster implementati dal device. I progettisti si sono accorti ben
presto che molti cluster sono affini a vari Application Profile ed hanno deciso di
raggrupparli sotto il nome ZigBee Cluster Library. Questa è la sostanziale novità che ha
portato, il 1 dicembre 2006, alla ratifica della nuova specifica “ZigBee 2006”
[ZBSpec06] che sostituisce la precedente (disponibile sul sito della ZigBee Alliance
[ZigBee.org]). Questa specifica ha assunto in via informale l’appellativo “ZigBee ver.
1.1” durante la progettazione ed ora viene denominata ufficialmente “Enhanced
ZigBee”.
Figura 14 Rapporto tra ZigBee Cluster Library ZigBee Profile
I cluster sono classificati in base al dominio funzionale di appartenenza. Essi sono

raccolti in domini diversi (“General”, “Lighting”, “HVAC”, “Measurement & Sensor”,
34
ecc.) e specificano per ogni cluster gli attributi, i comandi supportati e una descrizione
operativa. Gli Application Profiles (detti anche ZigBee Profiles) sono costruiti facendo
riferimento alle ZigBee Cluster Library: un profilo descrive i dispositivi di sua
competenza limitandosi ad elencare, per ciascuno di essi, i cluster implementati dal lato
server (precedentemente chiamati cluster in) e i cluster implementati dal lato client
(precedentemente chiamati cluster out).
La seguente tabella elenca alcuni i dispositivi finora previsti dal profilo Home
Automation.
Device Device ID
On/Off Switch 0x0000
Level Control Switch 0x0001
On/Off Output 0x0002
Level Controllable Output 0x0003
Scene Selector 0x0004

Generic
Configuration Tool 0x0005
Remote Control 0x0006
Combined Interface 0x0007
Range Extender 0x0008
Mains Power Outlet 0x0009
Reserved 0x000A – 0x00FF
On/Off Light 0x0100
Dimmable Light 0x0101
Color Dimmable Light 0x0102

Lighting
On/Off Light Switch 0x0103
Dimmer Switch 0x0104
Color Dimmer Switch 0x0105
Light Sensor 0x0106
Occupancy Sensor 0x0107
35
Reserved 0x0108 - 0x1FF
Shade 0x0200
Closures
Shade Controller 0x0201
Heating/Cooling Unit 0x0300
Thermostat 0x0301
Temperature Sensor 0x0302
Pump 0x0303
HVAC
Pump Controller 0x0304
Pressure Sensor 0x0305
Flow Sensor 0x0306
Control and Indicating Equipment 0x0400

Intruder Alarm Systems
Ancillary Control Equipment 0x0401
Zone 0x0402
Warning Device 0x0403
Reserved 0x0404 -0xFFFF
Tabella 3 Dispositivi previsti in Home Automation Profile
Prendendo i classici due dispositivi dimostrativi, l’interruttore e la lampada,

rispettivamente “On/Off Switch” e “On/Off Light” si comprende immediatamente il
ruolo che i cluster rivestono. Aggiungo una piccola nota per precisare che esiste anche il
dispositivo “On/Off Light Switch” ma almeno in questa versione di Home Automation
esso è identico a “On/Off Switch”. Il disegno di seguito riportato raffigura in maniera
essenziale il rapporto tra le due entità: i due dispositivi possono interagire grazie al fatto
di aver implementato, uno il client e l’altro il server, lo stesso cluster.
36
Figura 15 Schema di un cluster
Le due tabelle sottostanti sono tratte dal documento “Home Automation Profile
Specification” e servono a mostrare quali cluster i dispositivi in considerazione devono
implementare per essere conformi allo standard.
Tabella 4 Cluster supportati da On/Off Switch
37
Tabella 5 Cluster supportati da On/Off Light
Analizziamo ora il cluster “On/Off” (clusterID = 0x0006) la cui specifica è contenuta

all’interno del dominio “General”. La descrizione, come accade in tutte le altre, si
divide tra sever e client: entrambe le parti elencano gli attributi e i comandi generati e
ricevuti dal server (o dal client). Il server del cluster On/Off presenta un solo attributo,
nessun comando generato e tre comandi ricevuti. Il client non ha attributi né comandi
ricevuti (come nella maggior parte dei cluster) ma ha, di riflesso, come comandi
generati, gli stessi comandi ricevuti dal server. Si riportano le tabelle in originale.
Tabella 6 Attributi del server del cluster On/Off
38
Tabella 7 Comandi ricevuti dal server del cluster On/Off
Lo standard ZigBee stabilisce anche che alcuni server debbano poter notificare il valore
degli attributi, ad intervalli di tempo regolari, ad un altro dispositivo della rete: questo
servizio è noto sotto il nome di Attribute reporting. Il server del cluster On/Off dispone
dell’attributo OnOff che assume il significato di acceso quando è 1 e di spento quando è
0. Tale valore potrebbe essere notificato tramite il comando “Report Attribute” (di cui si
discuterà più avanti) a chi ne ha fa richiesta.
Quanto detto nel capitolo 2.2.4 non è più vero: l’identificativo associato ai cluster non
dipende dal profilo applicativo di appartenenza. Il clusterID ora identifica un cluster
globalmente e per garantire un quantitativo sufficiente di identificativi la nuova
specifica prevede che questo numero sia rappresentato su 16 bit invece che su 8 bit
come era nella specifica 2004. Questo rappresenta il vero limite alla retrocompatibilità
tra le due versioni in quanto modifica il formato dei messaggi applicativi.
L’esperienza maturata ha fatto anche rendere conto ai progettisti che non c’è nessun
motivo per cui l’Home Controls Stack Profile non possa essere adatto anche ad altri
contesti. Per questo motivo hanno deciso di mantenere nella nuova specifica 2006 solo
questo profilo chiamandolo semplicemente “ZigBee Stack Profile” eliminando
“Building Automation” e “Plant Control” che saranno inclusi in uno stack profile
dedicato.
Altra novità apportata in ZigBee è la creazione di gruppi di dispositivi: ogni AO può

indicare uno o più gruppi ai quali appartenere. L’APS mantiene, oltre al già citata
tabella di binding, una tabella dei gruppi (group table) che specifica per ogni gruppo gli
endpoint del nodo che gli appartengono. Un messaggio indirizzato ad un gruppo viene
trasmesso in broadcast (mulitcast per future versioni) e, raggiunto il livello APS di ogni
39
nodo, tale livello si occupa di consegnarlo agli Application Object registrati a quel
preciso gruppo o altrimenti scartato.
L’uso dei gruppi è congeniale all’impiego delle scene: le scene consistono nel
memorizzare tutti gli attributi di tutti i cluster di tutti gli AO facenti parte di uno
specifico gruppo. L’uso delle scene rende possibile compiere numerose azioni con un
solo comando utente. Un esempio di destinazione ambientato in casa è quello di
configurare i dispositivi per la notte: chiusura delle serrande, impostazione del sistema
antintrusione con esclusione della camera da letto, spegnimento di tutte le luci, ecc.
Per completezza è bene aggiungere che la ZigBee Alliance sta lavorando ad un’altra
specifica (versione “professional”) che affiancherà nel 2007 la versione in esame per
coprire mercati industriali. Tale versione sarà orientata a più grandi e sofisticate reti e
supporterà un metodo di indirizzamento casuale con risoluzione dei conflitti e quindi un
diverso algoritmo di routing che comporterà la mancata compatibilità con la versione
2006 a livello di rete [Gilles Thonet]. È stato infatti riscontrato che l’algoritmo
presentato precedentemente soffre di instabilità al crescere delle dimensioni della rete
limitando di fatto il numero teorico di 65 mila nodi [EETimes].
2.3.1. Formato del pacchetto ZCL

I frames ZCL sono trasmessi con l’uso della primitiva APSDE-DATA.request fornita
dal sottostrato applicativo APS. L’Application Object di destinazione riceve il pacchetto
tramite la primitiva destinatario APSDE-DATA.indication. Se è nella richiesta è
impostato il servio di acknowledgement, il destinatario riceve l’esito della richiesta
tramite la primitiva APSDE-DATA.confirm indicante il fallimento in caso di errato
recapito, il successo altrimenti. Prima di restituire un esito negativo l’APS aspetta lo
scadere di un timeout e provvede a ritrasmettere il pacchetto fino ad un numero
massimo di volte. Da notare il nome delle primitive rispetta sempre la forma
[interfaccia]-[servizio].[primitiva].
40
Figura 16 Trasmissione dati
Tale schema di trasmissione dei messaggi (usato anche negli altri livelli dello stack)
prevede in totale quattro primitive: request, indication, response e confirm. In generale,
un certo livello dello stack esegue una primitiva del livello inferiore con tipo request. Il
livello inferiore elabora la richiesta e la invia al corrispondente livello del nodo
destinatario. Sul nodo destinatario, il livello interessato dalla ricezione provvede ad
inoltrare la primitiva con tipo indication al livello superiore. Quest’ultimo produce la
risposta e chiama la primitiva del livello inferiore con tipo response. Il livello inferiore
del nodo destinatario si occupa di far arrivare la risposta al livello corrispondente del
nodo mittente ed sul nodo mittente la primitiva conclude il suo cammino tornando al
livello superiore con tipo confirm. A questo schema generale sono consentite due
eccezioni: la prima si ha quando la primitiva non coinvolge altri nodi e quindi si
esaurisce con una request e una confirm; la seconda si ha quando, come nel caso
precedente, il livello superiore non genera una risposta ed è sufficiente un riscontro di
avvenuta ricezione (acknowledgement) per generare la primitiva con tipo confirm.
Layer n+1 Layer n Layer n Layer n+1
request
indication
response
confirm
Figura 17 Tipi di una primitiva
La semantica delle primitive APSDE-DATA request e indication è la seguente:
41
APSDE-DATA.request { APSDE-DATA.indication {
DstAddrMode, DstAddrMode,
DstAddress, DstAddress,
DstEndpoint, DstEndpoint,
ProfileId, SrcAddrMode,
ClusterId, SrcAddress,
SrcEndpoint, SrcEndpoint,
asduLength, ProfileId,
asdu, ClusterId,
TxOptions, asduLength,
RadiusCounter asdu,
} WasBroadcast,
SecurityStatus
}
Il parametro “asdu” contiene il payload e l’acronimo sta per APS Data Unit. Un altro
parametro di interesse è il campo DstAddrMode che specifica il tipo di indirizzamento.
La specifica 2006 prevede, in aggiunta al metodo diretto e indiretto, anche
l’indirizzamento di gruppo: se questo parametro riporta il valore 0x01 allora il
parametro DstAddr contiene i 16 bit dell’identificativo del gruppo che verrà usato nella
maniera vista precedentemente. Altro parametro da specificare con la richiesta è
ClusterId: si tratta dell’identificatore del cluster usato dall’APS del nodo sorgente solo
nel caso di indirizzamento indiretto (per accedere alla tabella di binding), e
indubbiamente trasmesso all’APS del nodo di destinazione che eseguirà la primitiva
APSDE-DATA.indication.
Si coglie l’occasione per una breve digressione sul parametro DstAddrMode: tale
parametro è stato aggiunto anche alle primitive APSME-BIND.request e
APSMEUNBIND.request (e alle relative confirm) usate dallo ZDO per gestire, oltre alla
tabella di binding, anche la tabella dei gruppi.
Il payload di un pacchetto APS contiene un pacchetto ZCL. Il formato di un frame ZCL

è diviso in ZCL header (intestazione) e ZCL payload (carico informativo). La struttura
generale è illustrata nella prima tabella. La seconda tabella corrisponde al generico
pacchetto del livello APS (APDU - Application support sub-layer protocol data unit). I
numeri nella prima riga esprimono il numero di bit occupati dal campo.
42
2 1 1 4 0/16 8 8 Variable
Transaction
Frame Manufacturer Manufacturer Command Frame
Direction Res sequence
type specific code identifier payload
number
ZCL
ZCL header
payload
8 0/8 0/16 0/16 0/16 0/8 8 Variable
Destination Group Cluster Profile Source

Frame endpoint address identifier Identifier endpoint Aps Frame
control counter payload
Addressing fields
APS
APS header
payload
Figura 18 Pacchetto APS e ZCL
Il primo campo del pacchetto ZCL distingue il tipo di comando: questo può essere di
due tipi, o generico di tutti i cluster, oppure specifico di un certo cluster. I comandi del
primo tipo servono ad interagire con gli attributi dei cluster nei modi concessi. Ad
esempio il cluster On/Off ha la variabile booleana di sola lettura OnOff il cui valore può
essere letto attraverso il comando generico “Read attributes”, che permette anche la
richiesta di più di un attributo dello steso cluster. Segue l’immagine del formato del
payload di tale comando.
Figura 19 Formato del comando "Read attributes"
43
Il server del cluster On/Off che riceve il precedente messaggio provvede a restituire il
valore richiesto mediante il comando generico “Read attributes response”. Lo standard
ZigBee fornisce la descrizione del payload di tutti i comandi generici riportati nella
figura che segue. Quest’ultima riporta anche il rispettivo identificativo del comando
generico da inserire nel campo “Command identifier” nell’intestazione del pacchetto
ZCL.
Tabella 8 Elenco dei comandi ZCL generici
Per completare il cenno del paragrafo precedente sull’Attribute reporting occorre

segnalare il comando “Configure reporting” presente nella tabella che permette di
44
impostare il server per la notifica degli attributi, per i quali tale servizio è previsto,
specificando l’intervallo di tempo tra una notifica e la successiva. Il server provvede poi
a recapitare le notifiche generando un pacchetto ZCL contenente il comando “Report
attribute”.
I comandi del secondo tipo sono invece specifici del cluster a cui appartengono. Nel
precedente paragrafo è stata mostrata la tabella dei comandi del cluster On/Off: On, Off
e Toggle hanno associato un identificativo che va inserito nello stesso campo
dell’intestazione ZCL, cioè “Command identifier”, a cui è stato fatto riferimento poche
righe sopra parlando dei comandi generici,
Riepilogando, per questo lavoro di tesi sono stati presi in esame le seguenti sezioni
ZigBee inerenti le ZigBee Cluster Library:
 “Home Automation Profile Specification”, è la specifica del profilo “Home

Automation” contenente la descrizione dei dispositivi.
 “ZCL Foundation Specification”, sezione che descrive la struttura dei messaggi

disponibili per la manipolazioni degli attributi di tutti i cluster definiti attraverso
la ZCL.
 “ZCL Functional Domain: General”, sezione che descrive l’insieme dei cluster
sufficientemente generali da appartenere a diversi contesti funzionali.
 “ZCL Functional Domain: Measurement and Sensing”, sezione che descrive

l’insieme dei cluster per la valutazione di grandezze come l’illuminazione, la
temperatura, la pressione, l’umidità e della presenza umana.
 “ZCL Functional Domain: Lighting”, sezione che descrive l’insieme dei cluster
idonei a gestire funzionalità caratteristiche della luce come saturazione e colore.
 “ZCL Functional Domain: HVAC”, sezione che descrive l’insieme dei cluster
dedicati al riscaldamento, ventilazione e climatizzazione di luoghi chiusi
(HVAC sta per Heating, Ventilation and Air Conditioning).
 “ZCL Functional Domain: Closures”, sezione che descrive l’insieme dei cluster
destinati a controllare tipicamente dispositivi come serrande e imposte.
 “ZCL Functional Domain: Security and Safety”, sezione che descrive l’insieme
dei cluster rivolti a funzioni proprie degli allarmi antiintrusione.
45
3.
3. Stima del traffico di un ZigBee Home

Gateway
Sebbene le reti di sensori abbiano efficacia senza una connessione esterna, per
espandere la loro potenzialità è necessario dotarle di un metodo di comunicazione verso
Internet. Come accennato nell’introduzione, questo è compito del gateway. In generale,
un gateway è un dispositivo che permette a reti diverse di scambiare informazioni. Nel
caso specifico, il gateway a cui faremo riferimento mette in comunicazione la rete di
sensori ZigBee di una abitazione con la rete IP (Internet Protocol) fornita dall’operatore
di telecomunicazioni. Attraverso questo dispositivo è possibile interagire con la WSN in
maniera remota. Le applicazioni e i servizi offribili sono illimitati e l’operatore gioca un
ruolo di rilievo. Esso ha la possibilità di fornire l’accesso alla rete ZigBee in due modi:
 assicurando il trasporto su rete IP dei dati della rete di sensori che verranno
elaborati da applicativi di terze parti sviluppati in maniera verticale,
 costruendo una piattaforma di middleware sulla quale gli sviluppatori di

applicazioni per WSN possano creare i propri prodotti in maniera efficiente.
Queste due strade corrispondono a due diverse strategie di business: la prima si basata
sul traffico, la seconda sul servizio. Per comprendere meglio le potenzialità offerte dalla
prima strategia, è stata compiuta un’analisi del traffico veicolato dal gateway preso in
riferimento.
Figura 20 ZigBee Home Gateway
46
3.1. Scenario di monitoraggio remoto
Il profilo “Home Automation” esaminato nel precedente capitolo è il primo profilo
applicativo sviluppato dalla ZigBee Alliance ed ha lo scopo di standardizzare i
dispositivi dell’ambito residenziale. Nella tabella 3 sono elencati tutti i dispositivi finora
supportati dal profilo, raggruppati in cinque categorie: Generic, Lighting, Closures,
HVAC e Intruder Alarm System. Il gateway deve poter interagire con il maggior
numero possibile di dispositivi di una casa. Al fine di questa analisi il concetto di
gateway è stato considerato a livello applicativo come un dispositivo ZigBee
equivalente agli altri, astraendo da come avviene la connessione con il mondo IP. Per
rimanere comunque aderenti allo standard si è cercato il dispositivo più vicino alle
funzionalità di gateway: dall’elenco precedente è stato scelto il “Remote control”. La
figura sottostante è tratta dal documento di Home Automation Profile e mostra i cluster
implementati da tale dispositivo.
Server side Client side

Mandatory
None Basic
Identify
On/Off
Level Control
Groups
Scenes
Optional
Temperature Measurement Color Control
Illuminance Measurement Pump Configuration and Control
Illuminance Level Sensing Shade Configuration
Pressure Measurement On/Off Switch Configuration
Flow Measurement Temperature Measurement
Occupancy Sensing Illuminance Level Sensing
Illuminance Measurement
Tabella 9 Cluster supportati da Remote control
47
La specifica riporta che il Remote control è un dispositivo capace di controllare e
monitorare gli altri dispositivi come ad esempio accendere e spegnere una luce, leggere
la temperatura o impostare un termostato.
3.1.1. Remote control

Il Remote control può interfacciarsi con tutti quei dispositivi che implementano dal lato
server gli stessi cluster che esso implementa dal lato client. Per essere più chiari nel
capitolo precedente il dispositivo “On/Off Switch”, per il solo fatto di avere il cluster
“On/Off” dal lato client, è in grado di comandare tutti i dispositivi che implementano
tale cluster dal lato server e quindi anche la “On/Off Light”. La tabella 10 è servita a
trovare quali sono i dispositivi che il Remote control può comandare. In riga si trovano
tutti i dispositivi, cioè quelli della tabella 3, e in colonna si trovano i cluster del Remote
control del lato client. Se un dispositivo in riga implementa dal lato server il cluster in
colonna allora nella cella risultante dall’incrocio vi è una x, altrimenti la cella è vuota.
Cluster
Pump Configuration and Control
supported
by RC On/Off Switch Configuration
Temperature Measurement
Illuminance Level Sensing
Illuminance Measurement
at client
side
Shade Configuration
Level Control
Color Control
Identify
Groups
On/Off
Scenes
Basic
Device
On/Off Switch x
Level Control x
Switch
On/Off Output x x x
Level x x x x
Controllable
Output
Mains Power x x x
Outlet
On/Off Light x x x
Dimmable Light x x x x
Color Dimmable x x x x x
Light
48
On/Off Light x
Switch
Dimmer Switch x
Color Dimmer x
Switch
Light Sensor x
Occupancy
Sensor
Shade x x x x x
Heating/Cooling x x x x
Unit
Thermostat x x
Temperature x
Sensor
Pump x x x x x x
Pressure Sensor
Flow Sensor
IAS Control and x x
Indicating
Equipment (CIE)
Tabella 10 Dispositivi interfacciabili con un Remote control
Per avere una chiave di lettura della tabella occorre esaminare uno per uno i cluster in
colonna:
 Basic, questo cluster ha lo scopo di chiedere informazioni generali di un

dispositivo e quindi non è attinente né al monitoraggio né al controllo.
 Identify, questo cluster serve ad identificare un dispositivo (in genere mediante

l’accensione di un led) utile nei momenti dell’installazione. Anche questo non
attiene allo scopo.
 On/Off, questo cluster è stato abbondantemente esaminato e permette di

controllare parecchi dispositivi, tra i quali “On/Off Output” e “Level
Controllable Output”: questi sono dei dispositivi generici che permettono di
fornire o interrompere energia all’apparecchio a cui sono collegati (il secondo ha
anche la caratteristica di poter erogare diversi livelli di potenza).
 Level Control, questo cluster permette di impostare dei valori: con esso è
possibile configurare una intensità di luce di una “Dimmable light” o la potenza
del sopra citato “Level Controllable Output” ma anche di scegliere il grado di
chiusura di una serranda (“Shade”).
 Groups, di questo cluster si è già accennato ed esula lo scopo.

49
 Scenes, con il meccanismo delle scene è possibile richiamare contesti
precedentemente memorizzati ma ciò non rientra nel concetto di controllo.
 Color Control, questo cluster permette di comandare solo un “Color Dimmable

Light” regolando i valori di colore e saturazione.
 Pump Configuration and Control, si tratta di un cluster adatto a configurare solo

il dispositivo “Pump”, cioè a controllare l’irrigazione di giardino o simili.
 Shade Configuration, questo cluster permette di configurare solo le serrande

(“Shade”).
 On/Off Switch Configuration, si tratta di un cluster che configura gli interruttori

ma non da possibilità di controllo e perciò non è attinente.
 Temperature Measurement, serve a monitorare la temperatura dei relativi sensori

anche tramite attribute reporting (notare che un sensore di temperatura può
anche essere presente nell’irrigatore).
 Illuminance Level Sensing, questo cluster serve a monitorare se il livello di

illuminazione misurato è uguale, superiore o inferiore a quello impostato ma
come visibile dalla tabella non è implementato da nessun dispositivo in colonna.
 Illuminance Measurement, questo cluster ha lo scopo di restituire la quantità di

luce misurata da un sensore di illuminazione anche tramite attribute reporting.
A partire da queste considerazioni è possibile restringere l’insieme dei dispositivi

eliminando quelli che non interagiscono con il Remote control. I dispositivi elencati di
seguito non verranno considerati nel caso d’uso per i motivi descritti di volta in volta.
 “On/Off Switch”, “Level Control Switch”, “On/Off Light Switch”, “Dimmer

Switch”, “Color Dimmer Switch” sono diversi tipi di interruttori ma
condividono con il Remote control solo il cluster “On/Off Switch
Configuration” che non è utile allo scopo.
 “Occupancy Sensor”, questo dispositivo serve a monitorare la presenza di

persone negli ambienti ma, siccome il Remote control non ha il relativo cluster
“Occupancy Sensing”, non può essere collegato.
50
 “Thermostat”, questo dispositivo serve ad impostare la temperatura desiderata di
un “Heating/Cooling Unit” ma il Remote control il relativo cluster non può
essere comandata.
 “Pressure Sensor”, questo dispositivo è un sensore di pressione ma come il

precedente dispositivo non può essere controllato.
 “Flow Sensor”, questo dispositivo è un sensore di flusso di liquidi ma come per i

due precedenti dispositivi non può essere controllato.
 “Control and Indicating Equipment”, è il principale dispositivo impiegato nel

sistema antintrusione ma il Remote control non implementa né il cluster
“Ancillary Control Equipment” nè il cluster “Warning Device” e quindi non
può, rispettivamente, né interagire con esso né essere avvisato di un allarme.
3.1.2. Caso d’uso

Esaminate le caratteristiche del Remote control, le sue capacità e i suoi limiti, ed
individuati i dispositivi attivamente coinvolti in uno scenario di controllo remoto, è
possibile dare vita al caso d’uso. Per prima cosa occorre immaginare la composizione
tipica di una casa: il reparto giorno comprende sicuramente il salotto e la cucina mentre
il reparto notte il bagno e due camere da letto. In totale 5 vani. Sulla base di queste
ipotesi si prosegue con l’elenco dei dispositivi installati. Per semplificare la trattazione è
bene focalizzare l’attenzione solo sui dispositivi attivamente coinvolti dal monitoraggio
remoto. Per non perdere l’obiettivo si ribadisce che il fine ultimo è l’analisi del traffico
passante dal gateway. I dispositivi sono:
 1 On/Off Output, 1 Level Controllable Output: due elettrodomestici sono

controllati mediante questi dispositivi di cui uno dà la possibilità di regolare la
potenza.
 1 Main Power Outlet: questo è il dispositivo corrispondente all’interruttore

generale di corrente.
 3 On/Off Light, 2 Dimmable Light: ogni stanza ha una lampada per

l’illuminazione e due su cinque possono sono regolabili in intensità.
51
 1 Heating/Cooling Unit: la casa prevede certamente una unità di riscaldamento
e/o climatizzazione.
 5 Temperature Sensor, 5 Light sensor: in ogni stanza questi dispositivi

monitorano le temperatura e la luminosità.
 3 Shade: esistono in casa tre serrande motorizzate che hanno la possibilità di

essere comandate.
 1 Pump: un sistema di irrigazione delle piante del terrazzo.
Figura 21 Composizione tipica di una casa
52
3.2. Modello di traffico
Come discusso nel secondo capitolo, i messaggi ZCL si dividono in comandi generici e
comandi specifici. Per comodità chiameremo la seconda tipologia con il termine azioni.
Per quanto riguarda invece i comandi generici è necessario considerare che i comandi
come la lettura o la scrittura difficilmente verranno utilizzati in maniera programmata
perché in tal caso, cioè quando c’è il bisogno di avere notifica ad intervalli dei tempo
regolari, si preferisce usare il meccanismo dell’Attribute reporting.
Per stimare il traffico è necessario analizzare il formato del pacchetto di ogni comando
ZCL. Infatti il payload del pacchetto ZCL varia di comando in comando. Occorre altresì
definire quante volte in un arco temporale ogni pacchetto transita dal gateway. Per
organizzare queste informazioni si è reso necessario il ricorso ad un foglio di calcolo.
Figura 22 Frammento del foglio di calcolo
Per completezza nel foglio di calcolo sono inclusi anche i dispositivi in precedenza
scartati allo scopo di prevedere anche quelli per ora non supportati (ad esempio un
termostato).
53
La prima colonna contiene i dispositivi, la seconda i cluster lato server implementati del
dispositivo e la terza le operazioni supportate dal cluster. Per ogni operazione, le
successive tre colonne esprimono in ordine la dimensione in bit dell’intestazione, del
payload e del totale del pacchetto. Le prime sei colonne fanno riferimento a dati
oggettivi ricavati dalle specifiche. Le colonne successive invece sono frutto delle ipotesi
descritte in precedenza. La settima colonna infatti riporta le quantità dei dispositivi
presenti nella casa di riferimento. A seguire sono presenti quattro gruppi di tre colonne
ciascuno. Ogni gruppo rappresenta una fascia di sei ore della giornata. Si è pensato di
dividere le ventiquattro ore in fasce di sei ore per studiare anche le potenziali
concentrazioni di traffico. Di ogni fascia, la prima colonna riporta il numero di volte
nelle sei ore che un dispositivo invia (o riceve) il comando ZCL in riga che coinvolge il
gateway: ad esempio il valore 1 indica che transita un solo pacchetto in sei ore. Si
rimandano alcune considerazioni fatte per la stima di tali valori ad una successiva
descrizione. La seconda e la terza colonna del gruppo contengono rispettivamente il
numero di pacchetti e il numero di bit complessivi trasmessi nell’intera fascia oraria da
tutti i dispositivi del tipo in riga. La prima si ottiene moltiplicando la prima colonna per
la colonna del numero di dispositivi presenti e la terza moltiplicano la seconda colonna
con la colonna della dimensione del pacchetto. Eseguendo la sommatoria di ciascuna
terza colonna, si ottiene il totale per fascia di bit inviati e ricevuti dal gateway.
Eseguendo invece la sommatoria di ciascuna seconda colonna si ottiene il totale sempre
per fascia di pacchetti trasmessi. Nel prossimo paragrafo si precisa il significato dei
risultati ottenuti. In figura 23 è mostrata la porzione di foglio di calcolo dei risultati
ottenuti.
54
Figura 23 Frammento con i risultati ottenuti
3.2.1. Stima del numero di pacchetti inviati

Come già detto, occorre definire per ogni fascia temporale quanti pacchetti, di ciascun
cluster, di ciascun dispositivo, transitano dal gateway. Questa è la fase più delicata del
lavoro al caso d’uso in quanto ogni scelta va motivata in modo adeguato. Occorre
spingere la visione fino a immaginare le possibili applicazioni che utilizzeranno il
gateway per interfacciarsi con la rete di sensori.
Si intuisce immediatamente che il meccanismo dell’Attribue reporting genera il

maggiore volume di pacchetti. Almeno per quanto riguarda l’ambito domestico, l’uso
dei comandi specifici da impartire ai dispositivi è in effetti limitato.
L’utente potrebbe volere accendere e spegnere le luci della casa in modo da simulare la
propria presenza (cosa poco intelligente ma comunque possibile); potrebbe dovere
accendere l’impianto dell’acquario (o del terrario) in un momento della giornata in cui è
assente prendendosi cura dei suoi amici animali senza tornare a casa; riuscirebbe a
chiudere le serrande prima dell’arrivo di un temporale; sarebbe in grado di accendere
l’impianto di irrigazione la sera prima di rientrare a casa. Un utente difficilmente esegue
queste operazioni tutti i giorni ma in ogni modo disporrebbe dei mezzi per farlo. Nel
compilare il foglio di calcolo si è tenuto conto, in un certo senso, del caso peggiore.
Il ragionamento si fa più interessante quando si passa ad esaminare le notifiche che i

dispositivi inviano al mondo esterno. Il caso più evidente è quello del monitoraggio
55
della temperatura o della luminosità. L’utente ha la possibilità di visualizzare tali dati
delle diverse zone della casa mediante i relativi sensori. Questa informazione è
campionata dal modello una volta ogni ora ovvero sei volte per fascia temporale. I
dispositivi “Output” potrebbero inviare il loro stato, vale a dire se forniscono o meno
alimentazione all’apparecchio al quale sono collegati, ogni ora in modo da generare un
allarme nel caso che, ad esempio, il congelatore rischi di scongelarsi. A scopo di
statistica invece le lampade possono essere programmate in modo da inviare il loro stato
ogni trenta minuti e da questa statistica poi scegliere la tariffa elettrica più conveniente.
Tutte queste informazioni apparentemente di scarso valore potrebbero rivelarsi utili in
futuro per creare ad esempio offerte commerciali aderenti all’utenza.
Tale modello di monitoraggio e controllo trova anche applicazione per le cosiddette

seconde case: appartamenti al mare o chalet di montagna che per la maggior parte del
tempo risultano disabitati. Controllare la temperatura, accendere il riscaldamento,
ricevere allarmi dal sistema antintrusione, ecc. sono tutti servizi di valore.
La figura seguente è stata ottenuta nascondendo le colonne di minore interesse per

focalizzare le colonne contenenti le scelte effettuate. L’immagine è limitata ai
dispositivi della categoria “Generic” in verde scuro, “Lighting” in giallo e “Closures” in
verde acqua.
56
Figura 24 Visualizzazione del foglio di calcolo ottenuta nascondendo alcune
colonne
57
3.3. Risultati e conclusioni
Assumendo gli usi tipici di monitoraggio e di controllo remoto dei dispositivi presenti
in un’abitazione e ponderando svariate ipotesi è stato elaborato un modello dal quale si
ottengono dei valori di traffico assoluti sia in termini di byte sia in termini di pacchetti.
Questi risultati sono mostrati nella figura 22 e il grafico successivo esprime al meglio il
fenomeno: come era immaginabile, la quantità di dati che interessano il mondo esterno
è di modesta entità e si attesta intorno ai 1200 byte per tutte le fasce temporali
considerate. Anche il numero di messaggi raggiunto, circa 200, corrisponde al basso
traffico.
Figura 25 Risultati
Per completare l’interpretazione di questi risultati occorre specificare

l’implementazione del gateway. Il traffico in questione ha luogo sul lato di interfaccia
con la rete di sensori e il gateway ha il compito trasferirlo sul lato di interfaccia con la
58
rete IP detenuta dall’operatore di comunicazioni. Il gateway nello svolgere questo suo
compito di trasporto potrebbe usare un pacchetto TCP per ogni pacchetto ZCL oppure
aggregare più pacchetti ZCL in un unico pacchetto TCP. Occorre considerare perciò,
oltre al throughput, il numero di pacchetti ricevuti/inviati per avere una stima migliore
del traffico ottenuto sulla rete IP.
In questo caso entrambe i valori sono bassi e non generano un traffico sulla rete IP tale
da poter spingere l’operatore di telecomunicazioni ad orientare il business su tale
traffico. La scelta più interessante diventa quella di offrire un piattaforma di servizi
sulla quale gli sviluppatori di applicazioni possano costruire la propria applicazione.
Tale struttura ha senso proprio grazie all’uso dello standard ZigBee.
Il foglio di calcolo, per come è stato realizzato, ha il vantaggio di essere flessibile: è

possibile aggiungere nuovi dispositivi, variare il numero dei dispositivi esistenti e
modificare la frequenza dei messaggi scambiati in maniera rapida. Questo rende il
modello facilmente adattabile ai nuovi ambiti applicativi che usciranno in futuro.
Infatti tale analisi è attinente solo al profilo Home Automation ed al caso d’uso preso in
esame. Per profili come Wireless Sensor Application, Commercial Building
Automation o Industrial Plant Monitoring i risultati potrebbero essere molto diversi a
causa del diverso peso che avrà l’Attribute reporting.
59
4. Gateway Reference Implementation
Questo capitolo descrive la parte principale del lavoro di tesi: lo sviluppo di un gateway
per reti di sensori ZigBee. L’applicazione realizzata in realtà è un prototipo utile ad
esplorare da un punto di vista pratico le caratteristiche di un gateway.
In base all’analisi oggetto del terzo capitolo, l’operatore di telecomunicazioni ha scelto

di sviluppare una piattaforma di servizi per Wireless Sensor Network che ha chiamato
WSN-C (Wireless Sensor Network Center).
Service Service Service
WSN-C
Service
Platform
Internet
Gateway
Abstraction
Layer
Figura 26 Architettura di sistema
La figura riportata illustra l’architettura del sistema: in alto si trovano gli utenti che
utilizzano dei servizi sviluppati dallo stesso operatore di telecomunicazioni o da terze
parti; tali servizi sono retti dalla piattaforma di servizio, la quale offre un’interfaccia
pubblica con lo scopo di astrarre il più possibile la rete di sensori; la WSN-C si serve di
60
un livello di astrazione chiamato Gateway Abstraction Layer (GAL), presente nel
gateway, che le consente di configurare, controllare e comandare la rete di sensori.
Il compito del gateway, infatti, è di semplificare l’accesso alle risorse della rete di
sensori unificando le numerose primitive ZigBee in più semplici funzionalità di alto
livello. Il Gateway Abstraction Layer offre alla piattaforma di servizio l’accesso alle
funzionalità del gateway. Si distinguono tre diversi gruppi di funzioni denominati
“Management and Commissioning”, “Service discovery” e “Service interface”. Fanno
parte del primo gruppo le funzioni relative sia alla gestione del tipo e della topologia
della rete, sia alla gestione dell’energia, della localizzazione e della sicurezza dei nodi.
Le funzioni appartenenti al secondo gruppo sono necessarie per scoprire quali sono i
servizi offerti dai nodi e dalla rete nel suo complesso, mentre al terzo gruppo
afferiscono le funzioni relative ai singoli servizi applicativi dei nodi.
Come già accennato nel paragrafo 1.1, l’operatore dispone di terminali come il modem
ADSL, il videotelefono o il set top box ai quali poter aggiungere un modulo ZigBee, per
interagire con la rete di sensori, e la logica del gateway, affinché possano esporre le
suddette funzionalità alla piattaforma sfruttando la già presente connettività IP.
Il gateway è composto, oltre che dal Gateway Abstraction Layer, anche dal Gateway
Device Object che rappresenta la logica vera e propria, vale a dire l’implementazione
della macchina a stati che gestisce le richieste pervenute al GAL.
REST è la tecnologia usata per l’interfaccia tra il GAL e la piattaforma WSN-C è di cui
si tratterà nel paragrafo 4.3.4.
Per quanto concerne invece l’interfaccia con la rete di sensori occorre specificare che il
gateway è in realtà un’applicazione ZigBee come, ad esempio, di un “On/Off Switch” e
in quanto tale utilizza un nodo fisico per l’acquisizione un indirizzo di rete (short
address). Essendo un Application Object, ciò di cui dispone quindi è la ZigBee Device
Object Public Interface e la Application Support Sublayer Data Entity Interface. A
differenza di un dispositivo ZigBee comune, il gateway ha maggiori risorse
computazionali che gli permettono di sostenere la superiore complessità applicativa ed è
in grado di remotizzare alcune funzionalità attraverso l’utilizzo della rete dell’operatore.
Come visto nel precedente capitolo, l’applicazione gateway implementa i cluster

necessari alla remotizzazione delle funzionalità dei dispositivi di una rete di sensori.
Con il termine remotizzazione si intende la possibilità, da parte della piattaforma di
61
servizi, di interagire con la WSN. Occorre precisare che la piattaforma di servizi è
capace di gestire molteplici gateway mediante l’uso di identificativi (ad esempio
indirizzo IP del gateway).
La figura riportata di seguito schematizza il rapporto tra la rete ZigBee, la rete IP e le

due entità del gateway (la tecnologia xDSL non appartiene al livello data link ma è
citata allo semplice scopo di intendere il tipo di connessione).
Gateway Device Object
Gateway Abstraction Layer ZDO
TCP Application Support Sublayer
IP ZigBee Network Layer
xDSL, GPRS, ecc. 802.15.4 PHY & MAC
Figura 27 Gateway stack
62
4.1. Gateway Abstraction Layer
Questo paragrafo tratta nei particolari le funzionalità implementate dal prototipo
sviluppato. Il GAL ha lo scopo di mascherare la complessità legata allo standard ZigBee
permettendo allo sviluppatore di creare i servizi svincolandosi dai problemi di
implementazione dei livelli più bassi. Occorre notare che questa architettura di sistema
permette interfacciarsi con reti diverse da ZigBee (ad esempio TinyOS), semplicemente
implementando un gateway adatto a tale proposito che esponga il GAL. Tuttavia,
prediligendo la soluzione standard, la progettazione del GAL trae ispirazione da ZigBee
e per questo motivo nei paragrafi a venire si fa riferimento alle strutture dati dello
standard.
4.1.1. “Management and Commissioning”

Il prototipo sviluppato fornisce solo una primitiva chiamata device discovery che
racchiude in se varie funzionalità: permette di determinare i nodi presenti in una rete, i
loro indirizzi e i loro nodi figli (ricostruendo così l’albero delle associazioni, cioè il
“joining tree”), e di conoscere le caratteristiche di ognuno di loro come il tipo di nodo
(coordinatore, router o end device), la sorgente di alimentazione (e l’eventuale livello di
carica della batteria), la banda di frequenza, ecc. Tali informazioni vengono
principalmente acquisite da due descrittori presenti i ogni nodo ZigBee:
 Node descriptor, le cui informazioni sono descritte nella tabella sottostante
Campo Descrizione
Logical type Tipo logico del nodo (Coordinator, Router, End device)
Complex descriptor available Indica se il complex descriptor è disponibile
User descriptor available Indica se l’user descriptor è disponibile
APS flags Non supportato
Frequency band Banda di frequenza (868, 902, 2400 MHz)
MAC capability flags Impostazioni del livello IEEE 802.15.4 MAC come il
tipo di dispositivo (FFD, RFD), l’alimentazione (da rete
elettrica o da batteria), il risparmio energetico (nei
periodi di inattività), il supporto alla trasmissione
cifrata
63
Manufacturer code Codice del produttore fornito dalla ZigBee Alliance
Maximum buffer size Specifica la dimensione massima dell’APS Data Unit
Maximum transfer size Non supportato
Server Mask Indica se il nodo è capace di gestire il TrustCenter, la

Binding Table e la Discovery Cache
Tabella 11 Node descriptor
 Power descriptor, le cui informazioni sono descritte nella tabella sottostante
Campo Descrizione
Current power mode Indica se il ricevitore del nodo è sempre attivo oppure è spento
solo nei periodi di inattività, oppure si attiva periodicamente
oppure si attiva su intervento dell’utente
Available power Indica le fonti di alimentazione disponibili (rete elettrica,

sources batteria ricaricabile, batteria usa e getta)
Current power source Indica quale tra le fonti di alimentazione disponibili è in uso
Current power source Indica il livello di energia della fonte di alimentazione in uso
level (critico, 33%, 66%, 100%)
Tabella 12 Power descriptor
Quelle sullo stato di carica delle batterie dei nodi sono informazioni utili ad
implementare, sulla piattaforma di servizio, applicazioni indirizzate alla sostituzione
preventiva delle batterie per assicurare all’utente una efficace manutenzione. estensioni
future del dimostratore potrebbero coinvolgere questa classe di funzionalità al fine di
includere la configurazione delle applicazioni, la localizzazione dei nodi, la gestione
della sicurezza e l’Over the Air Programming (OTA) che consente la programmazione
dei nodi senza rimuoverli dalla loro sede.
4.1.2. “Service discovery”

Questa classe di funzionalità riguarda essenzialmente l’individuazione dei servizi offerti
dai nodi. Come anticipato, esiste infatti la possibilità di ospitare in un nodo fino a 240
Application object ognuno corrispondente ad un Endpoint. La primitiva offerta dal GAL
chiamata Service discovery è in grado di determinare gli Endpoint attivi di un nodo
64
remoto e per ognuno, l’identificativo del profilo applicativo, l’identificativo del
dispositivo applicativo e la lista dei cluster implementati. Le informazioni di un
Application object sono contenute in un Simple Descriptor esaminato nella tabelle
sottostante.
Campo Descrizione
Endpoint Identificativo usato per riferire l’Application Object

(compreso tra 1 e 240)
Application profile identifier Identificativo del Profilo applicativo pubblico o

privato ottenuto dalla ZigBee Alliance
Application device identifier Identificativo del dispositivo applicativo
Application device version Versione del dispositivo applicativo
Application input cluster count Numero dei cluster di input implementati
Application input cluster list Lista degli identificativi dei cluster di input
implementati
Application output cluster Numero dei cluster di output implementati

count
Application output cluster list Lista degli identificativi dei cluster di output
implementati
Tabella 13 Simple descriptor
Le ZigBee Cluster Library si rivelano uno strumento essenziale quando il profilo

applicativo del dispositivo è di tipo pubblico. In questo caso la piattaforma di servizio
non offre solo l’individuazione dei device della rete di sensori, ma fornisce anche i
comandi associati ai cluster implementati dal dispositivo, in modo da rendere quanto più
trasparente l’uso di ZigBee.
4.1.3. “Service interface”

Questa classe di funzionalità riguarda la capacità del gateway di interagire con i
dispostivi della rete dei sensori. Come accennato nell’introduzione di questo capitolo la
piattaforma di servizio utilizza il gateway per remotizzare le applicazioni esistenti nella
rete di sensori. Il dimostratore, al livello di sviluppo attuale, espone attraverso il GAL
solo la possibilità di inoltrare alla piattaforma tutti i messaggi applicativi che arrivano al
gateway. Per eseguire questa primitiva il GDO si serve della primitiva della ZDO Public
65
Interface APSDE-DATA.indication. Questa è già stata illustrata nel paragrafo 2.3.1.
Nei prossimi sviluppi questa parte sarà punto focale per l’interazione tra piattaforma e
servizi.
66
4.2. Gateway Device Object
Il GDO aggrega le primitive ZigBee allo scopo di eseguire le funzionalità offerte dal
Gateway Abstraction Layer. Al suo interno risiede la logica di interazione con una rete
ZigBee che viene mascherata alla piattaforma di servizio semplificando l’utilizzo delle
risorse di una WSN. Di seguito sono esposte le primitive accennate nel precedente
paragrafo con la definizione degli automi a stati finiti e la descrizione delle primitive
dello stack ZigBee utilizzate. Il GDO mantiene le informazioni ricevute dalla rete di
sensori in una struttura chiamata GW Information Base che verrà presentata nel
paragrafo 4.3.5.
4.2.1. Device Discovery

Nel documento di specifica [ZBSpec06] vengono illustrati i comandi per effettuare la
scoperta dei nodi ma nulla è detto esplicitamente sulla startegia di come questa vada
implementata. Tale scoperta può essere di tipo broadcast oppure unicast: la prima
consiste nel chiedere l’indirizzo di rete (lo short address) corrispondente ad un indirizzo
IEEE conosciuto a tutti i nodi (in broadcast), mentre la seconda nel chiedere l’indirizzo
IEEE unicamente al nodo di cui si conosce lo short address (in unicast). In entrambe i
casi, se il nodo che riceve una di queste due richieste è un coordinatore o un router, la
risposta può contenere anche la lista dei nodi associati (i figli) nel caso in cui sia
richiesto esplicitamente da un messaggio di richiesta estesa. Questo è in sintesi ciò che
viene citato nel documento di specifica [ZBSpec06]. Se ne deduce che un meccanismo
efficiente può utilizzare la presenza del coordinatore per effettuare una discovery della
rete con soli messaggi in unicast. Infatti il coordinatore di una rete ZigBee rappresenta
la radice del joining tree a partire dal quale è possibile ricostruire l’albero di
associazione. È sufficiente effettuare una richiesta dell’indirizzo MAC (essendo
coordinatore ha short address “0”) e richiedere che esso risponda con la lista dei nodi
associati (cosiddetta richiesta estesa). Da questo punto in poi si prosegue ricorsivamente
per tutti i nodi scoperti. Un punto rilevante da considerare in questa strategia è che l’uso
di messaggi unicast, al posto di messaggi broadcast, ottimizza il consumo di energia.
Per eseguire questa primitiva il GDO si serve di alcune primitive ZigBee della ZDO
Public Interface:
67
 IEEE_addr_req, questo comando serve a conoscere l’indirizzo IEEE di un nodo
di cui si conosce l’indirizzo di rete; tale comando genera un messaggio unicast
avente come destinatario il nodo con l’indirizzo di rete specificato; se la
richiesta è di tipo esteso e il nodo destinatario è un coordinatore o un router,
allora il comando di risposta IEEE_addr_conf contiene, oltre al indirizzo IEEE,
anche la lista degli indirizzi di rete dei dispositivi ad esso associati.
 Node_Desc_req, questo comando serve a conoscere le informazioni contenute

nel descrittore del nodo e descritte in tabella 11. La risposta perviene attraverso
in comando Node_Desc_conf.
 Power_Desc_req, questo comando serve a conoscere le informazioni contenute

nel descrittore dell’energia del nodo e descritte in tabella 12. La risposta
perviene attraverso in comando Power_Desc_conf.
Una serie di richieste dirette al coordinatore iniziano la Device Discovery: la

IEEE_addr_req, la Node_Desc_req e la Power_Desc_req. Dopo un breve intervallo di
tempo arrivano le rispettive risposte: IEEE_addr_conf, la Node_Desc_conf e la
Power_Desc_conf. La prima contiene il suo indirizzo MAC e la lista dei suoi figli, la
seconda il descrittore del nodo e la terza il descrittore dell’energia. Ottenuta la lista dei
figli del coordinatore si procede analogamente per ogni suo figlio, e successivamente
per ogni livello dell’albero fino alle foglie (cioè quei nodi che non hanno figli). Le
informazioni contenute in ogni descrittore ricevuto completano la GW Information
Base.
68
I seguenti diagrammi di flusso rappresentano una astrazione di quanto appena espresso.
Device Discovery IEEE_addr_conf
IEEE_addr_req (0) fill GW information base
Node_Desc_req (0) son = first son of list
Power_Desc_req (0) exists(son)
wait for all confirm

IEEE_addr_req (son)
Node_Desc_req (son)
Node_Desc_conf
Power_Desc_req (son)
fill GW information base
son = next son of list
Power_Desc_conf

wait for all confirm
Figura 28 Diagrammi di flusso relativi alla Device Discovery
4.2.2. Service Discovery
Per eseguire questa primitiva il GDO si serve di alcune primitive ZigBee della ZDO
Public Interface:
 Simple_desc_req, questo comando serve a conoscere le informazioni contenute

nel descrittore del Application Object e descritte in tabella 12. La risposta
perviene attraverso il comando Simple_desc_conf.
69
 Active_ep_req, questo comando serve a scoprire quali sono gli Endpoint attivi di
un nodo. La risposta Active_ep_conf contiene la lista di tali identificativi.
I seguenti diagrammi di flusso rappresentano una astrazione di quanto appena espresso.
Service Discovery Active_ep_conf
node = first node of GWIB fill GW information base
exists(node) endpoint = first endpoint of list
Active_ep_req (shortaddr) exists(endpoint)
node = next node of GWIB Simple_desc_req (shortaddr, endpoint)
endpoint = next endpoint of list
wait for all

Active_ep_conf
wait for all

Simple_desc_conf Simple_desc_conf
Figura 29 Diagrammi di flusso relativi alla Service Discovery
In generale la ricezione delle confirm è totalmente asincrona perciò dopo aver inviato
una serie request, l’ordine delle risposte è totalmente imprevedibile: per riconoscere la
provenienza ogni confirm riporta i dati identificativi del mittente.
70
4.3. Applicazione
Questo paragrafo illustra i punti chiave dell’architettura del programma sviluppato. Il
testbed, anche detto ambiente di prova, è costituito da due personal computer (di cui
uno usato anche per lo sviluppo), due dongle USB forniti dalla Integration [Integration]
e un nodo ZigBee fornito dalla BM Group Spa [BM]. Il gateway è realizzato dalla
coppia PC (munito di interfaccia di rete) e dongle USB mentre la rete di sensori è
rappresentata dal secondo PC unito al secondo dongle e dal nodo di BM. A corredo dei
dongle USB di Integration viene fornita una buona documentazione e degli esempi
applicativi. L’approccio iniziale con questo prodotto si è svolto analizzando il più
comune degli esempi presenti, l’interruttore e la lampada. L’implementazione è partita
dalla modifica di tale applicazione e, dopo aver assunto la conoscenza sufficiente, si è
proceduto allo sviluppo del dimostratore di gateway. L’ambiente di sviluppo usato è
Visual C++ del pacchetto Microsoft Visual Studio 2003. La scelta di tale software è
stata obbligata dal fatto che il driver del dongle USB, e la relativa manualistica, è stato
implementato singolarmente per MS Windows.
Figura 30 Dongle USB - ZigBee fornito da Integration
4.3.1. Interfaccia grafica

L’applicazione è dotata di un interfaccia nata per sperimentare in modo immediato le
funzionalità del gateway: in una prima versione non era disponibile alcuna connessione
con la piattaforma. Successivamente questa possibilità è stata aggiunta mediante la
realizzazione di un thread, descritto di seguito, che può accettare le richieste mediante
un socket TCP e interagire con l’applicazione: esso svolge la funzione principale del
71
gateway ossia quella esporre le funzionalità definite mediante il Gateway Device
Object.
La figura seguente mostra la schermata dalla quale è possibile eseguire le due discovery
descritte nel paragrafo precedente. Ad ogni discovery è associato un bottone con il
relativo nome. Il risultato di queste operazioni è presentato nel riquadro centrale che ha
la proprietà di organizzare il contenuto ad albero. L’albero risultante è in realtà l’albero
di joining: conoscere questa struttura è molto utile da punto di vista implementativo ma
poco rilevante ai fini della piattaforma di servizio. Per come è sviluppata l’applicazione,
il risultato della Device Discovery produce un messaggio recante l’esito della stessa
mentre quello della Service Discovery popola il suddetto albero. Questa scelta è stata
indotta dal fatto che l’albero ha la capacità di offrire una visione d’insieme che
altrimenti andrebbe persa: la prima funzionalità infatti fornisce solo informazioni sui
nodi e sulla loro relazione mentre la seconda funzionalità fornisce solo i servizi residenti
sui vari nodi. Fornire due risultati diversi avrebbe significato minore leggibilità e
ridondanza delle informazioni (cosa trascurabile dal punto di vista della piattaforma di
servizio).
72
(Fig. A) (Fig. B)
Figura 31 Interfaccia grafica
Dalla figura 31/A è possibile notare che la prima riga di questo riquadro rappresenta la
radice dell’albero e riporta l’indirizzo di rete e l’indirizzo MAC del nodo coordinatore.
Le righe successive, ottenute espandendo la radice, sono in ordine “Node Descriptor”,
“Power Descrptor”, “Endpoint” e “Sons”. Espandendo i primi due elementi si ottengono
le informazioni contenute nei relativi descrittori. Espandendo i secondi due elementi
invece si entra a conoscenza rispettivamente degli Application Object presenti sul nodo,
rappresentati dal valore dell’endpoint, e dei nodi associati, a partire dai quali tale
struttura si ripete. La figura 31/B esemplifica il caso in cui ci siano un nodo
coordinatore e due suoi figli.
Occorre notare che questa interfaccia grafica è utile ai fini di test o debug e non deve
essere ritenuta indispensabile per l’integrazione con la piattaforma di servizi. Sviluppi
futuri di questa applicazione permetterebbero ad esempio ad un tecnico esperto di
interagire direttamente con la rete di sensori per verificare dei malfunzionamenti.
73
4.3.2. Architettura applicativa
L’architettura che questo paragrafo descrive è rappresentata dalla figura seguente.
Figura 32 Architettura applicativa
Il box di colore azzurro rappresenta il driver fornito insieme al dongle di Integration che
permette all’applicazione di accedere alle funzioni ZigBee del dongle. In realtà tale
libreria contiene gli strati alti dello stack ZigBee mentre l’hardware contenuto nel
dongle si occupa principalmente delle funzioni radio. Come visibile nell’immagine la
DLL (Dynamic Link Library) offre le primitive principali per interagire con lo stack
ZigBee: la primitiva più importante è ZBDLLSend() perchè permette di chiamare le
funzioni della APS e della ZDO mediante un protocollo seriale opportunamente
documentato.
Per facilitare le chiamate di tali primitive ZigBee la stessa Integration fornisce anche
l’interfaccia “ZigBee Common Interfaces” raffigurata nel box di colore verde. Questa
interfaccia raccoglie tutte le primitive ZigBee (occupandosi cioè di comporre il
74
messaggio seriale in osservanza della specifica) e gestisce anche quali messaggi
provenienti provenienti dai livelli inferiori della pila protocollare debbano essere
consegnati all’applicazione. Ad esempio con tale chiamata
ZBIFSubscribe(AF_DIRECT_INDICATION) si specifica che ogni qualvolta arrivi
all’APS un messaggio di tipo diretto proveniente da un altro Application Object, esso
venga recapitato all’applicazione. Partendo dal livello più basso: la DLL recapita tutti i
messaggi provenienti dal basso alla ZigBee Common Interfaces chiamando la funzione
ZigBeeReceiveData(): quest’ultima è definita nell’interfaccia ma è utilizzabile dalla
DLL perché il suo puntatore viene passato alla DLL durante la fase di start. La funzione
ZigBeeReceiveData() controlla il tipo di messaggio e, se l’applicazione ha sottoscritto la
relativa ricezione, effettua la consegna al livello superiore con un messaggio di
windows generato con la primitiva PostMessage() appartenete alle MFC (Microsoft
Foundation Classes).
L’applicazione è identificata dal box rosso: essa utilizza la ZigBee Common Interfaces
per configurare il nodo, inviare richieste alla ZDO e all’APS e ricevere le risposte o i
messaggi applicativi. Come già scritto le risposte e i messaggi applicativi pervengono
mediante la coda dei messaggi di windows e la cui ricezione avviene, alla stregua di un
evento, con una chiamata di una funzione definita nell’applicazione. Per ogni tipo di
messaggio al quale l’applicazione ha sottoscritto la ricezione esiste una funzione che
gestisce il messaggio arrivato. Quest’ultimo si presenta in forma seriale e quindi
comporta un lavoro di estrazione delle informazioni (“unmarshaling”) che nel verso
opposto è eseguito dalla ZigBee Common Interfaces (“marshaling”). Per questo motivo
i due box, rosso e verde, presentano una diversa, ma complementare, sagoma.
4.3.3. Implementazione
Quanto descritto nel capitolo precedente assume maggiore dettaglio osservando lo
schema riportato di seguito.
75
Figura 33 Rappresetazione a oggetti
La figura rappresenta l’organizzazione delle classi dell’applicazione sviluppata. Ogni

classe è rappresentata da un box nel quale sono contenuti le variabili e i metodi più
importanti da discutere.
Le classi CGALApp e CGALDlg sono generate dall’ambiente di sviluppo

automaticamente: rappresentano rispettivamente la classe principale e la classe che si
occupa di implementare le funzionalità dell’interfaccia grafica (dialog). L’applicazione
all’avvio esegue la connessione con la libreria DLL usando la ZigBee Common
Intefaces, e attesi pochi secondi per permettere allo stack di completare l’attivazione,
inizia ad eseguire le richieste necessarie ad avviare il nodo e all’associazione alla rete.
Per svolgere questa fase preliminare utilizza i metodi offerti dalla classe CZigBeeIF
(rappresentati in figura con la scritta “ZDO_*_request(…);”). Le risposte come
precedentemente scritto pervengono sottoforma di eventi gestiti dalla serie di funzioni
contenute nella classe CGALDlg che iniziano con “ZDO” e terminano con “confirm”.
76
Se tutto è eseguito regolarmente l’applicazione provvede a far partire il thread per
l’interazione con la piattaforma. Dopo questa fase il gateway è pronto a ricevere sia le
richieste provenienti dall’interfaccia grafica sia quelle dalla piattaforma di servizio.
Si lascia al paragrafo relativo la descrizione della classe Node mentre occorre precisare
il significato delle frecce contenute nel disegno precedente: la freccia che parte dalla
DLL e arriva in corrispondenza della funzione ZigBeeReceiveData(…) è tratteggiata per
rimarcare che questa è una vera e propria chiamata di funzione diversamente dalle
frecce non tratteggiate che indicano l’inserzione o l’estrazione di messaggi dalla coda di
Windows.
La descrizione prosegue con l’analisi di cosa accade quando perviene una richiesta di
Device Discovery e di Service Discovery dall’interfaccia. Al momento della pressione
di uno dei due pulsanti il sistema provvede ad invocare il metodo appropriato,
“OnBnClickedDeviceDiscovery” oppure “OnBnClickedServiceDiscovery”, le cui
implementazioni sono fornite in appendice B. Questi due metodi realizzano quanto
espresso dal relativo diagramma di flusso delle figure 28 e 29.
In questi diagrammi sono stati tralasciati i meccanismi rivolti alla gestione degli errori. I
messaggi di richiesta inviati delle due discovery possono infatti essere persi per vari
motivi (ad esempio, il nodo di destinazione non è più attivo oppure il segnale è
disturbato da interferenze). A questo scopo lo stack ZigBee prevede che a seguito di una
request fallita venga comunque generata una confirm recante l’insuccesso: questa viene
prodotta solo dopo l’attesa di un periodo determinato. Questo garantisce che ad ogni
request sicuramente corrisponde una confirm. Sfruttando questa deduzione si può
determinare la conclusione di una discovery semplicemente controllando che il numero
di request inviate sia pari al numero di confirm ricevute. Questa soluzione risulta
efficiente in quanto le discovery impiegano un tempo proporzionale alla grandezza della
rete. Nel codice questo meccanismo è implementato mediante una variabile
(count_expected_confirm) che viene incrementata ogniqualvolta una request viene
inviata e decrementata quando una confirm viene ricevuta. Per considerare la discovery
terminata occorre controllare ad intervalli regolari che tale contatore sia zero. A tal fine
viene impostato un timer con scadenza di un secondo scaduto il quale si effettua il test:
se la variabile di cui sopra è zero, la discovery è terminata, altrimenti il timer riparte. Le
MFC forniscono la possibilità di settare un timer che, allo scadere, inserisce un
messaggio nella coda dell’applicazione. Quando l’applicazione processa questo
77
messaggio esegue il metodo OnTimer la cui implementazione è definita in CGALDlg.
A ogni timer è associato un numero che identifica l’evento: al numero 1 è associata la
terminazione della Device Discovery, al numero 2 la terminazione della Service
Discovery. Per affermare la correttezza dell’implementazione occorre fare due
commenti:
 osservato che le routine di gestione dei messaggi non vengono interrotte

dall’arrivo di nuovi messaggi, ne risulta che il controllo della variabile sopra
citata non è affetto da problemi di race condition,
 considerato che in entrambe i due processi di discovery (come evidenziato nei

diagrammi di flusso) si eseguono nuove request solo nel momento in cui si
riceve una confirm (ad esempio la IEEE_addr_conf esegue tre request per ogni
figlio presente nella lista contenuta nel messaggio di risposta), ne consegue che
il contatore sarà zero solo al termine del processo.
Affinché una discovery abbia successo deve accadere che tutti messaggi di risposta,
ovvero le confirm, abbiano esito positivo. Allo stato di sviluppo attuale, basta che una
confirm abbia esito negativo per compromettere l’intera discovery. Una estensione
futura del prototipo in esame dovrà certamente garantire una maggiore robustezza: a tal
fine basterebbe prevedere la replica dell’invio del messaggio di richiesta fallito.
Purtroppo lo stack utilizzato non fornisce la possibilità di identificare il messaggio perso
(come accade per i messaggi con esito positivo) altrimenti tale gestione risulterebbe
semplificata. Essendo questo un prototipo si è pensato di rilasciare le specifiche di
robustezza per poi riprendere la risoluzione del problema durante lo sviluppo della
applicazione finale, operando per risolvere le eventuali limitazioni dello stack
utilizzato.
Quanto appena descritto ha avuto influenza sulle scelte implementative adottate durante
lo sviluppo del thread destinato ad accogliere le richieste provenienti dalla piattaforma.
Sebbene il paragrafo 4.3.4 si occupi di trattare l’interazione tra GAL e WSN-C occorre
anticipare per maggiore chiarezza in questo paragrafo alcuni dettagli implementativi. Il
thread all’avvio apre un server socket TCP sul quale rimane in ascolto. Per ogni
connessione accettata si occupa di ricevere il messaggio ed effettuare il parsing della
richiesta. Il parsing serve ad isolare le parti del messaggio al fine di carpirne il
significato. In questa versione prototipale sono disponibili alla piattaforma solo due
78
funzionalità: “discovery” e “notification”. La prima è il risultato dell’unione delle due
discovery: tale accorpamento è stato fatto per semplificare l’interazione tra piattaforma
e gateway essendo unico il risultato prodotto. La seconda, non presente nell’interfaccia
grafica, è una parziale l’implementazione della classe di funzionalità denominata
Service Interface (vedi paragrafo 4.1.3): con questa richiesta la piattaforma riceve i
messaggi applicativi provenienti dalla rete di sensori.
Quando la piattaforma esegue la richiesta di “discovery”, il thread non fa altro che

inserire, nella coda dei messaggi dell’applicazione, un messaggio di tipo proprietario
passando come parametro il client socket. Quando l’applicazione processa tale
messaggio chiama la routine Discovery che compie i medesimi passi di
OnBnClickedDeviceDiscovery, ad eccezione di attivare il timer con evento numero 3
per controllare la terminazione della Device Discovery. Infatti questo timer,
diversamente dal timer relativo all’evento numero 1, si occupa di iniziare la Service
Discovery compiendo gli stessi passi di OnBnClickedServiceDiscovery, fatta sempre
eccezione per l’attivazione del timer, questa volta con evento numero 4. Il timer con
evento numero 4 è simile al numero 2 in quanto entrambe attendono la terminazione
della Service Discovery ma, diversamente dal numero 2 che esegue la visualizzazione
grafica, esso compone un documento XML, lo incapsula in un messaggio di risposta
“HTTP/1.1 200 OK” che viene trasmesso in risposta alla piattaforma mediante il client
socket fornito dal thread.
Come già accennato, una richiesta di tipo “notification” ha lo scopo di far fluire tutti i
messaggi della rete di sensori destinati al gateway alla piattaforma. Questa situazione
avrà luogo quando la piattaforma sarà in grado di inviare, usando il gateway, dei
messaggi ai singoli device. Per ora, questa caratteristica è stata sviluppata per
supportare un’applicazione proprietaria oggetto di un’altra attività. Per rendere
comprensibile il tipico caso d’uso bisogna immaginare che la piattaforma, dopo aver
fatto una Device Discovery ed una Service Discovery, sia interessata ad un particolare
servizio di un device nella rete. Essa dunque potrebbe dover inviare dei messaggi
applicativi per impostare, ad esempio, un Attribute reporting. In questo caso la lettura
periodica del valore raggiunge la piattaforma attraverso un canale attivato da questa
funzionalità. L’implementazione attuale usa lo stesso client socket utilizzato per inviare
la richiesta come canale sul quale trasmettere tali messaggi.
79
Per riassumere, esistono due flussi di controllo, l’applicazione principale e il thread:
l’applicazione reagisce agli eventi provenienti sia dall’interfaccia grafica sia dal thread
mentre quest’ultimo reagisce solamente alle richieste provenienti dalla piattaforma.
Piattaforma
TCP/IP
GAL Interfaccia
(thread) Grafica
Windows Messaging
Gateway Device Object
Stack ZigBee
Wireless Sensor Network
Figura 34 Schema riassuntivo
4.3.4. REST - Representational State Transfer

Questo paragrafo presenta la tecnologia scelta per l’interazione tra piattaforma e
gateway. REST, acronimo di Representational State Transfer, è un’insieme di principi
architetturali per sistemi distribuiti che derivano da quelli che hanno decretato il
successo del Web. REST si pone come alternativa a framework di protocolli come
SOAP e a sistemi per eseguire chiamate di procedure remote (RPC). Non si tratta di uno
standard, ma di una tecnologia che fa uso di standard: URL, HTTP, XML ed altri.
Un Uniform Resource Locator o URL è una stringa che identifica univocamente

l’indirizzo di una risorsa all’interno del WWW. Ogni Uniform Resource Locator è
composto dal protocollo, dal nome del server e dal path locale della risorsa.
80
REST essendo uno stile architetturale non forza l’uso di un particolare protocollo di
trasporto. Anche se attualmente il protocollo maggiormente utilizzato per i sistemi
aderenti a REST è HTTP, sono stati implementati con successo sistemi che fanno uso di
protocolli alternativi. L’Hyper Text Transfer Protocol, altrimenti detto HTTP è un
protocollo client-server generico, senza memoria di stato (stateless) e non-orientato alla
connessione (connection-less) utilizzato non solo per lo scambio di documenti
ipertestuali, ma per una moltitudine di applicazioni che variano dallo streaming
audio/video al trasporto di altri protocolli. Un metodo HTTP è un’operazione ben
definita su una risorsa. Il più importante metodo di HTTP è GET, che richiede una
risorsa ad un server. Questo è il metodo più frequente, ed è quello che viene attivato
facendo click su un link ipertestuale di un documento HTML, o specificando un URL
nell’apposito campo di un browser.
XML, acronimo di eXtensible Markup Language, ovvero “Linguaggio di marcatura

estensibile”, è un meta-linguaggio di markup, cioè un linguaggio che permette di
definire altri linguaggi di markup. Un documento XML è composto da componenti
denominati elementi (“tag”) ed è intrinsecamente caratterizzato da una struttura
gerarchica che prevede un elemento principale, chiamato root (radice). Ciascun
elemento rappresenta un componente logico del documento e può contenere altri
elementi (sottoelementi) o del testo. Gli elementi possono avere associati degli attributi
che ne descrivono le proprietà. XML offre la libertà di definire i tag a seconda delle
necessità, ma perché non si generi confusione è necessario un meccanismo che vincoli
l'uso degli elementi e la struttura del documento. Attualmente due sono gli approcci più
diffusi: Document Type Definition (DTD) e XML Schema Definition (XSD).
Tornando alla descrizione di REST, si elencano alcune delle sue caratteristiche:
 è conforme al modello client-server e la comunicazione avviene attraverso il

protocollo HTTP,
 è senza stato e ciò implica che ogni richiesta del client al server deve contenere
tutte le informazioni necessarie senza ricorrere alla conservazione di uno stato
sul server,
 definisce un interfaccia uniforme per la comunicazione con la quale accedere

alle risorse indipendente dal dominio applicativo del servizio fornito,
 le risorse vengono identificate univocamente usando un URL,
81
 è possibile introdurre proxy server, cache server e gateway in modo da
assicurare prestazioni, sicurezza, ecc.
Le proprietà rendono REST particolarmente semplice da implementare e a livello di

prestazioni migliore di altre tecnologie come ad esempio SOAP. Le possibilità di
impiego comprendono l’integrazione di software lagacy e la creazione di interfacce
pubbliche per la fruizione di servizi a terzi.
Nell’ottica della prima tipologia di impiego, tale soluzione è stata adottata

nell’architettura dell’applicazione per far comunicare la piattaforma, il client, con il
GAL, il server. Per ora la piattaforma è simulata da un browser web (quasi tutti infatti
sono in grado di visualizzare testo XML) non essendo questa ancora disponibile per un
test. Le risorse del GAL sono raggiungibili componendo un URL della seguente forma
“http://[ip_gateway]:[porta]/[discovery|notification]”. Come precedentemente descritto,
il GAL risponde, nel caso di una discovery, con un documento, XML mentre nel caso di
una notification l’interazione è di tipo proprietario. L’implementazione di REST per il
GAL è stata sviluppata in maniera elementare trascurando anche qui la robustezza: è
auspicabile che nell’applicazione finale si utilizzino librerie adatte alla gestione dei
messaggi HTTP in modo da non incappare in errori di gestione delle stringhe e
mantenere la conformità allo standard. L’immagine seguente raffigura il browser a
seguito dell’esecuzione di una richiesta di discovery.
Figura 35 Finestra del browser
82
4.3.5. Gateway Information Base
Questo paragrafo descrive le scelte implementative riguardanti la struttura dati per la
memorizzazione delle informazioni della rete di sensori. L’oggetto fondamentale di una
rete è il nodo. Un nodo è identificato da un indirizzo di rete e da un indirizzo MAC e
contiene:
 le informazioni due descrittori Node descriptor e Power descriptor,
 la lista dei Simple descriptor degli Application Object da esso esposti,
 la lista dei nodi (figli) ad esso associati.
Seguendo un approccio di programmazione orientato agli oggetti e nel rispetto di questa

visione è stata scritta la classe chiamata “Node”, che è riportata in appendice. Gli
oggetti “Node” vengono creati durante la Device Discovery: il primo viene creato
all’inizio della Device Discovery prima di interrogare il coordinatore; gli altri invece
vengono creati successivamente, prima di interrogare i nodi della lista dei figli quando
si riceve un IEEE_Addr_conf. Come emerso nel paragrafo 4.2.2, la ricezione delle
confirm è asincrona nei confronti delle request e per questo è necessario identificare
nella struttura dati l’oggetto relativo alle informazioni veicolate dalla confirm. La
struttura dati nel suo complesso rappresenta l’albero di join che viene costruito,
partendo dalla radice ossia dal coordinatore, con la Device Discovery. Ogni volta che si
riceve una confirm si dovrebbe ricercare l’oggetto “Node” per aggiungere le
informazioni ottenute. Questa ricerca, per quanto possa essere ottimizzata sulla base
dell’algoritmo CSkip con il quale si assegnano gli indirizzi ai nodi e che e di
conseguenza influisce sulla costruzione dell’albero di join, rappresenta una notevole
limitazione prestazionale. Per questo motivo è stato introdotto un array di puntatori a
oggetti “Node” ampio 65536 locazioni, tante quanti sono gli indirizzi di rete possibili.
Ogni volta che si crea un oggetto “Node” bisogna memorizzare il relativo puntatore nel
vettore nella locazione corrispondente all’indirzzo di rete e, viceversa, ogni volta si
ricerca un oggetto per aggiungervi le informazioni ricevute basta entrare in tale vettore
con l’indirizzo di rete ed estrarre il puntatore all’oggetto interessato. Questo comporta
un maggiore uso di memoria da tenere in considerazione quando il progetto verrà
portato su dispositivi con minori risorse fisiche. La figura seguente evidenzia le strutture
dati utilizzate per mantenere le informazioni della rete di sensori in memoria. Ogni
cerchio giallo rappresenta un oggetto della classe “Node” con al centro l’indirizzo di
83
rete (in formato esadecimale) mentre la freccia esprime relazione padre-figlio da cui
deriva la struttura ad albero. In basso si trova il vettore di puntatori illustrati dalle frecce
tratteggiate che partono dalla locazione corrispondente all’indirizzo di rete e puntano al
relativo oggetto “Node”.
Figura 36 Memorizzazione dei dati
Oltre ai dati la classe “Node” contiene tre metodi:
 XMLWrite genera il documento XML da restituire alla piattaforma,
 ServiceReq viene usato per cominciare una Service Discovery (vedi il primo
diagramma di flusso della figura 29),
 BuildTreeCtrl costruisce l’albero visualizzato dall’interfaccia grafica.
Questi metodi sfruttano l’albero richiamando annidatamente loro stessi sui nodi figli. In
pratica chiamando, ad esempio, XMLWrite sulla radice viene creato l’albero del
documento XML. Riassuendo questo metodo esegue i seguenti passi:
 Inserisce il tag <Node …>,
 prosegue aggiungendo le informazioni del Node descriptor,
84
 prosegue aggiungendo le informazioni del Power descriptor,
 prosegue aggiungendo le informazioni dei Simple descrptor,
 apre il tag <Sons>
 a questo punto chima il medesimo metodo su ognuno dei figli del oggetto
“Node” di appartenenza,
 chiude il tag </Sons>.
L’annidarsi delle chiamate del metodo XMLWrite produce spontaneamente la struttura

del documento XML. Tale struttura è in versione preliminare in quanto potrebbe subire
modifiche per raggiungere i requisiti della piattaforma. Il risultato prodotto è visibile
nella figura seguente.
Figura 37 Documento XML
85
5. Conclusioni
Le reti di sensori senza fili rappresentano uno degli argomenti più interessanti e
promettenti nell’attuale panorama scientifico internazionale. I possibili campi di
applicazione sono molto vasti e ancora largamente inesplorati. La commercializzazione
dei primi prodotti ha contribuito a portare queste tematiche al di fuori dei limitati
confini dei laboratori di ricerca universitari, stimolando l’interesse di piccole e grandi
aziende che vedono nelle WSN sia uno strumento per migliorare la produttività delle
proprie imprese che una possibilità di espandere l’attività su un nuovo mercato. A tal
proposito è nato lo standard ZigBee: una tecnologia che permette la creazione di reti
senza fili di oggetti intelligenti adatti ad attivare una moltitudine di servizi innovativi
che spaziano dall’automazione domestica al monitoraggio ambientale. Grazie
all’integrazione di questa tecnologia in terminali fissi, o anche mobili, che si
configurano come gateway connettendo il mondo delle reti di sensori alle reti di
distribuzione tradizionali dell’operatore, l’informazione si arricchisce e diventa
pervasiva ed accessibile ovunque. Il concetto di “pervasive computing” presuppone che
la tecnologia impiegata sia totalmente trasparente all’utente in modo che venga
percepita in maniera naturale. Nel 1991 Mark Weiser, capoufficio del dipartimento
tecnologico del Centro di Ricerca di Palo Alto (PARC) della Xerox, scriveva: “Le
tecnologie più profonde sono quelle che scompaiono, che saranno nascoste nella
fabbrica della vita giornaliera finché sarà indistinguibile dalla vita stessa […] Le
macchine entreranno nell’ambiente umano senza che l’uomo si sforzi più di entrare in
quello delle macchine, l’uso del computer dovrà essere ristoratore quanto una
passeggiata nei boschi”. La comunità scientifica dell’epoca considerò la visione di
Weiser basata su un’idea inconsistente e quasi fantascientifica. A distanza di qualche
decennio Weiser è considerato il precursore del modello di interazione tecnologica alla
base del “pervasive computing”.
86
5.1. Obiettivi raggiunti e futuri
Con questi presupposti, lo sviluppo di un gateway per reti di sensori ZigBee, oggetto di
questa tesi, costituisce il primo passo verso lo sviluppo di applicazioni e servizi a valore
aggiunto (VAS). Come visto nel capitolo 3, l’operatore di telecomunicazioni intende
costruire una piattaforma di middleware sulla quale, sia esso stesso che terzi, possano
sviluppare le applicazioni per wireless sensor network senza dover conoscere i dettagli
implementativi di tali reti. Il prototipo descritto nel capitolo 4 è servito per iniziare a
familiarizzare con lo standard ZigBee e iniziare ad individuare le prime macro
funzionalità che un gateway deve fornire. L’intero sviluppo è stato eseguito puntando il
più possibile all’implementazione finale, ovvero quella riguardante un dispositivo come
un modem o un videotelefono da poi commercializzare. Quanto prima infatti l’operatore
intende effettuare il porting di tale applicazione su un sistema operativo embedded. Tale
migrazione dovrà richiedere delle modifiche: il fatto di essere stati vincolati
all’ambiente MS Windows costringerà a rivedere alcune parti del codice pur
mantenendo valida l’ossatura dell’applicazione e le strutture dati. Di altrettanto interesse
sarà l’integrazione con la piattaforma che comporterà sicuramente la messa a punto
delle funzionalità esposte dal GAL, delle strutture dati XML restituite dal gateway e del
meccanismo di interazione REST.
87
5.2. Esperienza
L’avventura intrapresa presso i laboratori di Torino è stata una esperienza formativa
senza pari. Mi ha permesso di entrare in contatto con una realtà aziendale di alto livello
dove conta l’obiettivo ma contano anche le relazioni interpersonali. In tutte le persone
che ho incontrato non sono mai mancate cortesia e disponibilità. L’uso del “tu” ha
ulteriormente accresciuto il senso di fiducia mettendomi da subito a mio agio. La
presenza di numerosi altri tesisti ha reso poi la permanenza molto più coinvolgente: mi
ha permesso il confronto con ragazzi, sia stranieri che italiani, con i quali è rimasta una
grande amicizia. La crescita professionale unita a quella umana ha reso questa
esperienza un ottimo ricordo.
Figura 38 Gruppo del progetto WSN-C
88
6. Appendice
6.1. Dongle Integration
Lo stick di figura 30 fornisce un interfaccia conforme a 802.15.4 che può essere
facilmente collegata ad un computer. Il dongle fornisce anche una completa
compatibilità con lo standard ZigBee per mezzo dei driver inclusi. Esso è un semplice
metodo per integrare 802.15.4 o ZigBee in un computer, in un gateway o in un
dispositivo bridge. Utilizzando tale soluzione gli sviluppatori di software possono
evitare di scrivere un driver USB o di essere esperti di sviluppo di tecnologie wireless.
Integration offre loro la possibità di ridurre i costi di ricerca e sviluppo , di ridurre il
time-to-market e minimizzare i rischi di sviluppo. Sono disponibili a scelta due driver: il
primo fornisce accesso diretto all’interfaccia 802.15.4, il secondo alle interfacce
AF/ZDO di ZigBee.
Figura 39 Due tipi di driver
89
6.2. Nodo BM
Figura 40 Nodo BM MOD 01
BM MOD 01 è uno dei più piccoli, più economici e più performanti moduli ZigBee
attualmente disponibile sul mercato, membro di una famiglia di moduli caratterizzati da
una elevata flessibilità.
Grazie all’impiego del modulo BM MOD 01viene semplificata al massimo

l’integrazione in numerosi prodotti della connettività offerta da una rete wireless mesh.
Il modulo offre una piattaforma ZigBee compliant, facilmente adattabile alle
funzionalità richieste dal prodotto o dal sistema [Datasheet].
Questo nodo è stato utilizzato in accoppiata con la scheda della fotografia della figura
41.
90
Figura 41 Scheda di prova BM
Questa scheda di prova fornisce diverse interfacce come RS232 e USB. Essa può essere
alimentata usando un alimentatore da rete esterno o tramite la connessione USB.
91
6.3. Esempi di codice
6.3.1. OnBnClickedDeviceDiscovery
void CGALDlg::OnBnClickedDeviceDiscovery()
{
if (DiscoveryRunning == false) {
DiscoveryRunning = true;
m_Status.SetWindowText("Node discovery started");
//if a discovery has been already made the data structures must be
cleaned up
if (array_node[0]!=NULL){
delete array_node[0];
ZeroMemory(array_node,sizeof(array_node));
}
DiscoveryFailed=false;
array_node[0] = new Node(0);
hZigBee->ZDO_IEEE_ADDR_request(0, 1, 0, 0);
count_expected_confirm++;
Sleep(WAITMSECOND);
hZigBee->ZDO_NODE_DESC_request(0);
Sleep(WAITMSECOND);
hZigBee->ZDO_POWER_DESC_request(0);
my_timer = SetTimer(1, DISCOVERYTIMER, (TIMERPROC) NULL);
//set node discovery timer number 1 for discovery called from button
if ( my_timer == NULL ) ::MessageBox( m_hWnd, "Error creating
device discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else ::MessageBox( m_hWnd, "A discovery is running", "GAL",
MB_ICONSTOP | MB_OK );
}
6.3.2. OnBnClickedServiceDiscovery
void CGALDlg::OnBnClickedServiceDiscovery()
{
if (DiscoveryRunning == false) {
DiscoveryRunning = true;
m_Status.SetWindowText("Service discovery started");
if (array_node[0]==NULL) return;
array_node[0]->ServiceReq(hZigBee, &count_expected_confirm);
my_timer = SetTimer(2, DISCOVERYTIMER, (TIMERPROC) NULL); //set
service discovery timer number 2 for discovery called from button
service discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else ::MessageBox( m_hWnd, "A discovery is running", "GAL",
}
6.3.3. Discovery (richiesta proveniente dalla rete)
92
LRESULT CGALDlg::Discovery( WPARAM wParam, LPARAM lParam)
{
CString XMLString;
if(DiscoveryRunning==false){
DiscoveryRunning=true;
reply_skt = (SOCKET) lParam;
m_Status.SetWindowText("Discovery called from socket");
if (array_node[0]!=NULL){
delete array_node[0]; //if a discovery has been already made the
data structures must be cleaned up
ZeroMemory(array_node,sizeof(array_node));
}
DiscoveryFailed=false;
array_node[0] = new Node(0);
hZigBee->ZDO_IEEE_ADDR_request(0, 1, 0, 0);
Sleep(WAITMSECOND);
hZigBee->ZDO_NODE_DESC_request(0);
Sleep(WAITMSECOND);
hZigBee->ZDO_POWER_DESC_request(0);
my_timer = SetTimer(3, DISCOVERYTIMER, (TIMERPROC) NULL);
device discovery timer", "GAL", MB_ICONSTOP | MB_OK );
}
else
{
XMLString = "<error>Discovery is running</error>";
/*send( (SOCKET) lParam, XMLString.GetBuffer(),
XMLString.GetLength(), 0 );
closesocket((SOCKET) lParam);
TRACE("connection closed\n");*/
MySend((SOCKET) lParam, XMLString);
}
return 0;
}
6.3.4. ServerThread
UINT ServerThread( LPVOID Param )

{
HWND mainWnd = (HWND) Param;
WORD wVersionRequested;
WSADATA wsaData;
int err;
wVersionRequested = MAKEWORD( 2, 2 );
err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 )
{
TRACE( "Error at socket(): %ld\n", WSAGetLastError() );
::MessageBox( mainWnd, "Error could not find a usable WinSock DLL",
"GAL", MB_ICONSTOP | MB_OK );
return FALSE;
}
/* Confirm that the WinSock DLL supports 2.2.*/
/* Note that if the DLL supports versions greater */
/* than 2.2 in addition to 2.2, it will still return */
93
/* 2.2 in wVersion since that is the version we */
/* requested. */
if ( LOBYTE( wsaData.wVersion ) != 2 ||
HIBYTE( wsaData.wVersion ) != 2 )
{
WSACleanup( );
return FALSE;
}
/* The WinSock DLL is acceptable. Proceed. */
server_socket = socket( AF_INET, SOCK_STREAM, 0 );

if ( server_socket == INVALID_SOCKET ) {
WSACleanup();
return FALSE;
}
/* Socket created */
sockaddr_in sin;
memset( &sin, 0, sizeof sin );
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = INADDR_ANY;
sin.sin_port = htons( server_port );
if ( bind( server_socket, (SOCKADDR*) &sin, sizeof(sin) ) ==
SOCKET_ERROR )
{
::MessageBox( mainWnd, "Error bind failed", "GAL", MB_ICONSTOP |
MB_OK );
closesocket(server_socket);
WSACleanup();
return FALSE;
}
TRACE("Server started at port 5001\n");
/* Server started */
if ( listen( server_socket, 1 ) == SOCKET_ERROR )

{
::MessageBox( mainWnd, "Error listen failed", "GAL", MB_ICONSTOP |
MB_OK );
closesocket(server_socket);
WSACleanup();
return FALSE;
}
TRACE( "Waiting for a client to connect...\n" );
SOCKET client_socket = NULL; //socket for incoming connection
int nRead; //number of read char
TCHAR buff[2]; //buffer for recv function
int last_err; //last error number
CString m_strRecv; //the whole string received
unsigned long num_data_pending;
CString resToken; //string for tokenizer
int curPos; //integer for tokenizer
CString XMLString; //string for http reply message
94
thread_on=true;
while (thread_on)
{
client_socket = accept( server_socket, NULL, NULL);
if (client_socket != INVALID_SOCKET )
{
m_strRecv = ""; //reset the string for a new receive
do{
nRead = recv(client_socket,buff,1,0);
switch (nRead)
{
case 0:
break;
case SOCKET_ERROR:
last_err = WSAGetLastError();
TRACE( "Error at socket(): %ld\n", last_err );
::MessageBox( mainWnd, "Error receive failed", "GAL",
break;
default:
buff[nRead] = 0; //terminate the string
CString szTemp(buff);
ioctlsocket(client_socket, FIONREAD, &num_data_pending);
if (num_data_pending==0) nRead=0;
m_strRecv += szTemp;
}
}while(nRead>0);
//http message received
TRACE("HTTP message received %s---\n", m_strRecv.GetBuffer());
curPos= 0;
resToken= m_strRecv.Tokenize(" /?=&",curPos); //first token
if (resToken == "GET") {
resToken = m_strRecv.Tokenize(" /?=&",curPos); //second token
TRACE("macro: %s\n", resToken);
/* The case statement is not applicable to CString!!! this is a
trick for more readable code */
if (resToken == "discovery"){
::PostMessage( mainWnd, WM_USER+DISCOVERY, (WPARAM)
sizeof(client_socket), (LPARAM) client_socket);
goto exit_case;
}
if (resToken == "nodeservice"){
resToken= m_strRecv.Tokenize(" /?=&",curPos);
if(resToken == "node"){
resToken= m_strRecv.Tokenize(" /?=&",curPos);
nodeservice_param * par = new nodeservice_param;
par->reply_socket = client_socket;
par->node = atoi(resToken.GetBuffer());
::PostMessage( mainWnd, WM_USER+NODESERVICE, (WPARAM)
sizeof(par), (LPARAM) par);
goto exit_case;
}
else goto default_case;
}
if (resToken == "notification"){
::PostMessage( mainWnd, WM_USER+NOTIFICATION, (WPARAM)
sizeof(client_socket), (LPARAM) client_socket);
goto exit_case;
}
95
default_case: TRACE("Wrong GAL request\n");
XMLString = "<error>Wrong GAL request</error>";
/*send( client_socket, XMLString.GetBuffer(),
closesocket(client_socket);
MySend(client_socket, XMLString);
exit_case: TRACE("");
}
else //if first token is not "GET"
{
TRACE("Wrong HTTP request\n");
XMLString = "<error>Wrong HTTP request</error>";
/*send( client_socket, XMLString.GetBuffer(),
closesocket(client_socket);
}
}
else // if client_socket is invalid
{
if (thread_on==true) ::MessageBox( mainWnd, "Error invalid
accepted socket", "GAL", MB_ICONSTOP | MB_OK );
}
} //close bracket of while(thread_on)
TRACE("Thread exit--------------------------------------------------
\n");
WSACleanup();
return TRUE;
}
6.3.5. Node
class Node{
char chIEEE[24];
unsigned char ieee_addr[8];
char chNWK[5];
unsigned short nwk_addr;
std::list<SimpleDescriptor *>::iterator iteSD;
std::list<Node *>::iterator iteN;
HTREEITEM tmp; //
public:
Node(unsigned short nwk_addr_par);
~Node();
NodeDescriptor node_desc;
PowerDescriptor power_desc;
std::list <SimpleDescriptor *> simple_desc;
std::list <Node *> Sons;
void set_ieee_addr(unsigned char * ptr_ieee);
char * get_ieee_addr();
char * get_nwk_addr();
void XMLWrite(std::ostream * XMLstream);
void ServiceReq(CZigBeeIf * hZB, int * count);
void BuildTreeCtrl(CTreeCtrl * ntc, HTREEITEM ti_parent);
};
96
7. Riferimenti
[SOSUS] INFORMATION PROCESSING AND ROUTING IN WIRELESS

SENSOR NETWORKS by Yang Yu (Motorola Labs, USA), Viktor K
Prasanna & Bhaskar Krishnamachari (University of Southern
California, USA)
[ZigBee.org] http://www.zigbee.org/
[ZBSpec04] ZigBee Document 053474r06, 14 Dicembre 2004
[ZBSpec06] ZigBee Document 053474r13, 1 Dicembre 2006
[Gilles Thonet] zigbee-faq.pdf
[EETimes] http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=1930
06037
[Freescale] www.freescale.com/files/wireless_comm/doc/brochure/BRZIGBEETE
CH.pdf
[Integration] http://www.integration.com/products/Zigbee_solutions.shtml
[BM] http://www.bm-modules.com/
[Datasheet] http://www.bm-
group.com/download/datasheets/BM_MOD01_Datasheet_rev2p5.pdf
http://www.daintree.net/news/jan07/zaspec-update.htm
http://rfdesign.com/mag/radio_implementing_zigbee_wireless/
http://www.dailywireless.org/2006/09/27/zigbee-2006
http://www.codeproject.com/cpp
97

Analisi e Implementazione Di Un Gateway Efficiente Per Wireless Sensor Networks

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisi e Implementazione Di Un Gateway Efficiente Per Wireless Sensor Networks

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSITÀ DEGLI STUDI DI PISA

Facoltà di Scienze Matematiche, Fisiche e Naturali

Analisi e implementazione di un gateway

ANNO ACCADEMICO 2006/2007

Ai miei genitori perché sono le mie radici e le mie ali,

ai miei nonni per il loro premuroso sostegno,

alla mia ragazza perché insieme i sogni sono più vicini,

alla sua famiglia per l’affetto dimostrato,

al prezioso Pasquale per tutti questi anni fianco a fianco,

al carissimo Ubaldo per la sua costante presenza,

ad Andrea, Francesco e Raffaele per la loro sincera amicizia,

al mio tutor Claudio per la sua cordiale disponibilità,

e a tutto il gruppo WSN per l’importante esperienza vissuta a Torino,

Dedicato a mamma e papà.

La prima parte dell’esperienza presso l’operatore di telecomunicazioni è stata

Figura 1 Logo ZigBee

 ZigBee Compliant Platform, questa certificazione specifica che il livello fisico e

 ZigBee Certified Products, questa certificazione specifica che il dispositivo è

Il primo livello di certificazione è indirizzato ai costruttori di semiconduttori, di moduli

Un profilo applicativo è un insieme di applicazioni che condividono gli stessi messaggi

ZigBee garantisce consumi limitati quando i nodi sono attivi in trasmissione/ricezione

ZigBee assicura la scalabilità permettendo la formazione di reti ad hoc

Per fornire l’interoperabilità tra prodotti di fornitori diversi, la ZigBee Alliance

2.1.2. ZigBee vs Bluetooth

Bluetooth ha origine nel 1994 dall’esigenza di Ericsson di proporre accessori wireless

Bluetooth è un protocollo complesso la cui implementazione occupa circa 250 KByte di

Figura 4 Confronto tra lo stack ZigBee e lo stack Bluetooth

Il seguente grafico rende l’idea dell’esatta collocazione di Zigbee e di Bluetooth

I dispositivi Bluetooth hanno consumi paragonabili a quelli ZigBee quando la radio è

Data rate 20 kbits/s 1Mbits/s

Network join time 30ms 3s

New slave enumeration 30ms 20s

Sleping slave changing to 15ms 3s

Active slave channel access 15ms 2ms

Power profile year days

Network topology ad-hoc, star, mesh, cluster ad-hoc, piconet

Number of devices per <65000 <8

Protocol stack 28 KByte 250 KByte

Tabella 1 Caratteristiche di ZigBee contro quelle di Bluetooth

Le differenze principali di ZigBee rispetto alla tecnologia Bluetooth, si possono

Un vantaggio fondamentale di ZigBee, rispetto al Bluetooth, è la sicurezza che viene

In definitiva, realizzazioni Bluethooth in semplici applicazioni, richiederebbero un costo

I prodotti commerciali presenti in ambito domestico che possono usufruire della

Figura 7 Home Automation

I benefici della connettività semplice, economica, a basso consumo offerta dalla

Figura 8 Industrial plant monitoring

La ZigBee Alliance intende allargare lo standard per coprire i seguenti campi di

Il profilo applicativo Automatic Meter Reading riguardarà l’ambito commerciale e

Le previsioni annunciano che questo standard riguarderà anche il mondo

Figura 9 ZigBee stack

2.2.1. Standard 802.15.4

Per la sincronizzazione lo standard prevede due modalità: "beacon mode”, se il

2.2.2. ZigBee Network Layer

Il processo di associazione di ognuno di questi dispositivi prevede l’assegnazione di un

Il compito principale di questo livello è l’instradamento dei pacchetti (routing). Quando

Figura 11 Tipologie di routing

La specifica ZigBee offre la possibilità di configurare la rete scegliendo lo Stack Profile

Tabella 2 Home Controls Stack Profile

 Si occupa di eseguire la formazione e la scoperta della rete.

 Si occupa dell’allocazione degli indirizzi.

 Si occupa dell’instradamento dei messaggi.

2.2.3. Application layer

Il ZigBee Device Object è una soluzione applicativa che ha il compito di inizializzare i