Skip to content

ISL routing

Contact Graph Routing on a Connection Network

ISL routing is how ASTROLAB moves a command or a file across satellites when you opt in. It does not invent contacts. It reads a completed Connection Network and picks a store-and-forward path.

Default everywhere is still Direct (same satellite hears the station, or dumps itself). ISL (CGR earliest delivery) is a policy on Coverage (command) and Latency (dump). Both share one planner. Routing Analysis is a different product: it shows the best route over time for inspection (CGR is one of its criteria); it does not move traffic.

The planner follows NASA/JPL Contact Graph Routing, issued by CCSDS as SABR. Official documents, what that algorithm does not minimise, and why max Delivery delay can stay high while mean drops: Contact Graph Routing.

Open Web App · clocks: Coverage and latency clocks

Two products, one planner

Product Clock What rides the ISL Size
Coverage Discrete facility-tasking Tasking delay (T0 → T1) The order (1 byte) Microseconds. The pass that matters is when the contact opens
Latency dump Delivery delay (T2 → T3) The file (MMFU packet) COMM rates matter

The picture and the dump never share a route. Coverage still owns Look (T1 → T2). Latency never replays Tasking.

Latency also asks the same planner in three other places:

Where What CGR decides
Discrete event assignment When an event is generated, CGR projects the delivery from every spacecraft that can acquire it. Only the earliest makes the file; the others spend no MMFU or radio.
Static IoT Each site is a client node with uplink contacts. CGR picks the uplink, so it picks the acquirer, then the rest of the path. Uplink Data Rate and Max. Concurrent Uplinks are the uplink radio.
Static Session Not CGR: a session is not stored and forwarded. A min-cost flow over the links live at each instant decides who is carried. Continuous session.
flowchart LR
  subgraph cmd [Command T0 to T1]
    GS["Facility"] --> Recv["Receiver sat"]
    Recv --> Img["Imager"]
  end
  subgraph look [Look T1 to T2]
    Img --> AOI["AOI target"]
  end
  subgraph dump [Dump T2 to T3]
    Img --> Neigh["Neighbour"]
    Neigh --> GS2["Any gateway"]
  end

You need:

  1. A Connection Network with spacecraft–spacecraft edges (and spacecraft–facility for dump / uplink). Those ends may be sensors used as lasers or a dump antenna: access uses their FOV and constraints; Routing, Latency dump, command ISL and Session collapse them to the parent bus. ISL keeps one radio per laser; dump windows on the same bus are unioned.
  2. Policy ISL (CGR earliest delivery) on Coverage and/or Latency.
  3. COMM rates on the spacecraft and facility. Imaging sensors keep only Acquisition data rate for Coverage.

COMM fields that size a hop

Editor field Asset Role
ISL Data Rate Spacecraft Pair hop = min of the two buses
Downlink Data Rate Spacecraft X-band dump from this bus
Max. Concurrent ISL Links Spacecraft CGR-ETO / Session: parallel ISL transmits (default 1). Per CN laser when those sensors are the ISL ends; per spacecraft when the CN rows are the buses.
Max. Concurrent Downlink Links Spacecraft CGR-ETO: parallel X-band dumps (default 1). Independent of ISL.
Max. Concurrent Uplinks Spacecraft Static Latency only: ground clients received at once (IoT sites, Session users). Not a dump radio.
Processing Latency Spacecraft Added when a file arrives on this bus (ISL relay, Static IoT uplink); the bus forwards only after it. CGR includes it in the projected delivery.
Max. RX Data Rate Facility Ground ingest; hop = min(bus downlink, this)
Max. TX Data Rate Facility Ground → spacecraft command uplink
Max. Concurrent RX Links Facility Spacecraft dumping into this GS at once (default 999, effectively no limit)
Processing Latency Facility Added to dump delivered_at. CGR includes it when comparing stations.

What CGR actually does

Contact Graph Routing (CGR) is a per-message earliest-arrival search on the time-varying contact plan (the CN access_by_pair windows). It is not “fewest hops” and not a live BFS at every MMFU step. The official rule (Burleigh / SABR) is earliest projected delivery, then hop count only as a tie-break — Contact Graph Routing.

At the instant the message is ready (order generated, or file closed onboard):

  1. Build remaining contacts (start, end, residual volume from COMM rates).
  2. Search for the earliest time the last byte arrives, counting the wait until the next contact, the radiation size/rate, and the radio intervals below. If two routes deliver at the same instant, the one with fewer hops wins, then the proximate node with the smaller id. There is no hop budget.
  3. Hand the resulting node list to the data plane.

