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

CCSDS Space Packetプロトコル — 探査機データを仕分ける最小単位の器

変調・符号化・測距という物理層の話が一段落し、ここからはネットワーク・プロトコル層に入る。複数の観測機器のデータをどう1本のRFリンクに詰め込むか、CCSDS 133.0-B Space Packet Protocolのヘッダ構造とAPIDによる仕分けの仕組みを読み解く。

CCSDSSpace Packet ProtocolAPIDパケット構造テレメトリ

この回で学ぶこと

これまでの回では、PCM/PSK/PMから始まり、PLL、各種の変調方式、誤り訂正符号、レンジングといった、一貫して物理層の話を積み重ねてきました。すなわち「ビット列を電波の振幅・位相・周波数にどう乗せるか」「雑音の中からどうビットを正しく取り出すか」という、電波そのものを相手にする議論です。

しかし探査機の中では、物理層の手前でまず解決しなければならない、もっと素朴な問題があります。1機の探査機には通常、姿勢制御系・電源系・熱制御系といったバス機器(探査機本体を維持するサブシステム)に加えて、カメラ、分光計、磁力計、粒子検出器など複数の観測機器が同居しています。これらはそれぞれ独立に、しかも別々のタイミングでデータを生成します。ところが探査機から地球に伸びる送信機は基本的に1本(多くても数本)しかありません。「誰のデータか」「どこからどこまでが1つのまとまりか」が分からないビットの奔流を、そのまま1本のRFリンクに流し込んだら、地上局はそれを解読しようがありません。

この問題に対する答えが、CCSDSが規定する Space Packet Protocol(CCSDS 133.0-B、通称「宇宙パケットプロトコル」)です。これは、探査機内の各アプリケーションプロセス(観測機器やサブシステムのソフトウェアタスクだと思ってください)が生成するデータを、送信元・長さ・順序番号を明示したパケットという単位に詰める、極めてシンプルながら宇宙データシステム全体の基盤をなす規格です。今回からしばらくは、物理層の上に乗るネットワーク・プロトコル層――データをどう構造化し、どう多重化し、どう信頼性を持たせて転送するか――を扱っていきます。その第一歩として、最も基本的な構成単位であるSpace Packetの構造を理解しましょう。

直感的導入: なぜ「小包」に仕分ける必要があるのか

地上のインターネットで例えるなら、Space Packetは宛先(送り主)ラベルの付いた小包のようなものです。郵便局(=RFリンク)が1本しかなくても、荷物の外側に「差出人:カメラ観測班」「内容量:何グラム」というラベルさえ貼ってあれば、複数の荷主の荷物を同じトラックに混載でき、受け取った側(地上局)はラベルを見てそれぞれの荷主に仕分け直すことができます。

もう少し工学的に言い換えると、Space Packetのヘッダには次の3種類の情報が入っています。

誰のデータか(送信元の識別) — これを担うのが APID (Application Process Identifier) です。
どこまでが1つのパケットか(パケットの境界) — パケット長フィールド が担います。
何番目のパケットか(順序と欠落の検出) — パケットシーケンスカウント が担います。

以下、CCSDSの一次ヘッダの各フィールドをひとつずつ数式とビット幅で追いながら、この3つがどう実現されているかを見ていきます。

Space Packet ProtocolのCCSDS階層内での位置づけ

CCSDSのプロトコル階層は、地上のOSI参照モデルと完全には対応しませんが、大まかには次のような積み重ねになっています。

アプリケーション層(観測機器・搭載ソフトウェア)
        ↓  データをSpace Packetに詰める  ← 今回
Space Packet Protocol (CCSDS 133.0-B)
        ↓  複数のパケットをフレームに多重化する  ← 次回以降
Space Data Link Protocol (TM/TC, CCSDS 132.0-B / 232.0-B)
        ↓  同期・チャネル符号化を施す
物理層(変調・符号化) ← これまでの回

