CHAPTER 4:

Message Queuing Telemetry Transport (MQTT)

&
CoAP (Constrained Application) Protocol
 MQTT Protocol Stack
Application
MQTT
TCP
IP
DATA LINK LAYER

PHY LAYER

IFA’2021 2
 Message Queuing Telemetry Transport (MQTT)
n Lightweight (low network bandwidth & small code) messaging protocol for M2M & IoT
communications
n Telemetry = Tele-Metering = Remote Measurements
n Telemetry data goes from devices to a server(s) or broker(s)
n MQTT is a many-to-many communication protocol for passing messages between multiple clients
through a central broker or (brokers).
– Invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link)
– Original use case was to create a protocol for minimum battery loss and minimum
bandwidth connecting oil pipelines over satellite connections

n MQ originated from “message queueing (MQ)” architecture used by IBM for

service oriented networks.

n There is no queueing in MQTT.

IFA’2021 3
 MQTT OVERVIEW
n Telemetry data goes from devices to a server(s) or broker(s)

n Uses a publish/subscribe mechanism.

n Facebook messenger uses MQTT to minimize battery usage

(When you send a message on Facebook it goes through MQTT)

n Several other applications exist in medical, environmental applications

n Many open-source implementations (libraries) of clients and brokers are available

– Really Small Message Broker (RSMB) written C,

– Mosquitto
– Micro Broker: Java based applications for PDAs, iPADS, notebooks

IFA’2021 4
 MQTT OVERVIEW
n Built for proprietary embedded systems; now shifting to IoT

n You can send anything as a message; up to 256 MB

n Built for unreliable networks

n Enterprise scale implementations down to hobby projects

n Decouples readers and writers

n Messages have a topic, QoS, and retain status associated with them

IFA’2021 5
 MQTT OBJECTIVES
– Simple to implement
– Provide a QoS Data Delivery
– Lightweight and Bandwidth Efficient
– Data Agnostic
– Continuous Session Awareness
– Reliability and low power
– “Publish/Subscribe” model
– Requires a central MQTT broker to manage and route messages
– Uses TCP for its transport layer for reliability
IFA’2021 6
 MQTT COMPONENTS
MQTT BROKER
n Consists of three parts:
– Broker
– Subscribers
– Publishers
– Both roles can be !!

IFA’2021 7
 MQTT BROKER
n Software on a Computer
n On premise or in the Cloud
n Self Builit or 3rd Party hosted
n Open Source or Proprietary
n Receives all messages
n Filters all messages
n Publishes the messages to all subscribed clients

IFA’2021 8
 MQTT Concepts
n Topics/Subscriptions:
– Messages are published to topics (news, sports, food, fashion, trave, etc..).
– Clients can subscribe to a topic or a set of related topics
n Publish/Subscribe:
– Clients can subscribe to topics or publish to topics.
– (One to many or many to many or many to one)
Publish Topics Subscribe
Temperature
Temperature
Sensor Apartment
Dweller
Humidity
Sensor Humidity

Building
Light Manager
Sensor Light

IFA’2021 9
 MQTT ARCHITECTURE
Sensors MQTT
Sensors
Sensors
Sensors
Sensors
Broker
Sensors
Sensors

Subscriber Subscriber Subscriber Subscriber

Subscribe Subscribe Subscribe Subscribe

…/location …/speed …/contents/rfid …/location

Bridge
Broker Broker
Publish Publish Publish
Publish
…/location …/weight …/contents
…/speed
Publisher Publisher Publisher Publisher

IFA’2021 10
 Topics
n Each published data specifies a topic
n Each subscriber subscribed to that topic will receive it
n Topic format (TREE): Organized as trees using “/” character (topic level)
n TOPIC replaces the ADDRESS notion!!!

Separator /# matches all sublevels

/+ matches only one sublevel

/home/rooms/kitchen/temperature

sub-topic sub-topic sub-topic sub-topic

(topic level) 11
IFA’2021
 Publish/Subscribe Concept
(Or open source MOSQUITTO
on Windows or Linux))
(Free self hosted brokers)
If you do not want to install your own broker, use a cloud based broker ECLIPSE
iot.eclipse.org and the port is 1883 or 8883.
IFA’2021
Decoupled in space and time:
Clients do not need each others
IP address and port (space) and
they do not need to be running at
the same time (time).
The broker’s IP and port must be
known by clients
Namespace hierarchy used for
topic filtering
It may be the case that a published
message is never consumed by any
subscriber
12
 MQTT: Example
