Large Scale LEO Satellite Networks for the Future Internet: Challenges and Solutions to Addressing and Routing

This document analyses the problems and challenges of addressing and routing to Low Earth Orbit (LEO) satellites used for the future Internet. It focuses on the scenario where Inter-Satellite-Links (ISL) are used for massive LEO satellite constellation. Such LEO satellite network is the key to the Non-terrestrial Network (NTN) integration with 5G and beyond. The paper describes two categories of solutions. One is based on IPv6 and another is based on a new protocol, New IP. The two categories of solutions are a) using new types of addresses for LEO satellites and b) new concepts for routing with these addresses. The semantic addressing scheme leverages the characteristics of satellites with known orbit elements; and simplifies the satellite identification by using limited indexes. The routing method combines semantic addressing with source routing and generates a new semantic routing scheme. Compared with traditional methods, the new proposals dramatically reduce the workload in satellite, such as table size, Ternary Content-addressable memory (TCAM) lookups, and packet header size. Thus it is more suitable to networks in space where the harsh environment limits the hardware performance, power consumption, link bandwidth and system complexity.


Introduction
Low Earth Orbit (LEO) satellites are being used for Internet access.They fly at an altitude from 250km to 2000km [1].To cover the Earth, the size of a LEO constellation is much larger than for Geostationary satellites (GSO) [2] or Medium Earth Orbit (MEO) [3].It is estimated that 50,000 active LEO satellites will orbit overhead within ten years.Only three geostationary satellites, each separated by 120 degrees of longitude, are sufficient to provide coverage of almost the entire planet.Unlike GSO, LEO satellites move very fast from a ground reference point.
Commercial deployments exist already.Starlink [4] is offering such a service now.They have launched over 1,600 satellites and intends to eventually have over 40,000 satellites.China has requested orbit and spectrum resource from ITU for 12,000 satellites [5,6].3GPP (3rd Generation Partner-ship Project) plans to integrate LEO satellites with 5G in its proposed Non-terrestrial-network (NTN) Integration [7] for the future Internet.
The current networking technologies are not sufficient to support such network moving at very high speed.LEO satellites therefore raise many new technological challenges, including long distance radio communications, free space optical communications, accurate laser tracking technologies, networking, and mobility protocols for fast moving networks, etc.
In this paper, the LEO satellite network dynamics, challenges and impacts to the network routing are analysed based on theoretical formulas for the satellite movement, speed, and coverage.
The purpose of this work is to seek a set of methods that can be used for large scale LEO satellite network and integrated with the existing Internet and other types of satellites (GEO or MEO).The technologies should be potentially adopted by industry and accepted by standardization organization, IETF and 3GPP.The solutions should maximize the usage of current technologies since their quality, performance and scalability have been proven in Internet for many years.Based on these criteria, we focused on the current routing protocols used in Internet.We investigated their problems when used for satellite network.We studied to fix the problems without introducing completely new technologies.We propose new methods for satellite addressing and routing specially optimized for LEO satellite networks.The new proposals can be realized by IPv6 [8] or New IP (See Section 5).It includes the following major items.The item (1) and ( 2) are for the packet forwarding; The item (3) and ( 4) are about how the routing decision is made.
(1) A semantic addressing scheme that takes into account the orbit parameters of the satellites; (2) A source-routing mechanism to forward efficiently with small table look-ups; (3) A modified version of OSPF [9] that detects and distributes real-time network topology and state; (4) The pre-computed or real-time computed satellite positions and link metrics to obtain the shortest IP routing path information.
The paper is organized as follows.Section 2 describes an overview of LEO satellites, satellite services and some previous research literature; Section 3 talks about how the LEO satellites are used for future Internet and the corresponding challenges to existing IP routing technologies; Section 4 is the proposed solution based on IPv6, the new semantic ad-dress system is in Section 4.2; and the new routing scheme is in Section 4.3.Section 5 is the proposed solution based on New IP.Section 6 reviews the congestion control solution in Internet and describes our solutions.Our proposal is evaluated in Section 7; Section 8 concludes with some future research directions.
The illustrated satellite orbit images and the simulation test results are based on the open-source software SaVi [10].

Basics for LEO Satellite and Traditional Services
A LEO satellite constellation consists of certain number of orbits.SpaceX for instance is using an orbit at 550kms of altitude, and OneWeb flies its satellites 1,200kms from the Earth.Each orbit has its own altitude and inclination and hold the same number of satellites.The orbit parameters are described by [11].For a group of orbits that have the same altitude and inclination angle, the Longitude of the ascending node (Ω) can be derived from the total number of orbits since all orbits are evenly distributed in the range of 360°.All satellites in the same orbit will also evenly distributed in the 360°range.
A satellite is said to occupy an inclined orbit around Earth if the orbit exhibits an angle other than 0°to the equatorial plane.This angle is called the orbit's inclination.The typical LEO satellite orbit will have an inclination angle less than 90°.This type of orbit configuration leads to a satellite network topology that is an interleaved mesh network as shown in Figure 1.Half of the satellites are moving in a different direction from the other half.In Figure 1, the green satellites move in a different direction from the blue satellites.All satellites may communicate with terrestrial devices by uplink and downlink, or with other satellites by Inter-Satellite Link (ISL) to form a network in the sky and forward packets directly.
Satellites have provided voice or data services for a long time by GEO/MEO/LEO.The data rate for the voice or data service normally is roughly 10 kbps.With such low data rate, most Internet applications cannot run.It is therefore expected that other services would primarily use satellite networks, at least initially.
The basic formulas for satellite movement, coverage and other key parameters are analysed and estimated in Appendix A and B. For instance, a Starlink LEO satellite at 550 kms above ground has a ground footprint of about 941 kms radius.That is the maximal distance between two points on the ground connected to the same satellite.This shows that inter-satellite links are required to provide global connectivity.

