---
title: 'Fully Orbital Telco: In-Orbit Network Architecture'
url: https://www.emergentmind.com/topics/fully-orbital-telco
type: topic
---

# Fully Orbital Telco: In-Orbit Network Architecture

A fully orbital telco is a telecommunications architecture in which the essential elements of network operation are placed in orbit: radio access, core-network functions, traffic routing, service breakout, and, in more recent formulations, regional processing and global orchestration. In Barros’s 2025 blueprint, the defining question is whether a complete mobile network, including radio access, core functions, traffic routing, and content delivery, can operate entirely from orbit [2507.14188]. The 2026 multi-orbit space-based data center framework generalizes this into an integrated Earth-space compute architecture spanning LEO, MEO, and GEO, in which the constellation evolves from a passive relay network into an intelligent multi-layer system [2603.18601]. The concept has antecedents in CLEO’s use of standard Internet routing in low Earth orbit [1204.3261], in enterprise LEO connectivity demonstrations by BMW Group and OneWeb [2007.12748], and in earlier proposals for in-orbit optical backbones and global multi-orbit broadband extensions [1009.5506][1407.2521].

## 1. Historical precursors and conceptual boundary

The earliest operational lineage of a fully orbital telco lies in orbital IP networking rather than in direct-to-device mobile access. The Cisco router in Low Earth Orbit (CLEO) was launched as an experimental secondary payload on the UK-DMC satellite in September 2003, and the broader Disaster Monitoring Constellation relied on the Internet Protocol for command and control and for delivery of data from payloads. Integration was possible because Surrey Satellite Technology Ltd. adopted existing commercial networking standards, specifically IP over Frame Relay over standard High-Level Data Link Control on standard serial interfaces [1204.3261].

CLEO was not a complete orbital mobile operator, but it demonstrated a critical proposition: an off-the-shelf commercial Internet router could be flown, commanded, and used for production imaging traffic in LEO with standard IP, Cisco IOS features, and delay-tolerant overlays. The operational stack included IPv4 and later IPv6, Mobile IP, IPSec, Saratoga, and a DTN Bundle Protocol agent. This established that orbital networking could inherit terrestrial protocol machinery rather than requiring a wholly bespoke protocol stack [1204.3261].

Later work sharpened the distinction between hybrid satellite connectivity and a fully orbital telco. The BMW–OneWeb proof of concept evaluated LEO satellite networks for enterprise connectivity, but it remained a bent-pipe architecture with gateway backhaul and terrestrial routing dependencies [2007.12748]. Barros’s 2025 formulation draws the boundary more explicitly by characterizing first-wave direct-to-device systems as fallback-grade, rural-only, bandwidth-limited, and fully dependent on Earth-based mobile cores for identity, session, and policy control [2507.14188]. In that sense, the term denotes more than satellite access; it denotes orbital placement of the telecom control and forwarding fabric itself.

## 2. Orbital topology and space-segment architectures

Architectures proposed under the fully orbital telco label differ in orbital altitude, backbone fabric, and division of function across layers. A production-oriented LEO design in the BMW–OneWeb extension places satellites in LEO shells at \(1{,}000\)–\(1{,}400\) km altitude, using a Walker-Delta constellation such as \(600\) satellites in \(12\) planes at inclination \(\approx 87.4^\circ\), with multi-beam phased arrays, spot beams of \(\approx 200\)–\(300\) km radius on the ground, and bi-directional optical inter-satellite links targeting per-link data rates \(\ge 10\) Gb/s [2007.12748]. Barros’s 2040 blueprint instead emphasizes a \(500\)–\(600\) km LEO Walker/polar constellation of \(O(600)\) satellites equipped with flat-panel AESAs at \(2\)–\(7\) GHz, \(1{,}000+\) simultaneous beams per satellite, and \(4\)–\(6\) optical terminals at \(1550\) nm delivering \(10\)–\(100\) Gb/s per link [2507.14188].

