Low Earth Orbit (LEO) Systems

• LEO is a low-altitude orbital regime characterized by dense constellations between 500–2000 km that support low-latency communications and edge computing.
• Structured constellations using Walker-type shells and +GRID connectivity enable predictable routing, delay compensation, and dynamic resource placement.
• Advanced modulation, synchronization, and distributed learning techniques address challenges like Doppler shift, intermittent links, and security in LEO networks.

LEO, or Low Earth Orbit, denotes Earth-centered orbital regimes used by contemporary small-satellite and mega-constellation systems to provide communications, sensing, navigation support, and increasingly in-orbit computation. In the surveyed research, LEO systems are typically discussed at altitudes from roughly $500$ to $2000$ km, with especially intensive study around $550$–$710$ km, where propagation delay is far below GEO while coverage per satellite remains small enough to require dense constellations (Leyva-Mayorga et al., 2019). Current work treats LEO not merely as a relay layer but as a structured, dynamic network substrate whose orbital geometry directly shapes coverage, Doppler, routing, transport behavior, edge placement, learning workflows, and security design (Pfandzelter et al., 2022).

1. Orbital regime and constellation geometry

LEO constellations derive their utility from the combination of short path lengths and large constellation cardinality. At around $600$ km altitude with minimum elevation angle $30^\circ$, a single satellite covers only about $0.45\%$ of Earth’s surface, which is why persistent service requires constellations of hundreds to tens of thousands of spacecraft rather than a few high-capacity nodes (Leyva-Mayorga et al., 2019). The same literature emphasizes that LEO propagation delay is low enough to support 5G/B5G integration and even some ultra-reliable services with relaxed latency budgets, while still retaining the broad-area reach of non-terrestrial infrastructure (Leyva-Mayorga et al., 2019).

A recurring structural abstraction is the shell, often represented by a Walker-type arrangement of orbital planes and satellites per plane. For networking purposes, one especially useful topology is the +GRID pattern, in which each satellite maintains four inter-satellite neighbors: predecessor and successor in-plane, plus one nearest neighbor in each adjacent plane. Under this connectivity, a single shell can be modeled as an $N \times M$ 2D torus, where $N$ is the number of orbital planes and $M$ the number of satellites per plane (Pfandzelter et al., 2022). This abstraction is not merely topological; it yields analytic path-length expressions. The in-plane neighbor distance is constant,

$2000$0

whereas the adjacent-plane distance varies over the orbital period,

$2000$1

This distinction is operationally important because equal hop counts can correspond to unequal and time-varying propagation delays (Pfandzelter et al., 2022).

The same geometric regularity that enables tractable placement and routing also imposes limits. Shell-level models typically assume regular spacing, fixed neighbor relations, single-shell independence, and globally uniform demand (Pfandzelter et al., 2022). This suggests that LEO is simultaneously more structured than terrestrial wide-area networks and more dynamic in physical realization.

2. Physical links, modulation, and synchronization

LEO systems are organized around ground-to-satellite links (GSLs) and inter-satellite links (ISLs). The 5G/B5G survey distinguishes GSLs, intra-plane ISLs, inter-plane ISLs, and cross-seam ISLs, and reports that typical propagation delays of about $2000$2 ms between ground and LEO and propagation delays below $2000$3 ms are typical in GSLs, while typical GSL Doppler shifts near $2000$4 kHz must be handled at the waveform and receiver level (Leyva-Mayorga et al., 2019). These values already place LEO outside many terrestrial timing assumptions.

For optical ISLs, the constraints are sharper. Coherent LEO-LEO links were evaluated for QPSK, 8-QAM, and 16-QAM at 28 GBaud, 60 GBaud, and 120 GBaud, with both staircase codes and oFEC. The main result is that higher-order modulation formats combined with high symbol rates can prove unfeasible, even for first-neighbor connections, and that optical pre-amplification as well as the choice of a more robust code such as oFEC can be decisive (Vieira et al., 2022). The paper gives concrete feasibility margins showing that configurations such as 800G 16-QAM at 120 GBaud are often geometry-dependent and sometimes infeasible on first-neighbor interorbital links, especially in polar shells (Vieira et al., 2022).

The same optical-ISL work characterizes Doppler at a scale unusual for coherent optical communications. For first-neighbor interorbital links, many shells remain below $2000$5 GHz, but polar cases reach about $2000$6 GHz and $2000$7 GHz, while an all-to-all upper-bound argument yields about $2000$8 GHz at $2000$9 nm (Vieira et al., 2022). The practical conclusion is nuanced: Doppler amplitudes can be much larger than in fiber systems, but Doppler derivatives are still slow enough that all-digital compensation remains viable. A filtered two-stage scheme combining coarse spectral-shift estimation with an $550$0th-power method is reported as sufficient for all examined cases (Vieira et al., 2022).

