SpaceLesson

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

プロトコル階層設計思想 — OSI参照モデル対CCSDS独自層構造

SpacePacket、TM/TCフレーム、SLE、CFDPと個別に学んできたCCSDSプロトコル群を、いったん俯瞰する回。地上ネットワークの標準であるOSI 7層モデルを整理し、CCSDSがなぜそれをそのまま採用せず、深宇宙リンクの帯域・遅延・電力制約に最適化された独自の層構造を選んだのかを、これまでのレッスンを横断しながら考える。

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

CCSDSOSI参照モデルプロトコル設計階層化アーキテクチャ

この回で学ぶこと

Space Packetから始まり、TM/TCトランスファーフレームと仮想チャンネル、COP-1、CFDP、SLE、SCPS、DTN——これまで100を超えるレッスンを重ねる中で、私たちはCCSDS(Consultative Committee for Space Data Systems)が定める個々のプロトコルを、1つずつ丁寧に、ヘッダのビット幅からアルゴリズムの数式まで掘り下げて学んできました。個々のプロトコルの中身はすでに手元にあります。この回でやることは新しいプロトコルを1つ追加することではなく、いったん引いた視点に立ち、これらすべてが「なぜこのように積み重なっているのか」という設計思想そのものを俯瞰することです。

地上のネットワーク技術を学んだことがある人なら、必ず一度はOSI参照モデルという7層の枠組みに出会っているはずです。物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層という積み木を、教科書やネットワーク技術者試験で叩き込まれた記憶がある人も多いでしょう。ところがCCSDSのプロトコルスタックを実際に眺めてみると、この7層にきれいに対応する構造にはなっていません。Space Packetの回でも「CCSDSのプロトコル階層は、地上のOSI参照モデルと完全には対応しません」と一言だけ触れて先へ進みましたが、この回では、その「なぜ対応しないのか」を正面から掘り下げます。

OSIモデルという地上の参照枠組みを簡潔に復習したうえで、CCSDSの各プロトコルをその7層に無理やり当てはめてみて、どこがきれいに対応し、どこがはみ出すのかを具体的に整理します。そのうえで、CCSDSがOSIをそのまま採用しなかった根本的な理由——OSIモデルが暗黙に前提とする地上ネットワークの環境条件が、深宇宙リンクではことごとく成り立たないという、これまでDTNやSCPS、電力制約とリンク設計のトレードオフの回で繰り返し登場してきたテーマ——を統合的に結びつけます。最後に、「層の分離」という設計原則そのものがCCSDS標準の進化にどう貢献しているかを、実務の観点から見ていきます。

直感的導入: なぜ「層に分ける」のか、そもそもの動機

具体的な層構造の話に入る前に、そもそもなぜ通信システムを「層」に分けて設計するのか、その動機を確認しておきましょう。

1本の探査機との通信を実現するには、たとえば次のような、性質のまったく異なる仕事を同時にこなす必要があります。

  • 電波の位相をどう揺らしてビットを乗せるか(PCM/PSK/PMのような変調)
  • 雑音まみれのビット列から、どこがフレームの先頭かを見つけ出すか(フレーム同期)
  • ビット誤りをどう検出・訂正するか(Reed-Solomon符号、畳み込み符号、LDPC)
  • 複数の観測機器のデータをどう1本のリンクに多重化するか(SpacePacketのAPID、仮想チャンネル)
  • 失われたデータをどう検知し、再送するか(COP-1)
  • 大きなファイルを、途切れがちな回線越しにどう1バイトも欠けずに届けるか(CFDP)

これらすべてを1つの巨大な仕様書に一緒くたに書いてしまうと、たとえば「変調方式を新しくしたい」という変更が、遠く離れた「ファイル転送の再送ロジック」の仕様まで書き直させてしまう、という事態が起こりえます。これでは標準の保守も、実装の検証も、機関をまたいだ相互運用性の確保も、破綻してしまいます。

そこで通信システムの設計では、仕事を性質ごとに「層(レイヤー)」に切り分け、各層は自分のすぐ下の層が提供する機能だけを信頼して使い、その内部実装がどう変わっても、自分の層のインターフェース(上下の層とのやり取りの約束事)さえ変わらなければ影響を受けない、という原則を置くのが定石です。この「層の独立性」こそが、この回全体を貫く中心テーマです。OSIモデルとCCSDSプロトコルスタックは、この同じ動機——複雑な仕事を独立に設計・進化させられる単位に切り分けたい——から出発しながら、環境条件の違いによってまったく異なる切り分け方にたどり着いた、という関係にあります。

