特許7580548 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ パナソニック　インテレクチュアル　プロパティ　コーポレーション　オブ　アメリカの特許一覧

特許7580548通信装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3A
3B
4
5
6
7A
7B
8A
8B
9
10A
10B
11A
11B
11C
12
13A
13B
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-31

(45)【発行日】2024-11-11

(54)【発明の名称】通信装置

(51)【国際特許分類】

H04W 74/0808 20240101AFI20241101BHJP

H04W 84/12 20090101ALI20241101BHJP

H04W 72/54 20230101ALI20241101BHJP

【ＦＩ】

H04W74/0808

H04W84/12

H04W72/54 110

【請求項の数】 9

(21)【出願番号】P 2023146777

(22)【出願日】2023-09-11

(62)【分割の表示】P 2022088826の分割

【原出願日】2017-10-25

(65)【公開番号】P2023162448

(43)【公開日】2023-11-08

【審査請求日】2023-09-11

(31)【優先権主張番号】P 2016216622

(32)【優先日】2016-11-04

(33)【優先権主張国・地域又は機関】JP

(31)【優先権主張番号】P 2017039514

(32)【優先日】2017-03-02

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニックインテレクチュアルプロパティコーポレーションオブアメリカ

【氏名又は名称原語表記】ＰａｎａｓｏｎｉｃＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙＣｏｒｐｏｒａｔｉｏｎｏｆＡｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】チトラカールロジャン

(72)【発明者】

【氏名】ホァンレイ

(72)【発明者】

【氏名】浦部嘉夫

【審査官】三枝保裕

(56)【参考文献】

【文献】国際公開第２０１６／１３９８５９（ＷＯ，Ａ１）

【文献】Kaiying Lv (ZTE Corp.)，UL MU CCA Response，IEEE 802.11-16/0054r1，2016年01月18日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ７／２４－７／２６

Ｈ０４Ｗ４／００－９９／００

(57)【特許請求の範囲】

【請求項1】

トリガベースPHYプロトコルデータユニットのリソースを割り当てるトリガフレームを含むPHYプロトコルデータユニットをアクセスポイントから受信した後に、動作チャネルにおいてエネルギー検出を行い、
前記エネルギー検出に基づいて、前記動作チャネルにおけるプライマリチャネルと第１セカンダリチャネルを含む１つ以上の２０MHzサブチャネルの各々のビジーまたはアイドル状態を示すビットマップ情報を設定する、回路と、
前記ビットマップ情報が前記第１セカンダリチャネルはアイドルであることを示すとき、前記プライマリチャネルがビジーまたはアイドルであるかに関わらず、前記トリガフレームに応答して、前記第１セカンダリチャネルにて前記アクセスポイントへ前記トリガベースPHYプロトコルデータユニットを送信する、アンテナと、を備える
通信装置。

【請求項2】

前記アンテナは、前記トリガベースPHYプロトコルデータユニットを前記プライマリチャネルにて送信しない、
請求項１に記載の通信装置。

【請求項3】

前記トリガフレームは、前記エネルギー検出を要求することを示すキャリアセンス要求サブフィールドを含む、
請求項１に記載の通信装置。

【請求項4】

前記ビットマップ情報は８ビットのビットマップ情報である、
請求項１に記載の通信装置。

【請求項5】

前記１つ以上の２０MHzサブチャネルはさらに第２セカンダリチャネルを含む、
請求項１に記載の通信装置。

【請求項6】

前記ビットマップ情報は前記１つ以上の２０MHzサブチャネルの各々のビジーまたはアイドル状態を示し、２０MHz毎に各ビットが対応したビットマップ情報である、
請求項５に記載の通信装置。

【請求項7】

前記回路は、前記トリガフレームを含む前記PHYプロトコルデータユニットを受信した後ショートインターフレームスペースの期間で前記エネルギー検出を行う、
請求項１に記載の通信装置。

【請求項8】

前記回路はネットワーク割当ベクトル値を保持し、前記ネットワーク割当ベクトル値に基づいて前記トリガフレームに応答するか否かを決定する、
請求項１に記載の通信装置。

【請求項9】

前記回路は、前記ネットワーク割当ベクトル値を更新するためのPHYプロトコルデータユニットは前記通信装置が所属する基本サービスセット内で送信されたか否かに基づいて、前記トリガフレームに応答するか否かを決定する、
請求項８に記載の通信装置。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、一般に、１つよりも多くのワイヤレスネットワークが物理的に同じ場所に位置するときにワイヤレス媒体のより効率的な使用を可能にするために新規のマルチチャネル仮想キャリア検知を利用する通信装置および通信方法に関する。

【背景技術】

【0002】

ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ（電気電子学会））８０２．１１ワーキンググループは現在、８０２．１１ａｘタスクグループの下で次世代ＷＬＡＮ（ＷｉｒｅｌｅｓｓＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ワイヤレスローカルエリアネットワーク））技術の標準化を進めている。このタスクグループの主な目標は、アクセスポイント（ＡＰ：ＡｃｃｅｓｓＰｏｉｎｔ）および／または端末局（ｔｅｒｍｉｎａｌＳｔａｔｉｏｎ）（その他の文書では「非ＡＰＳＴＡ」または単にＳＴＡ）の高密度シナリオでシステムスループット／エリアを高めるためにスペクトル効率を改善することである。ＩＥＥＥ８０２．１１ａｘ仕様に基づくデバイスは、一般に高効率（ＨＥ：ＨｉｇｈＥｆｆｉｃｉｅｎｃｙ）デバイスと呼ばれる。提案されている様々な技術の中で、直交周波数分割多元接続（ＯＦＤＭＡ：ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙ－ＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）およびアップリンクマルチユーザ送信は、ＩＥＥＥ８０２．１１ａｘタスクグループがスループット改善目標を達成するために採用した２つの主要な技術である。ＡＰと、そのＡＰとのＷＬＡＮメンバーシップのネゴシエート（関連付けプロセスとして知られる）を行った少なくとも１つのＳＴＡとを有する８０２．１１ＷＬＡＮは、基本サービスセット（ＢＳＳ：ＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ）と呼ばれる。

【0003】

図１は、８０２．１１ａｘの２つのＢＳＳ１００および１４５の例を示し、各ＢＳＳはそれぞれ、ＨＥＡＰと、そのＨＥＡＰに関連付けられたいくつかのＨＥＳＴＡとを含む。ＳＴＡのＢＳＳのチャネルと同じチャネルで動作し、かつ部分的または全体的にＳＴＡの無線カバレッジ内にあるＢＳＳは、重複基本サービスセット（ＯＢＳＳ：ＯｖｅｒｌａｐｐｉｎｇＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ）として知られている。図１では、ＳＴＡ２１２０がＡＰ１１０１に関連付けられていると仮定すると、ＢＳＳ１４５はＳＴＡ２１２０に関してＯＢＳＳと見なされる。

【0004】

８０２．１１ａｘデバイスを含む８０２．１１デバイスの媒体アクセス制御（ＭＡＣ：ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）プロトコルは、ワイヤレス媒体を共有するために競合ベースキャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ：ＣａｒｒｉｅｒＳｅｎｓｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓｗｉｔｈＣｏｌｌｉｓｉｏｎＡｖｏｉｄａｎｃｅ）プロトコルを使用する。衝突回避が、ランダムバックオフの使用を通して達成される一方で、ＣＳＭＡは、物理的および仮想的なキャリア検知（ＣＳ：ＣａｒｒｉｅｒＳｅｎｓｅ）メカニズムの使用を含む。物理ＣＳメカニズムは、物理層（ＰＨＹ：Ｐｈｙｓｉｃａｌｌａｙｅｒ）によって提供され、ワイヤレス媒体の実際の検知（プリアンブル検出（ＰＤ：ＰｒｅａｍｂｌｅＤｅｔｅｃｔｉｏｎ）もしくはエネルギー検出（ＥＤ：ＥｎｅｒｇｙＤｅｔｅｃｔｉｏｎ）のいずれかまたはこれら両方）を含む。仮想ＣＳメカニズムは、ＭＡＣ層によって提供され、ネットワーク割当ベクトル（ＮＡＶ：ＮｅｔｗｏｒｋＡｌｌｏｃａｔｉｏｎＶｅｃｔｏｒ）を利用する。

【0005】

ＮＡＶは、ほとんどのＩＥＥＥ８０２．１１フレームで通知される継続期間（ｄｕｒａｔｉｏｎ）情報に基づく、媒体のその後のトラフィックの予測を保持する。この継続期間は、ＭＡＣヘッダに含まれてもよく、および／またはもしあるならばＰＨＹヘッダ内の送信機会（ＴＸＯＰ：ＴｒａｎｓｍｉｔＯｐｐｏｒｔｕｎｉｔｙ）継続期間から取得されてもよい。ＴＸＯＰ継続期間は、特定のＳＴＡがワイヤレス媒体に対してフレーム交換シーケンスを開始する権利を有する期間を表す。物理ＣＳまたは仮想ＣＳのいずれかが、媒体がビジーであることを示したとき、デバイスは、肯定応答（Ａｃｋ：Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）フレームまたはブロック肯定応答フレームなどの特定のフレームを除いて信号を送信することを許可されない。ＯＢＳＳの存在下におけるチャネルアクセスメカニズムの効率を改善するために、８０２．１１ａｘは、２つのＮＡＶの使用を承認した。１つはＢＳＳ内ＮＡＶとして知られ、もう１つは基本ＮＡＶとして知られる。ＢＳＳ内ＮＡＶは、適用可能な場合、ＢＳＳ内として、すなわちＳＴＡが関連付けられているＢＳＳとして識別されるＰＨＹプロトコルデータユニット（ＰＰＤＵ：ＰＨＹｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ）からのＮＡＶ値を格納するために使用される。一方、基本ＮＡＶは、適用可能な場合、ＢＳＳ間ＰＰＤＵ、すなわちＯＢＳＳＰＰＤＵからの、またはＢＳＳ内もしくはＢＳＳ間として識別することができないＰＰＤＵからの別のＮＡＶ値を格納するために使用される。

【先行技術文献】

【非特許文献】

【0006】

【文献】ＩＥＥＥ８０２．１１－１５／０１３２ｒ１７，ＳｐｅｃｉｆｉｃａｔｉｏｎＦｒａｍｅｗｏｒｋｆｏｒＴＧａｘ，Ｍａｙ２０１５

【文献】ＩＥＥＥＳｔｄ８０２．１１－２０１２

【文献】ＩＥＥＥ８０２．１１－１６／００２４ｒ１，ＰｒｏｐｏｓｅｄＴＧａｘｄｒａｆｔｓｐｅｃｉｆｉｃａｔｉｏｎ

【文献】ＩＥＥＥ８０２．１１－１６／００５４ｒ１，ＵＬＭＵＣＣＡＲｅｓｐｏｎｓｅ

【発明の概要】

【発明が解決しようとする課題】

【0007】

ＳＴＡの基本ＮＡＶがＯＢＳＳ送信によって非ゼロ値に設定されているとき、仮想ＣＳは、ビジーを示すため、アップリンクマルチユーザチャネル検知（ＵＬＭＵＣＳ：ＵｐｌｉｎｋＭｕｌｔｉ－ＵｓｅｒＣｈａｎｎｅｌＳｅｎｓｉｎｇ）規則は、割り当てられたＲＵを含む２０ＭＨｚチャネルに対するエネルギー検出がそのチャネルがアイドルであることを示した場合でも、トリガフレームによって割り当てられたＲＵでＳＴＡがＨＥトリガベースＰＰＤＵを送信することを禁止する。これは、ＳＴＡにとっての送信機会の喪失につながり、したがって、ＯＢＳＳトラフィックの存在下でのアップリンクマルチユーザ送信の効率を低下させる。

【0008】

本開示の非限定的で例示的な一実施形態は、ＯＢＳＳトラフィックの存在下でのアップリンクマルチユーザ送信の効率の改善を助けることができる通信装置および通信方法を提供する。

【0009】

一般的な一態様では、本明細書で開示される技術は、通信装置であって、継続期間フィールドを含むＰＨＹ層データユニットを動作中に受信する受信部であって、継続期間フィールドが、通信装置が高効率（ＨＥ）トリガベース（ＴＢ）ＰＨＹ層データユニットの送信を禁止される継続期間を示す継続期間情報を含む受信部と、動作帯域幅内の各サブチャネルに関してビジーまたはアイドルの帯域幅情報を示すＰＨＹ－ＣＣＡ（クリアチャネル評価）プリミティブパラメータを動作中に発行する物理（ＰＨＹ）層回路と、媒体アクセス制御（ＭＡＣ）回路であって、継続期間情報に基づいて、示された継続期間が現在のネットワーク割当ベクトル（ＮＡＶ）値よりも大きいとき、かつ通信装置が受信したＰＨＹ層データユニットのターゲット受信者ではないと判断されたときに、ＮＡＶ値を動作中に更新し、また、ＨＥＴＢＰＨＹ層データユニットが送信されるべきリソースユニット（ＲＵ）を含む少なくとも１つのサブチャネルのビジー／アイドル状態を帯域幅情報に基づいて動作中に判断する媒体アクセス制御（ＭＡＣ）回路とを備え、ＭＡＣ回路が、更新されたＮＡＶ値および少なくとも１つのサブチャネルのビジー／アイドル状態に基づいてＨＥＴＢＰＨＹ層データユニットの送信を動作中に制御する通信装置を特徴とする。

【0010】

これらの一般的なおよび特定の態様は、デバイス、システム、方法、およびコンピュータプログラムならびにデバイス、システム、方法、およびコンピュータプログラムの任意の組み合わせを使用して実施され得る。

【0011】

本開示で説明される通信装置および通信方法は、ＯＢＳＳトラフィックの存在下でのアップリンクマルチユーザ送信の効率の改善を助けることができる。

【0012】

開示された実施形態のさらなる利益および利点は、明細書および図面から明らかになる。利益および／または利点は、明細書および図面の様々な実施形態および特徴によって個別に得られてもよく、これらは、そのような利益および／または利点の１つ以上を得るためにすべてが用意される必要はない。

【図面の簡単な説明】

【0013】

【図1】本開示の実施形態が適用され得る重複ワイヤレスネットワークの図である。

【図2】ＮＡＶ設定手順を強調した例示的なフレーム交換シーケンスのタイミング図である。

【図3A】８０２．１１ａｘで導入された２つのＮＡＶがどのように更新されるかを明確にする、別の例示的なフレーム交換シーケンスのタイミング図である。

【図3B】広帯域チャネルにおける２０ＭＨｚチャネルの命名規則を示す図である。

【図4】８０２．１１ａｘにおけるＵＬＭＵＣＳ規則を示す、例示的なアップリンクマルチユーザ送信の図である。

【図5】本開示で対処される技術的問題を示す図である。

【図6】ＵＬＭＵＣＳメカニズムに関連する様々なパラメータが図４に示されているフレームシーケンスに関してどのように更新されるかを示す表である。

【図7A】第１の実施形態で導入されるマルチチャネル仮想キャリア検知（ＣＳ）を示すフレーム交換シーケンスの例である。

【図7B】第１の実施形態による、ＮＡＶのＢＷフィールドの符号化スキームを示す表である。

【図8A】第１の実施形態によるマルチチャネル仮想ＣＳに関する規則を示すフローチャートである。

【図8B】第１の実施形態による修正されたマルチチャネル仮想ＣＳ規則に基づいて、ＵＬＭＵＣＳメカニズムに関連する様々なパラメータがどのように更新されるかを示す表である。

【図9】３つの重複ワイヤレスネットワークを示す図である。

【図10A】第１の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新規則を示すフレーム交換シーケンスの例である。

【図10B】第１の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新規則を示すフローチャートである。

【図11A】第１の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新に関する代替規則を示すフレーム交換シーケンスの例である。

【図11B】第１の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新に関する代替規則を示すフローチャートである。

【図11C】第１の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新に関する代替規則を示す別のフローチャートである。

【図12】第１の実施形態に従ってＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブに関して提案された追加のメンバを示す表である。

【図13A】本開示の第２の実施形態を示す例示的なＵＬＭＵ送信である。

【図13B】本開示の第２の実施形態による、チャネル状態を記録するために使用されるビットマップの図である。

【図14】第２の実施形態で導入されるマルチチャネル仮想キャリア検知（ＣＳ）を示すフレーム交換シーケンスの例である。

【図15】開示されているマルチチャネル仮想キャリア検知を実施する例示的なＳＴＡの簡略ブロック図である。

【図16】開示されているマルチチャネル仮想キャリア検知を実施する例示的なＳＴＡの詳細ブロック図である。

【図17】第３の実施形態によるマルチチャネル仮想キャリア検知（ＣＳ）を示すフレーム交換シーケンスの例である。

【図18】第３の実施形態による修正されたマルチチャネル仮想ＣＳ規則に基づいて、ＵＬＭＵＣＳメカニズムに関連する様々なパラメータがどのように更新されるかを示す表である。

【図19】第３の実施形態によるマルチチャネルＵＬＭＵＣＳメカニズムに関する規則を示すフローチャートである。

【図20】ＳＴＡが、受信したＰＰＤＵからチャネル帯域幅情報をどのように取得するかを列挙した表である。

【図21】第３の実施形態に従ってＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブに関して提案された追加のメンバを示す表である。

【図22】第４の実施形態による、ＳＴＡによって保持されるＮＡＶのフォーマットおよびＴＸ＿Ａｌｌｏｗｅｄフィールドの符号化である。

【図23】第４の実施形態によるマルチチャネル仮想キャリア検知（ＣＳ）を示すフレーム交換シーケンスの例である。

【図24】第４の実施形態によってなされる改善をより強調するように、本開示で対処される技術的問題を示す別の図である。

【図25】第４の実施形態による修正されたマルチチャネル仮想ＣＳ規則に基づいて、ＵＬＭＵＣＳメカニズムに関連する様々なパラメータがどのように更新されるかを示す表である。

【図26】第４の実施形態によるマルチチャネルＵＬＭＵＣＳメカニズムに関する規則を示すフローチャートである。

【図27】第４の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新規則を示すフレーム交換シーケンスの例である。

【図28】第４の実施形態による、複数のＯＢＳＳの存在下での基本ＮＡＶの更新規則を示すフローチャートである。

【発明を実施するための形態】

【0014】

