(57)【要約】無線ネットワーク内のマルチホップパケット送信の方法は、無線ネットワークを介してマルチホップルートを確立することを含む。マルチホップルートの確立後、送信プロトコルのパラメータはマルチホップルート全体にわたる送信遅延を最小にするために変更され、少なくとも１つのパケットは、変更された送信プロトコルのパラメータに従って、マルチホップルート上を送信される。第１の実施形態において、送信プロトコルのパラメータの変更は、ルート上のパケット送信の間、マルチホップルートの各ノードにおいてＮＡＶ値を設定することを含む。別の実施形態において、マルチホップパケットは、より高度なＱｏＳ値を割り当てられる。
2005504484.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワークにおいてマルチホップパケット送信を行う方法であって、
前記無線ネットワークを介してマルチホップルートを確立する工程と、
送信プロトコルのパラメータを変更して、前記マルチホップルート上のパケット送信の遅延を最小にする工程と、
前記変更された送信プロトコルのパラメータに従って、前記ルート上に少なくとも１つのパケットを送信する工程と
を備える方法。
【請求項２】
前記変更する工程は、前記ルート上の前記パケット送信の所要時間について、前記ルートの各ノードにおいてＮＡＶ値を設定する工程を更に含む請求項１記載の方法。
【請求項３】
前記確立する工程は、
第１のノードから第２のノードへ前記マルチホップルートを要求するルート要求メッセージを送信する工程と、
最初のメッセージが前記第１のノードから前記第２のノードへ移動するときに、前記ルートに関するルートデータを収集する工程と、
前記第２のノードから前記第１のノードへ、ルート応答メッセージを返送する工程と
を更に含む請求項２記載の方法。
【請求項４】
前記変更する工程は、
前記収集されたルートデータに対応する前記マルチホップパケット送信を完了するのに必要な合計時間を示す所要時間値を計算する工程と、
前記所要時間値を前記ルート応答メッセージ内に含める工程とを更に含み、
前記ＮＡＶ値は、前記所要時間値に対応する前記マルチホップルートの各ノードにおいて設定され、前記所要時間値によって示される期間、設定を維持する請求項３記載の方法。
【請求項５】
前記送信完了後、前記ＮＡＶ値を再設定する工程を更に含む請求項４記載の方法。
【請求項６】
前記送信する工程は、前記ＮＡＶ値が設定された場合、前記第１のノードから前記第２のノードへの前記ルートに沿った少なくとも１つのパケットを送信する工程を更に含む請求項４記載の方法。
【請求項７】
前記送信が前記所要時間値によって示される時間に先立って終了した場合、前記ＮＡＶ値を再設定する工程を更に含む請求項４記載の方法。
【請求項８】
前記確定する工程は、先行するルート決定から前記マルチホップルートを決定する工程を更に含む請求項４記載の方法。
【請求項９】
前記所要時間値は、先行する送信から決定され、前記ルート要求メッセージに含まれる請求項４記載の方法。
【請求項１０】
前記送信する工程は、優先度の高さに従って送信される請求項３記載の方法。
【請求項１１】
前記第１のノードから前記第２のノードへの決定された送信時間と同等の第２の所要時間値を決定する工程と、
前記ルート応答メッセージが完了するまでに、前記所要時間値に対応する前記ＮＡＶ値を設定する工程とを更に含む請求項３記載の方法。
【請求項１２】
前記ＮＡＶ値は、ノードがパケット送信の受信を開始した場合に設定されるのみである請求項２記載の方法。
【請求項１３】
前記変更する工程は、マルチホップパケット用のより高度なＱｏＳクラスを確立する工程を更に含む請求項１記載の方法。
【請求項１４】
パケットがマルチホップパケットかどうかを決定する工程を更に含む請求項１３記載の方法。
【請求項１５】
前記決定する工程は、前記パケットのＭＡＣヘッダのアドレスフィールドを解析して送信元アドレス及び宛先アドレスが同じＩＢＳＳであるかどうかを決定する工程を更に含む請求項１４記載の方法。
【請求項１６】
前記決定する方法は、マルチホップパケットを示す前記パケットの前記ＭＡＣヘッダ内のデータフィールドを識別する工程を更に含む請求項１４記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散型無線ローカルエリアネットワークに関し、特に、マルチホップメカニズムを使用して無線ローカルエリアネットワークシステム内でデータをより効率的に送信する方法に関する。
【背景技術】
【０００２】
本出願は、２００１年９月２７日出願の合衆国仮出願第６０／３２６，０５９号の内容全体から優先権を主張し、またその内容全体を本出願に取り入れている。
【０００３】
ＩＥＥＥ（８０２．１１）無線ローカルエリアネットワーク（ＷＬＡＮ）システムは、インフラストラクチャシステム又は非インフラストラクチャシステム（独立型ＢＳＳ又はアドホック型ネットワークモードとも呼ばれる）内におけるステーション（ＳＴＡ）とアクセスポイント（ＡＰ）との間の通信を可能にする。ＩＥＥＥ８０２．１１ＷＬＡＮシステムは、ＩＢＳＳ（独立基本サービスセット）モードにおけるＳＴＡ間のシングルホップ通信を可能にする。アクセス制御方式は、分散型協調機能（ＤＣＦ）と呼ばれる分散型メカニズムであり、ＣＳＭＡ／ＣＡ（搬送波検知多元アクセス／衝突回避）に基づく。物理ＣＳ（搬送波検知）に加えて、継所要時間値が各送信パケットの送信の長さを示すように仮想ＣＳメカニズムが使用される。
【０００４】
なお、パケットは１つ以上のフラグメントから構成されて、例えば干渉等が発生した場合のパケット再送のリスクを軽減してもよく、パケットの各フラグメントは、先行するフラグメントの正常な受信を示す受信側からの確認応答の後、ＳＩＦＳ（短フレーム間隔）の後に送信される。あるフラグメントで送信される所要時間は、（もし存在する場合は）対応するＡＣＫも加えて、後続のフラグメントを送信する時間を含む。
【０００５】
所要時間値を受信したステーションは、所要時間フィールドに保存される所要時間値と同じ期間、無線媒体上で送信を行なわない。いわゆる隠れ端末問題を処理ために、ＲＴＳ／ＣＴＳ制御方式を使用する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
現在、８０２．１１ＩＢＳＳネットワーク（アドホック型ネットワーク）のマルチホップはサポートされていない。マルチホップによって、互いに直接到達圏外であるステーションは、中間のステーションを経て中継パケットを介して通信することが可能となる。マルチホップサポートの更なる利点は、間隔を複数のホップに分割することによって、指数法則の伝播モデルにより、各ホップにおいて受信する信号の品質が改善されることである。これは、所定の条件下においてエンドツーエンド遅延を減少することが可能な、より高速のリンクを通して活用され得る。
【０００７】
８０２．１１プロトコルは本質的にマルチホップをサポートしないが、マルチホップのサポートを有するより高い階層のプロトコルを、既存の８０２．１１プロトコルの上に設けることを排除するものではない。現在、ＩＥＴＦ内のＭＡＮＥＴ  ＷＧは、マルチホップ機能を有するモバイルアドホック型ネットワークのための一組のＴＣＰ／ＩＰプロトコルの拡張に取り組んでいる。ＡＯＤＶ及びＤＳＲ等のいくつかのＭＡＮＥＴプロトコルは、ＩＢＳＳモードで動作する８０２．１１プロトコルと共に試験的に使用されている。
【０００８】
しかしながら、これらのルーティングプロトコルは８０２．１１プロトコル上で使用され、無線アクセスプロトコルに接続することなくアドホック型ネットワーク内でマルチホップルーティングを提供するが、その場合、性能上の問題が発生する。例えば、パケットが無線ステーション間で複数のホップを移動して目的地に到着する場合、無線プロトコルの性質によって深刻な遅延が発生する。また、各リンク上では衝突も発生し、各ホップでアクセス遅延が加わる可能性がある。エンドユーザに気づかれるＴＣＰトランザクションの高スループットを達成するために、遅延は重要な要素となりうる。従って、８０２．１１プロトコル内のマルチホップパケットの制御を有効とすることによって、ネットワーク全体の性能は著しく向上するであろう。
【課題を解決するための手段】
【０００９】
本発明は、複数のホップを有するルートが無線ネットワークで最初に確立される無線ネットワークにおけるマルチホップパケット通信方法を用いて前述及び他の問題を解決する。マルチホップルートに関連する送信プロトコルのパラメータは、マルチホップルート全体にわたるパケット送信の遅延を最小限にするために変更される。パケットは、変更された送信プロトコルのパラメータに従って、マルチホップルート上を送信される。
【００１０】
第１実施形態において、送信プロトコルのパラメータを変更する工程は、マルチホップルート上のパケット送信中、マルチホップルート上の各ノードでＮＡＶ値を設定することを含む。別の方法において、マルチホップパケットは、より高いＱｏＳ値に従ってマルチホップルート上を送信される。
【００１１】
本発明に含まれて本発明に関する更なる理解のために本発明に含まれ、かつ本明細書に取り入れられて本明細書の一部を構成する添付の図面によって、本発明の詳細な説明と共に本発明の原理を説明するための本発明の実施形態を示す。
【発明を実施するための最良の形態】
【００１２】
ここで図面、特に、３つの別個のＩＢＳＳ１５内に複数のＳＴＡ１０を示す図１を参照する。図１は、ＳＴＡ  ＡとＳＴＡ  Ｂとの間のマルチホップ接続を示す。この接続は、接続を確立するために２つの他のＳＴＡ１０を使用して、ＳＴＡ  ＡとＳＴＡ  Ｂとの間に３つのホップを最終的に含む。本発明に従って、追加の提案がＩＥＥＥ８０２．１１プロトコルに対して行なわれる。この提案では、マルチホップルート内のＳＴＡノードのＮＡＶ値は拡張されて、単一のリンクに及ぶだけではなく、複数のＳＴＡ間のホップの連鎖に及ぶ。ＮＡＶ値は、送信を衝突及び干渉から保護する。この方法において、２つのＳＴＡ１０間のマルチホップルートが確立された場合には、ペイロードを送信するための遅延は比較的短くなる。
【００１３】
多重リンクを包含するためにＮＡＶ値を拡張することにより、システム全体の容量は、ＢＳＳ帯域幅の大部分がひとつのパケットの送信にいままでより長い時間与えられるために、減少するであろう。しかしながら、多くの場合、２つ又は３つのホップのみが送信用に必要とされるため、容量の減少する時間が延びることはない。
【００１４】
また図２を参照すると、前述の通り補正されたＮＡＶ値を使用して本発明のルーティングプロトコルの実現方法を説明する流れ図が示されている。まず、ステップ３０において、ＳＴＡ  ＡはＳＴＡ  Ｂに送信するパケットを有する。ルート要求メッセージは、ステップ３５において、マルチホップ接続の第１のホップでＳＴＡ  Ａから次のＳＴＡ１０に送信される。ルート要求メッセージは、ステップ４０で第２のＳＴＡ１０に転送され、現在のＳＴＡ１０からＳＴＡ  Ａに戻る最短経路がステップ４５で決定される。最短経路の決定は、ホップの数、累積された経路損失、経験した干渉抵抗、使用中の無線媒体による遅延等の所定のコスト距離で計測される。更に、ステップ５０で、リンク遅延の逆数が、リンク速度がＳＴＡ  ＡとＳＴＡ  Ｂとの間の各ホップについて異なる場合、回線に沿って累積される。
【００１５】
第３のホップリンクにおいて、ルート要求メッセージはステップ５５でＳＴＡ  Ｂに転送される。与えられるルート要求メッセージは、ＳＴＡ  ＡとＳＴＡ  Ｂとの間の各ホップの見込まれるリンク速度から累積されたエンドツーエンドリンク全体の速度のみならず、ＳＴＡ  ＡとＳＴＡ  Ｂとの間の中間ノードの数（この場合は２）と、ＳＴＡ  Ａに戻る最短経路とに関する累積情報を含む。ＳＴＡ  Ｂは、ルート要求メッセージで受信された累積情報を使用し、ＳＴＡ  ＡからＳＴＡ  Ｂへのひとつのパケットの送信時間を表す所要時間値をステップ６０で計算する。所要時間値は、マルチホップ送信を完了するための時間を示す。ＳＴＡ  Ｂは、所要時間フィールド内の計算された所要時間値を含むルーティング応答メッセージをステップ６５で返送する。所要時間フィールドは、反復間隔及び経路決定時間を含んでも良い。反復間隔及び経路決定時間によって、音声等の反復構成を有するトラヒックの経路が反復方式で確立される。ルート応答メッセージが適切な所要時間値及び反復値を送信するために、ルート要求メッセージはパケット長の情報及びいくつかの反復構成のパラメータを送る。更に、各ＳＴＡは、例えば媒体の反復使用のためのパラメータを含むルート要求メッセージ内で媒体が要求されたときに、隣接するＳＴＡによって他の媒体の反復が実行されるように、媒体が利用できることを保証する。
【００１６】
ルーティング応答メッセージは、ステップ７０において、予め使用されたマルチホップルートに沿って第１の中間ＳＴＡ１０から次のＳＴＡ１０に転送される。マルチホップ内のＳＴＡは所要時間値を、ステップ７５でマルチホップリンク内の各ＳＴＡ１０毎にＮＡＶ値を設定するために使用する。これによってＳＴＡ１０は、所要時間値によって示される期間、送信を見合わせる。所要時間値がＳＴＡからのパケット送信を完了する時間を表すため、ＮＡＶ値は、ひとつのホップだけではなく複数のホップについて送信を妨げる。ルーティング応答メッセージは、ステップ８０でＳＴＡ  Ａに返送され、ＳＴＡ  Ａは、各ＳＴＡ１０でＮＡＶ値設定によって保護されているひとつ又は複数のパケットをＳＴＡ  Ｂに返送する。
【００１７】
ここで図３を参照すると、本発明の方法に従って、３つの中間ＳＴＡ１０を使用して４つのホップリンク上でＳＴＡ  ＡからＳＴＡ  Ｂにパケットが送信される、図２に関して説明した方法が更に示される。ステップ３５、４０、５５で前述した通り、ルート応答メッセージ１００は、マルチホップリンク１０５上でＳＴＡ  Ｂに送信される。ルート応答メッセージ１１０は、マルチホップリンク１１５上を、ＳＴＡ  ＢからＳＴＡ  Ａに返送される。経路セットアップ時間を減少させ、かつ遅延の変化を最小にするため、高優先度のルート要求及びルート応答メッセージプロトコルが、更に別の実施形態において、ＳＴＡ  ＡとＳＴＡ  Ｂとの間の最初の送信に関して使用されても良い。
【００１８】
ルート応答メッセージの送信元であるＳＴＡ  Ｂを含む各ＳＴＡでは、所要時間フィールド内の所要時間値は、データパケットをＳＴＡ  ＡからＳＴＡ  Ｂに送信するのに必要な期間、ＳＴＡのＮＡＶ値を設定するのに使用される。ＳＴＡ  Ａにおいてルート応答１１０が返されて受信され、ＮＡＶ設定１２０が中間ＳＴＡ１０毎に設定されると、ＳＴＡ  Ａからのひとつ又は複数のパケットがＳＴＡ  Ｂに送信されても良い。この送信はデータ送信及び確認応答プロセス１２５においてＳＴＡからＳＴＡへと行なわれる。従って、ひとつ又は複数のパケットはＳＴＡ  Ａから第１のＳＴＡ１０ａに第１のホップ上で最初に送信され、ＳＴＡ  Ａはひとつ又は複数のパケット受信の確認応答を受信する。このプロセスは、パケットが最終的にＳＴＡ  Ｂによって受信されかつ確認応答されるまで継続する。最後に、ＳＴＡ  Ｂは、ＥＴＥ確認応答メッセージ１３０をＳＴＡ  Ａに返送し、ＳＴＡ  Ｂでひとつ又は複数のパケットを受信したことを示す。ＳＴＡ  Ａでの確認応答メッセージ１３０の受信後、ＮＡＶ設定は通常レベルに戻っても良く、ＳＴＡ１０は送信を継続しても良い。
【００１９】
更なるステップにおいて、ＳＴＡ  ＡからＳＴＡ  Ｂへの送信が何らかの理由で完了されない場合、又は送信の完了が早すぎる場合、ＮＡＶ値は、ＳＴＡ  ＡとＳＴＡ  Ｂとの間の経路に沿ってクリアされても良い。この場合、追加のクリアメッセージは、ＳＴＡ  ＡからＳＴＡ  Ｂに送信されて、ＳＴＡ１０の各ＮＡＶ値をクリアしても良い。
【００２０】
図２で説明した方法を代替する方法において、メッセージ１００に対するルート要求応答の送信中にＳＴＡ  ＡからＳＴＡ  Ｂへのルートを決定する代わりに、事前のルート決定プロセスにおいてルートを決定しても良い。この場合、ルート要求メッセージ１００のタスクのみが、特定の時刻にＳＴＡ  ＡとＳＴＡＢとの間のマルチリンク経路に沿ってＮＡＶ値を設定することによって媒体を割り当てることになり、経路ルートを決定することは必要ではない。
【００２１】
更に別の方法では、ＳＴＡ  ＡとＳＴＡ  Ｂとの間のエンドツーエンド遅延の全知識は、事前のルート決定プロセスから利用されても良く、ルート要求メッセージは、ルート要求、ルート応答、データ受け取り及び確認応答メッセージの送信を含む、ＳＴＡ  ＡとＳＴＡ  Ｂとの間の通信全体の所要時間を包含する所要時間値を含んでも良い。
【００２２】
図４に示す更なる実施形態において、第１のルート要求１００は、ＳＴＡ  ＡからＳＴＡ  Ｂへの所要時間の事前の計測に基づく、又はＳＴＡ  ＡからＳＴＡ  Ｂへの往復時間の予測に基づく所要時間値を使用しても良い。この情報が、ルート要求メッセージの送信中、中間ＳＴＡでＮＡＶ値を設定するのに使用されることによって、ＳＴＡ  ＢからＳＴＡ  Ａへのルート応答メッセージ１１５のより速い返送が可能となる。プロセスの残りは、図３に関する説明と同様の方法で実行される。ルート要求メッセージ１００は、ＳＴＡ  Ｂへの途中のリンクにおいて使用中の無線媒体による遅延を常時認識できる。ＳＴＡ  Ｂへのリンク経路１０５に沿って、所要時間値は、現行のＩＢＳＳにおいて送信を妨げるＮＡＶ値を設定するために使用される。所要時間値が十分に長い場合、ルート応答メッセージ１１５は、返送経路上において使用中の媒体を認識することはなく、ＳＴＡ  ＡからＳＴＡ  Ｂへのデータ引き渡しの待ち時間を減少させる。
【００２３】
図５に示す更なる実施形態において、ルート要求メッセージ１００は、図３に関する説明と同様に、マルチホップリンク１０５に沿ってＳＴＡ  ＡからＳＴＡ  Ｂに送信される。しかしながら、複数ホップのリンク１１５に沿ったルート応答メッセージ１１０内の所要時間情報は、少し異なる方式で使用される。ＮＡＶ値を設定して、ルート応答メッセージ１１０をＳＴＡ１０が受信する時点からＳＴＡ  Ａがデータの送信を完了し、かつＥＴＥ確認応答メッセージ１３０を受信するまでＳＴＡからの送信を妨げる代わりに、所要時間値内の情報は、ひとつ又は複数のデータパケットが複数ホップのリンクに沿って特定のＳＴＡ１０で受信される時点を推定するのに使用される。ＮＡＶ値は、この時点において送信の完了まで設定されるだけである。これによって、ＩＢＳＳは、ＳＴＡ  ＡからのデータがＳＴＡ１０で実際に受信されるまで他のデータの送信に使用可能となる。従って、ＳＴＡ１０ｂとＳＴＡ  Ｂとの間の送信リンクに関して、データは、ＮＡＶ値設定がポイント１７０で設定されるまで、時間１６５全体に渡って送信されても良い。２つの特定のＳＴＡ間においてデータ及び確認応答手順１２５が開始されると、手順は図３に関して説明した手順と同じとなる。
【００２４】
このように、この着想は、マルチホップの流れの中のパケットが例えば１０ｂとＳＴＡ  Ｂとの間のホップに到達するまでの時間を利用する。
【００２５】
ＲＲＥＱメッセージに対する遅延の合計は、無線リンクのアクセスを勝ち取るための競合時間と、送信時間（見込まれる再送を含む）と、各ＳＴＡ１０がマルチホップの流れに沿って競合等を開始できる状態になるまでの各ＳＴＡ１０内の「中継時間」等を含む。パケットがＳＴＡ１０ｂに到達する時点を予測するために、ＲＲＥＱおよびＲＲＥＳＰ内には各ホップからの詳細な情報が含まれるべきである。次に、１つのホップに対する競合遅延が存在するかどうか、また「中継」遅延がＳＴＡ１０の処理部において一時的なロードのために発生するかどうかが問題である。恐らく、各ＳＴＡは、自身の通常の「中継」遅延をＲＲＥＱに挿入することができる。そのため、少なくとも最短の時間が推定される。従って、無線リンクの遅延を含む各ホップからの詳細及びＳＴＡの中継処理時間は、ＲＲＥＱ及びＲＲＥＳＰメッセージに含まれる。その後、推測は、データが最も早く到着する場合に、各ＳＴＡ１０で行なわれる。
【００２６】
図６の流れ図に関して示す更なる実施形態において、プロトコルは、ルート要求メッセージをステップ１８０でＳＴＡ  ＡからＳＴＡ  Ｂに送信し、かつステップ１８５でＳＴＡ  Ｂからのルート応答メッセージ１１０をＳＴＡ  Ａで受信することによって、ＳＴＡ  ＡとＳＴＡ  Ｂとの間のルートを最初に設定するであろう。次にプロトコルは、ＳＴＡ  ＡからＳＴＡ  Ｂに送信されるパケットが高優先度のアクセス制御方式の使用を必要とするマルチホップ送信かどうかをステップ１９０で決定する。パケットが多重無線ホップによって送信されるかどうかの決定は、パケットのＭＡＣヘッダの４つのアドレスフィールドを解析して、送信元アドレス及び宛先アドレスが同じＩＢＳＳのメンバかどうかを決定することを含む複数の方式で行なわれても良いが、これに限定されない。異なるＩＢＳＳを基礎とするメンバは、高優先度のアクセス制御方式を利用する。あるいは、パケットがより高度なＱｏＳクラスを要求するマルチホップ転送であることを示す新しい情報フィールドがＭＡＣヘッダに挿入されても良い。
【００２７】
しかしながら、この決定は、パケットのマルチホップ転送が必要とされると決定された場合に実行され、パケットは、通常の非マルチホップパケットの場合よりも、ステップ２００においてより高度なＱｏＳクラスを与えられる。これにより、パケットはマルチホップリンク上をより速く送信される。さもなければ、ＱｏＳは変化しないままであり、パケットはステップ２０５において通常の方式で送信される。
【００２８】
本発明の動作及び構成は、前述の説明から明らかであり、ここで示されかつ説明された本発明は特定の実施形態によって特徴づけられるが、記載した請求の範囲に規定されるような本発明の範囲を逸脱すること無しに変化及び変形が可能であると考えられる。
【図面の簡単な説明】
【００２９】
【図１】本発明に従って、別個のＩＢＳＳにおける第１のユニットと第２のユニットとのマルチホップ接続の確立を示す図である。
【図２】本発明に従って、リアクティブルーティングプロトコルを実現する方法を示す流れ図である。
【図３】本発明の第１実施形態の実現を示す図である。
【図４】本発明の別の実施形態を示す図である。
【図５】データが送信される時点に関する予測が使用される、本発明の更に別の実施形態を示す図である。
【図６】高優先度のアクセス構成を使用する、本発明の更に別の実施形態を示す図である。
【図１】
2005504484.tif 000003
【図２】
2005504484.tif 000004
【図３】
2005504484.tif 000005
【図４】
2005504484.tif 000006
【図５】
2005504484.tif 000007
【図６】
2005504484.tif 000008
【国際公開パンフレット】
2005504484.tif 000009
2005504484.tif 000010
2005504484.tif 000011
2005504484.tif 000012
2005504484.tif 000013
2005504484.tif 000014
2005504484.tif 000015
2005504484.tif 000016
2005504484.tif 000017
2005504484.tif 000018
2005504484.tif 000019
2005504484.tif 000020
2005504484.tif 000021
2005504484.tif 000022
2005504484.tif 000023
2005504484.tif 000024
2005504484.tif 000025
【国際調査報告】
2005504484.tif 000026
2005504484.tif 000027
2005504484.tif 000028