JP2023084929A

JP2023084929A - 無線通信装置

Info

Publication number: JP2023084929A
Application number: JP2021199331A
Authority: JP
Inventors: 朋子足立; Tomoko Adachi; 昌弘関谷; Masahiro Sekiya
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2021-12-08
Filing date: 2021-12-08
Publication date: 2023-06-20
Also published as: US20230180058A1

Abstract

【課題】ＣＳＭＡ／ＣＡを用いる無線通信システムで他のＡＰから無線リソースを分け与えられたＡＰ及びその配下のｎｏｎ－ＡＰＳＴＡが分け与えられた無線リソース内で送信できる仕組みを提供すること。【解決手段】実施形態に係る無線通信装置は、メモリとメモリに接続される処理部を具備する。無線通信装置は第１無線通信グループに所属する。処理部は第１、第２、第３パラメータをメモリに格納する。処理部は、受信パケットが第１無線通信グループ内の第２の無線通信装置から送信された場合、第１パラメータを更新し、受信パケットが第１無線通信グループを構成するアクセスポイントが連携対象とする他のアクセスポイントのいずれかが構成する第２無線通信グループ内の第３の無線通信装置から送信された場合、第２パラメータを更新し、それ以外の場合第３パラメータを更新する。【選択図】図２

Description

本発明の実施形態は、キャリアセンス通信に関し、特に複数のアクセスポイントが連携する通信に関する。

無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）システムにおいて、複数アクセスポイント（ａｃｃｅｓｓｐｏｉｎｔ；ＡＰ、基地局とも称する）の協調動作が提案されている。一例として、あるＡＰが送信権獲得後に送信権獲得期間（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ；ＴＸＯＰ）中の無線リソースである時間と周波数を他の複数ＡＰに分け与える手法が提案されている。この手法の概念は、次世代高速化無線ＬＡＮ規格の標準化を行う８０２．１１ＴａｓｋＧｒｏｕｐ（ＴＧ）ｂｅにおいて採用することが決定されている。

米国特許出願公開第２０２１／００５１７２２号明細書米国特許出願公開第２０２０／０２６７６３６号明細書米国特許出願公開第２０２０／００７６５５１号明細書米国特許出願公開第２０２０／０１２０５４４号明細書

ＩＥＥＥ８０２．１１－１９／１５８２ｒ１ＩＥＥＥ８０２．１１－１９／１２６２ｒ２３ＩＥＥＥ８０２．１１－２０／１９３５ｒ４４ＩＥＥＥＳｔｄ８０２．１１－２０２０ＩＥＥＥＳｔｄ８０２．１１ａｘ－２０２１

しかしながら、ＣＳＭＡ／ＣＡ（ｃａｒｒｉｅｒｓｅｎｓｅｍｕｌｔｉｐｌｅａｃｃｅｓｓｗｉｔｈｃｏｌｌｉｓｉｏＮＡＶｏｉｄａｎｃｅ）を用いる無線通信システムではＴＸＯＰの保護（プロテクション）目的にＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）が設定されるため、提案手法をＣＳＭＡ／ＣＡを用いる無線通信システムで単純に実施しようとしても、無線リソースを分け与えられたＡＰ及びその配下のｎｏｎ－ＡＰＳＴＡ（以下、単にＳＴＡ、端末とも称する）が分け与えられた無線リソース内で送信する仕組みがない。

本発明の目的は、ＣＳＭＡ／ＣＡを用いる無線通信システムで他のＡＰから無線リソースを分け与えられたＡＰ及びその配下のｎｏｎ－ＡＰＳＴＡが分け与えられた無線リソース内で送信する仕組みを提供することである。

実施形態に係る無線通信装置は、メモリと、メモリに接続される処理部と、を具備する。無線通信装置は、第１無線通信グループＢＳＳ１に所属する。処理部は、第１パラメータｉｎｔｒａ－ＢＳＳＮＡＶと、第２パラメータＥＳＳＮＡＶと、第３パラメータｂａｓｉｃＮＡＶをメモリに格納する。処理部は、受信したパケットが第１無線通信グループＢＳＳ１内の第２の無線通信装置から送信された物理パケットであると把握した場合、第１パラメータｉｎｔｒａ－ＢＳＳＮＡＶを更新する。処理部は、受信したパケットが第２の無線通信装置から送信された物理パケットではなく、第１無線通信グループＢＳＳ１を構成するアクセスポイントが連携対象とする他のアクセスポイントのいずれかが構成する第２無線通信グループＢＳＳ２内の第３の無線通信装置から送信された物理パケットであると把握した場合、第２パラメータＥＳＳＮＡＶを更新する。処理部は、受信したパケットが第２の無線通信装置から送信された物理パケットではなく、第３の無線通信装置から送信された物理パケットではないと把握した場合、第３パラメータｂａｓｉｃＮＡＶを更新する。処理部は、第１パラメータと第２パラメータと前記第３パラメータに基づいてパケットを送信するかを決定する。

第１実施形態に係る無線通信システムの一例を示す図。第１実施形態に係る無線通信装置の一例を示す図。ＭＡＣフレームの基本的なフォーマットを示す図。ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶの状態とトリガーフレームへの応答の可否との関係を示す図。トリガーフレームのフォーマットの一例を示す図。共有元ＡＰがＴＸＯＰの一部のリソース（時間）を時間で分割して複数の共有先ＡＰに分け与える場合のＭＡＰの一例を示す図。チャネルボンディングの一例を説明するための図。チャネルボンディングの一例における送信権獲得方法を説明するための図。共有元ＡＰがＴＸＯＰの一部のリソース（時間）を周波数で分割して複数の共有先ＡＰに分け与える場合のＭＡＰの一例を示す図。ＭＡＣフレームのＦｒａｍｅＢｏｄｙに含まれる情報エレメントの一例を示す図。ＡＰ手法１の一例を説明するための図。ＡＰ手法２の一例を説明するための図。ＡＰ手法２において、２つのＮＡＶの状態とトリガーフレームへの応答の可否との関係を示す図。ＡＰ手法３の一例を説明するための図。ＡＰ手法３において、２つのＮＡＶの状態とＭＡＰ送信の可否との関係を示す図。ＡＰ手法４の一例を説明するための図。ＡＰ手法４において、３つのＮＡＶの状態とＭＡＰ送信の可否との関係を示す図。ＳＴＡ手法１の一例を説明するための図。ＡＰ／ＳＴＡ手法の一例を説明するための図。ＳＴＡ手法２の一例を説明するための図。ＳＴＡ手法３の一例を説明するための図。ＳＴＡ手法４の一例を説明するための図。ＳＴＡ手法５の一例を説明するための図。ＳＴＡ手法６におけるＮＡＶ設定の一例を示すフローチャート。ＳＴＡ手法６の一例を説明するための図。ＳＴＡ手法６において、３つのＮＡＶの状態とトリガーフレームへの応答の可否とＭＡＰ送信の可否との関係を示す図。ＣＦ－Ｅｎｄフレームのフォーマットの一例を示す図。ＳＴＡ手法７の一例を説明するための図。ＡＰの一例の機能ブロック図。ＳＴＡまたはＡＰの全体構成例を示す図。無線ＬＡＮモジュールのハードウェア構成例を示す図。ＳＴＡの一例の斜視図。メモリカードに搭載した無線通信装置の一例を示す図。無線ＬＡＮにおけるランダムアクセスに基づく競合期間のフレーム交換の一例を示す図。

以下、図面を参照して、実施形態を説明する。以下の説明は、実施形態の技術的思想を具体化するための装置や方法を例示するものであって、実施形態の技術的思想は、以下に説明する構成要素の構造、形状、配置、材質等に限定されるものではない。当業者が容易に想到し得る変形は、当然に開示の範囲に含まれる。説明をより明確にするため、図面において、各要素のサイズ、厚み、平面寸法又は形状等を実際の実施態様に対して変更して模式的に表す場合もある。複数の図面において、互いの寸法の関係や比率が異なる要素が含まれることもある。複数の図面において、対応する要素には同じ参照数字を付して重複する説明を省略する場合もある。いくつかの要素に複数の呼称を付す場合があるが、これら呼称の例はあくまで例示であり、これらの要素に他の呼称を付すことを否定するものではない。また、複数の呼称が付されていない要素についても、他の呼称を付すことを否定するものではない。なお、以下の説明において、「接続」は直接接続のみならず、他の要素を介した接続も含む場合もある。

無線ＬＡＮ（ｌｏｃａｌａｒｅａｎｅｔｗｏｒｋ）の規格書として知られているＩＥＥＥＳｔｄ８０２．１１－２０２０およびＩＥＥＥＳｔｄ８０２．１１ａｘ－２０２１と、次世代無線ＬＡＮ規格であるＩＥＥＥＳｔｄ８０２．１１ｂｅ用の仕様フレームワーク文書（ＳｐｅｃｉｆｉｃａｔｉｏｎＦｒａｍｅｗｏｒｋＤｏｃｕｍｅｎｔ）である２０２１年９月２３日付けのＩＥＥＥ８０２．１１－２０／１９３５ｒ４４は、本明細書においてその全てが参照によって組み込まれる（ｉｎｃｏｒｐｏｒａｔｅｄｂｙｒｅｆｅｒｅｎｃｅ）ものとする。

以下、図面を参照しながら本実施の形態について詳細に説明する。

＜ＢＳＳ、ｉｎｆｒａｓｔｒｕｃｔｕｒｅＢＳＳ、ＥＳＳ＞
図１は、第１実施形態に係る無線通信システムの一例を示す。ＩＥＥＥ８０２．１１規格（前述のＩＥＥＥＳｔｄ８０２．１１ａｘ－２０２１などの拡張規格を含む。以降も同様）では、無線通信グループの最小単位はｂａｓｉｃｓｅｒｖｉｃｅｓｅｔ（ＢＳＳ）である。ＢＳＳはＢＳＳｉｄｅｎｔｉｆｉｅｒ（ＢＳＳＩＤ）を有する。例えばＢＳＳ内の全端末向けに送信されるブロードキャストフレームなどでは送信されるデータフレームのアドレスフィールドの１つにＢＳＳＩＤが入れられる。データフレームを受信した端末は、そのフレームが自端末が属するＢＳＳ内の全端末向けのものであるかをＢＳＳＩＤにより判断し、該当する場合にデータフレームのペイロードを抽出するなどの処理を行う。

ＩＥＥＥ８０２．１１規格では２種類のＢＳＳの形態が規定されている。１つは基地局（ＡＰ；ａｃｃｅｓｓｐｏｉｎｔ）がＢＳＳを立ち上げ、それに端末（ＳＴＡ；ｓｔａｔｉｏｎ）が接続する形態である。これをｉｎｆｒａｓｔｒｕｃｔｕｒｅＢＳＳと呼ぶ。もう一つはＡＰが存在せず、ＳＴＡのみでＢＳＳを構成する形態である。これをｉｎｄｅｐｅｎｄｅｎｔＢＳＳと呼ぶ。本実施形態では、ＢＳＳとしてはｉｎｆｒａｓｔｕｔｕｒｅＢＳＳが扱われる。

ｉｎｆｒａｓｔｕｔｕｒｅＢＳＳ（以降、ｉｎｄｅｐｅｎｄｅｎｔＢＳＳと特に対比して表現したい場合以外ではこれをＢＳＳと表現する）では、ＡＰのＭＡＣ（ｍｅｄｉｕｍａｃｃｅｓｓｃｏｎｔｒｏｌ；媒体アクセス制御）アドレスがＢＳＳＩＤとなる。ＡＰはＳＴＡの一種であり、この明細書では両者を無線通信装置と称する場合もある。ＡＰは、データの送信元（ｓｏｕｒｃｅ）である他のＳＴＡからデータの最終宛先（ｄｅｓｔｉｎａｔｉｏｎ）である別のＳＴＡへのデータの転送を可能にする機能を持つ。ＳＴＡはこの機能を持たない。この場合、他のＳＴＡまたは別のＳＴＡの一方は必ずしもＡＰと同一のＢＳＳにある必要はなく、他のＡＰ経由で接続していてもよいし、あるいは有線ＬＡＮに接続していてもよい。

ＡＰと他のＡＰ間を接続するためのシステムをｄｉｓｔｒｉｂｕｔｉｏｎｓｙｓｔｅｍ（ＤＳ）と呼ぶ。ＤＳには複数のＡＰが接続されていてよく、このＤＳにより接続した複数のＡＰはｅｘｔｅｎｄｅｄｓｅｒｖｉｃｅｓｅｔ（ＥＳＳ）を構成する。同一ＥＳＳであることを識別する識別子がサービスセット識別子（ｓｅｒｖｉｃｅｓｅｔｉｄｅｎｔｉｆｉｅｒ；ＳＳＩＤ）である。

図１では、ＡＰとして、ＡＰ１とＡＰ２が存在する。ＡＰ１がＳＴＡ１１とＳＴＡ１２を収容してＢＳＳ１を構成する。ＡＰ２がＳＴＡ２１とＳＴＡ２２を収容してＢＳＳ２を構成する。ＢＳＳ１とＢＳＳ２がＥＳＳを構成している。

＜無線通信装置＞
図２は、第１実施形態に係る無線通信装置の一例を示す。無線通信装置は、上位処理部１０、ＭＡＣ処理部２０、ＰＨＹ（Ｐｈｙｓｉｃａｌ；物理）処理部３０、ＭＡＣ／ＰＨＹ管理部４０、アナログ処理部５０、及びアンテナ６０を含む。図２では、アナログ処理部５０の個数とアンテナ６０の個数がそれぞれ１個であるが、多重化通信のために複数のアナログ処理部５０と複数のアンテナ６０が設けられていてもよい。複数のアナログ処理部５０の個数と複数のアンテナ６０の個数は等しくてもよいし、異なっていてもよい。例えば、２個以上のアンテナ６０が１個のアナログ処理部５０に共通に接続されていてもよい。

ＭＡＣ処理部２０、ＭＡＣ／ＰＨＹ管理部４０、及びＰＨＹ処理部３０は、他の無線通信装置との通信に関する処理を行う制御部またはベースバンド集積回路の一形態に相当する。アナログ処理部５０は、例えばアンテナ６０を介して信号を送受信する無線通信部またはＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）集積回路の一形態に相当する。本実施形態に係る無線通信用集積回路は、ベースバンド集積回路およびＲＦ集積回路の少なくとも前者を含む。ベースバンド集積回路の機能は、ＣＰＵ等のプロセッサで動作するソフトウェア（プログラム）によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはＲＯＭ、ＲＡＭ等のメモリ、ハードディスク、ＳＳＤなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発性メモリでもよい。

上位処理部１０は、ＭＡＣ層に対して上位層のための処理を行う。上位処理部１０は、ＭＡＣ処理部２０との間で信号をやり取りできる。上位層としては、代表的なものとしては、ＴＣＰ／ＩＰ層やＵＤＰ／ＩＰ層、さらにその上層のアプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部１０は、ＭＡＣ層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。無線通信装置は、上位処理部１０を介して有線インフラに接続するようになっていてもよい。

ＭＡＣ処理部２０は、ＭＡＣ層のための処理を行う。前述のように、ＭＡＣ処理部２０は、上位処理部１０との間で信号をやり取りできる。更に、ＭＡＣ処理部２０は、ＰＨＹ処理部３０との間で、信号をやり取りできる。ＭＡＣ処理部２０は、ＭＡＣ共通処理部７０、送信処理部８０、受信処理部９０、及びメモリ９４を含む。メモリ９４は、ＭＡＣ共通処理部７０、送信処理部８０、及び受信処理部９０に接続される。メモリ９４は、ＭＡＣ共通処理部７０、送信処理部８０、及び受信処理部９０の処理に必要なデータを記憶する。ＭＡＣ処理部２０の機能がソフトウェアによって行われる場合、メモリ９４はＭＡＣ処理部２０のソフトウェアも記憶する。

ＭＡＣ共通処理部７０は、ＭＡＣ層での送受信に共通する処理を行う。ＭＡＣ共通処理部７０は、上位処理部１０、送信処理部８０、受信処理部９０、及びＭＡＣ／ＰＨＹ管理部４０と夫々接続し、夫々との間で信号のやり取りをする。

送信処理部８０及び受信処理部９０は、相互に接続している。送信処理部８０は、ＭＡＣ共通処理部７０及びＰＨＹ処理部３０に夫々接続している。受信処理部９０は、ＭＡＣ共通処理部７０及びＰＨＹ処理部３０に夫々接続している。送信処理部８０は、ＭＡＣ層での送信処理を行う。受信処理部９０は、ＭＡＣ層での受信処理を行う。

ＰＨＹ処理部３０は、ＰＨＹ層のための処理を行う。前述のように、ＰＨＹ処理部３０は、ＭＡＣ処理部２０との間で信号をやり取りできる。ＰＨＹ処理部３０は、アナログ処理部５０を介してアンテナ６０に接続されている。

ＭＡＣ／ＰＨＹ管理部４０は、上位処理部１０、ＭＡＣ処理部２０（より詳細には、ＭＡＣ共通処理部７０）及びＰＨＹ処理部３０の夫々と接続されている。ＭＡＣ／ＰＨＹ管理部４０は、無線通信装置におけるＭＡＣ動作及びＰＨＹ動作を管理する。

アナログ処理部５０は、アナログ／デジタル及びデジタル／アナログ（ＡＤ／ＤＡ）変換器やＲＦ回路を含み、ＰＨＹ処理部３０からのデジタル信号を所望の周波数のアナログ信号に変換してアンテナ６０から送信、またアンテナ６０から受信した高周波のアナログ信号をデジタル信号に変換する。なお、ここでは、ＡＤ／ＤＡ変換をアナログ処理部５０で行っているが、ＰＨＹ処理部３０にＡＤ／ＤＡ変換機能を持たせる構成も可能である。

本実施形態に係る無線通信装置は、１チップ内にアンテナ６０を構成要素として含む（一体化する）ことで、このアンテナ６０の実装面積を小さく抑えることができる。

無線媒体への信号送信に際して、ＰＨＹ処理部３０は、送信処理部８０からＭＡＣフレームを受け取る。ＰＨＹ処理部３０は、ＭＡＣフレームにプリアンブル及びＰＨＹヘッダの追加や符号化、変調などの処理を行ってＰＨＹパケットに変換する。アナログ処理部５０は、デジタル信号であるＰＨＹパケットを、所望の周波数のアナログ信号に変換する。アンテナ６０は、アナログ処理部５０からのアナログ信号を無線媒体に輻射する。なお、ＰＨＹ処理部３０は、信号送信の期間中に、無線媒体がビジーであることを示す信号を、ＭＡＣ処理部２０（より正確には受信処理部９０）へ出力する。

ＰＨＹ処理部３０は、ＭＩＭＯ技術を拡張したアップリンクマルチユーザＭＩＭＯ（Ｕｐｌｉｎｋｍｕｌｔｉ－ＵｓｅｒＭＩＭＯ；ＤＬ－ＭＵ－ＭＩＭＯ）およびＤＬ－ＭＵ－ＭＩＭＯ（ＤｏｗｎｌｉｎｋＭｕｌｔｉ－ＵｓｅｒＭＩＭＯ；ＤＬ－ＭＵ－ＭＩＭＯ）の少なくとも一方に関する処理を行ってもよい。ＵＬ－ＭＵ－ＭＩＭＯは、ＡＰが、複数のＳＴＡから空間多重で（同一周波数帯域で同時に）送信されるストリームを複数のアンテナで同時に受信し、受信信号をＭＩＭＯ復調することで、各ＳＴＡのフレームへ分離する。これにより、ＡＰは、複数のＳＴＡから同一の周波数帯域で同時に送信されるフレームを受信できる。また、ＤＬ－ＭＵ－ＭＩＭＯでは、ＡＰが複数のアンテナから、複数台のＳＴＡに対しそれぞれストリームを空間多重で送信し、各ＳＴＡが受信信号をＭＩＭＯ復調することでフレームに分離し、自ＳＴＡ宛のフレームを受信する。これにより、ＡＰは、複数台のＳＴＡへ同時にフレームを同一の周波数帯域でそれぞれ送信できる。

無線媒体からの信号受信に際して、アナログ処理部５０は、アンテナ６０が受信したアナログ信号を、ＰＨＹ処理部３０が処理可能な基底帯域（ｂａｓｅｂａｎｄ）の信号に変換し、デジタル信号に変換する。ＰＨＹ処理部３０は、アナログ処理部５０からデジタルの受信信号を受け取り、その受信レベルを検出する。検出した受信レベルを、キャリアセンスレベル（閾値）と比較し、受信レベルが、キャリアセンスレベル以上であれば、ＰＨＹ処理部３０は媒体（ＣＣＡ；ｃｌｅａｒｃｈａｎｎｅｌａｓｓｅｓｓｍｅｎｔ）がビジーであるということを示す信号を、ＭＡＣ処理部２０（より正確には、受信処理部９０）へ出力する。受信レベルが、キャリアセンスレベル未満であれば、ＰＨＹ処理部３０は、媒体（ＣＣＡ）がアイドルであるということを示す信号を、ＭＡＣ処理部２０（より正確には受信処理部９０）へ出力する。

ＰＨＹ処理部３０は、受信信号に対し、復調処理、プリアンブル及びＰＨＹヘッダを取り除く処理などを行って、ペイロードを抽出する。ＩＥＥＥ８０２．１１規格では、このペイロードをＰＨＹ側ではＰＳＤＵ（ｐｈｙｓｉｃａｌｌａｙｅｒｃｏｎｖｅｒｇｅｎｃｅｐｒｏｃｅｄｕｒｅ（ＰＬＣＰ）ｓｅｒｖｉｃｅｄａｔａｕｎｉｔ）と呼んでいる。ＰＨＹ処理部３０は、抽出したペイロードを受信処理部９０に渡し、受信処理部９０はこれをＭＡＣフレームとして扱う。ＩＥＥＥ８０２．１１規格では、このＭＡＣフレームを、ＭＰＤＵ（ｍｅｄｉｕｍａｃｃｅｓｓｃｏｎｔｒｏｌ（ＭＡＣ）ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ）と呼んでいる。加えて、ＰＨＹ処理部３０は、受信信号を受信開始した際に、その旨を受信処理部９０に通知し、また受信信号を受信終了した際に、その旨を受信処理部９０に通知する。また、ＰＨＹ処理部３０は、受信信号が正常にＰＨＹパケットとして復号できた場合（エラーを検出しなければ）、受信信号の受信終了を通知すると共に、媒体がアイドルであるということを示す信号を、受信処理部９０に渡す。ＰＨＹ処理部３０は、受信信号にエラーを検出した場合には、エラー種別に即した適切なエラーコードをもって、受信処理部９０にエラーを検出したことを通知する。また、ＰＨＹ処理部３０は、媒体がアイドルになったと判定した時点で、媒体がアイドルであることを示す信号を受信処理部９０に通知する。

ＭＡＣ共通処理部７０は、上位処理部１０から送信処理部８０への送信データの受け渡し、及び受信処理部９０から上位処理部１０への受信データの受け渡しを、夫々仲介する。ＩＥＥＥ８０２．１１規格では、このＭＡＣデータフレームの中のデータを、ＭＳＤＵ（ｍｅｄｉｕｍａｃｃｅｓｓｃｏｎｔｒｏｌ（ＭＡＣ）ｓｅｒｖｉｃｅｄａｔａｕｎｉｔ）と呼んでいる。また、ＭＡＣ共通処理部７０は、ＭＡＣ／ＰＨＹ管理部４０からの指示を一旦受け取り、当該指示を送信処理部８０及び受信処理部９０に適したものに変換して出力する。

ＭＡＣ／ＰＨＹ管理部４０は、例えばＩＥＥＥ８０２．１１規格におけるＳＭＥ（ｓｔａｔｉｏｎｍａｎａｇｅｍｅｎｔｅｎｔｉｔｙ）に相当する。その場合、ＭＡＣ／ＰＨＹ管理部４０とＭＡＣ共通処理部７０との間のインターフェースは、ＩＥＥＥ８０２．１１規格におけるＭＬＭＥＳＡＰ（ＭＡＣｓｕｂｌａｙｅｒｍａｎａｇａｍｅｎｔｅｎｔｉｔｙｓｅｒｖｉｃｅａｃｃｅｓｓｐｏｉｎｔ）に相当する。ＭＡＣ／ＰＨＹ管理部４０とＰＨＹ処理部３０との間のインターフェースは、ＩＥＥＥ８０２．１１無線ＬＡＮにおけるＰＬＭＥＳＡＰ（ｐｈｙｓｉｃａｌｌａｙｅｒｍａｎａｇｅｍｅｎｔｅｎｔｉｔｙｓｅｒｖｉｃｅａｃｃｅｓｓｐｏｉｎｔ）に相当する。

なお、図２において、ＭＡＣ／ＰＨＹ管理部４０は、ＭＡＣ管理のための機能部とＰＨＹ管理のための機能部とが一体であるかのように描かれているが、分けて実装されてもよい。

＜ＢＳＳへの接続方法とデータフレームの交換開始＞
ＡＰはＢＳＳを立ち上げると、ビーコン（Ｂｅａｃｏｎ）フレームを周期的に送信する。なお、実際にはＣＳＭＡ／ＣＡ（ｃａｒｒｉｅｒｓｅｎｓｅｍｕｌｔｉｐｌｅａｃｃｅｓｓｗｉｔｈｃａｒｒｉｅｒａｖｏｉｄａｎｃｅ）を用いてビーコンフレームは送信されるため、厳密な固定間隔とはならない。

ビーコンフレームはＢＳＳの属性やＡＰの無線通信能力、またＳＴＡが同期を取るための送信時刻（ｔｉｍｅｓｔａｍｐ）情報を報知するものであり、ブロードキャストフレームである。ブロードキャストフレームとは、直接の受信先アドレス（ＲＡ；ｒｅｃｅｉｖｅｒａｄｄｒｅｓｓ）を指定するフィールドを全て１としたものである。なお、８０２．１１規格では、ＲＡはアドレスフィールドが複数ある場合には最初に設定されるアドレスフィールドである。ビーコンフレームにはＳＳＩＤを入れてもよいし、入れなくてもよい。ＳＳＩＤを入れない送信形態のことをステルスモードと呼ぶ。

ＡＰは、ＳＴＡからプローブ要求（ＰｒｏｂｅＲｅｑｕｅｓｔ）フレームを受信すると、当該ＳＴＡに対してプローブ応答（ＰｒｏｂｅＲｅｓｐｏｎｓｅ）フレームを送信する。プローブ要求フレームは通常ブロードキャストフレームで送信される。プローブ応答フレームは基本的にビーコンフレームと同じ情報を通知するもので、ユニキャストフレームである。ユニキャストフレームとは、ＲＡに特定のＳＴＡのＭＡＣアドレスを指定したフレームのことである。ＳＴＡがプローブ要求フレームでより詳細な情報について要求することも可能である。その場合には、ＡＰはプローブ応答フレームに要求された情報をビーコンフレームと同じ情報以外に付加して送信する。例えば、プローブ要求フレームでＳＴＡが追加で要求するエレメントＩＤを指定（ＩＥＥＥＳｔｄ８０２．１１－２０２０の９．４．２．１０ＥｘｔｅｎｄｅｄＲｅｑｕｅｓｔｅｌｅｍｅｎｔを使用して要求）した場合、ＡＰは、要求された情報をプローブ応答フレームに付加して送信する。あるいは、ＳＴＡがプローブ要求フレームで同一ベンダー間で通じる固有な要求を入れた（ＩＥＥＥＳｔｄ８０２．１１－２０２０の９．４．２．２１８ＶｅｎｄｏｒＳｐｅｃｉｆｉｃＲｅｑｕｅｓｔｅｌｅｍｅｎｔ）場合、それに対してＡＰが要求された情報をプローブ応答フレームに入れて送信することもある。また、ＳＴＡはプローブ要求フレームに特定のＳＳＩＤを入れることもできる。その場合は、当該プローブ要求フレームを受信した複数のＡＰのうちでＳＳＩＤが合致するＡＰがプローブ応答フレームを送信する。ＳＴＡがユーザの入力情報に基づきＳＳＩＤを指定したプローブ要求フレームを送信する。そのため、ステルスモードのＡＰであり、かつＳＳＩＤが合致するＡＰがプローブ要求フレームを受信できるエリア内にいた場合には、ＳＴＡはそのＡＰを検出できる。

ＳＴＡはビーコンフレームあるいはプローブ応答フレームを受信することにより、当該ＳＴＡが接続可能なＡＰを把握する。複数接続候補のＡＰがいる場合には、ＳＴＡはそのうちの１つのＡＰを選択し、接続を試みる。

ＩＥＥＥ８０２．１１規格では、ＳＴＡがＡＰに接続し、ＡＰとの間でデータフレームの交換ができるようになるためには、オーセンティケーションプロセス（ａｕｔｈｅｎｔｉｃａｔｉｏｎｐｒｏｃｅｓｓ）とアソシエーションプロセス（ａｓｓｏｃｉａｔｉｏｎｐｒｏｃｅｓｓ）を経る必要がある。

オーセンティケーションプロセスでは、オーセンティケーション（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）フレームをＳＴＡとＡＰの間で２回あるいは４回交換する。オーセンティケーションプロセスはＳＴＡがＡＰにオーセンティケーションフレームを送信することで開始される。オーセンティケーションフレームはユニキャストフレームである。オーセンティケーションフレームを受信した側は、Ａｃｋフレームを送信する。続いて、その受信側からオーセンティケーションフレームを送信する場合は、受信側はアクセス権を再度獲得してからオーセンティケーションフレームを送信する。４回交換する場合は、ＷＥＰ（ｗｉｒｅｄｅｑｕｉｖａｌｅｎｔｐｒｉｖａｃｙ）を使う場合である。しかし、その脆弱性からＷＥＰは使われない方向になっているため、通常はＳＴＡからＡＰへの送信、ＡＰからＳＴＡへの送信の２回で完了し、通常は４回交換することはない。ＡＰからＳＴＡへのオーセンティケーションフレームにはステータスコード（ＳｔａｔｕｓＣｏｄｅ）フィールドが入れられる。ステータスコードは、ＳＴＡからの要求をＡＰが受け付けるか否かをＳＴＡへ通知するものである。ＡＰは、要求を受け付ける場合には、ＳｔａｔｕｓＣｏｄｅフィールドにＳＵＣＣＥＳＳを意味する０を入れる。ＡＰは、要求を受け付けない場合には０以外の値をＳｔａｔｕｓＣｏｄｅフィールドに入れることにより、受け付けない理由を合わせてＳＴＡへ通知することができる。０以外の値としては、例えば１は特定の理由を明示せずに拒絶する場合に用いられ、１３はＳＴＡがＡＰの指定する特定のオーセンティケーションのアルゴリズムをサポートしない場合を理由として示した上で拒絶する場合に用いられる。

すなわちＳＴＡから開始されたオーセンティケーションプロセスが成功に終わる、すなわちＡＰがオーセンティケーションフレームでＳｔａｔｕｓＣｏｄｅフィールドに０を入れた場合、次にＳＴＡはアソシエーションプロセスを開始する。アソシエーションプロセスはＳＴＡがＡＰにアソシエーション要求（ＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔ）フレームを送信することで開始される。ＳＴＡはアソシエーション要求フレームに自ＳＴＡの無線通信能力を格納し、それを送信することでＡＰに自ＳＴＡの能力の通知をすることができる。アソシエーション要求フレームもアソシエーション応答フレームもユニキャストフレームであり、各々受信した側はＡｃｋフレームを送信する。ＡＰは、アソシエーション要求フレームをＳＴＡから受信すると、アソシエーション応答フレームをＳＴＡに送信する。アソシエーション応答フレームにはＡＰの無線通信能力情報とともにＳｔａｔｕｓＣｏｄｅフィールドが入れられる。ＳｔａｔｕｓＣｏｄｅフィールドが０（ＳＵＣＣＥＳＳ）である、すなわちアソシエーション要求を受け付けることを通知するアソシエーション応答フレームにはＢＳＳ内でＳＴＡを識別する識別子であるａｓｓｏｃｉａｔｉｏｎｉｄｅｎｔｉｆｉｅｒ（ＡＩＤ）が入れられる。ＡＰが各ＳＴＡにＡＩＤを割当てる。ＡＩＤを割当てられたＳＴＡは、ＡＰとの間で接続が完了したことになり、ＡＰとの間でデータフレームの交換を行うことができるようになる。ＳＴＡがＡＰと接続状態にある場合、ＳＴＡのＡＩＤが有効である。ＡＩＤを通知するフィールドはＡＩＤフィールドであり、１６ビットで構成される。実際にＡＩＤとして有効な値域は１から２００７である。ＡＰが、アソシエーションプロセス以外でＡＩＤフィールドを入れたフレームを送信する場合には、ＡＩＤフィールドとしては１から２００７以外の値を用いることもある。その場合は、ＡＩＤフィールドは、対象となるＳＴＡの属性などを指定するのに用いられる。

