JP2019527961A - 送信装置および送信方法 - Google Patents

Abstract

本開示の送信装置は、アップリンクマルチユーザ（ＵＬ ＭＵ）送信用リソースを割り当てるためのＴｒｉｇｇｅｒフレームを送信し、Ｔｒｉｇｇｅｒフレームは、複数のトリガタイプのうちの１つを示すタイプサブフィールドを含む共通情報フィールドを含み、複数のトリガタイプは、受信端末局から任意のタイプの応答フレームを要求するために使用される基本トリガを示す第１のトリガタイプと、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを要求するために使用される特定のトリガを示す第２のトリガタイプとを含む、送信部と、タイプサブフィールドが第２のトリガタイプを示す場合、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを受信する受信部とを有する。

Description

本開示は、一般に、マルチユーザ管理フレームを交換するための送信装置および送信方法に関する。

ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）（登録商標） ８０２．１１ワーキンググループは現在、８０２．１１ａｘタスクグループの下で次世代のＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）技術の標準化に取り組んでいる。タスクグループは、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）および／または端末局（以降、「非ＡＰ ＳＴＡ（ｔｅｒｍｉｎａｌ Ｓｔａｔｉｏｎ）」または単にＳＴＡ）の高密度環境でのシステムスループット／エリアを向上させるためのスペクトル効率の改善を主な目的としている。ＩＥＥＥ８０２．１１ａｘ規格に基づくデバイスは、一般に、高効率（ＨＥ：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ）デバイスと呼ばれる。提案されている種々の技術の中で、ＩＥＥＥ８０２．１１ａｘタスクグループがスループット改善目標を達成するために採用したＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ−Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）およびアップリンクマルチユーザ送信の２つは、重要な技術である。図１は、ＡＰ１９０およびＡＰ１９０に関連付けられたいくつかのＳＴＡを有する例示的な８０２．１１ａｘ ＷＬＡＮネットワーク１００を示す。

ＩＥＥＥ８０２．１１規格は、ＩＥＥＥ８０２．１１に基づく無線ネットワーク内で交換され得る種々のタイプのフレームを定義する。管理フレームは、無線ネットワーク内の無線通信を有効かつ維持するために使用される。これらのフレームは、ＩＥＥＥ８０２．１１デバイスのメディアアクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層内で生成され、適切な受信を保証するために、通常、よりロバストな変調符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）で送信される。いくつかの管理フレームは、ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）内のアクセスポイント（ＡＰ）によってブロードキャストされる。ブロードキャスト管理フレームは、例えば、ＢＳＳの存在ならびにＢＳＳが動作している無線チャネル、ＢＳＳのサービスセット識別子（ＳＳＩＤ：Ｓｅｒｖｉｃｅ Ｓｅｔ Ｉｄｅｎｔｉｆｉｅｒ）などの種々の属性をアドバタイズするためのＢｅａｃｏｎフレームを含む。ＡＰの通信範囲内にあるＳＴＡは、Ｂｅａｃｏｎフレームから取得した情報を使用して、ＢＳＳにまだ参加していない場合には、ＢＳＳに初めて参加し、ＢＳＳに既に参加している場合には、ＢＳＳの記録を更新することができる。しかしながら、管理フレームの大部分は、ユニキャスト方式（すなわち、特定のＳＴＡまたはＡＰ宛て）で使用される。

場合によっては、ＡＰは、特定のＳＴＡに管理フレームを送信して、特定の動作（例えば、ＳＴＡにＢＳＳを離脱するように要求するためのＤｉｓａｓｓｏｃｉａｔｅ フレームを実行するように）を要求することができる。しかし、大半の場合、ＡＰとＳＴＡとの間で関連する管理フレームの交換が行われる。一例として、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームは、ＡＰからＳＴＡに送信され、ＳＴＡは、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｓｐｏｎｓｅフレームをＡＰに返信してＢＳＳに参加する。別の例として、Ａｄｄ Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ（ＡＤＤＢＡ） Ｒｅｑｕｅｓｔは、ＡＰからＳＴＡに送信され、ＳＴＡは、ＡＤＤＢＡ ＲｅｓｐｏｎｓｅフレームをＡＰに返信して、２つのデバイス間におけるＢｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ（Ａｃｋ）メカニズムを有効にするためのセットアップをする。

IEEE802.11-15/0132r17, Specification Framework for TGax, May 2015 IEEE802.11-16/0024r1, Proposed TGax draft specification IEEE Std 802.11-2012

ダウンリンク（ＤＬ：downlink）において、ＭＵ−ＭＩＭＯ（Multi-user Multiple Input Multiple output）を用いたマルチユーザ送信が可能であり、ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）は、ダウンリンクおよびアップリンク（ＵＬ:uplink）の両方において使用可能であるが、マルチユーザ送信で効率的な管理フレーム交換を行うことは、困難である。

本開示の非限定的な実施形態は、アップリンクマルチユーザ（ＵＬ ＭＵ：Uplink Multi user）送信用リソースを割り当てるためのＴｒｉｇｇｅｒフレームを送信し、Ｔｒｉｇｇｅｒフレームは、複数のＴｒｉｇｇｅｒタイプのうちの１つを示すタイプサブフィールドを含む共通情報フィールドを含み、複数のトリガタイプは、受信端末局から任意のタイプの応答フレームを要求するために使用される基本トリガを示す第１のトリガタイプと、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを要求するために使用される特定のトリガを示す第２のトリガタイプとを含む、送信部と、タイプサブフィールドが第２のトリガタイプを示す場合、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを受信する受信部とを有する、送信装置を提供する。

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

本開示で説明される方法によって、効率的なマルチユーザ管理フレーム交換が可能となる。

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

マルチユーザ管理フレーム交換を利用するシステムの特定の実施形態の図である。 Ｂｌｏｃｋ Ａｃｋメカニズムのセットアップ（Ｓｅｔｕｐ）およびティアダウン（Ｔｅａｒｄｏｗｎ）を含む例示的なフレーム交換シーケンスの図である。 ＡＰと複数のＳＴＡとの間のＢｌｏｃｋ Ａｃｋ設定のための例示的なフレーム交換シーケンスの図である。 第１の実施形態で使用される「ＴＦ Ｔｉｍｅｏｕｔ」フィールドを搬送するために使用されるエレメントの構成を示す。 第１の実施形態における「ＴＦ Ｔｉｍｅｏｕｔ」フィールドの意味を示すテーブルである。 ＡＰによって開始される、本開示に係る例示的なマルチユーザ管理フレーム交換の図である。 ＡＰによって開始される、本開示に係る別の例示的なマルチユーザ管理フレーム交換の図である。 ＳＴＡによって開始される本開示に係る別の例示的なマルチユーザ管理フレーム交換の図である。 ＳＴＡによって開始される、本開示に係る別の例示的なマルチユーザ管理フレーム交換の図である。 第１の実施形態に係るＴｒｉｇｇｅｒフレームの構造を示す。 第１の実施形態に係るＣｏｍｍｏｎ Ｉｎｆｏフィールドの構造を示す。 第１の実施形態に係るＴｙｐｅ−ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏフィールドの構造を示す。 第１の実施形態に係るいくつかのフレームタイプを説明するテーブルを示す。 第１の実施形態に係るＳｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールドの構造を示す。 第１の実施形態に係るＡｃｔｉｏｎ Ｃａｔｅｇｏｒｙサブフィールドを説明するテーブルを示す。 第１の実施形態に係るＡｃｔｉｏｎ Ｆｉｅｌｄサブフィールドを説明するテーブルを示す。 第２の実施形態で使用される「ＴＦ Ｔｉｍｅｏｕｔ」フィールドを搬送するために使用されるＨＥ Ｖａｒｉａｎｔ Ａｇｇｒｅｇａｔｅｄ Ｃｏｎｔｒｏｌ（Ａ―Ｃｏｎｔｒｏｌ）サブフィールドの構造を示す。 第２の実施形態に係るＣｏｎｔｒｏｌサブフィールドのフォーマットを示す。 第２の実施形態に係るＣｏｎｔｒｏｌ ＩＤサブフィールド値を説明するテーブルを示す。 第２の実施形態に係る種々のトリガタイプ（Ｔｒｉｇｇｅｒ Ｔｙｐｅ）を説明するテーブルを示す。 第２の実施形態に係るＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールドのフォーマットを示す。 第２の実施形態に係るＦｒａｍｅ Ｓｕｂｔｙｐｅを説明するテーブルを示す。 第２の実施形態に係る種々のＡｃｔｉｏｎ Ｆｉｅｌｄ値を説明するテーブルを示す。 第２の実施形態に係るＵｓｅｒ Ｉｎｆｏフィールドのフォーマットを示す。 第３の実施形態に係るＡＤＤＢＡ Ｅｘｔｅｎｓｉｏｎ ｅｌｅｍｅｎｔフィールドのフォーマットを示す。 第３の実施形態に係るＡＤＤＢＡ Ｃａｐａｂｉｌｉｔｉｅｓフィールドのフォーマットを示す。 第３の実施形態に係る種々のＴＦ Ｔｉｍｅｏｕｔ値を説明するテーブルを示す。 第３の実施形態に係るＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールドの構造を示す。 第３の実施形態に係る種々のＦｒａｍｅ Ｔｙｐｅ値を説明するテーブルを示す。 第４の実施形態で使用されるＴＦ Ｔｉｍｅｏｕｔを搬送するために使用されるＵＬ ＭＵ ｒｅｓｐｏｎｓｅ ｓｃｈｅｄｕｌｉｎｇ Ｃｏｎｔｒｏｌサブフィールド構造の図である。 第４の実施形態に係るＡＰによって開始される例示的なマルチユーザ管理フレーム交換の図である。 本開示に係るマルチユーザ管理フレーム交換を開始するためにＡＰによって実行される動作のフローチャートである。 本開示に係るＡＰによって開始されるマルチユーザ管理フレーム交換に参加するためにＳＴＡによって実行される動作のフローチャートである。 例示的なＡＰのブロック図である。 例示的なＳＴＡのブロック図である。

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

図２は、Ｂｌｏｃｋ Ａｃｋパラメータをネゴシエートするための管理フレームの交換を含む、２つの８０２．１１デバイス間のフレーム交換の例示的なシーケンス２００を示す。インフラストラクチャＢＳＳにおいて、８０２．１１デバイスの一方がＡＰとなり、他方がＳＴＡとなる。シーケンス２００は、（ａ）Ｂｌｏｃｋ Ａｃｋ Ｓｅｔｕｐフェーズ２１０、（ｂ）１つ以上のデータ交換フェーズ２２０、および（ｃ）Ｂｌｏｃｋ Ａｃｋ Ｔｅａｒｄｏｗｎフェーズ２３０の３つの異なるフェーズからなる。Ｂｌｏｃｋ Ａｃｋは、ＩＥＥＥ８０２．１１ｅの改正に伴い導入された機能である。その機能によって、８０２．１１デバイスは、受信フレーム毎の即時Ａｃｋフレームの返信を要求することなく、別の８０２．１１デバイスにフレームをバースト送信することができる。

