An Architecture for Bundle Routing in Space: Collaborative Contact Negotiation and Visionary Server for DTN Route Development

I. INTRODUCTION

THE propagation of disruption/delay tolerant network (DTN) bundles through a mesh network requires routing path determination. Many routing algorithms have been suggested and are currently under study [1]. Some computation models calculate contact queuing delay and remaining contact capacity [2]. The routing path decision should either maximize the volume of data delivery or minimize the latency of data delivery [3]. Ideally, all nodes in a mesh network would benefit from the routing results.

Contact graph routing (CGR) and its variations are based on the concept that every contact request can be deterministically scheduled, yielding the most optimized results with an acceptable computational effort among cognitive nodes [4]. As suggested in schedule-aware bundle routing (SABR) [5] in the consultative committee for space data systems (CCSDS), for example, CGR is implemented in the interplanetary overlay network (ION) DTN software suite.

CGR-based algorithms use variations of the Dijkstra algorithm tailored for dynamic contact graphs. The performance of CGR-based algorithms relies on bundle priority and queuing delay. To enhance the realism of CGR, the queue backlog issue needs to be considered, as contacts assessed by CGR are dynamic, and the overloaded queuing problem is one of the key constraints for optimizing network performance, particularly in resource-constrained space environments where storage and transmission opportunities are limited [6]. This improvement enhances routing and the estimation of end-toend delivery delay by computing the path search algorithm and drawing the desired contact route [7]. On the other hand, recent studies such as [8] and [9] analyze the behavior in satellite networks and end devices, where [8] develops stochastic models to evaluate aging impact on satellite systems’ availability, addressing critical dependability challenges in space environments where maintenance is unavailable, while [9] investigates LoRa signal performance in satellite-assisted lowpower wide area networks (LPWANs) using Graham’s algorithm to enhance signal quality and strengthen device-satellite links in areas with limited connectivity to ensure reliable widearea link support. Also, to offer tighter control and enable better troubleshooting of valuable space assets from mission control centers, novel centralized routing approaches have been proposed [10], though at the cost of increased ground infrastructure complexity as space information networks, typically space sensor networks, continue to grow in scale and complexity. In such resource- and contact-opportunityconstrained environments, including both near-Earth and deepspace communications, situationally aware routing considering multiple factors such as traffic requirements may deliver optimal routing results [11]. Additional situational considerations need to be investigated to ensure more realistic performance satisfaction for relevant entities in future space networks. Certainly, fairness in allocating routing opportunities would be one of the key concerns of network entities [12]. In realistic space mission scenarios and more complex bundle routing topologies in space, establishing dynamic discoverybased and opportunistic contact among peers within an adjacent range presents challenges. One of the most challenging aspects of space networks compared to terrestrial networks is the difficulty in maintaining communication capability when anomalies occur in space network nodes. The troubled network node needs a dedicated emergency repair channel, either through direct connection or via relay links, to receive ground assistance for problem resolution. Node anomalies easily break the automation process of all variants of CGR and induce unpredictable impairments on the functioning of the space network. In such cases, ground control requests a dedicated emergency contact establishment from ground to the troubled space network node, which clearly requires manual intervention to override the previous contact path decision mechanism. This manual intervention is challenging due to the impact of long propagation delays, intermittent connectivity, asymmetric data rates, and constraints related to spacecraft attitude and battery power, especially in space networks. It is easy to anticipate that the partitioned network impacted by the anomaly cannot function properly until the troubled node returns to normal state.

A node’s determination of the next hop can be erroneous due to limited information about nearby nodes when executing the route calculation algorithm. Contact plans frequently change and need regular updates [13]. This is because of imperfect harvested contact information, the need for fair data volume delivery, and spacecraft management requirements such as narrow beam pointing, battery optimization, and on-board maintenance [14].

In space networking, contacts can be estimated and planned on ground, and routing over the pre-estimated path for DTN bundles are called as schedule-aware DTN routing [15].

However, each contact available through physical path analysis and estimation should not be interpreted as a firm appointment because other operational considerations must be concurrently accounted for. A path between nodes can be planned in detail, forming contact plans [5]. Dynamic changes to spacecraft configurations, such as antenna pointing, solar array pointing, or attitude direction, are often constrained by safety and protection needs. Therefore, a pre-negotiated and collaborative approach between peer-to-peer nodes is currently the only viable solution given the numerous operational limitations of spacecraft missions. For example, activities such as routine playback to the mission operations center (MOC) and on-orbit maintenance require clearing specific constraints before they can be performed, even with contact support. An important factor in establishing contact is determining whether a collaborative support relationship exists between two nodes, as nodes under such a relationship are expected to be contactable. A path to a node without a collaborative support relationship is untrustworthy and can be likened to being behind a firewall in terrestrial networks. In the space domain, every contact is enabled once coordinated and validated by both the MOC and the spacecraft control center (SCC).

We assert that coordination for identifying the optimal cooperative path can be accomplished by a single authoritative computing machine that collects contact information and trajectory data from each member node in a DTN mesh network with accompanying space communication assets, rather than relying on individual node computations as other DTN bundle routing schemes do.

A ground-based computing resource is better suited for this purpose compared to resource-constrained satellites and spacecraft in general because real-time computation of the routing path imposes a non-negligible computational load on each node.

The path selection shall aim to either maximize net data volume in both ingress and egress directions or minimize net latency among nodes. CGR achieves this by utilizing Dijkstra’s search algorithm to select the shortest path among contacts. Additionally, it is important to consider whether a scheduling method can support either fair time distribution or fair latency distribution.

The single authoritative computing machine will provide pre-negotiated contact plans to a service-client node that doesn’t need validation by each target node. These plans will be presented as an information set with self-annotations that advertise the pre-negotiated and collaborative aspects. We refer to this system as schedule self-annotated advertised bundle routing (SAABR).

We propose the concept of a visionary server (VS) that supports the required functionalities for managing contacts and providing the contact information set, as discussed earlier.

It is predicted that the route path decision from the VS may be the only practically applicable solution for the arbitration of routing scenarios in the DTN mesh network in space until new advanced space communication technologies emerge, eliminating concerns related to space communication constraints.

Major keywords and important terminologies used in this study are listed in Table I.

This paper is structured as follows: Section II presents a summary of the literature review on DTN bundle routing methods. Section III introduces the VS and SAABR. Section IV presents the core rules of contact allocation in SAABR. Section V presents the modeling of the simulation platform. Section VI discusses the results of the simulation. Finally, Section VII presents the conclusions of the study.

II. BUNDLE ROUTING METHODS OF DTN IN INTERPLANETARY NETWORK

In a DTN network, several routing mechanisms based on zero-knowledge or probability have been studied [1]. Epidemic [16], binary spray and wait [17], and flooding routing algorithms are based on zero knowledge about the overall node configuration. ProPHET [18], spray and focus [19], and multi-hop (MH) algorithms are based on the probability of establishing contact with nearby nodes to maximize the delivery success rate despite the network elements having obfuscated information.

Specifically, based on the premise that the movements of future network nodes are known in advance, schedule-based DTN routing algorithms have been studied. In scheduled networks, each contact schedule can be pre-computed and preloaded into one of the processes at the mission operation center, similar to those used in deep space networks (DSNs) [20]. CGR is the best-known example of this approach. It aims to calculate the shortest path to the next hop, generally using the Dijkstra search algorithm to find the optimal path among nodes and contacts.

