JP2000341329A - 衛星リンクを動的に割り当てるための方法及び装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】衛星リンクを動的に割り当てる方法を提供する
こと。 【解決手段】複数のクライアントと、ネットワークを介
して送られてきた要求に応じて衛星通信受信手段にＩＰ
アドレスを割り振る管理サーバとを含む通信システムに
おいて、クライアントの固有情報を格納するステップ
と、管理サーバとの間にリンクを確立するステップと、
格納固有情報に基づき、所与のクライアントに衛星リン
クを動的に割り当てるステップと、割り当てた衛星リン
クに対応するＩＰアドレスを送信するステップと、を含
む、衛星リンクを動的に割り当てるための方法が提供さ
れる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般には衛星リンク
を利用した通信に関するものであり、特にクライアント
からの要求に応じて、そのクライアントに衛星リンクを
動的に割り当てるための方法および装置に関する。

【０００２】

【従来の技術】インターネットの需要は高まる一方であ
りながら、そのネットワークの帯域、特にダイアルアッ
プを用いたインターネット利用者宅への回線の帯域が限
られているために、ユーザは満足なサービスを受けるこ
とが出来なく不満を募らせている。また、専用線接続を
行っているユーザにとっては、回線費用に対する投資を
なるべく抑えたいという要望が強いため、必要な帯域分
の専用線を引けないという問題が生じている。更にコン
テンツ提供者は自らのコンテンツを見栄えの良いものに
するため、あるいは、新しいサービスの提供として、画
像や音声など、従来の情報に比べて大きなデータの送信
を要望する傾向にある。これにより、益々ユーザにとっ
て必要とされるネットワーク帯域が広がりつつある。

【０００３】このような状況下において、新たなネット
ワーク基盤として、帯域の大きさ、広域性などを特徴と
した衛星の利用が注目されてきている。しかし、ユーザ
側設備として、通常、ユーザは送信機能のない衛星電波
受信装置（衛星受信アンテナ、アンテナ接続ボード、セ
ットトップ・ボックスなど）だけを装備する。この時、
インターネットのように、オンデマンド型の通信基盤に
おいては、双方向通信が前提となるためこれだけでの利
用は不可能である。従って、衛星リンクを双方向に見立
てるために、ユーザの衛星受信装置を持つクライアント
・マシンに何らかの仕組みを導入しなければならない。

【０００４】従来、衛星電波を発信する装置を持たない
端末が衛星通信を行う場合、次のような4種類の方式ａ
〜ｄが存在する。

【０００５】ａ．これは、クライアント・マシンが衛星
から流れて来るデータを受信するだけの方式である。こ
のタイプは、ＴＶ放送の形態に近く、インターネットな
どで基本となるオンデマンド性は全く無い。ただし、構
成は最も簡単である。これは、たとえば「片方向通信レ
シーバ」と呼ぶことができる。

【０００６】ｂ．クライアント・マシンが衛星電波受信
装置以外の安価なモデムと電話回線などを利用して決め
られたサイトにダイアルアップを行って、そのサイトに
あるデータに関してのみ送信要求できる方式である。こ
れは、比較的容易な構成であり、衛星という基盤をイン
トラネットの一部として利用したい時など有効である。
しかし、インターネットのような広域ネットワークでは
使えない。これは、たとえば「サイト・ローカル・レシ
ーバ」と呼ぶことができる。

【０００７】ｃ．上記のｂと同様、決められたサイトに
ダイアルアップを行い、そのサイトにある仲介代理サー
バ(プロキシ・サーバ)にデータ配信要求を行うと、その
代理サーバがサイト外の目的のサーバ（ターゲット・サ
ーバ）からデータを受け取りこれを衛星経由で配信し、
レシーバは間接的に通信を行うが結果的に双方向の衛星
通信をしているように見せかける方式である。この形態
は、イントラネットなどのように閉じられた環境下で使
えるだけでなく、インターネット・サービスなどでも利
用できる。しかし、クライアントからのリクエストは代
理サーバが処理可能なサービス品目に依存するため、利
用できるサービスには制限がある。その上、サイト・ロ
ーカル・レシーバ同様、決められたサイトに必ずダイア
ルアップしなければならないだけでなく、クライアント
はターゲット・サーバのロケーションに関係なくダイア
ルアップ・サイトのネットワークを必ず通過するため、
ネットワーク構成上無駄が生じることは否めない。これ
は、たとえば、「代理サーバ経由レシーバ」と呼ぶこと
ができる。

【０００８】ｄ．前述のｂ及びｃと同様、モデムやター
ミナル・アダプタ（ＴＡ）と電話回線などを利用する
が、これは、その地上線を疑似的に衛星電波の送信（上
り）回線として用いることで、クライアントが直接ター
ゲット・サーバに要求を送信する完全な双方向通信をエ
ミュレーションする方式である。このタイプは、たとえ
ば、「双方向通信エミュレーション・レシーバ」と呼ぶ
ことができる。これは本発明でも利用しているため、以
下で詳細に述べる。

【０００９】衛星リンクを双方向リンクに見立ててイン
ターネットとも融合できる汎用的な高帯域のリンクの一
部として利用する、つまり衛星通信を完全なＩＰ（イン
ターネット・プロトコル）通信基盤として利用するに
は、上記のｄ方式を採用する必要がある。

