MQTT Quality-of-Service (QoS): Use-Cases and Examples

MQTT plays a central role in the modern manufacturing industry, especially in the context of the Unified Namespace (UNS). This architecture enables seamless and scalable communication between different machines, systems and applications. As a lightweight and efficient protocol, MQTT is ideal for use in industrial environments as it enables reliable data transmission. Thereby, MQTT Quality-of-Service (QoS) plays a major role in the reliability of data transmission. This article describes the different QoS levels and their importance for secure and efficient message transmission in MQTT. The article also shows best practices for use in the Unified Namespace (UNS) architecture. Further information on the Unified Namespace (UNS) can be found here.

What is MQTT Quality-of-Service (QoS)?

The term Quality-of-Service (QoS) describes the reliability of message transmission in the MQTT protocol. This reliability refers to the connection between two actors – either from the publisher to the broker or from the broker to the subscriber. The different QoS levels offer certain guarantees for the successful delivery of messages.

What are QoS Levels?

To understand the QoS level for message transmission using MQTT, it helps to first take a closer look at the transmission mechanism of MQTT. In general, the transmission takes place in two steps. First, the publisher sends a message to the broker. The broker then forwards this message to all subscribers.

In theory, the message can be lost at two points during transmission: “Publisher to Broker” and “Broker to Subscriber”. Therefore, both the publisher and the subscriber can each define an MQTT QoS level. If the QoS levels of the publisher and subscriber are different, the broker always forwards the message with the QoS level specified by the subscriber. This means that a message can be transmitted to the subscriber by the broker with a lower QoS level despite a higher QoS level from the publisher.

Which QoS Levels are Available?

MQTT provides the following three quality-of-service levels:

• QoS 0: Message is received at most once (fire-and-forget),
• QoS 1: Message is received at least once and
• QoS 2: Message is received exactly once.

Which QoS Level Makes Sense in the Unified Namespace (UNS)?

The above definition can be used to summarize the effects on message transmission in the table. Here it becomes clear that only MQTT QoS Level 2 guarantees unique and one-time delivery. Nevertheless, QoS levels 0 and 1 should also be considered in the context of the UNS. This is because when selecting the QoS level, it is not only reliability that is decisive, but also the load on the broker as well as the latency of data transmission. It is important to find the optimum balance between reliability and system load for each topic. A detailed recommendation can be found in the following section.

MQTT Quality-of-Service (QoS) Level 0

MQTT QoS Level 0 only ensures that the message is sent once, but reception is not guaranteed. In this case, the sender does not wait for an acknowledgement. This method, also known as “fire and forget”, should be used as the default setting as it causes the lowest load on the broker.

How it works: The publisher sends the message to the broker and discards it immediately as it does not wait for an acknowledgement.

Example: This level is suitable for the delivery of high-frequency messages. This could be telemetry data from a sensor that transmits process parameters such as temperature or vibrations every 100ms. The sensor updates the data continuously and at a high frequency. The loss of individual messages is therefore not critical for use-cases such as condition monitoring.

MQTT Quality-of-Service (QoS) Level 1

MQTT QoS Level 1 ensures that the message is received once. To do this, the publisher sends the message until it receives an acknowledgement from the subscriber. This method is somewhat more complex than QoS level 0, as the message has to be sent and saved again until it is received.

How it works: Message transmission in MQTT QoS Level 1 takes place in two steps. First, the publisher sends the message to the broker. The broker responds with an acknowledgement (PUBACK). If the PUBACK does not reach the publisher, it sends the message again until it receives a PUBACK packet. This ensures that the message still arrives at the broker in the event of a (temporary) connection failure. The complexity of this method offers a good compromise between reliability and effectiveness. However, the publisher can also send the message twice at this QoS level. This can lead to the broker receiving the same message twice in the event of a connection failure during the acknowledgment (PUBACK) and therefore forwarding it several times.

Example: A typical use-case for QoS level 1 is an alarm. For example, a sensor can send the open status of a light barrier to a central alarm point using QoS level 1. Repeated transmission until acknowledgement ensures that the safety-critical message is received by the broker and the necessary steps can be initiated (e.g., Dashboard visualization). At the same time, possible multiple delivery is unproblematic in this scenario.

MQTT Quality-of-Service (QoS) Level 2

MQTT QoS Level 2 ensures that the message is delivered exactly once. It therefore offers the highest reliability, but at the expense of a higher load for the broker and client, which leads to slower execution.

How it works: A message sent with MQTT QoS Level 2 follows these four steps:

1. Publish: The publisher sends the message to the broker.
2. PUBREC (Acknowledge): The broker confirms receipt of the message with a PUBREC packet. Similar to QoS level 1, this ensures that reception is guaranteed. If the publisher does not receive a PUBREC, it sends the message again.
3. PUBCOMP: The broker recognizes through the PUBREL packet that the publisher will not resend the message. It deletes the message and the packet ID and confirms this with a PUBCOMP packet. As soon as the publisher receives the PUBCOMP, they can also remove the packet ID. This ID is now available for new messages.
4. PUBREL: After receiving the PUBREC, the publisher responds with a PUBREL packet and removes the message from its memory, but retains the packet ID to prevent duplicate sending.

Both the sender and the recipient have a queue (similar to a backlog list). This queue stores all messages that have not yet been confirmed in order to avoid duplicates. This guarantees the delivery of all messages even if the connection is (temporarily) interrupted.

Example: For business-critical messages, transmission with MQTT QoS level 2 is recommended. A typical use case is triggering an order process when the fill level is low. In this scenario, the order must be placed exactly once. The higher load for the broker and client is acceptable here, as the message is only sent infrequently.

Best Practices for a Unified Namespace (UNS)

In the context of a UNS architecture, selecting the right MQTT Quality of Service (QoS) level is crucial. The importance of the message must be weighed up against the greater burden of higher QoS levels for brokers and clients. Users should take into account the consequences of a message not being received or being received twice, the transmission frequency, the number of subscribers and state management (e.g. for offline clients). Publishers and subscribers should always use the same QoS level. Different levels will otherwise lead to automatic adjustment to the lower level, which can impair reliability. Three typical QoS scenarios in the context of the Industrial Unified Namespace (UNS) are described below.

Scenario: MQTT QoS Level 0

Users should use MQTT QoS Level 0 if:

• The connection between the transmitter and receiver is very reliable.
• The loss of messages is manageable or the frequency of the data is very high.
• Example: High-frequency telemetry data from machines and sensors. The loss of a message does not affect the use-case.

Scenario: MQTT QoS Level 1

Users should use MQTT QoS Level 1 if:

• Delivery of messages is critical and duplicates acceptable.
• Many publishers and/or subscribers, MQTT QoS Level 2 is not feasible, as the messages would otherwise overload the broker.
• Example: Business data that only represents a status. The repeated receipt of the status does not affect the use-case, as is the case with a status display in a dashboard.

Scenario: MQTT QoS Level 2

Users should use MQTT QoS Level 2 if:

• The handling of duplicates is crucial for the use-case.
• Example: business-critical data for important transactions, such as a one-off order trigger due to a fill level falling below a certain level.

Conclusion

QoS levels offer three delivery guarantees: maximum once, minimum once and exactly once. The MQTT QoS level should be selected specifically for each topic depending on the respective use case. Not only the importance of the data but also the transmission frequency, the load of the broker and the risk of failure play a role. A good standard is MQTT QoS level 1. In the i-flow UNS reference architecture, MQTT QoS level 0 is recommended for non-critical use cases. In addition to the QoS levels, there are further options for message transmission with MQTT. For more information, please read our articles on MQTT Retained Messages in our resources.