Deep Space Network Simulator (DSNS)

• Deep Space Network Simulator (DSNS) is a modular, event-driven platform for simulating large-scale satellite and interplanetary communication networks.
• It leverages a global priority event queue and modular actors to realistically model orbital dynamics, dynamic connectivity, and protocol behavior.
• DSNS applications span PKI security analysis and scheduling for NASA's DSN, demonstrating scalability and efficiency under complex operational constraints.

Searching arXiv for recent and directly relevant papers on Deep Space Network Simulator (DSNS) and adjacent DSN simulation/scheduling work. Deep Space Network Simulator (DSNS) denotes a family of simulation environments for deep-space communication systems and, in recent literature, most specifically a modular, event-driven simulator for large-scale satellite and interplanetary networks. DSNS is designed to model orbital dynamics, line-of-sight constraints, dynamic connectivity, speed-of-light delays, protocol behavior, and traffic at scales ranging from terrestrial constellations to Earth–Moon–Mars architectures (Smailes et al., 6 Aug 2025). In security-oriented work, it is also presented as a new, event-based simulator for PKI and connection-management in large, realistic space networks (Smailes et al., 2024). In adjacent NASA Deep Space Network operations research, the term is used in a narrower sense for realistic weekly scheduling simulators whose core must reason over missions, antennas, visibility windows, setup and teardown, oversubscription, and mission fairness (Claudet et al., 2021).

1. Scope and research context

The literature exhibits two closely related uses of DSNS. One use treats DSNS as a network simulator for large satellite and interplanetary systems, with an emphasis on event-driven execution, abstract protocol models, and scalability to thousands or tens of thousands of nodes. The other treats DSNS as an operational simulator for NASA’s Deep Space Network, where the principal challenge is weekly allocation of antenna tracks under visibility, maintenance, and fairness constraints. These uses are complementary rather than contradictory: one centers on end-to-end networking and protocol behavior, the other on resource scheduling and operations.

Reference	DSNS role	Main focus
“DSNS: The Deep Space Network Simulator” (Smailes et al., 6 Aug 2025)	General-purpose DSNS	Large-scale satellite and interplanetary network simulation
“KeySpace: Public Key Infrastructure Considerations in Interplanetary Networks” (Smailes et al., 2024)	Security-focused DSNS	PKI, connection establishment, revocation, relay firewalls
“Scheduling the NASA Deep Space Network with Deep Reinforcement Learning” (Goh et al., 2021)	Scheduling-oriented DSNS context	Gym-compatible weekly scheduling environment
“$\Delta$-MILP: Deep Space Network Scheduling via Mixed-Integer Linear Programming” (Claudet et al., 2021)	Scheduling kernel for DSNS	Hard-constraint DSN scheduling core with fairness

The motivation for the network-oriented DSNS is the mismatch between emerging interplanetary architectures and the capabilities of existing simulators. The relevant problem class combines tens of thousands of satellites in LEO megaconstellations, multi-planet systems with relays, highly dynamic links, long disruptions, and large light-time delays. The 2025 DSNS paper argues that existing offerings do not collectively support orbital simulation, interplanetary networks, dynamic connectivity, dynamic timesteps, extensibility, scalability, and an abstracted network stack in the same framework (Smailes et al., 6 Aug 2025). The 2024 PKI study sharpens that motivation by focusing on a narrower but technically demanding question: whether terrestrial PKI mechanisms remain workable under intermittent, relay-based, multi-segment interplanetary connectivity (Smailes et al., 2024).

2. Event-driven architecture and execution model

In its general network form, DSNS is a discrete-event simulator organized around a global priority event queue. Each Event carries a timestamp, an event type, and associated data; the simulation loop pops the earliest event, advances simulation time, dispatches the event to registered actors, and repeats until the end time or an empty queue. Actors implement protocol logic, traffic generation, transmission behavior, or scenario-specific behavior, while DataProviders supply derived state such as routing information. The core mobility and connectivity engine is a MultiConstellation object maintaining Constellation instances and their OrbitalCenters (Smailes et al., 6 Aug 2025).

