An Efficient Location-Based Forwarding Strategy for Named Data Networking and LEO Satellite Communications

Abstract

Low Earth orbit (LEO) satellite constellations are increasingly gaining attention as future global Internet providers. At the same time, named data networking (NDN) is a new data-centric architecture that has been recently proposed to replace the classic TCP/IP architecture since it is particularly well suited to the most common usage of the Internet nowadays as a content delivery network. Certainly, the use of NDN is especially convenient in highly dynamic network environments, such as those of next LEO constellations incorporating inter-satellite links (ISL). Among other native facilities, such as inbuilt security, NDN readily supports the mobility of clients, thus helping to overcome one of the main problems raised in LEO satellite networks. Moreover, thanks to a stateful forwarding plane with support for multicast transmission and inbuilt data caches, NDN is also able to provide a more efficient usage of the installed transmission capacity. In this paper, we propose a new location-based forwarding strategy for LEO satellite networks that takes advantage of the knowledge of the relative position of the satellites and the grid structure formed by the ISLs to perform the forwarding of NDN packets. So, forwarding at each node is done using only local information (node and destination locations), without the need of interchanging information between nodes, as is the case with conventional routing protocols. Using simulation, we show that the proposed forwarding strategy is a good candidate to promote the efficient and effective future use of the NDN architecture in LEO satellite networks.

1. Introduction

The TCP/IP architecture, originally proposed to provide reliable communication between pairs of nodes in the Internet [1], is a host-centric architecture in which packets only identify communication endpoints using IP addresses. However, the general purpose of the Internet has changed significantly since its origin, and today’s applications and services use it mainly as a distribution network [2]. Thus, the need to identify the ends of communication in IP networks has become nothing but a shortcoming of the system. Information-centric networks (ICNs) adopt a different paradigm for communication on the Internet. In ICNs, the current host-centric TCP/IP architecture is replaced with a new data-centric architecture that brings data into focus. One of the most popular ICN proposals is the named data networking (NDN) project, proposed in 2010 and funded by the NSF Future Internet Architecture Program. This architecture changes the dynamics of network interaction from sending a packet to a given destination to fetching data by addressing its name, regardless of its location. NDN has some relevant advantages over IP. Firstly, the data identity is decoupled from its location, and hence, the data can be easily moved. Additionally, any node can reply to a data request if it has a copy of the desired data. This means that the NDN architecture natively provides transparent in-network caching for content providers. In addition, it separates consumer mobility from data transmission due to its consumer-driven interaction.

At the same time, there has been renewed interest in low Earth orbit (LEO) satellite networks to provide global Internet connectivity with low latency and high bandwidth. These new satellite networks can play an important role in multiple applications, such as fleet management, maritime or aeronautical tracking systems, and even in disaster relief, since they guarantee connectivity in remote areas where it is difficult or expensive to install ground infrastructure. Indeed, they can also be a complement to fifth generation (5G) networks, either as an additional radio access technology (RAT) or as a 5G core (5GC) backhaul; they will surely compete with large distance connectivity providers, such as submarine cable. SpaceX Starlink is currently the most advanced satellite Internet provider. As of July 2022, SpaceX Starlink has a fully operational constellation of nearly 2600 satellites and more than 500,000 estimated subscribers, and it has applied for permission to deploy up to 42,000 satellites [3]. Its strongest competitors are Amazon’s Project Kuiper, OneWeb, Telesat’s Lightspeed, Boeing and Kepler Communications, but SpaceX is the only corporation that already has a fully operational network.

The possibility of interconnecting LEO satellites through inter-satellite links (ISLs) will be one of the strongest advantages of these constellations, though this feature has not been used by commercial deployments yet. ISLs are laser links, also known as free space optical (FSO) links, that take advantage of vacuum conditions for lower latency, higher data rates, smaller antenna sizes, narrower beams and lower power requirements. The use of ISLs between neighboring satellites results in a grid topology that is particularly convenient for maintaining a well-structured satellite network, the core idea of the work in this paper.

At present, it is not clear which will be the networking design of these large constellations of LEO satellites, but the idea of using NDN in them is gradually gaining attention since this architecture is especially convenient for highly dynamic network environments [4,5]. Its strongest advantage over IP is the mobility management, which is one of the biggest challenges of LEO constellations, given the orbital speed of these satellites (LEO satellites need about 90 min to orbit the Earth [6]). Additionally, NDN provides a stateful forwarding plane with support for multicast transmission and inbuilt data caches, thus resulting in a more efficient usage of the installed transmission capacity.

