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

CCSDS宇宙データリンクプロトコル — SpacePacketをフレームに詰め、仮想チャンネルで多重化する

SpacePacketという論理データ単位は、RFリンクに乗るまでに『トランスファーフレーム』という固定長の箱に詰め替えられる。CCSDS TM宇宙データリンクプロトコル(132.0-B)のフレーム構造を読み解き、仮想チャンネル(VC)・マスターチャンネル(MC)という2階層の多重化と、パケットレベルのAPIDとの役割分担を整理する。

前提知識: space-packet

CCSDSTMトランスファーフレーム仮想チャンネルマスターチャンネル宇宙データリンク層

この回で学ぶこと

SpacePacketの回では、探査機に搭載された個々のアプリケーション(姿勢制御、観測機器、電源系など)が生成するデータを、APID(Application Process Identifier)という識別子付きの可変長パケットにまとめる仕組みを学びました。SpacePacketは「どのアプリケーションが、どんな種類のデータを送っているか」を表現する論理的なデータ単位でしたが、それ自体は電波に乗せられる物理的な信号ではありません。SpacePacketの列は、最終的にPCM/PSK/PMのような変調方式でRF搬送波に乗る前に、必ずもう1段階の詰め替えを経ます。

その詰め替え先が、この回のテーマである**トランスファーフレーム(Transfer Frame)**です。フレームは固定長のバイト列で、複数のSpacePacketを機械的に詰め込むための「箱」の役割を果たします。これを規定するのが CCSDS TM(Telemetry)宇宙データリンクプロトコル、正式には CCSDS 132.0-B TM Space Data Link Protocol です。

さらにこの回では、1本の物理的なRFリンクの上に、性質の異なる複数のデータストリーム——たとえば「今まさに取得しているリアルタイムテレメトリ」「後で送るために撮り貯めた科学データの再生(プレイバック)」「探査機の健康状態を伝えるハウスキーピングテレメトリ」——を同居させるための多重化の仕組みを扱います。これが**仮想チャンネル(Virtual Channel, VC)であり、さらにその上位にあるマスターチャンネル(Master Channel, MC)**という階層です。フレーム同期とASMの回で学んだ「ビット列の海からフレームの先頭を掘り当てる」処理の、ちょうど次の段階に位置する話だと捉えてください。

同じ「識別子による多重化」でも、APIDとVC IDはまったく違う層で働いています。この2つを混同しないことが、この回でもっとも重要な整理です。

直感的な全体像: パケットの海を、固定長の箱に詰め替える

SpacePacketは可変長です。姿勢センサの値を伝える小さなパケットもあれば、圧縮された画像データを運ぶ数キロバイトの大きなパケットもあります。ところが、地上局の復調器やビット同期回路、フレーム同期の相関検出器は、区切りが一定でない可変長のデータよりも、あらかじめ長さの決まった固定長のブロックを相手にするほうが圧倒的に設計しやすくなります。フレーム長が固定であれば、ASM(アタッチド同期マーカー)を見つけた瞬間に「次のフレームの先頭はNバイト先」と機械的に予測でき、誤り訂正符号のブロック長も固定できます。

そこでTM宇宙データリンクプロトコルは、可変長のSpacePacketを、切れ目を気にせずに固定長のフレームへどんどん詰め込んでいくという設計を取ります。1つのSpacePacketがフレームの途中で終わらず、次のフレームにまたがってしまっても構いません。「今どこまで詰めたか」「次のフレームの先頭で新しいパケットが始まるか、それとも前のフレームからの続きか」という情報だけをフレームのヘッダに書いておけば、受信側は正しくパケットを復元できます。