本開示は、以下の図および実施形態の助けを借りることでよりよく理解することができる。本明細書で説明される実施形態は、本質的に例示に過ぎず、本開示の可能な用途および使用のいくつかを説明するために使用され、本明細書で明示的に説明されていない代替実施形態に関して本開示を限定するものとして解釈されるべきではない。

【0015】

先に説明したように、ダウンリンク方向およびアップリンク方向の両方でＯＦＤＭＡを使用するマルチユーザ送信は、ＩＥＥＥ８０２．１１ａｘタスクグループがスループット改善目標を達成するために採用した主要な技術である。ダウンリンク方向では、ＡＰがすべてのマルチユーザフレームを送信するため、マルチユーザ送信はアップリンク方向に比べて比較的簡単である。ダウンリンク（ＤＬ）マルチユーザＰＰＤＵは、各個別のＰＨＹサービスデータユニット（ＰＳＤＵ：ＰＨＹＳｅｒｖｉｃｅＤａｔａＵｎｉｔ）が搬送される狭帯域チャネル（リソースユニットまたはＲＵとして知られている）に関する情報を搬送するワイドチャネルＰＨＹヘッダで構成される。アップリンク方向の送信は、ダウンリンク方向よりも複雑である。なぜなら、複数のＳＴＡからの送信の時間同期が必要であり、また異なるＳＴＡからの送信が互いに確実に干渉しないようにしなければならない、すなわち、各ＳＴＡに一意のＲＵを割り当てなければならないからである。これは、ＩＥＥＥ８０２．１１ａｘでは、ＡＰによって送信されるトリガフレームと呼ばれる特殊な制御フレームによって達成される。

【0016】

トリガフレームは、ＵＬ送信に使用される、リソースユニット（ＲＵ）割り当て、アップリンク（ＵＬ：Ｕｐｌｉｎｋ）ＰＰＤＵ長、ＭＣＳなどの情報を含む。さらに、トリガフレームは、ＵＬＭＵ送信の前にキャリア検知が要求されるかどうかをＳＴＡに知らせる「ＣＳ要求サブフィールド」も含む。トリガフレームを受信すると、トリガフレームにおいてＲＵを割り当てられたＳＴＡは、トリガフレームの最後からショートインターフレームスペース（ＳＩＦＳ：ＳｈｏｒｔＩｎｔｅｒｆｒａｍｅＳｐａｃｅ）の期間後にＵＬマルチユーザ（ＭＵ：ｍｕｌｔｉ－ｕｓｅｒ）ＰＰＤＵの、それぞれのＵＬフレームを送信することができる。トリガフレーム内の「ＣＳ要求サブフィールド」の値が１である場合、ＳＴＡは、ＵＬＭＵ送信に参加するためにＳＴＡが仮想ＣＳを考慮し、ＲＵがＳＴＡに割り当てられているすべての２０ＭＨｚチャネルに対してエネルギー検出も実行するように要求されることを述べたアップリンクマルチユーザチャネル検知（ＵＬＭＵＣＳ）手順に従うように要求される。仮想ＣＳがアイドルであり、トリガフレームにおいて割り当てられたＲＵを含むすべての２０ＭＨｚチャネルもアイドルであると見なされた場合にのみ、ＳＴＡは、ＨＥトリガベースＰＰＤＵを送信することを許可される。２０ＭＨｚチャネルがすべてアイドルであるわけではない場合、ＳＴＡは、割り当てられたＲＵで送信することを許可されない。

【0017】

図１を参照すると、２つの重複ＢＳＳ（ＯＢＳＳ）が示されている。第１のＢＳＳであるＢＳＳ１１００は、ＡＰであるＡＰ１１０１と、ＡＰ１に関連付けられた４つのＳＴＡであるＳＴＡ１１１０、ＳＴＡ２１２０、ＳＴＡ３１３０、およびＳＴＡ４１４０とを含む。第２のＢＳＳであるＢＳＳ２１４５は、ＡＰであるＡＰ２１０２と、ＡＰ２に関連付けられた２つのＳＴＡであるＳＴＡ５１５０およびＳＴＡ６１６０とを含む。また、ＡＰ１１０１およびＡＰ２１０２の周りの円は、それぞれＡＰ１およびＡＰ２の無線カバレッジエリアを表す。図１から分かるように、ＳＴＡ２１２０は、ＡＰ１の無線カバレッジの縁に位置し、その上偶然ＡＰ２の無線カバレッジ内にある。したがって、ＳＴＡ２１２０に関して、ＢＳＳ２１４５は、ＯＢＳＳと見なされる。受信されるフレームが属するＢＳＳの識別情報は、このフレームを搬送するＨＥＰＰＤＵのＰＨＹヘッダ内のＢＳＳカラーフィールドをチェックすることによって、またはこのフレームのＭＡＣヘッダ内の基本サービスセット識別子（ＢＳＳＩＤ：ＢａｓｉｃＳｅｒｖｉｃｅＳｅｔＩｄｅｎｔｉｆｉｅｒ）フィールドをチェックすることによってこのフレームの受信者により判断され得る。

【0018】

図２は、８０２．１１ＮＡＶ設定手順を強調した例示的なフレーム交換シーケンス２００を示す。ＡＰ１１０１は、データフレームをＳＴＡ１１１０に送信しようとしており、送信を保護するために、ＡＰ１は、最初に送信要求（ＲＴＳ：ＲｅｑｕｅｓｔＴｏＳｅｎｄ）フレームをＳＴＡ１に送信し、これに対してＳＴＡ１は、ＲＴＳフレームの最後からショートインターフレームスペース（ＳＩＦＳ）の期間後に送信される送信可（ＣＴＳ：ＣｌｅａｒＴｏＳｅｎｄ）フレームで応答する。ＲＴＳフレーム内の継続期間フィールドは、ＲＴＳフレームの最後と、データフレームに応答して送信されるＡｃｋフレームの最後との間の期間を示す値に設定される。目的の受信者ＳＴＡ１を除いて、ＲＴＳフレームを受信したすべてのＳＴＡは、それらの既存のＮＡＶ値がより小さい場合、それらのＮＡＶをＲＴＳフレーム内の継続期間フィールドの値に更新する。同様に、目的の受信者ＡＰ１を除いて、ＣＴＳフレームを受信したすべてのＳＴＡは、それらの既存のＮＡＶ値がより小さい場合、それらのＮＡＶをＣＴＳフレーム内の継続期間フィールドの値に更新する。このようにして、ＡＰ１およびＳＴＡ１の無線カバレッジ内にあるすべてのＳＴＡは、それらのＮＡＶセットを有することになる。ＣＴＳフレームの受信に成功すると、ＡＰ１は、ＣＴＳフレームの最後からＳＩＦＳの期間後にデータフレームを送信し、これに対してＳＴＡ１は、Ａｃｋフレームで応答する。ＲＴＳフレーム／ＣＴＳフレームを受信したＳＴＡ２１２０および他のすべてのＳＴＡは、それらのＮＡＶセットを有するため、この継続期間中のこれらへの送信は許可されず、この結果、ＡＰ１によるデータフレームの送信は確実に保護される。

【0019】

図３Ａは、図１の２つのＢＳＳ１００および１４５内における例示的なフレーム交換シーケンス３００を示し、８０２．１１ａｘで導入された２種類のＮＡＶ、すなわちＢＳＳ内ＮＡＶおよび基本ＮＡＶを更新するための手順を強調している。２種類のＮＡＶを保持することにより、特定の条件下で周波数リソースのより効率的な空間的再利用が可能になる。この例は、２つの進行中の送信シーケンスを示している。１つ目は、ＡＰ１１０１とＳＴＡ１１１０との間の、ＢＳＳ１１００におけるＴＸＯＰ１３１０であり、２つ目は、ＡＰ２１０２とＳＴＡ５１５０との間の、ＢＳＳ２１４５における第２のＴＸＯＰ２３４０である。ＤＬＰＰＤＵ３１２を受信すると、ＢＳＳカラーフィールドもしくはＢＳＳＩＤフィールドのいずれかまたはこれら両方をチェックすることによって、ＳＴＡ２１２０は、ＰＰＤＵ３１２はＢＳＳ内ＰＰＤＵであると判断し、ＳＴＡ２は、ＰＰＤＵ３１２の受信者ではないため、ＳＴＡ２は、そのＢＳＳ内ＮＡＶであるＮＡＶ１３２０を、ＤＬＰＰＤＵ３１２の最後とＴＸＯＰ１の最後との間の期間を示す値に設定する。同様に、ＤＬＰＰＤＵ３４２を受信すると、ＢＳＳカラーフィールドもしくはＢＳＳＩＤフィールドのいずれかまたはこれら両方をチェックすることによって、ＳＴＡ２は、ＰＰＤＵ３４２はＢＳＳ間ＰＰＤＵであると判断し、ＳＴＡ２は、そのＢＳＳ間ＮＡＶであるＮＡＶ２３３０を、ＤＬＰＰＤＵ３４２の最後とＴＸＯＰ２の最後との間の期間を示す値に設定する。

【0020】

図３Ｂを参照すると、４０ＭＨｚ、８０ＭＨｚ、または８０＋８０ＭＨｚもしくは１６０ＭＨｚのチャネルで動作する８０２．１１インフラストラクチャＢＳＳにおける２０ＭＨｚチャネルの命名規則が示されている。これは、広帯域幅チャネルがどのように形成され得るかのほんの一例であり、他の多くの同様の構成が可能である。ＢＳＳが最初にセットアップされるとき、２０ＭＨｚチャネル３５０のうちの１つが、プライマリ２０ＭＨｚチャネルとして指定される。プライマリ２０ＭＨｚチャネルは、単にプライマリチャネルとも呼ばれ、非常に重要な意味を持つ。ＩＥＥＥ８０２．１１の仕様は、ＳＴＡがプライマリ２０ＭＨｚチャネルを含まないチャネルでそれらのアップリンクＰＰＤＵを送信することを許可され得る、アップリンクＯＦＤＭＡベースマルチユーザ送信の場合を除いて、インフラストラクチャＢＳＳにおけるすべての送信がプライマリ２０ＭＨｚチャネルを含むことを要求する。

【0021】

さらに、インフラストラクチャＢＳＳにおいて、すべてのビーコンフレームは、プライマリ２０ＭＨｚチャネルで送信される。プライマリ２０ＭＨｚチャネル以外の２０ＭＨｚチャネルは、非プライマリチャネルと呼ばれる。４０ＭＨｚＢＳＳの４０ＭＨｚチャネルまたはより広いＢＳＳのプライマリ４０ＭＨｚを一緒に形成する、プライマリ２０ＭＨｚチャネルに隣接する２０ＭＨｚチャネル３５５は、セカンダリ２０ＭＨｚチャネルまたは単にセカンダリチャネルと呼ばれる。８０ＭＨｚＢＳＳまたはより広いＢＳＳにおいて、プライマリ２０ＭＨｚチャネル３５０とセカンダリ２０ＭＨｚチャネル３５５は、一緒にプライマリ４０ＭＨｚチャネルを形成する。８０ＭＨｚＢＳＳまたはより広いＢＳＳにおいて、８０ＭＨｚＢＳＳの８０ＭＨｚチャネルまたはより広いＢＳＳのプライマリ８０ＭＨｚチャネルを一緒に形成する、プライマリ４０ＭＨｚチャネルに隣接する４０ＭＨｚチャネル（２つの２０ＭＨｚチャネル３６０および３６５から構成される）は、セカンダリ４０ＭＨｚチャネルと呼ばれる。８０＋８０ＭＨｚＢＳＳまたは１６０ＭＨｚＢＳＳにおいて、プライマリ４０ＭＨｚチャネルとセカンダリ４０ＭＨｚチャネルは、一緒にプライマリ８０ＭＨｚチャネルを形成する。８０＋８０ＭＨｚＢＳＳまたは１６０ＭＨｚＢＳＳにおいて、プライマリ８０ＭＨｚチャネルと一緒に８０＋８０ＭＨｚｚチャネルまたは１６０ＭＨｚチャネルを形成する、プライマリ２０ＭＨｚチャネル３５０を含まない８０ＭＨｚチャネル（４つの２０ＭＨｚチャネル３７０、３７５、３８０、および３８５から構成される）は、セカンダリ８０ＭＨｚチャネルと呼ばれる。１６０ＭＨｚチャネルでは、プライマリ８０ＭＨｚチャネルとセカンダリ８０ＭＨｚチャネルは互いに隣接するが、８０＋８０ＭＨｚチャネルでは、プライマリ８０ＭＨｚチャネルとセカンダリ８０ＭＨｚチャネルは互いに隣接する必要はなく、動作周波数帯域の異なる部分に位置してもよい。

【0022】

図４を参照すると、８０２．１１ａｘにおけるＵＬＭＵＣＳ手順を明確にするために、例示的なＵＬＭＵ送信シーケンス４００が示されている。アップリンクマルチユーザ（ＵＬＭＵ：ＵｐｌｉｎｋＭｕｌｔｉ－Ｕｓｅｒ）送信は、トリガフレーム４１０と呼ばれる特殊な制御フレームを送信することによってＡＰにより開始される。トリガフレーム４１０は、ＵＬ送信のためにＳＴＡによって使用される、リソースユニット（ＲＵ）割り当て、ＰＰＤＵ長、ＭＣＳなどの情報を含む。トリガフレーム４１０を受信すると、トリガフレームにおいてＲＵを割り当てられたＳＴＡは、ワイヤレス媒体を競合する必要なく、トリガフレームの最後からＳＩＦＳの期間後にＵＬマルチユーザＰＰＤＵの、それぞれのＵＬフレームを送信することができる。

【0023】

８０２．１１ａｘにおけるＵＬＭＵＣＳ手順には、ＵＬＭＵ送信に参加するために、１に設定されたＣＳ要求フィールドを有するトリガフレームにおいてＲＵを割り当てられたＳＴＡは、仮想ＣＳを考慮するよう要求され、また、ＲＵがそのＳＴＡに割り当てられているすべての２０ＭＨｚチャネルで、エネルギー検出に基づくクリアチャネル評価（ＥＤベースＣＣＡ）を実行すると述べられている。ＳＴＡは、仮想ＣＳがアイドルであり、その上、割り当てられたＲＵを含むすべての２０ＭＨｚチャネルがＥＤベースＣＣＡによってアイドルであると見なされる場合にのみ、そのＵＬＰＰＤＵ（ＨＥトリガベースＰＰＤＵ）の送信を許可される。２０ＭＨｚチャネルがすべてアイドルであるわけではない場合、ＳＴＡは、割り当てられたＲＵでの送信を許可されない。ＢＳＳ内ＮＡＶと基本ＮＡＶとの両方のカウンタ値がゼロである場合、仮想ＣＳはアイドルであると見なされる。この例では、図１のＢＳＳ１１００は８０ＭＨｚチャネルで動作しており、ＣＨ１、ＣＨ２、ＣＨ３、およびＣＨ４がプライマリ２０ＭＨｚチャネル、セカンダリ２０ＭＨｚチャネル、ターシャリ２０ＭＨｚチャネル、およびクォータナリ２０ＭＨｚチャネルを示すものとする。８０２．１１の用語では、ＣＨ１は、プライマリ２０ＭＨｚチャネルまたは単にプライマリチャネルと呼ばれ、ＣＨ２は、セカンダリ２０ＭＨｚチャネルまたは単にセカンダリチャネルと呼ばれ、ＣＨ３とＣＨ４は、一緒にセカンダリ４０ＭＨｚチャネルを形成する。

【0024】

ＳＴＡがＡＰ１１０１からトリガフレーム４１０を受信した瞬間、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３、およびＳＴＡ４の無線カバレッジエリア内にプライマリ２０ＭＨｚチャネルＣＨ１で進行中の送信はなく、４つのＳＴＡすべてのＢＳＳ内ＮＡＶと基本ＮＡＶとの両方がゼロに設定される。しかしながら、４６０によって示されているように、ＳＴＡ２の無線カバレッジエリア内にＣＨ３で進行中の送信がある。ＡＰ１１０１は、ＣＨ１では１つの１０６トーンＲＵをそれぞれＳＴＡ１１１０およびＳＴＡ４１４０に割り当て、ＣＨ２では１つの２４２トーンＲＵをＳＴＡ３１３０に割り当て、ＣＨ３およびＣＨ４をカバーする４８４トーンＲＵをＳＴＡ２１２０に割り当てるトリガフレーム４１０を送信することによってＵＬＭＵ送信シーケンスを開始する。ＥＤベースＣＣＡと仮想ＣＳとの両方がアイドルを返すため、ＳＴＡ１、ＳＴＡ３、およびＳＴＡ４は、それぞれのＵＬＰＰＤＵ４２０、４４０、および４３０を送信する。しかしながら、ＳＴＡ２の場合、仮想ＣＳはアイドルを返すが、ＥＤベースＣＣＡは、ＣＨ３でビジーを返す。ＳＴＡ２に割り当てられたＲＵを含む２０ＭＨｚチャネルがすべてアイドルであるわけではないため、ＵＬＭＵＣＳ規則に従って、ＳＴＡ２はそのＵＬＰＰＤＵ４５０の送信を禁止される。

【0025】

図５は、わずかに異なるチャネル状態における例示的なＵＬＭＵ送信シーケンス４００を示す。ＳＴＡがＡＰ１１０１からトリガフレーム４１０を受信した瞬間、ＳＴＡ１、ＳＴＡ３、およびＳＴＡ４の無線カバレッジエリア内にプライマリ２０ＭＨｚチャネルで進行中の送信はなく、ＳＴＡのＢＳＳ内ＮＡＶと基本ＮＡＶとの両方がゼロに設定される。しかしながら、送信シーケンス５００によって示されているように、ＢＳＳ２１４５ではＳＴＡ２の無線カバレッジエリア内にプライマリチャネルＣＨ１およびセカンダリチャネルＣＨ２で進行中のＯＢＳＳ送信がある。ＡＰ２１０２は、ＢＳＳ２では、ＳＴＡ５１５０およびＳＴＡ６１６０にＲＵを割り当てるためのトリガフレーム５１０を送信することによってＵＬＭＵ送信を開始する。トリガフレーム５１０からＳＩＦＳの後で、ＳＴＡ５およびＳＴＡ６は、それぞれの割り当てられたＲＵでそれぞれのＵＬＰＰＤＵを送信する。トリガフレーム５１０を搬送するＤＬＰＰＤＵを受信すると、ＳＴＡ２は、それがＯＢＳＳＰＰＤＵであると判断し、その基本ＮＡＶを非ゼロ値に設定する。

【0026】

