IoT wireless — LoRaWAN, Zigbee mesh e MQTT

📋 Obiettivi di apprendimento
Descrivere l’architettura LoRaWAN (end device, gateway, network server, application server) e le tre classi operative A/B/C
Spiegare il modello publish/subscribe di MQTT, il ruolo del broker, i livelli QoS 0/1/2 e i meccanismi retain e LWT
Descrivere come si protegge MQTT con TLS e autenticazione, e il modello di sicurezza a doppio livello di LoRaWAN (NwkSKey/AppSKey)
Confrontare LoRaWAN, Sigfox e NB-IoT identificando la tecnologia più adatta a uno scenario LPWAN dato
🎬
Video
Rete IoT con rete cellulare in Packet Tracer
Guarda →
📄
Slides
IoT wireless — LoRaWAN, MQTT e LPWAN
🔬
Lab
Rete IoT con rete cellulare in Packet Tracer
GitHub →
🖧
Lab
Rete IoT con rete cellulare in Packet Tracer
PKT →

L’IoT e le sue esigenze di connettività

L’Internet of Things pone requisiti di rete radicalmente diversi rispetto alla connettività tradizionale. Un sensore di temperatura in un campo agricolo, un contatore dell’acqua in una città, un tracker GPS su un container — questi dispositivi non devono trasmettere video in streaming né scaricare aggiornamenti software ogni ora. Devono fare una cosa sola: inviare piccoli pacchetti di dati con grande affidabilità, a lungo raggio, consumando pochissima energia.

Requisiti tipici di un dispositivo IoT a lungo raggio
🔋
Autonomia anni
Batteria non sostituibile o difficilmente accessibile
📡
Copertura km
Aree rurali, edifici industriali, zone senza Wi-Fi
📦
Payload piccolo
Decine o centinaia di byte per messaggio, raramente
💰
Costo basso
Migliaia di dispositivi per progetto — costo unitario critico

Né il Wi-Fi (troppo energivoro e corto raggio) né il 4G/5G (costoso e ad alto consumo) rispondono a questi requisiti. La categoria tecnologica progettata per questo scenario è la LPWAN — Low Power Wide Area Network.

LoRaWAN

LoRaWAN è lo standard LPWAN più diffuso a livello mondiale. Si basa su due livelli distinti: LoRa (Long Range) è la tecnologia radio fisica — una modulazione a spettro espanso chiamata Chirp Spread Spectrum (CSS) sviluppata da Semtech. LoRaWAN è il protocollo MAC e di rete che definisce come i dispositivi accedono al canale, come vengono autenticati e come sono organizzati.

📌 Chirp Spread Spectrum — perché funziona così bene

Il segnale LoRa usa chirp — segnali la cui frequenza aumenta o diminuisce nel tempo. Questa modulazione è altamente robusta al rumore e alle interferenze: il segnale rimane decodificabile anche quando è 20 dB sotto il livello del rumore ambientale. Questo permette di raggiungere distanze di 10-15 km in campo aperto con una potenza di trasmissione di pochi milliwatt.

Architettura LoRaWAN — quattro livelli

🌐 Application Server
Elabora i dati applicativi, li rende disponibili a dashboard e sistemi esterni. Decifra il payload (AppSKey).
🖧 Network Server
Gestisce autenticazione dei dispositivi, deduplicazione pacchetti (da più gateway), ADR (Adaptive Data Rate), sicurezza di rete (NwkSKey).
↕ IP/Internet
📡 Gateway 1
Relay radio → IP
📡 Gateway 2
Relay radio → IP
📡 Gateway 3
Relay radio → IP
↕ Radio LoRa (868 MHz)
🌡️ Sensore A
End Device
💧 Contatore B
End Device
🚪 Tracker C
End Device
📌 Il Gateway LoRaWAN non è un router — è un relay

A differenza di un router Wi-Fi o di uno switch, il gateway LoRaWAN non prende decisioni. Riceve tutti i frame radio nell’aria, li impacchetta in UDP/IP e li inoltra al Network Server. Un pacchetto trasmesso da un sensore può essere ricevuto da più gateway contemporaneamente — il Network Server si occupa della deduplicazione. Questo rende la rete molto robusta e scalabile.

Le tre classi di dispositivi LoRaWAN

Classi operative — consumo vs reattività
Classe A ✅ Più diffusa
TX → RX1 (breve) → RX2 (breve)
…sleep per ore…
TX → RX1 → RX2

Il dispositivo trasmette quando vuole, poi apre due brevi finestre di ricezione. Per il resto dorme. Consumo minimo — anni con una singola batteria.

Es: sensori temperatura, contatori, tracker lenti
Classe B
TX → RX1 → RX2
Beacon syncRX slot
Beacon → RX slot…

Aggiunge finestre di ricezione sincronizzate con beacon periodici del gateway. Permette al server di inviare dati in orari prevedibili. Consumo maggiore di Classe A.

Es: attuatori con comandi programmabili
Classe C
TX → RX1
RX2 sempre aperto
(salvo durante TX)

