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

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

探査機のソフトウェアアップデートや大容量科学データを、部分的な欠損があっても最終的に完全な形で届けるにはどうすればよいか。CCSDS 727.0-Bで規定されるCFDPのクラス1/クラス2、NAKベースの選択的再送、惑星間遅延に耐える確認応答設計を、TCPのSACKとの類比と確率的な往復回数の見積もりから理解する。

前提知識: space-data-link-protocol

CFDPファイル転送選択的再送CCSDS信頼性転送

この回で学ぶこと

前回は、探査機から送られてくるビット列をフレームという固定的な単位に区切り、さらに**仮想チャンネル(Virtual Channel)**によって複数のデータ種別(テレメトリ、科学データ、ファイルなど)を1本のRFリンクの上で多重化する仕組みを学びました。これは「途切れなく流れ続ける連続的なストリーム」をどう管理するか、という問題意識に基づく設計でした。

しかし探査機の運用には、ストリームとは違う性質のデータを扱わなければならない場面が数多くあります。たとえば、

探査機に搭載されたフライトソフトウェアのアップデートファイルを地上から送り込む
カメラで撮影した画像や分光計のデータなど、まとまった科学データファイルを地球に持ち帰る

といった作業です。これらに共通するのは、「たとえ転送の途中でビットの一部が失われても、最終的にはファイル全体が1バイトも欠けることなく揃っていなければ意味がない」という要求です。フライトソフトウェアの一部が欠けたまま書き込まれれば探査機は起動すらしなくなるかもしれませんし、貴重な観測画像の一部が永久に欠損すれば、その観測機会は二度と取り戻せません。

この「ファイルという単位で、最終的な完全性を保証しながら転送する」という、フレーム多重化よりも一段高いレイヤーの仕事を担うのが、この回で扱う CFDP (CCSDS File Delivery Protocol) です。CCSDSの勧告書 727.0-B に規定されており、名前に反して「ファイルの配送(Delivery)」を保証するプロトコルという意味合いが強い設計になっています。この回では、CFDPがどうやって欠損を検出し、どこを直せば効率的かを判断し、しかも往復に数十分もかかる惑星間リンクの上でそれを実用的な時間内にやってのけるのかを、数式を交えて理解します。

直感的導入: ストリームからファイルへ

前回学んだフレーム多重化は、いわば「ベルトコンベアの上に色分けした荷物を並べて流し続ける」ような仕組みでした。ベルトコンベアの上の荷物(フレーム)が1つ2つ落ちても、次の荷物は気にせず流れ続けます。テレメトリのような周期的に更新されるデータであれば、多少の欠損があっても次の更新値が来れば実用上は問題ありません。

一方、ファイル転送はまったく性質が異なります。1つのフライトソフトウェアの実行ファイルや1枚の画像ファイルは、内部で強く依存し合ったバイト列の集合体です。途中の1kB分が欠けたバイナリファイルは、単に「ちょっと画質が落ちた画像」にはならず、多くの場合まったく解釈不能なゴミになります。つまりファイル転送に必要なのは、フレームレベルの「流し続ける」設計思想ではなく、「欠けている部分を後から正確に特定し、そこだけをピンポイントで埋め直す」という修復志向の設計思想です。

CFDPはこの発想を、次の2段構えで実現します。

送信側は転送対象のファイルを、下位のフレーム層が運べる大きさのセグメント(File Data PDU)に分割し、それぞれにファイル先頭からのオフセット(バイト位置)を付けて連続的に送り出す。
受信側は受け取ったセグメントをオフセット情報をもとに元のファイルの形に並べ直しながら、「まだ受け取っていないオフセット範囲」を常に把握しておく。転送がひと通り終わった段階で、その欠損範囲だけをピンポイントで送信側に伝え、再送してもらう。

この「欠損している範囲だけを名指しで伝える」という部分が、CFDPの信頼性転送の心臓部です。以下、これを段階的に定式化していきます。

PDUとトランザクション: CFDPの基本構成要素

CFDPは、1回のファイル転送を1つのトランザクションとして管理します。トランザクションの中でやり取りされる制御・データの単位を PDU (Protocol Data Unit) と呼び、主に次の種類があります。

