September 2020 - In this interview, Kenichi Yamamoto of KDDI, a oneM2M Technical Excellence Award winner from 2018, describes his involvement with oneM2M and the activities he has been leading on IoT architecture and Edge & Fog computing topics.
Q: Let us begin by talking about your background and roles in KDDI and oneM2M.
KY: I am a member of the Technology Strategy Department of KDDI, the Japanese telecommunications operator. My role at KDDI is to contribute to IoT/Edge Computing standardization activities and, to explore promising technologies for delivering a better customer experience that constantly exceeds the expectations of our end users. I have been actively involved in oneM2M since 2017, promoting the development of technical specifications as a Co-Rapporteur for three work items, one for Edge/Fog computing, another for 3GPP external exposure API interworking and the other for Vehicular Domain Enablement.
I am also involved in the oneM2M Technical Committee in the Telecommunication Technology Committee (TTC) as a member. In cooperation with the Association of Radio Industries and Businesses (ARIB), another standards development organization in Japan, we discuss the policy for dealing with the oneM2M Steering Committee (SC) meeting, share information and exchange opinions among members on technical issues. We are working downstream to establish the technical specifications created by oneM2M as TTC specifications.
Q: Your recent focus has been on Edge/Fog computing. How do you define the topic and what it means for the IoT industry?
KY: Edge/Fog computing is a distributed computing paradigm that resides between IoT devices and Cloud Nodes. The aim of this technology is to mitigate the processing burden on Cloud Nodes. It also decreases communication latency by processing, acquiring, and storing data in distributed computing nodes that are closer to IoT devices in the field. In addition to its technical capabilities, Edge/Fog computing can reduce communication costs, enhance operational reliability, and make it more efficient to provide localized content.
Several organizations across the IoT industry are active in this arena so it is clearly quite important. One example is ETSI's Multi-access Edge Computing (MEC) initiative which operates as an Industry Specification Group (ISG). Members of the MEC ISG work on use cases, requirements, a reference architecture, and corresponding API specifications for application enablement in an Edge Computing node and for capability exposure to applications. Other organizations that are working on this topic include 3GPP, 5GAA, EdgeX Foundry and the OpenFog Consortium, which merged with the Industrial Internet Consortium (IIC).
From the outset, oneM2M architecture was conceived as a distributed architecture system. We probably anticipated the use cases that justify Edge/Fog computing. Early in 2018, during oneM2M's 33rd Technical Plenary (TP), KDDI and Convida Wireless launched a work item, WI-0080, on Edge/Fog Computing. Other oneM2M members that supported the work include Huawei, Hitachi, TNO, NEC, NEC Europe, NTT, BOE, Gemalto (now Thales), Qualcomm, AT&T, KETI, TIM, Cisco, and Nokia.
Q: What approach is oneM2M taking to address the Edge/Fog computing issue?
KY: As a first step, we studied service and feature use cases that involve Edge/Fog technology. Some of these use cases are broad, as in the case of smart factories and smart transportation. Others deal with high priority services, such as the cases of an accident notification service, a high-precision road map service, discovery of vulnerable road users and, a vehicular data service using data model techniques. Yet others deal with the technical intricacies of Edge/Fog computing, examples of which include link binding management for digital twins and reliable Edge/Fog computing. These use cases are documented in the use cases collection Technical Report (TR-0001) and vertical-specific Technical Reports (TR-0018, TR-0026). Requirements raised through the analysis of use cases are captured in the requirements Technical Specifications (TS-0002).
We also studied scenarios based on existing Edge/Fog technologies to identify optimizations that we might bring into oneM2M platform implementations. One such example deals with the optimization of vehicular data transfer over cellular networks. It involves interworking between oneM2M and the 3GPP's standard for the Service Capability Exposure Function (SCEF) (see figure below). The SCEF provides a means to expose services and capabilities provided by 3GPP network interfaces in a secure manner. By enabling interworking with the SCEF, a platform built to oneM2M standards can leverage the exposed information to adjust data transmission for individual devices. As a result, a mobile network operator can offer value-added services to a service provider.
Q: What conclusions did you reach following the analysis of Edge/Fog services and use cases?
KY: We identified six key issues from studying different use cases, developing requirements, and analyzing optimization scenarios. From these key issues, we addressed eight solutions on topics related to Edge/Fog offloading, common service description/service-awareness, Edge/Fog computing using the 3GPP SCEF API, dynamic service management. These key issues and solutions are captured in the Edge/Fog Computing Technical Report (TR-0052).
Our investigation into the concept of Edge/Fog offloading is derived from the Vulnerable Road User (VRU) detection service. It allows a cloud-based IoT platform (an Infrastructure-Node, Common Services Entity or IN-CSE in oneM2M terms), to transfer relevant resources and tasks to a target edge node (a Middle-Node, Common Services Entity or MN-CSE in oneM2M terms). Now, the MN-CSE can directly support IoT devices it serves with the service offloaded by the IN-CSE. One way to view this is as a way of taking oneM2M's any of the fourteen Common Service Functions (CSFs) that a cloud based IoT platform would provide and replicating them into one or more edge nodes.
Representatives from our Korean member, KETI, proposed two solutions for the Edge/Fog offloading arrangement. One of the solutions uses the announcement resource in oneM2M while the other uses a dedicated resource to manage resource offloading. The analysis of these solutions uses three criteria (i.e., system impact, complexity, and extensibility) and the conclusions form part of the ongoing work for Release 4 standardization.
Q: How does oneM2M help to address Edge/Fog challenges?
KY: There are several features in the WI on Edge/Fog computing so let me describe a couple that are of immediate interest. As an example, consider the case of service providers or developers that want to manage the software on edge nodes. This is problematic when service providers need to make updates, such as install, delete, activate, and deactivate operations, to individual nodes. There is a greater challenge in situations where the quantity of edge nodes is large. If they also wish to offload computing from Cloud nodes to Edge nodes, there also comes another challenge. Edge nodes tend to have more limited compute resources in comparison with Cloud deployments. I believe this places a heavy burden on service providers and is a big challenge for standardization.
One way that oneM2M addresses these issues is through a Software Campaign feature that another oneM2M member from Convida Wireless contributed to. This is an enhancement of oneM2M's existing device management functionality which serves to orchestrate oneM2M services onto Edge/Fog Nodes. A service provider can use a control dashboard or Application Entity (AE) to offload software management operations of Edge/Fog Nodes to a hosting IoT platform (an IN-CSE in oneM2M terms). It would issue a software campaign request containing information about the software version, software operation (install, uninstall, activate, deactivate), target Edge/Fog Nodes and trigger criteria. When the software campaign trigger criteria are satisfied, the hosting platform (CSE-1 as illustrated) performs the operations necessary to manage the CSE software on targeted Edge/Fog nodes. This example demonstrates the benefit of reducing the burden on developers and service providers by delegating device management functions in basic and complex, Edge/Fog deployment scenarios.
Another way that oneM2M helps service providers in Edge/Fog situations involves mobile network usage scenarios. A service provider might want to leverage 3GPP network congestion status at each edge site for service optimization. To do so, it can retrieve congestion information from a 3GPP SCEF with the network congestion monitoring feature proposed by KDDI. Based on information from the network, the service provider can manage software operations for specific Edge/Fog Nodes using the Software Campaign feature in a more dynamic fashion.
These examples highlight some of the benefits that oneM2M standards offer. Through our work on Edge/Fog computing, we are adding advanced features and enhancements to existing oneM2M technical specifications. Features associated with Software Campaigning, network congestion monitoring and resource synchronization are included as updates to the oneM2M Functional Architecture (TS-0001) and 3GPP interworking (TS-0026) documents.
There is one more new development I would like to mention to show how our standardization work can benefit the ecosystem of mobile communications service providers and users. At the beginning of 2020, the GSMA published a White Paper on the concept of an Operator Platform. This aims to help mobile network operators (MNOs) to make their assets and capabilities consistently available to the developer community and to the enterprise segment across networks and national boundaries. Based on this concept, the GSMA launched an Operator Platform Group (OPG) project to create the architecture and technical requirements that will guide Standards Development Organizations (SDOs) to develop specifications for the platform. In Phase 1, the work focuses on federating the Edge computing infrastructure across multiple MNOs. This will enable application providers to access a global Edge-Cloud to run innovative, distributed, and low latency services through a set of common APIs.
The GSMA's OPG plans to collaborate with the SDOs and oneM2M is in their frame for collaboration. The GSMA's Telco Edge Cloud (TEC) Chair delivered a presentation of the GSMA's OPG activity at the oneM2M Technical Plenary session on July 16th. We hope that the synergies between the OPG's requirements and oneM2M technical specifications for 3GPP SCEF interworking and Edge computing functionality could speed up their work.
