1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

Introduction to MQTT
MQTT (Message Queuing Telemetry Transport) – a messaging protocol used in many IoT
applications. It is a lightweight messaging protocol designed for M2M (machine to
machine) telemetry in low bandwidth environments. It is fast becoming one of the main
protocols for IOT (internet of things) deployments.

It was designed by Andy Stanford-Clark (IBM) and Arlen Nipper in 1999 for connecting
Oil Pipeline telemetry systems over satellite.

Although it started as a proprietary protocol it was released Royalty free in 2010 and
became an OASIS standard in 2014.

From smartwatches to home security systems and connected cars, MQTT enables
seamless communication among these devices, making our lives more convenient and
interconnected. Using MQTT in IoT enables real-time and asynchronous device
communication, while conserving power and bandwidth.

MQTT is a publish/subscribe protocol designed for connecting IoT devices. Unlike HTTP’s
request/response paradigm, MQTT operates in an event-driven manner, allowing
messages to be pushed to clients. This architectural approach enables highly scalable
solutions by decoupling data producers and data consumers, eliminating dependencies
between them. Two key components to establish MQTT connection for publishing and
subscribing of the messages are MQTT Clients and MQTT Broker as shown in the
diagram below.

How MQTT Works

As mentioned in the introduction, MQTT is a publish/subcribe messaging protocol.
Clients will connect to the network, which can subscribe or publish to a topic. When a
client publishes to a topic, the data is sent to the broker. The MQTT broker is responsible

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 1/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

for receiving all messages, filtering the messages, deciding who is interested in them, and
then publishing the message to all clients that are subscribed to that topic.

Topics are arranged in a directory-like structure. A topic might be "LivingRoom", or

"LivingRoom/Light" if you have multiple clients within that parent topic. Topics are
represented with strings separated by a forward slash. Each forward slash indicates a
topic level. The subscriber client will listen for incoming messages from the subscribed
topic and react to what was published to that topic, such as "on" or "off". Clients can
subscribe to one topic and publish to another as well. If the client subscribes to
"LivingRoom/Light", it might also want to publish to another topic like
"LivingRoom/Light/State" so that other clients can monitor the state of that light.

The Main MQTT Elements

In the section above, we already touched on what MQTT clients and an MQTT broker are.
In this segment, we will dive deeper into each of the involved parties, introduce new
MQTT system elements such as an MQTT packet, MQTT messages, and the MQTT broker
web interface and elaborate on their roles and interactions with each other.

1. MQTT Client - An MQTT client can, for example, be a device (sensors, smartphones,
web apps, and other devices) that establishes a connection to an MQTT broker.

Previously we defined two roles that MQTT clients can have:

A publisher – an MQTT client that publishes a message on a topic.

A subscriber – an MQTT client that subscribes to a topic to receive all messages
posted to it.

A single MQTT client can simultaneously be a publisher and a subscriber.

To establish the connection, clients use an MQTT library, a software component that
handles the MQTT protocol implementation. MQTT libraries provide an interface
between clients and the MQTT broker, allowing the clients to communicate with the
broker.

2. MQTT broker - At the core of the MQTT system is the MQTT broker, which serves as a
central message hub. It receives messages from publishers and routes them to
subscribers based on their topic subscriptions.

3. MQTT Packets - MQTT relies on packets to enable communication between the client
and the broker. Here are just a few examples of packets:

CONNECT: An MQTT client uses this packet to establish a connection with the
broker.
PUBLISH: The client employs this packet to send a message to a topic.
SUBSCRIBE: Clients use this packet to join one or more topics.
UNSUBSCRIBE: Clients can utilize this packet to leave one or more topics.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 2/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

DISCONNECT: The client can terminate the connection with the broker using this
packet.

These examples do not encompass the full spectrum of MQTT packets.

4. MQTT Messages - Note that the MQTT PUBLISH packet includes a payload
(sometimes called a message) that contains custom data sent to a broker by a publisher.
The broker then relays it to interested subscribers. Such messages are versatile and can
contain various types of data — from sensor readings and commands to vital status
updates, making them central to MQTT’s communication model.

MQTT QoS
For an MQTT message to reach its destination, it has to overcome a path from a
publisher to a broker, and then from the broker to a subscriber. In other words, there are
at least two stages of delivery where a message could get lost in the transmission
process. That is why MQTT QoS is necessary, as message loss directly impacts the
reliability of IoT projects. By offering different QoS levels, MQTT empowers clients to
optimize their network usage and achieve the desired balance between reliability and
efficiency.

