1.
MQTT: il protocollo che rende possibile
l’Internet Of Things
Davide Pozza – Omnys (www.omnys.com)
davide.pozza@omnys.com
http://it.linkedin.com/in/davidepozza
1

2.
/42
Davide Pozza
▪ Mi occupo di progettazione e delivery di infrastrutture software
“mission critical”
▪ Negli anni ho avuto modo di affrontare tematiche funzionali e
tecnologiche relative agli ambiti più svariati tra cui:
▪ Internet banking
▪ Ecommerce ed integrazione con sistemi di legacy
▪ ICT e telecomunicazioni
▪ Interazione con dispositivi “smart”
▪ Sono socio di Omnys, software house presente sul mercato dal
09/09/1999 che si occupa principalmente di:
▪ System Integration e Architetture Cloud
▪ Piattaforme web (ecommerce, turismo, infomobilità, editoria digitale)
▪ APP mobile
▪ Internet of Things (wearable, medical, home automation)
2

3.
/42
The Internet of Things
3
▪ Smartphone & wearable
▪ Controllo veicoli, persone,
animali, …
▪ Dispositivi embedded
▪ Automazione industriale
▪ Monitoraggio consumi
energetici
▪ Impianti di sicurezza e
sorveglianza
▪ Smart Building/Home & City
▪ Telemedicina e Salute
▪ Everyday things…

4.
/42
Verso l’interconnessione totale
“The Web is becoming more and more pervasive as an applications
platform, and effective standards are crucial for reducing the costs of
deploying applications across a wide range of devices and
environments, whether in the office, at home or on the move.
The Ubiquitous Web will provide people with access whenever and
wherever they find themselves, with applications that dynamically
adapt to the user's needs, device capabilities and environmental
conditions.”
Philipp Hoschka,
Ubiquitous Web Domain Leader
Ubiquitous
Web
Web 1.0 Web 2.0 Social Web
Mobile
Web
4

5.
/42
Una crescita esponenziale
A fine del 2014:
9 miliardi di dispositivi connessi
Entro il 2020:
• 57.000/sec
nuovi dispositivi che
si connetteranno
• 212 miliardi
di dispositivi in grado
di connettersi
• 30 miliardi
di dispositivi
connessi
5

6.
/42
Internet of Things: il problema
Persone +
Oggetti +
Sensori +
Dispositivi =
tantissimi endpoint
che emettono segnali
6

7.
/42
Internet of Things: una nuova sfida
▪ Richiede un modello di
comunicazione in real-time ed
event-driven
▪ Le informazioni devono poter
essere inviate in modalità one-to-
many
▪ Capacità di recepire (“listening”)
un evento non appena si verifica
▪ Necessità di ridurre al massimo la
dimensione dei pacchetti dati
scambiati
▪ Necessità di gestire l’invio di
messaggi anche su reti degradate
(reliability)
7

8.
/42
L’HTTP è adatto per gestire SEGNALI?
▪ E’ “document-centric” (XML, ecc) e basato sul paradigma request/
reply
▪ Ha un elevato overhead di rete
▪ E’ estremamente verboso: PUT/POST/GET/DELETE prevedono
comunque l’invio di molti bytes e non sono sempre la scelta migliore
nello sviluppo di applicazioni dove la comunicazione deve essere
“ultralight”
▪ Non prevede nessuna garanzia built-in sulla comunicazione
8

9.
/42
Internet of Things: non è il WEB!
▪ I firmware dei dispositivi
sono limitati (potenza,
memoria, batteria)
▪ Possono essere necessari
anche migliaia di dispositivi
per monitorare un sistema
industriale (es. gasdotti,
piattaforme petrolifere,…)
▪ La connettività può essere
molto degradata e/o
estremamente costosa
(GPRS, Satellite)
9

10.
/42
L’alternativa
MQTT = MQ TELEMETRY
TRANSPORT
“A light weight event and message oriented
protocol allowing devices to asynchronously
communicate efficiently across constrained
networks to remote systems”
10