Previous Research Works
IP routing issues in LEO satellite networks were identified early in [12] or [13].As more and more LEO constellations are being deployed, LEO satellite networking in space has received more attention for research.Survey or overview of related research works can be found in [14,15,16].[17] analysed the approach for shorter latency for LEO constellation.Detailed analysis and simulations for Starlink have been done in [18].Using ground relays for Starlink to expand the coverage was also proposed by [18].[19] overviews the key aspects of LEO satellite networking.[20] looks at location management for satellite networks and offers a comprehensive survey of this topic.[21,22] consider enhancing BGP [23] for space.[24] studied the interaction with TCP [25], especially as it pertains to the RTT of a flow routed over a LEO constellation.[26] proposed a routing method that is faster than the Dijkstra's algorithm [27] but can only apply to Walker Delta Constellation [28].The optimization of location-assisted on-demand routing (LAOR) is studied in [29], In LAOR, each node uses a learning process from its neighbors for the path of a destination and not as fast as the flooding based method used in IGP [30] in Internet.
[31] studied four solutions for routing in LEO constellations, from using BGP to a clean-slate design.They find that a path-aware networking architecture where end-hosts control the paths is optimal.[32,33] considered a layered routing mechanism between LEO and MEO constellations.
These works differ from this paper on following aspects: 1) we consider both IPv6 and New IP as network protocols; 2) we introduce new addressing system and new semantic source routing protocol; 3) the new method is independent of the types of LEO constellation and the algorithm to obtain the path; 4) the new method can dramatically reduce the message, computation and complexity on satellite for the routing.

Internet Service by LEO Satellites
Recently, some companies like StarLink, OneWeb [34], TeleSat [35] have used LEO constellations to provide Internet access service.The major difference between the new service and the traditional voice/data service is that the uplink and downlink rate are much higher and up to hundreds of Mbps thanks to the use of much lower orbit and phased array antenna [36].In these satellite networks, each satellite works independently without communicating through ISLs.This is so called "Bent Pipe" in the traditional satellite network.The "bent pipe" describes a communication where whatever is transmitted to a satellite needs to come down straight away.This mode has many limits and will be analysed in the next section 3.2.

LEO Satellite Network with ISL
In 3GPP, there are two scenarios for LEO satellite networks integrated within the future Internet.These are shown in Figure 2. In one scenario, the LEO satellite network is used as Radio Access Network (RAN).In the other, the LEO satellite network is used as a 5G Back Haul Network.The first use case is much more complicated than the second since many wireless access requirements need to be satisfied.Please refer to TR.38.821 [7] for the details of the first scenario.3GPP is still working on the second scenario (TR.23.700 [37]) and will make it available in the next 3GPP release Rel 18.For both cases, global coverage and shorter latency (compared to terrestrial network) are expected.LEO satellite communications are faster, due to the fact that the speed of light is faster in space than in fiber (light travels about 31% slower through fiber optical cables than it does through space); and due to a more direct routes the satellites are low enough that it does not add much delay to reach their orbit (about 500km), whereas fiber cables are hardly ever laid straight between source and destination and rather follow detours due to mountains, country boundaries, population density, oceanic cables, etc.
In the architecture described in TR.38.821 [7], the first mode (without ISL) is the "Transparent Payload", and the second mode (with ISL) is called the "Regenerative Payload".
The "Transparent Payload" mode is similar to the "Bent Pipe".Satellites receive signals from the user terminal on the ground, amplify the signal, convert the frequency and channel, then re-transmit the signal back to another ground station.The "Regenerative Payload" mode processes the data packets after the physical signaling process.At the upper layer, L2 or L3 networking functions are needed.
The "Transparent Payload" mode has the following limitations: (1) Two ground-stations that need to communicate must be within the coverage of the same satellite; (2) To provide global coverage, many gateway ground stations (connected to Internet) must be deployed in areas hard to reach by humans, such as oceans, polar areas, etc.
Inter-Satellite-Links (ISLs) are the best solution to these problems.It is more economical than using ground stations to relay the radio signal that was proposed and studied in [18], since deploying many ground stations in the middle of oceans and remote areas is not cost effective.By using ISLs, all LEO satellites are connected to each other and form a network in the sky.User traffic received on one satellite from its ground station (GS) can traverse the satellite network to any other satellite and reach any place on Earth.Starlink has tested ISL communication in 2022 and is expected to provide such service for polar areas soon.With a LEO satellite network with ISL, one user terminal at any place, and at any altitude (as long as it is lower than the satellites) on Earth can connect to the Internet or 5G network via the LEO satellite network.The Figure in Appendix H shows a path from a Terminal ground station (T-GS) to a Gateway ground station (GW-GS) connected to the Internet via ISLs.