バースト送信を開始する８０２．１１デバイスは、Ｏｒｉｇｉｎａｔｏｒと呼ばれ、一方、受信側の８０２．１１デバイスは、Ｒｅｃｉｐｉｅｎｔと呼ばれる。バースト送信完了後、Ｏｒｉｇｉｎａｔｏｒは、Ｒｅｃｉｐｉｅｎｔに対してＢｌｏｃｋ Ａｃｋ Ｒｅｑｕｅｓｔフレームを送信することによって、受信フレームのビットマップを含むＢｌｏｃｋ Ａｃｋの送信を要求できる。このやり取りについて、図２のフェーズ２２０に示す。ＩＥＥＥ８０２．１１ｎの改正により、データのバーストをＡ−ＭＰＤＵと呼ばれる単一の管理プロトコルデータユニット（ＭＰＤＵ：Management Protocol Data Unit）に集約できるようにすることで、この機能がさらに強化された。Ｂｌｏｃｋ Ａｃｋは便利な機能であるが、この機能を使用できるようにするために、ＯｒｉｇｉｎａｔｏｒとＲｅｃｉｐｉｅｎｔの両者が追加のリソースを用意する必要がある。Ｒｅｃｉｐｉｅｎｔは、フレームのバーストを受信するために追加のバッファを確保する必要があるだけでなく、フレームの受信状況を記録するスコアボードを保持する必要がある。同様に、Ｏｒｉｇｉｎａｔｏｒは、送信フレームの記録を保持する必要がある。この準備は、Ｂｌｏｃｋ Ａｃｋ Ｓｅｔｕｐフェーズ２１０で行われる。このフェーズにおいて、２つの８０２．１１デバイスは、バッファサイズ、関連フレームのトラフィック識別子（ＴＩＤ：Traffic Identifier）、ネゴシエーションの有効期間などをネゴシエートできる。データ交換フェーズが完了すると、当事者のいずれかがＴｅａｒｄｏｗｎフェーズ２３０でＢｌｏｃｋ Ａｃｋの取り決めをティアダウンしてもよい。

先に説明したように、管理フレーム交換の大部分は、２つの８０２．１１デバイスの間、通常、ＡＰとＳＴＡとの間で行われる。一例として、Ｂｌｏｃｋ Ａｃｋ Ｓｅｔｕｐフェーズ２１０に含まれる管理フレーム交換の詳細を図３に示す。この例では、ＡＰがＯｒｉｇｉｎａｔｏｒであり、ＳＴＡがＲｅｃｉｐｉｅｎｔである。ＡＰがＢｌｏｃｋ Ａｃｋ機能を使用できるようになるには、Ｂｌｏｃｋ Ａｃｋ機能を使用したいＡＰがＳＴＡ毎にＢｌｏｃｋ Ａｃｋ機能を設定する必要がある。フレーム交換シーケンス３００、３１０および３２０は、それぞれＳＴＡ１、ＳＴＡ２およびＳＴＡｎとの間でＢｌｏｃｋ Ａｃｋ機能を設定するために、ＡＰによって開始される。それぞれのシーケンスは、ＡＰと各ＳＴＡとの間のＡＤＤＢＡ Ｂｌｏｃｋ Ａｃｋ Ａｃｔｉｏｎ Ｍａｎａｇｅｍｅｎｔフレームの交換を含む。例えば、シーケンス３００において、ＡＰは、無線媒体に対する競合を行うことで交換を開始する。この競合については、本開示を通じて図中の記号３０２によって表される。

ＡＰが競合に勝つと、ＳＴＡ１に向けて一意にアドレス指定されたＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム３０４を送信する。ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム３０４を受信すると、ＳＴＡ１は、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームの終端からＳｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ（ＳＩＦＳ）時間後に、ＡＰに対してＡｃｋフレーム３０６を返信する。Ａｃｋフレームの送信については、無線媒体の競合を必要としない。ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームを処理し、要求を受け入れると、ＳＴＡは、競合を通じて無線媒体を獲得した後、ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレーム３０８を返信する。ＡＰは、Ａｃｋフレームを送信することによってＡＤＤＢＡフレームの受信に対する確認応答をする。ＳＴＡがＢｌｏｃｋ Ａｃｋ機能を使用する場合、逆方向、すなわちＳＴＡによって開始される同様のフレーム交換が必要となる。多くのＳＴＡが関与している場合、このＳｅｔｕｐ処理に多くの時間がかかることは明らかである。

管理フレーム交換の際、ＭＵ−ＭＩＭＯを使用するダウンリンク（ＤＬ）および直交周波数分割多元接続（ＯＦＤＭＡ）を使用するＤＬおよびアップリンク（ＵＬ）において、マルチユーザ送信が可能であるが、効率的なマルチユーザ通信を妨げる問題が、特にＵＬ方向において、いくつか存在する。これら問題は、次の２つの問題としてまとめられる。１）ほとんどの管理フレームは、Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ（ＥＤＣＡ）の最も高いアクセスカテゴリ（ＡＣ：Access Category）であるＡＣ＿ＶＯを使用して送信される。ＡＰがＤＬマルチユーザＰＨＹ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ（ＰＰＤＵ）で複数の管理フレームを複数のＳＴＡに送信する場合、フレームを首尾よく受信したＳＴＡは、返信の準備ができ次第、それぞれの応答管理フレームをＡＰに返信しようとする。同時に、ＳＴＡからマルチユーザの方式で複数の応答管理フレームを要求するために、ＡＰは、Ｔｒｉｇｇｅｒフレームと呼ばれる新たに定義された制御フレームの基本バリアントを送信しようとする。

基本Ｔｒｉｇｇｅｒ（Basic Trigger）フレームは、ＵＬ送信に使用されるリソースユニット（ＲＵ）割当（RU Allocation）、ＰＰＤＵ長、ＭＣＳ等の情報を含む。Ｔｒｉｇｇｅｒフレームを受信すると、ＴｒｉｇｇｅｒフレームでＲＵを割り当てられたＳＴＡは、ＵＬマルチユーザＰＰＤＵで各ＵＬフレームを返信することができる。これにより、ＳＴＡの応答管理フレームの間およびＡＰのＴｒｉｇｇｅｒフレームとの間で無線媒体に対する競合が行われる。Ｔｒｉｇｇｅｒフレームが媒体へアクセスできない場合、またはその送信が遅延された場合、ＳＴＡは、ＵＬフレームに対してマルチユーザ送信を利用することができない。２）Ｔｒｉｇｇｅｒフレームの基本バリアントは、ＳＴＡがＵＬマルチユーザＰＰＤＵで返信することができるフレームタイプを指定しない。これにより、いくつかのＳＴＡが応答管理フレーム以外のフレームを返信し、ＡＰが１つ以上のＴｒｉｇｇｅｒフレームをそれらのＳＴＡに送信することが必要となる状況につながる可能性がある。これらの両方の要因によって、非効率になるだけではなく、応答フレームの返信遅延により、タイムアウトのために要求フレームの一部を再発行する必要が生じる可能性がある。

本開示で説明された技術は、多くの無線通信システムに適用可能であるが、例として、本開示における残りの記載については、ＩＥＥＥ８０２．１１ＷＬＡＮシステムおよびそれに関連する用語をもってなされる。これは、代替の無線通信システムに関して本開示を限定するものと解釈されるべきではない。

再び図１を参照すると、例示的な無線ネットワーク１００は、ＡＰ１９０および多くの関連付けられたＳＴＡを含み得る。ＳＴＡ２ １２０およびＳＴＡ６ １６０は、処理能力が高く、ＱｏＳ要件が高く、省電力要件が比較的低いデバイスクラスを表す。ＳＴＡ１ １１０およびＳＴＡ４ １４０は、高い処理能力およびおそらくは高いＱｏＳ要件を有する可能性はあるが、消費電力についてより高い関心がある別のデバイスクラスを表す。もう１つの極端な場合、ＳＴＡ３ １３０およびＳＴＡ５ １５０は、処理能力が低く、消費電力に対して影響されやすい可能性のある別のクラスのデバイスを表す。ＩＥＥＥ ８０２．１１ａｘの用語では、ＳＴＡ１ １１０、ＳＴＡ２ １２０、ＳＴＡ４ １４０、およびＳＴＡ６ １６０は、高性能デバイスであるＣｌａｓｓ Ａデバイスと見なされ、ＳＴＡ３ １３０およびＳＴＡ５ １５０は、能力の低いデバイスであるＣｌａｓｓ Ｂデバイスと見なされる。

任意の無線通信における基本的な課題は、無線トランシーバが任意の時点で送信状態または受信状態のいずれか一方の状態でもありうるという事実である。無線デバイスが複数のトランシーバを含んでいても、送信信号は、受信信号よりも数倍強力であるため、トランシーバが特定の周波数で送信している間、同じ周波数の信号を受信することはできない。このため、事実上すべての無線デバイスは、半二重通信で動作する。この事実は次の課題にもつながる。送信部は自身で、送信信号に発生する可能性のある衝突を検出することができない。

ＩＥＥＥ８０２．１１では、受信側デバイスからの肯定応答を使用することで、この課題を排する。送信部によって要求された場合、受信者は、送信部のフレーム受信に成功したことを確認応答するために何らかの確認応答フレーム（Ａｃｋ／Ｂｌｏｃｋ Ａｃｋなど）を返信する。送信部がその送信に対して何も確認応答を受信しなければ、それは送信が失敗したと仮定し、フレームを再送するなどの回復動作の実行に移るかもしれない。予防措置について言えば、ＩＥＥＥ８０２．１１は、プライマリチャネルアクセスメカニズムとして、搬送波感知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ：Channel Sense Multiple Access with Collision Avoidance）を使用する。衝突回避は、ランダムバックオフを使用することで実現されるが、ＣＳＭＡは、物理的なおよび仮想的なチャネルセンス（ＣＳ：Channel Sense）メカニズムの使用を伴う。物理的なＣＳメカニズムは、ＰＨＹレイヤによって提供され、無線媒体の実際の検出（プリアンブル検出またはエネルギー検出またはその両方）を含む。仮想的なＣＳメカニズムは、ＭＡＣレイヤによって提供され、ネットワークアロケーションベクタ（ＮＡＶ：Network Allocation Vector）を利用する。ＮＡＶは、ほとんどのＩＥＥＥ８０２．１１フレームで通知される時間情報に基づいて、媒体上の将来のトラフィックの予測を維持する。この時間は、ＭＡＣヘッダに含まれてもよく、および／または、もし存在するならば、ＰＨＹヘッダ内のＴｒａｎｓｍｉｔ Ｏｐｐｏｒｔｕｎｉｔｙ（ＴＸＯＰ）時間から取得されてもよい。物理的なＣＳまたは仮想的なＣＳのいずれかが、媒体がビジーであることを示している場合、デバイスは、ＡｃｋフレームまたはＢｌｏｃｋ Ａｃｋフレームなどのいくつかの特定のフレーム以外の信号を送信することはできない。ＮＡＶは、デバイスの送信をその通信範囲内にある第三者デバイスから保護するのに有用であるが、ＮＡＶを設定するフレームの受信者であるＳＴＡからの競合を防止するようには設計されていない。

マルチユーザ送信は、ＩＥＥＥ ８０２．１１ａｃの改正で導入された、ＭＵ−ＭＩＭＯを用いた技術であるが、その対象は、ダウンリンクのみである。ＡＰは、異なる空間ストリームを使用して異なるＳＴＡ宛ての異なるユニキャストフレームを送信することができる。しかし、追加のアンテナが必要となり、かつ別種の複雑性を伴うので、この機能は、アップリンク方向には導入されなかった。先に説明したように、ダウンリンクおよびアップリンク方向の両方でＯＦＤＭＡを使用するマルチユーザ送信は、ＩＥＥＥ８０２．１１ａｘタスクグループがスループット改善目標を達成するために採用した重要な技術である。ダウンリンク方向では、ＡＰがすべてのマルチユーザフレームを送信するので、マルチユーザ送信は、比較的簡単である。ＤＬマルチユーザＰＰＤＵは、個々のＰＨＹサービスデータユニット（ＰＳＤＵ：PHY Service Data Unit）が搬送される狭帯域チャネル（リソースユニットまたはＲＵとして知られる）に関する情報を搬送するワイドチャネルＰＨＹヘッダから構成される。理論的には、１つの２０ＭＨｚチャネル内で、最大３７の独立した送信をマルチユーザＰＰＤＵで３７の別個のＳＴＡに搬送可能である。

