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

宇宙ネットワークの管理 — SNMP/MIBの発想でメガコンステレーション時代の監視を捉える

誰がいつアンテナを使うかというDSNスケジューリングの問題を解決した先で、運用中のネットワーク全体が本当に健全かをどう見張るのかという新しい課題が立ち上がる。地上のネットワーク管理で使われるSNMP/MIB、ポーリングとトラップという2つの情報収集モデルを、数百〜数千機規模の宇宙ネットワークにどう適用するかを整理する。

前提知識: DSN運用スケジューリング — 有限のアンテナを数十のミッションが取り合う資源配分問題

ネットワーク管理SNMPMIBメガコンステレーション運用監視

この回で学ぶこと

DSNスケジューリングの回では、有限個しかないアンテナという物理資源を、数十のミッションがどう取り合うかという資源配分の問題を扱いました。パス要求を可視ウィンドウ・適格アンテナ集合・優先度重みのタプルとして定式化し、「誰が」「いつ」「どのアンテナを」使うかを決める仕組みを見てきました。しかし、スケジュールが確定し、実際にパスが実行され始めた後には、まったく別種の問いが立ち上がります。それは——いま現在、このネットワークを構成する何百・何千という機器は、本当にちゃんと動いているのか、という問いです。

あるアンテナの受信機は信号にロックしているか。あるリンクのビット誤り率(BER)は許容範囲内か。ある中継衛星のバッファは溢れかけていないか。こうした問いに答えるのが**ネットワーク管理(Network Management)**です。地上の企業や大学のIT部門では、ルータやスイッチが数百〜数千台あるネットワークの状態を常時監視するために、**SNMP(Simple Network Management Protocol)**という考え方が何十年も使われてきました。この回では、SNMPが体現している「機器の状態を階層的なデータベースとして表現し、それを問い合わせる、あるいは機器側から能動的に知らせてもらう」という発想を、複数の地上局・複数の探査機・中継衛星からなる複雑な宇宙ネットワーク全体の監視にどう当てはめられるかを整理します。あわせて、前回や地上局自動化の回で見た「探査機は数十機」という規模から、メガコンステレーション時代の「衛星は数千機」という規模へと状況が変わったとき、この監視の仕組みがどのような壁にぶつかるのかも見ていきます。

なお、CCSDSのMission Operations (MO) サービスにおける監視制御サービス(M&C Services)は、1つのミッション運用センター内部でテレメトリパラメータをソフトウェアコンポーネント間でどう受け渡すかというアプリケーション間連携の標準化でした。これに対してこの回で扱うのは、地上局のアンテナ、受信機、中継衛星、リンクといったネットワークインフラそのものの稼働状況を、運用者(あるいは運用ソフトウェア)がどう俯瞰的に把握するかという、一段違うレイヤーの問題です。両者はしばしば同じ運用センターの中で協調しますが、扱う対象が異なる点に注意してください。

直感的な導入: 「誰が使うか」から「ちゃんと動いているか」へ

前回の枠組みでは、スケジューラが「アンテナ $a$ 、時間スロット $[e_r, l_r]$ を要求 $r$ に割り当てる」と決めた時点で、資源配分の問題は解決済みでした。しかし実際にパスが始まると、運用者(あるいは自動化されたシステム)は次のような、まったく別種の疑問に絶えず答え続けなければなりません。

割り当てられたアンテナは、本当に予定通り指向を完了し、信号を捉えているか。
受信機はロック状態を維持しているか、それとも信号を見失いかけているか。
そのリンクの信号対雑音比(SNR)や誤り率は、健全な範囲にあるか。
中継衛星のクロスリンクは輻輳していないか、機器の温度は正常範囲か。

これらはすべて「その時々のネットワークの健全性(health)」に関する問いであり、資源をどう割り当てるかという計画の問題とは独立に、運用中のシステム全体を継続的に見張るという別の営みを必要とします。地上のコンピュータネットワークの世界では、この営みのために1980年代からSNMPという枠組みが広く使われてきました。SNMPの発想はシンプルです。

