Application Layer Protocols for the IoT

1. Application Layer Protocols for the IoT

2. Outline

1.
2.
3.
4.
5.
6.
7.
8.
9.
Architecture of IoT
IoT Protocol Stack
MQTT - Message Queueing Telemetry Transport
CoAP - Constrained Application Protocol
XMPP - eXtensible Messaging and Presence Protocol
AMQP - Advanced Message Queueing Protocol
DDS - Data Distribution Service
Protocol Implementation
IoT communication patterns

3. Architecture of IoT

4. IoT Landscape

5. C6 Smart IoT

6. IoT Architecture

7. IoT Broker Architecture

8. IoT Brokerless Architecture

9. Simplified IoT System Architecture

10. IoT Levels

11. Protocols in Complex systems

12. IoT Protocol Stack

13. IoT Protocols and Standards

14. Standardized IoT Protocols

15. IoT Protocols

• Infrastructure (ex: 6LowPAN, IPv4/IPv6, RPL)
• Identification (ex: EPC, uCode, IPv6, URIs)
• Comms / Transport (ex: Wifi, Bluetooth, LPWAN)
• Discovery (ex: Physical Web, mDNS, DNS-SD)
• Data Protocols (ex: MQTT, CoAP, AMQP, Websocket, Node)
• Device Management (ex: TR-069, OMA-DM)
• Semantic (ex: JSON-LD, Web Thing Model)
• Multi-layer Frameworks (ex: Alljoyn, IoTivity, Weave, Homekit)

16. IoT Protocol Stack

17. IoT Application Layer Protocols

• Most popular application layer
protocols used nowadays:
• CoAP: Constrained Application
Protocol
• MQTT: Message Queuing Telemetry
Transport
• XMPP: Extensible Messaging and
Presence Protocol
• AMQP: Advanced Message Queuing
Protocol
• WebSocket: Computer
Communications Protocol
• Alljoyn: Full stack of protocols
intended for IoT. Not separable
application layer protocol

18. IoT Messaging Protocols

19. IoT Messaging Protocols

20. IoT Messaging Protocols

21. IoT Messaging Protocols

22. Where to find the specifications?

• HTTP
• IETF standard (RFC 2616 is HTTP/1.1)
• CoAP
• IETF standard (RFC 7252), http://coap.technology/
• MQTT
• OASIS standard
• AMQP
• OASIS and ISO 19464 standard (1.0)

23. Application layer protocols main features comparison

24. MQTT - Message Queueing Telemetry Transport

25. MQTT in the world of IoT

25

26. MQTT interaction model

26

27. MQTT in Short

• MQTT is a Client Server publish/subscribe messaging
transport protocol
• More features:
• Simple to implement (especially at the sensor side)
• QoS Support
• Lightweight and bandwidth efficient and Data agnostic
• Session awareness
27

28. MQTT Architecture

29. MQTT Communication Pattern

Publish/Subscribe paradigm
• Clients don’t know each other
• One-to-Many paradigm
• Every client publishes & subscribes
• PUSH information paradigm compared to PULL’s one in COAP
29

30. MQTT Components

• 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

31. MQTT Packet Format

32. MQTT Open Connection

CONNECT
message fields:

33. MQTT Publishing

PUBLISH
message fields:

34. MQTT QoS 0: “at most once”

Best effort transfer (same reliability
provided by the underlying transport
protocol)

35. MQTT QoS 1: “at least once”

The MQTT client stores the message
and keeps retransmitting it until it is
acknowledged by the MQTT broker
(message can be received multiple
times)

36. MQTT QoS 2: “exactly once”

QoS 2 is the highest level of service in MQTT.
This level guarantees that each message is
received only once by the intended recipients.
QoS 2 is the safest and slowest quality of
service level.

37. MQTT Last Will Message

• The Last Will and Testament (LWT) notifies other clients about an
hard disconnect by a specific client
• Each client can specify its last will message when connecting to a
broker
• The broker will store the message until it detects client hard
disconnection
• The broker sends the message to all subscribed clients on the specific
topic
• The stored LWT message will be discarded if a client disconnects
gracefully by sending a DISCONNECT message.
37

