Capitolo 2: La Tecnologia NB-IoT
2.3 Valutazione della Copertura
Uno dei più grandi obiettivi dell’ NB-IoT è l’espansione della copertura rispetto al caso LTE, lo scopo è quello di aumentare il Maximum Coupling Loss (MCL) di 20 dB rispetto al GSM.
Questo miglioramento è ottenuto grazie ai 180 kHz di banda dell’ NB-IoT: il nodo mantiene la stessa potenza trasmissiva del caso LTE ma è concentrata in un intervallo di frequenza ridotto;
il risultato è un’alta PSD (Power Spectral Density) che permette al nodo di raggiungere una distanza maggiore rispetto al GSM.
Nella stima del link budget per il canale NB-IoT downlink ed uplink, consideriamo un SNR minimo di 6 dBm ed un Noise Factor di 6 dB.
Il PRB NB-IoT è 180 kHz e produce un rumore di fondo ridotto rispetto all'elevata larghezza di banda. Con questi parametri andiamo a stimare il MCL per il canale downlink e quello uplink.
Downlink
Per il 3GPP [10] la potenza trasmessa dalla stazione radiobase è di 43 dBm.
In questa stima, il guadagno dell'antenna trasmittente e le perdite sono assunti come zero.
Parametri Valore
Applicando l'equazione del link budget per stimare L’ MCL:
L=PTX+GTX– LTX– SNRmin+174 – 10∗log10(B)– NF+GRX– LRX
L'MCL stimato è 164.44 dB, con un guadagno di 20 dB rispetto al segnale GSM ed è il più alto rispetto ad altre tecnologie IoT[6].
Questo valore di MCL garantisce un’ alta robustezza del segnale alle attenuazioni in modo che si possa raggiungere luoghi angusti come garage e scantinati.
La distanza di copertura per le diverse bande di frequenza viene stimata utilizzando la formula di attenuazione di spazio libero (FSL).
FSL(dB)=32 ,44+20∗log 10(dkm)+20∗log(fMHz)
Uplink
Secondo il 3GPP[10], la potenza di trasmissione sull’ end device è di 23 dBm, consideriamo sempre il guadagno dell'antenna trasmittente e le perdite siano zero.
Parametri Valore
Per la sottoportante con larghezza di banda 3.75 kHz, l’ MCL= 164.25 dB e per la sottoportante a 15 kHz, l’MCL = 158.23 dB.
Siccome il dispositivo NB-IoT è alimentato a batteria, la potenza di trasmissione è stata limitata a 23 dBm (classe di potenza 3) per contenere il consumo energetico.
La distanza di copertura per le diverse bande di frequenza come per il caso downlink viene stimata mediante FSL.
Possiamo definire 3 differenti livelli di Coverage Enhancement (CE): CE0,CE1 e CE2.
CE0 rappresenta il livello di copertura dello standard LTE, mentre nei casi CE1 e CE2 alcuni dei dispositivi che sarebbero fuori copertura in LTE, sono correttamente servito dal nodo di rete.
Mentre in LTE un dispositivo ha una copertura fino a MCL = 144 dBm, in NB‐IoT questo limite inferiore deve essere aggiornato a MCL = 164 dBm.
Tra le possibili tecniche di implementazione di questi livelli di extra-copertura, la più utilizzata è quella delle ripetizioni dei dati in uplink.
Per i diversi livelli CE, l’UE sceglierà un numero diverso di ripetizioni: in CE0, poiché siamo in condizioni LTE standard, l’UE non deve ripetere i dati.
In CE1 l’UE sarebbe fuori dalla copertura LTE, quindi ha bisogno ripetere i pacchetti 2, 4, 8 o 16 volte; infine, in CE2, abbiamo il canale nella peggiore condizione, quindi l’UE deve ripetere il blocco di trasporto 16, 32 o 128 volte.
In NB-IoT, l'utente è in grado stimare il livello di copertura in cui si trova secondo le seguenti operazioni:
1. UE invia il DMRS (Demodulation Reference Signals) all'eNodeB;
2. eNodeB rinvia alla UE il DCI (Downlink Control Information) comunicando all'utente qual è la condizione del suo canale in uplink;
3. Sulla base del DCI, l'UE stima il suo livello CE e il numero relativo di ripetizioni.
Con l'aumento delle ripetizioni nei pacchetti trasmessi e la conseguente introduzione di ridondanza aumenta la possibilità per l'EnodeB di decodificare correttamente
il messaggio inviato dall’ UE, ma d'altra parte diminuisce la capacità del sistema.
Capitolo 3
Sodaq Sara R412M
3.1 Introduzione
La scheda utilizzata per testare il NB-IoT è la Sodaq SARA R412M (Figura3.1).
Si tratta di una scheda di sviluppo che supporta sia NB-IoT che LTE-M e che consente l’accesso a tutte le bande di frequenza NB-IoT/LTE-M disponibili, questo implica una totale copertura in Europa, Nord America, Africa ed Asia [11].
Il nome "SARA R412M" deriva dal modulo cellulare ublox utilizzato all'interno di questa scheda: l’ ublox SARA R4.
Figura 3.1: Scheda Sodaq Sara R412M
3.2 Ublox SARA R4
I moduli della serie SARA R4 [12] sono delle soluzioni multi-mode LTE Cat M1, LTE Cat NB1 ed EGPRS che offrono possibilità di trasmissione dati con velocità fino a 375 kb/s in un intervallo di temperatura operativa esteso da –40 °C a +85 °C con un basso consumo
energetico.
Come si può vedere dal diagramma a blocchi (Figura 3.2) il dispositivo presenta molte
opzioni di interfaccia e uno stack IP integrato (Figura 3.3), i moduli della serie SARA R4 sono la scelta ottimale per le applicazioni LPWA che necessitano di una velocità di trasmissione dati medio/bassa, nonché per i dispositivi che richiedono una lunga durata della batteria, come quelli utilizzati nella misurazione intelligenti, telemetria e per il monitoraggio remoto.
La flessibilità del modulo ublox ci permette di selezionare solamente la modalità preferita di trasmissione, che nel nostro caso sarà NB1.
Figura 3.2: Diagramma a blocchi ublox Sara R4
3.3 Moduli scheda Sodaq Sara R412M
Per quanto sia potente il modulo ublox R4 da solo non può rendere la scheda SODAQ SARA completa.
Per questo motivo intorno al modulo, è stata sviluppata una scheda a basso consumo
alimentata con una batteria Li-Po, in aggiunta come possibile ricarica della batteria, abbiamo un connettore JST dedicato dove è possibile attaccare un pannello fotovoltaico.
Nella scheda sono stati integrati una vasta gamma di moduli (Figura 3.4) come:
• il microcontrollore Atmel SAMD21;
• GPS (uBlox M8Q per GPS, Galileo, GLONASS e supporto Beidou);
• Sensori (magnetometro digitale LSM303AGR e accelerometro);
• Antenna realizzata su PCB esterno, connettorizzata U.FL;
• Connettore Micro USB;
• lettore micro SIM.
Figura 3.3: Sommario Funzioni Principali ublox SARA R4
3.4 Arduino e l’ implementazione degli sketch nella scheda Sodaq SARA
La scheda Sodaq Sara R412M è compatibile con Arduino, quindi per programmarla possiamo utilizzare il software Arduino IDE (Figura 3.5).
Per permettere la stesura del codice sorgente, l'IDE include un editor di testo avanzato, inoltre caricando le apposite librerie, l’editor è in grado di compilare e caricare direttamente nella scheda Sodaq il programma eseguibile (detto anche sketch) con un solo click.
Figura 3.4: Moduli della scheda di Sviluppo Sodaq SARA R412M
I programmi di Arduino [13] sono scritti in linguaggio derivato dal C/C++, ma all'utente per poter creare un file eseguibile, si richiede solo di definire due funzioni:
• Void Setup: funzione che viene invocata solo una volta all’inizio del programma e che viene utilizzata per configurare il setting iniziale.
Non viene modificata durante l’esecuzione del programma.
• Void Loop: funzione che viene invocata ripetutamente, la cui esecuzione si interrompe solo quando viene tolta l’alimentazione alla scheda oppure viene premuto il tasto di reset.
Figura 3.5: Interfaccia Arduino IDE
3.5 Utilizzo degli AT commands
La scheda Sodaq SARA R412M supporta l’utilizzo degli AT commands [14] secondo gli standard 3GPP.
Gli AT commands sono uno specifico insieme di comandi originalmente sviluppato per il modem Hayes Smartmodem da 300 baud.
La stringa di inizializzazione consiste in una serie di comandi che prepara il modem per la comunicazione, impostando caratteristiche come il tipo di connessione, tempi di attesa, rilevazione del segnale di occupato e molti altri.
Ogni funzione del modem è governata dal relativo comando AT.
Per inviare un comando occorre trasmettere sulla porta seriale del modem una stringa ASCII formata da AT seguito da uno o più comandi e da un carattere di ritorno a capo (CR).
Per utilizzare gli AT commands sulla scheda Sodaq SARA R412M utilizziamo lo sketch riportato in Figura 3.6.
Una volta caricato lo sketch nella scheda, tramite il monitor seriale dell’ Arduino IDE possiamo inviare i comandi al nostro dispositivo (Figura 3.7).
Figura 3.6: Sketch Arduino per utilizzare gli AT Commands
Figura 3.7: Esempio monitor seriale con AT commands
Capitolo 4
MQTT e Trasmissione dati
4.1 Il Protocollo MQTT
La scheda precedentemente presentata è stata utilizzata per sviluppare un programma che rilevi i dati ambientali e la posizione tramite GPS.
I dati rilevati sono trasmessi, utilizzando una connessione NB-IoT, ad un MQTT Broker.
L'elaborazione e la visualizzazione dei dati avvengono su un PC.
Per inviare i dati alla piattaforma si è scelto di utilizzare il protocollo MQTT, che è stato progettato per situazioni dove la banda è limitata.
L'implementazione del codice MQTT è piuttosto snella, in quanto il protocollo è ben supportato dalla piattaforma Arduino.
MQTT (Message Queue Telemetry Transport) è un protocollo ISO Standard (ISO/IEC PRF 20922) [15] realizzato nel 1999 da Andy Stanford-Clark (IBM) e Arlen Nipper [16].
MQTT per scambiare informazioni, sfrutta un meccanismo di pubblicazione e sottoscrizione (pubblish-subscrive) di messaggi tramite un apposito message broker, in grado di gestire migliaia di client contemporaneamente.
Si tratta di un’ottima alternativa al modello client/server, dove ad instaurare una connessione diretta con il server è il client.
In MQTT, se un client vuole comunicare con un altro, pubblica un messaggio su un certo argomento (detto topic) sul message broker.
Un client MQTT è un qualsiasi dispositivo che esegue una libreria MQTT e si collega a un broker MQTT su una rete.
Il message broker (Figura 4.1) ha il compito di filtrare e distribuire le comunicazioni tra pubblisher e subscriber e tiene conto delle sessioni di tutti i client.
Un' altra funzione del broker è l'autenticazione e l'autorizzazione dei client, bisogna prestare attenzione alla configurazione del broker, perché spesso è il componente connesso
direttamente ad Internet e quindi il più esposto ad attacchi informatici.
Ogni client può iscriversi a molteplici topics, ogni volta che viene pubblicato un nuovo messaggio in un determinato topic, il message broker lo distribuisce a tutti i client iscritti a quel determinato topic.
Il Topic è una stringa UTF-8 con struttura simile a quella di una directory e i livelli dei topics, sono separati da uno slash (/).
Possiamo quindi creare dei topic secondo determinati criteri, ad esempio per la nostra scheda SODAQ SARA R412M possiamo fare in modo che le rilevazioni della posizione GPS vengano pubblicate sul topic: sodaq/GPS.
Per nominare i livelli dei topics è possibile utilizzare degli spazi e caratteri speciali, ma è bene tenere presente che utilizzare delle lettere minuscole o maiuscole per il nome di un
determinato livello, lo rende diverso (case sensitive).
Oltre a poter eseguire l’iscrizione ad un topic specifico, utilizzando il simbolo # è possibile iscriversi a tutti i topics di livello successivo a quello indicato (Es: sodaq/# in questo modo, si è eseguita la sottoscrizione per tutti i topics della scheda).
Per la trasmissione di messaggi tramite MQTT, è necessario conoscere IP, porta del broker e i parametri necessari per l’autenticazione.
Prendendo come esempio un sistema di monitoraggio di parametri ambientali, per inviare i dati rilevati del sensore, il sistema dovrà:
1. Instaurare una connessione con l’ MQTT broker;
2. Pubblicare in un determinato topic le rilevazioni effettuate (es. sodaq/umidità).
Per accedere in tempo reale alle rilevazioni che vengono trasmesse dal sistema di monitoraggio, si dovrà:
Figura 4.1: Processo MQTT[17]
2. Sottoscriversi al topic sul quale vengono pubblicate le rilevazioni ed aspettare la ricezione dei dati.
I parametri da inviare al topic di pubblicazione devono essere in formato JSON.
JSON (JavaScript Object Notation) è un semplice formato per lo scambio di dati, che risulta facile da scrivere per le persone ed altrettanto facile per le macchine analizzarne la sintassi [18].
JSON è un formato di testo completamente indipendente dal linguaggio di programmazione, ma utilizza convenzioni conosciute dai programmatori di linguaggi della famiglia del C, come C, C++, JavaScript, Python e molti altri.
Questa caratteristica fa di JSON il linguaggio ideale per lo scambio di dati per MQTT.
JSON è basato su due strutture:
• Un insieme di coppie nome/valore;
• Un elenco ordinato di valori.
Queste sono strutture di dati universali, tutti i linguaggi di programmazione moderni li supportano in entrambe le forme, nella Figura 4.2 viene riportato un esempio di rappresentazione di un oggetto in JSON.
Un oggetto è una serie non ordinata di nomi/valori che inizia con una parentesi graffa sinistra
”{” e finisce con una parentesi graffa destra ”}” ed ogni nome è seguito da 2 punti : e la coppia nome/valore è separata da una virgola.
4.2 Realizzazione Programma
Per la realizzazione del programma viene utilizzato Arduino IDE con l’aggiunta delle librerie fornite dalla Sodaq per questa scheda: Sodaq_R4X [19].
Le parti di codice riportate nella tesi sono: il Void Setup, la funzione per inviare i dati del GPS e il Void Loop.
4.2.1 Void Setup
L’esecuzione della funzione Void Setup (Figura 4.3) consiste di di diverse fasi.
Nella fase iniziale vengono abilitati i sensori presenti sulla scheda (tra cui l’accelerometro) e il GPS.
La fase successiva consiste nell’accensione e inizializzazione del modem per far si che la scheda possa connettersi alla rete mobile.
Successivamente attraverso la funzione r4x.connect presente nella libreria Sodaq di effettuare la connessione.
I parametri necessari per connettersi sono l’APN, nel nostro caso nbiot.tids.tim.it e URAT (uguale ad 8) che specifica l’utilizzo della tecnologia NB-IoT.
La scheda può essere utilizzata anche con altre modalità: URAT=7 indica LTE-M.
Figura 4.2: Esempio rappresentazione di un Oggetto in JSON [17]
Quando la connessione alla rete è riuscita, il passo successivo è la connessione con il Broker MQTT attraverso le funzioni:
• r4x.mqttSetServer, realizza la connessione al server;
• r4x.mqttSetAuth, fornisce i parametri di autenticazione per accedere al server;
• r4x.mqttlogin, effettua il login sul server.
Una volta completata la fase di Setup si passa all’ invio dei dati al MQTT Broker.
4.2.2 Void Loop
Con il Void Loop (Figura 4.4) vengono richiamate tutte le funzioni inserite nello sketch Arduino per leggere i parametri della scheda, del GPS e dei sensori, inoltre è presente un ritardo di 30 secondi tra l’invio di un set completo di dati ed un altro.
Figura 4.3: Void Setup
4.2.3 Funzione sendGPSThroughMQTT()
Con la funzione sendGPSThroughMQTT() inviamo al MQTT Broker i dati rilevati dal GPS.
La funzione (Figura 4.5) trasmette i dati al MQTT Broker se il risultato della condizione if da esito positivo (sodaq_gps.scan(true)), altrimenti la funzione non trasmette nessun dato al Broker.
Se il risultato della condizione if è true, allora si crea una stringa di dati (chiamata reading) che al suo interno presenta i seguenti valori:
• Latitudine: sodaq_gps.getLat(),5 (dove il 5 rappresenta le cifre dopo la virgole);
• Longitudine: sodaq_gps.getLon(),5;
• Altitudine: sodaq_gps.getAlt();
• Velocità: sodaq_gps.getSpeed();
• Numeri Satelliti: sodaq_gps.getNumberOfSatellites();
• HDOP: sodaq_gps.getHDOP();
• Data ed Ora: sodaq_gps.getDateTimeString().
La stringa dati viene poi trasmessa al MQTT broker con l’utilizzo della funzione
r4x.mqttPublish, in cui bisogna specificare il topic desiderato sul quale pubblicare i dati e la stringa da pubblicare.
Figura 4.4: Void Loop
4.3 Sensore BME 280 per il rilevamento di dati ambientali
Per simulare una reale applicazione della scheda Sodaq SARA R412M e analizzare il suo comportamento si è aggiunto alla scheda un sensore BME280.
Si tratta di un sensore ambientale che permette la rilevazione di temperatura, pressione barometrica e umidità (Figura 4.6).
Figura 4.6: Sensore BME 280
Figura 4.5: funzione sendGPSThroughMQTT()
Questo sensore è ottimo per tutti i tipi di rilevamento meteorologico/ambientale ed è una delle migliori soluzione di rilevamento a basso costo per misurare l'umidità (precisione di ± 3%), pressione barometrica (con precisione assoluta di ± 1 hPa) e temperatura (precisione di ± 1,0
°C) [20].
4.3.1 Rilevamento dati sensore BME 280
Con la creazione della funzione SendBME280MQTT() si rilevano i dati del sensore e poi vengono inviati al MQTT Broker.
La funzione (Figura 4.7) trasmetterà:
• Temperatura: utilizzando bme.readTemperature();
• Pressione: utilizzando bme.readPressure();
• Umidità: bme.readHumidity().
In Figura 4.8 è riportato un esempio dei dati rilevati con il Sensore BME 280 utilizzando il monitor seriale di Arduino (nel nostro sketch l’ altitudine è stata omessa perché quella proveniente dal sensore BME 280 è realizzata tramite un’approssimazione, si preferisce utilizzare quella del GPS).
Figura 4.7: Funzione Sensore BME 280
4.4 MQTT Broker
Il Broker MQTT è la parte fondamentale e più importante in una trasmissione MQTT.
Il Broker che abbiamo scelto di utilizzare è Mosquitto[21].
Mosquitto è un’implementazione completamente open-source di un broker MQTT (Figura 4.9), si tratta di un progetto che fa parte della fondazione Eclipse e che è possibile scaricare ed installare in un qualsiasi PC.
Per fare in modo che il progetto possa essere controllabile e modificabile direttamente via internet abbiamo utilizzato un server cloud che già implementa al suo interno il broker Mosquitto: CloudMQTT.
Figura 4.8: Esempio visualizzazione dati BME 280
4.4.1 CloudMQTT
CloudMQTT [22] è uno dei più semplici broker Mosquitto basati su cloud.
È possibile selezionare diversi piani di utilizzo, tra cui è presente anche un piano free, che ci consente di configurare l’istanza di broker CloudMQTT che poi verrà eseguita sui loro server hardware.
Con il piano gratuito possiamo connettere fino a 5 dispositivi pubblish/subscribe.
Quindi in modo facile possiamo realizzare un broker online pronto per l'uso per un progetto che necessiti di MQTT.
4.4.2 Configurazione CloudMQTT
Una volta connessi al sito [22], il primo passo da fare è creare una nuova istanza del Broker basato su Mosquitto (Figura 4.10), il servizio CloudMQTT si appoggia al Sistema AWS (Amazon Web Services).
Figura 4.9: Funzionamento Mosquitto
Figura 4.10: Creazione istanza CloudMQTT
Una volta creata la nuova istanza, scelto su quale Data Center vogliamo creare il nostro MQTT Broker (Figura 4.11) la configurazione è terminata.
La nostra istanza è già pronta e funzionante (Figura 4.12), basta solamente inserire nel nostro sketch Arduino i parametri necessari per accedere al Broker:
• MQTT_SERVER_NAME: farmer.cloudmqtt.com;
• MQTT_SERVER_PORT: 15955;
• MQTT_SERVER_USR: l’username assegnato da CloudMQTT;
• MQTT_SERVER_PSW: la password assegnata da CloudMQTT.
La porta viene direttamente assegnata dal sistema CloudMQTT e nell’istanza free non è modificabile, invece utilizzando un piano a pagamento che ci consente di avere un server dedicato, la porta MQTT utilizzata è la 1883 oppure la 8883 nel caso di MQTT over SSL.
Figura 4.11: Selezione Data Center CloudMQTT
All’interno di CloudMQTT è presente anche un Websocket per monitorare i processi in tempo reale (non è possibile vedere lo storico dei dati), i messaggi che arrivano dai dispositivi
(Figura 4.13) e c’è anche la possibilità di inviare messaggi ai dispositivi attraverso la funzione Send message.
Figura 4.12: Informazioni Istanza CloudMQTT
Figura 4.13: Interfaccia Websocket CloudMQTT
4.5 Node-RED: interfaccia Grafica per la visualizzazione dei dati
Una volta che il nostro dispositivo è connesso ed invia dati al Broker MQTT, è necessario per chi effettua un Subscrive al topics poter estrarre e decodificare i dati ricevuti e visualizzarli su un qualsiasi dispositivo, sia esso uno Smartphone (es. utilizzando l’app Android IoT MQTT Panel) oppure un PC.
Per visualizzare i dati su un PC utilizziamo Node-RED (Figura 4.14).
Node-RED [23] è uno strumento nato con l’idea di gestire il mondo dell’ IoT tramite il paradigma dei flussi di dati, sviluppato originariamente da IBM e poi rilasciato sotto licenza Apache 2.0, è completamente scritto in JavaScript e gira su Node.js (piattaforma basata sul JavaScript Engine V8 di Google).
Nei flussi di Node-RED viaggiano pacchetti di dati, che saltano da un nodo (i singoli oggetti del menù a sinistra, Figura 4.14) all’altro eseguendo azioni, calcoli, analisi ed eventi tramite javascript.
Il risultato dell’elaborazione può essere rediretto verso siti web, dashboard, sensori ed ogni altro apparecchio o servizio che riusciamo ad interfacciare.
Una volta installato ed avviato (Figura 4.15), possiamo lanciare il nostro web browser e digitare l’indirizzo:
• http://localhost:1880
e ci troveremo di fronte alla schermata iniziale (Figura 4.14).
Node-RED possiede un interfaccia web molto chiara: sulla sinistra troviamo i nodi disponibili suddivisi per categorie; selezionandoli singolarmente, vi troveremo nella finestra di destra una descrizione, un esempio di utilizzo e i dettagli relativi.
Un messaggio che viaggia nel flusso, viene detto msg ed è un parametro fondamentale.
Il payload o msg.payload che contiene il messaggio (sia esso una stringa, JSON, numerico od altro) da inviare al nodo successivo, il quale lo userà per l’operazione per cui è stato
programmato.
Figura 4.14: Schermata iniziale Node-RED
Figura 4.15: Avvio Node-RED
Un esempio di utilizzo è riportato nella Figura 4.16:
i dati in arrivo dal Broker MQTT sono delle stringhe JSON.
Per essere manipolate dal programma è necessario convertirle in un oggetto JSON; una volta ottenuto l’ oggetto JSON possiamo selezionare al suo interno il valore desiderato (es.
payload.t.value) ed utilizzarlo per i nostri scopi (in questo caso realizzare un grafico della Temperatura della scheda Sodaq ed un indicatore della temperatura attuale).
Il flow completo che abbiamo realizzato è rappresentato nella Figura 4.17.
Figura 4.16: Esempio Utilizzo Node-RED
Una volta completato il flow può essere mandato in esecuzione, premendo semplicemente il pulsante Deploy (si vede nella Figura 4.14 posizionato in alto a destra).
A questo punto Node-RED si connette al Broker CloudMQTT (è necessario inserire
A questo punto Node-RED si connette al Broker CloudMQTT (è necessario inserire