Routing Consideration for Satellite Constellation Network

For the last couple of years, the satellite-based constellation network has gained significant tractions. There are more and more stakeholders, spanning satellite service providers, mobile operators, telecom equipment & chip vendors, OTT cloud providers, etc., engaging, collaboratively and via various sorts of standardization development organizations (i.e, SDO's), in the exploration and research upon how to offer advanced mobile services over satellite networks. Out of all the mattered SDO's, the 3GPP, via its 5G standardization work, is currently demonstrating the most prominent progresses. The 3GPP Rel-18 has completed two satellite related working items (WIDs), i.e., the Sat-access and the Sat-backhaul . While the Sat-access WID investigates and standardizes how 5G mobile devices (or UEs) could access 5G systems and PLMNs (i.e., Public Land Mobile Networks) via wireless access networks whose transport services are provided by satellites, the Sat-backhaul WID roots its standardization work in the consideration of utilizing satellite connectivity for the wireless backhaul service. However, both the Rel-18 WIDs are based on the satellite 'transparent mode' , which focuses on the deployment architecture of only one satellite. In both WIDs, the RAN , i.e., eNB for LTE and gNB for 5G, is situated on the ground. The on-board (i.e., on-satellite) equipment does only fairly simple functionalities, e.g., frequency conversion, signal amplification, etc., which makes it act like a simple reflector, or so-called the 'bent pipe' mode as in . Therefore, there does not exist any implication from inter-satellite links or ISLs, nor does it have much (layer-2) switching & (layer-3) routing intelligence invovled.

Terminologies

TN: Terrestrial Network; refers to networks providing connectivity through communication lines that travel on, near, and/or below ground.
NTN: Non-Terrestrial Network; refers to networks providing connectivity through spaceborne satellites.

Criticalness of ISLs in the 3GPP Satellite work As of today, the 3GPP 5G standardization work has entered the final release, i.e., the Rel-19. There is an on-going satellite related study item (SID), i.e., 5GSat_Ph3 , that is based on the 'regenerative forwarding mode', as compared to the 'transparent mode' . Simply put, this SID studies the requirements of various kinds of satellite-based services, e.g., SMS, CIoT, etc., along with the associated challenges to accomplish the mobile registration, connection management, session establishment, and policy provisioning, etc. In the regenerative mode, a RAN (i.e., eNB for LTE and gNB for 5G) will be deployed on-board a satellite. Depending also on the characteristics of the offered mobile services, there might be other 4G/5G core network functions (NFs) to be deployed on-board satellite(s). Note that the above-mentioned satellite(s) might not be a single satellite. Actullay, it is almost guaranteed there are multiple independent satellite entities. So, this leads to naturally the introduction of the very critical topic for a satellite constellation network, i.e., the existence of inter-satellite links or ISLs along with their impact on providing network connectivity among satellites.

Challenges from the 3GPP Rel-19 Satellite Use case: Store & Forward The Rel-19 satellite use-case, store & forward or S&F , features the receiving of a message or datagram at an on-board (i.e., on-satellite) RAN from an on-ground UE. However, if the on-board RAN's connecting link to the on-ground core network is unavailable (i.e., the so-called unavailability of a feeder link), then the RAN will be delegated to store the message or datagram. The on-board RAN continues moving with the (hosting) satellite until the feeder link can provide the accessibility toward a ground-station (GS). At that moment, the stored message or datagram (at the on-board RAN) is delivered to the terrestrial network (TN). For the other direction of data delivery via the same satellite to the same UE, the satellite (along with the RAN) will have to rotate one or more rounds until the RAN can catch the UE again. At the first glance, someone might wonder that, even if the rotation time of one round is indeed long, the satellite will still be able to orbit back to the same geolocation (relative to Earth) after one round, at which the UE is previously located. Unfortunatley, this is not true thanks to Earth's self-rotation. For example, Earth is self-rotating at approximately 460 meter/sec at the equator. Assuming a LEO satellite could rotate the Earth one-round in 95 mins (of course, depending on the satellite's rotation track), then based on the following formula, Shift-distance on Earth = Earth-self-rotation-speed * Self-rotation-period we have, 460 m/s * (95 mins * 60 sec/min) ~ 2600 KM. This means the geolocation-shifting at the equator (relative to Earth) after one round could be more than 2000 Km. This significant shifting is way beyond the coverage of a RAN on-board a LEO satellite. Therefore, we can inherently draw the conclusion that the multi-satellite deployment with inter-satellite links (or ISLs) is the only feasible solution for satellite-based services. The shows the multi-satellite constellation network that serves as the hosting infrastructure for the 4G/5G satellite-based S&F service. In the figure, the wireless network functions (or NFs) RANs, MMEs and AMFs, etc., are on-board different satellites, which together provides wireless services to on-ground UEs. The satellites, with inter-satellite links or ISLs, form a connected network thru which wireless NFs can exchange operation context, transport data, sync-up states, and etc. Evidently, the previously-discussed geolocation-shifting challenge could be effectively addressed by a multi-satellite network.

|RAN|--|MME/AMF|----------------+ | : +---+ +-------+ : | | : : v | : +---+ +-------+ : +-----------------+ +---->|RAN|--|MME/AMF|------->| GS / TN / CN | | : +---+ +-------+ : +-----------------+ | : : ^ +----+ : : | | UE | : : | +----+ : : | | : +---+ +-------+ : | +---->|RAN|--|MME/AMF|----:-----------+ : +---+ +-------+ : ]]> Another advantage of a multi-satellite network is the latency reduction in data transfer & delivery. The work in has demonstrated thru simulation the better latency via the use of satellite constellation than purely using the underground fiber. We have to point out that, while ISLs play certainly a very important role in the Rel-19 5GSAT SID, the architectural assumption and the corresponding solution proposals of the SID claim that the network connectivity as provided by ISLs is out of the 3GPP scope . While we tend to agree from the 3GPP perspective, this does leave us an interesting routing topic to explore in the IETF domain.

