Entra nel mondo IoT con LoRaWAN

Il protocollo LoRaWAN consente di creare nel modo più semplice reti wireless per l’IoT collegando milioni di dispositivi remoti al cloud.

Un requisito fondamentale per Internet of Things (IoT) è il supporto per la comunicazione, indipendentemente da dove si trovi un nodo finale. Che si trovi in una cantina dell’area urbana o in una tubatura lungo una strada o una ferrovia, il dispositivo deve essere in grado di riportare il suo stato ai server remoti e ricevere comandi. La difficoltà di disporre i cavi in ogni posizione rende la comunicazione wireless praticamente obbligatoria per i dispositivi IoT.  E, a meno che non siano utilizzati molti gateway locali per inoltrare le comunicazioni, il supporto wireless a lunga distanza è essenziale. Ecco perché LoRaWAN è diventato una scelta ovvia per le comunicazioni IoT. Offre infatti un protocollo per applicazioni di sensori a basso traffico dati, basso consumo, basso costo ma a lungo raggio di portata, adatto ad una moltitudine di mercati verticali. Grazie a queste caratteristiche, oggi ci sono già milioni di nodi finali abilitati LoRaWAN in uso.

Molti fornitori hanno già dispositivi che attualmente non beneficiano di comunicazioni IoT. LoRaWAN offre a questi fornitori un modo relativamente semplice per portare nuove versioni di tali dispositivi nell’IoT. Nonostante l’enorme aggiornamento di funzionalità offerto da LoRaWAN, non vengono richieste importanti modifiche relative al core dell’architettura di un dispositivo di nodo sensore esistente. Ma per massimizzare la durata della batteria e la portata wireless utile, alcune semplici strategie di progettazione saranno molto di aiuto.

Come protocollo radio, che deve coesistere con altri sistemi che potrebbero dover utilizzare le stesse bande di frequenze radio senza licenza, LoRaWAN utilizza la tecnologia a spettro esteso. Tuttavia, non impiega  direct-sequenced spread-spectrum (DSSS) presente in altri protocolli. Per i sistemi con limitazioni di costi e dimensioni, un problema con DSSS è che richiede un clock di riferimento estremamente preciso. LoRaWAN sostituisce DSSS con la tecnologia chirp spread-spectrum (CSS), che elimina la necessità di un clock così preciso.

Figura 1 – Esempio di segnale Chirp per LoRaWan.

Il segnale chirp varia in frequenza nell’arco della sua durata ed ha trovato applicazioni nella progettazione di radio grazie ai bassi requisiti di potenza di trasmissione e alla robustezza intrinseca dei meccanismi di degradazione dei canali come multipath, fading, distorsione Doppler e interferenze. Attraverso l’uso di spread-spectrum modulation, in cui i bit di informazione sono codificati in modo capillare su più codici trasmessi, LoRaWAN offre un compromesso ottimizzato per la potenza rispetto alla velocità dei dati e alla larghezza di banda, attraverso l’uso di diversi fattori di diffusione. Ad esempio, un sensore posizionato vicino ad un gateway dovrebbe essere trasmesso ad un più basso fattore spread, in quanto per un elevato livello di collegamento il requisito è piccolo. Tuttavia, per un sensore situato a 10 km da un gateway potrebbe essere necessario trasmettere con un fattore di diffusione molto più elevato, che ridurrà la quantità di dati che è possibile inviare in un determinato periodo. Il compromesso garantisce che i pacchetti abbiano una maggiore probabilità di essere ricevuti correttamente in un’ampia varietà di condizioni e consente una maggiore flessibilità nel circuito RF e nella progettazione dell’antenna. Con LoRaWAN, tutte le comunicazioni sono tra nodi finali e un’unità gateway.  Ciò forma una rete con una topologia a stella, che fornisce una struttura semplice e che abilita modalità di comunicazione che consentono la gestione della batteria attraverso la scelta delle classi di accesso. La classe A viene spesso utilizzata per i nodi finali alimentati a batteria, sebbene tutti i nodi finali IoR LoRaWAN debbano almeno supportare questa classe di funzionamento. La classe A si basa sul protocollo Aloha utilizzato in molte reti wireless. Ogni dispositivo può trasmettere al gateway un messaggio di uplink in qualsiasi momento: non esiste una programmazione prestabilita o uno slot di temporizzazione assegnato. Per ogni messaggio di uplink LoRaWAN, il nodo finale si aspetta un messaggio di downlink in risposta. Questo messaggio di downlink può arrivare in uno dei due slot di downlink ricevuti. Una volta ricevuto il messaggio di downlink, il nodo finale può passare in modalità Sleep per risparmiare la batteria. Se il nodo finale riceve un messaggio di downlink nel primo slot, non deve attendere e restare in ascolto per un secondo intervallo di tempo di ricezione, lasciando così che il dispositivo spenga il suo circuito ricevitore il più rapidamente possibile.

