Migration as a Steady-State Execution Primitive: A Runtime for Virtual Stationarity in Low-Earth Orbit

1 Introduction

• Satellite contact windows last only minutes, making continuous migration necessary to maintain logical proximity as hosts pass over a target.The paper contrasts this steady-state requirement with terrestrial migration as an exceptional operation and notes that orbital heterogeneity and abrupt source disconnection undermine common assumptions.Source: §1 · p. 1
• VSR separates external orchestration from runtime handover and uses Capability Virtualization and Continuous State Projection to rebind host resources and reconstruct execution on successors.The framework includes a four-phase Prepare–Reconstruct–Project–Commit protocol and an authority fence for single-writer cutovers across heterogeneous ISAs.Source: §1 · p. 1
• Across 300 recurrent handovers, p95 downtime remained below 6 ms without cumulative performance degradation, and all cross-ISA trials resumed successfully.Under realistic orbital profiles, migrations completed in 2.8–4.5 s between handovers spaced 83–242 s apart, yielding availability of A_d ≥ 99.997%.Source: §1 · p. 1

2 Motivation

• Ground-to-satellite links can have under 10 ms propagation latency, but contemporary satellite networks primarily use terrestrial backhauls with added routing overhead.The section motivates its operational analysis with an offshore wind-farm maintenance use case.Source: §2 · pp. 1–2

2.1 XR-Assisted Offshore Maintenance

• A stationary XR host forces relay routing as the satellite passes beyond the horizon, risking latency SLO violations during maintenance sessions.The application streams video, telemetry, and equipment state for interactive overlays and remote expert guidance.Source: §2.1 · p. 2
• Figure 1’s latency and jitter increase in steps when direct line of sight is lost and relay routing occurs at 150 s and 270 s.The figure illustrates pass-over latency behavior.Source: Figure 1 · p. 2
• Median RTT rises from 6.6 ms to 14.4 ms over one relay hop and to 23.1 ms over two hops within five minutes, before other XR processing delays are counted.The worst-case co-planar route is extrapolated to 152.4 ms propagation-only RTT; this is an extrapolation, not a measured route.Source: §2.1 · p. 2
• The application should remain logically anchored above the wind farm, with its location and active state invariant despite satellite motion.The section frames this as the technician’s perspective on virtual stationarity.Source: §2.1 · p. 2

2.2 Migrating the Application

• Checkpoint/restore causes 100% packet loss, pre-copy can exceed 10 s and fail to converge under high write rates, and post-copy incurs about 75% sustained loss.The post-copy loss is attributed to reactive memory-page fetching over the inter-satellite link.Source: §2.2 · p. 2
• Brief contact windows and satellite compute and energy limits make terrestrial trade-offs between migration time and downtime prohibitive.The experiment uses a two-node Raspberry Pi 5 testbed and a VR-gaming UDP telemetry trace at approximately 4,000 packets/s and 5 MB/s.Source: §2.2 · p. 2

3 Related Work

• ReSync uses checkpoint/restore with buffered input replay, while Voyager uses lazy state retrieval; VSR instead projects host-call returns and memory effects and ends predecessor dependence at commit.VSR rebinds logical capabilities to target-local resources rather than federating host resources.Source: §3 · p. 2
• dOS/RecShim targets deterministic process groups, whereas VSR projects live computation across successive authoritative hosts using portable runtime state and rebound capabilities.The cited systems generally rely on OS- or kernel-level mechanisms and reproduce the same host environment at the destination.Source: §3 · pp. 2–3
• Checkpoint/restore, pre-copy, and post-copy trade blackout, migration duration, and sustained packet loss differently during handover.For the 256 MB UDP-based XR workload, checkpoint/restore causes a complete blackout, pre-copy limits loss but prolongs handover, and post-copy incurs sustained loss from reactive page faults.Source: Figure 2 · p. 3
• ReVirt, Liu et al., and Yu et al. use replay or iterative transfer at VM or container boundaries; VSR records boundary events and memory mutations and fences authority.The section describes the Liu et al. design as mechanically close to continuous state projection but targeting a single handover.Source: §3 · p. 3
• Placement and replication systems including,,, and prepare or select locations but do not specify recurrent transfer of a running execution with capability continuity and single authority.VSR accepts the successor and constraints from an external orchestrator and exposes downtime, migration duration, and long-run migration occupancy for feasibility analysis.Source: §3 · p. 3

