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

COP-1 — コマンドを確実に、正しい順序で届ける再送制御プロトコル

地上から探査機へのコマンド送信は、テレメトリと違って1個の欠落・順序の入れ替わりが致命的になりうる。CCSDS 232.1-BのCOP-1を、FARM/FOPという2つの状態機械とCLCW・タイムアウト再送の数式で理解する。

COP-1CCSDSCLCW再送制御コマンドリンク

この回で学ぶこと

これまでの回では主に、探査機から地上へ流れてくるテレメトリ(観測データや状態監視データ)をどう変調し、どう符号化し、どう誤りから守るかを扱ってきました。しかし探査機と地上局の通信はもちろん双方向です。地上から探査機へは、姿勢変更・観測シーケンスの起動・軟件更新・安全モード解除といったコマンドが送られます。この「アップリンク」の世界には、テレメトリの世界とは質的に異なる要求があります。

テレメトリはある程度の欠落を許容できます。1つのテレメトリフレームが化けて捨てられても、次のフレームでまた新しい観測値が送られてくるので、グラフに小さな欠測点ができるだけで済むことがほとんどです。ところがコマンドはそうはいきません。「姿勢制御スラスタを0.5秒噴射せよ」というコマンドが1個欠落すれば、探査機は期待された姿勢変更を行いません。さらに悪いのは順序が入れ替わるケースです。たとえば「カメラの電源を切る」という保護コマンドの前に「カメラのシャッターを開く」というコマンドが来てしまえば、想定外の状態遷移を引き起こし、最悪の場合は機器の損傷につながります。つまりアップリンクには、テレメトリにはなかった2つの強い要求が課されます。(1) コマンドは1個も欠落してはならない、(2) コマンドは送信した順序どおりに実行されなければならない。

この2つの要求(完全性と順序保証)を満たすために、CCSDSは COP-1 (Communications Operation Procedure-1) という再送制御プロトコルを規定しています。COP-1はCCSDS 232.1-B Communications Operation Procedure-1 に定義されており、前回扱ったTC(Telecommand)宇宙データリンクプロトコルの上に乗る形で動作します。地上のネットワークに親しんだ人は「これはTCPみたいなものか」と思うかもしれません。実際に考え方の一部は似ていますが、深宇宙特有の制約(片道数分から数時間に及ぶ光行時間、限られた計算資源、そして「確実性」への極端な要求)によって、TCPとはかなり違う、もっと単純で保守的な設計になっています。この回では、COP-1の心臓部である2つの状態機械——FARM(受信側)とFOP(送信側)——の協調動作を数式で追いながら、なぜこの設計に落ち着いたのかを見ていきます。

直感的な導入: 書留郵便のアナロジー

COP-1の仕組みを一言でたとえるなら、通し番号付きの書留郵便です。

地上局(送信側)は、探査機に送るコマンドフレームの1つ1つに、0から255まで巡回する連続な通し番号 $N(S)$ を振ります。探査機(受信側)は、次に来るべき番号をあらかじめ知っており(「次は番号17のはずだ」)、届いたフレームの番号がその期待値と一致していれば受理して次の期待値をインクリメントし、一致していなければ「まだ届いていません」と地上に伝えます。地上局はこの返事を待って、届いていなければ同じフレームを再送します。

この単純な仕組みには、テレメトリの誤り訂正符号(前方誤り訂正、FEC)だけでは実現できない性質があります。FECは「ビット誤りをその場で直す」ものですが、フレーム全体が丸ごと失われた場合(強いフェーディング、レンジング競合、送信タイミングのミスなど)には無力です。COP-1は、そもそも失われたフレームを検知し、同じ番号で作り直して送り直すことで、アップリンク全体としての完全性を保証します。そして受信側が番号順にしか受理しないことで、順序も自動的に保証されます。

以下、この「通し番号」「期待値」「再送要求」を、正式な状態機械の言葉に翻訳していきます。

COP-1の2つの状態機械: FARMとFOP

COP-1は、送信側(通常は地上局)で動く FOP (Frame Operation Procedure) と、受信側(通常は探査機の搭載データ処理システム)で動く FARM (Frame Acceptance and Reporting Mechanism) という、独立した2つの有限状態機械の協調で成り立っています。両者はTCフレームの中の $N(S)$ フィールドと、テレメトリに乗せて送り返される CLCW (Command Link Control Word) という32ビットの制御ワードを介してだけ通信します。

