JP2010532611A - 通信ネットワークにおける移動性管理及び効率的な情報検索のための方法、装置、及びシステム - Google Patents

Abstract

【課題】通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する方法、及び装置を提供する。
【解決手段】
方法は、モバイル通信装置（１０６）から該モバイル通信装置の識別子を含むレジスタリクエストをドメインルータ（１０３）で受信する（２０４）ステップと、識別子と関連した次回ホップルータ（１０４）へのアドレスをルックアップする（２０５）ステップと、レジスタリクエストを次回ホップルータ（１０４）へ送信する（２０６）ステップと、次回ホップルータ（１０４）からの応答を受信する（２１０）ステップと、応答がホームルータ（１０４）へのアドレスを含んでいる場合、応答をホームルータ（１０４）のアドレスを含むモバイル通信装置（１０６）に送信する（２１１）ステップと、を含み、応答はモバイル通信装置（１０６）とホームルータ（１０４）との間の接続の確立を開始する。
【選択図】図１

Description

本発明は、通信ネットワークにおける情報検索に関し、より具体的には通信ネットワークにおける効率的な情報検索のための包括的なオーバーレイネットワークを形成するための方法および装置に関する。

通信のピア・ツー・ピアモデルは、どのノードも他のいずれのノードのためのサーバとして機能できることを意味する。リソースは、要求ノードにリソースクエリーをピア・ツー・ピアネットワークに入れさせることにより検出される。要求されたリソースを、どのように、及びどのプロトコルによって検索するかは、ピア・ツー・ピアネットワークにおいて利用される検索パラダイムに基づいていて、検索パラダイムは、体系化されていないピア・ツー・ピアネットワークのクエリーフラッディングによるものか、体系化されたピア・ツー・ピアネットワークにおけるいくつかの分散したルックアップメカニズムによるものかのいずれかである。しかし、共通する想定は、要求ノード、ルックアップノード、ターゲットノードを含むすべてのノードが、全てピア・ツー・ピアネットワークの一部であることである。この想定は、使用を制限すると共に、そのサービスを一般的なインターネットモデルよりも限定させる。ここで、インターネットモデルでは、あらゆる登録されたサーバは公共のＤＮＳシステムを通してルックアップされてもよいとの前提である。しかし、ＤＮＳシステムは、サーバは固定のＩＰアドレスを有するとの想定している。現在のＤＮＳシステムが分散されたネームサーバおよびキャッシング原理によって作動する方法のため、アドレス変更を頻繁に行うことは、変更の間にサーバが到達不可能になる可能性があるため、できない。

ダイナミックＤＮＳ（ＤＤＮＳ）は、ＤＮＳシステムに拡大している。ＤＤＮＳは、ネームサーバに保持されたドメインネームデータをリアルタイムにて更新させる。その結果、インターネットドメインネームは、変化する（例えば、動的な）ＩＰアドレスを有するコンピュータ（サーバ）に割り当てられる。そのサービスは、通常、ＤＮＳの登録および更新プロセスを管理しているＤＤＮＳプロバイダーに関与する。ユーザは、変更が検出されるときは常に、ＤＤＮＳプロバイダーのＤＮＳサーバをサーバの最新のＩＰアドレスで更新する。このソリューションによる欠点は、ＤＤＮＳプロバイダーの関与と、ターゲットサーバに到達不可能である間、更新が世界規模のＤＮＳシステムに完全に効果を及ぼす前の潜在的な長応答時間と、を含む。更に、ホストがネットワークアドレス変換器（ＮＡＴ）の背後に位置し、従って、私的な（世界的な、ルーティング可能でない）アドレス範囲からＩＰアドレスを割り当てられるとき、問題を解決する方法は無い。

ＤＮＳおよびＤＤＮＳシステムだけではインターネット上のホスト移動性を十分にサポートすることができないため、多くの方法および技術が提案されている。従来より、ネットワーク層移動性、及び上位層移動性と称される２つのアプローチが存在する。

ＩＰｖ４“のためのＩＰ移動性サポート（ＩＥＴＦ ＲＦＣ ３３４４、 Ｃ． Ｐｅｒｋｉｎｓ、 Ｅｄ．、２００２年８月）、及びＩＰｖ６”における移動性サポート（ＩＥＴＦ ＲＦＣ ３７７５、 Ｄ． Ｊｏｈｎｓｏｎ他、２００４年６月）は、ネットワーク層移動性に関する現在のＩＥＴＥ規格を開示している。モバイルＩＰは、モバイルユーザ（モバイルノードまたはホスト）が、ネットワークとネットワークメディアとの間を推移している間、単一のアドレスを維持すること可能にする。それぞれのモバイルノードは、ネットワークへの現在の接続点に関わらず、ネットワークおよび他の全ての機器に関するユーザから見えないアドレス付与を考慮することにより、常にホームアドレスによって特定される。このノードの動きを把握する必要がある唯一の機器は、モバイル機器およびモバイル機器に代わって機能するホームルータである。このアプローチは、関連するネットワークのＩＰ下層構造におけるサポートに依存しており、常にそのサポートが存在するわけではない。ＮＡＴ通過をサポートするため、モバイルＩＰプロトコルの追加メッセージ拡張機能が必要である（カプセル化されたＵＤＳにおけるＩＰ）。更に、モバイルＩＰは、インターネットプロトコル・スタックの上位層にユーザに意識させずに作動する目的を有するルーティング・ソリューションであるので、モバイルＩＰはモバイル環境で重要になる可能性のあるアプリケーションデータの効率的移送を全くサポートしない。

アプリケーションレベルのエンド・ツー・エンドホスト移動性アーキテクチャは、「ホスト移動性に対するエンド・ツー・エンドアプローチ（Ａ． Ｃ． Ｓｎｏｅｒｅｎ ａｎｄ Ｈ． Ｂａｌａｋｒｉｓｈｎａｎ、 Ｐｒｏｃ． ｏｆ ｔｈｅ Ｓｉｘｔｈ Ａｎｎｕａｌ ＡＣＭ／ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｏｂｉｌｅ Ｃｏｍｐｕｔｉｎｇ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ、マサチューセッツ州ボストン、 ２０００年８月）」に開示されている。それは、アドレス変更に基づき、ＤＮＳシステムに対する確実な更新を用いており、エンド・ツー・エンド接続を切断することなく、ホストのＩＰアドレスの変更を管理するために、接続移行オプションを与える。そのアプローチは、中間ノードが移動性サポートに直接的に関与していないという意味で、全くの端末間である。結果として、インフラストラクチャ自体は、端末・ホスト能力に基づく効率的移送を提供するものでない。更に、そのアプローチは、ＮＡＴを通過する接続移行に関与しているが、ＮＡＴの背後のモバイルサーバに到達するための明確なサポートを与えない。

「意図的なネームシステムの設計および実施（Ｗ． Ａｄｊｉｅ−Ｗｉｎｏｔｏ他、 １７ｔｈ ＡＣＭ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ、 サウスカロライナ州チャールストン、１９９９年１２月）」という従来技術文献は、国際ネーミングシステム（ＩＮＳ）と称される機器およびコンピュータの動的なモバイルネットワークのためのリソース発見およびサービスロケーションシステムを開示している。ＩＮＳは、そのネームに属性および値に基づく別々の言語を用い、ネームリゾルーションとメッセージルーティングとを統合する遅延バインディングメカニズムを実装していて、クライアントに、セッションが進行している間にネーム・ツー・アドレス・マッピングが変化する場合であっても、エンドノードとの通信を続けさせることができる。このように、ＩＮＳアーキテクチャは、アプリケーションレベルのオーバーレイネットワークを形成するために特定のネームレゾルバを必要とする。

モバイルネットワークおよびＭＡＮＥＴ（モバイル・アドホック・ネットワーク）に対処する１つのアプローチは、下層ネットワークの一時的性質を認識したピア・ツー・ピア・オーバーレイルーティング構造を形成するために、「クロスレイヤ最適化」を用いることである。これは、「モバイル・ピア・ツー・ピア・プロトコルの性能評価（Ｉ． Ｇｒａｂｅｒ、 Ｒ． Ｓｃｈｏｌｌｍｅｉｅｒ、及びＷ． Ｋｅｌｌｅｒｅｒ、 Ｆｏｕｒｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｇｌｏｂａｌ ａｎｄ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｃｏｍｐｕｔｉｎｇ （ＧＰ２ＰＣ２００４）、２００４年）」、及び「モバイル・ピア・ツー・ピア・ネットワーキング（Ｗ． Ｋｅｌｌｅｒｅｒ、 Ｒ． Ｓｃｈｏｌｌｍｅｉｅｒ、 Ｉ． Ｇｒｕｂｅｒ、及びＦ． Ｎｉｅｔｈａｍｍｅｒ、 ｐａｔｅｎｔ ＷＯ２００５０４１５３４、２００４年）」に開示されたモバイル・ピア・ツー・ピア・プロトコルにおいて行われているアプローチである。このアプローチによれば、クロスレイヤ通信は、下層の物理的なレイヤでルーティングレイヤを連結するために用いられる。このアプローチは、レイヤを横切る通信を想定している。従って、展開を課題にする。

リソースを拘束されたモバイル機器へのピア・ツー・ピアネットワークの接続に関する問題は、例えば、「モバイル・ピア・ツー・ピア・ネットワークを可能にする（Ｊ． Ｏｂｅｒｅｎｄｅｒ他、 Ｍｏｂｉｌｅ ａｎｄ Ｗｉｒｅｌｅｓｓ Ｓｙｓｔｅｍｓ、 ｌＮＣＳ ３４２７、ドイツ（２００５年））」に開示されているネットワークに接続された部分のコンテンツをキャッシュすること、例えば、「モバイルウェブサーバ、ラクーンプロジェクト（ｈｔｔｐ：／／ｏｐｅｎｓｏｕｒｃｅ．ｎｏｋｉａ．ｃｏｍ／ｐｒｏｊｅｃｔｓ／ｍｏｂｉｌｅ―ｗｅｂ−ｓｅｒｖｅｒ／、 ｖｅｒｉｆｉｅｄ． ２００７−０５−０１）」に開示されている専用のゲートウェイに機器を接続すること、または、例えば、「ＪＸＭＥプロジェクト（ｈｔｔｐ：／／ｊｘｍｅ．ｊｘｔａ．ｏｒｇ／、 ｖｅｒｉｆｉｅｄ． ２００７−０５−０１）」に開示されているアクセスプロトコルを修正することによりシグナリングオーバーヘッドを最小化すること、のいずれかによって、モバイル機器を開放する手段により対応されている。これらのアプローチは、インターネットの実際のエンド・ツー・エンドパラダイムを制限する。