【００１０】１．クライアント要件 ユーザが準備するハードウェアは、モデムやＴＡなどの
通信機器を電話回線と組み合わせることで実現する地上
線用の双方向リンク・インターフェース（以下、ＢＤＬ
−ＩＦという）と受信専用の衛星受信ボードとを装備し
たクライアント・マシン、又は、ＢＤＬ−ＩＦ及びアン
テナ接続インターフェースを持つ衛星受信装置（以下、
双方をまとめてクライアント・マシンという）である。
クライアント・マシンの設定としては、ＢＤＬ−ＩＦの
ＩＰアドレスだけでなく、衛星受信ボードや衛星受信装
置のアンテナ接続インターフェースなどの片方向リンク
・インターフェース（以下、ＵＤＬ−ＩＦという）にＢ
ＤＬ−ＩＦのＩＰアドレスとは異なるＩＰアドレスを設
定する。このアドレスは衛星通信事業者や衛星通信シス
テムを構築する担当者などの衛星通信提供者（以下、単
にサービス提供者という。これはいわゆるインターネッ
ト・サービス・プロバイダＩＳＰとは異なる）が管理す
るアドレス・プールから割り当てられる。

【００１１】クライアント・マシンの経路制御テーブル
に関しては、ＵＤＬ−ＩＦをＩＰパケット送信用の優先
（デフォルト）インターフェースにするように設定す
る。これにより、通常のＩＰパケットはＵＤＬ−ＩＦに
向けてＩＰパケットを送出するようになるが、この目的
は、ＵＤＬ−ＩＦドライバ上位のＴＣＰ／ＩＰ層が自ら
の要求パケットをＵＤＬ−ＩＦから送出したように見せ
ることにある。この時、当然、受信専用のＵＤＬ−ＩＦ
はＩＰパケットの送出はできないため、ＵＤＬ−ＩＦに
成り代わってこれを送出するためのＢＤＬ−ＩＦをユー
ザが静的に、あるいは、何らかの仕組みを用いて動的に
選び設定する。選ばれた地上線からはターゲット・サー
バへの要求パケットが送出されるが、示された送信元ア
ドレスは、ＵＤＬ−ＩＦのアドレスが使われている。

【００１２】クライアント・マシンのソフトウェア要件
としては、上記にある、ＵＤＬ−ＩＦに成り代わってパ
ケットを送出する仕組みを実現するため、図１に示すよ
うに、送出時、ＩＰ層からＵＤＬ−ＩＦのデータリンク
層にＩＰパケットが渡される瞬間に出力ＩＰパケットを
予め選ばれているＢＤＬ−ＩＦのデータリンク層に受け
渡し（フックし）、そのインターフェースからパケット
を送出する機能を持たせる。この仕組みはＵＤＬ−ＩＦ
のデータリンク層の機能の一部としてＩＰ層とＵＤＬ−
ＩＦドライバの間に位置する実装となる。

【００１３】ネットワーク要件として満たさなければな
らないことは、クライアント・マシンは地上線経由でタ
ーゲット・サーバにＩＰ到達性を確保するということだ
けであり、片方向通信レシーバやサイト・ローカル・レ
シーバなどのように決められたサイトにダイアルアップ
する必要はない。

【００１４】以上のシステムは、ユーザが日常用いてい
るＴＣＰ／ＩＰアプリケーションの変更を必要とせず、
また、クライアントが装備している地上線用インターフ
ェースのハードウェアやドライバなどの変更も必要とし
ない。従って、クライアントの変更を最小限に抑えられ
る事も大きなメリットである。

【００１５】２．データの流れ クライアント・マシンは送信元としてＵＤＬ−ＩＦのア
ドレスを示したパケットを任意のターゲット・サーバに
ＢＤＬ−ＩＦ経由で送出する。宛先（送信先）となるタ
ーゲット・サーバはこのＩＰパケットを受け取り、送信
元ＩＰアドレスがサービス提供者が管理するアドレス・
レンジの一部であることを自ら、あるいは上位ルータの
経路制御テーブルから知り、それらへの経路はサービス
提供者のサイトを指し示しているため、返答パケットを
サービス提供者の持つ境界ルータに転送し、それをフィ
ードと呼ばれる衛星電波発信装置が接続されているルー
タ（以下、フィード・ルータという）に送るか、あるい
はフィードがルータのときは直接フィードに送る。フィ
ード・ルータ又はフィードはこれを衛星信号分割機（マ
ルチプレクサ）経由でトランスポンダ（衛星）に向けて
送信し、最終的にリクエストをしたクライアント・マシ
ンのＵＤＬ−ＩＦに届けられる。これより、衛星リンク
を双方向性のあるネットワークに見立てることが可能と
なる。

【００１６】特開平９−２５２２７１号公報は、上述の
ような衛星を利用したＩＰパケット通信の一手法を開示
している。それによれば、クライアントＰＣからサーバ
にＩＳＤＮを介してサービスの要求を示すＩＰパケット
を送信するとき、データ・リンク層（ＮＤＩＳ層）にお
いて、送信元のＩＰアドレスをＩＳＤＮカード（ＢＤＬ
−ＩＦ）のアドレスからＳＴＴＨカード（ＵＤＬ−Ｉ
Ｆ）のアドレスに書き換える。サーバは、ＳＴＴＨカー
ドのアドレスを送信先アドレスとして、アンテナ及び通
信衛星を介して、要求に応じたＩＰパケットをクライア
ントＰＣのＳＴＴＨカードに送信する。