FARM(受信側の状態機械): 受理判定ロジック

FARMは、探査機側で1本の仮想チャネルごとに1つ保持される状態機械で、中心的な状態変数は次の2つです。

$V(R)$ : 次に受理すべきフレームのシーケンス番号(期待値)。0から255までを巡回するmod-256のカウンタ。
$W$ : 正の受理ウィンドウ幅。 $V(R)$ から $V(R)+W-1 \pmod{256}$ までの範囲にあるフレームだけを「受理検討の対象」とする。

受信したフレームのシーケンス番号を $N(S)$ とすると、FARMの受理判定は次のように場合分けされます。

\text{action}(N(S)) = \begin{cases} \textbf{受理}, \ V(R) \leftarrow V(R)+1 \!\!\pmod{256} & \text{if } N(S) = V(R) \\[4pt] \textbf{棄却}(\text{再送要求フラグを立てる}) & \text{if } N(S) \in \{V(R){+}1,\dots,V(R){+}W{-}1\} \!\!\pmod{256}\\[4pt] \textbf{棄却}(\text{無視}) & \text{otherwise (ウィンドウ外)} \end{cases}

つまりFARMは、期待値ちょうどのフレームだけを受理し、期待値より先の番号(まだ来るべきでないフレームが先に届いた=順序前後)はウィンドウ内であっても捨て、再送を要求します。これがTCPの受信バッファとの決定的な違いです。TCPの受信側は順序が前後したセグメントを一旦バッファに保持しておき、欠けていたセグメントが後から届いた時点でまとめて並べ直して上位層に渡します(選択的再送、Selective Repeat的な振る舞い)。ところがFARMは順序前後したフレームを一切バッファしません。期待値どおりのフレームしか受理しないという、極めて保守的な設計です。理由は単純で、探査機側の実装コストと確実性を優先しているためです。バッファと並べ替えロジックを持たせるより、「期待値以外は全部捨てて、地上にもう一度番号を教えてもらう」という方式のほうが、宇宙機の限られた計算資源の中で誤動作の余地が小さく、検証もしやすいのです。

CLCW: 受理状況を地上へ伝える32ビットの返事

FARMが受理判定を行うたびに、その結果は CLCW (Command Link Control Word) という32ビット固定長のワードにまとめられ、探査機からのテレメトリフレームの制御領域に埋め込まれて地上へ送り返されます。主なフィールドは次の通りです。

フィールド	意味
`Lockout` フラグ	FARMが受理不能状態(ロックアウト)にあるかどうか
`Wait` フラグ	受理待機中かどうか
`Retransmit` フラグ	直前に受理できなかったフレームがあり、再送が必要であることを示す
`Report Value V(R)`	FARMが現在保持している期待シーケンス番号

地上のFOPは、このCLCWが載ったテレメトリフレームを受信するたびにこれらのフィールドを読み取り、自分が送ったフレームがどこまで受理されたか(= $V(R)$ の値がどこまで進んだか)を知ります。ここで重要なのは、CLCWはアップリンクとは独立にダウンリンクで運ばれてくるという点です。つまり、コマンドを送ってからその受理確認が返ってくるまでの間には、アップリンクの伝搬遅延に加えてダウンリンクの伝搬遅延も乗ります。これが後述するタイムアウト設計を難しくする最大の要因です。

FOP(送信側の状態機械): 送信・再送ロジック

FOPは地上局側で動作し、主な状態変数は次の通りです。

$V(S)$ : 次に送信するフレームに割り当てるシーケンス番号。
Sent_Queue: 送信済みだがまだCLCWで受理確認が取れていないフレームを保持しておくキュー。
タイマー $T_1$ : 送信してから確認を待つ最大時間。
Transmission_Count と Transmission_Limit: そのフレームを何回送ったか、と、あきらめる(Alert状態に入る)までの最大送信回数。

FOPの動作は次のイベント駆動ループとして書けます。

フレームを送信する際、 $N(S) \leftarrow V(S)$ を割り当て、Sent_Queueに追加し、 $V(S) \leftarrow V(S)+1$ 、タイマー $T_1$ を起動する。
CLCWを受信したら、その Report Value $V(R)$ と Sent_Queue を突き合わせ、 $N(S) < V(R)$ を満たす(受理済みと確認できた)フレームを Sent_Queue から取り除き、タイマーをリセットする。
CLCWの Retransmit フラグが立っていれば、Sent_Queue の先頭(まだ受理されていない最古のフレーム)を直ちに再送する。
タイマー $T_1$ がCLCWの到着を待たずに満了した場合も、同様に再送する。ただし Transmission_Count が Transmission_Limit に達していれば、それ以上の自動再送を諦めて Alert 状態(異常)に遷移し、運用者の介入を要求する。

