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

SCPS — TCP/IPを宇宙リンクに適応させた通信プロトコル群

地上のインターネットが使うTCP/IPを、そのまま数億kmの深宇宙リンクに持ち込むと何が壊れるのか。DTNのBundle Protocolに先立って登場した宇宙特化プロトコル群SCPS(SCPS-NP/TP/SP/FP)を、TCPのウィンドウ・輻輳制御の数式とともに理解する。

前提知識: dtn

SCPSTCP/IP輻輳制御CCSDSプロトコル設計

この回で学ぶこと

DTN(Delay/Disruption Tolerant Networking)の回では、「接続が頻繁に、しかも予測不能に完全に切れる」という極端な環境に対応するため、Bundle Protocolが送信元から宛先までのエンドツーエンドの経路を前提とせず、ノードごとにデータを丸ごと蓄積してから次の機会を待つ、という発想を持っていることを見ました。

しかし、DTNのこの発想が生まれる前から、宇宙機関は別の問題に取り組んでいました。それは、**「エンドツーエンドの経路自体は(パスの間)一応つながっているのに、地上のTCP/IPをそのまま使うと性能がまったく出ない」**という問題です。深宇宙リンクは、途切れてはいなくても、往復遅延(RTT: Round-Trip Time)が数十秒から数十分、外惑星探査ではさらに長くなり、しかもアップリンクとダウンリンクの帯域が大きく非対称で、ビット誤り率も地上の光ファイバー網とは比較にならないほど高くなります。地上のインターネットの前提——「RTTはせいぜい数百ms、パケットロスはほぼ輻輳のサイン」——がことごとく崩れるのです。

この問題に1990年代後半から取り組んだのが、CCSDSのSCPS (Space Communications Protocol Specifications) という標準群です。SCPSは、TCP/IPスイートの各層(ネットワーク層・トランスポート層・セキュリティ層・アプリケーション層)を1つずつ「宇宙リンク用に改造する」というアプローチを取りました。DTNのBundle Protocolが「地上の階層モデルを根本から見直す」という思想だったのに対し、SCPSは「地上のTCP/IPという実績あるモデルを土台に残しつつ、そのパラメータと振る舞いを宇宙の物理条件に合わせてチューニングする」という、より保守的で実装しやすいアプローチでした。この回では、SCPSファミリーの構成と、特にその心臓部であるSCPS-TPがTCPのどこをどう変えたのかを、ウィンドウサイズと輻輳制御の数式とともに見ていきます。

直感的導入: なぜTCPをそのまま宇宙に持っていけないのか

地上のTCPは、非常によくできたプロトコルですが、その設計にはいくつかの暗黙の前提が埋め込まれています。

RTTは短い(地上の広域網でもせいぜい数百ms程度)。
パケットロスの主因は輻輳(ネットワーク機器のバッファ溢れ)であり、伝送路自体のビット誤りはほぼ無視できる。
上り(ACKを送る向き)と下り(データを送る向き)の帯域は、極端には非対称でない。

深宇宙リンクでは、この3つの前提がすべて崩れます。

火星との往復遅延は、地球と火星の位置関係によって約8分から48分にも達します(片道光行時間が約4〜24分)。
深宇宙リンクのビット誤りは、強力な誤り訂正符号(畳み込み符号とビタビ復号、LDPC、ターボ符号など)をかけてもなお、地上の有線網より何桁も高い残留誤り率を持ちます。
探査機からのダウンリンク(科学データ)は高速だが、探査機へのアップリンク(コマンド)は低速、という非対称性が常態化しています。

TCPはこれらの条件下では性能が劇的に落ちます。以下でその理由を定量的に見ていきましょう。

定式化1: 帯域遅延積とウィンドウサイズの限界

TCPの基本原理は、「相手からのACK(受信確認)を待たずに、一度に送り出せるデータ量」をウィンドウサイズ $W$ (バイト単位)で制御するというものです。あるリンクの帯域幅を $R$ (bps)、往復遅延を $\text{RTT}$ (秒)とすると、帯域遅延積(Bandwidth-Delay Product, BDP)

\text{BDP} = R \times \text{RTT} \quad [\text{bit}]