Il dispositivo è quasi sempre in ascolto, eccetto durante la trasmissione. Massima reattività ai comandi del server. Consumo elevato — richiede alimentazione stabile.

Es: lampioni smart, attuatori industriali

Sicurezza LoRaWAN — doppio livello di cifratura

Il modello di sicurezza LoRaWAN è progettato per separare le responsabilità tra operatore di rete e fornitore dell’applicazione. Usa due chiavi AES-128 distinte che proteggono livelli diversi dello stack:

NwkSKey — Network Session Key

Condivisa tra il dispositivo e il Network Server. Protegge l’integrità e l’autenticità dei messaggi a livello di rete — verifica che il pacchetto provenga da un dispositivo legittimo e non sia stato alterato.

Il Network Server può verificare il messaggio ma non può leggere il payload applicativo.
AppSKey — Application Session Key

Condivisa tra il dispositivo e l’Application Server. Cifra il payload applicativo — i dati reali del sensore (temperatura, pressione, posizione GPS).

Solo l’Application Server può decifrare il contenuto — nemmeno l’operatore di rete lo vede.
Attivazione dei dispositivi — OTAA vs ABP
OTAA — Over The Air Activation ✅ Consigliato

Il dispositivo si unisce alla rete tramite una procedura di join che genera chiavi di sessione uniche ad ogni attivazione. Ogni nuova sessione ha NwkSKey e AppSKey diverse. Più sicuro perché le chiavi non sono statiche.

ABP — Activation By Personalization ⚠️

Le chiavi di sessione sono hardcoded nel firmware del dispositivo — non cambia mai. Più semplice da configurare ma meno sicuro: se un dispositivo viene fisicamente compromesso, le chiavi sono recuperabili.

MQTT — Message Queuing Telemetry Transport

Se LoRaWAN risolve il problema del trasporto radio dei dati IoT, MQTT risolve il problema del trasporto applicativo: come consegnare i messaggi dai sensori alle applicazioni che devono elaborarli, in modo efficiente e scalabile.

MQTT è un protocollo di messaggistica leggero basato sul modello publish/subscribe, progettato da IBM nel 1999 per la telemetria su collegamenti satellitari a bassa banda. Oggi è diventato lo standard de facto per la comunicazione IoT a livello applicativo, adottato da piattaforme come AWS IoT, Azure IoT Hub, Google Cloud IoT e centinaia di sistemi industriali.

📌 MQTT nel modello OSI

MQTT è un protocollo di livello applicativo (livello 7) che opera su TCP/IP (porta 1883 per MQTT non cifrato, porta 8883 per MQTT over TLS). Non è legato a nessuna tecnologia radio specifica: può funzionare sopra Wi-Fi, Ethernet, 4G o anche sopra LoRaWAN (tramite il Network Server come gateway). È il “linguaggio” che parlano i dispositivi IoT con le piattaforme cloud.

Il modello Publish/Subscribe

MQTT non usa il modello client/server tradizionale in cui un client si connette direttamente a un server. Usa invece il modello publish/subscribe, con un intermediario centrale chiamato broker.

Architettura Publish/Subscribe
Publisher (produttori)
🌡️
Sensore temperatura
PUBLISH
casa/salotto/temperatura
💡
Sensore luminosità
PUBLISH
casa/salotto/luce
🔀
BROKER
instrada i messaggi per topic
Subscriber (consumatori)
📱
App smartphone
SUBSCRIBE
casa/salotto/#
🖥️
Dashboard aziendale
SUBSCRIBE
casa/+/temperatura
Publisher e subscriber non si conoscono e non comunicano direttamente. Il broker è l’unico punto di contatto — disaccoppiamento totale tra chi produce e chi consuma i dati.

Topic — il sistema di indirizzamento

In MQTT i messaggi non vengono inviati a destinatari specifici ma pubblicati su topic — stringhe gerarchiche separate da / che identificano il tipo di dato:

Struttura gerarchica dei topic
edificio/piano2/stanza5/temperatura
fabbrica/linea3/motore7/rpm
città/zona_est/lampione42/stato
Wildcard nei subscription
+ = un livello qualsiasi
edificio/+/temperatura
→ tutti i piani, solo temperatura
# = tutti i livelli successivi
edificio/#
→ tutto ciò che è nell’edificio

Quality of Service — tre livelli di affidabilità

MQTT definisce tre livelli di QoS che determinano la garanzia di consegna del messaggio. La scelta del livello è un compromesso tra affidabilità e overhead di rete:

MQTT QoS — livelli di garanzia
QoS 0 — At most once
Publisher → Broker
(nessun ACK)

Fire-and-forget. Il messaggio viene inviato una volta sola, senza conferma. Può essere perso se la connessione cade.

Uso: dati non critici aggiornati frequentemente (telemetria ad alta frequenza)
QoS 1 — At least once
Publisher → Broker
Broker → PUBACK
(ritrasmette se no ACK)