4 A Runtime for Virtual Stationarity

• The paper first formalizes the correctness and feasibility contract for recurrent migration.This is the opening step in the section’s presentation sequence.Source: §4 · p. 3
• VSR runtime responsibilities are separated from external orchestration and execution-engine services.The section presents this separation after the formal contract.Source: §4 · p. 3
• The section then details the membrane’s two enabling mechanisms and reports one concrete realization.The mechanisms are detailed after the runtime framework is presented.Source: §4 · p. 3

4.1 System and Feasibility Model

• The model describes an application anchored to a ground target and allows it to execute on any satellite in the constellation.The satellite’s end-to-end RTT is represented as a time-varying latency process; no available GSL/ISL path is represented by infinite latency.Source: §4.1 · p. 3

4.1.1 Continuity Contract.

• A handover preserves equivalent application-visible state, required capability semantics, external-effect continuity, and exclusive authority to produce effects.The successor may be reconstructed while the source runs, but remains non-authoritative until handover completes.Source: §4.1.1 · p. 3

4.1.2 Service Objectives and Hosting Windows.

• End-to-end availability counts all time when the application misses its latency SLO, including pauses, path-update delays, and ordinary latency violations.The application specifies both its latency threshold and minimum availability.Source: §4.1.2 · p. 3
• A satellite is admissible only while its latency remains within the application’s SLO; its remaining hosting window sets the migration budget.The migration must finish within that budget, and the successor must meet the SLO when authority transfers.Source: §4.1.2 · p. 3

4.1.3 Steady-State Feasibility.

• Migration cost is evaluated cumulatively over the execution interval, with migration occupancy representing sustained link and compute use rather than service downtime.The downtime-only availability diagnostic matches the model’s availability only when no other latency violations occur.Source: §4.1.3 · p. 4

4.1.4 Contract.

• The mechanism-independent contract requires each handover to meet its budget and commit to an SLO-compliant successor, while schedule-wide availability and migration occupancy meet application limits.The stated limits are minimum availability A_min and maximum migration occupancy ε.Source: §4.1.4 · p. 4

4.2 Virtual Stationarity Runtime Framework

• External orchestration selects the successor and trigger, while the runtime handles how execution continues.The framework diagram identifies the orchestrator, Execution Engine, and Migration Membrane as separate components.Source: §4.2 · p. 4, Figure 3 · p. 4

4.2.1 Components.

• The Execution Engine must provide portable execution and safe-point state capture and restoration, including exposed application-memory mutations from intercepted system calls.The framework does not require a particular bytecode or managed runtime.Source: §4.2.1 · p. 4
• The Migration Membrane combines Capability Virtualization and Continuous State Projection, coordinates handover, and enforces exclusive authority through Live, Record, Replay, and Inactive modes.Prepared Inactive bindings cannot be invoked.Source: §4.2.1 · p. 4

4.2.2 Handover Protocol.

• The four-phase handover prepares a shared portable base, reconstructs target-local inactive bindings, projects continuation events until replay lag meets the commit threshold, then transfers authority at a matching execution fence.The source closes its effect gate before the target activates its bindings; the runtime then requests the orchestrator’s path update.Source: §4.2.2 · p. 4

• Capability Virtualization gives host-dependent operations stable logical names while each host supplies its own local bindings.Required capabilities constrain placement; optional capabilities can be unavailable and are exposed to application behavior.Source: §4.3.1 · p. 5
• During reconstruction, the target prepares host-local resources but leaves bindings inactive; only after commit are source bindings revoked and target bindings activated.A missing required capability invalidates admission, while a missing optional capability maps to its defined unavailable behavior.Source: §4.3.1 · p. 5
• Continuous State Projection reconstructs from a portable base and ordered continuation while the source remains authoritative, assuming reliable FIFO channels, synchronous VSB interactions, and deterministic execution between crossings.Continuation events carry operation outcomes and memory mutations; separating the direct return value from memory changes matters for reads.Source: §4.3.2 · p. 5
• Replay converges only when the source event rate is below target processing rate; when source production is much slower, migration time is approximately linear in base size and independent of memory-dirty rate.If the event rate reaches or exceeds processing capacity, the runtime aborts target reconstruction and leaves the source authoritative.Source: §4.3.2 · p. 6
• The source revokes authority before target activation, which occurs only after prior events are consumed and execution reaches the same opcode fence.Failures before source revocation abort projection; recovery after revocation is outside scope.Source: §4.3.2 · p. 6