図６の表６００は、図５に示したＵＬＭＵ送信シーケンス中のＳＴＡ２に関して、ＵＬＭＵＣＳメカニズムに関連する様々なパラメータを列挙している。プライマリチャネルＣＨ１での送信はＯＢＳＳに属するため、ＳＴＡ２の基本ＮＡＶは非ゼロ値に設定され、ＢＳＳ内ＮＡＶがゼロであっても、仮想ＣＳはビジーを示す。同様に、ＥＤベースＣＣＡは、ＣＨ１とＣＨ２でビジーを返し、ＣＨ３とＣＨ４でアイドルを返す。ＵＬＭＵＣＳ規則によれば、ＳＴＡ２のためにＲＵを含む両方のチャネル（ＣＨ３およびＣＨ４）で進行中の送信がなくても、仮想ＣＳはビジーを示すため、ＵＬＭＵＣＳは、４つの２０ＭＨｚのすべてで媒体はビジーであると見なし、その結果、ＳＴＡ２のＵＬＰＰＤＵ４５０の送信は許可されない。これは、基本ＮＡＶが過剰な保護になっている場合であると見なすことができる。すなわち、ＳＴＡ２が、ＣＨ３およびＣＨ４でそのＵＬＰＰＤＵ４５０を送信することを許可されたとしても、その送信は、ＯＢＳＳ送信に対していかなる干渉も引き起こさず、より高いチャネル使用効率をもたらしたであろう。

【0027】

上に示した欠点は、ＮＡＶ（ベースラインＮＡＶまたはＢＳＳ内ＮＡＶまたは基本ＮＡＶ）がもっぱらプライマリ２０ＭＨｚチャネルのアクティビティに基づいており、非プライマリチャネルの状態に関する情報を考慮／提供しないという事実によって生じている。正しいＰＰＤＵの受信によってプライマリ２０ＭＨｚがビジーである限り、ＮＡＶは設定され、残りのセカンダリチャネルの状態は記録されない。８０２．１１ａｘはＯＦＤＭＡベース狭帯域送信を導入しているため、この過剰な保護を回避することができれば、チャネル再利用効率をさらに改善することができる。

【0028】

上記の知見に基づいて、本出願の発明者らは、本開示に到達した。ＯＢＳＳトラフィックの存在下でアップリンクマルチユーザ送信の効率を改善する通信方法および通信装置が開示される。開示される方法によれば、周波数次元がＮＡＶに追加され、ＮＡＶは、広帯域チャネルの一部を形成するプライマリチャネルがビジーである継続期間を記録するだけでなく、広帯域チャネルの他の非プライマリチャネルのどれがビジーであるかも記録する。このビジーチャネルの情報を参照することによって、ＳＴＡは、どのチャネルがアイドルであり、ビジーチャネルに干渉を引き起こすことなく同時送信に使用され得るかを容易に推測することができる。

【0029】

本開示において提案される効率的なマルチチャネル仮想キャリア検知のための様々な実施形態は、以下の段落において詳細に説明される。

【0030】

＜第１の実施形態＞
先に指摘したように、現在、ＮＡＶ（ベースラインＮＡＶまたはＢＳＳ内ＮＡＶまたは基本ＮＡＶ）は、もっぱらプライマリ２０ＭＨｚチャネルのアクティビティに基づいており、非プライマリチャネルの状態に関する情報を考慮／提供しない。正しいＰＰＤＵの受信によってプライマリ２０ＭＨｚチャネルがビジーである限り、ＮＡＶは設定され、残りの非プライマリチャネルの状態は記録されない。現在のＮＡＶメカニズムのこの制限を克服するために、第１の実施形態は、ＮＡＶがプライマリチャネルがビジーである継続期間を記録するだけでなく、ビジーである非プライマリチャネルも記録するように周波数次元をＮＡＶに追加する。このために、ＢＷ（ｂａｎｄｗｉｄｔｈ（帯域幅））と呼ばれるフィールドが、ＮＡＶを設定するＰＰＤＵまたはフレームの帯域幅情報を記録するためにＮＡＶに追加される。ＮＡＶを設定するＰＰＤＵの帯域幅は常にプライマリ２０ＭＨｚチャネルを含むため、ＢＷフィールドは、どの非プライマリチャネルがビジーであるかを示す。このビジーチャネルの情報によって、ＳＴＡは、どのチャネルがアイドルであり、ビジーチャネルに干渉を引き起こすことなく同時送信に使用され得るかを容易に推測することができる。

【0031】

図７Ａを参照すると、８０ＭＨｚのＢＳＳにおけるＮＡＶの周波数次元の概念を視覚的に示すために一連の例示的なフレーム交換シーケンスが示されている。図７Ａの上半分は、異なる帯域幅の３つの送信シーケンス、すなわち８０ＭＨｚのＴＸＯＰ１７１２、４０ＭＨｚのＴＸＯＰ２７２２、および２０ＭＨｚのＴＸＯＰ３７３２を示す。各送信シーケンスは、ＡＰと、このＡＰと同じＢＳＳに属する１つ以上のＳＴＡとの間のＰＰＤＵの交換を含む。例として、送信シーケンスの最初のＰＰＤＵは、ＵＬＭＵ送信のためにＲＵを選択されたＳＴＡに割り当てるトリガフレームであり、その後にＳＴＡからのＨＥトリガベースＰＰＤＵが続き、肯定応答フレームを搬送する、ＡＰからのＤＬＰＰＤＵで終わってもよい。この例では、ＣＨ１、ＣＨ２、ＣＨ３、およびＣＨ４は、それぞれプライマリ２０ＭＨｚチャネル、セカンダリ２０ＭＨｚチャネル、ターシャリ２０ＭＨｚチャネル、およびクォータナリ２０ＭＨｚチャネルを示す。図７Ａの下半分は、本開示によって提案される、第三者ＳＴＡによって保持される二次元ＮＡＶを視覚的に表している。この例に関連する時点は、ｔ０、ｔ１、ｔ２、ｔ３、ｔ４、およびｔ５によって示されている。

【0032】

進行中の送信の無線カバレッジ内にあり、かつこの送信の送信者でも受信者でもないＳＴＡは、その送信に関して第三者ＳＴＡと見なされる。ＴＸＯＰ１７１２の最初のＰＰＤＵ７１０を受信すると、第三者ＳＴＡは、例えば、ＰＰＤＵによって搬送されたフレームのＭＡＣヘッダ内の受信者アドレスを読み取ることによって、またはＰＰＤＵ７１０で搬送されたトリガフレームのユーザ情報フィールドのＡＩＤ１２サブフィールドを読み取ることなどによって第三者ＳＴＡ自体がＰＰＤＵ７１０の受信者ではないと判断する。

【0033】

ＳＴＡは、既存のＮＡＶ規則に従って、ＳＴＡ自体がＰＰＤＵ７１０の受信者ではないと判断したら、ＮＡＶ継続期間を、時間ｔ０から時間ｔ１までの時間期間に設定し、これにより、ＳＴＡはＴＸＯＰ１７１２の最後である時間ｔ１まで送信することを禁止される。ＮＡＶ継続期間を記録することに加えて、第１の実施形態によれば、ＳＴＡはまた、受信したＰＰＤＵ７１０の帯域幅である８０ＭＨｚをＮＡＶのＢＷフィールドとして記録する。二次元ＮＡＶは、ＳＴＡが送信を禁止された時間期間および周波数範囲を表すボックス７１４によって表されている。時間ｔ１において、ＮＡＶ継続期間がゼロまでカウントダウンされると、ＢＷフィールドもゼロにリセットされる。

【0034】

同様に、ＰＰＤＵ７２０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、時間ｔ２からＴＸＯＰ２７２２の最後である時間ｔ３までの時間期間に設定し、一方、ＢＷフィールドは、ＰＰＤＵ７２０の帯域幅である４０ＭＨｚに設定される。これは、ボックス７２４として示されている。さらにチャネル検知規則がそれ相応に修正されれば、特定の条件下で、第三者ＳＴＡは、進行中の送信７２２に干渉を引き起こすことなくｔ２からｔ３までのＮＡＶ継続期間内に非占有チャネルＣＨ３およびＣＨ４で送信することを許可され得る。この結果、非占有セカンダリチャネルのより効率的な再利用が促進される。

【0035】

時間ｔ３において、ＮＡＶ継続期間がゼロまでカウントダウンされると、ＢＷフィールドもゼロにリセットされる。同様に、ＰＰＤＵ７３０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、時間ｔ４から、ＴＸＯＰ３７３２の最後である時間ｔ５までの時間期間に設定し、一方、ＢＷフィールドは、ＰＰＤＵ７３０の帯域幅である２０ＭＨｚに設定される。これは、ボックス７３４として示されている。この場合、第三者ＳＴＡは、進行中の送信７３２に干渉を引き起こすことなく、ｔ４からｔ５までのＮＡＶ継続期間内に非占有チャネルＣＨ２、ＣＨ３、およびＣＨ４で送信することを許可され得る。時間ｔ５において、ＮＡＶ継続期間がゼロまでカウントダウンされると、ＢＷフィールドもゼロにリセットされる。

【0036】

図７Ｂは、ＢＷフィールドの例示的な符号化の表７５０を示す。２ビットを使用して、ＢＷフィールドは、８０２．１１ａｘによってサポートされる４つの異なる帯域幅を表すことができる。値０は、ビジープライマリ２０ＭＨｚを示し、値１は、ビジープライマリ４０ＭＨｚを示し、値２は、ビジープライマリ８０ＭＨｚを示し、値３は、１６０ＭＨｚチャネル全体または８０＋８０ＭＨｚチャネルがビジーであることを示す。７５０に列挙されているＢＷ符号化によれば、図７Ａに示した例において、ＢＷフィールドは、ＮＡＶ設定７１４に関しては２に設定され、ＮＡＶ設定７２４に関しては１に設定され、ＮＡＶ設定７３４に関しては０に設定される。

【0037】

ＮＡＶに周波数次元を追加するという概念は、図３Ａで説明した２つのＮＡＶに簡単に拡張することができる。ＮＡＶの一方またはＮＡＶの両方は、それぞれのＢＳＳにおける進行中の送信の帯域幅を記録するように拡張され得る。図５に戻って参照すると、ＳＴＡ２がＵＬＰＰＤＵ４５０を送信することを禁止した過剰保護ＮＡＶは、進行中のＯＢＳＳ送信の帯域幅を基本ＮＡＶのＢＷフィールドとして記録するという概念を適用するのと同時に、仮想ＣＳ規則およびＵＬＭＵＣＳメカニズムに変更を加えることによって克服され得る。

【0038】

先に説明したように、図５に示した例では、ＳＴＡ２の基本ＮＡＶは、それがＡＰ１１０１からトリガフレーム４１０を受信した瞬間に非ゼロ値に設定され、この結果、仮想ＣＳは、ＳＴＡ２に関してビジーとなる。現在のＵＬＭＵＣＳ規則によれば、ＣＨ３およびＣＨ４で進行中の送信がなくても、仮想ＣＳはビジーを示すため、ＵＬＭＵＣＳメカニズムは、４つのチャネルのすべてで媒体はビジーであると見なし、その結果、ＳＴＡ２のためにＲＵを含む両方のチャネルがビジーでないにもかかわらず、ＳＴＡ２のＵＬＰＰＤＵ４５０の送信は許可されない。現在の仮想ＣＳ規則は、ＮＡＶのいずれか一方がビジーである限り、非プライマリチャネルの実際の状態に関係なく、広帯域チャネル全体に関してビジーを示す。

【0039】

図８Ａは、基本ＮＡＶに帯域幅フィールドを追加することによって、２０ＭＨｚチャネルごとに仮想ＣＳ規則をどのように示すことができるかを説明するフローチャート８００を示す。プライマリ２０ＭＨｚチャネルから開始され、トリガフレームが受信される広帯域チャネルの各２０ＭＨｚチャネルに関して、プロセスは、ＳＴＡが、１に設定されたＣＳ要求フィールドを有し、ＲＵをＳＴＡに割り当てるトリガフレームを受信したとき、ステップ８１０で開始される。トリガフレームにおいてＣＳ要求フィールドが１に設定されているため、ＳＴＡは、割り当てられたＲＵでＨＥトリガベースＰＰＤＵを送信する前にＵＬＭＵＣＳを実行することを要求される。ステップ８２０で、ＢＳＳ内ＮＡＶが非ゼロである場合、プロセスは、仮想ＣＳがその２０ＭＨｚチャネルに関してビジーを示すステップ８３０に進んで、プロセスは終了し、もしあれば次の２０ＭＨｚチャネルに進む。しかしながら、ステップ８２０でＢＳＳ内ＮＡＶがゼロである場合、プロセスはステップ８４０に進む。

【0040】

ステップ８４０で、基本ＮＡＶ継続期間がゼロである場合、プロセスは、仮想ＣＳがその２０ＭＨｚチャネルに関してアイドルを示すステップ８７０に進んで、プロセスは終了し、もしあれば次の２０ＭＨｚチャネルに進む。しかしながら、ステップ８４０で基本ＮＡＶが非ゼロである場合、プロセスはステップ８５０に進む。ステップ８５０で、２０ＭＨｚチャネルが、基本ＮＡＶのＢＷフィールドによってビジーチャネルのうちの１つとして示される場合、プロセスは、仮想ＣＳがその２０ＭＨｚチャネルに関してビジーを示すステップ８６０に進んで、プロセスは終了し、もしあれば次の２０ＭＨｚチャネルに進む。しかしながら、ステップ８５０で、２０ＭＨｚチャネルが、基本ＮＡＶのＢＷフィールドによってビジーチャネルのうちの１つとして示されない場合、プロセスは、仮想ＣＳがその２０ＭＨｚチャネルに関してアイドルを示すステップ８７０に進んで、プロセスは終了し、もしあれば次の２０ＭＨｚチャネルに進む。修正された仮想ＣＳ規則は、個々の２０ＭＨｚチャネルの各々に関して仮想ＣＳが通知されることを可能にするため、ＵＬＭＵＣＳメカニズムも、個々の２０ＭＨｚチャネルの各々に関してビジー／アイドルが通知されるように修正される。エネルギー検出（ＥＤ：ｅｎｅｒｇｙ－ｄｅｔｅｃｔ）または仮想ＣＳのいずれかが、特定の２０ＭＨｚチャネルでビジーを返した場合、その２０ＭＨｚチャネルはビジーであると見なされる。

【0041】

エネルギー検出（ＥＤ）と仮想ＣＳとの両方が、特定の２０ＭＨｚチャネルでアイドルを返した場合、その２０ＭＨｚチャネルはアイドルであると見なされる。しかしながら、ＵＬＭＵ送信規則は変更されないままである。すなわち、割り当てられたＲＵを含むすべての２０ＭＨｚチャネルがアイドルである場合にのみ、ＳＴＡは、１に設定されたＣＳ要求フィールドを有するトリガフレームによって割り当てられたＲＵでＨＥトリガベースＰＰＤＵを送信することを許可される。割り当てられたＲＵを含む２０ＭＨｚチャネルがすべてアイドルであるわけではない場合、ＳＴＡは、割り当てられたＲＵで何も送信することを許可されない。

【0042】

図８Ｂの表８８０は、図５に示したＵＬＭＵ送信シーケンス中のＳＴＡ２に関して、修正されたＵＬＭＵＣＳメカニズムに関連する様々なパラメータを列挙している。図６の表６００と比較すると、表８８０は、基本ＮＡＶのＢＷフィールドに基づいてチャネルの状態を示す１つの追加列８８２を含む。プライマリチャネルでの送信はＯＢＳＳに属するため、ＳＴＡ２のＢＳＳ内ＮＡＶはゼロであり、一方、基本ＮＡＶの継続期間フィールドは、ＯＢＳＳ送信の示された継続期間に設定される。図５の送信シーケンス５００に示したように、ＯＢＳＳ送信はＣＨ１およびＣＨ２でのみ発生するため、基本ＮＡＶのＢＷフィールドは、１（４０ＭＨｚ）に設定される。これは、ＣＨ１およびＣＨ２がビジーとして記録されることを意味する。

【0043】

同様に、ＣＨ３およびＣＨ４は、それぞれ記載８８４および８８６によって示されているようにアイドルとして記録される。図８Ａで説明した修正された仮想ＣＳ規則によれば、仮想ＣＳは、ＣＨ１およびＣＨ２でビジーを返し、ＣＨ３およびＣＨ４でアイドルを返す。同様に、ＥＤベースＣＣＡは、ＣＨ１とＣＨ２でビジーを返し、ＣＨ３とＣＨ４でアイドルを返す。修正されたＵＬＭＵＣＳ規則によれば、仮想ＣＳとＥＤベースＣＣＡとの両方が、ＣＨ１およびＣＨ２でビジーを示し、ＣＨ３およびＣＨ４でアイドルを示すため、それぞれ記載８８８、８９０、８９２、および８９４によって示されているように、ＵＬＭＵＣＳメカニズムは、ＣＨ１およびＣＨ２をビジーと見なし、一方、ＣＨ３およびＣＨ４はアイドルであると見なされる。ＣＨ３およびＣＨ４はアイドルと見なされるため、ＵＬＭＵＣＳ送信規則によれば、ＳＴＡ２は、ＣＨ３およびＣＨ４の割り当てられたＲＵでそのＵＬＰＰＤＵ４５０を送信することを許可される。

【0044】

図９は、図１に示した重複ワイヤレスネットワークに基づいている。ＢＳＳ１１００およびＢＳＳ２１４５とは別に、追加のＢＳＳであるＢＳＳ３９００が示されている。ＢＳＳ３９００は、ＡＰ３９０１と、２つのＳＴＡ、すなわちＳＴＡ７９１０およびＳＴＡ８９２０とを含む。ＳＴＡ２１２０はＡＰ３９０１の無線カバレッジ内にもあるため、ＢＳＳ３９００も、ＳＴＡ２に関してＯＢＳＳと見なされる。図９のＢＳＳの配置は、本開示で導入されるＮＡＶ帯域幅フィールドの更新に関する規則を説明するために使用される。ＮＡＶ帯域幅フィールドＢＷの更新に関して２つの選択肢を考えることができる。

【0045】