Metadata PDU: ファイル名、ファイルサイズ、転送オプション(クラス1かクラス2か、など)といった、トランザクションの開始時に一度だけ送られる管理情報。
File Data PDU: ファイル本体を切り出したセグメントで、(オフセット, データ長, データ本体) という形を持ちます。このオフセットこそが、後で欠損範囲を特定するための鍵になります。
EOF (End-of-File) PDU: ファイル全体を送り終えたことを示す合図で、ファイル全体のチェックサム(あるいはCRC)を含みます。
NAK (Negative Acknowledgement) PDU: 受信側が「まだ受け取っていないオフセット範囲のリスト」を送信側に通知するためのPDU。
Finished PDU / ACK PDU: 受信側がファイルの完全性検証(チェックサム照合)の結果や、トランザクションの終了を送信側に伝えるための応答PDU。

ここで注意すべき点があります。CFDPは、フレームの中身が1ビットも壊れていないことまでは保証しません。それは前回学んだ宇宙データリンクプロトコルの層(フレームのCRCと、さらに下の誤り訂正符号の層)がすでに引き受けている仕事です。CFDPが向き合っているのは、「そもそもフレームが1枚丸ごと届かなかった」場合、つまり下位層が訂正しきれずに破棄したフレームや、リンクが一時的に途切れた(可視時間外に出た、深宇宙の太陽合などによる遮断)ことによって生じるPDU単位の欠落です。CFDPは、届いたPDUの中身は正しいという前提のもとで、「どのPDUがそもそも届いていないか」だけに関心を持つプロトコルだ、と整理しておくと、前回・前々回の内容との役割分担がすっきり見えてきます。

クラス1とクラス2: 確認応答の有無という設計選択

CFDPは転送の信頼性レベルに応じて2つの転送クラスを用意しています。

クラス1(Unacknowledged, 確認応答なし)。 送信側はMetadata PDU・File Data PDU・EOF PDUを一方的に送り切るだけで、受信側からの応答を一切待ちません。実装が単純で、往復のやり取りが不要なぶん遅延が最小になりますが、途中で失われたFile Data PDUがあっても検出・再送の仕組みが存在しないため、そのファイルは欠損したまま受信側に残ります。低優先度のエンジニアリングデータの配布や、後述するようにDTNのBundle Protocol(前々回)の再送機構と組み合わせて使う場合など、CFDP自身が再送を担う必要のない場面で使われます。

クラス2(Acknowledged, 確認応答あり)。 NAK PDUとFinished/ACK PDUによる往復のやり取りを使い、欠損したFile Data PDUを検出し、選択的に再送します。往復にかかる時間と、トランザクションの状態を送受信双方が転送完了まで保持し続ける必要があるというコストと引き換えに、最終的にファイル全体が完全な形で届くことを保証します。フライトソフトウェアのアップデートや、再取得の効かない貴重な観測データなど、「絶対に欠けてはならない」ファイルの転送にはクラス2が使われます。

以下では、CFDPの信頼性転送の核であるクラス2の選択的再送の仕組みを詳しく見ていきます。

選択的再送とNAK: TCPのSACKとの類比

クラス2の受信側は、受け取ったFile Data PDUのオフセットを記録しながら、ファイル全体の中で「まだ受信できていないオフセット区間」の集合、いわゆるギャップリストを管理します。転送がひと通り終わった(EOF PDUを受け取った)時点で、受信側はこのギャップリストを

\mathcal{G} = \{ [o_1^{\text{start}}, o_1^{\text{end}}),\ [o_2^{\text{start}}, o_2^{\text{end}}),\ \dots \}

という区間のリストとしてNAK PDUに詰め、送信側に送り返します。送信側はこのリストで指定された区間だけを再送します。これはファイル全体を送り直すのではなく、本当に欠けている部分だけをピンポイントで埋め直す、非常に効率的な修復操作です。

この仕組みは、地上のインターネットにおけるTCPのSACK (Selective Acknowledgment) オプションと本質的に同じ発想です。素朴なTCP(SACKなし)は「次に期待しているバイト番号」という単一の値(累積ACK)しか報告できないため、ウィンドウ内で複数のセグメントが飛び飛びに失われると、実際には届いているセグメントまで無駄に再送してしまう(いわゆるGo-Back-N的な非効率)という弱点を持ちます。SACKオプションは、受信側が「どの区間が届いていて、どの区間が届いていないか」を非連続なブロックのリストとして報告できるようにすることで、送信側が本当に欠けている部分だけを再送できるようにしました。CFDPのNAK PDUのギャップリストは、まさにこのSACKのブロックリストと同じ役割を、ファイル転送という文脈で果たしていると考えると理解しやすいはずです。

