(57)【特許請求の範囲】
【請求項１】
第１の管理ドメインを構成するとともに複数の管理サーバを有する第１のモバイルネットワーク内の管理サーバと、第２の管理ドメインを構成する第２のネットワークとの間でデータが送受信される場合に、前記第１のモバイルネットワークのネットワークトポロジーを隠蔽する方法であって、
管理サーバの実ホスト名を、該管理サーバのランダムホスト名へ置換するゲートウェイサーバであって、通信が異なるセッションに属する場合には、管理サーバの実ホスト名をセッションごとに異なるランダムホスト名へ置換するゲートウェイサーバを介して、前記第２のネットワーク内の管理サーバへデータを送信するステップと、
前記第２のネットワーク内の管理サーバから前記ゲートウェイサーバを介してデータを受信するステップであって、前記データは、前記ゲートウェイサーバにより前記管理サーバの前記実ホスト名へ置換される前記管理サーバの前記ランダムホスト名または前記セッションごとに異なるランダムホスト名へとアドレス指定されるものである、ステップと、
前記管理サーバの前記実ホスト名と前記管理サーバの前記ランダムホスト名または前記セッションごとに異なるランダムホスト名との対応を表すマッピングテーブルを前記ゲートウェイサーバが管理するステップと
を含む方法。
【請求項２】
管理サーバから異なる第２の管理ドメインへデータが送信される場合に、前記管理サーバのホスト名はそれぞれ異なるランダム名へ置換されるものである、請求項１に記載の方法。
【請求項３】
前記マッピングテーブル内のマッピングエントリはタイムアウト後に削除されるものであり、
前記タイムアウトは好ましくはセッションの最大ライフタイムと少なくとも同じ長さである、
請求項１または２に記載の方法。
【請求項４】
データが送信される前記第２のドメイン内の管理サーバのアドレスが不明の場合、前記管理サーバが管理する端末のアドレスに関する情報をメッセージに含めるステップと、
前記メッセージが前記第２の管理ドメインへ到達すると、前記端末の前記アドレスに基づいて不明な前記管理サーバのアドレスを決定するステップと
をさらに含む請求項１〜３のいずれか一項に記載の方法。
【請求項５】
どの管理サーバがどのＩＰアドレスを管理するかを表す、ドメイン内のＩＰアドレスプール情報を管理するステップと、
前記ＩＰアドレスプール情報に基づいて、不明な前記管理サーバのアドレスを決定するステップと
をさらに含む請求項４に記載の方法。
【請求項６】
第１の管理ドメインを構成するとともに複数の管理サーバを有する第１のモバイルネットワーク内の管理サーバと、第２の管理ドメインを構成する第２のネットワークとの間でデータが送受信される場合に、前記第１のモバイルネットワークのネットワークトポロジーを隠蔽する装置であって、
前記第２のネットワーク内の管理サーバへデータを送信する送信ユニットであって、その結果、前記管理サーバの実ホスト名は該管理サーバのランダムホスト名へ置換され、通信が異なるセッションに属する場合には、前記管理サーバの実ホスト名はセッションごとに異なるランダムホスト名へ置換されるものである、送信ユニットと、
前記第２のネットワーク内の管理サーバからデータを受信する受信ユニットであって、前記データは前記管理サーバの前記ランダムホスト名または前記セッションごとに異なるランダムホスト名へとアドレス指定されるとともに、前記管理サーバの前記ランダムホスト名または前記セッションごとに異なるランダムホスト名を前記管理サーバの実ホスト名へ置換する受信ユニットと、
前記管理サーバの前記実ホスト名と前記管理サーバの前記ランダムホスト名または前記セッションごとに異なるランダムホスト名との対応を表すマッピングテーブルを管理する管理ユニットと
を備える装置。
【請求項７】
前記管理サーバから異なる第２の管理ドメインへデータが送信される場合、前記管理サーバのホスト名はそれぞれ異なるランダム名へ置換されるものである、請求項６に記載の装置。
【請求項８】
前記マッピングテーブル内のマッピングエントリはタイムアウト後に削除されるものであり、
前記タイムアウトは好ましくはセッションの最大ライフタイムと少なくとも同じ長さである、
請求項６または７に記載の装置。
【請求項９】
データが送信される前記第２のドメイン内の管理サーバのアドレスが不明の場合、前記送信ユニットは、前記管理サーバが管理する端末のアドレスに関する情報をメッセージに含めるものであり、その結果、前記メッセージが前記第２の管理ドメインへ到達すると、不明な前記管理サーバのアドレスが前記端末の前記アドレスに基づいて決定できるものとなる、請求項６〜８のいずれか一項に記載の装置。
【請求項１０】
どの管理サーバがどのＩＰアドレスを管理するかを表す、ドメイン内のＩＰアドレスプール情報を管理する管理ユニットと、
前記ＩＰアドレスプール情報に基づいて不明な前記管理サーバのアドレスを決定する決定ユニットと
をさらに備える請求項９に記載の装置。
【請求項１１】
コンピュータ上で、請求項１〜５のいずれか一項に記載の方法を実行するコンピュータ実行可能なプログラムコードを含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特にモバイルワイヤレスネットワークにおけるネットワークトポロジーを隠蔽する（ｈｉｄｅ）方法および装置に関する。
【背景技術】
【０００２】
現在および将来のモバイルワイヤレスネットワークにおいて、異なるネットワークドメインにある管理サーバの間で管理データを共有することが重要である。本明細書において「異なるネットワークドメイン」という用語は、特に、異なるネットワークオペレータによってオペレーションされているドメインのことを指す。このような場合に生じる問題は、ネットワークトポロジーを明らかにせずに、あるネットワークオペレータと別のネットワークオペレータとの間で上記データのやり取りをいかに実行するかということである。これは、トポロジーを明らかにすることでアタッカーがネットワーク内の管理サーバに対して容易に攻撃できるようになるからである。
【０００３】
この問題は、ユーザーがあるネットワークから別のネットワークに移動し、ホームネットワークと同じサービスを受けたい場合に、分散された認証、承認、課金および監査の管理をする必要があるユビキタス環境において特に生じる。
【０００４】
これは、２つ以上のネットワークがサービス提供に関わっている場合に、認証、承認、監査および課金などのタスクを実行する第１のネットワーク内の管理サーバが、他のネットワーク内の管理サーバとデータを送受信しなければならないということを意味する。しかしながら、このようなデータ送受信は監視されたり、管理サーバのアドレスや番号などといったネットワーク情報およびネットワークトポロジーが漏れたりする恐れがある。
【０００５】
多くのオペレータは、自分のネットワークの機密情報を守ることに強い関心を持っている。ビジネス政策上の理由だけでなく、実際のセキュリティに関する理由もある。例えば、アタッカーはこの情報を使用して、既知の脆弱性を有するソフトウェアを実行したり、管理サーバに対して直接的にサービス拒否攻撃（ＤｏＳ）をしたりする、ドメイン内の特別なサーバに攻撃をすることがある。従って、管理サーバの実際の名前およびアドレスはドメイン外に知られるべきではない。
【０００６】
従って、例えばサーバのＩＰアドレスに関する情報に基づいた、ネットワークオペレータのドメイン内のサーバに対する攻撃を阻止するといったセキュリティの考慮により、例えば管理データを送受信するために異なるドメイン内の管理サーバが相互に通信する場合は、ドメインのネットワークトポロジーが隠蔽され、他のドメインに対して明らかとならないことが望ましい。
【０００７】
通信相手の実際のアドレスを開示しないための既知の技術は、ベーシックネットワークアドレス変換（ベーシックＮＡＴ）およびネットワークアドレスポート変換（ＮＡＰＴ）である。ベーシックネットワークアドレス変換（ベーシックＮＡＴ）は、ＩＰアドレスがあるグループからエンドユーザーには見えない別のグループへとマッピングされる方法である。ネットワークアドレスポート変換（ＮＡＰＴ）は、多くの（送信元の）ネットワークアドレスと、それらのＴＣＰ／ＵＤＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ポートとが単一のネットワークアドレスへ変換されるものの、ＴＣＰ／ＵＤＰポートが送信元のネットワークアドレスごとに別々に管理されるため、逆方向のマッピングが実行される方法である。従来のＮＡＴと呼ばれるこれら２つの技術はともに、プライベートアドレスを有するアドレス体系を、グローバルにユニークな登録アドレスを有する外部アドレス体系へと関連付けるメカニズムを提供する。
【０００８】
非特許文献１に記載されている双方向ＮＡＴ（両方向ＮＡＴ）により、パブリックネットワークおよびプライベートネットワークの双方からセッションを開始できるようになるが、ドメインネームサーバ（ＤＮＳ）の特別な実装が必要である。このＤＮＳサーバは、ＤＮＳクエリ内のプライベートアドレス体系のアドレスを、ＤＮＳレスポンスにおいてバインドされる外部アドレス体系のアドレスへと変換できなければならない。
【０００９】
上記の方法は、少数のパブリックアドレスのみが使用できる場合にプライベートアドレスを有するネットワークのアドレス範囲を拡張することを目的とするが、ネットワークトポロジーに関する情報をはっきりと隠蔽する目的はない。
【００１０】
【非特許文献１】Ｐ．  Ｓｒｉｓｕｒｅｓｈ，  Ａ．  Ｈｏｌｄｒｅｇｅ，  “ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ  （ＮＡＴ）  Ｔｅｒｍｉｎｏｌｏｇｙ  ａｎｄ  Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ”，  ＲＦＣ  ２６６３，  Ａｕｇｕｓｔ  １９９９
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従って、本発明の目的は、特にモバイルワイヤレスネットワークにおいてネットワークトポロジーを隠蔽する方法および装置を提供することである。
【課題を解決するための手段】
【００１２】
一実施形態によれば、第１の管理ドメインを構成するとともに複数の管理サーバを有する第１のモバイルネットワーク内の管理サーバと、第２の管理ドメインを構成する第２のネットワークとの間でデータが送受信される場合に、前記第１のモバイルネットワークのネットワークトポロジーを隠蔽する方法であって、管理サーバの実ホスト名を、該管理サーバのランダムホスト名へ置換するゲートウェイサーバを介してのみ、前記第２のネットワーク内の管理サーバへデータを送信するステップと、前記第２のネットワーク内の管理サーバから前記ゲートウェイサーバを介してのみデータを受信するステップであって、前記データは、前記ゲートウェイサーバにより前記管理サーバの前記実ホスト名へ置換される前記管理サーバの前記ランダムホスト名へとアドレス指定されるものである、ステップと、前記管理サーバの前記実ホスト名と前記管理サーバの前記ランダムホスト名との対応を表すマッピングテーブルを前記ゲートウェイサーバが管理するステップとを含む方法が提供される。
【００１３】
この方法によれば、第２のネットワーク内の管理サーバは、第１のネットワーク内の管理サーバのアドレスを知ることができない。対称的に、つまり両方のネットワークそれぞれに対しゲートウェイサーバを用いてこの方法を適用すると、２つの管理サーバは互いのアドレスを知ることができない。従ってこの方法は、ネットワークドメインの外部の他のドメインに対して該ネットワークドメインを隠蔽することをサポートするが、異なるドメイン内のサーバ間で管理データを送受信することは許容する。
【００１４】
さらに、ゲートウェイサーバを介した通信は管理に関するオーバーヘッドを低減する。別のドメインとの通信に際してゲートウェイサーバを使用しない場合、ドメイン内の全ての管理サーバは、キーを生成、管理および配信することにより、コストおよびメンテナンスにかかる労力を増やす、認証用および暗号化用のパブリックキーおよびプライベートキーを必要とする。さらに、キーは有効なドメイン間（ｉｎｔｅｒ−ｄｏｍａｉｎ）になければならないため、信頼されている第三者は、認証リクエストを生成し有効化する必要がある。
【００１５】
さらに、提案された方法によれば、あるドメインの管理サーバは、管理サーバ名を知らなくても別のドメイン内の別の管理サーバへアドレス指定することができる。さらに、この機能は、内部サーバのアドレスを解決するのにＤＮＳサーバの助けを必要としない一方、対応するサーバは実ホスト名を知る必要はない。
【００１６】
一実施形態によれば、管理サーバから異なる第２の管理ドメインへデータが送信される場合、同一の管理サーバはそれぞれ異なるランダム名で表される。
【００１７】
これにより、（複数の）管理サーバの実際の名前、ひいてはネットワークトポロジーを特に効率的に隠蔽することができる。
【００１８】
一実施形態によれば、前記マッピングテーブル内のマッピングエントリはタイムアウト後に削除されるものであり、前記タイムアウトは少なくともセッションの最大ライフタイムと同じ長さである。
【００１９】
一実施形態によれば、通信が異なるセッションに属する場合、管理サーバのホスト名はそれぞれ異なるランダム名へ置換される。これによりドメイン内の管理サーバの実際の数を隠蔽することができる。
【００２０】
一実施形態によれば、前記方法は、データが送信される前記第２のドメイン内の管理サーバのアドレスが不明の場合、前記管理サーバが管理する端末のアドレスに関する情報をメッセージに含めるステップと、前記メッセージが前記第２の管理ドメインへ到達すると、前記端末の前記アドレスに基づいて不明な前記管理サーバのアドレスを決定するステップとをさらに含む。
【００２１】
一実施形態によれば、前記方法は、どの管理サーバがどのＩＰアドレスを管理するかを表す、ドメイン内のＩＰアドレスプール情報を管理するステップと、前記ＩＰアドレスプール情報に基づいて、不明な前記管理サーバのアドレスを決定するステップとをさらに含む。
【００２２】
一実施形態によれば、第１の管理ドメインを構成するとともに複数の管理サーバを有する第１のモバイルネットワーク内の管理サーバと、第２の管理ドメインを構成する第２のネットワークとの間でデータが送受信される場合に、前記第１のモバイルネットワークのネットワークトポロジーを隠蔽する装置であって、前記第２のネットワーク内の管理サーバへデータを送信する送信ユニットであって、その結果、前記管理サーバの実ホスト名は該管理サーバのランダムホスト名へ置換されるものである、送信ユニットと、前記第２のネットワーク内の管理サーバからデータを受信する受信ユニットであって、前記データは前記管理サーバの前記ランダムホスト名へとアドレス指定されるとともに、前記管理サーバの前記ランダムホスト名を前記管理サーバの実ホスト名へ置換する受信ユニットと、前記管理サーバの前記実ホスト名と前記管理サーバの前記ランダムホスト名との対応を表すマッピングテーブルを管理する管理ユニットとを備える装置が提供される。
【００２３】
一実施形態によれば、前記管理サーバから異なる第２の管理ドメインへデータが送信される場合、前記管理サーバのホスト名はそれぞれ異なるランダム名へ置換される。
【００２４】
一実施形態によれば、前記マッピングテーブル内のマッピングエントリはタイムアウト後に削除されるものであり、前記タイムアウトは好ましくはセッションの最大ライフタイムと少なくとも同じ長さである。
【００２５】
一実施形態によれば、通信が異なるセッションに属する場合、管理サーバのホスト名はそれぞれ異なるランダム名へ置換される。
【００２６】
一実施形態によれば、データが送信される前記第２のドメイン内の管理サーバのアドレスが不明の場合、前記送信ユニットは、前記管理サーバが管理する端末のアドレスに関する情報をメッセージに含めるものであり、その結果、前記メッセージが前記第２の管理ドメインへ到達すると、不明な前記管理サーバのアドレスが前記端末の前記アドレスに基づいて決定できるものとなる。
【００２７】
一実施形態によれば前記装置は、どの管理サーバがどのＩＰアドレスを管理するかを表す、ドメイン内のＩＰアドレスプール情報を管理する管理ユニットと、前記ＩＰアドレスプール情報に基づいて不明な前記管理サーバのアドレスを決定する決定ユニットとをさらに備える。
【００２８】
一実施形態によれば、コンピュータ上で、本発明の一実施形態に基づく方法を実行するコンピュータ実行可能なプログラムコードを含むコンピュータプログラムが提供される。
【発明を実施するための最良の形態】
【００２９】
異なるオペレータの管理サーバ間でデータが送受信される場合の本発明の一実施形態について説明する。管理サーバは例えば、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、承認（ａｕｔｈｏｒｉｚａｔｉｏｎ）、監査（ａｕｄｉｔｉｎｇ）、課金（ａｃｃｏｕｎｔｉｎｇ）および請求（ｃｈａｒｇｉｎｇ）などのタスクを管理するサーバである。従って以下Ａ４Ｃサーバとも呼ばれる。しかしながら、管理サーバは他のタスクを実行することもでき、管理タスクを実行するとともに別のドメイン内の管理サーバへ接続する必要がある任意の管理サーバに対して実施形態を適用することができる。
【００３０】
全ての管理サーバは、場合によっては別のドメイン内の他の全てのサーバとデータを送受信できなければならないため、場合によってはこのような通信から検出されるとともに攻撃を開始するのに用いられるネットワークトポロジーから問題が生じることがある。基本的に本発明の実施形態によれば、オペレータのネットワークトポロジーに関する情報を隠蔽することができるとともに、ドメイン間のデータの送受信が許可されているサーバの数を制限する。
【００３１】
従って、本発明によれば、攻撃の対象の数を削減することができる（例えば、既知の攻撃に対して特に保護されている専用サーバに対してのみ攻撃が行われることがある）。
【００３２】
一実施形態によれば、ネットワークオペレータが管理データを送受信できる一方で、ネットワークトポロジーに関する機密を守ることができる、送信元のホストアドレスを置換する具体的な手順が提供される。これは、メッセージ内の送信元のソースホストアドレスを「ダミー」、つまりランダムホストアドレスへ置換するホストアドレス置換を実行する専用のゲートウェイサーバを使用することによって実現できる。アドレス置換の関連付けを維持することにより、適切な双方向のメッセージルーティングが可能になる。
【００３３】
本発明の一実施形態は、アドレス体系ベースまたはドメインベースのメッセージルーティングを提供するＴＣＰ上のプロトコルが整っていることを前提とする。送信元ホスト、宛先ホストおよび宛先ドメインなどの情報に対するアドレスフィールドすなわち属性評価値対（Ａｔｔｒｉｂｕｔｅ  Ｖａｌｕｅ  Ｐａｉｒｓ）は、メッセージのアドレス指定およびルーティングを可能にできるようにサポートされる。これらのアドレスを使用して通信は、以下に説明するように本発明の実施形態に基づいて行うことができる。
【００３４】
基礎となるプロトコルによって使用される属性評価値対ＡＶＰ（つまりアドレスフィールド）は、送信元ホストなどのネットワークトポロジーに関する情報を含んでいるため、この情報を隠蔽するメカニズムが提供される。送信元ホストのＡＶＰは、送信サーバのアドレス（または名前、例えば完全修飾ドメイン名ＦＱＤＮ）を有している。一実施形態によれば、送受信されるメッセージがドメインを出入りする前に通らなければならないゲートウェイサーバが、ドメインに対して最初に送信されたＦＱＤＮをゲートウェイが通知する場合に、送信元ホストのＦＱＤＮのホスト部分をランダムに生成された名前へ置換する。一実施形態によればランダムに生成された名前は、シードによって連結された元のホスト名をＢａｓｅ６４でエンコードしたハッシュであり、それにより実ホスト名との矛盾も排除することができる。
【００３５】
本発明の実施形態は、ネットワークオペレータのドメイン内で特定の課金監査サーバにより収集されるとともにホームオペレータのドメインへ送信される課金監査データの送受信に適用できる。ホームオペレータとは、申し込みによりユーザーが会員となっているオペレータであり、ユーザーが自分のホームオペレータへ接続しない場合は、外部のオペレータである。このような実施形態では、情報を送受信する管理サーバは監査機能を有することができ、認証、承認、課金、監査および請求サーバ（Ａ４Ｃ）と呼ばれることもある。これらは、上述のアドレスを置換する機能を有するゲートウェイサーバを介してのみ外部ドメイン内の管理サーバと通信することができ、ネットワークトポロジーに関する情報を隠蔽することができる。
【００３６】
図１は、本発明の実施形態が適用される環境を概略的に示している。自身のモバイル端末を使用するユーザーＡは、図１の右側に示されている自身のホームオペレータのネットワークの登録ユーザーである。しかしながら、ユーザーＡが自分のホームオペレータのサービスエリア内に位置していない状況では、左側に示されている外部オペレータおよび外部オペレータとホームオペレータとの間のデータの送受信を仲介する中継オペレータといった１つ以上の外部オペレータを介してのみサービスを使用することができる。この場合ユーザーＡは、メッセージサービス、インターネットアクセス、ビデオストリーミング、任意のウェブサーバサービスまたはこれに類似のものといった付加価値サービスプロバイダにより提供されるサービスを、図１の長い実線矢印で示されているように外部オペレータおよび中継オペレータを介して付加価値サービスプロバイダへ接続することにより使用することができる。
【００３７】
サービス使用の適切な課金を行うために、図１に「Ａ４Ｃ」サーバとして示されている認証、承認、課金、監査および請求というタスクを実行する、各オペレータドメイン内に提供されている１つ以上の管理サーバがなければならない。サービスの課金や請求がホームオペレータの領域外で行われると、異なるドメインのＡ４Ｃサーバは、図１のＡ４Ｃサーバ間の点線矢印により示されているようにＡ４Ｃデータを送受信しなければならない。
【００３８】
オペレータドメインは１つのみを有していればよいが、通常各オペレータドメインは複数のＡ４Ｃサーバを有している。このような構成が図２に概略的に示されている。
【００３９】
あるドメイン、例えば外部オペレータドメインのネットワークトポロジーを隠蔽するために、一実施形態によれば、第１のドメイン２００（外部オペレータ）内のＡ４Ｃサーバといった管理サーバと、ホームオペレータドメイン内のＡ４Ｃサーバといった第２のドメイン２１０内の管理サーバとの接続は、直接ではなくゲートウェイサーバを介してなされる。そしてゲートウェイサーバは、外部ドメイン内のＡ４Ｃサーバへデータを転送する場合に、Ａ４Ｃサーバの送信アドレスまたは送信ホスト名を対応するランダムアドレスまたはランダムホスト名へ置換する。これにより任意のＡ４Ｃサーバの実送信アドレスまたは実送信ホスト名を、自身のドメインの外部、例えば外部オペレータドメインに対して隠蔽することができる。これは、複数のＡ４Ｃサーバ、Ａ４Ｃ１、Ａ４Ｃ２、・・・Ａ４Ｃｎは、それ自体の実アドレスまたは実ホスト名によってではなく、実アドレスまたは実ホスト名と置換されたランダムアドレスまたはランダムホスト名によってのみ現れるからである。
【００４０】
管理サーバから外部ドメイン内の相手への通信は、アドレス置換を実行するゲートウェイサーバを通過しなければならない。
【００４１】
一実施形態によればゲートウェイサーバは、Ａ４Ｃサーバの実際の名前またはアドレスとこれと置換されたアドレスとのマッピングを含んだマッピングテーブルを管理している。ゲートウェイサーバにより他のドメインへ転送されたメッセージは、送信アドレスや名前として、実際の名前またはアドレスを置換するのに使用されたランダム名またはランダムアドレスを有している。特定のＡ４Ｃサーバへ入ってくる任意のメッセージは、このランダム名やランダムアドレスを宛先としてゲートウェイサーバへ入ってくる。ゲートウェイサーバは、マッピングテーブルを使用して、ランダム名を実際の名前へ置換することにより、特定のＡ４Ｃサーバへ向けて入ってくるメッセージを適切にルーティングすることができる。
【００４２】
一実施形態において、アドレス置換に関する情報は図３に概略的に示されているマッピングテーブル内に記憶される。ここで「ランダム名」と「送信先ドメイン」との組み合わせはユニークであり、「送信元のホスト名」（つまり送信元ホストのＡＶＰ）を特定する。これは、本実施形態において、メッセージを異なる他のドメインへ送信する場合に、同一の送信元ホストのホスト名やアドレスが異なるランダム名へ置換されるということを意味している。これにより、送信元ホストを特定したり、ネットワークトポロジーに関する情報を明らかにしたりすることが特に難しくなる。これは送信元ホストの実アドレスを置換するのに使用されるランダムアドレスの多様性を増大させ、これによりネットワークトポロジーに関する情報を明らかにするのが困難になる。
【００４３】
入ってくるデータについては、ゲートウェイサーバは逆置換しなければならない。一実施形態によれば、ゲートウェイサーバは常に、送信元ホスト名（つまり送信元ホストＡＶＰ）を特定するために「ランダム名」と「送信先ドメイン」（宛先ドメインの名前）との組み合わせを使用している。これは、これらの値のマッピングが変化しないためである。必要であれば（例えば、スケーラビリティにより）、Ａ４Ｃサーバはタイムアウト後にこのマッピングを削除することができ、これは一実施形態によればセッションの最大ライフタイムよりも長い。
【００４４】
ゲートウェイはセッションの状態を維持する必要がないとともに、全てのアクティブセッションに対して同一のマッピングが使用されるため、ゲートウェイサーバは、どのセッションが実行中であるかを認識していない。従って、最初の送受信後、個々のＡ４Ｃサーバは、ネットワークトポロジーに関する実際の情報を明らかにすることなくアドレス指定ができ、ゲートウェイは新たなセッションごとにマッピングを変更する必要がない。
【００４５】
上記実施形態によれば、ドメイン内のサーバの実際の名前を隠蔽することができ、依然として、最大セッション期間が与えられなくても動作するが、ドメイン内の使用可能なサーバの数を推定することもできる。後述のさらなる実施形態によれば、使用中のＡ４Ｃサーバの実際の数を隠蔽することができる。この目的を達成するために、図４から分かるように「送信先ドメイン」の代わりにセッション識別子（ＳＩＤ）が使用される。これは、（実際の）送信元ホストアドレスとセッション識別子とのユニークなペアに対して、マッピングテーブル内の対応するランダム名が割り当てられるということを意味している。使用されるＳＩＤは、外部ドメインによってそのドメイン内の課金または監査を行うために受信されたルートＳＩＤまたは他のＳＩＤのいずれかであり、ドメイン間でデータを送受信するのに使用される。ＳＩＤの使用により、１つのＡ４Ｃは他のドメインに対する名前をセッション数と同じ数だけ有している。従って、サーバの実際の数を推定することは外部からはまったく不可能である。
【００４６】
一実施形態において、基礎となるプロトコルは、Ｃａｌｈｏｕｎ，  Ｐ．；  Ｌｏｕｇｈｎｅｙ，  Ｊ．；  Ｇｕｔｔｍａｎ，  Ｅ．；  Ｚｏｒｎ，  Ｇ．  ａｎｄ  Ａｒｋｋｏ，  Ｊ．，”ＲＦＣ  ３８５５  −  Ｄｉａｍｅｔｅｒ  Ｂａｓｅ  Ｐｒｏｔｏｃｏｌ”，  ２００３に記載されているＤｉａｍｅｔｅｒプロトコルとすることができる。この場合、開始メッセージ（ＤｉａｍｅｔｅｒのＡＡリクエスト）においてＳＩＤは使用できないため、Ｄｉａｍｅｔｅｒプロトコルの「エンドツーエンド識別子」ＡＶＰを使用して、応答（ＡＡ応答）が入ってくる場合に実際のＳＩＤへ置換することができる。
【００４７】
一実施形態によれば、マッピングテーブル内のセッション識別子を用いた実装は、好ましくは、スケーラビリティにより最大セッション期間が与えられる場合に使用されるものであり、一定時間後にマッピングテーブルからリファレンスを削除することができる。そうでなければ、マッピングテーブルが大きくなりすぎて、ゲートウェイが処理できなくなることがある。
【００４８】
上記実施形態は、ゲートウェイの外に対して、オペレータのネットワーク内のＡ４Ｃサーバを隠蔽することを目的としている。結果として、他のドメイン内のサーバを名前によりアドレス指定することは、ランダム名をサーバの実名へ逆マッピングするためにゲートウェイがマッピングテーブル内に適切なエントリを記憶している場合にのみ可能である。別のドメイン内のサーバへ送信された最初のメッセージについては、サーバのエントリがゲートウェイのマッピングテーブル内にもはや存在していないか、または可能性のある送信元がサーバのランダム名を認識していない。これらの問題を解決するために、２つのオプションを使用することができる。
・メッセージをドメインへとアドレス指定する：  これは、メッセージが１つの特定のサーバ専用ではない場合に使用することができる。ドメイン内の任意のサーバは受信側であり、リクエストされたアクションを実行できる。あるサーバが選択されると、後続のメッセージが同一のサーバへ送信されるということが重要である。一つの例は、ユーザーが外部オペレータＦＯのネットワークへ最初に接続する際にＦＯからホームオペレータＨＯへと送信されるＡＡ（認証および承認）リクエストである。ＡＡリクエストはＨＯのゲートウェイへ送信され、ゲートウェイはこれをそのドメイン内のＡ４Ｃサーバへ転送するものの、どのサーバが選択されるかは特に重要ではないため、任意の選択スキーム（例えば、ランダム）に基づいて、または負荷などの基準に基づいて選択することができる。リクエストが実行され、応答が返却され、従ってサーバはＦＯのドメイン内で認識される。
・メッセージは、クライアントのＩＰアドレスに基づいたメッセージルーティングを使用して対象となるサーバアドレスを指定できる：  それぞれのサーバをアドレス指定しなければならない他の全ての場合において、送信側はクライアントのＩＰアドレスに基づいたメッセージルーティングを使用できる（より詳細な説明は以下に示す）。このメカニズムは、ネットワークに関する内部の詳細を明らかにしないため、ゲートウェイの影響を受けない。
【００４９】
いずれの場合においても（例えば、第１の場合にはドメインのみをアドレス指定することにより、また第２の場合にはクライアントのＩＰアドレスに基づいたメッセージルーティングを使用することにより）、開始メッセージは適切なアドレスを有することができ、受信側に配信することができる。そしてメッセージの送受信は、ゲートウェイのマッピングテーブル内で必要な全てのエントリを生成し、リクエストに対する応答は送信側にピアサーバの名前を提供する。従って、後続の全てのメッセージは名前によるアドレス指定を使用できる。
【００５０】
本発明の実施形態に基づいた、クライアントのＩＰアドレスに基づくメッセージルーティングと呼ばれるメカニズムについて、図５を参照して詳細に説明する。
【００５１】
オペレータドメイン５００において、複数のアクセスポイントまたはネットワークアクセスサーバ（ここではＮＡＳ１およびＮＡＳ２）の各々に対して、ある範囲のＩＰアドレス５１０、５１１および５１２を動的に割り当てることができる。ＮＡＳのＩＰプールは、ＮＡＳが該ＮＡＳへ接続しているモバイル端末へ動的に割り当てることができる全てのＩＰアドレスのリストである。各ネットワークアクセスサーバは、対応するＡ４Ｃサーバによって管理されている。図４に示されているようにＮＡＳ１およびＮＡＳ３はＡ４Ｃ１によって管理され、ＮＡＳ２はＡ４Ｃ２によって管理されている。Ａ４Ｃサーバは複数のＮＡＳを管理することができるものの、各ＮＡＳは該ＮＡＳへ接続されている端末に対する認証、承認、監査および課金などのタスク用の管理サーバである１つのＡ４Ｃサーバのみによって管理されている。例えば、ある端末がＮＡＳ２へ接続すると、ＮＡＳ２を管理するＡ４ＣサーバＡ４Ｃ２またはＮＡＳ２によってＩＰアドレスが割り当てられ、Ａ４Ｃ２はこの端末で使用されるサービスについてデータを管理する。
【００５２】
本実施形態のＡ４Ｃサーバは、ＮＡＳ（ネットワークアクセスサーバ）からＩＰプール情報を取得または集約し、同一ドメイン内のＡ４Ｃピアへ通知する。これにより、各Ａ４Ｃサーバは、ドメイン内のどのＩＰアドレスがどのＡ４Ｃサーバによって管理されているかに関する情報を得る。図５の場合、Ａ４Ｃ２が管理するＩＰアドレスをＡ４Ｃ１が認識していることを意味し、この逆も同様である。その結果、管理メッセージ（例えば、「ＩＰアドレス○○の課金情報」）と関係するクライアントＩＰアドレスを認識している場合に、あるＡ４Ｃサーバへ送信すべき該管理メッセージのルーティング先を全てのＡ４Ｃサーバが認識しているという「イントラドメインオーバーレイルーティングインフラストラクチャ」が展開される。管理メッセージやＡ４Ｃメッセージが外部ドメイン内のＡ４Ｃサーバへ方向付けられる場合、外部ドメインが既知であれば、メッセージがイントラドメインである場合に、他のドメイン内の任意のＡ４Ｃサーバ（特にゲートウェイサーバ）へこれらメッセージを転送することができる。対象となるＡ４Ｃサーバが管理する端末のＩＰアドレスをメッセージが含んでいる場合、外部ドメイン内の任意のサーバは、モバイル端末のＩＰアドレスが含まれるＩＰプールを管理するＡ４Ｃサーバへ該メッセージを転送する。
【００５３】
このようにしてピアは、Ａ４Ｃサーバが管理するモバイル端末のＩＰアドレス、つまり通信相手のＩＰアドレスを示すことによってＡ４Ｃサーバのアドレスを知ることなくそのＡ４Ｃサーバをアドレス指定することができる。第１のドメイン内のＡ４Ｃサーバから外部ドメイン内のＡ４Ｃサーバへメッセージを送信する場合、この情報が含まれるはずである。この情報に基づいて、任意のＡ４Ｃサーバおよびゲートウェイサーバは、このＩＰアドレスを管理するＡ４Ｃサーバを特定し、正しいＡ４Ｃサーバへメッセージをルーティングすることができる。
【００５４】
このようなメカニズムに基づいて、他のドメイン内のＡ４Ｃサーバのアドレスがまだ不明である初期の送受信は、クライアントのＩＰアドレスに基づいたメッセージルーティングによって確立されるか、またはＡ４ＣサーバではなくＡ４Ｃドメインのみへアドレス指定されたメッセージによって確立される。クライアントのＩＰアドレスに基づいたメッセージルーティングにより、送信されるメッセージに対してモバイルデバイスのＩＰアドレスを挿入することは十分であり、他のドメイン内の各Ａ４Ｃサーバは、どのＡ４Ｃサーバへメッセージを転送する必要があるかを認識している。他のＡ４Ｃサーバのドメインのみがアドレス指定されると、ドメイン内のゲートウェイは、どのＡ４Ｃサーバへメッセージを転送すべきかを判断する。
【００５５】
ドメインを出る最初のメッセージの場合、ゲートウェイは、マッピングテーブル内の「送信先ドメイン」および「送信元ホスト名」のエントリを見つけることができない。この場合、ランダム名が（上述のように）生成され、エントリがマッピングテーブル内に作成される。
【００５６】
一実施形態によれば、どのＡ４ＣサーバがどのＩＰアドレスを管理しているかという情報は、全てのＡ４Ｃサーバではなくゲートウェイのみによって管理される。これは、クライアントのＩＰアドレスに基づいたメッセージルーティングがどの場合にも実行されるメッセージが、ゲートウェイを通過しなければならない場合に十分なものである。このような場合、ゲートウェイがルックアップを実行し、メッセージを正しいＡ４Ｃサーバへルーティングできるならば十分である。
【００５７】
ゲートウェイへのみ通知すればよいため、上記実施形態は管理がさらに容易であるのに対し、各Ａ４Ｃサーバが全てのピアのＩＰアドレスプールを認識している実施形態は、任意のＡ４ＣサーバがクライアントのＩＰアドレスに基づいてルーティングを行うことができるためより柔軟性がある。
【００５８】
以下、図６を参照して詳細に実施形態を説明する。本実施形態に基づいた構成は図６に概略的に示されており、オペレーション（例えば、課金）データを他のＡ４Ｃサーバへ送信するのに使用されるデータレポートリクエスト（ＤＲＲ）が示されている。オペレータ２は、Ａ４Ｃサーバ２から送信されるデータレポートリクエスト（１）をオペレータ１へ送信する。リクエストはゲートウェイ２によって転送されなければならない。事前に送信されたメッセージによりゲートウェイ２およびゲートウェイ１にマッピングテーブルがすでに存在しているとする。ゲートウェイ２において、マッピングテーブルのルップアップ（２）が実行され、これはまた図８のメッセージシーケンスチャート（ＭＳＣ）に示されており、送信元ホストアドレス（つまりＡＶＰ）は、「Ａ４Ｃサーバ２」（「送信元ホスト名」カラムのエントリを参照）から「ランダムＡ４Ｃ２」（「ランダム名」カラムのエントリを参照）へ変更される。しかしながら、エントリがすでに存在していなければ、（「ランダム名」カラムに入力される）ランダムに生成された名前により新たなエントリが生成される。続いてゲートウェイ２は、リクエスト（３）をオペレータ１へ送信する。それまでのメッセージ送受信から得られたＡ４Ｃサーバ１のランダム名は、リクエストの宛先ホストアドレス（つまりＡＶＰ）に含まれている。
【００５９】
図７は、図６に示されている第１のステップを含む完全なデータレポートリクエストおよびデータレポートアンサー（ＤＲＡ）の送受信を示している。オペレータ１のゲートウェイ１は、このマッピングテーブル内のＡ４Ｃサーバ１の実際の名前をルックアップし（４）、図７に示されているようにＤＲＲをＡ４Ｃサーバ１へ転送する（５）。Ａ４Ｃサーバ１は、宛先ホストアドレス（つまりＡＶＰ）内の「ランダムＡ４Ｃ２」を使用してデータレポートアンサーによって応答する（６）。ゲートウェイ１はアンサー内の送信元ホストアドレス（つまりＡＶＰ）を「Ａ４Ｃ１ランダム」へ置換し（７）、これをゲートウェイ２へ送信する（８）。ゲートウェイ２は、宛先ホストアドレス（つまりＡＶＰ）が設定されているかチェックし（９）、「ランダムＡ４Ｃ２」を「Ａ４Ｃサーバ２」へマッピングする。ゲートウェイ２が「ランダムＡ４Ｃ２」についてのマッピングをそのテーブル内で見つけることができない場合、一実施形態のメッセージは拒絶される。次いでデータレポートアンサーはＡ４Ｃサーバ２へ送信される（１０）。
【００６０】
一実施形態によれば、トポロジーを隠蔽するメカニズムの基本となるプロトコルはＤｉａｍｅｔｅｒである。Ｄｉａｍｅｔｅｒは、ネットワークアクセスやＩＰモビリティなどのアプリケーションのＡＡＡ（認証、承認、課金）プロトコルである。基本的なコンセプトは、ＡＡＡサービスを新たなアクセス技術へ提供するために、拡張可能なベースプロトコルを提供することである。Ｄｉａｍｅｔｅｒは、ローカルＡＡＡおよびローミングＡＡＡ両方での動作を目的としている。詳細はＲＦＣ３８５５を参照されたい。
【００６１】
しかしながら、本発明を実施するためには、Ｄｉａｍｅｔｅｒプロトコルを使用する必要はない。アドレス体系ベースまたはドメインベースのルーティングをサポートする任意のプロトコルを使用することができる。さらにプロトコルは、送信元ホストアドレス（送信元ホストアドレスＡＶＰ）、宛先ホスト（宛先ホストＡＶＰ）などのヘッダーフィールドをサポートしていなければならない。クライアントのＩＰアドレスに基づいたメッセージルーティングを適用するため、プロトコルがＮＡＳのＩＰプールＡＶＰのヘッダーフィールドをさらにサポートする場合は、一実施形態に基づく上記クライアントのＩＰアドレスに基づいたメッセージルーティングがサポートされていることが好ましい。
【００６２】
上記実施形態に基づく方法は、使用されている実際の規格とは無関係にネットワーク内で実施できることは当業者には容易に理解されるであろう。さらに、当業者は、本発明の実施形態と関連して説明した要素、ユニットおよび装置が、ハードウェア、ソフトウェアまたはそれらの組み合わせにより実現できることを容易に理解するであろう。特に、本発明の実施形態と、これに関連して説明した要素やモジュールとが、コンピュータ上またはマイクロプロセッサ上で実行されるコンピュータプログラムで実現できることが理解されるであろう。
【図面の簡単な説明】
【００６３】
【図１】本発明の実施形態に基づく構成を示す図である。
【図２】本発明のさらなる実施形態に基づく構成を示す図である。
【図３】本発明の一実施形態に基づくマッピングテーブル内のエントリを示す図である。
【図４】本発明のさらなる実施形態に基づくマッピングテーブル内のエントリを示す図である。
【図５】本発明のさらなる実施形態に基づく構成を示す図である。
【図６】本発明のさらなる実施形態に基づく通信スキームを示す図である。
【図７】本発明のさらなる実施形態に基づく通信スキームを示す図である。
【図８】本発明の実施形態に基づくシーケンス図である。
【図２】
0004394701.tif 000002
【図３】
0004394701.tif 000003
【図４】
0004394701.tif 000004
【図５】
0004394701.tif 000005
【図６】
0004394701.tif 000006
【図７】
0004394701.tif 000007
【図８】
0004394701.tif 000008
【図１】
0004394701.tif 000009