CSE3009

Internet of Things
Dr. B.KALAAVATHI
Professor Grade-1
Department of IoT
School of Computer Science and Engineering (SCOPE)
Vellore Institute of Technology Vellore
Mail: kalaavathi.b@vit.ac.in
Mobile: 94425 40803
Cabin: SJT615B
1
Message Queueing Telemetry Transport
protocol (MQTT)
What is MQTT?
• MQTT is a lightweight message queueing Telemetry transport
protocol.
• MQTT, as its name implies, is suited for the transport of
telemetry data (sensor and actor data).
• MQTT is very lightweight and thus suited for M2M (Mobile to
Mobile), WSN (Wireless Sensor Networks) and ultimately IoT
(Internet of Things) scenarios where sensor and actuator nodes
communicate with applications through the MQTT message
broker.
2
•Example:
•Light sensor continuously
sends sensor data to the
broker.
•Building control
application receives
sensor data from the
broker and decides to
activate the blinds.
•Application sends a blind
activation message to the
blind actor node through
the broker.
3
MQTT characteristics
•MQTT Key features:
• Lightweight message queueing and transport protocol
• Asynchronous communication model with messages (events)
• Low overhead (2 bytes header) for low network bandwidth applications
• Publish / Subscribe (Pub/Sub) model
• Decoupling of data producer (publisher) and data consumer (subscriber)
through topics (message queues)
• Simple protocol, aimed at low complexity, low power and low footprint
implementations (e.g. WSN - Wireless Sensor Networks)
• Runs on connection-oriented transport (TCP). To be used in conjunction
with 6LoWPAN (TCP header compression)
• MQTT caters for (wireless) network disruptions
4
5
6
Why MQTT?
• It’s a lightweight protocol. So, it’s easy to implement in software and
fast in data transmission.
• It’s based on a messaging technique.
• Minimized data packets. Hence, low network usage.
• Low power usage. As a result, it saves the connected device’s battery.
• It’s real time! That’s is specifically what makes it perfect for IoT
applications.

7
MQTT – MQ Telemetry Transport
MQTT model (1/3)
The core elements of MQTT are clients, servers (=brokers), sessions, subscriptions
and topics.
MQTT – MQ Telemetry Transport
MQTT model (2/3)
MQTT client (=publisher, subscriber):
Clients subscribe to topics to publish and receive messages. Thus subscriber and publisher are
special roles of a client.
Client

Publisher Subscriber

MQTT server (=broker):

Servers run topics, i.e. receive subscriptions from clients on topics, receive messages from clients
and forward these, based on client’s subscriptions, to interested clients.

Topic:
Technically, topics are message queues. Topics support the publish/subscribe pattern for clients.
Logically, topics allow clients to exchange information with defined semantics. Example
topic: Temperature sensor data of a building.

Publisher Topi Subscriber

c
MQTT – MQ Telemetry Transport

MQTT model (3/3)

Session:
A session identifies a (possibly temporary)
attachment of a client to a server. All communication
between client and server takes place as part of a
session.

Subscription:
Unlike sessions, a subscription logically attaches a client
to a topic. When subscribed to a topic, a client can
exchange messages with a topic.
Subscriptions can be «transient» or «durable», depending
11
•Message:
•Messages are the units of data exchange between topic
clients.
•MQTT is agnostic to the internal structure of messages.

12
• How MQTT works?
• Server is responsible for handling the client’s requests of
receiving or sending data between each other.
• MQTT server is called a broker and the clients are simply the
connected devices.
• So:
• When a device (a client) wants to send data to the broker, we call
this operation a “publish”.
• When a device (a client) wants to receive data from the broker, we
call this operation a “subscribe”.

13
14
• Example:
• Let’s say there is a device that has a temperature sensor. Certainly, it
wants to send its readings to the broker.
• On the other side, a phone/desktop application wants to receive this
temperature value.
• Therefore, 2 things will happen:
• device defines the topic it wants to publish on, ex: “temp”. Then, it
publishes the message “temperature value”.
• phone/desktop application subscribes to the topic “temp”. Then, it
receives the message that the device has published, which is the
temperature value.
• Again, the broker role here is to take the message “temperature
value” and deliver it to phone/desktop application.
15
16
• How many devices you can connect to a broker?
• number of connected devices “clients” to the broker
depends on the broker service provider.
• it can reach a massive number of clients those are publishing
and subscribing all the time.
• Not only the huge number of these connected devices but
also any device can get any other device’s data at any time.
• applications based on these quickly shared data are limitless.