本発明の目的は、少なくとも上記不利な点のいくつかを排除または軽減することであり、通信ネットワークにおける移動性管理及び効率的な情報検索のための改善された方法、装置、及びシステムを提供することである。

本発明は、ノードが包括的なオーバーレイネットワークを形成するとともに、移動可能であり、更に下層ネットワークインフラストラクチャと無関係に移動する、機器及びコンピュータの動的なモバイルネットワークにおいて、通信の効率的、且つ拡張可能性のあるピア・ツー・ピアモデルのためのプロトコルスタックを提供する。

本発明の第１の態様は、通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する方法である。その方法は、モバイル通信装置からそのモバイル通信装置の識別子を含むレジスタリクエストをドメインルータで受信するステップと、識別子と関連した次回ホップルータへのアドレスをルックアップするステップと、レジスタリクエストを次回ホップルータへ送信するステップと、次回ホップルータからの応答を受信するステップと、応答がホームルータへのアドレスを含んでいる場合、応答をホームルータのアドレスを含むモバイル通信装置に送信するステップと、を含み、上記応答はモバイル通信装置とホームルータとの間の接続の確立を開始する。

本発明の第２の態様は、コミュニケーションネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成するためのドメインルータである。そのドメインルータは、モバイル通信装置からそのモバイル通信装置の識別子を含むレジスタリクエストを受信するために用いられる受信機と、識別子と関連した次回ホップルータへのアドレスをルックアップするために用いられるコントローラと、レジスタリクエストを次回ホップルータに送信するために用いられる送信機と、を備え、そこにおいて、受信機は次回ホップルータからの応答を受信するために用いられ、コントローラは応答がホームルータへのネットワークアドレスを含むかどうかを決定するために用いられ、送信機はホームルータのアドレスを含む応答メッセージをモバイル通信装置に送信するために用いられ、上記応答メッセージはモバイル通信装置とホームルータとの間の接続の確立を開始する。

本発明の第３の態様は、通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する別の方法である。その方法は、ドメインルータからモバイル通信装置のためのモバイル通信装置の識別子を含むレジスタリクエストをホームルータにおいて受信するステップと、レジスタリクエストに対応して、ホームルータアドレスを含む応答を作成するステップと、ホームルータのアドレスを含むモバイル通信装置に対する転送応答を開始するためドメインルータに応答を送信するステップと、を含む。

本発明の第４の態様は、通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成するためのホームルータである。そのホームルータは、モバイル通信装置の識別子を含むモバイル通信装置のためのレジスタリクエストをドメインルータから受信するために用いられる受信機と、レジスタリクエストに対応して、ホームルータアドレスを含む応答を作成するために用いられるコントローラと、ホームルータのアドレスを含むモバイル通信装置に対する転送応答を開始するためドメインルータに応答を送信するために用いられる送信機と、を含む。

本発明の第５の態様は、コミュニケーションネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する更に別の方法である。その方法は、ドメインネームサーバに照会を送信することによりホームルータに接続を要求するステップと、ホームルータに接続されたドメインルータへのアドレスを受信するステップと、受信したアドレスのドメインルータにレジスタリクエストを送信することによりホームルータに登録することを要求するステップと、ドメインルータからホームルータに対する参照を付されたレジスタ応答を受信するステップと、レジスタリクエストを作成すると共にホームルータに直接的に送信するステップと、ホームルータとモバイル通信装置との間の接続を確立するステップと、を含む。

本発明の第６の態様は、プログラムがコンピュータ上で動かされるとき、上述の本発明の異なる態様に基づく方法の全てのステップを実行するために用いられるコンピュータプログラムコード手段を含むコンピュータプログラムである。

１つ以上の実施形態において、第６の態様のコンピュータプログラムは、コンピュータにて読み込み可能な媒体に格納されている。

１つ以上の実施形態において、第６の態様のコンピュータプログラムは、キャリヤに担持されたコンピュータプログラムであって、プログラムがコンピュータで動かされるとき、コンピュータに上述の本発明の異なる態様に基づく方法を行わせるためのコンピュータが実行可能な命令を含む。

コンピュータプログラムの１つ以上の実施形態において、キャリヤは記録媒体、コンピュータメモリ、リードオンリーメモリまたは電気的キャリヤ信号である。

本発明の第７の態様は、コンピュータに読み込み可能な媒体を含むコンピュータプログラム製品であって、上記プログラムがロードされたとき、コンピュータに対して上述の本発明の異なる態様に基づくいずれかの方法のプロセスを実行させるためのコンピュータプログラムコード手段を有する。

一組のエンティティを含むネットワークインフラストラクチャであって、１つ以上の構成要素が包括的なオーバーレイネットワークを形成する事例を示す。 モバイル通信装置をモバイルサーバノードとして登録し、図１に示す電子通信ネットワークのオーバーレイネットワークの中でホームルータとの接続を確立する方法の１つの実施形態に模式図である。 １つの実施形態によるドメインルータのブロック図である。 １つの実施形態によるホームルータのブロック図である。 １つの実施形態による移動先ルータのブロック図である。 １つの実施形態による方法の、クライアントがモバイルサーバノード（ＭＮ）からコンテンツを要求するときの模式図である。 第２の実施形態による方法の、クライアントがモバイルサーバノード（ＭＮ）にコンテンツを要求するときの模式図である。 １つの実施形態による方法の、クライアントが別のドメインに属する複数のＵＲＩに関連するリソースを保有するモバイルサーバノード（ＭＮ）にコンテンツを要求するときの模式図である。 １つの実施形態によるピアリング方法の模式図である。 第２の実施形態によるピアリング方法の模式図である。 メタデータクエリーに関する方法の１つの実施形態の模式図である。 オーバーレイネットワークの１つの実施形態を示す模式図である。 図１０のようなドメインルータの経路指定テーブルである。 図１０のような移動先ルータの経路指定テーブルである。 モバイルサーバノード（ＭＮ）による移動後において図１０の更新された場合を示す模式図である。 図１３による移動先ルータ（ＦＲ）の更新された経路指定テーブルである。 １つの実施形態による、モバイルサーバノード（ＭＮ）と現在の接続点の間でダウンストリーム及びアップストリーム

図１は、一組のエンティティを含むネットワークインフラストラクチャ１００の事例を示し、１つ以上のエンティティが包括的なオーバーレイネットワークを形成する。構成要素は、１つ以上のクライアント１０１と、ドメインネームサーバ（ＤＮＳ）１０２と、ドメインルータ（ＤＲ）１０３と、ホームルータ（ＨＲ）１０４と、移動先ルータ（ＦＲ）１０５と、モバイルサーバノード（ＭＮ）１０６と、を含んでよい。

クライアント１０１は、グローバルインターネット１０７にアクセスする従来のホストコンピュータであってよい（オーバーレイネットワークの必須部分ではない）。適切に装備されたクライアントは、いずれのＭＮ１０６にホストされたアプリケーションにもアクセスすることができる。同様に、ＭＮ１０６は、他の状況においてクライアントとして機能してよい。オーバーレイネットワークの一部であるネットワークエンティティは、１つ以上のＤＲ１０３、ＨＲ１０４、ＦＲ１０５およびＭＮ１０６であってよい。図１に示すネットワークインフラストラクチャおよびオーバーレイネットワークのエンティティの数および型は一例であり、本発明の範囲を制限するものでない。

ドメインルータＤＲ１０３は、ルックアップに適したエンティティであり、ある統一資源識別子（ＵＲＩ）または接続点、すなわち要求されたＵＲＩに関連したＭＮのためのＨＲまたはＦＲ、に関する論理ネームの要求をリダイレクトする。ルックアップは、１つ以上のドメインネームサーバ（ＤＮＳ）１０２、ドメインルータ（ＤＲ）１０３、ホームルータ（ＨＲ）１０４、移動先ルータ（ＦＲ）１０５、及びモバイルサーバノード（ＭＮ）１０６、またはそれらの組み合わせを含むオーバーレイネットワークにおいて他のノードと情報交換することにより行われる。

それぞれのＤＲ１０３は、それぞれの列が＜ＵＲＩ、｛次回ホップルータ｝、タイマ＞を含む次回ホップ経路指定テーブルを含む。従って、そのテーブルは、それぞれの登録されたＵＲＩのためのＨＲまたはＦＲのアドレスの次回ホップエントリーに関する順番付きリストを含み、あるＵＲＩ列のためのタイマは、そのＵＲＩに対するそれぞれのルックアップクエリーのために更新される。タイマが終了すると、ＵＲＩ列はテーブルから除去される。ＤＲ１０３は、次回ホップ経路指定テーブルにおいて、全てのＨＲ／ＦＲとの接続を維持する。その接続は、ＴＣＰや、何らかの適切な移送レイヤプロトコルを介してもよい。更に、ＤＲ１０３は、性能及び／または冗長性の理由から、クラスタトポロジーで構成されていてもよい。それぞれのネームドメインは、１つのＤＲエンティティまたは場合によりそのクラスタによって制御される。更に、ＤＲ１０３は、ＤＲ１０３によって制御されたドメインの中のあるＵＲＩに対する現在未解決であって、未解答のルックアップクエリーを有するクライアントに関するアドレスのテーブルを維持する。次回ホップＨＲ／ＦＲからあるＵＲＩに対する最初のクエリー応答を受信すると、ＤＲ１０３は現在未解決のクエリーを有する全てのクライアントに応答し、その結果、クライアント側のルックアップ遅延を最適化する。

