JP4607764B2 - モバイルピアツーピアネットワーク構築 - Google Patents

Description

本発明は、モバイル通信環境におけるモバイルピアツーピアネットワーク構築のためのプロトコルスタックに関し、特に、アプリケーション層に新たなサービスとオプションとを導入し、性能を向上させるための、モバイル無線ネットワークにおけるピアツーピアオーバーレイネットワーク構築をサポートするプロトコルスタックに関する。

米国特許第２００３／０１２５０６３号に、端末向けのモバイルネットワークにおけるピアツーピア通信が記載されている。無線ネットワークを介して、端末から要求を受信すると、モバイルエージェントレポジトリ（ｍｏｂｉｌｅ ａｇｅｎｔ ｒｅｐｏｓｉｔｏｒｙ）の一つまたは複数のレコードが、その要求に基づいて更新され、その結果、モバイルエージェントレポジトリが、共有スペースにある内容をその端末にミラーリングする。その後、無線ネットワークを介して、端末に応答を送信する。
一般的に、ピアツーピアアプリケーションは、最適化アルゴリズムを有するため、ＴＣＰや仮想的に安定した通信などのネットワーク層プロトコルに依存する一方、オーバーレイネットワーク内で情報を検出することができる。それにもかかわらず、無線通信ネットワークにおいて、特にアドホック無線通信ネットワークにおいては、あらゆるモバイルノードが稼動するため、接続の中断がよくある。

データパケット転送中の２つの近接したモバイルノードが、お互いの近傍から離れる場合は常に、両モバイルノード間の接続は中断する。すると、ネットワーク層プロトコルの上位にあるピアツーピアアプリケーションを意識していないネットワーク層プロトコルは、どのようなことをする必要があるのかとは関係なく、同じ宛先ノードに至る新たな経路を再構築しようとする。

それにもかかわらず、同じ情報源への新たな経路を確立しようとする代わりに、ネットワークトポロジーを変更すれば、他の情報源が、同じ情報をより低いコストで提供できる。

言い換えると、モバイルノードは、接続が中断したことをピアツーピアプロトコルレベルと、関連したアプリケーションとに報告し、その後、これらが、古い情報源がまだ利用可能であるか、または別の情報源がより適切であるかを決定する。

さらに、ピアツーピアネットワークは、通常、固定式ネットワーク構造の上で動作するため、ピアツーピアネットワークノードは、近傍にある通信当事者と遠隔のネットワーク参加者を区別しない。モバイルノード間の距離は、一般に、固定式ネットワークにおける通信の安定性と、エラーのない動作とに影響しないため、探索情報も密接に利用可能であるとはいえ、通常のピアツーピアプロトコルは、離れたノードへの接続を確立できる。

より詳細な一例として、図１は、４つのノードを有するモバイルアドホックネットワークの上で動作する、簡単なピアツーピアファイル共有アプリケーションを示している。ピアツーピアオーバーレイネットワークレベルでは、ノードＡはノードＤへの静的接続を維持しており、従って、ノードＡがネットワーク内のファイルを探索する場合、照会メッセージをノードＤに送信する。要求されたファイルが、ノードＤでは入手不可能な場合、ノードＤは、そのメッセージをノードＢに対して、このノードＢへの接続、すなわち、接続２を介して転送する。

図１に示す例によれば、このメッセージは、同じ理由でノードＣに再び転送されるため、要求されたファイルはこのノードＣで公開されることが、推測される。従って、物理ネットワーク層では、たった２ホップしかはなれていないノードＣを発見するのに６個の無線接続を用いる。

結論として、静的オーバーレイ接続を維持することは、帯域幅とバッテリの電力が非常に乏しいリソースであるモバイルアドホックネットワークなどの無線通信ネットワークにおいて、ピアツーピアネットワークプロトコルを適用する際の、性能上の大きなボトルネックである。

先行技術で、ピアツーピアアプリケーションとアドホック無線通信ネットワークとの組み合わせに関するいくつかの調査が行われているが、それでも、その調査には、ピアツーピアネットワークプロトコルレベルでのアドホックネットワーク構築の可能性に関する十分な考慮が欠けている。例えば、白書２００２年のＪＸＭＥ，Ａ．Ａｒｏｒａの「ＪＸＴＡ ｆｏｒ Ｊ２ＭＥ_TM−Ｅｘｔｅｎｄｉｎｇ ｔｈｅ Ｒｅａｃｈ ｏｆ Ｗｉｒｅｌｅｓｓ Ｗｉｔｈ ＪＸＴＡ Ｔｅｃｈｎｏｌｏｇｙ」では、ＪＸＴＡをモバイル環境に適応させているが、それでもモバイルアドホックについては十分に考慮していない。さらに、２００２年、イタリア、ボローニャでの、埋め込み型、ウエアラブル型およびモバイル型デバイスについてのユビキタスエージェントに関するワークショップの議事録「ＬＥＡＰ ｉｎｔｏ ＡｄＨｏｃ Ｎｅｔｗｏｒｋｓ」は、ルーティングに関する疑問を呈しておらず、また、２００１年のカリフォルニア州ロングビーチ市でのモバイルアドホックネットワーク構築に関するＡＣＭシンポジウム（ＭＯＢＩＨＯＣ２００１）議事録の７ＤＳ、Ｍ．ＰａｐａｄｏｐｏｕｌｉとＨ．Ｓｃｈｕｌｚｒｉｎｅの「Ｅｆｆｅｃｔ ｏｆ Ｐｏｗｅｒ Ｃｏｎｓｅｒｖａｔｉｏｎ，Ｗｉｒｅｌｅｓｓ Ｃｏｖｅｒａｇｅ ａｎｄ Ｃｏｏｐｅｒａｔｉｏｎ ｏｎ Ｄａｔａ Ｄｉｓｓｅｍｉｎａｔｉｏｎ ａｍｏｎｇ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅｓ」では、位置情報が考慮されていない。さらに、２００１年ジョージア州アトランタ市での、ユビキタスコンピューティングのためのアプリケーションモデルとプログラミングツールに関するワークショップの議事録（ＵＢＩＣＯＭＰ２００１）のＰＲＯＥＭ、Ｇ．ＫｏｒｔｕｅｍとＪ．Ｓｃｈｎｅｉｄｅｒによる「Ａｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋｓ」には、より大型のモバイルアドホックシナリオのためのスケーリングが欠如しており、一方、２００３年フランスのソフィアアンティポリス市でのモバイルアドホックネットワーク構築とコンピューティングに関するワークショップの議事録（ＭＡＤＮＥＴ２００３）のＯＲＩＯＮ、Ａ．Ｋｌｅｍｍ、Ｃ．ＬｉｎｄｅｍａｎｎとＯ．Ｐ．Ｗａｌｄｈｏｒｓｔによる「Ａ Ｓｐｅｃｉａｌ−Ｐｕｒｐｏｓｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｆｉｌｅ Ｓｈａｒｉｎｇ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ」では、ファイル共有アプリケーションのみ焦点を当てており、位置に対する認識が欠如していて、ルーティングのオーバーヘッドが大きい。さらにまた、Ｂｌｕｅｔｏｏｔｈ規格では、アドホック通信環境におけるピアツーピアアプリケーションに対して考慮がなされているが、それでも、非常に短距離の通信以外はルーティングをサポートしていない。

