Definition and Origin
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol based on the publish/subscribe model. It was proposed by IBM in 1999 and became an OASIS standard in 2014. Its design goal is to provide reliable message transmission for devices in low bandwidth, high latency, and unstable network environments. It has now become one of the mainstream protocols for communication between IoT devices and cloud platforms.
MQTT uses a client-server architecture, where devices act as clients connecting to a Broker (proxy server) and publish and subscribe to messages through topics. Publishers and subscribers are decoupled, not needing to know each other's existence, which facilitates scalability and maintenance.
Core Features
Technical Features
- Lightweight: The message header is only 2 bytes at minimum, suitable for constrained devices and narrowband networks.
- Publish/Subscribe: Devices and servers are decoupled, supporting one-to-many and many-to-many communication.
- QoS 0/1/2: Supports three quality levels: at most once, at least once, and exactly once.
- Based on TCP: Reliable transmission, supports TLS encryption
- Will messages: Automatically notify on abnormal disconnection, facilitating anomaly detection
- Persistent sessions: Offline messages can be temporarily stored and automatically delivered upon reconnection
QoS level description
| QoS | Semantics | Applicable scenarios |
|---|---|---|
| 0 | At most once | Sensor data, logs, tolerable to lose |
| 1 | At least once | Command issuance, status reporting, confirmation required but can be repeated |
| 2 | Exactly once | Billing, critical commands, no repetition allowed |
Topic and wildcard
MQTT topics use a hierarchical structure, such as device/12345/sensor/temperature. They support multi-level wildcards # (matching multiple levels) and single-level wildcards + (matching a single level), making it convenient to subscribe to device groups or manage in bulk.
Typical Use Cases
Smart home
Device status reporting, remote control command issuance
Connected Vehicles
T-Box data reporting, remote diagnostics, OTA upgrades
Industrial Internet of Things
PLC data acquisition, device monitoring, alarm notifications
Energy monitoring
Meter, water meter, photovoltaic inverter data reporting
Comparison with CoAP and HTTP
CoAP is based on UDP, designed for resource-constrained devices, and is suitable for request-response patterns; HTTP/HTTPS is suitable for RESTful APIs. MQTT, on the other hand, is designed for persistent connections, bidirectional communication, and message push scenarios, making it the preferred choice for real-time communication between IoT platforms and devices.
SimtoLink's IoT Cloud Platform and device management services use MQTT protocol for underlying communication. After devices connect via cellular networks (4G/NB-IoT) or WiFi, they establish a long connection with the MQTT Broker to achieve data reporting and command delivery. SimtoLink's IoT SIM cards provide stable network connections for devices, ensuring uninterrupted MQTT sessions; on the platform side, Topic permission management and QoS policy configuration are supported to meet various business requirements for reliability and real-time performance. In scenarios such as smart metering, vehicle terminals, and industrial monitoring, the combination of MQTT and cellular cards has become SimtoLink's typical solution.