Removed shall statement from clause 7, addressed comments from Bob, added...

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.

- **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 **should** 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]

Therefore, the orchestration framework should:

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

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

  ![Fig 7.2.1](media/handover.png) **Fig 7.2.1 IoT device handover**

![Fig 7.2.1](media/handover.png)

**Fig 7.2.1 IoT device handover**

Depending on system design and device capability, handover control can follow one of two approaches:

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, these can be MEC Services or MEC Applications which provide contextual information aggregated from other swarm nodes.

In this clause, the involved entities are defined 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 behavior. 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 Node:** is any participating entity (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 Node:** is a designated node (e.g., MN-CSE, MEC host, or IN-CSE) that aggregates results from multiple swarm nodes and produces a unified output. It collects partial results from distributed 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.

Compatibly with the deployment options described in Clause 6.4.1, the swarm computing could be implemented considering the following options:

- **Option1:** CSE at the edge and MEC host close to the devices so that swarm computing agents interact directly via local MN-CSEs/MEC Applications with low-latency

  ![Fig 7.3.1](media/swarm_computing_option1.png)

  **Fig 7.3.1 Swarm Computing Implementation - Option 1**

- **Option 2**: Part of swarm intelligence runs on constrained devices, while heavier computation is offloaded to MEC nodes for aggregation and route optimization.

![Fig 7.3.2](media/swarm_computing_option2.png)

**Fig 7.3.2 Swarm Computing Implementation - Option 2**

- **Option 3**: high-level pattern recognition in an IN-CSE hosted in cloud, while real-time behaviors remain at the edge

![Fig 7.3.3](media/swarm_computing_option3.png)

In order to allow multiple MEC/oneM2M nodes to collaboratively perform distributed tasks, the orchestration mechanisms shall take into account the following aspects:

**Fig 7.3.3 Swarm Computing Implementation - Option 3**

In order to allow multiple MEC/oneM2M nodes to collaboratively perform distributed tasks, the orchestration mechanisms should take into account the following aspects:

- **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) shall ensure swarm nodes operate on consistent views of data. To maintain consistent swarm knowledge across federated nodes, a distributed state synchronization is required.

- **Task offloading**: the orchestration mechanism shall support task offloading policies where swarm members dynamically delegate high-complexity processing to nearby MEC/oneM2M nodes.

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

- **Task offloading**: the orchestration mechanism should support task offloading policies where swarm members dynamically delegate high-complexity processing to nearby MEC/oneM2M nodes.

- **Resilience**: in case of node failures, the orchestrator dynamically reallocates unfinished subtasks to other swarm nodes.

- **Coordination and Aggregation**: results from swarm nodes are aggregated at a designed MEC host, IN-CSE or MN-CSE which acts as a collector node. The oneM2M’s group communication primitives could be used to coordinate actions across swarm members, while MEC APIs could be used to optimize routing and QoS for tasks exchanges.

![Fig 7.3.4](media/diagram_swarm_computing_orchestration.png)

**Fig 7.3.4 Swarm Computing - Orchestration Lifecycle**

## 7.4 Federated Learning

Federated Learning is a distributed machine learning approach in which model training is performed locally on multiple nodes and only model’s parameters or weights, not row data, are exchanged with aggregators. Instead of sending sensitive data to a central location, each node trains a local model using its own data and then shares only the model updates with a central location, which aggregates these updates to improve the global model. This enhances privacy, reduces bandwidth usage, and allows model adaptation close to data sources and IoT devices.

In the MEC/oneM2M interworking context, local training can be executed within Application Entities (AEs) on Middle Nodes (MN-CSE) or even on constrained edge devices, while aggregation roles can be hosted on Infrastructure Nodes CSEs (IN-CSE) in the cloud environment, or on ETSI MEC applications acting as intermediate servers at the edge. ETSI MEC services could provide capabilities such as Location API, Radio Network Information API, or IoT API to enrich local training with contextual features.

In this clause, the involved entities are defined as follows:

- **FL Client:** a participating device or node (e.g., IoT sensor, MEC node or application entity) that trains a machine learning model locally using its own private data. It holds raw data (never shared outside the device), performs local model training based on the global model received from the server/aggregator, and sends only model updates/gradients (not raw data) back to the FL Server or Aggregator.

- **FL Server:** coordinates the training process across all clients by distributing the initial global model, collecting updates, and managing the learning rounds. It selects which clients participate in each training round, sends the current global model parameters to selected clients, receives updated parameters or gradients from clients after local training, and passes these updates to the FL Aggregator for combination.

- **FL Aggregator:** is responsible for combining model updates from multiple clients into a new, improved global model. It performs model aggregation (e.g., weighted averaging of client models), handles data heterogeneity by balancing contributions from clients (e.g., clients with more data may weigh more), and ensures robustness against noisy updates, stragglers, or malicious clients (e.g., secure aggregation techniques).

- **FL Orchestrator:** manages the overall lifecycle and policies of the federated learning process, ensuring scalability and resilience across distributed clients and servers. It decides which clients participate in each round (e.g., based on resource availability, network conditions, or data diversity), optimizes how training workloads are distributed, especially in heterogeneous edge/cloud environments, handles privacy rules, security requirements, energy constraints, and fault tolerance, and orchestrates interactions across multiple FL Servers/Aggregators.

Compatibly with the deployment options described in Clause 6.4.1, the federated learning could be implemented considering the following options:

- **Option 1**: federated learning clients run entirely on MN-CSEs co-located with MEC hosts, while the aggregation process occurs within a (edge) MEC application.

![Fig 7.4.1](media/federated_learning_option1.png)

**Fig 7.4.1 Federated Learning Orchestration - Option 1**

- **Option 2**: local MN-CSE/MEC nodes act as intermediate aggregators before sending updates to a central (in-cloud) IN-CSE federated learning server.

![Fig 7.4.2](media/federated_learning_option2.png)

**Fig 7.4.2 Federated Learning Orchestration - Option 2**

- **Option 3**: most training happens at the edge, but global model updates and advanced analytics are performed in the cloud IN-CSE.

![Fig 7.4.3](media/federated_learning_option3.png)

**Fig 7.4.3 Federated Learning Orchestration - Option 3**

Therefore, the orchestration mechanism should be able to perform the following steps:

- **Federation Group Selection**: based on the federation registry, MEC/oneM2M nodes or instances with sufficient compute and local training capabilities are selected as participants to the federated learning process.

![Fig 7.4.4](media/diagram_federated_learning_orchestration.png)

**Fig 7.4.4 Federated Learning - Orchestration Lifecycle**

# Annex A: <br>Title of annex

<br />

# Document history

| Version | Date        | Milestone              |

| ------- | ---------- | ---------------------- |

| ------- | ----------- | ---------------------- |

| V0.0.1  | April 2025  | Early Draft available  |

| V4.0.2  | June 2025   | Early Draft Update     |

| V4.1.0  | July 2025   | Stable Draft available |