Challenges from the 3GPP Rel-20 Satellite Use cases: Resilient Notifications & Operations The satellite based use cases continue gaining tractions in the 3GPP Rel-20 study. In , two use cases have been proposed to study the delay- or disruption-tolerant service provisioning via either resilient notification or operations upon the temporary network unavailability. For the communication between satellites and UEs, the possibly poor conditions of reception channels and sometimes the lack of LoS (Line of Sight) might lead to UEs missing important messages. The resilient notification service specifies a reliable and effective notification mechanism that delivers alerts (e.g., beacons) to UEs such that UEs could adjust their spots of signal reception for (delay-tolerant) critical messages. defines resilient operation mode when either the backhaul link between a LEO satellite and its corresponding ground station is temporarily unavailable or the core newtork of the LEO satellite was temporally unaccessible, for any unusually unexpected reasons. When a disruption event occurs, the resilient operation mode of a LEO satellite network helps (satellite-service) users continue their communication via UE-Satellite-UE paths. Simultaneously, the resilient satellite system continually searches for any available communication path and reconnects to the ground station via multi-hop inter-satellite links over LEO (and/or possibly MEO/GEO) satellites. Evidently, the resilient operation mode helps the service continuity of a disruption-tolerant satellite network.

A satellite constellation network is generally comprised of tens of thousands of nodes. This means the application of pre-configured switching is impractical, nor is the static routing with certain intelligence. This leaves the only feasible candidate the dynamic routing scheme. However, a non-terrestrial network (or NTN) in the space bears some uniqueness to be considered for the adoption of dynamic routing protocol. We will analyze the special restrictions of running dynamic routing over the integrated NTN & TN.

Restriction#1: The very dynamics of routing topology The rotation variations of satellites result in two types of routing dynamics . They are the dynamics thanks to the intermittent & varied connectivities between on-ground nodes and satellites, and the dynamics as caused by the ever-lasting satellite movements & thus the ISLs/neighborship flappings.