OSI参照モデルの復習: 地上ネットワークの7層

OSI(Open Systems Interconnection)参照モデルは、1970年代末から1980年代にかけてISO(国際標準化機構)が策定した、ネットワーク通信を7つの層に分割する参照枠組みです。実際のインターネットが使うTCP/IPスイートは厳密にはこの7層と一対一対応しているわけではありませんが、「通信を層に分けて考える」という思考の型としては今も広く教えられ、使われています。7層を下から順に並べると、次のようになります。

層名称主な役割地上での代表例
第1層物理層 (Physical Layer)ビットを電気信号・光信号・電波に変換するイーサネットのケーブル信号、Wi-Fiの無線信号
第2層データリンク層 (Data Link Layer)隣接ノード間での、フレーム単位の伝送と誤り検出イーサネットフレーム、MACアドレス
第3層ネットワーク層 (Network Layer)複数のノードをまたぐ経路選択(ルーティング)とアドレッシングIP、ルータ
第4層トランスポート層 (Transport Layer)送信元-宛先間のエンドツーエンドの信頼性、順序保証、輻輳制御TCP、UDP
第5層セッション層 (Session Layer)通信セッションの確立・維持・終了の管理RPC、NetBIOSセッション
第6層プレゼンテーション層 (Presentation Layer)データ形式の変換(文字コード、暗号化、圧縮)TLS(の一部)、データエンコーディング
第7層アプリケーション層 (Application Layer)利用者が直接触れる通信サービスそのものHTTP、FTP、SMTP

このモデルの根底にある発想は、**「下の層は、上の層に対してどんどん高機能で抽象的なサービスを提供していく」**という一方向の積み上げです。物理層は「ビットを送れる」だけのサービスを、データリンク層はその上に「隣接ノードまでフレームを届けられる」サービスを、ネットワーク層はさらにその上に「任意の遠方のノードまで経路を選んで届けられる」サービスを、というように、各層が1つ下の層のサービスだけを使って、1つ上の層に新しい能力を提供します。ある層の実装(たとえば物理層のケーブルを光ファイバーから無線に変える)を差し替えても、その上の層(データリンク層以上)は変更を意識する必要がない——これがOSIモデルが目指した「層の独立性」の理想形です。

重要なのは、この7層という切り分け方そのものが、設計者の恣意的な選択ではなく、地上の有線・無線ネットワークが実際に直面する技術的な関心事の集合から逆算されたものだという点です。次節で見るように、この関心事の集合こそが、CCSDSの世界とは大きく異なります。

CCSDSプロトコルスタックをOSIに当てはめてみる

それでは、これまでのレッスンで学んできたCCSDSプロトコル群を、OSIの7層に対応させてみましょう。結論を先取りすると、きれいに当てはまる層と、まったく当てはまらない層が混在します。

OSI層CCSDSでの対応物対応の程度
物理層PCM/PSK/PMなどのRF変調方式、畳み込み符号・LDPC・ターボ符号などのチャネル符号化ほぼ対応
データリンク層TM/TCトランスファーフレーム、仮想チャンネル/マスターチャンネル、COP-1おおむね対応
ネットワーク層SpacePacket、SCPS-NP部分的にしか対応しない
トランスポート層SCPS-TP、CFDPの一部機能プロトコルによって対応度がばらつく
セッション層SLE (Space Link Extension)のサービスインスタンス管理かろうじて対応
プレゼンテーション層(該当なし。データ形式変換は上位のミッション運用系のPUS等に委ねられる)対応せず
アプリケーション層CFDPのファイル転送機能、各種ミッション運用サービス部分的に対応

表を上から順に見ていくと、物理層とデータリンク層はOSIとかなり素直に対応します。 PCM/PSK/PMや各種の誤り訂正符号が「ビットを電波に変換し、誤りに耐えさせる」というOSI物理層の仕事そのものですし、TM/TCトランスファーフレームが「隣接ノード(探査機と地上局)間でフレーム単位の伝送を行い、フレームレベルの誤り検出を行う」というOSIデータリンク層の仕事とほぼ重なります。仮想チャンネル・マスターチャンネルによる多重化も、データリンク層の中で完結する機能です。

問題はネットワーク層から上です。SpacePacketの回で確認した通り、SpacePacketのAPID(Application Process Identifier)は「送信元のアプリケーションプロセスを識別する」タグであり、OSIのネットワーク層が本来担うはずの**マルチホップの経路選択(ルーティング)**という機能をSpacePacket自体は持っていません。1機の探査機から1つの地上局へという、実質的に単一のリンク(ポイントツーポイント)を前提とした設計だからです。つまりSpacePacketは、ネットワーク層に「見た目は似ている」位置に置かれてはいますが、その中身はむしろデータリンク層の延長に近い、識別子ベースの多重化にとどまっています。

