update figures for deployment options

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.2-1. Multi-access edge system reference architecture [Todo:Add Reference].](/media/mec_arch_6_1.png)

**Figure 6.2-1: ETSI MEC architecture**

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:

- Radio Network Information API (MEC-012)

- Traffic Management API (MEC-015)

- Device Application Interface (MEC-016)

- Application Mobility Service API (MEC-021)

- WLAN Information API (MEC-028)

- Fixed Access Information API (MEC-029)

- V2X Information API (MEC-030)

## 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 in section 5 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. 

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

- This is one of the most common deployment scenarios that use cloud based IoT platforms and edge computing.

- Although some of the benefits of edge computing can be achieved through network and processing, the advantages of 100% edge computing are not fully utilized because the cloud remains the final endpoint where data is stored and managed.

<img src="/media/OptionA.1.png" width="900" height="500">

<img src="/media/OptionA.2.png" width="900" height="500">

<img src="/media/OptionA.png" width="900" height="500">

The following figures X illustrate deployment option A where oneM2M IN-CSE deployment is on the cloud Node and where the communication between  Iot applications (MN-AE) and multiple oneM2M devices is supported and managed by oneM2M platform. The choice to utilize MN-CSE at fog node is upto the scenario.

The following figures X illustrate deployment option A where oneM2M IN-CSE deployment is on the cloud Node and where the communication between  Iot applications (MN-AE) and multiple oneM2M devices is supported and managed by oneM2M platform. For specific Iot data processing, MEC services can be utilized using an IPE hosted on Edge. 

#### 6.4.1.2 Option B: oneM2M and MEC as an edge with the different physical node

- This option presents oneM2M and MEC deployed as edge nodes but located on different physical edge nodes.

<img src="/media/OptionB.png" width="900" height="500">

The following figure X illustrate deployment option B where oneM2M IN-CSE deployed on Cloud, MN-CSE is deployed at separate edge node than MEC platform. The MN-CSE acting as an Edge application for registration with MEC platform deployed on differnt edge node, for platforms discovery and communication additional logics and network configurations (DNS settings) should be performed.

The following figure X illustrate deployment option B where oneM2M IN-CSE deployed on Cloud, MN-CSE is deployed at separate edge node than MEC platform. The MN-CSE acting as an Edge application for registration with MEC platform deployed on differnt edge node, for MEC platform discovery and communication additional logics and network configurations (DNS settings) should be performed at MN-CSE.

#### 6.4.1.3 Option C: oneM2M and MEC in the same physical edge node

- In this scenario, oneM2M and MEC platforms are installed and operated on the same physical edge node, which can significantly improve service by eliminating unnecessary data and information exchange.

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

<img src="/media/OptionD.1.png" width="900" height="500">

<img src="/media/OptionD.2.png" width="900" height="500">

<img src="/media/OptionD.png" width="900" height="500">

The following figure X.1 illustrate deployment option D where oneM2M IN-CSE deployed on Cloud and MN-CSE can be added as a MEC service inside the MEC platform, for this case the service has to be MEC complient and can be accessible using mp1 interface via MEC platform. In other case, the regitrtaion of MN-CSE (as MEC application) with MEC platform should be done based on MEC011 application registration process.   

The following figure X.1 illustrate deployment option D where oneM2M IN-CSE deployed on Cloud, MN-CSE and MEC platform are deployed on the same edge node. In this case, the regitrtaion of MN-CSE (as MEC application) with MEC platform should be done based on MEC011 application registration process.   

### 6.4.2 Autonomous Vehicle with Continuous Edge Computing

#### 6.4.2.1 Use Case Driving Deployment

### 6.4.3 Vulnerable Road Users

#### 6.4.3.1 Use Case Driving Deployment

he “Vulnerable Road Users” (VRU) use case shares deployment characteristics with the “Autonomous Vehicle with Continuous Edge Computing” scenario, where achieving ultra-low latency, localized processing, and context awareness is critical. This is necessary to effectively process data from nearby roadside units, sensors mounted on traffic signals, and other urban infrastructure to enable real-time analytics and immediate response. To support this, specific processing tasks can be offloaded to oneM2M Edge Instances (MN-CSEs) operating close to the data sources. As vehicles and VRUs dynamically move across different geographic zones, coordination across multiple MEC nodes becomes essential. Therefore, a centralized IN-CSE deployed in the cloud is ideal for maintaining global context, orchestrating and synchronizing edge instances, and ensuring uninterrupted service continuity. Meanwhile, MN-CSEs should be deployed close to the edge to provide low-latency decision support

The “Vulnerable Road Users” (VRU) use case shares deployment characteristics with the “Autonomous Vehicle with Continuous Edge Computing” scenario, where achieving ultra-low latency, localized processing, and context awareness is critical. This is necessary to effectively process data from nearby roadside units, sensors mounted on traffic signals, and other urban infrastructure to enable real-time analytics and immediate response. To support this, specific processing tasks can be offloaded to oneM2M Edge Instances (MN-CSEs) operating close to the data sources. As vehicles and VRUs dynamically move across different geographic zones, coordination across multiple MEC nodes becomes essential. Therefore, a centralized IN-CSE deployed in the cloud is ideal for maintaining global context, orchestrating and synchronizing edge instances, and ensuring uninterrupted service continuity. Meanwhile, MN-CSEs should be deployed close to the edge to provide low-latency decision support

In the following table, we will consider all the relevant operational requirement for this use case.