# Routing Heterogeneous Traffic
in Delay Tolerant Satellite Networks

Pablo G. Madoery1 Gunes Karabulut Kurt14 Halim Yanikomeroglu1 Peng Hu2 Khaled
Ahmed3 Guillaume Lamontagne3
1 Department of Systems and Computer Engineering, Carleton University, Ottawa,
ON K1S 5B6, Canada  2 National Research Council Canada  3 Satellite Systems,
MDA, Sainte-Anne-de-Bellevue, QC H9X 3R2, Canada  4 Poly-Grames Research
Center, Department of Electrical Engineering, Polytechnique Montréal,
Montréal, QC, Canada

###### Abstract

Delay Tolerant Networking (DTN) has been proposed as a new architecture to
provide efficient store-carry-and-forward data transport in satellite
networks. Since these networks relay on scheduled contact plans, the Contact
Graph Routing (CGR) algorithm can be used to optimize routing and data
delivery performance. However, in spite of the various improvements that have
been made to CGR, there have been no significant proposals to prioritize
traffic with different quality of service requirements. In this work we
propose adaptations to CGR that allow performance improvements when sending
traffic with different latency constraints, and develop a linear programming
optimization model that works as a performance upper bound. The simulation
results of the proposed schemes are promising and open the debate on other
ways to improve performance while meeting the particular needs of
heterogeneous traffic.

###### Index Terms:

Routing, Contact Graph Routing, QoS, satellite constellations, Delay Tolerant
Networks

##  I Introduction

Satellite networks are becoming increasingly popular as a means to provide
high quality imagery, video and communication services around the globe [1].
Efficient space-terrestrial communication technologies, capable of
successfully moving large volumes of data between space and ground, are a key
element in these networks. In this context, Delay Tolerant Networking (DTN)
has been identified as a novel approach that can meet this goal in a cost-
effective way by relaxing communication requirements and network
infrastructure usually assumed in traditional protocols. The DTN architecture,
originated from deep-space and interplanetary networking, embraces the concept
of occasionally-connected networks that may suffer from frequent partitions,
high delay, and that may be comprised of more than one divergent set of
protocols [2]. To this end, a bundle layer that exists at a layer above the
transport layers of the network, employs a persistent storage on each DTN node
to store-carry-and-forward data packets as transmission opportunities become
available.

In the case of satellite networks, the forthcoming episodes of communications
and their properties can be determined in advance based on orbital dynamics.
These types of deterministic DTNs are known as scheduled DTNs, and can take
advantage of a contact plan comprising the future network connectivity in
order to optimize routing and data forwarding. The Contact Graph Routing (CGR)
algorithm, described in [3], is the most developed solution for these
networks, and has been the subject of numerous contributions from the research
community. These contributions include source routing extensions [4], the
adaptation of Dijkstra [5], the prevention of routing loops and consideration
of multiple destinations [6, 7], the application of overbooking management
techniques [8, 9], and congestion mitigation techniques [10], route table
management strategies and the incorporation of Yen’s algorithm [11]. Also, the
development of adaptations to improve the scalability [12], the incorporation
of opportunistic [13] and probabilistic contacts [14], a spanning-tree
formulation to compute routes to several destinations [15], and a partial
queue information sharing [16], among many other contributions.

However, despite the great interest of the community, there have been no
significant proposals to adapt CGR in order to prioritize the delivery of
traffic that may have heterogeneous requirements in terms of quality of
service (QoS). Therefore, in this work our contribution is twofold: on the one
hand we propose adaptations to the way CGR chooses the best routes in order to
prioritize the traffic according to the required qualities of service
(particularly maximum latency), and on the other hand we model the problem
with a linear programming optimization model that provides us with a
performance bound.

The rest of the paper is organized as follows. In Section II we describe the
processes involved when routing in scheduled satellite networks, how CGR
carries out the different tasks, and adaptations to CGR that take into account
QoS requirements. In addition, we provide an optimal traffic flow model, and
an execution example comparing the behaviour of these 3 schemes in a
particular scenario. Then, in Section III we describe the simulation
environment and the results obtained with different performance metrics.
Finally, in Section IV we describe future lines of research and in Section V
we conclude the work by summarizing the main findings.

