# A-SABR: The Adaptive Library for Schedule-Aware Bundle Routing

Olivier de Jonckère, Longrui Ma, Juan A Fraire

► To cite this version:

Olivier de Jonckère, Longrui Ma, Juan A Fraire. A-SABR: The Adaptive Library for Schedule-Aware Bundle Routing. WiSEE 2025 - IEEE International Conference on Wireless for Space and Extreme Environments, Oct 2025, Halifax, Canada. hal-05301072

HAL Id: hal-05301072

https://hal.science/hal-05301072v1

Submitted on 7 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A-SABR: The Adaptive Library for Schedule-Aware Bundle Routing

Olivier De Jonckère*, Longrui Ma†, Juan A. Fraire†‡,

*LIRMM, Université de Montpellier, France

†Inria, INSA Lyon, CITI, UR3720, 69621 Villeurbanne, France

‡CONICET - Universidad Nacional de Córdoba, Argentina

**Abstract**—Deep space communications face long delays and disruptions, making Delay-Tolerant Networking (DTN) and specialized routing essential. To address this, the CCSDS published the Schedule-Aware Bundle Routing (SABR) standard, built on the Contact Graph Routing (CGR) algorithm. Yet, over a decade of CGR development has introduced complexity and fragmentation, hindering prototyping and benchmarking.

This paper presents the Adaptive Library for Schedule-Aware Bundle Routing (A-SABR), an extensible Rust-based library for research and operations involving SABR/CGR. A-SABR supports rapid development and evaluation of routing strategies through a safe, modular design, and includes a broad set of existing CGR variants. It bridges the gap between flexible prototyping and reliable benchmarking, accelerating innovation in DTN routing. To illustrate its adaptability, we introduce new methods developed with A-SABR: a routing algorithm stamped VolCgr (Volume-CGR), a shortest-path-tree-based pathfinding for contact graphs, and additional options for volume management.

***Index Terms***—Contact Graph Routing, Delay-Tolerant Networks, Schedule-Aware Bundle Routing

## I. INTRODUCTION

Delay-Tolerant Networking (DTN) technologies are increasingly central to the future of space communications [1]. Deep space missions must contend with long propagation delays, frequent disruptions, and low data rates due to vast interplanetary distances and the dynamic nature of link availability. Recognizing this, the Interagency Operations Advisory Group (IOAG) underscores the necessity of DTN capabilities for most surface and orbital nodes [2]. This emphasis is mirrored in key initiatives such as NASA's Lunar Communication and Navigation System (LCRNS) [3], ESA's Moonlight [4], and the joint NASA-ESA LunaNet Interoperability Specification [5].

At the core of DTN lies the Bundle Protocol (BP) [6], [7], designed to support large data units (bundles) using a store-and-forward approach. BP enables asynchronous, hop-by-hop communication across heterogeneous networks without requiring continuous connectivity, functioning as an overlay protocol well-suited for the disrupted environments of space.

Space communications are shaped by deterministic yet intermittent link availabilities due to orbital mechanics and environmental occlusions. DTN models these opportunities through the concept of *contacts*—unidirectional intervals defined by start/end times, link delays, and nominal data rates.

Routing in DTNs departs fundamentally from Internet paradigms, requiring temporal planning across scheduled, time-varying links. Contact Graph Routing (CGR) [8], [9],

which underpins the Schedule-Aware Bundle Routing (SABR) standard [10], was first introduced in the NASA JPL's Interplanetary Overlay Network (ION) stack [11]. It enables autonomous routing based on a known contact plan [12], [13], relying on a modified Dijkstra algorithm and Yen's K-shortest paths to find routes with sufficient volume and earliest delivery.

However, CGR presents notable challenges. Its high computational complexity has raised scalability concerns [14], [15], [16], [17], spurring ongoing research into improved pathfinding [18], [16], [19], [8] and volume management [20], [21], [22]. These aspects are deeply interdependent [23], complicating modular development and testing. Moreover, CGR implementations often require integration with the local bundle protocol agent, for example, to compute earliest transmission opportunities based on local transmission queues.

