JP2006171917A - 無線マルチホップアドホックネットワークのためのプロトコル - Google Patents

Abstract

【課題】無線マルチホップアドホックネットワークにおけるピアツーピアサービス発見を改善する技術を提供する。
【解決手段】保存及び転送メッセージング原理に基づいて組織化された無線ピアツーピアネットワークにおけるサービスの提供に関し、特に、無線マルチホップアドホックネットワークにおいて、要求されたリモートサービスの利用可能性を判定するために必要である、低プロファイルで低オーバヘッドのサービス発見情報を提供するサービス発見プロトコルを実現する。
【選択図】図５Ａ

Description

本発明は、無線ピアツーピアネットワーク（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：以下、ＤＬＣという。）層は、既に、幾つかの低いレベルのサービス発見機能を実現している。この機能を利用するために、以下のような三段階の手法を提案する。
１．まず、ローカルサービステーブルに興味がある特定のサービスを問い合わせる。
２．ローカルでは、利用可能なサービスがない場合、ＤＬＣサービス発見プロトコルを実行する。
３．一旦、興味がある幾つかのサービスが既知となると、これらのサービスに関するより詳細な情報を検索し、要求側のピアに送る。

更に、適用されたサービス発見メカニズムの反応を強めるために、先見的なサービスの問い合わせだけではなく、サービス告知もサポートする。ここに提案するサービス発見プロトコルの設計目標は、送信されるメッセージの数を最少にするとともに、ロバストで効率的なサービス告知機能を提供することである。これにより、無線アドホックネットワークにおいてかなり高コストである同報通信メッセージの使用が回避される。

本発明の一実施例では、全てのピアＮ_ｉが、所謂サービス告知メッセージプールＰ_ｉを実現する。ここでは、このピアＮ_ｉが受信した全てのサービス告知メッセージＭ_ｉｋには、関連値ｒ_ｉｋによってタグが付される。この後、プール内の全ての関連値ｒ_ｉｋが足し合わされ、その結果、累積的な関連値が算出される。

ここで、Ｋ_ｉは、ピアのプールＰ_ｉに保存されたサービス告知メッセージＭ_ｉｋの総数を示す。一旦、累積的な関連値Ｒ_ｉが所定の閾値Ｒ_ｔｈ，ｉを超えると、プールＰ_ｉの全てのメッセージが集められ、全ての隣接するピアＮ_ｌ（ｌ≠ｉ）に送信される。この関連値ｒ_ｉｋは、重要度が低いサービスを告知する場合には、非常に小さい値とし、より重要なサービスを告知する場合には大きな値としてもよい。これにより、ネットワーク内でメッセージが配信される速度をより精密に制御することができる。

適用された伝送媒体が１ホップ同報通信（one-hop broadcasting）をサポートする場合、無線ピアＮ_ｉの近隣全体に対して、単一のサービス告知メッセージプールＰ_ｉを用いることができる。一方、１ホップ同報通信がサポートされていない場合、又はメッセージ配信をより高精度に制御する必要がある場合、別のプールＰ_ｊを用いてもよい。これにより、例えば、モバイルピアＮ_ｉに割り当てられるプールＰ_ｉの閾値Ｒ_ｔｈ，ｉをプールＰ_ｊの固定ピアＮ_ｊに割り当てられる閾値Ｒ_ｔｈ，ｊより高い値に設定することができる。また、非固定の閾値Ｒ_ｔｈ，ｉを定義することもでき、これは、外部の条件に応じて変化できる時変閾値関数Ｒ_ｔｈ，ｉ（ｔ）を意味する。例えば、隣接しているピアが小さな電力で動作し、及び／又はネットワーク内の様々なリソースの利用可能性に関する他の情報及び／又はピアＮ_ｉとその隣接しているピアＮ_ｌとの間のリンクの特徴が変更されている場合、隣接するピアＮ_ｌに不要なメッセージＭ_ｉｋが送信されることを回避するために、対応するピアＮ_ｉのサービス告知メッセージプールＰ_ｉの閾値Ｒ_ｔｈ，ｉが高められる。

