※この文章は合同誌の一部として技術書典17にて販売する予定だった書籍です。諸事情により出展できなくなったためこのブログに供養します。
はじめに
「月面に最初の女性を、次の男性を」と謳い、月面着陸に止まらず月面での定住を最終目標とするアルテミス計画が発表されてからすでに5年が経ちました。現在は月面での定住を2030年に実現することをゴールに、さまざまな開発・実験が進んでいる訳ですが、そのコンポーネントの一つとして、衛星通信環境の整備があげられます。
NASAは、その基幹システムとして「LunaNet」を提唱しています。これは宇宙空間で地球上のインターネットに似た構成で通信を行うことで、月面上においてもより堅牢で可用性の高い通信を実現しようという取り組みです。しかし、現実的に宇宙空間にネットワークを形成するには、遅延、軌道の問題など多くの壁が立ちはだかります。それらに対応するために、CCSDSやIETFなどの標準化団体、NASAやJAXAなどの宇宙機関が議論・開発に取り組んでいるのがDelay-Tolerant Networking (DTN)と呼ばれる技術です。
本書では、現状の宇宙通信の仕組みからネットワーク形成のための技術、さらには地球上のインターネットプロトコル（IP）の宇宙空間への応用に向けた取り組みまで、網羅的に紹介します。全ての技術、プロトコルを完璧に理解するにはさらなるリサーチが必要ですが、衛星通信に関する基礎的な知識、トレンドを本書から吸収していただければ幸いです。
現在の宇宙通信
私たち人類は、1969年に初めて月面に着陸しました。その後長い冷戦における各国独自の宇宙開発、冷戦後の国際協力的な宇宙開発を経て、2011年に国際宇宙ステーション（ISS）が完成しました。本章では、月とISS、更にはより遠い地点と地球間の通信について、現在どのような技術で、どのように行われているのかを紹介します。
DSN
衛星-地球間の通信には、主にNASAのDeep Space Network (DSN)なる設備が利用されています。DSNは1960年代から構築が始まったもので、アメリカのカリフォルニア、スペインのマドリード、オーストラリアのキャンベラにそれぞれアンテナを配置し、そこから月に向けて通信を行います。この3点は経度がおよそ120度ずつ離れており、月の位置に関わらず通信が行えるように配置されています。
各施設には複数のアンテナが設置されており、そのリアルタイムの通信状況はNASAのWebサイトから確認することができます。DSNは月よりさらに遠い距離との通信も可能であり、実際に火星探査機との通信やはやぶさ2との通信にも利用されています。また、アンテナのアレイ化や強力な誤り訂正符号の利用など、宇宙通信特有の、微弱な信号を受信し正確に処理する技術が多く用いられています。
通信能力について、DSNではX帯(8-12GHz)やKa帯(26-40GHz)などの帯域を用いて電波通信を行います。これは軍事通信などに主に使われる高周波数帯で、これにより高い指向性、広い帯域幅の確保、送信電力の効率化が実現します。とはいえ、そもそも電波を使うというアイディアがいささか1960年代的ではあります。より現代的な通信方法として、2023年には同じくNASAが近赤外線レーザーを用いて3100万km離れた距離からの映像ストリーミングに成功しています。この実験は探査機Phycheからストリーミングする形で行われ、映像伝送遅延は約100秒、下りのスループットは約267Mbpsを記録しており、これは従来の通信手法に比べてはるかに優れた数値です。実験自体はDSNのアンテナが用いられたわけではありませんが、現在DSNのアンテナの通信方法を更新するための作業が進んでいます。
通信衛星による中継
DSNのアンテナは月の公転による通信への影響を抑える効果を持ちますが、月の自転には対応できません。月の自転周期と地球の公転周期はほとんどの同じであり、月は地球に対して常に同じ面を向いています。つまりDSNのアンテナのような地球からの通信では月の裏側に直接データを伝送することができないという問題に直面するのです。
この問題は、月の周りを回る通信衛星で中継を行うことで解決します。実際に、中国の月探査機「嫦娥4号」は通信衛星の中継を経て地球と通信し、月の裏側の探査を行っています。またアルテミス計画の一環で建設予定の拠点「Gateway」は、月長楕円極軌道と呼ばれる、地球との通信を常時確保できる軌道に建設される予定で、Gatewayもまた月の裏側との中継拠点として活用されることが期待されています。
P2P通信の限界
今日インターネットに生きる私たちにとっては想像に難くありませんが、大量のコンピュータとサーバーが全て1対1で通信をするようなシステムは現実的ではありません。かつてSkypeがP2Pネットワークからクライアント・サーバー型に移行したように、P2Pでの大規模ネットワークはやがてスケーリングの問題に直面します。
まさにこのような問題が上述のDSNでも起きています。2023年8月には、アルテミス計画1の時点ですでにDSNの通信能力が限界を迎えていることが報じられています。DSNの予算が削られているというさらに悪い情報もありますが、そもそも宇宙空間にはすでに大量の探査機、人工衛星が打ち上げられており、その全てとの通信をDSNが捌くというのは明らかに無理があるのです。このような問題が「宇宙でインターネットを形成する」というアイディアにつながるわけですが、これについて次章で詳しく紹介いたします。
宇宙のインターネット
地球上のインターネットは、誰の管轄下に置かれるわけでもなく自律分散的に動作する、政治的・技術的にとても優れた仕組みです。当然宇宙空間でも同じような仕組みを実現したいわけですが、宇宙でインターネットを作るには地球には存在しなかった様々な壁が立ちはだかっています。
地球と宇宙の通信環境の違い
大きく不安定な遅延
私たちがよく、とてつもなく大きな数字を「天文学的」と呼ぶように、宇宙空間では大きさ、重さなど、あらゆる値がとても大きくなります。そしてそれは遅延も同じです。
東京からロサンゼルスまでは光速で約30msとほんの一瞬ですが、地球から月までは光速で約1300msかかります。つまりインターネットでいえば、一つのHTMLファイルをリクエストしてからレスポンスを得るのに最速でも1.3秒かかるのです。Webアプリケーションというのは通常、一つのHTMLファイルだけでなくCSS/JSファイル、大量の画像ファイル、さらにはフォントファイルなどもダウンロードする必要がありますから、あるWebページを満足に閲覧するためにはこれの何倍もの時間がかかることになります。月であればせいぜい10秒ほど待てば良いかもしれませんが、火星と地球は、最も近い時に光速で約3分の距離があり、それより遠い惑星も大量に存在します。これだけで、地球上のインターネットと全く同じシステムを宇宙空間で応用するのが難しいことが想像できるかと思います。
宇宙空間での遅延は大きいというだけでなく、不安定であるという側面を持ちます。上で火星と地球の光速距離について述べたとき、「最も近い時に」と書いたのは、火星と地球の距離というのはその時々で大きく変化するためです。火星の軌道は円形ではなく歪であるため、最も近いときは光速約3分ですが、最も遠い場合は約20分かかります。こういった不安定で大きい遅延が、宇宙におけるインターネットの形成をより一層難しくしているのです。
断続する通信
問題は遅延だけではありません。地球上のインターネットにおいては、あるコンピュータとコンピュータの通信が物理的に不可能というケースはケーブルの断線や人的要因などを除いてほとんどありません。一方、宇宙空間では、通信元と通信先が位置する惑星・衛星の軌道によっては正常状態でも通信が不可能というケースがあり得るのです。
例えば、地球から火星にライブストリーミングをするケースを考えてみましょう。地球上のインターネットと同じように、データは複数のネットワークデバイスを伝って火星に近づいていき、いよいよ火星を周回する人工衛星まで辿り着きました。しかし、ここで目的地のサーバーが衛星から見て火星の裏側にあった場合、衛星はデータの伝送を待つ必要があります。地球のように大量のデバイスが至る所にあれば問題ありませんが、そうなるには長い年月がかかります。その上この問題は衛星-惑星間だけでなく衛星-衛星間にも起きうるため、より根本的な解決が必要なのです。
宇宙のためのインターネット：DTN
上記の問題に対応する、遅延、途絶に柔軟なネットワークシステムの総称をDelay Tolerant Network (DTN)と呼び、様々な標準化団体、組織でDTNの議論と開発が行われています。途絶の意味を加えたDelay-Disruption Tolerant Networkという呼び名もあるらしいですがここでは前者で通すことにします。DTN自体は特定の技術というよりは時間的、空間的に断絶されうる環境に特化したネットワークアーキテクチャの総称であり、議論が行われている組織によって細かな定義は異なります。本書では、IRTFのRFC4838にて議論されている内容を主に紹介します。
IPとの違い
従来のInternet Protocol (IP)では以下のような環境を前提としています。
- 通信の間、2点間の経路が存在し続ける
- 通信エラーへの対処は再送を行うことで解決する
- パケット通信により相互接続性、パフォーマンスが向上する
- データの送信者から受信者への経路は一つ選択すれば十分である
当然これらは、宇宙空間のようなDTNが対象とする環境には当てはまりません。通信における中継ノードはパケットをとにかく速く転送し、信頼性の担保などはエンドノードが担うという仕組み自体が、宇宙空間と親和性が低いのです。これらが宇宙空間でIPを使うことが最適でないことの説明になるわけですが、これを踏まえてDTNアーキテクチャの主要な特徴を以下に紹介します。
可変長のメッセージ
DTNにおいては、伝送するデータをパケットのように決められたサイズに区切ることはしません。少なくとも、IPが位置するようなレイヤで区切ることはありません。これは、一つのデータを送信するためにかかる時間がとても長く、データを細かく区切って届かないものだけ再送するという従来の設計が通用しないからです。それよりも、誤り訂正などを含めてデータサイズが増えたとしても、一度により多くのデータを送ってしまった方がかえって安定するだろうというのがDTNの思想の一つです。
中継点での蓄積伝送（store-and-forward）
地球上でデータを中継するネットワークデバイスは基本的にデータを長い時間保持することはありません。先に少し述べた通り、IPでは、中継ノードはパケットを素早く転送するというのが主目的であるからです。一方、宇宙空間では軌道上の問題で通信が断絶することが多くあります。それに備えて、DTNで動作する中継ノードは、時には外部記憶も用いてデータを一度保持し、転送先ノードと通信可能になったタイミングで転送するというStore-and-forward機能を持ちます。
逐次名前解決
地球上でホスト名とアドレスを紐づけるのはDNSです。通信ノードはデータ送信前にDNSサーバーと通信し名前解決を行いますが、これは事前にDNSサーバーと通信できるという前提ありきの設計です。DTNにおいては、データを送信する際、名前解決をせず識別子のままで転送を行います。その識別子を管理するネットワークのゲートウェイに辿り着いた段階で名前解決を行うこの仕組みは逐次名前解決（Late Binding）と呼ばれています。
これらの特徴をもつDTNは、宇宙空間だけにフォーカスして作られているわけではありません。水中通信や災害を受けた地域など、あらゆる途絶されがちな環境での通信全てに対応可能なように設計されています。
DTNはあくまでネットワークの設計を定義するもので、具体的にはさらに細かな技術コンポーネントに分かれます。その主要な一つがBundle Protocolです。
Bundle Protocol
Bundle Protocol（BP）はDTNの、主にデータ転送の部分を担う主要な技術の一つです。
これまでDTNを紹介する中で、IPとの違いを主軸にしてきたわけですが、BPはIPを置き換えるものではありません。BPは、IPやそれ以外のネットワークプロトコルの上のレイヤでDTNを実現するためのオーバーレイネットワークプロトコルと言えます。とはいえ、一般的にはBPはIPとは共存しないものとして語られることが多いです。
基本的に、プロトコルの目的はDTNのそれと重なりますが、以下でいくつかの具体的な技術要素を紹介します。
Self-Delimiting Numeric Values
BPでは可変長の数値エンコーディングを実現するためにSelf-Delimiting Numeric Values (SDNVs)が採用されています。SDNVsは1バイト以上の可変長でエンコードされますが、その大きな特徴として各SDNVの末尾のバイトが最後のバイトを示すフラグとして使用されることです。これにより受信者はSDNVの長さを事前に知る必要がなく、ストリームから直接デコードすることができます。また値のサイズを示すために余分な1バイトを使うことがないため、限られた帯域を有効活用することができます。
Custody Transfer
BPにはCustodyという概念が存在します。BPにおいてメッセージの1単位をバンドルと呼ぶのですが、このバンドルの転送責任をCustodyと呼びます。あるバンドルのCustodyを引き受けたノードはそのバンドルを次のノードに転送するまで、ロストした際やエラー発生時の再送を行う義務があります。地球上の従来のインターネットでは再送責任を持つのは常に送信元であるサーバーですが、DTNにおいては毎度サーバーまで再送リクエストを送り返していてはキリがありません。各中継ノードがバンドル保持のために永続的なストレージを持ち、バンドルとCustodyをバケツリレーのように渡していくことで、再送のコスト低下と負荷分散を実現しているのです。
エンドポイントID
BPでは、エンドポイントIDという概念を用いて先の逐次名前解決を実現しています。エンドポイントIDはURI形式で表現され、異なるスキームを追加できるなど優れた柔軟性を持ちます。また辞書を用いることで、同じエンドポイントIDを複数回記述することによるデータ量の増加を防ぎます。例えば、バンドルの送信先と通信状況のリポート先が同じ場合、同じIDを2度書くのではなく、辞書にそのIDを持った上でそのオフセット番号をSDNVで記述すれば良いのです。
// 辞書による圧縮がない場合
{
Source Scheme Offset: dtn
Source SSP Offset: example_node
Destination Scheme Offset: dtn
Destination SSP Offset: example_node
Report-To Scheme Offset: dtn
Report-To SSP Offset: example_node
}
// 辞書での圧縮: それぞれのオフセットはSDNV、1バイトで済む場合もある
{
Source Scheme Offset: <offset of 'dtn'>
Source SSP Offset: <offset of 'example_node'>
Destination Scheme Offset: <offset of 'dtn'>
Destination SSP Offset: <offset of 'example_node'>
Report-To Scheme Offset: <offset of 'dtn'>
Report-To SSP Offset: <offset of 'example_node'>
}
これまでDTN、そしてBPの紹介をしてきましたが、BPがRFC5050として標準化されたのは2007年のことです。そこから17年が経ち、BPのような特殊なオーバーレイプロトコルでなくとも、汎用的なプロトコルを適切に設定することで宇宙空間での利用が可能になるのではないかという議論が始まっています。その議論の内容を次の章で紹介します。
宇宙におけるIPの再検討
先にも述べた通り、数多くの理由からIPをそのまま宇宙空間に応用することは難しいです。しかし、既存の汎用的なプロトコルを組み合わせることで、宇宙空間のインターネットを実現できる可能性も指摘されています。IETFのDTN WGから派生したdeepspaceグループでは、IPを宇宙空間で利用するための様々な設計・実装の提案が行われています。ここでは、deepspaceグループのドラフト「Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions」の内容をチェリーピックする形で、IPスタックの宇宙への応用について紹介していきます。
QUICの利用
このドラフトではトランスポート層として利用可能なプロトコルとしてQUICを挙げています。QUICは2022年にIETFにてRFC9000として標準化されたプロトコルで、UDPに輻輳制御やフロー制御機能、暗号化レイヤーを追加することでTCPより柔軟性が高く、同等の信頼性を持つ動作が可能です。QUICはHTTP/3に組み込まれたことでもその知名度を上げましたが、ここではQUICの暗号化と柔軟性に注目して宇宙空間での利用の可能性を論じています。
QUICはそのプロトコルの中にTLSを組み込んでおり、TLS over TCPのような追加のハンドシェイクを要することなく、1RTTで暗号化された通信路の確立が可能です。一度接続が完了すればそのあとは0RTT、つまり生のUDPのようにいきなり送りつけても信頼性の高い伝送が可能になります。これは1RTTの時間的コストが非常に高い宇宙空間にとっては非常に有用であり、IPsecに頼らざるを得なかった17年前とはだいぶ状況が進化していることがわかります。IPsecとの比較で言えば、IPsecはIPパケット全体を暗号化するのに対し、QUIC（TLS）はアプリケーションデータのみを暗号化するため、データ量の効率化という意味でもQUICが勝ります。
また、QUICには、一つの接続で複数のストリームを仮想的に張ることができる多重化ストリームという機能を持ちます。これは互いに依存しないストリームを複数持つことで、TCPに存在したHead-of-Line Blockingと呼ばれる問題を解消することが主な目的ですが、宇宙空間においてはRTTの節約という意味でこの機能が利用され得ます。
例えば、宇宙空間のクライアントが検索のためにGoogleのサーバーとQUICセッションを張り、その後YouTubeを見るために再びGoogleのサーバーと通信を試みるとします。この時、同じGoogleのサーバーならセッションを使い回し、YouTubeのリクエストに対してはハンドシェイクを待たずにデータを送ることができるのです。これは認証などの話を抜きにした理想的なシナリオですが、実際にこのようなアイディアは地球上でも提案されています。
IP転送
宇宙空間においては次の中継ノードにデータを転送するまでに長い時間がかかります。それをstore-and-forwardの仕組みで解決しようというのがDTNのアイディアなわけですが、既存の技術を用いてこの問題にアドレスすることも可能です。
Active Que Management (AQM)
AQMは元々、トランスポートプロトコルにおいて、ルータなど中継ノードのキュー長を制御することでバッファオーバーフローを防ぐ目的で設計された汎用的なキューの制御手法です。これを用いてキューの長さを長く設定することで、AQMは各中継ノードでのstore-and-forwardを実現する一つの構成要素になり得ます。
Bidirectional Forwarding Detection (BFD)
BFDはネットワークの障害を迅速に検出するための汎用的なプロトコルです。BFDでは、2つのノード間でBFDセッションを確立し、定期的に軽量なパケットを双方向で送受信、その欠落を検知して障害を判断します。やっていることは、私たちが、アプリケーションが繋がらないサーバーにpingを打ってみたりすることと同じですが、これは特に通信可能なノードが頻繁に変わる宇宙空間で有用です。実はBPにも同じような、通信状況を報告するためのフィールドがあるのですが、それをBFDで置き換えられる可能性をこのドラフトで論じています。
まとめ
これら以外にも、上述のドラフトやそれ以外の文書でIPの宇宙空間での活用について議論が交わされていますが、DNSやルーティングについては未だIPスタックを利用する良い例はあまり出ておらず、宇宙空間でのインターネットを実現するにはまだBPの方が現実的かなというのが私の個人的な考えです。とはいえIPが使えればその上のあらゆるプロトコルが利用可能になることを意味するため、今後の議論と開発の進展に期待しています。
おわりに
DTNやBPはかれこれ10年以上議論が続いているわけですが、実際に現実の宇宙空間でテストが行われた例はほとんどありません。宇宙でのインターネットに関するRFCやドラフトは年々増加しており、議論を行う団体も人数も増えていますが、その議論が最終的に現実世界にたどり着くことは稀です。地球上で実験可能な技術群と違い、そもそも実験を行えるのがNASAのような巨大な宇宙システムを持つ組織に限られるというのがその大きな理由ですが、やはり机上の空論感が漂ってしまいます。
そもそも、現状の宇宙空間ではインターネットを形成するより先にやるべきことが山積みであるという事実もあります。インターネットを形成するには惑星や衛星にコンピュータを設置する必要がありますが、そもそも基地も出来ていない、基地を建てるための地質調査が進行中という段階でこのような批判を行うことが不毛といえばその通りです。
宇宙×インターネットと言えば聞こえは良いですが、実現までの道のりは天文学的に長く、遠いのです。
