ネットワーク・プロトコル#110

宇宙ネットワークにおけるマルチキャスト配信 — 1対多をどう効率化するか

メガコンステレーションの数百機の衛星や複数の同型ローバーに同じソフトウェアを配信するとき、CFDPのような1対1転送を人数分繰り返すのは非効率すぎる。必要帯域の数式でその非効率性を示し、FECとファウンテン符号的な発想がどう解決の糸口になるかを理解する。

前提知識: CFDP — ファイル単位で信頼性を保証する宇宙データ転送プロトコル

マルチキャストFECファウンテン符号メガコンステレーションLDPC

この回で学ぶこと

前回学んだ CFDP は、地上局から探査機1機へ、あるいは探査機から地上局へという1対1のファイル転送を、欠損があっても最終的に完全な形で届ける仕組みでした。NAKベースの選択的再送によって、欠けている部分だけをピンポイントで埋め直す——これがCFDPの核心でした。

しかし現代の宇宙通信には、CFDPが暗黙に前提としていた「送信者1、受信者1」という構図に収まらない場面が急速に増えています。

数百機から数千機の衛星からなるメガコンステレーションの全機、あるいはその一部の軌道面に、同じフライトソフトウェアのアップデートを配信したい
火星表面に展開された複数の同型ローバーやランダーに、共通の運用パラメータや辞書データを一斉に送り込みたい
周回機が中継点となって、地表の複数のセンサーノードに同じコマンドセットを配る

これらはすべて「同じデータを、複数の受信者に届ける」という1対多の配信問題です。CFDPを学んだ今、素朴に思いつくのは「CFDPによる1対1転送を、受信者の数だけ繰り返せばよいのでは」という発想です。この回では、まずその素朴な発想がなぜスケールしないのかを帯域の数式で確認し、そのうえで宇宙リンク特有の制約(信号強度のばらつき、再送の扱い、FECによる信頼性確保)を踏まえたマルチキャストという設計思想を見ていきます。

直感的導入: 1対1転送を繰り返すことの何が問題か

いま、あるデータ(たとえば50MBのソフトウェアアップデート)を、地上局から $N$ 機の衛星に配信したいとします。前回学んだCFDPをそのまま使うなら、最も素直な方法は、 $N$ 機それぞれに対して独立にクラス2のCFDPトランザクションを立ち上げ、順番に(あるいは並行に)ユニキャスト転送を行うことです。

この方式の問題は、送信側が消費する帯域が受信者数に比例して増えることです。1機あたりの転送に必要な帯域(あるいは送信時間×帯域幅として計算される総情報量)を $B_{\text{unicast}}$ とすると、 $N$ 機全員に届けるために送信側のアンテナ・送信機が実質的に送出しなければならない総情報量は、

B_{\text{total}} = N \times B_{\text{unicast}}

となります。地上のインターネットであれば、送信側から先はルーターが枝分かれして経路を複製してくれるので、送信元のサーバーが直接 $N$ 倍のデータを送り出す必要はないケースも多いのですが、宇宙リンクでは話が単純ではありません。1本のRFビームが物理的に電波を放射している以上、 $N$ 機それぞれに別個のユニキャストセッションとして同じデータを送れば、送信側の送信機は文字通り同じビット列を $N$ 回、律儀に送信し直すことになります。

地上局のダウンリンク送信時間(あるいはアップリンクの送信時間)が有限のパス可視時間の中に制約されていることを思い出すと、この $N$ 倍という係数がどれほど深刻かが分かります。可視時間が1回のパスで例えば10分しかないコンステレーション地上局のスケジュールの中で、 $N=100$ 機に同じ50MBのファイルを送るのに $B_{\text{unicast}}$ 相当の時間を100回分確保しなければならないとすれば、他の運用(テレメトリ受信、コマンド送信、他衛星との交信)に割ける時間がほとんど残らなくなってしまいます。

マルチキャストの発想は、この $N$ という係数を消し去ろうとするものです。もし複数の受信機が同じ周波数・同じタイミングで同じRF信号を同時に受信できるなら、送信側は1回だけデータを送出すればよく、理想的には

B_{\text{total}} \approx B_{\text{unicast}}

