Scenarios and Routing Requirements for Mega-Constellation LEO Satellite Networks

Introduction In recent years, the deployment scale of Low Earth Orbit (LEO) mega-constellations has reached the threshold of tens of thousands of nodes. Early discussions on satellite routing primarily focused on utilizing mature terrestrial routing protocols (e.g., IS-IS) combined with area proxies or time-variant schedules to resolve scalability issues in the space segment. However, with the exponential advancement of space laser communications in terms of bandwidth and stability, the underlying physical architecture of satellite networks has undergone a fundamental shift. Satellite networks are progressively decoupling from their heavy reliance on dense terrestrial Ground Stations (GS) and evolving into highly autonomous, vacuum-based spaceborne routing networks. Traditional terrestrial routing protocols are designed with the core assumption of relatively stable topologies and low link-state change rates. Directly applying the global convergence paradigm of the terrestrial Internet (such as Global Link-State Routing Architectures) to space topologies leads to severe link-state advertisement storms and persistent routing obsolescence due to high-frequency topology variations. This document systematically reviews the realistic scenarios of satellite routing networks, evaluates existing mitigation mechanisms, and defines the functional and performance requirements that satellite routing protocols must satisfy.

Conventions

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are defined for use in this document:

ISL (Inter-Satellite Link): A link between two satellite nodes, specifically referring to vacuum photon transmission links realized via space laser communications in this document.
GS (Ground Station): Terrestrial facilities responsible for connecting the space segment to land-based network infrastructures.
PoP (Point of Presence): Interface points where the satellite network connects to the terrestrial Internet core.
Time-Variant Topology: The characteristic of LEO satellite networks where inter-satellite geometric relationships and link reachability change periodically, predictably, yet at high frequencies due to high-speed orbital dynamics.

Use Cases and Network Scenarios

Evolution from Dense GS to Spaceborne Laser Transit Networks Early commercial satellite networks relied heavily on the dense deployment of local Ground Stations. In this mode, satellites merely acted as "bent-pipes in the sky," and the data flow exhibited a simplistic single-hop structure:

Traditional Data Flow under Dense Ground Station Deployment [ User Terminal ] | v (Uplink) [ Space Satellite A ] | v (Downlink) [ Local Dense GS ] ---> [ Terrestrial Internet Core ] However, in actual deployment, global GS construction faces complex transnational regulatory constraints, exorbitant construction and maintenance costs, and geopolitical security risks. Consequently, most commercial constellations cannot achieve dense global ground deployment. With the comprehensive adoption of vacuum laser ISLs in next-generation constellations, user data flows have shifted to a non-dense ground deployment mode utilizing multi-hop spaceborne transits:

Multi-hop Space Transit Data Flow in Non-Dense GS Regions [ User Antenna ] | v (Uplink) [ Space Satellite A ] --(Vacuum Laser ISL)--> [ Space Satellite B ] | (Vacuum Laser ISL) v [ Remote GS ] <-- (Downlink, Thousands of km) -- [ Space Satellite C ] | v [ Terrestrial Internet PoP ]

Architectural Evolution of LEO Satellite Networks Dense GS Era +---------------+ | GS | +-------+-------+ | SAT | UT | v ISL-Assisted Era GS ---- SAT ---- SAT \ \ UT | v Spaceborne Routing Era UT -- SAT -- SAT -- SAT -- SAT | GS | PoP As ISL capabilities improve and gateway density decreases, the space segment progressively evolves from a simple access network into an autonomous routing network.

