JP3755881B2 - 移動アドホックネットワークおよび重み係数を乗じたサービス品質メトリックに基づいて機能を実行するための方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、通信ネットワークの技術分野に関し、特に、移動アドホック無線ネットワーク（ｍｏｂｉｌｅ ａｄ−ｈｏｃ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ）およびこれに関連した方法に関する。
【０００２】
【従来の技術】
無線ネットワークの開発は、ここ１０年間で、増加した。最も急速に発達している分野のうちの１つが、移動アドホックネットワークである。物理的に、移動アドホックネットワークは、地理学的に分布し、共通無線周波数を持つたくさんの移動可能なノードを含む。セルラーネットワーク（ｃｅｌｌｕｌａｒ ｎｅｔｗｏｒｋ）または衛星ネットワークのような他のタイプのネットワークと比較すると、移動アドホックネットワークも最も大きな特徴は、固定したインフラストラクチャーがないことである。ネットワークは、移動ノードだけから形成され、ノードがお互いと通信を行うときに、大急ぎで形成される。ネットワークは、特定のノードに依存せず、いくつかのノードがネットワークに参加しまたは他のノードがネットワークから離脱したときに、動的に調整される。
【０００３】
固定された通信インフラストラクチャーが信頼できず、または、利用できないような戦場や地震やハリケーンの起こった自然災害エリアのような悪い環境において、アドホックネットワークをすばやく配置することが可能であり、限られているがたくさんの必要とされる通信が与えられる。軍隊が、これらのネットワークの配置の背後でまだ主な活動をしている間に、アドホックネットワークの適用は、市民エリアまたは商業エリアにおいてすばやく新たに見つかる。アドホックネットワークによって、人々が、単にかれらのコンピュータまたはパーソナルディジタルアシスタント（ＰＤＡ）の電源をオンにするだけでいかなるネットワークを用いることなく、野外またはクラスルームに居てデータを交換することが可能である。
【０００４】
無線通信は日常生活に次第に行き渡っているので、移動アドホックネットワークの新たな適用が現れ続け、通信構造の重要な部分になるであろう。移動アドホックネットワークは、設計者におおきな難題を与える。固定されたインフラストラクチャーが欠如しているため、ノードが移動し、ネットワークに参加し、または、ネットワークから去るにしたがって、複数のノードが自身で組織され、再構成されなければならない。すべてのノードは本質的に同じであり、普通の階層構造やネットワークの中央制御部が存在しない。すべての機能がノードの間に分配されなければならない。ノードはしばしばバッテリーによって電力を供給され、限られた通信能力と計算能力を持つ。このシステムの帯域幅は、たいていの場合、制限される。２つのノードの間の距離は、無線送信範囲を超え、送信の目的地に達する前に、送信が他のノードによって中継される。結果として、ネットワークは、他段階構成・マルチホップのトポロジー・接続形態（ｍｕｌｔｉｈｏｐ ｔｏｐｏｌｏｇｙ）を持ち、このトポロジーは、ノードが動き回るにつれて、変化する。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）の移動アドホックネットワーク（Ｍｏｂｉｌｅ Ａｄ−ｈｏｃ Ｎｅｔｗｏｒｋｓ（ＭＡＮＥＴ））は、ルーティングプロトコルやマルチキャスティングプロトコルを積極的に評価し、標準化してきた。ノードが移動するにつれて、ネットワークトポロジーが任意に変化するので、情報が古く・不要に（ｏｂｓｏｌｅｔｅ）なってしまい、別のノードが、しばしば、時間（情報はあるノードでは古くなってしまい、他のノードでは現在の情報となる場合がある）と空間（ノードは、隣接範囲内と自分自身からあまり遠くない範囲においてネットワークトポロジーを単に知っている場合がある）の両方において、ネットワークの異なる視点を持つ。
【０００５】
ルーティングプロトコルは、頻繁に起こるトポロジー変化とあまり正確でない情報に適合される必要がある。これらの独自の要求のため、これらのネットワークにおけるルーティングは、他のネットワークにおけるルーティングと非常に異なる。１つのネットワーク全体に関して新鮮な情報を集めることは、しばしば、費用がかかり、実用的でない。多くのルーティングプロトコルは、リアクティブの（オンデマンドの）プロトコルである。リアクティブプロトコル（ｒｅａｃｔｉｖｅ ｐｒｏｔｏｃｏｌ）は、必要なときに、ルーティング情報を集め、目的地に対してルーティングを行い、使用されないルートを維持しない。すべての時に、すべての目的地への最適なルートを維持するプロアクティブプロトコル（ｐｒｏ−ａｃｔｉｖｅ ｐｒｏｔｏｃｏｌ）と比べて、この方法によって、ルーティングオーバーヘッド（ｒｏｕｔｉｎｇ ｏｖｅｒｈｅａｄ）が、大いに減少させられる。このことは、プロトコルが適合性を持つためには、重要である。ＡＯＤＶ（Ａｄ Ｈｏｃ ｏｎ Ｄｅｍａｎｄ Ｄｉｓｔａｎｃｅ Ｖｅｃｔｏｒ）とＴＯＲＡ（Ｔｅｍｐｏｒａｌｌｙ Ｏｒｄｅｒｅｄ Ｒｏｕｔｉｎｇ Ａｌｇｏｒｉｔｈｍ）は、上述のＭＡＮＥＴワーキンググループで与えられたオンデマンドルーティングプロトコルを代表するものである。
【０００６】
他の様々なルーティングプロトコルの例は、Ｐｅｒｋｉｎｓの米国特許第５，４１２，６５４に開示されているＤＳＶＤ（Ｄｅｓｔｉｎａｔｉｏｎ Ｓｅｑｕｅｎｃｅｄ Ｄｉｓｔａｎｃｅ−Ｖｅｃｔｏｒ）ルーティング、やＨａａｓの米国特許第６，３０４，５５６号に開示されているＺＲＰ（Ｚｏｎｅ Ｒｏｕｔｉｎｇ Ｐｒｏｔｏｃｏｌ）を含む。ＺＲＰは、プロアクティブとリアクティブの両方のアプローチを用いるハイブリッドプロトコルである。
【０００７】
これらの従来のルーティングプロトコルは、ソースノード（ｓｏｕｒｃｅ ｎｏｄｅ）から目的地ノードへのルートを選択することにおいて最善努力アプローチ（ｂｅｓｔ ｅｆｆｏｒｔ ａｐｐｒｏａｃｈ）を用いる。一般的には、途中の段階・ホップ（ｈｏｐｓ）の数は、そのような最善努力アプローチにおける主な基準である。言い換えると、ホップ・段階の最小の数を持つルートは、送信ルートとして選択される。
【０００８】
移動アドホックネットワークにおけるサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｕｒｖｉｃｅ（ＱｏＳ））ルーティングは、増加している関心事である。サービス品質を提供するために、プロトコルは、単にルートを見つけるだけではなく、ルートに沿って資源（ｒｅｓｏｕｒｃｅ）を確保することが必要とされる。ネットワークの限られた共有される帯域幅のため、また、これらの限られた資源を考慮し制御する中央制御部がないため、サービス品質ルートのために必要とされる資源を管理するためにノードはお互いに交渉しなければならない。これは、頻繁に起こるトポロジーの変化によってさらに複雑となる。これらの制限のため、サービス品質ルーティングは、最善努力ルーティングよりも要求することが多い。
【０００９】
サービス品質ルーティングアプローチのいくつかの例は、Ｃｈｅｎｘｉ Ｚｈｕによるタイトルが“Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ａｎｄ Ｑｕａｌｉｔｙ−ｏｆ―Ｓｅｒｖｉｃｅ Ｒｏｕｔｉｎｇ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｓ”である２００１年の出版物（ｐｕｂｌｉｃａｔｉｏｎ）と、Ｍ． Ｍｉｒｈａｋｋａｋらによるタイトルが“Ｄｙｎａｍｉｃ Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｓ”（ＭＩＴＲＥ Ｃｏｒｐ．）である２０００年の出版物に説明されている。Ｚｈｕは、小さい率から中くらいの率でのトポロジー変化を有する小さなネットワークにおいて帯域幅が保証されたサービス品質ルートの設立を議論している。Ｍｉｒｈａｋｋａｋらは、ＱｏＳ（サービス品質）の値の範囲を指定する資源蓄えリクエストに関心を向けており、ネットワークがこの範囲内でサービスを提供することが約束される。
【００１０】
各ノードにおいて、承認制御が、他のノードからのトラヒック（ｔｒａｆｆｉｃ）を転送するために、実行される。一般的には、従来の承認制御プロトコルは、ルートおよび接続に関しての十分な開示のためのプロトコルである。言い換えると、各ノードはすべてのルートおよび他のノードとの接続データを他のノードと共有する。これによって、全体的に見て最善努力ルートが選択される。
【００１１】
【特許文献１】
米国特許第５，４１２，６５４
【特許文献２】
米国特許第６，３０４，５５６号
【特許文献３】
米国特許出願第１０／１３４，７１５号
【特許文献４】
米国特許出願第１０／１３４，５５９号
【非特許文献１】
Ｃｈｅｎｘｉ Ｚｈｕによるタイトルが“Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ａｎｄ Ｑｕａｌｉｔｙ−ｏｆ―Ｓｅｒｖｉｃｅ Ｒｏｕｔｉｎｇ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｓ”である２００１年の出版物（ｐｕｂｌｉｃａｔｉｏｎ）
【非特許文献２】
Ｍ． Ｍｉｒｈａｋｋａｋらによるタイトルが“Ｄｙｎａｍｉｃ Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ ｆｏｒ Ｍｏｂｉｌｅ Ａｄ Ｈｏｃ Ｎｅｔｗｏｒｋｓ”（ＭＩＴＲＥ Ｃｏｒｐ．）である２０００年の出版物
【非特許文献３】
Ｄａｓらが開示した１９９７年の“Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ ｕｓｉｎｇ Ｍｉｎｉｍｕｍ Ｃｏｎｎｅｃｔｅｄ Ｄｏｍｉｎａｔｉｎｇ Ｓｅｔｓ”（通信に関するＩＥＥＥ Ｉｎｔ． Ｃｏｎｆ（ＩＣＣ
‘９７）
【非特許文献４】
Ｄａｓらが開示した“Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓｕｓｉｎｇ ａ Ｓｐｉｎｅ”（１９９７年のコンピュータ通信とネットワークに関する ＩＥＥＥ Ｉｎｔ． Ｃｏｎｆ．（ＩＣ３Ｎ ‘９７））
【非特許文献５】
Ｓｉｖａｋｕｍａｒらによる“Ｔｈｅ Ｃｌａｄｅ Ｖｅｒｔｅｂｒａｔａ： Ｓｐｉｎｅｓ ａｎｄ Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ”（１９８８年のコンピュータと通信についてのＩＥＥＥシンポジウム）
【発明が解決しようとする課題】
アドホックネットワークの開発の難題は、多数のノードを包含するためにそのようなネットワークを拡張することである。そうするための先行技術の１つの試みは、スパインネットワークルーティング（ｓｐｉｎｅ ｒｏｕｔｉｎｇ）を用いることである。このスパインルーティングの例は、Ｄａｓらが開示した１９９７年の“Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ ｕｓｉｎｇＭｉｎｉｍｕｍ Ｃｏｎｎｅｃｔｅｄ Ｄｏｍｉｎａｔｉｎｇ Ｓｅｔｓ”（通信に関するＩＥＥＥ Ｉｎｔ． Ｃｏｎｆ（ＩＣＣ ‘９７）に説明されている。このアプローチでは、スパインまたはバーチャルバックボーンが、各ネットワークノードがスパインノードから多くて１つのホップ・段階の位置・距離にあるように定義される。世界的なトポロジー（リンク状態）は、各スパインノードで維持される。リンク状態ルーティングアルゴリズムは、すべての目的地への現在のルートを生成するために各スパインノードで実行される。
【００１２】
別の関連したアプローチは、ＣＳＲ（ｃｌｕｓｔｅｒｅｄ ｓｐｉｎｅ ｒｏｕｔｉｎｇ）である。このＣＳＲは、Ｄａｓらが開示した“Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ ｕｓｉｎｇ ａ Ｓｐｉｎｅ”（１９９７年のコンピュータ通信とネットワークに関する ＩＥＥＥ Ｉｎｔ． Ｃｏｎｆ．（ＩＣ３Ｎ ‘９７））に説明されている。このアプローチは、ノードをクラスターにグループ分けして、二番目の階級レベルをＯＳＲアプローチに加えることによって、スパインルーティングを大きなネットワークへ適用することができるように意図されている。さらに別のアプローチがＰＳＲ（ｐｒｔｉａｌ ｋｎｏｗｌｅｄｇｅ ｓｐｉｎｅ ｒｏｕｔｉｎｇ）として知られている。このＰＳＲは、Ｓｉｖａｋｕｍａｒらによる“Ｔｈｅ Ｃｌａｄｅ Ｖｅｒｔｅｂｒａｔａ： Ｓｐｉｎｅｓ ａｎｄ Ｒｏｕｔｉｎｇ ｉｎ Ａｄ−Ｈｏｃ Ｎｅｔｗｏｒｋｓ”（１９８８年のコンピュータと通信についてのＩＥＥＥシンポジウム）に開示されている。
【００１３】
上述の先行技術のクラスター／スパインアプローチの各々の１つの共通の特性は、これらのアプローチの各々が、プロアクティブルーティングに頼っていることである。プロアクティブルーティングの１つの潜在的な欠点は、プロアクティブルーティングが、すべての時にすべての目的地への最適なルートを維持するためにかなりの量のルーティングオーバーヘッドを必要とすることである。この問題は、非常に多くのノードを含むアドホックネットワークに適用された場合に、特に際立ちやすい。クラスター／スパインアプローチを実施した場合に直面させられる他の問題・難題は、どのようにノードを効率的にクラスターに関係させ、各クラスターに関してクラスターリーダーノードを指定するかということである。
【００１４】
上述の背景技術の観点から、本発明の目的は、ネットワーク内での効率的なクラスターの組織化とルートの効率的な設立するための移動アドホックネットワークとその関連方法を提供することである。
【００１５】
【課題を解決するための手段】
本発明に従ったこの目的と他の目的は、ソースノードと目的地ノードの間に存在する複数の中間ノードを含む移動アドホックネットワークにおいてソースノードと目的地ノードの間の通信のための本発明の方法によって達成可能である。この方法は、複数のＱｏＳパラメータに基づいて目的地ノードへのルートを発見するために、サービス品質（ＱｏＳ）ルートリクエストを複数の中間ノードを介してソースノードからへ目的地ノードへ送信する段階を含む。このＱｏＳルートリクエストに応答して、ソースノードと目的地ノードの間にある複数の可能性のあるルートが、これらの可能性のあるルートの各々に関するＱｏＳパラメータの各々に対応するＱｏＳメトリックとともに決定されてよい。また、ＱｏＳパラメータは、重要さの順番でランク付けされてよく、ＱｏＳパラメータのランク付けに基づいてＱｏＳメトリックの各々に重み係数が乗じられてよい。そのように重み係数を乗ぜられたＱｏＳメトリックはお互いと比較され、この比較に基づいて、可能性のあるルートのなかから１のルートが選択されてよい。また、メッセージデータが、選択されたルートを介してソースノードから目的地ノードへ送信される。
【００１６】
上述したような方法で、ルートリクエストは、リンクメトリックとノードメトリックと共に、リアクティブルーティングプロトコルのためのＱｏＳ経路に関してルート発見を行うために用いられてよい。現在知っているプロアクティブルートの中からベストルートと蓄え用資源を発見するために、同様のアプローチをプロアクティブルーティングプロトコルを用いて使用されてよい。
【００１７】
従って、本発明は、多数のＱｏＳパラメータに基づいてソースノードと目的地ノードの間の通信のためのルートを選択する融通性があり効率的な方法を提供する。このように、例えば、所定の適用において最も大きな重要性を持つＱｏＳパラメータにより大きな重み係数を乗じることにより、多くの適用と動作環境で性能を向上させることが可能である。
【００１８】
特に、本発明の方法は、さらに、重み係数を乗ぜられたＱｏＳメトリックの総和を可能性のあるルートの各々に関して生成し、適切なルートを選択するために、これらの総和を比較する。ＱｏＳメトリックは、ＱｏＳリンクメトリックまたは／およびＱｏＳノードメトリックを含んでよい。例えば、ＱｏＳリンクメトリックは、利用可能な帯域幅、誤り率、端部から端部までの遅延、端部から端部までの遅延変動、ホップカウント、期待される経路耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含んでよい。また、ＱｏＳノードメトリックは、バッテリー寿命、移動性、通信容量および位置のうちの少なくとも１つを含んでよい。
【００１９】
また、複数の可能性のあるルートを決定する前記段階は、各中間ノードで、当該ノードがＱｏＳルートリクエストの要求ＱｏＳパラメータをサポートできるかどうかを決定する段階を含んでよい、中間ノードが要求されるＱｏＳパラメータをサポートできる場合には、当該中間ノードは、他の中間ノードと目的地ノードのうちの１つのノードにＱｏＳルートリクエストを転送する。このように、トラベル経路を定義・決定（ｄｅｆｉｎｅ）するために、サポート可能ＱｏＳパラメータを含むＱｏＳルートリクエストに関して、ノード資源が一時的にとっておかれてよい。そのように、複数の可能性のあるルートを決定する前記段階は、さらに、目的地ノードにおいて、ＱｏＳルートリクエストを受信したときに、ソースノードに返信を生成し、前記トラベル経路を介してこの返信を送信する段階を含んでよい。
【００２０】
この方法は、メッセージデータを送信する前に、選択されたルートでルート確認を中間ノードへ送信する段階を含んでよい。また、中間ノードの各々と目的地ノードにおいて、当該ノードがＱｏＳルートリクエストの要求ＱｏＳパラメータを継続してサポートできるかどうかが探知されてよく、当該ノードが要求されるＱｏＳパラメータを継続してサポートできないと探知された場合には、当該ノードにおいて、ＱｏＳエラー通知が生成されソースノードへ送信される。そのような場合にバックアップを供給するために、例えば、少なくとも１つの代用ルートがソースノードにおいて選択されてよい。
【００２１】
また、本発明の方法は、ノードを、ソースノードを含むソースクラスターと、目的地ノードを含む目的地クラスターと、ソースクラスターと目的地クラスターの間にある中間ノードを含む中間クラスターとに、グループ分けする段階を含んでよい。さらに、隣接クラスターターゲットノードが、アクセスポイントを供給するために、少なくとも１つの中間クラスターにおいて設立されてよい。可能性のあるルートの各々は、隣接クラスターターゲットノードを含んでよい。
【００２２】
また、ソースノードと少なくとも１つの中間クラスターにおける複数の可能性のあるターゲットノードとの間のターゲットルートを決定し、各ターゲットルートに関して複数のＱｏＳターゲットパラメータの各々に対応するＱｏＳターゲットメトリックを決定し、重要さの順番でＱｏＳターゲットパラメータをランク付けることにより、隣接クラスターターゲットノードが設立されてよい。また、ＱｏＳターゲットパラメータのランク付けに基づいてＱｏＳターゲットメトリックの各々に、重み係数を乗じてよい。重み係数が乗ぜられたＱｏＳターゲットメトリックが、比較されてよく、この比較に基づいて隣接クラスターターゲットノードが選択されてよい。このアプローチによって、隣接クラスターターゲットノードを選択する上でより大きな融通性が得られ、所定の状況においてより重要なＱｏＳパラメータに基づいて重み係数を乗じることによってより大きな効率が得られる。
【００２３】
特に、本発明の方法は、重み係数を乗じたＱｏＳターゲットメトリックの総和を、可能性のあるルートの各々に関して、生成し、隣接クラスターターゲットノードを選択するために、重み係数を乗じたＱｏＳターゲットメトリックのこれらの総和をお互いに比較してよい。また、ＱｏＳターゲットメトリックは、利用可能な帯域幅、誤り率、端部から端部までの遅延、端部から端部までの遅延変動、期待される経路耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含んでよい。
【００２４】
本発明の別の関連した方法は、複数のノードを含む移動アドホックネットワークにおいてノードを組織化するための方法である。この方法は、複数のノードをクラスターにグループ分けする段階、各クラスターにおける各ノードに関してサービス品質（ＱｏＳ）ノードメトリックを決定する段階を含んでよい。ここで、各ＱｏＳノードメトリックは、ＱｏＳノードパラメータに対応してよい。また、ＱｏＳノードパラメータは、重要さの順番でランク付けされてよく、ＱｏＳノードメトリックの各々に、ＱｏＳノードパラメータのランク付けに基づいて、重み係数が乗じられてよい。所定のクラスターにおける各ノードに関する重み係数が乗ぜられたＱｏＳノードメトリックは、お互いに比較され、この比較に基づいて所定のクラスターに関して所定のクラスターリーダーノードが選択される。この方法の態様によって、多数のＱｏＳパラメータを用いてクラスターへグループ分けされる移動アドホックネットワークにおいてクラスターリーダーノードを選択する融通性のある効率的なプロセスが提供される。
【００２５】
同様に、本発明の方法は、移動アドホックネットワークに追加ノードを供給する段階、追加ノードからクラスターの各々における少なくとも１つのノードへのルートを設立する段階、および、各ルートに関してＱｏＳリンクメトリックを決定する段階を含んでよい。各ＱｏＳリンクメトリックは、好ましくは、ＱｏＳリンクパラメータに対応する。また、ＱｏＳリンクパラメータは重要さの順番でランク付けされてよく、ＱｏＳリンクパラメータのランク付けに基づいてＱｏＳリンクメトリックの各々に重み係数が乗ぜられてよく、重み係数が乗ぜられたＱｏＳリンクメトリックが比較されてよい。この比較に基づいて、追加ノードが、複数のクラスターのうちの１のクラスターに結合・連合されてよい（関係づけられてよい）。
【００２６】
ＱｏＳリンクメトリックは、利用可能な帯域幅、誤り率、端部から端部までの遅延、端部から端部までの遅延変動、ホップカウント、期待される経路耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含んでよい。また、この方法は、さらに、重み係数が乗ぜられたＱｏＳリンクメトリックの各ルートに関する総和を生成する段階を有してよい。また、重み係数が乗ぜられた前記ＱｏＳリンクメトリックの比較において、重み係数が乗ぜられたＱｏＳリンクメトリックのこれらの総和が、お互いに対して比較されてよい。
【００２７】
この方法は、重み係数が乗ぜられたＱｏＳノードメトリックの各ノードに関する総和を生成する段階を含んでよい。所定のクラスターの各ノードに関する重み係数が乗ぜられたＱｏＳノードメトリックのこれらの総和が、お互いに対して比較されてよい。例えば、ＱｏＳノードメトリックは、バッテリー寿命、移動性、通信容量よび位置のうちの少なくとも１つを含んでよい。
【００２８】
【発明の実施の形態】
以下において、添付の図面を参照して本発明の好適実施形態がより詳しく説明される。しかしながら、本発明は多くの形式で実施が可能になり、以下で説明される実施形態に限定されるものと解釈してはならない。なお、以下で説明される実施形態が与えられることにより、本願の開示が完全になり、当業者は、本発明の範囲を十分に理解・認識できるであろう。同一・類似の参照符号は、全体にわたって同一・類似の要素に対応する。
【００２９】
当業者によって理解されるように、本発明の１部は、方法、データ処理システム、またはコンピュータプログラム製品として具現化されてよい。従って、本発明のこれらの部分は、全体的にハードウェアの実施形態または全体的にソフトウェアの実施形態の形式をとってよい。さらに、本発明の１部は、コンピュータ読み取り可能記憶媒体上のコンピュータプログラム製品であってよい。このコンピュータ読み取り可能記憶媒体は、この記憶媒体上においてコンピュータ読み取り可能プログラムコードを持っていてよい。スタティック記憶装置、ダイナミック記憶装置、ハードディスク、光学的記憶装置、および、磁気記憶装置を含むどんな適切なコンピュータ読み取り可能記憶媒体を本発明の実施形態のために用いてもよい。
【００３０】
本発明は、以下において、本発明の実施形態に従った方法、システム、コンピュータプログラム製品のフローチャート図等を参照して説明される。図のブロックや図のブロックの組み合わせは、コンピュータプログラムインストラクションによって実施することが可能であることが理解されるであろう。コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行されるインストラクションが１またはそれ以上の図示されたブロックの機能を実施するように、これらのコンピュータプログラムインストラクションは、一般用のコンピュータ、専用のコンピュータ、または、プログラム可能データ処理装置のプロセッサに供給される。
【００３１】
コンピュータまたは他のプログラム可能データ処理装置に特定の方法で機能するように命令するこれらのコンピュータプログラムインストラクションは、コンピュータ読み取り可能メモリに記憶されてよい。これによって、このコンピュータ読み取り可能メモリに記憶されたインストラクションが、１以上のフローチャートブロックによって特定された機能を実施するインストラクションを含む製造品となることができる。コンピュータプログラムインストラクションは、コンピュータまたは他のプログラム可能データ処理装置にロードされてよい。これによって、コンピュータまたは他のプログラム可能データ処理装置上で一連の処理段階を実行することができる。結果として、コンピュータまたは他のプログラム可能データ処理装置において実行されるインストラクションが、１以上のフローチャートブロックによって特定される機能を実施する段階を与えることになる。
【００３２】
最初に図１から５を参照すると、移動アドホックネットワーク２０においてソースノードから目的地ノードへのルートを決定する方法が、説明される。ネットワーク２０は、複数の移動可能ノード３０を有している。これらの移動可能ノード３０は、ソースノード１と、目的地ノード４を有し、さらに、ソースノード１と目的地ノード４の間に存在する中間ノード２、３、５を有している。当業者に理解されるように、ラップトップコンピュータ、パーソナルディジタルアシスタント（ＰＤＡ）または携帯電話のようなノード３０は、無線通信リンク３２によって接続される。ブロック１００において方法が開始され、図５のブロック１０２に示されるように、ＱｏＳパラメーターに基づいて目的地ノード４へのルートを決定するために、サービス品質（ＱｏＳ）ルートリクエストＲＲＥＱＱをソースノード１から送信する。以下で詳細に説明されるように、ＱｏＳパラメータは、好ましくは、利用可能な帯域幅、誤り率、端部から端部までの遅延（ｅｎｄ−ｔｏ−ｅｎｄ ｄｅｌａｙ）、端部から端部までの遅延の変動、ホップカウント（ｈｏｐ ｃｏｕｎｔ）、期待される経路の耐久性、および／または優先度に基づくものである。他のＱｏＳメトリック（測定基準（ｍｅｔｒｉｃ））が、以下において説明される。ルートリクエストＲＲＥＱＱは、ＱｏＳフロー識別子と、更新可能なＱｏＳリンクメトリックを含む。
【００３３】
また、ブロック１０４において、中間ノード２、３、５を含むノードがＱｏＳルートリクエストＲＲＥＱＱが要求するＱｏＳパラメータをサポート・支持（ｓｕｐｐｏｒｔ）できるかどうかを決定する。ノードが、特定のリクエストＲＲＥＱＱのＱｏＳパラメータをサポートできない場合には、ブロック１０６において、リクエストが否定され、リクエストはこのノードによって転送されない。ノード（例えば、ノード３）が、この特定のリクエストＲＲＥＱＱのＱｏＳパラメータをサポートできる場合には、このノードはＱｏＳリンクメトリックを更新し、このＱｏＳルートリクエストを他の中間ノード２と５に転送し、このＱｏＳルートリクエストのためにノード資源を一時的にとっておく・蓄える（ブロック１０８）。中間ノード２、５も、これらのノード２、５が、ノード３から転送されたＱｏＳルートリクエストＲＲＥＱＱをサポートできるかどうかを決定しなければならない。サポートできる場合には、更新されたＱｏＳリンクメトリックを持つルートリクエストＲＲＥＱＱが目的地ノード４に転送される。
【００３４】
目的地ノード４は、ＱｏＳルートリクエストＲＲＥＱＱを受信すると、ソースノード１への返信ＲＲＥＰＱを生成する（ブロック１１０）。この実施形態では、返信ＲＲＥＰＱは、フロー識別子（ｆｌｏｗ ｉｄｅｎｔｉｆｉｅｒ）と更新されたＱｏＳリンクメトリックを有する。この更新されたＱｏＳリンクメトリックは、各発見されたルートに関するものである。言い換えると、目的地ノード４は、例えば、１−２−４または１―３−５−４を含む様々な可能なルートのどこからでも転送されたＱｏＳルートリクエストＲＲＥＱＱを受信してよい。返信ＲＲＥＰＱは、各場合において生成される。ブロック１１２において、ソースノード１は、発見されたルートに関して、目的地ノード１からの返信ＲＲＥＰＱに含まれる更新された（複数の）ＱｏＳリンクメトリックに基づいて（複数の）ＱｏＳルートメトリックを生成する。また、ブロック１１４において、ソースノード１は、生成されたＱｏＳルートメトリックに基づいて目的地ノード４へのルートを選択する。
【００３５】
特に、本発明のいくつかの実施形態では、目的地ノード４へのルートは、複数のＱｏＳルートメトリックの加重平均を用いて選択されてよい。そのような実施形態を、図６を参照して説明する。図６に示された方法は、移動アドホックネットワーク２０におけるソースノード１と目的地ノード４の間の通信のために供給される。ブロック６０において方法が開始され、ＱｏＳルートリクエストが複数の中間ノード２、３、５を介してソースノード１から目的地ノード４へ送信される。これによって、上述したように複数のＱｏＳパラメータに基づいて目的地ノードへのルートを見つけ出す（ｄｉｓｃｏｖｅｒ）。ＱｏＳルートリクエストに応答して、ソースノード１と目的地ノード４の間の複数の可能性のあるルートが、ブロック６２において、上述したように、可能性のある各ルートに関する各ＱｏＳパラメータに対応するＱｏＳルートメトリックとともに決定される。
【００３６】
メトリック収集は様々な方法で行われてよい。例えば、これは、当業者に理解されるように、ＤＳＲタイプのアルゴリズムまたはリンク状態アルゴリズム（ｌｉｎｋ ｓｔａｔｅ ａｌｇｏｒｉｔｈｍ）を用いて、ソースノード１において全体的なメトリックベクトルを集めることによって実行されてよい。また、メトリック収集は、中間ノードにおける寄与を加えることにより、増加的に経路ベクトルを計算して実行されてもよい。後者のアプローチは、サポートされ得る全体の経路とネットワークメトリックの形式により多くの制限を与えることになる。もちろん、当業者は、本発明が、上述した先行技術のリアクティブプロトコルとプロアクティブプロトコルを含む多くの移動アドホックルーティングプロトコルを用いて実施されてよい。リアクティブプロトコルについて説明するが、既存の知られているプロアクティブルートに同報通信（ｂｒｏａｄｃａｓｔ）を制限してプロアクティブプロトコルを用いてもよい。
【００３７】
本発明のリアクティブプロトコルの態様によると、ブロック６３において、ＱｏＳパラメータは、重要さの順番でランク付けされてよい。当業者に理解されるように、このランク付けは、好ましくは、ネットワークの機能目的（ｎｅｔｗｏｒｋ ｐｅｒｆｏｒｍａｎｃｅ ｏｂｊｅｃｔｉｖｅｓ）の決定に基づいて、ネットワーク配置・配備の前に、行われれる。ランク付けによって、重み係数が決定される。重み係数は、各ノードに関して予め決定されており、または、ネットワーク管理によって設定される。実際のノードの作用の間、ノードはランク付けを知っている必要はない。むしろ、ノードは重み係数を知っているひつようがある。様々な移動アドホックネットワーク機能に関するランク付けが、次の表１に示されている。
【００３８】
【表１】

