Che cos'è un gateway LoRaWAN e quando serve davvero

Una rete LoRaWAN collega end-device come sensori e contatori a uno o più gateway. Il gateway riceve il traffico radio e lo inoltra tramite una connessione IP verso il Network Server, che svolge le funzioni di rete previste dall'architettura LoRaWAN.

Per questo il gateway deve essere adeguato sia sul lato radio sia sul lato IP. Una buona copertura non basta se manca il backhaul necessario o se il dispositivo non può integrarsi correttamente con l'infrastruttura prevista.

LoRaWAN è una tecnologia LPWA pensata per applicazioni IoT in cui contano copertura estesa e basso consumo, con profili di traffico compatibili con questo tipo di rete. A seconda dei requisiti applicativi, può essere utilizzata per sensoristica in smart building e industria, monitoraggio, metering e asset tracking.

Non è invece una soluzione universale per qualsiasi applicazione IoT. Grandi trasferimenti di dati o sistemi di controllo che richiedono latenze dell'ordine dei millisecondi non rappresentano il suo campo d'impiego naturale.

Se non è ancora chiaro se LoRaWAN sia la famiglia corretta per il progetto, è più utile partire dalla guida generale ai gateway prima di selezionare un modello specifico.

LoRa e LoRaWAN non sono la stessa cosa

LoRa indica la tecnologia radio utilizzata per la comunicazione wireless. LoRaWAN definisce invece il protocollo e l'architettura di rete che utilizzano quel livello radio.

La distinzione ha conseguenze pratiche: la presenza del supporto LoRa non permette, da sola, di concludere che un dispositivo sia un gateway LoRaWAN adatto alla rete prevista.

Prima della scelta va quindi verificato che il prodotto supporti effettivamente LoRaWAN e che la specifica variante sia coerente con la regione e con l'infrastruttura di rete.

Dove si colloca il gateway nella rete LoRaWAN

Il percorso essenziale dei dati può essere rappresentato così:

end-device → gateway LoRaWAN → rete IP → Network Server → eventuale Application Server

Uno stesso messaggio radio può essere ricevuto da più gateway, mentre il Network Server costituisce un componente distinto. La presenza di LoRaWAN nel gateway non implica quindi automaticamente la compatibilità con qualsiasi piattaforma backend.

L'Application Server si colloca più a valle e, in base allo stack utilizzato, può elaborare i payload applicativi e rendere i dati disponibili ad altri sistemi.

EU868 e compatibilità regionale: il primo filtro da verificare

Prima di confrontare IP rating, Ethernet, LTE o sistemi di gestione bisogna verificare la regionalizzazione LoRaWAN.

La LoRa Alliance definisce Regional Parameters per le diverse aree regolamentari. Per i prodotti europei trattati in questo articolo, i produttori identificano le SKU pertinenti con denominazioni come EU868. Questa indicazione va comunque letta insieme al piano regionale, alla SKU effettiva e alla configurazione della rete.

Due gateway appartenenti alla stessa famiglia commerciale possono infatti esistere in varianti regionali differenti. Digi distingue, per esempio, versioni EU868 da versioni US915, PLANET utilizza analogamente SKU distinte per le diverse regioni.

Prima di procedere vanno controllati:

• paese e piano regionale della rete.
• SKU esatta del gateway.
• configurazione degli end-device.
• coerenza con l'infrastruttura LoRaWAN prevista.

Anche la sola presenza della dicitura '868 MHz' non sostituisce il controllo completo della SKU e della configurazione. Il nome generale della famiglia prodotto può comprendere versioni destinate a regioni diverse.

Copertura e capacità: come dimensionare senza affidarsi a numeri fuorvianti

'Quanti chilometri copre?' e 'quanti dispositivi supporta?' sono domande legittime, ma non possono essere risolte correttamente con un solo numero.

La copertura dipende dal sito reale. La capacità dipende dal modo in cui la rete viene utilizzata. In entrambi i casi, le specifiche hardware del gateway rappresentano soltanto una parte del dimensionamento.

