Internet-Draft Routing Framework for LEO Constellation July 2023
Hou, et al. Expires 3 January 2024 [Page]
Workgroup:
RTGWG
Internet-Draft:
draft-hou-rtgwg-satellite-routing-framework-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Hou, Ed.
ZTE Corporation
X. Min
ZTE Corporation
F. Zhou
ZTE Corporation

Routing Framework for LEO Mega-constellation Based on Region Division

Abstract

The inter-satellite routing is the premis to ensure that the satellite network provides end-to-end stable service covering the whole globe. However, the mature terrestrial network technologies are difficult to directly apply to the satellite network because of the highly dynamic network topology and the limited on-board resources. This issue is further exacerbated in LEO mega-constellations. In view of this challenge, this document presents a routing framework for LEO mega-constellation. Based on the orbit position characteristic and the predictable topology, this framwork realizes flexible region division, establishes intra-region and inter-region path, as well as completes end-to-end data forwarding.

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 2 January 2024.

Table of Contents

1. Introduction

The LEO mega-constellation networks can overcome the limitations of the conventional terrestial network, achieving global signal coverage, and providing large broadband and low-latency network services for global users. The global communications ecosystem suggests that satellite-based communication will become an important part of 5G-advanced and 6G.

Routing issues are the premise to ensure the stable worldwide end-to-end service based on the satellite network. Compared with the terrestial network, the satellite network has the characteristics of highly dynamic nodes, time-varying network topology, and limited on-board resources. So the mature terrestrial nework routing technology is difficult to directly apply.

In view of this situation, some improved routing methods have been proposed based on the predictable topology changes in the satellite network. However, the development trend of the satellite network is becoming more and more low-orbit and large-scale, which further intensifies the dynamic property of the network. More topology changes as well as information announcements are happend, which would result in frequent routing calculations, much more protocol overhead, and even route flapping.

To tackle the above issues, the terrestial network generally adopts the manner of area division to imporve the efficiency of routing convergence and network management. The existing area division method typically divides a network into a backbone area and multiple non-backbone areas. The backbone area is unique and has routing informations of all areas. The non-backbone areas establish fixed connections around the backbone area. Thus, nodes in the backbone area are responsible for traffic forwarding between all areas, and require higher performance. However, the performance of satellites is peer-to-peer and limited, especially in the single-layer satellite constellation. The current area division method could easily make the backbone area congested in the satellite network. Besides, due to the permanent changes of the satellite network topology, the connection relationship between different areas is unable to maintain stability, and each area need to exchange routing informations continuously. So the existing area division method is not only inefficient but also lacks sufficient flexibility, and can't meet the requirement of routing in the satellite network.

Considering these problems, this document proposes a routing framework for LEO mega-constellation networks based on region division. The details of this framework are as follows:

(1) Firstly, based on the relative position between satellites, the new node type and capability are defined to realize flexible region divesion.

(2) Then, the mapping relationship between nodes and regions is established based on the satellite orbit position to reduce the inter-region network information announcement.

(3) Finally, based on the predictable network topology in the satellite network, the inter-region and intra-region paths are constructed to complete the end-to-end data forwarding.

Further details are discussed in subsequent sections.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

4. Region Planning

4.1. Region Model

In the satellite network, each satellite moves along the orbit, which can be divided into circular orbit satellites and elliptical orbit satellites. Different orbits can be described by Keplerian parameters. At present, the mainstream of satellite networks basically adopt circular orbit.

    Orbit     Orbit     Orbit
   Plane 1   Plane 2   Plane 3

     |         |         |
   +---+     +---+     +---+
---| 1 |-----| 4 |-----| 7 |---
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+     +---+
---| 2 |-----| 5 |-----| 8 |---
   +---+     +---+     +---+
     |         |         |
     |         |         |
   +---+     +---+     +---+
---| 3 |-----| 6 |-----| 9 |---
   +---+     +---+     +---+
     |         |         |
Figure 1: N5 and its adjacent satellites

