6.2 Orchestration of oneM2M CSE"s and MEC platforms

When using a oneM2M and MEC edge platform the deployments include multiple oneM2M/MEC instances. This clause describes needed features for the management, orchestration and federation of edge platforms that include a oneM2M MN-CSE and the ETSI MEC platform. 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.

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

  • 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 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).
  • 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.
  • 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 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. It may also support dynamic service discovery and registration, load balancing across multiple instances, and failover and redundancy mechanisms.