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

SLE (Space Link Extension) — 地上局とミッション運用センターをつなぐ標準インターフェース

地上局アンテナが受信したフレームは、どうやって数百〜数千km離れたミッション運用センターまで届くのか。RAF・RCF・FSP・CLTUという4つの代表的サービスと、生産ステータス通知によるリアルタイム性の担保という仕組みから、CCSDS SLEがRFハードウェアと運用ソフトウェアを疎結合にする標準インターフェースを数式と状態遷移で理解する。

前提知識: dsn

SLECCSDSクロスサポート地上局フレーム転送

この回で学ぶこと

これまでの回では、一貫して「探査機からのRF信号を、地上局のアンテナがどう受信し、どう復調・追尾・復号するか」という物理層の問題を扱ってきました。DSN概論の回で見たように、PLLが微弱な残留搬送波を追尾し、フレーム同期がビット列の海からフレームの先頭を掘り当て、誤り訂正符号がビット誤りを直す——こうして地上局の受信機の中では、最終的に構造化されたフレームの列が出来上がります。

しかし、ここで素朴な疑問が残ります。そのフレームは、いったいどこへ行くのでしょうか。 DSNのゴールドストーン局やESAのマドリード近郊の局は、実際に探査機を運用しているミッション運用センター(Mission Operations Center, MOC)——多くの場合、地上局から数百km、時には地球の反対側という遠隔地にあります——とは物理的に別の場所にあります。地上局のパラボラアンテナが受信したビットの列は、最終的にはこの遠隔地のMOCのソフトウェアに届いて初めて、科学者やエンジニアがデータとして扱えるようになります。

この「地上局とミッション運用センターの間」を橋渡しする標準化されたプロトコルが、この回のテーマである SLE (Space Link Extension) です。国際相互運用の回で、CCSDSの勧告群が物理層(401.0-B)から符号化層(131.0-B)まで階層的に整理されていることを見ましたが、SLEはその最上位、「地上局が受信したデータをネットワーク越しにMOCまで届ける」データ配送層を担う勧告群です。この回では、SLEがどんな設計思想のもとに作られ、どんな具体的なサービス(RAF・RCF・FSP・CLTU)を提供し、どうやって「今まさに届いているデータがリアルタイムなのか、それとも遅れているのか」を利用者に伝えているのかを見ていきます。

直感的導入: なぜ「地上局のソフトウェア」と「MOCのソフトウェア」を分離する必要があるのか

まず、SLEがなかったらどうなるかを想像してみましょう。

ある宇宙機関が新しい探査機を打ち上げるとき、地上局のRF受信機・復調器・フレーム同期器(まとめて「フロントエンド」あるいは「ベースバンド設備」と呼ばれます)と、MOCで動くミッション運用ソフトウェアの間に、あらかじめ決まった標準インターフェースが存在しなかったとします。すると、地上局とMOCを開発するチームは、その都度、両者の間でやり取りするデータのフォーマット・タイミング・エラー通知の方法などを個別に取り決め、専用のソフトウェアを書かなければなりません。これは国際相互運用の回で見た「相対型(bespoke)アプローチ」がここでも起きるということです。しかも今度の相手は探査機と地上局の組ではなく、地上局とMOCの組です。

さらに厄介なのは、DSN概論の回や国際相互運用の回で見たように、1つの探査機が複数の異なる機関の地上局に交互に(あるいは同時に)追跡される時代になっているという事実です。ESAの探査機がNASAのDSN局に一時的に追跡してもらう、あるいはNASAの探査機がESAのESTRACK局に助けてもらう——このとき、探査機側の変調方式やフレームフォーマットがCCSDS標準(PCM/PSK/PMや131.0-Bの符号化)に準拠していても、地上局からMOCへの「最後の配送区間」がその都度バラバラな独自プロトコルのままでは、クロスサポートは実現しません。 地上局のフロントエンドがどんなに標準的な方法でRF信号を復調できても、その先でMOC側のソフトウェアと会話できなければ、データはMOCまで届かないからです。

SLEが解決するのはまさにこの問題です。SLEは、地上局のRFハードウェア(アンテナ・受信機・フレーム同期器)と、MOCの運用ソフトウェアを、標準化されたネットワークインターフェースを介して疎結合(loosely coupled)にするという設計思想を採っています。地上局側は「SLEプロバイダ(Provider)」として、MOC側は「SLEユーザ(User)」として、あらかじめCCSDSで規定されたプロトコル(BIND・START・TRANSFER-DATAといった一連の操作)だけを介して会話します。地上局のハードウェアがどのメーカー製であろうと、MOCのソフトウェアがどの機関の独自システムであろうと、両者がSLEという同じ「言葉」を話せる限り、組み合わせは自由です。これが、国際相互運用の回で学んだクロスサポートという理念を、実際にビットのやり取りとして実現する技術的な裏付けになります。