ネットワーク内の各機器(ルータ、スイッチ、サーバなど)は、自分自身の状態を表す変数の集合を持っている。これを**管理情報ベース(Management Information Base, MIB)**と呼ぶ。
中央の**管理ステーション(manager)が、各機器のエージェント(agent)**にこれらの変数の値を問い合わせる(ポーリング)。
あるいは、機器側が異常を検知したときに、管理ステーションへ自発的に通知を送る(トラップ)。

宇宙ネットワークにおいても、地上局のアンテナ、受信機、探査機のトランスポンダ、中継衛星のクロスリンクといった1つ1つの構成要素を「機器」とみなせば、まったく同じ発想の枠組みを持ち込めます。以下では、この考え方を具体的に定式化していきます。

管理対象のモデル化: 宇宙ネットワークのMIB

まず、監視対象となるネットワーク要素の集合を

E = A \cup L \cup S

とします。ここで $A$ は地上局のアンテナ・受信機系統の集合、 $L$ は探査機・衛星への(あるいは相互の)通信リンクの集合、 $S$ は中継衛星やクロスリンクノードの集合です。各要素 $e \in E$ は、その状態を表す**管理対象オブジェクト(managed object)**の集合 $O_e$ を持ちます。たとえば地上局の受信機 $e$ であれば、

O_e = \{\, \text{ロック状態},\ \text{SNR},\ \text{受信電力},\ \text{フレーム同期率},\ \text{機器温度},\ \dots \,\}

といった具合です。SNMPの世界では、こうしたオブジェクトは木構造(ツリー)の中の一意な経路として識別されます。この経路を**OID(Object Identifier)**と呼び、たとえば「あるアンテナのSNR」は

\text{oid} = (\text{root}).\,\text{groundSegment}.\,\text{antenna}[12].\,\text{receiver}.\,\text{snr}

のように、大分類から個別の値へと階層的に絞り込んでいく経路として表現されます。この木構造こそがMIBです。MIBは単なる変数のリストではなく、「どこに何があるか」を体系的に整理した名前空間である点が重要です。木の上位の枝を、地上のネットワーク管理で標準的に使われるFCAPSという5分類——Fault(障害)、Configuration(構成)、Accounting(記録・課金)、Performance(性能)、Security(セキュリティ)——に沿って整理すると、宇宙ネットワークでも次のように対応づけられます。

FCAPS分類	宇宙ネットワークでの管理対象の例
Fault(障害)	受信機のアンロック、機器故障フラグ、クロスリンク断
Configuration(構成)	アンテナの現在の指向先、受信機の設定周波数、使用中の変調・符号化方式
Accounting(記録)	各ミッションが実際に使用したアンテナ時間、パスごとのデータ取得量
Performance(性能)	SNR、BER、フレーム同期率、スループット
Security(セキュリティ)	コマンド認証の成否、アクセス制御ログ

この分類はITU-T勧告M.3400(TMN Management Functions)に由来する、地上の通信網管理で標準的に使われる整理法ですが、宇宙ネットワークの監視対象を洗い出す際にも過不足なく当てはまります。管理ステーションは、ネットワーク全体の状態を、この木構造にしたがって整理された値の集合

\mathbf{v}(t) = \big\{\, v_{e,o}(t) \;\big|\; e \in E,\ o \in O_e \,\big\}

として把握しようとします。ここで $v_{e,o}(t)$ は時刻 $t$ における要素 $e$ のオブジェクト $o$ の値です。この $\mathbf{v}(t)$ をどうやって最新に保つか、というのが次節の主題です。

ポーリングとトラップ: 2つの情報収集モデル

ポーリング(polling)

最も素朴な方法は、管理ステーションが定期的に各要素へ「今の値を教えてくれ」と問い合わせることです。SNMPではこれをGET操作と呼びます。ポーリング間隔を $T_{poll}$ 、1回のポーリングで問い合わせるオブジェクト数を $k$ 、監視対象の要素数を $|E| = N$ とすると、単位時間あたりに管理ステーションと各要素の間を行き交うメッセージ数はおよそ

\text{message rate} \approx \frac{N \cdot k}{T_{poll}}

