Torna a reti di sensori

Caso d’uso LoRaWan

Date le particolarità della tecnologia, i casi d’uso per la rete di sensori sono quelli tipici applicazioni IoT outdoor a lungo raggio dette LPWA, dove concorre con altre tecnologie di rete: Sigfow, NB IoT e sotto certe condizioni, wifi. Caratteristiche di LoRaWAN sono essenzialmente:

alt text

Aspetti critici

Elementi critici su cui bilanciare convenienze e saper fare delle scelte argomentate sono:

Architettura di una rete di reti

Di seguito è riportata l’architettura generale fisica di una rete Lorawan. Essa è composta, a livello fisico, essenzialmente di una rete di accesso ai sensori e da una rete di distribuzione che fa da collante di ciascuna rete di sensori.

alt text

La rete di sensori fisica è a stella dove il centro stella è il gateway. Un sensore può anche essere associato a più gateway ed inviare dati a tutti i gateway a cui esso è associato. I dati normalmente arrivano ad un certo dispositivo attraverso un solo gateway.

I gateway utilizzano la rete internet (o una LAN) per realizzare un collegamento diretto virtuale con il network server, per cui, in definitiva, la topologia risultante è:

Avere a disposizione una rete di distribuzione IP per i comandi e le letture è utile perchè permette di creare interfacce web o applicazioni per smartphone o tablet per:

La figura sottostante riassume la rete LoRaWAN dal punto di osservazione di un collegamento L7 (applicativo) sulla rete di distribuzione:

alt text

Si noti, che il canale che collega i dispositivi IoT ai gateway non supera mai il livello 2 della pila ISO/OSI. Questi link hanno topologia a stella e possono collegare lo stesso sensore/attuatore a molti gateway. I dispositivi utilizzano un meccanismo di routing di livello L1 e quindi basato sul flooding. E’ il routing più semplice possibile, e anche il più affidabile ma possiede l’incoveniente di generare pacchetti duplicati nel loro percorso verso l’applicazione. Questo problema è gestito dal network server.

Documentazione logica (albero degli apparati attivi)

Esempio di connessione alla rete di distribuzione IP tramite gateway dotati di client VPN:

alt text

Si noti che l’architettura generale è quella di una federazione di reti di sensori più o meno isolate e sparpagliate sul territorio, ognuna delle quali fa capo, con topologia a stella, ad un proprio gateway, deputato al coordinamento della stella. La federazione è amministrata da un unico network server che inoltra i dati provenienti dai gateway verso l’applicazione utilizzando i servizi di trasporto offerti da una WAN. I servizi di autenticazione e cifratura (normalmente assenti in Internet) possono essere offerti, oltre che dal protocollo LoRaWAN, anche da da una VPN. I gateway posseggono la componente lora-gateway-bridge che si occupa di inserire il messaggio LoRaWAN in un payload di servizio MQTT per il network server

Il gateway All-In-One potrebbe essere un dispositivo con doppia interfaccia, modem UMTS per l’accesso alla rete di distribuzione su Internet, LoRaWAN verso la rete di sensori. Può essere utile per realizzare un gateway LoRaWAN da campo da adoperare:

Canali di comunicazione principali in una rete di sensori

In sintesi, sono necessari almeno due canali di comunicazione che, insieme, complessivamente, realizzano la comunicazione tra sensori e gestore delle informazioni:

Broker MQTT

Il broker MQTT è solo una delle tante soluzioni possibili per realizzare un canale multicast di livello applicativo tramite cui un utente col ruolo di publisher è in grado di notificare una replica dello stesso messaggio a più subscribers. E’ utile per:

Il canale applicativo su cui vengono inviati i messaggi sono quindi i topic. Su un certo topic il dispositivo con il ruolo di output agisce come un publisher, mentre quello con il ruolo di input agisce come un subscriber.

Gli utenti, in ogni caso, si comportano tutti come client poiché sono loro che iniziano la connessione con il broker e non il viceversa.

alt text

Fasi del protocollo:

  1. Il Subscriber dichiara presso il broker il proprio interesse a ricevere notifiche riguardo ad un certo argomento (topic) effettuando una chiamata subscribe()
  2. il publisher pubblica un messaggio che riguarda un certo topic effettuando una chiamata publish()
  3. Il broker inoltra il messaggio a tutti i subscriber interessati a quel topic

