Internet-Draft LISP-LEO April 2023
Pan, et al. Expires 15 October 2023 [Page]
Workgroup:
Internet Area Working Group
Internet-Draft:
draft-pan-intarea-lisp-leo-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Pan
BUPT
J. Hu
BUPT
Y. Chen
BUPT
X. Zhang
CURI
M. Gao
BUPT

Location/Identity Separation-based Mobility Management for LEO Satellite Networks

Abstract

In space-terrestrial integrated networks, the motion of LEO satellites relative to ground terminals is inevitable and can trigger the reassignment of terminal IP addresses, disrupting ongoing TCP connections. The traditional Mobile IP protocol solves this problem using a home agent and tunneling mechanism. However, for space-terrestrial integrated networks, Mobile IP is inefficient due to increased latency when registering with the remote home agent, high packet loss caused by large registration latency, and triangular routing to the remote home agent. To address these issues, this draft proposes LISP-LEO, a location/identity separation-based mobility management protocol for LEO satellite networks. Specifically, LISP-LEO divides the Earth's surface into partitions and maintains a partition-satellite mapping table in real-time based on the regularity of satellite motion. LISP-LEO always routes traffic to the satellite above the destined terminal by querying the partition-satellite mapping table, eliminating triangular routing and related performance overheads. Additionally, LISP-LEO proposes a last-hop relay to handle the corner case when multiple satellites occur above the destined terminal.

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 15 October 2023.

Table of Contents

1. Introduction

Satellite networks are recognized as a valuable complement to terrestrial networks due to their extensive coverage of the Earth's surface and their ability to overcome terrain limitations. Compared to MEO and GEO satellites, LEO satellites are smaller, less expensive, and closer to the ground, resulting in significantly lower space-ground transmission latency. Additionally, LEO satellite constellations feature high-density mesh topologies, which enable multi-path routing for traffic load balancing and link failure tolerance, even under extreme conditions. Given the commercial value of low latency and high reliability, as well as declining satellite launch costs, several companies have begun designing and launching mega-scale LEO satellite constellations into space. For instance, SpaceX's Starlink project aims to launch 12,000 LEO satellites and conduct inter-satellite routing to achieve global internet coverage [foust2018spacex].

Mobility management is one of the key challenges faced by LEO satellite networks. A typical LEO satellite constellation has an orbital altitude of less than 2000 km, resulting in a small Earth coverage area for a single satellite. In addition, the relative motion between LEO satellites and ground terminals occurs frequently, leading to short durations of Ground-to-Satellite Links (GSLs). Terminal-satellite handovers are inevitable during terminal-to-terminal communication via the LEO satellite network. However, at the network layer, such handovers result in the reassignment of the terminal IP address, which can disrupt running TCP connections since a TCP connection is established with a fixed pair of 5-tuple socket addresses. The disruption of TCP connections can further impact the carried services and end-user experiences.

Previous work on mobility management in LEO satellite networks has mainly focused on link-layer handover, which addresses the transfer of an ongoing link connection to a new spot beam or satellite [chowdhury2006handover], [papapetrou2004satellite]. In contrast, network-layer mobility management has received relatively little attention. Some existing solutions borrow ideas from mobility management protocols used in terrestrial networks and apply them to LEO satellite networks [sarikaya2001supporting], [darwish2021location]. For instance, Mobile IP [RFC3344] proposes two IP addresses to identify a mobile terminal and its location: the Home Address (HoA), which is a unique identifier of the mobile terminal and remains constant, and the Care-of Address (CoA), which specifies the current location of the mobile terminal in the network. In the initial stage, the home agent of a mobile terminal is the satellite above the mobile terminal. Upon a satellite handover, the mobile terminal obtains a new CoA from the new satellite (the foreign agent) and sends a binding update to the home agent. Through the binding update operation, the HoA can be associated with the CoA at the home agent to maintain communication continuity after handover. The home agent sends packets destined for the mobile terminal through a tunnel to the CoA, and upon arrival at the end of the tunnel, each packet is delivered to the mobile terminal.

