AOS宇宙データリンクプロトコル — ISSのための高速・多チャンネル拡張

この回で学ぶこと

前々回、探査機から流れてくるビット列をフレームという固定長の単位に区切り、仮想チャネル(Virtual Channel, VC)によって複数のデータ種別を1本のRFリンクの上で多重化するTM宇宙データリンクプロトコル(CCSDS 132.0-B)を学びました。TMは、ボイジャーからはやぶさまで、多くの深宇宙探査機のテレメトリダウンリンクを支えてきた、実績豊富で単純明快な設計です。しかしTMは元々、「1機の探査機が、比較的少数のデータストリームを、比較的低〜中程度のレートで、淡々と地球に送り続ける」という状況を暗黙の前提に設計されています。

この前提が根本から崩れる場面があります。**国際宇宙ステーション(ISS)**です。ISSは単一の探査機ではなく、アメリカ・ロシア・欧州・日本・カナダが運用する複数のモジュールが結合した、事実上の「複合プラットフォーム」です。そこでは工学テレメトリだけでなく、船外活動(EVA)や実験棟から流れる科学データ、ロボットアーム(Canadarm2など)の制御・状態データ、乗員との音声・映像通信、さらには来訪する補給船・有人宇宙船とのやり取りまでが、同時並行で発生します。これらを束ねて地上に送るには、TMが想定していたよりもずっと多くの独立したデータの流れを、ずっと高いレートで、しかも多様な形式のまま扱える通信プロトコルが必要でした。

そのために設計されたのが AOS (Advanced Orbiting Systems) 宇宙データリンクプロトコル、CCSDS 732.0-B AOS Space Data Link Protocol です。この回では、AOSがTMの何を引き継ぎ、何を拡張したのかを、(1) サポートするデータユニット種別、(2) 仮想チャネル構成の柔軟性、(3) Insert Zoneという低遅延データ専用領域、(4) フレーム構造そのものの違い、という4つの軸から見ていきます。VC・MC(Master Channel)による多重化という基本概念そのものは前々回すでに学んでいるので、ここでは再導出せず、AOSがその上に何を積み増したのかに焦点を絞ります。

直感的導入: 「単一車線の道路」から「多車線の物流ハブ」へ

TMプロトコルを道路にたとえるなら、車種がほぼ統一された単一車線の道路です。荷物(データ)はほとんどがCCSDSスペースパケットという規格化されたコンテナに詰められ、1本の車線を順番に流れていきます。車線(仮想チャネル)は最大8本まで用意できますが、探査機1機の通信要求としてはそれで十分でした。

ISSのような複合プラットフォームが必要としているのは、これとはスケールも性質も異なる多車線の物流ハブです。パケット化されたデータだけでなく、パケットの形にうまく収まらない連続的なビット列(たとえばアナログ的な性質を持つセンサーデータや、独自フォーマットの動画・音声ストリーム)も流れてきます。同時に稼働するデータの流れの本数もはるかに多く、ある種の緊急度の高い小さな荷物(たとえば精密な時刻情報や、即座に読み取ってほしい状態フラグ)は、一般の車線に並ばせず「専用の速達レーン」で運びたいという要求もあります。

AOSは、TMの基本構造(フレーム分割・仮想チャネル多重化)を土台にしながら、この物流ハブの要求に応えるために、車線の本数を増やし、車種の種類を増やし、速達レーンを新設した拡張版のプロトコルだと捉えると理解しやすくなります。以下、この直感を規格の中身に沿って具体化していきます。

定式化1: AOSがサポートするデータユニット種別

TMのデータフィールドは基本的に、複数のCCSDSスペースパケットを連結して詰め込む**M_PDU (Multiplexing Protocol Data Unit)**という1種類の形式に事実上限定されていました。AOSはこれに加えて、仮想チャネルごとに次のようなデータユニット種別を選択できます。

サービス種別	データユニット	内容
パケットサービス	M_PDU	TMと同じく、CCSDSスペースパケットを連結して詰め込む。パケット境界をまたぐ場合に備えた「先頭ヘッダポインタ」を持つ点もTMと共通。
ビットストリームサービス	B_PDU	パケット構造を持たない、連続的な生のビット列をそのまま運ぶ。有効ビット数を示すフィールドを持ち、フレーム境界とデータの論理的な境界が一致しなくてもよい。
仮想チャネルアクセスサービス	VCA_SDU	フレームのデータフィールド全体を、CCSDSが一切解釈しない「不透明な」1個のデータ単位として運ぶ。中身の形式は完全にミッション側(利用者)が自由に定義できる。
アイドルデータ	—	送るべき実データが無いときに、固定長フレームを埋めるための詰め物。TMと同じ役割。

