Webcomic #927 on the xkcd.com site typifies the dilemma around standardisation. It makes a joke about two people wanting to create a new standard when fourteen already exist, says Ken Figueredo of oneM2M.
While the subtext shines a light on rivalry between different organisations or schools of thought, the issue remains when it comes to standardisation for the Internet of Things (IoT) market. With growing market awareness around IoT standards, such as CoAP, MQTT, LWM2M and NB-IoT, does the world need another standard? The answer to this question depends on the definition of an IoT system.
IoT as a systems challenge
IoT systems consist of several elements. A basic technology stack includes devices and sensors, local- and wide-area connectivity networks, gateway or cloud-server platforms for managing communications and, other platforms to enable applications.
Then, there are different approaches for transporting small data payloads. And there are different schemes for representing data and information models for the purposes of data interoperability. This combination of elements represents a system of sub-systems. That is before any discussion of technologies and standards to enable cross-silo interoperability between individual IoT applications.
Given these choices, it should come as no surprise that two barriers to adoption involve issues of complexity and fragmentation. With greater commercial prospects for IoT, the supplier base continues to grow. However, many of these suppliers offer single-component or proprietary solutions which contributes to industry fragmentation.
To offset implementation difficulties, some mobile network operators and cloud service providers operate partner ecosystems. They attempt to replicate the concept of a restaurant menu to enable pick-and-mix solutions.
This approach relies on systems integration approaches to build and deploy individual solutions. However, integration is itself a challenge as the number of permutations starts to rise.
An alternative approach to the IoT challenge is to start from a multi-purpose framework for end-to-end IoT systems. This framework includes all the components necessary to build simple as well as complex IoT systems.
It relies on standardisation to link individual elements into an overall solution. An open standard approach, of course, would allow for vendor interoperability. This would foster a dynamic supply-side industry and drive economies of scale. It would simultaneously encourage adoption and innovation among demand-side users.
Tools for technologies: the oneM2M approach
In thinking about standardisation, consider two basic and recurring activities in an IoT system. One is to connect a device to a network. The second involves transporting data from the device to an application, via a gateway or server.
One approach is to develop the middleware software based on cellular network connectivity. There would be different versions for Bluetooth and Wi-Fi connectivity. Likewise, a developer might develop the software to transport data using the CoAP protocol and other versions for HTTPS, MQTT and WebSockets.
A different approach is to develop a set of tools to manage the processes associated with different IoT technologies. Now, an application developer could use a ‘Communication Management’ tool, which covers a super-set of different communications technologies. This arrangement abstracts the complexity of lower-level technologies and means that the developer can reuse the ‘tool’ to build solutions using different communications media.
The notion of creating a suite of common and reusable tools to manage different technologies in the IoT stack is central to the oneM2M standard. In effect, oneM2M standards define a middleware capability that resides between an upper, IoT application layer, and a lower layer for devices and connectivity technologies.
The middleware comprises an extensible toolkit of common service functions that developers can draw upon, as needed, for their deployment requirements. The standardisation framework employs a common API for middleware communications with applications, devices, and network connectivity technologies.
Unlike the xkcd.com joke, oneM2M does not compete with existing standards but adds to their utility. For example, a developer might combine cellular connectivity, a security model (choosing from DTLS, TLS, PSK, PKI options), an appropriate transport protocol (choosing from HTTPS, CoAP, MQTT, WebSockets options), a device content serialisation method (choosing from XML, JSON, plain text options) and a services management technology (choosing from OCF, LWM2M, Thread options). In this way, a few standardised tools support a huge range of technology stack permutations.
Preparing for future IoT use-cases and requirements
These examples illustrate how oneM2M reuses established technologies and standards. However, the opportunity space for IoT systems continues to evolve, more so with the growing role of AI/ML, data sharing and privacy obligations. In many cases, there are standardisation benefits associated with the new application possibilities.
Where new activities or technology solutions are required, oneM2M define new and complementary standards. Beginning in 2012, oneM2M’s Release 1 and Release 2 standards focused on architecture and connectivity topics. Releases 3 and 4 address topics higher up the technology stack.
These involve developments to enable semantic interoperability, to reduce harmful loads on mobile networks and, privacy and licensing tools for IoT data sharing. This approach demonstrates the need for a standard for end-to-end IoT systems and a roadmap to build new capabilities driven by innovation and emerging use-case requirements.
The author is Ken Figueredo of oneM2M
Comment on this article below or via Twitter: @IoTNow_OR @jcIoTnow
