JP5039679B2 - 無線メッシュ・ネットワークで隠れ端末のコリジョンを回避するためにランダム遅延を課す方法および装置 - Google Patents

Description

（関連出願の相互参照）
本出願は、その全文が本明細書に援用される、２００７年１０月１７日に出願された米国仮特許出願第６０／９８０６４１号の利益を主張する。

無線ローカル・エリア・ネットワーク（ＷＬＡＮ）がどこにでも見られるようになった。無線ローカル・エリア・ネットワーク（ＬＡＮ）では、非同期分散型ランダム・チャネル・アクセス方法を用いている間、一連のフレームの送信に対して無線チャネルが予約され得る。そのような環境では、送信のソースおよび宛先の両方が、干渉近隣（ｉｎｔｅｒｆｅｒｅｎｃｅ ｎｅｉｇｈｂｏｒｈｏｏｄ）を確立するために予約継続時間をブロードキャストする。

８０２．１１分散型チャネル・アクセスＭＡＣプロトコルによると、送信について近隣者に通知するためにＲＴＳ／ＣＴＳフレームが使用される。送信のソースおよび宛先は、干渉近隣を確立するために予約継続時間を含む、ＲＴＳおよびＣＴＳフレームを、各々、ブロードキャストする。いずれかのフレームを受信するノードは、特定の継続時間の間、送信することまたは送信の受信を承諾することを控える。このやり方によって、「隠れ端末」、ソースによる送信を聞き取ることができず、受信中のノードに干渉する可能性があるノードが、受信するＣＴＳフレームで示される継続時間の間、送信を控える。

チャネルを予約し、無線ＬＡＮの隠れ端末とのコリジョンを回避する１つの方法は、フレームごとの予約を利用することによるものである。ＲＴＳ／ＣＴＳフレームが予約の開始時に送信される。各データ・フレームおよびその後の確認応答に対して予約時間を更新することによって、予約時間がフレームごとに延長される。そのフレームごとの予約の結果、予約が受け入れられない、即ち、ＣＴＳフレームが適時に返されない場合、未使用で残る予約済み時間は存在せず、それゆえに予約は取り消しを必要としない。

無線ＬＡＮで予約を実行する別の方法は、開始から終了まで予約を利用することによるものである。開始から終了まで予約は、ノード（メッシュ点／ＡＰ／局）の任意の組み合わせに適用される。ノードが、単一の宛先に向けて送られる、おそらくは宛先からの応答を含む、送信の全シーケンスを網羅するためにチャネルを予約する。この方法の下では、継続時間フィールド値をフレームの全シーケンスを送信する時間に設定することによってチャネルが予約され得る。予約要求が認可されない、即ち、ＣＴＳフレームが適時に返されない場合、または送信終了後に時間が予約されたまま残っている場合、予約が取り消される必要がある。

チャネルが送信に利用可能であるか否かを決定するためにノードが単一のタイマ、ＮＡＶに依存するため、８０２．１１ＷＬＡＮでは予約の取り消しが問題であり得る。前の予約を超える、チャネルの占有を延長する継続時間フィールドの値を備えるフレームをノードが受信すると、より長い予約を反映するためにＮＡＶタイマが更新される。ノードが異なるソースから複数のＮＡＶ設定フレームを受信することが可能である。例えば、１つの近隣者からＣＴＳフレームを受信し、ＣＴＳを受信していない別の近隣者からＲＴＳを受信することが可能である。ＲＴＳに関連する送信の取り消しは、アイドル中のチャネルをリッスンすることか、ＲＴＳのソースからの明示的な予約の取り消しを受信することによって達成され得る。そのような取り消しに基づいてノードがそのＮＡＶをリセットする場合、ＣＴＳフレームを送信した近隣者に対して、この近隣者がそのＣＴＳフレームに関連する送信をまだ受信している場合、干渉／コリジョンを生じる危険性がある。ＮＡＶ設定要求のソースとは独立に、単一のＮＡＶタイマが保持されているため、予約の取り消しがＮＡＶタイマのリセットを生じさせるかどうかを判定する方法が存在しない。

この欠点にも関わらず、開始から終了までＮＡＶ設定方法は、「隠れ端末」、即ちメッシュ・ネットワークでは近隣者間が長い距離であるために問題が悪化する問題からの保護を提供するために重要である。

ＷＬＡＮは、複数のチャネルおよび複数の無線を含み得る。マルチ・チャネルおよびマルチ無線の両方の能力を提供する１つの手法が、本明細書にその開示が援用される、代理人整理番号第ＡＶＡ０６−０１号である、２００６年３月２９日に出願された、「Ａ Ｐｒｏｔｏｃｏｌ Ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ」と題された同時継続の特許出願に示されており、それは、ＣＣＣ（共通制御チャネル）ＭＡＣプロトコルを説明している。ＣＣＣは、２種類の論理チャネル、制御チャネルおよびデータ・チャネルを利用する。
米国仮特許出願第６０／９８０６４１号 代理人整理番号第ＡＶＡ０６−０１号である、２００６年３月２９日に出願された、「Ａ Ｐｒｏｔｏｃｏｌ Ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ」と題された同時継続の特許出願

上記で説明されたような従来の機構は、種々の欠点がある。そのような欠点の１つは「隠れ端末」問題の結果として生じる。隠れ端末問題は、局が送信機から聞き取ることができず、受信機の干渉の範囲内に存在する場合に生じる。無線メッシュで一例がみられる、ノードが長い距離で分離されているアドホック・ネットワークで、この問題はより重大である。

通常、隠れ端末問題は、ＲＴＳ／ＣＴＳ制御フレームの交換を介して多少とも解決する可能性がある。しかしながら、ノードを分離する距離が長い場合、ＲＴＳ／ＣＴＳペアに関連する送信の受信機の干渉範囲内の近隣者ノードが、ＣＴＳを送信するノードの送信範囲の外側でない可能性があり、それゆえに、ＣＴＳフレームを読み取ることが不可能になる。そのような近隣者は、ＣＴＳが送信される際にそれらのＮＡＶを設定せず、それゆえに受信するノードに干渉を生じる可能性がある。この問題を回避するために、ＲＴＳ／ＣＴＳフレームは、送信範囲を増大させるようにより低い速度で送信され得る。この方法の結果、一連のフレームに対するチャネルの予約が「開始から終了まで」に基づいて行われる必要がある。個々のデータ・フレームは、そのようなフレームが高速で送信され、従ってより短い送信範囲を有するので、予約を増大させるために依拠することができない。