要約すると、無線アドホック通信ネットワークに対して、このようなアドホックネットワークの特定の要件を考慮することなく、ピアツーピアコンピューティングを導入しても、性能は悪いものとなる。これは、ピアツーピアプロトコルが、下位のプロトコルに関する認識や情報、例えば、要求されたコンテンツや参加者の位置情報が全くなく、完全に独立したオーバーレイネットワーク構築に役立つように設計されているからである。このように、ピアツーピアネットワークにおいて近傍に関する認識が欠如しているため、遠隔接続となるが、その一方で、同じコンテンツがより密接に利用可能となる。また、モバイルアドホックネットワークでは、ホップの数が増えるとルーティングのオーバーヘッドも増加する、ホップ順ルーティングが採用されているが、ピアツーピアネットワークは、現在、下位の経路を意識しておらず、従って、最適な経路に関して判断することは不可能である。言い換えると、ピアツーピアプロトコルは固定式ネットワーク用に設計されており、従って、特に接続のロスが発生すると、参加者がピアツーピアネットワークから去ったかのように認識されるため、即座に再ルーティングをするモバイル通信環境において、変化するチャネル状態に対処することは不可能である。
Ｍ．ＫｈａｍｂａｔｔｉとＳ．Ａｋｋｉｎｅｎｉｎの文書によれば、特に２ロケーション管理方法、すなわち、階層的かつ分散的な方法に依存したピアツーピアモバイルアドホックネットワーク内でのロケーション管理が記載されている。この階層的な方法では、基地局とロケーションサーバとの双方として働く、少数のビーコン（ｂｅａｃｏｎ）が存在することを前提としている。分散的な方法では、ピアツーピア探索手法の型式を用いて、ビーコンを必要とせずにモバイルホスト間のロケーション管理を行う。
さらに、Ｒｕｅｄｉｇｅｒ Ｓｃｈｏｌｌｍｅｉｅｒと、Ｉｎｇｏ Ｇｒｕｂｅｒによる文書には、モバイルアドホックネットワークと、ピアツーピアネットワークにおけるルーティングが記載されている。特に、この参照文献では、ピアツーピアネットワークとモバイルアドホックネットワークとの類似点および相違点が強調され、この２つの分散的かつ自己組織型のネットワークに隠されている、潜在的な相乗効果が示されている。

上記事情に鑑み、本発明の目的は、モバイル無線通信ネットワークを介してのピアツーピアネットワーク構築を最適化することにある。

全体として、本発明は、ネットワーク層からアプリケーション層へ、またはその逆へと展開するモバイルピアツーピアプロトコルスタックを紹介する。ここで、上位のピアツーピアネットワークプロトコル層は、適当な探索基準を指定するだけでなく、適切な応答を受信し、その結果、無線ネットワークを認識して、トラフィックを最小化し、頻繁に発生する経路の中断に対処する。加えて、ネットワーク層ルーティングレベルは、ピアツーピアアプリケーションに関する情報を受信して、適当な通信ノードにしか通じていない経路を確立する。従って、本発明は、無線通信ネットワーク、例えば、アドホック無線ネットワークで、互いに異なるさまざまな関連サービスを生成するために必要なフレームワークを形成するものである。

従って、モバイル無線ネットワークでのピアツーピアアプリケーションの最適化は、ユーザにおいて、より高い度合いの受け入れをサポートし、また、固定式もしくは集中式のインフラストラクチャを用いることなく、サービスプロバイダの経費と、位置に基づいたサービスおよびアプリケーションを提供するための経費とを削減する。

本発明によれば、無線ネットワーク内のモバイルノードにおいて、請求項１の特徴を有するプロトコルスタックを使用する方法が提供される。同様に、無線ネットワーク内で動作し、請求項１１の特徴を有するネットワーク層ルーティングプロトコルと、モバイルピアツーピアネットワークプロトコルとを含むプロトコルスタックが動作するモバイルノードが提供される。

言い換えると、本発明によるプロトコルスタックは、動的なソースルーティングを考慮しており、また、例えば近接性に基づいてサービスを提供しているピアを発見することを可能にする、強化されたネットワーク層プロトコルと、アプリケーション層でのデータ交換のためのモバイルピアツーピアプロトコルと、これらの正式な２つのプロトコル間の層間通信のための同期式プロトコルとを含む。

本発明は、特に、ネットワーク層プロトコルの機能性を強化することを提案する。その結果、無線通信ネットワーク内でアプリケーションリソースを取得するために適用された照会メッセージが、例えば、照会に対して応答するモバイル通信ネットワーク内のモバイルノードの近接性、またはサービス能力に従って、アドレス情報の範囲を越えて拡張する探索基準を考慮できるようになる。従って、本発明は、無線通信ネットワークのトポロジに関する情報が実際に利用可能となるように、ネットワーク層プロトコルの探索基準を改善することを提案する。ネットワーク層ルーティングプロトコルレベルで用いられる探索基準のタイプに関する情報は、アプリケーションとサービスをサポートする上位のピアツーピア通信層プロトコルによって提供される。

本発明によれば、上位のピアツーピア層プロトコルとネットワーク層プロトコルとの間の探索基準の変更は、層間通信チャネルプロトコルによって達成でき、特に、ピアツーピアプロトコルスタック内の異なる階層レベル間の探索関連メッセージの交換に適用できる。

従って、適切なサービスリソースを探索している最中は、無線通信ネットワーク内での適切なリンクの維持と層間通信プロトコルの操作とによって、品質の向上と、経費の減少と、ピアツーピアサービスのプロバイダに対する経費の減少とによる、無線通信ネットワークでのピアツーピアサービスをユーザが受け入れる度合の向上が、達成できる。ピアツーピアサービスは、高度に動的で、急速に変化する無線通信ネットワーク、特に、無管理、無制御のアドホック無線通信環境でのルーティング機能性を提供するのに完全に適している。

本発明の別の好ましい実施形態によれば、モバイル通信環境において処理デバイスの内部メモリに直接読み込み可能なコンピュータプログラム製品が提供できる。ここで、このコンピュータプログラム製品は、モバイル通信環境の処理デバイス上で実行されると、本発明に係るプロトコルを使用するソフトウェアコードを含む。

従って、本発明はまた、コンピュータシステムまたはプロセッサシステムで、上述した様々なプロトコルを使用するために提供される。結論として、この結果、コンピュータシステム、または、より具体的には、アドホックネットワークなどに含まれるプロセッサと共に用いられる、コンピュータプログラム製品が、提供されることになる。

書き込み不可能な記憶媒体、例えば、プロセッサやコンピュータの入出力付属品によって読み取り可能な、ＲＯＭやＣＤ−ＲＯＭディスクなどの読み取り専用メモリに、永久的に記憶される情報と、書き込み可能な記憶媒体、すなわち、フロッピー（登録商標）ディスクおよびハードドライブに記憶される情報と、モデムあるいは他のインターフェースデバイスを介し、ネットワークやインターネット、電話網などの通信媒体を通して、コンピュータあるいはプロセッサに伝達される情報とを含む、本発明の機能を特徴づけるこのプログラムは、多くの形態のコンピュータあるいはプロセッサに提供できる。本発明の概念を実行する命令を読み取ることができるプロセッサを用いる際に、上述した媒体により、本発明の代替の実施形態が提示されることを理解すべきである。