この中で実務上とくに重要なのがビットストリームサービスとVCAサービスです。TMがパケットサービス一本に絞っていたのは、探査機のテレメトリのほとんどがCCSDSスペースパケットという規格化された単位で表現できるという前提があったからです。しかしISSでは、独自フォーマットの映像コーデック出力や、レガシーな計測器のデータ形式など、CCSDSパケットの枠に無理に押し込めるよりも生のビット列やブロックとしてそのまま運んだ方が効率的なデータが数多く存在します。AOSがこれらの受け皿としてB_PDUとVCA_SDUを用意していることが、「多様なデータタイプへの対応」というAOS設計の核心の1つです。

定式化2: 仮想チャネル構成の柔軟性 — アドレス空間とフレームカウンタ

TMとAOSのプライマリヘッダを比べると、仮想チャネルまわりの設計思想の違いがはっきり数字に現れます。

フィールド	TM (CCSDS 132.0-B)	AOS (CCSDS 732.0-B)
バージョン番号	2 bit (00)	2 bit (01)
探査機ID (SCID)	10 bit	8 bit
仮想チャネルID (VCID)	3 bit → 最大8本	6 bit → 最大64本
フレームカウンタ	マスターチャネル用8 bit + 仮想チャネル用8 bit(各mod-256)	仮想チャネルフレームカウント 24 bit(mod-16,777,216)

まず目を引くのがVCIDのビット数です。TMの3 bitでは仮想チャネルは最大8本までしか区別できません。単一の探査機であれば、工学テレメトリ・複数の観測機器・時にリアルタイムイベントデータ程度の使い分けで十分であり、8本という上限が問題になることはほとんどありません。しかしISSのように、独立して稼働する実験ラック・システムサブモジュール・映像系統・ロボティクス系統などが同時多発的にデータを生成するプラットフォームでは、8本という制約はすぐに窮屈になります。AOSがVCIDを6 bitに拡張し、1つのマスターチャネル(=1つのSCIDが表す送信元)あたり最大64本の仮想チャネルを持てるようにしたのは、この「同時に管理すべき独立したデータストリームの数」がTM想定より一桁近く多いという、ISSならではの要求への直接的な対応です。

次にフレームカウンタです。なぜAOSはこれをTMの8 bit ×2から24 bitの単一カウンタへと大幅に拡張したのでしょうか。これは高速リンクにおける実務上の問題を数字で確認すると理解しやすくなります。

仮にフレーム長を1024バイト(8192 bit)、ダウンリンクのビットレートを50 Mbpsとすると、1秒間に送出できるフレーム数は

$$f_{\text{frame}} = \frac{R_b}{L_{\text{frame}}} = \frac{50\times10^6\ \text{bit/s}}{8192\ \text{bit}} \approx 6103\ \text{フレーム/秒}$$

このレートでTM流の8 bitフレームカウンタ(0〜255、256通りで一周)を使うと、カウンタが一周するまでの時間は

$$T_{\text{wrap,TM}} = \frac{256}{f_{\text{frame}}} \approx \frac{256}{6103} \approx 42\ \text{ミリ秒}$$

わずか42ミリ秒ごとにカウンタが0に戻ってしまいます。地上局がフレームの欠落を検知するのは基本的に「フレームカウンタが連続していない(1つ以上飛んでいる)」ことを見つける作業ですが、カウンタの一周が42ミリ秒しかなければ、地上局側の受信処理がわずかに遅延しただけで「本当の欠落」なのか「カウンタが一周しただけ」なのかの判別が困難になり、フレーム損失統計の信頼性が損なわれます。

これに対してAOSの24 bitカウンタ(0〜16,777,215、約1678万通り)であれば、

$$T_{\text{wrap,AOS}} = \frac{16777216}{f_{\text{frame}}} \approx \frac{16777216}{6103} \approx 2749\ \text{秒} \approx 45.8\ \text{分}$$

一周するのに45分以上かかります。これなら、地上局の処理遅延や一時的な受信断があっても、フレームカウンタの連続性チェックが「一周による誤判定」に足を取られる心配はほとんどなく、長時間・高レートの連続運用にも耐えられます。AOSが24 bitという大きなカウンタ空間を採用しているのは、まさにISSのような高レート・長時間運用のプラットフォームを見据えた設計判断です。

定式化3: Insert Zone — 低遅延データのための専用領域

AOSがTMに対して持つもう1つの大きな拡張が Insert Zone(挿入ゾーン) です。これはTMのフレーム構造には存在しない、AOS独自のオプション領域です。