##  II Routing Schemes

###  II-A Routing in scheduled satellite networks

In delay tolerant satellite networks with planned communications, four
processes are usually involved in order to send traffic from the sources to
the destinations:

  * •

Planning: contact plans are determined by a central entity (a ground station
or a Mission Operation Center (MOC)) based on the estimation of future
episodes of communication. This task involves taking into account the physical
disposition and orientation of nodes through time, as well as their
communication system configuration (antenna, modulation, transmission power,
etc.). As a result, orbital propagators and communication models are combined
to determine a contact plan which can be further tuned to reduce energy
consumption or remove conflicting contacts. Then, this contact plan is
distributed to satellites in order to run routing processes in a distributed
manner when traffic is generated or received by different satellites in the
network.

  * •

Routing: each satellite uses the contact plan as an input in order to build a
routing table. Unlike stable networks such as the Internet, where each route
can be thought of as a sequence of nodes, here each route is constructed as a
sequence of temporary contacts. Therefore, these routes have associated times
during which they remain valid (they are no longer valid when one of their
contacts ends). Other attributes that can be calculated for these routes are
the delivery time, number of hops / contacts, remaining capacity, etc.

  * •

Forwarding: When traffic is generated or received at a satellite, it consults
its routing table, performs a filtering of those routes that remain being
valid and chooses the one that optimizes a metric that is usually delivery
time. Then, by using the information associated with the chosen route, it
proceeds to put the traffic in a queue associated with a given neighbor node.

  * •

Transmission: Finally, when contacts occur between satellites, the enqueued
traffic is then transmitted in a particular order.

###  II-B Contact Graph Routing (CGR)

As explained in [3] and summarized here for completeness, CGR is an algorithm
that runs in a distributed fashion on different satellites in order to first
build a routing table (routing process) and then select routes to enqueue
traffic (forwarding process).

In order to construct the route table, it starts from the contact plan
received as input, and builds a structure called contact graph, where the
vertices correspond to contacts, while the arcs correspond to data retention
events in a satellite. Although not so intuitive, the use of this static
structure facilitates the execution of route search algorithms in a topology
that is actually time-varying. By using this contact graph structure, the
search process itself is an adapted version of Dijkstra that explores the
different contacts (nodes in the contact graph) and ends up selecting those
whose sequence determines the optimal route in terms of earliest delivery time
to destination. Here we will refer to this scheme as CGR-DelTime for
comparison purposes. Furthermore, since routes have a deadline, and they also
have a limited capacity, CGR does not compute only 1 route to a destination,
but computes the K best routes using Lawler’s modification of Yen’s algorithm.

Then, in a second stage, during the forwarding process, CGR start from a
packet and the routing table built in the previous step, it filters the routes
that are no longer valid or that have consumed their capacity, and selects the
best route according to the earliest deliver time metric. After making some
annotations of the consumed capacity of the route, this second step is
repeated for each new packet that needs to be forwarded.

###  II-C Contact Graph Routing Adaptation

One thing to note here is that CGR already takes into account the time-to-live
($ttl$) of a packet when filtering the routes, and proceeds to ignore those
routes that have a projected delivery time later than what is required.
However, by choosing a route that is strictly better in terms of delivery
time, it is possible that a route with many contacts (hops) will be chosen and
that these contacts will also have to send traffic generated by other nodes.
Therefore, this can lead to a congestion situation where the route chosen by
CGR cannot be honored by downstream nodes, and where the traffic will not be
able to reach the destination in the required time.

In order to try to avoid this situation, we will consider in this work an
adaptation to CGR in the forwarding stage. In particular, this new scheme
called CGR-Hops will continue filtering those routes that fail to deliver a
packet in the required time, as the original CGR-DelTime scheme, but it will
then choose as the best route the one in which the number of hops is the
smallest. The expectation is that this scheme will make decisions that relieve
congestion by using fewer hops, and that this congestion relief will serve to
leave capacity to the traffic that needs to arrive earlier.

###  II-D Optimal Traffic Flow Model

In order to compare different routing strategies, it is useful to have an
optimization model that, although it cannot be applied in realistic networks
due to computational complexity, serves as a performance upper bound to
compare the proposed schemes in smaller networks.