However, the distance between the home agent and the mobile terminal in LEO satellite networks varies constantly due to satellite motion. As a result, the time required for registration with the home agent can sometimes be quite long, leading to high registration latency. This can cause severe packet loss since packets destined for the terminal's original CoA may be lost during registration. Additionally, the use of Mobile IP in LEO satellite networks results in the so-called triangular routing problem [sanguankotchakorn2008effect]. When a source terminal sends traffic to the mobile terminal, packets must first travel to the home agent, which then encapsulates the packets and tunnels them to the foreign agent. Finally, the foreign agent decapsulates these packets and delivers them to the mobile terminal. This packet route is inefficient, and in the worst-case scenario, when the mobile terminal is near the source terminal while its home agent is on the opposite side of the Earth, the packets destined for the mobile terminal may have to traverse the Earth twice.

To overcome the limitations of Mobile IP in LEO satellite networks, we propose LISP-LEO, a novel network-layer mobility management protocol based on location/identity separation. In our design, we divide the Earth's surface into multiple partitions and establish a dynamic partition-satellite mapping table. Each partition is assigned a service satellite that manages the mobility of terminals within that partition. We introduce a new IP addressing method based on location/identity separation, in which the terminal's address contains two parts: the Partition Identifier (PID) and the Identity Identifier (IID). The PID indicates the partition where the terminal is located, and the IID indicates its identity. With this method, the terminal's address remains unchanged during satellite handovers. To avoid the triangular routing problem, we always route traffic to the satellite above the partition where the destination terminal is located (its service satellite). We do this by querying the partition-satellite mapping table using the PID part of the destination IP address. We encapsulate the packets with the source and destination satellite identifiers and tunnel them to the service satellite. In the corner case where the terminal's service satellite is different from its access satellite, the service satellite will relay the packets to the access satellite, which will finally deliver them to the terminal. In LISP-LEO, the service satellite plays a similar role as the home agent in Mobile IP, but it is always close to the mobile terminal, avoiding the triangular routing problem.

Our major contributions are summarized as follows:

2. Terminology

This document uses the following terms.

3. Location/Identity Separation-based Protocol

LISP-LEO is an advanced mobility management protocol, and we provide a detailed description of its technical operations. First, we divide the Earth's surface into partitions and create a one-to-one mapping between partitions and satellites. Then, we design a location/identity separation-based addressing method for each mobile terminal on the ground to keep its IP address unchanged during satellite handover. Additionally, to ensure that a mobile terminal is aware of its access satellite, each satellite broadcasts its presence to the ground. After receiving the broadcast signals and updating its access satellite, the terminal registers with its service satellite. Finally, we examine the end-to-end packet transmission process between two mobile terminals, covering techniques such as tunneling and last-hop relay.

3.1. Partition Design

A typical M × N LEO satellite constellation consists of M orbital planes with N satellites in each plane. Each satellite in the constellation operates in tandem to provide global coverage of the Earth's surface. Due to the circular coverage area of each satellite, the coverage areas of adjacent satellites may overlap, potentially allowing a mobile terminal to be within the coverage area of one or more satellites simultaneously.

According to the number of satellites in the LEO satellite constellation and the coverage area of a satellite, we divide the Earth's surface into multiple partitions. For simplicity, we use a uniform division by latitude and longitude, resulting in the same number of partitions as the number of satellites. The size of each partition is slightly smaller than the coverage area of a single satellite. For a typical M × N constellation, the division results in M × N partitions, each spanning 360/N degrees of latitude and 360/(2 × M) degrees of longitude.

In our design, we assign each partition a unique PID as its identity. For example, in a 6 × 8 LEO constellation, the Earth's surface is divided into 48 partitions, each assigned a PID ranging from 1 to 48 as shown in Figure 1. Also, using the latitude and longitude range of a partition, we can easily find its center. To implement our protocol, all satellites and mobile terminals on the ground need to store information about each partition, including its PID and center.

+----+----+----+----+----+----+----+----+----+----+----+----+
| 02 | 10 | 18 | 26 | 34 | 42 | 03 | 11 | 19 | 27 | 35 | 43 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 01 | 09 | 17 | 25 | 33 | 41 | 04 | 12 | 20 | 28 | 36 | 44 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 08 | 16 | 24 | 32 | 40 | 48 | 05 | 13 | 21 | 29 | 37 | 45 |
+----+----+----+----+----+----+----+----+----+----+----+----+
| 07 | 15 | 23 | 31 | 39 | 47 | 06 | 14 | 22 | 30 | 38 | 46 |
+----+----+----+----+----+----+----+----+----+----+----+----+
Figure 1: The partition design of a 6 x 8 LEO constellation.