表１から分るように、ルートを選択する場合に、望まれるルートのタイプに基づいて様々なランク付けが用いられてよい。例えば、縦列の１つの項目である“ＱｏＳ帯域幅経路”は、最大の帯域幅を持つルートを得るのに最も重要な５つのＱｏＳパラメータのランク付けを与える。同様に、縦列の１つの項目である“Ｑｏｓ遅延経路”と“最善努力経路”は、それぞれ、最も少ない遅延量を持つルートまたは最善努力アプローチを用いてメッセージデータを伝達できる確率の最も高いルートを選択するためのランク付けを与える。もちろん、様々なランク付けが特定の適用のために用いられてよく、他のルート発見機能・特性が本発明に従ってランク付けされてよいことが当業者に理解されるであろう。ブロック６３に示されているランク付けを行う段階は、図示された順番で実行される必要はない（例えば、予めランク付けが行われていてもよい）。
【００３９】
所定の適用に用いられるＱｏＳパラメータのランク付けに基づいて、ＱｏＳメトリックの各々は、ブロック６４において、ソースノード１によって重み係数が乗ぜられていてよい。好ましくは、適切な値を重みベクトルｗに割り当てることが、上述したように、メトリックのランク付けに基づいて動作（ｏｐｅｒａｔｉｏｎ）前に行われてよい。実際にメトリックに重み係数を乗ずることは、好ましくは、以下で説明され与えられる数式に示されたように、リアルタイムの動作の間に、実行される。そのように、重み係数を掛けられたＱｏＳルートメトリックが、お互いと比較されて、ブロック６５において、この比較に基づいて、可能性のあるルートのうちの１つが選択される。一旦ルートが選択されると、ブロック６６において、選択されたルートを介してソースノード１から目的地ノード４へメッセージデータが送信される。このようにして、方法の実行が終了してよい（ブロック６７）。このメッセージデータは、動作の間に移動アドホックネットワークのノード間で送信される追加的なリクエスト／返信、ビデオデータ、音声データ、文字と数字のデータなど（これらに限定されない）を含むように意図されている。
【００４０】
特定の実施形態によると、ＱｏＳメトリックは、有益に・都合よく、ＱｏＳリンクメトリックおよび／またはＱｏＳノードメトリックを含む。特に，ＱｏＳリンクメトリックは、利用可能な帯域幅、誤り率、端部から端部までの遅延、端部から端部までの遅延変動、ホップカウント、期待される経路の耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含んでよい。ＱｏＳノードメトリックは、バッテリー寿命、移動性・移動度、通信容量および位置のうちの少なくとも１つを含んでよい。ＱｏＳノードメトリック／ＱｏＳリンクメトリックのさらなる例は、表１に与えられている。もちろん、当業者に知られている他のＱｏＳノードメトリック／ＱｏＳリンクメトリックが用いられてもよい。
【００４１】
上述したＱｏＳノードメトリック／ＱｏＳリンクメトリックに重み係数を乗じることが、２つの特定の例に関して説明される。一般的に、ルートを選択する場合に、重み係数を乗じた複数のＱｏＳメトリックの総和は、例えば、好ましくは、可能性のあるルートの各々に関して生成される。可能性のあるルートの各々の重み係数を乗じたＱｏＳメトリックの総和は、他の残りのＱｏＳノードメトリック／ＱｏＳリンクメトリックの重み係数を乗じたそれぞれの総和と比較され、最終的なルートがこの比較に基づいて選択される。特定の例を説明する前に、次の用語と定義をこれらの特定の例の理解を助けるために述べておく。
【００４２】
以下の例に関して、リンクメトリックベクトルｍ_Ｌとノードメトリックベクトルｍ_Ｎが定義される。リンクメトリックベクトルｍ_Ｌとノードメトリックベクトルｍ_Ｎの各々は、ネットワーク編成における様々なＱｏＳ要求を満足させるためにルートを評価するうえでの重要な特性である。また、ノードメトリックの形式は、ｍ_Ｎ＝（Ｃ_Ｎ１，Ｃ_Ｎ２，Ｃ_Ｎ３， ．．．）で与えられる。ここで、Ｃ_Ｎｉはノードメトリックベクトルのｉ番目の成分である。リンクメトリックの形式は、ｍ_Ｌ＝（Ｃ_Ｌ１，Ｃ_Ｌ２，Ｃ_Ｌ３， ．．．）で与えられる。ここで、Ｃ_Ｌｉは、リンクメトリックベクトルのｉ番目の成分である。当業者に理解されるように、リンクメトリックベクトルとノードメトリックベクトルは、ネットワークコントロールパケットでネットワーク２０にわたって伝達されることが可能である。
【００４３】
ソースノード１１から目的地ノードｋ＋１へのルートに関する未処理の経路メトリックは、ノード／リンクメトリックベクトルｍ_Ｐ＝（ｍ_Ｌ１，ｍ_Ｎ１，ｍ_Ｌ２， ．．． ，ｍ_{Ｌ（ｋ−１）}，ｍ_Ｎｋ，ｍ_Ｌｋ）で表現される。上述したように、所定の適用において重要なメトリック成分が、ランク付けされる。リンク重みベクトルＷ_Ｌとノード重みベクトルＷ_Ｎが定義されてよい。当業者に理解されるように、所定の適用において望ましい強調を与えるために、これらのメトリックベクトルは、ゼロとゼロでない成分を含んでよい。最終的は経路メトリックは、未処理の経路メトリックベクトル、ノード重みベクトルおよびリンク重みベクトルの関数として評価・表現されるスカラーであってよい。このスカラー最終経路メトリックは、Ｍ_Ｐ＝Ｆ（Ｗ_Ｎ，Ｗ_Ｌ，ｍ_Ｐ）で与えられる。経路またはルートは、好ましくは、最終経路メトリックＭ_Ｐの最もよい値に基づいて選択される。用いられる関数Ｆ（）の形は、もちろん、特定の適用（例えば、ＱｏＳ遅延経路、ＱｏＳ容量割り当て、最善努力など）に依存してよい。
【００４４】
遅延に敏感なＱｏＳ経路メトリックの第１の例を説明する。以下で与えられる第１経路メトリックの式は、ホップカウント（１の重み（ｗｅｉｇｈｔ））、双方向性（双方向のリンクの場合には、ＢＤ＝０、１方向のリンクの場合には、ＢＤ＝１で重みＫ_３を持つ）、見積もられたリンク遅延（重みＫ_１を持つ）、およびリンク容量の逆数（重みＫ_２を持つ）に関する成分を用いる。この例では、最もよい経路は、最小の経路メトリックに対応する。これらの重みに関するパラメータは、好ましくは、動作性能特性に基づいて予め作成することにより、前もって特定される。このような第１経路メトリックは次の式で表される。
【００４５】
【数１】

