SlideShare uma empresa Scribd logo
1 de 108
Baixar para ler offline
Università degli Studi di Trieste
Dipartimento di Ingegneria Elettronica e Informatica
Corso di Studi in Ingegneria Elettronica
Tesi di Laurea Triennale
Implementazione di protocolli e simulatori MATLAB
per lo sviluppo del livello MAC di reti di sensori wireless
Laureando:
Michael Mozzon
Relatore:
Prof. Massimiliano Comisso
Tutore Aziendale:
Dott. Fabio Versolatto
ANNO ACCADEMICO 2016-2017
Indice
Introduzione V
1 Riferimenti teorici 1
1.1 Wireless Sensors Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Caratteristiche tecniche e limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Principali applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Accesso al mezzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Tecniche di accesso al mezzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Speciche aziendali e analisi degli standard . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Speciche aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Panoramica dei protocolli di accesso al mezzo . . . . . . . . . . . . . . . . . . . . . 8
1.4 Inconsistenza dei protocolli esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Analisi conclusiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Protocolli e ambienti di sviluppo 15
2.1 Elaborazione del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Presentazione dei protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Implementazione software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Programma d'ottimizzazione BlockDis(nodi, slot) . . . . . . . . . . . . . . . . . . . 32
2.3.2 Simulatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Raccolta e analisi dati 41
3.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1 Tempo d'esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.3 Nodi, blocchi e slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.4 Dimensionamento e consumo degli stati . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Caratteristiche speciche e consumi teorici . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 Protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.3 Tabella dei consumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Raccolta ed elaborazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Tabelle protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Tabelle protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4 Confronto e conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4.1 Confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
I
Appendice A 81
Appendice B 85
Riferimenti bibliograci 91
Elenco delle tabelle
1 Raronto dei protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Totale slot per corretta ricezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3 Congurazioni di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Dimensionamento e consumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Dimensionamento dei periodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Tempi di ricezione continuata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 Consumi delle fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8 Protocollo Asincrono, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9 Protocollo Asincrono, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10 Protocollo Asincrono - Caratteristiche delle reti . . . . . . . . . . . . . . . . . . . . . . 57
11 Tempi e consumi del transitorio, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12 Tempi e consumi del transitorio, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13 Protocollo Sincrono, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14 Protocollo Sincrono, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
15 Protocollo Sincrono - Caratteristiche delle reti . . . . . . . . . . . . . . . . . . . . . . . . 68
16 Densità di pacchetti trasmessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
17 Tempi d'esecuzione e tempi di vita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
18 Tempi di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
19 Consumi di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
20 Tempi di vita dei nodi master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Elenco delle gure
1 Fasi protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Compensazione del burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Ricezione pacchetti del burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Trasmissione simultanea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Protocollo Asincrono - Diagramma di usso . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Fasi protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7 Discovery phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8 Data Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9 Communication phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10 Protocollo Sincrono - Diagramma di usso . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11 BlockDis(5, 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
II
12 BlockDis(nodi, slot) - output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13 Rete a quattro nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14 Simulatore Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15 Simulatore Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
16 Vita per esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
17 Tempo di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
18 Consumo in trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
III
Introduzione
Il settore delle telecomunicazioni ha assistito, negli ultimi cinquant'anni, a una notevole crescita in
concomitanza al progredire e al diondersi dei servizi internet nel mondo, diventando una disciplina
di studio e di ricerca fondamentale ai ni dell'evoluzione delle società odierne.
La sua rapida espansione ha portato alla necessità di standard che permettessero di denire le linee
guida comuni nello sviluppo delle tecnologie a esso correlate.
Nel 1979 si giunse così alla pubblicazione del Modello ISO/OSI, il quale formalizzò l'implementazio-
ne delle reti di telecomunicazione attraverso la divisione in sette livelli indipendenti [1]. Ciò produsse
una considerevole facilitazione nella formulazione dei protocolli, i quali divennero specici rispetto al
livello d'appartenenza e autonomi in relazione a quelli adiacenti, generando la possibilità di sviluppare
studi di ottimo per singoli livelli e comporne poi i risultati con quelli ottenuti dai livelli limitro.
La continua necessità di informazioni sempre più accurate e precise nei più svariati ambiti sociali,
ha prodotto negli ultimi anni lo sviluppo di una tecnologia interna al settore delle telecomunicazioni,
quello delle reti di sensori wireless (Wireless Sensor Networks - WSNs).
Caratterizzate da dispositivi di piccole dimensioni e ridotta capacità di calcolo, queste reti, grazie
alle loro interconnessioni, permettono il monitoraggio di intere aree con costi molto contenuti. L'in-
teresse nel loro sviluppo è dato in aggiunta, dalle grosse moli di dati ricavabili, in relazione al basso
consumo energetico e alle scarse necessità manutentive.
Data la numerosità e la diversità di impieghi, al ne di ottenere in ogni settore la miglior risoluzione
possibile, si richiede a questa tecnologia una forte essibilità. Sono riscontrabili quindi molteplici
protocolli sviluppati ad-hoc per ognuno dei sette livelli dello standard, in funzione alle caratteristiche
espresse per ottimizzare la singola attività.
V
Obiettivo aziendale
Il presente lavoro di tesi è parte dello sviluppo di un progetto dell'azienda Innova S.p.a. di Trieste.
Tale progetto prevede la volontà di eseguire il rilevamento di pacchetti audio in streaming, utiliz-
zando dispositivi collocati a corta distanza tra loro, in un ambiente potenzialmente rumoroso.
L'idea di utilizzare una WSN viene suggerita dalle ulteriori speciche. Si richiede, infatti, che i
nodi presentino dimensioni ridotte e che una volta collocati assumano posizioni stazionarie non più
raggiungibili. E' inoltre richiesta l'assenza di connessione via cavo, sia per l'alimentazione che per le
comunicazioni.
In questo scenario, dunque, sono state denite alcune delle caratteristiche imprescindibili allo
sviluppo dei protocolli di rete, le quali consistono nel:
a) minimizzare i consumi
b) assicurare cammini multipli
c) permettere il multi-hop
d) garantire un alto throughput
Obiettivo di tesi
Analizzato il progetto nella sua interezza, si è riscontrata la necessità di strutturare dei nuovi protocolli
relativi al livello due dello standard ISO/OSI.
Si è quindi provveduto a una semplicazione del lavoro, andando a realizzare due protocolli che
fungessero da base di studio per il problema reale.
Questi, che saranno analizzati in dettaglio nel Capitolo 2, non trattano, quindi, il passaggio di
pacchetti per streaming audio, ma trattano bensì l'inoltro di un singolo pacchetto a tutti i dispositivi
connessi alla rete.
Più nel dettaglio si è supposta la necessità di trasmettere a tutti i nodi un pacchetto in possesso
del nodo master. Tale obiettivo è stato raggiunto attraverso lo sviluppo di programmi in linguaggio
MATLAB che simulassero i due protocolli mostrando le diverse strategie adottate per il trasferimento
del dato.
L'obiettivo formale di questo lavoro di tesi consiste, dunque, nella presentazione dei due protocolli
fungenti da base per il progetto aziendale e nel raronto delle loro caratteristiche mediante i dati
estratti dalle implementazioni software, con particolare attenzione al massimo tempo di vita delle reti.
Nei capitoli successivi verrà tenuto conto oltre che dell'obiettivo di tesi, anche dell'obiettivo azien-
dale. Si procederà, dunque, all'analisi di svariati protocolli esistenti in letteratura e alla verica della
loro adottabilità, in relazione a quello che concerne il progetto reale.
VI
Capitolo 1
Riferimenti teorici
In questo capitolo verrà fornita un'introduzione alle reti di sensori wireless e al livello d'accesso al mezzo
trasmissivo. Si provvederà inoltre a descrivere alcuni dei più noti protocolli presenti in letteratura
relativi a quest'ultimo e a esaminarli sulla base delle prerogative aziendali.
1.1 Wireless Sensor Networks
Una rete di sensori wireless (Wireless Sensor Network - WSN) è descrivibile come una composizione
di dispositivi di piccole dimensioni, chiamati nodi, generalmente costituiti da una ridotta capacità di
calcolo. Ogni nodo dispone di un elaboratore interno, un rilevatore (di natura diversa in dipendenza
dalle necessità d'utilizzo), una ricetrasmittente (tale da permettere scambi di informazioni a corto-
medio raggio) e una batteria [2].
Pur trattandosi di una tecnologia ormai d'uso comune in ambienti industriali e di ricerca, i problemi
a essa correlati sono ancora fonte di ampio dibattito e studio.
La principale ragione che determina alcune dicoltà nel denire protocolli standard per WSNs è
costituita dalla loro versatilità. La loro implementazione, infatti, mostra una relativa facilità d'utilizzo
e progettazione oltre che un misurato costo di produzione e manutenzione; tali caratteristiche hanno
portato le reti di sensori a essere strumenti dinamici, adottabili nei più svariati settori lavorativi e
oramai necessari in ambienti come automotive, il monitoraggio ambientale, la salvaguardia energetica
e la prognosi biomedicale.
Per queste ragioni è stato necessario stilare uno standard non restrittivo, che lasciasse ampio mar-
gine d'elaborazione, permettendo modiche e ottimizzazioni in coerenza con le molteplici possibilità
d'utilizzo dei dispositivi.
1.1.1 Caratteristiche tecniche e limitazioni
Ogni rete di sensori è costituita da un insieme di nodi, il cui scopo è eseguire rilevazioni mirate
dell'ambiente nel quale si trovano e trasferirle, sotto forma di dati, a un elaboratore esterno.
Convenzioni formali
Al ne di permettere una comunicazione controllata e coordinata dei nodi, sono state adottate alcu-
ne convenzioni che permettano di catalogare quest'ultimi in sequenze gerarchiche, in funzione della
posizione assunta all'interno della rete.
A tale scopo si denisce:
Master: il nodo incaricato dell'assegnazione dei compiti e della sincronizzazione temporale della
rete.
Slave: il nodo assoggettato al master.
1
Access Point (AP): elaboratore con maggiore capacità di calcolo che ha il compito di collegare i
dispositivi operanti attraverso Wi-Fi alla rete cablata.
Sink: il nodo al quale convergono tutti i pacchetti circolanti nella rete. Svolge anche il ruolo di
elaboratore primario, collezionando e ordinando i pacchetti al ne di inoltrarli al AP [2].
Caratteristiche tecnico-strutturali
Anché si possa parlare di WSN, è necessario porre particolare attenzione ad alcune proprietà.
Le principali caratteristiche tecniche che contraddistinguono questa tipologia di reti sono [2, 3]:
• Ecienza energetica: la rete deve essere autosuciente e sopravvivere per il periodo di tempo
desiderato, col solo ausilio delle batterie o di dispositivi atti alla produzione di energia (es.
pannelli solari).
• Scalabilità: dev'essere possibile modicare la rete incrementando o decrementando il numero di
nodi a disposizione.
• Organizzazione autonoma: i nodi devono essere in grado di denire una gerarchia interna condi-
visa, che ottimizzi le comunicazioni.
• Robustezza: la necessità di garantire il mantenimento dell'operatività, a seguito di eventuali
perdite di dispositivi o interferenze esterne.
• Throughput: velocità nella trasmissione dei pacchetti, giunti con successo al AP.
Le caratteristiche strutturali invece consistono in [2]:
• Bassa complessità delle topologie
• Compatibilità con gli standard
• Minimizzazione delle dimensioni dei nodi
• Basso costo di fabbricazione
Con particolare riferimento alle caratteristiche di ecienza energetica e robustezza, si fa notare che
per svariate applicazioni, le reti di sensori, una volta posizionate nell'ambiente di lavoro non saranno
più raggiungibili. Per questa ragione risulta di fondamentale importanza che esse si mantengano in
attività per il tempo necessario al compimento delle rilevazioni e che la perdita di qualche dispositivo
non inuisca eccessivamente sull'ecienza della rete stessa.
A tale scopo, sono stati e vengono tuttora implementati protocolli di comunicazione che prevedono
la massimizzazione dei periodi d'inattività dei nodi e la presenza di cammini multipli utili al ne di
evitare l'isolamento di intere parti della topologia a seguito della perdita di pochi dispositivi.
Altri vincoli vengono imposti dalla capacità trasmissiva dei singoli nodi. Risulta infatti evidente
la necessità di trovare il giusto connubio tra range di trasmissione e dispendio energetico, poiché
maggiore sarà la potenza a cui i dispositivi trasmetteranno il segnale e minore sarà il numero di
pacchetti inviabili prima dell'esaurimento della batteria. Per questa ragione si cerca di minimizzare
2
la distanza tra i dispositivi, procedendo preferibilmente con comunicazioni a medio-corto raggio che
prevedano il passaggio per più nodi intermediari (relay) piuttosto che la comunicazione a lungo raggio
diretta al nodo sink.
Su questo tema si deve però tenere in considerazione l'aumento di complessità dato dalla stesura
di un protocollo di routing tale da garantire la trasmissione attraverso multi-hop e dunque l'aumento
dei costi di produzione per il sistema.
Ulteriore compromesso riguarda il throughput che diminuisce considerevolmente all'aumentare del
numero di hop tra il nodo d'invio e il sink, a causa sia dell'aumento della probabilità d'errore in
trasmissione e ricezione, che al necessario tempo di re-inoltro dovuto al nodo intermediario [3].
Inne si ha da tenere in considerazione il forte limite dovuto alla capacità di calcolo ed elaborazione
dei nodi sink e master, nei confronti delle informazioni fornite dai dispositivi di rete. Tale vincolo li-
mita le dimensioni della rete stessa e viene ovviato grazie all'aggiunta di dispositivi di coordinamento,
i quali però necessitano di particolari protocolli di comunicazione rivolti all'accreditamento dei nodi [3].
Alla luce di ciò si può forse percepire la grande molteplicità di soluzioni sviluppabili e la notevole
importanza dell'analisi del problema in oggetto, allo scopo di redigere e calibrare un protocollo di rete
ad-hoc che giunga alla risoluzione del servizio richiesto senza sprechi.
1.1.2 Topologie
La scelta della topologia è una delle fasi fondamentali nell'ottimizzazione di una rete di sensori.
Per quanto riguarda le topologie di rete appartenenti al livello 2 del modello OSI (livello di
collegamento), poniamo attenzione alle congurazioni:
• Stella: costituita da slaves collegati a un unico master che assume anche la funzione da sink della
rete. Tale topologia è funzionale nel caso di reti non troppo estese, che comunichino attraverso
lo scambio di payload di dimensioni ridotte [3].
• Peer to peer: rete costituita da più dispositivi aventi tutti uguali caratteristiche. Ogni sensore è
abilitato a creare molteplici collegamenti diretti (single-hop), in direzione degli altri componenti
della rete, aumentandone quindi la robustezza. Si tratta di una topologia funzionale nel caso di
copertura di ampie aree con elevata probabilità di perdita di nodi.
Queste strutture prevedono anche la possibile implementazione a livello tre (livello di rete), attraverso
il quale si ha il multi-hop, ossia il trasferimento dei dati al di fuori della network d'acquisizione.
L'operazione viene svolta da nodi che devono essere programmati implementando anche il proto-
collo di routing.
Altre topologie di interesse sviluppate per l'implementazione al livello di rete sono quelle proposte
dalla Zigbee Alliance [3, 4]:
• Tree: rete ad albero con vari livelli di comunicazione dove le foglie sono semplici nodi sensori e i
nodi interni sono router. Tale rete svolge un ruolo concorrente alla topologia a stella, diventando
più eciente all'aumentare del numero di nodi e/o della grandezza del payload.
3
• Cluster: rete composta da un coordinatore centrale, collegato a molteplici routers che fungono da
master per i nodi aliati. Ogni router forma un cluster e ogni cluster è identicato da un preciso
ID. Le comunicazioni interne sono bidirezionali ma asimmetriche. Il master denirà gli istanti
di sincronizzazione del cluster e fungerà da sink per i dispositivi aliati, inoltre raccoglierà ed
elaborerà le informazioni procedendo al loro inoltro al coordinatore centrale.
• Mesh: rete a singolo coordinatore, data dall'unione delle strutture peer-to-peer e cluster. Tale
topologia rende la rete molto dinamica grazie alla ridondanza dei percorsi e permette anche la
creazione di strutture di reti più complesse.
1.1.3 Principali applicazioni
Le reti di sensori wireless sono strumenti dal grande potenziale. La loro versatilità ed economicità
ha portato questi dispositivi a diondersi rapidamente in tutti i settori del mercato nei quali fosse
richiesto non solo un feedback a stimoli attivi ma anche il semplice controllo e monitoraggio di eventi.
E' possibile eseguire una primaria distinzione sulla base dell'utilizzo di queste tecnologie.
Si considerano allora, WSNs per:
- Event Detection (ED)
- Spatial Process Estimation (SPE)
Nel caso di reti basate sulla ED avremo che i nodi trasmetteranno un segnale binario che indicherà
la presenza o l'assenza dell'evento da rilevare. Il messaggio conuirà a un coordinatore che analizzerà le
risposte pervenute e stimerà la probabilità di errore di trasmissione/ricezione, producendo il responso
del monitoraggio relativo all'intera area controllata.
Gli ambiti applicativi per questa categoria di reti sono i più svariati e possono andare dal controllo
ambientale di grandi aree, attraverso l'individuazione di incendi, alluvioni, terremoti, piuttosto che al
automotive, col ne di fornire feedback immediati riguardo il funzionamento di dispositivi elettronici,
o meccanici, no a raggiungere scopi di interesse militare o di sicurezza privata [2].
Per quanto riguarda la tecnologia SPE, queste reti hanno solitamente una disposizione di nodi
casuale e piuttosto tta. I pacchetti trasmessi conterranno informazione mirata riguardante il punto di
collocazione. Il ne è quello di fornire una distribuzione omogeneamente spaziata di una caratteristica
del territorio (pressione, temperatura, altimetria, etc.) [3]. La copertura e la nezza nella rappresen-
tazione risulteranno tanto più accurate quanti più nodi saranno presenti nella zona considerata. Al
contrario però si avrà che maggiore sarà il numero di nodi utilizzati e minore sarà il throughput della
rete.
Un'applicazione di recente sviluppo che utilizza entrambe queste strategie e data dal Energy E-
cient Buildings [3]. Essa permette l'ottimizzazione energetica degli edici grazie a sensori di movimento
(ED) e luminosità (SPE) disposti nelle stanze. Prevede inoltre la possibilità di controlli manutentivi
dello stabile quali inltrazioni o lievi cedimenti strutturali.
Altre applicazioni delle WSN si riscontrano nel settore domestico con il Home Automation, nel
settore commerciale relativamente al controllo qualità e tracciamento della merce, nel settore biome-
dicale, con monitoraggi non invasivi sui pazienti e sviluppo di strumentazione di alta specializzazione
e in svariati altri ambiti.
4
1.2 Accesso al mezzo
Il sottolivello MAC costituisce la parte più bassa del secondo livello dello standard ISO/OSI, posto a
diretto contatto col livello sico.
Il principale compito di questo sottolivello consiste nel gestire l'accesso al canale di comunicazione,
anché i dispositivi di rete possano eseguire scambi d'informazione [5].
A tale scopo sono implementati svariati algoritmi e protocolli, i quali si dierenziano in funzione alle
richieste e possono essere atti a minimizzare le collisioni dei frame in ricezione, piuttosto che garantire
l'ottimizzazione del duty cycle o la massimizzazione del throughput.
Uno dei problemi principali per il quale il livello MAC relativo alle WSNs viene implementato con
attenzione riguarda la salvaguardia della batteria e quindi la massimizzazione del tempo di vita dei
nodi interni alla rete [5].
Le problematicità da trattare in questo ambito sono numerose.
La principale fonte di spreco energetico è rappresentata dalle collisioni dei pacchetti all'interno del
canale di comunicazione.
Con il termine collisioni si vogliono identicare gli eventi che provocano la mancata ricezione del
frame. Essi sono tipicamente dovuti a una trasmissione concomitante (anche parziale) da parte di due
o più nodi in direzione di uno stesso ricevitore, il quale subirà un eetto d'interferenza che produrrà
disturbo nella ricezione del pacchetto e la conseguente necessità di chiederne la ritrasmissione [6].
Altre fondamentali cause della dissipazione energetica dei nodi sono dovute al overhearing, al idle
listening, al control-packet overhead e al over-emitting
1, tutte problematiche comuni che hanno biso-
gno di particolare attenzione in fase di progettazione del protocollo [6].
Si ha quindi che un buon protocollo MAC debba presentare caratteristiche di accesso tali da
moderare gli sprechi appena descritti e permettere il completamento delle rilevazioni richieste.
1.2.1 Tecniche di accesso al mezzo
Le tecniche di accesso al canale trasmissivo, come accennato in precedenza, sono molteplici. In pri-
ma approssimazione possono essere distinte in due categorie. Si parla quindi di accesso attraverso
Contention-Based Protocols, riferendosi a tutti quei protocolli che permettono l'inizializzazione delle
trasmissioni in maniera non coordinata, o attraverso Contention-Free Protocols, riferendosi invece ai
protocolli che garantiscono l'allocazione di risorse esclusive ai singoli nodi.
Contention-Based Protocols
Questi protocolli mostrano alte performance in relazione alla gestione di un traco randomico, generato
ad esempio dalla rilevazione ambientale, con la circolazione di pacchetti lungo tutta la rete [7].
Data la non coordinazione delle trasmissioni, essi devono prevedere meccanismi di controllo che gli
permettano di ridurre il rischio di collisioni e nel caso di gestirle; queste tipologie di protocolli vengono,
1Tutti i termini citati indicano fasi di dissipazione energetica superua ai ni della comunicazione desiderata. In
particolare ci si riferisce a overhearing indicando la ricezione da parte di un nodo di pacchetti diretti ad altri nodi
della rete; idle listening come il mantenimento della fase di ascolto in un canale dormiente; control-packet overhead
l'invio di pacchetti per il controllo del corretto funzionamento del canale; over-emitting come la trasmissione di frame
in intervalli temporali nei quali i nodi ricevitori non sono disponibili o ancora pronti [6].
5
infatti, spesso implementati prevedendo la ritrasmissione di pacchetti di acknowledgement al ne di
rendere nota al trasmettitore la ricezione o meno dei dati da parte del ricevente.
I principali protocolli di questo tipo sono il Carrier Sense Multiple Access (CSMA) e ALOHA.
Al ne del nostro lavoro ci limitiamo a fornire una presentazione sintetica solo del protocollo
CSMA
2.
- Carrier Sense Multiple Access (CSMA)
Si tratta di un protocollo ad accesso casuale basato sul rilevamento della frequenza portante
[8]. Le trasmissioni avvengono a seguito della verica della disponibilità del canale di comunicazione,
il quale può essere identicato come slotted nel caso in cui le trasmissioni debbano avvenire in
corrispondenza dell'inizio di uno slot; unslotted nel caso in cui le trasmissioni possano iniziare in
qualsiasi istante.
Col ne di evitare problemi di hidden-terminal
3, viene spesso richiesta la copertura attraverso col-
legamento broadcast a tutti i nodi, questo provoca però l'eetto opposto, generando il problema di
exposed-terminal
4 e provocando il rallentamento nel passaggio dei dati [9]. Negli sviluppi si predilige
ugualmente però questa seconda soluzione poiché limita gli eetti di collisione.
In relazione ai sistemi di accesso al canale del protocollo CSMA si possono aggiungere due esten-
sioni atte a migliorarne l'adabilità. Si parla allora di CSMA con Collision Detection (CSMA-CD) se
il protocollo prevede il monitoraggio del canale vericando che i dati non subiscano modiche durante
la trasmissione (metodo maggiormente utilizzato nelle connessioni via cavo) [10]. CSMA con Collision
Avoidance (CSMA-CA) se vengono messe in atto misure di controllo del canale, come l'allungamento
del periodo di listening, preposte ad aumentare la probabilità di trasmissione senza collisioni (metodo
utilizzato nelle connessioni wireless) [8, 10].
Questo protocollo, non richiedendo una fase di coordinamento dei nodi, consente un notevole gua-
dagno in termini di ecienza energetica nel caso in cui si abbia la necessità di trasmettere una quantità
limitata di dati, mostrando però forti limiti riguardo la velocità di trasmissione quando più dispositivi
simultaneamente presentano la necessità di comunicare.
Contention-Free Protocols
Si tratta di protocolli che non prevedono la presenza di collisioni, poiché a ogni nodo vengono allocate
delle risorse.
Questa categoria di protocolli è a sua volta implementata attraverso due strategie, la Fixed
Assignment e la Dynamic Assignment [9].
2Il protocollo ALOHA non viene descritto qui di seguito per ragioni di brevità. Si ha, infatti, che nessuno dei protocolli
presentati nel Paragrafo 1.3 o delle risoluzioni sviluppate e presentate nel Capitolo 2 utilizzi questa metodologia d'accesso
al canale.
3Con hidden-terminal si intende la trasmissione simultanea di più nodi verso uno stesso ricevitore, causata dalla
mancanza di visibilità reciproca.
4Con exposed-terminals indichiamo quei nodi che eseguita la richiesta di trasmissione, sono costretti a mantenere lo
stato d'attesa, poiché percepiscono la comunicazione tra nodi limitro.
6
Anche in questo caso, per motivi legati all'utilizzo successivo di quanto descritto, si è deciso di
presentare solo protocolli relativi alla strategia di Fixed Assignment.
Consideriamo allora i tre protocolli costituenti questa sotto-categoria:
- Time Division Multiple Access (TDMA)
Questo protocollo permette la comunicazione di più dispositivi attraverso la suddivisione del
frame di trasmissione in intervalli temporali (slot).
Ogni slot viene assegnato a un singolo nodo, determinando con esso una corrispondenza biunivoca.
Ciò è possibile grazie da una preliminare fase di sincronizzazione e al passaggio periodico di pacchetti
atti a garantirne il mantenimento.
E' previsto che tutti i nodi eseguano la trasmissione dati in rapida successione all'interno degli slot
costituenti il frame e che abbiano la possibilità di occupare l'intera banda di frequenze in dotazione al
canale [11].
Lo sviluppo di questa modalità d'accesso permette una comunicazione sicura (priva di collisioni) ed
eciente dal punto di vista energetico. Il dispendio della fase di coordinamento è, infatti, compensato
dal minor tempo di latenza dei nodi, che non dovranno restare attivi in attesa della liberazione della
portante ma potranno attivarsi unicamente in corrispondenza del proprio slot.
- Frequency Division Multiple Access (FDMA)
Basato sulla divisione di frequenza, il protocollo FDMA permette la trasmissione simultanea
di più ussi d'informazione. Si prevede, infatti, la suddivisione del canale di trasmissione in bande e
l'assegnazione di ogni banda a un dispositivo dierente [10].
Similmente al protocollo TDMA sarà necessaria una fase di coordinamento e quindi anche di studio
della topologia al ne di poter allocare le risorse.
- Code Division Multiple Access (CDMA)
Tale metodo di accesso multiplo si fonda sull'assegnazione, a ogni dispositivo di rete, di un
codice ortogonale dierente rispetto a tutti gli altri.
Le trasmissioni possono quindi avvenire negli stessi intervalli temporali e occupando l'intera am-
piezza di banda poiché i segnali risultano ugualmente distinguibili in funzione al loro codice.
Se nel caso di pochi serventi, il protocollo CDMA, non mostra particolare ecienza, risultati migliori
si ottengono all'aumentare dei nodi nella rete, arrivando a superare gli esiti ottenuti dai protocolli
TDMA e FDMA in relazione alla riduzione del duty cycle [10].
7
1.3 Speciche aziendali e analisi degli standard
1.3.1 Speciche aziendali
Come in parte descritto nell'introduzione, il progetto prevede l'individuazione di un protocollo per
WSNs che permetta la ricezione di le audio in streaming.
Tale prerogativa implica la trasmissione di molti dati in intervalli di tempo ridotti. E' stato quindi
stimato il minimo throughput necessario a garantire lo scopo, risultante in 192 kbps.
Dal momento che i pacchetti acquisiscono senso solo se ricevuti in sequenza, tra le speciche non è
richiesto il re-invio dei dati in caso di mancata ricezione. Questa caratteristica porta all'assenza della
necessità di acknowledgements con la possibile riduzione del usso di dati nella rete.
Il contesto nel quale si suppone verranno collocati i nodi, consiste in un ambiente urbano delle
dimensioni di una stanza. Si tratterà allora della disposizione di pochi dispositivi a una distanza che
non supererà i dieci metri.
Data la natura dell'ambiente, vi è la necessità di prevenire i possibili problemi dovuti all'interfe-
renza. Dev'essere quindi sviluppata una rete robusta e scalabile, che mantenga la sua operatività nel
caso di perdita o di ricomparsa dei nodi.
Considerato che a seguito della loro collocazione i sensori non saranno più raggiungibili e non vi
sarà la possibilità di alimentarli via cavo, appare indispensabile cercare di minimizzare il duty cycle,
imponendo una scarica graduale e omogenea delle batterie allo scopo di aumentare la longevità della
rete e il numero di rilevazioni.
Si richiede, inne, l'utilizzo di topologie generiche e la possibilità, da parte di tutti i nodi, di fungere
da relay, sviluppando, quando necessario, la comunicazione multi-hop.
Nessun vincolo viene imposto sul metodo d'accesso al mezzo trasmissivo, il quale però dovrà per-
mettere la soddisfazione di tutte le caratteristiche sopraccitate.
I requisiti protocollari da tenere in considerazione sono dunque riassumibili in:
- Elevata bit rate
- Robustezza e scalabilità
- Basso consumo energetico
- Genericità delle topologie
- Possibilità di multi-hop
1.3.2 Panoramica dei protocolli di accesso al mezzo
Presentiamo una rapida descrizione di alcuni dei più noti standard riguardanti il livello MAC, mettendo
in luce l'esistenza o meno dell'implementazione del livello di routing che permetta il multi-hop.
8
Bluetooth
Bluetooth è un sistema di comunicazione a corta distanza (massimo 10 metri), studiato per reti
WPANs. E' stato sviluppato in modo da consentire un'alta velocità di trasmissione (qualche Mbps)
in funzione di un moderato consumo energetico.
La rete è sviluppata in piconet di al più sette elementi attivi [12]. Per ogni piconet è previsto
un master che ha il compito di mantenere la sincronizzazione tra i dispositivi e fungere da sink per
l'elaborazione dei dati e il re-inoltro.
Il protocollo è sviluppato unicamente per topologie a stella o point-to-point, non sono previste
infatti comunicazioni multi-hop tra i nodi, i quali hanno la possibilità di comunicare solo in via diretta
col nodo master.
La modalità di accesso al mezzo all'interno di ogni piconet è basata su TDMA, in aggiunta il canale
viene suddiviso in 79 portanti e si utilizza la tecnica di trasmissione radio FHSS (Frequency Hopping
Spread Spectrum) grazie alla quale la comunicazione esegue cambi continui di frequenza evitando di
rimanere ssa su di un canale che potrebbe essere rumoroso [4].
Sviluppo ulteriore della tecnologia Bluetooth è la versione Bluetooth Low Energy. In essa vengono
ottimizzate le dimensioni e il numero di pacchetti trasmessi, i periodi d'inattività dei nodi e la fase di
rilevamento dei dispositivi. Permette un'ecienza no a quindici volte maggiore se confrontata alla
versione uciale del protocollo Bluetooth, tale ecienza è pagata però attraverso la diminuzione del
throughput il quale non supera i 300 kbps [3].
Zigbee
Zigbee è un protocollo sviluppato per la comunicazione in reti di ampie dimensioni, il cui obiettivo
principale è quello di minimizzare il consumo energetico.
La velocità di trasmissione può arrivare a 250kbps, garantendo la copertura sino a 75 metri.
I dispositivi costituenti ogni topologia sono di tre nature [3, 13]:
- Il coordinatore (FFD): che si occupa di denire i compiti e di eseguire la mappatura della rete.
- I router (FFDs): che permettono l'inoltro dei pacchetti.
- Gli end devices (RFDs): i quali possono unicamente trasmettere al FFD più vicino i propri pac-
chetti.
L'implementazione del protocollo prevede due possibili metodi d'accesso al mezzo: il beacon-
enabled mode e il non beacon-enabled mode.
Per quanto riguarda il non beacon-enabled mode si ha che tutti gli RFDs hanno la possibilità di
inviare i pacchetti agli FFDs in un qualsiasi momento, ciò provoca la necessità di mantenere dispositivi
router e coordinatore sempre attivi e in fase di ricezione poiché non si è a conoscenza di quando verranno
attivate le comunicazioni. Si verica quindi un forte dispendio energetico da parte di questi nodi.
Nel caso del beacon-enabled mode invece l'intervallo di trasmissione è predenito, quindi FFDs
e RFDs si attivano insieme in una fase di comunicazione gestita inizialmente attraverso CSMA-CA e
successivamente attraverso un dei protocolli contention-free [14].
Questa seconda metodologia d'accesso è stata sviluppata in principio solo per topologie a stella,
nelle quali tutti gli RFDs inviavano attraverso singolo hop i dati a un coordinatore di rete.
9
Seppur a seguito della denizione delle topologie cluster-tree
5 sia stato possibile sviluppare proto-
colli basati su questo metodo d'accesso che permettessero il multi-hop, si ha che la prevenzione dalle
collisioni, necessaria in questo caso, genera il notevole aumento del duty cycle di ogni nodo.
In letteratura esistono, infatti, protocolli che permettono la gestione di collisioni dirette
6 e indirette
7
dei pacchetti nell'esecuzione dei multi-hop,
Questi protocolli però necessitano di un intervallo temporale consistente per vericare le collisioni,
limitando l'ecienza e riducendo il risparmio energetico [14].
ANT
Questo protocollo è sviluppato per applicazioni ultra-low power, permette comunicazioni di tipo
broadcast, burst o con acknowledgement, in reti di dimensioni di circa trenta metri.
In modalità burst presenta una data rate di 20kbps (vero data throughput), nella modalità broad-
cast e acknowledgement permette di arrivare sino a 1Mbps [13].
Le topologie supportate sono del tipo point-to-point, stella, albero e mesh, arrivando a controllare
un massimo di cento dispositivi. Ogni nodo può fungere sia da master che da slave, garantendo quindi
una buona intercambiabilità al ne della condivisione del carico.
Il canale è suddiviso in sotto-portanti dell'ampiezza di banda di 1MHz e il metodo d'accesso è
basato su TDMA.
Si tratta di una tecnologia proprietaria, dai costi di produzione molto contenuti e dal bassissimo
dispendio energetico, la quale però manca d'interoperabilità [3].
S-MAC
Sensors MAC è un protocollo contention-based, che utilizza la tecnica di ascolto della portante con
collision avoidance per garantire la propagazione dei dati [6].
Il range così come la potenza trasmissiva, sono dipendenti dai dispositivi e le topologie supportate
possono essere di qualunque tipo.
Il protocollo è strutturato su due fasi: lo sleeping period e il listening period. Queste si alternano
in maniera sistematica, determinate da iniziali impostazioni di set-up atte a regolare il duty cycle [7].
Non essendovi un coordinatore di rete, i nodi eseguono l'accesso al canale secondo una program-
mazione temporale del tutto autonoma. E' inoltre prevista la possibilità di eseguire due accessi in
un singolo periodo, cosa che, seppur aumenta la possibilità di trasmissione, causa overhearing e idle
listening nel canale.
Allo scopo di ridurre i tempi di latenza, è introdotto un pacchetto di sincronizzazione, il quale
viene trasmesso broadcast da ogni nodo a quelli limitro, per condividere la propria programmazione
temporale [6].
5Topologie nelle quali ogni cluster è composto da un FFD a cui sono collegati zero o più end-devices. Ogni FFD è a
sua volta collegato con i coordinatori dei cluster limitro in modo tale da formare un albero attraverso cui poter eseguire
il re-inoltro dei pacchetti.
6Col termine collisioni dirette facciamo riferimento alle collisioni dovute alla trasmissione simultanea di due nodi
che sono l'uno entro il range di trasmissione dell'altro.
Esempi di questi protocolli sono il Time Division protocol e il Beacon Only Protocol [14].
7Col termine collisioni indirette ci riferiamo a quelle collisioni che hanno luogo su un terzo nodo, il quale riceve le
trasmissioni simultanee emesse da due nodi che non sono in range tra loro.
Esempi di questi protocolli sono il Reactive Approach Protocol e il Proactive Approach Protocol [14]
10
Si ha così che chiunque dovesse avere la necessità di trasmettere a un nodo, potrà risvegliarsi nel
corretto intervallo, evitando la dissipazione di energia.
Nonostante i pacchetti di sincronizzazione, l'accesso attraverso CSMA-CA, provoca tempi di latenza
considerevolmente prolungati sopratutto in relazione alle trasmissioni richiedenti multi-hop.
Si tratta quindi di un protocollo ottimizzato per permettere la trasmissione di pochi dati, ripetuti
con ciclicità.
LEACH
Il Low Energy Adaptive Clustering Hierarchy è un protocollo di ottimizzazione energetica molto
eciente. Basato sul concetto di divisione della rete in cluster, prevede la nomina di un master
(Cluster Head - CH) per ogni cluster, il quale varierà a intervalli regolari in maniera randomica [15].
Il protocollo prevede due fasi, la prima di set-up, con la formazione dei clusters e la nomina dei
rispettivi CH, la seconda di Steady State, nella quale il CH dovrà rimanere attivo per tutta la
durata del periodo di nomina, ricevendo ogni pacchetto derivante dal proprio cluster ed eseguendo la
compressione dei dati, prima di re-inoltrarli al AP.
La metodologia d'accesso al canale utilizzata è del tipo contention-free, solitamente implementata
attraverso CDMA o TDMA. Tale metodo viene adoperato al ne di minimizzare le interferenze, non
solo tra i nodi di un cluster ma anche tra cluster limitro [16].
Il protocollo prevede la possibilità da parte di tutti i nodi di raggiungere il AP, non viene per questo
prevista l'implementazione del livello di routing per gestire il multi-hop tra cluster. Le topologie di
rete risultano quindi basate su disposizioni a stella, concentrate in ridotte aree, tali da consentire la
visibilità diretta del AP.
11
1.4 Inconsistenza dei protocolli esistenti
Dall'analisi della letteratura trattata nel Sotto-paragrafo 1.3.2, si può denotare come ogni protocollo
descritto, seppur ane alle speciche di progetto, non sia suciente a soddisfare le richieste nella sua
attuale implementazione.
Si noti infatti che, nonostante il protocollo Bluetooth garantisca un'elevata bit rate, con la pos-
sibilità di reti a sette nodi attivi, esso non potrà essere utilizzato poiché non prevede la possibilità
di eseguire multi-hop essendo programmato solo per topologie a stella o point-to-point. In aggiunta
prevede una maggiore dissipazione di energia da parte del nodo master che dovrà farsi carico della
compressione e del re-inoltro dei pacchetti di tutta la rete.
Ugualmente, non potrà essere utilizzato il protocollo Bluetooth Low Energy, il quale seppur pre-
vedendo un minor consumo da parte dei nodi e una suciente velocità di trasmissione, non permette
ai propri dispositivi di funzionare da relay.
Stesso problema presenta anche il protocollo LEACH. Sebbene quest'ultimo soddis tutte le carat-
teristiche di risparmio energetico, robustezza e bit rate, la sua implementazione prevede la divisione in
cluster comunicanti direttamente con il AP; non è previsto di conseguenza alcun protocollo di routing.
Il relazione al protocollo ANT le problematicità cambiano. Il limite in questo caso è dovuto al
throughput, che raggiungendo i 60kbps non è suciente a garantire le risorse per lo streaming.
Malgrado le motivazioni siano diverse, il medesimo problema vincola anche il protocollo S-MAC.
Se nel primo caso, il limite alla velocità trasmissiva è dato dalla ricerca di massimizzazione della
durata della vita dei dispositivi. Nel secondo caso la causa della lentezza nelle trasmissioni è dovuta
al meccanismo d'accesso al mezzo, il quale, per il protocollo S-MAC, impone lunghi periodi di latenza
sopratutto in presenza di intenso traco.
Concludiamo con l'analisi del protocollo Zigbee, che presenta due tipi distinti d'implementazione.
Le problematiche legate allo sviluppo del protocollo attraverso accesso con CSMA-CA sono coerenti
con quelle riscontrate dal protocollo S-MAC. In questo caso però la prolungata latenza dei nodi non
incia considerevolmente la velocità di trasmissione, che invece rimane elevata, ma lede l'autonomia
dei dispositivi, i quali riscontrano l'aumento del duty cycle provocante il rapido consumo delle batterie.
La seconda metodologia d'accesso, che utilizza CDMA o FDMA, presenta invece un basso consumo
energetico, ma come in relazione al protocollo LEACH, la suddivisione della topologia in clusters,
produce una notevole dicoltà nello sviluppo di protocolli di routing. Si ha infatti che questi quando
sviluppati, provocano il decadimento delle prestazioni nella trasmissione di dati o nella sopravvivenza
della rete.
1.4.1 Analisi conclusiva
Giunti a questo punto è necessario sottolineare che, malgrado quella di questo capitolo fosse solo una
breve esposizione comprendente alcuni dei protocolli d'accesso al mezzo più conosciuti, riuscire a sod-
disfare le speciche assegnate non è aatto banale. Difatti, anche l'analisi più approfondita di tali
protocolli o la ricerca di altri (come Wireless Hart, Z-Wave, Pegasis, etc.) non avrebbe prodotto risul-
tati migliori, limitandosi a evidenziare caratteristiche già citate e nel complessivo non soddisfacenti le
12
prerogative aziendali
8.
Se ne conclude la necessità di costruire protocolli nuovi, sviluppati ad-hoc, in conformità con gli
standard e le speciche assegnate.
Proponiamo ora la tabella riassuntiva dei protocolli, corredata con quelle che sono le necessità
aziendali ed enfatizzando gli attributi che hanno reso i protocolli studiati non consistenti col nostro
progetto.
8Facciamo notare come Wireless Hart non presenti la possibilità di comunicazione attraverso multi-hop [17] così come
il protocollo Pegasis [16], mentre Z-Wave essendo una tecnologia proprietaria, come ANT, manchi di interoperabilità.
13
Consumo
Energetico
ThroughputTopologieRangeComunicazioneRouting
Prerogative
Aziendali
basso192kbpsAd-hoc[0.5,10]mQualsiasiSi
Bluetoothelevato1-3Mbps
Piconet
Stella
PointtoPoint
10m
TDMA
(FHSS)
No
BLuetooth
LowEnergy
basso300kbps
Piconet
Stella
PointtoPoint
10m
TDMA
(FHSS)
No
Zigbee
elevato
basso
250kbpsAd-hoc100m
CSMA/CA
TDMA
Si
No
ANTmoltobasso60kbps
Stella
PointtoPoint
Tree
Mesh
30mTDMASi
S-MACbasso60kbpsAd-hoc100m
CSMA/CA
TDMA
Si
LEACHmoltobasso500kbps
Cluster
Stella
10m
CDMA
TDMA
No
Tabella1:Rarontodeiprotocolli
14
Capitolo 2
Protocolli e ambienti di sviluppo
Questo capitolo è dedicato alla formalizzazione dell'obiettivo di tesi e alla presentazione dei due
protocolli ideati per soddisfarne le speciche.
Si eseguirà inoltre una dettagliata descrizione dei simulatori e dei programmi a contorno che hanno
permesso la raccolta dei dati.
2.1 Elaborazione del problema
Prese in considerazione le problematiche esposte nel capitolo precedente e i limiti dei protocolli esi-
stenti, presentiamo, con questa tesi, la formulazione di un protocollo semplicato che funga da base di
lavoro per risolvere il problema reale.
Proponiamo, quindi, la progettazione e l'analisi di un nuovo protocollo, il quale non prevede più la
ricezione di frames per streaming audio, ma consiste bensì nella trasmissione di un singolo pacchetto
a tutti i nodi della rete.
Questo pacchetto, che viene trasmesso dal nodo master, supponiamo contenga informazioni ge-
neriche e nello specico relative al tempo, quindi all'orario scandito dal nodo master con la propria
precisione.
L'obiettivo è quello di valutare il minimo numero di iterazioni del frame che assicuri a ogni nodo
una probabilità di ricezione dell'ora maggiore del 99.5% e studiarne i risultati al variare delle topologie.
Facciamo notare che questa fase di progettazione non tiene conto di alcune delle dicoltà sottolinea-
te in precedenza. Non vi sono, infatti, riferimenti all'implementazione di protocolli per comunicazione
multi-hop, non vengono considerati i problemi dovuti alla robustezza della rete, in quanto si assume
la mancanza d'interferenza esterna e quindi la completa visibilità tra i nodi nel canale di comunica-
zione, e non si considerano, inne, neppure i problemi indotti dalla scalabilità, poiché l'esaurimento
della batteria da parte di un solo nodo porta alla terminazione della fase di comunicazione fornendo
le informazioni relative alla massima longevità della rete.
Si provvede però ad analizzare gli eetti delle collisioni ed è appunto su questo tema che si concen-
tra la stima delle iterazioni d'invio che inuenza la vita dei dispositivi.
In conclusione ci limitiamo a cercare il miglior protocollo che massimizzi la durata delle batterie di
tutti i dispositivi sottoposti a comunicazione.
15
2.2 Presentazione dei protocolli
A seguito della rielaborazione del problema, confrontiamo due soluzioni che permettono formalmente di
soddisfare le speciche minimizzando il duty cycle. Queste prendono il nome di Protocollo Asincrono
e Protocollo Sincrono in riferimento alle dierenze d'accesso al canale trasmissivo.
La presentazione dei protocolli e lo studio delle simulazioni software ci permetteranno, nel capitolo
successivo, di determinare le condizioni d'ottimalità di entrambi e quindi di denire il protocollo
migliore per fungere da base d'analisi al problema reale.
2.2.1 Protocollo Asincrono
Bastato sull'idea implementativa del protocollo S-MAC, il protocollo Asincrono prevede l'accesso al
mezzo trasmissivo attraverso CSMA. Non prevedendo fasi di coordinamento, questo metodo assicura
un considerevole risparmio energetico iniziale, il quale andrà dissipandosi all'aumentare del numero di
comunicazioni nella rete.
La trasmissione dati avviene sotto forma di burst di pacchetti, trasmesso da ogni nodo in possesso
dell'informazione in istanti pseudo-randomici delle comunicazioni.
Considerato che i pacchetti costituenti il burst contengono tutti la medesima informazione, ai nodi
limitro è suciente la ricezione completa di un unico pacchetto.
La scelta di utilizzare un burst è data dalla volontà di limitare i tempi di ricezione. In particolare
ogni nodo alterna brevi stati di ricezione a più lunghi stati di dormienza, dunque per permettere la
ricezione di un pacchetto è necessario fare in modo che il burst duri almeno il tempo di due ricezioni
successive.
Poiché nodi diversi possono eseguire il burst in istanti di tempo vicini, la gestione delle collisioni deve
basarsi sullo studio del numero di ritrasmissioni necessarie anché tutti i nodi abbiano la possibilità di
ricevere il frame. Per il nostro studio, consideriamo soddisfatta questa condizione quando otteniamo
una probabilità di corretta ricezione maggiore allo 0.995.
Lo studio della probabilità è stato sviluppato attraverso l'implementazione del programma Block-
Dis(nodi, slot) che verrà presentato nel Paragrafo 2.3.1.
Le topologie, come previsto dalle richieste, possono essere di natura generica purché costituiscano
un insieme connesso: ossia tutti i nodi devono avere nel loro raggio di trasmissione almeno un altro
dispositivo e non ci devono essere settori isolati; inoltre, la rete deve prevedere la presenza di almeno
un nodo slave e di un solo nodo master, denito a priori, che funga da trasmettitore iniziale.
Attraverso la Fig.1 è possibile vedere la generica attività di un singolo nodo in riferimento al proto-
collo. Si può notare come essa sia caratterizzata da quattro stati, quello di risveglio (Waking up state),
quello di dormienza (Sleeping state), quello di ricezione (Receiving state) e quello di trasmissione (Data
packet transmitting state). Viene inoltre enfatizzato come l'alternanza di questi stati dia luogo a due
fasi, Receiving phase e Transmitting phase, costituenti le possibili attività dei nodi.
Il protocollo ha una struttura periodica nel tempo tale da permettere la divisione in blocchi e
periodi.
16
I blocchi identicano l'intervallo temporale tra due ricezioni successive.
I periodi, invece, sono costituiti da un numero sso di blocchi tale da includere un burst di tra-
smissione. Il numero di periodi, data la relazione con il burst di pacchetti, risulta essere funzione del
programma d'ottimizzazione
9.
Sottolineiamo come questa suddivisione sia indipendente dalla struttura della rete. Difatti, poiché il
protocollo è asincrono dobbiamo supporre che le basi dei tempi (quindi blocchi e periodi) possano
essere sfasate da nodo a nodo.
Figura 1: Fasi protocollo Asincrono
Analisi degli stati
Waking up state
Consiste nell'intervallo di tempo necessario anché il nodo si riattivi e prenda conoscenza del compito
da svolgere negli istanti successivi. Precede ogni stato d'attività, seguendo agli stati di dormienza dei
dispositivi.
Il consumo energetico previsto è limitato poiché tutte le operazioni richiedono unicamente l'utilizzo
dalla CPU interna al sensore.
Sleeping state
In questo intervallo temporale il nodo risulta inattivo. Si tratta di uno stato di dormienza che permette
di preservare al massimo la batteria, non consentendo alcuna operazione se non il proseguire dei cicli
di clock col ne di determinare il successivo istante di risveglio.
Osservando la Fig.1, si fa notare che lo stato di dormienza che segue la trasmissione del burst di
dati è di lunghezza dierente rispetto a quello che segue gli stati di recezione. Questo fatto è dovuto
alla necessità da parte del singolo nodo di attendere l'inizio del nuovo blocco prima di procedere con
la fase successiva.
9Durante la presentazione del simulatore Asincrono, Paragrafo 2.3.2 - Sotto-paragrafo Protocollo Asincrono, si
provvederà a fornire maggiori spiegazioni riguardo la necessità d'utilizzo di più periodi ai ni della corretta ricezione del
frame da parte di tutti i nodi interessati.
17
Data packet transmitting state
Questo stato permette al nodo di trasmettere pacchetti alla rete. Le dimensioni sono calibrate su quelle
del pacchetto da trasferire e il consumo energetico è elevato a causa dell'utilizzo della ricetrasmittente.
Receiving state
Lo stato di ricezione prevede l'utilizzo della ricetrasmittente per l'ascolto del canale di comunicazione.
Anche questo presenta un consumo elevato e il dimensionamento è funzione dei pacchetti trasmessi. Si
ha, infatti, che ogni stato di ricezione dev'essere almeno due volte più lungo di ogni stato di trasmissione.
Analisi delle fasi
Transmitting phase
La fase di trasmissione è una delle due attività consentite a un nodo sensore che implementa questo
protocollo.
Questa si compone della successione di tre stati: Waking up state, Data Packet Transmitting state
e Sleeping state.
Il numero di iterazioni dello stato Data Packet Transmitting è funzione delle dimensione del
pacchetto e della lunghezza dei blocchi. Tale numero di iterazioni va a formare il burst di trasmissione
e assicura la possibilità di ricezione da parte di tutti i nodi limitro
10.
La fase di trasmissione è pseudo-randomica. Difatti, tutti i nodi aventi necessità di trasmettere
individuano autonomamente un blocco nel quale eseguire il burst.
La trasmissione viene eettuata una sola volta per periodo e il numero di periodi successivi che
presentano il burst è deciso dal programma di ottimizzazione.
La presenza di questa fase non è obbligatoria in ogni periodo ma è attivata solo in caso di neces-
sità da parte del nodo. L'intervallo di tempo occupato dal burst può, infatti, venire compensato dal
susseguirsi di due stati di ricezione, come mostrato nella Fig.2.
Figura 2: Compensazione del burst
10Il dimensionamento del burst è specicato nel sotto-paragrafo successivo, Receiving phase
18
Poiché negli istanti iniziali di vita della rete l'unico nodo ad avere l'informazione è il nodo master,
questo esegue un periodo comprendente la fase di trasmissione, mentre tutti gli altri dispositivi com-
pletano lo stesso periodo in fase di ricezione. Essendo il canale privo di perdite, tutti i nodi a distanza
di un hop dal trasmettitore ricevono l'informazione. Il nodo master, quindi, non avendo più necessità
di comunicare, esegue i periodi successivi in fase di ricezione.
I nodi slave, invece, ricevuto il pacchetto provvedono al suo re-inoltro. Tale operazione, come
suggerito in precedenza, è costituita da un numero di periodi dato dal programma d'ottimizzazione
e comprendenti la fase di trasmissione. Ovvero, i nodi trasmettono il burst per un numero di pe-
riodi opportunamente scelto tale da garantire la massima probabilità di ricezione a tutti i dispositivi
limitro. Al termine del re-inoltro l'attività dei nodi slaves torna a consistere solo nella fase di ricezione.
Il consumo legato a questa fase è considerevole. L'invio di un pacchetto implica l'accesso al canale
con l'accensione della trasmittente e la trasmissione dei dati. Il burst ha quindi un costo notevole in
termini energetici e la necessità di eseguire più periodi di trasmissione può portare al rapido consumo
della batteria.
Receiving phase
E' la fase che permette la ricezione dei dati ed è la seconda attività eseguibile dal nodo.
Costituita dal susseguirsi di stati di risveglio, ricezione e dormienza, è l'attività che occupa la mag-
gior parte della vita dei dispositivi di rete.
Gli stati di ricezione interni a questa fase permettono a ogni sensore di rimane in ascolto sul canale
sino all'istante di timeout. In caso di ricezione di dati all'interno di questi stati, il nodo provvede alla
loro memorizzazione ed elaborazione.
Se la ricezione di un pacchetto va a buon ne attraverso la decodica del messaggio, il nodo
interrompe lo stato di ricezione passando in Sleeping state prima dell'arrivo del timeout. Questa
soluzione garantisce il massimo risparmio energetico, in quanto, una volta ricevuto l'intero pacchetto,
risulta inutile ricevere altri dati (poiché come detto in precedenza tutti i frames componenti il burst
presentano lo stesso contenuto).
Se, invece, al termine della ricezione il nodo non dovesse essere in grado di decodicare il pacchetto,
allora eseguirebbe l'eliminazione dei dati, mantenendo attivo lo stato di ricezione sino all'arrivo del
timeout. La necessità di eliminare il pacchetto non decodicabile è data dalla scarsa memoria e capacità
di calcolo dei dispositivi, mentre la presenza di pacchetti non decodicabili, nonostante la caratteristica
d'adabilità del canale, è dovuta al fatto che i nodi non siano tra loro coordinati e quindi un nodo
possa iniziare lo stato di ricezione quando la trasmissione dell'altro è già in corso, causando così un
rilevamento solo parziale dei dati.
Per questa ragione il tempo di ricezione è superiore alle dimensioni di un singolo pacchetto e viene
stimato al ne di coprire l'intervallo temporale necessario all'invio di almeno due frame.
Su questo problema si basa anche il dimensionamento del burst, Fig.3. La caratteristica di rendere
l'insieme Waking up state + burst più lungo rispetto a un singolo blocco implica la possibilità di due
istanti di ricezione da parte dei nodi limitro (nel caso non siano anch'essi in fase di trasmissione). In
particolare il burst occupa le dimensioni di un blocco a cui è sottratto il tempo dello stato di ricezione e
19
sono stati aggiunti due pacchetti di trasmissione. Grazie a questa tecnica se la prima ricezione dovesse
terminare senza permettere la decodica del frame, cosa che può avvenire solo trattandosi del primo
frame del burst, sicuramente la seconda ricadrebbe ancora all'interno dell'intervallo di trasmissione,
consentendo al nodo la ricezione completa dell'ultimo pacchetto.
Figura 3: Ricezione pacchetti del burst
Caso diverso e più problematico è quello dovuto alle trasmissioni simultanee. Esiste, infatti, la
possibilità che a seguito del trasferimento dell'informazione dal nodo master e il conseguente inizio
delle trasmissioni da parte dei nodi slaves, questi decidano di inviare il burst in istanti di tempo vicini,
provocando nei dispositivi limitro l'eetto di collisioni in ricezione.
In questo caso il protocollo è implementato in modo tale che i nodi riceventi entrino subito in
Sleeping state e ci restino sino al risveglio successivo.
E' necessario far notare che i blocchi di nodi diversi, appartenenti agli stessi periodi, non per forza
occuperanno lo stesso intervallo temporale. Ciò è dovuto alla fase d'attivazione iniziale dei nodi che
può provocare il disallineamento dei blocchi. Il dettaglio verrà sottolineato maggiormente nell'analisi
del simulatore Asincrono del Paragrafo 2.3.2.
Con riferimento a quanto appena detto osserviamo la Fig.4. Essa mostra l'esempio di tre nodi salve
collegati in serie, in cui i nodi S1 e S3 iniziano il burst in un intervallo temporale ravvicinato e tale da
indurre l'eetto di collisioni sullo stato di ricezione del nodo S2.
Si può notare, dunque, come S2 a seguito dello stato di Waking up, attivi la ricezione solo per
l'intervallo di tempo necessario al ne di rendersi conto della collisione e rientri poi nello stato di
risparmio energetico.
20
Figura 4: Trasmissione simultanea
La gura soprastante ci permette di sottolineare nuovamente la mancanza di coordinamento tra
i nodi della rete, i quali non hanno percezione ne del contesto nel quale sono immersi, ne della
programmazione temporale dei nodi limitro.
La fase di ricezione, come quella di trasmissione, richiede un grande dispendio energetico. Per
questo risulta indispensabile vericare con accuratezza il numero di blocchi e di periodi al ne di non
incorrere in sprechi.
Riportiamo ora il diagramma di usso rappresentante il protocollo Asincrono nei suoi possibili stati
e attività:
21
Figura 5: Protocollo Asincrono - Diagramma di usso
22
2.2.2 Protocollo Sincrono
Il protocollo Sincrono si basa sulla struttura del protocollo LEACH e prevede un metodo d'accesso al
mezzo trasmissivo coordinato da parte dei nodi, che sfrutta la tecnica TDMA per eseguire la fase di
comunicazione.
Le topologie utilizzabili sono di natura generica, grazie alla possibilità da parte di tutti i dispositivi
di eseguire multi-hop, inoltre, la comunicazione avviene in sequenza gerarchica, dal nodo master ai
nodi slave, in intervalli di tempo deniti, detti slot. Anche i nodi slave sono tra loro distinti in più
livelli, in funzione al numero di hop che li separano dal nodo master.
Il protocollo è strutturato in tre fasi che permettono rispettivamente la scoperta della rete, l'allo-
cazione degli slot di trasmissione e la comunicazione eettiva tra i nodi. Queste fasi, in dipendenza al
nodo che si considera, sono attivate in istanti diversi. Le prime due, infatti, mostrano, tempi d'esecu-
zione maggiori nel caso di nodi slave posti a numerosi hop di distanza dal nodo master, mentre la terza
causa un ritardo nel nodo master, il quale è presente anche tra i nodi slave ma decresce all'aumentare
del numero di hop di distanza.
I problemi riguardanti la stima e la gestione dei tempi d'attesa sono arontati attraverso l'otti-
mizzazione delle trasmissioni con l'ausilio del programma BlockDis(nodi, slot)
11. Per ogni nodo si
provvede, infatti, a calcolare il numero di trasmissioni non coordinate tale da assicurare, con probabi-
lità superiore al 0.995, la corretta ricezione sia dei pacchetti che descrivono la topologia, sia di quelli
che deniscono l'allocazione delle risorse all'interno della trama di comunicazione.
La Fig.6 mostra il funzionamento di un dispositivo che esegue il protocollo.
Figura 6: Fasi protocollo Sincrono
Da questa possiamo distinguere cinque stati dierenti: quello di ricezione (Receiving state), quello
di trasmissione (Transmitting state), quello di latenza (Idle state), quello di dormienza (Sleeping state)
e quello di risveglio (Waking up state). In aggiunta si osserva come lo stato di dormienza si dierenzi
ulteriormente in tre tipologie: Sleeping state, Coordination Sleeping state e Synchronization Sleeping
state.
La combinazione di questi stati da luogo alle fasi, distinguibili in: Discovery phase, con la scoperta
della topologia; Data Initialization phase, con l'allocazione delle risorse; Communication phase, con la
comunicazione utile tra i nodi.
11La descrizione del programma si trova nel paragrafo 2.3.1
23
Osserviamo come la base dei tempi del protocollo sia strutturata in blocchi, il cui numero è funzione
del programma d'ottimizzazione e varia in relazione al nodo e alla fase che si sta considerando.
Ogni blocco, inne, è composto da più slot, le cui dimensioni sono costanti e dipendenti dal pac-
chetto trasmesso mentre la loro molteplicità risulta essere una delle variabili di gestione del protocollo.
Si osservi come il protocollo Sincrono aumenti la propria ecienza all'aumentare del numero di
comunicazioni, in modo tale che il benecio apportato dall'avere le risorse assegnate compensi la spesa
energetica dovuta al riconoscimento della rete e l'inizializzazione delle risorse.
Analisi degli stati
Waking up state
Questo stato è necessario per preparare all'attività le componenti hardware dei dispositivi, permettendo
ad esempio la sincronizzazione dell'oscillatore. Occupa l'intervallo temporale di uno slot e segue a tutti
gli stati di dormienza, inuendo sulla batteria con un consumo limitato.
Sleeping state
Questo stato permette un considerevole risparmio energetico garantito dalla totale inattività del nodo.
Come detto in precedenza si hanno tre stati di sleeping caratterizzati da diverse lunghezze.
Il primo, detto Sleeping state, appartiene alla fase di Data Initialization; serve a occupare il tempo
non altrimenti assegnato di ogni blocco e quindi ha dimensioni costanti per tutta la fase ma dipendenti
dal nodo considerato
12.
Il secondo e il terzo appartengono alla Communication phase. In particolare il secondo stato,
Coordination Sleeping state, mira a riallineare tutti i nodi nello stesso blocco, coordinandoli per la
fase di comunicazione. Lo stato può avere le dimensioni di uno o più blocchi in dipendenza al ritardo
accumulato dai nodi.
Il terzo, Synchronization Sleeping state, invece, prescinde dalla divisione in blocchi ma è un valore
ssato dipendente della frequenza con la quale è necessario far circolare un pacchetto all'interno della
rete al ne di mantenere la sincronizzazione tra i clock dei diversi dispositivi. Tale sincronizzazione
permette di non rieseguire la fase di inizializzazione ma di mantenere l'assegnazione degli slot anche
per le comunicazioni successive. Questo terzo stato ha dimensioni superiori rispetto ai due precedenti
e costituisce uno dei parametri attraverso il quale sarà possibile sviluppare l'analisi dati.
Idle state
Lo stato di latenza corrisponde all'intervallo temporale necessario anché il nodo elabori le infor-
mazioni ricevute. Questo si interpone tra le fasi e ha dimensioni costanti per tutti i nodi, con un
consumo energetico paragonabile a quello dello stato di Waking up, poiché il nodo ha la sola necessità
di processare le informazioni attraverso l'utilizzo della propria CPU.
12Come verrà descritto nella sotto-paragrafo Communication phase appartenente a questo paragrafo, lo stato di Slee-
ping semplice può essere presente anche nella fase di comunicazioni con lo stesso ruolo che presenta nella fase di Data
Initialization. Nella Fig.6 si è preferito riportare il caso in cui quest'eventualità non sia vericata.
24
Receiving state
Questo stato rappresenta il tempo speso dai dispositivi nell'ascolto del canale di comunicazione. Il
suo intervallo d'esecuzione standard copre l'intero slot ma può ridursi nel caso di ricezione, interrom-
pendosi una volta che si è ottenuto un pacchetto. Il consumo previsto è elevato poiché lo stato richiede
l'attivazione della ricetrasmittente e l'ascolto del canale per un tempo prolungato.
Transmitting state
Lo stato di trasmissione prevede l'inoltro di un pacchetto a tutti i dispositivi posti all'interno del raggio
di copertura della trasmittente del nodo. Le dimensioni dello stato sono inferiori rispetto a quelle degli
stati precedenti, mentre la dissipazione d'energia è elevata e risulta paragonabile a quella dello stato
di ricezione.
Analisi delle fasi
Discovery phase
La fase di Discovery è la prima che caratterizza la vita dei nodi. Essa è gestita attraverso l'alternanza
di stati di ricezione e stati di trasmissione e non prevede, in prima analisi, intervalli di dormienza e
risveglio.
Le sua attività consistono nello scambio di informazioni sulla struttura della rete, al ne di deter-
minare quali nodi dovranno eseguire il re-inoltro del pacchetto.
La fase prevede, dunque, la modica della topologia in una struttura ad albero in cui i percorsi
ridondanti vengono omessi. I collegamenti da preservare vengono decisi in maniera causale dai nodi;
difatti, quando un nodo si rende conto di ricevere lo stesso pacchetto da più dispositivi decide quale
collegamento preservare, semplicemente ignorando i pacchetti trasmessigli dagli altri
13.
Ogni nodo (diverso dal nodo master) è, quindi, posto in contatto con un unico dispositivo preposto a
fornirgli l'informazione desiderata e può o meno essere collegato a dispositivi a cui eseguire il re-inoltro.
Questa tecnica di creazione dell'albero di trasmissione implica che a seguito della disattivazione
di un nodo la topologia non possa sfruttare direttamente i percorsi alternativi (quando esistenti) ma
necessiti dell'esecuzione di una nuova fase di Discovery prima di garantire il proseguimento delle co-
municazioni.
L'intera fase è organizzata in blocchi: per ogni blocco, tutti i nodi mantengono lo stato di ricezione e,
se necessario, possono scegliere randomicamente uno slot in cui trasmettere l'informazione di discovery.
L'inizio della fase dipende dal livello a cui è posizionato il nodo ed è avviata dal nodo master.
Dunque, all'aumentare degli hop di distanza da quest'ultimo, i nodi slave iniziano la fase con ritardi
crescenti.
Questa fase subisce lievi variazioni in dipendenza alla categoria del nodo considerato. In particolare
la Fig. 6 riguarda la fase di discovery del nodo master.
13Il problema della creazione dell'albero non è stato approfondito al ne di questa tesi; si può però supporre che ogni
pacchetto contenga un header identicativo del nodo trasmittente e che, in realtà, i dispositivi continuino a ricevere tutti
i pacchetti trasmessi dai nodi limitro ma decidano di portare a termine solo la ricezione dei pacchetti contenenti lo
header scelto, scartando gli altri non appena decodicato il mittente.
25
Con riferimento alle Fig. 7a e 7b mettiamo in evidenza anche l'esecuzione di questa fase da parte
di due nodi slaves posti in congurazioni diverse.
(a) Serie (b) Stella
Figura 7: Discovery phase
Si può notare come in entrambe le gure i nodi slave (S1 e S2) presentino un iniziale periodo di
ricezione continuata, detto Listening, in cui i nodi vanno in ricezione a intervalli regolari, in attesa
di messaggi dal nodo master o dai nodi di livelli superiori. Una volta recepita l'informazione, questi
entrano in uno stato di dormienza, seguito da uno risveglio, sviluppati appositamente per permettere
la coordinazione all'istante d'accesso al nuovo blocco del nodo M (master).
In entrambe le congurazioni a seguito della corretta ricezione del pacchetto d'avvio i nodi proseguo-
no nell'eettiva attività di Discovery della rete, trasmettendo un pacchetto contenente le informazioni
relative alla loro posizione e al loro ruolo rispetto alla topologia.
La Fig. 7a rappresenta una rete di tre nodi in serie. Si può notare come il nodo S1 dopo aver
ottenuto l'informazione dal nodo M entri in fase di dormienza, mentre il nodo S2 mantenga la fase
di ricezione sino all'intervento di un istante di timeout. Tale istante è presente al ne di limitare la
dissipazione di energia a seguito di stati di ricezione troppo lunghi che non prevedono la ricezione
eettiva di pacchetti.
Al termine dell'intervallo di dormienza che segue il timeout, il nodo riprende la fase di listening;
se S2 non avesse ricevuto il pacchetto neanche nel secondo intervallo si sarebbe proseguito alternando
periodi di dormienza e periodi di ricezione sino alla arrivo di questo o all'esaurimento delle batte-
rie di S2. Osserviamo, inoltre, che se la fase di Discovery del nodo S1 termina prima che il nodo
S2 riceva il pacchetto e si attivi, S2 continuerebbe l'attività di listening e non verrebbe mai identi-
cato dagli altri nodi della rete. Per questa ragione risulta molto importante la stima del numero di
blocchi che vanno a formare questa fase, specie nel caso di reti complesse, costituite da numerosi livelli.
26
La Fig. 7b, invece, rappresenta una topologia a stella di tre nodi. In questo caso S1 e S2 ricevono
l'informazione dal nodo M prima che intervenga il timeout.
Si conclude sottolineando due elementi di questa fase:
Il primo è che il consumo risulta essere molto elevato e che la sua lunghezza, stimabile attraverso il
numero di blocchi, è in parte gestita dal programma di ottimizzazione e in parte dipendente dall'istante
d'attivazione di ogni nodo.
Il secondo è che l'attivazione successiva dei nodi provoca uno scoordinamento generale dal punto di
vista del numero dei blocchi; infatti, rispetto al nodo master, i nodi slaves niranno la fase di Discovery
con un ritardo pari al numero di blocchi eseguiti in modalità di ricezione continuata.
Data Initialization phase
La fase di inizializzazione è stata denita allo scopo di garantire l'allocazione di una risorsa a ogni
nodo che presenta necessità di trasferire dati. In secondo luogo questa fase ha anche la nalità di
determinare il ritardo tra i nodi in modo da stabilire il corretto coordinamento per la fase successiva.
Come osservabile in Fig. 6 la Data Initialization phase prevede l'alternanza ssa di quattro stati
occupanti le dimensioni totali di un blocco. Lo stato di dormienza, come già fatto notare nel sotto-
paragrafo Sleeping state, adatta le proprie dimensioni in funzione alle necessità di trasmissione o
ricezione dei nodi.
Le risorse vengono assegnate a partire dal master, il quale mantiene costante lo slot di trasmissione
per tutta la fase. I nodi slave che hanno bisogno di trasmettere eseguono la trasmissione in uno slot
randomico e interno al blocco. Se la termine del blocco il nodo slave ha ricevuto il pacchetto d'ini-
zializzazione dal nodo master (o dal nodo di livello superiore) allora decide di mantenere quello slot
per tutte le comunicazioni successive. Se, invece, il nodo non riceve il pacchetto, allora cambia slot di
trasmissione, supponendo che il proprio pacchetto abbia generato collisione con quello del master (o
dei nodi superiori).
Le immagini in Fig. 8 riproducono la fase di inizializzazione delle risorse attraverso lo studio di
due diverse topologie: la serie composta da tre nodi Fig. 8a e la stella composta da tre nodi Fig. 8b.
Notiamo nuovamente come la Fig. 6 fosse solo espressione dell'attività d'inizializzazione del nodo
master (M) e non rispecchiasse quella dei nodi slaves (S1 e S2).
27
(a) Serie (b) Stella
Figura 8: Data Initialization phase
Con riferimento alla Fig. 8a osserviamo allora come, tra i vari nodi, l'inizio della fase non sia
coordinato ma abbia un ritardo pari a quello accumulato nella fase di Discovery.
Una volta che la fase di Data Initialization ha inizio, i nodi slaves assumono uno stato di ricezione
continuata che viene interrotto solo nel caso questi debbano propagare l'informazione d'inizializzazione.
In questa fase i dispositivi che eseguono trasmissioni sono solo quelli che necessitano l'allocazione
di risorse e che dovranno, quindi, inoltrare i dati nella fase di comunicazione.
Questa è la ragione per cui S2 non esegue trasmissione ma si limita a mantenere attivo lo stato di
ricezione.
Il numero di questi blocchi ha sempre il ne di garantire a tutti i nodi interessati la ricezione, pur
tenendo conto dei ritardi d'avvio.
La Fig. 8b mostra la mancanza di necessità da parte di entrambi i nodi slave di accreditarsi una
risorsa e il mantenimento del ritardo acquisito dalla fase di Discovery in coerenza con la Fig. 7b.
Come per la fase di Discovery, si ha che a causa dei lunghi periodi di ricezione continuata anche
quest'ultima fase risulta essere molto dispendiosa per i dispositivi; inoltre, si induce un ulteriore ritardo
sui nodi slave rispetto al master e ai nodi che eseguono il re-inoltro provocando un'altra dilazione
temporale prima delle comunicazioni eettive.
Communication phase
Quest'ultima fase del protocollo è quella che determina il passaggio del pacchetto d'informazione tra i
nodi. Essa termina all'esaurimento della batteria di un qualsiasi dispositivo di rete, fornendo la stima
di vita della topologia e causando la ripresa dalla fase di Discovery.
La Fig. 6 evidenziava come la Communication phase presenti lunghi periodi di dormienza alternati
da stati di risveglio e trasmissione individuabili con cadenza costante.
28
Osservando ora le gure sottostanti possiamo enfatizzare più nello specico i vari aspetti di questa
fase.
(a) Serie (b) Stella
Figura 9: Communication phase
Notiamo innanzitutto i due diversi stati di dormienza: il primo, Coordination Sleeping state, indi-
rizzato al coordinamento di tutti i nodi, presenta dimensioni dierenti a seconda del ritardo accumulato
dai nodi della rete rispetto al nodo master e permette il risveglio dei dispositivi in maniera coordinata
in corrispondenza agli slot assegnati.
Il secondo, Synchronization Sleeping state, costituisce tutti gli stati di dormienza successivi e ha
dimensioni calibrate sul tempo di de-sincronizzazione dei dispositivi. Difatti, tutte le trasmissioni suc-
cessive hanno il solo lo scopo di mantenere la sincronizzazione tra i nodi e sono necessarie a causa delle
non idealità delle loro componenti hardware.
La Fig. 9a mostra una topologia di tre nodi, disposti in serie, nei primi istanti di sviluppo della
fase.
Nella prima riga è presentata l'attività del nodo master (M); si vede, quindi, lo stato di dormienza
in attesa del coordinamento di tutti i nodi, il risveglio, lo stato di trasmissione e quello di Sleeping
prima del comune intervallo di dormienza per sincronizzazione. La mancanza dello stato di ricezione
è dovuta al fatto che, secondo il protocollo, il nodo M non ha necessità di ricevere dati dalla rete.
L'alternanza delle attività, senza considerare lo stato di dormienza per coordinazione, prosegue poi
sino all'esaurimento della batteria.
Nella seconda riga osserviamo le attività del nodo S1 e la gestione della necessità di ricevere e poi
re-inoltrare il pacchetto.
Osserviamo che, poiché l'intervallo di tempo tra ricezione e trasmissione è conosciuto (denito dalla
fase di Data Initialization), si ha la possibilità di gestirlo attraverso uno stato di dormienza e risveglio
che permetta l'ulteriore ottimizzazione nel consumo della fase.
29
S2, invece, non avendo necessità di re-inoltro presenta solo lo stato di ricezione in corrispondenza
dello slot di trasmissione di S1.
Dalla terza riga vediamo anche che S2 non dispone di un periodo di dormienza per coordinazio-
ne
14,contrariamente ai nodi M e S1, poiché risulta essere il nodo con maggiore ritardo nella rete. A
seguito dello stato di Idle, infatti, si ha un intervallo di Sleeping dovuto all'ottimizzazione della fase e
non alla necessità di coordinazione del nodo.
Una situazione simile viene evidenziata nella Fig. 9b dove i nodi slaves non necessitano né di
un periodo di coordinamento, essendo loro i nodi con maggiore ritardo nella rete, né di uno stato di
trasmissione, non avendo necessità di re-inoltrare i dati ricevuti. Si ottiene quindi che questa rappre-
sentazione, descrivente una topologia a stella a tre nodi, se confrontata con quella in Fig. 9a, risulti
meno dispendiosa in termini energetici e permetta un leggero anticipo nell'inizio delle comunicazioni.
Nel complesso quest'ultima fase presenta un consumo energetico irrisorio se confrontato con quelle
precedenti; inoltre costituisce la fase più lunga del ciclo di vita dei dispositivi e, protraendosi sino al
loro spegnimento, garantisce la trasmissione coordinata dei pacchetti emessi dal nodo master.
Anche per questo protocollo riportiamo il diagramma di usso che cerca di sintetizzarne lo sviluppo
delle fasi:
14S2 potrebbe disporre, in realtà, di un intervallo di dormienza per coordinazione in dipendenza all'istante d'attivazione
degli altri nodi. Difatti, se il periodo di coordinazione fosse più lungo del necessario allora S2 dovrebbe assumere questo
stato per l'intervallo di tempo richiesto.
Per semplicità, nell'esposizione è stato assunto che essendo il nodo con maggiore ritardo della rete, questo non generi
ulteriore ritardo.
30
Figura 10: Protocollo Sincrono - Diagramma di usso
31
2.3 Implementazione software
Descriviamo ora la parte più pratica del lavoro, quella cioè che consiste nell'implementazione dei
protocolli sotto forma di simulatori e che ha permesso l'estrazione dei risultati relativi all'ecienza di
quest'ultimi.
2.3.1 Programma d'ottimizzazione BlockDis(nodi, slot)15
BlockDis(nodi, slot) è il programma realizzato appositamente per ottimizzare le prestazioni dei due
protocolli presentati nei paragra precedenti.
L'obiettivo di questo programma è fornire il numero di trasmissioni che ogni nodo appartenente a
un layer deve compiere al ne di ottenere, con una data probabilità, la corretta ricezione del pacchetto.
Layer Insieme di tutti i nodi connessi e aventi distanza massima di un hop l'uno dall'altro.
La stima viene eseguita supponendo che tutti i nodi appartenenti al layer abbiano la necessità di co-
municare e che non siano coordinati tra loro. Inoltre, dev'essere denito a priori il numero di spazi
(slot) in cui ogni nodo ha la possibilità di trasmettere.
Il programma prende in input due valori: il numero di nodi costituenti il layer e il numero di slot
disponibili per la comunicazione.
All'avvio i nodi scelgono in maniera casuale uno slot di trasmissione tra quelli disponibili e per i
restanti intervalli mantengono lo stato di ricezione.
Il software memorizza in una tabella i pacchetti ricevuti correttamente, ossia quelli che non hanno
subito collisioni, associandoli ai nodi che li hanno trasmessi.
Se alla prima iterazione non si vericano collisioni, quindi tutti i pacchetti vengono inviati in slot
diversi, il programma termina fornendo la stima del numero di iterazioni eseguite (una).
Se, invece, alcuni pacchetti (o tutti) subiscono collisioni, il programma riempie solo parzialmente
la tabella e prosegue incrementando di un'unità il contatore di iterazioni. A questo punto, ogni nodo
sceglie nuovamente uno slot e ritrasmette lo stesso pacchetto inviato in precedenza.
La scelta dello slot e la trasmissione del pacchetto viene ripetuta sino a quando tutti i pacchetti
sono ricevuti correttamente almeno una volta.
A questo punto il programma termina e fornisce in output il numero di iterazioni che è stato ne-
cessario eseguire per riempire la tabella.
Poiché non è previsto l'utilizzo di acknowledgements anche se la comunicazione di un nodo dovesse
avere successo, questo continuerebbe a trasmettere per tutte le iterazioni successive sino al termine del
programma, occupando uno slot di trasmissione ed eventualmente causando collisioni.
Per avere maggiore sicurezza sulla veridicità dei risultati, per ogni stima viene richiesta al pro-
gramma la ricorsione del processo diecimila volte. A ogni esecuzione di BlockDis(nodi, slot) sono
15Il codice MATLAB relativo al programma BlockDis(nodi, slot) e i programmi a contorno utilizzati per ottenere le
stime di output sono riportati in Appendice B
32
ottenute, quindi, diecimila risposte indicanti il numero di iterazioni eseguite per portare a termine la
comunicazione all'interno di un dato layer e con un dato numero di slot.
Da questi risultati è possibile estrarre informazioni riguardanti i valori più ricorrenti nelle iterazioni
e la distribuzione della probabilità di ricezione da parte dei nodi del layer.
Esempio di funzionamento
La Fig.11 cerca di chiarire il funzionamento del programma nel caso esemplicativo di cinque nodi e
cinque slot.
Figura 11: BlockDis(5, 5)
La topologia posta sul lato sinistro vuole identicare il layer, mentre l'arbitraria assegnazione dei
colori ha il solo scopo di permettere la distinzione dei pacchetti negli slot.
Ogni linea orizzontale rappresenta una diversa ricorsione del programma e produce un valore di
output. La diversa lunghezza delle ricorsioni è data dal numero di iterazioni che è stato necessario
eettuare anché tutti i pacchetti venissero inviati senza incorrere in collisioni.
Analizzando la prima riga dell'immagine, Recursion 1, si nota come per ogni iterazione tutti i
nodi eseguano la trasmissione. In particolare vediamo che a seguito della prima iterazione l'unico
pacchetto a essere stato trasmesso con successo è quello inviato dal nodo N1, mentre tutti gli altri
hanno colliso essendo stati inviati nello stesso slot di trasmissione di un altro nodo. Nella seconda
iterazione nessun pacchetto è stato trasmesso con successo e si sottolinea l'eetto della mancanza di
acknowledgement che ha portato, nel terzo slot, alla collisione tra il pacchetto del nodo N1 e quello di
N2, nonostante il pacchetto trasmesso da N1 sia ridondante. Nella terza iterazione i pacchetti di N1,
N2 e N5 sono trasmessi senza collisioni. Inne, a seguito della quarta iterazione si ottengono anche i
pacchetti trasmessi da N3 e N4 che permettono la conclusione della prima ricorsione col risultato di
quattro iterazioni.
La Fig.12 mostra, in via graca, gli output ottenuti dal programma. Per completezza, oltre a quelli
del programma BlockDis(5, 5) (linee rosse), sono stati rappresentati negli stessi graci tre ulteriori
output derivanti dall'incremento o il decremento del numero di slot. In questo modo si cerca di
evidenziare la dipendenza del numero di iterazioni dalla quantità di slot disponibili.
33
In particolare sono stati aggiunti gli output ottenuti da BlockDis(5, 3) (linea azzurra), BlockDis(5,
10) (linea gialla) e BlockDis(5, 30) (linea viola).
(a) Distribuzione delle iterazioni (b) Densità di probabilità cumulata
Figura 12: BlockDis(nodi, slot) - output
La Fig.12a rappresenta la distribuzione dei risultati delle ricorsioni, dove in ordinata vi è il numero
di volte in cui il programma ha terminato la ricorsione avendo come output il valore espresso in ascissa.
Normalizzando l'asse delle ordinate si ottiene la classica distribuzione di probabilità.
Facciamo notare che il valore delle ordinate parte da zero mentre quello delle ascisse inizia da uno
poiché al valore di zero iterazioni la rappresentazione perde di senso.
Le quattro curve mostrano come la distribuzione vari in funzione al numero di slot, aumentando il
proprio valore medio al diminuire di quest'ultimo.
La Fig.12b mostra, invece, la densità di probabilità cumulata. In ordinata è posta la probabilità
di corretta ricezione di tutti i pacchetti da parte dei nodi del layer, mentre in ascissa vi è ancora il
numero di iterazioni d'invio (iniziante da uno).
Dai graci proposti, quando il ne è quello di minimizzare il numero di iterazioni, appare evidente
la maggior ecienza del layer che dispone di un numero superiore di slot; ma se si considera invece il
problema di minimizzare il numero di slot utilizzati, le considerazioni cambiano.
Riportiamo nella tabella sottostante i risultati estratti dagli output precedenti, richiedendo una
probabilità di corretta ricezione maggiore o uguale allo 0.995:
Slot per layer Iterazioni necessarie Slot totali
3 34 102
5 14 70
10 7 70
30 4 120
Tabella 2: Totale slot per corretta ricezione
Vediamo, quindi, che seppur il numero di iterazioni si abbassa al crescere degli slot per layer, il
34
numero di slot totali presenta il minimo
16 all'interno dell'intervallo compreso tra tre e trenta slot per
layer.
Questa precisazione risulta di notevole importanza per l'ottimizzazione dei protocolli dove il numero
totale di slot inuisce sulla longevità della rete.
Utilizzo nei protocolli
Il programma d'ottimizzazione viene utilizzato in entrambi i protocolli presentati nei paragra pre-
cedenti allo scopo di massimizzare la longevità delle reti e di assicurare una probabilità di corretta
ricezione dei pacchetti superiore allo 0.995.
Nel caso del protocollo Asincrono il programma d'ottimizzazione permette di ottenere la stima
riguardante il numero di ripetizioni dei periodi contenenti il burst di trasmissione.
Tale stima dovrebbe essere fatta singolarmente per ogni nodo ma poiché in questo protocollo la
topologia non è nota si deve considerare ogni layer come composto da tutti i nodi costituenti la rete
e in funzione di questo numero denire la stima dei periodi di ritrasmissione. In sostanza è necessa-
rio assumere il caso in cui tutti i nodi siano posti a distanza di un hop e abbiano necessità di comunicare.
Nel caso del protocollo Sincrono, invece, il programma viene applicato in due frangenti distinti:
Il primo riguarda la Discovery phase, dove i nodi hanno necessità di comunicare tra loro per deter-
minare la topologia, quindi, come nel caso del protocollo Asincrono, il programma dovrà considerare
ogni layer come composto da tutti i nodi di rete, con l'unica dierenza data dal fatto che ora si parla
dell'iterazione di blocchi di trasmissione e non più di periodi.
Il secondo frangente riguarda la fase di Data Initialization, nella quale i nodi conoscono la topologia
e attendono l'assegnazione dello slot di trasmissione. In questa fase i layer fanno specico riferimento
al singolo nodo e sono di dimensioni minori o al più uguali a quelli stimati per la fase di Discovery
17.
2.3.2 Simulatori
Vediamo ora l'implementazione software dei protocolli descritti nei Paragra 2.2.1 e 2.2.2.
La descrizione dei simulatori verrà svolta attraverso l'analisi di un esempio al ne di poter fornire
esplicitamente i dati e poterli vericare attraverso la visione delle immagini.
Tutte le immagini saranno strutturate in righe, ognuna delle quali rappresenterà le attività di un
nodo allo scorrere del tempo.
Assegniamo, dunque, le caratteristiche comuni all'esecuzione dei protocolli:
Consideriamo la rete di Fig.13 composta da quattro nodi, dove il nodo M rappresenta il master, i
nodi S1, S2 e S3 gli slaves e le frecce i range di trasmissione e ricezione.
16La funzione ha forma parabolica e poiché le ricorsioni eseguite dal programma sono in numero nito non è possibile
denire con esattezza il valore per cui la curva presenta il minimo assoluto ma è solo possibile stimarne un ragionevole
intorno.
17Le motivazioni che portano alle diverse dimensioni dei layer tra la fase di Discovery e quella di Data Initialization
vengono approfondita all'interno del Paragrafo 2.3.2, nel sotto-paragrafo Protocollo Sincrono
35
Figura 13: Rete a quattro nodi
Supponiamo poi che il numero di blocchi costituenti un periodo del protocollo Asincrono sia uguale
al numero di slot costituenti un blocco del protocollo Sincrono e stimiamo questo valore in sei
18 blocchi
per periodo e quindi sei slot per blocco.
Analizziamo ora individualmente lo sviluppo dei due simulatori.
Simulatore Asincrono
Le immagini della Fig.14 mostrano in sequenza tutti i diversi stadi del simulatore
19.
(a) Fase iniziale e primo periodo (b) secondo periodo
(c) Quarto periodo (d) Quinto periodo
Figura 14: Simulatore Asincrono
18La decisione presa sul numero di blocchi per periodo e il fatto di porli uguale al numero di slot per blocco è del tutto
arbitraria e solo a titolo esemplicativo.
19Le immagini sono state prese a seguito di iterazioni successive del programma, poiché esso permette il calcolo e
la visualizzazione di un periodo alla volta. Ciò spiega i cambiamenti nella de-coordinazione dei nodi da un'immagine
all'altra.
36
La prima immagine, Fig.14a, mostra l'intervallo di risveglio e il primo periodo di vita dei nodi.
Il risveglio è proprio ciò che determina lo scoordinamento dei dispositivi di rete ed è individuabile
nell'iniziale zona verde.
Successivamente ha inizio il primo periodo in cui il nodo Master trasmette il burst di dati. Essendo
consapevole del proprio ruolo e di essere l'unico in possesso dell'informazione, questo dispositivo non
eseguirà ulteriori trasmissioni, poiché il canale è supposto essere senza perdite e non vi è alcun rischio
di collisioni.
Ponendo attenzione alla gura si può vedere che solo i nodi S1 e S2 ricevono il pacchetto interrom-
pendo anticipatamente il periodo di ricezione, mentre il nodo S3 prosegue nell'alternanza dei suoi stati
poiché posto oltre al raggio di trasmissione del nodo M.
La Fig.14b mostra il secondo periodo di comunicazione della rete.
In questa fase i nodi S1 e S2 hanno ricevuto il pacchetto e devono occuparsi di ritrasmetterlo ai
dispositivi sottostanti. Ricordiamo che i nodi non sono a conoscenza della topologia ma conoscono solo
il numero totale dei suoi componenti. Si ha quindi che sia S1 che S2 provvederanno a ritrasmettere
i dati sotto forma di burst per un numero di periodi dato da BlockDis(2, 6), ossia per tre periodi
consecutivi.
I valori in input a BlockDis(nodi, slot) sono: 2 per il numero di nodi e 6 per il numero di blocchi.
Mentre il valore 6 è ovvio poiché fornito come dato iniziale, il valore 2 viene scelto considerando il
numero di nodi concorrenti alla trasmissione e che potrebbero causare collisioni.
Poiché la topologia è composta da quattro nodi di cui un master (che sicuramente non genererà
collisioni), considerando di avere almeno uno slave a cui dover trasmettere, resta la possibilità di avere
al più due nodi invianti in concomitanza; da cui il valore 2 in input per il numero di nodi costituenti
il layer di trasmissione.
I nodi S1 e S2 ripeteranno il burst per tre volte, ma facciamo notare che per S1 la trasmissione è solo
uno spreco d'energia, dal momento che nessun altro nodo slave può riceverla. Per ciò che riguarda S2,
invece, sarebbe bastata una sola trasmissione del burst al ne di passare con successo l'informazione
al nodo S3.
Osservando, inne, le righe M e S3 si vede come il Master riceva sia il pacchetto di S1 che quello di
S2, anticipando così lo stato di dormienza ma non ricevendo informazioni utili, mentre S3 riceva solo
il pacchetto da parte del nodo S2.
La terza immagine, Fig.14c, rappresenta l'esecuzione del quarto periodo (similmente si è avuto per
il terzo). In questo frangente i nodi S1 e S2 si trovano alla terza e ultima iterazione del burst, mentre
il nodo S3 sta eseguendo la seconda.
Di quest'immagine sottolineiamo la mancata ricezione, da parte del nodo S2, del pacchetto tra-
smesso da S3. Quest'eventualità, dovuta al dimensionamento del burst, non è stata trattata nella
presentazione del protocollo Asincrono poiché risulta ininuente ai ni della trasmissione del pacchet-
to nella rete, infatti, il nodo S2 possiede già le informazioni trasmesse da S3 e la mancata ricezione
non apporta modiche nel suo stato.
37
Concludiamo la descrizione del simulatore Asincrono con la Fig.14d che riproduce l'ultimo periodo
di trasmissione del nodo S3. A seguito di questo periodo tutti i nodi proseguiranno alternando stati
di dormienza a stati di ricezione, in attesa che il master invii un altro burst di pacchetti da inoltrare
a tutta la rete.
Evidenziamo come il re-inoltro eseguito da S3 abbia tenuto conto delle stesse considerazioni fatte
per S1 e S2, infatti, S3 non poteva essere a conoscenza di non avere necessità di trasmettere il pacchetto
ma ha dovuto per di più considerare l'ottimizzazione e rieseguire il burst per tre periodi di la.
Simulatore Sincrono
Vediamo adesso lo sviluppo delle comunicazioni attraverso l'implementazione del protocollo Sincrono.
Ricordiamo che la topologia di riferimento è quella in Fig.13 e che ogni blocco è composto da sei slot
d'attività.
(a) Discovery phase (b) Data initialization phase
(c) Communication phase
Figura 15: Simulatore Sincrono
Iniziamo l'analisi dalla Fig.15a, ragurante la fase di Discovery, e calcoliamo il numero di blocchi
necessari alla trasmissione di ogni nodo.
In relazione al nodo master si devono tenere in considerazione due aspetti:
Il primo riguarda il tempo d'attivazione dei nodi slave posti a un hop di distanza (S1 e S2). Difatti,
i nodi si svegliano presentando ritardi tra loro, quindi può accadere che il primo pacchetto trasmesso
dal nodo master non sia suciente a risvegliare tutti i membri del layer. Per questa ragione si devono
riservare almeno due blocchi per l'attivazione.
38
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless
Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless

Mais conteúdo relacionado

Mais procurados

24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
maaske
 
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
maik_o
 
Il mio libro - My book (intro)
Il mio libro - My book (intro)Il mio libro - My book (intro)
Il mio libro - My book (intro)
pls3d
 
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia WebJoseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Cyclope86
 
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
Gabriele Filosofi
 

Mais procurados (20)

Il Linux OpenSound System
Il Linux OpenSound SystemIl Linux OpenSound System
Il Linux OpenSound System
 
domenicoCaputiTriennale
domenicoCaputiTriennaledomenicoCaputiTriennale
domenicoCaputiTriennale
 
Tesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGPTesi Triennale - X509 e PGP
Tesi Triennale - X509 e PGP
 
Monitoraggio di rete con nagios
Monitoraggio di rete con nagiosMonitoraggio di rete con nagios
Monitoraggio di rete con nagios
 
7335 7345 sm
7335 7345 sm7335 7345 sm
7335 7345 sm
 
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
24546913 progettazione-e-implementazione-del-sistema-di-controllo-per-un-pend...
 
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto...
 
MARKETING ED ECOMMERCE NELL’EDITORIA: IL CASO TRADING LIBRARY
MARKETING ED ECOMMERCE NELL’EDITORIA: IL CASO TRADING LIBRARYMARKETING ED ECOMMERCE NELL’EDITORIA: IL CASO TRADING LIBRARY
MARKETING ED ECOMMERCE NELL’EDITORIA: IL CASO TRADING LIBRARY
 