複数のＳＴＡからの送信間の時間同期が必要であり、また、異なるＳＴＡからの送信が互いに干渉しないようにする必要があるため、すなわち、ＳＴＡ毎にユニークなＲＵを割り当てる必要があるため、アップリンク方向の送信は、より複雑である。これは、ＡＰによって送信されるＴｒｉｇｇｅｒフレームと呼ばれる特別な制御フレームを通じて、ＩＥＥＥ８０２．１１ａｘにおいて実現される。Ｔｒｉｇｇｅｒフレームは、リソースユニット（ＲＵ：Resource Unit）割当、ＰＰＤＵ長、ＭＣＳ等、ＵＬ送信で使用される情報を含む。Ｔｒｉｇｇｅｒフレームを受信すると、ＴｒｉｇｇｅｒフレームでＲＵを割り当てられたＳＴＡは、無線媒体に対する競合を行うことなく、Ｔｒｉｇｇｅｒフレームの終端からＳＩＦＳ後にＵＬマルチユーザＰＰＤＵで各ＵＬフレームを送信することができる。任意のタイプのフレームを要求するために使用され得るＢａｓｉｃ Ｔｒｉｇｇｅｒフレームとは別に、特定のタイプのフレームを要求するために、Ｔｒｉｇｇｅｒフレームの様々なバリアントが定義されている。例えば、ＭＵ−ＲＴＳ（Multi-user Request To Send）バリアントは、複数のＳＴＡからＣＴＳ（Clear To Send）フレームを要求するために使用され、ＭＵ−ＢＡＲ（Multi-User Block Ack Request）は、複数のＳＴＡなどからＢｌｏｃｋ Ａｃｋフレームを要求するために使用される。

上記の知見に基づいて、本出願の発明者らは、本開示に至った。マルチユーザ管理フレーム交換の効率的でタイムリーな交換を可能にする方法が開示される。本開示の一態様によれば、ＡＰは、１つ以上のフレームを搬送するＤＬ ＰＰＤＵにおいて、時間を示し、その時間の間、ＤＬ ＰＰＤＵに含まれるフレームにおいてアドレス指定された受信側ＳＴＡは、明示的な再送許可を与える別のフレームを受信するまで、直前のＤＬ ＰＰＤＵへの即時確認応答以外のフレームを送信することはできない。これは、送信部が、それより以前に行った送信の受信者である１つ以上のＳＴＡからなされるであろう送信を保護するものとして見なされ得る。第三者のＳＴＡからの保護は、従来のＮＡＶ保護メカニズムを使用することによって保証され得る。これにより、ＡＰは、適時にＵＬマルチユーザＰＰＤＵを要求するＴｒｉｇｇｅｒフレームを送信することができる。

本開示の第２の態様は、ＵＬ ＰＰＤＵにおいて要求されるフレームタイプを、ＡＰが望むタイプに制限するために、Ｔｒｉｇｇｅｒフレームをカスタマイズすることを含む。マルチユーザ管理フレーム交換の場合、これは、Ｔｒｉｇｇｅｒフレームにおいて、特定のＴｒｉｇｇｅｒフレームタイプを使用するか、またはＢａｓｉｃ Ｔｒｉｇｇｅｒフレームの新しいバリアントを使用して、正確な管理フレームタイプ、サブタイプおよびその他の詳細を示し、これによって、アドレス指定されたＳＴＡが、ＵＬ ＰＰＤＵに含まれるべきＡＰが望む正確な管理フレームタイプを明確に識別できるようになる。

本開示で提案されるマルチユーザ管理フレーム交換のための種々の実施形態は、以下のセクションで詳細に説明される。

＜第１実施形態＞
前述のように、マルチユーザ管理フレーム交換の課題の１つは、複数のＳＴＡ宛ての管理要求フレームを含むＤＬマルチユーザＰＰＤＵを送信することによって、ＡＰが交換を開始する場合、それぞれのＳＴＡからの、対応するシングルユーザ管理応答／通知フレームがＡＰのＴｒｉｇｇｅｒフレームとの間で媒体に対して競合し、Ｔｒｉｇｇｅｒフレームの送信に遅延が生じる可能性があるという事実である。複数の管理応答フレームを搬送するＵＬマルチユーザＰＰＤＵは、ＡＰからＴｒｉｇｇｅｒフレームを受信することなく送信することはできないので、マルチユーザ管理フレーム交換に乱れが生じる。

ＤＬ ＰＰＤＵにより長いＴＸＯＰ時間を含めることによって、フレーム交換を開始するＡＰがＳＴＡからの後続の応答フレームを保護する試みを可能とし、それによって第三者ＳＴＡのＮＡＶを設定することになる。あるいは、ＡＰは、管理フレーム交換の前にマルチユーザＲＴＳ（ＭＵ―ＲＴＳ：Multi-user RTS）およびＣＴＳフレームの交換などの保護メカニズムを使用することもできる。しかしながら、ＮＡＶ設定規則がＳＴＡに適用されないので、ＤＬ ＰＰＤＵの受信者であるＳＴＡからの競合のためにＴｒｉｇｇｅｒフレームに遅延が生じるという問題は、解決されない。ＡＰが、ＳＴＡのＡｃｋフレームをＤＬ ＰＰＤＵへ搬送するＵＬ ＰＰＤＵの終端からＳＩＦＳ（Short Interframe Space）後にＴｒｉｇｇｅｒフレームを送信することによって、ＤＬ ＰＰＤＵの受信者であるＳＴＡから上記の競合を回避する試みが可能である。これにより、ＳＴＡのシングルユーザ管理応答／通知フレームが媒体に対して競合することを防止する。しかし、この方法は、ＳＴＡがこの時間内に管理応答／通知フレームを準備することができない場合があるので、必ずしも機能しない可能性がある。これは、いくつかの要因に起因する可能性があり、例えば、ＳＴＡの処理能力、交換される管理フレームの性質、またはＳＴＡが管理要求フレームの受信時に他の処理によりビジー状態にある場合などである。これによって、ＵＬ ＰＰＤＵのＲＵが使われないことになり、媒体の非効率的な使用だけでなく、極端な場合には、第三者ＳＴＡが、媒体がアイドル状態にあると認識し、送信を行い、その結果ＡＰで衝突が発生することにつながる。

この問題を解決するために、本開示では新たな保護メカニズムが導入されている。これは、ＡＰがダウンリンクユニキャストフレームにおいて、ここではＴＦ Ｔｉｍｅｏｕｔと呼ばれるＴｒｉｇｇｅｒフレームタイムアウト（Trigger Frame Timeout）を表す時間を含むことを伴う。ＴＦ Ｔｉｍｅｏｕｔをフレームに含めることは、次のダウンリンクフレームとして、アップリンクフレームを送信するためにＲＵを受信側ＳＴＡに割り当てるＴｒｉｇｇｅｒフレームをタイムアウト時間内に送信するというＡＰの意図を示している。ＴＦ Ｔｉｍｅｏｕｔは、ＴＦ Ｔｉｍｅｏｕｔを搬送するという明確な目的のために定義された新しいエレメントの別個のフィールドとして搬送されてもよいし、既存のエレメントで搬送されてもよい。

図４Ａは、第１の実施形態に係るＴＦ Ｔｉｍｅｏｕｔ時間を搬送するエレメント４００の構成を示す。エレメント４００は、エレメント（Ｅｌｅｍｅｎｔ）ＩＤ４１０と、長さ（Ｌｅｎｇｔｈ）フィールド４２０と、ＴＦ Ｔｉｍｅｏｕｔフィールド４３０とを含む。Ｅｌｅｍｅｎｔ ＩＤ４１０は、エレメントを一意的に識別し、１オクテット長であり、ＩＥＥＥ８０２．１１規格によって定義される。Ｌｅｎｇｔｈフィールド４２０も１オクテット長であり、Ｌｅｎｇｔｈフィールド後のオクテット数を指定する。この例では、Ｌｅｎｇｔｈフィールドは、１オクテットを示している。

ＴＦ Ｔｉｍｅｏｕｔフィールド４３０も１オクテット長であり、その符号化については、図４Ｂのテーブル４５０に示す通りである。ＴＦ Ｔｉｍｅｏｕｔに０が設定されると、Ｔｉｍｅｏｕｔが設定されていないことを示し、ＴＦ Ｔｉｍｅｏｕｔにゼロ以外の値が設定されていた場合は、ＴＦ Ｔｉｍｅｏｕｔがリセットされる。ゼロ以外の値が設定されると、ＴＦ Ｔｉｍｅｏｕｔは、タイムユニット（ＴＵ：Time Unit、１ＴＵ＝１０２４μｓ）のタイムアウト時間を示す。

図５は、この開示によって可能となる例示的なマルチユーザ管理フレーム交換５００を示す。この例におけるフレーム交換シーケンスは、図３で述べたＢｌｏｃｋ Ａｃｋ設定処理のマルチユーザバージョンであり、ＡＰ（Ｏｒｉｇｉｎａｔｏｒ）からのＡＤＤＢＡ ＲｅｑｕｅｓｔフレームとＳＴＡ（Ｒｅｃｉｐｉｅｎｔｓ）からのＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームの交換を伴う。ＡＰが媒体の競合を通じて、媒体を獲得し、ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ宛ての１つ以上のユニキャストＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム５０４、５０６、．．．、５０８を搬送するＯＦＤＭＡ ＤＬマルチユーザＰＰＤＵ５０２を送信することによって、フレーム交換が開始される。「Ｘ、．．．、Ｙ」は、ＸからＹまで昇順に番号付けされたオブジェクトを表す。ＳＴＡｎの文字「ｎ」は、２より大きく、マルチユーザＰＰＤＵで対応可能なＳＴＡの最大数よりも小さい数を表す。

第１の実施形態により、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム５０４、５０６、．．．、５０８のそれぞれは、ＴＦ Ｔｉｍｅｏｕｔフィールド４３０を含むエレメント４００も搬送する。ＴＦ Ｔｉｍｅｏｕｔフィールド４３０は、５１８によって視覚化されたように、時間を示し、その間、各ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム５０４、５０６、．．．、５０８のＲｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓフィールドと一致するアドレスを有するＳＴＡ（ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ）は、それぞれのＵＬフレーム送信のためにＲＵを割り当てるＴｒｉｇｇｅｒフレーム５１０を受信するまで、直前のＤＬ ＰＰＤＵに対する即時確認応答以外のフレームを送信することはできない。ＴＦ Ｔｉｍｅｏｕｔ時間用に使用される適切な値を決定するために、ＡＰは、交換されている管理フレームのタイプまたはＳＴＡの処理能力などのいくつかの要因を考慮する。例えば、ＡＰは、ＡＤＤＴＳフレームが多くのパラメータを含み、ＳＴＡがＡＤＤＴＳフレームを準備するのにより長い時間を必要とする可能性があるので、ＡＤＤＴＳ管理フレームの交換のためにより長いＴＦ Ｔｉｍｅｏｕｔ時間を設定することができる。同様に、ＡＰは、交換に関係するすべてのＳＴＡがより高い能力のクラスＡデバイスである場合には、より短いＴＦ Ｔｉｍｅｏｕｔ時間を設定し、ＳＴＡがより低い能力のクラスＢデバイスである場合には、より長いＴＦ Ｔｉｍｅｏｕｔ時間を設定することができる。