以下に、本発明の最良の形態およびさまざまな態様、好ましい実施形態を、図表を参照しながら説明する。さまざまな機能性を以下に説明するが、これらの機能性は、ソフトウェア、ハードウエア、あるいは、これらの組み合わせで実現できる。さらに、さまざまな態様のプロトコルの使用を、さまざまなレベルで抽出して説明するが、以下に説明する各々のプロトコルおよび関連した実施は、単体で操作され、または、本発明によるピアツーピアプロトコルスタックの実施の全体的な枠組内にある、さらなる関連のプロトコルおよび対応する実施と組み合わせて操作されることに注意すべきである。

図２に、本発明による、無線通信ネットワーク上にあるピアツーピア動作用のプロトコルスタックを示す。

図２に示すように、本発明は、モバイルピアツーピアプロトコルＭＰＰと、拡張ダイナミックソースルーティングプロトコルＥＤＳＲと、モバイルピア通信チャネル制御プロトコルＭＰＣＰとの提供と実施とに関する。

図２に示すように、拡張ダイナミックソースルーティングプロトコルＥＤＳＲは、ＯＳＩプロトコルスタックに従って、リンク層と物理層の上位で実行されるが、これは、本発明の範囲との関連性を考慮することなく、モバイルアドホック通信ネットワーク、以下すなわちＭＡＮＥＴと呼ばれる。しかしながら、一般に、本発明はまた、以下に説明するようにネットワーク層においてルーティングプロトコルをサポートする限り、他のどのようなタイプの無線通信ネットワークにも適用可能であることに注意すべきである。

図２に示されている、ピアツーピアモバイルアドホックネットワークには、ピアの検出とパケットのルーティングという、共通する二つの課題がある。これらの課題を解決するため、ピアツーピアネットワークとモバイルアドホック通信ネットワークとの間の相乗効果により、モバイルピアツーピアプロトコルの管理負担を軽減し、その性能および信頼性を向上させる。

図２に示すように、より詳しくは、ピアツーピアプロトコルにより、ピアは、直接的にデータを交換することが可能となり、従って、このプロトコルは、ピアツーピアネットワーク内でサービス関連のデータ、例えば、ファイルに関与することになる。モバイルピアツーピアプロトコルは、例えばＨＴＴＰに基づいて、データをアップロードし、ダウンロードする能力を有する。リンクの中断により送信が遮断された場合、コンテンツ範囲にあるヘッダーが、ファイルの転送を再開する能力を提供する。本発明によれば、ＨＴＴＰは、その豊富な特徴の集合と、さまざまなコンピュータ言語で利用可能な多くの標準実施との一例として適用される。しかしながら、同じ機能性を持つ他のどのようなプロトコルを適用しても良い。

さらに、拡張ダイナミックソースルーティングプロトコルは、既存のネットワーク層プロトコル、例えば、ＤＳＲプロトコルに対して、新しいタイプの要求と応答を有する。従って、拡張ダイナミックソースルーティングプロトコルは、単なるＩＰアドレス以外の基準によってピアを発見する手段となる。それにもかかわらず、拡張ネットワーク層ルーティングプロトコルＥＤＳＲは、以前に公知のダイナミックソースルーティングプロトコルの基本的動作を変更しておらず、従って、ＥＤＳＲノードは、既存のＤＳＲネットワークになくてはならない部分である。

さらに、モバイルピア制御プロトコルは、拡張ダイナミックソースルーティングプロトコルと、ネットワーク層とを、アプリケーション層内のピアツーピアアプリケーションと共にリンクする。以下に詳細に説明するように、モバイルピア制御プロトコルを用いて、アプリケーションは、拡張ダイナミックソースルーティング層に登録し、探索要求を起動して、無線通信ネットワーク内の他のノードから入力される探索要求を処理する。言い換えると、モバイルピア制御プロトコルは、アプリケーション層とネットワーク層との間の、クロス層通信チャネルまたは層間通信チャネルである。モバイルピア制御プロトコルは、ファイル交換自体を除き、入出力要求および応答の全てを、対応するプロトコルと通信する。

図３に、本発明による、モバイルピアツーピアネットワーク内での、データの探索およびダウンロード、アップロードを示す、メッセージ順序表を示す。

図３に示すユニットである、ピアツーピアアプリケーション（Ａ）１０と、ピアツーピアアプリケーション（Ｂ）１２とは、以下に説明するように、データ交換用の通信チャネルを起動するモバイル通信環境内で実行されるピアツーピアアプリケーションＡとＢとに関連している。さらに、追加のユニットＥＤＳＲ（Ａ）１４と、ＥＤＳＲ（Ｂ）１６とは、それぞれ、ピアツーピアアプリケーション（Ａ）と、ピアツーピアアプリケーション（Ｂ）とについて、ネットワーク通信プロトコル層で用いる機能性に関連している。

図３に示すように、制御関連のデータもしくはペイロードデータの交換は、順序表内のエラーラインで表されている。

以下に、ネットワークプロトコル層の使用と機能性との詳細な態様を、図４〜６を参照して説明する。

図４に、ＥＤＳＲ（Ａ）と（Ｂ）の概略図を示す。本発明によれば、このようなユニットは、それぞれ、無線通信ネットワーク内のノードにおいて、関連する拡張ダイナミックソースルーティングプロトコル機能を使用する目的で操作されるものと仮定する。

図４に示すように、このような拡張ダイナミックソースルーティングプロトコルユニット（Ａ）は、受信ユニット１８と、変換ユニット１９と、転送ユニット２０とに分割される。

第１のインターフェースユニット１８は、モバイルピアツーピア層プロトコル、すなわち、ピアツーピアアプリケーション（Ａ）の上で稼動するサービスを介して起動されるサービス要求に関連する探索関連のデータを受信することができる。さらに、変換ユニット２０は、提示された探索関連データを、ネットワーク層ルーティングプロトコルＥＤＳＲに従って、照会メッセージに変換する。すでに概説したように、本発明では、照会メッセージが、アドレス情報の範囲を越えて拡張する探索基準、すなわち、サービスリソースまたはこのようなタイプのサービスリソース、すなわち、データのタイプまたはサービスのタイプに対して、探索を起動するノードへの近接性の態様を特定する基準を含むことを提案する。さらに、動作に際して、転送ユニット２２は、照会項目を、サービスリソースの探索時に無線通信ネットワークを通して展開するために、下位層に出力する。

本発明で意味するところの探索基準の一般的な例として、サービスを、例えば、無線アドホック通信ネットワーク内の最も近い範囲に位置付けし、後続のデータ転送トラフィックを最小化し、または、サービスのタイプ、例えば、レストラン、銀行業、駐車などを表示する。照会メッセージに対するより詳細な例としては、探索要求ＳＲＥＱ、ハッシュ要求ＨＲＥＱ、ファイル応答ＦＲＥＰ、プッシュ要求ＰＲＥＱ、宣言応答ＤＲＥＰに関連したものがあり、これらを以下に詳細に説明する。

図３と図４に示すように、拡張ダイナミックソースルーティングプロトコルは、ピアツーピアアプリケーションの登録を受信して、次にこの登録の受信を承認する。これは、図４に示されている登録ユニット２４によって達成できる。

さらに、これ以降続いて、および、照会メッセージの準備の後で、転送ユニット２２も、無線通信ネットワーク内の別のノード（Ｂ）から起動された、照会メッセージに対する応答を受信する。従来、拡張ダイナミックソースルーティングプロトコル（Ａ）および（Ｂ）の各々の使用において、受信ユニット１８と転送ユニット２２とは、無線ネットワークインフラストラクチャ内を、ネットワークプロトコル層からピアツーピアアプリケーションレベルに流れている、照会メッセージを交換し、アプリケーションレベルでさまざまな照会メッセージを評価する。この評価の結果次第で、すなわち、関連するノードで操作されたサービスにより探索基準が満たされたかどうかによって、探索応答が生成され、これが次にピアツーピアアプリケーションレベルから拡張ダイナミックソースルーティングレベルにまで転送されて、上記の探索要求を起動したノード、以下、送信ノードに転送される。

