JP2005524363A

JP2005524363A - 移動体アドホック・ネットワークにおけるチャネル割り当て

Info

Publication number: JP2005524363A
Application number: JP2004502651A
Authority: JP
Inventors: ビルハーツ，トム
Original assignee: Harris Corp
Current assignee: Harris Corp
Priority date: 2002-04-29
Filing date: 2003-04-14
Publication date: 2005-08-11
Also published as: EP1502459B1; ATE514303T1; CN1650650A; US7616961B2; AU2003234091A1; EP1502459A1; EP1502459A4; WO2003094546A1; US20040203820A1; CA2484505A1

Abstract

移動体アドホック・ネットワークは、複数の無線移動体ノードと、複数のチャネルで複数のノードを相互に接続する複数の無線通信リンク(図５)とを有する。前記方法は、各ノードが第１のチャネルでリンク性能を監視し、リンク性能が少なくとも１つのサービス品質(QoS)の閾値に基づき、第１のチャネルで監視中のリンク性能がQoSの閾値より下になった場合に、各ノードが１つ以上の他の利用可能なチャネルを検索することを有する。QoSの閾値は、好ましくは利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び優先度のうちの少なくとも１つに基づく。

Description

本発明は、通信ネットワークの分野に関するものであり、特に移動体アドホック・ネットワーク及び関連する方法に関するものである。

近年、無線ネットワークは更なる発達をしてきた。最も急速に発達している分野のうちの１つは、移動体アドホック・ネットワークである。物理的には、移動体アドホック・ネットワークは、共通の無線チャネルを共有する多数の地理的に分散した潜在的な移動体ノードを有する。セルラネットワーク又は衛星ネットワークのような他の種類のネットワークに対して、移動体アドホック・ネットワークの最も独特の特徴は固定インフラを有さないことである。ネットワークは移動体ノードのみで構成され、ノードが相互に伝送すると、ネットワークがその進行中に作られる。ネットワークは特定のノードに依存せず、いくつかのノードがネットワークに加わり、又は他のノードがネットワークから離れると、動的に調整する。

戦場又は地震やハリケーンを受けた自然災害領域のように、固定通信インフラが信頼できない又は利用できない不利な環境において、アドホック・ネットワークは迅速に配置可能であり、制限はあるが十分に必要な通信を提供することができる。軍事が依然としてこのネットワークの発達の背後にある主要な原動力であるが、アドホック・ネットワークは民間又は商用の領域で新たな用途を迅速に見出している。アドホック・ネットワークにより、単にコンピュータ又はPDAの電源を入れることで作られたネットワーク構成以外のものを使用することなく、現場又はクラスルームでデータ交換をすることが可能になる。

無線通信が日々の生活に更に浸透すると、移動体アドホック・ネットワークの新たな用途が出現し続け、通信構成の重要な部分になるであろう。移動体アドホック・ネットワークは設計者に重要な課題をもたらす。固定インフラがないため、ノードはネットワークを移動し、それに加わり、又はそれを離れると、自己編成及び再構成しなければならない。全てのノードは本質的に同一であり、自然の階層又は中央コントローラはネットワークに存在しない。全ての機能はノードに分散されなければならない。ノードはしばしばバッテリーにより電源供給されており、限られた通信及び計算機能を有する。システムの帯域は通常は制限されている。２つのノード間の距離はしばしば無線伝送範囲を超過し、その宛先に到達する前に他のノードにより伝送が中継されなければならない。その結果、ネットワークは複数ホップ・トポロジを有することになり、ノードが移動すると、このトポロジが変化する。

インターネット特別技術調査委員会(IETF:Internet Engineering Task Force)の移動体アドホック・ネットワーク(MANET:Mobile Ad-Hoc Network)ワーキンググループは、マルチキャストを含むルーティングプロトコルの評価と標準化に積極的に取り組んでいる。ノードが移動するとネットワークトポロジが任意に変化するため、情報は陳腐化しやすくなり、時間(あるノードでは情報が期限切れになるが、他のノードでは現行のままであることがある)と空間(ノードは近隣のネットワークトポロジのみを認識し、その遠くのものを認識しないことがある)の双方において、ノードはしばしば異なるネットワーク構成を有することになる。

ルーティングプロトコルは、あまり正確でない情報で頻繁なトポロジの変化に適合する必要がある。この独特の要件のため、このネットワークでのルーティングは他のものと非常に異なる。全体のネットワークについての最新の情報を集めることは、しばしば高コストであり、非現実的である。多くのルーティングプロトコルはリアクティブ(オンデマンド式)のプロトコルである。必要な場合にのみ、ルーティングが必要な宛先までのルーティング情報を収集し、未使用のルートを維持しない。このように、常に全ての宛先への最適なルートを維持するプロアクティブのプロトコルに比較して、ルーティングのオーバーヘッドは非常に減少する。このことはプロトコルが適応性のあるものにするために重要である。Ad Hoc on Demand Distance Vector(AODV)と、Dynamic Source Routing(DSR)と、Temporally Ordered Routing Algorithm(TORA)は、MANETワーキンググループで提示されたオンデマンド式ルーティングプロトコルの代表である。

他の多様なルーティングプロトコルの例には、Perkinsによる米国特許第5,412,654号に開示されたDestination Sequenced Distance-Vector(DSDV)ルーティングと、Haasによる米国特許第6,304,556号に開示されたZone Routing Protocol(ZRP)が含まれる。ZRPは、プロアクティブとリアクティブの双方の手法を使用したハイブリッドプロトコルである。

これらの従来のルーティングプロトコルは、ソースノードから宛先ノードへのルートを選択する際にベストエフォート型の手法を使用する。一般的に、そのようなベストエフォート型の手法ではホップ数が主要な基準になる。換言すると、最小ホップ数を備えたルートが伝送ルートとして選択される。

移動体アドホック・ネットワークでは、サービス品質(QoS)ルーティングが関心を集めている。サービス品質を提供するために、プロトコルはルートを見つける必要があるばかりではなく、ルートを通じてリソースを安全にする必要がある。ネットワークの制限のある共有帯域と、これらの制限のあるリソースを考慮して制御する中央コントローラがないことのため、QoSルートに必要なリソースを管理するためにノードは相互に交渉しなければならない。このことは、頻繁なトポロジの変化により更に複雑になる。このような制約のため、QoSルーティングはベストエフォート型のルーティングより要求が高くなっている。

