Architettura LoRaWAN

LoRaWAN è una rete con struttura stella di stelle (star of stars topology) senza capacità di instradamento fra i nodi. Il gateway è il centro stella: raccoglie i dati trasmessi dai nodi e li inoltra, usando una connessione con tradizionali protocolli IP, al Network Server (NS) per una prima gestione del frame. I dati sono successivamente inviati allo Application Server (AS) che ha il compito di estrarre il dato utile (payload) e renderlo disponibile all’applicazione finale. In Figura 1 la struttura fisica e logica (stack) della rete.

Struttura fisica e logica LoRaWAN
Figura 1. Struttura fisica e logica LoRaWAN

La rete solitamente è gestita da un operatore in cloud. Essendo il protocollo aperto e di libero uso, esistono numerose implementazioni che facilitano anche la realizzazione di reti private. Nello stack logico della architettura è evidenziato il livello fisico LoRa. LoRaWAN: l’architettura tipo senza fornirne la concreta implementazione.

Nodo

La Figura 2 schematizza la struttura tipica di un nodo.


Figura 2. Struttura del nodo [20].

Il riquadro SX127x è il dispositivo Semtech in cui è ‘racchiusa’ la tecnologia proprietaria LoRa, la integrazione più o meno stretta con la MCU caratterizza la differente nomenclatura fra LoRa radio, modulo LoRa e modem radio.

Gateway

Il gateway non implementa particolari funzioni: riceve il messaggio radio, lo demodula e lo inoltra via UDP al Network Server con l’aggiunta di metadati quale, ad esempio, l’intensità del segnale (RSSI Received Signal Strength Indication) e la frequenza del canale radio. LoRa è un protocollo di trasmissione che non prevede meccanismi di protezione, l’integrità e la riservatezza del dato è delegata alla crittografia prevista per LoRaWAN e più avanti descritta. Nel presente progetto sono stati valutati due gateway entrambi basati su shield e installati su Raspberry Pi. Il primo, non molto efficiente, monocanale, con una scheda Dragino. Il secondo multicanale con scheda Ic880A di IMST GmbH, certamente più performante ed utilizzato per la connessione alla rete TTN.

Network Server

Il Network Server gestisce i gateway, i nodi, l’accesso dei nodi alla rete, provvede alla deduplica dei messaggi ricevuti da diversi gateway e generati dallo stesso nodo. Decripta la parte del messaggio che gli compete, instrada (routing) i messaggi in download (da Network Server a nodo) verso il gateway ritenuto più conveniente fra quelli in grado di raggiungere il nodo. In upload (da nodo alla rere) inoltra i dati all’Application Server. I dati trasmessi dai nodi possono essere ricevuti anche da più gateway se presenti nell’area di copertura radio.

Application Server

L’Application Server riceve il payload dal Network Sserver e lo rende disponibile all’utente attraverso meccanismi quali Web Application Program Interface (Web API), Message Queue Telemetry Transport (MQTT, un protocollo del tipo publish / subscribe) o g Remote Procedure Calls (gRPC meccanismo RPC sviluppato da Google).

Join Server

I nodi, alla loro attivazione, devono connettersi alla rete con una operazione di join (a tutti gli effetti una autenticazione). Il Join Server (JS) ha il compito di gestire l’accesso dei nodi alla rete attraverso opportune procedure di attivazione. Ha una funzione più marcata nelle specifiche LoRaWAN 1.1 con il ruolo di gestore delle chiavi di sicurezza.

Categoria: 

Tags: 

Mi piace: 

0
No votes yet

LoRaWAN classi di funzionamento

LoRaWAN  prevede per i nodi tre classi di funzionamento (A, B e C). Partendo dal presupposto che il dato trasmesso è breve, non sempre è critica la perdita di un dato e il consumo energetico è importante, le tre classi si differenziano nei tempi e nei modi usati per trasmettere e ricevere i dati verso la rete. Il nodo deve sempre implementare la classe A. Le classi B e C sono, di fatto, una estensione della classe A.