関連するさまざまな探索応答とは、ファイル応答、プッシュ応答、宣言応答である。

探索に関連し、図４に示す評価ユニット２６により達成されるさらなる態様として、探索を起動するノードで複数の探索応答を受信した際に、異なる探索要求を評価するという態様がある。本明細書において、評価ユニット２６は、少なくとも１つの所定の費用関数、例えば、送信ノードと受信ノードとを接続する無線ネットワークの経路上の少なくとも１つのノードの特性を処理する。この特性の典型的な例として、経路上のノードの数、ノードの送信出力、ノードの移動速度、ノードの転送がある。

以下において、上述した照会メッセージのさまざまな実例を説明する。従来、標準の機能を用いるＩＰフィールドと、本発明による探索基準に関連したフィールドとは、区別されている。

以下、探索要求（ＳＲＥＱ）について述べる。データを探索する際、ＥＤＳＲは、グヌーテラの照会メッセージのような類似のメッセージ、すなわち、探索要求（ＳＲＥＱ）を提供する。ＳＲＥＱは、モバイルＰ２Ｐネットワークにおけるデータ探索の初期のオプションである。ＳＲＥＱは、ＤＳＲオプションルート要求（ＲＲＥＱ）に基づいている。ＳＲＥＱは、応答として、応答タイプ（ｘＲＥＰ）のオプションが返却されるのを待っている。ＥＤＳＲが求める応答のタイプは、当初に要求されたサービスとデータタイプとに依存する。

表２−１に、ＳＲＥＱのビット構造を示し、ＳＲＥＱフィールドについて以下に説明する。

以下、ＩＰフィールドについて述べる。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＳＲＥＱを伝搬するためにパケットを再送信する中間ノードは、このソースアドレスを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。

以下、ＳＲＥＱフィールドについて述べる。オプションタイプは、３２である。オプションデータ長とは、８ビットの符号無し整数であり、オプションタイプフィールドと、オプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元により生成された、１６ビットの一意の値である。この値によって、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうかを決定できる。この識別表示の値が、受信ノードにより自身の探索要求テーブル内に発見された場合、この受信ノードは探索要求を廃棄して、ＳＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。Ｋｌｅｎとは、オプション中のキーワードの数を示す、４ビット値である。従って、キーワードの最大数は、１５である。次に、キーワードについて説明するが、キーワード［ｉ］とは、以前に選択されたサービスタイプの探索基準を明示する、文字列の３２ビットハッシュ値である。続くキーワードが、基準をさらに制限する。従って、ＡＮＤ演算子である。次に、アドレスについて説明するが、アドレス［ｉ］とは、探索要求オプション内に記録されている、ｉ番目のノードのＩＰアドレスである。このフィールドは、無線通信ネットワーク内で経路を決定するために用いられる。

ハッシュ要求（ＨＲＥＱ）について説明する。ハッシュ要求（ＨＲＥＱ）とは、ＳＲＥＱの特殊な形式である。しかしながら、ＨＲＥＱは、探索基準として、ファイルサイズと要求されたデータの特性のみ使用する。この特性は、１２８ビット長であり、ＭＤ５ハッシュ手順により作成される。この特性により、ＨＲＥＱを用いて、経路の中断があった場合に、データの代わりのソースを発見できる。ＨＲＥＱも、ＳＲＥＱと同様に、ＤＳＲオプションのＲＲＥＱに基づいている。

表２−２にＨＲＥＱのビット構造を示し、ＨＲＥＱフィールドについて以下に説明する。

以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。ＨＲＥＱを伝搬するためにこのパケットを再送信する中間ノードは、このフィールドを変更することはない。宛先アドレスとは、ＩＰに限定したブロードキャストアドレス（２５５．２５５．２５５．２５５）である。ホップ制限とは、８ビットの符号無し整数であり、パケットの有効期間（ＴＴＬ）を示す。

以下、ＨＲＥＱＰフィールドについて説明する。オプションタイプは、３３である。オプションデータ長は、８ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。識別表示とは、探索要求の送信元によって生成された１６ビットの一意の値である。この値により、受信ノードは、受信ノード自身がこの探索要求のコピーを最近検知したかどうか決定できる。この識別表示の値が、この受信ノードによってその探索要求テーブル内から発見された場合、この受信ノードはハッシュ要求を廃棄して、ＨＲＥＱパケット転送中のループを回避しなければならない。サービスタイプとは、探し求めているサービスの１６ビットのハッシュ値である。例えば、「Ａｕｄｉｏ」、「Ｖｉｄｅｏ」、「Ｔａｘｉ」、または類似のものである。ファイルサイズとは、データのサイズをオクテット単位で示す３２ビット値である。ＭＤ５ハッシュとは、ＭＤ５手順で生成される１２８ビットのハッシュ値である。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次にアドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信した、ｉ番目のノードのＩＰアドレスである。このフィールドは、ＭＡＮＥＴ内の経路を決定するために用いられる。

以下、ファイル応答（ＦＲＥＰ）について説明する。ファイル応答（ＦＲＥＰ）オプションは、ピアが探索要求を受信した際の応答である。従って、この探索要求は、ＳＲＥＱまたはＨＲＥＱであり、このピアが共有するオブジェクトのメタデータに適合する。ＦＲＥＱは、要求されたデータがファイルであり、従って、その共有されたファイルに関するあらゆる必要な情報を含むことを暗に示す。この情報に基づいて、要求側のピアは、ファイル送信を起動できるが、これはモバイルピアツーピアプロトコルによる。ＳＲＥＱの場合と同様に、ＦＲＥＱの構造は、ネットワーク層プロトコルＤＳＲのオプションである経路応答（ＲＲＥＰ）の構造に基づいている。

表２−３にＦＲＥＰのビット構造を示し、ＦＲＥＰフィールドについて以下に説明する。

以下、ＩＰフィールドについて説明する。ソースアドレスとは、パケット送信元のノードのＩＰアドレスである。宛先アドレスは、ＳＲＥＱ、ＨＲＥＱを送信するノードのアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。

以下、ＦＲＥＰフィールドについて説明する。オプションタイプは、４８である。オプションデータ長とは、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）であり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。Ｕは、１ビットフラグであり、提供側のピアがアップロード可能かどうかを示す。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この合計は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。ファイル名長は、８ビット値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名は、ファイルの名称である。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信ノードＲまでの全経路を含む。

以下、プッシュ要求（ＰＲＥＱ）について説明する。プッシュ要求（ＰＲＥＱ）オプションは、応答のノードから送信ノードに送られ、続いて、送信ノードから応答ノードにデータがアップロードされる。

表２−４にＰＲＥＱのビット構造を示し、ＰＲＥＱフィールドについて以下に説明する。

以下、ＩＰフィールドについて説明する。オプションタイプは、４９である。ソースアドレスは、ＰＲＥＱを生成するノードのＩＰアドレスである。宛先アドレスは、ＦＲＥＰを送信するノードのＩＰアドレスを含む。このアドレスは、ＦＲＥＰのソースアドレスフィールドからコピーすることが可能である。