L’ID MQTT è un identificativo che permette di individuare un dispositivo ma non è un indirizzo di livello 3, non individua la macchina host in base al suo IP, piuttosto è un indirizzo di livello applicativo noto solo ad un server centrale, cioè il broker. Un dispositivo IoT non è tenuto a conoscere l’IP di tutti gli altri dispositivi ma solamente quello del broker. Il broker soltanto sa gli indirizzi di tutti i dispositivi, conoscenza che acquisisce durante la fase di connessione di un client al broker, momento in cui avviene anche il recupero del’socket remoto del client.

Il broker, dal canto suo, associa ogni topic con tutti gli ID che sono registrati presso di esso come subscriber. Questa associazione è utilizzata per smistare tutti i messaggi che arrivano con un certo topic verso tutti gli ID che ad esso sono associati. Il topic diventa così un indirizzo di gruppo. La particolarità di questo indirizzo è che è gerarchico secondo una struttura ad albero, cioè gruppi di dispositivi possono essere suddivisi in sottogruppi più piccoli estendendo il nome del path con un ulteriore prefisso, diverso per ciascun sottogruppo. L’operazione può essere ripetuta ulteriormente in maniera ricorsiva.

Ad esempio, posso individuare le lampade della casa con il path luci e accenderle e spegnerle tutte insieme, ma posso sezionarle ulteriormente con il path luci/soggiorno con il quale accendere o spegnere solo quelle del soggiorno oppure con il path luci/soggiorno/piantane con il quale fare la stessa cosa ma solo con le piantane del soggiorno. Osservando l’albero degli apparati attivi, si vede bene che, in una rete IP WiFi, il client MQTT (con il ruolo di publisher o di subscriber) è sempre il dispositivo IoT.

Osservando l’albero degli apparati attivi, si vede bene che, in una rete LoRaWAN, il client MQTT (con il ruolo di publisher o di subscriber) è sempre il Network Server. Il Netwok Server è anche il gateway della rete di sensori inteso complessivamente come rete LoraWAN. Il gateway dalla rete Lora alla rete IP, in realtà, è il gateway LoRaWAN.

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Il vantaggio del broker MQTT è quello di poter gestire in modo semplice e standardizzato lo smistamento (inoltro) delle misure e dei comandi tra i vari portatori di interesse (stakeholder) di un cluster di reti di sensori, siano essi utenti umani, interfacce grafiche, server applicativi diversi o altri dispositivi IoT.

Alternative ad MQTT

Esistono molte altre soluzioni che magari sono più semplici e graficamente accattivanti ma che passano per portali proprietari o per servizi cloud a pagamento e nulla aggiungono di didatticamente rilevante ai nostri discorsi. Normalmente sono basate su webservices realizzati con protocolli Request/Response quali HTTPS e COAP.

Server di gestione

E’ un client del broker MQTT con funzioni sia di publisher che di subscriber per:

Server di rete

Il network server è comune in alcune tipologie di reti wireless LPWA ed è una componente di back-end responsabile dello smistamento finale verso gli utenti (routing applicativo) dei dati provenienti dai vari gateway configurandosi, quindi, come il centro stella logico di una stella di gateway. Lo schema logico di una rete di sensori LPWA basata su network server quindi appare:

alt text

Funzioni essenziali

Il Network Server, dopo aver elaborato i messaggi ricevuti dai gateway, li inoltra al LoRa App Server. La comunicazione tra il Network Server e l’Application Server generalmente avviene utilizzando HTTP, MQTT o altri protocolli di messaggistica. Il Network Server trasmette i dati dei payload applicativi al LoRa App Server insieme a informazioni di contesto (es. ID del dispositivo, metadati di rete).

Il network server è anche responsabile dello svolgimento di alcuni processi di controllo e gestione della rete:

Server di rete come IS

Il Server di Rete è un dispositivo IS (Intermediate System) che normalmente non è presente nelle reti meshed tradizionali perchè non esiste in queste reti un server deputato a possedere capacità di routing (smistamento). Talvolta, invece, nelle reti mesh è presente un server controller che, però, non è un dispositivo di smistamento IS ma solamente un server responsabile della supervisione, gestione e configurazione di altri dispositivi di rete intesi come IS. Un esempio notevole è il controller degli AP WiFi.