固定ピアＮ_ｊ上の累積的な関連値Ｒ_ｊ：＝Σ_ｋｒ_ｊｋは、所定の閾値Ｒ_ｔｈ，ｊを超えてはならないが、モバイルピアＮ_ｉは、それらの閾値Ｒ_ｔｈ，ｉの値として任意の値を自由に選ぶことができる。この閾値Ｒ_ｔｈ，ｉを「無限」に設定することは、如何なるメッセージも送信しないことを意味し、この値をゼロにすることは、全てのメッセージＭ_ｉｋを即時に再送することを意味する。

効率的な実行を実現するために、サービス告知メッセージを伝播するための基本プロトコルは、比較的単純である。本発明では、原則として、サービス告知処置に参加する全てのピアにおいて、以下のステップを実行する必要がある。
１．如何なるサービス告知も、更なる整数関連パラメータｒ_ｉｋ及び０〜１００％の間の実数で評価された関連性低下率（relevance degeneration rate）ｄ_ｉｋとに基づいて実行される。
２．サービス告知メッセージＭ_ｉｋが、以前にピアＮ_ｉ上で確認されたものである場合、そのサービス告知メッセージＭ_ｉｋは、破棄される。これ以外の場合、受け取られたサービス告知メッセージＭ_ｉｋのプールＰ_ｉにこのピアを含めることによって、メッセージは、このピアにおいてローカルに保存される。
３．この後、このプールＰ_ｉ内に保存されたサービス告知メッセージＭ_ｉｋに割り当てられている全ての関連値ｒ_ｉｋを加え、これにより累積的な関連値Ｒ_ｉ：＝Σ_ｋｒ_ｉｋを生成する。累積的な関連値Ｒ_ｉが所定の閾値Ｒ_ｔｈ，ｉを超えた場合、サービス告知メッセージＭ_ｉｋは、集められ、このピアＮ_ｉに近接する全てのピアに送信される。また、プールＰ_ｉ内のサービス告知メッセージＭ_ｉｋの数Ｋ_ｉが所定の閾値Ｋ_ｔｈ，ｉを超えた場合、又は最後のサービス告知メッセージＭ_ｉｋの受信から経過した時間Δｔ_ｉｋが所定の期間閾値Δｔ_ｔｈ，ｉを超えた場合にも同様の処理が行われる。これらの条件は、以下のように要約することができる。

４．サービス告知メッセージＭ_ｉｋを受け取る如何なるピアＮ_ｉもそのローカルプールＰ_ｉにサービス告知メッセージＭ_ｉｋを含める。更に、このピアＮ_ｉは、各関連値ｒ_ｉｋから、関連性低下率ｄ_ｉｋによって与えられる低下の割合を減算することによって入力メッセージの関連値ｒ_ｉｋを再計算する。

関連値ｒ_ｉｋの低下により、最初は高い関連値ｒ_ｉｋを有し（したがって、ネットワーク中で高速に送信され）、幾つかのホップの後に「重要度が低下する」メッセージＭ_ｉｋを作成することができる。このように、サービス告知メッセージＭ_ｉｋは、近隣のピアには高速に伝播され、遠くのピアには、ゆっくり伝播される。

送信される全てのメッセージＭ_ｉｋは、サービス識別子（又はサービス記述子）、メッセージ識別子、サービスをホストするピアＮ_Ｈのアドレスを含んでいる。メッセージ識別子は、メッセージＭ_ｉｋがタグ付けをされた後にインクリメントされるピアの内部のカウンタから作成される。ピアＮ_ｉは、新たなメッセージＭ_ｉｋを受け取った場合、常に、所定のピアからの所定のサービス識別子を有する最後に受け取ったメッセージＭ_{ｉ，ｋ−１}を確認する。保存されているメッセージ識別子が新たなメッセージＭ_ｉｋのメッセージ識別子より新しい場合、この新たなメッセージは、破棄される。

更に利用可能な各サービスは、利用可能なサービスを再告知すべき期間を定めるリースタイムアウトに関連付けられる。このメカニズムは、サービステーブル内に古いエントリが残ることを避けるために用いられる。