定式化: 選択的再送に必要な往復回数を確率的に見積もる

選択的再送がどれほど効率的かを、簡単な確率モデルで定量的に見てみましょう。

ファイルが $N$ 個のFile Data PDUセグメントに分割されているとします。個々のセグメントが(下位層の誤り訂正で救えなかった破棄や、一時的なリンク途絶により)独立に失われる確率を $p$ とし、成功して届く確率を $q = 1-p$ とします。

第1ラウンド(初回送信)。 $N$ 個すべてを送った直後に欠損しているセグメント数 $M_1$ は、二項分布 $M_1 \sim \text{Binomial}(N, p)$ に従い、期待値は

\mathbb{E}[M_1] = Np

第 $k$ ラウンド以降(選択的再送)。 NAK PDUを受け取った送信側は、欠損している $M_{k-1}$ 個のセグメントだけを再送します。再送されたセグメントも同じ確率 $p$ で独立に失われるとすると、

\mathbb{E}[M_k \mid M_{k-1}] = p\, M_{k-1} \quad \Longrightarrow \quad \mathbb{E}[M_k] = N p^{k}

つまり、期待欠損数はラウンドを重ねるごとに $p$ 倍ずつ幾何級数的に減少していきます。これが、送信側と受信側が往復を重ねながらファイルを完全な形に近づけていく過程の定量的な姿です。

「欠損の期待数がおよそ1個を下回った時点で、ほぼ確実に転送が完了している」とみなすと、必要なラウンド数 $K$ の目安は $N p^K < 1$ を解いて、

K > \frac{\ln N}{\ln(1/p)}

で与えられます。これは $N$ に対して対数的にしか増えません。たとえば $N = 1000$ セグメント、 $p = 0.01$ (1%のセグメント損失率)のリンクでは、

\mathbb{E}[M_1] = 1000 \times 0.01 = 10, \qquad \mathbb{E}[M_2] = 1000 \times 0.01^2 = 0.1

となり、 $K \approx \ln(1000)/\ln(100) \approx 1.5$ より、わずか2ラウンド程度の往復でほぼ完全なファイルが揃う計算になります。

さらに、 $N$ が大きく $p$ が小さい極限ではポアソン近似が使え、 $k$ ラウンド後に欠損が完全にゼロになっている確率は近似的に

P(M_k = 0) \approx \exp\!\big(-N p^k\big)

で評価できます。上の例では $P(M_2=0) \approx \exp(-0.1) \approx 0.905$ となり、2ラウンドの時点で9割超の確率でファイルが完全に揃っていることが分かります。

比較: 選択的再送がない場合

この効率性のありがたみは、もし選択的再送の仕組みがなく、1個でもセグメントが欠けていたらファイル全体を最初から送り直すしかない、という素朴な方式と比較するとよく分かります。この方式で1回の送信がすべて成功する確率は

P(\text{全セグメント成功}) = q^N = (1-p)^N

先ほどと同じ $N=1000$ , $p=0.01$ で計算すると、 $(0.99)^{1000} \approx 4.3 \times 10^{-5}$ という極めて小さい値になり、期待される再送回数(幾何分布の平均)は

\mathbb{E}[\text{必要な全体送信回数}] = \frac{1}{q^N} \approx 2.3 \times 10^{4} \ \text{回}

にも達してしまいます。セグメント単位で欠損箇所を特定し、そこだけを直すか(選択的再送、期待往復回数 $O(\log N)$ )、それともファイル全体の運を天に任せて送り直すか(全体再送、期待試行回数 $O(1/q^N)$ 、 $N$ に対して指数的に悪化)——この差が、CFDPがなぜNAKベースの選択的再送を採用しているかの数理的な理由です。

惑星間遅延に耐える設計: 確認応答をなるべく減らす

ここまでの議論では「1ラウンドあたり1往復」という前提を置きましたが、深宇宙リンクではこの1往復そのものが致命的に高くつきます。火星との往復光通信遅延(round-trip light time, RTLT)は地球と火星の相対位置によって約8分から48分程度まで変動し、木星・土星といった外惑星ではさらに長く、ボイジャー探査機のような太陽系外縁に達した探査機では片道の光時間だけで20時間を超えます。

