NTNエコシステムは、重要な転換点を迎えています。プラス面としては、 3GPP 標準化によって独自仕様のサイロ化が解消され共通のフレームワークが確立されつつあり、改造不要の携帯電話やeRedCapデバイスによって消費者向けおよびIoT市場の需要が拡大し、モバイルネットワーク事業者からの需要が現実のものとなりつつあり、再生可能ペイロードによってgNBのさらなる軌道投入が進められています。
これにより、ニッチな衛星通信から、拡張性があり、標準規格に基づいたサービス提供へと至る、信頼性の高い道筋が築かれる。
「課題」の側面も同様に重要です。ペイロードのSWaP（サイズ・重量・消費電力）や電力予算は、現在、3GPP 処理の需要と直接衝突しています。ドップラー効果、遅延、高速ハンドオーバーといった課題は、地上ネットワークから引き継がれた前提条件に疑問を投げかけています。統合リスクはプログラムの終盤まで表面化しない場合があり、あらゆるユースケースや軌道に適合する単一のアーキテクチャは存在しません。
ここで、NTNの商業的な可能性と、宇宙機の物理的な限界が対峙することになる。
その緊張関係こそが、本論文におけるビジネス上の問いの出発点である。すなわち、計画されているNTNサービスを、オンボード処理、消費電力、および熱負荷に換算した場合、どの程度の処理能力を確実に販売できるのか、ということである。
デバイス直結型またはIoTコンステレーションのビジネスケースは、カバレッジ、加入者収容能力、ユーザーあたりの帯域幅、遅延許容度、可用性という5つのサービス上の前提に基づいて構築されています。
これらの数値こそがビジネスケースそのものです。これらは、収益モデル、価格設定、そして取締役会、共同投資家、初期顧客に対してなされた約束の基盤となっています。また、これらの各数値は、衛星が発電できる電力や放熱できる熱量に対する権利でもあります。
再生型5GNRNTNペイロードでは、本来なら地上で行われるはずの無線アクセスネットワーク処理の一部またはすべてが衛星側に移行します。この処理は電力を消費し、放散しなければならない熱を発生させますが、その両方が、プラットフォームに割り当てられた限られたリソースを消費することになります。
そこで、コンステレーションがどれだけのサービスを提供できるかを左右する問いは、対象となるサービスがどれだけの電力と冷却能力を必要とするか、ということです。処理能力や熱処理能力の追加は、初期段階であれば対応可能な修正です。しかし、プラットフォームのアーキテクチャが確定してしまえば、同じ変更を行うことははるかに困難になり、コストも大幅に高くなります。
残された選択肢はサービス側にあり、資本が投入され、当初の数値に基づいて商業的な約束がなされた後に、それらは撤回されてしまう。
なぜ容量が電力の問題となるのか
低地球軌道上の衛星が発電できる電力は、太陽電池アレイのサイズと効率によって決まる限られた量です。その一部は、衛星の動作維持に充てられます。残りの電力は、RFペイロード、ビームフォーミングおよび信号処理、搭載ネットワーク処理、そして同じ電力供給を競い合うその他のミッション機能の間で分配されます。
電力を消費する機能はすべて熱を発生させるため、衛星が熱的限界に達すると、出力を低減せざるを得なくなります。提供可能なサービスには2つの制約があります。1つは利用可能な電力による制約、もう1つはペイロードの稼働強度や稼働時間を制限する熱的限界による制約です。
公表されている容量数値は、ペイロードがその制限範囲内で、その数値の根拠となっているトラフィックプロファイル、同時接続数、可用性の仮定を満たし続けられる場合にのみ、現実的なものとなります。もしビジネスケースにおいて、ペイロードが短期間しか対応できない負荷を想定している場合、その容量モデルと宇宙機の設計は、それぞれ異なるサービスを想定していることになります。
なぜ軌道が「手軽な解決策」を閉ざしてしまうのか
地上通信事業者は、容量不足に対処するために、電力や冷却設備を増強したり、別の拠点を追加したりします。しかし、軌道上ではこうした選択肢は一切ありません。許容範囲は打ち上げ時に固定されるため、ビームフォーミングのアーキテクチャもその範囲内に収まらなければなりません。
ビームフォーミングアーキテクチャでは、同じエンベロープ上でさらに別の要求が追加されます。より柔軟性の高いデジタルアーキテクチャは、より精密な指向制御、動的なカバレッジ、およびより高度な容量割り当てをサポートしますが、その柔軟性には処理負荷と消費電力のコストが伴います。アナログおよびハイブリッド方式では、その柔軟性を一部犠牲にすることで、デジタル処理の負荷を軽減します。
ビジネス上のポイントは、ビームフォーミング機能とネットワーク処理が、互いに独立した要件ではないということです。両者は、同じ宇宙機の設計要件の範囲内に収まらなければなりません。
数値が合わない場合、何が変化するのか
処理内容や電力需要は、多くの場合、遅れて決定されることがありますが、それは決して不注意によるものではありません。
詳細な負荷は、オンボードアーキテクチャと機能分割が決定されて初めて算出可能となるが、容量に関する数値は、資金調達の成立に向けて、それ以前に確定されていた。
こうしたコミットメントの後に実際の需要が確定した時点で、4つの選択肢が残り、そのそれぞれがビジネスケースの成否を左右する数値に影響を与えます：
- ビーム数が少ないということは、衛星1基あたりのセル数が少なくなることを意味するため、カバー範囲は広くなる一方で、同時にサービス対象となる市場は少なくなります。
- ビームあたりの帯域幅が狭くなると、各ユーザーが得られる通信速度が低下し、ブロードバンドとしての魅力が薄れますが、狭帯域IoTであれば依然として成立する可能性があります。
- 同時接続ユーザー数が減少すると、地域ごとのトラフィック量が減少し、需要が設計上限に近づくにつれて、輻輳やアクセス制限が発生する可能性が高まります。
- 可用性の低下により、サービス保証水準が一段階下がり、ブロードバンドの価格設定の根拠となっていた高い信頼性という数値からはかけ離れたものとなる。
実際には、これらの選択肢は組み合わせて適用されることが多く、どの組み合わせも収益創出能力を低下させる。これらは、予算が確定した後に適用される、販売可能な量の削減措置である。
慎重に選択された段階的な能力ロードマップは、商業的に見て妥当な方針である。
IoTから着手し、時間をかけてブロードバンドの容量レベルやビームを追加していくことで、ビジネスケース、価格設定、プラットフォームの選択を最初から整合させることができます。問題は、その点が後になって初めて判明する場合に限られます。最初から意図的に採用すれば、ロードマップによってビジネスケース、価格設定、プラットフォームの選択が最初から整合されます。しかし、適格性評価の段階で初めて判明した場合、サービスをサポートできないハードウェアに収めるために、すでに約束した内容を無理に縮小せざるを得なくなります。
いずれの場合でも、衛星が提供するビームや容量レベルは結局同じになります。異なるのは、それらに対してどのような約束がなされていたかという点です。当初から、事前に選定されたロードマップに従うことが計画でした。認定の段階でロードマップが変更を余儀なくされた場合、取締役会や顧客に対してすでに提示されていたブロードバンド容量、カバレッジ、または可用性の数値は、価格設定の根拠となった水準を維持できなくなります。
『Gatehouse Satcom 』の視点
Gatehouse Satcom この境界で機能する：ターゲット 5G NTN サービスを、ペイロードが満たすべき処理挙動へと変換する。
このマッピングは各プログラムごとに異なります。同じサービス定義であっても、搭載アーキテクチャ、機能の分割、およびソフトウェアの実装によって、処理負荷に実質的な違いが生じる可能性があります。各プログラムごとに個別の見積もりが必要です。以前のビルドの数値が新しいビルドにそのまま適用されることはほとんどありません。
私たちは常に次のような問いを投げかけています。特定のビーム構成、帯域幅、トラフィックプロファイル、および同時接続ユーザー数において、ネットワークは平均時およびピーク時にどの程度の処理負荷を生じさせるのか、そしてその負荷は宇宙機の電力および熱設計要件の範囲内に収まるのか、ということです。
その質問は、プラットフォームが決まる前にのみ意味があります。ハードウェアが決まった後にそれを尋ねても、自分が行き詰まっている理由を説明することしかできません。
選定されたCOTSハードウェアについて、まだ十分な確信が持てない場合は、この見積もりを基に、重点的な概念実証（PoC）およびリスク分析の段階に進むべきである。その目的は、プログラムを遅らせることではなく、ハードウェアが要求される処理負荷、消費電力、熱的挙動、および性能マージンに耐えられるかどうかといった重要な前提条件を早期に検証することにある。こうした検証結果により、プラットフォームの選定を覆すことが困難になる前に、実施・中止の判断基準が明確になる。
決定する前に見積もりを取りましょう
ペイロードの電力および熱的制約は、販売可能な容量の上限を定めており、プラットフォームを決定したり、誰かに具体的な数値を約束したりする前に、その上限を把握しておく必要があります。
プラットフォームの選定を行う前、また容量の数値に基づいて商業的な契約を結ぶ前に、処理および電力消費量の試算を行ってください。段階的なロードマップが適切な解決策である場合は、最初から慎重にその選択肢を選んでください。
待ったからといって、見積もりの精度は上がりません。先延ばしにすると、プラットフォームが確定した後にようやく見積もりが届き、その時点で調整できるのは、すでに販売済みのサービスだけになってしまいます。
