Added further oneM2M node types

This section provides an overview of the MEC framework, detailing its components, services, and how it supports Edge-based applications.

### 6.3.1	Introduction to onM2M

### 6.3.1	Introduction to oneM2M

oneM2M is a global standards initiative that develops specifications for a horizontal platform (or Service Layer) used for the exchange and sharing of data among Internet of Things applications. Individual IoT solutions using oneM2M can share data and resources through common service layer functions such as resource discovery and semantic interoperability. As a result, application developers, solution providers and data suppliers can share data between applications that span multiple verticals and reduce their dependence on single-vendor solutions.

oneM2M provides a layer of abstraction - similar to an operating system - that shields developers from the details of network communication protocols, interfaces to IoT device and device management. It provides a framework for interworking with different technologies, for example 3GPP and Modbus. 

**Figure 6.3.2-1: oneM2M architecture**

This architecture is composed of the following entities:

- *Common Services Entity (CSE)*: Provides the set of "service functions" that are common to the IoT domains

- *Common Services Entity (CSE)*: Provides the set of "service functions" that are common to multiple IoT domains

- *Application Entity (AE)*: Represents application logic for the end-to-end IoT solutions. This includes device firmware, gateway logic or backend applications

- *Interworking Proxy application Entity (IPE)*:  An AE that is used to interface between oneM2M and an external system

- *Network Services Entity*: Provides services to the CSEs beyond the data transport

- *Interworking Proxy application Entity (IPE)*:  A specialized AE that is used to interface between oneM2M and an external system

- *Network Services Entity*: Provides networking services to CSEs that are more than just data transport

- *Node*: Logical equivalent of a physical (or possibly virtualized) server or device

In particular, oneM2M defines several different kinds of node, which are named based on the specific instantiation option considered:

- *Application Service Node* (ASN) at the Edge device / Gateway (GW)

- *Middle Node (MN)* An Edge Node / Gateway (GW)

- *Infrastructure Node (IN)* A Cloud provider / company server

oneM2M defines several different kinds of node, which are named based on their use by oneM2M. 

- *Infrastructure Node (IN)*: A Cloud provider / company server. It hosts a CSE that is referred to as an IN-CSE and may host AEs. There is exactly one IN in the Infrastructure Domain of each oneM2M Service Provider

- *Application Service Node (ASN)*: A Node that contains at least one AE co-located with a CSE (an ASN-CSE)  

- *Middle Node (MN)*: A Node that contains one CSE (an MN-CSE) and zero or more AEs. It is typically found in an Edge Server or Gateway box.

- *Application Dedicated Node (ADN)*:A Node that contains at least one AE but does not contain a CSE. 

In addition, the oneM2M architecture supports another type of node, the so-called “Non-oneM2M Node” (NoDN), not shown in Figure 6.3.2-1. This is a node that does not contain native oneM2M Entities (neither AEs nor CSEs). Typically, such nodes would host some non-oneM2M IoT implementations or legacy technology which can be connected to the oneM2M system via interworking proxies or agents.

In addition, the oneM2M architecture defines one other type of node, the so-called “Non-oneM2M Node” (NoDN), not shown in Figure 6.3.2-1. This is a node that does not contain native oneM2M Entities (neither AEs nor CSEs). Typically, such nodes would host some non-oneM2M IoT implementations or legacy technology which can be connected to the oneM2M system via interworking proxies or agents.

The principal *Reference Points* defined by oneM2M are:

- *Mca*: The interface used by an AE to use the common services provided by the CSE

- *Mcc'*: Communication flows between CSEs that belong to different oneM2M service providers

- *Mcn*: Communication flows between a Common Services Entity (CSE) and the Network Services Entity (NSE) allowing the CSE to use the network services (other than transport and connectivity) provided by the NSE.

### 6.3.3    oneM2M Architecture oneM2M Common Service Layer Functions

From a functional perspective, oneM2M has defined fourteen common service functions (CSFs) as shown in Figure 6.3.3-1 below. These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies.

### 6.3.3    oneM2M Architecture Common Service Layer Functions