ＳＴＡがあるＡＰから他のＡＰへ再接続するための再アソシエーション（ｒｅａｓｓｏｃｉａｔｉｏｎ）プロセスでアソシエーション要求フレームを送信する場合もアソシエーションプロセスと同様の手順で同様の情報交換を行う。再アソシエーションプロセスがアソシエーションプロセスと異なる点は、再アソシエーションプロセスでＳＴＡが再接続を要求する他のＡＰに対して、再アソシエーション要求フレームを送信する際に、現在接続しているＡＰのＭＡＣアドレスを再アソシエーション要求フレームに追加することである。当該他のＡＰは、再アソシエーション要求フレームに対する応答である再アソシエーション応答（ＲｅａｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅ）フレームを送信する。

ＳＴＡがＡＰとデータフレームの交換ができる状態になると、ＡＰを介して認証サーバと接続できるため、４－ｗａｙハンドシェイクの手順を介してａｄｖａｎｃｅｄｓｅｃｕｒｉｔｙｓｔａｎｄａｒｄ（ＡＥＳ）などの暗号化処理を送信するフレームに施すことができるようになる。

＜ＭＡＣフレーム＞
ＭＡＣフレームはＭＡＣ層で生成されるフレームである。ＭＡＣフレームは、基本的に管理（ｍａｎａｇｅｍｅｎｔ）フレーム、データ（ｄａｔａ）フレーム、制御（ｃｏｎｔｒｏｌ）フレームの３種類に大別される。なお、一部のＩＥＥＥ８０２．１１拡張規格では、拡張（ｅｘｔｅｎｓｉｏｎ）フレームも定義されている。

上述のビーコンフレームやプローブ要求フレーム、プローブ応答フレーム、オーセンティケーションフレーム、アソシエーション要求フレーム、アソシエーション応答フレーム、再アソシエーション要求フレーム、再アソシエーション応答フレームなどはＭＡＣフレームのうちの管理フレームに分類される。管理フレームは他のＳＴＡとの間の通信リンクの管理のために用いられる。

上述のデータフレームは、ＭＡＣフレームのうちのデータ（ｄａｔａ）フレームに分類される。上述のｄａｔａフレームは、ＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）対応に対応するか否か、データのみを格納するか否か、あるいはＡｃｋフレームの意味も含むかなどの付加的な情報があるか否か、などによって細かく分かれる。なお、データフレームは通常は上位層から渡されたデータを格納するものである。しかし、特殊な例として、データフレームは、ＭＡＣ層で生成され、データを含まないデータフレームも含む。データを含まないデータフレームにはＮｕｌｌフレームとＱｏＳＮｕｌｌフレームの２種類がある。

上述のＡｃｋフレームはＭＡＣフレームのうちの制御フレームに分類される。他に応答系の制御フレームとして、ＢｌｏｃｋＡｃｋフレームや、ＢｌｏｃｋＡｃｋフレームの送信を要求するＢｌｏｃｋＡｃｋＲｅｑフレームや、送信権を獲得するフレーム交換の先頭で再送のダメージを削減するために送信するＲＴＳ（ｒｅｑｕｅｓｔｔｏｓｅｎｄ）フレームや、ＲＴＳフレームへの応答として送信あるいは送信先からの応答を求めない場合に送信権獲得のためのフレーム交換先頭で送信するＣＴＳ（ｃｌｅａｒｔｏｓｅｎｄ）フレームなどがある。制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信（すなわち交換）するときの制御のために用いられるものである。

＜ＭＡＣフレームフォーマット＞
図３の（ａ）は、ＭＡＣフレームの基本的なフォーマットを示す図である。本実施形態に係る管理フレーム、データフレームおよび制御フレームは、このようなフレームフォーマットをベースとする。本フレームフォーマットは、ＭＡＣヘッダ（ＭＡＣｈｅａｄｅｒ）、ＦｒａｍｅＢｏｄｙ（オクテット単位の可変長）及びＦＣＳ（ＦｒａｍｅＣｈｅｃｋＳｅｑｕｅｎｃｅ）（４オクテット）の各フィールドを含む。なお、前述のデータを含まないデータフレームであるＮｕｌｌフレームとＱｏＳＮｕｌｌフレームなどのようにＦｒａｍｅＢｏｄｙフィールドが存在しないＭＡＣフレームもあり得る。

図３の（ｂ）はＭＡＣヘッダの基本的なフォーマットを示す図である。ＭＡＣヘッダは、ＦｒａｍｅＣｏｎｔｒｏｌ（２オクテット）、Ｄｕｒａｔｉｏｎ／ＩＤ（２オクテット）、Ａｄｄｒｅｓｓ１（６オクテット）、Ａｄｄｒｅｓｓ２（０又は６オクテット）、Ａｄｄｒｅｓｓ３（０又は６オクテット）、ＳｅｑｕｅｎｃｅＣｏｎｔｒｏｌ（０又は２オクテット）、Ａｄｄｒｅｓｓ４（０又は６オクテット）、ＱｏＳＣｏｎｔｒｏｌ（０又は２オクテット）及びＨＴ（ＨｉｇｈＴｈｒｏｕｇｈｐｕｔ）Ｃｏｎｔｒｏｌ（０又は４オクテット）の各フィールドを含む。

これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しないＭＡＣヘッダもあり得る。例えばＡｄｄｒｅｓｓ３フィールドやＡｄｄｒｅｓｓ４フィールドが存在しないＭＡＣヘッダもある。また、ＱｏＳＣｏｎｔｒｏｌおよびＨＴＣｏｎｔｒｏｌの２フィールドの両方または一方が存在しないＭＡＣヘッダもある。また図３には示されていない他のフィールドが新たにＭＡＣヘッダ内に追加されてもよい。

ＦｒａｍｅＣｏｎｔｒｏｌフィールドには、タイプ（Ｔｙｐｅ）、サブタイプ（Ｓｕｂｔｙｐｅ）という２つのフィールド等が含まれる。管理フレームか、データフレームか、制御フレームかなどの大別はＴｙｐｅフィールドで行われる。大別されたフレームの中での細かい種別はＳｕｂｔｙｐｅフィールドで行われる。例えば制御フレームについては、前述のようにＢｌｏｃｋＡｃｋフレーム、ＢｌｏｃｋＡｃｋＲｅｑフレーム、ＲＴＳフレーム、ＣＴＳフレームといった分解能の情報がＳｕｂｔｙｐｅフィールドに入れられる。

媒体予約時間がＤｕｒａｔｉｏｎ／ＩＤフィールドに入れられる。Ｄｕｒａｔｉｏｎ／ＩＤフィールドに媒体予約時間が入れられている場合には、ＲＡで指定されたＳＴＡ以外のＳＴＡがそのフレームを受信した場合には、受信したＳＴＡはＤｕｒａｔｉｏｎ／ＩＤフィールドを後述のＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）を設定する時間（ＮＡＶ値）として用いる。制御フレームの中で省電力の時に使用されるＰＳ（ｐｏｗｅｒｓａｖｅ）－Ｐｏｌｌフレームでは、Ｄｕｒａｔｉｏｎ／ＩＤフィールドに媒体予約時間ではなく、そのフレームを送信するＳＴＡがＡＰから割り当てられたＡＩＤが記載される。ＰＳ－ＰｏｌｌフレームをＲＡで指定されたＳＴＡ以外のＳＴＡが受信した場合には、受信したＳＴＡは、Ｔｙｐｅフィールドが制御フレームを表していることと、ＳｕｂｔｙｐｅフィールドがＰＳ－Ｐｏｌｌフレームであることとを把握することで、Ｄｕｒａｔｉｏｎ／ＩＤフィールドからＮＡＶ値を設定できないことを把握する。その場合、ＳＴＡはｓｈｏｒｔｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＳＩＦＳ）という固定時間とＰＳ－Ｐｏｌｌフレームへの応答として送信されるＡｃｋフレームが媒体を占有する推定時間との和をＮＡＶ値として設定する。ＳＴＡは、このＡｃｋフレームが媒体を占有する推定時間をＰＳ－Ｐｏｌｌフレームの伝送レートから推定されるＡｃｋフレームの伝送レートとＡｃｋフレーム長（１４オクテット固定）とから求める。

Ａｄｄｒｅｓｓ１フィールドには、受信先アドレス（ｒｅｃｅｉｖｅｒａｄｄｒｅｓｓ；ＲＡ）が入る。Ａｄｄｒｅｓｓ２フィールドは、一部の制御フレームでは存在しない場合もある。存在する場合には、Ａｄｄｒｅｓｓ２フィールドには、送信元アドレス（ｔｒａｎｓｍｉｔｔｅｒａｄｄｒｅｓｓ；ＴＡ）が入る。Ａｄｄｒｅｓｓ３フィールドは、制御フレームでは存在しない。Ａｄｄｒｅｓｓ３フィールドは、管理フレームとデータフレームでは存在する。Ａｄｄｒｅｓｓ３フィールドには、フレームの用途に応じてＢＳＳの識別子であるＢＳＳＩＤか、ＴＡか、データの最終宛先アドレス（ｄｅｔｉｎａｔｉｏｎａｄｄｒｅｓｓ；ＤＡ）か、データの送信元アドレス（ｓｏｕｒｃｅａｄｄｒｅｓｓ；ＳＡ）が入る。なお、ＢＳＳＩＤは、全てのＢＳＳＩＤを対象とするｗｉｌｄｃａｒｄＢＳＳＩＤ（全てのビットが１）の場合もある。Ａｄｄｒｅｓｓ４フィールドは、データフレームの場合でかつＡＰ間でＳＴＡからのデータを転送する場合に存在する。Ａｄｄｒｅｓｓ４フィールドは、Ａｄｄｒｅｓｓ３フィールドがＤＡを通知するのに用いられる。Ａｄｄｒｅｓｓ４フィールドはＳＡを通知するのに用いられる。

ＳｅｑｕｅｎｃｅＣｏｎｔｒｏｌフィールドはＳｅｑｕｅｎｃｅＮｕｍｂｅｒサブフィールドとＦｒａｇｍｅｎｔＮｕｍｂｅｒサブフィールドに分かれている。ＳｅｑｕｅｎｃｅＮｕｍｂｅｒサブフィールドにはフレームに割り当てられたシーケンス番号を入れ、ＦｒａｇｍｅｎｔＮｕｍｂｅｒサブフィールドにはデータがフラグメント処理により複数のフラグメントに分割された場合に当該フレームで対応するフラグメント番号を入れる。

ＱｏＳフィールドは、フレームの優先度を考慮して送信を行うＱｏＳ制御を行うために用いられる。ＨＴＣｏｎｔｒｏｌフィールドは、ＩＥＥＥ８０２．１１ｎ規格で導入されたフィールドであり、ＩＥＥＥ８０２．１１ｎ規格の後継であるＩＥＥＥ８０２．１１ａｃ規格、ＩＥＥＥ８０２．１１ａｘ規格においても用いられる。ＨＴＣｏｎｔｒｏｌフィールドには、ＩＥＥＥ８０２．１１ｎ規格に対応させる場合はＨＴｖａｒｉａｎｔが設けられ、ＩＥＥＥ８０２．１１ａｃ規格に対応させる場合はＶＨＴｖａｒｉａｎｔが設けられ、ＩＥＥＥ８０２．１１ａｘ規格に対応させる場合はＨＥｖａｒｉａｎｔが設けられる。各バリアントはＨＴＣｏｎｔｒｏｌの先頭１ビットないしは２ビットで識別される。

ＦｒａｍｅＢｏｄｙフィールドは、フレームのタイプやサブタイプに応じた情報を入れるフィールドである。ＮｕｌｌフレームとＱｏＳＮｕｌｌフレーム以外のデータフレームでは、ＦｒａｍｅＢｏｄｙフィールドにデータが入る。管理フレームでは、サブタイプに応じて複数の固定フィールドや、複数の情報エレメント（ｉｎｆｏｒｍａｔｉｏｎｅｌｅｍｅｎｔ）がＦｒａｍｅＢｏｄｙフィールドに入る。制御フレームでは、サブタイプに応じてＦｒａｍｅＢｏｄｙフィールドがない場合もあるし、また複数の固定フィールドがＦｒａｍｅＢｏｄｙフィールドに含まれる場合もある。

ＦＣＳフィールドには、受信側でフレームの誤り検出のため用いられるチェックサム符号としてＦＣＳ情報が設定される。ＦＣＳ情報の例としては、ＣＲＣ（ｃｙｃｌｉｃｒｅｄｕｎｄａｎｃｙｃｏｄｅ）などがある。

＜ＮＡＶの説明＞
ＩＥＥＥ８０２．１１規格では、ＳＴＡ（ＡＰを含む）は、ＣＳＭＡ／ＣＡにより媒体アクセス権（以降、送信権と称する）を獲得した後、媒体を占有可能な時間（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ；ＴＸＯＰ）を得ると、ＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）属性などの制限を伴うものの、他のＳＴＡ（ＡＰを含む）との間でＭＡＣフレームを連続して交換できるようになる。

このＴＸＯＰにおいて、ＭＡＣフレームの交換を行う２つのＳＴＡ以外の第三者ＳＴＡが別のＭＡＣフレームを送信すると、２つのＳＴＡで交換中のフレーム（厳密にはフレームを格納する物理パケット（ｐｈｙｓｉｃａｌｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ；ＰＰＤＵ））と第三者ＳＴＡにより送信されたＭＡＣフレームとが衝突してしまう。そこで、第三者ＳＴＡが送信権を獲得することをＴＸＯＰの終了後まで延期するために、ＮＡＶという仕組みが設けられている。ＭＡＣフレーム交換を行っている２つのＳＴＡの周辺の第三者ＳＴＡでＮＡＶが設定されている状態では、ＴＸＯＰ、すなわち無線リソースが保護（ｐｒｏｔｅｃｔｉｏｎ）されている。

受信処理部９０は、ＣＳＭＡ／ＣＡ処理においてまず媒体が空いているかどうかを確認する、すなわちキャリアセンスを行う。ここで、キャリアセンスは、ＣＣＡ（ｃｌｅａｒｃｈａｎｎｅｌａｓｓｅｓｓｍｅｎｔ）のビジー／アイドルに関する物理的なキャリアセンス（ｐｈｙｓｉｃａｌｃａｒｒｉｅｒｓｅｎｓｅ）と、受信したフレームのＤｕｒａｔｉｏｎ／ＩＤフィールドの値あるいは受信フレーム種別に基づく仮想的なキャリアセンス（ｖｉｒｔｕａｌｃａｒｒｉｅｒｓｅｎｓｅ）との両方を包含するものである。物理的なキャリアセンスは、物理的な媒体で－６２ｄＢｍ以上の信号を検知すると発動する。後者のように、仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶと呼ばれる。なお、１つのチャネルを複数のリソースユニット（ｒｅｓｏｕｒｃｅｕｎｉｔ；ＲＵ）に分け、その一部を使って送受信するような場合に、受信処理部９０は、チャネル単位で行ったＣＣＡの結果情報またはＮＡＶに基づくキャリアセンス情報を当該一部のＲＵに適用してもよい。例えばキャリアセンス情報がアイドルを示すチャネルに属するＲＵでは、受信処理部９０は、キャリアセンスはアイドルと判断する。ＳＴＡ（ＡＰを含む）は他のＳＴＡ宛てのＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりからＮＡＶを設定する。受信処理部９０は、ＮＡＶ値をメモリ９４に書き込むことにより、ＮＡＶを設定することができる。また、新たなフレームを受信し、それによって設定するＮＡＶの方が現在のＮＡＶよりも長い、すなわち新たなフレームにより設定されるＮＡＶの終了タイミングが現在のＮＡＶで設定されている終了タイミングよりも遅い場合には、受信処理部９０は、メモリ９４に書き込まれている現在のＮＡＶ値を新たなフレームによるＮＡＶ値により更新する。このＮＡＶ値の更新により、現在のＮＡＶの終了時刻が新たなフレームによるＮＡＶの終了時刻まで延長する。

８０２．１１ａｘ規格では、上記のＤｕｒａｔｉｏｎ／ＩＤフィールドで示される媒体占有時間を８０２．１１ａｘ規格で新たに定義された物理パケット（ＨＥＰＰＤＵ）の物理（ｐｈｙｓｉｃａｌ；ＰＨＹ）ヘッダにあるＨＥ－ＳＩＧ－ＡフィールドのＴＸＯＰフィールドにも入れるようになっている。ＳＴＡ（ＡＰを含む）は受信復号できないＨＥＰＰＤＵを受信し、このＴＸＯＰフィールドに有意な値が設定されている場合には、その値からＮＡＶ値を取得する。またＨＥＰＰＤＵのＨＥ－ＳＩＧ－ＡフィールドにはＢＳＳＣｏｌｏｒフィールドがある。ＳＴＡ（ＡＰを含む）は、このフィールドによって自ＢＳＳ内のＨＥＰＰＤＵか他ＢＳＳ（ｏｖｅｒｌａｐｐｉｎｇＢＳＳ；ＯＢＳＳ）から送信されているＨＥＰＰＤＵかを判別できる。ＳＴＡ（ＡＰを含む）はＨＥＰＰＤＵを送信する際には、ＢＳＳＣｏｌｏｒフィールドに自ＢＳＳで設定したＢＳＳｃｏｌｏｒ値を設定する。自ＢＳＳで用いるＢＳＳｃｏｌｏｒ値はＡＰが決定する。

またさらに８０２．１１ａｘ規格では、アップリンク（ｕｐｌｉｎｋ；ＵＬ）マルチユーザ（ｍｕｌｔｉ－ｕｓｅｒ；ＭＵ）送信を実現するために、受信した物理パケットが自ＢＳＳから送信された物理パケットの場合に適用するＮＡＶとしてｉｎｔｒａ－ＢＳＳＮＡＶが特別に設けられる。ｉｎｔｒａ－ＢＳＳＮＡＶは、他の場合に適用するＮＡＶ、すなわち受信した物理パケットがＯＢＳＳから送信された物理パケットあるいは受信した物理パケットの送信元が自ＢＳＳかＯＢＳＳかを判別できない場合に適用されるＮＡＶと区別される。ここで、他の場合に適用されるＮＡＶは、ｂａｓｉｃＮＡＶと呼ばれる。ＡＰが１つまたは複数のＳＴＡに対し、ＵＬＭＵ送信を指示するフレームはトリガー（Ｔｒｉｇｇｅｒ）フレームである。トリガーフレームは制御フレームの一種である。図４は、トリガーフレームに対して応答してＵＬＭＵ送信できるか否かをｂａｓｉｃＮＡＶの設定状態とｉｎｔｒａ－ＢＳＳＮＡＶの設定状態との関係に依存して示す図である。なお、厳密には、トリガーフレーム内にキャリアセンスを要求するか否かを示すＣＳＲｅｑｕｉｒｅｄサブフィールドがあり、そのサブフィールドが“１”、すなわちキャリアセンスを要求する、とある場合に、ＳＴＡ（ＡＰ含む）は、これらの２つのＮＡＶの設定状態を加味して、トリガーフレームに応答可能であると判断すると、ＵＬＭＵパケットを送信できる。

（１）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、トリガーフレームへの応答は不可（すなわち、ＵＬＭＵ送信できない）である。

（２）ｂａｓｉｃＮＡＶが０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、トリガーフレームへの応答は不可（すなわち、ＵＬＭＵ送信できない）である。

（３）ｂａｓｉｃＮＡＶが０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、トリガーフレームへの応答は可能（すなわち、ＵＬＭＵ送信できる）である。

（４）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は可能であり、トリガーフレームへの応答は可能（すなわち、ＵＬＭＵ送信できる）である。

ｉｎｔｒａ－ＢＳＳＮＡＶは、ＳＴＡ（ＡＰを含む）が受信した物理パケットに格納されたＭＡＣフレームのアドレスフィールドである、ＲＡ、ＴＡ、あるいはＢＳＳＩＤフィールド値として自ＢＳＳのＢＳＳＩＤが設定されている場合に設定される。もしくは、ＳＴＡ（ＡＰを含む）が受信した物理パケットに格納された制御フレームにＴＡがなく、ＲＡはあり、そのＲＡに記載された値がその前に送信権を獲得したＴＸＯＰｈｏｌｄｅｒとして保持していたＭＡＣアドレスと同一と判断し、かつそのＴＸＯＰｈｏｌｄｅｒを保持した際にｉｎｔｒａ－ＢＳＳＮＡＶが設定されていた場合（つまりｉｎｔｒａ－ＢＳＳ通信として認識したＴＸＯＰのＴＸＯＰｈｏｌｄｅｒから何らかのフレームを送信されてそれに対する応答フレームにＴＡはないがＲＡはあり、そのＲＡがＴＸＯＰｈｏｌｄｅｒ宛てになっていると判断できる場合）に、ｉｎｔｒａ－ＢＳＳＮＡＶは設定される。また、ＳＴＡ（ＡＰを含む）が物理パケットを復号できない場合に物理パケットのヘッダ情報から同一ＢＳＳ内の通信であると判断できる場合も、ｉｎｔｒａ－ＢＳＳＮＡＶが設定される。この場合の物理パケットのヘッダ情報とは例えば前述のＢＳＳＣｏｌｏｒフィールドである。あるいは、ＳＴＡ（ＡＰを含む）は８０２．１１ａｃ規格で規定される物理パケット（ＶＨＴＰＰＤＵ）のヘッダに入れられるＶＨＴ－ＳＩＧ－ＡフィールドのＰａｒｉｔａｌＡＩＤフィールドに基づいてデータフレームを受信した通信が同一ＢＳＳ内の通信であると判断してもよい。

８０２．１１ａｘ規格では、ＡＰは必ずしもこの２つのＮＡＶを持つ必要はない。すなわち、ＡＰがｉｎｔｒａ－ＢＳＳＮＡＶを持つことはオプションである。ＡＰがｉｎｔｒａ－ＢＳＳＮＡＶを持たない場合は、ＡＰが８０２．１１ａｃ規格までの通常の１つのＮＡＶを持つ動作と同じ動作である。ＡＰでｉｎｒａ－ＢＳＳＮＡＶがオプションであるのは、８０２．１１ａｘ規格でトリガーフレームを送信するのは必ずＡＰであり、それを受信してその応答としてＵＬＭＵ送信を行うのは必ずＳＴＡだったからである。つまりＡＰでは図４でのトリガーフレームに対する応答の場合が存在しないからである。

＜Ｔｒｉｇｇｅｒｆｒａｍｅ＞
図５は、トリガーフレームのフォーマットの一例を示す図である。

Ｄｕｒａｔｉｏｎフィールド（２オクテット）は、上述のＤｕｒａｔｉｏｎ／ＩＤフィールドである。

ＣｏｍｍｏｎＩｎｆｏフィールド（８オクテット又はそれ以上）はＵＬＭＵ送信で対象となる全てのＳＴＡに共通の指示情報を示す領域である。ＣｏｍｍｏｎＩｎｆｏフィールドとしては、前述のＣＳＲｅｑｕｉｒｅｄサブフィールドの他に、トリガーフレームの種別を示すＴｒｉｇｇｅｒＴｙｐｅサブフィールドや、ＵＬＭＵパケットの時間長を指示するＵＬＬｅｎｇｔｈサブフィールドなどがある。

ＵｓｅｒＩｎｆｏＬｉｓｔフィールド（オクテット単位の可変長）は複数のＵｓｅｒＩｎｆｏフィールドから成る。各ＵｓｅｒＩｎｆｏフィールドは個々のＳＴＡ向けの制御情報を通知するものである。個々のＳＴＡのＡＩＤはＵｓｅｒＩｎｆｏフィールドの中のＡＩＤ１２サブフィールドで指定される。また特定のＳＴＡを指定せずに、ＵＬ直交周波数分割多重（ＵＬｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｅｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ；ＵＬＯＦＤＭＡ）ベースのランダムアクセス（ＵＬＯＦＤＭＡｂａｓｅｄｒａｎｄｏｍａｃｃｅｓｓ；ＵＯＲＡ）でＡＰに接続済みのＳＴＡ（ａｓｓｏｃｉａｔｅｄＳＴＡｓ）を対象とする場合には、“０”がＡＩＤ１２サブフィールドに設定される。特定のＳＴＡを指定せずに、ＵＯＲＡでＡＰに未接続のＳＴＡ（ｕｎａｓｓｏｃｉａｔｅｄＳＴＡｓ）を対象とする場合には、“２０４５”がＡＩＤ１２サブフィールドに設定される。ＵｓｅｒＩｎｆｏフィールドとしては、ＡＩＤ１２サブフィールドの他に、どのＲＵでの送信が割り当てられているかを示すＲＵＡｌｌｏｃａｔｉｏｎサブフィールドや、送信に用いる変調符号化方式（ｍｏｄｕｌａｔｉｏｎａｎｄｃｏｄｉｎｇｓｃｈｅｍｅ；ＭＣＳ）を指示するＵＬＨＥ－ＭＣＳサブフィールドなどがある。

＜ｍｕｌｔｉ－ＡＰの説明＞
複数ＡＰ連携（Ｍｕｌｔｉ－ＡＰｃｏｏｒｄｉｎａｔｉｏｎ；ＭＡＰ）はＥＳＳを構成する複数のＡＰが連携して動作することの総称である。

例えばあるＡＰが送信権獲得後に他の１つないし複数のＡＰに当該ＡＰが獲得したＴＸＯＰの一部無線リソースを分け与えるというような協調動作がある。ここで、送信権を獲得し、ＴＸＯＰの一部無線リソースを分け与えるＡＰが共有元ＡＰ（ｓｈａｒｉｎｇＡＰ）であり、一部無線リソースを分け与えられるＡＰが共有先ＡＰ（ｓｈａｒｅｄＡＰ）である。また無線リソースとは、時間あるいは周波数のことである。

図６は、共有元ＡＰが自身で獲得したＴＸＯＰの一部のリソース（時間）を時間で分割して共有先ＡＰに分け与え、ＴＸＯＰの一部のリソース（時間）を周波数で分離しない形態のＭＡＰの一例を示す。この場合は、共有元ＡＰは複数の共有先ＡＰに時分割でＴＸＯＰを分け与えることになる。共有元ＡＰであるＡＰ１は、ＴＸＯＰ１を獲得し、その一部の時間ＴＸＯＰ１１を自身で利用する。ＴＸＯＰ１１の終了後、ＡＰ１は、残りの一部の時間ＴＸＯＰ１２を共有先ＡＰの１つであるＡＰ２に分け与える。ＴＸＯＰ１２の終了後、ＡＰ１は、残りの一部の時間ＴＸＯＰ１３を共有先ＡＰの他の１つであるＡＰ２に分け与える。共有先ＡＰに分け与えられたＴＸＯＰの周波数幅は、共有元ＡＰが送信権を獲得した周波数幅と同じになる。例えば、共有元ＡＰが連続する２０ＭＨｚチャネル４つの８０ＭＨｚチャネルを獲得した場合には、複数の共有先ＡＰが各々時間分割でその８０ＭＨｚチャネルを使っていくことになる。

基準となる周波数チャネル（上記の例では２０ＭＨｚ）を複数まとめて使う手法をチャネルボンディング（ｃｈａｎｎｅｌｂｏｎｄｉｎｇ）と言う。図７はチャネルボンディングの一例を説明するための図である。

図７の（ａ）は、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚのボンディングチャネルを生成するためのチャネルボンディングの一例を示す。ＢＳＳにはＡＰが許容と指定する最大のチャネル幅まで、さまざまなチャネル幅に対応するＳＴＡが接続できる。そのＢＳＳを構成する全てのＳＴＡ（ＡＰを含む）が共通に動作可能な２０ＭＨｚチャネルがプライマリチャネルである。プライマリチャネルでは、必ずビーコンフレームが送信される。プライマリチャネルと連続し、プライマリチャネルと合わせて４０ＭＨｚボンディングチャネルを構成する２０ＭＨｚチャネルがセカンダリチャネルとなる。図７の（ａ）ではプライマリチャネルの右側（高周波数側）がセカンダリチャネルとなる例を示している。しかし、セカンダリチャネルの配置は、図７の（ａ）の例に限らない。プライマリチャネルとセカンダリチャネルとからなる４０ＭＨｚボンディングチャネルと連続し、４０ＭＨｚボンディングチャネルと合わせて８０ＭＨｚボンディングチャネルを構成する２つの２０ＭＨｚチャネルがセカンダリ４０ＭＨｚチャネル（ボンディングチャネル）を構成する。図７の（ａ）ではプライマリチャネルの左側（低周波数側）がセカンダリ４０ＭＨｚチャネルとなる例を示している。しかし、セカンダリ４０ＭＨｚチャネルの配置は、図７の（ａ）の例に限らない。プライマリチャネルとセカンダリチャネルとセカンダリ４０ＭＨｚチャネルとからなる８０ＭＨｚボンディングチャネルと連続し、８０ＭＨｚボンディングチャネルと合わせて１６０ＭＨｚボンディングチャネルを構成する４つの２０ＭＨｚチャネルがセカンダリ８０ＭＨｚチャネル（ボンディングチャネル）を構成する。図７の（ａ）ではセカンダリチャネルの右側（高周波数側）がセカンダリ８０ＭＨｚチャネルとなる例を示している。しかし、セカンダリ８０ＭＨｚチャネルの配置は、図７の（ａ）の例に限らない。３２０ＭＨｚチャネルボンディングでは、８つの連続する２０ＭＨｚチャネルからなるセカンダリ１６０ＭＨｚチャネル（ボンディングチャネル）が先の１６０ＭＨｚボンディングチャネルに連接する構成となる。

図７の（ｂ）のように、セカンダリチャネルとセカンダリ８０ＭＨｚチャネルが離間して合計で１６０ＭＨｚチャネルを確保することもでき、この場合は８０＋８０ＭＨｚボンディングチャネルと称する。

図８は、図７の（ａ）に示すチャネルボンディングの一例における送信権獲得方法を説明する図である。各ＡＰまた各ＳＴＡが２０ＭＨｚより大きいチャネル幅での送信権を獲得する場合に図８で説明する方法が適用される。図８の（ａ）は４０ＭＨｚのチャネルボンディングの場合の送信権獲得方法を説明する。以降では、送信元ＡＰが送信権を獲得する場合を例に説明する。送信元ＡＰはプライマリ２０ＭＨｚチャネルでＣＳを行う。プライマリ２０ＭＨｚチャネルについて送信権の獲得が可能であった場合、その時点からＰＩＦＳ（ＳＩＦＳ＋１スロット時間）遡る期間中にセカンダリ２０ＭＨｚチャネルのＣＳ状況の確認を行う。セカンダリ２０ＭＨｚチャネルについてＰＩＦＳ期間中にビジーを検出せず送信権の獲得が可能であった場合、送信元ＡＰは４０ＭＨｚのボンディングチャネルで送信を行う。セカンダリ２０ＭＨｚチャネルについてＰＩＦＳ期間中にビジーを検出した場合はセカンダリ２０ＭＨｚチャネルで送信権の獲得が不可であったと判断し、送信元ＡＰはプライマリ２０ＭＨｚチャネルのみで送信を行う、あるいは再度４０ＭＨｚチャネルでの送信を試みるためにプライマリ２０ＭＨｚチャネルでのＣＳ状況の確認から動作を再開してもよい。