The tension between theoretical flexibility and operational robustness further complicates CGR development. While operational environments demand high performance, memory safety, and strict error handling, research benefits from modular, generic architectures for benchmarking and innovation. This divergence has led to two predominant research approaches. First with emulation, where CGR modifications are embedded within bundle protocol implementations [21]. This method yields accurate performance insights under realistic conditions but hinders fair benchmarking and scalability analysis. Secondly with simulations, where CGR variants are evaluated in dedicated simulators [24], [25]. Simulations offer greater flexibility and accessibility but often lack computational realism and impede technology readiness advancement.

Despite over 15 years of collaborative progress, these structural limitations persist. During the 2024 Space-Terrestrial Internetworking (STINT) Workshop, Roy Gladden—manager of the Mars relay network—highlighted CGR as one of the key open challenges in DTN evolution.

***Contribution:*** To address these limitations, we introduce the Adaptive Library for Schedule-Aware Bundle Routing (A-SABR): a modular, Rust-based framework that decouples CGR into independently swappable components. A-SABR includes new approaches for pathfinding and routing, spearheaded by VolCgr (Volume-CGR), a new CGR variant that outperforms its previous competitors. It adheres to modern memory safety and performance standards, including those recommended by the 2024 U.S. Executive Order on software memory safety [26]. By providing a robust, extensible
platform, A-SABR enables the DTN research community to systematically explore trade-offs and design variants in CGR development—while also bridging the gap toward operational deployment.

*Organization:* The remainder of this paper is organized as follows: section II presents the details of SABR & CGR. Section III will present our library model, and section IV will propose a networking and processing evaluation. Last but not least, we will provide our conclusions and future work items.

## II. BACKGROUND

### A. CGR and SABR

The Schedule-Aware Bundle Routing (SABR) standard specifies how to select the best route from a set of candidates based on metrics like earliest delivery and available volume. It defines the selection logic in detail but assumes that candidate routes are already available, without specifying how they are computed.

Contact Graph Routing (CGR), implemented in NASA's ION stack, fills this gap by computing routes over time-varying contact plans. It builds a time-expanded graph and uses modified shortest-path algorithms to find viable paths, considering both timing and volume constraints.

In practice, SABR and CGR are tightly coupled—SABR being the reference document, and CGR its implementation. This integrated use, often referred to as SABR/CGR, blends standard definitions with implementation-specific logic, making it difficult to isolate or replace individual components without affecting the whole system.

### B. Routing Procedure Overview

The DTN equivalent of an IP route (the next address) is referred to as the *first hop contact* of a route. In the context of SABR/CGR, a *route* is the complete list of subsequent contacts between a source and a destination. We will consider 3 main procedures to create/select/update DTN routes:

* **Route Computation Procedure (RCP):** the main loop of Yen's algorithm. The RCP computes the next route, derived from the last found route [27], and inserts it in the routing table. Routes are constructed for an abstract bundle of size 0 and priorities are ignored.

* **Route Selection Procedure (RSP):** the entry-point for bundle forwarding, iterates over the routes in the destination's routing table to identify the best candidate route. If no routes are suitable, new routes are computed thanks to the RCP until a suitable route is found.

* **Route Update Procedure (RUP):** Once selected by the RSP, the volumes of the route contacts are updated in accordance with the bundle size (and priority for BPv6 [28]).

Although the terminology may differ, the details of the RCP, RSP, and RUP procedures were extensively described in [8].

Please note that the best *candidate/selected* route is not necessarily the best *existing* route. Indeed, Dijkstra's inaccuracies and the policy not to recompute routes until the routing table does not present suitable routes may lead to sub-optimal selection, [17].