さらに、1本のRFリンクを流れるデータは1種類とは限りません。リアルタイムのハウスキーピングテレメトリと、記録再生された科学データを、優先度も内容もまったく異なるまま同じ物理リンクに乗せたい場面が頻繁にあります。この「どのフレームがどのストリームに属するか」を区別するタグが仮想チャンネル(VC)です。そしてもし1本の物理リンクに複数の探査機(たとえば周回機と、それが中継する着陸機)のデータが混在するなら、その探査機ごとの区別を担うのがマスターチャンネル(MC)です。VCがストリームの種類を、MCが送信元の機体そのものを区別する——この2階層の入れ子構造を、以下で数式とフィールド構造を追いながら定式化していきます。

TMトランスファーフレームの構造

TM宇宙データリンクプロトコルにおけるフレームは、次のようなブロックの並びとして定義されます。

\underbrace{\text{Primary Header}}_{6\text{ oct(固定)}} \;\; \underbrace{\text{Secondary Header}}_{\text{任意}} \;\; \underbrace{\text{Transfer Frame Data Field}}_{\text{可変長, SpacePacketを複数格納}} \;\; \underbrace{\text{OCF}}_{4\text{ oct, 任意}} \;\; \underbrace{\text{FECF}}_{2\text{ oct, 任意}}

フレーム全体の長さは、あるミッションのある物理チャンネルについては運用パラメータとして固定されます(典型的には1024〜2048オクテット程度が使われることが多いですが、ミッションのリンク設計に応じて選ばれます)。可変なのはあくまでフレーム「内部」のデータフィールドの使い方であり、フレームそのものの長さはビット同期・フレーム同期を単純にするために固定長に保たれる、という点が設計の要です。

プライマリヘッダ: フレームの素性を記述する48ビット

プライマリヘッダは常に6オクテット(48ビット)の固定長で、次のフィールドから構成されます。

フィールド	ビット幅	役割
Transfer Frame Version Number (TFVN)	2	プロトコルのバージョン識別(TMでは固定値)
Spacecraft ID (SCID)	10	どの探査機が送信したフレームかを識別
Virtual Channel ID (VCID)	3	同一探査機内でのデータストリーム種別を識別
Operational Control Field Flag	1	このフレームにOCF(後述)が付与されているか
Master Channel Frame Count	8 (mod 256)	マスターチャンネル全体を通した連番
Virtual Channel Frame Count	8 (mod 256)	同一VC内だけを通した連番
Transfer Frame Data Field Status	16	下記参照

合計 $2+10+3+1+8+8+16 = 48$ ビット、ちょうど6オクテットになります。

Transfer Frame Data Field Statusの16ビットはさらに次のように細分されます。

サブフィールド	ビット幅	役割
Secondary Header Flag	1	セカンダリヘッダの有無
Sync Flag	1	データフィールドがSpacePacket形式かどうか
Packet Order Flag	1	(通常未使用、予約的な位置づけ)
Segment Length Identifier	2	セグメント化の有無
First Header Pointer	11	データフィールド内で、最初のSpacePacketの先頭が何オクテット目から始まるか

この中で実務上もっとも重要なのが First Header Pointer です。次節で詳しく見ます。

データフィールド: 可変長パケットを固定長の箱に詰める

First Header Pointer(11ビット、値の範囲は $0$ 〜 $2047$ )は、「このフレームのデータフィールドの中で、新しいSpacePacketのヘッダが何オクテット目から始まるか」というオフセットを表します。これにより、SpacePacketの境界とフレームの境界が一致しない——つまり1つのパケットが2つのフレームにまたがる——状況を正しく扱えます。

具体例で考えましょう。あるフレームのデータフィールドが1000オクテットだとして、直前のフレームから続くパケットの残り(たとえば300オクテット分)がまずデータフィールドの先頭に詰められ、その続きに新しいパケットのヘッダが始まるとします。このとき First Header Pointer の値は $300$ となり、受信機は「このフレームの先頭から300オクテットまでは前のフレームからの継続データ、301オクテット目から新しいパケットが始まる」と機械的に解釈できます。ここから先は、フレーム境界を一切気にせず、SpacePacketの主ヘッダにあるパケット長フィールド(SpacePacketの回参照)を頼りに、複数フレームをまたいでバイト列を連結していくだけでパケットを再構成できます。