【００１７】

【発明が解決しようとする課題】上述のようにして、衛
星リンクを双方向のネットワークに見立てる仕組みを構
築する場合、サービス提供者は全てのクライアント・マ
シンに専用のＩＰアドレスを準備してそれを各ユーザに
告知し、ユーザは自身でそれを静的に設定しなければな
らない。これはＩＰアドレスの浪費につながるだけでは
なく、ユーザの設定ミスによるトラブルを引き起こす可
能性も高い。また、ユーザによるＩＰアドレスの無断使
用／誤使用を防御することも困難である。

【００１８】更に、サービス提供者にとっては、新規ユ
ーザの登録だけではなく、ユーザが衛星通信サービスの
契約を解約した際などは、そのＩＰアドレスを確実に回
収して別のユーザにこのアドレスを割り当てるなど再利
用を正しく行わなければならない。つまり、サービス提
供者は個々のＩＰアドレスとユーザ情報の管理を常時行
わなければならず、ユーザが増大していくと、膨大な数
のアドレスを予約するだけではなく、これらの管理に多
大な労力が必要となり、きめ細かな運用は現実的なもの
ではなくなる。

【００１９】また、これは常時使用され得る衛星リンク
を確保していることに他ならず、効率的に衛星回線資源
を利用できなかったり、あるいは受信拠点数（クライア
ント・マシン数）の増加に迅速に対応できないといった
問題をも引き起こす。つまり、衛星リンクの使用量を完
全に把握する、あるいは、将来の使用率を適切に見積も
ることが困難であるため、不十分な衛星リンク（資源）
をユーザに割り当ててしまったり、逆に、余裕を持ち過
ぎた衛星リンクを割り当ててしまうことで資源の浪費に
つながる可能性もある。

【００２０】また、サービスに拡張性を持たせるため、
あるいはセキュリティに考慮するため、全ユーザ（クラ
イアント・マシン）に対して一つの衛星リンクを共有さ
せるのではなく、ユーザの契約や使用するネットワーク
の種類に応じて衛星リンクを分割したいという要望が出
てきたとしても、上記と同様、予め将来的な構想も含め
て全てを把握した最適な衛星リンクを事前に割り振るこ
とは不可能であるため、衛星リンクの分割さえも困難な
ものとなる。

【００２１】これらの問題により、衛星通信が既存のネ
ットワークの一部として、またはインターネットの一部
として一般ユーザ（エンドユーザ）にまで広がることは
困難とされていた。

【００２２】従って本発明の目的は、衛星リンクを効率
よく管理するために、衛星リンクを動的に割り当てる方
法及び装置を提供することにある。

【００２３】本発明の他の目的は、通信衛星を用いてＩ
Ｐ通信を行なう際に、多くのエンドユーザが既存のマシ
ンと廉価な受信専用衛星ボード、又はセットトップ・ボ
ックスのようなアンテナ接続インターフェースを持つ衛
星受信装置を使って広帯域の衛星リンクを最適に利用で
きるようにするとともに、サービス提供者にとっては、
効率的に衛星回線を制御でき、かつ、衛星資源を有効活
用できるようにすることにある。

【００２４】

【課題を解決するための手段】衛星リンクに双方向性を
持たせる事ができても、上記の課題を克服しなければ衛
星通信サービスを一般化することはできない。そこで本
発明は、衛星リンクをインターネットや企業ネットワー
ク（イントラネット）の一部として汎用的に利用するた
めの衛星リンク構成プロトコル（以下、ＳＬＣＰとい
う）を使用した方法及び装置を提供する。ＳＬＣＰは、
膨大な数の衛星通信ユーザ（クライアント・マシン）を
効率良く収容することを可能とするプロトコルであり、
サービス提供者により準備された衛星回線を、それぞれ
のクライアント・マシンに応じた適切な衛星リンク用Ｉ
Ｐアドレスとして、サービス提供者が衛星ボードなどの
衛星通信受信手段に動的に割り振るというものである。
更に、クライアント・マシンは管理サーバによりステー
タス管理を行われるため、クライアント自身が使用を中
断する意向を示すか、又は管理サーバが使用していない
と判断すると、割り振られたＩＰアドレスを解放して衛
星回線の資源の回収を行なうことができ、必要とするク
ライアントだけが衛星回線を利用するといった効率性を
実現する。

【００２５】従って本発明の１態様によれば、それぞれ
が衛星通信受信手段及びネットワーク通信手段を有する
複数のクライアントと、所与のクライアントからネット
ワークを介して送られてきた要求に応じて該所与のクラ
イアントの衛星通信受信手段にＩＰアドレスを割り振る
管理サーバとを含む通信システムにおいて、前記複数の
クライアントの固有情報を格納するステップと、所与の
クライアントの要求に応じて該所与のクライアントと前
記管理サーバとの間に前記ネットワークを介するリンク
を確立するステップと、前記要求に応じて、前記所与の
クライアントの格納されている固有情報に基づき、前記
管理サーバにより前記所与のクライアントに衛星リンク
を動的に割り当てるステップと、割り当てた衛星リンク
に対応するＩＰアドレスを前記管理サーバから前記ネッ
トワークを介して前記所与のクライアントに送信するス
テップと、を含む、衛星リンクを動的に割り当てるため
の方法が提供される。