Server di rete come nodo radice

Il server di rete è collegato ai gateway dei sensori mediante una normale rete IP mediante protocollo di livello applicativo. E’ un nodo di smistamento finale e, in questo senso, può essere considerati come dei router di livello applicativo. In pratica è il centro stella di una stella di gateway (o base station) che a loro volta sono il centro stella di una stella di sensori. I gateway sono tutti dello stesso tipo e si collegano, tramite lo stesso protocollo, al network server realizzando, con questo, un collegamento virtuale diretto.

I dati ricevuti possono essere inviati agli application server per le elaborazioni successive oppure è possibile inviare eventuali notifiche agli end device per far attuare un’azione. Non ci sono interfacce standard di trasmissione dei dati tra network server ed application server (webservice, websocket, webhook, MQTT sono variamente implementati).

Quindi sono macchine che partecipano attivamente alle funzioni di rete e pertanto fanno esse stesse parte della infrastruttura di rete. Spesso sono virtualizzate e le loro funzioni sono offerte come servizio su abbonamento. Sono presenti in quasi tutte le infrastrutture LPWA a lungo raggio come LoraWan, Sigfox e NB-IoT.

Gateway

Riassumendo, alla rete di distribuzione IP si collegano, quindi, una o più reti secondarie che servono da rete di accesso per i dispositivi sensori o attuatori con interfacce spesso di tipo non ethernet che necessitano di un gateway di confine con possibili funzioni di:

Comunicazione tra Gateway e Network Server

Comunemente, i gateway utilizzano il protocollo UDP o MQTT per trasmettere i pacchetti al Network Server. Il Network Server riceve i pacchetti, li decodifica, verifica l’integrità e l’autenticità dei messaggi e gestisce la rete (es. ADR, downlink).

Il gateway è uno snodo nevralgico dei messaggi, per cui la sua posizione dovrebbe essere ben nota e accuratamente riportata in planimetria per permettere una sua rapida manutenzione/sostituzione.

Gateway come Client MQTT

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Gateway come MCU hub di sensori

La parola gateway potrebbe talvolta portare a fraintendimenti dovuti al diverso significato nei diversi contesti in cui la si usa. Spesso, con il termine gateway si intente anche il dispositivo IoT che potrebbe essere, a sua volta, un gateway tra la il link di campo, porte analogiche/digitali o BUS, (vedi bus di campo per dettagli) e la rete di sensori (WiFi, Zigbee, LoraWAN, LAN, BLE, ecc.). In questo caso il gateway ha il compito di tradurre i messaggi dall’interfaccia a BUS su filo verso quella LoRaWAN e viceversa. Vedi (dispositivi terminali) per approfondimenti.

Funzioni di una rete LoRaWAN

Le funzioni dell’architettura LoRaWAN possono essere distinte su 3 dispositivi diversi oppure coincidere in un unico dispositivo che le ingloba tutte:

Acesso OTAA

Per abilitare l’accesso OTAA, vanno configurati sia il dispositivo IoT che il network server.

Sul Dispositivo IoT (End-Device) vanno impostati:

Sul Network Server:

La chiave AppKey può essere generata online su cloud di gestione dei dispositivi LoraWAN come TTN, oppure localmente, ad esempio con il comando openssl rand -hex 16.

In realtà, il server genera, automaticamente e in maniera trasparente all’utente, due chiavi:

Formato del payload

In sintesi, la lunghezza dei messaggi LoRaWAN è strettamente correlata alle limitazioni in banda ISM attraverso le restrizioni sul duty cycle e il Time on Air. Gli sviluppatori devono bilanciare la necessità di trasmettere dati con le normative che limitano il tempo di trasmissione per assicurare un uso efficiente e conforme dello spettro radio.

Time on Air (ToA) è a durata della trasmissione di un messaggio, dipende dalla lunghezza del messaggio e dalle impostazioni di trasmissione come il Data Rate e il Spreading Factor (SF). Messaggi più lunghi o l’uso di Spreading Factor più alti aumentano il Time on Air. Poiché il duty cycle limita il tempo totale di trasmissione, messaggi più lunghi riducono la frequenza con cui i dispositivi possono trasmettere senza superare i limiti di duty cycle.

Dettaglio banda ISM 868 MHz

alt text

I messaggi scambiati in una rete LoraWAN sono complessivamente di due tipi che si mappano l’uno sull’altro:

La traduzione non viene fatta normalmente direttamente sul gateway, anche se lui li traduce effettivamente in un JSON di servizio ma senza scompattare il payload applicativo (componente lora-gateway-bridge del gateway). La trasformazione dei dati (come la codifica e decodifica in formato Cayenne LPP) tipicamente avviene a livello di server di rete o di server di applicazione. Ecco come potrebbe essere gestita:

Messaggi lunghi

Esempio JSON solo sensori

{
  "device_id": "1234567890ABCDEF",
  "timestamp": "2024-05-07T12:30:45Z",
  "sensor_data": {
    "temperature": 25.5,
    "humidity": 60.2,
    "battery_voltage": 3.7
  },
  "other_information": {
    "location": {
      "latitude": 40.7128,
      "longitude": -74.0060
    },
    "signal_strength": -110
  }
}

Esempio JSON sensori + attuatori

{
  "device_id": "1234567890ABCDEF",
  "timestamp": "2024-05-07T12:30:45Z",
  "sensor_data": {
    "temperature": 25.5,
    "humidity": 60.2,
    "battery_voltage": 3.7
  },
  "actuator_data": {
    "led": {
      "status": "on",
      "color": "red"
    },
    "motor": {
      "status": "off",
      "speed": 0
    }
  },
  "other_information": {
    "location": {
      "latitude": 40.7128,
      "longitude": -74.0060
    },
    "signal_strength": -110
  }
}

Messaggi corti

Esempio struct sensori + attuatori

#include <iostream>

const int MAX_STRING_LENGTH = 100; // Lunghezza massima per le stringhe

// Definizione della struttura per il payload completo
struct LoRaPayload {
    char device_id[MAX_STRING_LENGTH];
    char timestamp[MAX_STRING_LENGTH];
    float temperature;
    float humidity;
    float battery_voltage;
    char led_status[MAX_STRING_LENGTH];
    char led_color[MAX_STRING_LENGTH];
    char motor_status[MAX_STRING_LENGTH];
    int motor_speed;
    char location[MAX_STRING_LENGTH];
    int signal_strength;
};

Esempio serializzazione sensori + attuatori con la libreria Cayenne

Per la serializzazione dei dati utilizzando il formato Cayenne LPP (Low Power Payload), possiamo adattare la struttura LoRaPayload in modo che i dati siano organizzati secondo le specifiche di Cayenne LPP. Cayenne LPP è un formato compatto e standardizzato per la trasmissione di dati attraverso reti LPWAN (Low Power Wide Area Network), progettato per dispositivi a basso consumo energetico come i dispositivi IoT. Questo formato consente di rappresentare diversi tipi di dati (ad esempio, temperatura, umidità, tensione) in un formato ottimizzato per la trasmissione su reti LPWAN.

Ecco un esempio di come potrebbe apparire una struttura LoRaPayload con la serializzazione Cayenne LPP:

#include <iostream>

const int MAX_PAYLOAD_SIZE = 100; // Dimensione massima del payload Cayenne LPP

// Definizione della struttura per il payload Cayenne LPP
struct CayenneLPP {
    uint8_t buffer[MAX_PAYLOAD_SIZE];
    int size; // Dimensione effettiva del payload
};

// Funzione per aggiungere un valore di tipo float al payload Cayenne LPP
void addFloatToCayenneLPP(CayenneLPP &lpp, uint8_t channel, float value) {
    lpp.buffer[lpp.size++] = channel;
    lpp.buffer[lpp.size++] = 0x02; // Tipo di dati (float)
    lpp.buffer[lpp.size++] = value >> 8; // Byte più significativo del float
    lpp.buffer[lpp.size++] = value & 0xFF; // Byte meno significativo del float
}

// Funzione per aggiungere un valore di tipo int al payload Cayenne LPP
void addIntToCayenneLPP(CayenneLPP &lpp, uint8_t channel, int value) {
    lpp.buffer[lpp.size++] = channel;
    lpp.buffer[lpp.size++] = 0x02; // Tipo di dati (int)
    lpp.buffer[lpp.size++] = value >> 8; // Byte più significativo dell'intero
    lpp.buffer[lpp.size++] = value & 0xFF; // Byte meno significativo dell'intero
}