This architecture is explicitly modular. The simulator includes actors such as MessageRoutingActor, LinkTransmissionActor, and LTPActor, as well as scenario-specific traffic actors. Routing state can be supplied by RoutingDataProvider or LookaheadRoutingDataProvider. Because execution is event-driven rather than globally time-stepped, the simulator can jump across long idle intervals and still operate at high temporal resolution when link activity is dense. A configurable minimum delta between mobility or routing recomputations can be imposed to prevent excessive recomputation during high-event-rate periods (Smailes et al., 6 Aug 2025).

Node and link modeling is abstract but physically informed. Nodes represent satellites, ground stations, planetary bases, gateways, relay satellites, CAs, or attackers, depending on the study. Links can be fixed or dynamic, and can be instantiated by ISLHelper and ILLHelper. Propagation delay is modeled as

$\text{delay} = \frac{d}{c},$

where $d$ is inter-node distance and $c$ is the speed of light. Transmission time is modeled as

$$T_{\text{tx}} = \frac{\text{message size}}{\text{link bandwidth}}.$$

Links also carry configurable bandwidth, probabilistic loss, and queueing behavior. The general DSNS paper uses examples such as a 25 Mb/s default link bandwidth and default loss probabilities of 5% or 0.5%, depending on scenario class (Smailes et al., 6 Aug 2025).

Protocol support is intentionally layered above a message-level abstraction. DSNS implements best-effort delivery, store-and-forward delivery, and a modeled reliability layer based on Licklider Transmission Protocol. In the LTP model, messages are split into red and green segments, checkpoint and report segments are exchanged, missing segments are retransmitted, and sessions are canceled after configurable timeout and retransmission limits. In the Earth Observation CCSDS reference scenario with 5% loss, the simulator reports 2.93% delivery for best effort, 16.76% for store and forward, and 100% for store-and-forward plus LTP, with the higher reliability obtained at the cost of increased latency (Smailes et al., 6 Aug 2025).

3. Mobility, connectivity, and scenario classes

DSNS supports multiple mobility models. Constellations may consist of fixed points, Walker constellations, or TLE-derived satellites propagated with SGP4. Distinct OrbitalCenters allow simultaneous modeling of Earth-, Moon-, and Mars-centered systems without the precision problems that arise when short-range LEO links and long interplanetary links are embedded in a single coordinate origin. Connectivity is recomputed from positions and can depend on line of sight, range thresholds, elevation constraints, and planetary occlusion (Smailes et al., 6 Aug 2025).

The scenario library is correspondingly broad. The general DSNS paper enumerates fixed terrestrial networks, ground station networks, LEO megaconstellations, federated constellations based on real TLEs, Earth–Moon systems, Earth–Mars systems, and combined Earth–Mars–Moon architectures. It also implements the CCSDS DTN simulation reference scenarios for Earth Observation, Lunar Communication, and Mars Communication (Smailes et al., 6 Aug 2025). The PKI paper uses a partly overlapping but security-specific scenario set: an Iridium-like LEO constellation with 66 satellites, Starlink Phase-1 shell with 1584 satellites, a federation of 121 real CubeSats, mixed LEO/MEO/GEO federations, and an Earth–Moon–Mars network with one relay satellite at Moon, one at Mars, Earth LEO and ground infrastructure, lunar and Martian constellations, and DSN-like ground stations acting as interplanetary relays (Smailes et al., 2024).

