火星探査機の電波が地球に届くまで片道10分以上、太陽系外縁を飛ぶVoyagerに至っては20時間以上かかります。これほど遠くから1ビットずつ送られてくるテレメトリを、どうやって「データの取り違え」「フレーム境界の見失い」「再送要求の混乱」なしに正しく受け取り、逆にコマンドを確実に送り届けるのでしょうか。答えはシンプルで、世界中の宇宙機関が同じ通信プロトコルを使っているからです。その標準が CCSDS（Consultative Committee for Space Data Systems, 宇宙データシステム諮問委員会） が定めるTM/TCプロトコル群です。
CCSDS標準を理解することは、現代の宇宙工学エンジニアにとってほぼ必須のスキルになりつつあります。たとえば、NASAの深宇宙探査機が困窮した際にESAやJAXAの地上局で代理受信できるのは、両者がCCSDSのフレーム構造と符号化階層に準拠しているからです。また、日本の小型衛星が海外の地上局サービス（KSAT、AWS Ground Station等）から運用される事例も増えていますが、これも同じ理由です。さらに、商用衛星オペレータがソフトウェア定義の地上局を構築する際、最初の参照仕様がCCSDSであることが珍しくありません。
本記事の内容
- なぜ宇宙機通信に標準規格が必要なのか（NASA/ESA/JAXAの相互運用の実態）
- CCSDSプロトコル階層と、TM/TC/AOSの位置付け
- Space Packet（アプリケーション層）の構造と役割
- TMフレーム（CCSDS 132.0-B）の主ヘッダ、データフィールド、FECF
- TCフレーム（CCSDS 232.0-B）とCLTU、COP-1再送制御
- ASM（Attached Sync Marker
0x1ACFFC1D）によるフレーム同期 - AOS（CCSDS 732.0-B）の高ビットレート向け拡張機能
- チャネル符号化階層（Reed-Solomon連接符号からLDPCまで）
- 国際運用におけるDSN/ESTRACK/JAXA局の共通化の実態
- Pythonによるフレームヘッダ解析の簡易例
前提知識
この記事を読む前に、以下の記事を読んでおくと理解が深まります。
また、以下の概念に馴染みがあると読みやすくなります。
- CRC（巡回冗長検査）の基本
- 誤り訂正符号（FEC）と符号化利得の概念
- HDLCやEthernetなど、地上系の通信フレームのおおまかな構造
なぜCCSDS標準が必要なのか
標準なき時代に起きていた問題
1970年代まで、宇宙機の通信プロトコルはミッションごとに「手作り」でした。NASAのMariner、ESAの初期Helios、ソ連のVenera — それぞれが固有のテレメトリ形式、固有のコマンド体系、固有の同期手法を持っていました。各機関が世界中に複数の地上局を建設する必要があり、しかも他機関のミッションが緊急事態に陥ったとしても助け合うことができない、という非効率が顕在化しました。
そこで1982年、欧米日加など主要宇宙機関の集まりとしてCCSDSが設立されます。最初の標準としてリリースされた TM Space Data Link Protocol（CCSDS 102.0-B、現行は132.0-B） と TC Space Data Link Protocol（CCSDS 202.0-B、現行は232.0-B） がその後数十年、地球周回衛星から深宇宙探査機までを支える共通基盤となりました。
身近な例で言えば、HTTPやTCP/IPがインターネットの相互接続を支えているように、CCSDSが宇宙の相互接続を支えています。ただし宇宙通信は地上のインターネットと異なり、片道何十分の伝搬遅延、コマンド誤りが致命的になる安全性、そして低S/N（信号対雑音比）下での確実な誤り訂正、という独特の制約があるため、CCSDSはこれらの制約に最適化された設計を持っています。
国際相互運用の具体例
CCSDS準拠の最大のご利益は、地上局の相互貸し借り が可能になることです。代表例を挙げてみましょう。
- NASA Deep Space Network（DSN） — Goldstone、Madrid、Canberraの3局が経度差120度で配置され、世界中の深宇宙探査機を24時間追跡できる。日本のはやぶさ・はやぶさ2もDSNを併用した
- ESA ESTRACK — Cebreros、New Norciaなどに深宇宙対応の35 mアンテナを持ち、NASAミッションのバックアップ局として機能する
- JAXA 美笹深宇宙局 — 直径54 mの大型アンテナを持ち、Mars Expressなど他機関の探査機データ受信にも貢献している
これらの局はすべて、CCSDSの規定する同一のフレーム同期パターン（ASM 0x1ACFFC1D）、同一のフレーム長、同一の符号化階層に対応しています。だからこそ、ミッション中に自国の局が悪天候や故障で運用できない場合でも、他機関の局が即座に代理受信できるのです。
宇宙機通信における国際標準の必要性を理解したところで、次にCCSDSが定めるプロトコル階層全体の見取り図を確認しましょう。
CCSDSプロトコル階層の全体像
OSI参照モデルとの対応
CCSDSはISO/OSIの7層モデルに概ね対応する形でプロトコルスタックを階層化しています。ただし、宇宙通信特有の事情（極端な遅延、低S/N、信頼性要件）を反映して、各層には地上系とは異なる工夫が織り込まれています。下表は代表的な対応関係です。
| OSI層 | CCSDS規格（代表例） | 役割 |
|---|---|---|
| アプリケーション | CCSDS 133.0-B Space Packet Protocol | アプリケーションデータ単位（APID付き） |
| ネットワーク | CCSDS 734.2-B SPP/Encapsulation, DTN（CCSDS 734.1-B） | 衛星間中継・遅延耐性ネットワーク |
| データリンク（プロトコルサブレイヤ） | CCSDS 132.0-B TM / 232.0-B TC / 732.0-B AOS | フレーム化、Virtual Channel管理、再送 |
| データリンク（同期＆チャネル符号化） | CCSDS 131.0-B TM Synchronization and Channel Coding | ASM挿入、Reed-Solomon、畳み込み、LDPC等 |
| 物理層 | CCSDS 401.0-B RFモジュレーション標準 | 変調、周波数、フィルタ |
「データリンク層」がさらに「プロトコルサブレイヤ」と「同期＆チャネル符号化サブレイヤ」に分かれている点が宇宙通信特有のポイントです。前者がフレーム構造やVirtual Channelといった論理構造を扱い、後者がそのフレームを物理層の上に安全に流すための同期と誤り訂正を担います。
TM/TC/AOSの使い分け
CCSDSのデータリンク層には主要な3つのプロファイルがあります。それぞれ用途が明確に分かれているので、最初に押さえておきましょう。
- TM Space Data Link Protocol（CCSDS 132.0-B） — 宇宙機 → 地上のテレメトリ伝送。固定長フレーム、ストリーム型。深宇宙探査機の標準
- TC Space Data Link Protocol（CCSDS 232.0-B） — 地上 → 宇宙機のコマンド伝送。可変長フレーム、確実な配送が要件。COP-1再送機構を持つ
- AOS Space Data Link Protocol（CCSDS 732.0-B） — 高ビットレート対応のTM拡張。データ多重化やパケットストリーム伝送に強い。ISSや地球観測衛星で広く使われる
TMが「読み出し中心の生中継」、TCが「確実に配信される指示書」、AOSが「TMの拡張高機能版」とイメージするとわかりやすいでしょう。本記事ではこの3つを順に取り上げていきます。
プロトコル階層と用途の見取り図ができたところで、次に最上層のSpace Packetから順に降りていきましょう。
Space Packet — アプリケーション層
Space Packetとは
Space Packet（CCSDS 133.0-B） は、宇宙機の中で動く各アプリケーション（センサ、推進系、姿勢制御系、ペイロード等）が生み出すデータを「パケット」という単位にまとめる、最上位の論理単位です。地上のインターネットにおけるIPパケットに相当する位置付けですが、宇宙機向けにグッと簡素化されています。
なぜパケット化が必要かというと、宇宙機には多数のサブシステムがあり、それぞれが独立にデータを生成するからです。たとえば姿勢制御CPUは10 Hzで姿勢データを出し、ペイロードカメラは画像取得時に大量データを吐き、サーマルセンサは1 Hzで温度を出す、といった具合です。これらを区別するために、各パケットには APID（Application Process ID） という識別子が付けられます。APIDは11ビット幅で、0〜2047まで割り当て可能です。
Space Packet ヘッダ構造
Space Packetは6バイトの主ヘッダ（Primary Header）と、可変長のデータフィールド、そしてオプションの副ヘッダから構成されます。テキスト図で示すと次のようになります。
+---------------+---------------+---------------+---------------+---------------+---------------+
| Octet 0 | Octet 1 | Octet 2 | Octet 3 | Octet 4 | Octet 5 |
+---------------+---------------+---------------+---------------+---------------+---------------+
| Ver(3) Type(1)| APID (11 bits) | SeqFlags(2)| Packet Seq Count (14 bits) |
| SecHdrFlag(1)| | | |
+---------------+---------------+---------------+---------------+---------------+---------------+
| Packet Data Length (16 bits, value = length - 1) |
+------------------------------------------------------------------------------------------------+
| Data Field (variable, includes optional Secondary Header) |
+------------------------------------------------------------------------------------------------+
主要なフィールドを順に説明します。
- Version (3 bit): パケットのバージョン番号。標準のSpace Packetでは
000 - Type (1 bit): テレメトリ（0）かテレコマンド（1）か
- Secondary Header Flag (1 bit): 副ヘッダがあるか
- APID (11 bit): アプリケーションプロセスID。APID
0x000はアイドルパケット用、0x7FFは予約 - Sequence Flags (2 bit): パケットが分割されているかを示す（
11が単一パケット、01が先頭、00が中間、10が末尾） - Packet Sequence Count (14 bit): 同じAPIDのパケットに付ける通し番号
- Packet Data Length (16 bit): データフィールド長から1引いた値。最大65536バイト
注意したいのは、Packet Data Length は データフィールド長 − 1 という形でエンコードされる点です。たとえばデータが100バイトなら、ここには99（0x0063）が入ります。これにより、長さ0は表現できず、最小1バイトから最大65536バイトまでを16ビットで表せるようになっています。仕様の細部に宇宙ならではの「無駄なくビットを使い切る」思想が見えます。
APIDで何を区別するか
APIDは単なる識別子ではなく、運用上の重要な意味を持ちます。実際のミッションでは、例えば以下のような割り当てが行われます。
- APID
0x10〜0x1F: 姿勢制御サブシステム - APID
0x20〜0x2F: 推進系 - APID
0x30〜0x3F: 熱制御 - APID
0x40〜0x4F: 通信系 - APID
0x100〜0x1FF: ペイロード（カメラ、分光計など）
地上のミッション運用システム（MOC: Mission Operations Center）では、APIDを見ただけでパケットをどの担当チームへルーティングすべきかが決定されます。これにより、大規模ミッションでも数十のサブチームが並行して自分の担当パケットだけを受信・処理できる、というスケーラブルな運用が可能になります。
Space Packetはアプリケーションが生み出す論理単位ですが、これを実際にRF回線に乗せるためには、もう一段下のフレーム化が必要です。次に、TMフレームへの埋め込みを見ていきましょう。
TMフレーム構造 — テレメトリの固定長フレーム
TMフレームの全体構造
CCSDS 132.0-Bが規定する TM Transfer Frame は、宇宙機から地上へのテレメトリ伝送に使われる固定長フレームです。固定長である点が地上のEthernet等と大きく異なり、これは深宇宙の長い伝搬遅延下で同期検出を確実にするための設計です。フレーム長は典型的に1024バイトや1115バイトが選ばれます。
+---------+------------------+--------------------+-------+----------+
| Primary | Secondary Header | Transfer Frame | OCF | FECF |
| Header | (optional) | Data Field | (opt.)| (CRC-16) |
| 6 octets| <=64 octets | variable | 4 oct.| 2 octets |
+---------+------------------+--------------------+-------+----------+
|<------------------ Transfer Frame (固定長) ------------------------>|
フレームの主要パーツは次の通りです。
- Primary Header (6 octet): バージョン、宇宙機ID、Virtual Channel ID、フレーム連番などを含む
- Secondary Header (オプション): ミッション固有の追加情報
- Transfer Frame Data Field: 実際のSpace Packetが詰め込まれる本体
- OCF (Operational Control Field, 4 octet, オプション): COP-1のCLCWなど運用制御情報
- FECF (Frame Error Control Field, 2 octet): CRC-16-CCITTによる誤り検出
なぜFECFが必要かというと、後段の誤り訂正符号（Reed-Solomon、LDPC等）が訂正しきれずに残った誤りを 確実に検出して捨てる ためです。誤った姿勢テレメトリが正しいフリで地上に届くと、運用判断を誤って衛星を喪失しかねません。検出だけでも極めて重要なのです。
Primary Header の中身
TMの主ヘッダ6バイトは、以下のように構成されています。
Octet 0-1 (Frame Identification):
+--------+------------------+----------------+---------+
| Ver(2) | Spacecraft ID(10)| Virtual Ch(3) | OCF(1) |
+--------+------------------+----------------+---------+
Octet 2 (Master Channel Frame Count):
+----------------------------------+
| Master Channel Frame Count (8) |
+----------------------------------+
Octet 3 (Virtual Channel Frame Count):
+----------------------------------+
| Virtual Channel Frame Count (8) |
+----------------------------------+
Octet 4-5 (Transfer Frame Data Field Status):
+-----+-----+-----+----+--------------------+
| TFS | SH | SyP | PO | First Header Ptr |
| (1) | (1) | (1) | (2)| (11) |
+-----+-----+-----+----+--------------------+
各フィールドのうち、運用上特に重要なものを取り上げましょう。
- Spacecraft ID (10 bit): 宇宙機の固有ID。CCSDSが世界規模で番号管理しており、ぶつからない
- Virtual Channel ID (3 bit): 同じ物理回線を論理的に最大8チャネルに分けて使う。例えばリアルタイムテレメトリ、再生テレメトリ、画像データを別々のVCに乗せて優先度管理する
- Master Channel Frame Count (8 bit): 衛星全体（全VC合計）で何番目のフレームか
- Virtual Channel Frame Count (8 bit): 各VCごとに独立に番号を付けたフレーム連番。地上はこれを見て欠落を検出する
- First Header Pointer (11 bit): フレーム内で最初のSpace Packetヘッダが始まるオクテット位置。可変長Space Packetを固定長フレームに詰める都合上、フレーム途中で前のパケットの続きが始まることがあるため、新しいパケットの開始位置を別途指示する必要がある
特に Virtual Channel の概念は、宇宙機通信を地上系と区別する象徴的な機構です。1本の物理回線（例えばX帯ダウンリンク）の中に、最大8本の独立した論理回線を多重化できます。たとえばカメラ画像の大量データはVC0、姿勢ハウスキーピングはVC1、ペイロード科学データはVC2、緊急アラームはVC7（最高優先度）、というように使い分けます。これにより、画像伝送中に異常が発生しても、緊急アラームが優先的に流れる仕組みが実現できます。
Virtual Channelによる優先度管理
Virtual Channelをどう扱うかは、衛星オンボードソフトウェアの設計上の中核的な課題です。最も一般的なアプローチは重み付きラウンドロビンです。各VCに優先度を割り当て、その重みに比例してフレームを順次送信していきます。たとえば次のようなスケジュールが考えられます。
- VC0（画像）: 重み 4
- VC1（HK）: 重み 2
- VC2（科学）: 重み 3
- VC7（緊急）: 重み 100（実質常に最優先）
VC7にデータがあるときは即座に送出し、それ以外は重みに従って公平に切り替えていきます。フレーム単位での切り替えなので、HDLCのようなパケット単位の制御に比べて実装がシンプルで、リアルタイム制御チップ上でも実装しやすいのが利点です。
ここで一つ自然な疑問が生まれます — 「固定長フレームに可変長Space Packetを詰める」とき、フレーム境界とパケット境界が一致しなかった場合はどうなるのでしょうか。
Space Packet とフレーム境界
可変長のSpace Packetを固定長フレームに詰めると、当然ながらフレーム末尾の途中でパケットが切れることがあります。CCSDSではこの状況を First Header Pointer (FHP) で解決しています。
FHPには、フレーム内で新しいSpace Packetのヘッダが始まる位置（オクテット番号）が入ります。特殊値として 0x7FF は「このフレーム内に新しいパケットの開始がない（前のフレームから続くデータのみ）」を意味します。地上側はFHPを見て、フレームをまたぐパケットも正しく再構築できるのです。これにより、固定長フレームの恩恵（同期検出の容易さ）を保ちつつ、上位層は可変長パケットを自由に使えます。
TMフレームの構造とVirtual Channelによる多重化が理解できたところで、次はその逆方向、地上から宇宙機に送るTCフレームを見てみましょう。
TCフレーム構造とCOP-1再送制御
TCの設計思想
TC Space Data Link Protocol（CCSDS 232.0-B） は、地上から宇宙機へのコマンド伝送を担います。TMとは設計思想が大きく異なる点が3つあります。
- 可変長フレーム — コマンドの長さは多様なので、可変長を許容する（最大1024オクテット）
- 確実な配送 — コマンドの取り違えや欠落は致命的なので、ACK/NAKに基づく COP-1再送機構 が組み込まれる
- 短いCLTU方式 — フレーム自体を CLTU（Communications Link Transmission Unit） という単位で送り、BCH符号で短いブロック単位で誤り訂正する
TM側が「ストリーム型・確率的訂正で十分」だったのに対し、TC側は「離散型・絶対に確実」が要求されます。この非対称性が宇宙機通信の特徴的な部分です。
TCフレーム構造
TCフレームは以下の構造を持ちます。
+----------+------------------+----------+
| Primary | Frame Data Field | FECF |
| Header | | (CRC-16) |
| 5 octets | variable | 2 octets |
+----------+------------------+----------+
主ヘッダは5バイトで、宇宙機ID、Virtual Channel ID、フレーム長（10ビット）、フレーム連番（8ビット）、Bypass Flag、Control Command Flagなどを含みます。Bypass FlagとControl Command Flagは、後述するCOP-1の動作モードを切り替えるための重要なフィールドです。
COP-1再送制御の仕組み
COP-1（Communications Operations Procedure-1） は、TCフレームを地上→宇宙機間で確実に届けるためのプロトコルです。位置付けとしてはTCPのACKに似ていますが、宇宙ならではの特徴があります。
宇宙機側には FARM（Frame Acceptance and Reporting Mechanism） が、地上側には FOP（Frame Operations Procedure） が動作します。地上はTCフレームに連続的にシーケンス番号 $N(S)$ を付けて送信し、宇宙機は受信したフレームに対して CLCW（Communications Link Control Word） をテレメトリ側に乗せて返します。CLCWには次に期待するシーケンス番号 $V(R)$ が含まれています。
地上側は、自分が次に送るシーケンス番号 $V(S)$ と、宇宙機が次に期待しているシーケンス番号 $V(R)$ の差から、宇宙機がまだ受け取っていないフレームを判定し、再送します。シーケンス窓 $W$ 以内のフレームしか未確認のままにできないため、地上はACKが返るまで一定枚数で送信を止めて待つ必要があります。
往復遅延 $T_{\text{RTT}}$ が大きい状況での実効ビットレート $R_{\text{eff}}$ は、フレーム長 $L$、シーケンス窓 $W$、リンクレート $R$ を用いて次のように見積もれます。
$$ R_{\text{eff}} = \min\left(R, \frac{W \cdot L}{T_{\text{RTT}}}\right) $$
火星探査機で $T_{\text{RTT}} \approx 20\,\text{min} = 1200\,\text{s}$、$L = 1024\,\text{byte}$、$W = 256$ の場合を考えてみましょう。
$$ \frac{W \cdot L}{T_{\text{RTT}}} = \frac{256 \times 1024 \times 8}{1200} \approx 1750\,\text{bps} $$
つまり物理リンクが何Mbpsあろうとも、COP-1単独では実効ビットレートが1.7 kbps程度に頭打ちになります。これが深宇宙ミッションで「コマンドはバルク的にアップロードしておく」運用が好まれる理由です。
CLTUとBCH符号
TCフレームをそのまま物理層に流すのではなく、CCSDSではフレームをさらに CLTU（Communications Link Transmission Unit） という単位に包んでから変調器に送ります。CLTUの構造は次のようになります。
+---------------------+-------------------------+----------+
| Start Sequence | Codeblocks (BCH(63,56)) | Tail Seq |
| 0xEB90 (16 bit) | each contains 7 octets | |
+---------------------+-------------------------+----------+
ポイントは、フレームを7オクテット（56ビット）ずつに区切って BCH(63,56)符号 を被せ、7ビットのパリティを足して63ビットのコードブロックを作る点です。各コードブロックで1ビットの誤りを訂正できるので、TC方向では誤訂正による「ありもしないコマンド」を作り出す危険が極小化されます。
これは、TM側がReed-Solomonや畳み込み符号のような「強力だが訂正失敗時に新しい誤りパターンを生む可能性のある」符号を使うのと、対照的な選択です。TC側では「訂正できる量を最小限にとどめ、もし訂正しきれなければ素直にフレームを捨てて再送に頼る」という、保守的な設計哲学が貫かれています。
TCフレームの確実な配送機構が理解できたところで、次に全てのフレーム伝送の起点となる「フレーム同期」の問題を見てみましょう。
フレーム同期 — ASMとビット同期
なぜフレーム同期が難しいか
宇宙機からのダウンリンク信号は、地上局では 連続的なビット列 としてしか受信されません。受信機がまずすべきことは「このビット列のどこから1フレームが始まっているのか」を見つけることで、これを フレーム同期 と呼びます。
地上の有線通信ならフレーム境界の検出は容易ですが、宇宙通信では信号対雑音比（S/N）が極端に低く、雑音の中に偶然「フレーム開始らしい」パターンが現れる可能性があります。誤って同期を取ってしまうと、それ以降のすべてのフレームを誤位置で切り出してしまい、全データが破棄されることになります。
ASM 0x1ACFFC1D の魔法
CCSDSはこの問題を ASM（Attached Sync Marker） で解決しています。全てのTM/AOSフレームの先頭に、固定パターン
$$ \text{ASM} = \texttt{0x1ACFFC1D} $$
（32ビット = 4オクテット）を必ず付加します。地上の同期回路は、受信ビット列とこの32ビットパターンの相関を取り続け、相関ピークが立った位置をフレーム開始と判定します。
なぜこのパターンなのでしょうか。0x1ACFFC1Dは二進数で
0001 1010 1100 1111 1111 1100 0001 1101
であり、0と1がほぼ均等に分布し、自己相関が「中央のピーク以外で十分小さくなる」性質を持つように選ばれています。具体的には、任意のシフトでの自己相関値が小さく、雑音による誤検出が起きにくい設計です。
フレーム同期の偽検出確率
フレーム同期の質を評価するには、偽検出確率の理論を押さえる必要があります。ビット誤り率 $p$ のチャネルで、$N$ ビットの同期パターンに対し最大 $k$ ビットの誤りを許容する場合、ランダムなビット位置で偽検出が起きる確率は
$$ P_{\text{false}} = \sum_{i=0}^{k} \binom{N}{i} \cdot 2^{-N} $$
で見積もれます。$N = 32$、$k = 0$（誤り許容なし、完全一致）の場合は $P_{\text{false}} = 2^{-32} \approx 2.3 \times 10^{-10}$ となり、たとえ100 Mbpsの回線でも誤検出は1秒あたり0.02回程度で済みます。
一方、低S/Nではビット誤り率 $p$ が高くなるため、完全一致ではASMを見逃してしまいます。そこで実装上は $k$ を1〜3程度に緩めます。$k = 3$、$N = 32$ の場合の偽検出確率は
$$ \binom{32}{0} + \binom{32}{1} + \binom{32}{2} + \binom{32}{3} = 1 + 32 + 496 + 4960 = 5489 $$
を $2^{-32}$ 倍した値、つまり約 $1.3 \times 10^{-6}$ となり、これでも数百 kbps の運用なら現実的です。
ロック・サーチ・フライウィール状態
実用の同期回路は 状態機械 として動きます。代表的な3状態モデルが下記です。
- Search（探索）— まだ同期していない状態。連続するビット列を1ビットずつシフトしてASMを探す。1個見つけたらVerifyへ
- Verify / Check（確認）— 次に来るべき位置にもASMがあるか確認する。フレーム長 $L$ ビット先に再びASMが出現すれば本物の同期と判定し、Lockへ
- Lock（同期確立）— 以降はフレーム長ごとに同期点を予測。多少のASM見逃しは「フライウィール」モードで耐え、連続失敗で同期外れと判定
このように、偽検出を完全に排除するのではなく、確率的に減らしながらシステム全体の頑健性を上げる設計になっています。
ASMによってフレーム境界が確実に取れるようになったところで、次はTMの拡張版である AOS を取り上げ、より高度な機能を見ていきましょう。
AOS — 高度オービット系の拡張機能
AOSの動機
AOS（Advanced Orbiting Systems, CCSDS 732.0-B） は、ISSや地球観測衛星、近年の小型衛星などの「高ビットレート・多種データ多重」が必要な用途向けに、TMを拡張したプロファイルです。TMの基本構造を踏襲しつつ、以下を追加しています。
- Insert Zone — フレーム主ヘッダ直後に固定長の挿入域。時刻スタンプなど一定情報を毎フレーム同位置に置く
- M_PDU（Multiplexing Protocol Data Unit） — 可変長Space Packetを多重化するためのデータ単位。FHPの仕組みを改良
- B_PDU（Bitstream Protocol Data Unit） — ビットストリーム（ビデオ等）をそのまま運ぶデータ単位
- VCA_SDU — Virtual Channel Access用の汎用データ単位。ユーザ定義のサブプロトコルが乗せられる
- OID（Only Idle Data）パッキング — 空きフレームをアイドルデータで埋める仕組み
AOSフレームの構造は次のようになります。
+---------+--------+--------------+----------------+-------+----------+
| Primary | Insert | Transfer | Trailer | OCF | FECF |
| Header | Zone | Frame Data F | (option) | (opt.)| (opt.) |
| 6 oct. | fixed | variable | | 4 oct.| 2 oct. |
+---------+--------+--------------+----------------+-------+----------+
特に Insert Zone が興味深い設計です。例えばISSではここに「フレーム生成時刻（UTC、秒単位）」を毎フレーム入れています。これにより、地上でフレームを並べ替える際、フレーム順序だけでなく時刻軸での正確な並び替えが可能になります。
Virtual Channelの拡張
TMでは3ビットしかなかったVirtual Channel IDが、AOSでは6ビットに拡張され、最大64のVCを許容します。ISSのように多数のペイロードが同時にデータを出力する環境では、3ビットでは足りないからです。さらに VCID = 0x3F がアイドルデータ用に予約され、ダウンリンクが空いている時間も継続的にフレームを流せる設計です。これにより同期回路が外れにくくなる、というメリットがあります。
AOSは現代の地球観測衛星（Landsat、Sentinel、ASNARO等）や、JAXAのHTV-X、ISSの実験データダウンリンクなど、ありとあらゆる「中〜高レート系」で標準となっています。
AOSがフレーム層の機能を強化したのと並行して、もう一つの強化方向が チャネル符号化 です。次にCCSDSの符号化階層を見ていきましょう。
チャネル符号化階層
符号化階層の役割
宇宙通信では、低送信電力・長距離・低S/Nというハンディキャップを補うため、強力な誤り訂正符号（FEC: Forward Error Correction）が必須です。CCSDSはミッションごとの選択肢として、複数の符号化方式を CCSDS 131.0-B（TM Synchronization and Channel Coding） で標準化しています。
これらは年代順に進化しており、ミッションが許容する複雑度と要求性能に応じて選ばれます。
| 符号化方式 | 規格上の登場 | 典型的なBER 10^-5 達成 Eb/N0 [dB] | 主な用途 |
|---|---|---|---|
| 畳み込み符号 K=7, R=1/2 | 1984年 | 約5.0 | 古典的TM、Voyager等 |
| Reed-Solomon (255,223) | 1987年 | (連接時) | 連接の外側符号 |
| RS+畳み込み 連接 | 1990年代 | 約2.5 | はやぶさ、Mars系 |
| Turbo符号 R=1/6 | 2002年 | 約0.1 | 深宇宙、Mars Express |
| LDPC符号 各種レート | 2007年〜 | 約0.7 | 近年の地球観測衛星 |
性能の指標として、目標BERを得るために必要な $E_b/N_0$（1ビットあたりの信号エネルギーと雑音電力密度の比）が小さいほど、より低S/Nで動作できることを意味します。シャノン限界はR = 1/2でおよそ0.2 dB前後なので、Turbo・LDPCはほぼ理論限界に肉薄しています。
Reed-Solomon (255,223) — 外側符号の定番
Reed-Solomon (255,223) は、255バイトのうち223バイトが情報ビット、残り32バイトがパリティです。最大16バイト（128ビット）のシンボル誤りを訂正できます。
なぜ255というキリの悪い長さかというと、これがバイト（8ビット）単位での最大長 $2^8 – 1 = 255$ だからです。8ビットを1シンボルとするガロア体 $\mathrm{GF}(2^8)$ 上で構成すると、自然に最大シンボル数が255になります。
RS符号は バースト誤りに強い のが特徴で、衛星通信で起こりやすい「短時間の信号落ち込み」「フェージング」によるまとまった誤りを効率よく訂正できます。詳細はReed-Solomon符号 — 衛星通信を支える誤り訂正の王道 を参照してください。
連接符号 — RS + 畳み込み
長年深宇宙ミッションの主役だったのが 連接符号（Concatenated Code） です。アーキテクチャは下図のような二段構成です。
[Source Data] -> [Reed-Solomon (255,223) Encoder]
-> [Interleaver (Depth 5)]
-> [Convolutional Encoder (K=7, R=1/2)]
-> [Modulator] -> Channel
外側のReed-Solomonがブロック符号として「比較的稀に起きる大きな誤り」を訂正し、内側の畳み込み符号が「頻繁に起きる小さな誤り」を訂正します。両者の間に インターリーバ が入り、内側のViterbi復号後に残るバースト誤りを時間方向に分散させてから外側のRSへ渡します。これにより、両者の強みが補完的に活きる、洗練された構成になっています。
この連接符号は、$E_b/N_0 \approx 2.5\,\text{dB}$ でBER $\le 10^{-5}$ を達成し、ISEE-3、Voyager後期、Galileo、Cassini、はやぶさ、Mars Pathfinder、Mars Global Surveyorなど、20年以上にわたり主役の座にありました。詳細は畳み込み符号とViterbi復号 — 高効率な誤り訂正 を参照してください。
Turbo符号とLDPC符号 — シャノン限界への接近
2000年代以降、計算機の能力向上により、より複雑だが性能の高い符号が実用化されました。
Turbo符号 は2つのRSC（Recursive Systematic Convolutional）符号器をインターリーバ越しに並列接続したもので、反復復号により $E_b/N_0 \approx 0.1\,\text{dB}$ という驚異的な性能を達成します。CCSDS 131.0-Bでは Rate 1/2、1/3、1/4、1/6 のTurbo符号が標準化されています。Mars Reconnaissance Orbiterや、近年の深宇宙ミッションで採用されています。詳細はTurbo符号の理論 — 反復復号によるシャノン限界への挑戦 を参照してください。
LDPC符号（Low-Density Parity Check） はTurboとは異なるアプローチで、極めて疎なパリティ検査行列を持つ線形ブロック符号です。Sum-Product復号により高い並列性で実装でき、近年の地球観測衛星（DVB-S2X含む）で広く採用されています。CCSDS 131.0-BではAR4JAと呼ばれる構造化LDPCがレート1/2、2/3、4/5などで標準化されています。詳細はLDPC符号の理論と実装 — 疎な検査行列で実現する高速復号 を参照してください。
符号化利得の見積もり
各符号化方式の効果を 符号化利得（Coding Gain） で定量化できます。符号化利得は「同じBERを達成するのに必要な $E_b/N_0$ の差」として定義され、
$$ G_c = \left( E_b/N_0 \right)_{\text{uncoded}} – \left( E_b/N_0 \right)_{\text{coded}} \quad [\text{dB}] $$
で計算されます。BER $10^{-5}$ を基準にすると、
- 畳み込み符号 K=7, R=1/2: $G_c \approx 5.4\,\text{dB}$
- 連接符号 (RS + 畳み込み): $G_c \approx 7.9\,\text{dB}$
- Turbo符号 R=1/2: $G_c \approx 10.3\,\text{dB}$
- LDPC AR4JA R=1/2: $G_c \approx 9.7\,\text{dB}$
5 dBの利得はリンクバジェット上 送信電力を約1/3にできる ことを意味します。深宇宙探査機の送信電力は数十W程度しかなく、しかも光速分の数で球面拡散する電波の中で1 ppmにも満たない電力しか地球に届かない世界です。符号化利得の数 dB は文字通り「ミッションが成立するかどうか」を分けます。
ここまでCCSDSのプロトコル階層と符号化階層を見てきました。次に、実際の運用現場でこれらの仕組みがどう活きているかを、国際運用の事例で見てみましょう。
国際運用例 — DSN/ESTRACK/JAXAの相互運用
「電波が届かない時間」を消す世界戦略
CCSDSの最大の運用上の恩恵は、他機関の地上局を借りられる ことです。深宇宙では地球の自転で1日約8時間しか単一局から見えない探査機を、3局が経度差120度で囲んで24時間追跡する仕組みが必要です。
- NASA: Goldstone (35.4N, 116.9W), Madrid (40.4N, 4.2W), Canberra (35.4S, 149.0E)
- ESA: Cebreros (40.5N, 4.4W), New Norcia (31.0S, 116.2E), Malargue (35.8S, 69.4W)
- JAXA: 美笹深宇宙局 (36.1N, 138.4E)
地理的に分散したこれらの局は、それぞれ独自に運営されていますが、全てがCCSDSのASM、フレーム長、符号化階層に準拠 しているため、相互の予約システムを通じて代理受信が可能です。
実際の例として、はやぶさ初号機の地球再突入時には、最終的なテレメトリ受信にDSNのキャンベラ局を使用しました。地球から見て探査機の位置が日本の真裏にあったため、JAXAの美笹局では受信できなかったからです。逆に、火星探査機のクリティカルイベント時にDSNが故障した際、ESAやJAXAの局がバックアップとして待機している事例が多数あります。
CCSDS Cross-Support Service
国際相互運用をさらに体系化したのが SLE（Space Link Extension, CCSDS 910.x-B） です。SLEは「ある機関の地上局で受信したテレメトリを、ネットワーク経由で別の機関のMOCに転送する」ためのプロトコル群で、
- RAF（Return All Frames）: 受信した全フレームを生で転送
- RCF（Return Channel Frames）: 特定のVCのフレームだけを転送
- CLTU: 地上→宇宙機方向のコマンドCLTUを転送
などのサービスを定義しています。AWS Ground Stationのようなクラウド型地上局サービスも、内部的にはこのSLEに準拠しており、ユーザは世界中のAWS局で受信したフレームを自社のサーバに直接ストリーム配信できます。
商用への波及
近年の商用衛星市場では、ベンチャー企業でも「打ち上げた瞬間からCCSDS準拠で運用」というケースが普通になりつつあります。なぜかというと、
- オープンソース実装（NASA cFS、Goddard Space Flight Centerのcore Flight Systemなど）がCCSDS前提で書かれているため、独自プロトコルを使うとフライトソフトウェアの開発コストが急増する
- 地上局サービス（KSAT、Leaf Space、Atlas、AWS Ground Station等）が全てCCSDSのみをサポートしている
- 投資家・保険会社・宇宙交通管理機関への報告フォーマットがCCSDSベースに収斂しつつある
このように、CCSDSは単なる「機関間の標準」を超えて、宇宙産業全体のデファクトスタンダードに育っています。
国際運用の実態が見えたところで、最後に簡単なPythonコードでフレームヘッダの解析を体験してみましょう。
Pythonによるフレームヘッダ解析の例
TM主ヘッダのパース
CCSDS TM主ヘッダを生バイト列から抽出する簡単な関数を書いてみます。
import struct
from dataclasses import dataclass
@dataclass
class TMFrameHeader:
version: int
spacecraft_id: int
virtual_channel_id: int
ocf_flag: int
master_channel_frame_count: int
virtual_channel_frame_count: int
first_header_pointer: int
def parse_tm_header(raw: bytes) -> TMFrameHeader:
"""CCSDS TM Primary Header (6 bytes) をパース."""
assert len(raw) >= 6, "Header must be at least 6 bytes"
# Octet 0-1: Frame Identification
word0 = struct.unpack(">H", raw[0:2])[0]
version = (word0 >> 14) & 0x03
spacecraft_id = (word0 >> 4) & 0x3FF
virtual_channel_id = (word0 >> 1) & 0x07
ocf_flag = word0 & 0x01
# Octet 2-3: Frame Counts
master_count = raw[2]
vc_count = raw[3]
# Octet 4-5: Transfer Frame Data Field Status
word2 = struct.unpack(">H", raw[4:6])[0]
first_header_pointer = word2 & 0x07FF
return TMFrameHeader(
version=version,
spacecraft_id=spacecraft_id,
virtual_channel_id=virtual_channel_id,
ocf_flag=ocf_flag,
master_channel_frame_count=master_count,
virtual_channel_frame_count=vc_count,
first_header_pointer=first_header_pointer,
)
# 例: ASMに続く仮想的なTMフレーム先頭6バイト
example = bytes([0x49, 0x25, 0x2A, 0x11, 0x00, 0x08])
header = parse_tm_header(example)
print(header)
このコードが出力する TMFrameHeader の各フィールドは、CCSDSのビットレイアウト仕様にそのまま対応しています。実機ではここに加えて、
- ASMの位置を別途検出してフレーム境界を確定する
- フレーム末尾の2バイトを取り出し、CRC-16-CCITTで FECF を検証する
- First Header Pointer の位置から Space Packet を切り出して APID 別に振り分ける
という3つの処理を追加すれば、最小限のTMデコーダになります。実装としてはわずか200行程度に収まるシンプルさで、HDLCやTCP/IPのデコーダと比べても格段に小さい点が、宇宙機通信プロトコルの「シンプルさを徹底した思想」を物語っています。
まとめ
本記事では、CCSDSが定めるTM/TC/AOSプロトコル群を、フレーム構造から国際運用までを通して体系的に解説しました。
- 国際標準としての位置付け — NASA/ESA/JAXAをはじめとする宇宙機関が共通利用するため、地上局の相互貸し借りや代理受信が可能になっている
- プロトコル階層 — Space Packet（アプリケーション）、TM/TC/AOSフレーム（データリンク）、同期＆チャネル符号化（物理層直前）の3層構造
- Space Packet — APIDで識別される可変長パケット。宇宙機内のアプリケーション単位
- TMフレーム — 固定長フレーム、Virtual Channelによる多重化、FECF（CRC-16）で誤り検出
- TCフレーム — 可変長、COP-1再送機構で確実な配送、CLTUでBCH(63,56)符号による短ブロック訂正
- ASM
0x1ACFFC1D— 32ビットの固定パターンで雑音下でもフレーム境界を確実に検出 - AOS — 高ビットレート向けの拡張、64個のVirtual Channel、Insert Zoneで時刻付け
- チャネル符号化 — 古典的な畳み込み + Reed-Solomon連接から、Turbo、LDPCへと進化し、シャノン限界に肉薄
- SLEとクラウド地上局 — 国際相互運用を体系化、商用衛星のデファクトスタンダードへ
CCSDSの規格群は、表面的な「フォーマットの仕様」を超えて、深宇宙の片道遅延、低S/N、安全性要件、機関間政治、商用エコシステムといった、宇宙通信を取り巻く全ての制約に対する先人たちの解答 が結晶化されたものです。これからの宇宙通信エンジニアにとっては、まさに「読まずには始まらない」必読仕様と言えるでしょう。
次のステップとして、以下の記事も参考にしてください。