38. MQTT for Sensor Networks – MQTT-SN

• Uses UDP
• Supports topic name indexing
• Reduced size of the payloads (by numbering the data packets with
numeric topic id’s rather than long topic names)
Disadvantage: MQTT-SN is only supported by a few platforms, and
there is only one free broker implementation known, called Really
Small Message Broker
38

39. Getting Started with MQTT

• MQTT protocol brokers:
• Mosquitto
• HiveMQ
• Emqttd
• ActiveMQ
• IBM MessageSight
• JoramMQ
• RabbitMQ
• VerneMQ
Clients are realized by installing MQTT client libraries
39

40. MQTT Summary

• MQTT is a publish/subscribe messaging protocol designed for
lightweight M2M communications. It was originally developed by IBM
and is now an open standard.
• MQTT has a client/server model, where every sensor is a client and
connects to a server, known as a broker, over TCP.
• MQTT is message oriented. Every message is a discrete chunk of data,
opaque to the broker.
• Every message is published to an address, known as a topic. Clients
may subscribe to multiple topics. Every client subscribed to a topic
receives every message published to the topic.
40

41. CoAP - Constrained Application Protocol

42. CoAP Architecture

42

43. CoAP at a Glance

• Embedded web transfer protocol (coap://)
• Based on REST architecture (client-server, stateless, cacheable)
• Asynchronous transaction model
• UDP binding with reliability and multicast support of GET, POST,
PUT, DELETE methods
• URI support
• 4 byte header
• Subset of MIME types and HTTP response codes o Built-in
discovery
• Optional observation and block transfer
43

44. COAP using GET and RESTful URLs

44

45. HTTP vs. CoAP

45

46. CoAP Messaging Basics

• Transport:
• (mainly) UDP binding
• Message Exchange between Endpoints
• Messages with 4 bytes header (shared by request and
responses) containing a message ID (16 bits)
• Reliable exchange through Confirmable Messages which must
be acknowledged (through ACK or Reset Messages). Simple
Stop-and-Wait retransmission with exponential back-off.
• Unreliable exchange through Non-Confirmable Message
• Duplicate detection for both confirmable and non-confirmable
messages (through message ID)
46

47. CoAP Message Format

Ver - Version (1)
T – Message Type (Confirmable, Non-Confirmable, Acknowledgement, Reset)
TKL- Token Length, if any, the number of Token bytes after this header
Code - Request Method (1-10) or Response Code (40-255)
Message ID – 16-bit identifier for matching responses
Token – Optional response matching token

48. CoAP Messaging

48

49. CoAP Message Semantics

50. CoAP Request and Response

51. CoAP Request and Response Example

52. CoAP Separate Response Example

53. CoAP Non-confirmable Request Example

54. CoAP Dealing with Packet Loss

• Stop and Wait approach
• Repeat a request after a time-out in case ACK (or RST) is not coming
back

55. CoAP Observation

• PROBLEM:
• REST paradigm is often “PULL” type, that is, data is
obtained by issuing an explicit request
• Information/data in WSN is often periodic/triggered (e.g.,
get me a temperature sample every 2 seconds or get me a
warning if temperature goes below 5°C)
• SOLUTION: use Observation on COAP resources

56. CoAP Observer Mode

57. CoAP Security

• DTLS (Datagram Transport Layer Security) is used by CoAP as the security
protocol
• For key management and data encryption and integrity protection.
• CoAP with DTLS support is similar to HTTPs.
• Problem: DTLS is inefficient for constrained IoT devices.
• Solution: Apply the 6LoWPAN header compression mechanisms to compress DTLS header.
57

58. CoAP vs MQTT

• MQTT is a many-to-many communication protocol for passing messages between
multiple clients through a central broker. It decouples producer and consumer by letting
clients publish and having the broker decide where to route and copy messages. While
MQTT has some support for persistence, it does best as a communications bus for live
data.
• CoAP is, primarily, a one-to-one protocol for transferring state information between
client and server. While it has support for observing resources, CoAP is best suited to a
state transfer model, not purely event based.
• MQTT clients make a long-lived outgoing TCP connection to a broker. This usually
presents no problem for devices behind NAT. CoAP clients and servers both send and
receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to
allow CoAP, or devices may first initiate a connection to the head-end as in LWM2M.
• MQTT provides no support for labelling messages with types or other metadata to help
clients understand it. MQTT messages can be used for any purpose, but all clients must
know the message formats up-front to allow communication. CoAP, conversely, provides
inbuilt support for content negotiation and discovery allowing devices to probe each
other to find ways of exchanging data.
58

59. Getting Started with CoAP

• Open source implementations:
Java CoAP Library Californium
C CoAP Library Erbium
libCoAP C Library
jCoAP Java Library
OpenCoAP C Library
TinyOS and Contiki include CoAP support
• Firefox has a CoAP plugin called Copper
• Wireshark has CoAP plugin
59

60. CoAP Summary

• Like HTTP, CoAP is a document transfer protocol. Unlike HTTP, CoAP is designed for the
needs of constrained devices.
• CoAP packets are much smaller than HTTP TCP flows. Bitfields and mappings from strings
to integers are used extensively to save space. Packets are simple to generate and can be
parsed in place without consuming extra RAM in constrained devices.
• CoAP runs over UDP, not TCP. Clients and servers communicate through connectionless
datagrams. Retries and reordering are implemented in the application stack. Removing
the need for TCP may allow full IP networking in small microcontrollers. CoAP allows UDP
broadcast and multicast to be used for addressing.
• CoAP follows a client/server model. Clients make requests to servers, servers send back
responses. Clients may GET, PUT, POST and DELETE resources.
• CoAP is designed to interoperate with HTTP and the RESTful web at large through simple
proxies.
• Because CoAP is datagram based, it may be used on top of SMS and other packet based
communications protocols.
60

61. XMPP - eXtensible Messaging and Presence Protocol

62. Who uses XMPP?

• Cisco Webex
• WhatsApp uses a trimmed down version
• Google’s Firebase and Google’s Android

63. XMPP

• Bi-directional streaming XML
• Core: IETF RFC 3920, 3921
• Extensions: XMPP Standards Foundation (XSF)
Membership-based
Elected technical council
Unit of work: XMPP Extension Protocol (XEP)
Process: Experimental, Proposed, Draft, Final
• Goals:
• Simple clients
• Federate everything

64. XMPP was originally named Jabber

• Jabber is best known as “the Linux of instant messaging”
• It is an open, secure, ad-free alternative to consumer instant
messaging services like AIM, ICQ, MSN, and Yahoo.
• Under the hood, Jabber is a set of streaming XML protocols
and technologies that enable any two entities on the
Internet to exchange messages, presence, and other
structured information in close to real time. (Jabber.org)

65. XMPP From IETF

• In IM, the central point of focus is a list of one's contacts or "buddies" (in XMPP this list is
called a "roster").
• The purpose of using such an application is to exchange relatively brief text messages
with particular contacts in close to real time -- often relatively large numbers of such
messages in rapid succession, in the form of a one-to-one "chat session" The catalyst for
exchanging messages is "presence" -- i.e., information about the network availability of
particular contacts (thus knowing who is online and available for a one-to-one chat
session).
• Presence information is provided only to contacts that one has authorized by means of
an explicit agreement called a "presence subscription".
• Thus at a high level XMPP needs to be able to complete the following use cases:
Manage items in one's contact list (list is maintained on the server)
Exchange messages with one's contacts
Exchange presence information with one's contacts (send communication status to the server)
Manage presence subscriptions to and from one's contacts