Figura 2 – Il Timing negli end-node di classe A LoRaWAN.

 

Con la classe A, non esiste alcuna procedura per un gateway LoRaWAN di riattivazione del nodo finale. Di conseguenza, la Classe A è una buona scelta per i sensori che verranno risvegliati localmente da timer o da variazioni rilevate su linee I/O, ma non per attuatori come valvole di irrigazione o serrature che devono essere in grado di rispondere rapidamente a comandi remoti. Per queste circostanze sono stati definiti i nodi finali di Classe B e Classe C. In Classe B, che è spesso preferita per i nodi finali alimentati a batteria con funzionalità di attuatore, a ciascun dispositivo è assegnato un intervallo di tempo basato su un segnale periodico fornito dal gateway. Il vantaggio di avere una fascia oraria assegnata è che il nodo può “dormire” tra ognuno questi periodi ed il successivo. Potenzialmente, con un’interfaccia RF intelligente, solo quel sottosistema ha bisogno di svegliarsi per ascoltare la durata dello slot, mentre il core processor rimane in uno stato di quiescenza, di basso consumo.  Solo se viene ricevuto un messaggio, il processore viene svegliato per elaborarlo. Un clock real-time può fornire la serie di interrupt necessari per garantire che il sottosistema Rx sia attivo per ogni slot. I messaggi di uplink possono essere inviati ogni volta che il dispositivo non sia programmato per l’ascolto di messaggio di downlink. In genere, ciò si verifica se un interrupt locale segnala che è stato ricevuto un input del sensore e il software del processore determina che questo è abbastanza importante da essere inoltrato ad un server.

Figura 3 – Il timing negli end-node LoRaWAN di Classe B (solo slot RX).

 

Un’applicazione tipica per la Classe B è quella delle valvole di irrigazione, in cui l’applicazione può tollerare una latenza dal comando all’attivazione della valvola anche di diversi minuti. La classe C viene generalmente utilizzata per i nodi finali alimentati dalla rete, come i lampioni e semafori stradali, che devono rispondere ai messaggi dalla rete il più rapidamente possibile. Questi dispositivi restano costantemente in ascolto per messaggi di downlink dal gateway. L’unica eccezione è quando il nodo finale sta trasmettendo un messaggio di uplink. Di conseguenza, i dispositivi di Classe C si comportano più come quelli che operano su reti che non dispongono delle ottimizzazioni di consumo offerte da LoRaWAN.

