MQTT QoS: Understanding The 3 Levels Of Service

MQTT QoS levels ensure IoT message delivery reliability, a crucial mechanism for developers to manage data integrity across diverse network conditions, as explained by dev-station.tech. This system provides a structured approach to balance message guarantee with performance overhead, offering a clear path to building robust IoT applications.

Message guarantee, delivery confirmation, and network performance.

What Are The Three MQTT QoS Levels?

The three MQTT Quality of Service (QoS) levels are QoS 0 (At most once), QoS 1 (At least once), and QoS 2 (Exactly once). They define the guarantee of message delivery between an MQTT client and broker, allowing developers to balance reliability with performance.

In the world of the Internet of Things, devices often communicate over unreliable networks. A sensor in a remote field might face intermittent cellular service, or a smart home device could be on a congested Wi-Fi network. The MQTT protocol was designed specifically for these challenging environments. At its core is the Quality of Service, or QoS, feature—a powerful agreement between sender and receiver that dictates the level of effort and confirmation required for a successful message transfer.

This is not just a technical setting; it is a fundamental choice that impacts your application’s reliability, latency, and resource consumption. Choosing the correct service level is one of the most critical architectural decisions an IoT developer can make. Dev Station Technology understands that this choice depends entirely on the use case. Is it a non-critical temperature reading that can be missed, or is it a critical command to shut down a piece of industrial machinery? Each scenario demands a different level of delivery guarantee.

How Does QoS 0 (At Most Once) Work?

QoS 0 operates on a fire-and-forget principle. The sender transmits the message a single time without requiring any acknowledgment from the receiver. It is the fastest level but provides no guarantee of delivery.

Often referred to as fire-and-forget, QoS 0 is the most basic delivery mode in MQTT. When a client publishes a message with QoS 0, it sends the TCP/IP packet and moves on. It does not wait for a confirmation, and it does not re-send the message if it gets lost.

• Mechanism: The client sends a single PUBLISH packet to the broker. The process ends there from the sender’s perspective.
• Overhead: This level has the lowest network and processing overhead. It uses the least bandwidth and requires the least CPU power and battery life, making it ideal for severely constrained devices.
• Use Cases: QoS 0 is suitable for non-critical telemetry data where some data loss is acceptable. For example, if a sensor reports ambient temperature every second, losing a single reading is unlikely to impact the overall system. The next reading a second later will provide an updated value.

How Does QoS 1 (At Least Once) Work?

QoS 1 guarantees that a message will be delivered at least one time. The sender continues to re-transmit the message until it receives a PUBACK (Publish Acknowledgment) packet from the receiver, which may result in duplicate messages.

This level introduces a crucial element: acknowledgment. With QoS 1, the sender is assured that the message has reached its destination. This provides a significant step up in reliable messaging and is the most commonly used level in IoT applications.

The message flow involves a two-step handshake:

1. Client to Broker: The publishing client sends a PUBLISH packet with a unique Packet Identifier. It then stores the message locally until it is acknowledged.
2. Broker to Client: Upon receiving the PUBLISH packet, the broker sends back a PUBACK packet containing the same Packet Identifier. Once the client receives the PUBACK, it can safely discard the stored message.

A key consideration for QoS 1 is the possibility of duplicate messages. If the sender transmits the PUBLISH packet but does not receive the PUBACK due to a network interruption, it will re-send the same message. The receiver might get the message twice but may have been unable to send the acknowledgment for the first one. Therefore, applications using QoS 1 must be designed to handle potential duplicates gracefully (i.e., be idempotent).

Use Cases: QoS 1 is perfect for scenarios where a message must be delivered, but a duplicate message would not cause harm. This includes commands that are idempotent (e.g., set light to ON), critical alerts, or notifications that trigger an action.

How Does QoS 2 (Exactly Once) Work?

QoS 2 provides the highest level of reliability, ensuring a message is delivered exactly one time by using a four-part handshake. This process eliminates the possibility of duplicates but introduces the most network and processing overhead.

For the most critical applications where data loss and duplication are unacceptable, QoS 2 offers the ultimate guarantee. This level is essential for systems like financial transactions or critical infrastructure controls, where a duplicate message could have serious consequences.

