Message Queuing Telemetry Transport - Sensor Networks (MQTT-SN) is based on the MQTT standard and makes the protocol more lightweight for use with sensor and actuator solutions. It is aimed at embedded devices using Non-IP Data Delivery (NIDD), UDP/IP or ZigBee networks.
Gateways are used as a bridge to translate between MQTT and MQTT-SN commands. An MQTT-SN gateway functionality can also be directly integrated into the broker, or be implemented as a separate entity. Clients can find these gateways automatically by using a DISCOVERY command; that is, clients do not need to be preconfigured with a gateway or broker address.
Multiple Gateways may be present at the same time within a single wireless network, for example, for load sharing or outage backup. Two possibilities exist for their implementation:
- A dedicated, E2E connections is established for each client
- Easy to implement, however amount of concurrent connections might be limited
- Only one connection is established between the gateway and broker
- More complex to implement
Figure: MQTT-SN Session Protocol & Overhead
Unlike MQTT, the Topic Name is replaced with 16-bit TopicID integers to shorten the amount of transmitted data. These TopicIDs can be preconfigured for individual clients in a known network to avoid sending REGISTER commands; this can be done either from client to broker, or vice-versa. Short Topic Names (2 characters) can be used instead.
As clients can be in sleep state to save power, gateways, in turn, buffer messages for sleeping devices.
Finally, QoS Level -1 allows simple clients to send messages directly to known gateways, even without having the initial connection set-up, registration or subscription necessary.
Due to these enhancements, several mobile network operators promote the usage of MQTT-SN for NarrowBand IoT networks.
Figure: Comparison of IoT Protcols - MQTT-SN
How is the client registration of topic done, to receive a TopicID?
1. The client sends register command to Gateway, containing a Long Topic Name.
2. The gateway sends REGACK command back as acknowledgement, containing:
- ReturnCode: Accepted, or reject reason
3. The gateway updates internal database for this client, including:
- Client ID
- Long Topic Name
How do clients discover a Gateway?
1. The gateway broadcasts the ADVERTISE command.
2. Clients searching with SEARCHGW command as broadcast with a radius measured in hops.
3. A gateway responds to the client with GWINFO command.
4. The client can then connect to the gateway.
How are clients assigned QoS Level -1?
(Preconditions: The gateway address is preconfigured in client)
The client sends a message with predefined TopicID, and does not care if either the gateway is reachable, or if message was received.
Compared to QoSLevel 0 with known gateway:
- The client does not need to send Connect command
- The gateway does not need to send an Acknowledge
- The gateway has less Client information
How is the sleep procedure managed?
1. When the client connects to a gateway, the gateway saves client state as “active."
2. In the event that a client sends a Disconnect command with a sleep duration time (a Disconnect command without sleep duration is considered as a regular client disconnect), the gateway saves the client state as “asleep.”
3. When the client wakes up to send a message, the gateway saves the client state as “awake” (If no ping is sent after sleep duration, the state is lost).
4. The gateway thereafter sends all buffered pending messages to client. The gateway sends a ping response and client goes to in the state “asleep.”