oneM2M IoT Service Layer (SL) Platform

oneM2M Overview

The oneM2M Global Organization creates Technical Specifications (TSs) to ensure that Machine-to-Machine (M2M) Communications can effectively operate on a Worldwide scale.

Seven (7) of the World's leading Information and Communications Technology (ICT) Standards Development Organizations (SDOs) launched in July 2012 a new Global Organization to ensure the most efficient Deployment of Machine-to-Machine (M2M) Communications Systems.

The new organization, called oneM2M, develops specifications to ensure the Global Functionality of M2M—allowing a range of Industries to effectively take advantage of the benefits of this emerging Technology.

The seven (7) majors ICT SDO founders of oneM2M are:

• The European Telecommunications Standards Institute (ETSI) , Europe
• The Association of Radio Industries and Businesses (ARIB), Japan
• The Telecommunication Technology Committee (TTC), Japan
• The Alliance for Telecommunications Industry Solutions (ATIS), USA
• The Telecommunications Industry Association (TIA), USA
• The China Communications Standards Association (CCSA), China
• The Telecommunications Technology Association (TTA), Korea

The members of the organization are devoted to developing Technical Specifications and Reports to ensure M2M Devices can successfully communicate on a  Global scale.

The oneM2M Standardization work is split in five (5) WG:

• WG1: Requirements
• WG2: Architecture
• WG3: Protocols
• WG4: Security
• WG5: Requirements and Domain Models (former MAS-Management, Abstraction and Semantics)

The Test Specifications cover different testing aspects such as interoperability, interworking, Conformance, Performance and Security for different Protocols and Network elements.

Akraino IoT Area oneM2M PTL and Community contributors

This is for the Akraino IoT oneM2M Family and compliant Blueprint creators. All are welcome to join by adding their name. 

Akraino oneM2M Contact person/PTL- Ike Alisson - 3 September 2021 through 3 March 2022

oneM2M supported IoT Use Cases (UCs) - SAREF (Smart Applications REFerence) Ontology

oneM2M supports IoT Use Cases (UCs) Smart M2M SAREF (Smart Appliances REFerence) Ontology. Initially, SAREF V1 was common to three (3) Domains, namely:

• Energy,
• Environment 
• Buildings 

The first core of SAREF (mapped into three (3) Applications’ Domains) has been improved to SAREF V2, thento SAREF V3 to enable mapping of SAREF with more Smart Applications domains such as:

• Smart City,
• Smart Industry and Manufacturing,
• Smart Agri-Food,
• Automotive,
• eHealth and Ageing-Well,
• Wearables,
• Smart Water,
• Smart Lift…)

Like this SAREF became Smart Applications REFerence Ontology (core SAREF) with its domain mapping extensions.

oneM2M Release Roadmap

oneM2M Layered Architecure Model

oneM2M Layered Model comprises three (3) layers:

• the Application Layer,
• the Common Services Layer
• the underlying Network Services Layer.

Application Entity (AE): The Application Entity is an Entity in the Application Layer that implements an M2M Application Service Logic. Each Application Service Logic can be resident in a number of M2M Nodes and/or more than once on a Single M2M Node. Each execution instance of an Application Service Logic is termed an "Application Entity" (AE) and is identified with a unique AE-ID.

Examples of the AEs include an instance of a fleet tracking application, a remote blood sugar measuring application, a power metering application or a pump controlling application.

Common Services Entity (CSE): A Common Services Entity represents an Instantiation of a Set of "Common Service Functions" of the oneM2M Service Layer. A CSE is actually the Entity that contains the collection of oneM2M-specified Common Service Functions that AEs are able to use. Such Service Functions are exposed to other Entities through the Mca (exposure to AEs) and Mcc (exposure to other CSEs) Reference Points.

Reference Point Mcn is used for accessing services provided by the underlying Network Service Entities (NSE) such as waking up a sleeping device. Each CSE is identified with a unique CSE-ID.

Examples of service functions offered by the CSE include: data storage & sharing with access control and authorization, event detection and notification, group communication, scheduling of data exchanges, device management, and location services.

Underlying Network Services Entity (NSE): A Network Services Entity provides Services from the underlying Network to the CSEs.

oneM2M Common Service functions (CSFs) applied to SAREF IoT UCs (Use Cases)

oneM2M's horizontal Architecture provides a Common Framework for IoT. oneM2M has identified a Set of Common Functionnalities, that are applicable to all the IoT Domains (SAREF). Think of these functions as a large Toolbox with special tools to solve a number of IoT problems across many different domains. Very much like a screw driver can be used to fasten screws in a car as well as in a plane, the oneM2M CSFs are applicable to different IoT Use Cases (UCs)/Domains in different Industry Domains.

In its first phase, oneM2M went through a large number of IoT Use Cases (UCs) and identified a Set of Common Requirements which resulted in the Design of this Set of Tools termed Common Service Functions (CSFs).

Furthermore, oneM2M has standardized how these Functions are being executed, i.e. is has defined uniform APIs to access these functions. Figure 5.3.1-1 shows a grouping of these functions into a few different scopes.

The Services above reside within a CSE (Common Service Entity) and are referred to as Common Services Functions (CSFs). The CSFs provide Services to the AEs via the Mca Reference Point and to other CSEs via the Mcc Reference Point.

oneM2M pre-integrated with 5G (3GPP) Specifications for cIoT

oneM2M baseline Architecture supports interworking with 3GPP and 3GPP Cellular Internet of Things (CIoT) Features such as IP and non-IP Data Control Plane Data Delivery. The oneM2M system may leverage the IoT related Features and Services that 3GPP added in Releases 10 through 15.  Features and Services may be accessed by an ADN-AE, MN-CSE, or an ASN-CSE that is hosted on a UE and an IN-CSE that is able to access services that are exposed by a MNO.