The problem of optimally routing multiple traffics is known in the literature
as multi-commodity flow [17]. In the context of DTN networks, the works [18,
19, 20] presented linear programming models that allow solving this problem in
networks with intermittent and scheduled communications. Here, we will
describe a new version of these models tailored to our particular needs and
extended to consider traffics with different quality of service in terms of
latency.

####  II-D1 Coefficients and Decision Variables

The topology is discretized into $K$ states, where each state $k_{q}\in K$
represents the network during a time interval $[t_{q-1},t_{q}]$. Thus, the
network is defined by $k_{1},...,k_{q},...k_{f}$ states, which correspond to
time intervals $[t_{0},t_{1}],...,[t_{q-1},t_{q}],...,[t_{f-1},t_{f}]$. Within
each state $k_{q}$, the network is represented by a graph $G_{k_{q}}$ whose
vertices $v\in V$ correspond to nodes and whose arcs $e\in E_{k_{q}}$
correspond to communication opportunities (contacts) between nodes in $k_{q}$.
The notation $c_{e}$ represents the capacity in number of packets that can be
sent from the source node to the destination node of an arc $e$ during one
state $k_{q}$. In addition, we represent the number of packets that can be
stored in node $v$ buffer as $b_{v}$. In order to use a compact notation we
will call $I^{v}$ the set of arcs $e$ entering a node $v$, while we will call
$O^{v}$ the set of arcs leaving it. Additionally $D$ constitutes the set of
all the traffic demands $d_{t_{q},ttl}^{y,z}$ generated at time $t_{q}$ from
node $y$ to node $z$ with time-to-live $ttl$. We assume in general that all
traffic demands are generated at the beginning of some state. If this is not
the case, it is always possible to add a new intermediate state to contemplate
the generation of such traffic. On the other hand, within the output
variables, $X_{e}^{y,z}$ constitutes the number of packets of traffic $y,z$
that are sent on arc $e$, while the variable $B_{v,t_{q}}^{y,z}$ is the number
of packets of traffic $y,z$ stored at node $v$ at time $t_{q}$. We summarize
these model parameters in Table I.

TABLE I: Optimal Traffic Flow Model Parameters Input Coefficients
---
$t_{q}\in T$ | Timestamps
$k_{q}=[t_{q}-1,t_{q}]\in K$ | States (Time intervals)
$v\in V$ | Nodes
$e\in E_{k_{q}}$ | Arcs of a graph in state $k_{q}$
$c_{e}$ | Capacity of arc $e$
$b_{v}$ | Capacity of buffer’s node $v$
$d_{t_{q},ttl}^{y,z}\in D$ |  | Traffic from node $y$ to node $z$
---
originated at timestamp $t_{q}$
with time-to-live $ttl$
Output Variables
$\\{X_{e}^{y,z}\\}$ |  | Traffic from node $y$ to node $z$
---
sent in arc $e$
$\\{B_{t_{q},v}^{y,z}\\}$ |  | Buffer occupancy of node $v$
---
at timestamp $t_{q}$ by traffic $y,z$

####  II-D2 Objective Function and Constraints

Taking into account the coefficients and decision variables defined, we link
them by means of the objective function defined in (1) subject to the
constraints (2) to (7).

$\displaystyle\textrm{minimize:}\quad\sum\limits_{k_{q}\in K}\sum\limits_{e\in
E_{k_{q}}}\sum\limits_{y\in V}\sum\limits_{z\in V}w(k_{q})*X_{e}^{y,z}$ (1)

Subject to:

$B_{t_{q},v}^{y,z}=\begin{cases}B_{t_{q-1},v}^{y,z}+\sum\limits_{e\in
I^{v}}X_{e}^{y,z}-\sum\limits_{e\in
O^{v}}X_{e}^{y,z}+d_{t_{q},ttl}^{y,z}&\text{if $y=v$}\\\
B_{t_{q-1},v}^{y,z}+\sum\limits_{e\in I^{v}}X_{e}^{y,z}-\sum\limits_{e\in
O^{v}}X_{e}^{y,z}&\text{if $y\neq v$}\end{cases}$ (2)
$\displaystyle\sum\limits_{y\in V}\sum\limits_{z\in V}B_{t_{q},v}^{y,z}$
$\displaystyle<=b_{v}\quad\forall\;t_{q},v$ (3)
$\displaystyle\sum\limits_{y\in V}\sum\limits_{z\in V}X_{e}^{y,z}$
$\displaystyle<=c_{e}\quad\forall\;k_{q},e$ (4)
$B_{t_{0},v}^{y,z}=\begin{cases}d_{t0,ttl}^{y,z}&\text{if $y=v$}\\\ \quad
0&\text{if $y\neq v$}\end{cases}\quad\forall\;v,y,z$ (5)
$B_{t_{q},v}^{y,z}>=\begin{cases}d_{t_{q},ttl}^{y,z}&\text{if $y=v$}\\\ \quad
0&\text{if $y\neq v$}\end{cases}\quad\forall\;t_{0}<t_{q},v,y,z$ (6)
$B_{t_{f},v}^{y,z}=\begin{cases}\sum\limits_{t_{q}\in
T}d_{t_{q},ttl}^{y,z}&\text{if $z=v$}\\\ \quad 0&\text{if $z\neq
v$}\end{cases}\quad\forall\;v,y,z$ (7)

A linear programming model is thus formed whose input consists of a set of
traffics ($d_{t_{q}}^{y,z}$) to be sent from sources ($y$) to destinations
($z$), with maximum latency requirements ($ttl$), through a time-varying
topology, with buffer capacities ($b_{v}$) and transmission capacities
($c_{e}$), and whose output consists of the optimal flows ($X_{e}^{y,z}$) to
be followed by the different traffics.

The objective function defined in (1) seeks to minimize the sum of the
products $w(k_{q})*X_{e}^{y,z}$, where $w(k_{q})$ is a weighting function that
assigns an increasing weight to each state. Thus, the higher the increment
caused by $w$, the higher the cost of using later arcs in time, i.e.,
minimizing the product prioritizes delivering traffic as soon as possible. On
the other hand, the lower the increasing cost of $w$, the more importance is
given to using as few arcs as possible.

With respect to the constraints, equation (2) defines the buffer occupancy of
each node ($v$) at each timestamp ($t_{q}$) taking into account the state at
the previous timestamp ($t_{q-1}$), the incoming ($e\in I^{v}$) and outgoing
($e\in O^{v}$) flows in the interval $[t_{q-1},t_{q}]$, and the traffic
generated at $t_{q}$ ($d_{t_{q},ttl}^{y,z}$). In turn, equation (3) limits the
buffer occupancy ($B_{t_{q},v}^{y,z}$) of each node according to $b_{v}$,
while equation (4) limits the amount of traffic that can flow through each arc
($X_{e}^{y,z}$) according to $c_{e}$.

In addition, the constraint (5) establishes the buffers at the initial
timestamp ($t_{0}$), while the constraint (6) ensures that traffics generated
in intermediate states are not sent in earlier states. This constraint also
ensures that traffics that have a maximum latency constraint ($ttl$) arrive at
their destinations on time and remain there until the final state. Finally,
equation (7) ensures that all $y,z$ traffics generated over time ultimately
reside in their corresponding buffers at the destination nodes
($B_{t_{f},v}^{y,z}$).

###  II-E Execution Example

(a) Topology, traffic and routes

(b) CGR-DelTime traffic flow

(c) LP Model and CGR-Hops traffic flow

Figure 1: Example of execution of different routing schemes

In order to intuitively understand the behavior of the different routing
schemes, we propose to analyze a simple example where 3 nodes ($N1$, $N2$,
$N3$) have 3 contacts in different states as shown in Figure 1(a).

The dotted lines represent contacts with the capacity to send 10 packets each.
Both nodes $N1$ and $N2$ generate 10 packets in state $k1$ destined for $N3$
(enclosed in squares). The traffic generated in $N1$ has a $ttl$ of 30
seconds, so it must reach its destination in state $k3$ or earlier, while the
traffic generated in $N2$ has a $ttl$ of 20 seconds, so it must reach
destination in state $k2$ or earlier. Regarding routes (represented as solid
blue lines), $N1$ is able to find routes $R1$ and $R3$ to reach node $N3$,
while $N2$ is able to find the route $R2$.

