PaperlayerView exact revision on arXiv

Source-linked AI summary

Satellite Intelligence: Distributed Training, Collaborative Inference,and LLM Adaptation in LEO Constellation

Zheng Lin, Zhanwei Wang, Yuxin Zhang, Yafei Wang, Ons Aouedi, Zihan Fang, Jinfeng Xu, Jing Yang, Vu Nguyen Ha, Yuanwei Liu, Mohamed-Slim Alouini, Symeon Chatzinotas

arXiv:2610.35282v1cs.NIcs.AI

TL;DR

LEO satellite AI faces tight onboard resources, dynamic topologies, and intermittent energy, while prior surveys do not jointly cover its training, inference, and LLM challenges. This survey synthesizes constraint-aware design principles and reviews those three paradigms, concluding with open challenges and a roadmap for space-native AI.

Abstract

from arXiv · show

The proliferation of orbital sensing data and the real-time demands of emerging global services are pushing low Earth orbit (LEO) satellite networks from bent-pipe relays toward intelligent onboard processing. This shift confronts a fundamental tension, where modern artificial intelligence (AI) training paradigms require intensive computation, abundant memory, and stable connectivity, all of which are scarce under the dynamic topologies, intermittent links, and severe size, weight, and power (SWaP) constraints of satellite networks. Addressing this tension demands rethinking AI workflows, from training and inference to the emerging deployment of large language models (LLMs), under a constraint-aware design philosophy. To the best of our knowledge, this paper provides the first survey that jointly covers all three, whereas prior surveys examine these aspects in isolation. We begin by identifying the deployment challenge of satellite intelligence (SI) and deriving design principles for SI. We then examine three advancing paradigms: i) distributed training, where federated learning (FL) and split learning (SL) enable satellite-ground co-training under resource limitations; ii) collaborative inference, which exploits single-satellite, multi-satellite, and satellite-ground architectures to meet real-time service demands; and iii) on-orbit LLM adaptation and serving, which tackles the frontier challenge of deploying LLMs under severe orbital constraints and resource-aware serving. Finally, we identify open challenges and future directions. By bridging the AI and satellite networks, this paper provides a research roadmap for the implementation of space-native AI technologies.

I. INTRODUCTION

The introduction frames satellite intelligence (SI) as a response to the limits of ground-centric processing under orbital constraints, and presents a survey that unifies distributed training, collaborative inference, and on-orbit LLM adaptation. It identifies a gap in prior surveys’ coverage and positions this work as a constraint-aware roadmap for space-native AI.

A. Background

  • Intermittent ground contacts and shared satellite-ground link bandwidth make ground-centric processing unsuitable for real-time satellite applications such as disaster response and planetary monitoring.The introduction also notes that raw high-fidelity sensor streams impose a prohibitive bandwidth burden on these links.Source: A. Background · p. 1

B. Motivation: From Terrestrial-Centric Processing to Satel-

  • LEO satellites’ SWaP limits, dynamic topologies, and intermittent energy make direct transplantation of resource-intensive terrestrial AI workflows impractical.The paper identifies a need for collaborative SI frameworks because an isolated satellite cannot handle the computing demands of modern AI tasks.Source: B. Motivation: From… · p. 2

C. Comparisons with Prior Surveys and Our Contributions

  • Prior surveys do not comprehensively address orbital constraints, satellite-specific distributed training, collaborative inference architectures, and on-orbit LLM adaptation and serving.The paper says no existing survey comprehensively covers all four dimensions.Source: C. Comparisons with Prior Surveys and… · pp. 2–4
  • This survey synthesizes constraint-aware design principles and coverage of distributed training, collaborative inference, on-orbit LLM deployment, and open challenges into a roadmap for SI.Its scope progresses from deployment constraints through training and inference to LLM adaptation and serving.Source: C. Comparisons with Prior Surveys and… · p. 4

II. DEPLOYMENT CHALLENGES AND DESIGN PRINCIPLES

The section characterizes SI as shaped by onboard resource limits, dynamic connectivity, and intermittent energy, then sets out constraint-aware design principles. It introduces satellite-ground collaboration as a foundation for satellite federated and split learning.