図８の（ｂ）は８０ＭＨｚのチャネルボンディングの場合の送信権獲得方法を説明する。共有元ＡＰは例えば自ＢＳＳで最大８０ＭＨｚのチャネル幅のサポートを行うとした場合、プライマリチャネルを基準に、それと連続する１つの２０ＭＨｚチャネルをセカンダリチャネルに、またプライマリチャネルとセカンダリチャネルで構成する４０ＭＨｚボンディングチャネルと連続する２つの２０ＭＨｚチャネルをセカンダリ４０ＭＨｚチャネルとして設定する。共有元ＡＰはセカンダリチャネル、セカンダリ４０ＭＨｚチャネルをどのように設定するかをビーコンフレーム、またプローブ応答フレームでＳＴＡに通知する。共有元ＡＰはＢＳＳで４０ＭＨｚチャネルまでしか用いない場合も、セカンダリチャネルを同様に通知する。また、共有元ＡＰは、１６０ＭＨｚチャネルや８０＋８０ＭＨｚチャネルの場合には、同様にセカンダリ８０ＭＨｚチャネルも通知し、３２０ＭＨｚチャネルの場合には、同様にセカンダリ１６０ＭＨｚチャネルも通知する。送信元ＡＰは８０ＭＨｚチャネルでの送信権獲得を試みる場合には、前述の４０ＭＨｚチャネルでの場合と同様、プライマリ２０ＭＨｚチャネルを基準に、プライマリ２０ＭＨｚチャネルについて送信権の獲得が可能と判断した時刻から遡ってＰＩＦＳ以内のセカンダリ２０ＭＨｚチャネル、セカンダリ４０ＭＨｚチャネル毎にＣＳ状況を確認し、その条件をクリアした最大のチャネル幅での送信を行う。すなわち、送信元ＡＰはセカンダリ２０ＭＨｚチャネルがＰＩＦＳ内でビジーを検出していたなら、仮にセカンダリ４０ＭＨｚチャネルではＰＩＦＳ内でビジーを検出していなくても、プライマリ２０ＭＨｚチャネルのみで送信を行う。あるいは、次の機会により広帯域を確保できることを期待して、再度８０ＭＨｚチャネルでの送信を試みるために、送信元ＡＰはプライマリ２０ＭＨｚチャネルでのＣＳ状況の確認から動作を再開してもよい。プライマリ２０ＭＨｚチャネルとセカンダリ２０ＭＨｚチャネルがＣＳ条件をクリアし、セカンダリ４０ＭＨｚチャネルではＰＩＦＳ内でビジーを検出している場合には、プライマリ２０ＭＨｚチャネルとセカンダリ２０ＭＨｚチャネルを用いた４０ＭＨｚチャネルでの送信ができる。すなわち８０ＭＨｚチャネルで送信するためには、プライマリチャネルでのＣＳ条件をクリアした上でセカンダリ２０ＭＨｚチャネルもセカンダリ４０ＭＨｚチャネルもＰＩＦＳ内でビジーを検出していないことが条件になる。１６０ＭＨｚチャネルで送信する場合も、同様にプライマリ２０ＭＨｚチャネルを基準に、セカンダリ２０ＭＨｚチャネルもセカンダリ４０ＭＨｚチャネルもセカンダリ８０ＭＨｚチャネルもＰＩＦＳ内でビジーを検出していないことが条件になる。３２０ＭＨｚチャネルで送信する場合は、同様にプライマリ２０ＭＨｚチャネルを基準に、セカンダリ２０ＭＨｚチャネルもセカンダリ４０ＭＨｚチャネルもセカンダリ８０ＭＨｚチャネルもセカンダリ１６０ＭＨｚチャネルもＰＩＦＳ内でビジーを検出していないことが条件になる。以上がチャネルボンディングを利用したＣＳの基本であるが、広帯域チャネルを２０ＭＨｚごとのサブチャネル単位でＣＳするようにし、ビジーとなる一部の２０ＭＨｚチャネルで送信しない手法（パンクチャ技術）を利用することも可能である。パンクチャ技術を適用した物理パケットの送信方法としては物理ヘッダからパンクチャして一つの物理パケットとして送信する手法（パンクチャパケット）と、一部の２０ＭＨｚサブチャネルでは送信せずに残りの２０ＭＨｚサブチャネル単位で同一の物理パケットを送信する手法（デュプリケートパケット）がある。これにより、広帯域の送信権獲得がしやすくなる。パンクチャ技術を利用するときもプライマリ２０ＭＨｚチャネルでは送信権が獲得できていなくてはならない。パンクチャ技術を利用して物理パケットを送信する場合には物理ヘッダにどこの２０ＭＨｚチャネルがパンクチャされているかを通知する。パンクチャされている２０ＭＨｚサブチャネルの組み合わせは制限されていてもよい。これによっていずれかの２０ＭＨｚサブチャネルで物理ヘッダを取得すれば、他のどの２０ＭＨｚサブチャネルでも送信されているかを把握できる。パンクチャ技術を利用した物理パケットを受信復号できるかをＡＰまたＳＴＡは互いに通知し（ＡＰならビーコンフレームやプローブ応答フレームで通知、またＳＴＡならアソシエーション要求フレームや際アソシエーション要求フレームで通知）、対応可能な相手にだけ物理パケットを送信する。ＭＡＰでは送信元ＡＰは、送信先ＡＰがパンクチャされた物理パケットを受信できる場合にパンクチャされた物理パケットを送信できるとする。

図９は、共有元ＡＰが自身で獲得したＴＸＯＰの一部のリソース（時間）を周波数で分割して複数の共有先ＡＰに分け与える形態のＭＡＰの一例を示す。この場合は、共有元ＡＰは複数の共有先ＡＰに周波数分割でＴＸＯＰを分け与えることになる。共有元ＡＰであるＡＰ１は、ＴＸＯＰ１を獲得し、その一部の時間ＴＸＯＰ１１を自身で利用する。ＴＸＯＰ１１の終了後、ＡＰ１は、残りの一部の時間ＴＸＯＰ１２の周波数幅を分割して得られた第１周波数幅のＴＸＯＰ１２を共有先ＡＰの１つであるＡＰ２に分け与えるとともに、第２周波数幅のＴＸＯＰ１２を共有先ＡＰの他の１つであるＡＰ３に分け与える。各共有先ＡＰに割り当てた周波数幅の合計は、共有元ＡＰが送信権を獲得した周波数幅と同じか、それよりも狭くなる、つまり共有元ＡＰが送信権を獲得した周波数幅以下となる。当然、各共有先ＡＰに割り当てた周波数は共有元ＡＰが送信権を獲得した周波数内である。これは、送信権を獲得した期間であるＴＸＯＰは周波数方向にも及んでおり、共有元ＡＰのＴＸＯＰ１はある周波数幅を保護しているため、その保護内の周波数であれば他のＡＰに分け与えられるということである。例えば図９において、共有元ＡＰ１が８０ＭＨｚチャネルを獲得した場合、共有先ＡＰ２に４０ＭＨｚ、共有先ＡＰ３に４０ＭＨｚを割当てる。この場合ＡＰ２とＡＰ３に割り当てられた周波数の合計は８０ＭＨｚで、ＡＰ１が獲得した８０ＭＨｚ幅と同じである。あるいは、ＡＰ２に４０ＭＨｚ、ＡＰ３に２０ＭＨｚを割当ててもよい。この場合はＡＰ２とＡＰ３に割り当てられた周波数の合計は６０ＭＨｚで、ＡＰ１が獲得した８０ＭＨｚ幅よりも狭くなる。

当然、時分割ＭＡＰと周波数分割ＭＡＰを組み合わせてもよい。当然、共有元ＡＰが他のＡＰにＴＸＯＰの一部無線リソースを分け与えつつ、自ＡＰも他のＡＰと同様に再度ＴＸＯＰの一部無線リソースを使ってもよい。例えば図６において、ＴＸＯＰ１２とＴＸＯＰ１３の後に、ＴＸＯＰ１が終了するまでに時間が残っていれば、再度ＡＰ１がＴＸＯＰを使うようにしてもよい。また例えば図９において、ＴＸＯＰ１２をＡＰ２とＡＰ３に周波数分割で割り当てたが、ＴＸＯＰ１２の周波数の一部をＡＰ１自身が使って、ＡＰ２、ＡＰ３と並行してＴＸＯＰ１２を利用してもよい。

ＴＸＯＰの一部無線リソースを共有先ＡＰに分け与える場合には、ＡＰはトリガーフレームを用いる。従来の８０２．１１ａｘ規格では、トリガーフレームはＡＰからそのＡＰに接続するＳＴＡにＴＸＯＰの一部無線リソースを割り当てるものである。そのため、本実施形態では、共有元ＡＰが共有先ＡＰにＴＸＯＰの一部無線リソースを割り当てる場合には、別のＴｒｉｇｇｅｒＴｙｐｅサブフィールドが定義される。あるいはトリガーフレームとは異なる新たな制御フレームが定義されてもよい。あるいは、既存のＴｒｉｇｇｅｒＴｙｐｅサブフィールドであり、一般的にＵＬＭＵ送信を指示するために用いるＢａｓｉｃｖａｒｉａｎｔ（これをベーシックトリガー（ＢａｓｉｃＴｒｉｇｇｅｒ）フレームと言う）の現状未使用の（ｒｅｓｅｒｖｅｄ）フィールド、あるいは後方互換性を維持しつつ一部フィールドを再定義することで、ＡＰが他のＡＰにＴＸＯＰの一部無線リソースを割り当てる本実施形態に利用できるようにしてもよい。なお、ベーシックトリガーフレームを改造して再利用する場合、あるいは新規のＴｒｉｇｇｅｒＴｙｐｅサブフィールドを定義する場合、ＵｓｅｒＩｎｆｏフィールドは既存の場合と同様にすることが考えられる。その場合、例えばＥＳＳ内での各ＡＰを識別するためにＡＰ各々に識別子を割当て、そのＡＰの識別子をＡＩＤ１２サブフィールドに入れることが考えられる。この場合、通常のＳＴＡが用いるＡＩＤは１～２００７であり、また既存のトリガーフレームでＡＩＤ１２サブフィールドとして前述のように特別な意味を与えられた値が定義されているため、それらを避けてＡＰの識別子を割当てるようにすればよい。例えばＥＳＳを形成するときに、ＥＳＳを形成開始した最初のＡＰが他のＡＰに識別子を割当てるようにしてもよいし、ユーザインターフェースを経由して手動により各ＡＰの識別子を指定するようにしてもよい。新たな制御フレームを定義する場合も、上述のようにＡＩＤ１２サブフィールドのようなものをＵｓｅｒＩｎｆｏフィールドに設け、共有元ＡＰがＴＸＯＰの一部無線リソースを割り当てる先の共有先ＡＰを、ＡＰの識別子で通知するようにしてもよいし、共有先ＡＰのＭＡＣアドレスをそのまま通知するようにしてもよい。前者の方がＡＰを指定するフィールドは短くすることができる一方、ＡＰどうしを識別するための識別子を割当てる方法が必要である。

共有元ＡＰからＴＸＯＰの一部無線リソースを割り当てられた共有先ＡＰでは、各々に割り当てられた無線リソースの中であたかもＡＰ自身が送信権を獲得したときのように利用する。例えば図６において、ＡＰ２はＴＸＯＰ１２の間に、ＡＰ２に接続するＳＴＡ２１やＳＴＡ２２にデータフレームを送信し、それに対するＡｃｋフレームやＢｌｏｃｋＡｃｋフレームなどの応答フレームを受信することや、あるいはＳＴＡ２１とＳＴＡ２１にトリガーフレームを送信して各々からデータフレームを送信させ、それに対する応答フレームを送信することなどが可能である。当然、ＴＸＯＰ１２内に収まるのであれば、これらの連続したフレーム交換を行ってもよい。

＜ＭＡＰ対応能力の通知＞
ＭＡＰを実施するに当たって、共有元ＡＰでは、共有先候補となるＡＰが後述のようにＮＡＶに関連した特別な操作ができるＡＰである、と予め把握しておく必要がある。また共有先となったＡＰでは、ＭＡＰ動作下で自ＢＳＳのＳＴＡに無線リソースを再割り当てする際に、その対象候補となるＳＴＡが後述のようにＮＡＶに関連した特別な操作ができるＳＴＡである、と予め把握しておく必要がある。すなわち、後述のようなＮＡＶに関連した特別な操作などＭＡＰ対応に不可欠となる能力（ｃａｐａｂｉｌｉｔｙ）の対応可否の通知が必要である。

例えば、ＭＡＰ動作が可能であるかという能力に関連する通知を各ＡＰが送信するビーコンフレーム、また他ＡＰ向け送信用のアクションフレームに入れて送信すれば、ＥＳＳを構成する複数のＡＰにおいてそれらのフレームを受信することで互いにＭＡＰ動作の対応可否を把握することができる。

アクションフレームも管理フレームの一種である。アクションフレームのＳｕｂｔｙｐｅフィールドはアクションフレームと示される。アクションフレームのＦｒａｍｅＢｏｄｙフィールドの先頭に配置されるＡｃｔｉｏｎフィールドの中のＣａｔｅｇｏｒｙサブフィールドはアクションフレームの大まかなカテゴリーを示す。さらにＣａｔｅｇｏｒｙサブフィールドに続くＡｃｔｉｏｎＤｅｔａｉｌｓサブフィールドはＣａｔｅｇｏｒｙサブフィールドに応じたより細かいアクションフレームの種別を表すサブフィールドを格納する。

ビーコンフレームやアクションフレームのＦｒａｍｅＢｏｄｙフィールドに入れる例えば情報エレメントの１つを使って、ＭＡＰ動作が可能であることを通知する。ＭＡＰ動作が可能であることを通知する情報エレメントには、ＭＡＰ動作以外の能力に係る通知も入れてもよい。例えば８０２．１１ｂｅ規格関連の能力を通知するフィールドとしてＥＨＴＣａｐａｂｉｌｉｔｉｅｓエレメントがあり、ここに入れるようにしてもよい。あるいは、新しくＭＡＰ動作関連の情報（とその他の情報）を通知する情報エレメントを定義してもよい。この場合、この情報エレメントとして新たな識別子（ＥｌｅｍｅｎｔＩＤ、ＥｌｅｍｅｎｔＩＤＥｘｔｅｎｓｉｏｎ）を定義することになる。

図１０は、ＭＡＣフレームのＦｒａｍｅＢｏｄｙに含まれる情報エレメントのフォーマットの一例を示す。情報エレメントは、ＥｌｅｍｅｎｔＩＤフィールド（１オクテット）、Ｌｅｎｇｔｈフィールド（１オクテット）、ＥｌｅｍｅｎｔＩＤＥｘｔｅｎｓｉｏｎフィールド（０又は１オクテット）、Ｉｎｆｏｒｍａｔｉｏｎフィールド（オクテット単位の可変長）を含む。

ＥｌｅｍｅｎｔＩＤＥｘｔｅｎｓｉｏｎフィールドは、情報エレメントを識別するためのＥｌｅｍｅｎｔＩＤの番号が１オクテットで表現できる数の上限に達した場合、用いられる。ＥｌｅｍｅｎｔＩＤが最大の“２５５”という値を取った場合のみ、ＥｌｅｍｅｎｔＩＤＥｘｔｅｎｓｉｏｎフィールドが追加され、情報エレメントを識別するためのＳｕｂｅｌｅｍｅｎｔＩＤが追加できるようになっている。

ＥｌｅｍｅｎｔＩＤＥｘｔｅｎｓｉｏｎフィールドも１オクテットあり、現行の８０２．１１規格に準拠する無線ＬＡＮ規格ではそのフィールドが“０”の値はＲｅｓｅｒｖｅｄになっており、“１”以上の値がＥｌｅｍｅｎｔＩＤと同様に情報エレメントを識別するために割り当てられている。ここに、情報エレメントを識別するための固有の値が記載される。

Ｌｅｎｇｔｈフィールドは、ＥｌｅｍｅｎｔＩＤフィールドとＬｅｎｇｔｈフィールドを除いた情報エレメントの長さ（サイズ）を示す。Ｉｎｆｏｒｍａｔｉｏｎフィールドは情報の内容を示す。

ＭＡＰの動作可能なＡＰに接続しているＳＴＡが、共有元ＡＰから自ＡＰ（当該ＳＴＡが接続しているＡＰ）に割り当てられたＴＸＯＰの一部無線リソースが自ＡＰからさらに再割り当てされた場合に、ＳＴＡは、条件によってはＮＡＶに関連した特別な操作を行い、データフレームなどの送信が可能であること、すなわち他ＡＰから分けられたＴＸＯＰ内で自ＡＰの指示による送信が可能なこと、を自ＡＰに送信する。このようにＳＴＡが自ＡＰに通知する場合も、アソシエーション要求フレームや再アソシエーション要求フレームにＭＡＰ動作が可能であることを通知する情報エレメントを入れればよい。またそのようなＳＴＡは接続候補のＡＰがビーコンフレームやプローブ応答に同様の情報エレメントを入れてあることで、当該ＡＰがＭＡＰの動作が可能であるか否かを予め把握できる。そこで、ＳＴＡは、アソシエーション要求フレームや再アソシエーション要求フレームを送信する先のＡＰがＭＡＰの動作が可能であることを確認した場合に、アソシエーション要求フレームや再アソシエーション要求フレームに先の情報エレメントを入れて、対応可能であることを自ＡＰに通知するようにしてもよい。ＡＰはアソシエーション要求フレームや再アソシエーション要求フレームで他ＡＰから分け与えられたＴＸＯＰ内で自ＡＰの指示による送信が可能なことの通知をＳＴＡから受けた場合に、再度アソシエーション要求フレームや再アソシエーション応答フレームにＭＡＰ動作が可能であることを通知する情報エレメントを入れてもよい。

＜ＭＡＰＣａｎｄｉｄａｔｅＳｅｔ＞
上述のように同一ＥＳＳ内でもＭＡＰ動作が可能なＡＰが一部に限られるなどして、実際にＭＡＰ動作を連携して行うＡＰが限られている場合には、ＭＡＰ動作を行う各ＡＰはＭＡＰ動作を連携する候補となる他のＡＰを把握しておくことが必要である。このようなＭＡＰ動作を連携する候補となるＡＰ群をＭＡＰ候補セット（ＭＡＰｃａｎｄｉｄａｔｅｓｅｔ）と呼ぶことにする。後述のＮＡＶ操作に関する記述部分で、同一ＥＳＳ内のＡＰなどと記載している部分は、同一ＥＳＳ内でもＭＡＰ動作が可能なＡＰが一部に限られる場合は、ＭＡＰ候補セットのＡＰと読み替える。

＜ＡＰが他ＡＰからＴＸＯＰの一部無線リソースを割り当てられた場合にそれを使うことができるようにする動作例＞
前述のように、８０２．１１ａｘ規格ではＡＰはｉｎｔｒａ－ＢＳＳＮＡＶを持つことはオプションであり、従来の１つのＮＡＶだけを持っていてもよい。

以下、ＡＰが他ＡＰからＴＸＯＰの一部無線リソースを割り当てられた場合にそれを使うことができるようにするＭＡＰ動作の例を説明する。ＭＡＰ動作例は、ＡＰに実装される例と、ＳＴＡに実装される例に分類される。先ず、ＡＰに実装されるＭＡＰ動作例を説明する。

＜ＡＰ動作例１：ＮＡＶ１つのみ＞
まず受信処理部９０により１つのＮＡＶだけが設定されている場合に、送信処理部８０がＮＡＶに関わらず他ＡＰから割り当てられたＴＸＯＰの一部無線リソースを使うことができるようにする動作例について記載する。

この場合、ＡＰの受信処理部９０が自ＡＰ宛てに他ＡＰからＴＸＯＰの無線リソースの一部を共有するフレームを受信したら、送信処理部８０は割り当てられた無線リソース内ではＮＡＶを無視して送信する。図１１はＡＰ動作例１の一例を説明するための図である。図１１では、ＡＰ１が共有元ＡＰであり、ＡＰ１が獲得したＴＸＯＰの一部無線リソースを共有先ＡＰ２に割り当てている。このＡＰ２にＴＸＯＰの一部無線リソースを割り当てるフレームが図中ではＭＡＰＴｒａｎｓｍｉｓｓｉｏｎＳｈａｒｉｎｇＴｒｉｇｇｅｒフレーム（ＭＡＰＴＸＳＴＦ）である。ここでは他ＡＰにＴＸＯＰの一部無線リソースを割り当てるフレームをトリガーフレームの一種としている。ＡＰ２に対してのみ割り当てる場合には、ＭＡＰＴＸＳＴＦのＲＡはＡＰ２のＭＡＣアドレスに設定している。

例えば、ＡＰ２はＭＡＰＴＸＳＴＦのＲＡが自ＡＰのＭＡＣアドレスを指定している場合、ＭＡＰＴＸＳＴＦを受信復号すると、Ｔｙｐｅフィールド、ＳｕｂｔｙｐｅフィールドからＭＡＰＴＸＳＴＦはフレーム種別としては制御フレームであるトリガーフレームであることが分かり、ＴｒｉｇｇｅｒＴｙｐｅサブフィールドからＭＡＰＴＸＳＴＦはＭＡＰであるＡＰが他ＡＰにＴＸＯＰの一部無線リソースを割り当てる際に用いるものであることが分かる。従って、ＡＰ２は、自ＡＰ宛てに他ＡＰからＴＸＯＰの無線リソースの一部を共有するフレームを受信したという条件を満たしたことになる。従って、仮にＡＰ１が、例えばＡＰ１が構成するＢＳＳ１内のＳＴＡ宛てフレームを送信する、あるいはＡＰ１宛てのＣＴＳフレームを送信する場合、それをＡＰ２が受信すると、ＮＡＶが設定された状態であっても、ＡＰ２（送信処理部８０）はＮＡＶを無視して、ＭＡＰＴＸＳＴＦに従い、ＴＸＯＰを使うことができ、ＡＰ２自身が構成するＢＳＳ内のＳＴＡ宛てに割り当てられた無線リソースを再割り当てするためなどの送信を行うことができる。自ＳＴＡ（ＡＰを含む）宛てのＣＴＳフレームを特にＣＴＳ－ｔｏ－ｓｅｌｆフレームと言う。自ＳＴＡ宛てとは、ＲＡを自ＳＴＡのＭＡＣアドレスに設定していることを言う。

図１１は、ＭＡＰＴＸＳＴＦを受信したＡＰ２は、割り当てられた一部無線リソースを使うということを通知するための応答フレーム（図１１ではＴｒａｎｓｍｉｓｓｉｏｎＳｈａｒｉｎｇＲｅｓｐｏｎｓｅフレーム（ＴＸＳＲＳＰ）がこれに相当する）をＡＰ１に送信した後に、ＡＰ２に接続するＳＴＡ２１とＳＴＡ２２にＵＬＭＵの送信指示をするトリガーフレーム（図１１ではＴｒｉｇｇｅｒフレーム（ＴＦ）がこれに相当する）を送信する例を示している。例えば、ＡＰ２は、ＭＡＰＴＸＳＴＦのＳＩＦＳ後にＴＸＳＲＳＰを送信し、ＴＸＳＲＳＰのＳＩＦＳ後にＴＦを送信するようにする。例えばＡＰ２がＳＩＦＳでＴＸＳＲＳＰの送信準備が難しい場合には、ＡＰ２は、予めＡＰ１との間でＡＰ２が必要な調整時間をネゴシエーションしておき、ＡＰ１が送信するＭＡＰＴＸＳＴＦを物理フレームに入れて送信する際にその調整時間に合わせてＭＡＰＴＸＳＴＦ後にパディング処理を行い、実質の物理パケット間の時間はＳＩＦＳにしつつＡＰ２が送信準備のための処理時間を稼げるようにする。

ＡＰ２がＡＰ１にＴＸＳＲＳＰを送信するためには、ＭＡＰＴＸＳＴＦのＭＡＣヘッダにＲＡに加えてＳＡがあり、ＳＡにＡＰ１のＭＡＣアドレスが設定されている必要がある。ＡＰ２はＭＡＰＴＸＳＴＦのＳＡに設定されているＡＰ１のＭＡＣアドレスをコピーしてＴＸＳＲＳＰのＲＡに設定する。ＴＸＳＲＳＰにはＡＰ１側でどのＡＰが応答しているかを識別するために、ＳＡを入れることが望ましく、ＡＰ２はＡＰ１にＴＸＳＲＳＰを送信する際にＳＡにＡＰ２自身のＭＡＣアドレスを設定する。

ここで、ＡＰ２は、受信したフレームのＲＡに自ＡＰのＭＡＣアドレスが設定されており、当該フレームがＭＡＰＴＸＳＴＦであると判断すると、ＮＡＶを無視してフレームの送信を行う。これ以外に、送信する条件として、同一ＥＳＳのＡＰが送信元ＡＰである場合にさらに限定してもよい。これを判断するためには、前述のようにＭＡＰＴＸＳＴＦのＴＡを用いればよい。ＡＰ１はＡＰ２が予め同一ＥＳＳを構成するＡＰの一つであることを把握していることによって、ＡＰ２はＴＡにＡＰ２のＭＡＣアドレスが記載されたＭＡＰＴＸＳＴＦを受信した際に、同一ＥＳＳのＡＰ１がそのフレームを送信したものと判断できる。同一ＥＳＳのＡＰにＴＸＯＰの一部無線リソースを割り当てられた場合にだけその無線リソースを使うことになるのであるから、さらにＴＸＳＲＳＰフレームを送信するかどうかもＭＡＰＴＸＳＲＦが同一ＥＳＳを構成するＡＰの一つから送信されていることを条件にすることが適当である。これは、仮にＡＰ２がＭＡＰＴＸＳＴＦを受信する前にＮＡＶが設定されていない場合には、ＭＡＰＴＸＳＴＦが自ＡＰ宛てであればＮＡＶを設定しないため、ＡＰ２はＴＸＳＴＦフレームは送信できることになるためである。但し、この場合でもＡＰ２はＳＴＡ２１、ＳＴＡ２２に対してＴＦフレームを送信することはできない。これは自ＳＴＡ（ＡＰ含む）宛てフレームを受信した場合にはＮＡＶは設定しないが、その代わりに類似の概念であるタイマーを有し、ＴＸＯＰを開始した（ＴＸＯＰｈｏｌｄｅｒである）ＡＰ１のＴＸＯＰ中であることを把握し、そのＴＸＯＰ中には送信権の取得を試みるべきではないためである。

ＡＰ１が複数のＡＰ、例えばＡＰ２とＡＰ３、にＴＸＯＰの一部リソースを割り当てているときには、ＭＡＰＴＸＳＴＦのＲＡにはブロードキャストアドレスが設定される。そこで、ＡＰ２が当該ＭＡＰＴＸＳＴＦが自ＡＰにＴＸＯＰの一部無線リソースを割り当てているものであるという把握は、例えばＭＡＰＴＸＳＴＦが従来のトリガーフレームと同様にＵｓｅｒＩｎｆｏフィールドのいずれかでＡＩＤ１２サブフィールドに自ＡＰに割り当てられた識別子があることで行う。

受信したフレームが同一ＥＳＳのＡＰからのフレームであるということを容易にＡＰが把握するために、ＭＡＰＴＸＳＴＦに前述のようにＥＳＳの識別子であるＳＳＩＤを入れるようにしてもよい。なお、ＳＳＩＤは一部の管理フレームに入れられるが、その場合には情報エレメントの形式で表現されている。これは、ＳＳＩＤがオクテット単位で最大３２オクテットまでの可変長だからである。トリガーフレームは制御フレームであり、通常は情報エレメントを入れない。これは制御フレームでは受信した際の処理負荷を軽減するためである。制御フレームではフィールド長が変わる可能性のあるフィールドを格納する場合に、情報エレメントのように長さ情報を入れて該当するフィールドを切り出すのではなく、細かい種別やそのフィールドが終了する特殊な値などを入れることによって、フィールドを把握できるようにしている。そこで、同様にＭＡＰＴＸＳＴＦにＳＳＩＤを入れる際には、例えばフレームボディ部の最後（ＦＣＳフィールドの前）に入れるようにする。当然、長さ情報とＳＳＩＤ値を入れる構成が許容されるようになるなら、それでもよい。あるいは、ＭＡＣアドレスと同様に６オクテットの値をＥＳＳの識別子として、ＳＳＩＤとは別に定義し（これを例えばＥＳＳＩＤとする）、用いるようにしてもよい。ＥＳＳＩＤを用いる場合には、予め同一ＥＳＳ内で周知しておく必要がある。

あるいは同一ＥＳＳのＡＰからであるということを容易にＡＰが把握するために、ＢＳＳＣｏｌｏｒフィールドのように同一ＥＳＳであることを識別するためのＳＳＩＤとは異なる識別子、ＥＳＳｃｏｌｏｒ、を新たに設けるようにしてもよい。この場合、同一ＥＳＳであることを識別するための識別子を例えばＢＳＳＣｏｌｏｒフィールドに入れる概念を基本的には踏襲し、通常は自ＢＳＳであるかを識別するのに用いるが、ある値については同一ＥＳＳであることを通知するものとして使うようにする。ＥＳＳｃｏｌｏｒ値は同一ＥＳＳ内のＡＰ間で何らかの方法によって決定し、同一ＥＳＳ内のＡＰ間で共有する。例えば、ＥＳＳの構成を開始した１台のＡＰなど、あるＡＰがＥＳＳｃｏｌｏｒ値を決めるようにしてもよいし、ユーザが決定の上、コントローラなどを介して各ＡＰに入力するようにしてもよい。また従来のＢＳＳｃｏｌｏｒのように途中で値を変更できるようにしてもよい。

なお、ＡＰ動作例１ではＡＰ２がＴＸＯＰの一部無線リソースを割り当てられる際に、すでにＡＰ２に接続するＳＴＡの１つが送信権を獲得し、ｉｎｔｒａ－ＢＳＳの通信が存在している場合で、ＡＰ１がそれを検知していない場合がある。この場合、ＡＰ２がＮＡＶを無視して送信してしまうため、ＡＰ２の通信とｉｎｔｒａ－ＢＳＳの通信と衝突してしまう恐れがある。また、ＡＰ２では検知している他のＢＳＳ（同一ＥＳＳに限らない）内の通信があるが、それをＡＰ１では検出していない場合に、やはりＡＰ２はＮＡＶを無視して送信してしまうため、他のＢＳＳでの通信と衝突してしまう恐れがある。この衝突の恐れを解消するＡＰ動作例２を次に説明する。

＜ＡＰ動作例２：８０２．１１ａｘ規格のＮＡＶ２つ（ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ）＞
ＡＰ動作例２では、２つのＮＡＶ、ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶ、をＡＰ２が持つ。ＡＰ動作例２がＡＰ動作例１と異なる点は、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されている場合にはＡＰが自ＡＰ宛てに他ＡＰからＴＸＯＰの無線リソースの一部を共有するフレームを受信しても、割り当てられた無線リソース内でｉｎｔｒａ－ＢＳＳＮＡＶを無視して送信することはできない点である。一方でｂａｓｉｃＮＡＶのみが設定されている場合には、ＡＰ動作例１と同様にｂａｓｉｃＮＡＶを無視して他ＡＰからの割当てフレームに従ってフレームを送信できる。

図１２の（ａ）はｂａｓｉｃＮＡＶのみが設定されている場合のＡＰ動作例２の一例を説明するための図である。ｂａｓｉｃＮＡＶが設定されていても、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されていなければ、ＡＰ２はｂａｓｉｃＮＡＶを無視し、ＡＰ１からＭＡＰ動作用の割当てフレームであるＭＡＰＴＸＳＴＦを受信し、それに対してＴＸＳＲＳＰを送信し、その後にＡＰ２に接続するＳＴＡ２１とＳＴＡ２２にＴＦを送信する。図１２の（ｂ）はｉｎｔｒａ－ＮＡＶが設定されている場合のＡＰ動作例２の一例を説明するための図である。ＡＰ２は、ｉｎｔｒａ－ＮＡＶを尊重し、ＭＡＰＴＸＳＴＦに対するＴＸＳＲＳＰを送信せず、またＳＴＡ２１とＳＴＡ２２へのＴＦも送信しない。仮にｉｎｔｒａ－ＮＡＶがＭＡＰＴＸＳＴＦの途中で終わり、ＴＸＳＲＳＰをＭＡＰＴＸＳＴＦの固定時間後（通常のＴＦの送信と同様に例えばＳＩＦＳ後）に送信するかどうかの判断を行う段階でｉｎｔｒａ－ＮＡＶが設定されていない状態であれば、仮にｂａｓｉｃＮＡＶが設定されている状態であったとしても図１２の（ａ）と同様になるため、ＡＰ２は送信してよい。

図１３は、ＡＰ動作例２において、２つのＮＡＶの設定状態と他ＡＰからＴＸＯＰの一部無線リソースが割り当てられた場合にその一部無線リソースを使うことができるか（図中での項目は“ＭＡＰ送信”と表現してある）の関係を示す。

（１）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１２の（ｂ）に対応する。

（２）ｂａｓｉｃＮＡＶが０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。この場合は、図１２の（ａ）に対応する。

（３）ｂａｓｉｃＮＡＶが０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１２の（ｂ）に対応する。

（４）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。

このようにすることで、連携する他のアクセスポイントから無線リソースを分け与えられた場合に、送信が可能になる。

ＡＰ動作例２で、ＡＰ動作例１と同様に、ＡＰは同一ＥＳＳのＡＰが送信元の場合に限りＭＡＰ送信可能というように送信条件を限定してもよい。また、ＭＡＰＴＸＳＴＦのＲＡがブロードキャストアドレスの場合に自ＡＰが割り当てられているかを把握する方法もＡＰ動作例１と同様である。ＡＰ動作例１での同一ＥＳＳのＡＰからであることを受信ＡＰが容易に把握するための手法もＡＰ動作例２に適用できる。