定式化・整理その1: プロバイダとユーザの疎結合

SLEのアーキテクチャを形式的に整理すると、次の2つの役割に分かれます。

SLEプロバイダ (Provider): 地上局側の設備。アンテナ・受信機・復調器・フレーム同期器といったRFフロントエンドから得られるフレームの流れを、SLEのサービスとして外部に提供する。
SLEユーザ (User): MOC側のソフトウェア。ネットワーク越しにプロバイダに接続し、フレームを受け取ったり(リターンリンク方向)、コマンドデータを送り込んだり(フォワードリンク方向)する。

この両者の間の「契約」は、あらかじめCCSDSが定めた一連の**操作(operation)**の集合として規定されています。代表的なものは次の通りです。

BIND / UNBIND: ユーザとプロバイダの間に論理的な接続(アソシエーション)を確立・解放する。ログイン・ログアウトに相当します。
START / STOP: 実際のデータ転送を開始・終了する。多くの場合、特定の時刻範囲を指定して要求できます。
TRANSFER-DATA: プロバイダからユーザへ(あるいはユーザからプロバイダへ)、実際のフレームやパケットのデータを渡す操作。
STATUS-REPORT: プロバイダがユーザに、これまでに転送したフレーム数・エラー数などの統計情報を定期的に報告する。
NOTIFY: プロバイダがユーザに、非同期に発生したイベント(後述する生産ステータスの変化など)を知らせる。

重要なのは、この操作の集合がサービスの種類(RAF・RCF・FSP・CLTUなど)によらず共通の骨格を持つということです。つまりSLEは、個々のサービスごとにゼロから通信手順を設計するのではなく、共通の「BIND-START-TRANSFER-DATA-STOP-UNBIND」という骨格の上に、サービスごとに異なるデータの中身(フレーム全体なのか、特定のチャンネルのフレームだけなのか、コマンドパケットなのか)を載せ替える、という設計になっています。この共通化によって、ユーザ側のソフトウェアは、どのサービスを使うときも似た手順で実装できるという利点が生まれます。

定式化・整理その2: 代表的なSLEサービス — RAF・RCF・FSP・CLTU

SLEには方向性が2つあります。探査機から地球へ向かう**リターンリンク(return link)のデータを配送するサービスと、地球から探査機へ向かうフォワードリンク(forward link)**のデータを配送するサービスです。ここでは代表的な4つのサービスを見ます。

RAF (Return All Frames) — 全フレームをそのまま転送する

プロバイダ(地上局)が受信・復号したフレームの列を

F = \{f_1, f_2, \dots, f_n\}

とすると、RAFサービスは、この $F$ をフィルタをかけずにそのまま、時系列順にユーザへ転送します。フレームには受信品質を示す**フレーム品質(frame quality)**のタグ——GOOD(誤りなし)、ERRED(誤り検出符号で誤りが検出された)、UNDETERMINED(誤り検出手段がない)——が付与されて渡されるため、ユーザ側は「届いたフレームがそのまま信頼できるものか」を個々に判断できます。RAFは最もシンプルで、いわば「地上局が受信した生のフレーム流をそのまま右から左へ流す」サービスです。MOCの中で複数の探査機・複数のミッションフェーズのデータをまとめて記録・アーカイブしておきたい場合などに使われます。

RCF (Return Channel Frames) — 特定の仮想チャンネルだけを転送する

探査機は1本のRFリンクの上に、テレメトリ・科学データ・診断データなど複数の論理的なデータの流れを多重化して送ることがあります(この多重化の仕組み自体は、次回以降に扱う**仮想チャンネル(Virtual Channel)**という概念で実現されます)。各フレームには、どの仮想チャンネルに属するかを示す識別子 $\mathrm{vcid}(f)$ が埋め込まれています。

RCFサービスは、ユーザがあらかじめ関心のある仮想チャンネルの集合 $V \subseteq \{0,1,\dots,63\}$ (あるいは「全チャンネル対象」の指定)を指定すると、

F_V = \{\, f_i \in F \mid \mathrm{vcid}(f_i) \in V \,\}

というフィルタ済みの部分列だけを転送します。たとえば、ある探査機の科学観測チームは仮想チャンネル3番だけを、姿勢制御チームは仮想チャンネル1番だけを、それぞれ別々のRCFサービスインスタンスとして受け取る、という使い方が典型的です。RAFが「全部まとめて」なのに対し、RCFは「必要な部分だけを絞って」配送する、という補完的な関係にあります。