は「そのリンクが物理的に運んでいる最中のデータ量」、すなわちパイプの中に飛んでいるビット数を表します。リンクの帯域を使い切るには、ACKが返ってくるのを待たずに、少なくともBDP分のデータを送り出し続けられる必要があります。したがって、達成可能なスループット $T$ は近似的に

T \approx \min\!\left(R,\ \frac{W}{\text{RTT}}\right)

で与えられます。 $W \geq \text{BDP}$ であれば $T \approx R$ (リンクを使い切れる)、 $W < \text{BDP}$ であれば $T \approx W/\text{RTT}$ とリンク容量よりずっと小さい値に頭打ちになります。

ここに、地上のTCPが宇宙リンクで直面する第一の壁があります。オリジナルのTCPヘッダのウィンドウフィールドは16ビットで、表現できる最大ウィンドウサイズは

W_{\max} = 2^{16}-1 = 65{,}535\ \text{バイト} \approx 524{,}280\ \text{ビット}

に制限されています(RFC 1323のウィンドウスケールオプションを使わない場合)。具体例で確認してみましょう。火星探査機とのリンクで、ダウンリンク帯域 $R = 1\ \text{Mbps}$ 、往復遅延 $\text{RTT} = 40\ \text{分} = 2400\ \text{秒}$ (火星が地球から遠い時期を想定)とすると、

\text{BDP} = 1\times10^6 \times 2400 = 2.4\times10^9\ \text{ビット} = 300\ \text{MB}

これに対し、ウィンドウスケールなしの標準TCPの最大ウィンドウは約64KBしかありません。このとき達成可能なスループットは

T \approx \frac{W_{\max}}{\text{RTT}} = \frac{524{,}280}{2400} \approx 218\ \text{bps}

1 Mbpsのリンクを使っているのに、実効スループットはわずか218 bps。 リンク容量の0.02%程度しか使えていないことになります。これは輻輳やビット誤りが一切なくても、単にウィンドウサイズがBDPに対して小さすぎるという理由だけで起きる、構造的な性能劣化です。

定式化2: スロースタートと輻輳回避の時間スケール

ウィンドウを単純に大きくすれば済むかというと、話はそう単純ではありません。TCPはリンクの状態をいきなり最大ウィンドウで攻めるのではなく、スロースタートでウィンドウを指数関数的に増やしながら様子見をし、ある閾値を超えると輻輳回避フェーズに移って、今度は1RTTごとに1MSS(最大セグメントサイズ)ずつ線形に増やしていきます。

スロースタートでは、 $n$ RTT経過後のウィンドウはおおよそ

W(n) \approx W_0 \cdot 2^{n}

で増加します( $W_0$ は初期ウィンドウ)。問題は、この「1回分の増加」に丸々1RTTかかるという点です。地上網ならRTTは数百msなので、 $W$ が目標値(たとえば先ほどのBDP相当)に達するまで数秒〜数十秒程度で済みます。しかし深宇宙リンクではRTTそのものが数十分に達するため、スロースタートで目標ウィンドウに到達するだけで何時間もかかってしまうことがあります。

さらに輻輳回避フェーズは1RTTあたり線形に1MSSしか増やさないため、いったんウィンドウが縮小される(パケットロスが起きる)と、そこから回復するのにも大量のRTTを要します。RTTが数十分のリンクでは、 $k$ 回分の増加に必要な実時間は

\Delta t \approx k \cdot \text{RTT}

であり、たとえば $k=100$ 回の増加ステップが必要な場合、 $\text{RTT}=40$ 分のリンクでは $\Delta t \approx 4000$ 分 $\approx 66.7$ 時間、実に3日近くかかる計算になります。深宇宙探査機との通信パスは1回あたり数時間〜1日程度しか確保できないことも多いため、パスが終わるまでにウィンドウが目標値に到達すらしないという事態が現実に起こり得ます。

定式化3: パケットロスの原因診断という問題

もう1つの構造的な問題は、TCPの輻輳制御が「パケットロス = 輻輳のサイン」という単一の仮定に基づいていることです。標準的なTCPの輻輳制御(たとえばTCP Renoの加法的増加・乗法的減少、AIMD)は、パケットロスを検知すると輻輳ウィンドウ $cwnd$ を

cwnd \leftarrow \frac{cwnd}{2}

と即座に半減させます。地上の有線網ではこの仮定はおおむね正しく、パケットロスの大半はルータのバッファ溢れによる輻輳です。