Classe A
Nella classe A il dispositivo trasmette, autonomamente, nel momento che ritiene opportuno. L’inizio di trasmissione avviene su propria iniziativa, senza nessun coordinamento con gli altri nodi o con il gateway, al più implementando un meccanismo denominato LBT (Listen Before Talk) per verificare se altri dispositivi stanno occupando il canale di comunicazione e ritardare la trasmissione. Al termine dell’invio dei dati, il nodo passa in ricezione (RX slot) in due istanti distinti T1 e T2. I valori di T1 e T2 sono di default di 1 e di 2 secondi a partire dall’istante di fine invio.
Il nodo può ricevere (down link) nei due slot temporali per ricevere i dati trasmessi da un gateway. La risposta alla trasmissione con un messaggio di conferma (ACK) non è obbligatoria. La Figura mostra la sequenza trasmissione-ricezione della classe A.

Classe A

Classe B
La classe B prevede una trasmissione e ulteriori successivi intervalli di ricezione coordinati dal gateway il quale invia un segnale di sincronizzazione, beacon, al nodo. Il nodo riceve ad intervalli, denominati ping period, predeterminati con riferimento l’istante di beacon e presenta, oltre a quanto previsto dalla modalità della classe A, ulteriori intervalli di ricezione. In Figura lo schema della tempistica della classe B.

ClasseB

Classe C
Il dispositivo di classe C è costantemente in ricezione e opera in trasmissione, quando necessario, con la modalità della classe A. In Figura la tempistica della classe C.

Classe C

Le tre classi si differenziano per caratteristiche di latenza (in ricezione) e consumo energetico. Il minore consumo energetico e la massima latenza si ha in classe A. La classe B consente una minore latenza grazie a slot aggiuntivi in ricezione, al costo di un aumento di consumo energetico. La classe C presenta una latenza minima, ma con un alto consumo energetico dovuto alla ricezione continua. I nodi nelle classi A e B, al di fuori dai periodi di trasmissione e ricezione, possono porsi in una condizione di basso consumo, modalità dette di sleeping o deep sleeping, riducendo drasticamente i consumi. Il consumo energetico influenza la durata delle batterie ed è una problematica importante nella sensoristica IoT. Per questo motivo la classe A è generalmente preferibile per i nodi ad alimentazione autonoma. Spesso, inoltre, si accetta la perdita di un pacchetto dovuta all’accesso con probabilità di collisione (la trasmissione simultanea di più nodi) o disturbi, rinunciando anche ai meccanismi di conferma (ACK) pur di ridurre al minimo l’attivazione del nodo. La perdita di un pacchetto, in molti sistemi di acquisizione a bassa dinamica, ha un peso inferiore rispetto il costo di un invio di acknowledge, eventuale ritrasmissione e conseguente impegno energetico. La mancata acquisizione di un pacchetto può essere verificata con il valore di Frame Counter, presente nel pacchetto inviato e incrementato ad ogni trasmissione. Per recuperare dati persi possono essere implementate strategie di correzione di errore o tecniche predittive, a livello applicativo, che consentono la ricostruzione del dato perso. Con attenti meccanismi di gestione della alimentazione (Power Management), riducendo allo stretto necessario le trasmissioni, le batterie dei nodi possono durare diversi anni, minimizzando gli interventi di manutenzione.

Categoria: 

Tags: 

Mi piace: 

0
No votes yet

Accesso alla rete LoRaWAN

Un nodo per accedere alla rete LoRaWAN deve essere attivato, con un meccanismo che lo identifica in modo univoco qualora opportunamente registrato nella rete. Si può pensare a questo meccanismo come una autenticazione. Ci sono due metodi di accesso: OTAA e ABP (Over The Air Activaction e  Activation by Personalization) di seguito descritti. In funzione del meccanismo vengono negoziate o fornite in modo statico opportune chiavi usate per criptare il traffico di dati in rete.
Indirizzamento.


