IoT protocols war !

Battles on the fields …

Paolo Patierno Microsoft MVP Windows Embedded / IoT

ppatierno@live.com

@ppatierno

Senior Software Engineer (Ditron S.r.l.)

Microsoft MVP Windows Embedded / IoT

”... constantly moving between the devices and the cloud ...”

”DotNetCampania” member

http://dotnetcampania.org/blogs/paolopat/default.aspx

“Embedded101” board of director member

http://www.embedded101.com/Blogs/PaoloPatierno.aspx

“TinyCLR.it” member http://www.tinyclr.it

Linkedin http://it.linkedin.com/in/paolopatierno

Who am I ? Contacts

IoT protocols introduction

HTTP, CoAP, MQTT, AMQP

battles on the fields ...

implementation and weight

data transfer and manipulation

IoT communication patterns

reliability and QoS

security

Agenda

IoT protocols landscape

IoT protocols trends

HTTP

IETF standard (RFC 2616 is HTTP/1.1)

CoAP

IETF standard (RFC 7252)

MQTT

soon (end 2014 ?) OASIS standard

AMQP

OASIS and ISO 19464 standard (1.0)

Standardization

Client/Server

request/response

HTTP : synchronous

CoAP : (also) asynchronous

HTTP is ASCII based

CoAP is binary based

Architecture : HTTP & CoAP

Client Server

Broker and connected Clients

broker receives subscriptions from clients on topics

broker receives messages and forward them

clients subscribe/publish on topics

Brokers bridge configuration

Architecture : MQTT

Architecture : AMQP (1.0)

client

producer (consumer)

broker

queue

container container connection

session

link

node node

multiplexing frames on sessions and links

transport indipendent

brokered

HTTP

client more complex (ASCII parser)

more bytes to pay on data transfer

connection oriented via TCP

CoAP

HTTP-like but binary

connection less via UDP

client more simple than HTTP

“options” like HTTP headers (binary)

Implementation & Weight

MQTT

client simple to develop (spec about 70 pages)

constrained devices (smallest packet 2 bytes)

connection oriented via TCP

AMQP

client more complex

connection oriented via TCP (with multiplexing)

Implementation & Weight

HTTP & CoAP

Content-Type based on MIME

MQTT

payload agnostic

no data types

no metadata

any data format (text, binary, JSON, XML, BSON, ProtoBuf, ...)

peer must agree on serialization/deserialization

Data transport & manipulation

AMQP

message

header : system and custom/user properties

body : opaque

metadata

data types system

peers can use Content-Type and Content-Encoding

filter on properties

Data transport & manipulation

IoT communication patterns

Telemetry

Information flows

from device to other

systems for

conveying status

changes in the device

Inquiries

Requests from

devices looking to

gather required

information or asking

to initiate activities

Commands

Commands from

other systems to a

device or a group of

devices to perform

specific activities

Notifications

Information flows from

other systems to a

device (-group) for

conveying status

changes in the world

1:N 1:N

HTTP

REST architecture for CRUD operations on resources

CoAP

REST architecture for CRUD operations on resources

MQTT

topics based

AMQP

distribution nodes (aka queues) based

IoT communication patterns : resources

devices act as ”servers”

URIs

used for addressing resources

schemes : http or coap

addressing : <scheme>://<address>/<resource_path>

verbs for CRUD operations

POST, GET, PUT, DELETE

CoAP discovery (CoRE Link format)

“well known” path to get available resources

HTTP & COAP : URIs

Topics for publish and subscribe

hierarchical