ＡＰのＴＦ Ｔｉｍｅｏｕｔ時間は、以前に実施したＳＴＡとのＢｌｏｃｋ Ａｃｋ Ｓｅｔｕｐに伴うＡＰの経験に基づいて選択してもよい。例えば、ＳＴＡがＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを時間通りに送信できないために、以前に行ったＳＴＡとのＢｌｏｃｋ Ａｃｋ Ｓｅｔｕｐに失敗した場合、ＡＰは、以降のＢｌｏｃｋ Ａｃｋ Ｓｅｔｕｐにおいて、そのようなＳＴＡのために、より長いＴＦ Ｔｉｍｅｏｕｔ時間を選択してもよい。同じフレーム交換に参加しているＳＴＡのグループのＴＦ Ｔｉｍｅｏｕｔ時間は、同じ値にする必要がある。ＴＦ Ｔｉｍｅｏｕｔ時間の計算は、ＡＰのＭＡＣ層内の専用モジュール１８５４によって行うことができ、またはＭＡＣ内のソフトウェア機能として実装することができる。ＴＦ Ｔｉｍｅｏｕｔ時間を受信したＳＴＡは、この時間のカウントダウンするためにＭＡＣ層内に別個のタイマ（ＴＦ Ｔｉｍｅｏｕｔ Ｔｉｍｅｒ１９５４）を実装してもよく、タイマ値が非ゼロである間に任意の送信を制限するＴＸ Ｒｅｓｔｒｉｃｔｉｏｎ Ｆｌａｇ１９５８を設定してもよい。ＡＰから有効なＴｒｉｇｇｅｒフレームを受信し、ＵＬフレーム送信用のＲＵをＳＴＡに割り当てると、ＴＦ Ｔｉｍｅｏｕｔ Ｔｉｍｅｒ１９５４はゼロにリセットされ、ＴＸ Ｒｅｓｔｒｉｃｔｉｏｎ Ｆｌａｇ１９５８はクリアされる。

ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームに対するＡｃｋフレームを受信した後、ＡＰは、Ａｃｋフレームを返信したＳＴＡにＴｒｉｇｇｅｒフレーム５１０を送信して、ＡＤＤＢＡ応答フレームの返信を要求する。前述の他の情報とは別に、Ｔｒｉｇｇｅｒフレーム５１０は、ＳＴＡが直後のＵＬ ＰＰＤＵで送信することができるフレームタイプをＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームに制限するための情報を含む。例示的なシーケンス５００において、Ｔｒｉｇｇｅｒフレーム５１０は、ＲＵ５１２、５１４、．．．、５１６をそれぞれＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎに割り当てる。Ｔｒｉｇｇｅｒフレームは、シングルユーザＰＰＤＵ（Single user PPDU）フォーマットのブロードキャストＴｒｉｇｇｅｒフレームとして送信されてもよく、マルチユーザＰＰＤＵ（Multi-user PPDU）フォーマットの複数のユニキャストＴｒｉｇｇｅｒフレームとして送信されてもよい。

ＳＴＡが時間内にＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを準備することができるとＡＰが確信している場合、ＡＰは、媒体に対して競合し、ＳＴＡからＡｃｋフレームを受信した直後にＴｒｉｇｇｅｒフレーム５１０を送信しようと試みてもよい。あるいは、ＳＴＡにＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを準備するためのより多くの時間を与えるために、送信を少し後で試みることを選択してもよいが、これは、第三者ＳＴＡがＴｒｉｇｇｅｒフレームの送信を先取りするリスクを伴う。このリスクは、管理フレーム交換の前にマルチユーザＲＴＳ（ＭＵ―ＲＴＳ）およびＣＴＳフレームの交換などの保護メカニズムを使用することによって最小限に抑えられる。マルチユーザ管理フレーム交換を保護するためにＭＵ−ＲＴＳ／ＣＴＳ交換または最初のダウンリンクＭＵ ＰＰＤＵで使用されるＴＸＯＰ時間をＡＰがどのように選択するかは、ＴＦ Ｔｉｍｅｏｕｔ時間に依存する。理想的には、管理フレーム交換を第三者ＳＴＡから保護するために、管理フレーム交換全体をカバーするＴＸＯＰ時間が望ましいが、ＴＦ Ｔｉｍｅｏｕｔ時間が比較的長いと、そのような保護は、第三者の端末から不公平と見なされる可能性があるので望ましくない。

より合理的なアプローチは、ＡＰが応答管理フレームを要求するＴｒｉｇｇｅｒフレーム５１０を保護するのにちょうどの長さのＴＸＯＰ時間を設定することであり、Ｔｒｉｇｇｅｒフレーム５１０は、次のフレーム交換を保護するのに十分長いＴＸＯＰ時間で次のＴＸＯＰを開始する。より慎重なアプローチは、ＡｃｋフレームによってダウンリンクＭＵ ＰＰＤＵ５０２の確認応答を行うまでの間だけＴＸＯＰ時間を設定することであり、その場合、第三者ＳＴＡに対する保護はない。管理フレーム交換に関与するＡＰまたはＳＴＡが、Ｔｒｉｇｇｅｒフレームまたはシングルユーザ応答管理フレームを送信するために、どのように媒体に対して競合するかについてもまた、ＴＸＯＰ時間の長さに依存し得る。ＴＸＯＰ時間内で、競合には、ランダムなバックオフを実行せず固定時間、例えば、ＰＩＦＳの間の媒体のセンシングだけを伴い、一方、ＴＸＯＰ時間外では、媒体競合はランダムバックオフも伴う。

Ｔｒｉｇｇｅｒフレーム５１０を受信すると、各ＳＴＡ（ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ）は、ＵＬマルチユーザＰＰＤＵ５２０を送信し、そのＰＨＹヘッダは全帯域を占め、それぞれのＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレーム５２２、５２４、．．．、５２６は、それぞれ割り当てられたＲＵ５１２、５１４、．．．、５１６の狭い帯域を占める。ＵＬマルチユーザＰＰＤＵ５２０を受信すると、ＡＰは、個々のＡｃｋフレーム５３２、５４３、．．．、５３６を搬送するＤＬマルチユーザＰＰＤＵとして確認応答フレーム５３０を、別個のＲＵで送信することによって、フレーム交換を完了する。

図６は、フレーム交換シーケンス５００に非常に類似するフレーム交換シーケンス６００を示すが、１つ以上のＳＴＡが、要求された管理フレームすなわち、この例におけるＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを時間内に準備することができない場合の例を示す。ここで、ＳＴＡ１は、ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを返信することができず、ＳＴＡ１に割り当てられたＲＵは、６１２で示すように空である。そのような場合、ＡＰは、ＳＴＡ１が以前にＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームに対して確認応答をしたことがあるという経験を利用して、ＳＴＡ１が一定時間後にＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームの送信を試みるという知識に基づく仮定を行う。

ＥＤＣＡチャネルアクセスの非効率性を回避するために、ＡＰは、Ａｃｋフレーム６２４、．．．、６２６を、各Ａｃｋフレームが１つのＲＵを占有した状態で、ＳＴＡｓ２、．．．、ＳＴＡｎに搬送する同じＤＬマルチユーザＰＰＤＵにおいて、別のＴｒｉｇｇｅｒフレーム６２２をＳＴＡ１に送信する。Ｔｒｉｇｇｅｒフレーム６２２は、Ａｃｋフレームよりも長いので、ＡＰは、パディングを最小限に抑えるために、Ａｃｋフレームを搬送するＲＵと比較して、Ｔｒｉｇｇｅｒフレームに対してより大きなＲＵを割り当てることができる。さらに、Ｔｒｉｇｇｅｒフレーム６２２は、１つのＳＴＡ、すなわちＳＴＡ１に対してのみＲＵを割り当てるので、ＡＰは、例えば、その周波数帯域内の最大のＲＵ、例えば、２０ＭＨｚの動作帯域内の２４２ ｔｏｎｅ ＲＵを割り当てる可能性が高い。要求されたアップリンクＰＰＤＵは、複数のユーザからの複数のＰＳＤＵといったより一般的な場合ではなく、シングルユーザからＰＳＤＵを搬送するので、これはＴｒｉｇｇｅｒフレームの特別な使用と見なされる。

ＡＤＤＢＡフレーム交換以外の管理フレーム交換のために、ＡＰおよびＳＴＡがＢｌｏｃｋ Ａｃｋ設定を実施済みの場合、ＡＰは、個々のＡｃｋフレーム６２４、．．．、６２６ではなく、単一のＭｕｌｔｉ−ＳＴＡ Ｂｌｏｃｋ Ａｃｋ ｖａｒｉａｎｔフレームを使用して、ＳＴＡｓ２、．．．、ＳＴＡｎからのＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームに対して確認応答することもできる。これはまた、Ｔｒｉｇｇｅｒフレーム６２２とＡｃｋフレームとの間のＲＵサイズのバランスをとるのに役立つ。Ｔｒｉｇｇｅｒフレーム６２０の終端からＳＩＦＳ時間後、ＳＴＡ１は、Ｔｒｉｇｇｅｒフレーム６２２によって割り当てられたＲＵでＡＰにＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレーム６３０を返信する。最後に、ＡＰは、Ａｃｋフレーム６４０を送信することによってフレーム交換を終了する。この例では、ＳＴＡ１のみが最初にＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームの送信に失敗するが、他のＳＴＡも、各ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームの送信に失敗する、またはＳＴＡが第２またはそれ以降のＴｒｉｇｇｅｒフレーム後であっても、ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅ時間の送信に失敗するといった他の多くのシナリオも起こり得る。当業者には、ここで説明した回復動作、すなわち、Ａｃｋフレームと同じＰＰＤＵで別のＴｒｉｇｇｅｒフレームを送信することも、フレーム交換シーケンスを回復するのに機能することは明らかである。ＡＰは、ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームの送信に失敗したＳＴＡの数が予め設定された値未満であるか、または回復の試みがマルチユーザフレーム交換シーケンスのためにＡＰによって予め決定されたタイムアウト時間を超過するまで、その処理を繰り返してもよい。

図７は、ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ（Ｏｒｉｇｉｎａｔｏｒ）と、ＳＴＡが関連付けられているＡＰ（Ｒｅｃｉｐｉｅｎｔ）との間のＢｌｏｃｋ Ａｃｋメカニズムを設定するために使用される別の例示的なマルチユーザ管理フレーム交換シーケンス７００を示す。シングルユーザの場合、ＳＴＡは、ＡＤＤＢＡ ＲｅｑｕｅｓｔをＡＰに送信することによってＡＤＤＢＡフレーム交換を開始する。ＡＰは、複数のＳＴＡからの多くのそのようなリクエストを待機し、ＤＬマルチユーザＰＰＤＵでＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを統合することが常に可能である。しかし、より効率的な方法は、ＳＴＡからのＡＤＤＢＡ Ｒｅｑｕｅｓｔを同期させることであろう。

ＡＰは、Ｂｌｏｃｋ Ａｃｋ設定を要求する可能性が最も高いＳＴＡに関する十分な情報を有すると想定される。ＡＰは、要求していないＢｕｆｆｅｒ Ｓｔａｔｕｓ ＲｅｐｏｒｔをＳＴＡから受動的に収集することによって、事前にそのような情報を収集することができる。または、ＡＰは、ＢＳＲＰ（Buffer Status Report Poll）バリアントＴｒｉｇｇｅｒフレームを使用して、バッファステータスレポート（Buffer Status Report）のためにＳＴＡを能動的にポーリングすることもできる。ある閾値を上回るバッファ負荷を示すＳＴＡは、マルチユーザＢｌｏｃｋ Ａｃｋ設定対象の候補と見なしてもよい。ＡＰは、ＳＴＡがＡＰとの間で設定した既存のトラフィックストリーム（ＴＳ：Traffic Stream）の情報を、マルチユーザＢｌｏｃｋ Ａｃｋ設定のための候補ＳＴＡを決定するために使用することもできる。ＡＰは、候補ＳＴＡ（ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ）からのＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームを要求するＴｒｉｇｇｅｒフレーム７１０を送信することによって、フレーム交換シーケンスを開始する。