Publish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based RoutingPublish/Subscribe EDI with Content-Based Routing
Publish/Subscribe EDI with Content-Based Routing
 
a4_centrata
a4_centrataa4_centrata
a4_centrata
 
Il mio libro - My book (intro)
Il mio libro - My book (intro)Il mio libro - My book (intro)
Il mio libro - My book (intro)
 
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia WebJoseki : un server per interrogare risorse RDF attraverso un interfaccia Web
Joseki : un server per interrogare risorse RDF attraverso un interfaccia Web
 
Progettazione di universal active filters e realizzazione di un software per ...
Progettazione di universal active filters e realizzazione di un software per ...Progettazione di universal active filters e realizzazione di un software per ...
Progettazione di universal active filters e realizzazione di un software per ...
 
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
Linee guida nazionali per la valorizzazione del patrimonio informativo pubbli...
 
Tesi peiretti
Tesi peirettiTesi peiretti
Tesi peiretti
 
Openfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistemsOpenfisca Managing Tool: a tool to manage fiscal sistems
Openfisca Managing Tool: a tool to manage fiscal sistems
 
Abstract Domenico Brigante
Abstract   Domenico BriganteAbstract   Domenico Brigante
Abstract Domenico Brigante
 
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
GFilosofi_brain-mind-and-behavior_a-neuroscientific-approach_2007
 