ＱｏＳルートメトリックを用いてルートを決定する二番目の例は、フロー割り当て必要性のためのＱｏＳ（サービス品質）が保証される容量割り当てＣ_ｒｅｑが要求された場合のためのものである。以下の経路メトリックの第２の例の式は、利用可能リンク容量Ｃ_Ａ（１の重みを持つ）、見積もられたリンク遅延（重みＫ１を持つ）、見積もられた遅延基準ずれ（重みＫ_２を持つ）、リンクでのパケットによる見積もられた送信回数（重みＫ_３を持つ）および双方向性（重みＫ_４を持つ）に関する成分を含む。この場合、最も良い経路は、最小の経路メトリックを持つ。このような第２経路メトリックは、次の式で与えられる。
【００４６】
【数２】

上述の方法の他の態様を、図７から９を参照して説明する。図８と９に示された例示的な移動アドホックネットワーク２１０は、無線通信リンク２１３によって接続された複数のノード２１１を含む。当業者に理解されるように、ノード２１１は、コンピュータ、パーソナルディジタルアシスタント（ＰＤＡ）などのような無線アドホックネットワーク内において通信可能な無線通信装置のどんな適切なタイプのものでもよい。もちろん、望まれる場合には、いくつかの実施形態では、ノード２１１のいくつかは、固定された通信インフラストラクチャーに動作可能に接続されている。
【００４７】
ノード２１１は、好ましくは、図８と９におけるノードのそれぞれのグループを囲む円のように、クラスター２１２にグループ分けされる。ノード２１１をクラスター２１２にグループ分けすることは、以下で詳細に説明される。クラスター２１２の各々に関して、ノード２１１のうちの１つは、それぞれのクラスターリーダーノード２２１から２３３として指定される。クラスターリーダーノード２２１から２３３を指定するプロセスとこのプロセスの機能は以下で説明される。説明を明確にするために、クラスター２１２を個々に関して説明する場合に、ある特定のクラスターには、当該クラスターのクラスタリーダーノードと同じ参照符号が付される。例えば、クラスターリーダーノード２２１は、クラスター２２１内に存在する。
【００４８】
本発明のこの方法の態様によると、ブロック７０において方法が開始され、上述したようにブロック７１においてノードがクラスターにグループ分けされる。その後、隣接するクラスターのターゲットノード（例えば、ノード２１７ａ）が、以下で詳細に説明されるように、アクセスポイントを提供しクラスターを通してルーティングを可能にするために少なくとも１つの中間クラスター（例えば、クラスター２２５）において設立される。これは、以下で詳細に説明されるように、ソースノード２１４と中間クラスター２２５の複数の可能性のあるターゲットノードとの間のターゲットルートを決定することによって有益に・都合よく行われる。上で説明したように、クラスター２２５内の様々な可能性のあるターゲットノードからの選択は、再び、重み係数を掛けられたＱｏＳメトリックに基づくものである。即ち、ＱｏＳターゲットメトリックは、好ましくは、各ターゲットルートに関して複数の望まれるＱｏＳターゲットパラメータの各々に対応するように決定される（ブロック７２）。
【００４９】
また、ＱｏＳターゲットパラメータは、上述したように、ブロック７３において、重要さの順番でランク付けされてよい。特に、表１は、縦列の項目となる“ＡＣＴＮノード選択”において隣接クラスターターゲットノード指定に関する例示的なラング付けを含む。もちろん、当業者に理解されるように、他のＱｏＳパラメータと他のランキング順位が、様々な適用において用いられてよい。
【００５０】
ＱｏＳターゲットメトリックに、その後、上述したように、ＱｏＳターゲットメトリックのランキングに基づいて重み係数が掛けられる（ブロック７４）。重み係数が掛けられたＱｏＳターゲットメトリックは、お互いと比較される。これによって、隣接クラスターターゲットノード（この例では、ノード２１７ａ）が、ブロック７５においてこの比較に基づいて選択される。ここで、重み係数を掛けられたＱｏＳターゲットメトリックの総和が、上記の第１式と第２式と同様な適切な式を用いて可能性のあるルートの各々に関して生成される。ソースノード２１４と目的地ノード２１５の間のベストルートは、隣接クラスターターゲットノード２１７ａを含む中間クラスター２２５を通るように選択される（ブロック７６）。
【００５１】
もちろん、当業者は、例えば、図８と９に示されたように、ソースクラスター２２１と目的地クラスター２３２の間に、多くの中間クラスターが存在するかもしれないことを認識するであろう。説明を明確にするために、隣接クラスターリーダーノード２１７ａだけの選択を説明したが、図９に示された最終ルートに沿って、引き続く隣接クラスターターゲットノード２１７ｂから２１７ｄを決定するために同じアプローチが用いられてよいことが理解されるであろう。このように、メッセージデータが、中間クラスター２２５（図示された例では、中間クラスター２２４、２２９、２２６、２３２も存在する）を介してソースノード２１４から目的地ノード２１５へ送信される。このアプローチのために用いられるターゲットメトリックは、例えば、上述したように、リンクノードメトリックおよび／またはノードメトリックを含んでよい。
【００５２】
図５を再び参照すると、ブロック１１６において、ソースノード１は、ルート確認ＣＯＮＦＱを選択されたルートで中間ノードへ送信する。これは、ブロック１０８において一時的にとっておかれた選択されたルートでの資源の使用を確認するためである。発見されたが選択されていないルートでの他に一時的にとっておかれた資源は、それらのルートでＣＯＮＦＱを送信しないでタイムアウトまで使用可能な状態にしておいてよい。
【００５３】
また、ソースノード１は、確認ＣＯＮＦＱを代用ルート上の中間ノードへ送信してまたは送信しないで、少なくとも１つの代用ルートを選択してよい。そのような待機ルート・代用ルート（ｓｔａｎｄｂｙ ｒｏｕｔｅ）は、複製送信（ｄｕｐｌｉｃａｔｅ ｔｒａｎｓｍｉｓｓｉｏｎ）、追加的な信頼性のためにあってよく、または、ルート故障およびまたはＱｏＳ欠損の場合のためのバックアップルートとして用いてもよい。ブロック１１８において、中間ノード２、３、５および／または目的地ノード４は、いつでも、ノードが継続してＱｏＳルートリクエストＲＲＥＱＱが要求するＱｏＳパラメータをサポートできるかどうかを探知してよい。ノードがトラヒック（ｔｒａｆｆｉｃ）の伝達を通してリクエストＲＲＥＱＱを継続してサポートできる場合には、とっておかれた資源と関連ルートが、ブロック１２６においてインアクティブ（使用されない状態（ｉｎａｃｔｉｖｅ）であると決定された場合には、タイムアウトまで使用可能な状態にされ、ある時間の間、データトラヒックのために使用されない場合またはある時間の間、周期的なＣＯＮＦＱメッセージの送信のために使用されない場合には、ブロック１２８において解放さる。
【００５４】
ノードが、継続してリクエストＲＲＥＱＱをサポートできない場合には、ノードは、ＱｏＳエラー通知ＲＥＲＲＱをソースノード１へ送信する（ブロック１２０）。この場合、ソースノード１は、ＱｏＳパラメータに基づいて目的地ノード４への新たなルートを発見するためにサービス品質（ＱｏＳ）ルートリクエストＲＲＥＱを送信する（ブロック１０２）一方、ＱｏＳエラー通知ＲＥＲＲＱを受信したときに、選択されたルートを維持してよい。ソースノード１は、ＱｏＳエラー通知ＲＥＲＲＱを受信した場合に、代用ルートへ切り替えてもよい（ブロック１２４）。
【００５５】
当業者に理解されるように、上述した本発明の方法の態様は、ダイナミックソースルーティング（ＤＳＲ）または上述したＡＯＤＶルーティングのようなオンデマンドルーティングプロトコルまたはリアクティブプロトコルのどのようなタイプのものに適用してもよく、または、ゾーンルーティングプロトコルＺＲＰのようなどのようなハイブリッドプロアクティブプロトコルまたはハイブリッドリアクティブプロトコルに適用してもよい。
【００５６】
ＱｏＳのカテゴリーとして最小帯域幅の割り当てと最大遅延制限を考慮したさらなる例を説明する。所定の帯域幅の割り当てに関して、ノード３０はある量の容量または帯域幅をとっておくことができると仮定する。トラヒックフローのノード１は、ＱｏＳルートリクエストＲＲＥＱＱを要求されるフロー（ｆｌｏｗ）の各々に関して送信する（ＲＲＥＱＱの最後のＱは、ＱｏＳリクエストを示す）。ＲＲＥＱＱメッセージは、要求されるＱｏＳをサポートできるルートを発見する機能を実行する。ＲＲＥＱＱを目的地４へ転送するノードは、ＲＲＥＱＱを転送する前に要求されるＱｏＳを満足させることができるかどうかを宣言（ｎｏｔｅ）し、これらのノードは、必要な場合には、資源を一時的にとっておく。ルート返答ＲＲＥＰＱパケットが、その経路にわたって要求されるＱｏＳが満足させられるかどうかという通知と共に目的地から返信される。ソースノード１は、望まれるＱｏＳを供給するために最善の選択を決定する前に、目的地４への複数の可能性のある経路を集めてよい。一旦この経路が決定されると、確認ＣＯＮＦＱメッセージが、示された経路に沿って目的地４へ送信される。この経路上において、一時的にとっておかれるどんな資源も、永久的・長期的な蓄えであると確認される。ＱｏＳの蓄え（ｒｅｓｅｒｖａｔｉｏｎ）が所定の時間の間、使用されない場合には、ＱｏＳの蓄えは時間切れになる。ルートに沿ったリンクが故障している（ｆａｉｌ）場合には、または、ＱｏＳリクエストが満足させられない場合には、ルートエラー（ＲＲＥＱＱ）パケットが、生成され、ソースノードへ戻される。
【００５７】
特に、与えられた目的地ノード４への新たなＱｏＳルートが必要とされる場合には、ソースノード１は、ＲＲＥＱＱパケットを目的地ノードへ同報通信する（ｂｒｏａｄｃａｓｔ）。これは、ＤＳＲやＡＯＤＶのようなプロトコルにおいて用いられる従来のＲＲＥＱパケットと同様なパケットの特定のタイプのものである。従来のＲＲＥＱ同報通信は、最善努力サービスのために用いられる。本発明の方法は、最善努力サービスのためのプロトコルによって設立された従来の手順に従ってよい。
【００５８】
指定された最小容量または帯域幅が、トラヒックフローのために要求される場合には、特別のＲＲＥＱＱパケットが、指定された容量で目的地ノード４へのフローをとっておくために用いられる。この場合、フローＩＤが、ソースノード１によってＲＲＥＱＱに割り当てられる。このフローＩＤは、ソースノードアドレスと結合させられてネットワーク２０においてフローを転送するどのノードへのフローでも一義的に識別する。ＲＲＥＱＱパケットは、とっておかれるべき容量（ｃａｐａｃｉｔｙ）も示す。
【００５９】
目的地４への経路における各ノード２、３、５で、最小容量要求または最小大域幅要求が利用可能な容量に対してチェックされ、フローのために蓄えが可能かどうかを決定する。ノードが要求されるトラヒック容量を収容・受容できる場合には、そのフローＩＤのために容量が一時的にとっておかれる（蓄えられる）。短時間の間にＣＯＮＦＱメッセージが受信されない場合には、この一時的な蓄えが解放される。ＲＲＥＱＱが、指定された最大遅延を超えない経路が見つかることを保証するように意図されている場合には、経路に沿った各ノードは、合計の経路遅延への当該ノードの寄与の評価・見積もりを行い、経路に沿った今までの寄与を加えた合計の遅延が指定された最大遅延の制限を越えていないかどうかを確かめるためにチェック・検査できなければならない。
【００６０】
最善努力トラヒックのためのＤＳＲやＡＯＤＶの従来の適用と違って、ＱｏＳ要求を満足する有効な経路が存在するかどうかを決定するために、ＲＲＥＱＱは目的地ノード４までの経路を通して伝達・伝播することが可能でなければならない。そのような経路が見つかった場合には、目的地ノード４は、ソースノード１に返信されるべきＲＲＥＰＱメッセージを生成する。このメッセージは、要求されるＱｏＳを満足する目的地ノード４への有効な経路が見つかり、経路が設立されたことをソースノードに対して示す（ＤＳＲの場合には、ソースルート・送信元経路に戻される）。見積もられた経路遅延は、遅延保証を求めるリクエストと容量を保証する経路のためのＲＲＥＰＱに含まれる。
【００６１】
ソースノード１は、要求されるＱｏＳを満足する目的地ノード４への複数の経路に関する複合ＲＲＥＰＱ（ｍｕｌｔｉｐｌｅ ＲＲＥＰＱ）を受信してよい。ソースノード１はこれらの経路の順位をランク付けて、最も高くランク付けられている経路である経路の選択を示すＣＯＮＦＱメッセージを発信する。他の経路はバックアップ経路として維持されてよいが、ＣＯＮＦＱがこれらの経路上に送信されない場合には、バックアップの代わりの経路として必要とされたときに、要求される資源が利用可能であることは保証されない。
【００６２】
いずれかの中間ノード２、３、５においてまたは目的地ノード４において、要求されるＱｏＳが満足させられない場合には、このノードを通る経路が要求されるＱｏＳを満足しないことを知っているので、ＲＲＥＱＱパケットが破棄される。しかしながら、発見プロセスによって、他の経路が見つかるかもしれない。いずれかの時点でリンクが故障した場合には、または、ＱｏＳ要求が満足されない場合には、ルートエラーＲＥＲＲＱパケットが生成され、故障の影響を受けるトラヒックフローの各々に関してソースノード１に返信される。この場合には、バックアップ経路が使用されなければならないかまたはルート発見プロセスが再び開始される。
【００６３】
上述した手順は簡単にＤＳＲプロトコルに適用される。従来ＤＳＲメッセージタイプのＲＲＥＱ，ＲＲＥＰ，ＲＲＥＲは、選択的な・オプションのパケットタイプとして定義され、逆方向適合モード（ｂａｃｋｗａｒｄｓ ｃｏｍｐａｔｉｂｉｌｉｔｙ ｍｏｄｅ）において最善努力トラヒックをサポートするのにプロトコルの従来の動作のために定義されたように使用されることが可能である。ＱｏＳ経路を管理するのに用いられるＲＲＥＱＱ、ＲＲＥＰＱ，ＲＲＥＲＱおよびＣＯＮＦＱパケットタイプを含む新たなパケットタイプが、ＱｏＳをサポートするために定義される。これらのタイプの要求されるヘッダーフィールドの定義は、直接的に上で定義した関数に基づくものである。ＱｏＳミッションデータのためのＱｏＳソースルーティングパケット（ＱｏＳ ｓｏｕｒｃｅ ｒｏｕｔｅｄｐａｃｋｅｔ）の特別のタイプも含まれる。ＱｏＳミッションデータのためのこのパケットは、パケットがどのフローに属するのかを識別するために、および、フロートラヒックの測定（ｍｅｔｅｒｉｎｇ）を考慮するために、フローＩＤを含んでよい。故障によってノードがＲＥＲＲＱパケットを発生させた場合には、以下の手順を用いてよい。ＲＥＲＲＱパケットがソースノードにおいて受信された場合には、現在のルートが破棄され、バックアップルートが試される。バックアップルート上で送信される最初のパケットは、別のタイプの特別のＱｏＳソースルーティングパケット（例えば、フローＩＤとＱｏＳパラメータを含むＲＲＥＱＴ）であってよい。また、このパケットは、ミッションデータを含むことも可能である。経路に沿った各ノードは、当該ノードがフローのために一時的な蓄えをまだ維持しているかどうかを確認するために検査・チェックをしなければならない。これらのノードが一時的な蓄えを維持していない場合には、これらのノードは、当該ノードがフローをサポートできるか、および、一時的なたくわえをすることができるかを確認するために再びチェックを行う。フローが各中間ノードでサポートされながらパケットが目的地に達した場合には、目的地ノードは、ソースノードに経路が有効であることを通知するためのＲＲＥＰＱパケットを返信する。
【００６４】
いずれかのノードがフローをサポートできない場合には、パケットが破棄され、このノードは、経路が要求されるＱｏＳパラメータをサポートできないことをソースノードに通知するためのＲＥＲＲＱパケットをソースノードに返信する。ソースノードがＲＲＥＰＱパケットを受信すると、ソースノードは、継続してトラヒックフローに関するミッションデータを送信することに加えて、ＣＯＮＦＱメッセージを経路の選択を確認するＣＯＮＦＱメッセージを選択された経路に沿って送信する。
【００６５】
ソースノード１がＲＥＲＲＱパケットを受信した場合には、ソースノード１は次の利用可能なバックアップ経路で同じ手順を試みる（実行する）。ソースノードが、目的地までのバックアップノードを１つの持っていな場合には、ソースノードは、目的地ノードまでの新たなＱｏＳ経路のために別のルート発見プロセスを開始する。新たなルートが見つかるまで、データフローが中断される。どの特定のプロトコルに関しても、各トラヒックフローに割り当てられる資源を管理するのに要求されるデータストラクチャーを定義することが可能であり、フローを識別する方法・仕方と、各フローに割り当てられたルートを調べる方法・仕方も定義することが可能である。ＱｏＳパラメータに基づくルート選択のさらなる詳細は、上記の米国特許出願第１０／１３４，７１５号に説明されている。
【００６６】
上述したクラスター連合とクラスターリーダーノードの選択の動作の詳細を、図１０を参照して説明する。図１０において、新たなクラスターリーダーの選択の概要が図示されている。クラスター３０１と３０２は、それぞれ、指定されたクラスターリーダーノード３０１と３０２を有している。図１０に示された例を用いて説明すると、ノード始動選択とクラスター連合の動作の詳細を説明する。
【００６７】
ノード始動とクラスター連合に関して、始動が起こると、ノード３０３は、次の段階を実行する。ノード３０３は、隣接するクラスター（この例ではクラスター３０１と３０２）のクラスターリーダーノードから周期的なクラスターリーダーノードアナウンス（ＣＬＮＡＮＮ）メッセージを聞き（ｌｉｓｔｅｎ ｆｏｒ）、ノード３０３が参加・連結（ｊｏｉｎ）するかもしれない可能性のあるクラスターを識別する。さらに、ノード３０３は、ｋ_Ｎ番目のホップ地域（ｈｏｐ ｎｅｉｇｈｂｏｒｈｏｏｄ）のすべてのノードに対する経路メトリック情報を集めるために、ｋ_Ｎ番目のホップ地域のノード２１１から周期的なＨＥＬＬＯメッセージを聞いてよい。さらに、ノード３０３は、ｋ_Ｎ番目のホップ地域のすべてのノードに対して周期的なＨＥＬＬＯメッセージを同報通信する。その後、クラスター連合メトリックＭ_ｍ ^ＣＡ（ｃｌｕｓｔｅｒ ａｓｓｃｉａｔｉｏｎ ｍｅｔｒｉｃ）が、各隣接クラスターリーダーｍに関して形成され、クラスターリーダーノードｍが、最小のクラスター連合メトリックＭ_ｍ ^ＣＡを用いて、参加するクラスターとして、選択されてよい。
【００６８】
クラスター連合メトリックＭ_ｍ ^ＣＡは、考えているノードが参加しようとするクラスターに十分近いことを示すために、好ましくは、閾値Ｔ_Ｊより小さい。この閾値が満足させられる場合には、クラスター参加メッセージＣＬＪＯＩＮがクラスターリーダーノードｍに送信される。クラスターが、クラスターごとのノードの数についての制限Ｌ_ＣＬより小さい値のノード数を持っている場合には、クラスターリーダーノードは、クラスターにノードを受け入れ、容認メッセージＣＬＡＣＣＥＰＴを当該ノードに送信する。クラスターリーダーノードが、別のメンバーを受け入れることができない場合には、クラスターリーダーノードは当該ノードに拒絶メッセージＣＬＲＥＪＥＣＴを送信する。また、ノードが拒絶された場合には、当該ノードは、次のベストクラスターリーダーノードをバックアップとして選択し、そのクラスターに参加するためにプロセスを繰り返す。上述のプロセスに従ったノード３０３は、たいていは、例えば、始動・電源オン（ｐｏｗｅｒｉｎｇ ｕｐ）の後すぐに、普通にクラスター２１２のメンバーになる。ノード３０３をクラスターに連合・関係させる別のアプローチを図１１を参照して説明する。この別のアプローチを図１０に示された例で説明を続けると、この方法の態様は、ブロック９０で開始され、上述したように、ノード２１１をクラスター２１２にグループ分けする。ブロック８２で、追加のノード３０３がクラスター２１２との連合のためにネットワークに与えられた場合に（例えば、ノード３０３が始動した場合に）、ブロック８３で、追加のノードから各クラスター（この例では、クラスター３０１と３０２）における少なくとも１つのノードへのルートが設立される。このルートの設立は、上述した技術を用いて行われてよい。いくつかの実施形態では、クラスター２１２内のルートが設立されたノードが、そのクラスターのクラスターリーダーノードである。他の実施形態では、このノードは、ホップカウントの観点から、クラスター２１２において、追加のノード３０３に最も近いノードであってよい。当業者に理解されるように、（ルート設立のための）他のノード（または、２以上のノード）が、他の実施形態において用いられてよい。
【００６９】
本発明の１つの実施形態によると、本発明の方法は、ブロック８４において、各ルートに関してＱｏＳリンクメトリックを決定する段階を含んでよい。この段階は、図６を参照して説明したように実行されてよい。各ＱｏＳリンクメトリックは、上述したようなＱｏＳリンクパラメータに対応している。ＱｏＳリンクパラメータは、上述したように、重要さの順番でブロック８５においてランク付けされる。１つのそのような例示的なランク付けのアプローチは、表１の縦列の項目“クラスター参加”に与えられる。他のＱｏＳパラメータとランク付けが、様々な実施形態で用いられてよい。上述したようにＱｏＳリンクパラメータのランク付けに基づいてＱｏＳリンクメトリックに、重み係数が乗ぜられて（ブロック８６）、関係・参加・連合するのにどのクラスターがノード３０３にとって最も良いかを決定するために、ブロック８７において、重み係数が乗ぜられたＱｏＳリンクメトリックが、お互いに対して比較される。このように、方法が終了する（ブロック８８）。また、重み係数を乗ぜられたＱｏＳリンクメトリックの総和が、各ルートに関して生成されてよい。参加・関係するのに最も良いクラスター２１２を決定するために、重み係数を乗ぜられたＱｏＳリンクメトリックが、お互いに対して比較されてよい。
ノード参加・連結のために用いられてよい式を以下で与える。例えば、ノード３０３がどのクラスター３０１、３０２が参加するかを決定し、上述したように、このノードが、隣接するクラスター（この例では、クラスター３０１と３０２）のノードへの経路メトリック（ｐａｔｈ＿ｍｅｔ）情報を集めて、エリアメトリックを形成する。次の式は、ＱｏＳパラメータ逆数リンク容量（重み１を持つ）、リンクでのパケットによる送信の見積もられた回数（重みＫ_１を持つ）および双方向性（重みＫ_２を持つ）を含む。また、この例では、隣接クラスターリーダーノードＡＬＮ（またはＣＬＮ）３０１、３０２への経路メトリック（ｐａｔｈ＿ｍｅｔ_ＡＬＮ）には他のノードよりも大きな重み係数が乗ぜられ、クラスターメトリックが、クラスターのノードの数によって正規化される。連合するのに最も良いクラスターは、次の式を用いて最も小さいエリアメトリックを与える。次の２番目の式において、隣接クラスターリーダーノードへの経路メトリックをｐａｔｈ＿ｍｅｔ_ＡＬＮで表し、それ以外のノードへの経路メトリックをｐａｔｈ＿ｍｅｔ_ｉで表している。
【００７０】
【数３】

