Clean up repository and update document

## 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 possible framework for the federation and orchestration of MEC/oneM2M instances by addressing the following mechanisms:

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**:

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

- **Federated Learning**: refers to a machine learning approach where multiple MEC/oneM2M instances collaboratively train and share models across multiple decentralized nodes without sharing row data, enhancing privacy and reducing latency.

The federation and orchestration framework shall leverage existing APIs, discovery mechanisms, and resource management principles defined in both standards, while extending them with federation and synchronization capabilities. Before orchestrating handover, swarm computing, or federated learning mechanisms, MEC/oneM2M instances shall be able to discover, register, and organize themselves into collaborative groups:

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**: each MEC/oneM2M node (e.g., IN-CSE, MN-CSE, MEC Platform, MEC Host, etc.) shall first register its identity, capabilities, and available services into a federation registry. This 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**: each MEC/oneM2M node 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:

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.

- Ensure a handover-safe mechanism for migrating subscriptions (first establish a new subscription and then terminate the old one).