In Figure 1(b), we observe the behavior of CGR-DelTime where traffic
transmissions are represented with colored solid lines. Here, N1 calculates
and sends the traffic trying to use the route $R1$, however, when the 10
packets arrive at $N2$, they find an unforeseen situation: $N2$ also has
traffic for $N3$ and needs to use the full capacity of the $N2-N3$ contact.
This generates a situation of congestion that causes in turn that the 10
packets of $N1$ cannot reach $N3$ in the required time. On the other hand, the
$N2$ traffic does reach $N3$ on time by using the route $R2$.

Finally, Figure 1(c) shows the behavior obtained both with CGR-Hops and with
the LP Model. Here, although CGR-Hops is aware that route $R1$ delivers the
packets earlier, it chooses route $R3$ which, in addition to delivering the
packets on time ($ttl=30$), uses fewer hops. This congestion avoidance effect
obtained by both the LP Model and CGR-Hops leads to more QoS compliant traffic
flows and makes it possible for all traffic to reach its destination on time.
The difference between the LP Model and CGR-Hops in this case is that the LP
Model needed and used global knowledge of the topology and the traffics to be
generated, while CGR-Hops was able to have a similar behavior without knowing
the traffic generated in other nodes of the network.

In order to assess whether this approach is promising, we proceed to evaluate
and analyze whether this type of behavior continues to occur in more complex
cases.

##  III Evaluation

To compare the performance of different routing schemes, we have adapted and
extended Dtnsim. DtnSim is a discrete event-driven simulator developed in the
Omnet++ framework, presented in [21] and made available to be used as free
software111Public DtnSim repository: https://bitbucket.org/lcd-unc-ar/dtnsim.

By using Dtnsim, we have generated 25 random network topologies of 100s
divided in 10 states of 10s. Each topology captures the time-varying
connectivity among 11 nodes, where the first 10 nodes represent satellites,
while node 11 represents a ground station. The connectivity between nodes is
based on a contact density parameter $\delta$ which can take values between
0.0 and 1.0. A network with $\delta$ = 1.0 is fully connected with contacts
present in all states, while $\delta$ = 0 implies no contacts exist at all. We
have considered $\delta=0.2$ for the cases under study. The effect of
increasing $\delta$ is that higher values of traffic generation are needed to
observe the same congestion and performance degradation. Each arc has a
capacity to send 10 traffic packets while there is no limit to the storage
capacity at the nodes.

In order to generate congestion situations, we have set up an all-to-one
traffic pattern in which all 10 nodes generate a variable traffic load
destined to node 11. In particular, nodes 1 to 5 generate packets that do not
have a maximum latency requirement ($ttl$), so they can arrive at their
destination at any state, while nodes 6 to 10 generate packets that have a
maximum latency requirement of 20 seconds, so they must arrive at the
destination in the first state (k=1) or the second state (k=2).

The choice of these parameters has been made in such a way that heterogeneous
traffic must be routed, that congestion is eventually provoked, and that the
packets have a chance to reach their destination before the end of the
simulation.

Figure 2: Simulation results

We compare the performance of CGR-DelTime, CGR-Hops, and the LP Model
described in section II. In particular, we analyze the following metrics:

  * •

Delivery ratio: total number of packets generated divided by the total number
of packets arriving at destination that meet their specified maximum latency.

  * •

Mean hops per packet: total number of transmissions of all packets divided by
the total number of packets arriving at destination that meet their specified
maximum latency.

  * •

Mean delay per packet: average latency with which packets are delivered to the
destination meeting their specified maximum latency.

  * •

Energy efficiency: total number of packets arriving at destination that meet
their specified maximum latency divided by the total number of transmissions
of all packets.

As it can be seen in Figure 2, regardless of the traffic load, the LP Model is
able to deliver all generated packets to the destination node while meeting
the maximum latency requirement imposed on each packet. On the other hand,
CGR-DelTime shows a delivery ratio that decreases as the traffic load
increases. This is because the congestion generated starts to prevent the
delivery of traffic to the destination. It should be highlighted that when a
packet cannot be sent to its destination on time, CGR deletes that packet.
Finally, although CGR-Hops also experiences a decrease in delivery ratio as
the traffic load increases, this decrease is smaller due to the better
congestion avoidance capability of this scheme.