La copertura va verificata sul sito reale

La copertura radio dipende da fattori come:

• posizione di gateway ed end-device.
• ostacoli.
• interferenze.
• geometria dell'edificio o del sito.
• distribuzione dei dispositivi.
• caratteristiche e installazione delle antenne.
• condizioni operative della rete.

Una distanza ottenuta o dichiarata in determinate condizioni non può quindi essere trasformata in una garanzia valida per qualsiasi installazione.

La documentazione LoRa Alliance sulla copertura raccomanda di individuare i gap attraverso dati e misure della rete e, quando necessario, intervenire sul posizionamento o aggiungere gateway. Nei siti complessi un pilot o una verifica sul campo può essere più utile di una distanza teorica.

Canali e capacità non indicano quanti sensori si possono collegare

I concentratori utilizzati nei gateway LoRaWAN possono ricevere traffico attraverso più canali e risorse di demodulazione. Alcuni dei modelli trattati, per esempio, dichiarano 8 canali di ricezione o 8 percorsi di demodulazione paralleli.

Questo non significa che 8 canali corrispondano a un massimo di 8 sensori.

La capacità effettiva dipende anche da:

• airtime dei messaggi.
• data rate e spreading factor.
• frequenza delle trasmissioni.
• profilo del traffico.
• uso di messaggi confermati o non confermati.
• numero e distribuzione dei gateway.

Il numero di canali è quindi un dato tecnico importante, ma non può essere utilizzato da solo per determinare quanti end-device possa sostenere una rete.

Per lo stesso motivo, claim commerciali espressi con metriche differenti - per esempio numero di nodi e numero di messaggi giornalieri - non sono direttamente confrontabili senza conoscere le relative condizioni.

Indoor o outdoor: ambiente, IP rating e alimentazione

Dopo regionalizzazione, copertura e traffico, il punto fisico di installazione permette di eliminare altre soluzioni non adatte.

Un gateway collocato in un locale tecnico o in un quadro non richiede necessariamente lo stesso involucro di un dispositivo esposto agli agenti esterni. Un modello IP67 non è quindi automaticamente superiore a un IP30: risponde a requisiti ambientali diversi.

La classificazione IP definita dalla IEC 60529 descrive il grado di protezione fornito dall'involucro. Da sola non esaurisce però le verifiche necessarie: temperatura operativa, montaggio, connettori, antenne e alimentazione devono comunque essere coerenti con il sito.

Ambiente indoor o protetto

Per building, locali tecnici o altre installazioni interne può essere sufficiente un gateway progettato per ambiente indoor.

Un esempio è Digi HX15-8-LR-GIE-002, variante EU868 indoor con Ethernet 10/100/1000, 8 Rx/1 Tx e alimentazione USB-C a 5 V. Digi prevede inoltre la gestione tramite la piattaforma X-ON.

Questo profilo è coerente con un requisito del tipo:

indoor + EU868 + Ethernet disponibile + alimentazione 5 V.

In un impianto industriale protetto con alimentazione DC può invece risultare pertinente PLANET LCG-300-EU, ID/SKU Digitx 119330: la variante EU868 utilizza un involucro IP30, dispone di cinque porte Gigabit Ethernet, alimentazione 9-54 V DC e 8 percorsi di demodulazione paralleli dichiarati dal produttore.

Il requisito diventa quindi:

quadro o ambiente protetto + EU868 + Ethernet + alimentazione DC industriale.

Questi due esempi non sono concorrenti in senso assoluto: rispondono a contesti di installazione differenti. La compatibilità con il backend previsto deve comunque essere verificata prima della scelta.

Ambiente outdoor o esposto

Se il gateway deve essere installato all'esterno, l'idoneità ambientale diventa un requisito preliminare.

Quando Ethernet è disponibile, Digi HX20-8-LR-GOE-002 è un esempio di configurazione coerente: variante EU868 per installazione outdoor, involucro IP67, Ethernet e alimentazione PoE.

Il requisito corrispondente è:

outdoor + EU868 + Ethernet disponibile + infrastruttura IEEE 802.3af compatibile.

Esistono anche gateway outdoor con connettività cellulare integrata, ma questa caratteristica diventa utile soltanto quando il sito richiede davvero un backhaul mobile.

Backhaul Ethernet o cellulare: quale collegamento serve davvero

La comunicazione radio fra end-device e gateway e il collegamento fra gateway e Network Server sono due parti differenti dell'architettura.

Gli end-device comunicano tramite LoRaWAN. Il gateway deve poi raggiungere il backend attraverso una rete IP: questo collegamento costituisce il backhaul.

Quando nel sito è disponibile Ethernet affidabile, non esiste un motivo automatico per aggiungere un modem cellulare. LTE o 5G diventano pertinenti in siti remoti senza WAN cablata oppure quando l'architettura richiede esplicitamente una seconda modalità di connettività.

Un gateway 5G non è quindi automaticamente preferibile a uno Ethernet. Se la rete cablata disponibile soddisfa i requisiti, il modem cellulare aggiunge dipendenze senza risolvere necessariamente un problema.

Solo dopo aver identificato uno scenario come outdoor + EU868 + necessità reale di un backhaul cellulare diventa naturale valutare PLANET LCG-350W-NR-EU868, ID/SKU Digitx 141131. PLANET identifica questa SKU come gateway LoRaWAN industriale outdoor con EU868, involucro IP67 e connettività 5G NR/4G LTE.

In questo caso il modem cellulare è una risposta al requisito del sito, non un upgrade generico.

Se invece il problema principale è collegare un sito alla WAN mobile e LoRaWAN non è il requisito centrale, l'approfondimento corretto è quello sui gateway cellulari 4G/5G/LTE.

Network Server, gestione remota e integrazione dei dati

Un gateway coerente sul piano radio, ambientale e di backhaul deve anche integrarsi nell'architettura software prevista.

Il primo controllo riguarda il Network Server. La dicitura 'gateway LoRaWAN' non garantisce, da sola, che ogni combinazione gateway-LNS sia supportata. Se il backend è già stato scelto, la compatibilità va verificata nella documentazione del modello e della piattaforma.

Compatibilità con il Network Server

Prima dell'acquisto è opportuno verificare almeno:

• piattaforma o LNS previsto.
• modalità di collegamento supportata dal gateway.
• eventuali requisiti di firmware o versione.
• documentazione ufficiale del produttore e della piattaforma.

Il fatto che un gateway utilizzi la variante regionale corretta non implica automaticamente che possa essere inserito senza ulteriori verifiche nel backend desiderato.

Gestione remota, MQTT e HTTP

La gestione remota diventa particolarmente rilevante quando i gateway sono distribuiti su più siti.

Digi utilizza Digi X-ON per provisioning e gestione dei gateway HX15/HX20. PLANET dichiara invece strumenti come PLANET NMS e CloudViewer per i modelli considerati. Le modalità operative devono quindi essere valutate per il singolo prodotto.

MQTT e HTTP appartengono a un livello diverso rispetto alla comunicazione radio LoRaWAN. Un Application Server può, a seconda della piattaforma, rendere disponibili i dati applicativi tramite MQTT o webhook HTTP.

Alcuni gateway possono inoltre offrire funzioni MQTT locali dipendenti dal firmware. Se una funzione software è decisiva per il progetto, va verificata sulla versione effettivamente installata anziché presunta dal nome del prodotto.

Se il requisito centrale è la conversione seriale/Ethernet, l'approfondimento appropriato riguarda i gateway Modbus. Per conversioni tra PROFINET, PROFIBUS, EtherNet/IP, CANopen o altri protocolli OT è più pertinente la guida ai gateway per protocolli industriali. Le funzioni VPN e firewall, invece, sono approfondite nella pagina dedicata ai gateway VPN e sicurezza.

Come scegliere il gateway LoRaWAN: checklist dal requisito al prodotto