つまりSpace Packetは、Reed-Solomon符号やフレーム同期で扱ってきた「フレーム」よりも1段上の階層に位置します。フレームは複数のパケット(あるいはパケットの断片)を運ぶための、物理リンクに合わせた固定長(または準固定長)の入れ物であるのに対し、パケットはアプリケーションが「これが1つの意味のあるデータのまとまりだ」と認識する単位です。この2つの階層を分けておくことで、「どんなデータを、どういう単位で作るか」という関心事(パケット層)と、「それを実際の無線リンクにどう流し込むか」という関心事(フレーム層)を独立に設計できる、という利点が生まれます。この分離の具体的な仕組みは、フレームと仮想チャンネルを扱う次のレッスンで詳しく見ます。

一次ヘッダの構造

Space Packetは必ず**一次ヘッダ(Primary Header)**を持ちます。これは固定長6オクテット(48ビット)で、次の6つのフィールドから成ります。

フィールド	ビット幅	値の範囲	意味
Packet Version Number	3	`000` 固定	CCSDS Version 1 のSpace Packetであることを示す
Packet Type	1	0 / 1	0 = テレメトリ(TM、探査機→地上)パケット、1 = テレコマンド(TC、地上→探査機)パケット
Secondary Header Flag	1	0 / 1	二次ヘッダの有無(1なら後述の二次ヘッダが続く)
APID	11	0–2047	アプリケーションプロセス識別子(送信元の識別番号)
Sequence Flags	2	`00`/`01`/`10`/`11`	パケットのセグメンテーション状態(後述)
Packet Sequence Count / Packet Name	14	0–16383	APIDごとの通し番号(mod 16384、後述)
Packet Data Length	16	0–65535	データフィールドの総オクテット数 − 1(後述)

合計 $3+1+1+11+2+14+16 = 48$ ビット、ちょうど6オクテットです。この一次ヘッダの直後に、(あれば)二次ヘッダ、そして実際のユーザーデータ(観測データやテレメトリ値そのもの)が続き、これら「二次ヘッダ+ユーザーデータ」をまとめてパケットデータフィールド (Packet Data Field) と呼びます。

APID: 11ビットの「差出人ラベル」

APID (Application Process Identifier) は一次ヘッダの中でもっとも実務的に重要なフィールドです。探査機に搭載された個々のアプリケーションプロセス――たとえば「カメラの画像データ生成タスク」「姿勢制御系のハウスキーピング(状態監視)データ生成タスク」「磁力計のサイエンスデータ生成タスク」――がそれぞれ固有のAPID値を割り当てられ、自分が生成したパケットのAPIDフィールドに必ずその値を書き込みます。

11ビットなので、表現できるAPIDの数は

2^{11} = 2048

通りです。ただしこのうち APID = 0x7FF(全ビット1、10進で2047)は「アイドルパケット(Idle Packet)」専用に予約されており、実際に観測機器やサブシステムに割り当てられるのは残り2047通りです。アイドルパケットは、送るべき実データが一時的にない瞬間でも物理リンクの同期(ビット同期・フレーム同期)を切らさないための「詰め物」であり、地上局側はAPID 0x7FF を見た時点でそのパケットの中身を単に無視します。

ここで地上のネットワークに馴染みのある人向けに1つ注意しておくと、APIDはIPアドレスのようにグローバルに一意である必要はありません。IPアドレスは(少なくともあるネットワークの中では)重複が許されませんが、APIDはあくまで1機の探査機(1つの管理されたデータシステム)の中でだけ一意であればよいという、ずっと狭いスコープの識別子です。木星探査機と火星探査機が両方ともAPID 100番を使っていても、両者のデータストリームは物理的に混ざりようがないので何の問題も起きません。この「識別子のスコープを必要最小限に絞る」という設計判断は、限られたビット数(11ビット)を有効に使うための合理的な選択です。

