MQTT vs CoAP protocol

Technical help and adoption support
1

Hello all,

I’m writing to understand the criteria used by you all for deciding usage of MQTT vs CoAP. This is many a times decided by many other factors such as familiarity, available firmware stacks, IoT cloud platform support, security support and so on. Also asking because LwM2M which was until recently only CoAP based has lot’s of device management support taken care of as an open standard.

Thanks and regards, Prithvi

2

Hi Prithvi

It will be good for you to invite specific companies who are likely to benefit from this solution to hear their feedback. As a registered member, you can invite other energy access practitioners.

Thanks
Aarti

3

Hi Prithvi,

Which of the following interoperability scenarios are you focused on? There are different initiatives with different objectives for each of these currently, I believe:

  1. Device to Device interoperability. Currently, GOGLA has a connector standard discussion active on providing a standard electrical connection between devices. There is OpenPaygo Link, which provides a transport/link layer access that can run on single-wire links between between devices. And there is Nexus Channel, which runs on top of a link layer (such as OpenPaygo Link) to provide standard resource interaction between devices (it uses CoAP, as Nexus Channel is a subset of the OCF device interoperability standard, ISO/IEC 30118-1:2018, which specifies a CoAP-based interaction model between device ‘resources’. Here is an example of a Nexus Channel ‘battery’ resource, showing the optional/required parameters to expose - but the format allows for any proprietary model to be introduced or new attributes to be expanded as needed Nexus Channel Redoc Wrapper).

  2. Device to IOT Cloud interoperability. I’m not aware of significant standardization here currently, but there are a number of different ways / providers that different manufacturers are using here (some proprietary, some off-the-shelf like AWS/Google, etc). I suspect that your mention of LWM2M is primarily around this layer of interoperability (is that right)?

  3. Account Management Platform interoperability. This relates to sharing customer/loan info between different platforms, and is probably not what you’re after (let me know if thats incorrect, though!)

  4. Device Management Platform interoperability. This relates to being able to manage device state (PAYG state is often discussed, but this includes parameters like threshold settings, operational parameters, etc) via standard APIs when the ultimate connection ‘to the device’ is done from another provider/service. As an example, Angaza provides this for units that implement Nexus Keycode firmware via the Nexus API, and I believe that Solaris has developed a standard for interchanging usage data between platforms/servers as well. I want to highlight the difference between this interoperability (management ‘platforms’ sharing information/commands) and the interoperability in item #2 (an IoT cloud sending commands to a device, and receiving responses - via MQTT, CoAP, a higher layer standard like LWM2M, some custom protocol, etc). For a simple example, this item relates to a platform requesting that another platform ‘generate a keycode’ or more complex binary command for some unit, but getting that keycode to the unit would be the responsibility of a system in item #2 above (sent via SMS? LoRAWAN? How are retries handled? etc).

I can comment more on the device-to-device management, as I’m working on Nexus Channel with active integrations right now, but am probably not the best person to comment on the other scenarios.

4

@jjmilburn are you aware of any discussion where for a gateway device that anchors device-device to device-IoT Cloud, whether there has been a preference for MQTT or CoAP between the interoperability efforts thus far for any reason? I’m assuming both are easily implemented in the embedded space?

5

Hi @Vaibhav , I would suggest that there is an arguable industry preference for the device<->cloud communication to be MQTT based, if you look at the IoT offerings from major providers. These all expect MQTT (if not using HTTP, which is often a no-go for very constrained devices):

Its a different story when talking about device-to-device communications, probably because of the lack of a reliable broker (and the complexity of configuring/guaranteeing one). IoTivity and the Open Connectivity Foundation standards (what the Nexus Channel Core app layer is built upon) uses CoAP for device to device communication.

I’m assuming both are easily implemented in the embedded space?

CoAP enables use on more constrained devices than MQTT (CoAP is connectionless for starters, but MQTT using TCP also increases resource needs beyond what constrained MCUs can typically support). So I can definitely see the case for making a more powerful gateway device able to speak MQTT to the cloud (to maximize compatibility with many different providers), while using a CoAP based protocol to handle local data transfer to constrained devices. So I’d suggest that MQTT might not be as easily implemented (or practical) in deeply embedded devices with <= 32kB RAM or <= 64-128kB Flash, for instance.

6

Thanks @jjmilburn that makes sense. Guaranteeing both, stable device-cloud connections where MQTT shines, as well as having brokers seems difficult in our business situations.