サービス利用可能性の告知は、無線マルチホップアドホックネットワークに接続されたクライアント端末に知らせる必要があるサービスが、自らをローカルのピアＮ_ｉに登録したときにトリガされる。したがって、如何なるサービス利用可能性告知メッセージＭ_ｉｋも、ピアのサービス告知メッセージプールＰ_ｉに含まれるだけではなく、ローカルサービステーブルの更新の必要性を生じさせる。

同様に、サービスの利用可能性を他のピアに知らせるとともに、サービスの停止もネットワーク全体に亘って伝播させる必要がある。原理的には、サービスの停止を告知する主な理由は、サービスがピアに登録されていないためである。ピアが既にネットワークに存在しなくなり、したがって、そのピアによってホストされていたサービスも利用不可能となる状況は、無線のピアの利用可能性を監視することによって処理される。メッセージを告知するための総合的な処理としては、上述した処理と同様のものを用いることができる。

ピアに関する情報から、ネットワークに存在していない古くなったエントリを取り除くために、サービス発見プロトコルにピアの消滅を示すメカニズムを加える。このメカニズムは、既に上述したリースメカニズム（leasing mechanism）をサポートする。

隣接する新たなピアＮ_ｊが出現すると、サービステーブル及びこのピアによって提供されるサービスの管理データ（例えば、メッセージカウンタ）が要求される。返されたサービスは、それらが既に処理されているものであるか否かが確認される。このサービスが既に処理されているものではない場合、それらは各ピアＮ_ｉのローカルメッセージプールＰ_ｉに加えられる。この結果、ネットワークの変化によって、メッセージの交換がトリガされ、これは、ネットワークにおけるメッセージの全体的な利用可能性に寄与する。不要なメッセージの送信を回避するために、後述する折衝手続（negotiation procedures）を適用することができる。

この折衝手続によって生じるメッセージオーバヘッドを避けるために、ネットワークに参加する新たなピアは、その隣接するピアの１つ（又は、幾つか）の状態のクローンを作ることだけが許可される。

ここまで、先見的なサービス存在情報の伝播のみを説明した。勿論、サービス要求を他のノードに転送するために、所定のプロトコルを用いてもよい。

無線のピアに隣接するピアのいずれか（又は複数のピア）にプールコンテンツを送信する場合、常に、送信されるメッセージの短い概要（アウトライン）が配信される。送信される情報には、（少なくとも）サービス識別子、サービスをホストするピアＮ_Ｈのアドレス、及びメッセージ識別子が含まれる。この情報に基づき、如何なるピアもそのメッセージがそのピアにとって興味があるものであるか否かを判定することができる。したがって、ピアＮ_ｉがピアＮ_ｉ＋１にメッセージＭ_ｉｋを提供する場合、以下のオプションが利用可能である。
１．このメッセージＭ_ｉｋがピアＮ_ｉ＋１にとって興味があるものではない場合、ピアＮ_ｉ＋１は、ピアＮ_ｉに対し、このメッセージを削除するよう要求できる。
２．メッセージＭ_ｉｋがピアＮ_ｉ＋１にとって興味があるものであるが、Ｎ_ｉ＋１がそのメッセージを受け取ることを未だ望んでいない（すなわち、ピアＮ_ｉ＋１がスリープモードに入り、更なるメッセージを処理しない）場合、ピアＮ_ｉ＋１は、ピアＮ_ｉに対し、このメッセージを保存し、後に送信するよう要求できる。
３．ピアＮ_ｉ＋１は、ピアＮ_ｉの１つ（Ｍ_ｉｋ）を無効にする更新されたメッセージＭ_{ｉ＋１，ｋ}を有していてもよい（例えば、ピアＮ_ｉは、サービス告知の送信を望むがピアＮ_ｉ＋１は、各サービスが利用可能ではなくなっていることを既に知っている場合等に用いられる）。この場合ピアＮ_ｉ＋１は、更新されたメッセージＭ_{ｉ＋１，ｋ}をピアＮ_ｉに提供する。