Direct does not run this search. A command is one hop, ground station → spacecraft. A dump is one hop, this bus → a facility it can see.

Who hears the GS is the uplink list, and it applies to Direct and to CGR. Same as acquirers means every acquiring spacecraft may take the order from the station. Selected spacecraft means only those buses have an uplink radio. A satellite outside the list is not commanded on Direct, even if it is an acquirer and even if it can see the target. CGR may still relay from a listed receiver to an acquirer that never sees the station. The command radio is always a spacecraft: a camera uses its parent bus. Look still uses the acquirer, so a narrow camera and a bus that sees the limb are different clocks.

CGR-ETO (radio occupancy)

Classic CGR assumes the contact is empty — the bundle leaves at contact start. ASTROLAB uses CGR-ETO: each radio stores the intervals it is already radiating, and each contact stores the intervals already queued on that contact. The next bundle takes the earliest start where [t, t + size/rate) fits inside the contact, misses that contact’s queue, and misses at least one free radio. Delivery is the end of that radiation: the contact plan has no range, so one-way light time is 0 (CGR-ETO). The radio is busy only while radiating. The standards write-up, including why a booking at 01:30 does not erase a pass that ended at 00:40, is on that same page.

Radio Used when the hop ends at COMM field Default
ISL A spacecraft (relay, or a command to a bus) Max. Concurrent ISL Links (per CN laser if the mesh is sensors; else per bus) 1
X-band A facility Max. Concurrent Downlink Links 1

A neighbour that is free can take a different message on a different contact. X-band and ISL do not block each other. Two radios of the same class can transmit at once only on two different contacts. The same contact is one queue.

A command is 1 byte. At 2 Mbps that radiation is 4 µs, so the byte does not fill the pass. For each event every imager is tried first without booking the radio. Only the order that is actually sent — the one that makes the earliest look — reserves its route. If the geometric Direct look is as early, that Direct look wins and the multi-hop route is left free. Events are planned in birth order.

A Latency file is different: every real file reserves the hop it is about to radiate. Continuous and Discrete share one timeline. The spacecraft that holds the file asks CGR, and only that next radiation interval is booked. The neighbour asks again when the file arrives. A station in view is that next hop when its delivery is the earliest, so the rest of a path is not left booked.

After the decision: the next hop is what radiates

The dump does not walk a route that was frozen when the file was born. It radiates the hop CGR just returned from the spacecraft that has the bytes. The events are the birth of each file, each contact edge, and the end of each radiation (size / rate). There is no fixed step moving bytes.

flowchart TD
  Ready["File at this spacecraft"] --> CGR["CGR from this node"]
  CGR --> Hop["Reserve next radiation only"]
  Hop --> Radio["Radiate size/rate"]
  Radio --> Where{"Arrived at a station?"}
  Where -->|yes| Done["Delivered"]
  Where -->|no| Ready

Practical cases

1. Polar dump, imager over ocean

SAT-01 is over the Pacific with a 100 MB scene. Inuvik is not up. SAT-02 already sees Svalbard.

  • Direct: SAT-01 waits until it sees a polar station.
  • CGR: SAT-01 → SAT-02 → Svalbard. Delivery delay is ISL wait + transmit + SAT-02’s X-band.

That is the usual win: mean dump latency drops; hops used > 1.

Only SAT-01 may hear the tasking station. The target is in SAT-07’s swath.

  • Direct: only SAT-01 can take the order and look — yield collapses.
  • CGR command: station → SAT-01 → … → SAT-07. Tasking delay is until SAT-07 has the order. Look delay is SAT-07’s first see of the AOI after that. The picture is still taken by the acquirer, not by the uplink radio.

Set Who hears the GS to the uplink buses on both policies, and leave Acquirers as the cameras. If Direct stays on “same as acquirers”, every camera is treated as an uplink radio and the No-ISL case is no longer the single-uplink case.

3. A long path can still set the maximum

CGR minimises arrival time, not hop count. A path with more hops that delivers earlier is the one that is kept. Then:

  • Residual volume is greedy — that path consumes contacts another file needed later.
  • ETO parks the second file behind the first on the same ISL radio.
  • At 250 Mbps a 100 MB hop is ~3.2 s; at 1 Gbps ~0.8 s. Queueing shows up as max Delivery delay spikes, not as a plot bug.