17
• Why not HTTP ?
• HTTP is slower, more overhead and power consuming protocol than
MQTT.
• Slower: because it uses bigger data packets to communicate with the
server.
• Overhead: HTTP request opens and closes the connection at each
request, while MQTT stays online to make the channel always open
between the broker “server” and clients.
• Power consuming: since it takes a longer time and more data
packets, therefore it uses much power.

18
• IoT platform is just a
cloud-based software
that implements a
broker server and some
software with GUI to
allow user control and
monitor the connected.
devices.
• MQTT broker is
included implicitly
inside the IoT platform.

19
• Which broker to use?
• many brokers that implement the MQTT
protocol.
• One of the most popular and commonly
used is the mosquitto broker.
• Mosquitto is an open source message
broker that implements the MQTT
protocol.
• It’s lightweight and suitable for use on all
devices from a low power single board like
Arduino, ESP8266 to full computers and
servers.
• need to use a cloud-based server that
implements the Mosquitto broker to make
IoT projects controllable over the internet.
20
Topic
s
• In MQTT, the word topic refers to an UTF-8 string that the broker uses
to filter messages for each connected client.
• The topic consists of one or more topic levels.
• Each topic level is separated by a forward slash

• Topics are case-sensitive.

• Wildcards
• When a client subscribes to a topic, it can subscribe to the exact topic of a
published message or it can use wildcards to subscribe to multiple topics
simultaneously.
• A wildcard can only be used to subscribe to topics, not to publish a
message.
• single-level multi-level

ľhe $-symbol topics are reserved for internal statistics of the MQTT broker.
Clients cannot publish messages to these topics.
$SYS/broker/clients/connected
$SYS/broker/messages/sent
$SYS/broker/uptime
Message format of MQTT
protocol
• All the messages of MQTT have a small code footprint, hence it is
popular as a lightweight messaging protocol.
• Fixed header (2 bytes) [Control + remaining length]
• Optional variable header
• Message payload (<= 256MB)
• Quality of Service (QoS) level
• MQTT supports one-to-one, one-to-many, and many-to-many
communication
Quality of
Service
• The Quality of Service (QoS) level is an agreement between the
sender of a message and the receiver of a message that defines the
guarantee of delivery for a specific message.
• There are 3 QoS levels in MQTT:
• At most once (0)
• At least once (1)
• Exactly once (2).
• When you talk about QoS in MQTT, you need to consider the two
sides of message delivery:
• Message delivery form the publishing client to the broker.
• Message delivery from the broker to the subscribing client.
• The client that publishes the message to the broker defines the QoS
level of the message when it sends the message to the broker.
• The broker transmits this message to subscribing clients using the
QoS level that each subscribing client defines during the subscription
process.
• QoS 0 - at most once
• This service level guarantees a best-effort delivery.
• There is no guarantee of delivery.
• The recipient does not acknowledge receipt of the message and the message
is not stored and re-transmitted by the sender.
• QoS level 0 is often called “fire and forget”
• QoS 1 - at least once
• QoS level 1 guarantees that a message is delivered at least one time to the
receiver.
• The sender stores the message until it gets a PUBACK (Publish
acknowledgement) packet from the receiver that acknowledges receipt of
the message.
• It is possible for a message to be sent or delivered multiple times.
• 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.
• The guarantee is provided by at least two request/response flows (a four-part
handshake) between the sender and the receiver.
• The sender and receiver use the packet identifier of the original
PUBLISH message to coordinate delivery of the message.

PUBREC - Publish received

PUBREL - Publish release
PUBCOMP - Publish Complete
Exampl
e
• MQTT – Topics
• Format
• You have a device that publishes “on” and “off” messages on
the home/office/lamp topic.
• You have a device that controls a lamp (it can be an ESP32, ESP8266, or any
other board). The ESP32 that controls your lamp, is subscribed to that
topic: home/office/lamp.
• So, when a new message is published on that topic, the ESP32 receives the
“on” or “off” message and turns the lamp on or off.
• Cloud-based Mosquitto brokers are many, like:
• ThingMQ
• ThingStudio
• MQTT.io
• Heroku
• CloudMQTT