選択肢１（静的更新）：ＢＷフィールドは、進行中の第三者送信のＮＡＶ設定ＰＰＤＵの最大帯域幅に常に設定される。第三者送信は、ＳＴＡがその送信の送信者でも受信者でもない、ＳＴＡの受信範囲内の送信を指す。ＮＡＶ設定ＰＰＤＵは、ＳＴＡのＮＡＶカウンタ（継続期間もしくはＢＷのいずれかまたはこれら両方）の変更をもたらし得る少なくとも１つのフレームを搬送するＰＰＤＵを指す。新しいＮＡＶ設定ＰＰＤＵを受信したときに、新しいＰＰＤＵの帯域幅が既存のＢＷフィールドよりも広い場合、ＢＷフィールドはより広い帯域幅に更新される。しかしながら、新しいＰＰＤＵの帯域幅が既存のＢＷフィールドよりも狭い場合、ＢＷフィールドは変更されない。ＢＷフィールドは、ＮＡＶ継続期間とは無関係に更新される。すなわち、新しいＰＰＤＵによりＮＡＶ継続期間が更新されなくても、新しいＰＰＤＵの帯域幅が既存のＢＷフィールドよりも広ければ、ＢＷフィールドは更新される。

【0046】

選択肢２（動的更新）：ＢＷフィールドは、進行中の第三者送信のＮＡＶ設定ＰＰＤＵの実際の帯域幅を反映するように動的に調整される。この選択肢は、選択肢１と比較してより複雑であり、受信される各第三者送信の帯域幅および継続期間の一時的な記録を必要とする。ＮＡＶ継続期間が、進行中のすべての第三者送信の最長継続期間に常に設定される一方で、帯域幅フィールドは、関連する第三者送信の最後に確認され、進行中の送信の次のセクションの実際の帯域幅に更新される。

【0047】

図１０Ａを参照すると、図９に示したＢＳＳの配置におけるＳＴＡ２の基本ＮＡＶの帯域幅フィールドに関する、上で言及した選択肢１（静的更新）の規則を視覚的に示すために、一連の例示的なフレーム交換シーケンスが示されており、ＢＳＳ１１００、ＢＳＳ２１４５、およびＢＳＳ３９００の３つのＢＳＳのすべてが８０ＭＨｚのＢＳＳであると仮定されている。図１０Ａの上部には、ＢＳＳ２１４５における異なる帯域幅の２つの送信シーケンス、すなわち８０ＭＨｚのＴＸＯＰ１１０１２と４０ＭＨｚのＴＸＯＰ２１０２２が示されている。同様に、図１０Ａの下部には、ＢＳＳ３９００における異なる帯域幅の２つの送信シーケンス、すなわち２０ＭＨｚのＴＸＯＰ３１０３２と８０ＭＨｚのＴＸＯＰ４１０３４が示されている。

【0048】

図１０Ａの中央部は、本開示によって提案されているようにＳＴＡ２１２０によって保持される二次元基本ＮＡＶの視覚的表現を示す。この例に関連する時点は、ｔ０、ｔ１、ｔ２、ｔ３、ｔ４、ｔ５、ｔ６、およびｔ７によって示されている。ＴＸＯＰ１１０１２の最初のＰＰＤＵ１０１０を受信すると、ＰＨＹヘッダ内のＢＳＳカラーフィールドまたはＭＡＣヘッダ内のＢＳＳＩＤフィールドに基づいて、ＳＴＡ２は、ＰＰＤＵ１０１０がＢＳＳ２からのＯＢＳＳＰＰＤＵであり、ＳＴＡ２がＰＰＤＵ１０１０の受信者の１つではないと判断する。ＮＡＶ継続期間を更新するための既存のＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ０から時間ｔ２までに設定し、ＮＡＶＢＷフィールドを８０ＭＨｚ（受信したＰＰＤＵ１０１０の帯域幅）に設定し、この結果、ＳＴＡ２は、ＴＸＯＰ１１０１２の最後である時間ｔ２までＣＨ１、ＣＨ２、ＣＨ３、およびＣＨ４で送信することを禁止される。二次元ＮＡＶは、時間ｔ０において、ＳＴＡ２が送信を禁止された時間期間および周波数範囲を表すボックス１０１４によって表されている。

【0049】

ＴＸＯＰ３１０３２の最初のＰＰＤＵ１０３０を受信すると、ＳＴＡ２は、１０３０がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０３０の受信者の１つではないと判断する。１０３０に示されている継続期間が、既存のＮＡＶ継続期間よりも長いため、ＮＡＶ継続期間を更新するためのＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ３までに更新し、この結果、ＳＴＡ２は、ＴＸＯＰ３１０３２の最後である時間ｔ３まで送信することを禁止される。時間ｔ２から時間ｔ３まで、実際の進行中のＯＢＳＳ送信は、ＢＳＳ３のみで行われるが、ＮＡＶＢＷフィールドは８０ＭＨｚを示す。これは、過剰保護ゾーン１０１６と見なすことができる。過剰保護ゾーン１０１６では、ゾーン１０１６に含まれるチャネルＣＨ２、ＣＨ３、およびＣＨ４のすべてが時間ｔ２から時間ｔ３までＳＴＡ２に対してアイドルであっても、ＳＴＡ２は、３つのチャネルのすべてで送信することを制限される。時間ｔ３において、基本ＮＡＶ継続期間がゼロまでカウントダウンされると、ＮＡＶＢＷフィールドもゼロにリセットされる。

【0050】

同様に、ＴＸＯＰ２１０２２の最初のＰＰＤＵ１０２０を受信すると、ＳＴＡ２は、１０２０がＢＳＳ２からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０２０の受信者の１つではないと判断する。ＮＡＶ継続期間を更新するための既存のＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ４から時間ｔ７までに設定し、ＮＡＶＢＷフィールドを４０ＭＨｚ（受信したＰＰＤＵ１０２０の帯域幅）に設定し、この結果、ＳＴＡ２は、ＴＸＯＰ２１０２２の最後である時間ｔ７までＣＨ１およびＣＨ２で送信することを禁止される。

【0051】

二次元ＮＡＶは、時間ｔ４において、ＳＴＡ２が送信を禁止された時間期間および周波数範囲を表すボックス１０２４によって表されている。ＴＸＯＰ４１０３６の最初のＰＰＤＵ１０３４を受信すると、ＳＴＡ２は、１０３４がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０３４の受信者の１つではないと判断する。１０３４に示されている継続期間が、既存のＮＡＶ継続期間よりも短いため、ＮＡＶ継続期間を更新するためのＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を更新しない。しかしながら、ＰＰＤＵ１０３４の帯域幅が現在のＮＡＶＢＷフィールドよりも広いため、ＢＷフィールドは、１０２６によって示されているように８０ＭＨｚに更新され、時間ｔ７まで８０ＭＨｚとして保持される。

【0052】

時間ｔ６から時間ｔ７まで、実際の進行中のＯＢＳＳ送信は、ＢＳＳ２のみで行われるが、ＮＡＶＢＷフィールドは８０ＭＨｚを示す。これは、過剰保護ゾーン１０２８と見なすことができる。過剰保護ゾーン１０２８では、ゾーン１０２８に含まれるチャネルＣＨ３およびＣＨ４の両方が時間ｔ６から時間ｔ７までＳＴＡ２に対してアイドルであっても、ＳＴＡ２は、これらのチャネルで送信することを制限される。しかしながら、ＯＢＳＳ送信がより狭い帯域幅のチャネルのものである場合、選択肢１を用いても、既存のＵＬＭＵＣＳメカニズムと比較してより効率的なセカンダリチャネルの再利用が可能である。時間ｔ７において、基本ＮＡＶ継続期間がゼロまでカウントダウンされると、ＮＡＶＢＷフィールドもゼロにリセットされる。

【0053】

選択肢１によるＮＡＶの更新規則は、図１０Ｂのフローチャート１０４０によって要約される。プロセスは、ＮＡＶ設定ＰＰＤＵが受信されるステップ１０４２で開始される。ステップ１０４４で、ＰＰＤＵが基本ＮＡＶの継続期間フィールドを増加させる場合、プロセスはステップ１０４６に進む。ステップ１０４６で、ＰＰＤＵ内の関連する継続期間情報に従って（例えば、ＰＨＹヘッダ内のＴＸＯＰ継続期間フィールドまたはＭＡＣヘッダ内の継続期間フィールドに基づいて）基本ＮＡＶ継続期間が更新され、プロセスはステップ１０４８に進む。ステップ１０４４で、ＰＰＤＵが基本ＮＡＶの継続期間フィールドを増加させない場合、プロセスはステップ１０４８に進む。ステップ１０４８で、受信したＰＰＤＵがＢＷフィールドを増加させる場合、プロセスはステップ１０５０に進み、そうでない場合、プロセスは終了する。ステップ１０５０で、基本ＮＡＶのＢＷフィールドが、受信したＰＰＤＵの帯域幅を反映するように更新されて、プロセスは終了する。

【0054】

図１１Ａを参照すると、図１０Ａに示したのと同じ例示的な送信シーケンスが、ＳＴＡ２の基本ＮＡＶの帯域幅フィールドに関する、上で言及した選択肢２（動的更新）の規則を視覚的に示すために、再利用されている。ＴＸＯＰ１１０１２の最初のＰＰＤＵ１０１０を受信すると、ＰＨＹヘッダ内のＢＳＳカラーフィールドまたはＭＡＣヘッダ内のＢＳＳＩＤフィールドに基づいて、ＳＴＡ２は、１０１０がＢＳＳ２からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０１０の受信者の１つではないと判断する。ＮＡＶ継続期間を更新するための既存のＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ０から時間ｔ２までに設定し、ＮＡＶＢＷフィールドを８０ＭＨｚ（受信したＰＰＤＵ１０１０の帯域幅）に設定し、この結果、ＳＴＡ２は、ＴＸＯＰ１１０１２の最後である時間ｔ２までＣＨ１、ＣＨ２、ＣＨ３、およびＣＨ４で送信することを禁止される。

【0055】

二次元ＮＡＶは、時間ｔ０において、ＳＴＡ２が送信を禁止された時間期間および周波数範囲を表すボックス１１１０によって表されている。ＴＸＯＰ３１０３２の最初のＰＰＤＵ１０３０を受信すると、ＳＴＡ２は、１０３０がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０３０の受信者の１つではないと判断する。１０３０に示されている継続期間が、既存のＮＡＶ継続期間よりも長いため、ＮＡＶ継続期間を更新するためのＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ３までに更新しなければならない。しかしながら、時間ｔ２から時間ｔ３まで、実際の進行中のＯＢＳＳ送信は、ＢＳＳ３のみで行われ、したがって、ＮＡＶ継続期間がｔ３までに更新される前に、現在のＮＡＶ継続期間の終了時間ｔ２が、一時変数ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅとして記録され、タイマ（ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒ）が、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに期限切れになるように設定される。ＰＰＤＵ１０３０の帯域幅は、２０ＭＨｚであり、現在のＮＡＶＢＷフィールドよりも狭いため、ＮＡＶＢＷフィールドに変更は加えられないが、ＰＰＤＵ１０３０の帯域幅は、一時変数Ｎｅｗ＿ＢＷとして保存される。ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒがｔ２で期限切れになると、ＮＡＶＢＷフィールドは、進行中の第三者送信１０３２の実際の帯域幅１１１２を表すＮｅｗ＿ＢＷ（２０ＭＨｚ）に更新される。

【0056】

結果として、基本ＮＡＶは、ＣＨ２、ＣＨ３、およびＣＨ４のすべてがＳＴＡ２に対してアイドルであるため、ＳＴＡ２が時間ｔ２から時間ｔ３までの間に３つのチャネルのいずれかで送信することを制限しない。同様に、ＴＸＯＰ２１０２２の最初のＰＰＤＵ１０２０を受信すると、ＳＴＡ２は、１０２０がＢＳＳ２からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０２０の受信者の１つではないと判断する。ＮＡＶ継続期間を更新するための既存のＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ４から時間ｔ７までに設定し、ＮＡＶＢＷフィールドを４０ＭＨｚ（受信したＰＰＤＵ１０２０の帯域幅）に設定し、この結果、ＳＴＡ２は、ＴＸＯＰ２１０２２の最後である時間ｔ７までＣＨ１およびＣＨ２で送信することを禁止される。二次元ＮＡＶは、時間ｔ４において、ＳＴＡ２が送信を禁止された時間期間および周波数範囲を表すボックス１０２４によって表されている。

【0057】

ＴＸＯＰ４１０３６の最初のＰＰＤＵ１０３４を受信すると、ＳＴＡ２は、１０３４がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵ１０３４の受信者の１つではないと判断する。ＰＰＤＵ１０３４に示されている継続期間が、既存のＮＡＶ継続期間よりも短いため、ＮＡＶ継続期間を更新するためのＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を更新しない。しかしながら、ＰＰＤＵ１０３４の帯域幅が、８０ＭＨｚであり、現在のＮＡＶＢＷフィールドよりも広いため、ＢＷフィールドは、１１２２によって示されているように８０ＭＨｚに更新されなければならない。しかしながら、時間ｔ６から時間ｔ７まで、進行中のＯＢＳＳ送信１０２２の帯域幅は４０ＭＨｚのみであり、したがって、ＮＡＶＢＷフィールドが８０ＭＨｚに更新される前に、現在のＮＡＶＢＷが、Ｎｅｗ＿ＢＷとして保存され、ＢＳＳ３の送信１０３６の終了時間ｔ６が、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅとして記録され、タイマ（ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒ）が、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに期限切れになるように設定される。ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒが時間ｔ６で期限切れになると、ＮＡＶＢＷフィールドは、進行中の第三者送信１０２２の実際の帯域幅１１２４を表すＮｅｗ＿ＢＷ（４０ＭＨｚ）に更新される。結果として、基本ＮＡＶは、チャネルＣＨ３およびＣＨ４の両方がＳＴＡ２に対してアイドルであるため、ＳＴＡ２が時間ｔ６から時間ｔ７までの間にこれらのチャネルのいずれかで送信することを制限しない。

【0058】

選択肢２によるＮＡＶの更新規則は、図１１Ｂのフローチャート１１４０および図１１Ｃの１１８０によって要約される。プロセスは、ＮＡＶ設定ＰＰＤＵが受信されるステップ１１４２で開始される。ステップ１１４４で、ＰＰＤＵが基本ＮＡＶの継続期間フィールドを増加させる場合、プロセスはステップ１１４６に進み、そうでない場合、プロセスはステップ１１６２に進む。ステップ１１４６で、受信したＰＰＤＵの帯域幅が基本ＮＡＶＢＷフィールドよりも小さい場合、プロセスはステップ１１４８に進み、そうでない場合、プロセスはステップ１１５４に進む。ステップ１１４８で、変数ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅがゼロである場合、現在の基本ＮＡＶの有効期限が変数ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに格納され、そうではなく、変数ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅが非ゼロである場合、２つの値のうちの小さい方、すなわちＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅまたは現在の基本ＮＡＶの有効期限が、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに格納され、プロセスはステップ１１５０に進む。ステップ１１５０で、２つの値のうちの大きい方、すなわちＮｅｗ＿ＢＷまたは受信したＰＰＤＵの帯域幅が、変数Ｎｅｗ＿ＢＷに格納され、プロセスはステップ１１５２に進む。

【0059】

ステップ１１５２で、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒと呼ばれるタイマがＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに期限切れになるように設定され、プロセスはステップ１１６０に進む。ステップ１１５４で、受信したＰＰＤＵの帯域幅が基本ＮＡＶＢＷフィールドよりも大きい場合、プロセスはステップ１１５６に進み、そうでない場合、プロセスはステップ１１５８に進む。ステップ１１５６で、基本ＮＡＶＢＷフィールドは、受信したＰＰＤＵの帯域幅に更新され、プロセスはステップ１１５８に進む。ステップ１１５８で、基本ＮＡＶの帯域幅は基本ＮＡＶ継続期間の最後まで変更されないと予期されるため、動作中であればＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒは停止され、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅとＮｅｗ＿ＢＷとの両方が０に設定され、プロセスはステップ１１６０に進む。ステップ１１６０で、ＰＰＤＵ内の関連する継続期間情報に従って（例えば、ＰＨＹヘッダ内のＴＸＯＰ継続期間フィールドまたはＭＡＣヘッダ内の継続期間フィールドに基づいて）基本ＮＡＶ継続期間が更新され、このプロセスは終了する。

【0060】

ステップ１１６２で、受信したＰＰＤＵの帯域幅が基本ＮＡＶＢＷフィールドよりも大きい場合、プロセスはステップ１１６４に進み、そうでない場合、このプロセスは終了する。ステップ１１６４で、受信したＰＰＤＵによるＮＡＶ有効期限が基本ＮＡＶの有効期限よりも小さい場合、プロセスはステップ１１６８に進み、そうでない場合、プロセスはステップ１１７０に進む。ステップ１１６８で、基本ＮＡＶＢＷフィールドの値が変数Ｎｅｗ＿ＢＷに格納され、プロセスはステップ１１７０に進む。ステップ１１７０で、受信したＰＰＤＵによるＮＡＶ有効期限が変数ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに格納され、プロセスはステップ１１７２に進む。ステップ１１７２で、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒがＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅに期限切れになるように設定され、プロセスはステップ１１７４に進む。ステップ１１７４で、基本ＮＡＶＢＷフィールドが、受信したＰＰＤＵの帯域幅に更新され、このプロセスは終了する。

【0061】

基本ＮＡＶＢＷ調整プロセスは、プロセス１１８０によって要約される。プロセス１１８０は、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅｒが期限切れになるステップ１１８２で開始される。ステップ１１８４で、基本ＮＡＶ継続期間が非ゼロである場合、プロセスはステップ１１８６に進み、そうでない場合、プロセスはステップ１１９０に進む。ステップ１１８６で、Ｎｅｗ＿ＢＷの値が非ゼロである場合、プロセスはステップ１１８８に進み、そうでない場合、プロセスはステップ１１９０に進む。ステップ１１８８で、基本ＮＡＶのＢＷフィールドが、Ｎｅｗ＿ＢＷに更新され、プロセス１１８０は終了する。ステップ１１９０で、ＢＷ＿ｕｐｄａｔｅ＿ｔｉｍｅとＮｅｗ＿ＢＷとの両方が０に設定され、プロセス１１８０は終了する。

【0062】