一方、複数ノードを経由するルーティングが本当に必要になる場面——中継アーキテクチャで見た周回機経由の中継や、DTNが扱う惑星間の多ホップネットワーク——では、SpacePacketだけでは足りず、SCPS-NPやDTNのBundle Protocolといった、より上位に置かれた別のプロトコルがルーティングの役割を担います。つまりCCSDSの世界では、「ネットワーク層の仕事」が単一のプロトコルに集約されておらず、複数のプロトコルに分散しているのです。これがOSIとの対応がきれいにいかない最初のポイントです。

トランスポート層・セッション層・プレゼンテーション層についても事情は同様です。SCPS-TPはTCPの宇宙適応版としてトランスポート層の仕事(信頼性のあるエンドツーエンド転送、輻輳制御)を担いますが、CFDPはファイルという単位での信頼性転送を、トランスポート層とアプリケーション層の機能を併せ持つ形で1つのプロトコルの中に実装しています。CFDPは「ファイルを1つのまとまりとして、途切れがちな回線越しに確実に届ける」という仕事の中に、再送制御(本来はトランスポート層的な仕事)とファイル操作(本来はアプリケーション層的な仕事)を両方詰め込んでおり、OSIの層分けの発想からすると「越境」した設計になっています。さらにSLEは、探査機と地上局の間ではなく、地上局とミッション運用センターの間という、OSIモデルが想定する「送信元から宛先までのエンドツーエンド通信」とはやや異なる区間を対象にした、地上系のサービスインスタンス管理の仕組みです。プレゼンテーション層に至っては、CCSDSプロトコルスタックの中に明確な対応物がほとんど存在しません(データ形式の意味づけは、Space Packetの二次ヘッダの回で触れたPUSのような、さらに上位のミッション運用標準に委ねられています)。

なぜCCSDSはOSIをそのまま採用しなかったのか

ここまでの対応表を見ると、CCSDSは「OSIを知らなかった」わけでも「OSIより劣る設計をした」わけでもないことが分かります。CCSDSの標準化活動は1980年代以降、OSIモデルの存在を十分意識しながら進められてきました。それでもなお、CCSDSがOSIの7層をそのまま踏襲しなかったのには、明確な技術的理由があります。それは、OSIモデルが暗黙に前提とする地上ネットワークの環境条件が、深宇宙リンクではことごとく成り立たないという、このシリーズで繰り返し登場してきたテーマそのものです。

OSIモデルの層分けは、次のような環境を暗黙に前提として設計されています。

  • 帯域が(相対的に)豊富である。ネットワーク層のヘッダオーバーヘッドや、トランスポート層のハンドシェイクにかかる数バイト〜数十バイトのコストは、リンク全体の帯域に対して無視できる程度である。
  • 遅延が短い(地上の広域網でもせいぜい数百ミリ秒)。エンドツーエンドのハンドシェイクや、ウィンドウベースの再送制御が、実用的な時間スケールで完結する。
  • 接続が常時、あるいはほぼ常時成立している。トランスポート層の「コネクション」という概念自体が、送信元-宛先間に持続的な経路が存在することを前提にしている。
  • 電力がほぼ無制限である(少なくとも通信ノード1台あたりで見れば)。層をまたぐたびに発生する処理オーバーヘッド(ヘッダの付け外し、プロトコル変換)のコストを、電力予算の観点から気にする必要が薄い。

DTNの回で数式付きで確認した通り、火星との往復遅延は最大で45分近くに達し、地上のTCPの3ウェイハンドシェイクはそれだけで1時間以上かかります。SCPSの回で見たように、標準TCPのウィンドウサイズの上限はBDP(帯域遅延積)に対してあまりに小さく、実効スループットはリンク容量の0.02%程度にまで落ち込みます。そして電力制約とリンク設計のトレードオフの回で見たように、探査機に搭載できる送信機の電力は数十〜数百ワット程度という極めて厳しい制約下にあり、1ビットを送るコストそのものが地上の有線網とは比較にならないほど高くつきます。

OSIが前提とする「豊富な帯域・低遅延・常時接続・実質無制限の電力」という4つの条件が、深宇宙リンクではすべて逆転しているのです。この環境条件の逆転が、具体的にプロトコル設計にどう跳ね返るかを、いくつかの側面から整理してみましょう。