この Transmission_Limit による打ち切りが重要です。COP-1は無限に再送を試み続けるプロトコルではありません。ある回数だけ試して、それでも埒が明かなければ「これは自動では解決できない異常事態だ」と判断して人間に委ねる、という設計思想が組み込まれています。

確率的な視点: 再送回数とAlert状態の発生確率

再送制御の設計を評価するには、フレームが1回の送信で正しく受理される確率を考えるのが有効です。TCフレームは通常、下位層(CLTU: Command Link Transmission Unit、前回扱ったBCH符号による誤り検出つきの符号化単位)によってある程度保護されていますが、それでも深宇宙リンクではフレーム全体が失われる(あるいは誤り検出に引っかかって捨てられる)確率 $p$ がゼロではありません。

各回の送信が独立に確率 $p$ で失敗すると仮定すると(現実には天候・回線状況などの相関がありますが、単純化した第一近似として)、あるフレームが受理されるまでに必要な送信回数 $N$ は幾何分布に従います。

P(N = k) = (1-p)\, p^{\,k-1}, \qquad k = 1, 2, 3, \dots

期待送信回数は

\mathbb{E}[N] = \frac{1}{1-p}

となり、 $p$ が小さければ $\mathbb{E}[N] \approx 1$ に近づきます。一方、Transmission_Limit を $L$ 回に設定したとき、 $L$ 回連続して失敗し Alert 状態に陥ってしまう確率は

P(\text{Alert}) = p^{L}

です。たとえばフレーム損失率 $p = 10^{-2}$ (1%)のリンクで $L = 4$ とすれば $P(\text{Alert}) = 10^{-8}$ と、実運用上は無視できるレベルまで下げられます。逆に言えば、運用者はミッションのリンクバジェットから見積もったフレーム損失率 $p$ をもとに、Alert 発生確率を許容できる水準以下に抑えるように Transmission_Limit を選びます。 $L$ を大きくしすぎると、リンク状態が本当に悪化したときに気づくのが遅れる(いつまでも自動再送を繰り返し、運用者への警告が遅延する)というトレードオフもあるため、 $L$ は「めったなことでは発報しないが、異常時には適切なタイミングで運用者に知らせる」ちょうどよい値として選ばれます。

タイムアウト設計と深宇宙の光行時間

FOPのタイマー $T_1$ をどう設定するかは、COP-1の実装で最も難しい実務的な判断です。 $T_1$ が満了する条件は、「フレームを送ってから $T_1$ 秒経ってもCLCWで受理確認が取れない」ことでした。しかし、コマンドが探査機に届き、探査機がそれを受理し、その結果がCLCWとしてテレメトリに乗って地上に戻ってくるまでには、往復分の伝搬遅延(RTLT: Round-Trip Light Time)がどうしても必要です。したがって $T_1$ は、少なくとも

T_1 > \text{RTLT} + T_{\text{proc,sc}} + T_{\text{proc,gs}} + T_{\text{margin}}

を満たさなければなりません。ここで $T_{\text{proc,sc}}$ は探査機側の処理・フレーム生成遅延、 $T_{\text{proc,gs}}$ は地上局側の処理遅延、 $T_{\text{margin}}$ は運用上の安全マージンです。この不等式を満たさずに $T_1$ を短く設定してしまうと、実際にはフレームがきちんと受理されていて、その確認CLCWがまだ伝搬中であるだけなのに、FOPが「タイムアウトした」と誤判断して不要な再送を行ってしまいます。COP-1は前述のとおりウィンドウ幅が小さい保守的なプロトコルなので、この誤った再送は帯域の無駄遣いにとどまらず、最悪の場合はシーケンス番号の管理を混乱させる要因にもなります。

問題は、RTLTがミッションによって桁違いに変わることです。地球-火星間のRTLTは両惑星の位置関係により約8分から45分程度まで変動し、地球-土星間では往復で2時間を超えることもあります。より極端な例では、冥王星フライバイ時のニューホライズンズ探査機は片道光行時間が約4.5時間(往復で9時間以上)、恒星間空間を飛行中のボイジャー1号・2号にいたっては片道の光行時間がすでに20時間を超えています。