int main() {
    // Esempio di utilizzo della struttura per creare un payload Cayenne LPP
    CayenneLPP lpp;
    lpp.size = 0; // Inizializza la dimensione del payload a 0
    addFloatToCayenneLPP(lpp, 1, 25.5); // Canale 1: Temperatura
    addFloatToCayenneLPP(lpp, 2, 60.2); // Canale 2: Umidità
    addFloatToCayenneLPP(lpp, 3, 3.7);  // Canale 3: Tensione della batteria
    addIntToCayenneLPP(lpp, 101, -110); // Canale 101: Forza del segnale

    // Output dei dati del payload Cayenne LPP
    std::cout << "Cayenne LPP Payload:" << std::endl;
    for (int i = 0; i < lpp.size; ++i) {
        std::cout << std::hex << static_cast<int>(lpp.buffer[i]) << " ";
    }
    std::cout << std::endl;

    return 0;
}

Gestione bridge broker MQTT

E’ una maniera per fare diventare il network server un client del broker MQTT che sta nella rete di distribuzione centrale.

Serve a realizzare un ponte tra:

alt text

Tutti i topic

Topic in cui recuperare tutti i messaggi associati ad un gateway avente identificativo univoco APP-EUIe a un dispositivo IoT avente un identificativo EUI64 che vale APP-EUI L’associazione può riguardare i topic:

Il payload è un messaggio JSON contenente un campo data e varie informazioni di controllo. Il campo data è codificato in BASE64 e compattato per occupare meno spazio possibile nella tratta dal sensore al gateway.

Un applicativo còient del broker MQTT generale può recuperarare i messaggi di un certo sensore eseguendo il subscribe sul topic lorawan/<APP-EUI>/<DEV-EUI>/+ dove è il MAC del network server mentre / è il MAC del sensore.

lorawan/<APP-EUI>/<DEV-EUI>/+
lorawan/8b-6c-f0-8e-ee-df-1b-b6/00-80-00-ff-ff-00-00-03/+

Solo topic up

Topic up in cui dispositivo è il publisher dei messaggi che vanno nella direzione dal dispositivo al gateway, mentre il gateway è il loro subscriber

lorawan/<APP-EUI>/<DEV-EUI>/up 
lorawan/8b-6c-f0-8e-ee-df-1b-b6/00-80-00-ff-ff-00-00-03/up

Questo topic può essere letto (come subscriber) dal Server applicativo per realizzare una attuazione verso un altro dispositivo o una elaborazione statistica o un salvataggio persistente in un database.

Esempio di payload:

{
  "jver": 1,
  "tmst": 561224395,
  "time": "2023-03-04T23:14:39.522787Z",
  "tmms": 1362006897523,
  "chan": 6,
  "rfch": 1,
  "freq": 903.5,
  "mid": 8,
  "stat": 1,
  "modu": "LORA",
  "datr": "SF9BW125",
  "codr": "4/5",
  "rssis": -14,
  "lsnr": 9.2,
  "foff": -2769,
  "rssi": -13,
  "opts": "03070307",
  "size": 8,
  "fcnt": 1,
  "cls": 0,
  "port": 33,
  "mhdr": "80cb80d000840100",
  "data": "dGVzdGRhdGE=",
  "appeui": "8b-6c-f0-8e-ee-df-1b-b6",
  "deveui": "00-80-00-ff-ff-00-00-03",
  "joineui": "16-ea-76-f6-ab-66-3d-80",
  "name": "JSR-DEBIAN-PC-DOT2",
  "devaddr": "00d080cb",
  "ack": false,
  "adr": true,
  "gweui": "00-80-00-00-d0-00-01-ff",
  "seqn": 1
}

Solo topic down

Topic down in cui gateway è il publisher dei messaggi che vanno nella direzione dal gateway al dispositivo, mentre il dispositivo è il loro subscriber

lorawan/<APP-EUI>/<DEV-EUI>/down
lorawan/8b-6c-f0-8e-ee-df-1b-b6/00-80-00-ff-ff-00-00-03/down

Questo topic può essere scritto (come publisher) dal Server applicativo o da un altro dispositivo IoT per realizzare una attuazione o una configurazione

Gestione firewall

Serve a proteggere l’accesso alla rete di distribuzione che, di base, è IP con indirizzi pubblici.