These models are contact-centric rather than link-budget-centric. Connectivity changes are driven primarily by orbital geometry, occlusions, and helper-defined policies. A complementary system, the Interplanetary Network Visualizer, covers similar ground in topology generation and contact-plan visualization but is explicitly a visualization and planning support tool rather than a full network simulator. It imports and exports contact plans compatible with NASA’s ION and HDTN formats and focuses on time-varying geometry, latency, and occlusion rather than queueing, routing, or transport behavior (Bihan et al., 2024). This suggests a natural division of labor in which DSNS supplies the event-driven protocol simulation and tools such as IPN-V provide visualization and contact-plan inspection.

4. PKI, connection establishment, and revocation studies

The PKI-oriented DSNS paper models connection establishment as an authenticated message exchange rather than a full TLS stack. Messages are not acknowledged, retransmissions are not modeled, and routing is assumed optimal with lookahead into future connectivity states. Within that abstraction, DSNS measures establishment overhead $T_E$, revocation coverage time $T_R(s)$ for a segment $s$, and attack penetration $P(s)$, defined as the proportion of nodes in segment $s$ that accept an attacker’s message sent at the same time as a revocation was issued (Smailes et al., 2024).

The simulator evaluates CRLs, CRL Broadcast, OCSP, OCSP Stapling, OCSP with Validators, and two new configuration ideas. The first is OCSP Hybrid, in which OCSP Stapling is used within a segment and in-transit validation is used for cross-segment traffic, with CAs located at relays between segments. The second is the use of relay nodes as firewalls, exploiting the fact that intersegment traffic must traverse a small set of relays. In the model, a relay with current revocation information can drop or invalidate messages tied to revoked keys before they consume interplanetary link capacity or reach remote segments (Smailes et al., 2024).

The principal findings are architectural. A single centralized CA on Earth is reported as infeasible for interplanetary networks because establishment overhead becomes very large. Distributed CAs, by contrast, make terrestrial PKI mechanisms viable in deep space. OCSP Hybrid yields low establishment overhead on interplanetary paths while avoiding the requirement that all traffic traverse CAs. Relay firewalls substantially reduce cross-segment attack reach; in some configurations the reported revocation coverage times for remote segments become negative, meaning the revocation or firewall state arrives effectively before an attack message could traverse the relevant relay path (Smailes et al., 2024). Within the scope of the paper, DSNS therefore serves as an “interplanetary PKI lab,” exposing race conditions between revocations and attacker traffic that depend directly on orbital geometry and light-time.

5. Scheduling-oriented DSNS in NASA Deep Space Network operations

A second DSNS tradition is rooted in operations research for NASA’s Deep Space Network. Here the central objects are antennas, missions, activities, view periods, and tracks. The deep RL scheduling paper formulates a Gym-compatible weekly scheduling environment in which the inputs are User Loading Profiles, ephemeris-based view periods, and maintenance windows. Episodes correspond to one week’s scheduling problem; the state is a fixed-length vector of size 518; the action is a request index $\text{delay} = \frac{d}{c},$0; and the environment greedily allocates the longest valid view period after the agent chooses which request to schedule next (Goh et al., 2021).

This scheduling environment encodes antenna availability, visibility constraints, minimum durations, setup and teardown times, and multi-antenna overlap requirements. The reward is

$\text{delay} = \frac{d}{c},$1

so the agent is rewarded for selecting requests that can still be placed under current resource and view-period constraints. In Week 44 of 2016, the PPO-trained agent scheduled 1,007 hours out of 1,770 requested, versus 944 for a random baseline, and satisfied 188 requests versus 180, with slightly improved fairness as measured by $\text{delay} = \frac{d}{c},$2 (Goh et al., 2021). The paper characterizes this as a proof of concept that a deep RL agent can learn heuristics used by expert DSN schedulers.

The $\text{delay} = \frac{d}{c},$3-MILP work treats the scheduling core more formally. It defines resource–view, activity–view, mission–activity, and view–time mappings; binary time-indexed allocation, start, end, setup, and teardown variables; and a weekly horizon discretized into 15-minute frames. Its added constraints address two operational issues absent from the earlier MILP formulation: splitting larger tracks into shorter segments with correct setup and teardown accounting, and preventing cross-antenna overlap of tracks for the same mission. The mission-level exclusivity rule is expressed as