For low-power satellite IoT, synchronization itself becomes the dominant abstraction. A LEO-ground LoRa study argues that perfect synchronization is infeasible because of signal propagation delay, Doppler effects, clock drift and atmospheric effects, even with atomic clocks, and formalizes quasisynchronous operation through a bounded residual timing error

$550$1

Its key result is that reliable LoRa communication remains achievable for $550$2, whereas $550$3 produces an error floor (Uysal et al., 2023). This reinforces a broader LEO principle: synchronization targets must be set around bounded residual error, not terrestrial notions of exact alignment.

3. Network architecture, routing, and transport

At network level, LEO is increasingly treated as a multi-hop, congestion-prone transport fabric rather than a simple bent-pipe overlay. The 5G/B5G survey frames the constellation as supporting not only user access but also feeder links, inter-gNB transport, multi-connectivity, and relay paths that can outperform purely terrestrial routes over long distances because propagation in vacuum is faster than in optical fiber (Leyva-Mayorga et al., 2019).

For rural and remote access, stochastic-geometry analysis models a relay architecture in which a ground user reaches the nearest ground gateway (GW) and the GW in turn connects to the nearest LEO satellite. End-to-end coverage is written as

$550$4

making explicit that both the satellite-side and terrestrial-side links must satisfy SNR constraints (Talgat et al., 2020). Within that model, lower satellite altitude and larger satellite populations reduce the gateway density needed for LEO-assisted coverage to outperform a distant anchored terrestrial base station (Talgat et al., 2020).

In geo-distributed data processing, the main bottleneck is often not the inter-satellite backbone but the access satellite selection problem. The DVA algorithm assigns each edge cloud to a visible satellite by prioritizing larger data volumes, then higher available bandwidth, then the fewest potential edge connections among top-bandwidth candidates. In STK-based experiments over 20 CloudFront nodes and Starlink Shell I, DVA achieves 49.7% lower transmission duration than shortest-path selection, 48.8% lower than maximum-visibility-duration selection, 2.28× and 2.30× higher throughput respectively, and remains within about 8% of the ILP optimum while running in under 1 ms versus about 290 ms for the optimal solver (Zhao et al., 2024). This directly supports the claim that geometry-only satellite selection is inadequate once edge-cloud data volumes and access-link contention dominate.

Transport-layer control shows a parallel shift away from terrestrial heuristics. LeoTCP is designed around the observation that LEO paths suffer non-congestive latency variation and loss, transient hotspots, and frequent handovers, so end hosts should not infer congestion from RTT or loss alone (Valentine et al., 26 Aug 2025). It uses per-hop in-network telemetry to compute bottleneck utilization,

$550$5

and adapts the congestion window accordingly (Valentine et al., 26 Aug 2025). In path-sharing scenarios, LeoTCP reports normalized delay around $550$6–$550$7, compared with $550$8–$550$9 for Cubic and $710$0–$710$1 for BBRv1, while also improving goodput and fairness (Valentine et al., 26 Aug 2025). The implication is that LEO transport must distinguish congestion from orbital path dynamics explicitly; loss-driven or delay-driven control alone is structurally ambiguous in this environment.

4. Edge computing, resource placement, and in-orbit learning

A central systems question in LEO is whether compute or service replicas must exist on every satellite. The resource-placement study answers negatively. By modeling a +GRID shell as a weighted torus, it formulates placement as selecting the minimum subset $710$2 such that every satellite lies within a shortest-path distance bound $710$3 of at least one resource node. The QoS-aware method converts weighted-distance placement into a normalized unweighted torus problem and shows that hop-count placement can fail to guarantee latency SLOs because physical hop lengths differ and vary with orbital geometry (Pfandzelter et al., 2022). In simulation on Starlink and Kuiper phase-I shells, the study reports, for example, that Starlink A requires 354 resource nodes for 1-hop placement, 94 for mean 10 ms, 135 for max 10 ms, and only 2 for 100 ms; across all tested shells, two resource nodes suffice at 100 ms (Pfandzelter et al., 2022). The practical message is that “compute everywhere” is often unnecessary, whereas geometry-aware partial deployment can satisfy latency objectives at far lower capital cost (Pfandzelter et al., 2022).

The same intermittency that complicates networking also complicates onboard learning. In Starlink-like traces, one split-learning study reports around 4-minute contact time in a 95-minute orbital period, roughly 5% contact availability, with mean downlink and uplink around 100 Mbps and 12 Mbps (Lin et al., 2 Jan 2025). Vanilla split learning therefore converges roughly 10× slower under intermittent contact. LEO-Split addresses this with an onboard auxiliary model, semi-supervised pseudo-labeling, and adaptive activation interpolation. On GBSense and EuroSAT, it reaches 96.3% and 91.1% under IID settings and converges about 4.4×–4.7× faster than baseline semi-supervised split-learning variants (Lin et al., 2 Jan 2025).