ＡＰ動作例２ではｉｎｔｒａ－ＢＳＳの通信が行われている状況で、ＡＰ１がそれを検知していない場合に、ＡＰ２が送信を行ってｉｎｔｒａ－ＢＳＳの通信と衝突してしまうというＡＰ動作例１での状況は回避できる。一方で、ＡＰ動作例２では、ＡＰ２では検知している他のＢＳＳ内の通信があるが、それをＡＰ１では検知していないために、ＡＰ１がＭＡＰＴＸＳＴＦを送信する場合に、ＡＰ２がｂａｓｉｃＮＡＶを無視して送信できてしまうため、他のＢＳＳでの通信と衝突してしまうことは起こり得る。この衝突の恐れを解消するＡＰ動作例３を次に説明する。

＜ＡＰ動作例３：ＮＡＶ２つ（新たなＭＡＰ用ＥＳＳＮＡＶ（ＢＳＳ内でのｎｏｎ－ＡＰＳＴＡのｉｎｔｒａ－ＢＳＳＮＡＶに置き換わるもの）、ｂａｓｉｃＮＡＶ）＞
ＡＰ動作例３は、同一ＥＳＳ内（自ＢＳＳを含む）のフレームを受信した時に設定されるＭＡＰ用のＮＡＶ（ＥＳＳＮＡＶと称する）と、それ以外の条件（同一のＥＳＳではないフレームまたはパケットを受信した時）に設定されるＮＡＶ（ｂａｓｉｃ－ＮＡＶと称する）の２つのＮＡＶを設けるものである。８０２．１１ａｘ規格では、ＳＴＡがｉｎｔｒａ－ＢＳＳＮＡＶとｂａｓｉｃＮＡＶを設定する。ＡＰ動作例３では、ｉｎｔｒａ－ＢＳＳＮＡＶは設定されず、ＥＳＳＮＡＶは、自ＢＳＳ内のフレームを受信した時も同一ＥＳＳ内の他のＡＰ／ＳＴＡからのフレームを受信した時も区別されずに設定される。ＥＳＳＮＡＶは８０２．１１ａｘ規格で設定された２つのＮＡＶがある場合の中のｉｎｔｒａ－ＢＳＳＮＡＶを拡張したものである。ＥＳＳＮＡＶはｉｎｔｒａ－ＢＳＳＮＡＶを包含するものとなる。

ＡＰは、受信したＭＡＣフレームのＲＡ、ＴＡ、あるいはＢＳＳＩＤフィールド値として自ＢＳＳのＢＳＳＩＤ（すなわち自ＢＳＳのＡＰのＭＡＣアドレス）を含む場合（自ＢＳＳのフレームの場合）あるいは同一ＥＳＳ内のＡＰのＭＡＣアドレスを含む場合には、同一ＥＳＳのフレームを受信したと判断してＥＳＳＮＡＶを設定する。また、ＡＰは、受信したフレームが同一ＢＳＳ内の通信として認識したＴＸＯＰのＴＸＯＰｈｏｌｄｅｒへの応答フレームであると判断できる場合も、ＥＳＳＮＡＶを設定する。

この場合の判断方法は８０２．１１ａｘ規格ＮＡＶにおけるｉｎｔｒａ－ＢＳＳＮＡＶでの判断方法と同様である。また、ＥＳＳｃｏｌｏｒ（ＡＰ動作例１で考察）を物理パケットのヘッダに入れる、あるいは既存のＢＳＳＣｏｌｏｒフィールドで、予めＥＳＳ内の各ＢＳＳのＢＳＳｃｏｌｏｒをＢＳＳ間で相互周知するなどして、ＡＰがＢＳＳｃｏｌｏｒを把握できるようにして、ＡＰが受信したフレームまたは物理パケットが同一ＥＳＳ内の通信によるフレームまたは物理パケットであると判断するようにすればよい。ＥＳＳｃｏｌｏｒを物理パケットのヘッダに入れる手法としては、例えば特定の値を同一ＥＳＳであることを識別するために設け、ＢＳＳＣｏｌｏｒフィールド値に入れること、あるいはＥＳＳＣｏｌｏｒフィールドを新たに設けることがある。ＰａｒｔｉａｌＡＩＤフィールドを用いる場合も同様に判断できる。

ＡＰは、ＥＳＳＮＡＶの設定条件にはならない場合（同一ＥＳＳかどうかを判別できない場合も含む）には、ｂａｓｉｃＮＡＶを設定する。従って、ここでのｂａｓｉｃＮＡＶの設定条件は従来の２つのＮＡＶでのｂａｓｉｃＮＡＶの設定条件とは若干変わる。ＡＰ動作例２ではＡＰはｉｎｔｒａ－ＢＳＳＮＡＶを尊重していたのに対し、ＡＰ動作例３ではＡＰはＥＳＳＮＡＶと対の概念であるところのｂａｓｉｃＮＡＶを尊重する。これは、従来の２つのＮＡＶを持つ場合に、ＳＴＡがＡＰからのトリガーフレームに応答する際にｂａｓｉｃＮＡＶを尊重するのと類似の動作である。ＡＰ動作例３では、ｂａｓｉｃＮＡＶが設定されている場合には、ＡＰは自ＡＰ宛てに他ＡＰからＴＸＯＰの無線リソースの一部を共有するフレームを受信しても、割り当てられた無線リソース内でｂａｓｉｃＮＡＶを無視して送信することはできない。一方でＥＳＳＮＡＶのみが設定されている場合には、ＡＰはＥＳＳＮＡＶを無視して他ＡＰからの割当てフレームに従って送信できる。

図１４の（ａ）はＥＳＳＮＡＶのみが設定されている場合のＡＰ動作例３を説明するための図である。ＡＰ２はＥＳＳＮＡＶを無視し、ＡＰ１からのＭＡＰＴＸＳＴＦに対し、ＴＸＳＲＳＰを送信し、その後にＡＰ２に接続するＳＴＡ２１とＳＴＡ２２にＴＦを送信する。図１４の（ｂ）はｂａｓｉｃＮＡＶが設定されている場合のＡＰ動作例３を説明するための図である。ＡＰ２はｂａｓｉｃＮＡＶを尊重し、ＭＡＰＴＸＳＴＦに対してＴＸＳＲＳＰを送信せず、またＳＴＡ２１とＳＴＡ２２へＴＦも送信しない。仮にｂａｓｉｃＮＡＶがＭＡＰＴＸＳＴＦの途中で終わり、ＴＸＳＲＳＰをＭＡＰＴＸＳＴＦの固定時間後に送信するかどうかを判断する段階でｂａｓｉｃＮＡＶが設定されていない状態であれば、仮にＥＳＳＮＡＶが設定されている状態であったとしても図１４の（ａ）と同様になるため、ＡＰ２は送信してよい。

図１５は、２つのＮＡＶの設定状態と他ＡＰからＴＸＯＰの一部無線リソースが割り当てられた場合に、その一部無線リソースを使うことができるか（図中での項目は“ＭＡＰ送信”と表現してある）の関係を示す。

（１）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１４の（ｂ）に対応する。

（２）ｂａｓｉｃＮＡＶが０ではなく（すなわち、設定されている）、ＥＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１４の（ｂ）に対応する。

（３）ｂａｓｉｃＮＡＶが０であり（すなわち、設定されていない）、ＥＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。この場合は、図１４の（ａ）に対応する。

（４）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。

ＡＰ動作例３では、ＡＰ動作例１と同様に、同一ＥＳＳのＡＰが送信元の場合に限りＭＡＰ送信可能というようにＭＡＰ送信できる条件を限定してもよい。またＭＡＰＴＸＳＴＦのＲＡがブロードキャストアドレスの場合に自ＡＰが割り当てられているかを把握する手法もＡＰ動作例１と同様である。ＡＰ動作例１での受信フレームまたは物理パケットが同一ＥＳＳのＡＰから送信されたものであることを受信ＡＰが容易に把握するための手法もＡＰ動作例３に適用できる。

ＡＰ動作例３ではＡＰ１がＡＰ２のＢＳＳ内で通信が行われている状況を検知していない場合に、ＡＰ２ではそれを検知すると、ＥＳＳＮＡＶが設定されていても送信してしまうために、この送信がｉｎｔｒａ－ＢＳＳ通信と衝突してしまうことは起こり得る。一方で、ＡＰ２では検知しているＥＳＳ外の他のＢＳＳ内の通信があり、それをＡＰ１では検知していない状況で、ＡＰ２が送信して、この送信がＥＳＳ外の他のＢＳＳ内の通信と衝突してしまう状況は回避できる。この衝突の恐れを解消するＡＰ動作例４を次に説明する。

＜ＡＰ動作例４：ＮＡＶ３つ（ｉｎｔｒａ－ＢＳＳＮＡＶ、ＥＳＳＮＡＶ、ｂａｓｉｃＮＡＶ）＞
動作例ＡＰ４はＡＰ動作例３と類似しているが、異なる点は、ＡＰ動作例３ではＥＳＳＮＡＶを設定する条件に自ＢＳＳのフレームを受信した場合も含めていたのを、ＡＰ動作例４ではＡＰはＥＳＳＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶとを区別して設定し、その上でｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶを尊重することである。ｉｎｔｒａ－ＢＳＳＮＡＶを設定するかどうかは、従来の２つのＮＡＶの場合にｉｎｔｒａ－ＢＳＳＮＡＶを設定する条件と同じである。すなわち、ＡＰは、受信パケットを復調してＭＡＣフレームを得た場合、ＭＡＣヘッダに自ＢＳＳと同じＢＳＳＩＤが含まれていると判断すると、ＭＡＣヘッダからＮＡＶ値を取り出し、その値からＮＡＶを設定する。ＡＰは、受信パケットを復調できない場合は、物理パケットのヘッダのＢＳＳｃｏｌｏｒ値に基づいて自ＢＳＳのパケットを受信したと判断すると、物理パケットのヘッダからＴＸＯＰを取り出し、ＴＸＯＰに応じてＮＡＶを設定する。ＡＰは、自ＢＳＳ内の通信ではないが同一ＥＳＳ内の通信であると判断できる場合に、ＥＳＳＮＡＶを設定する。ＥＳＳＮＡＶを設定する条件は、ＡＰ動作例３の場合のＥＳＳＮＡＶを設定する条件において、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する条件を除外すればよい。ｉｎｔｒａ－ＢＳＳＮＡＶの設定条件もＥＳＳＮＡＶの設定条件も当てはまらない場合に、ＡＰはｂａｓｉｃＮＡＶを設定する。ＡＰ動作例４では、ｂａｓｉｃＮＡＶあるいはｉｎｔｒａ－ＢＳＳＮＡＶのいずれかが設定されている場合には、ＡＰは自ＡＰ宛てに他ＡＰからＴＸＯＰの無線リソースの一部を共有するフレームを受信しても送信しない。一方で、ＥＳＳＮＡＶのみが設定されている場合には、ＡＰはＥＳＳＮＡＶを無視して他ＡＰからの割当てフレームに従って送信できる。

図１６の（ａ）はＥＳＳＮＡＶのみが設定されている場合のＡＰ動作例４を説明するための図である。ｂａｓｉｃＮＡＶもｉｎｔｒａ－ＢＳＳＮＡＶも設定されていない場合は、ＥＳＳＮＡＶが設定されていても、ＡＰ２は、ＥＳＳＮＡＶを無視して、ＡＰ１からのＭＡＰＴＸＳＴＦに対し、ＴＸＳＲＳＰを送信し、その後にＡＰ２に接続するＳＴＡ２１とＳＴＡ２２にＴＦを送信する。図１６の（ｂ）はｂａｓｉｃＮＡＶあるいはｉｎｔｒａ－ＢＳＳＮＡＶの少なくともいずれかが設定されている場合のＡＰ動作例４を説明するための図である。ＡＰ２は、ｂａｓｉｃＮＡＶあるいはｉｎｔｒａ－ＢＳＳＮＡＶの少なくともいずれかのＮＡＶを尊重し、ＭＡＰＴＸＳＴＦに対してＴＸＳＲＳＰを送信せず、またＳＴＡ２１とＳＴＡ２２へのＴＦも送信しない。仮にｂａｓｉｃＮＡＶが設定されていたが、ＭＡＰＴＸＳＴＦの途中で終わり、ＴＸＳＲＳＰをＭＡＰＴＸＳＴＦの固定時間後に送信するかどうかを判断する段階でｂａｓｉｃＮＡＶが設定されておらず、ＥＳＳＮＡＶのみが設定されている場合は、図１６の（ａ）と同様になるため、ＡＰは送信してよい。また仮にｉｎｔｒａ－ＢＳＳＮＡＶが設定されていたが、ＭＡＰＴＸＳＴＦの途中で終わり、ＴＸＳＲＳＰをＭＡＰＴＸＳＴＦの固定時間後に送信するかどうかを判断する段階でｉｎｔｒａ－ＢＳＳＮＡＶが設定されていないで、ＥＳＳＮＡＶのみが設定されている場合は、図１６の（ａ）と同様になるため、ＡＰは送信してよい。

図１７は、３つのＮＡＶの設定状態と他ＡＰからＴＸＯＰの一部無線リソースが割り当てられた場合にその一部無線リソースを使うことができるか（図中での項目は“ＭＡＰ送信”と表現してある）の関係を示す。

（１）ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、及びＥＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（２）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０ではなく（すなわち、設定されている）、ＥＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（３）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（４）ｂａｓｉｃＮＡＶが０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶとＥＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（５）ｂａｓｉｃＮＡＶが０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶとＥＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（６）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は不可（すなわち、割り当てられた無線リソースを使用できない）である。この場合は、図１６の（ｂ）に対応する。

（７）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０であり（すなわち、設定されていない）、ＥＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。この場合は、図１６の（ａ）に対応する。

（８）ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、及びＥＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は可であり、ＭＡＰ送信は可（すなわち、割り当てられた無線リソースを使用できる）である。

ＡＰ動作例４で、ＡＰ動作例１と同様に、同一ＥＳＳのＡＰが送信元の場合に限りＭＡＰ送信可能というようにＭＡＰ送信できる条件を限定してもよい。またＭＡＰＴＸＳＴＦのＲＡがブロードキャストアドレスの場合に自ＡＰが割り当てられているかを把握する手法もＡＰ動作例１と同様である。ＡＰ動作例１での同一ＥＳＳのＡＰからであることを受信ＡＰが容易に把握するための手法も本ＡＰ動作例４に適用できる。

ＡＰ動作例ではＡＰ１がＡＰ２のＢＳＳ内で通信が行われている状況を検知していない場合に、ＡＰ２はそれを検知しても、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されているので、ＡＰ２は送信しないため、ＡＰ２の通信がｉｎｔｒａ－ＢＳＳ通信と衝突してしまうことは回避できる。また、ＡＰ２では検知しているＥＳＳ外の他のＢＳＳ内の通信があり、それをＡＰ１では検知していない状況では、ＡＰ１がＭＡＰＴＸＳＴＦをＡＰ２に送信しても、ｂａｓｉｃＮＡＶが設定されているので、ＡＰ２は送信しないため、ＡＰ２が送信し、その送信がＥＳＳ外の他のＢＳＳ内の通信と衝突してしまう状況は回避できる。

次に、ＳＴＡに実装されるＭＡＰ動作例を説明する。

＜ＳＴＡが接続するＡＰ（自ＡＰ）が他ＡＰからＴＸＯＰの一部無線リソースを割り当てられ、それをさらに自ＡＰからＳＴＡに割り当てられた場合にＳＴＡがそれを使う動作例＞
ここでは、ｓｈａｒｅｄＡＰ下のＳＴＡの動作について記述する。８０２．１１ａｘ規格対応のＳＴＡはＵＬＭＵ送信に対応していることから、ＡＰ動作例４のように３つのＮＡＶを持つ場合での実現例、また従来、通常は２つのＮＡＶを持っていることが期待されるが、１つのＮＡＶのみを持ち、２つのＮＡＶを持つ場合と同様な期待動作を実現する場合での実現例を順に追って説明する。

＜ＳＴＡ動作例１：ＳＴＡは同一ＥＳＳ内のＡＰが送信したフレームを同一ＢＳＳ内のフレームと同じ扱いにする＞
ＳＴＡ動作例１では、ＳＴＡは２つのＮＡＶ、すなわちｉｎｔｒａ－ＢＳＳＮＡＶとｂａｓｉｃＮＡＶを持ち、同一ＥＳＳ内のＡＰが送信したフレームを同一ＢＳＳ内のＡＰまたはＳＴＡが送信したフレームと同じ扱いにする。すなわち、ＳＴＡは、ＳＴＡが接続するＡＰ以外でかつ同一ＥＳＳ内のＡＰが送信したフレームを受信すると、自ＡＰが送信した場合と同様にｉｎｔｒａ－ＢＳＳＮＡＶを設定する。

これを実現するためには、ＳＴＡは予めどのＡＰが同一ＥＳＳ内のＡＰであるかを把握しておく必要がある。そのために例えばＳＴＡが接続するＡＰがビーコンフレームやプローブ応答フレーム、アソシエーション応答フレームに、同一ＥＳＳ内のＡＰに関する情報を入れる。この情報の通知には例えば情報エレメントを使う。先のＭＡＰ動作に係る能力通知を行う情報エレメントにこの情報を追加するようにしてもよいし、同一ＥＳＳ内のＡＰの情報を通知するための情報エレメントを新たに設けてもよい。

図１８は、ＳＴＡ動作例１の一例を説明するための図である。ＡＰ２がＡＰ１からのＭＡＰＴＸＳＴＦを受信し、それに対する応答であるＴＸＳＲＳＰをＡＰ１に送信した後、ＡＰ２に接続するＳＴＡ２１とＳＴＡ２２にＴＦを送信する。ＳＴＡ２１とＳＴＡ２２は各々ＡＰ１からのＴＦの送信は同一ＥＳＳ内の送信であると判断し、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。そのため、ＳＴＡ２１とＳＴＡ２２は、ＡＰ２からのＴＦに対して応答し、ＵＬＭＵでデータフレームＤａｔａ１、Ｄａｔａ２を夫々ＡＰ２に送信できる。ＳＴＡ２１あるいはＳＴＡ２２でｂａｓｉｃＮＡＶが設定されていた場合には、ＳＴＡ２１あるいはＳＴＡ２２はＴＦ（厳密にはＴＦのＣＳＲｅｑｕｉｒｅｄサブフィールドが“１”の場合）に応答しない。

ＡＰ２に接続するＳＴＡ２１、ＳＴＡ２２は、ｉｎｔｒａ－ＢＳＳＮＡＶの通常の設定条件を満たすかどうかを前述のように受信したフレームのアドレスフィールドなどに自ＳＴＡが接続するＡＰのＭＡＣアドレスと同一のＢＳＳＩＤが入っているかなどで判断していた。しかし、ＭＡＰ動作に対応するＳＴＡは、これに加えて、受信フレームのＳＡに同一ＥＳＳ内のＡＰのＭＡＣアドレスが入っているかも設定条件の判断に含め、この条件に該当する場合にはｉｎｔｒａ－ＢＳＳＮＡＶを設定する。また、ＳＴＡは前述のように物理パケットのヘッダにＥＳＳ情報などが入る場合には、それに基づいて受信したフレームは同一ＢＳＳ内のフレームであると判断し、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。図１８ではＭＡＰＴＸＳＴＦのＳＡがＡＰ１であり、ＳＴＡ２１とＳＴＡ２２はＡＰ１がＡＰ２と同一ＥＳＳのＡＰであることを認識していることから、ＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。なお、ＭＡＰＴＸＳＴＦがＡＰ１からＡＰ２にユニキャストで送信される場合には、ＲＡにＡＰ２が設定されるので、通常の設定条件が満たされ、ｉｎｔｒａ－ＢＳＳＮＡＶが設定される。しかし、ＭＡＰＴＸＳＴＦでＲＡがブロードキャストアドレスに設定されている場合にも、ＳＡがＡＰ１であることから、前述の設定条件の判断に従い、ＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。

ＳＴＡ動作例１ではＡＰ１がＡＰ２にＴＸＯＰの無線リソースの一部を共有しない場合であっても、ＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定してしまう。そのため、仮にＡＰ２がＳＴＡ２１、ＳＴＡ２２で検知している送信を検知していない場合には、ＳＴＡ２１とＳＴＡ２２はＡＰ２が送信したＴＦに対して応答を送信してしまう。

これを解決するためには、例えば同一ＥＳＳ内のＡＰがＭＡＰＴＸＳＴＦを送信する場合であっても、全ての場合で、ＳＴＡ２１、ＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定せず、同一ＥＳＳ内のＡＰがＭＡＰＴＸＳＴＦを自ＡＰに送信したときにだけ、ＳＴＡ２１、ＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する方法がある。この場合、受信フレームのＲＡが自ＡＰであるかを判別して、受信フレームのＲＡが自ＡＰである場合に、ＳＴＡ２１、ＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。あるいは、受信フレームのＲＡがブロードキャストアドレスの場合は、例えばＡＩＤ１２フィールドのような、さらに個々のＳＴＡ／ＡＰを指定するフィールドがあれば、そのフィールドで自ＡＰが指定されているかを判別して、自ＡＰが指定されている場合に、ＳＴＡ２１、ＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。しかし、これらの場合、例えば共有元ＡＰがまずＣＴＳ－ｔｏ－ｓｅｌｆフレームなどを送信するなどしてＴＸＯＰを確保した場合には、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されず、その後にＳＴＡが接続するＡＰにＴＸＯＰの一部無線リソースが割り当てられ、さらにＳＴＡが接続するＡＰから当該ＳＴＡに無線リソースが再配分された際に、ＳＡＴは送信することができない。この解決方法の一例としてはＳＴＡ動作例４で説明する方法がある。

別の解決方法としては、同一ＥＳＳ内の他のＡＰから送信されたフレームに対し、受信電力レベル（例えばｒｅｃｅｉｖｅｓｉｇｎａｌｓｔｒｅｎｇｔｈｉｎｄｉｃａｔｏｒ（ＲＳＳＩ）として通知）がある値（少なくとも－６２ｄＢｍ未満。例えば－７２ｄＢｍあるいは－８２ｄＢｍ）以下であれば、ＳＴＡはｉｎｔｒａ－ＢＳＳＮＡＶを設定し、その値よりも大きければ、ＳＴＡはｂａｓｉｃＮＡＶを設定する方法がある。このようにすることで、自ＢＳＳのフレームではないが、同一ＥＳＳ内のＡＰからのフレームを受信し、かつ受信電力レベルがある程度低い場合には、仮に異なるＢＳＳでの通信同士が衝突しても互いに信号対干渉電力比（ｓｉｇｎａｌ－ｔｏ－ｉｎｔｅｒｆｅｒｅｎｃｅｒａｔｉｏ；ＳＩＲ）が大きいため通信を継続することが期待できるために、ｉｎｔｒａ－ＢＳＳＮＡＶを設定しても問題ないと考えられる。これは、８０２．１１ａｘ規格の空間的な周波数再利用（ｓｐａｔｉａｌｒｅｕｓｅ；ＳＲ）の概念が入ったものである。

ＳＴＡ動作例１では、仮にＡＰ１がＡＰ２にＴＸＯＰの一部無線リソースを割り当てた後にＡＰ１がＡＰ３にＴＸＯＰの他の一部無線リソースを割り当てる場合に、ＡＰ３及びその配下のＳＴＡはＡＰ２及びその配下のＳＴＡとのフレーム交換ではｂａｓｉｃＮＡＶを設定してしまう。そのため、ＡＰ２がＡＰ１のＴＸＯＰの最後までカバーする時間をＤｕｒａｔｉｏｎ／ＩＤフィールド、またはＴＸＯＰフィールドに設定すると、ｂａｓｉｃＮＡＶが設定されているために、ＡＰ３及びその配下のＳＴＡは送信できない。従って、ＡＰ２はＡＰ１によって割り当てられた時間だけをカバーするようＤｕｒａｔｉｏｎ／ＩＤフィールド、またはＴＸＯＰフィールドを設定し、ＡＰ２に接続するＳＴＡもＡＰ２に従った設定をするようにすると、ＡＰ３及びその配下のＳＴＡは送信ができる。

次に、ＳＴＡ動作例１の変形例であるＡＰ／ＳＴＡ動作例を説明する。ＡＰ／ＳＴＡ動作例はＳＴＡの動作のみならず、ＡＰの動作も規定する。

＜ＡＰ／ＳＴＡ動作例：ＥＳＳ内フレームにｉｎｔｒａ－ＢＳＳＮＡＶ適用＞
この動作例では、同一ＥＳＳ内のフレームを受信すると、ｉｎｔｒａ－ＢＳＳＮＡＶが設定される。この場合、ＮＡＶの設定条件は前述の通常のｉｎｔｒａ－ＢＳＳＮＡＶの設定条件において自ＢＳＳＩＤとした部分をＥＳＳ内の全てのＢＳＳＩＤに拡張したものである。このＮＡＶの設定条件はＡＰに接続するＳＴＡにのみ適用するようにしてもよいし、ＡＰとそれに接続するＳＴＡにも適用するようにしてもよい。ここでは、ＡＰとＳＴＡの両方にｉｎｔｒａ―ＢＳＳＮＡＶを設定する動作例を説明する。ＳＴＡはｉｎｔｒａ－ＢＳＳＮＡＶのみが設定されている状態では、自ＡＰからのＴＦに応答できるとする。ＡＰはｉｎｔｒａ－ＢＳＳＮＡＶのみが設定されている状態では、同一ＥＳＳ内の他のＡＰからのＭＡＰＴＸＳＴＦに応答できるとする。

図１９は、ＡＰ／ＳＴＡ動作例の一例を説明するための図である。ＡＰ１またはその配下のＳＴＡは、ＴＸＯＰを保護するために、例えばフレーム交換の先頭でＣＴＳ－ｔｏ－ｓｅｌｆフレームをＡＰ２及び配下のＳＴＡに送信する。ＡＰ２及びその配下のＳＴＡ２１とＳＴＡ２２はＣＴＳ－ｔｏ－ｓｅｌｆフレームからＡＰ１が自ＥＳＳ内のＡＰであると判断し、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。ＡＰ２はＡＰ１からのＭＡＰＴＸＳＴＦを受信する。ＡＰ２はＭＡＰＴＸＳＴＦが自ＥＳＳ内のフレームであると判断し、ｉｎｔｒａ－ＢＳＳＮＡＶのみが設定されている場合は、それを無視してＴＸＰＲＥＳをＡＰ１へ送信し、ＴＦを配下のＳＴＡ２１、ＳＴＡ２２へ送信する。ＴＦが同じＢＳＳ内のＡＰ２からのフレームであるので、ＳＴＡ２１、ＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶのみが設定されている場合は、それを無視してデータＤａｔａ１、データＤａｔａ２をＡＰ２へ夫々送信する。

ＡＰ／ＳＴＡ動作例にＳＴＡ動作例１で説明した受信電力レベルによるｉｎｔｒａ－ＢＳＳＮＡＶの設定条件を追加してもよい。

ＡＰ／ＳＴＡ動作例であれば、仮にＡＰ１がＡＰ２に一部無線リソースを割当てた後に、引き続きＡＰ１が他のＡＰ３にＴＸＯＰの一部無線リソースを割り当てる場合などであっても、ＡＰ２がＡＰ１のＴＸＯＰの最後までｂａｓｉｃＮＡＶを設定してしまい、ＡＰ３とその配下のＳＴＡで送信ができないというＳＴＡ動作例１でのような問題は起きない。そのため、ＳＴＡ動作例１のようにしてもよいが、ＡＰ／ＳＴＡ動作例ではＡＰ２はＡＰ１のＴＸＯＰの最後までカバーする時間をＤｕｒａｔｉｏｎ／ＩＤフィールド、またはＴＸＯＰフィールドに設定するようにし、またＡＰ２の配下のＳＴＡもＡＰ２に従った設定をするようにし、ＡＰ３及びその配下のＳＴＡが送信できるようにしてもよい。

またＡＰ／ＳＴＡ動作例では、図１９に示すように、ＭＡＰＴＸＳＴＦの送信前に共有元ＡＰであるＡＰ１がＴＸＯＰを保護するために例えばフレーム交換の先頭でＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信した場合であっても、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されることになり、ＳＴＡ２１とＳＴＡ２２はその後のＡＰ２からのＴＦに対して応答でき、問題はない。

＜ＳＴＡ動作例２：他ＡＰにＴＸＯＰを共有するフレームでは、ＮＡＶを設定しない＞
ＳＴＡ動作例２では、ＳＴＡは２つのＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶとｂａｓｉｃＮＡＶを持つ。通常は、あるＡＰが他のＡＰにＴＸＯＰの一部無線リソースを共有するフレームをＳＴＡが受信した場合には、ＳＴＡはｂａｓｉｃＮＡＶを設定、あるいはＲＡに自ＡＰが設定されている場合にはｉｎｔｒａ－ＢＳＳＮＡＶを設定する。しかし、ＳＴＡ動作例２では、ＳＴＡはそれらのＮＡＶを設定しない。あるＡＰが他のＡＰにＴＸＯＰの一部無線リソースを共有するフレームをＳＴＡが受信したかはフレーム種別で判別することができる。例えばそのフレームが前述の例のようにトリガーフレームの一種であるＭＡＰＴＸＳＴＦであるならば、ＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールドが制御フレームで、Ｓｕｂｔｙｐｅサブフィールドがトリガーフレームで、さらにＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドがＭＡＰＴＸＳバリアントであり、このバリアントの種別まで見てフレーム種別を判別し、その判別結果に応じてＮＡＶを設定する／しないという判断を行うことができる。

図２０はＳＴＡ動作例２の一例を説明するための図である。ＳＴＡ２１とＳＴＡ２２はフレーム種別がＭＡＰＴＸＳＴＦであることを検知すると、そのフレームはＮＡＶを設定しないフレームであると判断する。従って、その後にＡＰ２がＴＸＳＲＳＰをＡＰ１へ送信し、ＳＴＡ２１とＳＴＡ２２はそれを受信すると、従来のようにｉｎｔｒａ－ＢＳＳＮＡＶを設定する。その後にＡＰ２がＳＴＡ２１とＳＴＡ２２に対して送信するＴＦに対しては、ｉｎｔｒａ－ＢＳＳＮＡＶのみが設定されている状況であれば、ＳＴＡ２１とＳＴＡ２２はＴＦに対して応答送信できる。

ＳＴＡ動作例２では、フレーム種別、すなわちＭＡＰＴＸＳＴＦであるか否かのみをＮＡＶ設定の判断に用い、同一ＥＳＳ内のＡＰからであるか、あるいは受信したフレームが自ＡＰ宛てか（ＲＡに自ＡＰが設定されているかもしくはＡＩＤ１２サブフィールドで自ＡＰが指定されているか）の判断はＮＡＶ設定に不要である。単純にフレーム種別を確認するだけでよいため、ＮＡＶ設定の判断基準を単純にできる。

ＭＡＰＴＸＳＴＦによりＮＡＶは設定されないのでＴＸＯＰの保護はできないが、引き続き自ＡＰからのＴＸＳＲＳＰ送信がある場合には、その送信によりＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する、また他のＡＰにＴＸＯＰの一部が割り当てられ、当該他のＡＰがＴＸＳＲＳＰを送信する場合には、その送信によりＳＴＡ２１とＳＴＡ２２ではｂａｓｉｃＮＡＶを設定するので、ＭＡＰＴＸＳＴＦを送信したＡＰのＴＸＯＰは最終的に保護されることになる。

なお、ＭＡＰＴＸＳＴＦが複数のＡＰに送信され、その応答であるＴＸＳＲＳＰがＭＡＰＴＸＳＴＦを送信したＡＰへのＭＵ送信（これをｉｎｔｅｒ－ＡＰＭＵと呼ぶことにする）になる場合は、ＳＴＡ２１とＳＴＡ２２は一旦ｂａｓｉｃＮＡＶを設定することが考えられる。これは、ｉｎｔｅｒ－ＡＰＭＵの物理パケットのヘッダにＥＳＳｃｏｌｏｒが入れられる場合に、ＥＳＳｃｏｌｏｒは自ＢＳＳのＢＳＳｃｏｌｏｒでないため、ＳＴＡ２１とＳＴＡ２２がｂａｓｉｃＮＡＶを設定する動作を想定した場合である。ＳＴＡ２１とＳＴＡ２２がｂａｓｉｃＮＡＶを設定してしまうと、ＳＴＡ２１とＳＴＡ２２はその後のＡＰ２からのＴＦに応答送信することができない。