例えば、ネットワークの開始のように、ノード３０３が、参加・関係することを容認できるクラスターリーダーノード（２２１から２３３）を見つけることができない場合がある。この場合には、ノード２１１は、クラスターリーダーノードになるために争うことを決めてよい。普通のノード３０３がクラスターリーダーノードになるために争うことを決めた場合には、ノード３０３は次の手順を開始する。クラスターリーダーノードになるための値をアナウンスするために、ノード３０３は、特別のタイプのＣＬＮＡＮＮメッセージを、ｋ_Ｎ番目のホップ地域におけるすべてのノード２１１に同報送信する。クラスターリーダーになるための値は、この値をアナウンスをした当該ノードによって計算されたクラスターリーダーメトリックを含む。信頼性を目的とすることに関しては、ｋ_Ｎ番目の地域のノード２１１の各々は、好ましくは、ＣＬＮＡＮＮメッセージに対して返信を行う。当業者に理解されるように、この返信を行わないノードに対しては、ユニキャストによってフォローアップＣＬＮＡＮＮメッセージが送信されてよい。
【００７１】
ＣＬＮＡＮＮメッセージに対して肯定的に返信するノード２１１は、ノード３０３がクラスターリーダーノードになることを承認することを示すＣＬＮＡＮＮメッセージを返信する。ノード２１１は、当該ノード２１１がクラスターリーダーノードとなるための位置にないこと理由に、または、当該ノード２１１がオリジナルＣＬＮＡＮＮメッセージで受信されたクラスターリーダーメトリックよりも大きいクラスターリーダーメトリックを持っていること理由に、この肯定的な返信を行う。ＣＬＮＡＮＮメッセージに対して否定的に返信を行うノード２１１は、当該ノード２１１が、オリジナルＣＬＮＡＮＮメッセージで受信されたクラスターリーダーメトリックよりも良いクラスターリーダーメトリックを持っていて当該ノード２１１がより良いクラスターリーダーであろうことをアナウンスするＣＬＮＡＮＮメッセージを返信する。クラスターリーダーメトリックの値が同じである場合には、クラスターリーダーが入れ替わることになるとしても、クラスターリーダーの役割は、例えば、最も低いノードＩＤを持つノードに与えられる。
【００７２】
すべてのＣＬＮＡＮＮメッセージが肯定的である場合には、または、競争があったがノード３０３がクラスターリーダーの役割を勝ち取った場合には、当該ノード３０３がクラスターリーダーの役割を引き受ける。このノード３０３は，ｎ_ＣＬホップに関して伝達されるべき規則的なＣＬＮＡＮＮメッセージの周期的な同報送信を開始し、これによって隣接クラスター２１２のすべてのノードと隣接クラスターリーダーノードに当該ＣＬＮＡＮＮメッセージが達する。他のノード２１１は、この新たなクラスターに参加すべきかどうかを考え始めてよい。しかしながら、ノード３０３ではなく別のノードがクラスターリーダーノードの役割を勝ち取った場合には、ノード３０３は、この新しいクラスターリーダーのクラスターに参加するべきかどうかを考える。
【００７３】
本発明によると、クラスターリーダーノードの指定は、重み係数を乗じたＱｏＳメトリックの総和を用いて有益に実行されてよい。特に、図１２を参照すると、本発明のこの方法の態様は、ブロック９０で開始され、上述したように複数のノード２１１をクラスターにグループ分けして、ブロック９２で各クラスターの各ノードに関してＱｏＳノードメトリックを決定する。ここで、各ＱｏＳノードメトリックは、ＱｏＳノードパラメータに対応する。
【００７４】
ＱｏＳノードパラメータは、重要さの順番でランク付けされる（ブロック９３）。このランク付けの１つの例は、表１の縦列の項目“ＣＬＮノード選択”で与えられる。しかしながら、他の適切なランク付けおよび／またはＱｏＳパラメータが他の実施形態において用いられてよい。上述したように、ブロック９４において、ＱｏＳノードパラメータに基づいて、ＱｏＳノードメトリックの各々に重み係数が乗ぜられる。また、重み係数を乗ぜられたＱｏＳノードパラメータの総和を生成してもよい。ブロック９５において、所定のクラスターの各ノードに関する重み係数を乗ぜられたＱｏＳノードメトリック（または重み係数を乗ぜられたＱｏＳノードメトリックの総和）が、お互いに対して比較され、方法が終了する（ブロック９６）。また、ＱｏＳノードメトリックは、上述したものと同じであってよい。クラスターリーダーノードの指定とノード連合・参加の更なる詳細は、米国特許出願第１０／１３４，５５９号に説明されている。
【００７５】
本発明は、様々なタイプのＱｏＳルートの選択からネットワークの自己編成までにわたる様々な適用において用いられる一般化されたノードメトリックとリンクメトリックを表して用いるメカニズムを提供することが、当業者によって理解されるであろう。上述したアプローチは、重み係数を乗ぜられたＱｏＳの総和を用いることに関して説明されたが、総和することに加えて、他の適切な数学的な作用を用いて比較のための適切なデータが提供されてもよいことが理解されるであろう。いくつかの上述の実施形態では、ＱｏＳノードメトリックまたはＱｏＳリンクメトリックだけが、説明されたが、様々な実施形態において、これらのメトリックの一方または両方が用いられてもよいことが理解されるであろう。
【図面の簡単な説明】
【図１】本発明に従ったＱｏＳルートを含む移動アドホックネットワークの概略図である。
【図２】本発明に従ったＱｏＳルートを含む移動アドホックネットワークの概略図である。
【図３】本発明に従ったＱｏＳルートを含む移動アドホックネットワークの概略図である。
【図４】本発明に従ったＱｏＳルートを含む移動アドホックネットワークの概略図である。
【図５】本発明に従った移動アドホックネットワークにおけるＱｏＳルートのための方法の段階を説明するフローチャートである。
【図６】本発明に従ったＱｏＳメトリックの加重平均に基づいてルートを選択する方法の態様を説明するフローチャートである。
【図７】本発明に従ったＱｏＳメトリックの加重平均に基づいて隣接クラスターターゲットノードを選択する本発明の方法の態様を説明するフローチャートである。
【図８】本発明によるアドホックネットワークの概略図である。
【図９】ソースノードと目的地ノードの間の選択されたルートを示す図８のアドホックネットワークの概略図である。
【図１０】本発明に従ったクラスターのグループ分けとクラスターリーダーノード指定を説明する概略図である。
【図１１】本発明に従ったＱｏＳメトリックの加重平均に基づいてノードをそれぞれのクラスターに関連付ける本発明の方法の態様を説明するフローチャートである。
【図１２】本発明に従ったＱｏＳメトリックの加重平均に基づいてクラスターリーダーノードを選択する本発明の方法の態様を説明するフローチャートである。
【符号の説明】
１ ソースノード
２、３、５ 中間ノード
４ 目的地ノード
２０ 移動アドホックネットワーク
３０ 移動ノード
２１４ ソースノード
２１５ 目的地ノード
２１１ ノード
２１２ クラスター
２１３ 無線通信リンク
２２１ クラスターリーダーノード、クラスター
２１７ａ 隣接クラスターターゲットノード

