August 2019 - oneM2M Technical Plenary (TP) meetings are regularly scheduled events over the calendar year. Through this forum, oneM2M members have an opportunity to meet face-to-face to define the oneM2M technology roadmap, discuss and reach consensus on technical contributions towards the standard and test their oneM2M-based solutions with one another.
In this Executive Interview, Dale Seed, of Convida Wireless, shares his observations from the TP#41 event.
Q. Where did the oneM2M TP#41 event take place and who hosted/sponsored the meetings?
DS: The event took place the week commencing July 8th in Shanghai, China and was hosted by China Communications Standards Association (CCSA).
Q. What is the overall progress to date on oneM2M Release 4?
DS: I often use the following illustration when I'm talking to organisations that are interested in oneM2M. It shows our progression in creating Internet of Things (IoT) standards and our future intentions. What is particularly important is our operating model with regular member meetings, scheduled outputs and a standardisation roadmap that users can factor into their plans.
As to the specifics of how oneM2M standards are progressing, the timeline shows that Release 4 Stage 1 requirements are now frozen. As a result, most of our meeting time at TP#41 was dedicated towards progressing the Release 4 Stage 2 architecture related work. We expect to freeze the Stage 2 architecture at the end of Q4 2019 at which time Stage 3 protocol related work will ramp-up and last until Q3 2020. We are aiming to ratify oneM2M Release 4 during Q1 2021.
Q. What were the major work items focused on during the TP#41 meeting?
DS: Before getting into the details, let us recall that oneM2M members set out to standardise a set of horizontal capabilities in the form of common services in a middleware layer. Device management is a common service that every IoT application and connected device needs. It's much better for a scalable industry to agree on a common standard which brings costs down and enables interoperability among different suppliers.
From its early days, the scope of the oneM2M standard has expanded. We continue to work on common service capabilities. Our members are also active in solving the needs of different vertical segments. oneM2M aims to re-use existing industry standards so another area of activity is in standardising interworking capabilities. One final topic worth mentioning is semantic interoperability which addresses the new functions involved in creating value, higher up the IoT stack.
Q. Of those topics, what is oneM2M doing in the area of verticals?
DS: In a previous interview, I described a new set of Work Items (WIs) in the industrial, railway and smart city verticals. At TP#41, we saw some work in the public safety vertical as well. Specifically, WI-0070 deals with a Public Warning Service Enabler. Under this WI oneM2M is looking at adding support for a Public Warning Information Model that contains event types for various emergency situations (e.g. earthquakes, tsunamis, etc).
In addition, oneM2M is looking at features such as subscriptions and notifications that can leverage the Public Warning Information Model. These will allow notifications to be selectively sent based on emergency events of interest as shown in the use case below. For example, the Gas valve can selectively subscribe to receive notifications for earthquake warnings only, whereas a public warning sign can subscribe to receive notifications for both earthquake warnings as well as amber alerts.
Q. You mentioned the re-use of existing standards and interworking. How is oneM2M tackling these items
DS: As a middleware capability, oneM2M's horizontal architecture approach allows developers to build applications that involve several different technologies. As an example, a solution might use 3GPP networks for wide area connectivity, with an arrangement that relieves some of the data transfer load via Edge and Fog computing elements. If our solution involves an industrial facility, it's possible that they will have to interconnect to devices that use the Modbus standard.
During TP#41, our members worked on these topics, within a coherent, oneM2M frame of reference. For example, WI-0058 defines the procedures for how the oneM2M service layer interworks to an underlying 3GPP network to setup Quality of Service (QoS) sessions between the oneM2M applications. It relies on 3GPP's Service Capability Exposure Function (SCEF) T8 APIs. With member support, this capability is now part of technical specification TS-0026.
On the topic of Fog and Edge computing, WI-0080 deals with solutions for managing the dynamic instantiation (i.e. orchestration) of oneM2M services onto oneM2M network nodes. For example, this solution can be used to orchestrate oneM2M services onto edge compute node. This enables on-the-fly download and installation of oneM2M services onto edge compute nodes, based on the need and demand of devices and applications in the vicinity of these edge nodes and requiring oneM2M services. This opens up a whole new set of use cases and deployment options (e.g. vehicular) since oneM2M services no longer need to be pre-installed onto edge compute nodes. The solution is based on extensions to the existing oneM2M device management functionality. These extensions add support for new types of management objects specifically tailored for orchestrating oneM2M services and are now a part of technical report TR-0052.
Modbus is a de facto standard communication protocol for connecting industrial electronic devices in the industrial environment. oneM2M is a complementary technology. It allows solution providers to develop cross-silo applications that span different operating environments. Through WI-0072 which focuses on Modbus Interworking, there is a continuing stream of work to define additional interworkings to proximal network technologies. At TP#41, these activities provided additional contributions in Technical Report (TR) TR-0043. The Modbus interworking approach follows the same methodology as oneM2M applied to other proximal network interworking (e.g. OCF, LWM2M) definitions which employ a oneM2M Interworking Proxy Entity (IPE) to perform this interworking.
Q. From an IoT perspective, semantics is about making machines 'talk' to one another. How is oneM2M helping to make this a reality?
DS: Yes, that's one way to explain the role of semantics in IoT. As part of Release 2 and Release 3, oneM2M added support to attach semantic metadata to the data produced by IoT devices and applications and stored within the oneM2M service layer. This metadata provides additional context about the data (e.g. where was it produced, who it is related to, etc). oneM2M also added support to search and find data based on queries that make use of the semantic metadata. As part of Release 4, oneM2M is looking to make further enhancements to its existing suite of semantic capabilities. Within WI-0053, also known as Enhancements on Semantic Support, two new semantic capabilities are being studied. One is the addition of a semantic reasoning capability to the oneM2M service layer. The other, deals with the functionality necessary to assist with mapping a specified ontology to another specified ontology. These new mapping capabilities will bring cross-domain IoT applications closer to fruition. At TP#41, the studies of these two new capabilities were concluded in TR-0033 and the start of normative work was approved.
Q. Were there any other noteworthy developments at TP#41
DS: Yes, there are a couple worth mentioning because they capture the essence of IoT and why it differs from the usual discussion on smartphones and tablets. One of these deals with constrained devices where designers are often working with devices that may have power or processing capacity constraints.
Within WI-0076, which focuses on lightweight oneM2M Services, there is an effort to streamline the oneM2M messaging protocols and further reduce overhead for extremely constrained IoT devices and networks. During TP#41, members added several solutions to TR-0053. One solution enables constrained devices to offload and script their requests within the service layer. This means that the service layer can perform the requests on their behalf if and when the specified trigger criteria has been met.
Another solution adds the capability to configure a messaging profile within the service layer which enables it to filter and/or add metadata to messages that are exchanged with constrained devices. This enables constrained devices to shrink their messages by removing parameters that are static or redundant in nature.
With security and privacy being important topics in IoT solutions, another noteworthy activity falls under WI-0077 on Attribute Based Access Control Policies. As part of Release 4, oneM2M is working on further enhancements to its access control policies which are used to authorise access to the oneM2M service layer. Some of the enhancements include support for additional forms of context information that can be included within access control rules. These provide more flexible and powerful forms of authorisation as well as the definition of finer-grain access control policies (e.g. policies that apply to individual attributes of a resource). This WI also included the addition of privacy rules to access control policies. This allows the oneM2M service layer to anonymise personal data if needed. These solutions are captured in TR-0050.
Q. Turning away from these new capabilities, what progress has there been on market adoption?
DS: Over the past few months, a small task group has been collecting data on market deployments that use the oneM2M standard. A consolidated list of oneM2M solutions has been posted to the oneM2M website to make this information more accessible and visible. This information can be useful to companies and individuals looking to build and deploy oneM2M-based solutions and want to leverage an existing solution. The list already contains 65 solutions with39 of these deployed product solutions and another 10 being open source offerings.
Q. Can you give us an update on any collaboration / liaison activity between oneM2M and other organisations?
DS: We continue to work with other IoT bodies around the world. With this event taking place in China, we were honored to host representatives from the IoT Connectivity Alliance (ICA). The ICA is based in China and consists of a consortium of companies working together to unify IoT standards for easier use and deployment. oneM2M and ICA are exploring opportunities to collaborate more closely with one another and leverage each other's expertise. ICA was kind enough to provide oneM2M members with an overview of the work it has been doing including its Thing Model library which consists of 1000s of digital models of real-life devices.
In addition to our ICA discussions, we also reviewed our progress on our collaborations with Global Certification Forum (GCF) and ETSI Mobile Edge Computing (MEC). In the case of ETSI MEC, our members have started work on a joint white paper to identify synergies and potential gaps for interworking the oneM2M and ETSI MEC architectures with one another.
Q. When and where is the next TP meeting?
DS: TP#42 will take place the week commencing Sept 23rd in Hyderabad, India.
In conjunction with the TP#42 meeting, Telecommunications Standards Development Society, India (TSDSI) will also host oneM2M's upcoming Industry Day event, on Sept 25th. The objective of this event is to bring representatives from local Indian markets, industries, governments, and regulatory agencies together with oneM2M technical experts to help promote dialog and technical exchange on the use of oneM2M to help address India specific use case requirements and provide solutions suitable for Indian demographics.