図１２を参照すると、表１２００は、ＨＥＳＴＡによって使用されるＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブのｃｈａｎｎｅｌ－ｌｉｓｔパラメータの可能な値および意味を列挙している。ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ＳＴＡＴＥ，｛ｃｈａｎｎｅｌ－ｌｉｓｔ｝）プリミティブは、チャネルの状態をＭＡＣ層に示すためにＨＥＳＴＡのＰＨＹ層によって使用される。ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブは、ＳＴＡＴＥパラメータを常に含むが、ＳＴＡＴＥパラメータがＢＵＳＹであり、かつ複数のチャネルの状態が通知されるときにのみ、ｃｈａｎｎｅｌ－ｌｉｓｔパラメータを含む。ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブは、ＢＳＳ動作帯域幅内で、どのチャネルがビジーでどのチャネルがアイドルであるかを示す。ｃｈａｎｎｅｌ－ｌｉｓｔパラメータの最初の４つの値とその意味は、ＩＥＥＥ８０２．１１仕様で定義されているものと同じであるが、行１２１０、１２２０、および１２３０にそれぞれ列挙されている３つの値ｐｒｉｍａｒｙ２０、ｐｒｉｍａｒｙ４０、およびｐｒｉｍａｒｙ８０は、本開示の第１の実施形態によって追加されたものである。図３Ｂを参照すると、ｃｈａｎｎｅｌ－ｌｉｓｔパラメータの「ｐｒｉｍａｒｙ」の値は、プライマリ２０ＭＨｚチャネル３５０および他のすべての非プライマリチャネルがビジーであることを示す。

【0063】

「ｓｅｃｏｎｄａｒｙ」の値は、セカンダリ２０ＭＨｚチャネル３５５がビジーである一方で、プライマリ２０ＭＨｚチャネル３５０がアイドルであることを示す。「ｓｅｃｏｎｄａｒｙ４０」の値は、セカンダリ４０ＭＨｚチャネル（３６０および３６５）がビジーである一方で、プライマリ２０ＭＨｚチャネル３５０およびセカンダリ２０ＭＨｚチャネル３５５がアイドルであることを示す。「ｓｅｃｏｎｄａｒｙ８０」の値は、セカンダリ８０ＭＨｚチャネル（３７０、３７５、３８０、および３８５）がビジーである一方で、プライマリ２０ＭＨｚチャネル３５０と、セカンダリ２０ＭＨｚチャネル３５５と、セカンダリ４０ＭＨｚチャネルを一緒に形成する２つの２０ＭＨｚチャネル３６０および３６５とがアイドルであることを示す。先に言及したように、ｃｈａｎｎｅｌ－ｌｉｓｔパラメータの「ｐｒｉｍａｒｙ」の値は、プライマリ２０ＭＨｚチャネルと、ＢＳＳ動作チャネルの一部を形成する他のすべての非プライマリチャネルとがビジーであることを示す。レガシー８０２．１１システムでは、インフラストラクチャＢＳＳにおける送信のすべては、プライマリ２０ＭＨｚチャネルを含み、ＳＴＡは、プライマリ２０ＭＨｚチャネルがビジーである限り送信を許可されない。

【0064】

したがって、レガシー８０２．１１のＢＳＳでは、ビジーのプライマリ２０ＭＨｚチャネルは、すべての非プライマリチャネルもビジーであることと等しいと見なされる。しかしながら、８０２．１１ａｘのＢＳＳにおけるアップリンクＯＦＤＭＡベースマルチユーザ送信の場合、ＳＴＡは、ＡＰが非プライマリチャネルでＲＵをＳＴＡに割り当てる場合、プライマリ２０ＭＨｚチャネルを含まないチャネルでそのアップリンクＰＰＤＵを送信することを許可され得る。例として、図４を参照すると、トリガフレーム４１０において、ＡＰは、セカンダリチャネルＣＨ２でＲＵをＳＴＡ３に割り当て、８０２．１１ａｘＵＬＭＵ送信規則に従って、ＳＴＡ３は、ＵＬＭＵＣＳがＣＨ２をアイドルと見なした場合に、セカンダリチャネルＣＨ２でそのＵＬＰＰＤＵ４４０を送信することを許可される。プライマリチャネルがビジーであるときにＳＴＡのＰＨＹ層が非プライマリチャネルの状態を通知することを可能にするために、３つの追加の値（ｐｒｉｍａｒｙ２０、ｐｒｉｍａｒｙ４０、およびｐｒｉｍａｒｙ８０）がＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブに追加される。「ｐｒｉｍａｒｙ２０」の値は、プライマリ２０ＭＨｚチャネル３５０がビジーである一方で、残りの非プライマリチャネルがすべてアイドルであることを示す。「ｐｒｉｍａｒｙ４０」の値は、プライマリ４０ＭＨｚチャネル（３５０、３５５）がビジーである一方で、残りの非プライマリチャネルがすべてアイドルであることを示す。「ｐｒｉｍａｒｙ８０」の値は、プライマリ８０ＭＨｚチャネル（３５０、３５５、３６０、および３６５）がビジーである一方で、残りの非プライマリチャネルがすべてアイドルであることを示す。

【0065】

例として、図７Ａを参照すると、ＰＰＤＵ７１０が受信されると、受信したＳＴＡのＰＨＹ層は、４つの２０ＭＨｚチャネルのすべてがビジーであることを示すために、ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ＢＵＳＹ，｛ｐｒｉｍａｒｙ｝）プリミティブをＭＡＣ層に発行する。その後、ＰＰＤＵ７２０が受信されると、プライマリ２０ＭＨｚチャネルＣＨ１およびセカンダリ２０ＭＨｚチャネルＣＨ２がビジーである一方で、チャネルＣＨ３およびＣＨ４がアイドルであることを示すために、ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ＢＵＳＹ，｛ｐｒｉｍａｒｙ４０｝）プリミティブが発行される。同様に、ＰＰＤＵ７３０が受信されると、プライマリ２０ＭＨｚチャネルＣＨ１がビジーである一方で、チャネルＣＨ２、ＣＨ３、およびＣＨ４がアイドルであることを示すために、ＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ＢＵＳＹ，｛ｐｒｉｍａｒｙ２０｝）プリミティブが発行される。ＳＴＡのＭＡＣ層は、ＮＡＶのＢＷフィールドを正しく設定するためにＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブからの情報を使用する。

【0066】

＜第２の実施形態＞
図１３Ａを参照すると、例示的なアップリンクマルチユーザ送信シーケンス１３００は、同じＴＸＯＰ１３０５の間にＰＰＤＵの帯域幅が変更される場合を示している。図１のＡＰ２１０２は、他のフレームに加えて、ＳＴＡ５１５０およびＳＴＡ６１６０にそれぞれアドレス指定された２つのユニキャストトリガフレーム１３１２および１３１４を含む８０ＭＨｚＤＬＭＵＰＰＤＵ１３１０を送信する。トリガフレーム１３１２は、プライマリチャネルＣＨ１でＲＵをＳＴＡ５に割り当てる一方で、トリガフレーム１３１４は、セカンダリチャネルＣＨ２でＲＵをＳＴＡ６に割り当てる。ＡＰ２１０２はまた、ＰＰＤＵ１３１０のＰＨＹヘッダ内のＴＸＯＰ継続期間またはＰＰＤＵ１３１０によって搬送された個々のフレームのＭＡＣヘッダ内の継続期間フィールドのいずれかをＴＸＯＰ１３０５の最後までに設定することによって後続のアップリンク送信を保護する。ＰＰＤＵ１３１０からＳＩＦＳの後で、ＳＴＡ５が、ＣＨ１でそのＵＬＰＰＤＵ１３２０を送信する一方で、ＳＴＡ６は、ＣＨ２でそのＵＬＰＰＤＵ１３３０を送信する。

【0067】

ＡＰは、Ａｃｋフレーム１３４０および１３５０を搬送するＤＬＭＵＰＰＤＵをＳＴＡ５およびＳＴＡ６のそれぞれに送信することによってフレーム交換を終了する。ＯＢＳＳＳＴＡ、例えば図１のＳＴＡ２１２０がＰＰＤＵ１３１０を受信した場合、ＳＴＡ２は、ＰＰＤＵ１３１０がＢＳＳ２１４５からのＯＢＳＳＰＰＤＵであると判断する。ＳＴＡ２は、ＰＰＤＵ１３１０内の継続期間情報に基づいて基本ＮＡＶ継続期間１３６２をＴＸＯＰ１３０５の最後までに設定する。しかしながら、ＳＴＡ２がＭＵＰＰＤＵ１３１０内の個々のフレームを復号することができる場合、ＳＴＡ２は、後続のアップリンク送信の帯域幅を予測することができる。例えば、トリガフレーム１３１４および１３１２を復号することによって、ＳＴＡ２は、ＲＵがＣＨ１およびＣＨ２のみでアップリンクに割り当てられることを突き止めることができる。したがって、ＳＴＡ２は、ＰＰＤＵ１３１０によってトリガされた後続のアップリンク送信がＣＨ１およびＣＨ２のみをカバーすることになると予測することができる。したがって、基本ＮＡＶのＢＷフィールドをＰＰＤＵ１３１０の帯域幅である８０ＭＨｚに設定する代わりに、第２の実施形態によれば、ＳＴＡ２は、ＢＷフィールド１３６４を、後続のアップリンク送信の予測帯域幅である４０ＭＨｚに設定する。これは、ＳＴＡ２がそれ自体のアップリンク送信のためにアイドルのセカンダリチャネルＣＨ３およびＣＨ４を利用する機会を提供する。二次元基本ＮＡＶは、長方形１３６０によって視覚的に示されている。

【0068】

図１３Ｂを参照すると、ＮＡＶのＢＷフィールドは、２０ＭＨｚチャネルにつき１ビットの８ビットのビットマップ１３９０として格納され得る。８ビットを使用することで、最大１６０ＭＨｚチャネルで動作する８０２．１１のＢＳＳで使用されるすべての２０ＭＨｚチャネルの状態を記録することができる。チャネルのビジー状態は、対応するビットを１に設定することによって記録され、一方、アイドル状態は０で表される。

【0069】

図１４を参照すると、８０ＭＨｚのＢＳＳにおける第２の実施形態による二次元ＮＡＶを視覚的に示すために一連の例示的なフレーム交換シーケンスが示されている。上半分は、可変帯域幅を有する３つの送信シーケンス、すなわちＴＸＯＰ１１４１２、ＴＸＯＰ２１４２２、およびＴＸＯＰ３１４３２を示す。各送信シーケンスは、ＡＰと、このＡＰと同じＢＳＳに属する１つ以上のＳＴＡとの間のＰＰＤＵの交換を含む。例として、送信シーケンスの最初のＰＰＤＵは、ＵＬＭＵ送信用のＲＵを選択されたＳＴＡに割り当てるトリガフレームであり、その後にＳＴＡからのＨＥトリガベースＰＰＤＵが続き、肯定応答フレームを搬送する、ＡＰからのＤＬＰＰＤＵで終わってもよい。この例では、ＣＨ１、ＣＨ２、ＣＨ３、およびＣＨ４は、プライマリ２０ＭＨｚチャネル、セカンダリ２０ＭＨｚチャネル、ターシャリ２０ＭＨｚチャネル、およびクォータナリ２０ＭＨｚチャネルを示す。この例の下半分は、本開示によって提案されるように第三者ＳＴＡによって保持される二次元ＮＡＶの視覚的表現を示す。ＮＡＶのＢＷフィールドを記録するために使用されるビットマップも示されている。この例に関連する時点は、ｔ０、ｔ１、ｔ２、ｔ３、ｔ４、およびｔ５によって示されている。進行中の送信の無線カバレッジ内にあり、かつこの送信の送信者でも受信者でもないＳＴＡは、その送信に関して第三者ＳＴＡと見なされる。

【0070】

ＴＸＯＰ１１４１２の最初のＰＰＤＵ１４１０を受信すると、第三者ＳＴＡは、例えば、ＰＰＤＵによって搬送されたフレームのＭＡＣヘッダ内の受信者アドレスを読み取ることによって、またはＰＰＤＵ１４１０で搬送されたトリガフレームのユーザ情報フィールドのＡＩＤ１２サブフィールドを読み取ることなどによって第三者ＳＴＡがＰＰＤＵ１４１０の受信者ではないと判断する。既存のＮＡＶ規則に従って、ＳＴＡが、ＳＴＡはＰＰＤＵ１４１０の受信者ではないと判断したら、ＳＴＡは、ＮＡＶ継続期間をｔ０からｔ１までに設定する。ＮＡＶ継続期間を記録することに加えて、第２の実施形態によれば、ＳＴＡは、ＰＰＤＵ１４１０内のトリガフレームを復号し、後続のアップリンク送信のためにＣＨ１、ＣＨ２、およびＣＨ３でＲＵが割り当てられたと判断する。これに基づいて、ＮＡＶのＢＷフィールドにおいて、ＳＴＡは、ビット０、ビット１、およびビット２を１（ビジー）に設定し、残りのビットを０（アイドル）に設定する。二次元ＮＡＶは、ＴＸＯＰ１１４１２の最後である時間ｔ１までＳＴＡがＣＨ１、ＣＨ２、およびＣＨ３で送信することを禁止されるボックス１４１４によって表されている。

【0071】

同様に、ＰＰＤＵ１４２０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、ＴＸＯＰ２１４２２の最後である時間ｔ３までに設定する。ＳＴＡは、ＰＰＤＵ１４２０内のトリガフレームを復号し、後続のアップリンク送信のためにＣＨ１およびＣＨ２でＲＵが割り当てられたと判断する。これに基づいて、ＮＡＶのＢＷフィールドにおいて、ＳＴＡは、ビット０およびビット１を１（ビジー）に設定し、残りのビットを０（アイドル）に設定する。これは、時間ｔ３までＳＴＡがＣＨ１およびＣＨ２で送信することを禁止されるボックス１４２４として示されている。

【0072】

同様に、ＰＰＤＵ１４３０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、ＴＸＯＰ３１４３２の最後である時間ｔ５までに設定する。ＳＴＡは、ＰＰＤＵ１４３０内のトリガフレームを復号し、後続のアップリンク送信のためにＣＨ１でＲＵが割り当てられたと判断する。これに基づいて、ＮＡＶのＢＷフィールドにおいて、ＳＴＡは、ビット０を１（ビジー）に設定し、残りのビットを０（アイドル）に設定する。これは、時間ｔ５までＳＴＡがＣＨ１で送信することを禁止されるボックス１４３４として示されている。この場合、第三者ＳＴＡは、進行中の送信１４３２に干渉を引き起こすことなく、ｔ４からｔ５までのＮＡＶ継続期間内に非占有チャネルＣＨ２、ＣＨ３、およびＣＨ４で送信することを許可され得る。

【0073】

＜ＳＴＡの構成＞
図１５は、本開示で説明されている二次元ＮＡＶを実装する例示的なＳＴＡ１５００のブロック図である。このデバイスは、図１のＳＴＡのうちのいずれか１つであってもよい。ＳＴＡ１５００は、受信部１５０２、ＰＰＤＵデコーダ１５０４、メモリ１５０６、および送信部１５０８を備える。

【0074】

受信部１５０２は、その無線カバレッジエリア内の他のワイヤレスデバイスからＰＰＤＵを受信する。ＰＰＤＵデコーダ１５０４は、ＰＰＤＵがＳＴＡの対応するＢＳＳに属するＳＴＡによって送信されたのか、それともＯＢＳＳＳＴＡによって送信されたのかを判断するために、受信した各ＰＰＤＵを調べる。ＰＰＤＵデコーダ１５０４はまた、ＳＴＡがＰＰＤＵの目的の受信者であるかどうかを判断し、そうでない場合、ＰＰＤＵデコーダはさらに、ＰＰＤＵのＰＨＹヘッダまたはＰＰＤＵで搬送されたフレームのＭＡＣヘッダのいずれかから継続期間情報を抽出する。ＰＰＤＵデコーダはまた、受信したＰＰＤＵによって占有されている帯域幅を決定する。

【0075】

ＳＴＡ１５００は、メモリ１５０６の１つ以上のインスタンスを含むことができる。メモリ１５０６は、受信したＰＰＤＵで搬送された継続期間情報を記録し、該当する場合はＰＰＤＵによって占有されている帯域幅も記録する。ＰＰＤＵデコーダが、受信したＰＰＤＵがその対応するＢＳＳからＳＴＡによって送信されたと判断した場合、メモリ１５０６は、継続期間情報をＢＳＳ内ＮＡＶとして記録するだけである。しかしながら、ＰＰＤＵデコーダが、受信したＰＰＤＵがＯＢＳＳＳＴＡによって送信されたと判断した場合、メモリ１５０６は、継続期間情報と帯域幅情報との両方を基本ＮＡＶの一部として記録する。送信部１５０８は、命令されると、基本ＮＡＶの帯域幅によって示されるチャネルに干渉を引き起こすことなく、基本ＮＡＶの帯域幅情報によって示される周波数チャネル以外の周波数チャネルで送信を行う。

【0076】

図１６は、図１のＳＴＡのうちのいずれか１つであってもよい、本開示で説明されている二次元ＮＡＶを実装する例示的なＳＴＡ１６００の詳細ブロック図である。ワイヤレスデバイスであるＳＴＡ１６００は、メモリ１６２０、二次記憶装置１６４０、および１つ以上のワイヤレス通信インタフェース１６５０に結合された中央処理装置（ＣＰＵ：ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１６３０を備える。二次記憶装置１６４０は、関連する命令コード、データなどを永続的に記憶するために使用される不揮発性のコンピュータ可読記憶媒体であってもよい。起動時に、ＣＰＵ１６３０は、実行のために命令コードおよび関連データを揮発性メモリ１６２０にコピーすることができる。命令コードは、ＳＴＡ１６００の動作に必要とされるオペレーティングシステム、ユーザアプリケーション、デバイスドライバ、実行コードなどであってもよい。また、ＳＴＡ１６００は、電源１６１０、例えばリチウムイオン電池またはコイン電池（ｃｏｉｎｃｅｌｌｂａｔｔｅｒｙ）などを備えてもよく、あるいはそれは商用電源（Ｍａｉｎｓｅｌｅｃｔｒｉｃｔｙ）であってもよい。

【0077】