IP and Routing Protocols for LEO Satellite Network with ISL
When LEO satellites communicate directly, the question becomes: how to guide the user traffic from a ground station over the LEO networks to the Internet; and how to handle the return traffic on its way back.
A typical LEO satellite network consists of thousands of network nodes (satellite), and potentially millions of ground devices and network links (ISLs and Satellite-to-ground-stations links).Some proposals even suggest to connect devices directly to satellites.For networks of such large scale, L3 (or IP) routing has proven to be the best solution.
For 3GPP's "Regenerative Payload" mode (used in the scenario where satellites networks provide 5G RAN services), the satellites must provide the functions of eNodeB (4G) [38] or gNB (5G) [39]; the devices on ground provide the packet gateway (PGW, in 4G terminology) and User Plane Functions (UPF, for 5G).IP connectivity within the satellite network is mandatory for the under-layer infrastructure.Both control plane and data plane are over the IP layer.
Private companies like StarLink have used proprietary technologies for the service they currently provide.This cannot satisfy 3GPP's expectations and requirements in terms of inter-working between different networks over the Internet because the StarLink's satellites cannot communicate with the public Internet.For example, for the case where satellite networks provide the back-haul network for 5G, a cloud or content provider connected to the satellite network might want to push the cloud service to satellites.By doing so, they can provide so called "Edge Computing" services to clients with shorter distance between the clients and the servers.This cannot be done if the satellite network is not using the protocols supported by IETF (Internet Engineering Task Force) and 3GPP.
As a summary, IP and routing protocols are critical for LEO satellite network with ISL, as IP has proven to work at the scale of future LEO satellite deployments, and as these networks will have to be integrated within the Internet.As part of the Internet infrastructure, LEO satellite networks are expected to run IETF-and 3GPPsupported protocols, as regular service provider's network already do.It is the only way to integrate LEO satellite networks with NTN and other networks in the Internet.

Limits of Current IP and Routing Protocols for LEO Satellite Networks
The Internet Protocol (IP) [25] suite contains many technologies, protocols and solutions.IP routing and switching are fundamental for the Internet architecture.The typical routing protocols are Interior gateway protocol (IGP) [30] and Border Gateway Protocol (BGP) [23] for intra-domain and inter-domain respectively.There are two types of IGP protocols: one is OSPF [9] and another is IS-IS [40].Thereafter, we always use OSPF as an example of IGP.
LEO Satellites move very fast.One satellite will orbit around the Earth between 87 and 127 minutes.The established network is not steady like terrestrial networks.To understand their characteristics, we have to analyse the satellites' motion and its impact on the network in terms of topology, link lifetime, link metrics.
The formulas and parameters listed in Appendices A and B show that every satellite is moving within its orbit with a speed faster than 7 km/s.Every ground station is also moving along with the Earth self-rotation at the speed of 463m/s.This results in a short link life and highly variable link metrics (bandwidth).Due to the cost and complexity of ISL device and tracking technology, LEO satellite normally only deploys a limited number of ISLs.The links have different properties, that are categorized in Figure 3. Figure 3 describes five satellite link types (L1 through L5) and their properties.The link life and metrics characters are listed in Figure 4.If a LEO satellite only needs to connect to satellites at the same altitude, then five ISLs are enough (2xL1, 2xL2, 1xL4 links).L1 links are steady, but L2 links, connecting satellites on adjacent orbits, are not steady, their link metrics keep changing since the distance is changing.They will swap (right side becomes as left side on the above view point) at polar area.Figure 5 demonstrates this situation.L4 link connects to satellites at the same altitude which move in different direction.It normally has shorter lifetime than L2 links.Current routing protocols are based on IPv6 (IETF has announced that IPv4 was being gradually deprecated).To provide basic connectivity within a network is fundamental to all other protocols.Traditionally, IGP is designed to do this job.The current IGP is a distributed protocol.Each network node runs it.Consider OSPF as an example: LSA (Link State Advertisement) are populated by each node within the network, this is called LSA flooding.Any network change in any node/link state or link metrics will trigger one or multiple types of LSA to be flooded to the whole network.
Each satellite has to process the received LSA for its adjacency list, link state, network graph and store this information locally.Then, using itself as root, it computes the SPF (Shortest Path First) tree and generates a routing table.Thereafter, at each network node, received user packets can be forwarded by a route table lookup.The lookup will find the Longest Match Entry in the table and is often implemented through a TCAM lookup.The routing table is generated from LSDB (link state database) by LSA processing at all network nodes.The LSDB must be synchronized within the OSPF network and be identical.This guarantees the packet forwarding via each node's TCAM lookup will be loop-free.
In a LEO satellite network, the links of the network are very dynamic.If we apply the current routing protocol IGP as is, a huge number of flooding events caused by frequent link flipping and link metrics change will lead to each satellite's LSDB being in a synchronized state for only a very short time window.Thus the network is unusable for most of time.[41] has analysed that the network usability will be dramatically reduced to less than 20%.[41] made proposals to fix this issue, but they only work for F-Rosette satellites [42] now and need further work to apply to general LEO satellites.[43] has proposed to modify OSPF to solve the problem that ISL for satellites on the adjacent orbit is interrupted at the poles due to swapping, but it needs every satellite to calculate the SPF tree in the interval of seconds.
Additionally, the hardware performance and energy consumption in satellites are constrained and are not as cheap as in terrestrial network.They cannot be replaced, so the hardware has to be hardened.Therefore, a new mechanism that can dramatically reduce the workload in the satellite is required.

Overview of Solution
From the analysis in Section 3.4, we can see that the major problem with using the current routing protocol IGP for LEO satellite network is that the IGP's distributed mechanism is not suitable for LEO satellite networks.We should not completely rely on the distributed mechanism used for populating the LSA population, processing, computing the SPF and forwarding packet.
The basic principles of our proposal are: (1) Maximize the use of predictions and pre-computation for LEO satellite networks.This will be the basics of the detailed design described in Section 4.2 and 4.3.Each satellite's position, the distance between any two satellites, the distance between satellites and ground stations are all computable from the known orbit parameters of a satellite and the geographic coordinates of a ground station.These values can be converted to useful information about node and link state, and link metrics.Firstly, the distance between two satellites can tell whether ISL between satellites are possible to come up since ISL has limitation communication distance.The same rule applies to the radio links between satellite and ground-station.Secondly, the ISL metrics are mostly proportional to the physical distance.Some empirical formula can be used to get the ISL bandwidth estimation from physical distance.By using prediction and pre-computation for the LEO satellite network, the problems caused by traditional LSA update for IGP due to link flipping can be dramatically mitigated.(2) Use a single point for route calculations, and source routing for packet forwarding.Our new solution does not rely on hop-by-hop packet forwarding based on a distributed routing table.The single-point routing calculation can be done at any network node on demand when the node needs to send traffic to a remote node, either ground station or satellite.The source routing mechanism means the calculated routing information for the whole routing path will be carried into user packet.At each network node, the routing information can be used for the forwarding.Section 4.3 talks about this in more details.(3) Use a special addressing system for LEO satellite constellation.This system can represent the relative positions of the LEO satellites.This can be used to reference the satellite identification, its OSPF adjacency and the forwarding directions.The new address can reduce the packet header size for the source routing and speed up the adjacency lookup in the forwarding process.This is described in Section 4.2.

