@@ -723,7 +723,7 @@ In the following table, we will consider all the relevant operational requiremen
## 7.1 Introduction
The main focus of integration between **ETSI MEC** and **oneM2M** is to enable efficient data processing, low-latency communication, and enhanced service delivery in edge computing environments. The major capability of this integration includes **federation of the ETSI MEC platforms** and **interaction with oneM2M instances**, allowing for distributed computing and data management across multiple edge nodes. Both ETSI MEC and oneM2M provide some basic APIs and protocols in order to facilitate such a federation. However, orchestration mechanisms are still required to ensure seamless operation across multiple MEC/oneM2M instances. This clause describes a preliminary set of functional and technical recommendations for enabling a framework for the federation and orchestration of MEC/oneM2M instances by addressing the following mechanisms described in the use cases in **clause X**:
The main focus of integration between **ETSI MEC** and **oneM2M** is to enable efficient data processing, low-latency communication, and enhanced service delivery in edge computing environments. The major capability of this integration includes **federation of the ETSI MEC platforms** and **interaction with oneM2M instances**, allowing for distributed computing and data management across multiple edge nodes. Both ETSI MEC and oneM2M provide some basic APIs and protocols in order to facilitate such a federation. However, orchestration mechanisms are still required to ensure seamless operation across multiple MEC/oneM2M instances. This clause describes a preliminary set of functional and technical recommendations for enabling a framework for the federation and orchestration of MEC/oneM2M instances by addressing the following processes described in the use cases in **clause X**:
-**Handover**: refers to the process of transferring control of a device or service from MEC/oneM2M instance to another, ensuring seamless connectivity and service continuity.
@@ -733,38 +733,40 @@ The main focus of integration between **ETSI MEC** and **oneM2M** is to enable e
The federation and orchestration framework will explore the existing APIs for discovery and resource management principles defined in both standards, while proposing extensions to them with federation and synchronization capabilities. Before orchestrating handover, swarm computing, or federated learning mechanisms, MEC/oneM2M instances must be able to discover, register, and organize themselves into collaborative groups:
-**Instances Registration**: MEC/oneM2M nodes (e.g., IN-CSE, MN-CSE, MEC Platform, MEC Host, etc.) should be able to register to a federation registry, that may include its identity, capabilities, and available services. [propose removing this line] This registry might be hosted in a central IN-CSE or exposed as a distributed registry across MEC Orchestrators.
-**Instances Registration**: MEC/oneM2M nodes (e.g., IN-CSE, MN-CSE, MEC Platform, MEC Host, etc.) should be able to register to a federation registry, that may include its identity, capabilities, and available services. **[propose removing this line]** This registry might be hosted in a central IN-CSE or exposed as a distributed registry across MEC Orchestrators.
-**Instances Discovery**: MEC/oneM2M nodes shall be able to advertise its capabilities through standard discovery mechanisms (e.g., oneM2M Discovery resource, MEC location, etc.). This might be achieved by publishing metadata about the MEC/oneM2M node’s processing power, storage capabilities, network connectivity, and supported APIs. For example, using MEC IoT API could allow MEC applications to discover oneM2M platforms and route device traffic accordingly.
-**Instances Discovery**: MEC/oneM2M nodes **shall** be able to advertise its capabilities through standard discovery mechanisms (e.g., oneM2M Discovery resource, MEC location, etc.). **This might be achieved by publishing metadata about the MEC/oneM2M node’s processing power, storage capabilities, network connectivity, and supported APIs. For example, using MEC IoT API could allow MEC applications to discover oneM2M platforms and route device traffic accordingly.**
-**Instances Federation**: once discovered, MEC/oneM2M instances can be logically grouped into a federation group. Such a group might be a collection of MEC/oneM2M instances that are allowed to intercommunicate and cooperate in executing distributed tasks. Federation groups could be defined based on geographic proximity, application domain or QoS requirements.
-**Roles Assignment**: based on their capabilities, the MEC/oneM2M nodes could be selected for specific roles such as handover anchor, swarm computing worker or federated learning participant. For the instance, MEC/oneM2M nodes with high processing power and storage capacity could be selected for swarm computing and federated learning training tasks, while nodes with good connectivity could be used for handover, service continuity and low-latency communications.
Therefore, the orchestration framework shall: [This is not normative, therefore we need to removed **shall** statements]
- Implement resource replication mechanisms to mirror or move device/application registration between MN-CSE and IN-CSE or across MEC hosts including the reference criteria for doing that.
- Implement resource replication mechanisms to mirror or move device/application registration between MN-CSE instances **or IN-CSE or across MEC hosts including the reference criteria for doing that**.
- Ensure a handover-safe mechanism for migrating subscriptions (first establish a new subscription and then terminate the old one).
- Establish synchronization mechanisms between MN-CSE and IN-CSE to ensure that the recent device states are propagated upward and historical data are migrated asynchronous, when necessary.
- Identify and discover MEC/oneM2M instances from logical federation group.
-**Identify and discover MEC/oneM2M instances from logical federation group.**
- Match available resources (e.g., storage, compute, connectivity, etc.) with service requirements (e.g., handover, swarm computing or federated learning).
- Assign tasks to federation nodes.
- Keep registrations, subscriptions, and data synchronized across MN-CSEs/IN-CSEs and MEC nodes.
- Continuously monitor nodes performances and workload by reassigning tasks or triggering handover when needed.
The orchestration framework shall create a **federated, service-aware, and resource-optimized environment** where ETSI MEC and oneM2M instances jointly deliver advanced distributed computing and IoT data management, by addressing handover continuity, swarm scalability, and federated learning privacy.
The orchestration framework **shall** create a **federated, service-aware, and resource-optimized environment** where ETSI MEC and oneM2M instances jointly deliver advanced distributed computing and IoT data management, by addressing handover continuity, swarm scalability, and federated learning privacy.
## 7.2 Handover
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. This process is critical when devices move between different edge nodes or when services must be migrated to maintain low latency, reliability, and high availability.
Depending on system design and device capability, handover control can follow one of two approaches:
- Device-controlled handover: The device itself detects conditions that trigger a transition (e.g., deteriorating radio quality, mobility, policy changes). It initiates discovery, re-registration, and session updates with the target MEC/oneM2M instance. This approach offers autonomy but assumes the device has sufficient resources to evaluate conditions, make decisions, and handle signaling.
- Device-controlled handover: The device itself detects conditions that trigger a handover (e.g., deteriorating radio quality, mobility, policy changes). It initiates discovery, re-registration, and session updates with the target MEC/oneM2M instance. This approach offers autonomy but assumes the device has sufficient resources to evaluate conditions, make decisions, and handle signaling.
- Network-controlled handover: The MEC/oneM2M infrastructure (e.g., MN-CSEs or gateways) monitors device connectivity and system load, then initiates or enforces a handover. The device simply follows the instructions (e.g., re-register to a new MN-CSE) without needing complex logic or extensive signaling capability. This approach is suitable for constrained IoT devices with limited processing or decision-making capacity.
- Network-controlled handover: The MEC/oneM2M infrastructure (e.g., MN-CSEs or gateways) monitors device connectivity and system load, then initiates or enforces a handover. The device simply follows the instructions (e.g., re-register to a new MN-CSE) without needing complex logic or extensive signaling capability. This approach could be suitable for constrained IoT devices with limited processing or decision-making capacity.
In practice, the chosen strategy should balance device capability, network intelligence, and the requirements of the application domain. For resource-constrained IoT devices, offloading decision-making to the MEC/oneM2M layer may reduce device complexity and power usage, while device-controlled handovers may provide faster reaction times and greater autonomy in heterogeneous deployments.
Some of the requirements for an effective handover mechanism include:
Some of the requirements that be considered for an effective handover mechanism include:
-**Device Identity:** The device must maintain a consistent identity across different MEC/oneM2M instances to ensure that its context and state can be accurately transferred during a handover.