これを回避する方法の１つとして、ＳＴＡは、例えばｂａｓｉｃＮＡＶの設定終了時刻からＳＩＦＳ後に自ＡＰからＴＦを受信するなどしてｉｎｔｒａ－ＢＳＳＮＡＶを設定した場合にはその直前のｂａｓｉｃＮＡＶをキャンセル（ＮＡＶ値を０にする）することが考えられる。ＳＴＡは、ｂａｓｉｃＮＡＶが前から設定されており、その期間内にｉｎｔｅｒ－ＡＰＭＵを受信してｂａｓｉｃＮＡＶを再更新し、その再更新のＮＡＶの終了時刻からＳＩＦＳ後にｉｎｔｒａ－ＢＳＳＮＡＶを設定した場合にはｂａｓｉｃＮＡＶをキャンセルしない。すなわち、ＳＴＡは、ｉｎｔｒａ－ＢＳＳＮＡＶを設定した物理パケットの直前のＳＩＦＳで新たにｂａｓｉｃＮＡＶを設定した場合にだけ、ｂａｓｉｃＮＡＶをキャンセルできる。

あるいは、もう一つの回避方法は、ＳＴＡは物理パケットのヘッダのＥＳＳｃｏｌｏｒから同一ＥＳＳ内のフレームを受信したと判断できた場合には、ｂａｓｉｃＮＡＶではなく、ｉｎｔｒａ－ＢＳＳＮＡＶを設定することである。

あるいは、さらに他の回避手法は、ＳＴＡはＭＡＰＴＸＳＴＦを受信した直後のｉｎｔｅｒ－ＡＰＭＵの物理パケットではＭＡＰＴＸＳＴＦを受信した場合と同様にＮＡＶを設定しない（この場合は、特にｂａｓｉｃＮＡＶを設定しない）ことである。

ＳＴＡ動作例２では、ＡＰ１がＡＰ２に一部無線リソースを割り当てた後に、引き続き他のＡＰに一部無線リソースを割り当てるような場合には、ＳＴＡ動作例１の場合と同様、他のＢＳＳでのフレーム交換ではｂａｓｉｃＮＡＶが設定されてしまう。そのため、これを回避するために、各ＡＰは共有元ＡＰによって割り当てられた時間だけをカバーするようＤｕｒａｔｉｏｎ／ＩＤフィールド、またはＴＸＯＰフィールドを設定するようにする。また各ＡＰに接続するＳＴＡもそのＡＰに従った設定をするようにする。

また、ＳＴＡ動作例２ではＭＡＰＴＸＳＴＦの送信前に共有元ＡＰであるＡＰ１がＴＸＯＰを保護するために例えばフレーム交換の先頭でＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信した場合に、ＣＴＳ－ｔｏ－ｓｅｌｆフレームにはＲＡしかアドレスフィールドがなく、ＲＡはＡＰ１であるため、ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶを設定してしまい、その後のＡＰ２からのＴＦに対して応答送信できなくなる。ＳＴＡ動作例２については、できるだけ単純なＮＡＶ設定条件でＳＴＡがＭＡＰ下での所望送信を可能にする趣旨とするので、この問題の解決方法としては、例えば後述のＳＴＡ動作例４での同様の問題に対する解決方法として記載した、ＭＡＰＴＸＦＴＦを送信するＡＰではＣＴＳ－ｔｏ－ｓｅｌｆフレームの送信を禁ずることが相性がよい。しかし、ＳＴＡ動作例４でのその他の解決方法を適用してもよい。

＜ＳＴＡ動作例３：他ＡＰにＴＸＯＰを共有するフレームで、かつＴＸＯＰ共有の割当先に自ＡＰが含まれている場合、ＮＡＶを設定しない＞
ＳＴＡ動作例３では、ＳＴＡ動作例２と同様にＳＴＡは２つのＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶとｂａｓｉｃＮＡＶを持つが、ＳＴＡ動作例２とは違い、フレーム種別に加えて、割当先が自ＡＰであるかまでＳＴＡは確認する。

図２１はＳＴＡ動作例３の一例を説明するための図である。ＡＰ１はこの例ではＭＡＰＴＸＳＴＦをＡＰ２と他のＡＰに対して送信している。従ってＭＡＰＴＸＳＴＦのＲＡはブロードキャストアドレスである。ＳＴＡ２１とＳＴＡ２２はこのＭＡＰＴＸＳＴＦを受信すると、自ＡＰが割り当て対象となっているかを確認する。すなわち、ＳＴＡ２１とＳＴＡ２２は受信したＭＡＰＴＸＳＴＦのＵｓｅｒＩｎｆｏフィールドのいずれかのＡＩＤ１２サブフィールドに自ＡＰであるＡＰ２が指定されているかを確認する。受信したフレームがＭＡＰＴＸＳＴＦで、かつ自ＡＰが指定されていれば、ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶもｉｎｔｒａ－ＢＳＳＮＡＶも設定しない。この条件に当てはまらない場合は、ＳＴＡ２１とＳＴＡ２２は通常のＮＡＶ設定をする。

例えばＳＴＡ２１とＳＴＡ２２はＭＡＰＴＸＳＴＦを受信した場合、ＭＡＰＴＸＳＴＦに自ＡＰが指定されていることを確認できなければ、ｂａｓｉｃＮＡＶを設定する。なお、ＭＡＰＴＸＳＴＦのＲＡにＡＰ２が設定されている場合（すなわち（ＡＰ２にのみ割当てている場合）、ＳＴＡ２１とＳＴＡ２２は通常のＮＡＶ設定の手続きに従って、ｉｎｔｒａ－ＢＳＳＮＡＶを設定するのでよい。従って、ＳＴＡ２１とＳＴＡ２２はまず受信したフレームがＭＡＰＴＸＳＴＦの場合にＲＡがユニキャストアドレスであれば、通常の手続きに従いＮＡＶを設定する。すなわち、ＳＴＡ２１とＳＴＡ２２はＲＡが自ＡＰであれば、ｉｎｔｒａ－ＢＳＳＮＡＶを設定し、ＲＡが他のＡＰであれば、ｂａｓｉｃＮＡＶを設定する。ＳＴＡ２１とＳＴＡ２２は受信したフレームがＭＡＰＴＸＳＴＦの場合にＲＡがブロードキャストアドレスであれば、自ＡＰが割り当てられているかを確認し、自ＡＰが割り当てられている場合にはＮＡＶを設定せず、自ＡＰの割当てが確認できなければｂａｓｉｃＮＡＶを設定すればよい。

ＳＴＡ動作例３では同一ＥＳＳ内のＡＰからの送信かの確認（すなわちＭＡＰＴＸＳＴＦのＴＡの確認）は不要だが、ＲＡの確認、ＲＡの設定によってはさらに割当先の確認が必要である。

ＳＴＡ動作例３では、受信したフレームがＭＡＰＴＸＳＴＦであり複数のＡＰ宛てでかつ自ＡＰへの割当てがある場合には、当該フレームによるＴＸＯＰの保護はできない。引き続いて自ＡＰからのＴＸＳＲＳＰ送信はｉｎｔｅｒ－ＡＰＭＵ送信されることが期待されるが、その場合、ＳＴＡ２１とＳＴＡ２２は一旦ｂａｓｉｃＮＡＶを設定することが考えられる。これはＳＴＡ動作例２で提示した状況と同じである。ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶを設定してしまうと、その後のＡＰ２からのＴＦに応答送信することができない。

従って、これを回避するためには、ＳＴＡ動作例２で提示したと同様に、例えばｉｎｔｒａ－ＢＳＳＮＡＶを設定した直前に新規に設定されたｂａｓｉｃＮＡＶはキャンセルする、あるいは受信した物理パケットのヘッダのＥＳＳｃｏｌｏｒから物理パケットは同一ＥＳＳからの送信されたものであると判断できた場合にはｂａｓｉｃＮＡＶではなく、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する、あるいはＮＡＶを設定しなかったＭＡＰＴＸＳＴＦの直後のｉｎｔｅｒ－ＡＰＭＵでは同様にＮＡＶを設定しない、などの方法がある。いずれにせよ、自ＡＰから自ＢＳＳ内への送信が引き続き起こる場合には、それによってｉｎｔｒａ－ＢＳＳＮＡＶがＳＴＡ側では設定されるため、あるいはＳＴＡ側ではＡＰの送信対象となってタイマーを持つことでＡＰへの応答フレームの送信のみに抑制されるため、自ＡＰに割り当てられたＴＸＯＰ期間中は無線リソースを保護でき、更にその後他のＡＰにのみ割り当てられた際にはｂａｓｉｃＮＡＶが設定されることになり無線リソースを保護できる。ＳＴＡ２１とＳＴＡ２２はＡＰ２からのＴＦ受信時にｉｎｔｒａ－ＢＳＳＮＡＶしか設定されていないため、ＴＦに対して応答送信ができる。

ＳＴＡ動作例３では、ＡＰ１がＡＰ２にＴＸＯＰの一部無線リソースを割り当てた後に他のＡＰにＴＸＯＰの一部無線リソースを割り当てるような場合には、ＳＴＡ動作例１の場合と同様、他のＢＳＳではｂａｓｉｃＮＡＶが設定されてしまうため、各ＡＰは共有元ＡＰに割り当てられた時間だけをカバーするようＤｕｒａｔｉｏｎ／ＩＤフィールド、またはＴＸＯＰフィールドを設定、また各ＡＰに接続するＳＴＡもそのＡＰに従った設定をするようにする。

ＳＴＡ動作例３でも共有元ＡＰであるＡＰ１がフレーム交換先頭でＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信するなど、予めＴＸＯＰ全体を保護するようなフレーム交換が行われた場合には、ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶを設定してしまい、その後のＡＰ２からのＴＦに対して応答できない問題が起きうる。それを回避するためには、後述のＳＴＡ動作例４と同様の解決方法を適用すればよい。

＜ＳＴＡ動作例４：他ＡＰにＴＸＯＰを共有するフレームを受信し、かつＴＸＯＰ共有の割当先に自ＡＰが含まれている場合、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する＞
ＳＴＡ動作例４では、共有元ＡＰが共有先ＡＰにＴＸＯＰの一部無線リソースを割り当てるフレームをＳＴＡが受信し、その一部無線リソースの共有先としてＳＴＡに接続するＡＰが割り当てられている場合には、ＳＴＡはｉｎｔｒａ－ＢＳＳＮＡＶを設定する。ＳＴＡ動作例３では受信フレームが同一条件を満たす場合にｂａｓｉｃＮＡＶを設定しない、としたが、ＳＴＡ動作例４ではｉｎｔｒａ－ＢＳＳＮＡＶを設定するということである。

図２２はＳＴＡ動作例４の一例を説明するための図である。送信権を獲得したＡＰ１がＡＰ２と他のＡＰに対し、一部の無線リソースを割り当てるＭＡＰＴＸＳＴＦを送信する。このＭＡＰＴＸＳＴＦは複数のＡＰに一部無線リソースを割り当てる場合、ＳＴＡ動作例３の図２１と同様にＲＡにはブロードキャストアドレスが設定される。そこで、ＳＴＡ２１とＳＴＡ２２は、受信フレームがＭＡＰＴＸＳＴＦというフレーム種別であると判断すると、次に自ＡＰであるＡＰ２が割り当ての対象になっているかを確認する。すなわちＳＴＡ２１とＳＴＡ２２は、ＭＡＰＴＸＳＴＦのＵｓｅｒＩｎｆｏフィールドのいずれかのＡＩＤ１２サブフィールドにＡＰ２が指定されているかを確認する。ＡＰ２が指定されていれば、ＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。このｉｎｔｒａ－ＢＳＳＮＡＶの設定条件に当てはまらない場合は、ＳＴＡ２１とＳＴＡ２２は通常のＮＡＶ設定を行う、すなわちｂａｓｉｃＮＡＶを設定する。なお、ＭＡＰＴＸＦＴＦがＡＰ２にのみ送信され、ＲＡがＡＰ２に設定されている場合は、通常のＮＡＶ設定の手続きに従って、ＳＴＡ２１とＳＴＡ２２はｉｎｔｒａ－ＢＳＳＮＡＶを設定する。従って、手順としてはＳＴＡ２１とＳＴＡ２２はまず受信フレームがＭＡＰＴＸＳＴＦの場合にＲＡがユニキャストアドレスであれば、通常の手続きに従いＮＡＶ設定を行う。すなわち、ＳＴＡ２１とＳＴＡ２２はＲＡが自ＡＰであればｉｎｔｒａ－ＢＳＳＮＡＶを設定し、ＲＡが他のＡＰであればｂａｓｉｃＮＡＶを設定する。ＳＴＡ２１とＳＴＡ２２は受信フレームがＭＡＰＴＸＳＴＦの場合にＲＡがブロードキャストアドレスであれば、自ＡＰが割り当てられているかを確認し、確認できた場合にｉｎｔｒａ－ＢＳＳＮＡＶを設定、確認できなければｂａｓｉｃＮＡＶを設定すればよい。

ＳＴＡ２１とＳＴＡ２２は自ＡＰであるＡＰ２に無線リソースを割り当てるＭＡＰＴＸＳＴＦを受信すると、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。そのため、ＳＴＡ２１とＳＴＡ２２はその後にＡＰ２からのＴＦに対し、応答することができる。

ＳＴＡ動作例４でも、ＳＴＡ動作例３と同様、同一ＥＳＳ内のＡＰからの送信かの確認（すなわちＭＡＰＴＸＳＴＦのＳＡの確認）は不要だが、ＲＡの確認、ＲＡの設定によってはさらに割当先の確認が必要である。

ＳＴＡ動作例４では、ＳＴＡ動作例３と違い、受信フレームがＭＡＰＴＸＳＴＦであり複数のＡＰ宛てでかつ自ＡＰへの無線リソースの割当てがある場合にも、当該フレームによるＴＸＯＰの保護ができる。引き続いて自ＡＰからのＴＸＳＲＳＰ送信はｉｎｔｅｒ－ＡＰＭＵ送信されることが期待されるが、その場合、ＳＴＡ２１とＳＴＡ２２はＭＵパケットのヘッダのＢＳＳｃｏｌｏｒが自ＢＳＳとは異なると判断すると、ｂａｓｉｃＮＡＶを設定してしまう。これは前述のＳＴＡ動作例２あるいはＳＴＡ動作例３で提示した状況と同じである。

そこで、これを回避する方法としては、ＳＴＡ動作例２やＳＴＡ動作例３で採用された方法がある。例えばＳＴＡはＴＦでｉｎｔｒａ－ＢＳＳＮＡＶを設定するが、その直前に新規に設定されたｂａｓｉｃＮＡＶをキャンセルする方法がある。あるいは物理パケットのヘッダに通常はＢＳＳｃｏｌｏｒを入れるところを、ｉｎｔｅｒ－ＡＰ通信ではそこにＢＳＳｃｏｌｏｒを入れる方法がある。あるいはＥＳＳｃｏｌｏｒを入れるフィールドを別途設け、同一ＥＳＳの通信であると判断できた場合には、ｂａｓｉｃＮＡＶではなく、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する方法がある。あるいは、ＭＡＰＴＸＳＴＦで設定されたｉｎｔｒａ－ＢＳＳＮＡＶと、ＴＸＳＲＳＰにより設定するｂａｓｉｃＮＡＶが同じ期間（すなわちＮＡＶの終了時点が同一）である場合には、ＴＸＳＲＳＰにより設定するＮＡＶをｂａｓｉｃＮＡＶの代わりにｉｎｔｒａ－ＢＳＳＮＡＶにするという方法がある。

図２２の例では、ＮＡＶの種類をｂａｓｉｃＮＡＶからｉｎｔｒａ－ＢＳＳＮＡＶに置き換えるかの判断を行う物理パケット（ＴＸＳＲＳＰを格納する）に対し、比較するｉｎｔｒａ－ＢＳＳＮＡＶを設定する物理パケット（ＭＡＰＴＸＳＴＦを格納する）が前に来る。しかし、比較するｉｎｔｒａ－ＢＳＳＮＡＶを設定する物理パケットとして、ＴＸＳＲＳＰを格納する物理パケットの後に来る、ＴＦを格納する物理パケットを用いるようにしてもよい。その場合は、ＴＸＳＲＳＰにより設定するｂａｓｉｃＮＡＶと、自ＢＳＳのＳＴＡに無線リソースを割り当てるＴＦにより設定されるｉｎｔｒａ－ＢＳＳＮＡＶ（自ＳＴＡのみに割り当てられる場合には保持するタイマー）が同じ期間（すなわちＮＡＶの終了時点が同一）である場合には、ＴＸＳＲＳＰにより設定するＮＡＶをｂａｓｉｃＮＡＶの代わりにｉｎｔｒａ－ＢＳＳＮＡＶにする。このように設定される期間が同一である場合に、ｂａｓｉｃＮＡＶをｉｎｔｒａ－ＢＳＳＮＡＶに変更する際に、前述の直前あるいは直後の制約を組み合わせるようにしてもよい。その場合、直前あるいは直後を判断するために、２フレームの間隔が例えばＳＩＦＳのフレーム間隔になっているかを使う。直前がｂａｓｉｃＮＡＶであった場合にだけｂａｓｉｃＮＡＶがｉｎｔｒａ－ＢＳＳＮＡＶに書き換えられるようにするためには、ＳＴＡ２１、ＳＴＡ２２は、新規にｂａｓｉｃＮＡＶを設定する場合に、例えばそのＮＡＶの開始時点（物理パケットの終了時点）と終了時点を一時的なメモリ（例えば、図２のメモリ９４）に格納し、次にｉｎｔｒａ－ＢＳＳＮＡＶ（あるいは保持するタイマ）を設定する際の物理パケットの開始時点と前記ＮＡＶの開始時点の差分がＳＩＦＳであるか、差分がＳＩＦＳであった場合にＮＡＶの終了時点が同一になるかを判断する。これらの２つの条件を満たした場合にはＳＴＡ２１、ＳＴＡ２２は、当該ｂａｓｉｃＮＡＶを設定せず、満たさない場合にはｂａｓｉｃＮＡＶを設定するようにしてもよい。あるいは、ＳＴＡ２１、ＳＴＡ２２は、新規にｂａｓｉｃＮＡＶを設定する場合に例えば一時的なメモリにそのＮＡＶの終了時点を格納し、次の物理パケットとのフレーム間隔がＳＩＦＳ以上（比較、設定のための処理時間を上乗せしてもよい）となったら、その格納しておいた情報を削除しつつ、ｂａｓｉｃＮＡＶの設定を確定し、次の物理パケットのｉｎｔｅｒ－ＢＳＳＮＡＶ（あるいは保持するタイマ）の終了時点を比較するための情報が残っていればＮＡＶの終了時点が同一になるかを判断し、同一であればｂａｓｉｃＮＡＶは設定せず、同一でなければｂａｓｉｃＮＡＶを設定するようにしてもよい。いずれにせよ、何らか一時的なメモリに情報を保持しておく仕組みが必要である。このようにすることで、自ＡＰによって割り当てられたＴＸＯＰ期間中は割り当てられた無線リソースを保護でき、更にその後他のＡＰにのみよってＴＸＯＰの一部の無線リソースが割り当てられた際にはｂａｓｉｃＮＡＶが設定されることになり割り当てられた無線リソースが保護できる。

このＳＴＡ動作例４では、ＡＰ１がＡＰ２に一部無線リソースを割り当てた後に、引き続き他のＡＰに一部無線リソースを割り当てるような場合には、ＳＴＡ動作例１の場合と同様、他のＢＳＳではｂａｓｉｃＮＡＶが設定されてしまう。そのため、各ＡＰは共有元ＡＰによって割り当てられた時間だけをカバーするようＤｕｒａｔｉｏｎ／ＩＤフィールド、ＴＸＯＰフィールドを設定、また各ＡＰに接続するＳＴＡもそのＡＰに従った設定をするようにする。

このＳＴＡ動作例４でも共有元ＡＰであるＡＰ１がフレーム交換先頭でＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信してからＡＰ２に無線リソースの一部を割当てる場合、ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶを設定してしまい、その後にＡＰ２からＴＦを受信してもそのＴＦに応答できない。

その場合の第１の解決方法は、ＳＴＡ２１とＳＴＡ２２は、受信したフレームが例えば同一ＥＳＳ内のＡＰから送信されたＣＴＳ－ｔｏ－ｓｅｌｆフレームであれば、ｉｎｔｒａ－ＢＳＳＮＡＶを設定することである。なお、同一ＥＳＳ内でもＭＡＰ動作が可能なＡＰが一部に限られる場合は、ＳＴＡ２１、ＳＴＡ２２は、ＭＡＰ候補セットのＡＰから送信されたＣＴＳ－ｔｏ－ｓｅｌｆフレームを受信したら、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。

第２の解決方法は、ＳＴＡ２１とＳＴＡ２２は、ＣＴＳ－ｔｏ－ｓｅｌｆフレームで一旦ｂａｓｉｃＮＡＶを設定するが、直後すなわちＳＩＦＳ後に同一送信元が自ＡＰにＴＸＯＰの無線リソースを割り当てる場合、ｉｎｔｒａ－ＢＳＳＮＡＶを設定し、直前のｂａｓｉｃＮＡＶキャンセルすることである。この一旦設定したｂａｓｉｃＮＡＶをキャンセルする方法は、前述のＴＸＳＲＳＰによるｂａｓｉｃＮＡＶをキャンセルする方法と同様である。あるいはＴＸＯＰの一部無線リソースを他のＡＰに割り当てるフレーム送信前のＣＴＳ－ｔｏ－ｓｅｌｆフレーム送信を禁止する。

第３の解決方法は、ＴＸＯＰ共有フレーム送信前のＣＴＳ－ｔｏ－ｓｅｌｆフレームの送信を禁止することである。これにより、ＳＴＡ２１とＳＴＡ２２は、ｂａｓｉｃＮＡＶを設定することが禁止され、ＡＰ２からＴＦを受信した場合、そのＴＦに応答できる。

第４の解決方法は、ＣＴＳ－ｔｏ－ｓｅｌｆフレームの代わりにＲＡをＥＳＳ内のＡＰ群向けにマルチキャストアドレスに設定したＣＴＳフレーム（ＣＴＳ－ｔｏ－ＥＳＳｓｅｌｆフレーム）を使用することである。この場合は、各ＡＰから接続するＳＴＡにＥＳＳ内のＡＰ群向けマルチキャストアドレスを予め周知しておく必要がある。またＳＴＡはＣＴＳフレームを受信した際に、ＲＡがＥＳＳ内のＡＰ群向けマルチキャストアドレスに設定されている場合（すなわち自ＥＳＳ内に向けたＣＴＳ－ｔｏ－ＥＳＳｓｅｌｆフレームである場合）には、ｉｎｔｒａ－ＢＳＳＮＡＶを設定するようにする。しかしＡＰ１が例えばＡＰ１に接続するＳＴＡとの間で先にフレーム交換をするなど、ＣＴＳ－ｔｏ－ｓｅｌｆフレームに限らずＴＸＯＰ全体を予め保護してしまう場合には、ＳＴＡ２１とＳＴＡ２２はそれらのフレーム交換によってｂａｓｉｃＮＡＶを設定してしまい、これらの方法では自ＡＰに無線リソースが割り当てられた後に自ＡＰからのＴＦに応答できない。これを最も単純に解決するには、ＡＰ１は他のＡＰにＴＸＯＰの一部無線リソースを割り当てる際に制限を設けることが考えられる。例えば、共有元ＡＰが構成するＢＳＳが自ＢＳＳの場合でも、共有元ＡＰが当該ＴＸＯＰを使う場合、または共有元ＡＰが共有元ＡＰ自身が構成するＢＳＳ内のＳＴＡにＴＦを送信し、それらのＳＴＡが共有元ＡＰに送信する場合であって、それらのＳＴＡが当該ＴＸＯＰを使う場合には、共有元ＡＰと共有先ＡＰ、各々で使うＴＸＯＰの期間を同一にする。あるいは、共有先ＡＰに割り当てた期間の後に当該ＴＸＯＰを使う、また共有先ＡＰにＴＸＯＰの一部無線リソースを割り当てたら、以降は共有先ＡＰを減らすことはできても増やすことはできないようにする。このようにすれば、各ＡＰ下のＳＴＡでｂａｓｉｃＮＡＶにより自ＡＰからのＴＦに応答できないということが回避できる。

＜ＳＴＡ動作例５：１つのＮＡＶ（ＡＰからＴＸＯＰを共有するフレームによって設定されたＮＡＶの期間内に自ＡＰからＴＦで自ＳＴＡに無線リソースが割り当てられたと判断した場合はＮＡＶを無視して応答）＞
ＳＴＡ動作例５は、ＳＴＡが１つのＮＡＶしか持たない場合でも対応する動作例である。ＳＴＡは共有元ＡＰが自ＡＰにＴＸＯＰの一部無線リソースを共有するフレームを受信した時にＮＡＶを設定するが、ＳＴＡが共有元ＡＰが自ＡＰにＴＸＯＰの一部無線リソースを共有するフレーム（ＭＡＰＴＸＦＴＦ）を受信した後（正確にはそれを格納する物理パケットが無線媒体上で終わる時刻）からの固定時間内に自ＡＰからＴＦを受信し、ＴＦで自ＳＴＡが割当てられている場合は、当該ＮＡＶを無視して応答する。また自ＡＰがＴＦで指定したＴＸＯＰ（実際には共有元ＡＰから割り当てられた共有元ＡＰのＴＸＯＰの一部時間）内はＮＡＶを無視してＴＦに応答する動作を継続可能とする。固定時間とは、例えば共有先ＡＰが共有元ＡＰに共有通知への応答を送信するフレームの占有時間とその前後に要するフレーム間隔の和である。例えばフレームの占有時間が変動する場合にはフレームの占有時間はその期待する最大値などとする。固定時間は図２３では少なくともＡＰ２がＴＸＳＲＳＰを送信し、ＡＰ２がＴＦを送信する開始したことを判断する時間以上を確保する必要がある。各フレーム間がＳＩＦＳであり、ＴＦの送信開始をＴＸＳＲＳＰからＳＩＦＳ＋スロット時間（＝ＰＩＦＳ）で判断できるとするなら、最低でも２×ＳＩＦＳ＋ＴＸＳＲＳＰを格納する物理パケットの占有時間＋スロット時間が固定時間である。ＴＸＳＲＳＰを格納する物理パケットの占有時間は伝送レートやフレーム長が可変であれば、変動するので、例えば期待される最大時間が用いられる。例えばこの固定時間は値が規定される。

あるいは、固定時間内の代わりに、ＣＣＡがアイドル（すなわち媒体が使われていない）と認識する期間にＳＩＦＳ以上の空きがないことを条件にＮＡＶを無視して応答してもよい（ＳＴＡ動作例５ａ）。

図２３はＳＴＡ動作例５の一例を説明するための図である。ＡＰ１がＡＰ２にＭＡＰＴＸＳＴＦを送信し、ＳＩＦＳ後にＡＰ２がＴＸＳＲＳＰをＡＰ１に送信、さらにそのＳＩＦＳ後にＡＰ２がＳＴＡ２１とＳＴＡ２２にＴＦを送信する場合、ＭＡＰＴＸＳＴＦとＴＦの間の時間は２×ＳＩＦＳとＴＸＳＲＳＰを格納する物理パケットの占有時間との和になる。例えばＴＸＳＲＳＰを格納する物理パケットの占有時間を固定に規定、あるいは想定する最大値に規定し、それを用いるようにすれば、ＭＡＰＴＸＳＴＦの固定時間内に自ＡＰからＴＦを受信したら、ＳＴＡ２１、ＳＴＡ２２は当該ＴＦに応答できる。また、全ての物理パケットがＳＩＦＳ間隔で交換されているため、それらを全て観測できるならば、ＳＩＦＳ以上に空いたＣＣＡ時間は存在しないことになり、ＳＴＡはその条件を満足したら自ＡＰからＴＦを受信した場合に応答できるようにする。なお、ＴＸＳＲＳＰを格納する物理パケットの占有時間が固定時間内であることを条件にした場合には、自ＡＰがまず他のＳＴＡに一部無線リソースを再割り当てし、その後に自ＳＴＡに再割り当てした場合には固定時間内の条件を満足しないため、ＳＴＡはＴＦに応答できないという状況が発生しうる。ＳＴＡ動作例５ａではこの状況が発生し得ない。

あるいはＴＸＯＰの一部無線リソースを他のＡＰに共有するフレームに対して自ＡＰが応答した場合（ＭＵ物理パケットではＳＴＡでの復号が期待できないため、このように自ＡＰが応答したかを把握するためには、応答フレームがＳＵ送信される場合に限られる）、あるいはＴＸＯＰの一部無線リソースを他のＡＰに共有するフレームで自ＡＰが割り当てられていた場合には、ＳＴＡ２１、ＳＴＡ２２はそのＴＸＯＰ内ではＮＡＶを無視して自ＡＰからのＴＦに応答できるようにしてもよい（ＳＴＡ動作例５ｂ）。

あるいはＳＴＡ動作例４で記載したように、自ＡＰにＴＸＯＰの一部無線リソースを共有するフレームによるＮＡＶの終了時点が、その後の固定時間内に自ＡＰにより設定されるＮＡＶあるいは保持するタイマの終了時点と同一であれば、ＳＴＡ２１、ＳＴＡ２２はＮＡＶを無視して自ＡＰからのＴＦに応答するようにしてもよい（ＳＴＡ動作例５ｃ）。この場合の終了時点が同一かの判断に関連する手法はＳＴＡ動作例４での記載と同様である。

ＡＰ１があるＡＰに一部無線リソースを割当てた後にさらに他のＡＰにＴＸＯＰの一部無線リソースを割り当てるような場合には、ＳＴＡ動作例５（ＭＡＰＴＸＳＴＦの固定時間内に自ＳＴＡ宛てＴＦが来るかでＮＡＶを無視するかどうか判断）では、ＳＴＡは固定時間を超過するとＮＡＶをキャンセルできなくなり、自ＡＰからのＴＦに応答できない。これを回避するためには、例えば、共有元ＡＰは共有先ＡＰにＴＸＯＰの一部無線リソースを割り当てたら、以降は共有先ＡＰを減らすことはできても増やすことはできないようにする。

ＳＴＡ動作例５ａ（ＳＩＦＳ以上のＣＣＡアイドル期間の有無を条件とする場合）では全ての物理パケットが観測できたなら、自ＡＰからのＴＦに応答できないという問題はない。またＳＴＡ動作例５ｂ（自ＡＰが他のＡＰからＴＸＯＰの一部無線リソースを割り当てられたと判断できる場合にＮＡＶ無視）やＳＴＡ動作例５ｃ（ＮＡＶの終了時点を使って判断する場合）では自ＡＰからのＴＦに応答できないという問題はない。

ＣＴＳ－ｔｏ－ｓｅｌｆフレームの送信がＴＸＯＰの一部無線リソースを他のＡＰに共有するフレームの送信前にあったとしても、ＳＴＡ動作例５（ＭＡＰＴＸＳＴＦの固定時間内に自ＳＴＡ宛てＴＦが来るかでＮＡＶを無視するかを判断）ではＳＴＡ２１、ＳＴＡ２２は例えば固定時間にＣＴＳ－ｔｏ－ｓｅｌｆフレームを格納する物理パケットの占有時間とＴＸＯＰの一部無線リソースを他のＡＰに共有するフレームの送信前のＳＩＦＳも含めるようにすれば、自ＡＰからのＴＦに応答できる。ＭＡＰＴＸＳＴＦ前のＣＴＳ－ｔｏ－ｓｅｌｆフレームとのフレーム間隔がＳＩＦＳだとすると、ＣＴＳ－ｔｏ－ｓｅｌｆフレーム送信に必要な時間＋ＳＩＦＳまでカバーできるように固定時間は設定される。固定時間には、３×ＳＩＦＳ＋ＣＴＳ－ｔｏ－ｓｅｌｆを格納する物理パケットの占有時間＋ＴＸＳＲＳＰを格納する物理パケットの占有時間＋スロット時間が必要である。ＣＴＳ－ｔｏ－ｓｅｌｆの送信もあることを加味して、固定時間としては、長めの値を規定しておけばよい。しかし、特別な場合には、ＳＴＡ２１、ＳＴＡ２２は自ＡＰからのＴＦに応答できない。例えば、ＴＸＯＰの一部無線リソースを他のＡＰに共有するフレームの送信前に共有元ＡＰと他のＳＴＡとの間で全ＴＸＯＰを保護するようなフレーム交換を実施する場合には、ＳＴＡ２１、ＳＴＡ２２はその後の自ＡＰのＴＦに応答できない。これを解決するためにはＳＴＡ動作例４での同様な問題時の回避方法がある。なお、ＳＴＡ動作例５ａ（ＳＩＦＳ以上のＣＣＡアイドル期間の有無をＮＡＶを無視して応答する条件とする場合）やＳＴＡ動作例５ｂ（自ＡＰが他のＡＰからＴＸＯＰの一部無線リソースを割り当てられたと判断できる場合にＮＡＶ無視）、ＳＴＡ動作例５ｃ（ＮＡＶの終了時点を使ってＮＡＶを無視するかどうかを判断する場合）ではこのような場合でも、ＳＴＡ２１、ＳＴＡ２２は自ＡＰからのＴＦに応答できないとう問題はない。

