Inter-Satellite Links

Inter-satellite links (ISLs) add a routed space segment to the transport model. They are useful when user traffic or observation products may reach a gateway through one or more relay satellites instead of requiring the serving satellite to see a gateway directly.

flowchart LR UE["User or data source"] --> S1["Serving satellite"] S1 -->|"ISL"| S2["Relay satellite"] S2 -->|"ISL"| SG["Gateway-visible satellite"] SG --> GW["Ground gateway"]

ISLs extend the transport delivery system with a routed space segment. The same mission items, scheduler, delivery events, latency accounting, and backlog model apply.

Configuration

Enable the ISL surface and select the routed path mode:

transport:
  scheduler:
    path_mode: isl_gateway_routed
    scheduler_mode: greedy_capacity
  isl:
    enabled: true
    profile_id: customer_isl_ka
    frequency_khz: 26000000
    topology: walker_adjacent
    max_range_km: 8000
    max_hops: 8
    capacity_mbps: 300
    routing_policy: latency_weighted
    link_latency_ms: 2
    walker_adjacency:
      plane_seam: wrap
      cross_plane_slot_offset: 1

The profile and ISL antenna definition provide RF or optical link assumptions. The transport block provides topology, range, route, capacity, pointing, and terminal-concurrency policy.

From Candidate Pair To Routed Flow

An ISL route passes several distinct gates:

1. the topology admits a candidate satellite pair;
2. range and Earth obstruction allow geometric access;
3. antenna steering, pointing policy, and link budget permit the link;
4. neighbor and active-terminal limits admit simultaneous edges;
5. a route exists within the hop limit;
6. edge and terminal capacity admit the requested flow.

A pair present in the selected topology becomes available only after passing the remaining physical and resource gates; route artifacts record final selection.

Pairwise eligibility changes with orbital geometry. These windows describe usable candidate edges; route artifacts identify scheduler selection.

Candidate Topologies

transport.isl.topology	Candidate-pair rule
all	considers every pair before range and physical pruning
in_plane_only	considers range-qualified pairs classified in-plane
cross_plane_only	considers range-qualified pairs classified cross-plane
walker_adjacent	builds a fixed sparse lattice from Walker plane and slot coordinates

For walker_adjacent, each plane forms an in-plane cycle. Cross-plane links connect a slot to the configured offset in the neighboring plane. plane_seam: wrap also joins the final plane back to plane zero; open leaves that seam disconnected.

The Walker topology requires one complete, rectangular Walker shell with at least three planes and three satellites per plane and represents its regular sparse lattice. For cross-shell relationships, use one of the three proximity modes; they derive candidates from range-qualified satellite pairs and the selected in-plane or cross-plane rule. Explicit user-supplied edge lists are not a RunSpec topology mode.

Distinct Resource Controls

Three controls answer different engineering questions:

Control	Meaning
max_neighbors_per_sat	limits retained graph fanout for non-fixed topologies
parallelization.active_terminals_per_sat	limits simultaneous physical neighbor tracks per satellite
capacity_mbps	limits traffic carried by each admitted ISL edge

parallelization.flows_per_terminal can additionally limit route admissions sharing one terminal pairing. max_hops controls route length independently of terminal and throughput limits.

Leave max_neighbors_per_sat unset for walker_adjacent; the fixed lattice already defines fanout.

Routing And Pointing

The supported route policies are latency_weighted, shortest, and load_aware. Route choice remains constrained by the currently eligible edges, hop limit, gateway access, and resource policy.

pointing_policy: payload_strict preserves payload-pointing priority. isl_opportunistic allows the ISL surface to use available pointing opportunities more freely. A dedicated steerable ISL antenna avoids some shared surface conflicts, but still obeys its own field-of-regard and link assumptions.

When attitude realization is enabled, ensure the attitude schedule and ISL pointing intent are compatible. An abstract route cannot restore a link made unavailable by pointing or terminal constraints.

Outputs

ISL-routed studies add the following under transport/:

Artifact	Contents
isl_summary.json	topology, candidate/pruning counts, route counts, and performance estimates
isl_edges.*	timestamped candidate/eligible edges, range, capacity, and latency
isl_routes.*	selected satellite path, hop count, gateway, latency, and denial status
kpi_scheduler_global.json	fleet-level ISL capacity, terminal, and pointing denials
kpi_scheduler_by_point.*	point-level attribution of routed service outcomes

The standard transport summary, delivery-event, and backlog artifacts remain the authoritative end-to-end result. Use edge count as a topology diagnostic and the service artifacts for delivered-performance KPIs.

For a Walker case, review topology_provider, seam, slot offset, static-pair count, range-pruned count, eligible-edge count, routes found, and the scheduler denials before comparing latency or served volume.

Packaged Example

Run:

astraeus run astraeus-resources/examples/user/isl-routed-network.yaml

This case uses a 72-satellite Walker constellation, one gateway, a wrapped adjacent lattice with a one-slot cross-plane offset, and up to eight hops. It is large enough to show sparse-topology and route behavior while remaining a reviewable packaged example.

For a controlled topology comparison, run EX20 · Polar Mesh Topology Trade. It holds terminal access and traffic inputs fixed while comparing crosslinked and in-plane-only routing.

Fidelity And Scale Limits

• ISL results use the explicitly declared topology, link profile, terminals, and routing policy.
• walker_adjacent preserves its fixed lattice when an edge fails a physical gate; dynamic nearest-neighbor replacement requires another topology policy.
• Retained edge results grow with surviving pairs and simulation timesteps. All-pairs topology can therefore become much larger than sparse Walker adjacency.
• Routing resolution covers deterministic path selection, capacity, latency, terminals, and backlog at the configured cadence.
• Cadence limits the timing resolution of link eligibility, handover, route changes, and store-and-forward waits.

For the surrounding service and delivery model, see Communications, Service, And Transport. For exact fields, use the RunSpec reference.