wildcards (# and +)

ex. building1/+/room1, building1/floor1/room1/#

MQTT : topics

queus for ...

inbox : telemetry, inquiry (and command response)

outbox : command, notifications (and inquiry response)

AMQP : distribution nodes (aka queues)

Device Backend

inbox

outbox

Telemetry : HTTP

Device (client)

System (server)

HTTP PUT /<resource> (group_id, device_id, value)

HTTP 200 OK

Device (server)

System (client)

HTTP GET /<resource>

HTTP 200 OK (<resource>)

(long) polling

Telemetry : CoAP

Device (server)

System (client)

CON GET /<resource> Observe: 0 Token: 0xAB

ACK 2.05 Observe: 30 Token: 0xAB <resource>…

/<resource> changed

CON 2.05 Observe: 31 Token: 0xAB <resource>…

ACK Token: 0xAB

/<resource> changed

CON 2.05 Observe: 32 Token: 0xAB <resource>…

ACK Token: 0xAB

RST Token: 0xAB

ACK Token: 0xAB

register

deregister

Telemetry : MQTT

Device Broker

PUBLISH /$TEL/group_id/device_id/<resource>

acknowledgement (based on QoS)

PUBLISH /$TEL/group_id/device_id/<resource>

acknowledgement (based on QoS)

PUBLISH /$TEL/group_id/device_id/<resource>

acknowledgement (based on QoS)

* $TEL as base for topics not needed

Telemetry : AMQP

Device Server

transfer (<resource>)

transfer (<resource>)

transfer (<resource>)

settlement (based on QoS)

settlement (based on QoS)

flow

in_queue

HTTP

more verbose (ASCII, headers, ...) for few data

addressing problem (mobile roaming, NAT, ...)

no QoS (based on TCP)

CoAP

“observer” pattern

addressing problem (mobile roaming, NAT, ...)

QoS with “confirmable” message or not

Telemetry : summary

MQTT

born for telemetry with “publish/subscribe” pattern

no flow control for a lot of data at high rate

QoS (at most once, at least once, exactly once)

AMQP

messages flow control for more & high rate data

QoS (at most once, at least once, exactly once)

Telemetry : summary

Inquiry : HTTP

Device (client)

System (server)

HTTP GET /<info>

HTTP 200 OK (<info>)

Inquiry : CoAP

Device (client)

System (server)

CON [0x123] GET /<info>

ACK [0x123] 2.05 Content <info>…

Inquiry : MQTT

Device Broker

SUBSCRIBE /$INQ/group_id/device_id/req_id

PUBLISH /$INQ/<info>

PUBLISH /$INQ/group_id/device_id/req_id

acknowledgement (based on QoS)

acknowledgement (based on QoS)

inside publish inquiry payload from device

* $INQ as base for topics not needed

Inquiry : AMQP

Device Server

transfer (<info>, replyTo, messageId)

transfer (<info>, correlationId = messageId)

settlement (based on QoS)

settlement (based on QoS)

in_queue out_queue

HTTP & CoAP

request/response pattern

MQTT

no built in response path support

needed to define a response topic pattern (over)

group_id, device_id, req_id in custom format (as payload)

AMQP

built in response and correlation support

“replyTo” and “correlationId” for request/response

Inquiry : summary

Command : HTTP

Device (server)

System (client)

HTTP POST /<cmd>

HTTP 200 OK (<result>)

(long) polling

Command : CoAP

Device (server)

System (client)

CON [0x123] POST /<cmd> Token: 0xAB

ACK [0x123]

CON [0x7F2] 2.05 Content Token: 0xAB <result>…

ACK [0x7F2]

Too much time

result

Command : MQTT

Device Broker

SUBSCRIBE /$CMD/group_id/device_id/<cmd>

PUBLISH /$CMD/group_id/device_id/<cmd>

PUBLISH /$CMD/group_id/device_id/<cmd>/req_id

acknowledgement (based on QoS)

acknowledgement (based on QoS)

inside publish command payload from system

* $CMD as base for topics not needed

Command : AMQP

Device

transfer (<cmd>, replyTo, messageId)

transfer (<result>, correlationId = messageId)

settlement (based on QoS)

settlement (based on QoS)

Server in_queue out_queue

HTTP

more verbose (ASCII, headers, ...) for few data

addressing problem (mobile roaming, NAT, ...)

no QoS (based on TCP)

CoAP

response after a while pattern

addressing problem (mobile roaming, NAT, ...)

QoS with “confirmable” message or not

Command : summary

MQTT

no built in result command path support

needed to define a result topic pattern (over)

addressing result (req_id) in custom payload

if device is offline

no TTL (Time To Live) for command

old command could be delivered (if “retain” flag)

new command could be lost (if not “retain” flag)

commands are enqueued only if not “clean session”

Command : summary

AMQP

built in result and correlation support

“replyTo” and “correlationId” for command/result

if device is offline

TTL (Time To Live) to avoid old command

commands are enqueued

Command : summary

Notification : HTTP

Device (server)

System (client)

HTTP POST /<notify> (content)

HTTP 200 OK

Notification : CoAP

Device (server)

System (client)

CON [0x123] POST /<notify> (content)

ACK [0x123]

Notification : MQTT

Device Broker

SUBSCRIBE /$NOT/<notify>

PUBLISH /$NOT/<notify>

acknowledgement (based on QoS)

* $NOT as base for topics not needed

Notification : AMQP

Device Server (out_queue)

transfer (<notifiy>)

settlement (based on QoS)

transfer (<notify>)

settlement (based on QoS)

flow

HTTP

more verbose (ASCII, headers, ...) for few data

addressing problem (mobile roaming, NAT, ...)

no QoS (based on TCP)

CoAP

addressing problem (mobile roaming, NAT, ...)

QoS with “confirmable” message or not

Notification : summary

MQTT

born for notification with “publish/subscribe” pattern

no flow control for a lot of data at high rate

QoS (at most once, at least once, exactly once)

AMQP

messages flow control for more & high rate data

QoS (at most once, at least once, exactly once)

Notification : summary

HTTP

basic & digest authentication

HTTPS aka HTTP over SSL/TLS

encryption only payload

CoAP

DTLS (Datagram TLS)

encryption only payload

Security

MQTT

SSL/TLS

username/password on connection

encryption only payload

AMQP

SSL/TLS

SASL (Simple Authentication and Security Protocol)

encryption only payload

Security

devices

consider how much they are constrained

network

how much it is reliable

do you pay for data bytes transferred ?

message rate

how many messages per second

QoS needs

Conclusions

security

authenticity ? only signature

confidentiality ? need encryption

analysis & big data

needs of the backend to process data

self descriptive message with metadata ?

raw data, more fast ?

Conclusions

protocol choice depends on scenario

some protocols have more features than other

a complex system can use more protocols

Conclusions

IoT/M2M Embedded101 free ebook : http://bit.ly/m2miotbook

Subscribe! Blog : http://channel9.msdn.com/Blogs/Subscribe

IBM redbook : http://www.redbooks.ibm.com/abstracts/sg248054.html

IoT with Azure Service Bus : http://channel9.msdn.com/Events/Build/2014/3-635

Windows and Internet of Things : http://channel9.msdn.com/Events/Build/2014/2-511

MQTT Official web site : http://mqtt.org

M2Mqtt project : http://www.m2mqtt.net

Mosquitto : http://mosquitto.org

HiveMQ : http://www.hivemq.com

Eclipse IoT : http://iot.eclipse.org

MQTT An implementer’s perspective : http://bit.ly/1koMZLF

MQTT Another implementer’s perspective : http://bit.ly/1rHDnAN

Resources

CoAP Coap Technology : http://coap.technology

Official draft : https://datatracker.ietf.org/doc/draft-ietf-core-coap

CoRE Link format : http://tools.ietf.org/html/rfc6690#section-3.1

CoAPSharp : http://www.coapsharp.com

Copper : https://github.com/mkovatsc/Copper

AMQP Official web site : http://www.amqp.org

Microsoft Azure Service Bus : http://azure.microsoft.com/en-US/services/messaging/

AMQP.Net Lite : https://amqpnetlite.codeplex.com/

Qpid project : http://qpid.apache.org/

RabbitMQ : http://www.rabbitmq.com

ActiveMQ : http://activemq.apache.org/

Resources

Thanks !

The End