Kshana の LEO-PNT

LEO-PNT とは、低軌道（LEO）の衛星による PNT（測位・航法・時刻）で、全球測位システム（GPS）や Galileo などの中軌道（MEO）の全球測位衛星システム（GNSS）と併用、またはその代わりに使うものです。このページは、エンジンのすべての LEO-PNT の種別とシナリオをまとめます。各々が計算するもの、バンドと信号プリセットとその数値の出どころ、航法メッセージが搬送するもの、VALIDATED であるものと MODELLED であるもの、各シナリオの実行方法です。種別ごとのページはさらに詳しく説明しています：

まずシステム非依存#

エンジンは汎用の LEO-PNT シミュレーターです。任意のコンステレーション（Walker パターン、明示的な軌道要素、Simplified General Perturbations 4（SGP4）伝搬器を通した二行軌道要素セット（TLE）、または設計した単一パス）、任意の信号設計（任意のバンド、二位相偏移変調（BPSK）、バイナリオフセットキャリア（BOC）、周波数分割多元接続（FDMA）の各成分の任意の組み合わせ）、任意の航法メッセージモデルを扱えます。名前の付いたシステムは任意のプリセットで、それぞれ出典付きのデータファイルであり、シナリオが指定していない部分だけを補います。すべての機能、テスト、オラクル、同梱シナリオは、Celeste のデータがなくても動作します。