The main goal of this paper is to contribute to unveil the possibilities that emerge from applying the NDN architecture to large LEO satellite constellations using ISLs. Some open problems in these networks are related with forwarding and routing. In NDN, the routing plane is in charge of obtaining available routes, while the forwarding plane and the strategy layer make decisions about the preference and usage of routes based on their performance/status. However, routing tables in NDN may consume more memory space and bandwidth in comparison to common IP routing tables [7].

In this paper, we propose a new location-based forwarding strategy for LEO satellite networks that takes advantage of the knowledge of the relative position of the satellites and the grid structure formed by the ISLs to perform the forwarding of NDN packets. So, forwarding at each node is done using only local information (node and destination locations), without the need of interchanging information between nodes, as is the case with conventional routing protocols.

Simulation results show that this forwarding strategy results in high network utilization when we try to use the highest available bandwidth for multiple flows between several consumers and a producer, and so, it is a good candidate to promote the adoption of the NDN architecture in LEO satellite networks.

This paper is organized as follows. Section 1 introduces the work in this paper. Section 2 is a review of the related work found in the literature. Section 3 describes the general architecture of an NDN network. Section 4 introduces the forwarding problem and presents our new GeoTag-based forwarding strategy. Section 5 evaluates the proposed solution. Finally, Section 6 presents some conclusions and future lines of research.

2. Related Work

The problem of routing in LEO satellite networks with ISLs has been widely addressed in the literature, and it is now commonly accepted that adaptive routing is an absolute requirement to optimize network utilization [8]. Thus, the work in [9] presents and evaluates different adaptive routing schemes in a constellation of LEO satellites, also in comparison to static routing. The most important conclusion in this work is that, although taking network load into account can improve both network utilization and QoS, it also makes the routing architecture more complex. Another relevant conclusion of this work is that isolated traffic adaptive routing (i.e., using only locally available information) is an interesting and efficient alternative to more complex distributed routing schemes.

However, the use of traffic adaptive routing schemes in regularly meshed networks with many alternative paths, as it is our case, may cause traffic load oscillations between alternative paths that are particularly inconvenient under heavy traffic load conditions [10]. For this reason, many works propose adaptive multipath routing mechanisms that implement load balancing [11,12,13,14]. Finally, Ref. [15] surveys other advanced routing algorithms, such as virtual topology routing and virtual node routing.

In the case of NDN, although there are many works about routing in NDN networks [16,17,18], to the best of our knowledge, there are only a few works addressing the problems related to NDN routing in LEO satellite networks. In particular, we have found only two works about this type of networks, and they are mainly focused on mobility management due to satellite handovers [19,20].

In this paper, we present a multipath location-based forwarding strategy that benefits from some NDN features to completely avoid the need of interchanging information between nodes, as is the case with conventional adaptive routing protocols in large LEO satellite networks (and so the scalability and load oscillation problems related to them). In particular, our forwarding strategy takes advantage of the knowledge of the relative positions of the satellites and the grid structure formed by the ISLs to choose the next-hop along a minimum-hop path. When several minimum-hop paths are possible at an NDN node, the next-hop is locally chosen randomly in order to provide the desired load balancing.

The work in [21] also proposes a location-based mechanism for IP-based LEO satellite networks that uses the geographical position of the destination to search for the satellite node serving it. However, this algorithm just chooses a single path to minimize the physical distance between the source and the destination, instead of choosing any path minimizing the number of hops between the edge nodes, as in our proposal. In relation to this, it is very important to note that a very recent work [22] demonstrated that all the shortest-distance paths belong to the set of minimum-hop paths in LEO constellations as long as the inclination is not too large (i.e., less than 68°) or, alternatively, the phasing offset is large enough.

3. NDN Architecture

The most distinctive feature of NDN is the use of names to identify data rather than locations. While IP names the network location of the host to send the message to, NDN names the content of the message itself, without specifying any location. In the NDN architecture, every data chunk has a name, and the network layer uses data names to communicate. NDN communication consists of a pull-based model, i.e., the receiver sends an Interest packet that contains the name of the requested data chunk, and fetches one Data packet back from either the original data producer, or from a node cache. A clear advantage of this architecture is that any node that has the requested data packet can reply to the interest, without needing an overlay solution that changes the addresses of the remote hosts, like in TCP/IP.

With respect to the forwarding of NDN packets, each NDN node maintains three data structures: the forwarding information base (FIB), the pending interest table (PIT) and the content store (CS). Thus, once an interest packet is received at an interface of an NDN node, the following procedure is executed:

• The NDN node checks the CS for a copy of the requested data. If there are matching data in the CS, they are sent following the reverse path of the interest packet.
• Otherwise, the NDN node searches the PIT to find any prior interest with the same name from a different input interface. If there is a matching PIT entry, the incoming interface is added to the list of incoming interfaces for that entry.
• In the case of no match, neither in the CS nor in the PIT, the NDN node inserts a new entry for the name of the interest packet into the PIT, and the interest forwarding strategy decides whether, when and where to forward the incoming interest, among all the possible outgoing interfaces, according to the FIB for a given name or, alternatively, using a forwarding hint. (When a name cannot be announced globally, the interest packet can carry the ISP that hosts the producer. That is referred to as a forwarding hint. So, when an NDN node does not find a matching prefix for the name in an interest packet, it uses the forwarding hint to forward it.)

Data packets follow the reverse path of their corresponding interest packets, hop by hop, to reach all the requesters. When a data packet arrives at an NDN node, it checks the PIT to get the incoming interfaces for that name, and sends a copy through every one of them. Then, that PIT entry is removed, and the NDN node optionally saves a copy of the data in its CS. The CS is optional and works like a cache, that is, it is used to store the most popular data chunks traversing the node. If no matching entry exists in the PIT, the data packet is dropped.

NDN networks can run routing protocols to announce the reachability of data names, like IP does with IP addresses. The FIB also works just like the traditional IP forwarding table, but using NDN names instead of IP prefixes. Routing protocols are usually responsible for populating the FIB with entries relating names to output interfaces.

4. GeoTag-Based Forwarding Strategy

As previously explained, an interest forwarding strategy is the logic that decides in each NDN node whether, when and where to forward an incoming interest, among all the possible outgoing interfaces, according to the FIB for a given name or, alternatively, a forwarding hint. Already existing strategies are the best route strategy, that follows the longest prefix match principle; the multicast strategy; and the self-learning strategy, which broadcasts interests for the first time to learn a single path toward data. In [23], the authors surveyed the main forwarding strategies proposed in the literature for NDN-based wireless networks.

In this paper, we propose a new location-based forwarding strategy for NDN-based LEO satellite networks that takes advantage of the knowledge of the relative position of the satellite nodes and the grid structure formed by the ISLs to perform the forwarding of the interest packets without the need of interchanging information between nodes, as is the case with conventional routing protocols. We consider the most common scenario where each satellite keeps four ISLs connected to its four immediate neighbors: two intra-plane ISLs with the immediate previous and next satellites in the same orbital plane, and two inter-plane ISLs with the closest satellites of both immediate adjacent planes, as shown in Figure 1. That is, for our purposes, we can consider the satellite network as a grid covering the Earth and, therefore, we propose to identify each satellite by two Cartesian coordinates. The horizontal coordinate represents the ordinal number of the orbital plane while the vertical one represents the number of the satellite within the orbital plane, as shown in Figure 2.

Ground nodes that generate interest packets are referred to as consumers, and ground nodes that have the original data are called producers, although recall that it is also possible to maintain copies at intermediate NDN node caches. Both consumer and producer ground nodes must choose periodically the best (closest) access satellite to connect to so that they direct their beams to only one satellite for upstream communication, whereas downstream messages come from only that satellite. However, the constant mobility of LEO satellites forces the ground nodes to perform a handover every five minutes approximately. As pointed out in [24], there are two alternatives to solve the producer mobility problem in NDN: either the mobile producer makes the data available at a reachable named location, or it reports constantly its point of attachment (PoA), that is, the address of the satellite to which it is connected to, similarly to how the DNS system works for IP. In this paper, we choose this second option and, thus, the PoA will be the two Cartesian coordinates of this satellite.

The NDNLPv2 (NDN Link Adaptation Protocol version 2) protocol [25] offers the possibility to send a GeoTag into the interest packets, that is, a predefined 3-byte header that is meant to carry Cartesian 3D coordinates (GPS coordinates, usually). We propose using the first two bytes to encode the orbital plane and the ordinal position within the orbital plane as two Cartesian coordinates, while the third remaining byte is reserved for possible future expansion. In this way, the consumer, using the name of the desired data, obtains the PoA of the satellite connected to the producer (i.e., its two Cartesian coordinates), and sends these coordinates into the GeoTag field of the corresponding interest packet. Then, it forwards this packet to its own access satellite.

When an incoming interest arrives at a satellite node and it must be forwarded, the forwarding strategy must choose one of the five possible next-hop interfaces contained in the FIB: the four ISL links to the neighboring satellites (port, starboard, bow and stern) and the link to the ground. For that, the GeoTag of the interest is analyzed as follows:

• If the GeoTag matches with the address of the satellite, then the interest is forwarded to ground.
• Otherwise, the interest must be forwarded to another satellite. The next-hop satellite is obtained based on its own coordinates and the coordinates included in the GeoTag, choosing as the best next hop the one with the closest index of the bi-dimensional address relative to its own address. That is, if the GeoTag of the consumer is $(x_{\mathrm{c}},y_{\mathrm{c}})$ and the GeoTag of the output satellite (connected to the producer) is $(x_{\mathrm{p}},y_{\mathrm{p}})$:

  -

  When $|x_{\mathrm{p}}-x_{\mathrm{c}}|>|y_{\mathrm{p}}-y_{\mathrm{c}}|$, the next hop is in the horizontal direction ⟹ The next-hop is the satellite on the starboard side if $x_{\mathrm{p}}>x_{\mathrm{c}}$, or the satellite on the port side if $x_{\mathrm{p}}<x_{\mathrm{c}}$.

  -

  When $|x_{\mathrm{p}}-x_{\mathrm{c}}|<|y_{\mathrm{p}}-y_{\mathrm{c}}|$, the next hop is in the vertical direction ⟹ The next-hop is the satellite on the bow if $y_{\mathrm{p}}>y_{\mathrm{c}}$, or the satellite on the stern if $y_{\mathrm{p}}<y_{\mathrm{c}}$.

  -

  When $|x_{\mathrm{p}}-x_{\mathrm{c}}|=|y_{\mathrm{p}}-y_{\mathrm{c}}|\ne 0⟹$ The direction of the next-hop (horizontal or vertical) is chosen randomly in order to provide load balancing.

Once the forwarder satellite has obtained the next hop satellite, it forwards the interest packet to it. Eventually, the interest packet will reach the producer, and this will deliver the data packet without the GeoTag, just following the PIT entries back to the consumers, as usual. It is obvious that if caches are used at the satellite nodes, data can be sent back to the consumers from an intermediate node without the need to reach the producer. It is also possible that there are several producers for a given name. In this case, the consumer will choose the exit satellite closest to its access satellite.

Note that, if we have a consumer with coordinates $(x_{\mathrm{c}},y_{\mathrm{c}})$ that obtains data from a producer with coordinates $(x_{\mathrm{p}},y_{\mathrm{p}})$, the problem is equivalent to that of routing interest packets along a grid from a source edge at $(0,0)$ to the destination edge at $(W,H)$, where $W=|x_{\mathrm{p}}-x_{\mathrm{c}}|$ and $H=|y_{\mathrm{p}}-y_{\mathrm{c}}|$. Clearly, any path between these edges chosen by our forwarding strategy will comprise a minimum number of hops, and this number is $W+H$. Without loss of generality, let us assume that $W\ge H$ ($H\ge W$). In this case, the path followed by the interest packet between the edges consists of $W-H$ movements to the right ($H-W$ upward movements) and then a random sequence of H (W) rightward movements and other H (W) upward movements in an arbitrary order.

As an example, Figure 3 shows the minimum-hop paths, represented with red (yellowish) lines, between a consumer at $(0,0)$ and two producers at $(5,3)$ and $(2,3)$.

We could slightly modify our strategy to use any other two disjoint minimum-hop paths, but as the number of consumers is much higher than the number of producers, load balancing is much more necessary close to the producers due to the aggregated data traffic from them. Moreover, close to the consumers, we prefer to use a single path in order to benefit from the eventual use of caches at the NDN nodes. In this way, our mechanism performs load balancing from the producer between the two paths around the diagonal, and then uses a single path to the consumers.

5. Results

We tested the proposed GeoTag-based forwarding strategy using ndnSIM [26], the open-source NS-3 module that implements the NDN communication model, and a new GeoTag-based forwarding strategy module we developed for it [27].

The LEO constellation was configured with 30 orbital planes of 30 satellites, an inclination angle of 60° and an altitude of 400 km. Regarding the positions of the ground nodes, we chose different longitudes between latitudes 35° and 45° since this area corresponds to a highly populated region in the Northern Hemisphere, where the proposed constellation should provide good coverage. However, for the longitude, we avoided differencing between land and sea masses to keep the scenario simple. Additionally, the tracking period was established to 20 s.

