Critical Decisions for IoT Device Management Customers: Choosing Between Open Standards (MQTT or LwM2M).

The choice between employing a new standard (often LwM2M) or an older standard (MQTT) is difficult due to complexities of migrating to the new standard because of device management service suppliers (who may not use LwM2M) and due to legacy hardware systems deployed in the field (which may not support new protocols like LwM2M). Presently, multiple vendors (such as gateway manufacturers and platform suppliers alike) are adopting LwM2M. However, other industry players including the cloud hyper-scalers (such as Amazon Web Services, Microsoft Azure, and IBM Watson) are continuing their support of MQTT—believing that this protocol will continue to be a valuable commercial proposition for existing and legacy IoT systems. Also, the hyper-scalers could be following a different business strategy, in that they would rather invest in value-added services such as Machine Learning (ML) inferences (predictive analytics) both at the edge and for the cloud where they can differentiate their products (and the cloud is where they have historically excelled). By contrast, standardization of device management services may result in commoditization, thus the LwM2M standard leads to relatively undifferentiated products so the entrance of more module and gateway vendors into device management may just saturate the market. Also, the impact of cloud hyper-scalers sticking with MQTT suggests future dominance by LwM2M is not guaranteed—especially in existing and legacy ‘brownfield’ deployments where MQTT is already present.

MQTT (a TCP-based protocol) is an open standard which defines protocol translation and sends data packets across the network. MQTT was introduced in 1999, as a network protocol in order to exchange messages between devices—typically client and server nodes. What made MQTT innovative was its ability to serve resource-constrained and low-compute devices with a small footprint publish-subscribe (pub/sub) model. This made MQTT far more energy efficient for small footprint devices than its more famous TCP-based counterpart, the HTTP/S protocol.

LwM2M defines protocol translation as an open standard, just like MQTT. Unlike MQTT, LwM2M (a UDP-based protocol) also defines device management services as an open standard, whereas MQTT lacked clearly defined standards for device management services (even for core services such as OTA updates and device monitoring). As such, vendors for device management services built their own (usually proprietary) source code on top of MQTT protocols. In contrast, an open-source approach is demonstrated by many vendors, including Sierra Wireless and AVSystem, opting for LwM2M based standards which define device management services. Consequently, picking a device management provider created potential for vendor lock-in as one supplier’s proprietary software could not be easily switched with another supplier—even for core tasks such as upgrading firmware. On the other hand, LwM2M’s major impact was avoiding vendor lock-in for device management services as it creates an open standard for device onboarding, provisioning, and OTA updates, as well as decommissioning.

In 2020, the Eclipse Foundation (a non-profit, which manages projects including MQTT) launched SparkPlug, a new specification for MQTT, designed to plug deficiencies. Prior to SparkPlug, MQTT-based device management services had low interoperability compared to LwM2M. However, it remains to be seen if the new SparkPlug specification receives widespread adoption in the industry, especially whether SparkPlug addressing some of the shortcomings of MQTT, leads to a slowdown in the adoption of LwM2M. Another unknown is whether existing device management vendors will update their proprietary device management services relative to the open standards of SparkPlug, which introduces some interoperability and reduces the vendor lock-in.

As the number of IoT connections is expected to rise significantly by 2026, a decision to stick with MQTT may prove costly for the hyper-scalers. They may not be able to exploit the growth of higher revenues in the device management market segment if their share is declining due to a protocol translator, which has a larger presence in legacy deployments than greenfield deployments. For example, by March 2021, AVSystem had been able to integrate LwM2M-based device management services into both Azure IoT Hub and AWS IoT Core. Prior to this integration, the lack of Azure and AWS native support for LwM2M shows that customers faced significant challenges integrating new standardized protocols (LwM2M) with their pre-existing cloud stack. However, as cloud hyper-scalers are well aware, MQTT retains a strong developer community given its 20-year heritage; this community can be leveraged by customers to implement MQTT protocols in their IoT deployments. As a result of cloud hyper-scalers and gateway manufacturers pulling in different directions, the jury is still out on whether MQTT will succeed or fail in greenfield deployments.

Gateway and platform vendors benefit by leveraging the developer community for code maintenance, vulnerability identification, and feature development. This can be leveraged by those customers who are seeking to build a la carte solutions with a choice of an assortment of different vendors from edge to cloud, ranging from base-level subsystem modules to high-level analytics. If opting for LwM2M, vendor lock-in can be avoided, because enterprise customers and Industrial IoT (IIoT) customers can choose their device management service provider a la carte. Should a la carte options prove viable then market fragmentation is likely to result because customers with flexibility to choose their own device management vendors have a broader array of vendors to choose from (such as device management specialist suppliers, like AVSystem and EdgeIQ).

With an open standard defining device management service like LwM2M, a greater number of developers can access the source code in an open-source licensing environment over a proprietary licensing regime, so security vulnerabilities as well as bugs may be identified and patched earlier. This benefits the gateway and platform suppliers who rely upon LwM2M to deliver device management services. Those suppliers can benefit from a wide community of developers supporting their device management services. Also, customers benefit by opting for their solution knowing that the company’s service has the security features that are deemed essential in mission critical use-cases.

Signs of adoption of LwM2M in the industry continue to emerge with “pure-play” platform vendors (AVSystem and EdgeIQ), developing their device management services by opting for APIs and device agents based on LwM2M rather than MQTT. This development comes as a surprise, given that EdgeIQ has historically developed its product suite relative to MQTT.  AVSystem also has an open-source version of its LwM2M device agent that can be used for free, as well as a commercial license for more advanced features. This shows that the trend of standardization is not just useful because of its ability to leverage the open-source developer community, but also becoming an increasingly viable commercial proposition. This creates a win-win: leveraging a developer community benefits the customers with more frequent updates, as well as benefitting device management service suppliers who know their services have the support of community developers.