MQTT provides three levels of QoS:

At most once (QoS 0)

At least once (QoS 1)
Exactly once (QoS 2)

QoS 0
At the lowest level, QoS 0 in MQTT offers a best-effort delivery mechanism where the
sender does not expect an acknowledgment or guarantee of message delivery. This
means that the recipient does not acknowledge receiving the message, and the sender
does not store or re-transmit it. QoS 0, commonly called “fire and forget,” functions akin
to the underlying TCP protocol, where the message is sent without further follow-up or
confirmation.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 3/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

QoS 1
In QoS 1 of MQTT, the focus is on ensuring message delivery at least once to the
receiver. When a message is published with QoS 1, the sender keeps a copy of the
message until it receives a PUBACK packet from the receiver, confirming the successful
receipt. If the sender doesn’t receive the PUBACK packet within a reasonable time frame,
it re-transmits the message to ensure its delivery.

Upon receiving the message, the receiver can process it immediately. For example, if the
receiver is an MQTT broker, it distributes the message to all subscribing clients and
responds with a PUBACK packet to acknowledge the receipt of the message.

It’s important to note that in QoS 1, if the publishing client sends the same message
again, it sets a duplicate (DUP) flag. However, this flag is used for internal purposes and is
not processed by the broker or client. Regardless of the DUP flag, the receiver still sends
a PUBACK packet to acknowledge the receipt of the message, ensuring the sender is
aware of the successful delivery.

This approach of QoS 1 strikes a balance between reliability and efficiency, guaranteeing
that the message reaches the receiver at least once while allowing for potential
duplicates to be handled appropriately.

QoS 2
QoS 2 offers the highest level of service in MQTT, ensuring that each message is
delivered exactly once to the intended recipients. To achieve this, QoS 2 involves a four-
part handshake between the sender and receiver.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 4/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

When a receiver gets a QoS 2 PUBLISH packet from a sender, it processes the publish
message accordingly and replies to the sender with a PUBREC packet that acknowledges
the PUBLISH packet. If the sender does not get a PUBREC packet from the receiver, it
sends the PUBLISH packet again with a duplicate (DUP) flag until it receives an
acknowledgment.

After the receiver gets the PUBREL packet, it can discard all stored states and answer with
a PUBCOMP packet (the same is true when the sender receives the PUBCOMP). Until the
receiver completes processing and sends the PUBCOMP packet back to the sender, the
receiver stores a reference to the packet identifier of the original PUBLISH packet. This
step is important to avoid processing the message a second time.

After the sender receives the PUBCOMP packet, the packet identifier of the published
message becomes available for reuse.

When the QoS 2 flow is complete, both parties are sure that the message is delivered
and the sender has confirmation of the delivery.

If a packet gets lost along the way, the sender is responsible to retransmit the message
within a reasonable amount of time. This is equally true if the sender is an MQTT client or
an MQTT broker. The recipient has the responsibility to respond to each command
message accordingly.

Packet Identifier - Packet identifiers used for QoS 1 and 2 are unique
between a specific client and a broker within an interaction. However, they
are not unique across all clients. Once a flow is complete, the packet
identifier becomes available for reuse. This is why the packet identifier
does not need to exceed 65535 , as it is unrealistic for a client to send
more messages than that without completing an interaction

The Standard MQTT Ports

Port 1883: Default port for non-secure MQTT communication.
Port 8883: Default port for secure MQTT communication using TLS/SSL encryption.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 5/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

The choice of port 1883 was based on historical and conventional factors during its
development in the late 1990s. At the time, port 1883 was was vacant, which meant that
the MQTT protocol could utilize this port without conflicting with other well-known
services. As MQTT gained popularity, port 1883 became the default in many MQTT
implementations. It simplified the process for developers to connect devices and
applications using this standardized port.

For secure communication using TLS/SSL, MQTT utilizes port 8883. This is often referred
to as MQTT over TLS (MQTT/SSL). The reasoning behind port 8883 is likely due to its
memorability and similar conventions as port 1883. Port 8883 was also vacant and, same
as 1883, fell into the range of high ports (above 1023) available for custom services.

While it is possible to customize MQTT port numbers if needed, such modifications