3.2. Partition-Satellite Mapping Table

Similar to partitions, each satellite is assigned a unique SID as its identity. Then we establish a one-to-one mapping between partitions and satellites. Each partition corresponds to the satellite with the maximum elevation angle from its center. To keep track of this mapping, each satellite maintains a partition-satellite mapping table, which stores the relationship between partitions and satellites. Specifically, each entry in the mapping table contains a PID as the key and a SID as the value. For example, in Figure 2, partition n is associated with satellite Sj, which is recorded as an entry {n, Sj} in the partition-satellite mapping table.

+-------+-------+
|  PID  |  SID  |    O: satellite            *: mobile terminal
+-------+-------+
|   n   |   Sj  |
+-------+-------+               Packet Format
|  ...  |  ...  |           +-------------------+
+-------+-------+           |    Src SID: Si    |
  Mapping Table             +-------------------+
                            |    Dst SID: Sj    |
            ----------------+-------------------+----------------
        Si /                |  Src IP: m.a.b.c  |                \ Sj
          O  Tunnel Encap   +-------------------+   Tunnel Decap  O
          |                 |  Dst IP: n.x.y.z  |                 |
          |                 +-------------------+                 |
+-------------------+                                   +-------------------+
|  Src IP: m.a.b.c  |      Inter-Satellite Routing      |  Src IP: m.a.b.c  |
+-------------------+                                   +-------------------+
|  Dst IP: n.x.y.z  |                                   |  Dst IP: n.x.y.z  |
+-------------------+         Direction: h1->h2         +-------------------+
          |                                                       |
          |                                                       |
          *                                                       *
          h1                                                      h2
     Partition: m                                            Partition: n
     IP: m.a.b.c                                             IP: n.x.y.z
Figure 2: In LISP-LEO, the packets sent from the source terminal (h1) to the destination terminal (h2) will first query the partition-satellite mapping table in the satellite above the head (Si), using the PID (n) in the destination IP to obtain the corresponding SID (Sj), then encapsulated and tunneled via inter-satellite routing to the satellite (Sj) above the destination terminal (h2).

As satellites periodically fly over the Earth's surface, the mapping relationship keeps changing. Therefore, each satellite needs to update its mapping table according to the regularity of satellite motion. The update process is as follows:

  • First, each satellite obtains its location (its latitude and longitude information) via GPS. Then according to the real-time satellite location prediction approach [pan2019opspf], the satellite estimates the location of other satellites.
  • Second, the elevation angle between the center of each partition and each satellite is calculated separately. This calculation is based on the partition information that is pre-stored and the location information of each satellite obtained in the previous step.
  • Finally, the partition-satellite mapping table is updated with new information. Specifically, the mapping table is updated to associate each partition with the satellite that has the maximum elevation angle from the center of that partition.

3.3. Location/Identity Separation-based Addressing

Based on the above partition design, we introduce a new addressing method based on location/identity separation. The terminal's address is designed to consist of a PID and an IID:

IP Address = PID + IID.

In the new address, the PID indicates the terminal's location and represents the partition where the terminal is located; the IID is used to identify the terminal. As shown in Figure 2, terminal h1 is located in partition m and its address is m.a.b.c. Here, we follow the rule of the Class A IPv4 address (32-bit) [RFC0791]. The first 8 bits of the address are used for the PID and the remaining 24 bits represent the IID. Moreover, to avoid conflicting with others' IIDs when a mobile terminal moves into a neighbor partition, its IID should be globally unique.

Each mobile terminal obtains its address by calculating its PID and IID. The calculation rules are as follows:

  • PID: Each mobile terminal obtains its location via GPS and calculates the partition containing the location according to the pre-stored partition information.
  • IID: Each mobile terminal has been assigned a constant IID in advance which will not be changed.

According to the proposed addressing method, when a mobile terminal moves within a partition, its address will remain unchanged even if a satellite handover occurs. Moreover, the addressing method has good scalability. When the number of partitions increases in the future, we can further consider a support for longer-bit partition fields of IP addresses. And if we want to further support more mobile terminals in the LEO satellite network, we can even adopt the IPv6 address format (longer-bit, 128-bit) [RFC2460].