ワイヤレス通信インタフェース１６５０は、セルラー通信用のインタフェース、またはジグビー（Ｚｉｇｂｅｅ）などの短距離通信プロトコル用のインタフェースを備えてもよく、あるいはそれはＷＬＡＮインタフェースであってもよい。ワイヤレスインタフェース１６５０は、ＭＡＣモジュール１６５２、ＰＨＹモジュール１６６０、およびアンテナ１６７０をさらに備えてもよい。他のサブモジュールの中でも、ＭＡＣモジュール１６５２は、キャリア検知モジュール１６５４、ＮＡＶ帯域幅ビットマップ１６５６、およびＮＡＶ継続期間カウンタ１６５８を備えてもよい。ＮＡＶ帯域幅ビットマップ１６５６およびＮＡＶ継続期間カウンタ１６５８は、ＳＴＡ１６００がＰＰＤＵの目的の受信者ではない場合に、受信したＰＰＤＵに含まれる帯域幅情報および継続期間情報を記録するために使用される。キャリア検知モジュール１６５４は、キャリア検知を必要とする送信の前に、物理キャリア検知（エネルギー検知）と仮想キャリア検知（ＮＡＶ）との両方を実行する役割を担う。

【0078】

ＳＴＡ１６００は、明確にするために図１６には示されていない他の多くの構成要素を備えてもよい。本開示に最も関連する構成要素のみが示されている。

【0079】

＜第３の実施形態＞
先の実施形態では、ＮＡＶを設定するＰＰＤＵの帯域幅情報が、ＮＡＶ自体のフィールドとして記録されていた。しかしながら、帯域幅情報をＮＡＶから切り離して別個に記録することも可能である。第３の実施形態によれば、ＳＴＡは、ＮＡＶを設定するＰＰＤＵの帯域幅情報を別個のエンティティとして、例えば、ＯＢＳＳ＿ＢＷ情報フィールドとして記録する。

【0080】

図１７を参照すると、８０ＭＨｚのＢＳＳにおける第３の実施形態による帯域幅情報の記録を視覚的に示すために一連の例示的なフレーム交換シーケンス１７００が示されている。図１７の上部は、可変帯域幅を有する４つの送信シーケンス、すなわちＴＸＯＰ１１７１２、ＴＸＯＰ２１７２２、ＴＸＯＰ３１７３２、およびＴＸＯＰ４１７４２を示す。各送信シーケンスは、ＡＰと、このＡＰと同じＢＳＳに属する１つ以上のＳＴＡとの間のＰＰＤＵの交換を含む。

【0081】

図１７の中央部は、ＩＥＥＥ８０２．１１仕様によって定義されている規則に従って第三者ＳＴＡによって保持されるＮＡＶ継続期間の視覚的表現を示す。進行中の送信の無線カバレッジ内にあり、かつこの送信の送信者でも目的の受信者でもないＳＴＡは、その送信に関して第三者ＳＴＡと見なされる。図１７の下部は、同じ第三者ＳＴＡによって保持されるＯＢＳＳ＿ＢＷ情報の視覚的表現を示す。この例に関連する時点は、ｔ０、ｔ１、ｔ２、ｔ３、ｔ４、ｔ５、ｔ６、およびｔ７によって示されている。

【0082】

ＴＸＯＰ１１７１２の最初のＰＰＤＵ１７１０を受信すると、第三者ＳＴＡは、例えば、ＰＰＤＵによって搬送されたフレームのＭＡＣヘッダ内の受信者アドレスを読み取ることによって、またはＰＰＤＵ１７１０で搬送されたトリガフレームのユーザ情報フィールドのＡＩＤ１２サブフィールドを読み取ることなどによってＳＴＡ自体がＰＰＤＵ１７１０の目的の受信者ではないと判断する。ＳＴＡは、既存のＩＥＥＥ８０２．１１のＮＡＶ規則に従って、ＳＴＡ自体がＰＰＤＵ１７１０の目的の受信者ではないと判断したら、ＮＡＶ継続期間を、時間ｔ０から時間ｔ１までの時間期間に設定し、これにより、ＳＴＡはＴＸＯＰ１１７１２の最後である時間ｔ１まで送信することを禁止される。ＮＡＶ継続期間を記録することに加えて、第３の実施形態によれば、ＳＴＡはまた、ＮＡＶを設定するＰＰＤＵ１７１０の帯域幅情報をＯＢＳＳ＿ＢＷ情報フィールドに８０ＭＨｚとして記録する。時間ｔ１において、ＮＡＶ継続期間１７１４がゼロまでカウントダウンされると、ＯＢＳＳ＿ＢＷ情報フィールドもゼロにリセットされる。ボックス１７１６は、時間ｔ０と時間ｔ１との間のＯＢＳＳ＿ＢＷ情報を示す。ＯＢＳＳ＿ＢＷ情報フィールドは、図７Ｂの表７５０に示したように２ビットの変数として表されてもよいし、図１３Ｂの８ビットのビットマップ１３９０として保持されてもよい。

【0083】

同様に、ＴＸＯＰ２１７２２の最初のＰＰＤＵ１７２０を受信すると、ＳＴＡは、ＮＡＶ継続期間１７２４を、時間ｔ２からＴＸＯＰ２１７２２の最後である時間ｔ３までの時間期間に設定し、一方、ＯＢＳＳ＿ＢＷ情報フィールドは、４０ＭＨｚ（ＰＰＤＵ１７２０の帯域幅）に設定される。これは、ボックス１７２６として示されている。時間ｔ３において、ＮＡＶ継続期間１７２４がゼロまでカウントダウンされると、ＯＢＳＳ＿ＢＷ情報フィールドもゼロにリセットされる。同様に、ＴＸＯＰ３１７３２の最初のＰＰＤＵ１７３０を受信すると、ＳＴＡは、ＮＡＶ継続期間１７３４を、時間ｔ４からＴＸＯＰ３１７３２の最後である時間ｔ５までの時間期間に設定し、一方、ＯＢＳＳ＿ＢＷ情報フィールドは、２０ＭＨｚ（ＰＰＤＵ１７３０の帯域幅）に設定される。これは、ボックス１７３６として示されている。時間ｔ５において、ＮＡＶ継続期間１７３４がゼロまでカウントダウンされると、ＯＢＳＳ＿ＢＷ情報フィールドは再びゼロにリセットされる。さらにチャネル検知規則がそれ相応に修正されれば、特定の条件下で、第三者ＳＴＡは、進行中の送信１７２２および１７３２のそれぞれに干渉を引き起こすことなく、ｔ２からｔ３までの時間期間内に非占有チャネルＣＨ３およびＣＨ４で、ならびにｔ４からｔ５までの時間期間内にチャネルＣＨ２、ＣＨ３、およびＣＨ４で送信することを許可され得る。この結果、非占有セカンダリチャネルのより効率的な再利用が促進される。

【0084】

従来、ＩＥＥＥ８０２．１１のＳＴＡは、ＳＴＡのプライマリ２０ＭＨｚチャネルと重なるＰＰＤＵを受信して復号することのみを要求され、ＳＴＡは、そのプライマリ２０ＭＨｚチャネルと重ならないＰＰＤＵを受信または復号することを要求されない。しかしながら、ＳＴＡがそのようなＰＰＤＵを受信して復号する能力を有する場合、ＳＴＡは、そのようなＰＰＤＵの帯域幅をさらに記録するためにＯＢＳＳ＿ＢＷ情報フィールドを使用することができる。ＴＸＯＰ４１７４２は、第三者ＳＴＡによって使用されるプライマリ２０ＭＨｚと重ならないフレーム交換シーケンスを表す。ＴＸＯＰ４１７４２の最初のＰＰＤＵ１７４０を受信したとき、ＳＴＡがＰＰＤＵを受信して復号する能力を有する場合、ＳＴＡは、ＯＢＳＳ＿ＢＷ情報フィールドに帯域幅を記録することができる。この場合、ＳＴＡはＮＡＶ継続期間を設定しないことに留意されたい。

【0085】

ＯＢＳＳ＿ＢＷ情報フィールドによって記録された帯域幅情報は、ＳＴＡが関連付けられているＡＰにそのチャネルの可用性を知らせるためにＳＴＡによって参考として使用されてもよい。例として、ＳＴＡがＩＥＥＥ８０２．１１ａｘで定義された自発的な帯域幅クエリレポート（ＢＱＲ：ＢａｎｄｗｉｄｔｈＱｕｅｒｙＲｅｐｏｒｔ）の動作を実施する場合、ＳＴＡは、ＳＴＡが帯域幅クエリレポートでその関連ＡＰに送信する利用可能チャネルビットマップを埋めるためにＯＢＳＳ＿ＢＷ情報フィールドを使用することができる。ＴＸＯＰ４１７４２は、ＳＴＡに対してＮＡＶ継続期間を設定しないため、ＳＴＡが送信することを妨げない。しかしながら、ＯＢＳＳ＿ＢＷ情報フィールドにＴＸＯＰ４１７４２の帯域幅を記録することにより、ＳＴＡが、時間ｔ６から時間ｔ７までの時間期間にわたってＣＨ３およびＣＨ４がＳＴＡに関してビジーであると予期されることをそのＡＰに通知することが可能になる。これは、ＡＰが、時間ｔ６から時間ｔ７までの時間期間中の、ＳＴＡへの／からのダウンリンクまたはアップリンクのＯＦＤＭＡ送信のためにＳＴＡにリソースユニット（ＲＵ）を割り当てる際、ＣＨ３およびＣＨ４を避けるのを助ける。

【0086】

図５に戻って参照すると、ＳＴＡ２がＵＬＰＰＤＵ４５０を送信することを禁止した過剰保護ＮＡＶは、図１のＢＳＳ２１４５からの、進行中のＯＢＳＳ送信の帯域幅情報をＯＢＳＳＢＷ情報フィールドとして記録するという概念を適用するのと同時に、仮想ＣＳ規則およびＵＬＭＵＣＳメカニズムに変更を加えることによって克服され得る。

【0087】

図１８の表１８００は、図５に示したＵＬＭＵ送信シーケンス中のＳＴＡ２に関して、修正されたＵＬＭＵＣＳメカニズムに関連する様々なパラメータを列挙している。表１８００およびその内容は、ＯＢＳＳ＿ＢＷ情報フィールドが表１８００の基本ＮＡＶ１８１０とは別に設けられている点を除いて、図８Ｂの表８８０と同じである。ＢＳＳ２１４５からのＯＢＳＳ送信はＣＨ１とＣＨ２においてのみ重複するため、ＣＨ１とＣＨ２はビジーとして記録され、一方、ＣＨ３とＣＨ４は、それぞれ図１８の記載１８２０と１８２２によって示されているようにＯＢＳＳ＿ＢＷ情報フィールドにアイドルとして記録されている。

【0088】

第３の実施形態によれば、ビジー／アイドルの仮想ＣＳ状態が２０ＭＨｚチャネルごとに考慮されるように仮想ＣＳ規則が修正される。基本ＮＡＶ継続期間カウンタが非ゼロである場合、ＯＢＳＳ＿ＢＷ情報フィールドによってビジーとして示される２０ＭＨｚチャネルのみが、仮想ＣＳによってビジーであると見なされる。同様に、ＵＬＭＵＣＳ規則もまた、２０ＭＨｚチャネルごとにワイヤレス媒体のビジー／アイドル状態を考慮するように修正される。修正されたＵＬＭＵＣＳ規則によれば、仮想ＣＳとエネルギー検出（ＥＤ）ベースＣＣＡとの両方が、ＣＨ１およびＣＨ２でビジーを示し、ＣＨ３およびＣＨ４でアイドルを示すため、それぞれ記載１８３６、１８３４、１８３２、および１８３０によって示されているように、ＵＬＭＵＣＳメカニズムは、ＣＨ１およびＣＨ２をビジーと見なし、一方、ＣＨ３およびＣＨ４はアイドルであると見なされる。ＣＨ３とＣＨ４との両方がアイドルと見なされるため、修正されたＵＬＭＵＣＳ送信規則によれば、ＳＴＡ２は、ＣＨ３およびＣＨ４の割り当てられたＲＵでそのＵＬＰＰＤＵ４５０を送信することを許可され、この結果、ワイヤレス媒体のより効率的な使用が促進される。第３の実施形態による仮想ＣＳ規則は、以下のように要約することができる。
－ＳＴＡのアップリンク送信用に割り当てられたＲＵを含む各２０ＭＨｚチャネルに関して、以下の条件のいずれかが満たされない限り、送信のためにトリガフレームによって要求されたＳＴＡの仮想ＣＳにおいてＮＡＶが考慮される。
－ＮＡＶがＢＳＳ内フレームによって設定された。
－ＮＡＶ継続期間カウンタがゼロである。
－ＮＡＶ継続期間カウンタがゼロよりも大きいが、その２０ＭＨｚチャネルが、ＯＢＳＳ＿ＢＷ情報フィールドによってアイドルとして記録されている。

【0089】

ＮＡＶが考慮されない場合、仮想ＣＳは、２０ＭＨｚチャネルに関してアイドルを示し、そうでない場合、仮想ＣＳは、２０ＭＨｚチャネルに関してビジーを示す。

【0090】

第３の実施形態によるＵＬＭＵＣＳ規則は、以下のように要約することができる。
－トリガフレーム内のＣＳ要求サブフィールドが１に設定されている場合、トリガフレーム後のＳＩＦＳ時間中に、少なくとも、ＳＴＡのＵＬＭＵ送信用に割り当てられたＲＵを含む各２０ＭＨｚチャネルに関して、ＳＴＡは、トリガフレームに応答して、適切なエネルギー検出（ＥＤ）規則を使用するＣＣＡおよび仮想ＣＳの状態を考慮しなければならない。トリガフレームにおいて割り当てられたＲＵを含む２０ＭＨｚチャネルがアイドルであると見なされるとき、ＳＴＡは、ＨＥトリガベースＰＰＤＵを送信することができる。ＳＴＡが、割り当てられたＲＵを含む２０ＭＨｚチャネルがすべてアイドルであるわではないことを検出した場合、ＳＴＡは、割り当てられたＲＵで何も送信してはならない。

【0091】

図１９は、ＯＢＳＳ送信帯域幅情報をＯＢＳＳ＿ＢＷに保持することによって仮想ＣＳ規則が２０ＭＨｚチャネルごとに示される場合の、第３の実施形態によるＵＬＭＵＣＳ送信規則を説明するフローチャート１９００を示す。１に設定されたＣＳ要求フィールドを有するトリガフレームにおいてＡＰによってアップリンク送信のためにＳＴＡにＲＵが割り当てられた広帯域チャネルの各２０ＭＨｚチャネルに関して、ＵＬＭＵＣＳプロセスがステップ１９１０で開始される。トリガフレームではＣＳ要求フィールドが１に設定されているため、ＨＥトリガベースＰＰＤＵを送信する前に、ＳＴＡは、トリガフレームを含むＰＰＤＵの最後の直後のＳＩＦＳ中に、少なくとも、割り当てられたＲＵを含む２０ＭＨｚチャネルのすべてでＵＬＭＵＣＳを実行することを要求される。

【0092】

ステップ１９２０で、基本ＮＡＶ継続期間カウンタがチェックされ、それがゼロである場合、プロセスはステップ１９４０に進み、そうでない場合、プロセスはステップ１９３０に進む。ステップ１９３０で、２０ＭＨｚチャネルが、ＯＢＳＳ＿ＢＷによってビジーとして記録されている場合、プロセスはステップ１９５０に進み、そうでない場合、それはステップ１９４０に進む。ステップ１９４０で、仮想ＣＳは２０ＭＨｚチャネルをアイドルとして通知し、プロセスはステップ１９６０に進む。ステップ１９５０で、仮想ＣＳは２０ＭＨｚチャネルをビジーとして通知し、プロセスはステップ１９８０に進む。ステップ１９６０で、ＳＴＡは、トリガフレームを含むＰＰＤＵの最後の直後のＳＩＦＳ時間中にエネルギー検出（ＥＤ）を使用してワイヤレス媒体を検知し、チャネルがビジーであると検知された場合、プロセスはステップ１９８０に進み、そうでない場合、プロセスはステップ１９７０に進む。

【0093】

ステップ１９８０で、２０ＭＨｚチャネルは、ＵＬＭＵ送信に関してビジーであると見なされ、この２０ＭＨｚチャネル関してプロセスは終了する。ステップ１９７０で、２０ＭＨｚチャネルは、ＵＬＭＵ送信に関してアイドルであると見なされ、この２０ＭＨｚチャネル関してプロセスは終了する。このプロセスは、少なくとも、アップリンク送信のためにＳＴＡにＲＵが割り当てられた広帯域チャネルの各２０ＭＨｚチャネルに関して繰り返される。トリガフレームにおいてＳＴＡに割り当てられたＲＵを含む２０ＭＨｚチャネルのすべてがアイドルであると見なされた場合、ＳＴＡは、そのＨＥトリガベースＰＰＤＵを送信することができる。

【0094】

図２０を参照すると、表２０００は、様々なパラメータであって、そこから、ＮＡＶを設定する正しいＩＥＥＥ８０２．１１のＰＰＤＵを受信するＳＴＡがＰＰＤＵのチャネル帯域幅情報を決定することができる様々なパラメータを列挙している。ＩＥＥＥ８０２．１１の仕様によれば、正しいＩＥＥＥ８０２．１１のＰＨＹプリアンブルを受信すると、ＳＴＡのＰＨＹ層は、受信信号強度レベルを測定し、この信号強度レベルが一般にプリアンブル検出（ＰＤ）レベルと呼ばれる特定の閾値を上回る場合、ＰＨＹは、これをＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎ（ＢＵＳＹ，ｐｒｉｍａｒｙ）プリミティブによってＭＡＣ層に示す。ＳＴＡは、残りのＰＨＹヘッダフィールドを受信し続け、ＰＨＹヘッダの受信が成功したら、ＰＨＹ層は、ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎ（ＲＸＶＥＣＴＯＲ）プリミティブをＭＡＣに発行する。

【0095】

ＲＸＶＥＣＴＯＲの内容は、受信したＰＰＤＵのフォーマットに依存し、ＳＴＡは、表２０００に列挙されているようなＲＸＶＥＣＴＯＲの関連パラメータに基づいて、受信したＰＰＤＵの帯域幅を決定する。受信したＰＰＤＵがＨＥＰＰＤＵである場合、帯域幅は、ＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータによって示される。ここで、ＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータは、受信したＨＥＰＰＤＵのＰＨＹヘッダのＨＥ－ＳＩＧ－Ａの帯域幅フィールドに基づく。受信したＰＰＤＵがＶＨＴＰＰＤＵである場合、帯域幅は、同様にＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータによって示される。ここで、ＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータは、受信したＶＨＴＰＰＤＵのＰＨＹヘッダのＶＨＴ－ＳＩＧ－Ａ１の帯域幅フィールドに基づく。

【0096】

受信したＰＰＤＵがＨＴＰＰＤＵである場合、帯域幅は、同様にＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータによって示される。ここで、ＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータは、受信したＨＴＰＰＤＵのＰＨＹヘッダのＨＴ－ＳＩＧのＣＢＷ２０／４０ビットに基づく。しかしながら、受信したＰＰＤＵが非ＨＴＰＰＤＵである場合、ＰＰＤＵの正確な帯域幅の決定はより複雑である。なぜなら、非ＨＴＰＰＤＵは、レガシー非ＨＴＰＰＤＵフォーマットまたは非ＨＴ複製ＰＰＤＵフォーマット（ｎｏｎ－ＨＴｄｕｐｌｉｃａｔｅＰＰＤＵｆｏｒｍａｔ）であり得るからである。非ＨＴＰＰＤＵのＰＰＤＵフォーマットは、ＲＸＶＥＣＴＯＲのＮＯＮ＿ＨＴ＿ＭＯＤＵＬＡＴＩＯＮパラメータを参照して決定することができる。ＮＯＮ＿ＨＴ＿ＭＯＤＵＬＡＴＩＯＮパラメータがＯＦＤＭである場合、ＰＰＤＵは、レガシー非ＨＴＰＰＤＵであり、チャネル帯域幅は２０ＭＨｚである。

【0097】

しかしながら、ＮＯＮ＿ＨＴ＿ＭＯＤＵＬＡＴＩＯＮパラメータがＮＯＮ＿ＨＴ＿ＤＵＰ＿ＯＦＤＭである場合、ＰＰＤＵは、非ＨＴ複製ＰＰＤＵである。すなわち、同じＰＰＤＵが、複数の２０ＭＨｚチャネルで複製されている。この場合、ＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータは、推定チャネル帯域幅を示すに過ぎない。しかしながら、非ＨＴ複製ＰＰＤＵは、帯域幅シグナリングＳＴＡによって送信される場合がある。すなわち、受信したＰＰＤＵに含まれるＭＡＣヘッダの送信者アドレス（ＴＡ：ＴｒａｎｓｍｉｔｔｅｒＡｄｄｒｅｓｓ）フィールドは、帯域幅シグナリングＴＡである（ＴＡの個別／グループビットは１である）。そのような場合、ＰＰＤＵの正確な帯域幅は、ＲＸＶＥＣＴＯＲのＣＨ＿ＢＡＮＤＷＩＤＴＨ＿ＩＮ＿ＮＯＮ＿ＨＴパラメータをさらに参照して決定することができる。場合によっては、非ＨＴ複製ＰＰＤＵの正確な帯域幅を決定することが可能でないことがある。例えば、通常はＣＴＳフレームが、非ＨＴＰＰＤＵまたは非ＨＴ複製ＰＰＤＵフォーマットで送信されて、レガシーデバイスに対して最大のＮＡＶ保護が保証される。

【0098】

ＣＴＳフレームは、ＴＡフィールドさえ含まないため、ＣＴＳフレームが非ＨＴ複製フォーマットで送信される場合、ＣＴＳフレームによってカバーされる正確な帯域幅を決定することは不可能である。そのようなＰＰＤＵが受信され、ＳＴＡがＰＰＤＵの正確な帯域幅を決定することができない場合、第３の実施形態によれば、基本ＮＡＶ継続期間カウンタが非ゼロであるときにＳＴＡの送信を許可しないためにＳＴＡの動作チャネルのすべてがビジーとして記録されるようにＯＢＳＳ＿ＢＷ情報フィールドは設定される。これにより、ＳＴＡが進行中のＯＢＳＳ送信に誤って干渉を引き起こさないことが保証される。

【0099】

図２１を参照すると、表２１００は、ＨＥＳＴＡによって発行されるＰＨＹ－ＣＣＡ．ｉｎｄｉｃａｔｉｏｎプリミティブのｃｈａｎｎｅｌ－ｌｉｓｔパラメータの可能な値および意味を列挙している。ｃｈａｎｎｅｌ－ｌｉｓｔパラメータの４つの既存のメンバ、すなわちｐｒｉｍａｒｙ、ｓｅｃｏｎｄａｒｙ、ｓｅｃｏｎｄａｒｙ４０、およびｓｅｃｏｎｄａｒｙ８０に加えて、ＨＥＳＴＡは、任意選択的にｐｅｒ２０ＭＨｚｂｉｔｍａｐを含むこともでき、その場合、０である、ビットマップの各ビットは、アイドル２０ＭＨｚチャネルを示し、１である各ビットは、ビジー２０ＭＨｚチャネルを示す。ＨＥＳＴＡのＰＨＹ層が、このような２０ＭＨｚの粒度でチャネル状態を示す能力を有する場合、ＳＴＡは、代替的に、ＯＢＳＳ＿ＢＷ情報フィールドを設定するためにｐｅｒ２０ＭＨｚｂｉｔｍａｐを使用することもできる。

【0100】

＜第４の実施形態＞
先に言及したように、場合により、ＳＴＡが、受信したＰＰＤＵの正確な帯域幅を決定することが不可能であるかもしれないし、ＳＴＡは、実施の容易さまたは他の理由から受信したＰＰＤＵの帯域幅情報を記録しないことを選択するかもしれない。他の場合には、ＮＡＶを設定するＰＰＤＵがプライマリ２０ＭＨｚチャネルのみを占有するにしても、ＳＴＡは、ＮＡＶ継続期間中の非プライマリチャネルでの送信が推奨できない可能性があることを示す他の情報を所有するかもしれない。

【0101】

同様に、ＳＴＡが、受信したＰＰＤＵの正確な帯域幅を決定することができなくても、近傍のＯＢＳＳに関するその履歴知識に基づいて、ＳＴＡは、依然としてＰＰＤＵの帯域幅を正確に予測することができることが可能な場合もある。例えば、以前に受信したＯＢＳＳフレームに基づいて、ＳＴＡは、特定のＯＢＳＳが２０ＭＨｚプライマリチャネルでのみ動作すること、または特定のＨＥＳＴＡが２０ＭＨｚのみのデバイスであることを知ることができる（ＳＴＡとそのＡＰと間の能力交換中に受信されるフレームに基づいて）。ＳＴＡは、時間とともにその近傍に関するそのような知識ベースを構築してもよく、また、ＰＰＤＵが受信されたとき、基本サービスセット識別子（ＢＳＳＩＤ）または送信者／受信者アドレスなどのＰＰＤＵ内の一部の関連フィールドに基づいて、ＳＴＡは、ＮＡＶ期間（すなわち、ＮＡＶ継続期間カウンタが非ゼロである継続期間）中の非プライマリチャネルでのその送信が無害であるかどうかを判定することができる場合がある。

【0102】

第４の実施形態によれば、ＮＡＶ設定ＰＰＤＵの帯域幅情報を記録する代わりに、ＳＴＡは、ＳＴＡがＮＡＶ期間中に非プライマリ２０ＭＨｚチャネルで送信することができるかどうかを示すフラグＴＸ＿Ａｌｌｏｗｅｄを保持する。ＴＸ＿Ａｌｌｏｗｅｄフラグは、ＮＡＶと無関係に保持されてもよいし、ＮＡＶに密接に結び付けられてもよい。

【0103】

図２２を参照すると、２２００は、２オクテットを使用する第４の実施形態による、ＳＴＡによって保持されるＮＡＶを示す。ＩＥＥＥ８０２．１１の仕様によれば、ほとんどの場合、ＳＴＡは、正しい８０２．１１フレームのＭＡＣヘッダ内の２オクテットの継続期間／ＩＤフィールドの内容に基づいてそのＮＡＶを更新する。継続期間値を搬送するために使用されるとき、継続期間／ＩＤフィールドのビット１５は０に設定され、一方、残りの１５ビットはマイクロ秒単位で継続期間値を搬送する。場合によっては、ＨＥＳＴＡは、ＮＡＶを更新するためにＲＸＶＥＣＴＯＲ内の７ビットのＴＸＯＰ＿ＤＵＲＡＴＩＯＮパラメータを使用することもできる。いずれの場合も、２２１０によって示されているように、ＮＡＶ継続期間を記録するには１５ビットで十分である。

【0104】

最後のビットＢ１５は、ＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０として使用される。ＴＸ＿Ａｌｌｏｗｅｄフラグの符号化は、表２２３０で説明されている。ＴＸ＿Ａｌｌｏｗｅｄフラグがゼロに設定されている場合に、ＮＡＶ継続期間フィールド２２１０が非ゼロ値を示すとき、ＳＴＡは送信を許可されない。それが１に設定されている場合、ＳＴＡは、他の条件で許可されていれば（例えば、エネルギー検出（ＥＤ）ベースチャネル検知がまた非プライマリ２０ＭＨｚチャネルをアイドルとして返していれば）、ＮＡＶ期間中に非プライマリ２０ＭＨｚチャネルで送信することができる。

【0105】

図２３を参照すると、８０ＭＨｚのＢＳＳにおける第４の実施形態によるＮＡＶの記録を視覚的に示すために一連の例示的なフレーム交換シーケンス２３００が示されている。

【0106】

図２３の上部は、可変帯域幅を有する３つの送信シーケンス、すなわち８０ＭＨｚのＴＸＯＰ１２３１２、４０ＭＨｚのＴＸＯＰ２２３２２、および２０ＭＨｚのＴＸＯＰ３２３３２を示す。この例に関連する時点は、ｔ０、ｔ１、ｔ２、ｔ３、ｔ４、およびｔ５によって示されている。進行中の送信の無線カバレッジ内にあり、かつこの送信の送信者でも目的の受信者でもないＳＴＡは、その送信に関して第三者ＳＴＡと見なされる。

【0107】

ＴＸＯＰ１２３１２の最初のＰＰＤＵ２３１０を受信すると、第三者ＳＴＡは、例えば、ＰＰＤＵによって搬送されたフレームのＭＡＣヘッダ内の受信者アドレスを読み取ることによって、またはＰＰＤＵ２３１０で搬送されたトリガフレームのユーザ情報フィールドのＡＩＤ１２サブフィールドを読み取ることなどによって第三者ＳＴＡ自体がＰＰＤＵ２３１０の目的の受信者ではないと判断する。ＳＴＡは、既存のＮＡＶ規則に従って、ＳＴＡ自体がＰＰＤＵ２３１０の受信者ではないと判断したら、ＰＰＤＵ２３１０の関連フィールドから保護継続期間をコピーし、ＮＡＶ継続期間フィールド２２１０を例えば時間ｔ０から時間ｔ１までの時間期間に設定する。

【0108】

ＮＡＶ継続期間を記録することに加えて、第４の実施形態によれば、ＳＴＡはまた、プライマリ２０ＭＨｚチャネルとは別の、その動作帯域幅内の他の２０ＭＨｚチャネルでの送信が許容可能であるかどうかを予測する。ＳＴＡは、ＮＡＶ継続期間中の非プライマリチャネルでのその送信が無害であるかどうかを判定するために、ＰＰＤＵ２３１０の帯域幅、近傍のＯＢＳＳに関するその履歴知識、基本サービスセット識別子（ＢＳＳＩＤ）などのＰＰＤＵ内の関連フィールド、または送信者／受信者のアドレスなどの情報を利用することができる。

【0109】

ＰＰＤＵ２３１０の場合、ＳＴＡは、ＣＨ２、ＣＨ３、およびＣＨ４においてＴＸＯＰ１２３１２の後続の送信への干渉の危険性が高いため、ｔ０からｔ１までのＮＡＶ期間中に他の非プライマリ２０ＭＨｚチャネルで送信することは推奨できないと予測し、したがって、ＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０を０に設定する。これは、ボックス２３１４によって視覚的に示されている。同様に、ＰＰＤＵ２３２０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、時間ｔ２からＴＸＯＰ２２３２２の最後である時間ｔ３までの時間期間に設定する。この場合もまた、ＳＴＡは、ＣＨ２においてＴＸＯＰ２２３２２の後続の送信への干渉の危険性があるため、ｔ２からｔ３までのＮＡＶ期間中に他の非プライマリ２０ＭＨｚチャネルで送信することは推奨できないと予測し、したがって、ＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０を０に設定する。これは、ボックス２３２４として示されている。

【0110】

同様に、ＰＰＤＵ２３３０を受信すると、ＳＴＡは、ＮＡＶ継続期間を、時間ｔ４からＴＸＯＰ３２３３２の最後である時間ｔ５までの時間期間に設定する。しかしながら、この時点で、ＳＴＡは、ＮＡＶ期間中の非プライマリ２０ＭＨｚチャネルＣＨ２、ＣＨ３、およびＣＨ４でのその送信がＴＸＯＰ３２３３２の後続の送信に干渉しないと予測し、したがって、ＳＴＡは、他の条件で許可されていればＳＴＡがｔ４からｔ５までのＮＡＶ期間中に非プライマリ２０ＭＨｚチャネルで送信できることを示す１にＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０を設定する。これは、ボックス２３３６によって視覚的に示されている。しかしながら、ボックス２３３４によって視覚的に示されているように、ＮＡＶ期間中のプライマリ２０ＭＨｚチャネルＣＨ１での送信は禁止される。時間ｔ５において、ＮＡＶ継続期間カウンタがゼロになるとき、ＴＸ＿Ａｌｌｏｗｅｄフラグもゼロにリセットされる。

【0111】

図２４は、第４の実施形態によってなされる、スペクトル再利用の改善を強調するように、さらに別のチャネル状態における例示的なＵＬＭＵ送信シーケンス４００を示す。ＳＴＡがＡＰ１（図１の１０１）からトリガフレーム４１０を受信した瞬間、ＳＴＡ１、ＳＴＡ３、およびＳＴＡ４の無線カバレッジエリア内にプライマリ２０ＭＨｚチャネルで進行中の送信はなく、ＳＴＡ１、ＳＴＡ３、およびＳＴＡ４のＢＳＳ内ＮＡＶと基本ＮＡＶとの両方がゼロに設定される。しかしながら、送信シーケンス２４００によって示されているように、ＢＳＳ２（図１の１４５）ではＳＴＡ２の無線カバレッジエリア内にプライマリチャネルＣＨ１で進行中のＯＢＳＳ送信がある。

【0112】

ＡＰ２（１０２）およびＳＴＡ５（１５０）は、逆方向プロトコル（ＲＤＰ：ｒｅｖｅｒｓｅｄｉｒｅｃｔｉｏｎｐｒｏｔｏｃｏｌ）を使用して双方向フレーム交換を行っている。ＡＰ２は、１に設定された逆方向許可（ＲＤＧ：ＲｅｖｅｒｓｅＤｉｒｅｃｔｉｏｎＧｒａｎｔ）／ＭｏｒｅＰＰＤＵフィールドとともにＲＤＰＡ制御フィールドを含むＰＰＤＵ２４１０をＳＴＡ５に送信する。そして、ＳＴＡ５は、ＰＰＤＵ２４１０からの時間ＳＩＦＳの後にＰＰＤＵ２４２０で応答する。ＡＰ２は、ＡＣＫフレーム２４３０をＳＴＡ５に送信することによってフレーム交換を終了する。

【0113】

ＰＰＤＵ２４１０を受信すると、ＳＴＡ２は、それがＯＢＳＳＰＰＤＵであると判断し、その基本ＮＡＶを送信シーケンス２４００の最後までに設定する。ＳＴＡ２に対する図示のＯＢＳＳ干渉は、図５に示したものと比較してわずかに異なり、ＯＢＳＳ送信は、プライマリ２０ＭＨｚチャネルＣＨ１にのみ干渉する。しかしながら、元のＵＬＭＵＣＳ規則の下では、ＳＴＡ２への干渉の影響はまったく同じである。基本ＮＡＶは非ゼロであるため、仮想ＣＳは、ビジーを返し、エネルギー検出が、チャネルＣＨ３およびＣＨ４でアイドルを返しても、ＳＴＡ２は、チャネルＣＨ３およびＣＨ４の割り当てられたＲＵでＨＥトリガベースＰＰＤＵ４５０を送信することを許可されない。

【0114】

第４の実施形態によれば、ビジー／アイドルの仮想ＣＳ状態が異なる２０ＭＨｚチャネルに関して異なる仕方で考慮されるように仮想ＣＳ規則が修正される。少なくとも、仮想ＣＳは、プライマリ２０ＭＨｚチャネルと、ＳＴＡの動作帯域幅内の残りの非プライマリ２０ＭＨｚチャネルとに関して異なる仕方で考慮される。基本ＮＡＶ継続期間カウンタが非ゼロであるとき、プライマリ２０ＭＨｚチャネルは、仮想ＣＳによって常にビジーとして示される。しかしながら、非プライマリ２０ＭＨｚチャネルが仮想ＣＳによってアイドルと見なされるかそれともビジーと見なされるかは、ＴＸ＿Ａｌｌｏｗｅｄフラグに依存する。ＴＸ＿Ａｌｌｏｗｅｄフラグが設定されていないとき、すなわちＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０が０であるとき、すべての非プライマリ２０ＭＨｚチャネルもビジーとして示される。しかしながら、ＴＸ＿Ａｌｌｏｗｅｄフラグが設定されているとき、すなわちＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０が１であるとき、すべての非プライマリ２０ＭＨｚチャネルはアイドルとして示される。

【0115】

図２５の表２５００は、図２４に示したＵＬＭＵ送信シーケンス４００中のＳＴＡ２に関して、第４の実施形態による修正されたＵＬＭＵＣＳメカニズムに関連する様々なパラメータを列挙している。表２５００およびその内容は、ＣＨ２がアイドルであり、基本ＮＡＶを設定するＰＰＤＵの帯域幅情報を記録することによって各２０ＭＨｚチャネルのビジー／アイドル状態を保持する代わりに、略語ＴＸ＿Ａ２５１０によって示されているようにＴＸ＿Ａｌｌｏｗｅｄフラグだけが保持される点を除いて、図８Ｂの表８８０とほぼ同じである。ＰＰＤＵ２４１０を受信すると、ＢＳＳカラー、ＲＸＶＥＣＴＯＲのＣＨ＿ＢＡＮＤＷＩＤＴＨパラメータなどの、ＰＰＤＵからの関連フィールドに基づいて、ＳＴＡ２は、それがＢＳＳ間２０ＭＨｚＰＰＤＵであると判断する。ＳＴＡ２はまた、ＢＳＳ２が２０ＭＨｚのみで動作するという履歴情報を有することができ、ＰＰＤＵ２４１０に含まれるフレームのＢＳＳカラーまたはＢＳＳＩＤに基づいて、ＳＴＡ２は、ＮＡＶ期間中はＯＢＳＳ送信がプライマリ２０ＭＨｚチャネルＣＨ１に制限されることを確実に予測することができる。したがって、ＳＴＡ２は、ＮＡＶ期間中に非プライマリチャネルでそのＵＬＭＵＰＰＤＵを送信することが安全であると判断し、したがってＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０を１に設定する。