Furthermore, CGR-Hops shows a favorable performance in terms of the average
number of hops per packet because it chooses routes with fewer hops. In this
case, the LP Model uses a higher number of hops per packet because, in
addition to being constrained to comply with maximum latencies, it seeks to
deliver packets as soon as possible regardless of whether it must use more
hops to do so. The decreasing trend as the traffic load increases is explained
by the fact that when congestion increases, the model starts to give up
sending traffic in the first states and use later states with shorter routes.

Energy efficiency can be interpreted in our case as how many packets are
successfully delivered to destination with each transmission. It is the
inverse of the mean hops per packet metric although it has the advantage of
being limited in range between 0 and 1. It can be seen here that CGR-Hops is
the most efficient scheme and that the LP Model lies between CGR-DelTime and
CGR-Hops. The explanation as to why the model is not the most efficient here
lies in the fact that the model seeks to deliver traffic as quickly as
possible and ends up using many arcs in the early states before moving on to
using arcs in later states. In contrast, CGR-Hops proceeds to use routes with
fewer hops as long as those routes meet the maximum latency requirement.

Finally, the LP Model obtains the best metric in terms of delay per packet
followed by CGR-DelTime and then by CGR-Hops. It is worth noting 2 points
here: on the one hand, this metric is encompassing all generated packets
regardless of their maximum required latency. If the average delay is
calculated separately for each type of traffic we can expect the average delay
per packet to be lower for traffics with lower $ttl$ values. On the other
hand, this metric is calculated only on the delivered packets that meet the
maximum required latency, so it should be noted that these schemes are not
directly comparable if the delivery ratio is different as in this case.

In general, the effect that CGR-Hops ends up achieving is to delay traffic
that can be delayed, thus relieving congestion, and allowing traffic that need
to be delivered earlier to reach its destination on time.

##  IV Future work

As future work we envision further modifications to CGR to achieve even better
performance. In particular:

  * •

load balancing: if all nodes always use the shortest routes, it is likely that
the different routes will share more links, generating a bottleneck in terms
of capacity (congestion). The proposal then is not to use only the shortest
routes, but that a node can perform a load-balancing by round-robin on the K
best routes.

  * •

centrality: in graph theory, the centrality metric is related to how many
routes pass through a link or node. The idea here would be to use routes
through links or nodes that do not have the highest centrality, trying to
avoid congestion.

  * •

machine learning: the proposal here is to use machine learning models to
estimate the congestion that may exist on a link or node at a given time, and
then use these estimates to carry out the routing seeking to avoid those
routes more congested but without underutilizing them.

##  V Conclusion

In this work we have proposed and evaluated an adaptation to CGR to improve
performance when sending traffic with different maximum latency requirements.
The results show that the current capability of CGR to honor latency
requirements is limited because it uses only local traffic information, and
strictly chooses routes that optimize the expected delivery time without
considering the number of hops involved. However, these decisions do not take
into account that intermediate nodes can also generate traffic producing
congestion situations that prevent the effective fulfillment of latency
requirements. On the other hand, the proposed adaptation selects, within the
routes that meet the maximum latency requirements, those that have fewer hops.
This allows to alleviate congestion and increase the number of packets that
are delivered on time.

## Acknowledgments

This work has been supported in part by the National Research Council Canada’s
(NRC) High Throughput Secure Networks program within the Optical Satellite
Communications Consortium Canada (OSC) framework