Claims (9)

1. ソースノードと目的地ノードの間に複数の中間ノードを持つ移動アドホックネットワークにおける前記ソースノードと前記目的地ノードの間で通信を行う方法であって：
   複数のＱｏＳ（サービス品質）パラメータに基づいて前記目的地ノードへのルートを発見するために、ＱｏＳルートリクエストを前記複数の中間ノードを介して前記ソースノードから前記目的地ノードへ送信する段階；および
   前記ＱｏＳルートリクエストに応答して、前記ソースノードと前記目的地ノードの間の複数の可能性のあるルートを決定し、当該可能性のあるルートの各々に関する前記ＱｏＳパラメータの各々に対応するＱｏＳメトリックを決定する段階を備え、前記ＱｏＳメトリックが少なくとも１つのＱｏＳリンクメトリックと少なくとも１つのＱｏＳノードメトリックとを含み、
   更に、重要さの順番で前記ＱｏＳパラメータをランク付けする段階；
   前記ＱｏＳパラメータの前記ランキングに基づいて前記ＱｏＳメトリックの各々に重み係数を乗じる段階；
   前記重み係数を乗ぜられたＱｏＳメトリックの比較を行い、当該比較に基づいて前記可能性のあるルートから１つのルートを選択する段階；および
   前記選択されたルートを介して前記ソースノードから前記目的地ノードへメッセージデータを送信する段階；
   を備えることを特徴とする方法。