Objective Assessment of Performance Bottlenecks Prior network analyses asserted that performance degradation in non-dense GS regions stems directly from the scarcity of local ground stations. However, the extended physical distance between users and ground stations, which necessitates multi-hop inter-satellite transit before downlinking, does not inherently entail a degradation in communication performance. On the contrary, since light propagates approximately 30% faster in a vacuum than in standard terrestrial silica fiber optics, data transmission via spaceborne laser networks can potentially achieve higher speeds than conventional terrestrial networks. When providing long-distance inter-continental transit (e.g., New York to London, Tokyo to Los Angeles, and Sydney to Singapore), the theoretical physical latency of inter-satellite laser links is lower than that of traditional submarine fiber cables. Operational engineering practices demonstrate that the performance ceiling of satellite routing networks is actually restricted by the highly non-uniform global distribution of terrestrial Internet Points of Presence (PoPs). With the enhanced transit capabilities of the space segment, the routing and scheduling efficiency of data packets within the space network directly determines whether they can be precisely and efficiently delivered to the optimal terrestrial PoP egress.

Limitations of Global Convergence Paradigms A global link-state routing architecture computes routes by distributing link-state topology information and running SPF (Shortest Path First) computation. In LEO constellations with tens of thousands of nodes, directly applying network-wide fine-grained link-state flooding and globally synchronized convergence may face significant scalability and stability challenges. This is not merely a local issue that can be solved by parameter tuning; rather, it reflects a fundamental mismatch between the design assumptions of such mechanisms and the physical characteristics of satellite networks.

Conflict Between Global Consistency and Time-Variant Topologies LEO satellites move at speeds greater than 27,000 km/h. Due to relative geometric changes, satellite attitude control, and optical pointing adjustment, inter-satellite link events, including link disruption and peer change, may occur on timescales ranging from seconds to minutes. A global link-state routing architecture relies heavily on multi-hop control-message flooding across the network to maintain a consistent link-state view. In a constellation with tens of thousands of nodes, the time required for control messages to propagate across the network may be significantly longer than the topology change interval. As a result, convergence may lag behind topology changes, and route computation may rely on stale views.

Control Plane Overhead Scaling with Network Size When the number of constellation nodes reaches tens of thousands, the number of dynamic inter-satellite links also increases with the scale of the constellation. Any regular link up/down event may trigger network-wide flooding. The control plane would need to frequently encapsulate and transmit link-state advertisements, which may lead to excessive control-plane churn in the space segment. This can consume scarce inter-satellite control-channel resources and significantly reduce bandwidth available for user data traffic.

Engineering Challenges of Network-Wide Shortest-Path Convergence In a highly dynamic satellite network, propagation delay and continuous topology changes make it difficult for all nodes to obtain a fully consistent and up-to-date topology view at the same time. Under such conditions, frequent attempts to achieve network-wide consistent shortest-path convergence may cause repeated computation, path oscillation, and forwarding instability, thereby affecting service continuity and reliability.

Mismatch between Network-Wide State Maintenance and On-Board Resource Constraints Network-wide link-state routing requires participating nodes to maintain large-scale topology state and perform corresponding path computation. Compared with terrestrial equipment, on-board computing environments are constrained by power, thermal dissipation, storage, and radiation conditions. Requiring satellite nodes to maintain network-wide fine-grained state and frequently perform large-scale path computation would significantly increase operational burden and engineering risk.

Existing Mitigation Approaches The challenges discussed in the previous section have motivated the development of several architectural approaches intended to improve the scalability and operational feasibility of large-scale satellite networks. Rather than attempting to maintain complete network-wide topology awareness at all times, these approaches seek to reduce routing complexity through infrastructure assistance, topology abstraction, or predictive mechanisms. Although such techniques significantly improve practicality in current deployments, important challenges remain as satellite networks continue evolving toward increasingly autonomous spaceborne routing systems.