Semantic Addressing for LEO Satellites
Massive LEO satellite constellations have a useful property: all satellites within the same orbit move in concert.The relative positions of satellites within a given orbit remain constant.After ISLs are established, the satellite network remains the same (while moving fast with respect to the ground).In the network, each satellite behaves like a network node, all satellites are connected with its designated neighbor satellites via ISLs.
One satellite network may consist of many satellites with different orbit parameters, such that all satellites orbits carefully cover the entire Earth.Recall we approximate all satellites orbits by circles in Appendix A, so the key orbit parameters are the Altitude and the Inclination angle.Normally a massive LEO satellite constellation only has very few sets of (Altitude, Inclination angle) parameters.Therefore, the LEO constellation can be grouped as follows, and different index can be assigned to all satellites: (1) One LEO satellite constellation is composed of couple of shell groups of satellites, see Figure 6.All satellites in a shell group are assigned a Shell_Index.Satellites with a given Shell_Index have the same (Altitude, Inclination angle) parameters.The Shell_Index can be assigned by increasing (or decreasing) altitude.
(2) Each shell group will have a number (NO) of orbit planes evenly distributed by the same interval of Longitude of the ascending node (Ω).The interval is equal to (360°/NO).All satellites within the same orbit are assigned an Orbit_Index as shown in Figure 7.The Orbit_Index can be assigned by increasing (or decreasing) Longitude of the ascending node (Ω).It must be noted that in the real LEO satellite constellation, the orbit parameters for each satellite may not be exact the same as the theoretical values described above.The parameters may also shift after staying in space for times.But that does not impact the semantic address assignment as long as the relative position of a satellite is not changing.
As described above, using three indexes can uniquely identify a satellite in a LEO constellation.Since there will be more than one LEO constellations in space, it is necessary to distinguish different LEO constellations that belongs to different country, region, or company.So, we can introduce an Owner Code to indicate the owner of the constellation.
According to the analysis in Appendix A, the maximum number of orbit plane and the maximum number of satellites per orbit plane both are below 255.So, one octet is enough to store each index.Finally, the satellite identifier or the native semantic address can be defined as per Appendix C.
When IPv6 [8] is used for LEO satellites, the native semantic address can be embedded into the "Interface Identifier" (i.e., the rightmost 64 bits) part of IPv6 address.The detailed packet format is shown in Appendix D.
For L2 switching, the semantic address can be embedded into MAC address at the field of "Network Interface Con-troller (NIC) Specific".Due to the shorter length of the NIC field, the "Shell_Index" and Intf_Index can only have 4-bit.This is illustrated in Appendix E.

Semantic-address based Routing for LEO Satellite Network
This section describes our new mechanism for IP routing based on the semantic address described in Section 4.2.The mechanism is essentially a source routing method.It is conceptually similar to IPv6 Segment Routing (SRv6) with loose-hop [44,45,46] but with many differences in the architecture and details.
For the new mechanism, the path info is converted to a series of semantic instructions.The instructions are embedded into the IPv6 packet header.At each satellite, the instruction is fetched from the packet and the routing is done based on the instructions.We represent a satellite by its indexes: Sat(Shell_Index, Orbit_Index, Sat_Index).

Path Determination
For source routing, the path must be determined at the source of the traffic.Here, the source can be a ground-station or any satellite depending on the application.We use Source Ground Station (src-GS) as source in our experiment.To minimize latency (especially compared with terrestrial networks), the packets should follow the shortest path in terms of physical distance from the src-GS to the Destination Ground Station (dst-GS).For this purpose, we leverage Dijkstra's algorithm [27] that has been implemented by OSPF [9] and running in the Internet for long time.
As described in Section 3.4, we cannot apply OSPF to satellite networks in the traditional way, but we can still use it after modifications.The steps below use the example that a src-GS needs to send data to another dst-GS.The modification illustrated is only the key part and is not for implementation purpose: (1) Generation of an ephemeris table by pre-computation and analysis from satellite orbit parameters, GS geocoordinates [47], predicated weather, space conditions, etc.This table stores the time window for each link's state and the link's end-points.Most importantly, the table will store the info about the satellite-GS links, and ISL links state above polar area (for the swapping window, see 3.4).Given a time and a node (satellite or ground station), we can find out from the table which could be its link peer and what is the link state.Considering the MIMO [48] from 5G NR [49], one satellite may connect to multiple GS and one GS may connect to multiple satellites.Proper policy will be used to determine which link is "most likely" up or down.This table will be synchronized and stored (partially) in every satellite and GS, presumably all satellites and GS have its local clock synchronized.Each node (satellite or GS) will store which could be its link peer at which time window.Then the node can use the table to guide its antenna direction and link setup dynamically.(2) Each satellite and ground station runs a modified version of OSPF that only does the node and link state detection, but no SPF calculation unless the node wants to send traffic.(3) Each OSPF instance on each satellite will populate the Router LSA that advertises the satellite, its neighbor satellites and associated ISL links.The attached network to the satellite can be populated by Network LSA and Intra-Area-Prefix-LSA.Appendix K demonstrates the detailed OSPF message type and size for an exam-pled configuration.(4) The src-GS will periodically compute all satellites' position and all ISL link metrics.This can also be done offline by another more powerful computer and does not need to be real-time.The pre-computed results are stored at src-GS.The periodicity to compute this is dependent on the network scale, network state and shortest path requirement.Normally tens of seconds to one minute are good enough, see the number of distinct path in the experiment described in Section 7.2.( 5) src-GS is configured as an OSPF monitor node [50].This prevents too frequent link up/down events caused by the state changes of satellite-to-ground-station links.The src-GS will process the real-time OSPF messages from the satellite network to obtain all node and link states.Thereafter, the real-time network graph can be generated and path can be calculated by OSPF.
The workflow and function modules to obtain the path information and instructions for packet forwarding are illustrated in Figure 9.The modules only need to be implemented on the nodes that will send traffic via the satellite network.

