Merge branch 'ESTIMED-D2.2-StableDraft-Section-6.3-Niblett' into 'ESTIMED-D2.2-StableDraft'

### 6.3	oneM2M Components

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 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. 

It is also designed as a distributed software layer, making it particularly suitable for use in Edge computing deployments, mitigating the burdens on data centers and core networks and improving communication latency by acquiring, processing, and storing data at the edge of network.

### 6.3.2	oneM2M Architecture

The oneM2M service layer is a general-purpose standard that applies to all industry verticals. It brings together all components in the IoT solution stack and specifies a distributed software/middleware layer, sitting between applications and underlying communication networking HW/SW. 

oneM2M service layer can be integrated into devices, gateways, and servers. Figure 6.3.2-1 shows a simplified oneM2M architecture:

![Figure 6.3.2-1: oneM2M architecture.](/media/oneM2M architecture.png)

**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 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)*:  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.

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 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 across the Mcc reference point enable a CSE to use the services supported by another 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 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. 

### 6.2.1	oneM2M Framework XXXX-1 

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. 

Description of the target oneM2M Framework ….

### 6.3.4  Mapping between MEC and oneM2M

### 6.2.2	oneM2M Framework XXXX-2 

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 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.

Description of the target oneM2M Framework ….

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.2.3	oneM2M Framework XXXX-3 

### 6.3.5  Virtualization of oneM2M Common Service Layer functions

Description of the target oneM2M Framework ….

Network Virtualization allows IT service providers to develop an end-to-end digital service based on network as a service (NaaS). Network Function Virtualization (NFV) targeted the oneM2M common service layer functions where the virtualization technologies are used to replace hardware servers hosting a common set of IoT functions with VNFs that can run as software on virtual machine. On top of appropriate virtualization infrastructure, VNFs of oneM2M service functions can be deployed anywhere in the network on-demand. NFV enables to slice an oneM2M common service layer in the form of multiple virtual IoT CSFs at the network edge. To achieve this, virtualization technologies allow the transformation of IoT CSFs from the common service layer to virtual IoT CSFs like software images. These virtual IoT CSFs include resources and service functions that have attributes specifically designed to meet the needs for IoT vertical markets such as smart building, industrial IoT, smart city, and, subsequently, create a network-as-a-service model for oneM2M edge computing.

## 6.4	Use Cases & Frameworks Mapping