Hanging paragraph
Editor note: This is a hanging paragraph and it must be moved to its own clause 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.
This process, illustrated in Figure 6.3.1, is critical when devices move between different edge nodes or when services must be migrated to maintain low latency, reliability, and high availability.

Fig 6.3.1 IoT device handover 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 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 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. To design an effective handover mechanism, the following high-level considerations should be addressed:
-
Identity & Security: The device must maintain a consistent identity across MEC/oneM2M instances, with fast and secure re-authentication (e.g., token-based methods). Security credentials and keys should be managed automatically to ensure a smooth transition.
-
Session & State Continuity: Handover must preserve session continuity and data consistency. This includes mechanisms for state replication (buffers, acknowledgments, sequence numbers), subscription reinstatement, downlink catch-up, and, where possible, context transfer of QoS or profiles between gateways.
-
Performance & Latency: Interruptions must be minimized with well-defined handover budgets (e.g., ≤200 ms for critical telemetry). Local buffering, ordering policies, duplicate suppression, and time synchronization help maintain low latency and reliable delivery.
-
Network Awareness & Adaptation: The mechanism should leverage network conditions such as bandwidth, signal strength, and congestion when selecting target gateways. Neighbour awareness, proactive discovery, and policy-based triggers (RSSI/SNR thresholds, cost/latency trade-offs) are key to ensuring optimal handover decisions. Admission control policies must also be considered, allowing gateways to accept or defer connections gracefully.
-
Monitoring & Reliability: System reliability depends on the ability to measure and manage handovers. KPIs such as attach/authentication time, packet loss, and latency deltas should be tracked. Tracing, alarms for frequent or failed handovers, and robust retry/backoff logic ensure stability and resilience.
-
Device Constraints & Efficiency: IoT devices, often resource- or power-constrained, require lightweight solutions. Gateway-local registrations can reduce complexity, while power-aware scanning and cached neighbour reports minimize RF cost. Feature negotiation and versioned message contracts further improve compatibility and efficiency across heterogeneous deployments.
These considerations will be further analyzed in oneM2M and ETSI MEC.