11.
/42
MQTT: i principali benefici
▪ Rende semplice la connessione tra il
mondo degli oggetti e il mondo dell’ IT
evitando il “polling” dei sensori
▪ Consente la trasmissione di dati su reti
soggette a frequenti interruzioni
▪ Fornisce il massimo disaccoppiamento
possibile garantendo comunque la
trasmissione/ricezione dei dati (QoS)
▪ Riesce a gestire la comunicazione
con un elevato numero di dispositivi
11

12.
/42
Il protocollo MQTT in SINTESI
• Semplice: solo 3 funzioni:
– connect + publish + subscribe (un client può funzionare su un controller a 8 bit e
256kb di RAM)
• Affidabile: QoS per supportare reti degradate
• Leggero: overhead minimo ed estrema efficenza:
– no envelope, o headers; pacchetti anche da 2 bytes
• Aperto: standard definito e aperto (royalty-free)
12

13.
/42
Il trend di interesse per l’MQTT
Google Trends evidenzia un interesse in forte crescita in relazione al
termine “MQTT”
13

14.
/42
Ambito dell’MQTT
Intelligence & Analytics
Traditional Backend
Systems
BigData
Interconnection
Mobile & Web Embedded Controllers, Sensors, Actuators, …
Data/Alert
Respond
Control
Sense
14

15.
/42
Il modello Publish/Subscribe
▪ Il PUBLISHER invia (publish) un
messaggio su un TOPIC (subject)
▪ Il SUBSCRIBER è un consumer
che si mette in ascolto (subscribe)
sui messaggi pubblicati su un
TOPIC specifico
▪ Il BROKER (server di
smistamento messaggi) si occupa
di effettuare il matching tra
SUBSCRIBER e PUBLISHER
con il conseguente dispatching
del messaggio.
Subscriber
Broker
Publisher
Topic
Publisher
Topic Subscriber
Subscriber
15