つまり受信者数 $N$ によらずほぼ一定の帯域で済むはずです。これは、地上局のアンテナビームの中に複数の衛星が同時に入っている場合(たとえば軌道面が近い衛星群を1つのビーム幅でカバーできる場合)や、そもそも1機の中継衛星が広いビームで多数の地上局あるいは地表ノードに同時にサービスしているような構成で、物理的に現実味を持つシナリオです。この回では、この理想と現実のギャップを埋めるために宇宙リンクのマルチキャストがどう設計されているかを見ていきます。

定式化: ユニキャスト繰り返しとマルチキャストの帯域比較

もう少し丁寧に定式化しておきましょう。1回のユニキャスト転送に必要な送信時間を $T_{\text{unicast}}$ 、リンクの利用可能な帯域幅を $W$ とすると、

B_{\text{unicast}} = W \cdot T_{\text{unicast}}

がおおよそのオーダーで、ユニキャスト繰り返し方式の総所要時間は

T_{\text{total}}^{\text{unicast-repeat}} = N \times T_{\text{unicast}}

と、受信者数に比例して線形に増えていきます。一方、理想的なマルチキャストでは、送信側は1回だけデータを送出すればよいので、

T_{\text{total}}^{\text{multicast}} \approx T_{\text{unicast}}

$N$ に依存しません。この差を比 $\eta$ として表すと、

\eta = \frac{T_{\text{total}}^{\text{unicast-repeat}}}{T_{\text{total}}^{\text{multicast}}} \approx N

となり、受信者数が増えるほどマルチキャストの優位性は直線的に拡大します。 $N=1$ (受信者が1機だけ)なら両者に差はなく、CFDPをそのまま1対1で使えば十分ですが、 $N$ が数十・数百のオーダーになるメガコンステレーションでは、この $\eta \approx N$ という係数は運用スケジュールを左右するほど大きな意味を持ちます。

ただし、後述するように、この「 $B_{\text{total}} \approx B_{\text{unicast}}$ 」という理想形は、宇宙リンク特有の事情によって単純には実現できません。以下、その課題を順に見ていきます。

課題1: 受信機ごとの信号強度・タイミングのばらつき

地上のIPマルチキャストであれば、ネットワーク中のルーターがパケットを電気的・光学的に複製して送り出すため、末端の受信者が信号を「物理的に共有」しているわけではありません。しかし宇宙リンクでのマルチキャストは、多くの場合、1本のRF信号を複数の受信機が同時に受信するという、より物理層に近い形で実現されます。

このとき問題になるのが、受信機ごとの条件の違いです。

信号強度(受信 $E_b/N_0$ )のばらつき。 送信アンテナのビーム内であっても、各衛星までの距離、ビーム中心からのオフセット角、受信側アンテナの利得は個体ごとに異なります。ある衛星は十分なマージンで受信できても、ビーム端に近い別の衛星は $E_b/N_0$ が数dB低く、ビット誤り率が桁違いに悪化しているかもしれません。
タイミング・ドップラーのばらつき。 各受信機は送信源に対して異なる相対速度・相対距離を持つため、受信するドップラーシフトや伝搬遅延がそれぞれ異なります。シンボル同期や搬送波再生を各受信機が独立に行う必要があり、「全員が同じタイミングで同じように復調できる」という前提は成り立ちません。

この結果、同じマルチキャスト送信に対して、ある受信機は全パケットを正常に受信できるが、別の受信機は一部のパケットを取りこぼす、という状況が構造的に発生します。しかも、どの受信機がどのパケットを取りこぼすかは受信機ごとにバラバラです。ここが、CFDPが前提としていた「1対1リンクの中でのギャップリスト管理」では対応しきれない、マルチキャスト特有の難しさです。

課題2: 誰が取りこぼしたかに応じた再送の設計

前回CFDPで学んだクラス2の選択的再送は、受信側が1つ、ギャップリストも1つでした。ところがマルチキャストでは、受信機が $N$ 台いれば、取りこぼしたパケットの集合(ギャップリスト)も最大 $N$ 通り存在しえます。ここで再送方法として、大きく2つの戦略が考えられます。

