---
title: Low Earth Orbit (LEO) Systems
url: https://www.emergentmind.com/topics/leo
type: topic
---

# Low Earth Orbit (LEO) Systems

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 [1912.08110]. 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 [2201.05872].

## 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 [1912.08110]. 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 [1912.08110].

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 [2201.05872]. This abstraction is not merely topological; it yields analytic path-length expressions. The in-plane neighbor distance is constant,

$$
D_{M} = (r_{E} + h) \sqrt{2\left(1 - \cos\left(\frac{2\pi}{M}\right)\right)},
$$

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

$$
D_{N}(t) = (r_{E} + h) \sqrt{2\left(1 - \cos\left(\frac{2\pi}{N}\right)\right)} \sqrt{\cos^{2}\left(2\pi\frac{t}{T}\right) + \cos^{2}(i)\sin^{2}\left(2\pi\frac{t}{T}\right)}.
$$

This distinction is operationally important because equal hop counts can correspond to unequal and time-varying propagation delays [2201.05872].

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 [2201.05872]. 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 \(2\) ms between ground and LEO** and **propagation delays below \(4\) ms are typical in GSLs**, while **typical GSL Doppler shifts near \(600\) kHz** must be handled at the waveform and receiver level [1912.08110]. 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 [2212.02030]. 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 [2212.02030].

The same optical-ISL work characterizes Doppler at a scale unusual for coherent optical communications. For first-neighbor interorbital links, many shells remain below **\(1\) GHz**, but polar cases reach about **\(4.5927\) GHz** and **\(6.3443\) GHz**, while an all-to-all upper-bound argument yields about **\(10\) GHz** at **\(1550\) nm** [2212.02030]. 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 \(M\)th-power method is reported as sufficient for all examined cases [2212.02030].

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

$$
\tau = \Delta T_c,\qquad -\Delta_s/2 \le \Delta \le \Delta_s/2,\quad 0 \le \Delta_s \le 1.
$$

Its key result is that reliable LoRa communication remains achievable for **\(\Delta_s < 1\)**, whereas **\(\Delta_s = 1\)** produces an error floor [2308.00634]. 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 [1912.08110].

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

$$
P_{\rm cov}=P_{\rm cov}^{S-GW}P_{\rm cov}^{GW-U},
$$

making explicit that both the satellite-side and terrestrial-side links must satisfy SNR constraints [2006.15591]. 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 [2006.15591].

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 [2406.10856]. 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 [2508.19067]. It uses per-hop in-network telemetry to compute bottleneck utilization,

$$
U_i = \frac{ack.qLen_i + txRate_i \times avgRTT}{ack.bw_i \times avgRTT},
$$

and adapts the congestion window accordingly [2508.19067]. In path-sharing scenarios, LeoTCP reports normalized delay around **\(1.06\)–\(1.07\)**, compared with **\(2.01\)–\(2.13\)** for Cubic and **\(1.37\)–\(1.69\)** for BBRv1, while also improving goodput and fairness [2508.19067]. 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 \(R \subseteq S\) such that every satellite lies within a shortest-path distance bound \(\mathbb{D}_{\text{SLO}}\) 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 [2201.05872]. 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** [2201.05872]. The practical message is that “compute everywhere” is often unnecessary, whereas geometry-aware partial deployment can satisfy latency objectives at far lower capital cost [2201.05872].

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** [2501.01293]. 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 [2501.01293].

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 **\(6\times\)** versus centralized training, **\(15\times\)** versus SL, and **\(60\times\)** versus FL; processing latency is about **\(65\times\)** lower than FL and **56%** lower than SL [2504.13479]. 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**, **\(53^\circ\)** constellation sampled every **5 minutes**, it achieves **NRMSE around \(0.06\)** and reports a **15.91%** error reduction over the best sequence-based baseline, with **inference time < \(1.5\) ms** on an RTX 4070 Ti GPU [2606.29856]. 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 [2606.04901]. 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%** [2606.04901]. 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**, **\(53^\circ\)** Walker-Delta constellation with each satellite linked to **4 nearest neighbors** [2512.21018]. Cooperative processing reduces orbit error from **\(2.95\) m** in standalone mode to **\(0.12\) m** with float ambiguities and **\(0.06\) m** with fixed ambiguities, while timing improves from **\(7.95\) ns** to about **\(0.21\) ns** and **\(0.11\) ns** respectively [2512.21018]. 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 [2512.21018].

## 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 [2201.05872]. 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 [2508.19067]. 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 [2212.02030].

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 [2006.15591]. 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 [2406.10856].

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 [1912.08110].

Source: https://www.emergentmind.com/topics/leo