ホームルータＨＲ１０４は、ルックアップに適したエンティティであり、あるＵＲＩまたは要求されたＵＲＩに関連したＭＮのための接続点（ＨＲまたはＦＲ）に対する論理ネームの要求をリダイレクトする。ルックアップは、オーバーレイネットワークにおいて他のノードとの情報交換によって行われる。それぞれのＨＲ１０４は、それぞれの列が＜ＵＲＩ、｛次回ホップルータ｝、｛前回ホップルータ｝、タイマ、ダイレクト＞を含む経路指定テーブルを含む。それぞれの登録されたＵＲＩのために、テーブルは、ＨＲまたはＦＲのアドレスの次回ホップエントリーに関する順番付きリスト、ＤＲ、ＨＲまたはＦＲのアドレスの前回ホップエントリーに関する順番付きリスト、ＵＲＩに対するそれぞれのルックアップクエリーのために更新されたタイマ、そのＵＲＩと関連したＭＮがＨＲ１０４と直接接続されているかどうかを示すダイレクトフラッグを含む。この場合、ＨＲ１０４は、ＭＮを対象としているあらゆるルックアップリクエストのため、自身のアドレスで応答する。タイマが終了すると、ＵＲＩ列はテーブルから除去される。ＨＲ１０４は、その経路指定テーブルにおける全てのＨＲ／ＦＲとの接続を維持する。その接続は、ＴＣＰまたはあらゆる適切な移送レイヤプロトコルを介してもよい。いかなるＭＮ（１つ以上）に直接的に接続される場合、ＨＲ１０４は、ＴＣＰまたはあらゆる適切な移送レイヤプロトコルを介して、そのＭＮと直接接続（場合によっては、ＮＡＴやファイアウォールを通じて）を維持する責任がある。ＨＲ１０４は、ＭＮと他のノードとの間のアプリケーショントラフィックのための中継ノードとして機能する。新しいＭＮは、一般的に、場合によっては明確な案内に基づき、オーバーレイネットワークに入るために、そのＵＲＩをＨＲに登録する。ＭＮは他のＨＲとの交信を維持できるが、それぞれの時刻において、ただ１つのＨＲ１０４があるＭＮに対するオリジナルＨＲであってもよい。

移動先ルータＦＲ１０５は、ルックアップに適したエンティティであり、あるＵＲＩまたは要求されたＵＲＩに関連したＭＮのための接続点（ＨＲまたはＦＲ）に対する論理ネームの要求をリダイレクトする。ルックアップは、オーバーレイネットワークにおける他のノードとの情報交換により行われる。それぞれのＦＲ１０４は、それぞれの列が＜ＵＲＩ、｛次回ホップルータ｝、｛前回ホップルータ｝、タイマ、ダイレクト＞を含む経路指定テーブルを含む。それぞれの登録されたＵＲＩのために、テーブルは、ＨＲまたはＦＲのアドレスの次回ホップエントリーに関する順番付きリスト、ＤＲ、ＨＲまたはＦＲのアドレスの前回ホップエントリーに関する順番付きリスト、ＵＲＩに対するそれぞれのルックアップクエリーのために更新されたタイマ、そのＵＲＩを有しているＭＮがＦＲ１０５と直接接続されているかどうかを示すダイレクトフラッグを含む。この場合、ＦＲ１０５は、ＭＮを対象としているあらゆるルックアップリクエストのため、自身のアドレスで応答する。タイマが終了すると、ＵＲＩ列はテーブルから除去される。ＦＲ１０５は、その経路指定テーブルにおける全てのＨＲ／ＦＲとの接続を維持する。その接続は、ＴＣＰまたはあらゆる適切な移送レイヤプロトコルを介してもよい。いかなるＭＮ（１つ以上）に直接的に接続される場合、ＦＲ１０５は、ＴＣＰまたはあらゆる適切な移送レイヤプロトコルを介して、そのＭＮと直接接続（場合によっては、ＮＡＴやファイアウォールを通じて）を維持する責任がある。ＦＲ１０５は、ＭＮと他のノードとの間のアプリケーショントラフィックのための中継ノードとして機能する。あるＭＮに対してＦＲとして機能するノードは、他のＭＮに対してＨＲとして機能してもよい。

モバイルノードＭＮ１０６は、１つのネットワークまたはサブネットから別の１つにその位置を変えると共に、そのＩＰアドレスを変えるホストである。それは、リンクレイヤの接続可能性と割り当てられた有効なＩＰアドレスを仮定することにより、いかなる位置でも他のインターネットノードと通信を続け、他のインターネットノードから連絡可能な状態を維持できる。ＭＮ１０６は、例えば、ＧＳＭ、ＵＭＴＳまたはＷＬＡＮ１０８のような他のシステムまたはネットワークのような、通信システムやモバイルネットワーク１０７のためのモバイル端末として具体化された電子装置に取り付けられていてよい。

上記のエンティティ１０１乃至１０６、及び１０８のあらゆる組み合わせは、１つの機器に共同で配置されていてよく（場合によっては、マルチホーム）、またはそれらが別々の機器に全てインストールされてもよい。以下、これらの論理エンティティを、コンピュータ、ネットワーク接続および通信能力を有する個々の機器で動く別々のユニットのソフトウェアとしてみなしてもよいし、表示するだろう。

図２は、モバイル通信装置をモバイルサーバノードＭＮ１０６として登録し、図１に示す電子通信ネットワークのオーバーレイネットワークにおいて、ホームルータＨＲ１０４との接続を確立する方法を説明する。必要なネットワーク接続条件及び有効なＩＰアドレスの保有に加えて、ＭＮ１０６は、適切なオーバーレイ機能をインストールされている必要がある。この機能は、プログラムがロードされたとき、コンピュータに対してその機能を提供するためにその処理を実行させるためのコンピュータプログラムコード化手段を有するコンピュータ読み取り可能な媒体を含むコンピュータプログラム製品であってよい。

図２の実施形態によると、ＭＮ１０６は、最初ＨＲ１０４の実際のアドレスを知らない。この場合、ブートストラップは、ステップ２０１でＤＮＳクエリーを送信することにより、ＤＮＳ１０２を通じてＭＮ１０６がそのネームを解決することにより実現される。ＤＮＳは、応答できるＤＲのアドレスを探し、それをステップ２０２でＤＮＳ応答を送信することにより返信する。これにより、ＭＮは、ステップ２０３のレジスタリクエストを行うことができる。

１つの実施形態によれば、ＤＲはステップ２０４でレジスタリクエストを受信し、ステップ２０５でそのネームに基づきルックアップを行う。ＤＲは、ある有効なＨＲが特定された場合、ステップ２０６で特定されたＨＲにレジスタリクエストを送信する。ＨＲは、ステップ２０７でＤＲからのレジスタリクエストを受信し、ステップ２０８でそのレジスタリクエストを処理する。ＨＲは、ステップ２０９で要求しているＤＲにレジスタ応答を送信することにより返信する。ＤＲは、ステップ２１０でＨＲからのレジスタ応答を受信する。ＤＲは、ＨＲのＩＰアドレス、例えば「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ＠ＨＰ_ＩＰ」を提示しているＭＮに向かってステップ２１１で応答メッセージを返す。ＭＮは、ステップ２１２でＤＲからのレジスタ応答を受信し、それから、受信したＩＰアドレスを用いることにより特定されたＨＲに対してレジスタリクエストをステップ２１３で直接送信できる。ＨＲがステップ２１４で要求しているＭＮから直接レジスタリクエストを受信したとき、ＨＲは、ステップ２１５で受信したレジスタリクエストを検証する。ＨＲは、ステップ２１７でＭＮによって受信されるレジスタ応答をステップ２１６で送信する。それは、ＭＮとＨＲとの間で直接接続が無事に確立されたことの確認を意味する。上記の連続した処理を完了すると、ＭＮ１０６は、後述するようにインターネットに接続されている他のホストからもアドレス指定可能である。

上記の通り、ＨＲは、それに対してＭＮが登録できるように特定されなければならない。しかし、有効なＨＲがＤＲにおいて知られていない場合には、適切に応答するためにルールが定義されてもよい。動作は、適切なエラーメッセージで返答すること、または１つ以上の代わりのＨＲが明確化されている場合その代わりのＨＲを参照することを含む。ＭＮは、ＨＲにコンタクトし、直接接続が確立される。この接続は、ＭＮが登録取消または終了するまで、例えば、キープアライブメッセージまたは類似のものにより、両方のエンティティによって、モニターされ、維持され、修復される。

ＭＮは、上記の方法の実施形態のように、最初そのＨＲの実際のアドレスを知らなくてもよく、またＨＲのアドレスを知っていてもよい。

後者の場合、ＨＲのＩＰアドレスは、前回のセッションからキャッシュされるか、予め設定されるか、または別の案内で通知されることにより、予め知られていてもよい。この場合、ＭＮが既に「その」ＨＲのアドレスを知っているとき、ＭＮは、ＨＲと直接的に、コンタクトし登録してもよい。

本発明は、上記のような、モバイル通信装置をオーバーレイネットワークにおいてホームルータＨＲに登録する方法の実施形態によって限定されるものではない。本発明のより一般的な実施形態では、最初のブートストラップ及びその後の再登録処理は、以下のステップのいずれかの組み合わせである。
１．ＭＮは、現在のサブネットにおいて放送手段（または専用のアドレスにおけるマルチキャスト）によりローカルディスカバリー（近隣探索）を行う。それは、そのサブネットに存在するＨＲ／ＦＲノードからの直接応答を得ることが可能である。あるいは、それは、そのサブネットに存在する他のＭＮ（すなわち、探索中継エージェントとして機能するＭＮ）から応答として運ばれた受信されたヒントによる、可能性のあるＨＲ／ＦＲノードに対する間接的な参照になってよい。複数の選択肢がある場合、ＭＮは構成可能な基準に基づくアンカーポイントを選ばなければならない。

２．ＭＮはそのＤＲのアドレスを解決し、適当なＨＲまたはＦＲの参照のためにＤＲにコンタクトする。ＤＲは、その応答を様々な評価基準、例えばネットワークの近接性（ホップの数、ピン／トレースルートの待ち時間、オーバーラッピングルート等）、地理的な位置（例えば、ＧＰＳデータに基づく）、容量および報告されている通信量測定結果（例えば、ノードおよびリンクの現在の処理および負荷状況）、またはコミュニティー及び知り合いの個人間の関係に基づいて、もしくは他の手段によって設定されたピアリングコラボレーションアグリーメントに基づくことができる。このプロセスは、他のＤＲ及びＨＲ／ＦＲノード、及び場合によってはオーバーレイにおける他の専用目的サーバからの入力に依存しても、依存しなくてもよい。

３．ＭＮは、いくつかの予め決定された順序スキームに従って、前回のセッションからキャッシュされた、または他の保管場所、一般的にはウェブサイト等から検索された既知のＨＲ／ＦＲノードにコンタクトする。