以下、ＰＲＥＱフィールドについて説明する。オプションタイプは、４９である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートにより、このピアとのＭＰＰ通信が可能となる。ファイルサイズは、３２ビット値であり、発見されたファイルのサイズを示す。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５ハッシュ手順で作成される。この値は、ファイルサイズと組み合わせて、ピアツーピアネットワーク内でファイルを明確に特定する。次に、アドレスについて説明するが、アドレス［ｉ］とは、このメッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＰＲＥＱは、送信ノードＳから受信側ノードＲまでの全経路を含む。この経路は、ＦＲＥＰを搬送した経路と同じ経路でなくてはならない。

以下、宣言返答（ＤＲＥＰ）について説明する。宣言返答（ＤＲＥＰ）オプションとは、探索要求を受信したピアの応答のことである。この探索要求は、ＳＲＥＱまたはＨＲＥＱである。ＤＲＥＰは、ネットワーク層プロトコルＥＤＳＲの一般的なオプションであり、アプリケーション開発者に対して、特定のアプリケーションの用件を満たすために、ＭＰＰを越えてプロトコルを使用できる可能性を提供する。従って、ＤＲＥＰは、提供されたサービスに関する特定の情報を送信するのではなく、サービスのプロファイルに関する情報を送信する。従って、モバイルピアツーピアプロトコルＭＰＰは、２つのピアの間の通信チャネルを確立するために必要なあらゆる情報を持つ、プロファイルを送信できる。ＤＲＥＰは、ＦＲＥＰの特殊な形式であり、ビット構造は異なっていない。ＤＲＥＰ内のデータ情報とは、サービスプロファイルのことである。

以下、ＩＰフィールドについて説明する。ソースアドレスとは、ＤＲＥＰを生成するノードのＩＰアドレスである。宛先アドレスとは、ＳＲＥＱ、ＨＲＥＱを送信するノードのＩＰアドレスを含む。このアドレスは、ＳＲＥＱ、ＨＲＥＱのソースアドレスフィールドからコピーすることが可能である。

以下、ＤＲＥＱフィールドについて説明する。オプションタイプは、５０である。オプションデータ長は、１６ビットの符号無し整数であり、オプションタイプフィールドとオプションデータ長フィールドとを除いた、オクテット単位のオプション長である。Ｌは、１ビットフラグであり、他のネットワークとの通信を可能とするために、最後のホップがＥＤＳＲネットワークの外部であるかどうかを示す。ファイルサイズは、３２ビット値であり、プロファイルのサイズをオクテット単位で示す。ＴＣＰポートとは、ＴＣＰポート（１〜６５５３５）のことであり、これを介して、ピアのサービスが到達可能となる。このポートによって、ピアとのＭＰＰ通信が可能となる。キーワードの合計は、ＳＲＥＱ内の全てのキーワードをビット毎に加算したものである。この和は、要求と応答のマッチコードとして用いることが可能である。ＭＤ５ハッシュは、１２８ビットのハッシュ値であり、ＭＤ５手順で生成される。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に特定する。ファイル名長は、８ビットの値であり、ファイル名の長さを示す。従って、ファイル名は、最大で２５５文字まで含むことが可能である。ファイル名とは、データの名称である。次にアドレスについて説明するが、アドレス［ｉ］とは、メッセージを受信したｉ番目のノードのＩＰアドレスである。従って、ＦＲＥＰは、送信ノードＳから受信側ノードＲまでの全経路を含む。

図５は、モバイルピアツーピア層プロトコルレベルでの機能性を示す略図である。

図５に示すように、このプロトコル層の機能性は、第１のインターフェースユニット２８と、評価ユニット３０と、メモリーユニット３２と、探索応答生成ユニット３４と、データ交換ユニット３６と、登録ユニット３８と、第２のインターフェースユニット４０とに関連付けて使用される。

動作に際して、第１のインターフェースユニットは、ノードのアドレス情報の範囲を越えて拡張する探索基準を含んだ、サービス要求を受信する。ここで、サービス要求は、モバイルピアツーピアネットワークプロトコルの上で操作されるサービス内で生成されることに注意すべきである。

また、動作に際して、第２のインターフェースユニットは、サービス要求を、モバイルピアツーピアネットワークプロトコルの下位で稼動する、ネットワーク層ルーティングプロトコルと交換し、これにより、無線ネットワーク内の共有サービスリソースを特定する。第２のインターフェースユニット４０も、遠隔ノードで起動されるネットワーク層ルーティングプロトコルからサービス要求を受信し、このサービス要求を評価するために、モバイルピアツーピアプロトコル上で稼動しているサービスに転送する。

また、動作に際して、評価ユニット３０は、モバイルピアツーピアネットワークプロトコルレベルで、探索要求を評価する。従来、ピアツーピアサービスをさまざまなタイプに分類したものを記憶する、メモリーユニット３３も、評価のための基礎として提供されている。従来、評価ユニットは、図６に示すように、サービスリソース探索用のディレクトリ構造を用いて、モバイルピアツーピアサービスをさまざまなタイプに分類する。

動作に際して、図６に示す探索応答生成ユニット３４は、モバイルピアツーピアネットワークプロトコル上における探索要求の評価によって探索基準を満たしたことを認識すると、探索応答を生成し、続いて第２のインターフェースユニット４０を介して転送される。

モバイルピアツーピアプロトコルレベルでの機能性の更なる態様は、探索成功後の動作に関連している。

従来、データ交換ユニット３６は、無線モバイル通信ネットワーク内で経路を特定する、探索要求と探索応答の交換後に、モバイルピアツーピアプロトコル層でデータ交換のための直接交換を行う。また、動作に際して、データ交換ユニット３６は、接続の中断が発生すると、接続を回復する。本発明によるデータの直接交換は、可能な限りＨＴＴＰに基づいた、データのダウンロードおよびアップロード、または、データのダウンロードまたはアップロードにより実施するのが望ましい。

上述したように、探索に直接的に関連する別のユニットとして、図６に示す登録ユニット３８がある。これによって、ネットワーク層ルーティングプロトコルでのモバイルピアツーピアサービスの登録と、後続の探索関連メッセージの交換のために、登録要求の提示後の、登録の結合の受信とが可能になる。

本発明のさらなる態様は、モバイルピアツーピアプロトコルレベルと、ネットワーク層ルーティングプロトコルとの間の、情報の交換に関連する。従来、図５に示すように、モバイルピアツーピア制御プロトコルは、モバイルピアツーピアプロトコル層レベルで機能性を実施する上位層と、ネットワーク層ルーティングプロトコルレベルでモバイルピア制御プロトコルの機能性を実施する下位層レベルとを有する。以下では、上位層をＭＰＣＰ７、下位層をＭＰＣＰ３と呼ぶ。

モバイルピアツーピア制御プロトコルは、サービス層とネットワーク層との間の通信チャネルを提供する、同期式のプロトコルである。従って、ＭＰＣＰは、一方ではＯＳＩ第３層で実施され、他方ではＯＳＩ第７層のそれぞれのサービスによって実施されなければならない。従って、ＭＰＣＰ３とＭＰＣＰ７は、個々に定義されている。

