As a sequel of my previous blog on MQTT, this blog will discuss in detail about the IoT messaging protocol MQTT-SN.

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.

Operational behaviour

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.

Following figure illustrates MQTT-SN and MQTT entities in an example of home automation,

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 Forwarder
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.

Standardization

MQTT-SN is not standardized yet. It is a copyright of IBM published with a royalty free license.

Message format

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.

Message delivery

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.

Security

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.

Strengths

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.

Weakness

  • 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.

Follow-up links

CoAP : https://blog.imaginea.com/internet-of-things-messaging-protocols-part-3

Entire content of this series of blogs is available here.

References

  • 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.

Credits

Resources used in “Figure 1” are downloaded from web as follows,