A. Deployment Challenges of SI

  • Satellite processors and memory are sharply constrained, and fixed post-launch resource budgets make mismatches between AI workloads and onboard capacity difficult to remedy.The cited examples range from about 1 GB of memory on CubeSat-class platforms to 8–32 GB on GPU-equipped payloads.Source: A. Deployment Challenges of SI · p. 4
  • LEO contact windows, degraded links, and limited SGL capacity constrain the exchange of AI features and model parameters, producing transmission queues and parameter staleness.A given ground station may be available for only a few windows per day, each lasting up to about 10 minutes; small-satellite RF SGLs typically provide 30–100 Mbps.Source: A. Deployment Challenges of SI · pp. 4–5
  • Intermittent solar generation and limited AI battery capacity make continuous onboard execution unsustainable and can interrupt long-running processes.A typical orbit includes an approximately 30-minute eclipse within 90 minutes, while AI battery capacity is typically 10–100 Wh.Source: A. Deployment Challenges of SI · p. 5

B. Design Principles for SI

  • SI design principles call for partitioning or scheduling work across satellite and ground resources, asynchronous disruption-tolerant coordination, and energy-aware scheduling synchronized with orbital cycles.The principles also call for hardware-algorithm co-design and predictive scheduling around sunlit-eclipse transitions.Source: B. Design Principles for SI · p. 5

III. SATELLITE DISTRIBUTED TRAINING FRAMEWORKS

  • Satellite-ground collaboration exchanges model parameters, activations, and gradients, providing a common architecture for federated and split learning.The survey introduces these two paradigms as representative approaches to distributed training under satellite constraints.Source: §III · pp. 5–6

A. Satellite-GS Collaborative Architecture

Satellite–ground collaboration divides processing between resource-constrained satellites and capable ground stations (GSs), which exchange intermediate results rather than raw satellite data.

A. Satellite-GS Collaborative Architecture

  • The architecture supports FL and SL through exchanges of model parameters, activations, and gradients between satellites and the GS.In SL, “smashed data” collectively refers to activations sent to the GS and gradients returned at the cut layer.Source: A. Satellite-GS Collaborative… · p. 6
  • Satellites perform lightweight processing and cache model parameters or smashed data until a satellite–GS visibility window opens.Depending on the paradigm, satellites update a full model in FL or shallow layers in SL.Source: A. Satellite-GS Collaborative… · p. 6
  • The GS aggregates FL updates or processes SL’s deep layers using received intermediate results, without accessing raw satellite data.This arrangement balances computation across the network and preserves data privacy by design.Source: A. Satellite-GS Collaborative… · p. 6
  • Fig. 4 depicts satellite FL model exchange during satellite–GS contact windows.Source: Figure 4 · p. 7

B. Satellite FL

Satellite FL uses repeated satellite–GS model exchanges for collaborative training, while its local updates, participation, and energy use must be adapted to orbital constraints.

1) FL Workflow in Satellite Networks

  • Each FL round broadcasts a GS global model, trains local satellite models, uploads updates during contact windows, and aggregates them by weighted averaging.The GS redistributes the resulting global model for the next round.Source: 1) FL Workflow in Satellite Networks · p. 7

2) Efficient Local Updates

  • Parameter-efficient fine-tuning, adaptive local epochs, and update compression address satellite FL’s compute, memory, and communication costs.PEFT freezes the pretrained backbone; epoch counts must balance resources against divergence, while sparsification and quantization require calibration to avoid excessive optimization noise.Source: 2) Efficient Local Updates · pp. 7–8

3) Connectivity-Aware Coordination

  • Because GS contact windows are short and intermittent, FL coordination can schedule participation using predicted visibility rather than assume continuous connectivity.Contact-aware selection balances round completion against spatial bias; asynchronous aggregation can incorporate delayed updates with staleness compensation, and ISL relays can recover updates from satellites lacking GS visibility.Source: 3) Connectivity-Aware Coordination · p. 8

4) Eclipse-Aware Scheduling

  • Local FL workload can scale with predicted solar power, battery state, training time, and the reserve needed for the next eclipse.The controller adjusts epochs and mini-batch size as energy measurements are updated.Source: 4) Eclipse-Aware Scheduling · pp. 8–9
  • Cross-plane scheduling can prioritize satellites with available energy while accounting for how repeated selections affect their future battery reserves.The aim is to keep batteries above a safe threshold over the long run as constellation topology changes.Source: 4) Eclipse-Aware Scheduling · pp. 9–10

C. Satellite SL

Satellite SL partitions a neural network between satellites and the GS, but its frequent forward–backward exchanges must be coordinated with variable resources, connectivity, memory, and energy.