開始から終了までＮＡＶ設定要求の使用は、隠れ端末からの保護に加え、マルチ・チャネル・アクセス制御プロトコルでの異なるチャネルの予約も同様に可能にする。プロトコルの一例はＣＣＣである。利用可能なデータ・チャネルの貯留のうちの１つを予約するために、制御フレームが制御チャネル上で交換される。そのような場合、フレームごとによるチャネルの予約の延長は、非効率になる、制御チャネル上の付加的な制御フレームの交換を必要とする。

上記で説明されたような従来の機構は、種々の欠点がある。そのような欠点の１つは、従来の無線メッシュ・ネットワークで、マルチ・ホップ・フロー上での送信の高い相関は、マルチ・ホップ・フロー上での送信のうちの１つとの隠れ端末コリジョンを経験するフローが、残りのマルチ・ホップ送信によってさらに遅延されるということである。

本発明の実施形態は、そのような欠点を著しく克服し、無線メッシュ・ネットワークでの隠れ端末コリジョンを回避するためにランダム遅延を課す機構および技術を提供する。さらなる遅延を回避するために、マルチ・ホップ経路に沿って各ノードでランダム遅延を課すことによってマルチ・ホップ経路を行き来するフレームの連続的な送信の間の相関を低減し得る。そのような遅延は、他の競合ノードが自分のバックオフをカウントダウンして送信することを可能にするのに充分に長くすべきである。

無線メッシュ・ネットワークで隠れ端末コリジョンを回避するためにランダム遅延を課す方法の特定の実施形態では、方法は、宛先ノードへのマルチ・ホップ経路に沿って、第１のノードから第２のノードに転送することを含む。方法は、第２のノードに関する所定の遅延期間の間、第２のノードからマルチ・ホップ経路の次のホップへのパケットの転送を控えることをさらに含む。さらに、方法は、所定の遅延期間後に第２のノードからマルチ・ホップ経路の次のホップにパケットを転送することを含む。

別の実施形態は、無線メッシュ・ネットワークで隠れ端末コリジョンを回避するためにランダム遅延を課すコンピュータ可読コードを有するコンピュータ可読媒体を含む。コンピュータ可読媒体は、宛先ノードへのマルチ・ホップ経路に沿って、第１のノードから第２のノードに転送する命令を含む。コンピュータ可読媒体は、２のノードに関する所定の遅延期間の間、第２のノードからマルチ・ホップ経路の次のホップへのパケットの転送を控える命令を含む。さらに、コンピュータ可読媒体は、所定の遅延期間後に第２のノードからマルチ・ホップ経路の次のホップにパケットを転送する命令を含む。

さらに別の実施形態は、本発明の実施形態として本明細書で開示されている全ての方法動作を処理するように構成されているコンピュータ化されたデバイスを含む。そのような実施形態では、コンピュータ化されたデバイスは、メモリ・システム、プロセッサ、通信インターフェースを、これらの構成要素を接続する相互接続機構内に含む。メモリ・システムは、本明細書で説明されているように無線メッシュ・ネットワークで隠れ端末コリジョンを回避するためにランダム遅延を課すことを提供し、プロセッサ上で実施される場合（例えば、実行される場合）、コンピュータ化されたデバイス内で本明細書で説明されているように動作し、本発明の実施形態として本明細書で説明されている全ての方法の実施形態および動作を実施するプロセスでコード化されている。従って、本明細書で説明されている処理を実行または実行するようにプログラムされている全てのコンピュータ化されたデバイスは本発明の一実施形態である。

本明細書で開示されている本発明の別の装置は、上記で要約され、以下で詳細が開示されている方法の実施形態のステップおよび動作を実行するソフトウェア・プログラムを含む。詳述すると、コンピュータ・プログラム製品は、コンピュータ化されたデバイスで実行されると、本明細書で説明されているように無線メッシュ・ネットワークで隠れ端末コリジョンを回避するためにランダム遅延を課す関連動作を提供する、符号化されているコンピュータ・プログラム・ロジックを含むコンピュータ可読媒体を有する１つの実施形態である。コンピュータ・プログラム・ロジックは、コンピューティング・システムを用いて少なくとも１つのプロセッサ上で実行される場合、本発明の実施形態として本明細書で示されている動作（例えば、方法）をプロセッサに実行させる。本発明のそのような装置は、通常、ソフトウェア、コード、および／あるいは光学媒体（例えば、ＣＤ−ＲＯＭ）、フロッピー（登録商標）もしくはハード・ディスク、または、１つもしくは複数のＲＯＭ、ＲＡＭもしくはＰＲＯＭチップのファームウェアもしくはマイクロ・コード等の、または特定用途向け集積回路（ＡＳＩＣ）等の、または１つもしくは複数のモジュールにダウンロード可能なソフトウェア・イメージ、共有ライブラリ、その他等の、他の媒体のようなコンピュータ可読媒体上に配置または符号化される他のデータ構造として提供される。本発明の実施形態として本明細書で説明されている技術をコンピュータ化されたデバイスの１つまたは複数のプロセッサに実行させるように、ソフトウェア、ファームウェアまたは他のそのような構成がコンピュータ化されたデバイス上にインストールされ得る。データ通信デバイスのグループで、または他のエンティティで等、コンピュータ化されたデバイスの集合で動作するソフトウェア・プロセスが、本発明のシステムを同様に提供し得る。本発明のシステムは、複数のデータ通信デバイス上の多数のソフトウェア・プロセスの間で分散されてよいし、または全てのプロセスが専用コンピュータの小セットもしくは１つのコンピュータの上で単独で実行されてよい。

本発明の実施形態が、例えばデータ通信デバイス内等で、厳密にソフトウェア・プログラムとして、ソフトウェアおよびハードウェアとして、またはハードウェアおよび／もしくは電気回路単独で実現され得ることを理解されたい。本明細書で説明されているように、本発明の特性は、ニュージャージー州、リンクロフトのＡｖａｙａ社により製造されているもの等、データ通信デバイスおよび／またはそのようなデバイスのためのソフトウェア・システムで採用されてよい。