When links between satellites are established for end-to-end communication, each satellite usually has a fixed number of links which communicate with neighboring nodes, and considering the cost of satellite links and power restrictions of satellites, satellite links are generally limited to direct connections between adjacent nodes. In a single-layer satellite constellation, each satellite may have four types of contiguous neighbour satellites and each type refers to a direction. The number of neighbor satellites distributed in one direction is determined by the number of antennas deployed on the satellite for communication. If the satellite contains a single antenna in each direction, the connection relationship between the satellite N5 and its two satellites in the same orbit and two satellites in different adjacent orbits is shown in Figure 1. In a multi-tier satellite constellation, each satellite may have two additional types of adjacent satellites, upper level satellites and lower level satellites in different tiers.

Therefore, the quadrangle is adopted as the basic model of region division, that is, a region also have four types of contiguous neighbour regions and each type refers to a direction, as shown in Figure 2. In this way, satellites in each region and the adjacency relationship between regions could remain unchanged with the dynamic change of satellite topology.

          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--+--| 2 |
+---+  |  +---+     +---+     +---+  |  +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |   l=3
       |  +---+     +---+     +---+  |
      h=3 | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+
Figure 2: Basic model of region division

4.2. Mapping Relationship

In a satellite constellation which has M orbit planes and N nodes per orbit plane, the orbit position information of a satellite can be marked with (X, Y), namely the node identifier. The corresponding region number k of this satellite can be calculated by Formula 1.

k=ceil(X/l)*(M/l)+ceil(Y/h)+delta

The X is the orbit plane of the satellite. The Y is the sequence in the orbit plane of the satellite. The h is the number of satellites included in the region in a single orbit plane. The l is the number of orbits spanned by the region. The h and the l are region range parameters which can be pre-planned by the control layer of the network. The delta is an offset value when calculating the region number.

Based on the orbit position information, the communication port of the satellite is addressed. During the data forwarding process, each relay satellite resolves the destination node identifier from the destination address, and then calculates the region number of the destination node via Formula 1. Through this method, each node can determine the mapping relationship between regions and nodes.

5. Node Capability

In order to realize the region division described in the previous section, the corresponding capability of the satellite node should be defined.

It should be noted that the process of satellite motion along the orbit is periodic and predictable. Predictable information in a satellite network includes the real-time position of a satellite, the connectivity of satellite links, the characteristics of satellite links.

Based on these predictable information, the management plane, the control plane and the forwarding plane of the network can be adaptively improved to ensure a stable and optimal end-to-end reachable path between a pair of satellites. On one hand, the flooding of routing convergence information caused by network topology changes can be avoided. On the other hand, the routing re-calculation is able to be fulfilled in advance before the satellite network topology changes. Thus the calculated results can be updated immediately and timely. The same methods can also apply to predictable changes in the characteristics of satellite links. The node capabilities described in this section incorporate this manner.

5.1. Node Type

According to the relative position of a satellite in the rigion, the type of the satellite can be classified as the internal node and the border node. The internal node doesn't connect nodes outside of the rigion. The border node is part of the rigion and has connections to nodes outside of the rigion. The internal node and the border node are collectively referred as the intra-region nodes. The node which have connections to the border node in the neighbor rigion is called the cross-rigion neighbor node.

5.2. Border Node Capability

Each region is abstracted as a single virtual node to hide the network information and the topology change from the external network. The virtual node represents the time-varying geographical location of a region in the satellite network. The geographical location of the virtual node corresponds to the specified node in the region. The specified node could be configured by the network administrator or elected via protocol mechanism. It should be noted that there is only one edge between any two adjacent virtual nodes.

In order to shield the network information in a region from the external network, the border node should have the following features:

(1) The capability of establishing connections with cross-rigion neighbor nodes.

The border node is the agent of the external connection for the local region, and is responsible for establishing the connection with the cross-rigion neighbor node. During the connection establishment process, these nodes build the adjacency relationship and announce the region number with each other. After the border node receives the region number of the neighbor region, the border node informs this information to other nodes on the local region.

(2) The capability of maintaining connections with cross-rigion neighbor nodes.

The change of the connection relationship between the border node and the cross-rigion neighbor node can be divided into predictable and unpredictable. The predictable connection change can be self-calculated and obtained by each node according to the orbit parameters. Therefore, the border node only notifiy the unpredictable connection change to nodes in the same region. Figure 3 presents a unpredictable link failure between A19 adn A24, and N8 is responsible for informing other nodes in the same region.

          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+ \|/ +---+
