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
 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
 Topics beginning with $

The $-symbol topics are reserved for internal statistics of the MQTT broker.
Clients cannot publish messages to these topics
• 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 MQTT Brokers

Types of brokers
 Managed Brokers
Managed broker services allow to use their hosted brokers for their clients. AWS IoT
Core is a good example of a managed MQTT Broker.

 Self-Hosted Brokers
As the name implies, self-hosted MQTT brokers require to install the broker on own
server with a static IP. The installation process is not difficult but managing, securing,
and scaling the brokers requires in-depth knowledge of the system. There are several
open-source implementations of MQTT brokers including mosquitto and hivemq.
 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.
Universal Resource Identifier (URI)
 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
 REST – Representational State Transfer

Representational means that it should be 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
CoAP Network Architecture
Transactional layer: Handles single
message exchanges between
endpoints using one of the four basic
message types (CON, NON, ACK, RST).
The transaction layer also supports
multicasting and congestion control.

Request/Response layer: Responsible

for sending and receiving RESTful-
based queries. REST queries are
piggybacked on CON or NON messages.
A REST response is piggybacked on the
corresponding ACK message.
 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

• 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
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

 Exchange type Default pre-declared names
Direct exchange (Empty string) and amq.direct
Fanout exchange amq.fanout
Topic exchange amq.topic
Headers exchange amq.match (and amq.headers in
RabbitMQ)
 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.
 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