地上局(あるいはミッション運用センター)では、受信したパケット列を一次ヘッダのAPIDフィールドだけを見て**デマルチプレクス(振り分け)**します。カメラのAPIDを持つパケットは画像処理パイプラインへ、姿勢制御系のAPIDを持つパケットは健全性監視(ヘルスモニタリング)システムへ、といった具合です。これは地上のネットワークにおいて、1本のIPアドレス(1台のサーバ)上で動く複数のアプリケーションをポート番号で振り分けるのと、発想としてはよく似ています。ただしAPIDが表しているのは「宛先ポート」ではなく「送信元プロセス」である点には注意してください——Space Packetは基本的に片方向(探査機→地上のテレメトリ、あるいは地上→探査機のテレコマンド)のデータ生成元を識別するための仕組みです。

パケット長フィールドと可変長パケットの制約

Space Packetは可変長です。同じAPIDでも、パケットごとに含まれるデータ量は異なってよく、その長さを一次ヘッダの最後のフィールドである Packet Data Length(16ビット)が示します。ただしこのフィールドの値 $C$ は、データフィールドのオクテット数そのものではなく、そこから1を引いた値として定義されている点に注意が必要です。

C = (\text{パケットデータフィールドの総オクテット数}) - 1

したがって、実際のデータフィールドのオクテット数は

L_{\text{data}} = C + 1

で求まります。 $C$ は16ビット符号なし整数なので $0 \le C \le 65535$ 、よって

1 \le L_{\text{data}} \le 65536 \ \text{オクテット}

が可変長パケットの許容範囲です。 $C=0$ (データフィールドが1オクテットだけ)から $C=65535$ (データフィールドが最大の65536オクテット、つまり64 KiBぴったり)まで表現できます。これに6オクテットの一次ヘッダを足すと、Space Packet 1個の総オクテット数の上限は

L_{\text{packet,max}} = 6 + 65536 = 65542 \ \text{オクテット}

となります。なぜわざわざ「−1」した値をフィールドに入れるのか、疑問に思うかもしれません。理由は単純で、「データフィールドが0オクテット」というケースはあり得ない(Space Packetは必ず何らかのデータフィールドを持つ)ため、値の範囲をシフトさせることで16ビットのビット幅から最大限の表現力(65536通りではなく65536通りをそのまま1〜65536に対応させる)を引き出しているのです。これは1バイトで表せる情報量を無駄にしないための、組込みシステム設計ではよく見る工夫です。

なお、実際の観測データ(たとえば高解像度画像1枚)がこの最大64 KiBよりずっと大きいことは日常茶飯事です。その場合は、Sequence Flagsフィールドを使ってひとつの大きなデータ単位を複数のSpace Packetに**セグメント化(分割)**します。

11(Unsegmented): このパケット1個で1つの完結したユーザーデータ単位を構成する(もっとも一般的なケース)。
01(First segment): セグメント化されたデータ単位の先頭パケット。
00(Continuation segment): 中間の継続パケット。
10(Last segment): 最後のパケット。

セグメント化されたパケット群は、同じAPIDかつ同じPacket Sequence Countの並びを共有し、地上局側でSequence Flagsを見ながら元のデータ単位に再結合されます。ただし実務では、大容量ファイルの信頼性ある分割転送は、この後の回で扱うCFDPのようなより上位のプロトコルに任され、Space Packet自体のセグメンテーション機構が単独で使われる場面は限定的です。

シーケンスカウントによる順序性と欠落検出

一次ヘッダのもう1つの重要なフィールドが、14ビットの Packet Sequence Count です。これは同一APIDから送出されるパケットに対して、0から始まり1つ生成するごとに1ずつ増える通し番号で、 $2^{14}=16384$ を法として周期的に折り返します。

n_{k+1} = (n_k + 1) \bmod 16384

地上局(あるいはその手前のミッションデータ処理系)は、APIDごとにこのカウント値の連続性を監視することで、パケットが欠落していないかを検出できます。いま、あるAPIDについて連続して受信した2つのパケットのシーケンスカウントが $n_1$ 、 $n_2$ だったとします。期待される値は $(n_1+1)\bmod 16384$ なので、実際に欠落したと推定されるパケット数 $L$ は

L = (n_2 - n_1 - 1) \bmod 16384