通常、仮想チャネルのデータフィールドに詰められたデータ(たとえばM_PDUに載ったパケット群)は、パケットがフレーム境界をまたいで分割されることがあるため、地上局側で複数フレームにまたがる再組み立て(リアセンブリ)を経てはじめて元のデータ単位として取り出せます。これは仕組み上避けられない、ある程度の処理遅延を伴います。

しかし、ミッションによっては「多少の遅延は許容できないが、データ量はごく小さい」という種類の情報があります。たとえば高精度な基準時刻情報、緊急性の高い状態フラグ、あるいは一定周期でジッタなく届いてほしいアイソクロナスな制御データなどです。こうしたデータのために、AOSはプライマリヘッダの直後(データフィールドより前)に、固定長・固定位置のInsert Zoneを配置できるようにしています。

Insert Zoneの中身は、通常の仮想チャネル多重化・パケット再組み立てのパイプラインを一切経由しません。フレームが届いた瞬間に、あらかじめ決められた固定オフセットから直接読み出すことができます。つまり、

• 通常のデータフィールド経由の配送: 仮想チャネルの多重化・(必要なら)複数フレームにまたがるパケット再組み立てを経てから利用可能になる。データ量やパケット境界の位置によって、取り出しまでの遅延にある程度のばらつき(ジッタ)が生じうる。
• Insert Zone経由の配送: フレームを受信した時点で、多重化状態や他のVCの混雑状況によらず、常に一定の固定オフセットから即座に取り出せる。

という違いがあります。Insert Zoneは容量こそ小さいものの、**「フレーム周期に縛られた、ジッタの小さい配送」**を保証できる点で、通常のVCデータフィールドとは質的に異なる役割を担っています。多数のサブシステムが同時にデータを生成し、VCごとの混雑状況が刻々と変わりうるISSのような複雑なプラットフォームでは、この「多重化の影響を受けない専用の低遅延経路」を持てることが、時刻同期や緊急状態通知といった用途で実務上大きな価値を持ちます。

定式化4: AOSフレーム全体の構造とTMとの比較

以上の拡張を踏まえて、AOSトランスファーフレームの全体構造をTMと並べて整理します。

AOSトランスファーフレームの構成(概要)

フィールド	長さ(目安)	有無
プライマリヘッダ(バージョン・SCID・VCID・VCフレームカウント・シグナリングフィールド)	6オクテット	必須
フレームヘッダ誤り制御(ヘッダ部分のみを保護するCRC)	2オクテット	オプション
Insert Zone	ミッションごとに固定長で設定	オプション(AOS独自)
データフィールド(M_PDU / B_PDU / VCA_SDU / アイドルデータ)	可変(フレーム全体長から他のフィールドを引いた残り)	必須
オペレーショナル制御フィールド(CLCWなどを運ぶ)	4オクテット	オプション
フレーム誤り制御(フレーム全体を保護するCRC)	2オクテット	オプション

この表とTMのフレーム構造を比べると、骨格(プライマリヘッダ+データフィールド+オプションの誤り制御フィールド群)はTMとほぼ相似形であることが分かります。AOSはTMを置き換える別物ではなく、同じ設計思想の上に、(1) より大きな仮想チャネル・フレームカウンタのアドレス空間、(2) パケット以外のデータユニット種別、(3) Insert Zoneという低遅延専用領域、を追加した拡張版だと理解するのが正確です。オペレーショナル制御フィールドがCLCW(COP-1の回で扱った、アップリンクの受理状況を伝える32ビットの制御ワード)を運ぶ役割を担う点や、フレーム全体をCRCで保護する仕組みも、TMから引き継がれた共通の設計です。

実務での使われ方

ISSでの実際のAOS運用

ISSの通信システムは、S帯とKu帯という複数の周波数帯を、TDRSS(Tracking and Data Relay Satellite System、NASAの中継衛星網)経由で使い分けています。S帯は主にコマンド・工学テレメトリなど比較的低〜中レートで確実性が重視されるデータに、Ku帯は科学データ・映像・大容量ファイル転送など高レートのデータに使われます。これら異なる速度・異なる発生元を持つ多数のデータストリームを、それぞれ独立した仮想チャネルに割り当てて多重化するために、AOSのVCID空間の広さ(最大64本)が実務上そのまま活きています。

ISSのKu帯ダウンリンクは、システム構成の変遷とともに向上してきましたが、おおむね数十Mbpsから、近年の改修後には百数十Mbpsのオーダーに達しており、これは伝統的な深宇宙探査機のダウンリンク(多くの場合数kbps〜数Mbpsのオーダー)と比べて桁違いに高いレートです。このレートで長時間・多チャンネルの運用を続けるからこそ、前節で確認したような24 bitフレームカウンタの余裕が実用上の意味を持ちます。

新規ミッション設計におけるTM/AOSの選択基準