Per la maggior parte dei dispositivi, il duty cycle di funzionamento e la sua interazione con le sorgenti di interrupt sono una considerazione importante nella progettazione degli end node. Tuttavia, la maggior parte delle piattaforme MCU dispone già delle funzionalità necessarie: i sensori a bassa energia quasi certamente useranno già la modalità Sleep.  Finché il dispositivo può essere svegliato in tempo per gestire i messaggi di rete, generalmente attraverso le azioni di un clock real-time, può rientrare nei requisiti di LoRaWAN e in un modo che massimizza l’efficienza energetica anche se il progettista deve analizzare come l’aggiunta delle comunicazioni wireless influirà sulla durata della batteria. Molti sistemi a batteria dovranno funzionare per parecchi anni contando su una singola carica della batteria perché sarebbe troppo costoso inviare regolarmente personale di manutenzione. Pertanto, è molto importante stimare il consumo tenendo conto delle comunicazioni wireless. Ciò può essere eseguito analizzando il consumo di energia nelle modalità Sleep e Active, determinando quindi quanto tempo il dispositivo spenderà in ciascuno di esse. Gli slot regolari per downlink usati dal dispositivo di Classe B aiutano a stabilire un limite di quanta attività il sottosistema Rx dovrà sostenere per tutta la sua durata.

In termini di integrazione software, uno stack LoRaWAN basico occupa circa 55-60 Kb di spazio codice. Poiché un numero crescente di sistemi deve essere in grado di gestire aggiornamenti over-the-air, i progettisti devono tenere conto della quantità di memoria non volatile necessaria per memorizzare il nuovo firmware oltre al codice esistente al fine di supportare il processo di aggiornamento. La memorizzazione di software nuovi e vecchi consente di ripristinare gli aggiornamenti in caso di errore.

Un’ulteriore considerazione in termini di capacità del processore è il supporto per le funzioni di sicurezza. Una caratteristica fondamentale del protocollo di rete LoRaWAN è il supporto integrato per comunicazioni sicure e crittografate. Il suo framework di autenticazione e sicurezza si basa sullo schema di crittografia AES 128, con chiavi separate utilizzate per proteggere i dati degli utenti e i metadati di rete in ogni pacchetto. Ciò consente a LoRaWAN di offrire un livello di sicurezza più elevato rispetto alle implementazioni a chiave singola.  Il vantaggio di AES 128 è che offre una robusta sicurezza nonostante un overhead relativamente basso. Può essere implementato interamente nel software o con l’assistenza hardware dove sono richieste prestazioni più elevate. Poiché i payload dei dati di LoRaWAN sono relativamente brevi – spesso meno di 12 byte – l’implementazione del software risulta pratica.

È importante proteggere le chiavi simmetriche necessarie per la chiave univoca del dispositivo e le chiavi di sessione che verranno derivate da questa chiave. Una MCU con Flash on-chip sicura dedicata o EEPROM è la scelta ideale. Molto spesso, i transceiver wireless progettati per LoRaWAN includeranno le necessarie funzioni di crittografia e memorizzazione delle chiavi.

Un altro fattore chiave è la scelta dell’antenna: questo è un componente assolutamente fondamentale per garantire che i dispositivi possano funzionare a lunghe distanze da un gateway. I progettisti di dispositivi IoT possono scegliere tra una grande varietà di tipi di antenna. Le scelte includono tipicamente: un’antenna a filo semplice di un quarto della lunghezza d’onda, un’antenna PCB realizzata direttamente sul circuito stampato, un’antenna basata su chip, una semplice antenna a bobina da un quarto d’onda, o un’antenna esterna a frusta da un quarto d’onda. I progettisti che scelgono di utilizzare un modulo LoRaWAN pronto all’uso o system-in-package spesso troveranno che l’antenna richiesta è già integrata, il che semplifica la progettazione anche se potrebbe essere meno flessibile di un’antenna sintonizzata per il dispositivo finale.

Grazie alla disponibilità di soluzioni ready-made e personalizzabili per la tecnologia LoRaWAN, è facile per i progettisti incorporare comunicazioni wireless a lungo raggio e a basso consumo nei loro progetti e portare il vantaggio della compatibilità IoT ai loro sistemi. La giusta considerazione dell’architettura di sistema e del software assicurerà che il sistema risultante offra prestazioni elevate ed efficienza energetica.