NTNシステムは、複数のソースから時刻情報を取得します。IoTデバイスを含むUEは、GNSS受信機を介してGPS時刻に同期します。軌道データやエフェメリスの予測値は、通常UTCで提供されます。コンピュータインフラでは、内部でTAIを用いてタイムスタンプが付けられる場合があります。通信事業者は、UTCまたは現地時間でビームのスケジューリングやログの分析を行います。 これらの各時刻システムは、ミリ秒単位ではなく秒単位で互いにオフセットがあり、そのオフセットは固定されていません。エンジニアがUTCでタイムスタンプが付けられた軌道入力を、GPS時刻を前提とする計算に投入すると、結果は18秒ずれてしまいます。システムはこの誤りを警告しません。フォーマットエラーも、解析失敗も、例外も発生しません。単に、数値が示す衛星の位置が、システムが想定している位置と一致しないというだけなのです。
これは構造的な統合上の問題です。タイミングの精度が測位精度、スケジューリング、およびリンク確立に直接影響を与えるNTNの展開環境において、この程度の大きさのオフセットが見過ごされると、実際には全く別の問題として現れるような実際の障害を引き起こします。
時刻体系とそのオフセット
GPS時間は、1980年1月6日午前0時（UTC）を起算点とする連続的な原子時計基準です。閏秒は組み込まれていません。TAIとGPS時間のオフセットは正確に19秒であり、GPSの起算点において定義上固定されています。
TAI（国際原子時）は、世界中の約400台の原子時計から導出される、基礎となる原子基準時です。また、TAIは連続的なものであり、閏秒は含まれません。
UTCは、TAIから閏秒の整数を差し引いて算出されます。この閏秒は、UTCを地球の自転と一致させるために、国際地球回転・基準系サービス（IERS）によって導入されたものです。2017年1月以降、TAIからUTCを差し引いたオフセットは37秒となっており、2026年初頭までは追加の閏秒は導入されません。
これらの定義によると、現在、GPS時間はUTCより18秒進み、TAIはUTCより37秒進み、GPS時間はTAIよりちょうど19秒遅れています。壁時計や現地時間は、UTCにタイムゾーンのオフセットが加算されるため、運用者の所在地に応じてさらにずれが生じます。
これらは、関連するすべての計算に波及する、正確で決定論的なオフセットです。
NTNがなぜ事態を悪化させるのか
地上波セルラーネットワークでは、この種のタイミングのずれが運用上の障害を引き起こす可能性は低い。基地局と端末は互いに近接しており、伝搬遅延も小さく、同期インフラは単一の通信事業者の管轄内で厳格に管理されているためである。
NTNは、これらすべての部分を変更します。 LEO 衛星への伝搬遅延は数十ミリ秒のオーダーです。 GEO コンステレーションの場合、デバイスと地上局間の衛星を経由した無線リンクの往復時間は約240ミリ秒に達します。NTNにおけるタイミングアドバンスの値は、地上通信の値をはるかに上回る規模になります。LEO の軌道速度によるドップラーシフトは、数十キロヘルツを超えることもあります。ビームのフットプリントは絶えず移動するため、スケジューリングでは将来の時点における衛星の位置を考慮に入れる必要があります。
これらはすべて、衛星がいつどこにあるかを知ることに依存しています。軌道力学の計算では、時間の関数として衛星の位置を表すエフェメリスデータが使用されます。エフェメリスの時間系が利用者の時間系と一致しない場合、衛星の位置、速度、ドップラー予測、ビーム指向、およびタイミングアドバンスの事前補正など、導出されるすべての量がオフセット分だけずれてしまいます。LEO 軌道における18秒の誤差は、地上軌跡のずれとしておよそ135キロメートルに相当します。つまり、衛星はシステムが計算した位置に単純に存在しないことになります。
この障害モードは、目立った兆候が見られないものです。軌道要素データは構造的に有効です。計算はエラーなく実行されます。出力値は妥当な数値範囲内に収まっています。しかし、予測された衛星の位置が誤っているため、それに依存するすべての下流機能（ビームスケジューリング、ドップラー事前補正、タイミングアドバンスの計算など）の性能が低下するか、または動作しなくなります。
実務において不一致が生じる場面
最もわかりやすい例は、UEと軌道データの間のインターフェースです。デバイスは、GPS時間で動作するGNSS受信機から時刻を取得します。GPS衛星はナビゲーションメッセージ内でUTCオフセットパラメータを送信しており、これにより受信機は必要に応じてUTCを算出できますが、本来の時間尺度としてはGPS時間が採用されています。
しかし、軌道データは通常、UTCで提供・保存されます。天体暦の予測、衛星位置表、ビームスケジューリング計画には、通常UTCのタイムスタンプが付けられます。これは、宇宙運用分野における慣例であり、ほとんどの地上インフラにおける標準的な基準となっているためです。
システムがUTCタイムスタンプ付きの天体位置データを取り込み、18秒の補正を適用せずにGPS時刻デバイス時計と照合すると、ドップラー事前補正およびタイミングアドバンスに使用される衛星位置が、誤ったエポックで算出されてしまいます。その結果、デバイスは、18秒古い、あるいは18秒先の衛星位置から導き出されたパラメータに基づいて信号の取得を試みてしまいます。LEO のシナリオでは、これにより、衛星が、計算されたパラメータが有効な角度範囲をはるかに超えた位置に移動してしまう可能性があります。
エンジニアが確認する症状としては、ランダムアクセスの試行が失敗すること、同期信号が弱いか、あるいは存在しないこと、あるいはドップラー事前補正が収束しないことなどが挙げられます。この不具合は、無線の問題やリンクバジェットの問題として現れますが、診断出力には、時刻システムの不一致を示唆する情報は一切含まれていません。
2つ目の一般的な不一致は、検証環境やテスト環境で発生します。一部のタイミングライブラリやインフラストラクチャコンポーネントは、TAIを使用するように設定されていたり、閏秒調整を行わないアトミックタイムスケールをデフォルトとして使用していたりする場合があります。これらのログをGPS時間に基づくデバイスの動作と比較すると、19秒のオフセットが生じます。UTCに基づくスケジュールされたイベントと比較すると、37秒のオフセットが生じます。 これらのログ間の相関分析を行うと、一見したタイミングの異常、誤ったレイテンシ測定値、あるいは原因が誤って特定された障害シーケンスが生じることがあります。ログの整合性に18秒または37秒のずれが生じると、正しくタイミングが取れたイベントが有効なウィンドウ外で発生したかのように見えたり、実際のタイミング障害が、一見問題のない領域にシフトされることで隠蔽されたりすることがあります。
3つ目の分野は、閏秒の処理に関するものです。GPSとUTCのオフセットは、常に18秒というわけではありません。閏秒が導入されるたびに変化します。閏秒はIERSによって少なくとも6か月前に発表されるため、変化そのものは予測可能です。リスクとなるのは、オフセット値がハードコードされているソフトウェアが、変更が有効になった際に更新されないことです。GPS衛星は現在のオフセットを送信しており、適切に実装された受信機はそれを自動的に適用します。 しかし、オフセット値をハードコードしているソフトウェアや、GPS-UTC変換係数を更新せずに保存しているデータベースは、閏秒が追加されるたびに、1秒ずつ気付かれないうちにずれが生じてしまいます。閏秒の発生前に検証されたシステムは、設定変更なしに閏秒発生後に障害を起こす可能性があり、その障害はログや診断出力において閏秒に言及することはありません。
実践における緩和策
理想的な状態としては、NTNシステムのすべてのコンポーネントが単一の時刻システムで動作することが挙げられます。デバイスは本来、GPS時刻に同期するように設計されているため、GPS時刻が自然な選択肢となります。しかし実際には、これが常に実現できるとは限りません。軌道データ提供業者、地上セグメントのインフラ、コアネットワーク要素、運用ツールはそれぞれ独自の規則を持っており、それらを変更することが必ずしもインテグレーターの裁量で決まるわけではありません。
インテグレーターが制御できるのは、すべてのインターフェースにおける時間システムの明確なラベル付けと変換です。すべてのタイミング入力には、その時間システムに関する曖昧さのない宣言が含まれている必要があります。 異なるタイムシステムで動作するコンポーネント間のすべての引き継ぎでは、ハードコードされた定数ではなく、維持管理された参照値から得られた正しいオフセットを適用する必要があります。検証には、意図的なオフセットの注入を含め、予期しないタイムシステムのタイミング入力が到着した際のシステムの挙動をテストし、不一致が黙って吸収されることなく検出されることを確認する必要があります。
『Gatehouse Satcom 』の視点
Gatehouse Satcom では、時刻システムの整合は、NTNの各プログラムで共通して直面する実用的な統合上の課題です。軌道データ、UEのタイミング、および衛星システムの統合に取り組むということは、GPS時刻、UTC、TAIの境界を日常的に越えることを意味します。 ある時刻系で提供されたエフェメリス入力が、別の時刻系で利用された際に、単なるタイミングエラーではなく、無線通信やスケジューリングの異常として現れる不具合が生じる事例を、我々はこれまで数多く目にしてきました。こうした不整合を特定し解決することは、我々の統合および検証作業における標準的な業務であり、複数のNTNシステム構成にわたる経験が直接的な技術的価値をもたらす分野の一つでもあります。
当社のテスト環境は、タイムシステムの前提条件を明確にし、本番環境へのデプロイ前に不整合を洗い出すように設計されています。本番環境でこうした不整合を発見した場合のコストは、間違った場所を探し回ることで費やされる数週間のデバッグ作業に相当します。
GPS時刻、UTC、およびTAI間のオフセットは決定論的であり、十分に文書化されており、修正も簡単です。システム内には、この補正が適用されていないことを示す兆候は一切ありません。NTNでは、すべてのタイミング入力が位置特定、スケジューリング、および同期に直接反映されるため、検出されなかった18秒のオフセットにより、一見タイミングとは無関係に見える理由で展開が失敗することになります。
無線 3GPP 無線インターフェースでは、タイミングはGPS時刻から導出されます。ネットワークは、システム情報を介してデバイスに現在の閏秒オフセットをブロードキャストし、UTCの導出を可能にします。無線インターフェース自体は、GPSに基づく時間スケールで動作します。したがって、GPSとUTCの境界は、アーキテクチャ内の定義された地点で越えられます。時刻システムの整合性を、当然の前提ではなく明示的な統合要件として扱うには、まずその境界がどこにあるかを把握することから始まります。