新しい探査機・プラットフォームを設計する際、TMとAOSのどちらを採用するかは、次のような観点で判断されます。

判断基準	TMが向いているケース	AOSが向いているケース
プラットフォームの複雑さ	単一の探査機、比較的少数の観測機器	複数モジュール・複数国が関わる複合プラットフォーム
同時多重化すべき独立ストリーム数	8本以内で十分収まる	8本を超える、あるいは将来的に増える見込みがある
データの形式	ほぼ全てCCSDSスペースパケットで表現できる	パケット化しにくい連続データ・独自形式データがある
データレート・運用時間	中〜低レート、フレームカウンタの一周が実務上問題にならない	高レートかつ長時間の連続運用で、短いカウンタ周期が問題になりうる
低遅延・低ジッタ配送の必要性	特になし	精密時刻・緊急状態通知など専用の低遅延経路が必要
実績・実装コストの単純さ	長い実績があり検証済みの単純な設計を優先したい	複雑さの増加を許容してでも柔軟性・拡張性を優先したい

要するに、単純な深宇宙探査機であれば、実績豊富で単純明快なTMで十分であり、あえてAOSの複雑さを持ち込む理由はほとんどありません。実際、多くの惑星探査機・小天体探査機は現在もTMベースの通信システムを使い続けています。一方で、ISSのように、有人・多国間・多システムが絡み合い、高速かつ多様な種類のデータを同時に扱う必要のあるプラットフォームでは、AOSの持つ拡張性(広い仮想チャネル空間、多様なデータユニット種別、Insert Zoneによる低遅延配送)がその複雑さに見合う価値を持ちます。この判断基準は、将来の有人月面拠点や大型商業宇宙ステーションのような、同種の複雑さを持つプラットフォームを設計する際にも踏襲されると考えられます。

演習問題

1. フレーム長 2048バイト、ダウンリンクレート 20 Mbpsのリンクを考える。(a) 1秒あたりのフレーム数 $f_{\text{frame}}$ を求めよ。(b) TM流の8 bitフレームカウンタと、AOSの24 bitフレームカウンタそれぞれについて、カウンタが一周するまでの時間を求め、両者が何桁違うか述べよ。

2. TMのVCIDが3 bit(最大8本)であるのに対し、AOSのVCIDは6 bit(最大64本)である。単一の深宇宙探査機のミッションでは3 bitで十分な理由と、ISSのような複合プラットフォームで6 bitが必要になる理由を、それぞれ本文の議論を踏まえて説明せよ。

3. Insert Zoneに載せるのに適したデータの例と、適さないデータの例をそれぞれ1つずつ挙げ、その理由を「通常のVCデータフィールド経由の配送との遅延・ジッタの違い」という観点から説明せよ。

4. ある新規ミッションとして、月面に複数の実験モジュールと居住モジュールが結合した小型有人拠点を想定する。この拠点の通信システム設計者として、TMとAOSのどちらを採用すべきかを、本文で挙げた判断基準のうち少なくとも2つを引用しながら論じよ。

まとめと次回予告

AOSは、TMプロトコルの「フレーム分割+仮想チャネル多重化」という基本設計を土台にしながら、(1) パケット以外の多様なデータユニット種別(B_PDU、VCA_SDU)、(2) 6 bit VCIDによる最大64本の仮想チャネルと24 bitフレームカウンタという拡張されたアドレス空間、(3) 通常の多重化パイプラインを経由しない低遅延専用領域Insert Zone、という3つの拡張を備えたプロトコルでした。これらはいずれも、単一の探査機を想定したTMでは想定しきれなかった、ISSのような有人・多国間・多システムのプラットフォーム特有の要求——同時多発的な多様なデータの流れ、高レート・長時間の連続運用、一部データの低遅延配送——に応えるための設計です。新規ミッションを設計する際は、プラットフォームの複雑さとデータの多様性を見極め、単純な探査機であればTM、複雑な複合プラットフォームであればAOSという判断基準で選択されることを見ました。

次回は、視点を大きく変えて、ローバーと周回機の間のような数百km・数ミリ秒規模の近接リンクを扱う Proximity-1宇宙リンクプロトコル に触れます。TMやAOSが数億km・数分〜数十分という深宇宙の伝搬遅延を前提に「独白型」の設計を選んできたのに対し、Proximity-1は遅延の桁がまるごと変わることで初めて可能になる「対話型」の通信という、まったく異なる設計思想に基づいています。

参考文献

• CCSDS 732.0-B, AOS Space Data Link Protocol, Blue Book
• CCSDS 132.0-B, TM Space Data Link Protocol, Blue Book
• CCSDS 131.0-B, TM Synchronization and Channel Coding, Blue Book
• 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