The “3GPP Trust Domain” in Figure 5.2-1 captures the Functional entities that shall be part of the 3GPP Domain (the Network). Although the Figure 5.2-1 shows that the IN-CSE and IN-AE are outside of the 3GPP Domain, the IN-CSE may be part of the Operator domain (Fig. 4.2-1b).

The 3GPP Trust Domain provides three (3) Interfaces to SCS/CSE (Service Capability Server/Common Service Entity) for MTC:

i) IP based interface at SGi reference point,

ii) RESTful API interface at T8 Reference Point,  

iii)  Diameter based interface at Tsp Reference Point.

The Service Capability Server (SCS) is a 3GPP term that refers to an entity which connects to the 3GPP Trust Domain to communicate with UEs used for Machine Type Communication (MTC). 

oneM2M Cloud Vendor Independent

oneM2M is Cloud Provider independent: From Fragmentation to Standards and decoupling Device, Cloud, and Application by Open Interfaces.

oneM2M addresses Edge/Fog computing in a deployment where the T8 Interface is exposed to the IN-CSE, therefore there is a “loose coupling” between the Edge/Fog Node and the Underlying Network.

In some Edge/Fog scenarios, an oneM2M Edge/Fog Node can exchange with the 3GPP Underlying Network parameters to be used for optimizing the Data Traffic over the Underlying Network for a set of Field Domain Nodes hosted on UEs. As a result, oneM2M System can avoid the need for the IN-CSE to process Data for the Field Domain Nodes. Figure 9.4.2.1‑1 illustrates the high-level illustration for the loosely coupled Edge/Fog Computing with 3GPP T8 API. The Edge/Fog Node retrieves underlining Network information in a particular area from a SCEF via the IN-CSE and adjusts Data processing/transfer for the Field Domain Nodes.

oneM2M and CIM NGSI-LD (Context Information Management Next Generation Service Interface - Linked Data)

The Goal of the ETSI CIM ISG on Context Information Management is to issue TSs to enable multiple Organisations to develop interoperable SW implementations of a cross-cutting Context Information Management (CIM) Layer.

The CIM Layer should enable Applications to Discover, Access, Update and Manage Context information from many different sources, as well as publish it through interoperable Data Publication Platforms.

Phase 1 - detect and describe the Standardization Gaps.

Phase 2 - Developing ISG CIM Group Specifications in Phase 2 will subsequently fill these gaps. It is expected that an extension of the RESTful binding of the OMA NGSI API involving expression using JSON-LD could aid interoperability, so this and potentially other extensions will be considered. 

The CIM API allows Users to Provide, Consume and Subscribe to Context Information close to Real-time Access to Information coming from many different Sources (not only IoT Data Sources).

oneM2M Semantic enablement and ASD (Advanced Semantic Discovery) for (AE) "Resources"

The oneM2M Architectural Model in oneM2M  Semantic enablement specification is based on the generic oneM2M Architecture for the Common Service Layer specified in oneM2M TS Functional Architecture.

The Core Functionality supporting Semantics resides at various CSEs, providing Services to the AEs via the Mca Reference Point and interacting with other CSEs via the Mcc Reference Point.

The Semantics (SEM) CSF (Common Service Function) is an oneM2M Common Service Function (CSF) which enables Semantic Information Management (SIM) and provides the related functionality based on this Semantic Information. The Functionality of this CSF is based on Semantic descriptions and implemented through the specialized resources and procedures described in oneM2M Semantic Enablement specification

The SEM CSF includes  Specialized Functional Blocks such as: SPARQL Engine, Repositories for Ontologies and Semantic Descriptions, which may be implemented via Permanent or Temporary Semantic Graph Stores, etc.

oneM2M Semantic enablement  for (AEs) Resource ASD (Advanced Semantic Discovery) and ETSI Smart M2M enhancement for (CSE) Resources ASD

Semantic Discovery in presence of a "Network" of M2M Service Providers (M2MSPs)

The Advanced Semantic Discovery (ASD) aims to discover AEs (also called Resources) that are registered/announced to some CSEs.

The ASD could start from any AE, even these ones not belonging to the same Trusted Domain.

The ASD differs from the usual one present in oneM2M in the sense that one (or many) AE could be searched for even without knowing its identifier, but just knowing its TYPE or ONTOLOGY membership, as shown in Figure 6.3.1-1.

Advanced Semantic Discovery (ASD) in Figure 6.3.2-1 below describes oneM2M as Semantic Discovery involving multiple CSEs.

ASD within Distributed Network of CSEs belonging a single Service Provider & across different IoT Service Providers.

Example of SRT (Semantic Routing Table)

The Ontology Mapping Task performed by

 => Create Operation or

 => Update Operation against an <OntologyMapping> Resource on a Hosting CSE.

A Retrieve operation against the same <OntologyMapping> Resource shall be used to get the result of Ontology mapping. A Delete operation against a <OntologyMapping> Resource shall follow the basic procedure as specified.

3GPP 5G NDL (Network data Layer) and oneM2M Semantic enablement and ETSI SmartM2M ASD integration

The information related to oneM2M Semantic enablement and ETSI SmartM2M ASD support (integration) with 3GPP specified 5G NDL (Network Data Layer in which Data "Compute" is separated from "Storage" in the process of virtualization of 5G NFs into VNFs/PNFs by separating the context in the NF's Application related Data from the Business Logic in the NF's Application related Data and stored separately in Nodes specified by 3GPP for 5G and denoted as "Structured" and "Unstructured" Data and supported in 5G 3GPP Rel 16 ATSSS (Access Traffic Steering, Switching and Splitting) is deliberately not included and part of the presentation on the oneM2M and 5G New Services.