【００２６】更に本発明の別の態様によれば、それぞれ
が衛星通信受信手段及びネットワーク通信手段を有する
複数のクライアントを含む通信システムにおいて、所与
のクライアントからネットワークを介して送られてきた
要求に応じて該所与のクライアントに衛星リンクを動的
に割り当てるための装置であって、前記複数のクライア
ントの固有情報を格納する手段と、所与のクライアント
の要求に応じて該所与のクライアントとの間に前記ネッ
トワークを介するリンクを確立する手段と、前記要求に
応じて、前記所与のクライアントの格納されている固有
情報に基づき、前記所与のクライアントに衛星リンクを
動的に割り当て、該割り当てた衛星リンクに対応するＩ
Ｐアドレスを前記所与のクライアントに送信する手段
と、を含む、衛星リンクを動的に割り当てるための装置
が提供される。

【００２７】このように、本発明では、衛星回線という
資源の割当てが最良の形で行え、管理サーバによる資源
の中央集中管理によって運用も効率良く行えるため、サ
ービス提供者が必要としていたコストも大幅に削減で
き、ユーザにも多大に還元されることが可能となる。こ
のようなメリットも、クライアント・マシンの変更が大
幅に必要となるものでは一般に受け入れられない恐れが
ある。しかし、本発明によるＳＬＣＰは衛星受信専用イ
ンターフェースのデータリンク層の機能として実現でき
るため、クライアントの変更は最小限に抑えられる点も
特筆すべきことである。

【００２８】

【発明の実施の形態】以下で説明するＳＬＣＰの通信方
法としては、インターネットの標準規格であるＲＦＣ１
６６１に定義されている２地点間プロトコル（ＰＰＰ）
の概念を元に、個々のユーザが使う衛星リンクを、必要
な時に動的に確立する仕組み、及び、その使用が終了し
た時には自動的に資源の回収を行う仕組みを基本とす
る。ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔ
ｓ）は、ＵＲＬ「ftp：//ftp.isi.edu/in-notes/rfcXXX
X.txt」で見ることができる。「XXXX」はＲＦＣの番号
を示す。まず図２を参照しながら、本発明を適用可能な
通信システムの概略構成について説明する。

【００２９】図２において、通信システム１は、広域ネ
ットワーク（ＷＡＮ）、インターネットなどのネットワ
ーク１０を介して相互に通信するサーバ１２、１４及び
クライアント・マシン（以下、単にクライアントとい
う）１６、１８と、通信衛星２０とを含む。サーバ１２
は、ＳＬＣＰのサーバ・モジュールＳＬＣＰＳが導入さ
れている管理サーバないしＳＬＣＰサーバ（ＳＬＣＰＳ
１）である。これに対して、クライアント１６、１８
は、ＳＬＣＰのクライアント・モジュールＳＬＣＰＣが
導入されているＳＬＣＰクライアント（ＳＬＣＰＣ１、
ＳＬＣＰＣ２）である。ＳＬＣＰＳ及びＳＬＣＰＣの詳
細については後で説明する。サーバ１４は、たとえばク
ライアント１６、１８からの要求に応じるウェブ・サー
バである。

【００３０】クライアント１６は、公衆回線網２２に接
続するための、モデムやＴＡなどのデータ通信装置（Ｄ
ＣＥ）２４と、通信衛星２０からの電波を受信するため
の受信アンテナ２６とを備えている。ＤＣＥ２４はクラ
イアント１６のネットワーク通信部２８に接続され、ア
ンテナ２６は衛星通信受信部３０に接続される。同様
に、クライアント１８も、ＤＣＥ３２、受信アンテナ３
４、ネットワーク通信部３６及び衛星通信受信部３８を
備えている。ネットワーク通信部２８及び３６は、いず
れも双方向リンク・インターフェースであり、従ってそ
れぞれ「ＢＤＬ−ＩＦ１」及び「ＢＤＬ−ＩＦ２」で示
されている。これに対して、各クライアントの衛星通信
受信部３０及び３８は、通信衛星２０からの電波を受信
するだけの片方向リンク・インターフェースであり、従
ってそれぞれ「ＵＤＬ−ＩＦ１」及び「ＵＤＬ−ＩＦ
２」で示されている。衛星通信受信部３０及び３８は、
たとえば衛星ボードにより実現され、その内部には、セ
キュリティの観点から、ユーザがアクセスできない固有
の衛星ボードＩＤがハードウェア的に埋め込まれてい
る。これについては後で説明する。

【００３１】ＳＬＣＰサーバ１２は、ポリシーの異なる
ネットワークをつなぐための境界ルータ４０を介してネ
ットワーク１０に接続され、ウェブ・サーバ１４はルー
タ４２を介してネットワーク１０に接続される。４４
は、「フィード」と呼ばれる衛星電波発信装置で、たと
えば境界ルータ４０から受け取ったＩＰパケットを衛星
信号多重器（ＭＵＸ）４６経由で通信衛星２０に向けて
送信する。このＩＰパケットは、最終的には、リクエス
トをしたクライアントのＵＤＬ−ＩＦに届けられる。Ｓ
ＬＣＰサーバ１２、境界ルータ４０、フィード４４、Ｍ
ＵＸ４６及び送信アンテナ４８は「サービス提供者」を
構成している。それらの間の接続は、たとえばＬＡＮの
形態をとってもよい。なお図２には示していないが、通
信システム１は、クライアント１６及び１８の固有情報
（後で説明する）を格納したユーザ・データベースを備
えている。このユーザ・データベースは、ＳＬＣＰサー
バ１２又はそれに関連した認証サーバに実装される。