require explicit configuration of both the MQTT client and broker. Sticking to the
standard port numbers is recommended to ensure smooth interoperability and hassle-
free communication across various MQTT implementations.

Benefits of the MQTT protocol

The MQTT protocol in IoT has become extremely popular and widely adopted due to the
following benefits:

Lightweight - The design of MQTT messages are small (the smallest message can
be as small as just two bytes), making them easy to transmit over networks. The
protocol is binary-based which optimizes the size of the messages and, therefore,
consume minimal bandwidth during its transmission. This makes MQTT ideal for
applications that often operate within limited network capacity.

Reliability - MQTT allows to adjust the level of reliability for message delivery to the
intended recipients. Therefore, MQTT supports different MQTT Quality of Service
(QoS) levels and allows user to specify the importance of message delivery by
choosing from QoS levels 0, 1 and 2. QoS 0 does not ensure a message was reliably
delivered, whereas 2 ensures that an intended subscriber receives a message exactly
once. For other cases, when a network stability comes under question, one can also
utilize persistent MQTT sessions. An active MQTT persistent session ensures that
even if a client has already established a connection with a broker and subscribed to
a specific topic goes offline, the broker will preserve the information the client did
not receive since the last active session. This information will be sent to the
subscriber when it comes back online.

Secure Communication - MQTT is very flexible and allows developers to implement

extra security measures as part of an MQTT broker functionality like username and
password authentication, client certificate authentication, and encryption using
Transport Layer Security (TLS), also colloquially referred to as Secure Sockets Layer
(SSL). You can also utilize access control lists and other measures to protect your
MQTT setup from unauthorized access and ensure its high level of security.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 6/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

Scalability: MQTT protocol supports both horizontal and vertical scalability

approaches, enabling smooth growth and scaling of your IoT project.
Simple Integration - The MQTT protocol’s simplicity and availability of various
MQTT libraries for different programming languages and platforms make it easy for
new IoT developers to integrate it into systems.

Strong Industry Support - MQTT has gained widespread support throughout the
industry, with MQTT brokers and client libraries forming a robust ecosystem of tools
and resources. Many providers also feature convenient and ready-to-use cloud or
on-premises MQTT solutions. They offer rich features and additional tools that make
MQTT even more accessible and easy to work with.

MQTT Common Use Cases

While smart homes represent a common use case for MQTT, its effectiveness extends
well beyond home automation. MQTT is widely applicable in various IoT and machine-to-
machine (M2M) scenarios. Several examples of these applications include:

Industrial Monitoring and Control - Within industrial settings, MQTT plays a

crucial role in the real-time monitoring and control of machinery, sensors, and
equipment. It facilitates communication between devices on the factory floor
enabling data collection, process optimization, and predictive maintenance for
improved productivity.

Telemetry and Remote Sensing - MQTT is suitable for applications that center
around sensing and telemetry such as monitoring, weather stations, and agricultural
systems. It enables the collection and transmission of data from sensors located in
remote areas to servers or cloud platforms. This facilitates decision-making
processes driven by data.

Asset Tracking and Fleet Management - MQTT is vital in asset tracking systems
and fleet management solutions by providing real-time location updates for
vehicles, containers, and valuable assets. It ensures tracking capabilities alongside
route optimization, which enhances the overall efficiency of transportation
operations.

Energy Management and Smart Grids - MQTT plays a significant role in energy
management by facilitating communication between smart meters, energy
monitoring systems, and utilities. It enables real-time data exchange, which helps
manage load balancers and implement demand response mechanisms. These
capabilities can help optimize energy consumption, contributing to the development
of smart grids.

Healthcare - In the healthcare industry, MQTT guarantees reliable communication

for a range of applications, including patient monitoring, telemedicine, and health
tracking devices. It enables the transmission of vital signs, patient data, and alerts

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 7/8
1/14/25, 10:52 AM Unit3 (Part 2) - MQTT

between devices and healthcare providers. This exchange elevates patient care and
contributes to improved health outcomes.
Smart Cities - MQTTs capabilities also extend to city applications such as street
lighting, waste management systems, traffic monitoring solutions, and
environmental monitoring technologies. MQTT contributes to city infrastructure
development while optimizing resource usage by enabling data exchange and
control in these areas. Ultimately, the goal is to enhance the quality of life for urban
residents.

https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fround-lake.dustinice.workers.dev%3A443%2Fhttps%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequence… 8/8