無線マルチホップアドホックネットワーク内では、同時に多くのサービスが利用可能である場合がある。それらの幾つかは、集合的サービス（conglomerate service）とみなされることがある（例えば、テレビジョンの制御装置と、周辺制御サービスとは、１つの家庭用娯楽サービスとみなすことができる）。サービス利用者がこのような集合的サービスの発見を望んでいる場合、このような集合的サービスをクエリ内で特定できるようにしてもよい。集合的サービスを特定のサービスに分解し、ネットワーク内でそれらを発見する処理は、本発明に基づくサービス発見プロトコルによって実行される。このために集合的サービスへの要求は、ネットワーク内に拡散し、このサービスに貢献することを望む各ピアは、対応する応答を返信する。これらの応答は、要求側のピアに集められ、集合的サービスを実現できるか否かが判定される。

サービス記述の基礎としては、キー／値の組だけがサポートされる。これらは、キー（属性）値を割り当てることによって、サービスを記述することを可能にする。所定のプロトコルによっては、基本サービス発見メカニズムだけが実現されるので、この情報は、十分である。例えば、ＵＰｎＰにおけるサービス記述言語等、他のサービス記述言語と比べて、イベント又は状態記述等の情報は、オーバーヘッドを最小にするために故意に省略される。より高い層においてこのような機能を実現するためには、追加コンポーネント、すなわちサービス発見（ＳＤ）メタデータハンドラ２０４を導入する。このコンポーネントは、より複雑なより高い層のサービス記述機能、例えば、ＵＰｎＰのサービス記述機能と、本発明に基づいてここに提案するサービス発見プロトコル２０８（図２参照）との間で調停することができる。このために、このコンポーネントは、コアサービス記述属性を抽出し、抽出したコアサービス記述属性をサービス発見プロトコル層に渡す。一旦、サービス発見プロトコルが幾つかのサービスを発見すると、サービス発見プロトコルは、これに応じて、応答を期待されたフォーマットに組み立て直す。必要な場合、このようなメタデータハンドラ２０４により、様々なサービス発見プロトコルを所定のサービス発見プロトコル２０８にマッピングしてもよい。

このプロトコルは、特にサービス発見の目的のために設計されているが、基本通信スキームは、例えば、ネットワーク状態情報、機器存在メッセージ、イベントの伝播、又はデータ配信に関してリアルタイムの制約条件を有さないあらゆる種類のデータ等、他のデータに対しても好適に機能する。このようなデータは、（例えば）分散されたルーティング情報、ＱｏＳ提供をサポートし／イネーブルにする分散された情報、ネットワーク状態情報、（インスタント）メッセージデータ、センサデータ、ピア状態情報等であってもよい。

図３〜図６に示すＵＭＬメッセージシーケンス図３００、４００、５００、６００は、サービスを登録する処理、本発明に基づくサービスの利用可能性を示すサービスメッセージを扱う処理及びサービスを登録解除する処理を示している。図７は、本発明に基づくサービス発見プロトコル２０８によって実行される提案されたサービス発見メカニズムの概要を説明するＵＭＬ状態図７００を示している。図８は、本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図８００である。

ここに提案するサービス発見プロトコルの柔軟性により、以下に列挙するような、ある程度の自由度が実現される。
１．如何なるピアＮ_ｉもサービス告知メッセージプールＰ_ｉが、いつ、幾つの告知メッセージを含むかをローカルで判定することができる。モバイルピアＮ_ｉ等の電力的制約を有するピアは、多くのメッセージＭ_ｉｋを送信することを回避するするために、より大きいプールＰ_ｉを有していてもよく、一方、固定ピアＮ_ｊは、より小さいプールＰ_ｊを有し、この結果、より多くのメッセージＭ_ｉｋを送信してもよい。更に、累積的な関連値Ｒ_ｉ（Ｒ_ｊ）のための閾値Ｒ_ｔｈ，ｉ（Ｒ_ｔｈ，ｊ）は、それぞれのモバイルピア（Ｎ_ｉ）又は固定ピア（Ｎ_ｊ）の現在の制約に応じて設定してもよい。値自体は、それぞれのピアの現在の状態に応じて、各ピアによって動的に変更してもよい。
２．サービス告知が減衰する可能性により、利用可能なサービスは、ピアＮ_ｉの近隣（Ｎ_ｊ）では、速やかに告知され、より遠くのピアは、このサービスを比較的遅く知る。
３．ネットワーク全体に非常に高速に知らせる必要があるサービスは、比較的高い関連値ｒ_ｉｋ（ｒ_ｊｋ）によって送信し、これ以外のサービスは、より低い関連値によって送信してもよい。いずれの場合も、ネットワーク内でサービス告知メッセージＭ_ｉｋを広める速度は、ピアＮ_ｉ（Ｎ_ｊ）によって容易に制御できる。
４．モバイルマルチホップアドホックネットワークを構成するピアの数の変動によって、メッセージ交換をトリガし、これは、全体的な情報の普及に貢献する。