ＨＲ／ＦＲのそれぞれの登録の際に、ＭＮは、もしあれば最後に接続されたＨＲ／ＦＲのアドレスを提示すべきである。この情報に基づいて、新しいＨＲ／ＦＲは、次回ホップ経路を更新するために最後に接続されたＨＲ／ＦＲにコンタクトする。そのようなアドレスが与えられない場合、ＨＲ／ＦＲは、もしあれば既知のＭＮによる最後の接続点に新しいＨＲ／ＦＲを最終的に導くことにより、ＭＮに登録されたネームに基づいてネーム解決処理を行う。そうでない場合、発信元のＨＲは直接コンタクトされるべきである。

ＭＮは、ネットワークトポロジーにおける変化、ノード障害、移動性のため、例えば、ノードが動き回り、より良い電波状態を検出し、または、他のノードとのクラスタリングのようなメタデータ状態によって、その接続点を変えることができる。

図３（ａ）は、通信ネットワークにおける効率的な情報検索のための包括的なオーバーレイネットワークにおけるドメインルータ１０３のブロック図である。ドメインルータ１０３は、通信ネットワークにおいて、ホームルータ１０４にモバイル通信装置１０６を登録するように構成されている。１つの実施形態によると、ドメインルータ１０３は、モバイル通信装置１０６からのレジスタリクエストを受信するための受信機３０１を含み、ここにおいて、レジスタリクエストはモバイル通信装置の識別子を含む。ドメインルータのコントローラ３０２は、識別子、すなわち要求しているＭＮ１０６と関連した、または関連するようになる、次回ホップルータ１０４または１０５のアドレスをルックアップするために用いられる。更に、ドメインルータ１０３は、次回ホップルータ１０４または１０５にレジスタリクエストを送信するために用いられる送信機３０３を有している。

受信機３０１は、更に、次回ホップルータ１０４、１０５からの応答を受信するために用いられる。コントローラ３０２は、応答がホームルータ１０のネットワークアドレスを含んでいるかどうかを決定するために用いられる。そして、送信機３０３は、ホームルータ１０４のアドレスを含む応答メッセージをモバイル通信装置ＭＮ１０６に送信するために用いられる。応答メッセージは、それがモバイル通信装置によって受信されて、処理されると、モバイル通信装置とホームルータとの接続の確立を開始する。

図３（ｂ）は、通信ネットワークにおける効率的な情報検索のための包括的なオーバーレイネットワークにおけるホームルータ１０４のブロック図である。１つの実施形態によると、ホームルータ１０４は、受信機３１１、コントローラ３１２及び送信機３１３を含む。受信機３１１は、ドメインルータ１０３からのモバイル通信装置１０６のレジスタリクエストを受信するために用いられる。レジスタリクエストは、モバイル通信装置１０６の識別子を含む。コントローラ３１２は、レジスタリクエストへの応答として、ホームルータアドレスを含む応答を発生させるために用いられる。送信機３１３は、モバイル通信装置１０６にホームルータのアドレスを含む転送応答を開始させるように、ドメインルータ１０３に応答を送信するために用いられる。

１つの実施形態によると、受信機３１１は、次に、モバイル通信装置１０６からのレジスタリクエストを受信するために用いられる。更に、コントローラ３１２は、モバイル通信装置１０６からのレジスタリクエストへの応答として、ホームルータ１０４とモバイル通信装置１０６との間の接続を確立するために用いられる。

図３（ｃ）は、通信ネットワークにおける効率的な情報検索のための包括的なオーバーレイネットワークを形成するための移動先ルータ１０５のブロック図である。１つの実施形態によると、移動先ルータ１０５は受信機３２１、コントローラ３２２および送信機３２３を含む。

図４は、１つの実施形態の方法の、クライアントがＭＮからコンテンツを要求するときの模式図（フローチャート）である。この実施形態は、ＨＴＴＰ ＧＥＴを発行することによりウェブページ等を要求するクライアントを説明する。ステップ４０１で、クライアントは、ウェブアドレス「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」によるＤＮＳクエリーをＤＮＳシステムに送信する。ＤＮＳネームサーバは、ステップ４０２で「ｅｘａｍｐｌｅ．ｃｏｍ」ドメインのためのＤＲのＩＰアドレスを応答する。次に、クライアントは、ステップ４０３で「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」アドレスを有するＨＴＴＰ ＧＥＴをＤＲのＩＰアドレスに送信する。受信されたＨＴＴＰ ＧＥＴに対応して、ＤＲはステップ４０４で、ルックアップクエリーが送信されるべき次回ホップルータを次回ホップ経路指定テーブルにおいてルックアップする。ルックアップクエリーを受信するＨＲは、直接接続されるように要求されたＭＮのアドレスを特定し、その結果、ステップ４０５において、自身のＩＰアドレスを含むルックアップ応答を送信する。ＨＲは、ＨＲがＭＮのオリジナルＨＲであればそれ自体を選択するか、または他のノード、すなわちオーバーレイネットワークにおける他のＨＲ及び／またはＦＲと情報交換するか、のいずれかによって、要求されたＭＮのＨＲを特定する。この実施形態では、ダイレクトフラッグは、そのＵＲＩと関連しているＭＮがＨＲ１０４と直接接続されていることを示す。従って、この場合ＨＲは、対象としているＭＮへのルックアップリクエスト、すなわち「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」のために自身のアドレスで応答する。ＨＲからのルックアップ応答に対応して、ＤＲは、ステップ４０６で、要求されたＭＮに接続されたＨＲのＩＰアドレスを含む、要求しているクライアントへのＨＴＴＰリダイレクトメッセージを作成すると共に送信する。従って、クライアントは、ステップ４０７において、要求された情報を有しているＭＮに接続されたＨＲに対してＨＴＴＰ ＧＥＴ「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」を送信してもよい。ＨＲは、要求された情報、すなわちウェブページ「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」にアクセスするために、ステップ４０８において、埋め込まれたＨＴＴＰ ＧＥＴ「ａｌｉｃｅ．ｅｘａｍｐｌｅ．ｃｏｍ」を作成して、ＭＮに送信する。ＭＮは、ステップ４０９において、埋め込まれたＨＴＴＰ ２００ ＯＫをＨＲに応答する。受信された埋め込まれたＨＴＴＰ ２００ ＯＫに対する応答として、ＨＲはステップ４１０において、要求されたウェブページのために、要求しているクライアントへＨＴＴＰ ２００ ＯＫを作成して送信する。そのユーザは、要求されたウェブページの情報にアクセス可能になる。

更なる実施形態では、当業者は、以上の方法を代替のアプリケーションプロトコルに適用できることを理解するだろう。この実施形態に示すように、最終的な宛先、すなわちＭＮのアドレスは、クライアントから隠されている。クライアントは、ＨＲ（またはＦＲ）がクライアントとＭＮとの間のメッセージを中継している間に、ＭＮのＨＲ（または別の状況ではＦＲ）とのＴＣＰ接続を確立する。ほとんどのクライアントは、将来の要求のため、ＭＮのＨＲ（またはＦＲ）のアドレスをキャッシュすることができるため、このタイプのルックアップは、予め知られていないクライアントのために行われなければならないのみと推測される。実際、これは現在のウェブブラウザに関する典型的特徴である。更に、ＤＲが少なくとも１つの今まで未解決のルックアップを有する特定のＵＲＩ／ネームのための付加的なリクエストを受信する場合、ＤＲは、要求している全てのクライアントに応答メッセージを送信するために、最初に戻るルックアップ結果を用いてもよい。その結果、更にクライアントのルックアップ遅延を最適化できる。

図５は、第２の実施形態の方法の、クライアントがＭＮ１０６からコンテンツを要求するときの模式図（フローチャート）である。この実施形態では、ＭＮ１０６は、別のサブネットに移動し、上記の再登録プロセスによって新たに登録した。ＭＮ１０６が別のゲートウェイに移動したとき、またはネットワークトポロジーが変化した場合も、同様である。ＭＮ１０６は、２つの代替のＦＲ１０５ａおよび１０５ｂと共に順次登録されている。ここに示された状況で、登録プロセスは、ＤＲ１０３−ＨＲ１０４−ＦＲ１０５ａ−ＦＲ１０５ｂから成る「ルックアップチェーン」を形成し、そこで、最下部のＦＲ１０５ｂがＭＮの現在の接続点である。

ＭＮは、ハンドオーバーによって新しいＦＲに移動してもよく、または上記理由によりそのＨＲに戻ってもよい。ハンドオーバーは、進行中のアプリケーションセッションを阻害しないように、オーバーレイによって制御される。移動によって、新しい接続点（ＨＲ／ＦＲ）が最後の既知の接続点（ＨＲ／ＦＲ）にコンタクトするとき、いかなる過去の関係も次回ホップ経路指定テーブルを調査することによって検出される。結果として、ループは発生せず、ルックアップパスにおける経路数は最小限に保たれる。以下、このプロセスの詳細につき、具体的に説明する。

図５において、メッセージングステップ５０１乃至５０４は、図４のメッセージングステップ４０１乃至４０４に等しい。しかし、図４のメッセージ４０５のように直接応答することが可能であるのに対して、ＨＲ１０４は、クエリーを「ルックアップチェーン」を下って、すなわち、図５に示すＦＲ１０５’を介したステップ５０５及び５０６、及びアンカーのＦＲ１０５”を通して伝播しなければならない。アンカーのＦＲ１０５”は、リダイレクトメッセージがステップ５１０でクライアント１０１に戻るように、ステップ５０７においてルックアップ応答を返し、応答はステップ５０８でＨＲ１０４に、ステップ５０９でＤＲ１０３に届く。そして、クライアント１０１は、ステップ５１１でリクエストをアンカーのＦＲ１０５”に向けて伝達する。それによって、アンカーのＦＲ１０５”は、ステップ５１２でリクエストをＭＮ１０６に中継する。ＭＮ１０６からの応答は、ステップ５１３、５１４によって、アンカーのＦＲ１０５”を介してクライアントに直接届く。