A distinct multi-orbit formulation assigns differentiated system roles to LEO, MEO, and GEO. In this hierarchy, LEO serves as the edge radio and inference tier for direct handset-to-satellite access, dynamic handovers, and latency-critical AI inference with propagation delay \(O(1\text{–}10\,\mathrm{ms})\); MEO acts as a regional fog tier for aggregation, cooperative traffic processing, and handover coordination across adjacent LEO cells; and GEO provides global cloud and orchestration functions, long-term storage, and the northbound interface to terrestrial NMS/NWDAF functions [2603.18601].

| Orbit layer | Principal role | Latency/task regime |
|---|---|---|
| LEO | Radio access, dynamic handovers, real-time inference | \(O(1\text{–}10\,\mathrm{ms})\) |
| MEO | Regional aggregation, distributed inference, handover coordination | Tens–low hundreds of ms |
| GEO | Global orchestration, SLA management, long-term storage | Hemisphere-wide persistent layer |

Other proposals replace the laser mesh with a physical in-orbit backbone. The 2010 LEO optic-fiber/microwave system proposes circum-terra optical-fiber loops at roughly \(1{,}200\) km altitude, with a continuous single-mode fiber of \(\sim 40{,}000\) km circumference linking on the order of \(600\) mini-satellite substations, \(10\) Gb/s per fiber span, and \(\approx 6\) Tbps aggregate across \(600\) spans [1009.5506]. At MEO, Wood et al. describe an extension of O3b through inclined elliptical orbits with \(i = 63.4^\circ\), \(e = 0.347\), two planes, and five satellites per plane, yielding continuous high-latitude coverage while preserving low-latency service characteristics at apogee [1407.2521]. Taken together, these designs show that the fully orbital telco concept is not tied to a single orbital shell or a single backbone medium.

## 3. Protocol stacks, core functions, and mobility control

Protocol design in fully orbital telco research proceeds from terrestrial Internet encapsulations toward space-resident mobile-core functions. CLEO’s on-board stack ran over standard space-qualified serial lines, with HDLC framing on each serial link, Frame Relay inside HDLC, IPv4 and later IPv6 at the network layer, and TCP/UDP, Saratoga, and a DTN Bundle Protocol agent above that. On each SSTL–CLEO serial link the encapsulation was IP over Frame Relay over HDLC, with a worst-case overhead per packet of \(\approx 8\) bytes and link-level utilization \(\approx 99.5\%\) for a standard \(1500\)-byte IP packet [1204.3261].

Recent mobile-network proposals move substantially further. The BMW–OneWeb production blueprint adopts 3GPP Rel-17 NTN adaptations, including RRC modifications for long RTT, timing advance changes, and Doppler compensation in PHY/MAC, and places MME/AMF functions in-satellite for the control plane while retaining S-GW/P-GW or UPF on the ground for the user plane [2007.12748]. Barros’s 2040 architecture completes the migration by placing AMF, SMF, and AUSF microservices on board, distributing UPF instances across satellites, caching UDM/HSS tables and locally stored cryptographic keys, and enforcing slice-level SLAs and geo-fenced lawful-intercept policies through an on-board PCF [2507.14188].

Mobility management is correspondingly reworked. In CLEO, Mobile IP was used so that a ground-side VMOC controller could change its IP attachment point without changing the home agent, while TCP sessions still broke on pass handover, motivating Saratoga and the DTN Bundle Protocol for store-and-forward continuity [1204.3261]. In the BMW–OneWeb architecture, inter-satellite handover is make-before-break, with the user terminal maintaining a dual link to the current and next satellite, duplicating packets during transition, and releasing the old link upon a \(7\) dB stronger new link; satellite-to-terrestrial handover uses dual connectivity and IP session continuity via Proxy-MIP or S-GW relocation [2007.12748].

SkyOctopus extends this logic to multi-anchor mobile satellite networking by placing a traffic classifier, the S-UPF, on each satellite and selecting among globally distributed anchors on a per-flow basis. Its optimization target is