Other limitations like the use of Yen can impact the stability of the algorithm [14], but will not be covered in this paper.

### C. Volume management

Volume/contact management involves maintaining a record of residual contact capacities based on previous scheduling activity. This local state is used to enhance the efficiency and accuracy of future routing decisions.

CGR/SABR includes 2 main volume management techniques.

a) *Earliest Transmission Opportunity (ETO):* ETO [20] is applicable to the first hops contacts, its characteristics and limitations were covered in [22]. ETO computes the earliest bundle transmission time depending on the local transmission queue.

b) *Effective Volume Limit (EVL):* EVL (from SABR) records the residual volume of individual contacts for filtering (RSP) and updates (RUP).

Although volume management is not involved in the RCP, it remains central in the logic of the RSP and the RUP. Including volume management in the RCP is a serious option in order to drop Yen's algorithm, as described in, and is the base mechanism of SPSN [17] and VolCgr, introduced in this paper. This construction approach will be referred to as bundle-aware.

## III. THE A-SABR LIBRARY

A-SABR was developed to reconcile the needs of DTN researchers and implementers by overcoming structural limitations of traditional CGR. Implemented in Rust, it benefits from memory safety, high-level abstractions, and high performance.

A-SABR reduces software complexity through a modular, compile-time configurable framework. Its architecture separates concerns across routing subdomains—pathfinding, resource management, contact plan parsing, path storage, and routing logic. Each component can be independently extended or replaced, supporting precise benchmarking and rapid prototyping.

It is compatible with contact plan formats from tools like ION [11] and dtn-tvg-util [29], while also introducing a format that enables per-node and per-contact resource policies—avoiding the uniform strategies of typical implementations.

The following sections detail A-SABR's architecture, components, and interfaces.

### A. Software Paradigm

Reducing the coupling for more flexibility (e.g. with polymorphism or control flow) can deteriorate the performance. To allow A-SABR to be suitable for operations, flexibility must be resolved at compile time to increase the performance. While not mentioned in the following sections, the library heavily relies on metaprogramming with templates, macros, and compilation features to drop any unnecessary overhead for a given routing algorithm. Some capabilities will be
highlighted by redirecting to examples directly available on
our GitHub repository<fnref n="1" />.

## B. Topology Model

A-SABR's contacts are stored in a *Multigraph*, as introduced in [18] and later in [16]. As a recall, maximal performance requires three levels to store the contacts. The first level being an *O*(1) access to a given transmitter. The second level allowing fast iteration over the receivers of a given transmitter. And the third level consist of the contacts of a given transmitter/receiver pair, sorted by start time. The topology model does not constraint the pathfinding model (see section III-E).

## C. Route Model

Pathfinding is built with the concept of *RouteStage*. A *RouteStage* translates either a progression step of a Dijkstra variant, Dijkstra's work area of a contact (as in ION where the current parent contact and arrival time are stored), or a route hop in the sense of SABR. In A-SABR, a route is a *RouteStage* that represents a hop between the penultimate node and the destination. The route is reconstructed by chaining, as a *RouteStage* shall store a reference to the parent *RouteStage*. An advantage of this approach is its flexibility and simplicity; in most cases, the work areas become the output of the pathfinding.

The current version do not decline the *Multigraph* in several variants (e.g. a node graph or contact graph), and the *RouteStage* acts as a proxy to behave as if we were operating on a contact graph or a node graph depending on the elements pushed in Dijkstra's priority queue (see section III-E).

## D. Resource Management

Contacts and nodes are templated with a concrete implementation of the *ContactManager* or *NodeManager* interface. This design allows for the flexibility of introducing new management techniques while still keeping a minimal code base and high performance. Each interface requires a set of methods depicted as "dry_run" actions, and their "schedule" counterparts. A "schedule" action must be identical to its "dry_run" variant, but is allowed to update the internal metrics of the entity (e.g. the residual volume for a contact or the buffer occupancy for a node).