なお、上述した各項目及び特にそれらの組合せのいずれも、最新技術に基づく従来のサービス発見プロトコルでは、発見することができない。

ここに提案するプロトコルは、例えば、家庭用及び個人的な用途のシナリオにおいて動作するよう設計されている無線マルチホップアドホックネットワークの要求に適合し、以下のような特徴を有する。
・同報通信を行わない。：無線マルチホップアドホックネットワークにおいては、同報通信は、（可能であるとしても）高価であり、電力を消費するタスクである。したがって、ここに提案するサービス発見プロトコルは、無線マルチホップアドホックネットワークにおけるサービス発見を実現する技術であるとみなすことができる。
・如何なる不要なメッセージも送信せず、これにより、トラフィックオーバヘッドを回避し、電力を節約する。：これは、特にモバイル型の電源として電池を用いるピアにおいて重要な特徴である。ここに提案するプロトコルを用いることにより、これまでの技術水準と比較して、同じ（又はより良い）機能を有しながら、消費電力が小さい機器を製造することができる。
・無線のピアに近接したピア（例えば、同じ部屋に設置されているテレビジョンセット）の最新状態をユーザに知らせ続けるので、したがって、この技術を利用することによって無線ピアのユーザは、今までにない経験をすることができる。

下層における機能を利用し、プロトコルをより単純にすることにより、必要に応じて、（少なくとも幾つかの）機能をハードウェアに容易に統合することができる。

本発明の更なる実施例として、本発明は、保存及び転送メッセージング原理に基づいて、ピアツーピアベースの無線マルチホップアドホックネットワークにおいて要求されたリモートサービスの利用可能性を判定するために必要なサービス発見情報を提供するプロキシサーバとして機能するピアＮ_ｉを提供する。この場合、ピアは、上述した方法を実現するサービス発見マネージャユニット２０４を備える。

また、本発明は、このピアＮ_ｉ上で実行されて、上述のサービス発見方法をサポートするよう設計されているソフトウェアプログラム製品を提供する。

従来のサービス発見メカニズムとプロトコルの異なる特徴、長所及び短所を比較して示す図である。 本発明に基づくメタデータベースのサービス記述の処理のために用いられる異なるピアプロトコル層を示す図である。 本発明に基づくリモートサービスを登録するためのインタラクションを示す第１のＵＭＬメッセージシーケンス図である。 本発明に基づくローカルサービスを登録するためのインタラクションを示す第２のＵＭＬメッセージシーケンス図である。 本発明に基づくリモートサービスの利用可能性を示すサービスメッセージを扱うためのインタラクションを示す第３のＵＭＬメッセージシーケンス図である。 本発明に基づくリモートサービスの利用可能性を示すサービスメッセージを扱うためのインタラクションを示す第３のＵＭＬメッセージシーケンス図である。 本発明に基づくローカル又はリモートサービスを登録解除するためのインタラクションを示す第４のＵＭＬメッセージシーケンス図である。 本発明に基づくサービス発見プロトコル２０８によって実行されるサービス発見メカニズムを示すＵＭＬ状態図である。 本発明に基づくサービス発見プロトコル２０８によって実行されるサービス発見メカニズムを示すＵＭＬ状態図である。 本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図である。 本発明に基づくサービス発見プロトコルのオブジェクト指向インプリメンテーションのためのクラスを示すＵＭＬクラス図である。