$\text{delay} = \frac{d}{c},$4

A dynamic objective heuristic then reweights mission activity and view weights to improve fairness and to prioritize special cases such as emergencies and landings (Claudet et al., 2021).

For DSNS design in the operational sense, $\text{delay} = \frac{d}{c},$5-MILP functions as a hard-constraint scheduling kernel. The paper states that it satisfies 100% of the requested constraints and produces 100% valid tracks across tested oversubscribed weeks, while improving fairness relative to the previous MILP. On Week 44 of 2016 it scheduled 901 hours, or 63.5% of requested time, satisfied 208 of 284 requests, achieved $\text{delay} = \frac{d}{c},$6, and maintained a minimum mission satisfaction of 45.8% (Claudet et al., 2021). A plausible implication is that high-fidelity DSN operations simulators can use RL environments for heuristic policy learning and MILP formulations for hard feasibility and repair.

6. Performance, interoperability, limitations, and extensions

The general DSNS paper emphasizes scalability. In a Walker-constellation benchmark with up to 50,688 satellites, 12 ground stations, and traffic ranging from none to a high-traffic regime, DSNS remains faster than real time in all tested configurations on a single CPU core, while memory usage stays below 2.1 GB. With fewer nodes or lower traffic, runtime is reported as tens to hundreds of times faster than real time. The paper contrasts this with figures cited for Stardust, StarryNet, and Hypatia, arguing that DSNS exceeds existing tools in scale while maintaining realistic orbital and link modeling (Smailes et al., 6 Aug 2025).

The simulator’s extensibility follows from its actor and provider abstractions. New routing algorithms can be implemented by extending RoutingDataProvider; new protocols can be inserted as actors consuming and emitting message events; new mobility models can be introduced by overriding Constellation; and helper scripts such as ccsds_reference.py and custom_reference.py instantiate the reference scenarios used in the paper (Smailes et al., 6 Aug 2025). In the PKI study, DSNS is likewise described as an event-based system whose computational requirements are governed only by the number of events generated by the simulation, rather than by detailed emulation of full protocol stacks (Smailes et al., 2024).

The present limitations are equally clear. The 2025 DSNS does not directly implement the full CCSDS JSON/CSV scenario specification, its routing strategies rely on global knowledge, and its lower-layer physical model is limited to speed-of-light delay, bandwidth, queues, and probabilistic loss rather than full RF or link-budget modeling (Smailes et al., 6 Aug 2025). The PKI study does not model full network stacks, bandwidth limits, retransmissions, or cryptographic computation costs; messages are simply delivered or dropped under an idealized routing model (Smailes et al., 2024). The scheduling-focused RL environment omits explicit priorities in the reward, track splitting across days, MSPA, and many human negotiation features of real DSN operations (Goh et al., 2021).

Adjacent work identifies several physically richer extensions. A DSNS intended to study deep-space file transfer at Ka-band would need real-time SNR prediction, dynamic turbo code-rate selection, and RaptorQ-coded file transfer under RTTs of 6.5–44 minutes; the DCSM study reports about 20% higher file transfer rate than a static scheme under such assumptions (Adhikary et al., 2018). A DSNS intended to model DSN pulsar-timing use would need 70-m antenna models, 1325–1965 MHz L-band reception, 1280 MHz sampling, PPS-aligned start-time definition, coherent dedispersion, and timing-pipeline behavior consistent with short-term residuals of less than 100 ns for PSR B1937+21 at DSS-14 (Kocz et al., 2017). This suggests that DSNS is best understood not as a single fixed simulator, but as a modular simulation substrate whose current literature spans large-scale DTN networking, PKI/security analysis, and operational DSN scheduling, and whose future extensions are likely to couple those layers more tightly.