QoSルーティングの手法のいくつかの例は、Chenxi Zhuによる2001年の“Medium Access Control and Quality-of-Service Routing for Mobile Ad Hoc Networks”という題の刊行物と、Mirhakkak他による2000年の“Dynamic Quality-of-Service for Mobile Ad Hoc Networks”という題の刊行物に示されている。Zhuは、低から中程度にトポロジが変化する小さいネットワークにおいて、QoSルートの保証された帯域を確立することについて説明している。Mirhakkak他は、ネットワークがQoS値の範囲内でサービスを提供する確約をする間に、QoS値の範囲を指定するリソース予約要求に関するものである。

各ノードで、トラヒックを他のノードから転送するために許可制御が実行される。一般的に従来の許可制御プロトコルは、ルートと接続性に関する全ての情報開示を提供する。換言すると、各ノードは全てのルートと接続性のデータを他のノードと共有し、それによりベストエフォート型のルートが総合的に選択される。

前述の背景を鑑みて、移動体アドホック・ネットワークで動的チャネル割り当てを提供し、効率的に複数のチャネルを利用することが本発明の目的である。

本発明による前記及び他の目的、特徴及び利点は、移動体アドホック・ネットワークにおける動的チャネル割り当ての方法により提供される。ネットワークは、複数の無線移動体ノードと、複数のチャネルで複数のノードを相互に接続する複数の無線通信リンクとを有する。前記方法は、各ノードが第１のチャネルでリンク性能を監視し、リンク性能が少なくとも１つのサービス品質(QoS)の閾値に基づき、第１のチャネルで監視中のリンク性能がQoSの閾値より下になった場合に、各ノードが１つ以上の他の利用可能なチャネルを検索することを有する。

QoSの閾値は、利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び優先度のうちの少なくとも１つに基づくことが好ましい。また、検索は、第２のチャネルに切り替え、第２のチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストし、第２のチャネルのリンク性能を決定するためにチャネル活動のクエリに対する応答を処理することを有してもよい。更に、第２のチャネルのリンク性能がQoSの閾値より上である場合には、各ノード30は第１のチャネルに切り戻し、チャネル変化のメッセージをブロードキャストしてもよい。又は、以前のチャネルのリンク性能がQoSの閾値より下である場合には、次のチャネルに切り替え、そのチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストしてもよい。

代替として、検索は、その他のチャネルに切り替え、第２のチャネルのリンク性能を受動的に監視することを有してもよい。ここで、第２のチャネルのリンク性能がQoSの閾値より上である場合には、各ノードは第１のチャネルに切り戻し、チャネル変化のメッセージをブロードキャストしてもよい。又は、以前のチャネルのリンク性能がQoSの閾値より下である場合には、次のチャネルに切り替え、そのチャネルのリンク性能を受動的に監視してもよい。

また、各ノードは、複数のチャネルのそれぞれのリンク性能情報、及び／又は近隣ノードのチャネル情報を格納してもよい。また、検索は、リンク性能について他のチャネルを定期的に監視することを有してもよい。

本発明のシステム形態は、複数の移動体ノードと、複数のチャネルで複数の移動体ノードを相互に接続する複数の無線通信リンクとを有する移動体アドホック・ネットワークを対象とする。各移動体ノードは、無線通信リンクを介して複数のノードのうちの他のノードと無線で一方向又は双方向に通信する通信装置と、通信装置を介して通信をルーティングするコントローラとを有する。コントローラは第１のチャネルのリンク性能を監視するリンク性能モニタを有し、リンク性能は少なくとも１つのサービス品質(QoS)の閾値に基づき、第１のチャネルで監視中のリンク性能がQoSの閾値より下になった場合に、１つ以上の利用可能なチャネルを検索するチャネル検索ユニットを有する。

本発明は、本発明の好ましい実施例が示されている添付図面を参照して以下に更に詳細に説明される。しかし、本発明は多数の異なる形式で具体化されることがあり、ここに示される実施例に限定して解釈されるべきではない。これらの実施例は、この開示が十分且つ完全であり、当業者に本発明の範囲を完全に伝えるために提供されている。同様の数字は同様の要素を示し、代替の実施例で同様の要素を示すためにプライム表記法が使用されている。

当業者にわかるように、本発明の部分は、方法、データ処理システム、又はコンピュータプログラム製品として具体化されてもよい。従って、本発明のこれらの部分は、完全なハードウェアの実施形態、完全なソフトウェアの実施形態、又はソフトウェアとハードウェアの形態を組み合わせた実施形態の形式をとってもよい。更に、本発明の部分は、媒体上にコンピュータ読取可能コードを有するコンピュータ使用可能記憶媒体のコンピュータプログラム製品でもよい。静的及び動的記憶装置と、ハードディスクと、光記憶装置と、磁気記憶装置に限定されるわけではなく、これらを含む如何なる適切なコンピュータ読取可能媒体も利用され得る。

本発明は、本発明の実施例による方法とシステムとコンピュータプログラム製品のフローチャートの例示を参照して以下に説明される。当然のことながら、図示のブロック及び図示のブロックの組み合わせは、コンピュータプログラム命令により実装され得る。そのコンピュータプログラム命令は、多目的コンピュータ、特殊目的コンピュータ又はその他のプログラム可能データ処理装置のプロセッサに提供され、コンピュータ又はその他のプログラム可能データ処理装置のプロセッサを介して実行する命令がブロックに指定された機能を実装するように機械を形成する。

これらのコンピュータプログラム命令はまた、コンピュータ又はその他のプログラム可能データ処理装置を特定の方法で機能させ得るコンピュータ読取可能メモリに格納されてもよく、それによりコンピュータ読取可能メモリに格納された命令が、フローチャートのブロックに指定された機能を実装する命令を含む生成物を生じる。コンピュータプログラム命令はまた、一連の動作ステップをコンピュータ又はその他のプログラム可能装置で実行させてコンピュータに実装された処理を行わせるように、コンピュータ又はその他のプログラム可能データ処理装置にロードされてもよく、それによりコンピュータ又はその他のプログラム可能装置で実行する命令が、フローチャートのブロックに指定された機能を実装するステップを提供する。

最初に図１−５を参照して、移動体アドホック・ネットワーク20でソースノードから宛先ノードへのルートを決定する方法について説明する。ネットワーク20は、ソースノード1と、宛先ノード4と、その間の中間ノード2、3、5とを含む複数の移動体ノード30を有する。ラップトップコンピュータ、個人情報端末(PDA)又は携帯電話のようなノード30は、当業者にわかるように、無線通信リンク32により接続されている。前記方法はブロック100で開始し、図５のブロック102に示されるように、QoSパラメータに基づいて宛先ノード4へのルーティングを発見するために、ソースノード1からサービス品質(QoS)ルート要求RREQQを送信することを有する。QoSパラメータは、更に詳細に以下に説明されるように、利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び／又は優先度に基づくことが好ましい。ルート要求RREQQは、QoSフロー識別子と、更新可能QoSリンク測定量とを有する。