From a functional perspective, oneM2M has defined fourteen common service functions (CSFs) as shown in Figure 6.3.3-1 below. These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies. A given  CSE does not have to implement every CSF and CSE's can communicate with each other giving an AE or CSE the ability to access oneM2M resources that are hosted on a remote CSE.

![Figure 6.3.3-1: Common Service Functions.](/media/oneM2M CSFs.png)

**Figure 6.3.3-1: Common Service Functions**

These oneM2M services are defined so that application developers can focus on application-specific functionality (e.g., turning a switch on or off), while relying on abstractions provided by oneM2M to mask the underlying technology-specific details, thus allowing bindings to different communications stacks and protocols such as HTTP, CoAP and MQTT. For example, a simple switch might use a fixed or Wi-Fi network, a CoAP or HTTP transport. It might use a JSON or XML serialization, an Open Connectivity Foundation (OCF) or thread service enablement, or an ontology based on Smart Appliances REFerence (SAREF) or W3C’s Thing Description. 

Finer-grained capabilities underpin each service function as illustrated in the case of device management, security and application and service management functions. In keeping with a philosophy of leveraging existing standards rather than re-inventing them, oneM2M complements existing and proven security technologies to address IoT security challenges. It provides a common set of security capabilities to secure IoT devices and data; and to prevent or mitigate attacks. This is made possible by an abstracted set of security-related APIs to simplify security for devices and applications. oneM2M is a constantly evolving standard with a strategic roadmap designed to address new IoT requirements. This is made possible by the common service layer concept, which was conceived to accommodate new service functions. oneM2M works according to a release cycle to standardize new service functions. It emulates the cellular industry’s 3GPP standardization model, to address new requirements and evolving technologies through progressive releases.

Finer-grained capabilities underpin each service function as illustrated in the case of device management, security and application and service management functions. In keeping with a philosophy of leveraging existing standards rather than re-inventing them, oneM2M complements existing and proven security technologies to address IoT security challenges. It provides a common set of security capabilities to secure IoT devices and data; and to prevent or mitigate attacks. This is made possible by an abstracted set of security-related APIs designed to simplify security for devices and applications. oneM2M is a constantly evolving standard with a strategic roadmap designed to address new IoT requirements. This is made possible by the common service layer concept, which was conceived to accommodate new service functions. 

### 6.3.4  Mapping between MEC and oneM2M

MEC applications can both consume services available in the MEC system and also produce services, which are made available by the MEC platform to other applications.

In the context of Internet of Things (IoT) and Machine-to-Machine (M2M) communications, we can consider the following mapping of oneM2M entities with ETSI MEC entities:

- A common service function (e.g., Network Service Function) or CSE in oneM2M architecture can be represented as a MEC Service and/or as a service producing MEC App instance. This service would be exposed by the MEC platform to be connected to (authorized) consumer Application Entities (AE).

- Similarly, an AE in the oneM2M architecture can be seen as a MEC App instance by ETSI MEC system.

- A common service function (e.g., Network Service Function) or CSE in the oneM2M architecture can be represented as a MEC Service and/or as a service-producing MEC App instance. This service would be exposed by the MEC platform to be connected to (authorized) consumer Application Entities (AEs).

- Similarly, an AE in the oneM2M architecture can be implemented as a *MEC Application* in an ETSI MEC system.

Architectural interworking between ETSI MEC and oneM2M is made possible by seeing the CSE and AE functional elements of oneM2M as particular instances of MEC services and applications from the point of ETSI MEC system (which is not imposing any mechanisms on how these services and applications should be designed). More specific hooks can be envisaged to effectively integrate these two systems and gain more benefits from tighter integration (for example, specific mechanisms for application onboarding and instantiation, or additional MEC service APIs).

Architectural interworking between ETSI MEC and oneM2M is made possible by seeing the CSE and AE functional elements of oneM2M as particular instances of MEC services and applications from the point of ETSI MEC system and by providing MEC-specific IPE'a. More specific hooks can be envisaged to effectively integrate these two systems and gain more benefits from tighter integration (for example, specific mechanisms for application onboarding and instantiation, or additional MEC service APIs).

### 6.3.5  Virtualization of oneM2M Common Service Layer functions