FSP (Forward Space Packet) — コマンドパケットを転送する

ここからはフォワードリンク方向のサービスです。FSPサービスでは、ユーザ(MOC)が、探査機に送りたいコマンドをCCSDS Space Packetという単位で作成し、それをプロバイダ(地上局)に渡します。プロバイダはそのパケットを受け取ると、フレーム化・誤り訂正符号の付与・CLTU(Command Link Transmission Unit、開始符号と終了符号で挟まれたコマンド無線送信の最小単位)の生成といった、下位層の処理をすべて自分で引き受けて、実際にRFとして送信します。ユーザ側は「送りたいパケットの中身」だけを意識すればよく、それをどうビットに変換して電波に乗せるかという詳細は地上局のプロバイダに委ねられる、という抽象度の高いインターフェースです。

CLTU (Forward CLTU) — 完成済みの送信単位をそのまま流す

一方、CLTUサービス(正式にはForward CLTU、FCLTUとも呼ばれます)では、ユーザ側があらかじめCLTU——BCH符号による誤り検出符号や開始・終了シーケンスまで含めて完成した、送信可能な最小単位のビット列——を自分で組み立てて、プロバイダに渡します。プロバイダは中身を解釈・加工せず、指定された**放射開始時刻(radiation start time)**にそのビット列をほぼそのままRFとして送信するだけです。

FSPとCLTUの違いは、「地上局にどこまでの処理を任せるか」という抽象度のトレードオフとして整理できます。FSPは扱いやすい反面、地上局側の処理(フレーム化やCLTU生成のタイミング)がブラックボックスになります。CLTUは自分で全ビットを組み立てる手間がかかる反面、探査機に電波が届く正確なタイミングや、ビット列そのものを完全に制御できるという利点があります。着陸(EDL, Entry-Descent-Landing)のような、コマンドの到達タイミングがミッションの成否を左右するクリティカルフェーズでは、この精密な制御性からCLTUサービスが好まれる場面があります。

(このほかにもリターン方向にはCLCW(Command Link Control Word、COP-1で扱う再送制御に使われる制御フィールド)だけを抜き出して配送するROCF(Return Operational Control Field)サービスなど、SLEにはいくつかの派生サービスがありますが、この回ではRAF・RCF・FSP・CLTUの4つを基本形として押さえておけば十分です。)

定式化・整理その3: サービスインスタンスと生産ステータス通知

1つの物理アンテナパスに、複数の論理接続

実運用では、1回のアンテナパス(探査機がある地上局から可視である一続きの時間帯)の間に、複数のSLEサービスインスタンスが同時に張られるのが普通です。たとえば、あるパスの間に次のような複数の論理接続が並行して存在することがあります。

アーカイブ用に全フレームを保存するRAFサービスインスタンス
科学データチームが仮想チャンネル3番だけを受け取るRCFサービスインスタンス
運用管制チームがコマンドを送り込むFSPサービスインスタンス

これらはすべて、同じ1つの物理的なRF受信チェーン(1つのアンテナ・1つの受信機)から得られる同じフレーム流を、論理的に分岐・フィルタして複数の独立した接続に配ることで実現されています。それぞれのサービスインスタンスは独立したBIND状態・START状態を持ち、あるユーザが接続を切っても他のユーザのサービスは影響を受けません。この「1つの物理設備、複数の論理接続」という関係は、アンテナアレイ合成の回で見た「複数のアンテナを1つの受信システムに束ねる」こととちょうど逆方向の多重化——1つの受信系を、複数の独立した論理サービスに分岐させる——だと捉えると理解しやすいでしょう。

生産ステータス通知によるリアルタイム性の担保

MOC側のソフトウェアにとって、「フレームが届いていない」という状況には、実は本質的に異なる2つの原因があり得ます。

探査機が単に送るべきデータを持っていない(あるいは仮想チャンネルにたまたまデータが来ていない)、つまり正常な無データ状態。
地上局側のRF受信チェーンに何らかの異常が起きている——PLLが搬送波ロックを失った、フレーム同期が同期パターンを見失った、アンテナが探査機の方向から外れた——という異常による無データ状態。

この2つを区別できなければ、MOCの運用者は「今、探査機は本当に元気なのか、それとも地上局側で何かが壊れているのか」を判断できません。SLEはこの区別を、生産ステータス(production status)という状態と、それが変化した際に送られるNOTIFY操作による非同期通知によって解決します。生産ステータスは、おおむね次の3状態で表されます。