Può essere impostato per far passare tutto se la rete di distribuzione è sicura come accade, ad esempio, nel caso di una LAN aziendale.

alt text

Beacon

I beacon sono delle sequenze di sincronizzazione (dette preambolo) in grado sia di sincronizzare gli orologi dei dispositivi (Tx e Rx) che si accingono ad iniziare una comunicazione, ma anche di indentificare in maniera univoca i dispositivi che li emettono. Per dei dettagli vedi preambolo di sincronizzazione.

La trama dati compresa tra due beacon consecutivi viene detta supertrama (superframe) ed è generalmente divisa in due zone con politiche di accesso al canale diverse:

Nel contesto di LoRaWAN, un gateway può assumere un ruolo di coordinamento, simile a quello svolto dal PCF in una rete Wi-Fi, gestendo l’accesso al canale nel modo master/slave, quello in cui il centrale ha il ruolo di master che stabilisce quale stazione deve parlare, quando e per quanto tempo, usando una politica di turnazione delle stazioni (polling).

Classi di dispositivi

La specifica LoRaWAN definisce tre classi di dispositivi:

Classe A

In qualsiasi momento un nodo terminale può trasmettere un segnale. Dopo questa trasmissione uplink (tx) il nodo finale ascolterà una risposta dal gateway.

Il nodo terminale apre due slot di ricezione in t1 e t2 secondi dopo una trasmissione uplink. Il gateway può rispondere all’interno del primo slot di ricezione o del secondo slot di ricezione, ma non in entrambi. I dispositivi di classe B e C devono supportare anche la funzionalità di classe A.

alt text

Classe B

Oltre agli slot di ricezione di Classe A, i dispositivi di classe B aprono slot di ricezione aggiuntivi a orari programmati.

Il nodo terminale riceve un beacon sincronizzato col tempo dal gateway, consentendo al gateway di sapere quando il nodo è in ascolto. Un dispositivo di classe B non supporta la funzionalità del dispositivo C.

Il beacon viene inviato ogni 128 secondi a partire dalle 00:00:00 Coordinated Universal Time 13 (UTC), 1 gennaio 1970 più NwkID più TBeaconDelay.

TBeaconDelay è un ritardo specifico della rete scelto nell’intervallo [0:50] ms. TBeaconDelay può variare da una rete all’altra ed è pensato per consentire un leggero ritardo di trasmissione dei gateway. TBeaconDelay deve essere lo stesso per tutti i gateway di una determinata rete. Tutti gli slot di ping dei dispositivi terminali utilizzano il tempo di trasmissione del beacon come riferimento temporale, pertanto il server di rete deve tenere in considerazione questo tempo quando pianifica i downlink di classe B.

alt text

Classe C

Oltre agli slot di ricezione di Classe A, un dispositivo di Classe C ascolterà continuamente le risposte dal gateway. Un dispositivo di classe C non supporta la funzionalità del dispositivo B.

Non c’è un messaggio specifico per un nodo per dire al server che è un nodo di Classe C. Spetta all’applicazione lato server sapere che 13 gestisce i nodi di Classe C in base al contratto passato durante la procedura di join.

alt text

Uplink confermato

Potrebbe essere il caso di un pulsante che comanda l’accensione di un motore, oppure un pulsante di allarme, o anche un apri porta.

alt text

  1. Il dispositivo finale trasmette innanzitutto un frame di dati confermato contenente il payload Data0 in un istante arbitrario e su un canale arbitrario. Il frame counter Cu è semplicemente derivato aggiungendo 1 al precedente frame counter di uplink.
  2. La rete riceve il frame, genera un frame in downlink con il bit ACK impostato, e lo invia esattamente RECEIVE_DELAY1 secondi dopo utilizzando la prima finestra di ricezione del dispositivo finale. Questo frame di downlink utilizza la stessa velocità di dati e lo stesso canale dell’uplink di Dati0. Anche il contatore del frame downlink Cd è derivato aggiungendo 1 all’ultimo downlink verso quello specifico dispositivo finale. Se non c’è alcun payload di downlink in sospeso, la rete genererà un frame senza carico utile.
  3. In questo esempio il frame di ACK non viene ricevuto. Se un nodo finale non riceve un frame di ACK in una delle due finestre di ricezione immediatamente dopo la trasmissione, l’uplink può inviare nuovamente lo stesso frame con lo stesso payload e contatore di frame entro ACK_TIMEOUT secondi dopo la seconda finestra di ricezione.
  4. Questo nuovo invio deve essere effettuato su un altro canale e deve rispettare la limitazione sul duty cycle come qualsiasi altra normale trasmissione.
  5. Se questa volta il dispositivo terminale riceve in downlink l’ACK durante la sua prima finestra di ricezione, appena il frame ACK viene demodulato, il dispositivo terminale è libero di trasmettere un nuovo frame su un nuovo canale.

