IoT Messaging Protocol

(Session layer Protocol)

MESSAGING PROTOCOLS –MQT T, AMQP, COAP, SMQT T, DDS
Session Layer Protocol (Messaging
Protocol)
▪ Manages connection between two endpoints of a network, controls
data between sender and receiver
▪ Layers 5, 6 and 7 combine together- IoT protocol stack
▪ Also refer to as Messaging protocol or Application Layer protocol
o Message Queue Telemetry Transport (MQTT)
o Advanced Message Queuing Protocol (AMQP)
o Constrained Application Protocol (CoAP)
o Secure Message Queue Telemetry Transport (SMQTT)
o Data Distribution Service (DDS)
o Extensible Messaging and Presence Protocol (XMPP) …….so on
 Why Not HTTP?
• Designed and architected for general purpose computing in
client/server Models
• IoT devices – power constrained, remote, and bandwidth limited
• More efficient, secure, and scalable protocols are necessary to
manage many devices in various network topologies such as mesh
networks
• Two types:
• Message Orientated Middleware (MOM) –
• Representational State Transfer (REST) -
Universal Resource Identifier (URI)
 MQTT - Message Queuing Telemetry Transport

• MQTT is a lightweight publish/subscribe messaging protocol designed for

M2M (machine to machine) telemetry in low bandwidth environments
• Invented by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom
(now Eurotech) in 1999
• OASIS (Organization for the Advancement of Structured Information
Standards) standard, ISO standard (ISO/IEC PRF 20922)
• Public and royalty-free license
• Used by Amazon Web Services, IBM WebSphere MQ, Microsoft Azure IoT,
Adafruit, Facebook Messenger

http://www.steves-internet-guide.com/mqtt-works/
 MQTT Features

• Lightweight - Low network bandwidth, small code Footprint

• Low overheads – 2 bytes/header
• Secured authentication using user name and password– Data
encrypted with TLS(Transport layer security)/ SSL(Secure
Sockets Layer) (https:// in place of http://)
• Publish/subscribe message exchange pattern
• Decouples information source and consumer
• Quality of service: at most once, at least once, exactly once
• Centralized broker
MQTT Architecture
 Message flow

→A publisher first sends a control message along with the data

message.

→Once updated in the broker, the broker distributes this

topic’s content to all the subscribers of that topic for which the new
message has arrived.

→In the absence of any subscribers of a topic, a broker normally

discards messages received for that topic unless specified by the
publisher otherwise.
 MQTT – Topics
• An endpoint to that the clients
(publisher and subscriber) are
connected
• Topics are simple, hierarchical
strings, encoded in UTF-8,
delimited by a forward slash.
• For example,
building1/room1/temperature
and
building1/room1/humidity are
valid topic names.
• Subscribers can choose to
subscribe to a specific topic or
all the subtopics through
wildcards.
MQTT Topics – Single level & Multilevel Wildcard Subscription

Examples
Example: Sigle level & Multi-level Wildcard in Topics
 Topics beginning with $

The $-symbol topics are reserved for internal statistics of the MQTT
broker.
Clients cannot publish messages to these topics
Quality of Service Classes • QoS-0 (non-assured transmission): This is
the minimal QoS level. It is a best-effort
delivery process without the receiver
acknowledging message or the sender
reattempting transmission.
• Qos-1 (assured transmission): This mode
will guarantee delivery of the message at
least once to the receiver. The receiver will
send an acknowledgment back with a
PUBACK response.
• QoS-2 (assured service on applications):
This is the highest level of QoS that ensures
and informs both the sender and receiver
that a message has been transmitted
correctly. PUBREC →PUBREL →PUBCOMP.
QoS 0 can be chosen when…
• it is accepted that messages are
occasionally lost.
• the message interaction between the
internal services in the same subnet
• the network of client and server is very
stable.
QoS 1 can be chosen when

• Focus on the consumption of system

resources and wish optimized
performance.
• Can not lose any message, but can
accept and process duplicate messages.
QoS 2 can be chosen when
• It is unacceptable that lost
message(the loss of message may
result in loss of life or property), and do
not want to receive duplicate
messages.
•For applications such as a bank,
firefight, aviation, etc that require high
completeness of data and timeliness.
 MQTT Brokers

An MQTT broker is a central software entity in the MQTT architecture.

MQTT brokers facilitate transactions between MQTT clients:

1. Allow clients to make a connection request

2. Authenticate the devices based on the connection information shared by the connecting
device(s)
3. Once authenticated, make sure that the device can send/receive messages to/from
other devices securely using Transport Layer Security (TLS) encryption
4. Stores messages within the server so that they could be re-sent in the case of unwanted
connection loss, on client-connect, on client-disconnect, etc.
Types of Messages
Types of Messages
 Examples_MQTT Brokers

HiveMQ Eclipse IoT

ActiveMQ VerneMQ
RabbitMQ Solace
CloudMQTT
Mosquitto
emqttd
flespi Wave
IBM Message Sight vertx-mqtt-broker
Mosca & Aedes JoramMQ
MQTT Dashboard Moquette MQTT
 MQTT-SN

• MQTT-SN is designed as per the needs of wireless communication

network - low bandwidth, high link failures, short message length
etc.
• MQTT-SN is optimized for the implementation on low cost, battery-
operated devices with limited processing and storage resources.
• MQTT-SN needs a bridge to translate MQTT-SN messages into
MQTT messages.
• It can be run successfully over BLE and Zigbee. (Very light weight)
Four components:

• Gateways: In MQTT-SN, a gateway has the responsibility of

protocol conversion from MQTT-SN to MQTT and vice versa.
Gateways can also be aggregating or transparent
• Forwarders: A route between a sensor and an MQTT-SN
gateway may take many paths and hop. Nodes between the
source client and the MQTT-SN gateway are called forwarders.
• Clients: Clients behave in the same way as in MQTT and are
capable of subscribing and publishing data.
• Brokers: Brokers behave in the same way as in MQTT
MQTT – SN Network Architecture
 Two type of Gateways:

1) Transparent Gateway - For each MQTT-SN client, transparent