S-CGR, Source-CGR, which relies on a source DTN node’s computation for calculating a routing path to a destination DTN node, has been studied [21]. Contact information, such as start and end times and available contact volume, is computed by a source DTN node and stored at each DTN node of concern.

Considering the queueing delay in routing computation and the available capacity to handle receiving messages, ICGR, an improved CGR, has been studied and proposed [2] to achieve an improved message delivery rate and reduced latency.

To cope with dynamic changes at intermediate nodes, moderate source routing (MSR) has been proposed [22] to mitigate the overhead of route recomputation by the source, including standard CGR verification. In this research, the CGR routes extension block (CGRR-EB), which differs from the CGR extension block [23] in terms of format and information content, has been introduced.

A study on predictable link-state routing (PLSR), which does not necessitate considering all possible contact opportunities but instead uses certain contact opportunities decided a priori or through prediction, has been performed [24]. In this study, the topologies of predictable networks are described by a series of topology snapshots, which are ultimately disseminated to the necessary nodes that require the predefined topology paths. This scheme seems to be a quite suitable approach for routing planning in predictable delay tolerant networks (PDTNs) to achieve lower resource usage [25]. The precomputed contact plans and routes are created in a centralized computation resource, and the results are periodically uploaded at target satellites [26]. The contact allocation and control mechanism helps to reduce computing power consumption and radio interference [27]. A predictable link and contact plan can be represented using snapshots for static contact states and a snapshot sequence for depicting their evolution over time [28].

Starting with the idea that connectivity can be predicted in advance through the analysis of estimated information and orbital elements in space nodes, the contact plan generated by that routing can be distributed in advance to all relevant nodes to let them calculate the next route by themselves. The period of contact plan distribution should be determined empirically, while allowing for dynamic updates to handle urgent events. Therefore, nodes that receive the contact plan can understand future connectivity information, which is essential for computing CGR for bundle forwarding or delivery.

CGR-based algorithms depend on the assumption that it is possible to collect all necessary information about adjacent accessible nodes for path computation. These algorithms primarily focus on temporal contact opportunities and data rates, without considering the heterogeneity of physical layer characteristics that exist between different spacecraft. This approach works only within a single agency constellation where communication systems are often standardized, and even then only if orbital information of DTN nodes is shared across agencies—a practice not currently implemented. The dynamic and real-time identification of accessible nodes is particularly challenging in a multi-agency DTN setup due to the lack of shared orbital and mission information. Furthermore, these conventional routing approaches fail to account for crucial physical layer compatibility issues such as RF frequency bands, modulation schemes, and polarization types, which can render theoretically possible contacts practically infeasible. Sharing information about RF compatibility at the physical layer during contact planning is important because these parameters often change according to operational modes such as normal mode and survival mode of a spacecraft. The visionary server addresses these limitations by centralizing both orbital data and detailed physical communication specifications of all participating spacecraft, enabling it to construct routing paths that are not only temporally optimal but also physically compatible across heterogeneous space assets from multiple agencies. Online and real-time routing is challenging due to inherent uncertainty in DTN environments, and an optimal path is not always feasible even with complete knowledge of future routes [29]. CGR-based algorithms are more suited for single agency constellations where such information is centrally managed and readily available. When a contact time experiences issues due to a node’s temporary failure, maintenance, heavy rain, snow, or strong wind, the event must be propagated throughout the network. This is especially challenging in a multi-agency DTN. Therefore, addressing these challenges requires increased collaboration, standardized data sharing, or more autonomous and adaptive routing algorithms.

Also, regarding the overbooking issue, lower priority bundles encounter problems in getting opportunities to transmit compared to higher priority bundles. To overcome this, an overbooking management scheme by modifying CGR was presented [30]. CGR-based routing algorithms may calculate an overbooked contact plan that a node cannot service due to its performance limitations, unless such overbooking is intentionally restrained. The overbooked contact schedule is particularly critical, as such situations are difficult to capture and resolve promptly. These overbooking scheduling results must be resolved in space networks because they provide limited connectivity due to constrained size, weight, and power (SWaP).

It can be tentatively projected that the biggest gap between state-of-the-art routing algorithms and reality in space networks may be the lack of support for predicted dynamic contact changes in real-time, due to constraints in SWaP and limitations in spacecraft attitude control, communication capabilities, and internal resources or system failure.

III. VISIONARY SERVER AND SAABR

Considering the aforementioned research on deterministic routing, the major points constituting the critical path to the registration of the contact plan among nodes are as follows:

· Connectivity can be pre-computed at a location with significantly higher computing power than that of performance-restrained spacecraft, thereby forming the contact plan.

· The generated contact plan must consider the overbooked schedule by checking each node’s SWaP, as announced by the node operator.

· The generated contact plan must be distributed to the relevant network nodes for routing decisions, so transport mechanisms are required to carry this information to the recipient nodes.

Based on this summary, it is concluded that the VS can support these activities and achieve optimal results by implementing predefined rules and fostering collaboration among nodes, rather than having each node compute the routing path individually. Sharing information for filling routing table for contact path computation essentially relies on permission and voluntarily provision by space agencies or governance institute. The same process will be required for any variants of CGR. Any other attempts to collect the data besides interagencies cooperation are not cost effective and can be thought as a legal issue substantially. In this context, the VS functions like a high-performance server that processes routing decisions based on established rules and agreements among agencies and institutions participating in collaborative DTN space networks. This approach ensures that all nodes within the network do not need to compute these decisions independently but rather follow and execute the coordinated contact plan negotiated by the VS.

The VS generates contact plans for each end-to-end connection between source and destination nodes at specific times. Like a routing service user, the source node receives these contact plans in advance by querying the VS before initiating a new bundle departure. The methods for querying and delivering contact plans to a node are beyond the scope of this study. For further details, readers can reference research on the contact plan update protocol [31]. Additionally, background concepts in software-defined networking [32] provide a useful starting point for this purpose.

Provided that a source node now knows all the necessary contact plans to a destination node through the above-stated process, this study proposes a new extension block to indicate to intermediate nodes how to forward received bundles to the next hop. The VS orchestrates contact events across all the area of concern to meet each partner’s needs fairly, thereby preemptively resolving potential conflicts before actual contacts are established. As described in the development of the contact plan designer [33], iterative enhancement and optimization efforts are generally required until satisfactory results are achieved throughout the VS’s computation process.

An annotated advertised-CGR (AA-CGR) extension block (EB) for BPv7 is newly introduced in this study to carry all the required routing information from the source node to the destination node including intermediate nodes, all of which are governed by this SAABR scheme.

Once a source node possesses an advertised routing schedule path from the VS by querying it, the source node can then compose the AA-CGR EB and is ready to initiate new bundle departure to the destination node through intermediate nodes.

A. Visionary Server

The VS is an arbitration and management platform that has extensive knowledge of spacecraft flight dynamics and is optimized for calculating fair distribution of contact opportunities in the routing schedule. It implements sophisticated arbitration logic for contact scheduling based on the given contact policy and the requested data volume to be transmitted by the service requester.