## References

  * [1] J. Alvarez and B. Walls, “Constellations, clusters, and communication technology: Expanding small satellite access to space,” in _2016 IEEE Aerospace Conference_ , March 2016, pp. 1–11.
  * [2] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, “Delay-tolerant networking architecture,” Internet Requests for Comments, RFC Editor, RFC 4838, April 2007.
  * [3] J. A. Fraire, O. De Jonckère, and S. C. Burleigh, “Routing in the space internet: A contact graph routing tutorial,” _Journal of Network and Computer Applications_ , vol. 174, p. 102884, 2021.
  * [4] J. Edward, “Improving graph-based overlay routing in delay tolerant networks,” _IEEE Wireless Days_ , 2011.
  * [5] J. Segui, E. Jennings, and S. Burleigh, “Enhancing contact graph routing for delay tolerant space networking,” in _IEEE Global Telecommunications Conference_ , 2011, pp. 1–6.
  * [6] E. Birrane, S. Burleigh, and N. Kasch, “Analysis of the contact graph routing algorithm: Bounding interplanetary paths,” _Acta Astronautica_ , vol. 75, pp. 108–119, 2012.
  * [7] C. Caini, G. M. De Cola, and L. Persampieri, “Schedule-aware bundle routing: Analysis and enhancements,” _International Journal of Satellite Communications and Networking_ , vol. 39, no. 3, pp. 237–249, 2021.
  * [8] N. Bezirgiannidis, C. Caini, D. P. Montenero, M. Ruggieri, and V. Tsaoussidis, “Contact graph routing enhancements for delay tolerant space communications,” in _7th IEEE advanced satellite multimedia systems conference and the 13th signal processing for space communications workshop (ASMS/SPSC)_ , 2014, pp. 17–23.
  * [9] N. Bezirgiannidis, C. Caini, and V. Tsaoussidis, “Analysis of contact graph routing enhancements for dtn space communications,” _International Journal of Satellite Communications and Networking_ , vol. 34, no. 5, pp. 695–709, 2016.
  * [10] P. G. Madoery, J. A. Fraire, and J. M. Finochietto, “Congestion management techniques for disruption-tolerant satellite networks,” _International Journal of Satellite Communications and Networking_ , vol. 36, no. 2, pp. 165–178, 2018.
  * [11] J. A. Fraire, P. G. Madoery, A. Charif, and J. M. Finochietto, “On route table computation strategies in delay-tolerant satellite networks,” _Ad Hoc Networks_ , vol. 80, pp. 31–40, 2018.
  * [12] P. G. Madoery, J. A. Fraire, F. D. Raverta, J. M. Finochietto, and S. C. Burleigh, “Managing routing scalability in space DTNs,” in _6th IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE)_ , 2018, pp. 177–182.
  * [13] S. Burleigh, C. Caini, J. J. Messina, and M. Rodolfi, “Toward a unified routing framework for delay-tolerant networking,” in _IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE)_ , 2016, pp. 82–86.
  * [14] F. D. Raverta, J. A. Fraire, P. G. Madoery, R. A. Demasi, J. M. Finochietto, and P. R. D’Argenio, “Routing in delay-tolerant networks under uncertain contact plans,” _Ad Hoc Networks_ , vol. 123, p. 102663, 2021.
  * [15] O. De Jonckère, “Efficient contact graph routing algorithms for unicast and multicast bundles,” in _IEEE International Conference on Space Mission Challenges for Information Technology (SMC-IT)_ , 2019, pp. 87–94.
  * [16] S. Dhara, C. Goel, R. Datta, and S. Ghose, “CGR-SPI: A new enhanced contact graph routing for multi-source data communication in deep space network,” in _IEEE International Conference on Space Mission Challenges for Information Technology (SMC-IT)_ , 2019, pp. 33–40.
  * [17] T. C. Hu, “Multi-commodity network flows,” _Oper. Res._ , vol. 11, no. 3, pp. 344–360, Jun. 1963.
  * [18] S. Jain, K. Fall, and R. Patra, “Routing in a delay tolerant network,” in _Proceedings of the 2004 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications_ , ser. SIGCOMM ’04. New York, NY, USA: ACM, 2004, pp. 145–158.
  * [19] J. Alonso and K. Fall, “A linear programming formulation of flows over time with piecewise constant capacity and transit times,” Tech. Rep., 2003.
  * [20] J. A. Fraire, P. G. Madoery, and J. M. Finochietto, “Traffic-aware contact plan design for disruption-tolerant space sensor networks,” _Ad Hoc Networks_ , vol. 47, pp. 41 – 52, 2016.
  * [21] J. A. Fraire, P. G. Madoery, F. Raverta, J. M. Finochietto, and R. Velazco, “Dtnsim: Bridging the gap between simulation and implementation of space-terrestrial dtns,” in _Space Mission Challenges for Information Technology (SMC-IT), 2017 IEEE Int. Conference on_ , Sept 2017.