Downlink confermato

Potrebbe essere il caso di una attuazione che è bene che sia confermata, quale un motore, oppure la riuscita di una configurazione, ecc.

alt text

  1. Lo scambio di frame viene avviato dal dispositivo terminale che trasmette un payload dell’applicazione “non confermato” o qualsiasi altro frame sul canale A.
  2. La rete utilizza la finestra di ricezione downlink per trasmettere un frame di dati “confermato” verso il dispositivo finale sullo stesso canale A
  3. Alla ricezione di questo frame di dati che richiede una conferma, il dispositivo finale trasmette un frame con il bit ACK impostato a sua discrezione. Questo frame potrebbe anche contenere dati (piggybacking) o comandi MAC come carico utile. Questo uplink ACK viene trattato come qualsiasi uplink standard e come tale viene trasmesso su un canale casuale che potrebbe anche essere diverso dal canale A.

Piggy backing

Per consentire ai dispositivi terminali di essere il più semplici possibile e di mantenere il minor numero di stati possibile, è possibile trasmettere un messaggio di ack puro cioè senza dati possibilmente subito dopo la ricezione di un messaggio di dati che richiede una conferma. In alternativa, il dispositivo finale può dilazionare la trasmissione di un ack per collegarlo al successivo messaggio di dati (tecnica del piggy backing).

Formato dei messaggi

alt text

Messaggi MQTT

Messaggi confermati

La conferma dei messaggi inviati da parte del ricevente normalmente non è necessaria nel caso dei sensori. Infatti, se un invio da parte di un sensore non andasse a buon fine, è inutile richiedere la ritrasmissione di un dato che comunque a breve arriva con una misura più aggiornata.

La conferma, invece, è prevista per funzioni di comando o configurazione. Ad esempio nel caso di pulsanti, rilevatori di transito o allarmi in cui l’invio del messaggiò avviene sporadicamente e in maniera del tutto asincrona (cioè non prevedibile dal ricevitore), potrebbe essere auspicabile avere un feedback da parte del protocollo mediante un meccanismo di conferma basato su ack. Ma non sempre ciò è possibile.

La conferma, però, potrebbe pure essere gestita soltanto dal livello applicativo (non dal protocollo) utilizzando un topic di feeedback (o stato) per inviare il valore dello stato corrente subito dopo che questo viene interessato da un comando in ingresso sul dispositivo.

Definizione di topic e payload

Sovente, nella rete di distribuzione IP è presente un server col ruolo di broker MQTT a cui sono associati:

In realtà, il topic di configurazione, pur essendo teoricamente appropriato, potrebbe anche essere incorporato nel topic di comando, magari prevedendo un livello più alto di autorizzazione rispetto ai comandi relativi alle funzioni ordinarie.

Gestione dei topic di comando

Potremmo a questo punto inserire il comando delle luci nel topic più generale delle misure ed attuazioni che chiameremo comandi e registrare i pulsanti del soggiorno al topic luci/soggiorno/comandi come pubblisher, mentre potremmo registrare le attuazioni delle lampade allo stesso topic come subscriber. Il comando potrebbe essere il JSON {"toggle":"true"}, per cui alla fine tutto intero il path diventerebbe luci/soggiorno/comandi/{"toggle":"true"}. Se volessimo selezionare un solo dispositivo sono possibili due strade alternative:

Gestione dei topic di stato

Questo canale viene utilizzato per inviare lo stato di un dispositivo a tutti coloro che ne sono interessati. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di stato potrebbe essere:

Gestione dei topic di configurazione

Questo canale viene utilizzato per inviare comandi di configurazione al dispositivo da parte del server di processo. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di configurazione per, ad esempio, impostare il periodo di pubblicazione automatica dello stato potrebbe essere:

Pagine correlate:

Sitografia:

Torna a reti di sensori