July 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#40 event. This took place at an important time in the evolution of oneM2M as members shift their focus from Release 3 to Release 4 activities.
Q. Where did the oneM2M TP#40 event take place and who hosted/sponsored the meetings?
DS. The event took place during the week commencing May 20th in San Diego, California and was hosted by Qualcomm.
Q. Now that Release 3 has been ratified and published, what is the timeframe for Release 4 ratification and publication?
DS. For each Release, the TP work programme is grouped into stages. At TP#40, Release 4 use cases and requirements (i.e. Stage 1) was frozen which means that no new proposals for use cases and requirements will be accepted towards Release 4.
The next milestone that is planned in the Release 4 cycle is to freeze the architecture (i.e. Stage 2) which is planned for the end of 2019. Freezing the Release 4 protocol level work (i.e. Stage 3) is planned for Q2/Q3 of 2020 and Release 4 ratification is planned for the end of 2020.
Staged timing and long-range planning are essential parts of the process in developing formal and open standards. Within oneM2M, it helps members to organise their resources and provides a roadmap for users that are building long-term Internet of Things (IoT) solutions.
Q. What were the major Work Items (WIs) focused on during the TP#40 meeting?
DS. Most of the meeting time was devoted to progressing Release 4 work items. We pushed forward on the definition of Fog/Edge use cases and requirements to feed into work on oneM2M's Fog/Edge architecture. In practical terms, this is a bit like a vehicle driving along a road, passing several roadside units which are Edge/Fog nodes in a larger system architecture. In this case, the oneM2M system will synchronise data and context information between the nodes to support uninterrupted and continuous intelligent transport services. There is more information about this in oneM2M's WI-0080.
As the universe of IoT applications expands, we see a need for capabilities and processes that allow oneM2M applications and devices to discover oneM2M Service Providers (SPs). By automating this process, we see a lot of benefits for interoperability and innovation. This leads us to another major work item in Release-4, which is to define the enhancements that will support the discovery of oneM2M services. oneM2M service discovery can be based on criteria specified by the oneM2M entity performing the discovery (e.g. the types services required). Once a oneM2M SP is discovered, a oneM2M entity can then enroll to the oneM2M SP to obtain the proper credentials and information needed for it to establish a oneM2M security association and registration. Once registered, a oneM2M entity can then access the services offered. The Technical Plenary reviewed a couple of solutions and accepted additions to TR-0059.
The TP also made progress on the topic of action triggering. This is the kind of functionality that equips the oneM2M service layer to perform an operation autonomously if or when a pre-definable trigger condition is met. An example may involve updating the state of a resource to send a command to an actuator device. At TP#40, progress was made on enhancing this functionality to support configuring the service layer to perform sequences of operations rather than just a single operation.
Public safety systems are an important consideration in IoT systems and a topic of focus for oneM2M. Another focus at TP#40 was the definition of use cases and requirements applicable to devices operating under normal and emergency conditions. Within WI-0070, the TP plans to add supporting features to enable devices to switch to an emergency mode of operation and perform a predefined emergency task when a warning message - that is compatible with the Public Warning Information Model - is received. Enabling and disabling the emergency mode can be manually controlled by an application. It can also be a part of a schedule or based on a timer function.
One final area of work I want to discuss tackles the role of oneM2M as an interworking solution between different networking technologies. At TP#40, work started on the definition of methods for interworking Modbus to oneM2M in TR-0043. Modbus is mainly used for industrial purposes as illustrated in the diagram below.
The Modbus interworking will follow the same methodology as the other local area network inter-workings (e.g. OCF, LWM2M) defined in oneM2M and use a oneM2M IPE (interworking proxy entity) to perform the interworking.
Q. We discussed market adoption in our last interview. What progress has there been since then?
DS. Several members contributed to a list of oneM2M-based solutions in the market. The goal of this contribution was to pull together a consolidated list of oneM2M solutions and to post this information on the oneM2M website to make this information more accessible and visible for our members and non-members. This information will be useful to companies and/or individuals looking to build and deploy oneM2M-based solutions and are wanting to leverage an existing solution.
The contribution already has over 60 solutions and additional ones are likely to be added soon which shows great progress towards oneM2M market adoption. The wider TP membership is currently reviewing this information which should soon be posted on the oneM2M website.
Q. Industry collaboration is another aspect of market adoption. Have there been any developments between oneM2M and other organisations?
DS. oneM2M has been very active in its collaboration with other organisations. There were progress updates on collaboration work with ZigBee, 3GPP, ETSI MEC and GCF.
ZigBee provided copies of their specifications to oneM2M to enable it to progress with their plans to define an Interworking Proxy Entity (IPE) to interwork between oneM2M and Zigbee based proximal network deployments.
3GPP responded to oneM2M regarding the Liaison Statement that oneM2M issued to 3GPP to enhance their T8 Non-IP Data Delivery API to address a few shortcomings identified by oneM2M. 3GPP notified oneM2M that the request was accepted and work on corresponding enhancements has subsequently begun.
Leading up to TP#40, there were several conference calls between oneM2M and ETSI MEC focusing on potential areas of collaboration on the topic of edge-based computing. TP attendees agreed to move forward with a joint white paper that identifies 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#41 will take place the week commencing July 8th in Shanghai, China.