A related framework, SFL-LEO, combines split learning with federated aggregation and asynchronous disconnected-period training. On CIFAR-10 with 20 satellites, it reports 84.4% accuracy under IID data, versus 83.2% for FL and 73.2% for conventional SL, while reducing transmission by $710$4 versus centralized training, $710$5 versus SL, and $710$6 versus FL; processing latency is about $710$7 lower than FL and 56% lower than SL (Wu et al., 18 Apr 2025). The significance is not merely algorithmic: LEO learning systems become viable only when disconnection time is converted from dead time into useful local optimization.

Operational control also increasingly depends on predictive models. LEOSTP, a conditional diffusion-based traffic predictor for LEO, uses historical traffic together with population distribution, POI distribution, and local time to forecast satellite traffic under moving coverage. On a simulated 1584-satellite, 24-plane, 550 km, $710$8 constellation sampled every 5 minutes, it achieves NRMSE around $710$9 and reports a 15.91% error reduction over the best sequence-based baseline, with inference time < $600$0 ms on an RTX 4070 Ti GPU (Ao et al., 29 Jun 2026). This indicates that traffic prediction in LEO must be conditioned on the semantic properties of covered Earth regions, not just on recent traffic values.

5. Security, autonomy, and positioning in LEO constellations

As constellations densify and move toward autonomous mesh routing, security and precise navigation become intrinsic network functions. CLIF frames LEO ISL security as a cross-layer anomaly-detection problem rather than a purely physical-layer authentication problem. It fuses three ephemeris-consistency features with nine network-state features into a 12-dimensional per-link observation and evaluates unsupervised per-satellite detectors on simulations of Starlink (1,584 satellites), Kuiper (1,156 satellites), and a 2,740-satellite multi-operator peering network (Kohli et al., 3 Jun 2026). Its Mahalanobis-distance detector achieves 99.5% recall on Starlink, 99.4% on Kuiper, and 94.8% on the multi-operator constellation, with false positive rates below 0.7% (Kohli et al., 3 Jun 2026). The paper’s substantive contribution is the claim that insider routing attacks, spoofing, and composite attacks cannot be covered by physical-layer checks alone; LEO ISL integrity is a behavioral problem spanning geometry, traffic, queues, and routing state.

Positioning, navigation, and timing are likewise shifting onboard. A decentralized GNSS network study treats a large LEO constellation as a dynamic graph in which each satellite processes local GNSS observations and exchanges only compact state information with neighbors. Its momentum-accelerated gradient-tracking method is evaluated on a 500-satellite, 20-plane, 550 km, $600$1 Walker-Delta constellation with each satellite linked to 4 nearest neighbors (Liu et al., 24 Dec 2025). Cooperative processing reduces orbit error from $600$2 m in standalone mode to $600$3 m with float ambiguities and $600$4 m with fixed ambiguities, while timing improves from $600$5 ns to about $600$6 ns and $600$7 ns respectively (Liu et al., 24 Dec 2025). This is a substantial architectural shift: precise orbit and clock estimation becomes a distributed in-orbit service rather than a purely ground-fused product.

These results suggest that large LEO constellations are evolving toward self-organizing space systems. Security, orbit determination, and timing are no longer external support functions; they are becoming endogenous properties of the constellation mesh (Liu et al., 24 Dec 2025).

6. System-level implications and recurrent misconceptions

Several misconceptions recur in LEO discourse and are explicitly contradicted by the surveyed work. One is that hop count is an adequate QoS surrogate. The torus-placement analysis shows that equal hop radii can map to very different physical latencies because adjacent-plane distances vary over time and differ from in-plane distances (Pfandzelter et al., 2022). Another is that loss or RTT inflation reliably indicates congestion. LeoTCP shows that in LEO, weather effects, path changes, and handovers produce non-congestive delay and loss, so end-to-end inference alone is insufficient (Valentine et al., 26 Aug 2025). A third is that terrestrial coherent-optics operating points can be ported directly into optical ISLs. The optical-link study demonstrates that even first-neighbor LEO links can render high-order, high-baud operating points infeasible, depending on shell geometry and coding choice (Vieira et al., 2022).

The broader architectural pattern is therefore one of geometry-aware design. Regular orbital structure makes some traditionally hard networking problems unusually tractable: shells can be abstracted as tori, gateway coverage can be analyzed with stochastic geometry, and visibility is predictable enough to support centralized scheduling or asynchronous learning (Talgat et al., 2020). Yet that same structure produces non-terrestrial phenomena that require dedicated protocol design: large Doppler, moving coverage semantics, intermittent contact, topology drift, queue transients, and operator-to-operator peering heterogeneity (Zhao et al., 2024).

A plausible synthesis is that LEO should be understood neither as a simple extension of terrestrial networking nor as a classical satellite system with upgraded radios. The surveyed literature instead treats it as a structured, mobile network-compute substrate: one in which orbital mechanics determine link budgets and path lengths, protocol state must adapt to predictable yet rapid topology change, and compute, control, security, and PNT increasingly migrate into the constellation itself (Leyva-Mayorga et al., 2019).