Skip to content

What is MQTT Quality of Service (QoS) 0,1, & 2? – MQTT Essentials: Part 6

by HiveMQ Team
(updated on ) 16 min read

MQTT Quality of Service (QoS) is an agreement between the message sender and receiver that defines the level of delivery guarantee for a specific message. Here’s Part 6 of MQTT Essentials, where we will look deeper at the different Quality of Service (QoS) levels in MQTT. If you are looking to understand MQTT Topics, Wildcards, & Best Practices, check out Part 5 of the series. Else, let’s dive in.

What is Quality of Service (QoS) in MQTT?

MQTT provides three levels of QoS:

  • At most once (QoS 0)

  • At least once (QoS 1)

  • Exactly once (QoS 2)

How to Examine Message Delivery in MQTT?

When discussing QoS in MQTT, it’s important to consider message delivery from the publishing client to the broker and from the broker to the subscribing client. These two aspects of message delivery have subtle differences.

The client that publishes a message to the broker defines the QoS level for the message during transmission. The broker then transmits the message to subscribing clients using the QoS level defined by each subscribing client during the subscription process. If the subscribing client defines a lower QoS level than the publishing client, the broker will transmit the message with the lower QoS level.

Understanding how message delivery works in MQTT sets the foundation for appreciating the significance of Quality of Service (QoS) levels in ensuring reliable communication between the publishing client, broker, and subscribing client.

Why is Quality of Service (QoS) Important?

Quality of Service (QoS) is crucial in MQTT due to its role in providing the client with the ability to select a service level that aligns with both the network reliability and the application’s requirements. MQTT’s inherent capability to handle message re-transmission and ensure delivery, even in unreliable network conditions, makes QoS essential for facilitating seamless communication in such challenging environments. By offering different QoS levels, MQTT empowers clients to optimize their network usage and achieve the desired balance between reliability and efficiency.

Now that we understand the significance of Quality of Service (QoS) in MQTT, let’s delve into the inner workings of QoS and explore how it operates to ensure reliable message delivery in varying network conditions.

How does QoS 0 work in MQTT?

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.

Quality of Service level 0: delivery at most onceQuality of Service level 0: delivery at most once

How does QoS 1 work in MQTT?

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.

Quality of Service level 1: delivery at least onceQuality of Service level 1: delivery at least once

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.

MQTT PUBACK packetMQTT PUBACK packet

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.

How does QoS 2 work in MQTT?

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.

MQTT Quality of Service level 2: delivery exactly onceMQTT Quality of Service level 2: delivery exactly once

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.

MQTT PUBREC PacketMQTT PUBREC Packet

Once the sender receives a PUBREC packet from the receiver, the sender can safely discard the initial PUBLISH packet. The sender stores the PUBREC packet from the receiver and responds with a PUBREL packet, the receiver discards all stored states and replies with a PUBCOMP packet.

MQTT PUBREL PacketMQTT PUBREL Packet

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.

MQTT PUBCOMP PacketMQTT PUBCOMP Packet

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.

What are the Key Considerations for QoS in MQTT?

While understanding QoS in MQTT, there are several important aspects to keep in mind:

Downgrade of QoS

The QoS levels defined by the sender and receiver can differ. The client sending the message to the broker defines the QoS level, while the broker uses the QoS defined by the receiver during subscription. For example, if the sender uses QoS 2 and the receiver subscribes with QoS 1, the broker delivers the message to the receiver with QoS 1. This can result in multiple deliveries of the same message to the receiver.

Packet identifiers are unique per client

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

What are the Best Practices While Using MQTT Quality of Service (QoS) 0,1, & 2?

We are often asked for advice about how to choose the correct QoS level. Selecting the appropriate QoS level depends on your specific use case. Here are some guidelines to help you make an informed decision:

Use QoS 0 when:

  • You have a completely or mostly stable connection between sender and receiver. A classic use case for QoS 0 is connecting a test client or a front end application to an MQTT broker over a wired connection.

  • You don’t mind if a few messages are lost occasionally. The loss of some messages can be acceptable if the data is not that important or when data is sent at short intervals

  • You don’t need message queuing. Messages are only queued for disconnected clients if they have QoS 1 or 2 and a persistent session.

