🎓 Course — 42 Lessons 42
Learn
Demo
Study
Project
🖹️ Web Deck ⭐ GitHub
AETHERIX Logo
AETHERIX
Building the Internet for Mars — A communication platform that sends data reliably between Earth and Mars, despite 3 to 22 minutes of signal delay.
BPv7 · RFC 9171 QKD · BB84 / E91 1550nm Optical RL Routing 5-Tier Network
✓ Exam Passed EduQual Level 6 · Sep 2026 Overall 80.5%
Al Nafi EduQual Level 6 oral — Diploma in AI Operations (Topic 59): Presentation 23/25 · Interview 17.25/25 · Overall 40.25/50. ▶ Recorded session · Verified session record →
5
Network Tiers
241
Nodes
200
Max Mbps
1550
nm Wavelength
780
Day Synodic Period
480
Unit Tests
🚀
What is AETHERIX?
AETHERIX is a communication system designed to send data reliably between Earth and Mars. Think of it as building the internet — but for outer space. Regular internet protocols can't handle the extreme delays and intermittent connections of deep space. AETHERIX solves this with four key innovations: delay-tolerant networking, AI-powered routing, quantum-secure encryption, and laser communications.
Featured on LinkedIn
View full post →
⚡ The Challenge
Earth–Mars Distance

Mars orbits the Sun at a different speed than Earth, meaning the distance between them constantly changes over a 780-day cycle:

📏
Distance Range
Closest: 55 million km (3 min signal delay) · Average: 225 million km (12.5 min) · Farthest: 401 million km (22 min)
Why the Internet Doesn’t Work in Space

TCP/IP — the protocol that powers the internet — assumes instant responses and continuous connections. In space, those assumptions break down:

⚠
The Problem
A round-trip to Mars takes 6 to 44 minutes. During solar conjunction (when Mars is behind the Sun), there’s a 2-week complete blackout. TCP would time out and fail.
❖ The Solution — Four Key Innovations
📦

Delay-Tolerant Networking

Messages are packaged into “bundles” that hop from node to node, waiting at each stop until the next connection is available. Like postal mail — not a phone call.

RFC 9171 CCSDS 734.2-B-1
🤖

AI-Powered Routing

Instead of fixed routing tables, our AI agent learns the best paths through the network by trial and error, adapting to changing conditions in real time.

Q-Learning Multi-Agent
🔐

Quantum Security

Using the laws of quantum physics to create unbreakable encryption. Any eavesdropping attempt is physically detectable — secured by nature itself.

BB84 E91 QBER < 11%
🔬

Optical Communications

Using infrared lasers instead of radio waves for 10–100× faster data transfer. Like upgrading from dial-up to fiber optic — in space.

1550nm 2–200 Mbps
🎯
Start Your Journey
Click “Start Your Journey” above to learn how each of these technologies works, or jump straight to the interactive demos to see them in action. No prior knowledge required — we’ll guide you from zero to expert.
📚
Built on Real Standards
AETHERIX isn’t science fiction. It’s built on RFC 9171 (the IETF standard for Bundle Protocol v7), CCSDS standards (used by NASA, ESA, and JAXA), and well-established quantum cryptography protocols (BB84, E91). Every calculation in the demos uses real physics and real orbital mechanics.
🎓
Who Is This For?
Whether you’re a student curious about space communication, an engineer interested in DTN protocols, or a researcher exploring quantum security — AETHERIX has something for you. Start with the “Learn” section for plain-language explanations, then explore the interactive demos for hands-on experience.
💡
Reading Time
The full learning journey (Welcome → What is DTN → How It Works → Journey to Mars → The Network → Space Security → Why It Matters) takes about 15–20 minutes. Each page builds on the previous one, but you can also jump to any topic independently.
💡
Think of it Like the Postal Service
When you send a letter, it doesn’t travel directly from sender to recipient. It goes through post offices, sorting centers, and delivery trucks — stopping at each one before moving to the next. DTN works the same way for data in space. Each stop (called a “node”) receives the data, keeps it safe, and forwards it when a connection becomes available.
⚠ Why TCP/IP Doesn’t Work in Space
What the Internet Expects
  • ✗ Instant response (< 1 second round trip)
  • ✗ Continuous, unbroken connection
  • ✗ Data arrives in perfect order
  • ✗ Both sides active simultaneously
What Space Actually Provides
  • ✓ 6 to 44 minute round-trip delay
  • ✓ Intermittent, scheduled connections
  • ✓ Data may arrive out of order
  • ✓ 2-week solar conjunction blackouts
⚡
The Fundamental Insight
TCP/IP was designed for Earth, where computers are always connected and signals travel in milliseconds. Space has none of those luxuries. We need a completely different approach — one that embraces delay and disconnection as normal operating conditions.
📦 How Store-and-Forward Works

Instead of requiring an end-to-end connection, DTN breaks the journey into hops. At each hop, the data is stored safely until the next connection window opens.

1

Create

The sender packages data into a “bundle” with a destination address, priority level, and lifetime. Think of it as addressing a package with tracking information.

2

Store

The bundle waits at the current node until a communication link to the next hop becomes available. This could be minutes, hours, or even days — the data is safe.

3

Forward

When the link opens, the bundle is transmitted to the next node in the path. Each transmission is confirmed before the bundle moves on.

4

Custody Transfer

The receiving node takes legal “custody” of the bundle — it’s now responsible for safe delivery. If anything goes wrong, the data isn’t lost. It’s like registered mail with guaranteed delivery.

5

Deliver

Steps 2–4 repeat until the bundle reaches its final destination. The entire journey might take hours, but the data arrives intact and verified.

📋
What is a Bundle?
A bundle is like a data packet but much smarter. It includes: source and destination addresses (like dtn://mars.rover-01/science), priority level (Emergency → Bulk, 5 levels), lifetime (how long it’s valid), custody tracking (who’s responsible right now), and the payload (actual data — up to gigabytes). Unlike regular packets, bundles can be millions of times larger.
🔔 Priority Levels Explained

Not all data is equally urgent. BPv7 defines 5 priority classes so the network can make intelligent decisions about what to send first when bandwidth is limited.

Emergency

Life-threatening alerts, abort commands. Must be delivered immediately — bypasses all other traffic. Think: “Solar flare incoming, take cover now.”

Priority & Normal

Telemetry, navigation updates, time-sensitive science data. Standard operational traffic — the majority of daily communications.

Expedited & Bulk

Software updates, archive dumps, high-res image batches. Can wait for off-peak windows — delivered when capacity allows.

🔌
What Are Convergence Layers?
Bundles don’t travel raw — they ride on “convergence layers” adapted to each link type. TCPCL (RFC 7242) handles reliable Earth-segment links. LTP (RFC 5326, named after J.C.R. Licklider) handles long-delay deep-space links with retransmission. UDPCL handles fast optical inter-satellite links. Each layer translates bundles into the right format for its physical connection.
📊 Store-and-Forward Visualized
DTN Store-and-Forward Flow
DTN Store-and-Forward Flow — Bundles hop from node to node, stored safely at each stop until the next contact window opens. No end-to-end connection required.
Challenge
TCP/IP requires continuous end-to-end connectivity — impossible with 3–22 min signal delays and 2-week solar conjunction blackouts.
Purpose
Shows how DTN decouples sending from delivery — each node stores the bundle and forwards it only when the next link is available.
Impact
Data is never lost even if links drop. AETHERIX achieves 98.7% delivery ratio with <5% protocol overhead.
🚀
DTN in the Real World
DTN isn’t theoretical — it’s already deployed. NASA’s Disruption Tolerant Networking experiment on the ISS successfully demonstrated interplanetary protocols in 2016. The Mars 2020 Perseverance rover uses DTN principles for data relay through orbiters. Even terrestrial networks use DTN for disaster response, Arctic communications, and military tactical networks where connectivity is unreliable.
📜 Bundle Protocol v7 — The Standard
RFC 9171 — IETF Standard (January 2022)

Bundle Protocol v7 (BPv7) is the official IETF standard for delay-tolerant networking, developed jointly with CCSDS (the international body for space communications). It defines how bundles are created, addressed, routed, and delivered across challenged networks — from deep space to disaster zones.

RFC 9171 CCSDS 734.2-B-1 CCSDS 734.2-B-1 RFC 5326 LTP
🔬

Optical Link Budget

Laser Communications at 1550nm

Instead of radio waves, AETHERIX uses infrared lasers (1550nm wavelength) to beam data through space. This allows 10–100× higher data rates than traditional RF systems.

📊
What this means
Where Mars Reconnaissance Orbiter sends 0.5–6 Mbps via radio, AETHERIX achieves 2–200 Mbps via laser — enough for high-definition video from Mars.
📏
Why 1550nm?
This wavelength is the same used in fiber optic networks on Earth. It’s well-understood, has minimal atmospheric interference, and is eye-safe — ideal for high-power space transmitters.
🤖

Reinforcement Learning Routing

AI That Learns the Best Path

Traditional space networks use fixed routing tables that must be manually updated. AETHERIX uses a reinforcement learning agent that learns from experience which paths work best.

🧠
What this means
The network adapts to unexpected outages, congestion, and changing link quality without human intervention — critical when a response from Earth takes 20+ minutes.
🎯
How Does RL Work?
The agent tries different routing decisions and gets “rewards” for good outcomes (fast delivery) and “penalties” for bad ones (delays, drops). Over time, it learns the best strategy — similar to how humans learn from trial and error.
🔐

Quantum Key Distribution

Unbreakable Encryption from Physics

AETHERIX uses quantum mechanics to securely distribute encryption keys. Any attempt to eavesdrop physically disturbs the quantum states, alerting both parties immediately.

⚗
What this means
Even a future quantum computer couldn’t break this encryption. It’s secured by the fundamental laws of physics, not computational difficulty.
🔬
BB84 Protocol Simplified
Alice sends photons in random orientations. Bob measures them. They compare which orientations they used (not the actual bits). Where they agree, they keep those bits as a shared key. If the error rate exceeds 11%, someone tried to listen in.
🌐

5-Tier Network Architecture

241 Nodes Across 5 Layers

The network spans from Earth’s surface to Mars’s surface through 5 distinct tiers, with relay satellites at Lagrange points maintaining connectivity even during solar conjunction blackouts.

🏗
The 5 Tiers
T1 Earth Ground (DSN stations) → T2 Earth Orbital (GEO + LEO laser mesh) → T3 Deep Space (Lagrange relays) → T4 Mars Orbital (relay orbiters) → T5 Mars Surface (rovers, bases, sensors)
🛰
Why Lagrange Points?
The Earth-Sun L4 and L5 points are gravitationally stable positions where relay satellites maintain line-of-sight to both planets — even when Mars is behind the Sun. This eliminates the 2-week communication blackout.
📈
The Reward Function
The RL agent optimizes a multi-objective reward: R = α(delivery) − β(delay) − γ(hops) − δ(drops) − ε(energy). Each Greek letter is a tunable weight — mission operators can prioritize speed for emergency traffic or energy efficiency for bulk science data. The agent learns the optimal trade-offs through thousands of simulated contact windows.
🛠 Convergence Layers — The Translation Layer
TCPCL (RFC 7242)

Earth-segment links between ground stations and GEO relays. Reliable, ordered delivery over TCP — similar to how web browsers communicate, but carrying space bundles.

LTP (RFC 5326)

Deep-space links between Lagrange relays and Mars orbiters. Handles 3–22 minute delays with selective retransmission — only resend what was lost, not the whole bundle.

UDPCL (Optical ISL)

Inter-satellite laser links within constellations. Fragmented delivery with simulated packet loss — optimized for speed over the LEO and GEO laser mesh.

⚠
Why Not Just Use Contact Graph Routing?
Traditional Contact Graph Routing (CGR) uses pre-computed routing tables based on known contact schedules. But space is unpredictable — solar storms disrupt links, satellites drift, and equipment fails. CGR requires manual updates sent from Earth (taking 20+ minutes to arrive). The RL agent adapts in real-time, learning from actual network conditions rather than relying on plans that may already be outdated.
🧠
Multi-Agent Federated Learning
Each node runs its own RL agent with local observations. Periodically, agents share learned Q-tables (routing experience) and aggregate them — similar to how a team of explorers shares maps they’ve each drawn. This means every node benefits from the collective experience of the entire network, without sending raw data centrally.
📊 Architecture & Data Flow
System Architecture
System Architecture — Five core modules feed into the simulation engine and web showcase, built on CCSDS/IETF standards.
Challenge
Interplanetary networking requires integrating link analysis, adaptive routing, quantum security, and orbital mechanics into a cohesive system.
Purpose
Maps the five source modules (Infrastructure, Routing, Security, Orbital, Simulation) to their engines and interactive showcase pages.
Impact
All 44 modules, 768 tests, and 15 demos trace back to this architecture — every component is independently testable.
Protocol Stack
Protocol Stack — From application layer down through BPv7, convergence layers (LTP, TCPCL, UDPCL), to the physical optical/RF links.
Challenge
Standard internet protocols (TCP/IP) fail catastrophically at interplanetary distances — timeouts, connection resets, retransmission storms.
Purpose
Visualizes the BPv7 stack from RFC 9171 — showing how bundles traverse LTP (deep space), TCPCL (Earth), and UDPCL (optical ISL).
Impact
Standards-compliant design (RFC 9171, RFC 5326, CCSDS 734.2-B-1) ensures interoperability with NASA's ION-DTN implementation.
End-to-End Data Flow
End-to-End Data Flow — How a bundle travels from Mars surface through all protocol layers to Earth mission control in 7 hops.
Challenge
A 500 MB science dataset must traverse 7 network hops across 5 tiers, switching between UHF, optical laser, and TCP/IP — without losing a single byte.
Purpose
Traces the complete bundle lifecycle: creation → RL route selection → LTP segmentation → optical transmission → reassembly → delivery confirmation.
Impact
Total transfer takes ~13 min vs 12.5 min light-time — near speed-of-light delivery with DTN overhead under 5%.
🌍
How Far Is Mars, Really?
Mars and Earth both orbit the Sun, but at different speeds. Earth completes an orbit in 365 days, Mars in 687 days. This means the distance between them is constantly changing — from as close as 55 million km to as far as 401 million km. That’s a 7× difference in distance over the course of the synodic period.
📏 Distance Ranges Explained
Closest Approach (Opposition)
55M km

Signal delay: ~3 minutes one way. Data rates can reach 200 Mbps — comparable to home broadband. This is the golden window.

⏱
Happens roughly every 26 months. Last opportunity: Jan 2025. Next: Feb 2027.
Average Distance
225M km

Signal delay: ~12.5 minutes one way. Data rates: 10–20 Mbps. This is the typical operating condition.

💡
225M km is about 1.5 AU — 1.5 times the distance from Earth to the Sun.
Maximum Distance (Conjunction)
401M km

Signal delay: ~22 minutes one way. Data rates drop to 2–5 Mbps. And Mars is behind the Sun — direct communication is blocked.

⚠
2-week blackout during solar conjunction. No direct communication possible.
⏱ The Speed of Light Problem
⚡
Why Can’t We Just Speed Up the Signal?
Radio signals, lasers, and all electromagnetic radiation travel at the speed of light — approximately 300,000 km per second. This is the absolute speed limit of the universe (Einstein’s special relativity). No amount of engineering can make data travel faster. AETHERIX works around this limit using delay-tolerant networking — accepting the delay and designing systems that work reliably despite it.
Light-Time Delay — A Thought Experiment

Imagine you’re an astronaut on Mars and you send a message to Mission Control: “We found something interesting!”

  • T+0 min You send the message from Mars
  • T+12 min Message arrives at Earth (average distance)
  • T+12 min Mission Control reads it and immediately replies: “Tell us more!”
  • T+24 min You receive the reply. 25 minutes for a simple back-and-forth.
💡
The Implication
Real-time conversation is impossible. Mars astronauts must be able to make decisions autonomously. The communication system must be able to handle delayed, asynchronous exchanges — exactly what DTN is designed for.
🌏 The Synodic Period — Why Conditions Repeat Every 780 Days
Orbital Dance

Earth orbits the Sun every 365.25 days. Mars takes 686.98 days. Because they move at different speeds, Earth “laps” Mars roughly every 780 days (the synodic period). This creates a repeating pattern:

Day 0 Conjunction — farthest, solar blackout
Day 390 Opposition — closest, best conditions
Day 780 Back to conjunction — cycle repeats
Contact Windows

Communication isn’t available 24/7. Contact windows are scheduled periods when a ground station on Earth has line-of-sight to a Mars orbiter or relay:

📅
Typical Contact Schedule
Opposition: 8–12 hrs/day · Quadrature: 4–8 hrs/day · Conjunction: 0 hrs (direct) or 2–4 hrs (via Lagrange relays)
🔬
Try It Yourself
The Orbital Mechanics demo in the Demo section lets you calculate contact windows for any time period. You can see exactly when communication is possible and what data rates to expect.
📊 Earth–Mars Distance Over Time
Earth-Mars Distance Over Synodic Period
Distance Over 780-Day Synodic Period — The distance cycles from 54.6M km (opposition) to 401M km (conjunction), directly impacting data rates and latency.
Challenge
Earth and Mars orbit at different speeds, creating a 7× distance variation (54.6M to 401M km) over 780 days that makes link performance wildly inconsistent.
Purpose
Plots the exact distance curve so mission planners can predict when data rates will be highest and schedule bulk transfers accordingly.
Impact
Enables 10–200 Mbps at opposition but drops to 2–5 Mbps at conjunction — bandwidth planning is critical for 50–100 GB daily targets.
Contact Window Availability
Contact Window Availability — Communication hours per day vary dramatically across the synodic period, from 12 hrs at opposition to zero during conjunction.
Challenge
Ground stations only see Mars for limited windows each day, and during solar conjunction there is zero direct line-of-sight for ~2 weeks.
Purpose
Shows daily available communication hours across the full synodic period, including the critical conjunction blackout gap.
Impact
AETHERIX's Lagrange point relays (L4/L5) maintain 50–70% capacity during conjunction, raising overall availability from 60–75% to >95%.
Earth-Mars Data Journey
The 7-Hop Data Journey — From Perseverance rover on Mars surface through areostationary relay, deep-space Lagrange relays, LEO constellation, to DSN ground station and JPL.
Challenge
Mars surface assets (rovers, sensors) have only low-power UHF radios — they cannot reach Earth directly across 225M km.
Purpose
Maps the exact 7-hop path: UHF → areostationary → polar orbiter → L5 Lagrange → LEO mesh → DSN → JPL, showing each link technology.
Impact
The RL agent selects this route in real-time, rerouting around failures. If hop 4 drops, the bundle is stored and rerouted via L4 — no data loss.
🌐
Why Do We Need 241 Nodes?
The internet works because there are thousands of routers creating redundant paths between any two points. Space is no different — we need multiple relay points between Earth and Mars to ensure data always has a path forward. 241 nodes across 5 tiers provides enough redundancy that the network survives individual satellite failures, scheduled maintenance, and solar conjunction blackouts.
🏗 The 5 Tiers Explained
T1

Earth Ground Stations

5 nodes — NASA’s Deep Space Network (DSN): Goldstone (California), Madrid (Spain), Canberra (Australia), plus the Mission Operations Center and Science Operations Center.

📡
Why 3 DSN Sites?
Placed roughly 120° apart around the globe so at least one station always has line-of-sight to any point in deep space, 24 hours a day.
T2

Earth Orbital Relays

51 nodes — 3 GEO relay satellites for continuous Earth coverage, plus 48 LEO satellites forming a laser inter-satellite mesh (similar to SpaceX Starlink, but for deep space backhaul).

🔬
Laser Mesh in LEO
The 48 LEO satellites use laser links to communicate with each other, creating a high-bandwidth backbone in orbit. Data can be routed through the mesh to reach any ground station, regardless of which satellite first received the Mars transmission.
T3

Deep Space Transit

4 nodes — Relay satellites at Earth-Sun Lagrange points L4 and L5, plus 2 transfer orbit satellites. These are the critical “bridge” nodes between the Earth and Mars systems.

🛠
Why Lagrange Points?
L4 and L5 are gravitationally stable points 60° ahead of and behind Earth in its orbit. Satellites placed here can “see” both Earth and Mars even during solar conjunction — when Mars is behind the Sun from Earth’s perspective. This eliminates the 2-week communication blackout.
T4

Mars Orbital Relays

4 nodes — 2 areostationary orbiters (Mars’ equivalent of geostationary satellites at 17,032 km altitude) providing continuous coverage of fixed surface locations, plus 2 polar orbiters for global coverage.

📡
Areostationary Orbit
Mars rotates once every 24.6 hours. A satellite at 17,032 km altitude orbits at the same rate, appearing stationary from the surface — just like GEO satellites on Earth, but for Mars.
T5

Mars Surface Assets

177 nodes — Human habitats, scientific bases, exploration rovers, reconnaissance drones, weather stations, and environmental sensors. These are the “endpoints” generating and consuming data.

💡
Why So Many Surface Nodes?
A Mars colony needs ubiquitous connectivity — everything from life-support monitoring (critical, low bandwidth) to high-resolution science cameras (bulk, high bandwidth). The large node count supports diverse data priorities and ensures coverage across the entire Martian surface.
🔗 How Data Flows Through the Network
Example: Mars Rover → Earth Mission Control
🚀
Step-by-Step Journey
1. Rover takes a photo and creates a bundle (T5 → T5)
2. Bundle transmitted via UHF to areostationary orbiter (T5 → T4)
3. Orbiter forwards via optical laser to deep space relay (T4 → T3)
4. Deep space relay beams toward Earth’s LEO mesh (T3 → T2)
5. LEO mesh routes to the nearest DSN-capable satellite (T2 → T2)
6. Satellite downlinks to DSN ground station (T2 → T1)
7. Ground station delivers to Mission Control (T1 → T1)
Total: 7 hops, ~12.5 minutes (mostly light-time delay)
📡 Deep Dive: Key Infrastructure
LEO — Low Earth Orbit Satellites

Altitude: 160–2,000 km. Orbital period: 90–120 minutes. Role: Rapid-response relay mesh.

AETHERIX deploys 48 LEO satellites in a Walker constellation at ≈550 km altitude (similar orbital shell to Starlink). Each satellite carries a 1550nm optical terminal for inter-satellite links (ISL) and a Ka-band transceiver for ground uplink.

🔬
Technical Detail
Each LEO node maintains 4 laser ISL links (2 intra-plane, 2 inter-plane) at 10 Gbps per link. The mesh topology means any ground station can reach any other via at most 6 inter-satellite hops with <2 ms latency. The constellation provides continuous coverage between 65°N and 65°S latitude.
💡
Why Not Just Use GEO for Everything?
GEO satellites at 35,786 km introduce ≈240 ms round-trip latency and require enormous launch vehicles. LEO satellites are cheaper to build and launch, and their laser mesh provides lower latency and higher aggregate bandwidth. The trade-off: LEO satellites move fast across the sky, so you need many of them for continuous coverage.
GEO — Geostationary Earth Orbit Satellites

Altitude: 35,786 km (exactly). Orbital period: 23h 56m 4s (matches Earth’s rotation). Role: Persistent relay over fixed ground stations.

AETHERIX uses 3 GEO relay satellites positioned over the Americas, Europe/Africa, and Asia/Pacific. Each GEO satellite maintains a permanent optical downlink to its regional DSN station and a Ka-band uplink to the LEO mesh.

🔬
Technical Detail
GEO relay terminals use 0.5m aperture telescopes with <1 μrad pointing accuracy for the deep-space optical link. The Ka-band feeder link to ground operates at 500 Mbps. Each GEO satellite carries a 10 kW solar array and has a 15-year design life. They serve as the primary aggregation point for Mars-bound traffic from the LEO mesh.
💡
Why Geostationary?
A satellite in GEO appears stationary from the ground — no tracking antenna needed. This simplifies ground station design enormously: a fixed dish always points at the same satellite. For AETHERIX, this means DSN stations maintain a permanent, high-bandwidth link to their regional GEO relay without any antenna steering.
DSN — Deep Space Network Sites

NASA’s Deep Space Network is the backbone of all interplanetary communication. Three complexes spaced ≈120° apart ensure 24/7 coverage of the solar system.

Goldstone (California, USA)
35°N latitude. 70m + 34m antennas. Primary downlink for Mars missions. Houses the Signal Processing Center that demodulates deep-space signals as weak as 10−²¹ watts.
Madrid (Robledo, Spain)
40°N latitude. 70m + 34m antennas. European node, provides overlap coverage with both Goldstone and Canberra during orbit shifts.
Canberra (Australia)
35°S latitude. 70m + 34m antennas. Southern hemisphere coverage essential for Mars observations during certain orbital geometries.
📡
Why 120° Apart?
Earth rotates once every 24 hours. With 3 stations at 120° intervals, as Earth turns one station out of view, the next station rotates into view. At least one station always has line-of-sight to any spacecraft in the solar system. Without this spacing, there would be communication gaps of several hours per day.
Lagrange Points L4 & L5

Lagrange points are positions in a two-body orbital system where a smaller object can maintain a stable position relative to the two larger bodies, balanced by their gravitational pulls.

L4 — 60° ahead of Earth in its orbit
A relay satellite here trails Earth by 60° (≈150M km ahead). It can see Mars even when Earth can’t — during solar conjunction, L4 has an unobstructed view of both planets from a different angle.
L5 — 60° behind Earth in its orbit
Trails Earth by 60° (≈150M km behind). Provides a second relay path independent of L4. If one relay fails, the other maintains service.
🔬
Why L4/L5 and not L1/L2?
L1 and L2 (between Earth-Sun and beyond Earth) are meta-stable — satellites drift away and need constant station-keeping fuel. L4 and L5 are gravitationally stable — objects naturally remain there with zero fuel. This is critical for relay stations meant to operate for 15+ years without refueling. The Trojan asteroids at Jupiter’s L4/L5 prove these points are naturally stable over billions of years.
🛠
Eliminating the Blackout
During solar conjunction, Mars is behind the Sun from Earth’s view — a ≈2° exclusion zone means no direct communication for ~14 days. But L4 and L5 are offset by 60°, so they always have some visibility to both planets. The relay path Earth → L4 → Mars is longer (adding ≈25% distance) but it’s always available. This is how AETHERIX achieves >95% availability versus current 60–75%.
Areostationary Orbiters

Mars’ equivalent of Earth’s geostationary satellites. The term comes from Ares (Greek name for Mars) + stationary.

Altitude: 17,032 km above Mars’ equator. Orbital period: 24h 37m (matches Mars’ sidereal rotation). A satellite at this altitude appears stationary from a fixed point on the Martian surface.

🔬
Technical Detail
Mars’ gravitational parameter (μ = 4.283×10¹³ m³/s²) and rotation rate (ω = 7.088×10⁻⁵ rad/s) yield the areostationary radius r = (μ/ω²)¹⁄³ = 20,429 km from Mars’ center (17,032 km altitude). AETHERIX places 2 areostationary orbiters: one over Jezero Crater (primary base) and one over Olympus Mons (secondary base). Each carries a 5W optical terminal for the deep-space link and a UHF transceiver for surface coverage.
📡
Areostationary vs Geostationary
The concept is identical — orbit at the same rate the planet rotates — but the numbers differ. Earth’s GEO is at 35,786 km; Mars’ areostationary orbit is at 17,032 km (lower because Mars is smaller and rotates slower). Both provide the same benefit: a permanent, fixed relay overhead for surface assets.
Polar Orbiters

AETHERIX deploys 2 polar orbiters in sun-synchronous orbits around Mars at ≈300–400 km altitude, similar to Mars Reconnaissance Orbiter (MRO).

Role: Complement the areostationary orbiters by covering the Martian poles (which areostationary satellites cannot see from the equatorial plane) and providing redundant relay paths for high-latitude surface assets.

🔬
Technical Detail
Polar orbiters complete one orbit every ≈2 hours, passing over every point on Mars twice per sol (Martian day). They carry both UHF (for surface relay) and optical terminals (for the deep-space link back to Earth via Lagrange relays). During the ≈10-minute communication window per pass, a polar orbiter can relay ≈1–5 GB of data from surface assets.
📊 Network Topology Visualized
5-Tier Network Diagram
5-Tier Network Diagram — 241 nodes spanning Earth ground, Earth orbital, deep-space Lagrange relays, Mars orbital, and Mars surface tiers.
Challenge
A single communication path between Earth and Mars is a fragile single point of failure — satellite outages, solar storms, and orbital geometry all disrupt links.
Purpose
Shows the full 5-tier topology with multiple redundant paths at every tier — ensuring data always has an alternative route.
Impact
241 nodes across 5 tiers provide at least 3 independent paths between any Earth-Mars pair, achieving >95% network availability.
Network Tier Distribution
Node Distribution by Tier — Mars Surface (T5) dominates with 177 nodes, while critical relay tiers (T3, T4) are kept lean for efficiency.
Challenge
Mars surface has hundreds of diverse assets (bases, rovers, drones, sensors) that all need connectivity, but relay infrastructure in orbit is expensive and limited.
Purpose
Breaks down the 241 nodes by tier, showing where investment is concentrated: heavy on surface endpoints, lean on expensive deep-space relays.
Impact
The topology balances coverage (177 surface nodes for ubiquitous Mars connectivity) against cost (only 8 orbital relay nodes needed as aggregation points).
Network Topology Graph
Network Topology Graph — Multiple redundant paths ensure no single point of failure. BFS pathfinding routes bundles around failures automatically.
Challenge
With 241 nodes and hundreds of inter-tier links, finding the optimal route manually is infeasible — especially when links fail dynamically.
Purpose
Visualizes the actual graph structure the RL agent navigates, with inter-tier links and BFS pathfinding for fallback routing.
Impact
The RL agent learns Q-values for each node pair, achieving 20–40% faster delivery than static Contact Graph Routing while maintaining 97% delivery ratio.
🔑
What Happens If a Node Fails?
The DTN routing automatically finds an alternative path. If the areostationary orbiter is down, the bundle can route through the polar orbiter instead. If the L4 relay is in maintenance, the L5 relay takes over. This is why having multiple redundant paths across 5 tiers is essential — the network degrades gracefully rather than failing catastrophically.
🔒
Why Can’t We Just Use Regular Encryption?
Current encryption (like AES-256) relies on the difficulty of certain mathematical problems. But quantum computers will eventually solve these problems efficiently, breaking today’s encryption. For a Mars mission planned decades in advance, we need security that will hold up not just today, but in 20–30 years. That’s where quantum key distribution comes in.
⚠ The Quantum Threat
What Quantum Computers Will Break
  • ✗ RSA — Used in most internet security (HTTPS, SSH)
  • ✗ ECC — Elliptic curve cryptography
  • ✗ Diffie-Hellman — Key exchange protocols
⚠
An adversary could record encrypted Mars communications today and decrypt them years later when quantum computers become available. This is called “harvest now, decrypt later.”
What Quantum Key Distribution Provides
  • ✓ Information-theoretic security — based on physics, not math
  • ✓ Eavesdropper detection — any interception is immediately visible
  • ✓ Future-proof — no computer can ever break the laws of physics
⚗
QKD security comes from the No-Cloning Theorem: it’s physically impossible to make an exact copy of an unknown quantum state. Any measurement disturbs the state, revealing the eavesdropper.
⚗ BB84 Protocol — Step by Step
💡
The Key Insight
BB84 works because measuring a quantum particle changes it. If Alice sends a photon in a specific orientation and Eve tries to intercept it, Eve’s measurement changes the photon. When Bob later measures it, the error rate goes up — and Alice and Bob can detect that someone was listening.
1

Quantum Transmission

Alice (Earth) sends a stream of photons, each representing a random bit (0 or 1) in a randomly chosen basis (rectilinear or diagonal). Think of it as sending letters in randomly chosen alphabets.

2

Measurement

Bob (Mars) measures each photon in a randomly chosen basis. When his basis matches Alice’s, he gets the correct bit. When it doesn’t, he gets a random result. About 50% of bases will match.

3

Sifting

Alice and Bob publicly compare which bases they used (not the actual bits). They keep only the bits where their bases matched. This is their “sifted key.”

4

Error Check (QBER)

They compare a subset of the sifted key to calculate the Quantum Bit Error Rate (QBER). If QBER < 11%, no eavesdropper was detected. If QBER ≥ 11%, someone was listening — they abort and try again.

📡
Why 11%?
This threshold comes from quantum information theory. Below 11%, privacy amplification can extract a perfectly secure key. Above 11%, too much information has leaked to the eavesdropper.
5

Privacy Amplification

They apply a mathematical function to the sifted key that compresses it, removing any partial information an eavesdropper might have gained. The result is a shared secret key that is provably secure.

🔬 Technical Deep Dive: BB84 Protocol
📚
What Does BB84 Stand For?
BB84 = Bennett + Brassard, published in 1984. Charles Bennett (IBM Research) and Gilles Brassard (Université de Montréal) proposed this protocol at the IEEE International Conference on Computers, Systems and Signal Processing in Bangalore, India. It was the first practical quantum key distribution scheme and remains the most widely studied.
BB84: How It Actually Works (Technical)

The protocol uses two conjugate bases for encoding classical bits into quantum states:

Rectilinear Basis (Z-basis, |+⟩ / |−⟩)
Bit 0 → |0⟩ (vertical polarization). Bit 1 → |1⟩ (horizontal polarization). Measured with a vertical/horizontal polarizer.
Diagonal Basis (X-basis, |+⟩ / |−⟩)
Bit 0 → |+⟩ (+45° polarization). Bit 1 → |−⟩ (−45° polarization). Measured with a diagonal/anti-diagonal polarizer.

Protocol execution (N photons):

  1. Transmission: Alice generates N random bits and N random bases. For each bit i, she prepares photon i in the state |ψ⟩ corresponding to her random bit value in her random basis.
  2. Measurement: Bob independently chooses N random bases and measures each photon. If his basis matches Alice’s, he gets the correct bit with certainty. If it doesn’t match, quantum mechanics dictates he gets a random result (50/50 chance of either bit).
  3. Sifting (public channel): Alice and Bob publicly announce their basis choices (not the bit values). They discard all bits where bases didn’t match — roughly 50%. The remaining ≈N/2 bits form the sifted key.
  4. QBER estimation: They publicly compare a random subset (≈25%) of the sifted key to estimate the Quantum Bit Error Rate. In the absence of eavesdropping, QBER comes only from channel noise (typically 1–4%).
  5. Eavesdropper detection: If Eve intercepts and measures a photon, she must choose a basis. When she guesses wrong (≈50% of the time), her measurement disturbs the quantum state. This introduces a ≈25% error rate in the sifted key — well above the 11% security threshold.
  6. Privacy amplification: If QBER < 11%, Alice and Bob apply a universal hash function (e.g., based on Toeplitz matrices) to compress the sifted key. The result is a shorter key about which Eve has negligible information (<2⁻ⁿ⁸ bits).
📊
Key Rate Calculation
For BB84 with an ideal single-photon source: Key Rate = ½ × N × (1 − QBER) × f(EC), where N = raw qubits, the ½ factor comes from sifting, and f(EC) accounts for bits consumed during error correction. With 1000 photons at 3% QBER, expect ≈400–450 final secret key bits.
QKD — Quantum Key Distribution

QKD = Quantum Key Distribution. A family of protocols that use quantum mechanical phenomena (superposition, entanglement, measurement disturbance) to establish a shared secret key between two parties with information-theoretic security.

Security guarantee: Unlike classical key exchange (Diffie-Hellman, RSA), QKD’s security does not depend on computational assumptions. It is provably secure against an adversary with unlimited computing power, including quantum computers.

BB84 (1984) E91 (1991) B92 (1992) SARG04 (2004)
PQC — Post-Quantum Cryptography

PQC = Post-Quantum Cryptography. Classical cryptographic algorithms designed to resist attacks by quantum computers. Unlike QKD (which uses physics), PQC relies on mathematical problems believed to be hard for both classical and quantum computers.

NIST Standards (2024):

  • ✓ ML-KEM (FIPS 203) — Key encapsulation, based on CRYSTALS-Kyber. Replaces RSA key exchange.
  • ✓ ML-DSA (FIPS 204) — Digital signatures, based on CRYSTALS-Dilithium. Replaces RSA/ECDSA signatures.
  • ✓ SLH-DSA (FIPS 205) — Hash-based signatures. Backup with minimal security assumptions.
🔐
QKD + PQC: Defense in Depth
AETHERIX uses both. QKD provides the primary key exchange (information-theoretic security). PQC provides a computational fallback layer for cases where QKD isn’t available (e.g., during solar conjunction when the quantum channel is too lossy). Together they guarantee that even if one layer is compromised, the other maintains security.
🔬
E91 Protocol (Ekert 1991) — The Entanglement Approach
Artur Ekert’s protocol uses entangled photon pairs instead of Alice preparing and sending states. A source (which could be a satellite) generates pairs of entangled photons in the Bell state |Φ⁺⟩ = (½√2)(|00⟩ + |11⟩). One photon goes to Alice, the other to Bob. Each measures independently in randomly chosen bases. Entanglement ensures their results are correlated when bases match. Security comes from testing Bell inequality violations — if the correlation exceeds the classical limit, no eavesdropper was present. E91 is more robust against photon-number-splitting attacks but harder to implement than BB84.
📊 QKD Security Analysis
QKD Security Analysis
QBER vs Eavesdropper Presence — When QBER stays below 11%, the channel is secure. Above 11%, an eavesdropper is detected and the key exchange is aborted.
Challenge
Classical encryption (AES, RSA) will be broken by quantum computers. An adversary could record encrypted Mars data today and decrypt it in 10–20 years ("harvest now, decrypt later").
Purpose
Shows how the Quantum Bit Error Rate (QBER) acts as an eavesdropper alarm — any interception physically disturbs the quantum states, raising QBER above the 11% security threshold.
Impact
Provides information-theoretically secure key exchange — security guaranteed by the laws of physics, not computational difficulty. Future-proof against any computer, quantum or classical.
QKD Key Generation Rate
Key Generation Rate — BB84 achieves 1–10 kbps for LEO links. E91 with repeaters extends to interplanetary distances at reduced rates.
Challenge
QKD key rates drop dramatically with distance — single-photon transmission over 225M km is extremely lossy, and quantum signals cannot be amplified (no-cloning theorem).
Purpose
Compares key generation rates across deployment phases: BB84 direct (LEO), BB84/E91 with 1 repeater (GEO), and E91 with 3-hop repeater chain (Earth-Mars).
Impact
AETHERIX deploys quantum repeaters at Lagrange points L4/L5, extending QKD to interplanetary distances. Combined with post-quantum crypto (Kyber/Dilithium) for defense in depth.
🚀 Deployment Roadmap
Phase 1: Earth ↔ LEO
1–10 kbps

Satellite-to-ground QKD (similar to China’s Micius satellite). Proven technology. Range: 500–2,000 km.

Proven
Phase 2: Earth ↔ GEO
100–1000 bps

Entanglement-based QKD (E91) with higher photon loss at 36,000 km. Requires quantum repeaters at LEO.

Near-term
Phase 3: Earth ↔ Mars
1–10 bps

Quantum repeaters at Lagrange points enable entanglement swapping across 225M km. Low rate but provably secure.

Future
💡
Defense in Depth
AETHERIX uses both QKD and Post-Quantum Cryptography (PQC). QKD provides information-theoretic security for key exchange, while PQC algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium — recently standardized by NIST as FIPS 203/204) provide computational security as a backup layer. Together, they create a defense-in-depth security architecture that’s resilient against both classical and quantum attacks.
✧
Want to see BB84 actually run?
BB84 Step by Step walks the protocol photon by photon with a worked eight-photon example, shows exactly why an eavesdropper injects a ~25% error rate, and includes an animated top-to-bottom simulation of the full journey — Alice → quantum channel → Bob → sifting → QBER → error correction → privacy amplification → key.
🎯
The one idea everything else hangs on
If you measure a photon in the basis it was prepared in, you get the right answer every time. If you measure it in the wrong basis, your result is fundamentally random — and the original state is destroyed. Eve doesn’t know which basis Alice used, so she has to guess. That single fact is the entire security argument.
🔬 1 · The two bases

A basis is really just the question you ask the photon. There are two questions, and each one has two possible answers — so each photon can carry one bit, encoded four possible ways.

Z basis — “upright or sideways?”
│
bit 0
vertical, 0°
─
bit 1
horizontal, 90°
X basis — “leaning left or right?”
↗
bit 0
diagonal, +45°
↘
bit 1
diagonal, −45°
💡
The photon does not have “Z” or “X” written on it
All that travels down the fibre or through vacuum is a polarization. Nothing in the photon tells you which of the two questions it was prepared to answer. Bob has to guess, and so does Eve. Bob gets to compare his guesses with Alice afterwards; Eve never does, because by the time the bases are announced she has already had to act.
👨‍🔬 2 · Alice prepares eight photons

Alice generates a random bit and a random basis for each photon. She does not send her bits — she sends the polarizations those bits encode.

PhotonAlice’s bitAlice’s basisPhoton sentMeaning
11Z─horizontal
20X↗+45°
31X↘−45°
40Z│vertical
51Z─horizontal
60X↗+45°
71Z─horizontal
81X↘−45°
👨‍💻 3 · Bob guesses a basis for every photon

Bob has no idea what Alice chose, so he flips his own coin for each arriving photon. Three cases show what happens:

Photon 1 — right basis

Alice sent bit 1 in Z (─). Bob measures in Z.

He asked the question the photon was built to answer, so he gets 1, with certainty.

Photon 2 — wrong basis

Alice sent bit 0 in X (↗). Bob measures in Z.

A +45° photon is neither vertical nor horizontal, so the answer is a coin flip — 0 or 1, 50/50. Crucially, nothing in the result tells Bob he guessed wrong.

Photon 3 — right basis

Alice sent bit 1 in X (↘). Bob measures in X.

Right question again — he gets 1. Note that “right basis” has nothing to do with Z vs X; it only means the same as Alice’s.

Bob’s raw string

Running all eight, Bob might record:

11111001

Some of these are Alice’s bits; some are noise from a wrong-basis guess. Bob cannot tell which is which — and that is fine, because the next step sorts it out without either of them revealing a single bit.

⚖ 4 · The public conversation — sifting

Now they talk over an ordinary, completely public channel. Alice says “my bases were Z X X Z Z X Z X.” Bob says “mine were Z Z X X Z X X Z.” Neither of them says a single bit value. Announcing a basis leaks nothing: knowing Alice asked the Z question tells you nothing about whether her answer was 0 or 1.

PhotonAliceBobAgree?Alice’s bitBob’s bitVerdict
1ZZ✓11KEEP
2XZ✗01discard
3XX✓11KEEP
4ZX✗01discard
5ZZ✓11KEEP
6XX✓00KEEP
7ZX✗10discard
8XZ✗11discard
Sifted key — photons 1, 3, 5, 6

Alice has

1110

Bob has

1110

🎉 A shared secret string, and nothing that would let a listener reconstruct it was ever spoken aloud.

Thrown away — photons 2, 4, 7, 8
????

Half the photons are wasted — and that is by design, not inefficiency. Because Alice and Bob each pick between two bases independently, they agree about 50% of the time. That ½ sifting factor is the q in the key-rate formula further down.

▶ 5 · Watch the whole journey

Everything above, running top to bottom. Photons fall from Alice through the quantum channel to Bob; below Bob the picture switches from photons to bits, because that is exactly where the physics hands over to classical information theory. Turn Eve on and watch the QBER climb toward 25%.

Loading simulator…

🔍
What to look for
Use Step with 16 photons to read the narration one photon at a time. Then set 1,000 photons at 4× and watch the sift ratio settle on ~50% and the QBER settle on the channel noise. Finally arm Eve: the sift ratio does not budge — she cannot affect that — but the QBER jumps to roughly 25% and the key collapses to zero.
🕵 6 · Where Eve comes in

Eve sits on the channel and runs the obvious attack: intercept, measure, resend. Follow one photon through it.

One photon, intercepted
1
Alice prepares bit 0 in the X basis and sends ↗.
2
Eve intercepts. She has to pick a basis blind — suppose she picks Z, asking “vertical or horizontal?” But ↗ is neither. Quantum mechanics forces a random answer; say she reads 0.
3
Her measurement destroyed the original state. There is no “put it back” — the no-cloning theorem means she never had a spare copy either. All she can do is manufacture a replacement from what she read: she sends Bob │, a photon Alice never sent.
4
Bob happens to choose X — Alice’s original basis. Ordinarily that would be a guaranteed-correct bit. But he is now measuring Eve’s vertical photon in the X basis, so he gets a coin flip. Say he reads 1.
💥
Alice had 0. Bob has 1. The bases agreed, so this bit survives sifting — and lands in the key as an error. Eve has left a fingerprint she cannot erase.
🔢 7 · Why Eve costs exactly ~25%

This is the part that usually makes BB84 click. Look only at the bits that survive sifting — the ones where Alice and Bob agreed on a basis. For such a bit to come out wrong, two independent coin flips both have to go badly:

Event 1 50%
Eve guesses the wrong basis. (If she guesses right, she learns the bit and resends the identical state — no damage, no trace.)
Event 2 50%
Given Eve resent a scrambled state, Bob’s measurement in Alice’s basis lands on the wrong value. (Half the time he gets Alice’s bit back by luck.)
50% × 50% = 25% QBER
Full intercept-and-resend injects roughly a 25% error rate into the sifted key. Compare that with a healthy space link at 1–5%. It is not subtle.
⚠
Eve gets no error message
Nothing announces “eavesdropper detected.” Quantum mechanics simply makes her interference statistically visible in a quantity Alice and Bob can measure themselves. She cannot tune her attack to be quieter without also learning less — that trade-off is the theorem.
📊 8 · They only check a sample

Alice and Bob don’t compare the whole sifted key — that would burn all of it. They publicly reveal a randomly chosen subset: “let’s compare positions 7, 19, 31, 44…”

→
Compare 100 bits.
→
Find 3 disagreements.
=
QBER = 3/100 = 3%. Comfortably low.

Those 100 bits are now public knowledge, so they are discarded — the sample is spent, not free. The random choice of positions matters: it stops Eve from concentrating her attack where she knows nobody will look.

🎯 9 · What 11% actually means
⚠
The common shortcut is wrong
“Below 11% = safe, above 11% = Eve” is not what the threshold says. QBER is not an Eve detector. It is a security parameter. The measured QBER tells Alice and Bob an upper bound on how much information could have leaked — and therefore how hard they must work in error correction and privacy amplification, and how much key they must sacrifice.
Scenario A — QBER 2%

A relatively clean channel. About 72% of the sifted bits survive into the final key.

Scenario B — QBER 7%

Still workable, but expensive: only about 27% survives. Same protocol, far less key.

Scenario C — QBER 15%

Under standard BB84 assumptions, no secure key can be extracted at all. Abort.

✧
Where 11% comes from — it is not a hand-picked number
The surviving fraction of the sifted key is 1 − 2 h₂(Q), where h₂ is the binary entropy. Binary entropy reaches ½ at Q ≈ 0.110 — so at 11% the expression hits zero. The abort rule and the key-rate formula are the same statement: past 11% the formula simply hands you no bits. (This is the asymptotic bound for ideal single-photon BB84 with one-way reconciliation; real finite-key and detector effects push the practical limit lower.)
🔧 10 · Error correction — and what it costs

Even with no Eve at all, detectors misfire and photons scatter. Alice and Bob’s sifted keys will differ in a few places, and a key that differs in even one bit is useless.

Alice
101101001101
Bob
101001001101

So they run information reconciliation (CASCADE, or an LDPC code) over the public channel — exchanging parities until the keys match.

📢
Everything they say, Eve hears
“The parity of these ten bits is 1” is a real constraint on the key, and it is public. Reconciliation therefore leaks roughly h₂(Q) × n bits of information about an n-bit sifted key. Those bits have to be paid for later — which is what the next stage is for.
🧷 11 · Privacy amplification

Now Alice and Bob hold identical keys — say 600 bits — but they must assume Eve holds partial information about them, both from the channel and from the reconciliation chatter.

They do not try to work out which bits she knows. They can’t, and they don’t need to. Instead they compress: run the whole string through a universal hash function and keep a shorter output.

600 bitsidentical, but partially compromised
↓
universal hash2-universal family, publicly chosen seed
↓
400 bitsEve’s partial knowledge is now worthless

The intuition: “even if Eve knew a chunk of our 600-bit string, she should know essentially nothing about this shorter one.” Compression converts partial knowledge into no knowledge — at the price of key length. That is why the final key is always meaningfully shorter than the sifted key, even on a perfect channel.

🗺 12 · The whole pipeline
ALICErandom bits + random bases
↓
encode photonsone photon per bit
↓
QUANTUM CHANNELfibre, free space, or satellite downlink — Eve may attack here
↓
BOBrandom measurement basis
↓
public basis exchangebases only — never bits
↓
SIFTING~50% remain
↓
QBER ESTIMATIONcompare a random sample, then burn it
↓
Q ≥ 11%🛑 ABORT — no key
Q < 11%continue
↓
ERROR CORRECTIONleaks ~h₂(Q)·n bits
↓
PRIVACY AMPLIFICATIONdiscards ~h₂(Q)·n more
↓
🔐 SECRET KEYinformation-theoretically secure
🔢 13 · Running the numbers on 1,000 photons
Sent
1,000

single photons

After sifting
~500

1,000 × ½ — bases agree half the time

Final key @ 3% QBER
~306

not 485 — see below

❌
The tempting formula is wrong
It is natural to write key = ½ × N × (1 − QBER) × f(EC) and get 500 × 0.97 ≈ 485 bits. That treats the 3% purely as bits to be repaired. But the errors are not just damage — they are evidence of how much Eve might know, and that has to be paid for twice: once in the reconciliation leak, once in privacy amplification.
The standard asymptotic bound
R  ≈  q · [ 1 − 2 h₂(Q) ]
TermMeaningValue here
qsifting factor — fraction of photons where the bases agree½
Qmeasured quantum bit error rate0.03
h₂(Q)binary entropy — −Q log₂Q − (1−Q) log₂(1−Q)0.194
1 − 2h₂(Q)fraction of the sifted key that survives EC + PA0.611
Rsecret bits per photon sent0.306

So 1,000 transmitted single photons at 3% QBER yield roughly 306 secret bits — about 63% of the naive 485, and that is still an idealised figure before finite-key statistics, multi-photon pulses, detector dark counts and imperfect reconciliation efficiency take their cut.

The simulator above computes its key length with exactly this expression — drag the noise slider and watch how quickly the final key falls away as Q rises.

🧠 14 · If you remember one thing
🔑
The whole protocol in one sentence
Alice hides each bit behind a randomly chosen quantum basis; Bob guesses the basis; Eve cannot learn the photon without sometimes disturbing it; Alice and Bob detect that disturbance statistically through the QBER, then reconcile and compress what remains into a secret key.
✧
Why this matters for AETHERIX
The security does not come from making the channel impossible to tap — on an Earth–Mars optical link you could never guarantee that. It comes from making undetected interception incompatible with quantum mechanics. That is the one security property that survives a 22-minute one-way delay, a link you do not physically control, and an adversary who records everything today to break later. See PQC Bundle Integrity for how AETHERIX combines this with post-quantum classical crypto.
🎯
The Analogy
Imagine shining a laser pointer at a wall across the street. Now imagine that wall is on Mars — 400 million kilometers away — and the beam has to hit a receiver the size of a dinner plate. That’s deep-space optical communication. The beam divergence is only ~5 microradians (0.0003 degrees), requiring pointing accuracy equivalent to hitting a coin from 4 km away.
📏 Why Optical Beats Radio
Shorter Wavelength = Narrower Beam

Radio antennas spread their signal across a wide cone — like a floodlight. Optical lasers concentrate energy into a tight beam — like a laser pointer. At 1550 nm (infrared), the wavelength is 10,000× shorter than Ka-band radio, so the beam stays concentrated over interplanetary distances.

📏
Beam Divergence
Optical (1550nm): ~5 μrad → spot size ~2,000 km at Mars distance
Ka-band RF: ~0.5 mrad → spot size ~200,000 km at Mars distance
The optical beam is 100× narrower, concentrating 10,000× more energy on the receiver.
Higher Frequency = More Bandwidth

Data rate scales with frequency. Optical at 193 THz (1550nm) can modulate information far faster than Ka-band at 26.5 GHz. The theoretical Shannon limit for optical is orders of magnitude higher than RF.

📏
Real-World Data Rates
Mars Reconnaissance Orbiter (X-band): ~6 Mbps
DSOC / AETHERIX (Optical): 2–200 Mbps (distance-dependent)
At opposition (55M km), optical can achieve 200 Mbps — enough for streaming HD video from Mars.
⚠ The Challenges
Cloud Cover

Optical signals can’t penetrate clouds. This is why AETHERIX uses hybrid optical/RF — when clouds block the laser at a DSN site, the system falls back to Ka-band radio. Sites like Goldstone (California desert) were chosen for their clear skies.

Pointing Accuracy

A 5 μrad beam at 225M km produces a ~1,100 km spot. The receiver must be within that spot. Spacecraft vibration, thermal deformation, and orbital motion all affect pointing. Requires sub-microradian pointing stability — achieved with fine-steering mirrors.

Background Noise

The Sun is an intense infrared source. When Mars is near solar conjunction, sunlight swamps the optical receiver. This creates the same ~2-week blackout as RF, but the effect is more severe for optical. Lagrange-point relays help maintain partial connectivity.

💡
Why 1550 nm?
The 1550 nm wavelength sits in the C-band of the near-infrared spectrum — the same band used by terrestrial fiber-optic internet. This is not a coincidence: decades of telecom investment have produced cheap, reliable, high-power lasers and sensitive detectors at this wavelength. It also happens to have low atmospheric absorption, passing through clear air with minimal loss. NASA’s DSOC (Deep Space Optical Communications) demonstration in 2023 used exactly this band.
📈 Optical vs RF Comparison
PropertyOptical (1550nm)Ka-band (26.5 GHz)X-band (8.4 GHz)
Wavelength1550 nm11.3 mm35.7 mm
Frequency193 THz26.5 GHz8.4 GHz
Beam Divergence~5 μrad~0.5 mrad~1.5 mrad
Max Data Rate200 Mbps50 Mbps6 Mbps
Weather ImmunityLow (clouds block)Moderate (rain fade)High
Power EfficiencyVery highModerateModerate
Best ForBulk science downlinkHigh-rate backupReliable command/telemetry
HeritageDSOC (2023)MRO, Mars ExpressViking, MGS, MRO
📊 Link Budget & Performance Analysis
Link Budget Breakdown
Link Budget Breakdown — Signal power from transmitter through free-space path loss, atmospheric loss, and receiver optics. Link margin determines achievable data rate.
Challenge
At 225M km average distance, free-space path loss reaches –365 dB — the signal arriving at Earth is 10^36 times weaker than what was transmitted.
Purpose
Shows the complete link budget waterfall: Tx power → antenna gain → FSPL → atmospheric loss → Rx gain → sensitivity threshold → margin.
Impact
AETHERIX achieves positive link margin (3–15 dB) at all distances, enabling 2–200 Mbps with a 5W laser and 22 cm aperture — realistic spacecraft hardware.
Data Rate vs Distance
Data Rate vs Distance — Optical link achieves 200 Mbps at closest approach, degrading to ~2 Mbps at maximum distance. RF remains far below at all ranges.
Challenge
Current Mars missions (MRO) achieve only 0.5–6 Mbps via X-band radio — insufficient for streaming science data or supporting human crews.
Purpose
Compares achievable optical vs RF data rates across the full 54.6M–401M km distance range.
Impact
Optical delivers 10–100× improvement: 200 Mbps at opposition (HD video), 20 Mbps at average distance, 2 Mbps even at conjunction — all with the same 5W transmitter.
Optical vs RF Radar Chart
Optical vs RF Comparison — Optical dominates in data rate, power efficiency, and beam focus. RF wins in weather immunity and heritage.
Challenge
Choosing between optical and RF involves trade-offs — optical is faster but blocked by clouds; RF is slower but weather-resistant.
Purpose
Multi-axis radar comparison across 7 dimensions: data rate, power efficiency, beam divergence, weather immunity, pointing accuracy, cost, and heritage.
Impact
AETHERIX uses hybrid optical/RF — optical for bulk science downlink (10–200 Mbps) with RF backup for critical commands and cloudy conditions.
Bandwidth Evolution
Bandwidth Evolution — From Viking's 8 bps to AETHERIX's 200 Mbps — a 25 million-fold improvement over five decades of deep-space communication.
Challenge
Deep-space data rates have historically been limited — Viking (1975) transmitted at just 8 bps, and even MRO (2006) only achieves ~6 Mbps.
Purpose
Charts the historical progression of Mars communication bandwidth, projecting AETHERIX's optical link as the next leap.
Impact
AETHERIX represents a 25 million-fold improvement over Viking and a 33× improvement over current MRO rates — enabling HD video and bulk science from Mars.
🎯
Why this page exists
The single most obvious challenge to AETHERIX is “optical comms at Mars distance is theoretical.” It is not. On 3 December 2024 DSOC downlinked data from 494 million kilometres — further than Earth and Mars ever get from each other. The physics question is settled; what remains is the networking problem, which is what AETHERIX addresses.
🚀 What DSOC is
The demonstration

DSOC is a NASA technology demonstration riding aboard the Psyche spacecraft, which launched on 5 October 2023 toward the metal-rich asteroid of the same name. Psyche is the mission; DSOC is a passenger on it, proving a communications technology while the spacecraft goes about its own science.

That distinction matters: DSOC is not a communications mission. It is a risk-reduction experiment flown alongside a conventional radio link, so that if the laser had failed, nothing would have been lost. NASA did not bet a mission on it — and neither does AETHERIX, which is why the architecture keeps Ka-band RF as a fallback.

Why lasers instead of radio

A radio wave at Ka-band has a wavelength of roughly 1 cm. An infrared laser at 1550 nm has a wavelength about 10,000× shorter. Beam divergence scales with wavelength over aperture, so for the same size telescope the laser beam spreads far less — more of the transmitted energy lands on the receiver instead of spilling into empty space.

That is the entire argument in one sentence: shorter wavelength, tighter beam, more photons on target. NASA measured the result at at least 10× the data rate of state-of-the-art radio systems of comparable size and power.

🏁 What it actually achieved
First light
11 Dec 2023

Streamed an ultra-high-definition video to Earth from 31 million km (19 million miles) at the system’s maximum bitrate of 267 Mbps.

Distance record
3 Dec 2024

Downlinked Psyche data from 494 million km (307 million miles) — further than the maximum Earth–Mars distance of 401 million km.

Versus radio
≥10×

Data rates at least ten times higher than state-of-the-art radio telecommunications systems of comparable size and power.

💡
Read the two numbers together — they are not the same claim
267 Mbps was achieved at 31 million km, which is close range. 494 million km was the distance record, at a far lower rate. Rate falls with the square of distance, so you cannot combine them into “267 Mbps at 494 million km” — that would be wrong by roughly a factor of 250. What the pair proves is that the link closes across the whole Earth–Mars range, and that the rate at any given distance is an engineering trade, not a physical barrier.
⚙ How the link is built
On the spacecraft

A flight laser transceiver transmitting near-infrared photons at 1550 nm through a 22 cm aperture telescope, driven by a 4 W laser. It also carries a photon-counting camera to receive the low-rate uplink.

1550 nm 22 cm 4 W
Uplink from Earth

A powerful modulated laser at the Optical Communication Telescope Laboratory (OCTL), part of JPL’s Table Mountain Facility near Wrightwood, California. The uplink doubles as a beacon the spacecraft locks onto for pointing.

Downlink to Earth

A superconducting nanowire photon-counting receiver at Caltech’s Palomar Observatory in San Diego County. Not a conventional radio dish — a detector cold enough to register individual photons.

Why you have to count photons at this range

On a terrestrial fibre link the receiver measures a waveform — there is so much light that you can treat it as a continuous signal. At interplanetary distance that is no longer true. Free-space path loss is around −353 dB at Mars opposition, so what arrives is not a waveform but a sparse trickle of individual photons, sometimes fewer than one per transmitted bit.

That is why the receiver is a superconducting nanowire single-photon detector cooled to a few kelvin: at that temperature a single arriving photon deposits enough energy to break superconductivity and produce a measurable voltage pulse. The information is carried in which time slot the photon arrives in — pulse-position modulation — rather than in amplitude.

🔬
This is the same detector family used in QKD
Superconducting nanowire single-photon detectors are exactly what quantum key distribution receivers use, for the same reason: both are counting individual photons. The optical and quantum halves of AETHERIX share a detector technology — which is a genuine architectural synergy, not a coincidence.
🔗 What this means for AETHERIX
ParameterDSOC (flown)AETHERIX (modelled)Comment
Wavelength1550 nm1550 nmIdentical — telecom heritage
Flight aperture22 cm22 cmIdentical
Laser power4 W5 WSame class
Ground receivePalomar (5.1 m)5 m Hale-classSame class
DetectorSNSPD photon countingPhoton-counting modelSame physics
CodingCoded (SCPPM)UncodedThe one real difference — ~13 dB
⚖
The honest calibration — state this before you are asked
AETHERIX models a DSOC-class terminal because DSOC is the only deep-space optical system with flight heritage. Run the AETHERIX link budget at DSOC’s demonstrated operating point — 267 Mbps at 31 million km — and it returns −12.8 dB. DSOC demonstrably closed that link, so the model is conservative by roughly 13 dB. That gap is the SCPPM forward-error-correction coding gain and high-order PPM photon efficiency the model deliberately omits. AETHERIX margins are therefore a floor, not a rate prediction — which is the safe direction to be wrong in.
⚖ Optical vs radio — what is actually being traded?
❌
First, the misconception worth killing
Optical is not lower latency. Radio and light are the same thing at different wavelengths, and both travel at c. The Earth–Mars one-way delay is 3–22 minutes either way — no laser reduces it by a single second. If someone says optical is “faster,” they mean data rate, never delay.

So is the trade speed or volume? Neither, separately. Volume is just rate multiplied by how long the link is open — the same quantity seen over time. The real trade is data rate per kilogram and per watt, bought at the cost of availability. Here is that trade in the project’s own numbers, all at 225 million km and 2 Mbps:

ConfigurationMarginOptical advantage≈ rate ratio
Optical — 5 W, 22 cm flight, 5 m ground−7.92 dB—baseline
Ka-band, same 5 W / 22 cm / 5 m−62.00 dB+54.1 dB~255,000×
Ka-band, 34 m DSN dish, 5 W−45.35 dB+37.4 dB~5,500×
Ka-band, 34 m DSN dish, 100 W, 3 m spacecraft antenna−9.65 dB+1.7 dB~1.5×
Ka-band, 70 m DSN dish, 100 W, 3 m antenna−3.37 dB−4.6 dBRF wins
💡
Read the last two rows — that is the whole answer
At equal hardware the optical advantage is absurd: 54 dB, roughly 255,000×. But radio can buy that back — with a 70 metre ground dish, 100 W of transmit power and a 3 metre spacecraft antenna, RF actually beats the 5 W optical terminal. The catch is what those numbers cost: a 3 m high-gain antenna and 100 W of RF power are enormous on a spacecraft mass and power budget, against 22 cm and 5 W for the laser. The optical advantage is per-kilogram and per-watt, not absolute — which is exactly why NASA phrases its DSOC result as “at least 10× … of comparable size and power.” Those five words carry the entire claim.
What optical buys you

Rate for the same mass and power. Beam divergence scales as wavelength ÷ aperture, and 1550 nm is ~10,000× shorter than Ka-band, so far less energy is wasted spilling past the receiver. For a mission where every kilogram is contested, this is the decisive argument.

What it costs you

Availability. Cloud stops an optical link dead; Ka-band passes straight through. The tight beam also demands far harder pointing. So optical maximises rate, RF maximises uptime — and since volume = rate × uptime, neither wins volume outright.

🎯
Which is why AETHERIX is hybrid, not optical
Optical primary for throughput when the sky is clear and the geometry is good; Ka-band RF fallback for the times it is not. That is not hedging — it is the only configuration that maximises delivered volume rather than peak rate. NASA reached the same conclusion: DSOC flew alongside Psyche’s radio link, never instead of it.
❗ What DSOC does not solve

If NASA has already flown deep-space laser comms, what is left to contribute? This is the sharpest challenge to the whole project, and it has a clean answer: DSOC solved a link problem. AETHERIX addresses a network problem.

It is a point-to-point link

DSOC connects one spacecraft to one ground station when both are in view. It has no routing, no relaying, no store-and-forward, and no notion of a bundle. It does not answer “what happens to this data when nobody is in view?” — which is the question DTN exists for.

Clouds still stop it

Optical links do not penetrate cloud. A single ground site is weather-limited, which is why AETHERIX keeps Ka-band RF as a fallback and spreads receivers across sites. NASA made the same call: DSOC flew alongside Psyche’s conventional radio link, not instead of it.

Solar conjunction still blacks out

When the Sun sits between Earth and Mars, the corona blocks the direct line of sight regardless of how good the laser is. That is a geometry problem, not a link-budget one — and it is why AETHERIX puts relays at the ES-L4 and ES-L5 Lagrange points.

Pointing is brutal

The tighter beam that makes optical fast also makes it hard to aim. At 494 million km the spacecraft must point not at where Earth is, but at where Earth will be when the photons arrive — minutes of lead angle. Losing lock loses the link entirely.

🎯
The one-sentence answer if challenged
“DSOC proved the physical layer works at interplanetary distance. AETHERIX takes that proven link and builds the network on top of it — store-and-forward with custody so data survives when no path exists, adaptive routing so the network reconfigures without a 22-minute round trip to ask permission, and quantum key distribution so the link is secure against an adversary who records now and decrypts in twenty years.”
NASA DSOC ↗
🎯
Why Standards Matter in Space
When NASA’s Mars Reconnaissance Orbiter talks to ESA’s ExoMars orbiter, they need a common language. When a future Chinese Mars relay forwards data to a NASA ground station, the protocols must interoperate. Standards ensure that hardware built by different agencies, in different decades, can communicate. Without them, every mission would be an isolated island.
📚 The Three Standards Bodies
IETF (Internet Engineering Task Force)

Creates the internet standards (RFCs) that DTN builds on. Key RFCs include RFC 9171 (Bundle Protocol v7), RFC 5326 (LTP), RFC 4838 (DTN Architecture), and RFC 7242 (TCPCL). Open, community-driven process.

CCSDS (Consultative Committee for Space Data Systems)

The space agency consortium (NASA, ESA, JAXA, CSA, etc.) that defines space-specific protocols. CCSDS 734.2-B-1 is the CCSDS Bundle Protocol (space profile of RFC 9171 BPv7); RFC 4838 defines the DTN architecture; CCSDS 734.3-B-1 (SABR) standardises contact-graph routing; CCSDS 141.0-B-1 covers optical links.

NIST (National Institute of Standards and Technology)

Defines cryptographic standards. For AETHERIX, the key standards are FIPS 203 (ML-KEM / CRYSTALS-Kyber for key encapsulation) and FIPS 204 (ML-DSA / CRYSTALS-Dilithium for digital signatures) — the new post-quantum cryptography standards finalized in 2024.

⚙ The Protocol Stack
LayerProtocolStandardPurpose
ApplicationBundle Protocol v7RFC 9171 / CCSDS 734.2-B-1End-to-end messaging with custody transfer
TransportLTP (Licklider)RFC 5326Reliable segmentation over long-delay links
TransportTCPCLRFC 7242TCP convergence layer for Earth segment
TransportUDPCLRFC 7122UDP convergence for optical inter-satellite links
NetworkContact Graph Routing (SABR)CCSDS 734.3-B-1Static routing based on contact schedules
NetworkRL Routing (AETHERIX)ResearchAdaptive routing via reinforcement learning
SecurityBPSecRFC 9172Bundle security (integrity + confidentiality)
PhysicalOptical (1550nm)CCSDS 141.0-B-1Laser communication physical layer
PhysicalRF (Ka/X/S/UHF)CCSDS 401.0-B-30Radio frequency physical layer
📦 Convergence Layers Explained
TCPCL (RFC 7242)

TCP Convergence Layer. Used on Earth where TCP works — between DSN ground stations and mission control, between data centers. Reliable, ordered delivery. Segments bundles into TCP-friendly frames.

LTP (RFC 5326)

Licklider Transmission Protocol. The deep-space workhorse. Designed for links with 3–22 minute delays. Segments data, selectively retransmits only lost segments (not the whole payload). Report-based ACK instead of per-packet ACK.

UDPCL (RFC 7122)

UDP Convergence Layer. Used for high-speed optical inter-satellite links where reliability is handled by LTP above. Fire-and-forget with optional fragmentation. Best for LEO mesh laser links with low latency.

💡
AETHERIX vs CGR
Traditional DTN uses Contact Graph Routing (CGR) — a static algorithm that computes paths from pre-planned contact schedules. AETHERIX replaces this with reinforcement learning routing that adapts in real time to changing conditions (node failures, buffer overflows, link degradation). CGR is deterministic but brittle; RL is probabilistic but resilient. Learn more on the Reinforcement Learning page.
🎯
Why This Is Different from Regular Encryption
Today’s encryption (RSA, AES) relies on mathematical problems that are hard to solve — but not impossible. A future quantum computer could break RSA in hours. QKD is different: its security comes from laws of physics, not computational difficulty. Even an infinitely powerful computer cannot break it, because doing so would violate quantum mechanics.
🔬 Three Quantum Principles
Superposition

A quantum bit (qubit) doesn’t have a definite value until you measure it. Think of a coin spinning in the air — it’s neither heads nor tails until it lands. In BB84, Alice encodes bits in the polarization of photons. A photon polarized at 45° is in a superposition of horizontal (0) and vertical (1).

No-Cloning Theorem

It is physically impossible to make an identical copy of an unknown quantum state. This is the mathematical proof (Wootters & Zurek, 1982) that makes QKD secure. Eve cannot intercept a photon, copy it, and send the original on to Bob — the universe forbids it.

Measurement Disturbance

Measuring a quantum system changes it irreversibly (wavefunction collapse). When Eve measures a photon in the wrong basis, she gets a random result — and the photon’s original state is destroyed. Bob’s subsequent measurement will disagree with Alice’s, revealing Eve’s presence as an elevated QBER.

🔐 BB84 Protocol Walkthrough
Step-by-Step: How Alice and Bob Create a Shared Secret
1
Preparation: Alice generates random bits and randomly chooses a measurement basis for each bit: Z-basis (0°/90° polarization, representing 0/1) or X-basis (45°/135° polarization, also representing 0/1). She sends one photon per bit to Bob.
2
Measurement: Bob randomly chooses Z-basis or X-basis for each arriving photon. When Bob’s basis matches Alice’s, he gets the correct bit (~100% of the time). When it doesn’t match, he gets a random result (50/50).
3
Sifting: Over a classical (public) channel, Alice and Bob announce which basis they used for each photon — but not the bit values. They discard all bits where bases didn’t match. About 50% survive, forming the sifted key.
4
Error Estimation: They publicly compare a random subset of the sifted key. The error rate (QBER) bounds how much Eve could have learned — it is a security parameter, not a simple on/off eavesdropper alarm. Natural noise: 1–5%. Full intercept-and-resend: ~25%. Above 11% no secure key can be distilled, so they abort. (worked through here.)
5
Error Correction: They use classical error-correcting codes (CASCADE protocol) to fix any remaining discrepancies, making their keys identical.
6
Privacy Amplification: They apply a hash function to compress the corrected key, eliminating any partial information Eve might have gained. The result is a provably secure shared secret key.
✧ BB84 vs E91
BB84 (Prepare-and-Measure)

Named after Charles Bennett and Gilles Brassard (1984). Alice prepares photons in specific states and Bob measures them. Simpler to implement. Used by China’s Micius satellite (2016) for the first satellite-to-ground QKD. Security relies on the no-cloning theorem.

E91 (Entanglement-Based)

Named after Artur Ekert (1991). A source creates entangled photon pairs — sending one to Alice and one to Bob. Their measurements are correlated even across vast distances (Einstein’s “spooky action at a distance”). Security is verified via Bell inequality violations — if the inequality holds, no eavesdropper is present.

💡
The 11% Threshold
The QBER security threshold of 11% comes from the Csiszár-Körner theorem (1978), which proves that secure key extraction is possible as long as the mutual information between Alice and Bob exceeds the mutual information between Alice and Eve. For BB84 with one-way reconciliation, this translates to QBER < 11%. Below this threshold, privacy amplification can distill a perfectly secure key regardless of Eve’s computing power.
🎯
The Analogy
Imagine you’re navigating a new city without a map. At first you try random streets — some lead to dead ends, others get you closer to your destination. Over time, you learn which routes work. That’s reinforcement learning. The agent is the navigator, the actions are street choices, the reward is arriving at the destination quickly, and the learned “map” is the Q-table.
📏 Core Concepts
State, Action, Reward

The agent observes the network state (current node, neighbors, link quality, buffer occupancy), chooses an action (forward to neighbor X, store, drop, or split), and receives a reward based on the outcome:

📊
Reward Function
R = α(delivery) − β(delay) − γ(hops) − δ(drops) − ε(energy)
High reward for fast delivery to the correct destination. Penalty for delays, extra hops, dropped bundles, and wasted energy. The agent maximizes cumulative reward over time.
Q-Table: The Learned Map

The agent maintains a Q-table — a lookup table that maps every (state, action) pair to an expected reward. After thousands of simulated routing decisions, the Q-table encodes the best action for every situation the agent has encountered. A high Q-value means “I’ve learned this action works well in this state.”

🤖 How Q-Learning Works
The Learning Loop
1
Observe State: The agent reads the current network conditions — which node it’s at, buffer fullness at neighbors, link quality to each neighbor, the bundle’s priority and destination tier.
2
Choose Action: With probability ε (epsilon), the agent picks a random action (exploration). Otherwise, it picks the action with the highest Q-value for this state (exploitation). Early in training, ε is high (mostly random). Over time, ε decays (mostly exploiting learned knowledge).
3
Execute & Observe Reward: The action is executed in the simulation. If the bundle is delivered, the agent gets a positive reward. If it’s dropped or delayed, the reward is negative.
4
Update Q-Table: The Bellman equation updates the Q-value: Q(s,a) ← Q(s,a) + α[r + γ max Q(s’,a’) − Q(s,a)]. The learning rate α controls how fast new experiences override old ones. The discount factor γ controls how much future rewards matter vs. immediate ones.
⚙ Exploration vs Exploitation
Exploration (ε high)

The agent tries random actions, including bad ones. This is essential — without exploration, the agent might never discover that a non-obvious route (through a Lagrange relay during conjunction) is actually the best strategy. Too much exploration wastes time on known-bad choices.

Exploitation (ε low)

The agent uses its Q-table to pick the best-known action. This is efficient — it takes the routes it has already learned work well. But without occasional exploration, it can’t adapt when network conditions change (e.g., a node fails or a new link becomes available).

📊
Epsilon Decay Schedule
AETHERIX starts with ε = 1.0 (fully random) and decays by 0.5% each episode: ε ← ε × 0.995. After 500 episodes, ε ≈ 0.08 (92% exploitation). After 1000 episodes, ε ≈ 0.007 (99.3% exploitation). This is the epsilon-greedy strategy — the standard approach that balances learning new routes with using known-good ones.
🌐 Multi-Agent Federated Learning
Why One Agent Isn’t Enough

In the real network, every node runs its own RL agent — each one learning from local observations. The challenge: a single agent at one node only sees a small part of the network. Multi-agent federated learning solves this by periodically aggregating Q-tables across nodes:

Local Training
Each node trains its Q-table from local routing experiences. Mars surface agents learn about Mars-orbiter links; Earth agents learn about DSN schedules.
Robust Aggregation
Periodically, nodes share their Q-tables (not raw data). Plain averaging is only one option — the coordinator also supports coordinate-wise median (Byzantine-robust up to <50% compromised contributors) and trimmed mean, so one poisoned Q-table cannot drag the consensus.
Global Improvement
Every node benefits from every other node’s experience. A relay node that discovered a great conjunction-time route shares that knowledge with all other nodes in the federation.

Conjunction-proof rounds: federation aggregates over whichever agents are present — relays vanish for hours behind the Sun, so rounds never block on a straggler. And sync ships sparse Q-table deltas (only changed cells, as priority-class control traffic) instead of full tables — a round-trip that costs kilobytes over a link charging by the megabit.

📈 RL vs CGR: A Comparison
PropertyContact Graph Routing (CGR)RL Routing (AETHERIX)
ApproachDeterministic graph searchProbabilistic learning
AdaptabilityStatic — needs updated contact plansDynamic — adapts in real time
Node FailuresRequires re-computationAutomatically reroutes
KnowledgeRequires perfect schedule knowledgeLearns from experience
OverheadNone after computationQ-table memory + training
ConvergenceInstant (deterministic)~500–1000 episodes
RobustnessBrittle under uncertaintyResilient to surprises
💡
Production Upgrade: From Q-Table to DQN
The current demo uses a Q-table — fine for small state spaces but it can’t generalize to unseen states. A production system would use a Deep Q-Network (DQN) — a neural network that approximates the Q-function, enabling the agent to handle the full 241-node, 5-tier topology with continuous state variables. The training principles remain identical.
📊 RL Routing Performance
RL Routing Heatmap
Q-Value Heatmap — The RL agent's learned routing preferences across node pairs. Brighter cells indicate higher-value (better) routing decisions learned through experience.
Challenge
Static Contact Graph Routing (CGR) requires pre-computed contact schedules and cannot adapt when solar storms disrupt links or satellites drift off orbit.
Purpose
Visualizes the RL agent's Q-table — the learned "experience map" showing which routing decisions yield the best outcomes for each (state, action) pair.
Impact
The agent discovers optimal routes through trial-and-error, achieving 20–40% faster delivery than CGR while adapting in seconds to link failures (vs hours for manual CGR rerouting).
Energy Efficiency
Energy Efficiency Trade-offs — The reward function balances delivery speed against energy consumption, enabling intelligent routing even for power-constrained relay nodes.
Challenge
Relay satellites have finite solar power and battery capacity. Routing everything through the fastest path may drain a critical relay, leaving it unable to handle emergency traffic.
Purpose
Shows how the multi-objective reward function (R = α·delivery − β·delay − γ·hops − δ·drops − ε·energy) learns to balance speed against energy conservation.
Impact
Emergency bundles (P0) get routed through the fastest path regardless of energy cost, while bulk science data (P4) is routed through energy-efficient paths — autonomous QoS-aware routing.
☢
The Analogy
Think of cosmic rays as microscopic bullets constantly striking the computer. Most pass through harmlessly, but some flip a memory bit from 0 to 1 — corrupting data or crashing software. On Earth, the atmosphere and magnetic field shield us. In deep space there is no shield, so the computer must detect and repair its own errors in real time.
⚠ Radiation Effects
Single Event Effects (transient)

SEU (Single Event Upset) — one ion flips one bit. MBU (Multiple Bit Upset) — one ion flips several adjacent bits at once. SET — a transient glitch in logic. These are soft errors: recoverable if caught.

Destructive & cumulative

SEL (Single Event Latchup) — a parasitic short that can burn out the chip unless power is cycled. TID (Total Ionizing Dose) — slow cumulative degradation measured in krad. DD — displacement damage to the silicon lattice (solar cells, sensors).

🛡 Defense-in-Depth
Four layers that work together
1
TMR (Triple Modular Redundancy): three copies of a computation run in parallel; a voter outputs the majority. A single faulty replica is silently overruled. Failure needs two replicas wrong at once — roughly 3p² vs p, a huge reliability gain.
2
SECDED ECC memory: a Hamming code (39,32) that Single Error Corrects and Double Error Detects. One flipped bit per word is fixed transparently; two are detected. Cost: 21.9% extra storage.
3
Memory scrubbing: a background task continuously re-reads and rewrites memory, fixing single-bit errors before a second one accumulates in the same word (which SECDED could not correct). Bit-interleaving spreads each logical word across physical cells so one ion rarely hits two bits of the same word.
4
FDIR + watchdog: Fault Detection, Isolation & Recovery. A watchdog timer must be “kicked” by healthy software; if it expires, the system resets and reloads a golden image. After exhausting its recovery budget, it drops to a minimal-power SAFE-MODE and waits for ground.
📊 By the Numbers
~200×
Fewer errors with ECC + scrubbing + interleaving
3,334×
TMR reliability gain (p = 1e−4 / op)
200 krad
RAD750 dose tolerance (>2000× Mars margin)
~0.9/day
Residual uncorrectable over Earth–Mars transit
🔬
Flight Heritage
NASA’s RAD750 (Curiosity & Perseverance command computers) tolerates ~200 krad and is latchup-immune. ESA uses the LEON3FT / GR712RC fault-tolerant SPARC processor. AETHERIX models this stack in src/computing/radiation.py (Earth–Mars transit: ~37,000 raw upsets → ~186 uncorrectable).
🎯
The Analogy
It works like an emergency room. A patient in cardiac arrest (a spacecraft fault alert) is seen immediately, ahead of someone with a routine check-up (a bulk file transfer) — even if the routine patient arrived first. AETHERIX triages every bundle by urgency and deadline before it touches the downlink.
🔢 Four-Tier Classification
TierClassExamplesBPv7 priority
P0Emergency / Safety-criticalHealth telemetry, collision avoidance, fault alertsEMERGENCY
P1Mission-criticalCommand acknowledgements, time-sensitive scienceHIGH_SCIENCE
P2High-priorityRoutine telemetry, scheduled scienceSTANDARD
P4Low / BulkHousekeeping logs, file transfers, software imagesBULK
⚙ Three Levers
Compression

Shrink data before sending. Lossless telemetry via CCSDS 121.0-B-3 (Rice) ≈ 3×; lossy imagery via CCSDS 122.0-B-2 (wavelet) ≈ 10×; video (H.265) ≈ 50×.

Deadline-aware scheduling

A preemptive QoS scheduler orders traffic by priority, then by earliest deadline. Items that cannot meet their deadline this contact are deferred to the next one — no point sending stale data.

BPv7 fragmentation

A huge low-priority bundle does not block the link: the scheduler sends the portion that fits this contact and defers the remainder, keeping utilization at 100%.

📊 By the Numbers
100%
Link utilization (no wasted bandwidth)
5 / 6
Items fully delivered, by priority
BPv7
Bulk fragmented to the next pass
Preempt
Emergency uses direct-to-Earth backup
📡
Worked Scenario
A 30 Mbps, 15-minute oversubscribed contact: emergency health telemetry, command ACKs, a seismic event capture and the daily panorama all get through; a 6 GB software update is fragmented (41% now, the rest next pass). Modeled in src/routing/prioritization.py.
📊 Performance Comparison
MetricCurrent (MRO)AETHERIXImprovement
Downlink Speed0.5–6 Mbps2–200 Mbps10–100×
Daily Data Volume5–10 GB50–100 GB10–20×
Availability60–75%>95%+20–35%
RoutingStatic (CGR)AI-Adaptive (RL)Autonomous
SecurityAES-256QKD + Post-QuantumFuture-proof
Scalability5–10 assets241 nodes10–100×
Solar ConjunctionComplete blackout50–70% via Lagrange relays+50–70%
🎯
What Does This Mean?
Current Mars missions return about 5–10 GB of data per day. AETHERIX could increase that to 50–100 GB — enabling high-resolution video, real-time scientific analysis, and support for multiple simultaneous missions. It’s the difference between receiving a few photos and streaming HD video.
🌎 Real-World Impact
🔬

Scientific Discovery

More data means more science. High-resolution imagery, spectral analysis, atmospheric measurements, and real-time telemetry from rovers, orbiters, and landers.

👨‍🚀

Human Missions

Reliable communication is critical for crewed Mars missions. Astronauts need to communicate with Mission Control, receive emergency updates, and transmit medical data.

🤖

Autonomous Operations

With AI routing, the network operates autonomously during blackouts and unexpected events — critical when you can’t wait 20+ minutes for a response from Earth.

🔮

Future-Proof Security

Quantum computers will eventually break current encryption. QKD provides information-theoretic security that no computer, classical or quantum, can ever break.

💡
The Bigger Picture
AETHERIX isn’t just faster — it’s a fundamentally new approach to space communication. It scales from a single rover to an entire Mars colony, supporting scientific instruments, human habitats, and everything in between. This is the infrastructure humanity will need to become a multi-planetary species.
📅 Deployment Roadmap
1

Phase 1: Earth → Lunar (2028–2030)

Deploy QKD between ground stations and lunar orbiters. Validate optical links at ≤400,000 km with 1.3s round-trip delay. Establish the first quantum-secured space link.

2

Phase 2: Earth → Mars Relay (2030–2035)

Deploy Lagrange-point relays and Mars orbiters. RL routing agents begin training on real contact windows. Target: 50 Mbps average, >90% availability.

3

Phase 3: Full Network (2035+)

Scale to 241 nodes across all 5 tiers. Federated RL agents across the full mesh. QKD key exchange via quantum repeaters. Target: 200 Mbps at closest approach, supporting human missions.

🧭 Ecosystem Integrations (Audited)
HASTE
Payload Layer

Microsoft’s AI disaster-assessment framework (satellite imagery → rapid damage maps). Adopted as AETHERIX’s payload layer: imagery triage that concretely generates EMERGENCY vs BULK bundles instead of abstract traffic.

MIT · Q4
TorchGeo
Triage Models

PyTorch geospatial ML library with pre-trained Sentinel-2/Landsat weights. Trains the triage models whose outputs become BPv7 priority classes — research-side only, never a core dependency.

MIT · Q4
OpenMCT
Mission Ops

NASA Ames’ web-based mission-control framework, flown on real missions. The flight-ops console for ops-handbook drills — complementing Grafana’s platform/SRE view with a mission-ops view.

Apache-2.0 · Q4
F´ (F Prime)
Flight Software

JPL’s flight-proven C++ framework (Ingenuity Mars Helicopter), with a CFDP stack. The flatsat “Mars asset” option — making F´-CFDP ↔ AETHERIX-BPv7 file delivery a first-class interop experiment.

Apache-2.0 · Q3
🔍
Audited Before Adopted
Every external tool passed an audit before entering the roadmap: permissive license (MIT/Apache-2.0), active maintenance, flight-grade or peer-reviewed provenance — and the rule that no new dependency enters the stdlib core: ML stacks live payload-side and the core consumes their outputs, never their libraries. OpenC3 COSMOS (AGPL dual-license) and Azure Orbital (paid service, collides with the no-ground-station-claims rule) were evaluated and excluded on the record. Full audit table: docs/ROADMAP_12MO.md.
🌎
Not Just Space — Earth Applications Too
DTN technology developed for space has immediate terrestrial applications: disaster response (networks when infrastructure is destroyed), maritime and Arctic communications (intermittent satellite coverage), military tactical networks (hostile jamming environments), and remote IoT sensors (agriculture, environmental monitoring with limited connectivity). The same protocols that work between planets work between disconnected areas on Earth.
💰
The Economics
Three levers push the effective cost per delivered bit down: higher data-rate capability (more bits per pass), autonomous operations (fewer ground staff per contact), and multi-mission sharing of relay infrastructure. AETHERIX does not implement a cost model, so no specific dollar-per-MB figure is claimed here — the design point is the direction of these levers, not a costed savings estimate.
📚
Standards Compliance
AETHERIX is built on international standards: RFC 9171 (BPv7), RFC 4838 (DTN Architecture), RFC 5326 (LTP), RFC 7242 (TCPCL), CCSDS 734.2-B-1 (CCSDS Bundle Protocol), CCSDS 141.0-B-1 (Optical Communications), and CCSDS 401.0-B-30 (RF). This ensures interoperability with existing and future space agency infrastructure worldwide.
📊 Performance Comparison
AETHERIX vs Current Systems
AETHERIX vs Current Mars Communication — 10–100× faster data rates, >95% availability, quantum-secure encryption, and 241-node scalability vs 5–10 assets today.
Challenge
Today's Mars communication relies on 5–10 aging assets with static routing, 0.5–6 Mbps data rates, and 60–75% availability — insufficient for human missions.
Purpose
Head-to-head comparison across 8 metrics: downlink rate, daily volume, availability, routing, security, scalability, conjunction resilience, and cost per MB.
Impact
AETHERIX delivers 10–100× faster rates (2–200 Mbps), >95% availability (via Lagrange relays), quantum-secure encryption, and scales to 241 nodes — ready for Mars settlement infrastructure.
Development Roadmap Timeline
Development Roadmap — Phases 1–4 complete (topology, BPv7, RL routing, QKD). Phases 5–8: ns-3 simulation, ION-DTN integration, hardware prototypes, and decoy-state QKD validation.
Challenge
Moving from proof-of-concept to production requires integration with NASA's ION-DTN stack, realistic ns-3 network simulation, and eventually hardware-in-the-loop testing.
Purpose
Maps the phased development roadmap from current working demo through production deployment, with clear milestones for each phase.
Impact
Phases 1–4 are complete with 44 modules, 768 tests, and 15 interactive demos — including the demo-grade DQN routing agent (src/routing/dqn_agent.py, stdlib-only, trained under the deterministic safety shield) and the examiner’s distance test enshrined as CI (tests/test_distance_sensitivity.py: 55/225/401 M km runs must differ). Phases 5–8 target ns-3 integration, DQN productionisation, optical hardware demonstration, and decoy-state QKD validation — quarter-gated in docs/ROADMAP_12MO.md.
🔍
Quick Find
Press Ctrl+F (or ⌘F on Mac) and type any term to jump straight to it. Terms are grouped into categories below — each card shows the acronym, full name, a concise definition, a concrete example, and the standard or source file it comes from.
📦 Protocols & Standards
BPv7 — Bundle Protocol v7

The IETF standard (RFC 9171) that defines how data is packaged, addressed, and transported across networks with long delays and intermittent connections. The core protocol of DTN.

Example: A 500 MB rover scan becomes one bundle with a source, destination, priority and lifetime. It survives seven hops to Earth without any end-to-end connection ever existing.

RFC 9171
DTN — Delay-Tolerant Networking

A networking approach designed for environments where connections are intermittent, delays are extreme, and traditional protocols like TCP/IP fail. Think “postal service for data.”

Example: Posting a letter rather than making a phone call. The call needs both ends live at once; the letter is held at each post office until the next route opens.

CCSDS 734.2-B-1
LTP — Licklider Transmission Protocol

A reliable transport protocol (RFC 5326) designed for links with very long round-trip times. Provides assured delivery over single hops in the DTN architecture.

Example: Used on the Earth–Mars deep-space hop. It splits data into a “red part” that is retransmitted until acknowledged and a “green part” that is not, so it never waits for a round trip to open a session.

RFC 5326
TCPCL — TCP Convergence Layer

A convergence layer (RFC 7242) that adapts BPv7 to use TCP for reliable delivery on the Earth segment, where low-delay, persistent connections are available.

Example: Used on the Earth-side segment between DSN sites and mission control, where a normal reliable TCP stream already exists and round trips are milliseconds.

RFC 7242
UDPCL — UDP Convergence Layer

A convergence layer that uses UDP for fast delivery over optical inter-satellite links. Trades guaranteed delivery for speed, with fragmentation and loss simulation.

Example: Used inside the 48-satellite LEO laser mesh, where latency is tiny and loss is bursty rather than congestive — so TCP’s congestion control would hurt more than help.

RFC 9171
CCSDS

Consultative Committee for Space Data Systems. An international standards body that defines communication protocols for space missions. Used by NASA, ESA, JAXA, and others.

Example: The space-agency equivalent of the IETF. CCSDS 734.2-B-1 is the space profile of BPv7; CCSDS 141.0-B-1 covers the optical physical layer AETHERIX models.

Space Standards
RFC 9171

The IETF standard that formally defines Bundle Protocol v7 — the core DTN data format, including primary blocks, extension blocks, and processing rules.

Example: The document that defines what a bundle actually is — primary block, payload block, lifetime, priority. AETHERIX’s bundle.py implements this structure directly.

RFC 9171
RFC 5326

The IETF standard that defines the Licklider Transmission Protocol (LTP) — designed for reliable data transmission over links with very long delays.

Example: Specifies LTP. The key idea is that the sender does not need an acknowledgement to keep transmitting — essential when an ACK takes 22 minutes to come back.

RFC 5326
CGR — Contact Graph Routing

A static routing approach that pre-computes paths through a DTN using a graph of known future contacts. Deterministic but cannot adapt to unexpected changes.

Example: Plans a route from a published schedule: “Madrid sees Mars 16:00–24:00.” If the link fails at 17:00, CGR keeps following the stale plan — which is exactly the weakness AETHERIX’s RL agent addresses.

CCSDS 734.3-B-1
SABR — Schedule-Aware Bundle Routing

The CCSDS standardisation of Contact Graph Routing. It computes routes from a pre-published schedule of when links will exist, rather than from live network state. This is the static baseline AETHERIX’s reinforcement-learning agent replaces.

Example: A ground operator publishes a contact plan saying “Mars orbiter and DSN Madrid are in view 14:00–22:00 tomorrow.” SABR plans the whole route from that table in advance. If the link fails at 15:00, SABR keeps following the stale plan.

CCSDS 734.3-B-1
BPSec — Bundle Protocol Security

The security extension to BPv7. It adds integrity and confidentiality blocks to a bundle so that each hop can verify the payload has not been altered, without needing an end-to-end session.

Example: A bundle leaves Mars with an integrity block. Six hops later, a Lagrange relay can check the payload is unmodified on its own — it does not need to contact the sender, which would cost 44 minutes.

RFC 9172
ION-DTN

NASA’s reference implementation of the Bundle Protocol — the flight-proven DTN software actually used on spacecraft. It is the production system AETHERIX’s simulation is measured against.

Example: ION has flown on the International Space Station and on deep-space missions. AETHERIX does not use ION; it implements BPv7 independently so every component is inspectable, and cites ION as the interoperability target.

NASA JPL
BPA — Bundle Protocol Agent

The software component on each node that actually does the BPv7 work: accepting bundles, taking custody, storing them, choosing a next hop, and forwarding when a contact opens.

Example: Every one of AETHERIX’s 241 nodes runs a BPA. When a rover generates science data, its BPA wraps it into a bundle and holds it until the orbiter comes overhead.

RFC 9171
TTL — Time To Live (Bundle Lifetime)

How long a bundle is allowed to remain in the network before it is discarded as stale. Set by the sender, it stops undeliverable data from filling buffers forever.

Example: An emergency alert might have a 2-hour lifetime — after that it is worthless. A bulk science file might have 30 days, because it is still useful whenever it arrives.

RFC 9171
Custody Signal

The acknowledgement one node sends back to the previous custodian to say “I have accepted responsibility for this bundle; you may now free your buffer.” Custody transfer is not complete until this arrives.

Example: A Mars orbiter forwards a bundle to an L4 relay and keeps its own copy. Only when L4’s custody signal comes back does the orbiter delete it — so a failure mid-transfer never loses the data.

RFC 9171
Contact Plan

The pre-computed schedule of which nodes will be able to talk to which, and when. Derived from orbital mechanics, it is the input Contact Graph Routing depends on.

Example: “Goldstone sees Mars 08:00–16:00; Madrid sees it 16:00–24:00.” That table is a contact plan. Its weakness is that it describes the future as predicted, not as it turns out.

CCSDS 734.3-B-1
MTU — Maximum Transmission Unit

The largest block of data a link can carry in one piece. Anything larger must be fragmented before transmission and reassembled afterwards.

Example: A 500 MB science bundle cannot cross a link with a 64 KB MTU in one go, so BPv7 fragments it — which is also how AETHERIX fills the tail of a closing contact window instead of leaving it idle.

RFC 9171
🌐 Network Architecture
Node

Any endpoint in the DTN network — a satellite, rover, ground station, relay, or habitat. Each node can store, forward, and route bundles.

Example: AETHERIX has 241 of them, from DSN ground stations down to individual Mars surface sensors. Each one runs a Bundle Protocol Agent and can take custody.

A2 topology.py
Bundle

The fundamental data unit in DTN. Like a network packet but smarter — it carries its own address, priority, lifetime, and custody tracking information. Designed to survive long delays.

Example: The DTN equivalent of a packet, but self-contained: it carries everything needed to be delivered later, including its own lifetime and priority, because no session exists to hold that state.

RFC 9171
Custody Transfer

A responsibility handoff mechanism. When a node accepts custody of a bundle, it guarantees the bundle will not be lost — even if the original sender goes offline.

Example: A Mars orbiter forwards a bundle to an L4 relay but keeps its copy. Only when L4 signals “I have custody” does the orbiter delete it — so a mid-transfer failure never loses data.

RFC 9171
Store-and-Forward

The core DTN delivery model. Data is stored at each intermediate node until the next connection becomes available, then forwarded. No end-to-end connection required.

Example: In AETHERIX’s baseline run, 183 of 288 bundles are sitting in custody at intermediate nodes at the 24-hour mark. They are not lost — they are waiting for their next contact window.

A3 run_simulation.py
Convergence Layer

A protocol adapter that sits between BPv7 and the physical link. Each transport type (TCP, UDP, LTP) has its own convergence layer, letting BPv7 work over any link technology.

Example: The adapter between BPv7 and whatever link is actually underneath. AETHERIX uses three: LTP for deep space, TCPCL for Earth, UDP-CL for optical inter-satellite links.

RFC 9171
Contact Window

A scheduled period during which two nodes can communicate. Contact windows are predicted from orbital mechanics and define when data can be sent or received.

Example: “Optimal” windows run 8–12 hours at 99% availability; at solar conjunction the window drops to zero for two to four weeks.

A2 topology.py
EID — Endpoint ID

The DTN addressing format. Looks like dtn://node/service. Identifies the source and destination of a bundle, similar to an IP address but designed for delay-tolerant operation.

Example: Written dtn://mars.surface.rover-01/science. Unlike an IP address it names a destination role, not a reachable host — which is what lets you address somewhere currently unreachable.

RFC 9171
EIRP — Effective Isotropic Radiated Power

A measure of the power radiated by an antenna in a specific direction, combining transmitter power and antenna gain. Key metric in link budget calculations.

Example: AETHERIX’s 5 W, 22 cm optical terminal produces 144.4 dBm EIRP. It is the first term in the link-budget waterfall — how much power effectively heads toward the receiver.

A4 link_budget.py
ISL — Inter-Satellite Link

A communication link between two satellites, typically using optical (laser) or RF technology. Enables data relay without passing through a ground station.

Example: The 10 Gbps optical links between AETHERIX’s 48 LEO satellites. Because there is no atmosphere between them, these are the fastest links in the whole architecture.

A2 topology.py
Walker Delta Constellation

A standard pattern for arranging satellites in a constellation, defined by three numbers: total satellites, number of orbital planes, and the phase offset between planes. It gives even, predictable coverage.

Example: AETHERIX’s 48-satellite LEO laser mesh in Tier 2 is arranged this way. The pattern matters because it determines whether there is always a satellite overhead — and therefore whether a ground station ever goes dark.

Walker, 1984
MOC & SOC

Mission Operations Centre and Science Operations Centre. MOC flies the spacecraft — commanding, health, safety. SOC handles what the mission is for — planning observations and processing the science data.

Example: In AETHERIX’s Tier 1 these are two of the five ground nodes. A P0 emergency bundle is destined for the MOC; a 500 MB terrain scan is destined for the SOC.

A2 topology.py
Interplanetary Internet

The long-term vision DTN was invented to serve: a permanent, standards-based network spanning multiple planets, rather than a set of bespoke point-to-point links rebuilt for every mission.

Example: Today each Mars mission largely builds its own relay arrangements. An interplanetary internet means a new lander could join an existing network the way a new laptop joins Wi-Fi.

RFC 4838
BFS — Breadth-First Search

A graph algorithm that explores a network layer by layer, guaranteeing it finds the path with the fewest hops. AETHERIX uses it to generate candidate routes across the 241-node topology.

Example: BFS answers “what are the possible ways from this Mars rover to Earth?” The reinforcement-learning agent then decides which of those candidates to actually use, based on live link quality and buffer state.

A2 topology.py
🌏 5-Tier Network Architecture
🌐
The 5-Tier Model
AETHERIX organizes 241 nodes across five tiers, from Earth’s surface to Mars’s surface. Each tier serves a distinct role in relaying data across interplanetary distances.
Tier 1 — Earth Ground

The DSN ground stations on Earth: Goldstone (California), Madrid (Spain), and Canberra (Australia). These are the primary Earth-side endpoints for transmitting and receiving data.

DSN
Tier 2 — Earth Orbital

GEO relay satellites and a constellation of 48 LEO satellites with laser crosslinks. Aggregates and routes data from ground stations toward deep space.

GEO + LEO
Tier 3 — Deep Space Transit

Relay stations at the Earth-Sun Lagrange points (ES-L4, ES-L5). Provide critical routing during solar conjunction when direct Earth–Mars links are blocked by the Sun.

Lagrange Relays
Tier 4 — Mars Orbital

Areostationary and polar-orbit relay satellites around Mars. Receive data from deep space and distribute it to surface assets, or collect surface data for return to Earth.

Relay Orbiters
Tier 5 — Mars Surface

End-user assets on Mars: habitats, rovers, drones, sensor networks, and science instruments. The final destinations and sources of interplanetary data.

Rovers & Bases
DSN — Deep Space Network

NASA’s global network of large radio antenna dishes at Goldstone (USA), Madrid (Spain), and Canberra (Australia). Provides continuous coverage for deep space communication.

Example: Goldstone, Madrid and Canberra, spaced roughly 120° apart in longitude so at least one always has line of sight to a target as Earth rotates.

[1] NASA DSN
GEO — Geostationary Earth Orbit

An orbit at 35,786 km altitude where a satellite appears stationary relative to a point on Earth. Used for relay satellites that maintain constant position over ground stations.

Example: 35,786 km up, orbiting once per day so it appears fixed overhead. AETHERIX puts three GEO relays in Tier 2 as the bridge between the LEO mesh and deep space.

A2 topology.py
LEO — Low Earth Orbit

An orbit below 2,000 km altitude. AETHERIX uses a constellation of 48 LEO satellites with optical crosslinks to form a laser mesh network around Earth.

Example: Where AETHERIX’s 48-satellite laser mesh sits. Low altitude means short hops and high rates, but any single satellite is only overhead for minutes at a time.

A2 topology.py
Lagrange Point

A gravitationally stable position in a two-body orbital system where a smaller object can maintain a fixed position. AETHERIX uses Earth-Sun L4 and L5 for relay stations.

Example: ES-L4 and ES-L5 sit 60° ahead of and behind Earth in its orbit. That geometry keeps a line of sight to Mars around the solar limb when the direct path is blocked by the corona.

[3] JPL Horizons
🔬 Optical & RF Communications
FSPL — Free Space Path Loss

The loss of signal strength that occurs as a signal spreads out while traveling through free space. Increases with the square of the distance — a major challenge for interplanetary links.

Example: At Mars opposition it is about −353 dB, and at conjunction about −370 dB. Computed from 20·log₁₀(4πd/λ) — a single number that explains why deep space is hard.

A4 link_budget.py
Link Budget

A complete accounting of all gains and losses in a communication link, from transmitter output to receiver input. Determines whether a link can close — i.e., deliver enough signal to be usable.

Example: Add every gain, subtract every loss, and see whether anything usable arrives. AETHERIX’s optical budget closes at +4.31 dB at opposition; Ka-band at the same rate does not close at all.

A4 link_budget.py
Link Margin

The difference between the received signal power and the minimum power required for reliable communication. Positive margin means the link works; more margin means more reliability.

Example: Positive means the link works. AETHERIX reports +4.31 / +3.33 / +3.08 dB at 55M / 225M / 401M km — and those are uncoded, so they are a floor rather than a prediction.

A4 link_budget.py
SNR — Signal-to-Noise Ratio

The ratio of desired signal power to background noise power. Higher SNR means clearer, more reliable communication. Measured in decibels (dB).

Example: AETHERIX requires 10 dB of SNR for its target bit error rate. Below that, the receiver cannot reliably tell a real photon from detector noise.

A4 link_budget.py
Aperture

The diameter of a telescope or antenna. Larger apertures collect more signal and produce narrower beams, enabling longer-range communication.

Example: Bigger collects more light and produces a tighter beam. AETHERIX models a 22 cm flight aperture against a 5 m ground telescope — the same asymmetry DSOC flies.

NASA DSOC
1550 nm

A near-infrared wavelength used for space optical communications. Chosen for its eye safety, low atmospheric absorption, and compatibility with terrestrial fiber-optic components.

Example: Chosen because the entire terrestrial telecom industry already builds lasers, amplifiers and detectors at this wavelength. NASA’s DSOC flies at exactly 1550 nm too.

Primary Wavelength
⚡
Radio Frequency Bands
AETHERIX supports multiple RF bands alongside optical links. Each band offers different trade-offs between data rate, range, and weather resilience.
Ka-band

26.5 GHz. High data rate but weather-sensitive. Primary RF band for high-throughput Mars downlink.

X-band

8.4 GHz. Moderate data rate with good all-weather performance. Used by most current Mars missions.

S-band

2.3 GHz. Lower data rate but highly reliable. Used for command uplink and emergency communications.

UHF

401 MHz. Ultra High Frequency. Short range, used for surface-to-orbiter links on Mars.

Doppler Shift

The change in frequency of a signal caused by relative motion between transmitter and receiver. Must be compensated for in space links.

Example: At 24 km/s relative velocity, a Ka-band carrier shifts by ±2.1 MHz. Without pre-compensation the receiver never acquires lock — the signal is outside the loop bandwidth.

A2 doppler.py
Atmospheric Attenuation

Signal loss from Earth’s atmosphere — clouds, rain, and gases absorb RF and optical signals. Optical links are more affected than RF. Typically 1–5 dB loss depending on weather.

Example: AETHERIX budgets −3 dB for clear sky. Cloud makes an optical link fail entirely, which is precisely why Ka-band RF is kept as the always-available fallback.

A4 link_budget.py
Pointing Loss

Signal loss from imperfect antenna/telescope alignment. Optical beams diverge only ≈5 μrad, so even tiny misalignments cause significant loss. Typically 1–3 dB per endpoint.

Example: AETHERIX budgets −1.0 dB at the transmitter and −0.5 dB at the receiver. At 494 million km you must aim at where Earth will be when the photons arrive, not where it is.

A4 link_budget.py
DSOC — Deep Space Optical Communications

NASA’s technology demonstration that proved laser communications work at interplanetary distance. It flies aboard the Psyche spacecraft, launched 5 October 2023, and is the flight heritage behind AETHERIX’s optical design.

Example: On 11 December 2023 DSOC sent ultra-high-definition video from 31 million km at 267 Mbps. On 3 December 2024 it downlinked from 494 million km — further than Earth and Mars ever get apart.

NASA DSOC [4]
PPM — Pulse-Position Modulation

A way of encoding data in when a light pulse arrives rather than how bright it is. Time is divided into slots, and which slot contains the photon carries the information.

Example: With 16 slots, a single detected photon carries 4 bits. That photon efficiency is why deep-space optical uses PPM — at Mars range you may receive fewer photons than you sent bits.

CCSDS 142.0-B-1
SCPPM — Serially Concatenated PPM

PPM combined with a powerful forward-error-correction code. The coding lets the receiver recover the data correctly even when a large fraction of photons are lost or arrive in the wrong slot.

Example: SCPPM is what DSOC actually flies. It is worth roughly 13 dB — and because AETHERIX’s link budget deliberately excludes it, AETHERIX’s reported margins are a conservative floor.

CCSDS 142.0-B-1
Coding Gain

How much weaker a signal can be, in decibels, and still be decoded correctly once forward-error correction is applied. It is the difference between what raw physics allows and what a real coded system achieves.

Example: AETHERIX’s uncoded budget returns −12.8 dB at DSOC’s demonstrated operating point. Since DSOC closed that link, roughly 13 dB of coding gain is exactly what the model leaves out.

A4 link_budget.py
SNSPD — Superconducting Nanowire Detector

A photon detector cooled to a few kelvin. A single arriving photon deposits enough energy to break superconductivity in the nanowire, producing a measurable voltage pulse — so individual photons can be counted.

Example: DSOC’s downlink receiver at Palomar Observatory is exactly this. The same detector family is used in QKD receivers, because both problems are “count single photons reliably.”

NASA DSOC
Beam Divergence

How quickly a transmitted beam spreads out with distance, set by wavelength divided by aperture. Narrower divergence means more of the transmitted energy lands on the receiver instead of missing it.

Example: A 1550 nm laser has a wavelength about 10,000× shorter than Ka-band radio, so for the same telescope size the beam is far tighter. That single fact is the entire case for optical over RF.

CCSDS 141.0-B-1
OCTL & Optical Ground Station

The Earth-side half of an optical link. NASA’s Optical Communication Telescope Laboratory at JPL’s Table Mountain Facility transmits the uplink laser, which the spacecraft also uses as a pointing beacon.

Example: The uplink does double duty: it carries low-rate commands, and it gives the spacecraft something to lock onto so it knows precisely where to aim its own downlink beam.

NASA DSOC
Dark Count

A detector click that was not caused by a real photon — thermal noise in the detector itself. Dark counts set the noise floor of a photon-counting receiver and directly limit how far a link can reach.

Example: In QKD, dark counts show up as errors in the sifted key, raising QBER even with no eavesdropper present. That is part of why a real channel never reads 0% QBER.

A5 qkd.py
Photon Efficiency

How many bits are carried per detected photon. Conventional radio thinks in watts; deep-space optical thinks in photons, because at these distances photons arrive one at a time.

Example: High-order PPM can carry several bits per photon. This is why quoting an optical link in raw power alone is misleading — the modulation choice changes the achievable rate for the same received energy.

CCSDS 142.0-B-1
🤖 Machine Learning & Routing
RL — Reinforcement Learning

An AI technique where an agent learns optimal behavior through trial and error, receiving rewards for good decisions and penalties for bad ones.

Example: Learning to navigate a new city without a map: try streets, notice which get you there faster, and gradually stop trying the dead ends.

A1 rl_agent.py
Q-Learning

A value-based RL algorithm that learns a “quality” score (Q-value) for every possible action in every possible state. The agent picks the action with the highest Q-value.

Example: The agent stores a value for every (situation, action) pair and updates it with the Bellman equation after each outcome. After 800 episodes AETHERIX’s agent converges on forwarding in 713 of 800 decisions.

A1 rl_agent.py
Q-Table

A lookup table that maps every network state to a value for each possible routing action. The agent’s “cheat sheet” built from experience. For larger networks, replaced by neural networks (DQN).

Example: A literal lookup table you can print and inspect row by row. That auditability is why AETHERIX uses one instead of a neural network — every routing decision can be explained.

A1 rl_agent.py
Epsilon-Greedy

A policy that mostly chooses the best-known action (exploitation) but occasionally tries a random one (exploration) with probability epsilon. Balances known good paths vs. discovering better ones.

Example: AETHERIX starts at ε = 1.0 (fully random) and decays by 0.995 per episode, reaching 0.018 after 800 episodes — about 98% exploiting what it has learned.

A1 rl_agent.py
Reward Function

A multi-objective scoring formula: R = α(delivery) − β(delay) − γ(hops) − δ(drops) − ε(energy). Guides the RL agent toward reliable, fast, efficient routing.

Example: R = +1.0(delivery) − 0.001(delay) − 0.1(hops) − 10.0(drops) − 0.01(energy). The drop penalty is ten times the delivery reward, which makes discarding a bundle strictly irrational.

A1 rl_agent.py
Federated Learning

A distributed machine learning approach where multiple nodes train locally and share only model updates (not raw data). Enables collaborative learning across the DTN.

Example: Each of the 241 nodes trains on what it can see locally, then they periodically merge Q-tables. Knowledge is shared without shipping raw telemetry across an expensive link.

A1 multi_agent.py
DQN — Deep Q-Network

A neural network that approximates the Q-table, enabling RL to scale to large state spaces. The production upgrade path from the current Q-table approach in AETHERIX.

Example: A neural network replacing the Q-table, which generalises to situations never seen before. AETHERIX deliberately does not use one — it is roadmap Phase 6, traded away for auditability.

Roadmap Phase 6
Exploration vs Exploitation

The fundamental trade-off in reinforcement learning. Exploiting means taking the best action you currently know; exploring means trying something else in case it turns out better.

Example: Always exploiting means never discovering a better route. Always exploring means never using what you learned. AETHERIX resolves it with ε-greedy: explore often at first, then decay to almost pure exploitation.

A1 rl_agent.py
Reward Shaping

Deliberately choosing the weights in a reward function so the agent learns the behaviour you actually want, rather than something that merely scores well.

Example: AETHERIX sets the drop penalty to 10.0 against a delivery reward of 1.0. That asymmetry makes discarding a bundle strictly irrational — the agent stores and waits instead. Late beats lost for science data.

A1 rl_agent.py
EWMA — Exponentially Weighted Moving Average

A running average that weights recent samples more heavily than old ones, so it tracks change quickly without storing history.

Example: AETHERIX uses it to track link quality. A link that just degraded should influence the routing decision more than how it behaved an hour ago — and EWMA does that in one number per link.

A1 contact_quality.py
🔐 Quantum & Security
QKD — Quantum Key Distribution

A method of creating shared secret keys using quantum physics. Any eavesdropping attempt disturbs the quantum states and is immediately detectable.

Unbreakable
BB84

The Bennett-Brassard 1984 QKD protocol. Uses polarized photons in two bases to establish a shared key. If an eavesdropper intercepts, the error rate rises above 11%.

Prepare & Measure
E91

The Ekert 1991 QKD protocol. Uses entangled photon pairs and Bell inequality tests to establish a key and detect eavesdropping simultaneously.

Entanglement-Based
QBER — Quantum Bit Error Rate

The error rate in quantum key transmission. If QBER is below 11%, no eavesdropper is present and the key is secure. Above 11%, the key is discarded.

Example: AETHERIX measures 0.0% on a clean channel and 24.7% under intercept-and-resend. It is a security parameter that bounds leakage — not an on/off eavesdropper alarm.

Threshold: < 11%
Qubit

The basic unit of quantum information. Unlike a classical bit (0 or 1), a qubit can be in a superposition of both states simultaneously. Measuring collapses it.

Example: In BB84 each qubit is a single photon’s polarisation. Unlike a classical bit it has no definite value until measured, and measuring it in the wrong basis destroys the original state.

[13] BB84
Quantum Repeater

A device that extends QKD range through entanglement swapping. Links short-distance quantum segments into a long-distance quantum channel.

Example: Needed because direct QKD key rate falls as 1/d² — at Mars range that is effectively zero bits per second. Chaining entanglement swaps through Lagrange relays is what makes the link possible.

A5 repeater_chain.py
PQC — Post-Quantum Cryptography

Cryptographic algorithms designed to resist attacks by quantum computers. Relies on mathematical problems hard for both classical and quantum computers.

Example: Classical algorithms chosen to resist a quantum attacker. AETHERIX pairs them with QKD because QKD distributes keys but cannot authenticate — you need both.

[16][17] NIST
CRYSTALS-Kyber

A NIST-standardized post-quantum key encapsulation mechanism. Used for securely exchanging encryption keys in a way that resists quantum computer attacks.

Example: Standardised by NIST as ML-KEM in FIPS 203 (2024). If you see both names, they are the same algorithm — Kyber was the submission, ML-KEM is the standard.

NIST Standard
CRYSTALS-Dilithium

A NIST-standardized post-quantum digital signature scheme. Used for authenticating messages and verifying identity in a quantum-resistant way.

Example: Standardised by NIST as ML-DSA in FIPS 204 (2024). This is the signature half, and it is what stops a man-in-the-middle attack on the QKD reconciliation channel.

NIST Standard
Privacy Amplification

A technique that reduces any partial information an eavesdropper might have about a key, by distilling a shorter, completely secret key from a longer one.

Example: Take 600 partially-compromised bits, run them through a universal hash, keep 400. You do not work out which bits leaked — compression destroys the eavesdropper’s partial knowledge wholesale.

A5 privacy_amplification.py
No-Cloning Theorem

A fundamental law of quantum physics: it is impossible to create an identical copy of an unknown quantum state. This is why QKD is secure — eavesdroppers cannot copy qubits.

Example: Wootters & Zurek, 1982. It is why an eavesdropper cannot simply copy a photon and forward the original — the universe forbids it, so she must measure and thereby disturb.

Wootters & Zurek 1982
Entanglement

A quantum phenomenon where two particles share correlated states, regardless of distance. Measuring one instantly determines the other. Einstein called it “spooky action at a distance.”

Example: Two photons whose measurement outcomes stay correlated no matter how far apart they are. E91 uses this instead of prepare-and-measure, and it is what entanglement swapping chains together.

[14] Ekert 1991
Sifting & the Sifted Key

The step after transmission where Alice and Bob publicly compare which basis they each used for every photon — never the bit values — and keep only the bits where the bases matched. Roughly half survive.

Example: Send 1,000 photons, keep about 500. That one-half is the q in the key-rate formula. Announcing a basis leaks nothing: knowing Alice asked the Z question says nothing about whether her answer was 0 or 1.

[13] BB84
Information Reconciliation

Correcting the remaining differences between Alice’s and Bob’s sifted keys over a public channel, so both end up with an identical string. Necessary because a key that differs by even one bit is useless.

Example: They exchange parities of blocks and binary-search to the mismatched bit. Everything said is public, so this step leaks information — which privacy amplification then has to remove.

Brassard & Salvail 1994
CASCADE

The standard information-reconciliation protocol for QKD. It runs several passes of block-parity comparison with shuffled block boundaries, binary-searching down to each error.

Example: Implemented in privacy_amplification.py. Its cost is measured in leaked bits: roughly h₂(Q)×n bits of information about an n-bit key become public.

A5 privacy_amplification.py
Binary Entropy — h₂(Q)

A measure of uncertainty in a two-outcome random variable: h₂(Q) = −Q·log₂Q − (1−Q)·log₂(1−Q). In QKD it converts an error rate into an amount of leaked information.

Example: The surviving fraction of a sifted key is 1 − 2·h₂(Q). Binary entropy reaches ½ at Q ≈ 0.11 — which is exactly why 11% is the abort threshold: the formula returns zero bits there.

[15] Shor-Preskill
Decoy States

A defence against attacks that exploit multi-photon pulses. The transmitter randomly varies pulse intensity, and the yields are compared per intensity — an attack affects them differently, so it becomes visible.

Example: AETHERIX does not implement decoy states; its model assumes a true single-photon source. This is a known limitation, scoped as roadmap Phase 8.

Roadmap Phase 8
PNS — Photon-Number-Splitting Attack

The attack decoy states defend against. Real transmitters use attenuated laser pulses that sometimes contain more than one photon; an eavesdropper keeps one and forwards the rest.

Example: Critically, PNS leaks key material without raising QBER at all — so QBER-based detection cannot see it. This is why an ideal-single-photon model is optimistic for real hardware.

Roadmap Phase 8
Bell Inequality & Bell Test

A statistical test that distinguishes genuine quantum entanglement from any classical explanation. If measured correlations exceed the classical bound (S > 2), the particles really were entangled.

Example: E91 uses this instead of the no-cloning theorem: if the Bell inequality is violated, no eavesdropper could have been present, because measuring would have destroyed the correlation.

[14] Ekert 1991
Entanglement Swapping

The mechanism that makes quantum repeaters possible. Two separately entangled pairs are joined by a measurement in the middle, leaving the two outer particles entangled despite never having interacted.

Example: Direct QKD to Mars is impossible — key rate falls as 1/d², reaching effectively zero. Chaining entanglement swaps through Lagrange relays is how the interplanetary segment becomes feasible at all.

A5 repeater_chain.py
ML-KEM (FIPS 203)

The NIST-standardised post-quantum key encapsulation mechanism, derived from CRYSTALS-Kyber. It establishes a shared secret using maths believed hard even for a quantum computer.

Example: AETHERIX pairs this with QKD: QKD distributes keys with physics-based security, ML-KEM provides a classical fallback wherever a quantum channel is unavailable.

[16] FIPS 203
ML-DSA (FIPS 204)

The NIST-standardised post-quantum digital signature algorithm, derived from CRYSTALS-Dilithium. It provides authentication that survives a quantum adversary.

Example: This matters because QKD distributes keys but does not authenticate. Without a signature layer, QKD is open to a man-in-the-middle. ML-DSA fills exactly that gap.

[17] FIPS 204
Finite-Key Analysis

Security accounting for the fact that real sessions exchange a finite number of photons. Asymptotic formulas assume infinitely many, so they overstate the extractable key for short sessions.

Example: AETHERIX’s bound R ≈ q[1 − 2h₂(Q)] is asymptotic. A real deployment must subtract a statistical-fluctuation term — scoped as roadmap Phase 8.

Roadmap Phase 8
Harvest Now, Decrypt Later

The threat model that justifies deploying quantum-resistant security today. An adversary records encrypted traffic now and stores it, waiting for a future quantum computer to break it.

Example: A Mars architecture designed now will still be operating in 20–30 years. Traffic intercepted today is still sensitive then — so computational security alone is not sufficient.

[16][17] NIST
Shor–Preskill Bound

The 2000 security proof for BB84 that established the 11% QBER threshold, by showing BB84 is equivalent to an entanglement-purification protocol whose security can be proven directly.

Example: This is the citation behind “QBER < 11%”. It is a statement about how much key can be extracted, not a detector that flags an eavesdropper.

[15] Shor-Preskill 2000
Csiszár–Körner Theorem

The 1978 information-theory result underpinning QKD: a secret key can be distilled whenever Alice and Bob share more mutual information with each other than either shares with an eavesdropper.

Example: It is the reason privacy amplification works at all — it says how much key can be salvaged from a partially compromised string, given the measured QBER.

Csiszár & Körner 1978
AES-256 & RSA

The classical encryption workhorses. AES-256 is symmetric (same key both ends); RSA is asymmetric and used for key exchange. Both rest on computational hardness, not physical law.

Example: RSA is the one that breaks first under a quantum computer running Shor’s algorithm. AES-256 is weakened but not broken. QKD replaces the key-exchange step precisely because that is the vulnerable half.

[16][17] NIST
SHA-256

A cryptographic hash function producing a fixed 256-bit fingerprint of any input. Any change to the input, however small, produces a completely different output.

Example: AETHERIX uses it in bundle integrity: each bundle is hashed and signed, so any relay can detect a single flipped byte without contacting the sender.

A6 bundle_integrity.py
☼ Orbital Mechanics
Synodic Period

The 780-day cycle over which Earth and Mars repeat their relative positions. Distance goes from closest approach (opposition) to farthest (conjunction) and back.

780 Days
Opposition

The point of closest Earth–Mars distance, approximately 55 million km. Signal delay is at its minimum (~3 minutes one-way). Best conditions for communication.

≈ 55M km
Conjunction

The point of maximum Earth–Mars distance, approximately 401 million km, with Mars behind the Sun. Signal delay peaks at ~22 minutes one-way.

≈ 401M km
Solar Conjunction Blackout

A ~2-week period around conjunction when the Sun lies directly between Earth and Mars, making direct communication impossible. Mitigated via Lagrange relays.

≈ 14 Days
True Anomaly

The angular position of a planet in its orbit, measured from perihelion. Used to calculate real-time Earth–Mars distance and contact windows.

Example: The angle from perihelion to the body’s current position. It is the slider in AETHERIX’s orbital demo — drag it and watch Earth–Mars distance sweep from 54.6M to 401M km.

A2 contact_windows.py
Perihelion

The closest point to the Sun in a planet’s orbit. Mars at perihelion is about 207 million km from the Sun.

Example: Mars at perihelion combined with Earth at the right point gives the 54.6 million km closest approach — the best case for any Mars communications link.

[3] JPL Horizons
Aphelion

The farthest point from the Sun in a planet’s orbit. Mars at aphelion is about 249 million km from the Sun.

Example: Contributes to the 401 million km worst case. Between perihelion and aphelion the distance varies by a factor of 7.3, and data rate by far more, since it falls with distance squared.

[3] JPL Horizons
Areostationary Orbit

The Mars equivalent of Earth’s geostationary orbit, at ~17,032 km altitude. A satellite here appears stationary over a fixed point on Mars.

Example: The Mars equivalent of geostationary, at 17,032 km altitude. A satellite there hovers over one spot on Mars, giving a surface base a permanently available relay.

A2 topology.py
AU — Astronomical Unit

149.6 million kilometers — the average distance from Earth to the Sun. Used as a standard unit for interplanetary distances. Mars orbits at ~1.52 AU.

Example: About 149.6 million km — the Earth–Sun distance. Mars sits at a semi-major axis of 1.524 AU, which is why its distance from Earth varies so dramatically.

149.6M km
Light-Time Delay

The time it takes for a signal traveling at the speed of light to traverse the distance between two points. Earth–Mars: 3 to 22 minutes one-way.

Example: 3.1 minutes at opposition, 22.3 minutes at conjunction, one way. Double it for a round trip: 6 to 44 minutes. This single fact is why TCP cannot work and DTN must.

[3] JPL Horizons
Quadrature

The orbital configuration where the Sun–Earth–Mars angle is about 90° — roughly halfway between opposition and conjunction, at intermediate distance.

Example: In AETHERIX’s orbital demo, quadrature sits at about 270 million km with roughly 15 minutes of one-way light time — between opposition’s 3 minutes and conjunction’s 22.

[3] JPL Horizons
MRO — Mars Reconnaissance Orbiter

The NASA orbiter that has served as the primary Mars relay since 2006. Its published performance is the industry baseline AETHERIX measures itself against.

Example: MRO’s Ka-band return link runs at 0.5–6 Mbps with 60–75% availability. Every AETHERIX comparison cites this as the baseline — and labels it as NASA’s figure, not a measurement of its own.

[1] NASA MRO
📊 Data & Metrics
Mbps

Megabits per second. A unit of data transfer speed. AETHERIX achieves 2–200 Mbps depending on Earth–Mars distance.

Example: MRO’s published Ka-band return link is 0.5–6 Mbps. AETHERIX targets 2–200 Mbps — a capability derived from the link budget, and labelled a target rather than a measurement.

[1] NASA MRO
dBm

Decibels relative to 1 milliwatt. A unit of absolute power level. 0 dBm = 1 mW.

Example: Decibels relative to one milliwatt. AETHERIX’s 5 W laser is 36.99 dBm; the signal arriving at Earth is around −90 dBm — roughly a billionth of a billionth of a watt.

A4 link_budget.py
dB

Decibels. A logarithmic ratio unit used to express gain or loss. +3 dB means double the power; −3 dB means half.

Example: A logarithmic ratio, so numbers add instead of multiplying. +3 dB is double the power, −3 dB is half. It is what makes a link budget a column of additions.

A4 link_budget.py
Throughput

Total data successfully delivered per unit time. Distinct from bandwidth — throughput accounts for protocol overhead and losses.

Example: Distinct from link rate: it is what actually gets delivered end to end. AETHERIX’s 500 MB Mars-to-JPL journey takes ~13 minutes against a 12.5-minute light-time floor — under 5% overhead.

A3 run_simulation.py
Latency

The end-to-end time from when data is sent to when it arrives. In interplanetary DTN, this includes propagation delay, storage time, and processing at each hop.

Example: In deep space this is dominated by physics, not equipment. No protocol improvement can beat the 3–22 minute light-time floor, which is why DTN optimises for delivery, not latency.

[3] JPL Horizons
Availability

The percentage of time that communication is possible. Current Mars missions achieve 60–75%; AETHERIX targets >95% via multi-path routing and Lagrange relays.

Example: MRO’s published figure is 60–75%. AETHERIX targets >95% using Lagrange relays for conjunction coverage — and that figure is labelled a design target, not a measurement.

[1] NASA MRO
Bit Error Rate (BER)

The fraction of bits received incorrectly. Deep-space links typically achieve 10−6 to 10−9 BER. Forward error correction (FEC) codes improve this by adding redundant bits for self-correction.

Example: AETHERIX designs to a 10⁻⁶ BER, which needs about 10 dB of SNR. One wrong bit in a million is tolerable for imagery; for a command sequence it is not, hence error correction.

A4 link_budget.py
📚
Continue Learning
This glossary covers every technical term used across the AETHERIX platform. For deeper explanations, visit the Learn pages — each topic is explained from the ground up with interactive demos. Start with What is DTN? for a guided introduction.
☢ Radiation-Hardened Computing
SEU — Single Event Upset

A single charged particle flips one bit in memory or a register. The most common soft error in space; corrected by ECC.

Example: A cosmic ray flips one bit in memory. AETHERIX’s radiation module measures 37,159 raw upsets over a 210-day cruise on 512 Mbit of unprotected memory.

A6 radiation.py
MBU — Multiple Bit Upset

One energetic ion flips two or more adjacent bits at once. SECDED cannot correct it — defeated by physically interleaving the bits of a word.

Example: One particle strike corrupts several adjacent cells at once, which defeats codes that can only fix one bit per word. The fix is bit interleaving, so adjacent physical cells belong to different words.

A6 radiation.py
SEL — Single Event Latchup

A particle triggers a parasitic short that can destroy the chip unless power is cycled. Mitigated with current limiting and latchup-immune (rad-hard) parts.

Example: A strike triggers a parasitic structure that draws destructive current. Unlike a bit flip this can physically destroy the part, so mitigation is current limiting plus a power cycle.

A6 radiation.py
TID — Total Ionizing Dose

Cumulative radiation dose (measured in krad) that slowly degrades electronics. The RAD750 tolerates ~200 krad — far above a Mars-mission dose.

Example: Cumulative damage rather than a single event — the part slowly degrades until it fails. The RAD750 gives roughly 2,127× margin over a 687-day Mars surface mission.

krad(Si)
TMR — Triple Modular Redundancy

Three identical units compute in parallel; a voter outputs the majority, masking any single faulty unit. Fails only if two agree wrongly (≈3p² vs p).

Example: Run three copies of the same computation and take the majority vote. If one is corrupted, the other two outvote it. AETHERIX measures a 3,334× reliability gain from TMR alone.

A6 radiation.py
SECDED / ECC

Single Error Correct, Double Error Detect. A Hamming-code memory (e.g. 39,32) that fixes one flipped bit per word and flags two. ~22% storage overhead.

Example: Single Error Correction, Double Error Detection — a (39,32) Hamming code. It repairs one flipped bit per word and notices two, but cannot fix two, which is why scrubbing matters.

A6 radiation.py
Memory Scrubbing

A background process that periodically re-reads and rewrites memory, repairing single-bit errors before a second upset accumulates and becomes uncorrectable.

Example: Periodically walk memory and repair single-bit errors before a second strike hits the same word. Without it, a correctable error eventually becomes an uncorrectable one.

A6 radiation.py
FDIR

Fault Detection, Isolation & Recovery. The autonomous logic that spots an anomaly, isolates the faulty unit, attempts recovery, and falls back to SAFE-MODE if it cannot.

Example: Fault Detection, Isolation and Recovery. Detect the fault, isolate the failing unit, reload it — and if the recovery budget runs out, drop to SAFE-MODE rather than fail silently.

A6 radiation.py
Watchdog Timer

A hardware timer that healthy software must periodically “kick.” If it expires (a hung CPU), it forces a reset — a last line of defense against radiation-induced lock-ups.

Example: A countdown the software must keep resetting. If it ever reaches zero, the system assumes the software has hung and reboots it. AETHERIX’s reaches SAFE_MODE after six ticks.

A6 radiation.py
RAD750

BAE Systems’ radiation-hardened flight processor used on Curiosity and Perseverance. ~200 krad tolerance, latchup-immune. ESA’s equivalent is the LEON3FT / GR712RC.

Example: The radiation-hardened PowerPC flown on Curiosity and Perseverance. Roughly 200 MHz — slower than a phone from 2005, but it survives an environment that would destroy the phone in days.

[18] BAE Systems
🔢 Data Prioritization & QoS
QoS — Quality of Service

Treating traffic differently by importance. AETHERIX maps every bundle to one of four priority tiers so urgent data is always sent first.

Example: Deciding what moves first when the link cannot carry everything. AETHERIX uses five classes, and P0 emergency traffic preempts whatever is currently in flight.

A7 prioritization.py
Priority Tiers (P0–P4)

P0 Emergency/Safety, P1 Mission-critical, P2 High-priority, P4 Low/Bulk — mapped onto BPv7 bundle priority for scheduling and preemption.

Example: P0 emergency (crew health, collision), P1 urgent (nav corrections), P2 normal (telemetry, science), P3 low (software updates), P4 bulk (archival). Five classes, strictly ordered.

A7 prioritization.py
Preemption

An emergency bundle interrupts an in-progress lower-priority transfer, is sent immediately (often via a low-rate direct-to-Earth backup), then normal traffic resumes.

Example: A P0 emergency arrives while a bulk file is transmitting. Preemption stops the bulk transfer mid-flight and sends the emergency instead — the bulk data resumes afterwards.

A7 prioritization.py
Deadline-Aware Scheduling

Ordering transmissions by priority and then by earliest deadline; data that cannot arrive in time this contact is deferred rather than wasting the link.

Example: Within one priority class, send whatever expires soonest first. Combined with strict priority across classes, this is what stops a time-critical bundle ageing out in a buffer.

A7 prioritization.py
Lossless Compression

Shrinks data with no information loss (telemetry via CCSDS 121.0-B-3, Rice coding ≈ 3×). Used where every bit matters.

Example: Rice coding under CCSDS 121.0-B-3 gives roughly 3× on telemetry. Every bit is recoverable, which matters when the data is a command log rather than a picture.

CCSDS 121.0-B-3
Lossy Compression

Discards perceptually-minor detail for much higher ratios (imagery via CCSDS 122.0-B-2, wavelet ≈ 10×; video ≈ 50×). Used for bulk imagery.

Example: Wavelet compression under CCSDS 122.0-B-2 gives roughly 10× on imagery by discarding detail the eye will not miss. Acceptable for a landscape photo, not for a checksum.

CCSDS 122.0-B-2
Bundle Fragmentation

Splitting a large BPv7 bundle so the portion that fits the current contact is sent and the remainder is deferred — keeping the link at full utilization.

Example: A contact window has four minutes left and the next bundle needs six. Fragmentation sends what fits and defers the rest, so the link is never left idle waiting for a whole bundle.

RFC 9171
SAFE-MODE

A minimal-power, beacon-only spacecraft state entered after repeated failures, preserving the vehicle while it waits for ground intervention.

Example: The spacecraft shuts down non-essential systems, points its antenna at Earth and waits for instructions. Deliberately boring — it is the state you want when nobody can reach you for 22 minutes.

A6 radiation.py
⏱
The 60-second version
If you only get one minute, run python run_simulation.py and talk over it. Six modules, no arguments, no external dependencies, deterministic on seed 42 — store-and-forward, link budget, RL convergence, conjunction recovery, QKD, and radiation hardening in a single command.
🛡 Fallback chain — never debug live

Work down this list. If something misbehaves, drop a tier and say so plainly: “Rather than debug that in front of you, let me show you the same result from the simulation.”

TierWhatWhy it is safe
1python run_simulation.pyNo network, no browser, no backend. Pure Python, zero external dependencies.
2Showcase from localhost:8080Static HTML/JS. No backend, no network dependency.
3./scripts/run_demos.sh 1-6Six standalone CLI demos, each runs independently.
4Read the source on GitHubAlways works. Content, not theatre.
✗React app + FastAPI backendMost moving parts. Two processes and a database — start before the call or not at all.
✅ Pre-flight (T−15 minutes)
If all five lines print, you are ready
$ cd ~/PROJECTS/AETHERIX $ source venv/bin/activate $ python -c "import sys; print('python', sys.version.split()[0])" python 3.14.6 $ python -m pytest tests/ -q | tail -1 643 passed, 1 warning in 38.15s $ python run_simulation.py > /tmp/preflight.txt 2>&1 && echo "sim OK" sim OK $ (cd docs && python3 -m http.server 8080 &) && sleep 1 && \ curl -s -o /dev/null -w "showcase %{http_code}\n" localhost:8080/index.html showcase 200
💡
Warm the simulation once before the call
The first run imports and compiles. A cold run in front of the examiner looks slow for no reason. Also open four tabs in this order: the deck, the showcase on localhost (never depend on the network), the GitHub repo for “show me the code”, and a terminal with the venv already active.
⌨ Track A · The terminal simulation

The spine of the demo. One command, six modules, every learning outcome.

$ python run_simulation.py ======================================================================== AETHERIX — Interplanetary DTN End-to-End Simulation ======================================================================== Python 3.14.6 | seed = 42 | 0 external dependencies
Say this first“Seed 42, zero external dependencies. Everything you are about to see is reproducible on your machine from the public repository.” That pre-empts the reproducibility question before it is asked.
Module 1

Baseline DTN store-and-forward

Network topology 5 tiers, 241 nodes (Earth/Mars) Simulated duration 24 hours Agent state untrained Q-table baseline Bundles generated 288 Bundles delivered 92 (31.9%) Bundles stored (in transit) 183 Average hops 59.0
What it means183 stored is the important number, not 92 delivered. Those bundles are not lost — they are in custody at intermediate nodes awaiting a contact window. That is store-and-forward working exactly as designed. The 59 average hops and 31.9% delivery are high/low because this agent is deliberately untrained — it is the “before” picture that Module 3 improves on.
Own it before you are asked“This module is deliberately the untrained baseline. The 31.9 percent is measured within the 24-hour window — sixty-four percent is still in custody and delivers on later contact windows. In DTN, undelivered is not the same as dropped.”
Module 2

Hybrid link budget — optical vs Ka-band

LO-c · LO-d
Opposition (55 M km) Optical (1550 nm) margin +4.31 dB Ka-band RF margin -14.39 dB One-way light-time 3.1 min Average (225 M km) Optical (1550 nm) margin +3.33 dB Ka-band RF margin -26.62 dB One-way light-time 12.5 min Solar conjunction (401 M km) Optical (1550 nm) margin +3.08 dB Ka-band RF margin -31.64 dB One-way light-time 22.3 min
What it meansLink margin is received power minus receiver sensitivity minus required SNR. Positive means the link closes. Optical closes at all three distances; Ka-band closes at none of them at these rates — that is the quantitative justification for the optical primary. Configuration: 5 W laser, 22 cm flight aperture, 5 m Hale-class ground telescope, distance-adaptive rates.
Say this unprompted“This is a conservative uncoded photon-counting budget. It excludes SCPPM coding gain and high-order PPM photon efficiency — together worth roughly 13 dB. These margins are a floor, not a rate prediction. As calibration: NASA’s DSOC downlinked 267 Mbps from 31 million km on 11 Dec 2023; my uncoded model gives −12.8 dB at that same point. Since DSOC demonstrably closed that link, that gap is the coding gain my model omits.”
Module 3

RL routing convergence

LO-g
Policy epsilon-greedy (epsilon_decay = 0.995) Episodes 800 Epsilon start -> end 1.000 -> 0.018 Exploration phase ~140 episodes to reach 70% exploitation Forward decisions (training) 713/800 Reward function R = +1.0(delivery) - 0.001(delay) - 0.1(hops) - 10.0(drops) - 0.01(energy)
What it meansEpsilon 1.000 → 0.018 is the learning actually happening — fully random to 98% exploiting. The drop weight of 10.0 against a delivery weight of 1.0 is the deliberate asymmetry: dropping is ten times more costly than delivering is rewarding, so the agent stores and waits rather than discards. For science data that cannot be recollected, late beats lost.
Likely question — “Is 713/800 good? Against what?”“It is a convergence indicator, not a performance score. I would not claim it as a benefit over CGR — I have not run a controlled head-to-head against a CGR implementation. That is the most significant gap in the work and the first thing I would close.”
Module 4

Solar-conjunction failure & recovery

Lead with this if short on time
Min link-quality threshold 0.3 Path evaluation (conjunction degraded): x Direct Mars -> Earth (1550 nm optical) nominal reward = -0.438 conjunction reward = -1.438 [CLOSED] ok Mars -> ES-L4 relay -> Earth (Ka-band RF) nominal reward = -0.201 conjunction reward = -0.201 [OPEN] ok Mars -> ES-L5 relay -> Earth (Ka-band RF) nominal reward = -0.201 conjunction reward = -0.201 [OPEN] RL agent decision (P0 bundle) forward -> transit.esl4.relay Policy engine (P0 EMERGENCY) forward via best_link Policy engine (P4 BULK) store [defer until link recovers]
What it means — the money shotThe direct optical path degrades from −0.438 to −1.438 as the corona blocks it; link quality falls to 0.05, below the 0.3 threshold, so it is marked CLOSED. The Lagrange paths are unaffected because L4 and L5 sit 60° ahead of and behind Earth and retain line of sight around the solar limb. The agent re-routes autonomously, and the policy engine then splits by priority: P0 forwards immediately, P4 is stored and deferred.
Say“Throughput drops, because Ka-band is slower than optical. Mission-critical data does not. And no operator was involved — which matters when a command takes 22 minutes to arrive.”

If asked why all rewards are negative: “The reward function charges for delay, hops and energy on every path — there is no free route. What matters is the ordering: −0.201 beats −1.438.”
Module 5

BB84 quantum key distribution

LO-b
Qubits exchanged 2048 Security threshold (QBER) < 11% Clean channel QBER 0.0% Sifted key bits 1019 Secure YES — key is valid Eavesdropped channel (intercept-resend) QBER 24.7% Secure NO — eavesdropper detected, key discarded
What it means2048 qubits → 1019 sifted is almost exactly half — the expected sifting factor, because Alice and Bob independently choose between two bases and agree about 50% of the time. That ½ is the q in the key-rate formula. 24.7% under attack matches the theoretical 25%: Eve guesses wrong half the time, and when she does Bob then reads the wrong bit half the time — 50% × 50%.
Say the nuance out loud“The common shorthand — ‘above 11 percent means Eve’ — is not what the threshold says. QBER is a security parameter: it bounds how much could have leaked and therefore how much key must be sacrificed. The surviving fraction is 1 − 2·h₂(Q), and binary entropy reaches ½ at Q ≈ 0.11 — so at 11 percent the extractable key is exactly zero. The abort rule and the key-rate formula are the same statement.”
— animated, one photon at a time. Use it if the examiner probes QKD depth.
Module 6

Radiation-hardened computing

LO-e
Environment interplanetary cruise (210 days, 512 Mbit) Raw bit upsets (unprotected) 37,159 Residual errors (TMR + SECDED ECC + scrubbing) 185.8 Protection factor 200x TMR reliability gain (@ p=1e-4) 3,334x RAD750 TID margin (687-day mission) 2,127x FDIR watchdog (6 ticks) final state: SAFE_MODE
What it means37,159 raw upsets reduced to 186 — a measured 200× reduction from the four-layer stack: TMR, SECDED ECC, memory scrubbing, and FDIR. Reaching SAFE_MODE after six watchdog ticks is the escalation working: detect, isolate, reload, and if the recovery budget is exhausted, fail safe rather than fail silent.
Likely question — “Measured or modelled?”“Measured within the simulation, and reproducible — module six, seed 42. It is not a hardware measurement: the upset-rate model is parameterised from published RAD750 and LEON3FT characteristics. I have not irradiated a physical part. So: measured in simulation, modelled with respect to reality.”
🖥 Track B · The showcase demos

Serve locally — cd docs && python3 -m http.server 8080 — and never depend on the network. All 15 demo tabs and 26 interactive controls were swept and verified working on 2 September 2026.

Optical Link Budget
1
Click Avg 225M km
2
Click ⚡ Calculate
Optical link budget calculator showing the full gain and loss waterfall
Open full size ↗
What the data meansThe waterfall shows every gain and loss term down to received power, then the margin against sensitivity. Point at the FSPL term — around −365 dB at average distance. That one number is why deep-space optical is hard, and it is computed from 20·log₁₀(4πd/λ), not looked up.
RL Routing
1
Click ❖ Get Decision
2
Click ⚛ Simulate Route
RL routing demo showing Q-values per action and the simulated route
Open full size ↗
What the data meansThe Q-value bars are the agent’s learned confidence for each action in the current state. The route visual then walks the chosen path hop by hop, colouring each node by action — forward, store, or drop — with total delay, hops and reward. Say: “Every one of those Q-values is a number I can show you in a table. That is the auditability argument for a Q-table over a neural network.”
Quantum Key Distribution — run both, in this order
1
Click ✧ Run Simulation — the clean channel
2
Click ⚠ Simulate Eavesdropper — watch the QBER jump
QKD demo, clean channel, key secure
Clean channel — full size ↗
QKD demo, eavesdropper detected at 25 percent QBER
Eavesdropped — full size ↗
What the data meansSifted key ~490 of 1000 is the ~50% sifting factor. QBER sits at the noise floor on a clean channel and jumps to roughly 25% under intercept-and-resend, flipping the banner to EAVESDROPPER DETECTED. The bit strip shows the first 40 sifted bits — matches green, mismatches red — so you can literally see Eve’s damage. The chart plots key length against error rate with the 11% threshold marked.
Do not skip the key-rate tableLEO 9.5 kbps · GEO 27.3 bps · Lunar 0.20 bps · Mars <0.01 bps — repeaters required. That collapse is 1/d² free-space diffraction loss, and it is the argument for entanglement-swapping repeaters on the interplanetary segment. It turns an apparent weakness into the justification for a design decision.
End-to-End Simulation
1
Click 🎯 Run Simulation
End-to-end simulation results with per-priority delivery breakdown
Open full size ↗
The number to point atEmergency traffic should always show the highest delivery ratio. If it does not, the priority scheduler is not working. That single comparison proves the QoS design in one glance.
Radiation Hardening
1
Click ☢ Run Simulation
Radiation simulation showing upset reduction per mitigation layer
Open full size ↗
What the data meansRaw upsets against residual errors after each mitigation layer, so TMR, ECC and scrubbing each show their individual contribution. Ends with the FDIR state machine escalating to SAFE_MODE.
Priority Scheduler
1
Click ⏰ Run Scheduler
Deadline-aware preemptive priority scheduler
Open full size ↗
What the data meansThe deadline-aware preemptive queue. Watch a P0 emergency preempt in-flight bulk traffic, and a large software update get fragmented so the remaining window is filled rather than wasted.
Orbital Mechanics & Bundle Protocol
1
Orbital: drag the true-anomaly slider → ☼ Calculate
2
Bundle: click ⚛ Create & Route
Orbital mechanics demo with distance, light time and synodic timeline
Open full size ↗
What the data meansDrag from opposition to conjunction and watch one-way light time go 3 → 22 minutes. The Bundle demo then shows a real BPv7 bundle — endpoint IDs in scheme://node/service form, priority class, lifetime, custody flag — and its routed path with per-hop actions.
⚖ Known limitations — own these before you are asked
💡
Volunteering a limitation costs nothing and buys credibility
Being caught hiding one costs the exam. Deliver each in three sentences: “The honest limitation is X. What I have demonstrated is Y. What I would do next is Z.” Then stop.
No controlled CGR comparison

RL convergence is demonstrated; a head-to-head delivery-ratio benefit against a real ION-DTN CGR implementation is not. This is the biggest gap.
Closed by Phase 5–6

Link budget is uncoded

No SCPPM coding gain, no high-order PPM efficiency — roughly 13 dB conservative against the demonstrated DSOC point. Margins are a floor, not a rate prediction.
Closed by Phase 5–7

Module 1 is an untrained baseline

Its 31.9% delivery ratio must never be quoted as system performance. It exists so Module 3 has a “before” to improve on.
By design — not a gap

Q-table, not DQN

No generalisation to unseen states. Deliberate, for auditability — DQN is roadmap phase 6, labelled as future work rather than claimed.
Closed by Phase 6

No hardware in the loop

Radiation figures are simulation outputs parameterised from published part characteristics, not irradiation testing.
Closed by Phase 7

Ideal single-photon BB84

No decoy states. A real weak-coherent-pulse source is vulnerable to the photon-number-splitting attack, which leaks key without raising QBER — so the current detection would miss it. The key-rate bound is also asymptotic, not finite-key.
Closed by Phase 8

Keplerian two-body orbits

Not JPL Horizons ephemeris. Good to a few percent; not mission-grade. Throughput and availability figures are targets, not measurements.
Closed by Phase 6

🔄
If something breaks live
Say this, calmly, and move: “That’s not behaving as it did in my pre-flight check — rather than debug it in front of you, let me show you the same result from the simulation.” Then drop to Tier 1 and run python run_simulation.py. Do not apologise twice and do not fix it live. Composure under a failed demo reads as engineering maturity.
Full walkthrough on GitHub →
☼ Earth–Mars Distance Over Synodic Period
❖ Network Topology
📺
Reading the Topology Map
Nodes are color-coded by network tier. Cyan particles flowing along edges represent data bundles being forwarded in real time. The 5-tier architecture routes data from Mars surface assets through orbital relays and Lagrange-point transit nodes to Earth ground stations.
Mars Surface Mars Orbital Deep Space Transit Earth Orbital Earth Ground Data Bundle
📚 Preparation & Research
🎯
What This Demo Shows
This simulation shows how an AI agent makes routing decisions in a delay-tolerant network. Given the current network state (which node you’re at, link quality, buffer fullness, bundle priority), the agent decides: forward (send to next hop), store (wait for better conditions), drop (discard undeliverable data), or split (send via multiple paths).
📏 Input Parameters Explained
Current Node & Destination

Current Node: Where the bundle is right now. Options span all 5 tiers from Mars surface to Earth ground stations. The agent considers which neighbors are reachable from this node.
Destination: Where the bundle needs to go. The agent calculates the best path from current node to destination through the network.

Priority & Buffer

Priority: EMERGENCY (0) through BULK (4). Emergency bundles force forwarding even on poor links. Bulk bundles may be stored until conditions improve.
Buffer Occupancy: How full the node’s storage is (0–100%). At >80%, the agent may drop low-priority bundles to make room for critical ones.

📈 Preset Test Cases
Emergency from Mars Surface

Setup: Node: mars.surface.rover-01, Dest: earth.control.moc, Priority: EMERGENCY, Buffer: 35%

Expected: Action: FORWARD immediately, even on marginal links. The agent prioritizes emergency delivery above all else — it will use any available path.

Why: Priority 0 overrides buffer and link quality concerns. Emergency data (solar flare alerts, system failures) cannot wait.

Standard at High Buffer

Setup: Node: transit.esl4.relay, Dest: earth.control.moc, Priority: STANDARD, Buffer: 90%

Expected: Action: STORE or cautious forward. With buffer nearly full, the agent may prefer to wait rather than risk a drop if the next hop can’t accept the bundle.

Why: At 90% buffer, the risk of overflow is high. Standard priority data can afford to wait for a cleaner transmission window.

Bulk Through LEO Mesh

Setup: Node: earth.leo.constellation, Dest: earth.control.moc, Priority: BULK, Buffer: 35%

Expected: Action: FORWARD or SPLIT. Low buffer pressure and proximity to destination allow the agent to route freely, potentially splitting for multipath delivery.

Why: LEO mesh has many paths to Earth ground. Bulk data benefits from multipath delivery — even if some fragments are lost, the total throughput is higher.

📈
Understanding the Output
Action: What the agent decided (Forward/Store/Drop/Split). Next Hop: Which neighbor receives the bundle. Confidence: How sure the agent is (0–100%). Higher = more experienced. Reasoning: Plain-language explanation of why this decision was made. Try “Simulate Route” to see the full multi-hop path.
Network State
35%
🎯
What This Simulation Does
This tool simulates quantum key distribution — the process of creating an unbreakable shared secret key between two parties (Alice and Bob) using quantum physics. You’ll see how many usable key bits are generated, whether an eavesdropper was detected, and why quantum mechanics guarantees security.
📏 Parameters Explained
Protocol

BB84: Alice sends photons in random orientations, Bob measures them. Simple and widely studied.
E91: Uses entangled photon pairs — both parties measure the same entangled particles. More robust against certain attacks but harder to implement.

Qubits / Pairs

Number of quantum particles exchanged. More qubits = longer final key. Typically 50–60% are “sifted out” (discarded because Alice and Bob used different measurement bases), so 1000 qubits → ≈500 raw key bits.

Channel Error Rate

Simulates natural noise in the quantum channel (detector errors, atmospheric scattering). If error rate exceeds 11%, the key is discarded — this could indicate eavesdropping. Normal channels: 1–5% error.

📈 Preset Test Cases
Clean BB84 Exchange

Setup: BB84, 1000 qubits, 0% error

Expected: QBER ≈0%, Secure: Yes, Sifted key ≈500 bits. Perfect channel with no noise.

Why: With zero channel error, Alice and Bob’s bits match perfectly when they use the same basis. The QBER stays well below the 11% threshold.

Noisy Channel

Setup: BB84, 1000 qubits, 8% error

Expected: QBER ≈8%, Secure: Yes (barely). Key is kept because QBER is below 11%, but some bits will be discarded during privacy amplification.

Why: 8% is high for natural noise — approaching the security threshold. The protocol remains secure but the final key is shorter after error correction and privacy amplification.

Eavesdropper Detected

Setup: BB84, 1000 qubits, click “Simulate Eavesdropper”

Expected: QBER >11%, Secure: No. The key is discarded entirely. Eve’s measurements disturbed the quantum states.

Why: The no-cloning theorem means Eve can’t copy qubits — she must measure them, which collapses their quantum state. When she guesses the wrong basis (≈50% of the time), she introduces errors that Alice and Bob detect.