図６は、異なるドメインに属する複数のＵＲＩに関連したリソースを有するＭＮ１０６を示す。各ドメインは、別々のＤＲ、この実施形態ではＤＲ１０３ａおよび１０３ｂにより制御されている。ＭＮ１０６のリソースは、適切なＤＲ１０３ｂを通るあらゆるＵＲＩに対するルックアップリクエストを介してアクセス可能である。そこで、それぞれのリクエストは、ステップ６０１及び６０２で従来のＤＮＳルックアップにより適切なＤＲ１０３ｂに伝達される。ここに示された実施形態において、リクエストは、ＭＮ１０６の第２のドメインのＵＲＩに対して作成される。この場合、第１のドメインにおけるＨＲ１０４ａとＦＲ１０５ａは、第２のドメインにおけるＨＲ１０４ｂに対するＦＲとして機能する。メッセージ６０１乃至６１２は、従って、図５に示すメッセージ５０１乃至５１２に類似する。

図５に示すようなあるＭＮを有する複数のＵＲＩに関連付け及びアドレス指定する方法および手段は、第１のドメインのＨＲ１０４ａに、それら同士との間、及び第２のドメインのＨＲ１０４ｂとの間のピアリングアグリーメントを設定させることにより実現される。
そのようなピアリングアグリーメントは、１つのＨＲによって別のＨＲに対して発行される明確なピアリング案内によって、または、場合によりオンデマンドで、１つのＨＲに別のＨＲとのピアリング関係を要求させることによって、確立される。ピアリング接続は、予め確立されていてもよく、またＭＮがネットワークとの接続を確立することを要求するとき、要求に応じて確立されてもよい。

上記のホストネーム・エイリアシングに関するＨＲピアリング方法に対する代替手段、及び補完手段は、ＤＲエイリアス・マッピング法である。この実施形態を図７に示す。この場合、それぞれの第２ドメインのＤＲ１０４ｂの管理者は、それらのＤＲにおけるＭＮ１０６のリソースのネームエイリアスを有する第１ドメインのＤＲ１０４ａのアドレスの関連性を登録してもよい。このように、ＭＮ１０６のエイリアスに関するあらゆるリクエストは、ステップ７０１及び７０２のＤＮＳルックアップの後に、ステップ７０３で第２のＤＲ１０３ｂに伝達される。ステップ７０４におけるリダイレクト応答に続き、ステップ７０５においてルックアップリクエストを第１ドメインのＤＲ１０３ａに伝達する。
次に、上記の第１のドメインにおける連続したルックアップリクエストは、ステップ７０６乃至７０９において行われる。そして、ステップ７１０のルックアップ応答に基づいて、要求するクライアントから現在のＦＲ１０５アンカーノードに対する直接コンタクトがステップ７１１で行われ、リクエストは、ステップ７１２において、ＦＲ１０５とＭＮ１０６との間の予め確立されている接続を通じて中継される。

ＨＲピアリングは、上記のホストネーム・エイリアシングのために存在してもよいが、代替のアクセスシナリオを提供することを含め、他の理由のために存在してもよい。代替のアクセスシナリオを保有する代表的な理由は、ネットワークの近接性及びクラスタリング、または性能及びや冗長性に関する理由を含む。このタイプのピアリング関係は、オンデマンドによって一般的に発生し、それらは、現在のノード位置、またはより複雑なメタデータ処理結果などのいくつかのリアルタイムの評価基準によって決定されてもよい。図８は、ピアリング方法の実施形態を示す。２つのＤＲ１０３ａ、１０３ｂは、ホストネーム・エイリアシング関係を通して関連する必要はなく、２つの別々のドメインを制御する。ＭＮ１０６は、図２に関連する上記のブートストラッピング及び登録のための方法を用いることにより、今まで知られていないＦＲ１０５ｂノードを発見する。発見後、ＭＮ１０６は、２つのＨＲ１０４ａと１０４ｂの間のピアリング関係を設定するため、ステップ８０１でリクエストを発行する。リクエストは、ＭＮ１０６のＨＲ１０４ａへのアドレスをパラメータとして含む。新たに発見されたＦＲ１０５ｂは、ステップ８０２でＨＲの全てまたはおそらく選択されたサブセットにピアリングリクエストを伝播する。それは、この場合、直接または間接的（他のＦＲを介して）にＨＲ１０４ｂに接続される。リクエストを受信するＨＲは、ステップ８０３のようにピアリングリクエストをＭＮ１０６のＨＲ１０４ａに送信する。ＭＮ１０６のＨＲ１０４ａは、ステップ８０４でＯＫを応答するか、または応答しない。それは、ステップ８０５及び８０６により、順次ＭＮ１０６に対して伝播されて戻される。要求されたピアリングが確立されると、ＨＲ１０４ａとＨＲ１０４ｂ、更にはＦＲ１０５が接続される。

この実施形態で説明されたように、新しく発見されたＦＲ１０５ｂは、ＦＲがメンバーであるルックアップチェーンに沿って前から存在するノード（ＨＲまたはＦＲ）にそれらを伝播するのでなく、ピアリングリクエストの一部または全てをフィルタリングによって除去するように構成されていてもよい。これは、そのようなピアリングリクエストが、ルックアップチェーンにおいてＦＲを有するＨＲに必ず転送される必要はないことを意味する。更に一般的な実施形態では、この種類のピアリングリクエストを受信するＦＲは、現在のフィルタリング評価基準によって許容されている場合にのみ、前から存在するノード（ＨＲまたはＦＲ）のいずれかにリクエストを転送してもよい。代表的なフィルタリングルールは、あるドメインに属すノードによって作成されたそれらのリクエストのみを転送することを含んでいてよい。別のフィルタは、要求しているノードの関係に応じて、リクエストを特定のＨＲに伝達してもよい。フィルタリングの理由は、ビジティングノードに対するアクセス認可であってもよい。

本発明は、また、システムに参加するノードにより生じたメタデータの収集、保存、インデックスを付けた検索を行うために、分散されたシステムを構成する。代表的なアプリケーション例は、ＧＰＳ機能を備えたＭＮに関する。ＭＮは、登録の間、及び／またはその後時間間隔毎に、そのＧＰＳデータを接続点ＨＲ／ＦＲに伝達してもよい。接続点は、場合によっては関連データインデックス付け及び処理を行った後、ＧＰＳ関連のメタデータ、またはシステムにおける他のノード（代表的にはＭＮのＨＲもしくはＤＲまたは他の目的用の（メタデータ）サーバのセット）に対してあらかじめ設定されたそれらのインデックスを格納、及び伝播してもよい。ＨＲ／ＦＲにおけるメタデータのインデックス化に関して更に効率的な使用が可能であり、そのようなメタデータを伝播する代わりに、「メタデータインデックス」の通知だけを伝播する。すなわち、関連ＤＲ（複数のＤＲ、または、該当すれば、他の専用サーバのセット）にメタデータが利用可能であること、及びその後のクエリングのためにどのタイプが必要であるか、を通知する。別の簡単なメタデータアプリケーションの実施形態は、ＭＮ（及びそれらのオーナー／ユーザ）がユーザコミュニティを設立し維持するために、互いに検索及び位置確認することを可能にするために、オーバーレイのメタデータ・インフラストラクチャを用いることである。これは、ＭＮがその接続点（ＨＲ／ＦＲ）において、例えば、単一のコミュニティー特有のＩＤによって自身を登録し、そのシステムが、このＩＤによって他のユーザを検索及び位置確認することができる場合、実現される。
そのように、あらゆるＭＮの、ネットワーク位置及びＧＰＳデータが存在する場合の実際の地理的な位置は、システムの他のＭＮによって決定されてもよい。更なる実施形態において、当業者は、現在のメタデータオーバーレイインフラストラクチャにおいて、上記のアプリケーションが更に拡張され、組み合わされることが可能であることを理解するものと思われる。上の図２に関連して説明したＭＮブートストラップ及び登録プロセスにおけるメタデータ検索及びクエリー操作を統合することは、一般的に都合がよい。

図９は、メタデータクエリーのための方法の実施形態を示す。この実施形態では、ＭＮ１０６ｂは、ステップ９０１でそのメタデータをＦＲ１０５ｂに伝達する。メタデータは、適用されるフィルタリングルールに応じて、場合によりいくつかの処理が行われた後で、どのインデックスポリシーがドメインＢで用いられているかに応じて、ステップ９０２でＭＮ１０６ｂのＨＲ１０４ｂに、ステップ９０３でＤＲ１０３ｂにそれぞれ順次伝播されてよい。ここで、格納されたメタデータ情報は、他のＭＮと共有できる。この実施形態では、別のドメインＡの別のＭＮ１０６ａは、マッチングデータを有する他のピアのために、ステップ９０４でメタデータクエリーを発行する。ＦＲ１０５ａは、ステップ９０５で、クエリーを行っているＭＮのＨＲに伝播し、ドメイン内クエリーを意味するドメインポリシーにより許容されるなら、ステップ９０６で、ドメインＡの同一のＤＲ１０３ａの下の全てのＨＲ１０４ａ’に順次クエリーを伝播してもよい。ドメインの全てのＨＲのアドレスは、そのドメインのＤＲによって格納および制御されてよい。そのドメインのそれぞれのクエリー受領ＨＲは、整合するメタデータ（上記の通り）が収集されていることを示したそれらのＦＲにそれらのクエリーを転送し、最終的にステップ９０７で応答が発信元のＨＲ１０４ａに戻るように導く。クエリーがどのように且つどのＦＲに伝達されるかを指示するクエリープロセスは、有向非巡回グラフのための予め決定された、例えば、横型検索または縦型検索のようなグラフ検索アルゴリズムに従ってよい。クエリーは、クエリーを行っているＨＲ１０４ａが直接ピアリング関係を持っている他のドメインのＨＲ（この実施形態では、ドメインＢのＨＲ１０４ｂ）にステップ９０８で伝播されてもよい。ピア関係にあるドメインＢのＨＲ１０４ｂは、次に、ステップ９０９でそのＤＲ１０３ｂに、発送元ドメイン、すなわちドメインＡからのドメイン内転送がドメインＢにおいて許容されているかを問い合わせてもよい。それが許容されている場合、クエリーは、ドメインＢのドメイン内において、ステップ９１０で他のＨＲ１０４ｂ’に伝播される。応答は、ステップ９１１で収集され、最終的にステップ９１２でドメインＡの発信元ＨＲ１０４ａに戻される。同様に、オリジナルクエリー内にそのように示されている場合、他のドメインのピア関係にあるＨＲ１０４ｃは、ステップ９１３でそのピア関係にあるＨＲ１０４ｃ’にクエリーを転送してもよい。その結果、この場合ドメインＣに対して間接的なピアリングクエリーを実施する。ドメインＣのＤＲ１０３ｃによって許容されている場合、ドメイン内クエリーはドメインＣ内で行われてもよい。検索応答は、ステップ９１４でＦＲ１０５ａにより受信され、最終的にステップ９１５でＭＮ１０６ａに中継される。

