]> China Mobile

CN yangfeng@chinamobile.com

China Satellite Network Group

CN pingdu@ustc.edu

ZTE

CN xiao.min2@zte.com.cn

RTG rtgwg LEO, satellite, routing, geographic coding, H3, dynamic topology, ephemeris, IP addressing This document proposes a dynamic routing mechanism for Low Earth Orbit(LEO) satellite networks based on geographic region coding. By decoupling IP addressing from physical location, the mechanism uses hierarchical geographic grid codes (inspired by Uber's H3 spatial index) as temporary IP addresses for satellites. Routing decisions are made based on the relative geographic position encoded in the destination address, rather than traditional prefix-based IP routing. Satellite ephemeris data is leveraged to pre-compute routing tables for discrete time slices, eliminating the need for real-time link-state flooding and enabling stable, predictable routing in highly dynamic satellite topologies.

Introduction

Background Low Earth Orbit (LEO) satellite constellations, exemplified by Starlink and OneWeb, are rapidly transforming global Internet access. Compared to traditional Geostationary Earth Orbit (GEO) satellites, LEO satellites offer significantly lower transmission delay (20-50 ms), higher bandwidth efficiency, and lower launch costs. However, LEO satellite networks present unique technical challenges, most notably the highly dynamic nature of network topology. Satellites in LEO constellations travel at orbital velocities of approximately 7.5-7.8 km/s, completing an orbit in roughly 90 minutes. Each satellite typically maintains four inter-satellite links (ISLs): two intra-plane links (forward and backward along the same orbital plane) and two inter-plane links (left and right to adjacent orbital planes). Intra-plane ISLs remain relatively stable due to minimal relative motion between co-orbital satellites. In contrast, inter-plane ISLs face continuous topology changes because adjacent orbital planes are non-parallel, and satellites can only maintain stable inter-plane connections with co-directional neighboring satellites for limited time periods.

Problem Statement The extreme dynamicity of LEO satellite networks renders traditional routing protocols fundamentally unsuitable: Topology Dynamicity Breaks Traditional Routing Traditional routing protocols such as OSPF , IS-IS , and BGP were designed for static or low-dynamicity terrestrial networks. Their operational model relies on periodic or event-triggered synchronization of routing information across the entire network. In LEO satellite networks, this approach fails catastrophically: Massive state synchronization overhead: Frequent topology changes trigger continuous link-state flooding, consuming enormous bandwidth and processing resources. Convergence failure: With handovers occurring every 11-15 seconds and network scales reaching tens of thousands of satellites, traditional protocols cannot converge within the interval between topology changes. The network remains in a perpetual state of re-convergence. Routing loops and black holes: Rapid topology changes cause routing inconsistencies, leading to transient loops and packet loss. Resource exhaustion: Satellites have limited computational power, memory, and bandwidth. Processing hundreds of thousands of terrestrial routes while simultaneously managing constant topology updates exhausts these scarce resources. Fixed IP Addressing Conflicts with Dynamic Topology Traditional IP addressing binds prefixes to geographic regions. In LEO networks, the same geographic area is served by different satellites at different times. Using fixed IP prefixes would require updating prefix bindings across the entire network every 15 seconds, which is operationally infeasible. Predictable Motion Is Underutilized Although satellite topology is highly dynamic, satellite motion follows entirely predictable orbital mechanics. Existing routing approaches fail to exploit this determinism, instead using stochastic methods designed for uncertain environments. Terrestrial Route Injection Overwhelms Satellites The terrestrial Internet contains hundreds of thousands of BGP prefixes. Injecting these into the satellite network would cause each satellite to maintain massive routing tables, consume bandwidth for route synchronization, and exhaust onboard resources. Satellites would spend more resources learning routes than forwarding traffic.

Objectives The proposed mechanism aims to: Decouple addressing from physical location to hide satellite mobility from the routing system. Eliminate the need for network-wide routing state synchronization. Reduce onboard computational and memory requirements. Leverage predictable satellite ephemeris for pre-computed, time-sliced routing tables. Enable seamless integration between the dynamic satellite segment and the static terrestrial Internet.

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 This document uses the following additional terms: DEV (Device): The user devices (e.g., laptop). Ephemeris: Precise orbital parameters that define a satellite's position as a function of time. GNSS: Global Navigation Satellite System. GRC (Geographic Region Code): A hierarchical spatial index code representing a geographic area on Earth's surface. GS (Ground Station): The satellite operator receiver. WR (Wifi Router): Intra-plane ISL: ISL between satellites in the same orbital plane. Inter-plane ISL: ISL between satellites in adjacent orbital planes. ISL (Inter-satellite link): PoP (Point of Presence): Segmented Longest Match: A modified longest prefix matching algorithm that operates on fixed-length segments rather than arbitrary prefix lengths. Time Slice: A discrete time interval during which the satellite topology is considered stable for routing purposes. UT (User Terminal): The user satellite receiver (e.g., Starlink terminal UT).

Architecture Overview

Network Segmentation The overall architecture includes UT, user WR, UT, inter-satellite links, GS and PoP that connect satellite networks to the terrestrial Internet. Due to the high relative velocity between satellites and ground infrastructure, frequent handovers are required. For example, Starlink performs beam switching approximately every 15 seconds.

|WR |<->|UT|<->|LEO|<--->|LEO|<->|GS|<->|PoP|<->|INET| | | | | | | |Sat| |Sat| | | | | | | +---+ +---+ +--+ +---+ +---+ +--+ +---+ +----+ ^ ^ ^ ^ |<-Terrestrial->|<----- Satellite -----> |<-Terrestrial->| | Segment | Segment | Segment | - INET: Internet ]]>