\text{production status} \in \{\ \text{OPERATIONAL},\ \ \text{INTERRUPTED},\ \ \text{HALTED}\ \}

OPERATIONAL(稼働中): RF受信チェーンが正常に動作し、フレームが(存在すれば)正しく生産されている状態。
INTERRUPTED(中断): 搬送波ロックの喪失やフレーム同期の喪失など、一時的な異常でフレーム生産が止まっている状態。多くの場合、原因が解消されれば自動的にOPERATIONALへ復帰します。
HALTED(停止): パスの終了などにより、フレーム生産そのものが意図的・恒常的に止まっている状態。

プロバイダはこの状態が遷移するたびに、ユーザに対して即座にNOTIFY操作を送ります。これにより、たとえばPLLが搬送波ロックを失った瞬間、MOCのオペレータは「フレームが来なくなった」という間接的な兆候ではなく、「地上局のRF受信チェーンで異常が発生した」という明示的でほぼリアルタイムな通知を受け取れます。これが「生産ステータス通知によるリアルタイム性の担保」の意味です。

さらにSLEには、フレームの**配送モード(delivery mode)**という設計上の選択肢もあります。実運用では、地上局とMOCを結ぶ地上ネットワーク自体が一時的に混雑・途絶することもあり得るため、

online-timely: 定められた最大遅延の範囲内で届けられなかったフレームは破棄し、常に「今」に近いデータを低遅延で流し続けるモード
online-complete: 多少の遅延を許容してでも、フレームの欠落や順序の乱れがない完全な列を保証するモード
offline: パス終了後に、地上局側にバッファ・記録されたフレームをまとめて後から取得するモード

のいずれかを、サービスインスタンスごとに選択できます。DTNの回で扱った「探査機-地球間」の断続的な接続性の問題とは別に、地上局-MOC間の地上ネットワークにも、独自の遅延・輻輳・途絶のリスクがあることをSLEは前提としており、生産ステータス通知と配送モードの組み合わせによって、リアルタイム性と完全性のどちらを優先するかをサービス利用者が選べるように設計されています。

実務での使われ方

なぜESAの地上局がNASAのミッションデータを転送できるようになったか

国際相互運用の回で、ESAのロゼッタ探査機のフィラエ着陸支援にDSNの局が加わった例や、NASAの主要ミッションが混雑する時期にESTRACKやJAXAの局が追跡を代行する例を見ました。これらのクロスサポートが技術的に成立する最後の一段——「支援側の地上局が受信したフレームを、支援を受ける側の機関のMOCまでどうやって届けるか」——を担っているのがSLEです。

たとえばESAのESTRACK局がNASAの探査機を一時的に支援するとき、ESTRACK局のフロントエンドがSLEプロバイダとして立ち上がり、地球の反対側にあるNASA/JPLのMOC(SLEユーザ)が、通常の地上ネットワーク(インターネットVPNや専用線)を介してそのSLEプロバイダにBINDし、RAFサービスでフレームを受け取ります。ESTRACK局のハードウェアやソフトウェアの内部実装がDSN局と全く異なっていても、SLEという共通インターフェースの向こう側でBIND・START・TRANSFER-DATAという同じ手順を踏める限り、MOC側はまるで自国の地上局からデータを受け取っているのと同じようにフレームを扱えます。これがCCSDS標準化の実利であり、国際相互運用の回で論じた「標準化によって相互運用協定のコストを機関数の2乗のオーダーから線形のオーダーに縮小する」という議論の、最も具体的な実装例の1つです。

商用地上局ネットワークとクラウド化

近年は各国宇宙機関の地上局だけでなく、KSAT(Kongsberg Satellite Services)、SSC(Swedish Space Corporation)、Atlas Space Operations、Leaf Spaceといった商用の地上局ネットワーク事業者が、世界中に分散配置したアンテナを複数のミッション運用者に時間貸しするサービスを展開しています。これらの事業者の多くは、自社の地上局とSLEインターフェースで直接つなげることを主要な特長として謳っています。ミッション運用者は、地上局のハードウェアの詳細を一切気にすることなく、自分たちのMOCソフトウェアがSLEユーザとして振る舞いさえすれば、世界中のどの対応地上局とも即座にデータをやり取りできるからです。SLEがなければ、商用地上局事業者は顧客ごとに個別のインターフェース開発を強いられ、このようなビジネスモデル自体が成立しにくかったといえます。

ミッション運用センターのネットワーク構成