更に、ブロック104において、前記方法は、各中間ノード2、3、5がQoSルート要求RREQQの所要のQoSパラメータに対応可能か否かを決定することを有する。ノードが特定の要求RREQQのQoSパラメータに対応できない場合、要求は拒否され、又はノードにより単に転送が行われない(ブロック106)。ノード(例えばノード3)が特定の要求RREQQのQoSパラメータに対応可能である場合、ノードはQoSリンク測定量を更新し、QoSルート要求を他の中間ノード2、5に転送し、そのQoSルート要求に対してノードのリソースを一時的に予約する(ブロック108)。中間ノード2、5はまた、ノード3から転送されたQoSルート要求RREQQの所要のQoSパラメータに対応可能であるか否かを決定しなければならない。そうである場合、更新されたQoSリンク測定量を備えてルート要求RREQQが宛先ノード4に転送される。

宛先ノード4は、QoSルート要求RREQQを受信すると、各発見ルートのフロー識別子と更新されたQoSリンク測定量を含むソースノード1への応答RREPQを生成する(ブロック110)。換言すると、宛先ノード4は、例えば1-2-4又は1-3-5-4を含む多様な可能なルートのうちのいずれかから転送されたルート要求RREQQを受信することがある。それぞれの場合について応答RREPQが生成される。ブロック112において、ソースノード1は、発見ルートにおける宛先ノード4からの応答RREPQの更新されたQoSリンク測定量に基づいて、QoSルート測定量を生成する。また、ブロック114において、ソースノード1は、QoSルート測定量に基づいて宛先ノード4へのルートを選択する。次にブロック116において、ソースノードは選択されたルートの中間ノードにルート確認CONFQを送信する。これは、ブロック108で一時的に予約されている選択されたルートでのリソースの使用を確認するためのものである。発見されたが選択されていないルートで一時的に予約されたその他のリソースは、そのルートにCONFQを送信しないことにより、タイムアウトになり得る。

また、ソースノード1は、スタンバイ・ルートの中間ノードに確認CONFQを送信することで、又は送信しないことで、少なくとも１つのスタンバイ・ルートを選択してもよい(ブロック122)。そのようなスタンバイ・ルートは、二重伝送のため、更なる信頼性のため、又はルート及び／若しくはQoS障害の場合のバックアップルートとして使用されることがある。ブロック118において、中間ノード2、3、5及び／又は宛先ノード4は、ノードがQoSルート要求RREQQの所要のQoSパラメータに対応し続けることが可能か否かを常に検出してもよい。トラヒックの伝搬を通じてノードが要求RREQQに対応し続けることが可能である場合に、ブロック126で動作中でないことが判断されると(データトラヒック又は定期的なCONFQメッセージの送信により一定期間使用されていない場合)、予約されたリソース及び関連するルートがタイムアウトになり、ブロック128で解放されることがある。

ノードが要求RREQQに対応し続けることができない場合には、ノードはソースノード1へのQoSエラー通知RERRQを生成する(ブロック120)。ここで、ソースノード1は、QoSエラー通知RERRQを受信すると、選択されたルートを維持する一方で、QoSパラメータに基づいて宛先ノード4への新たなルーティング経路を発見するために、サービス品質(QoS)ルート要求RREQQを再送信してもよい(ブロック102)。ソースノード1はまた、QoSエラー通知RERRQを受信すると、スタンバイ・ルートに切り替えてもよい(ブロック124)。

記載された方法は、当業者にわかるように、Dynamic Source Routing(DSR)若しくはAd-Hoc On-Demand Distance Vector(AODV)のような如何なる種類のオンデマンド式又はリアクティブのルーティングプロトコル、又はZone Routing Protocol(ZRP)のような如何なるハイブリッドのプロアクティブ／リアクティブのプロトコルにも適用可能である。

次に、QoSのカテゴリとして最小帯域割り当てと最大遅延制限を考慮した更に特別の例について説明する。固定帯域割り当ての場合には、ノード30は特定の量の容量又は帯域を予約することができることを仮定する。この場合も同様に、トラヒックフローのソースノード1は、要求されたフロー毎にQoSルート要求RREQQを送信する(記号の最後のQはQoS要求を示す)。RREQQメッセージは、所要のQoSに対応可能なルートを発見する役割を果たす。RREQQを宛先4に転送するノードは、RREQQを次に送信する前に所要のQoSを満たすか否かを示し、必要に応じて一時的にリソースを予約する。所要のQoSがそのパスで満たされ得るという指示を備えて、ルート応答RREPQパケットが宛先から返信される。ソースノード1は、所要のQoSを提供する最善の選択を決定する前に、宛先4への複数の潜在的なパスを収集することがある。このパスが決定されると、指示されたパスを通じて確認CONFQメッセージが宛先4に送信される。このパスの途中で、何らかの一時リソース予約が永続する予約として確認される。指定の期間に使用されない場合には、QoS予約はタイムアウトになる。ルート上のリンクが故障した場合、又はQoS要件が満たされない場合には、ルートエラー(RERRQ)パケットが生成され、ソースノードに返信される。

特に、所定の宛先ノード4への新たなQoSルートが必要になる場合、ソースノード1は宛先ノードにRREQQパケットをブロードキャストする。これは、DSR又はAODVのようなプロトコルで使用される従来のRREQパケットに類似した特別の種類のパケットである。従来のRREQブロードキャストは、“ベストエフォート型”サービスに使用される。本発明の方法は、ベストエフォート型サービス用のプロトコルにより確立された従来の手順に依然として従うことがある。

指定の最小容量又は帯域がトラヒックフローに必要な場合、宛先4まで指定の容量でフローを予約するために、特別のRREQQパケットが使用される。この場合には、ソースノード1によりフローIDがRREQQに割り当てられ、そのRREQQはソースノードアドレスと結合して、フローを転送しているネットワーク20の何らかのノードへのフローを一意に特定する。RREQQパケットはまた、予約されるべき容量を示す。

宛先4へのパスの各ノード2、3、5で、最小容量又は帯域の要件が利用可能な容量に対して検査され、そのフローに対して予約が行うことができるか否かを決定する。ノードが所要のトラヒックフローに対応可能である場合、そのフローIDに対して容量が一時的に予約される。短期間の間にCONFQメッセージが受信されなければ、この一時的な予約は解放される。指定の最大遅延を超えないパスが検出され得ることをRREQQが保障することになっている場合、パス上の各ノードは、全体のパスの遅延への貢献度を評価することができ、これまでのパス上の全体の遅延とその貢献度を加えたものが指定の最大遅延の範囲を超えるか否かを確認しなければならない。