Celeste IOD（軌道上実証）プリセットは、その中の任意のプリセットの一つです。その信号パラメーターは、ESA NAVISP（European Space Agency Navigation Innovation and Support Programme）の LEO-PNT ワークショップ（2026）で発表されたもので、まだ公開された出典がありません。エンジンのワークショップ由来の数値はすべて一つのファイル src/celeste_iod.rs にあり、build.rs はそれが存在する場合にのみコンパイルに含め、リポジトリ専用のシナリオ scenarios/*celeste-iod*.toml にもあります。このファイルとこれらのシナリオを削除すると、ソースを編集せずにプリセットを外せます。ほかのすべてのテスト、オラクル、シナリオは、それなしで動作します（tests/workshop_preset_isolation.rs は、どのファイルがそれに言及してよいかを守ります）。このページにはその数値は一切載せていません。

種別とその接続#

このチェーンはコード内で値を受け渡します（下のエンドツーエンドの LEO-PNT チェーンを参照）：信号設計がパスのバンドの EIRP（等価等方放射電力）の配分と追跡チップレートを決め、パスが追跡 C/N0 とコードジッターを与え、航法メッセージの SISRE とパスの C/N0 が、融合測位解の LEO 測定値に重みを与えます。

バンド#

汎用設計は公開されたバンドの中心を使います。いずれもREPRESENTATIVEであり、特定のシステムの信号ではありません（data/leo-signals/generic-bands.toml、generic-c-band.toml）。

BPSK(n) は、n × 1.023 Mchip/s の二位相偏移変調です。遅延比は (f_L/f)² で、f_L = 1191.795 MHz です。同じ距離での自由空間損失は 20·log10(f/f_L) だけ増加します（UHF で −8.2 dB、S で +6.4 dB、C で +12.5 dB）。

信号とシステムのプリセット#

各プリセットは、その数値に、PUBLIC（URL 付き）、REPRESENTATIVE（文書化された設計上の選択であり、実在のシステムについての主張ではありません）、WORKSHOPのいずれかを付けており、いずれかを使うすべての実行の結果は、どれであるかを示します。

航法メッセージ#

LEO 航法メッセージ（LEO-NAVMSG.md）は四つの部分を搬送します。これは Galileo Open Service Signal-in-Space Interface Control Document（OS SIS ICD）と、公表された LEO 提案に共通する構造です：

バイナリフレームは、これらの構成要素に倣った Kshana 独自の文書化された符号化であり、いかなるシステムのビット配置でもありません。RINEX 4.02 は LEO の航法レコードを定義していないため、RINEX 形式の出力は、文書化された Kshana の拡張です（先行事例：arXiv 2401.17767）。

レジリエンス#

スプーフィングモニター、その統計量、その限界は LEO-PASS.md にあります。バンドごとに異なるジャマーを持つマルチバンドのウォーターフォールは multi-band-jamming-waterfall です（LEO-SIGNAL.md）。

実験の重点領域ごとに一つのシナリオ#

Celeste IOD の第三者実験募集（ESA Open Space Innovation Platform、OSIP）の八つの実験重点領域は、汎用の LEO-PNT の問いであり、それぞれにシステム非依存のシナリオがあります：

エンドユーザーの分野ごとに一つのシナリオ#

各分野は一つの時間軸上の campaign チェーンであるためアニメーションでき、それぞれに leo-pass のメンバーがあるためジオメトリを出力できます（実行を参照）。

VALIDATED と MODELLED#

行が VALIDATED になるのは、テストが公表された設定を再現し、公表された数値を明示した許容差の範囲内で固定する場合に限られます。それ以外はすべて MODELLED で、その根拠を示します（VERIFICATION-MATRIX.md、MODELLED-RATIONALE.md）。

VALIDATED の LEO-PNT の行：

• 公表された動作点での、閉形式の帯域制限した信号電力と early-late コード追跡ジッター（Betz と Kolodziejski 2009）。Gabor 帯域幅と SSC は相互確認済み；
• LEO 航法衛星の最大ドップラー（Xona Pulsar X1 32–34 kHz、Iridium ±36 kHz）、および静止ユーザーのドップラーの包絡線を arXiv 2509.19551 表 1 と比較したもの；
• ITU-R P.838-3 の降雨係数、P.618-14 の降雨減衰と対流圏シンチレーション、P.2109-2 の建物侵入損失を、ITU-R Study Group 3 の検証データと比較したもの；
• 一次の電離圏遅延の換算と自由空間損失（IS-GPS-200 の群遅延比、Friis 形式）；
• 全球平均の SISRE の重み（Montenbruck ら 2018）、実際の放送エフェメリスでの RTKLIB に対する Galileo ICD ユーザーアルゴリズム、およびカタログの検査値に対する CRC-24Q。

MODELLED の LEO-PNT の行：すべての信号設計とバンドのトレードオフ、マルチバンドのウォーターフォール、すべてのパスとリンクバジェット全体、プリセット、低エネルギー測位、メッセージのフィッターと形式、ドップラーと合同測位、PPP の収束、NTN 測位、時刻比較、極域のカバレッジ、エンドツーエンドのチェーン、スプーフィングモニターと電離圏サウンディング、そしてすべてのキャンペーン（キャンペーンは種別を合成するもので、物理を加えません。その合成の恒等式はテストされています。CAMPAIGNS.md）。LEO の C/N0、測距誤差、測位の数値は、いずれの衛星の実測とも比較していません。

シナリオの実行#

上記のシナリオはすべて同梱されています。kshana example <name> がそれを表示し、

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

ファイルの隣に、結果（.result.json）、グラフ（.chart.svg）、詳細レポート（.report.html と .report.json。アニメーション実行を埋め込み、出力を一覧するセクション付き）、インタラクティブプレーヤー（.animation.html）、および出力を書き出します。何が当てはまるかは種別によります：

• 時間軸のある実行はアニメーションします：leo-pass のエポック、スプーフィング実行の spoof.series、spectrum のタイムライン、leo-pvt の合同エポックとタイミングトレース、leo-ppp の誤差曲線、およびすべてのキャンペーンチェーン。スイープや合成には時間軸がないため、--animate は終了ステータス 1 でこれを拒否し、その後コマンドは何も書き出しません。したがって、上記の八つのスイープと合成（leo-resilience-multiband-diversity、leo-resilience-spoof-monitors、および leo-focus-science-iono-sounding を除くすべての leo-focus-* シナリオ）は --animate なしで実行してください；
• leo-pass と leo-pnt-chain は、パスのジオメトリの CZML（Cesium Language）、KML（Keyhole Markup Language）、GeoJSON、STK（Systems Tool Kit）エフェメリスを出力します。キャンペーンは、ジオメトリを持つ各メンバーを、メンバーのラベルをファイル名に含めた（<name>.<member>.czml）独自のファイルセットとして出力するため、すべての分野が LEO パスを出力します。他の LEO 種別は、形式が当てはまらない理由を示します（INTEROP.md）。

残りの LEO シナリオを種別ごとに示します（詳細は各種別のページ）：

オプションのシナリオはリポジトリ専用で、Celeste のプリセットファイルとともに外されます。

そのうちの二つは他の種別にあります。leo-pnt-mega-shell（constellation-design）は、例示的な四つの Walker シェルで 5000 機の LEO-PNT コンステレーションの規模を見積もります：20° のマスクの上で PDOP が 3 以下となる可用性は 99.22 %、PDOP の中央値は 1.11、可視衛星は 648 のグリッド点と 12 エポックの平均で 39.4 機です。slot-timing-ocxo-leo（slot-timing）は、LEO 小型衛星のデータシート上の OCXO が、最後の GNSS 測位から k = 3 で 100 ns のスロットガードの内側にどれだけ留まるかを問います。ガードは測位の 650.8 s 後に破れるため、少なくとも 645.8 s ごと（一日 133.8 回）の測位が必要で、ランダムウォーク周波数雑音が支配的な項です。

エンドツーエンドの LEO-PNT チェーン#

leo-pnt-chain 種別（src/leo_pnt_chain.rs）は、一つの LEO-PNT システムを、信号設計からユーザーの位置まで追います。各段階はエンジン自身の種別で、チェーンシナリオの自身のテーブルで実行され、チェーンはコード内で値を一段階から次へ受け渡します：

値が受け渡されるのは、下流のテーブルが未設定のままにしている場合に限られ、すべての受け渡しは、その値、単位、送り先とともに、結果の handoffs 配列に一覧されます。[pass] のバンドは設計（signal = "<design>"）を指名しなければなりません。leo-pass のバンドが任意の leo-signal 設計をそれ単独でも搬送できるのは、そのためです。バンドは設計の中心周波数、送信帯域幅、追跡チップレートを採用し、EIRP を成分に配分し、エポックごとに、追跡成分の C/N0 と、帯域制限したコヒーレント early-late コード追跡ジッター（Betz と Kolodziejski 2009、ハーフチップ間隔、1 Hz ループ、20 ms）を報告します。

Scenarios:

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

結果、グラフ、詳細レポート（アニメーションしたパスを埋め込み、出力へリンク）、インタラクティブプレーヤー、およびパスのジオメトリの CZML（Cesium Language）、KML（Keyhole Markup Language）、GeoJSON、STK（Systems Tool Kit）エフェメリスファイルを書き出します。

このチェーンは MODELLED です。物理を加えず、各段階は自身のラベルを保ちます。測位段階の C/N0 モデルは sin(仰角) の直線であるため、パス固有の形は二つの数値に縮約されます。メッセージ段階は軌道決定をモデル化しないため、od_sisre_m は明示された入力です（同梱シナリオでは 0.25 m で、ATOMIC ペイロードが報告するデシメートル級の搭載軌道決定とステアリングされたチップスケールの時計を代表する値です：https://insidegnss.com/first-steps-toward-a-fully-operational-leo-pnt-payload/）。