ChronoRoute

Methodology

Where every number comes from

This project studies a routing protocol on the geometry of a real constellation, but much of what happens inside a real satellite network is not public. So every number and every visual on this site says where it comes from, and we do not show numbers we do not have.

Provenance

The four labels

Each label has its own colour and its own shape, so it can be read without colour.

Provenance labels used on this site
Label Meaning Example in this project
Label: REAL Public or measured data, real physics computed with real code on REAL inputs, or the exact output of our real code, such as the bytes of a header. CelesTrak orbital elements, satellite positions computed from them with SGP4, the speed of light, the bytes of a T-CRH.
Label: DERIVED Computed by our code from REAL inputs by an inference or a choice that could be made differently. Shells and orbital planes inferred from the elements, the colour groups, a planned route and its budgets.
Label: MODELLED Our assumption, used because the truth is not public. Which satellites are joined by laser links, the traffic, the failures.
Label: UNKNOWN Not public, so we do not claim it. Starlink's real routing. Starlink does not use T-CRH.

Rules we follow

  • A value is only as strong as its weakest input. A route is computed by our code, so the project’s shared label table calls it DERIVED, but it runs over MODELLED laser links: it is always shown together with the MODELLED label and called hypothetical.
  • The labels come from one table in the code (sim/chronoroute/labels.py), used by every data file the project writes; this site’s copy is checked against it on every build.
  • We do not show placeholder or invented numbers. Where data does not exist yet, the page says so.
  • Starlink’s real routing is UNKNOWN. Starlink does not use T-CRH; we use its public orbits only as a realistic test geometry.

Inventory

What is real, derived, modelled and unknown

Every input of the experiments, with its label and where it comes from.

Inputs and their provenance
What Label Where it comes from Notes
Starlink orbital elements Label: REAL CelesTrak supplemental GP (SupGP) element sets for Starlink, which CelesTrak derives from ephemerides published by SpaceX. Each snapshot is pinned with the sha256 hash of the raw download. Elements are a fitted orbit description, not a measured position.
Satellite positions at a given time Label: REAL SGP4 on REAL elements SGP4 propagation of those elements (satellite.js on this site; the sgp4 package in the Python simulator): real physics computed by real code from real data, as the project’s shared label table records it. A prediction, not tracking data: SGP4 is an approximation, and its error grows with the time since the element set’s epoch. We quote no accuracy figure, because we have not measured one for these elements. The two SGP4 implementations agree to within 10 m (tested on every build).
Speed of light Label: REAL physical constant 299,792,458 m/s in vacuum, exact by the definition of the metre. The only input of a propagation delay that is not a position.
Propagation delay of a link Label: DERIVED The distance between the two nodes, from their SGP4 positions, divided by the speed of light. A delay is only as strong as the link it belongs to: the delay of a MODELLED laser link is MODELLED.
Shape of the Earth Label: REAL public standard The WGS84 ellipsoid, the reference shape that GPS uses. Used for altitudes and ground positions on this site, and for the line-of-sight rule below.
Line of sight between two nodes Label: MODELLED 80 km clearance A laser link is allowed only while the straight line between the two satellites stays at least 80 km above the WGS84 ellipsoid, to keep it clear of the atmosphere. The geometry is exact, but the 80 km clearance is our choice (Hypatia’s rule), so the rule as a whole is MODELLED. Applied by the Python topology code at every time step and by this site’s route planner at the instant you pick.
T-CRH header bytes Label: REAL defined by our code The exact bytes our encoder produces, pinned byte for byte by the golden test vectors in spec/golden/. This site’s TypeScript engine is checked against every vector when the site is built (see the protocol page). The Python reference has a golden-vector test that runs in the project’s continuous integration. The ns-3 module has a test suite for the same vectors (make ns3-test), which is run locally, not in continuous integration.
Orbital shells (colour groups) Label: DERIVED Grouped by our code from each element set’s inclination and mean altitude. The globes colour the satellites by these groups. A grouping for display, not SpaceX’s own shell assignment. Public fleet statistics, such as Jonathan McDowell’s, are an independent reference.
Orbital planes Label: DERIVED Inferred by our pipeline from the elements: satellites are grouped into shells by inclination and altitude, and into planes by their ascending node; within a plane they are ordered by argument of latitude. SpaceX does not publish its planes. Satellites that fit no plane are left out of routing, and the route planner says how many.
Laser inter-satellite link topology Label: MODELLED Grid-4 (also written +Grid), a common research assumption, on those inferred planes. Each satellite links to the satellites ahead of and behind it in its plane and to at most one satellite in each neighbouring plane (a one-to-one nearest match). Links between planes are off above 70° latitude. Four links per satellite is an assumption from the research literature (Hypatia, after SpaceX regulatory filings), not knowledge of today’s network. Which satellites Starlink links, and how often those links change, is not public.
Ground links Label: MODELLED 25° mask assumed A city sees a satellite at least 25° above its horizon and connects to the four highest. The 25° value is from Starlink’s regulatory filings, as used by Hypatia; which visible satellites a terminal really uses is not public. Cities are placed on the WGS84 ellipsoid from Natural Earth coordinates (REAL).
Processing delay per hop Label: MODELLED 0.5 ms added to the light time of every hop when routes are planned. The existing model’s value; not measured on a real satellite.
Link capacities and queues Label: MODELLED Chosen per experiment and stated with it. Not public for Starlink.
Traffic Label: MODELLED Who sends how much to whom, and when: chosen per experiment and stated with it. Not public for Starlink.
Failures and slowdowns Label: MODELLED Which links go down or become slow, when, and for how long: chosen per experiment and stated with it. The up-but-slow case is the one T-CRH is designed to catch.
Starlink’s real routing Label: UNKNOWN Not public. We never claim it. Starlink does not use T-CRH; its public orbits serve only as a realistic test geometry.

