通信ネットワークにおけるプロトコルネゴシエーションのための方法、システムおよび装置
ネットワークの共通設定パラメータを決定する分散方法が開示される。ネットワークは、本方法を実行するように指定された少なくとも１つのノードを備える。本方法では、指定ノードは、自ノードのローカル動作環境に関する情報に基づき設定パラメータに係わるローカル決定を実施する（Ｍ３）。指定ノードは、もしあれば他の指定ノードにそのローカル決定を送信し、もしあれば他の指定ノードが行った対応するローカル決定を受信する（Ｍ４）。その受信に続いて、指定ノードは、そのローカル決定および受信したローカル決定に基づき、設定パラメータに係わる共同決定を実施する（Ｍ５）。共同決定は、指定ノードに共通の決定アルゴリズムを用いて行われる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークで使用する方法および装置に関する。
【背景技術】
【０００２】
既存のネットワークでは、様々なネットワーク要素の設定時点において、オフラインで読み出された多くの事前知識および情報が使用され、その後この設定は、ネットワークが運用中の長期にわたり、ほとんど変更されない。この事前知識は、いくつかの例を挙げると、ネットワーク内のネットワーク要素数、トポロジ、リンクおよびネットワーク要素の容量、ならびにＱｏＳ特性から成る。
【０００３】
将来のネットワーキングでは、全く新しい次元の動的性質が期待されている。アンビエントネットワーク（ＡＮ、Ambient Network）は、新しいネットワーキング概念であり、異なるオペレータ領域または技術領域に属し得る異種のネットワークの連携を可能にすることを目指している。この連携は、トランスペアレントで、オンデマンドで確立され、それ故「プラグアンドプレイ」動作をサポートすべきである。すなわち、ネットワークを形成するとき、およびどのように互いに接続するかについて、以前の設定もネゴシエーションも必要とされるべきでない。
【０００４】
アンビエントネットワーク（ＡＮ）は、第６次フレームワークプログラムの優先テーマの情報社会技術（ＩＳＴ、Information Society Technology）のもとで、欧州委員会が協賛している総合計画（ＩＰ、Integrated Project）である。
【０００５】
この新しい構想は、検討され、ワイヤレスワールドイニシアティブの一部であるアンビエントネットワーク計画に成長した。アンビエントネットワークは、第６次フレームワークプログラムの優先テーマの情報社会技術のもとで、欧州委員会が協賛している総合計画である。この計画は、２００４年に開始され、２００７年に終了する第２フェーズを現在実施中である。アンビエントネットワーク概念に基づくネットワークは、２０１２〜２０１５年頃に、ことによるともっと早くに運用開始になりうる。
【０００６】
アンビエントネットワーキングに関して作成または再規定されなければならない多くの概念の中でも、これらの異種のネットワークが混成される特徴が予見できることから、ルーティングは最も重要なものの１つである。同一のネットワーク要素が、ある時点のいわゆるアドホックネットワーク環境において、設置されて使用され、その後、より固定的なインフラタイプのネットワーク環境に、移動され再設置されてもよい。このタイプの動作環境に関しては、異なる動作環境において異なるルーティングプロトコルを使用できるマルチプロトコルルーティングアプローチが、「どれにも合う(one-size-fits-all)」単一プロトコルアプローチに代わるものとして妥当と思われる。
【０００７】
しかし、複数のルーティングプロトコルが同時に動作するのを許すことによって、かつ異なる環境および同じ環境でさえも複数のプロトコルを実施することによって、ネットワーク領域内およびネットワーク領域間で、できるだけ効率的に情報をルーティングしうるように、サポートしているプロトコルの中からどのように選ぶかの問題が生じる。
【０００８】
マルチプロトコル環境を考慮した２つのアプローチが、非特許文献１および非特許文献２に記載されている。
【０００９】
非特許文献１では、どのプロトコルが使用されなければならないかを識別するために使用しうるホスト情報を配信するために、ディレクトリサービスを使用するプロトコルネゴシエーション解決手段が提案されている。ディレクトリが利用可能でない場合、ネゴシエーションプロトコルは、使用可能なプロトコルを発見するために、通信中のピアを調べてもよい。従って、使用されているアプローチは、マルチプロトコル通信をサポートするために、調査とディレクトリサービスを混合している。
【００１０】
非特許文献２は、この相互接続性を提供するために、いくつかの目標の設定を含む相互接続性についての調査を提示する。異種の混成は、プロトコルミスマッチまたはインタフェースミスマッチと描写される。これらの問題を解決または軽減する３つの可能なアプローチも提示されている。
【００１１】
第１のアプローチは、ペアワイズアプローチであり、このアプローチでは、コンポーネントＡがコンポーネントＢとの通信を望むとき、１対の変換機能が存在すると想定している。ＡメッセージからＢメッセージへの変換に加えて逆方向への変換も存在しなければならないことから、１対の機能が必要である。第２のアプローチは、共通言語アプローチであり、このアプローチでは、特殊言語Ｓが使用され、あらゆるコンポーネントがその言語で連絡しうる。これは、単一標準と見なしてもよく、このアプローチはＸＤＮＭに最も近い。最後のアプローチは仲介者アプローチ、すなわち第三者がいるハイブリッドアプローチであり、各第三者は、種々の環境で使用される多くのプロトコルの中のあるサブセットを理解する。
【００１２】
特許文献１および特許文献２は、より高いスループットの提供またはモデムの標準ハンドシェイク手順で確立された最初に決めた設定の維持の提供のプロセスに係わるペアに対してより良い機能を選択するために、各モデムがサポートしている機能の情報交換を通じて通信を改善するように、モデム間での機能のネゴシエーションについての提案に焦点を合わせており、非常に具体的である。
【００１３】
特許文献３では、ローカルネットワークの要素による、自要素の通信のために共通プロトコルの設定を可能にする解決手段を著者が明記している。この文献は、２つの係わるノード間の実施プロセスを開示している。提案の解決手段の基本動作は、各ネットワーク要素が使用するプロトコルの互換性を検証し、同様である場合、変更は行われないが、それぞれの要素が異なるプロトコルで動作している場合、それらの１つの要素が、使用すべきプロトコルを決定するより優先順位の高い局に選択される。別の制約は、それがＣＳＭＡ／ＣＤ ＬＡＮでだけ機能することである。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】米国特許第４９５３２１０号明細書（Paul E. McGlynn他、「同期モデムのための機能ネゴシエーションプロトコル（Feature negotiation protocol for a synchronous modem）」、出願日：1990年2月22日、発行日：1990年8月28日）
【特許文献２】米国特許第４９０５２８２号明細書（Paul E. McGlynn他、「機能ネゴシエーションプロトコルおよび高速半二重モデムのための動的調節可能再教育手順（Feature Negotiation Protocol and Dynamically Adjustable RetrainingSequence for a High Speed Half Duplex MODEM）」、出願日：1988年10月19日、発行日：1990年2月27日）
【特許文献３】米国特許第５５８６１１７号明細書（Brian C. Edem他、「複数のプロトコル能力を有するデバイスによる、共通プロトコル設定への設定を可能にする方法および装置（Method and Apparatus Which allows Device with Multiple ProtocolCapabilities to Configure to a Common Protocol Configuration）」、出願日：1994年6月20日、発行日：1996年12月17日
【非特許文献】
【００１５】
【非特許文献１】Clark, R.、 Ammar, M.、 Calvert, K.共著、「マルチプロトコルネットワークにおけるプロトコル発見（Protocol discovery in multi protocol networks）」、Mobile and Networks Applications Journal、2006年6月、オンライン出版 http://www.springerlink.com/content/hn3241724163620x
【非特許文献２】F. Bamberger、 P. Ford、 J. M. Wing、「ＮＩＩに関するＲ＆Ｄの「相互接続性」セクション：技術チャレンジ（“Interoperability,” section inR&D for the NII: Technical Challenges）」、M. K. Vernon、 E. D. Lazowska、 S. D. Personick報告書編集、Interuniversity Communications Council, Inc.(EDUCOM)、 1994年
【発明の概要】
【課題を解決するための手段】
【００１６】
本発明の第１の態様によれば、ネットワークの共通設定パラメータを決定する分散の方法が提供され、そのネットワークは本方法を実行するように指定された少なくとも１つのノードを備え、指定のノードにおいて、自ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する工程と、もしあれば他の指定ノードへそのローカル決定を送信する工程と、もしあれば他の指定ノードが行った対応するローカル決定を受信する工程と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する工程とを備える分散方法が提供される。
【００１７】
本方法は、ネットワークの少なくとも１つの他のノードから少なくとも１つの他のノードのローカル動作環境に関するネットワーク情報を受信する工程と、受信した情報を用いてローカル決定を実施する工程とを備えてもよい。
【００１８】
本方法は、共同決定を非指定ノードに送信する工程を備えてもよい。
【００１９】
決定アルゴリズムは、少なくとも１つの指定ノードが行った最も多いローカル決定を採用する工程を備えてもよい。
【００２０】
共同決定を実施する工程は、自ノードのローカル決定および少なくとも１つの指定ノードから受信したローカル決定の中で過半数を占める決定を採用する工程を備えてもよい。
【００２１】
ノードの動作環境情報は、そのノードの重さを備えてもよく、共同決定を実施する工程は、最大の重さを有する少なくとも１つの指定ノードが行った決定を採用する工程を備えてもよい。
【００２２】
設定パラメータは、ネットワークで用いるルーティングプロトコルと、ネットワークインタフェースアドレスと、接続確立用のシグナリングプロトコルと、モビリティ管理用のプロトコルと、コーデックと、リンク層スケジューリングアルゴリズムと、送信電力の少なくとも１つを備えてもよい。
【００２３】
ローカル動作環境情報は、ノードがサポートしているプロトコルと、例えば処理能力および利用可能メモリなどのノードのハードウェア仕様と、例えばアドレス指定情報などのネットワークノード間のリンクおよび／またはインタフェースと、ノードの１つ以上のアイデンティティと、ネットワーク内のノード数と、例えばサポートしている能力、メディアおよび符号化のサポート、実施ポリシーなどのノードの状態情報と、デフォルトルーティングパラメータと、追加でネゴシエートするパラメータの中の、少なくとも１つを備えてもよい。
【００２４】
本方法は、ローカル動作環境情報を少なくとも１つの他の指定ノードに、そこでの本方法の実行に使用するために送信する工程を備えてもよい。
【００２５】
本方法は、少なくとも１つの他のノードへの情報の送信が、情報に領域境界を越えさせるだろうかどうかを判定する工程と、越えないと判定された場合だけ情報を送信する工程を備えてもよい。
【００２６】
本方法は、所定の間隔でローカル動作環境情報を送信する工程を備えてもよい。
【００２７】
本方法は、ローカル動作環境情報に影響を与える変更の発生に応じて、ローカル動作環境情報を送信する工程を備えてもよい。
【００２８】
本方法は、同じ領域内の別のノードだけにローカル動作環境情報を送信する工程を備えてもよい。
【００２９】
ネットワークは、単一の領域であっても、または単一の領域に関しても、または単一の領域を備えてもよい。
【００３０】
ネットワークは、本方法を実行するように指定された複数のノードを備えてもよい。
【００３１】
ネットワークのすべてのノードが、本方法を実行するように指定されてもよい。
【００３２】
ネットワークは、ＩＰネットワークを備えてもよい。
【００３３】
本方法は、各指定ノードで種々の工程を実行し、それによりシステム全体の方法の提供を備えてもよい。
【００３４】
本方法は、例えば共通設定パラメータに基づいた接続の確立などにより、共通設定パラメータを適用する工程を備えてもよい。
【００３５】
本発明の第２の態様によれば、ネットワークの共通設定パラメータを決定する分散方法の少なくとも一部を実行するように指定された、ネットワーク内のノードとして使用するかまたはノード内で使用する装置が提供され、本装置は、ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する手段と、もしあれば他の指定ノードにそのローカル決定を送信する手段と、もしあれば他の指定ノードが行った対応するローカル決定を受信する手段と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する手段とを備える。
【００３６】
本装置は、ネットワークの少なくとも１つの他のノードから、少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段を備えてもよく、受信した情報はローカル決定の実施に用いられる。
【００３７】
本装置は、共同決定を非指定ノードに送信する手段を備えてもよい。
【００３８】
共同決定を実施する手段は、少なくとも１つの指定ノードが行った最も多いローカル決定を採用するように構成されてもよい。
【００３９】
共同決定を実施する手段は、自ノードのローカル決定および少なくとも１つの指定ノードから受信したローカル決定の中から、過半数を占める決定を採用するように構成されてもよい。
【００４０】
ノードの動作環境情報はノードの重さを備えてもよく、共同決定を実施する手段は、最大の重さを有する少なくとも１つのノードが行った決定を採用するように構成されてもよい。
【００４１】
本装置は、ローカル動作環境情報を少なくとも１つの他の指定ノードに、そこでの本方法の実行に使用するために送信する手段を備えてもよい。
【００４２】
本装置は、少なくとも１つの他のノードへの情報の送信が情報に領域境界を越えさせるだろうかどうかを判定する手段と、越えないと判定された場合だけ情報を送信する手段とを備えてもよい。
【００４３】
本装置は、例えば共通設定パラメータに基づいた接続の確立などにより、共通設定パラメータを適用する手段を備えてもよい。
【００４４】
本発明の第３の態様によれば、ネットワークの共通設定パラメータを決定する分散型システムが提供され、本システムは、ネットワークの少なくとも１つの指定ノードのそれぞれにおいて、自ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する手段と、もしあれば他の指定ノードへそのローカル決定を送信する手段と、もしあれば他の指定ノードが行った対応するローカル決定を受信する手段と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する手段とを備える。
【００４５】
本システムは、各指定ノードにおいて、ネットワークの少なくとも１つの他のノードから少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段と、受信した情報を使用してローカル決定を実施する手段とを備えてもよい。
【００４６】
本システムは、各指定ノードにおいて、共同決定を非指定ノードに送信する手段を備えてもよい。
【００４７】
本発明の第４の態様によれば、装置を本発明の第１の態様による方法を実施するように制御するプログラム、または、装置にロードされたとき、装置を本発明の第２または第３の態様による装置にするプログラムが提供される。本プログラムは、運搬媒体で運ばれてもよい。運搬媒体は記憶媒体でもよい。運搬媒体は伝送媒体でもよい。
【００４８】
本発明の第５の態様によれば、本発明の第４の態様によるプログラムによってプログラムされた装置が提供される。
【００４９】
本発明の第６の態様によれば、本発明の第４の態様によるプログラムを格納している記憶媒体が提供される。
【図面の簡単な説明】
【００５０】
【図１】本発明の一実施形態の動作例の説明に使用する図である。
【図２Ａ】異なるタイプのネットワーク状態を示す図である。
【図２Ｂ】異なるタイプのネットワーク状態を示す図である。
【図２Ｃ】異なるタイプのネットワーク状態を示す図である。
【図３】本発明の一実施形態とともに使用するための、サポートしているある種のインタフェースおよびルーティングプロトコルを有するデバイス例を示す図である。
【図４Ａ】本発明の一実施形態による、ネットワークノードが実行するステップを示す図である。
【図４Ｂ】本発明の一実施形態による、ネットワークノードが実行するステップを示す図である。
【図５】パーソナルエリアネットワーク（ＰＡＮ）用のルーティングプロトコルを選択するために、３つのデバイスが本発明の一実施形態に従って動作する一例の説明に使用する図である。
【図６Ａ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図６Ｂ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図６Ｃ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図７】ホームアクセスネットワーク用のルーティングプロトコルを選択するために、６つのデバイスが本発明の一実施形態に従って動作する一例の説明に使用する図である。
【図８Ａ】本発明の一実施形態において、図７のデバイスが実行する動作手順例を示す図である。
【図８Ｂ】本発明の一実施形態において、図７のデバイスが実行する動作手順例を示す図である。
【図９】本発明の一実施形態で実行されるステップを示す概略フロー図である。
【図１０】本発明を具体化するデバイスの部品を示す概略ブロック図である。
【発明を実施するための形態】
【００５１】
上記で説明したように、ネットワーク要素の動的設定は現在非常に限られており、この限られている主な理由は、ネットワークが自らの設定および環境について「自己認識」する能力を持たないことである。この知識は、ほとんどの場合中央管理システムに存在し、そこからネットワーク要素は設定情報を取得する。
【００５２】
動的設定がサポートされている数少ない例外は、ある種のルーティングプロトコルを用いたルータでのルーティングテーブルの作成と、ホスト構成プロトコルを用いたホストのＩＰアドレスの設定である。
【００５３】
しかし、これらの数少ない例はよく制御されたネットワーク環境で動作し、そこでは、ネットワークトポロジおよびある種の機能の異なるネットワーク要素への分配は、ルーティングプロトコルまたはホスト構成プロトコルが動作する以前に既知となっている。
【００５４】
将来のネットワークでは、ネットワークトポロジおよび機能の分配が前もってわかると想定することはできない。さらに、ネットワークトポロジおよび機能は、（急速に）変化するかも知れず、ひいては動作環境の変化のために、ネットワーク要素のオンデマンドかつリアルタイムの再設定の必要があろう。
【００５５】
上記で提示の論文および特許のいずれにおいても、起こりうる環境を検証するためにネットワーク要素間のネゴシエーションの問題に注目し、異種の要素をサポートしうる通信インフラストラクチャをより容易かつより自動的に提供するために、ノードの利用可能な技術およびプロトコルを考慮して最善のものを選択することはなされていない。本発明の一実施形態では、新規な方法を規定することによって、現在の最先端技術のこれらの欠点に取り組むことを目指している。新規な方法は、広報（dissemination）・ネゴシエーション・決定スキームを通じてネットワーク動作環境をネットワーク要素が知るようになることで、ネットワーク要素を動的に選択し設定するために使用しうるものである。
【００５６】
本発明の一実施形態による解決策は、本明細書では「拡張ネットワーク環境発見およびネゴシエーション方法（ＸＤＮＭ、Extensible Network Environment Discovery and Negotiation Method）」と称する方法を使用し、ＸＤＮＭによって広報されたある種の情報のセットに基づき、使用すべき最善のルーティングプロトコルであろうプロトコルを選択決定する。プロトコルは、ネットワーク要素間のインタフェースにまたがって領域内ルーティングかそれとも領域間ルーティングが使用されるべきかについても決定できよう。
【００５７】
ＸＤＮＭは、適切なルーティングプロトコルを選択するための「メタプロトコル」として使用されるだけの範囲に限定されないことは明らかであり、ネットワーク要素の他のリアルタイム設定の基盤としての使用に役立つ「メタプロトコル」でもあってもよい。
【００５８】
以下の記述では、本発明の一実施形態の基本概念について適切なルーティングプロトコルの選択に関して述べるが、上記で説明したように、本発明は、他の設定パラメータの選択決定に使用されてもよい。そのような例は、ネットワークインタフェースアドレス、接続確立用のシグナリングプロトコル、およびモビリティ管理用のプロトコルであろう。
【００５９】
ＸＤＮＭを適用しうる典型的な状況は、あらゆる要素における以前の設定を用いずに、ネットワークのノードが使用する機能およびプロトコルを設定する状況である。そのような機能の設定が、ネットワーク動作環境を「自己認識」するＸＤＮＭの特性によって可能になる。
【００６０】
以下でさらに詳しく説明する特定の例のほかに、ＸＤＮＭのいくつかの使用例を挙げると、ビデオアプリケーションがネットワークリソースの使用を向上するために使用しなければならないコーデックのネゴシエーション、送信データの衝突を避けるためのリンク層スケジューリングアルゴリズム、およびバッテリ使用時間を長くするために使用すべき無線電力がある。
【００６１】
ルーティングプロトコルに関しては、ＸＤＮＭは、現在の動作環境についての情報に基づき、使用すべき最善のルーティングプロトコルが何であるかについての決定を可能にする。この動作環境情報は、以下から成ることができようが、それらに限定されないことは明らかである。
【００６２】
・ネットワーク要素がサポートしているプロトコル
・例えば処理能力および利用可能メモリに関して表された、ネットワーク要素のハードウェア仕様
・ネットワーク要素間のリンク／インタフェースについてのアドレス指定情報を含む情報
・ネットワーク要素のアイデンティティ（場合によっては、アイデンティティはアドレスプレフィックスに等しくできよう）（＊）
・領域内のネットワーク要素数
・各ネットワーク要素の「重さ」
・参加ノードのそれぞれがサポートしている能力と、メディアおよび符号化サポートと、実施ポリシーとを含む状態情報
・デフォルトルーティングパラメータ
・オプションでネゴシエートされてもよい追加のパラメータ
なお、上記でアスタリスク（＊）の付いた情報は、ＸＤＮＭの実施において必須とするのが普通であろう。
【００６３】
ＸＤＮＭは、３つの基本フェーズで動作すると考えられてもよい。
１．発見：各ネットワーク要素が、ネットワーク内の他のネットワーク要素に自要素のローカル動作環境情報を広報する。
２．ネゴシエーション：決定を実施する能力のある（決定することを指定された）各ネットワーク要素が、自要素のローカル決定アルゴリズムを用いて１つ以上の設定パラメータに係わるローカル（または仮の）決定を行う。この決定は、ネットワーク内の他のネットワーク要素に広報される。
３．決定：各々の指定された決定実施ネットワーク要素は、そのように指定された他のネットワーク要素が行ったローカル決定を受信時、ネットワークに関して１つの共同決定を選択実施する同じ所定の共同決定アルゴリズムを実行する。そのようなネットワーク要素のそれぞれが異なるローカル決定を行ったかもしれないので、これは重要である。
【００６４】
ＸＤＮＭ動作の全部を説明しうるシナリオは、以下の通りである（図１を参照して記述）。ネットワーク要素Ｎ１が無線ネットワークに到着し、そのＷＬＡＮインタフェースがネットワーク要素Ｎ２からの信号を検出する。ＸＤＮＭによって、Ｎ１とＮ２は、上に挙げたようなタイプの情報を送信することによって、それらのローカル動作環境を相互に発見することになる。次いでＮ１とＮ２は、やはりＸＤＮＭによって、どれほどの無線送信電力を使用すべきかをネゴシエートし、決定し、そして最後に設定する。
【００６５】
この初期フェーズの後に、Ｎ１のネットワークへの入場を許可するアドレスを取得および設定するために、第２のネゴシエーションおよび決定「レベル」が開始され得る。次いで、Ｎ１はサービス（例えば、ノードＮ３とのテレビ会議セッション）を要求し、所望のサービスに直接接続することが可能かどうかを検証すべきである（これはＸＤＮＭ以外の手段で行われる）。可能でない場合、Ｎ３（および場合によっては他のネットワーク要素）との通信を可能にするために使用するルーティングプロトコルを設定するために、別のネゴシエーションの開始が必要になる。
【００６６】
プロトコルネゴシエーションに関しては、サポートされているプロトコルおよび動作環境に関する他のパラメータが、ネットワーク要素間で交換され、事前設定のポリシーに従って決定される。そのようなポリシーの例は、過半数決定、加重決定またはデフォルトプロトコルを挙げることができるが、これらに限定されない（以下のさらなる記述を参照されたい）。
【００６７】
ＸＤＮＭがルーティングプロトコルのネゴシエーションに使用される例に関しては、以下の６つの起こりうるシナリオの中から１つを決定できよう。
１．ルーティングの必要なし。基本接続で十分である。
２．ルーティングが必要であり、適切な領域内プロトコルが選ばれる。
３．現在のプロトコルを取り替えるために、新しいプロトコルが選ばれる。
４．領域間でプロトコル変換が使用される（プロトコル変換はネットワーク要素内で常に起こっており、本明細書ではこれ以上説明しない）。
５．領域間ルーティングプロトコルが使用される（領域境界で行われる）。
６．ネットワーク要素が経路選定を望まない。パケットをパケットの経路選定ができるピアに転送する（ルーティング能力があるネットワーク要素による、ネットワークで使用するルーティングプロトコルのネゴシエーションとともに行われるローカル決定）。
【００６８】
特に能力の乏しいデバイスにおけるネゴシエーションを加速するために、恐らく環境に合わせて作られたルーティングプロトコルほど効率的ではないが、多くの異なるタイプの動作環境において高効率で使用できるデフォルトルーティングプロトコルの存在を、ＸＤＮＭは当てにしてもよい。
【００６９】
本発明の一実施形態について、各フェーズがいくつかの計算ステップから成る複数の異なるフェーズに関して、ここで図４Ａおよび４Ｂを参照してより詳細に説明する。これらのフェーズおよび計算ステップについては、以下の別々の見出しのもとでさらに説明する。説明では、ネットワーク要素は安定したネットワーク環境に配置され、全要素がアクティブであると想定している。これは、モビリティおよび無線リンクが存在するネットワークでは当てはまらないかもしれないが、説明のステップはこれらのタイプのネットワーク環境にも適用しうる。必要に応じて、モビリティに関するコメントをステップの説明の中で行う。
【００７０】
本発明の一実施形態における動作環境情報の配信について、ここでより詳細に説明する。
【００７１】
領域内の各ネットワーク要素は、領域内の他のネットワーク要素のそれぞれに、動作環境についてのローカル情報を配信する責任があり、これは図４ＡのステップＳ１（「ローカル環境情報収集」状態）で表されている。ローカル情報の例は前述し他通りである。本明細書での「ローカル」は、１つのネットワーク要素に特有でそれに限定された情報を指し、そのネットワーク要素を領域内の他のネットワーク要素に接続するインタフェースおよびリンクも含む。
【００７２】
ネットワーク要素間の動作環境情報を配信するための特定の配信メカニズムは重要ではなく、本明細書ではこれ以上説明しない。
【００７３】
ローカル動作環境情報の配信は様々な手法で行われてもよいし、またネットワークリソースを節約するために限定されてもよい。例えば、情報は、決定アルゴリズムを実行するネットワーク要素に向けてだけ、および／またはネットワーク要素のサブセットからだけ配信できよう。
【００７４】
図２Ａ〜２Ｃは、いくつかのありうるネットワーク状態を示す。最も簡単な場合は、図２Ａに示されるように、ネットワークが存在せず、決定プロセスは両方のノードで行われる。図２Ｂは次の状態を示し、ネットワークは形成されるが、ルーティングプロトコルは使用されていない。これは、適切なルーティングの決定が行われていない場合であろうが、それに限定されない。図２Ｃは最終的な状態を示し、これは完全に形成されたネットワークであり、例えば本発明の一実施形態を運用した結果として選ばれて設定されたルーティングプロトコルを有し、本明細書の領域にも相当する。
【００７５】
動作環境情報の配信により、環境決定アルゴリズム（ＸＤＮＭの不可欠の部分）を実行する責任があるネットワーク要素が、領域内のネットワーク要素から入手可能な最新の動作環境情報を入手することが可能になる。
【００７６】
以下にさらに詳しく説明する動的特性のおかげで、動作環境情報の配信は、周期的と、また場合によっては動作環境情報に影響を与える変化が起こった場合に直ぐにとの、両方で行われてもよい。
【００７７】
無線リンクを使用するネットワークでは、接続が頻繁に行われては終わるかもしれない。これは、ネットワーク要素のすべてに、ほかのすべてのネットワーク要素から連絡可能とはならないことがあるかもしれない結果になろう。この場合、これらの要素は、自要素の動作環境情報を広報できず、決定プロセスに参加しないであろう。これらのネットワーク要素は、後で確立したネットワークの一部になってもよい。
【００７８】
本発明の一実施形態の領域境界検出について、ここでより詳細に説明する。
【００７９】
動作環境情報の配信は、一般に領域外のネットワーク要素には届かないであろう。領域境界は、アドレスエリア間、セキュリティ制約間、管理責任および／または所有責任間などの境界によって特徴付けられてもよい。従って、配信メカニズムは、あるインタフェース／リンクを越える情報の送信が領域境界を越えることを意味するかどうかを確認することから一般に開始すべきである。領域境界の確認は、例としてアドレスプレフィックス情報および／またはある種のネットワーク（要素）アイデンティティを交換することによって達成されてもよい。領域境界が検出された場合およびそのときは、そのインタフェース／リンクを越えた動作環境情報のそれ以上の交換は一般に行われるべきでない。
【００８０】
ネットワーク要素が同時にいくつかの領域に属してもよいことに気付くはずである。このような場合、ネットワーク要素は、動作環境情報がネットワーク要素自体内に存在する領域境界を横切らないように適切に構成されるべきである。
【００８１】
領域境界を検出したとき、決定は、一般に、領域間で領域間ルーティングプロトコルを実行することである。
【００８２】
本発明の一実施形態の決定アルゴリズム（ローカルおよび共同）について、ここでより詳細に説明する。
【００８３】
領域内の１つ以上のネットワーク要素、場合によっては全部のネットワーク要素は、その領域に関して実行する１つのルーティングプロトコルを最終的に選択することになる（ルーティングプロトコルを使用しないという選択肢も含む）決定アルゴリズムを実行する責任を有し、動作環境情報の配信の一部として特定されたルーティングプロトコルの中だけから選択してもよい。ルーティングプロトコルの選択は、上に挙げた動作環境情報を考慮してもよいが、それに限定されない。
【００８４】
選択プロセス例には、ＧＳＭ、ＷＣＤＭＡ、ＢｌｕｅｔｏｏｔｈおよびＷＬＡＮのインタフェースならびにサポートしているルーティングプロトコル有するセルラ電話機を含むことができよう。
【００８５】
図３は、可能なデバイス２を示す。この場合のプロトコルの選択は、現在使用されているインタフェースに基づくことができよう。Ｂｌｕｅｔｏｏｔｈインタフェースが使用される場合はＢｌｕｅｌｉｎｅプロトコル、また他のインタフェースのいずれかが使用される場合はＴＯＲＡプロトコルである。
【００８６】
この責任を有する各ネットワーク要素は、ネットワーク要素自体の決定アルゴリズムを用いて自要素の（ローカル）決定をまず行う。これは、図４ＡのステップＳ２に表されている（「プロトコル選択」状態）。１つを超えるネットワーク要素が決定アルゴリズムを実行する場合、それらの要素はまた、自要素のローカル決定を互いに通知し、他のリモート決定を受信するために待たなければならない。これは、図４ＡのステップＳ３に表されている（「リモート決定持ち」状態）。
【００８７】
自要素のローカル決定アルゴリズムを実行する異なるネットワーク要素が、利用可能なルーティングプロトコル選択肢のセットの中から異なる決定に達した場合、それらの要素は、同一の共同決定に集合的に合意する必要がある。これは、図４ＢのステップＳ４に表されている（「決定戦略」状態）。これは、種々の異なる手法で達成されてもよく、いくつかの例について以下に説明する。ローカル決定アルゴリズムの実行能力があり共同決定に参加するノードは、共同決定を計算する同じロジックを使用するので、共同決定手順が事前設定されるべきである、および／またはデフォルト手順が続く。
【００８８】
過半数決定：この場合、決定は、決定アルゴリズムを実行するネットワーク要素の過半数が行ったローカル決定に基づく。この例では、過半数は、それらの５０％を超えるネットワーク要素が同じ決定を行ったことを意味し、次いでこれは、領域全体に責任を負う決定としても合意される。これは、図４ＢのステップＳ６に表されている（「最高票のプロトコルの選択」状態）。
【００８９】
加重決定：この場合、領域全体に責任を負う決定は、最大の「重さ」を有する決定アルゴリズムを実行するネットワーク要素が選択したルーティングアルゴリズムを選択することである。いくつかのネットワーク要素が同じ重さを有し、それが最大でもあるが、これらのそれぞれの決定が同一でない場合、（最大の重さを有する）それらの要素の間で、さらに前述の代替手法の過半数決定を行うことができよう。これは、図４ＢのステップＳ７に表されている（「加重票によるプロトコルの選択」）。
【００９０】
これらは、共同決定にどのように到達するかの単なる例にすぎないことは理解されるであろう。例えば、最も多いローカル決定もまた共同決定として選択でき、当業者には他の形態の決定ロジックも直ちに明白であろう。
【００９１】
１つの一貫して筋の通った決定が可能でない場合：共同決定が領域全体に責任を負う同一決定に帰着しないであろう場合、領域を分割するなどの代替案を考慮する必要がある。これは、図４ＢのステップＳ５に表されている（「適切なプロトコルが設定されない」状態）。一代替案は、デフォルトルーティングプロトコルに戻ることであろう。
【００９２】
ルーティングプロトコルの選択決定の広報：決定アルゴリズムを実行する１つ以上のネットワーク要素がいったんルーティングプロトコルを選択すると、これらのネットワーク要素の少なくとも１つは、選択したルーティングプロトコルの情報を領域内の他のすべてのネットワーク要素に広報する。
【００９３】
領域の動的側面：領域は決して静的ではなく、本発明の一実施形態は、ネットワーク要素がどの時点でも領域内に入り出て行ってもよい可能性（おそらくは断続的な接続のため）をサポートする。この場合、動作環境情報を広報後、決定アルゴリズムが実行され、現在のルーティングプロトコルが新しいネットワーク要素によって使用されうるかどうかをチェックすることになる。事実上これは、これらの動的特性のために、決定アルゴリズムが連続的に実行されてもよく、そして以前行った決定を再評価し、変更もしてもよいことを意味する。以前の決定が再評価される頻度は、可能性のあるポリシーとシステムの不安定および望ましくない変動の回避との両方に制約される。
【００９４】
通常、すべての決定実施ネットワーク要素は、すべての情報を受信していると想定されているであろう。そのような要素の情報受信を一時的に妨げる、ある種のネットワーク不安定が生じた際に何が起こるかについては、本開示の範囲外である。しかし、要するに、そのような状況では複数回の（再）送信を、たぶん送信ネットワーク要素への確認応答の返信とともに行うことができよう。それでもやはり決定に不一致がある場合（これは、非常に動的なネットワーク環境でさえ非常に起こりそうにない）、ネットワークが安定しておらず、分裂／分割を行うべきと宣言してもよい。従って、あるネットワーク要素がひょっとして異なる共同決定の情報を受信する場合、エラー状態を提起できよう。
【００９５】
他の側面：ネットワーク要素がルーティングを行わないことを選ぶ事例があろう。典型的な例は、専用ルータを有するネットワークに属するホストであろう。この場合、ネットワーク要素は、データをしかるべくルーティングする責任があるだろうルータに、すべてのパケットを転送するであろう。ルータの役を務めるネットワーク要素は、この役割を担っていることを領域内の近隣の要素に通知するであろう。
【００９６】
別の事例は、決定の実施に係わるネットワーク要素が特定のルーティングプロトコルを使用すべきとの決定に達するが、現時点でそのプロトコルが必要なすべてのネットワーク要素にはサポートされていない場合である。それらのネットワーク要素をルーティングループから除外する代わりに、決定されたルーティングプロトコルをインストールされているネットワーク要素が、選択されたルーティングプロトコルを持たない他のネットワーク要素のそれぞれに、このプロトコルをインストールするように取り計らう。
【００９７】
概観すると、本発明の一実施形態による方法は図９に要約される。方法は、領域境界検出ステップＭ１と、動作環境情報配信ステップＭ２と、ローカル決定実施ステップＭ３と、ローカル決定配信ステップＭ４と、共同決定実施ステップＭ５と、共同決定配信ステップＭ６とを備える。
【００９８】
本発明の一実施形態によるノードＮが、図１０に概略的に示されており、図９に示されるステップを実行するそれぞれの部分を備える。具体的には、ノードＮは、領域境界検出ステップＭ１を実行する領域境界検出部Ｐ１と、動作環境情報配信ステップＭ２を実行する動作環境情報配信部Ｐ２と、ローカル決定実施ステップＭ３を実行するローカル決定実施部Ｐ３と、ローカル決定配信ステップＭ４を実行するローカル決定配信部Ｐ４と、共同決定実施ステップＭ５を実行する共同決定実施部Ｐ５と、共同決定配信ステップＭ６を実行する共同決定配信部Ｐ６とを備える。配信の一般的ステップがその中に要求、送信および受信のステップを含んでもよいことは理解されるであろう。
【００９９】
図１０および図１１に示される部分の構成および動作は、これまでの説明および以下の説明から明らかになるであろう。
【０１００】
パーソナルエリアネットワークの状況における本発明の一実施形態について、ここで図５および図６を参照して説明する。
【０１０１】
図５は、上記の提案の方法（ＸＤＮＭ）を用いる起動している３つのデバイスを示す。これらのデバイスは、ラップトップ６と２つの携帯電話機２および４（ここでは、「灰色」２および「黒色」４と識別される）を備える。全デバイスは、利用可能なインタフェースの１つを通じて動作環境情報を交換するが、この例ではラップトップだけが決定アルゴリズム（ＤＡ）を実行するように指定されている。
【０１０２】
受信情報を使用して、ラップトップ６は、Ｂｌｕｅｔｏｏｔｈ−ＡＮプロトコルの使用を決定する。その理由は、全デバイスがそのルーティングプロトコルをサポートしていることに加えて、ルーティングに参加しているより小さなデバイスの電池電力を節約するアルゴリズムの要因からである。
【０１０３】
動作手順およびそれらの動作がなぜおよびどのように行われたかの説明については、図６Ａ〜６Ｃに示され、以下により詳細に記述する。図６Ａ〜６Ｃに描かれた動作は要約されているが、ＸＤＮＭ実行の一部として行われる最も関連深い動作を備えていることは理解されるであろう。
【０１０４】
ステップＴ１およびＴ２では、ラップトップ６が灰色携帯電話機２および黒色携帯電話機４のそれぞれに、どのルーティングプロトコルをサポートしているかに特に関する動作環境情報を要求する。この情報は、灰色携帯電話機２および黒色携帯電話機４からそれぞれステップＴ３およびＴ４で提供される。両方とも、リスト｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ｝を戻す。
【０１０５】
ステップＴ５では、ラップトップ６は、使用すべきルーティングプロトコルを決定しようとする。ラップトップ６自体がリスト｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ、ＯＳＰＦ｝のプロトコルをサポートするので、全デバイスに共通の１つを超えるプロトコル｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ｝がある。
【０１０６】
このため、ラップトップ６は、灰色携帯電話機２および黒色携帯電話機４にそれぞれステップＴ６およびＴ７で、サポートしているルーティングプロトコルに関連する電力消費に特に関する追加の動作環境情報を要求する。この情報は、灰色携帯電話機２および黒色携帯電話機４からそれぞれステップＴ８およびＴ９で提供される。
【０１０７】
ステップＴ１０では、ラップトップ６は、灰色携帯電話機２および黒色携帯電話機４から受信した追加の動作環境情報を使用して、使用すべき最善のプロトコルはＢｌｕｅｔｏｏｔｈ−ＡＮと決定する。この決定は、灰色携帯電話機２および黒色携帯電話機４にそれぞれステップＴ１１およびＴ１２で広報される。
【０１０８】
先の図９の概要の方法図に関しては、上記のように、ノードが同じ領域に関することが分かっているので、図９の領域境界検出ステップＭ１は明示的に必要ない。
【０１０９】
図９の動作環境情報配信ステップＭ２は、ステップＴ１〜Ｔ４およびＴ６〜Ｔ９に相当する（配信は２段階で実行される）。ラップトップ６も、自装置の動作環境情報を携帯電話機２および４と共有する（とはいえ、この共有の実行に必要なステップは明示的に示されていない）。
【０１１０】
図９のローカル決定実施ステップＭ３は、ステップＴ５およびＴ１０に相当する（決定は２段階で実行される）。
【０１１１】
ラップトップ６は唯一の指定された決定実施ノードなので、ローカル決定配信ステップＭ４も共同決定実施ステップＭ５も必要ない（ローカル決定は共同決定と同等である）。
【０１１２】
共同決定配信ステップＭ６はステップＴ１１〜Ｔ１４に相当する。
【０１１３】
ホームエリアネットワークの状況における本発明の一実施形態について、ここで図７および８を参照して説明する。
【０１１４】
図７は、５つの異なるデバイス（ブロードバンドルータ１４、ＷＬＡＮアクセスポイント２２、ラップトップ１８、デスクトップ１６およびＰＤＡ２０）を有するホームエリアネットワークと、領域境界の向こう側のアクセスネットワークに在る別のデバイス（アクセスルータ１２）とを示す。図７の全デバイスが提案の方法（ＸＤＮＭ）を実行する一方で、ホームエリアネットワークの３つのデバイスが決定アルゴリズム（ＤＡ）の実行も行うように指定され、図７に印が付けられている。
【０１１５】
以下に示す表は、図７のデバイスのそれぞれがサポートしているインタフェースおよびサポートしているルーティングプロトコルの概要である。図７は、使用しているインタフェースのある特定の設定を描写する、すなわち、ここに挙げているサポートしているインタフェースのすべてをこの特定の設定で使用しているわけではないことに注意すべきである。ＤＡを実行するデバイスは等しい重さを有し、この例では過半数共同決定アルゴリズムを使用しているとも想定している。
【０１１６】
【表１】
【０１１７】
種々の要素によって実行される方法のいくつかのステップが図８Ａおよび８Ｂに示されており、これらについて以下に説明する。いくつかの最初のステップは、図８Ａおよび８Ｂには示されていないが、それらについてまず説明する。
【０１１８】
例えばネットワークまたはノード／デバイスのアイデンティティを識別する情報を送信することによって、ＸＤＮＭによって領域境界が確認される（図９のステップＭ１に相当）。この場合、これは、ＸＤＮＭによりアクセスルータ１２とブロードバンドルータ１４との間で送信されるこれ以上の情報を発生せず、この特定の場合には、リンクをまたがって使用されるルーティングプロトコルももたらさない。
【０１１９】
ホームエリアネットワークに関しては、サポートしている（および使用している）インタフェースについての情報および各デバイスがどのルーティングプロトコルをサポートしているかの情報が広報される（図９のステップＭ２に相当）。ブロードバンドルータ１４およびデスクトップ１６におけるＤＡの実行（図９のステップＭ３に相当）は、これらのノードの両方ともＴＯＲＡＮプロトコルを使用するというローカル決定になるのに対して、ラップトップ１８のＤＡの実行は、（ラップトップ１８がホームエリアネットワーク内の他の全デバイスにＢｌｕｅｔｏｏｔｈ−ＡＮプロトコルの無料のダウンロードを提供して）Ｂｌｕｅｔｏｏｔｈ−ＡＮプロトコルを使用するというローカル決定になる。
【０１２０】
ステップＱ１では、各々の指定された決定実施ノードで行われたローカル決定は、他の指定された決定実施ノードに互いに広報される（図９のステップＭ４に相当）。
【０１２１】
次いで、各指定された決定実施ノードにおいて、（当該ノードのローカル決定および他の指定された決定実施ノードから受信したローカル決定を備える）ローカル決定のセットに基づき、共同決定が行われる。これは、図９のステップＭ５に相当する。この場合、過半数決定が行われ、ＴＯＲＡＮプロトコルがルーティングプロトコルとして選択される。
【０１２２】
ラップトップ１８は、共同決定実施アルゴリズムの実行からもたらされたプロトコルとは異なるプロトコルに決定していたので、ステップＱ２で、他の指定された決定実施ノードの特定の１つ（この例では、デスクトップ１６）に、そのノードが行った過半数決定を受け入れると通知する。ステップＱ５で、ブロードバンドルータ１４も、その決定の受け入れをデスクトップに通知する。
【０１２３】
ＰＤＡ２０は、ＤＡを実行しないので、決定実施ノードが到達したルーティングプロトコルの決定をまだ知らない。ステップＱ３で、共同決定の通知を待っていたＰＤＡ２０に、共同決定が通知される（図９のステップＭ６に相当）。この例では、ＰＤＡ２０は、電力制約と電池電力の節約のために共同決定を拒否し、どのルーティングプロトコルも使用せずに、ホストの役を務めると決定し、この決定を、ステップＱ４で別のノードに通知する。
【０１２４】
要約すると、本発明の一実施形態は、本明細書ではＸＤＮＭとして知られる方法を規定し、この方法は、自己設定しうる（ＩＰネットワークなどの）ネットワークをサポートするために使用されてもよい。ネットワーク要素間でローカル動作環境情報を広報することによって、ネットワーク内のネットワーク要素は、例えば様々なプロトコル選択肢、アドレス等を有するネットワーク要素をどのように適切に設定するかについて、自要素のものだが集合的に合意した決定を行いうる。本発明の一実施形態は、例えばネットワーク要素がネットワークに加わったり出て行ったりしてもよく、それにより以前の決定の継続的な再評価に導き、その結果ネットワーク内のネットワーク要素の再設定にさらに導きうる、動的ネットワーク環境もサポートする。
【０１２５】
全体として、自己設定ネットワーク要素および自己設定ネットワークは、ネットワーク管理のコストを大幅に改善し、本発明の一実施形態は、所有の総コストの引き下げに向けた重要なステップを提供しうる。
【０１２６】
１つ以上の上記のコンポーネントの動作がデバイスまたは装置上で動作するプログラムによって制御されてもよいことは理解されるであろう。このような動作プログラムは、コンピュータで読み取り可能な記憶媒体に格納されてもよく、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号などの信号の中に具体化できよう。添付の特許請求の範囲は、それ自体で、または運搬媒体上の記録として、または信号として、または他の任意の形態で、動作プログラムを包含していると解釈される。
【０１２７】
添付の特許請求の範囲に規定される本発明の範囲から逸脱することなしに、上記の実施形態に種々の変更を行いうることも、当業者に理解されるであろう。
【技術分野】
【０００１】
本発明は、通信ネットワークで使用する方法および装置に関する。
【背景技術】
【０００２】
既存のネットワークでは、様々なネットワーク要素の設定時点において、オフラインで読み出された多くの事前知識および情報が使用され、その後この設定は、ネットワークが運用中の長期にわたり、ほとんど変更されない。この事前知識は、いくつかの例を挙げると、ネットワーク内のネットワーク要素数、トポロジ、リンクおよびネットワーク要素の容量、ならびにＱｏＳ特性から成る。
【０００３】
将来のネットワーキングでは、全く新しい次元の動的性質が期待されている。アンビエントネットワーク（ＡＮ、Ambient Network）は、新しいネットワーキング概念であり、異なるオペレータ領域または技術領域に属し得る異種のネットワークの連携を可能にすることを目指している。この連携は、トランスペアレントで、オンデマンドで確立され、それ故「プラグアンドプレイ」動作をサポートすべきである。すなわち、ネットワークを形成するとき、およびどのように互いに接続するかについて、以前の設定もネゴシエーションも必要とされるべきでない。
【０００４】
アンビエントネットワーク（ＡＮ）は、第６次フレームワークプログラムの優先テーマの情報社会技術（ＩＳＴ、Information Society Technology）のもとで、欧州委員会が協賛している総合計画（ＩＰ、Integrated Project）である。
【０００５】
この新しい構想は、検討され、ワイヤレスワールドイニシアティブの一部であるアンビエントネットワーク計画に成長した。アンビエントネットワークは、第６次フレームワークプログラムの優先テーマの情報社会技術のもとで、欧州委員会が協賛している総合計画である。この計画は、２００４年に開始され、２００７年に終了する第２フェーズを現在実施中である。アンビエントネットワーク概念に基づくネットワークは、２０１２〜２０１５年頃に、ことによるともっと早くに運用開始になりうる。
【０００６】
アンビエントネットワーキングに関して作成または再規定されなければならない多くの概念の中でも、これらの異種のネットワークが混成される特徴が予見できることから、ルーティングは最も重要なものの１つである。同一のネットワーク要素が、ある時点のいわゆるアドホックネットワーク環境において、設置されて使用され、その後、より固定的なインフラタイプのネットワーク環境に、移動され再設置されてもよい。このタイプの動作環境に関しては、異なる動作環境において異なるルーティングプロトコルを使用できるマルチプロトコルルーティングアプローチが、「どれにも合う(one-size-fits-all)」単一プロトコルアプローチに代わるものとして妥当と思われる。
【０００７】
しかし、複数のルーティングプロトコルが同時に動作するのを許すことによって、かつ異なる環境および同じ環境でさえも複数のプロトコルを実施することによって、ネットワーク領域内およびネットワーク領域間で、できるだけ効率的に情報をルーティングしうるように、サポートしているプロトコルの中からどのように選ぶかの問題が生じる。
【０００８】
マルチプロトコル環境を考慮した２つのアプローチが、非特許文献１および非特許文献２に記載されている。
【０００９】
非特許文献１では、どのプロトコルが使用されなければならないかを識別するために使用しうるホスト情報を配信するために、ディレクトリサービスを使用するプロトコルネゴシエーション解決手段が提案されている。ディレクトリが利用可能でない場合、ネゴシエーションプロトコルは、使用可能なプロトコルを発見するために、通信中のピアを調べてもよい。従って、使用されているアプローチは、マルチプロトコル通信をサポートするために、調査とディレクトリサービスを混合している。
【００１０】
非特許文献２は、この相互接続性を提供するために、いくつかの目標の設定を含む相互接続性についての調査を提示する。異種の混成は、プロトコルミスマッチまたはインタフェースミスマッチと描写される。これらの問題を解決または軽減する３つの可能なアプローチも提示されている。
【００１１】
第１のアプローチは、ペアワイズアプローチであり、このアプローチでは、コンポーネントＡがコンポーネントＢとの通信を望むとき、１対の変換機能が存在すると想定している。ＡメッセージからＢメッセージへの変換に加えて逆方向への変換も存在しなければならないことから、１対の機能が必要である。第２のアプローチは、共通言語アプローチであり、このアプローチでは、特殊言語Ｓが使用され、あらゆるコンポーネントがその言語で連絡しうる。これは、単一標準と見なしてもよく、このアプローチはＸＤＮＭに最も近い。最後のアプローチは仲介者アプローチ、すなわち第三者がいるハイブリッドアプローチであり、各第三者は、種々の環境で使用される多くのプロトコルの中のあるサブセットを理解する。
【００１２】
特許文献１および特許文献２は、より高いスループットの提供またはモデムの標準ハンドシェイク手順で確立された最初に決めた設定の維持の提供のプロセスに係わるペアに対してより良い機能を選択するために、各モデムがサポートしている機能の情報交換を通じて通信を改善するように、モデム間での機能のネゴシエーションについての提案に焦点を合わせており、非常に具体的である。
【００１３】
特許文献３では、ローカルネットワークの要素による、自要素の通信のために共通プロトコルの設定を可能にする解決手段を著者が明記している。この文献は、２つの係わるノード間の実施プロセスを開示している。提案の解決手段の基本動作は、各ネットワーク要素が使用するプロトコルの互換性を検証し、同様である場合、変更は行われないが、それぞれの要素が異なるプロトコルで動作している場合、それらの１つの要素が、使用すべきプロトコルを決定するより優先順位の高い局に選択される。別の制約は、それがＣＳＭＡ／ＣＤ ＬＡＮでだけ機能することである。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】米国特許第４９５３２１０号明細書（Paul E. McGlynn他、「同期モデムのための機能ネゴシエーションプロトコル（Feature negotiation protocol for a synchronous modem）」、出願日：1990年2月22日、発行日：1990年8月28日）
【特許文献２】米国特許第４９０５２８２号明細書（Paul E. McGlynn他、「機能ネゴシエーションプロトコルおよび高速半二重モデムのための動的調節可能再教育手順（Feature Negotiation Protocol and Dynamically Adjustable RetrainingSequence for a High Speed Half Duplex MODEM）」、出願日：1988年10月19日、発行日：1990年2月27日）
【特許文献３】米国特許第５５８６１１７号明細書（Brian C. Edem他、「複数のプロトコル能力を有するデバイスによる、共通プロトコル設定への設定を可能にする方法および装置（Method and Apparatus Which allows Device with Multiple ProtocolCapabilities to Configure to a Common Protocol Configuration）」、出願日：1994年6月20日、発行日：1996年12月17日
【非特許文献】
【００１５】
【非特許文献１】Clark, R.、 Ammar, M.、 Calvert, K.共著、「マルチプロトコルネットワークにおけるプロトコル発見（Protocol discovery in multi protocol networks）」、Mobile and Networks Applications Journal、2006年6月、オンライン出版 http://www.springerlink.com/content/hn3241724163620x
【非特許文献２】F. Bamberger、 P. Ford、 J. M. Wing、「ＮＩＩに関するＲ＆Ｄの「相互接続性」セクション：技術チャレンジ（“Interoperability,” section inR&D for the NII: Technical Challenges）」、M. K. Vernon、 E. D. Lazowska、 S. D. Personick報告書編集、Interuniversity Communications Council, Inc.(EDUCOM)、 1994年
【発明の概要】
【課題を解決するための手段】
【００１６】
本発明の第１の態様によれば、ネットワークの共通設定パラメータを決定する分散の方法が提供され、そのネットワークは本方法を実行するように指定された少なくとも１つのノードを備え、指定のノードにおいて、自ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する工程と、もしあれば他の指定ノードへそのローカル決定を送信する工程と、もしあれば他の指定ノードが行った対応するローカル決定を受信する工程と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する工程とを備える分散方法が提供される。
【００１７】
本方法は、ネットワークの少なくとも１つの他のノードから少なくとも１つの他のノードのローカル動作環境に関するネットワーク情報を受信する工程と、受信した情報を用いてローカル決定を実施する工程とを備えてもよい。
【００１８】
本方法は、共同決定を非指定ノードに送信する工程を備えてもよい。
【００１９】
決定アルゴリズムは、少なくとも１つの指定ノードが行った最も多いローカル決定を採用する工程を備えてもよい。
【００２０】
共同決定を実施する工程は、自ノードのローカル決定および少なくとも１つの指定ノードから受信したローカル決定の中で過半数を占める決定を採用する工程を備えてもよい。
【００２１】
ノードの動作環境情報は、そのノードの重さを備えてもよく、共同決定を実施する工程は、最大の重さを有する少なくとも１つの指定ノードが行った決定を採用する工程を備えてもよい。
【００２２】
設定パラメータは、ネットワークで用いるルーティングプロトコルと、ネットワークインタフェースアドレスと、接続確立用のシグナリングプロトコルと、モビリティ管理用のプロトコルと、コーデックと、リンク層スケジューリングアルゴリズムと、送信電力の少なくとも１つを備えてもよい。
【００２３】
ローカル動作環境情報は、ノードがサポートしているプロトコルと、例えば処理能力および利用可能メモリなどのノードのハードウェア仕様と、例えばアドレス指定情報などのネットワークノード間のリンクおよび／またはインタフェースと、ノードの１つ以上のアイデンティティと、ネットワーク内のノード数と、例えばサポートしている能力、メディアおよび符号化のサポート、実施ポリシーなどのノードの状態情報と、デフォルトルーティングパラメータと、追加でネゴシエートするパラメータの中の、少なくとも１つを備えてもよい。
【００２４】
本方法は、ローカル動作環境情報を少なくとも１つの他の指定ノードに、そこでの本方法の実行に使用するために送信する工程を備えてもよい。
【００２５】
本方法は、少なくとも１つの他のノードへの情報の送信が、情報に領域境界を越えさせるだろうかどうかを判定する工程と、越えないと判定された場合だけ情報を送信する工程を備えてもよい。
【００２６】
本方法は、所定の間隔でローカル動作環境情報を送信する工程を備えてもよい。
【００２７】
本方法は、ローカル動作環境情報に影響を与える変更の発生に応じて、ローカル動作環境情報を送信する工程を備えてもよい。
【００２８】
本方法は、同じ領域内の別のノードだけにローカル動作環境情報を送信する工程を備えてもよい。
【００２９】
ネットワークは、単一の領域であっても、または単一の領域に関しても、または単一の領域を備えてもよい。
【００３０】
ネットワークは、本方法を実行するように指定された複数のノードを備えてもよい。
【００３１】
ネットワークのすべてのノードが、本方法を実行するように指定されてもよい。
【００３２】
ネットワークは、ＩＰネットワークを備えてもよい。
【００３３】
本方法は、各指定ノードで種々の工程を実行し、それによりシステム全体の方法の提供を備えてもよい。
【００３４】
本方法は、例えば共通設定パラメータに基づいた接続の確立などにより、共通設定パラメータを適用する工程を備えてもよい。
【００３５】
本発明の第２の態様によれば、ネットワークの共通設定パラメータを決定する分散方法の少なくとも一部を実行するように指定された、ネットワーク内のノードとして使用するかまたはノード内で使用する装置が提供され、本装置は、ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する手段と、もしあれば他の指定ノードにそのローカル決定を送信する手段と、もしあれば他の指定ノードが行った対応するローカル決定を受信する手段と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する手段とを備える。
【００３６】
本装置は、ネットワークの少なくとも１つの他のノードから、少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段を備えてもよく、受信した情報はローカル決定の実施に用いられる。
【００３７】
本装置は、共同決定を非指定ノードに送信する手段を備えてもよい。
【００３８】
共同決定を実施する手段は、少なくとも１つの指定ノードが行った最も多いローカル決定を採用するように構成されてもよい。
【００３９】
共同決定を実施する手段は、自ノードのローカル決定および少なくとも１つの指定ノードから受信したローカル決定の中から、過半数を占める決定を採用するように構成されてもよい。
【００４０】
ノードの動作環境情報はノードの重さを備えてもよく、共同決定を実施する手段は、最大の重さを有する少なくとも１つのノードが行った決定を採用するように構成されてもよい。
【００４１】
本装置は、ローカル動作環境情報を少なくとも１つの他の指定ノードに、そこでの本方法の実行に使用するために送信する手段を備えてもよい。
【００４２】
本装置は、少なくとも１つの他のノードへの情報の送信が情報に領域境界を越えさせるだろうかどうかを判定する手段と、越えないと判定された場合だけ情報を送信する手段とを備えてもよい。
【００４３】
本装置は、例えば共通設定パラメータに基づいた接続の確立などにより、共通設定パラメータを適用する手段を備えてもよい。
【００４４】
本発明の第３の態様によれば、ネットワークの共通設定パラメータを決定する分散型システムが提供され、本システムは、ネットワークの少なくとも１つの指定ノードのそれぞれにおいて、自ノードのローカル動作環境に関する情報に基づいて設定パラメータに係わるローカル決定を実施する手段と、もしあれば他の指定ノードへそのローカル決定を送信する手段と、もしあれば他の指定ノードが行った対応するローカル決定を受信する手段と、その受信に続いて、そのローカル決定および受信したローカル決定に基づいて、指定ノードに共通の決定アルゴリズムを用いて、設定パラメータに係わる共同決定を実施する手段とを備える。
【００４５】
本システムは、各指定ノードにおいて、ネットワークの少なくとも１つの他のノードから少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段と、受信した情報を使用してローカル決定を実施する手段とを備えてもよい。
【００４６】
本システムは、各指定ノードにおいて、共同決定を非指定ノードに送信する手段を備えてもよい。
【００４７】
本発明の第４の態様によれば、装置を本発明の第１の態様による方法を実施するように制御するプログラム、または、装置にロードされたとき、装置を本発明の第２または第３の態様による装置にするプログラムが提供される。本プログラムは、運搬媒体で運ばれてもよい。運搬媒体は記憶媒体でもよい。運搬媒体は伝送媒体でもよい。
【００４８】
本発明の第５の態様によれば、本発明の第４の態様によるプログラムによってプログラムされた装置が提供される。
【００４９】
本発明の第６の態様によれば、本発明の第４の態様によるプログラムを格納している記憶媒体が提供される。
【図面の簡単な説明】
【００５０】
【図１】本発明の一実施形態の動作例の説明に使用する図である。
【図２Ａ】異なるタイプのネットワーク状態を示す図である。
【図２Ｂ】異なるタイプのネットワーク状態を示す図である。
【図２Ｃ】異なるタイプのネットワーク状態を示す図である。
【図３】本発明の一実施形態とともに使用するための、サポートしているある種のインタフェースおよびルーティングプロトコルを有するデバイス例を示す図である。
【図４Ａ】本発明の一実施形態による、ネットワークノードが実行するステップを示す図である。
【図４Ｂ】本発明の一実施形態による、ネットワークノードが実行するステップを示す図である。
【図５】パーソナルエリアネットワーク（ＰＡＮ）用のルーティングプロトコルを選択するために、３つのデバイスが本発明の一実施形態に従って動作する一例の説明に使用する図である。
【図６Ａ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図６Ｂ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図６Ｃ】本発明の一実施形態において、図５のデバイスが実行する動作手順例を示す図である。
【図７】ホームアクセスネットワーク用のルーティングプロトコルを選択するために、６つのデバイスが本発明の一実施形態に従って動作する一例の説明に使用する図である。
【図８Ａ】本発明の一実施形態において、図７のデバイスが実行する動作手順例を示す図である。
【図８Ｂ】本発明の一実施形態において、図７のデバイスが実行する動作手順例を示す図である。
【図９】本発明の一実施形態で実行されるステップを示す概略フロー図である。
【図１０】本発明を具体化するデバイスの部品を示す概略ブロック図である。
【発明を実施するための形態】
【００５１】
上記で説明したように、ネットワーク要素の動的設定は現在非常に限られており、この限られている主な理由は、ネットワークが自らの設定および環境について「自己認識」する能力を持たないことである。この知識は、ほとんどの場合中央管理システムに存在し、そこからネットワーク要素は設定情報を取得する。
【００５２】
動的設定がサポートされている数少ない例外は、ある種のルーティングプロトコルを用いたルータでのルーティングテーブルの作成と、ホスト構成プロトコルを用いたホストのＩＰアドレスの設定である。
【００５３】
しかし、これらの数少ない例はよく制御されたネットワーク環境で動作し、そこでは、ネットワークトポロジおよびある種の機能の異なるネットワーク要素への分配は、ルーティングプロトコルまたはホスト構成プロトコルが動作する以前に既知となっている。
【００５４】
将来のネットワークでは、ネットワークトポロジおよび機能の分配が前もってわかると想定することはできない。さらに、ネットワークトポロジおよび機能は、（急速に）変化するかも知れず、ひいては動作環境の変化のために、ネットワーク要素のオンデマンドかつリアルタイムの再設定の必要があろう。
【００５５】
上記で提示の論文および特許のいずれにおいても、起こりうる環境を検証するためにネットワーク要素間のネゴシエーションの問題に注目し、異種の要素をサポートしうる通信インフラストラクチャをより容易かつより自動的に提供するために、ノードの利用可能な技術およびプロトコルを考慮して最善のものを選択することはなされていない。本発明の一実施形態では、新規な方法を規定することによって、現在の最先端技術のこれらの欠点に取り組むことを目指している。新規な方法は、広報（dissemination）・ネゴシエーション・決定スキームを通じてネットワーク動作環境をネットワーク要素が知るようになることで、ネットワーク要素を動的に選択し設定するために使用しうるものである。
【００５６】
本発明の一実施形態による解決策は、本明細書では「拡張ネットワーク環境発見およびネゴシエーション方法（ＸＤＮＭ、Extensible Network Environment Discovery and Negotiation Method）」と称する方法を使用し、ＸＤＮＭによって広報されたある種の情報のセットに基づき、使用すべき最善のルーティングプロトコルであろうプロトコルを選択決定する。プロトコルは、ネットワーク要素間のインタフェースにまたがって領域内ルーティングかそれとも領域間ルーティングが使用されるべきかについても決定できよう。
【００５７】
ＸＤＮＭは、適切なルーティングプロトコルを選択するための「メタプロトコル」として使用されるだけの範囲に限定されないことは明らかであり、ネットワーク要素の他のリアルタイム設定の基盤としての使用に役立つ「メタプロトコル」でもあってもよい。
【００５８】
以下の記述では、本発明の一実施形態の基本概念について適切なルーティングプロトコルの選択に関して述べるが、上記で説明したように、本発明は、他の設定パラメータの選択決定に使用されてもよい。そのような例は、ネットワークインタフェースアドレス、接続確立用のシグナリングプロトコル、およびモビリティ管理用のプロトコルであろう。
【００５９】
ＸＤＮＭを適用しうる典型的な状況は、あらゆる要素における以前の設定を用いずに、ネットワークのノードが使用する機能およびプロトコルを設定する状況である。そのような機能の設定が、ネットワーク動作環境を「自己認識」するＸＤＮＭの特性によって可能になる。
【００６０】
以下でさらに詳しく説明する特定の例のほかに、ＸＤＮＭのいくつかの使用例を挙げると、ビデオアプリケーションがネットワークリソースの使用を向上するために使用しなければならないコーデックのネゴシエーション、送信データの衝突を避けるためのリンク層スケジューリングアルゴリズム、およびバッテリ使用時間を長くするために使用すべき無線電力がある。
【００６１】
ルーティングプロトコルに関しては、ＸＤＮＭは、現在の動作環境についての情報に基づき、使用すべき最善のルーティングプロトコルが何であるかについての決定を可能にする。この動作環境情報は、以下から成ることができようが、それらに限定されないことは明らかである。
【００６２】
・ネットワーク要素がサポートしているプロトコル
・例えば処理能力および利用可能メモリに関して表された、ネットワーク要素のハードウェア仕様
・ネットワーク要素間のリンク／インタフェースについてのアドレス指定情報を含む情報
・ネットワーク要素のアイデンティティ（場合によっては、アイデンティティはアドレスプレフィックスに等しくできよう）（＊）
・領域内のネットワーク要素数
・各ネットワーク要素の「重さ」
・参加ノードのそれぞれがサポートしている能力と、メディアおよび符号化サポートと、実施ポリシーとを含む状態情報
・デフォルトルーティングパラメータ
・オプションでネゴシエートされてもよい追加のパラメータ
なお、上記でアスタリスク（＊）の付いた情報は、ＸＤＮＭの実施において必須とするのが普通であろう。
【００６３】
ＸＤＮＭは、３つの基本フェーズで動作すると考えられてもよい。
１．発見：各ネットワーク要素が、ネットワーク内の他のネットワーク要素に自要素のローカル動作環境情報を広報する。
２．ネゴシエーション：決定を実施する能力のある（決定することを指定された）各ネットワーク要素が、自要素のローカル決定アルゴリズムを用いて１つ以上の設定パラメータに係わるローカル（または仮の）決定を行う。この決定は、ネットワーク内の他のネットワーク要素に広報される。
３．決定：各々の指定された決定実施ネットワーク要素は、そのように指定された他のネットワーク要素が行ったローカル決定を受信時、ネットワークに関して１つの共同決定を選択実施する同じ所定の共同決定アルゴリズムを実行する。そのようなネットワーク要素のそれぞれが異なるローカル決定を行ったかもしれないので、これは重要である。
【００６４】
ＸＤＮＭ動作の全部を説明しうるシナリオは、以下の通りである（図１を参照して記述）。ネットワーク要素Ｎ１が無線ネットワークに到着し、そのＷＬＡＮインタフェースがネットワーク要素Ｎ２からの信号を検出する。ＸＤＮＭによって、Ｎ１とＮ２は、上に挙げたようなタイプの情報を送信することによって、それらのローカル動作環境を相互に発見することになる。次いでＮ１とＮ２は、やはりＸＤＮＭによって、どれほどの無線送信電力を使用すべきかをネゴシエートし、決定し、そして最後に設定する。
【００６５】
この初期フェーズの後に、Ｎ１のネットワークへの入場を許可するアドレスを取得および設定するために、第２のネゴシエーションおよび決定「レベル」が開始され得る。次いで、Ｎ１はサービス（例えば、ノードＮ３とのテレビ会議セッション）を要求し、所望のサービスに直接接続することが可能かどうかを検証すべきである（これはＸＤＮＭ以外の手段で行われる）。可能でない場合、Ｎ３（および場合によっては他のネットワーク要素）との通信を可能にするために使用するルーティングプロトコルを設定するために、別のネゴシエーションの開始が必要になる。
【００６６】
プロトコルネゴシエーションに関しては、サポートされているプロトコルおよび動作環境に関する他のパラメータが、ネットワーク要素間で交換され、事前設定のポリシーに従って決定される。そのようなポリシーの例は、過半数決定、加重決定またはデフォルトプロトコルを挙げることができるが、これらに限定されない（以下のさらなる記述を参照されたい）。
【００６７】
ＸＤＮＭがルーティングプロトコルのネゴシエーションに使用される例に関しては、以下の６つの起こりうるシナリオの中から１つを決定できよう。
１．ルーティングの必要なし。基本接続で十分である。
２．ルーティングが必要であり、適切な領域内プロトコルが選ばれる。
３．現在のプロトコルを取り替えるために、新しいプロトコルが選ばれる。
４．領域間でプロトコル変換が使用される（プロトコル変換はネットワーク要素内で常に起こっており、本明細書ではこれ以上説明しない）。
５．領域間ルーティングプロトコルが使用される（領域境界で行われる）。
６．ネットワーク要素が経路選定を望まない。パケットをパケットの経路選定ができるピアに転送する（ルーティング能力があるネットワーク要素による、ネットワークで使用するルーティングプロトコルのネゴシエーションとともに行われるローカル決定）。
【００６８】
特に能力の乏しいデバイスにおけるネゴシエーションを加速するために、恐らく環境に合わせて作られたルーティングプロトコルほど効率的ではないが、多くの異なるタイプの動作環境において高効率で使用できるデフォルトルーティングプロトコルの存在を、ＸＤＮＭは当てにしてもよい。
【００６９】
本発明の一実施形態について、各フェーズがいくつかの計算ステップから成る複数の異なるフェーズに関して、ここで図４Ａおよび４Ｂを参照してより詳細に説明する。これらのフェーズおよび計算ステップについては、以下の別々の見出しのもとでさらに説明する。説明では、ネットワーク要素は安定したネットワーク環境に配置され、全要素がアクティブであると想定している。これは、モビリティおよび無線リンクが存在するネットワークでは当てはまらないかもしれないが、説明のステップはこれらのタイプのネットワーク環境にも適用しうる。必要に応じて、モビリティに関するコメントをステップの説明の中で行う。
【００７０】
本発明の一実施形態における動作環境情報の配信について、ここでより詳細に説明する。
【００７１】
領域内の各ネットワーク要素は、領域内の他のネットワーク要素のそれぞれに、動作環境についてのローカル情報を配信する責任があり、これは図４ＡのステップＳ１（「ローカル環境情報収集」状態）で表されている。ローカル情報の例は前述し他通りである。本明細書での「ローカル」は、１つのネットワーク要素に特有でそれに限定された情報を指し、そのネットワーク要素を領域内の他のネットワーク要素に接続するインタフェースおよびリンクも含む。
【００７２】
ネットワーク要素間の動作環境情報を配信するための特定の配信メカニズムは重要ではなく、本明細書ではこれ以上説明しない。
【００７３】
ローカル動作環境情報の配信は様々な手法で行われてもよいし、またネットワークリソースを節約するために限定されてもよい。例えば、情報は、決定アルゴリズムを実行するネットワーク要素に向けてだけ、および／またはネットワーク要素のサブセットからだけ配信できよう。
【００７４】
図２Ａ〜２Ｃは、いくつかのありうるネットワーク状態を示す。最も簡単な場合は、図２Ａに示されるように、ネットワークが存在せず、決定プロセスは両方のノードで行われる。図２Ｂは次の状態を示し、ネットワークは形成されるが、ルーティングプロトコルは使用されていない。これは、適切なルーティングの決定が行われていない場合であろうが、それに限定されない。図２Ｃは最終的な状態を示し、これは完全に形成されたネットワークであり、例えば本発明の一実施形態を運用した結果として選ばれて設定されたルーティングプロトコルを有し、本明細書の領域にも相当する。
【００７５】
動作環境情報の配信により、環境決定アルゴリズム（ＸＤＮＭの不可欠の部分）を実行する責任があるネットワーク要素が、領域内のネットワーク要素から入手可能な最新の動作環境情報を入手することが可能になる。
【００７６】
以下にさらに詳しく説明する動的特性のおかげで、動作環境情報の配信は、周期的と、また場合によっては動作環境情報に影響を与える変化が起こった場合に直ぐにとの、両方で行われてもよい。
【００７７】
無線リンクを使用するネットワークでは、接続が頻繁に行われては終わるかもしれない。これは、ネットワーク要素のすべてに、ほかのすべてのネットワーク要素から連絡可能とはならないことがあるかもしれない結果になろう。この場合、これらの要素は、自要素の動作環境情報を広報できず、決定プロセスに参加しないであろう。これらのネットワーク要素は、後で確立したネットワークの一部になってもよい。
【００７８】
本発明の一実施形態の領域境界検出について、ここでより詳細に説明する。
【００７９】
動作環境情報の配信は、一般に領域外のネットワーク要素には届かないであろう。領域境界は、アドレスエリア間、セキュリティ制約間、管理責任および／または所有責任間などの境界によって特徴付けられてもよい。従って、配信メカニズムは、あるインタフェース／リンクを越える情報の送信が領域境界を越えることを意味するかどうかを確認することから一般に開始すべきである。領域境界の確認は、例としてアドレスプレフィックス情報および／またはある種のネットワーク（要素）アイデンティティを交換することによって達成されてもよい。領域境界が検出された場合およびそのときは、そのインタフェース／リンクを越えた動作環境情報のそれ以上の交換は一般に行われるべきでない。
【００８０】
ネットワーク要素が同時にいくつかの領域に属してもよいことに気付くはずである。このような場合、ネットワーク要素は、動作環境情報がネットワーク要素自体内に存在する領域境界を横切らないように適切に構成されるべきである。
【００８１】
領域境界を検出したとき、決定は、一般に、領域間で領域間ルーティングプロトコルを実行することである。
【００８２】
本発明の一実施形態の決定アルゴリズム（ローカルおよび共同）について、ここでより詳細に説明する。
【００８３】
領域内の１つ以上のネットワーク要素、場合によっては全部のネットワーク要素は、その領域に関して実行する１つのルーティングプロトコルを最終的に選択することになる（ルーティングプロトコルを使用しないという選択肢も含む）決定アルゴリズムを実行する責任を有し、動作環境情報の配信の一部として特定されたルーティングプロトコルの中だけから選択してもよい。ルーティングプロトコルの選択は、上に挙げた動作環境情報を考慮してもよいが、それに限定されない。
【００８４】
選択プロセス例には、ＧＳＭ、ＷＣＤＭＡ、ＢｌｕｅｔｏｏｔｈおよびＷＬＡＮのインタフェースならびにサポートしているルーティングプロトコル有するセルラ電話機を含むことができよう。
【００８５】
図３は、可能なデバイス２を示す。この場合のプロトコルの選択は、現在使用されているインタフェースに基づくことができよう。Ｂｌｕｅｔｏｏｔｈインタフェースが使用される場合はＢｌｕｅｌｉｎｅプロトコル、また他のインタフェースのいずれかが使用される場合はＴＯＲＡプロトコルである。
【００８６】
この責任を有する各ネットワーク要素は、ネットワーク要素自体の決定アルゴリズムを用いて自要素の（ローカル）決定をまず行う。これは、図４ＡのステップＳ２に表されている（「プロトコル選択」状態）。１つを超えるネットワーク要素が決定アルゴリズムを実行する場合、それらの要素はまた、自要素のローカル決定を互いに通知し、他のリモート決定を受信するために待たなければならない。これは、図４ＡのステップＳ３に表されている（「リモート決定持ち」状態）。
【００８７】
自要素のローカル決定アルゴリズムを実行する異なるネットワーク要素が、利用可能なルーティングプロトコル選択肢のセットの中から異なる決定に達した場合、それらの要素は、同一の共同決定に集合的に合意する必要がある。これは、図４ＢのステップＳ４に表されている（「決定戦略」状態）。これは、種々の異なる手法で達成されてもよく、いくつかの例について以下に説明する。ローカル決定アルゴリズムの実行能力があり共同決定に参加するノードは、共同決定を計算する同じロジックを使用するので、共同決定手順が事前設定されるべきである、および／またはデフォルト手順が続く。
【００８８】
過半数決定：この場合、決定は、決定アルゴリズムを実行するネットワーク要素の過半数が行ったローカル決定に基づく。この例では、過半数は、それらの５０％を超えるネットワーク要素が同じ決定を行ったことを意味し、次いでこれは、領域全体に責任を負う決定としても合意される。これは、図４ＢのステップＳ６に表されている（「最高票のプロトコルの選択」状態）。
【００８９】
加重決定：この場合、領域全体に責任を負う決定は、最大の「重さ」を有する決定アルゴリズムを実行するネットワーク要素が選択したルーティングアルゴリズムを選択することである。いくつかのネットワーク要素が同じ重さを有し、それが最大でもあるが、これらのそれぞれの決定が同一でない場合、（最大の重さを有する）それらの要素の間で、さらに前述の代替手法の過半数決定を行うことができよう。これは、図４ＢのステップＳ７に表されている（「加重票によるプロトコルの選択」）。
【００９０】
これらは、共同決定にどのように到達するかの単なる例にすぎないことは理解されるであろう。例えば、最も多いローカル決定もまた共同決定として選択でき、当業者には他の形態の決定ロジックも直ちに明白であろう。
【００９１】
１つの一貫して筋の通った決定が可能でない場合：共同決定が領域全体に責任を負う同一決定に帰着しないであろう場合、領域を分割するなどの代替案を考慮する必要がある。これは、図４ＢのステップＳ５に表されている（「適切なプロトコルが設定されない」状態）。一代替案は、デフォルトルーティングプロトコルに戻ることであろう。
【００９２】
ルーティングプロトコルの選択決定の広報：決定アルゴリズムを実行する１つ以上のネットワーク要素がいったんルーティングプロトコルを選択すると、これらのネットワーク要素の少なくとも１つは、選択したルーティングプロトコルの情報を領域内の他のすべてのネットワーク要素に広報する。
【００９３】
領域の動的側面：領域は決して静的ではなく、本発明の一実施形態は、ネットワーク要素がどの時点でも領域内に入り出て行ってもよい可能性（おそらくは断続的な接続のため）をサポートする。この場合、動作環境情報を広報後、決定アルゴリズムが実行され、現在のルーティングプロトコルが新しいネットワーク要素によって使用されうるかどうかをチェックすることになる。事実上これは、これらの動的特性のために、決定アルゴリズムが連続的に実行されてもよく、そして以前行った決定を再評価し、変更もしてもよいことを意味する。以前の決定が再評価される頻度は、可能性のあるポリシーとシステムの不安定および望ましくない変動の回避との両方に制約される。
【００９４】
通常、すべての決定実施ネットワーク要素は、すべての情報を受信していると想定されているであろう。そのような要素の情報受信を一時的に妨げる、ある種のネットワーク不安定が生じた際に何が起こるかについては、本開示の範囲外である。しかし、要するに、そのような状況では複数回の（再）送信を、たぶん送信ネットワーク要素への確認応答の返信とともに行うことができよう。それでもやはり決定に不一致がある場合（これは、非常に動的なネットワーク環境でさえ非常に起こりそうにない）、ネットワークが安定しておらず、分裂／分割を行うべきと宣言してもよい。従って、あるネットワーク要素がひょっとして異なる共同決定の情報を受信する場合、エラー状態を提起できよう。
【００９５】
他の側面：ネットワーク要素がルーティングを行わないことを選ぶ事例があろう。典型的な例は、専用ルータを有するネットワークに属するホストであろう。この場合、ネットワーク要素は、データをしかるべくルーティングする責任があるだろうルータに、すべてのパケットを転送するであろう。ルータの役を務めるネットワーク要素は、この役割を担っていることを領域内の近隣の要素に通知するであろう。
【００９６】
別の事例は、決定の実施に係わるネットワーク要素が特定のルーティングプロトコルを使用すべきとの決定に達するが、現時点でそのプロトコルが必要なすべてのネットワーク要素にはサポートされていない場合である。それらのネットワーク要素をルーティングループから除外する代わりに、決定されたルーティングプロトコルをインストールされているネットワーク要素が、選択されたルーティングプロトコルを持たない他のネットワーク要素のそれぞれに、このプロトコルをインストールするように取り計らう。
【００９７】
概観すると、本発明の一実施形態による方法は図９に要約される。方法は、領域境界検出ステップＭ１と、動作環境情報配信ステップＭ２と、ローカル決定実施ステップＭ３と、ローカル決定配信ステップＭ４と、共同決定実施ステップＭ５と、共同決定配信ステップＭ６とを備える。
【００９８】
本発明の一実施形態によるノードＮが、図１０に概略的に示されており、図９に示されるステップを実行するそれぞれの部分を備える。具体的には、ノードＮは、領域境界検出ステップＭ１を実行する領域境界検出部Ｐ１と、動作環境情報配信ステップＭ２を実行する動作環境情報配信部Ｐ２と、ローカル決定実施ステップＭ３を実行するローカル決定実施部Ｐ３と、ローカル決定配信ステップＭ４を実行するローカル決定配信部Ｐ４と、共同決定実施ステップＭ５を実行する共同決定実施部Ｐ５と、共同決定配信ステップＭ６を実行する共同決定配信部Ｐ６とを備える。配信の一般的ステップがその中に要求、送信および受信のステップを含んでもよいことは理解されるであろう。
【００９９】
図１０および図１１に示される部分の構成および動作は、これまでの説明および以下の説明から明らかになるであろう。
【０１００】
パーソナルエリアネットワークの状況における本発明の一実施形態について、ここで図５および図６を参照して説明する。
【０１０１】
図５は、上記の提案の方法（ＸＤＮＭ）を用いる起動している３つのデバイスを示す。これらのデバイスは、ラップトップ６と２つの携帯電話機２および４（ここでは、「灰色」２および「黒色」４と識別される）を備える。全デバイスは、利用可能なインタフェースの１つを通じて動作環境情報を交換するが、この例ではラップトップだけが決定アルゴリズム（ＤＡ）を実行するように指定されている。
【０１０２】
受信情報を使用して、ラップトップ６は、Ｂｌｕｅｔｏｏｔｈ−ＡＮプロトコルの使用を決定する。その理由は、全デバイスがそのルーティングプロトコルをサポートしていることに加えて、ルーティングに参加しているより小さなデバイスの電池電力を節約するアルゴリズムの要因からである。
【０１０３】
動作手順およびそれらの動作がなぜおよびどのように行われたかの説明については、図６Ａ〜６Ｃに示され、以下により詳細に記述する。図６Ａ〜６Ｃに描かれた動作は要約されているが、ＸＤＮＭ実行の一部として行われる最も関連深い動作を備えていることは理解されるであろう。
【０１０４】
ステップＴ１およびＴ２では、ラップトップ６が灰色携帯電話機２および黒色携帯電話機４のそれぞれに、どのルーティングプロトコルをサポートしているかに特に関する動作環境情報を要求する。この情報は、灰色携帯電話機２および黒色携帯電話機４からそれぞれステップＴ３およびＴ４で提供される。両方とも、リスト｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ｝を戻す。
【０１０５】
ステップＴ５では、ラップトップ６は、使用すべきルーティングプロトコルを決定しようとする。ラップトップ６自体がリスト｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ、ＯＳＰＦ｝のプロトコルをサポートするので、全デバイスに共通の１つを超えるプロトコル｛Ｂｌｕｅｔｏｏｔｈ−ＡＮ、ＴＯＲＡＮ｝がある。
【０１０６】
このため、ラップトップ６は、灰色携帯電話機２および黒色携帯電話機４にそれぞれステップＴ６およびＴ７で、サポートしているルーティングプロトコルに関連する電力消費に特に関する追加の動作環境情報を要求する。この情報は、灰色携帯電話機２および黒色携帯電話機４からそれぞれステップＴ８およびＴ９で提供される。
【０１０７】
ステップＴ１０では、ラップトップ６は、灰色携帯電話機２および黒色携帯電話機４から受信した追加の動作環境情報を使用して、使用すべき最善のプロトコルはＢｌｕｅｔｏｏｔｈ−ＡＮと決定する。この決定は、灰色携帯電話機２および黒色携帯電話機４にそれぞれステップＴ１１およびＴ１２で広報される。
【０１０８】
先の図９の概要の方法図に関しては、上記のように、ノードが同じ領域に関することが分かっているので、図９の領域境界検出ステップＭ１は明示的に必要ない。
【０１０９】
図９の動作環境情報配信ステップＭ２は、ステップＴ１〜Ｔ４およびＴ６〜Ｔ９に相当する（配信は２段階で実行される）。ラップトップ６も、自装置の動作環境情報を携帯電話機２および４と共有する（とはいえ、この共有の実行に必要なステップは明示的に示されていない）。
【０１１０】
図９のローカル決定実施ステップＭ３は、ステップＴ５およびＴ１０に相当する（決定は２段階で実行される）。
【０１１１】
ラップトップ６は唯一の指定された決定実施ノードなので、ローカル決定配信ステップＭ４も共同決定実施ステップＭ５も必要ない（ローカル決定は共同決定と同等である）。
【０１１２】
共同決定配信ステップＭ６はステップＴ１１〜Ｔ１４に相当する。
【０１１３】
ホームエリアネットワークの状況における本発明の一実施形態について、ここで図７および８を参照して説明する。
【０１１４】
図７は、５つの異なるデバイス（ブロードバンドルータ１４、ＷＬＡＮアクセスポイント２２、ラップトップ１８、デスクトップ１６およびＰＤＡ２０）を有するホームエリアネットワークと、領域境界の向こう側のアクセスネットワークに在る別のデバイス（アクセスルータ１２）とを示す。図７の全デバイスが提案の方法（ＸＤＮＭ）を実行する一方で、ホームエリアネットワークの３つのデバイスが決定アルゴリズム（ＤＡ）の実行も行うように指定され、図７に印が付けられている。
【０１１５】
以下に示す表は、図７のデバイスのそれぞれがサポートしているインタフェースおよびサポートしているルーティングプロトコルの概要である。図７は、使用しているインタフェースのある特定の設定を描写する、すなわち、ここに挙げているサポートしているインタフェースのすべてをこの特定の設定で使用しているわけではないことに注意すべきである。ＤＡを実行するデバイスは等しい重さを有し、この例では過半数共同決定アルゴリズムを使用しているとも想定している。
【０１１６】
【表１】
【０１１７】
種々の要素によって実行される方法のいくつかのステップが図８Ａおよび８Ｂに示されており、これらについて以下に説明する。いくつかの最初のステップは、図８Ａおよび８Ｂには示されていないが、それらについてまず説明する。
【０１１８】
例えばネットワークまたはノード／デバイスのアイデンティティを識別する情報を送信することによって、ＸＤＮＭによって領域境界が確認される（図９のステップＭ１に相当）。この場合、これは、ＸＤＮＭによりアクセスルータ１２とブロードバンドルータ１４との間で送信されるこれ以上の情報を発生せず、この特定の場合には、リンクをまたがって使用されるルーティングプロトコルももたらさない。
【０１１９】
ホームエリアネットワークに関しては、サポートしている（および使用している）インタフェースについての情報および各デバイスがどのルーティングプロトコルをサポートしているかの情報が広報される（図９のステップＭ２に相当）。ブロードバンドルータ１４およびデスクトップ１６におけるＤＡの実行（図９のステップＭ３に相当）は、これらのノードの両方ともＴＯＲＡＮプロトコルを使用するというローカル決定になるのに対して、ラップトップ１８のＤＡの実行は、（ラップトップ１８がホームエリアネットワーク内の他の全デバイスにＢｌｕｅｔｏｏｔｈ−ＡＮプロトコルの無料のダウンロードを提供して）Ｂｌｕｅｔｏｏｔｈ−ＡＮプロトコルを使用するというローカル決定になる。
【０１２０】
ステップＱ１では、各々の指定された決定実施ノードで行われたローカル決定は、他の指定された決定実施ノードに互いに広報される（図９のステップＭ４に相当）。
【０１２１】
次いで、各指定された決定実施ノードにおいて、（当該ノードのローカル決定および他の指定された決定実施ノードから受信したローカル決定を備える）ローカル決定のセットに基づき、共同決定が行われる。これは、図９のステップＭ５に相当する。この場合、過半数決定が行われ、ＴＯＲＡＮプロトコルがルーティングプロトコルとして選択される。
【０１２２】
ラップトップ１８は、共同決定実施アルゴリズムの実行からもたらされたプロトコルとは異なるプロトコルに決定していたので、ステップＱ２で、他の指定された決定実施ノードの特定の１つ（この例では、デスクトップ１６）に、そのノードが行った過半数決定を受け入れると通知する。ステップＱ５で、ブロードバンドルータ１４も、その決定の受け入れをデスクトップに通知する。
【０１２３】
ＰＤＡ２０は、ＤＡを実行しないので、決定実施ノードが到達したルーティングプロトコルの決定をまだ知らない。ステップＱ３で、共同決定の通知を待っていたＰＤＡ２０に、共同決定が通知される（図９のステップＭ６に相当）。この例では、ＰＤＡ２０は、電力制約と電池電力の節約のために共同決定を拒否し、どのルーティングプロトコルも使用せずに、ホストの役を務めると決定し、この決定を、ステップＱ４で別のノードに通知する。
【０１２４】
要約すると、本発明の一実施形態は、本明細書ではＸＤＮＭとして知られる方法を規定し、この方法は、自己設定しうる（ＩＰネットワークなどの）ネットワークをサポートするために使用されてもよい。ネットワーク要素間でローカル動作環境情報を広報することによって、ネットワーク内のネットワーク要素は、例えば様々なプロトコル選択肢、アドレス等を有するネットワーク要素をどのように適切に設定するかについて、自要素のものだが集合的に合意した決定を行いうる。本発明の一実施形態は、例えばネットワーク要素がネットワークに加わったり出て行ったりしてもよく、それにより以前の決定の継続的な再評価に導き、その結果ネットワーク内のネットワーク要素の再設定にさらに導きうる、動的ネットワーク環境もサポートする。
【０１２５】
全体として、自己設定ネットワーク要素および自己設定ネットワークは、ネットワーク管理のコストを大幅に改善し、本発明の一実施形態は、所有の総コストの引き下げに向けた重要なステップを提供しうる。
【０１２６】
１つ以上の上記のコンポーネントの動作がデバイスまたは装置上で動作するプログラムによって制御されてもよいことは理解されるであろう。このような動作プログラムは、コンピュータで読み取り可能な記憶媒体に格納されてもよく、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号などの信号の中に具体化できよう。添付の特許請求の範囲は、それ自体で、または運搬媒体上の記録として、または信号として、または他の任意の形態で、動作プログラムを包含していると解釈される。
【０１２７】
添付の特許請求の範囲に規定される本発明の範囲から逸脱することなしに、上記の実施形態に種々の変更を行いうることも、当業者に理解されるであろう。
【特許請求の範囲】
【請求項１】
ネットワークにおける共通設定パラメータを決定するための分散方法であって、前記ネットワークは前記方法を実行するように指定された少なくとも１つのノードを備え、指定されたノードにおいて、
自ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する工程と、
自身のローカル決定があれば、該ローカル決定を他の指定されたノードに送信する工程と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する工程と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する工程とを有する分散方法。
【請求項２】
前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードのローカル動作環境に関する情報を受信する工程と、前記受信情報を使用して前記ローカル決定を実施する工程とを有する請求項１に記載の分散方法。
【請求項３】
前記共同決定を非指定ノードに送信する工程を有する請求項１または２に記載の分散方法。
【請求項４】
前記決定アルゴリズムは、前記少なくとも１つの指定されたノードが行った最も多いローカル決定を採用する工程を有する請求項１乃至３のいずれか１項に記載の分散方法。
【請求項５】
前記共同決定を実施する工程は、自ノードのローカル決定および前記少なくとも１つの指定されたノードから受信したローカル決定の中から過半数の決定を採用する工程を有する請求項１乃至４のいずれか１項に記載の分散方法。
【請求項６】
ノードの動作環境情報がそのノードの重さを備え、前記共同決定を実施する工程は、最大の重さを有する前記少なくとも１つの指定されたノードが行った決定を採用する工程を有する請求項１乃至４のいずれか１項に記載の分散方法。
【請求項７】
前記設定パラメータは、前記ネットワークで使用するルーティングプロトコルと、ネットワークインタフェースアドレスと、接続確立用のシグナリングプロトコルと、モビリティ管理用のプロトコルと、コーデックと、リンク層スケジューリングアルゴリズムと、送信電力の少なくとも１つを備える請求項１乃至６のいずれか１項に記載の分散方法。
【請求項８】
前記ローカル動作環境情報は、前記ノードがサポートしているプロトコルと、例えば処理能力および利用可能メモリなどの前記ノードのハードウェア仕様と、例えばアドレス指定情報などのネットワークノード間のリンクおよび／またはインタフェースと、前記ノードの１つ以上のアイデンティティと、前記ネットワーク内のノード数と、例えばサポートしている能力、メディアおよび符号化のサポート、実施ポリシーなどの前記ノードの状態情報と、デフォルトルーティングパラメータと、追加でネゴシエートする情報の少なくとも１つを備える請求項１乃至７のいずれか１項に記載の分散方法。
【請求項９】
前記ローカル動作環境情報を少なくとも１つの他の指定されたノードへ、当該他のノードにおける前記方法の実行で使用するために送信する工程を有する請求項１乃至８のいずれか１項に記載の分散方法。
【請求項１０】
前記少なくとも１つの他のノードへの前記情報の送信が、前記情報に領域境界を越えさせるかどうかを判定する工程と、越えさせないと判定した場合だけ前記情報を送信する工程とを有する請求項９に記載の分散方法。
【請求項１１】
前記ローカル動作環境情報に影響を与える変化の発生に応えて、前記ローカル動作環境情報を送信する工程を有する請求項９または１０に記載の分散方法。
【請求項１２】
前記ローカル動作環境情報を同じ領域内の別のノードだけに送信する工程を有する請求項９、１０及び１１のいずれか１項に記載の分散方法。
【請求項１３】
前記ネットワークはＩＰネットワークを備える請求項１乃至１２のいずれか１項に記載の分散方法。
【請求項１４】
各指定されたノードにおける前記工程の実行を有する請求項１乃至１３のいずれか１項に記載の分散方法。
【請求項１５】
例えば前記共通設定パラメータに基づいた接続の確立により、前記共通設定パラメータを適用する工程を有する請求項１乃至１４のいずれか１項に記載の分散方法。
【請求項１６】
ネットワークの共通設定パラメータを決定する分散方法の少なくとも一部を実行するように指定された、前記ネットワーク内のノードとしてまたはそのノード内で使用する装置であって、
前記ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する手段と、
自身のローカル決定があれば、該ローカル決定を他の指定されたノードに送信する手段と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する手段と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する手段とを備える装置。
【請求項１７】
前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードの前記ローカル動作環境に関する情報を受信する手段を備え、前記ローカル決定を実施する手段は前記受信情報に基づき前記ローカル決定を実施するように構成される請求項１６に記載の装置。
【請求項１８】
前記共同決定を非指定ノードに送信する手段を備える請求項１６または１７に記載の装置。
【請求項１９】
前記共同決定を実施する手段は、前記少なくとも１つの指定されたノードが行った最も多いローカル決定を採用するように構成される請求項１６乃至１８のいずれか1項に記載の装置。
【請求項２０】
前記共同決定を実施する手段は、自ノードのローカル決定および前記少なくとも１つの指定されたノードから受信したローカル決定の中から過半数の決定を採用するように構成される請求項１６乃至１９のいずれか１項に記載の装置。
【請求項２１】
ノードの前記動作環境情報はそのノードの重さを備え、前記共同決定を実施する手段は最大の重さを有する前記少なくとも１つの指定されたノードが行った決定を採用するように構成される請求項１６乃至２０のいずれか１項に記載の装置。
【請求項２２】
前記ローカル動作環境情報を少なくとも１つの他の指定されたノードへ、当該他のノードにおける前記方法の実行で使用するために送信する手段を備える請求項１６乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記少なくとも１つの他のノードへの前記情報の送信が前記情報に領域境界を越えさせるかどうかを判定する手段と、越えさせないと判定した場合だけ前記情報を送信する手段とを備える請求項１６乃至２２のいずれか１項に記載の装置。
【請求項２４】
例えば前記共通設定パラメータに基づいた接続の確立により、前記共通設定パラメータを適用する手段を備える請求項１６乃至２３のいずれか１項に記載の装置。
【請求項２５】
ネットワークの共通設定パラメータを決定する分散型システムであって、前記ネットワークの少なくとも１つの指定されたノードのそれぞれが、
自ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する手段と、
自身のローカル決定をもしあれば他の指定されたノードに送信する手段と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する手段と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する手段と
を備える分散型システム。
【請求項２６】
各指定されたノードにおいて、前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段と、前記受信情報を使用して前記ローカル決定を実施する手段とを備える請求項２５に記載の分散型システム。
【請求項２７】
各指定されたノードにおいて、前記共同決定を非指定ノードに送信する手段を備える請求項２５または２６に記載の分散型システム。
【請求項２８】
請求項１乃至１５のいずれか１項に記載の方法を実行するように装置を制御するプログラム。
【請求項１】
ネットワークにおける共通設定パラメータを決定するための分散方法であって、前記ネットワークは前記方法を実行するように指定された少なくとも１つのノードを備え、指定されたノードにおいて、
自ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する工程と、
自身のローカル決定があれば、該ローカル決定を他の指定されたノードに送信する工程と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する工程と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する工程とを有する分散方法。
【請求項２】
前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードのローカル動作環境に関する情報を受信する工程と、前記受信情報を使用して前記ローカル決定を実施する工程とを有する請求項１に記載の分散方法。
【請求項３】
前記共同決定を非指定ノードに送信する工程を有する請求項１または２に記載の分散方法。
【請求項４】
前記決定アルゴリズムは、前記少なくとも１つの指定されたノードが行った最も多いローカル決定を採用する工程を有する請求項１乃至３のいずれか１項に記載の分散方法。
【請求項５】
前記共同決定を実施する工程は、自ノードのローカル決定および前記少なくとも１つの指定されたノードから受信したローカル決定の中から過半数の決定を採用する工程を有する請求項１乃至４のいずれか１項に記載の分散方法。
【請求項６】
ノードの動作環境情報がそのノードの重さを備え、前記共同決定を実施する工程は、最大の重さを有する前記少なくとも１つの指定されたノードが行った決定を採用する工程を有する請求項１乃至４のいずれか１項に記載の分散方法。
【請求項７】
前記設定パラメータは、前記ネットワークで使用するルーティングプロトコルと、ネットワークインタフェースアドレスと、接続確立用のシグナリングプロトコルと、モビリティ管理用のプロトコルと、コーデックと、リンク層スケジューリングアルゴリズムと、送信電力の少なくとも１つを備える請求項１乃至６のいずれか１項に記載の分散方法。
【請求項８】
前記ローカル動作環境情報は、前記ノードがサポートしているプロトコルと、例えば処理能力および利用可能メモリなどの前記ノードのハードウェア仕様と、例えばアドレス指定情報などのネットワークノード間のリンクおよび／またはインタフェースと、前記ノードの１つ以上のアイデンティティと、前記ネットワーク内のノード数と、例えばサポートしている能力、メディアおよび符号化のサポート、実施ポリシーなどの前記ノードの状態情報と、デフォルトルーティングパラメータと、追加でネゴシエートする情報の少なくとも１つを備える請求項１乃至７のいずれか１項に記載の分散方法。
【請求項９】
前記ローカル動作環境情報を少なくとも１つの他の指定されたノードへ、当該他のノードにおける前記方法の実行で使用するために送信する工程を有する請求項１乃至８のいずれか１項に記載の分散方法。
【請求項１０】
前記少なくとも１つの他のノードへの前記情報の送信が、前記情報に領域境界を越えさせるかどうかを判定する工程と、越えさせないと判定した場合だけ前記情報を送信する工程とを有する請求項９に記載の分散方法。
【請求項１１】
前記ローカル動作環境情報に影響を与える変化の発生に応えて、前記ローカル動作環境情報を送信する工程を有する請求項９または１０に記載の分散方法。
【請求項１２】
前記ローカル動作環境情報を同じ領域内の別のノードだけに送信する工程を有する請求項９、１０及び１１のいずれか１項に記載の分散方法。
【請求項１３】
前記ネットワークはＩＰネットワークを備える請求項１乃至１２のいずれか１項に記載の分散方法。
【請求項１４】
各指定されたノードにおける前記工程の実行を有する請求項１乃至１３のいずれか１項に記載の分散方法。
【請求項１５】
例えば前記共通設定パラメータに基づいた接続の確立により、前記共通設定パラメータを適用する工程を有する請求項１乃至１４のいずれか１項に記載の分散方法。
【請求項１６】
ネットワークの共通設定パラメータを決定する分散方法の少なくとも一部を実行するように指定された、前記ネットワーク内のノードとしてまたはそのノード内で使用する装置であって、
前記ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する手段と、
自身のローカル決定があれば、該ローカル決定を他の指定されたノードに送信する手段と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する手段と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する手段とを備える装置。
【請求項１７】
前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードの前記ローカル動作環境に関する情報を受信する手段を備え、前記ローカル決定を実施する手段は前記受信情報に基づき前記ローカル決定を実施するように構成される請求項１６に記載の装置。
【請求項１８】
前記共同決定を非指定ノードに送信する手段を備える請求項１６または１７に記載の装置。
【請求項１９】
前記共同決定を実施する手段は、前記少なくとも１つの指定されたノードが行った最も多いローカル決定を採用するように構成される請求項１６乃至１８のいずれか1項に記載の装置。
【請求項２０】
前記共同決定を実施する手段は、自ノードのローカル決定および前記少なくとも１つの指定されたノードから受信したローカル決定の中から過半数の決定を採用するように構成される請求項１６乃至１９のいずれか１項に記載の装置。
【請求項２１】
ノードの前記動作環境情報はそのノードの重さを備え、前記共同決定を実施する手段は最大の重さを有する前記少なくとも１つの指定されたノードが行った決定を採用するように構成される請求項１６乃至２０のいずれか１項に記載の装置。
【請求項２２】
前記ローカル動作環境情報を少なくとも１つの他の指定されたノードへ、当該他のノードにおける前記方法の実行で使用するために送信する手段を備える請求項１６乃至２１のいずれか１項に記載の装置。
【請求項２３】
前記少なくとも１つの他のノードへの前記情報の送信が前記情報に領域境界を越えさせるかどうかを判定する手段と、越えさせないと判定した場合だけ前記情報を送信する手段とを備える請求項１６乃至２２のいずれか１項に記載の装置。
【請求項２４】
例えば前記共通設定パラメータに基づいた接続の確立により、前記共通設定パラメータを適用する手段を備える請求項１６乃至２３のいずれか１項に記載の装置。
【請求項２５】
ネットワークの共通設定パラメータを決定する分散型システムであって、前記ネットワークの少なくとも１つの指定されたノードのそれぞれが、
自ノードのローカル動作環境に関する情報に基づき、前記設定パラメータに係わるローカル決定を実施する手段と、
自身のローカル決定をもしあれば他の指定されたノードに送信する手段と、
もしあれば他の指定されたノードが行った対応するローカル決定を受信する手段と、
その受信に続いて、自身のローカル決定および前記受信したローカル決定に基づき、前記指定されたノードに共通の決定アルゴリズムを用いて、前記設定パラメータに係わる共同決定を実施する手段と
を備える分散型システム。
【請求項２６】
各指定されたノードにおいて、前記ネットワークの少なくとも１つの他のノードから、前記少なくとも１つの他のノードのローカル動作環境に関する情報を受信する手段と、前記受信情報を使用して前記ローカル決定を実施する手段とを備える請求項２５に記載の分散型システム。
【請求項２７】
各指定されたノードにおいて、前記共同決定を非指定ノードに送信する手段を備える請求項２５または２６に記載の分散型システム。
【請求項２８】
請求項１乃至１５のいずれか１項に記載の方法を実行するように装置を制御するプログラム。
【図１】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【公表番号】特表２０１１−５０３９２２（Ｐ２０１１−５０３９２２Ａ）
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願番号】特願２０１０−５２６１６９（Ｐ２０１０−５２６１６９）
【出願日】平成１９年９月２８日（２００７．９．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６０３３０
【国際公開番号】ＷＯ２００９／０３９８９２
【国際公開日】平成２１年４月２日（２００９．４．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願日】平成１９年９月２８日（２００７．９．２８）
【国際出願番号】ＰＣＴ／ＥＰ２００７／０６０３３０
【国際公開番号】ＷＯ２００９／０３９８９２
【国際公開日】平成２１年４月２日（２００９．４．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]