Ground-Centric Architectures Many existing broadband satellite systems minimize onboard routing complexity by relying heavily on terrestrial infrastructure. In such architectures, user traffic is forwarded to a visible satellite and subsequently delivered to a nearby Ground Station (GS) whenever possible. The terrestrial Internet then performs the majority of long-distance transport and routing functions. Inter-satellite links primarily serve as extensions of gateway reachability rather than as a fully autonomous spaceborne routing fabric. This design offers significant operational advantages. Satellites are not required to maintain extensive routing state, route computation complexity remains low, and network management can leverage the mature capabilities of terrestrial infrastructure. The success of current commercial deployments demonstrates the practicality of this approach under conditions where sufficient gateway coverage is available. However, the effectiveness of ground-centric architectures depends heavily on the availability of geographically distributed ground infrastructure. As future constellations expand service coverage to oceans, polar regions, remote territories, and long-distance intercontinental routes, traffic increasingly traverses multiple inter-satellite hops before reaching a gateway. In such scenarios, the space segment itself becomes an active routing network rather than a simple relay system. Routing efficiency within the satellite constellation directly influences end-to-end performance, making distributed spaceborne routing capabilities increasingly important.

Topology Abstraction Architecture Based on Orbital Domain Partitioning To improve the scalability of large satellite networks, recent architectural proposals have introduced various forms of topology abstraction and hierarchical organization.proposes a satellite network routing architecture based on existing routing protocols and mechanisms. Its core idea is to organize satellites in adjacent orbits into larger routing areas and to reduce topology visibility across area boundaries through area abstraction, thereby limiting the amount of link-state information distributed across the entire network.

Example of Hierarchical Topology Abstraction +------------------+ | Domain A | | SAT SAT SAT | | SAT SAT SAT | +------------------+ | Abstract View | +------------------+ | Domain B | | SAT SAT SAT | | SAT SAT SAT | +------------------+ This architecture also uses the predictability of satellite orbital motion to introduce scheduled link-connectivity change information into the routing system. For predictable link disruption or topology adjustment, the routing system can obtain relevant information in advance and perform necessary routing adjustment before the actual change occurs, thereby reducing the impact of periodic topology changes on the control plane. These approaches show that orbital domain partitioning, topology abstraction, and scheduled link awareness can effectively mitigate routing-state scaling issues in large-scale satellite networks. focuses on providing a satellite network routing architecture based on existing routing protocols and forwarding mechanisms, and provides an important reference for subsequent routing-requirement analysis and protocol-mechanism design for LEO mega-constellations.

Remaining Challenges Existing approaches have significantly advanced the operational capability of satellite networks and demonstrated practical methods for managing large constellations. In particular, these approaches often rely on assumptions of predictable topology evolution based on orbital mechanics and scheduled connectivity information, as well as hierarchical routing abstractions (e.g., backbone and non-backbone role separation) to improve scalability. However, such assumptions may not fully capture the stochastic nature of inter-satellite link dynamics or the homogeneous characteristics of satellite nodes in large-scale LEO constellations. As LEO mega-constellations evolve toward more autonomous satellite transport networks, several challenges remain that need to be considered in subsequent routing-requirement and protocol-design work. First, routing-domain partitioning still depends on the link stability, orbital configuration, and connectivity characteristics of a specific constellation. How to determine routing areas that are stable, connected, and bounded in size under different constellation configurations and link conditions remains an open issue. Second, scheduled topology changes can be handled in advance through scheduling information, but unplanned link failures remain unavoidable. The routing system still needs to maintain service continuity while limiting the impact scope, preventing local failures from evolving into large-scale control-plane disturbance. Third, the routing protocol needs to clarify the propagation scope of state information, how scheduled changes and unplanned changes should be handled differently, what granularity of routing state satellite nodes should maintain, and how route computation should adapt to constrained on-board resources. Fourth, the routing system needs to maintain cross-region reachability, path stability, and fast recovery without requiring a complete network-wide fine-grained topology view. These remaining challenges motivate the routing requirements described in the next section.

Core Routing Requirements for Mega-Constellations Based on the above scenarios and constraints, the design objective of a routing protocol for LEO mega-constellations SHOULD NOT be to frequently compute instantaneous globally optimal paths. Instead, the protocol SHOULD maintain network reachability, control-plane stability, path continuity, and fast recovery under constrained state size and constrained computing resources. The protocol SHOULD satisfy the following core requirements.

