oneM2M standards help developers across the spectrum of use cases from IoT connectivity to data marketplaces, in multiple industry verticals.
IoT solutions solve pressing operational problems, connecting software applications to distributed assets. This could be as straightforward as remotely monitoring the status of a machine. Alternatively, it might involve the use of technology to update software on a set of digital displays or a fleet of vehicles.
The nature of each problem determines the technical choices made. For example, an IoT developer might choose the LWM2M protocol if device management is seen as critical. If they are concerned about low-power connectivity over large distances, they will construct a solution using SigFox or NB-IoT technologies. If payload efficiency is a priority, they might choose between CoAP and MQTT connectivity protocols. These are some of the technology choices that IoT developers face. It is often simpler to work with an IoT platform whose capabilities represent a toolkit of programmed functions that shield developers from these technology complexities.
New Needs and New Tools
After some time in service, the expectations of an IoT system are likely to evolve. There might be a need for more functionality. This could involve linking two or more IoT solutions to enable a new way of using data, possibly crossing departmental boundaries. In this situation, complexity depends on whether the two-silo solutions use common conventions, which makes interoperability possible. This depends on how device and application identities are managed, for example, and whether a translation gateway is required between domains. Yet another interoperability requirement might involve a procedure where one IoT solution notifies another when an action is triggered by some application logic.
IoT platforms eliminate many of these issues in situations where different IoT solutions use the same platform. However, matters get complicated if IoT solutions use different platforms. This can arise in the case of several related participants in an extended supply chain.
Of course, platform providers can add new capabilities to address new needs over time. However, this can be costly on a one-off basis. A better strategy is to think in terms of a toolkit of capabilities applied to a framework of IoT devices, gateways, and platform. The platform provider can add new capabilities to the platform over time without redesigning the technology stack. This is analogous to adding new tools to a toolbox as opposed to creating different configurations of a Swiss Army knife for each separate IoT solution.
To illustrate this concept, consider the case of an IoT solution that requires a set of service functions for device management (e.g. LWM2M), registration (for sensor, device, and application identities) and communications management (to handle a mix of MQTT and HTTPS traffic). Later, the developer might want to enhance the solution by implementing tiered access levels or to customize data privacy policies for different users. After that, there is the possibility of distributing and monetizing IoT data, which will require yet more tools.
Common Service Functions
While each IoT solution is different, all depend on a set of common service functions (CSFs). These are analogous to tools in the IoT developer’s toolbox. CSFs may reside in IoT platform nodes (i.e. gateways and servers) and serve the purpose of maintaining communications between IoT devices, sensors, and other IoT platforms.
As systems evolve in complexity, the basic CSF toolkit will continue to grow. This is a requirement that its founders anticipated when they created the oneM2M standardization organization in 2012. Its members went on to specify an architectural framework for IoT solutions based on middleware technology in the horizontal layer that sits between IoT applications and, lower level devices and communications networks. As illustrated, oneM2M’s middleware technology currently comprises fourteen CSFs.
Developers can begin with a subset of CSFs from the toolkit to solve the initial deployment challenges of launching an IoT solution. Later on, they can introduce other CSFs progressively as they add data discovery, semantic interoperability, usage charging, and other capabilities to their solutions.
The Role of oneM2M CSFs in Enabling Key Business Processes
Data marketplaces are emerging as an important class of IoT systems in several IoT industry verticals. The intention is to share IoT data among several ecosystem partners and to support multiple use cases, not just one, via a horizontal architecture that provides a common and scalable environment. There, owners of connected assets can supply IoT data to developers who consume data. Data consumers are less interested in deploying sensors and care more about building IoT applications to solve business and operational problems.
In the context of connected vehicles, mobility services or smart region initiatives, data marketplaces allow cities and other users of the transportation network to share data under controlled conditions. That establishes the foundation for a wide variety of smart city and intelligent transport solutions. Examples include congestion management, intelligent use of parking resources, coordination of incidents with traffic police, and mobility services that involve connected and autonomous vehicles. Such use cases are typical of the business-process and technical issues that cities are grappling with and exploring through the ATIS Smart Cities Data Exchange initiative.
The horizontal platform approach takes the form of simple architecture based on oneM2M standards. As illustrated, the foundation contains the oneM2M Service Layer and a set of CSFs to manage IoT data from a range of transport data assets. The next layer exposes raw and value-added data, derived from the application of transportation analytics, to data consumers. These data consumers then develop applications such as for travel planning, parking, and other services in the uppermost layer.
Business Processes and oneM2M Capabilities to Enable a Transportation Data Marketplace
Within the oneM2M Service Layer, the first key business process is to manage data from different sources. This uses the Data Management & Repository CSF and the standardized oneM2M information model. Together, they provide a common framework to store diverse types of static and time-series data. The second CSF that supports data management is the Discovery CSF which enables applications to query and easily discover data from various types of devices in the system. The third CSF that supports data management is the Subscription & Notification CSF. It enables applications to subscribe to events of interest such as a threshold to indicate that traffic congestion has reached a certain level.
A second business process is to establish and manage service subscription accounts. This uses the Registration CSF which allows a system administrator to associate policies that define the identity and lifetime of a service subscription. The third key business process is to enable the data marketplace operator to apply policy controls to manage access to the system. The Registration and Security CSFs provide control over individual user subscriptions in terms of how many resources they can create and how much data they can upload. Such usage statistics are one element in the process of monetizing data via the Service Charging and Accounting CSF.
Roadmap for New IoT Capabilities
Since the publication of its Release 1 standards, oneM2M members have continued to develop and deploy its technical capabilities. In addition to regular interoperability testing events, work is close to finalizing new capabilities for inclusion in the Release 4 “toolkit”. These address new requirements in the IoT market for Fog/Edge computing, enhanced support for user and subscriber management, and vertical sector requirements related to industrial, railway, and vehicular communications markets.