Orbit data

From public elements to positions

Label: REAL elements Label: REAL positions (SGP4)
  1. We download CelesTrak’s supplemental GP (SupGP) elements for Starlink. CelesTrak derives them from ephemerides published by SpaceX. The download time is taken from the HTTP Date header, and the raw file is kept with its sha256 hash.
  2. Element sets whose epoch is more than three days older than the download are left out. Every remaining set must initialise and propagate with SGP4 at the download time; any that fail are left out too. The snapshot’s manifest records how many were left out and why.
  3. SGP4 propagates each element set to the time you are looking at. Its error grows with the time since each element set’s epoch, so the site always shows how old the snapshot is.

Sources

Data, standards and prior work

Data and standards

Prior work

Limitations

What this work does not show

  • It is a simulation. Results will come from our Python simulator and ns-3 module, on modelled links, traffic and failures. Nothing here is measured on Starlink.
  • Orbits are a snapshot. SGP4 positions get less accurate as the element sets age.
  • Clocks must agree. The check assumes every node knows GPS time. A node whose clock is off by some amount shifts its verdicts by the same amount.
  • The alarm comes after the fact. The node at the far end of a slow link notices; the packet has already crossed that link.
  • Resolution is one unit. Lateness shorter than the deadline unit, or hidden by the slack S, is not seen. Slack trades missed problems against false alarms, which is exactly what the experiments will measure.
  • A hop budget is at most 255 units (25.5 ms at the provisional default unit of 0.1 ms). A longer budget is clamped, the SAT flag is set, and that deadline is then earlier than its budget.
  • Three header fields change in flight (Segments Left, Flags, Dev Hop): two more mutable fields than RFC 9631 allows, since only Segments Left changes in a CRH. This matters for IPsec AH.
  • Experimental and closed-domain. T-CRH uses an experimental routing type (253) and is meant for a single operator’s network, not the public Internet.
  • The fallback can fail. Greedy geographic forwarding can reach a node with no neighbour closer to the destination, so falling back does not guarantee delivery.

Results

Experiment results

  • Pre-registered experiments. Six experiments (E0, E1, E2, E4, E5, E16) were registered before they ran and analysed with the registered rules. Each has its own page on the experiments page with the question, the hypothesis, the verdict, charts with confidence intervals, the data and its run manifest (schema chronoroute.manifest/1, in spec/schemas/): the code commit, the configuration and its hash, the random seeds, the orbit snapshot, library versions and the SHA-256 hash of every output file.
  • Corrected semester results. The earlier semester code had known bugs. Its experiments have been re-run on the bug-fixed code, each with a provenance manifest, in results/legacy-v0.9. The results changelog lists every old headline number next to the corrected one, says why it changed, and names the claims that had to be retired. The original, uncorrected figures are kept in the repository only for that comparison.
  • Course milestone. T-CRH in ns-3 on the real 53.2° / 463 km Starlink shell, with link delays and states that change during the run, inside real IPv6 Routing Type 253 headers: docs/course-milestone.md, with the run folders in results/course-milestone.

The numbers of the semester results and the course milestone are not repeated on this site, so they cannot drift from the files: read them, with their limitations, in the documents above.

The protocol itself is pinned by golden test vectors; see the protocol page. The code is in the repository.