Scalable Routing-State Control The routing protocol SHOULD support routing-state control in scenarios with tens of thousands of highly dynamic satellite nodes. The protocol SHOULD NOT require every satellite node to maintain a complete network-wide fine-grained topology view, and SHOULD NOT trigger network-wide link-state flooding due to local link changes. Any link disruption triggered by local dynamics, such as polar-region traversal or minor attitude adjustment, SHOULD be handled preferentially within the affected routing area. Only when a local event affects cross-region reachability or critical forwarding capability SHOULD necessary abstracted state changes be advertised externally.

Awareness of Scheduled Topology Changes Because satellite orbital mechanics are highly predictable, the routing protocol SHOULD incorporate time-varying connectivity plans distributed by the management plane. For predictable link disruption, link establishment, peer change, or bandwidth variation, the protocol SHOULD be able to receive and use the corresponding planning information. The protocol SHOULD support necessary metric adjustment, path preparation, or forwarding-state update before scheduled topology changes occur, in order to reduce service interruption, packet loss, and control-plane instability.

Fast Recovery from Unplanned Failures The routing protocol SHOULD be able to handle unplanned link failures and abrupt link-quality degradation. For sudden link failures, short-term loss of lock, equipment faults, or local congestion, the protocol SHOULD support fast detection, fast bypass, and local recovery. The protocol SHOULD limit the impact of failures to a local scope and, when necessary, advertise only abstracted reachability changes externally.

Lightweight Forwarding State A satellite node SHOULD NOT be required to maintain a complete global forwarding table containing massive terrestrial user prefixes or all constellation-node information. The protocol SHOULD support prefix aggregation, area abstraction, label forwarding, or other lightweight mechanisms to reduce satellite forwarding-state size. The forwarding mechanism SHOULD adapt to the storage, computing, power, and reliability constraints of on-board equipment, and SHOULD support stable end-to-end forwarding within a limited forwarding-table size.

On-Board Autonomy with Ground Assistance The routing protocol SHOULD support basic routing operation on satellite nodes in the absence of continuous ground control. Ground systems can provide constellation plans, policy configuration, and global optimization information. The satellite routing system SHOULD provide a certain level of autonomous operation capability to support sparse ground-station coverage, transoceanic and intercontinental relay, and long-distance inter-satellite multi-hop routing scenarios.

Quantitative Objectives and Metrics To support objective evaluation and conformance testing, satellite routing protocols SHOULD satisfy the following quantitative engineering baselines in large-scale deployments. Specific values MAY be further refined according to constellation scale, link capability, and service class.

Node Scalability: The routing control plane SHOULD support at least 10,000 highly dynamic satellite nodes in concurrent operation and SHOULD be scalable toward 50,000 nodes. Persistent control-plane congestion, memory exhaustion, or route-computation failure SHOULD NOT occur.
Impact of Scheduled Handover: For predictable link-state changes, the routing protocol SHOULD support advance awareness, path preparation, and forwarding-state update. Link handover time SHOULD be no greater than 100 ms, and near-seamless path migration SHOULD be supported.
Unplanned Failure Recovery Time: Under a single-link failure, the service recovery time from link-failure detection to traffic switchover to a backup path SHOULD be no greater than 100 ms.
Control Plane Overhead: Under continuously highly dynamic constellation operation, the bandwidth consumed by routing protocol control messages SHOULD NOT exceed 1% of the total available bandwidth of any single physical link.

Security Considerations Due to their exposed physical nature, spaceborne wireless and laser links face significantly higher risks of eavesdropping, malicious packet injection, and node spoofing than terrestrial fiber infrastructure. Distributed routing protocols MUST implement lightweight, highly cryptographic authentication mechanisms for localized flooded control messages to prevent malicious or compromised nodes from introducing forged link states that cause network-wide traffic blackholes or Denial-of-Service (DoS) attacks.

IANA Considerations This document has no IANA actions.