LEO-PNT in Kshana

LEO-PNT is positioning, navigation and timing (PNT) from satellites in low Earth orbit (LEO), alongside or instead of the medium Earth orbit (MEO) global navigation satellite systems (GNSS) such as the Global Positioning System (GPS) and Galileo. This page ties together every LEO-PNT kind and scenario of the engine: what each computes, the bands and signal presets and where their numbers come from, what the navigation message carries, what is VALIDATED and what is MODELLED, and how to run each scenario. The kind pages go deeper:

System-agnostic first#

The engine is a generic LEO-PNT simulator. Any constellation (a Walker pattern, explicit orbital elements, a two-line element set (TLE) through the Simplified General Perturbations 4 (SGP4) propagator, or a designed single pass), any signal design (any band, any mix of binary phase-shift keying (BPSK), binary offset carrier (BOC) and frequency-division multiple access (FDMA) components), any navigation-message model. Named systems are optional presets: data files, each with its source, which fill only what a scenario leaves out. Every capability, test, oracle and bundled scenario runs with no Celeste data present.

The Celeste IOD (in-orbit demonstration) preset is one optional preset among them. Its signal parameters were presented at the ESA NAVISP (European Space Agency Navigation Innovation and Support Programme) LEO-PNT workshop, 2026, and have no public source yet. Every workshop-derived number of the engine lives in one file, src/celeste_iod.rs, which build.rs compiles in only when it exists, and in the repository-only scenarios scenarios/*celeste-iod*.toml. Deleting that file and those scenarios withholds the preset with no source edit; every other test, oracle and scenario runs without it (tests/workshop_preset_isolation.rs guards which files may name it). This page gives none of its numbers.

The kinds and how they connect#

The chain hands values in code (see End-to-end LEO-PNT chain below): the signal design sets the pass band's EIRP (equivalent isotropically radiated power) split and tracked chip rate; the pass gives the tracked C/N0 and code jitter; the navigation message's SISRE and the pass C/N0 weight the LEO measurements of the fused fix.

Bands#

The generic designs use public band centres; each is REPRESENTATIVE, not any system's signal (data/leo-signals/generic-bands.toml, generic-c-band.toml).

BPSK(n) is binary phase-shift keying at n × 1.023 Mchip/s. The delay ratio is (f_L/f)² with f_L = 1191.795 MHz. The free-space loss grows by 20·log10(f/f_L) at the same range (−8.2 dB at UHF, +6.4 dB at S, +12.5 dB at C).

Signal and system presets#

Every preset marks its numbers PUBLIC (with a URL), REPRESENTATIVE (a documented design choice, never a claim about a real system) or WORKSHOP, and the result of every run that uses one says which.

The navigation message#

A LEO navigation message (LEO-NAVMSG.md) carries four parts, the structure the Galileo Open Service Signal-in-Space Interface Control Document (OS SIS ICD) and the published LEO proposals share:

The binary frame is Kshana's own documented encoding modelled on these components, not any system's bit layout. RINEX 4.02 defines no LEO navigation records, so the RINEX-style export is a documented Kshana extension (prior art: arXiv 2401.17767).

Resilience#

The spoofing monitors, their statistics and their limits are on LEO-PASS.md. The multi-band waterfall with a different jammer per band is multi-band-jamming-waterfall (LEO-SIGNAL.md).

One scenario per experiment focus area#

The eight experiment focus areas of the Celeste IOD call for third-party experimentation (ESA Open Space Innovation Platform, OSIP) are generic LEO-PNT questions; each has a system-agnostic scenario:

One scenario per end-user vertical#

Each vertical is a campaign chain on one timeline, so it animates, and each has a leo-pass member, so it exports geometry (see Running).

VALIDATED and MODELLED#

A row is VALIDATED only when a test reproduces a published setup and pins the published figure within a stated tolerance; everything else is MODELLED with its rationale (VERIFICATION-MATRIX.md, MODELLED-RATIONALE.md).

VALIDATED LEO-PNT rows:

• closed-form band-limited signal power and early-late code-tracking jitter at published operating points (Betz and Kolodziejski 2009), with the Gabor bandwidth and SSC cross-checked;
• the maximum Doppler of a LEO navigation satellite (Xona Pulsar X1 32–34 kHz, Iridium ±36 kHz), and the static-user Doppler envelope against arXiv 2509.19551 Table 1;
• ITU-R P.838-3 rain coefficients, P.618-14 rain attenuation and tropospheric scintillation, and P.2109-2 building entry loss against the ITU-R Study Group 3 validation data;
• the first-order ionospheric delay scaling and free-space loss (IS-GPS-200 group-delay ratio, the Friis form);
• the global-average SISRE weights (Montenbruck et al. 2018), the Galileo ICD user algorithm against RTKLIB on real broadcast ephemerides, and CRC-24Q against its catalogue check value.

MODELLED LEO-PNT rows: every signal design and band trade, the multi-band waterfall, every pass and link budget as a whole, the presets, low-energy fixes, the message fitter and formats, Doppler and joint positioning, PPP convergence, NTN positioning, time transfer, polar coverage, the end-to-end chain, the spoofing monitors and ionosphere sounding, and every campaign (a campaign composes kinds and adds no physics; its composition identities are tested, CAMPAIGNS.md). No LEO C/N0, ranging error or positioning figure is compared with a measurement of any satellite.

Running a scenario#

Every scenario above is bundled: kshana example <name> prints it, and

kshana scenarios/<name>.toml --animate html --export all

writes, next to the file, the result (.result.json), the chart (.chart.svg), the advanced report (.report.html and .report.json, with a section that embeds the animated run and lists the exports), the interactive player (.animation.html) and the exports. What applies depends on the kind:

• a run with a time axis animates: leo-pass epochs, the spoof.series of a spoofing run, spectrum timelines, leo-pvt joint epochs and timing traces, leo-ppp error curves and every campaign chain. A sweep or a composition has no time axis: --animate refuses it with exit status 1 and then the command writes nothing at all, so run the eight sweeps and compositions above (leo-resilience-multiband-diversity, leo-resilience-spoof-monitors and every leo-focus-* scenario except leo-focus-science-iono-sounding) without --animate;
• leo-pass and leo-pnt-chain export CZML (the Cesium Language), KML (Keyhole Markup Language), GeoJSON and STK (Systems Tool Kit) ephemerides of the pass geometry; a campaign exports each member that has geometry as its own file set, the member label in the file name (<name>.<member>.czml), so every vertical exports its LEO passes; the other LEO kinds state why a format does not apply (INTEROP.md).

The remaining LEO scenarios, by kind (details on each kind's page):

The optional scenarios are repository-only and are withheld with the Celeste preset file.

Two of them sit in other kinds. leo-pnt-mega-shell (constellation-design) sizes a 5000-satellite LEO-PNT constellation in four illustrative Walker shells: availability 99.22 % at a PDOP of 3 or less above a 20° mask, median PDOP 1.11 and 39.4 satellites in view on average over 648 grid points and 12 epochs. slot-timing-ocxo-leo (slot-timing) asks how long the datasheet OCXO of a LEO smallsat stays inside a 100 ns slot guard at k = 3 after its last GNSS fix: the guard breaks 650.8 s after a fix, so it needs a fix at least every 645.8 s (133.8 a day), with random-walk frequency noise the dominant term.

End-to-end LEO-PNT chain#

The leo-pnt-chain kind (src/leo_pnt_chain.rs) follows one LEO-PNT system from its signal design to the user's position. Each stage is the engine's own kind, run on its own table of the chain scenario, and the chain hands values from one stage to the next in code:

A value is handed on only where the downstream table leaves it unset, and every hand-off is listed in the result's handoffs array with its value, unit and target. A band of [pass] must name the design (signal = "<design>"); that is how a leo-pass band carries any leo-signal design on its own too: it takes the design's centre frequency, transmit bandwidth and tracked chip rate, splits its EIRP across the components, and reports the tracked-component C/N0 and the band-limited coherent early-late code-tracking jitter (Betz and Kolodziejski 2009; half-chip spacing, 1 Hz loop, 20 ms) at every epoch.

Scenarios:

kshana scenarios/leo-pnt-end-to-end.toml --animate html --export all

writes the result, the chart, the advanced report (which embeds the animated pass and links the exports), the interactive player, and CZML (the Cesium Language), KML (Keyhole Markup Language), GeoJSON and STK (Systems Tool Kit) ephemeris files of the pass geometry.

The chain is MODELLED: it adds no physics, and each stage keeps its own labels. The positioning stage's C/N0 model is a straight line in sin(elevation), so a pass-specific shape is reduced to two numbers; the message stage models no orbit determination, which is why od_sisre_m is a stated input (0.25 m in the bundled scenarios, representative of the decimetre-level on-board orbit determination and steered chip-scale clock the ATOMIC payload reports: https://insidegnss.com/first-steps-toward-a-fully-operational-leo-pnt-payload/).