The output of the planned contact by the VS may not be the best optimized in terms of geographical and performance considerations compared to CGR-based algorithms, which are theoretical estimation methods, but it will strive to fulfill the requirements of all beneficiaries using the VS service in the affected DTN network. The route path decision from the VS is forecasted to be the most practically applicable solution for arbitrating routing scenarios in space DTN mesh networks, reflecting the needs and concerns of all nodes until fully advanced space communication technologies emerge that eliminate current constraints. In contrast, CGR focuses on the calculation of the shortest delivery time. The VS does not intend to compete with any CGR-based algorithms that aim to achieve optimized delivery time.

Every node that requires the services of the VS must regularly update its detailed orbit information (ephemeris) and contact policy, including collaborative relationships with other communication assets. After the VS calculates and simulates dynamic trajectories and line of sight for the given communication assets and spacecraft, it continually updates an optimized routing table in the local routing information cache. Subsequently, a routing service user can obtain a routing table specific to their target of interest by querying the VS. We assume that the ephemeris data for a spacecraft can be generated by an MOC, not by the spacecraft itself. As a result, each client node of the VS does not need to hold a contact table to build and compute contact paths by itself; instead, the VS provides all required routing information through a specific extension block to carry this information to client nodes.

In particular, available contact time must be collected collaboratively through joint space agencies or institutions because only the SCC or MOC knows the node downtime, maintenance time, special time for internal testing, software upgrades, and so on. Additionally, an MOC can only generate ephemeris data for a spacecraft under its control because continuous ranging is required to estimate its future track, in short, the ephemeris. All nodes benefiting from the VS service are requested to store the ephemeris data of the contact nodes obtained from the VS or its MOC and use it to adjust antenna positions and spacecraft attitudes to establish the planned contact. Through this process, a significant amount of orbit-indicating messages will be delivered to the ground antenna or spacecraft [34]. For example, the orbit ephemeris message (OEM) information recommended by the interagency operations advisory group (IOAG) Service Catalog #3’s navigation data exchange service is essential, particularly when precise antenna aiming is required to maintain the link. The volume of ephemeris data can be substantial, so non-negligible bundles are required to transfer the necessary ephemeris data to beneficiaries using the advertised contact plan from the VS. Updating the ephemeris data is crucial for spacecraft that need to point their antenna systems at remote spacecraft during specific contact times, unless they are equipped with omnidirectional antennas. However, transferring the ephemeris data to appropriate recipients is not a function of the VS or the contact plan handler; it is performed by the SCC as part of spacecraft maintenance operations. Due to the numerous preparations and processes required to set up and execute contact support in a collaborative environment, it is rarely possible to abruptly change the target of the contact support from a non-operational asset to another asset requiring urgent contact support. Such rapid configuration changes are only possible in ground segments, not in space segments. These abrupt configuration changes are only detectable from the ground and can be accessed via pre-defined communication channels, such as voice-chat or urgent messages pre-arranged among relevant space agencies’ MOC. This communication is coordinated by the VS, which collects and governs the path information and its distribution. The fundamental reason for unexpected configuration changes arises from spacecraft mode changes, e.g., normal mode to emergency mode, which necessitates complex procedures for finding and recovering from issues that have occurred. Until its state returns to normal, all involved network bridges cannot be restored. The VS scheme can especially aid in this situation. The troubled node experiencing abrupt system configuration changes is still seen as a valid node during dynamic route path computation. The VS helps to try various contacts according to analysis data collected from ground experts. In summary, the VS interrogates the midnodes to check the path’s potential availabilities, and tries to make dynamic changes to the pre-negotiated routing schedule to support higher priority in emergency scenarios if required. This consideration may be highlighted when a new mission launches and it needs high attention of communication support during set-up time on orbit.

The VS can also function as a DTN node, similar to the centralized structure of the deep space operations center (DSOC) for DSN and DTN operations [35]. DTN nodes requiring the VS service may send a bundle to request the services. Additionally, the VS shall be accessible to user DTN nodes via alternative interfaces, including HTTP.

The VS and query to a destination node can be used to support a spacecraft in an emergency state. Under the assumption that all the paths from the supporting node to the distressed node are cleared to support the emergency state, a new path can be established by this query using path overriding functions. Abrupt changes to the contact plan in space should be made with caution, as their impact can alter expected link performance metrics. Supporting distressed spacecraft is mandatory in space sector, so a collaborative consensus among agencies and institutions that operate ground stations and spacecraft is essential. If all the nodes in the path accept the urgent support request, all pre-planned contacts on the supporting node will be canceled, and an immediate contact will be manually established between the supporting node and the troubled node. In general, future contact nodes of the troubled node can be assigned as assistance nodes. Emergency supporting communication can be done with or without the DTN bundle protocol. In most situations, only space packet protocol (SPP) [36] or Licklider transmission protocol (LTP) [37] will be used to minimize complexity. When the functionality of the troubled node is restored, it resumes its role as a DTN node. Restoring the functionality of a spacecraft can involve significant delays, especially in space applications. Therefore, immediate re-planning of the contact schedule should be undertaken, and the newly generated plan needs to be propagated as soon as possible.

There are real-time end-to-end (E2E) link and non realtime E2E link. Real-time E2E link opportunity is essential for operating critical missions, such as landing, lifting(ascending), and online voice/text chat with astronauts for performing critical missions. The Visionary Server should allocate a requested real-time end-to-end contact according to the end user’s request for required latency and E2E link duration if relay nodes have two-way communication capability. This can be checked during the simulation. This opportunity of real-time E2E link is supposed to be very rare, and it is a very precious opportunity compared to non-real-time E2E link. Once this real-time E2E link is established, bundles that are selected as critical and of higher priority will have a higher chance of transaction (urgent or expedite bundle). To ensure continuous real-time E2E link communication during a critical mission, we should anticipate periods of potential dead contact for other nodes, even when time could be allocated. This real-time E2E link is essential for missions where temporal responsiveness is crucial, such as extra-vehicular activities (EVAs) on lunar surface. For example, landing or ascending on the lunar surface is extremely critical, so all available communication resources are supposed to be solely allocated to these mission phases. These events will be tightly scheduled to maximize communication support from lunar assets, including ground infrastructure. For example, a realtime E2E link with acceptable latency, even under conditions of data loss, is essential for real-time voice communication and video streaming [38]. For missions that require voice communication and real-time video streaming services, frequent contact reconfiguration may be necessary to ensure real-time E2E link. Fully continuous connectivity must be ensured for teleoperating rovers on the lunar surface, either from the ground station or by astronauts. Non-real-time E2E link is suitable for non-critical missions, such as scientific data playback and parameter updates. The link opportunity anticipates interruptions or delays and also encompasses relay assets for batch file-oriented transfer operations.

To keep the VS functional, prompt information updates from the partner agencies’ spacecraft will be necessary, especially when an orbital maneuver is executed. The release of the updated contact plan with the altered orbit may be delayed by hours, hampering continuous communication services. Additionally, when calculating the contact plan, a duty factor should be considered because ground antennas need some break time for setup, calibration, and routine maintenance before the next operation as shown in Fig. 1. During each contact, a spacecraft must perform a series of steps required to manage the contact. However, when bundles flow through a terrestrial network, the required steps do not necessitate significant preparation and standby time. This simplicity allows us to disregard the impact of contact establishment time in terrestrial networks for future analysis. Diligent and timely coordination among space agencies constituting the VS system is the key to its proper operability. To support spacecraft mission operation planning, necessary node position information needs to be updated on a weekly basis or required time interval, considering flight dynamics prediction accuracy for both long-term and shortterm periods.