Claims (12)

1. ピアツーピアベースの無線マルチホップアドホックネットワークにおいて、サービス発見情報及び要求されたリモートサービスの利用可能性を判定するための他のデータを提供する情報提供方法において、
   上記ネットワーク内のサービスプロバイダによって隣接するピア（Ｎ_ｌ）に提供されるリモートサービスについて言及する受信されたサービス告知メッセージ（Ｍ_ｉｋ）を配信するステップと、
   古くなった及び無関係のメッセージ（Ｍ_ｉｋ）を削除するステップ（Ｓ１ｂ）とを有する情報提供方法。
2. 上記ピア（Ｎ_ｉ）により、
   上記サービス告知メッセージ（Ｍ_ｉｋ）を受信するステップ（Ｓ１ａ）と、
   該ピア（Ｎ_ｉ）によって既に受け取られている古いサービス告知メッセージ（Ｍ_ｉｋ）と同じであるメッセージ（Ｍ_ｉｋ）を削除し（Ｓ１ｂ）、該ピア（Ｎ_ｉ）に割り当てられているローカルメッセージプール（Ｐ_ｉ）に新たなサービス告知メッセージ（Ｍ_ｉｋ）を累加するステップと、
   該ピア（Ｎ_ｉ）によって受信した各サービス告知メッセージＭ_ｉｋに関連値（ｒ_ｉｋ）をタグ付けするステップと、
   ローカルメッセージプール（Ｐ_ｉ）に保存されている全てのサービス告知メッセージ（Ｍ_ｉｋ）の関連値（ｒ_ｉｋ）を加算し、累積的な関連値（Ｒ_ｉ）を生成するステップと、
   この累積的な関連値（Ｒ_ｉ）が所定の関連性閾値（Ｒ_ｔｈ，ｉ）を超えると、全てのサービス告知メッセージ（Ｍ_ｉｋ）を集め、ローカルメッセージプール（Ｐ_ｉ）に保存し（Ｓ４ａ）、該集められたサービス告知メッセージ（Ｍ_ｉｋ）を該ピア（Ｎ_ｉ）に隣接する全てのピア（Ｎ_ｌ）に送信するステップ（Ｓ４ｂ）とを有することを特徴とする請求項１記載の情報提供方法。
3. モバイルピア（Ｎ_ｉ）に割り当てられているローカルメッセージプール（Ｐ_ｉ）の関連性閾値（Ｒ_ｔｈ，ｉ）を固定ピア（Ｎ_ｊ）に割り当てられているローカルメッセージプール（Ｐ_ｊ）の閾値（Ｒ_ｔｈ，ｊ）より高い値に設定するステップ（Ｓ５）を更に有する請求項２記載の情報提供方法。
4. 上記関連性閾値（Ｒ_ｔｈ，ｉ）を外部の条件に従って動的に変更するステップを更に有する請求項３記載の情報提供方法。
5. 上記ネットワーク内で利用可能なサービスを告知する第１のピア（Ｎ_ｉ）によって、
   隣接している第２のピア（Ｎ_ｌ）が小さな電力で動作し、及び／又はネットワーク内の様々なリソースの利用可能性に関する他の情報及び／又は上記第１のピア（Ｎ_ｉ）とその上記隣接しているピア（Ｎ_ｌ）との間のリンクの特徴が変更されているか否かを判定するステップ（Ｓ６ａ）と、
   上記判定の結果が肯定的である場合、上記隣接するピア（Ｎ_ｌ）に不要なメッセージ（Ｍ_ｉｋ）が送信されることを回避するために、対応する上記第１のピア（Ｎ_ｉ）のサービス告知メッセージプール（Ｐ_ｉ）の閾値（Ｒ_ｔｈ，ｉ）を高めるステップ（Ｓ６ｂ）とを有することを特徴とする請求項４記載の情報提供方法。
