Bandwidth, Latency, and 400 Million Kilometers: The Case for Mars-Local Compute Maleeha Masood
Indranil Gupta
Deepak Vasisht
University of Illinois Urbana-Champaign Urbana, IL, USA
University of Illinois Urbana-Champaign Urbana, IL, USA
University of Illinois Urbana-Champaign Urbana, IL, USA
arXiv:2609.31566v1 [cs.DC] 25 Sep 2026
ABSTRACT
selective: NASA reported in 2017 that HiRISE had imaged only about 3% of Mars, even though MRO’s lower-resolution Context Camera had mapped more than 99% of the planet since 2006 [10]. High communication latency also limits how quickly Earthbased operators can respond to changing conditions on Mars. Depending on the relative positions of Earth and Mars, the planets can be 400 million kilometers apart and one-way communication delays range from approximately 3 to 22 minutes. Communication can also be blocked for as long as 2 weeks when the Sun lies between Earth and Mars, and disrupts radio communication [7, 19]. More importantly, routine rover operations are organized around daily planning cycles: observations are transmitted to Earth for analysis, and a new activity plan is typically uploaded once per sol (i.e. one day on Mars). As a result, decisions that require Earth-based interpretation may not be executed until the following sol [1]. Mars therefore represents an extreme form of a familiar distributed-systems problem characterized by three features: (i) instruments generate data faster than the backhaul can carry it, (ii) connectivity is delayed and intermittent, and (iii) centralized decisions arrive too slowly to guide collection interactively. On Earth, such constraints are solved by pushing compute closer to the source of data collection either through placing more compute on edge devices or through nearby datacenters. Placing more compute on edge devices increases weight, size, and power requirements. Furthermore, surface datacenters cannot be shared across devices due to the lack of networking and communication infrastructure on Mars. We propose a two-tier computing infrastructure in Mars orbit. One to three areostationary1 nodes provide persistent access, shared state, and coordination across 90% of the planet. These areostationary nodes are paired with lowMars-orbit nodes to create high-rate surface links and additional compute where demand grows. Together, these tiers form a small, incrementally deployable computing infrastructure in Mars orbit. The proposed infrastructure could open up a whole host of exploration forms impossible today. For instance, missions could fuse observations across
There have been recent proposals for human settlements on Mars in 2030s [2, 32, 36]. 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
Human exploration of Mars is moving from long-term aspiration towards operational preparation. In July 2026, NASA began recruiting participants for a one-year Mars mission simulation [8, 30]. This aspiration builds on decades of advances in robotic reconnaissance. Orbiters have mapped candidate landing sites and monitored weather and dust activity, while rovers have characterized local terrain and surface conditions. This reconnaissance campaign is constrained less by what its instruments can observe than by how much of the resulting data can be returned to Earth. HiRISE, a camera aboard the Mars Reconnaissance Orbiter (MRO), can acquire as much as 28 gigabits in six seconds [5]. Yet, MRO returns data to Earth at rates of only a few megabits per second. Even at its maximum reported downlink rate of 6 Mbps, transmitting a single 28 gigabit acquisition would take more than an hour. High-resolution imaging is therefore necessarily
1 analogous to Earth’s geostationary satellites
1
Maleeha Masood, Indranil Gupta, and Deepak Vasisht Terrestrial LEO Earth control loop milliseconds Ground infrastructure dense gateways and cloud Earth–Link Outage brief or reroutable Solar irradiance Launch windows
1.36 kW/m2 frequent
Mars Orbit
the Mars Relay Network (MRN), which currently comprises Mars Odyssey, Mars Express, Mars Reconnaissance Orbiter (MRO), and the ExoMars Trace Gas Orbiter (TGO) [23]. Fig. 1 summarizes these missions and their communication with Earth. The MRN is a scheduled store-and-forward network built from science orbiters, not dedicated communication satellites. During brief UHF contacts, rovers upload buffered data to a passing orbiter, which later forwards it to Earth [12, 23]. Perseverance, for example, can transmit to a nearby orbiter at up to 2 Mbps, while its direct-to-Earth X-band link supports only hundreds of bits per second [20]. MRO then downlinks to Earth at roughly 0.5–4 Mbps, reaching 6 Mbps under favorable geometry [35]. Relay access remains intermittent— roughly a dozen contacts per week—and the MRN provides neither continuous visibility nor programmable compute [23]. NASA-operated relay data reach Earth through the Deep Space Network (DSN), whose antenna complexes in California, Spain, and Australia are shared across interplanetary missions [22, 23]. A typical science-data path is rover → MRN orbiter → DSN → mission operations center. The architecture is robust, but intermittent and scheduledriven.
3–22 min one way no surface backbone periodic and unavoidable 0.59 kW/m2 every 26 months
Table 1: Mars operates under different assumptions from terrestrial LEO.
3 – 22 min one way latency
Odyssey
100s of bps
Curiosity
Deep Space Network Mars Express
Mars Reconnaissance Orbiter
Perseverance
ExoMars Trace Gas Orbiter
Figure 1: Active Mars missions and their communication with Earth. Surface rovers can communicate directly with Earth at only hundreds of bits per second, or through relay orbiters at up to 2 Mbps that forward data to Earth at up to 6 Mbps.
2.2
Existing Challenges
Mars instruments generate more data than the Earth link can return. Surface assets can transmit to nearby relay orbiters at megabit-per-second rates, but the Mars–Earth backhaul is intermittent and constrained [23]. Consequently, missions must prioritize which observations to acquire and return, while potentially useful raw data remain buffered, compressed, or discarded. This mismatch will grow as Mars hosts more capable instruments, vehicles, and sensors. Future infrastructure must therefore increase not only communication capacity, but also the amount of scientific value extracted from each transmitted bit.
rovers and orbiters, maintain shared maps and models, and trigger follow-up measurements before waiting for the next Earth planning cycle. As Mars is predicted to host increasingly more sensors, vehicles, aircraft, and eventually human crews, these assets could share persistent computing services rather than operate as isolated missions. Finally, when humans arrive on Mars, this network can be re-purposed to serve both human and robotic explorers. This work is a starting point for computing at Mars, not a complete blueprint. We provide a first-order architecture, feasibility analysis, and estimates for the community to discuss, refine, or challenge. We hope this paper jump starts a broader conversation about building compute on Mars, the new forms of exploration it could enable, and the challenges that must be solved to make it practical.
Mars–Earth communication limits interactivity and discovery. Earth and Mars can be separated by 55-400 million kilometers, imposing one-way propagation delays of roughly 3–22 minutes [19]. The operational delay is often longer because of blockages from the Sun or the fact that observations must be returned to Earth, reviewed, and incorporated into a later command plan. Surface mobility reflects this slow control loop: Curiosity has traveled about 23 miles since 2012, while Perseverance took more than five years to complete its first 26.2 miles [21, 24]. These rates also reflect difficult terrain and careful science operations, but most new observations cannot influence rover actions until the next planning cycle.
2 PRIMER AND RELATED WORK 2.1 The Current Martian Fleet Mars currently hosts two active surface rovers: NASA’s Curiosity in Gale Crater and Perseverance in Jezero Crater [16, 23]. Their high-volume communications are supported by 2
Bandwidth, Latency, and 400 Million Kilometers: The Case for Mars-Local Compute
Mars infrastructure is expensive and difficult to deploy. Mars missions cost billions of dollars: Curiosity’s estimated life-cycle cost was about $2.5 billion, while Perseverance cost roughly $2.4 billion to build and launch, plus $300 million for landing and prime-mission operations [11, 13]. Because Earth–Mars launch opportunities recur only every 26 months, infrastructure cannot be added quickly [18]. Any orbital-computing architecture must therefore complement existing assets, provide value from its first deployment, and expand across successive launch windows.
2.3
Altitude / period Maximum Eclipse Coverage Minimum Link Distance Received Power Scaling Primary Role
Low Mars Orbit
17,030 km / 24.62 h 78.5 min 33%; persistent 17,030 km 1× geography: 3 reach ∼90% coverage and shared state
400 km / 118 min 41.6 min per orbit 2.5%; brief passes 400 km ∼ 1,800× as demand grows latency aware applications and added capacity
Table 2: Altitude separates surface coverage from surface-link capacity.
Related Work
Terrestrial LEO systems have explored satellite edge platforms and serverless runtimes [28, 29], state placement [4], contact-aware scheduling [34], split execution for Earth observation [33], and realistic satellite-network testbeds [3, 26]. These mechanisms exploit predictable mobility, but their assumptions do not transfer directly to Mars, where infrastructure is sparse, Earth contact is delayed and intermittent, and deployment opportunities are years apart (Table 1). Mars-specific studies have proposed areostationary spacecraft for persistent communication and monitoring [6] and an 81-satellite low-Mars-orbit edge network for planet-wide coverage [27]. Our design starts from a different requirement: shared compute needs a reachable service endpoint, not continuous high-rate access everywhere. We therefore separate persistent reachability from surface link capacity, using a small areostationary tier for shared service and adding loworbit capacity as demand grows. Our compute layer can be shared across current missions, and future sensors, vehicles and human operations, and can be incrementally deployable providing compute to active Mars missions with just one areostationary node.
3
Areostationary
separate these functions across two tiers: areostationary nodes provide persistent shared services, while low-Marsorbit nodes provide short, high-rate contacts and additional compute.
3.1
Two Orbital Regimes
Table 2 summarizes the trade-off between the altitude of nodes in the Mars orbits. An areostationary node remains fixed above the equator at approximately 17,030 km, while a 400 km low-Mars-orbit node moves rapidly over a much smaller footprint. High altitude increases persistent reachability; low altitude shortens the link to the surface. With a minimum elevation angle of 𝜀 min = 10◦ (as used in [35]), an areostationary node reaches approximately 33% of the Martian surface, compared with 2.5% for a 400 km node. The low node, however, is about 43× closer at closest approach. Under identical free-space link assumptions, this corresponds to roughly 1,800× greater received power. Altitude therefore separates two resources: persistent reachability and how much data the surface-link transmits.
A TWO-TIER COMPUTE LAYER FOR MARS
3.2
Compute placed on the surface of Mars is tied to a single mission and shares its power, mass, thermal, and lifetime constraints. It also cannot be shared easily across widely separated assets: Curiosity and Perseverance, for example, operate 3,700 km apart. Mars’ orbit provides a natural shared layer because surface data already pass through relay spacecraft on their way to Earth. A compute-bearing orbiter can therefore serve multiple missions, remain useful beyond any single rover or lander, and provide future missions with a standing pool of resources. Orbit also provides a more stable long-term platform than the surface, where dust accumulation has ended missions such as Opportunity and InSight [15, 17]. The challenge is that no single Mars orbit provides both persistent access and a strong surface link. We therefore
Three High Nodes Reach Most of Mars
We show the surface coverage of areostationary nodes in Fig. 2. A single areostationary node reaches approximately 33% of Mars and all the currently active surface rovers on Mars. Three areostationary nodes spaced 120◦ apart extend coverage to roughly 90% of the planet, with the remaining gaps concentrated near the poles. This result established the practicality of deploying compute on Mars. A constellation designed for continuous global communication may require tens of satellites. Shared compute has a weaker requirement: a surface asset needs one reachable compute endpoint, not uniform connectivity between arbitrary locations. To do so, only 1 areostationary node is needed to provide compute to all active Mars rovers, and only 2 additional areostationary compute nodes are 3
Maleeha Masood, Indranil Gupta, and Deepak Vasisht 90
applications. A 400 km node is roughly 40× closer to the surface than an areostationary node, corresponding to an approximately 1,800× received-power advantage under identical free-space link assumptions. This geometric advantage motivates a low-orbit tier. We model daily surface-to-orbit offload by evaluating the closest node visible above a 10◦ elevation angle (as used in [35]) every minute and assigning rate 𝑟 as:
latitude [deg]
60
Perseverance
30
Curiosity
0 −30 −60 −90
0
60
120
180 east longitude [deg]
no node in view
240
1 node
300
360
2 nodes
𝑟 = 𝑅0
Figure 2: Compute-availability coverage on Mars using areostationary nodes. Each node (★) sees ±70° of Mars. One node covers 33% of the planet and both active rovers; three nodes at 120° spacing cover 90% of the surface, leaving only the poles.
data offloaded per surface asset [Gb/sol]
5
4
3 TGO (measured, per orbiter) 2
0
MRO (measured, per orbiter)
0
1
2
3
4
5
6
number of low-Mars-orbit nodes
Figure 3: Data offloaded per surface asset versus the number of low-Mars-orbit nodes modelled using the 2 Mbps rover-to-orbiter UHF link [20]. Measured 2026 relay volumes [23] are shown for comparison. needed to cover 90% of Mars. Subsequent addition of highaltitude nodes produce rapidly diminishing coverage returns after the third node. Low-orbit nodes add even less instantaneous coverage because each sees only a small moving region (about 2.5% of Mars at a time). Coverage, however, is only half of the problem. The same altitude that gives an areostationary node a broad, persistent footprint also creates a weak surface link. High orbit can make compute reachable, but it cannot efficiently ingest high-volume data from the surface.
3.3
2 ,
where 𝑑 is the instantaneous slant range from the rover to that node, (𝑅0, 𝐷 0 ) = (2 Mbps, 400 km) is calibrated from Perseverance’s published maximum UHF rate [20]. Each 400 km node provides a rover with approximately 2.8 passes per sol, or about 26 minutes of aggregate contact. Figure 3 shows that a rover connected only to an areostationary node (0 low-Mars-orbit nodes) can offload about 0.09 Gb/sol. Each low-orbit node instead contributes approximately 0.85 Gb/sol from a few brief passes—roughly ten times the areostationary node’s daily surface-ingest capacity. Additional low-Mars-orbit nodes increase offload almost linearly because they contribute largely independent contact opportunities. Our single-node estimate falls between the relay volumes reported for MRO (0.85 Gb/day) and TGO (2.23 Gb/day) [23]. The comparison is approximate: NASA reports end-to-end data returned to Earth per orbiter, whereas our model estimates per-rover surface-to-orbit offload under ideal contact utilization. The result should therefore be interpreted as an upper bound rather than an operational prediction. Unlike high-altitude coverage, low-orbit capacity has no natural saturation point. The required number of low-orbit nodes is determined by how much data the surface fleet generates: additional nodes provide additional contact time and data transfer rates. High-orbit nodes are therefore sized by coverage, whereas low-orbit nodes are sized by demand. Low orbit therefore complements, rather than replaces, the high-orbit tier by providing a higher bandwidth link that persistent coverage alone cannot.
modeled, 2 Mbps UHF baseline
1
𝐷0 𝑑
3.4
Why Both Tiers Are Needed
The trade-off becomes clear by comparing three deployments: areostationary-only, low-orbit-only, and two-tier. Areostationary-only. One areostationary node provides persistent access to all active Mars rovers, three nodes cover roughly 90% of Mars, but the long surface link carries only about 0.09 Gb/sol under our UHF baseline. This design supports shared state and coordination, but not bulk surface-data transfer.
Low Orbit Buys Link Quality
The broad coverage of areostationary nodes makes shared compute reachable, but not necessarily useful for data-intensive 4
Bandwidth, Latency, and 400 Million Kilometers: The Case for Mars-Local Compute
Low-orbit-only. A 400 km node adds approximately 0.85 Gb/sol of surface ingress, but sees only about 2.5% of Mars at a time. Near-continuous access would therefore require a much larger constellation, such as the 81-node design explored in prior work [27], and several Earth–Mars launch windows to deploy.
Earth, power and cooling are supplied by datacenters. At Mars, they must be carried with the computer, making solar arrays, batteries, radiators, and the spacecraft bus the dominant costs. Power and thermal control. We size solar arrays at a conservative output of 100 W/m2 (compared to Mars’ average solar irradiance of approximately 590 W/m2 ) and assume charge and discharge efficiencies of 0.85 and 0.95, 70% usable battery depth, a 10–15% array margin, and a 10% battery reserve [9, 14]. A 400 km node, with a 118-minute orbit and a maximum 41.6-minute eclipse, requires approximately 106– 110 m2 of array and a 6.6 kWh battery. An areostationary node has a longer maximum eclipse of 78.5 minutes, but much more sunlight between eclipses, requiring approximately 68–71 m2 of array and a 12.5 kWh battery. Low orbit therefore requires more generation capacity, while areostationary orbit requires more energy storage. Nearly all consumed power becomes heat. Rejecting a 6 kW waste-heat load at 300 K requires an ideal radiator area of 15.4 m2 . Allowing for imperfect heat transport, external loading, degradation, deployment geometry, and reserve increases the preliminary estimate to 21–26 m2 .
Two-tier. A small areostationary tier establishes persistent shared service, while low-orbit nodes are added where greater link bandwidth and near-surface processing are needed. The architecture can be deployed incrementally, with each additional node expanding either coverage or capacity. The two tiers therefore solve different bottlenecks: areostationary nodes establish persistent service, while low-orbit nodes scale surface-data transfer.
3.5
What Runs Where?
The two tiers support different classes of computation. Loworbit nodes are closest to surface assets and provide brief, high-rate contacts. They are therefore best suited to dataintensive, latency-sensitive processing: filtering instrument streams, compressing or summarizing observations, detecting events, and selecting which data should be forwarded. Processing data during or shortly after contact reduces the volume that must traverse the Earth-facing links. Areostationary nodes provide persistent reachability over large regions and are better suited to long-lived shared state. They can maintain maps, scientific models, mission context, and cached datasets that must remain available across rover passes and orbital contacts. They can also combine observations from multiple assets, coordinate follow-up measurements, and expose common services to missions that were not designed to communicate directly. The two tiers can also form a processing pipeline. A loworbit node may extract features or identify an unusual observation, while an areostationary node compares it against prior measurements, updates shared state, and determines whether to request additional data or prioritize transmission to Earth. Earth remains responsible for objectives requiring human judgment, global mission planning, and archival science. Mars-local compute instead handles the work whose value depends on acting before the next Earth planning cycle.
4
Node Mass. The spacecraft mass is driven primarily by the systems required for continuous operation. Using NASAreported technology ranges for power generation and storage, a radiator and heat-transport areal mass of approximately 5–10 kg/m2 , and concept-stage assumptions for the compute subsystem and spacecraft bus, we estimate that the solar arrays contribute roughly 140–385 kg, the radiator and heat-transport system 105–260 kg, and the battery 45– 125 kg, depending on orbit [25, 31]. Adding 100–160 kg for compute and power electronics, 250–450 kg for communications, propulsion, attitude control, structure, and avionics, and a 20% reserve gives an operational dry mass of approximately 0.8–1.6 t per node. This places the design in the broad mass class of existing Mars orbiters such as MRO [9, 14]. Incremental deployment. Our compute architecture need not be launched as a complete constellation. A first areostationary node provides persistent service to all existing Mars rovers and can be used to validate the compute, thermal, power, and station-keeping systems. Later Earth– Mars launch opportunities, approximately 26 months apart, can add high-orbit nodes to expand coverage and low-orbit nodes where greater ingest capacity is needed. As a timely cost reference, SpaceX currently advertises future Starship cargo delivery to the Martian surface at roughly $100 million per tonne [32]. This is not a quoted price for Mars-orbit insertion, but it places the transport cost of a 0.8–1.6 t node in the rough $80–$160 million range before
ARE MARTIAN COMPUTE NODES FEASIBLE?
We do not claim a flight-ready spacecraft design but instead ask: does a Mars-orbit compute node pass a first-order feasibility test? We assume a 5 kW compute payload on each node and a 15% allowance for avionics, conversion losses, and other spacecraft systems, giving a continuous load of 5.75 kW. On 5
Maleeha Masood, Indranil Gupta, and Deepak Vasisht
capture, integration, and mission-specific costs. Each deployment should therefore provide useful capability on its own rather than depend on completing the full constellation.
5
than silently discard it. The open problem is to define approximation contracts that specify confidence, provenance, retention, and the authority to delete raw observations. What state should persist near Mars? Mars-local compute could maintain shared maps, models, caches, and mission context across assets that otherwise operate independently. StarCDN shows that caching reusable content in orbit can reduce reliance on Earth links [37]. Mars extends this question beyond replaceable content: maps, scientific products, model versions, and raw observations may remain authoritative for months or years while Earth is intermittently unreachable. LEO systems such as SpaceCore and Komet separate mobile functions from durable state [4, 28], but Mars cannot assume a continuously reachable source of truth. Raw observations may need immutable custody records, shared products may require versioning across long partitions, and transient nodes should only hold reconstructible state. The challenge is to provide useful sharing without losing provenance or creating unsafe consistency assumptions.
OPEN RESEARCH QUESTIONS FOR MARS-LOCAL COMPUTE
We outline some open research questions below. How does improving onboard AI change Mars systems? The value of Mars-local compute depends not only on communication constraints but also on what local computation can accomplish. As AI systems become more capable, increasing amounts of planning, scientific interpretation, and anomaly detection may execute near Mars, with Earth consulted only when model confidence is low or human judgment is required. This changes both communication and systems design: bandwidth becomes a resource for exceptions rather than every decision, while runtimes must support confidence-aware execution, model evolution, and verifiable human override across long communication delays. Mars-local compute thus becomes increasingly valuable as local intelligence improves.
Can Mars-local compute use modern accelerators? In low Earth orbits, commercial hardware can be operated with software hardening (e.g., replication). This is because Earth’s magnetosphere shields hardware from radiation. Operation on Mars requires radiation hardening (no magnetosphere). How do the compute-communication tradeoffs change given the comparatively limited capabilities of radiation-hardened hardware?
Where should computation run? Mars offers several execution sites—surface assets, low-Mars-orbit satellites, areostationary nodes, and Earth—with different latency, energy, and connectivity. Systems such as Serval [33] and Komet [28] show how predictable mobility can guide split execution and service placement in LEO satellites on Earth. At Mars, however, moving state between nodes may consume the same scarce capacity that computation is meant to save. A Mars runtime must decide when to move code, data, or intermediate results, and when computation should remain “local”.
How should Mars compute fail? Dense LEO constellations can often route around failed nodes; sparse Mars infrastructure may lose an entire region or service when one spacecraft fails. Mars-local compute must therefore degrade gracefully into relay-only operation, preserve raw data through missed contacts, and isolate failed instruments or software components without disabling communication.
How should communication and computation be scheduled together? LEO schedulers such as Umbra use predicted contacts to decide when data should be transmitted [34]. Near Mars, the system must also decide whether to process data before sending it. For example, an orbiter may spend compute and energy to compress an image or detect an important event, thereby reducing its size or increasing its priority. Communication and computation should therefore be scheduled together, rather than treating bandwidth, energy, storage, and processor time as separate resources.
6
CONCLUSION
Mars exploration is constrained not only by what its instruments can observe, but by how quickly those observations can be returned, processed, and acted upon. We propose a two-tiered compute architecture in the Mars orbit that can fundamentally change how missions operate. A small areostationary tier can establish persistent shared service across most of Mars, while low-orbit nodes can be added where missions need greater data ingress and near-surface processing. The system is useful from its first node, scales incrementally across launch windows, and appears feasible within the mass, power, and thermal envelope of large Mars spacecraft. The broader opportunity is to treat Mars orbit not only as a relay layer, but as shared computing infrastructure. Doing so could shorten scientific feedback loops, coordinate
When is approximation safe? Semantic filtering and selective inference can increase the useful information returned per downlink bit, as demonstrated by LEO Earthobservation systems such as Serval [33]. Mars makes mistakes harder to reverse because an observation may be unique and impossible to reacquire. The default should therefore be to rank, summarize, or progressively encode data rather 6
Bandwidth, Latency, and 400 Million Kilometers: The Case for Mars-Local Compute
assets across missions, and make each transmitted bit more valuable before it begins the 400-million-kilometer journey to Earth.
//assets.science.nasa.gov/content/dam/science/psd/mars/files/marsrelay-network/The%20Mars%20Relay%20Network%20Participation% 20Guide%20%E2%80%94%20Initial%20Release-July-1-2025.pdf Initial release, accessed: 2026-07-11. [13] NASA Office of Inspector General. 2011. NASA’s Management of the Mars Science Laboratory Project. Technical Report IG-11-019. National Aeronautics and Space Administration. https://oig.nasa.gov/docs/IG11-019.pdf [14] National Aeronautics and Space Administration. 2014. MAVEN: Mars Atmosphere and Volatile Evolution Mission. https://science.nasa.gov/ mission/maven/. Mission facts; accessed: 2026-07-16. [15] National Aeronautics and Space Administration. 2019. NASA’s Opportunity Rover Mission on Mars Comes to End. https://science.nasa.gov/missions/mer/nasas-opportunity-rovermission-on-mars-comes-to-end/. Accessed: 2026-07-16. [16] National Aeronautics and Space Administration. 2021. Mars 2020: Perseverance Rover. https://science.nasa.gov/mission/mars-2020perseverance/. Accessed: 2026-07-11. [17] National Aeronautics and Space Administration. 2022. NASA Retires InSight Mars Lander Mission After Years of Science. https://www.nasa.gov/missions/insight/nasa-retires-insight-marslander-mission-after-years-of-science/. Accessed: 2026-07-16. [18] National Aeronautics and Space Administration. 2024. Mars Mission Timeline. https://science.nasa.gov/planetary-science/programs/marsexploration/mission-timeline/. Accessed: 2026-07-10. [19] National Aeronautics and Space Administration. 2025. Core Area of Expertise: Intelligent and Adaptive Systems. https://www.nasa.gov/ ames/core-area-of-expertise-intelligent-and-adaptive-systems/. Accessed: 2026-07-10. [20] National Aeronautics and Space Administration. 2025. Perseverance Rover Components: Communications Section. https://science.nasa. gov/mission/mars-2020-perseverance/rover-components/. Communications section; accessed: 2026-07-11. [21] National Aeronautics and Space Administration. 2026. Curiosity Rover Location Map. https://science.nasa.gov/mission/msl-curiosity/ location-map/. Accessed: 2026-07-10. [22] National Aeronautics and Space Administration. 2026. Deep Space Network. https://www.nasa.gov/communicating-with-missions/dsn/. Accessed: 2026-07-11. [23] National Aeronautics and Space Administration. 2026. Mars Relay Network. https://science.nasa.gov/mars/mars-relay-network/. Accessed: 2026-07-10. [24] National Aeronautics and Space Administration. 2026. NASA’s HiRISE Captures Perseverance Marking a Milestone on Mars. https://science.nasa.gov/photojournal/nasas-hirise-capturesperseverance-marking-a-milestone-on-mars/. Accessed: 2026-07-10. [25] National Aeronautics and Space Administration. 2026. State-of-the-Art Small Spacecraft Technology: Power Systems. Technical Report. National Aeronautics and Space Administration. https://www.nasa.gov/wpcontent/uploads/2026/05/3-soa-power-2026-final.pdf Accessed: 202607-16. [26] Tobias Pfandzelter and David Bermbach. 2022. Celestial: Virtual Software System Testbeds for the LEO Edge. In Proceedings of the 23rd ACM/IFIP International Middleware Conference (Quebec, QC, Canada) (Middleware ’22). Association for Computing Machinery, New York, NY, USA, 69–81. https://doi.org/10.1145/3528535.3531517 [27] Tobias Pfandzelter and David Bermbach. 2023. Can Orbital Servers Provide Mars-Wide Edge Computing?. In Proceedings of the 1st ACM MobiCom Workshop on Satellite Networking and Computing (Madrid, Spain) (SatCom ’23). Association for Computing Machinery, New York, NY, USA, 7–12. https://doi.org/10.1145/3614454.3622997
REFERENCES [1] Mitchell Ai-Chang, John L. Bresina, Leonard Charest, Adam Chase, Jennifer Cheng-jung Hsu, Ari K. Jonsson, Bob Kanefsky, Paul H. Morris, Kanna Rajan, Jeffrey Yglesias, Brian G. Chafin, William C. Dias, and Pierre F. Maldague. 2004. MAPGEN: Mixed-Initiative Planning and Scheduling for the Mars Exploration Rover Mission. IEEE Intelligent Systems 19, 1 (2004), 8–12. https://doi.org/10.1109/MIS.2004.1265878 [2] Holly M. Dinkel and Jason K. Cornelius. 2024. Vela: A DataDriven Proposal for Joint Collaboration in Space Exploration. arXiv:2408.04730 [econ.EM] https://arxiv.org/abs/2408.04730 [3] Zeqi Lai, Hewu Li, Yangtao Deng, Qian Wu, Jun Liu, Yuanjie Li, Jihao Li, Lixin Liu, Weisen Liu, and Jianping Wu. 2023. StarryNet: Empowering Researchers to Evaluate Futuristic Integrated Space and Terrestrial Networks. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 1309– 1324. https://www.usenix.org/conference/nsdi23/presentation/laizeqi [4] Yuanjie Li, Hewu Li, Wei Liu, Lixin Liu, Yimei Chen, Jianping Wu, Qian Wu, Jun Liu, and Zeqi Lai. 2022. A case for stateless mobile core network functions in space. In Proceedings of the ACM SIGCOMM 2022 Conference (Amsterdam, Netherlands) (SIGCOMM ’22). Association for Computing Machinery, New York, NY, USA, 298–313. https: //doi.org/10.1145/3544216.3544233 [5] Alfred S. McEwen, Eric M. Eliason, James W. Bergstrom, Nathan T. Bridges, Candice J. Hansen, W. Alan Delamere, John A. Grant, Virginia C. Gulick, Kenneth E. Herkenhoff, Laszlo Keszthelyi, Randolph L. Kirk, Michael T. Mellon, Steven W. Squyres, Nicolas Thomas, and Catherine M. Weitz. 2007. Mars Reconnaissance Orbiter’s High Resolution Imaging Science Experiment (HiRISE). Journal of Geophysical Research: Planets 112, E5 (2007), E05S02. https://doi.org/10.1029/ 2005JE002605 [6] Luca Montabone, Nicholas G. Heavens, Jose L. Alvarellos, et al. 2020. Observing Mars from Areostationary Orbit: Benefits and Applications. Technical Report NASA NTRS 20205005976. NASA Planetary Science and Astrobiology Decadal Survey 2023–2032. https://ntrs.nasa.gov/ citations/20205005976 [7] NASA. 2024. M2M Architecture White Papers: Mars Challenges. Technical Report. National Aeronautics and Space Administration. https://www.nasa.gov/wp-content/uploads/2024/02/10-2024architecture-workshop-white-paper-mars-challenges.pdf [8] NASA. 2026. NASA Seeks Volunteers for Yearlong Simulated Mission to Moon, Mars. https://www.nasa.gov/hrp/nasa-seeks-volunteers-foryearlong-simulated-mission-to-moon-mars/. NASA Human Research Program. Accessed: 2026-07-16. [9] NASA Jet Propulsion Laboratory. 2005. Mars Reconnaissance Orbiter Launch Press Kit. Technical Report. National Aeronautics and Space Administration. https://www.jpl.nasa.gov/news/press_kits/mro-launch. pdf Accessed: 2026-07-16. [10] NASA Jet Propulsion Laboratory. 2017. Prolific Mars Orbiter Completes 50,000 Orbits. https://www.jpl.nasa.gov/news/prolific-marsorbiter-completes-50000-orbits/. Accessed: 2026-07-10. [11] NASA Jet Propulsion Laboratory. 2021. Mars 2020 Perseverance Landing Press Kit: Quick Facts. https://www.jpl.nasa.gov/news/press_kits/ mars_2020/landing/quick_facts/. Accessed: 2026-07-10. [12] NASA Mars Exploration Program. 2025. The Mars Relay Network (MRN) Participation Guide. Technical Report. National Aeronautics and Space Administration, Jet Propulsion Laboratory. https: 7
Maleeha Masood, Indranil Gupta, and Deepak Vasisht
[28] Tobias Pfandzelter and David Bermbach. 2024. Komet: A Serverless Platform for Low-Earth Orbit Edge Services. In Proceedings of the 2024 ACM Symposium on Cloud Computing (Redmond, WA, USA) (SoCC ’24). Association for Computing Machinery, New York, NY, USA, 866–882. https://doi.org/10.1145/3698038.3698517 [29] Tobias Pfandzelter, Jonathan Hasenburg, and David Bermbach. 2021. Towards a Computing Platform for the LEO Edge. In Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking (Online, United Kingdom) (EdgeSys ’21). Association for Computing Machinery, New York, NY, USA, 43–48. https://doi.org/10.1145/ 3434770.3459736 [30] Mustafa Qadri. 2026. NASA Seeks Volunteers for Year-Long Moon and Mars Simulation Mission. https://edition.cnn.com/2026/07/09/science/ nasa-moon-mars-simulation-scli-intl. CNN. Accessed: 2026-07-16. [31] John Siamidis. 2006. Heat Rejection Concepts for Lunar Fission Surface Power Applications. Technical Report NASA/CR-2006-214388. NASA Glenn Research Center. https://ntrs.nasa.gov/api/citations/ 20070001076/downloads/20070001076.pdf Also published as AIAA2006-4196. [32] SpaceX. 2026. Mars & Beyond. https://www.spacex.com/ humanspaceflight/mars. Accessed: 2026-07-16. [33] Bill Tao, Om Chabra, Ishani Janveja, Indranil Gupta, and Deepak Vasisht. 2024. Known Knowns and Unknowns: Near-realtime Earth Observation Via Query Bifurcation in Serval. In 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24).
USENIX Association, Santa Clara, CA, 809–824. https://www.usenix. org/conference/nsdi24/presentation/tao [34] Bill Tao, Maleeha Masood, Indranil Gupta, and Deepak Vasisht. 2023. Transmitting, Fast and Slow: Scheduling Satellite Traffic through Space and Time. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking (Madrid, Spain) (ACM MobiCom ’23). Association for Computing Machinery, New York, NY, USA, Article 24, 15 pages. https://doi.org/10.1145/3570361.3592521 [35] Jim Taylor, Dennis K. Lee, and Shervin Shambayati. 2014. Mars Reconnaissance Orbiter. Deep Space Communications and Navigation Series, Chapter 6. Jet Propulsion Laboratory, California Institute of Technology. https://descanso.jpl.nasa.gov/monograph/series13/ DeepCommo_Chapter6--141029.pdf Accessed: 2026-07-11. [36] Tiffany Vora and Chris Carberry. 2026. How Public–Private Partnerships Can Turn Mars into an Economic Frontier. Space.com (7 July 2026). https://www.space.com/space-exploration/how-publicprivate-partnerships-can-turn-mars-into-an-economic-frontier-oped Accessed: 2026-07-17. [37] William X. Zheng, Aryan Taneja, Maleeha Masood, Anirudh Sabnis, Ramesh K. Sitaraman, and Deepak Vasisht. 2025. StarCDN: Moving Content Delivery Networks to Space. In Proceedings of the ACM SIGCOMM 2025 Conference (São Francisco Convent, Coimbra, Portugal) (SIGCOMM ’25). Association for Computing Machinery, New York, NY, USA, 948–962. https://doi.org/10.1145/3718958.3754345
8