Lo stack di rete wireless MiWi

Analizziamo in questo articolo una soluzione semplice e a basso costo per connettività wireless short-range.

Sempre più applicazioni richiedono connettività wireless a corto raggio e sempre più dispositivi e microcontrollori embedded dispongono oggi di periferiche RF a tale scopo. Sebbene esistano protocolli standard, tuttavia, talvolta questi possono risultare troppo complessi per la propria applicazione o prevedere funzionalità non strettamente necessarie, implicando un inutile spreco di risorse. In questi casi può risultare utile disporre di soluzioni specifiche. MiWi Mesh (Figura 1) di Microchip è una di queste. Caratteristiche fondamentali di tale stack sono:

il supporto per tutti i dispositivi e transceiver RF di Microchip;
la portabilità tra differenti famiglie di CPU;
l’indipendenza dal sistema operativo;
la disponibilità di API di semplice adozione.

Figura 1: lo stack MiWi di Microchip, alternativa semplice e low-cost a protocolli standard di connettività wireless

CARATTERISTICHE GENERALI E TOPOLOGIA DI RETE

Il protocollo MiWi è basato sui livelli MAC e PHY dello standard IEEE 802.15.4 su cui poggiano anche gli standard ZigBee, ISA100.11a e WirelessHART. Esso è orientato alla realizzazione di reti LR-WPAN (Low bit Rate Wireless Personal Area Network) operanti nella banda ISM a 2.4 GHz (o al di sotto). Lo stack fornisce le funzionalità di formazione della rete, ricerca e connessione a una rete esistente, ricerca di nodi all’interno della stessa. Non sono invece coperti tutti gli aspetti specifici del livello applicativo. Il protocollo consente la realizzazione di reti fino a 1024 nodi (genericamente indicati come End Device) strutturati in cluster e controllati da un PAN coordinator che svolge le funzionalità di formazione della rete, allocazione degli indirizzi e gestione della tabella di connessione. Utilizzando la nomenclatura IEEE 802.15.4 si può dire che il PAN Coordinator è un nodo di tipo FFD (Full Function Device) mentre gli End Device sono di tipo FFD o RFD (Reduced Functin Device).

I dispositivi FFD, in particolare, dispongono di quasi tutti i servizi offerti dal protocollo IEEE 802.15.4, sono tipicamente alimentati da rete primaria e dispongono di ricevitore RF attivo in modalità idle. I nodi RFD hanno, invece, funzionalità limitata, alimentazione a batteria e non sono in grado di ricevere messaggi in modalità idle. Sono supportate reti con configurazione a stella, ad albero e di tipo mesh. Nel primo caso la comunicazione avviene esclusivamente tra PAN Coordinator ed End Device; se due End Device devono scambiare dati, quindi, questi devono prima essere inviati al PAN Coordinator che provvede a instradarli alla destinazione. Nella configurazione ad albero, invece, i nodi sono organizzati in cluster e questi sono connessi tra loro mediante speciali dispositivi che assumo il ruolo di Coordinator del singolo cluster; la configurazione per lo scambio di dati è di tipo multi-hop e l’instradamento del messaggio deve seguire la struttura dell’albero.

Analoga connettività multi-hop si ha nella topologia mesh (Figura 2) dove, tuttavia, i nodi di tipo FFD possono comunicare direttamente tra loro, indipendentemente dalla posizione nella gerarchia delle rete; la comunicazione tra RFD, invece, deve avvenire sempre mediante i nodi Coordinator parenti. Indipendentemente dalla topologia di rete, la comunicazione per una rete MiWi è di tipo non-beacon; tutti i nodi, ovvero, sono abilitati a trasmettere a ogni istante, a patto che il canale di trasmissione sia in quell’istante idle. Nelle reti beaconed, invece, il Coordinator invia un messaggio di sincronizzazione di frame al quale sono agganciati tutti gli End Point; questi sono abilitati a trasmettere sul canale soltanto in intervalli temporali predefiniti a loro riservati.

Figura 2: lo stack MiWi supporta una topologia di rete di tipo mesh

MODALITÀ DI INDIRIZZAMENTO DEI NODI

L’indirizzamento dei nodi sulla rete MiWi è quello previsto dal protocollo di base IEEE 802.15.4. In particolare, del campo Short Address previsto dalla citata specifica, il protocollo MiWi utilizza i primi 7 bit (meno significativi) per definire l’indirizzo Child del nodo stesso, e i successivi 3 bit per indicare quello del Coordinator del cluster a cui il nodo appartiene. Come si vede, attualmente sono quindi possibili soltanto 8 cluster all’interno di una rete MiWi. L’indirizzo di Child 0x00 è riservato e serve per segnalare al nodo che deve operare come Coordinator del cluster. L’indirizzo Short consente di definire sorgente e destinazione della comunicazione sulla rete MiWi. Oltre a esso sono poi definiti, come stabilito anche dallo standard IEEE 802.15.4, gli indirizzi PANID, per l’identificazione della rete, e EUI, associato invece univocamente a ogni dispositivo.