1) SL Workflow in Satellite Networks

  • Satellites send cut-layer activations to the GS, which computes loss and returns gradients so satellites can complete client-side backpropagation.The exchange repeats across mini-batches until training converges.Source: 1) SL Workflow in Satellite Networks · p. 10

2) Dynamic Split Execution

  • A resource-aware cut layer must minimize onboard computation while keeping cached activations within satellite memory limits.Deeper cuts can increase activation memory even when they reduce computation time.Source: 2) Dynamic Split Execution · p. 10
  • Heterogeneous satellites can use customized client-side models sharing initial base layers, while the GS selects matching backbone modules for each cut layer.The GS periodically aggregates and redistributes base-layer parameters to maintain consistent low-level feature extraction.Source: 2) Dynamic Split Execution · pp. 10–11
  • SL’s cached activations and returned gradients can jointly exceed onboard memory, so checkpointing, compressed gradients, or staggered batches can reduce peak usage.Compression must be tailored to the model and task because overly aggressive compression degrades training accuracy.Source: 2) Dynamic Split Execution · p. 11

3) Pipeline and Offline Orchestration

  • Intermittent GS links make SL vulnerable because interruptions hinder its coupled forward–backward pipeline rather than merely delaying it.Window-aware batch sizing and asynchronous forward/backward pipelines can use available contact time and avoid idle computation, but delayed gradients create staleness that requires correction.Source: 3) Pipeline and Offline Orchestration · pp. 11–12
  • During prolonged GS occlusion, an onboard surrogate can support client-side training, but its updates diverge from GS-produced gradients and cause a temporary accuracy drop after reconnection.The GS treats surrogate-guided rounds as stale and applies delay-compensated correction.Source: 3) Pipeline and Offline Orchestration · p. 12

4) Orbit-Aware Energy Control

  • Sunlit-phase scheduling budgets training rounds against predicted solar generation and eclipse reserves, while overlap power regulation limits simultaneous compute and transmission draw.Controllers can recalibrate budgets from battery telemetry and reduce batch size or use a shallower cut; eclipse conditions require a tighter margin against peak power limits.Source: 4) Orbit-Aware Energy Control · p. 12

D. Paradigm Comparison and Selection

Satellite FL and SL trade local computation against satellite–GS communication, so paradigm choice depends on available satellite resources and sustainable connectivity. The paper describes both concurrent hybrid deployment and transitions between paradigms.

D. Paradigm Comparison and Selection

  • FL suits satellites able to train full models locally with occasional exchanges, while SL offloads deep layers but requires frequent communication that must not become the bottleneck.A constellation can run FL and SL concurrently or transition individual satellites between them; transitions should follow sustained capacity mismatch rather than transient resource fluctuations.Source: D. Paradigm Comparison and Selection · p. 13

IV. SATELLITE COLLABORATIVE INFERENCE

Satellite inference can run locally, across cooperating satellites, or jointly between satellites and the ground station (GS), with the architecture chosen to fit task demands and available resources. The section surveys local-inference workflows and techniques for managing onboard compute, memory, and energy limits.

A. Inference Architectures for SI

  • SI inference spans local execution on one satellite, multi-satellite execution over inter-satellite links (ISLs), and satellite-GS execution over satellite-ground links (SGLs).The architectures trade reliance on a single satellite’s resources against participation by other satellites or the GS.Source: A. Inference Architectures for SI · p. 13

B. Local Inference for SI

  • Local inference runs the complete model onboard without wireless exchange, avoiding link availability as a feasibility constraint but remaining bounded by the satellite’s compute, memory, and energy budgets.The workflow profiles and installs eligible model configurations, preprocesses observations, then selects a model and execution configuration using task, observation, and resource conditions.Source: B. Local Inference for SI · pp. 13–14, 1) Workflow of Local Inference · p. 14
  • Compression reduces onboard model cost at a potential accuracy penalty, using pruning and quantization or standalone replacements produced by distillation or low-rank factorization.Structured pruning maps more efficiently to embedded accelerators than unstructured sparsity without dedicated support; pruning and quantization are often cascaded, while distilled and factorized models are alternatives.Source: 2) Model Compression and Reconstruction · p. 14
  • Model selection routes tasks among offline-prepared networks, balancing accuracy, latency, and energy using observation content or the satellite’s changing energy state and task load.Multiple candidates consume onboard storage, creating a trade-off between scene and resource coverage and memory for a more capable model.Source: 3) Model- and Depth-Adaptive Inference · p. 15
  • Early-exit inference uses intermediate classifiers and calibrated confidence thresholds to trade lower latency and energy for possible accuracy loss on small or ambiguous targets.For object detection, uncertainty estimates, visual features, and geographic priors can inform whether image tiles proceed to deeper stages.Source: 3) Model- and Depth-Adaptive Inference · pp. 15–16
  • Energy-aware processor control selects frequency to minimize energy under strict deadlines, accounting for stochastic execution time and the reliability cost of repeated thermal cycling.Offline latency profiles support high-probability deadline satisfaction, while online optimization can adjust frequency as queues and energy change; coordinating multicore mapping and DVFS can bound thermal excursions.Source: 4) Energy-Aware Processor Management · p. 16