16.
/42
Comunicazione asincrona e bidirezionale
MQTT
Broker
1. CONNECT to MQTT broker
2. PUBLISH on:
<house_id>/s/energyConsumption
<house_id>/s/solarEnergy
3. SUBSCRIBE to:
<house_id>/thermostat/setTemp
1. CONNECT to MQTT broker
2. SUBSCRIBE on:
<house_id>/s/*
3. PUBLISH to:
<house_id>/thermostat/setTemp
16

17.
/42
Garanzia nella comunicazione
▪ Keep-Alive message (PINGREQ, PINGRESP):
– il Broker riesce ad identificare una disconnessione non
esplicita del client
▪ Will message:
– viene impostato nel messaggio di CONNECT con topic, QoS
e retain. In caso di disconnessione inaspettata il messaggio
“Will” viene mandato ai subscribers registrati
▪ Retain message:
– un messaggio pubblicato su un topic viene mantenuto sul
broker. Un successivo subscriber che si connette sullo
stesso topic riceve il messaggio (last known good message)
▪ Persistent Session:
– dopo la disconnessione del client, tutte le sottoscrizioni
vengono mantenute nel broker e recuperate alla
connessione successiva
17

18.
/42
Cos’è il livello di qualità del servizio (QoS) ?
E’ un “agreement” tra il mittente ed il destinatario di un messaggio in
relazione alla garanzia di “delivery” del messaggio stesso.
Il QoS è una delle più potenti caratteristiche del protocollo MQTT in quanto
rende molto più semplice lo scambio messaggi su reti degradate attraverso la
gestione automatica della ri-trasmissione.
Ci sono tre livelli disponibili:
▪ QoS 0 – at most once: garantisce il “best effort delivery”; è detto anche
“fire & forget” e non contempla la conferma di ricezione che quindi è la
medesima del trasporto TCP/IP
▪ QoS 1 – at least once: garantisce la consegna del messaggio almeno una
volta verso un ricevente; il messaggio però può essere ricevuto anche più
volte
▪ QoS 2 - exactly once: garantisce la consegna del messaggio una ed una
sola volta verso un ricevente
18

19.
/42
Come funziona il QoS
BrokerPublisher Subscriber
BrokerPublisher Subscriber
PUBLISH (QoS = 0)
PUBLISH
Delete message
Store message
PUBLISH (QoS = 1)
Store message
Delete message
Delete message
PUBLISH
BrokerPublisher Subscriber
Store message
PUBLISH (QoS = 2)
Store message
Delete message
Delete message
PUBLISH
QoS 0: At most once (fire & forget)
QoS 1: At least once QoS 2: Exactly once
PUBREC
PUBREL
PUBCOMP
PUBACK
19

20.
/42
Sicurezza nella comunicazione
3 livelli di sicurezza:
▪ PROTOCOLLO
▪ Username/Password in CONNECT
▪ Possibilità di criptare il Payload
▪ TRASPORTO
▪ MQTT over TLS (v1.2)
▪ Autenticazione del client con certificato
▪ BROKER
▪ Gestione dei permessi su Publish/Subscribe e Topic
▪ Possibilità di integrare altri sistemi di autenticazione/autorizzazione (es. LDAP, OAuth
2.0)
20

21.
/42
MQTT vs HTTP (long polling): prestazioni
Test di spedizione (1024 messaggi con payload da 1 byte)
http://stephendnicholas.com/archives/1217
21

22.
/42
MQTT vs HTTP: la struttura del messaggio
MQTT:
dimensione header
2 byte
HTTP:
dimensione header
REQ/RES > 300 byte
22
GET /service
Host: www.endpointm2m.com
Accept:text/xml
Accept-Encoding:gzip, deflate, sdch
Connection:keep-alive
HTTP/1.1 200 OK
Connection:Keep-Alive
Content-Length:33452
Content-Encoding:gzip
Content-Type:text/xml
Keep-Alive:timeout=15, max=100
Last-Modified:Fri, 17 May 2013 14:50:39 GMT
Connection:close

23.
/42
MQTT-SN
▪ E’ un’evoluzione dello standard MQTT pensata per i dispositivi
embedded (SN = Sensor Networks)
▪ Non richiede lo stack TCP/IP: può essere utilizzato su seriale, UDP,
ZigBee, RF, …
23

24.
/42
MQTT … in pratica
24

25.
/42
I principali Broker MQTT
MOSQUITTO
25

26.
/42
Soluzioni MQTT in Cloud
▪ Pagamento a consumo di risorse (“pay per
usage”)
▪ Opzione “free tier”: sotto soglie ben definite
il servizio è gratuito
▪ Soluzioni IaaS / PaaS
▪ Elevati QoS (99.9%)
▪ Elevata scalabilità
▪ Tempi di startup estremamente ridotti
26

27.
/42
IBM Bluemix
▪ Sul fronte dei servizi Cloud MQTT/IoT sono i primi arrivati (GIU-14),
nonché i principali promotori e ideatori dello standard MQTT
▪ Fornisce un soluzioni “full stack” (boilerplate), tra cui quella dedicata
esclusivamente all’ IoT e basata su MQTT
▪ Basata su CloudFoundry con deploy in 3 step:
▪ Selezione di un Runtime (Node, Java, PHP, …)
▪ Selezione dei Servizi
▪ Installazione dell’applicazione
▪ Freemium plan:
▪ 20 dispositivi
▪ 100MB di traffico dati al mese
▪ 1GB di storage
27

28.
/42
IBM Bluemix
28

29.
/42
Amazon AWS IoT: overview
▪ Offre la più elevata quantità di servizi Cloud dislocati
in ben 11 regioni geografiche e vanta la miglior
offerta in termini di scalabilità e computazionalità
▪ AWS, nato nel 2006, solo pochi giorni fa (OTT-15)
ha lanciato la soluzione “AWS IoT” (attualmente in
“Beta”) che sfrutta il protocollo MQTT
▪ Free tier of 250K messages (IN/OUT) per month for
12 months. Therefore 5$ per million messages
29

30.
/42
Amazon AWS IoT: caratteristiche
30

31.
/42
Microsoft Azure IoT Suite
▪ La Suite IoT è stata lanciata molto recentemente (MAR-15)
▪ Microsoft ha dichiarato di puntare molto sull’IoT (Windows 10 for
Raspberry Pi)
▪ L’approccio è quello di mettere a disposizione “finished
applications to speed development of common scenarios”
▪ E’ possibile utilizzare il protocollo MQTT solo come layer
aggiuntivo in quanto non è incluso come soluzione nel “core” della
Suite.
31

32.
/42
Eurotech
▪ La suite EDC (Everywhere Device Cloud - iPaaS)
fornisce una soluzione completa (HW & SW) che offre
la connettività sicura e scalabile basata su MQTT
▪ La suite ESF (Everywhere Software Platform) è un
framework finalizzato a rendere il più semplice
possibile l’integrazione tra i dispositivi ed il cloud (EDC)
▪ Utilizza un’enhanced version del protocollo MQTT
che ad esempio può gestire la “birth date” del
dispositivo
▪ Modello di pricing basato su numero di dispositivi e/o
numero di messaggi scambiati
▪ La suite può funzionare su AWS, Azure o anche in
modalità standalone
32

33.
/42
Eurotech EDC/ESF
33

34.
/42
Client di riferimento MQTT
Disponibile per i seguenti linguaggi:
▪ C++
▪ C for embedded
▪ Go
▪ Java
▪ JavaScript
▪ Lua
▪ .Net
▪ Objective-C
▪ Python
Altri:
https://github.com/mqtt/mqtt.github.io/wiki/libraries
• Client di riferimento per
l’ecosistema MQTT
• Disponibile open-source
34

35.
/42
Alcuni casi d’uso
35

36.
/42
Monitoraggio oleodotti e piattaforme
36

37.
/42
Facebook Messenger
▪ More than 850M Users
▪ Chat application
▪ Improved Battery
▪ Lower latency
▪ Less bandwidth
https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920
“By maintaining an MQTT connection and routing messages through our
chat pipeline, we were able to often achieve phone-to-phone delivery
in the hundreds of milliseconds, rather than multiple seconds.”
37

38.
/42
Una “smart home” open source
▪ Mosquitto MQTT + openHab su Raspberry Pi
▪ Arduino per la gestione dei sensori
▪ Monitoraggio e controllo remoto da tablet/
smartphone con app openHab
http://www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi
38

39.
/42
Infomobilità e autotrasporti
▪ Ogni mezzo dispone di un device che raccoglie e invia i dati su posizione,
velocità e consumi
▪ I dati raccolti vengono inviati “dove serve”
▪ Le informazioni sono analizzate e le decisioni sono prese in tempo reale da
un singolo backend
39

40.
/42
Salute e medicina
▪ Ogni dispenser comunica con il server centrale in tempo reale inviando dati
su mancate/errate assunzioni
▪ Le informazioni relative ad eventi di allarme scatenano delle azioni
immediate (notifica telefonica, SMS, ecc)
1. il paziente non
assume il farmaco
2. Il dispositivo invia allarme
al server centrale (MQTT over GPRS)
3. Il server centrale (broker)
invia notifica istantanea al
medico
4. Il medico contatta
il paziente
40

41.
/42
Credits
▪ MQTT official web site : http://mqtt.org
▪ Mosquitto : http://mosquitto.org / https://www.eclipse.org/mosquitto
▪ Mosca: https://github.com/mcollina/mosca
▪ HiveMQ : http://www.hivemq.com
▪ M2Mqtt C# Client : http://m2mqtt.codeplex.com
▪ Eclipse Paho project : http://www.eclipse.org/paho/
▪ MQTT-SN: http://mqtt.org/2013/12/mqtt-for-sensor-networks-mqtt-sn
▪ Amazon AWS IoT: https://aws.amazon.com/iot/
▪ IBM Bluemix IoT: https://www.ibm.com/cloud-computing/bluemix/solutions/iot/
▪ Microsof Azure IoT Suite: http://www.microsoft.com/en-us/server-cloud/internet-of-things/
▪ Eurotech: http://www.eurotech.com/
41

42.
/42
Grazie per l’attenzione!
DOMANDE ?
42
OMNYS - Information Technology
www.omnys.com
@SMAU Milano 2015: PAD. 1 - STAND E11