JP2007505565A

JP2007505565A - 接続性拡張機能を提供する移動体アドホックネットワーク（ｍａｎｅｔ）及び関連する方法

Info

Publication number: JP2007505565A
Application number: JP2006526163A
Authority: JP
Inventors: ケイン，ジョーゼフ，ビブ; バーンハート，リチャード，チャールズ; ウィンダム，ウィリアム，アンソニー
Original assignee: Harris Corp
Current assignee: Harris Corp
Priority date: 2003-09-09
Filing date: 2004-09-01
Publication date: 2007-03-08
Also published as: TW200520453A; CA2538042A1; TWI251410B; EP1665645A2; KR100673866B1; EP1665645A4; EP1665645B1; WO2005027262A2; US7085290B2; CN1856960A; KR20060087548A; US20050053005A1; WO2005027262A3

Abstract

移動体アドホックネットワーク（MANET）（20）は、無線通信装置（30）と、それに接続されたコントローラ（31）とをそれぞれ有する複数の移動体ノード（21-28）を有してもよい。上位プロトコルレイヤ（36’）で、コントローラはサービス品質（QoS）閾値を確立してもよい。上位プロトコルレイヤの下の少なくとも１つの中間プロトコルレイヤ（39’）で、コントローラは、QoS閾値に基づいて少なくとも１つの宛先移動体ノード（25）にデータを送信するために少なくとも１つのルートを選択し、選択されたルートのQoSメトリックがQoS閾値の下に落ちたか否かを決定してもよい。下位プロトコルレイヤ（44’）で、コントローラ（31）は無線通信装置（30）と協調し、少なくとも１つの選択されたルートを介して少なくとも１つの宛先移動体ノード（25）にデータを送信してもよい。また、下位プロトコルレイヤ（44’）で無線通信装置と協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、信号送信出力、パターン及び／又は利得を調整してもよい。

Description

無線ネットワークは、過去１０年に更なる発展を経験してきた。最も急速に発展している領域の１つは移動体アドホックネットワーク（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機能が必要になる。

従って、前述の背景を鑑みて、拡張移動体ノード接続機能を有するMANET及び関連する方法を提供することが、本発明の目的である。

本発明による前記及び他の目的、特徴及び利点は、無線通信装置と、それに接続されてマルチレイヤプロトコル階層に従って動作するコントローラとをそれぞれ有する複数の移動体ノードを有してもよいMANETにより提供される。より具体的には、コントローラは、上位プロトコルレイヤでサービス品質（QoS）閾値を確立してもよい。更に、上位プロトコルレイヤの下の少なくとも１つの中間プロトコルレイヤで、コントローラは、QoS閾値に基づいて少なくとも１つの宛先移動体ノードにデータを送信するために少なくとも１つのルートを選択し、選択されたルートのQoSメトリックがQoS閾値の下に落ちたか否かを決定してもよい。

更に、少なくとも１つの中間プロトコルレイヤの下の下位プロトコルレイヤで、コントローラは、無線通信装置と協調し、少なくとも１つの選択されたルートのQoSメトリックを決定し、少なくとも１つの選択されたルートを介して少なくとも１つの宛先移動体ノードにデータを送信してもよい。コントローラはまた、下位プロトコルレイヤで無線通信装置と協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、信号送信出力を調整してもよい。

同様に、コントローラは、下位プロトコルレイヤで無線通信装置と更に協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、所望の方向に信号送信利得を調整してもよい。更に、無線通信装置は、調整可能信号（すなわちアンテナ）送信パターンを提供してもよい。従って、下位プロトコルレイヤで、コントローラはまた、無線通信装置と協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、信号送信パターンを調整してもよい。

QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、信号送信出力、信号送信利得及び／又は信号送信パターンを調整することにより、有利には、コントローラはその信号範囲を調整し（すなわちその送信出力を調整することにより）、多くの移動体ノードを組み込み、又は既にその信号範囲内のノードに対して大きい接続性を提供してもよい。更に、有利には、このような調整はまた、コントローラがネットワークの隣接の移動体ノードと干渉を生じないように、信号範囲を調整するために使用されてもよい。

更に、少なくとも１つの中間プロトコルレイヤで、コントローラは、送信前にデータをエンコードしてもよい。このように、コントローラは、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、実行するエンコード量を調整してもよい。このことはまた、ノード間で接続性を向上するため及び／又は干渉を減少させるために使用されてもよい。

同様に、下位プロトコルレイヤで、QoSメトリックがQoS閾値以上である場合に、コントローラは無線通信装置と協調し、第１の変調技術を使用してデータを変調してもよく、そうでない場合に、第２の変調技術を使用してデータを変調してもよい。すなわち、コントローラは、ネットワークトポロジが変化すると、信号接続性を増加させるため又は干渉を減少させるために変調技術を切り替え、QoS閾値を維持してもよい。

更に、下位プロトコルレイヤで、コントローラは無線通信装置と協調し、データレートでデータを送信してもよい。従って、コントローラはまた、無線通信装置と協調し、QoSメトリックがQoS閾値の下に落ちたという決定に基づいて、データレートを調整してもよい。この場合にも同様に、必要に応じて拡張した接続性又は減少した干渉を提供する。

一例として、上位プロトコルレイヤはアプリケーションレイヤでもよい。更に、少なくとも１つの中間プロトコルレイヤは、セッションレイヤとトランスポートレイヤとネットワークレイヤと無線トランスポートレイヤとのうち１つ以上を有してもよい。更に、下位ネットワークレイヤは物理レイヤでもよい。更に、QoS閾値は、例えば、利用可能帯域と誤り率とエンド・ツー・エンド遅延とエンド・ツー・エンド遅延の変化（すなわちジッタ）とホップ数と予想パス存続性と優先度とのうち少なくとも１つに基づいてもよい。

本発明の方法の態様は、簡単に前述したように、マルチレイヤプロトコル階層に従ってMANETで移動体ノードを動作するためのものである。その方法は、上位プロトコルレイヤで、サービス品質（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に関して、ソース移動体ノードは、半径r₁で規定される領域59’で送信する。従って、前述のようにQoS閾値を確立してQoSメトリックを決定して所望のルートを選択した（ブロック100-103）後に、QoSメトリックがQoS閾値の下に落ちたことが決定されると（ブロック104）、PHYレイヤ44’で、コントローラ31は無線通信装置30と協調し、図４に例示的に示すように信号送信出力を増加させる。減少した信号接続性の決定は、当業者にわかるように、１つ以上のQoS要因（誤り率、受信信号強度等）に基づいて行われてもよい。

その結果、MANET50’の送信領域59’は、半径r₁より大きい半径r₂での円により規定される。このように、例えばソース移動体ノード51が最初に移動体ノード54と通信しており、（図３に示す）範囲外に移動した場合に、信号送信出力の増加により、このノードを送信範囲59’内にする。

当然のことながら、隣接の移動体ノードとの干渉を無意識に生じさせることを回避するために、反対の手法が行われてもよい。図５に示すMANET60について検討する。MANET60は、相互に干渉しているソース移動体ノード61と隣接の移動体ノード62とを例示的に有する。特に、ソース移動体ノード61から移動体ノード63-67への送信は、移動体ノード62での意図的でない干渉を生じる。従って、例えば移動体ノード62からの干渉によりQoS閾値が満たされていないことをQoSメトリックが示す場合に、コントローラ31は、移動体ノード61及び62が相互に干渉しており、それに従ってその信号送信出力を減少することを決定してもよい。従って、その信号送信領域68は半径r₁₁で規定される円（図５）から半径r₂₁で規定される小さい円（図６）に減少し、もはや移動体ノード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で移動体ノードを動作する方法を示したフローチャートである。

Claims

無線通信装置と、それに接続されたコントローラとをそれぞれ有する複数の移動体ノードを有する移動体アドホックネットワーク（MANET）であって、
前記コントローラは、マルチレイヤプロトコル階層に従って動作し、
上位プロトコルレイヤでサービス品質（QoS）閾値を確立し、
前記上位プロトコルレイヤの下の少なくとも１つの中間プロトコルレイヤで、前記QoS閾値に基づいて少なくとも１つの宛先移動体ノードにデータを送信するために少なくとも１つのルートを選択し、前記選択されたルートのQoSメトリックが前記QoS閾値の下に落ちたか否かを決定し、
前記少なくとも１つの中間プロトコルレイヤの下の下位プロトコルレイヤで、前記無線通信装置と協調し、前記少なくとも１つの選択されたルートのQoSメトリックを決定し、前記少なくとも１つの選択されたルートを介して前記少なくとも１つの宛先移動体ノードにデータを送信し、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、信号送信出力を調整する移動体アドホックネットワーク。
請求項１に記載のMANETであって、
前記下位プロトコルレイヤで、前記コントローラは前記無線通信装置と更に協調し、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、所望の方向に信号送信利得を調整するMANET。
請求項１に記載のMANETであって、
前記無線通信装置は、調整可能信号送信パターンを提供し、前記下位プロトコルレイヤで、前記コントローラはまた、前記無線通信装置と協調し、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、前記信号送信パターンを調整するMANET。
請求項１に記載のMANETであって、
前記少なくとも１つの中間プロトコルレイヤで、前記コントローラは送信前にデータをエンコードし、前記コントローラはまた、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、誤り訂正符号化の量を調整するMANET。
請求項１に記載のMANETであって、
前記下位プロトコルレイヤで、前記QoSメトリックが前記QoS閾値以上である場合に、前記コントローラは前記無線通信装置と協調し、第１の変調技術を使用してデータを変調し、そうでない場合に、第２の変調技術を使用してデータを変調するMANET。
マルチレイヤプロトコル階層に従って複数の移動体ノードを有する移動体アドホックネットワーク（MANET）で移動体ノードを動作し、前記移動体ノードは無線通信装置を有する方法であって、
上位プロトコルレイヤでサービス品質（QoS）閾値を確立し、
前記上位プロトコルレイヤの下の少なくとも１つの中間プロトコルレイヤで、前記QoS閾値に基づいて少なくとも１つの宛先移動体ノードにデータを送信するために少なくとも１つのルートを選択し、前記選択されたルートのQoSメトリックが前記QoS閾値の下に落ちたか否かを決定し、
前記少なくとも１つの中間プロトコルレイヤの下の下位プロトコルレイヤで、前記無線通信装置を使用し、前記少なくとも１つの選択されたルートのQoSメトリックを決定し、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、前記無線通信装置に信号送信出力を調整させ、前記無線通信装置に、前記少なくとも１つの選択されたルートを介して前記少なくとも１つの宛先移動体ノードに対してデータを送信させることを有する方法。
請求項６に記載の方法であって、
前記下位プロトコルレイヤで、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、前記無線通信装置に、所望の方向に信号送信利得を調整させることを更に有する方法。
請求項６に記載の方法であって、
前記無線通信装置は、調整可能信号送信パターンを提供し、前記下位プロトコルレイヤで、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、前記無線通信装置に、前記信号送信パターンを調整させることを更に有する方法。
請求項６に記載の方法であって、
前記少なくとも１つの中間プロトコルレイヤで、送信前にデータをエンコードし、前記QoSメトリックが前記QoS閾値の下に落ちたという決定に基づいて、エンコードの量を調整することを更に有する方法。
請求項６に記載の方法であって、
前記下位プロトコルレイヤで、前記QoSメトリックが前記QoS閾値以上である場合に、前記無線通信装置に、第１の変調技術を使用してデータを変調させ、そうでない場合に、第２の変調技術を使用してデータを変調させることを更に有する方法。