C. Multi-Satellite Collaborative Inference

Multi-satellite collaborative inference partitions and places a model across an ISL-connected path, pooling satellite resources and enabling pipelined execution. Its benefits depend on coordinating deployment, feature transfer, and energy control around coupled resource and connectivity constraints.

C. Multi-Satellite Collaborative Inference

  • The workflow partitions a trained model into sub-models placed along an ISL-connected path, forwards intermediate features through the pipeline, and returns terminal predictions to the source satellite or stores them for downlink.For sustained input streams, micro-batches let different satellites process successive inputs concurrently.Source: 1) Workflow of Multi-Satellite… · p. 16
  • Multi-satellite inference pools distributed memory and compute for models beyond one satellite’s capacity, supports inference during GS non-visibility, and improves continuous-stream throughput through micro-batch pipelining.The workload and energy burden are distributed across satellites, while successive inputs can be processed concurrently with sub-model dependencies preserved.Source: 1) Workflow of Multi-Satellite… · p. 16
  • Partitioning and placement must jointly fit satellite compute and memory while balancing pipeline execution, routing, and offloading under changing workloads and network conditions.Uneven placement can leave faster satellites idle or make slower ones the bottleneck; large models may exceed individual memory limits, as illustrated by ViT-Huge’s approximately 1.26 GB of 16-bit weights versus OPS-SAT’s 1 GB CPU memory limit.Source: 2) Bottlenecks in Multi-Satellite… · p. 16, 3) Resource-Adaptive Model Deployment · p. 17
  • SpaceMoE distributes mixture-of-experts layers and experts across orbital-ring satellite subnets, placing frequently activated experts on satellites with lower expected path latency to reduce token-generation latency.Expert placement adds a deployment dimension beyond layer-wise partitioning.Source: 3) Resource-Adaptive Model Deployment · pp. 17–18
  • Dynamic ISL handovers and pointing errors can interrupt feature transfers, stall downstream satellites, and reduce pipeline availability; eclipse or battery depletion at any participating satellite can halt the pipeline.A multi-hop chain also trades longer transmission paths for the memory cost of replicating sub-models.Source: 2) Bottlenecks in Multi-Satellite… · p. 17, 4) Resilient Feature Transfer and… · p. 18
  • Feature compression must adapt to changing link capacity and contact duration because aggressive compression risks losing task-relevant information, while micro-batch pipelining overlaps communication with computation but cannot by itself prevent disruption losses.Topology-aware admission control delays batches without sufficient predicted contact time, and checkpointing buffered activations supports resumption after a link failure; split-and-exit control also adapts execution depth to energy and deadlines, though current methods often use simplified energy models.Source: 4) Resilient Feature Transfer and… · p. 18, 5) Energy-Constrained Split-and-Exit… · p. 18

D. Satellite-GS Collaborative Inference

Satellite-GS collaborative inference assigns part of a model to the satellite and the remaining layers to the GS, using SGL contact windows to transfer intermediate features. Its resource advantage is constrained by intermittent access, transmission volume, and end-to-end deadlines.

