MQTT reliability in IIoT: Choosing the right QoS

MQTT 5.0 QoS mechanisms: A detailed analysis

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for resource-constrained devices and low-bandwidth networks. One of its key features is the Quality of Service (QoS) mechanism, which defines the level of guarantee for message delivery between sender and receiver. MQTT 5.0 offers three QoS levels, allowing a balance between reliability, latency, and network resource utilization.

• QoS 0 (At most once): This level provides "fire-and-forget" message delivery, with no guarantees of delivery or order preservation. The sender sends the message and does not expect an acknowledgment, nor does it store it for retransmission. This is the fastest and least resource-intensive level.
• QoS 1 (At least once): Guarantees message delivery at least once. The sender stores a copy of the message until a PUBACK packet is received from the receiver. If PUBACK is not received within a certain time, the message will be resent. This can lead to message duplication.
• QoS 2 (Exactly once): The highest level of reliability, guaranteeing that each message is delivered exactly once without duplication. This uses a four-step handshake between the sender and receiver, involving PUBLISH, PUBREC, PUBREL, and PUBCOMP packets. This is the most secure, but also the slowest level with the highest overhead.

It is important to note that the final QoS level is determined by the lower value of the QoS set by the publisher and the QoS requested by the subscriber.

Impact of QoS on data delivery reliability in IIoT

In the Industrial Internet of Things (IIoT), where connection stability is often a challenge, the choice of QoS level directly impacts the reliability of critical data transmission.

• QoS 0: In IIoT scenarios with unstable connections or disconnections, using QoS 0 will inevitably lead to data loss. Any message sent during a connection break or device failure will be lost, as there are no acknowledgment or retransmission mechanisms. This is only suitable for non-critical, high-frequency data where the loss of individual data points is not catastrophic, such as streaming temperature readings updated every second.
• QoS 1: Provides significantly higher reliability, as messages are guaranteed to reach the broker (and subscriber) at least once. However, in the event of network failures or temporary disconnections, message duplication is possible. This requires client applications to be able to handle duplicates (e.g., using idempotent operations or message identifiers), which adds complexity at the application level. QoS 1 is a common choice for most critical data in IIoT, such as state changes or alarm signals, where duplication is acceptable.
• QoS 2: Offers the highest level of guarantee, eliminating both message loss and duplication. This is ideal for highly critical transactions where data integrity is an absolute requirement, such as financial transactions or medication dosing commands. However, the four-step packet exchange significantly increases latency and overhead on the network and devices, making it less efficient for large volumes of data or resource-constrained devices.

Architectural patterns for enhancing data transmission resilience

To ensure resilient data transmission in IIoT, especially under unstable network conditions, MQTT 5.0 QoS mechanisms should be complemented by architectural patterns such as persistent sessions and local caching.

Persistent sessions and Clean Start flags

MQTT 5.0 separated the concept of Clean Session into two distinct parameters: Clean Start and Session Expiry Interval.

• Clean Start = 0 (persistent session): Instructs the broker to attempt to resume an existing session associated with the Client ID. If a session exists, the broker restores its state, including subscriptions and unacknowledged messages (for QoS 1 and 2). This is critical for clients that may temporarily disconnect but need to receive all missed messages upon reconnection.
• Clean Start = 1 (clean session): Instructs the broker to discard any existing session and create a new one. The session is automatically destroyed when the client disconnects. This is suitable for short-lived connections or clients that do not need to receive missed messages.

The Session Expiry Interval parameter in MQTT 5.0 allows the client to specify how long the broker should retain session information after the client disconnects. This addresses the problem of indefinite session storage, which was characteristic of MQTT 3.1.1, allowing for more efficient management of broker resources. A value of 0xFFFFFFFF (or the default absence of a value) means the session never expires, while 0 means the session expires immediately upon disconnection.

Local caching (Store-and-Forward)

An additional layer of reliability, especially for edge devices with unstable internet connectivity, is local data caching using the "store-and-forward" principle. This pattern involves an edge gateway or device collecting data from sensors and automation devices, buffering it locally (e.g., on disk) when the connection to the MQTT broker is unavailable, and automatically forwarding the accumulated data when connectivity is restored. This ensures that data is not lost even during prolonged disconnections.

Message Expiry Interval

MQTT 5.0 also introduced the Message Expiry Interval, which allows the publisher to set an expiration time for messages. If a message remains on the broker longer than the specified interval (e.g., for an offline subscriber), the broker deletes it, preventing the delivery of outdated or irrelevant data after reconnection. This is particularly useful for time-sensitive data, such as SCADA readings, where outdated data can be worse than no data at all.

Choosing optimal QoS for critical IIoT data

The selection of optimal QoS levels and architectural patterns in IIoT is a compromise between reliability, latency, bandwidth utilization, and device resources.

• QoS 0: Recommended for high-frequency, non-critical data where the loss of individual messages is acceptable, and transmission speed is a priority. Examples: real-time temperature monitoring without critical thresholds, data for frequently updated dashboards.
• QoS 1: The most common choice for most critical data in IIoT. Guarantees delivery but requires applications to handle potential duplicates. Ideal for important state changes, alarm signals, and control commands where duplication is acceptable, and QoS 2 overhead is excessive. Should be used with persistent sessions (Clean Start = 0) to retain messages for offline clients.
• QoS 2: Reserved for extremely critical data where loss or duplication is absolutely unacceptable. Examples: financial transactions, security commands, pharmaceutical dosing control. Requires significant network and device resources. Also requires persistent sessions and can be complemented by Message Expiry Interval to prevent delivery of outdated data.

Combining QoS with persistent sessions (Clean Start = 0) and local caching (store-and-forward) on edge devices creates a robust architecture that withstands prolonged communication outages and ensures guaranteed data delivery. Message Expiry Interval helps manage data relevance, preventing the transmission of stale information after connection restoration.

QoS selection matrix for IIoT

The AZIOT platform supports all MQTT 5.0 QoS levels, allowing IIoT architects to flexibly configure connection and data processing parameters to ensure reliability according to the requirements of specific industrial scenarios, including the use of persistent sessions for connection resilience.

Choosing the correct MQTT 5.0 QoS level in conjunction with architectural patterns such as persistent sessions and local caching is fundamental for building resilient and reliable IIoT systems. This guarantees the delivery of critical data even in unstable network conditions, minimizing the risk of information loss and optimizing resource utilization. Understanding these mechanisms and their impact on system architecture is essential for any engineer or architect working with industrial IoT solutions.

Learn more about Intecracy and Unity Base integration solutions at Intecracy solutions and inbase.com.ua solutions.