n Clients connect to a “Broker” MQTT BROKER
n Clients subscribe to topics e.g.,
– client.subscribe(‘toggleLight/1’)
– client.subscribe(‘toggleLight/2’)
– client.subscribe(‘toggleLight/3’)

n Clients can publish messages to topics:

– client.publish(‘toggleLight/1’, ‘toggle’);
– client.publish(‘toggleLight/2’, ‘toggle’);

n All clients receive all messages published to

topics they subscribe to

n Messages can be anything

– Text
– Images
– etc.
IFA’2021 13
 Durable/Transient Subscriptions

n Subscriptions
– Clean Sessions:
At connection setupà Clean session flag à all subscriptions are removed on disconnect.
(When I disconnect then do not worry about me; I leave Rejkjavik I do not need weather report anymore)

– Durable Connections
l When I disconnect, please save/store it for my future need
l Subscription messages remain in effect after disconnection.
l Subscriber disconnect messages are buffered at the broker and delivered upon reconnection

– Non-durable Connections
l Connection lifetime gives subscription lifetime

IFA’2021 14
 State Retention
n Publications
– Retained (“Persistent”) Sessions/Messages
- When a client subscribes to a topic, retained messages are automatically delivered
- Server (Broker) keeps messages even after sending it to all subscribers.
– New subscribers get the retained messages

– One flag set both in the publish packet to the broker and in the
published packet to the subscribers
lOnly the most recent persistent message is stored and distributed

IFA’2021 15
 MQTT Session Aware Features
n Last Will and Testament (LWT) Message:
– At connection a client can inform that it has a WILL or a message that should
be published if unpexpected disconnection occurs à Alarm if the client looses
connection
In other words, topic published upon disconnecting a connection

n Any client can register a LWT

n Anybody subscribing to the LWT topic will know when a certain device (that
registered a LWT) gets disconnected

• Periodic KEEP ALIVE MESSAGES à If a client is still alive

IFA’2021 16
 MQTT has built in QoS levels for Message Delivery
Publishing “QoS” (Reliability)
n 0 – Unreliable (aka “at most once”) (Best Effort; no ACK)
– “Fire and Forget”
(Send it to me when you have it; if it does not get there, who cares)
In other words, you produce message, and send, if there is no device
receiving it, then do not care)
– OK for continuous streams, least overhead (1 message)
– TCP will still provide reliability

IFA’2021 17
 Publishing “QoS” (Reliability)

n 1 – Delivery “at least once” (duplicates possible)

– At least once (ACKed, retransmitted if ACK is not received)
– Used for alarms – more overhead (2 messages)
– Contains message ID (to match with ACKed message)

IFA’2021 18
 Publishing “QoS” (Reliability)
n 2 – Delivery “Exactly Once”
[Request to Send (Publish), Clear-to-Send (Pubrel), Message (Pubrel),
ACK (Pubcomp)] (No duplication; no loss)
– Utmost reliability is important – most overhead (4 messages) and slowest

IFA’2021 19
 Publishing “QoS” (Reliability)

n Reliability maintained even if the TCP connection

breaks (intermittent connections)

n Separate QoS for publishing and for subscribing

IFA’2021 20
 MQTT Message Format

Shortest Message is Two Bytes

IFA’2021 21
 Message Types

IFA’2021 22
 Message Types

IFA’2021 23
 MQTT Application Example

n Home pacemaker monitoring solution

n Sensors on patient
n Collected by a monitoring equipment in home (broker) using MQTT
n Subscribed by a computer in the hospital
n Alerts the doctor if anything is out-of-order

Instrumented Interconnected Intelligent

Patient at Home Home Monitoring Internet Message Server Analytical Doctor

Appliance with Application
MQTT
IFA’2021 24
 MQTT versus HTTP
MQTT HTTP
Design Data centric (Messaging) Document centric
Pattern Publish/Subscribe (continuous) Request/Response (one shot deal)
Complexity Simple (limited in scope) More Complex (very broad)
Message Size Small. Binary with 2B header Large.
Service Levels Three One
Libraries 30 kB in C and 100 kB in Java Very Large
Data Distribution 1 to zero, one, or n 1 to 1 only

n Open source, http://www.eclipse.org/paho/

n Clients available in .NET, Perl, Python, REXX, Rube
n Also for single board micro controller Arduino (8-bit Atmel
AVR or 32 bit Atmel ARM, $20)
Mbed, Nanode, Netduino
IFA’2021 25
 MQTT versus HTTP

MQTT HTTP
Purpose Messaging Documents
Protocol Efficiency High Average
Power Efficiency High Average
QoS Yes No
Client Languages Many Many

IFA’2021 26
 MQTT: Advantages