First Header Pointerにはさらに2つの特別な予約値が定義されています。

全ビット1(値 $2047$ ): このフレームには新しいパケットの先頭が1つも含まれない(前のフレームからの継続データのみ)ことを示す。
全ビット1のうち最下位1ビットだけ0(値 $2046$ ): このフレームがOID(Only Idle Data、埋め草データのみ)で構成されていることを示す。

なぜ「送るデータが何もない」場合にまでフレームを送る必要があるのでしょうか。理由は、フレーム同期の回で見た通り、地上局の受信機がビット同期・フレーム同期・(必要なら)搬送波追尾を維持し続けるには、リンク上に途切れることなく連続したフレームの流れが必要だからです。実データがない瞬間でも、埋め草(アイドル)データで満たされたフレームを送り続けることで、リンクそのものは「生きている」状態を保ちます。

フレームエラー制御フィールドとOCF

フレームの末尾には、任意で Frame Error Control Field (FECF) が2オクテット付与されます。これは生成多項式 $x^{16}+x^{12}+x^5+1$ によるCRC-16(CRC-CCITT)で、プライマリヘッダからデータフィールド、OCFまでを含めたフレーム全体に対して計算され、受信側でフレーム単位の誤り検出に使われます。

プライマリヘッダのOperational Control Field Flagが1のとき、データフィールドとFECFの間に4オクテットの OCF (Operational Control Field) が挿入されます。OCFの典型的な用途が CLCW (Communications Link Control Word) の運搬です。CLCWは、アップリンクのコマンド(TC)がどこまで正しく受信されたかを地上局側のFOPに伝え返すための32ビットのフィードバック情報で、これを使った再送制御プロトコルがCOP-1です。つまりダウンリンクのTMフレームは、単に観測データを運ぶだけでなく、アップリンクの受信確認情報を折り返し運搬する「戻り経路」としても働いています。

仮想チャンネル(Virtual Channel): フレームレベルの多重化

VC IDは3ビットのフィールドで、1つの探査機(1つのSpacecraft ID)につき最大8本(VCID $0$ 〜 $7$ )の仮想チャンネルを区別できます。それぞれの仮想チャンネルは独立したフレームカウント(Virtual Channel Frame Count)を持ち、独立したフレーム列として扱われます。

なぜ複数のVCが必要なのでしょうか。1本の物理リンクの帯域は限られていますが、探査機が送りたいデータの性質はまったく異なります。

リアルタイムテレメトリ用VC: 姿勢角・温度・電圧など、今まさに観測されている探査機の状態を低レートで継続的に送る。
記録再生(プレイバック)データ用VC: 可視パスの外で搭載レコーダに蓄積された科学データや過去のハウスキーピングデータを、可視パス中にまとめて高レートで送り出す。
科学データ用VC: 観測機器からの本命のデータを、上記2つとは独立したストリームとして扱う。

これらを1本のVCに混ぜてしまうと、優先度の高いリアルタイムテレメトリが、大容量のプレイバックデータの合間に埋もれてしまうといった問題が起きます。VCを分けることで、地上局の受信・処理系は「まずVC0(リアルタイムテレメトリ)だけを抜き出して即座に状態監視に回し、VC1・VC2(科学データ・プレイバック)は非同期にバッファして後段の処理系に渡す」といった、ストリームごとに異なる扱いを実現できます。この処理は**逆多重化(demultiplexing)**と呼ばれ、地上局側では受信フレームのVC IDフィールドを見るだけの単純なルーティング操作として実装されます。

処理順序の整理: フレーム同期の次にVC逆多重化が来る