もしCFDPが、地上のTCPのようにセグメント1つひとつに対して逐一ACKを返す設計だったらどうなるでしょうか。 $N=1000$ セグメントの火星向けファイルを、RTLT 40分の環境でセグメントごとに逐一確認応答していたら、往復待ちだけで $1000 \times 40\,\text{分} \approx 27.8\,\text{日}$ もかかってしまいます。これは全く実用的ではありません。

CFDPはこの問題を、次のような設計上の工夫で回避しています。

NAK方式(欠損だけを報告する)。 届いたものを逐一肯定応答するのではなく、届いていないものだけを否定応答で報告します。健全なリンクではほとんどのセグメントが1回で届くため、報告すべき内容自体が(前節で見た通り)ラウンドを追うごとに指数的に小さくなり、往復のたびに送るべき情報量も減っていきます。
Deferred NAKモード(遅延NAKモード)。 受信側は、セグメントを受け取るたびに逐一NAKを返すのではなく、EOF PDUを受け取ってファイル全体の送信が完了したと分かるまでギャップの報告を溜め込み、まとめて1通のNAK PDUとして送ります。これにより、 $N$ 個のセグメントを送るという長い送信フェーズの間は往復を一切必要とせず、フェーズの最後にまとめて1往復(前節の第1ラウンド分)を消費するだけで済みます。
RTLTを考慮したタイマー設計。 送信側・受信側のタイマー(NAK待ちタイマー、ACK待ちタイマーなど)は、そのリンクの既知のRTLTをもとに設定されます。RTLTを無視した短いタイマーを使うと、実際にはまだ応答が光の速さで戻ってきている途中なだけなのに「応答が来ない」と誤判定し、不要な再送を繰り返してしまう(輻輳制御のない環境でこれが起きると帯域を無駄に消費し続けます)。

この設計により、前節で見た「必要な往復回数はおよそ $O(\log N)$ 回」という性質と組み合わさって、全体の転送時間はおおむね

T_{\text{total}} \approx T_{\text{send}} + K \times \text{RTLT}

程度に収まります。ここで $T_{\text{send}}$ はファイル全体を1回送りきるのに必要な時間、 $K$ は前節で導いた対数オーダーのラウンド数です。逐一ACK方式の $N \times \text{RTLT}$ と比べて、この差は $N$ が大きいファイルほど圧倒的なものになります。

実務での使われ方

CFDPはNASA/JPL、ESA、JAXAをはじめとする各宇宙機関で、実運用のファイル転送プロトコルとして広く採用されています。

フライトソフトウェアアップデート。 火星探査ローバー(Curiosity、Perseveranceなど)や周回機のフライトソフトウェアの更新は、欠損が許されない典型例です。地上局からのアップリンクにクラス2 CFDPを用い、選択的再送によって送信されたバイナリが1バイトも欠けていないことをチェックサムで確認したうえで、探査機側で書き込みが実行されます。

科学データのダウンリンク。 火星探査機の間では、ローバーが取得した画像データを直接地球に送らず、周回機(MRO、MAVENなど)を中継点とする2ホップアーキテクチャ(中継通信の回で学んだ内容です)を経由することが一般的で、この中継リンクの上でもCFDPによるファイル単位の信頼性転送が使われています。

フライトソフトウェアフレームワークへの組み込み。 NASA/JPLが開発し多くの小型衛星・惑星探査ミッションで採用されている飛行ソフトウェア基盤 core Flight System (cFS) には、CFDPを実装した標準アプリケーション(CF App)が含まれており、ミッションごとに一から実装し直す必要がないよう部品化されています。これにより、CFDPは大型フラッグシップミッションだけでなく、CubeSatクラスの小型ミッションにも比較的手軽に導入できるようになっています。

DTN(Bundle Protocol)との関係。 前々回学んだ DTN (Delay/Disruption Tolerant Networking) のBundle Protocolは、接続が間欠的にしか得られないネットワーク全体にわたってデータを蓄積・転送する、ネットワーク層に近い「Store-and-Forward」の仕組みでした。これに対してCFDPは、1つの送信元から1つの宛先までを結ぶファイル転送というアプリケーション寄りの役割を担っています。両者は競合するものではなく、地上のインターネットにおける「TCP/IPの上でFTPが動く」という関係に近い形で、次の2通りの使われ方が整理されています。