“ベストエフォート型”トラヒック用のDSRとAODVの従来の用途と異なり、QoS要件を満たす有効なパスが存在するか否かを決定するために、RREQQは宛先ノード4まで伝搬可能でなければならない。そのようなパスが見つかると、宛先ノード4はソースノード1に返信するRREPQメッセージを生成する。このメッセージは、所要のQoSを満たす宛先ノード4への有効なパスが見つかり、ルートが確立されたことをソースノードに示す(DSRの場合にはソースルートが返信される)。遅延の保証を求める要求について、及びパス保証容量について、RREPQに推定パス遅延が含まれる。

ソースノード1は、所要のQoSを満たし得る宛先ノード4へのパスについて複数のRREPQを受信することがある。ソースノード1は、これらを順序付けし、最高順位のパスに対してパスの選択を示すCONFQメッセージを送出する。その他のパスはバックアップパスとして保持されることがあるが、CONFQがこれらのパスに送信されない場合には、バックアップの代替のパスとして必要な時に所要のリソースが利用可能であるという保証はない。

中間ノード2、3、5又は宛先ノード4において、所要のQoSに違反しており満たされていない場合には、このノードを通過するパスが所要のQoSを満たすことができないと認識して、RREQQパケットが破棄される。しかし、発見処理により他のパスが見つけられることがある。如何なる時でもルート上のリンクが故障した場合、又はQoS要件が満たされない場合には、故障により影響を受けた各トラヒックフローに対してルートエラーRERRQパケットが生成され、ソースノード1に返信される。この場合には、バックアップパスが使用され、又はルート発見処理が再起動されなければならない。

記載された手順は、容易にDSRプロトコルに適用される。従来のDSRメッセージ形式RREQ、RREP、RRERは、任意選択のパケット形式として定められており、逆方向の互換モードで“ベストエフォート型”トラヒックに対応するプロトコルの従来の動作用に定められたものとして使用可能である。新たな任意選択のパケット形式は、QoSパスを管理するために使用されるRREQQとRREPQとRRERQとCONFQパケット形式を含み、QoSに対応するように定められる。前述の機能に基づいて、これらの形式の所要のヘッダ・フィールドの定義は簡単である。QoSミッションデータ用の特別の形式のQoSソースルート・パケットも含まれる。このパケットは、パケットがどのフローに属するものであるかを特定し、フロートラヒックの測定を可能にするために、フローIDを含む。

以下の手順は、故障によりノードがRERRQパケットを発出する場合に使用される。RERRQパケットがソースノードで受信されると、現在のルートが破棄され、バックアップルートが試される。バックアップルートで送信される最初のパケットは、他の種類の特別のQoSソースルート・パケットRREQTであり、そのRREQTはフローIDとQoSパラメータを有する。このパケットはまた、ミッションデータを有することがある。パス上の各ノードは、依然としてフローの一時的な予約を維持し続けているか否かを確認する必要がある。そうでない場合には、フローに対応可能であるか否かを再確認し、一時的な予約を行う。各中間ノードで対応するフローでパケットが宛先に到達すると、宛先ノードはRREPQパケットを返信し、パスが有効であることをソースに通知する。

ノードがフローに対応できない場合、パケットは破棄され、ノードはRERRQパケットをソースノードに返信し、パスが所要のQoSパラメータに対応できないことを通知する。ソースノードがRREPQパケットを受信すると、選択されたパスを通じてCONFQメッセージを送信し、パスの選択を確認すると共にそのトラヒックフローでミッションデータを送信し続ける。

ソースノードがRERRQパケットを受信すると、次の利用可能なバックアップパスで同じ手順を試みる。ソースノードが宛先へのバックアップ用ソースルートを有さない場合、ソースノードは宛先ノードへの新たなQoSパスのために、その他のルート発見処理を開始する。新たなルートが見つかるまでミッションデータのフローは中断される。何らかの特有のプロトコルの場合、各トラヒックフローに割り当てられるリソースを管理するために必要なデータ構成が定められ、フローを特定する方法及び各フローに割り当てられたルートを検査する方法もまた定められ得る。

次に図６と７を更に参照して、本発明のシステム形態が説明される。移動体アドホック・ネットワーク20は、複数の移動体ノード30と、複数の移動体ノードを相互に接続する複数の無線通信リンク32とを有する。各移動体ノードは、無線通信リンク32を介して他のノードと無線で一方向又は双方向に通信する通信装置42と、通信装置42を介して通信をルーティングするコントローラ44とを有するルータ40(図６)を有する。また、コントローラ44の一部として又はコントローラに結合して、メモリ46が含まれることがある。

図７に示されるように、コントローラ44は、サービス品質(QoS)ルート要求を他のノードに送信し、少なくとも１つのQoSパラメータに基づいて宛先ノードへのルーティングを発見するルート発見ユニット50を有する。この場合も同様に、ルート要求は、フロー識別子とQoSリンク測定量とを有する。また、ルート要求処理ユニット52は、ノードがQoSルート要求の所要のQoSパラメータに対応可能であるか否かを決定し、QoSリンク測定量を更新する。また、一時リソース予約テーブル54は、対応可能なQoSパラメータを有するQoSルート要求のための一時的なノードのリソース予約を含む。更に、ルート測定量形成ユニット56は、ノードのリソース予約を有するノードからの応答の更新されたQoSリンク測定量に基づいてQoSルート測定量を生成する。また、ルート選択ユニット58は、QoSルート測定量に基づいて宛先ノードへのルートを選択し、選択されたルートのノードにルート確認を送信する。

ルート選択ユニット58は、スタンバイ・ルートのノードに確認CONFQを送信することで、又は送信しないことで、バックアップ又は二重伝送用のようなスタンバイ・ルートを選択してもよい。ルート要求処理ユニット52は、ノードがQoSルート要求の所要のQoSパラメータに対応し続けることができるか否かを検出し、そうでない場合には、QoSエラー通知RERRQを生成する。ルート選択ユニット58は、その他のノードからのQoSエラー通知を受信した際に、選択されたルートを維持する一方で、ルート発見ユニット50はその他のサービス品質(QoS)ルート要求RREQQを送信し、QoSパラメータに基づいて宛先ノードへの新たなルーティングを発見することが好ましい。ルート選択ユニット58は、その他のノードからのQoSエラー通知RERRQを受信するとスタンバイに切り替えることがある。

