Inter-satellite links

What you will accomplish

An end-to-end latency for traffic routed through the constellation rather than bounced off a single satellite, and a sweep that shows how much of that answer depends on an assumption the default leaves unstated.

Prerequisites

• The API running, with a constellation registered.
• Two ground stations that a single satellite cannot see at once.

Steps

curl -s -X POST localhost:8080/isl \
  -H 'content-type: application/json' \
  -d '{
    "constellation_id": "ph1",
    "duration_hours": 2,
    "step_seconds": 60,
    "ground_stations": [
      {"id":"nyc","name":"New York","latitude_deg":40.7,"longitude_deg":-74.0,"altitude_km":0.01},
      {"id":"ldn","name":"London","latitude_deg":51.5,"longitude_deg":-0.13,"altitude_km":0.02}
    ],
    "latency_pair": ["nyc","ldn"]
  }'

{
  "satellite_count": 60,
  "sample_count": 121,
  "sample_index": 0,
  "edges": [/* 230 feasible crosslinks at this sample */],
  "availability": [/* 540 pairs over the window */],
  "latency": {
    "latency_ms": 32.878924630913104,
    "hops": 4,
    "route": ["nyc", "ph1-s0-p04-sat03", "ph1-s0-p05-sat02", "ph1-s0-p00-sat03", "ldn"]
  },
  "latency_unreachable": false
}

230 edges: min 316, median 4175, max 5015 km
  edges within 1000 km:   6
  edges within 2000 km:  22
  edges within 3000 km:  48
  edges within 4000 km: 102
  edges within 5000 km: 222

The default has no range limit

Nothing in the response flags this. The number is correct for the model and the model contains an assumption nobody stated.

Sweep the constraint

# repeat with "max_range_km": 5000, 4500, 4200, 4000, 3500, 3000

Three regimes, and the transitions between them are abrupt.

This is why sweeping matters and why a single run reassures you wrongly. Tightening the assumption by 10 percent produced no visible change three times in a row, and then produced total failure.

Reading it as a design result

The honest statement about this constellation is not “New York to London in 32.9 ms”. It is:

A 60-satellite Walker shell at 550 km can route New York to London only with crosslink terminals good for at least about 3500 km. Below that the mesh does not span the ocean. Between 3500 and 4500 km the path costs 5 hops and 40.4 ms. Above 4500 km it costs 4 hops and 33.0 ms.

That sentence is a requirement on the terminal. The original number was a latency figure that quietly contained one.

If the terminals you can actually buy fall below the threshold, no amount of routing cleverness helps. The fix is orbital: more planes, more satellites per plane, or a different altitude. That is a constellation-design decision arriving from a link-hardware constraint, and it is better found now than after the bus is selected.

The other parameters

sample_index deserves attention. The edges array is the mesh at one instant, while availability covers the whole window. A route reported at sample 0 is not a route that exists continuously, and latency_unreachable is likewise a statement about the sampled instant rather than a guarantee about the window.

For a service-level claim, sweep sample_index across the window and report the worst case, in the same spirit as converging a coverage grid.

What this model does not include

The same caution appears in the design solver, where the ISL topology option reports an optimistic bound rather than a predicted latency.

Checklist

1. Did you set max_range_km to something a real terminal achieves?
2. Did you sweep it, rather than trusting one value?
3. Did you check more than one sample_index?
4. Are you quoting propagation delay as though it were end-to-end latency?
5. Does the route survive at the worst instant, not just the first one?

Next steps

• ISL API reference for the full schema.
• Closing a link for whether the individual hops close at all, which this analysis assumes rather than checks.