I recently came across the MQTT-SN (Message Queuing Telemetry Transport for Sensor Networks) protocol while working on a project and thought I’d give a quick overview on it and how it differs from MQTT and CoAp (Constrained Application Protocol).

Similar to how CoAp is a UDP (User Datagram Protocol) implementation based on the HTTP protocol, MQTT-SN is based on MQTT but uses UDP or another connectionless protocol like zigbee instead of TCP. CoAp and MQTT-SN are ideal for low power and lossy networks (LLN) with constrained devices like battery powered devices and mesh networks because they reduce the energy consumption of client applications to maintain a connection.

MQTT-SN allows Itron to have another Industrial IoT tool in our toolbox. If CoAp is a Phillips screwdriver then MQTT-SN would be a flat head. At Itron Idea Labs we often connect third party sensors/devices to quickly prove a business case so it can be handy to have more available options. Once a business case is proven, it is then passed on to a product team for further refinement.

A perfect example of an IoT device that needs low power consumption could be the sensors down in the sewer vaults. Itron's partner, Utility Systems Science & Software (US3) installs these low power sensors (In US3’s case they are CoAp based) to detect rising sewer levels and prevent leaks. Occasional truck rollouts to replace device batteries would be too expensive so in order to be competitive, the battery life must last the lifetime of the devices which can be 10+ years in the field.

Although MQTT-SN is not a new protocol by any means, it is scheduled to get an updated standard spec soon (mid 2021) by the technical committee OASIS MQTT TC.  The updated standard will align with the MQTT 5.0 standard and is important in guiding development and growing community use. I’d also expect it to gain more traction due to the increasing number of IoT devices/sensors and popularity of MQTT amongst developers. According to statistics website statista.com, the number of IoT devices worldwide is expected to increase by 3.08 billion in the next two years.

Another facet that developers are looking to be defined in the upcoming standard is security. The current MQTT-SN standard does not specify security so it is up to the user to implement security on their own, like DTLS (Datagram Transport Layer Security) security for example.

As it stands today, MQTT-SN solutions are reliant on having a gateway due to the nature of the internet being based on reliable TCP connections. The gateway translates the incoming MQTT-SN messages from the device side into MQTT over TCP for cloud side ingestion. While using gateways does allow us to ingest data with common MQTT brokers like Azure IoT Hub or AWS IoT Core services, they do have their own drawbacks. For instance, if using DTLS security data packets are only encrypted till the next gateway. The data would have to be encrypted by the device, sent to the gateway where it is unencrypted, translated and then encrypted again to send to the MQTT broker. This makes the data only as secure as your network hosting the gateway. So there are some current limitations until either the internet has more direct UDP support or MQTT-SN gets a defined E2EE (End-to-end encryption) solution like OSCORE (Object Security for Constrained RESTful Environments), for CoAp where only the payload is encrypted and can only be decrypted by a pre-authorized end-point.

Switching gears from some of the limitations, let's look at the existing two gateway architectures and messaging details that give MQTT-SN some unique advantages over MQTT.

1. Transparent gateways allow for more manageability with each device represented separately to the MQTT broker. 

2. Aggregating gateways have higher efficiency with just one gateway/broker connection but at the cost of manageability.

Here are some architecture diagrams illustrating this from IBM’s MQTT-SN protocol specification whitepaper.

The connect message has two additional and optional parts compared to MQTT that tell the server the client’s ‘Will’ topic and message. A Will is a message that is sent by the server in the event that the client disconnects unexpectedly.

Like MQTT, messages are sent/received using a form of addressing topics. Below are all the ways to publish and subscribe to topics using MQTT-SN.

Topic subscribe methods:

1. Long topic (full topic name)
2. Short name topic (two bytes long)
3. Pre-defined topic ID (integer agreed upon beforehand by gateway and clients)

Topic publish methods:

1. Topic ID (integer obtained by subscribing to long name, registering long name, or pre-defined)
2. Short name topic (two bytes long)

In addition to the usual QOS (Quality of Service) 0,1 and 2 supported in MQTT, MQTT-SN supports QOS -1. QOS -1 is a connectionless means to publish using pre-defined or short name publishing formats. This is ideal for very simple sensor devices since there is no connection setup/teardown or PUBACK (publish acknowledges from recipient). Due to the nature of mesh networks, the QOS options that send acknowledgments back over the mesh can be problematic and might not be supported by the network. A mesh is composed of many small and often constrained devices like battery powered water meters and having packets go back and forth over several hops(devices) can be network intensive. This was in part the reason why UDP solutions are favored over TLS solutions for mesh environments. UDP still ensures packet integrity via checksums, it just does not keep track of the message state.

MQTT-SN also supports a sleep mode for the client that helps preserve power by entering a low power state with the device’s transceiver powered off. Depending on the device application the device can sleep for a scheduled interval or an event like updated sensor data before powering on the transceiver again to publish messages or receive commands from the cloud. A device goes to sleep by sending a DISCONNECT message to the gateway/broker with the amount of time it will be in the ‘asleep’ state. So, to walk through our previous example of a sewer level detector: a device sends a batch of sewer level data, goes to sleep for say 6 hours storing up all the data its sampling while the transceivers is off, the device then wakes up and sends all its updated reads. If at any time the sewer level exceeds a set threshold the device can wake before the scheduled time to send an alert back to the server.

To wrap things up, MQTT-SN is another great tool for industrial IoT. There are a few limitations to keep in mind when developing but it does open up a larger device pool to cut down on development time and cost when building MVP’s to test business cases. If you are interested in learning more about MQTT or want to set up your very own MQTT-SN client/gateway, here are some helpful links to get you started.

• MQTT For Sensor Networks (MQTT-SN) Protocol Specification
• Eclipse Paho MQTT-SN C/C++ client for Embedded platforms