Studio, realizzazione e confronto di tecniche di risparmio energetico per applicazioni su reti di sensori ZigBee

Sommario Le tecnologie per NetworkEmbeddedSystem (NES), siano esse hardware o software, devono considerare alcuni aspetti 
fondamentali derivanti dai particolari scenari applicativi nei quali sono immerse. Sono tecnologie progettate per basso 
transfer rate, alimentazioni energetiche limitate (solitamente batterie) e alle quali viene richiesta grande dinamicità nelle 
attività di rete gestita in modo automatico (es., discovery e binding). Molto spesso oltre a quanto detto occore rispettare 
vincoli (soft o hard) di real-time. I domini applicativi sono tra i più svariati, pensiamo ad esempio all’ambiente 
industriale, domotico, auto motive, medico etc.
Questo lavoro vuole presentare e paragonare dal punto di vista energetico tre applicazioni per reti di sensori ZigBee su 
chip Texas Instruments CC2430. Più in particolare, pur svolgendo le stesse funzionalità di base, utilizzano protocolli 
applicativi differenti dai quali si cercherà di estrapolare vantaggi e svantaggi non solo dal punto di vista energetico ma 
anche funzionale. Partendo con una presentazione delle risorse hardware e software usate si prosegue con una 
panoramica dei due applicativi enfatizzando gli aspetti che più influenzano il nostro focus (consumi energetici) per 
arrivare alla quantificazione dei consumi in due scenari differenti.
Dai risultati ottenuti si capirà che il progettista di applicazioni NES non ha a disposizione una soluzione ottima in 
assoluto ma deve considerare ogni volta tutta una serie di fattori. Inoltre spesso, ma non sempre, efficienza energetica e 
funzionalità offerte sono dimensioni trasversali di uno stesso problema e il trade-off va ricercato volta per volta sulla 
base dei vincoli imposti dal dominio applicativo.
Introduzione Nel documento vengono studiate due applicazioni (SimpleApp1 e SimpleApp2) che pur garantendo alcune funzionalità 
comuni di base sono caratterizzate da protocolli applicativi differenti.
Esse sono state sviluppate sullo stack di protocolli ZigBee compliant Z-Stack e compilate ed eseguite su chip CC2430: 
si cercherà comunque si mantenere, ove possibile, una linea distaccata dalla tecnologia di riferimento. Tutti gli 
strumenti utilizzati durante il lavoro sono presentati nella sezione Strumentazioni e tools.
La coerenza con le misurazioni ufficiali Texas Instruments è stata verificata nel lavoro di tesi [18] .
SimpleApp3 è una variante di SimpleApp2 avente lo stesso protocollo applicativo e verrà utilizzata per verificare 
l’impatto sui consumi delle politiche di Power Saving offerte da Z-Stack.
Vengono elencati i principali obbiettivi che si vogliono raggiungere in ambito WirelessSensorNetwork:
1.Studiare in che modo e in quale misura la scelta di un protocollo applicativo incide sui consumi energetici;
2. Quali sono i caratteri da considerare in fase di progettazione dell’applicazione;
3. Fornire misurazioni e stime specifiche alla tecnologia utilizzata (Z-Stack e chips CC2430);
4. Quali sono (nel caso dei CC2430 ma è un risultato generalizzabile) le attività hardware più dispendiose;
5. Come opera e su quali fattori critici gioca una buona politica software di Power Saving?
Le tre applicazioni sono presentate nella sezione Presentazione delle applicazioni dove vengono descritti i caratteri 
comuni e caratterizzanti di ciascuna di esse, la funzione di costo energetico, le variabili e le flag di compilazione più 
importanti per un corretto utilizzo. Viene poi presentata graficamente la comunicazione tra i nodi e una traccia di packet 
sniffing (MAC e Application(APS) level).
In Misurazioni energetiche si introduce il setup degli esperimenti e la metodologia seguita per arrivare a quantificare le 
funzioni di costo presentate. La traccia seguita è simile a quella illustrata nel documento Texas Instruments [14] .
Nella sezione Caratterizzazione fasi si è costruito un set di misurazioni relative a configurazioni hardware standard allo 
scopo di ridurre al minimo gli errori umani nel passaggio dal grafico dei consumi alla misura numerica di corrente, dare 
un criterio logico alle attività del nodo e non considerare le differenze quantitative (ma non concettuali) tra le stesse fasi 
relative ad applicazioni differenti o esecuzioni differenti.
In Scenario1 e Scenario2 sono presentati due domini applicativi differenti e per ciascuno di essi sono state compilate, 
eseguite e confrontate le tre applicazioni SimpleApp1, SimpleApp2 e SimpleApp3.
Si è poi proceduto alla misurazione sul nodo e allo studio delle funzioni ottenute ( Comparativi ).
Nelle Conclusioni vengono toccati aspetti generali per le applicazioni NES, condizioni da considerare per una corretta 
lettura dei risultati ottenuti e per ciascuna applicazione viene fornito un bilancio che consideri consumi e caratteristiche 
funzionali.
Per una introduzione teorico-pratica utile alla lettura del documento si può consultare la sezione Cenni di teoria.
Durante la lettura si troveranno riferimenti bibliografici, a  Cenni di teoria e spunti per eventuali lavori di 
approfondimento.
Pagina 5 di 62
1 Strumentazioni e tools In questa sezione vengono presentate le risorse hardware e software utilizzate durante tutto il corso del lavoro.
1.1 Hardware e strumentazioni • PC con porta seriale RS232 e porta USB;
• 2 Chipcon SmartRF04EB Evaluation Boards con modulo CC2430 ( Figura 1) ;
• 1 CC2430DB Evaluation Boards per sniffaggio dei pacchetti (Figura 2);
• cavi usb per connessione, alimentazione, debug dei moduli e utilizzo dello sniffer;
• cavo rs-232 per la stampa a video dei messaggi proveniente dai moduli;
• Stabilized Power Supply, Stab AR100, 1.5-15V 10A; scheda acquisizione NI-DAQ e pannello BNC 2120, 
National Instruments; wafer card e resistenza da 1 ohm.
1.2 Software • ambiente Windows 2000 Service Pack 4;
• National Instruments Software;
• Measurement & Automation;
Pagina 6 di 62
Figura 2 : CC2430DB Evaluation Board.
Figura 1:  Chipcon SmartRF04EB Evaluation Boards con modulo 
CC2430.
• National Instruments LabView 7.1, NetcardAcquire e progetto AcquireNoFile 1
;
• IAR Embedded Workbench IDE V7.30 for 8051 (Chipcon CC2430)
2 
;
• Texas Instruments Z-Stack 1.4.2-1.1.0
3 
;
• Z-Tool;
• Packet Sniffer CC2430 ZigBee;
• SmartRF04 Prog.
2 Presentazione delle applicazioni Prima di affrontare questa sezione è consigliabile la lettura introduttiva del documento [6] e del documento [8] .
SimpleApp1 e SimpleApp2 sono due applicazioni scritte ad-hoc per mettere in luce due alternative implementative che 
portano la rete ZigBee creata a ricoprire le medesime funzionalità. Esse definiscono il comportamento di due tipologie 
di nodi: il Collector (con ruolo di Coordinator) e il Sensor (con ruolo di Router o EndDevice). Quando si parlerà di 
SimpleApp3 si indicherà un’applicazione avente medesimo codice sorgente di SimpleApp2 ma compilata con la flag 
POWER_SAVING disattivata nell’EndDevice. Per studiare il comportamento SW e HW di questa flag sul nodo 
CC2430 si rimanda al documento [8] o a Cenni di teoria - Power Management per CC2430 .
E' importante far notare che tutto il codice si appoggia quasi esclusivamente alle SimpleAPI
4
, una semplificazione delle 
API standard di Z-Stack che facilitano lo sviluppo di semplici applicazioni. Esse non hanno limitato in nessun modo lo 
studio in questione.
2.1 Caratteri comuni In questa sezione verranno descritte le caratteristiche comuni a tutte e tre le applicazioni sia per i nodi Collector sia per i 
nodi EndDevice.
Collector:
Dopo aver eseguito la fase di Network Formation, il nodo Collector prevede alcune azioni tramite joystick:
• SW1 per entrare nella modalità AllowBind (Led1 acceso) a tempo indefinito. Necessario quindi per permettere 
a qualsiasi EndDevice di inoltrare al Coordinator una EndDeviceBindRequest.
• SW2 per uscire dalla modalità AllowBind (Led1 spento) per un tempo indefinito. In questo modo il 
Coordinator non permette a nessun nuovo nodo di eseguire con successo una EndDeviceBindRequest.
Si assume che questo nodo sia alimentato da rete elettrica dunque con fonte energetica illimitata.
Infine, ogni volta che riceve con successo un pacchetto dati esso ne scrive il contenuto su RS-232 (eventualmente 
collegata ad una unità di elaborazione fissa). In fase di sviluppo è stato un utile strumento per il debugging SW.
Sensor:
Dopo aver eseguito la fase di joining alla rete, il nodo Sensor inoltra  automaticamente una EndDeviceBindRequest. Se 
non va a buon fine continuerà a farlo periodicamente (occorre per questo disattivare l'opzione di compilazione 
HOLD_AUTO_START ). Si noti che quanto appena detto permette l’utilizzo dell’applicazione anche a moduli non 
provvisti di joystick (caso molto frequente) oltre alla possibilità di disattivare il KeyPolling settando la variabile 
OnboardKeyIntEnable (= HAL_KEY_INTERRUPT_ENABLE) in OnBoard.c . Importante dire che la funzionalità del 
KeyPolling richiede un minimo consumo energetico.
Altre ottimizzazioni apportate:
• l’eliminazione del polling per l’attesa della chiamata alla callback zb_SendDataConfirm 5
 settando 