The contact allocation results provided by the VS, similar to the advertised contact plan, can be used for both DTN and non-DTN communication. The interplanetary network (IPN) comprises DTN-associated networks and non-DTN participants. Once the advertised contact plan is distributed, each ground and space node can operate its RF system using this contact information, regardless of whether it is a DTN or non-DTN node.

We provide an example of a topology that demonstrates the concepts of the VS and AA-CGR EB, as shown in Fig. 2. Additionally, we present a diagram illustrating the timing events of the scenario, as shown in Fig. 3. It is advised that a BP engine can benefit from selectively transmitting bundles to intermediate or final destination nodes using its overall accessible bundle transmission buffer, once it reads the advertised forwarding node information from the AA-CGR EB. Fig. 3 presents an example of the necessary processes and contact scenario between SCC2 and deep-space spacecraft 2 (DS2) through spacecraft 1 (SC1) and SC3 based on the topology shown in Fig. 2.

B. Annotated Advertised-CGR Extension Block

A registered node using the VS’s service may create its own contact plan based on the contact routing schedule provided by the VS. To simplify the implementation on a node that forwards or generates the routing path for the next hop using routing information from the VS, we have designed a new extension block in bundle version 7 [39]. This extension block annotates the visionary contact and routing plan for forwarding bundles to a designated destination and is referred to as the bundle routing annotation linked-tail, or simply AA-CGR extension block (AA-CGR EB) in this study. Inspired by the CGR extension block (CGR EB) [40], the CGR route (CGRR) extension block [41], and the S-CGR [21], this extension block holds the advertised and coordinated contact plan and routing information, including its start and end times [5], and can be attached to bundles forwarded to the next node.

AA-CGR EB is a concept that opposes opportunistic and real-time discovery contact with neighboring nodes. Intermittent connectivity, changes in distance, and variations in data rate/BER during contact can all be understood through space physics analysis of the moving spacecraft. Thus, all instances of failure during contact establishment are considered abnormal states, regardless of their duration. These failures are referred to as anomalies and can occur in either or both peers. Users of this extension block need to trust its content, eliminating the need for any validation steps in user nodes. By referencing this extension block, the next relaying node can immediately specify the node to which it should forward the bundle and the start and end times of the forwarding process.

An AA-CGR EB can be constituted with the following elements at minimum, though some sub-blocks may be treated as optional:

Array of unit sub block (sb): [TeX:] $$\left\{s b_1, \cdots, s b_n\right\},$$ the closest node shall be appeared at the first element of this array.

a) EIDs: {start node, next node}, the start node always represents the self node, while the next node signifies a node guided to the next hop for bundle forwarding or delivery.

b) Contact time: {AOS, LOS}, AOS: acquisition of signal, indicating the available start time of a contact, LOS: loss of signal, indicating the end time of a contact, formatted as the same representation of the DTN Time in BPv7 specification [39].

c) Node-to-node’s convergence layer (CL) type: indicating CL’s type of node-to-node link with selectable options of {udp, tcp, spp, ltp, etc.},

d) E2E link type: one of {rt, nrt}, indicating the desired connectivity type between end-to-end nodes with options for real-time (rt) and non-real-time (nrt) links.

e) Data rate: indicating the required transmission or reception speed (bits per second, bps).

f) Forwarding policy: rules for helping with the current node’s final forwarding decision.

g) Physical layer information: RF frequency, modulation, polarization, underlying spacelink type.

For example, an ‘rt’ link would be required for applications like telecommand operations or video conferencing where immediate response is critical, ensuring packets flow in an endto- end manner with minimal delay. In contrast, ‘nrt’ links are suitable for applications such as science data transmission or software updates where guaranteed delivery is more important than immediacy, allowing for store-and-forward operations across intermittent connections. This extension field delivers information on whether a source node is able to determine what type of control or data are to be executed.

The content of this EB consists of information in concise binary object representation (CBOR) [42], making it applicable to both unicast and multicast because it can hold and annotate multiple contact information entries as an array. Multiple contents can be concatenated in an AA-CGR EB, and a node should traverse the AA-CGR EB until it finds the guided contact path allocated to itself. Technologically speaking, the first contact path in the AA-CGR EB should be the one allocated to the node unless the previous node removes the contact path allocated to it. The format of the start and next node shall scale up for "ipn" and "dtn" endpoint identifier (EID) uniform resource identifier (URI) schemes [43] for unicast, and "imc" EID URI for multicast as an interplanetary multicast (IMC) endpoint ID [44]. If there is no traffic management in a DTN network, the forwarding policy within the EB structure may provide valuable information, enabling users to make informed decisions based on it. Based on user requirements, additional information can be added to the suggested AA-CGR EB above. In this study, the distance between nodes is not considered because it varies during contact. Instead, the desired data rate is more effectively delivered through pre-coordination rather than real-time calculation based on distance. For example, as suggested in the previous study [40], residual capacity for the current contact can be advertised in situations where on-board storage is constrained and needs to be closely monitored.

To evaluate the overhead of the AA-CGR EB, we demonstrate an example by assuming feasible link characteristics as shown in Fig. 4. In Fig. 4, the abbreviations b.t., b.n., b.c.f., c.t., and b.t.s.d. stand for block type, block number, block control flags, CRC type, and block-type specific data, respectively. In this example, a value of 15 (0x0F) is temporarily assigned to the block type of the AA-CGR EB. Fig. 5 shows the real example captured by Wireshark during a real BPv7 transaction test by using the AA-CGR EB on i3DTN [45], a DTN software platform developed by Korea Aerospace Research Institute (KARI). The structure follows the standard configuration, except for its block type which is marked as unknown since this AA-CGR EB is not registered for Wireshark bundle dissection processing. As shown in Fig. 5(b), the entire overhead from this example is 68 bytes. Since the use of the AACGR EB is flexible, this extension block can be included either in every bundle or only when contact topologies change. Once a node memorizes this route information, it can determine contact paths based on this information until a new update is provided. Therefore, the impact on network performance can be considered negligible, especially when implemented with the selective inclusion strategy.

Similar to the proposed concept of extension block operation, the length of the EB can be shortened as bundles approach their destination, because each node removes its selfreferencing routing element, as shown in Fig. 6. Consequently, when bundles reach their final forwarding node, this extension block can be completely removed before transmission to the destination. However, this operation is not mandatory, and any intermediate node can preserve the contents of the EB, particularly when the EB has an associated bundle integrity block (BIB) block [46].