この開示で説明されている種々の特性、技術、構成、その他の各々が、独立してまたは組み合わせて実行され得ることに留意されたい。従って、本発明は多数の異なるやり方で実現および考案され得る。さらに、本明細書のこの要約の節は、本開示または本願発明の全ての実施形態および／または付加的な新規の態様を特定しないことに留意されたい。その代わりに、この要約は、種々の実施形態の予備的な討論および従来の技術より優れる新規性の一致点を提供する。本発明のさらなる詳細、構成要素、および／または可能な観点（置換）に関して、読者は、以下でさらに議論されている本開示の詳細な説明のセクションおよび対応する図面を参照されたい。

同様の参照文字が異なる図面を通して同じ部分を参照している添付の図面で示されるように、前述は本発明の好適な実施形態のより詳細な説明から明らかになる。図面は縮尺どおりである必要はなく、その代わりに本発明の原理を示すことが強調されている。

無線ＬＡＮは共通制御プロトコル（ＣＣＣ）を利用し得る。ＣＣＣプロトコルは、ＢＳＳまたはメッシュ・ネットワーク内での複数のチャネルの使用を可能にするようにＩＥＥＥ８０２．１１分散型ＭＡＣプロトコルを拡張するＭＡＣプロトコルである。ＣＣＣプロトコルは、分散型優先的競合方式媒体アクセス（ｄｉｓｔｒｉｂｕｔｅｄ ｐｒｉｏｒｉｔｉｚｅｄ ｃｏｎｔｅｎｔｉｏｎ−ｂａｓｅｄ ｍｅｄｉｕｍ ａｃｃｅｓｓ）に基づく適応性のあるチャネル・アクセス・アーキテクチャを規定している。ＣＣＣプロトコルは、２つの論理チャネル機能、制御チャネル（ＣＣ）とデータ・チャネル（ＤＣ）とを区別する。以下の説明では、ＣＣＣ ＭＡＣプロトコルを観測する局またはメッシュ点が「ノード」と呼ばれる。ノードは制御チャネル上で制御および管理フレームを交換する。データ・チャネルはデータ・トラフィックを搬送する。

種々のデータ・チャネル上での送信に対する予約は、制御チャネル上で制御チャネルを交換することによって行われる。レガシーＲＴＳおよびＣＴＳメッセージの延長として、送信機会（ＴＸＯＰ）を送信するのにかかる時間の間、データ・チャネルを予約するためにＣＣ−ＲＴＳおよびＣＣ−ＣＴＳが使用される。ＴＸＯＰは、例えば、ＩＥＥＥ８０２．１１ｅ標準で規定されているような、単一の成功した競合方式チャネル・アクセスの試みに即座に続く、逐次的に送信される一連のフレーム（およびそれらの各確認応答）である。ＴＸＯＰの送信に対して選択される特定のデータ・チャネルは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ上の特定のフィールドで示される。同じ時間間隔の間、複数のデータ・チャネルまたはデータ・チャネルおよび制御チャネルを予約可能であるようにＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの交換が規定され得る。ノードは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの予約継続時間フィールドの値に基づいて、チャネル固有のＮＡＶに予約されているチャネル（単数または複数）の時間の長さの経過を追う。

転送および受信するノードの両方が各使用可能なチャネルに対するＮＡＶを保持する。データ・チャネルの使用中／アイドル状態およびそれらがいつ利用可能になるかを決定するために、ノードは制御チャネルを監視して他のチャネルによって行われる全ての予約の経過を追う。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ上の予約継続時間フィールドが、予約されるチャネルに対するＮＡＶを更新するために使用される。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ予約継続時間フィールドは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳフレームのＭＡＣヘッダの継続時間／ＩＤフィールドとは異なる。後者は、制御チャネル上でのＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ送信の長さを示す。要求されるチャネルが使用中である、またはその無線の全てが使用中であると受信するノードが見なす場合、予約要求が拒否される。

受信するノードは、短フレーム間隔（ＳＩＦＳ）の長さの時間間隔の範囲内でＣＣ−ＣＴＳに応答する。チャネル予約要求の受け入れを示すためにＣＣ−ＣＴＳが送信される。受信するノードによって送信されるＣＣ−ＣＴＳに予約継続時間フィールドに複写される。ＣＣ−ＣＴＳが受信されない場合、転送するノードは予約要求が拒否されたと推測する。受信するノードによって保持されるＮＡＶに従って、予め指定されている時間間隔の範囲内でデータ・チャネルがアイドルになるとＣＣ−ＲＴＳで示されている場合、かつ受信するノードが送信を受信する利用可能な無線を有する場合、予約が受け入れられる。データ・トラフィック送信の成功した受信の後に、ＥＤＣＡ規則に従ってデータ・チャネル上で、または制御チャネル上でのグループ確認応答としてのいずれかで、確認応答が送信される。

利用されている異なるフレームは、ＴＸＯＰを開始するノードで使用されるＣＣ−ＲＴＳフレームを含む。このフレームは、ソース・ノード、宛先ノード、ソース・ノード送信チャネル、ＴＸＯＰのフレームの継続時間および数を含む複数のフィールドを含む。ＣＣ−ＣＴＳフレームは、ＴＸＯＰを受け入れるノードによって使用される。ＣＣ−ＣＴＳフレームは、宛先ノード、ソース・ノード、ソース・ノード送信チャネル、継続時間、ＴＸＯＰのフレームの数および無線カウンタを含む複数のフィールドを含む。ＣＣ−ＡＣＫフレームは、成功裏に受信された、一連のフレームのうちの個々のフレームを特定する。ＣＣ−ＡＣＫフレームは、宛先ノード、ソース・ノードおよびＴＸＯＰフレーム受信状態を含む。

チャネル予約は、データ・チャネルに対するＣｈａｎｎｅｌ＿Ｓｔａｔｅ指示がアイドルであるという条件で、ソース・ノードがＣＣ−ＲＴＳフレームを制御チャネル上で宛先ノードに送信することによってそのデータ・チャネルを１つまたは複数のフレームに対して予約する場合に生じる。予約継続時間フィールドおよびＴＸＯＰフレームの数はＣＣ−ＲＴＳに設定される。宛先ノードは応答してＳＩＦＳ内でＣＣ−ＣＴＳを送信する。宛先ノードがソース・ノードのデータ・チャネルに対するＣｈａｎｎｅｌ＿Ｓｔａｔｅアイドル指示を有し、宛先ノードが送信を受信する利用可能な無線を有する、即ち、無線カウンタが非ゼロである場合に、予約要求が受け入れられる。予約要求が宛先ノードで受け入れられる場合、予約継続時間フィールドが調整され、ＴＸＯＰのフレームの数が宛先ノードによって送信されるＣＣ−ＣＴＳで繰り返され、ＣＣ−ＣＴＳは、トラフィックを受信するのに利用可能のままであるその無線の数−即ち、無線カウンタを含む。（後者は不可欠ではないが、他のノードが宛先ノードにフレームを送信するのに有用である）。予約要求が宛先ノードによって拒否される場合、ＣＣ−ＣＴＳの予約継続時間フィールドが０に設定され、その場合のソース・ノードは、予約継続時間が０に設定されている別のＣＣ−ＲＴＳを送信する。さらに、宛先ノードは、予約継続時間が０に設定されているＣＣ−ＲＴＳに応答して、予約継続時間フィールドが０に設定されているＣＣ−ＣＴＳを送信する。