Pattern Recognition Lecture Notes
Pattern Recognition Lecture NotesPattern Recognition Lecture Notes
Pattern Recognition Lecture Notes
 
I promessi sposi 3.0 Mobile User Experience & Usability nel settore dei beni...
I promessi sposi 3.0  Mobile User Experience & Usability nel settore dei beni...I promessi sposi 3.0  Mobile User Experience & Usability nel settore dei beni...
I promessi sposi 3.0 Mobile User Experience & Usability nel settore dei beni...
 

Semelhante a Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless

Il tutorial di Python
Il tutorial di PythonIl tutorial di Python
Il tutorial di Python
AmmLibera AL
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisition
AmmLibera AL
 
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
GabrieleGandossi
 

Semelhante a Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless (20)

Il tutorial di Python
Il tutorial di PythonIl tutorial di Python
Il tutorial di Python
 
Caratterizzazione di un rivelatore a piatti resistivi (RPC)
Caratterizzazione di un rivelatore a piatti resistivi (RPC)Caratterizzazione di un rivelatore a piatti resistivi (RPC)
Caratterizzazione di un rivelatore a piatti resistivi (RPC)
 
Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques Anomaly detection in network traffic flows with big data analysis techniques
Anomaly detection in network traffic flows with big data analysis techniques
 
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
Sviluppo di un sistema per il monitoraggio ambientale basato su reti di senso...
 
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientaleInterfaccia utente basata su eye-tracking per sistemi di controllo ambientale
Interfaccia utente basata su eye-tracking per sistemi di controllo ambientale
 
