@@ -458,7 +458,7 @@ This architecture is composed of the following entities:
-*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
-*Node*: Logical equivalent of a physical (or possibly virtualized) server or device
-*IPE*: 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)
@@ -482,7 +482,16 @@ These oneM2M services are defined so that application developers can focus on ap
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
### 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.
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).
### 6.3.5 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.