ＴＸＯＰの全てのフレームが送信されると、宛先ノードはＣＣ−ＡＣＫと呼ばれる確認応答を制御チャネル上に送信することによって送信シーケンスの状態を知らせる。成功裏に受信されたフレームは、ＣＣ−ＡＣＫで特定される。肯定応答が最高のアクセス優先度での競合により送信される。

隠れ端末から保護するために、メッシュ・ネットワークは全部のＴＸＯＰに対してＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ予約を必要とする。予約要求（ＣＣ−ＲＴＳ）が拒否される場合、予約されるチャネル時間の無駄を回避するためにソース・ノードは予約を取り消す必要がある。宛先ノードは、予約継続時間が０であるＣＣ−ＣＴＳを返すことによってＣＣ−ＲＴＳの拒否を示す。最初のＣＣ−ＲＴＳを聞き取った近隣者ノードに通知するために、ソース・ノードによって第２のＣＣ−ＲＴＳが送信される。ＮＡＶのリセットによって他の全ての未処理のＮＡＶ設定要求の取り消しが生じるので、近隣者のＮＡＶのリセットは回避される必要がある。従って、ＮＡＶ方法は、ＮＡＶのリセットを回避するように修正される。

隠れノードは、それが聞き取ることができない送信の受信に干渉する可能性があるノードである。局が互いに聞き取ることが可能なＷＬＡＮでは、隠れノード問題がＣＣ−ＲＴＳ／ＣＣ−ＣＴＳを使用することによって処理される。しかしながら、ＷＬＡＮメッシュでのノードの場合のように、もし送信するノードと受信するノードとが充分に分離されているならば、干渉範囲が送信範囲よりも長いため、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳが効果的でない。送信範囲は、全てのノードがその範囲内で送信を聞き取ることが可能であり、それを復号することが可能な範囲である。隠れノードは、送信の宛先ノードの干渉範囲内だが、送信範囲の外側にみつけられる。図１に示されるメッシュを考えられたい。無線ネットワーク１０は複数のノード、ノード１〜６を含む。ノード１は、関連送信範囲（ＴＸ範囲）１４および関連干渉範囲１２を有する。メッシュの空間的配置に起因して、ノードが隠れノードとして振舞う可能性がある。ノード１の干渉範囲１２は、その内部でノードの既存の通信が、ノード１からの送信によって中断される可能性がある範囲である。ノード１のＴｘ範囲１４は、その内部で全てのノードがノード１からの送信を聞き取ることが可能であり、パケットを復号することが可能である範囲である。

ノード１はノード２にＣＣ−ＲＴＳを送信し、ノード２はＣＣ−ＣＴＳで応答する。ノード２の干渉範囲内にあるノード３および５は、ノード２の送信範囲内でなく、そのため、それらはＣＣ−ＣＴＳを聞き取らない。ＢＳＳの場合と同様に、隠れノードに対して保護するために、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳが使用される必要がある。離れている距離はノードに干渉する可能性があるため、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳがメッシュ・トラフィック・フレームではなくより堅固なＰＨＹモードで送信される必要がある。即ち、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳがメッシュ・トラフィックよりも高い送信電力または低いデータ転送速度のいずれかで送信される。このやり方で、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳに関する送信範囲がメッシュ送信の干渉範囲と同様になり得る。次に、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳが干渉範囲で受信されて読まれ得る。予約は、開始から終了まで予約を使用して全部のＴＸＯＰに対して行われる必要がある。

隠れノードを回避するためのＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの使用は、ＴＸＯＰ（それらの間がＳＩＦＳアイドルの間隔で送信される一連のフレーム）を送信する場合の予約の取り消しで問題を生じさせる。８０２．１１ｅ案によれば、ＴＸＯＰの送信に対してチャネル時間を予約する２つの方法が存在する。一方は全部のＴＸＯＰの予約継続時間に対してチャネルを予約することであり、他方は１回に１つのフレームに対してチャネルを予約することである。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳが必要であるため、単一のＣＣ−ＲＴＳ／ＣＣ−ＣＴＳが全部のＴＸＯＰ継続時間に対してチャネルを予約する。予約要求が受け入れられない場合、予約されたチャネルを他の送信に対して使用可能にするためにＴＸＯＰに対する予約が取り消される必要がある。

ＣＣＣ ＭＡＣプロトコルでは、ゼロに設定されている予約継続時間フィールドを含む転送するノードから第２のＣＣ−ＲＴＳによって予約の拒否の通知が全てのノードに伝達される。転送するノードには、予約継続時間フィールドがゼロに設定されているＣＣ−ＣＴＳを受信する際に、要求の拒否が通知される。８０２．１１ＮＡＶ規則によると、継続時間フィールドが非ゼロであるフレームを聞き取るノードは、チャネルが、全ての前のＮＡＶ設定要求と同様に新規の継続時間値の満期を占めるようにそのＮＡＶを更新する。ＮＡＶは、それゆえに異なるソースからの複数のＮＡＶ設定要求の合成物である。

前のＮＡＶ設定要求の取り消しの通知を聞き取ったノードは、ＮＡＶを単純にリセットすることが不可能である。互いに聞き取ることが不可能なノードからの同じチャネルに対する複数のＮＡＶ設定要求をノードが聞き取ることが可能であるため、他のＮＡＶ設定要求が未処理であり得る。チャネルのＮＡＶを取り消すことは、従って、コリジョンをもたらす可能性がある。ＣＣ−ＲＴＳを介して予約が探される場合のチャネルのＮＡＶを設定するための異なるやり方が以下で説明されている。新規のＮＡＶ設定手法は、予約が取り消された場合にＮＡＶをリセットする必要性を取り除く。

