dati.
Sono stati pubblicati due diversi protocolli per la segnalazione della presenza in ascolto. Il primo, chiamato semplicemente Low Power Probing (LPP) [13], utilizza il meccanismo che consente di svegliarsi ad una sola sezione della rete. Il protocollo RI-MAC [14] è sviluppato come un protocollo MAC completa- mente funzionale basato sulla stessa idea dell’LPP. Sebbene i due protocolli siano stati pubblicati uno dopo l’altro, sono comunque stati sviluppati in modo indipendente.
2.2.3 Il protocollo RDC utilizzato
Contiki fornisce tre protocolli per gestire il Cycling radio a livello MAC: il protocollo ContikiMAC, Contiki X-MAC e Contiki LPP. ContikiMAC [15] è un protocollo basato sull’ascolto a bassa potenza con un’efficienza in termini di consumo energetico molto elevata. Il Contiki X-MAC si basa sul protocollo X- MAC originale, ma con un insieme significativo di miglioramenti ed estensioni. Il Contiki LPP si basa sulle stesse idee come l’originale LPP e RI-MAC, ma con una serie di modifiche.
In entrambi i protocolli X-MAC e LPP, i nodi si svegliano periodicamente in previsione di un potenziale pacchetto in arrivo. Il periodo di wake-up è fisso, ma i nodi non sono sincronizzati. Pertanto, vi è uno sfasamento tra tutti i nodi adiacenti. Utilizzando le informazioni per la sincronizzazione fra vicini, è possibile risparmiare energia quando è necessario l’invio di pacchetti. Sia il Contiki X-MAC che il Contiki LPP fanno uso di questa fase di allineamento. Sia il Contiki X-MAC che il Contiki LPP forniscono una funzionalità di streaming in cui i pacchetti possono essere contrassegnati con un flag che indica se si tratta di un flusso. I pacchetti contrassegnati con il flag flusso fanno parte di un gruppo di dati con priorità superiore, e il livello MAC li tratta in modo diverso rispetto ad altri.
2.3 Il livello di adattamento 6LowPAN
6LoWPAN [16] è stato progettato per adeguare i pacchetti IPv6 al trasporto tramite IEEE 802.15.4 e rispondere alle seguenti esigenze, tipiche del mondo dell’IoT:
• i dispositivi hanno limitata energia e devono gestire il duty-cycle, mentre IP presuppone che i device siano sempre attivi;
• le tecnologie wireless, come IEEE 802.15.4, non supportano il multica- st, molto importante per alcune caratteristiche di IPv6, l’alternativa del flooding consuma energia e banda;
• le applicazioni dei dispositivi wireless nell’IoT beneficiano del multihop mesh networking, difficilmente integrabile con le normali soluzioni di routing IP;
• le tecnologie radio utilizzate dai sensori wireless hanno una banda limitata e un frame di dimensioni ridotte, ad esempio IEEE 802.15.4 ha un frame di 127 byte, con payload disponibile nel range tra 72 e 116 byte mentre IPv6 prevede un frame di dimensioni di 1280 byte;
• i protocolli standard non sono ottimizzati per reti wireless a bassa po- tenza, nelle quali può verificarsi la caduta di un nodo per failure o per esaurimento dell’energia.
La creazione di uno standard per il trasporto di IPv6 nelle reti di sensori wireless ha permesso di ridurre al minimo i prerequisiti e la riprogettazione di protocolli come quelli utilizzati per il Neighbor Discovery (ND) consentendo di mantenere inalterate le caratteristiche peculiari di tali reti.
Alcuni concetti di 6LoWPAN sono strettamente legati alle funzione del link- layer, come ad esempio il PAN ID nella gestione dell’indirizzamento, ma il gruppo di lavoro sul 6LoWPAN ha voluto mantenere un livello di generalità, evitando di utilizzare tutte le caratteristiche peculiari del livello IEEE 802.15.4. Le ridotte funzionalità richieste al MAC layer sottostante permetteranno di applicare 6LoWPAN anche in futuro ad un range di nuove tecnologie.
L’adaptation-layer realizza tre compiti fondamentali:
• gestisce la frammentazione/deframmentazione dei pacchetti IP; • realizza la compressione degli header;
• gestisce l’inoltro dei pacchetti quando si utilizza il multi-hoping a livello due (questa funzionalità nel nostro caso non ci interessa perché la gestione del routing avviene a livello tre).
Il protocollo 6LoWPAN definisce quello che viene chiamato encapsulation hea- der stack che precede ogni datagramma IPv6. L’encapsulation header stack di 6LoWPAN è costituito da tre diversi header: Mesh addr header, Fragmenta- tion header e IPv6 header compression; quando presenti compaiono nell’ordine riportato in Fig. 2.1.
La frammentazione del pacchetto IP viene richiesta all’adaptation-layer quan- do il pacchetto IP non entra nella MTU prevista da 802.15.4; in tal caso il pacchetto IP (datagramma) viene spezzato in più link-frame, tali link-frame
2.3 Il livello di adattamento 6LowPAN
Figura 2.1: L’encapsulation header stack come previsto da 6LoWPAN; la parte Mesh addr introdotta da 6LoWPAN si riferisce al caso in cui il rou- ting avvenga a livello Data-Link; nel nostro caso il routing avviene a livello Network
sono preceduti da particolari header il cui modello è riportato in Fig. 2.2. Il primo frammento non contiene il campo datagram_offset, mentre gli altri lo contengono tutti. Descriviamo molto rapidamente i campi del Fragmentation header di 6LoWPAN:
• datagram_size: campo di 11-bits, esprime la lunghezza del datagram- ma IPv6 originale. Tale campo è contenuto solo nel primo frammento dell’intero pacchetto;
• datagram_tag: viene utilizzato per indicare univocamente un datagram- ma, tale campo è uguale in tutti i frame che appartengono allo stesso datagramma IPv6;
• datagram_offset: è un campo ad 8-bit, è contenuto in tutti i frammenti data-link appartenenti allo stesso datagram IPv6, eccetto che nel primo frame. Serve ad indicare la posizione di un frame all’interno dello stesso datagram.
6LoWPAN prevede, inoltre, l’esistenza di un timer che viene avviato alla ricezione del primo frame di un determinato datagram, tale timer può avere
Figura 2.2: Struttura del Fragmentation Header del primo frammento e dei successivi
durata massima 60 secondi, se allo scadere del timer non si hanno tutti i frame il datagram viene scartato.