これは何を意味するでしょうか。RTLTが数時間から数十時間に達するミッションでは、 $T_1$ もそれに応じて数時間から数十時間というオーダーで設定せざるを得ません。 つまり、地上のTCPが行っているような「数十〜数百ミリ秒単位でのリアルタイムな再送判断」は深宇宙のCOP-1では原理的に不可能です。あるフレームが受理されたかどうかを地上局が知るまでに数時間かかるとすれば、その間にFOPが次々とフレームを送り続けることは(順序保証の観点からも)危険であり、実運用では1回のコマンドパス(可視時間帯)の中で送るフレーム数を絞り、確認を待ってから次のバッチを送る、あるいはコマンドをあらかじめ十分な余裕をもって送っておく、といった運用上の工夫で補われます。極端に遠い探査機に対しては、そもそもリアルタイムな閉ループ再送を前提とせず、複数のコマンドをまとめた「コマンドロード」を確実性重視でゆっくり時間をかけてアップロードし、COP-1はそのロード全体が欠落なく届いたことを保証する役割に徹する、という運用スタイルが取られます。

スライディングウィンドウ的な考え方とTCPとの違い

COP-1の設計は、地上のTCPが持つ再送制御・フロー制御の考え方と多くの概念を共有しています。両者を並べて比較すると、COP-1が深宇宙という制約の中でどれだけ単純化・保守化されているかがよく分かります。

	TCP	COP-1
シーケンス番号空間	32ビット	8ビット(mod 256)
順序前後したデータの扱い	受信バッファに保持し、後で並べ替え(選択的再送)	期待値以外はすべて棄却(バッファしない)
ウィンドウ幅	輻輳制御アルゴリズムで動的に変動(数十〜数百KB相当)	プロトコル上は $W$ を定義できるが、実運用では未確認のフレームを1つに絞る、事実上のストップ・アンド・ウェイトに近い運用が一般的
再送タイマー	RTT(数十〜数百ms)の測定値から動的に推定(RTOアルゴリズム)	RTLT(数分〜数十時間)を見越して固定的・保守的に設定
打ち切り条件	一定回数再送後にコネクションを切断	`Transmission_Limit` 到達で`Alert`状態に遷移し人間に委ねる

COP-1が「プロトコルとしてはウィンドウを持てるにもかかわらず、実運用では窓を1に絞ったストップ・アンド・ウェイト的な使い方をされることが多い」のはなぜでしょうか。理由は、順序保証の要求の強さにあります。TCPは「最終的にバイト列が正しい順序で揃えば良い」プロトコルであり、そのために受信側が並べ替えバッファを持つコストを払っています。一方COP-1は、探査機側にその並べ替えロジックを持たせないという設計判断をした結果、複数フレームを並行して(パイプライン的に)送っても、1つでも失敗すればそれ以降のフレームはすべて期待値と一致しなくなり、まとめて棄却・再送対象になってしまいます。であれば、最初から1フレームずつ確認を取りながら送るほうが、無駄な再送が少なく、動作も単純で検証しやすいという結論になるのです。地上のネットワークでは帯域幅遅延積(bandwidth-delay product)を埋めるために大きなウィンドウでのパイプライン化が不可欠ですが、コマンドリンクは(テレメトリと比べて)そもそもデータレートが低く、パイプライン化による帯域利用率の改善よりも、単純さと確実性を優先する設計が合理的だと判断されています。

実務での使われ方

COP-1はCCSDS 232.1-B Communications Operation Procedure-1 として標準化されており、対応するTC宇宙データリンクプロトコルはCCSDS 232.0-B TC Space Data Link Protocol に規定されています。NASA/JPLのDSN(Deep Space Network)、ESAのESTRACK、JAXAのUSC(臼田)・美笹深宇宙局を含む世界中の深宇宙地上局のコマンド送信系は、この標準に準拠したFOP実装(地上局のコマンド送信ソフトウェア、たとえばJPLのAMMOS系列のツール群やESAのSCOS-2000ミッション制御システムに組み込まれている)を使っています。

運用上、パスの開始時にはまず地上と探査機の間で $V(S)$ と $V(R)$ を同期させる「初期化」手続き(Set V(R) ディレクティブなど)が実行されます。これは、前回のパスの終了時点からの状態の食い違いをリセットし、双方のシーケンス番号カウンタを合わせるための重要な儀式です。パス中はFOPの Sent_Queue の状況や Alert 状態の有無が運用者のコンソールに常時表示され、Alert が発生した場合は自動再送に任せず、運用者が原因(受信機のロック外れ、地上局のスケジューリングの問題、探査機側の異常など)を診断した上で手動で再開させます。