gateway forms an individual MQTT connection to the MQTT broker.

2) Aggregating Gateway - For all MQTT-SN clients, the Aggregating

gateway forms only one MQTT connection to the MQTT broker.
Reduces the number of MQTT connections when large number of
sensor nodes are in the network.
 Comparison MQTT with MQTT-SN
• MQTT-SN can run over simplified medium and UDP

• Topic names are replaced by short, two-byte long topic ID messages. This is to assist
with bandwidth constraints in wireless networks.

• The Topic name to topic ID can be preconfigured in MQTT-SN gateway, so that even
registration message can be skipped before publish.

• A discovery procedure helps clients to discover the actual network address of an

operating server/gateway.

• Multiple gateways may be present at the same time within a single wireless network
and can co-operate in a load-sharing or stand-by mode.
 Constrained Application Protocol (CoAP)

• CoAP is lightweight HTTP

equivalent for the IoT
CoAP HTTP
• Asynchronous message
• UDP based • TCP based
exchange
• Network layer – IPv6, 6LoWPAN • Network layer- IP
• Low overhead
• Supports multicasting • Doesn’t support multicasting
• Connection-less protocols
• Asynchronous communication • Synchronous communication
• Representational State Transfer
• Less overhead, Simple • More overhead, Complex
(REST)
• For resource constrained • For internet devices
• Built upon UDP versus devices
TCP/UDP for a normal HTTP
session
 Constrained Application Protocol (CoAP)
• The constrained devices have minimal RAM and an 8-bit processor at most.
• CoAP can efficiently work on such devices, even when these devices are
connected to highly lossy networks with high packet loss, high error rates, and
bandwidth in the range of kilobits
 REST – Representational State Transfer

Representational means possible to represent the underlying resource in different

formats depending on what the client requests.
State Transfer means that the client should store the state of its own
application/session.

When the client requests resources from the server, the client should send its
relevant state information to the server. This state information provides the context
so that the server/API can reply with the correct response.
The server does not have to store the state of 100’s, 1000’s or even millions of client
applications. The client is responsible for storing the state information and transfers
that state information to the server as part of the request.
RESTful Architecture Principles

Universal Resource Identifier (URI)