Implementazione di un sistema di misura di tipo quantitativo per sensori a na...
Implementazione di un sistema di misura di tipo quantitativo per sensori a na...Implementazione di un sistema di misura di tipo quantitativo per sensori a na...
Implementazione di un sistema di misura di tipo quantitativo per sensori a na...
 
Sat howto
Sat howtoSat howto
Sat howto
 
Andrea_Gangemi_tesi
Andrea_Gangemi_tesiAndrea_Gangemi_tesi
Andrea_Gangemi_tesi
 
Sistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisitionSistemi SCADA - Supervisory control and data acquisition
Sistemi SCADA - Supervisory control and data acquisition
 
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
Telecontrollo di un sistema cartesiano a 2 g.d.l. mediante interfaccia aptica...
 
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
Reti neurali di convoluzione per la visione artificiale - Tesi di Laurea Magi...
 
Modellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDAModellazione della dinamica di un liquido bifase mediante GPU CUDA
Modellazione della dinamica di un liquido bifase mediante GPU CUDA
 
Tesiandroid
TesiandroidTesiandroid
Tesiandroid
 
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilitàTesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
Tesi di Laurea sulla Sicurezza delle Reti Informatiche: Le vulnerabilità
 
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
Public Light Manager - Una GUI per la gestione remota di un impianto di illum...
 
Risorse infrastrutturali area vasta di Torremaggiore
Risorse infrastrutturali area vasta di TorremaggioreRisorse infrastrutturali area vasta di Torremaggiore
Risorse infrastrutturali area vasta di Torremaggiore
 
Tesi Nicola Pretto
Tesi Nicola PrettoTesi Nicola Pretto
Tesi Nicola Pretto
 
Tecniche per la rilevazione e correzione di errori nell'elaborazione automati...
Tecniche per la rilevazione e correzione di errori nell'elaborazione automati...Tecniche per la rilevazione e correzione di errori nell'elaborazione automati...
Tecniche per la rilevazione e correzione di errori nell'elaborazione automati...
 
Progetto, realizzazione e caratterizzazione dell'elettronica di acquisizione ...
Progetto, realizzazione e caratterizzazione dell'elettronica di acquisizione ...Progetto, realizzazione e caratterizzazione dell'elettronica di acquisizione ...
Progetto, realizzazione e caratterizzazione dell'elettronica di acquisizione ...
 