Il gateway e i nodi devono essere noti al network server e identificati in modo univoco attraverso identificativi di 64 bit denominati rispettivamente GatewayEUI e DevEUI (Extended Unique Identifier, EUI). Nei dispositivi commerciali questi identificatori sono definiti dal costruttore e scritti in qualche forma, non modificabile, nel dispositivo (in memoria ROM). In ambienti di sviluppo e prototipizzazione, l’identificativo è fornito generalmente dallo sviluppatore, il quale deve avere cura di evitare duplicazioni, almeno nell’ambito della rete nella quale è inserito il dispositivo. Ad esempio, per i gateway che dispongono di una interfaccia di rete ethernet, si può utilizzare il MAC address per generare il GatewayEUI inserendo 2 byte 0xffff a metà MAC address, come suggerito in ‘Mapping an EUI-48 to an EUI-64’ del citato documento IEEE. Esistono altri identificativi usati nella gestione del nodo e dell’applicativo (riferito all’Application Server).
DevAddr è l’indirizzo usato nei messaggi del nodo di 32 bit. Il suo uso al posto di un identificativo EUI-64, permette un messaggio corto, ma non è garantisce unicità del nodo nella rete. Per discriminare univocamente il nodo, nei casi di DevAddr duplicato, si fa riferimento alla crittografia del pacchetto: ogni nodo ha una chiave AES differente.
AppEUI è un identificativo usato per abbinare il nodo all’Application Server, indicativamente può essere paragonato al concetto di port number del protocollo TCP.


Attivazione
Il nodo, alla sua attivazione, deve essere riconosciuto e identificato dalla rete con un meccanismo appropriato. Esistono due modalità di autenticazione e attivazione dei nodi:

  • OTAA, Over The Air Activation.
  • ABP, Activation by Personalization.

OTAA prevede una fase iniziale di join alla rete durante la quale vengono negoziati i principali parametri di connessione quali indirizzi (DevAddr), chiavi AES per la crittografia (NwkSKey e AppSKey). Nella fase di attivazione, per gestire l’integrità e la riservatezza, viene utilizzato l’identificativo AppKey, noto al nodo e al network server, usato per firmare (MIC Message Integrity Code) e criptare i primi messaggi scambiati per l’attivazione. Nello scambio viene utilizzato un valore di nonce, generato casualmente, utile a limitare attacchi di tipo replay. In figura  è presentata la sequenza dei messaggi nella procedura OTAA.

Over The Air Activaction

Nella fase iniziale i dati sono protetti dalla chiave denominata AppKey, nota al nodo e al Network Server, tramite una firma MIC (Message Integrity Code). In seguito vengono generate e ascambiate le chiavi utilizzate per il normale traffico da e per il Nework server (NwkSKey) e l'application server (AppSKey).
Ad ogni riconnessione del nodo, ad esempio dopo uno spegnimento e successiva accensione, le chiavi e il DevAddr sono nuovamente negoziate e cambiate. Questo è il motivo per cui il meccanismo OTAA, rispetto a ABP, è ritenuto più sicuro. Il network server (o chi per esso) genera le chiavi di sessione, valide per lo specifico join: NwkSKey e AppSKey. La prima chiave è usata per criptare il pacchetto destinato al Network Server, la seconda per cifrare il payload destinato all’Application Server.


Nella attivazione ABP non esiste la fase di join. Le chiavi di crittografa e il DevAddr sono statiche e note a priori a tutti i rispettivi elementi della rete. ABP è un modo più snello, non richiede negoziazione. Le chiavi di crittografia restano immutate nel tempo (di solito scritte nel firmware) e consentendo più spazio ad attacchi malevoli, per questo è bene proteggere l’hardware per evitare la lettura delle chiavi agendo direttamente sul dispositivo. La figura  riassume i parametri coinvolti in ABP.

Activation by Personalization

 

Categoria: 

Tags: 

Mi piace: 

0
No votes yet