また、すべてのコマンドがCOP-1(確認付き、CCSDSの用語で Type-A / AD frame、Acknowledged/Sequence-controlled)で送られるわけではありません。極めて緊急性の高いコマンド(たとえば安全モードへの強制移行や、進行中の危険な動作の緊急停止)は、確認応答を待たずに即座に送出する Type-B / BD frame(Bypass/Expedited)という、COP-1のFOP/FARM機構そのものをバイパスする経路も用意されています。これは「確実性のために遅延を許容するCOP-1経路」と「即時性を優先し確実性はある程度犠牲にするバイパス経路」という、目的の異なる2つの送信モードを使い分ける設計です。

演習問題

あるTCフレームのシーケンス番号が $N(S) = 250$ で送信され、その後251, 252, … と続くとき、 $V(R) = 254$ の状態のFARMに $N(S) = 3$ (mod-256で254の少し先)のフレームが届いたとします。これはウィンドウ内・ウィンドウ外のどちらに分類されるか、mod-256の巡回演算に注意して議論してください(ウィンドウ幅 $W$ をいくつかの値で仮定して考えること)。
フレーム損失率 $p = 5\times10^{-3}$ のアップリンクで、Transmission_Limit を $L=3$ と $L=5$ にそれぞれ設定した場合の Alert 発生確率 $P(\text{Alert}) = p^L$ を計算し、両者を比較してください。また期待送信回数 $\mathbb{E}[N] = 1/(1-p)$ も求めてください。
木星探査ミッションを想定し、地球-木星間のRTLTがおよそ90分であるとします。探査機側処理遅延 $T_{\text{proc,sc}} = 5$ 秒、地上局側処理遅延 $T_{\text{proc,gs}} = 10$ 秒、安全マージン $T_{\text{margin}} = 5$ 分としたとき、FOPのタイマー $T_1$ に最低限必要な値を求めてください。またこの $T_1$ の大きさが実際のコマンド送信運用にどのような制約を課すか、この回の内容をもとに説明してください。
COP-1のFARMが、TCPの受信側のように順序前後したフレームを一旦バッファして後から並べ替える設計になっていないのはなぜだと考えられますか。この回で述べた「探査機側の実装コストと確実性」「パイプライン化による帯域利用率改善の価値の低さ」という2つの観点を踏まえて、自分の言葉で説明してください。

まとめと次回予告

COP-1は、地上局側のFOPと探査機側のFARMという2つの状態機械が、シーケンス番号 $N(S)$ とCLCWだけを頼りに協調動作することで、アップリンクの「完全性」と「順序保証」という、テレメトリにはない厳しい要求を満たす再送制御プロトコルでした。TCPの再送制御・フロー制御と概念的には親戚関係にありながら、深宇宙特有の長大な光行時間と、探査機側の限られた計算資源という制約のもとで、順序前後したフレームをバッファせずに捨てる、実質的にストップ・アンド・ウェイトに近い運用がされるなど、随所で「単純さと確実性を優先する」保守的な設計選択がなされていることを見ました。またタイムアウト $T_1$ の設計が、地球-火星間で数十分、恒星間空間のボイジャーでは数十時間というRTLTのスケールに支配されていることも確認しました。

次回は、こうしたコマンドやテレメトリのフレームに埋め込まれる時刻情報の話に移ります。COP-1のCLCWやFARM/FOPの動作そのものには時刻は直接登場しませんが、コマンドがいつ実行されるべきか、テレメトリのサンプルがいつ取得されたかを地上と探査機で矛盾なく共有するためには、標準化された時刻表現が欠かせません。CCSDSが定める時刻コードフォーマット(CUC、CDS等)に軽く触れながら、宇宙機通信における「時刻」の扱い方の基礎を見ていきます。

参考文献

CCSDS 232.1-B, Communications Operation Procedure-1, Blue Book
CCSDS 232.0-B, TC Space Data Link Protocol, Blue Book
CCSDS 231.0-B, TC Synchronization and Channel Coding, Blue Book
CCSDS 910.4-B, Space Communications Cross Support — Architecture Requirements Document (運用文脈)
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley(地上プロトコルとの比較のための参考)