1) *Contact resource management:* The *ContactManager* interface only requires the methods `dry_run_tx` and `schedule_tx` ("tx" for transmission). The method `dry_run_tx` would be invoked during construction and selection, and the `schedule_tx` for route update. This follows the concepts described in [22].

The library provides managers for SABR's ETO and EVL management techniques, and includes two additional management approaches:

**Queue Delay (QD):** EVL can be extended to compute a time analog to an ETO for the contacts with non-neighboring nodes, by inferring a delay thanks to the booked volume of a contact. This approach is called queue-delay [21], and is part of ION's CGR-unibo version of SABR/CGR.

**Contact Segmentation (CS):** contact segmentation proposes to track accurately the time intervals (or segments) of bandwidth availability/utilization. This approach was extensively covered in [22]

In A-SABR, EVL, ETO, and QD are generated with a unique macro that can add at compile time priority support for a given priority count and optionally budgeted priorities. The budgeted priorities are introduced with this paper. Priority budgeting allows limiting the volume that can be booked for a given priority level. With budgeting, the contact plan format must be adapted.

The pre-generated variants are listed on GitHub<fnref n="1" />, but the macro can be re-invoked to create a new variant showing more than 3 levels of priority. The delays are managed accordingly depending on the generated variant.

2) *Node resource management:* We now extend this approach to nodes with the *NodeManager* interface with an "acquire / process / release" responsibility design:

* acquire: the methods `dry_run_tx` and `schedule_tx` called upon bundle reception ("rx").

* process: `dry_run_process` and `schedule_process` after reception for potential bundle treatment.

* release: `dry_run_tx` and `schedule_tx` called upon bundle transmission.

For performance, those 3 sets are disabled by default and must be enabled individually at compile time. While acquire / release capabilities can be leveraged for bundle buffer management, the process capability may allow an implementer to add a scheduling delay. It also allows bundle mutability, for example if bundle compression, encapsulation, or addition of extension blocks is expected at a given node. This capability is still exploratory, but a complete example of the approach, "bundle_processing", is available on A-SABR's repository.

## E. Pathfinding Processes

CGR is typically described as operating on a graph where vertices represent *contacts*. In the context of Dijkstra's algorithm, this can be interpreted as "jumping" from one contact to the next, where each preceding contact acts as the *parent* of the following one. This differs from traditional node-based traversals and can be considered independent of the underlying data structure—A-SABR always uses a *multigraph*. To avoid confusion between the graph structure and construction strategy, we adopt the term *parenting* to describe this relationship (e.g. "contact parenting" rather than "contact graph").

The library offers pathfinding algorithms based on three main parenting strategies: *NodeParenting*, *ContactParenting*, and *HybridParenting* (renamed from Mpt [17] for clarity), each available in both single-destination and *shortest-path tree* (*SPT*) variants. The SPT variant of ContactParenting is a contribution of this paper.

Constructing an SPT over contacts was previously avoided due to memory and computational costs, and limited practical value—unicast and multicast typically require one path per *node*, not per contact. Storing such routes at scale would be

<footnote n="1">¹https://github.com/DTN-MTP/A-SABR</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1: a) The 6 A-SABR Dijkstra variants are volume-aware (3 single-destination, 3 shortest-path tree). b) Limiting contact approaches [15], which are not volume-aware, are implemented via composition. c) Pathfinding workflow.</figcaption></figure>

burdensome, especially with large contact plans, and exploring all the contacts at each RCP would be inefficient.

Instead, our approach connects each node. Although still leveraging contact parenting, traversal stops once all reachable nodes are visited.

The Pathfinding interface requires implementing a `get_next` (route/tree) method. Algorithms may compose with others (e.g., Yen depends on Dijkstra). Strategies such as *FirstEnding* and *FirstDepleted* are implemented through composition, each supporting all three backends: *NodeParenting*, *ContactParenting*, and *HybridParenting*.

Figure 1 illustrates the interactions between node and resource management during a `get_next` invocation.

## F. Storage and Routing

A Routing algorithm's entry-point is one of the following mainframes: `Cgr`, `VolCgr`, ans `Spsn`. Those mainframes are templated for compile time association of the previously mentioned modules. A storage must also be attached to the mainframe, and selection can be delegated to the storage. This design makes the code base of a mainframe minimal: for example, the `Cgr` mainframes's code is limited to asking the best known route to the storage and using it, or looping on the pathfinding's `get_next` function until one new route is suitable. The newly introduced `VolCgr` algorithm, discards alternative pathfinding (e.g. Yen, FirstEnding, FirstDepleted) to directly rely on a volume-aware Dijkstra call. The routes are still single destination-based and stored/selected in routing tables.

## IV. EVALUATION

We evaluate twelve routing variants representative of different strategies implemented in the A-SABR framework. These variants combine four distinct route construction strategies: First Depleted, First Ending, Shortest Path Set Node (Spsn), and Volume-aware, each paired with alternative pathfinding backends: *ContactParenting*, *HybridParenting*, and *NodeParenting*.

The limiting contact approaches (FirstEnding / FirstDepleted) are Yen's algorithm alternatives that erase a contact (the first ending or the one with the fewest EVL) of the last found route before computing the next one. As long as those contacts are permanently suppressed, the routing false negative (failure to find a route although one exists) is higher; we provide an example of this behavior in Figure 2. Those algorithms will therefore be excluded from some of our benchmarking tests.

We then split our evaluation into computational performance or “off-line” benchmarking<fnref n="2" /> and networking performance or “online” evaluation. The separation is motivated by the need to disregard simulation overhead in computational benchmarking. The offline tests focus on the measurements of individual procedure performance, while the online tests involve a simulator with bundle-based networking metrics. Both benchmarking strategies rely on realistic scenarios generated with real orbital data based on publicly available Two-Line Element (TLE) databases [24].

<footnote n="2">²https://github.com/DTN-MTP/A-SABR-processing-benchmark</footnote>
<figure><img src="image_3.png" /><figcaption>Fig. 2: Routing failure rates over time with congestion (trans-portation scenario, 80 nodes, 144306 contacts).</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Fig. 3: Bundle scheduling processing time benchmarking.</figcaption></figure>

The offline benchmarking consists of the initialization of a router and the subsequent scheduling of bundles with that router. The measurements are processed by either counting the number of scheduling for a fixed elapsed time or measuring the elapsed time for a given maximum bundle scheduling count. Leveraging a single strategy was not feasible due to high processing time disparities and the risk of OS scheduling noise for the fast algorithms.

This analysis permitted the confirmation of the high compu-
tational pressure of ContactParenting for the single destination
variant (see Cgr and VolCgr). The tree construction variant (see
Spsn) introduced with this paper does not perform well with
the highest processing pressure of all algorithms covered. This
result was expected as the tree construction presents a logical

<figure><img src="image_5.png" /><figcaption>Fig. 4: Delivery rates vs. processing time tradeoff.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 5: Delivery delays vs. processing time tradeoff.</figcaption></figure>

overhead compared to single destination construction in order
to detect that all reachable nodes are visited. Those results are
presented in Figure 3.

Regarding the networking evaluation, the scenario involves
an 80-node network with four celestial bodies: Earth, Moon,
Titan, and Mars, with Earth-like planetary ring-road networks
and realistic interplanetary delays. Two main findings can be
pointed out (Figure 4 and 5):

* The HybridParenting approach is the best-performing pathfinding approach, and presents a computational pressure barely higher than NodeParenting, and drastically lower than ContactParenting. It allows for networking performance similar to or better than ContactParenting.