Semantic Instructions Derived from the Path Information
The path information obtained by any routing algorithm is essentially a list of IP hops (or IP routing nodes) from source to destination.It can be converted into a list of segments.
A segment is defined as a list of satellites and four type segments are defined: (1) Segment with adjacent Shell_Index: For any direct adjacent satellites on the segment, their Shell_Index are also adjacent.Figure 6 shows an example.(2) Segment with adjacent Orbit_Index: For any direct adjacent satellites on the segment, their Orbit_Index are also adjacent, the Shell_Index are the same.The left on Figure 7 shows an example.(3) Segment with adjacent Sat_Index: For any direct adjacent satellites on the segment, their Sat_Index are also adjacent, the Orbit_Index and Shell_Index are identical.The right on Figure 8 shows a example.(4) Segment with non-adjacent index: this segment only has two satellites and the two satellites do not belong to any of the above three categories.
Each segment maps to an instruction that guides the packet forwarding at each satellite from the start to the end of the segment.For segment types (1) to (3), there are two directions to forward packet, each direction can be defined as either an increment or a decrement of a specified index.For type (4), there is one direction to forward packet.So, we have eight directions to forward packets: to the satellite ahead or behind; to either sides; above or below; to another non-adjacent satellite; or to ground-station.Figure 3 can also illustrate the forwarding directions since each link is associated with one direction to forward the packet.
Figure 10 shows a path from a Terminal ground station (T-GS) to a Gateway ground station (GW-GS) connected to the Internet via ISLs.

Semantic Instruction Design
To guide the packet from source to destination, a set of instructions must be executed sequentially.We define this as the "instruction list."Each instruction is designed as a "Function Name/Code" and Argument(s).The instruction carries semantics to tell a satellite the direction where to forward the packet, and where to stop the forwarding.The way to stop the forwarding on a segment is to check whether the argument in the instruction is equal to the specified index of the satellite address.
An Instruction can also tell a satellite to perform other operations beyond forwarding to a satellite such as punt to CPU, forward to GS, lookup address for forwarding, etc. Due to the limited number of forwarding directions, the Function name/code part is one octet.The size of the Argument depends on the Function.For the segment type (1) to (3), we only need one octet Argument to indicate one of three satellite address indexes, and this significantly reduces the instruction overhead.For the segment type (4), we may need Arguments of longer size.The defined Function Name and associated Arguments are shown in Appendix F. The detailed semantics for each function is illustrated in Appendix G.
An example to derive the routing instructions from the path information is described in Appendix H.
The instruction list must be encoded into a user's IPv6 packet.The standard IPv6 packet has already defined abundant extension headers to use for different features.For routing purpose, there is routing-type extension.The instructions can be encoded as a new sub-type (instructive routing) of the routing extension header.The detailed encoding and the packet format are illustrated in Appendix I.

Solution Based on New IP
The solution based on IPv6 described in Section 4 obviously has the following deficiency: (1) The IPv6 address is not a good fit for the solution, since the prefix part of the 128-bit IPv6 address is redundant and never used.The satellite semantic address only has a 32-bit length.It is essential and enough for the network node identification and routing.IPv4 has a 32-bit length, but does not define an option field in IPv4 header like the Extension Header in IPv6 to hold the semantic routing instruction information.Therefore, IPv4 is ruled out.(2) The IPv6 OSPF protocol use the IPv6 address for exchanging its protocol message.This is overhead and wastes link bandwidth.For example, the source and destination address in LSA message are both IPv6, the link local address is also IPv6.By using semantic address, we can use shorter addresses to identify each satellite, its interface and the multicast address used for flooding destinations.It is easy to use some bits in the semantic address to define a multicast address like the IPv6 or IPv4 multicast addresses.
To overcome the above problems, we can use New IP instead of the current Internet Protocol IPv6.
As its name suggests, New IP is a new Internet Protocol for future Internet that tries to solve visionary problems and satisfy the requirements for 5G and beyond.It was first proposed in ITU TSAG C-83 [51], and some research papers have been published [52] and [53].Compared with the existing IPv4 and IPv6, New IP is a superset and has many forward-looking mechanisms for future Internet.It supports new features such as (1) Free Choice of Addressing; (2) Guaranteed service and network programmability through "Contract"; (3) Qualitative communication by manipulation of the packet's Payload.
The proposed New IP header structure and supported functions are illustrated in Figure 11.When using New IP for LEO satellite networking, the major difference with IPv6 is the packet header type for both control plane and data plane will be New IP instead of IPv6.For example, for all control messages, we can use 32-bit length address (for Satellite Semantic Address) that will be shorter than IPv6 128-bit header size; For data plane, user packet can be either IPv4 or IPv6 or any other type of address that is supported by New IP.
Even the detailed flexible address format supported by New IP is not finalized yet.It is up to the Standard Organizations to define.We still can analyse the high level framework and benefit of using New IP over IPv6. Figure 12 shows the comparison in terms of control plane and data plane for two solutions.

