| Internet-Draft | Satellite Routing Problems | March 2025 |
| Liu & Jiang | Expires 3 September 2025 | [Page] |
The SDO 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on the satellite constellation network. While the ISLs, or Inter-Satellite Links, along with the routing scheme(s) over them are critical to help fullfil the satellite services, the 3GPP considers them out-of-scope. This leaves the significant work to be explored in the IETF domain. This draft stems from the 3GPP satellite use cases that have been studied for many years up to now, across a couple of releases, and lands on summarizing the challenges & considerations of the satellite-based routing. Based on some unique & advantageous characteristics associated with satellite networks, the draft raises briefly the general routing considerations for the integrated Non-Terrestrial & Terrestial Networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
For the last couple of years and until now, 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 and future 6G normative 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 [TR.23.700-28] and the Sat-backhaul [TR.23.700-27]. 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 satellite networks, the Sat-backhaul WID focuses its standardization work upon utilizing satellite connectivity for the wireless backhaul service. However, both the Rel-18 WIDs are based on the satellite 'transparent mode' [TR.38.821], which concentrates 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 [TR.38.821]. A satellite in this mode is restricted to function only as a transparent relay. There does not exist any implication from inter-satellite links or ISLs, nor does it have (layer-2) switching & (layer-3) routing intelligence invovled.¶
The 3GPP 5G Rel-19 standardization work has a satellite related work item (WID), i.e., 5GSat_Ph3 [TR.23.700-29]. It studied 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. Different from the 'transparent mode' as described in Section 1.2, this work is standardizing the 'regenerative payload forwarding mode', for which RAN nodes (i.e., eNB for LTE and gNB for 5G) will be deployed on-board satellites. 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). Evidently, the regenerative mode with multiple satellites and with multiple NF entities on-board satellites will certainly go beyond the layer-1 'transparent relay', and move toward the layer-2 or even layer-3 based switching and/or routing.¶
The regenerative mode guarantees the involvement of multiple independent satellite entities. 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.¶
The Rel-19 satellite use-case, store & forward or S&F [TR.23.700-29], 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 (via the coverage of the hosting satellite) 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 was 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 that is on-board a LEO satellite, assuming optical based transmission [Optical-transmission-range]. Therefore, we can inherently draw the conclusion that the multi-satellite deployment with inter-satellite links (or ISLs) is the most feasible solution for satellite-based services.¶
The Figure 1 shows the multi-satellite constellation network that serves as the hosting infrastructure for the 4G/5G satellite-based S&F (Store & Forward) service. In the figure, the wireless network functions (or NFs) RANs, MMEs and AMFs, etc., are on-board different satellites, which together provide 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.¶
MME/AMF: 4G/5G Contro NFs GS: ground-station
TN: terrestrial Network CN: 4G/5G Core Network
: :
: On-board Satellites : On-ground
: :
: +---+ +-------+ :
+---->|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 [UCL-Mark-Handley] 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 satellite work, the architectural assumption and the corresponding solution proposals of the WID claim that the network connectivity as provided by ISLs is out of the 3GPP scope [TR.23.700-29]. While we tend to agree from the 3GPP perspective, this does leave us an interesting routing topic to explore in the IETF domain.¶
The satellite based use cases continue gaining tractions in the 3GPP Rel-20 study. In [TS.22.887], two use cases have been proposed to study either the delay- or disruption-tolerant service, i.e., resilient notification upon the temporary network unavailability, or the service continuity in remote areas via multi-orbit satellite networks.¶
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. [TS.22.887] 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 reason(s). 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.¶
The same document [TS.22.887] also strives to achieve seamless network connectivity and service continuity via a multi-orbit satellite constellation network, with which the (limited) coverage as experienced by LEO satellites would be complemented by services from medium-Earth-Orbit (MEO) and/or Geo-stationary (GEO) satellites. Taking the resilient operation as the example: for some rare case, if there is no available communication path from a serving LEO to the ground station via LEO-based inter-satellite links (ISLs), the satellite system may continue searching via MEO or even GEO satellites to achieve the service continuity.¶
A satellite constellation network is generally comprised of tens of thousands of (satellite) nodes. This implies the application of pre-configured switching is impractical, nor is the static routing with certain intelligence. This also means the transparent payload mode shall be out of the picture. 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 challenges of running dynamic routing over the integrated NTN & TN.¶
The rotation variations of satellites result in two types of routing dynamics [ICNP23-6G.SQSC-Sat.Comm]. 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, e.g., in the case of OSPF link-cost computation.¶
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 potentially large scale of on-ground routing nodes that might be intermittently connected to satellites.¶
Dynamics among satellite nodes: In the ideal scenario, there would be tens of thousands of satellites in a satellite 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' [IETF-Draft.SAT-PR]. With this multi-orbit satellite 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' [IETF-Draft.SAT-PR].¶
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).¶
When compared to scenarios in the TN, both types of extreme dynamics will collaboratively cause the frequent flapping of routing neighborship. The successive large amount of routing database updates & sync-up events thus impair the efficiency of any adopted routing protocols.¶
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 published by a tier-1 MNO last year, 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 elucidated in the Section 2.1, will certainly consume quite some percentage of the precious link capacities. This, in our opinion, must be avoided.¶
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 minimally-required capabilites to fulfill the intra- and inter- satellite switching. On-board routing nodes must save energy due to power constraint. All these 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 multi-orbit satellite nework faces many challenges (as laid out in Section 2), 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. This will help design more efficient routing mechanism.¶
The periodic movement of a satellite could be well predicated based on track parameters, peering projection, and 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 [TS.23.501] 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. It is certainly more effective.¶
The challenges in Section 2 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 [IETF-Draft.SAT-SemAddressing] 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.¶
Consideration #2: 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 consideration#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:¶
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)¶
Consideration #3: Impact of the 'multi-orbit' objective: Satellite network is a multi-hierarchy, multi-track-per-hierarchy and multi-satellite-per-track, or so-called 'multi-orbit', constellation network. When an existing routing protocol (of course, with extension) or a new one is applied, the different roles of different satellites, i.e., LEO, MEO or GEO satellites, may play different factors that would impact the topology design and the selection of routing logics.¶
A multi-orbit satellite network with LEO, MEO and/or GEO implies the existence of multiple comparable routing paths, or so-called equal-cost or non-equal-cost multi-path. This bodes well for the almost-given sporadic, compromised or even failed communication between satellites and on-ground devices becuase of the re-route mechanism from the multi-path nature.¶
Consideration #5: Incorporate more intelligence into the routing scheme & path selection, e.g., the theme & objectives of IETF CATS or Compute Aware Traffic Steering WG: as argued in Section 2, the satellite HW normally bears the capability restriction, battery insufficiency, on-board processing limitation, and etc. All these compute-like factors should be combined with the traditional routing metrics (i.e., BW, delay, load, loss, reliability, etc.) to form a CATS-like network for integrated NTN + TN routing consideration.¶
Further, the novel routing scheme should avoid unbalanced density of the number of satellites, especially in the polar area when the inclination angle of all orbital tracks are 90-degree [IETF-Draft.SAT-PR].¶
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, the numerous discussions with whom have instigated the work of the authors.¶