ヘッダオーバーヘッドへの感度。 OSIの各層は、それぞれ独立にヘッダ(制御情報)を付加します。地上のネットワークでは、7層分のヘッダを積み重ねても、パケット全体に占める割合はわずかです。しかし深宇宙リンクでは、PCM/PSK/PMの回で見た変調損失や、限られた送信電力の制約により、1ビットでも余計なオーバーヘッドを削ることに強いインセンティブが働きます。SpacePacketの一次ヘッダが6オクテット、TMトランスファーフレームのプライマリヘッダが6オクテットというように、CCSDSの各層のヘッダは驚くほど切り詰められており、OSIのように各層が独立に自由なヘッダ設計をする余地は最初から想定されていません。層の数を最小限に絞り、層をまたぐたびに発生するヘッダの重複を避けるという設計判断そのものが、電力制約から逆算された結果です。

コネクション概念の扱い。 OSIのトランスポート層・セッション層は「持続的なコネクション」を前提としますが、DTNが扱う惑星間ネットワークでは、そもそも送信元から宛先までの経路が同時には存在しないことすらあります。この環境では、OSI的な「コネクションを確立してから通信する」という発想自体が崩壊するため、DTNはコネクション指向のトランスポート層モデルを捨て、蓄積転送(store-and-forward)というまったく別のパラダイムを採用しました。これはOSIの枠組みの中で「トランスポート層をどう改良するか」という問いに答えたのではなく、その問いの前提となる層の切り分け方自体を疑い直した結果です。

ルーティングの必要性の粒度。 OSIのネットワーク層は「任意の遠方のノードへの経路選択」を主要な仕事としますが、探査機と単一の地上局を結ぶ最も基本的なリンクでは、経路選択という問題自体がほぼ存在しません(1対1のポイントツーポイント通信だからです)。そのためSpacePacketは、ネットワーク層相当の位置にありながら、ルーティング機能を持たない軽量な識別子(APID)だけで済ませています。ルーティングが本当に必要になる中継・多ホップの場面でだけ、SCPS-NPやBundle Protocolという、より重い機能を持つプロトコルを追加で載せる——これは、OSIのように「ネットワーク層は常にルーティング機能を持つべきだ」と決め打ちするのではなく、必要なところにだけ必要な機能を足す、宇宙リンクの制約に最適化された積み上げ方です。

以上をまとめると、CCSDSがOSIをそのまま採用しなかった理由は、OSIモデルが間違っていたからではなく、OSIモデルが最適化しようとした環境条件(豊富な帯域・低遅延・常時接続・潤沢な電力)と、深宇宙リンクの環境条件(希少な帯域・長遅延・断続接続・厳しい電力制約)が、根本から異なっていたからです。CCSDSは、OSIという「参照モデル」が示した層に分けて考えるという方法論そのものは踏襲しつつ、実際に何層に、どう切り分けるかという具体的な設計は、宇宙リンク固有の制約から独立に導き出したのだと理解するのが正確です。

実務での使われ方: 層の独立性がCCSDS標準の進化を支える

「層に分ける」という設計原則は、単なる理論的な整理にとどまらず、CCSDS標準が数十年にわたって実際に進化し続けてこられた、実務上の生命線になっています。

変調方式の追加が上位層に影響しない。 PCM/PSK/PMは深宇宙探査の黎明期から使われてきた伝統的な変調方式ですが、CCSDSはその後もQPSK/OQPSK、より高次の変調方式、LDPC符号やターボ符号といった新しい物理層技術を継続的に追加してきました。これらはすべて、CCSDS 401.0-B(Radio Frequency and Modulation Systems)やCCSDS 131.0-B(TM Synchronization and Channel Coding)といった、物理層を担当する文書だけを改訂することで実現されています。物理層の上に載るTM宇宙データリンクプロトコル(CCSDS 132.0-B)やSpacePacket(CCSDS 133.0-B)の仕様は、変調方式が何であるかを一切気にせず、「復調・復号済みのビット列が渡ってくる」という抽象化されたインターフェースだけを前提に書かれています。これにより、あるミッションが最新のLDPC符号を採用しても、フレームフォーマットや仮想チャンネルの仕組みを再設計する必要はまったくありません。

世代の異なる探査機が同じ地上局インフラを共有できる。 DSNのようなアンテナ網は、数十年単位で運用され、その間に打ち上げられる探査機は世代ごとに異なる変調方式・符号化方式を採用します。物理層とデータリンク層以上が独立しているおかげで、地上局のアンテナ・受信機(物理層の実装)を新しい変調方式に対応させて更新しても、その上で運用されているデータ処理系(フレーム分解、SpacePacket復元、APID振り分けといったソフトウェア資産)にはほとんど手を入れる必要がありません。逆に、古い世代の探査機が今なお運用されている場合でも、地上局側は物理層の受信系統だけを古い方式に対応させておけば、その上位のデータ処理パイプラインは新しいミッションのものと共通化できます。