ＤＲは、そのドメインにおけるそれぞれのＨＲへのＴＣＰ接続または他の適切な移送レイヤ接続を維持する。冗長性に関する理由のため、それは、ネットワークの状況変化によりそれぞれのＨＲから伝播されたアドレス情報に基づいて、次回のＦＲとの２番目の接続を確立してもよい。図１０の状態に基づく、ＤＲ１０３の経路指定テーブルを図１１に示す。図１０に示すように、第１アドレスは、ＦＲ１０５及び１０５ｘの２つの飛び点のノードを指定していて、第２オプションとしてＨＲ１０４および１０４ｘを用いているが、これらは第１のルックアップ経路が機能しない場合にのみ使用される。冗長性経路は、ルックアップチェーンの全体または一部、ＤＲ１０３から、中間のＨＲ／ＦＲノード１０４、１０５、１０５’及びアンカーのＨＲ／ＦＲノード１０５”を超えて、最終的にＭＮ１０６ノードにまで及んでいてよい。また、冗長性の理由のために、いくつかのＨＲおよびＦＲノードをＭＮに接続させ、その結果、ＭＮに対する複数のアンカーノードを発生させることも可能である。ここで用いられた第１経路／第２経路冗長性戦略にもかかわらず、別の実施形態では、特定のＵＲＩをホスティングする特定のＭＮに導くルックアップチェーンにおいて、相互接続されたノード間に迂回経路を用いることが可能であることを示している。

冗長性および故障回復の理由のための機能、例えば、再試行スキーム（例えば、指数関数のバックオフタイマを含む）は、あらゆる２つのノード間の移送接続を制御するために設けられていてよい。無反応のノードに関係する経路を発見し、修理するためにこのような修復機構を用いることが必須であることは理解されるべきである。

ＨＲおよびＦＲノードは、ＴＣＰ接続を用いてＤＲ、ＨＲ、ＦＲ及びＭＮノードに接続してもよい。ここで、１つのＴＣＰ接続は、多くのルックアップ経路により用いられていてもよい（ルックアップリクエストを伝播するため）。ＴＣＰ以外の移送プロトコルは、代替の実施形態において用いられてもよい。それぞれのＴＣＰ接続は、図１０を参照した図１２にその事例を示す経路指定テーブルに関連している。冗長性接続が用いられてもよい。これは、この実施形態のそれぞれの指示における２つの代替案によって説明される。経路は、ＭＮ登録の間またはトポロジー変化（例えば、ノードが故障したとき）のための、シグナリングを用いて構成される。タイマは、ＵＲＩアドレスをホスティングするＭＮに対するそれぞれのルックアップイベントまたはハートビートによって、即座にまたは増加的に更新される。ノードのタイマの期限が終了した（設定可能な限界に達した）場合、タイムアウトしたエントリーは、近隣のノードに一連の信号を送った後でテーブルから除去されてよい。シグナリングは、隣接するノードにおける一連の経路指定テーブルイベントを開始する。一般的に、第１および第２の経路（２つの冗長性経路がＵＲＩ毎に使用される場合）は、タイムアウトしたノード以外のノードを指定するように更新される。必要な場合、新しいＴＣＰ接続が構成される。そうでない場合、既存のＴＣＰ接続の経路指定テーブルが変更される。ＵＲＩを有するＭＮが問題のノードに直接接続されている場合、ダイレクトフラッグがセットされる。その場合、このＵＲＩのためのタイマは活発ではない。ルックアップチェーンが長くなり過ぎないことを保証するために、不活発が検出された場合、ノードは、それ自身が特定のルックアップチェーンから除去されてもよい。ルータノードは、ＭＮとの低活性の関係を検出する責任を持つ。ノードが、あるＭＮとの関係でそのＭＮに十分なだけの長い時間直接接続されていないことを検出した場合（タイマ値によって検出、場合によって活発性測定と組み合わせ）、そのノード自身のチェーンからの除去を開始する。これを達成するために、ノードは、このＭＮのルックアッププロセスに関係する全ての近接したノード（すなわち、その第１および第２接続を介して接続されたノード、及びそれに第１または第２接続されたノード）とコンタクトしなければならない。ネットワークを再構築する責任は、残りのルータノードにある。

図１３は、図１０において「ｂｏｂ．ｅｘａｍｐｌｅ．ｃｏｍ」のＭＮ１０６がアドレス４５．６７８．９１．９を有するＦＲ１０５‘に移動した後の更新された場合を示す。図１４は、移動後のアドレス２３４．５６７．８９．２を有するＦＲ１０５の更新された経路指定テーブルを示す。図に示すように、第１及び第２のアドレスは、ＦＲの経路指定テーブルにおいて、現在のＭＮに関するエントリーと交換されている。これは、前段落で説明し、ここで更に説明するように、ノードのチェーンで交換される経路シグナリング更新メッセージの結果である。ノードＤＲ−ＨＲ−ＦＲ１−ＦＲ２を有するルックアップチェーンを１つの例として考えると、ＭＮはＦＲ２に直接接続されている。以下のステップは、ＭＮが、新しい、過去に用いられていない接続点であるＦＲ３に移動する場合に行われる。
ステップ１．ＭＮは、その移動に関してＦＲ２に連絡する。この時点から、ＦＲ２は、別の方法を連絡されるまで、ＭＮに対するあらゆるサービスリクエストに、一時的エラーメッセージを応答する。
ステップ２．ＭＮは、ＦＲ３に接続する。
ステップ３．ＦＲ３は、ＦＲ２にＭＮの新しい位置を知らせるメッセージを送信する。
ステップ４．ＦＲ２は、応答するとともに、ＦＲ３にチェーンにおいて先行するルータ（ＦＲ１）を連絡する。
ステップ５．ＦＲ３は、２ステップ戻ったルータ（ＦＲ１）に接続すると共に、それ（ＦＲ１）に前回のルータ（ＦＲ２）と第２接続を行うと同時に、自身（ＦＲ３）と第１接続を構成することを連絡する。影響を受けたノードの接続は、更新される。

ＭＮが、新しい、過去に用いられていない接続点に移動する代わりに、既にチェーンにあるルータに接続する場合、前回の接続点ノードはその経路指定テーブルを変えない、また前回の接続点ノードの「前任者」もその経路指定テーブルを変えない（その「前任者」が新しい接続点になるのでない場合）。これは、チェーンが、前回の接続点の周りでノードの変化の影響を受けないようにしている。代わりに、唯一の変化は、次回の第２接続上の新しい接続点となる「前任者」のノードにおいて起こる。この変化後、ＭＮの現在の接続点に先行する２つのノードが、それらの第１接続を有するノードを示す。従って、これらのルータのどれがルックアップに関係している場合であっても、私たちは第１の接続を最初に試すため、私たちは正しいノードで終わる。ＭＮが別の移動を行う場合、私たちは、ルーティングエントリーをそれらがこの最後の変化の前にあった状態に戻し、チェーンのこの部分を移動前の状態で残す。このようなチェーン内の移動を扱う１つの主な理由は、循環の形成を避けると共に、各ルータに対して１つの第１及び１つの第２の経路以上の経路を決して設けないためである。

ＭＮが１つのノード、例えばノードＡ、から別のノード、例えばルックアップチェーン（ＭＮに対するルックアップを行う相互接続されたノードの連続）における前回部分ではないノードＢに移動するとき、ルックアップチェーンの新しいブランチが形成される。ノードＡは、新しいアンカーノードＢを介して、ＭＮから登録メッセージを受信することによりその移動を知らされる。新しいブランチに接続する前に、ノードＡは、現在孤立したルックアップチェーン内の後継者ノード（存在する場合）が適切に切り離されることを確実にする。切り離しは、それらの後継者ノードに分解メッセージを送信することにより行われる。この実施形態では、ノードＡは、現在無効なチェーン内の後継者ノードに、ＭＮに対するエントリーが無効であると言う分解メッセージを送信する。特定のＵＲＩアドレスに関する分解メッセージを受信したノードは、そのＵＲＩに対する経路指定エントリー（全ての方向に）をクリアして、次に、無効なチェーンの端に達するまでルックアップを処理するように、分解メッセージを転送する。ＭＮが再び接続する可能性があるため、格納された情報の有効活用のため、エントリーの残りはタイムアウトに達するまでテーブルに保持される。ノードＡは、それから、その経路指定テーブルを適宜変更し、ノードＢと接続し、ルックアップ経路の「前任者」に対して経路セットアップメッセージを伝播する。更に、ノードＡは、ノードＢにその「前任者」のアドレスを、ノードＢにその「前任者」と相互接続させるために、連絡する。無効なチェーンが生じたときそれらを除去する１つの重要な側面は、チェーンの自動剪定（刈り込み）である。過去に用いられていないルータへの移動の大部分は、チェーンにおける最後のルータ以外のルータから発生すると予想でき、この現象はかなり一般的である。結果として、ＭＮが以前に上記の分解処理を用いたチェーンから切り離されたルータに戻る場合、そのルータは、過去に用いられていないルータの場合と同様にチェーンに組み入れられる。

別の実施形態において、ＭＮがＳＴＵＮＴサーバ機能を含んでもよいことに注意すべきである。その結果、ＳＴＵＮＴクライアントの機能を有するクライアントは、ＮＡＴ横断が成功する場合、ＳＴＵＮＴシグナリング及び横断プロセスの後に（ＨＲ／ＦＲ中継接続の代替手段として）、ＭＮとの直接接続を確立することができる。現行のシステムでは、これは、図４のステップ４０５及び４０６のメッセージのルックアップ応答においてＳＴＵＮＴオプションを含むことにより解決される。従って、ＳＴＵＮＴオプションが設定されるなら、ＨＲ／ＦＲおよびＭＮノードは全てＳＴＵＮＴ能力を有し、更にクライアントがＳＴＵＮＴ能力を有することを示すことにより、メッセージ７を送る代わりに、ＳＴＵＮＴシグナリングおよび横断プロセスが開始される。当業者にとって、他のＮＡＴ横断メカニズム及び技術、例えばＩＣＥフレームワークの中で言及したものは、上記のＳＴＵＮＴソリューションの代替または追加として用いてもよいことは明らかである。

