(57)【要約】      （修正有）【課題】無線マルチホップアドホックネットワークにおけるピアツーピアサービス発見を改善する技術を提供する。【解決手段】保存及び転送メッセージング原理に基づいて組織化された無線ピアツーピアネットワークにおけるサービスの提供に関し、特に、無線マルチホップアドホックネットワークにおいて、要求されたリモートサービスの利用可能性を判定するために必要である、低プロファイルで低オーバヘッドのサービス発見情報を提供するサービス発見プロトコルを実現する。【選択図】図５Ａ
2006171917.tif 000002
【特許請求の範囲】
【請求項１】
ピアツーピアベースの無線マルチホップアドホックネットワークにおいて、サービス発見情報及び要求されたリモートサービスの利用可能性を判定するための他のデータを提供する情報提供方法において、
上記ネットワーク内のサービスプロバイダによって隣接するピア（Ｎｌ）に提供されるリモートサービスについて言及する受信されたサービス告知メッセージ（Ｍｉｋ）を配信するステップと、
古くなった及び無関係のメッセージ（Ｍｉｋ）を削除するステップ（Ｓ１ｂ）とを有する情報提供方法。
【請求項２】
上記ピア（Ｎｉ）により、
上記サービス告知メッセージ（Ｍｉｋ）を受信するステップ（Ｓ１ａ）と、
該ピア（Ｎｉ）によって既に受け取られている古いサービス告知メッセージ（Ｍｉｋ）と同じであるメッセージ（Ｍｉｋ）を削除し（Ｓ１ｂ）、該ピア（Ｎｉ）に割り当てられているローカルメッセージプール（Ｐｉ）に新たなサービス告知メッセージ（Ｍｉｋ）を累加するステップと、
該ピア（Ｎｉ）によって受信した各サービス告知メッセージＭｉｋに関連値（ｒｉｋ）をタグ付けするステップと、
ローカルメッセージプール（Ｐｉ）に保存されている全てのサービス告知メッセージ（Ｍｉｋ）の関連値（ｒｉｋ）を加算し、累積的な関連値（Ｒｉ）を生成するステップと、
この累積的な関連値（Ｒｉ）が所定の関連性閾値（Ｒｔｈ，ｉ）を超えると、全てのサービス告知メッセージ（Ｍｉｋ）を集め、ローカルメッセージプール（Ｐｉ）に保存し（Ｓ４ａ）、該集められたサービス告知メッセージ（Ｍｉｋ）を該ピア（Ｎｉ）に隣接する全てのピア（Ｎｌ）に送信するステップ（Ｓ４ｂ）とを有することを特徴とする請求項１記載の情報提供方法。
【請求項３】
モバイルピア（Ｎｉ）に割り当てられているローカルメッセージプール（Ｐｉ）の関連性閾値（Ｒｔｈ，ｉ）を固定ピア（Ｎｊ）に割り当てられているローカルメッセージプール（Ｐｊ）の閾値（Ｒｔｈ，ｊ）より高い値に設定するステップ（Ｓ５）を更に有する請求項２記載の情報提供方法。
【請求項４】
上記関連性閾値（Ｒｔｈ，ｉ）を外部の条件に従って動的に変更するステップを更に有する請求項３記載の情報提供方法。
【請求項５】
上記ネットワーク内で利用可能なサービスを告知する第１のピア（Ｎｉ）によって、
隣接している第２のピア（Ｎｌ）が小さな電力で動作し、及び／又はネットワーク内の様々なリソースの利用可能性に関する他の情報及び／又は上記第１のピア（Ｎｉ）とその上記隣接しているピア（Ｎｌ）との間のリンクの特徴が変更されているか否かを判定するステップ（Ｓ６ａ）と、
上記判定の結果が肯定的である場合、上記隣接するピア（Ｎｌ）に不要なメッセージ（Ｍｉｋ）が送信されることを回避するために、対応する上記第１のピア（Ｎｉ）のサービス告知メッセージプール（Ｐｉ）の閾値（Ｒｔｈ，ｉ）を高めるステップ（Ｓ６ｂ）とを有することを特徴とする請求項４記載の情報提供方法。
【請求項６】
上記第１のピア（Ｎｉ）によって、
該第１のピア（Ｎｉ）に割り当てられるローカルメッセージプール（Ｐｉ）に保存されたサービス告知メッセージ（Ｍｉｋ）の数（Ｋｉ）が所定の閾値（Ｋｔｈ，ｉ）を超えた場合、受信され、集められたサービス告知メッセージ（Ｍｉｋ）を上記隣接する全てのピア（Ｎｌ）に送信するステップ（Ｓ４ｂ’）を有する請求項５記載の情報提供方法。
【請求項７】
上記第１のピア（Ｎｉ）によって、
最後のサービス告知メッセージ（Ｍｉｋ）の受信から経過した時間（Δｔｉｋ）が所定の期間閾値（Δｔｔｈ，ｉ）を超えた場合、受信され、集められたサービス告知メッセージ（Ｍｉｋ）を隣接する全てのピアに送信するステップ（Ｓ４ｂ”）を有する請求項５記載の情報提供方法。
【請求項８】
上記第１のピア（Ｎｉ）によって、
サービス告知メッセージ（Ｍｉｋ）が近いピア（Ｎｌ）には、高速に伝播され、上記第１のピア（Ｎｉ）から遠くのピア（Ｎｌ）には、遅く伝播されるように、各関連値（ｒｉｋ）から、サービス告知メッセージ（Ｍｉｋ）が伝播されたホップの数が大きくなるほど高くなる関連性低下率（ｄｉｋ）によって与える低下の割合を減算することによって、受信したサービス告知メッセージ（Ｍｉｋ）の関連値（ｒｉｋ）を再計算するステップ（Ｓ７）を有する請求項１乃至７いずれか１項記載の情報提供方法。
【請求項９】
上記第１のピア（Ｎｉ）によって、
上記ネットワーク内で上記隣接するピア（Ｎｌ）の利用可能性を監視するステップ（Ｓ８ａ）と、
上記ピア（Ｎｌ）が上記ネットワークに存在しなくなり、その結果、そのピア（Ｎｌ）がホストするサービスが利用可能ではなくなった場合、上記ネットワーク全体に、これらのサービスの停止を伝播するステップとを有する請求項１乃至８いずれか１項記載の情報提供方法。
【請求項１０】
上記第１のピア（Ｎｉ）によって、
該第１のピア（Ｎｉ）に割り当てられているローカルメッセージプール（Ｐｉ）のコンテンツが上記隣接するピア（Ｎｌ）のいずれか又はそれらのうちの複数に送信される場合、上記隣接するピア（Ｎｌ）には、伝播すべき、サービス告知メッセージ（Ｍｉｋ）に関する、これらのデータを受け取る隣接しているピアがメッセージ（Ｍｉｋ）について特に興味があるものであるか否かを判定できるよう、少なくともサービス識別子と、サービスをホストするピア（ＮＨ）のアドレスと、メッセージ識別子とを含む短い概要を供給するステップを有する請求項１乃至９いずれか１項記載の情報提供方法。
【請求項１１】
上記第１のピア（Ｎｉ）によって、
興味がある特定のサービスの利用可能性に関する情報を含んでいるローカルサービステーブルについて、これらのサービスをホストするピア（ＮＨ）に対し、先見的に問い合わせを行うステップ（Ｓ１０ａ）と、
ローカルで利用可能なサービスがない場合、マルチホップアドホックネットワーク内で要求されたサービスの利用可能性を判定するために必要であるサービス発見情報を提供するためにサービス発見プロトコルを実行するステップ（Ｓ１０ｂ）と、
興味がある幾つかのサービスが既知になると、これらのサービスに関するより多くの詳細情報を検索するステップ（Ｓ１０ｃ）とを有する請求項１乃至１０いずれか１項記載の情報提供方法。
【請求項１２】
請求項１乃至１１いずれか１項記載の情報提供方法を実現するよう設計されたソフトウェアプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ピアツーピアネットワーク（wireless peer-to-peer networks）の分野に関し、詳しくは、例えば、家庭用及び個人的な用途の環境で動作するように設計されている無線マルチホップアドホックネットワークにおいて、要求されたリモートサービスの利用可能性を判定するために必要である、低プロファイル（low-profile）で低オーバヘッド（low-overhead）のサービス発見情報を提供するサービス発見プロトコル及びこれに対応する方法に関する。
【背景技術】
【０００２】
新たな個人用のネットワーク対応型モバイル機器（ＭＤプレーヤやカムコーダ等）が普及し、並びに有線及び無線ネットワークに基づく、略々ユビキタスな通信インフラストラクチャの登場により、ユーザとアプリケーションが、構成又は管理を行うことなく、既存のサービスとインタラクトできるようにすることが益々重要になってきている。このようなメカニズムを実現するためには、主に、新たなサービスが自らの存在及び特性を広告できるようにし、サービスユーザが必要なサービスを発見し利用できるようにすることが必要である。これらのタスクは、サービス発見プロトコル（service discovery protocols）によって実現される。
【０００３】
サービス発見プロトコルにより、サービスプロバイダは、潜在的クライアントに自らの能力の広告をすることができ、これにより、クライアントとサービスプロバイダは、モバイル及び無線のネットワークにおいて、関係を持ち、主要な役割（key role）を果たすことができるようになる。サービス発見を扱う既存のプロトコルとしては、例えば、ＩＥＴＦのサービスロケーションプロトコル（Service Location Protocol：以下、ＳＬＰという。）、サンマイクロシステムズ社（Sun Microsystems）のＪｉｎｉ（登録商標）、ブルートゥースのサービス発見プロトコル（Service Discovery Protocol：以下、ＳＤＰという。）、現在幾つかの製品において利用されている一般に公開されたサービス発見プロトコルであるサリュテーション（Salutation）（登録商標）、マイクロソフト社（Microsoft）が推奨するユニバーサルプラグアンドプレイ（Universal Plug and Play：以下、ＵＰｎＰという。）プロトコル等がある。
【０００４】
今日の最先端のサービス発見プロトコルを用いて、無線マルチホップアドホックネットワーク内でサービスを発見するタスクは、多くのリソースを消費するタスクである。これは、これらのプロトコルは、多くの場合、無線マルチホップアドホックネットワークの特定の特性には不向きな同報通信又は集中制御構造を適用するためである。したがって、例えば、アプリケーションがリモートリソース（サービス）を用いて、何らかの機能性をユーザに提供できるような、何らかのスマートで、分散型のネットワークの機能を実現する必要がある。以下では、家庭用又は個人用のネットワークシナリオで用いられるサービス発見プロトコルに対する要求を明らかにし、及びそのために可能なプロトコルについて検討する。
【０００５】
無線マルチホップアドホックネットワークにおけるサービス発見のためには、幾つかの境界条件（boundary conditions）を考慮に入れなくてはならない。これらの境界条件は、いずれも、目標環境（target environment）内で動作しなければならない全てのサービス発見プロトコルによってカバーされている必要がある要求アイテムとして表現される。サービス発見プロトコルは、目標環境によって与えられるシナリオとは異なるシナリオで動作可能であってもよいが、サービス発見プロトコルは、このシナリオにおいて最適な動作を提供するように構築するべきである。
【０００６】
目標環境のアドホック的性質のため、適用される如何なるサービス発見プロトコルも、ノードがネットワークに持続的に参加したり、ネットワークから外れたりすることができる可変のネットワークトポロジにおいて動作可能である必要がある。ノードがネットワークにどのくらい持続的に（固定的又は移動的に）参加しているかを示していたとしても、その参加期間は必ずしもある継続時間続くものとは限らない。したがって、如何なるサービス発見プロトコルも、１つの障害点も有することなく（すなわち、如何なる中心コンポーネントも有することなく）動作する必要がある。
【０００７】
典型的なマルチホップアドホックネットワークにおいて、ネットワーク全体に同報通信メッセージを送信することは、使用されるリソースを鑑みると、高コストである。更に、帯域幅は、貴重なリソースであるため、発見要求に対する高い反応性を維持するとともに、使用される帯域幅は、最小限にするべきである。如何なるサービス発見プロトコルも、同報通信メッセージの伝送を避け、背景トラヒックの量を減少させることによって、この点を考慮する必要がある。
【０００８】
アドホックネットワーク環境において生じる可能性がある他の問題として、ネットワークパーティション（network partition）及び再参加（rejoin）の問題がある。サービス発見プロトコルは、このシナリオを効率的に且つ高速に処理する必要がある。
【０００９】
例えば、ホームネットワークでは、ユーザ側による如何なる構成処理もできないようにする必要がある。ソフトウェアは、モバイルコードを有さなければ、容易にアップグレードできない。一旦、システムが実用化されると、そのシステムは、かなり長い期間に亘って用いられると考えられる。
【００１０】
そこで、全てのサービス発見プロトコルについて、実現するべき幾つかの典型的な要求がある。以下の各項目について、これらが、上述した境界条件下で動作することを確実にする必要がある。
・サービスの発見：サービス発見プロトコルに対する非常に基本的な（そして最も明白な）要求は、ネットワークにおいて、興味があるサービスを発見することである。幾つかのアプリケーションにおいては、更に、ネットワーク上のサービスに関して、最新の情報を維持し、これによりサービスの発見だけではなく、サービス及び可能であればサービスの状態を監視することが要求されることもある。更に、例えば、サービスが満たす属性の不完全なリストを提供することによってサービスを発見することにより、分散的にクエリを実行することも可能である。
・一貫性がある単純なサービス記述：サービス発見の一部として、通信プロトコルだけではなく、データ形式も指定する必要がある。これらのフォーマットは、矛盾と曖昧さを防ぐために必要である。
・変化への速やかなセットアップと反応：如何なるサービス発見プロトコルも、ネットワークにおける変化に対する迅速な反応を実現するよう努力し、すなわち、新たに導入されたサービスは、可能な限り速やかに、他のノードに告知される。待ち時間を最小にすると、ネットワーク（最終的にユーザ）の体感的な速度に影響する。この問題は、ネットワークトポロジの変化が、例外的であるよりはむしろ規則的であるアドホック環境において特に明白である。
【００１１】
上述のように、解決すべき課題は、上述の境界条件下で要求された機能を実現する必要性として簡潔に要約することができる。
【００１２】
・発行／購読型のサービス発見プロトコル対要求／応答型のサービス発見プロトコル：発行／購読型プロトコルが適用されている場合、ネットワークは、あるソース又はチャンネルにおいて、専用サービス発見メッセージを登録する。これらのメッセージは、それぞれサービスが利用可能になった場合、又はもう存在していない場合に送信される。応答／要求型の発見プロトコルでは、サービスは、クライアントが明示的に要求した場合のみ、検索される。この場合、サービス利用可能性に関する情報は、告知されない。したがってサービスの利用可能性を監視するためには、ネットワーク内の全ての（又は特定の幾つかの）サービスを周期的にポーリングする必要がある。勿論、ハイブリッド的な手法（上述した２つの手法の組合せ）を用いてもよい。
【００１３】
ａ）ユニバーサルプラグアンドプレイ（ＵＰｎＰ）
ユニバーサルプラグアンドプレイは、マイクロソフト社主導の業界団体によって採用されているオープンネットワークアーキテクチャである。ＵＰｎＰは、異なるサービスと機器について、アドホックピアツーピアネットワーク接続を提供する。
【００１４】
ｂ）サービスロケーションプロトコル（ＳＬＰ）
サービスロケーションプロトコル（http://www.srvloc.org/参照）は、ＩＥＴＦが提案するサービス発見プロトコルである。これは、Ｓｒｖｌｏｃワーキンググループ（Srvloc Working Group）によって開発され、ベンダから独立した規格である。ＳＬＰは、ＴＣＰ／ＩＰネットワークのために設計されており、インターネットの分野における標準規格となるよう意図されている。ＳＬＰの現在のバージョンは、ＳＬＰｖ２である。ＳＬＰアーキテクチャは、基本的に、ユーザエージェント（ＵＡ）、サービスエージェント（ＳＡ）、ディレクトリエージェント（ＤＡ）の３つのメンバから構成されている。
【００１５】
ｃ）サリュテーション
サリュテーションアーキテクチャは、サービス発見と使用上の問題に関する業界団体による解決策の１つである。このアーキテクチャは、アプリケーション、サービス及び機器、すなわち、所謂ネットワークエンティティに対し、自らの能力を広告し、又は所望の能力を要求するための標準化された手法を提供する。この規格は、プロセッサ、オペレーティングシステム、及び通信プロトコルから独立している。この規格の要部は、サリュテーションマネージャ（Salutation Manager：以下、ＳＬＭという。）である。全てのネットワークエンティティは、ＳＬＭを備え、又は、リモートプロシージャコール（Remote Procedure Call：以下、ＲＰＣという。）プロトコルを用いてリモートのＳＬＭを使用する。ＳＬＭは、転送独立インタフェース（ＳＬＭ−ＡＰＩ）をサービス及びクライアントに提供する。ネットワークエンティティは、サービス、クライアント又はその両方として動作できる。異なるＳＬＭ同士は、ＲＰＣに基づいて、サリュテーションマネージャプロトコルを用いて通信を行う。
【００１６】
ｄ）Ｊｉｎｉ
Ｊｉｎｉは、サンマイクロシステムズ社によって開発されたサービス指向のＪａｖａ（登録商標）ベースのアーキテクチャ（インフラストラクチャ及びプログラミングモデル）である。Ｊｉｎｉのアーキテクチャは、Ｊｉｎｉルックアップサービス（Jini Lookup Service：以下、ＪＬＳという。）コンポーネントに基づいている。サービスは、発見プロトコルを用いてＪＬＳサーバの場所を発見し、参加プロトコルを用いて自らをＪＬＳに登録する必要がある。また、クライアントは、ＪＬＳを発見し、利用可能なサービスに関する問い合わせを行うことができる。クエリとサービスの間の照合は、Ｊａｖａインタフェース又は特徴的な属性のリストを比較することによって行うことができる。各サービスは、一定の期間だけ、すなわち、リース期間の間だけ、ＪＬＳによって維持される。これにより、登録されていないサービスがレジスタから排除される。
【００１７】
ｅ）ブルートゥース
ブルートゥース対応のパーソナルエリアネットワーク（personal area network：以下、ＰＡＮという。）は、大型のマルチホップネットワークから構成され、ここでは、モバイル機器は、単一のピコネット上に存在しているマスタノードを介して他のモバイル機器と通信できるだけではなく、複数の中間ノードを介して到達できる無線ノードとも通信できる。これにより、モバイル機器は、通信を行い、他のモバイル機器又はインフラストラクチャシステムによって提供されるサービスを利用できる。モバイル端末がこれらのサービスを利用できるようにするために、サービスプロバイダは、何らかの基本構成情報と共に全ての利用可能なサービスを発行する必要があり、サービスユーザは、これらのサービスを検索し、特定のサービスプロバイダを選択するための手段を有している必要がある。このため、ブルートゥースサービス発見プロトコル（ＳＤＰ）は、利用可能なブルートゥースサーバによって提供されるサービスを発見するために、ブルートゥースクライアントのアプリケーションシェルがどう行動するか及びそれらの特性を定義する。したがって、ＳＤＰにより、クライアントアプリケーションは、例えば、ＳＬＰ、サリュテーション等の他の発見プロトコルを用いてサービスにアクセスすることができる。但し、これらは必ずしも必要ではない。このプロトコルは、クライアント端末が、サービスの利用可能性に関する知識を有することなく、特定の属性に基づいて、リモートサービスをどのように検索するかを定義する。このプロトコルは、クライアント端末がブルートゥースサーバの動作範囲内に入ったときに、利用可能になった新たなサービスを発見するための手段を提供する。また、ＳＤＰは、サービスが利用可能ではなくなったことを検出する機能も提供する。
【００１８】
ＳＤＰクライアントを備える機器は、クラス又は属性の幾つかを指定するサービスを検索でき、また、この機器は、サービスの特性に関する知識を有することなく、そのサービスを検索することもできる。続いて、リモートＳＤＰサーバがこれらの照会に応答する。機器は、新たなサービスの利用可能性を検知できなくてはならず、また、既知のサービスが利用可能ではないことについても知る必要がある。仲介エージェント（intermediary agent）をキャッシュとして用いて、システムの効率を高めてもよい。
【００１９】
米国特許公開公報２００２／０１２０７５０Ａ１号には、例えば、アドホックブルートゥースＰＡＮ等、複数のマルチホップネットワークからなる一般的な無線ローカルエリアネットワークにおいて、サービス発見を実行するための方法、無線ネットワーク機器及びコンピュータプログラム製品が開示されている。
【００２０】
米国特許公報６，３９７，０６１Ｂ１号には、短距離モバイルアドホックネットワーク（mobile ad-hoc network：ＭＡＮＥＴ）において、所定の通信範囲内でローカルな無線ネットワークと通信する無線通信機器に適用されるデータ転送の優先順位を再決定するための方法及び装置が開示されている。
【００２１】
米国特許公開公報２００１／０００３１９１Ａ１号には、少なくとも１つの通信ネットワークにおいて、マルチメディアアプリケーションを動作させる通信装置及びソフトウェアが開示されている。
【００２２】
欧州特許公開公報１２２７６８９Ａ１号には、ローカルサービスの発見処理において、モバイル機器をサポートするためのエントリゲートウェイサーバが開示されている。
【００２３】
欧州特許公開公報１０２２８７６Ａ１号には、少なくとも２個のモバイル端末を含む無線ローカルエリアネットワークにおいて、サービスを広告するための方法、及び他のモバイル端末とサービス情報を交換する装置が開示されている。
【００２４】
欧州特許公開公報１０２４６２８Ａ１号には、装置に近接するサービス提供装置によって提供されるサービスと、装置に近接しないサービス提供装置によって提供されるサービスとを区別するためのスキーム及び装置が開示されている。
【００２５】
国際特許公開公報ＷＯ０２／０８４９７５Ａ２号には、サービスブックをモバイル機器に送信するために必要な無線データ通信装置上のホストサービスを動的に発見し、サービスを提供し、サービスにアクセスするための高度なシステム及び方法が開示されている。
【００２６】
国際特許公開公報ＷＯ０２／２３８２６Ａ２号には、サービス発見及び接続をサポートするサービスフレームワークが開示されており、詳しくは、リモート及びローカルの、並びに一時的及び持続的な様々なサービスを発見し、これに接続し、及びこれらのサービスが不要となったとき、又はこれらのサービスが利用可能ではなくなったとき、これらのサービスから切断するためのサービスフレームワークを含むクライアントプラットフォームを備えるユーザ機器を有する情報家電システムが開示されている。
【００２７】
国際特許公開公報ＷＯ０２／４５３８２Ａ２号には、ブルートゥース対応機器等の無線送受信機の仮想シリアルポート上で動作するアプリケーション（例えば、旧型のアプリケーション）のためのサービス記録を提供する方法及び装置が開示されている。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
本発明の目的は、無線マルチホップアドホックネットワークにおけるピアツーピアサービス発見を改善する技術を提供することである。
【課題を解決するための手段】
【００２９】
この目的は、独立請求項として示す技術によって解決される。更に有利な特徴は従属請求項において定義されている。本発明の更なる目的及び利点は、以下に示す好ましい実施の形態において開示されている。
【００３０】
本発明は、例えば、家庭用及び個人的な用途の環境で動作するように設計されている保存及び転送メッセージング原理（store-and-forward messaging principle）に基づいて組織化された無線マルチホップアドホックネットワークにおいて、要求されたリモートサービスの利用可能性を判定するために必要である、低プロファイル（low-profile）で低オーバヘッド（low-overhead）のサービス発見情報を提供するサービス発見プロトコル及びこれに対応する方法を提供する。
【００３１】
本発明の一実施例では、受信されたサービス告知メッセージを送信する。このメッセージは、ネットワーク内でサービスプロバイダによって提供されたリモートサービスについて言及する。ここでは、このピアによって既に受け取られている古いサービス告知メッセージと同じであるメッセージを削除し、新たなサービス告知メッセージは、このピアに割り当てられているローカルメッセージプールに累加される。まず、このピアが受け取った各サービス告知メッセージには、関連値によってタグを付す。次に、ローカルメッセージプールに保存されている全てのサービス告知メッセージの関連値を加算し、累積的な関連値を生成する。この累積的な関連値が所定の関連性閾値を超えると、全てのサービス告知メッセージを集め、ローカルメッセージプールに保存し、この集められたサービス告知メッセージをこのピアに隣接する全てのピアに送信する。
【発明を実施するための最良の形態】
【００３２】
全てのクライアントのアプリケーション及び／又はサービスにおける実行されているあるサービスをピアが要求した場合、基本的に、ユーザにとって興味がある可能性があるあらゆるサービスを先見的に問い合わせる、又は幾つかのチャンネルからのサービス告知を待機するといった２つの異なる可能性がある。
【００３３】
ネットワークにおいて所定の属性を有する特定のサービスを見つけるために、反応型サービス発見メカニズム（reactive service discovery mechanism）を実行してもよい。このために、データリンク制御（data link control：以下、ＤＬＣという。）層は、既に、幾つかの低いレベルのサービス発見機能を実現している。この機能を利用するために、以下のような三段階の手法を提案する。
１．まず、ローカルサービステーブルに興味がある特定のサービスを問い合わせる。
２．ローカルでは、利用可能なサービスがない場合、ＤＬＣサービス発見プロトコルを実行する。
３．一旦、興味がある幾つかのサービスが既知となると、これらのサービスに関するより詳細な情報を検索し、要求側のピアに送る。
【００３４】
更に、適用されたサービス発見メカニズムの反応を強めるために、先見的なサービスの問い合わせだけではなく、サービス告知もサポートする。ここに提案するサービス発見プロトコルの設計目標は、送信されるメッセージの数を最少にするとともに、ロバストで効率的なサービス告知機能を提供することである。これにより、無線アドホックネットワークにおいてかなり高コストである同報通信メッセージの使用が回避される。
【００３５】
本発明の一実施例では、全てのピアＮｉが、所謂サービス告知メッセージプールＰｉを実現する。ここでは、このピアＮｉが受信した全てのサービス告知メッセージＭｉｋには、関連値ｒｉｋによってタグが付される。この後、プール内の全ての関連値ｒｉｋが足し合わされ、その結果、累積的な関連値が算出される。
【００３６】
【数１】
2006171917.tif 000003
【００３７】
ここで、Ｋｉは、ピアのプールＰｉに保存されたサービス告知メッセージＭｉｋの総数を示す。一旦、累積的な関連値Ｒｉが所定の閾値Ｒｔｈ，ｉを超えると、プールＰｉの全てのメッセージが集められ、全ての隣接するピアＮｌ（ｌ≠ｉ）に送信される。この関連値ｒｉｋは、重要度が低いサービスを告知する場合には、非常に小さい値とし、より重要なサービスを告知する場合には大きな値としてもよい。これにより、ネットワーク内でメッセージが配信される速度をより精密に制御することができる。
【００３８】
適用された伝送媒体が１ホップ同報通信（one-hop broadcasting）をサポートする場合、無線ピアＮｉの近隣全体に対して、単一のサービス告知メッセージプールＰｉを用いることができる。一方、１ホップ同報通信がサポートされていない場合、又はメッセージ配信をより高精度に制御する必要がある場合、別のプールＰｊを用いてもよい。これにより、例えば、モバイルピアＮｉに割り当てられるプールＰｉの閾値Ｒｔｈ，ｉをプールＰｊの固定ピアＮｊに割り当てられる閾値Ｒｔｈ，ｊより高い値に設定することができる。また、非固定の閾値Ｒｔｈ，ｉを定義することもでき、これは、外部の条件に応じて変化できる時変閾値関数Ｒｔｈ，ｉ（ｔ）を意味する。例えば、隣接しているピアが小さな電力で動作し、及び／又はネットワーク内の様々なリソースの利用可能性に関する他の情報及び／又はピアＮｉとその隣接しているピアＮｌとの間のリンクの特徴が変更されている場合、隣接するピアＮｌに不要なメッセージＭｉｋが送信されることを回避するために、対応するピアＮｉのサービス告知メッセージプールＰｉの閾値Ｒｔｈ，ｉが高められる。
【００３９】
固定ピアＮｊ上の累積的な関連値Ｒｊ：＝Σｋｒｊｋは、所定の閾値Ｒｔｈ，ｊを超えてはならないが、モバイルピアＮｉは、それらの閾値Ｒｔｈ，ｉの値として任意の値を自由に選ぶことができる。この閾値Ｒｔｈ，ｉを「無限」に設定することは、如何なるメッセージも送信しないことを意味し、この値をゼロにすることは、全てのメッセージＭｉｋを即時に再送することを意味する。
【００４０】
効率的な実行を実現するために、サービス告知メッセージを伝播するための基本プロトコルは、比較的単純である。本発明では、原則として、サービス告知処置に参加する全てのピアにおいて、以下のステップを実行する必要がある。
１．如何なるサービス告知も、更なる整数関連パラメータｒｉｋ及び０〜１００％の間の実数で評価された関連性低下率（relevance degeneration rate）ｄｉｋとに基づいて実行される。
２．サービス告知メッセージＭｉｋが、以前にピアＮｉ上で確認されたものである場合、そのサービス告知メッセージＭｉｋは、破棄される。これ以外の場合、受け取られたサービス告知メッセージＭｉｋのプールＰｉにこのピアを含めることによって、メッセージは、このピアにおいてローカルに保存される。
３．この後、このプールＰｉ内に保存されたサービス告知メッセージＭｉｋに割り当てられている全ての関連値ｒｉｋを加え、これにより累積的な関連値Ｒｉ：＝Σｋｒｉｋを生成する。累積的な関連値Ｒｉが所定の閾値Ｒｔｈ，ｉを超えた場合、サービス告知メッセージＭｉｋは、集められ、このピアＮｉに近接する全てのピアに送信される。また、プールＰｉ内のサービス告知メッセージＭｉｋの数Ｋｉが所定の閾値Ｋｔｈ，ｉを超えた場合、又は最後のサービス告知メッセージＭｉｋの受信から経過した時間Δｔｉｋが所定の期間閾値Δｔｔｈ，ｉを超えた場合にも同様の処理が行われる。これらの条件は、以下のように要約することができる。
【００４１】
【数２】
2006171917.tif 000004
【００４２】
４．サービス告知メッセージＭｉｋを受け取る如何なるピアＮｉもそのローカルプールＰｉにサービス告知メッセージＭｉｋを含める。更に、このピアＮｉは、各関連値ｒｉｋから、関連性低下率ｄｉｋによって与えられる低下の割合を減算することによって入力メッセージの関連値ｒｉｋを再計算する。
【００４３】
【数３】
2006171917.tif 000005
【００４４】
関連値ｒｉｋの低下により、最初は高い関連値ｒｉｋを有し（したがって、ネットワーク中で高速に送信され）、幾つかのホップの後に「重要度が低下する」メッセージＭｉｋを作成することができる。このように、サービス告知メッセージＭｉｋは、近隣のピアには高速に伝播され、遠くのピアには、ゆっくり伝播される。
【００４５】
送信される全てのメッセージＭｉｋは、サービス識別子（又はサービス記述子）、メッセージ識別子、サービスをホストするピアＮＨのアドレスを含んでいる。メッセージ識別子は、メッセージＭｉｋがタグ付けをされた後にインクリメントされるピアの内部のカウンタから作成される。ピアＮｉは、新たなメッセージＭｉｋを受け取った場合、常に、所定のピアからの所定のサービス識別子を有する最後に受け取ったメッセージＭｉ，ｋ−１を確認する。保存されているメッセージ識別子が新たなメッセージＭｉｋのメッセージ識別子より新しい場合、この新たなメッセージは、破棄される。
【００４６】
更に利用可能な各サービスは、利用可能なサービスを再告知すべき期間を定めるリースタイムアウトに関連付けられる。このメカニズムは、サービステーブル内に古いエントリが残ることを避けるために用いられる。
【００４７】
サービス利用可能性の告知は、無線マルチホップアドホックネットワークに接続されたクライアント端末に知らせる必要があるサービスが、自らをローカルのピアＮｉに登録したときにトリガされる。したがって、如何なるサービス利用可能性告知メッセージＭｉｋも、ピアのサービス告知メッセージプールＰｉに含まれるだけではなく、ローカルサービステーブルの更新の必要性を生じさせる。
【００４８】
同様に、サービスの利用可能性を他のピアに知らせるとともに、サービスの停止もネットワーク全体に亘って伝播させる必要がある。原理的には、サービスの停止を告知する主な理由は、サービスがピアに登録されていないためである。ピアが既にネットワークに存在しなくなり、したがって、そのピアによってホストされていたサービスも利用不可能となる状況は、無線のピアの利用可能性を監視することによって処理される。メッセージを告知するための総合的な処理としては、上述した処理と同様のものを用いることができる。
【００４９】
ピアに関する情報から、ネットワークに存在していない古くなったエントリを取り除くために、サービス発見プロトコルにピアの消滅を示すメカニズムを加える。このメカニズムは、既に上述したリースメカニズム（leasing mechanism）をサポートする。
【００５０】
隣接する新たなピアＮｊが出現すると、サービステーブル及びこのピアによって提供されるサービスの管理データ（例えば、メッセージカウンタ）が要求される。返されたサービスは、それらが既に処理されているものであるか否かが確認される。このサービスが既に処理されているものではない場合、それらは各ピアＮｉのローカルメッセージプールＰｉに加えられる。この結果、ネットワークの変化によって、メッセージの交換がトリガされ、これは、ネットワークにおけるメッセージの全体的な利用可能性に寄与する。不要なメッセージの送信を回避するために、後述する折衝手続（negotiation procedures）を適用することができる。
【００５１】
この折衝手続によって生じるメッセージオーバヘッドを避けるために、ネットワークに参加する新たなピアは、その隣接するピアの１つ（又は、幾つか）の状態のクローンを作ることだけが許可される。
【００５２】
ここまで、先見的なサービス存在情報の伝播のみを説明した。勿論、サービス要求を他のノードに転送するために、所定のプロトコルを用いてもよい。
【００５３】
無線のピアに隣接するピアのいずれか（又は複数のピア）にプールコンテンツを送信する場合、常に、送信されるメッセージの短い概要（アウトライン）が配信される。送信される情報には、（少なくとも）サービス識別子、サービスをホストするピアＮＨのアドレス、及びメッセージ識別子が含まれる。この情報に基づき、如何なるピアもそのメッセージがそのピアにとって興味があるものであるか否かを判定することができる。したがって、ピアＮｉがピアＮｉ＋１にメッセージＭｉｋを提供する場合、以下のオプションが利用可能である。
１．このメッセージＭｉｋがピアＮｉ＋１にとって興味があるものではない場合、ピアＮｉ＋１は、ピアＮｉに対し、このメッセージを削除するよう要求できる。
２．メッセージＭｉｋがピアＮｉ＋１にとって興味があるものであるが、Ｎｉ＋１がそのメッセージを受け取ることを未だ望んでいない（すなわち、ピアＮｉ＋１がスリープモードに入り、更なるメッセージを処理しない）場合、ピアＮｉ＋１は、ピアＮｉに対し、このメッセージを保存し、後に送信するよう要求できる。
３．ピアＮｉ＋１は、ピアＮｉの１つ（Ｍｉｋ）を無効にする更新されたメッセージＭｉ＋１，ｋを有していてもよい（例えば、ピアＮｉは、サービス告知の送信を望むがピアＮｉ＋１は、各サービスが利用可能ではなくなっていることを既に知っている場合等に用いられる）。この場合ピアＮｉ＋１は、更新されたメッセージＭｉ＋１，ｋをピアＮｉに提供する。
【００５４】
無線マルチホップアドホックネットワーク内では、同時に多くのサービスが利用可能である場合がある。それらの幾つかは、集合的サービス（conglomerate service）とみなされることがある（例えば、テレビジョンの制御装置と、周辺制御サービスとは、１つの家庭用娯楽サービスとみなすことができる）。サービス利用者がこのような集合的サービスの発見を望んでいる場合、このような集合的サービスをクエリ内で特定できるようにしてもよい。集合的サービスを特定のサービスに分解し、ネットワーク内でそれらを発見する処理は、本発明に基づくサービス発見プロトコルによって実行される。このために集合的サービスへの要求は、ネットワーク内に拡散し、このサービスに貢献することを望む各ピアは、対応する応答を返信する。これらの応答は、要求側のピアに集められ、集合的サービスを実現できるか否かが判定される。
【００５５】
サービス記述の基礎としては、キー／値の組だけがサポートされる。これらは、キー（属性）値を割り当てることによって、サービスを記述することを可能にする。所定のプロトコルによっては、基本サービス発見メカニズムだけが実現されるので、この情報は、十分である。例えば、ＵＰｎＰにおけるサービス記述言語等、他のサービス記述言語と比べて、イベント又は状態記述等の情報は、オーバーヘッドを最小にするために故意に省略される。より高い層においてこのような機能を実現するためには、追加コンポーネント、すなわちサービス発見（ＳＤ）メタデータハンドラ２０４を導入する。このコンポーネントは、より複雑なより高い層のサービス記述機能、例えば、ＵＰｎＰのサービス記述機能と、本発明に基づいてここに提案するサービス発見プロトコル２０８（図２参照）との間で調停することができる。このために、このコンポーネントは、コアサービス記述属性を抽出し、抽出したコアサービス記述属性をサービス発見プロトコル層に渡す。一旦、サービス発見プロトコルが幾つかのサービスを発見すると、サービス発見プロトコルは、これに応じて、応答を期待されたフォーマットに組み立て直す。必要な場合、このようなメタデータハンドラ２０４により、様々なサービス発見プロトコルを所定のサービス発見プロトコル２０８にマッピングしてもよい。
【００５６】
このプロトコルは、特にサービス発見の目的のために設計されているが、基本通信スキームは、例えば、ネットワーク状態情報、機器存在メッセージ、イベントの伝播、又はデータ配信に関してリアルタイムの制約条件を有さないあらゆる種類のデータ等、他のデータに対しても好適に機能する。このようなデータは、（例えば）分散されたルーティング情報、ＱｏＳ提供をサポートし／イネーブルにする分散された情報、ネットワーク状態情報、（インスタント）メッセージデータ、センサデータ、ピア状態情報等であってもよい。
【００５７】
図３〜図６に示すＵＭＬメッセージシーケンス図３００、４００、５００、６００は、サービスを登録する処理、本発明に基づくサービスの利用可能性を示すサービスメッセージを扱う処理及びサービスを登録解除する処理を示している。図７は、本発明に基づくサービス発見プロトコル２０８によって実行される提案されたサービス発見メカニズムの概要を説明するＵＭＬ状態図７００を示している。図８は、本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図８００である。
【００５８】
ここに提案するサービス発見プロトコルの柔軟性により、以下に列挙するような、ある程度の自由度が実現される。
１．如何なるピアＮｉもサービス告知メッセージプールＰｉが、いつ、幾つの告知メッセージを含むかをローカルで判定することができる。モバイルピアＮｉ等の電力的制約を有するピアは、多くのメッセージＭｉｋを送信することを回避するするために、より大きいプールＰｉを有していてもよく、一方、固定ピアＮｊは、より小さいプールＰｊを有し、この結果、より多くのメッセージＭｉｋを送信してもよい。更に、累積的な関連値Ｒｉ（Ｒｊ）のための閾値Ｒｔｈ，ｉ（Ｒｔｈ，ｊ）は、それぞれのモバイルピア（Ｎｉ）又は固定ピア（Ｎｊ）の現在の制約に応じて設定してもよい。値自体は、それぞれのピアの現在の状態に応じて、各ピアによって動的に変更してもよい。
２．サービス告知が減衰する可能性により、利用可能なサービスは、ピアＮｉの近隣（Ｎｊ）では、速やかに告知され、より遠くのピアは、このサービスを比較的遅く知る。
３．ネットワーク全体に非常に高速に知らせる必要があるサービスは、比較的高い関連値ｒｉｋ（ｒｊｋ）によって送信し、これ以外のサービスは、より低い関連値によって送信してもよい。いずれの場合も、ネットワーク内でサービス告知メッセージＭｉｋを広める速度は、ピアＮｉ（Ｎｊ）によって容易に制御できる。
４．モバイルマルチホップアドホックネットワークを構成するピアの数の変動によって、メッセージ交換をトリガし、これは、全体的な情報の普及に貢献する。
【００５９】
なお、上述した各項目及び特にそれらの組合せのいずれも、最新技術に基づく従来のサービス発見プロトコルでは、発見することができない。
【００６０】
ここに提案するプロトコルは、例えば、家庭用及び個人的な用途のシナリオにおいて動作するよう設計されている無線マルチホップアドホックネットワークの要求に適合し、以下のような特徴を有する。
・同報通信を行わない。：無線マルチホップアドホックネットワークにおいては、同報通信は、（可能であるとしても）高価であり、電力を消費するタスクである。したがって、ここに提案するサービス発見プロトコルは、無線マルチホップアドホックネットワークにおけるサービス発見を実現する技術であるとみなすことができる。
・如何なる不要なメッセージも送信せず、これにより、トラフィックオーバヘッドを回避し、電力を節約する。：これは、特にモバイル型の電源として電池を用いるピアにおいて重要な特徴である。ここに提案するプロトコルを用いることにより、これまでの技術水準と比較して、同じ（又はより良い）機能を有しながら、消費電力が小さい機器を製造することができる。
・無線のピアに近接したピア（例えば、同じ部屋に設置されているテレビジョンセット）の最新状態をユーザに知らせ続けるので、したがって、この技術を利用することによって無線ピアのユーザは、今までにない経験をすることができる。
【００６１】
【表１】
2006171917.tif 000006
【００６２】
【表２】
2006171917.tif 000007
【００６３】
【表３】
2006171917.tif 000008
【００６４】
【表４】
2006171917.tif 000009
【００６５】
【表５】
2006171917.tif 000010
【００６６】
【表６】
2006171917.tif 000011
【００６７】
【表７】
2006171917.tif 000012
【００６８】
下層における機能を利用し、プロトコルをより単純にすることにより、必要に応じて、（少なくとも幾つかの）機能をハードウェアに容易に統合することができる。
【００６９】
本発明の更なる実施例として、本発明は、保存及び転送メッセージング原理に基づいて、ピアツーピアベースの無線マルチホップアドホックネットワークにおいて要求されたリモートサービスの利用可能性を判定するために必要なサービス発見情報を提供するプロキシサーバとして機能するピアＮｉを提供する。この場合、ピアは、上述した方法を実現するサービス発見マネージャユニット２０４を備える。
【００７０】
また、本発明は、このピアＮｉ上で実行されて、上述のサービス発見方法をサポートするよう設計されているソフトウェアプログラム製品を提供する。
【図面の簡単な説明】
【００７１】
【図１】従来のサービス発見メカニズムとプロトコルの異なる特徴、長所及び短所を比較して示す図である。
【図２】本発明に基づくメタデータベースのサービス記述の処理のために用いられる異なるピアプロトコル層を示す図である。
【図３】本発明に基づくリモートサービスを登録するためのインタラクションを示す第１のＵＭＬメッセージシーケンス図である。
【図４】本発明に基づくローカルサービスを登録するためのインタラクションを示す第２のＵＭＬメッセージシーケンス図である。
【図５Ａ】本発明に基づくリモートサービスの利用可能性を示すサービスメッセージを扱うためのインタラクションを示す第３のＵＭＬメッセージシーケンス図である。
【図５Ｂ】本発明に基づくリモートサービスの利用可能性を示すサービスメッセージを扱うためのインタラクションを示す第３のＵＭＬメッセージシーケンス図である。
【図６】本発明に基づくローカル又はリモートサービスを登録解除するためのインタラクションを示す第４のＵＭＬメッセージシーケンス図である。
【図７Ａ】本発明に基づくサービス発見プロトコル２０８によって実行されるサービス発見メカニズムを示すＵＭＬ状態図である。
【図７Ｂ】本発明に基づくサービス発見プロトコル２０８によって実行されるサービス発見メカニズムを示すＵＭＬ状態図である。
【図８Ａ】本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図である。
【図８Ｂ】本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図である。
【図１】
2006171917.tif 000013
【図２】
2006171917.tif 000014
【図３】
2006171917.tif 000015
【図４】
2006171917.tif 000016
【図５Ａ】
2006171917.tif 000017
【図５Ｂ】
2006171917.tif 000018
【図６】
2006171917.tif 000019
【図７Ａ】
2006171917.tif 000020
【図７Ｂ】
2006171917.tif 000021
【図８Ａ】
2006171917.tif 000022
【図８Ｂ】
2006171917.tif 000023
【外国語明細書】
2006171917.tif 000024
2006171917.tif 000025
2006171917.tif 000026
2006171917.tif 000027
2006171917.tif 000028
2006171917.tif 000029
2006171917.tif 000030
2006171917.tif 000031
2006171917.tif 000032
2006171917.tif 000033
2006171917.tif 000034
2006171917.tif 000035
2006171917.tif 000036
2006171917.tif 000037
2006171917.tif 000038
2006171917.tif 000039
2006171917.tif 000040
2006171917.tif 000041
2006171917.tif 000042
2006171917.tif 000043
2006171917.tif 000044
2006171917.tif 000045
2006171917.tif 000046
2006171917.tif 000047
2006171917.tif 000048
2006171917.tif 000049
2006171917.tif 000050
2006171917.tif 000051
2006171917.tif 000052
2006171917.tif 000053
2006171917.tif 000054
2006171917.tif 000055
2006171917.tif 000056
2006171917.tif 000057
【図１】
2006171917.tif 000058
【図２】
2006171917.tif 000059
【図３】
2006171917.tif 000060
【図４】
2006171917.tif 000061
【図５Ａ】
2006171917.tif 000062
【図５Ｂ】
2006171917.tif 000063
【図６】
2006171917.tif 000064
【図７Ａ】
2006171917.tif 000065
【図７Ｂ】
2006171917.tif 000066
【図８Ａ】
2006171917.tif 000067
【図８Ｂ】
2006171917.tif 000068