This architecture is composed of the following entities:
-*Reference Point*: One or more interfaces - Mca, Mcn, Mcc and Mcc’ (between 2 service providers)
-*Common Services Entity (CSE)*: Provides the set of "service functions" that are common to the IoT domains
-*Application Entity (AE)*: Provides application logic for the end-to-end IoT solutions
-*Application Entity (AE)*: Represents application logic for the end-to-end IoT solutions. This includes device firmware, gateway logic or backend applications
-*Network Services Entity*: Provides services to the CSEs beyond the data transport
-*Node*: Logical equivalent of a physical (or possibly virtualized) server or device
@@ -466,6 +465,24 @@ In particular, oneM2M defines several different kinds of nodes, which are named
In addition, the oneM2M architecture supports another type of node, the so-called “Non-oneM2M Node” (NoDN), not shown in the figure above. 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 oneM2M Common Service Layer Functions
From a functional perspective, oneM2M has defined fourteen common service functions (CSFs) as shown in the figure below. These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies.
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.
### 6.3.4 Virtualization of oneM2M Common Service Layer functions
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.