のオーダーになります。ポーリングの利点は明快です。管理ステーションが能動的に問い合わせている以上、応答が返ってこないこと自体が「その要素が生きていない(あるいは通信が切れている)」ことの直接的な証拠になるという、暗黙の生存確認(liveness check)が組み込まれています。一方で欠点は、異常の検知が原理的に最大 $T_{poll}$ だけ遅れることと、 $N$ や $k$ が大きくなるとメッセージ量が線形に増え続けることです。しかも宇宙ネットワークでは、地上局から遠く離れた中継衛星や探査機へのポーリングには電波の伝搬遅延(光速で決まる往復時間)が加わるため、 $T_{poll}$ を極端に短くすること自体にも限界があります。

トラップ(trap)

もう1つの方法は、各要素が自分自身で状態を監視し、あらかじめ定めたしきい値を逸脱したときにだけ、要素側から管理ステーションへ自発的に通知を送るというものです。SNMPではこれをTRAPと呼びます。地上局自動化の回で見た、SNRがしきい値 $\theta_{\text{warn}}$ を下回ったときに状態機械がLOCKEDからDEGRADEDへ自動遷移する仕組みは、まさにこのトラップの発想そのものです。

\text{LOCKED} \xrightarrow{\text{SNR}(t) < \theta_{\text{warn}}} \text{DEGRADED} \quad \Longrightarrow \quad \text{要素からトラップを送信}

トラップの通知は、異常の発生というイベント駆動の点過程(point process)としてモデル化できます。健全性が保たれている平常時にはイベント発生率 $\lambda \approx 0$ であり、通信量はほぼゼロです。これはポーリングと対照的に、平常時の帯域コストがほぼゼロで済むという大きな利点をもたらします。特に、伝送容量そのものが限られている深宇宙リンクやクロスリンクにおいて、監視のためだけに常時帯域を消費するポーリングよりも、トラップの方が資源効率で有利になる場面は多くあります。

しかしトラップには本質的な弱点があります。要素が完全に沈黙してしまった場合(電源断、通信途絶、ソフトウェアのクラッシュなど)、そもそもトラップを送る主体自体が機能していないため、管理ステーション側は「異常が起きていない」のか「異常すぎて報告すらできない」のかを区別できません。この問題を解決するために、実際のSNMP運用ではトラップだけに頼らず、低頻度なハートビート的ポーリング(生存確認だけを目的とした、間隔の長いGET)を組み合わせるのが定石です。つまり実務上は、次のようなハイブリッドモデルが採用されます。

\text{監視} = \underbrace{\text{低頻度ポーリング(生存確認)}}_{\text{要素が生きているかを保証}} \;+\; \underbrace{\text{トラップ(異常の即時通知)}}_{\text{平常時の帯域コストを抑制}}

地上局自動化の回で見た健全性指標ベクトル $\mathbf{h}(t)$ の継続監視と、しきい値超過によるFAULT状態への自動遷移・遠隔アラート発報は、このハイブリッドモデルの一実装例として理解できます。

規模の壁: メガコンステレーション時代の監視問題

これまでの深宇宙探査の運用は、多くても数十機のミッションを、経験豊富な運用者が比較的少数のアンテナと突き合わせながら監視する、という規模で成り立ってきました。前回で扱ったDSNのスケジューリング問題も、ミッション数十・アンテナ十数基という規模を前提にしていました。

しかし、地球周回の商業衛星コンステレーションでは事情がまったく異なります。2020年代に運用が本格化した大規模な低軌道通信衛星群は、1つの事業者だけで数千機規模の衛星を同時に運用するに至っています。この規模になると、前節で述べた素朴なポーリングモデルがどれほど非現実的になるかを、具体的な数字で確認してみましょう。

かりに $N = 5{,}000$ 機の衛星それぞれについて、 $k = 50$ 個の健全性パラメータ(電源状態、姿勢、リンクロック状態、温度など)を $T_{poll} = 1$ 秒間隔でポーリングしようとすると、

\frac{N \cdot k}{T_{poll}} = \frac{5{,}000 \times 50}{1\,\text{s}} = 250{,}000 \ \text{メッセージ/秒}

