lunar-jamming (scenario kind)

Scenario kind of the engine v0.38.0, family Lunar and cislunar. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Lunar-native RF jamming: per-satellite jammer-to-signal ratio, effective C/N₀ and loss of lock for a selenographic surface user under a lunar surface (or raised) jammer, over the illustrative public-source Moonlight/LCNS-class lunar-orbit constellation. Composes the existing open jamming physics (jamming::j_over_s_db, effective_cn0_dbhz, rx_antenna_gain_db, lock_status, q_factor) with the existing lunar sky geometry (lunar_service::LunarConstellation + topocentric, lunar::selenographic_to_mcmf); no geometry or radiometry is re-derived. Unlike the Earth jamming kind, the signal leg is NOT a fixed received power: each satellite's isotropic received power is its own link budget EIRP − FSPL(slant range), so the J/S varies satellite by satellite with lunar range and elevation. Reports ONE ROW PER VISIBLE (epoch, satellite) LINK — azimuth, elevation, slant range, both received powers the J/S is the difference of, the J/S, the nominal and effective C/N₀ and the lock status — plus aggregate figures of merit beside (never in place of) that table, and the same table as a CSV artifact. Every emitted numeric field carries a unit and a provenance class. VALIDATED sub-results carry their source module oracle (the anti-jam equation and J/S link of Kaplan & Hegarty §9.4, externally referenced in tests/gnss_denied_jamming_resilience_reference.rs; the lunar geometry of lunar_service). The composition itself is cross-checked against an independent two-link-budget path (linkbudget::received_signal_power_dbw, a different free-space-loss expression) to 1e-9 dB. MODELLED: the illustrative constellation, the representative EIRP / jammer power / antenna gains / noise temperature, and the absence of terrain shadowing, multipath, AGC dynamics and adaptive nulling. Not a certified denial-of-service product. With a jammer configured the report also carries a DENIAL CONTOUR WITH AN UNCERTAINTY BAND rather than a contour read off one scalar: the full measured wanted-signal C/N₀ distribution over the per-satellite table (n, min, p05, p25, median, p75, p95, max, mean, sample stdev, and the sample's own asymmetry), and the contour evaluated at each of those order statistics under BOTH denial criteria the engine recognises — the incumbent power-ratio one (J/S = 30 dB, as in attack-surface and tracking-loop) and the loss-of-lock one (effective C/N₀ falling to tracking_threshold_dbhz, the criterion this report's own status column uses) — on both axes of the denial plane (required jammer EIRP at the scenario standoff, denial standoff at the scenario EIRP). The band edges ARE contour(p05) and contour(p95), the same closed-form map applied to the sample's own quantiles: not a sigma fitted to the sample and not median ± k·stdev, with stdev emitted for continuity and used by nothing. A quantile already at or below the tracking threshold has no finite denying J/S and its loss-of-lock columns are null with a counted reason, never a clamped radius.

One run of scenarios/lunar-jamming.toml summarises as: lunar-jamming | 4 sats, 12 epochs, 38 links from (-89.67, 129.78) | J/S 33.651..36.668 dB (mean 35.622) | 0 LOST | availability 0.167 of 0.167 nominal

Inputs#

From the schema (kshana kinds --json):

• Required fields: none
• Optional fields: n_sats, sma_km, eccentricity, inc_deg, argp_deg, site_lat_deg, site_lon_deg, site_alt_m, horizon_hours, step_min, elev_mask_deg, sat_eirp_dbw, carrier_hz, chip_rate_hz, user_boresight_gain_dbi, temp_k, tracking_threshold_dbhz, degraded_margin_db, jammer

The example scenarios/lunar-jamming.toml sets, among others:

Run it#

kshana scenarios/lunar-jamming.toml

What it gives#

The scalar results of that run, with the units the engine states:

Evidence#

MODELLED: the verification matrix rows that name this kind.

• MODELLED Lunar-native jammer-to-signal ratio, effective C/N₀ and loss of lock for a selenographic surface user under a lunar surface (or raised) jammer, over the illustrative public-source Moonlight/LCNS-class constellation.
• MODELLED The lunar-jamming report no longer rests its denial contour on one scalar.

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

• MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED
• PARTNER Not provided — Kshana models signal performance, not payload/antenna hardware. Oracle (NoneKind): none: a partner-owned discipline, with no module and no test by design
• MODELLED Lunar-native jammer-to-signal ratio, effective C/N₀ and loss of lock for a selenographic surface user under a lunar surface (or raised) jammer, over the illustr. Oracle (ReferenceImpl): Composition cross-check against an independent in-repo code path: every per-link J/S is re-derived as the difference of two link budgets computed with linkbudget::received_signal_power_dbw, whose free-space loss is the single expression 20·log10(4πRf/c) rather than the three-term sum jamming::free_space_path_loss_db uses — the two agree to < 1e-9 dB on every row (measured worst case 7.11e-14 dB, i.e. float round-off)
• MODELLED The lunar-jamming report no longer rests its denial contour on one scalar. It emits the full measured wanted-signal C/N₀ distribution over the per-satellite t. Oracle (InternalConsistency): Internal consistency against the engine's own forward functions, which is all this capability can honestly claim. Every contour point is a closed-form inversion, and each inversion is checked by pushing its answer back through the FORWARD function the report's own rows were scored with: the J/S column through jamming::effective_cn0_dbhz (which must return tracking_threshold_dbhz to < 1e-9 dB-Hz), the standoff column

Limitations#

What the run's own report says is not modelled or not validated:

• MODELLED: the illustrative constellation, the representative EIRP / jammer power / antenna gains / noise temperature, and the absence of terrain shadowing, multipath, AGC dynamics and adaptive nulling. (kind catalogue (kshana kinds --json))
• MODELLED. The constellation is the illustrative, public-source Moonlight/LCNS-class geometry (not the real ephemeris; no affiliation or endorsement implied), and the interference model is a link budget: no terrain shadowing of the jammer (a first-order effect in south-polar terrain), no multipath, no AGC near/far dynamics, no adaptive nulling, no acquisition-vs-tracking hysteresis. (scenario file comment, lines 26 to 30)
• Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))
• Lunar surface-navigation RF jamming (per-satellite J/S) is MODELLED, not validated: checked against a separate implementation in this same codebase — independent of the unit under test, but not externally authoritative. (verification matrix (docs/MODELLED-RATIONALE.md))
• Lunar denial contour with an uncertainty band from the measured C/N₀ spread is MODELLED, not validated: checked against its own closed-form / analytic identity — catches transcription and coefficient errors, but is not an external oracle. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#

• Family page: Lunar and cislunar
• All kinds: KINDS.md
• Topic page: integrations.md