戦略A: 全員に一律再送する。 誰か1機でも取りこぼしたパケットがあれば、そのパケットを全受信機に向けてもう一度マルチキャスト送信します。実装は単純ですが、ある衛星だけがたまたま強いフェードに遭って多くのパケットを落とした場合、その1機のためだけに全員が同じ再送を(すでに受信済みであっても)再び浴びることになり、無駄が生じます。取りこぼす受信機の数が増えるほど、再送すべきパケットの合計(和集合)も増えていき、最悪の場合はほぼ全パケットを再送する羽目になります。

戦略B: 取りこぼした受信機だけに個別補完する。 マルチキャスト送信がひと通り終わった後、各受信機がCFDPのクラス2と同じ要領で個別にギャップリストを送り返し、その受信機だけをターゲットにした個別のユニキャスト補完送信を行います。無駄な再送は最小限に抑えられますが、受信機の数だけ個別セッションを管理する必要があり、応答を待つ往復の数も受信機ごとに発生するため、CFDPの回で見た「惑星間遅延に耐える設計」の恩恵を受けにくくなります。

実務では、この2つの中間、すなわち「多くの受信機が共通して取りこぼしたパケットは全員向けに再送し、少数の受信機だけが取りこぼした残りは個別に補完する」というハイブリッドな設計が取られることが一般的です。取りこぼし数の期待値がラウンドを重ねるごとに幾何級数的に減っていくという、CFDPの回で導いた

\mathbb{E}[M_k] = N_{\text{seg}}\, p^{k}

という関係(ここでは $N_{\text{seg}}$ はセグメント数)は、マルチキャストでも各受信機ごとに成り立ちますが、 $N$ 台の受信機全体で見た「和集合としての取りこぼしパケット集合」は、各受信機の取りこぼしパターンが独立だとすると受信機が増えるほど広がりやすいという性質を持ちます。したがって、再送のラウンド設計は「個々の受信機の取りこぼし確率」だけでなく「受信機集団全体としてどれだけのパケット種類をカバーし切れているか」という視点で考える必要があり、これが次に述べるFECベースのアプローチが好まれる理由につながっていきます。

課題3の解決策: FECによる信頼性確保とファウンテン符号的発想

戦略A・戦略Bのどちらも、結局は「誰が何を取りこぼしたか」を個別に追跡し、ピンポイントで再送するという、CFDPと同じ発想の延長線上にあります。これに対してマルチキャスト配信でより強力なのは、そもそも「誰が何を取りこぼしたか」を追跡しなくても済むように、送信するデータ自体に冗長性を持たせておくというアプローチです。

LDPC符号の回で学んだ前方誤り訂正(FEC)は、本来は1つの受信機がビット単位・シンボル単位で被る雑音による誤りを訂正するための仕組みでした。この考え方を、パケット単位の消失(パケットが丸ごと届かない、という前回CFDPで扱った種類の欠落)に対して拡張したものが、**消失訂正符号(erasure code)**です。

消失訂正符号の基本的な考え方はこうです。元のデータを $K$ 個の情報パケットに分割したうえで、それを冗長化して $K$ 個より多い $M$ 個( $M > K$ )の符号化パケットを生成して送信します。受信側は、送られた $M$ 個のパケットのうちどの $K$ 個でもよいので、合計 $K$ 個を集めることができれば、元のデータ全体を復元できます。

これが宇宙のマルチキャストと相性がよい理由は、まさに前節で述べた「受信機ごとに取りこぼすパケットの組み合わせがバラバラ」という状況にあります。もし各受信機がどのパケットを落としたかに関わらず、単に「必要な数さえ集まればよい」という条件で復元できるなら、送信側は「どの受信機が何を取りこぼしたか」を個別に把握して個別に再送を出し分ける必要がなくなります。単純に、追加の符号化パケットを送り続けるだけで、すべての受信機がそれぞれ独立に、自分の取りこぼし方に応じた必要数だけ集まった時点で復元を完了できるのです。

この発想をさらに推し進め、 $M$ をあらかじめ固定せず「受信側が復元に十分な数を集めるまで、いくらでも符号化パケットを生成し続けられる」という性質を持たせた符号族を、水源が尽きることなく水を流し続けるイメージから ファウンテン符号(fountain code) と呼びます。代表的な実装には LT符号(Luby Transform)や、その改良である Raptor符号があり、これらは受信側が集めた符号化パケットの数がおよそ $K(1+\varepsilon)$ 個( $\varepsilon$ は符号の効率に依存する小さな超過分)に達した時点で、高い確率で元の $K$ 個の情報パケットすべてを復元できるという性質を持ちます。

