完全なgNBまたはgNB-DUを搭載した再生型NTNペイロードは、直接手を加えることのできない通信ノードです。運用開始後は、他のRAN 要素と同様にパッチ適用、アップグレード、保守を行う必要がありますが、その際には、地上でのライフサイクルに関する想定のほとんどが通用しない制約下で行わなければなりません。衛星ごとに異なるソフトウェアリビジョンが必然的に稼働し、カバレッジエリアが重複し、相互にトラフィックを引き継ぐ稼働中のコンステレーション全体で、プロトコルレベルの一貫性を維持しつつ、すべての衛星を同時に更新できないという状況下で運用を継続することこそが、この分野における最大の技術的課題です。
この記事では NR 用語を統一して使用していますが、eNBを搭載した NB-IoTeNBを搭載する再生型ペイロードにも同様に適用されます。技術的な課題は同じです。つまり、すべての通信ノードを一度に更新できない場合、どのようにして通信ノードのコンステレーションを最新の状態に保ち、規格に準拠させ、相互運用性を確保するかということです。
本記事では、搭載型gNBペイロードのソフトウェアライフサイクル管理が、地上展開と根本的に異なる点、およびコンステレーション全体にわたる更新の設計にどのような技術的制約が影響を与えるかを考察する。
地上ベースラインとその破綻の理由
オンプレミスのRAN では、gNBのソフトウェア更新は、よく理解されたパターンに従って行われます。具体的には、基地局間での段階的な展開、検証が完了するまで新機能の動作を制限する機能フラグ、冗長なブートパーティションによる迅速なロールバック、そしてカナリア展開において実トラフィックを対象に実行される回帰テストスイートなどです。その背景には、ノードへの十分なアップリンク帯域幅、復旧のための物理的なアクセス、展開フェーズ内でのハードウェアの均一性、そして数時間から数日以内にクラスタ全体を単一のソフトウェアバージョンに統一できる能力といった前提があります。
再生型 LEO 衛星コンステレーションは、これらの前提条件のすべてに反しています。アップロード帯域幅は、TT&C（テレメトリ・テレコマンド・コマンド）リンクの容量に制限されます。これは通常、テレメトリやハウスキーピング用に設計されたSバンドまたは狭帯域Kaバンドのコマンドリンクであり、大量のデータ転送を想定したものではありません。gNBのソフトウェアイメージ全体を転送するには、複数の通過にわたり分割する必要があり、各地上局との通信ウィンドウは数分間しか続きません。ハードウェアの改訂は、数年にも及ぶコンステレーションの構築フェーズごとに異なってきます。 2025年に打ち上げられた衛星は、2028年に打ち上げられた衛星とは異なるプロセッサアーキテクチャやFPGA世代を搭載している可能性があるが、同じサービスネットワーク内で共存しなければならない。ロールバックは原理的には可能だが、地上展開では決して直面することのないリスクを伴う。つまり、冗長な演算パスを持たない衛星で起動シーケンスに失敗した場合、そのノードが失われることになる。
TT&Cの帯域幅とアップロードのスケジューリング
ユーザープレーンのトラフィックを伝送するフィーダーリンクは、プラットフォーム管理に使用されるリンクとは異なります。TT&Cコマンドのアップリンクは、設計上帯域幅に制限があり、スループットよりも信頼性とリンクマージンを優先しています。キロビット毎秒のコマンドストリーム用に割り当てられたリンク、あるいは新しいプラットフォームで利用可能な低メガビット毎秒の通信速度のリンクを介して、数十メガバイトから数百メガバイト規模のソフトウェアイメージをアップロードする場合でも、複数の地上局通過にまたがって慎重なスケジューリングを行う必要があります。
アップデートの適用はオンデマンドでは行えません。コンステレーション全体にわたって計画を立て、キューに入れ、順序立てて実行する必要があります。最初のアップロード（T0）から最後の衛星の更新（T0+n）までの時間は、コンステレーションの規模、地上局のカバレッジ、およびTT&Cのスループットによって異なりますが、nは時間単位ではなく、週または月単位で測定されます。再送信、異常対応のための優先順位による割り込み、およびペイロード運用との競合により、キャンペーン期間はさらに長くなります。 更新は単発のイベントではなく、一連のキャンペーンである。
その結果、展開キャンペーン中のどの時点においても、コンステレーション内では異なるバージョンのソフトウェアが混在して稼働することになります。これは例外的なケースではなく、積極的にメンテナンスが行われているコンステレーションにとっては、常態と言えるものです。
ハードウェアリビジョンの不一致
コンステレーションは、段階的に製造・打ち上げられます。各段階は、衛星の組み立て時点（多くの場合、打ち上げの18～36カ月前）で利用可能な演算ハードウェア、FPGAファブリック、および周辺機器インターフェースを反映しています。コンステレーションの運用期間を通じて、ハードウェアプラットフォームは多様化していきます。gNBソフトウェアは、ハードウェア適応レイヤーの背後でこれらの違いを抽象化するか、ハードウェアの改訂版ごとに並列なビルドターゲットを維持する必要があります。
重要なインターフェースおよびハードウェアのルーティングは、打ち上げ時点で確定され、その後は変更できません。このため、ハードウェアとソフトウェアの両方について、プロトコル準拠をはるかに超えるレベルの 3GPP プロトコル準拠の範囲をはるかに超えるものです。更新に失敗した後、衛星が正常な状態に戻れる能力、および起動・復旧パスの安定性は、衛星が地上を離れる前に実証されなければなりません。
軌道上に投入された後、各ソフトウェアリリースは、コンステレーション内で稼働中のすべてのハードウェアリビジョンに対して検証されなければなりません。これにより、組み合わせ的な回帰テストの問題が生じます。新しいペイロードでのみ利用可能なハードウェアアクセラレーションを使用するリリースは、古いプラットフォームではスムーズに性能を低下させる必要があります。実際には、ハードウェアおよびソフトウェアのリビジョンが異なる衛星は、機能レベルごとにグループ分けされ、各グループはサポートする機能に応じたユーザー端末（UE）群に対応しています。地上セグメントは、これらの機能レベルを追跡し、モビリティや負荷分散に関する決定においてそれらを考慮に入れなければなりません。
LEO 3年から5年の衛星の寿命は、自然な更新サイクルをもたらします。古いハードウェアは軌道から撤去され、新しいプラットフォームに置き換えられるため、バージョンの不整合が生じる期間が制限されます。しかし、その期間内においては、組み合わせの問題は依然として残っています。
バージョンの共存とプロトコル層間の相互作用
最も重大な制約はアーキテクチャ上のものです。異なるソフトウェアリビジョンを実行している2つの衛星が、同じUE群にサービスを提供し、衛星間またはビーム間のハンドオーバーに参加する場合、バージョン間のずれの影響を最も受けやすいプロトコル層は3つあります。それは、MACおよびHARQのタイミング、RRC状態の処理、およびタイミングアドバンスの計算です。これらそれぞれが、ハンドオーバー境界において異なる種類の問題を引き起こします。
リリース N を実行している衛星 A から、リリース N+1 を実行している衛星 B へ UE がハンドオーバーされると仮定する。リリース N+1 によって MAC スケジューリングの挙動が変更され、HARQ プロセス数の管理方法の変更、DRXサイクルのアライメントの調整、あるいはBSRの解釈の変更が行われた場合、UE はハンドオーバー時に不連続性を経験することになる。 RRC再構成メッセージは、ターゲットセルが実際に実装している内容と整合するパラメータを伝達しなければならない。送信元セルとターゲットセルの間でタイミング関係に不一致がある場合、UEの状態マシンは予期しない状況に遭遇する可能性がある。
3GPP 仕様は、異種混在環境に対応するように設計されています。ランダムアクセスや接続確立時の機能交換により、UEとネットワークノードはサポートされる機能についてネゴシエーションを行うことができ、TS 38.331に規定される重要および非重要な拡張コンテナにより、下位互換性を損なうことなく新しいIEを導入することが可能になります。マルチベンダーのノードが存在する地上波ネットワークでは、実装や仕様の解釈の違いに起因する同様の相互運用性の課題に直面しています。
これらのメカニズムは、UEとネットワーク間の互換性に対応しているが、問題の半分しか解決していない。UE側のインターフェースは両方のバージョンで仕様に準拠している一方で、ノード間の動作は異なる場合がある。衛星Aのスケジューラが特定のHARQタイミングプロファイルを想定し、衛星Bのスケジューラが別のプロファイルを想定している場合、両衛星間、あるいは各衛星と共有の地上側CUとの間のXnまたはF1シグナリングは、その違いに対応しなければならない。
TS 38.401 で定義されているように、地上側のgNB-CUと搭載型の gNB-DU を使用するアーキテクチャでは、F1 インターフェースが主要なバージョン境界となります。 CUは、異なるソフトウェア・リリースを実行しているDUとの互換性を維持しなければならない。CU-CPとCU-UP間のE1インターフェースは、ユーザープレーンの処理がリリースごとに独立して進化する場合、2つ目のバージョン依存の境界をもたらす。この問題は、地上波O-RAN の展開において存在するが、バージョンを迅速に統一できない場合には、その制約がはるかに大きくなる。F1AP手順、UEコンテキスト管理、およびベアラー設定シーケンスは、その時点でコンステレーション内に存在するバージョン範囲全体を通じて安定していなければならない。
TS 38.213で規定されている HARQ の処理回数、スケジューリングアルゴリズム、およびフィードバックのタイミングは、UE が認識する遅延およびBLER に直接影響を与えます。長いRTT に対する NTN 独自の適応策（フィードバックウィンドウの拡張や処理回数の変更など）は、3GPP の各リリースを通じて現在も改良が進められています。連続するリリースを追従する実装ではこれらの変更が引き継がれるため、HARQ の挙動はバージョン間の差異が生じる恒常的な要因となっています。
RRCの「非アクティブ」状態または「接続中」状態の管理、あるいは測定報告およびハンドオーバーのトリガー閾値への変更は、コンステレーション全体のモビリティ性能に影響を及ぼします。ハンドオーバーのトリガー閾値がより厳格に設定された衛星は、たとえ両方が仕様準拠である場合でも、保守的な設定で動作する衛星とは、ソースセルとしての挙動が異なってしまいます。
NTNの点火時期の進角（TA）の計算は、衛星の軌道要素とUEの位置推定値に依存します。新しいリリースでTAの計算が改良され、ドップラーの事前補正が改善されたり、SIBで放送される共通のTAが調整されたりした場合、旧衛星と新衛星の間を移動するUEは、ハンドオーバー時にTAの処理に段階的な変化が生じます。
ローリングアップデート、機能の段階的導入、およびロールバック
こうした制約に対する実用的な対応策として、ローリングアップデート戦略と衛星ごとの機能制限を組み合わせた手法が採用されています。新しいプロトコルの動作は実装されますが、コンステレーションの一定割合がアップデートを受け取るまでは、設定フラグによって無効化されたままとなります。その後、カバレッジの重複状況に応じて段階的な有効化が可能であれば、コンステレーション全体、あるいは地域ごとに、新しい動作が有効化されます。
軌道上でのロールバックは可能ですが、制約があります。デュアルパーティションによるブート方式は依然として一般的であり、これにより、以前に正常に動作していたイメージへの復元が可能となります。新しいペイロードアーキテクチャでは、コンテナ化されたプロセス分離やハイパーバイザーベースの障害封じ込め機能が追加されており、イメージ全体の交換ではなく、機能レベルでのよりきめ細かな復旧が可能になっています。いずれの場合も、トリガー条件を慎重に定義する必要があります。サービスウィンドウ中にロールバックを行う衛星は、アクティブなUE接続に支障をきたす可能性があります。 新しいイメージの起動に失敗し、自律的に元に戻すことができない衛星は、次回のTT&C通信が行われるまで「デッドノード」となります。地上局の通信範囲外にあるLEO 衛星の場合、その通信まで数時間かかる可能性があります。
したがって、地上セグメントは、衛星ごとに、現在のソフトウェアバージョン、ハードウェアリビジョン、有効な機能フラグ、およびロールバック状態を追跡しなければならない。モビリティ管理、負荷分散、およびハンドオーバーの決定においては、機能の違いを考慮に入れなければならない。これは単なるオプションとしての複雑さではない。これは、維持管理された再生型コンステレーションの運用上の基本要件である。
ゲートハウスからの眺め
NTNプロトコルスタックを直接扱うことで、ある層での変更が、仕様書の検討だけでは予測しがたい形で他の層の想定とどのように相互作用するかがわかります。 局所的には正しいMACスケジューリングの変更であっても、HARQの再送信パターンを変化させ、その結果、RLCの再組み立てタイマーに負荷をかけたり、RRCの非アクティブ時の挙動を変化させたりすることがあります。こうした相互作用は、現実的な遅延やドップラープロファイルの下で異なるバージョンのノードを組み合わせた統合テストを実行すれば再現可能ですが、回帰テストスイートが単一バージョン・単一ノードの挙動のみを検証している場合には、これらの相互作用は検出されません。
シミュレートされたコンステレーション・セグメント全体で異なるリリースの組み合わせを実行するバージョン共存テストの経験から、問題が集中するのはバージョン間の境界であることが確認されています。新しいコードを実行している単一のノード内部ではなく、引き継ぎ箇所、F1インターフェース、つまりタイミングやスケジューリングの解釈がわずかに異なる2つのノードが、共有されたUEコンテキスト上で協調しなければならない地点で問題が発生するのです。 当初からこの点を考慮して設計を行い、バージョン互換性契約を定義し、個々のリリースではなくリリースの組み合わせを網羅する回帰マトリックスを構築し、バージョン間のモニタリングのためにプロトコル層の相互作用を計測対象に含めることは、過度な慎重さではありません。これは、準備なしにこうした制約に直面した際に私たちが観察した事実を反映しているのです。
結論
再生可能なNTNペイロードのソフトウェアライフサイクル管理における最大の課題は、アトミックに更新できない衛星コンステレーション全体で、複数のソフトウェアリビジョンを継続的に共存させることである。この環境では、衛星間のハンドオーバー時においてもユーザー体験を維持するために、プロトコル層の挙動を十分に一貫させておく必要があり、ロールバックの選択肢は存在するが、それにはコストが伴う。 ライフサイクル管理を「展開後の運用上の課題」として扱うチームは、サービスへの影響を通じてこれらの制約に直面することになる。LEO の3～5年という寿命は、最終的に最も古いハードウェアを退役させる自然な更新サイクルを提供するが、その期間内に、混在バージョン運用に対応するためのアーキテクチャの決定、検証戦略、および地上セグメントの設計が整っていなければならない。これらは、最初の衛星が軌道に到達する前に決定しておく必要がある。
技術者以外の方向けの要約
衛星が独自の携帯電話基地局ソフトウェア（「再生型ペイロード」）を搭載している場合、打ち上げ後のそのソフトウェアの更新は、地上の携帯電話基地局の更新とはまったく異なります。技術者を派遣することはできません。アップロード帯域幅はごくわずかです。また、すべての衛星を一度に更新することもできません。1つの更新を衛星群全体に展開するには、数週間を要します。
つまり、どの時点でも、衛星ごとに異なるバージョンのソフトウェアが動作していることになります。これはごく普通の現象ですが、運用上、大きな課題をもたらします。すなわち、携帯電話が異なるバージョンのソフトウェアを実行している2つの衛星の間を移動する際、各衛星がタイミング、スケジューリング、接続管理を処理する方法に違いがあるにもかかわらず、ハンドオーバーを円滑に行わなければならないからです。
技術的な解決策としては、段階的な展開、機能の段階的導入（十分な数の衛星がアップデートを受け取った後にのみ新機能を有効にする）、およびバージョンの組み合わせを網羅した厳格なテストが挙げられます。アーキテクチャ的な解決策としては、リリース後にどうするか考えるのではなく、最初から異なるバージョンが混在する環境での運用を想定して設計することです。
プログラムおよび運用責任者にとって、これは、ライフサイクル管理が導入後の運用上の課題ではなく、初日からアーキテクチャおよび地上セグメントの設計に組み込まれる必要があることを意味します。経営陣にとって重要なポイントは、再生型衛星コンステレーションへの投資判断においては、初期導入だけでなく、持続的なソフトウェアガバナンスも考慮に入れなければならないということです。