Review of Current Technologies for Congestion Control in Internet
Congestion control for Internet is a broad topic and has been studied for many years.Due to the complexity, there are many research papers for this topic.Most of them just stayed at academia stage and have never been adopted by industry.The current strategy and technologies of handling network congestion or related issues in Internet are as follows: (1) Achieve the end-to-end congestion control by using Layer 4 (L4) protocols: TCP, or UDP with congestion control mechanism added.TCP naturally provides basic congestion avoidance in its algorithm, there are many variations for TCP [54]: tahoe, reno, cubic, etc. UDP itself does not have congestion control, and extra mechanism has to be added to upper layer in two end-hosts for the UDP session, [55] has given a detailed guidance for different methods.Recently, new congestion avoidance algorithms like BBR [56], L4S [57], QUIC [58] (based on UDP) are gradually coming up and deployed.in those new algorithms, only L4S needs to change network device.BBR and QUIC still treat network as a black box.After detecting the congestion by different methods and parameters at one end-host, the algorithm will adjust the traffic at source to achieve the congestion control.All congestion control mechanism based on Layer 4 has assumed that the under-layer network is a black box and the congestion control algorithm is independent to the under-layer network, and off course it is also independent to the routing if under-layer network is IP.(2) Using Traffic Engineering (TE) technologies.TE is to address the problem of efficiently allocating resource in the network so that user constraints are met and operator benefit is maximized [59].Normally Service Provider use TE technologies to deliver better QoS (Quality of Service) for aggregated flows that are carried by the network.Better QoS always means less congestion.Unlike L4 solutions that the algorithms are implemented at the end-host software (except L4S [57] and Active Queue Management [60]), TE solutions try to manage the Internet traffic by enforcing control at network device directly.There are lots of technologies for TE, such as CAC (Connection Admission Control), DiffServ (Differentiated services) [61], IntServ (Integrated services) [62], These methods use resource reservation, traffic classification, marking, queuing and scheduling mechanisms to process prioritized IP flows, steering different traffic for different path by policy, or manage the resource sharing for different flows.The typical protocols for TE are RSVP [63], RSVP-TE [64], MPLS [65] and Segment Routing (SRv6) [46].Recently, SDN (Software-Defined-Networking) [66] has been studied and deployed in some scenarios such as SD-WAN (Software-Defined Wide Area Network) [67], 5G Back haul network, etc.These technologies do not use the traditional distributed protocols, they use a centralized controller to control and manage a network to realize many TE functionalities.(3) Using Deterministic Networking (detnet) [68] technologies.Detnet is a IETF on-going working group that uses the Time-Sensitive Networking (TSN) [69] to deliver the time-sensitive transmission of IP data over deterministic Ethernet networks.TSN uses resource reservation, different scheduling and shaping for Ethernet to obtain the bounded latency for Ethernet data.Since the bandwidth and latency are guaranteed for TSN flows, the congestion can be eliminated for those specified flows in a well managed Ethernet network.
As summary, all existing congestion control related technologies and solutions described above are agnostic to L3 routing protocols.To use TE and Detnet technologies, regular routing protocols (IGP and BGP) must be deployed first to provide the basic IP connectivity.This is mandatory for 1) TE and Detnet protocols' signaling message and 2) other non-TE and non-TSN traffic (Best effort).For all scenarios, the routing protocols in Internet is to provide the best-effort IP connectivity service, they do not have to consider the network congestion and its impact to routing decision.This strategy decouples the issues of routing and congestion.It greatly reduced the complexity of the network design and provisioning, thus increased the network scalability and has been proven to be succeed for Internet for many years.
It also must be noted even through there are many technologies deployed in Internet to handle network congestion, we generally cannot make Internet congestion-free like the traditional circuit switch network [70] or ATM network [71].This is nature to a statistic multiplexing network that is the fundamental of IP.Even with the use of TE and Detnet, we can only obtain certain degree of QoS for specified flows at some limited network.It is not feasible to apply those technologies to the scale of Internet to completely remove congestion for all IP flows.The end-to-end QoS support for all IP applications for whole Internet is neither economical nor necessary.Many applications work very well with the Best-Effort service provided by Internet.

Congestion Control for LEO Satellite Network
IP based LEO satellite network will be like a regular terrestrial IP network and congestion is inevitable.The proposed routing method is to provide the best-effort IP connectivity for LEO satellite network.We will follow the current principals, technologies and traditions to handle congestion for LEO satellite network.The proposed routing solution does not have to consider the dynamic congestion impact.This is similar to all IGP used for terrestrial network.However, we have to be aware that current technologies described in Section 6.1 to handle congestion may need to be changed when used for the LEO satellite network.For example, the LEO satellite network has some special characteristics, such as high delay variation, frequent hand-over, packet loss caused by weather, solar flare, mobility or ISL tracking.Some works have been done in IETF.RFC 2488 [72] enhanced TCP over satellite channel.[73] describes an on-going work for transport over satellite.Further research is needed to investigate whether each existing protocol described in Section 6.1 needs any modification, or enhancement, or new technology is needed for large scale LEO satellite network.