Use QoS 1 when:

  • You need to get every message and your use case can handle duplicates. QoS level 1 is the most frequently used service level because it guarantees the message arrives at least once but allows for multiple deliveries. Of course, your application must tolerate duplicates and be able to process them accordingly.

  • You can’t bear the overhead of QoS 2. QoS 1 delivers messages much faster than QoS 2.

Use QoS 2 when:

  • It is critical to your application to receive all messages exactly once. This is often the case if a duplicate delivery can harm application users or subscribing clients. Be aware of the overhead and that the QoS 2 interaction takes more time to complete.

Queuing of QoS 1 and 2 messages

All messages sent with QoS 1 and 2 are queued for offline clients until the client is available again. However, this queuing is only possible if the client has a persistent session.

Conclusion

That’s the end of Part 6 of our MQTT Essentials series. We hope that you find this information useful. In the next article, we cover a subject that is closely associated with Quality of Service levels: persistent sessions in MQTT.

Are you enjoying our content? Then sign up for our newsletter below. Subscribe to our RSS feed here to stay updated. Do check out MQTT FAQs and MQTT Glossary to know all the key MQTT terminologies. Watch the video below that complements the concepts discussed in this article.

Watch the Video

Chapters
  • 00:00 - Introduction
  • 00:18 - What are Quality of Service (QoS) Levels in MQTT?
  • 01:51 - QoS 0: delivery at most once in MQTT
  • 02:21 - QoS 1: delivery at least once in MQTT
  • 03:05 - QoS 2: delivery exactly once in MQTT
  • 03:58 - Best practices with QoS level in MQTT
  • 05:21 - Announcing part 8 - Persistent Sessions & Message Queueing in MQTT

FAQs on QoS in MQTT

HiveMQ Team

The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.

Related content:

Enhanced Authentication - MQTT 5 Essentials Part 11

authentication flow in enhanced authentication relies on three MQTT message types: CONNECT, CONNACK (already present in MQTT v3), and the new MQTT v5 AUTH message.

Blog

The Importance of an ROI-driven Framework for Industry 4.0 and IIoT

Learn the importance of building ROI framework into a POC & how MQTT helps improve ROI-influencing KPIs like OEE, predictive maintenance, etc. in IIoT.

Blog

Smart Cities and Public Safety Made Possible with MQTT and HiveMQ

Explore how MQTT protocol and HiveMQ MQTT platform together can help in creating smart cities and enable public safety.

Blog

Real-time Analytics of MQTT Messages Using Elasticsearch, Kibana & HiveMQ

Learn to harness the power of Elasticsearch, Filebeat, Kibana, and HiveMQ for real-time analytics on MQTT messages. This blog covers installation, configuration, and deployment, allowing you to efficiently manage and analyze MQTT traffic.

Blog

Managing IoT Device State Within MQTT

Explore efficient and scalable IoT device state management with our blog series on architectural patterns. Learn how to implement device state seamlessly within MQTT.

Blog

Masterless Clustering of MQTT Broker for Business Continuity

Discover HiveMQ MQTT platform’s masterless clustering architecture, which provides business continuity for mission-critical applications across indusries.

Blog

Hands-on Guide to LoRaWAN and HiveMQ MQTT Broker Integration for IoT

A technical hands-on guide to integrating HiveMQ MQTT broker with ChirpStack open source LoRaWAN network server for IoT applications.

Blog

Reinforcing Security of OT Systems in IIoT with MQTT and HiveMQ

Explore potential attacks on an MQTT Broker, security challenges in OT for IIoT, and discover how MQTT and HiveMQ can effectively mitigate these threats.

Blog

Hands-on Guide to Using MQTT and Eclipse Ditto for Digital Twins

Learn using HiveMQ MQTT Broker and the open-source Eclipse Ditto framework for creating and managing digital twins in IIoT using an ESP32 device.

Blog

Winning the Regulatory Compliance Game Using Industrial Digital Twins and MQTT

Learn how to address regulatory compliance challenges in industrial digital twins using MQTT and explore key best practices while implementing MQTT.

Blog
HiveMQ logo
Review HiveMQ on G2