The first user of this EB, referred to as the source node, is responsible for generating the entire contents of the AACGR EB from its own node to a destination node. There are two options to create it: 1) it can execute CGR to obtain a computed path based on the uploaded contact information. The contact routing schedule managed by the VS will have no duplicate contacts between nodes and will provide straightforward forwarding information, as all contacts are managed centrally. Therefore, the computation time for performing CGR will not be an issue; 2) alternatively, instead of computing the path itself, it promptly queries the newly advertised contact plan for a route to a destination node from the VS or AA-CGR EB moderators as soon as it receives the contact plans from the VS, as described above. Then, the VS or any AA-CGR EB moderator returns a draft but complete form of the AA-CGR EB. Considering that spacecraft have constrained computing power and that CGR computation is complex, it is recommended that, prior to initializing a bundle stream, the source node pull the entire contact path from the VS. Similar to a domain name server (DNS), reading the EB provides sufficient routing information for delivering or forwarding bundles to a target node. This EB enables a source node with long bundles to assign different next hops based on the available data volume slots provided by the predefined data rate and the buffer space status on the next hop when the bundles are fragmented. This query can be made, for example, up to one week before the actual contact time depending on use cases, and various protocols can be utilized such as HTTP, BP, or even specifically designed in-house protocols. Detailed specifications of the querying process and the delivery mechanisms of responses to the querying node are beyond the scope of this study. However, efficient protocol and operation policy would be necessary to address normal and stressed network situation because query in recovery action is the key function and needs to be performed less manually. Additionally, a source node can register a frequently used path with the VS. Once the new routing table is updated by the VS, the draft content for the suggested AA-CGR EB can be provided automatically and utilized in a timely manner. This AA-CGR EB can be positioned in a BPv7 bundle as shown in Fig. 7.

Every user of the AA-CGR EB must use the pre-delivered ephemeris data of the currently pointing node throughout the contact period to accurately aim their communication antenna. The VS should have already provided the ephemeris data for the current contact.

SAABR is a routing mechanism that utilizes pre-planned contact plans embedded in bundles, establishing routes from source to destination nodes without requiring intermediate nodes to perform AA-CGR EB path calculations.

The major difference from previous variations of CGR is that intermediate nodes do not need to validate or verify the integrity of the advertised contact information included in the AA-CGR EB. This is because the information is already validated by the space agencies or institutes operating the affected DTN assets, considering their operational episodes [14], before dispatching it. Once a node receives a bundle containing the AA-CGR EB, it can forward or deliver the bundle to the node specified by the EB. Simultaneously, the node’s antenna must aim at the next node using the provided ephemeris orbit information. The AA-CGR EB can be applied to both interplanetary and terrestrial DTN networks. The EB can also contain information necessary to determine the forwarding policy to the neighboring node of the targeted bundle, avoiding traversal through untrusted nodes or networks. This information is useful for implementing protection mechanisms such as encapsulation or re-encoding on the bundle.

These mechanisms prevent unfriendly relaying nodes from deleting, modifying, or appending any information to the bundle between the trusted and untrusted networks, regardless of BPSec implementation. One of the protection mechanisms can be a virtual private network (VPN) with BPSec [47]. The payload block of a bundle, along with the related BIB and bundle confidentiality block (BCB), can be randomized using the hash-based message authentication code-deterministic random bit generator (HMAC-DRBG) mechanism [48]. This is useful for concealing credentials from untrusted networks during bundle delivery. In this case, a bundle consists of the primary block, several extension blocks including AA-CGR EB, and the randomized section that includes the payload block, BIB, and BCB. When the bundle reaches its destination, the randomized section is derandomized, and its contents are validated and verified against the contents of the BIB and BCB.

In this case, the primary block and the packed block can be configured as described in BIBE [49], and will remain invariant during transactions across all boundaries between trusted and untrusted networks. Only the remaining extension blocks are expected to be modified by trusted and untrusted relay nodes. However, the AA-CGR EB can be set to invariant during all transactions with BIB protection to guarantee no changes during node traversal. This is useful for avoiding traversal over untrusted relay nodes.

The necessity of SAABR can also be justified by its ability to reflect the maintenance schedule or downtime of the ground antenna or spacecraft. This downtime can be predicted, but it must be shared among the cognitive nodes rather than being discovered in real-time prior to finalizing contact scheduling. The process of sharing this information must be collaborative because information sharing can be an issue where CGRbased routing is performed among different space agencies and organizations [50]. If the pre-negotiated and collaborative contact management suggested by SAABR is not feasible, this information needs to be disseminated through networks using a separate method. It could be an important function to redistribute the advertised contact plan on SAABR when there are changes in the network. The VS knows who requested those paths, so it can warn or automatically update about new possible paths, since network changes are not easily detectable by remote nodes.

AA-CGR EB may terminate at the boundary between the terrestrial internet and the space network because the terrestrial internet is well-developed, and TCP/IP and UDP/IP don’t require special considerations for carrying bundles. Thus, routing information in the internet is not necessary, and AACGR EB may terminate at SCC or MOC.

Here is the summary of how the VS and SAABR operation work:

1) Every node that has contracted and registered with the VS to use its service sends future ephemeris information regularly.

2) The VS analyzes the whole topology and contact opportunities, and allocates contact plans through the registered DTN nodes according to predefined rules.

3) The allocated contact plans, along with the ephemeris data for the duration of the contact, are distributed to the registered DTN nodes with appropriate tailoring for each node.

4) Each node can compute a contact routing schedule by using CGR or its derived algorithms.

5) Alternatively, if a node wants the VS to create an instantly usable contact routing schedule instead of generating it based on the delivered contact plans, it may request the VS to generate it. Then, the VS generates the requested contact routing schedule, aka SAABR, and delivers it to the requesting node. After receiving the SAABR information, the source node simply includes the AACGR EB, specifying the next forward node, in the bundle production.

IV. RULES OF CONTACT ALLOCATION IN SAABR

In this section, we present some major contact allocation rules for SAABR. These are suggestions, and the parameters can be adjusted based on the specific nodes. Each implementer of the VS may modify or add new rules according to their requirements and circumstances. Note that these rules and their parameters are changeable depending on circumstances, and special tuning can be applied to certain node-to-node contact opportunities to provide the necessary amount of time, despite the trade-off of reliability and accuracy. This approach is often required to support a troubled space network node in order to maximize communication supportability.

A. Duty Time and Setup Time

All contacts require consideration of downtime and setup time. Setup time is necessary to prepare the next contact path and includes checking the communication system’s functionality regarding power, battery, thermal status, and so on. In a spacecraft, waiting time is required until a sufficiently strong RF signal level is reached for communication, depending on the orbit and attitude conditions. Therefore, at least the following constant parameters should be considered.

· Minimum setup time: [hour]. This setup time shall be reserved for the resting period between contacts. This parameter shall include system maintenance, antenna calibration and transition, and attitude stabilization (for spacecraft). This time will not be reflected in the effective contact time.

· Maximum duty time: [hour] or [%] in a day. More contacts are not allowed if the accumulated contact time exceeds this duty limit.

B. Allocating Contact Time

For efficiency, a certain amount of time shall be guaranteed as the minimum contact time. This means that even if a better contact path is discovered, a pre-allocated contact cannot be interrupted if the minimum contact time hasn’t passed. For this, at least the following constant parameters should be considered.

· Threshold contact time: [min]. If the remaining available time doesn’t exceed this threshold, the current contact time is extended because allocating it for a new contact would not be effective, considering the setup and other preparation times.

· Minimum contact time: [hour]. At least this amount of contact time shall be allocated if the remaining available time can support it.

· Maximum contact time: [hour]. When an intermission is required during antenna system operation, the maximum contact time can be used to limit the continuous operation time of the communication system, including the antenna, ground storage, and other components.

· Minimum E2E contact time: [min]. For reasons such as performing a critical mission operation, an E2E contact path can be requested. This request shall probably have the highest priority for contact allocation.