しかし深宇宙リンクでは、パケットロスの少なからぬ部分が、AWGN雑音や太陽電波雑音、Kaバンドの降雨減衰といった**伝送路自体のビット誤り(corruption loss)**に起因します。これは輻輳とは無関係な現象であり、リンクは実は空いているのに、TCPは「輻輳が起きた」と誤診断してウィンドウを半減させてしまいます。RTTが長いリンクではこの誤診断1回のコストが非常に大きく(前節で見た通り、ウィンドウの回復に長い実時間がかかる)、ビット誤りが多いリンクほどTCPのスループットは実際の帯域よりずっと低い水準に張り付いてしまいます。

以上の3つ——(1) 標準ウィンドウの上限がBDPに対して小さすぎる、(2) スロースタート・輻輳回避の時定数がRTTに比例して長大化する、(3) ビット誤りによるロスを輻輳と誤診断する——が、地上のTCPをそのまま深宇宙リンクに持ち込んだときに起きる、代表的な性能劣化のメカニズムです。SCPS-TPは、この3つの問題それぞれに対処するように設計されています。

SCPSファミリーの構成

SCPSは単一のプロトコルではなく、地上のTCP/IPスイートに対応する4つの規格からなるファミリーです。それぞれがOSI参照モデルのどの層に位置し、地上のどのプロトコルの「宇宙適応版」であるかを整理すると、次のようになります。

SCPS規格	対応する層	地上での対応物	役割
SCPS-NP (Network Protocol)	ネットワーク層	IP	宇宙リンク・地上リンク混在環境でのアドレッシングとルーティング、ヘッダ圧縮
SCPS-TP (Transport Protocol)	トランスポート層	TCP	長遅延・非対称帯域・高ビット誤り率への適応(本回の主眼)
SCPS-SP (Security Protocol)	セキュリティ層	IPsec相当	帯域制約下・間欠接続下でも機能する機密性・完全性・認証の付与
SCPS-FP (File Protocol)	アプリケーション層	FTP	長遅延下でのラウンドトリップ回数を切り詰めたファイル転送

SCPS-NPは、IPの代替、あるいはIPと共存する軽量なネットワーク層プロトコルです。宇宙リンクでは伝送効率がシビアなため、地上のIPヘッダに含まれる汎用的だが冗長なフィールドを削り、ヘッダを大幅に圧縮できるようにしています。またミッション運用でしばしば必要になる「優先度付きルーティング」(限られた帯域の中で、どのデータを優先して送るか)のための拡張フィールドも持ちます。

SCPS-SPは、地上のIPsecに近い発想のセキュリティ層です。ただし、帯域が極端に限られ、しかも接続が間欠的にしか得られない宇宙リンクでは、IPsecの鍵交換やハンドシェイクをそのまま使うと往復遅延のコストが大きすぎるため、SCPS-SPはより少ないラウンドトリップで機密性・完全性・送信元認証を確立できるように設計されています。

SCPS-FPは、地上のFTP(File Transfer Protocol)の宇宙適応版です。従来のFTPは、接続確立・認証・ディレクトリ操作・ファイル転送要求などの過程で何度もクライアント-サーバ間のやり取り(ラウンドトリップ)を必要とします。RTTが数十分に達する深宇宙リンクでは、ラウンドトリップ1回ごとに数十分単位のコストがかかるため、これを愚直に繰り返すFTPは実用になりません。SCPS-FPは、これらのやり取りに必要なラウンドトリップの回数を最小限に切り詰め、可能な限り「1往復、あるいは0往復に近い形で」ファイル転送を完了できるように設計されています。トランスポート層にはSCPS-TPを用いることが想定されています。

そして、この4つの中で最も設計上の工夫が集中しているのが、次節で詳しく見るSCPS-TPです。

SCPS-TPの設計: TCPを「拡張」として実装する

SCPS-TPの設計思想として特徴的なのは、まったく新しいプロトコルをゼロから作るのではなく、標準TCPのオプション機構を使って機能拡張として実装し、拡張に対応していない相手とも(拡張機能なしで)通信できる後方互換性を保つ、という戦略を取ったことです。これにより、SCPS-TP対応機器と非対応機器が混在するネットワークでも、最低限TCPとして通信が成立します。