2. 前記重み係数を乗ぜられたＱｏＳメトリックの総和を、前記可能性のあるルートの各々に関して、生成する段階をさらに含み、前記重み係数を乗ぜられたＱｏＳメトリックの比較が、前記重み係数を乗ぜられたＱｏＳメトリックの当該総和を比較することにより行われること特徴とする請求項１に記載の方法。
3. 前記少なくとも１つのＱｏＳリンクメトリックが、利用可能な帯域幅、誤り率、端部から端部への遅延、端部から端部への遅延変動、ホップカウント、期待される経路の耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含み、
   前記少なくとも１つのＱｏＳノードメトリックは、バッテリー寿命、移動性、通信容量および位置のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
4. 前記複数の可能性のあるルートを決定する前記段階は：
   前記ノードが前記ＱｏＳルートリクエストの前記要求ＱｏＳパラメータをサポートできるかどうかを決定し、当該ノードが当該要求されるＱｏＳパラメータをサポートできる場合には、当該ノードが、前記他の中間ノードと前記目的地ノードのうちの１のノードに前記ＱｏＳルートリクエストを転送する段階；および
   トラベル経路を定義するために、サポート可能なＱｏＳパラメータを持つＱｏＳルートリクエストに関してノード資源を一時的にとっておく段階；
   を含むことを特徴とする請求項１に記載の方法。