無線チャネルは、ＣＳＭＡ／ＣＡを使用する間、一連のシーケンスの送信に対して予約がされ得る。干渉近隣を確立するために、送信のソースおよび宛先の両方が予約継続時間をブロードキャストする。上述したように、および図２で示されるように、予約がフレームごとに行われてよい。８０２．１１分散型チャネル・アクセスＭＡＣプロトコルによると、予約の開始について近隣者に通知するためにＲＴＳ／ＣＴＳフレームが使用される。各データ・フレームおよびその後の確認応答を用いて予約の予約継続時間を更新することによって、予約時間がフレームごとに延長される。このシナリオ２０では、ＮＡＶが１回に１フレーム設定される。データ・フレームの継続時間フィールドは、ＮＡＶを拡張するために使用される。次のフレーム２６およびそのＡＣＫ２８の継続時間の間、ＲＴＳ２２がＮＡＶ３４ａを設定する。ＲＴＳ２２に応答してＣＴＳ２４が返されると、データ・フレーム２６の送信が短フレーム間隔（ＳＩＦＳ）で開始する。データ・フレーム２６の継続時間フィールドは、次のデータ・フレーム３０およびＡＣＫ３２の継続時間の間、ＮＡＶ３４ｂを拡張する。予約が拒否される場合、予約の取り消しが要求されない。

次に図３を参照すると、全部のシーケンスに対して単一のＲＴＳ／ＣＴＳでチャネルの予約が行われ得る。チャネルが全部のＴＸＯＰに対して予約されている。ＲＴＳ４２の継続時間フィールドは、データ・フレーム４６および５０、ならびにＡＣＫ４８および５２に対して必要な時間に設定される。一度、ＣＴＳ４４が返されると、データ・フレーム４６および５０ならびにＡＣＫ４８および５２の送信がＳＩＦＳ時間で開始する。予約要求が拒否される場合、または送信の完了で時間が予約されたままである場合、残りの予約時間が取り消しされる必要がある。

図４で示されるように、ＲＴＳ５８がＮＡＶをＴＸＯＰの予約継続時間値に設定する。予約が受け入れられない場合（５８）、チャネルの使用を許可するためにＮＡＶの残りの予約時間が取り消されるべきである。

次に図５を参照すると、隠れノードを回避するために、２段階ＮＡＶ設定プロセスが利用されている。ＮＡＶは、他のノードがチャネル上での送信を控える必要のある期間である。コリジョンを回避するために、各ノードは、受信される予約要求および応答に従って設定されているＮＡＶを保持する。予約は、予約継続時間が予約の長さに設定されているＣＣ−ＲＴＳ６２で要求される。宛先ノードは、予約継続時間がゼロに設定されているＣＣ−ＣＴＳ６８を返すことによってＣＣ−ＲＴＳ６２の拒否を示す。最初のＣＣ−ＲＴＳ６２を聞き取った近隣者ノードに通知するために、予約継続時間がゼロに設定されている第２のＣＣ−ＲＴＳ６９がソース・ノードによって送信される。このシナリオ６０では、ＮＡＶが第１の段階の継続時間６４、ＣＣ−ＣＴＳ／ＣＣ−ＲＴＳハンドシェイクの予約継続時間にだけ設定される。ゼロの予約継続時間を有するＣＣ−ＣＴＳ６８の受信により予約が取り消されるため、ＮＡＶは第２の段階６６の間、拡張されない。ＣＣ−ＣＴＳまたは別のフレームに応じて、予約継続時間フィールドに従ってＮＡＶが更新される。受信されるフレームの予約継続時間のフィールドがその満了時間の延長を必要とする場合に、ＮＡＶが更新される。図５で、予約継続時間がゼロに設定されている同じＭＰから第２のＣＣ−ＲＴＳが聞き取られると、ＴＸＯＰに対する最初の予約が取り消され、それゆえに、ＮＡＶはＣＣ−ＲＴＳＨＳＨＫの初期設定を超えて拡張されない。

次に図６を参照すると、予約が取り消されない場合の２段階ＮＡＶが示されている。このシナリオ７０では、ＮＡＶは、ＣＣ−ＣＴＳ／ＣＣ−ＲＴＳハンドシェイク７４の予約継続時間に対して更新される。ＣＣ−ＲＴＳ７２を受信する局は、予約継続時間フィールドの全部の値に対してそのチャネルのＮＡＶを更新しないが、長さＣＣ−ＲＴＳＨＳＨＫ７４の時間間隔の間に対してだけ更新する。ＣＣ−ＲＴＳ７２が取り消されない（例えば、ゼロよりも大きい予約継続時間値を有するＣＣ−ＣＴＳ６８を受信することによって）場合、ＮＡＶは、初期のＣＣ−ＲＴＳ７２予約継続時間の残り７６に対して更新される。予約が取り消されず、それゆえに、初期のＣＣ−ＲＴＳ７２の全部の予約継続時間を網羅するようにＮＡＶが拡張される。

ソース・ノードからのＣＣ−ＲＴＳ７２は、時間ＣＣ−ＲＴＳＨＳＨＫに対してＮＡＶを更新する。この期間ＣＣ−ＲＴＳＨＳＨＫは、ＣＣ−ＣＴＳ送信時間にＣＣ−ＲＴＳ送信時間を加え、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳに関連する２つのＳＩＦＳに関する時間を加えたもの（ＣＣ−ＣＴＳＴｘ時間＋ＣＣ−ＲＴＳＴｘ時間＋２×ＳＩＦＳ）を含む。時間間隔ＣＣ−ＲＴＳＨＳＨＫが経過した後に主たるＮＡＶタイマを更新するためにバックグラウンドのタイマが使用される。時間間隔ＣＣ−ＲＴＳＨＳＨＫの間に複数のＣＣ―ＲＴＳフレームが受信される場合、局は受信される各ＣＣ−ＲＴＳの対（ソースＩＤ、予約継続時間）を記憶している必要がある。この情報は、ＮＡＶが全部のＣＣ−ＲＴＳ予約継続時間に対して更新されるまで記憶されている必要がある。局は、限られた数のＣＣ−ＲＴＳ、最長の残余予約継続時間を備えるものに対する情報を保持してよい。