66. XMPP

IETF Standard since 2004
Open and free – supported by the XMPP Standards Foundation (XSF)
Created by Jeremy Miller in 1998 – originated as Jabber - multi user chat
Has been extended in many ways over the years, supports Pub/Sub
Designed for client server instant messaging but with no central authority
Architecture similar to email – anyone can run an XMPP server
May be isolated on a local intranet or may be public
All about sending XML messages over a network to do a wide variety of
things. An XMPP message may be used to communicate between people (a
chat application) or might be used by a sensor to report on its state.

67. XMPP Architecture

• Addressing Scheme: [email protected]/resource
JID = Jabber ID
Node: identity, e.g. user name
Domain: DNS domain name
Resource: device identifier
• [email protected] identifies a person
• Client talks to “local” server
• Wherever the user account is hosted
• Tied to directory if desired
• Organizational policy enforced
• Servers talk to other servers
• DNS lookup on domain portion of address
• Dialback, MTLS for security
• One connection for many conversations

68. XMPP Architecture

69. Naming Things (1)

A lot like an email address , XMPP uses Jabber ID’s (JIDs)
All of these JIDs could be logged on at the same time.
[email protected]
Called a “bare JID”
[email protected]/mobile Includes a resource. This is called a “full JID”
[email protected]/tablet Resource used for message delivery
[email protected]/auto
Resource typically assigned by server
On Whatsapp: [email protected]
You may only subscribe to bare JIDS.
A resource identifies a particular client belonging to the user
A user can log in to an XMPP server multiple times, and in this case, the resource
can denote a location. For example, the sample user might have a JID for his main
terminal ([email protected]/terminal) and another JID (session)
from an EVA pod ([email protected]/eva_pod1). So, a particular
location can be targeted or left absent to reach the user at whichever location he
happens to be logged in.