Ｔｒｉｇｇｅｒフレーム７１０を受信すると、アドレス指定された各ＳＴＡは、それぞれのＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム７２２、７２４、．．．、７２６を準備し、それらをＵＬマルチユーザＰＰＤＵ７２０内のそれぞれに割り当てられたＲＵで送信する。ＡＰは、それぞれのＡｃｋフレームを搬送するＤＬマルチユーザＰＰＤＵ７３０を送信することにより、ＵＬマルチユーザＰＰＤＵ７２０の受信に対する確認応答をする。すべてのＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを準備し終えると、ＡＰは、媒体に対して競合し、媒体を獲得すると、ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを搬送するＤＬマルチユーザＰＰＤＵ７４０をＳＴＡに送信する。最後に、フレーム交換シーケンスは、各Ａｃｋフレームを搬送するＵＬマルチユーザＰＰＤＵを送信することによって、ＳＴＡによって完結される。

図８は、フレーム交換シーケンス７００に非常に類似した別の管理フレーム交換シーケンス８００を示す。ＡＰは、候補ＳＴＡ（ＳＴＡ１、ＳＴＡ２、．．．、ＳＴＡｎ）からのＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームを要求するＴｒｉｇｇｅｒフレーム８１０を送信することによって、フレーム交換シーケンスを開始する。Ｔｒｉｇｇｅｒフレームを受信すると、アドレス指定された各ＳＴＡは、それぞれのＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームを準備し、それらをＵＬマルチユーザＰＰＤＵ８２０内のそれぞれに割り当てられたＲＵで送信する。この例では、ＡＰは、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームを受信した際のＳＩＦＳ時間内にＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを準備できるくらい十分に速い。ＥＤＣＡの競合の非効率を回避するために、ＳＴＡ毎に、ＡＰは、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームに対するＡｃｋフレームおよび各ＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを集約し、ＵＬ ＰＰＤＵ８２０の終了からＳＩＦＳだけ後に、ＤＬマルチユーザＰＰＤＵ８３０でそれらを送信する。最後に、フレーム交換シーケンスは、各Ａｃｋフレームを搬送するＵＬマルチユーザＰＰＤＵを送信することによって、ＳＴＡによって完結される。この例では、ＡＰが、フレーム交換シーケンス８００全体を完了するのに十分な長さのＴＸＯＰ時間をＴｒｉｇｇｅｒフレーム８１０に設定すると仮定する。

図９Ａは、この開示に従って特定のタイプのフレームを要求するようにカスタマイズ可能なＴｒｉｇｇｅｒフレームの構造を示す。フレーム構造９００は、ＩＥＥＥ８０２．１１ａｘにおいて、ＵＬマルチユーザ送信の要求とリソース割り当てに使用されるＴｒｉｇｇｅｒフレームと呼ばれる特殊な制御フレームとして提案されている。Ｆｒａｍｅ Ｃｏｎｔｒｏｌ９０２、Ｄｕｒａｔｉｏｎ９０４、Ｒｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓ（ＲＡ）９０６、Ｔｒａｎｓｍｉｔｔｅｒ Ａｄｄｒｅｓｓ（ＴＡ）９０８、およびＦｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ（ＦＣＳ）９１８のような共通のＭＡＣフレームフィールドの他に、Ｔｒｉｇｇｅｒフレームは、以下のフィールドも含む。
・ＴｒｉｇｇｅｒフレームによってＲＵを割り当てられたすべてのＳＴＡに対する共通の情報を示すために使用されるＣｏｍｍｏｎ Ｉｎｆｏフィールド９１０、
・特定のユーザ固有の情報を示すために使用される１つ以上のＵｓｅｒ Ｉｎｆｏフィールド９１２、．．．、９１４。ブロードキャストＴｒｉｇｇｅｒフレームは、複数のＵｓｅｒ Ｉｎｆｏフィールドを搬送するが、ユニキャストＴｒｉｇｇｅｒフレームは、単一のＵｓｅｒ Ｉｎｆｏフィールドのみを搬送する。
・任意で、Ｔｒｉｇｇｅｒフレームは、Ｔｒｉｇｇｅｒフレームを拡張し、ＳＴＡに対してＵＬマルチユーザＰＰＤＵを準備するためのより多くの時間を提供するために、Ｐａｄｄｉｎｇフィールド９１６を含んでもよい。

図９Ｂは、Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９１０の構造を示し、以下のサブフィールドを含む。
・Ｔｒｉｇｇｅｒ Ｔｙｐｅサブフィールド９２２は、Ｔｒｉｇｇｅｒフレームのタイプを示す。第１の実施形態では、Ｔｒｉｇｇｅｒ Ｔｙｐｅサブフィールドは、値０（ゼロ）に設定され、Ｂａｓｉｃ Ｔｒｉｇｇｅｒフレームを示す、
・Ｌｅｎｇｔｈサブフィールド９２４は、要求されたＵＬ ＰＰＤＵの長さを示す。
・Ｃａｓｃａｄｅ Ｉｎｆｏｒｍａｔｉｏｎサブフィールド９２６は、１であれば、次のＴｒｉｇｇｅｒフレームが現在のＴｒｉｇｇｅｒフレームに続くことを示す、
・ＣＳ Ｒｅｑｕｉｒｅｄフィールド９２８は、ＳＴＡが応答フレームを送信する前に物理的および仮想的なキャリアセンシング（Ｃａｒｒｉｅｒ Ｓｅｎｓｉｎｇ）を行う必要があるかどうかを示している、
・ＢＷフィールド９３０は、チャネル帯域幅を示す、
・Ｓｕｂｆｉｅｌｄｓ ＣＰ ａｎｄ ＬＴ Ｔｙｐｅ９３２、ＭＵ ＭＩＭＯ ＬＴＦ ｍｏｄｅ９３４、＃ ｏｆ ＬＴＦ９３６、ＳＴＢＣ９３８、ＬＤＰＣ Ｅｘｔｒａ Ｓｙｍｂｏｌ９４０、ＡＰ ＴＸ Ｐｏｗｅｒ９４２およびＰａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎ９４４は、ＰＨＹレイヤがＵＬ ＰＰＤＵを準備および送信するために必要な情報を示す、
・Ｓｐａｔｉａｌ Ｒｅｕｓｅサブフィールド９４６は、媒体のＳｐａｔｉａｌ Ｒｅｕｓｅのための情報を示している、
・ＵＬ ＰＰＤＵのＳＩＧＡ内の予備ビットをどのように設定すべきかを示すＨＥ−ＳＩＧＡ Ｒｅｓｅｒｖｅｄサブフィールド９４８、
・Ｔｙｐｅ−ｄｅｐｅｎｄｅｎｔ ｃｏｍｍｏｎ ｉｎｆｏサブフィールド９５０は、特定のＴｒｉｇｇｅｒフレームタイプに固有の情報を示す。ＩＥＥＥ８０２．１１ａｘで提案されている現在のＢａｓｉｃ Ｔｒｉｇｇｅｒフレームには、Ｔｙｐｅ−ｄｅｐｅｎｄｅｎｔ ｃｏｍｍｏｎ ｉｎｆｏサブフィールドは含まれていない。

図９Ｃは、第１の実施形態で提案されたＴｙｐｅ−ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９５０の構造を示しており、Ｕｓｅｒ Ｉｎｆｏフィールドに示されたＳＴＡがＴｒｉｇｇｅｒフレームに続くＵＬ ＰＰＤＵに含まれる可能性のあるフレームタイプを制限する。Ｂａｓｉｃ Ｔｒｉｇｇｅｒフレームは現在、ＵＬ ＰＰＤＵに含まれる可能性のある応答フレームタイプに制限を課していない。第１の実施形態によれば、２オクテット長のＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールド９５２がＴｙｐｅ−ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９５０に含まれ、以下のサブフィールドを含む。
・１ビット長のＦｒａｍｅ Ｔｙｐｅサブフィールド９５４は、ＵＬ ＰＰＤＵにおいて要求されるフレームタイプを示す。値０は、データ（Ｄａｔａ）フレームを示し、値１は、管理（Ｍａｎａｇｅｍｅｎｔ）フレームを示す。
・４ビット長のＴＩＤ／Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド９５６は、Ｆｒａｍｅ Ｔｙｐｅサブフィールド９５４がＤａｔａフレームを示す場合、ＤａｔａフレームのＴＩＤを示し、Ｆｒａｍｅ Ｔｙｐｅサブフィールド９５４がＭａｎａｇｅｍｅｎｔフレームを示す場合、Ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ Ｓｕｂｔｙｐｅを示す。ＩＥＥＥ８０２．１１規格のＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドのために定義されたＳｕｂｔｙｐｅサブフィールドと同じフレームサブタイプ符号化が使われ、例えば、０がＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム、１３がＡｃｔｉｏｎフレームを示す。
・１オクテット長のＳｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド９５８は、Ｆｒａｍｅ Ｔｙｐｅサブフィールド９５４がＤａｔａフレームを示す場合は予備であり、Ｆｒａｍｅ Ｔｙｐｅサブフィールド９５４がＭａｎａｇｅｍｅｎｔフレームを示す場合、フレームタイプに関するさらなる詳細を示す。Ｓｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド９５８の符号化は、管理フレーム毎に異なる場合がある。例えば、Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド９５６が１３、すなわち管理アクション（Management Action）フレームを示す場合、Ｓｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド９５８は、５ビット長のＡｃｔｉｏｎ Ｃａｔｅｇｏｒｙサブフィールド９７２および３ビット長のＡｃｔｉｏｎ Ｆｉｅｌｄサブフィールド９７４にさらに分割される。Ａｃｔｉｏｎ Ｃａｔｅｇｏｒｙサブフィールド９７２の符号化は、図９Ｆのテーブル９８０に詳述されており、値０〜２１は、ＩＥＥＥ８０２．１１規格で定義されたＡｃｔｉｏｎ ｆｒａｍｅ Ｃａｔｅｇｏｒｙを指定するために使用される。例えば、０がＳｐｅｃｔｒｕｍ Ｍａｎａｇｅｍｅｎｔ Ａｃｔｉｏｎフレームを示し、３がＢｌｏｃｋ Ａｃｋ Ａｃｔｉｏｎフレームを示す。Ａｃｔｉｏｎ Ｆｉｅｌｄサブフィールド９７４は、Ａｃｔｉｏｎフレームカテゴリ内のフレームフォーマットを指定し、Ａｃｔｉｏｎ ＣａｔｅｇｏｒｙがＢｌｏｃｋ Ａｃｋ Ａｃｔｉｏｎフレームを示すときの例が図９Ｇのテーブル９９０に詳述されている。値０〜７の意味は、ＩＥＥＥ８０２．１１規格の関連するセクションで定義されているものと同じであり、例えば、０がＡＤＤＢＡ Ｒｅｑｕｅｓｔ、１がＡＤＤＢＡ Ｒｅｓｐｏｎｓｅを示す。

Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化は、図９Ｄのテーブル９６０に要約されている。

＜第２実施形態＞
第２の実施形態により、ＡＰは、ＨＥ Ｖａｒｉａｎｔ ＨＴ ＣｏｎｔｒｏｌフィールドのＡｇｇｒｅｇａｔｅｄ Ｃｏｎｔｒｏｌ（Ａ―Ｃｏｎｔｒｏｌ）サブフィールド内のＣｏｎｔｒｏｌサブフィールドのうちの１つを使用してＴＦ Ｔｉｍｅｏｕｔを示す。