サービスにより提供される機能から、モバイルピア制御プロトコルＭＰＣＰを開発する必要性が生まれる。サービスは、データを提供するだけでなく、探索要求に対して肯定応答または否定応答のどちらを行うか、すなわち、サービスが、要求されたファイルを共有しているかどうかを判断しなければならない。肯定応答をする場合、サービスは、必要な情報をＥＤＳＲと通信し、これにより、ＦＲＥＰを要求側のピアに送信可能となるようにしなければならない。ＭＰＣＰは、以下のタスクを満たさなければならない。
第一に、登録である。１つのピアが複数のサービスを実施できるため、全てのサービスは、ネットワーク層に登録しなければならない。この結果、ネットワーク層は、サービスに対して、探索要求が入力されたことを適宜通知できる。ユーザがサービスを削除すると、このサービスは、ネットワーク層における登録を取り消さなければならない。
第二に、探索である。サービスが、そのユーザに対して、無線通信ネットワーク内のデータ探索の可能性を提供すると、ＭＰＣＰは、ＭＰＣＰ３を介して探索パラメータを、ネットワーク層プロトコルＥＤＳＲに転送しなければならない。
第三に、要求である。ＭＰＣＰ３は、入力された要求をＭＰＣＰ７に送信し、次にサービスに送信する。また、ＭＰＣＰは、適切な応答をネットワーク層プロトコルＥＤＳＲに送信する。
最後に、応答である。ＭＰＣＰ３は、応答が返ってきたことをＭＰＣＰ７に通知し、それから、ネットワーク層プロトコルＥＤＳＲでの動作を適宜開始する。

このようなタスクのために、本発明によれば、確認メッセージ、登録メッセージ、要求メッセージ、応答メッセージのようないくつかのメッセージが、特定のパラメータと共に定義される。

以下に、パラメータを伴うＭＰＣＰメッセージと、期待される応答とを詳細に述べる。

まず、確認メッセージとして、ＡＣＫ（肯定応答）がある。メッセージＡＣＫは、正常に受信したメッセージに対して応答する。
メッセージ形式は、ＡＣＫ（［Ｉｄ］）である。送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
このメッセージに対する応答に該当するものはない。

次に、確認メッセージとして、ＮＡＫ（否定応答）がある。メッセージＮＡＫは、エラーはないものの、正常に実行できないメッセージに対して応答する。この理由は、例えば、ユーザ権限、タイムアウトまたはその他類似のものである。異常の原因は、ＮＡＫ内の番号（コード）および文字列（理由）として、送信元に返却される。
メッセージ形式は、ＮＡＣ（［Ｉｄ］、コード、理由）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
コードは、異常の理由を明確に指定する番号である。
理由は、ユーザが読み取り可能な、異常の理由である。
このメッセージに対する応答に該当するものはない。

さらに、確認メッセージとして、ＥＲＲ（エラー）がある。メッセージＥＲＲは、メッセージ形式にエラーがあるメッセージに対して応答する。その理由は、例えば、登録されているサービスとの矛盾、もしくは、探索要求の不正な形式である。エラーの理由は、番号（エラーコード）および文字列（説明）として、送信元に返却される。
メッセージ形式は、ＥＲＲ（［Ｉｄ］、エラーコード、説明）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。このパラメータは、ＭＰＣＰ３からのメッセージに対してのみ用いられ、このメッセージの受信者であるＭＰＣＰ７サービスを指定する。
エラーコードは、異常の理由を明確に指定する番号である。
説明は、ユーザが読み取り可能な、エラーの理由である。
このメッセージに対する応答に該当するものはない。

次に、登録メッセージとして、ＲＥＧ（登録）がある。メッセージＲＥＧによって、サービスは、自らをＭＰＣＰ３に登録できる。これは、必要な動作であり、通常、サービスを起動する際に行われる。登録されたサービスは、例えば、追加の処理のためにＩＳＲＥＱを受信できる。
メッセージ形式は、ＲＥＧ（Ｉｄ、ポート、（サービス））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子である。これは、例えば、プロセスＩＤ、または、例えばシステム時間および確率関数に基づいて生成される乱数、または、サービスが現在使用中のＩＰアドレスとポートの組み合わせである。
ＩＰは、サービスのＩＰアドレスである。これは、装置が、いくつかのネットワーク要素またはＩＰアドレスをサポートする場合に必要である。
ポートは、ＴＣＰポートである。これにより、サービスは、ＩＰアドレスを通して利用可能となる。
サービスは、サービスタイプのリストである。例えば、探索要求を受信した後は、登録されているサービスに対応するものだけが転送される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、登録メッセージとして、ＤＲＥＧ（登録取消）がある。メッセージＤＲＥＧにより、サービスは、ＭＰＣＰ３の自らの登録を取り消すことができ、今後ＭＰＣＰ３からメッセージを受信することはない。
メッセージ形式は、ＤＲＥＧ（Ｉｄ）である。
送信元は、ＭＰＣＰ３またはＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

次に、探索メッセージとして、ＳＥＱ（探索要求）がある。メッセージＳＲＥＱにより、ＭＰＣＰ７は、ＭＰＣＰ３におけるキーワードに基づいて、探索要求を起動できる。ＭＰＣＰのＳＲＥＱは、ＥＤＳＲプロトコルの対応するＳＲＥＱに変換され、次に下位に下げられる。
メッセージ形式は、ＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、文字列の１６ビットのハッシュ値であり、要求されたサービスを指定する。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

次に、探索メッセージとして、ＩＳＲＥＱ（入力される探索要求）がある。ＩＳＲＥＱは、ＳＲＥＱに対応するメッセージである。ＭＰＣＰ３は、ＥＤＳＲの詳細なＳＲＥＱオプションを持つＩＳＲＥＱメッセージを、ＭＰＣＰ７に送る。すると、各サービスは、自らがこの探索要求に対して肯定応答するかどうか検証できる。
メッセージ形式は、ＩＳＲＥＱ（Ｉｄ、サービス、（キーワード））である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。
キーワードは、３２ビットハッシュ値のリストであり、指定されたサービスにおける、探索のためのキーワードとして用いられる。ハッシュ値は、ＥＤＳＲのＳＲＥＱを送信する前に、探索語の文字列から生成される。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、探索メッセージとして、ＨＲＥＱ（ハッシュ要求）がある。ＨＲＥＱにより、サービスは、ＥＤＳＲのＨＲＥＱを起動し、データをダウンロードするための代替のソースを探索できる。
メッセージ形式は、ＨＲＥＱ（Ｉｄ、サービス、ファイルサイズ、ハッシュ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。このサービスは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドに対応している。
ファイルサイズは、オクテット単位のデータのサイズである。
ハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、探索メッセージとして、ＩＨＲＥＱ（入力されるハッシュ要求）がある。ＭＰＣＰ３は、ＥＤＳＲのＨＲＥＱを受信すると、即座にメッセージＩＨＲＥＱをＭＰＣＰ７に送る。これにより、各サービスは、適宜応答することができる。
メッセージ形式は、ＩＨＲＥＱ（Ｉｄ、サービス、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
サービスは、要求されたサービスを指定する、文字列の１６ビットのハッシュ値である。これは、ＥＤＳＲのＨＲＥＱオプションのサービスタイプフィールドからのコピーである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のデータのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