70. Naming Things (2)

• The resource may be a random string
• Each connection is bound to a specific resource
• Many clients may use the same account at the same time. To send a message to
one of them you must have the full JID.
• Only “friends” may communicate with each other.
• Suppose Alice makes a request for a presence subscription to Bob’s bare JID.
• If Bob agrees, Alice will receive Bob’s full JID along with presence status (online,
offline, etc.)
• Suppose Bob makes a request for a presence subscription to Alice’s bare JID.
• If Alice agrees, Alice and Bob are now friends. Both each have the other’s full JID.

71. XMPP Security Stuff

• Start-TLS
Prove the identity of the server
Prove the identity of the user (optional)
Encryption
Data integrity
• SASL (RFC 4422)
• Authentication
• Optional encryption (rarely used)
• Pluggable (e.g. passwords, Kerberos, X.509, SAML, etc.)

72. XMPP Extensions

• Many already exist: http://www.xmpp.org/extensions/

73. XMPP Summary

• XMPP was developed for instant messaging (IM) to connect people to other people via text
messages.
• XMPP uses the XML text format as its native type, making person-to-person communications
natural.
• XMPP runs over HTTP on top of TCP. Its key strength is a [email protected] addressing scheme
that helps connect the needles in the huge Internet haystack.
• In the IoT context, XMPP offers an easy way to address a device. This is especially handy if that
data is going between distant, mostly unrelated points, just like the person-to-person case. It’s
not designed to be fast. In fact, most implementations use polling, or checking for updates only
on demand.
• A protocol called BOSH (Bidirectional streams over Synchronous HTTP) lets severs push messages.
• XMPP response time is in seconds and it is good for people to people communication
• XMPP provides a great way, for instance, to connect your home thermostat to a Web server so
you can access it from your phone. Its strengths in addressing, security, and scalability make it
ideal for consumer-oriented IoT applications.
73

74. AMQP - Advanced Message Queueing Protocol

75. AMQP Architecture

76. AMQP Architecture

producer
(consumer)
queue
client
broker
container
node
connection
session
container
node
link
multiplexing frames on sessions and links
transport independent
brokered

77. AMQP Frame