| 8 |--+--| 2 |-----| 5 |-----| 8 |--X--| 2 |
+---+  |  +---+     +---+     +---+ /|\ +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |
       |  +---+     +---+     +---+  |
          | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+
Figure 3: Inter-region link failure

(3) The capability of isolating network information advertisements between different regions.

If the network variation is happened in a region (such as link interruption, node failure, and etc.), the affected nodes will typically flood routing information to other nodes. When the flooding information reaches the border node, this information will be blocked, that is, the routing information in a region can't pass through the border node to the adjacent region.

5.3. Shared Node Capability

In addition to the above unique features of the border node, both the border node and the internal node share the following functions:

(1) The capability of maintaining intra-region network information.

When a region is initially created, the node establishes a connection with a neighbor node, determines the node of the region based on the planned region parameters, generates a network topology in the region according to the orbit parameters, notifies its own network information to other nodes in the region, and continuously monitors its own direct links. Then, the node calculates and updates the intra-region network topology according to the planned time interval by the predictability of satellite orbital movement. As a sudden failure occurs, the node notifies it and updates the local network information and the intra-region topology. Figure 4 presents a unpredictable link failure between N5 adn N8. N5 and N8 are responsible for informing other nodes in the same region.

          Orbit     Orbit     Orbit
         Plane 1   Plane 2   Plane 3

          +---+     +---+     +---+
          | 3 |-----| 6 |-----| 9 |
       |  +---+     +---+     +---+  |
       |    |   A18   |         |    |
   ----+----+---------+---------+----+----
+---+  |  +---+     +---+     +---+  |  +---+
| 7 |--+--| 1 |-----| 4 |-----| 7 |--+--| 1 |
+---+  |  +---+     +---+     +---+  |  +---+
  | A14|    |   A19   |         |    |A24 |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+ \ / +---+  |  +---+
| 8 |--+--| 2 |-----| 5 |--X--| 8 |--+--| 2 |
+---+  |  +---+     +---+ / \ +---+  |  +---+
  |    |    |         |         |    |    |
  |    |    |         |         |    |    |
+---+  |  +---+     +---+     +---+  |  +---+
| 9 |--+--| 3 |-----| 6 |-----| 9 |--+--| 3 |
+---+  |  +---+     +---+     +---+  |  +---+
   ----+----+---------+---------+----+----
       |    |   A20   |         |    |
       |  +---+     +---+     +---+  |
          | 1 |-----| 4 |-----| 7 |
          +---+     +---+     +---+
Figure 4: Intra-region link failure

(2) The capability of maintaining cross-region connection relationships.

When a region is initially created, the node generates a mapping relationship between the border node and the adjacent region according to the notification information of the border node. Then, the node periodically calculates the connectivity between border nodes and connected cross-region neighbor nodes based on the predictability of satellite orbital movement, and updates the mapping relationship. As a sudden failure occurs, each node in the local region receives the routing information announced by the border node, and updates the mapping relationship.

(3) The capability of maintaining inter-region network topology.

Based on the orbit parameters of the designated nodes in the region corresponding to the virtual nodes, and the planned region range, the node calculate the geographical positions of other virtual nodes in the entire network to obtain the inter-region network topology.

6. Routing Computation

6.1. Information for Routing Calculation

Through above node capabilities, each node maintains following network informaiton, including the intra-region topology relationship, the inter-region topology relationship, as well as the mapping relationship between the border node and the adjacent region.

(1) Inter-region topology relationship

Based on the satellite parameters (such as orbit parameters, satellite running time, and etc.), each satellite calculates the geographical location of virtual node corresponding to each region and constructs the inter-region topology relationship. Then, according to the inter-region topology relationship and the route computation algorithm, inter-region paths between the local region and others are obtained. Finally, the next hop regions to reach destination regions is also achieved. Figure 5 shows the representation of the inter-region topology relationship.

+------+------+------+
| Area1| Area2| Cost |
+------+------+------+
|  A14 |  A19 |  10  |
+------+------+------+
Figure 5: Inter-region topology relationship

(2) Intra-region topology relationship

Each satellite calculates the connection relationship between any two nodes in the local region based on the satellite parameters. According to the connection relationship, intra-region topology relationship is constructed, which shows in Figure 6.