要約すれば、ＣＣ−ＲＴＳを聞き取る場合にチャネルのＮＡＶが２段階で設定される。初期のＣＣ−ＲＴＳを受信すると、ノードは、ＣＣ−ＣＴＳおよび別のＣＣ−ＲＴＳを送信するのに必要な時間間隔ＣＣ−ＲＴＳＨＳＨＫに関する特定のチャネルに対してＮＡＶを更新する。取り消しＣＣ−ＲＴＳが受信されない場合、ノードは次に、ＮＡＶを初期のＣＣ−ＲＴＳで示される残りの予約継続時間値、またはその後のＣＣ−ＲＴＳで示される拡張された予約継続時間値に設定する。予約が拒否される場合、ＮＡＶはさらなる動作を必要とせずに終了する。

本発明が複数のチャネルを有するＷＬＡＮに対して説明されてきたが、単一のチャネルだけが使用されているシナリオに同様の概念が適用される。この単一チャネルのシナリオでは、近隣者ノードは予約が取り消される場合に警告される必要がある。ＮＡＶ消去機構は、標準の任意選択的な機構であり、局がそのＮＡＶを更新するために、ＲＴＳフレームからの情報を最も最近の基準として使用し、２ＳＩＦＳ＋ＣＴＳ＿ｄｕｒａｔｉｏｎ＋２Ｓｌｏｔｔｉｍｅの間信号が検出されない場合、局がそのＮＡＶを消去することを可能にする（ＩＥＥＥ８０２．１１：９．２．５．４）。これは、４方向ハンドシェイクが完了されない場合のチャネルの再使用を可能にする。ＮＡＶ消去によって生じるコリジョンを回避するために、以下が使用される。局は、ＣＴＳの継続時間が終了したか否かを記憶している。そうでない場合、ＣＴＳは「保留」である。継続時間フィールドが非ゼロである新規のＣＴＳが到達すると、フラグＣＴＳ＿ＰＥＮＤＩＮＧが設定される。ＮＡＶが完了すると、フラグが消去される。チャネルが特定の時間間隔の間、アイドルであり、フラグＣＴＳ＿ＰＥＮＤＩＮＧが消去されている場合、局はそのＮＡＶを消去する。フラグＣＴＳ＿ＰＥＮＤＩＮＧが設定されている場合、局はＮＡＶを消去しない。これは、ＮＡＶ消去によって生じるコリジョンの回避を可能にする。

マルチ・ホップ・フローの送信の高い相関は、マルチ・ホップ・フロー上の送信のうちの１つとの隠れ端末コリジョンを経験するフローが、残りのマルチ・ホップ送信によってさらに遅延されることを生じさせる。さらなる遅延を回避するために、マルチ・ホップ経路に沿って各ノードでランダム遅延を課することによって、マルチ・ホップ経路を行き来するフレームの連続的な送信の間の相関を低減し得る。そのような遅延は、他の競合ノードがそのバックオフをカウントダウンして送信するのに充分に長くすべきである。

ランダム遅延は以下のようにして導入され得る。転送するノードでのバックオフに対してのより広いコンテンション・ウィンドウは、隠れ端末コリジョンを経験する別のフローに対してチャネル上に乗る機会を提供し得る。例えば、最優先アクセス・カテゴリに対する初期のコンテンション・ウィンドウの初期設定サイズは８に設定され、各再送信の試みに対して２倍にされる。転送する必要のあるフレームを受信するノードは、１６のコンテンション・ウィンドウから開始されてよく、各再送信の試みに対して４倍にされる。転送するノードでのコンテンション・ウィンドウ・オフセット（最低バックオフ可能性）は、チャネルにアクセスする前の最小の待機を確実にし得る。例えば、転送する必要のあるフレームを受信するノードは、時間スロットに２００マイクロ秒相当を付加し、バックオフを遅延をランダムにし、フレームを送信する前に引くべきである。チャネルが他のフローによる使用に対して自由である時間を増大させるために、転送するノードがバックオフを行う前に予め特定された待機時間が必要であるべきである。例えば、転送する必要のあるフレームを受信するノードは、２００マイクロ秒の間、バックオフを呼び出すべきでない。受信されるフレームの処理が、この待機時間の間に行われ得る。

現在開示されている方法のフローチャートが図７Ａおよび７Ｂに示されている。本明細書で長方形の構成要素は、「処理ブロック」と表示され、コンピュータ・ソフトウェア命令または命令グループを示している。代替的に、処理および決定ブロックが、デジタル信号プロセッサ回路または特定用途向け集積回路（ＡＳＩＣ）等の機能的に同等の回路によって実行されるステップを示す。フロー図は、あらゆる特定のプログラミング言語の構文を示していない。むしろ、フロー図は、当業者が、本発明により必要とされる処理を実行するための、回路を製造するために、またはコンピュータ・ソフトウェアを生成するために必要な機能的な情報を示す。ループおよび変数の初期化ならびに一時的変数の使用等の多数のルーチン・プログラム構成要素が示されていないことに留意されたい。本明細書で特に示す場合を除き、説明されている特定の一連のステップは単に例示的なものであり、本発明の精神から逸脱することなしに変更され得ることを当業者は理解するであろう。従って、以下で説明されているステップは、特に言及する場合を除き、非順序的であり、その意味は、可能である場合に複数のステップがあらゆる都合の良いまたは所望の順序で実行され得ることである。

次に図７Ａおよび７Ｂを参照すると、無線メッシュ・ネットワークで隠れ端末コリジョンを回避するためにランダム遅延を課する方法１００が示されている。方法１００は、宛先ノードへのマルチ・ホップ経路に沿って、第１のノードから第２のノードにパケットを転送することを開示する処理ブロック１０２で開始する。

処理ブロック１０４は、第２のノードに対する所定の遅延期間の間、パケットを第２のノードから、マルチ・ホップ経路の次のホップにパケットを転送することを控えることを提示している。処理ブロック１０６、１０８、１１０および１１２で示されるように、所定の遅延期間は種々の形式で提供され得る。処理ブロック１０６は、第２のノードに対する所定の遅延期間が、別のノードの送信を可能にするために充分な長さであることを語っている。処理ブロック１０８は、第２のノードに対する所定の遅延期間が、第２のノードでのバックオフに対してより広いコンテンション・ウィンドウの使用を含むことを開示している。処理ブロック１１０は、第２のノードに対する所定の遅延期間が所定の時間を第２のノードでのバックオフに対するコンテンション・ウィンドウに付加することを含むことを述べている。処理ブロック１１２は、第２のノードに対する所定の遅延期間が第２のノードでのバックオフに対するコンテンション・ウィンドウを適用する前に所定の待機時間、待機することを含むことを語っている。