というオーダーのやり取りが、中央の管理ステーション1か所に集中することになります。これは通信帯域の観点でも、管理ステーション側の処理能力の観点でも、現実的に破綻する規模です。しかもこれは監視対象を非常に控えめに見積もった数字であり、実際の衛星は数百のテレメトリパラメータを持つのが普通です。

この壁を越えるために、地上のネットワーク管理でも用いられてきたのが階層化という発想です。すべての要素を単一の中央管理ステーションが直接ポーリングするのではなく、

地域ごと・機能ごとにまとまった要素群に対して、**局所的な管理エージェント(中間ノード)**を配置する。
中間ノードは、自分が担当する要素群を高頻度で監視し、平常時はその集約された健全性サマリ(たとえば「担当する100機のうち99機は正常」)だけを、より低頻度で上位の管理ステーションへ報告する。
個別要素で異常(トラップ)が発生した場合だけ、その詳細情報が中間ノードを経由して上位へエスカレーションされる。

これはITU-T勧告が定めるTMN(Telecommunications Management Network)の管理階層——ネットワーク要素層・要素管理層・ネットワーク管理層・サービス管理層——の考え方そのものであり、地上局自動化の回で見た「無人局に運用者を常駐させるのではなく、異常時にだけ遠隔の運用者を呼び出す」という発想を、単一の運用者と多数の無人局の関係から、多段階の管理階層全体へと一般化したものだと理解できます。中央の管理ステーションが把握すべき情報量は、要素数 $N$ そのものではなく、「各中間ノードの集約サマリの数」というはるかに小さいオーダーに抑えられます。

実務での使われ方

地上の情報通信網でのSNMP。 SNMPはIETFのRFC 1157(1990年)で標準化され、MIB-IIがRFC 1213で規定されて以来、ルータ・スイッチ・サーバ・プリンタに至るまで、地上のIT機器の監視でほぼ普遍的に使われてきたプロトコルです。GET・GETNEXT・SET・TRAPという少数の操作だけで、階層的なMIBツリーの任意の場所にある値を読み書きできるというシンプルさが、長年にわたって使われ続けている理由の1つです。宇宙ネットワークの監視設計を考える技術者にとって、SNMP/MIBはまさに「巨大で異種混在なシステムの状態を、どう体系的に扱うか」という問題に対する、数十年分の実運用実績を持つ参照モデルになっています。

CCSDS XTCE(XML Telemetric and Command Exchange, CCSDS 660.0-B)。 個々の探査機・衛星が持つテレメトリパラメータを、階層的な名前空間を持つデータベースとして記述する標準規格で、CCSDSによって定められています。1機の探査機について「どんなパラメータがあり、それぞれどう解釈すべきか」を体系的に定義するという点で、宇宙分野におけるMIBの発想の実例と言えます。ただしXTCEが記述するのは基本的に1機の探査機の内部構造であり、この回で扱った「複数の地上局・複数の衛星からなるネットワーク全体」を横断する管理情報ベースとは、対象とする範囲が異なる点には注意が必要です。

ESAのSCOS-2000における限界値監視(Out-of-Limit checking)。 ESAのミッション制御システムSCOS-2000は、受信したテレメトリパラメータの値をあらかじめ設定した限界値と常時比較し、逸脱を検知すると自動的にアラームを発報する仕組みを持っています。これは本文で述べたトラップの考え方を、探査機のテレメトリ監視という文脈で実装したものです。

DSNのモニタ&コントロール(M&C)システム。 地上局自動化の回で触れたように、NASAのDSNでは複数のアンテナの状態を1か所の運用管制室から統合的に監視するM&Cシステムへの移行が進められてきました。個々のアンテナ・受信機の健全性指標を集約し、オペレータのコンソールに統合的に提示するという構成は、本文で述べた階層化された監視アーキテクチャの実例です。

メガコンステレーション事業者の運用センター。 数千機規模の衛星を運用する商業コンステレーション事業者は、個々の衛星の健全性を人間が逐一確認することを前提とせず、衛星自身がオンボードで異常を検知して地上へトラップ的に通知する仕組みと、統計的・機械学習的な異常検知アルゴリズムによる自動化されたアラート選別を組み合わせて運用している。数千機のうち大多数が正常に動作している状況で、真に人間の判断を要する少数の異常だけを浮かび上がらせるという設計思想は、本文で述べた「ハイブリッドモデル」と「階層化」の発想を、より大規模かつ高度に自動化した形で実践したものだといえます。