図１０Ａは、ＩＥＥＥ８０２．１１ａｘで定義されているＨＥ Ｖａｒｉａｎｔ ＨＴ Ｃｏｎｔｒｏｌフィールド１０００のＡ―Ｃｏｎｔｒｏｌサブフィールドのフォーマットを示す。Ａ―Ｃｏｎｔｒｏｌサブフィールドは、１つ以上のＣｏｎｔｒｏｌサブフィールド１０１０、．．．、１０２０の並びと、それに続く、Ａ―Ｃｏｎｔｒｏｌサブフィールドの長さを３０ビットにするために０でパディングされたオプションのＰａｄｄｉｎｇサブフィールド１０３０を含む。各Ｃｏｎｔｒｏｌサブフィールドは、４ビット長のＣｏｎｔｒｏｌ ＩＤサブフィールドと可変長のＣｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎサブフィールドで構成される。Ｃｏｎｔｒｏｌ ＩＤサブフィールドは、Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎサブフィールドで搬送される情報タイプを示し、Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎサブフィールドの長さは、予備以外のＣｏｎｔｒｏｌ ＩＤサブフィールドの値毎に定められる。Ｃｏｎｔｒｏｌ ＩＤ０〜３は、８０２．１１ａｘで定義されており、その詳細は図１０Ｃのテーブル１０６０に示す通りである。図１０Ｂは、第２の実施形態によるＴＦ Ｔｉｍｅｏｕｔを搬送するために使用されるＣｏｎｔｒｏｌサブフィールド１０５０のフォーマットを示す。Ｃｏｎｔｒｏｌ ＩＤサブフィールド１０５２の他に、８ビット長のＴＦ Ｔｉｍｅｏｕｔサブフィールド１０５４を搬送する。サブフィールドが取り得る符号化は、テーブル１０６０の行１０６２に詳述される通りである。ダウンリンクフレームのＭＡＣヘッダでＡ―Ｃｏｎｔｒｏｌサブフィールド内のＴＦ Ｔｉｍｅｏｕｔを搬送することは、ＴＦ Ｔｉｍｅｏｕｔを伝える効率的な方法となり得る。

第２の実施形態により、新しいＴｒｉｇｇｅｒ Ｔｙｐｅが、Ｍａｎａｇｅｍｅｎｔフレームを要求するために使用されるＴｒｉｇｇｅｒフレームに対して定義される。図１１Ａのテーブル１１００は、８０２．１１ａｘで定義された種々のＴｒｉｇｇｅｒ Ｔｙｐｅと共に、行１１０２の、第２の実施形態で提案された、Ｍａｎａｇｅｍｅｎｔフレームを要求するために使用されるＴｒｉｇｇｅｒ Ｔｙｐｅの符号化の例を詳細に示す。Ｍａｎａｇｅｍｅｎｔフレームを要求するために使用される場合、Ｔｒｉｇｇｅｒ Ｔｙｐｅサブフィールド９２２は、Ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ Ｔｒｉｇｇｅｒを示す値に設定される。

図１１Ｂは、Ｔｙｐｅ―Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９５０に含まれるように提案された２オクテット長のＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールド１１００の構造を示し、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールド１１００は、ＡＰが望む特定のＭａｎａｇｅｍｅｎｔフレームをさらに絞り込むために使用され、４ビット長のＦｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１１１２と８ビット長のＳｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド１１１４とを含み、残りの４ビットは予備となる。Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１１１２は、要求されているＭａｎａｇｅｍｅｎｔ ｆｒａｍｅ Ｓｕｂｔｙｐｅを示し、ＩＥＥＥ８０２．１１規格のＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドのために定義されたＳｕｂｔｙｐｅサブフィールドと同じフレームサブタイプ符号化を使用することができる。Ｓｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド１１１４の符号化は、Ｍａｎａｇｅｍｅｎｔフレーム毎に異なり、Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１１１２がＭａｎａｇｅｍｅｎｔ Ａｃｔｉｏｎフレームを示すときの符号化例を図９Ｅに示す。

図１１Ｄのテーブル１１４０は、Ａｃｔｉｏｎ Ｃａｔｅｇｏｒｙが、ＱｏＳ Ａｃｔｉｏｎフレームである１を示す場合の、Ａｃｔｉｏｎ Ｆｉｅｌｄサブフィールド９７４の符号化例を示す。０から６までの値の意味は、ＩＥＥＥ８０２．１１規格の関連するセクションで定義されているものと同じであり、例えば、１がＡＤＤＴＳ Ｒｅｓｐｏｎｓｅを示し、４がＱｏＳ Ｍａｐ ｃｏｎｆｉｇｕｒｅを示す。

図１１Ｅは、Ｕｓｅｒ Ｉｎｆｏフィールド９１２、．．．、９１４のうちの１つの構造１１５０を示し、以下のサブフィールドを含む。
・Ｕｓｅｒ Ｉｎｆｏフィールドが意図するＳＴＡのＡＩＤを搬送するＡＩＤ１２サブフィールド１１５２、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡに割り当てられたＲＵを示すＲＵ Ａｌｌｏｃａｔｉｏｎサブフィールド１１５４、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡによって応答として送信されるアップリンクＰＰＤＵのコードタイプを示すｃｏｄｉｎｇ Ｔｙｐｅサブフィールド１１５６、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡによって応答として送信されるアップリンクＰＰＤＵのＭＣＳを示すＭＣＳサブフィールド１１５８、
・デュアルキャリア変調（ＤＣＭ：Ｄｕａｌ Ｃａｒｒｉｅｒ Ｍｏｄｕｌａｔｉｏｎ）が、Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡによって応答として送信されるアップリンクＰＰＤＵによって使用されるどうかを示すＤＣＭサブフィールド１１６０、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡによって応答として送信されるアップリンクＰＰＤＵの空間ストリームを示すＳＳ Ａｌｌｏｃａｔｉｏｎサブフィールド１１６２、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡによって応答として送信されるアップリンクＰＰＤＵに対するＡＰの想定されるＲＳＳＩを示すＴａｒｇｅｔ ＲＳＳＩサブフィールド１１６４、
・１ビット長のＲｅｓｅｒｖｅｄフィールド１１６５、
・Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒサブフィールド１１５２によって識別されるＳＴＡに固有の情報を示すＴｙｐｅ ｄｅｐｅｎｄｅｎｔ Ｕｓｅｒ Ｉｎｆｏサブフィールド１１６６。第２の実施形態により、Ｔｒｉｇｇｅｒ Ｔｙｐｅサブフィールド９２２がＭａｎａｇｅｍｅｎｔ ｆｒａｍｅ Ｔｒｉｇｇｅｒを示す値に設定されている場合、Ｔｙｐｅ ｄｅｐｅｎｄｅｎｔ Ｕｓｅｒ Ｉｎｆｏサブフィールド１１６６は、Ｍａｎａｇｅｍｅｎｔフレーム交換に関連するユーザ固有の追加情報を搬送する。一例として、ＡＤＤＴＳ ＱｏＳ Ａｃｔｉｏｎフレームの交換中に使用される場合、Ｔｒａｆｆｉｃ Ｓｔｒｅａｍ ＩＤ（ＴＳＩＤ）値を含むことができ、またはＢｌｏｃｋ Ａｃｋ Ａｃｔｉｏｎフレームの交換中に使用される場合、ＴＩＤ値を含むことができる。異なるＵｓｅｒ Ｉｎｆｏフィールドは、異なる値を搬送することができる。

＜第３実施形態＞
第３の実施形態により、ＴＦ Ｔｉｍｅｏｕｔを搬送する別の方法が提案される。新しいエレメントを定義する代わりに、管理フレームによって搬送された既存のエレメントをＡＰが使用して、ＴＦ Ｔｉｍｅｏｕｔを搬送してもよい。

Ｂｌｏｃｋ Ａｃｋ Ａｃｔｉｏｎフレームの場合の例を図１２Ａに示す。ＴＦ Ｔｉｍｅｏｕｔは、ＡＤＤＢＡ Ｅｘｔｅｎｓｉｏｎエレメント１２００で搬送される。Ｅｌｅｍｅｎｔ ＩＤ１２０２は、８０２．１１規格で規定されているように設定される。Ｌｅｎｇｔｈフィールド１２０４は、１オクテットを示し、ＡＤＤＢＡ Ｃａｐａｂｉｌｉｔｉｅｓフィールド１２０６は、図１２Ｂに示すようにカスタマイズされる。既存のＮｏ−Ｆｒａｇｍｅｎｔａｔｉｏｎサブフィールド１２１２以外の残りの７ビットは、現在予備扱いとなっている。第３の実施形態により、予備扱いされているビットのいくつか、例えば、６ビットは、ＴＦ Ｔｉｍｅｏｕｔ１２２４を示すために使用され、残りの１ビットは予備となる。ＴＦ Ｔｉｍｅｏｕｔの符号化は、図１２Ｃのテーブル１２３０に詳述されている通りである。ゼロ値は、ＴＦ Ｔｉｍｅｏｕｔが設定されていないことを示すか、または以前に設定されたＴＦ Ｔｉｍｅｏｕｔをリセットするために使用される。また、値１〜６３は、１〜６３ＴＵのタイムアウト値をそれぞれ示す。第１の実施形態と比較して、第２の実施形態で提案された方法によって設定することができるＴＦ Ｔｉｍｅｏｕｔ範囲は、ＴＦ Ｔｉｍｅｏｕｔを示すために既存のエレメントで使用可能なビット数に依存してより短くなるかもしれないが、実際の実装ではＴＦ Ｔｉｍｅｏｕｔ時間が非常に長くなることは期待されないので、ＡＰの送信を保護するという目標は達成することができる。

第３の実施形態により、第１の実施形態で提案されたＴｒｉｇｇｅｒフレームのバリアントであるＴｒｉｇｇｅｒフレームの別のバリアントが提案される。図１３Ａは、第３の実施形態により、Ｔｙｐｅ−Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９５０に含まれるように提案された２オクテット長のＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールド１３００の構造を示す。Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅサブフィールド１３００は、２ビットのＦｒａｍｅ Ｔｙｐｅサブフィールド１３１０、４ビットのＴＩＤ／Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１３２０および８ビットのＳｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド１３３０を含み、残りの２ビットは予備となる。

残りのサブフィールドは、第１の実施形態で定義されたものと同じであるが、Ｆｒａｍｅ Ｔｙｐｅサブフィールド１３１０の符号化は、図１３Ｂのテーブル１３４０に詳述されている通りであり、８０２．１１規格のＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドに対して定義されたＴｙｐｅサブフィールドの定義と一致する。ＴＩＤ／Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１３２０は、Ｆｒａｍｅ Ｔｙｐｅサブフィールド１３１０がＤａｔａフレームを示す場合には、ＤａｔａフレームのＴＩＤを示し、Ｆｒａｍｅ Ｔｙｐｅサブフィールド１３１０がＭａｎａｇｅｍｅｎｔフレームを示す場合には、Ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ Ｓｕｂｔｙｐｅを示し、Ｆｒａｍｅ Ｔｙｐｅサブフィールド１３１０がＣｏｎｔｒｏｌフレームを示す場合、Ｃｏｎｔｒｏｌ ｆｒａｍｅ Ｓｕｂｔｙｐｅを示す。Ｓｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド１３３０は、Ｆｒａｍｅ Ｔｙｐｅサブフィールド１３１０がＭａｎａｇｅｍｅｎｔフレームを示す場合、フレームタイプに関するさらなる詳細を示し、そうでない場合は、ＤａｔａおよびＣｏｎｔｒｏｌフレームのために予約される。Ｓｕｂｔｙｐｅ Ｓｐｅｃｉｆｉｃサブフィールド１３３０の符号化は、Ｍａｎａｇｅｍｅｎｔフレーム毎に異なり、Ｆｒａｍｅ Ｓｕｂｔｙｐｅサブフィールド１３２０がＭａｎａｇｅｍｅｎｔ Ａｃｔｉｏｎフレームを示す場合の符号化例を図９Ｅに示す。