【００３２】次に、図３のフローチャートを参照しなが
ら、図２に示した通信システム１の動作について詳しく
説明する。図３に示されている「認証サーバ」は、以下
で説明する認証手続きを実行するサーバで、図２には示
されていないが、これはＳＬＣＰサーバ１２と同じでも
よく、またそれとは別のサーバであってもよい。

【００３３】クライアント１６及び１８は、図３のフロ
ーを開始する前に初期設定しておく必要があるので、ま
ずこの初期設定について説明する。各ＳＬＣＰクライア
ントは、予めユーザに告知されている「ユーザ情報（ユ
ーザＩＤ、パスワード等）」及び「ＳＬＣＰサーバ」を
自身の記憶装置（図示せず）内のＳＬＣＰＣ定義ファイ
ルに記述して記憶させておく。複数のＢＤＬ−ＩＦ（地
上線用インターフェース）を持つＳＬＣＰクライアント
の場合、ＳＬＣＰサーバ（ＳＬＣＰＳ１）１２と通信す
るＢＤＬ−ＩＦも一つ選んでおく。また、必要に応じ
て、常時ＢＤＬ−ＩＦを送受信に使うような送信先の一
覧もクライアントに定義しておき、特定の通信相手に対
してはＳＬＣＰの使用如何に限らず衛星リンクを経由し
ない通信を実現できる状態にしておく。これは、経路制
御テーブルで実現できる。ＳＬＣＰサーバ１２への経路
は必ずＢＤＬ−ＩＦを用いるように自動設定される。

【００３４】この後、各クライアントは任意のサイトに
ダイアルアップを行って各ＢＤＬ−ＩＦにＩＰアドレス
を割り当てる。この時共に地上線を用いた双方向性リン
クＢＤＬが確立されたことになる。この状態は、地上線
を用いてＳＬＣＰのサーバー・モジュールであるＳＬＣ
ＰＳを起動しているＳＬＣＰサーバー（ＳＬＣＰＳ１）
１２とＩＰ通信到達性を確立したことに他ならない。

【００３５】上記の環境が整った後、サービスを要求す
るクライアント（ＳＬＣＰＣ１、ＳＬＣＰＣ２）はＳＬ
ＣＰＣモジュールを起動して、最初のステップ１００で
ＳＬＣＰＣ接続要求を出し、次のステップ１０１でＢＤ
Ｌが確立されているかどうかを見る。上述の初期設定で
ＢＤＬが確立されていると、ステップ１０２へ進んでＳ
ＬＣＰ接続を開始し、さもなければ、ステップ１１０に
ジャンプしてＳＬＣＰＣを終了する。ＳＬＣＰ接続を開
始すると、ＴＣＰ上でのＰＰＰ（ＰＰＰ ｏｖｅｒ Ｔ
ＣＰ）を用い、ＲＦＣ１６６１に書かれたフェーズ・ダ
イアグラムに従って状態遷移を行う。具体的には、正常
な場合の一連の状態としては、リンク確立フェーズによ
ってＳＬＣＰＣとＳＬＣＰＳのリンク確立を行い（ステ
ップ１０３及び２００）、次に認証フェーズによってＳ
ＬＣＰＣの認証が行われ（ステップ１０４、２０１、２
０２及び２０３）、最後にＲＦＣ１３３２のＩＰＣＰに
準拠したネットワーク層プロトコル・フェーズによって
ＩＰアドレス情報がＳＬＣＰＣに渡される。本発明に従
う衛星リンクの動的割り当ては、認証フェーズとネット
ワーク層プロトコル・フェーズとの間で行われる。

【００３６】ＳＬＣＰＣのリンク確立要求ステップ１０
３でリンク・デッドが検出された場合は、リンクを確立
できないので、終了ステップ１１０に進む。また、ＳＬ
ＣＰＳのステップ２００でリンク確立が不可の場合は、
ＳＬＣＰＣ終了処理ステップ２０８に進む。ＳＬＣＰＣ
のクライアント認証開始要求ステップ１０４は、当該ク
ライアントの固有情報である認証データをＳＬＣＰＳに
送る。この認証データとしては、前述のユーザ情報及び
衛星ボードＩＤの他に、ユーザとサービス提供者との間
の契約情報を表すＩＤ（契約サービスＩＤ）を定義する
こともできる。認証データを受け取ったＳＬＣＰＳは、
ＳＬＣＰサーバ又はＳＬＣＰサーバとともに稼働する別
の認証サーバのユーザ・データベースに蓄積されている
認証データを用いて認証手続に入る。ここでもし認証に
失敗するとステップ２０２から２０８に進む。この認証
フェーズの通信方法はＲＦＣ１９９４のＣＨＡＰに準拠
して行われ、認証手段としてはＲＦＣ２１３８のＲＡＤ
ＩＵＳに準拠している。また、必要に応じてアカウンテ
ィングの機能を持たせてもよいが、これはＲＦＣ２１３
９に準拠する。

