Commit 7032111b authored by Marco Picone's avatar Marco Picone
Browse files

Merge branch 'Deployment_options_and_descriptions' into 'ESTIMED-D2.2-StableDraft'

Deployment options and descriptions

See merge request estimed/wp2/gr-mec-dec-050!6
parents e074b54e b3be0562
Loading
Loading
Loading
Loading
+79 −39
Original line number Diff line number Diff line
@@ -154,22 +154,44 @@ All rights reserved.<br />
    - [5.5.0	Description](#550description)
    - [5.5.1	User Premises Edge and oneM2M Integration](#551user-premises-edge-and-onem2m-integration)
- [6	MEC-oneM2M Architectural \& Use Case Mapping](#6mec-onem2m-architectural--use-case-mapping)
  - [6.0	Introduction](#60introduction)
  - [6.1	MEC Frameworks](#61mec-frameworks)
    - [6.1.1	ETSI MEC Framework](#611etsi-mec-framework)
    - [6.1.2	MEC Framework XXXX-2](#612mec-framework-xxxx-2)
    - [6.1.3	MEC Framework XXXX-3](#613mec-framework-xxxx-3)
    - [6.2	oneM2M Components](#62onem2m-components)
    - [6.2.1	oneM2M Framework XXXX-1](#621onem2m-framework-xxxx-1)
    - [6.2.2	oneM2M Framework XXXX-2](#622onem2m-framework-xxxx-2)
    - [6.2.3	oneM2M Framework XXXX-3](#623onem2m-framework-xxxx-3)
  - [6.3	Use Cases \& Frameworks Mapping](#63use-cases--frameworks-mapping)
    - [6.3.x](#63x)
      - [6.3.x.1 Use Case Driving Deployment](#63x1-use-case-driving-deployment)
        - [Table 6.3.x.1-1 – Operational Requirements and Platform Support for Autonomous Vehicle with Continuous Edge Computing](#table-63x1-1--operational-requirements-and-platform-support-for-autonomous-vehicle-with-continuous-edge-computing)
    - [6.3.x	Smart Warehouse Automation](#63xsmart-warehouse-automation)
      - [6.3.x.1		Use case Driven Deployment](#63x1use-case-driven-deployment)
        - [Table 6.3.x.1-1 – Operational Requirements and Platform Support for Smart Warehouse Automation](#table-63x1-1--operational-requirements-and-platform-support-for-smart-warehouse-automation)
  - [6.1	Introduction](#61introduction)
  - [6.2	MEC Frameworks](#62mec-frameworks)
    - [6.3	oneM2M Components](#63onem2m-components)
    - [6.3.1	Introduction to oneM2M](#631introduction-to-onem2m)
    - [6.3.2	oneM2M Architecture](#632onem2m-architecture)
    - [6.3.3    oneM2M Architecture Common Service Layer Functions](#633----onem2m-architecture-common-service-layer-functions)
    - [6.3.4  Mapping between MEC and oneM2M](#634--mapping-between-mec-and-onem2m)
    - [6.3.5  Virtualization of oneM2M Common Service Layer functions](#635--virtualization-of-onem2m-common-service-layer-functions)
  - [6.4	Use Cases \& Frameworks Mapping](#64use-cases--frameworks-mapping)
    - [6.4.1 Deployment Options](#641-deployment-options)
      - [6.4.1.1 Option A: deploy the oneM2M as a cloud, MEC as an edge](#6411-option-a-deploy-the-onem2m-as-a-cloud-mec-as-an-edge)
      - [6.4.1.2 Option B: oneM2M and MEC as an edge with the different physical node](#6412-option-b-onem2m-and-mec-as-an-edge-with-the-different-physical-node)
      - [6.4.1.3 Option C: oneM2M and MEC in the same physical edge node](#6413-option-c-onem2m-and-mec-in-the-same-physical-edge-node)
      - [6.4.1.4 Option D: oneM2M and MEC are tightly coupled in the same edge node](#6414-option-d-onem2m-and-mec-are-tightly-coupled-in-the-same-edge-node)
    - [6.4.2 Autonomous Vehicle with Continuous Edge Computing](#642-autonomous-vehicle-with-continuous-edge-computing)
      - [6.4.2.1 Use Case Driving Deployment](#6421-use-case-driving-deployment)
        - [Table 6.4.2.1-1 – Operational Requirements and Platform Support for Autonomous Vehicle with Continuous Edge Computing](#table-6421-1--operational-requirements-and-platform-support-for-autonomous-vehicle-with-continuous-edge-computing)
    - [6.4.3 Vulnerable Road Users](#643-vulnerable-road-users)
      - [6.4.3.1 Use Case Driving Deployment](#6431-use-case-driving-deployment)
        - [Table 6.4.3.1-1 – Operational Requirements and Platform Support for Vulnerable Road Users](#table-6431-1--operational-requirements-and-platform-support-for-vulnerable-road-users)
    - [6.4.4 Swarm-based Autonomous Ant Delivery Optimization](#644-swarm-based-autonomous-ant-delivery-optimization)
      - [6.4.4.1 Use Case Driving Deployment](#6441-use-case-driving-deployment)
        - [Table 6.4.4.1-1 – Operational Requirements and Platform Support for Swarm-based Autonomous Ant Delivery Optimization](#table-6441-1--operational-requirements-and-platform-support-for-swarm-based-autonomous-ant-delivery-optimization)
    - [6.4.5	Smart Warehouse Automation](#645smart-warehouse-automation)
      - [6.4.5.1		Use case Driven Deployment](#6451use-case-driven-deployment)
        - [Table 6.4.5.1-1 – Operational Requirements and Platform Support for Smart Warehouse Automation](#table-6451-1--operational-requirements-and-platform-support-for-smart-warehouse-automation)
    - [6.4.6	Industrial Digital Twins](#646industrial-digital-twins)
      - [6.4.6.1		Use case Driven Deployment](#6461use-case-driven-deployment)
        - [Table 6.4.6.1-1 – Operational Requirements and Platform Support for Industrial Digital Twins](#table-6461-1--operational-requirements-and-platform-support-for-industrial-digital-twins)
    - [6.4.7	Assisted Manoeuvring for Autonomous Ships](#647assisted-manoeuvring-for-autonomous-ships)
      - [6.4.7.1		Use case Driven Deployment](#6471use-case-driven-deployment)
        - [Table 6.4.7.1-1 – Operational Requirements and Platform Support for Assisted Manoeuvring for Autonomous Ships](#table-6471-1--operational-requirements-and-platform-support-for-assisted-manoeuvring-for-autonomous-ships)
    - [6.4.8	Smart Metaverse Shopping with Edge-AI and Cloud-IoT Integration](#648smart-metaverse-shopping-with-edge-ai-and-cloud-iot-integration)
      - [6.4.8.1		Use case Driven Deployment](#6481use-case-driven-deployment)
        - [Table 6.4.8.1-1 – Operational Requirements and Platform Support for Smart Metaverse Shopping](#table-6481-1--operational-requirements-and-platform-support-for-smart-metaverse-shopping)
    - [6.4.9	Future Homes](#649future-homes)
      - [6.4.9.1		Use case Driven Deployment](#6491use-case-driven-deployment)
        - [Table 6.4.9.1-1 – Operational Requirements and Platform Support for Future Homes](#table-6491-1--operational-requirements-and-platform-support-for-future-homes)
- [7	New Internetworking Proposed Recommendations Based on Use Cases](#7new-internetworking-proposed-recommendations-based-on-use-cases)
  - [7.1	XXX](#71xxx)
- [Annex A: Title of annex](#annex-a-title-of-annex)
@@ -552,44 +574,62 @@ This section provides a synthesis of the previously identified use cases in sect
The selection of the most appropriate deployment option for each use case is guided by insights from the ETSI white paper[i.2], where 4 deployment options are mentioned for interworking of oneM2M and MEC technologies.

#### 6.4.1.1 Option A: deploy the oneM2M as a cloud, MEC as an edge
- This deployment presents the IoT platform itself on the cloud side.
- 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.
This option captures the MEC and oneM2M standard as they exist at the start of the effort to integrate both standards with only changes to support MEC devices and oneM2M devices. This can be done by developing applications that use the oneM2M Mca reference point and the MEC Mp1 reference point. 
- An oneM2M IN-CSE is deployed in the cloud and an IN-AE represents the application that is connected to the IN-CSE.
- The edge gateway connects IoT devices to the MEC framework to provide services to the devices.
- The MEC gateway is connected to the IN-CSE through an MEC IPE. The IN-CSE represents the MEC platform and devices that are registered to the MEC platform using the MEC IPE.  
  - devices may use MEC services and APIs (Mp1) with support from the MEC IPE hosted as an MEC APP.
  - devices may use non-MEC services, e.g. UPC-UA devices, using a 3rd party IPE hosted as an MEC APP.
  - devices may use oneM2M services through a Mca proxy. This Mca proxy can be hosted as an MEC APP. These oneM2M devices can also take advantage of exposed MEC services.

![6.4.1.1-1. Deployment Option A.](/media/OptionA.png)

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.
- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required.


![Figure 6.4.1.1-1: Deployment Option A](/media/OptionA.png)
**Figure 6.4.1.1-1: Deployment Option A**
The figures 6.4.1.1-1 illustrates deployment option A where the oneM2M IN-CSE deployment is on a cloud Node and where the communication between non-oneM2M devices and the IN-CSE is provided by an IPE running as a MEC application.

#### 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.
- Compared to Option A, both oneM2M and MEC exist on edge nodes, allowing for data and information exchange to be performed locally, possibly resulting in faster processing
- Although oneM2M IoT service providers and ETSI MEC entities are different, this scenario can still be used in the early edge computing market.
This option enhances the performance of the edge deployment by introducing additional services through the integration of a oneM2M MN-CSE. An oneM2M IPE is added that interworks MEC services and devices.  This can be realized using an exemplar setup consisting of one platform with an MEC framework and a second platform hosting the MN-CSE. 
- An oneM2M IN-CSE is deployed in the cloud and an IN-AE represents the application that is connected to the IN-CSE.
- The edge consists of the MEC platform that connects devices using MEC apis.
- The edge also includes an oneM2M MN-CSE that offers services to oneM2M devices and other types of devices.
  - The MEC IPE is deployed with the oneM2M platform or the MEC platform.
  - Additional services can be exposed by oneM2M AEs as such interworking with other devices, swarm computing and federated learning. 
  - These additional oneM2M AEs can be deployed on either the oneM2M platform or the MEC platform.

![6.4.1.2-1. Deployment Option B.](/media/OptionB.png)

![Figure 6.4.1.2-1: Deployment Option B](/media/OptionB.png)
**Figure 6.4.1.2-1: Deployment Option B**
This deployment uses oneM2M IoT service providers and ETSI MEC entities that may be different, this scenario can still be used in the early edge computing market by using the same custom MEC IPE that was defined in option A.  Additionally, new capabilities from oneM2M can be delpoyed to support compute intensive services.
- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required.

The figure 6.4.1.2-1  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.
- A Service Level Agreement between the platform providers is required, and both platforms support dynamic deployment to various edge nodes.
This option focuses on integrating the services of oneM2M and ETSI MEC. This achieves better performance by combining the oneM2M MN-CSE and the MEC framework. The MEC IPE is no longer needed because the oneM2M and MEC framework are integrated. 
- An oneM2M IN-CSE is deployed in the cloud and an IN-AE represents the application that is connected to the IN-CSE.
- The edge consists of the MEC platform that connects devices using MEC apis and the oneM2M MN-CSE to support a variety to devices.
- The MEC IPE is replaced with new APIs that take advantage of new standards work from ETSI MEC and oneM2M. 

![Figure 6.4.1.3-1: Deployment Option C](/media/OptionC.png)
**Figure 6.4.1.3-1: Deployment Option C**
![6.4.1.3-1. Deployment Option C.](/media/OptionC.png)

In this scenario, oneM2M and MEC platforms are installed and operated on the same physical edge node. This can significantly improve services by eliminating unnecessary data movement and information exchange. It also supports customizing the system to take advantage of high compute platform capabilities that may be needed for federated learning or swarm computing.
- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required.

The figure 6.4.1.3-1 illustrate deployment option C where oneM2M IN-CSE deployed on Cloud, MN-CSE and MEC platform are deployed on the same edge node.

#### 6.4.1.4 Option D: oneM2M and MEC are tightly coupled in the same edge node
- This scenario involves oneM2M and MEC platforms being physically coupled through APIs, allowing for mutual interworking.
- The oneM2M platform is recognized as an MEC application, utilizing all functions provided by MEC to provide a 100% edge computing environment.
- 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.
This option attempts to simplify the services by offered by ETSI MEC and oneM2M by fully integrating the services. 
- An oneM2M IN-CSE is deployed in the cloud and an IN-AE represents the application that is connected to the IN-CSE.
- The edge consists of the MEC platform that connects devices using MEC apis and the oneM2M MN-CSE to support a variety to devices. 
- MEC exposes APIs that integrate the oneM2M services. 

![Figure 6.4.1.4-1: Deployment Option D](/media/OptionD.png)
**Figure 6.4.1.4-1: Deployment Option D**
![6.4.1.3-1. Deployment Option D.](/media/OptionD.png)

In this scenario oneM2M integrates to MEC and offers services that support directly supporting providing data source, processing, and multi-access networking.
- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required.

The figure 6.4.1.4-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

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).
+101 KiB (117 KiB)
Loading image diff...
+121 KiB (140 KiB)
Loading image diff...
+119 KiB (138 KiB)
Loading image diff...
+73.3 KiB (90.7 KiB)
Loading image diff...
Loading