Adding initial content for handover

## 7.2 Handover

Tbd

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.

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 transition (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 is 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.

Some of the requirements for an effective handover mechanism include:

- **Device Identity:** 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.

- **Session Continuity:** The handover process must ensure that ongoing sessions are not interrupted, and that any in-progress data transfers are completed successfully.

- **Data Consistency:** 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.

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

- **Gateway-local Registrations:** Device can (re)register with any gateway to ensure that its context and state are preserved during a handover.

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

- **Subscription Reinstatement:** Subscriptions/observers (oneM2M SUB, MQTT topics, CoAP obs) must auto-recreate.

- **State Replication:** Gateway state (buffers, pending acks, last sequence) is either transferred or reconstructed from IN-CSE.

- **Local Buffering:** Device and gateways buffer uplink during handover with monotonic sequence numbers + dedupe.

- **At-Least-Once → Exactly-Once (optional):** Support idempotent writes (resource versions, message IDs) to avoid duplicates upstream.

- **Downlink Catch-Up:** Gateway B fetches missed downlink commands from IN-CSE (or shared queue) after attach.

- **Time Sync:** NTP/PTP or application-level timestamping (monotonic device timestamps + gateway receive timestamps).

- **Ordering Policy:** Define whether ordering is per-topic/per-resource and how replays are handled.

- **Security Material Policy:** Automatic management of security credentials and keys across handovers.

- **Handover Budget:** Define max interruption (e.g., ≤ 200 ms for critical telemetry, ≤ 2 s for non-critical).

- **Admission Control:** Gateway B can refuse connections to a gateway; device must gracefully fall back (retry next candidate).

- **Handover KPIs:** Attach time, auth time, packet loss during HO, buffer depth, duplicates, latency deltas.

- **Tracing:** Correlate spans across gateways (traceID propagated in app headers or oneM2M request IDs).

- **Alarms:** Emit events for frequent HO, failed re-auth, buffer overflow, policy violations.

- **Power-Aware Scanning:** Duty-cycle discovery scans; cache neighbor beacons to reduce RF cost.

- **Backoff & Retry Logic:** Exponential backoff with bounded total outage; last-known-good gateway memory.

- **Versioned Contracts:** Message schemas (TLVs/JSON) are backward compatible across gateways.

- **Feature Flags:** Device announces supported HO features; gateways negotiate the HO method.

## 7.3 Swarm Computing