The exactly-once delivery is achieved through a more complex four-part handshake:

1. PUBLISH: The sender sends a PUBLISH packet (with Packet ID) and stores it.
2. PUBREC (Publish Received): The receiver gets the PUBLISH packet, stores the Packet ID, and responds with a PUBREC packet.
3. PUBREL (Publish Release): Upon receiving PUBREC, the sender discards the initial message and sends a PUBREL packet. This signals that it has completed its part of the transaction.
4. PUBCOMP (Publish Complete): The receiver gets the PUBREL packet, discards the stored Packet ID, and responds with a PUBCOMP packet. Only when the sender receives the PUBCOMP can it be certain the transaction is fully complete.

This robust handshake ensures that both parties have a confirmed state of the message transfer, which prevents both loss and duplication. However, this guarantee comes at the cost of increased latency and resource usage.

Use Cases: QoS 2 is reserved for mission-critical systems. Examples include processing a payment, dispensing a precise amount of medication, or controlling a robotic arm where a repeated command would be catastrophic.

How Do You Choose The Right MQTT QoS Level?

Choosing the right MQTT QoS level requires balancing your application’s need for reliability against the costs of network bandwidth, CPU processing, and battery consumption. You must analyze the criticality of your data and the capabilities of your IoT devices.

The decision is a trade-off. There is no single best QoS level; there is only the best level for your specific application. A 2021 study by the Eclipse Foundation on IoT developer trends found that reliability remains a top concern for developers, highlighting the importance of making an informed QoS choice. At Dev Station Technology, we advise clients to consider the following factors:

• Data Criticality: What is the business impact if a message is lost? If the impact is high, QoS 0 is not an option. What is the impact if a message is duplicated? If a duplicate would cause a system failure, QoS 2 is necessary.
• Device Constraints: Is your device powered by a small battery? If so, the high power consumption of QoS 2’s four-part handshake might be prohibitive. The minimal overhead of QoS 0 would be beneficial.
• Network Conditions: In a highly stable and reliable network, the risks of using QoS 0 are lower. In a cellular network with frequent dropouts, the re-transmission mechanisms of QoS 1 and QoS 2 become vital for ensuring proper IoT connectivity.

How Can You Implement MQTT QoS In Your Code?

You can implement MQTT QoS by setting the `qos` parameter in the publish function of your MQTT client library. This is typically an integer value of 0, 1, or 2 that tells the client and broker which delivery guarantee to use for that specific message.

Implementing QoS is straightforward in most MQTT client libraries. Let’s look at an example using the popular Paho MQTT client for Python. The `publish()` function includes a parameter specifically for setting the QoS level.

Here is a step-by-step guide to publishing messages with different QoS levels.

1. Install the Library: First, ensure you have the Paho MQTT library installed.

   pip install paho-mqtt

2. Create the Publisher Script: In your Python script, you will import the client, connect to a message broker, and then publish. The key is the `qos` argument in the `client.publish` call.

   import paho.mqtt.client as mqtt
   import time
   
   # --- Connection Details ---
   BROKER_ADDRESS = "mqtt.eclipseprojects.io" # Public test broker
   CLIENT_ID = "qos_example_publisher"
   PORT = 1883
   
   # --- Topics ---
   TEMPERATURE_TOPIC = "iot/sensor/temperature"
   COMMAND_TOPIC = "iot/device/command"
   PAYMENT_TOPIC = "iot/system/payment"
   
   def on_connect(client, userdata, flags, rc):
       if rc == 0:
           print("Successfully connected to broker")
       else:
           print(f"Failed to connect, return code {rc}\n")
   
   # --- Create and Connect Client ---
   client = mqtt.Client(CLIENT_ID)
   client.on_connect = on_connect
   client.connect(BROKER_ADDRESS, PORT)
   client.loop_start()
   
   # --- Publish Messages with Different QoS Levels ---
   try:
       # QoS 0: Non-critical, frequent data
       client.publish(TEMPERATURE_TOPIC, payload="23.5", qos=0)
       print(f"Published to {TEMPERATURE_TOPIC} with QoS 0")
       time.sleep(1)
   
       # QoS 1: Important command that should not be missed
       client.publish(COMMAND_TOPIC, payload="TURN_ON", qos=1)
       print(f"Published to {COMMAND_TOPIC} with QoS 1")
       time.sleep(1)
   
       # QoS 2: Critical transaction that must happen exactly once
       client.publish(PAYMENT_TOPIC, payload="TXN_12345", qos=2)
       print(f"Published to {PAYMENT_TOPIC} with QoS 2")
       time.sleep(2) # Give time for the handshake to complete
   
   except KeyboardInterrupt:
       print("Publication stopped")
   
   finally:
       client.loop_stop()
       client.disconnect()