* The VolCgr approach, introduced with this paper, becomes the best-performing algorithm and even beats Spsn in the current scenario. This new approach is a significant achievement, but Spsn remains configurable to lower the processing pressure for negligible networking tradeoffs.

Beyond delivery and delay, rescheduling and contact utiliza-
tion offer deeper insights. ContactParenting variants achieve
high utilization but incur higher rescheduling and runtime per
transmission. HybridParenting maintains comparable delivery
<table><caption>TABLE I: Tradeoffs Across Routing mainframes, Pathfinding, and composite pathfinding Strategies</caption><thead><tr><th>Strategy</th><th>Delivery</th><th>Delay</th><th>CPU Time</th><th>Scalability</th></tr></thead><tbody><tr><td>VolCgr</td><td>High</td><td>Low</td><td>Medium</td><td>High</td></tr><tr><td>Spsn</td><td>High</td><td>Low</td><td>Medium</td><td>High</td></tr><tr><td>Cgr</td><td>Medium</td><td>Medium</td><td>High</td><td>Low</td></tr><tr><td>HybridParenting</td><td>High</td><td>Low</td><td>Low</td><td>High</td></tr><tr><td>NodeParenting</td><td>Medium</td><td>Medium</td><td>Very Low</td><td>Very High</td></tr><tr><td>ContactParenting</td><td>High</td><td>Low</td><td>Very High</td><td>Low</td></tr><tr><td>FirstEnding</td><td>Low-Med</td><td>Low</td><td>Low</td><td>Medium</td></tr><tr><td>FirstDepleted</td><td>Low</td><td>Low</td><td>Very High</td><td>Medium</td></tr></tbody></table>

with significantly lower overhead, offering a more scalable balance.

Table I summarizes the tradeoffs observed across the evaluated routing strategies. VolCgr and HybridParenting emerge as well-balanced approaches, offering high delivery performance with moderate to low computational cost and good scalability. In contrast, ContactParenting yields excellent delivery and delay metrics but at the expense of high CPU time, making it less suitable for large-scale scenarios. SPSN provides strong delivery guarantees and the lowest processing cost. FirstEnding and FirstDepleted are computationally light but suffer from reduced delivery performance due to their aggressive contact suppression strategies.

## V. CONCLUSION AND FUTURE WORK

This paper presented A-SABR, a modular and high-performance routing library designed to support both the research and operational deployment of Schedule-Aware Bundle Routing (SABR) strategies in Delay-Tolerant Networks. By decoupling core CGR functionalities into configurable components and leveraging Rust's compile-time metaprogramming capabilities, A-SABR offers a platform that is both extensible and efficient.

Our evaluation demonstrated that the HybridParenting approach delivers networking performance comparable to ContactParenting while maintaining significantly lower computational costs, marking it as a practical choice for scalable DTN deployments. Furthermore, the VolCgr strategy, introduced in this work, outperforms existing methods in our realistic simulation scenarios, establishing a new state-of-the-art tradeoff between delivery performance and computational load.

Future work includes extending node-level management capabilities, integrating advanced scheduling strategies, supporting dynamic contact plan updates, and enabling native interfacing with real-time DTN stacks.

## REFERENCES

[1] 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. [Online]. Available: http://www.rfc-editor.org/rfc/rfc4838.txt

[2] "The future mars communications architecture," Interagency Operations Advisory Group, 2022. [Online]. Available: https://www.ioag.org/Public\%20Documents/MBC\%20architecture\%20report\%20final\%20version\%20PDF.pdf

[3] "LCRNS Project - TEMPO," https://tempo.gsfc.nasa.gov/projects/LCRNS/, 2023, accessed: 2024-03-15.

[4] "ESA's Moonlight: Connectivity and Secure Communications," https://www.esa.int/Applications/Connectivity_and_Secure_Comunications/Moonlight, 2023, accessed: 2024-03-15.

