October 2019 - Roland Hechwartner of Deutsche Telekom Group (DT) is also the Chairperson for oneM2M's Technical Plenary (TP). Here, he reports on the recent TP#42 meeting which took place in India.
Q: Where did the oneM2M TP event take place and who hosted and sponsored the meetings?
RH: As a reminder for our readers, oneM2M rotates its TP meetings in different parts of the world. That way, we make the most of oneM2M's global focus and involve as many members as possible. Our 42nd TP took place in Hyderabad, India, with the assistance of the Telecommunications Standards Development Society of India (TSDSI).
In addition to the usual series of technical sessions, TSDSI also hosted an Industry Day event. This is something which oneM2M introduced a few years ago to engage with the wider market and to share examples of how oneM2M standards are being applied.
In addition to TSDSI, I would like to thank several co-hosts for making the Industry Day possible. These include the India-EU Cooperation Project on ICT Related Standardisation, the International Institute of Information Technology in Hyderabad and Sensorise Digital Services Pvt. Ltd.
Q: What were the highlights of this TP?
RH: It probably makes sense to describe the developments in the context of oneM2M's new organisational structure, as readers may recall that we now operate under three activity areas. These are as follows: Requirements and Domain Models (RDM), System Design and Security (SDS), and, Testing and Developers Ecosystem (TDE).
At a high level, I would highlight extensions of our horizontal approach to serve new requirements in several vertical domains, notably for railways, automotive vehicles and the industrial sector. We also see great promise in strengthening standardisation capabilities along the Internet of Things (IoT) stack. This includes enhanced interoperability capabilities at the connectivity layer, in relation to 3GPP for mobile networks, and with Modbus which is prevalent in industrial networks.
We are also working to improve semantic support capabilities which will make oneM2M resources more discoverable by IoT applications, for example. In the testing arena, oneM2M members continue to add to the body of conformance testing specifications.
One final observation about the TP is that it brought together a lot of organisations from across India and the Asia region. In addition to delegates from oneM2M member organisations, there was a good presence from university and research institutes as well as representatives from large Indian firms, such as Tata Consultancy Services, and the small and medium-sized business sector. This wide-ranging interest is positive for oneM2M adoption. It reflects similar industry patterns to those we recently heard about from representative in Korea's academic and industrial sectors.
Q: What did participants learn in terms of the new requirements you mentioned?
RH: The main achievement in the Requirements and Domain Models area was to finalise the Work Item (WI) on the Public Warning Service enabler - WI-0070 - which feeds into the Technical Report (TR) document, TR-0046. This is an example of a vertical application scenario. It deals with emergency situations where people and things need to communicate with each other and trigger actions accordingly. To make this possible, there is a need to integrate different types of devices, sensors and actuators, with a variety of vertical systems for emergency communication purposes. oneM2M is well suited to this task. It defines a set of common services that enable standardised communication and interaction between IoT applications on various types of endpoint devices, gateways or edge nodes and servers from different developers and manufacturers in a multi-network environment. The TR was finalised and approved at TP#42. Further normative updates to the domain model arising from this study will be handled in future meetings and applied to Release 4.
Other items of work in progress included the documents on Vehicular Domain enablement, Railway Domain enablement as well as, Industrial Domain enablement. With Smart Cities being an important application area for oneM2M, there was further progress on the development of ontologies for Smart City Services.
Q: You mentioned interoperability as another highlight of the TP. What developments occurred on that topic?
RH: You can look at oneM2M as a standard that enables IoT applications to communicate with one another across domains and application silos. It can function as a "standard of standards" by leveraging existing and well-established domain standards.
Consider the mobile industry as one example. Within the TP, we are specifying interworking functions between the oneM2M service layer and 3GPP features. These will expose some 3GPP Release-13, 14 and 15 features to the oneM2M service layer for the benefit of IoT applications, and vice-versa (some oneM2M features that can be used by cellular IoT networks).
In the industrial sector, many applications rely on the Modbus application layer messaging protocol. Our TR on Modbus Interworking is near to completion and it investigates interworking capabilities between Modbus devices and the oneM2M system. In other words, how can oneM2M applications gain access to the data stored in Modbus devices via an interworking entity. This analysis will eventually propose changes and enhancements to the current oneM2M architecture.
Another emerging topic for industrial applications involves Edge and Fog Computing architectures. These will be deployed to mitigate the burdens on data centers/core networks and decrease communication latency by processing, acquiring and storing data at the edge network near IoT devices. We launched a new WI in this area to analyse Edge and Fog computing use cases and their associated requirements. This will help in identifying oneM2M features to support a range of technical requirements including capabilities to lower communication costs, to enhance reliability, and to supply localised content more efficiently.
Q: It sounds like the TP is also working on enhancements to improve the usability of oneM2M. What are some of those developments?
RH: In addition to server and gateway node deployments of oneM2M's common service functions, we also want to enable oneM2M services and corresponding resources to be hosted on even more constrained IoT devices. This falls under the category of lightweight oneM2M services.
Another area of progress is to enhance the discovery of oneM2M resources through better semantic descriptions. In Release 3, there is a framework of semantic descriptions for content, storage, management and discovery of ontologies as well as basic capabilities to enable semantic mashups. For Release 4, we plan to add basic capabilities to enable semantic reasoning as well as basic capabilities to enable and support analytics.
In other areas, we are also working to help system administrators to specify complex access control policies in a uniform way. At present, the current oneM2M access control policy scheme is based on an Access Control List (ACL). This can specify access control rules modelled as a 3-tuple (subject, resource, action). When extra access conditions need to be considered, an access control rule can be modelled as a 4-tuple (subject, resource, action, context). Here, the context represents a condition under which a specific access control rule can be used for access control. The new Attribute-Based Access Control (ABAC) approach allows various attributes related to subject, resource, action and context to be added to these elements. ABAC allows administrators to specify complex access control policies in a uniform way. For example, in a oneM2M system, the attributes belonging to a subject may be role, IP address, domain, group, etc. The attributes belonging to a resource may be resource type, parent ID, creation time, etc. and those belonging to an action may be a time period in which the specified action can be performed. Various attributes of subject, resource and/or action can be used to describe access control conditions that are used to constrain the usage of an access control rule.
There is also work underway to improve the treatment of subscribers and users. The current oneM2M architecture supports enrollment of individual oneM2M devices (i.e. nodes) and applications (i.e. AEs). Once enrolled, applications (i.e. AEs) can then securely and individually register to a service layer entity (i.e. CSE). oneM2M also supports M2M Service Subscriptions which define applications and devices that can register to a CSE. However, capabilities such as enrollment, authorisation and privacy at the granularity of a service subscriber and/or an authorised user affiliated with a service subscriber do not exist yet. This WI analyses different approaches for adding this support. TP members will propose normative solutions that should feed into the corresponding specifications, i.e. TS-0001 and TS-0003.
Q: And finally, what were the major developments in the conformance testing arena?
RH: Conformance testing is an important and growing part of oneM2M's work. It represents a critical step in proving whether an implementation complies with the defined oneM2M specifications. During TP#42, we ratified three Conformance Test Specifications for Release 2. These were TS-0017 Implementation Conformance Statements v2.2.0, TS-0018 Test Suite Structure and Test Purposes v2.14.0 and, TS-0019 Abstract Test Suite and Implementation eXtra Information for Test v2.4.0.
Q:When and where is the next TP meeting?
RH: The next technical plenary meeting, oneM2M TP#43, will be hosted by ATIS and takes place in Washington DC, USA, from December 2-6.