で与えられます。 $L=0$ ならば欠落なし、 $L>0$ ならばその個数だけパケットが失われた(あるいは順序が入れ替わって届いた)ことが分かります。

ここで注意すべきなのは、この検出はあくまでmod 16384の世界での相対的な判定にすぎないという点です。もし実際の連続欠落数がちょうど $16384$ の整数倍(たとえば16384個や32768個)だった場合、カウント値は一周してちょうど元の連続値に戻ってしまうため、 $L=0$ と誤って判定されてしまいます。

L_{\text{true}} = L + 16384\,m \quad (m = 0, 1, 2, \dots)

という式が示す通り、シーケンスカウントだけからは $m$ を特定できません。実運用でこれほど大量の連続欠落が起きることは通信途絶(掩蔽や太陽合など)を伴うごく特殊な状況に限られますが、パケット処理系は別途、通信パス(コンタクト)の開始・終了時刻や、下位のフレーム層で管理される情報と突き合わせることで、この種の「折り返しによる見落とし」を防いでいます。

また、このシーケンスカウントによる欠落検出は、あくまで**「何個パケットが失われたか」を教えてくれるだけ**であり、「届いたパケットのビットが正しいか」は一切保証しません。ビット誤りの検出・訂正は、Reed-Solomon符号や畳み込み符号の回で見たように、より下位の物理層・データリンク層の仕事です。Space Packet Protocol自体は誤り検出符号(CRCなど)を一次ヘッダに含んでいません。パケットレベルの完全性は、フレーム層に付与される巡回冗長検査(CRC)や下位の前方誤り訂正符号にすべて委ねる、という明確な役割分担がここにも表れています。

二次ヘッダ(オプション)

一次ヘッダのSecondary Header Flagが1であれば、一次ヘッダの直後に**二次ヘッダ(Secondary Header)が続きます。CCSDS 133.0-Bは二次ヘッダの内部構造そのものは規定せず、「あれば必ず時刻コード(Time Code Field)**で始まり、その後に任意の付加データフィールド(Ancillary Data Field)を置いてよい」という枠組みだけを定めています。実際のビット割り付けはミッションごと(あるいは適用する上位規格ごと)に決めます。

もっともよく使われる枠組みの1つが、ESA(欧州宇宙機関)が定める PUS (Packet Utilisation Standard, ECSS-E-70-41A) です。PUSでは二次ヘッダに「サービスタイプ」「サブサービスタイプ」といったフィールドを追加し、「これはハウスキーピングデータのサービス(サービスタイプ3)である」「これはイベントレポートのサービス(サービスタイプ5)である」といった意味づけをパケット自体に持たせます。これにより、地上のデータ処理系はAPIDだけでなくサービスタイプの組み合わせによって、パケットの用途をより細かく識別・処理できるようになります。二次ヘッダに載る時刻コードの具体的なビット構造(CUC/CDSフォーマット)は、後の回で改めて扱います。

実務での使われ方

Space Packet Protocol(CCSDS 133.0-B-2)は、NASA・ESA・JAXA・ロスコスモスをはじめとするほぼすべての主要宇宙機関のミッションで採用されている、宇宙データシステムのデファクトスタンダードです。実務での使われ方を、開発フェーズと運用フェーズに分けて見てみましょう。

開発・試験フェーズ(AIT: Assembly, Integration and Test)。 探査機に搭載する各観測機器やサブシステムのフライトソフトウェアは、開発の初期段階からSpace Packet Protocolでデータを出力するように設計されます。地上の試験装置である EGSE (Electrical Ground Support Equipment) は、飛行時に地上局が受信するのとまったく同じパケット形式のデータを模擬的に生成・受信できるため、機体が実際に打ち上がる前から、各機器のAPID割り当てが正しいか、パケット長やシーケンスカウントが仕様通りに振る舞うかを、機体に接続したインターフェース試験の段階で検証できます。この「飛行データと試験データが同一フォーマットである」という性質は、開発コストと試験リスクの両方を大きく下げる、CCSDS標準化のもっとも実務的な恩恵の1つです。