The end-to-end network is logically divided into two segments: Terrestrial Segment: From the DEV to the UT, and from the GS to the PoP and beyond. This segment uses traditional IP prefix-based routing (IPv4 or IPv6 ). Satellite Segment: From the UT through the inter-satellite network to the GS. This segment uses geographic region coding for IP address, decoupling the destination address from the current physical location of the serving satellite. It is supposed the user traffic will be encapsulated in tunnel in this proposal.

Key Design Principles Address-Satellite Decoupling: the address of satellite is not fixed, but periodically changed per geographic region coding. Predictive Routing: Routing tables are pre-computed using satellite ephemeris data for each time slice, eliminating runtime route computation and flooding. Localized State: Each satellite only needs to know connectivity information for its own and adjacent orbital planes, not the entire network topology. Directional Forwarding: Routing decisions resolve to one of six directions: North, South, East, West, Down (to ground), or Up (to upper level shell). Centralized Route Computation: A ground control unit centrally computes time-sliced routing tables using global constellation ephemeris and distributes validated routing tables to satellites, reducing onboard computation and ensuring routing consistency.

Geographic Region Coding

Hierarchical Grid Partitioning The Earth's surface is partitioned into a hierarchical grid system. This document uses the H3 spatial index as a reference model, but other hierarchical geospatial indexing systems MAY be used. The H3 system partitions the globe into 122 base (Level-0) hexagonal cells. Each Level-0 cell is subdivided into 7 Level-1 cells, each Level-1 cell into 7 Level-2 cells, and so on. This yields: Level 0: 122 regions Level 1: 122 x 7 = 854 regions Level 2: 122 x 7^2 = 5,978 regions Level 3: 122 x 7^3 = 41,846 regions Level 4: 122 x 7^4 = 292,922 regions Level 5: 122 x 7^5 = 2,050,454 regions Level 6: 122 x 7^6 = 14,353,178 regions At Level 6, the smallest region has an area of 36 square kilometer, providing sufficient granularity for LEO satellite routing. In reality, make sure each cell has one satellite is the finest granularity. According to this address allocation schema, the satellite will have dynamic address and UT/GS will have fixed address.

Geographic Region Code (GRC) Format The GRC is encoded as a 32-bit value compatible with IPv4 addressing, enabling reuse of existing IPv4 forwarding hardware and software with minimal modifications. In case of IPv6, it can also be easily fit into 128 bits address.

Segmented Longest Match Traditional IP routing uses longest prefix match with arbitrary prefix lengths (0-32 bits for IPv4). For GRC-based routing, a segmented longest match algorithm is used: Match boundaries are fixed at specific bit positions corresponding to hierarchy levels: 11, 14, 17, 20, 23, 26, 29, and 32 bits. A routing table lookup attempts to match the destination GRC at each of these fixed lengths, starting from the longest (most specific) and falling back to shorter (less specific) matches. This approach is compatible with existing trie-based or TCAM-based forwarding hardware without modifications.

Satellite Address Binding