本発明のその他の実施例は、移動体アドホック・ネットワーク22において、必要なサービス品質を維持しつつ、複数ホップのルートに対するトラヒック許可制御を提供する。このことが図８−１１を参照して説明される。そのような許可制御方法により、ノードがそれ自体のトラヒック用のある程度のリソースを保持する一方で、他のトラヒックを転送する場合に適正に共有することが適応的に可能になる。この場合も同様に、アドホック・ネットワークは、複数の無線移動体ノード30と、複数のノードを相互に接続する複数の無線通信リンク32とで構成される。

移動体アドホック・ネットワーク22でトラヒック許可を制御する方法はブロック200で開始し、ソースノードがサービス品質(QoS)ルート要求RREQQを送信し、QoSパラメータに基づいてトラヒックのルーティングを発見することを有する(ブロック202)。ブロック208において、ネットワーク22の各ノード30は、ノードのQoSタグ値を計算し、トラヒック許可制御の決定を行う。ノードのQoSタグ値は、少なくとも１つのノード特有のQoS測定量の関数である。QoSパラメータは、例えば、帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び／又は優先度に基づいてもよく、ノード特有のQoS測定量は、例えば、利用可能な電力、ノードによる利用可能な帯域、最近の誤り率、最近の遅延、範囲内の他のノードによる利用可能な帯域、及びノードのキューの大きさのうちの１つ以上を有してもよい。QoSタグ値は、各項目の合計又は要素としての各項目を備えたベクトルで重み付けされてもよい。

各ノード30は、計算されたQoSタグ値とQoSルート要求RREQQのQoSパラメータに基づいて許可を決定し、QoSルート要求に応じてトラヒックが許可されたか否かに関してソースノードに応答してもよい(ブロック214)。更に、各ノード30は、ノードに関連するルート及び接続性の情報を計算し(ブロック210)、トラヒックのルート選択のためにルート及び接続性の情報とQoSタグ値を他のノードに送信してもよい(ブロック212)。

ノードのQoSタグ値を計算すること208は、少なくとも１つのQoS測定量に関する情報について範囲内の他のノードにクエリ送出し(ブロック204)、他のノードから受信したQoS測定量の情報と少なくとも１つのノード特有のQoS測定量を処理して、ノードのQoSタグ値を計算することを有してもよい。ノードのQoSタグ値を計算することは、範囲内のその他の各ノードがQoS測定量の情報を有して応答したことを確認することを更に有してもよい(ブロック206)。

特に、利用可能な電力、ノードによる利用可能な帯域、最近の誤り率、最近の遅延、及びノードのキューの大きさのような、QoS測定量項目のほとんどは、ローカルでノードに既知のものである。しかし、例えば範囲内の他のノードによる利用可能な帯域は、ローカルではわからない。従って、図８を参照して、ノード1が11Mbpsの伝送媒体のうちの5Mbpsという要求をノード4に出すと、ノード4は、範囲内のその他のノード(ここではノード1、3、5)が禁止的な確約を既に行っているか否かを検査しなければならない。従って、ノード4はCHECKメッセージをブロードキャストし、確約した帯域を有する範囲内の何らかのノードは、そのようなことを示すCHECK REPLYメッセージを返信する。ノード4は、最近受信を行った全てのノードからCHECK REPLYを受信したことを確認する。受信情報により、ノード4は、ルート要求RREQQのQoSパラメータに対応可能であるか否かの決定を行うことができる。

QoSルート要求に応答すること(ブロック214)は、ノードがルート要求のQoSパラメータに対応できない時に、ノードのQoSタグ値に基づいてどのトラヒックのルーティングにノードが対応可能であるかを示すことを有してもよい。例えば、ノード4は要求を確約することができない場合、対応可能な最善のものを記載した応答を発出してもよい。従って、ソースは、レベルが十分であるか否か、又は要求を小さくするべきか否かを決定し、緩和したQoS要求RREQQを発出することができる。

前述の通り、従来の手法は、ルートと接続性に関する全ての情報開示を提供する。換言すると、各ノード30は、相互に認識している全てを共有し、それにより全体で“最善”のルート(通常は最小ホップ)が選択される。この発明では、ルートと接続性の情報は、必要なサービス品質に基づいて他のノードが使用可能な値でタグ付けされる。更に、情報を共有するノードは、その情報を使用可能なQoSのレベルを決定することができる。この決定は共通の一式のルールに基づいてもよく、又はいくつかのノードは優先されているためノード毎でもよい。例えば、多数のパケットを転送しているが、電源が使い果たされようとしており、それ自体のトラヒックについて故障のある帯域を有することを認識したノードは、最重要(最も優先度の高い)のパケット以外の全てを不許可にするタグにより、そのルートと接続性を特定の他のノードに通知する。

本発明のこの実施例のシステム形態は、複数の移動体ノード30と、複数の移動体ノードを相互に接続する複数の無線通信リンク32とを有する移動体アドホック・ネットワーク22を対象とする。図６と７を参照して前述した通り、各移動体ノードは、無線通信リンクを介して相互に無線で一方向又は双方向に通信する通信装置42と、通信装置を介して通信をルーティングするコントローラ44とを有するルータ40を有する。コントローラ44は、サービス品質(QoS)ルート要求を他のノードに送信し、少なくとも１つのQoSパラメータに基づいて宛先ノードへのルーティングを発見するルート発見ユニット50を有する。ここで、QoSタグ計算ユニット60は、ノードのQoSタグ値を計算し、トラヒック許可制御の決定を行う。トラヒック許可コントローラ62は、計算されたQoSタグ値とQoSルート要求のQoSパラメータに基づいて、QoSルート要求に応じてトラヒックを許可するか否かを決定する。

コントローラ44はまた、ノードに関連するルート及び接続性の情報を計算する接続性計算機64を有し、その情報はトラヒックのルート選択のために他のノードに送信されてもよい。QoSタグ計算ユニット60は、少なくとも１つのQoS測定量に関する情報について範囲内の他のノードにクエリ送出し、他のノードから受信したQoS測定量の情報と少なくとも１つのノード特有のQoS測定量を処理し、ノードのQoSタグ値を計算してもよい。また、QoSタグ計算ユニット60は、範囲内のその他の各ノードがQoS測定量の情報を備えて応答したことを確認してもよい。

更に、ルート要求処理ユニット52は、QoSルート要求に応答し、ノードがルート要求のQoSパラメータに対応可能であるか否かを示し、トラヒックを許可する。また、ルート要求処理ユニット52は、ノードがルート要求のQoSパラメータに対応できない時に、ノードのQoSタグ値に基づいてどのトラヒックのルーティングにノードが対応可能であるかを示してもよい。

