diff --git a/GR_MEC-DEC_050.md b/GR_MEC-DEC_050.md index f8f5d699c54fb53060a85eeead092ad65a30678b..257e7fef9770a77dc9def8936f1bc9555eaed836 100644 --- a/GR_MEC-DEC_050.md +++ b/GR_MEC-DEC_050.md @@ -1,9 +1,8 @@ --- -Title: Multi-access Edge Computing (MEC); ESTIMED Use Cases & Recommendations +Title: Multi-access Edge Computing (MEC);
ESTIMED Use Cases & Recommendations Spec Number: MEC-DEC 050 -Version: v4.0.4 -Date: 2025-10 -Release: 5 +Version: v4.1.1 +Date: 2025-11 Work Item: DGR/MEC-DEC050EstimedRec keywords: M2M, MEC, oneM2M Copyright Year: 2025 @@ -11,15 +10,11 @@ Long ISG Name: Multi-access Edge Computing Short ISG Name: MEC --- -# Contents - -
- # Intellectual Property Rights Essential patents -IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database](https://ipr.etsi.org/). +IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _\"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards\"_, which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database](https://ipr.etsi.org/). Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. @@ -27,7 +22,7 @@ Trademarks The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks. -**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM**® and the GSM logo are trademarks registered and owned by the GSM Association. +**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association. # Foreword @@ -69,24 +64,41 @@ References are either specific (identified by date of publication and/or edition The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader\'s understanding but are not required for conformance to the present document. -- [i.1] [ETSI GS MEC 003: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/04.01.01_60/gs_mec003v040101p.pdf) \"Multi-access Edge Computing (MEC); Framework and Reference Architecture\". -- [i.2] [ETSI White Paper No. #59: ](https://www.etsi.org/images/files/ETSIWhitePapers/ETSI-WP59-Enabling-Multi-access-Edge-Computing-in-iot.pdf) \"Enabling Multi-access Edge Computing in Internet-of- Things: how to deploy ETSI MEC and oneM2M\". -- [i.3] [ESTIMED Project Official Website](https://estimed.etsi.org/). -- [i.4] [ETSI GS MEC 009: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/009/03.01.01_60/gs_MEC009v030101p.pdf) \"Multi-access Edge Computing (MEC); General principles, patterns and common aspects of MEC Service APIs\". -- [i.5] [ETSI GS MEC 010-2: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/01002/02.02.01_60/gs_MEC01002v020201p.pdf) \"Multi-access Edge Computing (MEC); MEC Management; Part 2: Application lifecycle, rules and requirements management\". -- [i.6] [ETSI GS MEC 011: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/011/03.01.01_60/gs_MEC011v030101p.pdf) \"Multi-access Edge Computing (MEC); Edge Platform Application Enablement\". -- [i.7] [ETSI GS MEC-013: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/03.01.01_60/gs_MEC013v030101p.pdf) \"Multi-access Edge Computing (MEC); Location API\". -- [i.8] [ETSI GS MEC 012: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/02.01.01_60/gs_mec012v020101p.pdf) \"Multi-access Edge Computing (MEC); Radio Network Information API\". -- [i.9] [ETSI GS MEC 015: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/015/03.01.01_60/gs_MEC015v030101p.pdf) \"Multi-access Edge Computing (MEC); Traffic Management APIs\". -- [i.10] [ETSI GS MEC 016: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/016/03.01.01_60/gs_MEC016v030101p.pdf) \"Multi-access Edge Computing (MEC); Device application interface\". -- [i.11] [ETSI GS MEC 021: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/021/03.01.01_60/gs_MEC021v030101p.pdf) \"Multi-access Edge Computing (MEC); Application Mobility Service API\". -- [i.12] [ETSI GS MEC 028: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/028/02.02.01_60/gs_MEC028v020201p.pdf) \"Multi-access Edge Computing (MEC); WLAN Access Information API\". -- [i.13] [ETSI GS MEC 029: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/029/02.01.01_60/gs_mec029v020101p.pdf) \"Multi-access Edge Computing (MEC); Fixed Access Information API\". -- [i.14] [ETSI GS MEC 030: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/030/03.01.01_60/gs_MEC030v030101p.pdf) \"Multi-access Edge Computing (MEC); V2X Information Services API\". -- [i.15] [ETSI GS MEC 033: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/033/03.01.01_60/gs_MEC033v030101p.pdf) \"Multi-access Edge Computing (MEC); IoT API\". -- [i.16] [ETSI GS MEC 040: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/040/03.02.01_60/gs_MEC040v030201p.pdf) \"Multi-access Edge Computing (MEC); Federation enablement APIs\". -- [i.17] [ETSI GS MEC 045: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/045/03.01.01_60/gs_MEC045v030101p.pdf) \"Multi-access Edge Computing (MEC); QoS Measurement API\". -- [i.18] [ETSI GS MEC 046: ](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/046/03.01.01_60/gs_MEC046v030101p.pdf) \"Multi-access Edge Computing (MEC); Sensor-sharing API\". +[i.1][ETSI GS MEC 003](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/04.01.01_60/gs_mec003v040101p.pdf): \"Multi-access Edge Computing (MEC); Framework and Reference Architecture\". + +[i.2][ETSI White Paper No. #59](https://www.etsi.org/images/files/ETSIWhitePapers/ETSI-WP59-Enabling-Multi-access-Edge-Computing-in-iot.pdf): \"Enabling Multi-access Edge Computing in Internet-of- Things: how to deploy ETSI MEC and oneM2M\". + +[i.3][ESTIMED Project Official Website](https://estimed.etsi.org/). + +[i.4][ETSI GS MEC 009](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/009/03.01.01_60/gs_MEC009v030101p.pdf): \"Multi-access Edge Computing (MEC); General principles, patterns and common aspects of MEC Service APIs\". + +[i.5][ETSI GS MEC 010-2](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/01002/02.02.01_60/gs_MEC01002v020201p.pdf): \"Multi-access Edge Computing (MEC); MEC Management; Part 2: Application lifecycle, rules and requirements management\". + +[i.6][ETSI GS MEC 011](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/011/03.01.01_60/gs_MEC011v030101p.pdf): \"Multi-access Edge Computing (MEC); Edge Platform Application Enablement\". + +[i.7][ETSI GS MEC-013](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/03.01.01_60/gs_MEC013v030101p.pdf): \"Multi-access Edge Computing (MEC); Location API\". + +[i.8][ETSI GS MEC 012](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/02.01.01_60/gs_mec012v020101p.pdf): \"Multi-access Edge Computing (MEC); Radio Network Information API\". + +[i.9][ETSI GS MEC 015](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/015/03.01.01_60/gs_MEC015v030101p.pdf): \"Multi-access Edge Computing (MEC); Traffic Management APIs\". + +[i.10][ETSI GS MEC 016](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/016/03.01.01_60/gs_MEC016v030101p.pdf): \"Multi-access Edge Computing (MEC); Device application interface\". + +[i.11][ETSI GS MEC 021](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/021/03.01.01_60/gs_MEC021v030101p.pdf): \"Multi-access Edge Computing (MEC); Application Mobility Service API\". + +[i.12][ETSI GS MEC 028](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/028/02.02.01_60/gs_MEC028v020201p.pdf): \"Multi-access Edge Computing (MEC); WLAN Access Information API\". + +[i.13][ETSI GS MEC 029](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/029/02.01.01_60/gs_mec029v020101p.pdf): \"Multi-access Edge Computing (MEC); Fixed Access Information API\". + +[i.14][ETSI GS MEC 030](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/030/03.01.01_60/gs_MEC030v030101p.pdf): \"Multi-access Edge Computing (MEC); V2X Information Services API\". + +[i.15][ETSI GS MEC 033](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/033/03.01.01_60/gs_MEC033v030101p.pdf): \"Multi-access Edge Computing (MEC); IoT API\". + +[i.16][ETSI GS MEC 040](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/040/03.02.01_60/gs_MEC040v030201p.pdf): \"Multi-access Edge Computing (MEC); Federation enablement APIs\". + +[i.17][ETSI GS MEC 045](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/045/03.01.01_60/gs_MEC045v030101p.pdf): \"Multi-access Edge Computing (MEC); QoS Measurement API\". + +[i.18][ETSI GS MEC 046](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/046/03.01.01_60/gs_MEC046v030101p.pdf): \"Multi-access Edge Computing (MEC); Sensor-sharing API\". # 3 Definition of terms, symbols and abbreviations @@ -105,7 +117,7 @@ Void. For the purposes of the present document, the following abbreviations apply: -`3D Three-dimensional` +`3D Three-Dimensional` `3GPP 3rd Generation Partnership Project` `5G Fifth Generation mobile networks` `ADN Application Dedicated Node` @@ -115,17 +127,17 @@ For the purposes of the present document, the following abbreviations apply: `AIS Automatic Identification System` `AI Artificial Intelligence` `API Application Programming Interface` -`API GW API Gateway` +`API GW API GateWay` `AR Augmented Reality` `ASN Application Service Node` `ASN-CSE Application Service Node - Common Services Entity` `AV Autonomous Vehicle` +`CNC Computer Numerical Control` +`CoAP Constrained Application Protocol` `CPE Customer Premises Equipment` `CPU Central Processing Unit` -`CSF Common Service Function` `CSE Common Services Entity` -`CNC Computer Numerical Control` -`CoAP Constrained Application Protocol` +`CSF Common Service Function` `DT Digital Twin` `FL Federated Learning` `GPU Graphics Processing Unit` @@ -137,7 +149,7 @@ For the purposes of the present document, the following abbreviations apply: `IN-CSE Infrastructure Node - Common Services Entity` `IoT Internet of Things` `IPE Interworking Proxy application Entity` -`LIDAR Light Detection and Ranging` +`LIDAR LIght Detection And Ranging` `MEP MEC Platform` `MN-AE Middle Node AE` `MN-CSE Middle Node - Common Services Entity` @@ -147,7 +159,7 @@ For the purposes of the present document, the following abbreviations apply: `NSE Network Services Entity` `OAS OpenAPI Specification` `OCF Open Connectivity Foundation` -`ROC Remote Operation Center` +`ROC Remote Operation Centre` `SAREF Smart Appliances REFerence` `VIM Virtualisation Infrastructure Manager` `VRU Vulnerable Road User` @@ -161,7 +173,7 @@ The ESTIMED project [\[i.3\]](#_ref_i.3) takes a use case-driven approach to ste Clause 5 delivers a domain-centric analysis of carefully selected use cases, illustrating the practical application of MEC and oneM2M in Edge-IoT environments. Use cases are categorized by relevant domains-such as Mobility, Industrial, and Maritime to reflect their specific operational contexts. Within each domain, use cases are thoroughly examined, covering the scenario context, involved stakeholders, technical and operational requirements, and key challenges. The clause also explores how MEC and oneM2M technologies contribute to overcoming these challenges. The use cases were identified through a structured engagement with stakeholders, facilitated by a dedicated form designed to capture all critical details consistently, including descriptions, actors, requirements, preconditions and postconditions, triggers, and interaction flows. -Building on this foundation, Clause 6 analyses the principal architectures of MEC and oneM2M frameworks, emphasizing their core functionalities and complementarity in supporting Edge-IoT deployments. For each use case, the clause maps relevant architectural components and capabilities from both frameworks, highlighting overlaps as well as identifying new features that could enhance support for specific scenarios. This mapping lays the groundwork for a comprehensive architectural reflection and technical assessment. +Building on this foundation, clause 6 analyses the principal architectures of MEC and oneM2M frameworks, emphasizing their core functionalities and complementarity in supporting Edge-IoT deployments. For each use case, the clause maps relevant architectural components and capabilities from both frameworks, highlighting overlaps as well as identifying new features that could enhance support for specific scenarios. This mapping lays the groundwork for a comprehensive architectural reflection and technical assessment. Clause 7 includes recommendations that enable a framework for the federation and orchestration of MEC and oneM2M instances. It also discusses how these capabilities can be used in Swarm Computing and Federated Learning applications. @@ -294,6 +306,8 @@ As mobile industrial assets like AGVs or modular production units relocate withi **Figure 5.3.4-1: Industrial Digital Twins supported and enabled for both IoT/IIoT interactions and edge-cloud computation by the integrated capabilities of oneM2M and ETSI MEC** + + ## 5.4 Maritime ### 5.4.1 Description @@ -314,6 +328,8 @@ As the vessel transits through different MASS zones, the proposed oneM2M/MEC arc **Figure 5.4.2-1: Scenario for assisted manoeuvring exploiting oneM2M and ETSI MEC** + + ## 5.5 Metaverse ### 5.5.1 Description @@ -332,6 +348,8 @@ If needed, IoT actuators in the real store - such as digital signage or voice as **Figure 5.5.2-1: Smart Shopping with Edge-AI and Cloud IoT Integration** + + ## 5.6 Future Home ### 5.6.1 Description @@ -348,11 +366,13 @@ In this extension reported in Figure 5.6.2-1, the non-MEC node is realized as a **Figure 5.6.2-1: Future Home user premises scenario with integrated Edge and IoT functionalities** + + # 6 MEC-oneM2M Architectural & Use Case Mapping ## 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 and provides, as part of Clause 7, a preliminary set of functional and technical recommendations for enabling a framework for federation and orchestration of MEC/oneM2M instances (e.g. handover, swarm computing and federated learning). +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 and provides, as part of clause 7, a preliminary set of functional and technical recommendations for enabling a framework for federation and orchestration of MEC/oneM2M instances (e.g. handover, swarm computing and federated learning). ## 6.2 MEC Frameworks @@ -364,6 +384,8 @@ ETSI MEC framework (schematically illustrated in Figure 6.2-1) offers applicatio **Figure 6.2-1: Multi-access edge system reference architecture** + + Figure 6.2-1 depicts the generic multi-access edge system reference architecture. The MEC framework defined by ETSI GS MEC 003 [\[i.1\]](#_ref_i.1) includes a standardized architecture with the following key functional elements: - MEC Orchestrator: manages resources and coordinates MEC operations. @@ -383,20 +405,20 @@ MEC also offers another reference architecture variant for MEC in NFV, MEC feder To support applications running at the edge, ETSI has developed a set of standardized service APIs. This local services environment is a flexible and extendable framework, as new services can be introduced by following the API guidelines in ETSI GS MEC 009 [\[i.4\]](#_ref_i.4), when creating new service APIs. These APIs allow applications to access useful network and context information through the Mp1 interface. MEC applications (API producer) can also register new services to MEP and consume/subscribe to existing ones through this interface. Transition from MEC Phase 1 to MEC Phase 4 (period 2024-2026) provided MEC service APIs include: -- Application lifecycle, rules and requirements management (ETSI GS MEC 010-2) [\[i.5\]](#_ref_i.5) -- Edge Platform Application Enablement (ETSI GS MEC 011) [\[i.6\]](#_ref_i.6) -- Location API (ETSI GS MEC-013) [\[i.7\]](#_ref_i.7) -- Radio Network Information API (ETSI GS MEC 012) [\[i.8\]](#_ref_i.8) -- Traffic Management API (ETSI GS MEC 015) [\[i.9\]](#_ref_i.9) -- Device Application Interface (ETSI GS MEC 016) [\[i.10\]](#_ref_i.10) -- Application Mobility Service API (ETSI GS MEC 021) [\[i.11\]](#_ref_i.11) -- WLAN Information API (ETSI GS MEC 028) [\[i.12\]](#_ref_i.12) -- Fixed Access Information API (ETSI GS MEC 029) [\[i.13\]](#_ref_i.13) -- V2X Information API (ETSI GS MEC 030) [\[i.14\]](#_ref_i.14) -- IoT API (ETSI GS MEC 033) [\[i.15\]](#_ref_i.15) -- Federation Enablement API (ETSI GS MEC 040) [\[i.16\]](#_ref_i.16) -- QoS Measurement API (ETSI GS MEC 045) [\[i.17\]](#_ref_i.17) -- Sensor Sharing API (ETSI GS MEC 046) [\[i.18\]](#_ref_i.18) +- Application lifecycle, rules and requirements management (ETSI GS MEC 010-2 [\[i.5\]](#_ref_i.5)) +- Edge Platform Application Enablement (ETSI GS MEC 011 [\[i.6\]](#_ref_i.6)) +- Location API (ETSI GS MEC-013 [\[i.7\]](#_ref_i.7)) +- Radio Network Information API (ETSI GS MEC 012 [\[i.8\]](#_ref_i.8)) +- Traffic Management API (ETSI GS MEC 015 [\[i.9\]](#_ref_i.9)) +- Device Application Interface (ETSI GS MEC 016 [\[i.10\]](#_ref_i.10)) +- Application Mobility Service API (ETSI GS MEC 021 [\[i.11\]](#_ref_i.11)) +- WLAN Information API (ETSI GS MEC 028 [\[i.12\]](#_ref_i.12)) +- Fixed Access Information API (ETSI GS MEC 029 [\[i.13\]](#_ref_i.13)) +- V2X Information API (ETSI GS MEC 030 [\[i.14\]](#_ref_i.14)) +- IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) +- Federation Enablement API (ETSI GS MEC 040 [\[i.16\]](#_ref_i.16)) +- QoS Measurement API (ETSI GS MEC 045 [\[i.17\]](#_ref_i.17)) +- Sensor Sharing API (ETSI GS MEC 046 [\[i.18\]](#_ref_i.18)) All APIs are described using the OpenAPI Specification (OAS), ensuring consistency and ease of integration across platforms. @@ -417,22 +439,24 @@ oneM2M service layer can be integrated into devices, gateways, and servers. Figu **Figure 6.3.2-1: oneM2M architecture** + + This architecture is composed of the following entities: - _Common Services Entity (CSE)_: Provides the set of \"service functions\" that are common to multiple IoT domains. - _Application Entity (AE)_: Represents application logic for the end-to-end IoT solutions. This includes device firmware, gateway logic or backend applications. - _Interworking Proxy application Entity (IPE)_: A specialized AE that is used to interface between oneM2M and an external system. - _Network Services Entity_: Provides networking services to CSEs that are more than just data transport. -- _Node_: Logical equivalent of a physical (or possibly virtualized) server or device. +- _Node_: Logical equivalent of a physical (or possibly virtualised) server or device. oneM2M defines several different kinds of node, which are named based on their use by oneM2M. - _Infrastructure Node (IN)_: A Cloud provider / company server. It hosts a CSE that is referred to as an IN-CSE and may host AEs. There is exactly one IN in the Infrastructure Domain of each oneM2M Service Provider. - _Application Service Node (ASN)_: A Node that contains at least one AE co-located with a CSE (an ASN-CSE). - _Middle Node (MN)_: A Node that contains one CSE (an MN-CSE) and zero or more AEs. It is typically found in an Edge Server or Gateway box. -- _Application Dedicated Node (ADN)_:A Node that contains at least one AE but does not contain a CSE. +- _Application Dedicated Node (ADN)_: A Node that contains at least one AE but does not contain a CSE. -In addition, the oneM2M architecture defines one other type of node, the so-called “Non-oneM2M Node\" (NoDN), not shown in Figure 6.3.2-1. 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. +In addition, the oneM2M architecture defines one other type of node, the so-called \"Non-oneM2M Node\" (NoDN), not shown in Figure 6.3.2-1. 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: @@ -449,6 +473,8 @@ From a functional perspective, oneM2M has defined fourteen Common Service Functi **Figure 6.3.3-1: Common Service Functions** + + 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 Applications 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 designed 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. @@ -466,44 +492,44 @@ Architectural interworking between ETSI MEC and oneM2M is made possible by seein ### 6.3.5 Virtualisation of oneM2M Common Service Layer functions -Network Virtualisation allows IT service providers to develop an end-to-end digital service based on Network as a Service (NaaS). Network Function Virtualisation (NFV) targeted the oneM2M common service layer functions where the Virtualisation 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 Virtualisation 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, Virtualisation 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. +Network Virtualisation allows IT service providers to develop an end-to-end digital service based on Network as a Service (NaaS). Network Function Virtualisation (NFV) targeted the oneM2M common service layer functions where the Virtualisation 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 Virtualisation infrastructure, VNFs of oneM2M service functions can be deployed anywhere in the network on-demand. NFV enables to slice a oneM2M common service layer in the form of multiple virtual IoT CSFs at the network edge. To achieve this, Virtualisation 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. ## 6.4 Use Cases & Frameworks Mapping ### 6.4.1 Introduction to Use Cases & Frameworks Mapping -This clause provides a synthesis of the previously identified use cases in clause 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. +This clause provides a synthesis of the previously identified use cases in clause 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. The selection of the most appropriate deployment option for each use case is guided by insights from the ETSI white paper [\[i.2\]](#_ref_i.2), where 4 deployment options are mentioned for interworking of oneM2M and MEC technologies. ### 6.4.2 Deployment Options -The selection of the most appropriate deployment option for each use case is guided by insights from the ETSI white paper [\[i.2\]](#_ref_i.2), where 4 deployment options are mentioned for interworking of oneM2M and MEC technologies. - #### 6.4.2.1 Option A: deploy the oneM2M as a cloud, MEC as an edge 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 (see Figure 6.4.2.1-1). 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. +- A 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. +- 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. ![Figure 6.4.2.1-1: Deployment Option A](media/OptionA.png) **Figure 6.4.2.1-1: Deployment Option A** -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. + +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 needed. #### 6.4.2.2 Option B: oneM2M and MEC as an edge with the different physical node -This option illustrated in Figure 6.4.2.2-1 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 MEC framework and a second platform hosting the MN-CSE: +This option illustrated in Figure 6.4.2.2-1 enhances the performance of the edge deployment by introducing additional services through the integration of a oneM2M MN-CSE. A oneM2M IPE is added that interworks MEC services and devices. This can be realized using an exemplar setup consisting of one platform with 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. +- A 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. -- The edge also includes an oneM2M MN-CSE that offers services to oneM2M devices and other types of devices. +- The edge also includes a 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. @@ -512,15 +538,17 @@ This option illustrated in Figure 6.4.2.2-1 enhances the performance of the edge **Figure 6.4.2.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 deployed to support compute intensive services: -- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is required. +- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is needed. #### 6.4.2.3 Option C: oneM2M and MEC in the same physical edge node This option focuses on integrating the services of oneM2M and ETSI MEC as reported in Figure 6.4.2.3-1. 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. +- A 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. @@ -528,15 +556,17 @@ This option focuses on integrating the services of oneM2M and ETSI MEC as report **Figure 6.4.2.3-1: Deployment Option C** + + 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. +- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is needed. #### 6.4.2.4 Option D: oneM2M and MEC are tightly coupled in the same edge node This option attempts to simplify the services offered by ETSI MEC and oneM2M by fully integrating the services as schematically illustrated in Figure 6.4.2.4-1: -- An oneM2M IN-CSE is deployed in the cloud and an IN-AE represents the application that is connected to the IN-CSE. +- A 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 and the oneM2M MN-CSE to support a variety of devices. - MEC exposes APIs that integrate the oneM2M services. @@ -544,28 +574,32 @@ This option attempts to simplify the services offered by ETSI MEC and oneM2M by **Figure 6.4.2.4-1: Deployment Option D** + + In this scenario oneM2M integrates to MEC and offers services that support directly 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. +- A standard document providing interoperability and interworking between the two platforms, oneM2M and ETSI MEC, is needed. ### 6.4.3 Autonomous Vehicle with Continuous Edge Computing #### 6.4.3.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. +As autonomous vehicles move across MEC zones, orchestration and synchronization across multiple oneM2M platforms is needed. 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 Table 6.4.3.1-1, all the relevant operational requirements for this use case are considered. **Table 6.4.3.1-1: Operational Requirements and Platform Support for Autonomous Vehicle with Continuous Edge Computing** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| -| Up and running IoT platform | Not Required | Supported: oneM2M platform can be deployed at cloud or any edge node | +| Up and running IoT platform| Not Required | Supported: oneM2M platform can be deployed at cloud or any edge node | | Registration of vehicles, IoT devices, and applications | Not Required | Supported: oneM2M features provide Common Service Functions (CSFs) to register both devices and Application Entities (AEs) | | Data collection from IoT Devices (Vehicle sensors, Road sensors, LIDAR) | Not Required | 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033) [\[i.15\]](#_ref_i.15) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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 CSF to instantiate an AE as MEC application | +
+ ### 6.4.4 Vulnerable Road Users @@ -577,13 +611,15 @@ In Table 6.4.4.1-1, all the relevant operational requirements for this use case **Table 6.4.4.1-1: Operational Requirements and Platform Support for Vulnerable Road Users** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement| Support in MEC | Support in oneM2M | |----|----|----| -| Up and running IoT platform | Not Required | Supported: oneM2M platform can be deployed at cloud or any edge node | +| Up and running IoT platform | Not Required | Supported: oneM2M platform can be deployed at cloud or any edge node | | Registration of vehicles, IoT devices, and applications | Not Required | Supported: oneM2M features provide CSFs to register both devices and Application Entities (AEs) | | Data collection from IoT Devices (Vehicle sensors, Road sensors, LIDAR) | Not Required | 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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 CSF to instantiate an AE as MEC application | +
+ ### 6.4.5 Swarm-based Autonomous Ant Delivery Optimization @@ -595,17 +631,19 @@ As robots move across delivery zones, the system ensures seamless session handov **Table 6.4.5.1-1: Operational Requirements and Platform Support for Swarm-based Autonomous Ant Delivery Optimization** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| -| Up and running IoT platform | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud | -| Registration of devices (Swarm Robots) | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs | -| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs | +| Up and running IoT platform | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud | +| Registration of devices (Swarm Robots) | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs | +| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs | | Real-time data ingestion from AEs (pheromone map updates, route feedback and obstacle reports) | Not required | Supported via oneM2M\'s CSF 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform | | Instantiate of AE (e.g. Swarm optimization) on Edge Node | AE can be instantiated as MEC Application on MEC Host. | Supported: oneM2M platform needs to include a CSF to instantiate an AE as MEC application | | Low-latency control for Hybrid Swarm Robots (feedback for Swarm optimization)| 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 required. But MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. | | Service continuity during Hybrid Swarm Robot zone transitions | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE) instance coordinated by IN-CSE | +
+ ### 6.4.6 Smart Warehouse Automation @@ -616,7 +654,7 @@ In Table 6.4.6.1-1, all the relevant operational requirements for this use case **Table 6.4.6.1-1: Operational Requirements and Platform Support for Smart Warehouse Automation** -| Operational Requirement | Support in MEC | Support in oneM2M | +| 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 centre | | Registration of sensors, AGVs, and applications | Not required | Supported: oneM2M features provide CSFs to register both devices and Application Entities (AEs) | @@ -624,8 +662,10 @@ In Table 6.4.6.1-1, all the relevant operational requirements for this use case | 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 (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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 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 Required | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. | +| Offloading low latency tasks of IoT Platform for real time data processing | Not Required | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. | | Service continuity during AGV zone transitions | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE) instance coordinated by IN-CSE | +
+ ### 6.4.7 Industrial Digital Twins @@ -638,19 +678,21 @@ In Table 6.4.7.1-1, all the relevant operational requirements for this use case **Table 6.4.7.1-1: Operational Requirements and Platform Support for Industrial Digital Twins** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| | IoT platform deployment | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud or control centre | -| Registration of Industrial devices (Digital Twin (DT)) | Not required | Supported: oneM2M enables registration of industrial sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs using \ data | -| Registration of Industrial applications | Not required | Supported: oneM2M enables registration of industrial | -| Applications as AEs via standardized resource structures and CSFs | | | +| Registration of Industrial devices (Digital Twin (DT)) | Not required | Supported: oneM2M enables registration of industrial sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs using \ data | +| Registration of Industrial applications | Not required | Supported: oneM2M enables registration of industrial| +| Applications as AEs via standardized resource structures and CSFs | | | | Real-time data ingestion from factory floor (sensors, robots, AGVs) | Not required | Supported via oneM2M\'s CSF 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a 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. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform | | Instantiate of AE (e.g. AGV controller, sensor manager, analytics & controller) on Edge Node (Edge Digital Twin) | AE can be instantiated as MEC Application on MEC Host | Supported: oneM2M platform needs to include a 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 required. But MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. | | Service continuity during AGV zone transitions | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE) instance coordinated by IN-CSE | -| Synchronization of Digital Twin state between edge and cloud | Not required | oneM2M ensures data consistency and context synchronization between MN-CSE (edge) and IN-CSE (cloud) whereas DT state plays vital role | +| Synchronization of Digital Twin state between edge and cloud | Not required | oneM2M ensures data consistency and context synchronization between MN-CSE (edge) and IN-CSE (cloud) whereas DT state plays vital role | +
+ ### 6.4.8 Assisted Manoeuvring for Autonomous Ships @@ -664,17 +706,19 @@ In Table 6.4.8.1-1, all the relevant operational requirements for this use case **Table 6.4.8.1-1: Operational Requirements and Platform Support for Assisted Manoeuvring for Autonomous Ships** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| -| IoT platform deployment | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud | -| Registration of devices on the Ships | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or MN-AE or ADN-AE via standardized resource structures and CSFs | -| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs | +| IoT platform deployment | Not directly required | Supported: oneM2M IN-CSE can be deployed at cloud| +| Registration of devices on the Ships | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or MN-AE or ADN-AE via standardized resource structures and CSFs | +| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs | | Real-time data ingestion from AEs (vessel localization, its speed, course and other environment variables) | Not required | Supported via oneM2M\'s CSF and Mca interfaces | | Instantiate of MN-CSE on Edge Node plays role ROC with AI capabilities | MEC provides the infrastructure to host oneM2M as a service producing MEC application using Mp1 interface. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform | | Instantiate of AE (e.g. generate warnings in real-time and optimize its transmission to the vessel) on Edge Node | AE can be instantiated as MEC Application on MEC Host. | Supported: oneM2M platform needs to include a CSF to instantiate an AE as MEC application | | Low-latency control for unmanned Vessels (i.e. assisted manoeuvring, collision avoidance and situational awareness) | 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 required. But MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms. | | Service continuity during vessels transitions | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE) instance coordinated by IN-CSE | +
+ ### 6.4.9 Smart Metaverse Shopping with Edge-AI and Cloud-IoT Integration @@ -688,15 +732,17 @@ In Table 6.4.9.1-1, all the relevant operational requirements for this use case **Table 6.4.9.1-1: Operational Requirements and Platform Support for Smart Metaverse Shopping** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| -| IoT platform deployment | Not directly | Supported: oneM2M IN-CSE can be deployed at cloud | -| Registration of IoT devices deployed in the physical store | Not required | Supported: oneM2M enables registration of industrial sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs | -| Registration of IoT applications | Not required | Supported: oneM2M enables registration of industrial Applications as AEs via standardized resource structures and CSFs | +| IoT platform deployment | Not directly | Supported: oneM2M IN-CSE can be deployed at cloud | +| Registration of IoT devices deployed in the physical store| Not required | Supported: oneM2M enables registration of industrial sensors, actuators, controllers as either IN-AEs or ADN-AE via standardized resource structures and CSFs | +| Registration of IoT applications | Not required | Supported: oneM2M enables registration of industrial Applications as AEs via standardized resource structures and CSFs | | Real-time data ingestion from Stores (shelf inventory levels, product locations, environmental conditions) | Not required | Supported via oneM2M\'s CSF and Mca interfaces | | Instantiate of MN-CSE on Edge Node with AI capabilities (If required) | MEC provides the infrastructure to host oneM2M as a service producing MEC application using Mp1 interface. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform | | Instantiate of AE (e.g. sensor manager, analytics & controller) on Edge Node | AE can be instantiated as MEC Application on MEC Host. It can use AI models for analysing real time data and providing feedback. Virtual Store App instantiate as an MEC application/Edge Application on MEC Host. | Supported: oneM2M platform needs to include a CSF to instantiate an AE as MEC application | | Low-latency control for real time data processing | Supported: MEC Apps handle time-sensitive operations with minimal delay. | Supported: MN-CSE enables fast coordination through subscriptions, notifications, and data routing | +
+ ### 6.4.10 Future Homes @@ -709,16 +755,19 @@ In Table 6.4.10.1-1, all the relevant operational requirements for this use case **Table 6.4.10.1-1: Operational Requirements and Platform Support for Future Homes** -| Operational Requirement | Support in MEC | Support in oneM2M | +| Operational Requirement | Support in MEC | Support in oneM2M | |----|----|----| -| IoT platform deployment | Not directly | Supported: oneM2M IN-CSE can be deployed at cloud or as MN-CSE elsewhere | -| Registration of devices at the home premises (lights, thermostats, cameras, wearables) | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or MN-AE or ADN-AE via standardized resource structures and CSFs | -| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs | +| IoT platform deployment | Not directly | Supported: oneM2M IN-CSE can be deployed at cloud or as MN-CSE elsewhere | +| Registration of devices at the home premises (lights, thermostats, cameras, wearables) | Not required | Supported: oneM2M enables registration of sensors, actuators, controllers as either IN-AEs or MN-AE or ADN-AE via standardized resource structures and CSFs | +| Registration of applications | Not required | Supported: oneM2M enables registration of Applications as AEs via standardized resource structures and CSFs| | Real-time data ingestion from AEs (location data, Health alerts or anomalies, room temperature, energy consumption, object movements) | Not required | Supported via oneM2M\'s CSF and Mca interfaces | | Instantiate of MN-CSE/ASN-CSE on Edge Node (Customer Premises Edge) | MEC provides the infrastructure to host oneM2M as a service producing MEC application using Mp1 interface. Can provide support to integrate a new MEC IoT service inside the MEC Platform which should be more coupled with oneM2M standards. Whereas MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. Not Supported in MEC: If MEC supports CPEs, then MEC systems can discover them, and MEP enables MEC applications to offload real time data processing tasks to this non-MEC systems. | Supported: oneM2M platform needs to include a CSF to integrate with the MEC platform | | Instantiate of AE (e.g. Energy Optimization, Real-time Safety Alerts, Contextual Scene Adaptation, Manage home appliances) on Edge Node | AE can be instantiated as MEC Application on MEC Host or as Edge application on CPEs. | Supported: oneM2M platform needs to include a CSF to instantiate an AE as MEC application | | Offloading low latency tasks of IoT Platform for real time data processing | Not required. But MEC IoT API (ETSI GS MEC 033 [\[i.15\]](#_ref_i.15)) enables minimal registration and discovery of IoT platforms. | Supported: Tasks can be offloaded to MN-CSE instances using Mcc interface mechanisms.| -| Service continuity during devices movements. | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement), ETSI GS MEC 021 [\[i.11\]](#_ref_i.11) (Application Mobility service) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE/ASN-CSE) instance coordinated by IN-CSE/MN-CSE | +| Service continuity during devices movements. | Supported via ETSI GS MEC 013 [\[i.7\]](#_ref_i.7) Location API (tracks UE movement), ETSI GS MEC 021 [\[i.11\]](#_ref_i.11) (Application Mobility service) and ETSI GS MEC 040 [\[i.16\]](#_ref_i.16) (supports MEC Federation and cross-MEP orchestration). | Supported: oneM2M handles session handover and task migration to a new edge (MN-CSE/ASN-CSE) instance coordinated by IN-CSE/MN-CSE | + +
+ # 7 Proposed Recommendations for Federation and Orchestration Mechanisms @@ -761,9 +810,9 @@ The orchestration framework should create a federated, service-aware, and resour The Handover mechanism refers to the process of transferring control of a device or service from one MEC/oneM2M instance to another, ensuring seamless connectivity and service continuity. There three main scenarios where handover is essential: - Optimizing the connection of wireless IoT devices as they move geographically, ensuring they remain connected to the most appropriate edge node. - Maintenance of services or servers that need to be migrated between MEC/oneM2M instances due to load balancing, resource optimization, or fault tolerance. -- Emergency scenarios where rapid handover is required to maintain service continuity during network disruptions or failures, such as a failure of an edge node or a sudden surge in demand. +- Emergency scenarios where rapid handover is needed to maintain service continuity during network disruptions or failures, such as a failure of an edge node or a sudden surge in demand. -This process, illustrated in Figure 7.2-1, is critical when devices move between different edge nodes or when services must be migrated to maintain low latency, reliability, and high availability. +This process, illustrated in Figure 7.2-1, is critical when devices move between different edge nodes or when services are migrated to maintain low latency, reliability, and high availability. ![Figure 7.2-1: IoT device handover](media/handover.png) @@ -799,31 +848,24 @@ These considerations will be further analysed in oneM2M and ETSI MEC. Swarm Computing refers to the coordination of multiple MEC/oneM2M instances to perform distributed computing tasks, leveraging the capabilities of edge devices and networks. In this paradigm, individual MEC/oneM2M nodes act like members of a swarm, each contributing processing power, storage, connectivity, or sensing capabilities to achieve collective goal. The system operates in a decentralized and adaptive manner, where tasks can be dynamically partitioned, distributed, and recombined across nodes depending on resource availability, network conditions, and application requirements. This enables resilient, scalable, and low-latency processing, as tasks are executed closer to the data sources and devices while ensuring cooperative load balancing, fault tolerance, and energy efficiency. When mapped onto MEC/oneM2M interworking, distributed instances could be implemented as Application Entities (AEs) hosted on Middle Nodes (MNs) or Application Dedicated Nodes (ADNs). In this scenario, local coordination within a swarm could be supported by nearby Common Service Entities (CSEs). In ETSI MEC terms, there can be MEC Services or MEC Applications which provide contextual information aggregated from other swarm nodes. In this clause, the entities involved are described as follows: - - **Swarm Agent (Local/Edge):** is a software entity running on a device, MEC host, or oneM2M Application Entity that performs local computation and participates in cooperative swarm behaviour. It executes subtasks of a global distributed task, shares local state, sensor data, or intermediate results with peers. The local Swarm Agent may run on constrained devices or ADNs, focusing on lightweight processing and sensing, while the Edge Swarm Agent may run on MEC hosts or MNs, handling more complex subtasks and acting as a bridge to cloud/federated nodes. - - **Swarm Entity**: is any participating user or platform (e.g. device, MEC host, AE, MN, or ADN) that contributes computing, storage, or sensing resources to the swarm. It executes assigned subtasks and exchanges state updates with other nodes via oneM2M group communication or MEC APIs. - **Swarm Collector:** software (e.g. CSE or MEC host) that aggregates results from multiple swarm nodes and produces a unified output. It collects partial results from distributed swarm nodes, performs aggregation (e.g. fusion of sensor data), and provides the final output back to the orchestrator, applications, or end-users. - - - - **Swarm Orchestrator:** is the central coordination entity of the swarm that manages task distribution, resource allocation, synchronization, resilience, and policy enforcement. It splits global tasks into subtasks, assigns subtasks to swarm nodes based on capacity, connectivity, and energy, detects node failures and reassigns tasks, and ensures QoS, latency, energy, and fault-tolerance goals. It may operate centrally (e.g. cloud IN-CSE) or decentrally (e.g. at MEC/MN-CSE) depending on deployment. - -Consistent with the deployment options described in Clause 5, swarm computing may be implemented through the following options: - +Consistent with the deployment options described in clause 5, swarm computing may be implemented through the following options: - **Option 1:** In this configuration, Swarm Entities ask Swarm Agents to perform local tasks and interact with a Swarm Collector located nearby at the edge. The Swarm Orchestrator coordinates task assignment and resource allocation. Swarm Agents can execute subtasks locally and return intermediate results to the Swarm Collector, which consolidates outputs and sends them back to the Swarm Orchestrator. The Swarm Orchestrator and the Swarm Collector may be co-located or deployed separately on the edge. This option emphasizes low-latency collaboration between distributed Swarm Nodes and is well-suited for scenarios where tasks require real-time responses and localized aggregation as illustrated in Figure 7.3-1. - ![Figure 7.3-1: Swarm Computing Implementation - Option 1](media/swarm_computing_option_1_updated.png) +![Figure 7.3-1: Swarm Computing Implementation - Option 1](media/swarm_computing_option_1_updated.png) - **Figure 7.3-1: Swarm Computing Implementation - Option 1** +**Figure 7.3-1: Swarm Computing Implementation - Option 1** -- **Option 2:** Swarm Entities could be resource-constrained devices running lightweight processing. These devices can only execute simple tasks and rely on the Swarm Agents for heavier processing and the Swarm Collector for results aggregation. The Swarm Orchestrator manages tasks\' distribution and offloading policies, ensuring that constrained Swarm Entities are not overloaded. The Swarm Collector aggregates results from multiple Swarm Agents (e.g. deployed on the edge, namely Swarm Agent 1 and Swarm Agent 2) in charge of processing of the different sub-tasks, and returns consolidated outputs. This result is then shared with the Swarm Orchestrator as well as with the Swarm Agent that sent the original request. Finally, the initial Swarm Agent (Local) performs post-processing operations according to the requirements of the initial request, as shown in the Figure 7.3-2. In this option, the Swarm Collector and the Swarm Orchestrator may be co-located on the edge platform.. +- **Option 2:** Swarm Entities could be resource-constrained devices running lightweight processing. These devices can only execute simple tasks and rely on the Swarm Agents for heavier processing and the Swarm Collector for results aggregation. The Swarm Orchestrator manages tasks\' distribution and offloading policies, ensuring that constrained Swarm Entities are not overloaded. The Swarm Collector aggregates results from multiple Swarm Agents (e.g. deployed on the edge, namely Swarm Agent 1 and Swarm Agent 2) in charge of processing of the different sub-tasks, and returns consolidated outputs. This result is then shared with the Swarm Orchestrator as well as with the Swarm Agent that sent the original request. Finally, the initial Swarm Agent (Local) performs post-processing operations according to the requirements of the initial request, as shown in the Figure 7.3-2. In this option, the Swarm Collector and the Swarm Orchestrator may be co-located on the edge platform. ![Figure 7.3-2: Swarm Computing Implementation - Option 2](media/swarm_computing_option_2_updated.png) @@ -831,7 +873,7 @@ Consistent with the deployment options described in Clause 5, swarm computing ma - **Option 3:** This option extends orchestration beyond the edge by combining local processing with cloud-level intelligence. Swarm Entities interact with Swarm Agents at the edge (close to the devices) to perform latency-sensitive processing. In addition, the Swarm Collector, located in a more centralized or cloud domain, executes high-level analytics such as large-scale pattern recognition or long-term optimization using datasets that have been previously collected. The Swarm Orchestrator ensures synchronization between local results coming from the Swarm Agent at the edge and global insights from the cloud, as illustrated in Figure 7.3-3. The Swarm Collector (Global) receives the data produced by the Swarm Entity via the Swarm Orchestrator, and then performs application-specific pattern recognition which is shared with the Swarm Entity via the Swarm Orchestrator and the Swarm Agent. -This hybrid model leverages the strengths of both edge and cloud: low latency at the edge and high computational power in the cloud, enabling scalable and adaptive swarm intelligence. This option is more application-specific because it divides intelligence between cloud and edge based on the workload. While Options 1 and 2 mainly vary by how close computation is to devices or how much is offloaded, Option 3 requires a split between real-time behavior at the edge and high-level reasoning in a cloud. Therefore, the placement of functions depends on the type of analytics, latency constraints, and data-handling rules of each application. +This hybrid model leverages the strengths of both edge and cloud: low latency at the edge and high computational power in the cloud, enabling scalable and adaptive swarm intelligence. This option is more application-specific because it divides intelligence between cloud and edge based on the workload. While Options 1 and 2 mainly vary by how close computation is to devices or how much is offloaded, Option 3 requires a split between real-time behaviour at the edge and high-level reasoning in a cloud. Therefore, the placement of functions depends on the type of analytics, latency constraints, and data-handling rules of each application. ![Figure 7.3-3: Swarm Computing Implementation - Option 3](media/swarm_computing_option_3_updated.png) @@ -842,7 +884,7 @@ To allow multiple MEC/oneM2M nodes to collaboratively perform distributed tasks, - **Task Decomposition:** a global computation task is divided into smaller subtasks. The orchestrator distributes these subtasks to participating MEC/oneM2M nodes based on their declared processing and storage capacity, network connectivity, or CPU/GPU availability. -- **Synchronization:** appropriate synchronization mechanisms (e.g. publish/subscribe over oneM2M and MEC APIs) should ensure swarm nodes operate on consistent views of data. To maintain consistent swarm knowledge across federated nodes, a distributed state synchronization is required. +- **Synchronization:** appropriate synchronization mechanisms (e.g. publish/subscribe over oneM2M and MEC APIs) should ensure swarm nodes operate on consistent views of data. To maintain consistent swarm knowledge across federated nodes, a distributed state synchronization is needed. - **Task offloading:** the orchestration mechanism should support task offloading policies where swarm members dynamically delegate high-complexity processing to nearby MEC/oneM2M nodes. @@ -898,34 +940,20 @@ The orchestration mechanism should be able to perform the following steps: - **Local Training:** each selected node trains the model locally using its own data. The training parameters (e.g. weights, gradients, etc.) are stored locally and not exposed outside the node. - **Aggregation and Synchronization:** model\'s updates are periodically transmitted to the aggregation nodes which might be either an IN-CSE or a MEC host. The aggregator combines updates using secure aggregation protocols and redistributes the improved global model. This allows to maintain consistency between IN-CSE/MEC host, MEC/oneM2M nodes and MEC orchestrator (aggregator). -
- -# Annex : Change history - -| Date | Version | Information about changes | -| --------------- | ------- | ----------------------------------------- | -| <Month year> | <#> | <Changes made are listed in this cell> | -| | | | -| | | | -| | | | - -
# History +--------+---------------+----------------------------------------------------------------+ |Version |Date |Milestone | +:=======+:==============+:===============================================================+ -|V4.0.1 |April 2025 |Early draft available | +|V4.1.1 |November 2025 |Publication | +--------+---------------+----------------------------------------------------------------+ -|V4.0.2 |June 2025 |Early draft update | -+--------+---------------+----------------------------------------------------------------+ -|V4.0.3 |September 2025 |Stable draft available | +| | | | +--------+---------------+----------------------------------------------------------------+ -|V4.0.3 |September 2025 |Clean-up done by editHelp! | -| | |E-mail: [edithelp@etsi.org](edithelp@etsi.org) | +| | | | +--------+---------------+----------------------------------------------------------------+ -|V4.0.4 |October 2025 |Final draft available | +| | | | +--------+---------------+----------------------------------------------------------------+ | | | | +--------+---------------+----------------------------------------------------------------+ +