＜ＳＴＡ動作例６：３つのＮＡＶ＞
ＳＴＡ動作例６では、ＳＴＡに従来のｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶに加えて新たに３つ目のＮＡＶ、ＥＳＳＮＡＶを導入する。ＥＳＳＮＡＶは、受信したフレーム／物理パケットが自ＢＳＳ内のフレーム／物理パケットではない（つまりｉｎｔｒａ－ＢＳＳＮＡＶは適用されない）が、同一ＥＳＳ内のフレーム／物理パケットであると判断した場合に設定するＮＡＶである。従来の２つのＮＡＶを持つＳＴＡは、受信したフレーム／物理パケットが自ＢＳＳ内のフレーム／物理パケットではない場合には、ｂａｓｉｃＮＡＶを設定していた。ＳＴＡ動作例６では、ＳＴＡは自ＢＳＳ外のフレーム／物理パケットに対し同一ＥＳＳ内かどうかの識別を追加し、自ＢＳＳ外のフレーム／物理パケットが同一ＥＳＳ内のものであると判断した場合にはＥＳＳＮＡＶを設定する、そう判断しなかった場合には従来のｂａｓｉｃＮＡＶを設定する、という動作を行う。図２４はＳＴＡ動作例６におけるＳＴＡのＮＡＶ設定の一例を示すフローチャートである。ＳＴＡは受信したフレーム／物理パケットが自ＢＳＳ内のフレーム／物理パケットであるかを判断する（ステップＳ１０２）。ＳＴＡは、受信したフレーム／物理パケットが自ＢＳＳ内のフレーム／物理パケットであると判断した場合、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する（ステップＳ１０４）。ＳＴＡは、受信したフレーム／物理パケットが自ＢＳＳ内のフレーム／物理パケットではあると判断しない場合、受信したフレーム／物理パケットが自ＥＳＳ内のフレーム／物理パケットであるかを判断する（ステップＳ１０６）。ＳＴＡは、受信したフレーム／物理パケットが自ＥＳＳ内のフレーム／物理パケットであると判断した場合、ＥＳＳＮＡＶを設定する（ステップＳ１０８）。ＳＴＡは、受信したフレーム／物理パケットが自ＥＳＳ内のフレーム／物理パケットであると判断しない場合、ｂａｓｉｃＮＡＶを設定する（ステップＳ１１０）。

ＥＳＳＮＡＶの設定に用いる判断は、前述のｉｎｔｒａ－ＢＳＳＮＡＶを設定する方法と基本的に同様である。ＳＴＡ動作例６でｉｎｔｒａ－ＢＳＳＮＡＶの設定判断に使う情報は、前述のｉｎｔｒａ－ＢＳＳＮＡＶの設定判断に使う情報とは異なる。

ＳＴＡ動作例６では、ＳＴＡは物理パケットを受信して、復号でき、物理パケットに格納されているＭＡＣフレームからアドレスフィールドを抽出できれば、それらのアドレスフィールドに従い、受信したフレームが自ＥＳＳ内のフレームかを判断する。もしくはそのＭＡＣフレームにＴＡはないがＲＡがある場合にはそのＲＡに記載された値とその前に送信権を獲得したＴＸＯＰｈｏｌｄｅｒのＭＡＣアドレスとの関係から、受信したフレームが自ＥＳＳ内のフレームかを判断する。ＳＴＡは接続するＡＰから、自ＥＳＳ内の他のＡＰのＭＡＣアドレス（すなわち自ＥＳＳ内の他のＢＳＳのＢＳＳＩＤ）を予め取得している。

また、ＳＴＡは受信した物理パケットを復号できない場合には、物理パケットのヘッダから受信した物理パケットが同一ＥＳＳ内の通信によるものであるかを判断し、それに基づきＥＳＳＮＡＶを設定する。この判断のためには、例えば、前述のようにＢＳＳｃｏｌｏｒを用いる方法がある。あるいは前述のようにＢＳＳＣｏｌｏｒフィールドにＥＳＳｃｏｌｏｒ値も入れられるようにしてもよい。あるいは、ＢＳＳＣｏｌｏｒフィールドとは別にＥＳＳＣｏｌｏｒフィールドを追加した新規物理パケットを定義する場合には、ＥＳＳＣｏｌｏｒフィールドの値に基づき判断するようにしてもよい。この場合、いずれかのＮＡＶを設定する値としては物理ヘッダのＴＸＯＰフィールドの値を用いる。ＢＳＳＣｏｌｏｒフィールドで特別にＥＳＳｃｏｌｏｒを定義せずに、受信したパケットが同一ＥＳＳ内の通信に用いられている物理パケットであることを識別するためには、ＳＴＡは従来の自ＢＳＳのＢＳＳｃｏｌｏｒを把握するだけでなく、同一ＥＳＳ内の他のＢＳＳのＢＳＳｃｏｌｏｒも把握しておく必要がある。ＳＴＡは接続するＡＰからこれらの情報を取得すればよい。ＡＰが同一ＥＳＳ内の他のＢＳＳのＢＳＳｃｏｌｏｒを把握するためには、その前段として同一ＥＳＳ内の他のＡＰから例えばビーコンフレームやＡＰ間に用いるアクションフレームなどを介して同一ＥＳＳ内の他のＢＳＳのＢＳＳｃｏｌｏｒの通知を受けるようにすればよい。例えば同一ＥＳＳ内であるＡＰが同一ＥＳＳ内の他の複数のＡＰで用いるＢＳＳｃｏｌｏｒを通知できるようにすれば、ＡＰが他のＡＰから個々にＢＳＳｃｏｌｏｒを取得する必要がなく、効率化が図れる。

ＥＳＳｃｏｌｏｒを特別に定義し、ＢＳＳＣｏｌｏｒフィールド内で通知できるようにする場合は、ＢＳＳＣｏｌｏｒフィールド値に基づき自ＢＳＳのＢＳＳｃｏｌｏｒかを確認する（ステップＳ１０２）。ＢＳＳＣｏｌｏｒフィールドに自ＢＳＳのＢＳＳｃｏｌｏｒが設定されていなければ、ＢＳＳＣｏｌｏｒフィールドに自ＥＳＳのＥＳＳｃｏｌｏｒが設定されているかを確認する（ステップＳ１０６）。ＥＳＳＣｏｌｏｒフィールドをＢＳＳＣｏｌｏｒフィールドとは別に設けた新規物理パケットの場合には、まずＢＳＳＣｏｌｏｒフィールドに自ＢＳＳのＢＳＳｃｏｌｏｒが設定されているかを判断し（ステップＳ１０２）、自ＢＳＳのＢＳＳｃｏｌｏｒが設定されていないと判断した場合に、次にＥＳＳＣｏｌｏｒフィールドに自ＥＳＳのＥＳＳｃｏｌｏｒが設定されているかを判断する（ステップＳ１０６）。このＥＳＳｃｏｌｏｒも同一ＥＳＳ内のＡＰ間で何らかの手法によって決定し、共有し、各ＡＰが接続するＳＴＡに周知しておく必要がある。その上で、ＳＴＡはｂａｓｉｃＮＡＶが設定されていなければ、自ＡＰからのＴＦに応答できる。

図２５はこのＳＴＡ動作例６の一例を説明するための図である。ＡＰ２に接続するＳＴＡ２１とＳＴＡ２２は、ＡＰ１がＡＰ２と他のＡＰに対して送信するＭＡＰＴＸＳＴＦを受信する。この場合のＭＡＰＴＸＳＴＦのＲＡはブロードキャストアドレスであり、ＴＡはＡＰ１に設定されている。そこで、ＳＴＡ２１とＳＴＡ２２はＭＡＰＴＸＳＴＦのＴＡが自ＢＳＳのＢＳＳＩＤ（すなわち自ＡＰのＭＡＣアドレス）ではないが、同一ＥＳＳ内として認識できる他のＢＳＳのＢＳＳＩＤの一つ（すなわち同一ＥＳＳ内として認識できる自ＡＰ以外のＡＰのＭＡＣアドレス）であることを検出する。そこで、ＳＴＡ２１とＳＴＡ２２はＭＡＰＴＸＳＴＦを格納する物理パケットの無線媒体上での終了とともに当該物理パケットの物理ヘッダのＴＸＯＰフィールド値を用いてＥＳＳＮＡＶを設定する。

その後、ＡＰ２はＡＰ１に対し、ＭＡＰＴＸＳＴＦへの応答としてＴＸＳＲＳＰをＭＵ送信する。その際にＡＰ２はＭＵ送信する物理パケットの物理ヘッダのＢＳＳＣｏｌｏｒフィールドに例えばＥＳＳｃｏｌｏｒを入れる。例えばＡＰはＡＰ間通信を行う場合に、使用する物理パケットにＢＳＳＣｏｌｏｒフィールドがあれば当該フィールドにはＥＳＳｃｏｌｏｒを入れる、という判断をする。ＳＴＡ２１とＳＴＡ２２はＭＵ送信されたＴＸＳＲＳＰの物理ヘッダのＢＳＳＣｏｌｏｒフィールドに、自ＢＳＳのＢＳＳｃｏｌｏｒではないが、自ＥＳＳのＥＳＳｃｏｌｏｒが入れられていることを検出し、このＴＸＳＲＳＰを格納する物理パケットの物理ヘッダのＴＸＯＰフィールド値を抽出する。先にＭＡＰＴＸＳＴＦによって設定したＥＳＳＮＡＶよりもＴＸＳＲＳＰによって設定するＮＡＶの方が長い場合には、ＳＴＡ２１とＳＴＡ２２はＴＸＳＲＳＰを格納する物理パケットの物理ヘッダのＴＸＯＰフィールド値でＥＳＳＮＡＶを上書きする。例えばＡＰ２はＴＸＳＲＳＰのＤｕｒａｔｉｏｎ／ＩＤフィールド、また物理パケットのＴＸＯＰフィールドに、ＭＡＰＴＸＳＴＦによって設定されるＮＡＶと同一の値、すなわちＡＰ１が取得したＴＸＯＰの終了時点までをカバーする値を設定する。このような場合には、ＳＴＡ２１とＳＴＡ２２で設定されるＥＳＳＮＡＶは、ＭＡＰＴＸＳＴＦによって、ＡＰ１が取得したＴＸＯＰの終了時点まで設定される。そのため、ＭＡＰＴＸＳＴＦによってＥＳＳＮＡＶを上書きする必要はない。

その後、ＳＴＡ２１とＳＴＡ２２がＡＰ２からＴＦを受信する段階では、ＳＴＡ２１とＳＴＡ２２ではＥＳＳＮＡＶしか設定されていないとする。ＳＴＡ２１とＳＴＡ２２はＡＰ２からのＴＦを受信すると、ＴＦが自ＢＳＳ内のフレームであることを認識した上で、ＴＦを受信しつつ自ＳＴＡはＴＸＯＰｈｏｌｄｅｒではないことから、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。この場合に、ＳＴＡ２１とＳＴＡ２２は（さらにＡＰ２も）ＴＸＯＰｈｏｌｄｅｒはＥＳＳＮＡＶを設定したＴＦがＡＰ１からのＴＦであると認識する。ＴＦ受信時にＥＳＳＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶは設定されているが、ｂａｓｉｃＮＡＶは設定されていないため、ＳＴＡ２１とＳＴＡ２２はＴＦに対する応答としてフレーム送信ができる。

ＳＴＡ動作例６であれば、ＡＰ１が自ＢＳＳや他のＡＰにＴＸＯＰの一部無線リソースを割当て、その後、ＡＰ２あるいはＡＰ２を含む複数のＡＰにＴＸＯＰの一部無線リソースを割当てる場合においても、ＳＴＡ２１とＳＴＡ２２は他のＡＰにＴＸＯＰの一部無線リソースが割り当てられている時間は従来のｂａｓｉｃＮＡＶの代わりにＥＳＳＮＡＶが設定されることになる。そのため、ＡＰ１やそのＴＸＯＰの一部無線リソースを割り当てられたＡＰ（ＡＰ２を含む）でそのＴＸＯＰ全体を保護するＤｕｒａｔｉｏｎ／ＩＤフィールド、またＴＸＯＰフィールドを設定しても問題ない。つまりその期間内にＡＰ２からＴＦを受信してもＳＴＡ２１とＳＴＡ２２は応答送信できる。

またＡＰ１がまずＣＴＳ－ｔｏ－ｓｅｌｆフレームなどでＴＸＯＰを保護する動作を行っても、ＳＴＡ２１とＳＴＡ２２は従来のｂａｓｉｃＮＡＶの代わりにＥＳＳＮＡＶを設定することになり、その後ＡＰ２からＴＦを受信しても応答送信ができる。

図２６はｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、さらにＥＳＳＮＡＶの３つのＮＡＶがどのような設定の場合にＳＴＡで自ＡＰからのＴＦに応答できるか（Ｔｒｉｇｇｅｒｆｒａｍｅ応答＠ｎｏｎ－ＡＰＳＴＡ）を示す。また、図２６は合わせて先のＡＰ動作例４で示したＡＰで他のＡＰからＴＸＯＰの一部無線リソースを割り当てられた場合に応答送信できる条件（ＭＡＰ応答＠ＡＰ）も合わせて記載してある。ＳＴＡ側では、従来ｂａｓｉｃＮＡＶが設定されていたＭＡＰ間での通信がＥＳＳＮＡＶに置き換わることで、自ＡＰからのＴＦ送信に応答できるようになる。

（１）ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、及びＥＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＴＦ応答は不可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できない）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（２）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０ではなく（すなわち、設定されている）、ＥＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＴＦ応答は不可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できない）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（３）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶが０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＴＦ応答は不可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できない）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（４）ｂａｓｉｃＮＡＶが０ではなく（すなわち、設定されている）、ｉｎｔｒａ－ＢＳＳＮＡＶとＥＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は不可であり、ＴＦ応答は不可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できない）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（５）ｂａｓｉｃＮＡＶが０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶとＥＳＳＮＡＶがともに０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＴＦ応答は可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できる）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（６）ｂａｓｉｃＮＡＶとＥＳＳＮＡＶがともに０であり（すなわち、設定されていない）、ｉｎｔｒａ－ＢＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＴＦ応答は可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できる）、ＭＡＰ送信は不可（すなわち、ＡＰは割り当てられた無線リソースを使用できない）である。

（７）ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶがともに０であり（すなわち、設定されていない）、ＥＳＳＮＡＶが０ではない（すなわち、設定されている）場合、送信権の獲得は不可であり、ＴＦ応答は可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できる）、ＭＡＰ送信は可（すなわち、ＡＰは割り当てられた無線リソースを使用できる）である。

（８）ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、及びＥＳＳＮＡＶがともに０である（すなわち、設定されていない）場合、送信権の獲得は可であり、ＴＦ応答は可（すなわち、ＳＴＡは割り当てられた無線リソースを使用できる）、ＭＡＰ送信は可（すなわち、ＡＰは割り当てられた無線リソースを使用できる）である。

このＳＴＡ動作例６に、ＳＴＡ動作例２～ＳＴＡ動作例４のように、ＥＳＳＮＡＶを設定する際に受信したフレームのフレーム種別をＭＡＰＴＸＳＴＦに制限したり、さらにその割当先に自ＡＰが含まれている制限を加えたりしてもよい。しかし、そうすると、上記で示した、ＡＰ１が時分割で異なるＡＰ（またはＡＰ群）にＴＸＯＰの一部無線リソースを割当てていく場合に後で割り当てられたＡＰ下のＳＴＡでｂａｓｉｃＮＡＶが設定されてしまうため割り当てられた無線リソースを利用できない、ＣＴＳ－ｔｏ－ｓｅｌｆフレームによりｂａｓｉｃＮＡＶが設定されてしまうため割り当てられた無線リソースを利用できない、という問題が生じ、前述のような何らかの対策や制限が必要になってくる。

＜ＳＴＡ動作例７：ｂａｓｉｃＮＡＶをｔｒｕｎｃａｔｅするフレームの導入＞
ＳＴＡ動作例１～６まではＳＴＡ側でのＮＡＶに対する操作を従来と変えることで、ＭＡＰ通信下で自ＡＰからのＴＦに対して応答送信できるようにした。しかし、ＳＴＡ動作例７では、従来の手法でｂａｓｉｃＮＡＶ設定により自ＡＰからのＴＦに対して応答送信できない状況をｂａｓｉｃＮＡＶを０にリセットするフレームをＡＰ側で送信することで解決するというものである。ＮＡＶをリセットすることは、別の表現ではＴＸＯＰを断ち切る（ｔｒｕｎｃａｔｅ）と言う。

ＮＡＶをリセットするフレームとしてＣＦ－Ｅｎｄフレームがある。ＣＦ－Ｅｎｄフレームは制御フレームの一種である。この従来のＣＦ－Ｅｎｄフレームを受信した場合の動作をまず説明する。

＜ＣＦ－Ｅｎｄの従来動作＞
図２７は、ＣＦ－Ｅｎｄフレームのフォーマットの一例を示す。ＣＦ－ＥｎｄフレームはＦｒａｍｅＣｏｎｔｒｏｌフィールド、Ｄｕｒａｔｉｏｎフィールド、２つのアドレスフィールド、ＦＣＳから構成される。Ｄｕｒａｔｉｏｎフィールドは０にする。最初のアドレスフィールドはＲＡフィールドで、受信先のアドレスフィールドを入れるが、ＣＦ－Ｅｎｄフレームではブロードキャストアドレスが入る。２つ目のアドレスフィールドはＢＳＳＩＤ（ＴＡ）フィールドで、ＣＦ－Ｅｎｄフレームを送信するＳＴＡ（ＡＰを含む）のＭＡＣアドレスが入る。

１つのＮＡＶのみを管理するＳＴＡ（ＡＰを含む）は、ＣＦ－Ｅｎｄフレームを受信すると、ＮＡＶが設定されている場合はそのＮＡＶをリセットする。ここで、具体的にＮＡＶをリセットするタイミングはＣＦ－Ｅｎｄフレームを格納する物理パケットの終わりである。なお、８０２．１１ａｘ規格対応のＡＰ（ＨＥＡＰ）で１つのＮＡＶしか管理しない場合には、設定されているＮＡＶが最後に更新された際のフレームが自ＢＳＳ内の物理パケットによるもので、ＣＦ－Ｅｎｄフレームを格納する物理パケットが他ＢＳＳからのものと判断した場合でなければ、ＮＡＶをリセットすべき、となっている。乃至は逆で設定されているＮＡＶが最後に更新された際のフレームが他ＢＳＳからの物理パケットによるもので、ＣＦ－Ｅｎｄフレームを格納する物理パケットが自ＢＳＳ内のものと判断した場合でなければ、ＮＡＶをリセットすべき、となっている。

ｂａｓｉｃＮＡＶとｉｎｔｒａ－ＢＳＳＮＡＶの２つのＮＡＶを管理するＳＴＡ（ＡＰを含む）はＣＦ－Ｅｎｄフレームを受信すると、ＣＦ－Ｅｎｄフレームを格納する物理パケットが他ＢＳＳからのものであると判断した場合には、ｂａｓｉｃＮＡＶをリセットし、ＣＦ－Ｅｎｄフレームを格納する物理パケットが自ＢＳＳ内のものであると判断した場合にはｉｎｔｒａ－ＢＳＳＮＡＶをリセットする。

物理パケットが自ＢＳＳ内のものか、他ＢＳＳからのものかの判断は、前述のように物理パケットの物理ヘッダのＢＳＳＣｏｌｏｒフィールドや、物理パケット内に格納されたＭＡＣフレームを復号できる場合には、そのＭＡＣフレームのアドレスフィールドに基づき（またフレーム種別によってはアドレスフィールドが制限されている関係で過去の履歴も加味して）行う。ＣＦ－Ｅｎｄフレームを抽出できた場合には、ＣＦ－ＥｎｄフレームのＢＳＳＩＤ（ＴＡ）フィールドに記載されたＡＰのＭＡＣアドレスが自ＡＰのＭＡＣアドレスと同一であるか比較することにより、物理パケットが自ＢＳＳ内のものか、他ＢＳＳからのものか判断すればよい。

前述のＳＴＡ動作例６のように、ｂａｓｉｃＮＡＶ、ｉｎｔｒａ－ＢＳＳＮＡＶ、ＥＳＳＮＡＶの３つのＮＡＶを管理するＳＴＡはＣＦ－Ｅｎｄフレームを受信すると、ＣＦ－Ｅｎｄフレームを格納する物理パケットが自ＢＳＳ内のものであると判断した場合にはｉｎｔｒａ－ＢＳＳＮＡＶをリセットし、ＣＦ－Ｅｎｄフレームを格納する物理パケットが自ＢＳＳ内のものではないが同一ＥＳＳ内のものであると判断した場合にはＥＳＳＮＡＶをリセットし、ＣＦ－Ｅｎｄフレームを格納する物理パケットが自ＢＳＳ内のものでも同一ＥＳＳ内のものでもない、すなわち同一ＥＳＳ外からのものであると判断した場合にはｂａｓｉｃＮＡＶをリセットするようにすればよい。

同一ＥＳＳ内であるかどうかは自ＢＳＳ内かを判断する場合と同様に、物理パケットの物理ヘッダのＢＳＳＣｏｌｏｒフィールドや、物理パケット内に格納されたＭＡＣフレームを復号できる場合にはそのＭＡＣフレームのアドレスフィールドなどに基づき判断すればよい。

ＳＴＡ動作例７の動作説明に戻る。ＳＴＡ動作例７として、ここでは、２つのＮＡＶを管理するＳＴＡに対して、ｂａｓｉｃＮＡＶをリセットするフレームを使ってＳＴＡがＭＡＰ下で自ＡＰからのＴＦに応答送信できるようにする方法を示す。

従来のＣＦ－Ｅｎｄフレームでは、ＢＳＳＩＤ（ＴＡ）フィールドには自ＡＰのＭＡＣアドレスが入る。従ってＣＦ－Ｅｎｄフレームは２つのＮＡＶを管理する場合には、自ＢＳＳのＮＡＶ、すなわちｉｎｔｒａ－ＢＳＳＮＡＶをリセットするために送信するという位置づけになり、ｂａｓｉｃＮＡＶはリセットされずに残る。あるＢＳＳのＡＰが他のＡＰのＭＡＣアドレスをＢＳＳＩＤ（ＴＡ）フィールドに設定して送信することはできない。また仮に他のＡＰのＭＡＣアドレスをＢＳＳＩＤ（ＴＡ）フィールドに設定して送信できたとしても、従来のＣＦ－Ｅｎｄフレームでは他ＢＳＳからと判断した場合にｂａｓｉｃＮＡＶをリセットするため、これではＴＸＯＰの一部無線リソースを共有元ＡＰから割り当てられたＡＰやそれに接続するＳＴＡだけでなく、周辺の全てのＡＰやそれに接続するＳＴＡまでｂａｓｉｃＮＡＶをリセットしてしまう。

そこで、ＳＴＡ動作例７ではｂａｓｉｃＮＡＶがリセットされるＡＰやＳＴＡ（リセット対象）を限定するフレームを新たに設ける。このフレームを便宜的にＣＦ－Ｅｎｄ２フレームとする。ＣＦ－Ｅｎｄ２フレームはＣＦ－Ｅｎｄフレームと同様、制御フレームの一種として扱う。ＣＦ－Ｅｎｄ２フレームはＣＦ－Ｅｎｄフレームとは異なるサブタイプとする。

ＣＦ－Ｅｎｄ２フレームは、フォーマットとしてはＣＦ－Ｅｎｄフレームと同様でよい。Ｄｕｒａｔｉｏｎフィールドは０に設定する。但し、ＣＦ－Ｅｎｄフレームとは異なり、ＣＦ－Ｅｎｄ２フレームではＲＡフィールドにｂａｓｉｃＮＡＶのリセット対象のＢＳＳのＢＳＳＩＤを指定する。ＲＡフィールドはＢＳＳＩＤを指定するフィールドとなるため、ＲＡフィールドと表す代わりにＢＳＳＩＤ（ＲＡ）フィールドと表すようにしてもよい。ＲＡフィールドに指定された値と同一のＢＳＳＩＤを持つＢＳＳに所属するＳＴＡは、ｂａｓｉｃＮＡＶが設定されていたら、それをリセットする動作を行う。仮に対象のＢＳＳのＳＴＡでｉｎｔｒａ－ＢＳＳＮＡＶが設定されていても、それはリセットせずに残す。例えばＣＦ－Ｅｎｄ２フレームの送信はＡＰからのみに制限するようにする。その場合、送信するＡＰはＢＳＳＩＤ（ＴＡ）フィールドに自分のＭＡＣアドレスを設定する。受信したＳＴＡはＢＳＳＩＤ（ＴＡ）フィールドが自ＡＰのＭＡＣアドレスである場合にのみ、ｂａｓｉｃＮＡＶをリセットするようにしてもよい。あるいは、同一ＥＳＳ内であるＡＰから他のＡＰのＢＳＳを対象にしたＣＦ－Ｅｎｄ２フレームも送信するような使い方を許容するのであれば、受信したＳＴＡはＢＳＳＩＤ（ＴＡ）フィールドが同一ＥＳＳ内の他のＡＰのＭＡＣアドレスである場合も、ｂａｓｉｃＮＡＶをリセットするようにすればよい。この場合、ＳＴＡは前述の手法などにより予め同一ＥＳＳ内にある自ＡＰ以外のＡＰのＭＡＣアドレスを把握しておく。なお、ＣＦ－Ｅｎｄ２フレームではＲＡフィールドでｂａｓｉｃＮＡＶをリセットさせる対象となるＢＳＳを指定するだけでＢＳＳＩＤ（ＴＡ）フィールドを入れないフォーマットにすることも可能である。この場合、受信したＳＴＡはＲＡフィールドが自ＢＳＳのＢＳＳＩＤと一致していればｂａｓｉｃＮＡＶをリセットする。しかし、これではどのＳＴＡでも他のＳＴＡのｂａｓｉｃＮＡＶをリセットできてしまう。そのため、ＣＦ－Ｅｎｄ２フレームを受信したＳＴＡは、ＢＳＳＩＤ（ＴＡ）フィールドに基づきフレームの送信元アドレスを確認し、ＢＳＳＩＤ（ＴＡ）フィールドがある条件を満たした場合（例えば前述のように自ＡＰである場合、あるいは自ＥＳＳのＡＰである場合）にのみ、ｂａｓｉｃＮＡＶをリセットする動作にしてもよい。ＣＦ－Ｅｎｄ２フレームを受信したＳＴＡで同一ＥＳＳ内のＡＰであるかを簡単に把握するために、ＣＦ－Ｅｎｄ２フレームにさらにＥＳＳの識別子を入れるフィールドを追加する、あるいはＴＡフィールドの代わりにこのＥＳＳＩＤを入れるフィールドを入れるようにしてもよい。ＥＳＳの識別子は、前述のように通常はＳＳＩＤである。そこでＳＳＩＤを制御フレームであるＣＦ－Ｅｎｄ２フレームに入れる場合には、ＳＳＩＤは可変長の構成であるため、例えばＡＰ動作例１で記載したようにフレームボディ部の最後に入れるようにする。あるいは、長さ情報とＳＳＩＤ値を入れる構成が許容されるなら、ＳＳＩＤを長さ情報とともに入れる。あるいはＥＳＳの識別子として、ＳＳＩＤとは別に６オクテット固定のＥＳＳＩＤを定義し、このＥＳＳＩＤを用いる。

図２８はＳＴＡ動作例７の一例を説明するための図である。ＳＴＡ動作例７は、このＣＦ－Ｅｎｄ２フレームを利用し、ＭＡＰ下でＳＴＡが自ＡＰからのＴＦに対し送信応答できるようにする例である。ＡＰ１がＡＰ２と他のＡＰのＭＡＰＴＸＳＴＦを送信する。ＭＡＰＴＸＳＴＦのＲＡフィールドはブロードキャストアドレスであり、ＴＡフィールドはＡＰ１に設定されているとする。この場合、ＡＰ２に接続するＳＴＡ２１とＳＴＡ２２はＭＡＰＴＸＳＴＦを格納する物理パケットを復号できる。ＳＴＡ２１とＳＴＡ２２は、ＭＡＰＴＸＳＴＦを抽出できても、ＲＡフィールドもＴＡフィールドも自ＢＳＳのＢＳＳＩＤではないため、受信した物理パケットは他ＢＳＳの物理パケットであると判断し、ｂａｓｉｃＮＡＶを設定する。

その後、ＡＰ２がＡＰ１からのＭＡＰＴＸＳＴＦに対してＴＸＳＲＳＰをＡＰ１に対してＭＵ送信する。ＭＵ送信された物理パケットの物理ヘッダにＡＰ２が構成するＢＳＳのＢＳＳｃｏｌｏｒが記載されていない場合、ＳＴＡ２１とＳＴＡ２２は当該物理パケットも他ＢＳＳからの物理パケットであると判断し、物理ヘッダのＴＸＯＰフィールド値をｂａｓｉｃＮＡＶとして設定するかを判断するため、物理ヘッダのＴＸＯＰフィールド値によって設定される期間と先のＭＡＰＴＸＳＴＦで設定されたｂａｓｉｃＮＡＶの期間とを比較する。ＡＰ２が物理ヘッダのＴＸＯＰフィールド値にＭＡＰＴＸＳＴＦでのＤｕｒａｔｉｏｎ／ＩＤフィールド値からＳＩＦＳとＴＸＳＲＳＰフレームを格納する物理パケットの占有時間長を差し引いた値を設定、すなわちＭＡＰＴＸＳＴＦによって獲得したＴＸＯＰと同じ期間を保護するように設定している場合、ＳＴＡ２１とＳＴＡ２２ですでに設定されているｂａｓｉｃＮＡＶの終了時点とＴＸＳＲＳＰフレームを格納する物理パケットにより示されるＮＡＶ値の終了時点は同じであるため、ＳＴＡ２１とＳＴＡ２２はｂａｓｉｃＮＡＶを上書きする必要はない。

次に、ＡＰ２は割り当てられた無線リソースをＳＴＡ２１とＳＴＡ２２に再割り当てするが、その前にＣＦ－Ｅｎｄ２フレームを送信してＳＴＡ２１とＳＴＡ２２のｂａｓｉｃＮＡＶをリセットする。ここでｂａｓｉｃＮＡＶのリセット対象となるＢＳＳはＡＰ２のＢＳＳであるので、ＡＰ２は、ＡＰ２のＢＳＳのＢＳＳＩＤ（便宜的にこれをＢＳＳＩＤ２と図中では表している。ＢＳＳＩＤ２はＡＰ２のＭＡＣアドレスである）をＣＦ－Ｅｎｄ２フレームのＲＡフィールドに設定する。図２８においてＣＦ－Ｅｎｄ２フレームに付した括弧内にはＲＡフィールドの設定状況、すなわちＢＳＳＩＤ２に設定してあることが示されている。ＡＰ２はＣＦ－Ｅｎｄ２フレームをＡＰ１から割り当てられた無線リソース内で送信する。ＳＴＡ２１とＳＴＡ２２は前述の説明に従い、ＣＦ－Ｅｎｄ２フレームを受信し、自ＢＳＳのＢＳＳＩＤが指定されていることを把握すると、設定されていたｂａｓｉｃＮＡＶをＣＦ－Ｅｎｄ２フレームを格納する物理パケットの終わりで０にリセットする。

ＡＰ２はＣＦ－Ｅｎｄ２フレームを送信後、ＳＴＡ２１とＳＴＡ２２に無線リソースを再割り当てするＴＦを送信する。ＴＦのＲＡはブロードキャストアドレスであり、ＴＡがＡＰ２に設定されているため、ＳＴＡ２１とＳＴＡ２２はＴＦを格納する物理パケットは自ＢＳＳ内の物理パケットであると判断し、その上でＴＸＯＰｈｏｌｄｅｒではなく受信したフレームがＴＦであることから、ｉｎｔｒａ－ＢＳＳＮＡＶを設定する。ＳＴＡ２１とＳＴＡ２２は、設定したＮＡＶがｉｎｔｒａ－ＢＳＳＮＡＶであることから、ＴＦに対し、ＳＩＦＳ後に例えばデータフレームを送信するなど応答することができる。