$$
L_{\mathrm{total}}(u,g,a)=L_{u\to s}+L_{s\to a}+L_{a\to g},
$$

with the optimal anchor chosen as

$$
a^*=\arg\min_{a\in A} L_{\mathrm{total}}(u,g,a).
$$

The implementation uses enhanced Open5GS and UERANSIM, parallel PFCP session establishment to multiple anchors, higher-priority PDR installation for flow steering, and GTP-U tunnels from the S-UPF to the selected anchor [2502.03250].

At larger scale, the multi-orbit SBDC model introduces compute-aware routing over a time-expanded contact graph, in which edge weights combine propagation delay, inverse capacity, predicted compute availability, energy zone, and thermal headroom. The routing weight is given as

$$
w_{ij}(t)=\lambda\tau_{ij}(t)+\mu \frac{1}{C_{ij}(t)}+\nu g(E_i(t),\Theta_i(t)),
$$

and the control plane is explicitly hierarchical: a LEO embedded local controller for immediate forwarding, a MEO regional orchestrator running multi-agent RL, and a GEO global orchestrator synchronizing the digital twin and enforcing SLAs [2603.18601].

## 4. Link budgets, latency models, and achievable bandwidth

The physical and network performance of fully orbital telco systems is typically expressed through standard free-space and capacity equations. A recurrent model is

$$
L_{fs}(d)=20\log_{10}(4\pi d/\lambda)\,[\mathrm{dB}],
$$

paired with the Shannon relation

$$
C=B\log_2(1+\mathrm{SNR}),
$$

and a latency approximation such as

$$
T_{\mathrm{latency}}=2d/c+T_{\mathrm{processing}}.
$$

These equations appear across LEO microwave, optical ISL, and in-orbit fiber proposals [1009.5506][2007.12748][2507.14188].

For the BMW–OneWeb LEO design, a \(1.2\times10^6\) m sat–user slant range gives propagation of \(\approx 8\) ms one-way and \(16\) ms roundtrip, with \(T_{\mathrm{processing}}\approx 4\text{–}8\) ms, implying \(\approx 20\text{–}25\) ms optimum end-to-end latency. In the demonstration, observed ping was \(\approx 35\text{–}45\) ms because of bent-pipe via a single GW, terrestrial routing hops, and UDP overhead. With a \(100\) MHz Ku-band carrier and SNR \(=10\) dB, the example capacity is \(\approx 346\) Mb/s per beam, while the demo fixed Terminal CCM to \(60\) Mb/s and measured download \(\approx 60\text{–}65\) Mb/s and upload \(\approx 65\text{–}70\) Mb/s [2007.12748].

Barros’s urban-grade LEO model uses \(R=550\) km and \(f=2\) GHz, giving \(\mathrm{FSPL}\approx 153\) dB. The SNR expression includes \(G_{\mathrm{rx}}=-17\) dBi for a smartphone, \(L_{\mathrm{urban}}=30\) dB, \(kTB\approx -114\) dBm for \(B=10\) MHz, and \(M=3\) dB implementation margin; with satellite array gain \(G_{\mathrm{array}}\approx 36\) dB, rooftop line-of-sight SNR is \(\approx +7\) dB. A \(64\)-QAM target requires \(\mathrm{SNR}\ge 15\) dB and \(\eta\approx 6\) bps/Hz, while an example with \(B=100\) MHz and \(\eta=4\) bps/Hz yields \(C=400\) Mbps per beam. One-hop optical mesh latency is \(\approx 1\) ms, and \(3\)–\(5\)-hop paths yield \(<10\) ms extra propagation beyond the \(\sim 1.8\) ms one-way RF delay [2507.14188].

The multi-orbit SBDC paper reports representative comparative metrics rather than a deployment measurement:

| Layer | One-way latency | Throughput (max) |
|---|---|---|
| Ground DC | \(250\,\mathrm{ms}\) | \(100\,\mathrm{Gb/s}\) |
| LEO SBDC | \(20\,\mathrm{ms}\) | \(50\,\mathrm{Gb/s}\) |
| MEO SBDC | \(80\,\mathrm{ms}\) | \(200\,\mathrm{Gb/s}\) |
| GEO SBDC | \(250\,\mathrm{ms}\) | \(400\,\mathrm{Gb/s}\) |

The same study also reports data reduction of \(10\times\) onboard at LEO, \(5\times\) at MEO regional aggregation, a real-time wildfire detection pipeline with \(\approx 50\) ms sensor-to-alert latency versus \(400\) ms for a ground data center, and radiative-cooled AI accelerators with \(\approx 50\%\) lower PUE than terrestrial edges [2603.18601].

Alternative backbone media produce different operating points. The in-orbit optical-fiber proposal assigns microwave per-beam bandwidths of hundreds of MHz with \(C\sim 100\text{–}500\) Mbps, free-space optical operational systems at \(\ge 2.7\) Gb/s, and end-to-end interactive loop latency of \(\approx 208\) ms for Earth-to-LEO plus full ring traverse, compared with \(\approx 430\) ms for GEO [1009.5506].

## 5. Experimental results and service regimes

Demonstrations and simulations collectively indicate that the service regime of a fully orbital telco depends on whether the system remains bent-pipe, adopts distributed anchor selection, or moves to orbital core placement and dense beamforming. The BMW Group–OneWeb proof of concept evaluated entertainment and business productivity streaming services, handover to 4G, VPN use, and cloud applications. Across three tests, it reported a \(2\text{–}3\times\) faster ping rate, \(4\text{–}5\times\) faster download rates, and \(30\text{–}60\times\) faster upload rates relative to the comparison baseline, with a Ka band gateway located \(50\) miles away handling full backhaul [2007.12748].

SkyOctopus provides the most explicit evidence that mobile-satellite latency is strongly affected by anchor placement rather than only by orbital altitude. Its prototype uses actual LEO constellations such as Starlink, Kuiper, and OneWeb, with \(100\) UEs moving randomly over the Atlantic, \(25\) destinations selected from the top-\(50\) global websites, \(40\) AWS PoPs, and \(h=20\) anchors. For Starlink, average end-to-end latency falls from \(187.7\) ms in Standard NTN to \(70.5\) ms in SkyOctopus, with maximum latency reduced from \(396.6\) ms to \(163.8\) ms, corresponding to a \(53\%\) reduction versus the standard scheme. Session establishment time is \(\approx 713\) ms independent of anchor count \((\pm 13\%)\), compared with insertion-based growth to \(\sim 4.5\) s for \(20\) anchors, an overall \(86\%\) reduction in setup time. Under anchor-distribution algorithms with \(h=20\), the Greedy method yields \(67\) ms for Starlink, \(64\) ms for Kuiper, and \(62\) ms for OneWeb [2502.03250].

Urban-grade direct-to-device simulation places a harder bound on feasibility. With a \(64\times64\) array and \(100\) MHz bandwidth in S-band, rooftop LOS users sustain \(64\)-QAM with mean throughput \(\approx 50\) Mbps and \(95\)th-percentile \(\ge 30\) Mbps. Street-level direct users average \(<5\) Mbps and experience \(>30\%\) outage at \(10\) MHz channels. Relay-assisted mode using roof-mounted nano-anchors raises street-level throughput to \(20\text{–}30\) Mbps with \(>90\%\) reliability. The beam-level model gives \(C_{\mathrm{beam}}\approx 400\) Mbps for rooftop LOS, allowing up to \(40\) users at \(10\) Mbps, and \(C_{\mathrm{beam}}\approx 100\) Mbps for street-level NLOS direct, allowing \(\sim 10\) users at the same rate; rooftop or façade relay adds \(+20\) dB link gain and pushes \(C_{\mathrm{beam}}\approx 500\) Mbps [2507.14188].