フレーム同期の回で見たSEARCH→CHECK→LOCKという同期状態機械は、あくまで「連続ビット列のどこからどこまでが1フレームか」というフレームの切り出しを担う処理でした。VCによる逆多重化は、その一段階あとの処理です。処理パイプライン全体を順番に並べると、次のようになります。

ビット同期・シンボル同期(復調直後)
フレーム同期: ASMの相関検出により、連続ビット列をフレーム単位に切り出す(フレーム同期の回)
FECFによるフレーム単位の誤り検出(必要ならここで破損フレームを廃棄)
VC逆多重化: プライマリヘッダのVCIDフィールドを見て、フレームを対応するVCのキューへ振り分ける(この回)
各VC内でのフレームカウントの連続性チェック(フレーム損失検知)
First Header Pointerを使ったデータフィールドからのSpacePacket復元
APID逆多重化: 復元されたSpacePacketのAPIDを見て、対応するアプリケーションプロセスへ振り分ける(SpacePacketの回)

この並びから分かる通り、VC IDはフレームというコンテナに貼られたラベルであり、フレームを開封する前(SpacePacketを取り出す前)に読み取られます。一方APIDはSpacePacketというコンテンツに書かれたラベルであり、フレームを開封してデータフィールドを取り出したあと、パケットを復元して初めて読み取れます。同じ「多重化のための識別子」という機能を持ちながら、両者は処理パイプライン上でまったく異なる段階、異なる粒度で働いているのです。VC IDはリンク層(フレーム)の識別子、APIDはアプリケーション層に近い(パケット)の識別子だと整理すると理解しやすくなります。

マスターチャンネル: さらに上位の多重化階層

VCがストリームの種類を区別するのに対し、マスターチャンネル(MC)は送信元の探査機そのものを区別する、もう1段上の多重化階層です。

マスターチャンネルは、プライマリヘッダのTFVN(2ビット)とSpacecraft ID(10ビット)を合わせた12ビットの Master Channel ID (MCID) によって識別されます。同じMCID(同じ探査機)を持つフレームの集合が1つのマスターチャンネルであり、その内部がさらにVC IDによって最大8本の仮想チャンネルに分かれる、という入れ子構造になっています。MCIDとVCIDを合わせた15ビットの組は Global VCID (GVCID) と呼ばれ、リンク上のあらゆるフレームを一意に識別する完全なアドレスになります。

\text{GVCID} = \underbrace{\text{MCID}}_{\text{TFVN(2b)}+\text{SCID(10b)}} \;\Vert\; \underbrace{\text{VCID}}_{3\text{b}}

マスターチャンネルという階層が意味を持つのは、1本の物理リンクに複数の探査機のデータが混在する場面です。代表的なのは中継通信アーキテクチャの回で扱った、周回機が着陸機・ローバーのデータを中継してDSNへ送る構成です。周回機自身のテレメトリと、中継している着陸機のテレメトリは、それぞれ異なるSpacecraft IDを持つ独立したマスターチャンネルとしてフレーム化され、1本の周回機→地球ダウンリンクの上に多重化されます。地上局は、まずMCIDを見てどの探査機由来のデータかを判別し、次にその内側でVCIDを見てストリーム種別を判別する、という2段階の逆多重化を行うことになります。

Master Channel Frame Count(8ビット、mod 256)とVirtual Channel Frame Count(8ビット、mod 256)という2つの独立したカウンタが用意されているのも、この2階層構造を反映しています。MC Frame Countはそのマスターチャンネル(探査機)全体を通しての連番なので、「その探査機からのフレームを1つでも取りこぼしていないか」をVCの区別なく検出できます。一方VC Frame Countは特定のVCだけを通した連番なので、「特定のストリーム(たとえば科学データVC)だけに着目したフレーム損失」を検出できます。両方のカウンタを併用することで、地上局はどの階層でデータが欠けたのかを切り分けて診断できるわけです。

TCトランスファーフレームとCLTU: アップリンクの逆方向設計

