Source-linked AI summary
Bandwidth, Latency, and 400 Million Kilometers: The Case for Mars-Local Compute
Maleeha Masood, Indranil Gupta, Deepak Vasisht
TL;DR
Mars exploration is constrained by limited bandwidth and delayed, intermittent Earth communication. The paper proposes shared computing nodes in Mars orbit, with local processing and two tiers of capacity. Its analysis finds the architecture incrementally deployable and apparently feasible within large Mars spacecraft’s mass, power, and thermal envelope.
Problem
Mars exploration data exceed what the Earth link can return, while communication delays and blockages slow Earth-based responses.
Source: §1 · p. 1Method
The paper proposes two tiers of Mars-orbit computing nodes: low-orbit nodes process data-intensive, latency-sensitive workloads, while areostationary nodes maintain shared state and coordinate follow-up actions.
Source: §1 · p. 1, §3.5 · p. 5Results
The proposed system is useful from its first node, scales incrementally, and appears feasible within the mass, power, and thermal envelope of large Mars spacecraft.
Source: §6 · p. 6Takeaways & Limitations
Mars-local compute handles work whose value depends on acting before the next Earth planning cycle, while Earth retains human-judgment, global-planning, and archival tasks.
Source: §3.5 · p. 5The work is a first-order architecture and feasibility analysis, not a complete blueprint.
Source: §1 · p. 2
Abstract
from arXiv · showhide
There have been recent proposals for human settlements on Mars in 2030s. Any human activity on Mars must be preceded by extensive robotic exploration. However, Mars exploration is bottlenecked by the low bandwidth, intermittent Mars-Earth link. For example, HiRISE, a high-resolution camera onboard the Martian orbiter MRO imaged less than 3% of Mars over eleven years, even though MRO's low resolution Context Camera had mapped more than 99% of Mars in that time. We present a systems case for shared compute for Mars exploration. Such Mars-local compute, paired with advances in computer vision and AI, can enable large volumes of data to be collected and processed on Mars while sending periodic updates, insights, and selective datasets to Earth. To overcome the lack of surface infrastructure on Mars, we propose a two-tier in-orbit deployment of computational satellites that provides consistent coverage and bandwidth. Our analysis shows that the proposed deployment can start small: one areostationary node makes compute reachable from all active Mars missions, two additional areostationary nodes can extend this coverage to roughly 90% of the planet, while low-Mars-orbit nodes add high-rate surface links and compute capacity where demand grows.
1 INTRODUCTION
Mars exploration is constrained by the amount of data that can be returned to Earth and by delayed, intermittent communication. The paper proposes shared computing nodes in Mars orbit to process data locally and support missions across the planet.
1 INTRODUCTION
- HiRISE imaged only about 3% of Mars, while MRO’s lower-resolution Context Camera mapped more than 99% since 2006.HiRISE can acquire 28 gigabits in six seconds, but even a 6 Mbps downlink would take more than an hour to transmit one acquisition.Source: §1 · p. 1
- Earth–Mars delays of 3–22 minutes, solar blockages lasting up to two weeks, and daily planning cycles can defer decisions until the following sol.The delay depends on the planets’ relative positions, and the Sun can block radio communication.Source: §1 · p. 1
- A two-tier Mars-orbit infrastructure pairs one to three areostationary nodes with low-orbit nodes for persistent shared access and added high-rate surface links.The proposed nodes provide shared state and coordination across 90% of the planet; low-orbit capacity can be added as demand grows.Source: §1 · p. 1
- Mars-local computing could let assets share persistent services and support both robotic and human explorers.The paper describes this work as a first-order architecture and feasibility analysis, not a complete blueprint.Source: §1 · p. 2
2 PRIMER AND RELATED WORK
Mars missions rely on intermittent relays and Earth-based planning, while data volumes, communication delays, and deployment constraints challenge current operations. The paper contrasts these conditions with terrestrial LEO systems and proposes separating persistent reachability from high-rate surface-link capacity.
2.1 The Current Martian Fleet
- Mars Relay Network access is intermittent—about a dozen contacts per week—and provides neither continuous visibility nor programmable compute.The network is a scheduled store-and-forward system built from science orbiters rather than dedicated communication satellites.Source: §2.1 · p. 2
2.2 Existing Challenges
- Mars instruments generate more data than the Earth link can return, forcing missions to prioritize observations while useful raw data may remain buffered, compressed, or discarded.This mismatch is expected to grow as Mars hosts more capable instruments, vehicles, and sensors.Source: §2.2 · p. 2
- Earth–Mars propagation delays of roughly 3–22 minutes and later command cycles limit how quickly observations can influence rover actions.The source also notes that rover travel rates reflect difficult terrain and careful science operations.Source: §2.2 · p. 2
- Infrastructure is costly and slow to deploy: launch opportunities recur every 26 months, so new systems must provide value from their first deployment and expand over time.Curiosity’s estimated life-cycle cost was about $2.5 billion; Perseverance cost roughly $2.4 billion to build and launch, plus $300 million for landing and prime-mission operations.Source: §2.2 · p. 3
2.3 Related Work
- Unlike terrestrial LEO designs that exploit predictable mobility, Mars systems face sparse infrastructure, delayed intermittent Earth contact, and deployment opportunities years apart.The proposed design separates persistent reachability through a small areostationary tier from surface-link capacity added through low-orbit nodes.Source: §2.3 · p. 3
3 A TWO-TIER COMPUTE LAYER FOR MARS
The paper divides Mars-orbit compute between persistent shared services and low-orbit high-rate links, allowing compute to be reached broadly while capacity grows with demand. The analysis quantifies their distinct coverage and link roles and assigns each tier different computing tasks.
3 A TWO-TIER COMPUTE LAYER FOR MARS
- Orbital compute can serve widely separated missions beyond any single rover’s lifetime, avoiding surface compute’s mission-specific power, mass, thermal, and lifetime constraints.The paper describes the two tiers as separating persistent shared services from short, high-rate contacts and additional compute.Source: §3 · p. 3
3.1 Two Orbital Regimes
- At a 10° minimum elevation, areostationary nodes reach about 33% of the surface versus 2.5% for a 400 km node; the low node is about 43× closer at closest approach, yielding roughly 1,800× greater received power.The comparison assumes identical free-space link conditions.Source: §3.1 · p. 3
3.2 Three High Nodes Reach Most of Mars
- One areostationary node reaches both active rovers and about 33% of Mars; three spaced 120° apart reach roughly 90%, with polar gaps and diminishing coverage returns beyond three.Low-orbit nodes see about 2.5% of Mars at a time.Source: §3.2 · pp. 3–4
3.3 Low Orbit Buys Link Quality
- Each low-orbit node adds about 0.85 Gb/sol through largely independent contacts, making offload increase almost linearly; the single-node estimate is an ideal-contact-utilization upper bound.The model estimates per-rover surface-to-orbit offload, unlike reported end-to-end data returned to Earth.Source: §3.3 · p. 4
3.4 Why Both Tiers Are Needed
- Areostationary-only supports persistent shared state but not bulk transfer; low-orbit-only adds ingress yet sees about 2.5% of Mars at a time, while two tiers combine persistence with demand-scaled capacity.Near-continuous low-orbit access would require a much larger constellation, such as the explored 81-node design.Source: §3.4 · pp. 4–5
3.5 What Runs Where?
- Low-orbit nodes filter, compress, summarize, detect events, and select data during brief contacts; areostationary nodes maintain shared maps and state, combine observations, and coordinate follow-up measurements.Together they can identify an unusual observation, compare it with prior measurements, update shared state, and decide whether to request more data or prioritize transmission.Source: §3.5 · p. 5
4 ARE MARTIAN COMPUTE NODES FEASIBLE?
The paper tests first-order feasibility rather than proposing a flight-ready spacecraft design. Its estimates cover power, thermal control, mass, and incremental deployment costs for Mars-orbit compute nodes.
Power and thermal control
- Low orbit requires approximately 106–110 m2 of solar array and a 6.6 kWh battery; areostationary orbit requires 68–71 m2 and 12.5 kWh.The estimates assume 100 W/m2 conservative array output, specified charge and discharge efficiencies, and battery reserves.Source: §4 · p. 5
- 21–26 m2 is the preliminary radiator estimate for rejecting a 6 kW waste-heat load at 300 K.The ideal radiator area is 15.4 m2 before allowances for heat transport, external loading, degradation, geometry, and reserve.Source: §4 · p. 5
Node Mass
- A node is estimated at 0.8–1.6 t operational dry mass, with 5.75 kW continuous load and orbit-dependent power-system requirements.The mass estimate includes a 20% reserve and depends on orbit.Source: §4 · p. 5
Incremental deployment
- A first areostationary node can serve existing rovers and validate systems, with later launch opportunities adding coverage or low-orbit ingest capacity.Earth–Mars launch opportunities are approximately 26 months apart.Source: §4 · p. 5
- At roughly $100 million per tonne for advertised future Starship surface delivery, a 0.8–1.6 t node implies about $80–$160 million in transport cost before other costs.This is not a quoted price for Mars-orbit insertion; capture, integration, and mission-specific costs are additional, so each deployment should be useful independently.Source: §4 · pp. 5–6
5 OPEN RESEARCH QUESTIONS FOR MARS-LOCAL COMPUTE
The open questions concern how local intelligence, placement, scheduling, approximation, persistent state, hardware, and failure handling should work under Mars communication and infrastructure constraints.
How does improving onboard AI change Mars systems?
- As local AI improves, planning, interpretation, and anomaly detection may run near Mars, with Earth consulted for low-confidence cases or when human judgment is required.This shifts bandwidth toward exceptions and requires confidence-aware execution, model evolution, and verifiable human override.Source: §5 · p. 6
Where should computation run?
- A Mars runtime must choose among surface assets, low-orbit satellites, areostationary nodes, and Earth, while accounting for state-transfer costs that can consume scarce capacity.The open question is when to move code, data, or intermediate results versus keeping computation local.Source: §5 · p. 6
How should communication and computation be scheduled together?
- Communication and computation should be scheduled together, including whether to spend compute and energy to compress an image or detect an important event before transmission.The scheduling decision spans bandwidth, energy, storage, and processor time.Source: §5 · p. 6
When is approximation safe?
- Mars approximation should rank, summarize, or progressively encode data rather than silently discard it, because unique observations may be impossible to reacquire.The open problem is defining contracts for confidence, provenance, retention, and authority to delete raw observations.Source: §5 · p. 6
What state should persist near Mars?
- Persistent Mars state may include maps, scientific products, model versions, and raw observations, requiring provenance and versioning despite long partitions and no continuously reachable source of truth.Transient nodes should hold only reconstructible state.Source: §5 · p. 6
Can Mars compute use modern accelerators?
- Mars operation requires radiation-hardened hardware, whose comparatively limited capabilities raise questions about compute–communication trade-offs.The passage contrasts Mars with low Earth orbit, where Earth’s magnetosphere shields hardware and commercial equipment can use software hardening.Source: §5 · p. 6
How should Mars compute fail?
- Because sparse Mars infrastructure may lose a region or service when one spacecraft fails, compute must degrade gracefully while preserving data and isolating faults.The proposed fallback includes relay-only operation and preserving raw data through missed contacts.Source: §5 · p. 6
6 CONCLUSION
The conclusion presents Mars-orbit compute as incrementally deployable shared infrastructure, with areostationary service and low-orbit capacity for greater ingress and near-surface processing. It could shorten scientific feedback loops and make transmitted bits more valuable.
6 CONCLUSION
- A small areostationary tier can provide persistent shared service across most of Mars, while low-orbit nodes add ingress and near-surface processing capacity where needed.The system is described as useful from its first node and incrementally scalable across launch windows.Source: §6 · p. 6
- The proposed system appears feasible within the mass, power, and thermal envelope of large Mars spacecraft.The conclusion frames Mars orbit as shared computing infrastructure, not only a relay layer.Source: §6 · p. 6
- The infrastructure could shorten scientific feedback loops, coordinate assets across missions, and make each transmitted bit more valuable.Those bits must still travel the 400-million-kilometer journey to Earth.Source: §6 · p. 7