APID割り当て。 実際のミッションでは、システムエンジニアリングチームがミッション設計の初期段階で「APID割り当て表(APID Allocation Table)」を策定し、インターフェース制御文書(ICD: Interface Control Document)の一部として管理します。多くのミッションでは、同じ観測機器であってもハウスキーピングデータ(温度・電圧などの機器状態監視データ)と科学観測データを別々のAPIDに分けます。これにより、ハウスキーピングデータだけを優先的に抽出して機器の健全性を即座に確認する、といった運用上の柔軟性が生まれます。

運用フェーズ(ミッション運用センター)。 地上局(DSNなど)がRF信号から復調・復号したビット列は、まずデータリンク層のフレームから個々のSpace Packetへと分解されます(この処理はしばしば「Level 0処理」と呼ばれます)。分解されたパケット列は、APIDフィールドに従って自動的に振り分けられ、姿勢制御系のパケットは軌道・姿勢の解析チームへ、各観測機器のパケットはそれぞれの機器の運用チーム(多くの場合、機器を開発した大学・研究機関)へと転送されます。NASA/JPLのAMMOS(Advanced Multi-Mission Operations System)のような多ミッション対応の地上データシステムは、この「フレームからパケットへの分解とAPIDによる自動仕分け」を汎用的な処理パイプラインとして実装しており、ミッションごとに専用のソフトウェアを1から書く必要がないようになっています。

演習問題

APIDフィールドは11ビットです。理論上表現できるAPIDの総数を求め、そのうち実際にアプリケーションプロセスへ割り当てられる数はいくつになるか(予約されている値を踏まえて)答えてください。
あるSpace PacketのPacket Data Lengthフィールドの値が $C = 1023$ だったとき、(a) パケットデータフィールドの実際のオクテット数、(b) 一次ヘッダを含めたパケット全体のオクテット数、をそれぞれ求めてください。
あるAPIDについて、地上局が連続して受信した2つのパケットのシーケンスカウントが $n_1 = 16000$ 、 $n_2 = 50$ だったとします。式 $L=(n_2-n_1-1)\bmod 16384$ を使って推定される欠落パケット数 $L$ を求めてください。またこの推定値が「真の欠落数」と必ずしも一致しない理由を、mod 16384という制約に触れながら説明してください。
ある探査機に5つの観測機器(カメラ、分光計、磁力計、粒子検出器、放射線モニタ)と、姿勢制御系・電源系という2つのバスサブシステムが搭載されているとします。それぞれにハウスキーピングデータと科学データを別々のAPIDで持たせる設計にする場合、最低いくつのAPIDが必要になるか、自分なりの割り当て表を作って示してください(バスサブシステムに科学データAPIDは不要です)。

まとめと次回予告

Space Packet Protocolは、探査機内の複数のアプリケーションプロセスが生成するデータを、APID(送信元識別)・Packet Data Length(境界の明示)・Packet Sequence Count(順序性と欠落検出)という3つの情報を載せた6オクテットの一次ヘッダで包み、1本の限られたRFリンクの上でも「誰の、どこからどこまでの、何番目のデータか」が地上局側で判別できるようにする、宇宙データシステムの最も基礎的な階層です。この枠組みがあることで、地上局はAPIDを見るだけで受信データを各観測機器・サブシステムの担当チームへ自動的に仕分けることができ、開発段階のEGSEも飛行時とまったく同じデータ形式で試験を行えます。

次回は、視点をもう1段だけRFリンクに近づけ、探査機の中に搭載されるもう1つの重要な仕組み——観測機器と搭載コンピュータをつなぐ内部データバス規格であるSpaceWireに軽く触れながら、複数のSpace Packetがどのようにして物理リンク上のフレームへと多重化されていくのか(Space Data Link Protocolと仮想チャンネル)を扱っていきます。

参考文献

CCSDS 133.0-B-2, Space Packet Protocol, Blue Book
CCSDS 132.0-B, TM Space Data Link Protocol, Blue Book
ECSS-E-70-41A, Ground Systems and Operations — Telemetry and Telecommand Packet Utilization
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