5. 前記ノードを、前記ソースノードを含むソースクラスターと前記目的地ノードを含む目的地クラスター、前記ソースクラスターと前記目的地クラスターの間にある前記中間ノードを含む少なくとも１つの中間クラスターにグループ分けする段階；および
   アクセスポイントを供給するために、前記少なくとも１つの中間クラスターの隣接クラスターターゲットノードを設立する段階であり、前記可能性のあるルートの各々は、隣接クラスターターゲットノードを含むところの段階；
   を含むことを特徴とする請求項１に記載の方法。
6. 前記隣接クラスターターゲットノードを設立する前記段階は：
   前記ソースノードと前記少なくとも１つの中間クラスターの複数の可能性のあるターゲットノードとの間の複数のターゲットルートを決定し、当該ターゲットルートの各々に関して複数のＱｏＳターゲットパラメータの各々に対応するＱｏＳターゲットメトリックを決定する段階；
   重要さの順番で前記ＱｏＳターゲットパラメータのランク付けを行う段階；
   前記ターゲットパラメータの前記ランク付けに基づいて、前記ＱｏＳターゲットメトリックの各々に重み係数を乗じる段階；および
   重み係数を乗ぜられたＱｏＳターゲットメトリックの比較を行い、当該比較に基づいて、前記隣接クラスターターゲットノードを選択する段階；
   を含むことを特徴とする請求項５に記載の方法。
