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.
Hello Sir,
Good Morning
I have been reading the updated draft. I have some concerns
1. Regarding the message types are detailed in Table 2-1. The direction of flow is conveyed from Client to gateway. But while explaining these control packets you mention communication client to server or server to client. I got lost there.
2. Another point is in some places, the draft is mentioning the gateway or server. As per my understanding, they both are separate entities, and the gateway’s main task is to convert MQTT-SN to MQTT and vice-versa.
3. In this draft we left the method of assigning clientID to the gateway, if we want to align it with MQTTv5, then why we are not letting the server generate a client and send it in CONNACK?
4. Last, section 8 “Safety, Security, and Data Protection Considerations”, should we expect more content in this section or will be a separate document for this?
Hello Hemant, sorry for the very late reply.
1. One of the remaining pieces of work we have to do is to clean up terminology. In MQTT-SN we do use the terms gateway and server interchangeably, but hey do have somewhat different meanings – an MQTT-SN gateway can be implemented as a standalone utility or as part of an MQTT broker. The term “server” encompasses all types of MQTT-SN gateway implementation. But we should be clear.
2. See 1. “Server” includes “gateway” in my mind.
3. That is the intention – maybe it wasn’t clear. It should be clear in the latest draft (https://www.oasis-open.org/apps/org/workgroup/mqtt-sn/download.php/69227/mqtt-sn-v2.0-wd11.docx)
4. We haven’t finalized this but I expect we will have some content in this placeholder section. We are also considering an implementation guide (name and form to be decided) that could contain additional information.