処理ブロック１１４は、所定の遅延期間の後に第２のノードによりマルチ・ホップ経路の次のホップにパケットを転送することを開示している。

処理は、宛先ノードへのマルチ・ホップ経路に沿って、第３のノードで第２のノードからのパケットを受信することを述べている処理ブロック１１６で継続する。

処理ブロック１１８は、第３のノードに対する所定の遅延期間の間、第２のノードからマルチ・ホップ経路の次のホップにパケットを転送することを控えることを述べている。処理ブロック１２０、１２２、１２４、１２６および１２８で示されるように、所定の遅延期間は種々の形式で提供され得る。処理ブロック１２０は、第３のノードに対する所定の遅延期間が、別のノードが送信を可能にするために充分な長さであることを語っている。処理ブロック１２２は、第３のノードに対する所定の遅延期間が第３のノードでのバックオフに対してより広いコンテンション・ウィンドウの適用を含むことを開示している。処理ブロック１２４は、第３のノードに対する所定の遅延期間が所定の時間を第３のノードでのバックオフに対するコンテンション・ウィンドウに付加することを含むことを述べている。処理ブロック１２６は、第３のノードに対する所定の遅延期間が第３のノードでのバックオフに対するコンテンション・ウィンドウを適用する前に所定の待機時間、待機することを含むことを語っている。処理ブロック１２８は、第３のノードに対する所定の遅延期間が第２のノードに対する所定の遅延期間よりも大きいことを開示している。

処理ブロック１３０は、第３のノードに対する所定の遅延期間の後に第３のノードによりマルチ・ホップ経路の次のホップにパケットを転送することを述べている。

図８は、ホスト・コンピュータ・システム２４０として構成されているコンピュータ・システムの例示的なアーキテクチャを示す。コンピュータ・システム２４０は、パーソナル・コンピュータ、ワークステーション、携帯型コンピューティング・デバイス、メインフレーム、サーバ等のような任意の種類のコンピュータ化されたシステムであってよい。この例では、メモリ・システム２１２、プロセッサ２１３、および通信インターフェース２１４を結合する相互接続機構２１１をシステムが含む。通信インターフェース２１４は、コンピュータ・システム２４０が外部のデバイスまたはシステムと通信することを可能にする。

メモリ・システム２１２は、上記で説明されたようにエージェント２５５に関する本発明の実施形態の機能性を処理することを実現するデータおよび／または論理命令（例えば、メモリ、またはディスク等の別のコンピュータ可読媒体上に記憶されている）等のソフトウェア・コードを示すアプリケーション２５５−Ａで符号化されている任意の種類のコンピュータ可読媒体であってよい。プロセッサ２１３は、対応するエージェント処理２５５−Ｂを作成するためにホストに関するアプリケーション２５５−Ａの論理命令を起動、実行、遂行、解釈、またはそれ以外のやり方で実行するために、相互接続機構２１１を介してメモリ・システム２１２にアクセスすることが可能である。換言すると、エージェント・プロセス２５５−Ｂは、コンピュータ・システムのプロセッサ２１３内または上で実行されるエージェント・アプリケーション２５５−Ａの１つまたは複数の部分を示す。前述の例で説明されているように動作するエージェント２５５は、図８でエージェント２５５−Ａおよび／またはプロセス２５５−Ｂにより示されていることに留意されたい。

本発明の実施形態は、フロッピー（登録商標）・ディスク、ハード・ディスク等のコンピュータ可読媒体内で、光学媒体で、またはファームウェア、読み出し専用メモリ（ＲＯＭ）の、もしくは、この例では、（例えば、ランダム・アクセス・メモリまたはＲＡＭ内の）メモリ・システム２１２内の実行可能コード等のメモリ型システムで、符号化されているアプリケーション（即ち、非実施または不実行の論理命令および／またはデータ）を含むことに留意されたい。さらに、本発明の別の実施形態が、プロセスとしてプロセッサ２１３内で動作するアプリケーションを提供し得ることを理解されたい。この例では示されていないが、当業者は、コンピュータ・システムが、本発明の説明を容易化するために除外されているオペレーティング・システム等の他のプロセスおよび／またはソフトウェアならびにハードウェア構成要素を含み得ることを理解するであろう。

プロセッサ（単数または複数）と一体化されているデバイス（単数または複数）またはコンピュータ・システムは、例えば、パーソナル・コンピュータ（単数または複数）、ワークステーション（単数または複数）（例えば、Ｓｕｎ社、ＨＰ社）、携帯情報端末（単数または複数）（ＰＤＡ（単数または複数））、携帯電話（単数または複数）、ラップトップ・コンピュータ（単数または複数）、携帯型コンピュータ（単数または複数）等の携帯型デバイス（単数または複数）、または本明細書で提供されるように動作し得るプロセッサ（単数または複数）と一体化されることが可能な別のデバイス（単数または複数）を含んでよい。従って、本明細書で提供されるデバイスは網羅的ではなく、限定ではなしに例示として提供されている。

「マイクロプロセッサ」および「プロセッサ」、または「このマイクロプロセッサ」および「このプロセッサ」への言及は、スタンドアロンおよび／または分散型環境（単数または複数）で通信し得る１つまたは複数のマイクロプロセッサを含んでよく、従って、他のプロセッサと有線もしくは無線通信を介して通信するように構成されていてよく、そのような１つまたは複数のマイクロプロセッサが同様のまたは異なるデバイスであり得る１つまたは複数のプロセッサ制御デバイス上で動作するように構成されていてよいことを理解されたい。そのような「マイクロプロセッサ」または「プロセッサ」の専門用語の使用は、従って、中央処理装置、算術論理装置、特定用途向け集積回路（ＩＣ）、および／またはタスク・エンジンを含んでよく、そのような例は、限定ではなく例示として提供されていることをさらに理解されたい。

