LEO-PNT dans Kshana

LEO-PNT désigne le positionnement, la navigation et la synchronisation temporelle (PNT) à partir de satellites en orbite terrestre basse (LEO), en complément ou à la place des systèmes mondiaux de navigation par satellite (GNSS) en orbite terrestre moyenne (MEO) tels que le Global Positioning System (GPS) et Galileo. Cette page relie chaque type de scénario et chaque scénario LEO-PNT du moteur : ce que chacun calcule, les bandes et les préréglages de signal et l'origine de leurs nombres, ce que porte le message de navigation, ce qui est VALIDATED et ce qui est MODELLED, et comment exécuter chaque scénario. Les pages des types de scénario vont plus loin :

D'abord indépendant du système#

Le moteur est un simulateur LEO-PNT générique. N'importe quelle constellation (un motif de Walker, des éléments orbitaux explicites, un jeu d'éléments à deux lignes (TLE) passé dans le propagateur Simplified General Perturbations 4 (SGP4), ou un passage unique conçu), n'importe quelle conception de signal (n'importe quelle bande, n'importe quel mélange de composantes à modulation par déplacement de phase binaire (BPSK), à porteuse à décalage binaire (BOC) et à accès multiple par répartition en fréquence (FDMA)), n'importe quel modèle de message de navigation. Les systèmes nommés sont des préréglages facultatifs : des fichiers de données, chacun avec sa source, qui ne complètent que ce qu'un scénario laisse de côté. Chaque fonctionnalité, test, référence indépendante et scénario fourni s'exécute sans aucune donnée Celeste.

Le préréglage Celeste IOD (démonstration en orbite) est l'un de ces préréglages facultatifs. Ses paramètres de signal ont été présentés à l'atelier LEO-PNT du NAVISP de l'ESA (programme d'innovation et de soutien à la navigation de l'Agence spatiale européenne), 2026, et n'ont pas encore de source publique. Chaque nombre issu de l'atelier figure dans un seul fichier du moteur, src/celeste_iod.rs, que build.rs ne compile que s'il existe, et dans les scénarios réservés au dépôt scenarios/*celeste-iod*.toml. Supprimer ce fichier et ces scénarios retire le préréglage sans modification de source ; tous les autres tests, références indépendantes et scénarios s'exécutent sans lui (tests/workshop_preset_isolation.rs contrôle quels fichiers peuvent le nommer). Cette page n'en donne aucun nombre.

Les types de scénario et leur enchaînement#

La chaîne transmet des valeurs dans le code (voir Chaîne LEO-PNT de bout en bout ci-dessous) : la conception de signal fixe la répartition de la PIRE (puissance isotrope rayonnée équivalente) de la bande du passage et la cadence de chips suivie ; le passage donne le C/N0 suivi et la gigue de code ; le SISRE du message de navigation et le C/N0 du passage pondèrent les mesures LEO de la position fusionnée.

Bandes#

Les conceptions génériques utilisent des centres de bande publics ; chacune est REPRESENTATIVE, et non le signal d'un système (data/leo-signals/generic-bands.toml, generic-c-band.toml).

BPSK(n) est une modulation par déplacement de phase binaire à n × 1,023 Mchip/s. Le rapport de retard est (f_L/f)² avec f_L = 1191,795 MHz. La perte en espace libre augmente de 20·log10(f/f_L) à la même distance (−8,2 dB en UHF, +6,4 dB en S, +12,5 dB en C).

Préréglages de signaux et de systèmes#

Chaque préréglage marque ses nombres PUBLIC (avec une URL), REPRESENTATIVE (un choix de conception documenté, jamais une affirmation sur un système réel) ou WORKSHOP, et le résultat de chaque exécution qui en utilise un indique lequel.

Le message de navigation#

Un message de navigation LEO (LEO-NAVMSG.md) comporte quatre parties, la structure que partagent le Galileo Open Service Signal-in-Space Interface Control Document (OS SIS ICD) et les propositions LEO publiées :

La trame binaire est l'encodage documenté propre à Kshana, modelé sur ces composantes, et non la disposition binaire d'un système. RINEX 4,02 ne définit aucun enregistrement de navigation LEO ; l'export de type RINEX est donc une extension de Kshana documentée (travaux antérieurs : arXiv 2401,17767).

Résilience#

Les moniteurs de leurrage, leurs statistiques et leurs limites sont sur LEO-PASS.md. La cascade multibande avec un brouilleur différent par bande est multi-band-jamming-waterfall (LEO-SIGNAL.md).

Un scénario par domaine d'expérimentation#

Les huit domaines d'expérimentation de l'appel Celeste IOD à l'expérimentation par des tiers (Open Space Innovation Platform de l'ESA, OSIP) sont des questions LEO-PNT génériques ; chacun a un scénario indépendant du système :

Un scénario par secteur d'utilisateurs finaux#

Chaque secteur est une chaîne campaign sur une seule chronologie, donc elle s'anime, et chacun a un membre leo-pass, donc il exporte la géométrie (voir Exécution).

VALIDATED et MODELLED#

Une ligne n'est VALIDATED que si un test reproduit une configuration publiée et fige le chiffre publié dans une tolérance indiquée ; tout le reste est MODELLED, avec sa justification (VERIFICATION-MATRIX.md, MODELLED-RATIONALE.md).

Lignes LEO-PNT VALIDATED :

• puissance de signal à bande limitée en forme close et gigue de suivi de code early-late à des points de fonctionnement publiés (Betz et Kolodziejski 2009), avec la largeur de bande de Gabor et les SSC recoupés ;
• le Doppler maximal d'un satellite de navigation LEO (Xona Pulsar X1 32–34 kHz, Iridium ±36 kHz), et l'enveloppe Doppler d'un utilisateur statique comparée au tableau 1 d'arXiv 2509,19551 ;
• coefficients de pluie P.838-3 de l'UIT-R, affaiblissement par la pluie et scintillation troposphérique P.618-14, et perte de pénétration dans les bâtiments P.2109-2, comparés aux données de validation de la Commission d'études 3 de l'UIT-R ;
• la mise à l'échelle du retard ionosphérique du premier ordre et la perte en espace libre (rapport de retard de groupe d'IS-GPS-200, forme de Friis) ;
• les pondérations SISRE moyennes mondiales (Montenbruck et al. 2018), l'algorithme utilisateur de l'ICD Galileo comparé à RTKLIB sur de véritables éphémérides diffusées, et le CRC-24Q comparé à sa valeur de contrôle du catalogue.

Lignes LEO-PNT MODELLED : chaque conception de signal et chaque arbitrage de bande, la cascade multibande, chaque passage et chaque bilan de liaison dans son ensemble, les préréglages, les positions à faible énergie, l'ajusteur et les formats du message, le positionnement Doppler et conjoint, la convergence du PPP, le positionnement NTN, le transfert de temps, la couverture polaire, la chaîne de bout en bout, les moniteurs de leurrage et le sondage de l'ionosphère, et chaque campagne (une campagne compose des types de scénario et n'ajoute aucune physique ; ses identités de composition sont testées, CAMPAIGNS.md). Aucun C/N0 LEO, aucune erreur de mesure de distance ni aucun chiffre de positionnement n'est comparé à une mesure d'un satellite quelconque.

Exécuter un scénario#

Chaque scénario ci-dessus est fourni : kshana example <name> l'affiche, et

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

écrit, à côté du fichier, le résultat (.result.json), le graphique (.chart.svg), le rapport avancé (.report.html et .report.json, avec une section qui intègre l'exécution animée et liste les exports), le lecteur interactif (.animation.html) et les exports. Ce qui s'applique dépend du type de scénario :

• une exécution avec un axe temporel s'anime : époques de leo-pass, le spoof.series d'une exécution de leurrage, chronologies de spectrum, époques conjointes et traces de synchronisation temporelle de leo-pvt, courbes d'erreur de leo-ppp et chaque chaîne de campagne. Un balayage ou une composition n'a pas d'axe temporel : --animate le refuse avec le code de sortie 1 et la commande n'écrit alors rien du tout ; exécutez donc les huit balayages et compositions ci-dessus (leo-resilience-multiband-diversity, leo-resilience-spoof-monitors et chaque scénario leo-focus-* sauf leo-focus-science-iono-sounding) sans --animate ;
• leo-pass et leo-pnt-chain exportent des éphémérides CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON et STK (Systems Tool Kit) de la géométrie du passage ; une campagne exporte chaque membre qui a une géométrie comme son propre jeu de fichiers, l'étiquette du membre figurant dans le nom du fichier (<name>.<member>.czml), de sorte que chaque secteur exporte ses passages LEO ; les autres types de scénario LEO indiquent pourquoi un format ne s'applique pas (INTEROP.md).

Les autres scénarios LEO, par type de scénario (détails sur la page de chaque type de scénario) :

Les scénarios facultatifs sont réservés au dépôt et sont retirés avec le fichier de préréglage Celeste.

Deux d'entre eux relèvent d'autres types de scénario. leo-pnt-mega-shell (constellation-design) dimensionne une constellation LEO-PNT de 5000 satellites en quatre couches de Walker illustratives : disponibilité de 99,22 % pour un PDOP de 3 ou moins au-dessus d'un masque de 20°, PDOP médian de 1,11 et 39,4 satellites en vue en moyenne sur 648 points de grille et 12 époques. slot-timing-ocxo-leo (slot-timing) demande combien de temps l'OCXO de la fiche technique d'un petit satellite LEO reste dans une garde de créneau de 100 ns à k = 3 après sa dernière position GNSS : la garde est rompue 650,8 s après une position, il faut donc une position au moins toutes les 645,8 s (133,8 par jour), le bruit de fréquence à marche aléatoire étant le terme dominant.

Chaîne LEO-PNT de bout en bout#

Le type de scénario leo-pnt-chain (src/leo_pnt_chain.rs) suit un système LEO-PNT depuis sa conception de signal jusqu'à la position de l'utilisateur. Chaque étape est un type de scénario du moteur, exécuté sur sa propre table du scénario de chaîne, et la chaîne transmet des valeurs d'une étape à la suivante dans le code :

Une valeur n'est transmise que là où la table en aval ne la fixe pas, et chaque transmission est listée dans le tableau handoffs du résultat avec sa valeur, son unité et sa cible. Une bande de [pass] doit nommer la conception (signal = "<design>") ; c'est ainsi qu'une bande leo-pass porte aussi toute conception leo-signal de son propre chef : elle reprend la fréquence centrale de la conception, la largeur de bande d'émission et la cadence de chips suivie, répartit sa PIRE entre les composantes, et indique à chaque époque le C/N0 du composant suivi et la gigue de suivi de code early-late cohérente à bande limitée (Betz et Kolodziejski 2009 ; espacement d'un demi-chip, boucle de 1 Hz, 20 ms).

Scenarios:

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

écrit le résultat, le graphique, le rapport avancé (qui intègre le passage animé et renvoie vers les exports), le lecteur interactif, et des fichiers d'éphéméride CZML (Cesium Language), KML (Keyhole Markup Language), GeoJSON et STK (Systems Tool Kit) de la géométrie du passage.

La chaîne est MODELLED : elle n'ajoute aucune physique, et chaque étape garde ses propres étiquettes. Le modèle de C/N0 de l'étape de positionnement est une droite en sin(élévation), de sorte qu'une forme propre à un passage est réduite à deux nombres ; l'étape de message ne modélise aucune détermination d'orbite, ce qui explique pourquoi od_sisre_m est une entrée indiquée (0,25 m dans les scénarios fournis, représentatif de la détermination d'orbite embarquée de niveau décimétrique et de l'horloge pilotée à l'échelle du chip que signale la charge utile ATOMIC : https://insidegnss.com/first-steps-toward-a-fully-operational-leo-pnt-payload/).