As a sequel of my previous blog on MQTT, this blog will discuss in detail about the IoT messaging protocol MQTT-SN.
MQTT for Sensor Networks (MQTT-SN) is a variant of MQTT designed specifically to suit battery operated devices and constrained wireless environment with low bandwidth, high link failure and short message length. MQTT-SN is originally developed to work on top of Zigbee APS layer. It can also work on top of any un-ordered, lossy and bi-directional network protocols. As MQTT, it is also a topic based publish-subscribe messaging protocol.
Message flow in a MQTT-SN based solutions is as follows,
- MQTT-SN clients searches for a gateway in the local network using search gateway broadcast message. MQTT-SN gateway broadcasts advertise messages in the local network it is connected.
- MQTT-SN gateways should be connected to a MQTT broker before advertising or should be a MQTT broker by itself.
- MQTT-SN clients finds the gateway destination using dynamic discovery and connects to the gateway.
- MQTT-SN clients can either be a publisher or subscriber.
- Publishers registers the topics that it is going to publish with gateway to get 2 byte topic id’s which helps to reduce the message size.
- Subscribers sends subscribe messages with topic name or predefined short topic id or 2 bytes short topic name. MQTT-SN gateways uses subscription acknowledgement message or separate register message to inform IDs of topic names to subscribers.
- MQTT broker and MQTT-SN gateways controls the message flow, receives the messages from publishers and routes them to subscribers.
Figure 1 : MQTT and MQTT-SN entities
Please refer “Credits” section to know credits for image resources used.
In the above example,
- IoT devices like smart thermostat and smart lock acts as MQTT-SN clients, dynamically discovers and connects to the MQTT-SN gateway.
- Smart door lock and thermostat communicates with Home gateway using MQTT-SN to register, publish and subscribe to interested topics.
- Smart devices publishes data regarding their current status and subscribes to control messages. These devices connects to MQTT broker via MQTT-SN gateway.
- Connected home gateway acts as MQTT-SN gateway as well as MQTT client and connects to a MQTT broker. Gateway is responsible for maintaining MQTT sessions with broker and route the messages to MQTT-SN clients. It is also responsible to translate MQTT-SN messages to MQTT and vice versa.
- A smartphone application acts as a MQTT client and connects to the MQTT broker. It subscribes to current status of smart devices and publishes control messages to smart devices.
- MQTT broker runs in the cloud. MQTT broker and MQTT-SN gateway controls the message flow between control application and smart physical devices.
Types of MQTT-SN gateways
Transparent gateways are gateways that maintains separate MQTT sessions with the broker for each connected MQTT-SN client.
Aggregating gateways maintains only one MQTT session with the broker and it uses this single connection to exchange the messages from and to multiple MQTT-SN clients. Aggregating gateway is more complex to implement, but it will be useful in reducing the number of concurrent connections to a MQTT broker.
MQTT-SN forwarders can be used to encapsulate and forward MQTT-SN frames from wireless sensors to MQTT-SN gateway and vice versa. It can be used in scenarios where MQTT-SN clients cannot access the gateway directly.
Key differences between MQTT and MQTT-SN
MQTT-SN is almost similar to MQTT with the following differences,
- Works on top of un-ordered, lossy and bidirectional network protocols.
- To reduce message size, topic names are reduced to 2 bytes. Pre-defined and normal topic IDs, short topic names and register procedure are introduced to avoid UTF-8 encoded string payloads (topic names) in every publish messages.
- MQTT-SN clients can discover a gateway dynamically using ADVERTISE, SEARCHGW and GWINFO control messages.
- Supports sleeping clients. Power constrained devices can go to sleep state by disconnecting with a sleep duration. Gateway will buffer the messages that should be delivered to such sleeping clients. Sleeping clients can come online only when it needs to send or receive messages.
MQTT-SN is not standardized yet. It is a copyright of IBM published with a royalty free license.
MQTT-SN defines twenty seven type of control messages for the communication between clients and gateways such as CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT etc.
Every MQTT-SN message contains a 2 or 4 bytes message header and variable payload. Size of the smallest MQTT-SN message is 2 bytes. Largest MQTT-SN message is of size 65535 bytes. But, for MQTT-SN over UDP, it is recommended to frame MQTT-SN messages to fit in a single IP datagram to avoid fragmentation and packet loss issues.
MQTT-SN offers four type of QoS (Quality of Service) for message delivery as described below. QoS 0, 1 and 2 inherited from MQTT as it is.
- QoS 0 – At most once delivery
- QoS 1 – At least once delivery
- QoS 2 – Exactly once delivery
- QoS -1 – Simple clients
Defined for very simple clients to publish messages to a pre-known gateway without the need for connection setup and teardown. Such client does not care whether the gateway is active and whether the message is delivered.
Real world implementations
MQTT-SN is not widely adopted and it is hard to find popular implementations of MQTT-SN. There are few interesting project works on MQTT-SN and you can find one here. Eclipse Paho and Mosquitto projects provides open source implementations of MQTT-SN components.
MQTT-SN does not define any security mechanism at protocol level. For MQTT-SN over UDP, DTLS can be used for transport layer security. In addition to this, application layer security mechanisms can be used.
Where MQTT-SN fits in IoT ecosystem ?
As MQTT-SN is defined to work on top of un-ordered and lossy network protocols, it can be used as a messaging protocol between the devices and gateway connected in wireless networks or local network as stated in the examples below,
- Gateway to devices and vice versa in a local network – In an ecosystem, where multiple battery operated devices are connected to a IoT gateway in a local network, MQTT-SN can be used for messaging between IoT gateway and battery operated devices.
With most of the strengths inherited from MQTT, MQTT-SN have some additional strengths as listed below,
- MQTT-SN is specifically defined to run on low powered wireless networks and battery operated devices.
- Designed to work on top of wireless networks like Zigbee or BLE (Bluetooth Low Energy). Can work on top of un-ordered and lossy networks such as UDP/IP.
- Supports dynamic discovery of gateway.
- Explicitly supports sleeping clients.
- Avoids UTF-8 encoded string payloads to carry topic names in every publish message by using pre-defined topic IDs, short topic names and dynamic topic IDs. This reduces the size of publish messages considerably.
- Provides three level of QoS for message delivery as in MQTT. In addition, it provides QoS -1 for very simple client implementations to avoid connection setup, teardown and to publish messages to a pre-known gateway without worrying about the current status of gateway and message delivery.
- MQTT-SN over UDP is not a best fit for IoT solutions which requires ordered delivery of messages. If MQTT-SN over UDP is used in such cases, explicit mechanisms and message contracts should be defined to maintain the ordered delivery of messages.
- In MQTT-SN over UDP, message size should be relatively small to avoid IP fragmentation and packet loss issues.
- No security mechanism defined at messaging protocol level.
- Cannot subscribe to multiple topics (without specifying a wildcard) in one SUBSCRIBE message.
Entire content of this series of blogs is available here.
- MQTT-SN v1.2 specification by Andy Stanford-Clark and Hong Linh Truong, IBM,
14 Nov 2013.
- Aquila 2.0 – MQTT-SN based IoT Platform, Hackday.io project, Rodmg, 9 Oct 2016.
Resources used in “Figure 1” are downloaded from web as follows,
- Smart thermostat image is downloaded from “https://dominickcomfort.com/heating-cooling/equipment/accessories/thermostats/”
- WiFi access point or router image is downloaded from “https://www.netgear.com/home/products/networking/wifi-range-extenders/EX6200.aspx?cid=wmt_netgear_organic”
- Cloud image is downloaded from “http://www.iconarchive.com/show/long-shadow-media-icons-by-pelfusion/Cloud-icon.html”
- Cloud server image is downloaded from “http://www.pngall.com/cloud-server-png”
- Smartphone in hand image is downloaded from “http://www.freepngimg.com/png/298-smartphone-in-hand-png-image”
- WiFi logo and waves are downloaded from the links,
- Smart lock image is downloaded from “http://www.kwikset.com/”.
- Home gateway image is downloaded from http://online.vividwireless.com.au/wireless-broadband-modems/home-gateway