【００３７】クライアント認証が首尾よく終了すると
（ステップ２０３）、ＳＬＣＰＣは、ＵＤＬ−ＩＦ用の
ＩＰアドレスを割り当ててもらうため、ステップ１０５
でＵＤＬ確立要求を出す。ＳＬＣＰＳはそれに応答し
て、ステップ２０４でＩＰアドレスの割り当てを開始
し、次のステップ２０５で、要求元のクライアントにＩ
Ｐアドレスを割り当てることができるかどうかを判断す
る。ＳＬＣＰサーバは、そのために、それぞれ所定数の
ＩＰアドレスをリストした複数のアドレス・プール（図
４参照）と、割り当て済みのＩＰアドレスが記録される
割り当て済みアドレス・テーブル（図示せず）とを備え
ており、要求元クライアントからの認証データ応じたア
ドレス・プール及び割り当て済みアドレス・テーブルか
ら、利用可能なＩＰアドレスがあるかどうかを決める。
もしなければ、終了処理ステップ２０８に進む。ＩＰア
ドレスが割り当て可能であれば、ＳＬＣＰＳは、要求元
クライアントに関連するアドレス・プールから、そのク
ライアントに割り当てるＩＰアドレスを選び、それを割
り当て済みアドレス・テーブルに記録する。そして割り
当てたＩＰアドレス（ＵＤＬ−ＩＰ１／ＵＤＬ−ＩＰ
２）と、サービスＩＤ（ＳＩＤ）及び新規デフォルト・
ゲートウェイ・アドレス（ＵＤＬ−ＩＰ３）とをクライ
アントに通知して、ＩＰアドレス割り当てを終了する
（ステップ２０６）。この通信方法は前述のようにＲＦ
Ｃ１３３２記載のＩＰＣＰに準拠している。

【００３８】クライアントに返されるＳＩＤは衛星リン
クを識別するもので、そのクライアントのユーザ情報及
び改竄不可能な衛星ボードＩＤに基づいて認証が行われ
た結果割り当てられるため、ユーザが誤って、あるいは
故意に偽りの衛星リンクを使用することはできない。こ
れはセキュリティ的な利点がある。更にこれは、単一の
アドレス・プールからＩＰアドレスを振り分けるのでは
なく、ユーザに提供するサービスの形態や使用ネットワ
ークの種類に応じて衛星リンクを分けることができるよ
う配慮されている。つまり、サービス提供者は任意に複
数のアドレス・プールを使い分けてサービスできる。こ
れにより、サービス提供者は、ユーザに応じてサービス
品目を区別することができ、顧客や環境に応じて柔軟
に、かつ、動的にサービスや衛星リンクの帯域分割が行
える。

【００３９】前述のように、ＳＬＣＰクライアントがＳ
ＬＣＰサーバから受け取る情報には、自らの衛星通信受
信部（ＵＤＬ−ＩＦ１又はＵＤＬ−ＩＦ２）のＩＰアド
レス（ＵＤＬ−ＩＰ１又はＵＤＬ−ＩＰ２）の他に、新
規デフォルト・ゲートウェイとなるフィード４４（フィ
ード４４がルータ機能を持っていない場合は、図示しな
いフィード・ルータ）のＵＤＬ側ＩＰアドレス（ＵＤＬ
−ＩＰ３）が含まれる。これら様々なデータをやり取り
するＳＬＣＰ通信はＬＡＮ／ＷＡＮ／インターネットを
通って行われるため、セキュリティの点では、暗号化さ
れたストリームを用いるのが好ましい。

【００４０】これにより全てのフェーズが成功すると、
クライアントの衛星通信受信部に対して利用可能な衛星
リンク（サービスＩＤ）用のＩＰアドレスが動的に割り
振られたことになり、ステップ１０６でクライアントの
経路制御テーブルが変更されて、デフォルト・インター
フェースがＵＤＬ−ＩＦになる。ただし、ＳＬＣＰサー
バ１２（ＳＬＣＰＳ１）に対する経路は常にＢＤＬ−Ｉ
Ｆが使われるように自動設定されている。同様に、クラ
イアントの初期設定でＢＤＬ−ＩＦを使うように静的に
設定した送信先へは意図的に地上線を送受信に使うよ
う、ホスト・ルート又はネットワーク・ルートが設定さ
れる。

【００４１】以上によりＵＤＬが確立されると（ステッ
プ１０７）、ＴＣＰ／ＩＰスタックとしては、ＢＤＬ−
ＩＦから送出されるべく設定した宛先以外へは、ＵＤＬ
−ＩＦに向けてＩＰパケットを送出する。そして、ウェ
ブ・サーバ１４のようなターゲット・サーバに対してリ
クエスト・パケットをＵＤＬ−ＩＦに送出しようとする
が、この時、ＩＰ層からＵＤＬ−ＩＦのデータリンク層
にＩＰパケットが渡される瞬間に出力ＩＰパケットを予
め選ばれているＢＤＬ−ＩＦのデータリンク層にフック
し、そのＢＤＬ−ＩＦからＤＣＥ（たとえば２４）を介
してＩＰパケットを送出する。こうして、ＵＤＬ−ＩＰ
を送信元アドレスとして含むＩＰパケットが地上線経由
でウェブ・サーバ１４に送られる。

