Skip to main content

Routing Consideration for Satellite Constellation Network
draft-jiang-tvr-sat-routing-consideration-01

Document Type Active Internet-Draft (individual)
Authors Tianji Jiang , Peng Liu
Last updated 2024-07-03
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jiang-tvr-sat-routing-consideration-01
TVR Working Group                                               T. Jiang
Internet-Draft                                                    P. Liu
Intended status: Informational                              China Mobile
Expires: 4 January 2025                                      3 July 2024

       Routing Consideration for Satellite Constellation Network
              draft-jiang-tvr-sat-routing-consideration-01

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 4 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jiang & Liu              Expires 4 January 2025                 [Page 1]
Internet-Draft              Satellite Routing                  July 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 Rel-19 Satellite Use case: Store &
           Forward . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.4.  Challenges from the 3GPP Rel-20 Satellite Use cases:
           Resilient Notifications & Operations  . . . . . . . . . .   6
   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 . .   8
     2.3.  Restriction#3: The HW limitation & reduced
           capabilities  . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Satellite Routing: Uniqueness, Design Principles & Algorithmic
           Considerations  . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Algorithmic Considerations for Path Selections  . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 & Liu              Expires 4 January 2025                 [Page 2]
Internet-Draft              Satellite Routing                  July 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 & Liu              Expires 4 January 2025                 [Page 3]
Internet-Draft              Satellite Routing                  July 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 Rel-19 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 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 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)

Jiang & Liu              Expires 4 January 2025                 [Page 4]
Internet-Draft              Satellite Routing                  July 2024

   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.

          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 & Liu              Expires 4 January 2025                 [Page 5]
Internet-Draft              Satellite Routing                  July 2024

1.4.  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 [TS.22.887], 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.

   [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 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.

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.

Jiang & Liu              Expires 4 January 2025                 [Page 6]
Internet-Draft              Satellite Routing                  July 2024

   *  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.

Jiang & Liu              Expires 4 January 2025                 [Page 7]
Internet-Draft              Satellite Routing                  July 2024

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.

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

Jiang & Liu              Expires 4 January 2025                 [Page 8]
Internet-Draft              Satellite Routing                  July 2024

   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
      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

Jiang & Liu              Expires 4 January 2025                 [Page 9]
Internet-Draft              Satellite Routing                  July 2024

      -  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.

   *  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.

Jiang & Liu              Expires 4 January 2025                [Page 10]
Internet-Draft              Satellite Routing                  July 2024

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 and Huaimo Chen, 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.

   [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.22.887]
              "3GPP TS 22.887 (Rel-20, V0.1.0): Feasibility Study on
              satellite access - Phase 4",  3GPP TS 22.887, June 2024.

Jiang & Liu              Expires 4 January 2025                [Page 11]
Internet-Draft              Satellite Routing                  July 2024

   [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

   Peng Liu
   China Mobile
   Email: liupengyjy@chinamobile.com

Jiang & Liu              Expires 4 January 2025                [Page 12]