１つの実施形態では、ＭＮは、１つまたはいくつかのＨＲ／ＦＲノードと同時に１つまたはいくつかのアクティブな接続を維持してもよいことに注意すべきである。複数の接続が、確立され、より高い全バンド幅容量にするため並行して使用されてもよい。確立された接続の全てがアクティブでなくてもよく、冗長性に関する理由により維持されてもよく、バックアップまたは代替経路として用いられてもよい。すなわち、「ホット」および「コールド」の両方の予備接続が可能であり、操作上の要求に応じて使用される。ＭＮに関係するアプリケーションが別の接続を用いることは、可能であるが、必要でない。しかし、これらのアプリケーションの１つまたはいくつかは、並列接続を横断して伝達することも可能である。その結果、データ転送の間、複数のＨＲ／ＦＲエンティティに関係する。この場合、アプリケーションデータは、冗長性を保ち、複製されたデータを並列に伝達されてもよく、またデータ転送は、並列接続を横断して分割されてもよい。異なる接続は、例えば、ＷＣＤＭＡ、ＨＳＰＡ、ＥＤＧＥ、Ｗｉｍａｘ、ＷｉＦｉ、イーサネット（登録商標）、ブルートゥース、ＵＳＢのような当業者に従来技術の１つであることが明らかな、異なる伝達手段を用いてもよい。更に、ＭＮと、１つまたはいくつかの接続されたＦＲ／ＨＲノードとの間で維持されている接続のセットは、場合によってはアンカーＦＲ／ＨＲの制御下において、更に場合によってはオンデマンドで常に最適の伝達手段及び接続を選択し、それらの接続の違いの間につなぎ目がなく且つ途切れない方法により、データを伝達し、その後その伝達データをハンドオーバーするためのアプリケーションセッションを許容すべきである。ここで、「最適」は、費用、信頼性、サービスの質、バンド幅及び容量、消費電力、位置及び空間的な存在等のような様々な評価基準の組み合わせにより決定されてよい。そのようなハンドオーバースキームは、ＭＮに実装されたハンドオーバースキームと、例えば、次の段落で説明するような新しく確立された接続または既に存在している接続を介してＭＮに接続されたＨＲ／ＦＲと、により開始され制御されてもよい。

１つの実施形態では、ＭＮは、同一のローカルエリアネットワーク（ＬＡＮ）に存在するＨＲ／ＦＲノードと、および／またはブルートゥースやＵＳＢのような狭い範囲の通信技術が届く範囲内にあるＨＲ／ＦＲノードと、直接的または間接的に接続していてよい。そのような接続は、例えば３ＧからブルートゥースまたはＷＬＡＮへの絶え間ないハンドオーバー、及びその逆を考慮すると、スタンドアロンまたは上記の他の伝達技術と並列に使用されてよい。説明した局所的接続性能力により上記のオーバーレイネットワークソリューションを拡張することによって、ユーザは、局所的に存在するＭＮに、オーバーレイネットワークインフラストラクチャを利用せずに、ＭＮと局所的に存在するＦＲ／ＨＲエンティティとの間でパーソナルエリアネットワーク（ＰＡＮ）を形成することにより、接続することが可能である。そのようなローカル接続が可能であり、局所的に存在するＦＲ／ＨＲモジュールがオーバーレイインフラストラクチャに接続されている場合、ＭＮは、局所的に存在するＦＲ／ＨＲエンティティを介して、オーバーレイネットワークインフラストラクチャに接続できる。それは、より良い接続性ソリューションを提供する。後者の場合、局所的に接続されたＦＲ／ＨＲは、オーバーレイネットワークの一部として、ＭＮ及びいくつかの要求しているクライアントに対応する。局所的に存在するクライアント、例えばウェブブラウザ・クライアントが局所的に存在するＦＲ／ＨＲを含むＰＣに存在し、且つクライアントが局所的に存在するＦＲ／ＨＲと過去に接続されてない局所的に存在するＭＮからのコンテンツをリクエストする場合、アプリケーションセッションにおけるつなぎ目のないハンドオーバーは、オンデマンドでＭＮとＦＲ／ＨＲとの間のローカル接続を確立して、ローカルホストソケットを介してＦＲ／ＨＲにリクエストを伝達することにより可能となる。これを達成するための手順は以下の通りである。尚、ローカル接続のためにブルートゥースを想定している。
１．ＭＮとローカルＨＲ／ＦＲを対にすることにより、ブルートゥースの上の接続を、発見し、確立する。
２．ローカルホストソケットを開けて、ＭＮおよびローカルＨＲ／ＦＲそれぞれに入ってくるトラフィックを待つ。
３．ＭＮは、ローカルホストソケットへのリダイレクト応答でクライアントから受け取ったあらゆるリクエストに応答するように、現在のオーバーレイＨＲ／ＦＲに指示する。
４．オーバーレイＨＲ／ＦＲは、クライアントのＰＣのローカルホストソケットにリダイレクトを戻す。
５．クライアントのＰＣのＦＲ／ＨＲエンティティは、ブルートゥース接続を介して、受け取ったリダイレクトされたリクエストをＭＮに伝える。
６．ＭＮは、リダイレクトされたリクエストを受信し、応答を収集し、それからブルートゥース接続を超えてクライアントＰＣのＦＲ／ＨＲに応答を送信する。
７．クライアントＰＣのＦＲ／ＨＲは、ローカルホストソケットへの応答を書く。そして、ハンドオーバーは完了し、ブラウザは表示された全てのウェブ内容を有する。

上記の内容は網羅的ではない。そして、可能ならどこでも、情報を利用できる。手順の動作は、異なった順序で行われてもよい。

図１５は、１つの実施形態に従い、ＭＮとその現在の接続点（ＨＲ／ＦＲノードにより実現される）との間のシグナリング及びデータメッセージの下流への伝達及び上流への伝達を、効率的に操作および制御するためのシステムの一部を示す。この方法は、モバイル機器における場合によっては不十分なリソース、及びＭＮとそのアンカーＦＲ／ＨＲノードとの間の潜在的低容量またはエラー傾向があるワイヤレスアクセスを処理するために重要である。いくつかの実施形態は、以下の機能要素、すなわち前処理、プロキシ機能性、下流および上流のトラフィック管理をそれぞれ含む。下流のロードバランシングおよびトラフィック管理は、図１５に示されている。それは右に位置するＭＮ機器へのデータメッセージの流れが、どのように左からＭＮの一般的な接続点（ＦＲまたはＨＲ）に到達するかを示す。ＦＲは内部バッファ構造に入ってくるトラフィックストリームを導くとともに、必要であれば一時保存する。それぞれのＭＮ機器は、アンカーノードの内部に論理的に表される。そのようなそれぞれの機器表現の中では、機器で動くそれぞれのアプリケーションが、１つまたはいくつかのバッファによって表される。スケジューリングアルゴリズム構造は、一般的なデータ移送チャンネルへのアクセスを制御する。適切な制御のため、チャンネル容量（ｃ（ｔ））及びアプリケーション性能（ｂ（ｔ））に関する現在の状態のフィードバックにつき、それぞれのＭＮ機器からアンカーノードに信号が戻される。スケジューラは、階層構造に組織化され、データは、現在のスケジューリングポリシー（ノード管理者により構成可能）に従って、共通の移送チャンネル（または、混雑の場合に遮断される）の方向に流される。類似構造が上流の方向にも必要である。そこでは、各機器が、機器で働くそれぞれのアプリケーションからアンカーノードまでのデータの流れを制御する。

また、ＭＮとそのアンカーノード（ＨＲ／ＦＲ）との間のトラフィックの管理も、機能をオフロードするための前処理および処理を構成する。これは、別々の制御シグナリングプロトコルにより管理される（本発明のバンド外で働くと想定されるが、バンド内でもシグナリングは用いられる）。制御シグナリングプロトコルは、装置の現在実行可能状態のアプリケーションのために、アンカーノードにおける前処理に関するルールおよびポリシーを定義している。よく定義された制御構造によると、一般的に、機器はアンカーノードに指示を出してもよい。そのような指示は、代表的に、アンカーノードが、データパケットの調査および分類をどのように及びどのアプリケーションデータのために行うか、及び、前処理結果は機器に伝達すべきか、及びどのように機器に伝達すべきか（代表的には、パケットの分野に関係した適切なデータをコード化して書く）を指示するものである。セキュリティ及びアクセス制御の機能のようなパケットフィルタリングがこの方法により実行されてもよいことは、明らかである。

従って、ここに説明された実施形態の方法および装置は、機器およびコンピュータのダイナミックなモバイル通信ネットワークにおいて、効率的で拡張可能性のある通信のピア・ツー・ピアモデルのためのプロトコルスタックを提供する。ここで、ノードは、包括的なオーバーレイネットワークを形成し、可動性であり、下層のネットワークインフラストラクチャとは無関係に移動してもよい。

更に、本発明の実施形態のプロトコルスタックは、ダイナミックなソースルーティングを考慮するとともに、サービスホスティングピアを、例えば接近性に基づき検索する強化されたネットワークレイヤプロトコルを含み、更に、現在のアプリケーションのデータ交換と性能を最適化するために、モバイルノードと、アプリケーションレイヤにおける効率的なデータ交換のためのオーバーレイネットワークルータノードとの間のプロトコルを含む。

本発明の利点は、モバイルノードが常に他のピアから到達可能であり、固定されたワイヤーラインおよびモバイル無線通信ネットワークの両方のミックスの上で動いている包括的なオーバーレイピア・ツー・ピアネットワークを通してアドレス可能である、ダイナミックで拡張可能性のあるネットワークインフラストラクチャを提供することである。

本発明の方法は、望ましくは、コンピュータ能力を有する電子装置により、実行可能なコンピュータソフトウェアで行われる。本発明のこの実施例では、電子装置は、データを処理するためのコンピュータプロセッサ、及びコンピュータプロセッサに接続され、記憶媒体上でデータを保存するための格納手段を含むコンピュータ装置を備える。ここで、コンピュータ装置は、方法のステップを実行するために構成されている。