n Publish/Subscribe model
– Brokers and nodes publish information and others subscribe according to the
message content, type, or subject.
– Generally, the broker subscribes to all messages and then manages information
flow to its nodes.
– Advantages
l Space Decoupling:
– Nodes can publish information and subscribe without any knowledge of each other
l Time Secoupling
– Nodes can remain in sleep states even when other nodes are publishing messages
l Synchronization Decoupling
– For nodes in operation, messages are queued by the broker until the receiving node is finished with its
existing operation

IFA’2021 27
 MQTT – Disadvantages
n Centralized Broker
– Must be specialized due to increased cost and responsibility
– Can be a drawback for distributed IoT systems
– Can become a single point of failure for the complete network
n TCP
– Designed for devices with more memory and processing resources
(e.g., multi-step handshake)
– With TCP, it is ideal for two communicating nodes to hold their TCP sockets
open for each other continuously with a persistent session.
– Without session persistence, need to establish connection over and over.

IFA’2021 28
 CoAP (Constrained Application) Protocol Stack

• TCP overhead is Application

too high and its
flow control is not CoAP
appropriate for
short-lived UDP
transactions
IP
• UDP has lower DATA LINK LAYER
overhead and
supports multicast PHY LAYER

IFA’2021 29
 Constrained Application Protocol (CoAP)

n Subset of HTTP functionality re-designed for IoT and M2M

n UDP Binding with Reliability and Multicast Support (MQTT none)
n REST-based web transfer protocol
n Manipulates Web resources using the same methods as HTTP:
GET, PUT, POST, and DELETE

n Small simple 4 byte header

n Lightweight fast HTTP
n Asynchronous Message Exchange

IFA’2021 30
 What is REST? (Representational State Transfer)

n Web standards architecture and provides methods to access resources

n Resource is typically any kind of information, i.e., text, images, etc.
n REST commonly supports four methods:
– GET: Provides a read only access to a resource
– PUT: Used to update an existing resource or create a new resource
– POST: Used to create a new resource/information
– DELETE: Used to remove a resource/information

IFA’2021 31
 CoAP FEATURES

n OBSERVE à GET + OBSERVE

If you send a GET with OBSERVE flag, each time a sensor device/serve
sees any change in any state, it will push the notification to the originator.

n DISCOVERY: SERVER LIST (RESOURCES+MEDIA TYPES)

How to find devices around ?

IFA’2021 32
 CoAP

CoAP enables web services constrained devices and networks,

while integrating with the web architecture and HTTP

IFA’2021 33
 CoAP REST Compatibility

IFA’2021 34
 CoAP Architecture

CoAP has…
UDP
Multicast Support
Security (DTLS)
Use of URI allows interaction
expectations
Asynchronous Comms
(observe) – similar to pub/sub

BUT…
Immature
QoS = confirming message
received
IFA’2021 35
 Use Case
Light
LoWPAN-1

(IPv6 Multicast enabled)

Backbone
Switch

Network
Light-1
Router-1
(6LoWPAN Border Router)

LoWPAN-2
Light-2

Router-2
Light-3 (6LoWPAN Border Router)

Use-cases
IP Multicast Group •Group light control
(Room-A-Lights)
Room-A •Firmware updates
•Parameter distribution
IFA’2021 36
 CoAP Message Types

n Four message types for QoS:

– CON: Confirmable – requires an ACK
– NON: Non-confirmable – no ACK needed
– ACK Acknowledgement – ACKs a Confirmable
– RST: Reset - indicates a Confirmable message has been
received but context is missing for processing

IFA’2021 37
 CoAP Features
n CoAP provides reliability without using TCP as transport protocol

n CoAP enables asynchronous communication

– e.g., when CoAP server receives a request which it cannot handle immediately, it first ACKs the
reception of the message and sends back the response in an off-line fashion

n Also supports multicast and congestion control

IFA’2021 38
 CoAP: Open Source Implementations

n mbed
n Java CoAP Library Californium
n C CoAP Library Erbium
n libCoAP C Library
n Open CoAP C Library
n TinyOS and Contiki Operating Systems with CoAp Support

n Firefox has a CoAP plugin called Copper

n You can implement CoAP by yourself

IFA’2021 39
 CoAP versus HTTP

IFA’2021 40
 Comparison CoAP & MQTT
Both used in IoT

n CoAP:
– one-to-one communication
– UDP/IP
– unreliable
– lightweight and easy to implement

n MQTT:
– many-to-many communication
– TCP/IP
– focus on message delivery; reliable
– higher overheads (protocol data, processing costs)

IFA’2021 41