+------+------+------+
| Node1| Node2| Cost |
+------+------+------+
|  N1  |  N2  |  6   |
+------+------+------+
Figure 6: Intra-region topology relationship

(3) Mapping relationship

In a region, each satellite receives the neighbor region number advertised by the border node. Then, a mapping relationship between the neighbor region and the border node is constructed. Figure 7 shows the representation of the mapping relationship.

+-----------+----------+
| Edge Node | Nig Area |
+-----------+----------+
|    N1     |   INF    |
+-----------+----------+
|    N2     |   A14    |
+-----------+----------+
Figure 7: Mapping relationship

6.2. Routing Computation

Based on these network information, the intra-region routing table and inter-region routing table could be constructed.

(1) Intra-region routing

When the destination address of the data packet is identified in the local region, the intra-region routing table is used for the data forwarding. The data forwarding process is consistent with the terrestrial network. The intra-region routing table entries include destination address, network mask, routing priority, routing overhead, forwarding interface, and next hop address.

(2) Inter-region routing

When the destination address of the data packet is identified in the remote region, the inter-region routing table is used for the data forwarding. The path calculation process of each node is as follows:

a. Firstly, based on the inter-region topology relationship, the inter-region path from the region where the node is located to other regions is calculated.

b. Then, according to the mapping relationship and the intra-region topology relationship, the intra-region path to the next hop region is calculated.

The inter-region routing table entries replaces the destination address and network mask with the destination area, and adds the next hop forwarding area. Figure 8 presents an example of the inter-region routing table.

+--------+---------+-----+------+-----+------------+
|Dst Area| Nxt Area| Pri | Cost | Inf | Nxt Hop Adr|
+--------+---------+-----+------+-----+------------+
|   22   |   18    |  1  |  6   | eth |  x.x.x.x   |
+--------+---------+-----+------+-----+------------+
Figure 8: Inter-region routing table

7. Data Forwarding

7.1. Scenario 1: Intra-region data forwarding

As shown in Figure 9, N2 and N4 are located in the same region. N2 serves as the source end to send data to the destination end N4. The data forwarding path between N2 and N4 pass through N2, N5, and N4 in turn. The routing process is consistent with that of the terrestial network. So, this document doesn't describe the process here.

                     Orbit plane 1       Orbit plane 2

                 |       .--.                .--.       |
                 |  ###-| N3 |-### <--> ###-| N6 |-###  |
                 |       \__/                \__/       |
                 |        ^        A18        ^         |
   --------------+--------+-------------------+---------+--------------
        A14      |        v        A19        v         |     A24
     .--.        |       .--.                .--.       |        .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v          |        v ----------------> v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^         |         ^
      |          |        |                   |         |         |
      v          |        v                   v         |         v
     .--.        |       .--.                .--.       |        .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
     \__/        |       \__/                \__/       |        \__/
                 |        ^                   ^         |
   --------------+--------+-------------------+---------+--------------  N
                 |        v        A20        v         |                ^
                 |       .--.                .--.       |                |
                 |  ###-| N1 |-### <--> ###-| N4 |-###  |         Moving |
                 |       \__/                \__/       |      Direction S
Figure 9: Intra-region data forwarding

7.2. Scenario 2: Inter-region data forwarding

+-----+-----+-----+-----+-----+-----+
| A1  | A6  | A11 | A16 | A21 | A26 |
|     |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+
| A2  | A7  | A12 | A17 | A22 | A27 |
|     |     |     |    ^>>    |     |
+-----+-----+-----+----^+-----+-----+
| A3  | A8  | A13 | A18^| A23 | A28 |
|     |     |     |    ^|     |     |
+-----+-----+-----+----^+-----+-----+
| A4  | A9  | A14 | A19^| A24 | A29 |
|   >>>>>>>>>>>>>>>>>>>>|     |     |
+-----+-----+-----+-----+-----+-----+
| A5  | A10 | A15 | A20 | A25 | A30 |
|     |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+
Figure 10: End-to-end inter-region path

As shown in Figure 10, the satellite network is divided into 30 regions. At a certaion time, Sat1 is located in region 4 and Sat2 is located in region 22. Sat1 serves as the source end to send data to the destination end Sat2. The data forwarding path between Sat1 and Sat2 pass through region 4, 9, 14, 19, 18, 17, and 22 in turn.

