With the emergence of the ioe paradigm, which involves people, data, intelligent processes, sensors, and devices , wireless communication networks are going through an unprecedented revolution to meet the requirements of ioe global deployment. It is anticipated that future networks will have to ensure the provision of communications and computation services, and security for a tremendous number of devices with very broad and demanding requirements in a ubiquitous manner. This fuels the need for providing broadband Internet connectivity everywhere on Earth and even within its surrounding space. Although terrestrial communication networks have witnessed several significant advances, the coverage of communication networks is still patchy, particularly in rural and difficult-to-serve areas (e.g., seas, oceans, polar regions, and high altitudes in the sky). During the COVID-19 pandemic, many people/companies realized that work can be done remotely and it is not necessary to go to working places. This might encourage many people to leave the big cities and move to live in more relaxing and less expensive areas (e.g., rural areas), even after the pandemic is over. In this situation, there will be new population distribution which requires the provision of the Internet in more scattered spots. Besides providing coverage to rural and difficult-to-serve areas, the large footprint of satellite networks can boost the communication capacity for a huge number of terrestrial users on a flexible basis. This makes satellites ideal for providing broadcasting or multicasting services. In addition, satellite networks can offer critical and emergency services during and after natural disasters.
Recently several industrial groups and standardization organizations, including the 3gpp, are proposing the integration of satellite networks with 5G and beyond to support seamless and broadband coverage everywhere, for everything, at any time . Driven by the growing demands for Internet and communication, satellite networks have developed fast during the last 10 years , especially for the low Earth orbit (LEO) satellite networks (SatNets) such as the Iridium NEXT system and the upcoming SpaceX mega-constellations. The objective is to cover the entire Earth with LEO satellites equipped with obp devices. Such SatNets can be considered as an extension of the terrestrial IP network or as a standalone satellite network where satellites are the data sources, processors, and consumers .
Due to their low altitudes (160-2000 km), LEO satellites provide low-latency communications in comparison to meo and geo satellites. However, the fast movement on the low Earth orbits comes with the price of the very frequent handovers/disconnections in communications with ground stations and users, aerial network entities, and other LEO satellites . For example, a LEO satellite at 500 km altitude travels at 7.6 km/s and it takes around 95 minutes to orbit the Earth resulting in a handover every 5 minutes approximately. Therefore, there is a pressing need for efficient mobility management protocols to provide seamless communication between the Internet and satellite networks .
ietf introduced the mip protocol (i.e., mipv4 and mipv6) and pmipv6 protocol to provide mobility management in the terrestrial IP networks. IETF’s IP-based mobility management protocols aim at maintaining the tcp connection between a mn and a static ap or bs while reducing the effects of location changes of the MN. This is achieved through the mobility management interrelated components, handover management and location management. Handover management is the process by which a MN keeps its connection active while moving from one AP to another. Location management has two components, location update which is the process of identifying and updating the logical location of the MN in the network, and the second component is data delivery (i.e., routing) which forwards the data packets directed to the MN to its new location. This study focuses on the location management side with its two components, location updates (binding updates) and data delivery (routing), as described in Figure 1.
Due to the differences between terrestrial networks and SatNets in terms of topology, processing power, and communication links, the application of standard IP mobility management protocols, and more specifically their location management techniques, to satellite network has some drawbacks . IETF’s IP-based location management techniques were designed to manage the logical location of MNs (terminals) and deliver their data to wherever they move. However, in LEO SatNets both terminals and BS (satellites) are moving, which creates new challenges that cannot be fully addressed using existing IETF’s location management techniques. In addition, IETF location management techniques are intended to work in centralized units that manage both control and data traffic (i.e., routing) . As a result, IETF location management techniques have poor scalability and may create processing overload in core network devices. Moreover, even in terrestrial networks, such standards posed several problems because of their low granularity mobility management and suboptimized routing. What makes things more challenging is the characteristics of future LEO SatNets, such as the very frequent and rapid topology changes due to the fast LEO satellites speed, the very dense deployment of LEO satellites in the form of a network of mega-constellations, and the complete integration with aerial, terrestrial, and even deep space networks. In addition, future LEO SatNets will be utilized in highly populated areas where thousands or millions of heterogeneous user devices can communicate directly with the LEO satellite (without going through a gateway). Hence, future LEO SatNets will create unprecedented mobility scenarios that require innovative solutions.
To overcome the limitations of IETF IP-based location management, one of three approaches was followed by the existing studies on LEO SatNets location management. The first approach attempted to enhance or extend the IETF IP-based location management techniques [86, 17]. The second approach is based on the split of the two roles of IP addresses (i.e., locator/identifier split) [23, 22]. The third approach focuses on utilizing sdn for the purpose of topology (location) management [81, 80]. However, the existing studies are not considering the unique characteristics of future LEO SatNets, and the adoption of the existing solutions -as they are- will not be adequate. By pointing out the advantages that existing studies have and what is required for future LEO SatNets, this study aims to shape the future of the needed and foreseen location management.
I-a Existing Surveys and Tutorials
A number of excellent surveys and tutorials related to mobility management were published over the past several years, involving discussions on the IETF’s mobility management protocols and their proposed enhancements, reviews on the available location/identifier split architectures and mapping systems, and various surveys on the exploitation of software defined networks concepts for mobility management purposes.
A comprehensive tutorial on mobility management in data networks was introduced in . In , the authors discussed the suitability of the existing mobility management solutions introduced by the standardization bodies (e.g., IEEE, IETF, 3gpp, and ITU) to be applied to 5G and beyond networks.  introduced a review on the architectures, design, benefits, and potential drawbacks of the hip which is an inter-networking architecture and an associated set of protocols, developed at the IETF. The mobility management services in mobile networks were surveyed in . For networks with self-organizing and self-configuring characteristics, the applicability of IETF mobility management protocols was discussed in . Several algorithms, developed to address the challenges of IP-based mobility management in the iot environment, were reviewed in .
A detailed discussion of the limitations of the IP addressing architecture and the existing enhancements based on location/identifier split architectures were presented in . In , the authors introduced a comprehensive survey on location/identifier split network architectures and their characteristics. As an essential component in location/identifier split solutions,  provided a survey on several mapping systems.
SDN is considered a promising approach to manage mobility. The author in , discussed the challenges faced when SDN is utilized to manage mobility in IP-based networks.
Mobility management is a quite mature research topic in communication networks, however, this is not the case for the next generation of satellite networks. Many recent surveys and tutorial on future SatNets focused on discussing communication and networking related issues. For example, Radhakrishnan et al.  focused on inter-satellite communications in small satellite constellations from the perspectives of physical to network layers, and the Internet of remote things applications of satellite communication were reviewed in . However, only a few reviews were published on the mobility management related issues in next generation satellite networks. The author in  discussed the challenges facing SDN-based integrated satellite-terrestrial networks. Another review , explored the challenges that software-defined next generation satellite networks may encounter and provided some potential solutions.  discussed the survivability and scalability of space networks. The aforementioned surveys with regards to mobility management are summarized at a glance in Table III to allow the reader to capture the focal point of each of the existing surveys.
The discussion throughout this section reveals that mobility management in future SatNets is still in its infancy phase. Although some very few reviews discussed the integration of SDN and future SatNets, mobility management issues, and more specifically location management, were not the focus of such papers. Therefore, this review paper aims to discuss the existing location management solutions and the challenges facing their applicability in future LEO SatNets.
|2010||||An in-depth look at the architecture, design, benefits, and potential drawbacks of the HIP.|
|2012||||A survey of the mobility management services and their techniques, strategies and protocols.|
|2012||||Discusses some future network architectures in terms of their support for IETF mobility management protocols, including architectures of wireless mesh networks with self organizing and self configuring network characteristics.|
|2013||||A survey of mapping systems used in location/identifier split proposals|
|2014||||A comprehensive tutorial on mobility management in data networks.|
|2014||||Discusses the limitations of the IP addressing architecture and reviews the existing enhancement proposals based on location/identifier split architectures.|
|2016||||A review of the developed algorithms to address the challenges of integrating IoT and IP, the attributes of IP mobility management protocols and their enhancements.|
|2016||||A survey of the recent research works related to the software defined integrated satellite and terrestrial networks with challenge identification and a discussion of the emerging topics requiring further research.|
|2017||||A review of the studies on IP mobility management using software defined networking.|
|2017||||A comprehensive survey on location/identifier split network architectures and their mechanisms, and characteristics.|
|2018||||An architecture of software-defined next-generation satellite networks with the exploitation of network function virtualization, network virtualization, and software-defined radio concepts.|
|2018||||A survey on survivability and scalability of space networks with a discussion on IP mobility management applicability|
|2020||||A review of the 5G and beyond mobility management functional requirements with a discussion on whether the existing mechanisms introduced by standardization bodies (e.g., IEEE, IETF, 3gpp, and ITU) meet these requirements.|
I-B Paper Contributions and Structure
The contributions of this paper are as follows:
We describe the future LEO SatNets mobility characteristics and its challenging features and highlight two unprecedented location management scenarios.
We give an overview of IETF’s location management techniques and their limitations in the context of future LEO SatNets.
We comprehensively and critically review the existing solutions for location management in LEO SatNets, which are categorized into three approaches.
For each of the reviewed approaches, we point out the “Issues to consider” which are important points that should be considered in future LEO SatNets location management.
We summarize the current view of LEO SatNets location management and discuss the challenges of location management in future LEO SatNets.
Important future research directions are highlighted, including considering the relationship between orbit related parameters and location management, utilization of Blockchain technology, adoption of the collaborative Internet architecture, investigating the new IP address proposal.
Section II presents the future LEO SatNets envisioned mobility characteristics, identifies the challenging features of future LEO SatNets, and describes two unprecedented mobility scenarios. In Section III, we give an overview of IP-based standardized location management and its limitations in future LEO SatNets. Section IV introduces the taxonomy of the existing location management techniques for LEO SatNets. Section V reviews the existing studies that proposed extensions of IETF location management techniques for LEO SatNets. Section VI discusses the existing solutions that followed the locator/identifier split approach in LEO SatNets. Section VII investigates the SDN-based location management in LEO SatNets. At the end of Sections V, VI, and VII, an “Issues to consider” subsection is included, which highlights the main points that should be taken into consideration for future LEO SatNets location management. Section VIII highlights the advantages of existing solutions and discusses the challenges of the three location management approaches in future LEO SatNets. In Section IX, important future research directions are suggested, and our conclusions are presented in Section X.
Ii Mobility characteristics in future LEO SatNets
Satellite communication systems have been considered as a potential solution for complementing terrestrial networks by providing coverage in rural areas as well as offloading and balancing data traffic in densely populated areas . With the emergence of LEO satellite mega-constellations, which involve hundreds to thousands of satellites , the concept of satellite networks is evolving rapidly and gaining increased attention. It is expected that satellite networks will be an integral part of the future universal communication network, which is not only on Earth but also in its surrounding space and even extends to reach the Moon and other planets. 3gpp introduced a number of satellite use cases in 5G networks (3gpp TR 22.822 Release 16) which discuss the role of satellites in future networks . For example, 3gpp introduced Internet of Things with a Satellite Network and Global Satellite Overlay use cases that both emphasize the future role of satellite networks. However, to realize such use cases there are still several challenging matters to address. A major challenge that faces future satellite networks is mobility management. Therefore, in this section, after highlighting the challenging features of future LEO SatNets, we discuss two unprecedented mobility management scenarios in future satellite networks with a focus on location management.
Ii-a Challenging Features of Future LEO SatNets
There are some key points that should be kept in mind while designing, implementing, or evaluating location management solutions for future LEO SatNets:
A network of mega-constellations that have thousands of LEO satellites operated by different operators is expected. Therefore, it is essential to ensure interoperability between different constellations and also between the different operators. This necessitates the development of standards for future satellite network operation and management.
LEO satellites move at very high speed which results in frequent handovers.
Future LEO SatNets is not only to provide coverage for rural or remote areas but also to serve highly populated areas by boosting terrestrial network capacity and ensuring continuous coverage for fast-moving users (e.g., trains, planes, drones). Thus, thousands of users can be connected to a LEO satellite.
With the development of wireless communication technologies, not only large terminals but also small or handheld user devices for broadband communication will be able to communicate directly with satellites without the need for ground gateways. This will open the door of heterogeneity in terms of the used devices and their required qos.
Future LEO SatNets will be integrated with terrestrial, aerial, and maybe deep space networks. In terms of network management, such integration will result in more complexity and require high scalability.
A satellite will have multiple roles as it can work as a terminal, a router, and a BS.
Although deploying satellites at low/very low altitudes will require hundreds or thousands of satellites to provide continuous coverage all over the globe, a significant decrease in propagation delays can be achieved in comparison to legacy satellite communication. Nevertheless, the resulting delay and jitter are still considered non-negligible in certain delay-sensitive applications.
Deploying LEO satellites on low earth orbits will decrease the communication delay with terrestrial or aerial networks or users. However, the lower the orbit the more satellites are required to provide coverage, the faster the satellites should move, and the smaller the satellite footprint will be. Consequently, the frequency of handover will increase when orbit altitude decreases.
Ii-B Unprecedented Location Management Scenarios
In future broadband satellite networks, satellites will no longer be only used as a bent pipe. A satellite will be working as a mobile BS, a router, and a terminal. However, a LEO-based mobile BS moves very fast, which results in a high frequency of handovers and location updates triggers for both the satellite and its connected users. Moreover, future satellite networks will have thousands of LEO satellites, which require location management solutions with high scalability. Due to the LEO satellite connectivity and mobility characteristics, future LEO SatNets will introduce two unprecedented location management scenarios that require new solutions. The following two points elaborate on the two envisioned scenarios:
LEO satellite-based mobile BSs moving at high speeds and serving thousands of users’ devices: In future networks, it is expected that satellites, especially LEO satellites, will provide wide coverage and support the communication network capacity in densely populated areas, as shown in Figure 2. In this situation, a LEO satellite-based mobile BS will be serving thousands of users. This will be empowered by the integration of reconfigurable intelligent surfaces with LEO satellites as well . In this scenario, a wide range of user device types can be served through LEO satellites including smart devices, machines, sensors, autonomous vehicles, and cargo drones. The mobility of LEO at high speeds will result in triggering location updates not only to the satellite based mobile BS but also to the thousands of users that are connected to the LEO satellite. Although the users might not be moving, changing their network access point (i.e., the LEO satellite mobile BS) will trigger location updates in classical mobility management protocols (e.g., MIPv6). This is because, in IP networks, IP addresses are used for both routing and addressing purposes. Moreover, this unnecessary and massive number of location updates will be triggered every 5-10 minutes approximately.
A LEO satellite can be connected to two or more networks simultaneously (i.e., terrestrial, aerial, and space networks): In future integrated networks, besides being part of the network of satellite mega-constellations, LEO satellites will be also connected to terrestrial networks, aerial networks, or both, as shown in Figure 3. When a LEO satellite is connected to terrestrial and/or aerial networks, changes in satellite position will trigger location updates in both networks if each network has its own location management system. In addition, the topology changes in LEO satellite mega-constellations will also trigger frequent location updates among satellites. In this scenario, the LEO satellite can play the role of a mobile BS, a router, or a terminal. However, the most complicated case is when the LEO satellite is working as a mobile BS to serve a large number of users through multiple backhaul connections (space, aerial, terrestrial). Managing the location updates in several networks and providing a mapping between the location systems of such networks is considered a challenging issue.
Iii Overview of IP-based standardized location management and its limitations in future LEO SatNets
In traditional terrestrial cellular networks, mobility management is quite a mature topic. For location management, most of the research has focused on tracking and paging. The tracking area (location area) used in 4G and 5G usually comprises a dynamic group of cells. Location management solutions aim to find the balance among tracking area division and location updates/paging overhead. To communicate with other devices in a cellular network, the terminal device must establish an end-to-end user plane path through the domain of the mobile operator. To manage the location of an idle terminal, the terminal performs a location update upon crossing the boundaries of a tracking area. This location update is saved in a database that can be enquired to know the location of an idle terminal. To discover an idle terminal current location, the location area’s cells are contacted through paging. With the upcoming densification of 5G, it is expected to encounter a considerable increase in the location management signaling cost due to more location updates (if the tracking areas are small) or paging (if the tracking areas are large) .
In IP-based networks, location management is done in a slightly different way as the active TCP/IP connections of a mobile terminal need to be maintained while moving from one access router to another. In the 1970s, the IP protocol was introduced as an inter-networking protocol for delivering data packets in wired networks, where IP addresses play the double role of routing and addressing. With the development of mobile wireless communication devices, there was a real need to support mobility in IP-based networks. Therefore, IETF introduced MIPv4 and later followed by MIPv6, PMIPv6, fmipv6, and hmipv6. Mobility management, in these protocols, consists of two main components, which are handover management and location management. In this study, the focus is on the location management aspect of mobility management. Location management aims to locate the MNs and guarantee data delivery . The two procedures composing location management are binding updates and data delivery. To address mobility in Internet networks, the IETF mobile internet protocols bind the MNs to their corresponding new IP addresses as the MNs’ locations change. The binding update is executed only when a handover has occurred (i.e., when the MN changes its network access point). The following two subsections explore the fundamental procedure of location management in IPv6 mobility management standards and investigate the limitations of applying such standards in future LEO SatNets. Figures 4, 5, 6, and 7 describe the network architecture of each of the four IPv6 mobility management standards, and summarize their location management procedures.
Iii-a Location Management Procedure in IPv6 Mobility Management Standards
In the home network a MN gets a permanent address, called the home address. This address is registered at the ha in the home network and is used for both identification and routing purposes. Figure 4, shows the network architecture and the location management message exchange of MIPv6. Since MIPv6 is a host-based mobility management protocol, the MN detects its mobility from the home network (previous network) to a foreign network by using the IPv6 neighbour discovery mechanism. When the MN moves out of the home network and accesses a foreign network, it will perform the following steps :
The IPv6 neighbor discovery or address auto-configuration mechanism is used to obtain a temporary IP address from the foreign network, called the coa.
The MN informs the HA of its current location by sending a bu message and the HA responds with a ba to the MN.
After completing the binding update with the HA, the HA and the ar at the foreign network (i.e., far) will establish a bidirectional tunnel to deliver the data packets between the cn and MN. In this case, the data packets have to traverse the HA, which is not necessarily the optimum route .
The MN has the option to optimize the data forwarding route by sending BU message to the CN as well. Nevertheless, the MN will keep receiving packets through the HA until the CN starts using the CoA address.
Before using the CoA, the CN will send two test messages to both the HA and MN. The HA has to forward the message to the MN then the MN has to respond to both messages through the two different paths. When the CN receives both responses it can start using the CoA, then the communication between CN and MN can be through the FAR without going through the HA.
In MIPv6, the handover and the location management processes are closely coupled, and every handover results in updating the CoA at HA and CN (for route optimization). This leads to a high handover delay and increases packet loss rate. Therefore, some improved protocols, such as FMIPv6 , HMIPv6  and PMIPv6 , have been proposed.
To reduce packet loss and handover latency, IETF proposed FMIPv6, which enables the MN to configure a CoA before moving to the new AR (i.e., FAR) coverage . FMIPv6 protocol allows a MN to request information about neighbouring ARs. There are two modes of FMIPv6, namely Predictive and Reactive handover . Figure 5 shows an example of FMIPv6 handover, where the MN location is updated through the following steps:
The MN sends a rs to the par requesting information for a potential handover.
PAR replies with a pradv containing information about neighbouring ARs.
After receiving PRAdv, the MN configures a CoA and sends a fbu to FAR to bind the MN’s home address to the CoA in order to tunnel the arriving packets to the new location of the MN. PAR sends an acknowledgement to the MN confirming that the tunnel is ready.
The MN will send a fna as soon as it gets connected to FAR. This message confirms the use of the CoA.
However, if the MN could not anticipate the handover, then the reactive mode will be used. In this case, the MN will configure its CoA after moving to FAR coverage and the FBU is sent to PAR through FAR and is encapsulated in a FNA message. Then, the two routers PAR and FAR will exchange a handover initiation/handover acknowledgement messages to establish the tunnel then PAR starts forwarding packets to FAR to be delivered to the MN.
HMIPv6 is an enhancement of Mobile IPv6 with the feature of localized mobility management for MNs . To support localized mobility management, it introduces a new network entity called the map. In HMIPv6 a MN has two types of addresses; a regional rcoa and an lcoa. The RCoA is a global address and specifies a particular domain of the Internet. LCoA is a local address within the domain. When the MN moves between local networks inside a MAP domain (micro/intra-domain handover), it changes and updates its LCoA only at the MAP. However, moving from one MAP domain to a new MAP domain (macro/inter-domain handover), the MN has to change both addresses by registering a new local LCoA and a new RCoA at the new MAP. In this case, the new MAP registers the new RCoA to the MN’s HA. Figure 6 shows the network architecture of HMIPv6 and an example of a MN moving from MAP1 domain to the MAP2 domain :
The MN sends a request control message to MAP1 to create a multicast group for the MN.
MAP1 creates a multicast group by sending a multicast group join request to all neighboring ARs. Then, the neighboring ARs respond to MAP1 to show their availability to receive multicast data packets.
During the handover process, any received data packet from the CN is tunneled through MAP1 to all the available ARs, where it is buffered.
When the MN travels from MAP1 domain to MAP2 domain, it acquires new addresses (i.e., new RCoA, new LCoA) from the MAP2 network.
The MN sends a BU to MAP2 through AR3 and sends a message requesting AR3 to forward a multicast message. AR3 receives the request message, and subsequently forwards the buffered packets to the MN.
MAP2 receives the BU message and performs dad. MAP2 sends a BU to the MN’s HA after receiving the DAD and waits for a BA from the HA. After receiving a BA from HA, MAP2 sends a BA to the MN.
After receiving a BA, the MN sends a BU to the CN via MAP2 to change the destination address to the new RCoA. Then, data packets will be delivered to the MN through MAP2.
To provide a mobility management solution with reduced signaling and delay to support a MN moving within an IPv6 domain, the IETF introduced PMIPv6. As a network-based mobility management protocol, PMIPv6 introduces two new network entities, mag and lma . A LMA is connected to multiple MAGs and in one PMIPv6 domain, there can be multiple LMAs managing the mobility of a different group of MNs. When the MN is moving within a PMIPv6 domain, the MAG performs the signaling interaction with the LMA on behalf of the MN to ensure session continuity . When a MN joins the network, it will send a RS to the reachable MAG. Then the MAG sends a pbu to its LMA. The LMA responds with a pba which includes the MN’s home network prefix, creates a bce, and establishes a bidirectional tunnel with the MAG. The MN will use the home network prefix to configure its address using either stateless or stateful address configuration. When the MN is moving from the coverage of one MAG to another within the same PMIPv6 domain, as described in Figure 7, only a local update of location is required and data flow can directly be adjusted at LMA based on the following steps :
MAG1 detects that the MN is moving away from its coverage area and sends a PBU to the LMA.
The LMA responds with a PBA message to MAG1.
MAG2 detects the attachment of the MN and sends a PBU to the LMA.
The LMA responds with PBA message to MAG2 and switches the bidirectional tunnel from MAG1 to MAG2.
The MN keeps using the same IP address as long as it is moving between MAGs belong to the same PMIPv6 domain.
In case the MN moves outside the PMIPv6 domain, then the location management procedure of MIPv6 needs to be executed and the home network LMA will play the role of a HA.
Iii-B Limitations of IPv6 Location Management Standards
Location management goal is to locate mobile nodes and guarantee their data delivery while moving from one access point/network to another. The two phases of location management are binding updates and data delivery . One major problem that faces the location management techniques of IETF mobility management standards is the scalability issue. This is because the IETF’s mobility management standards depend on the availability of fixed anchor nodes that manage MNs mobility in a centralized manner. Unlike terrestrial networks that are geographically bounded, future SatNets will have a global scale which makes the adoption of the IETF’s mobility management standards infeasible. Moreover, in all IP-based location management protocols, data packets routing go through the location management anchor thereby producing the non-optimal routing path . This non-optimal data routing is unacceptable in future LEO SatNets as it will consume link resources and increase delivery delays. The following paragraphs discuss the drawbacks of applying each of the main IP mobility management protocols (i.e., MIPv6, PMIPv6, HMIPv6, and FMIPv6) in future LEO SatNets with a focus on the protocols’ location management aspect.
Both MIPv4 and MIPv6 protocols have been designed to manage mobility in Internet networks by binding the mobile user to its corresponding new address as its location changes. However, implementing MIPv6 in future LEO SatNets will face the challenge of satellites’ high mobility that will generate a large number of binding update requests from both LEO satellites and their connected end-users, which consume a massive amount of network resources. In MIPv6 (as in MIPv4), data packets transmission is disrupted during the handover period (i.e., handover latency). This latency comprises the required time to detect the movement, configure a new address, and to update the MN location . Packets sent to the MN during the handover period might be lost. In future LEO SatNets, depending on the received signal strength to detect mobility might be inaccurate because of the signal fluctuation, which may result in unnecessary address configuration and location update requests. The effect of atmospheric disturbances (e.g., rain) on the received signal strength should be taken in consideration. In addition, the propagation delay will prolong the time of the new address configuration and location updates especially if the mobility control entity is located on Earth. Although MIPv6 introduced the routing optimization to avoid keep sending the data packets through the HA, the non-optimal routing still cannot be neglected at the initial stage. This may require the data packets to go through the HA, which can be a ground gateway, and then be sent to the destination satellite. With the long propagation delay of the gsl, sending data packets down to Earth and then up to satellites might create serious packet delivery delays and increase the load on GSLs. This issue gets even worse when the HA is located far away from the current location of the satellite. .
Under the FMIPv6 framework, the next access point is predicted and the address configuration of the MN can be done prior to handover to reduce the handover delay . However, FMIPv6 introduces some interactive signaling messages between the current and the new access routers and also requires the establishment of a tunnel between the two routers. Although FMIPv6 with buffering and forwarding mechanisms outperforms MIPv6 in reducing handover latency and packet loss, this comes with a cost. Basically, the forwarding tunnel between the current and new access routers is established prior to handover, and the sent data from CN to MN is forwarded through the current router to the new one . In future LEO SatNets, if satellites are playing the role of access routers, then creating a forwarding tunnel will consume bandwidth resources of isl and satellite buffering capacity. In addition, as FMIPv6 depends on predicting the handover target (next access router), inaccurate predictions will waste network resources. In the presence of multiple mega-constellations, the user will have multiple potential satellites as a handover target, which makes predicting the handover target accurately a challenging task.
The HMIPv6 protocol adds a MAP to the network to handle local handover, which decreases the required mobility management signaling and reduces the handover delay of location updates . However, the large scale movement of a LEO satellite is considered as global mobility that cannot take advantage of HMIPv6. Thus, with the large scale of future LEO SatNets, HMIPv6 will be performing inter-MAPs handovers which generates a high number of control messages for location management and prolongs latency.
In PMIPv6 the network performs the mobility management process on behalf of the MN, which reduces the signaling interaction between the MN and the network access point . In , the author compared the performance of MIPv6 and PMIPv6 in a simple LEO constellation and the results showed reduced handover latency with the implementation of PMIPv6. However, the application of PMIPv6 in future LEO SatNets may face several drawbacks, such as the high load on LMA, the long handover delay due to the signaling that needs to pass the MAG and LMA which one of them might be located on the ground. In PMIPv6, LMA manages not only the mobility of the MN but also handles its related data traffic . In future LEO SatNets, if a terrestrial gateway is the candidate LMA, directly applying PMIPv6 can cause non-optimal routing. This is because packets cannot be routed among satellites of different domains instead packets would make a round trip through GSLs which is unnecessary . PMIPv6 can provide good mobility support for receivers during an IP multicast session . However, when the source node is mobile (i.e., LEO satellite) in a PMIPv6 based multicast session, all the receivers need to resubscribe every time the source node changes its network access point or location.
Iv Taxonomy of location management approaches in IP-based LEO SatNets
The existing research about location management in LEO SatNets can be divided into three approaches, as described in Figure 8:
Extensions of IETF location management techniques for LEO SatNets: As described in Section III, mobility management in IP-based networks consists of handover management and location management. The IETF IPv6 mobility management standards (e.g., MIPv6, PMIPv6, FMIPv6, HMIPv6) addressed the location management issue in terrestrial networks. Although some research attempted to employ the location management techniques of IPv6 mobility management standards , , , such techniques have many limitations when applied to satellite networks. To enhance the performance of the IETF location management techniques, a number of extensions were proposed for satellite network location management, which are discussed in Section V. This solution’s approach consists of two categories where the location management is done in either a distributed or centralized manner. The distributed IETF location management techniques’ extensions can be either anchor-based or anchorless, as described in Figure 8.
Locator/identifier split in LEO SatNets: Since the IP dual-role (i.e., locator and identifier) is regarded as the main cause of inefficient location management. In terrestrial networks, many research works are investigating the separation of the locator and identifier roles of IP such as ilnp . Section VI, explores the existing work on locator/identifier split in LEO SatNets and discusses the applicability of such solutions in future LEO SatNets.
SDN-based location management in LEO SatNets: The SDN concept was introduced to add programmability and flexibility to network management . Since the centralized nature of SDN limits the network scalability, several works have integrated SDN with a dmm architecture to adapt to the large scale of LEO SatNets. Section VII, describes the existing studies that investigated the merging of SDN and DMM in LEO SatNets, and discusses the shortcomings of applying such solutions in future LEO SatNets location management.
The following three sections critically review and compare the existing studies under each approach and point out the important points that should be considered in the context of future LEO SatNets. In Section VIII, Table V compares the advantages and the challenges of the three approaches from the perspective of future LEO SatNets.
V Approach #1: Extensions of IETF location management techniques for LEO SatNets
To provide worldwide communication and Internet services, there is a need for the development of IP-based satellite networks which can be easily integrated into terrestrial and aerial IP networks. To provide continuous connection, one of the main issues in future IP-based LEO SatNets is mobility management, which is more complex than in terrestrial networks because of the reasons mentioned in section II. From the perspective of future LEO SatNets, this section explores and discusses the proposed enhancements of existing IP-based location management standards and their drawbacks. This section is concluded with an “Issues to Consider” subsection, which describes some critical points that should be taken into consideration while implementing or developing IP-based location management solutions for future LEO SatNets.
V-a Enhancements of Existing IP-based Location Management Techniques for LEO SatNets
SIGMA is a mobility management scheme where the MN can keep using its old IP address while obtaining the new IP address . Every time the MN obtains a new address, it updates the lm database and sets this new address as its primary address. To start a communication, the CN queries the LM with the MN’s identity, and the LM replies with the primary IP address of the MN. Then, the CN can initiate communication with the MN in its new location. When dealing with satellites, the scheme uses satellite predicted mobility to predict the time of setting the primary address to the new IP address and delete the old IP address. However, the scheme did not consider the extensive signalling resulting from frequent satellite handovers in future mega-constellations.
To decrease the location management cost, fixed Location Areas (LAs) can be chosen for location management in IP-based LEO SatNets. Fixed geographical location areas fulfill this requirement as it reduces the bending update frequency. However, when delivering data to a MN, huge and complex operations should be done by the network to determine to which satellites the MN is connected at that moment and to hide the effect of frequent satellite movement from the MN. A location management scheme based on dual las in an IP-based LEO SatNet is proposed . The scheme used two types of LAs, the fes LA and satellite LA. Every FES is connected to three LEO satellites. Initially, MNs report both the satellite LA and FES LA information to its HA. A binding update will not be triggered unless the MN moves out of the two LAs that were reported to the HA through the last binding update procedure. Although this scheme suppresses the binding update frequency, its loose location management necessitates the use of paging to locate MNs (to which one of the three satellites the MN is connected). To send a packet to an ideal MN, the packet is first routed to the MN’s HA. Then the data is routed to the FES. The FES sends a paging request to the satellite to which the MN has been registered (the last stored SAT ID). If the MN is still under the coverage area of that satellite, the packet will be delivered successfully. Otherwise, the FES predicts the satellite that covers the MN and sends the paging request to it. Clearly, this scheme is reducing the cost of binding updates while introducing the cost of paging and suboptimal data packet routing.
To overcome the scalability issue of the centralized IP-based location management solutions, some studies proposed distributed solutions that come with the benefits of the optimal or near-optimal routing path, workload distribution, improved handover performance with shorter packet delivery latency. There are two types of distributed location management, anchor-based and anchorless . In anchor-based location management, the responsibilities of location management are permanently assigned to certain network entities. In contrast, anchorless location management role is shifted from one network entity to another based on network topology changes.
In , the author presented an IP-based distributed location management scheme. The scheme is anchor-based as it depends on the availability of distributed gs that are able to communicate and collaborate to manage the locations of satellites and attached MNs. The GSs register the binding (location) information of MNs and satellites, and they also forward the data from and to the MN. When a CN needs to communicate with a MN, it will forward the data through a satellite to the GS, then the GS will forward the data through satellites to the MN’s corresponding GS. Thus, forwarding data packets has to go through GSLs which is considered a non-optimal route that consumes GSLs bandwidth and increases the packet delivery delay. Although, distributing location management tasks over GSs improves the system scalability, but it introduces a large amount of signaling overhead in the terrestrial network when binding updates are globally exchanged among GSs.
A virtual mobility management scheme called VMIPv6, which is an enhancement of MIPv6 protocol, is proposed in . VMIPv6 adopts the anchorless concept of location management and the distributed architecture introduced in the IETF’s DMM requirements document (RFC 7333) . To reduce the location management overhead and delay, the author created a vac to co-manage the mobility of users in the corresponding vad. The set of LEO satellites on top of one specific LA is called VAC. The whole coverage area of all satellites in a VAC is defined as VAD. With changes in topology, the VAC is reconstructed by adding the new satellites sliding into the LA and deleting the ones sliding out of the LA. The departing satellite relays the LA’s binding information to the new satellite. Every VAC has multiple local Mobile Agent Anchors (MAAs) and one hmaa. The maa and HMAA are on-board routers in LEO satellite and can provide location management and routing services for the registered MNs. The MAAs of a VAC can share the mobility information of the MNs and cooperatively manage their binding. The HMAA maintains the connection between VAC and HA, and the MN registers its HMAA’s subnet IP address at its HA. The local MAA is responsible for controlling the connection links between the MN and the VAC, and the MN binds its local MAA’s IP address to each MAA of its related VAC. Within a VAD each MN has a global care-of address and a local one. When satellite’s mobility forces the MN to switch its connection to a new satellite within the same VAD, then the MN only updates the binding information with the new MAA. Thus, only the local care-of address will change. If the HMAA of a MN slid out of the VAD or the MN moved to another VAD, then the global care-of address will change. In this case, the MN should re-choose a MAA in VAC as its new HMAA and send the binding update information to the HA/CN to inform its new global care-of address.
The author of  identifies two main drawbacks of placing the home agent entity in a ground station, which are: 1) ground stations are fixed and do not move with satellites, which makes it hard to communicate with the home agent when the satellite is not in line-of-sight; and 2) ground stations deployment is bounded by Earth geography. In addition, fixed home agents on satellites will require several hops to complete binding updates when the satellite is not in line-of-sight, which increases the update delay and consumes ISLs bandwidth. To overcome such problems,  proposes to use a flexible agent placed on LEO satellites, where the home agent functionality is relayed from one satellite to another (i.e., the satellite that is closer to the MN) in a flexible manner. Once the procedure of binding update at the correspondent node is finished, the functionality of the home agent will relay from the previous flexible agent to the current access satellite. Although this solution reduces the delay in communicating with the home agent, frequently transferring the home agent records from one satellite to another will consume resources of ISLs. Nevertheless, having the HA on a satellite may result in forwarding the data packets through satellites even though the CN and the MN are connected through terrestrial networks.
|Algorithm||Location management placement||Anchor based/ Anchorless||Distributed/ centralized||Location update frequency||Data forwarding route||Main limitation in LEO satellites mega-constellation|
|SIGMA ||Ground||Anchor-based||Centralized||Every time the MN moves from one AR (satellite) coverage to another||It has to pass through terrestrial gateways||Did not consider the high frequency of satellite handovers in future LEO SatNets. Non-optimized routing through terrestrial networks.|
|Dual LAs ||Ground||Anchor-based||Centralized||When the MN leaves both FES LA and satellite LA||It has to pass through HA and FES||Requires paging to locate MN. Did not consider satellite’s location management.|
|Distributed location management using GSs ||Ground||Anchor-based||Distributed||Every time a MN/satellite changes its GS||It has to pass through GSs||Assumes the availability of many GSs. Did not consider the direct communication between satellites and MN.|
|VMIPv6 ||Satellites (location management), Ground (home agent)||Anchorless||Distributed||When the MN switches its connection to a new satellite within the same VAD, the MN only updates the local care-of address with the new MAA. If the HMAA of a MN slid out of the VAD or the MN moved to another VAD, then the global care-of address will change at HA.||It has to pass through HA then satellites||When a VAD is serving thousands of MNs, relaying MNs’ binding records from the departing satellite to the new satellite consumes ISLs resources. Having a fixed HA on the ground causes non-optimal routing.|
|Flexible agent ||Satellite||Anchorless||Every time a MN changes its access satellite||Distributed||It has to pass through the HA which is the current access satellite||In future LEO SatNets it is not easy to determine the next access satellite since there will be multiple candidate satellites in the mega-constellations and LEO satellites have limited processing resources.|
V-B Issues to Consider
IP-based location management has been early investigated in GEO satellite mesh networks . Nevertheless, the emergence of future LEO SatNets creates the need for more recent research on location management solutions that consider the special characteristics of future mega-constellations. The following points summarize some important issues that should be considered in IP-based location management for future LEO SatNets.
In IP-based location management, the anchor entity has two roles managing terminals locations and routing data packets to terminals. When anchor nodes are placed on earth, location management in future LEO SatNets faces the problem of limited link resources and long propagation delays while communicating with anchor nodes for binding updates or data delivery. On the other hand, placing anchor nodes on LEO satellites may encounter the problem of limited on-board processing and storage, and satellite fast mobility.
Studying the placement of anchor nodes (in both anchor-based and anchorless solutions) is very important to achieve route optimization. Through inspecting the previous studies, it is clear that neither space placement nor terrestrial placement of anchor nodes can give favourable routing performance in all forwarding scenarios.
IP-based location management solutions require complex signaling, such as the tunnels dynamic construction and release, which increases the load on satellites’ OBP units.
The proposed enhancements of IP-based location management in LEO SatNets face the problem of high location management overhead due to the unprecedented network architecture, where satellite mounted BSs move at high speeds causing the frequent handover of users/MNs in large groups.
Unlike location management in terrestrial networks, IP-based location management in future LEO SatNets has two levels. The first level is the location management of MNs. The second level is the location management of satellites that act as a BS, router, or terminal. Separating the two levels of location management might reduce the complexity of the location management system. However, there is still a need for some kind of mapping and coordination between the two levels.
Vi Approach #2: Locator/identifier split in LEO SatNets
The current satellite network architecture is using IP addresses as both identifiers (identify who is the endpoint) and locators (i.e., where is the endpoint in the routing system). However, the dual role of IP address is diminishing its ability to support mobility, especially in future satellite networks where the support for mobility with high scalability and tight time constraints is a pressing requirement . Mobility support in IP networks depends heavily on the network topology that has static anchor nodes, which makes IP mobility solutions impractical when applied to satellite networks. In a satellite network, location management should be intrinsically designed with the consideration of the network topology in order to avoid scalability issues. Some emerging mobile network architectures (e.g., MobilityFirst , ), considered the separation of identifier and location as a contributory to mobility management enhancement. In particular, the scalability of routing with the implementation of the locator/identifier split has been well investigated . With locator/identifier splitting, a remote node can be identified even if it is using multiple addresses during the communication (e.g., multi-homing concept). Thus, with locator/identifier separation, it is possible to keep an ongoing communication continuous while moving as nodes can keep their identifiers .
Conventional mobility management consists of two main procedures, location management, and handover management. However, in the location/identity split approach, mobility management is achieved through two correlated steps, namely location (binding) update and location resolution .
Based on the location/identity split approach, HIP ,  was proposed as a draft at IETF in 1999 followed by subsequent improvements in various aspects. The HIP architecture adds a new layer, called the Host Identity Layer, between the IP layer and the transport layer, thereby decoupling the layers from each other, and splitting the dual roles of IP addresses. When HIP is used, IP addresses function as pure locators. Instead of IP addresses, the applications use Host Identifiers to name peer hosts. To establish a HIP association, the two involved communicating parties issue a four-way handshake is required. HIP has a number of implementations such as OpenHIP  and HIPL . However, the implementation of HIP for satellite networks has not been investigated.
lisp  was initiated at the irtf in 2007, and has developed in the IETF working group since 2009. LISP has been promoted by Cisco and many research organizations such as LISP4.net , and LISP-Lab  with worldwide testbeds. LISP has multiple implementations such as Open-LISP , Cisco IOS , which significantly accelerated its development. LISP divides the whole network into the core and the edges and divides the IP addressing space into the eid and rloc. An EID is topology-independent and used as a local address by hosts within edge networks, while a RLOC is used as a global locator to transmit packets within the core network. In LISP, the border router that forwards packets from the edge to the core is called itr, whereas the one that forwards packets in the opposite direction is called etr. The ITR maintains a cache of RLOC-EID mapping locally. If the ITR does not have the location of the destined EID, it will send a Map-Request to the mapping system. Afterward, the ITR will send the data packet to the proper ETR. There are a number of proposals for LISP mapping systems such as LISP-Tree  and LISP-DDT . However, the application of LISP was not investigated in satellite networks.
In , GRIMM is proposed as a gateway based regional mobility management architecture for satellite network based on locator/identifier split. GRIMM divides the coverage of the satellite system into regions based on the terrestrial gateways distribution. Each gateway is equipped with a tgms and is responsible for the localized location management of the MN within its region. The global location management is realized through the synchronization among all gateways. When a foreign TGMS receives global updates, it generates the mapping entry between MN’s ID and its corresponding TGMS. To avoid the non-optimal routing, GRIMM’s location resolution is conducted before forwarding data packets. In GRIMM, a MN accesses a satellite with a fixed id and the local TGMS records the MN’s ID and its corresponding accessed satellite. When the MN ID is registered locally for the first time, the TGMS will trigger a global update among all TGMSes. To start a session between a MN and a CN, the accessed satellite will first send a request of location resolution to the local TGMS upon receiving the first data packet. If the local TGMS does not have the specific locator of the enquired CN’s ID, the request will be redirected to the corresponding TGMS. After receiving the requested CN location, the source satellite begins to encapsulate the data packet with location information and then forwards it through inter-satellite links to that area. The destined satellite can decapsulate the packet and then sends it to the CN. When a MN moves from one satellite area to another, subsequent messages will notify the accessed satellite of CN to update MN’s location in the cached mapping entry. This is to update the routing path between satellites. Although the regional location management greatly reduces the management cost and facilitates the scalability of the network, global updates may create high signaling overhead among the gateways. In addition, keeping records of every MN’s ID and its corresponding TGMS in all foreign TGMS requires massive storage resources.
SAT-GRD is a proposed identification/location split network architecture for integrating satellite and terrestrial networks . It separates the identity of both the network and the host from their locations. It introduces a hierarchical mapping and resolution system that enables the separation of the control and data plane in SAT-GRD as well as the decoupling of the intra-domain routing policy from the inter-domain routing. Each edge network has its own edge mapping system and there are two core mapping systems one in space (using GEO and MEO satellites) and the other one is on the ground (for terrestrial network). Between satellite and terrestrial networks, there are a number of border routers that handle the mapping of the host’s ID and location between the two networks.
A heterogeneous satellite-terrestrial network architecture, HetNet, is proposed in . HetNet synthesizes locator/identity split and information-centric networking. The author assumed the availability of a network manager node at each edge network that handles the location registration and the location-to-ID resolution. In addition, there are network management nodes in the core network that forms a hierarchical structure with the edge network management nodes. For satellite networks, their network management nodes are placed in the ground gateways. When a MN moves within the same network then its location is updated in the local network management node, whereas an upper network management node needs to update the MN location when it is moving from one network to another. However, the author did not clarify whether a satellite moving from one gateway to another will cause a local or a higher level location update. Moreover, the proposed architecture did not consider the direct communication between satellites and MNs, instead, it assumed that MNs can communicate with satellites through ground gateways only.
Location/identity split can enhance mobility in satellite networks. However, with the high mobility of LEO satellites, employing the conventional binding (location) update schemes will create a large number of binding updates for both MNs and satellites. To mitigate the effect of frequent satellite handover on the binding update rate, the authors of  and  proposed the concept of vap to make binding update independent of satellite’s motion. The virtual attachment point stays in fixed position in relative to the ground. The VAP scheme decouples the binding of endpoints and satellites into two types of independent bindings: the binding between the endpoint and the virtual attachment point, and the binding between virtual attachment point and physical satellite. The two independent bindings provide the binding information required for endpoint mobility based on the location/identity split approach. Thus, a virtual spherical network consisting of fixed VAPs is superimposed over the physical satellite topology in order to hide the mobility of satellites from the terrestrial endpoints. A VAP is created and maintained by the different satellites that pass over the constant network location of VAP. Then a binding between the MN identity and the fixed virtual attachment point rather than the physical satellite passing over the MN is carefully maintained by an identity-to-location resolution system. For the binding of the physical satellites to a certain VAP, the proposed scheme takes advantage of the periodic and predictable LEO satellite movement as well as the satellite predefined constellation topology. Thus, on a periodical basis, a group of satellites will be leaving a VAP and rebinding to the next VAP.
To enable location/identifier split in satellite networks, there is a real need for a rapid mapping system that can resolve identifiers to network locations in a real-time manner. Conventional ground station based satellite system control frame is restricted to the land distribution. The distributed mapping system constructed only by ground stations may be too far to access for global scattered mobile users. Consequently, the lookup latency becomes another challenge. To address this issue,  presented a space-based distributed rmrs along with a dynamic replica placement algorithm. The goal of RMRS is to achieve low lookup latency, low update cost, and high system availability (resilience to failures). The two main components of RMRS are the virtual resolvers and replica placement controllers. The space-based fixed virtual resolvers are responsible for maintaining the mapping replicas and responding to user requests, while the replica placement controllers on the ground are responsible for determining the number and locations of the mapping replicas. The virtual resolvers have the same concept as the VAPs . The virtual resolvers are fixed with respect to Earth and create a virtual overlay network upon underlying moving physical satellites. Each virtual resolver is embodied at a certain time by specific satellites. When a satellite leaves a virtual resolver region, then the mapping records handled by this virtual resolver are then transmitted to the subsequent satellites passing by. The replica placement controllers usually reside in the ground stations and communicate with the virtual resolvers (LEO satellites) through GSLs. Replicating every mapping at every possible location will create an unacceptable cost, especially with the rapid movement of satellites and their large-scale network. Therefore, the replica placement controllers use the dynamic replica placement algorithm to determine the number and locations of replicas for each mapping entry so as to provide a tradeoff between lookup latency and update cost. However, an accurate calculation of the region size is required with consideration of the number of satellites in the constellation. This is to avoid the situation of having no satellite in the virtual resolver region for some time.
Locator/identifier split also has its natural advantages in mobility support. The identifier uniquely represents the node in the network and the varying locator is used for routing. Through dynamic mapping from identifier to locator before sending packets, the independent location management (i.e., mapping service) is achieved, and non-optimal routing is eliminated. Independent implementation of mapping service provides more flexibility and its advantages can become more significant with the increase of network scale, especially in scenarios with constant mobility. Existing locator/identifier split architectures mainly focus on the terrestrial network. And related work on its application feasibility in satellite networks has not been conducted .
|Algorithm||Location resolver placement||Location update frequency||Location query trigger||Main limitation in LEO satellites mega-constellation|
|HIP , ||Ground-based||Every location change||Establishing a connection with CN or when CN change its location||Not investigated for satellite networks|
|LISP ||Ground-based||When MN moves from one edge network to another||When the location is not available in ITR cache||Not investigated for satellite networks|
|GRIMM ||Ground-based||Global update: when a MN moves from one region to another. Local update: when accessed satellite change||When new data session starts and its done through SGLs||Global updates will create high network overhead, requires large storage to keep global records, Ground-based location resolution delays session initiation|
|SAT-GRD ||Ground and satellite-based||When MN moves from one AR to another within the same edge, the location update is in the edge mapping system. Whereas, moving from one edge network to another results in location updates at the core mapping system level||When moving from one AR to another or from one edge network to another||Did not consider the direct communication between satellites and users. The border routers might encounter high loads and bottlenecks when direct communication between satellites and users is considered.|
|HetNet ||Ground-based||Upper hierarchical level update: when MN moves from one edge network to another. Local update: when MN moves within the same edge network||When new data session starts and its done through SGLs||Did not consider the direct communication between satellites and users|
|VAP ||Satellite-based||When a MN or satellite changes its VAP region||When new data session starts and it is done through ISLs||Creates overhead on ISLs when location-ID records are transferred from one satellite to another.|
|RMRS ||Satellite-based||Updates are done in the original and replica satellites when a MN or satellite changes its virtual region||When new data session starts and its done through ISLs||Creates overhead on ISLs when location-ID records are transferred from one satellite to another. Creating replicas increases the location update cost and consumes the satellite limited processing power.|
Vi-a Issues to Consider
This section highlights the issues that should be considered in implementing the location/identifier approach for future LEO SatNets.
To enable implementing location/identifier split approach in future SatNets, it is important to have optimal location update/resolution schemes that are scalable and can work rapidly with reduced complexity and signaling costs.
Placing location resolvers on the ground may create delays in location update/resolution and they might not be uniformly distributed due to the geographical structure of Earth. On the other hand, placing the location resolvers of a certain region on satellites requires periodic transmission of location-ID mapping records from one satellite to another, which may congest the ISLs. In this regard, placing location resolvers on haps may provide a good solution as the HAPS position is in between satellites and ground stations/users, and it is considered quasi-stationary with respect to Earth and .
In the future, satellite networks are going to be part of the integrated vhetnet . Therefore, any locator/identifier split system should consider the backward compatibility with legacy IP locator and identifier systems.
Global updates performed by some of the existing solutions seem impractical especially when there are thousands of satellites and millions of user devices communicating with the satellite networks.
Most of the existing studies do not consider the status of future satellite networks which will consist of several mega-constellations that will provide connectivity and Internet services not only in rural or remote areas but also in urban areas.
Vii Approach #3: SDN-based location management in LEO SatNets
SDN concept separates the control plane from the data plane. In SDN, controllers are considered the brain that performs intelligent functionalities. Through the northbound interfaces, the controllers interact with applications to decide on how to create/update flow tables located in the SDN switches. Communication among SDN controllers can be done through westbound and eastbound interfaces. An SDN controller can communicate with one or more SDN switches through secure channels. The switches have flow tables that contain predefined actions on how to treat the received packets. Whenever a new packet is received at the SDN switch, a flow table lookup is done. In the lookup process, if the packet headers match can be found in the lookup table, then the predefined actions are performed. If the match was not found in the flow table entries then the packet will be forwarded to the controller through the southbound interface . For more details on SDN, the interested reader may refer to .
Based on the received network topology information, the SDN controller makes the routing/forwarding decisions. Unlike traditional networks, topology management is a fundamental task in SDN. td is a key component to support the logically centralized control and network management principle of SDN. TD enables a controller to have global visibility of the complete network. Discovering the network topology includes the discovery of switches, hosts, and interconnected switches. In the TD process, each entity on the network can collect information about the network topology. The information collection can be done at different levels and in many ways. The TD must be error-free because a topology error may lead to wrong routing flows. In addition, the TD process must be efficient in terms of sending topology information only when changes happen and not flooding the controllers with unnecessary information .
Based on the aforementioned explanation of SDN’s TD, it can be concluded that TD is providing a major part of the functionality of location management in SDN. Basically, location management and TD both provide information on the network entities’ location (logical location) within the network and the interconnections between different entities. For this reason, several studies proposed SDN based mobility management schemes where TD is utilized for location management. For example,  proposes a location management scheme for a 5G mobile core network that purely relies on SDN. The scheme is used to manage the MN status and the paging procedure.
In , discusses the challenges of TD protocol for SDN-based wireless sensor networks. The author highlighted the issue of limited resources of sensor networks that require lightweight TD protocol, which is a similar requirement in satellite networks. Although satellite networks will have more resources than wireless sensor networks in terms of power and processing capabilities, applying existing TD protocols in satellite networks will encounter very high network overhead. In particular, with the fast mobility of satellites that results in frequent topology changes in the densely deployed mega-constellations, more packets will be sent to the controller to update the topology and flow table. Such an overhead traffic could negatively affect the efficiency of network resources utilization.
The authors in  and  utilized SDN to construct and manage the topology of an icn overlaid on a legacy IP network using the controller’s management capabilities. A centralized controller constructs the ICN topology dynamically when new customer networks join the overlay, and it can modify the topology of the ICN overlay in order to reduce the load on the congested links. This dynamic topology control performed by the centralized controller is a useful feature for future LEO SatNets. However, the centralized nature of SDN will raise a concern with respect to satellite network scalability.
In SDN, the controller is responsible for updating the forwarding rules of the network elements’ in the data plane. The time required for a rule to be installed is referred to as the flow setup time. In a large-scale network such as a LEO mega-constellation, a single controller with limited resources will not be able to handle all the update requests originating from the data plane and the controller might encounter bottlenecks. Furthermore, due to the large distances between the satellites and the controller, there is no guarantee to meet the acceptable control plane latency. Therefore, having a distributed control plane becomes mandatory. However, it is very important to choose the optimum number of controllers and their locations based on the traffic load distribution and topology changes .
Vii-a Merging of SDN and Distributed Mobility Management
The DMM concept was introduced by IETF to overcome the limitations of centralized management such as the one point of failure, bottlenecks, and high delays. DMM-based solutions can be categorized into two types, depending on the distribution level of the control plane :
Partially distributed: The control plane is centralized in certain control points in the network, whereas the data plane is completely distributed among the network entities; and
Fully distributed: Both control plane and data plane are completely distributed among the network entities, and there exists no central entity of control.
Some researchers considered SDN as an enabler for DMM . They considered that DMM approaches will push mobility anchor points to be distributed at the network edge and foreseen the SDN separation of data and control planes, which allows quicker configuration and provision of network connections, as an enabler for managing mobility in a distributed way at the edge. On the other hand, some studies considered that DMM can help in mitigating the drawbacks of SDN centralization. The merging of SDN and DDM concepts have been investigated in several types of networks. For example, an architecture that uses the SDN paradigm with the DMM concept in an environment of heterogeneous IP networks was proposed in 
. The proposed architecture avoids the centralization problem of SDN and presents a hierarchical cluster-based implementation of the SDN‐DMM controllers that ensures the scalability of the control plane and reduces the availability problem related to the single point of failure. With the merging of SDN and DMM, a large portion of data traffic can be treated locally at the network edge, which reduces the probability of bottlenecks at the network core. When a MN moves to another network, it does not need to change its IP address while being in an ongoing session. Instead, the controller will update the IP flow related to the moving MN to ensure that the forwarded packets will reach the MN in the new network. In addition, several studies studied the merging of DMM and SDN in 5G, .
Vii-B SDN-based Location Management in LEO SatNets
A simple sdsn architecture was proposed in . It contains three planes: the data plane (satellite infrastructure, terminal router), the control plane (a group of GEO satellites), and the management plane (nocc). Similarly, the author of  proposed a SDSN where the controllers are located on GEO satellites and the switches are deployed in MEO and LEO satellites. Since the frequent handovers will rapidly increase the flow table size in SDSN, a lot of flows will be dropped during topology changes (handovers) due to the limited size of the flow table. In particular, a commodity switch can store about 1500 entries only because of the high cost and energy consumption of the tcam that is usually used by SDN switches . After a handover, the flow table will have unexpired entries occupy the flow table space and are useless because they will not be matched any more. The subsequent flows may be dropped if the TCAM space is limited. To address this problem the author of 
proposed a heuristic tsmm algorithm which aims to reduce the drop-flow during handover. The TSMM algorithm adjusts the entries timeout dynamically while considering two key points, the limited flow table space and the satellite link handover. This aims to evict the flow entries that belong to the former connection as soon as the handover occurs. This work has been extended in SAT-FLOW
, which is a multi-strategy flow table management method for SDSN. SAT-FLOW is composed of two heuristic algorithms, dct algorithm and TSMM algorithm. DCT calculates a dynamic idle timeout value for the flow entries taking limited TCAM space and classified traffic into consideration. TSMM utilizes the result of DCT and considers link handover in satellite networks. Thus, DCT aims to reduce the flow table size and TSMM aims to reduce the drop-flows during the handover. A time estimation model is proposed by to estimate the mean time required to complete the SDN control (i.e., finding or creating the necessary traffic flow) and to deliver the first packet to the destination. The author considered an architecture where three GEO satellites play the role of SDN controllers and the data plane is distributed among the LEO satellites.
However, the fixed controller placement at GEO satellites might not be able to react to traffic fluctuations caused by variable user activities and different time zones. In addition, with densely populated and highly dynamic LEO mega-constellations, having few controllers placed at GEO may result in bottlenecks and high delays while updating routing flows.
To overcome the fixed placement problem, a dynamic SDN controller placement is considered in . The author developed a mathematical model and formulated it as an ilp to find the optimal controller placement and the number of satellites that will work as controllers. The goal of the model is to minimize the average flow setup time with respect to the traffic dynamics. The model was derived based on an SDN architecture, where the control plane layer consists of several LEO satellites that varies based on traffic demands in addition to seven satellite gateways placed on the ground and serve as entry points to the backbone network. The gateways position is fixed and is obtained from the existing IRIDIUM system. The satellites that are part of the control plane serve as both controllers and network switches. They manage, control, and update the forwarding rules of the flow tables of the satellites of the data plane. On the other hand, the satellites of the data plane are only responsible for forwarding packets based on rules defined by the corresponding controllers. However, this study considered the LEO satellites in the number of hundreds, which does not reflect the mega-constellation characteristics of future networks. The future densely deployed satellite networks may result in creating huge flow tables that have very short lifetime.
A framework of SDSN is proposed by , which defines the dcpp as well as the scpp, and used an apso algorithm to solve the problems in DCPP and SCPP. The author considered the parameters of propagation delay, reliability, controller load, signalling cost, and the dynamic characteristic of satellite networks. In the DCPP the number and location of active controllers can be adjusted by altering the on-off states according to the changes in network conditions. The author assumed an architecture of multiple controllers that can be placed in LEO, MEO, or GEO, whereas the switches are all placed in the same LEO constellation. In this work, the data plane switches send periodic hello messages to their controller, such messages are used to collect information about changes in network topology (i.e., topology discovery). In addition, the periodic hello messages are used to connect with a new controller when the switch loses the connection with the current controller. Controllers exchange the obtained topology discovery information to build up a global view of the network.
A three-layer hierarchical controller architecture for software-defined GEO/LEO satellite networks is proposed in . The solution exploited the wide coverage ability of GEO satellites, easy upgrade and maintenance of NOCC, and stability of inter-satellite links in the same low earth orbit. The control plane consists of domain controllers, slave controllers, and a super controller. The GEO satellites are set as domain controllers because of their broadcast potential over a wide-coverage area and stable connection with the ground station. The domain controller aims at monitoring and managing the LEO satellites in its coverage. The LEO satellites forward and collect the network status information, and are divided into different domains according to the GEO coverage. Several slave controllers are selected from LEO satellites. The GEO domain controllers communicate with just the slave controllers under their own authority instead of all LEO satellites in their domain. The slave controllers collect the status information of the LEO satellites under their own authority by using inter-satellite links and then send the collected information to corresponding domain controllers. The NOCC is deployed as a super controller that can obtain the knowledge of the overall network through the primary GEO satellites. Based on the aforementioned description, a logically centralized control plane with global knowledge is created through physically distributed LEO controllers. To select the slave controller, each LEO orbit plane is regarded as a separate management area. The LEO satellites in each orbit plane are divided into two groups such that one group is moving from north to south and the other from south to north. In each group, the LEO satellite whose latitude is nearest to is selected as the slave controller to collect the status information of other LEO satellites in this group. However, if more than one LEO satellite has the same lowest latitude, the one which can maintain a longer communication time window will be selected as the slave controller.
|Algorithm||Study objective||Controller placement||Dynamic/Fixed||Location update frequency||Main limitation in LEO satellites mega-constellation|
|OpenSAN ||Proposed a SDN-based satellite network architecture||In GEO satellites||Fixed||Based on satellite movement prediction, flow tables are updated||This architecture is designed to provide services for terrestrial users through ground gateways only and not through direct communication.|
|TSMM , DCT ||To manage flow tables and reduce the drop-flows due to frequent handover||In GEO satellites||Fixed||With every handover||The authors presented a good idea to manage flows tables, however, the focus was on satellites only without considering terrestrial terminals or users.|
|Time estimation model||To estimate the mean time required to complete the SDN control and to deliver the first packet to destination||In GEO satellites||Fixed||Periodically based on satellite movement||Communicate with terrestrial networks using ground gateways. No consideration for the case when thousands of users are directly connected to LEO satellites.|
|Dynamic controller placement-ILP ||To present a mathematical model that finds the optimal controller placement and the number of satellites that will work as controllers||In LEO satellites (with variable number and placement)||Dynamic||Based on the satellite movement prediction||Due to LEO satellite fast movement, SDN controllers will change frequently. It is very complicated to manage the changes in controllers seamlessly in a network consisting of thousands of satellites while serving millions of users.|
|Dynamic controllers placement- Swarm optimization ||To present an architecture of multiple controllers placed dynamically using swarm optimization||In GEO, MEO, LEO satellites||Dynamic||Using periodic hello messages||Using periodic hello messages will consume the ISLs resources especially in large scale networks.|
|Hierarchical dynamic controller placement ||To present a hierarchical dynamic controller architecture||In GEO and LEO satellites||Dynamic||Periodically collected and sent by LEO controllers||Maintaining the hierarchical architecture in a very dense satellite network consumes ISLs resources due to the very frequent topology changes.|
Vii-C Issues to Consider
This section points out the important issues that should be considered in order to utilize SDN-based location management for future LEO SatNets.
In software defined future LEO SatNets, there will be millions or billions of user devices connected to LEO satellites. This will create a huge number of flow records at each switch (LEO satellite), and such records will be expired once the satellite moves to serve a different group of people. Setting up new flow records with every satellite handover consumes resources and creates delays. However, the idea of relaying flow tables from a departing satellite to a coming one worth investigation.
When terrestrial and satellite networks are integrated, there will be millions or billions of flows. Storing, maintaining, and searching through these flow tables records is a complicated and critical issue.
Although the distributed SDN architecture is preferred in SatNets environment, the limited satellite resources to implement all the distributed SDN functions should be taken into consideration.
To gain the advantages of dynamic SDN controller placement in future LEO SatNets, a number of factors should be considered such as traffic demands, users distribution, users mobility, signalling cost, and the dynamic characteristic of satellite networks.
18]. Thus, the utilization of artificial intelligence in SDN-based LEO SatNets location management should be considered. In particular, artificial intelligence/machine learning algorithms can be useful in selecting the SDN controllers and their placements in order to adapt to the dynamic nature of LEO SatNets.
In terrestrial networks, SDN controllers update the flow tables using the information obtained through topology discovery protocols. In satellite networks, a large portion of topology update overhead can be saved by predicting satellite movement. However, with the availability of mega-constellations of thousands of satellites, user devices will have multiple candidate satellites to handover. In this situation, updating users’ related flows based on mobility predictions is complicated.
Viii Current view and future challenges
The previous three sections focused on discussing the efforts that have been done to address the problem of location management in LEO SatNets. Some researchers tackled the issue of LEO SatNets location management by extending or enhancing the IETF IP-based location management techniques that come as part of IPv6 mobility management protocols. In contrast, a considerable number of studies identified the dual role of IP address as an identifier and a locator to be the main cause of the poor performance of IETF IP-based location management techniques in LEO SatNets. Consequently, several researchers investigated the employment of the location/identifier split concept in LEO SatNets. A third approach utilized the network softwarization and the decoupling of control and data planes advantages offered by SDN to support location management in LEO SatNets in a flexible way.
Clearly, the IETF IP-based location management techniques and location/identifier split algorithms are based on two totally different concepts as the former considers the dual role of IPv6 address while the later separates the two roles. IPv6 and SDN are interrelated technologies where IPv6 operates on the network layer and SDN handles the management of the networking operations. From the location management perspective, SDN serves more the routing side by using the flow concept rather than IP addresses to deliver packets to their destinations.
Under each of the three aforementioned approaches, several solutions have been proposed to deal with location management in LEO SatNets. Although such solutions have some potentials when applied to future LEO SatNets, many challenges will be encountered as well. This is due to the complicated and new mobility and topology characteristics of future LEO SatNets which were discussed in Section II. Table V summarizes the advantages and challenges of each of the three location management approaches from the perspective of future LEO SatNets.
|Approach #1: Extensions of IETF location management techniques||
|Approach #2: Locator/identifier split||
|Approach #3: SDN-based location management||
Ix Future research directions
Intensive research is required to overcome the obstacles and unlock the potentials of future LEO SatNets to providing continuous connectivity everywhere, for everything, and in the required QoS. Location management in future LEO SatNets faces many serious challenges. This section highlights some critical points that require further investigation and recommends future research directions.
In future LEO SatNets, there will be several mega-constellations with different orbital parameters. Such parameters will have an effect on a number of variables including propagation delays, handover frequency and duration, footprints, and density of satellites. Such variables affect the performance of location management algorithms. Thus, for different orbits/constellations, location management might be different. In addition, the diversity in required QoS for user devices/applications should be taken into consideration while designing location management solutions for future LEO SatNets.
The authors in  considered that the main causes of the current Internet’s problems are the so-called triple bindings, namely user/network binding, control/data binding, and resource/location binding. The author proposed a collaborative Internet architecture that completely cancels the restrictions imposed by the triple bindings. Although this approach applicability in future LEO SatNets was not discussed, it worths the investigation as it may add flexibility to network topology management.
As part of the secure mobility management work presented in , the author proposes to use blockchain technology for group location management in vehicular ad hoc networks. Blockchain technology is well known for managing its ledgers in a secure and distributed nature. This feature of blockchain might be advantageous in managing the flow tables in SDN-based LEO SatNets.
Recently, discussions have started on proposing a “New IP Address” for 2030 networks , , , which aims to connect heterogeneous networks, provide deterministic forwarding, and support intrinsic security. Theoretically, New IP offers more efficient addressing and network management than the existing TCP/IP standard. However, there are some concerns that New IP would require authorization and authentication of the sent data packets and the user identity as well as the internet addresses.
Efficient location management is essential to unlocking the potential of future LEO SatNets. This article aims to explore the current development in location management and identify the gaps and challenges facing the realization of required location management for future LEO SatNets. From the perspective of future LEO SatNets, this article critically reviews the existing three location management approaches including extensions of the IETF location management techniques approach, the locator/identifier split approach, and the SDN-based location management approach. The deterministic aspects of the LEO mega-constellations and the fixed terminals can be exploited to support location management. Software defined satellite network concept will play a major role in supporting location management in future LEO SatNets. Worthy recommendations for future research directions conclude this work. This article can be used as a road map to guide the research efforts towards fulfilling the requirements of location management in future LEO SatNets environment.
-  (2018) Study on Using Satellite Access in 5G, 3GPP TR 22.822 V16.0.0 (2018-06). Technical report 3GPP Technical Specification Group Services and System Aspects. Cited by: §II.
-  (Website) External Links: Cited by: §VI.
-  (2012) Mobility Management for IP-based Next Generation Mobile Networks: Review, Challenge and Perspective. Journal of Network and Computer Applications 35 (1), pp. 295–315. External Links: Cited by: §I-A, TABLE I.
-  (2018) New Topology Management Scheme in LTE and 5G Networks. In IEEE 87th Vehicular Technology Conference (VTC Spring), pp. 1–5. Cited by: item 3.
-  High Altitude Platform Station based Super Macro Base Station (HAPS-SMBS) Constellations. to appear in IEEE Communications Magazine, 2021 (arXiv preprint arXiv:2007.08747). Cited by: 2nd item.
-  (2019) Coverage and Rate Analysis for Vertical Heterogeneous Networks (VHetNets). IEEE Transactions on Wireless Communications 18 (12), pp. 5643–5657. Cited by: 3rd item.
-  (2012) Identifier-Locator Network Protocol (ILNP) Engineering Considerations. IRTF, RFC 6741 (E). Cited by: item 2.
-  (2014) OpenSAN: A Software-Defined Satellite Network Architecture. ACM SIGCOMM Computer Communication Review 44 (4), pp. 347–348. Cited by: §VII-B, TABLE IV.
-  (2018) The Impact of Delay in Software-Defined Integrated Terrestrial-Satellite Networks. China Communications 15 (8), pp. 11–21. Cited by: §VII-B, TABLE IV.
-  (2014) A Comprehensive Tutorial for Mobility Management in Data Networks. IEEE Communications Surveys Tutorials 16 (2), pp. 812–833. Cited by: §I-A, TABLE I.
-  (2014) Requirements for Distributed Mobility Management. IETF RFC 7333. Cited by: §V-A.
-  (2020) Free Space Optics for Next-Generation Satellite Networks. IEEE Consumer Electronics Magazine, pp. 1–9. External Links: Cited by: §II.
-  (2016) Mobility Management: Principle, Technology and Applications. Springer. Cited by: §III-A, §III-A.
-  (2020) NEW IP Framework and Protocol for Future Applications. In NOMS - IEEE/IFIP Network Operations and Management Symposium, Vol. , pp. 1–5. Cited by: 4th item.
-  (2019) SDN-DMM for Intelligent Mobility Management in Heterogeneous Mobile IP Networks. International Journal of Communication Systems 32 (17), pp. e4140. Cited by: §I, §VII-A, §VII-A.
-  (2011) DevoFlow: Scaling Flow Management for High-Performance Networks. In ACM Special Interest Group on Data Communication (SIGCOMM) Conference, pp. 254–265. Cited by: §VII-B.
-  (2020) Flexible and Aggregated Mobility Management in Integrated Satellite-Terrestrial Networks. In International Wireless Communications and Mobile Computing (IWCMC), pp. 982–987. Cited by: §I, §V-A, TABLE II.
-  A Vision of Self-Evolving Network Management for Future Intelligent Vertical HetNet. to appear in IEEE Wireless Communications Magazine, 2021 (arXiv preprint arXiv:2009.02771). Cited by: 5th item.
-  (2016) Satellite Communications Supporting Internet of Remote Things. IEEE Internet of Things Journal 3 (1), pp. 113–123. Cited by: §I-A.
-  (2017) IP Mobility Management Using Software Defined Networking: A Review. In IEEE 2nd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC), Vol. , pp. 76–81. Cited by: §I-A, TABLE I.
-  (2013) Locator/ID Separation Protocol (LISP), Document IETF RFC 6830. Technical report IETF. Cited by: TABLE III, §VI.
-  (2017) Locator/Identifier Split Networking: A Promising Future Internet Architecture. IEEE Communications Surveys Tutorials 19 (4), pp. 2927–2948. Cited by: §I-A, TABLE I, §I.
-  (2016) SAT-GRD: An ID/Loc Split Network Architecture Interconnecting Satellite and Ground Networks. In IEEE International Conference on Communications (ICC), Vol. , pp. 1–6. Cited by: §I, TABLE III, §VI.
-  (2017) HetNet: A Flexible Architecture for Heterogeneous Satellite-Terrestrial Networks. IEEE Network 31 (6), pp. 86–92. Cited by: TABLE III, §VI.
-  (2012) LISP Delegated Database Tree. Technical report IETF. Cited by: §VI.
-  (2016) Mobility Management for IoT: A Survey. EURASIP Journal on Wireless Communications and Networking 2016 (1), pp. 165. Cited by: §I-A, TABLE I.
-  (2008) Proxy Mobile IPv6, Document IEEE RFC 5213. Technical report IETF. Cited by: §III-A, §III-A.
-  (2018) Leveraging SDN for Handover in Distributed Mobility Management of 5G Network. In 12th International Conference on Telecommunication Systems, Services, and Applications (TSSA), pp. 1–7. Cited by: §VII-A.
-  (2016) GRIMM: A Locator/Identifier Split-Based Mobility Management Architecture for LEO Satellite Network. In 6th International Conference on Instrumentation & Measurement, Computer, Communication and Control (IMCCC), pp. 605–608. Cited by: §I, §I, §III-A, §III-B, §III-B, §III-B, TABLE III, §VI, §VI, §VI.
-  (2018) Exploring the Gateway-Based Distributed Location Management Schemes in LEO Satellite Networks. IEICE Transactions on Communications 101 (3), pp. 825–834. Cited by: item 1.
-  (2016) Distributed Mobility Management in IP/LEO Satellite Networks. In 3rd International Conference on Systems and Informatics (ICSAI), pp. 691–695. Cited by: §V-A, TABLE II.
-  (2016) Comparative Handover Performance Analysis of MIPv6 and PMIPv6 in LEO Satellite Networks. In 6th International Conference on Instrumentation & Measurement, Computer, Communication and Control (IMCCC), pp. 93–98. Cited by: §III-B, item 1.
-  (2017) Host Multihoming with the Host Identity Protocol, Document IETF RFC 8047. Technical report IETF. Cited by: TABLE III, §VI.
-  (2013) A Survey of Mapping Systems for Locator/Identifier Split Internet Routing. IEEE Communications Surveys Tutorials 15 (4), pp. 1842–1858. Cited by: §I-A, TABLE I.
-  (2018) Survivability and Scalability of Space Networks: A Survey. Telecommunication Systems 68 (2), pp. 295–318. Cited by: §I-A, TABLE I.
-  (2020) Analysis of PMIPv6 Extensions for Identifying and Assessing the Efforts Made for Solving the Issues in the PMIPv6 Domain: A Systematic Review. Computer Networks, pp. 107366. Cited by: §III-A, §III-B.
-  (2014) PMIPv6-based IP Mobility Management over Regenerative Satellite Mesh Networks. In 7th Advanced Satellite Multimedia Systems Conference and the 13th Signal Processing for Space Communications Workshop (ASMS/SPSC), pp. 1–8. Cited by: item 1, §V-B.
-  (2015) IP Multicast Receiver Mobility Support Using PMIPv6 in a Global Satellite Network. IEEE Communications Magazine 53 (3), pp. 30–37. Cited by: §III-B.
-  (2020) Are Mobility Management Solutions Ready for 5G and Beyond?. Computer Communications 161, pp. 50 – 75. External Links: Cited by: §I-A, TABLE I.
-  (2010) LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System. IEEE Journal on Selected Areas in Communications 28 (8), pp. 1332–1343. Cited by: §VI.
-  (2017) Distributed Mobility Management for the Future Mobile Networks: A Comprehensive Analysis of Key Design Options. IEEE Access 5, pp. 11423–11436. Cited by: §V-A.
-  (2016) Machine Learning Paradigms for Next-Generation Wireless Networks. IEEE Wireless Communications 24 (2), pp. 98–105. Cited by: §I.
-  (2020) A New Approach to a Service Oriented Internet Protocol. In IEEE International Conference on Computer Communications Workshops (INFOCOM WKSHPS), Vol. , pp. 273–278. Cited by: 4th item.
-  (2004) Mobility Support in IPv6, Document RFC 3775. Technical report IETF. Cited by: §III-A.
-  (2020) SDN-based Session and Mobility Management in 5G Networks. Wiley 5G Ref: The Essential 5G Reference Online, pp. 1–17. Cited by: §III, §VII.
-  (2017) Evaluating 5G Multihoming Services in the MobilityFirst Future Internet Architecture. In IEEE 85th Vehicular Technology Conference (VTC Spring), Vol. , pp. 1–5. Cited by: §VI.
-  (2020) UCIP: User Controlled Internet Protocol. In IEEE International Conference on Computer Communications Workshops (INFOCOM WKSHPS), Vol. , pp. 279–284. Cited by: 4th item.
-  (2018) Topology Discovery Protocol for Software Defined Wireless Sensor Network: Solutions and Open Issues. In IEEE 27th International Symposium on Industrial Electronics (ISIE), pp. 1282–1287. Cited by: §VII, §VII.
-  (2005) Fast Handovers for Mobile IPv6, Document IEEE RFC 4068. Technical report IETF. Cited by: §III-A, §III-A.
-  A vision and Framework for the High Altitude Platform Station (HAPS) Networks of the Future. to appear in IEEE Communications Surveys and Tutorials, 2021 (arXiv preprint arXiv:2007.15088). Cited by: 2nd item.
-  (2019) A Secure Blockchain-based Group Mobility Management Scheme in VANETs. In IEEE/CIC International Conference on Communications in China (ICCC), Vol. , pp. 340–345. Cited by: 3rd item.
-  (2019) Physical-Layer Security in Space Information Networks: A Survey. IEEE Internet of Things Journal 7 (1), pp. 33–52. Cited by: §I.
-  (2017) Timeout strategy-based Mobility Management for Software Defined Satellite Networks. In IEEE International Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp. 319–324. Cited by: §VII-B, TABLE IV.
-  (2017) SAT-FLOW: Multi-Strategy Flow Table Management for Software Defined Satellite Networks. IEEE Access 5, pp. 14952–14965. Cited by: §VII-B, TABLE IV.
-  (2016) Software Defined Integrated Satellite-Terrestrial Network: A Survey. In International conference on space information network, pp. 16–25. Cited by: §I-A, TABLE I.
-  (2015) A Review on Internet of Things (IoT), Internet of Everything (IoE) and Internet of Nano Things (IoNT). In Internet Technologies and Applications (ITA), pp. 219–224. Cited by: §I.
-  (2006) Host Identity Protocol (HIP) Architecture, Document IETF RFC 4423. Technical report IETF. Cited by: TABLE III, §VI.
-  (2016) SDN-based Distributed Mobility Management for 5G Networks. In IEEE Wireless Communications and Networking Conference, pp. 1–7. Cited by: §VII-A.
-  (2010) Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks. IEEE Communications Surveys Tutorials 12 (2), pp. 186–204. Cited by: §I-A, TABLE I.
-  (2018) Dynamic SDN Controller Placement in a LEO Constellation Satellite Network. In IEEE Global Communications Conference (GLOBECOM), pp. 206–212. Cited by: §II, §VII-B, TABLE IV, §VII.
-  (Website) External Links: Cited by: §VI.
-  (2019) Software Defined Networking Distributed and Dynamic Mobility Management. Google Patents. Note: US Patent 10,349,327 Cited by: §VII-A.
-  (2017) OpenFlow-Compliant Topology Management for SDN-Enabled Information Centric Networks. In IEEE Symposium on Computers and Communications (ISCC), pp. 951–954. Cited by: §VII.
-  (2014) The OpenLISP Control Plane Architecture. IEEE Network 28 (2), pp. 34–40. Cited by: §VI.
-  (2012) Implementation and Analysis of FMIPv6, an Enhancement of MIPv6. In International Conference on Ad Hoc Networks, pp. 351–364. Cited by: §III-A.
-  (2016) Survey of Inter-Satellite Communication for Small Satellite Systems: Physical Layer to Network Layer View. IEEE Communications Surveys & Tutorials 18 (4), pp. 2442–2473. Cited by: §I-A.
-  (2014) A Survey and Taxonomy of ID/Locator Split Architectures. Computer Networks 60, pp. 13 – 33. External Links: Cited by: §I-A, TABLE I.
-  (2008) Mobility Management Protocols for Next-Generation All-IP Satellite Networks. IEEE Wireless Communications 15 (2), pp. 46–54. Cited by: §I, §I, §III-A, §III-A, §III-B, §III-B, §III-B, §III-B, §III, §V-A, TABLE II.
-  (2005) Hierarchical Mobile IPv6 (HMIPv6) Mobility Management, Document IEEE RFC 4140. Technical report IETF. Cited by: §III-A, §III-A.
-  (2015) Software-Defined Wireless Networking Opportunities and Challenges for Internet-of-Things: A Review. IEEE Internet of Things Journal 3 (4), pp. 453–463. Cited by: §VII.
-  (2017) Comparative Handover Performance Analysis of MIPv6 and FMIPv6 in LEO Satellite Networks. In International Conference on Network and Information Systems for Computers (ICNISC), pp. 30–36. Cited by: §III-B.
-  (2017) Towards Location Management in SDN-based MCN. In IFIP/IEEE Symposium on Integrated Network and Service Management (IM), pp. 1097–1102. Cited by: §VII.
-  (Website) External Links: Cited by: §VI.
-  (Website) External Links: Cited by: §VI.
-  (Website) External Links: Cited by: §VI.
-  (2020) Reconfigurable Intelligent Surface Empowered Terahertz Communication for LEO Satellite Networks. arXiv preprint arXiv:2007.04281. Cited by: 1st item.
-  (2012) A Survey of Identity and Handoff Management Approaches for the Future Internet. Computer Communications 36 (1), pp. 63–79. External Links: Cited by: §I-A, TABLE I.
-  (2014) MobilityFirst: A Mobility-Centric and Trustworthy Internet Architecture. ACM SIGCOMM Computer Communication Review 44 (3), pp. 74–80. Cited by: §VI.
-  (2012) Separating Identifier from Locator with Extended DNS. In IEEE International Conference on Communications (ICC), pp. 2747–2751. Cited by: §VI.
-  (2018) Dynamic and Static Controller Placement in Software-Defined Satellite Networking. Acta Astronautica 152, pp. 49 – 58. External Links: Cited by: §I, §VII-B, TABLE IV.
-  (2018) Controller Placement in Software-Defined Satellite Networks. In 14th International Conference on Mobile Ad-Hoc and Sensor Networks (MSN), pp. 146–151. Cited by: §I, §VII-B, TABLE IV.
-  (2018) Software-Defined Next-Generation Satellite Networks: Architecture, Challenges, and Solutions. IEEE Access 6 (), pp. 4027–4041. Cited by: §I-A, TABLE I.
-  (2009) ES-FHMIPv6: An Efficient Scheme for Fast Handover over HMIPv6 Networks. International Journal of Future Generation Communication and Networking 2 (2), pp. 11–24. Cited by: §III-A.
-  (2018) A Controller-based Architecture for Information Centric Network Construction and Topology Management. China Communications 15 (7), pp. 131–145. Cited by: §VII.
-  (2016) Smart Identifier Network: A Collaborative Architecture for the Future Internet. IEEE Network 30 (3), pp. 46–51. Cited by: 2nd item.
-  (2019) Virtual Agent Clustering Based Mobility Management Over the Satellite Networks. IEEE Access 7, pp. 89544–89555. Cited by: §I, 3rd item, §V-A, §V-A, TABLE II.
-  (2016) MSN: A Mobility-Enhanced Satellite Network Architecture: Poster. In 22nd Annual International Conference on Mobile Computing and Networking, pp. 465–466. Cited by: §VI.
-  (2017) Design Overview of a Rapid Mapping Resolution System for Enabling Identifier/Location Separation in Satellite Network. In 16th International Conference on Optical Communications and Networks (ICOCN), pp. 1–3. Cited by: TABLE III, §VI.
-  (2017) Supporting Location/Identity Separation in Mobility-Enhanced Satellite Networks by Virtual Attachment Point. Pervasive and Mobile Computing 42, pp. 1–14. Cited by: TABLE III, §VI, §VI, §VI.
-  (2012) An IP Mobility Management Scheme with Dual Location Areas for IP/LEO Satellite Network. Journal of Zhejiang University SCIENCE C 13 (5), pp. 355–364. Cited by: §V-A, TABLE II.