加えて、本発明は、本発明を実行に移すために用いられる、キャリヤ上またはキャリヤ内のプログラムに拡大する。プログラムは、ソースコードの形であってもよいし、本発明の方法を実施するために好適に用いられるコードであるオブジェクトコードであってもよい。キャリヤはエンティティであってもよく、また、プログラムを運ぶことができる機器であってもよい。例えば、キャリヤは、記録媒体、コンピュータメモリ、リードオンリーメモリまたは電気的キャリヤ信号であってもよい。

Claims (26)

1. 通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する方法であって、
   モバイル通信装置（１０６）から該モバイル通信装置の識別子を含むレジスタリクエストをドメインルータ（１０３）で受信する（２０４）ステップと、
   前記識別子と関連した次回ホップルータ（１０４）へのアドレスをルックアップする（２０５）ステップと、
   前記レジスタリクエストを前記次回ホップルータ（１０４）へ送信する（２０６）ステップと、
   前記次回ホップルータ（１０４）からの応答を受信する（２１０）ステップと、
   前記応答がホームルータ（１０４）へのアドレスを含んでいる場合、応答を前記ホームルータ（１０４）の前記アドレスを含む前記モバイル通信装置（１０６）に送信する（２１１）ステップと、を含み、前記応答は前記モバイル通信装置（１０６）と前記ホームルータ（１０４）との間の接続の確立を開始することを特徴とする方法。
2. 請求項１に記載の方法であって、前記ルックアップする（２０５）ステップは、更に、前記通信ネットワークにおける前記ホームルータ（１０４）のネットワークアドレスを確認するステップを含む、方法。
3. 請求項１または２に記載の方法であって、前記ルックアップする（２０５）ステップは、ネットワークの近接性、または地理的な位置、または容量及び通信量、または前記ホームルータ（１０４）に関するコミュニティーおよび知り合いの個人間の関係に基づいて設定されたピアリングコラボレーションアグリーメントに基づく、方法。
4. 請求項３に記載の方法であって、前記ネットワークの近接性は、前記ホームルータ（１０４）に関するホップの数、ピン／トレースルートの待ち時間、及びオーバーラッピングルートの１つ以上に基づき判断される、方法。
5. 請求項３に記載の方法であって、前記地理的な位置は、前記モバイル通信装置（１０６）のＧＰＳデータに基づく、方法。
6. 通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成するためのドメインルータ（１０３）であって、
   モバイル通信装置（１０６）から該モバイル通信装置の識別子を含むレジスタリクエストを受信するために用いられる受信機（３０１）と、
   前記識別子と関連した次回ホップルータ（１０４、１０５）へのアドレスをルックアップするために用いられるコントローラ（３０２）と、
   前記レジスタリクエストを前記次回ホップルータ（１０４、１０５）に送信するために用いられる送信機（３０３）と、を備え、
   そこにおいて、前記受信機（３０１）は前記次回ホップルータ（１０４、１０５）からの応答を受信するために用いられ、前記コントローラ（３０２）は前記応答がホームルータ（１０４）へのネットワークアドレスを含むかどうかを決定するために用いられ、前記送信機（３０３）は前記ホームルータ（１０４）の前記アドレスを含む応答メッセージを前記モバイル通信装置（１０６）に送信するために用いられ、前記応答メッセージは前記モバイル通信装置と前記ホームルータとの間の接続の確立を開始することを特徴とするドメインルータ。
7. 請求項６に記載のドメインルータであって、前記ネットワークアドレスはドメインネームであり、前記ドメインルータ（１０３）は前記通信ネットワークの中で検索可能なドメインネームを有するエージェントとして登録されている、ドメインルータ。
8. 請求項６または７に記載のドメインルータであって、前記受信機（３０１）は１つ以上のクライアント（１０１）からの論理識別子のためのルックアップリクエストを受信するために用いられ、前記コントローラ（３０２）は前記論理識別子に関係したホームルータまたは移動先ルータをルックアップすると共に前記送信機が前記ルックアップホームルータに前記ルックアップクエリーを送信するように制御するために用いられ、前記受信機は前記ルックアップホームルータからのリクエストを処理する責任を持つ中継ノードのリダイレクトアドレスを受信するために用いられ、更に、前記送信機は前記中継ノードの前記リダイレクトアドレスと共に前記要求クライアントに応答するために用いられる、ドメインルータ。
9. 請求項６乃至８のいずれか１項に記載のドメインルータであって、ホームルータ及び移動先ルータへのアドレスの経路指定テーブルを備える、ドメインルータ。
10. 請求項６乃至９のいずれか１項に記載のドメインルータであって、そこにおいて、前記受信機は一つ以上のホームルータ及び／または移動先ルータからの登録または更新情報を受信するために用いられ、更に前記コントローラは前記経路指定テーブルに前記登録情報を格納するために用いられる、ドメインルータ。
11. 請求項１０に記載のドメインルータであって、そこにおいて、前記経路指定テーブルはホームルータ及び／または移動先ルータの代替アドレスを１つ以上の論理識別子により格納する、ドメインルータ。
12. 請求項６乃至１１のいずれか１項に記載のドメインルータであって、そこにおいて、前記コントローラは前記経路指定テーブルの全てのルータと移送レイヤにおいて接続を維持するために用いられる、ドメインルータ。
13. 請求項６乃至１２のいずれか１項に記載のドメインルータであって、１つ以上の他のドメインルータに関係した論理識別子のリストを備え、前記コントローラは前記他のドメインの１つに対する前記論理識別子のリストのネームに対するクエリーをリダイレクトするために用いられる、ドメインルータ。
14. 請求項６乃至１３のいずれか１項に記載のドメインルータであって、前記ドメインルータの前記経路指定テーブルに格納されたホームルータによって生成されたクエリーを該ホームルータに送信することを可能にするドメインのリストを備える、ドメインルータ。
15. 請求項６乃至１３のいずれか１項に記載のドメインルータであって、前記ドメインルータによって制御されたドメインの中のあるＵＲＩに対する現在未解決であって、未解答のルックアップクエリーを有するクライアントに関するアドレスのテーブルを備え、前記コントローラは、次回ホップホームルータ／移動先ルータからあるＵＲＩに対する最初のクエリー応答を受信すると、現在未解決のクエリーを有する全てのクライアントに応答するために用いられる、ドメインルータ。
16. 通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する方法であって、
    ドメインルータ（１０３）からモバイル通信装置（１０６）のための該モバイル通信装置の識別子を含むレジスタリクエストをホームルータ（１０４）において受信する（２０７）ステップと、
    前記レジスタリクエストに対応して、前記ホームルータアドレスを含む応答を作成する（２０８）ステップと、
    前記ホームルータの前記アドレスを含む前記モバイル通信装置（１０６）に対する転送応答を開始するため前記ドメインルータ（１０３）に前記応答を送信する（２０９）ステップと、を含むことを特徴とする方法。
17. 請求項１６に記載の方法であって、
    前記モバイル通信装置（２１４）からのレジスタリクエストを受信するステップと、
    前記モバイル通信装置（２１４）からの前記レジスタリクエストに対応して、前記ホームルータ（１０４）と前記モバイル通信装置（１０６）との間の接続を確立する（２１５、２１６）ステップと、を含む方法。
18. 請求項１７に記載の方法であって、そこにおいて、前記接続は移送レイヤ接続である、方法。
19. 通信ネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成するためのホームルータ（１０４）であって、
    モバイル通信装置（１０６）のための該モバイル通信装置の識別子を含むレジスタリクエストをドメインルータから受信するために用いられる受信機（３１１）と、
    前記レジスタリクエストに対応して、前記ホームルータアドレスを含む応答を作成するために用いられるコントローラ（３１２）と、
    前記ホームルータの前記アドレスを含む前記モバイル通信装置（１０６）に対する転送応答を開始するため前記ドメインルータ（１０３）に前記応答を送信するために用いられる送信機（３１３）と、を備えることを特徴とするホームルータ。
20. 請求項１９に記載のホームルータであって、そこにおいて、前記受信機（３１１）は前記モバイル通信装置（１０６）からのレジスタリクエストを受信するために用いられ、
    前記コントローラ（３１２）は、前記モバイル通信装置（１０６）からの前記レジスタリクエストに対応して、前記ホームルータ（１０４）と前記モバイル通信装置（１０６）との間の接続を確立するために用いられる、ホームルータ。
21. コミュニケーションネットワークにおける効率的な情報検索のために、包括的なオーバーレイネットワークを形成する方法であって、
    ドメインネームサーバ（１０２）に照会を送信することによりホームルータ（１０４）に接続を要求する（２０１）ステップと、
    ホームルータ（１０４）に接続されたドメインルータ（１０３）へのアドレスを受信する（２０２）ステップと
    受信した前記アドレスのドメインルータ（１０３）にレジスタリクエストを送信する（２０３）ことによりホームルータ（１０４）に登録することを要求する（２０３）ステップと、
    前記ドメインルータ（１０３）から前記ホームルータ（１０４）に対する参照を付されたレジスタ応答を受信する（２１２）ステップと、
    レジスタリクエストを作成すると共に前記ホームルータ（１０４）に直接的に送信する（２１３）ステップと、
    前記ホームルータ（１０４）と前記モバイル通信装置（１０６）との間の接続を確立する（２１７）ステップと、を含むことを特徴とする方法。
22. コンピュータプログラムであって、該プログラムがコンピュータ上で動かされるとき、請求項１乃至５、１６乃至１８、及び２１のいずれか１項に記載の方法の全てのステップを実行するために用いられるコンピュータプログラムコード手段を含むコンピュータプログラム。
23. コンピュータにて読み込み可能な媒体に格納された、請求項２２に記載のコンピュータプログラム。
24. キャリヤに担持されたコンピュータプログラムであって、前記プログラムがコンピュータで動かされるとき、コンピュータに請求項１乃至５、１６乃至１８、及び２１のいずれか１項に記載の方法を行わせるためのコンピュータが実行可能な命令を含むコンピュータプログラム。
25. 請求項２４に記載のコンピュータプログラムであって、そこにおいて、前記キャリヤは記録媒体、コンピュータメモリ、リードオンリーメモリまたは電気的キャリヤ信号である、コンピュータプログラム。
26. コンピュータに読み込み可能な媒体を含むコンピュータプログラム製品であって、前記プログラムがロードされたとき、前記コンピュータに対して請求項１乃至５、１６乃至１８、及び２１のいずれか１項に記載の方法のプロセスを実行させるためのコンピュータプログラムコード手段を含む、コンピュータプログラム製品。

Images