focus

I PROTOCOLLI APPLICATIVI NEL MONDO IOT

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020

GESTIONE DEL SISTEMA
Per capire meglio il funzionamento...

focus

Indice

4 I PROTOCOLLI APPLICATIVI

5 MQTT (MQ TELEMETRY TRANSPORT)

6 CONNECT E PUBLISH

7 HTTP (HYPER TEXT TRANSFER PROTOCOL)

8 COAP (CONSTRAINED APPLICATION PROTOCOL)

12 MISURA IMPULSO DI CORRENTE SU TX

11 APPENDICE E GLOSSARIO

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 2

 focus
INFORMAZIONI

I protocolli
applicativi nel
mondo IOT

Competence in key areas of I’m looking for new technical challen-

management and leadership, ges and solve them using my knowle-
production con-rol, sw development, dge and former experiences.
supplier qualification,

Ing. FABIO GATTI

Esperto IoT e wireless

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 3

 focus

IOT

I PROTOCOLLI APPLICATIVI NEL MONDO IOT

Introduzione
I protocolli applicativi rivestono un ruolo fon-
damentale in quanto hanno la responsabilità
di veicolare i dati dal device per giungere al
Cloud in un formato utilizzabile per applica-
zioni successive. L’attenzione del progettista
viene spesso spostata in favore di un mag-
giore approfondimento dei livelli PHY/MAC:
in questo articolo vedremo invece che i pro-
tocolli applicativi hanno un ruolo importante
nelle prestazioni sia in termini di consumo
energetico che relativamente alle tematiche
di sicurezza e affidabilita’ del Sistema.

Architettura
Un device IOT scambia dati con il cloud uti-
lizzando uno stack protocollare in grado di
comunicare, normalmente tramite link wire-
less, con un dispositivo gateway locale oppu-
re direttamente con una rete di telecomuni-
cazioni (fig. 1).

L’applicazione installata sul device scambia

dati, prevalentemente in uplink, con i servizi
Cloud tramite i diversi livelli dello stack pro-
tocollare (fig. 2).
A livello applicativo sono disponibili diver-
se scelte che influenzano direttamente le
prestazioni del sistema in termini di banda,
consumo energetico, range. Il documento
analizza 3 diversi protocolli applicativi evi-
denziandone i dettagli, l’overhead introdotto
sul dato e i risvolti sul consumo energetico.
FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 4
 focus

Ambiente di test chetto al server Thingsboard con 3 diversi Protocolli applicativi

L’ambiente di test e’ stato realizzato con i se- protocolli, MQTT, HTTP e COAP Viene analizzato il comportamento della
guenti dispositivi: scheda in termini di corrente e struttura del
• Device: Scheda ST B-L475E-IOT01A2 pacchetto per i 3 protocolli riportati.
Misura
• Wireless link: wifi con scheda ISM-
Durante il ciclo di invio del pacchetto, un os-
43362-M3G-L44 MQTT (MQ Telemetry Transport)
cilloscopio con sonda di corrente sulla linea
• Gateway: Raspberry PI 3 model B+ MQTT e’ un protocollo binario ISO standard
di alimentazione 1 della scheda ST (tensione
• Server: thingsboard.io (ISO/IEC PRF 20922) di messaggistica di tipo
di alimentazione 5V) rileva il profilo di cor-
Lo schema di collegamento tra i diversi sotto publish/subscribe posizionato on top allo
rente. Sulla scheda e’ stato installato il sof-
sistemi e’ riportato in fig. 3: stack tcp/ip.
tware Mshark per il tracciamento del dettagli
della comunicazione. Mshark analizza i dati a Il protocollo prevede un chiamata alla pri-
Abbiamo installato un programma applica- mitiva CONNECT per l’invio dei parametri,
valle del driver di rete in modo da accedere ai
tivo sulla scheda ST che realizza un ciclo di tipicamente livello di servizio e username/
dati in chiaro, mentre la trasmissione radio e’
lettura dei sensori a bordo e l’invio del pac- password, e una successiva PUBLISH:
cifrata con protocollo WPA2.

——————————
1 La scheda ST e’ equipaggiata con jumper JP5 per la misura di corrente situato sulla parte posteriore della board. Il collegamento sezionato dal jumper non alimenta il trasmettitore radio.

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 5

 focus

Analizziamo di seguito le 2 primitive principali, CONNECT e PUBLISH.

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 6

 focus

Principali caratteristiche Osservazioni HTTP

• Protocollo binario compatto
• Richiede TCP
• Client semplice da realizzare
• Semantica dati in JSON
• Topic fa parte del messaggio:
fare attenzione a limitare la dimensione
• Password in chiaro
• Sicurezza con TLS
Notare come il protocollo invii in chiaro il pa- (Hyper Text Transfer Protocol)
rametro user name. Questo comporta quin- Http e’ un protocollo di trasferimento dati
di la necessita’ di un sistema crittografico a REQUEST/RESPONSE sotto forma di ipertes-
livello di rete. Il parametro topic fa parte del to basato sullo stack tcp/ip. I dati possono es-
payload della publish: al fine di contenere la sere trasportati utilizzando le primitive GET o
lunghezza dello stesso e’ opportuno sceglie- POST a seconda che si utilizzi l’URL oppure il
re un topic di lunghezza ridotta. BODY del messaggio.