LDPC符号の回で学んだ疎な検査行列とメッセージパッシングによる復号の考え方は、実はこのファウンテン符号の復号アルゴリズムとも深く関係しています。LT符号の復号は、受信した符号化パケットと情報パケットの間の疎な接続関係をグラフとして表現し、次数1(まだ判明していない情報パケットをただ1つだけ含む)の符号化パケットから芋づる式に情報パケットを確定させていく、という反復的な手続きで進みます。これはLDPC符号のビリーフ伝搬(確率伝搬)復号と同じ、疎グラフ上でのメッセージパッシングという枠組みの一種と見なすことができます。

まとめると、消失訂正・ファウンテン符号的なアプローチをマルチキャスト配信に採用することで、次のような利点が得られます。

送信側は受信機ごとの個別のギャップリストを管理・応答する必要がなく、単純に符号化パケットを送り続ければよい(あるいは、必要量が事前に見積もれるなら固定数だけ送って終える)。
受信機は他の受信機の受信状況と無関係に、自分が集めたパケット数だけを基準に独立して復元判定ができる。
戦略Aのような「1機のために全員が同じ再送を浴びる」無駄も、戦略Bのような「受信機ごとの個別セッション管理」の煩雑さも回避できる。

一方で、消失訂正符号には「元データに対して常に一定の冗長オーバーヘッドが乗る」というコストがあり、CFDPのクラス2のような「本当に欠けている部分だけを正確に再送する」方式に比べると、リンク品質が良好で損失率が低い場合には送信データ量に無駄が生じやすいという側面もあります。実務では、リンクの損失特性(受信機ごとの損失率のばらつきの大きさ)と、往復遅延の大きさ(往復のたびに再送を出し分けるコストの大きさ)を天秤にかけ、CFDP的な選択的再送(戦略A/B)とFEC・ファウンテン符号的なアプローチのどちらを採るか、あるいは両者を組み合わせるかを設計することになります。

実務での使われ方

地上のIPマルチキャストとの類比。 地上のインターネットには古くから IPマルチキャスト(IGMP によるグループ管理、PIM によるマルチキャストルーティングツリーの構築など)という技術があり、1つのストリームを多数の受信者に効率よく配信する仕組みが実運用されています。地上では「ルーターがパケットを複製する」という形で $B_{\text{total}} \approx B_{\text{unicast}}$ に近い効率を実現していますが、宇宙リンクでは中継ノードでの複製よりも、この回で見たような「1本のビームを複数受信機が共有する」あるいは「FEC・ファウンテン符号で受信機間の取りこぼしの違いを吸収する」というアプローチの重要性が相対的に大きくなります。両者は「1対多をどう効率化するか」という同じ問題意識に対する、リンクの物理的性質に応じた異なる解法だと整理できます。

衛星放送・DVB規格でのファウンテン符号の実績。 ファウンテン符号(特にRaptor符号)は、宇宙リンクのマルチキャスト配信そのものではありませんが、衛星やモバイル網を使った放送規格である 3GPP MBMS や DVB-H のファイルダウンロード配信(FLUTE: File Delivery over Unidirectional Transport)において、多数の受信機に同じファイルを一方向配信する用途ですでに実運用されてきた実績があります。これは、この回で扱った「取りこぼし方が受信機ごとにバラバラでも、必要数さえ集めれば復元できる」という性質が、まさに一方向・多数受信機の放送型配信に適していることを裏付けています。

メガコンステレーションでの一斉ソフトウェア更新という将来像。 Starlinkに代表されるような数千機規模のメガコンステレーションでは、軌道面ごと・打ち上げバッチごとに大量の同型衛星が存在し、共通のフライトソフトウェアアップデートやパラメータテーブルを配信する必要が繰り返し発生します。1機ずつCFDPで律儀に配信していては地上局・地上ゲートウェイの帯域とスケジュールを圧迫してしまうため、ある軌道面・あるビーム内に同時に見えている複数機に対して、この回で見たようなマルチキャスト的配信(共通データの一括送出+FECによる個別の取りこぼし吸収)を組み合わせる設計は、今後のコンステレーション運用において重要性を増していく分野です。