本発明のその他の実施例は、移動体アドホック・ネットワーク22における複数ホップのルートのトラヒックポリシーを提供するものであり、図１２を参照して説明される。前述の通り、ネットワーク22は、複数の無線移動体ノード30と、複数のノードを相互に接続する複数の無線通信リンク32とを有する。前記方法はブロック300で開始し、その他の実施例で説明した通り、QoSパラメータに基づいてトラヒックのルーティングを発見するために、ノードがサービス品質(QoS)ルート要求RREQQを送信することを有する(ブロック302)。ここでは、QoSルート要求RREQQは、トラヒックフロー識別子を少なくとも有する。ブロック304において、各ノードはノードのQoSタグ値を計算し、トラヒックの許可制御の決定を行う。また、各ノードは計算されたQoSタグ値とQoSルート要求のQoSパラメータに基づいて、QoSルート要求に応じてトラヒックを許可するか否かを決定する(ブロック306)。また、ブロック308において、各ノードはQoSルート要求に応答し、ノードがルート要求のQoSパラメータに対応可能であるか否かを示し、トラヒックを許可する。しかし、この実施例では、各ノードはトラヒックフロー識別子に基づいて許可されたトラヒックをポリシー処理し、許可されたトラヒックがQoSルート要求RREQQのQoSパラメータを超えないことを確保する(ブロック310)。

この場合も同様に、QoSパラメータは、例えば、利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び／又は優先度に基づいてもよく、ノード特有のQoSタグ値は、例えば、利用可能な電力、ノードによる利用可能な帯域、最近の誤り率、最近の遅延、範囲内の他のノードによる利用可能な帯域、及びノードのキューの大きさのうちの少なくとも１つの関数でもよい。換言すると、要求RREQQが例えば特定の量の帯域の要求を含み、ノードが要求に関連するトラヒックを許可する場合、ノードは、許可されたトラヒックが所要の帯域を超えないことを確保するようにノード自体をポリシー処理する。

前記方法は、QoSルート要求のQoSパラメータを超えるトラヒックの伝搬を各ノードが回避することを有することが好ましい(ブロック312)。このステップは、QoSルート要求のQoSパラメータを超えるトラヒックをバッファリングし、QoSルート要求のQoSパラメータでバッファリングされたトラヒックを伝搬することを有してもよい。代替として、各ノードは、所要のリソースが利用可能になった時にバッファリングされたトラヒックを伝搬してもよく、又はQoSルート要求のQoSパラメータを超えるトラヒックを単に破棄してもよい。更に、その他の実施例で説明した通り、QoSルート要求に応答することは、ノードがルート要求のQoSパラメータに対応できない時に、ノードのQoSタグ値に基づいてどのトラヒックのルーティングにノードが対応可能であるかを示すことを有してもよい。

図７を参照すると、コントローラ44は、トラヒックフロー識別子に基づいて許可されたトラヒックをポリシー処理し、許可されたトラヒックがQoSルート要求のQoSパラメータを超えないことを確保するトラヒックポリシー処理ユニット84を有する。また、トラヒックポリシー処理ユニット84は、過剰のトラヒックを格納する過剰トラヒックバッファ86を有することが好ましい。

特に、トラヒックフローIDは、ルートテーブルとQoSパケット(制御とデータの双方)で使用される。前述の通り、これは許可制御を実行する識別子を提供する。例えば宛先ノードへの特定の容量のパスの予約を取得したソースノードは、フローIDを使用してトラヒックを測定し、トラヒックのポリシー処理を実行することができる。このことは、そのフローIDについて合意した容量より大きいものを許可しないことを確保する。更に、宛先へのパスの各ノードは、割り当てられた容量に対してポリシー処理を実行することができる。当然のことながら、所定のフローの要求に対応するか否かを決定する基準として、利用可能な容量以外の基準も使用可能である。例えば、バッテリー電源の少ないノードは、所定のトラヒックフローに対応したくないことがある。この場合には、RREQQメッセージは無視され、それにより所要のトラヒックフローの転送ノードとしてのノードの使用を不許可にする。

本発明のその他の実施例は、移動体アドホック・ネットワークにおける複数ホップのルート用のトラヒック追跡を提供するものであり、図１３と１４を参照して説明される。図１３に示される通り、この場合も同様にネットワーク24は、複数の無線移動体ノード30と、複数のノードを相互に接続する複数の無線通信リンク32とを有する。前記方法はブロック400(図１４)で開始し、各ノードがネットワーク24のノード30間で通信されるトラヒックを監視することを有する(ブロック402)。各ノード30は、ネットワーク24の多様なノード間で通信されるトラヒックの程度に基づいてトラヒック情報を生成し(ブロック404)、各ノードはトラヒックデータベースとしてローカルでバッファにトラヒック情報を格納する(ブロック406)。

前記方法において、トラヒック情報は帯域に基づくことが好ましく、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び／又は優先度を有してもよい。トラヒックデータベースは1ホップのトラヒック・マトリクスを有してもよい。換言すると、特定のノード1のデータベースは、ネットワークのノード2-8の間のリンク32毎のトラヒック情報を有する。図１３において、ノード1はノード6へのトラヒック・ルートAを必要としている。ここで、ノード7と8が大量のトラヒックを送信しているが、ノード1-6が送信していない場合には、大きいホップ数を結果として生じることになったとしても、1-7-8-6ではなく1-2-3-4-5-6を通じてトラヒックをルーティングする方が好ましい。

前記方法は、ルーティングプロトコルの選択や、プロトコルのパラメータ最適化や、ルート選択にとって有利であることがある。トラヒック・マトリクスは以下に例示されている。７個のノードのネットワークの場合において、マトリクスの各要素は、存在する場合にはどの程度のトラヒックがマトリクスの行のソースノードからマトリクスの列の宛先ノードに送信されているかを示している。ここで、トラヒックは、ある程度の期間での帯域の観点から定量化され(最近使用された帯域はより大きく重み付けられる)、パケット損失率、遅延等を有することがある。トラヒック・マトリクスがまばらに構成されている場合(多数の0の帯域又はほぼ0の帯域の項目がある場合)、ルートは継続的に更新されておらず、使用されていないため、リアクティブのルーティングプロトコルが有利である。逆に、高密度のトラヒック・マトリクスは、ノード30間の多数の相互作用を示しており、プロアクティブ又はハイブリッドのプロトコルが利点を提供することがある。従って、前記方法は、格納されたトラヒック情報に基づいて各ノードがリアクティブ、プロアクティブ又はハイブリッドのプロトコルのようなルート発見プロトコルを選択することを有してもよい(ブロック412)。