機関をまたいだ相互運用性(クロスサポート)。 SLEや国際クロスサポートの回で見たように、NASA、ESA、JAXAといった各宇宙機関は、互いの地上局を融通し合う相互運用協定を結んでいます。これが可能なのは、CCSDS標準が層ごとに独立した文書として整備されているため、各機関が「物理層の実装は自国のアンテナ設備の事情に合わせて多少異なっていても、データリンク層以上のフレームフォーマットさえ共通であれば、相互にデータを受け渡しできる」という部分的な標準化の恩恵を受けられるからです。もしCCSDSがOSIのように7層すべてを一枚岩の仕様として策定していたら、ある層の些細な違いが全体の相互運用性を阻害してしまい、機関間のクロスサポートはずっと困難になっていたはずです。

このように、CCSDSにおける「層の分離」は、学術的な美しさのためではなく、変調方式の技術革新、地上局インフラの世代交代、機関をまたいだ相互運用性という、実務上の3つの要請に応えるための実利的な設計原則として機能しています。OSIとは異なる切り分け方を選びながらも、「ある層の変更が他の層に波及しない」というOSIの核心的な理念そのものは、CCSDSの世界でも変わらず生き続けているのです。

演習問題

  1. 本文の対応表を参考に、OSIの7層のうち「CCSDSでほぼそのまま対応する層」と「複数のCCSDSプロトコルに機能が分散している層」をそれぞれ挙げ、なぜそのような違いが生まれるのかを、この回で学んだ環境条件(帯域・遅延・接続性・電力)の観点から説明してください。

  2. SpacePacketのAPIDは、OSIのネットワーク層が担うはずの「経路選択(ルーティング)」機能を持ちません。それにもかかわらずSpacePacketがネットワーク層相当の位置に置かれる理由と、実際に複数ホップのルーティングが必要になった場合にCCSDSがどう対応しているかを、中継アーキテクチャやDTNの回の内容を踏まえて説明してください。

  3. もしCCSDSがOSIモデルの7層構造をそのまま忠実に採用し、各層が独立に自由なヘッダを付加できる設計にしていたら、深宇宙リンクの限られた帯域・電力予算にどのような悪影響が出ると考えられるか、PCM/PSK/PMの変調損失の議論を踏まえて具体的に論じてください。

  4. 「ある層の変更が他の層に影響を与えない」という層の独立性の原則が、実際のCCSDS標準の運用でどのように役立ってきたかを、変調方式の追加・地上局インフラの世代交代・機関間クロスサポートという3つの観点のうち少なくとも1つを選んで、具体例とともに説明してください。

まとめと次回予告

OSI参照モデルとCCSDSプロトコルスタックは、どちらも「複雑な通信システムを、独立に設計・進化させられる層に切り分ける」という同じ動機から出発していますが、その切り分け方は大きく異なります。OSIが前提とする「豊富な帯域・低遅延・常時接続・潤沢な電力」という地上ネットワークの環境条件は、深宇宙リンクではことごとく逆転しており、CCSDSはネットワーク層以上の機能を単一のプロトコルに集約せず、必要な場面にだけ必要な機能(SCPS、DTN、CFDPなど)を追加する、より柔軟で軽量な積み上げ方を選びました。それでもなお、「層の独立性」というOSIの核心的な理念そのものは受け継がれており、それが変調方式の技術革新や機関間の相互運用性を支える実務上の生命線になっている、というのがこの回の結論です。

次回は、CCSDSプロトコルスタックの応用として、動画や画像のようなリアルタイム性の高いストリーミングデータを扱うCCSDS動画・ストリーミング配信プロトコルに軽く触れます。この回で整理した層構造の中で、映像のようなデータがどの層でどう扱われるのかを見ていきます。

参考文献

  • CCSDS 130.0-G, Overview of Space Communications Protocols, Green Book
  • ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
  • CCSDS 401.0-B, Radio Frequency and Modulation Systems, Part 1: Earth Stations and Spacecraft
  • CCSDS 132.0-B, TM Space Data Link Protocol
  • CCSDS 133.0-B, Space Packet Protocol
  • CCSDS 710.0-G, Space Communications Protocol Specification (SCPS)—Rationale, Requirements, and Application Notes
  • 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