SCPS-TPが標準TCPに対して加える主な拡張は、前節で整理した3つの問題に、それぞれ対応しています。

(1) ウィンドウスケーリングによるBDP対応

標準TCPが持つRFC 1323のウィンドウスケールオプションと同様の仕組みを使い、実効的なウィンドウサイズをBDPに見合うところまで拡大できるようにします。先ほどの例のように帯域遅延積が数百MBに達するようなリンクでも、ウィンドウを

W \gtrsim \text{BDP} = R \times \text{RTT}

まで引き上げることで、理論上のスループットの天井を $R$ 近くまで押し上げます。

(2) 修正スロースタートとレート主導の輻輳制御

長いRTTの下でスロースタートに要する実時間を短縮するため、SCPS-TPは初期ウィンドウの取り方や増加のペースを、RTTに依存しにくい形に調整します。また輻輳ウィンドウの制御でも、AIMDのような「RTTごとに何MSS増やす」という時間駆動の増分ではなく、リンクの利用可能帯域そのものを直接推定してレートを決める、より積極的な立ち上がりを許容する方式が採られます。これは、応答が遅いリンクでは「様子を見ながら慎重に増やす」というTCPの美徳が、そのまま「立ち上がりに何時間もかかる」という欠点に直結してしまうためです。

(3) 輻輳ロスと破損ロスの区別

SCPS-TPの最大の特徴の1つが、パケットロスの原因を区別するという発想です。標準TCPは「ロス=輻輳」の一枚岩の仮定で動きますが、SCPS-TPは、下位層(リンク層)から得られる情報や、再送されたパケットが実際に破損データを含んでいたかどうかといった手がかりを使って、そのロスが

輻輳によるロス(congestion loss): ネットワークが混雑している、送信レートを落とすべきサイン
破損によるロス(corruption loss): 単にビット誤りでパケットが壊れただけで、リンクは空いている

のどちらであるかを可能な限り切り分けます。破損ロスだと判断できた場合には、標準TCPのようにウィンドウを半減させず、送信レートをほぼ維持したまま該当パケットだけを再送します。これにより、ビット誤り率の高い宇宙リンクでも、輻輳制御が不必要にスループットを絞り込んでしまう事態を避けられます。

(4) 選択的否定確認応答(SNACK)

再送の効率化のためにSCPS-TPが導入するのがSNACK (Selective Negative Acknowledgment) オプションです。標準TCPの再送の基本は「一定時間内にACKが来なければタイムアウトで再送する」または「重複ACKを3回受け取ったら再送する(高速再送)」という仕組みですが、RTTが長いリンクではこの検知自体に長い時間がかかり、さらに一度に大量のデータが失われた場合には効率が悪くなります。SNACKは、受信側が「どのバイト範囲が欠落しているか」をまとめて送信側に明示的に伝えることで、送信側が本当に足りない部分だけをピンポイントで再送できるようにし、往復遅延が長いリンクでの再送効率を大きく改善します。

(5) 非対称帯域への対応(ACK圧縮・ヘッダ圧縮)

探査機からのダウンリンクが高速、地上からのアップリンクが低速という非対称性がある場合、通常のTCPでは「大量に届くデータパケットに対して、同じだけの数のACKパケットを低速な逆方向リンクで送り返す」必要があり、ACKトラフィックそのものが細いアップリンクを圧迫してしまうことがあります。SCPS-TPは、複数のACKをまとめて間引いて送る、あるいはヘッダ情報を圧縮するといった工夫により、逆方向リンクに必要な帯域を切り詰め、非対称なリンクでも順方向のスループットが不必要に制限されないようにしています。

SCPSとDTNの位置づけの違い

ここまで見てきたSCPS-TPの工夫は、いずれも「エンドツーエンドの接続は(遅延はあっても)一応維持されている」ということを前提にしています。ウィンドウ・ACK・再送タイムアウトといったTCPの基本機構は、そもそも送信元と宛先の間に、ある程度の期間は途切れずに存在する経路があることを仮定しているからです。