3.4. Satellite Broadcast

As described earlier, each mobile terminal on the ground is covered by at least one satellite to meet its communication requirements. When a mobile terminal moves into the overlapping coverage areas of multiple satellites, it is necessary to select a suitable access satellite as its current point of attachment to the LEO satellite network. To achieve this, we design a satellite broadcast mechanism. Each satellite periodically broadcasts within its coverage area to advertise its service. Each broadcast message contains information about the corresponding satellite, such as its SID and location.

Each mobile terminal determines its access satellite relying on the broadcasts it receives. To have the best signal transmission quality, the terminal selects the satellite with the maximum elevation angle (the nearest) as its access satellite [papapetrou2004satellite]. Specifically, after receiving satellite broadcasts from multiple satellites, the terminal obtains the location of these satellites. Then combined with the terminal's location obtained from GPS, the terminal calculates the satellite with the maximum elevation angle, which is chosen as the terminal's access satellite.

3.5. Terminal Registration with the Service Satellite

Based on the mapping relationship depicted in Section 3.2, the satellite associated with a partition is designated as the service satellite for mobile terminals within that partition. In our protocol, the service satellite is considered to be crucial and plays a similar role to the home agent in Mobile IP. And we design a registration mechanism to maintain mobility bindings at the service satellite. Specifically, each mobile terminal must register with its service satellite after updating its access satellite. This registration process creates or modifies a mobility binding at the service satellite that associates the terminal's address with the SID of its access satellite.

As previously mentioned, the coverage area of a satellite is slightly larger than the size of a partition. Additionally, the maximum elevation angle rule dictates that a mobile terminal's access satellite is closest to itself, while its service satellite is closest to the center of the partition where the terminal is located. As a result, a mobile terminal's service satellite is either the access satellite or one of the four adjacent satellites of the access satellite. To deal with both scenarios, our protocol defines two different registration procedures, one registering directly with the terminal's service satellite, and the other registering via a non-service satellite that relays the registration to the terminal's service satellite one-hop away. The following rules specify the different conditions to use the above two registration procedures:

  • Direct Registration: If a mobile terminal's access satellite happens to be its service satellite, the mobile terminal must register directly with its service satellite.
  • Indirect Registration: If a mobile terminal's access satellite is not its service satellite, the mobile terminal must register indirectly with its service satellite via its access satellite.

Both registration procedures involve the exchange of Registration Request and Registration Reply messages. As shown in Figure 3, when registering directly with the service satellite, the registration procedure only requires the following two messages:

  • (1) The mobile terminal sends a Registration Request to the service satellite.
  • (2) The service satellite responses a Registration Reply to the mobile terminal, granting the Request.
O: satellite
*: mobile terminal
                                  Si
          Satellite    +------------O------------+
                                    \#
                                     \\
                                    b \\
                                       \\ a
                                        \\
                                         #\
The Earth's Surface    +------------------*------+
                                           MT

      a. MT sends a Registration Request to Si
      b. Si sends a Registration Reply to MT

     Si is not only the MT's service satellite,
          but also its access satellite.
Figure 3: Registering directly with the service satellite.

As shown in Figure 4, when the mobile terminal registers indirectly with the service satellite via the access satellite instead, the registration procedure requires the following four messages:

  • (1) The mobile terminal sends a Registration Request to the access satellite to start the registration process.
  • (2) The access satellite processes the Registration Request and then relays it to the service satellite one-hop away.
  • (3) The service satellite sends a Registration Reply back to the access satellite to grant the Request.
  • (4) The access satellite processes the Registration Reply and then relays it to the mobile terminal to inform it of the disposition result of its Request.
O: satellite
*: mobile terminal

                                       b
                          Si       #---       Sj
          Satellite    +----O----------------O------+
                                   ---#    /#
                                  c       //
                                       d //
                                        // a
                                       //
                                      #/
The Earth's Surface    +-------------*--------------+
                                      MT

      a. MT sends a Registration Request to Sj
      b. Sj relays the Registration Request to Si
      c. Si sends a Registration Reply to Sj
      d. Sj relays the Registration Reply to MT

      Si is the MT's service satellite and Sj is
                its access satellite.