In this example, three different messages are sent, each to a different topic and with a QoS level appropriate for its imagined use case. The logic for the underlying handshakes is handled automatically by the Paho library, simplifying the developer’s task to just choosing the number 0, 1, or 2.

How Can MQTT QoS Help Troubleshoot Lost Messages?

If your IoT system is experiencing lost messages, the primary troubleshooting step is to increase the QoS level from 0 to 1. This introduces message acknowledgments, which immediately provides a delivery guarantee and helps confirm that the message is successfully reaching the broker.

When an IoT system is not behaving as expected and you suspect messages are being lost in the publish/subscribe flow, MQTT QoS is your most powerful diagnostic tool. Starting with QoS 0 provides no insight into message delivery; a packet is sent, and you can only hope it arrives.

By systematically increasing the QoS level, you can pinpoint the source of the issue:

• Upgrading to QoS 1: If switching from QoS 0 to QoS 1 resolves the issue of lost messages, it confirms the problem was packet loss between the client and the broker. The network was unreliable, and the fire-and-forget nature of QoS 0 was insufficient. The guaranteed delivery of QoS 1 overcomes this.
• Observing QoS 1 Duplicates: If, after moving to QoS 1, you begin to see duplicate commands or alerts, it indicates that your network is dropping the acknowledgment (PUBACK) packets from the broker back to the client. The client, not receiving the acknowledgment, re-sends the message, causing the duplication. This tells you that your receiving application must be made idempotent.
• Implementing QoS 2: If even duplicates are causing critical failures, moving to QoS 2 is the final step. Its four-part handshake is designed to solve these edge cases, ensuring a message is processed exactly once by the broker. If issues persist even with QoS 2, the problem likely lies outside of the MQTT delivery mechanism, perhaps in the broker’s configuration or the subscribing client’s logic.

What Is The Performance Overhead of Each QoS Level?

The performance overhead increases significantly with each QoS level. QoS 1 has roughly double the network traffic of QoS 0 because of its acknowledgment packet. QoS 2 has approximately four times the traffic of QoS 0 due to its four-part handshake.

Understanding the specific network traffic and latency costs associated with each QoS level is essential for designing efficient IoT systems. The overhead is not just theoretical; it translates directly into higher data plan costs, shorter battery life, and slower response times.

Here is a computational breakdown of the message flow and relative overhead:

This calculation shows that moving from QoS 0 to QoS 2 results in a 300% increase in network packets for a single message transaction. For a battery-powered device sending hundreds of messages per day, this difference is substantial and will dramatically affect device longevity in the field.

What Are The Next Steps for Your IoT Project?

The next steps are to analyze your specific use case, select the appropriate QoS level for each message type in your system, and implement it in your application. For expert guidance on architecting a reliable and efficient IoT solution, consider partnering with a specialist.

Mastering MQTT QoS is a key step toward becoming a proficient IoT architect. By understanding the guarantees and trade-offs of each level, you can design systems that are both reliable and efficient, tailored perfectly to their real-world environments.

If you are planning an IoT project and need help designing a robust messaging architecture, the experts at Dev Station Technology are here to help. We can guide you through the complexities of protocol selection, security implementation, and platform development to ensure your project is a success.

To learn more about how we can help you build the next generation of connected devices, please explore our services at dev-station.tech or contact our team directly at sale@dev-station.tech for a consultation.