実際のMOCのネットワーク構成では、SLEユーザとして機能するソフトウェア(ESAのSCOS-2000、NASA/JPLのAMMOSに代表されるようなミッション運用システムの一部)が、地上局側のSLEプロバイダと1本以上のTCP/IPコネクションを常時、あるいはパスのたびに確立します。地上局側のプロバイダとMOC側のユーザの間の物理的な経路は、地上局のRFフロントエンドから見ればもはや「電波」ではなく「地上のデータネットワーク」であり、そこでの遅延は数十〜数百ミリ秒程度と、探査機-地球間の光速による伝搬遅延(火星でも片道十分以上、DTNの回参照)に比べれば無視できるほど小さいのが通常です。つまりSLEが扱う遅延・信頼性の課題は、DTNが扱う「光速の壁」とは性質の異なる、地上ネットワーク特有の(とはいえ運用上は決して軽視できない)問題だといえます。

演習問題

あるパスの間に、RAFサービスインスタンスとRCF(仮想チャンネル3番のみ)サービスインスタンスが同時に張られているとする。このパスで受信されたフレーム列が $F=\{f_1,\dots,f_{100}\}$ で、そのうち仮想チャンネル3番に属するフレームが20個だったとき、RAFサービスとRCFサービスがそれぞれユーザに転送するフレームの個数を答え、この2つのサービスインスタンスが「同じ物理的な受信チェーンを共有しながら独立して動作できる」理由を、本文中の $F_V$ の定義を使って説明してください。
なぜMOCのソフトウェアにとって、「フレームが来ない」ことと「生産ステータスがINTERRUPTEDである」ことを区別できる必要があるのか、具体例(PLLの搬送波ロック喪失、あるいは単に探査機がその時間帯にデータを送っていない場合)を挙げて説明してください。
FSPサービスとCLTUサービスは、どちらも地球から探査機へコマンドを送るためのフォワードリンクのサービスですが、抽象度と制御性においてトレードオフの関係にあります。着陸(EDL)のようなクリティカルフェーズでCLTUサービスが好まれる可能性がある理由を、本文の議論をもとに自分の言葉で説明してください。
国際相互運用の回で学んだ「標準化アプローチによって相互運用協定のコストが機関数の2乗のオーダーから線形のオーダーに縮小する」という議論を踏まえ、SLEが標準化されていなかった場合、地上局とMOCの組み合わせの数に対して、どのようなコストの増大が起きると考えられるか論じてください。

まとめと次回予告

この回では、これまで「探査機からのRF信号を地上局アンテナが受信する」ところまでで止まっていた視点を一歩先に進め、受信されたフレームが物理的な地上局から遠隔地のミッション運用センターまでどう届けられるかを扱いました。SLEは、地上局のRFハードウェアとMOCの運用ソフトウェアを、BIND-START-TRANSFER-DATA-STOP-UNBINDという共通の骨格を持つ標準インターフェースで疎結合にし、RAF(全フレーム転送)・RCF(特定仮想チャンネルの転送)・FSP(コマンドパケット転送)・CLTU(完成済み送信単位の転送)という代表的なサービスによって、リターンリンク・フォワードリンク双方のデータ配送を実現しています。また、1つの物理アンテナパスに複数の論理的なサービスインスタンスが同時に張られること、そして生産ステータス通知によって「データが来ない」ことの原因(正常な無データか、RF受信チェーンの異常か)を利用者が即座に区別できる仕組みも見ました。これは、国際相互運用の回で学んだクロスサポートという理念を、実際のビット転送として具体化する技術的な要となる規格です。

次回は、SLEがRCFサービスで「特定のチャンネルだけを転送する」ために利用していた**仮想チャンネル(Virtual Channel)**という概念そのものに焦点を当て、探査機からのフレームがどのようにして1本のRFリンクの上で複数のデータ種別に多重化されているのかという、宇宙データリンクプロトコルの中身を見ていきます。

参考文献

CCSDS, Cross Support Reference Model—Part 1: Space Link Extension (SLE) Services, CCSDS 910.4-B
CCSDS, Space Link Extension—Return All Frames Service Specification, CCSDS 911.1-B
CCSDS, Space Link Extension—Return Channel Frames Service Specification, CCSDS 911.2-B
CCSDS, Space Link Extension—Forward CLTU Service Specification, CCSDS 912.1-B
CCSDS, Space Link Extension—Forward Space Packet Service Specification, CCSDS 912.3-B
CCSDS, Overview of Space Communications Protocols, CCSDS 130.0-G (Green Book)
DSN Telecommunications Link Design Handbook, DSN No. 810-005
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76