@@ -766,65 +766,21 @@ Depending on system design and device capability, handover control can follow on
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 that be considered for an effective handover mechanism include (__required__):
To design an effective handover mechanism, the following high-level considerations should be addressed:
-**Device Identity(_required__):** 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.
-**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 Continuity:** The handover process must ensure that ongoing sessions are not interrupted, and that any in-progress data transfers are completed successfully.
-**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.
-**Data Consistency(_required__):** The handover mechanism must guarantee that the device's data remains consistent and up-to-date across all MEC/oneM2M instances involved in the process.
-**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.
-**Data Latency:** The handover process must minimize data latency to ensure that real-time applications can continue to function without interruption. This may include methods to pre-fetch data, maintain persistent connections, or identifying fast versus slow changing data.
-**Network Awareness & Adaptation**: The mechanism should leverage network conditions such as bandwidth, signal strength, and congestion when selecting target gateways. Neighbor 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.
-**Network Conditions:** The handover mechanism must take into account the current network conditions, such as bandwidth availability and signal strength, to determine the best MEC/oneM2M instance for the device to connect to.
-**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.
-**Gateway-local Registrations(_required__):** Device can (re)register with any gateway to ensure that its context and state are preserved during a handover.
-**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 neighbor reports minimize RF cost. Feature negotiation and versioned message contracts further improve compatibility and efficiency across heterogeneous deployments.
-**Fast Re-authentication:** The handover process must support fast re-authentication mechanisms to minimize downtime and ensure a smooth transition between MEC/oneM2M instances, e.g. token-based handover that consists of short-lived tokens that are refreshed via the IN-CSE.
-**Context Transfer (optional but ideal):** Gateway A can pass the device’s session/profile/QoS/subscriptions to Gateway B.
-**Neighbor Awareness:** MEC/oneM2M instances should be aware of their neighboring instances to facilitate efficient handover and resource sharing. This includes maintaining a list of nearby instances, their capabilities, and current load conditions.
-**Proactive Discovery:** Device keeps a shortlist of candidate gateways (scan list / neighbor report / cached CSRs).
-**Triggering:** Handover triggers on RSSI/SNR/BER, link loss, congestion, or policy (cost/power/latency).