There are nine kinds of frame types: OPEN, BEGIN, ATTACH, FLOW, TRANSFER, DISPOSITION, DETACH, END,
CLOSE.
The nine kinds of frames will be used in sequence: OPEN the connection, BEGIN a session on the channel,
ATTACH a link to this session, use FLOW to update the link state, then use TRANSFER to send a message.
DISPOSITION will be used to inform remote peers of delivery state changes. And DETACH will be used to
detach a link from a session, similarly END is used for ending a session while CLOSE will close the
connection.

78. AMQP Message Format

79. AMQP Messaging Features

80. AMQP Messaging Features

81. DDS - Data Distribution Service

82. DDS Domain

83. DDS in a nutshell

• Main entities:
• Domain Participant Data Writer Publisher
Data Reader Subscriber
• Topic
• All networking is abstracted. Usually implemented on top of raw
sockets
• Anycasting and Multicasting

84. DDS Architecture

85. DDS Architecture

86. DDS Architecture

• DDS (Data Distribution Service for Real time Systems)
• – DDS implements direct device-to-device “bus” communication with a relational data model. Some
companies call this a “DataBus” because it is the networking analog to a database. Similar to the way a
database controls access to stored data, a data bus controls data access and updates by many
simultaneous users. This is exactly what many high-performance devices need to work together as a
single system.
• – High-performance integrated device systems use DDS.Itistheonly technology that delivers the
flexibility, reliability, and speed necessary to build complex, real-time applications. Applications include
military systems, wind farms, hospital integration, medical imaging, asset-tracking systems, and
automotive test and safety. DDS connects devices together into working, distributed applications
• – Object management group’s DDS is a datacentric publish and subscribe technology to address the
data distribution requirements of mission critical systems such as financial trading, air traffic control
etc.
• – DDStargetsdevicesthatdirectlyusedevicedata.Itdistributesdatatoother devices While interfacing with
the IT infrastructure is supported, DDS’s main purpose is to connect devices to other devices
• – It enables scalable,real-time,reliableandhighperformanceand interoperable data exchanges (by DDS
interoperability wire protocol) between publishers and subscribers.

87. DDS Architecture

• DDS (Data Distribution Service for Real time Systems)
• – DDS standard
• • Data centric publish and subscribe(DCPS) layer allows configuration from small scale to large scale systems
• – Use APIs that present a set of standardized “profiles” targeting real time information availability from small scale to large scale
systems
• A DDS interoperability wire protocol (dynamic DSI)
• An extensible and dynamic topic types for DDS standard.
• – DDS is both language and OS independent
• DCPS APIs has been implemented in a range of different programming languages (C, C++, Java, Javascript etc.
• Using standardized APIs helps ensure that DDS applications can be ported easily between different vendor’s implementations
• – DDS specifies a DDS interoperability (DDSI) wire protocol that helps multiple DDS applications to interoperate
• • A wire level protocol refers to the mechanism of transmitting data from point to point • Wire protocol is used to describe a
common way to represent information at application level
• • The protocol also supports automatic “Discovery“ that allows DDS participants to declare the information they can provide or,
receive including data type & QoS
• • Protocol automatically connect publishers to subscribers and this simplifies process of configuring systems with many nodes and
many devices exchanging data

88. Protocol Implementation

89. Protocol Implementation

90. Scalability of IoT Communication

91. Implementation & Weight

Implementation & Weight
• 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)

92. Implementation & Weight

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)

93. Data transport & manipulation

Data transport & manipulation
• 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

94. Data transport & manipulation

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

95. IoT communication patterns

96. IoT communication patterns

1:N
Telemetry
Inquiries
Information flows
from device to other
systems for
conveying status
changes in the device
Requests from
devices looking to
gather required
information or asking
to initiate activities
1:N
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

97. IoT communication patterns : resources

• 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

98. MQTT : topics