これに対しDTNのBundle Protocolが対象とするのは、そもそも「送信元から宛先まで、同時に成立する経路が存在しない」環境です。惑星間中継ネットワークのように、ノード間のリンクがスケジュールされた接触(コンタクト)の間しか開かず、しかも複数ホップを経由する必要がある場合、ある瞬間を切り取ってもエンドツーエンドの経路そのものが物理的に存在しないことがあります。この場合、TCPのようにコネクションの状態を維持し続けるモデルは根本的に破綻するため、Bundle Protocolはノードごとにデータの塊(バンドル)を丸ごと蓄積し、次のホップへの接触が来るのを待つ、蓄積&転送のオーバーレイモデルを採用しているのでした。

この2つの適用領域の違いを整理すると、次のようになります。

	SCPS(特にSCPS-TP)	DTN(Bundle Protocol)
前提とする接続性	遅延はあるが、パスの間はエンドツーエンドの経路が(一応)成立している	経路が瞬間的にも常時成立するとは限らない、間欠的な接触の連なり
モデル	コネクション指向、TCP的なウィンドウ・ACK・再送	オーバーレイ的な蓄積&転送、ホップごとの管理
典型的な適用場面	探査機-地球間の単一の深宇宙リンク(長遅延だが接続そのものは安定)	惑星間中継網、月・惑星の裏側に隠れるノード、電源制約で間欠運転するノードなど
信頼性の単位	エンドツーエンドのバイトストリーム	ホップごとのバンドル、カストディ転送

つまりSCPSは「1本の長遅延リンクを、地上のTCP/IPの延長線上でいかに効率よく使うか」という問題への回答であり、DTNは「そもそも1本のリンクという単位では捉えきれない、断続的で多ホップなネットワーク全体をいかに設計するか」というより広い問題への回答です。歴史的には、まずSCPSが1990年代後半にTCP/IPの改良として登場し、その後、深宇宙探査ミッションの多様化(複数の周回機・着陸機・ローバーが関与する惑星間ネットワーク)にともなって、SCPSの前提(接続はいずれ成立する)すら成り立たない状況への対応として、2000年代にDTNのアーキテクチャが提案されるという流れになります。両者は競合する規格というより、適用条件が異なる補完的な道具として理解するのが適切です。

実務での使われ方

SCPSはCCSDSの正式な勧告として標準化され、以下の4つの文書に規定されています。

CCSDS 713.0-B, SCPS Network Protocol (SCPS-NP)
CCSDS 714.0-B, SCPS Transport Protocol (SCPS-TP)
CCSDS 715.0-B, SCPS Security Protocol (SCPS-SP)
CCSDS 717.0-B, SCPS File Protocol (SCPS-FP)

SCPSの開発は、もともと米国防総省(DoD)とNASAが共同で主導した経緯があり、初期には軍事衛星通信システムでの採用が先行しました。低軌道の小型実験衛星でのTCP/IP系プロトコルの技術実証(1990年代末〜2000年代初頭の一連の小型衛星ミッション)を通じて、SCPS-TPの長遅延・高ビット誤り率環境での有効性が確認され、その後、商業衛星通信の分野にもSCPS-TPの発想——特に「ロスの原因を輻輳と破損とで区別する」「ACKを間引いて非対称帯域を有効活用する」という考え方——が、Performance Enhancing Proxy (PEP) と呼ばれる、衛星リンクの両端に置いてTCPの挙動を横取り・最適化する中継装置の設計に強く影響を与えました。今日の商用VSAT(超小型地球局)や静止衛星ブロードバンドサービスの多くが、何らかの形でこのSCPS-TP的な輻輳制御・ACK処理の考え方を取り入れたPEPを介してTCPトラフィックを流しています。

深宇宙探査の文脈では、SCPS-TPやSCPS-FPは、探査機と地上局の間で直接運用されるというよりも、地上系のミッション運用インフラや、比較的継続的な接続が期待できるリンク(たとえば月周回機と地球の間、あるいは地球周回の中継衛星と地上局の間)での、ファイル転送・テレメトリ配送の効率化という文脈で活用されてきました。惑星間の多ホップネットワークが本格的に構築されつつある現在では、SCPSが対応する「長遅延だが接続は維持される」領域と、DTNが対応する「接続が間欠的にしか得られない」領域とを、ミッションのアーキテクチャに応じて使い分ける、あるいは組み合わせるという設計判断が行われています。次回扱うLTP (Licklider Transmission Protocol) は、まさにこの中間領域——DTNのBundle層の下で、個々のリンクごとの信頼性を担う——に位置するプロトコルであり、SCPS-TPが持っていた「長遅延リンクでの効率的な再送」という発想を、DTNのアーキテクチャの中に引き継いだ存在だと言えます。