次に、応答メッセージとして、ＦＲＥＰ（ファイル応答）がある。ＦＲＥＰは、ＩＳＲＥＱまたはＩＨＲＥＱという形式を持つ探索要求を受信した際に、ファイルとして対応するデータが利用可能である場合における、サービスに対する肯定的な応答である。ＭＰＣＰ３は、ＩＰアドレスやＴＣＰポートなどの登録されているサービスのデータの情報に基づいて、ＥＤＳＲのＦＲＥＰを作成できる。
メッセージ形式は、（Ｉｄ、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、応答メッセージとして、ＩＦＲＥＰ（入力されるファイル応答）がある。ＩＦＲＥＰは、ＦＲＥＰに対応するものである。ＩＦＲＥＰは、ＥＤＳＲのＦＲＥＰオプションの詳細な情報とともに、ＭＰＣＰ３によりＭＰＣＰ７に送られる。この情報に基づいて、サービスは、ＭＭＰ上でデータ転送を起動できる。
メッセージ形式は、ＩＦＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイル名、ファイルサイズ、アップロード）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、提供されたサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスを得ることが可能となる。
ファイルハッシュは、全てのファイルに対する、１２８ハッシュビットのＭＤ５ハッシュ値である。
ファイル名は、ファイルの名前である。
ファイルサイズは、オクテット単位のファイルのサイズである。
アップロードは、ブール値であり、ＭＰＰサーバにアップロードできるかどうかを示す。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、応答メッセージとして、ＰＲＥＱ（プッシュ要求）がある。ＦＲＥＰを受信した後で、モバイルピアツーピアプロトコルＭＰＰは、提供されているピアに対し、与えられたＴＣＰポートを介して、直接接続を確立しようとする。もし不可能であれば、提供側のピアがファイアウォールの背後にある場合と同様に、そして、提供側のピアが、アップロードを許容する場合（ＦＲＥＰ内のＵフラグ）と同様に、ＭＰＣＰ７は、ＭＰＣＰ３にＰＲＥＱメッセージを送り、ＥＤＳＲのＰＲＥＱを起動する。ＰＲＥＱは、提供側のピアに対し、提供されたポートを介してＭＰＰのダウンロードを開始できないため、代わりにファイルをアップロードしてほしい旨を通知する。ＰＲＥＱにより、アップロードするために必要とされる全ての必要なデータが、提供される。
メッセージ形式は、ＰＲＥＱ（Ｉｄ、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ファイルハッシュは、１２８ビットのＭＤ５ハッシュである。この値は、ファイルサイズと組み合わせて、Ｐ２Ｐネットワーク内でファイルを明確に指定する。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、応答メッセージとして、ＩＰＲＥＱ（入力されるプッシュ要求）がある。ＩＰＲＥＱは、ＰＲＥＱに対応するものである。これは、アップロードの必要がある、要求されているファイルに関する情報を含む。これは、ＥＤＳＲのＰＲＥＱを受信すると、ＭＰＣＰ３によりＭＰＣＰ７に送られる。これにより、モバイルピアツーピアプロトコルＭＰＰによるアップロードを開始することができる。
メッセージ形式は、ＩＰＲＥＰ（Ｉｄ、ＩＰ、ポート、ファイルハッシュ、ファイルサイズ）である。
送信元は、ＭＰＣＰ３である。
Ｉｄは、サービス固有の識別子であり、これより前に、ＭＰＣＰ３に登録するために用いられたものである。
ＩＰは、要求側のサービスのＩＰアドレスである。
ポートは、ＴＣＰポートであり、これを介してサービスをアップロードすることが可能になる。
ファイルハッシュは、全てのデータに対する、１２８ビットのＭＤ５ハッシュ値である。
ファイルサイズは、オクテット単位のファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

さらに、応答メッセージとして、ＤＲＥＰ（説明応答）がある。ＤＲＥＰは、ＥＤＳＲのＤＲＥＰメッセージの送信を要求する。ＭＰＣＰ７からＭＰＣＰ３に送られるが、これは、受信されたＩＳＲＥＱまたはＩＨＲＥＱに対する、肯定応答である。ＭＰＣＰ３は、ＥＤＳＲのＤＲＥＰを作成するためのＩＰアドレスやＴＣＰポートなどの、登録されているサービスに関する必要な情報を提供する。
メッセージ形式は、ＰＲＥＰ（Ｉｄ、プロファイルハッシュ、プロファイル名、プロファイルサイズ）である。
送信元は、ＰＣＰ７である。
Ｉｄは、サービス固有の識別子であり、これより前にＭＰＣＰ３に登録するために用いられたものである。
プロファイルハッシュは、プロファイルデータに関する、１２８ビットのＭＤ５ハッシュ値である。
プロファイル名は、プロファイルの名前である。
プロファイルサイズは、オクテット単位のプロファイルのサイズである。
このメッセージに対する応答として、ＡＣＫ、ＮＡＫ、ＥＲＲがある。

上記に加えて、本発明により提案されているプロトコルスタックが、ＳＤＬでシミュレーションされ、その機能が立証された。特に、ノードの数を５としてシミュレーションを行った。これらの調査およびそれに関連するものと、以前からあるソリューション、特にグヌーテラとを比較すると、本発明によるプロトコルスタックが、アドホックネットワークで用いられてきた従来のピアツーピアプロトコルよりも、性能面で飛躍的に向上していることがわかる。より詳細に述べると、ファイル探索が１回成功する毎のオーバーヘッドは、グヌーテラの場合で４８５０バイトであり、ＭＰＰの場合は１９６６バイトであった。さらに、バックグラウンドのトラフィックは、グヌーテラの場合で２．４３キロビット／秒、ＭＰＰの場合は０．０２９キロビット／秒であった。

本発明の動機付けとなる、無線ネットワーク上で稼動する、ピアツーピアアプリケーションの例を示す図である。 本発明による、無線通信ネットワーク上で稼動する、ピアツーピア運用のためのプロトコルスタックを示す図である。 本発明による、モバイルピアツーピアネットワークにおける、データの探索とダウンロードを示すメッセージ順序表である。 ネットワーク層ルーティングプロトコルレベルでの機能性を示す概略図である。 モバイルピアツーピアプロトコルレベルでの機能性を示す概略図である。 本発明による、サービスリソースの探索の基礎となるディレクトリ構造を示す図である。 モバイルピア制御プロトコルレベルにおける機能性を示す概略図である。

Claims (17)

1. モバイルピアツーピアアプリケーションと拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）との間で層間通信チャネルプロトコル（ＭＰＣＰ）を使用して、前記モバイルピアツーピアアプリケーションと前記拡張ネットワーク層ルーティングプロトコルとの間で、全ての入出力メッセージを、ファイル交換を除いて、交換するステップと、
   モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービス（１０）から、サービスを提供するモバイルノードと該サービスの提供を受けるモバイルノードとの間のホップ制限を含んだ探索基準を含むサービス要求を受信するステップと、
   無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求を拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）に転送するステップであって、前記特定は、前記探索基準を含んだ前記拡張ネットワーク層ルーティングプロトコルに基づいて、照会項目を展開することにより行われるものである、ステップと、
   前記拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）に従って、前記探索基準を照会メッセージに変換するステップと、
   サービスを提供しているモバイルノードを特定するために前記拡張ネットワーク層ルーティングプロトコルを用いて、前記照会メッセージを前記無線ネットワーク内の少なくとも１つの別のモバイルノードと交換するステップと
   を含み、
   プロトコルスタックが、前記無線ネットワーク内のモバイルノードをルーティングするために提供されている前記拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）と、モバイルピアツーピアネットワークプロトコル（ＭＰＰ）とを含み、
   前記ピアツーピアネットワークプロトコルが、前記拡張ネットワーク層ルーティングプロトコルの上位で動作するものである、
   無線ネットワークのモバイルノードにおいてプロトコルスタックを使用する方法。
