Americas

  • United States
stevenhilton
Contributor

IoT alphabet soup: when should an enterprise use MQTT versus LWM2M?

Opinion
Sep 10, 20184 mins
Internet of Things

Enterprises need a way to ensure their IoT devices communicate to platforms and apps. Identifying when to use the popular MQTT or the newer LWM2M protocol will save enterprises time and money later.

There is tremendous interest from industrial enterprises to understand the nuances of the two most debated IoT data communications protocols: MQTT and LWM2M. MQTT and LWM2M are protocols that create a standard way to get device data to systems, platforms, applications, and other devices.

Let’s talk a little about each protocol and when it’s best used in an enterprise IoT deployment.

MQTT and when to use it

Message queuing telemetry transport (MQTT) is an ISO standard which describes a publish/subscribe (pub/sub) messaging protocol. Nearly all IoT platforms support MQTT communication, making it the de facto standard for device-to-platform IoT communication.

MQTT is best used for:

  • Simple or trial IoT deployments
  • When enterprises have many unmanaged devices generating high data volumes being ingested by an IoT platform
  • When a well-productized device management solution is available directly from the IoT platform vendor being used by the enterprise

MQTT is an application-layer protocol and leverages TCP and IP for the transport and internet layers, respectively. Modern revisions of the MQTT specification support features such as end-to-end encryption using either transport layer security (TLS) for the entire channel or payload encryption, quality of service (QoS), and session persistence. MQTT is designed to be a lightweight protocol for CPU-constrained devices, although implementation of TLS-secured MQTT does increase the client-side computational requirements. MQTT’s flexibility allows the protocol to support both data management and device management capabilities, although implementation of these features is entirely platform- or vendor-specific, preventing simple portability of an IoT solution between IoT platforms.

LWM2M and when to use it

OMA lightweight machine to machine (LWM2M) is a combination of different technologies that provides a defined standard for IoT data communication and device management. LWM2M’s primary benefit to enterprises is that it reduces vendor lock-in by allowing cross-vendor and cross-platform interoperability of data management and device management capabilities. This also reduces the complexities of managing heterogeneous hardware deployments.

LWM2M is best used for:

  • Complex and long-term IoT deployments
  • Implementations with managed devices or edge components such as IoT gateways
  • Implementations with connectivity-constrained devices
  • Solutions where an enterprise wants to avoid vendor lock-in.

Unlike MQTT, LWM2M has a well-defined data and device management structure that enables a variety of vendor- and implementation-agnostic features such as secure device bootstrapping, client registration, object/resource access, and device reporting. The LWM2M specification defines a variety of standard objects, which when implemented within an LWM2M client, provides a well-defined standard for data types for sensors, such as standardized temperature, pressure, analog input/output, and other sensor readings. The LWM2M specification also provides well-defined standards for many typical device management functions, such as remote device actions, firmware updates, on-device software management, and connectivity monitoring and management including cellular management and provisioning.

LWM2M is typically implemented on top of the constrained application protocol (CoAP) service layer protocol. Unlike MQTT, CoAP is designed with a more traditional client/server model and leverages user datagram protocol (UDP) including support for multicast, rather than TCP for communication. Data messages follow an HTTP-like syntax with a REST architecture that enables less-complex integration between existing RESTful API endpoints and CoAP-supporting devices. For message security, CoAP and LWM2M typically utilize datagram transport layer security (DTLS) for data payload encryption. Unlike MQTT and TLS, CoAP messages encrypt the payload of the message rather than the entire message transport. This removes some of the cryptographic overhead found in TLS and MQTT. In addition, CoAP and LWM2M support implementation over an SMS bearer, providing additional flexibility for network constrained devices that cannot support the UDP protocol.

Enterprises rely on IoT data communications protocols to create a standard way to get data from devices to systems, platforms, applications, and other devices. While MQTT is the most common protocol used by enterprises today, MachNation believes that LWM2M is growing in market share. For larger, more complex, longer-lived deployments with managed devices, LWM2M is the protocol that enterprises should consider.

stevenhilton
Contributor

Steven Hilton is a co-founder and President at MachNation, the leading insight services firm researching Internet of Things (IoT) middleware and platforms. His primary areas of expertise include competitive positioning, marketing media development, cloud services, small and medium businesses and sales channels.

Steve has served on Cisco’s IoT World Forum Steering Committee where he was co-chairperson of the Service Provide and Security working groups. Steve has 25 years’ experience in technology and communications marketing.

Prior to founding MachNation, he built and ran the IoT/M2M and Enterprise practice areas at Analysys Mason. He has also held senior positions at Yankee Group, Lucent Technologies, TDS (Telephone and Data Systems) and Cambridge Strategic Management Group.

Steve is a frequent speaker at industry and client events, and publishes articles and blogs in several respected trade journals. He holds a degree in economics from the University of Chicago and a Master’s degree in marketing from Northwestern University’s Kellogg School of Management.

The opinions expressed in this blog are those of Steven Hilton and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.