Definition
MQTT (Message Queuing Telemetry Transport) is a lightweight IoT messaging protocol based on the publish/subscribe model, suitable for low-bandwidth, high-latency networks. The platform natively supports MQTT 3.1.1 and MQTT 5.0, with features such as QoS, Retained Message, and Last Will.
Core Features
- Lightweight: Low protocol overhead, suitable for narrowband scenarios such as NB-IoT and 2G
- Publish/Subscribe: Message routing based on Topics
- QoS: Supports 0/1/2 levels of message quality assurance
Applications in device access
MQTT is the core protocol of the Device Management Platform Device Access access layer. Devices report Telemetry data via Topics, receive Downstream Command commands, subscribe to OTA notifications, etc. The platform usually specifies Topic conventions (such as /product/{productKey}/device/{deviceId}/property/post), supports QoS to ensure reliable delivery of critical messages, and Last Will is used to detect abnormal device disconnections.
Security and Extensibility
In production environments, TLS encryption must be enabled, supporting mTLS mutual authentication or X.509 Certificate certificate authentication. MQTT 5.0 introduces features like shared subscriptions, request/response, and user properties, suitable for large-scale, multi-tenant scenarios. It coexists with protocols such as LwM2M and CoAP to meet the access needs of different device types.
What a topic subscription does in the access layer
In device access, MQTT is a publish-and-subscribe channel based on topics. After the device opens a session with the broker, it publishes measurements or events to agreed topics, and it subscribes to its own downstream topic to receive commands, desired properties, and upgrade notices. The broker forwards a message to whoever is subscribed to that topic. It does not interpret what a measurement means to the business. Topics therefore need a stable hierarchy that separates product, device, direction, and data type, rather than one shared topic with everything distinguished only in the body. The quality-of-service level decides whether the broker and the device must acknowledge, and whether duplicates must be prevented. The higher the level, the more handshakes, and a narrowband link should not spend that on high-frequency samples. A retained message lets a subscriber that comes online later receive the last one immediately. That fits a "current desired value." It does not fit every historical alarm. A last will is published by the broker on an abnormal disconnect, to say "this device did not leave cleanly." It cannot be the only source of a business alarm. Whether the session keeps subscriptions after a disconnect decides whether the device must subscribe again when it reconnects. How a thing model property corresponds to a topic should be written into the access agreement, not scattered through each side's code.
Which messages belong on this channel
What fits is small, frequent state, an occasional command, and a short progress notice. A large file, a firmware body, and a long log should not be forced into one message. They should use a dedicated download or a sequence of chunks, and this channel should carry only the address and the progress. A critical command should at least be confirmable on arrival, and it should carry a command identifier at the application layer so duplicates can be dropped. Only samples that should leave quickly, and may be lost, use the lowest level. Device identity has to be established when the connection is made. It cannot rest on a device name the client writes into the topic and claims for itself. A shared subscription fits several processing instances on the platform side sharing the uplink. It does not fit several devices sharing one lossy subscription group to receive commands. Last will, retain, and clean session need a default written per product. Used together with a device shadow, the desired value pushed from the shadow and the actual value reported by the device should use different topics, so a handler does not write the desired value back as the actual one.
Quality of service and session switches used the wrong way
Putting a control command on the lowest quality of service loses the command when the network jitters, while the platform still shows it as sent. Putting a sample that fires every second on the highest level fills a narrowband link with acknowledgements, and the samples themselves pile up. A repeated client identifier lets the device that comes online later kick the previous one off, and both look unstable. A clean session that drops subscriptions on every disconnect means downstream messages keep going to a topic with no receiver, if the device does not subscribe again after reconnecting. An old reboot command left in a retained message runs as soon as a new device subscribes. A last-will topic that is the same as the normal alarm topic makes a disconnect published by the broker look like a sensor fault to the business system. Topic permission that limits writes and not reads lets any client that holds a connection subscribe to someone else's uplink. In a reconnect storm every device opens a session at once, the broker overloads, and that triggers still more reconnects. Using the topic hierarchy in place of authorization, and assuming that a device name in the topic means only that device can publish, lets a forged topic impersonate it.