Dynamics between on-ground routing nodes and satellites: because of the versatile satellite parameters, e.g., height, inclination angle, azimuth angle, elevation angle, etc., the neighborship between a ground node and a satellite varies dramatically. Moreover, even if for the short period that a neighborship is maintained, the ever-changing distance (due to the orbital movement) between the two peering entities impacts the 'routing protocol cost' of a link. For example, assuming a LEO satellite orbits at the 500 km altitude. Therefore, the orbital period is roughly 95 minutes. Thanks to the choice of an evevation angle, a specific spot on Earth could access the satellite approximately for 7 minutes during one satellite round. This indicates not only the link-flapping (i.e., a dramatic routing event) after a 7-min service duration, but also the very fluid 'routing link cost' within the 7 minutes. The situation would be much challenging if considering the size of a satellite constellation network, along with the on-ground routing nodes intermittently connected to satellites.
Dynamics among satellite nodes: In the ideal scenario, there would be tens of thousands of satellites in a constellation network. Each satellite orbits around a pre-determined track. Depending on the coverage requirements, every track has some number of satellites. For the same height and same inclination angle, but with varied azimuth angles, there would be a lot of tracks forming a 'shell' around the Earth. Then, different height can yield different 'shell' . With this deployment topology in mind, we can project potentially the very complicated 'routing peers' as formed by satellites on the same track, between neighboring tracks, and between neighboring 'shells' . All satellites are moving, on the same direction, on the opposite directions, or on angled directions. They all move fairly fast. So, a well-established routing-peer may break up in a short period, and then either of them may form a new peering with other satellite nodes. The scenario is extremely dynamic, which will definitely de-stablize any existing routing protocol(s).

Both types of extreme dynamics collaboratively cause the frequent flapping of routing neighborship. The successive large amount of routing database updates & sync-up events thus lead to inefficiency of routing protocols.

Restriction#2: The limited bandwidth of peering links Normally, the links between peering satellites and between satellites and ground-stations or (on-ground) mobile equipment use either the radio or optical transports, either of which renders the fairly limited link bandwidth (BW). For example, in one case regarding the direct satellite service as offered by some mobile-phone providers, the measured uplink/downlink data-plane transmission rate via a GEO satellite is only @ 10 Kbps. In another field-trial recently published by a tier-1 MNO, with a LEO at the orbit height 550 Km, the measured rate is approximately 5 Mbps for Uplink, 1 Mbps for downlink, and 230 Mbps for ISLs. Therefore, for the satellite constellation network with a potentially large routing database (LSDB), the frequent control-plane activities, e.g., LSP exchanges, LSDB sync-up, etc., as caused by the , will certainly consume quite some percentage of the precious link capacities. This, in our opinion, must be avoided.

Restriction#3: The HW limitation & reduced capabilities Because of the harsh environment in the space, HW specifications of routing equipment on-board satellites must conform to very strict standards to accommodate challenging scenarios. Plus, it is also very expensive to carry loads in rocket launches. Therefore, the on-board routing equipment must be as effective as possible and may only have the mininally-required capabilites to fulfill the intra- and inter- satellite switching. On-board routing nodes must save energy due to power constraint. All the together lead to the on-board deployment of the capability-reduced routing entities that would not be able to run a full-fledge routing protocol.

Even if the discussed restrictions in post challenges to the satellite-based network routing, there exists a fairly unique characteristic in the satellite constellation, i.e., the trajectory and velocity of a satellite is predictable and can be pre-determined, which can help design more efficient routing mechanism. The periodic movement of a satellite could be well predicated based on track parameters & operational information of the satellite. These data can be, e.g., satellite height, inclination & azimuth angles, time-based link changes (flapppings), peering adjacencies, peering distance (i.e., link costs), and even traffic volumes. These satellite footprints are termed 'ephemeris', which bode well for more 'predictable' routing path selection. For example, the 5G standard demonstrates a ‘predictable’ QoS probing optimization upon using satellites to provide mobile backhaul service. In its description, the 5G control-functions (NFs like AMF, SMF, PCF, etc.) apply 'ephemeris' to predicting the availability of NFs in future. Then they engage with themselves via the 'scheduled changes' to guide the probing frequency of QoS monitoring. This is obviously more effective.