Hop count on the route is a result. It is not an input. Compare mean, P95, max, lost at T_end, and hops used. The published CGR-Hops variant (fewest hops among routes that meet a deadline) is not what this policy runs — Contact Graph Routing.

4. Local dump beats a planned ISL

CGR said SAT-01 → SAT-02 → Inuvik. Mid-route SAT-01 rises over Troll.

MMFU dumps to Troll now. Delivery delay is shorter than following the rest of the plan. The lifecycle target is the station that actually received the file.

5. Direct still wins when the imager already sees a gateway

If SAT-01 is over Svalbard at Acquisition, Direct and CGR (with local dump) match. ISL cannot beat geometry you already have.

6. Two lasers and a dump dish

A flight-like bus often has three comm terminals plus a camera. Put the terminals on the Connection Network; leave the camera on Coverage.

flowchart LR
  subgraph sat [SAT-01]
    Cam["Nadir camera"]
    Plus["+V laser"]
    Minus["-V laser"]
    Dish["X-band dish"]
  end
  Cam --> Cov["Coverage Look / produce"]
  Plus --> N1["Neighbour ahead"]
  Minus --> N2["Neighbour aft"]
  Dish --> GS["Svalbard"]
Row you draw Who uses it Radio
+V-01 → +V-02 (and the aft pair) Latency dump, Session, command ISL, Routing Max. Concurrent ISL Links on SAT-01, per laser. +V and −V can radiate together.
Dish-01 → Svalbard Direct or CGR dump Max. Concurrent Downlink Links on SAT-01 (one X-band pool).
Nadir camera Coverage only Acquisition data rate on the sensor. Not an ISL hop.

CGR still routes SAT-01 → SAT-02 → Svalbard. The hop SAT-01 → SAT-02 is open when either laser sees the neighbour; occupancy is the laser that opened that window. A single laser that sees two neighbours shares its pool (max = 1 serialises those two hops).

If you draw All Satellites → All Satellites instead of the lasers, access is bus line-of-sight and Max. Concurrent ISL Links is the spacecraft total. Same planner; coarser geometry.

How to declare the rows: Connection Network — sensors as terminals.

Limits (not a plotting bug)

CGR does not minimise the worst file. A polar gap with no neighbour in view of a gateway, a single ISL radio, or a long path that then misses a pass can leave max Delivery delay near Direct’s own next-orbit wait even when mean has dropped to seconds. Lost files at scenario end are worse than max: they never arrived.

That is the SABR / ION objective, not an ASTROLAB-only quirk. Geometry and one radio still set the worst file; the dump does ask CGR again at each spacecraft that holds the file. Limits and how to read a Dashboard spike: Contact Graph Routing.

Edge cases (read these before you trust a spike)

What you see Likely cause What to check
CGR max ≫ Direct max, mean still better One file queued on a busy ISL radio (ETO) or a long CGR path that then waits hops used, which GS received, packet time vs contact
hops used on the lifecycle How many contacts that file actually crossed. It is a result, not a cap Policy is CGR; the route list on the message
Overflow / lost at T_end MMFU full, or file still onboard at scenario end Capacity, last dump contact
0 delivered / no acquisition sources Coverage Look empty (FOV, pointing, constraints) or no CN path to a selected GS Coverage n_sources, CN sat–GS windows
Command yield stuck at “only SAT-01” Policy still Direct and only SAT-01 is an uplink radio, or the Connection Network has no sat–sat edges Who hears the GS, acquirers, CN ISL edges
Direct and CGR command delays match on a sparse uplink Direct was left on “same as acquirers”, so every camera was allowed to hear the station The spacecraft list is the same on both policies
ISL does nothing No sat–sat edges on the CN, only an imaging sensor on the CN, or rates 0 CN access pairs (lasers or buses), ISL Data Rate on both buses (hop = min of the two)
Neighbour takes a file it should not Should not, on CGR dump Route stick: ISL only to planned next

What ISL does not do

  • It does not change Link RF margins.
  • It does not paint Continuous / Static Coverage. Those stay geometry.
  • It does not replace Routing Analysis, which compares route criteria over time.
  • It does not jointly optimise all files as a single multi-commodity flow in the UI (CGR is per message).
  • Command ISL does not fly the image to the imager — only the order.