Indice
1 Introduzione 5
1.1 Stato dell’arte . . . . 5
1.2 Obiettivi del lavoro . . . . 12
2 ZigBee e lo Standard IEEE 802.15.4 17 2.1 Introduzione . . . . 17
2.2 Finalit` a dello Standard . . . . 18
2.3 Architettura e principi di funzionamento . . . . 21
2.3.1 Protocollo di trasmissione . . . . 22
2.3.2 Robustezza della Trasmissione . . . . 25
2.4 Il Physical Layer (PHY) . . . . 27
2.5 Il Medium Access Control Layer (MAC) . . . . 30
2.6 ZigBee: vantaggi e prospettive di sviluppo . . . . 35
3 Progettazione dell’hardware 40 3.1 Definizione delle specifiche e schema a blocchi del sistema . . . 40
3.2 Il modulo ZigBee: il CC2420 . . . . 42
3.2.1 Compatibilit` a del CC2420 con ZigBee . . . . 44
3.2.2 Principi di funzionamento . . . . 45
3.3 Il microcontrollore: il PIC18F2510 . . . . 51
3.3.1 Le modalit` a di clock . . . . 53
3.3.2 I power managed modes . . . . 55
3.3.3 L’interfaccia SPI . . . . 58
3.3.4 Il convertitore A/D . . . . 60
3.4 Il Front End Analogico . . . . 61
3.4.1 L’amplificatore da strumentazione: l’INA321 . . . . 64
3.4.2 Il problema della flessibilit` a e le configurazioni possibili 67 3.5 Applicazione scelta e sensori utilizzati . . . . 72
3.5.1 Il sensore di pressione . . . . 73
3.5.2 Il sensore di temperatura . . . . 77
4 Descrizione del firmware 81 4.1 Descrizione generale del firmware . . . . 82
4.1.1 Inizializzazione . . . . 87
4.1.2 Accensione del CC2420 . . . . 88
4.1.3 Richiesta di un comando . . . . 90
4.1.4 Ricevuto . . . . 90
4.1.5 Ricezione . . . . 91
4.1.6 Men` u . . . . 92
4.1.7 Main . . . . 93
4.1.8 Impostazione dei parametri dei sensori . . . . 95
4.1.9 Definizione della potenza di trasmissione . . . . 96
4.1.10 Taratura . . . . 96
4.1.11 Modalit` a di wake up . . . . 97
4.1.12 Invio dei dati . . . . 98
4.2 Organizzazione del codice . . . . 99
4.3 Il firmware dedicato . . . 101
4.3.1 Funzione di taratura per il sensore 1 . . . 102
4.3.2 Funzione di taratura per il sensore 2 . . . 105
4.3.3 Descrizione del Main . . . 106
5 Risultati sperimentai 107 5.1 Sensore di temperatura: test condotti e risultati ottenuti . . . 109
5.2 Sensore di pressione: test condotti e risultati ottenuti . . . 112
5.2.1 Test in vitro . . . 112
5.2.2 Il test in vivo . . . 115
6 Conclusioni e prospettive del lavoro 125 6.1 Compatibilit` a ZigBee . . . 125
6.2 Flessibilit` a . . . 126
6.3 Ridotte dimensioni . . . 127
6.4 Consumi e autonomia di funzionamento . . . 128
A Lo schema finale del sistema 131 B Listato del codice 136 B.1 File funzioni.asm . . . 136
B.2 File prototipo.asm . . . 145
B.3 File applicazione.asm . . . 160
B.4 File myalias.inc . . . 175
B.5 File CC2420.inc . . . 177
B.6 File applicazione.inc . . . 178
B.7 File prototipo.inc . . . 178 B.8 File funzioni.inc . . . 178
Bibliografia 179
Capitolo 1 Introduzione
1.1 Stato dell’arte
Osservando lo stato dell’arte ` e possibile rendersi conto di quanto sia vasto il panorama della ricerca sui sistemi impiantabile che fanno uso della telemetria per il monitoraggio di parametri fisiologici. Del resto nel campo dei dispo- sitivi impiantabili si sono ottenuti, negli anni, successi importanti, si pensi per esempio al pacemaker cardiaco, che fra l’altro ` e tipicamente dotato di un sistema di telemetria.
Un primo importante campo di applicazione ` e senz’altro quello legato al
sistema gastro-intestinale: al fine di evitare i disagi che provocano gli esami
che utilizzano sonde endoscopiche sono state sviluppate, negli anni, diverse
soluzioni, come capsule [1] o microrobot [2]. Le prime vengono trasportate
grazie ai movimenti peristaltici dell’esofago prima e dell’intestino poi, i se-
condi sono dotati di locomozione attiva [3], in modo da potersi collocare in
una zona di particolare interesse. Entrambe le tipologie di dispositivi sono in
grado di monitorare diverse grandezze, quali temperatura, pH [4], pressione
[5], o possono utilizzare veri e propri sistemi di imaging. Ricerche di questo
tipo sono gi` a in fase avanzata e dispositivi del genere vengono attualmente rilasciati sul mercato.
Un ramo diverso ` e quello del monitoraggio del glucosio per pazienti dia- betici [6], che pu` o essere, fra l’altro, associato ai sistemi di rilascio controllato di insulina gi` a presenti sul mercato.
Ci sono, poi, le applicazioni che mirano all’acquisizione di diversi biopoten- ziali, compresi quelli ricavati da neuroni della corteccia cerebtale [7], [8], [9], con la finalit` a, dopo un opportuno signal processing di andare a stimolare la muscolatura, in modo da sostituire dei canali neurali interrotti in seguito a traumi, in modo da cercare di recuperare la mobilit` a degli arti.
Sistemi di telemetria possono anche essere utili nello studio e nel controllo dello stato di protesi articolari [10].
Un altro settore ` e quello che riguarda il sistema cardiovascolare, per il quale si deve spesso rinunciare a misure precise delle grandezze caratteristiche in quanto fortemente invasive o comunque necessitano di apparecchiature da ambulatorio. Si pensi per esempio alle misure di flusso sanguigno, che possono essere ottenute in modo soddisfaciente con i flussimetri elettroma- gnetici, che per` o richiedono l’accesso al vaso, oppure con strumenti ecografici.
La sola pressione fornisce informazioni parziali sul sistema, anche considerato
il fatto che potrebbe essere interessante conoscerne il valore preciso in punti
diversi del sistema (ventricolo, coronarie, ecc.), informazione non ricavabile
dal classico sfigmomanometro. Oltre alle applicazioni cliniche, fra l’altro,
questo ` e un settore di grande interesse per la ricerca medica [11] che ha la
necessit` a di monitorare delle cavie ed ` e costretta a farlo, spesso, mantenendole
sotto anestesia, invece che libere di muoversi, soluzione che sarebbe assai
preferibile.
L’obiettivo ultimo della ricerca in questi settore ` e quello di un monito- raggio remoto del paziente, attraverso gli strumenti di telecomunicazione di uso comune (internet, cellulari, ecc.), che colleghino i sensori impiantati su un soggetto direttamente con il medico [12].
Da questa rapida panoramica sulle applicazioni si intuisce subito la grande variet` a di sensoristica utilizzata. Si va da sensori chimici (ISFET, per esem- pio), per la misura del pH a sensori piezoresistivi con architettura a ponte interno per la pressione, a misure di tipo conduttivo o resistivo attraverso elet- trodi, a sensori di forza o all’acquisizione diretta di biopotenziali attraverso array di microelettrodi.
Un’altra differenza importante riguarda le diverse risposte che si sono date al problema dell’alimentazione, almeno nelle applicazioni in cui tale problema sia cruciale. Infatti nel caso del monitoraggio del sistema gastro- intestinale, per esempio, il tempo per il quale il dispositivo deve funzionare
`
e generalmente limitato e stimabile con una certa precisione (intorno alle
32 h), per cui, pur restando il problema di ottenere un’efficienza massima
in modo da poter ridurre il pi` u possibile le dimensioni, ` e accettabile l’uso
di una batteria sufficiente. C’` e, se mai, da tener presente che questi sistemi
hanno, a volte, sistemi di imaging, che richiedono una banda ben pi` u elevata
di un’applicazione che deve trasmettere solo dei campioni di una grandezza
fisiologica, e presentano consumi ben maggiori. In altri casi, invece, una
durata della batteria per periodi lunghi sarebbe auspicabile per pensare ad
un monitoraggio continuo di soggetti. Generalmente si resta comunque su
tempi dell’ordine dei giorni [11] o al massimo di un paio di settimane [5].
Un’alternativa a soluzioni a batteria ` e data dal trasferimento di energia al sistema attraverso un collegamento elettromagnetico. In sostanza il circuito ha una spira, o una bobina, che funge da secondario di un trasformatore ed ` e collegata ad un raddrizzatore e un regolatore di tensione. Il primario
`
e all’esterno del corpo, ` e costituito da una bobina di sezione maggiore e di maggior numero di spire che viene pilotata da un amplificatore di potenza in modo da generare un campo elettromegnetico sufficiente a trasferire al si- stema impiantato l’energia necessaria per operare. La scelta di una soluzione di questo tipo [10], [9], ` e giustificata dal fatto che presenta i vantaggi di non introdurre nell’organismo sostanze chimiche come quelle che si trovano nella batteria e di permettere di prevedere un impianto permanente, senza dover sottoporre il soggetto a un intervento chirurgico una volta finita la batteria.
Un’altra possibilit` a di questo tipo di soluzione ` e quella di modulare la portante con le istruzioni che dall’esterno si vuole dare al dispositivo o con i dati che esso trasmette, in modo da utilizzare lo stesso canale per la trasmis- sione, la ricezione e il trasferimento di energia come viene mostrato in [13], in cui si usa una portante a 2 MHz, con ampiezza dell’ordine di decine di volts, per alimentare il sistema, oltre che per lo scambio dei dati. In figura 1.1 si riporta lo schema di massima del sistema.
I vantaggi che questo tipo di soluzione offre hanno portato a studiare il problema dell’ottimizzazione del collegamento elettromagnetico [14].
Soluzioni di questo tipo, presentano, rispetto a quelle a batteria, il note-
vole svantaggio di un’efficienza molto bassa (intorno all’1%), per cui ` e ne-
cessario un certo consumo per alimentare il sistema esterno, inoltre il sistema
pu` o compiere, in effetti, solo una sequenza di misure, durante intervalli tem-
Figura 1.1: Schema di un sistema di telemetria con accoppiamento induttivo per l’alimentazione del circuito e per lo scambio dati [13]
porali decisi dall’utente. Non ` e possibile effettuare un vero e proprio moni- toraggio continuo di un parametro, che permetta di risalire alle condizioni fisiologiche precedenti al verificarsi di un cambiamento improvviso su tale parametro; n` e ` e possibile avvisare che dei valori fisiologici stanno uscendo dai range normali.
Le frequenze di trasmissione usate spaziano addirittura su tre ordini di grandezza: si va dall’ordine dei megahertz a quello dei gigahertz. Per le carat- teristiche di assorbimento che presenta il corpo umano la frequenza ottimale
`
e collocata sulle centinaia di megahertz [5], da cui le scelte dei 433 MHz [1], [5] o dei 303 MHz [6], con modulazioni di tipo digitale (FSK, ASK), tuttavia non manca l’uso della modulazione FM che fa spesso preferire la banda 98- 108 MHz [8]. Una novit` a interessante ` e presentata in [11], dove si ` e utilizzato un modulo Bluetooth (2.4 GHz).
A livello tecnologico, accanto alla soluzione a componenti discreti, al fine
di ridurre le dimensioni del dispositivo e minimizzare i consumi di potenza, vengono talvolta realizzati dei sistemi integrati su singolo chip (system on chip, SoC). Questi sistemi vengono progettati a partire dai blocchi alle cui propriet` a intellettuali la fonderia ha accesso, che vanno a completare quel- li progettati in proprio, se necessario, come ` e stato fatto in [1]. In questo modo ` e possibile, a partire dai datasheet e dal software di sviluppo dei bloc- chi, progettare il sistema, che la fonderia realizza poi su circuito integrato.
I processi CMOS usati sono di diverso tipo (0.35, 0.6, 1.5, 2.5 µm) e sono comunque ben al di sotto dello stato attuale dell’arte (90 e 60 nm), visto che non si ha a che fare con sistemi cos`ı complessi da richiedere tecnologie del genere. Con questo tipo di soluzione si riesce a mantenere le dimen- sioni del chip intorno a 4-5 mm 2 e i consumi intorno ai pochi milliwatt, complessivi. In [9] ` e presentato un rice-trasmettitore FM che consuma solo 460 µA, mentre in [8] si trova una comparazione fra le caratteristiche di vari dispositivi. Un altro vantaggio che tali sistemi presentano ` e la possibilit` a di integrare sullo stesso chip anche i sensori (per esempio ISFET, come in [1]) o dei microelettrodi [8], che vengono fabbricati, a partire dai processi CMOS, in modo da ottenere microsistemi che combinano funzionalit` a elet- troniche a meccaniche e che vengono comunemente chiamati MEMS (Micro Electro-Mecanichal Systems).
I SoC, comunque, presentano anche diversi svantaggi. Primo il costo,
che fra l’altro va combinato con l’assoluta impossibilit` a di rivedere le scelte
di progetto, magari su un blocco, per adattarle ad un’applicazione nuova,
senza ricomonciare il processo dall’inizio. Questo, specie finch´ e si resta nel
campo della ricerca, ` e senz’altro un limite importante. Inoltre le dimensioni
sono, normalmente, destinate a crescere. Talvolta infatti i disturbi introdotti dal blocco a radiofrequenza su quello di acquisizione sono inaccettabili ed ` e necessario separare i due moduli [1]. In pi` u il modulo esterno di alimentazione e l’antenna con l’eventuale circuito di adattamento impongono di rivedere le dimensioni del sistema finale che pu` o passare, per esempio, da 4.84 mm 2 ai 2 cm 2 di [8], pur sempre ottimo, ma pu` o essere destinato anche ad aumentare, qualora si voglia ottenere un’autonomia del sistema maggiore e si debba, quindi, utilizzare batterie pi` u grandi.
Le architetture per i sistemi, infine, sono abbastanza simili: quasi sempre si cerca di trarre beneficio dall’elettronica digitale e viene utilizzato un mi- crocontrollore, che comunica sia con il blocco analogico di acquisizione che con quello a radiofrequenza. Per quel che riguarda il front end analogico si trovano alcune differenze legate al tipo di sensori utilizzati. Si va dai pi` u diffusi amplificatori da strumentazione, come l’AD620 di Analog Device [5], a soluzioni pi` u complesse dedicate all’applicazione specifica [4], [8]. In alcuni casi, poi, si ` e cercato di dare al sistema una certa variet` a di configurazioni, come in [6], in cui viene utilizzato un sistema di switch per passare da una configurazione a corrente fissata ad una a tensione fissata su un elettrodo, oppure in [10], in cui si fa uso dell’AD7714 di Analog Device, che integra un amplificatore da strumentazione con ingressi configurabili (da tre totalmente differenziali a cinque pseudo differenziali) ed ` e dotato di guadagno variabile e di sistemi di bilanciamento degli offset.
A partire dalla consapevolezza della vastit` a del panorama della ricerca
in questo settore e di quelle che erano le linee del Centro di Ricerca in Mi-
croingegneria (CRIM), laboratorio della Scuola Superiore S. Anna di Pisa,
presso cui si ` e svolto il lavoro, ` e stato possibile definire gli obiettivi di questo lavoro e fissarne le specifiche, compiendo alcune scelte preliminari.
1.2 Obiettivi del lavoro
Quello della ricerca sui sistemi di telemetria impiantabile ` e un campo che il CRIM porta avanti da diversi anni, e che ha visto, talvolta, la collabo- razione diretta con il mondo della ricerca medica. In generale, infatti, per gli argomenti che il centro studia, la telemetria di dati provenienti da mi- crosistemi impiantabili ` e un aspetto importante a livello generale e coinvolge molte applicazioni specifiche.
In tempi relativamente recenti (2003) ` e uscito il protocollo IEEE 802.15.4, presentato al mercato con il nome di ZigBee (si veda il capitolo 2), dal quale ci si aspetta numerosi vantaggi nel campo delle reti wireless di sensori. Da qui l’idea, da parte di alcuni ricercatori del centro, tra cui l’Ing. Valdastri, relatore di questo lavoro di tesi, di andare a valutare la possibilit` a di eventuali applicazioni dello standard in campo biomedico, in modo da verificarne i presunti punti di forza.
Si ` e cos`ı intrapreso uno studio preliminare dello standard [15], cercando di
metterne a fuoco le caratteristiche fondamentali e di capire se e come potesse
essere utilizzato nella misura di parametri fisiologici. Una descrizione del
protocollo, utile a comprendere questo lavoro, ma anche a ricavare, in breve,
quali sono i suoi tratti essenziali si trova nel capitolo 2. Qui si cercher` a,
invece, di mettere a fuoco quali sono le motivazioni che fanno sperare di poter
ottenere dei risultati dall’uso di ZigBee e che hanno portato alla decisione di
intraprendere la fase di progettazione.
1. ZigBee si propone come sistema a basso consumo. In particolare ci` o che ` e interessante ` e la filosofia dello standard: esso infatti ` e pensato per applicazioni in cui i dispositivi possano trascorrere gran parte del periodo di funzionamento in una modalit` a a basso consumo e si attivino solo per un breve intervallo di tempo, necessario a trasmettere una certa quantit` a di dati. Questa idea pu` o essere utilizzata in molte applicazioni di tipo biomedico, in cui non ` e necessario un funzionamento continuo del sistema, mentre ` e importante il tempo di vita del sistema stesso che deve essere il pi` u lungo possibile. Il protocollo di trasferimento dati di ZigBee ` e pensato in tale prospettiva. Questa filosofia ` e stata il punto di partenza di questo lavoro, in cui si ` e cercato di dedicare particolare attenzione alla gestione del ciclo di funzionamento del sistema.
2. ZigBee permette di costruire reti complesse. Si pu` o arrivare, in teoria, fino a 65536 nodi. Nelle applicazioni che il CRIM studia non ` e raro avere a che fare con diverse entit` a che devono comunicare fra s` e, in pi` u si pu` o pensare al monitoraggio contemporaneo di pi` u sensori, impiantati anche su soggetti diversi. Inoltre la costruzione di reti complesse pu` o essere studiata in modo da implementare una ridondanza che migliori il risparmio energetico [16].
3. ZigBee ` e uno standard internazionale di tipo commerciale. Questo
aspetto presenta due vantaggi. Il primo ` e legato al fatto che c’` e da
aspettarsi, vista la presenza nell’alleanza ZigBee di case quali Philips o
Motorola, dei forti investimenti nei prossimi anni, il che significa con-
tinuo miglioramento delle caratteristiche dei componenti e possibilit` a
di utilizzare un protocollo solido e articolato senza doverlo sviluppare per intero. L’altro vantaggio ` e che un’applicazione che faccia uso di uno standard internazionale ` e pi` u facilmente interfacciabile con altre.
4. ZigBee opera sui 2.4 GHz. In effetti pu` o operare anche sugli 868 Mhz o 915 MHz, ma con data rate pi` u bassi dei 250 kb/s previsti per i 2.4 GHz, per cui queste ipotesi sono da scartare per non aumentare troppo i tem- pi di trasmissione dei dati. I 2.4 GHz si trovano proprio agli estremi della gamma di frequenza ottimale per le trasmissioni attraverso il cor- po umano, secondo lo studio svolto in [5], tuttavia presenta anche il vantaggio non trascurabile delle minori dimensioni per l’antenna.
Confermata, a partire da queste valutazioni, la scelta di ZigBee, sono state anche fatte altre scelte preliminari al lavoro.
Prima di tutto, riguardo all’applicazione, si ` e deciso, dato il panorama molto vario presente in letteratura e dato che lo stesso CRIM utilizza la telemetria con finalit` a diverse, di non focalizzarsi, almeno inizialmente su una in particolare. Anzi, constatato come spesso l’architettura a microcon- trollore, che di per s` e sarebbe facilmente riadattabile ad applicazioni nuove,
`
e spesso limitata, nella sua versatilit` a dall’hardware (si veda la sezione 3.4.2 per una discussione pi` u ampia di questo problema), si ` e pensato di svilup- pare il sistema con un’attenzione particolare proprio alla sua flessibilit` a ed adattabilit` a ad applicazioni diverse. Ad un certo punto del lavoro, poi, si ` e comunque fissato, per completezza e come esemplificazione, un’applicazione del sistema (sezione 3.5).
Per quel che riguarda l’alimentazione la scelta ` e caduta sull’utilizzo di
batterie. Questo per valorizzare l’autonomia che il sistema deve avere dal
soggetto: infatti si ` e pensato, nel progettarlo, ad applicazioni quali moni- toraggio e drug delivery, durante le quali il sistema non deve azionarsi solo a comando. Cercando di rendere le applicazioni compatibili con la gestione del ciclo di funzionamento descritta poco sopra, si spera di ottenere tempi di funzionamento lunghi, che rendano vantaggiosa o comunque percorribile la strada dell’impianto.
Come soluzione tecnologica di realizzazione, infine, si ` e scelto quella a componenti discreti perch´ e ritenuta pi` u consona, in questo momento, a rag- giungere gli obiettivi fissati sopra (basti pensare a quanto sarebbe prematuro cercare tra le propriet` a intellettuali un blocco transceiver ZigBee, visto che sono usciti da poco i primi moduli discreti). Questo non preclude evoluzioni future del lavoro verso tecnologie pi` u raffinate, di dimensioni minori (e pi` u costose).
Questo lavoro, quindi, si propone di progettare e realizzare un sistema impiantabile con le seguenti caratteristiche:
• includere un modulo di telemetria ZigBee compatibile,
• ridotte dimensioni,
• bassi consumi,
• lunga durata della batteria, ottenuta attraverso cicli di acquisizione pensati per questo,
• flessibilit` a hardware e firmware, in modo da poter essere utilizzato
come piattaforma per lo sviluppo di diverse applicazioni di interesse
scientifico,
• costi contenuti.
Di seguito saranno descritti il protocollo ZigBee (capitolo 2), le soluzioni adottate relativamente all’hardware (capitolo 3) e al firmware (capitolo 4).
Saranno riportati i risultati sperimentali del lavoro (capitolo 5) e discussi,
infine, i risultati ottenuti rispetto agli obiettivi qui fissati, evidenziando quali
saranno le priorit` a per uno sviluppo ulteriore del lavoro (capitolo 6).
Capitolo 2
ZigBee e lo Standard IEEE 802.15.4
2.1 Introduzione
ZigBee ´ e il nome di un’alleanza commerciale nata per sviluppare sistemi wireless per applicazioni che richiedano basso data rate, ma che possano prevedere reti con un gran numero di nodi, a partire dal protocollo IEEE 802.15.4 [15].
Identificare ZigBee con lo Standard IEEE 802.15.4 non ´ e del tutto cor- retto, quindi, anche se di fatto spesso succede. Il progetto ZigBee, che vede tra i promotori colossi del calibro di Philips, Motorola, Atmel, Mitsubishi, intende partire dal protocollo, che definisce gli aspetti di livello pi´ u basso, e sviluppare dei livelli superiori, proponendosi esso stesso come standard per arrivare ad applicazioni complesse e a prodotti commerciali di uso comune.
In questo capitolo si intende evidenziare brevemente quali sono le caratteri-
stiche del protocollo IEEE 802.15.4. A questo scopo, dopo un’introduzione
generale sulle finalit` a che si propone di raggiungere, lo standard sar` a descrit-
to nel suo insieme e saranno poi analizzati in modo pi` u specifico il Physical Layer (PHY) e il Medium Access Control (MAC) che esso intende definire. Si vuole cos`ı riassumere brevemente le caratteristiche principali di uno standard uscito in tempi relativamente recenti (anno 2003), in modo da evidenziarne gli aspetti essenziali e il funzionamento di insieme, al fine di offrire una pre- sentazione pi` u completa del lavoro svolto, senza appesantire la trattazione in maniera eccessiva e rimandando a [15] per ogni approfondimento.
Nella parte finale del capitolo sar´ a data una breve panoramica di come ZigBee intende collocarsi sul mercato e quali sono i suoi vantaggi e punti di forza rispetto, in particolare, a Bluetooth (IEEE 802.15.1).
2.2 Finalit` a dello Standard
Le caratteristiche dello IEEE 802.15.4, per quanto dichiarato nel documento stesso, sono:
• basso data-rate (250 kb/s massimo)
• bassissima complessit` a
• bassissimo costo
• connessioni a corto raggio, tipicamente 10m, senza escludere la possi- bilit` a che tale distanza possa essere superata, a secondo delle appli- cazioni.
• bassissimi consumi di potenza
In particolare lo standard intende definire i due strati (PHY e MAC) di
base di quello che pu` o essere uno stack assai pi` u complesso.
Le connessioni tra i dispositivi andranno a creare una rete (Low Rate Wireless Personal Area Network, cio` e LR-WPAN), cos`ı definita:
• bit rate di 250, 40 o 20 kb/s
• configurazione a stella o diretta (peer to peer ), mostrate in figura 2.1, eventualmente combinabili per formare maglie complesse
• indirizzo a 16 bit o a 64 bit, in modalit` a estesa
• allocazione di Guranteed Time Slots (GTS) per la gestione di comuni- cazioni complesse
• utilizzo della portante per individuare eventuali collisioni e accesso sicuro al canale
• basso consumo energetico
• misura dell’energia sul canale
• misura della qualit` a del collegamento
• 16 canali nella banda intorno ai 2450 MHz, 10 in quella intorno ai 915 MHz, 8 per quella intorno agli 868 MHz.
Un dispositivo compatibile con lo standard ` e classificabile come FFD (Full Function Device) o RFD (Reduced Function Device). Gli RFD sono pensati per applicazioni semplici, implementano solo alcuni aspetti dello standard e devono essere connessi a un FFD.
Una rete prevede la connessione di almeno due dispositivi. In ogni rete
un FFD deve sempre fungere da coordinatore della rete stessa. Le topologie
di base per le reti sono riportate in figura 2.1.
Figura 2.1: Topologia di rete a stella e peer to peer
Nelle reti a stella tutti i dispositivi sono connessi al coordinatore della rete, in quelle peer to peer ogni FFD ` e connessa con ogni altra FFD presente nella sua sfera d’azione, pur rimanendo indispensabile la presenza di un co- ordinatore.
Questa seconda topologia permette di costruire reti estremamente complesse, dotate di diversa capacit` a di connettivit` a, ma questo aspetto non ` e oggetto di approfondimento dello standard.
E’ possibile anche che possano coesistere reti indipendenti nella stessa regione
di spazio, perch´ e a ciascuna Personal Area Network (PAN) ` e assegnato un
identificatore (PAN-ID) grazie al quale ` e possibile gestire la comunicazione
sia all’interno della stessa PAN, sia tra PAN diverse.
2.3 Architettura e principi di funzionamento
L’architettura di un dispositivo di una LR-WPAN ` e definita attraverso dei blocchi, detti layers, a ciascuno dei quali sono assegnate funzionalit` a precise.
Lo standard si limita a definire il PHY, che ` e quello che contiene il rice- trasmettitore con le sue funzionalit` a di basso livello, che permettono di trasmettere e ricevere dati attraverso il canale, e il MAC che definisce le diverse strutture dati da trasmettere.
Ci dovranno essere, poi layers di livello superiore per gestire la rete stessa e le funzionalit` a che ciascun dispostivo deve implementare.
Figura 2.2: Architettura di un dispositivo LR-WPAN [15]
La struttura e le funzionalit` a principali di PHY e MAC saranno discusse
pi` u avanti (capitoli 2.4 e 2.5), mentre di seguito sar` a dato un quadro generale
del funzionamento di una LR-WPAN.
2.3.1 Protocollo di trasmissione
I dati che si devono trasmettere, fra due dispositivi o fra layers dello stesso dispositivo vengono raggruppati in pacchetti di byte come indicato in figura 2.3.
Figura 2.3: Struttura generale di un pacchetto
In particolare, il PPDU (PHY Protocol Data Unit ) ` e il pacchetto finale che viene trasmesso PHY nel canale, composto da:
- un preambolo che serve per la sincronizzazione dei dispositivi, costituito da 32 zeri,
- un delimitatore di inizio frame, costituito da byte 0xA7 che segna l’inizio del pacchetto vero e proprio,
- un byte che indica la lunghezza del PSDU (PHY Service Data Unit ).
In realt` a si usano 7 bit, il pi` u significativo ` e riservato, per cui si ottiene una lunghezza massima di 127,
- il PSDU che ` e un il pacchetto che il PHY riceve dal layer superiore, che
coincide con il MPDU, cio` e il pacchetto preparato dal MAC.
Il MPDU, a sua volta, comprende:
- il MAC Header, che contiene dei byte di riconoscimento,
- il MAC Service Data Unit (MSDU) che contiene ci` o che i layers superiori vogliono effettivamente trasmettere,
- il MAC footer (MFR) che permette di verificare se quanto ricevuto ` e corretto.
Una descrizione pi` u dettagliata del MPDU sar` a data nel capitolo 2.5, ma ` e utile accennare fin da subito a quali sono i tipi di frame che sono previsti:
• il beacon frame `e usato per scambiare segnalazioni utili per gestire la comunicazione nonch` e la fase di formazione della rete,
• il data frame `e usato per la trasmissione effettiva dei dati,
• l’acknolwdgement frame `e usato per segnalare la corretta ricezione di un frame,
• il command frame `e usato per trasmettere dei comandi per il MAC di un altro dispositivo.
Le modalit` a di trasferimento possono prevedere i beacons abilitati o meno.
Nel primo caso ` e sempre il coordinatore ad iniziare il trasferimento, inviando un beacon. Qualora un dispositivo debba trasmettere dei dati, pu` o farlo dopo la ricezione del beacon. Il coordinatore risponde con un acknowledgement, se richiesto.
Se invece il dispositivo si aspetta di ricevere dati, invia un command speci-
fico, al quale il coordinatore risponde con un acknowledgement, se richiesto,
e i dati. Il dispositvo pu` o a sua volta inviare un acknowledgement (figura 2.4).
(a) Da coordinatore a nodo (b) Da nodo a coordinatore
Figura 2.4: Trasferimento dati in modalit` a beacons enabled [15]
Esiste anche la modalit` a, pi` u semplice, in cui i beacons siano disabilitati, almeno per la gestione della comunicazione. In questo caso un dispositivo che voglia trasmettere dei dati, semplicemente li invia e pu` o ricevere dal co- ordinatore un acknowledgement.
Se invece deve ricevere dei dati invia una richiesta, con un command, al co- ordinatore, il quale risponde con un acknowledgement, se richiesto, a cui fa seguire i dati. Al solito l’acknowledgement di risposta ` e opzionale (figura 2.5).
La comunicazione pu` o essere anche gestita attraverso strutture dette su-
perframe. Il coordinatore gestisce questa modalit` a di trasmissione allocando
una finestra temporale, divisa in un massimo di 16 periodi di uguale durata,
tra due beacons. In tale intervallo i vari dispositivi possono effettuare una
trasmissione.
(a) Da coordinatore a nodo (b) Da nodo a coordinatore
Figura 2.5: Trasferimento dati in modalit` a beacons disabled [15]
In questo modo si creano dei conflitti tra i dispositivi della rete, che il coor- dinatore non si preoccupa di gestire.
Un’ulteriore possibilit` a, invece, ` e quella in cui il coordinatore alloca fino a 7 guaranteed time slots (GTSs), tra i 16 previsti, dedicati esclusivamente ad una certa applicazione della rete che magari ha delle specifiche pi` u delicate in termini di banda.
L’utilizzo della struttura superframe risulta utile per gestire reti complesse, con un gran numero di nodi.
2.3.2 Robustezza della Trasmissione
La robustezza della trasmissione ` e garantita da alcune caratteristiche.
La prima ` e il Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA), che definisce il protocollo per evitare collisioni tra dispositivi sul canale.
Essa consiste nell’ascoltare se ` e presente una portante sul canale. Se esso ` e
libero, la trasmissione pu` o avvenire, se ` e occupato il dispositivo aspetta per
un tempo casuale e ripete l’accesso.
Se si utilizza la struttura superframe il dispositivo effettua l’accesso all’inizio di uno slot (la sincronizzazione ` e possibile a partire dal beacon che il co- ordinatore invia) e, qualora non trovi il canale libero, lascia trascorrere un numero casuale di slots.
Una seconda ` e costituita dall’uso dell’acknowledgement. Qualora esso sia stato richiesto e non arrivi il dispositivo pu` o ripetere la trasmissione. Tale pacchetto non richiede il CSMA-CA.
Una terzo importante meccanismo che garantisce la robustezza ` e costi- tuito da un meccanismo di controllo nel MFR, controllo che avviene su due byte, che costituiscono la Frame Check Sequence (FCS), e che sono generati sui dati con un algoritmo che ne valuta delle propriet` a statistiche, al fine di garantire che ci siano il minor numero possibile di errori.
Infine lo standard dedica una particolare attenzione alla sicurezza del prorocollo. Ci` o ` e ottenuto attraverso:
• il meccanismo di Access Control. Esso consiste nel definire una lista (ACL) dei dispositivi con cui un nodo vuole comunicare e rifiutare ogni altro scambio di informazioni;
• la possibilit` a di criptare i dati, attraverso una chiave definita per la rete, per una parte di essa, o solo per due nodi;
• la possibilit` a di usare un messaggio che garantisca l’integrit` a dei dati, cio` e garantisca che i dati non sono stati modificati da un ente diverso che non conosca la chiave;
• un meccanismo per controllare quanto il dato `e recente: l’ultimo letto
deve essere pi` u recente del penultimo, altrimenti viene rifiutato;
A seconda di quali di questi meccanismi sono attivi si dice che il disposi- tivo opera il unsecured mode, se nessun meccanismo ` e attivo, in ACL mode, se ` e attivo solo la ACL, o secured mode se sono attivi tutti.
2.4 Il Physical Layer (PHY)
Il PHY, come si ` e accennato, ` e responsabile delle operazioni di basso livello, la maggior parte delle quali saranno in effetti implementate nell’hardware del dispositivo. Tuttavia un’identificazione precisa del PHY con l’hardware non
`
e corretta, dato che lo standard non detta regole precise in questo senso e il costruttore pu´ o scegliere di lasciare al firmware diversi aspetti del PHY.
Le operazione che il PHY deve poter compiere sono:
• accendere e spengere il rice-trasmettitore
• misurare la quantit` a d’energia presente su un canale (Energy Detection, ED), in modo da poter decidere se ha senso operare su tale frequenza o ci sono dei disturbi che rendono difficile la comunicazione;
• valutare un indicatore della qualit` a del collegamento (Link Quality Indicator, LQI) quando si ricevono dati;
• effettuare il CSMA-CA;
• selezionare il canale
• effettuare la ricezione e la trasmissione dei dati.
Le frequenze di trasmissione e i relativi data rates e tipi di modulazione
sono riportati in tabella 2.1.
Tabella 2.1: Bande di frequenza e data rates [15]
Ci si limita, qui di seguito a illustrare brevemente le caratteristiche del funzionamento nella banda dei 2450 MHz, che ` e quella che garantisce le mas- sime prestazioni in termini di banda. Il data rate dovr` a essere 250 kb/s.
Figura 2.6: Schema del modulatore [15]
In figura 2.6 ` e riportato uno schema a blocchi del modulatore. L’alfabeto che si usa ` e composto da 16 simboli, ognuno codifica 4 bit dell’informazione che si deve trasmettere ed ` e costituito da una sequenza pseudo-causale di 32 bit (chip). In tabella 2.2 sono riportate le equivalenze.
I chip cos`ı ottenuti vengono modulati in Offset Quadrature Phase-Shift
Tabella 2.2: Conversione dei dati per la trasmissione [15]
Keying (O-QPSK), cio` e ciascuno di essi va a modulare una portante sinu- soidale in fase o in quadratura in modo alternato, cio` e i chip dispari quella in fase e i chip pari quella in quadratura. Si ottengono cos`ı due segnali, sfasati di un semiperiodo, costituiti da una sequenza di semionde sinusoidali positive o negative a secondo del chip corrispondente.
In figura 2.7 sono riportati, come esempio, i segnali associati al simbolo zero.
Figura 2.7: Esempio dei segnali in uscita per il simbolo zero [17]
Oltre alla gestione delle frequenze e alle funzioni di rice-trasmissione, l’altro aspetto fondamentale del PHY ` e la costruzione del PPDU che si ` e illustrato in 2.3.
2.5 Il Medium Access Control Layer (MAC)
I compiti del MAC sono:
• generare i beacons se il dispositivo `e un coordinatore;
• garantire il sincronismo con essi, in particolare gestire il protocollo GTS;
• gestire la connessione e la disconnessione di un dispositivo alla rete;
• gestire tutti i meccanismi per garatntire la sicurezza;
• utilizzare in modo corretto il CSMA-CA per accedere al canale;
• garantire una connessione il pi` u robusta possibile tra due dispositivi della rete.
Il MAC utilizza, per svolgere i suoi compiti, diverse primitive che qui non si andr` a ad approfondire. Si ritiene invece necessario riprendere quanto gi` a accennato in 2.3 riguardo al MPDU e vederne i vari campi con un certo dettaglio, sia perch` e ` e necessario per una comprensione del firmware che si
`
e sviluppato in questo lavoro, sia perch` e la gestione dei MPDUs ` e uno dei primi aspetti che si deve affrontare per sviluppare un’applicazione ZigBee.
Si riporta in figura 2.8 la struttura di un frame generico, in cui sono riconoscibili i gi` a citati MHR, MSDU o MAC payload e il MFR.
Figura 2.8: Formato di un MPDU di tipo generico [15]
Nell’illustrarlo si metteranno in evidenza le particolarit` a dei vari bea-
con, data, acknowledgement, command frame in modo da dare un’idea della
struttura di questi ultimi.
Il MHR, come detto, contiene il FCF, il data sequence number e le informazioni sull’indirizzo del dispostivo che trasmette e del destinatario.
Il FCF ` e costituito da due byte e raccoglie varie informazioni. La struttura
`
e rappresentata in figura 2.9. E’ opportuno specificare che la trasmissione comincia dal bit meno significativo del byte pi` u a sinistra.
Figura 2.9: Frame Control Field [15]
Con riferimento alla figura:
• frame type segnala il tipo di pacchetto in accordo a quanto riportato in tabella 2.3;
• security enabled segnala se `e attivo o no il meccanismo di crittografia dei dati;
• frame pending segnala se c’`e un altro frame che deve essere trasmesso;
• acknowledgement request segnala se si vuole un acknowledgment frame in risposta, a conferma della corretta ricezione;
• intra-PAN segnala se la trasmissione avviene tra due dispositivi ap- partenenti alla stessa rete;
• source e destination address mode segnalano come vanno letti i campi
indirizzo relativi: 00 indica che l’indirizzo non ` e presente, 10 indica
l’uso di indirizzi a 16 bit 11 la modalit` a estesa a 64 bit. La modalit´ a a 16 bit consente di ottenere il limite teorico di 65536 nodi per la rete, tale numero si trova spesso in letteratura per indicare la potenza del protocollo.
Tabella 2.3: Tipi di frame [15]
Il sequence number serve per identificare la comunicazione che sta avendo luogo fra due dispositivi. Nel caso di beacons a ciascuno viene attribuito un numero e ciascun dispositivo deve essere in grado di memorizzare l’ultimo ricevuto. Eccetto la gestione della connessione e disconnessione di un dispos- itivo alla rete, solo il coordinatore utilizza i bacons ed essi diventano cos`ı un preciso meccanismo di coordinamento di tutta la rete.
Per gli altri pacchetti, invece, ogni dispositivo inizalizza il suo sequenziatore
in modo casuale e poi lo incrementa. Il sequence number serve solo per garan-
tire che durante uno scambio dati entrambi i dispositivi si stiano riferendo
allo stesso frame. Per esempio nel caso di un acknowledgement esso conterr` a
lo stesso sequence number del frame da confermare.
I campi address, invece, contengono l’indirizzo della rete di appartenenza e del dispositivo sorgente e destinazione del frame.
Nel caso di un acknowledgement nessuno di questi campi ` e presente, mentre nel caso di un beacon sono presenti solo le specifiche che riguardano il dispos- itivo trasmittente. Per gli altri casi non specificare uno dei due sottintende che ci si riferisce al coordinatore, ma si dovrebbe sempre specificare l’altro.
Il MAC payload ` e il campo che si differenzia di pi` u per lunghezza e com- posizione, a seconda del tipo di frame a cui si riferisce. Nel caso di un acknowledgement ` e assente, nel caso di un data contiene i dati veri e propri che si vuole trasmettere, nel caso di un command contiene un identificatore del comando e gli eventuali parametri che lo completano. Il caso pi` u com- plicato ` e quello di un beacon, date le diverse funzioni che esso pu` o avere, che vanno dalla gestione dei meccanismi di associazione e dissociazione da una rete, alla gestione della comunicazione con o senza GTSs; l’approfondimento dei vari casi ` e lasciato alla consultazione di [15].
Il MFR, infine, ` e costituito da due byte (Frame Check Sequence, FCS), generati a partire dal MHR e dal MAC payload con il seguente algoritmo:
- sia G(x) la base polinomiale G(x) = x 16 + x 12 + x 5 + 1
- sia P (x) il polinomio ottenuto a partire dai dati trasmessi tale che P (x) = b 0 x k−1 + · · · + b k−1
, dove b 0 ` e il primo bit trasmesso;
- sia x 16 · P (x) il polinomio ottenuto moltiplicando x 16 per P (x);
- si divida x 16 · P (x) modulo 2 per G(x) fino a ottenere come resto R(x) = r 0 x 15 + · · · + r 15
.
I coefficienti r 0 · · · r 15 costituiscono la FCS.
La FCS viene poi ricalcolata dal destinatario sui dati effettivamentericevuti e confrontata con quella indicata dal trasmettitore. ´ E cos`ı possibile stimare la correttezza di quanto ricevuto.
2.6 ZigBee: vantaggi e prospettive di svilup- po
Dopo questa panoramica sullo standard IEEE 802.15.4 si ritiene utile ap- profondire un po’, rispetto a quanto gi` a detto in 2.1, cosa sia effettivamente ZigBee, quali siano i suoi punti di forza e gli obiettivi commerciali.
Con riferimento alla figura 2.2, l’alleanza ZigBee nasce con l’intento di sviluppare gli Upper Layers, cio` e i livelli superiori al MAC (con relativo protocollo di comunicazione) fino ad applicazioni commerciali di uso comune.
Tali livelli, in particolare, sono costituiti da un’espansione e un’automa-
tizzazione del livello di sicurezza gi` a previsto nello standard al livello del
MAC, e dal livello di gestione della rete: la possibilit` a teorica di arrivare
fino a 65536 nodi (consentiti dalla modalit` a di indirizzamento ridotta), e la
possibilit` a di connessioni peer to peer induce a pensare ad applicazioni in reti
estremamente complesse, con topologia a maglia, in cui le connessioni siano
riconfigurabili in modo automatico in modo da ottimizzare i collegamenti o
sostituirli in caso di interruzione di uno di essi.
Nell’alleanza ci sono, poi, anche le competenze per lo sviluppo delle appli- cazioni, dal campo industriale a quello dell’utilizzo comune nell’industria dei giocattoli o dell’automazione della casa.
Quanto detto fino ad ora permette di capire la collocazione che ZigBee vuole assumere nel quadro delle applicazioni wireless, come si vede in figura 2.10.
Figura 2.10: Collocazione dei protocolli IEEE 802 in funzione del data rate e del range:
Wireless Personal, Local, Metropolitan, Wide Area Network
ZigBee, pi` u che ad una concorrenza con altri standard, quali, per esempio, Bluetooth che ` e quello pi` u simile per caratteristiche e mercato, si propone come soluzione mirata per un tipo specifico di applicazioni. Si riconosce, in figura, la collocazione a livello di PAN (Personal Area Network ) e LAN (Local Area Network ). L’altra caratteristica fondamentale ` e costituita dal basso bit rate.
Un confronto, seppure sommario, con le caratteristiche di Bluetooth per-
metter` a di capire quali sono i vantaggi sui quali ZigBee si propone di far leva.
L’origine dei due standard ` e simile: Bluetooth ha origine nel 1994 dall’esi- genza di Ericsson di proporre accessori per telefonia wireless, sulla frequenza dei 2.4 Ghz. Nel 1998 ad Ericsson si uniscono IBM, Nokia, Intel e Toshiba e si forma il Bluetooth Special Interest Group che verso la met` a del 1999 chiede alla IEEE di formalizzare lo standard. Il protocollo IEEE 802.15.1 che definisce il PHY e il MAC di Bluetooth viene pubblicato nel 2002.
ZigBee, invece, nasce da un’idea di Motorola, nel 1998 e nel 2001 comincia l’elaborazione del protocollo IEEE, pubblicato a maggio del 2003. A met` a 2002 nasce la ZigBee Alliance tra la stessa Motorola, Philips, Honeywell, Invensys e Mitsubishi. Numerose case si aggiungeranno in seguito, tanto da superare le 100 unit` a.
Questo cenno alla storia dei due standard non ` e superfluo per capirne le differenze: Bluetooth nasce prima, per applicazioni con bit rate abbastanza elevato (1Mbit/sec), dato che sono collocate in banda vocale e audio e per il trasferimento di dati digitali fra diversi sistemi di elaborazione (PC, palmare, cellulare, ecc.). ` E pensato per collegare pochi dispositivi, massimo otto, con reti a stella, ma spesso le applicazioni si riducono alla connessione di due dis- positivi. ` E pensato per funzionare in modo continuo, una sua caratteristica importante ` e la rapidit` a di connessione, cio` e la rapidit` a con cui un dispositivo si accorge della presenza di un altro e si prepara a stabilire il collegamento.
Per ottimizzare questo aspetto i dispositivi Bluetooth devono restare accesi
durante tutto il periodo di funzionamento, quindi la latenza non costituisce
un problema ed infatti si arriva a tempi di wake up di 3 s, ma il riconosci-
mento di tutti i dispositivi della rete pu` o arrivare anche 20 s, contro i soli 2 ms necessari per accedere al canale. Questa caratteristica di continuit` a di funzionamento porta anche conseguenze sull’alimentazione che deve essere a batteria ricaricabile (o, ovviamente, fissa).
Quanto detto permette di individuare immediatamente come Bluetooth risulti poco ottimizzato o assolutamente inadatto ad applicazioni di monito- raggio o attuazione a bassissima frequenza, ma alta ripetitivit` a, come processi industriali (es. la misura della temperatura in processi di trattamento di alimenti), l’automazione della casa, o tutte quelle applicazioni in cui, fra l’altro, potrebbe essere utile non limitare il numero dei nodi della rete.
Cos`ı ZigBee si presenta al mercato come una soluzione che vuole essere
ottimizzata per queste applicazioni: rinuncia ad un alto bit rate, prevede la
possibilit` a di costruire reti complesse e facilmente riconfigurabili, anche in
modo autonomo, garantisce tempi di risveglio dell’ordine dei 15ms, e di enu-
merazione dei dispositivi in rete dell’ordine delle decine di ms, aumentando
un po’ i tempi di accesso al canale (typ. 15 ms). Queste caratteristiche
permettono di sviluppare applicazioni in cui i vari nodi siano spenti o in
modalit` a basso consumo per la maggior parte del tempo, arrivando a durate
di batteria considerevoli, anche di anni, adatta per dispositivi che non pos-
sono essere ricaricati di frequente. Un’altra caratteristica significativa, poi, ` e
che lo stack di ZigBee dovrebbe richiedere circa 28 kB di memoria per essere
caricato, contro i circa 250 kB di Bluetooth. ` E importante notare, infine,
che i 250 kb/s sono una frequenza comunque elevata in applicazioni del tipo
di quelle citate sopra. Questo ha una duplice utilit` a: da una parte ZigBee
resta una soluzione percorribile anche per applicazioni a banda pi` u larga, al
limite con sistemi di interfacciamento con lo stesso Bluetooth, ma soprattut- to, visto che i consumi maggiori in molti casi (per esempio di sensoristica) potrebbero essere dettati proprio dalla rice-trasmissione, una frequenza trop- po bassa causerebbe un aumento dei consumi (aumenterebbe il tempo in cui il dispositivo deve stare in modalit` a rice-trasmissione).
Cos`ı tra gli obiettivi commerciali di ZigBee, accanto a quelli fondamentali dell’automazione industriale e domestica, non mancano gli apparecchi elet- tronici di consumo (TV, CD, ecc.), le periferiche per PC, i giocattoli. E non mancano le applicazioni di tipo medico, nel quadro delle quali questo lavoro vuole collocarsi, come accennato in precedenza e come si discuter` a a breve.
E bene chiarire che in questo lavoro di tesi non si ` ´ e implementato l’intero standard ZigBee, che sarebbe risultato senz’altro eccessivo in questa fase di progettazione prototipazione, ma si ` e cercato di sviluppare il firmware (si veda, in particolare, il capitolo 4) in maniera che questo risultasse il pi` u possibile compatibile con il protocollo IEEE 802.15.4, facendo leva sui punti di forza dello standard descritti sopra. L’utilizzo di livelli superiori dello stack rappresenta senz’altro un’opportunit` a necessaria per certi versi (si pensi ai problemi della sicurezza), affascinante per altri (la possibilit` a di mettere in rete pi` u dispositivi) ed ` e lasciata ad una successiva fase.
Nel seguito, comunque, sar` a spesso usato il termine ZigBee, volendo in-
dicare non tanto lo standard nella sua interezza, ma quelli che sono i suoi
tratti fondamentali, compreso senz’altro il protocollo IEEE 802.15.4, e la sua
filosofia, su cui si ` e cercato di costruire questo lavoro.
Capitolo 3
Progettazione dell’hardware
3.1 Definizione delle specifiche e schema a blocchi del sistema
Le specifiche per un sistema impiantabile che voglia raggiungere gli obiettivi fissati in 1 sono principalmente il basso consumo di potenza e le dimensioni piccole, tali criteri hanno guidato la scelta dei componenti da utilizzare e la definizione dell’architettura.
Per cercare di ottenere bassi consumi, infatti, si ` e cercato di progettare il sistema in modo che i singoli moduli possano essere attivati per l’intervallo di tempo strettamente necessario al loro utilizzo e possano essere spenti al di fuori di esso. Lo schema a blocchi che si ` e scelto per il sistema ` e risultato quello riportato in figura 3.1.
Il blocco pi` u critico, dal punto di vista del consumo di potenza, ` e il
rice-trasmettitore, per cui il microcontrollore (µC) dovr` a essere in grado di
gestirne l’accensione e lo spegnimento. Per quel che riguarda il front end
analogico si ` e scelto di utilizzare un interruttore al fine di controllare l’alimen-
tazione su tutto il blocco e non sui singoli componenti. Questo ha permesso
Figura 3.1: Schema a blocchi del sistema
di utilizzare i pin di I/O del µC per gestire, sempre attraverso interruttori, le diverse configurazioni del blocco.
Il blocco che risulta avere i consumi minori, in generale, ` e proprio il microcontrollore, che per questo motivo ` e l’unico responsabile del risveglio del dispositivo: la possibilit` a di utilizzare interrupt provenienti dagli altri blocchi per riattivare il µC ` e stata scartata perch` e meno vantaggiosa.
Per quel che riguarda l’alimentazione si ` e scelto di usare una comune batteria al litio di tipo commerciale. Questo perch` e tale aspetto, per quel che riguarda i dispositivi impiantabili, ` e tutt’oggi oggetto di ricerca piut- tosto avanzata [18] e una riflessione attenta su questo tema avrebbe occupato molto tempo ed energie con poche possibilit` a di giungere, a breve, a soluzioni che superassero di gran lunga le prestazioni di batterie come la Panasonic CR2450 (3 V, 620 mAh) visti anche gli altri vantaggi (quali l’affidabilit` a e la disponibilit` a sul mercato) di questi oggetti.
Per quel che riguarda le dimensioni fisiche dei componenti esse sono in-
dicate in tabella A.1. La miniaturizzazione del dispositivo, anche se non
eseguita effettivamente, ` e stato un aspetto che si ` e tenuto ben presente in
ogni fase del progetto, e sar` a discussa nel capitolo 6.
Un’altra specifica importante ` e stata la flessibilit` a del sistema, in modo che l’hardware consentisse di sfruttare pienamente i vantaggi dell’architet- tura a microcontrollore, prevedendo la possibilit` a di adattarsi ad applicazioni molto diverse. Si ` e cos`ı cercato di implementare il sistema, e in particolare il front end analogico, in modo che il µC possa adattarlo a vari tipi di sen- sori; l’utilizzo di switch e di potenziometri digitali ` e da intendersi proprio in questa direzione.
Infine la scelta di ZigBee ` e da considerarsi una specifica del lavoro: essa non ` e stata messa in discussione, proprio perch` e uno degli scopi ` e quello di andare a studiare i benefici che tale protocollo pu` o portare a questo tipo di applicazioni.
3.2 Il modulo ZigBee: il CC2420
Il progetto ` e iniziato dalla definizione del rice-trasmettitore. Questo perch` e, come detto, l’uso del protocollo ZigBee era una specifica fondamentale di progetto per cui tutto il resto dell’hardware e lo stesso firmware sono stati implementati avendo bene in mente la filosofia dello standard e le prestazioni che si potevano ottenere dal modulo di telemetria, che fra l’altro, ` e anche quello pi` u critico in termini di consumi.
Fra le possibilit` a, per altro non ancora cos`ı varie, che il mercato offriva si
`
e scelto il CC2420 di Chipcon, che si presenta in questa sezione.
Il CC2420 ` e un rice-trasmettitore operante sui 2.4 GHz, ZigBee compati-
bile. Integra su singolo chip anche il regolatore di tensione e il PLL ed inoltre
non richiede filtri aggiuntivi. Ha ottima sensibilit` a (-94 dBm) e reiezione del
canale adiacente (39 dB). Comunica con il µC attraverso interfaccia seriale
di tipo SPI, con data rate massimo di 10 Mb/s. Come componenti esterne richiede poco pi` u del solo quarzo, con i relativi condensatori. Dei 48 piedi- ni solo 10 sono utilizzati dal microcontrollore per controllarlo, gli altri sono tutti per connetere all’alimentazione i diversi blocchi interni del sistema. Le dimensioni del package sono 7 x 7 mm 2 .
La potenza in uscita ` e, al massimo, 0 dBm, ma pu` o essere ridotta, fino a -25 dBm con notevole beneficio dei consumi. La corrente assorbita in trasmissione, infatti, con alimentazione a 3.3 V, passa da 17.4 mA (57.4 mW) a 8.5 (28.5 mW). In ricezione invece assorbe 19.7 mA (65 mW). Inoltre il dispositivo dispone di altre modalit` a a basso consumo:
• idle (426 µA, 1.4 mW) in cui il dispositivo si porta in uno stato di attesa, dal quale pu` o passare rapidamente sia alla ricezione che alla trasmissione;
• power down (20 µA, 66 µW) in cui l’oscillatore viene disabilitato, sar` a quindi necessario un ciclo di attesa (typ 0.86 ms) prima di operare,;
• voltage regulator off (max. 1 µA, 3 µW) in cui viene disattivato anche il regolatore di tensione, i cui tempi di accensione sono dell’ordine degli 0.3 ms.
I consumi in trasmissione e ricezione sono significativi, come si vede, per questo sar` a necessario sfruttare al massimo la flessibilit` a del dispositivo e comunicare con l’esterno solo quando strettamente necessario.
Prima di vedere un po’ pi` u nel dettaglio come il CC2420 si presenta al
microcontrollore, si metter` a in evidenza quali sono le risorse hardware che il
dispositivo offre per implementare il protocollo IEEE 802.15.4.
3.2.1 Compatibilit` a del CC2420 con ZigBee
Il CC2420 implementa in hardware molte delle funzioni di competenza del PHY, quali, per esempio, la misura dell’energia sul canale e del LQI, oltre, ovviamente, alla trasmissione e ricezione dei dati.
La misura dell’energia viene fatta attraverso il Receive Signal Strenght Indicator (RSSI), che viene riportato in un registro apposito di 8 bit. Viene ricavato, in effetti, come media su 8 simboli (1 simbolo = 4 bit, quindi 128 µs in tutto) e un bit nel registro di stato indica quando ` e valido. Dal RSSI ` e possibile ricavare il LQI, via software. Opure una stima di questo parametro pu` o essere fatta con una correlazione sui primi 7 bit che seguono il SFD.
Questo perch` e usando solo il RSSI si ha che un’interferenza sul canale che causa un aumento dell’energia rilevata viene indicata come un aumento del LQI, mentre in realt` a ` e un disturbo. Ecco perch` e si pu` o cercare di stimare, invece, l’errore sui dati ricevuti. La correlazione ` e calcolata in hardware e riportata su 7 bit.
Per quel che riguarda il PPDU l’hardware implementa il preambolo (si possono scegliere anche preamboli diversi, perdendo la compatibilit` a ZigBee) e inserisce automaticamente lo SFD. Non calcola, invece il lenght byte, che andr` a inserito via software nella FIFO di trasmissione come primo byte.
Il CC2420, poi, realizza in modo automatico anche alcune funzioni del MAC, quali il CSMA-CA, che avviene attraverso il controllo del CCA (clear channel assestement ) e quelle relative alla sicurezza.
L’accesso sicuro al canale viene stimato confrontando il valore del RSSI
con una soglia che pu` o essere impostata. Per quel che riguarda la sicurezza di
trasmissione, invece, un primo meccanismo riguarda il controllo dell’indirizzo.
Quando tale modalit` a ` e attiva si rileva in modo automatico:
• la correttezza del FCF,
• il PANid, se presente (sempre se `e un beacon) deve coincidere con quello impostato in macPANid nella memoria del dispositivo,
• l’indirizzo di destinazione, se presente deve coincidere con macshortAddress in memoria,
• se `e presente solo l’indirizzo del sorgente si accetta solo se il dispositivo
`
e un coordinatore e il trasmettitore appartiene alla rete.
Se una di queste condizioni non si verifica i dati in ingresso non vengono accettati. Sui dati accettati, inoltre, viene effettuato in hardware il calcolo della FCS e il risultato viene indicato su un bit (CRC) che segnala la validit` a del pacchetto. C’` e, infine, la possibilit` a di inviare, in modo automatico, un acknowledgement qualora richiesto e qualora i dati siano stati giudicati validi.
Per quel che riguarda il MPDU, infine, quasi tutto deve essere fatto via software: il FCF, il sequence number, ovviamente i dati. Della FCS si ` e gi` a detto. Fra l’altro essa non viene presentata nella FIFO di ricezione, al suo posto sono dati invece due byte: in uno si trova il RSSI, nell’altro il CRC (MSB) e la correlazione dei dati sugli altri 7 bit a cui si ` e fatto riferimento poc’anzi. Tali dati sono di pi` u immediato utilizzo della FCS a cui non si ` e, in effetti, interessati direttamente.
3.2.2 Principi di funzionamento
Come gi` a accennato il CC2420 comunica con il controllore attraverso inter-
faccia seriale SPI. Esso ` e dotato di diversi registri di controllo, alcuni dei
quali servono per passare comandi al dispositivo. Ci sono, inoltre, due FIFO separate per la ricezione e la trasmissione dei dati, da 128 byte ciascuna. Esse non esauriscono lo spazio di RAM disponibile, in cui sono collocati anche i campi necessari per gestire la sicurezza (per esempio la chiave per criptare i dati), l’indirizzo della PAN e del dispositivo. In figura 3.2 sono riportati i col- legamenti con il µC, ai quali vanno aggiunti quello per il reset del dispositivo e quello per il controllo del regolatore di tensione interno.
Figura 3.2: Collegamenti tra il CC2420 e il µC [17]
In particolare i collegamenti per la SPI sono CSn, SI, SO, SCLK.
Quando il dispositivo ` e in ricezione cerca lo SFD di un frame. Quando
lo trova mette alto il piedino SFD, che rimane in tale stato finch` e non si ` e
ricevuto l’intero data frame, a meno che il riconoscimento dell’indirizzo non
fallisca e il dato venga scaricato. Il primo byte che viene scritto nella FIFO
di ricezione (RXFIFO) ` e quello che indica la lunghezza. In quel momento il
piediono FIFO viene messo alto e rimane in tale posizione finch` e la RXFIFO
non viene svuotata. L’istante in cui SFD va alto non ` e quello giusto per
accedere ai dati: qualora la verifica dell’indirizzo fallisca, per esempio, essi
vengono automaticamente rifiutati dal dispositivo e si potrebbe leggere dati non validi. Per decidere quando accedere, quindi, ` e opportuno controllare, pi` u che SFD, il piedino FIFOP, che viene portato a uno quando il numero di byte nella RXFIFO supera una soglia definita dall’utente. FIFOP torna nello stato basso appena si ` e letto un byte dalla RXFIFO.
In trasmissione il comportamento di SFD ` e simile: va alto dopo che ` e stato inviato il SFD, torna basso quando si ` e finito di trasmettere i dati.
Controllando SFD ` e possibile avere una stima della durata dell’operazione di ricezione e trasmissione, qualora sia necessario, per cui ` e bene collegarlo ad un piedino del µC che possa dare l’avvio a un timer. I piedini FIFO e FIFOP, invece, sono collegati esclusivamente alla gestione della RXFIFO. Il piedino CCA, infine, segnala il risultato dell’accesso al canale e pu` o essere utile al µC per riconoscere quando esso sia libero o meno.
Il µC pu` o accedere, attraverso l’interfaccia SPI, ai vari registri del CC2420, sia in lettura che in scrittura, nonch` e alla RAM. Le FIFO di ricezione e trasmissione, comunque, sono accessibili, l’una in lettura e l’altra in scrittura, attraverso due registri ad esse collegati, che puntano alla prima locazione non letta e incrementano il puntatore in modo automatico ad ogni operazione, semplificando lo scambio dei dati. I registri di comando maggiormente usati in questo lavoro sono stati:
• SNOP, che non esegue alcuna operazione, se non restituire lo STATUS BYTE (tabella 3.1), come avviene in ogni operazione di accesso ai regi- stri;
• SXOSCON e SXOSCOFF che accendono e spengono l’oscillatore, facendo
uscire o entrare, rispettivamente, il dispositivo in modalit` a power down;
• SRXON e STXON che portano il dispositivo dallo stato idle alla modalit` a di ricezione o trasmissione, rispettivamente;
• SACK e SACKPEND che mandano un acknowledgement con il bit pending frame (sezione 2.5 e figura 2.9) a zero o a uno, rispettivamente;
• SRFOFF che porta il CC2420 in modalit` a idle a partire da qualunque stato di radiofrequenza.
Bit Nome Descrizione
7 - Riservato
6 XOSC16M STABLE Indica se l’oscillatore ` e stabile
5 TX UNDERFLOW Segnala se il lenght byte non coincide con la lunghezza effettiva del MPDU e si ` e avuto un underflow
4 ENC BUSY Segnala quando il modulo che cura la crittografia dei dati sta lavorando
3 TX ACTIVE Segnala che si sta trasmettendo
2 LOCK Segnala che il PLL ` e agganciato
1 RSSI VALID Segnala che il valore del RSSI misurato ` e valido, cio` e ` e mediato su 128 µs
0 - Riservato
Tabella 3.1: Descrizione dello Status Byte
La figura 3.3 mostra il funzionamento della macchina a stati del CC2420
e le funzioni di questi comandi. Il firmware deve gestire correttamente il
dispositivo portandolo a lavorare nello stato voluto. Si notino, in particolare,
i tempi di calibrazione che andranno attesi. Si osserva anche che dopo la
trasmissione il dispositivo si porta automaticamente in ricezione, cio` e una
modalit` a di alto consumo, per cui si dovr´ a fare attenzione a lasciarlo in tale
stato solo per il tempo strettamente necessario.
Figura 3.3: Macchina a stati del CC2420 [17]
In figura 3.4, infine, viene riportato lo schema dei collegamenti del CC2420 con l’esterno; per tale schema ci si ` e attenuti a [17]. R 1 ` e una resistenza di bias, necessaria per la polarizzazione del circuito, C 1 ` e il condensatore neces- sario per stabilizzare il regolatore e deve avere la resistenza serie indicata in tabella A.1, qualora ci` o non sia possibile si pu` o inserire un resistore oppor- tuno in serie. Il regolatore interno dovr` a essere usato per alimentare solo il CC2420 per non rischiare di introdurre disturbi sul dispositivo.
Figura 3.4: Componenti esterni del CC2420
L’oscillatore deve essere a 16 MHz, in quanto determina la frequenza di trasmissione. Deve essere caricato con due condensatori tali che:
C L = 1
1 C
2+ C 1
3
