WARNING! Gitlab maintenance operation scheduled for Monday, 20 April between 12:00 and 14:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.
@@ -384,18 +384,17 @@ In this extension, the non-MEC node is realized as a Customer Premises Edge devi
# 6 MEC-oneM2M Architectural & Use Case Mapping
## 6.0 Introduction
## 6.1 Introduction
This clause provides an analysis of the main reference architectures and characteristics of MEC and oneM2M , highlighting their core functionalities and how they complement each other in the context of Edge-IoT deployments. For each of the identified use cases, the clause maps the relevant architectural elements and functionalities from both, illustrating how they contribute to the scenario. It also identifies potential new features or enhancements that could further support the use case. Where overlapping functionalities exist across use cases, these are acknowledged and will be further analyzed in the following clause 7, which focuses on deriving structured application requirements and identifying gaps for future standardization efforts.
## 6.1 MEC Frameworks
## 6.2 MEC Frameworks
This section provides an overview of the MEC framework, detailing its components, services, and how it supports Edge-based applications.
### 6.1.1 ETSI MEC Framework
ETSI MEC framework offers application developers and content providers, cloud-computing capabilities at the edge of the network, in an environment characterized by ultra-low latency and high bandwidth together with real-time access to network information that can be leveraged by applications
![6.1.1-1. Multi-access edge system reference architecture [Todo:Add Reference].](/media/mec_arch_6_1.png)
![6.2-1. Multi-access edge system reference architecture [Todo:Add Reference].](/media/mec_arch_6_1.png)
Figure 6-1 depicts the generic multi-access edge system reference architecture. The MEC framework defined by ETSI includes a standardized architecture with the following key components:
Figure 6.2-1 depicts the generic multi-access edge system reference architecture. The MEC framework defined by ETSI includes a standardized architecture with the following key components:
- MEC Orchestrator: manages resources and coordinates MEC operations.
- MEC Host: includes the MEC platform, MEC applications, and the underlying virtualization infrastructure.
@@ -427,15 +426,7 @@ Some examples of MEC service APIs include:
All APIs are described using the OpenAPI Specification (OAS), ensuring consistency and ease of integration across platforms.
### 6.1.2 MEC Framework XXXX-2
Description of the target MEC Framework ….
### 6.1.3 MEC Framework XXXX-3
Description of the target MEC Framework ….
### 6.2 oneM2M Components
### 6.3 oneM2M Components
This section provides an overview of the MEC framework, detailing its components, services, and how it supports Edge-based applications.
@@ -451,9 +442,12 @@ Description of the target oneM2M Framework ….
Description of the target oneM2M Framework ….
## 6.3 Use Cases & Frameworks Mapping
## 6.4 Use Cases & Frameworks Mapping
This section provides a synthesis of the previously identified use cases and the architectural features of the MEC and oneM2M frameworks. It maps each use case to the relevant framework components and functionalities, showcasing how MEC and oneM2M support specific operational needs. The mapping highlights the alignment between the frameworks and the identified scenarios, while also pointing out areas where enhancements or additional integration mechanisms may be required to better support cross-domain use cases.
This section provides a synthesis of the previously identified use cases and the architectural features of the MEC and oneM2M frameworks. It maps each use case to the relevant framework components and functionalities, showcasing how MEC and oneM2M support specific operational needs. The mapping highlights the alignment between the frameworks and the identified scenarios, while also pointing out areas where enhancements or additional integration mechanisms may be required to better support cross-domain use cases. Additionally, the selection of the most appropriate deployment option for each use case is guided by insights from the ETSI white paper: [Todo: Add reference]
### 6.4.1 Deployment Options
The selection of the most appropriate deployment option for each use case is guided by insights from the ETSI white paper [Todo: Add reference], where 4 deployment options are mentioned for interworking of oneM2M and MEC technologies. The figure xx depict the following 4 deployment options:
Option A: deploy the oneM2M as a cloud, MEC as an edge
- This deployment presents the IoT platform itself on the cloud side.
@@ -475,44 +469,44 @@ Option D: oneM2M and MEC are tightly coupled in the same edge node
- The MEC platform can directly provide data source, processing, and multi-access networking by hosting oneM2M as an application.
- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required.
### 6.3.x
### 6.4.x Autonomous Vehicle with Continuous Edge Computing
Mapping of oneM2M and MEC Framework to the Use Case
#### 6.3.x.1 Use Case Driving Deployment
#### 6.4.x.1 Use Case Driving Deployment
For the “Autonomous Vehicle with Continuous Edge Computing” use case, achieving ultra-low latency, context awareness, and localized processing is essential to handle data from nearby sources and enable real-time analytics. To meet these requirements, certain tasks can be offloaded to oneM2M Edge Instances (MN-CSEs).
As autonomous vehicles move across MEC zones, orchestration and synchronization across multiple oneM2M platforms is required. For this, a centralized IN-CSE deployed in the cloud is suitable to maintain global context, coordinate edge instances, and ensure seamless service continuity.
In the following table, we will consider all the relevant operational requirement for this use case.
##### Table 6.3.x.1-1 – Operational Requirements and Platform Support for Autonomous Vehicle with Continuous Edge Computing
##### Table 6.4.x.1-1 – Operational Requirements and Platform Support for Autonomous Vehicle with Continuous Edge Computing
| Operational Requirement | Support in MEC | Support in oneM2M |
| Up and running IoT platform | Not applicable | Supported: oneM2M platform can be deployed at cloud or any edge node |
| Registration of vehicles, IoT devices, and applications | Not applicable | Supported: oneM2M features provide CSFs to register both devices and AEs (Application Entities) |
| Data collection from IoT Devices (Vehicle sensors, Road sensors, LIDAR) | Not applicable | Supported via oneM2M’s Common Service Layer using Mca interfaces for data exchange |
| Instantiate of MN-CSE on Edge Node | MEC provides the infrastructure to host oneM2M as a service producing MEC application (using Mp1 interface or as a new MEC service inside the MEC Platform. MEC IoT API (MEC046) enables registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a Common Services Function (CSF) to integrate with the MEC platform |
| Instantiate of MN-CSE on Edge Node | MEC provides the infrastructure to host oneM2M as a service producing MEC application (using Mp1 interface or as a new MEC service inside the MEC Platform. MEC IoT API (MEC033) enables registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a Common Services Function (CSF) to integrate with the MEC platform |
| Instantiation of AE on Edge Node | AE can be instantiated as MEC Application on MEC Host | Supported: oneM2M platform needs to include a Common Services Function (CSF) to instantiate an AE as MEC application
### 6.3.x Smart Warehouse Automation
### 6.4.x Smart Warehouse Automation
Mapping of oneM2M and MEC Framework to the Use Case.
#### 6.3.x.1 Use case Driven Deployment
#### 6.4.x.1 Use case Driven Deployment
The architecture integrates a centralized oneM2M IN-CSE, responsible for managing infrastructure-level data (sensors, tags, operational policies), and multiple MN-CSEs deployed at the MEC edge, enabling real-time, latency-sensitive decision-making close to the action. For time-critical events such as rerouting AGVs, responding to hazards, or optimizing resource allocation, processing tasks are offloaded to MEC-hosted MN-CSEs. These instances provide ultra-low-latency data processing
In the following table, we will consider all the relevant operational requirement for this use case.
##### Table 6.3.x.1-1 – Operational Requirements and Platform Support for Smart Warehouse Automation
##### Table 6.4.x.1-1 – Operational Requirements and Platform Support for Smart Warehouse Automation
| Operational Requirement | Support in MEC | Support in oneM2M |
| Warehouse IoT platform deployment | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud or control center |
| Registration of sensors, AGVs, and applications | Not required | Supported: oneM2M features provide CSFs to register both devices and AEs (Application Entities) |
| Collection of environmental and telemetry data | Not required | Supported via oneM2M’s Common Service Layer and Mca interfaces |
| Instantiate of MN-CSE on Edge Node | MEC provides the infrastructure to host oneM2M as a service producing MEC application (using Mp1 interface or as a new MEC service inside the MEC Platform. MEC IoT API (MEC046) enables registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a Common Services Function (CSF) to integrate with the MEC platform |
| Instantiate of MN-CSE on Edge Node | MEC provides the infrastructure to host oneM2M as a service producing MEC application (using Mp1 interface or as a new MEC service inside the MEC Platform. MEC IoT API (MEC033) enables registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a Common Services Function (CSF) to integrate with the MEC platform |
| Instantiate of AE (e.g., AGV controller, sensor manager) on Edge Node | AE can be instantiated as MEC Application on MEC Host | Supported: oneM2M platform needs to include a Common Services Function (CSF) to instantiate an AE as MEC application |
| Low-latency control for AGVs and asset tracking | Supported: MEC apps handle time-sensitive operations with minimal delay | Supported: MN-CSE enables fast coordination through subscriptions, notifications, and data routing |
| Offloading low latency tasks of IoT Platform for real time data processing | Not applicable | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. |