ここまではダウンリンク(探査機→地球)のTM宇宙データリンクプロトコルを見てきましたが、アップリンク(地球→探査機、コマンド送信)には対をなす TC (Telecommand) 宇宙データリンクプロトコル(CCSDS 232.0-B TC Space Data Link Protocol)が規定されています。基本思想(可変長のパケットをフレームに詰める)は共通ですが、フレーム構造にはアップリンク特有の違いがあります。

TCトランスファーフレームのプライマリヘッダは5オクテット(40ビット)で、次の構成を取ります。

フィールド	ビット幅	役割
TFVN	2	バージョン識別
Bypass Flag	1	0ならCOP-1のシーケンス制御対象(Type-AD)、1ならバイパス(Type-BD)
Control Command Flag	1	0ならデータフレーム、1なら制御コマンドフレーム(Type-BC、`Set V(R)`等)
Reserved Spare	2	予約
Spacecraft ID	10	宛先探査機の識別
Virtual Channel ID	6	TMより広い6ビット。アップリンクは複数の探査機・複数機器を同一リンクで宛先指定するケースが多い
Frame Length	10	フレーム全体のオクテット長(可変長)
Frame Sequence Number N(S)	8 (mod 256)	COP-1のFARM/FOPが使う送信シーケンス番号

TMがフレーム長固定・データを取りこぼさず流し続けることを優先するのに対し、TCフレームは可変長で、必要なコマンドがあるときだけ送信されるという非対称な設計です。この8ビットのFrame Sequence Numberこそが、COP-1の回で見た「シーケンス番号空間は8ビット(mod 256)」というFARM/FOPの土台になっています。

さらにTCフレームは、変調される前段で CLTU (Command Link Transmission Unit) という単位に符号化されます。これはCCSDS 231.0-B TC Synchronization and Channel Coding が規定するもので、TCフレームのビット列を7オクテット(56ビット)ずつのブロックに区切り、各ブロックにBCH(63,56)符号による1オクテット(7検査ビット+1フィルビット)の誤り検出パリティを付加して64ビットのコードブロックとします。これらのコードブロックの前後に、開始を示す2オクテットのスタートシーケンス(値 0xEB90)と、終端を示す固定パターンのテイルシーケンスを付けたものがCLTUです。アップリンクは往復時間が長く再送のコストが高いため、ダウンリンクのような連接符号やLDPC符号ではなく、実装が枯れて検証しやすいBCH符号が今なお標準的に使われています(CCSDS符号化標準の変遷の回で見たアップリンク特有の保守性の議論とも整合します)。TCフレームとCLTUの詳細、そしてこの上に乗るCOP-1の再送制御は、COP-1の回で改めて扱います。

実務での使われ方

TM宇宙データリンクプロトコルとVC/MCの仕組みは、CCSDSに準拠するほぼすべての深宇宙・地球観測ミッションで使われています。

VC割り当ての設計パターン: 多くのミッションでは、リアルタイムのハウスキーピングテレメトリに低いVCID(たとえばVC0)を、記録再生された科学データに別のVCID(たとえばVC1)を、さらに追加の観測系統や画像データに別のVCIDを割り当てるという設計が広く採られています。優先度の高いストリームに低いVCIDを割り当てておくと、地上局の運用者が管制卓でストリームを識別しやすいという運用上の慣習的な利点もあります。
中継ミッションでのMCID活用: 火星探査における周回機-着陸機の中継(中継通信アーキテクチャの回)や、国際宇宙ステーションのように複数の通信系統(S帯・Ku帯)を持つ有人施設では、送信元(探査機)ごとに異なるSpacecraft IDを割り当ててマスターチャンネルを分離し、1本の物理リンク上に複数機体のデータを安全に混在させる設計が使われています。
AOS宇宙データリンクプロトコルとの関係: 近地球ミッションや高データレートのミッション向けには、TM宇宙データリンクプロトコルの近縁にあたる AOS (Advanced Orbiting Systems) 宇宙データリンクプロトコル(CCSDS 732.0-B)が用意されており、VC IDフィールドが6ビットに拡張されて最大64本の仮想チャンネルを扱えるなど、より大規模な多重化に対応しています。基本的なフレーム/VC/MCの考え方はTMと共通しています。
地上局側の逆多重化処理: NASA/JPLのAMMOS(Advanced Multi-Mission Operations System)や、ESAのSCOS-2000といったミッション運用ソフトウェア群には、受信フレームからMCID・VCIDを読み取って対応するデータストリームへ振り分ける逆多重化処理が組み込まれており、DSNをはじめとする各局のデータ処理チェーンの標準的な構成要素になっています。