＜第４実施形態＞
第４の実施形態によれば、ＡＰは、マルチユーザ管理フレーム交換を開始するＤＬマルチユーザＰＰＤＵ内に、ＡＰがＤＬマルチユーザＰＰＤＵに続く次のフレームとして、ＲＵをＳＴＡに割り当てるＴｒｉｇｇｅｒフレームを送信する意図を受信側ＳＴＡに示す、ＴＦ Ｆｌａｇと呼ばれる１つ以上のフラグを含む。ＴＦ Ｆｌａｇは、ＨＥ Ｖａｒｉａｎｔ ＨＴ Ｃｏｎｔｒｏｌフィールド１０００のＡ―ＣｏｎｔｒｏｌサブフィールドのＣｏｎｔｒｏｌサブフィールドのうちの１つで搬送されてもよい。

図１４は、Ｃｏｎｔｒｏｌ ＩＤサブフィールドが０である場合のＣｏｎｔｒｏｌサブフィールド１４５０の構造を示し、この場合、Ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎサブフィールドは、Ｃｏｎｔｒｏｌサブフィールドを含むフレームに対する即時確認応答を搬送するＵＬマルチユーザＰＰＤＵのためのスケジューリング情報を搬送する。Ｃｏｎｔｒｏｌサブフィールド１４５０は、以下のサブフィールドを含む。
・アップリンク応答ＰＰＤＵの長さを示すＵＬ ＰＰＤＵ Ｌｅｎｇｔｈサブフィールド１４５２。
・アップリンク応答ＰＰＤＵを送信するために割り当てられたＲＵを示すＲＵ Ａｌｌｏｃａｔｉｏｎサブフィールド１４５４。
・ＡＰの送信電力を示すＤＬ ＴＸ Ｐｏｗｅｒサブフィールド１４５６。
・ＡＰのターゲット受信電力を示すＵＬ Ｔａｒｇｅｔ ＲＳＳＩサブフィールド１４５８。
・アップリンク応答ＰＰＤＵのために使用されるＭＣＳを示すＵＬ ＭＣＳサブフィールド１４６０。
・Ｃｏｎｔｒｏｌサブフィールド１４５０を含むフレームに続く次のフレームとして、ＲＵをＳＴＡに割り当てて後続のアップリンク応答ＰＰＤＵを送信するためのＴｒｉｇｇｅｒフレームを送信するＡＰの意図を示す、第４の実施形態で提案されたＴＦ Ｆｌａｇ１４６２。

ＴＦフラグ１４６２が１に設定されているとき、送信制限を表し、ＴＦ Ｆｌａｇ１４６２を搬送するフレームの受信者であるＳＴＡは、ＡＰからＲＵを割り当てるＴｒｉｇｇｅｒフレームを受信するまで、またはＴＦ Ｆｌａｇ１４６２を搬送するフレームによって示されるＴＸＯＰ時間が満了するまで、即時確認応答フレームを除いて、媒体上での送信が制限される。言い換えれば、第４の実施形態により、ＴＦ Ｆｌａｇ１４６２を搬送するフレームによって示されるＴＸＯＰ時間は、他の実施形態で提案された暗黙的なＴＦ Ｔｉｍｅｏｕｔとして機能する。Ｔｒｉｇｇｅｒフレームの受信に失敗した場合、ＳＴＡは、ＴＸＯＰが満了すると通常の送信を再開することができる。

図１５のフレーム交換シーケンス１５００は、第４の実施形態によるマルチユーザ管理フレーム交換の一例を示す。Ｂｌｏｃｋ Ａｃｋ Ｓｅｔｕｐのための管理フレーム交換を例にして説明する。ダウンリンクマルチユーザＰＰＤＵ１５１０は、ＳＴＡ（ＳＴＡ１、．．．、ＳＴＡｎ）宛ての複数のユニキャストＡＤＤＢＡ Ｒｅｑｕｅｓｔフレーム１５１２、．．．、１５１６を搬送する。各ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームはまた、ＴＦ Ｆｌａｇ１４６２を１に設定した状態で、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームに対するＡｃｋフレームのＲＵを割り当てるＣｏｎｔｒｏｌサブフィールド１４５０を搬送する。ＰＰＤＵ１５１０はまた、ＡＰがＳＴＡからのＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを要求するＴｒｉｇｇｅｒフレーム１５３０を送信すると想定される時間をカバーするのに十分な長さを有するＴＸＯＰ時間１５２０を設定する。ＴＸＯＰ時間１５２０は、第三者ＳＴＡからＴｒｉｇｇｅｒフレーム１５２０を保護するものとして機能する。ＴＦ Ｆｌａｇ１４６２は、１に設定されているので、Ｔｒｉｇｇｅｒフレーム１５３０が受信されるまで、ＳＴＡは、各自のシングルユーザＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームを送信することが制限される。

ＴＦ Ｆｌａｇを搬送する別の代替方法は、マルチユーザ管理フレーム交換を開始するＤＬマルチユーザＰＰＤＵのＰＨＹヘッダ内の１ビットを使用することであり、例えば、ＨＥ ＳＩＧ−Ｂのｃｏｍｍｏｎ ｂｌｏｃｋフィールドの１ビットである。そのビットが設定されている場合、送信制限は、ＳＩＧ―Ｂ ｕｓｅｒフィールドに割り当てられた非ブロードキャストＲＵを持つすべてのＳＴＡに適用される。

＜無線通信システム＞
図１６は、ＡＰによって開始されるマルチユーザＭａｎａｇｅｍｅｎｔフレーム交換を容易にするために、ＡＰによって実施される例示的な方法１６００を示す。ＳＴＡによって開始されるフレーム交換の場合の例も同様であり、したがって説明を省略する。１６１０において、上位層アプリケーションからの情報に基づいて、またはＡＰのバッファ内にあるＤａｔａフレームに基づいて、ＡＰは、ＡＰがＭａｎａｇｅｍｅｎｔフレーム交換を開始しようとするＳＴＡのグループを選択する。ＡＰは、グループの選択中、ＳＴＡの能力などの他の要因も考慮することができる。例えば、能力が高いクラスＡのＳＴＡを１つのグループにまとめ、能力の低いクラスＢのＳＴＡを別のグループにまとめるなどである。

同様の情報に基づいて、１６２０において、ＡＰは、ＴＦ Ｔｉｍｅｏｕｔに対して使用される値、またはＴＦ Ｆｌａｇの方法が使用される場合に使用される適切なＴＸＯＰ時間も決定する。１６３０において、ＡＰは、ユニキャスト管理フレームを搬送するためのマルチユーザＰＰＤＵを構築し、マルチユーザＰＰＤＵは、ＴＦ ＴｉｍｅｏｕｔまたはＴＦ Ｆｌａｇを含む。１６４０において、媒体に対して競合した後、ＡＰは、マルチユーザＰＰＤＵを送信する。１６５０において、ＡＰは、各応答管理フレームを返信するためのＲＵをＳＴＡに割り当てるＴｒｉｇｇｅｒフレームを構築し、適切な時間待機した後、Ｔｒｉｇｇｅｒフレームを送信する。１６６０において、ＳＴＡから応答管理フレームを受信すると、ＡＰは、各Ａｃｋフレームを搬送するマルチユーザＰＰＤＵを送信する。ＳＴＡのいずれかが応答管理フレームの返信に失敗した場合、ＡＰは、マルチユーザＰＰＤＵに、そのようなＳＴＡそれぞれに対してＲＵを割り当てるブロードキャストまたは単一／複数のユニキャストＴｒｉｇｇｅｒフレームも含める。このステップは、ＴＸＯＰ時間が満了するまで、またはＡＰが関連するすべてのＳＴＡから応答管理フレームを受信するまで、必要に応じて繰り返すことができる。

図１７は、ＡＰによって開始されたマルチユーザＭａｎａｇｅｍｅｎｔフレーム交換に参加するためにＳＴＡによって実施される例示的な方法１７００を示す。ＳＴＡによって開始されたフレーム交換の場合の例も同様であり、したがって説明を省略する。１７１０において、ＳＴＡは、ＡＰによって送信されたマルチユーザＰＰＤＵを受信し、ＰＨＹヘッダからの関連情報に基づいて、ＳＴＡ宛ての管理フレームを抽出する。１７２０において、ＳＴＡは、受信した管理フレームの処理とは別に、ＴＦ ＴｉｍｅｏｕｔフィールドまたはＴＦ Ｆｌａｇのいずれかを抽出し、ＴＦ Ｔｉｍｅｏｕｔ時間、またはＴＦ Ｆｌａｇの方法が使用される場合、残りのＴＸＯＰ時間に初期化されるタイマを開始する。タイマが非ゼロである間、ＳＴＡは、受信した管理フレームに対する即時確認応答以外のフレーム送信を控える。

１７３０において、ＳＴＡは、ＡＰからの要求を受け入れ、Ｔｒｉｇｇｅｒフレームを待つ場合、応答管理フレームを準備する。１７４０において、ＡＰからＴｒｉｇｇｅｒフレームを受信すると、タイマがリセットされ、ＳＴＡは、準備した応答管理フレームを、ＴｒｉｇｇｅｒフレームによってＳＴＡに割り当てられたＲＵで送信する。一方、ＳＴＡがＡＰからＴｒｉｇｇｅｒフレームを受信する前にタイマが満了すると、送信制限が解除され、ＳＴＡは自由に競合して、シングルユーザＰＰＤＵフォーマットで応答管理フレームを送信する。

＜アクセスポイントの構成＞
図１８は、例示的なＡＰ１８００のブロック図であり、ＡＰ１８００は、図１のＡＰ１９０であってもよい。ＡＰ１８００は、メモリ１８２０、二次記憶装置１８４０、１つ以上の無線通信インタフェース１８５０、および他の有線通信インタフェース１８８０に結合された中央処理装置（ＣＰＵ：Central Processing Unit）１８３０を含む。二次記憶装置１８４０は、関連する命令コード、データなどを永続的に記憶するために使用される不揮発性のコンピュータ可読記憶媒体であってもよい。起動時に、ＣＰＵ１８３０は、実行のために命令コードおよび関連データを揮発性メモリ１８２０にコピーしてもよい。命令コードは、ＡＰ１８００の動作に必要なオペレーティングシステム、ユーザアプリケーション、デバイスドライバ、実行コードなどであってもよい。命令コードのサイズ、したがって、二次記憶装置１８４０およびメモリ１８２０の両方の記憶容量は、ＳＴＡ１７００の記憶容量よりもかなり大きくてもよい。

ＳＴＡ１８００は、電源１８１０を備えてもよく、多くの場合、電源１８１０は、電源幹線でもよいが、場合によっては、車載バッテリーなどの大容量バッテリーでもよい。有線通信インタフェース１８８０は、イーサネット（登録商標）インタフェース、電力線インタフェース、または電話回線インタフェースなどでもよい。無線通信インタフェース１８５０は、セルラ通信用のインタフェース、Ｚｉｇｂｅｅ（登録商標）などの短距離通信プロトコル用のインタフェースを備えてもよく、またはＷＬＡＮインタフェースでもよい。