🔐
Understanding the Output
Raw Key Length: Total bits before sifting. Sifted Key: Bits where Alice and Bob used the same basis (≈50% of raw). QBER: Error rate — below 11% = secure. Secure: Whether the key is safe to use. Efficiency: Percentage of raw qubits that became usable key bits.
Protocol Configuration
0%
Key Rate Estimates by Distance
🎯
What This Tool Shows
This orbital mechanics calculator predicts the Earth–Mars distance over time and identifies communication “contact windows” — periods when the link geometry is favorable for data transfer. Understanding these windows is essential for planning when to transmit high-priority science data vs. low-priority bulk data.
📏 Parameters Explained
Start Day

Day 0 = Mars opposition (closest approach, ≈55M km). The synodic period is 780 days. Day 390 ≈ conjunction (farthest, ≈401M km). This lets you simulate any point in the Earth–Mars orbital cycle.

Duration

How many days to simulate. Shorter windows (30–90 days) show detailed contact scheduling. The full 780-day period shows the complete distance cycle from opposition through conjunction and back.

📈 Preset Test Cases
Opposition Window

Setup: Start: Day 0, Duration: 90 days

Expected: Distance starts at ≈55M km, light delay ≈3 min. Multiple high-quality contact windows. Data rates 50–200 Mbps.

Why: At opposition, Earth and Mars are at their closest. This is the golden window — schedule your highest-priority data transfers here.

Conjunction Blackout

Setup: Start: Day 370, Duration: 60 days

Expected: Distance peaks at ≈401M km. Solar conjunction causes a ~2-week communication blackout around day 390. No direct contact windows.

Why: Mars passes behind the Sun from Earth’s perspective. The Sun’s radio interference makes direct communication impossible — only Lagrange relay paths work.

Full Synodic Period

Setup: Start: Day 0, Duration: 780 days

Expected: Complete distance curve showing the sinusoidal variation. Best windows in first/last 90 days. Worst around day 390.

Why: The 780-day synodic period is the fundamental planning cycle for Mars missions. All link budget, routing, and scheduling decisions reference this timeline.

📊
Reading the Charts
Distance Timeline: Shows Earth–Mars distance over the selected period. Lower = better for communication. Contact Windows: Highlighted periods where link geometry supports data transfer. Summary Stats: Min/max/average distance, light-time delay, and estimated data rates for the selected window.
Configuration
Quick presets:
Summary
Distance Timeline
Contact Windows
🎯
What This Tool Does
This simulator creates Bundle Protocol v7 data units — the fundamental messages in a DTN network. You configure the source, destination, priority, and payload size, then watch as the bundle is constructed with full addressing, custody tracking, and lifetime management. Use “Create & Route” to see it traverse the network.
📏 Bundle Fields Explained
Source & Destination

DTN Endpoint IDs in the format dtn://node/service. The source is where the bundle originates; the destination is the final recipient. The routing engine computes the multi-hop path between them.

Priority & Payload

Priority: EMERGENCY (0) — life-safety alerts. BULK (4) — archive dumps. Determines queuing order at each hop.
Payload: The actual data in MB. Bundles can carry up to GBs — millions of times larger than TCP packets.

Deadline & Lifetime

Deadline: Hours until the bundle must arrive. Expired bundles are dropped to free buffer space.
Lifetime: Maximum days the bundle can exist in the network. Prevents stale data from circulating forever in a DTN.

📈 Preset Test Cases
Emergency Alert

Setup: Rover → Earth MOC, EMERGENCY, 1 MB, 4h deadline

Expected: Immediate forwarding through all hops. Custody transfer at every node. Priority 0 means it jumps to the front of every queue.

Why: Small payload + highest priority + short deadline = fastest possible delivery. Think solar flare warning or system failure alert.

Science Data Dump

Setup: Rover → Earth MOC, STANDARD, 500 MB, 168h deadline

Expected: Standard queuing at each hop. May be stored at intermediate nodes during unfavorable contact windows. 7-day deadline allows flexible routing.

Why: 500 MB of science data can tolerate delays. The routing agent will choose energy-efficient paths and wait for good contact windows.

Bulk Software Update

Setup: Earth DSN → Mars Areo, BULK, 2000 MB, 720h deadline

Expected: Lowest priority in every queue. Sent during off-peak windows when no higher-priority data is waiting. 30-day lifetime accommodates slow delivery.

Why: Software updates are large but not time-critical. The network fills spare capacity with bulk data, maximizing throughput without impacting operations.

📦
Understanding Bundle Details
After creating a bundle, you’ll see: Bundle ID (unique UUID), Primary Block (source, destination, timestamp), Priority (queuing order), Lifetime (expiration), Custody (which node is responsible), and Flags (fragmentation, ACK requests). “Create & Route” shows the full multi-hop path through the 5-tier network.
Create Bundle
Active Bundles
🎯
What This Engine Simulates
The DTN Engine is the heart of the network — it demonstrates how data is segmented, transmitted, and reassembled using the Licklider Transmission Protocol (LTP) over lossy deep-space links. Below the LTP simulator, the Policy Engine shows how different routing policies make decisions based on bundle priority, buffer state, and link quality.
📏 LTP Parameters Explained
Payload Size

The bundle payload in bytes. LTP breaks large payloads into segments that fit the link MTU. Larger payloads = more segments = more chances for loss, but also more efficient use of the link.

MTU (Maximum Transmission Unit)

The largest single segment that can be sent in one frame. Smaller MTU = more segments = more overhead but finer-grained retransmission. Deep-space links typically use 1400 bytes.

Link Loss Rate

Percentage of segments lost in transit (simulates atmospheric interference, pointing errors). LTP selectively retransmits only lost segments — not the entire payload. Critical for 20+ minute delay links.

📈 Preset LTP Test Cases
Clean Link

Setup: 10000 bytes, 1400 MTU, 0% loss

Expected: 8 segments sent, 8 received. Zero retransmissions. Total transfer time = 1 round trip.

Why: With no loss, LTP is a simple segmentation protocol — split, send, acknowledge. The ideal baseline case.

Moderate Loss

Setup: 10000 bytes, 1400 MTU, 5% loss

Expected: ≈1 segment lost on average. LTP retransmits only the lost segment. Total transfer time ≈2 round trips.

Why: At 5% loss, roughly 1 in 20 segments is lost. LTP’s selective retransmission is far more efficient than TCP’s go-back-N approach over 20-minute-delay links.

Heavy Loss

Setup: 100000 bytes, 1400 MTU, 20% loss

Expected: ≈72 segments, ≈14 lost. Multiple retransmission rounds required. Transfer time ≈3–4 round trips.

Why: At 20% loss, the link is severely degraded (solar storm scenario). LTP still delivers — eventually — because each retransmission round only resends what was lost, not everything.

⚙
LTP vs TCP Over Deep Space
TCP would timeout and retransmit the entire window after a single loss — wasting precious bandwidth on a 20-minute-delay link. LTP sends a report of exactly which segments arrived, and the sender retransmits only the missing ones. For a 100KB payload with 5% loss, LTP saves ≈95KB of unnecessary retransmission compared to TCP.
LTP Segmentation Simulator
5%
⚙ Routing Policies
Policy Evaluator
35%
80%
🎯
What This Calculator Does
This tool performs RF (radio frequency) link budget analysis — the traditional approach for deep-space communication. While AETHERIX primarily uses optical (laser) links, RF provides critical backup, works through clouds, and handles command uplink where lasers are impractical.
📏 RF Parameters Explained
Frequency Band

Ka-band (26.5 GHz): Highest RF data rate but weather-sensitive. X-band (8.4 GHz): Current Mars standard — reliable, moderate speed. S-band (2.3 GHz): Command uplink. UHF (401 MHz): Mars surface-to-orbiter short range.

Dish Size (Tx & Rx)

Antenna diameter in meters. Larger dishes = higher gain = longer range. Spacecraft typically have 1–5m dishes; DSN ground stations have 34–70m dishes. Gain increases with frequency and dish size.

Tx Power & Data Rate

Tx Power: Transmitter output in watts. Spacecraft: 5–40W. Ground: up to 400W.
Data Rate: Target speed in bps. RF is much slower than optical: typical 1 kbps–6 Mbps vs optical’s 2–200 Mbps.

📈 Optical vs RF Comparison
PropertyOptical (1550nm)Ka-band RFX-band RF
Wavelength1550 nm11.3 mm35.7 mm
Beam Divergence≈5 μrad (very narrow)≈0.5 mrad≈1.5 mrad
Data Rate2–200 Mbps1–50 Mbps0.5–6 Mbps
Weather ImmunityLow (clouds block)Moderate (rain fade)High
Best ForBulk science downlinkHigh-rate backupReliable command/telemetry
📈 Preset RF Scenarios
Mars Relay (Ka-band)

Setup: Ka-band, 225M km, 20W, 3m/34m dishes, 1 Mbps

Expected: Link margin +2 to +6 dB. Reliable high-rate downlink for bulk science data at average distance.

Why: This is the baseline Ka-band scenario for Mars relay operations, representing typical operating conditions.

Safe Mode (X-band)

Setup: X-band, 225M km, 10W, 2m/34m dishes, 256 kbps

Expected: Link margin +8 to +15 dB. Very robust link for commanding, telemetry, and safe-mode operations.

Why: X-band is the reliable fallback when Ka-band is weather-impacted or during safe-mode. Lower data rate but very high margin.

Mars Surface (UHF)

Setup: UHF, 0.02M km (20km), 5W, 0.1m/0.5m antennas, 128 kbps

Expected: Link margin +15 to +25 dB. Short-range surface-to-orbiter link for rover and habitat communications.

Why: UHF fills the last-mile gap on Mars — connecting surface assets to orbiting relays. Very short range but sufficient for local networks.

💡
When to Use RF vs Optical
AETHERIX uses a hybrid approach: optical lasers for high-speed science data downlink (when sky is clear), Ka-band RF for high-rate backup and cloud-penetration, X-band for reliable command uplink and telemetry, and UHF for Mars surface-to-orbiter links. The RL routing agent automatically selects the best available link type for each bundle.
RF Parameters
🎯
What This Simulation Does
This runs a full network simulation across all 241 nodes in the 5-tier topology. It generates bundles at random Mars-side sources, routes them through the network using policy-driven forwarding, and tracks delivery statistics. This is the most comprehensive test of AETHERIX’s performance.
📏 Configuration Explained
Duration

Simulation time in hours. 168h = 1 week (good baseline). Longer runs show convergence behavior.

Time Step

Granularity in seconds. 3600 = hourly. Smaller steps = more accurate but slower.

Bundles/hour

Traffic generation rate. 10 = moderate load. 50+ = stress test. Higher rates test buffer management.

Seed

Random seed for reproducibility. Same seed + same config = identical results. Essential for scientific reproducibility.

📈 Preset Scenarios
Baseline (1 Week)

Setup: 168h, 3600s step, 10 bundles/h, seed 42

Expected: Delivery ratio >80%, avg delay 4–8h, 3–5 hops average. Emergency bundles: >95% delivery.

Why: Moderate load with reasonable timeouts gives the policy engine room to optimize. This is the standard benchmark configuration.

Stress Test

Setup: 168h, 3600s step, 50 bundles/h, seed 42

Expected: Delivery ratio drops to 60–75%. More drops and expired bundles. Buffer overflows at intermediate nodes. Emergency delivery stays >90%.

Why: 50 bundles/hour overwhelms the network’s capacity. This tests the priority queuing — emergency traffic should still get through while bulk data suffers.

Long Duration

Setup: 720h (30 days), 7200s step, 10 bundles/h, seed 42

Expected:; Shows long-term trends, orbital effects on delivery, and buffer utilization patterns over the synodic period.

Why: A month-long simulation reveals how changing Earth–Mars distance affects throughput over time and tests the routing agent’s adaptability.

📊
Reading the Results
Delivery Ratio: % of bundles that reached their destination. Average Delay: End-to-end time including storage at each hop. Average Hops: How many intermediate nodes each bundle traversed. Priority Breakdown: Per-priority delivery stats — emergency should always be highest. Charts: Delivery over time (should trend upward as the agent learns) and priority distribution.
Simulation Configuration
🎯
What This Scenario Simulates
This is the full integration test — combining link budget analysis, RL routing decisions, QKD security assessment, and orbital mechanics into a single Mars mission scenario. It shows how all AETHERIX components work together over a realistic mission timeline.
📏 Scenario Parameters
Start Day

Day 0 = Mars opposition. Day 390 = conjunction. This sets the initial Earth–Mars distance and orbital geometry, which affects link budgets throughout the simulation.

Duration

Mission duration in days. 30 days = one contact window. 90 days = seasonal planning. 365 days = full mission phase showing distance variation.

Bundles per Type

Number of bundles generated for each priority level (5 levels). Total bundles = 5 × this number. 25 = 125 total bundles (moderate). 100 = 500 bundles (stress test).

📈 Preset Mission Scenarios
Opposition Campaign

Setup: Start Day 0, 30 days, 25 bundles/type

Expected: High throughput, low latency. QKD key rate — 5–10 kbps. Delivery ratio >90%. This is the best-case mission scenario.

Why: Opposition gives the shortest distance, strongest signal, and fastest data rates. Mission planners concentrate high-priority science observations for this window.

Conjunction Challenge

Setup: Start Day 370, 60 days, 25 bundles/type

Expected: Reduced throughput, some blackouts. Lagrange relays maintain partial connectivity. QKD key rate drops significantly. Emergency delivery remains >80%.

Why: This stress-tests the network’s resilience during the worst orbital conditions. The RL routing agent must find alternative paths through relays.

Full Mission Year

Setup: Start Day 0, 365 days, 15 bundles/type

Expected:; Shows the full performance envelope — from peak throughput at opposition through the conjunction bottleneck and back. Reveals seasonal patterns in delivery statistics.

Why: A full year captures the complete range of operating conditions. This is the scenario used for long-term mission planning and infrastructure sizing.

📊
Reading the Integrated Results
The mission results combine all subsystems: Data Transfer Timeline shows daily throughput varying with distance. Bundle Traffic Mix shows priority distribution over time. Routing Simulation shows which paths the RL agent selected. QKD Security Assessment shows key generation rate and security status for each link.
Scenario Configuration
🎯
What This Simulator Does
This tool simulates the rate of bit upsets (Single Event Upsets, SEUs) in a spacecraft computer’s memory during an Earth–Mars transit. It shows how the defense-in-depth stack — Error Correction Code (SECDED ECC), periodic memory scrubbing, Triple Modular Redundancy (TMR), and Fault Detection Isolation and Recovery (FDIR) — reduces uncorrectable errors by approximately 200× compared to unprotected memory.
📏 Parameters Explained
Environment

LEO: Low Earth Orbit — shielded by Earth’s magnetosphere, lowest upset rate.
Van Allen Belt: Trapped proton/electron belts — 10–100× higher rate than LEO.
Interplanetary Cruise: No magnetic shielding, galactic cosmic rays dominate.
Solar Particle Event: Worst case — solar flare injects massive proton flux.
Mars Surface: Thin atmosphere provides partial shielding (≈50% reduction vs. interplanetary).

Memory Size

Total memory in MB exposed to radiation. More memory = more bits that can be upset. A typical spacecraft computer has 256–2048 MB. Each bit has an independent probability of being flipped by an energetic particle.

Scrub Interval

How often the ECC engine reads and corrects every memory word. Shorter intervals catch more errors before they accumulate. 60s is typical for interplanetary missions. During solar events, 1–10s scrubbing may be required to prevent multi-bit upset accumulation.

📈 Preset Test Cases
Quiet Interplanetary Cruise

Setup: Interplanetary, 512 MB, 60s scrub

Expected: ≈186 uncorrectable errors/day residual after all mitigations. TMR + ECC handle the vast majority.

Why: Nominal operating scenario. Galactic cosmic rays produce a steady but manageable upset rate. The defense stack keeps residual errors to a level FDIR can handle.

Solar Particle Event

Setup: SPE, 512 MB, 60s scrub

Expected: Thousands of upsets — ECC overwhelmed without shorter scrub interval.

Why: Solar flares increase upset rates 100–1000×. Stress-tests whether scrub interval is short enough to prevent uncorrectable multi-bit errors.

Rad-hard Part (100× fewer upsets)

Setup: Interplanetary, 512 MB, 10s scrub

Expected: Near-zero residual uncorrectable errors.

Why: Radiation-hardened parts reduce upset rates by 100×. Combined with fast scrubbing, this is the gold standard for critical missions.

☢
Understanding the Output
Raw SEU Rate: Total bit upsets per day without any protection. After ECC: Remaining errors after single-error correction. After Scrubbing: Errors that accumulate between scrub passes. After TMR: Residual errors after triple-voting. Uncorrectable: Final errors requiring FDIR intervention. Protection Factor: How many × the defense stack reduced errors vs. raw rate.
Simulation Configuration
60s
🎯
What This Scheduler Does
Given a limited contact window (duration × data rate), this scheduler decides which bundles to transmit in priority order. It applies CCSDS compression, respects bundle deadlines, and can preempt lower-priority traffic when emergencies arrive mid-contact.
📏 Parameters Explained
Contact Duration

Length of the Earth–Mars communication window in minutes. Typical DSN passes are 8–15 minutes; high-elevation windows can reach 30–60 minutes. Shorter windows force harder prioritization decisions.

Link Rate

Data rate in Mbps. Optical links: 2–200 Mbps depending on distance. RF backup: 0.5–6 Mbps. Duration × rate = total capacity available.

Traffic Oversubscription

How much data is waiting vs. capacity. 150% = 1.5× more data than fits. 200%+ = severe contention. The scheduler must choose what to send and what to defer.

📈 Preset Test Cases
Typical Contact

Setup: 15 min, 30 Mbps, 150% oversubscribed

Expected: Emergency + mission-critical + science delivered. Bulk fragmented. Compression saves ≈40%.

Why: Standard operating scenario — enough capacity for critical data, bulk must wait.

Short Emergency Window

Setup: 5 min, 10 Mbps, 200% oversubscribed

Expected: Only P0 + P1 delivered. Heavy preemption.

Why: Degraded link or emergency situation — only highest-priority data survives.

High-Capacity Link

Setup: 30 min, 100 Mbps, 120% oversubscribed

Expected: Nearly everything fits — only small fraction of bulk deferred.

Why: Best-case near opposition with high-rate optical link.

📊
Reading the Schedule Output
Window Capacity: Total bytes available (duration × rate). Scheduled: Bundles that fit in priority order. Deferred: Bundles pushed to next window. Preempted: Lower-priority bundles evicted for emergencies. Compression Savings: Bytes saved by CCSDS compression. Utilization: Percentage of the window filled.
Scheduler Configuration
15 min
30 Mbps
⚖
The House Rule
AETHERIX is a scientific proof-of-concept, so each choice optimises for defensibility: can the reasoning be explained line-by-line, can the result be reproduced from a seed, and can the mechanism be printed and inspected? “Impressive-sounding” loses to “explainable” every time.
📧 Network Layer
Bundle Protocol v7 — over TCP/IP

Why: TCP’s three-way handshake and congestion control assume round-trip times below the retransmission-timeout floor. At 3–22 minutes of one-way light delay, a TCP session across the Earth–Mars gap is mathematically incapable of staying up, and continuous end-to-end connectivity never exists. BPv7’s store-carry-forward custody model (RFC 9171) moves the reliability unit from the link to the bundle, so a partitioned network still delivers. Why not TCP/IP: it is the right tool for the Earth and Mars local segments — and AETHERIX uses it exactly there (TCPCL, RFC 7242) — but not for the interplanetary backbone.

Optical primary + RF fallback — over optical-only or RF-only

Why: 1550 nm optical offers 10–100× the bandwidth of Ka-band at the same mass budget, but optical links die in clouds, dust, and solar-conjunction geometry; Ka/X-band RF survives them at lower rate. A hybrid terminal gets optical’s throughput with RF’s availability. Why not single-mode: optical-only forfeits conjunction-season communications entirely (see the solar_conjunction scenario’s RF-fallback behaviour); RF-only caps the science return by an order of magnitude.

1550 nm carrier — over 850 nm / 1064 nm

Why: 1550 nm rides the mature fibre-telecom component ecosystem — InGaAs detectors, telecom-grade amplifiers, WDM-quality optics — sits in a clean atmospheric transmission window, and is the band NASA’s own lunar lasercom demonstrations used. The honest trade: for a fixed aperture, a shorter wavelength actually diffracts less — 850 nm would give a tighter beam — but you would trade into a component desert: no flight-qualified amplifier chain, no detector ecosystem, worse receiver sensitivity in practice. The optics supply chain is part of the link budget.

🚚 Transport & Data Flow
Segment-matched convergence layers — over one transport everywhere

Why: each segment’s physics picks its transport. The Earth segment (milliseconds, wired) runs TCPCL (RFC 7242) where TCP’s ecosystem of TLS and middleboxes wins. The deep-space hop runs LTP (RFC 5326), whose checkpoint-based selective ARQ was engineered for minutes-long delays — no handshake, no ACK clock. The laser crosslinks run UDPCL with fragmentation, because an ISL has no congestion, only loss. Why not one transport: every candidate fails somewhere — TCP dies at light-time, LTP over a LAN is wasted machinery, bare UDP has no reliability at all.

Hop-by-hop custody transfer — over end-to-end retransmission

Why: an end-to-end acknowledgment across Earth–Mars costs a 6–44 minute round trip — the sender stalls for the better part of an hour per loss. DTN custody (CCSDS 734.2-B-1 §3 + Annex D) moves the retransmission duty hop-by-hop: each relay accepting custody re-sends only over its own short-delay link, and buffer space becomes the network’s currency. Why not end-to-end: it treats a 2-hop and a 20-hop path identically and pays full light-time for every recovery — through a network whose whole point is that the path is long.

Routing over the time-varying contact graph — over static link-state routing

Why: OSPF-style protocols compute paths over a connected snapshot of the topology; the interplanetary graph is disconnected most of the time — an edge exists only inside a scheduled contact window. AETHERIX routes over the (node, time) contact graph (contact_graph.py): pathfinding only through contacts that are actually open at forwarding time. Why not link-state: a table computed on “connected now” would be empty for hours at a stretch, and one computed on “eventually connected” hands bundles to voids.

Priority classes + deadline-aware scheduling — over FIFO queuing

Why: in a 2 Mbps conjunction-season window, an EMERGENCY telecommand and a bulk terrain map cannot politely share a queue — one of them is worthless if late. Bundles carry one of five BPv7 priority classes (EMERGENCY…BULK), and the scheduler orders within each class by deadline, preempting bulk for time-critical traffic (prioritization.py). Why not FIFO: it is trivially fair and trivially wrong — fair to the data, not to the mission.

🤖 Routing & Autonomy
Reinforcement learning — over static Contact Graph Routing

Why: CGR (CCSDS 734.3-B-1) computes best routes from a pre-planned contact schedule — optimal while the plan holds, brittle the moment it doesn’t. A dust storm delays a rover, a relay drops to safe mode, and the graph no longer matches reality. An RL agent that observes link quality, buffer occupancy, and bundle deadlines keeps making the best available decision, and the reward function R = α(delivery) − β(delay) − γ(hops) − δ(drops) − ε(energy) encodes the mission’s actual trade-offs. Why not pure CGR: the DSN runs on schedules today, so AETHERIX’s policy engine ships CGR-style rule policies as the fallback tier — RL earns its keep in the disrupted cases the schedule can’t see.

Tabular Q-learning — over a TensorFlow DQN

Why: the state space is genuinely discrete — a 5-tier topology, bounded link-quality and buffer bins, five priorities, four actions — which is exactly the regime where a Q-table is the theoretically correct estimator, not a compromise. The learned policy can be printed and inspected cell-by-cell, every number is reproducible from a seed with zero external dependencies, and convergence is detectable by auditing the table’s deltas. Why not a DQN: deep networks pay off in continuous, high-dimensional spaces; here they would add a 2 GB dependency, version pinning, seed-sensitive training runs, and a black box in front of the exact quantities an examiner asks about (reward shaping, ε-decay, convergence). A DQN upgrade path exists in the roadmap — it is a deliberate later, not a miss.

EWMA statistical detection — over a trained deep-learning classifier

Why: the autonomy loop’s detector (src/simulation/anomaly.py) maintains per-node, per-metric EWMA baselines and flags ≥2 metrics simultaneously beyond 3.5σ. It is unsupervised (no labelled training set to drift out of date), explainable (every alarm cites its z-scores), self-limiting (anomalous samples never update the baseline, so an attack cannot poison its own detector), and deterministic stdlib. Why not a neural classifier: a supervised model trained on simulated attacks learns the simulator’s fingerprints rather than the physics, invites label leakage (severity or source fields derived from the ground-truth label sneaking in as features), and turns every “why did it fire?” question into an archaeology dig through weights. Detection here must be auditable at 3–22 minutes of light distance.

Physics-correlated telemetry — over random-value fuzzing

Why: the telemetry generator couples link margin and data rate to Earth–Mars distance through the orbital module (inverse-square law) and models each anomaly as a physically consistent signature — link degradation collapses margin, a custody storm fills buffers, radiation corruption spikes checksum failures while the link stays healthy, and a navigation spoof (POSITION_SPOOF) drives the reported-vs-ephemeris position error to thousands of km while every RF/optical observable stays healthy — the exact mismatch an onboard ephemeris cross-check would catch, mitigated by EPHEMERIS_CROSSCHECK + NAV_QUARANTINE. A detector can only be honestly evaluated against telemetry that behaves like physics. Why not uniform random features: any classifier looks good against white noise; the scientific-strictness rule (cite the sample, the seed, the config — no fabricated numbers) starts with the generator.

Deterministic policy fallback — over a pure learned policy

Why: an RL agent explores by design — and the day it explores badly is the day an EMERGENCY bundle meets a full buffer. The policy engine ships five deterministic rule policies as the guaranteed-safe tier (policy_engine.py); the learned policy earns discretion inside the envelope the rules allow. Why not pure RL: an untrained or drifting agent is a single point of behavioural failure; deterministic rules are auditable line-by-line before launch and boring in exactly the way safety-critical software should be.

Federated Q-table aggregation — over centralized training

Why: no Mars asset can stream gradients to an Earth learner at 3–22 minutes of light time — and back. Agents train locally on the traffic they actually see and merge Q-tables opportunistically when contacts allow (multi_agent.py) — the same delay-tolerant store-and-poll trick the network itself uses for data, applied to learning. Why not centralized: the training round-trip would be slower than the mission, and the central model would never see the local conditions (buffer pressure, link quality) each node actually routes under.

Byzantine-robust median aggregation — over plain FedAvg averaging

Why: plain averaging is optimal only when every contributor is honest — but a single compromised or corrupted relay contributing a poisoned Q-table shifts the mean arbitrarily. The coordinator’s coordinate-wise median tolerates up to just-under-half Byzantine contributors, and trimmed mean (dropping each cell’s min/max) suits small contributor counts; rounds also proceed with whoever shows up, because a federation that blocks on a relay behind the Sun never completes a round at all. Why not FedAvg: its robustness assumption (honest majority and full participation) is exactly what a 241-node network under attack and conjunction cannot promise.

Escalation ladder (WATCH first) — over immediate full response

Why: the first EWMA breach of an episode raises only a WATCH — raise sampling cadence, cross-validate against the node’s own baseline — and the full mitigation playbook fires only on a persistent breach (deployed at persistence = 2). In a sparse DTN topology, wrongly isolating a healthy relay (purging its custody refs, deferring its bulk traffic) costs real science return; a proportional response prices that in. Why not fire everything on first alarm: a detector with a nonzero false-positive rate plus an irreversible playbook is a system that cries wolf — and operators learn to ignore it, which is its own security failure.

Designed-in degradation modes — over fail-fast intelligence

Why: every intelligence dependency has a designed-in dumb fallback: an unconverged RL agent hands routing to the deterministic policy tier; a compromised or exhausted QKD pool drops security to classical hash-based mode; an unreachable audit sink spills to a bounded local buffer with a counted drop-oldest policy. Every switch is an audited event with a reason string (degradation.py). Why not let the smart part be load-bearing: the RL agent explores by design and the quantum channel has bad days; a network where “the AI is down” means “routing is down” has built its fragility in on purpose.

Decaying link-quality memory — over permanent averages

Why: link-quality observations decay exponentially with a configurable half-life (pheromone evaporation, contact_quality.py): fresh mediocrity outranks stale excellence by construction, and fully decayed memory falls back to the configured default — old news becomes ignorance, not pessimism. Why not a running average: an average over a link that was excellent before a conjunction and is dead after it will keep recommending a corpse for as long as the good samples outnumber the bad; decay forgets on a timescale you choose.

Hash-chained incident audit — over append-only plain logs

Why: each incident record commits cryptographically to its predecessor, so any retroactive edit — an attacker scrubbing their custody flood from history, or an operator quietly rewriting a response — breaks the chain, and verify_audit_chain() says exactly where. The same hash-chaining idea that makes blockchains append-only, applied to an operations log, at the cost of one SHA-256 per record. Why not a plain append-only file: “append-only” is a convention, not a property — nothing in a text log detects the line that was edited in place after the fact. If the audit record of an autonomous system can be silently rewritten, the autonomy has no accountability.

Convergence-gated training — over fixed episode budgets

Why: the trainer stops when Q-value deltas fall below a criterion, not after an arbitrary N episodes (training.py) — so “converged” is a measured property, and every reported learning curve cites both the episode count and the gate that ended it. Why not fixed budgets: too few episodes hides non-convergence behind a clean-looking curve; too many burns compute and invites overfitting to simulator quirks — either way the number you quote is about the budget, not the agent.

🔒 Security
QKD — over classical key agreement alone

Why: mission data must stay confidential for decades — an adversary can record ciphertext today and decrypt it once quantum hardware matures (“harvest now, decrypt later”). BB84/E91 key distribution is secured by physics (no-cloning, measurement disturbance), not by computational hardness, and eavesdropping raises QBER above the 11% Csiszár–Körner threshold where the key is simply discarded. Why not QKD alone: it needs line-of-sight quantum channels and only distributes keys — it neither authenticates nor survives a conjunction blackout — which is exactly why the integrity layer below exists.

Hash-based signatures — over RSA/ECC, and where ML-DSA sits

Why hash-based (Lamport + Merkle): security reduces to SHA-256’s collision resistance — Shor’s algorithm simply has no structure to attack, and Grover only halves the exponent — while verification is pure hashing, cheap enough for flight avionics doing per-bundle checks on the store-and-forward path. Why not RSA/ECC: both collapse under Shor; signing long-lived mission profiles with them is a dated-lock on the door. Why not ML-DSA (FIPS 204) here: lattice-based NIST standards are the right production choice, but their lattices and Fiat-Shamir layers are far harder to audit line-by-line than 256 hash comparisons; the hash-based family (Lamport 1979, Merkle 1979 — the same family NIST standardised as SPHINCS+/FIPS 205) demonstrates the identical post-quantum property with an implementation an examiner can read in one sitting.

Layered QKD + PQC — over either alone