C. Contact Performance

An end-to-end path shall be monitored to check its service performance, such as latency and data transfer rate. For this, at least the following constant parameters should be considered.

· Maximum latency: [sec]. If the current average latency approaches this limit, this node shall have priority for contact allocation.

· Minimum data rate: [%] (=average data rate/advertised data rate). If the data utilization rate is too low, this node shall have priority for contact allocation.

D. Contact Occultation

Even when line of sight is established, real contact cannot be maintained at certain spacecraft attitudes and antenna angles in space. The VS shall understand the spacecraft’s constraints. This contact opportunity cannot be included in the advertised contact plan. For this, at least the following parameters should be considered.

· Sun vector angle: [lower limit [TeX:] $$^{\circ}$$–upper limit [TeX:] $$^{\circ}$$]. If the sun vector angle being maneuvered to adjust the antenna position exceeds the limits of the allowed sun vector angle, this contact shall not be permitted.

· Sun avoidance angle: [lower limit [TeX:] $$^{\circ}$$–upper limit [TeX:] $$^{\circ}$$]. If the spacecraft’s rotating angle to adjust the antenna position exceeds the limits of the allowed sun protection angle, this contact shall not be permitted.

· Storage capacity limit: [% of total storage capacity]. If forecast storage consumption exceeds this limit, this contact shall not be permitted.

V. DESIGN OF SIMULATION

We developed a simulation platform to compute contact allocation based on SAABR and to measure bundle delivery ratio and bundle latency, as these metrics are essential for evaluating link performance [53].

For this simulation, we present an example topology for a future ground-to-cislunar space communication network, as shown in Fig. 8. The configured topology used in Fig. 8 is inspired by LunaNet study [54]. Although this topology is not the final state of space networks of LunaNet, it is the baseline of LunaNet communication architecture; so the topology of Fig. 8 has been chosen to demonstrate how the VS and SAABR can be applied in actual space environments. This configuration is based on interplanetary mission scenarios similar to NASA’s deep space network, illustrating efficient routing between various space assets with diverse physical link characteristics. This approach can significantly enhance communication reliability and performance in complex space networks among space agencies. As stated above, the VS excels at global cooperation and its efficiency in handling contact negotiation in LunaNet which constitutes heterogeneous nodes in different agencies. Varying conditions affecting the contact routing schedule by the VS may provide informative simulation outputs regarding trends in important network performance metrics, such as latency and transaction data rates. Communication links in Fig. 8 can be sectorized according to the affected region. The connectivity of each link in this study is illustrated in Fig. 9. The assumed return link data rate used in this simulation is also depicted in Fig. 9. The number beside the Connectivity line represents the link speed in megabits per second (Mbps). The current values assigned to the link speeds between nodes are hypothetically determined based on existing space communication methods, including optical communication. However, these values should be considered as reference points for the link metric analysis in this study, as they are subject to change in actual implementations. Note that this simulation analyzes only the return link metrics. It assumes the forward link characteristics have no significant impact on these metrics, despite the typical asymmetry between the two links in space communication. This assumption is valid because most forward link capacity is used for commanding and signaling.

A. Design of Geographically-aware Network Topology

DSN G, C, and M stand for DSN’s deep space antenna complexes in Goldstone, Canberra, and Madrid.

· DSN_G: Goldstone Deep Space Communications Complex, Near Barstow, California, United States, Approximately 35.4269[TeX:] $$^{\circ}$$ N latitude, 116.8889[TeX:] $$^{\circ}$$ W longitude.

· DSN_C: Canberra Deep Space Communication Complex, Near Madrid, Spain, Approximately 40.4272[TeX:] $$^{\circ}$$ N latitude, 4.2507[TeX:] $$^{\circ}$$ W longitude.

· DSN_M: Madrid Deep Space Communication Complex, Near Madrid, Spain, Approximately 40.4272[TeX:] $$^{\circ}$$ N latitude, 4.2507[TeX:] $$^{\circ}$$ W longitude.

Orbital information of the gateway in the near rectilinear halo orbit (NRHO) [55] is hypothetically determined using the following data.

· Orbital period: 6.5 days.

· Lunar distance

a) Perilune (closest): 3,000 km.

b) Apolune (farthest): 70,000 km.

In this study, two elliptical lunar frozen orbit (ELFO) relay satellites for lunar relay satellite (LRS), one per ELFO plane, are considered for simplicity, although four relay satellites per ELFO plane were considered in a previous study [56]. No direct contact with the rover and lander on the lunar surface from orbital communication relay assets or ground antennas is considered in this study. Rather, a central communication hub such as the lunar communication terminal (LCT) [57] may take on this responsibility for transceiving on behalf of lunar surface probe assets, even though these assets have this direct capability. The direct link capability to orbital communication relay assets or a ground station is limited to emergency use as a backup.

The model of orbital information for the geosynchronous Earth orbit (GEO) relay satellites is derived from one of NASA’s tracking and data relay satellites (TDRS) operating in GEO orbit [58].

In this simulation, communication relay assets between Earth and the lunar surface, including relay satellites at GEO, gateway at NRHO, and LRSs at ELFO, are considered to have two simultaneously operable channels: one toward Earth and one toward the Moon. However, they cannot be pointed in a single direction exclusively. This hypothetical channel uses a single beam, not a multi-beam, so it is only capable of tracking a single object. These relay nodes essentially operate as DTN nodes with an added custodian buffer for store-and-forward. For simplicity, the processing cost on a DTN node, including SAABR bundle creation and handling, is assumed to be zero, meaning it has no impact on delay in link metric analysis.

For rover or lander DTN nodes, two landing sites are determined using the following data.

