Internet DRAFT - draft-jiang-tvr-sat-routing-consideration
draft-jiang-tvr-sat-routing-consideration
TVR Working Group T. Jiang
Internet-Draft P. Liu
Intended status: Informational China Mobile
Expires: 26 August 2024 H. Chen
Futurewei Technologies
23 February 2024
Routing Consideration for Satellite Constellation Network
draft-jiang-tvr-sat-routing-consideration-00
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jiang, et al. Expires 26 August 2024 [Page 1]
Internet-Draft Satellite Routing February 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Criticalness of ISLs in the 3GPP Satellite work . . . . . 3
1.3. Challenges from the 3GPP Satellite Use case: Store &
Forward . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Satellite Routing: Restrictions & Challenges . . . . . . . . 6
2.1. Restriction#1: The very dynamics of routing topology . . 6
2.2. Restriction#2: The limited bandwidth of peering links . . 7
2.3. Restriction#3: The HW limitation & reduced
capabilities . . . . . . . . . . . . . . . . . . . . . . 7
3. Satellite Routing: Uniqueness, Design Principles & Algorithmic
Considerations . . . . . . . . . . . . . . . . . . . . . 8
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 8
3.2. Algorithmic Considerations for Path Selections . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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.
Jiang, et al. Expires 26 August 2024 [Page 2]
Internet-Draft Satellite Routing February 2024
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.
1.1. 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.
1.2. 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 [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).
Jiang, et al. Expires 26 August 2024 [Page 3]
Internet-Draft Satellite Routing February 2024
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.
1.3. Challenges from the 3GPP Satellite Use case: Store & Forward
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
Jiang, et al. Expires 26 August 2024 [Page 4]
Internet-Draft Satellite Routing February 2024
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|----:-----------+
: +---+ +-------+ :
Figure 1: Multi-SAT Architecture for 4G/5G S&F Service
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.
Jiang, et al. Expires 26 August 2024 [Page 5]
Internet-Draft Satellite Routing February 2024
2. Satellite Routing: Restrictions & Challenges
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.
2.1. Restriction#1: The very dynamics of routing topology
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
Jiang, et al. Expires 26 August 2024 [Page 6]
Internet-Draft Satellite Routing February 2024
'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.
2.2. 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 Section 2.1, will certainly
consume quite some percentage of the precious link capacities. This,
in our opinion, must be avoided.
2.3. 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.
Jiang, et al. Expires 26 August 2024 [Page 7]
Internet-Draft Satellite Routing February 2024
3. Satellite Routing: Uniqueness, Design Principles & Algorithmic
Considerations
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.
3.1. Design Principles
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#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
Jiang, et al. Expires 26 August 2024 [Page 8]
Internet-Draft Satellite Routing February 2024
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)
3.2. 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., [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:
* 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.
Jiang, et al. Expires 26 August 2024 [Page 9]
Internet-Draft Satellite Routing February 2024
* 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.
4. Security Considerations
Generally, this function will not incur additional security issues.
5. IANA Considerations
This document makes no request of IANA.
6. Acknowledgements
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.
7. References
7.1. Normative References
[IETF-Draft.SAT-PR]
Han, L., "Problems and Requirements of Satellite
Constellation for Internet", draft-lhan-problems-
requirements-satellite-net-06, January 2024.
[IETF-Draft.SAT-SemAddressing]
Han, L., "Satellite Semantic Addressing for Satellite
Constellation", draft-lhan-satellite-semantic-addressing-
04, September 2023.
[TR.23.700-27]
"3GPP TR 23.700-27 (V18.0.0): Study on 5G system with
Satellite Backhaul", 3GPP TR 23.700-27, December 2022.
Jiang, et al. Expires 26 August 2024 [Page 10]
Internet-Draft Satellite Routing February 2024
[TR.23.700-28]
"3GPP TR 23.700-28 (V18.1.0): Study on Integration of
satellite components in the 5G architecture; Phase
2", 3GPP TR 23.700-28, March 2023.
[TR.23.700-29]
"3GPP TR 23.700-29 (V19.2.0): Study on integration of
satellite components in the 5G architecture; Phase
3", 3GPP TR 23.700-29, February 2024.
[TR.38.821]
"3GPP TR 38.821 (V16.2.0): Solutions for NR to support
non-terrestrial networks (NTN)", 3GPP TR 38.821, March
2023.
[TS.23.501]
"3GPP TS 23.501 (V18.2.1): System Architecture for the 5G
System (5GS)", 3GPP TS 23.501, June 2023.
[TS.23.503]
"3GPP TS 23.503 (V18.2.0): Policy and charging control
framework for the 5G System (5GS); Stage 2", 3GPP TS
23.503, June 2023.
7.2. Informative References
[ICNP22-NIB-LEO.Routing]
Han, L. and et al., "New IP based semantic addressing and
routing for LEO satellite networks", https://newip-and-
beyond.net/presentations/W_S3_Han.pdf, October 2022.
[ICNP23-6G.SQSC-Sat.Comm]
Han, L. and et al., "Evolution to 6G for Satellite NTN
Integration: From Networking
Perspective", https://qualitativesemantic.wordpress.com/,
October 2023.
[UCL-Mark-Handley]
Handley, M., "Using ground relays for low-latency wide-
area routing in megaconstellations",
https://discovery.ucl.ac.uk/id/eprint/10090242/1/hotnets-
ucl.pdf, November 2019.
Authors' Addresses
Tianji Jiang
China Mobile
Email: tianjijiang@chinamobile.com
Jiang, et al. Expires 26 August 2024 [Page 11]
Internet-Draft Satellite Routing February 2024
Peng Liu
China Mobile
Email: liupengyjy@chinamobile.com
Huaimo Chen
Futurewei Technologies
Email: hchen.ietf@gmail.com
Jiang, et al. Expires 26 August 2024 [Page 12]