ノードは何のトラヒックを送信、受信及び転送しているかを認識している。ノードが直接に関与していないトラヒックを認識するために、ノードはトラヒックデータを含むメッセージを監視し、又は明示的に送信され得る。(他のノードの要求RREQと応答RREPを受信することにより、又はデータパケットのソースルートを監視することにより)無差別にルート情報を収集するDSRのようなルーティングプロトコルは、トラヒック・マトリクスのほとんどを構成するように適合され得る。最適化リンクステート型ルーティング(OLSR:optimized link state routing)のようなリンクステート型ルーティングプロトコルは、既にルート情報を共有しており、各ノードが何をどこに対してどの品質で送信しているかを認識しているため、トラヒック・マトリクス情報を共有するように拡張可能である。また、プロトコルは、トラヒック輻輳によりどの程度の遅延が予期されるかを認識しているため、トラヒック・マトリクスの帯域に基づいて、ホップ列を通じた期待遅延に従ってタイマを設定可能である。このことにより、不要なタイムアウトが発生することを減少又は除去することがある。

更に、ブロック408において、多様なノードのそれぞれがネットワーク24で通信している宛先の数に基づいて、各ノード30はトラヒック宛先情報を生成し、宛先量データベースにトラヒック宛先情報を格納してもよい(ブロック410)。このように、各ノード30はまた、格納されたトラヒック宛先情報に基づいてトラヒック・ルートを発見及び選択してもよい。換言すると、宛先量データベースは、複数のノードのそれぞれが通信している宛先の数を明らかにする。

再び図７を参照すると、この実施例によるネットワーク24のルータ40のコントローラ44は、ネットワークのノード30間で通信されるトラヒックを監視するトラヒック監視ユニット70を有する。トラヒック情報生成器76は、ネットワークの多様なノード間で通信されるトラヒックの程度に基づいてトラヒック情報を生成し、トラヒック情報バッファ78は、トラヒックデータベースにトラヒック情報を格納する。

トラヒック監視ユニット70は、トラヒック活動のクエリをブロードキャストし、トラヒック活動のクエリに対する応答を処理してもよい。代替として、トラヒック監視ユニット70は、ネットワーク24のノード30間のトラヒックを受動的に監視してもよい。ルート発見ユニット50は、格納されたトラヒック情報に基づいて宛先ノードへのルーティングを発見し、ルート選択ユニット58は、格納されたトラヒック情報に基づいて宛先ノードへのトラヒック・ルートを選択する。また、ルート発見ユニット50は、トラヒックデータベースに格納されたトラヒック情報を処理し、リアクティブとプロアクティブとハイブリッドのルート発見処理のうちの１つを選択し、選択されたルート発見処理でトラヒック・ルートを発見してもよい。各トラヒック・ルートは、無線通信リンク32の組み合わせを有する。

トラヒック宛先情報生成器72は、多様なノード30のうちのそれぞれがネットワーク24で通信している宛先の数に基づいてトラヒック宛先情報を生成し、宛先情報バッファ74は、宛先量データベースにトラヒック宛先情報を格納する。ルート発見ユニット50はまた、格納されたトラヒック宛先情報に基づいて宛先ノードへのルーティングを発見してもよく、ルート選択ユニット58は、格納されたトラヒック宛先情報に基づいて宛先ノードへのトラヒック・ルートを選択してもよい。

本発明のその他の実施例は、複数のチャネルを効果的に利用するために、移動体アドホック・ネットワークで動的チャネル割り当てを提供する。動的チャネル割り当ての方法は、図１５−１８を参照して説明される。ここで、ネットワーク26は、複数の無線移動体ノード30と、複数のチャネルで複数のノードを相互に接続する複数の無線通信リンク32とを有する。IEEE802.11aのようなIEEE802.11の派生は、5GHz帯でISMスペクトルを利用する。この帯域では、多数のチャネルに対応する多くの利用可能な帯域が存在する。その結果として、自動的にチャネルを802.11ノードに割り当てる処理が重要になる。そのようなチャネル決定は、現在のチャネル利用とその他のチャネルのサンプリングに基づく。動的チャネル選択を使用することは、スペクトルが均等に使用されるため、より良い性能を提供する。更に、チャネルを使用している現在の局でQoSが維持されるように、チャネルの使用が抑制される。

前記方法はブロック500(図18)で開始し、各ノードが第１のチャネルでリンク性能を監視することを有する。リンク性能は、例えば、帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び優先度のような、サービス品質(QoS)の閾値に基づく。ブロック504において、第１のチャネルの監視中のリンク性能がQoSの閾値(例えば最小帯域又は最大遅延)より下になると、各ノードは１つ以上の他の利用可能なチャネルを検索する。検索は、リンク性能について他のチャネルを定期的に監視することを有してもよい。

検索は、第２のチャネルに切り替え(ブロック512)、第２のチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストし(ブロック516)、ブロック518で第２のチャネルのリンク性能を決定するためにチャネル活動のクエリに対する応答を処理することを有してもよい。更に、第２のチャネルのリンク性能がQoSの閾値より上である場合には、各ノード30は第１のチャネルに切り戻し、チャネル変化のメッセージをブロードキャストしてもよい(ブロック506)。又は、以前のチャネルのリンク性能がQoSの閾値より下である場合には、次のチャネルに切り替え、そのチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストしてもよい(ブロック504)。

代替として、検索は、その他のチャネルに切り替え(ブロック512)、ブロック514で第２のチャネルのリンク性能を受動的に監視することを有してもよい。この場合も同様に、第２のチャネルのリンク性能がQoSの閾値より上である場合には、各ノード30は第１のチャネルに切り戻し、チャネル変化のメッセージをブロードキャストしてもよい(ブロック506)。又は、以前のチャネルのリンク性能がQoSの閾値より下である場合には、次のチャネルに切り替え、そのチャネルのリンク性能を受動的に監視してもよい(ブロック504)。また、各ノード30は、複数のチャネルのそれぞれのリンク性能情報を格納し(ブロック508)、及び／又はブロック510で近隣ノードのチャネル情報を格納してもよい。換言すると、各ノード30は、他のノードがどのチャネルを使用しているかを追跡してもよい。