Dynamic Address Assignment Satellites dynamically bind GRCs to their interfaces based on their current orbital position: A satellite continuously determines its coordinates using onboard GNSS or ephemeris-based position calculation. The geographic coding module converts the satellite's coordinates into the corresponding GRC at the appropriate hierarchy level. When a satellite enters a new geographic region, it updates its interface addresses to reflect the new GRC. A satellite MAY bind multiple GRCs simultaneously (analogous to multiple IP addresses on a single interface), representing the multiple geographic regions it currently covers.

Interface Direction Mapping Each satellite maintains 6 logical interfaces corresponding to directional ISLs: North: Intra-plane link to the satellite ahead in the orbital direction. South: Intra-plane link to the satellite behind in the orbital direction. East: Inter-plane link to the satellite in the adjacent orbital plane to the east. West: Inter-plane link to the satellite in the adjacent orbital plane to the west. Down: Link to ground (UT or GS) or lower level shell. Up: Link from ground to satellite or upper level shell. All interfaces are bound with a GRC-based address, and routing table determine the egress direction based on the destination GRC.

Time-Sliced Routing

Ephemeris-Based Pre-computation Satellite ephemeris data provides precise orbital parameters, enabling the prediction of each satellite's position at any future time. The routing system leverages this predictability as follows: The orbital period is divided into discrete time slices. The duration of each time slice is a configuration parameter, typically set to be shorter than the minimum handover interval (range from seconds to minutes). A ground control unit computes the predicted positions and connectivity of all satellites for each time slice using constellation ephemeris. Based on these positions, the coverage area of each satellite is determined, and the set of GRCs served by each satellite is identified. For each satellite and each time slice, a routing table is centrally computed that maps destination GRCs to egress directions (North, South, East, West, Down, Up). The computed routing tables are validated and distributed to satellites prior to the corresponding time slice. Satellites locally store and activate the downloaded routing tables at time-slice boundaries.

Routing Table Structure The routing table for each time slice MUST support multi-path and multi-source reachability, containing entries of the form: Destination GRC (prefix) Egress Paths (Directions) Path Attributes (Priority/Weight/Next-Hop) GRC-A/14 Path 1: East Path 2: North Primary (Weight: 50) Backup (Weight: 50) GRC-B/17 Path 1: Down Local Ground Station The egress direction is one of: North, South, East, West, Down, or Up. The next-hop field is optional and MAY be used for explicit next-hop specification in complex topologies. To preserve the multi-source characteristics inherited from terrestrial protocols (e.g., BGP multi-homing), a single destination GRC prefix MAY resolve to multiple egress directions. The forwarding engine can execute Equal-Cost Multi-Path (ECMP), Unequal-Cost Multi-Path (UCMP), or Active-Standby switches based on the path attributes.

Routing Table Refresh At each time slice boundary: The time-varying routing module retrieves the pre-computed routing table for the new time slice from the routing database. The module updates the forwarding information base (FIB) with the new routing table. The old routing table is retained briefly (e.g., for one additional time slice) to handle packets in flight that were forwarded based on the previous table. The local GRC bindings are updated to reflect the satellite's new position. This periodic refresh replaces the event-driven link-state updates of traditional routing protocols, providing deterministic and bounded routing updates.

Packet Forwarding

Encapsulation and Tunneling User traffic enters the satellite network at the UT and exits at a GS. The end-to-end flow is:

WR->UT->[Satellite Network]->GS->PoP->Internet ]]>

Step 1: The DEV sends an IPv4/IPv6 packet destined for a remote content server. The packet traverses the user's local network to the UT. Step 2: The UT queries the Routing Database with the destination terrestrial IP. To preserve multi-source characteristics, the database MAY return a list of multiple candidate PoPs and their corresponding GS GRCs. The UT applies a multi-source selection policy (e.g., spatial proximity, load balancing, or primary/backup policy) to select one or more target GS GRCs, and encapsulates the user traffic into a tunnel. Step 3: The encapsulated packet traverses the inter-satellite network. At each satellite hop, the forwarding engine extracts the destination GRC from the outer header, performs a segmented longest match lookup in the current time-slice routing table, and forwards the packet in the appropriate direction (North, South, East, West, Down or Up). Step 4: The GS receives the encapsulated packet, terminates the tunnel, and forwards the inner packet to the PoP using standard IP routing. Step 5: The PoP performs NAT (if required) and injects the packet into the terrestrial Internet. Step 6: Return traffic follows the reverse path through the same GS, satellite network, and UT.