We simulated a variable number of consumers executing the ConsumerPcon application. With this application (analogous to iPerf [28] in TCP/IP), we can measure the network utilization since it implements a TCP-like congestion control algorithm that allows the flows between the consumers and the producer to use all the available bandwidth. Note that, in this scenario, the rate of interest packets issued per second is not fixed, but is constantly changed by the chosen window adaptation algorithm. We also configured the consumers to start sending the interest packets at different instants to prevent the synchronization of the window adaptation algorithms. Regarding the producer, it is configured to always reply to the interest packets with data packets of a fixed size (1050 bytes). Finally, to keep things simple, we configured all the links in the simulation experiments with the same capacity.

For testing the performance of our forwarding strategy, we firstly measured the percentage of bandwidth usage at the link from the producer to its satellite node. Each test comprises 10 random executions of the same scenario, applying a random position displacement to the ground nodes. Initially, we simulated a scenario where all the consumers send interests for the same data name from the producer.

Figure 4 shows the average link usage at the producer (with 95% confidence intervals) for 4, 8, 16 and 32 consumers. We can see that our forwarding strategy achieves an average link usage from the producer of 90% with 4 consumers, but this percentage decreases as the number of consumers increases, falling to 70% for 32 consumers. The reason for this decrease is that, as the number of consumers increases, the probability that a NDN node receives multiple interests for the same data increases. In this case, the satellite node will only forward one interest packet, thus saving some bandwidth at the producer since all these pending interests will be fulfilled with just a single data packet. Note that, under these conditions, the links to the consumers from their corresponding satellites will get fully utilized, while there is still spare capacity at the producer.

To illustrate this effect, we repeat the experiment, but this time, each consumer will request different data.

As expected, the results in Figure 5 show that the average link usage for 4 consumers is now slightly higher (94%). In addition, in this case, the link usage slightly increases with the number of consumers, reaching a value of 95% for 16 and 32 consumers, which is an excellent result for our Forwarding Strategy, despite the short periods of unavailability caused by the satellite handovers. (When a handover occurs at the consumer in the time between the original interest transmission and the reception of the corresponding data, the data do not reach the new satellite serving the consumer but the old one. This is because in an NDN network, data packets follow the reverse path recorded in the PIT tables by interest packets. For the purpose of this paper, we relied on the retransmission mechanism of the consumer application to overcome this issue with good enough results, although it is possible to devise a mechanism to overcome this problem as in [20].) The reason for the increase in the bandwidth usage with the number of consumers is caused by the sawtooth behavior of the TCP-like congestion avoidance algorithm. As the number of unsynchronized consumers increases, their aggregated demand grows smoother than their individual demands. This effect is also present when using regular TCP transmissions.

To take a closer look into the effects of interest aggregation at the forwarders, we represent in Figure 6 the normalized total number of bytes exchanged in the network (the total number of bytes was normalized by the maximum value obtained in all the simulation experiments) in the previous experiments, both for the case of consumers requesting the same named content and for different contents.

We can observe that more of the network capacity is used when consumers request the same content. This is expected since some traffic in shared links serves several consumers and, therefore, downstream links can carry more capacity. That is, a single packet at a shared link results in multiple copies when it reaches the consumers. We can also appreciate that the total traffic increases with the number of consumers in the same content case, as the opportunities for aggregating interest packets at the forwarders increase.

Finally, the effects of caching when requesting the same content can be seen in Figure 7.

As before, as the number of consumers increases, the amount of total data transmitted also augments. Even with the link from the producer saturated, the consumers can still get high throughput because their data copies do not have to travel from the producer itself. With no caches, this sharing is only due to the coalescing of interest packets. However, with active caching, the sharing also comes from copies of data previously forwarded by individual satellite nodes.

6. Conclusions

In this paper, we proposed a new location-based forwarding strategy that can be a very good candidate to enable the efficient and effective future use of the NDN architecture in LEO satellite networks. The proposed forwarding strategy takes advantage of the knowledge of the relative positions of the satellite nodes, together with the grid structure formed by the inter-satellite links, to perform the forwarding of the NDN interest packets without the need of interchanging information between nodes, as is the case with conventional adaptive routing protocols, thus avoiding the scalability problems related to them. In addition, our forwarding strategy performs load balancing from the producer between the two paths around the diagonal toward each consumer, and then uses a single path toward it. The reason to use this alternative is that load balancing is much more necessary close to the producers, while using a single path close to the consumers could benefit from the eventual use of caches at the NDN nodes.

The simulation experiments we have conducted show that the proposed forwarding strategy works properly, and it is able to achieve an average link usage at the producer of 95%. Moreover, our experiments show that an NDN-based constellation with our proposal makes even better use of network capacity when consumers request the same content from the producer. The usage improves even more if caches are deployed in the NDN nodes.