As shown in Figure 11, the data is forwarded from Node 6 in region 14 to Node 3 in region 19 20. Node 3 resolves the destination node identifier (x_dst, y_dst) from the destination address, and then calculates the region number of the destination node as 22 via Formula 1.

Node 3 queries the inter-region routing table to forward data. According to the inter-region routing table record, if the destination node is located in region 22, the data packet is forwarded via region 18, and the next hop node is Node 6. Each node in region 19 repeats the above operations, and finally forwards the packet to region 18. For the border node, the next hop address in the inter-region routing table is the port address of the cross-rigion neighbor satellite.

                     Orbit plane 1       Orbit plane 2

                 |       .--.                .--.       |
                 |  ###-| N3 |-### <--> ###-| N6 |-###  |
                 |       \__/                \__/       |
                 |        ^        A18        ^  ^      |
   --------------+--------+-------------------+--|------+--------------
        A14      |        v        A19        v  |      |     A24
     .--.        |       .--.                .--.       |        .--.
###-| N4 |-### <-+> ###-| N1 |-### <--> ###-| N4 |-### <+-> ###-| N1 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v          |        v                   v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N5 |-### <-+> ###-| N2 |-### <--> ###-| N5 |-### <+-> ###-| N2 |-###
     \__/        |       \__/                \__/       |        \__/
      ^          |        ^                   ^  ^      |         ^
      |          |        |                   |  |      |         |
      v ----------------> v ----------------> v  |      |         v
     .--.        |       .--.                .--.       |        .--.
###-| N6 |-### <-+> ###-| N3 |-### <--> ###-| N6 |-### <+-> ###-| N3 |-###
     \__/        |       \__/                \__/       |        \__/
                 |        ^                   ^         |
   --------------+--------+-------------------+---------+--------------  N
                 |        v        A20        v         |                ^
                 |       .--.                .--.       |                |
                 |  ###-| N1 |-### <--> ###-| N4 |-###  |         Moving |
                 |       \__/                \__/       |      Direction S
Figure 11: Inter-region data forwarding

8. Extensions and Future Works

In the future work, following problems would be taken in mind:

(1) Extension of the current routing protocol to support the framework described in this document.

(2) Improvement of the routing algorithm presented in this document to consider more network metrics and obtain the optimal path

9. Security Considerations

TBA

10. Acknowledgements

TBA

11. IANA Considerations

This document has no IANA actions.

12. References

12.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

12.2. Informative References

[I-D.hou-tvr-satellite-network-usecases]
Dongxu, H., Min, X., Zhou, F., and D. Yuan, "Satellite Network Routing Use Cases", Work in Progress, Internet-Draft, draft-hou-tvr-satellite-network-usecases-01, , <https://datatracker.ietf.org/doc/html/draft-hou-tvr-satellite-network-usecases-01>.
[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., and Y. Qu, "TVR (Time-Variant Routing) Use Cases", Work in Progress, Internet-Draft, draft-ietf-tvr-use-cases-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-use-cases-00>.
[I-D.lhan-satellite-semantic-addressing]
Han, L., Li, R., Retana, A., chenmeiling, and N. Wang, "Satellite Semantic Addressing for Satellite Constellation", Work in Progress, Internet-Draft, draft-lhan-satellite-semantic-addressing-03, , <https://datatracker.ietf.org/doc/html/draft-lhan-satellite-semantic-addressing-03>.
[KUIPER]
"Amazon receives FCC approval for project Kuiper satellite constellation.", <https://tinyurl.com/bs7syjnk>.
[Large-Scale-LEO-Network-Routing]
"Large Scale LEO Satellite Networks for the Future Internet: Challenges and Solutions to Addressing and Routing," Computer Networks and Communications, 1(1), 31-58", <https://ojs.wiserpub.com/index.php/CNC/article/view/2105>.
"Starlink", <https://en.wikipedia.org/wiki/Starlink>.
[ThreeGPP]
"3GPP", <https://www.3gpp.org/>.

Authors' Addresses

Dongxu Hou (editor)
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Xiao Min
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Fenlin Zhou
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China