EX20 — Polar Mesh Topology Trade

Tags: polar constellation · inter-satellite links · topology trade · AI-assisted workflow Input: polar-mesh-topology-trade.yaml · Runtime tier: standard · Interface: CLI and skills

Purpose

Ask what cross-plane links contribute to a 66-satellite polar network. The study holds the constellation, terminal access, traffic, gateway, link budget, scheduler, and time window constant while changing only the ISL topology.

Setup

Both cases use 66 satellites in six planes at 778 km and 86.4° inclination, with an approximate Tempe city reference as the common gateway destination. One case uses a sparse crosslinked Walker-adjacent mesh; the counterfactual keeps only two in-plane neighbors per satellite.

Plan the two cases before execution, then run them with one worker:

astraeus batch plan \
  astraeus-resources/examples/user/polar-mesh-topology-trade.yaml

astraeus batch run \
  astraeus-resources/examples/user/polar-mesh-topology-trade.yaml \
  --workers 1

RunSpec Focus

The baseline connects adjacent satellites both within and across planes:

transport:
  isl:
    topology: walker_adjacent
    walker_adjacency:
      plane_seam: open
      cross_plane_slot_offset: 0

The alternative changes only the topology and neighbor bound:

transport:
  isl:
    topology: in_plane_only
    max_neighbors_per_sat: 2

The complete shared setup is in _shared/polar-mesh-network-base.yaml; the two short child RunSpecs make the controlled difference easy to review.

AI-Assisted Flow

The bundled AI skills can recreate the counterfactual instead of treating the two cases as opaque inputs. From an editable resource copy, ask:

$astraeus-runspec-drafter Starting from
examples/user/cases/polar-mesh-crosslinked.yaml, create my-in-plane-only.yaml.
Keep every inherited assumption fixed. Change only the ISL topology to
in_plane_only with two neighbors per satellite, validate it, and show me the
resolved difference.

$astraeus-study-manager Create a copy of the EX20 batch that compares the
crosslinked baseline with my-in-plane-only.yaml. Plan it, summarize the two
cases and resource preflight, and stop for approval before running.

After approving and running the study:

$astraeus-study-reporter Compare the completed EX20 batch. Separate terminal
access from gateway-route closure, calculate the routed share among rows with
a terminal uplink opportunity, and support every conclusion with the batch or
child-run artifacts.

The assistant helps author the alternative, check the controlled change, operate the grouped study, and interpret the evidence. Astraeus validation, execution, and saved artifacts produce the result.

Results

Both cases completed successfully in a 24.1-second reference run. Each had 6,908 grid-time opportunities with a terminal-to-satellite uplink. The crosslinked mesh routed every one to the gateway, while the in-plane-only case routed 2,171, or 31.4%.

Result	Crosslinked mesh	In-plane only
Gateway route completion among terminal-access opportunities	100%	31.4%
Delivery success	91.0%	38.0%
Area-weighted scheduled service	28.1%	6.95%
End backlog	118 MB	817 MB
Routed latency p95	120 s	240 s
Mean routed hops	4.08	2.79

The maps use the same point-level aggregation as the Streamlit Transport → ISL → ISL Route Fraction by Point view. Each cell shows the share of grid-time requests completed through a positive-hop ISL path; the common gateway is marked by the black diamond. The summary table below retains the conditional route-completion and end-to-end outcome metrics.

Artifacts To Inspect

Artifact	What it shows
batch_summary.json / .csv	Comparable delivery, service, route, hop, latency, backlog, runtime, and status values
cases/.../transport/isl_routes.parquet	One row per grid-time request, route closure, path, waits, hops, latency components, and denial reason
cases/.../transport/isl_summary.json	Topology, eligible edges, route counts, hop distribution, and routing diagnostics
cases/.../transport/transport_summary.json	Admitted and delivered traffic plus end-of-run backlog
cases/.../runspec.json	Fully resolved inputs used by each child run

Interpretation

Cross-plane links connect terminal-visible satellites to gateway-visible satellites in other orbital planes. That increases gateway route completion, scheduled service, and delivery while reducing backlog and tail latency.

The higher mean hop count in the crosslinked case is a reach result: it includes remote paths that the in-plane-only network cannot complete. Compare route closure before interpreting hop count in isolation.

Public Reference Basis

The constellation shape is informed by public Iridium architecture: 66 operational satellites in six polar planes, approximately 780 km altitude, 86.4° inclination, and a crosslinked space mesh. Iridium identifies Tempe, Arizona as its primary commercial gateway location. The case uses idealized Walker phasing, an approximate city reference, and illustrative Astraeus traffic, terminal, RF, capacity, and scheduling assumptions.

Sources: Iridium network overview, Iridium 2025 Annual Report, and FCC Iridium NEXT authorization.