Project Roadmap

Five phases from terrestrial validation to cislunar deep-space communication.

Phase Status

Complete Validated and operational

In Progress Currently active

Planned Future development

Phase 1: Terrestrial DTN Validation

In Progress
Hardware
Raspberry Pi + Mobilinkd TNC4 + Yaesu FT-817
Link Characteristics
VHF/UHF at 9600 baud (G3RUH GFSK)
Purpose
Ground-based validation using commercial amateur radio equipment. Two-node terrestrial network operational. Validated ping, store-and-forward, and telemetry.

Phase 1.5: QO-100 GEO Satellite DTN

Planned
Hardware
Ground station with 2.4 GHz uplink + 10 GHz downlink
Link Characteristics
QO-100 narrowband transponder (Es'hail-2 satellite)
Purpose
Geostationary satellite demonstration using QO-100 amateur transponder. Validate DTN over real satellite link with constant visibility. First space-based DTN demonstration before LEO orbital complexity.

Phase 2: CubeSat Engineering Model (EM)

Planned
Hardware
STM32U585 OBC + Software Defined Radio + External NVM
Link Characteristics
UHF 437 MHz / S-band 2.2 GHz
Purpose
Ground-based flatsat with flight-representative hardware. Validate flight software, power budget, thermal/vacuum readiness. Identical software stack to flight unit, lab-grade RF front-end.

Phase 3: LEO CubeSat Flight

Planned
Hardware
STM32U585 OBC + Flight IQ transceiver
Link Characteristics
UHF 437 MHz at 9.6 kbps
Purpose
Orbital deployment demonstrating ground-to-space DTN. Ground-to-space ping and store-and-forward. Handheld/small Yagi reception for broad community participation.

Phase 4: Cislunar Deep-Space Communication

Planned
Hardware
STM32U585 or more capable processor
Link Characteristics
S-band/X-band with LDPC/Turbo coding
Purpose
Amateur participation in Earth-Moon DTN. Earth-Moon distance (~384,400 km). 3-5m dishes for 500 bps cislunar links. Seeking support from the ESA ARTES programme for the prospective cislunar payload.

Future Enhancements

Cross-cutting capabilities planned to support all mission phases.

Contact Log — Versioned Contact-Plan and Run-Evidence Logging planned

A structured logging system that captures both planned (expected) and actual (observed) contact behavior for every DTN session. Enables cross-phase comparison of DTN performance across terrestrial, QO-100, LEO, and cislunar links.

  • • Versioned log entries — immutable, schema-versioned JSON records per session
  • • Cross-phase comparison — normalized goodput, plan adherence, and delivery success metrics
  • • Planned vs. actual — contact plan snapshot alongside observed timing and throughput
  • • Phase-aware metadata — link type, frequency band, OWLT, orbital parameters per session
  • • Integrates with Contact Plan Manager and HDTN telemetry automatically
  • • Machine-readable and human-readable — queryable by phase, time range, node pair, and outcome

Station Identification Beacon — Amateur Radio Compliance planned

Periodic BPv7 beacon bundles containing the operator's callsign and station metadata in plaintext, ensuring compliance with amateur radio regulations requiring station identification at least every 10 minutes.

  • • Regulatory compliance — plaintext callsign readable by any demodulating third party
  • • Analogous to FT8/WSPR — callsign in payload via well-known beacon service number (2048)
  • • Independent of data traffic — configurable timer (default 10 min) via HDTN infrastructure
  • • Includes station metadata — callsign, Maidenhead grid square, and node type
  • • Cross-phase — required for all phases from terrestrial through cislunar

Test Framework — Requirements-Based Verification (NASA TM Methodology) planned

A property-based test framework modeled after NASA Glenn's HDTN Test Framework (TM-20240014467 / LEW-20818-1), providing automated verification across all mission phases.

  • • Property-based testing — correctness properties verified for all inputs via randomized generation
  • • Requirements traceability — each test traces to system requirements for flight proposals
  • • Cross-phase coverage — validates BPv7 → LTP → KISS → G3RUH across all configurations
  • • NASA methodology — follows Glenn Research Center's published test framework approach
  • • CI integration — automated execution in the continuous integration pipeline
  • • Supports flight proposals — verification evidence for regulatory and ESA ARTES submissions

Multi-Node Contact Graph — Distributed Routing and Plan Distribution planned

A multi-node contact graph generator with time-dependent routing, enabling distributed ground station networks to route bundles through multiple intermediate nodes (ground relays, LEO satellites, GEO transponders, cislunar payloads) using store-and-forward semantics.

  • • Pairwise contact generation — automatic contact windows for terrestrial, GEO, LEO, and cislunar links
  • • Time-dependent Dijkstra routing — optimal multi-hop paths minimizing delivery time
  • • Four relay scenarios — ground relay, satellite relay, GEO backbone, multi-station coverage
  • • Storage-constrained routing — respects relay node buffer limits with priority preemption
  • • REST API distribution — ground stations receive plans via API with webhook push notifications
  • • OTA distribution — space nodes receive plan updates as administrative DTN bundles (≤5KB)
  • • Bootstrap plans — pre-loaded from initial TLE; converges to operational plan on first OTA update
  • • Plan versioning — monotonic versions with latest-wins conflict resolution
  • • HDTN-compatible export — local node view in NASA HDTN JSON format

DTN Abstraction Layer — Multi-Engine Support planned

An abstraction layer decoupling RADIANT services from any single DTN implementation, enabling support for multiple DTN engines (HDTN, ION-DTN, ESA DTN) through a common Go interface and plugin/adapter architecture.

  • • Common Engine interface — unified API for bundle creation, sending, receiving, and status
  • • Plugin registry — adapters registered by name with factory functions for dynamic instantiation
  • • HDTN adapter — wraps existing HDTN integration via REST API lifecycle management
  • • ION-DTN adapter — interfaces with JPL's Interplanetary Overlay Network via bp library
  • • µD3TN adapter — lightweight, space-tested implementation for microcontrollers (candidate flight software for CubeSat phases)
  • • Hardy adapter — modular Rust BPv7 implementation with no_std core libraries (candidate for memory-safe flight software)
  • • ESA DTN adapter — integrates European Space Agency's DTN daemon
  • • YAML configuration — switch engines without code changes
  • • Contact plan abstraction — shared contact plans independent of engine implementation
  • • Bundle serialization — common model with round-trip marshal/unmarshal properties
  • • Lifecycle events — state change callbacks for monitoring engine health

Contact Plan as a Service (CPaaS) — Centralised Contact Management planned

A centralised service treating contact plan information as a shared network resource, managed independently of the DTN implementation. Provides the authoritative source for network connectivity opportunities across all DTN engines.

  • • Canonical contact model — time-bounded directed links with data rate, OWLT, and confidence
  • • Node registry — typed nodes (ground station, LEO, GEO, cislunar) with capabilities
  • • REST CRUD API — create, query, update, and delete contacts programmatically
  • • Orbital prediction — automatic contact generation from TLE data with confidence decay
  • • Conflict detection — configurable resolution policies for overlapping contacts
  • • Multi-format export — HDTN JSON, ION commands, and canonical JSON serialization
  • • Push subscriptions — webhook/websocket notifications on plan changes
  • • OTA distribution — BPv7 plan update bundles for space nodes (≤5KB per bundle)
  • • Plan versioning — per-node and global monotonic versions with diff queries
  • • Role-based access control — admin, operator, and node roles with bearer token auth

RADIANT Network Orchestrator — Coordinated DTN Operations planned

The highest-level coordination component transforming RADIANT from a collection of independent DTN nodes into a platform for managing delay-tolerant network operations with topology discovery, policy-based routing, and delivery orchestration.

  • • Topology discovery — automatic network graph from CPaaS node registry and contacts
  • • Link state tracking — real-time Active/Scheduled/Degraded/Unavailable states
  • • Delivery request API — high-level destination + QoS requirements, orchestrator handles routing
  • • CGR path computation — Contact Graph Routing with confidence, latency, and hop constraints
  • • Service classes — Expedited, Standard, Bulk with bandwidth allocation and traffic classification
  • • Node trust management — operator-assigned trust levels affecting relay eligibility
  • • Telemetry collection — node and link metrics with rolling averages and retention
  • • Delivery statistics — success rates, latency, utilisation, and per-service-class breakdown
  • • Network visualisation — REST + WebSocket for real-time network map rendering
  • • Integrates with DTN Abstraction Layer and CPaaS for end-to-end coordination