(57)【要約】  無線ローカル・エリア・ネットワーク内の露出ノードを回避するための方法、装置およびコンピュータ・プログラム製品が提示される。この方法は、設定される場合、ノードがチャネル上のそれ自体への送信を許可することを防ぐ、チャネルの第１のタイマ（ＮＡＶ＿ＲＴＳ）をノードで維持するステップと、設定される場合、ノードがチャネル上で送信することを防ぐチャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）をノードで維持するステップとを含む。この方法はさらに、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときにＮＡＶ＿ＲＴＳを更新するステップと、０より大きく、かつＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときにＮＡＶ＿ＣＴＳを更新するステップとを含む。
2009510803.tif 000002
【特許請求の範囲】
【請求項１】
設定される場合、ノードがチャネル上のそれ自体への送信を許可することを防ぐ前記チャネルの第１のタイマ（ＮＡＶ＿ＲＴＳ）を前記ノードで維持するステップと、
設定される場合、前記ノードが前記チャネル上で送信することを防ぐ前記チャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）を前記ノードで維持するステップと、
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときに前記ＮＡＶ＿ＲＴＳを更新するステップと、
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときに前記ＮＡＶ＿ＣＴＳを更新するステップとを含む方法。
【請求項２】
０に等しい予約期間値を有するＣＣ−ＲＴＳフレームが受信されるときに前記ＮＡＶ＿ＲＴＳの更新を控えるステップをさらに含む請求項１に記載の方法。
【請求項３】
０に等しい予約期間値を有するＣＣ−ＣＲＴＳフレームが受信されるときに前記ＮＡＶ＿ＣＴＳの更新を控えるステップをさらに含む請求項１に記載の方法。
【請求項４】
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときに前記ＮＡＶ＿ＲＴＳを更新するステップが、前記ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間より大きいアイドル時間の後に続いて受信されたかどうか判断し、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳの受信に必要な時間の間、前記ＮＡＶ＿ＲＴＳを更新し、取消しが受信されない場合に前記ＮＡＶ＿ＲＴＳを延長するステップを含む、請求項１に記載の方法。
【請求項５】
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）が受信されるときに前記ＮＡＶ＿ＲＴＳを更新するステップが、前記ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間を超えないアイドル時間の後に続いて受信されたかどうか判断し、前記ＣＣ−ＲＴＳ予約期間値の間、前記ＮＡＶ＿ＲＴＳ期間を更新するステップを含む、請求項１に記載の方法。
【請求項６】
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）が受信されるときに前記ＮＡＶ＿ＣＴＳを更新するステップが、前記ＣＣ−ＣＴＳ予約期間値の間、前記ＮＡＶ＿ＣＴＳ期間を更新するステップを含む、請求項１に記載の方法。
【請求項７】
前記チャネルのタイマを維持し、および前記チャネルについて受信された最後のＣＣ−ＭＲＴＳの転送側ノードおよび最後のノードを記憶し、前記チャネルについて受信された前記最後のＣＣ−ＲＴＳの予約期間値を維持するステップをさらに含む請求項１に記載の方法。
【請求項８】
前記タイマが０の値である間、ノードが、チャネルについて、０より大きい予約期間値を有するＣＣ−ＲＴＳを受信するときに、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳ（ＣＣ−ＲＴＳＨＳＨＫ）を受信するのに必要な時間間隔の間、前記チャネルの前記ＮＡＶ＿ＲＴＳを更新し、前記タイマを前記ＣＣ−ＲＴＳＨＳＨＫの値に設定し、前記タイマが終了するときに前記チャネルの前記ＮＡＶ＿ＲＴＳを、前記チャネルについて受信された前記最後のＣＣ−ＲＴＳの前記予約時間間隔に等しい値で更新する、請求項７に記載の方法。
【請求項９】
前記タイマが０より大きい間、ノードが、チャネルについて、０より大きい予約期間値を有するＣＣ−ＲＴＳを最後のノードと同じで、かつ同じチャネルについてのノードから受信するときに、前記ＣＣ−ＲＴＳ期間値の間、前記チャネルの前記ＮＡＶ＿ＲＴＳを更新し、前記タイマをリセットする、請求項７に記載の方法。
【請求項１０】
前記ノードが、チャネルについて、０の予約期間を有するＣＣ−ＲＴＳを最後のノードと同じで、かつ同じチャネルについてのノードから受信し、かつ前記タイマが０より大きいときに前記タイマをリセットする、請求項７に記載の方法。
【請求項１１】
前記ノードがチャネルについて、０より大きい予約期間値を有するＣＣ−ＣＴＳを受信するときに、前記ＣＣ＿ＣＴＳ予約期間値の間、前記チャネルの前記ＮＡＶ−ＣＴＳを更新する、請求項７に記載の方法。
【請求項１２】
前記ノードがチャネルについて、他のＮＡＶ設定要求を受信するときに、前記ＮＡＶ設定フレームの前記期間値の間、前記チャネルの前記ＮＡＶ−ＲＴＳおよび前記ＮＡＶ−ＣＴＳを更新する、請求項７に記載の方法。
【請求項１３】
露出ノードを回避するためのコンピュータ読取り可能コードをその中に含むコンピュータ読取り可能媒体であって、
設定される場合、ノードがチャネル上のそれ自体への送信を許可することを防ぐ前記チャネルの第１のタイマ（ＮＡＶ＿ＲＴＳ）を前記ノードで維持するための命令と、
設定される場合、前記ノードが前記チャネル上で送信することを防ぐ前記チャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）を前記ノードで維持するための命令と、
０より大きく、かつ前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときに前記ＮＡＶ＿ＲＴＳを更新するための命令と、
０より大きく、かつ前記ＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときに前記ＮＡＶ＿ＣＴＳを更新するための命令とを含むコンピュータ読取り可能媒体。
【請求項１４】
チャネルについて、０に等しい予約期間値を有するＣＣ−ＲＴＳフレームが受信されるときに、前記チャネルの前記ＮＡＶ＿ＲＴＳの更新を控えるための命令をさらに含む請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１５】
チャネルについて、０に等しい予約期間値を有するＣＣ−ＣＴＳフレームが受信されるときに、前記チャネルの前記ＮＡＶ＿ＣＴＳの更新を控えるための命令をさらに含む請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１６】
前記チャネルについて、０より大きく、かつ前記チャネルの前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときに前記チャネルの前記ＮＡＶ＿ＲＴＳを更新するための命令が、前記チャネルについて前記ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間より大きいアイドル時間の後に続いて受信されたかどうか判断し、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳの受信に必要な時間の間、前記ＮＡＶ＿ＲＴＳを更新し、取消しが受信されない場合に前記ＮＡＶ＿ＲＴＳを延長するための命令を含む、請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１７】
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）が受信されるときに前記チャネルの前記ＮＡＶ＿ＲＴＳを更新するための前記命令が、前記チャネルについて前記ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間を超えないアイドル時間の後に続いて受信されたかどうか判断し、前記ＣＣ−ＲＴＳ予約期間値の間、前記ＮＡＶ＿ＲＴＳ期間を更新するための命令を含む、請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１８】
前記チャネルについて、０より大きく、かつ前記ＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）が受信されるときに前記チャネルの前記ＮＡＶ＿ＣＴＳを更新するための前記命令が、前記ＣＣ−ＣＴＳ予約期間値の間、前記ＮＡＶ＿ＣＴＳ期間を更新するための命令を含む、請求項１３に記載のコンピュータ読取り可能媒体。
【請求項１９】
タイマを維持し、前記チャネルについて受信された最後のＣＣ−ＭＲＴＳの転送側ノードおよび最後のノードを記憶し、前記チャネルについて受信された前記最後のＣＣ−ＲＴＳの予約期間値を維持するための命令をさらに含む請求項１３に記載のコンピュータ読取り可能媒体。
【請求項２０】
前記タイマが０の値である間、ノードが、チャネルについて、０より大きい予約期間値を有するＣＣ−ＲＴＳを受信するとき、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳ（ＣＣ−ＲＴＳＨＳＨＫ）を受信するのに必要な時間間隔の間、前記チャネルの前記ＮＡＶ＿ＲＴＳを更新し、前記タイマを前記ＣＣ−ＲＴＳＨＳＨＫの値に設定し、前記タイマが終了するときに前記チャネルの前記ＮＡＶ＿ＲＴＳを、前記チャネルについて受信された前記最後のＣＣ−ＲＴＳの前記予約期間に等しい値で更新するための命令をさらに含む請求項１９に記載のコンピュータ読取り可能媒体。
【請求項２１】
前記タイマが０より大きい間、前記ノードが、チャネルについて、０より大きい予約期間値を有するＣＣ−ＲＴＳを前記最後のノードと同じノードから受信するときに、前記ＣＣ−ＲＴＳ期間値の間、前記チャネルの前記ＮＡＶ＿ＲＴＳを更新し、前記タイマをリセットするための命令をさらに含む請求項１９に記載のコンピュータ読取り可能媒体。
【請求項２２】
前記ノードが、チャネルについて、０の予約期間を有するＣＣ−ＲＴＳを前記最後のノードと同じノードから、同じチャネルについて受信し、かつ前記タイマが０より大きいときに前記タイマをリセットするための命令をさらに含む請求項１９に記載のコンピュータ読取り可能媒体。
【請求項２３】
前記ノードがチャネルについて、０より大きい予約期間値を有するＣＣ−ＣＴＳを受信するときに、前記ＣＣ＿ＣＴＳ予約期間値の間、前記チャネルの前記ＮＡＶ−ＣＴＳを更新するための命令をさらに含む請求項１９に記載のコンピュータ読取り可能媒体。
【請求項２４】
前記ノードがチャネルについて、他のＮＡＶ設定要求を受信するときに、前記ＮＡＶ設定フレームの前記期間値の間、前記チャネルの前記ＮＡＶ−ＲＴＳおよび前記ＮＡＶ−ＣＴＳを更新するための命令をさらに含む請求項１９に記載のコンピュータ読取り可能媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
無線ローカル・エリア・ネットワーク（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）は、至るところに存在するようになった。一般に、とりわけ分散ＭＡＣプロトコルを介してアクセスされるＷＬＡＮ内の無線通信には、単一のチャネルが使用される。［ＩＥＥＥ  ８０２．１１規格］ＷＬＡＮは、複数のチャネルと複数の無線とを含むことができる。マルチチャネルとマルチ無線の両方の能力を提供する一手法は、参照によりその開示が本明細書に組み込まれており、ＣＣＣ（Ｃｏｍｍｏｎ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ：共通制御チャネル）ＭＡＣプロトコルについて述べている、２００６年３月２９日に出願した同時係属特許出願、「Ａ  Ｐｒｏｔｏｃｏｌ  Ｆｏｒ  Ｗｉｒｅｌｅｓｓ  Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ」、整理番号ＡＶＡ０６−０１に記載されている。ＣＣＣは、２つのタイプの論理チャネル、すなわち制御チャネルおよびデータ・チャネルを使用する。
【０００２】
無線のローカル・エリア・ネットワーク（ＬＡＮ：Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）では、非同期分散ランダム・チャネル・アクセス方法を使用しならが、フレーム・シーケンスの送信のために無線チャネルを予約することができる。こうした環境では、干渉近隣区域（ｉｎｔｅｒｆｅｒｅｎｃｅ  ｎｅｉｇｈｂｏｒｈｏｏｄ）を確立するために、送信の元と宛先の両方が、予約期間をブロードキャストする。
【０００３】
８０２．１１分散チャネル・アクセスＭＡＣプロトコルによれば、隣接ノード（ｎｅｉｇｈｂｏｒ）に送信について通知するために、ＲＴＳ／ＣＴＳフレームが使用される。送信の元および宛先は、干渉近隣区域を確立するために、予約期間を含むＲＴＳおよびＣＴＳ制御フレームをそれぞれ送信する。いずれかの制御フレームを受信するノードは、指定された期間の間、送信すること、または送信の受信に同意することを控える。
【０００４】
チャネルを予約し、無線ＬＡＮ内の隠れ端末との衝突を防止する一方法は、フレーム単位の予約を使用することによる。ＲＴＳ／ＣＴＳフレームは、予約の開始時に送信される。予約時間は、フレーム単位に、予約の期間を各データ・フレーム、およびその後に続く肯定応答で更新することによって延長される。フレーム単位の予約の結果として、予約が受け付けられない、すなわちＣＴＳフレームが時間内に返されない場合には未使用の予約済み時間が残っておらず、したがって、その予約は取り消す必要がないことになる。
【特許文献１】同時係属特許出願、「Ａ  Ｐｒｏｔｏｃｏｌ  Ｆｏｒ  Ｗｉｒｅｌｅｓｓ  Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ」、整理番号ＡＶＡ０６−０１
【特許文献２】同時係属特許出願、「Ａｖｏｉｄｉｎｇ  Ｈｉｄｄｅｎ  Ｔｅｒｍｉｎａｌｓ  Ｉｎ  Ａ  Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ」、整理番号第ＡＶＡ０６−３０号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記で説明したものなどの従来の機構には、様々な欠点がある。こうした１つの欠点は「露出ノード」問題と呼ばれ、この問題は、無線メッシュ・ネットワーク内で悪化する。露出ノード問題は、ＮＡＶが、送信の元または宛先からのフレーム（たとえばＲＴＳ／ＣＴＳ）受信時に設定される場合に生じる。このＮＡＶ設定法によって、過度に保守的な衝突回避の措置が取られることになる。ＲＴＳの送信元の近くの局は、それがＣＴＳ応答を聞くことができない場合には送信できないようにされるべきである。同様に、ＣＴＳは聞こえるが、前者を促すＲＴＳは聞こえない局は、別の送信を受信しないようにされるべきでない。本発明は、ＣＣＣのようなマルチチャネル・プロトコルを使用する場合、露出ノードをどのように回避することができるかについて述べている。
【課題を解決するための手段】
【０００６】
本発明の実施形態は、露出ノード問題を防止する機構および技術を提供する。露出ノード問題は、送信またはＴＸＯＰの元および宛先によって送信されたＮＡＶ設定フレームについて別個のＮＡＶを維持することによって対処される。ＴＸＯＰ内のすべてのフレームは、一方向でなければならない。この要件は、受信されたフレームについての肯定応答をグループ肯定応答として制御チャネル上で送信することによって満たされる。
【０００７】
露出端末を回避するための方法の特定の一実施形態では、この方法は、設定される場合、ノードがチャネル上のそれ自体への送信を許可することを防ぐ、チャネルの第１のタイマ（ＮＡＶ＿ＲＴＳ）をノードで維持するステップと、設定される場合、ノードがチャネル上で送信することを防ぐチャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）をノードで維持するステップとを含む。この方法はさらに、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときにＮＡＶ＿ＲＴＳを更新するステップと、０より大きく、かつＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときにＮＡＶ＿ＣＴＳを更新するステップとを含む。
【０００８】
他の実施形態は、露出端末を回避するためのコンピュータ読取り可能コードをその中に含むコンピュータ読取り可能媒体を含み、この媒体は、設定される場合、ノードがチャネル上のそれ自体への送信を許可することを防ぐチャネルの第１のタイマ（ＮＡＶ＿ＲＴＳ）をノードで維持し、設定される場合、ノードがチャネル上で送信することを防ぐチャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）をノードで維持するための命令を含む。この媒体はさらに、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信要求（ＣＣ−ＲＴＳ）フレームが受信されるときにＮＡＶ＿ＲＴＳを更新するための命令と、０より大きく、かつＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときにＮＡＶ＿ＣＴＳを更新するための命令とを含む。
【０００９】
さらに他の実施形態は、本発明の実施形態として本明細書に開示されたすべての方法操作を処理するように構成された、コンピュータ化された装置を含む。こうした実施形態では、コンピュータ化装置は、メモリ・システムと、プロセッサと、これらの構成要素を接続する相互接続機構内の通信インターフェースとを含む。メモリ・システムは、本明細書で説明されるように露出ノードを回避するプロセスで符号化され、このプロセスは、プロセッサ上で実施されるとき（たとえば実行時）、コンピュータ化装置内で、本明細書で説明されるように、本発明の実施形態として本明細書で説明された方法実施形態および操作のすべてを実施するように動作する。したがって、本明細書で説明された処理を実施し、またはそれを完全に実施するようにプログラムされたいずれのコンピュータ化装置も本発明の一実施形態である。
【００１０】
本明細書に開示される本発明の実施形態の他の構成は、上記に要約され、以下で詳細に開示される方法実施形態の諸ステップおよび操作を実施するためのソフトウェア・プログラムを含む。より具体的には、コンピュータ・プログラム製品は、コンピュータ化装置内で実施されるときに、本明細書で説明された露出ノードを回避する関連の操作を提供する、符号されたコンピュータ・プログラム論理をその中に含むコンピュータ読取り可能媒体を有する一実施形態である。このコンピュータ・プログラム論理は、コンピューティング・システムで少なくとも１つのプロセッサ上で実行されるときに、プロセッサに、本発明の実施形態として本明細書に示された操作（たとえば方法）を実施させる。本発明のこうした構成は一般に、光学媒体（たとえばＣＤ−ＲＯＭ）、フロッピー（登録商標）、ハード・ディスクなどのコンピュータ読取り可能媒体、あるいはファームウェアや、１つまたは複数のＲＯＭ、ＲＡＭまたはＰＲＯＭチップ内のマイクロコードなどの他の媒体内で構成されまたは符号化されたソフトウェア、コードおよび／または他のデータ構造体として、あるいは特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉ）、あるいは１つまたは複数のモジュール、共有ライブラリ内などのダウンロード可能ソフトウェア画像として提供される。ソフトウェア、ファームウェア、または他のこうした構成は、コンピュータ化装置内の１つまたは複数のプロセッサに、本発明の実施形態として本明細書に説明された技術を実施させるためにコンピュータ化装置内にインストールすることができる。データ通信装置または他のエンティティの一群など、コンピュータ化装置の集合内で動作するソフトウェア・プロセスは、本発明のシステムを提供することもできる。本発明のシステムは、複数のデータ通信装置上の多くのソフトウェア・プロセス間で分散することができ、あるいはすべてプロセスが、専用コンピュータの小さいセット、または１つのコンピュータ内だけで実行され得る。
【００１１】
本発明の諸実施形態は厳密には、ソフトウェア・プログラムとして、ソフトウェアとハードウェアとして、あるいはハードウェアおよび／または回路単独に、たとえばデータ通信装置内で実施することができることが理解されたい。本明細書に説明されたように、本発明の諸特徴は、ニュージャージー州のＬｉｎｃｒｏｆｔのＡｖａｙａ  Ｉｎｃ．社によって製造されたものなど、こうした装置のためのデータ通信装置および／またはソフトウェア・システム内で使用してもよい。
【００１２】
上記内容は、添付の図面内に示されるように、本発明の好ましい実施形態についての以下のより具体的な説明から明らかであり、図面では、同じ参照符号は、それぞれ異なる図を通して同じ部分に言及する。図面は、図面は必ずしも一定の尺度で作られておらず、そうではなく、本発明の原理を示すことに重点が置かれている。
【発明を実施するための最良の形態】
【００１３】
従来の無線ネットワークは、メディア・アクセス制御のための共通制御（ＣＣＣ）プロトコルを使用してもよい。ＣＣＣプロトコルは、ＩＥＥＥ  ８０２．１１分散ＭＡＣプロトコルを、ＢＳＳまたはメッシュ・ネットワーク内の複数チャネルの使用を可能にするように拡張するＭＡＣプロトコルである。ＣＣＣプロトコルは、分散型の優先競合ベースのメディア・アクセスに基づいて、柔軟なチャネル・アクセス・アーキテクチャを定義する。ＣＣＣプロトコルは、２つの論理チャネル機能、すなわち制御チャネル（ＣＣ：Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）とデータ・チャネル（ＤＣ：Ｄａｔａ  Ｃｈａｎｎｅｌ）を区別する。以下の説明では、ＣＣＣ  ＭＡＣプロトコルに従う局またはメッシュ点は、「ノード」と呼ばれる。ノードは、制御チャネル上で制御および管理フレームを交換する。データ・チャネルは、データ・トラフィックを運ぶ。
【００１４】
様々なデータ・チャネル上の送信の予約は、制御チャネル上で制御フレームを交換することによって行われる。レガシーＲＴＳおよびＣＴＳメッセージの拡張物として、ＣＣ−ＲＴＳおよびＣＣ−ＣＴＳは、ＴＸＯＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｏｐｐｏｒｔｕｎｉｔｙ：送信機会）を送信するために要する時間の間、データ・チャネルを予約するために使用される。ＴＸＯＰは、ＩＥＥＥ  ８０２．１ｅ規格によって定められた例については、単一の競合ベース・チャネル・アクセス試みの成功に直ちに続いて連続的に送信されるフレーム・シーケンス（およびそれぞれの肯定応答）である。ＴＸＯＰの送信のために選択された特定のデータ・チャネルは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの特別なフィールド内に示される。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの交換は、同じ時間間隔の間、それが複数のデータ・チャネル、またはデータ・チャネルおよび制御チャネルを予約することができるように定義され得る。ノードは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの予約期間フィールドの値に基づいて、チャネル特有のＮＡＶ内でチャネルが予約される時間の長さを追跡する。
【００１５】
転送側と受信側の両方のノードが、使用可能な各チャネルのＮＡＶを維持する。ノードは、制御チャネルを監視し、データ・チャネルの使用中／アイドル状況、およびそれがいつ使用可能になるか判断するために、他のノードによって行われたすべての予約を追跡する。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの予約期間フィールドは、予約されたチャネルのＮＡＶを更新するために使用される。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ予約期間フィールドは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳフレームのＭＡＣヘッダ内の期間／ＩＤフィールドとは異なる。後者は、制御チャネル上のＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ送信の長さを示す。予約要求は、受信側ノードが、要求されたチャネルが使用中であると見なす場合、またはそのすべての無線が使用中である場合には拒否される。
【００１６】
受信側ノードは、短フレーム間隔（ＳＩＦＳ：Ｓｈｏｒｔ  ＩｎｔｅｒＦｒａｍｅ  Ｓｐａｃｅ）の時間間隔の長さ内にＣＣ−ＣＴＳで応答する。ＣＣ−ＣＴＳが、チャネル予約要求の受入れを示すために送信される。予約期間フィールドは、受信側ノードによって送信されたＣＣ−ＣＴＳ内でコピーされる。ＣＣ−ＣＴＳが受信されない場合、転送側ノードは、予約要求が拒否されると見なす。予約は、ＣＣ−ＲＴＳ内に示されたデータ・チャネルが、受信側ノードによって維持されたＮＡＶによる事前に指定された時間間隔内にアイドル状態になる場合、および受信側ノードが送信を受信するのに使用可能な無線を有する場合に受け入れられる。データ・トラフィック送信の受信が成功した後には、ＥＤＣＡ規則に従ってデータ・チャネル上で、またはグループ肯定応答として制御チャネル上で送信された肯定応答が続く。
【００１７】
転送側と受信側のノードの両方が、使用可能な各チャネルのＮＡＶを維持する。ノードは、制御チャネルを監視し、データ・チャネルの使用中／アイドル状況、およびそれがいつ使用可能になるか判断するために、他のノードによって行われたすべての予約を追跡する。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳの予約期間フィールドは、予約されたチャネルのＮＡＶを更新するために使用される。ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ予約期間フィールドは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳフレームのＭＡＣヘッダ内の期間／ＩＤフィールドとは異なる。後者は、制御チャネル上のＣＣ−ＲＴＳ／ＣＣ−ＣＴＳ送信の長さを示す。予約要求は、受信側ノードが、要求されたチャネルが使用中であると見なす場合、またはそのすべての無線が使用中である場合に拒否される。
【００１８】
受信側ノードは、短フレーム間隔（ＳＩＦＳ）の時間間隔の長さ内にＣＣ−ＣＴＳで応答する。ＣＣ−ＣＴＳが、チャネル予約要求の受入れを示すために送信される。予約期間フィールドは、受信側ノードによって送信されたＣＣ−ＣＴＳ内でコピーされる。ＣＣ−ＣＴＳが受信されない場合、転送側ノードは、予約要求が拒否されると見なす。予約は、ＣＣ−ＲＴＳ内に示されたデータ・チャネルが、受信側ノードによって維持されたＮＡＶによる事前に指定された時間間隔内にアイドル状態になる場合、および受信側ノードが送信を受信するのに使用可能な無線を有する場合に受け入れられる。データ・トラフィック送信の受信が成功した後には、ＥＤＣＡ規則に従ってデータ・チャネル上で、またはグループ肯定応答として制御チャネル上で送信された肯定応答が続く。
【００１９】
使用される様々なフレームには、ＴＸＯＰを開始するノードによって使用されるＣＣ−ＲＴＳフレームが含まれる。このフレームは、送信元ノードと、宛先ノードと、送信元ノード送信チャネルと、期間と、ＴＸＯＰ内のいくつかのフレームとを含む複数のフィールドを含む。ＣＣ−ＣＴＳフレームはＴＸＯＰを受け入れるノードによって使用される。ＣＣ−ＣＴＳフレームは宛先ノードと、送信元ノードと、送信元ノード送信チャネルと、期間と、ＴＸＯＰ内のいくつかのフレームと、無線カウンタとを含む。ＣＣ−ＡＣＫフレームが、うまく受信されたフレーム・シーケンス内の個々のフレームを識別する。ＣＣ−ＡＣＫフレームは、宛先ノードと、送信元ノードと、ＴＸＯＰフレーム受信状況とを含む。
【００２０】
チャネル予約は、データ・チャネルについてのＣｈａｎｎｅｌ＿Ｓｔａｔｅ表示がアイドルである場合に、送信元ノードが制御チャネル上で宛先ノードにＣＣ−ＲＴＳフレームを送信することによって、１つまたは複数のフレームの間、そのデータ・チャネルを予約するときに行われる。予約期間フィールドおよびＴＸＯＰフレームの数は、ＣＣ−ＲＴＳ内に設定される。宛先ノードは、それに応答してＳＴＦＳ内にＣＣ−ＣＴＳを送信する。予約要求は、宛先ノードが送信元ノードのデータ・チャネルについてのＣｈａｎｎｅｌ＿Ｓｔａｔｅアイドル表示を有する場合、および宛先ノードが送信を受信するのに使用可能な無線を有し、すなわち無線カウンタがゼロでない場合に受け入れられる。予約要求が宛先ノードによって受け入れられる場合、予約期間フィールドが調整され、ＴＸＯＰ内のフレーム数は、宛先ノードによって送信されたＣＣ−ＣＴＳ内で繰り返され、ＣＣ−ＣＴＳは、トラフィック受信に使用できる状態のままの無線の数、すなわち無線カウンタを含む（後者は必要ではないが、しかし、宛先ノードに送信するフレームを有する他のノードにとって有用である）。予約要求が宛先ノードによって拒否される場合、ＣＣ−ＣＴＳ内の予約期間フィールドは０に設定され、その場合、送信元ノードは、０に設定された予約期間フィールドを含む別のＣＣ−ＲＴＳを送信する。さらに、宛先ノードは、０に設定された予約期間フィールドを含むＣＣ−ＲＴＳに応答して、予約期間フィールド内に０を含むＣＣ−ＣＴＳを送信する。ＴＸＯＰ内のすべてのフレームが送信されるとき、宛先ノードは、制御チャネル上で、ＣＣ−ＡＣＫと呼ばれる肯定応答を送信することによって送信シーケンスの状況を肯定応答する。うまく受信されたフレームは、ＣＣ−ＡＣＫ内で識別される。肯定応答は、最も高いアクセス優先度で競合することによって送信される。
【００２１】
チャネル予約は、データ・チャネルについてのＣｈａｎｎｅｌ＿Ｓｔａｔｅ表示がアイドルである場合に、送信元ノードが制御チャネル上で宛先ノードにＣＣ−ＲＴＳフレームを送信することによって１つまたは複数のフレームの間、そのデータ・チャネルを予約するときに行われる。予約期間フィールドおよびＴＸＯＰフレームの数は、ＣＣ−ＲＴＳ内に設定される。宛先ノードは、それに応答してＳＴＦＳ内にＣＣ−ＣＴＳを送信する。予約要求は、宛先ノードが送信元ノードのデータ・チャネルについてのＣｈａｎｎｅｌ＿Ｓｔａｔｅアイドル表示を有する場合、および宛先ノードが送信を受信するのに使用可能な無線を有し、すなわち無線カウンタがゼロでない場合に受け入れられる。予約要求が宛先ノードによって受け入れられる場合、予約期間フィールドが調整され、ＴＸＯＰ内のフレーム数は、宛先ノードによって送信されたＣＣ−ＣＴＳ内で繰り返され、ＣＣ−ＣＴＳは、トラフィック受信に使用できる状態のままの無線の数、すなわち無線カウンタを含む（後者は必要ではないが、しかし、宛先ノードに送信するフレームを有する他のノードにとって有用である）。予約要求が宛先ノードによって拒否される場合、ＣＣ−ＣＴＳ内の予約期間フィールドは０に設定され、その場合、送信元ノードは、０に設定された予約期間フィールドを含む別のＣＣ−ＲＴＳを送信する。さらに、宛先ノードは、０に設定された予約期間フィールドを含むＣＣ−ＲＴＳに応答して、予約期間フィールド内に０を含むＣＣ−ＣＴＳを送信する。
【００２２】
ＴＸＯＰ内のすべてのフレームが送信されるとき、宛先ノードは、制御チャネル上で、ＣＣ−ＡＣＫと呼ばれる肯定応答を送信することによって送信シーケンスの状況を肯定応答する。うまく受信されたフレームは、ＣＣ−ＡＣＫ内で識別される。肯定応答は、競合によって送信される。
【００２３】
これらの追加、および（以下で論じる）肯定応答の特別な形とは別に、ＣＣＣプロトコルは、ＩＥＥＥ  ８０２．１１の分散ランダム・アクセス・プロトコルについての規則、ならびにチャネル・アクセスおよび仮想キャリアセンスについてのその修正物（ＤＣＦおよびＥＤＣＡ）に従うが、さらなる拡張によって、向上したチャネル・アクセス優先付けを可能にすることができる。
【００２４】
ＣＣＣは、既存の８０２．１１技術と後方互換性がある。すべてのノード、すなわち既存の８０２．１１技術を使用するノードとＣＣＣ準拠のノードの両方が、既存の８０２．１１  ＭＡＣプロトコルを介して制御チャネルで通信することができる。さらに、データ・チャネルの予約を確保するノードは、チャネルがアイドル状態であることを保証するために、調停フレーム間隔に等しい期間の間、リッスンした後にだけ、予約済みのチャネル上で送信する。この措置は、ＣＣＣに準拠した局がレガシー／独立局と共存することを可能にするために導入される。
【００２５】
所望であれば、成功した送信は、肯定応答されてもよい。（制御チャネル上でデータを送信する）単一の無線を有するノードは、８０２．１１規格、およびその修正物によって提供される肯定応答の形のいずれかを使用することができる。２つの無線、すなわち１つの制御無線と１つのデータ無線と有するノードについても、複数のデータ無線を有するノードと通信するときの特定の状況を除いて、同じことが当てはまる。
【００２６】
ノードは、ＴＸＯＰの受信の成功について送信側に通知するために、ＣＣ肯定応答（ＣＣ−ＡＣＫ）と呼ばれるグループ肯定応答を制御チャネル上で送信することもできる。ＣＣ−ＡＣＫは、隣接チャネル干渉の回避、または露出ノードの回避のために使用される。
【００２７】
「露出ノード」は、送信側ノードのセンス範囲内であるが、受信側ノードの干渉範囲外であるノードであり、したがって、それは、別のノードから送信を受信することはできないが、それ自体で送信することができ、あるいは受信側ノードのセンス範囲内であるが、送信側ノードの干渉範囲外であるノードであり、したがって、それは、送信することはでないが、それに向けられた別の送信を受信することができる。メッシュ・ネットワークでは、ノード間の距離のために、露出ノード問題が強調される。メッシュの空間的配置によりノードは、露出されるようになり、そのＮＡＶを保守的に設定する。新しいＮＡＶ規則は、さもなければ「露出ノード」になったであろうものが衝突を引き起こさずに送信することを可能にする。
【００２８】
露出ノード問題は、メッシュ・トラフィック・チャネルとは異なる制御チャネル上で予約および肯定応答が行われる場合、回避することができる。ＮＡＶは、それに応じて修正される。露出ノード問題によって、送信側ノードの隣接ノードのＮＡＶは、過度に保守的なやり方で設定されるようになる。
【００２９】
ＮＡＶ設定要求（ＣＣ−ＲＴＳまたはＣＣ−ＣＴＳ）を聞くことができるノードは、送信を控え、予約要求（すなわちＣＣ−ＲＴＳ）を受信するときに予約を拒否する。こうしたノードは、そのＮＡＶの設定を引き起こした送信と同時に送信を送信しまたは受信することができ得る。しかし、ノードは、進行中の送信の宛先から十分に遠く離れている場合には、同時に送信することを控える必要はない。
【００３０】
Ａｃｋは、露出ノードによる同じチャネル上のＴｘ（Ｒｘ）を防ぐ。ＣＣ−ＲＴＳは聞こえるが、応答して送信されたＣＣ−ＣＴＳは聞こえない露出ノードは、Ａｃｋとの衝突が生じ得るので、同時に送信することができない。Ａｃｋが同じチャネル上で返されない場合は、露出ノードによる送信は可能である（たとえばＡｃｋが抑制され、または別個のチャネル上でＡｃｋされる）。
【００３１】
次に図１を参照すると、露出ノードの一例が示されている。この環境では、ノードＣは、ノードＢのセンス範囲内にある。ノードＢはノードＡと通信しており、ノードＣはノードＤと通信している。ノードＣがノードＤにＣＣ−ＲＴＳを送信するとき、センス範囲内のすべてのノード（たとえばノードＢ）は、ＣＣ−ＲＴＳを聞く。ノードＢは、それに応じてＮＡＶを設定し、送信を控える。ノードがＣＣ−ＲＴＳの宛先の干渉範囲内にない場合、そのノードは、衝突を引き起こさずに同時に送信することができる。ノードＢは、ＣがＤに送信を送るのと同時に送信することができる。ＣＣ−ＲＴＳを聞くノードは、それ自体に向けられたＣＣ−ＲＴＳを受け入れるべきでない。ノードＢは、ＣがＤに送信している間、ノードＡから送信を受信することができない。
【００３２】
ＣＣ−ＲＴＳのセンス範囲外の宛先への第２の送信が、Ｂから可能である。ノードＡは、Ｃのセンス範囲外にあるので、ＣからのＣＣ−ＲＴＳを聞いておらず、したがって、ノードＢからのＣＣ−ＲＴＳへのＣ−ＣＴＳで応答する。ノードＢは、ノードＣが送信するとき、「露出される」ようになる。ノードＣは、ノードＢが送信するとき、「露出される」ようになる。
【００３３】
露出ノード問題の別の例が、図２に示されている。この環境では、ノードＣは、ノードＢのセンス範囲内にある。ノードＢはノードＡと通信しており、ノードＣはノードＤと通信している。ノードＤがノードＣにＣＣ−ＲＴＳを送信するとき、センス範囲内のすべてのノードは、ＣＣ−ＲＴＳを聞く。ノードＢは、それに応じてＮＡＶを設定し、送信を控える。あるノードがＣＣ−ＲＴＳの宛先の干渉範囲内にない場合、それは、衝突を引き起こさずに同時に送信することができる。ノードＡは、ノードＤがＣに送信を送るのと同時に送信することができる。ＣＣ−ＲＴＳのセンス範囲外の宛先への第２の送信が可能である。ノードＡは、Ｃのセンス範囲外にあるので、ＣからのＣＣ−ＲＴＳを聞いておらず、したがって、ノードＢにＣＣ−ＲＴＳを送信することができる。ＣＣ−ＣＴＳを聞くあるノードは、それ自体に向けられたＣＣ−ＲＴＳを受け入れるべきである。ノードＢは、ＣがＤに送信している間、ノードＡからの送信を受信することができる。ノードＢは、ノードＤが送信するとき、「露出される」ようになる。ノードＣは、ノードＡが送信するとき、「露出される」ようになる。
【００３４】
ＣＣＣ  ＭＡＣプロトコルによれば、トラフィック・チャネルの予約のために、制御チャネルが使用される。制御チャネルは一般に、データ・トラフィックを運ぶチャネルと異なる。グループ肯定応答、メッシュＡｃｋ（ＭＡＣＫ：Ｍｅｓｈ  ＡｃＫ）は、ＴＸＯＰの受信が成功すると、制御チャネル上で送信することができる。これは、送信で使用されるチャネル上で通常送信される定期的なＡｃｋ（個別またはグループ）の代わりである。トラフィック・チャネルからＡｃｋを取り除くことによって、露出ノードが、保留中のＮＡＶ設定要求を有する隣接ノードと同時に送信することが可能である。ＣＣ−ＲＴＳを受信するノードがいつ送信することができるか判断するために、新しいＮＡＶ規則が使用される。従来の８０２．１１のＮＡＶ規則によれば、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳは、隣接ノードのＮＡＶを設定する。ＮＡＶが設定されると、ノードは、ＮＡＶが終了するまで、ＣＣ−ＲＴＳを送信することができず、またはＣＣ−ＣＴＳの送信によりＣＣ−ＲＴＳを承認することができない。既存のＮＡＶ設定規則は、適切なときに露出ノードが送信することを可能にするのに適していない。
【００３５】
ＮＡＶの新しい規則は、以下のとおりである。ＮＡＶは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳを受信するノードがいつ送信することができるか区別しなければならない。ＮＡＶは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳを受信するノードがいつ予約を受け入れる（すなわちＣＣ−ＣＴＳを送信する）ことができるか区別しなければならない。「露出ノード」問題に対処するために、それぞれのノードは、それぞれのデータ・チャネルについて２つのＮＡＶ、すなわちＮＡＶ＿ＲＴＳおよびＮＡＶ＿ＣＴＳを維持する。ＮＡＶ＿ＲＴＳは、０より大きく、かつ予約期間の現在値より大きい予約期間を有するＣＣ−ＲＴＳを受信するときに更新される。あるチャネルについてＮＡＶ＿ＲＴＳが０より大きい場合、ノードは、０に等しい予約期間を有するＣＣ−ＣＴＳを送信することによって、そのチャネルを求めるＣＣ−ＲＴＳ予約要求を拒否しなければならない。ＮＡＶ＿ＣＴＳは、０より大きく、かつ予約期間の現在値より大きい予約期間を有するＣＣ−ＣＴＳを受信するときに更新される。あるチャネルについてＮＡＶ＿ＣＴＳが０より大きい場合、ノードは、そのチャネルの予約を試みるべきでない。ノードが、０に等しい予約期間を有するＣＣ−ＲＴＳを聞く場合、ＮＡＶ＿ＲＴＳは更新されない。０に等しい予約期間を有するＣＣ−ＣＴＳをノードが聞く場合、ＮＡＶ＿ＣＴＳは更新されない。
【００３６】
参照によりその全体が本明細書に組み込まれている、本出願と同日に出願された同時係属特許出願、「Ａｖｏｉｄｉｎｇ  Ｈｉｄｄｅｎ  Ｔｅｒｍｉｎａｌｓ  Ｉｎ  Ａ  Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ」、整理番号第ＡＶＡ０６−３０号は、隠れノードおよび予約拒否について論じており、本発明と併せて実施することができる。拒否されたＣＣ−ＲＴＳによって引き起こされたチャネル予約を取り消すために提案されたＮＡＶ設定プロセスは、新しいＮＡＶ設定規則に組み込むことができる。ＣＣ−ＲＴＳに応答して、ＮＡＶは、以下の２つのステップ、すなわち予約ハンドシェイクを可能にするための固定の時間間隔、および残りの予約時間で設定される。
【００３７】
あるノードが０より大きい予約期間を有するＣＣ−ＲＴＳを聞く場合、ＳＩＦＳより長いアイドル状態に続いて、それは、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳを受信するのに必要な時間の間、ＮＡＶ＿ＲＴＳを更新し、取消しが受信されない場合にＮＡＶを延長する。あるノードは、ＳＩＦＳ以下のアイドル状態の後に続いて、０より大きい予約期間を有するＣＣ−ＲＴＳを聞く場合、ＣＣ−ＲＴＳ予約期間値の間、ＮＡＶ＿ＲＴＳを更新する。あるノードは、０より大きい予約期間を有するＣＣ−ＣＴＳを聞く場合、Ｃ−ＣＴＳ予約期間値の間、ＮＡＶ＿ＣＴＳを更新する（ノードによる同時送信は衝突を引き起こす）。
【００３８】
あるチャネルについてＮＡＶを二重に使用することによって、露出ノードは、ＣＣ−ＲＴＳ／ＣＣ−ＣＴＳを介してそのチャネルが予約される送信に干渉せずに受信しまたは送信することができる。しかし、露出ノードへのまたはそこからの送信は、反対方向で送信される肯定応答に干渉する。こうした衝突を回避するために、肯定応答は、制御チャネル上で送信することができる。換言すると、ＣＣ−ＡＣＫ、すなわちデータ・チャネル上のＴＸＯＰ送信の後に続いて制御チャネル上で送信される肯定応答の使用は、ＷＬＡＮメッシュが露出ノードを防ぐこと可能にするための肯定応答に必要とされる。
【００３９】
ここに開示された方法のフローチャートが、図１Ａおよび図１Ｂに示されている。矩形要素は、本明細書では「処理ブロック」と示され、コンピュータ・ソフトウェア命令または命令群を表している。ひし形の要素は、本明細書では「判断ブロック」と示され、コンピュータ・ソフトウェア命令、または処理ブロックによって表されたコンピュータ・ソフトウェア命令の実行に影響を及ぼす命令群を表す。
【００４０】
あるいは、処理および判断ブロックは、デジタル信号プロセッサ回路や特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）など、機能的に等価の回路によって実施されるステップを表す。このフローチャートは、いずれかの特定のプログラミング言語の構文を示すものではなく、むしろこのフローチャートは、本発明に従って必要な処理を実施するために回路を組み立て、またはコンピュータ・ソフトウェアを生成するのに当業者が必要とする機能情報を示している。ループおよび変数の初期化、ならびに一時変数の使用など、多くのルーチン・プログラム要素は示されていないことに留意されたい。本明細書に特に示されない限り、示された特定のステップシーケンスは例示的なものにすぎず、本発明の趣旨から逸脱せずに変更されてもよいことが当業者には理解されよう。したがって、特に示されていない限り、下記に述べられた諸ステップは順序が定められておらず、すなわち、可能なときに諸ステップは、好都合なまたは望ましい任意の順序で実施することができることを意味する。
【００４１】
次に図３Ａおよび３Ｂを参照すると、無線ネットワーク内の露出ノードを回避するための方法１００の特定の一実施形態が示されている。この方法は処理ブロック２０２から開始し、この処理ブロック１０２は、ノード上で、他のノードがチャネル上で送信することを控えなければならない、チャネルの第１の期間（ＮＡＶ＿ＲＴＳ）を維持するステップを開示している。処理ブロック２０４は、ノード上で、そのノードがそのチャネル上で送信することを控えなければならない、チャネルの第２のタイマ（ＮＡＶ＿ＣＴＳ）を維持するステップを示している。
【００４２】
処理ブロック２０６は、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信依頼（ＣＣ−ＲＴＳ）フレームが受信されるときにＮＡＶ＿ＲＴＳを更新するステップを示している。処理ブロック２０８に示されるように、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信依頼（ＣＣ−ＲＴＳ）フレームが受信されるときにＮＡＶ＿ＲＴＳを更新するステップは、ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間より大きいアイドル時間の後に続いて受信されたかどうか判断し、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳの受信に必要な時間の間、ＮＡＶ＿ＲＴＳを更新し、取消しが受信されない場合にＮＡＶ＿ＲＴＳを延長するステップを含む。処理ブロック２１０にさらに示されるように、０より大きく、かつＮＡＶ＿ＲＴＳの現在値より大きい予約期間値を有する送信依頼（ＣＣ−ＲＴＳ）が受信されるときにＮＡＶ＿ＲＴＳを更新するステップは、ＣＣ−ＲＴＳが、短フレーム間隔（ＳＩＦＳ）時間を超えないアイドル時間に続いて受信されたかどうか判断し、ＣＣ−ＲＴＳ予約期間値の間、ＮＡＶ＿ＲＴＳ期間を更新するステップを含む。
【００４３】
処理ブロック２１２は、０より大きく、かつＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）フレームが受信されるときにＮＡＶ＿ＣＴＳを更新するステップを開示している。これは、処理ブロック２１４に示されるように、０より大きく、かつＮＡＶ＿ＣＴＳの現在値より大きい予約期間値を有する送信応答（ＣＣ−ＣＴＳ）が受信されるときにＮＡＶ＿ＣＴＳを更新するステップが、ＣＣ−ＣＴＳ予約期間値の間、ＮＡＶ＿ＣＴＳ期間を更新するステップを含むことを含んでもよい。
【００４４】
処理は処理ブロック２１６に続き、この処理ブロック２１６は、０に等しい予約期間値を有するＣＣ−ＲＴＳフレームが受信されるときにＮＡＶ＿ＲＴＳの更新を控えるステップを示している。処理ブロック２１８は、０に等しい予約期間値を有するＣＣ−ＣＴＳフレームが受信されるときにＮＡＶ＿ＣＴＳの更新を控えるステップを示している。
【００４５】
処理ブロック２２０は、この方法が、タイマを維持し、受信された最後のＣＣ−ＲＴＳの転送側ノードおよび最後のノードを記憶し、受信された最後のＣＣ−ＲＴＳの予約期間値を維持するステップをさらに含むことを示している。処理ブロック２２２は、タイマが０の値である間、ノードが、０より大きい予約期間値を有するＣＣ−ＲＴＳを受信するとき、ＣＣ−ＣＴＳおよびＣＣ−ＲＴＳ（ＣＣ−ＲＴＳＨＳＨＫ）を受信するのに必要な時間間隔の間、ＮＡＶ＿ＲＴＳを更新し、タイマをＣＣ−ＲＴＳＨＳＨＫの値に設定し、タイマが終了するときにＮＡＶ＿ＲＴＳを、受信された最後のＣＣ−ＲＴＳの予約期間に等しい値で更新するステップを示している。処理ブロック２２４は、タイマが０より大きい間にノードが最後のノードと同じノードから、０より大きい予約期間値を有するＣＣ−ＲＴＳを受信するときに、ＣＣ−ＲＴＳ期間値の間、ＮＡＶ＿ＲＴＳを更新し、タイマをリセットするステップを示している。処理ブロック２２６は、ノードが、最後のノードと同じノードから０の予約期間値を有するＣＣ−ＲＴＳを受信し、かつタイマが０より大きいときに、タイマをリセットするステップを開示している。処理ブロック２２８は、ノードが０より大きい予約期間を有するＣＣ−ＣＴＳを受信するときに、ＣＣ＿ＣＴＳ予約期間値の間、ＮＡＶ−ＣＴＳを更新するステップを示しており、処理ブロック２３０は、ノードが他のＮＡＶ設定要求を受信するときに、ＮＡＶ設定フレーム内の期間値の間、ＮＡＶ−ＲＴＳおよびＮＡＶ−ＣＴＳを更新するステップを示している。
【００４６】
図４は、ノード２４０として構成されたコンピュータ・システムの例示的なアーキテクチャを示している。ノード２４０は、パーソナル・コンピュータ、ワークステーション、携帯型コンピューティング装置、メインフレーム、サーバなど、任意のタイプのコンピュータ化システムであり得る。この実施例では、ノードは、メモリ・システム２１２、プロセッサ２１３および通信インターフェース２１４を連結する相互接続機構２１１を含む。通信インターフェース２１４は、ノード２４０が外部装置またはシステムと通信することを可能にする。
【００４７】
メモリ・システム２１２は、アプリケーション２５５−Ａで符号化される任意のタイプのコンピュータ読取り可能媒体とすることができ、アプリケーション２５５−Ａは、上記で説明されたように本発明の実施形態の処理機能を実施する（たとえばメモリまたは、ディスクなどの別のコンピュータ読取り可能媒体内に格納された）データおよび／または論理命令などのソフトウェア・コードを表す。プロセッサ２１３は、対応するプロセス２５５−Ｂを生成するためにホスト用のアプリケーション２５５−Ａの論理命令を開始し、走らせ、実行し、解釈し、または別のやり方でそれを実施するために、相互接続機構２１１を介してメモリ・システム２１２にアクセスすることができる。換言すると、プロセス２５５−Ｂは、コンピュータ・システム内のプロセッサ２１３内またはその上で実施するアプリケーション２５５−Ａの１つまたは複数の部分を表す。
【００４８】
本発明の実施形態は、フロッピー（登録商標）・ディスク、ハード・ディスクなどコンピュータ読取り可能媒体、光学媒体内で、またファームウェア、読取り専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）などのメモリ・タイプ・システム内で、あるいはこの実施例のようにメモリ・システム２１２（たとえばランダム・アクセス・メモリすなわちＲＡＭ内）の実行可能コードとして符号化されたアプリケーション（すなわち未実行の、または機能していない論理命令および／またはデータ）を含むことを理解されたい。本発明の他の実施形態は、プロセッサ２１３内でプロセスとして動作するアプリケーションを提供できることも理解されたい。この実施例では示されていないが、このコンピュータ・システムは、本発明についての説明を容易にするためにこの図から除かれている他のプロセスおよび／またはオペレーティング・システムなどのソフトウェアおよびハードウェア構成要素を含んでもよいことが当業者には理解されよう。
【００４９】
本発明の好ましい実施形態について述べたが、次に、これらの概念を組み込む他の実施形態を使用してもよいことが当業者には明らかになろう。さらに、本発明の一部として含まれたソフトウェアは、コンピュータ使用可能媒体を含むコンピュータ・プログラム製品として実施されてもよい。たとえば、こうしたコンピュータ使用可能媒体は、コンピュータ読取り可能プログラム・コード・セグメントがその中に格納されたハード・ドライブ装置、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭまたはコンピュータ・ディスケットなど、読取り可能メモリ・デバイスを含むことができる、コンピュータ読取り可能媒体は、デジタルまたはアナログ信号として運ばれるプログラム・コード・セグメントを含む光学、有線または無線の通信リンクを含むこともできる。したがって、本発明は、述べられた諸実施形態に限定されるべきでなく、添付の特許請求の範囲の精神および範囲によってのみ限定されるものであることを述べておく。
【図面の簡単な説明】
【００５０】
【図１】露出ノードの第１の例を示すネットワークの図である。
【図２】露出ノードの第２の例を示すネットワークの図である。
【図３Ａ】本発明の実施形態による露出ノードを回避するための方法の特定の実施形態を示す図である。
【図３Ｂ】本発明の実施形態による露出ノードを回避するための方法の特定の実施形態を示す図である。
【図４】本発明に従って動作するノードのブロック図である。
【図１】
2009510803.tif 000003
【図２】
2009510803.tif 000004
【図３Ａ】
2009510803.tif 000005
【図３Ｂ】
2009510803.tif 000006
【図４】
2009510803.tif 000007
【国際調査報告】
2009510803.tif 000008