DIVERSI TIPI DI MESSAGGI

In una rete MiWi, i dati sono scambiati mediante pacchetti il cui formato, ancora un volta, è in accordo alla specifica IEEE 802.15.4. Sul livello MAC definito da questo, lo stack MiWi definisce il proprio protocollo introducendo un header (Figura 3) che include le informazioni necessarie al routing del messaggio sulla rete.

Figura 3: struttura dell’header dei messaggi MiWi

Queste comprendono l’indirizzo Short dei nodi sorgente e destinazione, l’ID della rete PAN di entrambi, un Sequence Number utilizzato per tracciare il messaggio lungo la sua trasmissione, oltre a un campo di controllo di frame e uno che abilita la trasmissione del pacchetto mediante hop. Il controllo di frame aggiunge informazioni accessorie, come ad esempio l’adozione di una codifica a livello applicativo del messaggio e la richiesta di acknowledge della corretta ricezione. Vi è, inoltre, il campo con l’identificativo del tipo di messaggio. Lo standard, infatti, ne prevede fino a 256 diversi tipi, chiamati anche Report. Nell’implementazione corrente, 10 identificativi sono riservati per Report necessari alla gestione dello stack mentre i restanti sono disponibili per l’applicazione utente.

Tra quelli riservati vi sono evidentemente i messaggi di base dello stack, come, ad esempio, i Report per l’acknowledge della corretta ricezione di un pacchetto, per la richiesta di hop del canale di trasmissione wireless correntemente adottato (tale messaggio può essere inviato soltanto dal PAN Coordinator della rete) e per la risincronizzazione di un nodo RFD al risveglio dallo stato di sleep o ibernazione. Ma vi sono anche tipi di messaggi per funzionalità avanzate. Ne esiste uno, ad esempio, che consente di ricercare all’interno delle diverse reti rilevate un certo nodo, in funzione del suo EUI univoco. Ciò è utile in uno scenario in cui due nodi sono in comunicazione ma, per qualche motivo, a un tratto, uno dei due cambia la rete di appartenenza (perché in mobilità). Cambierà di conseguenza anche il suo Short Address (essendo assegnato dal PAN Coordinator della rete cui il dispositivo è connesso), con il risultato che i nodi non saranno più in grado di comunicare sulla base delle vecchie credenziali di accesso. La possibilità di ricercare sulla rete il nodo in funzione del suo identificativo nativo univoco consente di ristabilire la connessione. Oltre a questo, vi sono poi i messaggi specifici che consentono di creare connessioni dinamiche tra due nodi, senza una necessaria conoscenza della specifica topologia di rete; si parla in questo caso di connessioni indirette.

UN SEMPLICE SCHEMA DI ROUTING

Come anticipato, in una rete MiWi il routing del messaggio viene realizzato sulla base delle informazioni contenute nell’header e della conoscenza della topologia di rete presente. Per costruire la tabella di routing, lo stack prevede il seguente meccanismo: ogni volta che un nodo si connette alla rete invia un messaggio di beacon; tutti i nodi di tipo Coordinator che ricevono tale messaggio inviano a loro volta una risposta, all’interno della quale segnalano la propria conoscenza della configurazione di rete utilizzando, in particolare, il campo Local Coordinators del messaggio. Tale campo ha la dimensione di un byte e ogni bit di questo indica se il corrispondente Coordinator della rete (si ricordi che ne sono consentiti al massimo 8 dall’attuale implementazione dello standard) è da esso stesso visibile. Note tali informazioni, l’instradamento del messaggio può seguire lo schema di principio mostrato in Figura 4.

Figura 4: un semplice algoritmo di routing dei messaggi in una rete MiWi

UN AMBIENTE DI SVILUPPO INTEGRATO

Il codice sorgente dello stack MiWi è disponibile pubblicamente sul web all’indirizzo indicato al riferimento [1] e può essere usato come punto di partenza per estensioni specifiche della propria applicazione. Esso è incluso nell’ambiente di sviluppo MiWi Development Environment che fa parte delle Microchip Applications Libraries (MAL). La versione presentata in questo articolo è quella Mesh ma è disponibile anche un adattamento per reti P2P. Wireless Development Studio (Figura 5) è la GUI utente in ambiente Java per la configurazione della libreria MiWi mediante interfaccia grafica. Essa include anche uno sniffer di protocollo utile per il monitoraggio del traffico sulla rete e il debug di quest’ultima.