演習問題

TM宇宙データリンクプロトコルのプライマリヘッダは6オクテット(48ビット)で、VCIDは3ビットです。1つのマスターチャンネル(1つの探査機)が持てる仮想チャンネルの最大数を求めてください。また、AOS宇宙データリンクプロトコルではVCIDが6ビットに拡張されています。この場合の最大VC数を求め、なぜ近地球・高データレートのミッションではより多くのVCが必要になりやすいか、この回で学んだVCの用途を踏まえて論じてください。
あるフレームのデータフィールドが1200オクテットで、First Header Pointerの値が $450$ であったとします。この値が意味する内容を説明し、受信機がこのフレームからSpacePacketを復元する際にどのような処理を行うかを述べてください。あわせて、First Header Pointerが取りうる値の最大値(全ビット1) $2047$ が意味する特別な状態についても説明してください。
あるVCにおいて、直前に受信したフレームのVirtual Channel Frame Countが $254$ 、その次に受信したフレームのVirtual Channel Frame Countが $2$ でした。8ビットカウンタ(mod 256)のラップアラウンドを考慮すると、この間に何フレームが失われたと推定できるか計算してください。
APID(SpacePacketレベルの識別子)とVC ID(フレームレベルの識別子)は、どちらも「複数のデータストリームを区別する識別子」という点で似ていますが、役割はまったく異なります。この回で整理した「フレーム同期→VC逆多重化→First Header Pointerによるパケット復元→APID逆多重化」という処理パイプラインを踏まえ、両者の違いを自分の言葉で説明してください。

まとめと次回予告

SpacePacketという可変長の論理データ単位は、CCSDS TM宇宙データリンクプロトコル(132.0-B)が定めるトランスファーフレームという固定長の箱に詰め替えられて初めて、フレーム同期や誤り訂正符号化といった下位層の処理に乗せられます。First Header Pointerというたった11ビットのフィールドが、パケットとフレームという2つの異なる境界のズレを吸収する鍵でした。そして、仮想チャンネル(VC)がストリームの種類を、マスターチャンネル(MC)が送信元の探査機そのものを区別するという2階層の多重化構造によって、1本の物理リンクの上に複数の性質・複数の送信元のデータを整理して同居させる仕組みも見ました。VC IDとAPIDは、どちらも識別子でありながらフレーム層とパケット層というまったく異なる粒度で働いている、という区別がこの回の核心です。

次回は、この連続的なフレーム・ストリームの世界から少し視点を変え、探査機のソフトウェアアップデートや科学データファイルを「1バイトも欠けることなく」届けるための、ファイル単位の信頼性転送プロトコル CFDP (CCSDS File Delivery Protocol) を扱います。フレームというストリーム指向の世界の上に、ファイルという別の抽象化がどう組み立てられるかを見ていきます。

参考文献

CCSDS 132.0-B, TM Space Data Link Protocol
CCSDS 232.0-B, TC Space Data Link Protocol
CCSDS 231.0-B, TC Synchronization and Channel Coding
CCSDS 133.0-B, Space Packet Protocol
CCSDS 732.0-B, AOS Space Data Link Protocol
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD