(57)【要約】  移動体アドホックネットワーク（MANET）（20）は、無線通信装置（30）と、それに接続されてマルチレイヤプロトコル階層（32’）に従って動作するコントローラ（31）とをそれぞれ有する複数の移動体ノード（21-28）を有してもよい。特に、コントローラ（31）は、アプリケーションレイヤでサービス品質（QoS）閾値を確立し、アプリケーションレイヤの下のQoSサポートレイヤ（37’）で、QoS閾値に基づいてデータ受信肯定応答を必要とするか否かを決定する。QoSサポートレイヤの下のQoS符号化レイヤ（38’）で、少なくとも１つの宛先移動体ノード（25）に送信するために、アプリケーションレイヤ（36’）からのデータがエンコードされてもよい。更に、QoS符号化レイヤ（38’）の下のQoSルート選択レイヤ（39’）で、QoS閾値に基づいて少なくとも１つの宛先移動体ノードへの少なくとも１つのルートが選択されてもよい。QoSルート選択レイヤ（39’）の下のQoSトラヒックレイヤ（41’）で、QoS閾値に基づいてデータトラヒックフローが制御されてもよい。
2007505566.tif 000002
【特許請求の範囲】
【請求項１】
無線通信装置と、それに接続されたコントローラとをそれぞれ有する複数の移動体ノードを有する移動体アドホックネットワーク（MANET）であって、
前記コントローラは、マルチレイヤプロトコル階層に従って動作し、
アプリケーションレイヤでサービス品質（QoS）閾値を確立し、
前記アプリケーションレイヤの下のQoSサポートレイヤで、前記QoS閾値に基づいてデータ受信肯定応答を必要とするか否かを決定し、
前記QoSサポートレイヤの下のQoS符号化レイヤで、少なくとも１つの宛先移動体ノードに送信するために、前記アプリケーションレイヤからのデータをエンコードし、
前記QoS符号化レイヤの下のQoSルート選択レイヤで、前記QoS閾値に基づいて前記少なくとも１つの宛先移動体ノードへの少なくとも１つのルートを選択し、
前記QoSルート選択レイヤの下のQoSトラヒックレイヤで、前記QoS閾値に基づいてデータトラヒックフローを制御し、
前記QoSトラヒックレイヤの下の少なくとも１つの下位プロトコルレイヤで、前記無線通信装置と協調し、前記少なくとも１つの選択されたルートを介して前記少なくとも１つの宛先移動体ノードにデータを送信する移動体アドホックネットワーク。
【請求項２】
請求項１に記載のMANETであって、
前記QoSルート選択レイヤと前記QoSトラヒックレイヤとの間のQoS転送レイヤで、前記QoS閾値に基づいてユニキャスト通信モードとマルチキャスト通信モードとの間を選択し、
前記少なくとも１つの下位プロトコルレイヤで、前記コントローラは、前記無線通信装置と協調し、前記選択された通信モードに基づいてデータを送信するMANET。
【請求項３】
請求項１に記載のMANETであって、
前記QoSサポートレイヤで、前記コントローラは、他の移動体ノードから受信した各QoSルート要求と内部QoSメトリックとに基づいて、他の移動体ノードからのトラヒックを承認するか否かを決定するMANET。
【請求項４】
請求項１に記載のMANETであって、
前記QoSパケット符号化レイヤで、前記コントローラは、前方誤り訂正（FEC：forward  error  correction）アルゴリズムを使用してデータをエンコードし、前記QoS閾値に基づいて前記データの誤り訂正データを生成し、送信前に前記誤り訂正データ及び前記データをインターリーブするMANET。
【請求項５】
請求項１に記載のMANETであって、
前記QoSルート選択レイヤで、前記コントローラは、出力データを送信するために必要なエネルギー使用レベルと前記QoS閾値とに基づいて、出力データで負荷平準化を実行するMANET。
【請求項６】
マルチレイヤプロトコル階層に従って複数の移動体ノードを有する移動体アドホックネットワーク（MANET）で移動体ノードを動作し、前記移動体ノードは無線通信装置を有する方法であって、
アプリケーションレイヤでサービス品質（QoS）閾値を確立し、
前記アプリケーションレイヤの下のQoSサポートレイヤで、前記QoS閾値に基づいてデータ受信肯定応答を必要とするか否かを決定し、
前記QoSサポートレイヤの下のQoS符号化レイヤで、少なくとも１つの宛先移動体ノードに送信するために、前記アプリケーションレイヤからのデータをエンコードし、
前記QoS符号化レイヤの下のQoSルート選択レイヤで、前記QoS閾値に基づいて前記少なくとも１つの宛先移動体ノードへの少なくとも１つのルートを選択し、
前記QoSルート選択レイヤの下のQoSトラヒックレイヤで、前記QoS閾値に基づいてデータトラヒックフローを制御し、
前記QoSトラヒックレイヤの下の少なくとも１つの下位プロトコルレイヤで、前記無線通信装置に、前記少なくとも１つの選択されたルートを介して前記少なくとも１つの宛先移動体ノードにデータを送信させることを有する方法。
【請求項７】
請求項６に記載の方法であって、
前記QoSルート選択レイヤと前記QoSトラヒックレイヤとの間のQoS転送レイヤで、前記QoS閾値に基づいてユニキャスト通信モードとマルチキャスト通信モードとの間を選択することを更に有し、
前記協調することは、前記無線通信装置と協調し、前記選択された通信モードに基づいてデータを送信することを有する方法。
【請求項８】
請求項６に記載の方法であって、
前記QoSサポートレイヤで、他の移動体ノードから受信した各QoSルート要求と内部QoSメトリックとに基づいて、他の移動体ノードからのトラヒックを承認するか否かを決定することを更に有する方法。
【請求項９】
請求項６に記載の方法であって、
前記QoSパケット符号化レイヤで、前方誤り訂正（FEC：forward  error  correction）アルゴリズムを使用してデータをエンコードし、前記QoS閾値に基づいて前記データの誤り訂正データを生成し、送信前に前記誤り訂正データ及び前記データをインターリーブすることを更に有する方法。
【請求項１０】
請求項６に記載の方法であって、
前記QoSルート選択レイヤで、出力データを送信するために必要なエネルギー使用レベルと前記QoS閾値とに基づいて、出力データで負荷平準化を実行することを更に有する方法。
【発明の詳細な説明】
【背景技術】
【０００１】
無線ネットワークは、過去１０年に更なる発展を経験してきた。最も急速に発展している領域の１つは移動体アドホックネットワーク（MANET：mobile  ad  hoc  network）である。物理的には、MANETは、複数の地理的に分散し、１つ以上の共通の無線チャネルを共有する潜在的な移動体ノードを有する。セルラネットワークや衛星ネットワークのような他の形式のネットワークと比較して、MANETの最も独特な特徴は、固定インフラが存在しないことである。ネットワークは、移動体（場合によっては静止した）ノードで構成され、ノードが他のノードと送受信すると、“進行中に”ネットワークが作られる。ネットワークは一般的には特定のノードに依存せず、あるノードがネットワークに加わり、また、あるノードがネットワークから去ると、ネットワークは動的に調整する。
【０００２】
戦場又は地震やハリケーンを受けた自然災害領域のように、固定通信インフラが信頼できない又は利用できない不利な環境において、MANETは迅速に配置可能であり、十分に必要な通信を提供することができる。軍事が依然としてこのネットワークの発達の背後にある主要な原動力であるが、アドホックネットワークは民間又は商用の領域で新たな用途を迅速に見出している。MANETにより、単にコンピュータ又はPDAの電源を入れることで作られたネットワーク構成以外のものを使用することなく、人又はアプリケーションが現場又はクラスルームでデータ交換をすることが可能になる。
【０００３】
無線通信が日々の生活に更に浸透すると、MANETの新たな用途が出現し続け、無線通信の重要な部分になるであろう。しかし、MANETは設計者に重要な課題をもたらす。固定インフラがないため、ノードはネットワークを移動し、それに加わり、又はそれを離れると、自己編成及び再構成しなければならない。潜在的には全てのノードは機能的に同一であり、自然の階層又は中央コントローラはネットワークに存在しない。全ての機能はノードに分散されなければならない。ノードはしばしばバッテリーにより電源供給されており、限られた通信及び計算機能を有する。システムの帯域は通常は制限されている。２つのノード間の距離はしばしば無線伝送範囲を超過し、その宛先に到達する前に他のノードにより伝送が中継されなければならない。その結果、MANETは一般的にマルチホップ・トポロジを有することになり、ノードが移動すると、このトポロジが変化する。
【０００４】
インターネット特別技術調査委員会（IETF:Internet  Engineering  Task  Force）のMANETワーキンググループは、マルチキャストプロトコルを含むルーティングプロトコルの評価と標準化に積極的に取り組んでいる。ノードが移動するとネットワークトポロジが任意に変化するため、情報は陳腐化しやすくなり、時間（あるノードでは情報が期限切れになるが、他のノードでは現行のままであることがある）と空間（ノードは近隣のネットワークトポロジのみを認識し、その遠くのものを認識しないことがある）の双方において、異なるノードはしばしば異なるネットワークの視野を有することになる。
【０００５】
ルーティングプロトコルは、場合によってはあまり正確でない情報で、頻繁なトポロジの変化に適応する必要がある。この独特の要件のため、このネットワークにおけるルーティングは、その他のものと非常に異なる。全体ネットワークについて新しい情報を収集することは、しばしば高コスト且つ非現実的である。あるルーティングプロトコルはリアクティブ（オンデマンド）型プロトコルである。すなわち、必要な時にのみルーティングする必要のある宛先に対してのみルーティング情報を収集し、未使用のルートを保持しない。このように、ルーティングのオーバーヘッドは、全ての時間での全ての宛先へのルートを維持するプロアクティブ型プロトコルに比較して非常に減少する。Ad  Hoc  on  Demand  Distance  Vector（AODV）と、Dynamic  Source  Routing（DSR）と、Temporally  Ordered  Routing  Algorithm（TORA）は、MANETワーキンググループで提示されているリアクティブ型ルーティングプロトコルの代表である。
【０００６】
プロアクティブ型ルーティングプロトコルの例には、Clausen他による“Optimized  Link  State  Routing  Protocol”という題のInternet  Engineering  Task  Force（IETF）  MANET  Working  Group、Internet  Draft、2001年10月31がある。他の多様なルーティングプロトコルの例には、Perkinsの米国特許第5,412,654号に開示されているDestination-Sequenced  Distance  Vector（DSDV）ルーティングと、Haasの米国特許第6,304,556号に開示されているZone  Routing  Protocol（ZRP）とが含まれる。ZRPは、プロアクティブ型手法とリアクティブ型手法の双方を使用したハイブリッド型プロトコルである。
【０００７】
この従来のルーティングプロトコルは、ソースノードから宛先ノードへのルートを選択する際にベストエフォート型手法を使用する。一般的に、このような手法では、ホップ数を最小化することが主要な基準である。
【０００８】
MANETでサービス品質（QoS）ルーティングが関心を集めている。サービス品質を提供するために、プロトコルはルートを見つける必要があるだけでなく、ルートを通じたリソースを特定及び／又は確保する必要がある。ネットワークの潜在的に限られた共有の帯域のため、また、これらの限られたリソースを把握して制御することができる中央コントローラがないため、ノードは相互にネゴシエーションして、QoSルートに必要なリソースを管理しなければならない。このことは頻繁なトポロジ変化により更に複雑になる。これらの制約のため、QoSルーティングはベストエフォート型又は最小ホップ型ルーティングより要求が厳しい。
【０００９】
QoSルーティング手法のいくつかの例は、Chenxi  Zhuによる2001年の“Medium  Access  Control  and  Quality-of-Service  Routing  for  Mobile  Ad  Hoc  Networks”という題の刊行物と、M.Mirhakkak他による2000年の“Dynamic  Quality-of-Service  for  Mobile  Ad  Hoc  Networks”、MITRE  Corp.という題の刊行物とに示されている。Zhuは、トポロジが小〜中レートで変化する小規模ネットワークで帯域保証のQoSルートを確立することについて議論している。Mirhakkak他は、QoSの値の範囲を指定するリソース予約要求に取り組み、ネットワークがこの範囲内でサービスを提供することを確約する。
【００１０】
MANETは依然として発展の初期段階であるため、MANETにQoS機能を実装するほとんどの試みは、前述の従来技術の手法の場合のように、今まではルートを確立するためにQoSパラメータを使用することに主に集中してきている。しかし、MANETはサイズ及び複雑性が増加し続けるため、異なるネットワークプロトコル階層のレイヤにQoS動作を効率的に分散する方法と共に、更なるQoS機能が必要になる。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従って、前述の背景を鑑みて、QoSプロトコル階層を実装するMANET及び関連する方法を提供することが、本発明の目的である。
【課題を解決するための手段】
【００１２】
本発明による前記及び他の目的、特徴及び利点は、無線通信装置と、それに接続されたコントローラとをそれぞれ有する複数の移動体ノードを有してもよいMANETにより提供される。コントローラは、マルチレイヤプロトコル階層に従って動作してもよい。より具体的には、コントローラは、アプリケーションレイヤでサービス品質（QoS）閾値を確立し、アプリケーションレイヤの下のQoSサポートレイヤで、QoS閾値に基づいてデータ受信肯定応答を必要とするか否かを決定してもよい。QoSサポートレイヤの下のQoS符号化レイヤで、コントローラは、少なくとも１つの宛先移動体ノードに送信するために、アプリケーションレイヤからのデータをエンコードしてもよい。
【００１３】
更に、QoS符号化レイヤの下のQoSルート選択レイヤで、コントローラは、QoS閾値に基づいて少なくとも１つの宛先移動体ノードへの少なくとも１つのルートを選択してもよい。QoSルート選択レイヤの下のQoSトラヒックレイヤで、コントローラは、QoS閾値に基づいてデータトラヒックフローを制御してもよい。更に、QoSトラヒックレイヤの下の少なくとも１つの下位プロトコルレイヤで、コントローラは無線通信装置と協調し、少なくとも１つの選択されたルートを介して少なくとも１つの宛先移動体ノードにデータを送信してもよい。このように、本発明のプロトコル階層は、拡張QoSを提供するために協調のQoS動作を効率的且つ便宜的に構成するQoSフレームワークを提供する。
【００１４】
前述のレイヤに加えて、QoSルート選択レイヤとQoSトラヒックレイヤとの間のQoS転送レイヤで、コントローラは、QoS閾値に基づいてユニキャスト通信モードとマルチキャスト通信モードとの間を選択してもよい。従って、少なくとも１つの下位プロトコルレイヤで、有利には、コントローラは無線通信装置と協調し、選択された通信モードに基づいてデータを送信してもよい。
【００１５】
一例として、少なくとも１つの下位プロトコルは、QoSトラヒックレイヤ用のインタフェースを提供する無線適応レイヤを有してもよい。更に、少なくとも１つの下位プロトコルレイヤはまた、媒体アクセスレイヤと物理レイヤとを有してもよい。
【００１６】
従って、物理レイヤで、コントローラは無線通信装置と協調し、少なくとも１つの選択されたルートのQoSメトリックを決定してもよい。
【００１７】
更に、QoSルート選択レイヤで、コントローラは、QoSメトリックがQoS閾値の下に落ちたか否かを決定してもよい。従って、物理レイヤで、コントローラは無線通信装置と協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、少なくとも１つの信号特性を調整してもよい。一例として、少なくとも１つの信号特性は、出力、利得及び／又は信号パターンを有してもよい。従って、有利には信号特性は、信号接続性を増加させるように又は干渉を減少させるように調整されてもよい。実際に、これらの特性は、受信ノードで干渉を減少させるように調整されるだけでなく、隣接のノードで意図的でない干渉をも減少させるように調整され得る。
【００１８】
更に、QoSサポートレイヤで、コントローラは、他の移動体ノードから受信した各QoSルート要求と内部QoSメトリックとに基づいて、他の移動体ノードからのトラヒックを承認するか否かを決定してもよい。更に、QoSルート要求は、各トラヒックフロー識別子と、それに関連する第２のQoS閾値とを有してもよい。従って、QoSトラヒックレイヤで、有利にはコントローラは、各トラヒックフロー識別子に基づいて承認されたトラヒックを規制し、承認されたトラヒックが各第２のQoS閾値を超えないことを確保してもよい。一例として、内部QoSメトリックは、利用可能出力、利用可能帯域、最近の誤り率及び最近の遅延のうち１つ以上を有してもよい。
【００１９】
QoSパケット符号化レイヤで、コントローラはまた、前方誤り訂正（FEC：forward  error  correction）アルゴリズムを使用してデータをエンコードし、QoS閾値に基づいてデータの誤り訂正データを生成してもよい。更に、少なくとも１つの選択されたルートは複数の選択されたルートを有してもよく、コントローラは、誤り訂正データ及びデータをインターリーブし、インターリーブされたデータを複数の選択されたルートを通じて配信してもよい。従って、FECを実行してインターリーブされたデータを複数のルートを通じて配信することにより、ルートの１つが動作不可能であるとしても、MANETは破損したデータパケットが訂正されることを可能にし、必要に応じて新しいルートが確立されている間に送信が継続することを可能にする。更に、FECエンコードに関連する更なる量のデータが複数のルートに広がってもよく、更なる帯域の要件を緩和する。
【００２０】
更に、QoSルート選択レイヤで、コントローラは、出力データを送信するために必要なエネルギー使用レベルとQoS閾値とに基づいて、出力データで負荷平準化を実行してもよい。有利には、このことにより、消費電力、利用可能なQoS及び所定のアプリケーションにより必要とされるQoS閾値が、適切に釣り合うことが可能になる。
【００２１】
更に、無線通信装置は複数のチャネルで動作してもよく、選択されたルートは複数のチャネルのうち１つに関連してもよい。
【００２２】
従って、少なくとも１つの下位プロトコルレイヤで、有利には、コントローラは無線通信装置と協調し、選択されたルートのQoSレベルがQoS閾値の下に落ちたときに、少なくとも１つの他の利用可能なチャネルを探索してもよい。
【００２３】
本発明の方法の態様は、上記に簡単に説明したようなMANETで移動体ノードを動作するためのものである。その方法は、アプリケーションレイヤでQoS閾値を確立し、アプリケーションレイヤの下のQoSサポートレイヤでQoS閾値に基づいてデータ受信肯定応答を必要とするか否かを決定することを有してもよい。更に、QoSサポートレイヤの下のQoS符号化レイヤで、アプリケーションレイヤからのデータは、少なくとも１つの宛先移動体ノードへの送信のためにエンコードされてもよい。QoS符号化レイヤの下のQoSルート選択レイヤで、少なくとも１つの宛先ノードへの少なくとも１つのルートは、QoS閾値に基づいて選択されてもよい。また、QoSルート選択レイヤの下のQoSトラヒックレイヤで、データトラヒックフローはQoS閾値に基づいて制御されてもよい。更に、その方法はまた、QoSトラヒックレイヤの下の少なくとも１つの下位プロトコルレイヤで、無線通信装置に、少なくとも１つの選択されたルートを介して少なくとも１つの宛先移動体ノードにデータを送信させることを有してもよい。
【発明を実施するための最良の形態】
【００２４】
本発明について、添付図面を参照して以下に十分に説明する。図面には本発明の好ましい実施例を示している。しかし、本発明は多数の異なる形式で具体されてもよく、ここに示された実施例に限定して解釈されるべきではない。むしろ、これらの実施例は、この開示が十分且つ完全であるように提供されたものであり、当業者に本発明の範囲を当業者に十分に伝えるものである。全体に渡って同様の数字は同様の要素を示し、代替の実施例で類似の要素を示すためにプライム及びマルチプライム表記法が使用されている。
【００２５】
まず図１を参照すると、本発明によるMANET20は、複数の移動体ノード21-28を例示的に有する。図示の例では、移動体ノード21は、ソースノードとして機能し、移動体ノード25は、ソースノードが通信しようとする宛先ノードとして機能する。ノード21-28は、例えば無線通信装置30及び当業者にわかる他の装置を含み、MANET内で通信可能な如何なる適切な形式の移動体装置（コンピュータ、携帯情報端末（PDA）等）でもよい。当然のことながら、ノード21-28のうち特定のものは、必要に応じて何らかの用途で、任意選択で固定通信インフラに接続されてもよいことがわかる。
【００２６】
ソース移動体ノード21は例示的にコントローラ31を更に有する。その動作は以下に詳細に説明する。一例として、コントローラ31は、当業者にわかるように、マイクロプロセッサ、メモリ、ソフトウェア等を使用して実装されてもよい。更に、無線通信装置30は、例示的に図示するように、無線モデム、無線ローカルエリアネットワーク（LAN）装置、セルラ電話装置等と、関連のアンテナとを有してもよい。一例として、当業者にわかるように、１つ以上のフェーズド・アレイ・アンテナ（及び他の適切なアンテナ）が使用されてもよい。移動体ノード23-28もまた、同様に適切な無線通信装置／コントローラ（これらは図を明瞭にするために図１に図示しない）を有することが好ましいことも、更にわかる。
【００２７】
コントローラ31が実行する１つの機能は、データを送信するために、ソース移動体ノード21と宛先移動体ノード25との間に１つ以上のルートを確立することである。移動体ノード22-24を通過して無線通信リンク29a-29dを有する単一のルートが例示的な実施例に例示的に図示されている。図を明瞭にするために単一のルートのみが図示されているが、如何なる数のルートが本発明に従って使用されてもよい点に留意すべきである。
【００２８】
当業者にわかるように、MANETルートは、例えばネットワークのサイズとノード間の近接性とに応じて、如何なる数の中間ノードを有してもよい。ルートを通じた各中間ノードは、一般的に“ホップ”と呼ばれるため、複数の中間ノードを通過するルートは、時々“マルチホップ”ルートと呼ばれる。図を明瞭にするために、この例では比較的少ない数の中間ノード22-24が図示されているが、MANET20は如何なる数のノードを有してもよい点に留意すべきである。更に、宛先移動体ノード25へのルートの一部は有線インフラをも有してもよいことがわかる。
【００２９】
コントローラ31がルートを確立する方法は、MANET20に実装されている特定のMANETルーティングプロトコルに依存することもわかる。前述のように、このことは、ルーティング情報を継続的に最新に保持するプロアクティブ型ルーティングプロトコルを使用して行われてもよく、宛先ノード22にデータを送信する必要があるときにオンデマンドでルートを発見するリアクティブ型プロトコルを使用して行われてもよく、又はその組み合わせにより行われてもよい。例えば前述のようなルートを確立するために、本発明に従って如何なる適切なMANETプロトコルが使用されてもよい。
【００３０】
MANETは依然として相対的に初期段階であり、普遍的な標準がまだ採用されていないため、MANET内のデータ通信は、他の無線ネットワーク（例えば無線LAN）と同様に、オープン・システム・インターコネクション（OSI：open  system  interconnection）アーキテクチャ（又はその何らかの変形）に従う可能性が高い。背景として、OSIは７つの異なる制御レイヤ（すなわち、（上位から下位に）アプリケーションレイヤ、プレゼンテーションレイヤ、セッションレイヤ、トランスポートレイヤ、ネットワークレイヤ、データリンクレイヤ、及び物理レイヤ）を有するネットワークプロトコル階層である。
【００３１】
一般的に、OSIモデルでは、元のノード又は端末で１つのレイヤから次のレイヤに制御が渡され、アプリケーションレイヤから始まり、物理レイヤに進む。データはネットワークを通じて送信され、宛先端末／ノードに到達すると、階層を逆の順に（すなわち物理レイヤからアプリケーションレイヤに）処理される。更に、それぞれ特定のレイヤに対応するデータは、ネットワークレベルでパケットと呼ばれるプロトコルデータユニット（PDU：protocol  data  unit）に一般的に構成される。
【００３２】
本発明によれば、コントローラ31は、マルチレイヤプロトコル階層32に従って同様に動作し、QoS動作について統合フレームワークを提供する。一般的には、マルチレイヤプロトコル階層は、上位プロトコルレイヤ33と、１つ以上の中間プロトコルレイヤ34と、下位プロトコルレイヤ35とを有し、これらのレイヤで拡張QoS機能を提供するために相補QoS動作が実行される。
【００３３】
より具体的には、マルチレイヤプロトコル階層32’の例示的な実施例は図２に例示的に図示されており、それを使用した関連する方法は図８及び９に図示されている。図示及び理解の明瞭性のために、図８及び９に図示されている方法のステップが実行される様々なプロトコルレイヤが、例示的に点線で図示されてラベル付けされている点に留意すべきである。ブロック80で始まるマルチレイヤプロトコル階層32’に従って、コントローラ31は、アプリケーションレイヤ36’でMANET20を通じたデータ転送のサービス品質（QoS）閾値を確立してもよい（ブロック81）。より具体的には、アプリケーションレイヤ36’は、送信されるデータが生成又は処理されるレイヤであることが好ましい。
【００３４】
QoS閾値（又はサービスタイプTOS）は、この上位レイヤで動作している特定のアプリケーションに応じて変化する。例えば、時間依存のデータ（ビデオ又はオーディオデータ等）は、その整合性を維持するために、テキストデータファイルより大きいQoS閾値を必要としてもよい。特定のアプリケーションに必要なQoS閾値を規定する１つの一般的な方法は、データ送信に容認され得る全体のエンド・ツー・エンド遅延によるものである。しかし、QoS閾値を規定するために、多数の他のQoSパラメータが本発明に従って使用されてもよい。例えば、このようなパラメータは、当業者にわかるように、利用可能帯域、誤り率、エンド・ツー・エンド遅延の変化、ホップ数、予想パス存続性、優先度等のうち１つ以上を有してもよい。
【００３５】
ブロック82において、アプリケーションレイヤ36’の下のQoSサポートレイヤ37’で、コントローラ31は、QoS閾値及びモードに基づいてデータ受信肯定応答を必要とするか否かを決定する。すなわち、当業者にわかるように、ある場合には、送信データの受信移動体ノードの肯定応答（“Ack”）を有すること、及び／又はデータの正確な受信が確認できない場合に（“Nack”）ソース移動体ノード21に通知することが望ましい。QoSサポートレイヤ37’は、図２に例示的に示すOSIモデルに関して、概念的にセッション及び／又はトランスポートレイヤとして考えられてもよい。
【００３６】
データパケット受信肯定応答は、例えばソース移動体ノード21が隣接のノードに対して“信頼性のある”マルチキャスト動作を実行する必要があるときに、特に有用なことがある。一例として、移動体ノードがクラスタ又はグループに構成されており、ソース移動体ノード21がクラスタのリーダノードとしての役目を果たす場合、そのクラスタの他のノードに更新ネットワークトポロジ情報又は他の制御データを送信する必要があることがある。このように、ソース移動体ノード21は、これらのノードがこの重要なデータの受信を肯定応答することを要求してもよい。当然のことながら、データ肯定応答は、データの重要度と特別のAck/Nack送信に必要なオーバーヘッドとに基づいて、必要に応じて多数の他の状況で使用され得る。
【００３７】
更に、QoSサポートレイヤ37’で実行され得る他の特に有利な機能は、ハイレベルの承認制御である。より具体的には、ブロック89（図９）で始まり、コントローラ31は、他の移動体ノードから受信した各QoSルート要求とソースノード21の内部QoSメトリックとに基づいて、他の移動体ノードからのトラヒックを承認するか否かを決定してもよい。すなわち、基本的にコントローラ31は、その自分のQOS要件／リソースと、ソースノード21のリソースへのアクセスを要求する他の移動体ノードのQoS要件／リソースとに基づいて、何の形式のトラヒックが現在サポート可能であるかを決定する。
【００３８】
一例として、内部QoSメトリックは、利用可能出力、利用可能帯域、最近の誤り率及び最近の遅延のうち１つ以上を有してもよい。図を明瞭にするため、承認制御動作は、図２のQoSサポートレイヤ37’と離れたブロック47’で実行されるものとして図示されている。しかし、これらの動作のうち一部又は全部は、QoSサポートレイヤ37’と同じコントローラ又はプロセッサで実行されてもよい（同様に、それらは他のレイヤで別々のプロセッサにより実行されてもよい）。このような承認制御に関する更なる詳細は、2002年4月29日に出願されてこの譲受人に譲り受けられた同時継続の米国特許出願第10/134,173に提供されている。この内容が参照として取り込まれる。
【００３９】
ブロック83において、QoSサポートレイヤ37’の下のQoSパケット符号化レイヤ36’で、コントローラ31は、宛先移動体ノード25に送信するために、アプリケーションレイヤ36’からのデータをエンコードする。当然のことながら、アプリケーションレイヤ36’のコントローラ31により使用される他の移動体ノードから受信したデータパケットもまた、送信側移動体ノードにより使用されるエンコードアルゴリズムに対する相補デコードアルゴリズムを使用して、同様にQoSパケット符号化レイヤ38’でデコードされてもよいことが、当業者にわかる。
【００４０】
１つの特に有利な符号化手法は、コントローラ31が前方誤り訂正（FEC：forward  error  correction）アルゴリズムを使用してデータをエンコードし、QoS閾値に基づいてデータの誤り訂正データを生成することである。更に、コントローラ31はまた、宛先移動体ノード25にデータを送信するために複数のルートを選択してもよい。このような場合には、ブロック91において、有利にはコントローラ31は、誤り訂正データ及び送信されるデータパケットをインターリーブし、インターリーブされたデータを複数の選択されたルートを通じて配信してもよい。
【００４１】
FECを実行し、インターリーブされたデータを複数のルートを通じて配信することにより、ルートの１つが失われていたとしても、MANETは破損したデータパケットが訂正されることを可能にし、必要に応じて新しいルートが確立されている間に送信が継続することを可能にする。更に、FECエンコードに関連する更なる量のデータは、複数のルートに広がってもよく、これにより更なる帯域の要件を緩和する。QoSパケット符号化レイヤ38’で実行され得るFEC／インターリーブ動作に関する更なる詳細は、2003年2月19に出願されてこの譲受人に譲り受けられた同時継続の米国特許出願第10/369,313号に提示されている。この内容が参照として取り込まれる。
【００４２】
ブロック84において、ルート選択は、QoS符号化レイヤ38’の下のQoSルート選択レイヤ39’で実行されてもよい。一般的に、コントローラ31は、QoSルート要求を隣接の移動体ノードに送信させ、所望の宛先移動体ノードへの潜在的なルートを発見する。何のQoSレベルをルートがサポート又は提供することができるかについての指示又はメトリックを有するルート確認は、ソース移動体ノード21に返信される。利用可能ルートのリストは、ルーティングテーブル45’に格納されてもよい。そのルーティングテーブル45’から、コントローラ31はルーティングアルゴリズムに基づいて所望のルートを選択する。MANET内で１つ以上のルートを通じてデータを確立して送信する複数の特に有利な手法は、2002年8月8日に出願された同時継続の米国特許出願第10/214,997号と、2002年6月19日に出願された同時継続の米国特許出願第10/174,721号と、事件番号GCSD-1468(51334)のROUTE  SELECTION  IN  MOBILE  AD-HOC  NETWORKS  BASED  ON  TRAFFIC  STATE  INFORMATIONという題の同時継続の出願とに記載されている。これらの全てがこの譲受人に譲り受けられており、この内容が参照として取り込まれる。
【００４３】
更に、ブロック92において、コントローラ31は、出力データを送信するために必要なエネルギー使用レベル（すなわち出力）とQoS閾値とに基づいて、出力データについてQoSルート選択レイヤ39’で負荷平準化を任意選択で実行してもよい。有利には、このことにより、消費電力、利用可能なQoS及び所定のアプリケーションにより必要とされるQoSが、所定の状態で適切に釣り合うことが可能になる。負荷平準化動作に関する更なる詳細は、事件番号CSCD-1470(51336)のLOAD  LEVELING  IN  MOBLIE  AD-HOC  NETWORKS  TO  SUPPORT  END-TO-END  DELAY  REDUCTION,  QOS  AND  ENERGY  LEVELINGという題の同時継続の出願に提供されている。この内容が参照として取り込まれる。
【００４４】
更に、ブロック93において、QoSルート選択レイヤ39’の下のQoS転送レイヤ40’で、コントローラ31は、ユニキャスト通信モードとマルチキャスト通信モードとの間を選択することが好ましい。より具体的には、コントローラ31は、アプリケーションレイヤ36’で、所定のアプリケーションについてQoS転送レイヤ40’で選択される特定の形式の通信モード（例えばクラスタのリーダノードのブロードキャストでは信頼性のあるマルチキャスト通信）を指示してもよい。
【００４５】
他のアプリケーションでは、特定の通信モードはアプリケーションレイヤ36’で必ずしも指定されなくてもよい。従って、コントローラ31は、QoS閾値に基づいて何の通信モードが適切であるかを決定してもよい。当然のことながら、この決定は、他の要因（特定の無線通信装置30のリソースの可用性、特定の形式の送信が他の移動体ノードとの意図的でない干渉を生じる可能性があるか否か等）を考慮してもよい。特に、特定の通信モードがアプリケーションレイヤ36’で指定されている場合であっても、コントローラは、前述の要因のうち１つ以上に基づいて異なる通信モードが使用されるべきであることをQoS転送レイヤ40’で決定してもよい。
【００４６】
更に、ブロック85において、QoS転送レイヤ40’の下のQoSトラヒックレイヤ41’で、コントローラ31はデータトラヒックフローを制御することが好ましく、また、QoS閾値を維持するためにそのデータキューを管理してもよい。特に、１つの有利な実施例では、前述のQoSルート要求は、それぞれのトラヒックフロー識別子と、それに関連する第２のQoS閾値又は上限とを有してもよい。従って、ブロック94において、有利にはコントローラ31は、各トラヒックフロー識別子に基づいて承認されたトラヒックを規制し、承認されたトラヒックがそれぞれの第２のQoS閾値を超えないことを確保してもよい。このようなトラヒック規制に関する更なる詳細は、2002年4月29日に出願されてこの譲受人に譲り受けられた同時継続の米国特許出願第10/134,714号に提供されている。この内容が参照として取り込まれる。
【００４７】
更に、当業者にわかるように、QoSトラヒックレイヤ41’の下の少なくとも１つの下位プロトコルレイヤで、コントローラ31は無線通信装置30と協調し、上位レイヤから提供されたコマンド／データに基づいて選択されたルートを介して宛先移動体ノード25にデータを送信する。このように、図８に示す方法が終了する（ブロック87）。
【００４８】
更に、ユニキャスト及びマルチキャストモードがコントローラ31により共に実装される場合には、有利にはコントローラは、無線通信装置30と協調し、選択された特定の通信モードに基づいてデータを送信してもよい。すなわち、ブロック95-98において、使用されている通信モードの特定の形式と選択されたルートのQoSメトリックとに応じて、様々な信号送信特性が調整されてもよい。このように、図９に示す方法が終了する（ブロック99）。信号送信及び受信特性の調整は、以下に更に説明する。
【００４９】
特に、階層32’の下位プロトコルレイヤは、QoSトラヒックレイヤ41’の下の無線適応レイヤ42’と、無線適応レイヤの下の媒体アクセス（MAC）レイヤ43’と、MACレイヤの下の物理（PHY）レイヤ44’とを有することが好ましい。無線適応レイヤ42’は、上位プロトコルレイヤとMAC及びPHYレイヤとの間のインタフェースを提供し、そのうちの後者は、コントローラ31が無線通信装置30と物理的にインタフェース接続するところである。当然のことながら、例えばリンクレイヤのように、他のレイヤも階層32’に同様に含まれてもよく、ここに記載した特定の機能は特定の実施例では異なるレイヤに実装されてもよいことが、当業者にわかる。
【００５０】
従って、ブロック95において、物理レイヤ44’では、コントローラ31は無線通信装置30と協調し、選択されたルートのQoSメトリックを決定することが好ましい。これは、何らかのQoS調整が行われる必要があるか否か、又は単に通信がそのルートでもはや不可能であるか否かを決定するために使用され得る。QoSメトリックは確立されたルートのQoSを維持するために使用されるだけでなく、一般的にルート発見及び選択のために使用されることもわかる。これが図２に動作ブロック46’で例示的に図示されている。この場合も同様に、図を明瞭にするため、ブロック46’は無線適応レイヤ42’と離れて図示されているが、ここに示されている動作は実際に無線適応レイヤ（又は他のレイヤ）で実行されてもよい点に留意すべきである。
【００５１】
ブロック96において、選択されたルートのQoSメトリックを監視することにより、QoSルート選択レイヤ39’で、コントローラ31はQoSメトリックがQoS閾値の下に落ちたか否かを決定してもよい。そうである場合には、ブロック97において、物理レイヤ44’で、コントローラ31は無線通信装置30と協調し、QoSメトリックを改善するために１つ以上の信号特性を調整してもよい。
【００５２】
次に更に図３〜７及び１０〜１１を参照して、QoSを改善するためにどのように信号特性が調整可能であるかについての特定の例について説明する。第１の例は、QoSメトリックが所望の移動体ノード（選択されたルートを通じた次の移動体ノード）への信号接続性が望ましくないレベル（例えばQoS閾値の下）に減衰したことを示す場合である。
【００５３】
ソース移動体ノード51とそれに隣接する移動体ノード52-58とを有する図３に示すMANET50に関して、ソース移動体ノードは、半径r1で規定される領域59’で送信する。従って、前述のようにQoS閾値を確立してQoSメトリックを決定して所望のルートを選択した（ブロック100-103）後に、QoSメトリックがQoS閾値の下に落ちたことが決定されると（ブロック104）、PHYレイヤ44’で、コントローラ31は無線通信装置30と協調し、図４に例示的に示すように信号送信出力を増加させる。減少した信号接続性の決定は、当業者にわかるように、１つ以上のQoS要因（誤り率、受信信号強度等）に基づいて行われてもよい。
【００５４】
その結果、MANET50’の送信領域59’は、半径r1より大きい半径r2での円により規定される。このように、例えばソース移動体ノード51が最初に移動体ノード54と通信しており、（図３に示す）範囲外に移動した場合に、信号送信出力の増加により、このノードを送信範囲59’内にする。
【００５５】
当然のことながら、隣接の移動体ノードとの干渉を無意識に生じさせることを回避するために、反対の手法が行われてもよい。図５に示すMANET60について検討する。MANET60は、相互に干渉しているソース移動体ノード61と隣接の移動体ノード62とを例示的に有する。特に、ソース移動体ノード61から移動体ノード63-67への送信は、移動体ノード62での意図的でない干渉を生じる。従って、例えば移動体ノード62からの干渉によりQoS閾値が満たされていないことをQoSメトリックが示す場合に、コントローラ31は、移動体ノード61及び62が相互に干渉しており、それに従ってその信号送信出力を減少することを決定してもよい。従って、その信号送信領域68は半径r11で規定される円（図５）から半径r21で規定される小さい円（図６）に減少し、もはや移動体ノード62’への干渉を生じない。
【００５６】
信号出力に加えて、同様に他の信号特性が調整されて、同様な結果（すなわち、増加したノード間接続性又は減少した干渉）を実現してもよい。例えば、図７に示す場合では、図示のように送信領域68’’から移動体ノード62’’を除外するために、信号送信アンテナパターン（又はビーム形状）が変更されている。他の同様な技術は、所望の方向の信号送信利得を調整することであり、当業者にわかるように、これも送信領域に変化をもたらす。
【００５７】
更に、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、信号送信出力、信号送信利得及び／又は信号送信パターンを調整することにより、有利には、コントローラ31はまた、多くの移動体ノードを組み込むように信号送信範囲を調整してもよい。例えば更なるルートが必要な場合、又は新しいノードがノードのクラスタ又はグループに加わる場合に、このことは特に有用なことがある。
【００５８】
ブロック106において、改善したQoSを提供するために、同様に他の信号特性が任意選択で調整されてもよい。例えば、当業者にわかるように、実行される誤り符号化が変更されてもよい。同様に、コントローラ31は無線通信装置30と協調し、QoSメトリックがQoS閾値以上である場合に、第１の変調技術を使用してデータを変調してもよく、そうでない場合に、第２の変調技術を使用してデータを変調してもよい。一例として、適切な変調技術は、TDMA、CDMA、FDMA及びSDMA等を有してもよい。ブロック107において、送信は調整された信号特性に従って実行される。これにより、図示の方法が終了する（ブロック108）。
【００５９】
更に、コントローラ31は無線通信装置30と協調し、所望のデータレートでデータを送信する。従って、コントローラ31はまた、無線通信装置30と協調し、当業者にわかるように、利用可能なQoSに基づいて必要に応じてデータレートを調整してもよい。
【００６０】
特定のノードが隣接の干渉するノードから受信する干渉を減少させるために、同様の技術も使用されてもよいこともわかる。すなわち、宛先移動体ノードは、データを受信するルートのQoSメトリックが、アプリケーションレイヤ36’で設定されたQoS閾値の下に落ちたことを決定してもよい（ソース移動体ノードにより提供されてもよく、双方のノードで合意されてもよく、又は独立に確立されてもよい）。このような場合に、ブロック110’及び111’において（図１１）、コントローラ31は、前述のように、例えば全体の信号受信利得及び／又は信号受信パターンを調整し、データを受信するときに干渉する移動体ノードにより生じる干渉を減少させることができる。
【００６１】
更に、無線通信装置30はまた、図２のMAC/PHYコラム47a’-47c’で例示的に示される複数のチャネルで動作してもよい。従って、所定のルートが複数のチャネルのうち１つに関連する場合、コントローラ31は無線通信装置30と協調し、選択されたルートのQoSレベルがQoS閾値の下に落ちたときに、１つ以上の他の利用可能な物理チャネルを探索又は監視してもよい。このようなチャネル監視及び選択についての更なる将来は、2002年4月29日に出願されてこの譲受人に譲り受けられた米国特許出願第10/134,862号に提供されている。この内容が参照として取り込まれる。当然のことながら、コラム47a’-47c’は、変調形式、通信モード形式等のような他の物理レイヤの設定又は“ノブ（knob）”に同様に対応してもよい点に留意すべきである。
【００６２】
従って、本発明のプロトコル階層は、拡張QoSを提供するために協調のQoS動作を効率的且つ便宜的に構成するためのQoSフレームワークを提供することが、当業者にわかる。更に、本発明は、特定のアプリケーション及びユースシナリオのコンポーネント型の開発を可能にする全体の統合フレームワークを提供する。更に、複数の代替のソースから宛先へのパケットルートの生成に役立つトラヒック状態の使用（例えば稼働率、残留容量、ホップ数、転送遅延等）を提供する。
【００６３】
更に、本発明によれば、有利には、無線適応レイヤ42’により、複数の無線インタフェース（例えば、異なる無線形式、インタフェース、物理チャネル等）の使用が可能になる。更に、本発明はまた、QoS駆動のPHYレイヤの適応を提供し、受信範囲を改善し、干渉を減少させ、到達する隣接のノード数を増加させ、信頼性を改善する。更に、データパケットは上位プロトコルレイヤで符号化され、必要に応じて大きい誤り訂正等を提供してもよい。また、有利には、大きい信頼性及びスループットを提供するため並びにエンド・ツー・エンド遅延を小さくするために、複数のルートが使用されてもよい。
【図面の簡単な説明】
【００６４】
【図１】本発明によるMANETの概略ブロック図である。
【図２】図１のMANETに実装されたマルチレイヤプロトコル階層の代替実施例の概略ブロック図である。
【図３】信号接続性を増加させるために本発明に従って信号送信出力を調整する前のMANETを示す概略ブロック図である。
【図４】信号接続性を増加させるために本発明に従って信号送信出力を調整する後のMANETを示す概略ブロック図である。
【図５】隣接の移動体ノードで信号干渉を減少させるために本発明に従って信号送信出力を調整する前のMANETを示す概略ブロック図である。
【図６】隣接の移動体ノードで信号干渉を減少させるために本発明に従って信号送信出力を調整する後のMANETを示す概略ブロック図である。
【図７】同様に隣接の移動体ノードで干渉を減少させるために本発明に従ってソース移動体ノードで信号送信アンテナパターンを調整した後の図５のMANETの概略ブロック図である。
【図８】本発明に従ってMANETで移動体ノードを動作する方法を示したフローチャートである。
【図９】本発明に従ってMANETで移動体ノードを動作する方法を示したフローチャートである。
【図１０】本発明に従ってMANETで移動体ノードを動作する方法を示したフローチャートである。
【図１１】本発明に従ってMANETで移動体ノードを動作する方法を示したフローチャートである。
【図１】
2007505566.tif 000003
【図２】
2007505566.tif 000004
【図３】
2007505566.tif 000005
【図４】
2007505566.tif 000006
【図５】
2007505566.tif 000007
【図６】
2007505566.tif 000008
【図７】
2007505566.tif 000009
【図８】
2007505566.tif 000010
【図９】
2007505566.tif 000011
【図１０】
2007505566.tif 000012
【図１１】
2007505566.tif 000013
【国際調査報告】
2007505566.tif 000014