Simulation and Evaluation
This section presents the simulation results.We also compare our proposed method with traditional routing protocols in terms of protocol message processing workload on satellite; memory requirement; packet size overhead.
The simulation is to experiment from the following perspectives to validate the proposed solutions: (1) End-to-End delay (Section 7.1): Whether the path provided by the algorithm for a LEO satellite network is better than the current Internet based on terrestrial network in terms of packet delay.(2) Performance and scalability (Section 7.2): Whether the proposed routing method is realistic in terms of time spent in path determination for different network scales; and in terms of the number of distinct paths in a given period of time.(3) Packet Overhead (Section 7.3): Whether the proposed new data plane has smaller packet overhead than the traditional methods SRv6 and SRv6-C (SRv6 with Com-pressed SID) [74,75].
Since the detailed OSPF modifications for IPv6 and New IP are implementation dependent and can only be finalized by IETF, the simulation does not cover the details of the control message size and the gains for the two solutions since those data can be easily obtained by analysis after the protocol changes are finalized and standardized.
The results of the following simulations apply to both solutions.The only difference between both solutions is the packet header definition.In the simulation of delay (Section 7.1), we only assume the packet size is 1500 bytes and does not distinguish the user data part and packet header.In the simulation for the packet overhead (Section 7.3), we only count the extra bytes introduced by the semantic instruction list that is identical for both solutions.
To simulate the moving satellite network and measure the dynamic impact on the path and packet delay, there are many variables: the number of satellites and orbit planes; the orbit parameters; the number of links allowed for each GS to connect to satellites; the type of allowed ISL (links between adjacent or non-adjacent satellites).
For our simulations, we use the following setup: One layer of satellites with the altitude 550 km and the inclination angle 53°(these are Starlink parameters).Except for Section 7.2, there are 30 Orbit Planes, 30 Satellites per Orbit Plane; One radio link between each GS and satellite; Five ISLs for each satellite (four for adjacent satellites and one for non-adjacent satellite).The simulation is running on Intel® Core™ i7-6650U CPU@ 2.20GHz with 16GB of RAM size and Windows 10.

GS-to-GS Delay
The GS-to-GS delay estimation for a satellite network is de-scribed in Appendix J. Figure 13 illustrates the simulated round-trip delays (2 * Delay in Eq. 10) from eight cities to Los Angeles, and compares them with the real ping statistics from [76].We can see that the delay over the satellite network is lower by at least 30%.The longer the distance, the better the improvement.The explanation is the uplink to the satellite and the downlink to the ground add distance to the path when compared with a strictly ground network.However, data travels faster over the satellite links.For longer distance, the faster speed more than compensates the detour to the sky.

Performance
We proposed that satellites run a simplified OSPF protocol as described in Section 4.3.1.The link metrics are estimated from the computation at the source node.This eliminates a huge amount of LSA update messages.With our method, after the adjacency is established, a link state change only leads to very limited Router LSA updates.This only happens when the ISL or Satellite fails -a rare situation (that needs to be avoided at all cost, as repairs are quasi impossible in space).The protocol messaging and processing in the satellite is thus dramatically reduced.
For traditional routing process, the TCAM lookup must be done in routing tables generated by OSPF at every satellite.The routing table size is typically large enough to hold at least the 128-bit IPv6 address or prefix of all satellites in the network.Depending on the configuration, the satellites may also store a huge number of Internet routes in routing tables.
With our method, a satellite only needs to store a table of adjacent satellites and its connected groundstations.As described in Section 4.3.1,there are total eight directions to forward the packet to a neighbor satellite or ground station.For each direction we need to store an adjacent satellite or ground station information.So, the size of adjacency table is very limited.Our method does not need a TCAM lookup to find out the longest matched prefix, as the embedded instruction can tell which direction or which neighbor to forward the packet to.This process is faster than the TCAM lookup.Compared with the traditional method, our method saves memory space (especially the expensive TCAMs), but also performs faster.
Our method is based on source routing.It shifts most of the path computation workload from the satellite to the source node.We measured the time spent by Dijkstra's algorithm for path calculations.The results (see Figure 14) show the calculations take less than 10 millisecond and grow with the number of satellites in a quadratic way but with slow acceleration.More optimizations could be done to reduce the acceleration further.It is reasonable to predict that by more optimization and more powerful CPU, the computation time can be reduced to single digit of millisecond for a commercial network with more than 10,000 satellites.We also counted the total number of different paths within a certain period of time from the source.This number can tell how frequent the path will change for a destination, and it is related to the computation power and storage requirements for a source node.Table 1 shows the number of different paths from source node for 24 hours.It indicates for one destination in one day, there are about thousands of paths to store on source node.This is reasonable to handle at the source node.

Data Plane Packet Overhead
The data plane packet overhead is determined by the size of the instruction list included in the user data packet.The number of instructions is dependent on the number of hops and segments on the path.The total size of the instruction list, as well as the overhead, can be calculated as per Appendix L. Table 2 shows the minimum and maximum number of hops and segments in the simulations.Table 3 calculates the packet overhead and compared with SRv6 and SRv6 with C-SID.Our method has the smallest packet header overhead, thus will save the link bandwidth.

Summary and Future Work
LEO satellite constellations will be a key part of the future Internet.They will be integrated with 5G and beyond to provide truly global Internet coverage with shorter latency.Their use will expand the Internet from the ground into the sky and into space.
We have analysed the problems and challenges of LEO satellite networks posed by the current IP routing technologies.We also proposed solutions that include new semantic addressing and routing methods.These can be used to route data between satellites connected by ISL.This provides the basic IP connectivity to massive LEO constellations.The new solutions can be based on the current IPv6 or New IP.
Our simulations and analysis have demonstrated a very competitive performance in GS-to-GS latency, processing time, the memory space, and scalability.It also shows shorter packet overhead when compared with SRv6 and SRv6 with C-SID.
Further research is needed in the areas of optimized path computation; fast state detection for Satellites, GS and all links; faster satellite position computation.For the broader areas, more works are expected to investigate whether other IP technologies need to be enhanced, or new technologies need to be invented for the integration of the space network, the air network and the ground-sea network.