La scelta può ora essere ridotta a una sequenza di verifiche. L'obiettivo è eliminare progressivamente le SKU incompatibili, non cercare il modello con il maggior numero di funzioni.

Prima di iniziare servono almeno: paese o regione, punto di installazione, distribuzione indicativa degli end-device, profilo di traffico, alimentazione disponibile, backhaul e Network Server o piattaforma prevista.

1. Verificare piano regionale e SKU. Per lo scenario europeo considerato, controllare la variante EU868 e scartare SKU destinate a piani differenti.
2. Definire l'ambiente. Stabilire se il gateway sarà installato indoor/in ambiente protetto oppure outdoor/esposto.
3. Valutare posizione e copertura. Considerare geometria del sito, ostacoli, interferenze e distribuzione degli end-device, prevedere misure o test se necessario.
4. Stimare traffico e capacità. Considerare frequenza dei messaggi e airtime senza utilizzare il solo numero di canali come indicatore del numero massimo di dispositivi.
5. Verificare l'alimentazione. USB-C, DC industriale e PoE richiedono infrastrutture differenti.
6. Scegliere il backhaul. Usare Ethernet quando soddisfa il requisito, valutare il cellulare solo se risolve un'esigenza concreta.
7. Controllare gestione e provisioning. Verificare piattaforme, servizi ed eventuali dipendenze operative.
8. Verificare il Network Server. La compatibilità deve essere documentata per il backend previsto.
9. Confrontare solo le SKU rimaste compatibili. Le funzioni accessorie diventano rilevanti dopo i requisiti obbligatori.
10. Ricontrollare prima dell'acquisto. Firmware, specifiche, disponibilità e prezzo sono elementi che possono cambiare nel tempo.

Se copertura o capacità rimangono incerte, il passo successivo corretto è un pilot o una verifica sul campo, mantenendo la possibilità di riposizionare o aggiungere gateway.

Scenari tipici e configurazioni coerenti

La stessa checklist porta a soluzioni differenti in funzione del contesto:

Indoor o smart building con Ethernet: Digi HX15-8-LR-GIE-002 è coerente quando servono EU868, installazione indoor, Ethernet e alimentazione USB-C 5 V. Digi conferma per la famiglia HX15 EU868, Ethernet 10/100/1000, 8 Rx/1 Tx e alimentazione USB-C.

Ambiente industriale protetto con Ethernet e DC: PLANET LCG-300-EU, ID/SKU Digitx 119330, risponde al profilo EU868 + IP30 + Ethernet + 9-54 V DC. PLANET conferma inoltre 8 percorsi di demodulazione paralleli.

Outdoor con Ethernet e PoE: Digi HX20-8-LR-GOE-002 è coerente con un sito esposto che dispone di Ethernet e infrastruttura IEEE 802.3af.

Outdoor o sito remoto con backhaul cellulare necessario: PLANET LCG-350W-NR-EU868 aggiunge 5G NR/4G LTE a un gateway LoRaWAN outdoor EU868 IP67 quando il collegamento mobile è realmente richiesto.

Questi esempi non costituiscono una classifica: rappresentano configurazioni diverse.

Se i requisiti non sono ancora sufficientemente definiti per arrivare a una singola SKU, è preferibile non forzare la scelta. Dopo aver stabilito almeno regione, ambiente, alimentazione e backhaul, si può consultare la categoria gateway LoRaWAN disponibili su Digitx.it e applicare i criteri definiti sopra. La categoria risulta attualmente attiva e comprende, tra gli altri, LCG-300-EU e LCG-350W-NR-EU868.

Il risultato finale dovrebbe essere una configurazione coerente - indoor Ethernet, industriale protetta Ethernet, outdoor Ethernet oppure outdoor con backhaul cellulare - ottenuta eliminando le alternative incompatibili. Se durante questo percorso emerge che il problema principale è un altro, come la sola connettività cellulare o la conversione di protocolli, è più corretto passare alla famiglia di gateway dedicata anziché adattare forzatamente una soluzione LoRaWAN.