Il broker conferma la ricezione. Se l’ACK non arriva, il messaggio viene ritrasmesso. Può arrivare duplicato.

Uso: comandi importanti dove i duplicati sono tollerabili
QoS 2 — Exactly once
P → B: PUBLISH
B → P: PUBREC
P → B: PUBREL
B → P: PUBCOMP

Handshake a 4 fasi che garantisce consegna esattamente una volta. Massima affidabilità, overhead maggiore.

Uso: transazioni critiche, comandi attuatori (apri valvola, sblocca serratura)

Retain e Last Will Testament

🗂️ Retain — messaggi persistenti

Un messaggio pubblicato con il flag retain=true viene conservato dal broker. Quando un nuovo subscriber si iscrive a quel topic, riceve subito l’ultimo messaggio trattenuto — senza dover aspettare il prossimo aggiornamento.

Utile per: stato attuale di un dispositivo, ultima lettura di un sensore, configurazione di un attuatore
💀 LWT — Last Will and Testament

Quando un client si connette al broker, può specificare un messaggio “testamento” — topic + payload — da pubblicare automaticamente se la connessione cade in modo inaspettato (crash, perdita di rete).

Es: il sensore pubblica LWT “offline” su sensori/42/stato — il sistema sa subito che il dispositivo è irraggiungibile

Sicurezza MQTT — TLS, autenticazione e autorizzazione

Il protocollo MQTT base non include meccanismi di sicurezza — la connessione sulla porta 1883 è in chiaro. In produzione è indispensabile aggiungere:

🔒
MQTT over TLS
porta 8883

Cifra tutto il traffico MQTT con TLS. Il certificato del broker viene verificato dal client. Opzionalmente il broker può richiedere un certificato client (mutual TLS). Il broker Mosquitto supporta TLS nativamente con poche righe di configurazione.

🪪
Username/Password

MQTT supporta autenticazione con username e password nel pacchetto CONNECT. Solo utile se combinata con TLS — in chiaro le credenziali sono visibili a qualsiasi sniffer.

🛡️
ACL sui topic

Il broker può limitare quali topic ogni client può pubblicare o sottoscrivere. Esempio: il sensore temperatura può solo pubblicare su sensori/42/#, non su topic di altri dispositivi.

Confronto tecnologie LPWAN

LoRaWAN non è l’unica tecnologia LPWAN. Le tre principali si differenziano per architettura, frequenze e modello di deployment:

CaratteristicaLoRaWANSigfoxNB-IoT
Frequenza868 MHz (EU) — ISM868 MHz (EU) — ISMBande LTE licenziate
Copertura tipica2–15 km3–50 km1–10 km
Velocità dati0,3–50 kbps100 bps (UL)
600 bps (DL)
20–250 kbps
InfrastrutturaPrivata o pubblica (TTN)Solo operatore SigfoxOperatori 4G/LTE
Messaggi/giornoIllimitati (duty cycle)140 UL / 4 DLIllimitati
Autonomia batteriaAnni (AA battery)AnniAnni (PSM mode)
Punto di forzaFlessibilità, rete privata, open sourceSemplicità, copertura europeaIntegrazione 4G, roaming internazionale
📌 Come scegliere la tecnologia LPWAN giusta
LoRaWAN: vuoi costruire la tua infrastruttura privata (campus, fabbrica), hai molti messaggi al giorno, non hai già una copertura 4G, vuoi piena ownership dei dati
Sigfox: vuoi una soluzione chiavi-in-mano senza infrastruttura, hai pochi messaggi al giorno, non hai bisogno di alta latenza
NB-IoT: hai già dispositivi con SIM, hai bisogno di roaming internazionale, accetti il costo dell’abbonamento operatore, hai bisogno di payload più grandi
📌 Riepilogo — Punti chiave
  • LoRaWAN: architettura star-of-stars con gateway passivi (relay), Network Server e Application Server. Classi A/B/C: A = massima autonomia; C = massima reattività. Sicurezza doppia con NwkSKey (rete) e AppSKey (applicazione) — operatore e cliente hanno chiavi separate
  • MQTT è un protocollo applicativo publish/subscribe basato su broker. I client pubblicano su topic gerarchici (edificio/piano/stanza/sensore), i subscriber ricevono automaticamente i messaggi di interesse. Il broker disaccoppia completamente produttori e consumatori
  • QoS 0 (fire-and-forget), QoS 1 (almeno una volta, possibili duplicati), QoS 2 (esattamente una volta, handshake 4 fasi). Retain: il broker memorizza l’ultimo messaggio per i nuovi subscriber. LWT: messaggio automatico quando la connessione cade
  • MQTT di base è in chiaro (porta 1883) — in produzione si usa sempre MQTT over TLS (porta 8883) con autenticazione e ACL sui topic
  • Confronto LPWAN: LoRaWAN (flessibile, rete privata possibile), Sigfox (semplice, limitato a 140 messaggi/giorno UL), NB-IoT (integra la rete 4G, roaming internazionale)

Lascia un commento