D. Satellite-GS Collaborative Inference

  • A typical satellite-GS workflow runs shallow model layers onboard, transmits intermediate features during an SGL contact window, and has the GS execute the remaining layers and produce task outputs.Features can be buffered until a suitable contact, and outputs may be returned to the satellite or used by GS-side applications.Source: 1) Workflow of Satellite-GS… · p. 19
  • GS resources can support models beyond accessible satellites’ capacity, but SGLs face attenuation or blockage, 1.7–6.7 ms one-way propagation delays, and only four to six daily contacts lasting up to about ten minutes for LEO Earth-observation satellites.These contact windows constrain when and how much intermediate data can be transmitted.Source: D. Satellite-GS Collaborative Inference · p. 18, 1) Workflow of Satellite-GS… · p. 19
  • Contact-aware partitioning chooses the model split jointly with transmission and GS execution so intermediate features fit available contacts and end-to-end deadlines.A split chosen only to minimize onboard computation may produce features too large for a contact or miss the visibility window, forcing a wait for the next contact.Source: 2) Contact-Aware Model Partitioning · pp. 19–20
  • Downlink-efficient compression reduces transmitted volume through task-critical feature selection or channel-tailored encoding, with the objective of delivering relevant semantics within contact windows.The appropriate design differs between error-prone low-rate links, where robustness matters, and reliable links where encoding efficiency and contact duration constrain delivery.Source: 3) Downlink-Efficient Compression · p. 20
  • GS-access-aware coordination selects direct, forwarded, or locally processed delivery paths and prioritizes tasks according to contact duration, deadlines, storage limits, urgency, or prediction confidence.For feedback-dependent tasks, routes can be updated as visibility changes; when capacity is insufficient, urgency or confidence can guide transmission priority.Source: 4) GS-Access-Aware Task Coordination · p. 20

E. Paradigm Comparison and Selection

The paper presents architecture selection as a dynamic decision based on model, workload, resources, and communication conditions. It then introduces on-orbit LLM deployment as a distinct challenge under satellite resource constraints.

E. Paradigm Comparison and Selection

  • The preferred inference architecture depends on task feasibility, profiled accuracy and resource overhead, and predicted communication availability, including contact waiting and result-return latency.Local execution avoids external communication delay when feasible; multi-satellite or satellite-GS execution is preferred when added resources justify their communication and contact costs.Source: E. Paradigm Comparison and Selection · p. 21
  • Switching architectures requires checking model availability and accounting for loading, migration, or data-transfer costs, so expected performance benefits must preserve task feasibility and outweigh this overhead.Sustained performance degradation under the selected deployment can motivate model updating through distributed training.Source: E. Paradigm Comparison and Selection · p. 21

V. ON-ORBIT ADAPTATION OF LLMS

  • On-orbit LLM deployment extends beyond conventional satellite AI because LLMs demand substantially more memory and computation under stringent SWaP limits.The section covers resource-efficient serving, orbital simulation and validation, and LLM-enabled SI capabilities including knowledge-augmented reasoning and constellation-scale multi-agent systems.Source: §V · p. 21

A. Motivations and Challenges

The section frames onboard LLMs as a cognitive layer for satellite intelligence, while emphasizing that practical deployment must address resource-constrained serving, orbital validation, and software-stack integration.

Why LLMs for SI

  • LLMs are positioned as a cognitive layer that interprets information, invokes tools, and coordinates task execution without replacing specialized perception, control, or verified aerospace software.The intended capabilities include knowledge-augmented reasoning, satellite-aware tool orchestration, and constellation coordination.Source: 1) Why LLMs for SI · p. 21

Knowledge-Augmented Cognitive Reasoning

  • Knowledge-augmented reasoning combines domain adaptation with external retrieval to generate context-aware recommendations from heterogeneous mission information.Examples include anomaly diagnosis across telemetry and orbital conditions, and observation planning across priorities, visibility, payload, communications, and energy.Source: 1) Why LLMs for SI · p. 21

Satellite-Aware Tool Use and Workflow Orchestration

  • LLM agents can translate mission objectives into executable subtasks, select tools, and integrate outputs into plans, including locally when ground-station connectivity is unavailable.Command validation, rule-based constraints, and human oversight are specified for safety-critical operations.Source: 1) Why LLMs for SI · p. 22

Autonomous Constellation Coordination

  • Onboard LLMs can support constellation coordination by exchanging summarized local states and negotiating assignments, while a hierarchy combines time-sensitive satellite decisions with ground-based global planning.The passage describes this as useful under limited inter-satellite and satellite-ground links, with supervision retained for complex or safety-critical decisions.Source: 1) Why LLMs for SI · p. 22