Design Principles The restrictions in and the advantageous ephemeris information together indicate that it is not effective, if not infeasible, to run the traditional dynamic routing scheme over on-board satellite nodes. Moreover, for a potential routing scheme that could be tailored to satisfy the requirements of a satellite constellation, it has to be associated with somewhat innovational satellite-based addressing semantics. For example, the IETF draft has provided a plausible satellite-based addressing scheme, which proposes the concepts of 'shell-, track- & sat- indices' to exclusively position (i.e., address) a satellite in the sky.

Principle#1: No full-set routing intelligence on satellites: There would not be dependent on dynamic routing, nor would there have distributed routing database (LSDB) via peering neighborship & LSP exchanges. Fundamentally, we propose to relieve the conventional routing burden from intermediary nodes (i.e., satellites) which do not need to rely on complex dynamic routing intelligence.
Principle#2: Simplified traffic forwarding logics on-board satellites: The switching logics should be as straightforward as they could get. They should not reply on dynamically-generated routing tags, nor do they stick to the ubiquitious longest-prefix matching scheme. It would be best if they are predictable and deterministic given the existence of satellite ephemeris.
Principle#3: Adoption of layered routing structure: The satellite constellation or non-terrestrial network (NTN) is integrated with the on-ground terrestrial network (TN) to offer the end-to-end connectivity. While the design principle#1 suggests not considering a full-set routing scheme over the on-board satellites, there would not be the similar restriction on the TN nodes. The TN nodes can just run any existing routing protocol(s).
This could naturally lead to a two-layer routing structure to differentiate the capability variations between the NTN and TN:
- a traditional routing scheme running for the 'overlay' TN, and
- a novel switching scheme operating exclusively for the 'underlay' NTN
Note this two-layer routing architecture bears the analogue of SRv6, MPLS, etc. However, unlike them, this scheme does not require any dynamic routing on the underlay NTN (e.g., the satellite networks)

Algorithmic Considerations for Path Selections We will briefly discuss how to select the end-to-end path between two on-ground nodes over the integrated TN & NTN. As we know, the GPS coordinate, i.e., (latitude, longitude), of any on-ground node can be accurately obtained. Then, a source node would utilize the GPS coordinate of a destination node, the ephemeris information of satellite nodes, and some novel design of the satellite addressing semantics (e.g., ), to calculate accurately the end-to-end path between them. The path constitutes both terrestrial nodes and satellite nodes. This paper provides a good design for the LEO based semantic routing. We can roughly consider the following three switching algorithms from a source to a destination:

Latitude first & Longitude second: the source node calculates the path 'horizontally' based on its latitude value until it reaches hypothetically the same longitude as the destination node. After that, the computation will be continued 'vertically' along the longitude until it reaches the destination coordinate.
Longitude first & Latitude second: the source node calculates the path 'vertically' based on its longitude value until it reaches hypothetically the same latitude as the destination node. After that, the computation will be continued 'horizontally' along the latitude until it reaches the destination coordinate.
'Big-circle' determined path: As we know, the shortest path between any two points along the surface of a sphere goes thru the 'big-circle' of the sphere, which is formed by the two points and the center of the sphere. So, the 3rd-algorithm recommends to use the 'big-circle' as the reference track to compute the end-to-end path between a source and a destination.

Generally, this function will not incur additional security issues.

This document makes no request of IANA.

The authors of the document appreciate the valuable inputs and contributions from Lin Han and Huaimo Chen, the numerous discussions with whom have instigated the work of the authors.