Is a New IoT Standard Needed? OneM2M's Perspective on Interoperability

Ken Figueredo of oneM2M

Webcomic #927 on xkcd.com illustrates the perennial debate over standards. It humorously depicts two developers debating a new standard while fourteen already exist, as noted by Ken Figueredo of oneM2M.

Beyond the joke lies a genuine challenge: standardising the IoT landscape. As awareness of protocols like CoAP, MQTT, LWM2M, and NB‑IoT grows, many ask whether yet another standard is necessary. The answer hinges on how we define an IoT system.

IoT as a systems challenge

An IoT ecosystem is a multi‑layered stack: devices and sensors at the edge, local and wide‑area networks, gateways or cloud platforms that orchestrate connectivity, and application frameworks that drive business value.

Data transport and semantic modeling add further complexity. Multiple transport protocols (e.g., CoAP, MQTT, HTTPS) coexist alongside diverse data representations (JSON, XML, plain text). Together, these form a lattice of subsystems that must interoperate across silos.

Consequently, complexity and fragmentation emerge as the primary adoption barriers. As the IoT market expands, suppliers proliferate, yet many deliver siloed, proprietary components, exacerbating fragmentation.

To mitigate implementation hurdles, mobile operators and cloud vendors are building partner ecosystems—akin to a restaurant menu—that let customers mix and match components.

While such ecosystems promise modularity, integration remains difficult, especially as the number of possible permutations grows.

An alternative is a comprehensive, end‑to‑end framework that encompasses every layer—edge devices, connectivity, middleware, and applications—enabling both simple and sophisticated deployments.

Such a framework depends on open standards to stitch together components. Vendor interoperability fuels a vibrant supply chain, achieves economies of scale, and spurs broader adoption and innovation on the demand side.

Tools for technologies: the oneM2M approach

Effective standardisation targets two core IoT activities: device‑to‑network connectivity and data transfer from edge devices to applications through gateways or cloud services.

One path is to build middleware that supports a specific connectivity domain—cellular, Bluetooth, or Wi‑Fi—and separately, another that handles transport protocols such as CoAP, HTTPS, MQTT, or WebSockets.

Alternatively, a unified suite of management tools can abstract these layers. An application developer could leverage a ‘Communication Management’ module that consolidates multiple transport protocols, allowing reuse across diverse media without re‑implementing low‑level details.

OneM2M embodies this philosophy by delivering a middleware layer that sits between application services and underlying device or connectivity stacks, offering a shared set of reusable tools.

The middleware offers an extensible toolkit of services that developers can selectively adopt. A unified API governs interactions between middleware, applications, devices, and network interfaces.

Contrary to the xkcd sketch, oneM2M augments, rather than competes with, existing standards. A single developer can combine cellular connectivity, a security framework (DTLS, TLS, PSK, PKI), a transport protocol (HTTPS, CoAP, MQTT, WebSockets), a serialization format (XML, JSON, plain text), and a service‑management stack (OCF, LWM2M, Thread). Thus, a handful of standardized tools enable a vast array of stack configurations.

Preparing for future IoT use‑cases and requirements

These scenarios show oneM2M’s ability to leverage existing protocols while acknowledging that the IoT landscape is rapidly expanding—especially with AI/ML, data sharing, and privacy mandates—where standardisation can unlock new opportunities.

When emerging needs arise, oneM2M introduces complementary standards. Starting in 2012, Release 1 and 2 addressed architecture and connectivity; Releases 3 and 4 expanded to higher‑level stack concerns.

The newer releases focus on semantic interoperability, minimizing mobile‑network congestion, and privacy/licensing mechanisms for data sharing. This trajectory underscores the imperative for an end‑to‑end IoT standard that evolves alongside innovation and emerging use cases.

The author is Ken Figueredo of oneM2M