【００４２】ウェブ・サーバ１４はこのＩＰパケットを
受け取り、送信元ＩＰアドレスがＵＤＬ−ＩＰ１又はＵ
ＤＬ−ＩＰ２であることを知り、それらへの経路はサー
ビス提供者が管理するアドレス・レンジの一部であるこ
とを自らあるいは上位ルータの経路制御テーブルから認
識し、返答パケットをサービス提供者の持つ境界ルータ
４０に転送する。境界ルータ４０はそれをフィード４４
が接続されているルータ（図示せず）に送るか、あるい
はフィード４４がルータの時は直接フィード４４に送
る。フィード４４（又はフィード・ルータ）はこれを衛
星信号多重器（ＭＵＸ）４６経由でトランスポンダ（通
信衛星２０）に向けて送信し、最終的にリクエストをし
たクライアントのＵＤＬ−ＩＦに届けられる。

【００４３】この間、ＳＬＣＰサーバはＰＰＰの機能を
利用してＳＣＬＰクライアントの状態を監視している。
これは、クライアントの状態を照会するキープ・アライ
ブ（ＫＡ）パケットを地上線経由で定期的に交換するこ
とで行われる（ステップ１０８及び２０７）。所定の時
間間隔を越えて応答がないクライアントは、定常終了し
なかった、あるいは、予期しない停止を行ったと判断さ
れ、ＳＬＣＰＳはＳＬＣＰＣの終了処理を行い（ステッ
プ２０８）、当該クライアントに割り当てていた資源
（衛星リンク、ＩＰアドレス）の回収を行う。これは、
前述の割り当て済み資源テーブルから対応する資源情報
を削除することにより行われる。クライアントの状態に
異常がなく、衛星通信が首尾よく終了した場合には、Ｓ
ＬＣＰＣのステップ１０９でＳＬＣＰＣ終了要求をＳＬ
ＣＰＳに送ることにより、同様の終了処理が行われる。
かくして、割り当てられていたＩＰアドレス及び衛星リ
ンクを再利用できるようになる。

【００４４】最後に、図４を参照しながら、ＳＬＣＰを
用いたサービス形態の一例を説明する。図４は、一般消
費者に対してサービスされている共有インターネット・
セグメントとしての第１ネットワークＮＷ１、ある特定
のＩＳＰが所有するネットワークの一部として使用され
る第２ネットワークＮＷ２、及びある企業が自社内ＬＡ
Ｎ（イントラネット）の一部として使用する第３ネット
ワークＮＷ３が各々構成されている衛星リンクを示して
いる。各クライアントの地上線インターフェース（ＢＤ
Ｌ−ＩＦ）は、前述のように、ＳＬＣＰ接続を開始する
前にダイアルアップ接続によって固有のＩＰアドレスが
割り当てられている。

【００４５】図４では、ＮＷ１〜３が太いリング５０で
束ねられている。この束ねているものが衛星（１トラン
スポンダ）である。トランスポンダは図示の細いリング
５２及び５４のように、セキュリティ要件などに基づい
て任意に複数のキャリア（搬送波）に分割もできる。Ｓ
ＬＣＰを用いることで、ＮＷ１に収容されるべきクライ
アントは自動的にＳＬＣＰサーバ５６の認証手続きによ
ってＮＷ１のリンクとそれに適したＩＰアドレスが割り
当てられる。ＮＷ２も同様である。そのため、ＳＬＣＰ
サーバ５６は図示のような２つのアドレス・プールを備
えており、それを用いて、ＮＷ１及びＮＷ２のクライア
ントにＩＰアドレスを割り当てる。ＮＷ３のクライアン
トは、ＮＷ３用のアドレス・プールを備えた別のＳＬＣ
Ｐサーバ５８によってＩＰアドレスを割り当てられる。
６０、６２及び６６はそれぞれのネットワーク用のルー
タである。図４の例では、インターネット用ルータ６０
及びイントラネット用ルータ６２は共通のフィード６４
に接続されているが、それらを別々のフィードに接続す
るようにしてもよい。

【００４６】前述のように、ＳＬＣＰＣによって渡され
るクライアントの情報に従ってＳＬＣＰＳが適切な衛星
リンクを割り当てることが可能であるため、インターネ
ットの支線やバックボーンとして、あるいは、企業内ネ
ットワーク（イントラネット）の一部として衛星を自由
度高く使うことができるようになる。なお、ＳＬＣＰサ
ーバを一台で上記構成を組むことは可能であるが、運用
及びセキュリティの観点から、図４のようにＳＬＣＰサ
ーバは分離した方が望ましい。また、フィードに関して
も、サービス提供者のポリシーに応じて分離できる。

【図面の簡単な説明】

【図１】クライアント・マシンのネットワーク層構造を
示す図。

【図２】本発明を適用可能な通信システムの概略構成を
示す図。

【図３】図２の通信システムにおいてＳＬＣＰＣの接続
要求から終了までの流れを示すフローチャート。

【図４】通信システムのサービス形態の一例を示す図。

【符号の説明】