【0116】

第４の実施形態による仮想ＣＳ規則によれば、ＣＨ１は、ビジー２５２２として示されるが、ＴＸ＿Ａｌｌｏｗｅｄフラグ２２２０が１であるため、非プライマリチャネルＣＨ２、ＣＨ３、およびＣＨ４は、仮想ＣＳによってアイドルとして示される。同様に、ＳＴＡ２が、トリガフレームを含むＰＰＤＵ４１０の後のＳＩＦＳ中にエネルギー検出（ＥＤ）ベースＣＣＡを実行するとき、ＣＨ１はビジーとして示され、一方、３つの非プライマリチャネルＣＨ２、ＣＨ３、およびＣＨ４はアイドルとして示される。それぞれ記載２５３６、２５３４、２５３２、および２５３０によって示されているように、ＵＬＭＵＣＳメカニズムは、仮想ＣＳとエネルギー検出検知との両方の状態を考慮し、ＣＨ１をビジーとして示し、一方、ＣＨ２、ＣＨ３、およびＣＨ４はアイドルと見なされる。ＣＨ３とＣＨ４との両方がアイドルと見なされるため、修正されたＵＬＭＵＣＳ送信規則によれば、ＳＴＡ２は、ＣＨ３およびＣＨ４の割り当てられたＲＵでそのＵＬＰＰＤＵ４５０を送信することを許可され、この結果、ワイヤレス媒体のより効率的な使用が促進される。

【0117】

第４の実施形態による仮想ＣＳ規則は、以下のように要約することができる。
－ＳＴＡのアップリンク送信用に割り当てられたＲＵを含む各２０ＭＨｚチャネルに関して、以下の条件のいずれかが満たされない限り、送信のためにトリガフレームによって要求されたＳＴＡの仮想ＣＳにおいてＮＡＶが考慮される。
－ＮＡＶがＢＳＳ内フレームによって設定された。
－ＮＡＶ継続期間カウンタがゼロである。
－２０ＭＨｚチャネルがプライマリ２０ＭＨｚチャネルではなく、ＴＸ＿Ａｌｌｏｗｅｄフラグが１に設定されている。

【0118】

【0119】

第４の実施形態によるＵＬＭＵＣＳ規則は、以下のように要約することができる。
－トリガフレーム内のＣＳ要求サブフィールドが１に設定されている場合、トリガフレーム後のＳＩＦＳ時間中に、少なくとも、ＳＴＡのＵＬＭＵ送信用に割り当てられたＲＵを含む各２０ＭＨｚチャネルに関して、ＳＴＡは、トリガフレームに応答して、適切なエネルギー検出（ＥＤ）規則を使用するＣＣＡおよび仮想ＣＳの状態を考慮しなければならない。トリガフレームにおいて割り当てられたＲＵを含む２０ＭＨｚチャネルがアイドルであると見なされるとき、ＳＴＡは、ＨＥトリガベースＰＰＤＵを送信することができる。ＳＴＡが、割り当てられたＲＵを含む２０ＭＨｚチャネルがすべてアイドルであるわではないことを検出した場合、ＳＴＡは、割り当てられたＲＵで何も送信してはならない。

【0120】

図２６は、第４の実施形態によるＵＬＭＵＣＳ送信規則を説明するフローチャート２６００を示す。１に設定されたＣＳ要求フィールドを有するトリガフレームにおいてＡＰによってアップリンク送信のためにＳＴＡにＲＵが割り当てられた広帯域チャネルの各２０ＭＨｚチャネルに関して、ＵＬＭＵＣＳプロセスがステップ２６１０で開始される。トリガフレームではＣＳ要求フィールドが１に設定されているため、ＨＥトリガベースＰＰＤＵを送信する前に、ＳＴＡは、トリガフレームを含むＰＰＤＵの最後の直後のＳＩＦＳ中に、少なくとも、割り当てられたＲＵを含む２０ＭＨｚチャネルのすべてでＵＬＭＵＣＳを実行することを要求される。ステップ２６２０で、基本ＮＡＶ継続期間カウンタがチェックされ、それがゼロである場合、プロセスはステップ２６４０に進み、そうでない場合、プロセスはステップ２６３０に進む。

【0121】

ステップ２６３０で、２０ＭＨｚチャネルがプライマリ２０ＭＨｚチャネルである場合、プロセスはステップ２６６０に進み、そうでない場合、それはステップ２６５０に進む。ステップ２６５０で、ＴＸ＿Ａｌｌｏｗｅｄフラグが０に設定されている場合、プロセスはステップ２６６０に進み、そうでない場合、それはステップ２６４０に進む。ステップ２６４０で、仮想ＣＳは２０ＭＨｚチャネルをアイドルとして通知し、プロセスはステップ２６７０に進む。ステップ２６６０で、仮想ＣＳは２０ＭＨｚチャネルをビジーとして通知し、プロセスはステップ２６９０に進む。

【0122】

ステップ２６７０で、ＳＴＡは、トリガフレームを含むＰＰＤＵの最後の直後のＳＩＦＳ時間中にエネルギー検出（ＥＤ）を使用してワイヤレス媒体を検知し、チャネルがビジーであると検知された場合、プロセスはステップ２６９０に進み、そうでない場合、プロセスはステップ２６８０に進む。ステップ２６９０で、２０ＭＨｚチャネルは、ＵＬＭＵ送信に関してビジーであると見なされ、この２０ＭＨｚチャネル関してプロセスは終了する。同様に、ステップ２６７０で、２０ＭＨｚチャネルは、ＵＬＭＵ送信に関してアイドルであると見なされ、この２０ＭＨｚチャネル関してプロセスは終了する。このプロセスは、少なくとも、アップリンク送信のためにＳＴＡにＲＵが割り当てられた広帯域チャネルの各２０ＭＨｚチャネルに関して繰り返される。トリガフレームにおいてＳＴＡに割り当てられたＲＵを含む２０ＭＨｚチャネルのすべてがアイドルであると見なされたとき、ＳＴＡは、割り当てられたＲＵでそのＨＥトリガベースＰＰＤＵを送信することができる。

【0123】

図２７を参照すると、例えば図９に示したＢＳＳの配置においてＳＴＡの無線カバレッジ内に複数のＯＢＳＳがあるときの、ＴＸ＿Ａｌｌｏｗｅｄフラグの更新規則を視覚的に示すために一連の例示的なフレーム交換シーケンスが示されており、ＢＳＳ１１００、ＢＳＳ２１４５、およびＢＳＳ３９００の３つのＢＳＳのすべてが８０ＭＨｚのＢＳＳであると仮定されている。図２７の上部には、ＢＳＳ２１４５における異なる帯域幅の３つの送信シーケンス、すなわち８０ＭＨｚのＴＸＯＰ１２７１０と、ＴＸＯＰ２２７２０およびＴＸＯＰ３２７３０の２つの２０ＭＨｚのＴＸＯＰとが示されている。同様に、図２７の下部には、ＢＳＳ３９００における異なる帯域幅の３つの送信シーケンス、すなわちＴＸＯＰ４２７４０、ＴＸＯＰ６２７６０の２つの２０ＭＨｚのＴＸＯＰと、可変帯域幅のＴＸＯＰ５２７５０とが示されている。図２７の中央部は、第４の実施形態によって提案されているようにＳＴＡ２１２０によって保持される基本ＮＡＶの視覚的説明を示す。この例に関連する時点はｔ０、ｔ１、ｔ２、ｔ３、ｔ４、ｔ５、ｔ６、ｔ７、ｔ８、ｔ９、ｔ１０、およびｔ１１によって示されている。

【0124】

ＴＸＯＰ１２７１０の最初のＰＰＤＵ２７１２を受信すると、ＰＨＹヘッダ内のＢＳＳカラーフィールドまたはＭＡＣヘッダ内のＢＳＳＩＤフィールドに基づいて、ＳＴＡ２は、ＰＰＤＵ２７１２がＢＳＳ２からのＯＢＳＳＰＰＤＵであり、ＳＴＡ２がＰＰＤＵの受信者の１つではないと判断する。ＮＡＶ継続期間の更新に関する既存のＮＡＶ規則に従って、ＳＴＡ２は、基本ＮＡＶ継続期間を時間ｔ０から時間ｔ２までに設定する。同時に、ＮＡＶ期間中のその後のＯＢＳＳ送信の予測に基づいて、ＳＴＡ２は、ＴＸ＿Ａｌｌｏｗｅｄフラグを０に設定する。

【0125】

ＴＸＯＰ４２７４０の最初のＰＰＤＵ２７４２を受信すると、ＳＴＡ２は、２７４２がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、ＳＴＡ２がＰＰＤＵの受信者の１つではないと判断する。ＰＰＤＵ２７４２に示されている継続期間は既存のＮＡＶ継続期間よりも長いため、ＮＡＶ時間の更新に関する規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を、ＴＸＯＰ４２７４０の最後である時間ｔ３までに更新する。ＳＴＡ２が、ＴＸＯＰ４２７４０の帯域幅が２０ＭＨｚのみであると判断しても、ＢＳＳ２の送信シーケンス２７１０のその知識に基づいて、ＳＴＡ２は、延長されたＮＡＶ期間中も非プライマリチャネルでの送信を禁止し続けるべきであると判定し、したがって、ＴＸ＿Ａｌｌｏｗｅｄフラグに変更を加えない。

【0126】

同様に、ＴＸＯＰ２２７２０の最初のＰＰＤＵ２７２２を受信すると、ＳＴＡ２はＰＰＤＵの受信者の１つではないため、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ４から時間ｔ７までに設定する。ＳＴＡ２は、ＴＸＯＰ２２７２０の帯域幅が２０ＭＨｚのみであると判断し、ＮＡＶ期間中に非プライマリ２０ＭＨｚチャネルでの送信が許可され得ることを示す１にＴＸ＿Ａｌｌｏｗｅｄフラグを設定する。

【0127】

ＴＸＯＰ５２７５０の最初のＰＰＤＵ２７５２を受信すると、ＳＴＡ２は、２７５２がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵの受信者の１つではないと判断する。２７５２に示されている継続期間が既存のＮＡＶ継続期間よりも短いため、ＮＡＶ継続期間の更新に関するＮＡＶ規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を更新しない。しかしながら、ＰＰＤＵ２７５２の帯域幅は２０ＭＨｚよりも広いため、ＳＴＡ２は、非プライマリチャネルでの送信によるＯＢＳＳへの干渉の危険性を予測し、したがって、ＴＸ＿Ａｌｌｏｗｅｄフラグを０に更新して、残りのＮＡＶ期間中に非プライマリチャネルで新しい送信を開始することを禁止する。しかしながら、ＰＰＤＵ２７５２の一部のフィールドまたはＢＳＳ３に関するその以前の知識（例えば、このＰＰＤＵ２７５２が、２０ＭＨｚのみのＨＥデバイス、すなわち、プライマリ２０ＭＨｚチャネルでのみ動作する能力を有するデバイスからの応答のみを求めるフレームを含むこと）に基づいて、ＳＴＡ２が、ＴＸＯＰ５の帯域幅が２０ＭＨｚに低減されると判断することができる場合、ＳＴＡ２は、ＴＸ＿Ａｌｌｏｗｅｄフラグを更新しないことを選択することもでき、これにより、ＮＡＶ期間中の非プライマリ２０ＭＨｚチャネルでの送信は許可され続ける。

【0128】

同様に、ＴＸＯＰ３２７３０の最初のＰＰＤＵ２７３２を受信すると、ＳＴＡ２はＰＰＤＵの受信者の１つではないため、ＳＴＡ２は、ＮＡＶ継続期間を時間ｔ８から時間ｔ１０までに設定する。ＳＴＡ２はまた、ＴＸＯＰ３２７３０の帯域幅が２０ＭＨｚのみであると判断し、ＮＡＶ期間中に送信が許可され得ることを示す１にＴＸ＿Ａｌｌｏｗｅｄフラグを設定する。

【0129】

ＴＸＯＰ６２７６０の最初のＰＰＤＵ２７６２を受信すると、ＳＴＡ２は、２７６２がＢＳＳ３からのＯＢＳＳＰＰＤＵであり、それがＰＰＤＵの受信者の１つではないと判断する。ＰＰＤＵ２７６２に示されている継続期間は既存のＮＡＶ継続期間よりも長いため、ＮＡＶ継続期間の更新に関する規則に従って、ＳＴＡ２は、ＮＡＶ継続期間を、ＴＸＯＰ６２７６０の最後である時間ｔ１１までに更新する。ＴＸＯＰ６２７６０の帯域幅も２０ＭＨｚのみであるため、ＳＴＡ２は、ＴＸ＿Ａｌｌｏｗｅｄフラグを更新しないことを選択し、これにより、ＮＡＶ期間中の非プライマリ２０ＭＨｚチャネルでの送信が許可され続ける。時間ｔ１１において、ＮＡＶ継続期間カウンタがゼロに達したとき、ＳＴＡ２は、ＴＸ＿Ａｌｌｏｗｅｄフラグをゼロにリセットする。

【0130】

ＴＸ＿Ａｌｌｏｗｅｄフラグの更新規則は、図２８のフローチャート２８００によって要約される。プロセスは、ＮＡＶ設定ＯＢＳＳＰＰＤＵが受信されるステップ２８１０で開始される。ステップ２８１５で、基本ＮＡＶ継続期間の現在値がゼロである場合、プロセスはステップ２８７０に進み、そうでない場合、それはステップ２８２０に進む。

【0131】

ステップ２８２０で、ＰＰＤＵが基本ＮＡＶのＮＡＶ継続期間を増加させる場合、プロセスはステップ２８３０に進み、そうでない場合、プロセスはステップ２８４０に進む。ステップ２８３０で、ＰＰＤＵ内の関連する継続期間情報に従って（例えば、ＰＨＹヘッダ内のＴＸＯＰ継続期間フィールドまたはＭＡＣヘッダ内の継続期間フィールドに基づいて）基本ＮＡＶ継続期間が更新され、プロセスはステップ２８４０に進む。ステップ２８４０で、ＴＸ＿Ａｌｌｏｗｅｄフラグが１である場合、プロセスはステップ２８５０に進み、そうでない場合、プロセスは終了する。

【0132】

ステップ２８５０で、ＳＴＡは、非プライマリ２０ＭＨｚチャネルでのその送信がＯＢＳＳ送信に干渉を引き起こす可能性があるかどうかを判断し、そうである場合、プロセスはステップ２８６０に進み、そうでない場合、プロセスは終了する。ステップ２８６０で、ＳＴＡはＴＸ＿Ａｌｌｏｗｅｄフラグを０に設定し、プロセスは終了する。

【0133】

ステップ２８７０で、受信したＰＰＤＵの帯域幅が２０ＭＨｚであり、ＳＴＡが、非プライマリ２０ＭＨｚチャネルでのその送信がＯＢＳＳ送信に干渉を引き起こさないと判断した場合、プロセスはステップ２８８０に進み、そうでない場合、プロセスはステップ２８７５に進む。ステップ２８８０で、ＳＴＡは、ＴＸ＿Ａｌｌｏｗｅｄフラグを１に設定し、プロセスはステップ２８８５に進む。ステップ２８７５で、ＳＴＡは、ＴＸ＿Ａｌｌｏｗｅｄフラグを０に設定し、プロセスはステップ２８８５に進む。ステップ２８８５で、ＰＰＤＵが基本ＮＡＶのＮＡＶ継続期間を増加させる場合、プロセスはステップ２８９０に進み、そうでない場合、プロセスは終了する。ステップ２８９０で、ＰＰＤＵ内の関連する継続期間情報に従って（例えば、ＰＨＹヘッダ内のＴＸＯＰ継続期間フィールドまたはＭＡＣヘッダ内の継続期間フィールドに基づいて）基本ＮＡＶ継続期間が更新され、プロセスは終了する。

【0134】

図１５および図１６を使用して上で説明したＳＴＡの構成により、上で言及した、本開示の第３および第４の実施形態が実施され得ることは言うまでもない。

【0135】

前述の実施形態では、本開示は、例としてハードウェアで構成されているが、ハードウェアとソフトウェアとの協働によって実現されてもよい。

【0136】

さらに、実施形態の説明に使用された機能ブロックは、一般的には、集積回路であるＬＳＩデバイスとして実施される。機能ブロックは個々のチップとして形成されてもよいし、機能ブロックの一部または全部が単一チップに集積されてもよい。本明細書では「ＬＳＩ」という用語を使用しているが、集積度に応じて「ＩＣ」、「システムＬＳＩ」、「スーパーＬＳＩ」、または「ウルトラＬＳＩ」という用語を使用することもできる。

【0137】

さらに、回路の集積化は、ＬＳＩに限定されず、ＬＳＩ以外の専用回路または汎用プロセッサによって達成されてもよい。ＬＳＩの製造後に、プログラム可能なフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）またはＬＳＩ内の回路セルの接続または設定の再構成を可能にする再構成可能プロセッサが使用されてもよい。

【0138】

半導体技術またはこの技術から派生する他の技術の進歩の結果として、ＬＳＩに代わる回路集積技術が現れた場合、機能ブロックは、そのような技術を使用して集積されてもよい。別の可能性は、バイオテクノロジーなどの適用である。

【産業上の利用可能性】

【0139】

本開示は、マルチチャネルワイヤレス通信システムで効率的な仮想キャリア検知（ＣＳ）を行うためにワイヤレス装置に適用され得る。

【符号の説明】

【0140】

１５００ＳＴＡ（局）
１５０２受信部
１５０４ＰＰＤＵデコーダ
１５０６メモリ
１５０８送信部
１６００ＳＴＡ（局）
１６１０電源
１６２０メモリ
１６３０中央処理装置（ＣＰＵ）
１６４０二次記憶装置
１６５０ワイヤレス通信インタフェース
１６５２ＭＡＣモジュール
１６５４キャリア検知モジュール
１６５６ＮＡＶ帯域幅ビットマップ
１６５８ＮＡＶ継続期間カウンタ
１６６０ＰＨＹモジュール
１６７０アンテナ

【図1】