These evaluations jointly indicate that the phrase “fully orbital” does not imply a single uniform service class. Enterprise backhaul, vehicular hybrid connectivity, direct handset access, and onboard AI offload stress different parts of the architecture: anchor selection, beam density, compute placement, or inter-satellite backhaul.

## 6. Engineering constraints, governance, and future directions

The principal obstacles identified in the literature are engineering, operational, and regulatory rather than purely geometric. Barros’s blueprint states that the remaining constraints are power, thermal dissipation, compute radiation hardening, and regulatory models, and that these are engineering bottlenecks, not physical limits [2507.14188]. The quantitative budget is severe: solar array output is \(0.5\text{–}2\) kW depending on satellite size; beamforming plus compute draw is \(1\text{–}1.5\) kW; radiative cooling is limited to \(\approx 100\) W/m\(^2\); rad-hard SoCs offer \(<5\) W of computing at \(<100\) MHz clocks; and on-board RAN plus core requires \(>100\) GOPS. Proposed mitigations include GaN amplifiers \((>60\%\) efficiency), dynamic beam power scaling, solar-oriented scheduling, deployable radiators, phase-change heat sinks, distributed FPGA clusters, lightweight containerization, photonic interconnects, and neuromorphic inference [2507.14188].

Operational experience from orbital IP routing shows that these constraints are not abstract. In CLEO, no permanent latch-ups occurred, but occasional soft resets were detected, and precise time tagging of DTN bundles required synchronization between RTEMS on the SSTL computer and CLEO’s IOS clock via SMPTE-style IRIG-B timecode over RS-422. The paper’s recommendations for scaling included native IP routing such as OSPF over LEO cross-links where crosslink availability and low latency can be guaranteed, simplified GRE or UDP tunneling over HDLC when multiple virtual circuits are unnecessary, and DTN bundle agents integrated with on-board solid-state mass storage so that multi-pass transfers can survive router reboots or power cycles [1204.3261].

At constellation scale, the 2026 SBDC framework adds a further layer of research problems: radiation-induced soft errors with TID up to \(100\) krad, limited radiator rejection under the Stefan–Boltzmann constraint, debris collision risk, mobility-aware scheduling over short LEO passes, trust-aware orchestration with attestation logs and provenance, autonomous FDIR under partial observability, and standard inter-domain protocols akin to BGP for stove-piped LEO, MEO, and GEO fleets to advertise compute, trust posture, and SLA terms. Regulatory questions include joint spectrum-compute licensing, jurisdiction and data sovereignty, and extensions to 3GPP NTN and ETSI edge standards for orbital resource advertisement, compute placement APIs, and telemetry schemas [2603.18601].

Roadmaps in the literature remain staged rather than instantaneous. Barros divides the period from 2025 to 2040 into Foundational Integration, Orbital Autonomy, and Full Terrestrial Decoupling, progressing from \(100\text{–}200\) beams and partial PHY/MAC onboard to \(>1{,}024\) beams per satellite, full 5G SA core in orbit, \(50\text{–}100\) Mbps sustained per-user rates in megacities, inter-satellite handover \(<100\) ms, session-drop \(<0.1\%\), and Earth-independent operation without gateway fallback [2507.14188]. The BMW–OneWeb blueprint proposes an adjacent path: upgrade to regenerative payloads with ISLs, deploy flat-panel user terminals in vehicles and enterprise sites, integrate with 5G NR NTN Release 17+, automate packet-loss-based satellite-to-terrestrial handoff, and expand toward multi-shell architectures [2007.12748].

A plausible implication is that the fully orbital telco is best understood not as a single finished system but as a convergence point for several research trajectories: orbital IP routing, regenerative LEO access, in-space core-network functions, multi-anchor path optimization, optical mesh backhaul, and multi-orbit compute orchestration. Across those trajectories, the central claim remains consistent: telecommunications can move from orbit as transport medium to orbit as the primary locus of networking intelligence.

Source: https://www.emergentmind.com/topics/fully-orbital-telco