Figure 4: Registering indirectly with the service satellite.

To prevent registration failure caused by packet loss or other issues, a mobile terminal initiates a timer with a reasonable waiting time each time it sends a Registration Request. If no Registration Reply is received within the specified waiting time, the mobile terminal will resend a new Registration Request. The timer settings should take into account the round-trip time (RTT) of space-terrestrial communication as well as the message processing latency.

In the proposed registration mechanism, each mobile terminal will register with its service satellite when a satellite handover occurs. Due to the periodic movement of satellites over the Earth's surface, a mobile terminal's service and access satellites are constantly changing. However, a mobile terminal's service satellite is always either the access satellite or one of the access satellite's four neighbors. This ensures that the distance between the mobile terminal and its service satellite remains relatively stable during satellite motion. Consequently, the registration latency is also bounded within a stable range proportional to the distance between the mobile terminal and its service satellite.

Note that the satellite broadcast interval has an impact on the timeliness of registration when a satellite handover occurs. If the interval is too long, the mobile terminal may not receive the broadcasts to update its access satellite in time after handover, thereby delaying the registration with the service satellite. This will cause potential packet loss as packets may be routed to a new service satellite. Due to the lack of the latest registration information, the new service satellite does not know whether to route the packets to the mobile terminal or its access satellite, so it simply drops them. On the contrary, if these broadcasts can be triggered frequently (such as every 1ms), the mobile terminal can be sensitive to satellite handovers and complete registration quickly, at the cost of some message processing overhead.

3.6. End-to-End Transmission between Terminals

As shown in Section 3.2 and Section 3.3, each satellite in the LEO satellite network maintains a partition-satellite mapping table that provides a real-time mapping between each partition and the satellite closest to its center. In addition, the PID in the address of a mobile terminal indicates the partition where the terminal is located. Therefore, for communication between a source terminal (ST) and a destination terminal (DT), when a packet arrives at the ST's access satellite, we can identify the DT's service satellite by querying the mapping table using the PID in the destination address. Once we have determined the service satellite, we can use tunneling to route the packet between the ST's access satellite and the DT's service satellite. Specifically, the ST's access satellite encapsulates the original IP packet and tunnels it to the DT's service satellite, which is then responsible for delivering the packet to the DT.

Underneath the tunnel, each satellite functions as a router with its own routing table and forwards each packet based on its destination address. The satellite routing table is responsible for storing all routes to other satellites. Essentially, the inter-satellite network is the underlay network of the overlay tunnel between the ST and the DT. We use the SID of the ST's access satellite and the SID of the DT's service satellite as the source and destination addresses of the underlay routing for tunneling the original IP packet. This ensures that the inter-satellite network can be entirely independent from the ground network, allowing us to use any inter-satellite routing protocol, such as OPSPF [pan2019opspf], to calculate the satellite routing table. During inter-satellite routing, after each satellite receives an incoming packet, it will look up its routing table based on the destination SID in the outer packet header, determine the next hop and forward the packet.

Based on the above discussion, we describe the packet transmission process between terminals in detail:

  • (1) The ST sends an IP packet to its access satellite to start the packet transmission procedure.
  • (2) The ST's access satellite queries the local partition-satellite mapping table, encapsulates the packet, and then forwards it to the DT's service satellite.
  • (3) The DT's service satellite queries the registration information (the bindings between the terminals' addresses and the SIDs of their access satellites) and forwards the packet to the DT directly or indirectly.

