April 2020 - In this interview, Roland Hechwartner of Deutsche Telekom Group (DT) and Chairman for oneM2M's Technical Plenary (TP) describes some of the highlights from oneM2M's recent TP meeting in San Diego, USA.
Q: What topics best highlight the work that took place for TP44?
RH: I would like to begin by thanking Qualcomm for hosting this meeting at their San Diego facilities. Our TP meetings run for a whole week, so this gathering gave our members an opportunity to meet with other West Coast organisations that are interested in oneM2M. For example, SGS - the inspection, verification, testing and certification company - hosted one of our meetings and provided a tour of their test and certification facilities.
We covered a lot of issues within oneM2M's three working groups: Requirements & Domain Models (RDM), System Design & Security (SDS) and Testing & Developers Ecosystem (TDE). Some of the most prominent and interesting topics discussed at the TP meeting include the continuing role of oneM2M as a hub for individual IoT technologies, time management in distributed Internet of Things (IoT) systems, and scaling of the IoT marketplace by standardising device management.
Q: What TP initiatives are underway regarding oneM2M's role as a hub for IoT technologies?
RH: You can think of oneM2M's role in IoT solutions as an interoperability hub that works across different industry verticals and industry-specific protocols. To find out more, here is a good illustration of its role which is described in a whitepaper that oneM2M published with the Industrial Internet Consortium (IIC). The different components in oneM2M's technical specifications provide the tools to create IoT solutions that combine different technologies in ways that are relevant to multiple application sectors.
As oneM2M is a modular standard, our members contribute to specifications in different areas. During this TP, we worked on developments related to the ZigBee and Modbus protocols, in addition to continuing some earlier work to support oneM2M's alliance with the Open Geospatial Consortium (OGC).
Let's begin with ZigBee, which is a low-power, low data rate, and close-proximity wireless ad-hoc network, mainly used in the home automation sector. During the TP, members voted to progress work on ZigBee interworking. This will begin with a Technical Report (TR) followed by a Technical Specification (TS) and follow the generic interworking principles defined by oneM2M. The scope of the report will cover use case configuration, resource structures, interworking principles, as well as the mapping of oneM2M to Zigbee2mqtt library and procedures for user-application interactions within the system.
In light of this, the Modbus protocol is an application layer messaging protocol that allows an easy form of communication within all types of network, and the oneM2M system is a horizontal layer, interworking with multiple subsystems of different verticals. The TR investigates interworking between Modbus devices and the oneM2M system. For example, how oneM2M applications can access the data stored in Modbus devices via an interworking entity. The TR on Modbus interworking was approved during the previous TP in December 2019. At this meeting, work commenced on the Technical Specification which normatively defines the interworking with oneM2M.
Moving on, another area I would like to highlight relates to the OGC which combines more than 505 businesses, government agencies, research organisations, and universities. Overall, their aim is to make geospatial information and services findable, accessible, interoperable, and reusable. Since we share several common values, you can appreciate the benefits of oneM2M working with the OGC. This is captured in a new WI (WI-0100) which aims to define interworking capabilities between OGC's SensorThings API (STA) and oneM2M. This will broaden the reach of existing platforms. It will enable platforms based on OGC/STA to connect to Sensor- or Actuator Systems that conform to the oneM2M standard. In a similar manner, a oneM2M Common Services Entity (CSE) platform can also be used to interwork with STA-enabled Sensors.
The benefits of interworking can be significant for cities that operate with heterogeneous architectures. They can make the most of the strengths and capabilities of both standards. An example that illustrates this idea comes from the EU-funded project mySMARTLife. In that case, DT's T-Labs connected the Hamburg SensorThings API with a Deutsche Telekom T-Labs Platform based on oneM2M. The design of an interworking solution with OGC's SensorThings API will follow the same principles that apply to existing interworking solutions in oneM2M.
Q: Based on the capabilities of oneM2M, tell us how the framework deals with time management?
RH: Let me begin by defining a few terms to explain the issue. The oneM2M standard defines a set of Common Services Functions (CSFs) such as device management and registration, among others. These CSFs reside in a CSE, which might correspond to a cloud or server hosted IoT platform in operational terms. Applications - which are also referred to as Application Entities (AEs) in oneM2M terminology - make use of these in the case of platform-to-platform interoperability.
oneM2M members plan to publish the Time Management Common Services Function (TMG CSF) as part of the oneM2M Release 4 standard. This will provide the capabilities for entities within an IoT deployment to synchronize their current time values with one another. There are several reasons why this is important. For example, due to various limitations and constraints of some deployments, entities such as resource constrained devices may lack support for synchronising their current time values with the current time values of other entities in the system. In addition, existing time synchronisation mechanisms such as Network Time Protocol (NTP), Precision Time Protocol (PTP), and Global Positioning System (GPS) may not always be available or may not be best suited for all types of IoT deployments.
The TMG CSF supports a set of time management capabilities for M2M entities to select and use to help them synchronise and manage their current time values with another. Without adequate time synchronisation, entities hosted on different nodes in the M2M system may be unable to maintain time synchronisation with one another. For example, a lack of synchronisation between AEs and CSEs can result in not sending a message to another in the proper scheduled time window. Another example would be AEs timestamping data such as sensor measurements, which they share with other AEs and which may result in information that is incorrectly processed or misinterpreted.
The TMG CSF enables a CSE to make its current time value available such that other entities can retrieve and use it to synchronise their current time value to the CSE's. The TMG CSF also supports the capability to send out time beacon notifications that include the current time value of a CSE to other entities in the M2M system such that they can use it to synchronise their current time value to the CSEs. The TMG CSF also supports the capability to perform time compensation on behalf of other entities by adjusting time related metadata sourced from or targeted towards these entities such that they do not need to perform time management operations themselves.
Q: You mentioned market scaling and new developments around device management, which seems to be a basic function in the IoT marketplace. What new initiatives is oneM2M working on to improve device management?
RH: oneM2M is continuing to evolve its Smart Device Template (SDT) to handle devices, sensors and actuators that are not equipped with existing, Standardised Device Management (DM) capabilities. This is an important way of enlarging the pool of connected devices that organisations can manage with oneM2M. For those not familiar with SDT, this is a simple, modular and agnostic framework to manage smart devices. It allows applications to communicate easily with other devices, regardless of the type of technology or communications protocols used by the devices. This is a huge benefit for service providers having to deal with many different types of devices in any given deployment setting. During this TP, we added device management functions to the existing set of SDT services with the aim of including changes in Release 4.
Q: Finally, what's next?
RH: Our next Technical Plenary is in July and is likely to be a virtual meeting due to travel uncertainties for our members across the globe. After that, we will continue our cooperation with the ITU-T at the next meeting which will take place in Geneva, Switzerland.