2. 前記照会メッセージのうちＳＲＥＱとＨＲＥＱとが、データの探索に関連しており、前記照会メッセージのうちＨＲＥＱが、探索データのファイルサイズと特性に関する情報とを指定するものである、請求項１に記載の方法。
3. 前記無線ネットワーク内の別のモバイルノードにおいて、前記照会メッセージを受信するステップと、
   ノードに登録されている少なくとも１つのピアツーピアアプリケーションに対し、前記拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）に従って、前記照会メッセージを転送するステップと、
   探索基準が満たされたかどうかについての評価を前記ピアツーピアアプリケーションから受信するステップと、
   少なくとも１つの探索基準が満たされた場合に、探索が起動された前記無線ネットワーク内のサービス要求側ノードに対して探索応答を送るステップと
   をさらに含む請求項１または２に記載の方法。
4. サービス要求側モバイルノードにおいて、前記探索応答を受信するステップをさらに含み、前記探索応答のうちＦＲＥＰが、前記サービス要求側モバイルノードと、サービス提供側モバイルノードとを接続する前記無線ネットワーク内の経路情報を含む、請求項３に記載の方法。
5. 前記探索応答を複数受信した場合に、少なくとも１つの所定の費用関数に従ってさまざまな探索結果を評価するステップをさらに含み、前記少なくとも１つの所定の費用関数が、前記サービス要求側モバイルノードと、前記サービス提供側モバイルノードとを接続する、前記無線ネットワークの経路上の少なくとも１つのノードの特性を評価するものである、請求項１から４のいずれか一項に記載の方法。
6. 前記サービス要求側モバイルノードにおいて、モバイルピアツーピアネットワークプロトコルレベルで、探索要求を評価するステップをさらに含み、前記探索要求の評価が、モバイルピアツーピアサービスをさまざまなタイプに分類した内容に基づくものである、請求項１に記載の方法。
7. 前記層間通信チャネルプロトコルの使用が、モバイルピアツーピアアプリケーションレベルで動作する第１の部分（ＭＰＣＰ７）と、前記拡張ネットワーク層ルーティングプロトコルレベルで動作する第２の部分（ＭＰＣＰ３）とに分割できるものである、請求項１に記載の方法。
8. 前記層間通信チャネルプロトコルの前記第１の部分と、前記第２の部分との間でメッセージを交換することを特徴とする請求項７に記載の方法。
9. モバイルピアツーピアアプリケーションと拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）との間で、層間通信チャネルプロトコル（ＭＰＣＰ）を使用する層間通信ユニットと、
   前記モバイルピアツーピアアプリケーションと前記拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）との間で、全ての入出力メッセージを、ファイル交換を除いて、交換する交換ユニット（４２、４４）と、
   モバイルピアツーピアネットワークプロトコルの上で稼動するモバイルピアツーピアサービスから、サービスを提供するモバイルノードと該サービスの提供を受けるモバイルノードとの間のホップ制限を含んだ探索基準を含むサービス要求を受信することができる第１のインターフェースユニット（１８）と、
   無線ネットワーク内の共有サービスリソースを特定するために、前記サービス要求を、拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）に転送することができる第２のインターフェースユニット（２２）であって、前記特定は、前記探索基準を含んだ前記拡張ネットワーク層ルーティングプロトコルに基づいて、照会項目を展開することにより行われるものである、第２のインターフェースユニット（２２）と、
   前記拡張ネットワーク層ルーティングプロトコルに従って、前記探索基準を照会メッセージに変換することができる変換ユニット（２０）と、
   サービス提供側のモバイルノードを特定するために、前記拡張ネットワーク層ルーティングプロトコルを用いて、前記照会メッセージを前記無線ネットワーク内の少なくとも１つの別のモバイルノードと交換することができる第３のインターフェースユニットと
   を備え、
   無線ネットワークのモバイルノードをルーティングするために提供されている前記拡張ネットワーク層ルーティングプロトコルと、モバイルピアツーピアネットワークプロトコルとを含むプロトコルスタックが動作しており、
   前記ピアツーピアネットワークプロトコルが、前記拡張ネットワーク層ルーティングプロトコルの上位で動作するものである、
   無線ネットワーク内で動作するモバイルノード。
10. 前記変換ユニット（２０）が、探索関連データをデータの探索に関連した照会メッセージ（ＳＲＥＱ、ＨＲＥＱ）に変換することができ、前記変換ユニットが、前記探索関連データを探索データについてのファイルサイズと特性についての情報とを指定する照会メッセージ（ＨＲＥＱ）に変換するものである、請求項９に記載のモバイルノード。
11. 前記第１のインターフェースユニット（１８）が、前記拡張ネットワーク層ルーティングプロトコル（ＥＤＳＲ）に従って前記モバイルノードに登録されている少なくとも１つのピアツーピアアプリケーションに対して、前記照会メッセージを転送することと、
    前記第１のインターフェースユニット（１８）が、探索基準が満たされたかどうかの評価を前記ピアツーピアアプリケーションから受信することと、
    探索基準が満たされた場合に、前記第３のインターフェースユニットが、探索が起動された前記無線ネットワーク内のサービス要求側モバイルノードに対して探索応答を送ることと
    を特徴とする請求項９または１０に記載のモバイルノード。
12. 前記第３のインターフェースユニットが、探索応答を受信し、前記探索応答のうちＦＲＥＰが、送信側ノードと、前記探索応答を送る応答側ノードとを接続する前記無線ネットワーク内の経路情報を含み、前記経路情報が、探索の後に行われるデータ交換中に、前記第２のインターフェースユニットによって使用されるものである、請求項１１に記載のモバイルノード。
13. 前記探索応答を複数受信したときに、さまざまな探索結果を評価することができる評価ユニット（２６）をさらに含み、前記評価ユニット（２６）が、前記サービス要求側モバイルノードと、サービス提供側モバイルノードとを接続する前記無線ネットワーク内の経路上の少なくとも１つのモバイルノードの特性を反映した少なくとも１つの所定の費用関数を処理するものである、請求項１１または１２に記載のモバイルノード。
14. モバイルピアツーピアネットワークプロトコルレベルにおいて、前記探索要求を評価することができるさらなる評価ユニット（３０）と、評価の基礎として、モバイルピアツーピアサービスをさまざまなタイプに分類したものを記憶するメモリユニットとを含むものである請求項９に記載のモバイルノード。
15. 交換ユニットが、モバイルピアツーピアアプリケーションレベルで動作する上位層ユニット（４２）と、前記拡張ネットワーク層ルーティングプロトコルレベルで動作する下位層ユニット（４４）とを含むものである、請求項９に記載のモバイルノード。
16. 前記照会メッセージが、少なくともサービス確認、またはサービス登録、またはデータ探索、またはサービス要求、またはサービス応答に関連しているものである、請求項９または１５に記載のモバイルノード。
17. 無線ネットワーク内のノードをルーティングするために提供されている拡張ネットワーク層ルーティングプロトコルを伴うプロトコルスタックが動作しており、
    さらに、無線ネットワーク内通信のためのモバイルピアツーピアネットワークプロトコルをサポートするように動作しており、
    プログラムが、前記プロトコルスタックが動作しているモバイルノードのプロセッサ上で実行されるときに、請求項１から８のいずれか一項に記載のステップを実行するソフトウェアコード部分を含む、
    モバイルノードの内部メモリに直接読み込み可能なコンピュータプログラム。

Images