モバイルピアツーピアネットワーク構築
【課題】
モバイル無線通信ネットワークを介してのピアツーピアネットワーク構築を最適化する。
【解決手段】
本発明は、モバイル無線通信ネットワークにおける、モバイルピアツーピアネットワーク構築に関する。特に、ネットワーク層からアプリケーション層に及ぶ、モバイルピアツーピアプロトコルスタックを導入する。ここで、上位のピアツーピアネットワークプロトコル層が、アドレス情報、例えば、近接性を越えて拡張するモバイル通信ネットワークにおいて、共有されているサービスリソース取得のための探索基準を明確にする。これらの基準は、下位層のネットワークプロトコルに信号で送られて、拡張されたルーティングを実行する。これにより、例えば、ノードおよびサービスタイプの近接性、または、ノードまたはサービスタイプの近接性による、ネットワーク内のサービスに関連したリソースの探索の性能が向上する。
モバイル無線通信ネットワークを介してのピアツーピアネットワーク構築を最適化する。
【解決手段】
本発明は、モバイル無線通信ネットワークにおける、モバイルピアツーピアネットワーク構築に関する。特に、ネットワーク層からアプリケーション層に及ぶ、モバイルピアツーピアプロトコルスタックを導入する。ここで、上位のピアツーピアネットワークプロトコル層が、アドレス情報、例えば、近接性を越えて拡張するモバイル通信ネットワークにおいて、共有されているサービスリソース取得のための探索基準を明確にする。これらの基準は、下位層のネットワークプロトコルに信号で送られて、拡張されたルーティングを実行する。これにより、例えば、ノードおよびサービスタイプの近接性、または、ノードまたはサービスタイプの近接性による、ネットワーク内のサービスに関連したリソースの探索の性能が向上する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル通信環境におけるモバイルピアツーピアネットワーク構築のためのプロトコルスタックに関し、特に、アプリケーション層に新たなサービスとオプションとを導入し、性能を向上させるための、モバイル無線ネットワークにおけるピアツーピアオーバーレイネットワーク構築をサポートするプロトコルスタックに関する。
【背景技術】
【０００２】
一般的に、ピアツーピアアプリケーションは、最適化アルゴリズムを有するため、ＴＣＰや仮想的に安定した通信などのネットワーク層プロトコルに依存する一方、オーバーレイネットワーク内で情報を検出することができる。それにもかかわらず、無線通信ネットワークにおいて、特にアドホック無線通信ネットワークにおいては、あらゆるモバイルノードが稼動するため、接続の中断がよくある。
【０００３】
データパケット転送中の２つの近接したモバイルノードが、お互いの近傍から離れる場合は常に、両モバイルノード間の接続は中断する。すると、ネットワーク層プロトコルの上位にあるピアツーピアアプリケーションを意識していないネットワーク層プロトコルは、どのようなことをする必要があるのかとは関係なく、同じ宛先ノードに至る新たな経路を再構築しようとする。
【０００４】
それにもかかわらず、同じ情報源への新たな経路を確立しようとする代わりに、ネットワークトポロジーを変更すれば、他の情報源が、同じ情報をより低いコストで提供できる。
【０００５】
言い換えると、モバイルノードは、接続が中断したことをピアツーピアプロトコルレベルと、関連したアプリケーションとに報告し、その後、これらが、古い情報源がまだ利用可能であるか、または別の情報源がより適切であるかを決定する。
【０００６】
さらに、ピアツーピアネットワークは、通常、固定式ネットワーク構造の上で動作するため、ピアツーピアネットワークノードは、近傍にある通信当事者と遠隔のネットワーク参加者を区別しない。モバイルノード間の距離は、一般に、固定式ネットワークにおける通信の安定性と、エラーのない動作とに影響しないため、探索情報も密接に利用可能であるとはいえ、通常のピアツーピアプロトコルは、離れたノードへの接続を確立できる。
【０００７】
より詳細な一例として、図１は、４つのノードを有するモバイルアドホックネットワークの上で動作する、簡単なピアツーピアファイル共有アプリケーションを示している。ピアツーピアオーバーレイネットワークレベルでは、ノードＡはノードＤへの静的接続を維持しており、従って、ノードＡがネットワーク内のファイルを探索する場合、照会メッセージをノードＤに送信する。要求されたファイルが、ノードＤでは入手不可能な場合、ノードＤは、そのメッセージをノードＢに対して、このノードＢへの接続、すなわち、接続２を介して転送する。
【０００８】
図１に示す例によれば、このメッセージは、同じ理由でノードＣに再び転送されるため、要求されたファイルはこのノードＣで公開されることが、推測される。従って、物理ネットワーク層では、たった２ホップしかはなれていないノードＣを発見するのに６個の無線接続を用いる。
【０００９】
結論として、静的オーバーレイ接続を維持することは、帯域幅とバッテリの電力が非常に乏しいリソースであるモバイルアドホックネットワークなどの無線通信ネットワークにおいて、ピアツーピアネットワークプロトコルを適用する際の、性能上の大きなボトルネックである。
【００１０】
先行技術で、ピアツーピアアプリケーションとアドホック無線通信ネットワークとの組み合わせに関するいくつかの調査が行われているが、それでも、その調査には、ピアツーピアネットワークプロトコルレベルでのアドホックネットワーク構築の可能性に関する十分な考慮が欠けている。例えば、白書２００２年のＪＸＭＥ，Ａ．Ａｒｏｒａの「ＪＸＴＡ ｆｏｒ Ｊ２ＭＥTM−Ｅｘｔｅｎｄｉｎｇ ｔｈｅ Ｒｅａｃｈ ｏｆ Ｗｉｒｅｌｅｓｓ Ｗｉｔｈ ＪＸＴＡ Ｔｅｃｈｎｏｌｏｇｙ」では、ＪＸＴＡをモバイル環境に適応させているが、それでもモバイルアドホックについては十分に考慮していない。さらに、２００２年、イタリア、ボローニャでの、埋め込み型、ウエアラブル型およびモバイル型デバイスについてのユビキタスエージェントに関するワークショップの議事録「ＬＥＡＰ ｉｎｔｏ ＡｄＨｏｃ Ｎｅｔｗｏｒｋｓ」は、ルーティングに関する疑問を呈しておらず、また、２００１年のカリフォルニア州ロングビーチ市でのモバイルアドホックネットワーク構築に関するＡＣＭシンポジウム（ＭＯＢＩＨＯＣ２００１）議事録の７ＤＳ、Ｍ．ＰａｐａｄｏｐｏｕｌｉとＨ．Ｓｃｈｕｌｚｒｉｎｅの「Ｅｆｆｅｃｔ ｏｆ Ｐｏｗｅｒ Ｃｏｎｓｅｒｖａｔｉｏｎ，Ｗｉｒｅｌｅｓｓ Ｃｏｖｅｒａｇｅ ａｎｄ Ｃｏｏｐｅｒａｔｉｏｎ ｏｎ Ｄａｔａ Ｄｉｓｓｅｍｉｎａｔｉｏｎ ａｍｏｎｇ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ」では、位置情報が考慮されていない。さらに、２００１年ジョージア州アトランタ市での、ユビキタスコンピューティングのためのアプリケーションモデルとプログラミングツールに関するワークショップの議事録（ＵＢＩＣＯＭＰ２００１）のＰＲＯＥＭ、Ｇ．ＫｏｒｔｕｅｍとＪ．Ｓｃｈｎｅｉｄｅｒによる「Ａｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋｓ」には、より大型のモバイルアドホックシナリオのためのスケーリングが欠如しており、一方、２００３年フランスのソフィアアンティポリス市でのモバイルアドホックネットワーク構築とコンピューティングに関するワークショップの議事録（ＭＡＤＮＥＴ２００３）のＯＲＩＯＮ、Ａ．Ｋｌｅｍｍ、Ｃ．ＬｉｎｄｅｍａｎｎとＯ．Ｐ．Ｗａｌｄｈｏｒｓｔによる「Ａ Ｓｐｅｃｉａｌ−Ｐｕｒｐｏｓｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｆｉｌｅ Ｓｈａｒｉｎｇ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ」では、ファイル共有アプリケーションのみ焦点を当てており、位置に対する認識が欠如していて、ルーティングのオーバーヘッドが大きい。さらにまた、Ｂｌｕｅｔｏｏｔｈ規格では、アドホック通信環境におけるピアツーピアアプリケーションに対して考慮がなされているが、それでも、非常に短距離の通信以外はルーティングをサポートしていない。
【００１１】
要約すると、無線アドホック通信ネットワークに対して、このようなアドホックネットワークの特定の要件を考慮することなく、ピアツーピアコンピューティングを導入しても、性能は悪いものとなる。これは、ピアツーピアプロトコルが、下位のプロトコルに関する認識や情報、例えば、要求されたコンテンツや参加者の位置情報が全くなく、完全に独立したオーバーレイネットワーク構築に役立つように設計されているからである。このように、ピアツーピアネットワークにおいて近傍に関する認識が欠如しているため、遠隔接続となるが、その一方で、同じコンテンツがより密接に利用可能となる。また、モバイルアドホックネットワークでは、ホップの数が増えるとルーティングのオーバーヘッドも増加する、ホップ順ルーティングが採用されているが、ピアツーピアネットワークは、現在、下位の経路を意識しておらず、従って、最適な経路に関して判断することは不可能である。言い換えると、ピアツーピアプロトコルは固定式ネットワーク用に設計されており、従って、特に接続のロスが発生すると、参加者がピアツーピアネットワークから去ったかのように認識されるため、即座に再ルーティングをするモバイル通信環境において、変化するチャネル状態に対処することは不可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上記事情に鑑み、本発明の目的は、モバイル無線通信ネットワークを介してのピアツーピアネットワーク構築を最適化することにある。
【課題を解決するための手段】
【００１３】
全体として、本発明は、ネットワーク層からアプリケーション層へ、またはその逆へと展開するモバイルピアツーピアプロトコルスタックを紹介する。ここで、上位のピアツーピアネットワークプロトコル層は、適当な探索基準を指定するだけでなく、適切な応答を受信し、その結果、無線ネットワークを認識して、トラフィックを最小化し、頻繁に発生する経路の中断に対処する。加えて、ネットワーク層ルーティングレベルは、ピアツーピアアプリケーションに関する情報を受信して、適当な通信ノードにしか通じていない経路を確立する。従って、本発明は、無線通信ネットワーク、例えば、アドホック無線ネットワークで、互いに異なるさまざまな関連サービスを生成するために必要なフレームワークを形成するものである。
【００１４】
従って、モバイル無線ネットワークでのピアツーピアアプリケーションの最適化は、ユーザにおいて、より高い度合いの受け入れをサポートし、また、固定式もしくは集中式のインフラストラクチャを用いることなく、サービスプロバイダの経費と、位置に基づいたサービスおよびアプリケーションを提供するための経費とを削減する。
【００１５】
本発明によれば、請求項１および３１に従って、ネットワーク層ルーティングプロトコルを使用する方法および装置と、独立請求項１９と５９に従って、モバイルピアツーピアネットワークプロトコルを利用する方法と、独立請求項３７と７７に従って、モバイルピアツーピアプロトコルレベルおよびネットワーク層ルーティングプロトコルレベル間での、層間通信チャネルプロトコルを利用する方法とに依存して、モバイル無線通信ネットワーク、例えば、アドホックネットワークでピアツーピア通信を最適化するプロトコルスタックが提供される。
【００１６】
言い換えると、本発明によるプロトコルスタックは、動的なソースルーティングを考慮しており、また、例えば近接性に基づいてサービスを提供しているピアを発見することを可能にする、強化されたネットワーク層プロトコルと、アプリケーション層でのデータ交換のためのモバイルピアツーピアプロトコルと、これらの正式な２つのプロトコル間の層間通信のための同期式プロトコルとを含む。
【００１７】
本発明は、特に、ネットワーク層プロトコルの機能性を強化することを提案する。その結果、無線通信ネットワーク内でアプリケーションリソースを取得するために適用された照会メッセージが、例えば、照会に対して応答するモバイル通信ネットワーク内のモバイルノードの近接性、またはサービス能力に従って、アドレス情報の範囲を越えて拡張する探索基準を考慮できるようになる。従って、本発明は、無線通信ネットワークのトポロジに関する情報が実際に利用可能となるように、ネットワーク層プロトコルの探索基準を改善することを提案する。ネットワーク層ルーティングプロトコルレベルで用いられる探索基準のタイプに関する情報は、アプリケーションとサービスをサポートする上位のピアツーピア通信層プロトコルによって提供される。
【００１８】
本発明によれば、上位のピアツーピア層プロトコルとネットワーク層プロトコルとの間の探索基準の変更は、層間通信チャネルプロトコルによって達成でき、特に、ピアツーピアプロトコルスタック内の異なる階層レベル間の探索関連メッセージの交換に適用できる。
【００１９】
従って、適切なサービスリソースを探索している最中は、無線通信ネットワーク内での適切なリンクの維持と層間通信プロトコルの操作とによって、品質の向上と、経費の減少と、ピアツーピアサービスのプロバイダに対する経費の減少とによる、無線通信ネットワークでのピアツーピアサービスをユーザが受け入れる度合の向上が、達成できる。ピアツーピアサービスは、高度に動的で、急速に変化する無線通信ネットワーク、特に、無管理、無制御のアドホック無線通信環境でのルーティング機能性を提供するのに完全に適している。
【００２０】
本発明の別の好ましい実施形態によれば、モバイル通信環境において処理デバイスの内部メモリに直接読み込み可能なコンピュータプログラム製品が提供できる。ここで、このコンピュータプログラム製品は、モバイル通信環境の処理デバイス上で実行されると、本発明に係るプロトコルを使用するソフトウェアコードを含む。
【００２１】
従って、本発明はまた、コンピュータシステムまたはプロセッサシステムで、上述した様々なプロトコルを使用するために提供される。結論として、この結果、コンピュータシステム、または、より具体的には、アドホックネットワークなどに含まれるプロセッサと共に用いられる、コンピュータプログラム製品が、提供されることになる。
【００２２】
書き込み不可能な記憶媒体、例えば、プロセッサやコンピュータの入出力付属品によって読み取り可能な、ＲＯＭやＣＤ−ＲＯＭディスクなどの読み取り専用メモリに、永久的に記憶される情報と、書き込み可能な記憶媒体、すなわち、フロッピー（登録商標）ディスクおよびハードドライブに記憶される情報と、モデムあるいは他のインターフェースデバイスを介し、ネットワークやインターネット、電話網などの通信媒体を通して、コンピュータあるいはプロセッサに伝達される情報とを含む、本発明の機能を特徴づけるこのプログラムは、多くの形態のコンピュータあるいはプロセッサに提供できる。本発明の概念を実行する命令を読み取ることができるプロセッサを用いる際に、上述した媒体により、本発明の代替の実施形態が提示されることを理解すべきである。
【発明を実施するための最良の形態】
【００２３】
以下に、本発明の最良の形態およびさまざまな態様、好ましい実施形態を、図表を参照しながら説明する。さまざまな機能性を以下に説明するが、これらの機能性は、ソフトウェア、ハードウエア、あるいは、これらの組み合わせで実現できる。さらに、さまざまな態様のプロトコルの使用を、さまざまなレベルで抽出して説明するが、以下に説明する各々のプロトコルおよび関連した実施は、単体で操作され、または、本発明によるピアツーピアプロトコルスタックの実施の全体的な枠組内にある、さらなる関連のプロトコルおよび対応する実施と組み合わせて操作されることに注意すべきである。
【００２４】
図２に、本発明による、無線通信ネットワーク上にあるピアツーピア動作用のプロトコルスタックを示す。
【００２５】
図２に示すように、本発明は、モバイルピアツーピアプロトコルＭＰＰと、拡張ダイナミックソースルーティングプロトコルＥＤＳＲと、モバイルピア通信チャネル制御プロトコルＭＰＣＰとの提供と実施とに関する。
【００２６】
図２に示すように、拡張ダイナミックソースルーティングプロトコルＥＤＳＲは、ＯＳＩプロトコルスタックに従って、リンク層と物理層の上位で実行されるが、これは、本発明の範囲との関連性を考慮することなく、モバイルアドホック通信ネットワーク、以下すなわちＭＡＮＥＴと呼ばれる。しかしながら、一般に、本発明はまた、以下に説明するようにネットワーク層においてルーティングプロトコルをサポートする限り、他のどのようなタイプの無線通信ネットワークにも適用可能であることに注意すべきである。
【００２７】
図２に示されている、ピアツーピアモバイルアドホックネットワークには、ピアの検出とパケットのルーティングという、共通する二つの課題がある。これらの課題を解決するため、ピアツーピアネットワークとモバイルアドホック通信ネットワークとの間の相乗効果により、モバイルピアツーピアプロトコルの管理負担を軽減し、その性能および信頼性を向上させる。
【００２８】
図２に示すように、より詳しくは、ピアツーピアプロトコルにより、ピアは、直接的にデータを交換することが可能となり、従って、このプロトコルは、ピアツーピアネットワーク内でサービス関連のデータ、例えば、ファイルに関与することになる。モバイルピアツーピアプロトコルは、例えばＨＴＴＰに基づいて、データをアップロードし、ダウンロードする能力を有する。リンクの中断により送信が遮断された場合、コンテンツ範囲にあるヘッダーが、ファイルの転送を再開する能力を提供する。本発明によれば、ＨＴＴＰは、その豊富な特徴の集合と、さまざまなコンピュータ言語で利用可能な多くの標準実施との一例として適用される。しかしながら、同じ機能性を持つ他のどのようなプロトコルを適用しても良い。
【００２９】
さらに、拡張ダイナミックソースルーティングプロトコルは、既存のネットワーク層プロトコル、例えば、ＤＳＲプロトコルに対して、新しいタイプの要求と応答を有する。従って、拡張ダイナミックソースルーティングプロトコルは、単なるＩＰアドレス以外の基準によってピアを発見する手段となる。それにもかかわらず、拡張ネットワーク層ルーティングプロトコルＥＤＳＲは、以前に公知のダイナミックソースルーティングプロトコルの基本的動作を変更しておらず、従って、ＥＤＳＲノードは、既存のＤＳＲネットワークになくてはならない部分である。
【００３０】
さらに、モバイルピア制御プロトコルは、拡張ダイナミックソースルーティングプロトコルと、ネットワーク層とを、アプリケーション層内のピアツーピアアプリケーションと共にリンクする。以下に詳細に説明するように、モバイルピア制御プロトコルを用いて、アプリケーションは、拡張ダイナミックソースルーティング層に登録し、探索要求を起動して、無線通信ネットワーク内の他のノードから入力される探索要求を処理する。言い換えると、モバイルピア制御プロトコルは、アプリケーション層とネットワーク層との間の、クロス層通信チャネルまたは層間通信チャネルである。モバイルピア制御プロトコルは、ファイル交換自体を除き、入出力要求および応答の全てを、対応するプロトコルと通信する。
【００３１】
図３に、本発明による、モバイルピアツーピアネットワーク内での、データの探索およびダウンロード、アップロードを示す、メッセージ順序表を示す。
【００３２】
図３に示すユニットである、ピアツーピアアプリケーション（Ａ）１０と、ピアツーピアアプリケーション（Ｂ）１２とは、以下に説明するように、データ交換用の通信チャネルを起動するモバイル通信環境内で実行されるピアツーピアアプリケーションＡとＢとに関連している。さらに、追加のユニットＥＤＳＲ（Ａ）１４と、ＥＤＳＲ（Ｂ）１６とは、それぞれ、ピアツーピアアプリケーション（Ａ）と、ピアツーピアアプリケーション（Ｂ）とについて、ネットワーク通信プロトコル層で用いる機能性に関連している。
【００３３】
図３に示すように、制御関連のデータもしくはペイロードデータの交換は、順序表内のエラーラインで表されている。
【００３４】
以下に、ネットワークプロトコル層の使用と機能性との詳細な態様を、図４〜６を参照して説明する。
【００３５】
図４に、ＥＤＳＲ（Ａ）と（Ｂ）の概略図を示す。本発明によれば、このようなユニットは、それぞれ、無線通信ネットワーク内のノードにおいて、関連する拡張ダイナミックソースルーティングプロトコル機能を使用する目的で操作されるものと仮定する。
【００３６】
図４に示すように、このような拡張ダイナミックソースルーティングプロトコルユニット（Ａ）は、受信ユニット１８と、変換ユニット１９と、転送ユニット２０とに分割される。
【００３７】
第１のインターフェースユニット１８は、モバイルピアツーピア層プロトコル、すなわち、ピアツーピアアプリケーション（Ａ）の上で稼動するサービスを介して起動されるサービス要求に関連する探索関連のデータを受信することができる。さらに、変換ユニット２０は、提示された探索関連データを、ネットワーク層ルーティングプロトコルＥＤＳＲに従って、照会メッセージに変換する。すでに概説したように、本発明では、照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準、すなわち、サービスリソースまたはこのようなタイプのサービスリソース、すなわち、データのタイプまたはサービスのタイプに対して、探索を起動するノードへの近接性の態様を特定する基準を含むことを提案する。さらに、動作に際して、転送ユニット２２は、照会項目を、サービスリソースの探索時に無線通信ネットワークを通して展開するために、下位層に出力する。
【００３８】
本発明で意味するところの探索基準の一般的な例として、サービスを、例えば、無線アドホック通信ネットワーク内の最も近い範囲に位置付けし、後続のデータ転送トラフィックを最小化し、または、サービスのタイプ、例えば、レストラン、銀行業、駐車などを表示する。照会メッセージに対するより詳細な例としては、探索要求ＳＲＥＱ、ハッシュ要求ＨＲＥＱ、ファイル応答ＦＲＥＰ、プッシュ要求ＰＲＥＱ、宣言応答ＤＲＥＰに関連したものがあり、これらを以下に詳細に説明する。
【００３９】
図３と図４に示すように、拡張ダイナミックソースルーティングプロトコルは、ピアツーピアアプリケーションの登録を受信して、次にこの登録の受信を承認する。これは、図４に示されている登録ユニット２４によって達成できる。
【００４０】
さらに、これ以降続いて、および、照会メッセージの準備の後で、転送ユニット２２も、無線通信ネットワーク内の別のノード（Ｂ）から起動された、照会メッセージに対する応答を受信する。従来、拡張ダイナミックソースルーティングプロトコル（Ａ）および（Ｂ）の各々の使用において、受信ユニット１８と転送ユニット２２とは、無線ネットワークインフラストラクチャ内を、ネットワークプロトコル層からピアツーピアアプリケーションレベルに流れている、照会メッセージを交換し、アプリケーションレベルでさまざまな照会メッセージを評価する。この評価の結果次第で、すなわち、関連するノードで操作されたサービスにより探索基準が満たされたかどうかによって、探索応答が生成され、これが次にピアツーピアアプリケーションレベルから拡張ダイナミックソースルーティングレベルにまで転送されて、上記の探索要求を起動したノード、以下、送信ノードに転送される。
【００４１】
関連するさまざまな探索応答とは、ファイル応答、プッシュ応答、宣言応答である。
【００４２】
探索に関連し、図４に示す評価ユニット２６により達成されるさらなる態様として、探索を起動するノードで複数の探索応答を受信した際に、異なる探索要求を評価するという態様がある。本明細書において、評価ユニット２６は、少なくとも１つの所定の費用関数、例えば、送信ノードと受信ノードとを接続する無線ネットワークの経路上の少なくとも１つのノードの特性を処理する。この特性の典型的な例として、経路上のノードの数、ノードの送信出力、ノードの移動速度、ノードの転送がある。
【００４３】
以下において、上述した照会メッセージのさまざまな実例を説明する。従来、標準の機能を用いるＩＰフィールドと、本発明による探索基準に関連したフィールドとは、区別されている。
【００４４】
以下、探索要求（ＳＲＥＱ）について述べる。データを探索する際、ＥＤＳＲは、グヌーテラの照会メッセージのような類似のメッセージ、すなわち、探索要求（ＳＲＥＱ）を提供する。ＳＲＥＱは、モバイルＰ２Ｐネットワークにおけるデータ探索の初期のオプションである。ＳＲＥＱは、ＤＳＲオプションルート要求（ＲＲＥＱ）に基づいている。ＳＲＥＱは、応答として、応答タイプ（ｘＲＥＰ）のオプションが返却されるのを待っている。ＥＤＳＲが求める応答のタイプは、当初に要求されたサービスとデータタイプとに依存する。
【００４５】
表２−１に、ＳＲＥＱのビット構造を示し、ＳＲＥＱフィールドについて以下に説明する。
【００４６】
【表１】
【００４７】
以下、ＩＰフィールドについて述べる。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＳＲＥＱを伝搬するためにパケットを再送信する中間ノードは、このソースアドレスを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。
【００４８】
以下、ＳＲＥＱフィールドについて述べる。オプションタイプは、３２である。オプションデータ長とは、８ビットの符号無し整数であり、オプションタイプフィールドと、オプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元により生成された、１６ビットの一意の値である。この値によって、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうかを決定できる。この識別表示の値が、受信ノードにより自身の探索要求テーブル内に発見された場合、この受信ノードは探索要求を廃棄して、ＳＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。Ｋｌｅｎとは、オプション中のキーワードの数を示す、４ビット値である。従って、キーワードの最大数は、１５である。次に、キーワードについて説明するが、キーワード［ｉ］とは、以前に選択されたサービスタイプの探索基準を明示する、文字列の３２ビットハッシュ値である。続くキーワードが、基準をさらに制限する。従って、ＡＮＤ演算子である。次に、アドレスについて説明するが、アドレス［ｉ］とは、探索要求オプション内に記録されている、ｉ番目のノードのＩＰアドレスである。このフィールドは、無線通信ネットワーク内で経路を決定するために用いられる。
【００４９】
ハッシュ要求（ＨＲＥＱ）について説明する。ハッシュ要求（ＨＲＥＱ）とは、ＳＲＥＱの特殊な形式である。しかしながら、ＨＲＥＱは、探索基準として、ファイルサイズと要求されたデータの特性のみ使用する。この特性は、１２８ビット長であり、ＭＤ５ハッシュ手順により作成される。この特性により、ＨＲＥＱを用いて、経路の中断があった場合に、データの代わりのソースを発見できる。ＨＲＥＱも、ＳＲＥＱと同様に、ＤＳＲオプションのＲＲＥＱに基づいている。
【００５０】
表２−２にＨＲＥＱのビット構造を示し、ＨＲＥＱフィールドについて以下に説明する。
【００５１】
【表２】
【００５２】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＨＲＥＱを伝搬するためにこのパケットを再送信する中間ノードは、このフィールドを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。
【００５３】
以下、ＨＲＥＱＰフィールドについて説明する。オプションタイプは、３３である。オプションデータ長は、８ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元によって生成された１６ビットの一意の値である。この値により、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうか決定できる。この識別表示の値が、この受信ノードによってその探索要求テーブル内から発見された場合、この受信ノードはハッシュ要求を廃棄して、ＨＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。ファイルサイズとは、データのサイズをオクテット単位で示す３２ビット値である。ＭＤ５ハッシュとは、ＭＤ５手順で生成される１２８ビットのハッシュ値である。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次にアドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信した、ｉ番目のノードのＩＰアドレスである。このフィールドは、ＭＡＮＥＴ内の経路を決定するために用いられる。
【００５４】
以下、ファイル応答（ＦＲＥＰ）について説明する。ファイル応答（ＦＲＥＰ）オプションは、ピアが探索要求を受信した際の応答である。従って、この探索要求は、ＳＲＥＱまたはＨＲＥＱであり、このピアが共有するオブジェクトのメタデータに適合する。ＦＲＥＱは、要求されたデータがファイルであり、従って、その共有されたファイルに関するあらゆる必要な情報を含むことを暗に示す。この情報に基づいて、要求側のピアは、ファイル送信を起動できるが、これはモバイルピアツーピアプロトコルによる。ＳＲＥＱの場合と同様に、ＦＲＥＱの構造は、ネットワーク層プロトコルＤＳＲのオプションである経路応答（ＲＲＥＰ）の構造に基づいている。
【００５５】
表２−３にＦＲＥＰのビット構造を示し、ＦＲＥＰフィールドについて以下に説明する。
【００５６】
【表３】
【００５７】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。宛先アドレスは、ＳＲＥＱ、ＨＲＥＱを送信するノードのアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。
【００５８】
以下、ＦＲＥＰフィールドについて説明する。オプションタイプは、４８である。オプションデータ長とは、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）であり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。Ｕは、１ビットフラグであり、提供側のピアがアップロード可能かどうかを示す。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この合計は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。ファイル名長は、８ビット値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名は、ファイルの名称である。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信ノードＲまでの全経路を含む。
【００５９】
以下、プッシュ要求（ＰＲＥＱ）について説明する。プッシュ要求（ＰＲＥＱ）オプションは、応答のノードから送信ノードに送られ、続いて、送信ノードから応答ノードにデータがアップロードされる。
【００６０】
表２−４にＰＲＥＱのビット構造を示し、ＰＲＥＱフィールドについて以下に説明する。
【００６１】
【表４】
【００６２】
以下、ＩＰフィールドについて説明する。オプションタイプは、４９である。ソースアドレスは、ＰＲＥＱを生成するノードのＩＰアドレスである。宛先アドレスは、ＦＲＥＰを送信するノードのＩＰアドレスを含む。このアドレスは、ＦＲＥＰのソースアドレスフィールドからコピーすることが可能である。
【００６３】
以下、ＰＲＥＱフィールドについて説明する。オプションタイプは、４９である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＰＲＥＱは、送信ノードＳから受信側ノードＲまでの全経路を含む。この経路は、ＦＲＥＰを搬送した経路と同じ経路でなくてはならない。
【００６４】
以下、宣言返答（ＤＲＥＰ）について説明する。宣言返答（ＤＲＥＰ）オプションとは、探索要求を受信したピアの応答のことである。この探索要求は、ＳＲＥＱまたはＨＲＥＱである。ＤＲＥＰは、ネットワーク層プロトコルＥＤＳＲの一般的なオプションであり、アプリケーション開発者に対して、特定のアプリケーションの用件を満たすために、ＭＰＰを越えてプロトコルを使用できる可能性を提供する。従って、ＤＲＥＰは、提供されたサービスに関する特定の情報を送信するのではなく、サービスのプロファイルに関する情報を送信する。従って、モバイルピアツーピアプロトコルＭＰＰは、２つのピアの間の通信チャネルを確立するために必要なあらゆる情報を持つ、プロファイルを送信できる。ＤＲＥＰは、ＦＲＥＰの特殊な形式であり、ビット構造は異なっていない。ＤＲＥＰ内のデータ情報とは、サービスプロファイルのことである。
【００６５】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、ＤＲＥＰを生成するノードのＩＰアドレスである。宛先アドレスとは、ＳＲＥＱ、ＨＲＥＱを送信するノードのＩＰアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。
【００６６】
以下、ＤＲＥＱフィールドについて説明する。オプションタイプは、５０である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、プロファイルのサイズをオクテット単位で示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートによって、ピアとのＭＰＰ通信が可能となる。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この和は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５手順で生成される。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に特定する。ファイル名長は、８ビットの値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名とは、データの名称である。次にアドレスについて説明するが、アドレス［ｉ］とは、メッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信側ノードＲまでの全経路を含む。
【００６７】
図５は、モバイルピアツーピア層プロトコルレベルでの機能性を示す略図である。
【００６８】
図５に示すように、このプロトコル層の機能性は、第１のインターフェースユニット２８と、評価ユニット３０と、メモリーユニット３２と、探索応答生成ユニット３４と、データ交換ユニット３６と、登録ユニット３８と、第２のインターフェースユニット４０とに関連付けて使用される。
【００６９】
動作に際して、第１のインターフェースユニットは、ノードのアドレス情報の範囲を越えて拡張する探索基準を含んだ、サービス要求を受信する。ここで、サービス要求は、モバイルピアツーピアネットワークプロトコルの上で操作されるサービス内で生成されることに注意すべきである。
【００７０】
また、動作に際して、第２のインターフェースユニットは、サービス要求を、モバイルピアツーピアネットワークプロトコルの下位で稼動する、ネットワーク層ルーティングプロトコルと交換し、これにより、無線ネットワーク内の共有サービスリソースを特定する。第２のインターフェースユニット４０も、遠隔ノードで起動されるネットワーク層ルーティングプロトコルからサービス要求を受信し、このサービス要求を評価するために、モバイルピアツーピアプロトコル上で稼動しているサービスに転送する。
【００７１】
また、動作に際して、評価ユニット３０は、モバイルピアツーピアネットワークプロトコルレベルで、探索要求を評価する。従来、ピアツーピアサービスをさまざまなタイプに分類したものを記憶する、メモリーユニット３３も、評価のための基礎として提供されている。従来、評価ユニットは、図６に示すように、サービスリソース探索用のディレクトリ構造を用いて、モバイルピアツーピアサービスをさまざまなタイプに分類する。
【００７２】
動作に際して、図６に示す探索応答生成ユニット３４は、モバイルピアツーピアネットワークプロトコル上における探索要求の評価によって探索基準を満たしたことを認識すると、探索応答を生成し、続いて第２のインターフェースユニット４０を介して転送される。
【００７３】
モバイルピアツーピアプロトコルレベルでの機能性の更なる態様は、探索成功後の動作に関連している。
【００７４】
従来、データ交換ユニット３６は、無線モバイル通信ネットワーク内で経路を特定する、探索要求と探索応答の交換後に、モバイルピアツーピアプロトコル層でデータ交換のための直接交換を行う。また、動作に際して、データ交換ユニット３６は、接続の中断が発生すると、接続を回復する。本発明によるデータの直接交換は、可能な限りＨＴＴＰに基づいた、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードにより実施するのが望ましい。
【００７５】
上述したように、探索に直接的に関連する別のユニットとして、図６に示す登録ユニット３８がある。これによって、ネットワーク層ルーティングプロトコルでのモバイルピアツーピアサービスの登録と、後続の探索関連メッセージの交換のために、登録要求の提示後の、登録の結合の受信とが可能になる。
【００７６】
本発明のさらなる態様は、モバイルピアツーピアプロトコルレベルと、ネットワーク層ルーティングプロトコルとの間の、情報の交換に関連する。従来、図５に示すように、モバイルピアツーピア制御プロトコルは、モバイルピアツーピアプロトコル層レベルで機能性を実施する上位層と、ネットワーク層ルーティングプロトコルレベルでモバイルピア制御プロトコルの機能性を実施する下位層レベルとを有する。以下では、上位層をＭＰＣＰ７、下位層をＭＰＣＰ３と呼ぶ。
【００７７】
モバイルピアツーピア制御プロトコルは、サービス層とネットワーク層との間の通信チャネルを提供する、同期式のプロトコルである。従って、ＭＰＣＰは、一方ではＯＳＩ第３層で実施され、他方ではＯＳＩ第７層のそれぞれのサービスによって実施されなければならない。従って、ＭＰＣＰ３とＭＰＣＰ７は、個々に定義されている。
【００７８】
サービスにより提供される機能から、モバイルピア制御プロトコルＭＰＣＰを開発する必要性が生まれる。サービスは、データを提供するだけでなく、探索要求に対して肯定応答または否定応答のどちらを行うか、すなわち、サービスが、要求されたファイルを共有しているかどうかを判断しなければならない。肯定応答をする場合、サービスは、必要な情報をＥＤＳＲと通信し、これにより、ＦＲＥＰを要求側のピアに送信可能となるようにしなければならない。ＭＰＣＰは、以下のタスクを満たさなければならない。
第一に、登録である。１つのピアが複数のサービスを実施できるため、全てのサービスは、ネットワーク層に登録しなければならない。この結果、ネットワーク層は、サービスに対して、探索要求が入力されたことを適宜通知できる。ユーザがサービスを削除すると、このサービスは、ネットワーク層における登録を取り消さなければならない。
第二に、探索である。サービスが、そのユーザに対して、無線通信ネットワーク内のデータ探索の可能性を提供すると、ＭＰＣＰは、ＭＰＣＰ３を介して探索パラメータを、ネットワーク層プロトコルＥＤＳＲに転送しなければならない。
第三に、要求である。ＭＰＣＰ３は、入力された要求をＭＰＣＰ７に送信し、次にサービスに送信する。また、ＭＰＣＰは、適切な応答をネットワーク層プロトコルＥＤＳＲに送信する。
最後に、応答である。ＭＰＣＰ３は、応答が返ってきたことをＭＰＣＰ７に通知し、それから、ネットワーク層プロトコルＥＤＳＲでの動作を適宜開始する。
【００７９】
このようなタスクのために、本発明によれば、確認メッセージ、登録メッセージ、要求メッセージ、応答メッセージのようないくつかのメッセージが、特定のパラメータと共に定義される。
【００８０】
以下に、パラメータを伴うＭＰＣＰメッセージと、期待される応答とを詳細に述べる。
【００８１】
まず、確認メッセージとして、ＡＣＫ（肯定応答）がある。メッセージＡＣＫは、正常に受信したメッセージに対して応答する。
メッセージ形式は、ＡＣＫ（［Ｉｄ］）である。送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
このメッセージに対する応答に該当するものはない。
【００８２】
次に、確認メッセージとして、ＮＡＫ（否定応答）がある。メッセージＮＡＫは、エラーはないものの、正常に実行できないメッセージに対して応答する。この理由は、例えば、ユーザ権限、タイムアウトまたはその他類似のものである。異常の原因は、ＮＡＫ内の番号（コード）および文字列（理由）として、送信元に返却される。
メッセージ形式は、ＮＡＣ（［Ｉｄ］、コード、理由）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
コードは、異常の理由を明確に指定する番号である。
理由は、ユーザが読み取り可能な、異常の理由である。
このメッセージに対する応答に該当するものはない。
【００８３】
さらに、確認メッセージとして、ＥＲＲ（エラー）がある。メッセージＥＲＲは、メッセージ形式にエラーがあるメッセージに対して応答する。その理由は、例えば、登録されているサービスとの矛盾、もしくは、探索要求の不正な形式である。エラーの理由は、番号（エラーコード）および文字列（説明）として、送信元に返却される。
メッセージ形式は、ＥＲＲ（［Ｉｄ］、エラーコード、説明）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
エラーコードは、異常の理由を明確に指定する番号である。
説明は、ユーザが読み取り可能な、エラーの理由である。
このメッセージに対する応答に該当するものはない。
【００８４】
次に、登録メッセージとして、ＲＥＧ（登録）がある。メッセージＲＥＧによって、サービスは、自らをＭＰＣＰ３に登録できる。これは、必要な動作であり、通常、サービスを起動する際に行われる。登録されたサービスは、例えば、追加の処理のためにＩＳＲＥＱを受信できる。
メッセージ形式は、ＲＥＧ（Ｉｄ、ポート、（サービス））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子である。これは、例えば、プロセスＩＤ、または、例えばシステム時間および確率関数に基づいて生成される乱数、または、サービスが現在使用中のＩＰアドレスとポートの組み合わせである。
ＩＰは、サービスのＩＰアドレスである。これは、装置が、いくつかのネットワーク要素またはＩＰアドレスをサポートする場合に必要である。
ポートは、ＴＣＰポートである。これにより、サービスは、ＩＰアドレスを通して利用可能となる。
サービスは、サービスタイプのリストである。例えば、探索要求を受信した後は、登録されているサービスに対応するものだけが転送される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８５】
さらに、登録メッセージとして、ＤＲＥＧ（登録取消）がある。メッセージＤＲＥＧにより、サービスは、ＭＰＣＰ３の自らの登録を取り消すことができ、今後ＭＰＣＰ３からメッセージを受信することはない。
メッセージ形式は、ＤＲＥＧ（Ｉｄ）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８６】
次に、探索メッセージとして、ＳＥＱ（探索要求）がある。メッセージＳＲＥＱにより、ＭＰＣＰ７は、ＭＰＣＰ３におけるキーワードに基づいて、探索要求を起動できる。ＭＰＣＰのＳＲＥＱは、ＥＤＳＲプロトコルの対応するＳＲＥＱに変換され、次に下位に下げられる。
メッセージ形式は、ＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、文字列の１６ビットのハッシュ値であり、要求されたサービスを指定する。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８７】
次に、探索メッセージとして、ＩＳＲＥＱ（入力される探索要求）がある。ＩＳＲＥＱは、ＳＲＥＱに対応するメッセージである。ＭＰＣＰ３は、ＥＤＳＲの詳細なＳＲＥＱオプションを持つＩＳＲＥＱメッセージを、ＭＰＣＰ７に送る。すると、各サービスは、自らがこの探索要求に対して肯定応答するかどうか検証できる。
メッセージ形式は、ＩＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、ＥＤＳＲのＳＲＥＱを送信する前に、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８８】
さらに、探索メッセージとして、ＨＲＥＱ（ハッシュ要求）がある。ＨＲＥＱにより、サービスは、ＥＤＳＲのＨＲＥＱを起動し、データをダウンロードするための代替のソースを探索できる。
メッセージ形式は、ＨＲＥＱ（Ｉｄ、サービス、ファイルサイズ、ハッシュ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。このサービスは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドに対応している。
ファイルサイズは、オクテット単位のデータのサイズである。
ハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８９】
さらに、探索メッセージとして、ＩＨＲＥＱ（入力されるハッシュ要求）がある。ＭＰＣＰ３は、ＥＤＳＲのＨＲＥＱを受信すると、即座にメッセージＩＨＲＥＱをＭＰＣＰ７に送る。これにより、各サービスは、適宜応答することができる。
メッセージ形式は、ＩＨＲＥＱ（Ｉｄ、サービス、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。これは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドからのコピーである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のデータのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９０】
次に、応答メッセージとして、ＦＲＥＰ（ファイル応答）がある。ＦＲＥＰは、ＩＳＲＥＱまたはＩＨＲＥＱという形式を持つ探索要求を受信した際に、ファイルとして対応するデータが利用可能である場合における、サービスに対する肯定的な応答である。ＭＰＣＰ３は、ＩＰアドレスやＴＣＰポートなどの登録されているサービスのデータの情報に基づいて、ＥＤＳＲのＦＲＥＰを作成できる。
メッセージ形式は、（Ｉｄ、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９１】
さらに、応答メッセージとして、ＩＦＲＥＰ（入力されるファイル応答）がある。ＩＦＲＥＰは、ＦＲＥＰに対応するものである。ＩＦＲＥＰは、ＥＤＳＲのＦＲＥＰオプションの詳細な情報とともに、ＭＰＣＰ３によりＭＰＣＰ７に送られる。この情報に基づいて、サービスは、ＭＭＰ上でデータ転送を起動できる。
メッセージ形式は、ＩＦＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、提供されたサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスを得ることが可能となる。
ファイルハッシュは、全てのファイルに対する、１２８ハッシュビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９２】
さらに、応答メッセージとして、ＰＲＥＱ（プッシュ要求）がある。ＦＲＥＰを受信した後で、モバイルピアツーピアプロトコルＭＰＰは、提供されているピアに対し、与えられたＴＣＰポートを介して、直接接続を確立しようとする。もし不可能であれば、提供側のピアがファイアウォールの背後にある場合と同様に、そして、提供側のピアが、アップロードを許容する場合（ＦＲＥＰ内のＵフラグ）と同様に、ＭＰＣＰ７は、ＭＰＣＰ３にＰＲＥＱメッセージを送り、ＥＤＳＲのＰＲＥＱを起動する。ＰＲＥＱは、提供側のピアに対し、提供されたポートを介してＭＰＰのダウンロードを開始できないため、代わりにファイルをアップロードしてほしい旨を通知する。ＰＲＥＱにより、アップロードするために必要とされる全ての必要なデータが、提供される。
メッセージ形式は、ＰＲＥＱ（Ｉｄ、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、１２８ビットのＭＤ５ハッシュである。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に指定する。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９３】
さらに、応答メッセージとして、ＩＰＲＥＱ（入力されるプッシュ要求）がある。ＩＰＲＥＱは、ＰＲＥＱに対応するものである。これは、アップロードの必要がある、要求されているファイルに関する情報を含む。これは、ＥＤＳＲのＰＲＥＱを受信すると、ＭＰＣＰ３によりＭＰＣＰ７に送られる。これにより、モバイルピアツーピアプロトコルＭＰＰによるアップロードを開始することができる。
メッセージ形式は、ＩＰＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、要求側のサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスをアップロードすることが可能になる。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９４】
さらに、応答メッセージとして、ＤＲＥＰ（説明応答）がある。ＤＲＥＰは、ＥＤＳＲのＤＲＥＰメッセージの送信を要求する。ＭＰＣＰ７からＭＰＣＰ３に送られるが、これは、受信されたＩＳＲＥＱまたはＩＨＲＥＱに対する、肯定応答である。ＭＰＣＰ３は、ＥＤＳＲのＤＲＥＰを作成するためのＩＰアドレスやＴＣＰポートなどの、登録されているサービスに関する必要な情報を提供する。
メッセージ形式は、ＰＲＥＰ（Ｉｄ、プロファイルハッシュ、プロファイル名、プロファイルサイズ）である。
送信元は、ＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前にＭＰＣＰ３に登録するために用いられたものである。
プロファイルハッシュは、プロファイルデータに関する、１２８ビットのＭＤ５ハッシュ値である。
プロファイル名は、プロファイルの名前である。
プロファイルサイズは、オクテット単位のプロファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９５】
上記に加えて、本発明により提案されているプロトコルスタックが、ＳＤＬでシミュレーションされ、その機能が立証された。特に、ノードの数を５としてシミュレーションを行った。これらの調査およびそれに関連するものと、以前からあるソリューション、特にグヌーテラとを比較すると、本発明によるプロトコルスタックが、アドホックネットワークで用いられてきた従来のピアツーピアプロトコルよりも、性能面で飛躍的に向上していることがわかる。より詳細に述べると、ファイル探索が１回成功する毎のオーバーヘッドは、グヌーテラの場合で４８５０バイトであり、ＭＰＰの場合は１９６６バイトであった。さらに、バックグラウンドのトラフィックは、グヌーテラの場合で２．４３キロビット／秒、ＭＰＰの場合は０．０２９キロビット／秒であった。
【図面の簡単な説明】
【００９６】
【図１】本発明の動機付けとなる、無線ネットワーク上で稼動する、ピアツーピアアプリケーションの例を示す図である。
【図２】本発明による、無線通信ネットワーク上で稼動する、ピアツーピア運用のためのプロトコルスタックを示す図である。
【図３】本発明による、モバイルピアツーピアネットワークにおける、データの探索とダウンロードを示すメッセージ順序表である。
【図４】ネットワーク層ルーティングプロトコルレベルでの機能性を示す概略図である。
【図５】モバイルピアツーピアプロトコルレベルでの機能性を示す概略図である。
【図６】本発明による、サービスリソースの探索の基礎となるディレクトリ構造を示す図である。
【図７】モバイルピア制御プロトコルレベルにおける機能性を示す概略図である。
【技術分野】
【０００１】
本発明は、モバイル通信環境におけるモバイルピアツーピアネットワーク構築のためのプロトコルスタックに関し、特に、アプリケーション層に新たなサービスとオプションとを導入し、性能を向上させるための、モバイル無線ネットワークにおけるピアツーピアオーバーレイネットワーク構築をサポートするプロトコルスタックに関する。
【背景技術】
【０００２】
一般的に、ピアツーピアアプリケーションは、最適化アルゴリズムを有するため、ＴＣＰや仮想的に安定した通信などのネットワーク層プロトコルに依存する一方、オーバーレイネットワーク内で情報を検出することができる。それにもかかわらず、無線通信ネットワークにおいて、特にアドホック無線通信ネットワークにおいては、あらゆるモバイルノードが稼動するため、接続の中断がよくある。
【０００３】
データパケット転送中の２つの近接したモバイルノードが、お互いの近傍から離れる場合は常に、両モバイルノード間の接続は中断する。すると、ネットワーク層プロトコルの上位にあるピアツーピアアプリケーションを意識していないネットワーク層プロトコルは、どのようなことをする必要があるのかとは関係なく、同じ宛先ノードに至る新たな経路を再構築しようとする。
【０００４】
それにもかかわらず、同じ情報源への新たな経路を確立しようとする代わりに、ネットワークトポロジーを変更すれば、他の情報源が、同じ情報をより低いコストで提供できる。
【０００５】
言い換えると、モバイルノードは、接続が中断したことをピアツーピアプロトコルレベルと、関連したアプリケーションとに報告し、その後、これらが、古い情報源がまだ利用可能であるか、または別の情報源がより適切であるかを決定する。
【０００６】
さらに、ピアツーピアネットワークは、通常、固定式ネットワーク構造の上で動作するため、ピアツーピアネットワークノードは、近傍にある通信当事者と遠隔のネットワーク参加者を区別しない。モバイルノード間の距離は、一般に、固定式ネットワークにおける通信の安定性と、エラーのない動作とに影響しないため、探索情報も密接に利用可能であるとはいえ、通常のピアツーピアプロトコルは、離れたノードへの接続を確立できる。
【０００７】
より詳細な一例として、図１は、４つのノードを有するモバイルアドホックネットワークの上で動作する、簡単なピアツーピアファイル共有アプリケーションを示している。ピアツーピアオーバーレイネットワークレベルでは、ノードＡはノードＤへの静的接続を維持しており、従って、ノードＡがネットワーク内のファイルを探索する場合、照会メッセージをノードＤに送信する。要求されたファイルが、ノードＤでは入手不可能な場合、ノードＤは、そのメッセージをノードＢに対して、このノードＢへの接続、すなわち、接続２を介して転送する。
【０００８】
図１に示す例によれば、このメッセージは、同じ理由でノードＣに再び転送されるため、要求されたファイルはこのノードＣで公開されることが、推測される。従って、物理ネットワーク層では、たった２ホップしかはなれていないノードＣを発見するのに６個の無線接続を用いる。
【０００９】
結論として、静的オーバーレイ接続を維持することは、帯域幅とバッテリの電力が非常に乏しいリソースであるモバイルアドホックネットワークなどの無線通信ネットワークにおいて、ピアツーピアネットワークプロトコルを適用する際の、性能上の大きなボトルネックである。
【００１０】
先行技術で、ピアツーピアアプリケーションとアドホック無線通信ネットワークとの組み合わせに関するいくつかの調査が行われているが、それでも、その調査には、ピアツーピアネットワークプロトコルレベルでのアドホックネットワーク構築の可能性に関する十分な考慮が欠けている。例えば、白書２００２年のＪＸＭＥ，Ａ．Ａｒｏｒａの「ＪＸＴＡ ｆｏｒ Ｊ２ＭＥTM−Ｅｘｔｅｎｄｉｎｇ ｔｈｅ Ｒｅａｃｈ ｏｆ Ｗｉｒｅｌｅｓｓ Ｗｉｔｈ ＪＸＴＡ Ｔｅｃｈｎｏｌｏｇｙ」では、ＪＸＴＡをモバイル環境に適応させているが、それでもモバイルアドホックについては十分に考慮していない。さらに、２００２年、イタリア、ボローニャでの、埋め込み型、ウエアラブル型およびモバイル型デバイスについてのユビキタスエージェントに関するワークショップの議事録「ＬＥＡＰ ｉｎｔｏ ＡｄＨｏｃ Ｎｅｔｗｏｒｋｓ」は、ルーティングに関する疑問を呈しておらず、また、２００１年のカリフォルニア州ロングビーチ市でのモバイルアドホックネットワーク構築に関するＡＣＭシンポジウム（ＭＯＢＩＨＯＣ２００１）議事録の７ＤＳ、Ｍ．ＰａｐａｄｏｐｏｕｌｉとＨ．Ｓｃｈｕｌｚｒｉｎｅの「Ｅｆｆｅｃｔ ｏｆ Ｐｏｗｅｒ Ｃｏｎｓｅｒｖａｔｉｏｎ，Ｗｉｒｅｌｅｓｓ Ｃｏｖｅｒａｇｅ ａｎｄ Ｃｏｏｐｅｒａｔｉｏｎ ｏｎ Ｄａｔａ Ｄｉｓｓｅｍｉｎａｔｉｏｎ ａｍｏｎｇ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ」では、位置情報が考慮されていない。さらに、２００１年ジョージア州アトランタ市での、ユビキタスコンピューティングのためのアプリケーションモデルとプログラミングツールに関するワークショップの議事録（ＵＢＩＣＯＭＰ２００１）のＰＲＯＥＭ、Ｇ．ＫｏｒｔｕｅｍとＪ．Ｓｃｈｎｅｉｄｅｒによる「Ａｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋｓ」には、より大型のモバイルアドホックシナリオのためのスケーリングが欠如しており、一方、２００３年フランスのソフィアアンティポリス市でのモバイルアドホックネットワーク構築とコンピューティングに関するワークショップの議事録（ＭＡＤＮＥＴ２００３）のＯＲＩＯＮ、Ａ．Ｋｌｅｍｍ、Ｃ．ＬｉｎｄｅｍａｎｎとＯ．Ｐ．Ｗａｌｄｈｏｒｓｔによる「Ａ Ｓｐｅｃｉａｌ−Ｐｕｒｐｏｓｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｆｉｌｅ Ｓｈａｒｉｎｇ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ」では、ファイル共有アプリケーションのみ焦点を当てており、位置に対する認識が欠如していて、ルーティングのオーバーヘッドが大きい。さらにまた、Ｂｌｕｅｔｏｏｔｈ規格では、アドホック通信環境におけるピアツーピアアプリケーションに対して考慮がなされているが、それでも、非常に短距離の通信以外はルーティングをサポートしていない。
【００１１】
要約すると、無線アドホック通信ネットワークに対して、このようなアドホックネットワークの特定の要件を考慮することなく、ピアツーピアコンピューティングを導入しても、性能は悪いものとなる。これは、ピアツーピアプロトコルが、下位のプロトコルに関する認識や情報、例えば、要求されたコンテンツや参加者の位置情報が全くなく、完全に独立したオーバーレイネットワーク構築に役立つように設計されているからである。このように、ピアツーピアネットワークにおいて近傍に関する認識が欠如しているため、遠隔接続となるが、その一方で、同じコンテンツがより密接に利用可能となる。また、モバイルアドホックネットワークでは、ホップの数が増えるとルーティングのオーバーヘッドも増加する、ホップ順ルーティングが採用されているが、ピアツーピアネットワークは、現在、下位の経路を意識しておらず、従って、最適な経路に関して判断することは不可能である。言い換えると、ピアツーピアプロトコルは固定式ネットワーク用に設計されており、従って、特に接続のロスが発生すると、参加者がピアツーピアネットワークから去ったかのように認識されるため、即座に再ルーティングをするモバイル通信環境において、変化するチャネル状態に対処することは不可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上記事情に鑑み、本発明の目的は、モバイル無線通信ネットワークを介してのピアツーピアネットワーク構築を最適化することにある。
【課題を解決するための手段】
【００１３】
全体として、本発明は、ネットワーク層からアプリケーション層へ、またはその逆へと展開するモバイルピアツーピアプロトコルスタックを紹介する。ここで、上位のピアツーピアネットワークプロトコル層は、適当な探索基準を指定するだけでなく、適切な応答を受信し、その結果、無線ネットワークを認識して、トラフィックを最小化し、頻繁に発生する経路の中断に対処する。加えて、ネットワーク層ルーティングレベルは、ピアツーピアアプリケーションに関する情報を受信して、適当な通信ノードにしか通じていない経路を確立する。従って、本発明は、無線通信ネットワーク、例えば、アドホック無線ネットワークで、互いに異なるさまざまな関連サービスを生成するために必要なフレームワークを形成するものである。
【００１４】
従って、モバイル無線ネットワークでのピアツーピアアプリケーションの最適化は、ユーザにおいて、より高い度合いの受け入れをサポートし、また、固定式もしくは集中式のインフラストラクチャを用いることなく、サービスプロバイダの経費と、位置に基づいたサービスおよびアプリケーションを提供するための経費とを削減する。
【００１５】
本発明によれば、請求項１および３１に従って、ネットワーク層ルーティングプロトコルを使用する方法および装置と、独立請求項１９と５９に従って、モバイルピアツーピアネットワークプロトコルを利用する方法と、独立請求項３７と７７に従って、モバイルピアツーピアプロトコルレベルおよびネットワーク層ルーティングプロトコルレベル間での、層間通信チャネルプロトコルを利用する方法とに依存して、モバイル無線通信ネットワーク、例えば、アドホックネットワークでピアツーピア通信を最適化するプロトコルスタックが提供される。
【００１６】
言い換えると、本発明によるプロトコルスタックは、動的なソースルーティングを考慮しており、また、例えば近接性に基づいてサービスを提供しているピアを発見することを可能にする、強化されたネットワーク層プロトコルと、アプリケーション層でのデータ交換のためのモバイルピアツーピアプロトコルと、これらの正式な２つのプロトコル間の層間通信のための同期式プロトコルとを含む。
【００１７】
本発明は、特に、ネットワーク層プロトコルの機能性を強化することを提案する。その結果、無線通信ネットワーク内でアプリケーションリソースを取得するために適用された照会メッセージが、例えば、照会に対して応答するモバイル通信ネットワーク内のモバイルノードの近接性、またはサービス能力に従って、アドレス情報の範囲を越えて拡張する探索基準を考慮できるようになる。従って、本発明は、無線通信ネットワークのトポロジに関する情報が実際に利用可能となるように、ネットワーク層プロトコルの探索基準を改善することを提案する。ネットワーク層ルーティングプロトコルレベルで用いられる探索基準のタイプに関する情報は、アプリケーションとサービスをサポートする上位のピアツーピア通信層プロトコルによって提供される。
【００１８】
本発明によれば、上位のピアツーピア層プロトコルとネットワーク層プロトコルとの間の探索基準の変更は、層間通信チャネルプロトコルによって達成でき、特に、ピアツーピアプロトコルスタック内の異なる階層レベル間の探索関連メッセージの交換に適用できる。
【００１９】
従って、適切なサービスリソースを探索している最中は、無線通信ネットワーク内での適切なリンクの維持と層間通信プロトコルの操作とによって、品質の向上と、経費の減少と、ピアツーピアサービスのプロバイダに対する経費の減少とによる、無線通信ネットワークでのピアツーピアサービスをユーザが受け入れる度合の向上が、達成できる。ピアツーピアサービスは、高度に動的で、急速に変化する無線通信ネットワーク、特に、無管理、無制御のアドホック無線通信環境でのルーティング機能性を提供するのに完全に適している。
【００２０】
本発明の別の好ましい実施形態によれば、モバイル通信環境において処理デバイスの内部メモリに直接読み込み可能なコンピュータプログラム製品が提供できる。ここで、このコンピュータプログラム製品は、モバイル通信環境の処理デバイス上で実行されると、本発明に係るプロトコルを使用するソフトウェアコードを含む。
【００２１】
従って、本発明はまた、コンピュータシステムまたはプロセッサシステムで、上述した様々なプロトコルを使用するために提供される。結論として、この結果、コンピュータシステム、または、より具体的には、アドホックネットワークなどに含まれるプロセッサと共に用いられる、コンピュータプログラム製品が、提供されることになる。
【００２２】
書き込み不可能な記憶媒体、例えば、プロセッサやコンピュータの入出力付属品によって読み取り可能な、ＲＯＭやＣＤ−ＲＯＭディスクなどの読み取り専用メモリに、永久的に記憶される情報と、書き込み可能な記憶媒体、すなわち、フロッピー（登録商標）ディスクおよびハードドライブに記憶される情報と、モデムあるいは他のインターフェースデバイスを介し、ネットワークやインターネット、電話網などの通信媒体を通して、コンピュータあるいはプロセッサに伝達される情報とを含む、本発明の機能を特徴づけるこのプログラムは、多くの形態のコンピュータあるいはプロセッサに提供できる。本発明の概念を実行する命令を読み取ることができるプロセッサを用いる際に、上述した媒体により、本発明の代替の実施形態が提示されることを理解すべきである。
【発明を実施するための最良の形態】
【００２３】
以下に、本発明の最良の形態およびさまざまな態様、好ましい実施形態を、図表を参照しながら説明する。さまざまな機能性を以下に説明するが、これらの機能性は、ソフトウェア、ハードウエア、あるいは、これらの組み合わせで実現できる。さらに、さまざまな態様のプロトコルの使用を、さまざまなレベルで抽出して説明するが、以下に説明する各々のプロトコルおよび関連した実施は、単体で操作され、または、本発明によるピアツーピアプロトコルスタックの実施の全体的な枠組内にある、さらなる関連のプロトコルおよび対応する実施と組み合わせて操作されることに注意すべきである。
【００２４】
図２に、本発明による、無線通信ネットワーク上にあるピアツーピア動作用のプロトコルスタックを示す。
【００２５】
図２に示すように、本発明は、モバイルピアツーピアプロトコルＭＰＰと、拡張ダイナミックソースルーティングプロトコルＥＤＳＲと、モバイルピア通信チャネル制御プロトコルＭＰＣＰとの提供と実施とに関する。
【００２６】
図２に示すように、拡張ダイナミックソースルーティングプロトコルＥＤＳＲは、ＯＳＩプロトコルスタックに従って、リンク層と物理層の上位で実行されるが、これは、本発明の範囲との関連性を考慮することなく、モバイルアドホック通信ネットワーク、以下すなわちＭＡＮＥＴと呼ばれる。しかしながら、一般に、本発明はまた、以下に説明するようにネットワーク層においてルーティングプロトコルをサポートする限り、他のどのようなタイプの無線通信ネットワークにも適用可能であることに注意すべきである。
【００２７】
図２に示されている、ピアツーピアモバイルアドホックネットワークには、ピアの検出とパケットのルーティングという、共通する二つの課題がある。これらの課題を解決するため、ピアツーピアネットワークとモバイルアドホック通信ネットワークとの間の相乗効果により、モバイルピアツーピアプロトコルの管理負担を軽減し、その性能および信頼性を向上させる。
【００２８】
図２に示すように、より詳しくは、ピアツーピアプロトコルにより、ピアは、直接的にデータを交換することが可能となり、従って、このプロトコルは、ピアツーピアネットワーク内でサービス関連のデータ、例えば、ファイルに関与することになる。モバイルピアツーピアプロトコルは、例えばＨＴＴＰに基づいて、データをアップロードし、ダウンロードする能力を有する。リンクの中断により送信が遮断された場合、コンテンツ範囲にあるヘッダーが、ファイルの転送を再開する能力を提供する。本発明によれば、ＨＴＴＰは、その豊富な特徴の集合と、さまざまなコンピュータ言語で利用可能な多くの標準実施との一例として適用される。しかしながら、同じ機能性を持つ他のどのようなプロトコルを適用しても良い。
【００２９】
さらに、拡張ダイナミックソースルーティングプロトコルは、既存のネットワーク層プロトコル、例えば、ＤＳＲプロトコルに対して、新しいタイプの要求と応答を有する。従って、拡張ダイナミックソースルーティングプロトコルは、単なるＩＰアドレス以外の基準によってピアを発見する手段となる。それにもかかわらず、拡張ネットワーク層ルーティングプロトコルＥＤＳＲは、以前に公知のダイナミックソースルーティングプロトコルの基本的動作を変更しておらず、従って、ＥＤＳＲノードは、既存のＤＳＲネットワークになくてはならない部分である。
【００３０】
さらに、モバイルピア制御プロトコルは、拡張ダイナミックソースルーティングプロトコルと、ネットワーク層とを、アプリケーション層内のピアツーピアアプリケーションと共にリンクする。以下に詳細に説明するように、モバイルピア制御プロトコルを用いて、アプリケーションは、拡張ダイナミックソースルーティング層に登録し、探索要求を起動して、無線通信ネットワーク内の他のノードから入力される探索要求を処理する。言い換えると、モバイルピア制御プロトコルは、アプリケーション層とネットワーク層との間の、クロス層通信チャネルまたは層間通信チャネルである。モバイルピア制御プロトコルは、ファイル交換自体を除き、入出力要求および応答の全てを、対応するプロトコルと通信する。
【００３１】
図３に、本発明による、モバイルピアツーピアネットワーク内での、データの探索およびダウンロード、アップロードを示す、メッセージ順序表を示す。
【００３２】
図３に示すユニットである、ピアツーピアアプリケーション（Ａ）１０と、ピアツーピアアプリケーション（Ｂ）１２とは、以下に説明するように、データ交換用の通信チャネルを起動するモバイル通信環境内で実行されるピアツーピアアプリケーションＡとＢとに関連している。さらに、追加のユニットＥＤＳＲ（Ａ）１４と、ＥＤＳＲ（Ｂ）１６とは、それぞれ、ピアツーピアアプリケーション（Ａ）と、ピアツーピアアプリケーション（Ｂ）とについて、ネットワーク通信プロトコル層で用いる機能性に関連している。
【００３３】
図３に示すように、制御関連のデータもしくはペイロードデータの交換は、順序表内のエラーラインで表されている。
【００３４】
以下に、ネットワークプロトコル層の使用と機能性との詳細な態様を、図４〜６を参照して説明する。
【００３５】
図４に、ＥＤＳＲ（Ａ）と（Ｂ）の概略図を示す。本発明によれば、このようなユニットは、それぞれ、無線通信ネットワーク内のノードにおいて、関連する拡張ダイナミックソースルーティングプロトコル機能を使用する目的で操作されるものと仮定する。
【００３６】
図４に示すように、このような拡張ダイナミックソースルーティングプロトコルユニット（Ａ）は、受信ユニット１８と、変換ユニット１９と、転送ユニット２０とに分割される。
【００３７】
第１のインターフェースユニット１８は、モバイルピアツーピア層プロトコル、すなわち、ピアツーピアアプリケーション（Ａ）の上で稼動するサービスを介して起動されるサービス要求に関連する探索関連のデータを受信することができる。さらに、変換ユニット２０は、提示された探索関連データを、ネットワーク層ルーティングプロトコルＥＤＳＲに従って、照会メッセージに変換する。すでに概説したように、本発明では、照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準、すなわち、サービスリソースまたはこのようなタイプのサービスリソース、すなわち、データのタイプまたはサービスのタイプに対して、探索を起動するノードへの近接性の態様を特定する基準を含むことを提案する。さらに、動作に際して、転送ユニット２２は、照会項目を、サービスリソースの探索時に無線通信ネットワークを通して展開するために、下位層に出力する。
【００３８】
本発明で意味するところの探索基準の一般的な例として、サービスを、例えば、無線アドホック通信ネットワーク内の最も近い範囲に位置付けし、後続のデータ転送トラフィックを最小化し、または、サービスのタイプ、例えば、レストラン、銀行業、駐車などを表示する。照会メッセージに対するより詳細な例としては、探索要求ＳＲＥＱ、ハッシュ要求ＨＲＥＱ、ファイル応答ＦＲＥＰ、プッシュ要求ＰＲＥＱ、宣言応答ＤＲＥＰに関連したものがあり、これらを以下に詳細に説明する。
【００３９】
図３と図４に示すように、拡張ダイナミックソースルーティングプロトコルは、ピアツーピアアプリケーションの登録を受信して、次にこの登録の受信を承認する。これは、図４に示されている登録ユニット２４によって達成できる。
【００４０】
さらに、これ以降続いて、および、照会メッセージの準備の後で、転送ユニット２２も、無線通信ネットワーク内の別のノード（Ｂ）から起動された、照会メッセージに対する応答を受信する。従来、拡張ダイナミックソースルーティングプロトコル（Ａ）および（Ｂ）の各々の使用において、受信ユニット１８と転送ユニット２２とは、無線ネットワークインフラストラクチャ内を、ネットワークプロトコル層からピアツーピアアプリケーションレベルに流れている、照会メッセージを交換し、アプリケーションレベルでさまざまな照会メッセージを評価する。この評価の結果次第で、すなわち、関連するノードで操作されたサービスにより探索基準が満たされたかどうかによって、探索応答が生成され、これが次にピアツーピアアプリケーションレベルから拡張ダイナミックソースルーティングレベルにまで転送されて、上記の探索要求を起動したノード、以下、送信ノードに転送される。
【００４１】
関連するさまざまな探索応答とは、ファイル応答、プッシュ応答、宣言応答である。
【００４２】
探索に関連し、図４に示す評価ユニット２６により達成されるさらなる態様として、探索を起動するノードで複数の探索応答を受信した際に、異なる探索要求を評価するという態様がある。本明細書において、評価ユニット２６は、少なくとも１つの所定の費用関数、例えば、送信ノードと受信ノードとを接続する無線ネットワークの経路上の少なくとも１つのノードの特性を処理する。この特性の典型的な例として、経路上のノードの数、ノードの送信出力、ノードの移動速度、ノードの転送がある。
【００４３】
以下において、上述した照会メッセージのさまざまな実例を説明する。従来、標準の機能を用いるＩＰフィールドと、本発明による探索基準に関連したフィールドとは、区別されている。
【００４４】
以下、探索要求（ＳＲＥＱ）について述べる。データを探索する際、ＥＤＳＲは、グヌーテラの照会メッセージのような類似のメッセージ、すなわち、探索要求（ＳＲＥＱ）を提供する。ＳＲＥＱは、モバイルＰ２Ｐネットワークにおけるデータ探索の初期のオプションである。ＳＲＥＱは、ＤＳＲオプションルート要求（ＲＲＥＱ）に基づいている。ＳＲＥＱは、応答として、応答タイプ（ｘＲＥＰ）のオプションが返却されるのを待っている。ＥＤＳＲが求める応答のタイプは、当初に要求されたサービスとデータタイプとに依存する。
【００４５】
表２−１に、ＳＲＥＱのビット構造を示し、ＳＲＥＱフィールドについて以下に説明する。
【００４６】
【表１】
【００４７】
以下、ＩＰフィールドについて述べる。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＳＲＥＱを伝搬するためにパケットを再送信する中間ノードは、このソースアドレスを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。
【００４８】
以下、ＳＲＥＱフィールドについて述べる。オプションタイプは、３２である。オプションデータ長とは、８ビットの符号無し整数であり、オプションタイプフィールドと、オプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元により生成された、１６ビットの一意の値である。この値によって、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうかを決定できる。この識別表示の値が、受信ノードにより自身の探索要求テーブル内に発見された場合、この受信ノードは探索要求を廃棄して、ＳＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。Ｋｌｅｎとは、オプション中のキーワードの数を示す、４ビット値である。従って、キーワードの最大数は、１５である。次に、キーワードについて説明するが、キーワード［ｉ］とは、以前に選択されたサービスタイプの探索基準を明示する、文字列の３２ビットハッシュ値である。続くキーワードが、基準をさらに制限する。従って、ＡＮＤ演算子である。次に、アドレスについて説明するが、アドレス［ｉ］とは、探索要求オプション内に記録されている、ｉ番目のノードのＩＰアドレスである。このフィールドは、無線通信ネットワーク内で経路を決定するために用いられる。
【００４９】
ハッシュ要求（ＨＲＥＱ）について説明する。ハッシュ要求（ＨＲＥＱ）とは、ＳＲＥＱの特殊な形式である。しかしながら、ＨＲＥＱは、探索基準として、ファイルサイズと要求されたデータの特性のみ使用する。この特性は、１２８ビット長であり、ＭＤ５ハッシュ手順により作成される。この特性により、ＨＲＥＱを用いて、経路の中断があった場合に、データの代わりのソースを発見できる。ＨＲＥＱも、ＳＲＥＱと同様に、ＤＳＲオプションのＲＲＥＱに基づいている。
【００５０】
表２−２にＨＲＥＱのビット構造を示し、ＨＲＥＱフィールドについて以下に説明する。
【００５１】
【表２】
【００５２】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＨＲＥＱを伝搬するためにこのパケットを再送信する中間ノードは、このフィールドを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。
【００５３】
以下、ＨＲＥＱＰフィールドについて説明する。オプションタイプは、３３である。オプションデータ長は、８ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元によって生成された１６ビットの一意の値である。この値により、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうか決定できる。この識別表示の値が、この受信ノードによってその探索要求テーブル内から発見された場合、この受信ノードはハッシュ要求を廃棄して、ＨＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。ファイルサイズとは、データのサイズをオクテット単位で示す３２ビット値である。ＭＤ５ハッシュとは、ＭＤ５手順で生成される１２８ビットのハッシュ値である。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次にアドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信した、ｉ番目のノードのＩＰアドレスである。このフィールドは、ＭＡＮＥＴ内の経路を決定するために用いられる。
【００５４】
以下、ファイル応答（ＦＲＥＰ）について説明する。ファイル応答（ＦＲＥＰ）オプションは、ピアが探索要求を受信した際の応答である。従って、この探索要求は、ＳＲＥＱまたはＨＲＥＱであり、このピアが共有するオブジェクトのメタデータに適合する。ＦＲＥＱは、要求されたデータがファイルであり、従って、その共有されたファイルに関するあらゆる必要な情報を含むことを暗に示す。この情報に基づいて、要求側のピアは、ファイル送信を起動できるが、これはモバイルピアツーピアプロトコルによる。ＳＲＥＱの場合と同様に、ＦＲＥＱの構造は、ネットワーク層プロトコルＤＳＲのオプションである経路応答（ＲＲＥＰ）の構造に基づいている。
【００５５】
表２−３にＦＲＥＰのビット構造を示し、ＦＲＥＰフィールドについて以下に説明する。
【００５６】
【表３】
【００５７】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。宛先アドレスは、ＳＲＥＱ、ＨＲＥＱを送信するノードのアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。
【００５８】
以下、ＦＲＥＰフィールドについて説明する。オプションタイプは、４８である。オプションデータ長とは、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）であり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。Ｕは、１ビットフラグであり、提供側のピアがアップロード可能かどうかを示す。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この合計は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。ファイル名長は、８ビット値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名は、ファイルの名称である。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信ノードＲまでの全経路を含む。
【００５９】
以下、プッシュ要求（ＰＲＥＱ）について説明する。プッシュ要求（ＰＲＥＱ）オプションは、応答のノードから送信ノードに送られ、続いて、送信ノードから応答ノードにデータがアップロードされる。
【００６０】
表２−４にＰＲＥＱのビット構造を示し、ＰＲＥＱフィールドについて以下に説明する。
【００６１】
【表４】
【００６２】
以下、ＩＰフィールドについて説明する。オプションタイプは、４９である。ソースアドレスは、ＰＲＥＱを生成するノードのＩＰアドレスである。宛先アドレスは、ＦＲＥＰを送信するノードのＩＰアドレスを含む。このアドレスは、ＦＲＥＰのソースアドレスフィールドからコピーすることが可能である。
【００６３】
以下、ＰＲＥＱフィールドについて説明する。オプションタイプは、４９である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＰＲＥＱは、送信ノードＳから受信側ノードＲまでの全経路を含む。この経路は、ＦＲＥＰを搬送した経路と同じ経路でなくてはならない。
【００６４】
以下、宣言返答（ＤＲＥＰ）について説明する。宣言返答（ＤＲＥＰ）オプションとは、探索要求を受信したピアの応答のことである。この探索要求は、ＳＲＥＱまたはＨＲＥＱである。ＤＲＥＰは、ネットワーク層プロトコルＥＤＳＲの一般的なオプションであり、アプリケーション開発者に対して、特定のアプリケーションの用件を満たすために、ＭＰＰを越えてプロトコルを使用できる可能性を提供する。従って、ＤＲＥＰは、提供されたサービスに関する特定の情報を送信するのではなく、サービスのプロファイルに関する情報を送信する。従って、モバイルピアツーピアプロトコルＭＰＰは、２つのピアの間の通信チャネルを確立するために必要なあらゆる情報を持つ、プロファイルを送信できる。ＤＲＥＰは、ＦＲＥＰの特殊な形式であり、ビット構造は異なっていない。ＤＲＥＰ内のデータ情報とは、サービスプロファイルのことである。
【００６５】
以下、ＩＰフィールドについて説明する。ソースアドレスとは、ＤＲＥＰを生成するノードのＩＰアドレスである。宛先アドレスとは、ＳＲＥＱ、ＨＲＥＱを送信するノードのＩＰアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。
【００６６】
以下、ＤＲＥＱフィールドについて説明する。オプションタイプは、５０である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、プロファイルのサイズをオクテット単位で示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートによって、ピアとのＭＰＰ通信が可能となる。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この和は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５手順で生成される。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に特定する。ファイル名長は、８ビットの値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名とは、データの名称である。次にアドレスについて説明するが、アドレス［ｉ］とは、メッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信側ノードＲまでの全経路を含む。
【００６７】
図５は、モバイルピアツーピア層プロトコルレベルでの機能性を示す略図である。
【００６８】
図５に示すように、このプロトコル層の機能性は、第１のインターフェースユニット２８と、評価ユニット３０と、メモリーユニット３２と、探索応答生成ユニット３４と、データ交換ユニット３６と、登録ユニット３８と、第２のインターフェースユニット４０とに関連付けて使用される。
【００６９】
動作に際して、第１のインターフェースユニットは、ノードのアドレス情報の範囲を越えて拡張する探索基準を含んだ、サービス要求を受信する。ここで、サービス要求は、モバイルピアツーピアネットワークプロトコルの上で操作されるサービス内で生成されることに注意すべきである。
【００７０】
また、動作に際して、第２のインターフェースユニットは、サービス要求を、モバイルピアツーピアネットワークプロトコルの下位で稼動する、ネットワーク層ルーティングプロトコルと交換し、これにより、無線ネットワーク内の共有サービスリソースを特定する。第２のインターフェースユニット４０も、遠隔ノードで起動されるネットワーク層ルーティングプロトコルからサービス要求を受信し、このサービス要求を評価するために、モバイルピアツーピアプロトコル上で稼動しているサービスに転送する。
【００７１】
また、動作に際して、評価ユニット３０は、モバイルピアツーピアネットワークプロトコルレベルで、探索要求を評価する。従来、ピアツーピアサービスをさまざまなタイプに分類したものを記憶する、メモリーユニット３３も、評価のための基礎として提供されている。従来、評価ユニットは、図６に示すように、サービスリソース探索用のディレクトリ構造を用いて、モバイルピアツーピアサービスをさまざまなタイプに分類する。
【００７２】
動作に際して、図６に示す探索応答生成ユニット３４は、モバイルピアツーピアネットワークプロトコル上における探索要求の評価によって探索基準を満たしたことを認識すると、探索応答を生成し、続いて第２のインターフェースユニット４０を介して転送される。
【００７３】
モバイルピアツーピアプロトコルレベルでの機能性の更なる態様は、探索成功後の動作に関連している。
【００７４】
従来、データ交換ユニット３６は、無線モバイル通信ネットワーク内で経路を特定する、探索要求と探索応答の交換後に、モバイルピアツーピアプロトコル層でデータ交換のための直接交換を行う。また、動作に際して、データ交換ユニット３６は、接続の中断が発生すると、接続を回復する。本発明によるデータの直接交換は、可能な限りＨＴＴＰに基づいた、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードにより実施するのが望ましい。
【００７５】
上述したように、探索に直接的に関連する別のユニットとして、図６に示す登録ユニット３８がある。これによって、ネットワーク層ルーティングプロトコルでのモバイルピアツーピアサービスの登録と、後続の探索関連メッセージの交換のために、登録要求の提示後の、登録の結合の受信とが可能になる。
【００７６】
本発明のさらなる態様は、モバイルピアツーピアプロトコルレベルと、ネットワーク層ルーティングプロトコルとの間の、情報の交換に関連する。従来、図５に示すように、モバイルピアツーピア制御プロトコルは、モバイルピアツーピアプロトコル層レベルで機能性を実施する上位層と、ネットワーク層ルーティングプロトコルレベルでモバイルピア制御プロトコルの機能性を実施する下位層レベルとを有する。以下では、上位層をＭＰＣＰ７、下位層をＭＰＣＰ３と呼ぶ。
【００７７】
モバイルピアツーピア制御プロトコルは、サービス層とネットワーク層との間の通信チャネルを提供する、同期式のプロトコルである。従って、ＭＰＣＰは、一方ではＯＳＩ第３層で実施され、他方ではＯＳＩ第７層のそれぞれのサービスによって実施されなければならない。従って、ＭＰＣＰ３とＭＰＣＰ７は、個々に定義されている。
【００７８】
サービスにより提供される機能から、モバイルピア制御プロトコルＭＰＣＰを開発する必要性が生まれる。サービスは、データを提供するだけでなく、探索要求に対して肯定応答または否定応答のどちらを行うか、すなわち、サービスが、要求されたファイルを共有しているかどうかを判断しなければならない。肯定応答をする場合、サービスは、必要な情報をＥＤＳＲと通信し、これにより、ＦＲＥＰを要求側のピアに送信可能となるようにしなければならない。ＭＰＣＰは、以下のタスクを満たさなければならない。
第一に、登録である。１つのピアが複数のサービスを実施できるため、全てのサービスは、ネットワーク層に登録しなければならない。この結果、ネットワーク層は、サービスに対して、探索要求が入力されたことを適宜通知できる。ユーザがサービスを削除すると、このサービスは、ネットワーク層における登録を取り消さなければならない。
第二に、探索である。サービスが、そのユーザに対して、無線通信ネットワーク内のデータ探索の可能性を提供すると、ＭＰＣＰは、ＭＰＣＰ３を介して探索パラメータを、ネットワーク層プロトコルＥＤＳＲに転送しなければならない。
第三に、要求である。ＭＰＣＰ３は、入力された要求をＭＰＣＰ７に送信し、次にサービスに送信する。また、ＭＰＣＰは、適切な応答をネットワーク層プロトコルＥＤＳＲに送信する。
最後に、応答である。ＭＰＣＰ３は、応答が返ってきたことをＭＰＣＰ７に通知し、それから、ネットワーク層プロトコルＥＤＳＲでの動作を適宜開始する。
【００７９】
このようなタスクのために、本発明によれば、確認メッセージ、登録メッセージ、要求メッセージ、応答メッセージのようないくつかのメッセージが、特定のパラメータと共に定義される。
【００８０】
以下に、パラメータを伴うＭＰＣＰメッセージと、期待される応答とを詳細に述べる。
【００８１】
まず、確認メッセージとして、ＡＣＫ（肯定応答）がある。メッセージＡＣＫは、正常に受信したメッセージに対して応答する。
メッセージ形式は、ＡＣＫ（［Ｉｄ］）である。送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
このメッセージに対する応答に該当するものはない。
【００８２】
次に、確認メッセージとして、ＮＡＫ（否定応答）がある。メッセージＮＡＫは、エラーはないものの、正常に実行できないメッセージに対して応答する。この理由は、例えば、ユーザ権限、タイムアウトまたはその他類似のものである。異常の原因は、ＮＡＫ内の番号（コード）および文字列（理由）として、送信元に返却される。
メッセージ形式は、ＮＡＣ（［Ｉｄ］、コード、理由）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
コードは、異常の理由を明確に指定する番号である。
理由は、ユーザが読み取り可能な、異常の理由である。
このメッセージに対する応答に該当するものはない。
【００８３】
さらに、確認メッセージとして、ＥＲＲ（エラー）がある。メッセージＥＲＲは、メッセージ形式にエラーがあるメッセージに対して応答する。その理由は、例えば、登録されているサービスとの矛盾、もしくは、探索要求の不正な形式である。エラーの理由は、番号（エラーコード）および文字列（説明）として、送信元に返却される。
メッセージ形式は、ＥＲＲ（［Ｉｄ］、エラーコード、説明）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
エラーコードは、異常の理由を明確に指定する番号である。
説明は、ユーザが読み取り可能な、エラーの理由である。
このメッセージに対する応答に該当するものはない。
【００８４】
次に、登録メッセージとして、ＲＥＧ（登録）がある。メッセージＲＥＧによって、サービスは、自らをＭＰＣＰ３に登録できる。これは、必要な動作であり、通常、サービスを起動する際に行われる。登録されたサービスは、例えば、追加の処理のためにＩＳＲＥＱを受信できる。
メッセージ形式は、ＲＥＧ（Ｉｄ、ポート、（サービス））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子である。これは、例えば、プロセスＩＤ、または、例えばシステム時間および確率関数に基づいて生成される乱数、または、サービスが現在使用中のＩＰアドレスとポートの組み合わせである。
ＩＰは、サービスのＩＰアドレスである。これは、装置が、いくつかのネットワーク要素またはＩＰアドレスをサポートする場合に必要である。
ポートは、ＴＣＰポートである。これにより、サービスは、ＩＰアドレスを通して利用可能となる。
サービスは、サービスタイプのリストである。例えば、探索要求を受信した後は、登録されているサービスに対応するものだけが転送される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８５】
さらに、登録メッセージとして、ＤＲＥＧ（登録取消）がある。メッセージＤＲＥＧにより、サービスは、ＭＰＣＰ３の自らの登録を取り消すことができ、今後ＭＰＣＰ３からメッセージを受信することはない。
メッセージ形式は、ＤＲＥＧ（Ｉｄ）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８６】
次に、探索メッセージとして、ＳＥＱ（探索要求）がある。メッセージＳＲＥＱにより、ＭＰＣＰ７は、ＭＰＣＰ３におけるキーワードに基づいて、探索要求を起動できる。ＭＰＣＰのＳＲＥＱは、ＥＤＳＲプロトコルの対応するＳＲＥＱに変換され、次に下位に下げられる。
メッセージ形式は、ＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、文字列の１６ビットのハッシュ値であり、要求されたサービスを指定する。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８７】
次に、探索メッセージとして、ＩＳＲＥＱ（入力される探索要求）がある。ＩＳＲＥＱは、ＳＲＥＱに対応するメッセージである。ＭＰＣＰ３は、ＥＤＳＲの詳細なＳＲＥＱオプションを持つＩＳＲＥＱメッセージを、ＭＰＣＰ７に送る。すると、各サービスは、自らがこの探索要求に対して肯定応答するかどうか検証できる。
メッセージ形式は、ＩＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、ＥＤＳＲのＳＲＥＱを送信する前に、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８８】
さらに、探索メッセージとして、ＨＲＥＱ（ハッシュ要求）がある。ＨＲＥＱにより、サービスは、ＥＤＳＲのＨＲＥＱを起動し、データをダウンロードするための代替のソースを探索できる。
メッセージ形式は、ＨＲＥＱ（Ｉｄ、サービス、ファイルサイズ、ハッシュ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。このサービスは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドに対応している。
ファイルサイズは、オクテット単位のデータのサイズである。
ハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００８９】
さらに、探索メッセージとして、ＩＨＲＥＱ（入力されるハッシュ要求）がある。ＭＰＣＰ３は、ＥＤＳＲのＨＲＥＱを受信すると、即座にメッセージＩＨＲＥＱをＭＰＣＰ７に送る。これにより、各サービスは、適宜応答することができる。
メッセージ形式は、ＩＨＲＥＱ（Ｉｄ、サービス、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。これは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドからのコピーである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のデータのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９０】
次に、応答メッセージとして、ＦＲＥＰ（ファイル応答）がある。ＦＲＥＰは、ＩＳＲＥＱまたはＩＨＲＥＱという形式を持つ探索要求を受信した際に、ファイルとして対応するデータが利用可能である場合における、サービスに対する肯定的な応答である。ＭＰＣＰ３は、ＩＰアドレスやＴＣＰポートなどの登録されているサービスのデータの情報に基づいて、ＥＤＳＲのＦＲＥＰを作成できる。
メッセージ形式は、（Ｉｄ、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９１】
さらに、応答メッセージとして、ＩＦＲＥＰ（入力されるファイル応答）がある。ＩＦＲＥＰは、ＦＲＥＰに対応するものである。ＩＦＲＥＰは、ＥＤＳＲのＦＲＥＰオプションの詳細な情報とともに、ＭＰＣＰ３によりＭＰＣＰ７に送られる。この情報に基づいて、サービスは、ＭＭＰ上でデータ転送を起動できる。
メッセージ形式は、ＩＦＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、提供されたサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスを得ることが可能となる。
ファイルハッシュは、全てのファイルに対する、１２８ハッシュビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９２】
さらに、応答メッセージとして、ＰＲＥＱ（プッシュ要求）がある。ＦＲＥＰを受信した後で、モバイルピアツーピアプロトコルＭＰＰは、提供されているピアに対し、与えられたＴＣＰポートを介して、直接接続を確立しようとする。もし不可能であれば、提供側のピアがファイアウォールの背後にある場合と同様に、そして、提供側のピアが、アップロードを許容する場合（ＦＲＥＰ内のＵフラグ）と同様に、ＭＰＣＰ７は、ＭＰＣＰ３にＰＲＥＱメッセージを送り、ＥＤＳＲのＰＲＥＱを起動する。ＰＲＥＱは、提供側のピアに対し、提供されたポートを介してＭＰＰのダウンロードを開始できないため、代わりにファイルをアップロードしてほしい旨を通知する。ＰＲＥＱにより、アップロードするために必要とされる全ての必要なデータが、提供される。
メッセージ形式は、ＰＲＥＱ（Ｉｄ、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、１２８ビットのＭＤ５ハッシュである。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に指定する。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９３】
さらに、応答メッセージとして、ＩＰＲＥＱ（入力されるプッシュ要求）がある。ＩＰＲＥＱは、ＰＲＥＱに対応するものである。これは、アップロードの必要がある、要求されているファイルに関する情報を含む。これは、ＥＤＳＲのＰＲＥＱを受信すると、ＭＰＣＰ３によりＭＰＣＰ７に送られる。これにより、モバイルピアツーピアプロトコルＭＰＰによるアップロードを開始することができる。
メッセージ形式は、ＩＰＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、要求側のサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスをアップロードすることが可能になる。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９４】
さらに、応答メッセージとして、ＤＲＥＰ（説明応答）がある。ＤＲＥＰは、ＥＤＳＲのＤＲＥＰメッセージの送信を要求する。ＭＰＣＰ７からＭＰＣＰ３に送られるが、これは、受信されたＩＳＲＥＱまたはＩＨＲＥＱに対する、肯定応答である。ＭＰＣＰ３は、ＥＤＳＲのＤＲＥＰを作成するためのＩＰアドレスやＴＣＰポートなどの、登録されているサービスに関する必要な情報を提供する。
メッセージ形式は、ＰＲＥＰ（Ｉｄ、プロファイルハッシュ、プロファイル名、プロファイルサイズ）である。
送信元は、ＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前にＭＰＣＰ３に登録するために用いられたものである。
プロファイルハッシュは、プロファイルデータに関する、１２８ビットのＭＤ５ハッシュ値である。
プロファイル名は、プロファイルの名前である。
プロファイルサイズは、オクテット単位のプロファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。
【００９５】
上記に加えて、本発明により提案されているプロトコルスタックが、ＳＤＬでシミュレーションされ、その機能が立証された。特に、ノードの数を５としてシミュレーションを行った。これらの調査およびそれに関連するものと、以前からあるソリューション、特にグヌーテラとを比較すると、本発明によるプロトコルスタックが、アドホックネットワークで用いられてきた従来のピアツーピアプロトコルよりも、性能面で飛躍的に向上していることがわかる。より詳細に述べると、ファイル探索が１回成功する毎のオーバーヘッドは、グヌーテラの場合で４８５０バイトであり、ＭＰＰの場合は１９６６バイトであった。さらに、バックグラウンドのトラフィックは、グヌーテラの場合で２．４３キロビット／秒、ＭＰＰの場合は０．０２９キロビット／秒であった。
【図面の簡単な説明】
【００９６】
【図１】本発明の動機付けとなる、無線ネットワーク上で稼動する、ピアツーピアアプリケーションの例を示す図である。
【図２】本発明による、無線通信ネットワーク上で稼動する、ピアツーピア運用のためのプロトコルスタックを示す図である。
【図３】本発明による、モバイルピアツーピアネットワークにおける、データの探索とダウンロードを示すメッセージ順序表である。
【図４】ネットワーク層ルーティングプロトコルレベルでの機能性を示す概略図である。
【図５】モバイルピアツーピアプロトコルレベルでの機能性を示す概略図である。
【図６】本発明による、サービスリソースの探索の基礎となるディレクトリ構造を示す図である。
【図７】モバイルピア制御プロトコルレベルにおける機能性を示す概略図である。
【特許請求の範囲】
【請求項１】
モバイルピアツーピア層プロトコルの上で稼動するサービスを介して起動されるサービス要求に関連した探索関連データを受信するステップと、
ネットワーク層ルーティングプロトコルに従って、前記探索関連データを照会メッセージに変換するステップと
を含み、前記照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準を含むものである、
無線ネットワークにおいて通信するためのモバイルピアツーピア層プロトコルをサポートするようにネットワーク層ルーティングプロトコルを用いる方法。
【請求項２】
前記照会メッセージのうちＳＲＥＱとＨＲＥＱとが、データの探索に関連しているものである、請求項１に記載の方法。
【請求項３】
前記照会メッセージのうちＨＲＥＱが、探索データのファイルサイズと、探索データの特徴的性質とを指定するものである、請求項２に記載の方法。
【請求項４】
前記サービス要求に応答する応答ノードを特定するために、前記照会メッセージを転送するステップを含むことを特徴とする請求項１から３のいずれか一項に記載の方法。
【請求項５】
照会メッセージが、前記無線ネットワークのモバイルノード間で転送されるものである、請求項４に記載の方法。
【請求項６】
無線ネットワークインフラストラクチャのノードにおいて前記照会メッセージを受信するステップと、
前記照会メッセージを、前記ノードに登録されている少なくとも１つのピアツーピアアプリケーションに対し、前記ネットワーク層ルーティングプロトコルに従って転送するステップと、
前記ピアツーピアアプリケーションから、探索基準を満たしたかどうかの評価を受信するステップと、
少なくとも１つの探索基準が満たされた場合に、探索が起動された前記無線ネットワークにある送信ノードに対して探索応答を送るステップと
をさらに含むことを特徴とする請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記送信ノードにおいて、前記探索応答を受信するステップをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記探索応答のうちＦＲＥＰが、前記送信ノードと、前記探索応答を送信する対応ノードとを接続する前記無線ネットワーク内の経路情報を含むものである、請求項６または７に記載の方法。
【請求項９】
前記探索応答のうちＰＲＥＱが、前記送信ノードから前記応答ノードへデータをアップロードするために送信ノードと、前記探索応答を送信する対応ノードとを接続する前記無線ネットワーク内の経路情報を含むものである、請求項６または７に記載の方法。
【請求項１０】
前記探索応答のうちＤＲＥＰが、探索されたサービスに関連するプロファイル情報を含むものである、請求項６または７に記載の方法。
【請求項１１】
前記探索応答をピアツーピア層プロトコルに転送するステップをさらに含むことを特徴とする請求項６から１０のいずれか一項に記載の方法。
【請求項１２】
前記探索応答を複数受信したときに、さまざまな探索結果を評価するステップをさらに含むことを特徴とする請求項６から１１のいずれか一項に記載の方法。
【請求項１３】
前記評価は、少なくとも１つの所定の費用関数に従って行われるものである、請求項１２に記載の方法。
【請求項１４】
前記所定の費用関数が、前記送信ノードと前記応答ノードとを接続する前記無線ネットワークの経路上の少なくとも１つのノードの特性を評価するものである、請求項１３に記載の方法。
【請求項１５】
前記特性が、前記経路上のノードの数、またはノードの送信出力、またはノードの移動速度、またはノードの転送レートであることを特徴とする、請求項１４に記載の方法。
【請求項１６】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスを、ネットワーク層ルーティングレベルに登録するステップをさらに含むことを特徴とする請求項１から１５のいずれか一項に記載の方法。
【請求項１７】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスが登録されたことを、前記ネットワーク層ルーティングプロトコルレベルに通知するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記無線ネットワークが、アドホック無線ネットワークであることを特徴とする、請求項１から１７のいずれか一項に記載の方法。
【請求項１９】
ノードアドレス情報の範囲を越えて拡張する探索基準を含むサービス要求を受信するステップと、
無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求をネットワーク層ルーティングプロトコルと交換するステップと
を含む、モバイルピアツーピアサービスをサポートするようにモバイルピアツーピアネットワークプロトコルを使用し、前記モバイルピアツーピアネットワークプロトコルが、無線ネットワークにあるノードをルーティングするために提供されているネットワーク層ルーティングプロトコルの上位で動作するものである方法。
【請求項２０】
前記サービス要求を、前記モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービスから受信することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記サービス要求を、前記ネットワーク層ルーティングプロトコルから受信することを特徴とする請求項１９に記載の方法。
【請求項２２】
モバイルピアツーピアネットワークプロトコルレベルで、前記サービス要求に対する探索応答を受信するステップをさらに含むことを特徴とする請求項１９から２１のいずれか一項に記載の方法。
【請求項２３】
前記探索応答が、前記ネットワーク層ルーティングプロトコルから前記モバイルピアツーピアネットワークプロトコルに転送されるものである、請求項２２に記載の方法。
【請求項２４】
前記探索応答が、前記無線ネットワークの経路の情報を含み、前記経路が、探索要求を起動する前記モバイルピアツーピアサービスが稼働している送信ノードと、前記探索応答を送信する応答ノードとを接続するものである、請求項２２または２３に記載の方法。
【請求項２５】
モバイルピアツーピアネットワークプロトコルレベルで、前記探索要求を評価するステップをさらに含むことを特徴とする請求項１９から２４のいずれか一項に記載の方法。
【請求項２６】
前記評価が、モバイルピアツーピアサービスをさまざまなタイプに分類することに基づくものである、請求項２５に記載の方法。
【請求項２７】
モバイルピアツーピアサービスをさまざまなタイプに分類するステップが、ハッシュ値を用いて行われるものである、請求項２６に記載の方法。
【請求項２８】
サービスプロファイルに基づいて、モバイルピアツーピアサービスを説明するステップをさらに含むことを特徴とする請求項２５から２７のいずれか一項に記載の方法。
【請求項２９】
サービスプロファイルが、サービスの特徴と、サービス提供者とに関連する情報を含むものである、請求項２８に記載の方法。
【請求項３０】
探索応答を生成するステップと、モバイルピアツーピアネットワークプロトコルレベルにおける前記探索要求の前記評価が探索基準を満たしたことを示す場合にサービス応答を転送するステップとをさらに含むことを特徴とする請求項２５から２９のいずれか一項に記載の方法。
【請求項３１】
接続が中断した後に、接続を回復するステップを含むことを特徴とする請求項１９から３０のいずれか一項に記載の方法。
【請求項３２】
前記モバイルピアツーピアネットワークプロトコルに基づいて、前記送信ノードと前記応答ノードとの間で前記サービス要求に関連しているデータを直接交換するステップをさらに含むことを特徴とする請求項１９から３１のいずれか一項に記載の方法。
【請求項３３】
前記データを直接交換するステップが、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードを介して行われるものである、請求項３２に記載の方法。
【請求項３４】
前記データを直接交換するステップが、ＨＴＴＰデータのダウンロードおよびアップロード、または、ＨＴＴＰデータのダウンロードまたはアップロードを介して行われるものである、請求項３３に記載の方法。
【請求項３５】
モバイルピアツーピアサービスを、前記ネットワーク層ルーティングプロトコルに登録するステップをさらに含むことを特徴とする請求項１９から３４のいずれか一項に記載の方法。
【請求項３６】
モバイルピアツーピアサービスの前記ネットワーク層ルーティングプロトコルへの登録に肯定応答するステップをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項３７】
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間で全ての入出力メッセージを、ファイル交換を除いて、交換するステップ
を含む、モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間でクロス層通信チャネルプロトコル（ＭＰＣＰ）を使用する方法。
【請求項３８】
前記クロス層通信チャネルプロトコルの使用が、前記モバイルピアツーピアアプリケーションのレベルで動作する第１の部分（ＭＰＣＰ７）と、前記ネットワーク層ルーティングプロトコルのレベルで動作する第２の部分（ＭＰＣＰ３）とに分割できるものである、請求項３７に記載の方法。
【請求項３９】
メッセージが、前記クロス層通信チャネルプロトコルの前記第１の部分と、前記第２の部分との間で交換されるものである、請求項３８に記載の方法。
【請求項４０】
メッセージが、少なくともサービス確認、またはサービス登録、またはデータ探索、またはサービス要求、またはサービス応答に関連しているものである、請求項３７から３９のいずれか一項に記載の方法。
【請求項４１】
モバイルピアツーピア層プロトコルの上で稼動するサービスを介して起動されるサービス要求に関連する探索関連データを受信することができる第１のインターフェースユニットと、
ネットワーク層ルーティングプロトコルに従って、前記探索関連データを照会メッセージに変換するができる変換ユニットと
を含み、前記照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準を含むものである、
無線ネットワーク内通信のための、モバイルピアツーピア層プロトコルをサポートするように動作するネットワーク層ルーティングプロトコルを用いる装置。
【請求項４２】
前記変換ユニットが、前記探索関連データをデータの探索に関連した照会メッセージ（ＳＲＥＱ、ＨＲＥＱ）に変換することができるものである、請求項４１に記載の装置。
【請求項４３】
前記変換ユニットが、前記探索関連データをファイルサイズと、探索されたデータの特徴的性質に関連した情報とを指定する照会メッセージ（ＨＲＥＱ）に変換できるものである、請求項４２に記載の装置。
【請求項４４】
前記サービス要求に応答する応答ノードを特定するために、前記照会メッセージを転送することができる第２のインターフェースユニットをさらに含むことを特徴とする請求項４１から４３のいずれか一項に記載の装置。
【請求項４５】
前記第２のインターフェースユニットが、前記照会メッセージを前記無線ネットワーク内のモバイルノード間で転送するものである、請求項４４に記載の装置。
【請求項４６】
前記第２のインターフェースユニットが、無線ネットワークインフラストラクチャのノードと前記照会メッセージを交換できることと、
前記第１のインターフェースユニットが、前記照会メッセージを前記ノードに登録されている少なくとも１つのピアツーピアアプリケーションに対し、前記ネットワーク層ルーティングプロトコルに従って転送することと、
前記第１のインターフェースユニットが、探索基準を満たしているかどうかの評価を、前記ピアツーピアアプリケーションから受信できることと、
前記第２のインターフェースユニットが、探索基準を満たしたときに、探索が起動された前記無線ネットワーク内の送信ノードに対して探索応答を送信できることと
を特徴とする、請求項４１から４５のいずれか一項に記載の装置。
【請求項４７】
前記第２のインターフェースユニットが、前記探索応答を受信できるものである、請求項４６に記載の装置。
【請求項４８】
前記探索応答のうちＦＲＥＰが、前記送信ノードと前記探索応答を送る応答ノードとを接続する前記無線ネットワーク内の経路情報を含み、前記経路情報が、探索の後に続くデータ交換中に、前記第２のインターフェースユニットによって使用されるものである、請求項４６または４７に記載の装置。
【請求項４９】
前記探索応答のうちＰＲＥＱが、前記第２のインターフェースユニットを介して前記送信ノードから前記応答ノードへデータをアップロードするために、前記無線ネットワーク内の送信ノードと、前記探索応答を送る応答ノードとを接続する経路情報を含むものである、請求項４６または４７に記載の装置。
【請求項５０】
前記探索応答のうちＤＲＥＰが、前記第２のインターフェースユニットと前記第１のインターフェースユニットとを介して前記モバイルピアツーピア層プロトコルの上で稼動するサービスに転送された探索済みのサービスに関連するプロファイル情報を含むものである、請求項４５または４６に記載の装置。
【請求項５１】
前記第１のインターフェースユニットが、前記探索応答をピアツーピア層プロトコルに転送できるものである、請求項４６から５０のいずれか一項に記載の装置。
【請求項５２】
前記探索応答を複数受信したときに、さまざまな探索結果を評価できる評価ユニットをさらに含むことを特徴とする請求項４６から５１のいずれか一項に記載の装置。
【請求項５３】
前記評価ユニットが、少なくとも１つの所定の費用関数を処理できるものである、請求項５２に記載の装置。
【請求項５４】
前記評価ユニットが、前記送信ノードと前記応答ノードとを接続する前記無線ネットワークの経路上にある少なくとも１つのノードの特徴を評価できるものである、請求項５３に記載の装置。
【請求項５５】
前記特徴が、前記経路上にあるノードの数、またはノードの送信出力、またはノードの移動速度、またはノードの転送レートであることを特徴とする、請求項５４に記載の装置。
【請求項５６】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスをネットワーク層ルーティングレベルに登録することができる登録ユニットを含むことを特徴とする請求項４１から５５のいずれか一項に記載の装置。
【請求項５７】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスがネットワーク層ルーティングプロトコルレベルに登録されたことを、前記登録ユニットが確認することができるものである、請求項５６に記載の装置。
【請求項５８】
アドホック無線ネットワーク内で動作できることを特徴とする請求項４１から５７のいずれか一項に記載の装置。
【請求項５９】
ノードアドレス情報の範囲を越えて拡張する探索基準を含むサービス要求を受信することができる第１のインターフェースユニットと、
無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求をネットワーク層ルーティングプロトコルと交換することができる第２のインターフェースユニットと
を含み、モバイルピアツーピアネットワークプロトコルが、無線ネットワークのノードをルーティングするために提供されているネットワーク層ルーティングプロトコルの上位で動作するものである、
モバイルピアツーピアサービスをサポートするようにモバイルピアツーピアネットワークプロトコルを使用する装置。
【請求項６０】
前記第１のインターフェースユニットが、前記サービス要求を、前記モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービスから受信することを特徴とする、請求項５９に記載の装置。
【請求項６１】
前記第２のインターフェースユニットが、前記サービス要求を前記ネットワーク層ルーティングプロトコルから受信できるものである、請求項５９に記載の装置。
【請求項６２】
前記第２のインターフェースユニットが、モバイルピアツーピアネットワークプロトコルレベルにおいて、前記サービス要求に対する探索応答を受信することができるものである、請求項５９から６１のいずれか一項に記載の装置。
【請求項６３】
前記第１のインターフェースユニットと、前記第２のインターフェースユニットとが、前記ネットワーク層ルーティングプロトコルから前記モバイルピアツーピアネットワークプロトコルに前記探索応答を転送できるものである、請求項６２に記載の装置。
【請求項６４】
前記探索応答が、探索要求を起動したモバイルピアツーピアサービスが稼働中の送信ノードと、前記探索応答を送信する応答ノードとを接続する前記無線ネットワーク内の経路に関する情報を含むものである、請求項６２または６３に記載の装置。
【請求項６５】
モバイルピアツーピアネットワークプロトコルレベルにおいて、前記探索要求を評価することができる評価ユニットを含むことを特徴とする請求項５９から６４のいずれか一項に記載の装置。
【請求項６６】
評価の基礎として、モバイルピアツーピアサービスをさまざまなタイプに分類したものを記憶するメモリユニットを含むことを特徴とする請求項６５に記載の装置。
【請求項６７】
前記評価ユニットが、モバイルピアツーピアサービスを、ハッシュ値を用いてさまざまなタイプに分類できるものである、請求項６６に記載の装置。
【請求項６８】
前記メモリユニットが、モバイルピアツーピアサービスに関連するサービスプロファイルを記憶できるものである、請求項６５から６７のいずれか一項に記載の装置。
【請求項６９】
サービスプロファイルが、サービスの特徴と、サービス提供者とに関連する情報を含むものである、請求項６８に記載の装置。
【請求項７０】
探索応答を生成することができる探索応答生成ユニットを含み、
モバイルピアツーピアネットワークプロトコルレベルにおいて、前記探索要求の評価が探索基準が満たされたことを示す場合に、前記第２のインターフェースユニットが、サービス応答を転送することができるものである、請求項６５から６９のいずれか一項に記載の装置。
【請求項７１】
接続が中断した後に、接続を回復することができる接続回復ユニットを含むことを特徴とする請求項５９から７０のいずれか一項に記載の装置。
【請求項７２】
前記モバイルピアツーピアネットワークプロトコルに基づいて、前記送信ノードと前記応答ノードとの間でサービス要求に関連したデータを直接交換することができるデータ交換ユニットを含むことを特徴とする請求項５９から７１のいずれか一項に記載の装置。
【請求項７３】
前記データ交換ユニットが、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードを介して直接的なデータ交換を行うことができるものである、請求項７２に記載の装置。
【請求項７４】
前記データ交換ユニットが、ＨＴＴＰデータのダウンロードおよびアップロード、または、ＨＴＴＰデータのダウンロードまたはアップロードを介して直接的なデータ交換を行うことができるものである、請求項７３に記載の装置。
【請求項７５】
モバイルピアツーピアサービスを前記ネットワーク層ルーティングプロトコルに登録することができる登録ユニットを含むことを特徴とする請求項５９から７４のいずれか一項に記載の装置。
【請求項７６】
前記登録ユニットが、モバイルピアツーピアサービスを前記ネットワーク層ルーティングプロトコルに登録したことに対する肯定応答を受信することができるものである、請求項７５に記載の装置。
【請求項７７】
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間で全ての入出力メッセージを、ファイル交換を除いて、交換することができる交換ユニットを含むものである、
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間でクロス層通信チャネルプロトコル（ＭＰＣＰ）を使用する装置。
【請求項７８】
交換ユニットが、モバイルピアツーピアアプリケーションレベルで動作する上位層ユニット（ＭＰＣＰ７）と、ネットワーク層ルーティングプロトコルレベルで動作する下位層ユニット（ＭＰＣＰ３）とを含むものである、請求項７７に記載の装置。
【請求項７９】
メッセージが、少なくとも、サービス確認、またはサービス登録、またはデータ探索、またはサービス要求、またはサービス応答に関連しているものである、請求項７７または７８に記載の装置。
【請求項８０】
プログラムがモバイル通信装置のプロセッサ上で実行されるときに、請求項１から１８、または請求項１９から３６、または請求項３７から４０のいずれか一つを実行するソフトウェアコード部分を含むものである、
モバイル通信装置の内部メモリに直接的に読み込み可能なコンピュータプログラム製品。
【請求項１】
モバイルピアツーピア層プロトコルの上で稼動するサービスを介して起動されるサービス要求に関連した探索関連データを受信するステップと、
ネットワーク層ルーティングプロトコルに従って、前記探索関連データを照会メッセージに変換するステップと
を含み、前記照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準を含むものである、
無線ネットワークにおいて通信するためのモバイルピアツーピア層プロトコルをサポートするようにネットワーク層ルーティングプロトコルを用いる方法。
【請求項２】
前記照会メッセージのうちＳＲＥＱとＨＲＥＱとが、データの探索に関連しているものである、請求項１に記載の方法。
【請求項３】
前記照会メッセージのうちＨＲＥＱが、探索データのファイルサイズと、探索データの特徴的性質とを指定するものである、請求項２に記載の方法。
【請求項４】
前記サービス要求に応答する応答ノードを特定するために、前記照会メッセージを転送するステップを含むことを特徴とする請求項１から３のいずれか一項に記載の方法。
【請求項５】
照会メッセージが、前記無線ネットワークのモバイルノード間で転送されるものである、請求項４に記載の方法。
【請求項６】
無線ネットワークインフラストラクチャのノードにおいて前記照会メッセージを受信するステップと、
前記照会メッセージを、前記ノードに登録されている少なくとも１つのピアツーピアアプリケーションに対し、前記ネットワーク層ルーティングプロトコルに従って転送するステップと、
前記ピアツーピアアプリケーションから、探索基準を満たしたかどうかの評価を受信するステップと、
少なくとも１つの探索基準が満たされた場合に、探索が起動された前記無線ネットワークにある送信ノードに対して探索応答を送るステップと
をさらに含むことを特徴とする請求項１から５のいずれか一項に記載の方法。
【請求項７】
前記送信ノードにおいて、前記探索応答を受信するステップをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記探索応答のうちＦＲＥＰが、前記送信ノードと、前記探索応答を送信する対応ノードとを接続する前記無線ネットワーク内の経路情報を含むものである、請求項６または７に記載の方法。
【請求項９】
前記探索応答のうちＰＲＥＱが、前記送信ノードから前記応答ノードへデータをアップロードするために送信ノードと、前記探索応答を送信する対応ノードとを接続する前記無線ネットワーク内の経路情報を含むものである、請求項６または７に記載の方法。
【請求項１０】
前記探索応答のうちＤＲＥＰが、探索されたサービスに関連するプロファイル情報を含むものである、請求項６または７に記載の方法。
【請求項１１】
前記探索応答をピアツーピア層プロトコルに転送するステップをさらに含むことを特徴とする請求項６から１０のいずれか一項に記載の方法。
【請求項１２】
前記探索応答を複数受信したときに、さまざまな探索結果を評価するステップをさらに含むことを特徴とする請求項６から１１のいずれか一項に記載の方法。
【請求項１３】
前記評価は、少なくとも１つの所定の費用関数に従って行われるものである、請求項１２に記載の方法。
【請求項１４】
前記所定の費用関数が、前記送信ノードと前記応答ノードとを接続する前記無線ネットワークの経路上の少なくとも１つのノードの特性を評価するものである、請求項１３に記載の方法。
【請求項１５】
前記特性が、前記経路上のノードの数、またはノードの送信出力、またはノードの移動速度、またはノードの転送レートであることを特徴とする、請求項１４に記載の方法。
【請求項１６】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスを、ネットワーク層ルーティングレベルに登録するステップをさらに含むことを特徴とする請求項１から１５のいずれか一項に記載の方法。
【請求項１７】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスが登録されたことを、前記ネットワーク層ルーティングプロトコルレベルに通知するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記無線ネットワークが、アドホック無線ネットワークであることを特徴とする、請求項１から１７のいずれか一項に記載の方法。
【請求項１９】
ノードアドレス情報の範囲を越えて拡張する探索基準を含むサービス要求を受信するステップと、
無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求をネットワーク層ルーティングプロトコルと交換するステップと
を含む、モバイルピアツーピアサービスをサポートするようにモバイルピアツーピアネットワークプロトコルを使用し、前記モバイルピアツーピアネットワークプロトコルが、無線ネットワークにあるノードをルーティングするために提供されているネットワーク層ルーティングプロトコルの上位で動作するものである方法。
【請求項２０】
前記サービス要求を、前記モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービスから受信することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記サービス要求を、前記ネットワーク層ルーティングプロトコルから受信することを特徴とする請求項１９に記載の方法。
【請求項２２】
モバイルピアツーピアネットワークプロトコルレベルで、前記サービス要求に対する探索応答を受信するステップをさらに含むことを特徴とする請求項１９から２１のいずれか一項に記載の方法。
【請求項２３】
前記探索応答が、前記ネットワーク層ルーティングプロトコルから前記モバイルピアツーピアネットワークプロトコルに転送されるものである、請求項２２に記載の方法。
【請求項２４】
前記探索応答が、前記無線ネットワークの経路の情報を含み、前記経路が、探索要求を起動する前記モバイルピアツーピアサービスが稼働している送信ノードと、前記探索応答を送信する応答ノードとを接続するものである、請求項２２または２３に記載の方法。
【請求項２５】
モバイルピアツーピアネットワークプロトコルレベルで、前記探索要求を評価するステップをさらに含むことを特徴とする請求項１９から２４のいずれか一項に記載の方法。
【請求項２６】
前記評価が、モバイルピアツーピアサービスをさまざまなタイプに分類することに基づくものである、請求項２５に記載の方法。
【請求項２７】
モバイルピアツーピアサービスをさまざまなタイプに分類するステップが、ハッシュ値を用いて行われるものである、請求項２６に記載の方法。
【請求項２８】
サービスプロファイルに基づいて、モバイルピアツーピアサービスを説明するステップをさらに含むことを特徴とする請求項２５から２７のいずれか一項に記載の方法。
【請求項２９】
サービスプロファイルが、サービスの特徴と、サービス提供者とに関連する情報を含むものである、請求項２８に記載の方法。
【請求項３０】
探索応答を生成するステップと、モバイルピアツーピアネットワークプロトコルレベルにおける前記探索要求の前記評価が探索基準を満たしたことを示す場合にサービス応答を転送するステップとをさらに含むことを特徴とする請求項２５から２９のいずれか一項に記載の方法。
【請求項３１】
接続が中断した後に、接続を回復するステップを含むことを特徴とする請求項１９から３０のいずれか一項に記載の方法。
【請求項３２】
前記モバイルピアツーピアネットワークプロトコルに基づいて、前記送信ノードと前記応答ノードとの間で前記サービス要求に関連しているデータを直接交換するステップをさらに含むことを特徴とする請求項１９から３１のいずれか一項に記載の方法。
【請求項３３】
前記データを直接交換するステップが、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードを介して行われるものである、請求項３２に記載の方法。
【請求項３４】
前記データを直接交換するステップが、ＨＴＴＰデータのダウンロードおよびアップロード、または、ＨＴＴＰデータのダウンロードまたはアップロードを介して行われるものである、請求項３３に記載の方法。
【請求項３５】
モバイルピアツーピアサービスを、前記ネットワーク層ルーティングプロトコルに登録するステップをさらに含むことを特徴とする請求項１９から３４のいずれか一項に記載の方法。
【請求項３６】
モバイルピアツーピアサービスの前記ネットワーク層ルーティングプロトコルへの登録に肯定応答するステップをさらに含むことを特徴とする請求項３５に記載の方法。
【請求項３７】
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間で全ての入出力メッセージを、ファイル交換を除いて、交換するステップ
を含む、モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間でクロス層通信チャネルプロトコル（ＭＰＣＰ）を使用する方法。
【請求項３８】
前記クロス層通信チャネルプロトコルの使用が、前記モバイルピアツーピアアプリケーションのレベルで動作する第１の部分（ＭＰＣＰ７）と、前記ネットワーク層ルーティングプロトコルのレベルで動作する第２の部分（ＭＰＣＰ３）とに分割できるものである、請求項３７に記載の方法。
【請求項３９】
メッセージが、前記クロス層通信チャネルプロトコルの前記第１の部分と、前記第２の部分との間で交換されるものである、請求項３８に記載の方法。
【請求項４０】
メッセージが、少なくともサービス確認、またはサービス登録、またはデータ探索、またはサービス要求、またはサービス応答に関連しているものである、請求項３７から３９のいずれか一項に記載の方法。
【請求項４１】
モバイルピアツーピア層プロトコルの上で稼動するサービスを介して起動されるサービス要求に関連する探索関連データを受信することができる第１のインターフェースユニットと、
ネットワーク層ルーティングプロトコルに従って、前記探索関連データを照会メッセージに変換するができる変換ユニットと
を含み、前記照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準を含むものである、
無線ネットワーク内通信のための、モバイルピアツーピア層プロトコルをサポートするように動作するネットワーク層ルーティングプロトコルを用いる装置。
【請求項４２】
前記変換ユニットが、前記探索関連データをデータの探索に関連した照会メッセージ（ＳＲＥＱ、ＨＲＥＱ）に変換することができるものである、請求項４１に記載の装置。
【請求項４３】
前記変換ユニットが、前記探索関連データをファイルサイズと、探索されたデータの特徴的性質に関連した情報とを指定する照会メッセージ（ＨＲＥＱ）に変換できるものである、請求項４２に記載の装置。
【請求項４４】
前記サービス要求に応答する応答ノードを特定するために、前記照会メッセージを転送することができる第２のインターフェースユニットをさらに含むことを特徴とする請求項４１から４３のいずれか一項に記載の装置。
【請求項４５】
前記第２のインターフェースユニットが、前記照会メッセージを前記無線ネットワーク内のモバイルノード間で転送するものである、請求項４４に記載の装置。
【請求項４６】
前記第２のインターフェースユニットが、無線ネットワークインフラストラクチャのノードと前記照会メッセージを交換できることと、
前記第１のインターフェースユニットが、前記照会メッセージを前記ノードに登録されている少なくとも１つのピアツーピアアプリケーションに対し、前記ネットワーク層ルーティングプロトコルに従って転送することと、
前記第１のインターフェースユニットが、探索基準を満たしているかどうかの評価を、前記ピアツーピアアプリケーションから受信できることと、
前記第２のインターフェースユニットが、探索基準を満たしたときに、探索が起動された前記無線ネットワーク内の送信ノードに対して探索応答を送信できることと
を特徴とする、請求項４１から４５のいずれか一項に記載の装置。
【請求項４７】
前記第２のインターフェースユニットが、前記探索応答を受信できるものである、請求項４６に記載の装置。
【請求項４８】
前記探索応答のうちＦＲＥＰが、前記送信ノードと前記探索応答を送る応答ノードとを接続する前記無線ネットワーク内の経路情報を含み、前記経路情報が、探索の後に続くデータ交換中に、前記第２のインターフェースユニットによって使用されるものである、請求項４６または４７に記載の装置。
【請求項４９】
前記探索応答のうちＰＲＥＱが、前記第２のインターフェースユニットを介して前記送信ノードから前記応答ノードへデータをアップロードするために、前記無線ネットワーク内の送信ノードと、前記探索応答を送る応答ノードとを接続する経路情報を含むものである、請求項４６または４７に記載の装置。
【請求項５０】
前記探索応答のうちＤＲＥＰが、前記第２のインターフェースユニットと前記第１のインターフェースユニットとを介して前記モバイルピアツーピア層プロトコルの上で稼動するサービスに転送された探索済みのサービスに関連するプロファイル情報を含むものである、請求項４５または４６に記載の装置。
【請求項５１】
前記第１のインターフェースユニットが、前記探索応答をピアツーピア層プロトコルに転送できるものである、請求項４６から５０のいずれか一項に記載の装置。
【請求項５２】
前記探索応答を複数受信したときに、さまざまな探索結果を評価できる評価ユニットをさらに含むことを特徴とする請求項４６から５１のいずれか一項に記載の装置。
【請求項５３】
前記評価ユニットが、少なくとも１つの所定の費用関数を処理できるものである、請求項５２に記載の装置。
【請求項５４】
前記評価ユニットが、前記送信ノードと前記応答ノードとを接続する前記無線ネットワークの経路上にある少なくとも１つのノードの特徴を評価できるものである、請求項５３に記載の装置。
【請求項５５】
前記特徴が、前記経路上にあるノードの数、またはノードの送信出力、またはノードの移動速度、またはノードの転送レートであることを特徴とする、請求項５４に記載の装置。
【請求項５６】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスをネットワーク層ルーティングレベルに登録することができる登録ユニットを含むことを特徴とする請求項４１から５５のいずれか一項に記載の装置。
【請求項５７】
前記モバイルピアツーピア層プロトコルの上で稼働中のサービスがネットワーク層ルーティングプロトコルレベルに登録されたことを、前記登録ユニットが確認することができるものである、請求項５６に記載の装置。
【請求項５８】
アドホック無線ネットワーク内で動作できることを特徴とする請求項４１から５７のいずれか一項に記載の装置。
【請求項５９】
ノードアドレス情報の範囲を越えて拡張する探索基準を含むサービス要求を受信することができる第１のインターフェースユニットと、
無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求をネットワーク層ルーティングプロトコルと交換することができる第２のインターフェースユニットと
を含み、モバイルピアツーピアネットワークプロトコルが、無線ネットワークのノードをルーティングするために提供されているネットワーク層ルーティングプロトコルの上位で動作するものである、
モバイルピアツーピアサービスをサポートするようにモバイルピアツーピアネットワークプロトコルを使用する装置。
【請求項６０】
前記第１のインターフェースユニットが、前記サービス要求を、前記モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービスから受信することを特徴とする、請求項５９に記載の装置。
【請求項６１】
前記第２のインターフェースユニットが、前記サービス要求を前記ネットワーク層ルーティングプロトコルから受信できるものである、請求項５９に記載の装置。
【請求項６２】
前記第２のインターフェースユニットが、モバイルピアツーピアネットワークプロトコルレベルにおいて、前記サービス要求に対する探索応答を受信することができるものである、請求項５９から６１のいずれか一項に記載の装置。
【請求項６３】
前記第１のインターフェースユニットと、前記第２のインターフェースユニットとが、前記ネットワーク層ルーティングプロトコルから前記モバイルピアツーピアネットワークプロトコルに前記探索応答を転送できるものである、請求項６２に記載の装置。
【請求項６４】
前記探索応答が、探索要求を起動したモバイルピアツーピアサービスが稼働中の送信ノードと、前記探索応答を送信する応答ノードとを接続する前記無線ネットワーク内の経路に関する情報を含むものである、請求項６２または６３に記載の装置。
【請求項６５】
モバイルピアツーピアネットワークプロトコルレベルにおいて、前記探索要求を評価することができる評価ユニットを含むことを特徴とする請求項５９から６４のいずれか一項に記載の装置。
【請求項６６】
評価の基礎として、モバイルピアツーピアサービスをさまざまなタイプに分類したものを記憶するメモリユニットを含むことを特徴とする請求項６５に記載の装置。
【請求項６７】
前記評価ユニットが、モバイルピアツーピアサービスを、ハッシュ値を用いてさまざまなタイプに分類できるものである、請求項６６に記載の装置。
【請求項６８】
前記メモリユニットが、モバイルピアツーピアサービスに関連するサービスプロファイルを記憶できるものである、請求項６５から６７のいずれか一項に記載の装置。
【請求項６９】
サービスプロファイルが、サービスの特徴と、サービス提供者とに関連する情報を含むものである、請求項６８に記載の装置。
【請求項７０】
探索応答を生成することができる探索応答生成ユニットを含み、
モバイルピアツーピアネットワークプロトコルレベルにおいて、前記探索要求の評価が探索基準が満たされたことを示す場合に、前記第２のインターフェースユニットが、サービス応答を転送することができるものである、請求項６５から６９のいずれか一項に記載の装置。
【請求項７１】
接続が中断した後に、接続を回復することができる接続回復ユニットを含むことを特徴とする請求項５９から７０のいずれか一項に記載の装置。
【請求項７２】
前記モバイルピアツーピアネットワークプロトコルに基づいて、前記送信ノードと前記応答ノードとの間でサービス要求に関連したデータを直接交換することができるデータ交換ユニットを含むことを特徴とする請求項５９から７１のいずれか一項に記載の装置。
【請求項７３】
前記データ交換ユニットが、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードを介して直接的なデータ交換を行うことができるものである、請求項７２に記載の装置。
【請求項７４】
前記データ交換ユニットが、ＨＴＴＰデータのダウンロードおよびアップロード、または、ＨＴＴＰデータのダウンロードまたはアップロードを介して直接的なデータ交換を行うことができるものである、請求項７３に記載の装置。
【請求項７５】
モバイルピアツーピアサービスを前記ネットワーク層ルーティングプロトコルに登録することができる登録ユニットを含むことを特徴とする請求項５９から７４のいずれか一項に記載の装置。
【請求項７６】
前記登録ユニットが、モバイルピアツーピアサービスを前記ネットワーク層ルーティングプロトコルに登録したことに対する肯定応答を受信することができるものである、請求項７５に記載の装置。
【請求項７７】
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間で全ての入出力メッセージを、ファイル交換を除いて、交換することができる交換ユニットを含むものである、
モバイルピアツーピアアプリケーションと、ネットワーク層ルーティングプロトコルとの間でクロス層通信チャネルプロトコル（ＭＰＣＰ）を使用する装置。
【請求項７８】
交換ユニットが、モバイルピアツーピアアプリケーションレベルで動作する上位層ユニット（ＭＰＣＰ７）と、ネットワーク層ルーティングプロトコルレベルで動作する下位層ユニット（ＭＰＣＰ３）とを含むものである、請求項７７に記載の装置。
【請求項７９】
メッセージが、少なくとも、サービス確認、またはサービス登録、またはデータ探索、またはサービス要求、またはサービス応答に関連しているものである、請求項７７または７８に記載の装置。
【請求項８０】
プログラムがモバイル通信装置のプロセッサ上で実行されるときに、請求項１から１８、または請求項１９から３６、または請求項３７から４０のいずれか一つを実行するソフトウェアコード部分を含むものである、
モバイル通信装置の内部メモリに直接的に読み込み可能なコンピュータプログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００７−５２４２５８（Ｐ２００７−５２４２５８Ａ）
【公表日】平成１９年８月２３日（２００７．８．２３）
【国際特許分類】
【出願番号】特願２００５−５０９８１１（Ｐ２００５−５０９８１１）
【出願日】平成１５年１０月１６日（２００３．１０．１６）
【国際出願番号】ＰＣＴ／ＥＰ２００３／０１１４７２
【国際公開番号】ＷＯ２００５／０４１５３４
【国際公開日】平成１７年５月６日（２００５．５．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公表日】平成１９年８月２３日（２００７．８．２３）
【国際特許分類】
【出願日】平成１５年１０月１６日（２００３．１０．１６）
【国際出願番号】ＰＣＴ／ＥＰ２００３／０１１４７２
【国際公開番号】ＷＯ２００５／０４１５３４
【国際公開日】平成１７年５月６日（２００５．５．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]