There are two scenarios in which the DT's service satellite forwards traffic to the DT. Upon receiving a packet, the service satellite queries the registered bindings to obtain the corresponding SID according to the DT's address in the inner packet header. Then, the service satellite compares the obtained SID with its own SID, and there are two results. One is that the service satellite is the DT's access satellite, as shown in Figure 2. In this case, the service satellite directly decapsulates the packet and forwards it to the DT through its interface towards the ground. The other is that the DT's service satellite is not its access satellite, which requires an additional one-hop relay, as shown in Figure 5. Specifically, the service satellite needs to relay the packet to the access satellite first. To achieve this, the service satellite modifies the destination SID in the outer packet header to the obtained SID (the access satellite's SID) and the source SID in the outer packet header to its own SID. After receiving the packet, the DT's access satellite decapsulates and forwards the packet to the DT.

O: satellite
ST: source terminal
DT: destination terminal

                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 Sm        Sn    b    XX                           XX        Si    c   Sj
  O         O--------XX   Inter-Satellite Routing   XX-------#O--------#O
           #          XX                           XX                  /
          /            XXXXXXXXXXXXXXXXXXXXXXXXXXXXX                  /
       a /                                                           / d
        /                                                           /
       /                                                           #
      ST                                                          DT

  a. ST sends an IP packet to Sn         b. Sn forwards the packet to Si
  c. Si relays the packet to Sj          d. Sj forwards the packet to DT

Sm is the ST's service satellite and Sn is its access satellite. Si is the
         DT's service satellite and Sj is its access satellite.
Figure 5: Packet transmission between terminals (including last-hop relay).

To summarize, in LISP-LEO, the traffic from the ST is first forwarded to the DT's service satellite. If the DT's service satellite is not its access satellite, the service satellite needs to further deliver the traffic to the access satellite. As described above, if the DT's service and access satellites are the same, there is no triangular routing. Otherwise, the route taken by the traffic destined for the DT can still be triangular. However, in this case, the DT's service and access satellites are only one-hop away from each other. So after arriving at the service satellite, the traffic destined for the DT only needs an additional one-hop relay to reach the access satellite, which finally forwards the traffic to the DT. Consequently, in both cases, LISP-LEO can well address the triangular routing problem in Mobile IP.

4. Known Open Issues and Areas of Future Work

Based on the above description, this protocol is effective in situations where mobile terminals always move within their partitions. However, there is still a chance that a mobile terminal moves into a neighboring partition during communication, even if a single partition is designed to be large enough. As illustrated in Section 3.3, the PID in the terminal's address indicates the current partition where the terminal is located. So the terminal's address needs to be updated. Otherwise, the packets destined for the terminal will be sent to the satellite above the old partition by querying the partition-satellite mapping table, affecting the accuracy of packet delivery. However, updating the address during the communication process will interrupt the running TCP connections and affect the communication quality. Although this document does not provide a specific solution, we will explore potential options. One preliminary idea is to allow each mobile terminal to detect whether its IP address has changed. Once there is a change, the terminal will send an address notification message to the peer to notify the changed IP address. After the peer receives the message, a new TCP connection will be established to maintain the previous communication.

5. Security Consideration

This present memo does not find any security problem.

6. IANA Consideration

This document has no IANA actions.

7. References

7.1. Normative References

[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/info/rfc791>.
[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, , <https://www.rfc-editor.org/info/rfc2460>.
[RFC3344]
Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, DOI 10.17487/RFC3344, , <https://www.rfc-editor.org/info/rfc3344>.

7.2. Informative References

[chowdhury2006handover]
Chowdhury, P.K., Atiquzzaman, M., and W. Ivancic, "Handover schemes in satellite networks: State-of-the-art and future research directions", .
[darwish2021location]
Darwish, T., Kurt, G., and H. Yanikomeroglu, "Location management in IP-based future LEO satellite networks: A review", .
[foust2018spacex]
Foust, J., "Spacex's space-internet woes: despite technical glitches, the company plans to launch the first of nearly 12,000 satellites in 2019", .
[pan2019opspf]
Pan, T., Huang, T., and X. Li, "OPSPF: Orbit Prediction Shortest Path First Routing for Resilient LEO Satellite Networks", .
[papapetrou2004satellite]
Papapetrou, E., Karapantazis, S., and G. Dimitriadis, "Satellite handover techniques for LEO networks", .
[sanguankotchakorn2008effect]
Sanguankotchakorn, T. and P. Jaiton, "Effect of triangular routing in mixed IPv4/IPv6 networks", .
[sarikaya2001supporting]
Sarikaya, B. and M. Tasaki, "Supporting node mobility using mobile IPv6 in a LEO-satellite network", .

Authors' Addresses

Tian Pan
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Jun Hu
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Yujie Chen
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China
Xuebei Zhang
China Unicom Research Institute
No. 33 Erlong Road, Xicheng District
Beijing
100048
China
Minglan Gao
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road, Haidian District
Beijing
100876
China