Why: QKD delivers information-theoretic symmetric keys but cannot authenticate bundles or operate without a quantum channel; hash-based signatures authenticate anywhere, anytime, but rest on computational (quantum-hard) assumptions. Layered, each covers the other’s blind spot: keys from physics, integrity from hashing. Why not pick one: every real interplanetary security architecture (e.g. NASA’s DTN PKI studies) layers; a single-mechanism answer is the wrong answer for a 20-year mission.

Crypto agility with a CBOM — over fixed-algorithm security

Why: every signature names its algorithm, unknown IDs fail closed, and each run emits a cryptographic bill of materials — algorithms, key/sizes, quantum assumptions, rotation policy, and the registered upgrade path (ML-DSA-65, SPHINCS+-128s). A 20-year mission will outlive at least one cryptographic fashion; agility is the field that lets it negotiate. Why not hardcode today’s choice: “we’ll migrate later” without a negotiation field and an inventory is a wish, not a plan — and the byte-cost of security stays invisible until it eats a 2 Mbps conjunction-season link.

Deterministic seeded keyrings — over production CSPRNG keys

Why: in a reproducible research codebase, even key material must be regenerable — CI regenerates the keyring from a seed every build and asserts the verification chain end-to-end, so a security regression fails the pipeline, not the mission. Why not CSPRNG everywhere: production signing would, obviously, use os.urandom() — the module supports it (pass seed=None) — but unsaved random keys make test failures un-reproducible. The demo keys sign demo bundles; nothing here pretends otherwise.

Repeater chain with purification — over single-hop QKD to Mars

Why: direct single-photon exchange across 54.6–401 million km is beyond any realistic channel budget — the key rate collapses with distance no matter the engineering. The chain swaps entanglement hop-by-hop at Lagrange relays and purifies each pair before swapping, explicitly trading rate for fidelity (repeater_chain.py). Why not single-hop: the physics forbids it, not the budget — which is precisely why the relay tier exists in the topology at all.

CASCADE + universal-hash amplification — over shipping raw sifted keys

Why: a sifted BB84 key still leaks information proportional to the QBER. CASCADE reconciliation repairs Alice/Bob discrepancies, then universal-hash privacy amplification compresses exactly the leakable fraction back out — bounded by the Csiszár–Körner result, which is also where the 11% abort threshold comes from: a theory-derived constant, not a tuned hyperparameter (privacy_amplification.py). Why not raw sifted keys: the “secure” flag would be marketing — the same physics that detects Eve also quantifies her, and only amplification spends that knowledge.

☢ Computing & Scheduling
Layered radiation stack — over any single mitigation

Why: TMR outvotes computation faults, SECDED ECC fixes single-bit memory errors, scrubbing prevents a second fault accumulating in the same word, and FDIR bounds whatever survives — each layer exists because the layer above it has a measurable residual (~200× combined reduction; see Radiation Hardening). Why not one silver bullet: every individual mitigation has a failure mode the others catch; a single mechanism is a single point of failure with a cosmic-ray trigger.

FDIR + watchdog with SAFE-MODE floor — over unlimited autonomous recovery

Why: autonomy needs a floor. The FDIR controller has a bounded recovery budget — reset, reload golden image, retry — and when it is exhausted, the node drops to a minimal-power SAFE-MODE and waits for ground (radiation.py). Why not recover forever: an agent that never gives up can thrash indefinitely on an unfixable fault, draining power and corrupting state; knowing when to stop and phone home is itself a reliability feature — the same philosophy behind the deterministic policy fallback in routing.

🛠 Engineering
Stdlib-only simulation core — over NumPy/TensorFlow everywhere

Why: every module under src/ runs on a bare Python 3.9+ interpreter — clone, python src/simulation/telemetry.py, done. Zero pinned dependencies means zero version-drift failures and identical numbers on any machine, forever. Why not heavy frameworks: framework convenience is paid for in reproducibility, install time, and auditability; the core’s math (link budgets, orbital mechanics, EWMA, hash chains) needs no linear algebra library. External deps live where they earn their keep — FastAPI for the API surface — and nowhere else.

Acceptance gates in CI — over after-the-fact review

Why: the pipeline gates what ships, not what looks good: the security chain (sign → verify → tamper/replay rejected) must pass on every build; the autonomy ladder must hold its measured precision/detection/FP budgets across fixed seeds; and a known-event regression reruns the seeded solar-conjunction blackout asserting delivery survives, accounting stays physical, and two runs produce identical numbers. Why not manual review: security and quality properties decay silently; only an executable check that runs on every commit catches the regression the day it lands rather than the week before launch.

Physics plausibility guards — over trusting the simulator

Why: nothing propagates faster than c, margins/rates/temperatures stay in mission-class domains, contacts never overlap a blackout, and accounting identities hold — enforced by code (plausibility.py) that runs in CI behind every published figure. Why not eyeball the outputs: the failure mode of a simulation is a plausible-looking number that is physically impossible; guards turn that from a review-time argument into a build failure. This is also the discipline that separates a measured 3.5% conjunction-season delivery ratio from a slide that says “99.9% uptime”.

Stateless seed-recompute API — over telemetry warehousing

Why: POST /api/telemetry/stream recomputes the entire run from its seed instead of storing rows — what happened and what is stored cannot diverge, and the audit of any result is simply “re-run it”. Why not a telemetry database: persisted streams invite silent drift (schema changes, physics changes, pruned rows), and a stored anomaly that can’t be regenerated is indistinguishable from a bug. Stateless request/response also keeps every response a citable artifact — the same reason a streaming command endpoint was removed earlier in the project’s history.

FastAPI + Pydantic — over Flask + hand-rolled validation

Why: request schemas validate at the boundary (422 before any logic runs), response models document themselves, and /docs renders the whole API as interactive OpenAPI — the documentation cannot rot because it is generated. Why not Flask + manual checks: every endpoint grows its own validation archaeology, and hand-written API docs become a second codebase that lies the first time someone ships a field rename.

SQLite locally, PostgreSQL in Docker — over one database everywhere

Why: a fresh clone runs on SQLite with zero configuration — the whole stack boots with one script — while the same ORM serves containerized PostgreSQL when production parity matters. Why not PostgreSQL-only: forcing a database server onto every contributor for a simulation demo is a barrier with no benefit. Why not SQLite-only: you would never exercise the concurrency behaviour, types, and connection handling of the deployment target until deploy day.

🛡
The Four Invariants
Every redundancy in AETHERIX obeys the same four rules. 1. The belt is authoritative — local, primary, the source of truth for reads. 2. The suspenders are independent — a different mechanism, host, or trust domain, not a second copy of the same failure mode. 3. Losing the suspenders is a degradation — observable in metrics and health, never fatal to the belt. 4. Losing the belt has a pre-planned route — written down in the recovery runbook (ops/RECOVERY.md, 20 failure modes), never improvised mid-incident.
⚖ The Pairings — belt vs suspenders, and why
LayerBELT — primarySUSPENDERS — backupWhy this pairing
Persistence Local database (SQLite / PostgreSQL container) — every write lands here first Remote mirror (AWS RDS / GCP Cloud SQL / Azure) — best-effort upserts by primary key The local write must never wait on a WAN round-trip; the remote must never block or fail it. Mirror failures are counted (aetherix_db_mirror_failures_total), shown in /api/health, and re-converge automatically on recovery — no duplicates, no operator action
Dashboards Local Grafana (:3001) — 10 provisioned dashboards, zero external dependency Grafana Cloud via Prometheus remote_write — same metrics shipped off-host Operations need a zero-latency local view; history needs to survive the machine. Prometheus buffers remote writes on disk and replays them, so even the handover is lossless
Alerting Alertmanager → POST /api/alerts — alerts land in the local metrics stack Parallel external webhook (continue: true) — Slack/email/anything off-box The on-box loop must close locally (dashboards + counters); humans must be woken even if the box is the problem. Two receivers, same alert, independent paths
Search Meilisearch — typo-tolerant ranked full-text over 162 unique documents Backend substring engine over a committed manifest (GET /api/search) The fast engine is a container that can die; the fallback is a JSON file in git served by the API that is already running. The Modules hub switches automatically and labels the mode — search degrades in quality, never disappears
QKD keys Quantum-derived key escrow pool (KDF output, hash-chained custody ledger) Classical hash-based integrity mode — Lamport/Merkle signatures QKD supplies confidentiality but dies with the quantum channel (QBER > 11% or pool exhaustion); hash-based authenticity never depended on it. The degradation is automatic and audited
Routing intelligence RL agent — adapts to conditions the contact plan never modeled Deterministic policy tier — CGR-style rule policies A learning agent explores by design; an unconverged one must never be the only thing between an EMERGENCY bundle and its destination. The fallback engages on any unlearned state
Incident audit Hash-chained audit log — tamper-evident, append-only by construction Local incident spool — bounded drop-oldest buffer while the sink is down The chain guarantees the record cannot be silently rewritten; the spool guarantees the record survives the sink disappearing. Overflow is counted, then flushed in order on recovery
CI gates Jenkins pipeline — integrity / autonomy / resilience / API gates on every commit ./scripts/acceptance.sh — the same four gates, runnable on any laptop Verification must not depend on the verifier being up. Jenkins down must never mean “we ship unverified” — the local script mirrors the exact gate logic
Knowledge Wiki.js on the shared PostgreSQL — the editable working copy The showcase site + GitHub Pages — the immutable published copy Collaboration needs mutable; the submitted record needs immutable. The Pages deployment is a third copy in a different failure domain entirely (and the presentation there is locked)
Operations data Live scenario stream — the running behavior you can watch Seeded, reproducible history — every result re-derivable from seed + config Watching behavior is not the same as proving it. If the stream dies, the dashboards’ history is still re-generable deterministically — nothing observed is unverifiable
Service availability Container restart policies + healthchecks (unless-stopped, 15s probes) Blackbox probes → Prometheus → alerts → both alert receivers Self-healing covers the common crash; probing covers the case where the container is “up” but wrong. Together they answer both “is it running” and “is it actually serving”
⚠ Failure Behavior — what happens when each one breaks
If the BELT breaks (primary loss)

The suspenders are already holding the layer’s guarantee — that is their job. Every primary failure has a numbered entry in ops/RECOVERY.md with its detection signal and route: database → fail over to the remote mirror or replay-converge it; API → stateless restart (telemetry and integrity recompute from seed); Jenkins → the job re-seeds itself at boot; search → automatic fallback engine, then seed rebuilds the index deterministically.

If the SUSPENDERS break (backup loss)

A degradation, by construction — never an outage. The mirror is best-effort (local writes unaffected), remote_write buffers and replays, the external alert hook being down silences one of two receivers, and every one of these states is visible: /api/health reports the mirror, Prometheus metrics count the failures, Grafana panels surface them on the Security and Services dashboards. Silent degradation is the one failure mode this architecture forbids.

⚙
All external suspenders are env-flagged, and default OFF
The platform runs fully local with zero configuration: DB_MIRROR_ENABLED + REMOTE_DATABASE_URL (RDS/Cloud SQL/Azure), REMOTE_WRITE_URL/_USER/_PASSWORD (Grafana Cloud), ALERT_EXTERNAL_WEBHOOK_URL (parallel alerting) — documented with examples in .env.example, applied idempotently by scripts/render_monitoring.py (unsetting restores the committed local-only files byte-for-byte). The automatic suspenders — search fallback, routing fallback, security degradation, incident spool — need no flag: they engage only on failure. The full failure→detection→recovery matrix (20 entries) lives in ops/RECOVERY.md, and the cryptographic layer’s details in the PQC Integrity and Autonomous Ops sections.
⏱
The Light-Time Problem
One-way signal delay between Earth and Mars ranges from 3 to 22 minutes. When a custody-signalling storm floods a relay buffer, ground controllers learn about it at least 3 minutes later — and their response arrives at least 3 minutes after that. The anomaly has persisted for at minimum 6–44 minutes before any human intervention lands. Autonomy is not a luxury feature; it is the only way to protect the network inside a contact window.
📊 The Closed Loop
telemetry → detect → classify → watch / escalate → hash-chained record
1
Telemetry: every node reports seven physical metrics each minute — link margin, data rate, buffer occupancy, custody accept rate, checksum failure rate, avionics temperature, bus power. The nominal values are physics-correlated: data rate follows the inverse-square law with Earth–Mars distance, thermal state follows the orbital day.
2
Detect (EWMA): an exponentially-weighted moving average learns each node’s own baseline mean and variance per metric — unsupervised, no training data. A sample is anomalous when ≥2 metrics simultaneously exceed 3.5σ. Anomalous samples never update the baseline, so an attack cannot poison its own detector.
3
Classify: the dominant deviation pattern maps to a threat class — collapsed margin → LINK_DEGRADATION; custody storm + buffer fill → CUSTODY_FLOOD; checksum failures with a healthy link → PAYLOAD_CORRUPTION. Classification reads observable physics only — never the injection label (no label leakage).
4
Escalate: response is proportional — the first breach of an episode raises a WATCH (raised sampling cadence, cross-validation against the node’s own baseline); only a persistent breach fires the full playbook. Wrongly isolating a healthy relay in a sparse DTN topology is expensive, so the loop refuses to cry wolf: RF fallback and bulk deferral for degraded links, custody quarantine and buffer purge for floods, ECC scrubbing and bundle re-verification for radiation corruption.
5
Record: every incident is appended to a hash-chained audit log — each record commits cryptographically to the previous one, so any retroactive edit breaks the chain and verify_audit_chain() flags it. Records carry z-scores, playbook actions, and — for evaluation only — the injected ground truth.
⚠ The Anomaly Catalogue
LINK_DEGRADATION

Optical link attenuation: pointing loss, dust on the terminal, partial solar conjunction. Signature: link margin collapses by 8–12 dB, throughput falls to near zero. Response: Ka-band RF fallback, bulk traffic deferred to the next contact window.

CUSTODY_FLOOD

Spoofed DTN custody signals (CCSDS 734.2-B-1 Annex D aggregate custody signals) — a custody-signalling storm that fills relay buffers with hijacked references. Signature: custody accept rate ×8–14, buffer occupancy spikes. Response: custody quarantine, spoofed-reference purge.

PAYLOAD_CORRUPTION

Radiation-induced single-event upsets corrupt stored bundles during cruise (see Radiation Hardening). Signature: checksum failures jump from ~0.05/hour to 12–22/hour while the link stays healthy. Response: ECC scrubbing, bundle re-verification queue.

⚡ Designed-in Degradation
No intelligence dependency is a single point of failure

Every smart component has a designed-in dumb fallback, and every mode switch is an audited event with a reason string — degradation is a first-class operating state, never a silent failure (src/simulation/degradation.py):

RL unconverged → static routing
While the Q-table is immature (or the current state was never learned), the deterministic policy tier — CGR-style rule policies — routes every bundle. An untrained agent is never the only thing between an EMERGENCY bundle and its destination.
QKD compromised → classical security
QBER above the 11% threshold or an exhausted key pool switches security to classical mode: hash-based bundle integrity (which never depended on the quantum channel) keeps verifying, and the switch is recorded in the audit chain.
Sink unreachable → local spool
If the telemetry/audit sink drops, incidents buffer locally with a bounded drop-oldest policy — and the number of dropped-oldest records is surfaced, so the loss is observable, never silent.

A DegradationCoordinator exposes one dashboard-safe status object — what is degraded right now, and why — so an operator (or an examiner) never has to read three subsystems to answer “what fell back?”.

📏 Physics Constrains the Numbers
Plausibility guards on every quoted output

Numbers are only trustworthy if they are physical. src/simulation/plausibility.py validates every externally-quoted quantity against hard bounds — nothing propagates faster than c, link margins and data rates stay inside the mission-class domain, temperatures stay inside avionics limits, contact windows never overlap a conjunction blackout, and accounting identities hold (delivered ≤ generated, ratios in [0, 1]). The guards run in CI behind every published figure: a physics-violating regression fails the build, not the review. It is also why the telemetry anomalies themselves are physically consistent signatures rather than random spikes — a detector can only be honestly evaluated against telemetry that behaves like physics.

🔬
Reproducibility & Qualification
The full closed loop ships in src/simulation/telemetry.py and src/simulation/anomaly.py (stdlib-only, seeded). The detector is qualified with numbers, not adjectives: evaluate() reports detection rate, mean detection latency, and false-positive rate against the injected ground truth for every seed — running the deployed escalation ladder (first breach → WATCH, persistent breach → playbook), seed 42 at 80 ticks measures 26 incidents (13 WATCH + 13 escalated), 96.2% classification precision, 12/12 episodes detected, 1 false positive across 432 healthy samples (0.2%), audit chain verifying; the exact figures print from any run and are gate-checked in CI (detection ≥ 0.80, FP rate ≤ 0.05). Every published number must pass the physics plausibility guards (no faster-than-light delays, in-domain rates and margins, accounting identities) before it can be quoted. Each run cites its seed per the project’s scientific-strictness rule, and the incident audit is hash-chained so the record itself is tamper-evident. The same model powers the in-browser demo below with an independent JS implementation.
🔒
Why Hash-Based Signatures?
An adversary can record encrypted Mars traffic today and store it until quantum computers mature — the “harvest now, decrypt later” attack. RSA and ECC fall to Shor’s algorithm; hash-based schemes fall only to brute force, and Grover’s search gives at most a quadratic speedup — leaving SHA-256 at ~128-bit quantum security. Better still for deep space: verification is just hashing — no number theory — so a power-constrained Mars relay can verify bundles its flight CPU can actually afford.
⚖ How the Construction Works
One-time keys, amortised by a tree
1
Lamport keygen: for a 256-bit digest, generate 256 pairs of 32-byte secrets. The public key is the SHA-256 of each secret — 512 hashes total.
2
Sign: hash the bundle payload to a 256-bit digest; each digest bit selects which secret of pair i to reveal. Verification re-hashes the revealed secrets and matches them against the public key at exactly the digest-selected positions.
3
One-time property: each key signs exactly once. Two signatures under one key reveal both secrets of some pairs, letting anyone forge — so the verifier rejects any key index presented a second time (replay defence).
4
Merkle tree: the signer pre-generates N Lamport keys and publishes a single 32-byte Merkle root. Each signature carries its key index plus an authentication path proving membership — the verifier never needs the full key set on the wire.
🛡 Fail-Closed Verification Chain
Four checks, in order

1. Payload hash — the digest must match what was signed; any tampered byte rejects. 2. Merkle path — the claimed public key must belong to the published root. 3. Lamport proofs — every revealed secret must hash to its public-key slot. 4. Replay ledger — a key index that already verified once is refused forever.

Where it sits in the stack

This models the Bundle Integrity Block (BIB) from BPSec (RFC 9172) layered on BPv7 (RFC 9171 §4.3): the ground segment signs each bundle before transmission; every relay on the store-and-forward path can verify integrity locally before committing buffer space — complementing the QKD key distribution in QKD Science with authentication QKD does not provide.

Crypto agility — over fixed-algorithm security

Every signature carries an explicit algorithm_id (OTS-LAMPORT-SHA256 today). A verifier that does not recognise the ID fails closed — no silent cross-algorithm verification — so migrating to a post-quantum standard later is a negotiated field change, not a protocol break. The registered upgrade path names the standardised successors in the same family and class: ML-DSA-65 (FIPS 204) and SPHINCS+-128s (FIPS 205).

Cryptographic Bill of Materials

Every run emits a CBOM (crypto_bill_of_materials(), surfaced on the API and the Integrity tool): algorithms in use, key/signature sizes (8 KB Lamport public keys, 8 KB signatures, 32-byte Merkle root), classical and quantum security bits, the quantum assumption (collision resistance only — no Shor-vulnerable structure), rotation policy (one-time keys; exhaustion re-publishes the root), and the agility register. Security overhead is a measured line item against link capacity, not a footnote.

🔬
Implementation
Pure-stdlib, deterministic implementation in src/security/bundle_integrity.py (seeded keyrings for reproducible CI; production keys would come from a CSPRNG). Exercises as a build acceptance stage in the Jenkins pipeline and as an API endpoint (POST /api/integrity/demonstrate). Try the interactive demo below — it runs the same construction in your browser with the Web Crypto SHA-256.
💾 Secure Firmware OTA — the Same Signatures, Applied to Remote Code

The strictest trust boundary in the network is remote code execution by update: a forged firmware package that bricks an asset light-minutes away. src/security/firmware_ota.py reuses the Lamport/Merkle keyring to sign update manifests (hw id, version bounds, image hash), and the spacecraft verifies fail-closed before anything touches flash: hardware identity → image hash → ledger replay check → post-quantum signature → anti-rollback version floor. Every attempt — accepted or rejected — lands in a hash-chained update ledger whose replay protection survives reboots (one-time key indexes are re-fed from the ledger), and a rollback() path returns to last-known-good as an audited event.

QKD-keyed transport

The image travels encrypted under a key derived from a (simulated) QKD session — the same KDF as the key escrow pool — then rides the link as BPv7 fragments with per-chunk integrity.

Resume after contact loss

Contacts are lossy: the receiver acks chunks that arrived and the next contact retransmits only the missing ones — store-and-forward semantics one layer up, measured in the transfer stats.

Attacks, all rejected

Rogue keyring (valid construction, wrong root), tampered image, replay of a committed package, stale-but-legitimately-signed rollback — each fails its named gate; try it live via POST /api/ota/demonstrate.

AI safety shield

The learned router (tabular or DQN) sits under a deterministic shield (src/routing/safety_shield.py): EMERGENCY traffic can never be dropped, split, or routed by exploration, and quarantined relays are unreachable — overrides are audited, invariants asserted.

The compromised-relay story is closed end-to-end: a trust monitor (src/routing/trust_monitor.py) detects bundle withholding (custody accepted, traffic never seen downstream) and phantom contacts (advertised contacts that contradict the contact plan) via neighbour consensus — then contains the relay from both routing (shield quarantine) and federation (excluded from Q-table aggregation, so poisoned learning updates never land). The examiner’s own “empty shell” experiment is now a CI gate: tests/test_distance_sensitivity.py runs the simulator at 55, 225 and 401 million km and fails the build if the results match — distance drives light-time transit, the inverse-square downlink rate, and per-step contact capacity. See docs/ROADMAP_12MO.md (quarterly go/no-go gates), docs/MISSIONS.md (DSOC/Roman/Hubble/JWST, category-clean) and docs/QKD_READINESS.md (why a simulated QBER proves nothing — and the CHSH Bell test, shipped as E91Protocol.bell_test(), that would).

🔑 What It Means

A hash chain is an append-only log where every record cryptographically commits to the entire history before it. Each entry stores its own digest and the digest of the previous entry:

hashi = SHA-256( recordi ‖ hashi-1 )

The result is a one-way linked list: you cannot change, delete or reorder any historical entry without invalidating every hash that comes after it — including the head hash, a single 64-character fingerprint that seals the whole log. Verify the chain locally, compare the head against a trusted copy, and you have proven the entire history intact in milliseconds.

⚙ How It Works, Step by Step
1. Canonicalize

Each event is serialized to a canonical byte string (fixed field order, fixed encoding) so any verifier re-derives identical bytes.

2. Link

The entry's hash covers its own record plus the previous entry's hash. The first entry commits to a fixed genesis value.

3. Seal

Publishing the head hash (latest entry) is enough: it transitively commits to every entry ever appended.

4. Verify

Recompute the chain front-to-back. The first mismatching entry pinpoints exactly where tampering happened — everything after it is untrustworthy by construction.

Why Tampering Fails
Entry 1
h₁ = H(r₁, GENESIS)
→
Entry 2
h₂ = H(r₂, h₁)
→
✎ edit r₃
h₃' ≠ h₃
✗
Entry 4
h₄ built on h₃ — broken

An attacker who rewrites entry 3 must also recompute entries 4, 5, … N — and then must make you accept a different head hash than the one already published. If the head is mirrored off-host (or simply written down), the attack is detectable, not preventable: that is exactly what tamper-evidence means.

🚀 Why Deep Space Needs It
No online authority

One-way light time is 3–22 minutes. A Mars-side system cannot phone home for approval or a timestamping service. Its decisions must be self-evidencing: the log itself carries the proof of what happened and in what order.

Custody without observers

DTN custody transfer (CCSDS 734.2-B-1 §3 + Annex D — a profile of RFC 5050; BPv7 migrated custody to BIBE) means bundles change hands hop by hop with no end-to-end witness. A chained ledger gives each hop a non-repudiable record of what it received and forwarded.

Cheap to verify, expensive to forge

Verification is N hash computations — microseconds for thousands of entries, on any CPU, with no keys to distribute. Forging requires rewriting history and replacing every published copy of the head.

Quantum-safe by construction

SHA-256 chaining relies only on hash preimage resistance — no number theory for a quantum computer to attack (unlike RSA/ECC signatures). Same reasoning as the Lamport one-time signatures in the integrity layer.

🛠 Where AETHERIX Uses It (and Why)
UseWhereWhat is chainedWhy it is needed
Key-escrow custody ledger src/security/key_pool.py ADR-0002 Every deposit/withdrawal: H(key) commitment, pool depth, timestamp, previous hash; verify_ledger() recomputes the chain. QKD-derived keys are never persisted — the DB keeps metadata only. The chain proves what was issued and consumed, and that nobody silently edited the escrow history. Exposed live as the aetherix_qkd_key_ledger_ok metric on the Grafana Security dashboard (must stay 1).
Incident audit trail src/simulation/anomaly.py Every detected incident in the autonomy loop: canonical record + previous digest → audit_hash; verify_audit_chain() detects retroactive edits. An autonomous agent that quarantines traffic or escalates severity must leave evidence it cannot rewrite after the fact — the audit is the accountability record for actions taken without human sign-off.
Merkle keyring root src/security/bundle_integrity.py A binary Merkle tree over N Lamport one-time public keys; the root hash commits to all of them; sibling authentication paths prove membership. One published root authenticates every future bundle signature without transmitting the key set each time — bandwidth matters at 3–22 min light time. Merkle's 1979 construction, the same idea Bitcoin later built blocks on.
🔬
See it live
The API endpoint POST /api/security/qkd draws from the escrow (ledger grows), the Grafana Security dashboard verifies the chain every scrape, and python3 src/security/key_pool.py prints ledger entries plus a verify_ledger() verdict. Tamper with any stored entry in a REPL and re-verify — the chain reports the exact first broken index.
📚 The Lineage

The construction is old, battle-tested and everywhere once you know to look: Haber & Stornetta (1991) proposed linked timestamping for digital documents — the direct ancestor of the blockchain; git commits hash their parents (your repo is a hash chain with branches); Bitcoin chains blocks the same way (with proof-of-work on top); Certificate Transparency logs chain TLS certificates so misissued ones are caught; and Merkle (1979) generalized linking into trees, which AETHERIX uses for the keyring. The principle is identical each time: make history cheap to verify and expensive to rewrite.

🚀
What You Are Running
An in-browser implementation of the same model as src/simulation/telemetry.py + src/simulation/anomaly.py: six nodes across the 5 network tiers, one-minute telemetry ticks, physics-correlated baselines (inverse-square data rate, orbital-day thermals), and anomaly episodes injected with distinct physical signatures. The EWMA detector adapts to each node unsupervised; the escalation ladder runs exactly as deployed — first breach raises a WATCH (raise cadence, cross-validate), a persistent breach fires the full playbook. Every incident lands in the audit log with its severity, and the log is audited against the injection ground truth after the fact. Independent JS implementation — identical model, its own seeded RNG.
Simulation Configuration
4%
🔒
What You Are Running
The same construction as src/security/bundle_integrity.py, implemented in JavaScript with the browser’s native SHA-256: a seeded keyring of one-time Lamport keys rolled into a Merkle tree, four bundles signed and verified, then two attacks — a flipped payload byte (tamper) and a re-submitted valid signature (replay). Fail-closed: every check must pass.
Ground Station (Signer)
🎓 Free Courses & Certificates
▶️ Video Courses & Playlists (YouTube)

Free, full-length lecture series mapped to the learning objectives. Every playlist link was verified live — titles, channels and video counts checked on 2 September 2026.

🛠 Reference Tools & Software

Standard tools in this field, used here for cross-checking and further study. None are dependencies of AETHERIX — the core simulation runs on the Python standard library with zero external dependencies, which is what makes python run_simulation.py reproducible on a bare checkout.

📖 Key References (IEEE Format)
How to use: Pick a command on the left, read what it does and what to expect, then copy it and run it from the project root in your own terminal. Nothing is executed by the browser or a server — this page is a safe reference.
🛠 Shell Scripts
💻 Python Modules

Loading design docs…