2080-um002_-it-e.pdf
2080-um002_-it-e.pdf2080-um002_-it-e.pdf
2080-um002_-it-e.pdf
 

Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless

  • 1. Università degli Studi di Trieste Dipartimento di Ingegneria Elettronica e Informatica Corso di Studi in Ingegneria Elettronica Tesi di Laurea Triennale Implementazione di protocolli e simulatori MATLAB per lo sviluppo del livello MAC di reti di sensori wireless Laureando: Michael Mozzon Relatore: Prof. Massimiliano Comisso Tutore Aziendale: Dott. Fabio Versolatto ANNO ACCADEMICO 2016-2017
  • 2.
  • 3.
  • 4.
  • 5. Indice Introduzione V 1 Riferimenti teorici 1 1.1 Wireless Sensors Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 Caratteristiche tecniche e limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Principali applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Accesso al mezzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Tecniche di accesso al mezzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Speciche aziendali e analisi degli standard . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.1 Speciche aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2 Panoramica dei protocolli di accesso al mezzo . . . . . . . . . . . . . . . . . . . . . 8 1.4 Inconsistenza dei protocolli esistenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4.1 Analisi conclusiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Protocolli e ambienti di sviluppo 15 2.1 Elaborazione del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Presentazione dei protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1 Protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.2 Protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 Implementazione software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3.1 Programma d'ottimizzazione BlockDis(nodi, slot) . . . . . . . . . . . . . . . . . . . 32 2.3.2 Simulatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3 Raccolta e analisi dati 41 3.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.1 Tempo d'esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.3 Nodi, blocchi e slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.1.4 Dimensionamento e consumo degli stati . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2 Caratteristiche speciche e consumi teorici . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2.1 Protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2.2 Protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.3 Tabella dei consumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Raccolta ed elaborazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1 Tabelle protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.2 Tabelle protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4 Confronto e conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.1 Confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 I
  • 6. Appendice A 81 Appendice B 85 Riferimenti bibliograci 91 Elenco delle tabelle 1 Raronto dei protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Totale slot per corretta ricezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3 Congurazioni di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4 Dimensionamento e consumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5 Dimensionamento dei periodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Tempi di ricezione continuata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7 Consumi delle fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8 Protocollo Asincrono, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9 Protocollo Asincrono, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 10 Protocollo Asincrono - Caratteristiche delle reti . . . . . . . . . . . . . . . . . . . . . . 57 11 Tempi e consumi del transitorio, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 12 Tempi e consumi del transitorio, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 13 Protocollo Sincrono, 5 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 14 Protocollo Sincrono, 10 nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 15 Protocollo Sincrono - Caratteristiche delle reti . . . . . . . . . . . . . . . . . . . . . . . . 68 16 Densità di pacchetti trasmessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 17 Tempi d'esecuzione e tempi di vita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 18 Tempi di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 19 Consumi di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 20 Tempi di vita dei nodi master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Elenco delle gure 1 Fasi protocollo Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Compensazione del burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 Ricezione pacchetti del burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4 Trasmissione simultanea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5 Protocollo Asincrono - Diagramma di usso . . . . . . . . . . . . . . . . . . . . . . . . . 22 6 Fasi protocollo Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7 Discovery phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8 Data Initialization phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9 Communication phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10 Protocollo Sincrono - Diagramma di usso . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11 BlockDis(5, 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 II
  • 7. 12 BlockDis(nodi, slot) - output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13 Rete a quattro nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 14 Simulatore Asincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15 Simulatore Sincrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16 Vita per esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 17 Tempo di trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 18 Consumo in trasmissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 III
  • 8.
  • 9. Introduzione Il settore delle telecomunicazioni ha assistito, negli ultimi cinquant'anni, a una notevole crescita in concomitanza al progredire e al diondersi dei servizi internet nel mondo, diventando una disciplina di studio e di ricerca fondamentale ai ni dell'evoluzione delle società odierne. La sua rapida espansione ha portato alla necessità di standard che permettessero di denire le linee guida comuni nello sviluppo delle tecnologie a esso correlate. Nel 1979 si giunse così alla pubblicazione del Modello ISO/OSI, il quale formalizzò l'implementazio- ne delle reti di telecomunicazione attraverso la divisione in sette livelli indipendenti [1]. Ciò produsse una considerevole facilitazione nella formulazione dei protocolli, i quali divennero specici rispetto al livello d'appartenenza e autonomi in relazione a quelli adiacenti, generando la possibilità di sviluppare studi di ottimo per singoli livelli e comporne poi i risultati con quelli ottenuti dai livelli limitro. La continua necessità di informazioni sempre più accurate e precise nei più svariati ambiti sociali, ha prodotto negli ultimi anni lo sviluppo di una tecnologia interna al settore delle telecomunicazioni, quello delle reti di sensori wireless (Wireless Sensor Networks - WSNs). Caratterizzate da dispositivi di piccole dimensioni e ridotta capacità di calcolo, queste reti, grazie alle loro interconnessioni, permettono il monitoraggio di intere aree con costi molto contenuti. L'in- teresse nel loro sviluppo è dato in aggiunta, dalle grosse moli di dati ricavabili, in relazione al basso consumo energetico e alle scarse necessità manutentive. Data la numerosità e la diversità di impieghi, al ne di ottenere in ogni settore la miglior risoluzione possibile, si richiede a questa tecnologia una forte essibilità. Sono riscontrabili quindi molteplici protocolli sviluppati ad-hoc per ognuno dei sette livelli dello standard, in funzione alle caratteristiche espresse per ottimizzare la singola attività. V
  • 10. Obiettivo aziendale Il presente lavoro di tesi è parte dello sviluppo di un progetto dell'azienda Innova S.p.a. di Trieste. Tale progetto prevede la volontà di eseguire il rilevamento di pacchetti audio in streaming, utiliz- zando dispositivi collocati a corta distanza tra loro, in un ambiente potenzialmente rumoroso. L'idea di utilizzare una WSN viene suggerita dalle ulteriori speciche. Si richiede, infatti, che i nodi presentino dimensioni ridotte e che una volta collocati assumano posizioni stazionarie non più raggiungibili. E' inoltre richiesta l'assenza di connessione via cavo, sia per l'alimentazione che per le comunicazioni. In questo scenario, dunque, sono state denite alcune delle caratteristiche imprescindibili allo sviluppo dei protocolli di rete, le quali consistono nel: a) minimizzare i consumi b) assicurare cammini multipli c) permettere il multi-hop d) garantire un alto throughput Obiettivo di tesi Analizzato il progetto nella sua interezza, si è riscontrata la necessità di strutturare dei nuovi protocolli relativi al livello due dello standard ISO/OSI. Si è quindi provveduto a una semplicazione del lavoro, andando a realizzare due protocolli che fungessero da base di studio per il problema reale. Questi, che saranno analizzati in dettaglio nel Capitolo 2, non trattano, quindi, il passaggio di pacchetti per streaming audio, ma trattano bensì l'inoltro di un singolo pacchetto a tutti i dispositivi connessi alla rete. Più nel dettaglio si è supposta la necessità di trasmettere a tutti i nodi un pacchetto in possesso del nodo master. Tale obiettivo è stato raggiunto attraverso lo sviluppo di programmi in linguaggio MATLAB che simulassero i due protocolli mostrando le diverse strategie adottate per il trasferimento del dato. L'obiettivo formale di questo lavoro di tesi consiste, dunque, nella presentazione dei due protocolli fungenti da base per il progetto aziendale e nel raronto delle loro caratteristiche mediante i dati estratti dalle implementazioni software, con particolare attenzione al massimo tempo di vita delle reti. Nei capitoli successivi verrà tenuto conto oltre che dell'obiettivo di tesi, anche dell'obiettivo azien- dale. Si procederà, dunque, all'analisi di svariati protocolli esistenti in letteratura e alla verica della loro adottabilità, in relazione a quello che concerne il progetto reale. VI
  • 11. Capitolo 1 Riferimenti teorici In questo capitolo verrà fornita un'introduzione alle reti di sensori wireless e al livello d'accesso al mezzo trasmissivo. Si provvederà inoltre a descrivere alcuni dei più noti protocolli presenti in letteratura relativi a quest'ultimo e a esaminarli sulla base delle prerogative aziendali. 1.1 Wireless Sensor Networks Una rete di sensori wireless (Wireless Sensor Network - WSN) è descrivibile come una composizione di dispositivi di piccole dimensioni, chiamati nodi, generalmente costituiti da una ridotta capacità di calcolo. Ogni nodo dispone di un elaboratore interno, un rilevatore (di natura diversa in dipendenza dalle necessità d'utilizzo), una ricetrasmittente (tale da permettere scambi di informazioni a corto- medio raggio) e una batteria [2]. Pur trattandosi di una tecnologia ormai d'uso comune in ambienti industriali e di ricerca, i problemi a essa correlati sono ancora fonte di ampio dibattito e studio. La principale ragione che determina alcune dicoltà nel denire protocolli standard per WSNs è costituita dalla loro versatilità. La loro implementazione, infatti, mostra una relativa facilità d'utilizzo e progettazione oltre che un misurato costo di produzione e manutenzione; tali caratteristiche hanno portato le reti di sensori a essere strumenti dinamici, adottabili nei più svariati settori lavorativi e oramai necessari in ambienti come automotive, il monitoraggio ambientale, la salvaguardia energetica e la prognosi biomedicale. Per queste ragioni è stato necessario stilare uno standard non restrittivo, che lasciasse ampio mar- gine d'elaborazione, permettendo modiche e ottimizzazioni in coerenza con le molteplici possibilità d'utilizzo dei dispositivi. 1.1.1 Caratteristiche tecniche e limitazioni Ogni rete di sensori è costituita da un insieme di nodi, il cui scopo è eseguire rilevazioni mirate dell'ambiente nel quale si trovano e trasferirle, sotto forma di dati, a un elaboratore esterno. Convenzioni formali Al ne di permettere una comunicazione controllata e coordinata dei nodi, sono state adottate alcu- ne convenzioni che permettano di catalogare quest'ultimi in sequenze gerarchiche, in funzione della posizione assunta all'interno della rete. A tale scopo si denisce: Master: il nodo incaricato dell'assegnazione dei compiti e della sincronizzazione temporale della rete. Slave: il nodo assoggettato al master. 1
  • 12. Access Point (AP): elaboratore con maggiore capacità di calcolo che ha il compito di collegare i dispositivi operanti attraverso Wi-Fi alla rete cablata. Sink: il nodo al quale convergono tutti i pacchetti circolanti nella rete. Svolge anche il ruolo di elaboratore primario, collezionando e ordinando i pacchetti al ne di inoltrarli al AP [2]. Caratteristiche tecnico-strutturali Anché si possa parlare di WSN, è necessario porre particolare attenzione ad alcune proprietà. Le principali caratteristiche tecniche che contraddistinguono questa tipologia di reti sono [2, 3]: • Ecienza energetica: la rete deve essere autosuciente e sopravvivere per il periodo di tempo desiderato, col solo ausilio delle batterie o di dispositivi atti alla produzione di energia (es. pannelli solari). • Scalabilità: dev'essere possibile modicare la rete incrementando o decrementando il numero di nodi a disposizione. • Organizzazione autonoma: i nodi devono essere in grado di denire una gerarchia interna condi- visa, che ottimizzi le comunicazioni. • Robustezza: la necessità di garantire il mantenimento dell'operatività, a seguito di eventuali perdite di dispositivi o interferenze esterne. • Throughput: velocità nella trasmissione dei pacchetti, giunti con successo al AP. Le caratteristiche strutturali invece consistono in [2]: • Bassa complessità delle topologie • Compatibilità con gli standard • Minimizzazione delle dimensioni dei nodi • Basso costo di fabbricazione Con particolare riferimento alle caratteristiche di ecienza energetica e robustezza, si fa notare che per svariate applicazioni, le reti di sensori, una volta posizionate nell'ambiente di lavoro non saranno più raggiungibili. Per questa ragione risulta di fondamentale importanza che esse si mantengano in attività per il tempo necessario al compimento delle rilevazioni e che la perdita di qualche dispositivo non inuisca eccessivamente sull'ecienza della rete stessa. A tale scopo, sono stati e vengono tuttora implementati protocolli di comunicazione che prevedono la massimizzazione dei periodi d'inattività dei nodi e la presenza di cammini multipli utili al ne di evitare l'isolamento di intere parti della topologia a seguito della perdita di pochi dispositivi. Altri vincoli vengono imposti dalla capacità trasmissiva dei singoli nodi. Risulta infatti evidente la necessità di trovare il giusto connubio tra range di trasmissione e dispendio energetico, poiché maggiore sarà la potenza a cui i dispositivi trasmetteranno il segnale e minore sarà il numero di pacchetti inviabili prima dell'esaurimento della batteria. Per questa ragione si cerca di minimizzare 2
  • 13. la distanza tra i dispositivi, procedendo preferibilmente con comunicazioni a medio-corto raggio che prevedano il passaggio per più nodi intermediari (relay) piuttosto che la comunicazione a lungo raggio diretta al nodo sink. Su questo tema si deve però tenere in considerazione l'aumento di complessità dato dalla stesura di un protocollo di routing tale da garantire la trasmissione attraverso multi-hop e dunque l'aumento dei costi di produzione per il sistema. Ulteriore compromesso riguarda il throughput che diminuisce considerevolmente all'aumentare del numero di hop tra il nodo d'invio e il sink, a causa sia dell'aumento della probabilità d'errore in trasmissione e ricezione, che al necessario tempo di re-inoltro dovuto al nodo intermediario [3]. Inne si ha da tenere in considerazione il forte limite dovuto alla capacità di calcolo ed elaborazione dei nodi sink e master, nei confronti delle informazioni fornite dai dispositivi di rete. Tale vincolo li- mita le dimensioni della rete stessa e viene ovviato grazie all'aggiunta di dispositivi di coordinamento, i quali però necessitano di particolari protocolli di comunicazione rivolti all'accreditamento dei nodi [3]. Alla luce di ciò si può forse percepire la grande molteplicità di soluzioni sviluppabili e la notevole importanza dell'analisi del problema in oggetto, allo scopo di redigere e calibrare un protocollo di rete ad-hoc che giunga alla risoluzione del servizio richiesto senza sprechi. 1.1.2 Topologie La scelta della topologia è una delle fasi fondamentali nell'ottimizzazione di una rete di sensori. Per quanto riguarda le topologie di rete appartenenti al livello 2 del modello OSI (livello di collegamento), poniamo attenzione alle congurazioni: • Stella: costituita da slaves collegati a un unico master che assume anche la funzione da sink della rete. Tale topologia è funzionale nel caso di reti non troppo estese, che comunichino attraverso lo scambio di payload di dimensioni ridotte [3]. • Peer to peer: rete costituita da più dispositivi aventi tutti uguali caratteristiche. Ogni sensore è abilitato a creare molteplici collegamenti diretti (single-hop), in direzione degli altri componenti della rete, aumentandone quindi la robustezza. Si tratta di una topologia funzionale nel caso di copertura di ampie aree con elevata probabilità di perdita di nodi. Queste strutture prevedono anche la possibile implementazione a livello tre (livello di rete), attraverso il quale si ha il multi-hop, ossia il trasferimento dei dati al di fuori della network d'acquisizione. L'operazione viene svolta da nodi che devono essere programmati implementando anche il proto- collo di routing. Altre topologie di interesse sviluppate per l'implementazione al livello di rete sono quelle proposte dalla Zigbee Alliance [3, 4]: • Tree: rete ad albero con vari livelli di comunicazione dove le foglie sono semplici nodi sensori e i nodi interni sono router. Tale rete svolge un ruolo concorrente alla topologia a stella, diventando più eciente all'aumentare del numero di nodi e/o della grandezza del payload. 3
  • 14. • Cluster: rete composta da un coordinatore centrale, collegato a molteplici routers che fungono da master per i nodi aliati. Ogni router forma un cluster e ogni cluster è identicato da un preciso ID. Le comunicazioni interne sono bidirezionali ma asimmetriche. Il master denirà gli istanti di sincronizzazione del cluster e fungerà da sink per i dispositivi aliati, inoltre raccoglierà ed elaborerà le informazioni procedendo al loro inoltro al coordinatore centrale. • Mesh: rete a singolo coordinatore, data dall'unione delle strutture peer-to-peer e cluster. Tale topologia rende la rete molto dinamica grazie alla ridondanza dei percorsi e permette anche la creazione di strutture di reti più complesse. 1.1.3 Principali applicazioni Le reti di sensori wireless sono strumenti dal grande potenziale. La loro versatilità ed economicità ha portato questi dispositivi a diondersi rapidamente in tutti i settori del mercato nei quali fosse richiesto non solo un feedback a stimoli attivi ma anche il semplice controllo e monitoraggio di eventi. E' possibile eseguire una primaria distinzione sulla base dell'utilizzo di queste tecnologie. Si considerano allora, WSNs per: - Event Detection (ED) - Spatial Process Estimation (SPE) Nel caso di reti basate sulla ED avremo che i nodi trasmetteranno un segnale binario che indicherà la presenza o l'assenza dell'evento da rilevare. Il messaggio conuirà a un coordinatore che analizzerà le risposte pervenute e stimerà la probabilità di errore di trasmissione/ricezione, producendo il responso del monitoraggio relativo all'intera area controllata. Gli ambiti applicativi per questa categoria di reti sono i più svariati e possono andare dal controllo ambientale di grandi aree, attraverso l'individuazione di incendi, alluvioni, terremoti, piuttosto che al automotive, col ne di fornire feedback immediati riguardo il funzionamento di dispositivi elettronici, o meccanici, no a raggiungere scopi di interesse militare o di sicurezza privata [2]. Per quanto riguarda la tecnologia SPE, queste reti hanno solitamente una disposizione di nodi casuale e piuttosto tta. I pacchetti trasmessi conterranno informazione mirata riguardante il punto di collocazione. Il ne è quello di fornire una distribuzione omogeneamente spaziata di una caratteristica del territorio (pressione, temperatura, altimetria, etc.) [3]. La copertura e la nezza nella rappresen- tazione risulteranno tanto più accurate quanti più nodi saranno presenti nella zona considerata. Al contrario però si avrà che maggiore sarà il numero di nodi utilizzati e minore sarà il throughput della rete. Un'applicazione di recente sviluppo che utilizza entrambe queste strategie e data dal Energy E- cient Buildings [3]. Essa permette l'ottimizzazione energetica degli edici grazie a sensori di movimento (ED) e luminosità (SPE) disposti nelle stanze. Prevede inoltre la possibilità di controlli manutentivi dello stabile quali inltrazioni o lievi cedimenti strutturali. Altre applicazioni delle WSN si riscontrano nel settore domestico con il Home Automation, nel settore commerciale relativamente al controllo qualità e tracciamento della merce, nel settore biome- dicale, con monitoraggi non invasivi sui pazienti e sviluppo di strumentazione di alta specializzazione e in svariati altri ambiti. 4
  • 15. 1.2 Accesso al mezzo Il sottolivello MAC costituisce la parte più bassa del secondo livello dello standard ISO/OSI, posto a diretto contatto col livello sico. Il principale compito di questo sottolivello consiste nel gestire l'accesso al canale di comunicazione, anché i dispositivi di rete possano eseguire scambi d'informazione [5]. A tale scopo sono implementati svariati algoritmi e protocolli, i quali si dierenziano in funzione alle richieste e possono essere atti a minimizzare le collisioni dei frame in ricezione, piuttosto che garantire l'ottimizzazione del duty cycle o la massimizzazione del throughput. Uno dei problemi principali per il quale il livello MAC relativo alle WSNs viene implementato con attenzione riguarda la salvaguardia della batteria e quindi la massimizzazione del tempo di vita dei nodi interni alla rete [5]. Le problematicità da trattare in questo ambito sono numerose. La principale fonte di spreco energetico è rappresentata dalle collisioni dei pacchetti all'interno del canale di comunicazione. Con il termine collisioni si vogliono identicare gli eventi che provocano la mancata ricezione del frame. Essi sono tipicamente dovuti a una trasmissione concomitante (anche parziale) da parte di due o più nodi in direzione di uno stesso ricevitore, il quale subirà un eetto d'interferenza che produrrà disturbo nella ricezione del pacchetto e la conseguente necessità di chiederne la ritrasmissione [6]. Altre fondamentali cause della dissipazione energetica dei nodi sono dovute al overhearing, al idle listening, al control-packet overhead e al over-emitting 1, tutte problematiche comuni che hanno biso- gno di particolare attenzione in fase di progettazione del protocollo [6]. Si ha quindi che un buon protocollo MAC debba presentare caratteristiche di accesso tali da moderare gli sprechi appena descritti e permettere il completamento delle rilevazioni richieste. 1.2.1 Tecniche di accesso al mezzo Le tecniche di accesso al canale trasmissivo, come accennato in precedenza, sono molteplici. In pri- ma approssimazione possono essere distinte in due categorie. Si parla quindi di accesso attraverso Contention-Based Protocols, riferendosi a tutti quei protocolli che permettono l'inizializzazione delle trasmissioni in maniera non coordinata, o attraverso Contention-Free Protocols, riferendosi invece ai protocolli che garantiscono l'allocazione di risorse esclusive ai singoli nodi. Contention-Based Protocols Questi protocolli mostrano alte performance in relazione alla gestione di un traco randomico, generato ad esempio dalla rilevazione ambientale, con la circolazione di pacchetti lungo tutta la rete [7]. Data la non coordinazione delle trasmissioni, essi devono prevedere meccanismi di controllo che gli permettano di ridurre il rischio di collisioni e nel caso di gestirle; queste tipologie di protocolli vengono, 1Tutti i termini citati indicano fasi di dissipazione energetica superua ai ni della comunicazione desiderata. In particolare ci si riferisce a overhearing indicando la ricezione da parte di un nodo di pacchetti diretti ad altri nodi della rete; idle listening come il mantenimento della fase di ascolto in un canale dormiente; control-packet overhead l'invio di pacchetti per il controllo del corretto funzionamento del canale; over-emitting come la trasmissione di frame in intervalli temporali nei quali i nodi ricevitori non sono disponibili o ancora pronti [6]. 5
  • 16. infatti, spesso implementati prevedendo la ritrasmissione di pacchetti di acknowledgement al ne di rendere nota al trasmettitore la ricezione o meno dei dati da parte del ricevente. I principali protocolli di questo tipo sono il Carrier Sense Multiple Access (CSMA) e ALOHA. Al ne del nostro lavoro ci limitiamo a fornire una presentazione sintetica solo del protocollo CSMA 2. - Carrier Sense Multiple Access (CSMA) Si tratta di un protocollo ad accesso casuale basato sul rilevamento della frequenza portante [8]. Le trasmissioni avvengono a seguito della verica della disponibilità del canale di comunicazione, il quale può essere identicato come slotted nel caso in cui le trasmissioni debbano avvenire in corrispondenza dell'inizio di uno slot; unslotted nel caso in cui le trasmissioni possano iniziare in qualsiasi istante. Col ne di evitare problemi di hidden-terminal 3, viene spesso richiesta la copertura attraverso col- legamento broadcast a tutti i nodi, questo provoca però l'eetto opposto, generando il problema di exposed-terminal 4 e provocando il rallentamento nel passaggio dei dati [9]. Negli sviluppi si predilige ugualmente però questa seconda soluzione poiché limita gli eetti di collisione. In relazione ai sistemi di accesso al canale del protocollo CSMA si possono aggiungere due esten- sioni atte a migliorarne l'adabilità. Si parla allora di CSMA con Collision Detection (CSMA-CD) se il protocollo prevede il monitoraggio del canale vericando che i dati non subiscano modiche durante la trasmissione (metodo maggiormente utilizzato nelle connessioni via cavo) [10]. CSMA con Collision Avoidance (CSMA-CA) se vengono messe in atto misure di controllo del canale, come l'allungamento del periodo di listening, preposte ad aumentare la probabilità di trasmissione senza collisioni (metodo utilizzato nelle connessioni wireless) [8, 10]. Questo protocollo, non richiedendo una fase di coordinamento dei nodi, consente un notevole gua- dagno in termini di ecienza energetica nel caso in cui si abbia la necessità di trasmettere una quantità limitata di dati, mostrando però forti limiti riguardo la velocità di trasmissione quando più dispositivi simultaneamente presentano la necessità di comunicare. Contention-Free Protocols Si tratta di protocolli che non prevedono la presenza di collisioni, poiché a ogni nodo vengono allocate delle risorse. Questa categoria di protocolli è a sua volta implementata attraverso due strategie, la Fixed Assignment e la Dynamic Assignment [9]. 2Il protocollo ALOHA non viene descritto qui di seguito per ragioni di brevità. Si ha, infatti, che nessuno dei protocolli presentati nel Paragrafo 1.3 o delle risoluzioni sviluppate e presentate nel Capitolo 2 utilizzi questa metodologia d'accesso al canale. 3Con hidden-terminal si intende la trasmissione simultanea di più nodi verso uno stesso ricevitore, causata dalla mancanza di visibilità reciproca. 4Con exposed-terminals indichiamo quei nodi che eseguita la richiesta di trasmissione, sono costretti a mantenere lo stato d'attesa, poiché percepiscono la comunicazione tra nodi limitro. 6
  • 17. Anche in questo caso, per motivi legati all'utilizzo successivo di quanto descritto, si è deciso di presentare solo protocolli relativi alla strategia di Fixed Assignment. Consideriamo allora i tre protocolli costituenti questa sotto-categoria: - Time Division Multiple Access (TDMA) Questo protocollo permette la comunicazione di più dispositivi attraverso la suddivisione del frame di trasmissione in intervalli temporali (slot). Ogni slot viene assegnato a un singolo nodo, determinando con esso una corrispondenza biunivoca. Ciò è possibile grazie da una preliminare fase di sincronizzazione e al passaggio periodico di pacchetti atti a garantirne il mantenimento. E' previsto che tutti i nodi eseguano la trasmissione dati in rapida successione all'interno degli slot costituenti il frame e che abbiano la possibilità di occupare l'intera banda di frequenze in dotazione al canale [11]. Lo sviluppo di questa modalità d'accesso permette una comunicazione sicura (priva di collisioni) ed eciente dal punto di vista energetico. Il dispendio della fase di coordinamento è, infatti, compensato dal minor tempo di latenza dei nodi, che non dovranno restare attivi in attesa della liberazione della portante ma potranno attivarsi unicamente in corrispondenza del proprio slot. - Frequency Division Multiple Access (FDMA) Basato sulla divisione di frequenza, il protocollo FDMA permette la trasmissione simultanea di più ussi d'informazione. Si prevede, infatti, la suddivisione del canale di trasmissione in bande e l'assegnazione di ogni banda a un dispositivo dierente [10]. Similmente al protocollo TDMA sarà necessaria una fase di coordinamento e quindi anche di studio della topologia al ne di poter allocare le risorse. - Code Division Multiple Access (CDMA) Tale metodo di accesso multiplo si fonda sull'assegnazione, a ogni dispositivo di rete, di un codice ortogonale dierente rispetto a tutti gli altri. Le trasmissioni possono quindi avvenire negli stessi intervalli temporali e occupando l'intera am- piezza di banda poiché i segnali risultano ugualmente distinguibili in funzione al loro codice. Se nel caso di pochi serventi, il protocollo CDMA, non mostra particolare ecienza, risultati migliori si ottengono all'aumentare dei nodi nella rete, arrivando a superare gli esiti ottenuti dai protocolli TDMA e FDMA in relazione alla riduzione del duty cycle [10]. 7
  • 18. 1.3 Speciche aziendali e analisi degli standard 1.3.1 Speciche aziendali Come in parte descritto nell'introduzione, il progetto prevede l'individuazione di un protocollo per WSNs che permetta la ricezione di le audio in streaming. Tale prerogativa implica la trasmissione di molti dati in intervalli di tempo ridotti. E' stato quindi stimato il minimo throughput necessario a garantire lo scopo, risultante in 192 kbps. Dal momento che i pacchetti acquisiscono senso solo se ricevuti in sequenza, tra le speciche non è richiesto il re-invio dei dati in caso di mancata ricezione. Questa caratteristica porta all'assenza della necessità di acknowledgements con la possibile riduzione del usso di dati nella rete. Il contesto nel quale si suppone verranno collocati i nodi, consiste in un ambiente urbano delle dimensioni di una stanza. Si tratterà allora della disposizione di pochi dispositivi a una distanza che non supererà i dieci metri. Data la natura dell'ambiente, vi è la necessità di prevenire i possibili problemi dovuti all'interfe- renza. Dev'essere quindi sviluppata una rete robusta e scalabile, che mantenga la sua operatività nel caso di perdita o di ricomparsa dei nodi. Considerato che a seguito della loro collocazione i sensori non saranno più raggiungibili e non vi sarà la possibilità di alimentarli via cavo, appare indispensabile cercare di minimizzare il duty cycle, imponendo una scarica graduale e omogenea delle batterie allo scopo di aumentare la longevità della rete e il numero di rilevazioni. Si richiede, inne, l'utilizzo di topologie generiche e la possibilità, da parte di tutti i nodi, di fungere da relay, sviluppando, quando necessario, la comunicazione multi-hop. Nessun vincolo viene imposto sul metodo d'accesso al mezzo trasmissivo, il quale però dovrà per- mettere la soddisfazione di tutte le caratteristiche sopraccitate. I requisiti protocollari da tenere in considerazione sono dunque riassumibili in: - Elevata bit rate - Robustezza e scalabilità - Basso consumo energetico - Genericità delle topologie - Possibilità di multi-hop 1.3.2 Panoramica dei protocolli di accesso al mezzo Presentiamo una rapida descrizione di alcuni dei più noti standard riguardanti il livello MAC, mettendo in luce l'esistenza o meno dell'implementazione del livello di routing che permetta il multi-hop. 8
  • 19. Bluetooth Bluetooth è un sistema di comunicazione a corta distanza (massimo 10 metri), studiato per reti WPANs. E' stato sviluppato in modo da consentire un'alta velocità di trasmissione (qualche Mbps) in funzione di un moderato consumo energetico. La rete è sviluppata in piconet di al più sette elementi attivi [12]. Per ogni piconet è previsto un master che ha il compito di mantenere la sincronizzazione tra i dispositivi e fungere da sink per l'elaborazione dei dati e il re-inoltro. Il protocollo è sviluppato unicamente per topologie a stella o point-to-point, non sono previste infatti comunicazioni multi-hop tra i nodi, i quali hanno la possibilità di comunicare solo in via diretta col nodo master. La modalità di accesso al mezzo all'interno di ogni piconet è basata su TDMA, in aggiunta il canale viene suddiviso in 79 portanti e si utilizza la tecnica di trasmissione radio FHSS (Frequency Hopping Spread Spectrum) grazie alla quale la comunicazione esegue cambi continui di frequenza evitando di rimanere ssa su di un canale che potrebbe essere rumoroso [4]. Sviluppo ulteriore della tecnologia Bluetooth è la versione Bluetooth Low Energy. In essa vengono ottimizzate le dimensioni e il numero di pacchetti trasmessi, i periodi d'inattività dei nodi e la fase di rilevamento dei dispositivi. Permette un'ecienza no a quindici volte maggiore se confrontata alla versione uciale del protocollo Bluetooth, tale ecienza è pagata però attraverso la diminuzione del throughput il quale non supera i 300 kbps [3]. Zigbee Zigbee è un protocollo sviluppato per la comunicazione in reti di ampie dimensioni, il cui obiettivo principale è quello di minimizzare il consumo energetico. La velocità di trasmissione può arrivare a 250kbps, garantendo la copertura sino a 75 metri. I dispositivi costituenti ogni topologia sono di tre nature [3, 13]: - Il coordinatore (FFD): che si occupa di denire i compiti e di eseguire la mappatura della rete. - I router (FFDs): che permettono l'inoltro dei pacchetti. - Gli end devices (RFDs): i quali possono unicamente trasmettere al FFD più vicino i propri pac- chetti. L'implementazione del protocollo prevede due possibili metodi d'accesso al mezzo: il beacon- enabled mode e il non beacon-enabled mode. Per quanto riguarda il non beacon-enabled mode si ha che tutti gli RFDs hanno la possibilità di inviare i pacchetti agli FFDs in un qualsiasi momento, ciò provoca la necessità di mantenere dispositivi router e coordinatore sempre attivi e in fase di ricezione poiché non si è a conoscenza di quando verranno attivate le comunicazioni. Si verica quindi un forte dispendio energetico da parte di questi nodi. Nel caso del beacon-enabled mode invece l'intervallo di trasmissione è predenito, quindi FFDs e RFDs si attivano insieme in una fase di comunicazione gestita inizialmente attraverso CSMA-CA e successivamente attraverso un dei protocolli contention-free [14]. Questa seconda metodologia d'accesso è stata sviluppata in principio solo per topologie a stella, nelle quali tutti gli RFDs inviavano attraverso singolo hop i dati a un coordinatore di rete. 9
  • 20. Seppur a seguito della denizione delle topologie cluster-tree 5 sia stato possibile sviluppare proto- colli basati su questo metodo d'accesso che permettessero il multi-hop, si ha che la prevenzione dalle collisioni, necessaria in questo caso, genera il notevole aumento del duty cycle di ogni nodo. In letteratura esistono, infatti, protocolli che permettono la gestione di collisioni dirette 6 e indirette 7 dei pacchetti nell'esecuzione dei multi-hop, Questi protocolli però necessitano di un intervallo temporale consistente per vericare le collisioni, limitando l'ecienza e riducendo il risparmio energetico [14]. ANT Questo protocollo è sviluppato per applicazioni ultra-low power, permette comunicazioni di tipo broadcast, burst o con acknowledgement, in reti di dimensioni di circa trenta metri. In modalità burst presenta una data rate di 20kbps (vero data throughput), nella modalità broad- cast e acknowledgement permette di arrivare sino a 1Mbps [13]. Le topologie supportate sono del tipo point-to-point, stella, albero e mesh, arrivando a controllare un massimo di cento dispositivi. Ogni nodo può fungere sia da master che da slave, garantendo quindi una buona intercambiabilità al ne della condivisione del carico. Il canale è suddiviso in sotto-portanti dell'ampiezza di banda di 1MHz e il metodo d'accesso è basato su TDMA. Si tratta di una tecnologia proprietaria, dai costi di produzione molto contenuti e dal bassissimo dispendio energetico, la quale però manca d'interoperabilità [3]. S-MAC Sensors MAC è un protocollo contention-based, che utilizza la tecnica di ascolto della portante con collision avoidance per garantire la propagazione dei dati [6]. Il range così come la potenza trasmissiva, sono dipendenti dai dispositivi e le topologie supportate possono essere di qualunque tipo. Il protocollo è strutturato su due fasi: lo sleeping period e il listening period. Queste si alternano in maniera sistematica, determinate da iniziali impostazioni di set-up atte a regolare il duty cycle [7]. Non essendovi un coordinatore di rete, i nodi eseguono l'accesso al canale secondo una program- mazione temporale del tutto autonoma. E' inoltre prevista la possibilità di eseguire due accessi in un singolo periodo, cosa che, seppur aumenta la possibilità di trasmissione, causa overhearing e idle listening nel canale. Allo scopo di ridurre i tempi di latenza, è introdotto un pacchetto di sincronizzazione, il quale viene trasmesso broadcast da ogni nodo a quelli limitro, per condividere la propria programmazione temporale [6]. 5Topologie nelle quali ogni cluster è composto da un FFD a cui sono collegati zero o più end-devices. Ogni FFD è a sua volta collegato con i coordinatori dei cluster limitro in modo tale da formare un albero attraverso cui poter eseguire il re-inoltro dei pacchetti. 6Col termine collisioni dirette facciamo riferimento alle collisioni dovute alla trasmissione simultanea di due nodi che sono l'uno entro il range di trasmissione dell'altro. Esempi di questi protocolli sono il Time Division protocol e il Beacon Only Protocol [14]. 7Col termine collisioni indirette ci riferiamo a quelle collisioni che hanno luogo su un terzo nodo, il quale riceve le trasmissioni simultanee emesse da due nodi che non sono in range tra loro. Esempi di questi protocolli sono il Reactive Approach Protocol e il Proactive Approach Protocol [14] 10
  • 21. Si ha così che chiunque dovesse avere la necessità di trasmettere a un nodo, potrà risvegliarsi nel corretto intervallo, evitando la dissipazione di energia. Nonostante i pacchetti di sincronizzazione, l'accesso attraverso CSMA-CA, provoca tempi di latenza considerevolmente prolungati sopratutto in relazione alle trasmissioni richiedenti multi-hop. Si tratta quindi di un protocollo ottimizzato per permettere la trasmissione di pochi dati, ripetuti con ciclicità. LEACH Il Low Energy Adaptive Clustering Hierarchy è un protocollo di ottimizzazione energetica molto eciente. Basato sul concetto di divisione della rete in cluster, prevede la nomina di un master (Cluster Head - CH) per ogni cluster, il quale varierà a intervalli regolari in maniera randomica [15]. Il protocollo prevede due fasi, la prima di set-up, con la formazione dei clusters e la nomina dei rispettivi CH, la seconda di Steady State, nella quale il CH dovrà rimanere attivo per tutta la durata del periodo di nomina, ricevendo ogni pacchetto derivante dal proprio cluster ed eseguendo la compressione dei dati, prima di re-inoltrarli al AP. La metodologia d'accesso al canale utilizzata è del tipo contention-free, solitamente implementata attraverso CDMA o TDMA. Tale metodo viene adoperato al ne di minimizzare le interferenze, non solo tra i nodi di un cluster ma anche tra cluster limitro [16]. Il protocollo prevede la possibilità da parte di tutti i nodi di raggiungere il AP, non viene per questo prevista l'implementazione del livello di routing per gestire il multi-hop tra cluster. Le topologie di rete risultano quindi basate su disposizioni a stella, concentrate in ridotte aree, tali da consentire la visibilità diretta del AP. 11
  • 22. 1.4 Inconsistenza dei protocolli esistenti Dall'analisi della letteratura trattata nel Sotto-paragrafo 1.3.2, si può denotare come ogni protocollo descritto, seppur ane alle speciche di progetto, non sia suciente a soddisfare le richieste nella sua attuale implementazione. Si noti infatti che, nonostante il protocollo Bluetooth garantisca un'elevata bit rate, con la pos- sibilità di reti a sette nodi attivi, esso non potrà essere utilizzato poiché non prevede la possibilità di eseguire multi-hop essendo programmato solo per topologie a stella o point-to-point. In aggiunta prevede una maggiore dissipazione di energia da parte del nodo master che dovrà farsi carico della compressione e del re-inoltro dei pacchetti di tutta la rete. Ugualmente, non potrà essere utilizzato il protocollo Bluetooth Low Energy, il quale seppur pre- vedendo un minor consumo da parte dei nodi e una suciente velocità di trasmissione, non permette ai propri dispositivi di funzionare da relay. Stesso problema presenta anche il protocollo LEACH. Sebbene quest'ultimo soddis tutte le carat- teristiche di risparmio energetico, robustezza e bit rate, la sua implementazione prevede la divisione in cluster comunicanti direttamente con il AP; non è previsto di conseguenza alcun protocollo di routing. Il relazione al protocollo ANT le problematicità cambiano. Il limite in questo caso è dovuto al throughput, che raggiungendo i 60kbps non è suciente a garantire le risorse per lo streaming. Malgrado le motivazioni siano diverse, il medesimo problema vincola anche il protocollo S-MAC. Se nel primo caso, il limite alla velocità trasmissiva è dato dalla ricerca di massimizzazione della durata della vita dei dispositivi. Nel secondo caso la causa della lentezza nelle trasmissioni è dovuta al meccanismo d'accesso al mezzo, il quale, per il protocollo S-MAC, impone lunghi periodi di latenza sopratutto in presenza di intenso traco. Concludiamo con l'analisi del protocollo Zigbee, che presenta due tipi distinti d'implementazione. Le problematiche legate allo sviluppo del protocollo attraverso accesso con CSMA-CA sono coerenti con quelle riscontrate dal protocollo S-MAC. In questo caso però la prolungata latenza dei nodi non incia considerevolmente la velocità di trasmissione, che invece rimane elevata, ma lede l'autonomia dei dispositivi, i quali riscontrano l'aumento del duty cycle provocante il rapido consumo delle batterie. La seconda metodologia d'accesso, che utilizza CDMA o FDMA, presenta invece un basso consumo energetico, ma come in relazione al protocollo LEACH, la suddivisione della topologia in clusters, produce una notevole dicoltà nello sviluppo di protocolli di routing. Si ha infatti che questi quando sviluppati, provocano il decadimento delle prestazioni nella trasmissione di dati o nella sopravvivenza della rete. 1.4.1 Analisi conclusiva Giunti a questo punto è necessario sottolineare che, malgrado quella di questo capitolo fosse solo una breve esposizione comprendente alcuni dei protocolli d'accesso al mezzo più conosciuti, riuscire a sod- disfare le speciche assegnate non è aatto banale. Difatti, anche l'analisi più approfondita di tali protocolli o la ricerca di altri (come Wireless Hart, Z-Wave, Pegasis, etc.) non avrebbe prodotto risul- tati migliori, limitandosi a evidenziare caratteristiche già citate e nel complessivo non soddisfacenti le 12
  • 23. prerogative aziendali 8. Se ne conclude la necessità di costruire protocolli nuovi, sviluppati ad-hoc, in conformità con gli standard e le speciche assegnate. Proponiamo ora la tabella riassuntiva dei protocolli, corredata con quelle che sono le necessità aziendali ed enfatizzando gli attributi che hanno reso i protocolli studiati non consistenti col nostro progetto. 8Facciamo notare come Wireless Hart non presenti la possibilità di comunicazione attraverso multi-hop [17] così come il protocollo Pegasis [16], mentre Z-Wave essendo una tecnologia proprietaria, come ANT, manchi di interoperabilità. 13
  • 25. Capitolo 2 Protocolli e ambienti di sviluppo Questo capitolo è dedicato alla formalizzazione dell'obiettivo di tesi e alla presentazione dei due protocolli ideati per soddisfarne le speciche. Si eseguirà inoltre una dettagliata descrizione dei simulatori e dei programmi a contorno che hanno permesso la raccolta dei dati. 2.1 Elaborazione del problema Prese in considerazione le problematiche esposte nel capitolo precedente e i limiti dei protocolli esi- stenti, presentiamo, con questa tesi, la formulazione di un protocollo semplicato che funga da base di lavoro per risolvere il problema reale. Proponiamo, quindi, la progettazione e l'analisi di un nuovo protocollo, il quale non prevede più la ricezione di frames per streaming audio, ma consiste bensì nella trasmissione di un singolo pacchetto a tutti i nodi della rete. Questo pacchetto, che viene trasmesso dal nodo master, supponiamo contenga informazioni ge- neriche e nello specico relative al tempo, quindi all'orario scandito dal nodo master con la propria precisione. L'obiettivo è quello di valutare il minimo numero di iterazioni del frame che assicuri a ogni nodo una probabilità di ricezione dell'ora maggiore del 99.5% e studiarne i risultati al variare delle topologie. Facciamo notare che questa fase di progettazione non tiene conto di alcune delle dicoltà sottolinea- te in precedenza. Non vi sono, infatti, riferimenti all'implementazione di protocolli per comunicazione multi-hop, non vengono considerati i problemi dovuti alla robustezza della rete, in quanto si assume la mancanza d'interferenza esterna e quindi la completa visibilità tra i nodi nel canale di comunica- zione, e non si considerano, inne, neppure i problemi indotti dalla scalabilità, poiché l'esaurimento della batteria da parte di un solo nodo porta alla terminazione della fase di comunicazione fornendo le informazioni relative alla massima longevità della rete. Si provvede però ad analizzare gli eetti delle collisioni ed è appunto su questo tema che si concen- tra la stima delle iterazioni d'invio che inuenza la vita dei dispositivi. In conclusione ci limitiamo a cercare il miglior protocollo che massimizzi la durata delle batterie di tutti i dispositivi sottoposti a comunicazione. 15
  • 26. 2.2 Presentazione dei protocolli A seguito della rielaborazione del problema, confrontiamo due soluzioni che permettono formalmente di soddisfare le speciche minimizzando il duty cycle. Queste prendono il nome di Protocollo Asincrono e Protocollo Sincrono in riferimento alle dierenze d'accesso al canale trasmissivo. La presentazione dei protocolli e lo studio delle simulazioni software ci permetteranno, nel capitolo successivo, di determinare le condizioni d'ottimalità di entrambi e quindi di denire il protocollo migliore per fungere da base d'analisi al problema reale. 2.2.1 Protocollo Asincrono Bastato sull'idea implementativa del protocollo S-MAC, il protocollo Asincrono prevede l'accesso al mezzo trasmissivo attraverso CSMA. Non prevedendo fasi di coordinamento, questo metodo assicura un considerevole risparmio energetico iniziale, il quale andrà dissipandosi all'aumentare del numero di comunicazioni nella rete. La trasmissione dati avviene sotto forma di burst di pacchetti, trasmesso da ogni nodo in possesso dell'informazione in istanti pseudo-randomici delle comunicazioni. Considerato che i pacchetti costituenti il burst contengono tutti la medesima informazione, ai nodi limitro è suciente la ricezione completa di un unico pacchetto. La scelta di utilizzare un burst è data dalla volontà di limitare i tempi di ricezione. In particolare ogni nodo alterna brevi stati di ricezione a più lunghi stati di dormienza, dunque per permettere la ricezione di un pacchetto è necessario fare in modo che il burst duri almeno il tempo di due ricezioni successive. Poiché nodi diversi possono eseguire il burst in istanti di tempo vicini, la gestione delle collisioni deve basarsi sullo studio del numero di ritrasmissioni necessarie anché tutti i nodi abbiano la possibilità di ricevere il frame. Per il nostro studio, consideriamo soddisfatta questa condizione quando otteniamo una probabilità di corretta ricezione maggiore allo 0.995. Lo studio della probabilità è stato sviluppato attraverso l'implementazione del programma Block- Dis(nodi, slot) che verrà presentato nel Paragrafo 2.3.1. Le topologie, come previsto dalle richieste, possono essere di natura generica purché costituiscano un insieme connesso: ossia tutti i nodi devono avere nel loro raggio di trasmissione almeno un altro dispositivo e non ci devono essere settori isolati; inoltre, la rete deve prevedere la presenza di almeno un nodo slave e di un solo nodo master, denito a priori, che funga da trasmettitore iniziale. Attraverso la Fig.1 è possibile vedere la generica attività di un singolo nodo in riferimento al proto- collo. Si può notare come essa sia caratterizzata da quattro stati, quello di risveglio (Waking up state), quello di dormienza (Sleeping state), quello di ricezione (Receiving state) e quello di trasmissione (Data packet transmitting state). Viene inoltre enfatizzato come l'alternanza di questi stati dia luogo a due fasi, Receiving phase e Transmitting phase, costituenti le possibili attività dei nodi. Il protocollo ha una struttura periodica nel tempo tale da permettere la divisione in blocchi e periodi. 16
  • 27. I blocchi identicano l'intervallo temporale tra due ricezioni successive. I periodi, invece, sono costituiti da un numero sso di blocchi tale da includere un burst di tra- smissione. Il numero di periodi, data la relazione con il burst di pacchetti, risulta essere funzione del programma d'ottimizzazione 9. Sottolineiamo come questa suddivisione sia indipendente dalla struttura della rete. Difatti, poiché il protocollo è asincrono dobbiamo supporre che le basi dei tempi (quindi blocchi e periodi) possano essere sfasate da nodo a nodo. Figura 1: Fasi protocollo Asincrono Analisi degli stati Waking up state Consiste nell'intervallo di tempo necessario anché il nodo si riattivi e prenda conoscenza del compito da svolgere negli istanti successivi. Precede ogni stato d'attività, seguendo agli stati di dormienza dei dispositivi. Il consumo energetico previsto è limitato poiché tutte le operazioni richiedono unicamente l'utilizzo dalla CPU interna al sensore. Sleeping state In questo intervallo temporale il nodo risulta inattivo. Si tratta di uno stato di dormienza che permette di preservare al massimo la batteria, non consentendo alcuna operazione se non il proseguire dei cicli di clock col ne di determinare il successivo istante di risveglio. Osservando la Fig.1, si fa notare che lo stato di dormienza che segue la trasmissione del burst di dati è di lunghezza dierente rispetto a quello che segue gli stati di recezione. Questo fatto è dovuto alla necessità da parte del singolo nodo di attendere l'inizio del nuovo blocco prima di procedere con la fase successiva. 9Durante la presentazione del simulatore Asincrono, Paragrafo 2.3.2 - Sotto-paragrafo Protocollo Asincrono, si provvederà a fornire maggiori spiegazioni riguardo la necessità d'utilizzo di più periodi ai ni della corretta ricezione del frame da parte di tutti i nodi interessati. 17
  • 28. Data packet transmitting state Questo stato permette al nodo di trasmettere pacchetti alla rete. Le dimensioni sono calibrate su quelle del pacchetto da trasferire e il consumo energetico è elevato a causa dell'utilizzo della ricetrasmittente. Receiving state Lo stato di ricezione prevede l'utilizzo della ricetrasmittente per l'ascolto del canale di comunicazione. Anche questo presenta un consumo elevato e il dimensionamento è funzione dei pacchetti trasmessi. Si ha, infatti, che ogni stato di ricezione dev'essere almeno due volte più lungo di ogni stato di trasmissione. Analisi delle fasi Transmitting phase La fase di trasmissione è una delle due attività consentite a un nodo sensore che implementa questo protocollo. Questa si compone della successione di tre stati: Waking up state, Data Packet Transmitting state e Sleeping state. Il numero di iterazioni dello stato Data Packet Transmitting è funzione delle dimensione del pacchetto e della lunghezza dei blocchi. Tale numero di iterazioni va a formare il burst di trasmissione e assicura la possibilità di ricezione da parte di tutti i nodi limitro 10. La fase di trasmissione è pseudo-randomica. Difatti, tutti i nodi aventi necessità di trasmettere individuano autonomamente un blocco nel quale eseguire il burst. La trasmissione viene eettuata una sola volta per periodo e il numero di periodi successivi che presentano il burst è deciso dal programma di ottimizzazione. La presenza di questa fase non è obbligatoria in ogni periodo ma è attivata solo in caso di neces- sità da parte del nodo. L'intervallo di tempo occupato dal burst può, infatti, venire compensato dal susseguirsi di due stati di ricezione, come mostrato nella Fig.2. Figura 2: Compensazione del burst 10Il dimensionamento del burst è specicato nel sotto-paragrafo successivo, Receiving phase 18
  • 29. Poiché negli istanti iniziali di vita della rete l'unico nodo ad avere l'informazione è il nodo master, questo esegue un periodo comprendente la fase di trasmissione, mentre tutti gli altri dispositivi com- pletano lo stesso periodo in fase di ricezione. Essendo il canale privo di perdite, tutti i nodi a distanza di un hop dal trasmettitore ricevono l'informazione. Il nodo master, quindi, non avendo più necessità di comunicare, esegue i periodi successivi in fase di ricezione. I nodi slave, invece, ricevuto il pacchetto provvedono al suo re-inoltro. Tale operazione, come suggerito in precedenza, è costituita da un numero di periodi dato dal programma d'ottimizzazione e comprendenti la fase di trasmissione. Ovvero, i nodi trasmettono il burst per un numero di pe- riodi opportunamente scelto tale da garantire la massima probabilità di ricezione a tutti i dispositivi limitro. Al termine del re-inoltro l'attività dei nodi slaves torna a consistere solo nella fase di ricezione. Il consumo legato a questa fase è considerevole. L'invio di un pacchetto implica l'accesso al canale con l'accensione della trasmittente e la trasmissione dei dati. Il burst ha quindi un costo notevole in termini energetici e la necessità di eseguire più periodi di trasmissione può portare al rapido consumo della batteria. Receiving phase E' la fase che permette la ricezione dei dati ed è la seconda attività eseguibile dal nodo. Costituita dal susseguirsi di stati di risveglio, ricezione e dormienza, è l'attività che occupa la mag- gior parte della vita dei dispositivi di rete. Gli stati di ricezione interni a questa fase permettono a ogni sensore di rimane in ascolto sul canale sino all'istante di timeout. In caso di ricezione di dati all'interno di questi stati, il nodo provvede alla loro memorizzazione ed elaborazione. Se la ricezione di un pacchetto va a buon ne attraverso la decodica del messaggio, il nodo interrompe lo stato di ricezione passando in Sleeping state prima dell'arrivo del timeout. Questa soluzione garantisce il massimo risparmio energetico, in quanto, una volta ricevuto l'intero pacchetto, risulta inutile ricevere altri dati (poiché come detto in precedenza tutti i frames componenti il burst presentano lo stesso contenuto). Se, invece, al termine della ricezione il nodo non dovesse essere in grado di decodicare il pacchetto, allora eseguirebbe l'eliminazione dei dati, mantenendo attivo lo stato di ricezione sino all'arrivo del timeout. La necessità di eliminare il pacchetto non decodicabile è data dalla scarsa memoria e capacità di calcolo dei dispositivi, mentre la presenza di pacchetti non decodicabili, nonostante la caratteristica d'adabilità del canale, è dovuta al fatto che i nodi non siano tra loro coordinati e quindi un nodo possa iniziare lo stato di ricezione quando la trasmissione dell'altro è già in corso, causando così un rilevamento solo parziale dei dati. Per questa ragione il tempo di ricezione è superiore alle dimensioni di un singolo pacchetto e viene stimato al ne di coprire l'intervallo temporale necessario all'invio di almeno due frame. Su questo problema si basa anche il dimensionamento del burst, Fig.3. La caratteristica di rendere l'insieme Waking up state + burst più lungo rispetto a un singolo blocco implica la possibilità di due istanti di ricezione da parte dei nodi limitro (nel caso non siano anch'essi in fase di trasmissione). In particolare il burst occupa le dimensioni di un blocco a cui è sottratto il tempo dello stato di ricezione e 19
  • 30. sono stati aggiunti due pacchetti di trasmissione. Grazie a questa tecnica se la prima ricezione dovesse terminare senza permettere la decodica del frame, cosa che può avvenire solo trattandosi del primo frame del burst, sicuramente la seconda ricadrebbe ancora all'interno dell'intervallo di trasmissione, consentendo al nodo la ricezione completa dell'ultimo pacchetto. Figura 3: Ricezione pacchetti del burst Caso diverso e più problematico è quello dovuto alle trasmissioni simultanee. Esiste, infatti, la possibilità che a seguito del trasferimento dell'informazione dal nodo master e il conseguente inizio delle trasmissioni da parte dei nodi slaves, questi decidano di inviare il burst in istanti di tempo vicini, provocando nei dispositivi limitro l'eetto di collisioni in ricezione. In questo caso il protocollo è implementato in modo tale che i nodi riceventi entrino subito in Sleeping state e ci restino sino al risveglio successivo. E' necessario far notare che i blocchi di nodi diversi, appartenenti agli stessi periodi, non per forza occuperanno lo stesso intervallo temporale. Ciò è dovuto alla fase d'attivazione iniziale dei nodi che può provocare il disallineamento dei blocchi. Il dettaglio verrà sottolineato maggiormente nell'analisi del simulatore Asincrono del Paragrafo 2.3.2. Con riferimento a quanto appena detto osserviamo la Fig.4. Essa mostra l'esempio di tre nodi salve collegati in serie, in cui i nodi S1 e S3 iniziano il burst in un intervallo temporale ravvicinato e tale da indurre l'eetto di collisioni sullo stato di ricezione del nodo S2. Si può notare, dunque, come S2 a seguito dello stato di Waking up, attivi la ricezione solo per l'intervallo di tempo necessario al ne di rendersi conto della collisione e rientri poi nello stato di risparmio energetico. 20
  • 31. Figura 4: Trasmissione simultanea La gura soprastante ci permette di sottolineare nuovamente la mancanza di coordinamento tra i nodi della rete, i quali non hanno percezione ne del contesto nel quale sono immersi, ne della programmazione temporale dei nodi limitro. La fase di ricezione, come quella di trasmissione, richiede un grande dispendio energetico. Per questo risulta indispensabile vericare con accuratezza il numero di blocchi e di periodi al ne di non incorrere in sprechi. Riportiamo ora il diagramma di usso rappresentante il protocollo Asincrono nei suoi possibili stati e attività: 21
  • 32. Figura 5: Protocollo Asincrono - Diagramma di usso 22
  • 33. 2.2.2 Protocollo Sincrono Il protocollo Sincrono si basa sulla struttura del protocollo LEACH e prevede un metodo d'accesso al mezzo trasmissivo coordinato da parte dei nodi, che sfrutta la tecnica TDMA per eseguire la fase di comunicazione. Le topologie utilizzabili sono di natura generica, grazie alla possibilità da parte di tutti i dispositivi di eseguire multi-hop, inoltre, la comunicazione avviene in sequenza gerarchica, dal nodo master ai nodi slave, in intervalli di tempo deniti, detti slot. Anche i nodi slave sono tra loro distinti in più livelli, in funzione al numero di hop che li separano dal nodo master. Il protocollo è strutturato in tre fasi che permettono rispettivamente la scoperta della rete, l'allo- cazione degli slot di trasmissione e la comunicazione eettiva tra i nodi. Queste fasi, in dipendenza al nodo che si considera, sono attivate in istanti diversi. Le prime due, infatti, mostrano, tempi d'esecu- zione maggiori nel caso di nodi slave posti a numerosi hop di distanza dal nodo master, mentre la terza causa un ritardo nel nodo master, il quale è presente anche tra i nodi slave ma decresce all'aumentare del numero di hop di distanza. I problemi riguardanti la stima e la gestione dei tempi d'attesa sono arontati attraverso l'otti- mizzazione delle trasmissioni con l'ausilio del programma BlockDis(nodi, slot) 11. Per ogni nodo si provvede, infatti, a calcolare il numero di trasmissioni non coordinate tale da assicurare, con probabi- lità superiore al 0.995, la corretta ricezione sia dei pacchetti che descrivono la topologia, sia di quelli che deniscono l'allocazione delle risorse all'interno della trama di comunicazione. La Fig.6 mostra il funzionamento di un dispositivo che esegue il protocollo. Figura 6: Fasi protocollo Sincrono Da questa possiamo distinguere cinque stati dierenti: quello di ricezione (Receiving state), quello di trasmissione (Transmitting state), quello di latenza (Idle state), quello di dormienza (Sleeping state) e quello di risveglio (Waking up state). In aggiunta si osserva come lo stato di dormienza si dierenzi ulteriormente in tre tipologie: Sleeping state, Coordination Sleeping state e Synchronization Sleeping state. La combinazione di questi stati da luogo alle fasi, distinguibili in: Discovery phase, con la scoperta della topologia; Data Initialization phase, con l'allocazione delle risorse; Communication phase, con la comunicazione utile tra i nodi. 11La descrizione del programma si trova nel paragrafo 2.3.1 23
  • 34. Osserviamo come la base dei tempi del protocollo sia strutturata in blocchi, il cui numero è funzione del programma d'ottimizzazione e varia in relazione al nodo e alla fase che si sta considerando. Ogni blocco, inne, è composto da più slot, le cui dimensioni sono costanti e dipendenti dal pac- chetto trasmesso mentre la loro molteplicità risulta essere una delle variabili di gestione del protocollo. Si osservi come il protocollo Sincrono aumenti la propria ecienza all'aumentare del numero di comunicazioni, in modo tale che il benecio apportato dall'avere le risorse assegnate compensi la spesa energetica dovuta al riconoscimento della rete e l'inizializzazione delle risorse. Analisi degli stati Waking up state Questo stato è necessario per preparare all'attività le componenti hardware dei dispositivi, permettendo ad esempio la sincronizzazione dell'oscillatore. Occupa l'intervallo temporale di uno slot e segue a tutti gli stati di dormienza, inuendo sulla batteria con un consumo limitato. Sleeping state Questo stato permette un considerevole risparmio energetico garantito dalla totale inattività del nodo. Come detto in precedenza si hanno tre stati di sleeping caratterizzati da diverse lunghezze. Il primo, detto Sleeping state, appartiene alla fase di Data Initialization; serve a occupare il tempo non altrimenti assegnato di ogni blocco e quindi ha dimensioni costanti per tutta la fase ma dipendenti dal nodo considerato 12. Il secondo e il terzo appartengono alla Communication phase. In particolare il secondo stato, Coordination Sleeping state, mira a riallineare tutti i nodi nello stesso blocco, coordinandoli per la fase di comunicazione. Lo stato può avere le dimensioni di uno o più blocchi in dipendenza al ritardo accumulato dai nodi. Il terzo, Synchronization Sleeping state, invece, prescinde dalla divisione in blocchi ma è un valore ssato dipendente della frequenza con la quale è necessario far circolare un pacchetto all'interno della rete al ne di mantenere la sincronizzazione tra i clock dei diversi dispositivi. Tale sincronizzazione permette di non rieseguire la fase di inizializzazione ma di mantenere l'assegnazione degli slot anche per le comunicazioni successive. Questo terzo stato ha dimensioni superiori rispetto ai due precedenti e costituisce uno dei parametri attraverso il quale sarà possibile sviluppare l'analisi dati. Idle state Lo stato di latenza corrisponde all'intervallo temporale necessario anché il nodo elabori le infor- mazioni ricevute. Questo si interpone tra le fasi e ha dimensioni costanti per tutti i nodi, con un consumo energetico paragonabile a quello dello stato di Waking up, poiché il nodo ha la sola necessità di processare le informazioni attraverso l'utilizzo della propria CPU. 12Come verrà descritto nella sotto-paragrafo Communication phase appartenente a questo paragrafo, lo stato di Slee- ping semplice può essere presente anche nella fase di comunicazioni con lo stesso ruolo che presenta nella fase di Data Initialization. Nella Fig.6 si è preferito riportare il caso in cui quest'eventualità non sia vericata. 24
  • 35. Receiving state Questo stato rappresenta il tempo speso dai dispositivi nell'ascolto del canale di comunicazione. Il suo intervallo d'esecuzione standard copre l'intero slot ma può ridursi nel caso di ricezione, interrom- pendosi una volta che si è ottenuto un pacchetto. Il consumo previsto è elevato poiché lo stato richiede l'attivazione della ricetrasmittente e l'ascolto del canale per un tempo prolungato. Transmitting state Lo stato di trasmissione prevede l'inoltro di un pacchetto a tutti i dispositivi posti all'interno del raggio di copertura della trasmittente del nodo. Le dimensioni dello stato sono inferiori rispetto a quelle degli stati precedenti, mentre la dissipazione d'energia è elevata e risulta paragonabile a quella dello stato di ricezione. Analisi delle fasi Discovery phase La fase di Discovery è la prima che caratterizza la vita dei nodi. Essa è gestita attraverso l'alternanza di stati di ricezione e stati di trasmissione e non prevede, in prima analisi, intervalli di dormienza e risveglio. Le sua attività consistono nello scambio di informazioni sulla struttura della rete, al ne di deter- minare quali nodi dovranno eseguire il re-inoltro del pacchetto. La fase prevede, dunque, la modica della topologia in una struttura ad albero in cui i percorsi ridondanti vengono omessi. I collegamenti da preservare vengono decisi in maniera causale dai nodi; difatti, quando un nodo si rende conto di ricevere lo stesso pacchetto da più dispositivi decide quale collegamento preservare, semplicemente ignorando i pacchetti trasmessigli dagli altri 13. Ogni nodo (diverso dal nodo master) è, quindi, posto in contatto con un unico dispositivo preposto a fornirgli l'informazione desiderata e può o meno essere collegato a dispositivi a cui eseguire il re-inoltro. Questa tecnica di creazione dell'albero di trasmissione implica che a seguito della disattivazione di un nodo la topologia non possa sfruttare direttamente i percorsi alternativi (quando esistenti) ma necessiti dell'esecuzione di una nuova fase di Discovery prima di garantire il proseguimento delle co- municazioni. L'intera fase è organizzata in blocchi: per ogni blocco, tutti i nodi mantengono lo stato di ricezione e, se necessario, possono scegliere randomicamente uno slot in cui trasmettere l'informazione di discovery. L'inizio della fase dipende dal livello a cui è posizionato il nodo ed è avviata dal nodo master. Dunque, all'aumentare degli hop di distanza da quest'ultimo, i nodi slave iniziano la fase con ritardi crescenti. Questa fase subisce lievi variazioni in dipendenza alla categoria del nodo considerato. In particolare la Fig. 6 riguarda la fase di discovery del nodo master. 13Il problema della creazione dell'albero non è stato approfondito al ne di questa tesi; si può però supporre che ogni pacchetto contenga un header identicativo del nodo trasmittente e che, in realtà, i dispositivi continuino a ricevere tutti i pacchetti trasmessi dai nodi limitro ma decidano di portare a termine solo la ricezione dei pacchetti contenenti lo header scelto, scartando gli altri non appena decodicato il mittente. 25
  • 36. Con riferimento alle Fig. 7a e 7b mettiamo in evidenza anche l'esecuzione di questa fase da parte di due nodi slaves posti in congurazioni diverse. (a) Serie (b) Stella Figura 7: Discovery phase Si può notare come in entrambe le gure i nodi slave (S1 e S2) presentino un iniziale periodo di ricezione continuata, detto Listening, in cui i nodi vanno in ricezione a intervalli regolari, in attesa di messaggi dal nodo master o dai nodi di livelli superiori. Una volta recepita l'informazione, questi entrano in uno stato di dormienza, seguito da uno risveglio, sviluppati appositamente per permettere la coordinazione all'istante d'accesso al nuovo blocco del nodo M (master). In entrambe le congurazioni a seguito della corretta ricezione del pacchetto d'avvio i nodi proseguo- no nell'eettiva attività di Discovery della rete, trasmettendo un pacchetto contenente le informazioni relative alla loro posizione e al loro ruolo rispetto alla topologia. La Fig. 7a rappresenta una rete di tre nodi in serie. Si può notare come il nodo S1 dopo aver ottenuto l'informazione dal nodo M entri in fase di dormienza, mentre il nodo S2 mantenga la fase di ricezione sino all'intervento di un istante di timeout. Tale istante è presente al ne di limitare la dissipazione di energia a seguito di stati di ricezione troppo lunghi che non prevedono la ricezione eettiva di pacchetti. Al termine dell'intervallo di dormienza che segue il timeout, il nodo riprende la fase di listening; se S2 non avesse ricevuto il pacchetto neanche nel secondo intervallo si sarebbe proseguito alternando periodi di dormienza e periodi di ricezione sino alla arrivo di questo o all'esaurimento delle batte- rie di S2. Osserviamo, inoltre, che se la fase di Discovery del nodo S1 termina prima che il nodo S2 riceva il pacchetto e si attivi, S2 continuerebbe l'attività di listening e non verrebbe mai identi- cato dagli altri nodi della rete. Per questa ragione risulta molto importante la stima del numero di blocchi che vanno a formare questa fase, specie nel caso di reti complesse, costituite da numerosi livelli. 26
  • 37. La Fig. 7b, invece, rappresenta una topologia a stella di tre nodi. In questo caso S1 e S2 ricevono l'informazione dal nodo M prima che intervenga il timeout. Si conclude sottolineando due elementi di questa fase: Il primo è che il consumo risulta essere molto elevato e che la sua lunghezza, stimabile attraverso il numero di blocchi, è in parte gestita dal programma di ottimizzazione e in parte dipendente dall'istante d'attivazione di ogni nodo. Il secondo è che l'attivazione successiva dei nodi provoca uno scoordinamento generale dal punto di vista del numero dei blocchi; infatti, rispetto al nodo master, i nodi slaves niranno la fase di Discovery con un ritardo pari al numero di blocchi eseguiti in modalità di ricezione continuata. Data Initialization phase La fase di inizializzazione è stata denita allo scopo di garantire l'allocazione di una risorsa a ogni nodo che presenta necessità di trasferire dati. In secondo luogo questa fase ha anche la nalità di determinare il ritardo tra i nodi in modo da stabilire il corretto coordinamento per la fase successiva. Come osservabile in Fig. 6 la Data Initialization phase prevede l'alternanza ssa di quattro stati occupanti le dimensioni totali di un blocco. Lo stato di dormienza, come già fatto notare nel sotto- paragrafo Sleeping state, adatta le proprie dimensioni in funzione alle necessità di trasmissione o ricezione dei nodi. Le risorse vengono assegnate a partire dal master, il quale mantiene costante lo slot di trasmissione per tutta la fase. I nodi slave che hanno bisogno di trasmettere eseguono la trasmissione in uno slot randomico e interno al blocco. Se la termine del blocco il nodo slave ha ricevuto il pacchetto d'ini- zializzazione dal nodo master (o dal nodo di livello superiore) allora decide di mantenere quello slot per tutte le comunicazioni successive. Se, invece, il nodo non riceve il pacchetto, allora cambia slot di trasmissione, supponendo che il proprio pacchetto abbia generato collisione con quello del master (o dei nodi superiori). Le immagini in Fig. 8 riproducono la fase di inizializzazione delle risorse attraverso lo studio di due diverse topologie: la serie composta da tre nodi Fig. 8a e la stella composta da tre nodi Fig. 8b. Notiamo nuovamente come la Fig. 6 fosse solo espressione dell'attività d'inizializzazione del nodo master (M) e non rispecchiasse quella dei nodi slaves (S1 e S2). 27
  • 38. (a) Serie (b) Stella Figura 8: Data Initialization phase Con riferimento alla Fig. 8a osserviamo allora come, tra i vari nodi, l'inizio della fase non sia coordinato ma abbia un ritardo pari a quello accumulato nella fase di Discovery. Una volta che la fase di Data Initialization ha inizio, i nodi slaves assumono uno stato di ricezione continuata che viene interrotto solo nel caso questi debbano propagare l'informazione d'inizializzazione. In questa fase i dispositivi che eseguono trasmissioni sono solo quelli che necessitano l'allocazione di risorse e che dovranno, quindi, inoltrare i dati nella fase di comunicazione. Questa è la ragione per cui S2 non esegue trasmissione ma si limita a mantenere attivo lo stato di ricezione. Il numero di questi blocchi ha sempre il ne di garantire a tutti i nodi interessati la ricezione, pur tenendo conto dei ritardi d'avvio. La Fig. 8b mostra la mancanza di necessità da parte di entrambi i nodi slave di accreditarsi una risorsa e il mantenimento del ritardo acquisito dalla fase di Discovery in coerenza con la Fig. 7b. Come per la fase di Discovery, si ha che a causa dei lunghi periodi di ricezione continuata anche quest'ultima fase risulta essere molto dispendiosa per i dispositivi; inoltre, si induce un ulteriore ritardo sui nodi slave rispetto al master e ai nodi che eseguono il re-inoltro provocando un'altra dilazione temporale prima delle comunicazioni eettive. Communication phase Quest'ultima fase del protocollo è quella che determina il passaggio del pacchetto d'informazione tra i nodi. Essa termina all'esaurimento della batteria di un qualsiasi dispositivo di rete, fornendo la stima di vita della topologia e causando la ripresa dalla fase di Discovery. La Fig. 6 evidenziava come la Communication phase presenti lunghi periodi di dormienza alternati da stati di risveglio e trasmissione individuabili con cadenza costante. 28
  • 39. Osservando ora le gure sottostanti possiamo enfatizzare più nello specico i vari aspetti di questa fase. (a) Serie (b) Stella Figura 9: Communication phase Notiamo innanzitutto i due diversi stati di dormienza: il primo, Coordination Sleeping state, indi- rizzato al coordinamento di tutti i nodi, presenta dimensioni dierenti a seconda del ritardo accumulato dai nodi della rete rispetto al nodo master e permette il risveglio dei dispositivi in maniera coordinata in corrispondenza agli slot assegnati. Il secondo, Synchronization Sleeping state, costituisce tutti gli stati di dormienza successivi e ha dimensioni calibrate sul tempo di de-sincronizzazione dei dispositivi. Difatti, tutte le trasmissioni suc- cessive hanno il solo lo scopo di mantenere la sincronizzazione tra i nodi e sono necessarie a causa delle non idealità delle loro componenti hardware. La Fig. 9a mostra una topologia di tre nodi, disposti in serie, nei primi istanti di sviluppo della fase. Nella prima riga è presentata l'attività del nodo master (M); si vede, quindi, lo stato di dormienza in attesa del coordinamento di tutti i nodi, il risveglio, lo stato di trasmissione e quello di Sleeping prima del comune intervallo di dormienza per sincronizzazione. La mancanza dello stato di ricezione è dovuta al fatto che, secondo il protocollo, il nodo M non ha necessità di ricevere dati dalla rete. L'alternanza delle attività, senza considerare lo stato di dormienza per coordinazione, prosegue poi sino all'esaurimento della batteria. Nella seconda riga osserviamo le attività del nodo S1 e la gestione della necessità di ricevere e poi re-inoltrare il pacchetto. Osserviamo che, poiché l'intervallo di tempo tra ricezione e trasmissione è conosciuto (denito dalla fase di Data Initialization), si ha la possibilità di gestirlo attraverso uno stato di dormienza e risveglio che permetta l'ulteriore ottimizzazione nel consumo della fase. 29
  • 40. S2, invece, non avendo necessità di re-inoltro presenta solo lo stato di ricezione in corrispondenza dello slot di trasmissione di S1. Dalla terza riga vediamo anche che S2 non dispone di un periodo di dormienza per coordinazio- ne 14,contrariamente ai nodi M e S1, poiché risulta essere il nodo con maggiore ritardo nella rete. A seguito dello stato di Idle, infatti, si ha un intervallo di Sleeping dovuto all'ottimizzazione della fase e non alla necessità di coordinazione del nodo. Una situazione simile viene evidenziata nella Fig. 9b dove i nodi slaves non necessitano né di un periodo di coordinamento, essendo loro i nodi con maggiore ritardo nella rete, né di uno stato di trasmissione, non avendo necessità di re-inoltrare i dati ricevuti. Si ottiene quindi che questa rappre- sentazione, descrivente una topologia a stella a tre nodi, se confrontata con quella in Fig. 9a, risulti meno dispendiosa in termini energetici e permetta un leggero anticipo nell'inizio delle comunicazioni. Nel complesso quest'ultima fase presenta un consumo energetico irrisorio se confrontato con quelle precedenti; inoltre costituisce la fase più lunga del ciclo di vita dei dispositivi e, protraendosi sino al loro spegnimento, garantisce la trasmissione coordinata dei pacchetti emessi dal nodo master. Anche per questo protocollo riportiamo il diagramma di usso che cerca di sintetizzarne lo sviluppo delle fasi: 14S2 potrebbe disporre, in realtà, di un intervallo di dormienza per coordinazione in dipendenza all'istante d'attivazione degli altri nodi. Difatti, se il periodo di coordinazione fosse più lungo del necessario allora S2 dovrebbe assumere questo stato per l'intervallo di tempo richiesto. Per semplicità, nell'esposizione è stato assunto che essendo il nodo con maggiore ritardo della rete, questo non generi ulteriore ritardo. 30
  • 41. Figura 10: Protocollo Sincrono - Diagramma di usso 31
  • 42. 2.3 Implementazione software Descriviamo ora la parte più pratica del lavoro, quella cioè che consiste nell'implementazione dei protocolli sotto forma di simulatori e che ha permesso l'estrazione dei risultati relativi all'ecienza di quest'ultimi. 2.3.1 Programma d'ottimizzazione BlockDis(nodi, slot)15 BlockDis(nodi, slot) è il programma realizzato appositamente per ottimizzare le prestazioni dei due protocolli presentati nei paragra precedenti. L'obiettivo di questo programma è fornire il numero di trasmissioni che ogni nodo appartenente a un layer deve compiere al ne di ottenere, con una data probabilità, la corretta ricezione del pacchetto. Layer Insieme di tutti i nodi connessi e aventi distanza massima di un hop l'uno dall'altro. La stima viene eseguita supponendo che tutti i nodi appartenenti al layer abbiano la necessità di co- municare e che non siano coordinati tra loro. Inoltre, dev'essere denito a priori il numero di spazi (slot) in cui ogni nodo ha la possibilità di trasmettere. Il programma prende in input due valori: il numero di nodi costituenti il layer e il numero di slot disponibili per la comunicazione. All'avvio i nodi scelgono in maniera casuale uno slot di trasmissione tra quelli disponibili e per i restanti intervalli mantengono lo stato di ricezione. Il software memorizza in una tabella i pacchetti ricevuti correttamente, ossia quelli che non hanno subito collisioni, associandoli ai nodi che li hanno trasmessi. Se alla prima iterazione non si vericano collisioni, quindi tutti i pacchetti vengono inviati in slot diversi, il programma termina fornendo la stima del numero di iterazioni eseguite (una). Se, invece, alcuni pacchetti (o tutti) subiscono collisioni, il programma riempie solo parzialmente la tabella e prosegue incrementando di un'unità il contatore di iterazioni. A questo punto, ogni nodo sceglie nuovamente uno slot e ritrasmette lo stesso pacchetto inviato in precedenza. La scelta dello slot e la trasmissione del pacchetto viene ripetuta sino a quando tutti i pacchetti sono ricevuti correttamente almeno una volta. A questo punto il programma termina e fornisce in output il numero di iterazioni che è stato ne- cessario eseguire per riempire la tabella. Poiché non è previsto l'utilizzo di acknowledgements anche se la comunicazione di un nodo dovesse avere successo, questo continuerebbe a trasmettere per tutte le iterazioni successive sino al termine del programma, occupando uno slot di trasmissione ed eventualmente causando collisioni. Per avere maggiore sicurezza sulla veridicità dei risultati, per ogni stima viene richiesta al pro- gramma la ricorsione del processo diecimila volte. A ogni esecuzione di BlockDis(nodi, slot) sono 15Il codice MATLAB relativo al programma BlockDis(nodi, slot) e i programmi a contorno utilizzati per ottenere le stime di output sono riportati in Appendice B 32
  • 43. ottenute, quindi, diecimila risposte indicanti il numero di iterazioni eseguite per portare a termine la comunicazione all'interno di un dato layer e con un dato numero di slot. Da questi risultati è possibile estrarre informazioni riguardanti i valori più ricorrenti nelle iterazioni e la distribuzione della probabilità di ricezione da parte dei nodi del layer. Esempio di funzionamento La Fig.11 cerca di chiarire il funzionamento del programma nel caso esemplicativo di cinque nodi e cinque slot. Figura 11: BlockDis(5, 5) La topologia posta sul lato sinistro vuole identicare il layer, mentre l'arbitraria assegnazione dei colori ha il solo scopo di permettere la distinzione dei pacchetti negli slot. Ogni linea orizzontale rappresenta una diversa ricorsione del programma e produce un valore di output. La diversa lunghezza delle ricorsioni è data dal numero di iterazioni che è stato necessario eettuare anché tutti i pacchetti venissero inviati senza incorrere in collisioni. Analizzando la prima riga dell'immagine, Recursion 1, si nota come per ogni iterazione tutti i nodi eseguano la trasmissione. In particolare vediamo che a seguito della prima iterazione l'unico pacchetto a essere stato trasmesso con successo è quello inviato dal nodo N1, mentre tutti gli altri hanno colliso essendo stati inviati nello stesso slot di trasmissione di un altro nodo. Nella seconda iterazione nessun pacchetto è stato trasmesso con successo e si sottolinea l'eetto della mancanza di acknowledgement che ha portato, nel terzo slot, alla collisione tra il pacchetto del nodo N1 e quello di N2, nonostante il pacchetto trasmesso da N1 sia ridondante. Nella terza iterazione i pacchetti di N1, N2 e N5 sono trasmessi senza collisioni. Inne, a seguito della quarta iterazione si ottengono anche i pacchetti trasmessi da N3 e N4 che permettono la conclusione della prima ricorsione col risultato di quattro iterazioni. La Fig.12 mostra, in via graca, gli output ottenuti dal programma. Per completezza, oltre a quelli del programma BlockDis(5, 5) (linee rosse), sono stati rappresentati negli stessi graci tre ulteriori output derivanti dall'incremento o il decremento del numero di slot. In questo modo si cerca di evidenziare la dipendenza del numero di iterazioni dalla quantità di slot disponibili. 33
  • 44. In particolare sono stati aggiunti gli output ottenuti da BlockDis(5, 3) (linea azzurra), BlockDis(5, 10) (linea gialla) e BlockDis(5, 30) (linea viola). (a) Distribuzione delle iterazioni (b) Densità di probabilità cumulata Figura 12: BlockDis(nodi, slot) - output La Fig.12a rappresenta la distribuzione dei risultati delle ricorsioni, dove in ordinata vi è il numero di volte in cui il programma ha terminato la ricorsione avendo come output il valore espresso in ascissa. Normalizzando l'asse delle ordinate si ottiene la classica distribuzione di probabilità. Facciamo notare che il valore delle ordinate parte da zero mentre quello delle ascisse inizia da uno poiché al valore di zero iterazioni la rappresentazione perde di senso. Le quattro curve mostrano come la distribuzione vari in funzione al numero di slot, aumentando il proprio valore medio al diminuire di quest'ultimo. La Fig.12b mostra, invece, la densità di probabilità cumulata. In ordinata è posta la probabilità di corretta ricezione di tutti i pacchetti da parte dei nodi del layer, mentre in ascissa vi è ancora il numero di iterazioni d'invio (iniziante da uno). Dai graci proposti, quando il ne è quello di minimizzare il numero di iterazioni, appare evidente la maggior ecienza del layer che dispone di un numero superiore di slot; ma se si considera invece il problema di minimizzare il numero di slot utilizzati, le considerazioni cambiano. Riportiamo nella tabella sottostante i risultati estratti dagli output precedenti, richiedendo una probabilità di corretta ricezione maggiore o uguale allo 0.995: Slot per layer Iterazioni necessarie Slot totali 3 34 102 5 14 70 10 7 70 30 4 120 Tabella 2: Totale slot per corretta ricezione Vediamo, quindi, che seppur il numero di iterazioni si abbassa al crescere degli slot per layer, il 34
  • 45. numero di slot totali presenta il minimo 16 all'interno dell'intervallo compreso tra tre e trenta slot per layer. Questa precisazione risulta di notevole importanza per l'ottimizzazione dei protocolli dove il numero totale di slot inuisce sulla longevità della rete. Utilizzo nei protocolli Il programma d'ottimizzazione viene utilizzato in entrambi i protocolli presentati nei paragra pre- cedenti allo scopo di massimizzare la longevità delle reti e di assicurare una probabilità di corretta ricezione dei pacchetti superiore allo 0.995. Nel caso del protocollo Asincrono il programma d'ottimizzazione permette di ottenere la stima riguardante il numero di ripetizioni dei periodi contenenti il burst di trasmissione. Tale stima dovrebbe essere fatta singolarmente per ogni nodo ma poiché in questo protocollo la topologia non è nota si deve considerare ogni layer come composto da tutti i nodi costituenti la rete e in funzione di questo numero denire la stima dei periodi di ritrasmissione. In sostanza è necessa- rio assumere il caso in cui tutti i nodi siano posti a distanza di un hop e abbiano necessità di comunicare. Nel caso del protocollo Sincrono, invece, il programma viene applicato in due frangenti distinti: Il primo riguarda la Discovery phase, dove i nodi hanno necessità di comunicare tra loro per deter- minare la topologia, quindi, come nel caso del protocollo Asincrono, il programma dovrà considerare ogni layer come composto da tutti i nodi di rete, con l'unica dierenza data dal fatto che ora si parla dell'iterazione di blocchi di trasmissione e non più di periodi. Il secondo frangente riguarda la fase di Data Initialization, nella quale i nodi conoscono la topologia e attendono l'assegnazione dello slot di trasmissione. In questa fase i layer fanno specico riferimento al singolo nodo e sono di dimensioni minori o al più uguali a quelli stimati per la fase di Discovery 17. 2.3.2 Simulatori Vediamo ora l'implementazione software dei protocolli descritti nei Paragra 2.2.1 e 2.2.2. La descrizione dei simulatori verrà svolta attraverso l'analisi di un esempio al ne di poter fornire esplicitamente i dati e poterli vericare attraverso la visione delle immagini. Tutte le immagini saranno strutturate in righe, ognuna delle quali rappresenterà le attività di un nodo allo scorrere del tempo. Assegniamo, dunque, le caratteristiche comuni all'esecuzione dei protocolli: Consideriamo la rete di Fig.13 composta da quattro nodi, dove il nodo M rappresenta il master, i nodi S1, S2 e S3 gli slaves e le frecce i range di trasmissione e ricezione. 16La funzione ha forma parabolica e poiché le ricorsioni eseguite dal programma sono in numero nito non è possibile denire con esattezza il valore per cui la curva presenta il minimo assoluto ma è solo possibile stimarne un ragionevole intorno. 17Le motivazioni che portano alle diverse dimensioni dei layer tra la fase di Discovery e quella di Data Initialization vengono approfondita all'interno del Paragrafo 2.3.2, nel sotto-paragrafo Protocollo Sincrono 35
  • 46. Figura 13: Rete a quattro nodi Supponiamo poi che il numero di blocchi costituenti un periodo del protocollo Asincrono sia uguale al numero di slot costituenti un blocco del protocollo Sincrono e stimiamo questo valore in sei 18 blocchi per periodo e quindi sei slot per blocco. Analizziamo ora individualmente lo sviluppo dei due simulatori. Simulatore Asincrono Le immagini della Fig.14 mostrano in sequenza tutti i diversi stadi del simulatore 19. (a) Fase iniziale e primo periodo (b) secondo periodo (c) Quarto periodo (d) Quinto periodo Figura 14: Simulatore Asincrono 18La decisione presa sul numero di blocchi per periodo e il fatto di porli uguale al numero di slot per blocco è del tutto arbitraria e solo a titolo esemplicativo. 19Le immagini sono state prese a seguito di iterazioni successive del programma, poiché esso permette il calcolo e la visualizzazione di un periodo alla volta. Ciò spiega i cambiamenti nella de-coordinazione dei nodi da un'immagine all'altra. 36
  • 47. La prima immagine, Fig.14a, mostra l'intervallo di risveglio e il primo periodo di vita dei nodi. Il risveglio è proprio ciò che determina lo scoordinamento dei dispositivi di rete ed è individuabile nell'iniziale zona verde. Successivamente ha inizio il primo periodo in cui il nodo Master trasmette il burst di dati. Essendo consapevole del proprio ruolo e di essere l'unico in possesso dell'informazione, questo dispositivo non eseguirà ulteriori trasmissioni, poiché il canale è supposto essere senza perdite e non vi è alcun rischio di collisioni. Ponendo attenzione alla gura si può vedere che solo i nodi S1 e S2 ricevono il pacchetto interrom- pendo anticipatamente il periodo di ricezione, mentre il nodo S3 prosegue nell'alternanza dei suoi stati poiché posto oltre al raggio di trasmissione del nodo M. La Fig.14b mostra il secondo periodo di comunicazione della rete. In questa fase i nodi S1 e S2 hanno ricevuto il pacchetto e devono occuparsi di ritrasmetterlo ai dispositivi sottostanti. Ricordiamo che i nodi non sono a conoscenza della topologia ma conoscono solo il numero totale dei suoi componenti. Si ha quindi che sia S1 che S2 provvederanno a ritrasmettere i dati sotto forma di burst per un numero di periodi dato da BlockDis(2, 6), ossia per tre periodi consecutivi. I valori in input a BlockDis(nodi, slot) sono: 2 per il numero di nodi e 6 per il numero di blocchi. Mentre il valore 6 è ovvio poiché fornito come dato iniziale, il valore 2 viene scelto considerando il numero di nodi concorrenti alla trasmissione e che potrebbero causare collisioni. Poiché la topologia è composta da quattro nodi di cui un master (che sicuramente non genererà collisioni), considerando di avere almeno uno slave a cui dover trasmettere, resta la possibilità di avere al più due nodi invianti in concomitanza; da cui il valore 2 in input per il numero di nodi costituenti il layer di trasmissione. I nodi S1 e S2 ripeteranno il burst per tre volte, ma facciamo notare che per S1 la trasmissione è solo uno spreco d'energia, dal momento che nessun altro nodo slave può riceverla. Per ciò che riguarda S2, invece, sarebbe bastata una sola trasmissione del burst al ne di passare con successo l'informazione al nodo S3. Osservando, inne, le righe M e S3 si vede come il Master riceva sia il pacchetto di S1 che quello di S2, anticipando così lo stato di dormienza ma non ricevendo informazioni utili, mentre S3 riceva solo il pacchetto da parte del nodo S2. La terza immagine, Fig.14c, rappresenta l'esecuzione del quarto periodo (similmente si è avuto per il terzo). In questo frangente i nodi S1 e S2 si trovano alla terza e ultima iterazione del burst, mentre il nodo S3 sta eseguendo la seconda. Di quest'immagine sottolineiamo la mancata ricezione, da parte del nodo S2, del pacchetto tra- smesso da S3. Quest'eventualità, dovuta al dimensionamento del burst, non è stata trattata nella presentazione del protocollo Asincrono poiché risulta ininuente ai ni della trasmissione del pacchet- to nella rete, infatti, il nodo S2 possiede già le informazioni trasmesse da S3 e la mancata ricezione non apporta modiche nel suo stato. 37
  • 48. Concludiamo la descrizione del simulatore Asincrono con la Fig.14d che riproduce l'ultimo periodo di trasmissione del nodo S3. A seguito di questo periodo tutti i nodi proseguiranno alternando stati di dormienza a stati di ricezione, in attesa che il master invii un altro burst di pacchetti da inoltrare a tutta la rete. Evidenziamo come il re-inoltro eseguito da S3 abbia tenuto conto delle stesse considerazioni fatte per S1 e S2, infatti, S3 non poteva essere a conoscenza di non avere necessità di trasmettere il pacchetto ma ha dovuto per di più considerare l'ottimizzazione e rieseguire il burst per tre periodi di la. Simulatore Sincrono Vediamo adesso lo sviluppo delle comunicazioni attraverso l'implementazione del protocollo Sincrono. Ricordiamo che la topologia di riferimento è quella in Fig.13 e che ogni blocco è composto da sei slot d'attività. (a) Discovery phase (b) Data initialization phase (c) Communication phase Figura 15: Simulatore Sincrono Iniziamo l'analisi dalla Fig.15a, ragurante la fase di Discovery, e calcoliamo il numero di blocchi necessari alla trasmissione di ogni nodo. In relazione al nodo master si devono tenere in considerazione due aspetti: Il primo riguarda il tempo d'attivazione dei nodi slave posti a un hop di distanza (S1 e S2). Difatti, i nodi si svegliano presentando ritardi tra loro, quindi può accadere che il primo pacchetto trasmesso dal nodo master non sia suciente a risvegliare tutti i membri del layer. Per questa ragione si devono riservare almeno due blocchi per l'attivazione. 38