• The prototype extends WAMR with an opcode hook and read-only MAP_PRIVATE memory view so the source can resume while the base image is transmitted.The target restores relocatable structures to support execution across operating systems and ISAs.Source: §4.4 · p. 6
• The runtime derives logical capabilities from imported module/function pairs and rebinds evaluated UDP resources to a target socket.Missing optional WASI functions return __WASI_ERRNO_ENOSYS.Source: §4.4 · p. 6
• Figure 4 reports migration time, aggregate CPU use, post-cleanup memory, and transferred continuation events across 300 handovers triggered every 30 seconds.The plotted lines are least-squares trends.Source: Figure 4 · p. 6
• The projection prototype batches mutation records and continuation events in ping-pong buffers, with a flusher transmitting completed batches at most every 500 μs.A receiver inserts events into a bounded FIFO buffer, and commit appends an End event carrying the source opcode counter and identifier.Source: §4.4 · p. 6

5 Evaluation

• The evaluation used four Raspberry Pi 5 hosts, and its availability measure excludes external path updates.The devices represent COTS payload classes rather than specific flight hardware.Source: §5 · pp. 6–7

5.1 Steady-State Correctness and Stability

• Across recurrent handovers, p95 downtime stayed below 6 ms and migration time, CPU use, memory, and continuation traffic showed no material drift.Migration time had a 4.24 s median; continuation traffic had a 5.29 MB median versus a 135.47 MB base snapshot.Source: §5.1 · p. 7, Table 1 · p. 7

5.2 Semantic Continuity

• Across 100 handovers and 176,801 replayed events, verification found no sequence gaps, duplicate outputs, or hash-chain mismatches.The workload tested reconstructed nondeterministic system-call returns and memory mutations, followed by output through the target-local binding.Source: §5.2 · p. 7

5.3 Scaling and Convergence Bounds

• Membrane migration varied by less than 1% across 10–140 MB/s write loads, while pre-copy ceased converging near transfer capacity.Across 200–1,000 MB base states, membrane and checkpoint/restore slopes were 9.06 and 8.96 ms/MB, respectively; membrane downtime stayed within 2–5 ms.Source: §5.3 · p. 7, Figure 5 · p. 7
• Measured durations deviate from the model by 1.3% on average over 1,000–21,000 calls/s; a fit trained on 1k–15k calls/s predicts withheld 16k–21k measurements with 0.8% mean error.Using the 15 s beam-switch period reported by Zhao et al. as a demanding reference rather than a universal budget, the model predicts a breach at 20.2k calls/s.Source: §5.3 · pp. 7–8

5.4 Portability

• All 100 bidirectional x86-64/ARM64 trials resumed on the target without application changes, validating WAMR portability for that architecture pair.The result does not establish architecture independence for arbitrary native runtimes.Source: §5.4 · p. 8

5.5 Orbital Feasibility

• In orbital-profile trials, migrations took 2.8–4.5 s within 83–242 s handover intervals, with no upward drift in median RTT across 900 s traces.Tighter latency targets increased handover frequency rather than individual migration cost.Source: §5.5 · p. 8, Figure 6 · p. 8
• Across 20 aligned handovers, median runtime availability was at least 99.997%, while the same logical UDP descriptor remained usable after each handover.The reported availability covers runtime interruption only, not external path updates or ordinary latency violations.Source: §5 · p. 7, §5.5 · p. 8, Table 2 · p. 8

Conclusion

• Across 300 recurrent handovers, p95 downtime remained below 6 ms without cumulative growth in migration time or continuation state.Simulated orbital schedules also completed within available handover intervals with downtime-only availability of A_d≥99.997%.Source: §6 · p. 8
• The Migration Membrane combines Capability Virtualization to rebind host-dependent resources with Continuous State Projection to reconstruct evolving execution on a successor.An authority fence completes handover without predecessor dependence or both hosts producing external effects.Source: §6 · p. 8

Future Work

• Future work will incorporate orbital, network, energy, and thermal constraints into external host selection.The authors also plan to investigate continuously active state projection for higher handover frequencies and broader classes of virtualized capabilities.Source: §6 · p. 8