[5] NASA, "Lunanet interoperability specification version 5 - draft," https://www.nasa.gov/wp-content/uploads/2023/09/lunanet-interoperability-specification-v5-draft.pdf?emrc=6f4483, 2023, accessed: Mar. 15, 2024.

[6] K. Scott, S. Burleigh, and E. Birrane, "Bundle protocol version 7," Internet Requests for Comments, RFC Editor, RFC 9171, January 2022. [Online]. Available: http://www.rfc-editor.org/rfc/rfc9171.txt

[7] Consultative Committee for Space Data Systems (CCSDS), "Ccsds bundle protocol specification (blue book, recommended standard CCSDS 734.2-B-1," https://public.ccsds.org/Pubs/734x2b1.pdf, September 2015.

[8] 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.

[9] S. Burleigh, "Contact graph routing," 2009. [Online]. Available: http://tools.ietf.org/html/draft-burleigh-dtnrg-cgr-00

[10] B. Book, "Schedule-aware bundle routing," Consultative Committee for Space Data Systems, 2019.

[11] S. Burleigh, "Interplanetary overlay network: An implementation of the dtn bundle protocol," 2007.

[12] 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.

[13] J. A. Fraire, "Introducing contact plan designer: A planning tool for dtn-based space-terrestrial networks," in 2017 6th SMC-IT. IEEE, 2017, pp. 124-127.

[14] O. De Jonckère, J. A. Fraire, and S. Burleigh, "On the tractability of yen's algorithm and contact graph modeling in contact graph routing," in 2023 IEEE International Conference on Wireless for Space and Extreme Environments (WiSEE), 2023, pp. 80-86.

[15] 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.

[16] M. Moy, R. Kassouf-Short, N. Kortas, J. Cleveland, B. Tomko, D. Conricode, Y. Kirkpatrick, R. Cardona, B. Heller, and J. Curry, "Contact multigraph routing: Overview and implementation," in 2023 IEEE Aerospace Conference, 2023, pp. 1-9.

[17] O. De Jonckère, J. A. Fraire, and S. Burleigh, "Enhanced pathfinding and scalability with shortest-path tree routing for space networks," in ICC 2023-IEEE International Conference on Communications. IEEE, 2023, pp. 4082-4088.

[18] O. De Jonckère and J. A. Fraire, "A shortest-path tree approach for routing in space networks," China Communications, vol. 17, no. 7, pp. 52-66, 2020.

[19] F. Walter, "Prediction-enhanced Routing in Disruption-tolerant Satellite Networks," Doctoral Dissertation, Technische Universität Dresden, 2020. [Online]. Available: https://nbn-resolving.org/urn:nbn:de:bsz:14-qucosa2-721622

[20] G. Araniti, N. Bezirgiannidis, E. Birrane, I. Bisio, S. Burleigh, C. Caini, M. Feldmann, M. Marchese, J. Segui, and K. Suzuki, "Contact graph routing in dtn space networks: overview, enhancements and performance," IEEE Communications Magazine, vol. 53, no. 3, pp. 38-46, 2015.

[21] 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.

[22] O. De Jonckère, J. A. Fraire, and S. Burleigh, "Distributed volume management in space dtns: Scoping schedule-aware bundle routing," in 2024 IEEE 10th SMC-IT. IEEE, 2024, pp. 125-134.

[23] O. De Jonckère, "Scalable schedule-aware bundle routing," 2023.

[24] https://gitlab.com/d3tn/aidodtnsim.

[25] https://github.com/msancheznet/dtnsim.

[26] https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf.

[27] J. Y. Yen, "Finding the K shortest loopless paths in a network," Management Science, vol. 17, no. 11, pp. 712-716, 1971.

[28] K. Scott and S. C. Burleigh, "Bundle Protocol Specification," RFC 5050, Nov. 2007. [Online]. Available: https://www.rfc-editor.org/info/rfc5050

[29] https://gitlab.com/d3tn/dtn-tvg-util.