Gaps Between LLMs and Satellite Operations

  • LLM serving must jointly manage autoregressive computation, growing KV-cache memory, onboard resources, changing orbital conditions, mission priorities, and satellite-ground coordination.The section identifies adaptive serving mechanisms as necessary to jointly account for connectivity, resources, latency, and mission priorities.Source: 2) Gaps Between LLMs and Satellite… · p. 22
  • Conventional static-platform benchmarks and isolated in-orbit experiments are inadequate for representative evaluation, motivating orbital-aware simulation and hardware-in-the-loop validation.In-orbit experiments are costly, infrequent, and difficult to reproduce; the section also identifies reliable integration with the satellite software stack as a deployment challenge.Source: 2) Gaps Between LLMs and Satellite… · pp. 22–23

B. Resource-Efficient On-Orbit LLM Deployment

The section treats on-orbit LLM deployment as a system problem spanning resource-efficient onboard execution, satellite-ground collaboration, and coupled orbital simulation and validation.

Resource-Efficient On-Orbit LLM Deployment

  • On-orbit LLM deployment must coordinate onboard serving, satellite-ground collaborative serving, and orbital simulation and validation under spacecraft resource and environmental constraints.The constraints include model weights, activations, growing KV caches, runtime states, radiation faults, restricted heat dissipation, variable energy, and intermittent connectivity.Source: B. Resource-Efficient On-Orbit LLM… · p. 23

Efficient Onboard LLM Serving

  • Hardware-aware compression uses quantization, structured pruning, and distillation to reduce onboard resource demands while accounting for autoregressive inference and target hardware.The section warns that irregular sparsity may not accelerate without hardware support, aggressive quantization can degrade reasoning and safety alignment, and memory must remain available for caches and other workloads.Source: 1) Efficient Onboard LLM Serving · p. 24
  • KV-cache management controls both what enters the cache and what it retains, using retrieval, reusable prefixes, quantization, importance-aware eviction, and sparse or sliding-window attention.Eviction should preserve authoritative measurements and decision provenance needed for later mission decisions or audits.Source: 1) Efficient Onboard LLM Serving · p. 25
  • Energy-aware serving schedules deferrable prefill and other non-urgent work during sunlit phases while reserving battery for latency-sensitive decoding and adapting execution as eclipse approaches.The section distinguishes batched prompt prefill from sequential decoding, which requires sustained power; runtimes can also reduce concurrency, checkpoint decoding, switch models, or defer requests to the ground.Source: 1) Efficient Onboard LLM Serving · p. 25

Satellite-GS Collaborative LLM Serving

  • Satellite-ground collaborative serving routes routine or time-critical tasks to satellites and knowledge-intensive analysis or complex planning to the ground, considering task quality, criticality, deadlines, contacts, and link capacity.Collaboration can offload a whole request or only a reasoning step, and task criticality need not align with model confidence.Source: 2) Satellite-GS Collaborative LLM… · pp. 25–26
  • At task or reasoning-step boundaries, satellites can exchange compact structured semantic state for asynchronous ground verification or refinement instead of sending full interaction histories.This supports reasoning during orbital occlusion and makes transmission volume track changes in task state rather than accumulated context.Source: 2) Satellite-GS Collaborative LLM… · p. 26

Orbital LLM Simulation and Validation

  • Orbital LLM evaluation requires an integrated closed loop because orbital-network simulators omit LLM serving behavior while serving simulators assume stable datacenter conditions.The proposed framework couples orbital dynamics, hardware and serving behavior, and mission workloads, then progresses from trace-driven simulation through emulation and hardware-in-the-loop to limited in-orbit experiments.Source: 3) Orbital LLM Simulation and Validation · pp. 26–27, Figure 15 · p. 26

C. LLM-Enabled Cognitive Capabilities for SI

The section presents LLMs as cognitive interfaces that connect satellite observations, mission knowledge, tools, and distributed decisions, while preserving roles for specialized algorithms and satellite-ground collaboration.

LLM-Enabled Cognitive Capabilities for SI

  • LLMs can serve as a cognitive interface linking observations, mission knowledge, domain tools, and distributed decisions rather than replacing specialized perception, communication, or control algorithms.The section organizes these capabilities around mission objectives and operational timescales.Source: C. LLM-Enabled Cognitive Capabilities… · p. 27