Nell’esempio riportato e’ stata seguita la seconda opzione. Il protocollo e’ piuttosto prolisso: si osservi la lunghezza di 304 byte per il tras-
porto di 57 byte di informazione. Anche in questo caso il contenuto e’ in chiaro, esponendo il parametro User name all’interno dell’URI

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 7

 focus

Principali caratteristiche
• Protocollo molto verboso (overhead)
• Richiede TCP
• Client complesso da realizzare (parsing)
• Password in chiaro
• Sicurezza con HTTPS
• RESTful

Osservazioni COAP (Constrained Application Supporta 4 tipi di messaggi:

Notare come il protocollo invii in chiaro il Protocol) • Confirmable (CON)
parametro user name. Questo comporta un Coap e’ un semplice protocollo REQUEST/ • Non-Confirmable (NON-CON)
sistema crittografico a livello di rete. Il para- RESPONSE a basso overhead progettato per • Ack
metro topic fa parte del URI. device constrained (ovvero di potenza e ca- • Reset
pacità di calcolo limitate) del mondo IOT e
definito in RFC 7252. Lo stack utilizza UDP Nell esempio seguente vediamo l’utilizzo
come livello di trasporto sulla porta standard del tipo CON:
5683.

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 8

 focus

Di seguito riportiamo il messaggio di conferma (ricordare che il messaggio di origine e’ di tipo CON).

Osservare come la risposta riporti l’identificativo del messaggio in quanto utilizzando il servizio di trasporto
UDP non e’ garantito l’ordine di arrivo dei messaggi.

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 9

 focus

Principali caratteristiche Osservazioni Overhead

• Protocollo molto leggero adatto a oggetti
constrained
• Richiede un servizio datagram, non neces-
sario IP (es. SMS)
• Gestisce i duplicati
• Gestisce la QoS a livello applicativo (conf
/ non conf)
• Client complesso (poca documentazione)
Anche Il messaggio COAP mostra il parame-
tro username in chiaro: puo’ essere necessa-
rio aggiungere quindi un livello di sicurezza.
Su COAP abbiamo due scelte possibili DTLS
oppure IPSEC.
Abbiamo visto che I protocolli analizzati in-
troducono una certa ridondanza (overhead)
in quanto introducono informazioni aggiun-
tive. Riportiamo nella seguente tabella il cal-
colo dell’overhead nel caso di trasferimento
di 57 byte:

HTTP risulta la scelta più verbose in quanto COAP e MQTT risultano comparabili ma va scelta questa che va ponderata valutando gli
non e’ stato progettato specificatamente per osservato che MQTT richiedere una chiamata effetti sul microcontrollore del device e sulla
l’IOT ma deriva dai vecchi sistemi di calcola- aggiuntiva (CONNECT) e l’apertura di due so- RAM.
tori. cket TCP rispetto agli endpoint UDP di COAP,

Riportiamo infine i diversi assorbimenti necessari per la trasmissione del segnale:

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 10

 focus

La scelta ricade quindi su MQTT o COAP dato Si tratta di una scelta molto importante per DUT per verificare tutti gli aspetti (carico del
che HTTP richiede un picco di corrente deci- il progettista, spesso trascurata rispetto ai processore, allocazione della RAM) della pia-
samente maggiore. classici livelli PHY/MAC, in quanto influenza ttaforma.
l’overhead della trasmissione e consente il
Conclusioni fine tuning del Sistema. Appendice
In questo articolo abbiamo analizzato 3 di- Mshark: procedura di installazione
versi protocolli applicativi per il trasporto Da questa analisi risulta che MQTT e COAP Riportiamo di seguito la procedura di ins-
delle informazioni, mostrando i dettagli dei sono i protocolli più indicati per il mondo tallazione dell’analizzatore di protocollo su
pacchetti, l’efficienza di trasporto e la misura IOT ma e’ comunque necessario procedere Raspberry PI per tutti gli interessati a ripete-
di corrente per la trasmissione del dato. poi ad una analisi di dettaglio sul proprio re le prove descritte.

Glossario Riferimenti
COAP Constrained Application Protocol RFC2616 Hypertext Transfer Protocol
DUT Device Under Test RFC7252 The Constrained Application Protocol
HTTP Hyper Text Transfer Protocol (CoAP)
MQTT MQ Telemetry Transport ISO/IEC 20922:2016 MQ Telemtry Transport
RFC Request for Comment
TCP Transmission Control Protocol
UDP User Datagram Protocol

FARE ELETTRONICA FOCUS - Nº 4 - LUGLIO 2020 11