図２８ではＡＰ２がＣＦ－Ｅｎｄ２フレームを送信したが、ＭＡＰＴＸＳＴＦがＡＰ２以外のＡＰにも送信されているとしているので、ＭＡＰＴＸＳＴＦを受信した他のＡＰでもＭＵ送信でＴＸＳＲＳＰを送信した後に、各々割り当てられた無線リソース内でＣＦ－Ｅｎｄ２フレームを同様に送信する。ＡＰ同士が異なる周波数チャネルをＡＰ１から割り当てられているならば、周波数が異なるために、各ＡＰはＣＦ－Ｅｎｄ２フレームを各々割り当てられた周波数チャネルで送信できる。各ＡＰ下のＳＴＡはその割り当てられた周波数チャネル下で待ち受けしていれば、自ＡＰからのＣＦ－Ｅｎｄ２フレームを受信できる。

すでに無線リソースを割り当て済みということからは、共有先ＡＰがＣＦ－Ｅｎｄ２フレームを送信する方が適当ではあるが、共有元のＡＰ１がＣＦ－Ｅｎｄ２フレームを送信してもよい（図２８の破線）。この場合、ＡＰ１はＡＰ２のＢＳＳ（ＢＳＳＩＤ２）以外にも他のＡＰのＢＳＳにおいてもｂａｓｉｃＮＡＶをリセットするようにしなくてはならないため、ＣＦ－Ｅｎｄ２フレームとしては複数のＢＳＳＩＤを設定できるようにしなければならない。ＣＦ－Ｅｎｄ２フレームは制御フレームであるため、フレーム長が固定、あるいは前半のフィールド内で最終的なフレーム長を予め予想できる制約がなければいけないことを加味すると、例えば固定数のＲＡフィールドを設けるという方法がある。例えばＣＦ－ＥｎｄフレームではＲＡフィールドは１つであったところを、ＣＦ－Ｅｎｄフレーム２では４つのＲＡフィールド、例えばＲＡ１フィールド、ＲＡ２フィールド、ＲＡ３フィールド、ＲＡ４フィールド、を設け、最大４つのＢＳＳＩＤを指定できるようにする。ＢＳＳＩＤを指定するときには、これらのフィールドを前から順番に使い、使い切らない場合は例えば全て“０”でこれらのフィールド（例えば、６オクテット）を埋めるようにする。前述のように長さ情報を入れられる柔軟な制御フレームの構成が可能になれば、それでも問題はない。あるいは、複数のＢＳＳＩＤを指定するマルチキャストアドレスを予め設けておき、これをＲＡに入れる手法もある。これであれば、１つのフィールドで足りる。但し、対象となるＢＳＳＩＤの組み合わせが複数ある場合には、その分のアドレスを指定しておく必要があり、また予めＥＳＳ内で周知しておく必要がある。

また、各ＡＰが自ＢＳＳ下のＳＴＡに対してＣＦ－Ｅｎｄ２フレームを送信する場合、前述のようにＣＦ－Ｅｎｄ２フレームは新規フレームであることから従来のＳＴＡはそのサブタイプを認識せず、受信してもｂａｓｉｃＮＡＶをリセットするという期待動作をしない。なお、Ｄｕｒａｔｉｏｎフィールドは０に設定されているため、従来のＳＴＡでＣＦ－Ｅｎｄ２フレームを受信して新たにｂａｓｉｃＮＡＶが設定される心配はない。このＣＦ－Ｅｎｄ２フレームという新規フレームは、例えば新規拡張規格対応のＳＴＡで対応必須にする。そうすれば、新規拡張規格対応下でＭＡＰする際に限らず、ＣＦ－Ｅｎｄ２フレームを対象のＢＳＳ下のＳＴＡでｂａｓｉｃＮＡＶをリセットするために使うこともできる。この場合は、同一ＥＳＳ内で、あるＡＰが他のＡＰのＢＳＳでのｂａｓｉｃＮＡＶをリセットするためにＣＦ－Ｅｎｄ２フレームを送信することも可能になる。あるいは、新規拡張規格下でＣＦ－Ｅｎｄ２フレームへの対応をオプション機能とする。その場合は、ＳＴＡは自ＡＰにアソシエーション要求フレームや再アソシエーション要求フレームを送信する際に、ＣＦ－Ｅｎｄ２フレームへの対応可否を通知し、ＡＰでは配下のどのＳＴＡがＣＦ－Ｅｎｄ２フレームを受信してｂａｓｉｃＮＡＶをリセットできるか予め把握できる。あるいは、新規拡張規格内でＭＡＰをオプション機能とし、ＭＡＰ対応のＳＴＡではＣＦ－Ｅｎｄ２フレームへの対応も必須にする。この場合、ＳＴＡは自ＡＰに自ＡＰにアソシエーション要求フレームや再アソシエーション要求フレームを送信する際に、ＭＡＰ対応の可否を通知する。ＡＰは配下のどのＳＴＡがＭＡＰ対応か、を把握し、ＭＡＰ対応のＳＴＡのｂａｓｉｃＮＡＶをリセットする目的でＣＦ－Ｅｎｄ２フレームを送信できる。ＳＴＡがＭＡＰ対応の場合にＣＦ－Ｅｎｄ２フレームへの対応も必須にするなら、ＭＡＰ下で自ＡＰからのＴＦ送信に応答できるようにするために、他のＡＰがＳＴＡの属するＢＳＳを対象にＣＦ－Ｅｎｄ２フレームを送信することもできる。

ＣＦ－Ｅｎｄ２フレームがＭＡＰ対応のＳＴＡでのみｂａｓｉｃＮＡＶをリセットする動作をさせることになるのであれば、当然ＡＰでＭＡＰ下でＣＦ－Ｅｎｄ２フレームを送信し、さらにその後にＴＦを送信する場合に、ＴＦで無線リソースを割り当てる対象のＳＴＡとして、ＭＡＰ対応のＳＴＡのみ、言い換えればＣＦ－Ｅｎｄ２フレームに対応するＳＴＡのみに制限した方が、ＴＦに応答送信できるＳＴＡが増え、無線リソースの有効利用になる。

このＣＦ－Ｅｎｄ２フレームを使った方法では、例えばＡＰ１がＡＰ２と他のＡＰに一部無線リソースを割当てた後に、また別のＡＰ群に一部無線リソースを割当てた際には、ＳＴＡ２１とＳＴＡ２２など最初の割当て対象のＡＰ下のＳＴＡは再びＡＰ１からのＭＡＰＴＸＳＴＦを受信すること、またそれを受信しなくても新たな対象になったＡＰ群からのＴＸＳＲＳＰを受信することで、再びｂａｓｉｃＮＡＶを設定し、通信を妨害しない。またこの方法では、ＣＴＳ－ｔｏ－ｓｅｌｆフレームなどにより予めＴＸＯＰが保護されている状況でもＣＦ－Ｅｎｄ２フレームによってその保護を行っているｂａｓｉｃＮＡＶをキャンセルできるために、ＳＴＡで自ＡＰからのＴＦに応答送信できる。

なお、ＳＴＡ動作例７では、ＭＡＰに無関係なフレームで予めｂａｓｉｃＮＡＶが設定されていた場合に、ＣＦ－Ｅｎｄ２フレームによってそれが０で上書きされ、ＳＴＡが本来保護しなければならなかったフレーム送信を無視して送信してしまい、フレームの衝突が起こってしまう可能性がある。そこで、この問題を解決するＳＴＡ動作例７ａ、７ｂ、７ｃを以下に示す。

＜ＳＴＡ動作例７ａ：ＭＡＰＴＸＳＴＦによりｂａｓｉｃＮＡＶが設定され、かつそのＮＡＶ終了前にＣＦ－Ｅｎｄ２フレームを受信した場合のみ、ｂａｓｉｃＮＡＶをリセットする＞
解決方法の１つ目の動作例７ａでは、共有元ＡＰが共有先ＡＰに一部無線リソースを割り当てるフレーム（前の例に従えばＭＡＰＴＸＳＴＦ）によって、ＳＴＡはｂａｓｉｃＮＡＶを設定し、かつそのｂａｓｉｃＮＡＶが切れる、すなわち終了する前に、自ＢＳＳが対象となるＣＦ－Ｅｎｄ２フレームを受信した場合のみ、ｂａｓｉｃＮＡＶをリセットする。

ＳＴＡ動作例７ａの実装方法の例としては、ＭＡＰＴＸＦＴＦによってｂａｓｉｃＮＡＶが設定されたか否かのフラグをＳＴＡで持つようにすることがある。そして、ＳＴＡは他のフレームあるいは物理パケットでｂａｓｉｃＮＡＶが延長された場合にはそのフラグをオフ状態とする。また、ＭＡＰＴＸＳＴＦを受信した段階ですでにｂａｓｉｃＮＡＶが設定されていれば、ＳＴＡはそのフラグをオン状態とせず、オフ状態のままとする。その上で、自ＢＳＳが対象となるＣＦ－Ｅｎｄ２フレームを受信した際にこのフラグがオン状態であれば、ＳＴＡはｂａｓｉｃＮＡＶをリセットする。

但し、ＳＴＡ動作例７ａではＣＴＳ－ｔｏ－ｓｅｌｆフレームなどで予めＴＸＯＰが保護されている場合や他のＡＰに一部無線リソースが割り当てられた後に自ＡＰに一部無線リソースが割り当てられるような場合には、ＭＡＰＴＸＳＴＦより前にｂａｓｉｃＮＡＶが設定される状況になる。その場合にＳＴＡは自ＡＰからのＴＦに応答送信できない。そこで、上述ではＭＡＰＴＸＳＴＦを受信した段階ですでにｂａｓｉｃＮＡＶが設定されていれば、ＳＴＡはフラグをオン状態としないとしたが、ＭＡＰＴＸＳＴＦによって設定される想定のｂａｓｉｃＮＡＶと既存のｂａｓｉｃＮＡＶの終了時点が同一であれば、ＳＴＡはフラグをオン状態とするようにしてもよい。

＜ＳＴＡ動作例７ｂ：ＣＦ－Ｅｎｄ２フレームに残りのＴＸＯＰをカバーする値を設定し、ＳＴＡはｂａｓｉｃＮＡＶと終了時刻が同じであればｂａｓｉｃＮＡＶをリセット＞
解決方法の２つ目の動作例７ｂでは、ＣＦ－Ｅｎｄ２フレームに残りのＴＸＯＰをカバーする期間を記載し、ＳＴＡは自ＢＳＳが対象となるＣＦ－Ｅｎｄ２フレームを受信し、設定されているｂａｓｉｃＮＡＶの残り期間とＣＦ－Ｅｎｄ２フレームに記載されている期間が同一であれば、すなわちＣＦ－Ｅｎｄ２フレームに記載されている残りのＴＸＯＰの終了時点と設定されているｂａｓｉｃＮＡＶの終了時点が同じであれば、ｂａｓｉｃＮＡＶをリセットする。この残りのＴＸＯＰをカバーする期間はＣＦ－Ｅｎｄフレームの場合と同様に設けるＤｕｒａｔｉｏｎフィールドに設定してもよい。ＣＦ－ＥｎｄフレームではＤｕｒａｔｉｏｎフィールドには値として“０”を設定するように定義されているが、ＣＦ－Ｅｎｄ２フレームではＤｕｒａｔｉｏｎフィールドには“１”以上の値を設定できるようにするということになる。これによって従来のＳＴＡではＣＦ－Ｅｎｄ２フレームのＤｕｒａｔｉｏｎフィールドに設定された値をＮＡＶ設定候補として抽出するが、すでに設定されているＮＡＶと同時刻に終わるあるいは早く終わる場合にはＮＡＶの上書きは発生しないため、ＣＦ－Ｅｎｄ２フレームを受信したことによる影響は生じない。あるいは、Ｄｕｒａｔｉｏｎフィールドは残し、そこはＣＦ－Ｅｎｄフレームと同様にＮＡＶをリセットするという意味で“０”を設定するが、別に新たなフィールド、例えばＴＸＯＰＤｕｒａｔｉｏｎフィールド、を設けて、そこで残りのＴＸＯＰを記載するようにしてもよい。この場合の新たなフィールドも従来のＤｕｒａｔｉｏｎ／ＩＤフィールドと同様、２オクテットとするのが適当である。

共有先ＡＰがＣＦ－Ｅｎｄ２フレームを送信する場合は、共有元ＡＰが獲得したＴＸＯＰを共有元ＡＰが送信するフレーム、例えばＭＡＰＴＸＳＴＦ、により認識し、残りのＴＸＯＰをＣＦ－Ｅｎｄ２フレームに記載する。共有先ＡＰは共有元ＡＰがＴＸＯＰｈｏｌｄｅｒであることを認識しているので、共有元ＡＰが獲得したＴＸＯＰを把握できる。なお、従来はＴＸＯＰｈｏｌｄｅｒは同じＢＳＳ内の送信であった場合にのみ保持するものである。しかし、ＭＡＰ動作をするＡＰは他のＢＳＳの送信であっても少なくとも同一ＥＳＳ内の物理パケットについてはＴＸＯＰｈｏｌｄｅｒと認識して保持できるものとする。あるいは、ＭＡＰ動作をするＡＰは同一ＥＳＳ内のＡＰだけはＴＸＯＰｈｏｌｄｅｒと認識して保持できるようにするのでもよい。

共有元ＡＰがＣＥ－Ｅｎｄ２フレームを送信する場合は、当然共有元ＡＰ自身がＴＸＯＰｈｏｌｄｅｒであるので、残りのＴＸＯＰをＣＦ－Ｅｎｄ２フレームに記載できる。

ＳＴＡは自ＢＳＳを対象とするＣＦ－Ｅｎｄ２フレームを受信し、ｂａｓｉｃＮＡＶが設定されている場合にはそのｂａｓｉｃＮＡＶの値とＣＦ－Ｅｎｄ２フレームに記載されているＴＸＯＰの残り期間を比較し、終了時点が同じであれば、すなわち期間が同一であれば、ｂａｓｉｃＮＡＶをリセットする。

＜ＳＴＡ動作例７ｃ：ＣＦ－Ｅｎｄ２フレームにＴＸＯＰｈｏｌｄｅｒを入れ、ＳＴＡでの保持情報と合致したときにだけｂａｓｉｃＮＡＶをリセットする＞
解決方法の３つ目の動作例７ｃは、ＣＦ－Ｅｎｄ２フレームを送信するＡＰが認識しているＴＸＯＰｈｏｌｄｅｒをＣＦ－Ｅｎｄ２フレームに記載し、ＳＴＡはｂａｓｉｃＮＡＶを設定する際にそのＮＡＶを設定する元になったフレームのＴＸＯＰｈｏｌｄｅｒを抽出・保持しておく。すなわち、ＳＴＡはＮＡＶを設定する元になったフレームのＴＡをＴＸＯＰｈｏｌｄｅｒとして保持する。ＳＴＡは、そのフレームがＣＴＳ－ｔｏ－ｓｅｌｆフレームの場合はＲＡをＴＸＯＰｈｏｌｄｅｒとして保持する。ＳＴＡは、自ＢＳＳが対象となるＣＦ－Ｅｎｄ２フレームを受信し、ＣＦ－Ｅｎｄ２フレームに記載されたＴＸＯＰｈｏｌｄｅｒと設定されているｂａｓｉｃＮＡＶのＴＸＯＰｈｏｌｄｅｒとして保持しているＭＡＣアドレスが同一と判断すると、ｂａｓｉｃＮＡＶをリセットする。前述のように、従来はＳＴＡはＴＸＯＰｈｏｌｄｅｒを自ＢＳＳ内の送信であった場合にのみ保持するものである。しかし、ＭＡＰ動作下で自ＡＰからのＴＦに応答送信できるようにするＳＴＡは受信パケットが他のＢＳＳであっても少なくとも同一ＥＳＳ内の物理パケットであると判断すれば、受信パケットの送信元ＡＰをＴＸＯＰｈｏｌｄｅｒと認識して保持できるものとする。あるいは、ＳＴＡは同一ＥＳＳ内のＡＰだけはＴＸＯＰｈｏｌｄｅｒと認識して保持できるようにするのでもよい。

例えば、ＡＰは、ＣＦ－Ｅｎｄ２フレームのＲＡフィールドに、前述のようにｂａｓｉｃＮＡＶのリセット対象となるＢＳＳを設定し、送信するＡＰのアドレスをＣＦ－Ｅｎｄ２フレームのＢＳＳＩＤ（ＴＡ）フィールドに設定し、その上で新たにＴＸＯＰｈｏｌｄｅｒを入れるフィールド、ＴＸＯＰＨｏｌｄｅｒフィールド、を新たに設けるようにしてもよい。この場合の新たなフィールドは他のアドレスフィールドと同様、６オクテットとするのが適当である。

あるいは、ＡＰは、ＣＦ－Ｅｎｄ２フレームのＲＡフィールドに、ｂａｓｉｃＮＡＶのリセット対象となるＢＳＳのＢＳＳＩＤを入れる代わりにＴＸＯＰｈｏｌｄｅｒのアドレスを入れるようにしてもよい。ＭＡＰ下で利用されることを考えると、ここに入れるＴＸＯＰｈｏｌｄｅｒは必ずいずれかのＡＰであり、ＡＰのＭＡＣアドレスがＢＳＳＩＤであることから、ＢＳＳＩＤが入ると言える。なお、この先頭のＲＡフィールドはＴＸＯＰＨｏｌｄｅｒフィールドに改めてもよい。図２８のＳＴＡ動作例７では、ＡＰ２はＡＰ２のＢＳＳＩＤであるＢＳＳＩＤ２をＣＦ－Ｅｎｄ２フレームのＲＡフィールドに入れて送信したが、ＳＴＡ動作例７ｃでは、ＡＰ２はＡＰ１のＢＳＳＩＤであるＢＳＳＩＤ１をＣＦ－Ｅｎｄ２フレームのＲＡフィールドに入れて送信する。例えば、ｂａｓｉｃＮＡＶのリセット対象となるＢＳＳのＡＰがＣＦ－Ｅｎｄ２フレームを送信するようにすれば、ＳＴＡはＢＳＳＩＤ（ＴＡ）フィールドを用いてｂａｓｉｃＮＡＶのリセット対象であるかを判断することができる。ＡＰ２がＣＦ－Ｅｎｄ２フレームを送信する場合、ＣＦ－Ｅｎｄ２フレームのＢＳＳＩＤ（ＴＡ）にはＡＰ２のＭＡＣアドレスであるＢＳＳＩＤ２が設定され、ＡＰ２自身とＡＰ２に接続するＳＴＡのみがリセット対象となり、それらのＡＰ／ＳＴＡで保持されているｂａｓｉｃＮＡＶのＴＸＯＰｈｏｌｄｅｒがＣＦ－Ｅｎｄ２フレームのＲＡフィールドに記載されたＭＡＣアドレス（ここではＢＳＳＩＤ１（ＡＰ１））と合致した場合には当該ｂａｓｉｃＮＡＶをリセットする。

ｂａｓｉｃＮＡＶが延長されたときには、ＳＴＡは例えばそのＮＡＶを延長した元になったフレームからＴＸＯＰｈｏｌｄｅｒを抽出し、保持していたＴＸＯＰｈｏｌｄｅｒを抽出したＴＸＯＰｈｏｌｄｅｒで上書きする。

ＳＴＡはｂａｓｉｃＮＡＶのＴＸＯＰｈｏｌｄｅｒの保持条件を例えば同一ＥＳＳ内の物理パケットの受信時に限定する場合、あるいは同一ＥＳＳ内のＡＰからの物理パケットの受信時に限定する場合に、ＴＸＯＰｈｏｌｄｅｒ保持対象外の物理パケットを受信してｂａｓｉｃＮＡＶを設定する際には、ＴＸＯＰｈｏｌｄｅｒ（具体的にはそれ用の記憶領域）は空（ｖｏｉｄ）のままにしておく。ＴＸＯＰｈｏｌｄｅｒが空（ｖｏｉｄ）になるような物理パケットの受信によりｂａｓｉｃＮＡＶが延長される際も、仮にＴＸＯＰｈｏｌｄｅｒが保持されていたとしてもＴＸＯＰｈｏｌｄｅｒは空（ｖｏｉｄ）にする。ＳＴＡはＣＦ－Ｅｎｄ２フレーム受信時にＴＸＯＰｈｏｌｄｅｒが保持していなければ（つまり空（ｖｏｉｄ）の状態であれば）、ｂａｓｉｃＮＡＶをリセットしない。

以下、ＡＰまたはＳＴＡの構成について説明する。

図２９は、ＡＰ４００の他の例の機能ブロック図である。ＡＰ４００は、通信処理部４０１と、送信部４０２と、受信部４０３と、複数、例えば４つのアンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄと、ネットワーク処理部４０４と、有線インターフェース（Ｉ／Ｆ）４０５と、メモリ４０６とを備えている。ＡＰ４００は、有線Ｉ／Ｆ４０５を介して、サーバ４０７と接続されている。通信処理部４０１は、図２に示したＭＡＣ共通処理部７０と同様な機能を有している。送信部４０２は、図２に示した送信処理部８０と同様な機能を有している。受信部４０３は、図２に示した受信処理部９０と同様な機能を有している。ネットワーク処理部４０４は、図２に示した上位処理部１０と同様な機能を有している。ここで、通信処理部４０１は、ネットワーク処理部４０４との間でデータを受け渡しするためのバッファを内部に保有してもよい。このバッファは、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。

ネットワーク処理部４０４は、通信処理部４０１とのデータ交換、メモリ４０６とのデータ書き込み・読み出し、および、有線Ｉ／Ｆ４０５を介したサーバ４０７との通信を制御する。ネットワーク処理部４０４は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理やアプリケーション層の処理を行ってもよい。ネットワーク処理部４０４の動作は、ＣＰＵ等のプロセッサによるソフトウェア（プログラム）の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。

一例として、通信処理部４０１は、ベースバンド集積回路に対応し、送信部４０２と受信部４０３は、フレームを送受信するＲＦ集積回路に対応する。通信処理部４０１とネットワーク処理部４０４とが１つの集積回路（１チップ）で構成されてもよい。送信部４０２および受信部４０３のデジタル領域の処理を行う部分とアナログ領域の処理を行う部分とが異なるチップで構成されてもよい。また、通信処理部４０１が、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理を実行するようにしてもよい。また、アンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄの個数はここでは４つであるが、少なくとも１つのアンテナを備えていればよい。

メモリ４０６は、サーバ４０７から受信したデータや、受信部４０３で受信したデータの保存等を行う。メモリ４０６は、例えば、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。また、メモリ４０６は、ＳＳＤやＨＤＤ、ＳＤカード、ｅＭＭＣ等であってもよい。メモリ４０６が、ＡＰ４００の外部にあってもよい。

有線Ｉ／Ｆ４０５は、サーバ４０７とのデータの送受信を行う。図２９では、サーバ４０７との通信を有線で行っているが、サーバ４０７との通信を無線で実行するようにしてもよい。この場合、無線Ｉ／Ｆが、有線Ｉ／Ｆ４０５の代わりに用いればよい。

サーバ４０７は、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばＨＴＴＰサーバ（Ｗｅｂサーバ）、ＦＴＰサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。ＰＣやスマートフォン等のユーザが操作する通信装置でもよい。また、ＡＰ４００と無線で通信してもよい。

ＡＰ４００のＢＳＳに属するＳＴＡが、サーバ４０７に対するデータの転送要求を発行した場合、このデータ転送要求に関するパケットが、ＡＰ４００に送信される。ＡＰ４００は、アンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄを介してこのパケットを受信し、受信部４０３で物理層の処理等を、通信処理部４０１でＭＡＣ層の処理等を実行する。

ネットワーク処理部４０４は、通信処理部４０１から受信したパケットの解析を行う。具体的には、宛先ＩＰアドレス、宛先ポート番号等を確認する。パケットのデータがＨＴＴＰＧＥＴリクエストのようなデータ転送要求である場合、ネットワーク処理部４０４は、このデータ転送要求で要求されたデータ（例えば、ＨＴＴＰＧＥＴリクエストで要求されたＵＲＬに存在するデータ）が、メモリ４０６にキャッシュ（記憶）されているかを確認する。メモリ４０６には、ＵＲＬ（またはその縮小表現、例えばハッシュ値や、代替となる識別子）とデータとを対応づけたテーブルが格納されている。ここで、データがメモリ４０６にキャッシュされていることを、メモリ４０６にキャッシュデータが存在すると表現する。

メモリ４０６にキャッシュデータが存在しない場合、ネットワーク処理部４０４は、有線Ｉ／Ｆ４０５を介して、サーバ４０７に対してデータ転送要求を送信する。つまり、ネットワーク処理部４０４は、ＳＴＡの代理として、サーバ４０７へデータ転送要求を送信する。具体的には、ネットワーク処理部４０４は、ＨＴＴＰリクエストを生成し、ＴＣＰ／ＩＰヘッダの付加などのプロトコル処理を行い、パケットを有線Ｉ／Ｆ４０５へ渡す。有線Ｉ／Ｆ４０５は、受け取ったパケットをサーバ４０７へ送信する。

有線Ｉ／Ｆ４０５は、データ転送要求に対する応答であるパケットをサーバ４０７から受信する。ネットワーク処理部４０４は、有線Ｉ／Ｆ４０５を介して受信したパケットのＩＰヘッダから、ＳＴＡ宛のパケットであることを把握し、通信処理部４０１へパケットを渡す。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を実行し、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄから送信する。ここで、ネットワーク処理部４０４は、サーバ４０７から受信したデータを、ＵＲＬ（またはその縮小表現）と対応づけて、メモリ４０６にキャッシュデータとして保存する。

メモリ４０６にキャッシュデータが存在する場合、ネットワーク処理部４０４は、データ転送要求で要求されたデータをメモリ４０６から読み出して、このデータを通信処理部４０１へ送信する。具体的には、メモリ４０６から読み出したデータにＨＴＴＰヘッダ等を付加して、ＴＣＰ／ＩＰヘッダの付加等のプロトコル処理を行い、通信処理部４０１へパケットを送信する。このとき、一例として、パケットの送信元ＩＰアドレスは、サーバ４０７と同じＩＰアドレスに設定し、送信元ポート番号もサーバ４０７と同じポート番号（サーバ４０７に対するデータの転送要求を発行したＳＴＡが送信するパケットの宛先ポート番号）に設定する。したがって、ＳＴＡから見れば、あたかもサーバ４０７と通信をしているかのように見える。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を実行し、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄから送信する。

このような動作により、頻繁にアクセスされるデータは、メモリ４０６に保存されたキャッシュデータに基づいて応答することになり、サーバ４０７とＡＰ４００間のトラフィックを削減できる。なお、ネットワーク処理部４０４の動作は、上述の動作に限定されるものではない。ＳＴＡの代わりにサーバ４０７からデータを取得して、メモリ４０６にデータをキャッシュし、同一のデータに対するデータ転送要求に対しては、メモリ４０６のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題はない。

ＡＰ４００を、図１から図２８を参照して説明したＡＰとして適用することが可能である。図１から図２８を参照して説明したフレーム、データまたはパケットの送信を、メモリ４０６に保存されたキャッシュデータを用いて実行してもよい。また、図１から図２８を参照して説明したＡＰが受信したフレーム、データまたはパケットで得られた情報を、メモリ４０６にキャッシュしてもよい。図１から図２８を参照して説明したＡＰが送信するフレームは、キャッシュされたデータまたは当該データに基づく情報を含んでもよい。データに基づく情報は、例えばＳＴＡ宛のデータの有無の情報、データのサイズに関する情報、データの送信に必要なパケットのサイズに関する情報でもよい。またデータの送信に必要な変調方式等の情報でもよい。

図２９は、キャッシュ機能を備えたＡＰについて説明を行ったが、図２９と同じブロック構成で、キャッシュ機能を備えたＳＴＡを実現することもできる。ここでいうＳＴＡは、ｎｏｎ－ＡＰＳＴＡである（前述したようにＡＰも無線通信装置の一形態である）。この場合、有線Ｉ／Ｆ４０５を省略してもよい。図１から図２８を参照して説明したＳＴＡによるフレーム、データまたはパケットの送信を、メモリ４０６に保存されたキャッシュデータを用いて実行してもよい。また、図１から図２８を参照して説明したＳＴＡが受信したフレーム、データまたはパケットで得られた情報を、メモリ４０６にキャッシュしてもよい。図１から図２８を参照して説明したＳＴＡが送信するフレームは、キャッシュされたデータまたは当該データに基づく情報を含んでもよい。データに基づく情報は、例えば送信するデータの有無の情報、データのサイズに関する情報、データの送信に必要なパケットのサイズに関する情報でもよい。またデータの送信に必要な変調方式等の情報でもよい。

図３０は、ＳＴＡ（ｎｏｎ－ＡＰＳＴＡ）またはＡＰの一例の全体構成例を示したものである。この構成例は一例であり、構成例はこれに限定されるものではない。ＳＴＡまたはＡＰは、１つまたは複数のアンテナ１４７_１～１４７_ｎ（ｎは１以上の整数）と、無線ＬＡＮモジュール（または無線通信装置）１４８と、ホストシステム１４９を備える。無線ＬＡＮモジュール１４８は、ホスト・インターフェースを備え、ホスト・インターフェースで、ホストシステム１４９と接続される。無線ＬＡＮモジュール１４８は、接続ケーブルを介してホストシステム１４９と接続される他、ホストシステム１４９と直接接続されてもよい。また、無線ＬＡＮモジュール１４８が基板にはんだ等で実装され、基板の配線を介してホストシステム１４９と接続される構成も可能である。ホストシステム１４９は、任意の通信プロトコルに従って、無線ＬＡＮモジュール１４８およびアンテナ１４７_１～１４７_ｎを用いて、外部の装置と通信を行う。通信プロトコルは、ＴＣＰ／ＩＰと、それより上位の層のプロトコルと、を含んでもよい。または、ＴＣＰ／ＩＰは無線ＬＡＮモジュール１４８に搭載し、ホストシステム１４９は、それより上位層のプロトコルのみを実行してもよい。この場合、ホストシステム１４９の構成を簡単化できる。図３０に示すＳＴＡは、例えば、移動体ＳＴＡ、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置、自動車等でもよい。無線ＬＡＮモジュール１４８は、ＩＥＥＥ８０２．１１に加え、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）またはＬＴＥ－Ａｄｖａｎｃｅｄ（ｓｔａｎｄａｒｄｓｆｏｒｍｏｂｉｌｅｐｈｏｎｅｓ）のような他の無線通信規格の機能を備えていてもよい。

図３１は、無線ＬＡＮモジュール１４８のハードウェア構成例を示す。この構成は、無線ＬＡＮモジュール１４８がｎｏｎ－ＡＰＳＴＡおよびＡＰのいずれに搭載される場合にも適用可能である。この構成例では、アンテナは１本のみであるが、２本以上のアンテナを備えていてもよい。この場合、各アンテナに対応して、送信系統（２１６、２２２～２２５）、受信系統（２１７、２３２～２３５）、ＰＬＬ２４２、水晶発振器（基準信号源）２４３およびスイッチ２４５のセットが複数配置され、各セットがそれぞれベースバンド回路２１２に接続されてもよい。ＰＬＬ２４２または水晶発振器２４３またはこれらの両方は、発振器に対応する。

無線ＬＡＮモジュールは、ベースバンドＩＣ（ＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）２１１と、ＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）ＩＣ２２１と、バラン２２５と、スイッチ２４５と、アンテナ２４７とを備える。

ベースバンドＩＣ２１１は、ベースバンド回路（制御回路）２１２、メモリ２１３、ホスト・インターフェース２１４、ＣＰＵ２１５、ＤＡＣ（ＤｉｇｉｔａｌｔｏＡｎａｌｏｇＣｏｎｖｅｔｅｒ）２１６、およびＡＤＣ（ＡｎａｌｏｇｔｏＤｉｇｉｔａｌＣｏｎｖｅｒｔｅｒ）２１７を備える。

ベースバンドＩＣ２１１とＲＦＩＣ２２１は同じ基板上に形成されてもよい。また、ベースバンドＩＣ２１１とＲＦＩＣ２２１は１チップで構成されてもよい。ＤＡＣ２１６およびＡＤＣ２１７の両方またはいずれか一方が、ＲＦＩＣ２２１に配置されてもよいし、別のＩＣに配置されてもよい。またメモリ２１３およびＣＰＵ２１５の両方またはいずれか一方が、ベースバンドＩＣとは別のＩＣに配置されてもよい。

