Definition
QoS (Quality of Service) in protocols such as MQTT represents the message delivery quality level: QoS 0 at most once, QoS 1 at least once, QoS 2 exactly once. Device Management Platform configures QoS based on business needs, balancing reliability and performance.
QoS Levels and Selection
MQTT QoS 0 is "fire and forget," without acknowledgment or retransmission, suitable for high-frequency telemetry and other loss-tolerant scenarios; QoS 1 ensures at least once delivery through PUBACK acknowledgment, may repeat, suitable for alarms, Downstream Command downstream instructions, etc.; QoS 2 guarantees exactly once delivery through a four-step handshake, the most costly, suitable for critical control and payment instructions. Device Management Platform needs to configure according to message type: telemetry can use QoS 0, control and configuration are recommended QoS 1 or 2; also consider retry and deduplication strategies for unstable networks.
Integration with DMP
The platform supports QoS configuration in device access, rule engine, message routing, and other aspects. The effective QoS is the smaller value between the device side and the platform side; persistent sessions and Clean Session affect the retention and delivery of offline messages. In large-scale device scenarios, QoS 1/2 will increase Broker load and latency, and it is necessary to consider architectures such as MQTT clusters and message queues to achieve a balance between reliability and throughput.
Use Cases
Suitable for OTA upgrade package delivery (QoS 1), remote control commands (QoS 1), critical alarms (QoS 1), high-frequency sensor data (QoS 0), etc. Proper QoS configuration is the foundation for ensuring the reliability and efficiency of IoT communication.
What the three delivery levels actually guarantee
A quality-of-service level constrains how this one message is acknowledged. It does not mean the path never drops a message, and it does not mean the business action runs only once. Level 0 does not wait for an acknowledgement. A sample can disappear when the link jitters, which suits a periodic value that the next sample can replace. Level 1 must receive at least one acknowledgement. The sender retransmits after a timeout, so the same content can arrive more than once. Level 2 uses a multi-step handshake to separate "already delivered" from "will not be retransmitted." The extra round trips are worth it only for a critical command that the receiver cannot deduplicate on its own.
Choose the level by asking whether the receiver can recognize a duplicate. If a telemetry point carries a timestamp and a sequence number, a repeated sample can be dropped, and level 1 is usually a fair trade for reliability. A control command with no identifier becomes a second execution when it is delivered twice. That is when level 2 is worth considering, or when the application assigns a one-time identifier to each command. Raising every uplink to the highest level only multiplies handshakes. It does not repair a bad device clock or a missing idempotent design in the application.
When a persistent session and an offline backlog exist together
A level means something only when the session and the queue policy allow it. After a clean session, messages from the offline period are not retained, and the acknowledgement path of level 1 has nothing to replay. A persistent session plus a long outage then pushes the whole backlog at a device that has just come online, so upgrade packages, alarms, and ordinary samples share one connection. The workable arrangement is to queue messages that must be replayed on their own, with a cap on count and retention. Expired periodic samples are dropped. Keep only commands and alarms that still affect the current state.
High-rate telemetry does not belong in the replay queue of a persistent session. When a device returns after several hours offline, the replay is a stale curve, and it blocks the current control receipt. Split queues by topic. Sampling may drop the old and keep the new. Commands stay, by identifier, until they are acknowledged or time out. If the platform subscription level is higher than the publish level, the extra acknowledgement level is not performed by the sender. During troubleshooting, read the level that actually took effect, not the numbers each side typed into the configuration screen.
Silent downgrade when the two ends disagree
Publish and subscribe take the lower level. That is protocol behavior, not a fault. The console may set a downlink to level 1 while the device subscription is still level 0. The message then goes out at level 0 with no acknowledgement. If the screen shows only the platform setting, operations will believe the command was confirmed, while the message from before a device restart may already be lost. Before sending remote control, check the effective level negotiated when the device connected, not only the product default.
Using level 2 in place of application-level deduplication is another mistake. The handshake guarantees that this publication will not retransmit without limit. If the device loses power after it has acted and before it writes the result back, the application can still receive the same business command again. A critical action should carry a command identifier. The device records identifiers it has already executed and, on a repeat, only replays the previous result. The opposite mistake is to send alarms at level 0. On a weak network they disappear without a trace, and the platform treats "no alarm" as "healthy." An alarm should at least be acknowledgeable, or be superseded by the next status. Do not treat silence as proof that nothing happened.
When tracing a fault, record the whole life of one message: the level the publisher chose, whether the session is retained, whether it entered the offline queue, the level that took effect for the subscriber, and whether the application dropped duplicates by identifier. Leave any of those out and a protocol downgrade is misread as a device fault, or a double execution is misread as a network retransmission. Changing the default level is an access-configuration change. Watch acknowledgement counts and traffic on a few devices before widening it to the whole product. During that watch, also watch queue depth, so higher-level messages do not push lower-level samples off the link entirely. After the change, sample a few devices that go offline and come back, and confirm the backlog is not feeding expired samples into the rules in one burst.