Forwarding Algorithm The forwarding algorithm at each satellite is:

Handling Local Traffic If the destination GRC matches one of the GRCs currently bound to the local satellite, the packet is delivered to upper layer protocol.

System Components

Geographic Coding Module The geographic coding module is responsible for: Converting satellite coordinates (latitude, longitude, altitude) into the corresponding GRC. Determining the set of GRCs covered by the satellite's footprint at the current position. Updating interface address bindings when the satellite enters new geographic regions. The module MUST support real-time coordinate updates at a rate sufficient to track satellite motion (e.g., at least 1 Hz).

Time-Varying Routing Module The time-varying routing module is responsible for: Loading the pre-computed routing table for the current time slice from the routing database. Managing the transition between time slices, including FIB updates and table retention policies. Synchronizing with the satellite's onboard clock to ensure accurate time slice alignment. The module SHOULD support graceful transitions that do not disrupt packets in flight.

Data Forwarding Module The data forwarding module is responsible for: Receiving packets from ingress interfaces. Extracting destination GRCs and performing routing table lookups. Forwarding packets to the appropriate egress interfaces. Maintaining packet ordering within flows. The module MUST support the segmented longest match algorithm and SHOULD leverage existing hardware forwarding engines (e.g., TCAMs) where available.

Routing Database The routing database stores: Pre-computed routing tables for all time slices in the satellite's orbital period. Ephemeris data for all satellites in the constellation. Mapping between GRCs and geographic coordinates. Terrestrial-to-GRC Multi-Source Mapping Table: Maps a standard terrestrial IP prefix (IPv4/IPv6) to a set of candidate GRCs representing multiple terrestrial injection/egress points (PoPs/GSs). The database is populated prior to satellite launch and MAY be updated via ground control uploads when constellation parameters change.

Integration with Terrestrial Networks

Border Gateway Function The GS and PoP serve as the border between the satellite segment (GRC-based routing) and the terrestrial segment (IP prefix-based routing). The border gateway performs the following functions: Ingress (Satellite to Terrestrial): Terminates satellite tunnel encapsulation. Extracts the inner IP packet. Performs standard IP routing lookup using the destination IP address. Applies NAT if the satellite segment uses private addressing. Egress (Terrestrial to Satellite): Receives IP packets destined for satellite network users. Determines the target UT GRC. If the user network is multi-homed (connected via multiple UTs for multi-source reliability), the gateway selects the optimal UT GRC list based on BGP metrics or geographic policies. Selects the ingress GS and encapsulates the packet into a satellite tunnel with GRC-based outer addressing.

DNS and Address Resolution The DNS resolution process is unchanged from standard IP networks: The DEV queries a DNS resolver for the content server's domain name. The resolver returns the server's IP address. The DEV sends packets to this IP address. The UT intercepts the packet and initiates the satellite routing process based on the destination's geographic region. The GRC-based addressing is transparent to end hosts and applications.

Security Considerations

Spoofing and Injection Because GRCs are derived from geographic coordinates rather than administratively assigned prefixes, an attacker could potentially inject false routing information if they gain control of a satellite or GS. Mitigations include: Cryptographic authentication: Routing table updates and ephemeris data SHOULD be cryptographically signed by the constellation operator. Access control: Only authorized ground control stations SHOULD be able to modify routing databases. Anomaly detection: Satellites SHOULD monitor for anomalous routing behavior (e.g., sudden changes in forwarding patterns) and report to ground control.

Routing Database Integrity The pre-computed routing tables are critical to correct network operation. Compromise of the routing database could cause widespread black holes or loops. Protections include: Secure storage: Routing databases SHOULD be stored in tamper-resistant hardware on satellites. Integrity verification: Checksums or digital signatures SHOULD be used to verify routing table integrity at load time.

Privacy Considerations GRC-based routing encodes geographic information in packet headers. While this does not expose precise user locations (GRCs represent regions, not individual devices), traffic analysis could infer user coarse location. Operators SHOULD consider: Encryption: IPsec or TLS SHOULD be used to protect user traffic content, though GRC headers remain visible for routing. Logging minimization: Forwarding devices SHOULD minimize logging of GRC-based forwarding decisions to reduce metadata exposure.

IANA Considerations This document has no IANA actions.

This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments The authors would like to thank the IETF Routing Area working group for their valuable feedback on this work.