NTNのすべてのサービスは、ひとつのアイデアから始まり、軌道上で機能するものとして完成しなければなりません。この2つの点の間には長い道のりがあり、私たちはこの25年間、どこが順調に進み、どこで困難に直面するかを学び続けてきました。本稿では、私たちがお客様を導くのと同じ方法で、その道のりを3つの段階に分けて解説し、各段階でプロジェクトが躓きやすい特定の決定事項について詳しく見ていきます。
設計が完全に 3GPP 規格に完全に準拠していても、実運用では期待通りの性能を発揮できないサービスが生まれることがあります。なぜなら、規格はシステムが「何をしなければならないか」を定義しているだけで、特定の衛星が特定のサービスエリアにおいて、それを適切に実行できるかどうかは定義していないからです。そのギャップこそが課題の核心であり、それはいくつかの予測可能な箇所に集中しています。
Gatehouse Satcom は、業界で現在採用されているNTN規格の策定に携わる3GPP 代表団の積極的なメンバーです。当社のソフトウェアは現在、軌道上で稼働しており、当社のペイロードソフトウェアを搭載した衛星と、地上の標準化されたデバイスとの間で、初の商用通信リンクの確立に成功しました。当社の顧客は、老舗の衛星事業者から新しいサービスを構築するスタートアップ企業まで多岐にわたり、その多くは本市場における先駆者です。
その経験が、私たちの働き方を形作りました。
この問題に取り組む一つの方法は、「分析」「検証」「運用」という3つの段階を経ることです。
- Analyze を使えば、ハードウェアに資金を投じる前に、そのサービスで何ができるかを把握できます。
- Validateは、実際の機器上で検証を行い、その検証結果に基づいて計画を修正できる余地を残しています。
- 「運用」フェーズでは、立ち上げから本番運用に至るまでのプロセスを担当します。各フェーズは、特定の種類の決定を確定させるために設けられており、その決定は変更可能な段階で行われます。また、立ち上げに向けて段階が進むごとに実行の余地が狭まっていくため、フェーズの順序も重要です。
すべてのお客様が、当社にこれら3つのサービスをすべて必要とするわけではありません。すでに実現可能性調査を終えており、検証を必要としているお客様もいれば、検証は完了しているものの、本番運用への移行を支援してほしいというお客様もいらっしゃいます。これらのフェーズはプロセス全体を表していますが、お客様がどの段階にいても、その段階からサポートを開始いたします。
フェーズ1 – 分析
Analyzeは、ハードウェアへの投資を行う前に、主に1つの疑問に答えを出します。それは、「そのサービスは、理想的な条件下だけでなく、サービス提供エリア全体において、ビジネスケースで求められる要件を満たすことができるか」というものです。
この段階は、その後の段階に比べれば短期間ですが、取り返しのつかない決定が下される段階でもあります。衛星の基本的な信号伝送能力は、設計段階で決定され、打ち上げ時に確定します。ここでの作業は、まだ調整可能なうちにそれらの数値を正確に設定し、最良のケースではなく最悪のケースを想定してその規模を決定することです。
さまざまな信号条件下におけるリンクバジェットの実現可能性の算出
衛星のビームは広範囲をカバーしていますが、その範囲内の状況は一様ではありません。ビームの中心付近にある端末は、衛星までの経路が短く、信号も強くなります。一方、端にある端末は、経路が長く、信号も弱くなります。両者の差は大きいです。
高度約600kmを周回する小型衛星による NB-IoTSバンドで高度約600 kmを周回する小型衛星によるサービスの場合、デバイスあたりのリンク予算はビーム内において大幅に変化する。この例では、中心付近（最良ケース）では、デバイスあたりダウンリンクで約35～50 kb/s、アップリンクで約1.5～3 kb/sの伝送が可能である。 一方、端部（ワーストケース）では、同じシステムでも1デバイスあたりのダウンリンクは13～20 kb/s、アップリンクは0.6～1.5 kb/s程度にとどまります。中心ケースと端部ケースは、同じ衛星の同じ通過経路における状況を示しています。この差によって、サービスがカバレッジ全域で目標を達成できるか、それとも衛星の真下でのみ達成できるかが決まります。
つまり、「分析」 段階における真の選択は、システムをどのように設計するかという点にある 。最悪のケースを想定して設計すれば、コストは高くなるが、サービスは全運用範囲にわたって維持される。一方、最良のケースを想定して設計すれば、ビームの端部がサービスの弱点となる。楽観的な設計案は、実現可能性調査書上では「許容範囲内」と見なされるが、その真価は軌道上で初めて明らかになる。その時点で能力は固定されており、向上させることはできない。「分析」 段階でこの点を明確にしておくことで、状況に応じて拡張可能なパイロットと、好条件でのみ機能するパイロットとを区別することができる 。
フェーズ2 – 検証
「分析」は 、理論上の数値を導き出します 。「検証」は 、その結果に基づいてシステムが理論通りに動作するかどうかを確かめるものであり 、その結果に対応するための時間と予算がまだ残っているうちに実施されます。
このフェーズでは、実際のハードウェア、ソフトウェア、機器を用いて、実験室内で軌道上の環境を再現します。実験室は宇宙そのものではありませんが、我々はそれを代替物ではなく、近似環境として扱います。実現可能性に関する仮定が成り立つかどうかを判断するには、この環境は十分に近いものです。ここで発見された問題は、低コストで修正できます。一方、打ち上げ後に同じ問題が発見された場合、修正がまったく不可能である可能性もあります。プロジェクトの継続を決定する上で最も重要なのは2つの結果であり、そのため、このフェーズでは2つの詳細な検証が行われます。
衛星の1周分の間、リンクを維持する
衛星の通過は、数分間にわたって地平線から地平線へと続きます。衛星は昇り、頭上を通過し、沈んでいきます。地上の端末に対する衛星の角度は通過中ずっと変化し、それに伴って通信強度も変化します。通信強度は、衛星が頭上にあるときに最も強く、通過の開始時と終了時に地平線付近にあるときは最も弱くなります。
通信事業者が求める結果は、測定対象のリンクが、測定区間内のあらゆる地点（最も性能が低い地点を含む）において、サービスの最低要件を満たしているかどうかです。最も性能が低い地点でも要件を上回っているリンクは、実現可能性の試算が正しいことを裏付け、サービスが確実に機能するという確かな証拠となります。一方、端部の地点で要件を下回ってしまうリンクは、まだ修正の余地がある実験環境における問題を特定することになります。どちらの結果も有用であり、サービス開始後よりも開始前に把握しておく方がはるかに有益です。
一度に十分な数のデバイスに対応する
2つ目の結果は、容量に関するものです。十分な電力を備えた衛星であれば、1つのデータチャネルではなく複数のチャネルを並行して稼働させ、より多くの端末に同時にサービスを提供することができます。この容量を増やす方法には効率的なものと非効率的なものがあり、その選択は、それを支えるための搭載電力が確保できるかどうかにかかっています。チャネルに電力を供給する能力がないままチャネルを追加すると、サービスが向上するどころか、逆に低下してしまう可能性があります。
「Validate」が明らかにするのは 、衛星が信号を伝送できるかどうかではなく、そのビジネスが依存する数のデバイスに対し、顧客が期待する品質でサービスを提供できるかどうかという点です。打ち上げ前に実際のコンポーネントを用いてこれを確認することこそが、その答えを得る価値がある理由なのです。
フェーズ3 – 運用
運用は打ち上げと同時に開始される。これは、プログラムにおいて後戻りできない唯一の境界線である。それ以前は、システムは調整可能である。しかし、運用開始後は、衛星が実際の環境下で実際の通信トラフィックを処理することになり、固定された要素と調整可能な要素との区別が明確になる。
「Analyze」 段階で固定要素が決定され、 打ち上げ時に確定されました。具体的には、 衛星の電力、ハードウェア、ビームがカバーする範囲などです。調整可能なのは、その固定された能力を、視野内にある各デバイスにどのように配分するかという点のみです。ただし、その調整は、以前の段階で設定された範囲内でのみ行われます。
リーチとキャパシティの間で固定リソースを配分する
軌道上において、最も明確な調整可能な判断は、多くの端末へのサービス提供と、接続が困難な端末への接続の間に、衛星の通信時間をどのように配分するかという点である。
状態の良い端末は通信時間をほとんど消費しないため、衛星は一度に多くの端末に対応することができます。一方、状態の悪い端末、ビームの端にある端末、遮蔽物がある端末、あるいはアンテナの感度が低い端末は、通信時間をより多く消費します。なぜなら、これらの端末に確実に信号を届けるためには送信を繰り返す必要があり、その繰り返しごとに、他の端末に対応できたはずの通信時間が消費されてしまうからです。
その結果、直接的なトレードオフが生じます。強力な中央集約型デバイスに通信時間を割り当てれば、約10台をカバーできるかもしれません。一方、同じ通信時間を、信号を数回中継する必要がある処理の難しいエッジデバイスへの接続に充てると、カバーできる台数は4台程度にとどまるでしょう。同じリソースを2つの方法で配分しただけで、サービス対象となるデバイスの数に2倍以上の差が生じるのです。
運用担当者は、そのサービスが対象とするデバイスの密度や種類に基づいて、その境界線を設定し、動的に移動させることもできます。つまり、ある地域ではカバー範囲を優先し、別の地域では容量を優先するなど、サービスのライフサイクルを通じて調整を行うのです。必要に応じて、軌道上の衛星のソフトウェアを更新することも可能です。ただし、こうした調整が行える範囲は、すべて打ち上げ前に固定されています。「運用（Operate）」 段階での裁量の幅は、「分析（Analyze）」および 「検証（Validate）」 段階での決定によって残された 範囲に限定されます 。
旅は目的地そのものではない
当社のソフトウェアは、規格に準拠しており、軌道上での実績があり、衛星上でも地上でも確実に動作します。しかし、ソフトウェアだけでは、事業者がアイデアを、顧客が信頼するサービスへと発展させることはできません。
その道のりが重要なのです。最悪のケースを想定した実現可能性分析。まだ対応の余地があるうちに、仮定を証拠へと変える検証段階。サービスの範囲がすでに確定した状態で開始されるローンチ。
「道のりそのものが方法である」。その行き着く先は、市場投入までの期間が短く、事業拠点全体で確実に機能し、ビジネスの基盤となるデバイスに対応できる、検証済みのサービスである。リスクを事前に排除した上で、より早くその目標に到達すること――これこそが、各フェーズを順序立てて進めることの価値である。
その道のりのどの段階にあっても、私たちは皆様の取り組みに加わることができます。新たにスタートを切るチームにとっては、「分析」フェーズが自然な入り口となります。これは、体系的な実現可能性調査を通じて、ビジネスケースを数ヶ月ではなく数週間という短期間で、具体的なリンク予算、カバレッジ、および容量の数値へと落とし込むものです。すでに一定の進捗があるチームの場合は、「検証」フェーズや「本番運用」フェーズから参画します。打ち合わせをご予約いただければ、皆様の現在の状況に合わせてサポートを開始いたします。