１ 通信システム １０ ネットワーク １２ ＳＬＣＰサーバ（管理サーバ） １４ ウェブ・サーバ １６、１８ ＳＬＣＰクライアント ２０ 通信衛星 ２２ 公衆回線網 ２４、３２ データ通信装置（ＤＣＥ） ２６、３４ 受信アンテナ ２８、３６ ネットワーク通信部（ＢＤＬ−ＩＦ） ３０、３８ 衛星通信受信部（ＵＤＬ−ＩＦ） ４０ 境界ルータ ４２ ルータ ４４ フィード ４６ 衛星信号多重器（ＭＵＸ） ４８ 送信アンテナ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 泉山 英孝 東京都千代田区丸の内二丁目２番２号 エ ヌ・ティ・ティ サテライトコミュニケー ションズ株式会社内 (72)発明者 竹井 淳 東京都千代田区丸の内二丁目２番２号 エ ヌ・ティ・ティ サテライトコミュニケー ションズ株式会社内 (72)発明者 小谷 伸哉 東京都小金井市東町５丁目28番24号、カサ グランデエラン303号 Ｆターム(参考） 5K030 GA11 GA20 HA08 HC01 HC13 HD09 JL02 KA01 KA05 LB01 LB05 LE17 5K072 BB15 BB22 BB25 BB27 DD16 DD17 FF03 FF05 FF27 9A001 CC05 CC06 CC07 EE01 JJ25 JJ27 KK56

Claims (10)

【特許請求の範囲】
1. 【請求項１】それぞれが衛星通信受信手段及びネットワ
   ーク通信手段を有する複数のクライアントと、所与のク
   ライアントからネットワークを介して送られてきた要求
   に応じて該所与のクライアントの衛星通信受信手段にＩ
   Ｐアドレスを割り振る管理サーバとを含む通信システム
   において、 前記複数のクライアントの固有情報を格納するステップ
   と、 所与のクライアントの要求に応じて該所与のクライアン
   トと前記管理サーバとの間に前記ネットワークを介する
   リンクを確立するステップと、 前記要求に応じて、前記所与のクライアントの格納され
   ている固有情報に基づき、前記管理サーバにより前記所
   与のクライアントに衛星リンクを動的に割り当てるステ
   ップと、 割り当てた衛星リンクに対応するＩＰアドレスを前記管
   理サーバから前記ネットワークを介して前記所与のクラ
   イアントに送信するステップと、 を含む、衛星リンクを動的に割り当てるための方法。
2. 【請求項２】前記所与のクライアントは、受け取ったＩ
   Ｐアドレスを自身の衛星通信受信手段のための送信元ア
   ドレスとして使用し、該送信元アドレスを含むＩＰパケ
   ットを前記ネットワークを介して目的とするサーバに送
   る、請求項１に記載の方法。
3. 【請求項３】前記所与のクライアントの衛星通信受信手
   段をＩＰパケット送受信用のデフォルト・インターフェ
   ースに設定するステップと、 特定の宛先以外へは、前記衛星通信受信手段に向けてＩ
   Ｐパケットを送出するステップと、 前記ＩＰパケットを前記所与のクライアントのネットワ
   ーク通信手段に取り込んで、前記ネットワークに送出す
   るステップと、 を更に含む、請求項２に記載の方法。
4. 【請求項４】前記ネットワークはそれぞれ異なる衛星リ
   ンクに対応する複数の異なるネットワークを含み、前記
   管理サーバはネットワーク毎のＩＰアドレス・プールを
   備えており、前記衛星リンクを動的に割り当てるステッ
   プは、前記所与のクライアントが属するネットワークに
   応じて対応する衛星リンクを割り当てる、請求項１〜３
   のいずれかに記載の方法。
5. 【請求項５】前記複数のネットワークはインターネット
   およびイントラネットを含み、前記管理サーバがインタ
   ーネット用及びイントラネット用に別々に設けられてい
   る、請求項４に記載の方法。
6. 【請求項６】それぞれが衛星通信受信手段及びネットワ
   ーク通信手段を有する複数のクライアントを含む通信シ
   ステムにおいて、所与のクライアントからネットワーク
   を介して送られてきた要求に応じて該所与のクライアン
   トに衛星リンクを動的に割り当てるための装置であっ
   て、 前記複数のクライアントの固有情報を格納する手段と、 所与のクライアントの要求に応じて該所与のクライアン
   トとの間に前記ネットワークを介するリンクを確立する
   手段と、 前記要求に応じて、前記所与のクライアントの格納され
   ている固有情報に基づき、前記所与のクライアントに衛
   星リンクを動的に割り当て、該割り当てた衛星リンクに
   対応するＩＰアドレスを前記所与のクライアントに送信
   する手段と、 を含む、衛星リンクを動的に割り当てるための装置。
7. 【請求項７】前記所与のクライアントは、受け取ったＩ
   Ｐアドレスを自身の衛星通信受信手段のための送信元ア
   ドレスとして使用し、該送信元アドレスを含むＩＰパケ
   ットを前記ネットワークを介して目的とするサーバに送
   る手段を含む、請求項６に記載の装置。
8. 【請求項８】前記所与のクライアントは、前記衛星通信
   受信手段をＩＰパケット送受信用のデフォルト・インタ
   ーフェースに設定して、特定の宛先以外へは、前記衛星
   通信受信手段に向けてＩＰパケットを送出する手段と、
   前記ＩＰパケットを自身のネットワーク通信手段に取り
   込んで、前記ネットワークに送出する手段とを更に含
   む、請求項７に記載の装置。
9. 【請求項９】前記ネットワークはそれぞれ異なる衛星リ
   ンクに対応する複数の異なるネットワークを含み、前記
   管理サーバはネットワーク毎のＩＰアドレス・プールを
   備えており、前記送信する手段は、前記所与のクライア
   ントが属するネットワークに応じて対応する衛星リンク
   を割り当てる、請求項６〜８のいずれかに記載の装置。
10. 【請求項１０】前記複数のネットワークはインターネッ
    トおよびイントラネットを含み、前記管理サーバがイン
    ターネット用及びイントラネット用に別々に設けられて
    いる、請求項９に記載の装置。