| Internet-Draft | Satellite Routing | February 2024 |
| Jiang, et al. | Expires 26 August 2024 | [Page] |
The 3GPP has done tremendous work to either standardize or study various types of wireless services that would depend on a 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 somewhat significant work to be explored in the IETF domain. This draft stems from the latest 3GPP satellite use cases, and lands on summarizing the restrictions & challenges in term of satellite-based routing. Based on some unique & advantageous characteristics associated with satellite movement, the draft raises briefly the general design principles and possible algorithms for the integrated NTN+TN routing, while leaves the implementation details for further expansion.¶
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 26 August 2024.¶
Copyright (c) 2024 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, 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 [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 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' [TR.38.821], 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 [TR.38.821]. 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.¶
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 [TR.23.700-29], that is based on the 'regenerative forwarding mode', as compared to the 'transparent mode' [TR.38.821]. 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.¶
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 round 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 Figure 1 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 easily 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 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 [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.¶
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.¶
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.¶
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' [IETF-Draft.SAT-PR]. 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' [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).¶
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.¶
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 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 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 Section 2 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 [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. This is obviously more effective.¶
The restrictions 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.¶
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:¶
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)¶
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., [IETF-Draft.SAT-SemAddressing]), to calculate accurately the end-to-end path between them. The path constitutes both terrestrial nodes and satellite nodes. This paper [ICNP22-NIB-LEO.Routing] 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:¶
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.¶