さらに、メモリへの言及は、特に言及する場合を除き、プロセッサ制御デバイスの内部もしくはプロセッサ制御デバイスの外部にあり得て、および／または種々の通信プロトコルを使用して有線もしくは無線ネットワークでアクセスされ得て、特に言及する場合を除き、外部および内部のメモリ・デバイスの組み合わせを含むように配置され得て、そのようなメモリがアプリケーションに基づいて隣接および／または分離されていてよい、１つまたは複数のプロセッサ可読およびアクセス可能なメモリ素子をおよび／または構成要素を含んでよい。従って、データベースへの言及は、１つまたは複数のメモリ集団を含んでよく、そのような言及が市販のデータベース製品（例えば、ＳＱＬ、Ｉｎｆｏｒｍｉｘ、Ｏｒａｃｌｅ）および独自仕様のデータベースを含んでよく、さらに、限定ではなしに例示として提供される構造であるリンク、キュー、グラフ、ツリー等の関連メモリに対する別の構造を含んでよいことを理解されたい。

ネットワークへの言及は、特に規定する場合を除き、１つまたは複数のイントラネットおよび／またはインターネット、ならびに仮想ネットワークを含んでよい。本明細書でのマイクロプロセッサ命令またはマイクロプロセッサ実行可能命令への言及は、上記に従って、プログラム可能ハードウェアを含むことを理解されたい。

特に言及する場合を除き、用語「実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）」は、正確な関係、状況、配置、方向、および／または他の特性、ならびに、開示されている方法およびシステムに実質的に影響を及ぼさない限りにおいて当業者が理解する逸脱である、それらの逸脱、を含むように解釈されてよい。

本開示の全文を通じて、名詞を修飾する冠詞「１つの（ａ）」または「１つの（ａｎ）」の使用は、便益のために使用されているものであり、特に言及する場合を除き、１つまたは複数の、修飾されている名詞を含むことを理解されたい。

他の何かと通信する、関連する、および／または基づくように、本明細書で説明されているか、または、それ以外の方法で図面を介して表現されている、素子、構成要素、モジュール、および／またはそれらの部分は、本明細書で特に明記する場合を除き、直接的および／または間接的なやり方でそのように通信し、関連し、および基づくことを理解されたい。

方法およびシステムがそれらの特定の実施形態に関して説明されてきたが、それらはそのように限定されていない。明らかに、上記の教示の観点から多くの修正および変更が明白になるであろう。本明細書で説明および例示されている、詳細、材料、部分の配置の多くの付加的な変更が、当業者によりなされ得る。

本発明の好適な実施形態を説明したことによって、これらの概念が組み込まれている別の実施形態が使用され得ることが今や当業者には明白になるであろう。さらに、本発明の一部として含まれているソフトウェアは、コンピュータ使用可能媒体を含むコンピュータ・プログラム製品で実現され得る。例えば、そのようなコンピュータ使用可能媒体は、コンピュータ可読プログラム・コード・セグメントを有する、ハード・ドライブ・デバイス、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはコンピュータ・ディスケット等の可読メモリ・デバイスを含んでよい。コンピュータ可読媒体は、光学的、有線もしくは無線のいずれかで、デジタルもしくはアナログ信号としてプログラム・コード・セグメントを担持する通信リンクをさらに含んでよい。従って、本発明は、説明されている実施形態に限定されるべきではなく、むしろ、添付の特許請求の範囲の精神および範疇によってのみ制限されるべきであると考えられる。

無線ネットワークのノードの送信範囲および干渉範囲を示す無線ネットワークの説明図である。 無線ネットワークでの従来のフレームごとの予約のタイミング図である。 無線ネットワークでの従来の開始から終了まで予約のタイミング図である。 予約の取り消しの必要性を示すタイミング図である。 本発明の実施形態による、予約が取り消された場合の２段階の予約を示すタイミング図である。 本発明の実施形態による、予約が取り消されない場合の２段階の予約を示すタイミング図である。 本発明の実施形態による、無線ネットワークで隠れ端末を保護する方法のフロー図である。 本発明の実施形態による、無線ネットワークで隠れ端末を保護する方法のフロー図である。 本発明の実施形態により動作するノードのブロック図である。

Claims (9)

1. 宛先ノードへのマルチ・ホップ経路に沿って、第１のノードから第２のノードにパケットを転送するステップと、
   前記第２のノードに対する所定の遅延期間の間、前記第２のノードから前記マルチ・ホップ経路の次のホップに前記パケットを転送することを控えるステップと、
   前記所定の遅延期間の後に前記第２のノードにより前記マルチ・ホップ経路の前記次のホップに前記パケットを転送するステップであって、前記第２のノードに対する前記所定の遅延期間は、他のノードが隠れ端末コリジョンを受けながら送信することを可能にするのに充分な長さであり、隠れ端末は他のノードの送信範囲外のノードを含むが前記他のノードの干渉範囲内にあるステップとを含む、方法。
2. 前記第２のノードに対する前記所定の遅延期間は、前記第２のノードでのバックオフに対するより広いコンテンション・ウィンドウの使用を含む、請求項１に記載の方法。
3. 前記第２のノードに対する前記所定の遅延期間は、前記第２のノードでのバックオフに対するコンテンション・ウィンドウに所定の時間を付加するステップを含む、請求項１に記載の方法。
4. 前記第２のノードに対する前記所定の遅延期間は、前記第２のノードでのバックオフに対するコンテンション・ウィンドウを適用する前に所定の待機時間、待機するステップを含む、請求項１に記載の方法。
5. 宛先ノードへの前記マルチ・ホップ経路に沿って、第３のノードで前記第２のノードからの前記パケットを受信するステップと、
   前記第３のノードに対する所定の遅延期間の間、前記第３のノードから前記マルチ・ホップ経路の次のホップに前記パケットを転送するステップを控えることと、
   前記第３のノードに対する前記所定の遅延期間の後に前記第３のノードにより前記マルチ・ホップ経路の前記次のホップに前記パケットを転送するステップとをさらに含む、請求項１に記載の方法。
6. 前記第３のノードに対する前記所定の遅延期間は、別のノードが送信することを可能にするのに充分な長さである、請求項５に記載の方法。
7. 前記第３のノードに対する前記所定の遅延期間は、前記第３のノードでのバックオフに対するより広いコンテンション・ウィンドウの使用を含む、請求項５に記載の方法。
8. 前記第３のノードに対する前記所定の遅延期間は、前記第３のノードでのバックオフに対するコンテンション・ウィンドウに所定の時間を付加するステップを含む、請求項５に記載の方法。
9. 前記第３のノードに対する前記所定の遅延期間は、前記第３のノードでのバックオフに対するコンテンション・ウィンドウを適用する前に所定の待機時間、待機するステップを含む、請求項５に記載の方法。

Images