6. 上記第１のピア（Ｎ_ｉ）によって、
   該第１のピア（Ｎ_ｉ）に割り当てられるローカルメッセージプール（Ｐ_ｉ）に保存されたサービス告知メッセージ（Ｍ_ｉｋ）の数（Ｋ_ｉ）が所定の閾値（Ｋ_ｔｈ，ｉ）を超えた場合、受信され、集められたサービス告知メッセージ（Ｍ_ｉｋ）を上記隣接する全てのピア（Ｎ_ｌ）に送信するステップ（Ｓ４ｂ’）を有する請求項５記載の情報提供方法。
7. 上記第１のピア（Ｎ_ｉ）によって、
   最後のサービス告知メッセージ（Ｍ_ｉｋ）の受信から経過した時間（Δｔ_ｉｋ）が所定の期間閾値（Δｔ_ｔｈ，ｉ）を超えた場合、受信され、集められたサービス告知メッセージ（Ｍ_ｉｋ）を隣接する全てのピアに送信するステップ（Ｓ４ｂ”）を有する請求項５記載の情報提供方法。
8. 上記第１のピア（Ｎ_ｉ）によって、
   サービス告知メッセージ（Ｍ_ｉｋ）が近いピア（Ｎ_ｌ）には、高速に伝播され、上記第１のピア（Ｎ_ｉ）から遠くのピア（Ｎ_ｌ）には、遅く伝播されるように、各関連値（ｒ_ｉｋ）から、サービス告知メッセージ（Ｍ_ｉｋ）が伝播されたホップの数が大きくなるほど高くなる関連性低下率（ｄ_ｉｋ）によって与える低下の割合を減算することによって、受信したサービス告知メッセージ（Ｍ_ｉｋ）の関連値（ｒ_ｉｋ）を再計算するステップ（Ｓ７）を有する請求項１乃至７いずれか１項記載の情報提供方法。
9. 上記第１のピア（Ｎ_ｉ）によって、
   上記ネットワーク内で上記隣接するピア（Ｎ_ｌ）の利用可能性を監視するステップ（Ｓ８ａ）と、
   上記ピア（Ｎ_ｌ）が上記ネットワークに存在しなくなり、その結果、そのピア（Ｎ_ｌ）がホストするサービスが利用可能ではなくなった場合、上記ネットワーク全体に、これらのサービスの停止を伝播するステップとを有する請求項１乃至８いずれか１項記載の情報提供方法。
10. 上記第１のピア（Ｎ_ｉ）によって、
    該第１のピア（Ｎ_ｉ）に割り当てられているローカルメッセージプール（Ｐ_ｉ）のコンテンツが上記隣接するピア（Ｎ_ｌ）のいずれか又はそれらのうちの複数に送信される場合、上記隣接するピア（Ｎ_ｌ）には、伝播すべき、サービス告知メッセージ（Ｍ_ｉｋ）に関する、これらのデータを受け取る隣接しているピアがメッセージ（Ｍ_ｉｋ）について特に興味があるものであるか否かを判定できるよう、少なくともサービス識別子と、サービスをホストするピア（Ｎ_Ｈ）のアドレスと、メッセージ識別子とを含む短い概要を供給するステップを有する請求項１乃至９いずれか１項記載の情報提供方法。
11. 上記第１のピア（Ｎ_ｉ）によって、
    興味がある特定のサービスの利用可能性に関する情報を含んでいるローカルサービステーブルについて、これらのサービスをホストするピア（Ｎ_Ｈ）に対し、先見的に問い合わせを行うステップ（Ｓ１０ａ）と、
    ローカルで利用可能なサービスがない場合、マルチホップアドホックネットワーク内で要求されたサービスの利用可能性を判定するために必要であるサービス発見情報を提供するためにサービス発見プロトコルを実行するステップ（Ｓ１０ｂ）と、
    興味がある幾つかのサービスが既知になると、これらのサービスに関するより多くの詳細情報を検索するステップ（Ｓ１０ｃ）とを有する請求項１乃至１０いずれか１項記載の情報提供方法。
12. 請求項１乃至１１いずれか１項記載の情報提供方法を実現するよう設計されたソフトウェアプログラム製品。

Images