MQTT-SN Standardization Progress

Good News! The MQTT-SN standardization is progressing nicely. That isn’t to say at warp speed, but at a steady pace in the right direction with no significant obstacles so far. Of course, someone might decide to discover one in response to this article, but it’s better to know about any now if they exist.

Looking back, I think we had two major objectives, apart from the benefit of standardization itself:

  • To take into account experiences of implementation and improve them. MQTT-SN was devised in a different era of MQTT and networks: things have moved on.
  • To align more closely with MQTT 5.0 which had been developed in the meantime. Ironically, in the odd case such as cleanstart/cleansession, this means moving back in time to pre-MQTT 3.1.1.

Simon Johnson brought the experience of ThingStream’s use of MQTT-SN in a production environment into the fray. We started with that, along with some alignment with MQTT 5.0. I thought at the beginning that I would prefer the fewest changes we could get away with, but as our discussions proceeded I realized there were more changes I would like to see adopted.

So we’ve ended up with a list of about 40 issues. Through the end of 2020 and the first few months of 2021 we proposed solutions to those and had them agreed. In the meantime, Andy Banks had updated the original source specification to the format used at OASIS and started making basic corrections.

Since then, Simon and I have updated the draft specification with the issue proposals to result in the latest working draft. At this stage, or with a few minor extra changes, we will have completed the technical updates needed to implement the new version of MQTT-SN.

Next Steps

There is still a lot of work before the specification is complete: the non-normative sections, introduction, conformance statements and formalization (RFC-izing) of the language for example. I estimate all this will take six months at least.

The immediate steps are:

  • Take the current working draft to the MQTT Technical Committee to hear any objections to our direction of travel. I don’t expect any, but I want to find out.
  • Assuming no objections, we can then embark on the process of completing the non-normative sections and rest of the updates.

In the meantime, Simon and I are planning implementations, Simon in Java, mine in Python. If anyone else wants to start implementing then that would be welcome. Having some implementation experiences is necessary for the specification to become an OASIS standard, as well as double checking our work.

I hope that later in the year, we will have a specification ready for release as a first Committee Specification Draft (CSD), along with a couple of implementations. Reaching a final standard should then be possible in 4Q this year or 1Q the next.

One Thing! – Security

I heard, through Simon, that CoAP has added functionality to deter security issues. I didn’t know what that was, but a quick search resulted in hits about DDoS attacks. From a quick read, I think that MQTT-SN isn’t vulnerable to the same type of attacks, but perhaps QoS -1 publishes (without a connection) could be used and should be thought about carefully before use. If anyone has any thoughts or more information on this topic, do speak up.

Author: Ian Craggs

I am the project lead of Eclipse Paho, a member of the Eclipse IoT working group and Eclipse IoT PMC, and co-chair of the OASIS MQTT-SN standardization Technical Sub-Committee.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.