例えば図１５−１７に示される通り、ネットワーク26はノード30とリンク32とを有する。ノード1A-5Aは第１のチャネルを現在使用しており、ノード1B-5Bは第２のチャネルを現在使用している。ノード2Bは、第２のチャネルのリンク性能が最小帯域のようなQoSの閾値より下になりつつあること又は下になったことを決定する。ノード2Bは、第１のチャネルに切り替えて、ノード2Bの１ホップ内のノードにチャネル活動のクエリCAQをブロードキャストする(図１６)。ノード1Aと2Aと3Aは、第１のチャネルのリンク性能の情報と共にチャネル活動の応答CARをノード2Bに送信する（図１７）。第１のチャネルの帯域がノード2Bに受け入れられる場合には、第２のチャネルに戻り、第１のチャネルに変化しようとしていることを何らかのノード1Bと3Bと4Bと5Bに通知するためにチャネル変化のメッセージをブロードキャストする。その結果、これらのノードは将来の参照の際にノード2Bがどこで検出可能であるかを認識する。帯域が受け入れられない場合には、ノード2Bは第３のチャネルに移動し、前記のステップを繰り返す。全てのチャネルにアクセスし、ノード2BがQoSの閾値より上の帯域を検出しなかった場合には、最善のものを選択し、より良いチャネルを定期的に検索することがある。

本発明のこの実施例のシステム形態は、複数の移動体ノード30と、複数のチャネルで複数の移動体ノードを相互に接続する複数の無線通信リンク32とを有する移動体アドホック・ネットワーク26を対象とする。図６と７を参照すると、各移動体ノードは、無線通信リンク32を介して他のノードと無線で一方向又は双方向に通信する通信装置42と、通信装置を介して通信をルーティングするコントローラ40とを有するルータ40を有する。コントローラ40は、第１のチャネルのリンク性能を監視するリンク性能モニタ80を有する。第１のチャネルの監視中のリンク性能がQoSの閾値より下になった場合に、チャネル検索ユニット82は１つ以上の利用可能なチャネルを検索する。

チャネル検索ユニット82は、第２のチャネルに切り替え、第２のチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストし、第２のチャネルのリンク性能を決定するためにチャネル活動のクエリに対する応答を処理する。また、第２のチャネルのリンク性能がQoSの閾値より上である場合に、チャネル検索ユニット82は第１のチャネルに切り戻し、チャネル変化のメッセージをブロードキャストする。又は以前のチャネルのリンク性能がQoSの閾値より下である場合には、次のチャネルに切り替え、そのチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストする。代替として、チャネル検索ユニット82は、その他のチャネルに切り替え、第２のチャネルのリンク性能を受動的に監視してもよい。リンク性能情報メモリ66は、複数のチャネルのそれぞれのリンク性能情報を格納し、チャネル情報メモリ68は、近隣ノードのチャネル情報を格納する。

本発明によるQoSルーティングを有する移動体アドホック・ネットワークの概念図である。本発明によるQoSルーティングを有する移動体アドホック・ネットワークの概念図である。本発明によるQoSルーティングを有する移動体アドホック・ネットワークの概念図である。本発明によるQoSルーティングを有する移動体アドホック・ネットワークの概念図である。本発明による移動体アドホック・ネットワークでのQoSルーティングの方法のステップを示したフローチャートである。本発明のネットワークによるノードのルータを示した概念図である。図６のルータのコントローラの詳細を示した概念図である。本発明による許可制御を含む移動体アドホック・ネットワークの概念図である。本発明による許可制御を含む移動体アドホック・ネットワークの概念図である。本発明による許可制御を含む移動体アドホック・ネットワークの概念図である。本発明による移動体アドホック・ネットワークでの許可制御の方法のステップを示したフローチャートである。本発明による移動体アドホック・ネットワークでのトラヒック許可制御をポリシー処理する方法のステップを示したフローチャートである。本発明によるトラヒック追跡を有する移動体アドホック・ネットワークの概念図である。本発明による移動体アドホック・ネットワークでのトラヒックを追跡する方法のステップを示したフローチャートである。本発明による動的チャネル割り当てを有する移動体アドホック・ネットワークの概念図である。本発明による動的チャネル割り当てを有する移動体アドホック・ネットワークの概念図である。本発明による動的チャネル割り当てを有する移動体アドホック・ネットワークの概念図である。本発明による移動体アドホック・ネットワークでの動的チャネル割り当ての方法のステップを示したフローチャートである。

Claims

複数の無線移動体ノードと、複数のチャネルで前記複数のノードを相互に接続する複数の無線通信リンクとを有する移動体アドホック・ネットワークにおける動的チャネル割り当ての方法であって、
各ノードで、第１のチャネルでリンク性能を監視し、リンク性能が少なくとも１つのサービス品質(QoS)の閾値に基づき、
前記第１のチャネルで監視中のリンク性能が前記QoSの閾値より下になった場合に、各ノードで１つ以上の他の利用可能なチャネルを検索すること
を有する方法。
請求項１に記載の方法であって、
前記QoSの閾値が、利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び優先度のうちの少なくとも１つに基づく方法。
請求項１に記載の方法であって、
検索が、
第２のチャネルに切り替え、
前記第２のチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストすること
を有する方法。
請求項１に記載の方法であって、
各ノードで、前記複数のチャネルのそれぞれのリンク性能情報を格納することを更に有する方法。
請求項１に記載の方法であって、
各ノードで、近隣ノードのチャネル情報を格納することを更に有する方法。
複数の移動体ノードと、
複数のチャネルで前記複数の移動体ノードを相互に接続する複数の無線通信リンクと
を有する移動体アドホック・ネットワークであって、
各移動体ノードが、
前記無線通信リンクを介して前記複数のノードのうちの他のノードと無線で一方向又は双方向に通信する通信装置と、
前記通信装置を介して通信をルーティングし、
第１のチャネルのリンク性能を監視し、リンク性能が少なくとも１つのサービス品質(QoS)の閾値に基づくリンク性能モニタと、
前記第１のチャネルで監視中のリンク性能がQoSの閾値より下になった場合に、１つ以上の利用可能なチャネルを検索するチャネル検索ユニットと
を有するコントローラと
を有する移動体アドホック・ネットワーク。
請求項６に記載のネットワークであって、
前記QoSの閾値が、利用可能な帯域、誤り率、エンドツーエンドの遅延、エンドツーエンドの遅延の変化、ホップ数、期待パス耐久性、及び優先度のうちの少なくとも１つに基づくネットワーク。
請求項６に記載のネットワークであって、
前記チャネル検索ユニットが、
第２のチャネルに切り替え、
前記第２のチャネルのリンク性能を決定するためにチャネル活動のクエリをブロードキャストするネットワーク。
請求項６に記載のネットワークであって、
前記複数のチャネルのそれぞれのリンク性能情報を格納するリンク性能情報メモリを更に有するネットワーク。
請求項６に記載のネットワークであって、
近隣ノードのチャネル情報を格納するチャネル情報メモリを更に有するネットワーク。