複数ローバー・複数センサーノードへの一斉コマンド配信。 火星や月面に複数の探査機器(ローバー、着陸機、分散配置されたセンサーネットワーク)を同時展開するミッション構想でも、中継周回機から地表の複数ノードに共通のコマンドや時刻同期情報を一斉配信する需要があり、同様のマルチキャスト設計の考え方が応用されます。

演習問題

地上局からメガコンステレーションの $N = 60$ 機(1回の打ち上げバッチに相当)に、それぞれ20MBのソフトウェアアップデートを配信したい。1機あたりのユニキャスト転送に要する時間 $T_{\text{unicast}}$ を3分とするとき、(a) CFDPによるユニキャスト繰り返し方式での総所要時間、(b) 理想的なマルチキャストでの総所要時間、をそれぞれ求め、比 $\eta$ を計算せよ。
消失訂正符号を用いたマルチキャスト配信で、元データが $K=1000$ 個の情報パケットに分割されているとする。受信機Aはリンク品質が良く送信された符号化パケットの95%を受信でき、受信機Bはビーム端に近く80%しか受信できないとき、それぞれの受信機が復元に必要な最低限の符号化パケットを集めるためには、送信側は少なくとも何個の符号化パケットを送出する必要があるか(ファウンテン符号は $K$ 個をほぼちょうど集めれば復元できる理想的なものと仮定してよい)。両受信機の必要送出数が異なることの意味を1〜2文で説明せよ。
本文で述べた再送戦略A(全員に一律再送)と戦略B(取りこぼした受信機だけに個別補完)について、受信機の数 $N$ が非常に大きく、かつ各受信機の取りこぼしパターンがほぼ独立でバラバラな場合、それぞれの戦略でどのような非効率が生じるかを説明し、FECベースのアプローチがなぜこの状況で有利になるかを論じよ。
LDPC符号の回で学んだメッセージパッシング復号と、この回で紹介したLT符号(ファウンテン符号)の復号(次数1のパケットから芋づる式に情報パケットを確定させる手続き)の類似点と相違点を、それぞれが対象とする誤り・消失の単位(ビット/シンボル単位かパケット単位か)に注目して整理せよ。

まとめと次回予告

CFDPが解決したのは「1対1のリンクで、いかに効率よく完全なファイルを届けるか」という問題でした。この回で見たマルチキャスト配信は、その先にある「同じデータを複数の受信者に届けるとき、送信側の帯域を受信者数で割り増ししないためにはどうするか」という、1対多に特有の問題でした。素朴なユニキャスト繰り返しでは総帯域が $B_{\text{total}} = N \times B_{\text{unicast}}$ と線形に増えてしまう一方、理想的なマルチキャストはこれをほぼ受信者数によらない水準に抑えられます。ただし宇宙リンクでは受信機ごとの信号強度・タイミングのばらつきという物理的制約があるため、再送を「誰が何を取りこぼしたか」で個別に管理する方式(CFDP的な選択的再送の延長)と、FEC・ファウンテン符号によって「取りこぼし方の違いそのものを吸収してしまう」方式との間でトレードオフが生じることを見ました。

次回は、この回で触れたメガコンステレーションという運用形態そのものに焦点を当て、数千機規模の衛星群が地上局・地上ゲートウェイ・衛星間リンクとどう連携して通信アーキテクチャを構成しているのか、メガコンステレーション通信アーキテクチャを概観します。

参考文献

CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)
CCSDS 727.2-G, CCSDS File Delivery Protocol (CFDP) - Introduction and Overview (マルチキャスト拡張に関する議論を含む版)
M. Luby, “LT Codes,” Proceedings of the 43rd Annual IEEE Symposium on Foundations of Computer Science, 2002
A. Shokrollahi, “Raptor Codes,” IEEE Transactions on Information Theory, vol. 52, no. 6, 2006
RFC 6726, FLUTE - File Delivery over Unidirectional Transport
B. Quinn, K. Almeroth, RFC 3170, IP Multicast Applications: Challenges and Solutions
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76