• Topics for publish and subscribe
• hierarchical
• wildcards (# and +)
• ex. building1/+/room1, building1/floor1/room1/#

99. AMQP : distribution nodes (aka queues)

• queues for ...
• inbox : telemetry, inquiry (and command response)
• outbox : command, notifications (and inquiry response)
inbox
Device
Backend
outbox

100. Telemetry : HTTP

Device
System
(server)
(client)
HTTP GET /<resource>
(long)
polling
HTTP 200 OK (<resource>)
Device
System
(client)
(server)
HTTP PUT /<resource> (group_id, device_id, value)
HTTP 200 OK

101. Telemetry : CoAP

Device
System
(server)
(client)
register
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>…
/<resource>
changed
CON 2.05 Observe: 32 Token: 0xAB <resource>…
deregister
RST Token: 0xAB
ACK Token: 0xAB
ACK Token: 0xAB
ACK Token: 0xAB

102. 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

103. Telemetry : AMQP

Server
Device
in_queue
transfer (<resource>)
transfer (<resource>)
settlement (based on QoS)
transfer (<resource>)
settlement (based on QoS)
flow

104. Telemetry : summary

• 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

105. 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)

106. Inquiry : HTTP

Device
System
(client)
(server)
HTTP GET /<info>
HTTP 200 OK (<info>)

107. Inquiry : CoAP

Device
System
(client)
(server)
CON [0x123] GET /<info>
ACK [0x123] 2.05 Content <info>…

108. Inquiry : MQTT

Device
Broker
SUBSCRIBE /$INQ/group_id/device_id/req_id
PUBLISH /$INQ/<info>
acknowledgement (based on QoS)
inside publish inquiry payload from device
PUBLISH /$INQ/group_id/device_id/req_id
acknowledgement (based on QoS)
* $INQ as base for topics not needed

109. Inquiry : AMQP

Device
in_queue
transfer (<info>, replyTo, messageId)
settlement (based on QoS)
transfer (<info>, correlationId = messageId)
settlement (based on QoS)
Server
out_queue

110. Inquiry : summary

• 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

111. Command : HTTP

Device
System
(server)
(client)
HTTP POST /<cmd>
HTTP 200 OK (<result>)
(long)
polling

112. Command : CoAP

Device
System
(server)
(client)
CON [0x123] POST /<cmd> Token: 0xAB
ACK [0x123]
Too
much
time
CON [0x7F2] 2.05 Content Token: 0xAB <result>…
result
ACK [0x7F2]

113. Command : MQTT

Device
Broker
SUBSCRIBE /$CMD/group_id/device_id/<cmd>
PUBLISH /$CMD/group_id/device_id/<cmd>
acknowledgement (based on QoS)
inside publish
command payload
from system
PUBLISH /$CMD/group_id/device_id/<cmd>/req_id
acknowledgement (based on QoS)
* $CMD as base for topics not needed

114. Command : AMQP

Device
in_queue
transfer (<cmd>, replyTo, messageId)
settlement (based on QoS)
transfer (<result>, correlationId = messageId)
settlement (based on QoS)
Server
out_queue

115. Command : summary

• 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

116. 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”

117. 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

118. Notification : HTTP

Device
System
(server)
(client)
HTTP POST /<notify> (content)
HTTP 200 OK

119. Notification : CoAP

Device
System
(server)
(client)
CON [0x123] POST /<notify> (content)
ACK [0x123]

120. Notification : MQTT

Device
Broker
SUBSCRIBE /$NOT/<notify>
PUBLISH /$NOT/<notify>
acknowledgement (based on QoS)
* $NOT as base for topics not needed

121. Notification : AMQP

Server
Device
(out_queue)
transfer (<notifiy>)
settlement (based on QoS)
transfer (<notify>)
settlement (based on QoS)
flow

122. Notification : summary

• 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

123. 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)

124. Security

• HTTP
• basic & digest authentication
• HTTPS aka HTTP over SSL/TLS
• encryption only payload
• CoAP
• DTLS (Datagram TLS)
• encryption only payload

125. Security

• MQTT
• SSL/TLS
• username/password on connection
• encryption only payload
• AMQP
• SSL/TLS
• SASL (Simple Authentication and Security Protocol)
• encryption only payload