The web interface is a full-stack React + FastAPI application that wraps every AETHERIX module behind interactive pages with real-time calculations, result history, info bubbles, external resources, and a command terminal. It runs locally via PM2 (SQLite) or Docker Compose (PostgreSQL).
Step 1: Install & Start
git clone https://github.com/matx104/AETHERIX.git
cd AETHERIX
./scripts/dev.sh setup    # install Python deps + Node.js deps
./scripts/dev.sh start    # start backend (:8000) + frontend (:3000)
What this does: dev.sh setup creates a Python venv, installs dependencies, and runs npm install in frontend/. dev.sh start launches both processes via PM2 — the FastAPI backend on port 8000 and the Vite dev server on port 3000.
Step 2: Open the App
URLWhat You'll See
http://localhost:3000Welcome page with module overview, stats, and showcase links
http://localhost:3000/dashboardDashboard with API health, network stats, showcase grid
http://localhost:3000/telemetryTelemetry & Autonomy — seeded streams, escalation ladder, incident audit
http://localhost:3000/integrityBundle Integrity — Lamport/Merkle signing, tamper + replay rejection, CBOM
http://localhost:8000/docsSwagger API docs for all 10 routers (+ /redoc)
http://localhost:8000/metricsPrometheus metrics — HTTP + domain counters (API reference in docs/API_REFERENCE.md)
API Surface (10 routers)
The FastAPI interface is fully documented — interactive at /docs, static in docs/API_REFERENCE.md, and exercised end-to-end by the CI pipeline and ./scripts/platform.sh verify.
RouterEndpointsPurpose
/api/healthGETService health + DB probe
/api/simulationsGET, POST, GET {id}, DELETE {id}Simulation run records (seeded)
/api/link-budgetPOST optical, POST rf/{band}, GET historyOptical + RF (Ka/X/S/UHF) link budgets
/api/routingPOST decide, GET decisions, POST train/stepRL routing decisions + training step
/api/orbitalGET distance, GET timeline, POST contact-windows, GET historyEarth–Mars distance, light time, contact windows
/api/securityPOST qkd, GET qkd/sessionsBB84/E91 QKD simulation + session history
/api/telemetryPOST stream, GET nodesAutonomy loop: EWMA detection, escalation ladder, audit (deterministic per seed)
/api/integrityPOST demonstratePost-quantum signature chain + tamper/replay tests + CBOM
/api/alertsPOSTAlertmanager webhook sink (counted per alertname)
/api/cmdGET catalog, GET catalog/{id}Copy-and-run command reference
Step 3: Navigate & Use Each Page
PageHow to UseShowcase Deep-Dive
Welcome / Landing page. Click any module card to open the tool, or click "Learn the science" to read the theory on this showcase site. Welcome
Dashboard /dashboard Shows API health, DB status, network stats. The Showcase & Learning grid links to 9 showcase pages. The Resources card lists key DTN references. Welcome
Link Budget /link-budget Pick a scenario (minimum, average, maximum) or enter a custom distance in km. Click "Calculate Optical Link". Results show EIRP, margin, data rate, loss. Scroll down for history and external resources. Optical Comms
RL Routing /routing Edit the network state (current node, neighbors, buffer, priority, destination). Click "Get Routing Decision". The agent returns an action (forward/store/drop), next hop, confidence score, and reasoning. History tracks all decisions. RL Routing
Orbital /orbital Drag the true anomaly slider (0°–360°) to see how Earth–Mars distance changes. The timeline bar chart shows the full 780-day synodic period. Stats update in real time. Orbital Mechanics
QKD Security /security Choose BB84 or E91, set qubit count and channel error. Toggle "Simulate Eavesdropper" to inject Eve. Click "Run Protocol". Results show QBER, security verdict, sifted key, and Alice's key bits. Below that, the BB84 Journey animates the whole protocol in-browser — Alice → channel (± Eve) → Bob → sifting → QBER → error correction → privacy amplification → key. BB84 Step by Step
QKD Science
Simulations /simulations Enter a name, pick a scenario, optionally set a seed. Click "Create Run". All runs are stored in the DB and listed below with status, seed, and timestamp. Simulation
Command Reference /cmd Browse the command catalog in the left sidebar (shell scripts + Python modules). Select a command to see what it does and the expected output, then click Copy and run it in your own terminal. Read-only — nothing runs in the browser. Command Reference
Every page has an info bubble at the top (click "Learn more →" to jump to this showcase) and a Resources card at the bottom with curated RFCs, papers, courses, and tools. The sidebar also has direct links to the Showcase, Resources, Glossary, and Quiz.
🔗 Showcase Integration
How the Integration Works
Frontend FeatureWhere to Find ItWhat It Does
Info BubblesTop of every module pageQuick explanation + "Learn more →" link to matching showcase section
Resources CardsBottom of every module pageCurated RFCs, papers, courses, tools + link to full Resources page
Welcome Page/"Learn the science →" on each module card links to showcase
Dashboard Grid/dashboard9 cards linking to Welcome, What is DTN, How It Works, etc.
Sidebar ExternalLeft sidebar, bottomAlways-visible: Showcase, Resources, Glossary, Quiz
FooterBottom of every pageGitHub, LinkedIn, Portfolio, Resume, Repo, Showcase
📸 Interface Previews
Dashboard — The hub page. Shows API health, database status, Earth–Mars stats, platform modules table, and a showcase grid linking to learning materials.
localhost:3000/dashboard
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
⚷ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
📖 Glossary
✓ Quiz
Mission Control
AETHERIX Interplanetary DTN Platform v3.0.0
API Status
ok
Database
connected
Earth-Mars Range
54.6-401M km
Network Tiers
5
Platform Modules
ModulePathStatus
Link Budget/link-budgetActive
RL Routing/routingActive
Orbital/orbitalActive
QKD Security/securityActive
Bundle Protocol/routingDemo
Quick Actions

Navigate to each module using the sidebar...

Optical Link
1550 nm
QKD Protocol
BB84
Link Budget Calculator — Select a scenario or enter a custom distance, then click "Calculate Optical Link". Results appear on the right: EIRP, link margin (green = positive = link works), data rate, free-space loss, received power. All runs are saved to the database and shown in the history table below.
localhost:3000/link-budget
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
ʆ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
Link Budget Calculator
Optical and RF link budget analysis for Earth-Mars communications
Optical Link Parameters
Scenario
Distance (km)
Calculate Optical Link
Results
Distance
225.0M km
Link Margin
3.45 dB
EIRP
107.60 dBm
Data Rate
50.0 Mbps
Free Space Loss
-295.22 dB
Received Power
-72.14 dBm
RL Routing Agent — Edit the network state fields (current node, neighbors, buffer, bundle priority, destination), then click "Get Routing Decision". The agent returns an action (FORWARD / STORE / DROP), the chosen next hop, a confidence score, and a natural-language reasoning string.
localhost:3000/routing
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
ʆ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
RL Routing Agent
Reinforcement learning-based routing decisions for DTN bundles
Network State
Current Node
earth_dsn_goldstone
Buffer Occupancy
0.4
Bundle Priority
2
Get Routing Decision
Routing Decision
Action
FORWARD
Next Hop
earth_orbit_geo_1
Confidence
92.0%
Reasoning
Best link quality (0.92), sufficient buffer
Orbital Mechanics — The four stat cards show current distance, light-time delay, and min/max range. Drag the true anomaly slider to explore how distance changes with orbital position. The bar chart shows the full 780-day synodic period (green = close, yellow = moderate, red = far/conjunction).
localhost:3000/orbital
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
ʆ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
Orbital Mechanics
Earth-Mars distance calculations, contact windows, and light-time delay
Current Distance
225.3M km
Light-Time Delay
12.5 min
Min Distance
54.6M km
Max Distance
401.0M km
Synodic Period Timeline
Day 0 = Perihelion ~390 days = Aphelion Period = 780 days
QKD Security — Choose BB84 or E91, set the number of qubits and channel error rate. Toggle "Simulate Eavesdropper" to inject an eavesdropper (inflates error to 15%). Click "Run Protocol". If QBER < 11%, the key is secure. Results include the sifted key, efficiency, and Alice's key bits.
localhost:3000/security
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
ʆ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
QKD Security
Quantum Key Distribution — BB84 and E91 protocol simulation
Protocol Parameters
Protocol
BB84 (Bennett-Brassard 1984)
Number of Qubits
1000
Channel Error Rate
0.0
Run BB84 Protocol
QKD Result
QBER
4.20%
Threshold: 11%
Secure
YES
Sifted Key Length
487
Efficiency
48.7%
Alice's Key (first 32 bits)
[1, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 1, 1, 0, ...]
Command Reference — Browse the command catalog in the left sidebar (grouped by Shell Scripts, Python Modules, etc.). Select a command to see what it does and the output to expect, then click Copy and run it in your own terminal from the project root. It's a safe read-only reference — nothing is executed by the browser or the server.
localhost:3000/cmd
AETHERIX
🏠 Welcome
▦ Dashboard
⟡ Link Budget
⟳ RL Routing
◎ Orbital
ʆ QKD Security
▶ Simulations
⌘ CMD
External
🌐 Showcase
📚 Resources
Shell Scripts
Initialize Environment
Run Test Suite
Code Quality Check
Clean Artifacts
Python Modules
Optical Link Budget
RL Routing Agent
QKD Protocol
Simulation Engine
Command Terminal
Run scripts, tests, modules, and utilities from the web interface
Run Test Suite Run all 768 tests
Run Clear
$ ./scripts/run_tests.sh ====== 768 tests ran ====== test_rf_link_budget.py ......................... 51 passed test_ltp.py .................................... 45 passed test_simulator.py .............................. 34 passed test_api.py .................................... 32 passed test_orbital.py ................................ 30 passed ... 480 passed in 114.68s ✓ Process finished with exit code 0
PM2 Process Management
PM2 manages both the backend and frontend processes. Use ./scripts/dev.sh to control them:
CommandWhat It Does
./scripts/dev.sh startInstall deps + start backend & frontend
./scripts/dev.sh stopStop all PM2 processes
./scripts/dev.sh restartRestart all processes
./scripts/dev.sh statusShow PM2 process status
./scripts/dev.sh logs [backend|frontend]Tail logs
./scripts/dev.sh buildBuild frontend for production
The CLI runs AETHERIX Python modules directly from your terminal. No Node.js or Docker required — just Python 3.9+ and a virtual environment. Each module prints a self-contained demo with real calculations.
Step 1: Set Up the Environment
git clone https://github.com/matx104/AETHERIX.git
cd AETHERIX
./scripts/init.sh          # creates venv + installs deps
source venv/bin/activate   # activate the virtual environment
./scripts/run_tests.sh     # verify: 768 tests pass
What init.sh does: Creates venv/, installs requirements.txt (numpy, matplotlib, etc.), and verifies the installation. Add --dev to include linting tools.
Step 2: Run Utility Scripts
Shell scripts handle environment management, testing, linting, and cleanup. Always activate the venv first with source venv/bin/activate.
ScriptWhat It Does
./scripts/init.shSet up virtual environment and install dependencies
./scripts/init.sh --devInclude development tools (linting, formatting)
./scripts/run_tests.shRun the full test suite (768 tests)
./scripts/run_tests.sh -vVerbose test output
./scripts/run_demos.shInteractive demo menu (6 Python demos)
./scripts/lint.shCode quality checks (ruff)
./scripts/lint.sh --fixAuto-fix code style issues
./scripts/clean.shClean artifacts and caches
Step 3: Run Individual Modules
Each module prints a self-contained demo with real calculations — link budgets, routing decisions, QKD sessions, orbital distances, and more. Just run with python.
CommandWhat It Outputs
python src/infrastructure/link_budget.pyOptical link budget for minimum/average/maximum scenarios
python src/infrastructure/rf_link_budget.pyRF link budget across Ka/X/S/UHF bands
python src/routing/rl_agent.pyRL agent training demo with Q-table convergence
python src/routing/bundle.pyBPv7 bundle creation, priority, custody demo
python src/routing/prioritization.pyData prioritization scheduler across priority classes
python src/routing/forwarding_engine.pyStore-and-forward with BundleQueue demo
python src/routing/training.pyRL training loop with convergence detection
python src/security/qkd.pyBB84 & E91 key exchange with QBER analysis
python src/security/repeater_chain.pyMulti-hop quantum repeater chain with purification
python src/security/privacy_amplification.pyCASCADE reconciliation & universal hashing
python src/orbital/contact_windows.pyContact window prediction & distance timeline
python src/orbital/doppler.pyClassical & relativistic Doppler shift
python src/orbital/topology.py5-tier 241-node network topology with BFS routing
python src/computing/radiation.pyRadiation hardening with error correction codes
python src/simulation/simulator.pyFull end-to-end simulation engine
python src/simulation/policy_engine.pyPolicy-based routing with 5 default policies
Generate Presentation
Generate PPTX or PDF presentations from the project data:
cd presentation
pip install python-pptx reportlab   # if not installed
python generate_pptx.py             # → AETHERIX_Presentation.pptx
python generate_pdf.py              # → AETHERIX_Presentation.pdf
One-click full platform: ./scripts/platform.sh demo builds and starts everything — app + PostgreSQL + this showcase + Prometheus/Grafana/node-exporter/Alertmanager + Jenkins with the pipeline pre-loaded — then waits for health, seeds sample data via the API, runs verification gates, and streams live scenario data for 60 s. Individual steps: up | wait | seed | verify | live | status | logs | down | nuke.
URLService
http://localhost:3000Frontend (React app)
http://localhost:8000Backend API + /docs + /metrics
http://localhost:8080Showcase site (this page)
http://localhost:3001Grafana (admin/admin — dashboard “AETHERIX Platform Overview”)
http://localhost:9090Prometheus
http://localhost:9093Alertmanager
http://localhost:8090Jenkins CI (job “AETHERIX”)
http://localhost:7700Meilisearch — full-text search over all lessons, curriculum, exam prep and docs (indexed by scripts/search_index.py)
http://localhost:3002Wiki.js — the design-documentation home: HLD, Data Pipeline, LLDs (autonomy/security/routing), Deployment, Observability (Mermaid diagrams), plus Q/A crib sheet, recovery matrix, glossary. Auto-seeded by scripts/wiki_seed.py (~30s setup wizard on first visit)
Or start the core stack only with Docker Compose (PostgreSQL + FastAPI backend + React frontend via nginx) in isolated containers with health checks and automatic restarts. Ideal for production or isolated environments.
Step 1: Start All Containers
./scripts/dev.sh docker-up    # build & start all containers
This builds three containers: postgres:16-alpine, aetherix-backend, and aetherix-frontend (nginx serving the built React app). The backend connects to PostgreSQL instead of SQLite.
URLService
http://localhost:3000Frontend (nginx, proxies /api to backend)
http://localhost:8000Backend API (FastAPI)
localhost:5432PostgreSQL database (user: aetherix)
Step 2: Verify Containers Are Running
Use ./scripts/dev.sh docker-ps or docker compose ps to check. All three should show "Up (healthy)".
NAME IMAGE STATUS PORTS aetherix-postgres postgres:16 Up (healthy) 0.0.0.0:5432->5432/tcp aetherix-backend aetherix-backend Up (healthy) 0.0.0.0:8000->8000/tcp aetherix-frontend aetherix-frontend Up (healthy) 0.0.0.0:3000->80/tcp
Step 3: Use the Web Interface
Once containers are healthy, open http://localhost:3000 and use the web interface exactly as described in the Web Interface tab. All pages work identically — the only difference is PostgreSQL instead of SQLite under the hood.
Container Architecture
🐳
PostgreSQL 16
Port 5432
Persistent volume
5 tables
Health checked
⚙
FastAPI Backend
Port 8000
7 API routers
Swagger docs
SQLAlchemy ORM
🌐
React Frontend
Port 3000
8 pages
nginx proxy
Vite + TypeScript
Step 4: Manage & Inspect
CommandWhat It Does
./scripts/dev.sh docker-upBuild & start all containers
./scripts/dev.sh docker-downStop & remove containers
./scripts/dev.sh docker-logs [service]Tail container logs (backend, frontend, postgres)
./scripts/dev.sh docker-psShow container status
Inspecting the Database
To query PostgreSQL directly inside the container:
$ docker exec -it aetherix-postgres psql -U aetherix -d aetherix aetherix=# \dt List of relations Schema | Name | Type | Owner --------+-------------------------+-------+--------- public | simulation_runs | table | aetherix public | link_budget_results | table | aetherix public | routing_decision_logs | table | aetherix public | qkd_sessions | table | aetherix public | contact_window_records | table | aetherix (5 rows)
Startup Logs

Backend startup:

aetherix-backend | INFO: Uvicorn running on http://0.0.0.0:8000 aetherix-backend | INFO: Started reloader process aetherix-backend | INFO: Started server process aetherix-backend | INFO: Application startup complete. aetherix-backend | Connected to PostgreSQL at postgres:5432 aetherix-backend | Tables created successfully.

PostgreSQL init:

aetherix-postgres | initdb: database system initialized aetherix-postgres | LOG: starting PostgreSQL 16 aetherix-postgres | LOG: database system is ready to accept connections aetherix-postgres | database "aetherix" created aetherix-postgres | user "aetherix" created
🔌 Troubleshooting
ImportError

Run ./scripts/init.sh to install dependencies. Activate the virtual environment first: source venv/bin/activate

Tests failing

Ensure the virtual environment is activated and all dependencies are installed: source venv/bin/activate && pip install -r requirements.txt

Site not loading

The site must be served via HTTP, not opened as a file. Use python -m http.server 8080 inside the docs/ directory.

PPTX generation fails

Install the required package: pip install python-pptx. For PDF: pip install reportlab.

🎯 Learning Objectives (a–h) × Surfaces
Objective Code Module Slide(s) Web Section Questions
a. DTN protocols (BPv7, LTP, convergence layers) src/routing/bundle.py — BPv7 Bundle, EndpointID, BundlePriority
src/routing/ltp.py — LTP segmentation, retransmission
src/routing/tcpcl.py — TCP Convergence Layer (RFC 7242)
src/routing/udp_cl.py — UDP Convergence Layer, optical ISL
src/routing/forwarding_engine.py — store-and-forward, BundleQueue
src/routing/contact_graph.py — contact graph BFS pathfinding
src/routing/node.py — DTN node model, buffer management
8: BPv7 Deep Dive
9: DTN Store-and-Forward
What is DTN?
How It Works
BPv7 Interactive Demo
DTN Engine Demo
Deep Space Standards
Glossary
dtn_protocols ✅
b. Quantum communications/crypto (BB84, E91, QKD, repeaters) src/security/qkd.py — BB84Protocol (QBER), E91Protocol, QuantumRepeater
src/security/repeater_chain.py — multi-hop repeater chain, purification
src/security/privacy_amplification.py — CASCADE, universal hashing
16: Quantum Security Space Security
Science Behind QKD
QKD Interactive Demo
quantum_comms ✅
c. Space infrastructure (DSN, 5-tier topology, optical/RF) src/orbital/topology.py — 241-node 5-tier network
src/infrastructure/link_budget.py — OpticalLinkBudget
src/infrastructure/rf_link_budget.py — Ka/X/S/UHF bands
6: System Architecture
7: Architecture Diagram
10: Network Topology
11: 5-Tier Diagram
12: Network Diagram
13: Optical Comms
5-Tier Topology Explorer
Optical Communications
Link Budget Calculator
RF Band Comparison
space_infrastructure ✅
d. Orbital mechanics/link prediction (contact windows, Doppler) src/orbital/contact_windows.py — distance, light-time, contact windows
src/orbital/bodies.py — celestial body database
src/orbital/doppler.py — classical/relativistic Doppler
14: Earth-Mars Journey
17: Orbital Mechanics
Contact Window Predictor
Distance Timeline
orbital_mechanics ✅
e. Radiation-hardened computing (SEU, TMR, ECC, FDIR) src/computing/radiation.py — SEU, TMR, ECC, FDIR, scrubbing 18: Radiation Hardening Radiation Effects
Mitigation Demo
radiation_hardening ✅
f. Mission-critical data prioritization (QoS, preemption) src/routing/prioritization.py — QoS classes, compression, preemption 19: Data Prioritization QoS Learn Page
Priority Queue Demo
data_prioritization ✅
g. Industry application (standards, real-world context) CCSDS 734.2-B-1, RFC 4838, RFC 9171, RFC 5326, CCSDS 734.3-B-1, CCSDS 141.0-B-1, CCSDS 401.0-B-30 citations across docstrings and demos 5: The Answer
13: Optical Comms
20: End-to-End Mission
25: Roadmap
Standards Catalogue
Why It Matters
Mission Scenario
standards ✅
h. Tools (Python, simulation, web showcase, testing) src/simulation/simulator.py — full simulation engine
src/simulation/policy_engine.py — policy-based routing
src/routing/training.py — RL training, convergence detection
src/routing/multi_agent.py — federated learning
src/routing/rl_agent.py — Q-learning agent
15: RL Routing
23: Performance
24: Implementation
Dashboard
Simulation Runner
RL Routing Demo
Usage Guide
Study Mode
Technology Stack
aetherix_specific ✅
📄 Presentation Sections × Coverage
Section Slides Code Demonstrated Web Demo
1. Network Architecture 3: What is AETHERIX
4: The Distance
5: The Answer
6: System Architecture
7: Architecture Diagram
8: BPv7 Deep Dive
9: DTN Store-and-Forward
10: Network Topology
11: 5-Tier Network Diagram
12: Network Diagram
15: RL Routing
src/routing/bundle.py, src/routing/ltp.py, src/routing/tcpcl.py, src/routing/udp_cl.py, src/routing/forwarding_engine.py, src/routing/contact_graph.py, src/routing/node.py, src/routing/rl_agent.py, src/routing/training.py, src/routing/multi_agent.py, src/orbital/topology.py, src/simulation/simulator.py, src/simulation/policy_engine.py What is DTN
How It Works
The Network
Bundle Demo
DTN Engine
RL Routing
Dashboard
Simulation
2. Quantum Comms 16: Quantum Security src/security/qkd.py, src/security/repeater_chain.py, src/security/privacy_amplification.py Space Security
QKD Science
QKD Demo
3. Infrastructure 13: Optical Comms
14: Earth-Mars Journey
17: Orbital Mechanics
18: Radiation Hardening
19: Data Prioritization
src/infrastructure/link_budget.py, src/infrastructure/rf_link_budget.py, src/orbital/contact_windows.py, src/orbital/bodies.py, src/orbital/doppler.py, src/computing/radiation.py, src/routing/prioritization.py Optical Comms
RF Budget
Link Budget
Orbital
Journey to Mars
Radiation Demo
Priority Demo
4. Scenario Analysis 20: End-to-End Mission
21: Data Flow Diagram
22: Data Flow Visual
23: Performance
24: Implementation
25: Roadmap
src/simulation/simulator.py, src/simulation/policy_engine.py, src/routing/training.py Mission
Dashboard
Simulation
Why It Matters
Standards
🎥 Interview Areas × Coverage
Area Code Learn Page Demo Questions
1. DTN Protocols & Bundle Protocol bundle.py, ltp.py, tcpcl.py, udp_cl.py, forwarding_engine.py, contact_graph.py, node.py What is DTN, How It Works, Bundle, Standards bundle, dtn-engine, simulation dtn_protocols ✅
2. Quantum Key Distribution qkd.py, repeater_chain.py, privacy_amplification.py Space Security, QKD Science qkd quantum_comms ✅
3. Space Infrastructure & Topology topology.py, link_budget.py, rf_link_budget.py The Network, Optical Comms link-budget, rf-budget space_infrastructure ✅
4. Orbital Mechanics & Link Budget contact_windows.py, bodies.py, doppler.py Orbital, Journey to Mars orbital orbital_mechanics ✅
5. Radiation Hardening & Fault Tolerance radiation.py Radiation radiation-demo radiation_hardening ✅
6. Data Prioritization & QoS prioritization.py Prioritization priority-demo data_prioritization ✅
7. RL Routing & AI rl_agent.py, training.py, multi_agent.py, policy_engine.py Reinforcement Learning routing aetherix_specific ✅
✅ Success Checklist
✅ 1. BPv7, LTP & Convergence Layers
7 code modules, 2 slides, 5 web pages, dtn_protocols questions, 12 test files
✅ 2. Quantum Key Distribution
3 code modules (BB84, E91, repeater, privacy amplification), 1 slide, 3 web pages
✅ 3. 5-Tier Space Network Architecture
3 code modules (topology, optical, RF), 5 slides, 4 web pages
✅ 4. Orbital Distances & Contact Windows
3 code modules (contact_windows, bodies, doppler), 2 slides, 2 web pages
✅ 5. Radiation Effects & Mitigation
radiation.py (SEU, TMR, ECC, FDIR, scrubbing), 1 slide, 2 web pages
✅ 6. Data Prioritization & QoS
prioritization.py (QoS classes, compression, preemption), 1 slide, 2 web pages
✅ 7. Industry Standards (CCSDS, RFC)
Standards cited across all module docstrings, #deep-space-standards page, standards questions
✅ 8. Python, Simulation & Testing
44 modules, 768 tests across 46 files, simulation engine, #usage and #built-by pages
✅ 9. Presentation: All 4 Graded Sections
34 slides mapped to Architecture, Quantum, Infrastructure, Scenario
✅ 10. Interactive Web Showcase
37 tabs: 17 learn pages, 15 interactive demos, glossary, quiz with 3,170 questions
✅ 11. Question Bank: 7 Interview Areas
8 topics mapped to all 7 interview areas
✅ 12. Code Tested & Runnable
768 tests, every module has __main__ block, run_tests.sh and run_demos.sh validated
✅ 13. Technical Depth (40%)
44 modules, 9,800+ lines in src/ implementing BPv7, LTP, BB84, E91, Q-learning with mathematical foundations
✅ 14. Problem-Solving (20%)
RL routing outperforms static CGR, hybrid optical/RF, multi-hop QKD repeaters, configurable policy engine
MAT
Muhammad Abdullah Tariq
Pakistan's Youngest CISSP at 22
Hafiz-ul-Quran
Lead Multi Cloud DevOps Engineer
Cloud Security Architect · DevSecOps · SOCIRIS Founder & CEO
7+ years architecting enterprise-scale infrastructure across AWS, Azure, GCP, and Oracle Cloud. Currently orchestrating 5 multi-cloud production environments supporting 50+ applications at 99.9% uptime. AETHERIX was built as an EduQual Level 6 research project exploring how delay-tolerant networking, quantum key distribution, and reinforcement learning can enable reliable Earth-Mars communication.
Cloud: AWS · Azure · GCP · Oracle · VMware
Orchestration: Kubernetes (EKS/AKS/GKE) · OpenShift · Docker · ArgoCD
Security: CISSP · ISO 27001 Lead Auditor · Zero Trust · DAST/SAST
Languages: Python · Bash · JavaScript · TypeScript
50+
Apps at 99.9% Uptime
75%
Cloud Cost Reduction
100+
Certifications (15 Issuers)
15+
Active Platforms
🏆 Key Achievements
  • ✅ Passed EduQual Level 6 viva — AETHERIX interplanetary DTN defense (80.5% overall, presentation 92%)
  • ✅ 45% security vulnerability reduction across 50+ microservices
  • ✅ 50% faster deployments via GitOps + Kubernetes automation
  • ✅ 80% manual task elimination through automation
  • ✅ 165% team efficiency gain via structured mentorship
  • ✅ 200+ cloud resources monitored via custom NOC/SOC stack
📚 Education
  • 🎓 BS Cyber Security — ILMA University (CGPA 3.75)
  • 🎓 Diploma AI Operations (RQF Level 6) — EduQual UK · Pass 80.5% (Sep 2026)
  • 🎓 Higher Ed. Diploma AI-Ops — Al Nafi (A+)
  • 🚀 Nights & Weekends S5 — buildspace, SF
  • 📖 Hifz-ul-Quran — Markaz-ul-Usman, Kuwait (1st)
🔐 Anchor Certifications
CISSP ISO 27001 Lead Auditor CCSP AWS Advanced Networking Microsoft Cybersecurity Google Cybersecurity GenAI Cybersecurity & Privacy ISO 27001 Master
💼 Featured Projects
  • SOCIRIS — AI-powered IDS/IPS (Founder & CEO)
  • WAZIR Stack — Autonomous AI agent system on Oracle Cloud
  • OMNI-GRC — AI-powered GRC across 8 frameworks
  • JourneyOS — Modular AI OS for life journeys
  • ARISE — Solo-levelling personal growth system
🏅 Awards & Recognition
  • 🏆 Youngest CISSP Graduate — Al Nafi (Feb 2025)
  • 🏆 Future Leader Award — Server4Sale & ITCN Asia (Aug 2024)
  • 🏆 buildspace N&W S5 Alumni — SF Bay Area (Aug 2024)
  • 🏆 Microsoft Learn Level 11 — 173,850 XP
  • 🏆 12+ additional awards across competitions
🚀
About This Project
AETHERIX is a research-grade proof of concept demonstrating interplanetary delay-tolerant networking. Built with 33 Python modules, 643 unit tests, and 15 interactive browser demos. Built on RFC 9171 (BPv7), RFC 4838 (DTN Architecture), CCSDS 734.2-B-1 (CCSDS Bundle Protocol), and RFC 5326 (LTP). Part of an EduQual Level 6 Diploma in AI Operations.
1 / 54
00:00
Keyboard Shortcuts
← / →Navigate slides SpaceNext slide Home / EndFirst / Last slide FToggle fullscreen TToggle timer SSpeaker notes PFull script EscExit presentation ?Show shortcuts

References & Standards

Every claim in this project traces to a cited standard, NASA mission dataset, peer-reviewed protocol, or verifiable source module.

Industry & Scientific [1]–[20]

[1]NASA Mars Relay Network / MRO Ka-band (0.5–6 Mbps)
[2]CCSDS 734.2-B-1 — CCSDS Bundle Protocol Specification (Sept 2015)
[3]JPL Horizons ephemeris (Earth–Mars geometry)
[4]NASA DSOC / Psyche (2023 optical demo)
[5]CCSDS 141.0-B-1 — Optical Communications Physical Layer (Aug 2019)
[5a]CCSDS 142.0-B-1 — Optical Communications Coding & Synchronization (Aug 2019)
[6]CCSDS 131.0-B-5 — TM Synchronization & Channel Coding (Sept 2023)
[7]CCSDS 121.0-B-3 — Lossless Data Compression (Aug 2020)
[8]CCSDS 122.0-B-2 — Image Data Compression (Sept 2017)
[9]IETF RFC 9171 — Bundle Protocol v7
[10]IETF RFC 5326 — Licklider Transmission Protocol
[11]IETF RFC 7242 — TCP Convergence Layer
[12]IETF RFC 4838 — DTN Architecture
[13]Bennett & Brassard, 1984 — BB84 QKD
[14]Ekert, 1991 — E91 Entanglement QKD
[15]Shor & Preskill, 2000 — QBER < 11% proof
[16]NIST FIPS 203 — ML-KEM (post-quantum)
[17]NIST FIPS 204 — ML-DSA (post-quantum sig)
[18]BAE Systems RAD750 — rad-hard CPU
[19]ESA / Cobham LEON3FT — fault-tolerant CPU
[20]IETF RFC 4838 §3.1 — DTN challenges

Project Source [A1]–[A8]

[A1]src/routing/rl_agent.py — Q-learning agent
[A2]src/orbital/topology.py — 241-node 5-tier network
[A3]run_simulation.py — 7-module simulation suite
[A4]src/infrastructure/link_budget.py — optical 2–200 Mbps
[A5]src/security/qkd.py — BB84, E91, repeater
[A6]src/computing/radiation.py — SEU/TID, TMR, ECC
[A7]src/routing/prioritization.py — QoS scheduler
[A8]run_simulation.py Module 4 — failure/recovery
Reproducibility: Every simulation result is seed-fixed and reproducible:
python run_simulation.py
Full 70+ academic reference list in references/REFERENCES.md
Source: github.com/matx104/AETHERIX
🏆 Assessment Result ✓ Passed EduQual Level 6 · Sep 2026
80.5%
Overall · 40.25/50
23/25
Presentation (92%)
17.25/25
Interview (69%)

Al Nafi EduQual Level 6 oral examination — 3 Sep 2026, 84-minute session (presentation, live demo, examiner Q&A). Result published 8 Sep 2026. Full session record on NAFA-BOX → · ▶ Watch the recorded session & result details

80.5%
Overall · 40.25 / 50
23/25
Presentation (92%)
17.25/25
Interview / Q&A (69%)
Verified Record
OutcomePASSED
Overall40.25 / 50 (80.5%)
Presentation component23 / 25 (92%)
Interview / Q&A component17.25 / 25 (69%)
SessionOral examination · 1h 24m (presentation, live demo, examiner Q&A)
Assessed3 September 2026
Result published8 September 2026

The companion study site (NAFA-BOX) rounds the overall result to 81%; the exact figure is 80.5% (40.25/50).

🎥 Recorded Session

The full 84-minute assessment session as examined — presentation, live demo, and examiner Q&A. Also available on NAFA-BOX or YouTube.

🔗 Featured on LinkedIn
Project write-up
View full post →
📖 Verified session record → 🎥 Watch on NAFA-BOX ▶ YouTube ← Back to Showcase