7. 前記重み係数を乗ぜられたＱｏＳターゲットメトリックの総和を、前記可能性のあるルートの各々に関して、生成する段階をさらに含み、前記重み係数を乗ぜられたＱｏＳターゲットメトリックの前記比較は、前記重み係数を乗ぜられたＱｏＳターゲットメトリックの前記総和の比較によって行われることを特徴とする請求項６に記載の方法。
8. 移動アドホックネットワークであって：
   ソースノード；
   目的地ノード；および
   前記ソースノードと前記目的地ノードの間にある複数の中間ノード；
   を含み、
   前記ソースノードは、
   複数のＱｏＳパラメータに基づいて前記目的地ノードへのルートを発見するために、サービス品質（ＱｏＳ）ルートリクエストを前記複数の中間ノードを介して前記目的地ノードへ送信し、
   前記ＱｏＳルートリクエストの応答として、前記目的地ノードへの複数の可能性のあるルートと、前記可能性のあるルートの各々に関する前記ＱｏＳパラメータの各々に対応するＱｏＳメトリックを受信し、前記ＱｏＳメトリックが少なくとも１つのＱｏＳリンクメトリックと少なくとも１つのＱｏＳノードメトリックとを含み、前記ソースノードは更に、
   重要さの順番で前記ＱｏＳパラメータのランク付けを行い、
   前記ＱｏＳパラメータの前記ランク付けに基づいて、前記ＱｏＳメトリックの各々に重み係数を乗じ、
   前記重み係数を乗ぜられたＱｏＳメトリックの比較を行い、当該比較に基づいて前記可能性のあるルートから１のルートを選択し、
   前記選択されたルートを介して前記目的地ノードへメッセージデータを送信することを特徴とする移動アドホックネットワーク。
9. 前記少なくとも１つのＱｏＳリンクメトリックは、利用可能な帯域幅、誤り率、端部から端部までの遅延、端部から端部までの遅延変動、ホップカウント、期待される経路耐久性、優先度、１方向性／双方向性およびリンク容量のうちの少なくとも１つを含み、
   前記少なくとも１つのＱｏＳノードメトリックは、バッテリー寿命、移動性、通信容量および位置のうちの少なくとも１つを含むことを特徴とする請求項８に記載の移動アドホックネットワーク。

Images