DRESPONSE_POLL_RATE = 0. L’attività del nodo EndDevice termina dopo la trasmissione con ricezione 
del MAC.ack poiché non sono previsti messaggi di conferma da parte del Collector dopo la ricezione del dato.
• l’eliminazione del polling a seguito alla chiamata della callback zb_ReceiveDataIndication settando 
DQUEUED_POLL_RATE = 0. Sarebbe infatti un polling inutile poiché non sono previsti più messaggi in 
coda nel Coordinator assumendo che TransmitRequestFrequency (TRF) > DataRequestFrequency (DRF).
1
Tale file di progetto in particolare visualizza r *1,5 con r dato reale di corrente.
2
 Per l’utilizzo dell’IDE si faccia riferimenti al documento: [9].
3
 Si faccia riferimento ai documenti: [6] e [5].
4
 Si faccia riferimento al documento: [4] e a Cenn i di teoria - Introduzione alle SimpleAPI.
5
 Si vedano le callback zb_SendDataConfirm e zb_ReceiveDataIndication nel documento [4] Pagina 7 di 62
Sarebbe interessante stimare l’impatto di queste ottimizzazioni sui risultati finali di consumo energetico. Ad una prima 
stima si può dire che l’impatto non è certamente ininfluente nel lungo periodo (almeno per quanto riguarda le due 
tipologie di polling) poiché azionano l’antenna del nodo e come si vedrà la trasmissione e ricezione sono le due attività 
più costose. 
Per quanto riguarda i fattori caratterizzanti si vedano le sezioni seguenti.
2.2 SimpleApp1
In seguito verrà presentata l'applicazione SimpleApp1 proponendo i caratteri specifici, una breve introduzione alla 
struttura del codice e alla sua compilazione nel Collector e nell' EndDevice e un message sequence chart. Verrà infine 
costruita la funzione di costo f(t) utilizzata in seguito per i calcoli dei consumi sui singoli scenari.
2.2.1 Elementi caratterizzanti Collector:
Dal lato Collector vengono inseriti nell'evento GIVE_ME_DATA_EVT generato dall' OSAL dei controlli sulle define 
compilative che definiscono il tipo di dato richiesto. Esso invoca il metodo zb_SendDataRequest(0xFFFF, 
SENSOR_REQUEST_CMD_ID, 2, pData, 0, FALSE, 0 ).
La chiamata genera un pacchetto in coda a livello MAC e in attesa di essere spedito ai nodi specificati (inviati in 
broadcast). Questo pacchetto rappresenta la richiesta di una particolare tipologia di dato a un generico nodo Sensor. 
Tale pacchetto verrà come vedremo raccolto dal Sensor. Successivamente il Collector sarà avvisato tramite la CallBack 
zb_ReceiveDataIndication( uint16 source, uint16 command, uint16 len, uint8 *pData ) di un dato in arrivo. Questo dopo 
opportune elaborazioni (si veda il ruolo di pData[0]) verrà scritto su porta RS-232.
Sensor:
Nel lato Sensor abilitando l'opzione NWK_AUTO_POLL viene attivato un polling di CMD.DataRequest al Collector 
alla ricerca di pacchetti in coda destinati a lui. La segnalazione di questa presenza avviene con la chiamata della 
funzione void zb_ReceiveDataIndication( uint16 source, uint16 command, uint16 len, uint8 *pData ) che leggerà il 
contenuto di pData e di conseguenza recupererà il dato richiesto. Se non lo trova ritornerà alla modalità LITE_SLEEP 
mode senza spedire nulla .
2.2.2 Architettura software Si mostra in Figura 31 il message sequence chart e lo Packet Sniffing in Figura 3 di parte dell’attività di SimpleApp1.
2.2.3 Funzione generica di costo Utilizzando il message sequence chart in Figura 31 si calcola la funzione f(t) dei consumi del protocollo trasmissivo 
caratterizzante SimpleApp1 non considerando le fasi di inizializzazione, discovery, binding e rebinding gestite in 
maniera analoga a tutte e tre le applicazioni e non direttamente coinvolte nel protocollo applicativo.
L’ idea è quella di misurare l’intervallo che durante tutta l’attività si ripete e di moltiplicarlo per il numero di volte che 
verrà eseguito. 
t = tempo di attività di SimpleApp1;
TRF = TransmitRequestFrequency;
DRF = DataRequestFrequency;
DRWDC = DataRequestWithDataCost;
DRNDC = DataRequestNoDataCost;
DRWDD = DataRequestWithDataDuration;
DRNDD = DataRequestNoDataDuration;
SMC = SleepModeCost.
ConsumoTotale = y = f(t) = CostoIntervallo * k
con 
Pagina 8 di 62
k = t / TRF
CostoIntervallo = (1 * DRWDC) +  //success ((TRF/DRF)-1) * DRNDC + //insuccess DRWDD – ((TRF/DRF)-1) * DRNDD) * SMC + //device in LITE_SLEEP
Figura 4: Schematico delle fasi che si alternano durante l'attività di SimpleApp1.
2.2.4 Compilazione e variabili d’ambiente Vengono descritte solo le flag indispensabili al corretto debugging dell’applicazione. Per ulteriori informazioni di faccia 
riferimento al documento [10] .
Collector: 
Opzioni di compilazione:
Per la richiesta del solo DataTemperature:
SET_TEMP
Per la richiesta del solo dato di DataBattery residua:
xSET_BATT
Per la richiesta del DataTemperature e di DataBattery residua, quest’ultimo solo nel caso fosse sotto la soglia 
minima decisa nel codice del Sensor.
xSET_TEMP_BATT
Pagina 9 di 62
Figura 3: Porzione di packet sniffing relativa ad una MAC.dataRequest, richiesta del dato e 
trasmissione al Coordinator. Si notino i MAC.ack .