Appendix A. Coverage, Speed and Other Parameters
To describe the dynamic position of a satellite, we need six orbit elements [11]: Eccentricity ( e ), Semi- major axis (  ), Inclination ( i ), Longitude of ascending node (  ), Argument of periapsis (  ) and True anomaly ( v ).For our analysis purpose, we approximate the satellites' orbit as circles.Then the key orbit elements are its Altitude and Inclination.All other orbit parameters can be derived from these.
The basic math to calculate satellite coverage, moving speed and period are shown in Eq. ( 1) to (7).Fig. 15 illustrates the coverage radius and its relationship with other parameters (altitude, elevation angle) of satellite.To estimate the required minimum number of satellites and orbit planes to cover the entire Earth, we can use Euclidean geometry at equator area (most sparse area).The satellite on the polar orbit (the inclination is 90°) will have projection on a plane as illustrated on Fig. 16.The minimum number of satellites and orbit planes are described in Eq. ( 8) and (9).See Table 4 for the definitions of the parameters.It must be noted the real deployment of LEO satellites is usually denser than the above estimation for the minimum number of satellites and orbit planes.

B. Some Calculated Key Parameters
Table 5 illustrates some computed data for three altitudes with Eq. ( 1) to (9).

E. MAC Semantic Address for Satellite
This encoded MAC address can also be used for L3 solutions where the interface MAC may also need to be configured for each ISL.

J. Delay Estimation
The packet delay for one direction from src-GS to dst-GS can be estimated with Eq. ( 10) to (14).The variables are described in Table 7.The estimation has considered all delays occurred on the path a packet traverses from source to destination.The packet size, ISL link and radio link speeds, packet processing time, etc. are selected conservatively not to reduce the simulated delay.

K. OSPF Message Analysis
We use the following example to analyse the OSPF messages. One layer of LEO satellite network;  Each satellite has four neighbor satellites connected by ISL;  Each satellite is configured as: 1) 32-bit semantic address as the router-ID; 2) one Loop-back interface with a IPv6 address, the address is as described in Appendix D. 3) all ISL interface address are automatically configured with a Link Local address;

Figure 1 .
Figure 1.Half Satellites (green dots) move on the different direction as the another half Satellites (blue dots) (20 Orbit Planes, 20 Satellites per Orbit Plane).

Figure 2 .
Figure 2. Two scenarios of LEO satellite network used for 5G NTN in 3GPP.

Figure 3 .
Figure 3. Link types of satellites on three different altitudes.

Figure 4 .
Figure 4. Link types of satellites on three different altitudes.

Figure 5 .
Figure 5. Adjacent links for satellites on adjacent orbit at four incremental time (t0 to t3).

( 3 )
Each orbit plane in the same shell group will have the same number (NS) of satellites evenly distributed by the same interval of True anomaly () in the orbit plane.The interval is equal to (360°/NS).Each satellite in the same orbit plane is assigned a Sat_Index as shown in Figure8.The Sat_Index can be assigned by increasing (or decreasing) True anomaly ().

Figure 6 .
Figure 6.Shell Index for a LEO constellation consisting of three layers of satellites with different altitudes (3 Shells, 20 Orbit Plane, 20 Satellites per Orbit Plane).

Figure 7 .
Figure 7. Orbit Plane Index and Associated Segment for a LEO constellation (20 orbit planes, 20 satellites per orbit plane).

Figure 8 .
Figure 8. Satellite Index and Associated Segment for a LEO constellation (20 orbit planes, 20 satellites per orbit plane).

Figure 9 .
Figure 9. Workflow and function modules on traffic source node (GS/Satellite) to obtain path info.and instructions.

Figure 10 .
Figure 10.An IP Forwarding Path from T-GS to GW-GS consists of list of Satellites.Each satellite's address is represented by (Shell_Index, Orbit_Index, Sat_Index).

Figure 11 .
Figure 11.New IP Header Structure and Functions.

Figure 12 .
Figure 12.Comparison of IPv6 and New IP Solutions.

Figure 13 .
Figure 13.Real Ping delay using terrestrial network compared with Simulation delay using satellite network.

Figure 15 .
Figure 15.The Coverage of Satellite on Earth.

Figure 16 .
Figure 16.The minimum number of satellites and orbit planes at equator area.

Table 4 . 2 vN
Definition of variables for Eq.(1) to (9) e R Earth Radius (average) = 6,371km h Altitude of satellite  The least elevation angle that a ground station or a terminal can communicate with a satellite  The view angle for the coverage area from Earth center AB The arc length of the coverage radius D The arc length of the coverage diameter M The mass of Earth = 5.97219 × 10 24 kg G The gravitational constant = 6.6743 × 10 −11 m 3 kg −1 s −Speed of the satellite P Period of the satellite T Length of time a GS can communicate with a satellite S min N The min number of satellites per orbit plane at equator area O minThe minimum number of orbit planes at equator area

Figure 19 .
Figure 19.MAC Semantic Address for Satellite.

Figure 20 .
Figure 20.Example of routing

S
delay at all satellites and GS Dist Distance from Src-GS to Dst-GS, this is obtained from simulation l Speed of light in free space, l S =300,000km/s Sat N Number of satellites on the path ISL N Number of ISL links on the path

Table 1 .
Total # of distinct paths for 24h at the source.

Table 2 .
# of hops & segments for 24h at the source.

Native Satellite Semantic Address Figure 17.
Native Satellite Semantic Address.