Satellite Knowledge-Augmented Reasoning

  • Satellite knowledge-augmented reasoning must evaluate the spatio-temporal validity of retrieved evidence, using metadata such as timestamps, coordinate systems, and topological provenance.The passage notes that maneuvers can invalidate orbital state vectors and that neighboring-satellite telemetry may lag current readings.Source: 1) Satellite Knowledge-Augmented… · p. 27
  • A satellite knowledge-retrieval architecture can combine spatio-temporal knowledge graphs, deterministic database queries, manual retrieval, and filtering of stale telemetry.The described approach couples semantic search with graph traversal and metadata filtering to support auditable mission reasoning.Source: 1) Satellite Knowledge-Augmented… · p. 27

Satellite-Aware Tool Use

  • For critical operations, the LLM proposes actions, deterministic tools verify physical feasibility, and flight software or ground operators authorize execution under predefined safety classifications.The passage also calls for typed schemas, middleware integration, and validation through a digital twin or physics-based simulation before live execution.Source: 2) Satellite-Aware Tool Use · p. 27

Satellite-GS Cognitive Collaboration

  • Satellite-ground cognitive collaboration divides authority according to observability: satellites access current local observations, while ground systems retain broader historical, constellation-wide, mission, and human knowledge.This differs from collaborative serving, which concerns where model computation is executed.Source: 3) Satellite-GS Cognitive Collaboration · pp. 27–28
  • A versioned shared mission state lets satellites and ground systems update asynchronously while checking write versions and distinguishing mandatory directives from advisory results.The store records observations, hypotheses, plans, actions, and unresolved decisions, supporting decision consistency under delayed and intermittent connectivity.Source: 3) Satellite-GS Cognitive Collaboration · p. 28

Constellation-Scale Multi-Agent Systems

  • Constellation agents reason and act independently toward shared objectives, but coordination must constrain messages, decision authority, and state exchange as links and local observations vary.The section recommends timestamped and validity-bounded messages, predefined procedures for consequential decisions, and compact belief summaries transmitted when they materially change.Source: 4) Constellation-Scale Multi-Agent… · pp. 28–29

VI. OPEN CHALLENGES AND FUTURE DIRECTIONS

The section identifies system security, data compliance, and data efficiency as concerns for practical satellite intelligence.

Open Challenges and Future Directions

  • Practical and efficient satellite intelligence remains an open direction involving system security, data compliance, and data efficiency.The section presents these as pressing concerns and potential solution areas.Source: §VI · p. 29

A. Secure and Reliable SI

The section identifies security and reliability, data compliance, and data efficiency as open challenges for satellite intelligence (SI), and outlines approaches and constraints for addressing them.

A. Secure and Reliable SI

  • Even without raw-data downlinks, intermediate representations can expose sensitive imagery or mission intent, while differential-privacy noise compounds with channel errors, quantization, and sparsification.Privacy mechanisms must balance information leakage against the signal-to-noise ratio of compressed orbital transmissions.Source: A. Secure and Reliable SI · p. 29
  • Greater ground-station offloading exposes more invertible features, while asynchronous participation makes poisoned updates harder to distinguish from stragglers and erroneous autonomous decisions may risk collisions.The section calls for lightweight, topology-aware verification that stays within onboard compute limits.Source: A. Secure and Reliable SI · p. 29

B. Data-Compliance-Aware SI

  • Jurisdiction-spanning telemetry requires data influence to be removable from every affected model artifact, but verifiable unlearning on constrained satellites without disrupting missions remains open.Region-specific parameter-efficient modules over a shared frozen backbone allow compliance by dropping the associated module, at the cost of cross-regional knowledge sharing.Source: B. Data-Compliance-Aware SI · pp. 29–30

C. Data-Efficient SI

  • Because orbital data is abundant but mostly unlabeled and redundant, training on all observations can exhaust onboard resources and may degrade performance.Targeted sample selection and constellation-level allocation must also avoid skewing local data toward rare edge cases.Source: C. Data-Efficient SI · p. 30
  • Ground-only labels motivate active learning for uncertain samples, while unlabeled observations can support self-supervised learning through multiview spatio-temporal consistency.Clouds, illumination, and seasons can obscure the distinction between genuine landcover change and observational discrepancy.Source: C. Data-Efficient SI · p. 30

VII. CONCLUSION

  • The survey presents constraint-aware principles and frameworks for distributed training, collaborative inference, and on-orbit LLM adaptation, alongside open challenges in security, compliance, and data efficiency.Source: §VII · p. 30

Related papers

Loading 2610.35282v1…