CFDP単独での利用。 探査機と地上局(あるいは探査機と中継機)が直接つながる、比較的単純な点対点リンクでは、CFDPが宇宙データリンクプロトコルのフレーム層の上に直接載って、それ単体で信頼性転送を完結させます。これが従来の主流の使われ方です。
Bundle Protocolの上位層としての利用。 複数の中継ノードをまたいでバンドルが転々と蓄積・転送されるようなDTN的なネットワーク構成では、CFDPのファイル転送セッション自体をBundleの中に載せて運び、ネットワーク全体の経路制御・蓄積転送はBundle Protocol側に任せる、という構成が取られることがあります。この場合CFDPは「ファイルという単位への分割・再構成・完全性検証」という役割に専念し、「途切れがちな複数ホップをどう経由させるか」という役割をBundle Protocolに委ねる、階層的な役割分担になります。

このように、CFDPは単体のプロトコルとしても、より大きなDTNアーキテクチャの一部品としても機能できる柔軟性を持っており、これが宇宙機関の間で長年にわたり標準的なファイル転送手段として使われ続けている理由の一つです。

演習問題

あるファイルが $N = 500$ 個のFile Data PDUセグメントに分割されており、リンクのセグメント損失率が $p = 0.05$ であるとします。第1ラウンド、第2ラウンド終了時点での欠損セグメント数の期待値 $\mathbb{E}[M_1]$ 、 $\mathbb{E}[M_2]$ をそれぞれ求め、 $N p^K < 1$ を満たす最小の整数ラウンド数 $K$ を求めてください。
問1と同じ $N=500$ , $p=0.05$ のリンクで、選択的再送を使わずファイル全体を1回でも欠損なく送り切るまで全体を送り直し続けるとした場合の、期待される全体送信回数 $\mathbb{E}[1/q^N]$ を計算し、問1で求めた選択的再送のラウンド数と比較してください(この差が意味することを1〜2文で説明すること)。
木星探査機とのリンクで往復光時間(RTLT)が90分であるとします。 $N = 2000$ セグメントのファイルを、(a) セグメントごとに逐一ACKを返す方式、(b) この回で学んだdeferred NAKモード(往復回数 $K \approx 2$ )、のそれぞれで転送した場合に、往復待ちだけでどれだけの時間差が生じるか概算してください。
クラス1(確認応答なし)が適した状況と、クラス2(確認応答あり、選択的再送)が適した状況を、それぞれ具体的な転送対象データの例を1つずつ挙げて説明してください。また、CFDPが下位層(宇宙データリンクプロトコルのフレームCRCや誤り訂正符号)にどこまでの仕事を任せ、自分自身はどこから先の欠損だけに責任を持つのか、この回の内容をもとに整理してください。

まとめと次回予告

CFDPは、フレーム単位の多重化(前回)やBundle Protocolによる蓄積転送(前々回)よりも一段高い、「ファイルという単位で最終的な完全性を保証する」というレイヤーの仕事を担うプロトコルです。クラス1とクラス2という2つの信頼性レベルを使い分け、クラス2ではNAKベースの選択的再送によって、TCPのSACKに似た発想で欠損部分だけをピンポイントに修復します。そして何よりも重要なのは、往復に数十分から数十時間もかかる惑星間リンクの上で実用的に動作するよう、確認応答の頻度そのものを最小化する(deferred NAKモード、対数オーダーの往復回数)という設計思想が随所に貫かれている点でした。

次回は、前々回のDTN・前回の宇宙データリンクプロトコルの議論を踏まえつつ、フレーム構造をさらに掘り下げた AOS宇宙データリンクプロトコル (Advanced Orbiting Systems Space Data Link Protocol) に軽く触れ、複数のミッション・複数の物理チャンネルにまたがるより複雑なデータリンク層の構成を見ていきます。

参考文献

CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)
CCSDS 720.2-G, CFDP - Introduction and Overview
RFC 2018, TCP Selective Acknowledgment Options
V. Cerf et al., Delay-Tolerant Networking Architecture, RFC 4838
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76