無線インタフェース１８５０は、ＭＡＣモジュール１８５２およびＰＨＹモジュール１８６０をさらに含んでもよい。ＡＰのＭＡＣモジュール１８５２は、ＳＴＡ１９００のＭＡＣモジュールよりもかなり複雑であり、多くのサブモジュールを含んでもよい。サブモジュールの中でも特に、ＭＡＣモジュール１８５２は、方法１６００のステップ１６２０の実行を担うＴＦ Ｔｉｍｅｏｕｔ計算部１８５４を備えてもよい。ＭＡＣモジュール１８５２はまた、Ｔｒｉｇｇｅｒフレーム内のＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅを表すのに使用される符号化のテーブル１８５６を格納してもよい。ＰＨＹモジュールは、ＭＡＣモジュールデータと送信／受信信号間の変換を担う。無線インタフェースはまた、ＰＨＹモジュールを介して、無線媒体上の／無線媒体からの無線通信信号の実際の送信／受信を担う１つ以上のアンテナ１８７０に結合されてもよい。

特定の実施形態では、オペレーティングシステムは、リアルタイムオペレーティングシステム（ＲＴＯＳ）を備え、ユーザアプリケーションは、ウェブブラウザまたはスマートフォンアプリを備え、デバイスドライバは、ＷＬＡＮドライバを備え、実行コードは、ＣＰＵ１８３０によって実行されることで、メソッド１６００を実行させる。実施形態に応じて、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化テーブル１８５６は、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化９６０、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化１１３０、またはＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化１３４０を表すことができる。Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化テーブル１８５６は、製造時にデフォルト値と共に記憶されてもよいが、ＡＰ１８００は、必要に応じて、現行のネットワーク条件に従ってこれらを微調整し、例えば、ａｓｓｏｃｉａｔｉｏｎ処理の間、メンバＳＴＡに新規テーブルの内容を通知してもよい。または、ＡＰ１８００は、Ｂｅａｃｏｎフレームのようないくつかの周期的なフレーム内の情報エレメントで新しいテーブル内容をアドバタイズすることを選択してもよい。

ＡＰ１８００は、分かりやすくするために図１８には図示していない多くの他の構成要素を備えてもよい。本開示に最も関連する構成要素のみが図示されている。

＜ＳＴＡの構成＞
図１９は、例示的なＳＴＡ１９００のブロック図であり、図１のＳＴＡのいずれか１つであってもよい。ＳＴＡ１９００は、メモリ１９２０、二次記憶装置１９４０、および１つ以上の無線通信インタフェース１９５０に結合された中央処理装置（ＣＰＵ）１９３０を含む。

二次記憶装置１９４０は、関連する命令コード、データなどを永続的に記憶するために使用される不揮発性のコンピュータ可読記憶媒体であってもよい。起動時に、ＣＰＵ１９３０は、実行のために命令コードおよび関連データを揮発性メモリ１９２０にコピーしてもよい。命令コードは、ＳＴＡ１９００の動作に必要なオペレーティングシステム、ユーザアプリケーション、デバイスドライバ、実行コードなどであってもよい。ＳＴＡ１９００はまた、電源１９１０、例えば、リチウムイオン電池またはコインセル電池などを備えてもよい。無線通信インタフェース１９５０は、セルラ通信用のインタフェース、またはＺｉｇｂｅｅなどの短距離通信プロトコル用のインタフェースを備えてもよく、またはＷＬＡＮインタフェースでもよい。

無線インタフェース１９５０は、ＭＡＣモジュール１９５２およびＰＨＹモジュール１９６０をさらに含んでもよい。サブモジュールの中でも特に、ＭＡＣモジュール１９５２は、ＴＦ Ｔｉｍｅｏｕｔフィールド、またはＴＦ Ｆｌａｇの方法が使用される場合のＴＸＯＰ時間のいずれかに基づいて送信制限期間を追跡するＴＦ Ｔｉｍｅｏｕｔタイマ１９５４を備えてもよい。ＭＡＣモジュール１９５２は、送信制限状態を記録するＴＸ Ｒｅｓｔｒｉｃｔｉｏｎ Ｆｌａｇ１９５８を維持してもよく、フラグがセットされている場合、ＳＴＡは、即時確認応答以外のフレーム送信を控える。ＭＡＣモジュール１９５２はまた、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化を表すために使用されるビット符号化のテーブル１９５６を格納してもよい。ＰＨＹモジュールは、ＭＡＣモジュールデータと送信／受信信号間の変換を担う。無線インタフェースはまた、ＰＨＹモジュールを介して、無線媒体上の／無線媒体からの無線通信信号の実際の送信／受信を担う１つ以上のアンテナ１９７０に結合されてもよい。

特定の実施形態では、オペレーティングシステムは、リアルタイムオペレーティングシステム（ＲＴＯＳ）を備え、ユーザアプリケーションは、ウェブブラウザまたはスマートフォンアプリを備え、デバイスドライバは、ＷＬＡＮドライバを備え、実行コードは、ＣＰＵ１９３０によって実行されることで、メソッド１７００を実行させる。ＴＦ Ｔｉｍｅｏｕｔタイマ１９５４は、ＴＦ Ｔｉｍｅｏｕｔを追跡するために１７２０で使用される。実施形態に応じて、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化テーブル１９５６は、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化９６０、Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化１１３０、またはＰｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化１３４０を表すことができる。Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化テーブル１９５６は、製造時にデフォルト値と共に格納されてもよい。Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅの符号化テーブル１９５６は、ａｓｓｏｃｉａｔｉｏｎ処理中にＡＰによって通知される値に従って、またはＢｅａｃｏｎフレームのような周期的なフレームでＡＰによって定期的にアドバタイズされる値に基づいて更新されることも可能である。

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

上述した実施形態では、一例として、本開示をハードウェアで構成したが、ハードウェアと協働するソフトウェアで実現してもよい。

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

また、回路の集積化は、ＬＳＩに限らず、ＬＳＩ以外の専用回路や汎用プロセッサで実現してもよい。ＬＳＩの製造後、プログラマブルなＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩの回路セルの接続や設定の再構成が可能なリコンフィギュラブルプロセッサを用いてもよい。

ＬＳＩに置き換わる集積回路化技術が、半導体技術やその技術に由来する他の技術の進歩の結果として現れた場合、そのような技術を用いて機能ブロックを統合することができる。別の可能性は、バイオテクノロジーなどの応用である。

本開示は、効率的な方法で複数の無線装置間の管理フレームの交換を可能にするために使用することができる。

１００ 無線ネットワーク
１１０，１２０，１３０，１４０，１５０，１６０，１９００ ＳＴＡ
１９０，１８００ ＡＰ
１８１０，１９１０ 電源
１８２０，１９２０ メモリ
１８３０，１９３０ ＣＰＵ
１８４０，１９４０ 二次記憶装置
１８５０，１９５０ 無線インタフェース
１８５２，１９５２ ＭＡＣモジュール
１８５４ ＴＦ Ｔｉｍｅｏｕｔ計算部
１８５６，１９５６ Ｐｒｅｆｅｒｒｅｄ Ｒｅｓｐｏｎｓｅ Ｔｙｐｅテーブル
１８６０，１９６０ ＰＨＹモジュール
１８７０，１９７０ アンテナ
１８８０ 有線通信インタフェース
１９５４ ＴＦ Ｔｉｍｅｏｕｔタイマ
１９５８ ＴＸ Ｒｅｓｔｒｉｃｔｉｏｎ Ｆｌａｇ

Claims (12)

1. アップリンクマルチユーザ（ＵＬ ＭＵ）送信用リソースを割り当てるためのＴｒｉｇｇｅｒフレームを送信し、前記Ｔｒｉｇｇｅｒフレームは、複数のトリガタイプのうちの１つを示すタイプサブフィールドを含む共通情報フィールドを含み、前記複数のトリガタイプは、受信端末局から任意のタイプの応答フレームを要求するために使用される基本トリガを示す第１のトリガタイプと、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを要求するために使用される特定のトリガを示す第２のトリガタイプとを含む、送信部と、
   前記タイプサブフィールドが前記第２のトリガタイプを示す場合、前記複数の端末局から前記特定のタイプのＵＬ ＭＵ応答フレームを受信する受信部と、
   を有する送信装置。
2. 前記タイプサブフィールドが前記第２のトリガタイプを示す場合、前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のそれぞれに要求されるフィードバックタイプを示すフィードバックタイプサブフィールドを含む、
   請求項１に記載の送信装置。
3. 前記特定のタイプのＵＬ ＭＵ応答フレームは、マルチユーザ管理フレーム交換のための複数の管理フレームタイプのうちの１つである、
   請求項１に記載の送信装置。
4. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のそれぞれに対するユーザ情報フィールドを含み、前記ユーザ情報フィールドは、前記複数の端末局のうちの対応する１つの端末局が使用する１つ以上のリソースユニット（ＲＵ）を示すＲＵ割当サブフィールドを含む、
   請求項１に記載の送信装置。
5. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のうちの１つと前記複数の端末局のそれぞれに対するユーザ情報フィールドとを関連付けるための複数のビットを搬送するＡＩＤサブフィールド、を含み、前記ユーザ情報フィールドは、前記複数の端末局のうちの対応する１つの端末局が使用する１つ以上のリソースユニット（ＲＵ）を示すＲＵ割当サブフィールドを含み、前記ＲＵ割当サブフィールドが示す前記１つ以上のＲＵは、前記ＡＩＤサブフィールドによって示される１つの端末局に関連付けられる、
   請求項１に記載の送信装置。
6. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局による確認応答（ＡＣＫ）フレーム以外のフレーム送信が制限される送信制限時間を示すタイムアウトサブフィールドを含む、
   請求項１に記載の送信装置。
7. アップリンクマルチユーザ（ＵＬ ＭＵ）送信用リソースを割り当てるためのＴｒｉｇｇｅｒフレームを送信し、前記Ｔｒｉｇｇｅｒフレームは、複数のトリガタイプのうちの１つを示すタイプサブフィールドを含む共通情報フィールドを含み、前記複数のトリガタイプは、受信端末局から任意のタイプの応答フレームを要求するために使用される基本トリガを示す第１のトリガタイプと、複数の端末局から特定のタイプのＵＬ ＭＵ応答フレームを要求するために使用される特定のトリガを示す第２のトリガタイプとを含む、工程と、
   前記タイプサブフィールドが前記第２のトリガタイプを示す場合、前記複数の端末局から前記特定のタイプのＵＬ ＭＵ応答フレームを受信する工程と、
   を含む送信方法。
8. 前記タイプサブフィールドが前記第２のトリガタイプを示す場合、前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のそれぞれに要求されるフィードバックタイプを示すフィードバックタイプサブフィールドを含む、
   請求項７に記載の送信方法。
9. 前記特定のタイプのＵＬ ＭＵ応答フレームは、マルチユーザ管理フレーム交換のための複数の管理フレームタイプのうちの１つである、
   請求項７に記載の送信方法。
10. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のそれぞれに対するユーザ情報フィールドを含み、前記ユーザ情報フィールドは、前記複数の端末局のうちの対応する１つの端末局が使用する１つ以上のリソースユニット（ＲＵ）を示すＲＵ割当サブフィールドを含む、
    請求項７に記載の送信方法。
11. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局のうちの１つと前記複数の端末局のそれぞれに対するユーザ情報フィールドとを関連付けるための複数のビットを搬送するＡＩＤサブフィールド、を含み、前記ユーザ情報フィールドは、前記複数の端末局のうちの対応する１つの端末局が使用する１つ以上のリソースユニット（ＲＵ）を示すＲＵ割当サブフィールドを含み、前記ＲＵ割当サブフィールドが示す前記１つ以上のＲＵは、前記ＡＩＤサブフィールドによって示される１つの端末局に関連付けられる、
    請求項７に記載の送信方法。
12. 前記Ｔｒｉｇｇｅｒフレームは、前記複数の端末局による確認応答（ＡＣＫ）フレーム以外のフレーム送信が制限される送信制限時間を示すタイムアウトサブフィールドを含む、
    請求項７に記載の送信方法。

Images