· Rover_1: historical Apollo 11 landing site, landed on the Moon on July 20, 1969, at a site named Tranquility Base. The exact location of the landing site is 0.67408[TeX:] $$^{\circ}$$ N, 23.47297[TeX:] $$^{\circ}$$ E in the Mare Tranquillitatis region. Refer for more information on Apollo 11 at NASA’s Apollo 11 Mission Report. National Aeronautics and Space Administration website (https://www.nasa.gov/mission_pages/apollo/missions/ apollo11.html).

· Rover_2: it is located at the south pole on the Moon according to a study [59], hypothetical location is −136.2[TeX:] $$^{\circ}$$ N, −89.406[TeX:] $$^{\circ}$$ E.

The satellite contact analysis was conducted using systems tool kit (STK), software developed by analytical graphics, inc. (AGI), to evaluate communication windows between the DTN nodes and ground stations within the given topology. The simulation period is set from Dec 1, 2026 to Dec 31, 2026, during 31 days. As a result, a contact window information file was created for each node-to-node contact. This contact window information is transformed into a database holding self-annotated and advertised link opportunities provided by the nodes. It is assumed that all advertised link opportunities are received and analyzed by the VS, and that all nodes, especially end nodes on the Moon’s surface, know how to create and handle the DTN bundles, including SAABR messages, aka AA-CGR EB.

B. Development of Simulation Platform

A simulation platform was developed in C++ according to the rules described in Section IV to extract scheduled contact information based on SAABR. This simulation software is fully compliant with POSIX standards and runs on Linux. Various C++ standard template library (STL) data structures and algorithms were utilized to efficiently store and process contact event information, including vectors for dynamic storage of events, priority queues for event scheduling, maps for quick lookups, and algorithms for sorting and filtering contact data. The software produces various contact metrics, such as contact begin and end times. The final output of this simulation software can be used to build pre-allocated contact events within an estimated contact prediction database pool created by a space flight dynamics analysis tool—in this study, STK. For simplicity, contact schedule allocation based on performance and priority is not considered within this simulation platform. Note that SAABR’s basic operation mechanism is fair-time allocation for each node. However, the contact allocation can be prioritized according to specific requirements, such as latency fairness, transferred data-volume fairness, or urgent E2E contact plans. The simulation flow sequences are depicted in Fig. 10.

The simulation run step is 1 minute, as the contact window information generated by STK is presented every minute. For easy access to the contact window information, this information is catalogued using an STL vector database, ordered by time for each node-to-node connection. During catalog generation, the start time and end time of the simulation are determined. Additionally, initialization of the simulation parameters is performed at this step.

The first process of each time interval (i.e., 1 minute) is to identify the winner of the current contact window for each node-to-node connection until the entire network topology is thoroughly checked before moving to the next simulation time. The winning contact is either established as a new connection or maintains its current connection, allowing its link parameters to be used in link metric analysis. After link metrics update, simulation time is updated as 1 minute amount for next simulation run. If there are multiple nodes contending for becoming winner, arbitration logic described in Section IV is applied to adjust the link opportunities by the given rules.

The first step of each time interval (i.e., 1 minute) is to identify the winner of the current contact window for each node-to-node connection. This process continues until the entire network topology is thoroughly checked before moving to the next simulation time. By allocating contact through the parameter of minimum contact time, a node is guaranteed to maintain communication, ensuring an even distribution of contact opportunities. Selecting the winner of a contact means that this node-to-node contact is chosen to reflect its link parameters in the link metric analysis. After the link metrics are updated, the simulation time is incremented by 1 minute for the next simulation run. If multiple nodes are contending to become the winner, the arbitration logic described in Section IV is applied to adjust the link opportunities according to the given rules.

It shall be noted again that this simulation only runs for the return link from the lunar surface to ground stations. Every contact has two adjacent nodes, i.e., a left node and a right node, if applicable. Rover nodes on the lunar surface must be end nodes, as they are the starting points of the data transaction analysis. Ground stations, i.e., DSN sites, are also end nodes but are designated as ground nodes in this simulation; they are the leftmost nodes. The rover is the rightmost node. Therefore, a right node of a contact refers to a node closer to the rover nodes, while a left node of a contact refers to a node closer to the ground nodes.

When a contact of a node-to-node is approved, i.e., becoming the winner of the current simulation time, link metrics are updated according to the predefined link performance parameters. During this step, latency and transferred data volume from a right node to a left node are updated accordingly. All data generated by the rightmost node, i.e., the rover node, are tagged with the generated simulation time and are monitored for tracing delivery status until they reach the leftmost node, i.e., the ground node. Due to the unfair allocation of link speed in the suggested topology, some portions of the data transaction cannot be transferred within a given contact time; the remaining portions are transferred at the next allocated contact, regardless of the size of the span. For simplicity, link interference and link failure from BER are not considered in this simulation. Additionally, each node is assumed to have infinite internal storage, preventing any interruption due to resource capacity constraints. Link metrics are logged and printed at the end of the simulation for stored volume, as well as the minimum, average, maximum, and median latency, with variances and standard deviations of the values, along with the accumulated contact time and end-to-end connectivity during the simulation period. The median value is used because most of the latency measurements in the simulation are clustered around the minimum latency, whereas the average value is skewed by a few extremely high latency instances.

VI. SIMULATION RESULTS AND ANALYSIS

In this section, various simulation results illustrating the observational opportunities for the link characteristics of the simulation topology are presented. The simulation begins with several dry runs to establish the fundamental space communication link between the cis-lunar environment and the ground station. Subsequently, complex contact scenarios are evaluated in this simulation to estimate potential snapshots of cis-lunar communication environments and future link metrics. The parameters used in this simulation are summarized in Table III.

A. Dry Runs

First, we performed dry runs to assess basic cis-lunar communication characteristics using two scenarios: direct-to- Earth (DTE) contact from the lunar surface and minimal-relay paths. The results are summarized in Table IV.

^a Giga(10⁹) bits

^b Minimum latency, second

^c Average latency, second

^d Maximum latency, second

^e Median latency, second

^f Variance

^g Standard deviation

^h Accumulated contact time, seconds (days)

ⁱ End-to-end contact time, seconds (days)

These dry runs utilized the simplest contact configuration within the structured topology. The goal was to understand basic link metric behaviors through simple link-to-link contacts before advancing to more complex simulations with multiple contact conflicts.

RV_2 (Rover 2 located near the south pole) has lower link connectivity compared to RV_1. Even with support from DSN_G, DSN_C, and DSN_M, RV_2 does not achieve full direct connectivity, whereas RV_1 consistently maintains full connectivity with all DSNs. The presence of relay satellites in GEO provides better link coverage for RV_1, but RV_2 gains minimal benefit from the GEO relay satellite. On the contrary, the presence of a relay satellite in NRHO, i.e., gateway (abbreviated as GW in Table IV), does not provide a wide contact angle for RV_1 compared to RV_2. RV_2 has nearly continuous contact with gateway.

An LRS provides partial connectivity with RV_1 and RV_2 for 6–7 hours daily, highlighting the necessity of deploying four or more lunar relay satellites in cislunar space for nearcomplete coverage. Gateway and LRS present similar latency trends to the rovers; however, the combination of LRS and RV_1 has lower latency compared to other combinations involving gateway, LRS, RV_1, and RV_2.

In the final step of these dry runs, we tested the simplest contact conflict using links between GEO and RV_1, and between gateway and RV_2, to observe the impact of using the most effective relay assets. Note that contact scheduling by SAABR optimizes fair contact time distribution, resulting in RV_1 receiving about 15 days of contact allocation while competing with GW. Consequently, RV_1 and RV_2 share the contact opportunity in the E2E link. However, the scheduling system can be adapted for fair latency distribution or fair data delivery volume distribution. Relay assets in the middle zone can accumulate contact time exceeding 31 days (the aforementioned simulation period) due to their dual ports, which enable parallel data transactions in both directions (to Earth and to the Moon). The yielded volume of data transactions through this simulation is for reference only because changing the data rates for each link will certainly yield different values. Both RV_1 and RV_2 have an E2E link to Earth lasting around 15 days in this scenario. The ground experiences a worst-case latency of 2.68 hours for packet delivery completion, although most data arrives with minimal latency. Those results are for reference only and are intended to be used for understanding the basic trends in link metrics for simple link cases. More sophisticated simulation scenarios continue in the following section.

B. Operational Simulation

In this subsection, we present some operational simulation cases that are realistic for the future. Note that this simulation topology is focused on setting minimal and functionally limited cislunar communication environments that necessitate the VS and SAABR concepts, and this topology only intends to represent one of the possible snapshots of the future cislunar communication landscape. The results of the operational simulation are summarized in Table V.

The first three simulation scenarios involve DSN_G, DSN_C, and DSN_M, as well as RV_1 and RV_2, which are all single port end-point nodes. Using DSN_G, DSN_C, and DSN_M, RV_1 has full contact coverage with Earth, whereas RV_2 has only a 3.53-day open contact window with Earth. When DSN_G, DSN_C, and DSN_M support both RV_1 and RV_2, RV_2 has only 2.36 days of contact availability.

As pointed out in the dry run cases, GEO relay satellites, such as TDRS, provide a much wider contact window with RV_1, and RV_2 is allocated slightly more contact time compared to DSN-only cases; however, the contact is still limited to 7.12 days (approximately 23%) per month.

As mentioned in the dry run cases, Gateway significantly enhances the contact availability for RV_2, as shown in Table V. When included in the simulation topology, Gateway allows RV_2 to secure contact for almost a full month, without affecting RV_1’s contact opportunities.

The final operational simulation scenario includes LRSs in the topology configuration. LRS_1 and LRS_2 establish crosslinks with GEO_1, GEO_2, and GEO_3, while supporting RV_1 and RV_2. LRS_1 and LRS_2 have no cross-link with the Gateway. As a result, this case has shown that LRSs do not provide significant advantages in link metrics. Rather, worstcase latency increases for ground stations, and overall contact utilization across each communication node slightly decreases because all intermediate nodes, including GEO relay assets, are configured for single access in the lunar direction. Consequently, the GEO relay assets experience contact congestion when handling Gateway and LRS communications. However, this simulation represents only one of many possible snapshots in the future cis-lunar communication environment. Note that in this final topology, links between DSNs and Rovers are not included due to their low connectivity probability and low data throughput; these links are reserved for emergency backup. While optimizing these contact plans for better throughput is possible, such optimization lies beyond the scope of this study.

C. Assessment of the Simulation Results

The simulation results show various link metrics for the communication assets involved. A rover on the near side of the moon, not located in the polar region, receives support from GEO relay satellites, specifically TDRS. However, a rover in the polar region does not gain much benefit from DSNs and GEO relay satellites. Support from gateway in NRHO can assist this polar mission because usually DSNs and TDRS are heavily tasked with supporting deep space missions. LRS may act as a backup, but it requires regular transitions with the rover as new contacts begin and old ones end, which may introduce service transition latency. For future cis-lunar missions, other ground stations, such as lunar exploration ground sites (LEGS) or commercial ground stations, will be required instead of DSNs.

Using a converting tool, the simulation results can produce the required schedulable contact plan format according to desirable practices by users. This can also represent a feasible contact schedule scenario and produce actual contact plan commanding bundle following the approach suggested in this study as shown in Figs. 4 and 6.

The basic approach using the VS is based on fair contact distribution, with contact prediction by the VS and allocation and distribution by SAABR. As the simulation results show, the contact opportunity for RV_1 and RV_2 is approximately evenly distributed when Gateway and LRSs are included in the topology. However, without Gateway, it is harder to determine the contact plan for RV_2, as RV_2 is in a shadowed region by the ground communication facility. Therefore, special consideration for RV_2 may be necessary. Gateway will be essential for supporting missions on the far side of the moon. In this case, LRS’s role and importance will increase, as there is no direct link from ground stations and GEO relay satellites. The trends of the allocated contact time through the operational simulation scenarios are shown in Fig. 11. The allocated contact scenarios are highly achievable because the essential parameters of contact schedule of a node are generated by considering resource constraints such as computing power, consumable resources, and SWaP by the corresponding agency or expert group. Technically speaking, the correctness gap between estimation and reality in practice would be minimized through empirical iterations, and become controllable.

Note that data throughput, i.e., the accumulated volume, should only be used for reference and not heavily considered, as the changing data rate between nodes is the main driving factor behind this output.

The trends of the average latencies from ground stations are shown in Fig. 12, where DFE stands for direct from Earth. As can be referenced in Table V and Fig. 12, involving GW in the route path introduces very high variations of latency for some ground stations, with significant standard deviations as documented in Table V. This occurs due to queuing issues when significant amounts of queued data remain even after a contact is closed. Bundle transaction from ground station through GEO only to lunar surface shows minimal latency because the ground station to GEO link is established as a dedicated connection, whereas GW is a shared relay node, resulting in queuing issues with bundle priority problems. This effect needs to be handled with a certain policy for allowing it or not because it may induce unintended surplus latency. This issue affects all non point-to-point communication route development. To address the residual data queuing problem in intermediate nodes, empirical iterations would be required to establish an optimal balance among pre-negotiated contact time, bandwidth allocation for each contact, and the node’s bundle storage buffer capacity.

VII. CONCLUSION

This study presented the VS concept for centralized planning among deep space nodes where dynamic path support and negotiation are challenging. It proposed a schedule selfannotated and advertised bundle routing (SAABR) protocol for bundle protocol version 7 or later, designed to distribute pre-generated contact plans to participating nodes. SAABR enabled deep space nodes with limited computational power and mobility to utilize predefined contact commands. The contact planning logic could be optimized for fairness in data volume, timing, or latency based on specific requirements. The VS served as a contact planning service provider, leveraging ground stations’ flight dynamics analysis to forecast orbital positions of space communication relay satellites. This approach demonstrated advantages compared to real-time contact establishment at the moment when scheduled contact is met, which relies on proximity-based RF signal detection and negotiation under uncertain spacecraft conditions, though each method may be optimal depending on specific operational contexts. Supporting situations where contacts are established under uncertain conditions—such as battery depletion, exhausted on-board storage, or communication mode changes (RF frequency, polarization, and data rate that often change during mode transitions)—can be extremely important for rapidly recovering from abnormal network issues through ground intervention. Therefore, when such anomalies happen on DTN space network, the VS scheme can more rapidly identify the root cause of the anomaly throughout constituted collaboration framework on the system. In short, the reactivity for anomaly and recovering capability are the strong suite of the VS.

Simulations examined the feasibility of central contact routing versus real-time discovery for distributing routing opportunities across networks. The results confirmed Gateway’s crucial role in supporting lunar polar missions, particularly in conjunction with the lunar relay satellite for far-side lunar operations. While this study targeted potential future cis-lunar communication environments, the analysis of contact allocation across various operational scenarios provided valuable insights for future cis-lunar communication environments, until deep space communication achieves Earth-like QoS levels.

A fast and efficient broadcasting mechanism that handles contact change events within the network warrants consideration, irrespective of the routing methods previously discussed.

However, an unchecked contact scenario in this study is when a node enters an out-of-operating status and how we control the impact to suppress it as narrowly as possible during reconfiguration of the related network to support the troubled node. Since delivery mechanisms for the allocated contact schedule are involved in this process, significant temporal impacts need to be considered.

For future studies, contact planning and modification according to user-specific requirements and user feedback in mission operation centers—such as balancing preferences between extended contact durations and high-speed, shortduration end-to-end links—and securing urgent paths for supporting first-hop and last-hop (FHLH) [60] are areas of interest. Automation of antenna pointing and spacecraft body attitude control according to given contact opportunity is a certain area to be thoroughly considered for unmanned DTN space network operation. Development of an open-source tool supporting both ground- and central-based contact routing analysis would benefit the community.

ACKNOWLEDGMENT

The author would like to express sincere gratitude to Dr. Su-jin Choi for generating the orbital information data used in the topology for this simulation. Special thanks are also extended to Prof. Carlo Caini and Scott Burleigh for their valuable insights on contact graph routing.