メモリ２１３は、ホストシステムとの間で受け渡しするデータを格納する。またメモリ２１３は、ＳＴＡまたはＡＰに通知する情報、またはＳＴＡまたはＡＰから通知された情報、またはこれらの両方を格納する。また、メモリ２１３は、ＣＰＵ２１５の実行に必要なプログラムを記憶し、ＣＰＵ２１５がプログラムを実行する際の作業領域として利用されてもよい。メモリ２１３はＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。

ホスト・インターフェース２１４は、ホストシステムと接続するためのインターフェースである。インターフェースは、ＵＡＲＴ、ＳＰＩ、ＳＤＩＯ、ＵＳＢ、ＰＣＩＥｘｐｒｅｓｓなど何でも良い。

ＣＰＵ２１５は、プログラムを実行することによりベースバンド回路２１２を制御するプロセッサである。ベースバンド回路２１２は、主にＭＡＣ層の処理および物理層の処理を行う。ベースバンド回路２１２、ＣＰＵ２１５またはこれらの両方は、通信を制御する通信制御装置、または通信を制御する制御部に対応する。

ベースバンド回路２１２およびＣＰＵ２１５の少なくとも一方は、クロックを生成するクロック生成部を含み、当該クロック生成部で生成するクロックにより、内部時間を管理してもよい。

ベースバンド回路２１２は、送信するフレームに、物理層の処理として、物理ヘッダの付加、符号化、暗号化、変調処理など行い、例えば２種類のデジタルベースバンド信号（以下、デジタルＩ信号とデジタルＱ信号）を生成する。

ＤＡＣ２１６は、ベースバンド回路２１２から入力される信号をＤＡ変換する。より詳細には、ＤＡＣ２１６はデジタルＩ信号をアナログのＩ信号に変換し、デジタルＱ信号をアナログのＱ信号に変換する。なお、直交変調せずに一系統の信号のままで送信する場合もありうる。複数のアンテナを備え、一系統または複数系統の送信信号をアンテナの数だけ振り分けて送信する場合には、アンテナの数に応じた数のＤＡＣ等を設けてもよい。

ＲＦＩＣ２２１は、一例としてＲＦアナログＩＣあるいは高周波ＩＣ、あるいはこれらの両方である。ＲＦＩＣ２２１は、フィルタ２２２、ミキサ２２３、プリアンプ（ＰＡ）２２４、ＰＬＬ（ＰｈａｓｅＬｏｃｋｅｄＬｏｏｐ；位相同期回路）２４２、低雑音増幅器（ＬＮＡ）、バラン２３５、ミキサ２３３、およびフィルタ２３２を備える。これらの要素のいくつかが、ベースバンドＩＣ２１１または別のＩＣ上に配置されてもよい。フィルタ２２２、２３２は、帯域通過フィルタでも、低域通過フィルタでもよい。

フィルタ２２２は、ＤＡＣ２１６から入力されるアナログＩ信号およびアナログＱ信号のそれぞれから所望帯域の信号を抽出する。ＰＬＬ２４２は、水晶発振器２４３から入力される発振信号を用い、発振信号を分周または逓倍またはこれらの両方を行うことで、入力信号の位相に同期した、一定周波数の信号を生成する。なお、ＰＬＬ２４２は、ＶＣＯ（ＶｏｌｔａｇｅＣｏｎｔｒｏｌｌｅｄＯｓｃｉｌｌａｔｏｒ）を備え、水晶発振器２４３から入力される発振信号に基づき、ＶＣＯを利用してフィードバック制御を行うことで、当該一定周波数の信号を得る。生成した一定周波数の信号は、ミキサ２２３およびミキサ２３３に入力される。ＰＬＬ２４２は、一定周波数の信号を生成する発振器の一例に相当する。

ミキサ２２３は、フィルタ２２２を通過したアナログＩ信号およびアナログＱ信号を、ＰＬＬ２４２から供給される一定周波数の信号を利用して、無線周波数にアップコンバートする。プリアンプ（ＰＡ）は、ミキサ２２３で生成された無線周波数のアナログＩ信号およびアナログＱ信号を、所望の出力電力まで増幅する。バラン２２５は、平衡信号（差動信号）を不平衡信号（シングルエンド信号）に変換するための変換器である。ＲＦＩＣ２２１では平衡信号が扱われるが、ＲＦＩＣ２２１の出力からアンテナ２４７までは不平衡信号が扱われるため、バラン２２５で、これらの信号変換を行う。

スイッチ２４５は、送信時は、送信側のバラン２２５に接続され、受信時は、受信側のバラン２３５またはＲＦＩＣ２２１に接続される。スイッチ２４５の制御はベースバンドＩＣ２１１またはＲＦＩＣ２２１により行われてもよいし、スイッチ２４５を制御する別の回路が存在し、当該回路からスイッチ２４５の制御を行ってもよい。

プリアンプ２２４で増幅された無線周波数のアナログＩ信号およびアナログＱ信号は、バラン２２５で平衡－不平衡変換された後、アンテナ２４７から空間に電波として放射される。

アンテナ２４７は、チップアンテナでもよいし、プリント基板上に配線により形成したアンテナでもよいし、線状の導体素子を利用して形成したアンテナでもよい。

ＲＦＩＣ２２１におけるＬＮＡ２３４は、アンテナ２４７からスイッチ２４５を介して受信した信号を、雑音を低く抑えたまま、復調可能なレベルまで増幅する。バラン２３５は、低雑音増幅器（ＬＮＡ）２３４で増幅された信号を、不平衡－平衡変換する。ミキサ２３３は、バラン２３５で平衡信号に変換された受信信号を、ＰＬＬ２４２から入力される一定周波数の信号を用いてベースバンドにダウンコンバートする。より詳細には、ミキサ２３３は、ＰＬＬ２４２から入力される一定周波数の信号に基づき、互いに９０°位相のずれた搬送波を生成する手段を有し、バラン２３５で変換された受信信号を、互いに９０°位相のずれた搬送波により直交復調して、受信信号と同位相のＩ（Ｉｎ－ｐｈａｓｅ）信号と、これより９０°位相が遅れたＱ（Ｑｕａｄ－ｐｈａｓｅ）信号とを生成する。フィルタ２３２は、これらＩ信号とＱ信号から所望周波数成分の信号を抽出する。フィルタ２３２で抽出されたＩ信号およびＱ信号は、ゲインが調整された後に、ＲＦＩＣ２２１から出力される。

ベースバンドＩＣ２１１におけるＡＤＣ２１７は、ＲＦＩＣ２２１からの入力信号をＡＤ変換する。より詳細には、ＡＤＣ２１７はＩ信号をデジタルＩ信号に変換し、Ｑ信号をデジタルＱ信号に変換する。なお、直交復調せずに一系統の信号だけを受信する場合もあり得る。

複数のアンテナが設けられる場合には、アンテナの数に応じた数のＡＤＣを設けてもよい。ベースバンド回路２１２は、デジタルＩ信号およびデジタルＱ信号に基づき、復調処理、誤り訂正符号処理、物理ヘッダの処理など、物理層の処理等を行い、フレームを得る。ベースバンド回路２１２は、フレームに対してＭＡＣ層の処理を行う。なお、ベースバンド回路２１２は、ＴＣＰ／ＩＰを実装している場合は、ＴＣＰ／ＩＰの処理を行う構成も可能である。

図３２（ａ）および図３２（ｂ）は、それぞれ無線ＳＴＡの他の二例の斜視図である。図３２（ａ）の無線ＳＴＡはノートＰＣ３０１であり、図３２（ｂ）の無線ＳＴＡは移動体端末３２１である。ノートＰＣ３０１および移動体端末３２１は、それぞれ無線通信装置３０５、３１５を搭載している。無線通信装置３０５、３１５として、これまで説明してきたＳＴＡに搭載されていた無線通信装置、またはＡＰに搭載されていた無線通信装置、またはこれらの両方を用いることができる。無線通信装置を搭載する無線ＳＴＡは、ノートＰＣや移動体端末に限定されない。例えば、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置、自動車等にも無線ＳＴＡを搭載可能である。

また、無線ＳＴＡまたはＡＰ、またはこれらの両方に搭載されていた無線通信装置は、メモリカードにも搭載可能である。当該無線通信装置をメモリカードに搭載した例を図３３に示す。メモリカード３３１は、無線通信装置３５５と、メモリカード本体３３２とを含む。メモリカード３３１は、外部の装置（無線ＳＴＡまたはＡＰ、またはこれらの両方等）との無線通信のために無線通信装置３３５を利用する。なお、図３３では、メモリカード３３１内の他の要素（例えばメモリ等）の記載は省略している。

無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置、またはこれらの両方）の他の例を説明する。他の例は、バス、プロセッサ部、及び外部インターフェース部を備えてもよい。プロセッサ部及び外部インターフェース部は、バスを介して外部メモリ（バッファ）と接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。ファームウエアが動作するプロセッサ部は、処理部または処理部の処理を行うプロセッサであってもよいし、当該処理の機能拡張または変更に係る処理を行う別のプロセッサであってもよい。ファームウエアが動作するプロセッサ部を、ＡＰあるいは無線ＳＴＡあるいはこれらの両方が備えてもよい。または当該プロセッサ部を、ＡＰに搭載される無線通信装置内の集積回路、または無線ＳＴＡに搭載される無線通信装置内の集積回路が備えてもよい。

上述した実施形態に係る無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置、またはこれらの両方）の構成に加えて、クロック生成部を備えてもよい。クロック生成部は、クロックを生成して出力端子より無線通信装置の外部にクロックを出力する。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側とを同期させて動作させることが可能となる。

上述した実施形態に係る無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置）の構成に加えて、電源部、電源制御部、及び無線電力給電部を含んでもよい。電源制御部は、電源部と無線電力給電部とに接続され、無線通信装置に供給する電源を選択する制御を行う。このように、電源を無線通信装置に備える構成とすることにより、電源を制御した低消費電力化動作が可能となる。

上述した実施形態に係る無線通信装置の構成に加えて、ＳＩＭカードを含んでもよい。ＳＩＭカードは、例えば無線通信装置における制御部と接続される。このように、ＳＩＭカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。

上述した実施形態に係る無線通信装置の構成に加えて、動画像圧縮／伸長部を含んでもよい。動画像圧縮／伸長部は、バスと接続される。このように、動画像圧縮／伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長とを容易に行うことが可能となる。

上述した実施形態に係る無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置、またはこれらの両方）の構成に加えて、ＬＥＤ部を含んでもよい。ＬＥＤ部は、送信部または受信部または制御部またはこれらのうちの複数と接続される。このように、ＬＥＤ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

上述した実施形態に係る無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置、またはこれらの両方）の構成に加えて、バイブレータ部を含んでもよい。バイブレータ部は、例えば無線通信装置における制御部と接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

上述した実施形態に係る無線通信装置（ＡＰの無線通信装置または無線ＳＴＡの無線通信装置、またはこれらの両方）の構成に加えて、ディスプレイを含んでもよい。ディスプレイは、図示しないバスを介して、無線通信装置の制御部に接続されてもよい。このようにディスプレイを備える構成とし、無線通信装置の動作状態をディスプレイに表示することで、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

次に、［１］無線通信システムにおけるフレーム種別、［２］無線通信装置間の接続切断の手法、［３］無線ＬＡＮシステムのアクセス方式、［４］無線ＬＡＮのフレーム間隔について説明する。

［１］通信システムにおけるフレーム種別一般的に無線通信システムにおける無線アクセスプロトコル上で扱うフレームは、前述したように、大別してデータ（ｄａｔａ）フレーム、管理（ｍａｎａｇｅｍｅｎｔ）フレーム、制御（ｃｏｎｔｒｏｌ）フレームの３種類に分けられる。これらの種別は、通常、フレーム間で共通に設けられるヘッダ部で示される。フレーム種別の表示方法としては、１つのフィールドで３種類を区別できるようにしてあってもよいし、２つのフィールドの組み合わせで区別できるようにしてあってもよい。ＩＥＥＥ８０２．１１規格では、フレーム種別の識別は、ＭＡＣフレームのフレームヘッダ部にあるＦｒａｍｅＣｏｎｔｒｏｌフィールドの中のＴｙｐｅ、Ｓｕｂｔｙｐｅという２つのフィールドで行う。データフレームか、管理フレームか、制御フレームかの大別はＴｙｐｅフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のビーコンフレームといった識別はＳｕｂｔｙｐｅフィールドで行われる。

管理フレームは、他の無線通信装置との間の物理的な通信リンクの管理に用いるフレームである。例えば、他の無線通信装置との間の通信設定を行うために用いられるフレームや通信リンクをリリースする（つまり接続を切断する）ためのフレーム、無線通信装置でのパワーセーブ動作に係るフレームがある。

データフレームは、他の無線通信装置と物理的な通信リンクが確立した上で、無線通信装置の内部で生成されたデータを他の無線通信装置に送信するフレームである。データは本実施形態の上位層で生成され、例えばユーザの操作によって生成される。

制御フレームは、データフレームを他の無線通信装置との間で送受（交換）する際の制御に用いられるフレームである。無線通信装置がデータフレームや管理フレームを受信した場合にその送達確認のために送信される応答フレームは、制御フレームに属する。応答フレームは、例えばＡＣＫフレームやＢｌｏｃｋＡＣＫフレームである。またＲＴＳフレームやＣＴＳフレームも制御フレームである。

これら３種類のフレームは、物理層で必要に応じた処理を経て物理パケットとしてアンテナを経由して送出される。なお、ＩＥＥＥ８０２．１１規格（前述のＩＥＥＥＳｔｄ８０２．１１ａｃ－２０１３などの拡張規格を含む）では接続確立の手順の１つとしてアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）プロセスがあるが、その中で使われるＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔフレームとＡｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅフレームが管理フレームであり、ＡｓｓｏｃｉａｔｉｏｎＲｅｑｕｅｓｔフレームやＡｓｓｏｃｉａｔｉｏｎＲｅｓｐｏｎｓｅフレームはユニキャストの管理フレームであることから、受信側無線通信装置に応答フレームであるＡＣＫフレームの送信を要求し、このＡＣＫフレームは上述のように制御フレームである。

［２］無線通信装置間の接続切断の手法接続の切断（リリース）には、明示的な手法と暗示的な手法とがある。明示的な手法としては、接続を確立している無線通信装置間のいずれか一方が切断のためのフレームを送信する。ＩＥＥＥ８０２．１１規格ではＤｅａｕｔｈｅｎｔｉｃａｔｉｏｎフレームがこれに当たり、管理フレームに分類される。通常、接続を切断するフレームを送信する側の無線通信装置では当該フレームを送信した時点で、接続を切断するフレームを受信する側の無線通信装置では当該フレームを受信した時点で、接続の切断と判定する。その後、非ＡＰの無線通信装置であれば通信フェーズでの初期状態、例えば接続するＢＳＳ探索する状態に戻る。無線通信ＡＰがある無線通信装置との間の接続を切断した場合には、例えば無線通信ＡＰが自ＢＳＳに加入する無線通信装置を管理する接続管理テーブルを持っているならば当該接続管理テーブルから当該無線通信装置に係る情報を削除する。例えば、無線通信ＡＰが自ＢＳＳに加入する各無線通信装置に接続をアソシエーションプロセスで許可した段階で、ＡＩＤを割り当てる場合には、当該接続を切断した無線通信装置のＡＩＤに関連づけられた保持情報を削除し、当該ＡＩＤに関してはリリースして他の新規加入する無線通信装置に割り当てられるようにしてもよい。

一方、暗示的な手法としては、接続を確立した接続相手の無線通信装置から一定期間フレーム送信（データフレーム及び管理フレームの送信、あるいは自装置が送信したフレームへの応答フレームの送信）を検知しなかった場合に、接続状態の切断の判定を行う。このような手法があるのは、上述のように接続の切断を判定するような状況では、接続先の無線通信装置と通信距離が離れて無線信号が受信不可あるいは復号不可になるなど物理的な無線リンクが確保できない状態が考えられるからである。すなわち、接続を切断するフレームの受信を期待できないからである。

暗示的な方法で接続の切断を判定する具体例としては、タイマーを使用する。例えば、送達確認応答フレームを要求するデータフレームを送信する際、当該フレームの再送期間を制限する第１のタイマー（例えばデータフレーム用の再送タイマー）を起動し、第１のタイマーが切れるまで（つまり所望の再送期間が経過するまで）当該フレームへの送達確認応答フレームを受信しないと再送を行う。当該フレームへの送達確認応答フレームを受信すると第１のタイマーは止められる。

一方、送達確認応答フレームを受信せず第１のタイマーが切れると、例えば接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマー（例えば管理フレーム用の再送タイマー）を起動する。第１のタイマーと同様、第２のタイマーでも、第２のタイマーが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマーが切れると接続が切断されたと判定する。接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。

あるいは、接続相手の無線通信装置からフレームを受信すると第３のタイマーを起動し、新たに接続相手の無線通信装置からフレームを受信するたびに第３のタイマーを止め、再び初期値から起動する。第３のタイマーが切れると前述と同様に接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマー（例えば管理フレーム用の再送タイマー）を起動する。この場合も、第２のタイマーが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマーが切れると接続が切断されたと判定する。この場合も、接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。後者の、接続相手の無線通信装置がまだ存在するかを確認するための管理フレームは、前者の場合の管理フレームとは異なるものであってもよい。また後者の場合の管理フレームの再送を制限するためのタイマーは、ここでは第２のタイマーとして前者の場合と同じものを用いたが、異なるタイマーを用いるようにしてもよい。

［３］無線ＬＡＮシステムのアクセス方式例えば、複数の無線通信装置と通信または競合することを想定した無線ＬＡＮシステムがある。ＩＥＥＥ８０２．１１無線ＬＡＮではＣＳＭＡ／ＣＡ（ＣａｒｒｉｅｒＳｅｎｓｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓｗｉｔｈＣａｒｒｉｅｒＡｖｏｉｄａｎｃｅ）をアクセス方式の基本としている。ある無線通信装置の送信を把握し、その送信終了から固定時間を置いて送信を行う方式では、その無線通信装置の送信を把握した複数の無線通信装置で同時に送信を行うことになり、その結果、無線信号が衝突してフレーム送信に失敗する。ある無線通信装置の送信を把握し、その送信終了からランダム時間待つことで、その無線通信装置の送信を把握した複数の無線通信装置での送信が確率的に分散することになる。よって、ランダム時間の中で最も早い時間を引いた無線通信装置が１つなら無線通信装置のフレーム送信は成功し、フレームの衝突を防ぐことができる。ランダム値に基づき送信権の獲得が複数の無線通信装置間で公平になることから、ＣａｒｒｉｅｒＡｖｏｉｄａｎｃｅを採用した方式は、複数の無線通信装置間で無線媒体を共有するために適した方式であるということができる。

［４］無線ＬＡＮのフレーム間隔ＩＥＥＥ８０２．１１無線ＬＡＮのフレーム間隔について説明する。ＩＥＥＥ８０２．１１無線ＬＡＮで用いられるフレーム間隔は、ｄｉｓｔｒｉｂｕｔｅｄｃｏｏｒｄｉｎａｔｉｏｎｆｕｎｃｔｉｏｎｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＤＩＦＳ）、ａｒｂｉｔｒａｔｉｏｎｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＡＩＦＳ）、ｐｏｉｎｔｃｏｏｒｄｉｎａｔｉｏｎｆｕｎｃｔｉｏｎｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＰＩＦＳ）、ｓｈｏｒｔｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＳＩＦＳ）、ｅｘｔｅｎｄｅｄｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＥＩＦＳ）、ｒｅｄｕｃｅｄｉｎｔｅｒｆｒａｍｅｓｐａｃｅ（ＲＩＦＳ）などがある。

フレーム間隔の定義は、ＩＥＥＥ８０２．１１無線ＬＡＮでは送信前にキャリアセンスアイドルを確認して開けるべき連続期間として定義されており、厳密な前のフレームからの期間は議論しない。従ってここでのＩＥＥＥ８０２．１１無線ＬＡＮシステムでの説明においてはその定義を踏襲する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＣＳＭＡ／ＣＡに基づくランダムアクセスの際に待つ時間を固定時間とランダム時間との和としており、固定時間を明確にするため、このような定義になっているといえる。

ＤＩＦＳとＡＩＦＳとは、ＣＳＭＡ／ＣＡに基づき他の無線通信装置と競合するコンテンション期間にフレーム交換開始を試みるときに用いるフレーム間隔である。ＤＩＦＳは、トラヒック種別による優先権の区別がないとき、ＡＩＦＳはトラヒック種別（ＴｒａｆｆｉｃＩｄｅｎｔｉｆｉｅｒ；ＴＩＤ）による優先権が設けられている場合に用いる。

ＤＩＦＳとＡＩＦＳとで係る動作としては類似しているため、以降では主にＡＩＦＳを用いて説明する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＭＡＣ層でフレーム交換の開始などを含むアクセス制御を行う。さらに、上位層からデータを渡される際にＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）対応する場合には、データとともにトラヒック種別が通知され、トラヒック種別に基づいてデータはアクセス時の優先度のクラス分けがされる。このアクセス時のクラスをアクセスカテゴリ（ＡｃｃｅｓｓＣａｔｅｇｏｒｙ；ＡＣ）と呼ぶ。従って、アクセスカテゴリごとにＡＩＦＳの値が設けられることになる。

ＰＩＦＳは、競合する他の無線通信装置よりも優先権を持つアクセスができるようにするためのフレーム間隔であり、ＤＩＦＳ及びＡＩＦＳのいずれの値よりも期間が短い。ＳＩＦＳは、応答系の制御フレームの送信時あるいは送信権を一旦獲得した後にバーストでフレーム交換を継続する場合に用いることができるフレーム間隔である。ＥＩＦＳはフレーム受信に失敗した（受信したフレームがエラーであると判定した）場合に起動されるフレーム間隔である。

ＲＩＦＳは送信権を一旦獲得した後にバーストで同一無線通信装置に複数のフレームを連続して送信する場合に用いることができるフレーム間隔であり、ＲＩＦＳを用いている間は送信相手の無線通信装置からの応答フレームを要求しない。

ここでＩＥＥＥ８０２．１１無線ＬＡＮにおけるランダムアクセスに基づく競合期間のフレーム交換の一例を図３４に示す。

ある無線通信装置においてデータフレーム（Ｗ＿ＤＡＴＡ１）の送信要求が発生した際に、キャリアセンスの結果、媒体がビジーである（ｂｕｓｙｍｅｄｉｕｍ）と認識する場合を想定する。この場合、キャリアセンスがアイドルになった時点から固定時間のＡＩＦＳを空け、その後ランダム時間（ｒａｎｄｏｍｂａｃｋｏｆｆ）空いたところで、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。なお、キャリアセンスの結果、媒体がビジーではない、つまり媒体がアイドル（ｉｄｌｅ）であると認識した場合には、キャリアセンスを開始した時点から固定時間のＡＩＦＳを空けて、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。

ランダム時間は０から整数で与えられるコンテンションウィンドウ（ＣｏｎｔｅｎｔｉｏｎＷｉｎｄｏｗ；ＣＷ）の間の一様分布から導かれる擬似ランダム整数にスロット時間をかけたものである。ここで、ＣＷにスロット時間をかけたものをＣＷ時間幅と呼ぶ。ＣＷの初期値はＣＷｍｉｎで与えられ、再送するたびにＣＷの値はＣＷｍａｘになるまで増やされる。ＣＷｍｉｎとＣＷｍａｘとの両方とも、ＡＩＦＳと同様アクセスカテゴリごとの値を持つ。Ｗ＿ＤＡＴＡ１の送信先の無線通信装置では、データフレームの受信に成功し、かつ当該データフレームが応答フレームの送信を要求するフレームであるとそのデータフレームを内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ時間後に応答フレーム（Ｗ＿ＡＣＫ１）を送信する。Ｗ＿ＤＡＴＡ１を送信した無線通信装置は、Ｗ＿ＡＣＫ１を受信すると送信バースト時間制限内であればまたＷ＿ＡＣＫ１を内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ時間後に次のフレーム（例えばＷ＿ＤＡＴＡ２）を送信することができる。

ＡＩＦＳ、ＤＩＦＳ、ＰＩＦＳ及びＥＩＦＳは、ＳＩＦＳとスロット時間との関数になるが、ＳＩＦＳとスロット時間とは物理層ごとに規定されている。また、ＡＩＦＳ、ＣＷｍｉｎ及びＣＷｍａｘなどアクセスカテゴリごとに値が設けられるパラメータは、通信グループ（ＩＥＥＥ８０２．１１無線ＬＡＮではＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ（ＢＳＳ））ごとに設定可能であるが、デフォルト値が定められている。

例えば、８０２．１１ａｃの規格策定では、ＳＩＦＳは１６μｓ、スロット時間は９μｓであるとして、それによってＰＩＦＳは２５μｓ、ＤＩＦＳは３４μｓ、ＡＩＦＳにおいてアクセスカテゴリがＢＡＣＫＧＲＯＵＮＤ（ＡＣ＿ＢＫ）のフレーム間隔はデフォルト値が７９μｓ、ＢＥＳＴＥＦＦＯＲＴ（ＡＣ＿ＢＥ）のフレーム間隔はデフォルト値が４３μｓ、ＶＩＤＥＯ（ＡＣ＿ＶＩ）とＶＯＩＣＥ（ＡＣ＿ＶＯ）のフレーム間隔はデフォルト値が３４μｓ、ＣＷｍｉｎとＣＷｍａｘとのデフォルト値は、各々ＡＣ＿ＢＫとＡＣ＿ＢＥとでは３１と１０２３、ＡＣ＿ＶＩでは１５と３１、ＡＣ＿ＶＯでは７と１５になるとする。なお、ＥＩＦＳは、基本的にはＳＩＦＳとＤＩＦＳと最も低速な必須の物理レートで送信する場合の応答フレームの時間長の和である。なお効率的なＥＩＦＳの取り方ができる無線通信装置では、ＥＩＦＳを起動した物理パケットへの応答フレームを運ぶ物理パケットの占有時間長を推定し、ＳＩＦＳとＤＩＦＳとその推定時間の和とすることもできる。

なお、各実施形態で記載されているフレームは、ＮｕｌｌＤａｔａＰａｃｋｅｔなど、ＩＥＥＥ８０２．１１規格または準拠する規格で、パケットと呼ばれるものを指してもよい。

また、複数のＳＴＡが多重送信するフレームは、異なる内容のフレームであっても、同一の内容のフレームでもよい。一般的な表現として、複数のＳＴＡが第Ｘのフレームを送信または受信すると表現するとき、これらの第Ｘのフレームの内容は同じであっても、異なってもよい。Ｘは任意の値である。

本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路（ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。

別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。また、回路は、単一チップに配置された複数の回路でもよいし、複数のチップまたは複数の装置に分散して配置された１つ以上の回路でもよい。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

ＡＰ…基地局、ＳＴＡ…端末、１０…上位処理部、２０…ＭＡＣ処理部、３０…ＰＨＹ処理部、４０…ＭＡＣ／ＰＨＹ管理部、５０…アナログ処理部、６０…アンテナ、７０…ＭＡＣ共通処理部、８０…送信処理部、９０…受信処理部。

Claims

メモリと、
前記メモリに接続される処理部と、
を具備し、
第１無線通信グループに収納される無線通信装置であって、
前記第１無線通信グループは第２無線通信グループとともに拡張無線通信グループを構成し、
前記処理部は、
第１パラメータと第２パラメータと第３パラメータを前記メモリに格納し、
受信したパケットが前記第１無線通信グループに収納される無線通信装置から送信されたパケットであると把握した場合、前記第１パラメータを更新し、
前記受信したパケットが前記第１無線通信グループに収納される無線通信装置から送信されたパケットであると把握しない場合、かつ前記受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握した場合、前記第２パラメータを更新し、
前記受信したパケットが前記第１無線通信グループに収納される無線通信装置から送信されたパケットであると把握しない場合、かつ前記受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握しない場合、前記第３パラメータを更新し、
前記第１パラメータと前記第２パラメータと前記第３パラメータに基づいてパケットを通信するかを決定する、無線通信装置。
前記無線通信装置は、ＩＥＥＥ８０２．１１ａｘ規格に準拠する無線通信装置であり、
前記処理部は、受信したフレームに含まれるＤｕｒａｔｉｏｎ／ＩＤフィールドに基づいて前記第１パラメータと前記第２パラメータと前記第３パラメータを設定する、請求項１記載の無線通信装置。
前記無線通信装置は、ＩＥＥＥ８０２．１１ａｘ規格に準拠する無線通信装置であり、
前記処理部は、ｓｈｏｒｔｉｎｔｅｒｆｒａｍｅｓｐａｃｅという固定時間とＰＳ－Ｐｏｌｌフレームへの応答として送信されるＡｃｋフレームが無線通信媒体を占有する推定時間との和に基づいて前記第１パラメータと前記第２パラメータと前記第３パラメータを設定する、請求項１記載の無線通信装置。
前記第１パラメータと前記第２パラメータと前記第３パラメータは、他の無線通信装置がパケットの送信権の獲得を延期する時間を表し、
前記処理部は、更新前の第１パラメータが表す時間より更新後の第１パラメータが表す時間の方が長い場合、前記第１パラメータを更新する、請求項１記載の無線通信装置。
前記第３パラメータが０であり、前記第１パラメータと前記第２パラメータとがともに０ではない場合、前記処理部は、パケットの送信権の獲得が不可能であり、
前記無線通信装置がデータ転送機能を有しない第１無線通信装置である場合、前記処理部は、他の無線通信装置から割り当てられた媒体の使用が可能であり、前記無線通信装置がデータ転送機能を有する第２無線通信装置である場合、前記処理部は、他の無線通信装置から割り当てられた媒体の使用が不可能である、請求項１記載の無線通信装置。
前記第１パラメータと前記第２パラメータと前記第３パラメータとがともに０である場合、前記処理部は、パケットの送信権の獲得が可能であり、他の無線通信装置から割り当てられた媒体の使用が可能である、請求項１記載の無線通信装置。
メモリと、
前記メモリに接続される処理部と、
を具備し、
第１無線通信グループに収納される無線通信装置であって、
前記第１無線通信グループは第２無線通信グループとともに拡張無線通信グループを構成し、
前記処理部は、
第２パラメータと第３パラメータを前記メモリに格納し、
受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握した場合、前記第２パラメータを更新し、
前記受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握しない場合、前記第３パラメータを更新し、
前記第２パラメータと前記第３パラメータに基づいてパケットを送信するかを決定する、無線通信装置。
前記第２パラメータと前記第３パラメータとがともに０ではない場合、前記処理部は、パケットの送信権の獲得が不可能であり、他の無線通信装置から割り当てられた媒体の使用が不可能である、請求項７記載の無線通信装置。
前記第２パラメータが０ではなく、前記第３パラメータが０である場合、前記処理部は、パケットの送信権の獲得が不可であり、他の無線通信装置から割り当てられた媒体の使用が可能である、請求項７記載の無線通信装置。
前記第２パラメータと前記第３パラメータとがともに０である場合、前記処理部は、パケットの送信権の獲得が可能であり、他の無線通信装置から割り当てられた媒体の使用が可能である、請求項７記載の無線通信装置。
メモリと、
前記メモリに接続される処理部と、
を具備し、
第１無線通信グループに収納される無線通信装置であって、
前記第１無線通信グループは第２無線通信グループとともに拡張無線通信グループを構成し、
前記処理部は、
第１パラメータと第３パラメータを前記メモリに格納し、
受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握した場合、前記第１パラメータを更新し、
前記受信したパケットが前記拡張無線通信グループに収納される無線通信装置から送信されたパケットであると把握しない場合、前記第３パラメータを更新し、
前記第１パラメータと前記第３パラメータに基づいてパケットを通信するかを決定する、無線通信装置。
前記処理部は、前記無線通信装置がデータ転送機能を有する第２無線通信装置である場合、前記拡張無線通信グループ内のデータ転送機能を有する第３無線通信装置から送信された第１無線通信媒体割り当てフレームを受信し、前記第１パラメータが０でなく、前記第３パラメータが０である場合、前記第１無線通信媒体割り当てフレームへの応答を前記第３無線通信装置へ送信し、第２無線通信媒体割り当てフレームを前記拡張無線通信グループ内のデータ転送機能を有しない少なくとも１つの第４無線通信装置へ送信する、請求項１１記載の無線通信装置。
前記第１パラメータが０ではなく、前記第３パラメータが０である場合、前記処理部は、前記パケットの送信が可能である、請求項１１記載の無線通信装置。