CoAP Network Architecture
 CoAP Messages
Confirmable (CON): Requires an ACK. If the ACK is not received, the
sender transmits the CON message over and over at exponentially
increasing intervals until it receives the ACK or a RST. This is the CoAP
form of congestion control. This is the resiliency mechanism to
compensate for the lack of resiliency in UDP.
Non-confirmable (NON): Requires no ACK. Essentially a fire-and-forget
message or broadcast.
Acknowledgement (ACK): Acknowledges a CON message. The ACK
message can piggyback along with other data.
Reset (RST): Indicates that a CON message has been received but the
context is missing. The RST message can piggyback along with other data.
 AMQP - Advanced Message Queuing Protocol

• Concept of interoperability between clients and the server by enabling

cross-vendor implementations
• An AMQP broker is tasked with maintaining message queues between
various subscribers and publishers.
• The protocol is armed with features of message orientation, queuing,
reliability, security, and routing.
• Both request–response and publish–subscribe methods are supported.
• The data format description is released on the network as a stream of
bytes. This description allows AMQP to connect to anyone who can
interpret and create messages in the same format.
 AMQP - Advanced Message Queuing Protocol

• MOM protocol used by massive data sources e.g. J P Morgan Chase

processing over 1 billion messages per day.
• AMQP is a flow-controlled, message-orientated communication system.
• AMQP attempts to decouple publishers from subscribers like MQTT.
Unlike MQTT, it has mechanisms for load balancing and formal queuing.
• Example: RabbitMQ.
• Producers and consumers subscribe to the Exchange service. The
exchange service receives messages from a publisher and routes the
data to an associated queue. This relationship is called a binding
• The binding can either be direct to one queue or fanned out to multiple
queues
• The primary unit of data in AMQP is referred to as a frame.
• These frames are responsible for the initiation of connections, termination of
connections, and control of messages between two peers using AMQP.
• There are nine frame types in AMQP:
(i) Open: responsible for opening the connection between peers.
(ii) Begin: responsible for setup and control of messaging sessions between peers.
(iii) Attach: responsible for link attachment.
(iv) Transfer: responsible for message transfer over the link.
(v) Flow: responsible for updating the flow control state.
(vi) Disposition: responsible for updating of transfer state.
(vii) Detach: responsible for detachment of link between two peers.
(viii) End: responsible for truncation of a session.
(ix) Close: responsible for closing/ending a connection
 AMQP message types

• Asynchronous Directed Messages: Message is transmitted without

requiring a receiver acknowledgment.
• Request/Reply or Pub/Sub: Similar to MQTT with a central server
acting as a pub/sub service.
• Store and Forward: This is used for hub relaying, where a message is
sent to an intermediate hub and then sent on towards its destination.
Video Links of RabbitMQ

Basics of AMQP https://www.youtube.com/watch?v=deG25y_r6OY&t=8s

Exchange & binding https://www.youtube.com/watch?v=o8eU5WiO8fw

 DDS (Data Distribution Service)

• It is an IoT protocol developed for M2M (Machine to Machine)

Communication by OMG (Object Management Group)

• It enables data exchange via publish-subscribe methodology in

broker-less architecture

• It uses multicasting to bring high quality QoS to the applications.

• DDS protocol can be deployed from low footprint devices to cloud.

• DDS is a fully distributed GDS (Global Data Space).
• Avoids single point of failure or bottleneck
• Applications can autonomously and asynchronously read/write
data in GDS.
• The publishers and subscribers can join or leave the GDS at any
point in time.
• Publishers and subscribers express their intention to produce or
consume specific type of data such as topics.
• The subscriptions are matched taking into account topics with
details such as (name, data type, QoS).
• Subscriptions are dynamically matched.
DDS provides Qos-controlled
data-sharing.
Applications communicate by
publishing and subscribing to
Topics identified by their Topic
name.
Subscriptions can specify time
and content filters and get only a
subset of the data being
published on the Topic.
DDS systems can span from Edge to Fog to Cloud.

At the edge they can be used for high-speed real-time machine to machine
communications. Within the intermediary system they can provide robust,
reliable QoS and content-aware information flows.
DDS: Data Distribution Service