演習問題

ある深宇宙探査機とのダウンリンクの帯域が $R = 4\ \text{Mbps}$ 、往復遅延が $\text{RTT} = 20\ \text{分}$ であるとする。帯域遅延積 $\text{BDP} = R \times \text{RTT}$ をビットおよびバイトで求めよ。また、この値がウィンドウスケールなしの標準TCPの最大ウィンドウ(65,535バイト)の何倍に相当するかを求め、標準TCPで達成できる実効スループット $T \approx W_{\max}/\text{RTT}$ を計算し、リンク容量に対して何%しか使えていないかを議論せよ。
スロースタートでウィンドウが $n$ RTTの経過で $W(n) \approx W_0 \cdot 2^n$ と増加するモデルを用いる。 $W_0 = 1$ MSS(1 MSS = 1460バイトとする)、目標ウィンドウを問1で求めたBDP相当とするとき、目標に到達するまでに必要なRTTの回数 $n$ をおよそ求めよ。さらにその回数に $\text{RTT}=20$ 分を掛けて、実時間として何時間かかるかを見積もり、この時間が探査機との1回の可視パス(数時間程度と仮定)の中に収まるかどうかを論じよ。
標準TCPは、パケットロスを検知すると輻輳ウィンドウを問答無用で半減させる( $cwnd \leftarrow cwnd/2$ )。宇宙リンクでこの挙動がなぜ問題になるのかを、「輻輳によるロス」と「ビット誤りによる破損ロス」の違いに触れながら説明し、SCPS-TPがこの問題にどう対処しているかをまとめよ。
SCPS-TP(コネクション指向、エンドツーエンドのウィンドウ制御)と、DTNのBundle Protocol(蓄積&転送のオーバーレイモデル)は、それぞれどのような接続性の前提の違いに基づいて設計されているか。次の2つのシナリオそれぞれについて、どちらの方式がより適しているかを理由とともに述べよ。(a) 単一の探査機と地球の間の、遅延は長いが常時オープンな1本の巡航フェーズのリンク。(b) 複数の周回機・着陸機・ローバーが、それぞれ限られた可視時間帯にしか互いに接触できない惑星間中継ネットワーク。

まとめと次回予告

SCPSは、地上のTCP/IPスイートを1層ずつ宇宙リンク用に改造するという保守的だが実践的なアプローチによって、深宇宙通信特有の長遅延・非対称帯域・高ビット誤り率という3つの課題に対処してきたプロトコル群です。特にSCPS-TPは、(1) ウィンドウスケーリングによる帯域遅延積対応、(2) RTTに縛られにくい輻輳制御の立ち上がり、(3) 輻輳ロスと破損ロスの区別、(4) SNACKによる効率的な再送、(5) ACK圧縮による非対称帯域対応、という具体的な拡張の積み重ねによって、標準TCPがほぼ機能しなくなるような環境でも実用的なスループットを引き出そうとします。そして、SCPSが「接続は一応維持される」ことを前提にしているのに対し、DTNは「接続がそもそも同時には成立しない」というより厳しい条件に応える、適用領域の異なる補完的な設計であることも整理しました。

次回は、DTNのBundle Protocolの下で、個々のリンク(コンタクト)ごとの信頼性を担うLTP (Licklider Transmission Protocol) に軽く触れます。LTPは、SCPS-TPが培った「長遅延下での効率的な再送」というノウハウを、DTNの間欠接続モデルの中でどう活かしているかを見ていく回になります。

参考文献

CCSDS 713.0-B, SCPS Network Protocol (SCPS-NP)
CCSDS 714.0-B, SCPS Transport Protocol (SCPS-TP)
CCSDS 715.0-B, SCPS Security Protocol (SCPS-SP)
CCSDS 717.0-B, SCPS File Protocol (SCPS-FP)
CCSDS 710.0-G, Space Communications Protocol Specification (SCPS)—Rationale, Requirements, and Application Notes
RFC 2760, Ongoing TCP Research Related to Satellites
RFC 1323, TCP Extensions for High Performance
V. Cerf et al., “Delay-Tolerant Networking Architecture,” RFC 4838
J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76