演習問題

ある地上局ネットワークが $N = 20$ 局のアンテナを持ち、各局につき $k = 30$ 個の健全性パラメータを $T_{poll} = 5$ 秒間隔でポーリングしているとする。1メッセージ(GET要求とその応答のペア)のサイズを平均200バイトとして、このポーリングが生成する平均通信量(バイト/秒)を概算せよ。また、この局数が10倍の200局に増えた場合、通信量はどう変化するか説明せよ。
前問と同じ200局のネットワークについて、代わりにトラップベースの監視に切り替え、1局あたり平均して1時間に1回程度の頻度でしきい値逸脱イベントが発生するとする。この場合の平均メッセージレート(メッセージ/秒)を概算し、問1のポーリングベースの通信量と比較せよ。トラップベースの方が明らかに有利に見えるにもかかわらず、実務でポーリングを完全に廃止できない理由を、本文の議論に基づいて説明せよ。
ある地上局の受信機について、次の3つの管理対象オブジェクトのMIBツリー(階層)を設計せよ: (a) ロック状態(真偽値)、(b) SNR(数値、dB単位)、(c) 機器温度(数値、摂氏)。本文中のOID表記の例を参考に、「地上局セグメント→アンテナ→受信機→各パラメータ」という経路で階層を示し、FCAPSのどの分類に属するかもあわせて答えよ。
本文中で計算した「 $N=5{,}000$ 機、 $k=50$ 、 $T_{poll}=1$ 秒で毎秒25万メッセージ」という数字について、階層化されたアーキテクチャを導入することで中央管理ステーションが扱うメッセージ量をどのように削減できるか、本文中の3段階の階層化プロセスに沿って説明せよ。また、この階層化が地上局自動化の回で述べた「正常系は自動化し、例外系だけ人間に委ねる」という設計思想とどう対応しているか論じよ。

まとめと次回予告

この回では、前回までに扱ってきた「誰がいつアンテナを使うか」という資源配分の問題から視点を移し、運用中の宇宙ネットワーク全体の健全性をどう継続的に監視するかという問題を扱いました。地上のネットワーク管理で使われるSNMP/MIBの発想を借り、地上局・リンク・中継衛星といったネットワーク要素の状態を階層的なMIBツリーとして整理し、FCAPSという5分類で管理対象を体系づけました。そのうえで、管理ステーションが情報を収集する2つのモデル——定期的に問い合わせるポーリングと、異常時に要素側から能動的に知らせるトラップ——それぞれの利点と限界を比較し、実務では両者を組み合わせたハイブリッドモデルが使われることを見ました。さらに、探査機数十機の時代からメガコンステレーションの数千機の時代へと規模が変わったとき、単純な中央集権的ポーリングが具体的にどう破綻するかを数字で確認し、TMNの管理階層に基づく階層化がこの壁を越える手段であることを整理しました。

次回は、この監視の話とは少し毛色を変えて、宇宙ネットワークにおけるマルチキャスト配信に軽く触れます。1つの探査機や1本のリンクを対象にしたこれまでの議論とは異なり、同じデータを複数の受信者(複数の地上局や複数の衛星)に効率よく配る、という「1対多」の通信の考え方を紹介します。

参考文献

J. Case, M. Fedor, M. Schoffstall, J. Davin, A Simple Network Management Protocol (SNMP), RFC 1157, IETF, 1990
K. McCloghrie, M. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, RFC 1213, IETF, 1991
D. Harrington, R. Presuhn, B. Wijnen, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks, RFC 3411, IETF, 2002
ITU-T Recommendation M.3400, TMN Management Functions
CCSDS 660.0-B-2, XML Telemetric and Command Exchange (XTCE), Blue Book
ESA, SCOS-2000 Mission Control System, Product overview documentation
DSN Telecommunications Link Design Handbook, DSN No. 810-005
J. R. Wertz, D. F. Everett, J. J. Puschell (eds.), Space Mission Engineering: The New SMAD