JP6515203B2 - Ｗｌａｎシステムにおけるトリガーされた送信機会および複数ユーザａｃｋ手順 - Google Patents

Description

本発明は、無線通信に関する。

関連出願の相互参照
本出願は、その内容が参照により本明細書に組み込まれている、２０１５年４月２９日に出願された米国特許仮出願第６２／１５４，４４２号明細書の利益を主張するものである。

ローカルエリアネットワーク（ＬＡＮ）において動作するステーション（ＳＴＡ）とアクセスポイント（ＡＰ）との間の確認応答（ＡＣＫ）ポリシーをネゴシエートするための方法およびシステムが提供される。ＳＴＡからＡＰへの変更されたアップリンク要求フレーム（ＵＬＲ）の送信が提供される。ＵＬＲフレームは、ＳＴＡが１つまたは複数の送信機会（transmission opportunities）を要求しているトラフィックストリームに関連する情報を含むことができる。関連する情報は、トラフィックストリームに関連付けられている決定された優先順位と、要求されるＡＣＫタイプとを含むことができる。送信機会は、シングルユーザ送信機会、マルチユーザ送信機会の一部、またはピアツーピア送信機会のうちの１つまたは複数であってもよい。

さらに、優先順位および／または確認応答ポリシー表示（indication）を備えるデータおよび／またはトリガーフレームを受信するための方法およびシステムも提供される。データフレームは、複数のＳＴＡのデータを含むことができるシングルユーザデータフレームまたはマルチユーザ（ＭＵ）データフレームであってもよい。

アップリンク送信およびダウンリンク送信の両方のデータパケットは、多入力多出力（ＭＵ−ＭＩＭＯ）送信リソースを占有することができる。
１つまたは複数のＭＵブロックＡＣＫ（ＢＡ）フレームは、ＡＰから１つまたは複数のＳＴＡへのＡＣＫを信号伝達するために使用されてもよい。

さらに詳細な理解は、添付の図面と併せて例として示した、以下の説明から獲得され得る。
１つまたは複数の開示される実施形態が実施されることができる例示の通信システムのシステム図である。 図１Ａに示される通信システム内で使用されることができる例示のワイヤレス送信／受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示される通信システム内で使用されることができる例示の無線アクセスネットワークおよび例示のコアネットワークのシステム図である。 第１の例示の複数ステーション（マルチＳＴＡ）ブロック確認応答（ＢＡ）制御フレームのフォーマットを示す図である。 第２の例示のマルチＳＴＡ ＢＡ制御フレームのフォーマットを示す図である。 アップリンク要求（ＵＬＲ）フレームの例示的な設計を示す図である。 アップリンク要求フレーム、トリガーフレーム、シングルユーザ（ＳＵ）およびマルチユーザ（ＭＵ）データフレームにおける優先順位および確認応答（ＡＣＫ）ポリシー表示手順の例を示す図である。 アップリンク要求フレーム、トリガーフレーム、およびＭＵデータフレームにおける優先順位およびＡＣＫポリシー表示手順の第２の例を示す図である。 スケジュールフレームにおける優先順位およびＡＣＫポリシーネゴシエーション手順の例を示す図である。 アグリゲーションブロックＡＣＫ（Ａ−ＢＡ）セッションスケジューリングフレームの例を示す図である。

図１Ａは、１つまたは複数の開示される実施形態が実施されることができる例示の通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのようなコンテンツを、複数のワイヤレスユーザに提供する多重アクセスシステムであり得る。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスできるようにすることができる。たとえば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などのような、１つまたは複数のチャネルアクセス方法を採用することができる。

図１Ａにおいて示されるように、通信システム１００は、ワイヤレス送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、およびその他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは各々、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスであってもよい。一例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャー、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサー、家庭用電化製品などを含むことができる。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂは各々、コアネットワーク１０６、インターネット１１０、および／またはその他のネットワーク１１２のような１つまたは複数の通信ネットワークへのアクセスを容易にするため、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェイスをとるように構成された任意のタイプのデバイスであってもよい。一例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ Ｂ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであってもよい。基地局１１４ａ、１１４ｂは各々単一の要素として示されるが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。

基地局１１４ａはＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなどのような、その他の基地局および／またはネットワーク要素（図示せず）を含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されることもある特定の地理的領域内のワイヤレス信号を送信および／または受信するように構成されてもよい。セルは、セルセクタにさらに分割されてもよい。たとえば、基地局１１４ａに関連付けられているセルは、３つのセクタに分割されてもよい。したがって、１つの実施形態において、基地局１１４ａは、３つの送受信機、すなわちセルのセクタごとに１つの送受信機を含むことができる。もう１つの実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することができるので、セルの各セクタに対して複数の送受信機を使用することができる。

基地局１１４ａ、１１４ｂは、エアインターフェイス１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインターフェイス１１６は（たとえば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光線など）任意の適切なワイヤレス通信リンクであってもよい。エアインターフェイス１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

さらに具体的には、前述のように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどのような、１つまたは複数のチャネルアクセススキームを採用することができる。たとえば、ＲＡＮ１０４内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェイス１１６を確立することができるＵｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ：ユニバーサル移動体通信システム）Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（ＵＴＲＡ：地上波無線アクセス）のような無線技術を実施することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＥｖｏｌｖｅｄ ＨＳＰＡ（ＨＳＰＡ＋）のような通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。

もう１つの実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を使用してエアインターフェイス１１６を確立することができるＥｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）のような無線技術を実施することができる。

その他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などのような無線技術を実施することができる。

図１Ａの基地局１１４ａは、たとえば、ワイヤレスルータ、Ｈｏｍｅ Ｎｏｄｅ Ｂ、Ｈｏｍｅ ｅＮｏｄｅ Ｂ、またはアクセスポイントであってもよく、事業所、家庭、車両、キャンパスなどのような、局在的な領域においてワイヤレス接続を容易にするために任意の適切なＲＡＴを使用することができる。１つの実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立するためにＩＥＥＥ８０２．１１のような無線技術を実施することができる。もう１つの実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立するためにＩＥＥＥ８０２．１５のような無線技術を実施することができる。さらにもう１つの実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラーベースのＲＡＴ（たとえば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を使用して、ピコセルまたはフェムトセルを確立することができる。図１Ａにおいて示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂが、コアネットワーク１０６を介してインターネット１１０にアクセスすることは必要とされなくてもよい。

ＲＡＮ１０４は、コアネットワーク１０６と通信することができ、コアネットワーク１０６は音声、データ、アプリケーション、および／またはｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであってもよい。たとえば、コアネットワーク１０６は、コール制御、課金サービス、モバイルロケーションベースのサービス、プリペイドコール、インターネット接続、ビデオ配信などを提供すること、および／またはユーザ認証のような高水準のセキュリティ機能を実行することができる。図１Ａにおいて示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６が、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用するその他のＲＡＮと直接または間接的に通信できることが理解されよう。たとえば、Ｅ−ＵＴＲＡ無線技術を使用していることがあるＲＡＮ１０４に接続されていることに加えて、コアネットワーク１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信することもできる。

コアネットワーク１０６はまた、ＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのゲートウェイとしての役割を果たすこともできる。ＰＳＴＮ１０８は、従来のアナログ電話回線サービス（ＰＯＴＳ）を提供する回線交換電話ネットワークを含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートの伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）のような、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含むことができる。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または操作される有線またはワイヤレスの通信ネットワークを含むことができる。たとえば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用することができる１つまたは複数のＲＡＮに接続された別のコアネットワークを含むこともできる。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全部は、マルチモード能力（capabilities）を含むことができる、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄはさまざまなワイヤレスリンクを介してさまざまなワイヤレスネットワークと通信するための複数の送受信機を含むことができる。たとえば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用することができる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、例示のＷＴＲＵ１０２を示すシステム図である。図１Ｂにおいて示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不可能なメモリ１３０、取り外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２が、前述の要素の任意の部分的組み合わせを含むことができ、引き続き実施形態に整合することが理解されよう。

プロセッサ１１８は、汎用プロセッサ、特殊用途プロセッサ、標準的なプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のタイプの集積回路（ＩＣ）、状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境で動作できるようにする任意の他の機能を実行することができる。プロセッサ１１８は、送信／受信要素１２２に結合されることができる送受信機１２０に結合されてもよい。図１Ｂはプロセッサ１１８および送受信機１２０を別個のコンポーネントとして示すが、プロセッサ１１８および送受信機１２０が電子パッケージまたはチップに共に統合されてもよいことが理解されよう。

送信／受信要素１２２は、エアインターフェイス１１６を介して基地局（たとえば、基地局１１４ａ）に信号を送信するか、または基地局から信号を受信するように構成されてもよい。たとえば、１つの実施形態において、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。もう１つの実施形態において、送信／受信要素１２２は、たとえば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器であってもよい。さらにもう１つの実施形態において、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および受信するように構成されてもよい。送信／受信要素１２２は、ワイヤレス信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。

加えて、図１Ｂにおいて、送信／受信要素１２２は単一の要素として示されるが、ＷＴＲＵ１０２は任意の数の送信／受信要素１２２を含むことができる。さらに具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、１つの実施形態において、ＷＴＲＵ１０２は、エアインターフェイス１１６を介してワイヤレス信号を送信および受信するために２つ以上の送信／受信要素１２２（たとえば、複数のアンテナ）を含むことができる。

送受信機１２０は、送信／受信要素１２２によって送信されるべき信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成されてもよい。前述のように、ＷＴＲＵ１０２は、マルチモード能力を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が、たとえばＵＴＲＡおよびＩＥＥＥ８０２．１１のような複数のＲＡＴを介して通信できるようにするための複数の送受信機を含むことができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（たとえば、液晶ディスプレイ（ＬＣＤ）表示ユニット、または有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されてもよく、これらの機器からユーザ入力データを受信することができる。プロセッサ１１８はまた、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、取り外し不可能なメモリ１３０および／または取り外し可能メモリ１３２のような、任意のタイプの適切なメモリから情報にアクセスし、適切なメモリにデータを格納することができる。取り外し不可能なメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意のタイプのメモリストレージデバイスを含むことができる。取り外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含むことができる。その他の実施形態において、プロセッサ１１８は、サーバ上、またはホームコンピュータ（図示せず）上のような、ＷＴＲＵ１０２に物理的に位置していないメモリから情報にアクセスし、そのようなメモリにデータを格納することができる。

プロセッサ１１８は、電源１３４から電力を受信することができ、ＷＴＲＵ１０２内のその他のコンポーネントへの電力の配電および／または制御を行なうように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってもよい。たとえば、電源１３４は、１つまたは複数の乾電池（たとえば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含むことができる。

プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（たとえば、緯度および経度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェイス１１６を介して位置情報を受信すること、および／または２つ以上の近隣の基地局から受信されている信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２が、任意の適切な位置決定の方法を用いて位置情報を取得することができ、引き続き実施形態に整合することが理解されよう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合されてもよく、周辺機器１３８は、追加の特徴、機能、および／または有線もしくはワイヤレス接続を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる。たとえば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線装置、デジタル音楽プレイヤー、メディアプレイヤー、テレビゲームプレイヤーモジュール、インターネットブラウザなどを含むことができる。

図１Ｃは、１つの実施形態によるＲＡＮ１０４およびコアネットワーク１０６を示すシステム図である。前述のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインターフェイス１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、コアネットワーク１０６と通信することもできる。

ＲＡＮ１０４はｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含むことができるが、引き続き実施形態に整合しながら、ＲＡＮ１０４は任意の数のｅＮｏｄｅ−Ｂを含むことができることが理解されよう。ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは各々、エアインターフェイス１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数の送受信機を含むことができる。１つの実施形態において、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃはＭＩＭＯ技術を実施することができる。したがって、たとえば、ｅＮｏｄｅ−Ｂ１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信することができる。

ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは各々、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理の決定、ハンドオーバーの決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示されるように、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェイスを介して相互に通信することができる。

図１Ｃに示されるコアネットワーク１０６は、モビリティ管理エンティティゲートウェイ（ＭＭＥ）１４２、サービス提供ゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含むことができる。前述の要素は各々、コアネットワーク１０６の一部として示されているが、それらの要素のうちのいずれかがコアネットワークオペレータ以外のエンティティによって所有および／または操作されてもよいことが理解されよう。

ＭＭＥ１４２は、Ｓ１インターフェイスを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃの各々に接続されてもよく、制御ノードとしての役割を果たすことができる。たとえば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中に特定のサービス提供ゲートウェイを選択することなどに責任を負うことができる。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡのような他の無線技術を採用するその他のＲＡＮ（図示せず）とを切り替えるための制御プレーン機能を提供することもできる。

サービス提供ゲートウェイ１４４は、Ｓ１インターフェイスを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃの各々に接続されてもよい。サービス提供ゲートウェイ１４４は一般に、ユーザデータパケットを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でルーティングおよび転送することができる。サービス提供ゲートウェイ１４４はまた、ｅＮｏｄｅ−Ｂ間ハンドオーバー中にユーザプレーンを固定すること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに使用可能な場合にページングをトリガーすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理して格納することなどのようなその他の機能を実行することもできる。

サービス提供ゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６に接続されてもよく、ＰＤＮゲートウェイ１４６は、インターネット１１０のようなパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応のデバイスとの間の通信を容易にすることができる。

コアネットワーク１０６は、その他のネットワークとの通信を容易にすることができる。たとえば、コアネットワーク１０６は、ＰＳＴＮ１０８のような回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上通信線通信デバイスとの間の通信を容易にすることができる。たとえば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインターフェイスとしての役割を果たすＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、またはＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、その他のサービスプロバイダによって所有および／または操作される他の有線またはワイヤレスネットワークを含むことができるネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

その他のネットワーク１１２は、ＩＥＥＥ８０２．１１ベースのワイヤレスローカルエリアネットワーク（ＷＬＡＮ）１６０にさらに接続されてもよい。ＷＬＡＮ１６０は、アクセスルータ１６５を含むことができる。アクセスルータは、ゲートウェイ機能を含むことができる。アクセスルータ１６５は、複数のアクセスポイント（ＡＰ）１７０ａ、１７０ｂと通信することができる。アクセスルータ１６５とＡＰ１７０ａ、１７０ｂの間の通信は、有線イーサネット（ＩＥＥＥ８０２．３標準）、または任意のタイプのワイヤレス通信プロトコルを介してもよい。ＡＰ１７０ａは、ＷＴＲＵ１０２ｄとエアインターフェイスを介してワイヤレス通信する。

インフラストラクチャ基本サービスセット（ＢＳＳ）モードにおけるＷＬＡＮは、ＢＳＳのアクセスポイント（ＡＰ）、およびＡＰに関連付けられている１つまたは複数のステーション（ＳＴＡ）を有する。ＡＰは通常、分散システム（ＤＳ）またはＢＳＳのトラフィック流入および流出を搬送する別のタイプの有線／ワイヤレスネットワークへのアクセスまたはインターフェイスを有する。ＢＳＳの外部から生じるＳＴＡへのトラフィックは、ＡＰを経由して到着し、ＳＴＡに配信される。ＢＳＳの外部の宛先へのＳＴＡから生じるトラフィックは、それぞれの宛先に配信されるようにＡＰに送信される。ＢＳＳ内のＳＴＡ間のトラフィックはまた、ＡＰを経由して送信されてもよく、ここでソースＳＴＡはトラフィックをＡＰに送信し、ＡＰはトラフィックを宛先ＳＴＡに配信する。ＢＳＳ内のＳＴＡ間のそのようなトラフィックは、実際に、ピアツーピア（Ｐ２Ｐ）トラフィックである。そのようなＰ２Ｐトラフィックはまた、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネル化ＤＬＳ（ＴＤＬＳ）を使用する直接リンクセットアップ（ＤＬＳ）によりソースＳＴＡと宛先ＳＴＡの間で直接送信されてもよい。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有していないので、ＳＴＡは相互に直接通信する。通信のこのモードは、通信の「アドホック」モードと称される。

８０２．１１ａｃインフラストラクチャ動作モードを使用して、ＡＰは、固定チャネル、通常は１次チャネルで、ビーコンを送信することができる。このチャネルは、２０ＭＨｚ幅であってもよく、ＢＳＳの動作チャネルである。このチャネルはまた、ＡＰとの接続を確立するためにＳＴＡによって使用される。８０２．１１システムの基本的チャネルアクセスメカニズムは、キャリア感知多重アクセス衝突回避（ＣＳＭＡ／ＣＡ）である。この動作モードにおいて、ＡＰを含むあらゆるＳＴＡは、１次チャネルを感知する。チャネルがビジー状態であると検出される場合、ＳＴＡは、バックオフする。したがって、１つのＳＴＡのみが所与のＢＳＳにおいて任意の所与の時間に送信することができる。

ＩＥＥＥ８０２．１１ｎにおいて、高スループット（ＨＴ）ＳＴＡはまた、通信のために４０ＭＨｚ幅のチャネルを使用することができる。これは、１次２０ＭＨｚチャネルを、隣接の２０ＭＨｚチャネルと結合して、４０ＭＨｚ幅の連続チャネルを形成することによって達成される。

ＩＥＥＥ８０２．１１ａｃにおいて、超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚ、および８０ＭＨｚのチャネルは、上記で説明されている８０２．１１ｎと同様に、連続する２０ＭＨｚチャネルを結合することによって形成される。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを結合すること、または８０＋８０構成と称されることもある、２つの非連続の８０ＭＨｚチャネルを結合することによって形成されてもよい。８０＋８０構成の場合、データは、チャネルエンコーディング後に、それを２つのストリームに分割するセグメントパーサを通過する。逆高速フーリエ変換（ＩＦＦＴ）および時間ドメイン処理は、各ストリームで別々に行なわれる。次いで、ストリームは、２つのチャネルにマップされ、データが送信される。受信機において、このメカニズムは逆転され、結合されたデータはＭＡＣに送信される。

サブ１ＧＨｚの動作モードは、ＩＥＥＥ８０２．１１ａｆおよび８０２．１１ａｈによってサポートされる。これらの仕様について、チャネル動作帯域幅、およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるそれらに応じて低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルの５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用する１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚ帯域幅をサポートする。８０２．１１ａｈの可能なユースケースは、マクロカバレッジエリアにおけるメータータイプ制御（ＭＴＣ）デバイスのサポートである。ＭＴＣデバイスは、限られた帯域幅のサポートのみを含むが、非常に長いバッテリ寿命の要件も含む、限定された能力を有することができる。

ＩＥＥＥ８０２．１１ｎ、ＩＥＥＥ８０２．１１ａｃ、ＩＥＥＥ８０２．１１ａｆ、およびＩＥＥＥ８０２．１１ａｈのような、複数のチャネルおよびチャネル幅をサポートするＷＬＡＮシステムは、１次チャネルと指定されるチャネルを含む。１次チャネルは、ＢＳＳ内のすべてのＳＴＡによってサポートされる最大共通動作帯域幅と等しい帯域幅を有することができるが、これは必須ではない。したがって、１次チャネルの帯域幅は、最小帯域幅動作モードをサポートするＢＳＳで動作しているＳＴＡのグループのＳＴＡによって制限される。ＩＥＥＥ８０２．１１ａｈの例において、たとえＢＳＳ内のＡＰおよびその他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、またはその他のチャネル帯域幅動作モードをサポートすることができるとしても、１ＭＨｚモードのみをサポートするＳＴＡ、たとえばＭＴＣタイプのデバイスがある場合、１次チャネルは、１ＭＨｚ幅であってもよい。すべてのキャリア検知、およびＮＡＶ設定は、１次チャネルのステータスに依存する、すなわち、たとえば１ＭＨｚ動作モードのみをサポートするＳＴＡがＡＰに送信しているので、１次チャネルがビジー状態である場合、使用可能な周波数帯域全体は、その大部分がアイドル状態であり使用可能であったとしても、ビジー状態であると見なされる。

米国において、８０２．１１ａｈによって使用されることができる使用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚである。それは韓国においては９１７．５ＭＨｚから９２３．５ＭＨｚであり、日本においては９１６．５ＭＨｚから９２７．５ＭＨｚである。８０２．１１ａｈに使用可能な合計帯域幅は、国識別コードに応じて６ＭＨｚから２６ＭＨｚである。

スペクトル効率を高めるため、ＩＥＥＥ８０２．１１ａｃでは、たとえばダウンリンクＯＦＤＭシンボル中、同じシンボルの時間フレームにおける複数のＳＴＡへのダウンリンクマルチユーザＭＩＭＯ（ＭＵ−ＭＩＭＯ）送信の概念を導入した。ダウンリンクＭＵ−ＭＩＭＯの使用の可能性はまた、ＩＥＥＥ８０２．１１ａｈに対して現在考慮されている。ダウンリンクＭＵ−ＭＩＭＯは、ＩＥＥＥ８０２．１１ａｃにおいて使用されているように、同じシンボルタイミングを複数のＳＴＡに使用するので、複数のＳＴＡへの波形送信の干渉が問題とはならないことに留意するのは重要である。しかし、ＡＰとのＭＵ−ＭＩＭＯ送信に関与するすべてのＳＴＡは、同じチャネルまたは帯域を使用する必要があり、動作帯域幅を、ＡＰとのＭＵ−ＭＩＭＯ送信に含まれるＳＴＡによってサポートされる最小チャネル帯域幅に制限することになる。

たとえチャネルコーディングおよびインターリービングのような保護メカニズムが送信を保護するために使用される場合であっても、ワイヤレス送信は、信頼できないことがある。したがって、コレクトパケット受信の確認応答（ＡＣＫ）のためのメカニズムがＷＬＡＮシステムに導入された。それに宛てられたデータフレームを正常に受信するＳＴＡまたはＡＰは、フレームを受信した直後、または遅れて、肯定応答を送信する。フレームを送信するＳＴＡまたはＡＰは、所定の時間内にＡＣＫを受信しない場合、データフレームが正しく受信されなかったと仮定して、データフレームを再送信することができる。すべてのデータフレームがこのように確認応答されることができるわけではないことに留意されたい。ＩＥＥＥ８０２．１１標準はまた、データフレームの受信者から明示的に確認応答が予期されていないことを発信者が表示する場合、「Ｎｏ ＡＣＫ」をサポートする。

ブロック確認応答（ＢＡ）は、８０２．１１ｅ改訂で導入された。ＢＡは、複数のフレームの受信者が、データフレームのブロックを確認応答するために単一ブロックＡＣＫを送信できるようにすることによって、システム効率を高める。これはまた、プリアンブルおよびヘッダが一度しか送信されることができないようにするので、オーバーヘッドを大幅に低減する。２つのＢＡ方法、１）即時ブロックＡＣＫ、および２）遅延ブロックＡＣＫ、が導入された。

ＩＥＥＥ８０２．１１ａｈにおいて、同期フィールド（ＳＴＦ）、ロングトレーニングフィールド（ＬＴＦ）、および制御シグナリング（ＳＩＧ）フィールドを単に使用するショートＡＣＫパケットフォーマットが提案されてきた。既存のＷＬＡＮ技術は、アグリゲートＭＡＣプロトコルデータユニット（ＡＭＰＤＵ）およびアグリゲートＭａｃサービスデータユニット（ＡＭＳＤＵ）のようなシングルユーザ（ＳＵ）アグリゲーションメカニズムを有するが、必須のＭＵアグリゲーションメカニズムはない。ＤＬ ＭＵ−ＭＩＭＯは、８０２．１１ａｃにおいて導入され、これはＭＵアグリゲーション方法であるが、オプションであって、ポーリングされたＡＣＫをＵＬで個々に送信するものとして制限されている。これは、特に、より短いパケットに対して、オーバーヘッドを追加する。また、ＤＬ方向のＭＵ ＡＣＫ／ＢＡアグリゲーションは、既存のＷｉＦｉ仕様において使用可能ではない。

近年、２．４ＧＨｚおよび５ＧＨｚ帯域の高密度のシナリオを含む多数の使用シナリオにおいてワイヤレスユーザの広範なスペクトルのすべてのユーザが体験するサービス品質を高めるように、可能な将来の修正の範囲および目的を検討するために、ＩＥＥＥ８０２．１１ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ ＷＬＡＮ（ＨＥＷ） Ｓｔｕｄｙ Ｇｒｏｕｐ（ＳＧ）が創設された。ＡＰおよびＳＴＡの高密度の配備をサポートする新しいユースケース、ならびに関連する無線リソース管理（ＲＲＭ）技術が、ＨＥＷ ＳＧによって考察されている。

ＨＥＷの潜在的な用途は、スタジアムイベントのデータ配信のような新興の使用シナリオ、鉄道駅または企業／小売り環境のような高いユーザ密度のシナリオ、ならびに医療用途向けのビデオ配信およびワイヤレスサービスに対する依存度の高まりを示す証拠も含む。

ＩＥＥＥ標準化委員会は、ＨＥＷ ＳＧで開発されたＰｒｏｊｅｃｔ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＰＡＲ）およびＣｒｉｔｅｒｉａ ｆｏｒ Ｓｔａｎｄａｒｄｓ Ｄｅｖｅｌｏｐｍｅｎｔ（ＣＳＤ）に基づいてＩＥＥＥ８０２．１１ａｘ Ｔａｓｋ Ｇｒｏｕｐ（ＴＧ）を承認した。

ＴＧａｘ標準委員会において、さまざまなアプリケーションについて測定されたトラフィックが、ショートパケットへの高い可能性を有すること、およびショートパケットを生成することもできるネットワークアプリケーションがあることを、複数の寄稿が示した。これらのアプリケーションは、仮想オフィス、ＴＰＣ ＡＣＫ、ビデオストリーミングＡＣＫ、デバイス／コントローラ（マウス、キーボード、ゲームコントロールなど）、アクセス−プローブ要求／応答、ネットワーク選択（プローブ要求、ＡＮＱＰ）、およびネットワーク管理−制御フレームを含む。

さらに、ＴＧａｘにおける多くの寄稿は、ＵＬおよびＤＬ ＯＦＤＭＡならびにＵＬおよびＤＬ ＭＵ−ＭＩＭＯを含むＭＵ機能の導入を提案した。ＵＬ ＭＵ送信に応じて送信されるＤＬ確認応答を多重化するためのメカニズムを設計し定義することは、ＴＧａｘ ＳＦＤにおいて明白に求められている。

既存のＷＬＡＮは、ショートパケット／ペイロードに対し高いオーバーヘッドおよび／または遅延を有するので、ＭＡＣ効率を高めてショートパケット／バーストに対するＴＧａｘのメディアアクセスオーバーヘッドおよび／または遅延を低減する解決策を提供すること、ＤＬおよびＵＬ ＯＦＤＭＡならびにＭＵ−ＭＩＭＯを含むＭＵ機能の効果的なＡＣＫおよびその他の潜在的なフィードバック情報アグリゲーションスキームを提供すること、ならびに同時ＭＵショートパケット送信を可能にする効果的な技法を提供することが望まれる。

２０１５年３月のＴＧａｘ標準化委員会において、アップリンク ＭＵ送信後に複数のＳＴＡを確認応答するためにマルチＳＴＡブロックＡＣＫ制御フレームを使用するフレームワークが提案された。マルチＳＴＡ ＢＡ制御フレームの２つのフォーマットが提案された。

図２は、マルチＳＴＡブロック確認応答（ＢＡ）フレーム２００の第１の例示的なフレームフォーマット図である。このフレームフォーマットは、フレームがマルチＳＴＡ ＢＡであるという表示の追加を含む変更を伴う、複数トラフィック識別子（マルチＴＩＤ）ＢＡフレームフォーマットを再使用することによって定義される。また、各ＢＡ情報フィールドは、異なるＳＴＡに宛てられてもよい。ＢＡフレームフォーマットは、フレーム制御フィールド２０２、期間／ＩＤフィールド２０４、ＲＡ２０６、ＴＡ２０８、ＢＡ制御フィールド２１０、ＢＡ情報フィールド２１２、およびＦＣＳフィールド２１４を含むことができる。ＢＡ制御フィールド２１０は、ＢＡＲ ＡＣＫポリシーフィールド２１６、マルチＴＩＤフィールド２１８、圧縮ビットマップ２２０、リトライを用いるグループキャスト（ＧＣＲ）フィールド２２２、後の使用のために予約されたフィールド２２４、およびＴＩＤ＿ＩＮＦＯフィールド２２６を含むことができる。ＢＡ情報フィールド２１２は、ＴＩＤごとの情報フィールド２２８、ＢＡ開始シーケンス制御フィールド２３０、およびＢＡビットマップ２３２を含むことができる。ＴＩＤごとの情報フィールドのビットＢ０〜Ｂ１０は、ＢＡ情報フィールドの意図された受信者を識別する部分ＡＩＤを搬送することができる。

図３は、マルチＳＴＡ ＢＡフレーム３００の第２のフレームフォーマット図である。このフレームフォーマットは、ＢＡの代わりに、ＳＴＡごとのＡＣＫ表示を可能にする変更を伴う、マルチＴＩＤ ＢｌｏｃｋＡｃｋフレームフォーマットを再使用することによって定義される。ＢＡフレームは、フレーム制御３０２、期間／ＩＤフィールド３０４、ＲＡ３０６、ＴＡ３０８、ＢＡ制御フィールド３１０、ＢＡ情報フィールド３１２、およびＦＣＳ３１４を備える。ＢＡ制御フィールド２１０は、ＢＡＲ ＡＣＫポリシー３１６、マルチＴＩＤフィールド３１８、圧縮ビットマップ３２０、ＧＣＲフィールド３２２、後の使用のために予約されたフィールド３２４、およびＴＩＤ＿ＩＮＦＯフィールド３２６を備える。ＢＡ情報フィールド３１２は、ＴＩＤごとの情報フィールド３２８、ブロック開始シーケンス制御フィールド３３０、およびＢＡビットマップ３３２を備えることができる。ＢＡ情報フィールド３１２において、ＴＩＤごとの情報フィールド３２８のＢ１１ ３３４が設定される場合、ＢｌｏｃｋＡｃｋビットマップ３３２およびブロック開始シーケンス制御サブフィールド３３０は存在せず、このＢＡ情報フィールド３１２は、ＴＩＤごとの情報フィールド３２８に表示されるＡＩＤを伴うＳＴＡのＡＣＫを表示する。

ＢＳＳにおいて、ＡＰに関連付けられているＳＴＡは、異なる能力を有することができる。たとえば、一部のＳＴＡは、ＵＬおよびＤＬ ＭＵ−ＭＩＭＯの両方、またはＵＬおよびＤＬ ＯＦＤＭＡの両方が可能であってもよい。その他のＳＴＡは、ＤＬ ＭＵ−ＭＩＭＯおよび／またはＤＬ ＯＦＤＭＡのみが可能であってもよいが、ＵＬ ＭＵ−ＭＩＭＯおよび／またはＵＬ ＯＦＤＭＡは可能ではない。異なるＳＴＡに使用される確認応答スキームは、ＳＴＡの能力に応じて異なっていてもよい。加えて、ＳＴＡに使用される確認応答スキームは、異なるトラフィック優先順位に対して異なっていてもよい。パケットの受信側ＳＴＡが確認応答を送信側ＳＴＡに提供する方法を認識するように、送信のためのトラフィック優先順位およびＡＣＫポリシー、ならびに送信機会（ＴＸＯＰ：transmission opportunities）を表示するための、効率的な手順を有することが望ましい。

ポーリングＡＣＫメカニズムは、ＤＬ ＭＵ−ＭＩＭＯについてＩＥＥＥ８０２．１１ａｃにおいて導入されており、後方互換性のためにＤＬ ＯＦＤＭＡに使用されてもよい。しかし、ＡＣＫをＵＬで個別に送信することによって生じる大きなオーバーヘッドにより、これはＤＬ ＭＵ技術には効率的ではない。したがって、ＤＬ ＯＦＤＭＡおよび／またはＤＬ ＭＵ−ＭＩＭＯに対してより効率的なメカニズムおよび手順を設計することが望ましい。

ＤＬ方向のＡＣＫ／ＢＡアグリゲーションは、既存のＷＬＡＮ仕様において使用可能ではない。ＵＬ ＯＦＤＭＡおよびＵＬ ＭＵ−ＭＩＭＯを含めるＵＬ ＭＵ機能のＴＧａｘへの導入に伴って、ＴＧａｘ ＳＦＤにおいてＵＬ ＭＵ送信に応じて送信されるＤＬ確認応答を多重化するためのメカニズムを定義することが明白に求められている。

ＳＴＡは、ＳＴＡが１つまたは複数のアップリンクＴＸＯＰを要求しているパケットまたはトラフィックに関する優先順位およびその他の情報を含む情報をアップリンク要求フレームの一部としてＡＰに提供することができる。ＴＸＯＰは、ＳＵ ＴＸＯＰ、またはマルチユーザ（ＭＵ）ＴＸＯＰの一部、またはＰ２Ｐ ＴＸＯＰであってもよい。アップリンク要求フレームの例示的な設計は図４に示される。

図４は、アップリンク要求フレーム４００の例示的な設計である。アップリンク要求フレーム４００は、プリアンブル４０２、ＭＡＣヘッダ４０４、フレームボディ４０６、およびＦＣＳフィールド４０８のうちの１つまたは複数を含むことができる。プリアンブルフィールド４０２、ＭＡＣヘッダ４０４、および／またはフレームボディ４０６、および／またはアップリンク要求フレームの任意の他の部分は、１つまたは複数のトラフィック情報フィールド４１０〜４１４を含むことができる。トラフィック情報フィールドは、本明細書に開示されている１つまたは複数のフィールドを含むことができる。

ＴＩＤフィールド４１６は、ＳＴＡがＵＬまたはＰ２Ｐ ＴＸＯＰを要求しているトラフィックフローのＩＤの１つまたは複数を表示することができる。ＴＩＤフィールド４１６はまた、１つまたは複数のＴＩＤを表示するために、ハッシュ、ビットマップ、またはその組み合わせとして実施されてもよい。

優先順位フィールド４１８は、ＳＴＡがＵＬまたはＰ２Ｐ ＴＸＯＰを要求しているトラフィックまたはパケットの優先順位を表示することができる。

サイズフィールド４２０は、パケットのサイズ、または表示された優先順位および／もしくはトラフィックフローのトラフィック量を表示するために使用されてもよい。サイズは、バッファに入れられているパケットまたはトラフィックを送信するために必要とされるビット、バイト、または予想される時間もしくはＴＸＯＰ（ｎｓ、ＴＵ、または任意の他の時間単位）の数によって表示されてもよい。あるいは、サイズフィールドは、何らかの時間単位あたり、たとえばＴＸＯＰ間隔あたり、ｍｓあたり、秒あたり、ＴＵあたり、または任意の他の間隔に、予想されるトラフィックを表示するために使用されてもよい。１つまたは複数のビットは、表示されるトラフィックが現在バッファ内にあるか、または将来予想されることを表示するために使用されてもよい。

遅延情報フィールド４２２は、表示されるトラフィックの耐容遅延を表示するために使用されてもよい。それは、表示されるトラフィックがすでにＳＴＡにおいて経験しているキューイング遅延の量を表示するために使用されてもよい。これは、ＴＸＯＰが、たとえば各ＴＸＯＰ間隔からのカウント、ＴＳＦタイマー値、またはアップリンク要求フレームの送信もしくは終わりから、または、スケジュールされたＴＷＴ時間、たとえばスケジュールされたＴＷＴの開始時間など、特定の遅延間隔の範囲内でスケジュールされるべきであることを受信側ＳＴＡに表示するために使用されてもよい。

要求されるＴＸＯＰタイプフィールド４２４は、送信側ＳＴＡが要求している、たとえば表示されるトラフィックまたはパケットの、ＴＸＯＰのタイプの１つまたは複数を表示するために使用されてもよい。要求されるＴＸＯＰタイプは、ＳＵ ＴＸＯＰ、ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰであってもよい。要求されるＴＸＯＰタイプフィールドは、整数、ハッシュテーブル、またはビットマップとして実施されてもよい。本明細書において説明される要求されるＴＸＯＰについて、追加の情報が含まれてもよい。

ＴＸＯＰのＳＵおよびＭＵタイプの場合、要求されるＴＸＯＰの帯域幅および／またはリソースユニット（ＲＵ）の数が、表示されてもよい。加えて、チャネルおよび／またはＲＵのプリファレンスも含まれてもよい。

ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰの場合、空間ストリームの数が表示されてもよい。アップリンク要求フレームは、受信側ＳＴＡによるＭＩＭＯ送信のチャネルを推定するために、ＬＴＦまたはその他のフィールドを含むことができる。アップリンク要求フレームは、ＭＩＭＯ送信のチャネルを推定するために、受信側ＳＴＡによって使用されてもよい。

すべてのＴＸＯＰについて、要求されるＴＸＯＰの期間が表示されてもよい。また、要求されるＴＸＯＰが周期的なものであることが表示されてもよい。

ＴＸＯＰ周波数フィールド４２６は、要求されるＴＸＯＰの周波数を表示するために使用されてもよい。周波数は、ｎｓ、ｍｓ、ＴＵ、または任意のその他の時間単位の数で指定されてもよい。付加的に、または代替として、要求されるＴＸＯＰ間隔は、指定されてもよい。

ＡＣＫタイプフィールド４２８は、受信側ＳＴＡが、送信側ＳＴＡから正常に受信されたパケットに応答するときに、受信側ＳＴＡが使用すべき要求されるＡＣＫのタイプのうちの１つまたは複数を表示するために使用されてもよい。可能な要求されるＡＣＫタイプは、本明細書において開示される１つまたは複数のＡＣＫタイプを含むことができる。

通常のＡＣＫタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＡＣＫであってもよい。

通常の即時ＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい。

遅延の通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい。

遅延マルチＳＴＡ ＡＣＫ／ＢＡタイプは、後の時点にマルチＳＴＡ ＡＣＫ／ＢＡパケットの一部として送信されるマルチＳＴＡ ＡＣＫ／ＢＡであってもよく、これはレガシー帯域幅上で送信されてもよい。

即時マルチＳＴＡ ＢＡ／ＡＣＫタイプは、たとえばＳＩＦＳ間隔後など、データパケットの送信の直後にマルチＳＴＡ ＢＡ／ＡＣＫパケットの一部として送信されるマルチＳＴＡ ＢＡ／ＡＣＫであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅上で送信されてもよい。

スケジュール済みマルチＳＴＡ ＢＡ／ＡＣＫタイプは、スケジュールされた時間に送信されるマルチＳＴＡ ＢＡパケットの一部として送信されるマルチＳＴＡ ＢＡ／ＡＣＫであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅またはリソース割り当てフレームによって割り当てられるリソース上で送信されてもよい。

即時高効率（ＨＥ）ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さいチャネル、たとえば５ＭＨｚチャネル、ならびに／またはデータパケットおよびアグリゲートパケットが送信されるＭＩＭＯチャネル上で、送信されてもよい。

即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡであってもよい。ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さい、たとえば５ＭＨｚチャネルの、データパケットおよびアグリゲートパケットが送信されるチャネル上で、送信されてもよい。

即時ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＭＩＭＯ ＡＣＫ／ＢＡであってもよい。ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば、データパケットおよびアグリゲートパケットが送信される、同じＭＩＭＯチャネル上で、送信されてもよい。

スケジュール済みＨＥ ＡＣＫ／ＢＡタイプは、たとえばＡＣＫ ＲＡＷで、スケジュールされた時間において送信されてもよいＨＥ ＡＣＫ／ＢＡであってもよい。ＨＥ ＡＣＫは、リソース割り当てフレームによって割り当てられたリソースを使用して送信されてもよい。

もう１つの設計において、ＡＣＫタイプフィールド４２８は、ＡＣＫサブタイプおよびタイミングタイプという２つのサブフィールドを使用するものとして実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ／ＢＡ、ＨＥ ＡＣＫ／ＢＡ、ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

さらにもう１つの設計において、ＡＣＫタイプ４２８は、ＡＣＫサブタイプ、リソースタイプ、およびタイミングタイプという３つのサブフィールドを使用して実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ／ＢＡ、ＨＥ ＡＣＫ／ＢＡであってもよい。リソースタイプは、レガシー帯域幅、ＯＦＤＭＡ、ＭＩＭＯ、ＯＦＤＭＡ／ＭＩＭＯであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

アップリンク要求フレームの任意の部分またはその任意の組み合わせは、アクションフレーム、アクションＮｏ Ａｃｋフレーム、または管理、制御フレーム、拡張フレーム、ＮＤＰフレーム、ＮＤＰ搬送ＭＡＣ情報フレームの任意の他のタイプのような新しい制御フレームまたは新しい管理フレームとして実施されてもよく、また、情報要素、サブ要素、または管理、制御、拡張、ＮＤＰもしくはデータフレームのフィールドもしくはサブフィールドのセットもしくはサブセット、またはＭＡＣ／ＰＬＣＰヘッダの一部として実施されてもよい。

アップリンク要求フレームまたはその任意の部分はまた、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵのような、現在のアグリゲートされたパケットの送信後に、送信側ＳＴＡにおいてトラフィック情報の受信側ＳＴＡを更新するために、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵの一部として送信されてもよい。

例示的なＡＣＫ、優先順位表示、およびＴＸＯＰ要求手順は、本明細書において開示される。１つの実施形態において、ＳＴＡは、１つまたは複数のトラフィックストリームまたはＴＩＤについてそのバッファまたは予想されるトラフィックを調べてもよく、バッファに入れられているトラフィックまたは将来予想されるトラフィックについてＵＬ、および／またはＤＬ ＴＸＯＰもしくはＰ２Ｐ ＴＸＯＰを要求する。

もう１つの実施形態において、ＳＴＡは、１つまたは複数のパケットまたはトラフィックストリームの優先順位をアップリンク要求（ＵＬＲ）で表示することができる。さらに、ＳＴＡは、バッファに入れられているトラフィックがバッファ内にあった時間、またはバッファ内のトラフィックが、それらを送信するためにＴＸＯＰが割り当てられる必要があるまでに許容できる最大遅延をＵＬＲで表示することができる。受信側ＳＴＡは、表示されたトラフィックの優先順位に部分的に基づいて、バッファ内のトラフィックが、送信側ＳＴＡにＴＸＯＰが割り当てられる必要があるまでに許容できる遅延を計算することができる。

ＳＴＡは、トラフィックストリームまたは将来のトラフィックに必要とされる周波数またはＴＸＯＰ間隔をＵＬＲで表示することができる。受信側ＳＴＡは、表示されたトラフィックの優先順位に部分的に基づいて、トラフィックストリームまたはＴＩＤが、ＴＸＯＰ間隔ごとに送信側ＳＴＡにＴＸＯＰが割り当てられる必要があるまでに許容できる遅延を計算することができる。

ＳＴＡは、要求しているＴＸＯＰのタイプ、たとえばＳＵ ＴＸＯＰ、ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰの１つまたは複数、ならびに帯域幅、またはＲＵの数、空間ストリームの数、期間などのような、表示された要求されるＴＸＯＰに関連する詳細な情報をＵＬＲで表示することができる。ＵＬ ＯＦＤＭＡおよび／またはＵＬ ＭＵ−ＭＩＭＯに対応していないＳＴＡは、ＯＦＤＭＡおよび／またはＭＵ ＭＩＭＯ ＴＸＯＰであるＴＸＯＰを要求しないものとする。

ＳＴＡは、要求されるＴＸＯＰを要求している要求されるＡＣＫタイプ、たとえば通常のＡＣＫ／ＢＡ、遅延ＢＡ、スケジュール済みＡＣＫ／ＢＡ、即時マルチＳＴＡ ＡＣＫ／ＢＡ、遅延マルチＳＴＡ ＡＣＫ／ＢＡ、スケジュール済みマルチＳＴＡ ＡＣＫ／ＢＡ、通常のＨＥ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、通常のＨＥ ＭＩＭＯ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ／ＭＩＭＯ ＡＣＫ／ＢＡ、スケジュール済みＨＥ ＡＣＫ／ＢＡなどの１つまたは複数をＵＬＲで表示することができる。受信側ＳＴＡがＯＦＤＭＡおよび／またはＭＵ−ＭＩＭＯまたはＭＩＭＯパケットを送信できないことをＳＴＡが認識している場合、ＳＴＡはＯＦＤＭＡおよび／またはＭＵ ＭＩＭＯまたはＭＩＭＯ ＡＣＫを要求しないものとする。

ＳＴＡは、ＴＸＯＰを取得する場合、１つまたは複数のＵＬＲフレームを、ＡＰまたは別のＳＴＡに送信することができる。あるいは、ＳＴＡは、１つまたは複数のＵＬＲフレームを、ＵＬＲに使用されるアクセス間隔に、ＡＰまたは別のＳＴＡに送信することができる。ＳＴＡはまた、１つまたは複数のＵＬＲフレームを、ＳＴＡに割り当てられているリソースを介してスケジュールされている時間に、ＡＰまたは別のＳＴＡに送信することができる。

ＳＴＡは、ＡＰもしくは別のＳＴＡに送信されるか、またはブロードキャストアドレスに送信されるか、またはＡＰもしくは別のＳＴＡがそのメンバーであるＳＴＡのグループに送信される、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵのような、アグリゲートフレームのＡＰまたは別のＳＴＡへの１つまたは複数のＵＬＲフレームを含むことができる。

加えて、または代替的に、ＳＴＡは、ＴＸＯＰネゴシエーションフレームを使用して、ＡＰとのＴＸＯＰおよびＡＣＫ設定をネゴシエートすることができる。ＴＸＯＰネゴシエーションフレームは、優先順位、要求されるＴＸＯＰタイプ、ＡＣＫタイプのフィールドのうちの１つまたは複数を含むことができる。これらのフィールドは、上記で説明されるようなものであってもよい。要求側ＳＴＡは、１つもしくは複数の優先順位値、要求される１つもしくは複数の要求されるＴＸＯＰタイプ、および／または１つもしくは複数のＡＣＫタイプを表示することができる。そのようなＴＸＯＰネゴシエーション、またはその１つもしくは複数のフィールドもしくはサブフィールドは、プローブ要求または（再）アソシエーション要求に含まれてもよい。

加えて、または代替的に、ＡＰは、ＴＸＯＰネゴシエーション応答フレームを使用して、ＳＴＡとのＴＸＯＰおよびＡＣＫ設定を割り当てることができ、これはＴＸＯＰネゴシエーションフレームに応答するものであってもよい。ＴＸＯＰネゴシエーション応答フレームは、優先順位、ＴＸＯＰタイプ、ＡＣＫタイプのフィールドのうちの１つまたは複数を含むことができる。これらのフィールドは、上記で説明されるようなものであってもよい。ＡＰは、１つもしくは複数の優先順位値を表示してもよく、１つもしくは複数のＴＸＯＰタイプ、１つもしくは複数のトラフィック優先順位、ＴＩＤをＳＴＡに割り当て、および／または１つもしくは複数のＡＣＫタイプをＳＴＡ、１つもしくは複数のトラフィック優先順位、ＴＩＤに割り当てる。そのようなＴＸＯＰネゴシエーション応答、またはその１つもしくは複数のフィールドもしくはサブフィールドは、プローブ応答または（再）アソシエーション応答において行なわれてもよい。

ＴＸＯＰおよびＡＣＫネゴシエーションに続く通信において、ＳＴＡおよびＡＰは、合意されたＴＸＯＰタイプおよび／またはＡＣＫタイプのうちの１つまたは複数を使用することができる。

トリガーフレームにおける優先順位およびＡＣＫポリシーの表示手順は、本明細書において開示される。１つの実施形態において、ＳＴＡ、たとえばＡＰは、トリガーフレーム、たとえばＨＥ ＭＵ初期化フレーム（ＭＵＩ）を使用して、ＳＵまたはＭＵフレームの送信をトリガーすることができる。トリガーフレームまたはＭＵＩフレームの内容は、ＳＴＡ／ＡＰが受信した任意のＵＬＲフレームに基づいてもよい。トリガーフレームまたはＭＵＩフレームは、プリアンブル、ＭＡＣヘッダ、フレームボディ、およびＦＣＳフィールドのうちの１つまたは複数を含むことができる。プリアンブルフィールド、および／またはＭＡＣヘッダ、および／またはフレームボディ、および／またはトリガーフレームもしくはＭＵＩフレームの任意の他の部分は、ＤＡ、ＴＩＤ、優先順位、パケット期間、ＴＸＯＰタイプ、帯域幅もしくはＲＵ、空間ストリームの数、ＴＸＯＰの期間、ＴＸＯＰ周波数フィールド、またはＡＣＫタイプフィールドを含む１つまたは複数のサブフィールドを含むことができる。

宛先アドレス（ＤＡ）は、トリガーフレームまたはＭＵＩフレームが向けられているＳＴＡまたはＳＴＡのグループを表示することができる。トリガーフレームまたはＭＵＩは、受信側ＳＴＡによってＳＵまたはＭＵ送信ＴＸＯＰの送信をトリガーするために使用されてもよい。

ＴＩＤフィールドは、トリガーフレームまたはＭＵＩフレームがトリガーフレームであるトラフィックフローのＩＤの１つまたは複数を表示することができる。ＴＩＤフィールドはまた、１つまたは複数のＴＩＤを表示するために、ハッシュ、またはビットマップ、または組み合わせとして実施されてもよい。

優先順位フィールドは、トリガーフレームまたはＭＵＩフレームがトリガーするよう意図されている送信のパケットのトラフィックの優先順位を表示することができる。優先順位フィールドは、値として実施されてもよく、値はこの優先順位、および／またはそれよりも高い優先順位のトラフィックのみが、トリガーフレームまたはＭＵＩフレームによってトリガーされるＴＸＯＰを使用して送信されてもよいことを暗示する。あるいは、優先順位フィールドは、ビットマップとして実施されてもよく、ビットマップはトリガーフレームまたはＭＵＩフレームに続いて送信されることを許容されるトラフィック優先順位を表示する。優先順位フィールドの０またはすべて「１」の値は、すべてのトラフィック優先順位が、トリガーフレームまたはＭＵＩフレームによってトリガーされたＴＸＯＰにおいて許容されることを表示するために使用されてもよい。

パケット期間フィールドは、受信側ＳＴＡが送信すべきＵＬまたはＰ２Ｐパケットまたはアグリゲートパケットの期間を表示するために使用されてもよい。受信側ＳＴＡが、表示されるトラフィックまたはそれ以上について送信するのに十分なパケットを有していない場合、それは、トリガーフレームまたはＭＵＩフレームに表示されているよりも優先順位が低いかまたは高いアグリゲートパケットトラフィックでパケットを送信するか、またはパケットを含めることができる。

ＴＸＯＰタイプフィールドは、トリガーフレームまたはＭＵＩフレームによってトリガーされるＴＸＯＰのタイプを表示するために使用されてもよい。ＴＸＯＰタイプは、ＳＵ ＴＸＯＰ、ＳＵ ＭＩＭＯ ＴＸＯＰ、ＳＵ ＯＦＤＭＡ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰであってもよい。本明細書において開示される要求されるＴＸＯＰについて、追加の情報が含まれてもよい。

ＴＸＯＰのＳＵおよびＭＵタイプの場合、トリガーされるＴＸＯＰにおいて使用されるべき受信側ＳＴＡの各々について割り当てられている帯域幅および／またはＵＲの数が表示されてもよい。トリガーされるＴＸＯＰにおいて使用するためにＳＴＡに割り当てられる帯域幅またはＲＵは、トリガーフレームまたはＭＵＩフレームに使用される帯域幅およびＲＵと同じであってもよい。

ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰの場合、空間ストリームの数が、受信側ＳＴＡの各々について表示されてもよい。トリガーされるＴＸＯＰにおいて使用するためのＳＴＡの空間チャネルは、そのＳＴＡのトリガーフレームまたはＭＵＩフレームに使用されるものと同じであってもよい。

すべてのＴＸＯＰについて、ＴＸＯＰの期間が表示されてもよい。また、要求されるＴＸＯＰが周期的なものであることが表示されてもよい。

ＴＸＯＰ周波数フィールドは、ＳＵ／ＭＵ ＴＸＯＰの周波数または間隔を表示するために使用されてもよい。周波数は、ｎｓ、ｍｓ、ＴＵ、または任意のその他の時間単位の数で指定されてもよい。

ＡＣＫタイプフィールドは、トリガーフレームもしくはＭＵＩフレームの送信側ＳＴＡによって、またはトリガーされるＴＸＯＰで送信されるパケットの応答側ＳＴＡによって使用されるＡＣＫのタイプを表示するために使用されてもよい。ＡＣＫタイプに関して含まれることができる追加情報は、本明細書において開示される。

通常のＡＣＫタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上の、またはトリガーフレームもしくはＭＵＩフレームが送信されるものと同じ帯域幅上のレガシーＳＵ ＡＣＫであってもよい。

通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上の、またはトリガーフレームもしくはＭＵＩフレームが送信されるものと同じ帯域幅上のレガシーＳＵ ＢＡであってもよい。

遅延ＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上の、またはトリガーフレームもしくはＭＵＩフレームが送信されるものと同じ帯域幅上のレガシーＳＵ ＢＡであってもよい。

遅延の通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上の、またはトリガーフレームもしくはＭＵＩフレームが送信されるものと同じ帯域幅上のレガシーＳＵ ＢＡであってもよい。

遅延マルチＳＴＡ ＡＣＫ／ＢＡタイプは、後の時点にマルチＳＴＡ ＡＣＫ／ＢＡパケットの一部として送信されるマルチＳＴＡ ＡＣＫ／ＢＡであってもよく、これはレガシー帯域幅上で送信されてもよい。

即時マルチＳＴＡ ＢＡ／ＡＣＫタイプは、たとえばＳＩＦＳ間隔後など、データパケットの送信の直後にマルチＳＴＡ ＢＡ／ＡＣＫパケットの一部として送信されるマルチＳＴＡ ＢＡ／ＡＣＫであってもよく、マルチＳＴＡ ＢＡ／ＡＣＫはレガシー帯域幅上で送信されてもよい。

スケジュール済みマルチＳＴＡ ＢＡ／ＡＣＫタイプは、スケジュールされた時間に送信されるマルチＳＴＡ ＢＡ／ＡＣＫパケットの一部として送信されるマルチＳＴＡ ＢＡ／ＡＣＫであってもよく、マルチＳＴＡ ＢＡ／ＡＣＫはレガシー帯域幅またはリソース割り当てフレームによって割り当てられるリソース上で送信されてもよい。

即時ＨＥ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されるＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さいチャネル、たとえば２．５ＭＨｚ、５ＭＨｚチャネル、ならびに／またはデータパケットおよびアグリゲートパケットが送信されるＭＩＭＯチャネル上で、送信されてもよい）。

即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡであってもよい。ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さい、たとえば５ＭＨｚチャネルの、データパケットおよびアグリゲートパケットが送信されるチャネル上で、送信されてもよい。

即時ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＭＩＭＯ ＡＣＫ／ＢＡであってもよい。ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＭＩＭＯチャネルの、データパケットおよびアグリゲートパケットが送信されるチャネル上で、送信されてもよい。

スケジュール済みＨＥ ＡＣＫ／ＢＡタイプは、たとえばＡＣＫ ＲＡＷで、スケジュールされた時間において送信されてもよいＨＥ ＡＣＫ／ＢＡであってもよい。ＨＥ ＡＣＫは、リソース割り当てフレームによって割り当てられたリソースを使用して送信されてもよい。

もう１つの実施形態において、ＡＣＫタイプフィールドは、ＡＣＫサブタイプおよびタイミングタイプという２つのサブフィールドを使用するものとして実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ／ＢＡ、ＨＥ ＡＣＫ／ＢＡ、ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡ、ＨＥ ＯＦＤＭＡ、およびＭＩＭＯ ＡＣＫ／ＢＡであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

もう１つの実施形態において、ＡＣＫタイプは、ＡＣＫサブタイプ、リソースタイプ、およびタイミングタイプという３つのサブフィールドを使用して実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、遅延ＢＡ、マルチＳＴＡ ＡＣＫ／ＢＡ、ＨＥ ＡＣＫ／ＢＡであってもよい。リソースタイプは、レガシー帯域幅、ＯＦＤＭＡ、ＭＩＭＯ、ＯＦＤＭＡ／ＭＩＭＯであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

トリガーフレームの任意の部分またはＭＵＩフレームまたはその任意の組み合わせは、アクションフレーム、アクションＮｏ Ａｃｋフレーム、または管理、制御フレーム、拡張フレーム、ＮＤＰフレーム、ＮＤＰ搬送ＭＡＣ情報フレームの任意の他のタイプのような新しい制御フレームまたは新しい管理フレームとして実施されてもよく、また、情報要素、サブ要素、または管理、制御、拡張、ＮＤＰもしくはデータフレームのフィールドもしくはサブフィールドのセットもしくはサブセット、またはＭＡＣ／ＰＬＣＰヘッダの一部として実施されてもよい。ＡＣＫ／ＢＡ／マルチＳＴＡ ＡＣＫ／ＢＡ、または確認応答フレーム、制御フレーム、拡張フレーム、管理フレーム、データフレーム、もしくはＮＤＰフレームの任意の他のタイプは、トリガーフレームとして使用されてもよい。

ＨＥ ＳＵ／ＭＵ送信手順は、本明細書において説明されるようなものであってもよい。ＳＴＡ、たとえばＡＰは、トリガーフレームまたはＭＵＩフレームを送信して、ＳＵまたはＭＵフレームの送信をトリガーすることができる。トリガーフレームまたはＭＵＩフレームによってトリガーされるＴＸＯＰは、トリガーされるＴＸＯＰ（ＴＴＸＯＰ）と称されてもよい。トリガーフレームまたはＭＵＩフレームの送信は、トリガーフレームまたはＭＵＩフレームの送信側ＳＴＡによって受信された１つまたは複数のＵＬＲフレームに基づいてもよい。トリガーフレームまたはＬＭＵＩフレームは、送信すべきパケットを有することもあるＳＴＡのポールフレームとして使用されてもよい。ＳＴＡ、たとえばＡＰは、ＴＴＸＯＰが使用されるべきＴＩＤをトリガーフレームまたはＭＵＩフレームで表示することができる。ＳＴＡ、たとえばＡＰは、ＴＴＸＯＰが使用されるべきトラフィックの優先順位をトリガーフレームまたはＭＵＩフレームで表示することができる。たとえば、送信側ＳＴＡは、優先順位、および／またはそれよりも高い優先順位のトラフィックのみが、トリガーフレームまたはＭＵＩフレームによってトリガーされるＴＸＯＰを使用して受信側ＳＴＡによって送信されてもよいことを表示することができる。

ＳＴＡ、たとえばＡＰは、たとえば通常のＡＣＫ／ＢＡ、遅延ＢＡ、スケジュール済みＡＣＫ／ＢＡ、即時マルチＳＴＡ ＡＣＫ／ＢＡ、遅延マルチＳＴＡ ＡＣＫ／ＢＡ、スケジュール済みマルチＳＴＡ ＡＣＫ／ＢＡ、通常のＨＥ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、通常のＨＥ ＭＩＭＯ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ／ＭＩＭＯ ＡＣＫ／ＢＡ、スケジュール済みＨＥ ＡＣＫ／ＢＡなど、受信された（アグリゲートされた）（データ）パケットに応じて、ＴＴＸＯＰで使用されるべきＡＣＫスキームをトリガーフレームまたはＭＵＩフレームで表示することができる。ＳＴＡ、たとえばＡＰは、確認応答側ＳＴＡがＯＦＤＭＡおよび／またはＭＵ−ＭＩＭＯパケットを送信できないことをそれが認識している場合、ＨＥ ＯＦＤＭＡおよび／またはＭＵ ＭＩＭＯ ＡＣＫ／ＢＡを表示すべきではない。

パケット、たとえばＴＴＸＯＰのデータパケットまたはアグリゲートパケットの受信側ＳＴＡは、トリガーフレームまたはＭＵＩフレームで表示されたＡＣＫスキームを使用すべきである。たとえば、表示されたＡＣＫが即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡである場合、確認応答側ＳＴＡは、即時ＡＣＫ／ＢＡを、たとえば（アグリゲート）パケットの受信後のＳＩＦＳ間隔の後に、パケットが受信されるものと同じＲＵまたはチャネルを介して、送信することができる。即時マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、即時マルチＳＴＡ ＢＡ／ＡＣＫを、たとえばＳＴＡのグループからの（アグリゲート）パケットの受信後のＳＩＦＳ間隔の後に、ＴＴＸＯＰ中に使用される全帯域幅を介して、送信することができる。遅延マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、マルチＳＴＡ ＡＣＫ／ＢＡを、一定期間後に送信して、ＴＴＸＯＰで受信されたパケット／アグリゲートパケットのいずれかまたは一部を確認応答することができる。スケジュール済みＨＥ ＡＣＫ／ＢＡが表示される場合、確認応答側ＳＴＡは、スケジュールされた間隔にＨＥ ＡＣＫ／ＢＡを送信して、ＴＴＸＯＰで受信された任意のパケットを確認応答することができる。

トリガーフレームまたはＭＵＩフレームの宛先となることができる、ＴＴＸＯＰのパケット、データパケットまたはアグリゲートパケットの送信側ＳＴＡは、パケットの期間を使用してＴＴＸＯＰ中に送信すべきパケットのサイズおよび期間を計算することができる。これらのＳＴＡはまた、トリガーフレームまたはＭＵＩフレームで表示されたＡＣＫスキームを検査すべきであり、適切なモード／帯域幅または時間を使用して、それらの送信されたパケットの確認応答を受信する必要がある。

ＴＴＸＯＰで使用されるべきＡＣＫスキームは、トリガーフレームまたはＭＵＩフレームに含まれるＴＩＤ情報または優先順位情報またはアソシエーション中およびアソシエーション後のネゴシエーションによって暗示されてもよい。トリガーフレームまたはＭＵＩフレームの宛先ではないすべての受信側ＳＴＡは、パケットの期間、ＴＴＸＯＰの期間および／または表示されたＡＣＫタイプを使用して、省電力のためにそれらが休止またはスリープできる時間を計算することができる。

データまたはアグリゲートフレームにおける優先順位およびＡＣＫポリシーの表示手順は、本明細書において開示される。データパケット、ＨＥパケット、および／またはＡ−ＭＰＤＵもしくはＡ−ＭＳＤＵのようなアグリゲートパケットは、そのプリアンブルまたはフレームボディまたは任意の部分で、本明細書において開示される以下の情報を搬送することができる。

ＴＩＤフィールドは、パケットが送信されるトラフィックフローのＩＤの１つまたは複数を表示することができる。ＴＩＤフィールドはまた、１つまたは複数のＴＩＤを表示するために、ハッシュ、またはビットマップ、または組み合わせとして実施されてもよい。

優先順位は、現在のパケットに含まれるパケットのトラフィックの優先順位を表示することができる。

ＡＣＫタイプフィールドは、現在のフレームを確認応答するために使用されるべきＡＣＫのタイプを表示するために使用されてもよい。ＡＣＫタイプは、本明細書において開示される以下のタイプの１つまたは複数のものを含むことができる。

通常のＡＣＫタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＡＣＫであってもよい。

通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい。

遅延の通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい。

遅延マルチＳＴＡ ＡＣＫタイプは、後の時点にマルチＳＴＡ ＡＣＫパケットの一部として送信されるマルチＳＴＡ ＡＣＫであってもよく、これはレガシー帯域幅上で送信されてもよい。

即時マルチＳＴＡ ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットの送信の直後にマルチＳＴＡ ＢＡパケットの一部として送信されるマルチＳＴＡ ＢＡであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅上で送信されてもよい。

スケジュール済みマルチＳＴＡ ＢＡタイプは、スケジュールされた時間に送信されるマルチＳＴＡ ＢＡパケットの一部として送信されるマルチＳＴＡ ＢＡであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅またはリソース割り当てフレームによって割り当てられるリソース上で送信されてもよい。

即時ＨＥ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さいチャネル、たとえば５ＭＨｚチャネル、ならびに／またはデータパケットおよびアグリゲートパケットが送信されるＭＩＭＯチャネル上で、送信されてもよい。

即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡであってもよい。ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さい、たとえば５ＭＨｚチャネルの、データパケットおよびアグリゲートパケットが送信されるチャネル上で、送信されてもよい。

即時ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＭＩＭＯ ＡＣＫ／ＢＡであってもよい。ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば、データパケットおよびアグリゲートパケットが送信されるものと同じＭＩＭＯチャネル上で、送信されてもよい。

スケジュール済みＨＥ ＡＣＫ／ＢＡタイプは、たとえばＡＣＫ ＲＡＷで、スケジュールされた時間に送信されてもよいＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、リソース割り当てフレームによって割り当てられたリソースを使用して送信されてもよい。

もう１つの設計において、ＡＣＫタイプフィールドは、ＡＣＫサブタイプおよびタイミングタイプという２つのサブフィールドを使用するものとして実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ、ＨＥ ＡＣＫ、ＨＥ ＯＦＤＭＡ ＡＣＫ、ＨＥ ＭＩＭＯ ＡＣＫであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

さらにもう１つの設計において、ＡＣＫタイプは、ＡＣＫサブタイプ、リソースタイプ、およびタイミングタイプという３つのサブフィールドを使用して実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ、ＨＥ ＡＣＫであってもよい。リソースタイプは、レガシー帯域幅、ＯＦＤＭＡ、ＭＩＭＯ、ＯＦＤＭＡ／ＭＩＭＯであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

ＨＥパケット送信手順は、以下のようなものであってもよい。ＳＴＡは、パケット、ＨＥパケット、Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵのようなアグリゲートパケットを送信することができる。そのようなパケットの送信は、ＴＴＸＯＰにおいてトリガーフレームまたはＭＵＩフレームによってトリガーされてもよい。ＨＥパケット、データパケット、またはアグリゲートパケットの送信側ＳＴＡは、たとえば通常のＡＣＫ／ＢＡ、遅延ＢＡ、スケジュール済みＡＣＫ／ＢＡ、即時マルチＳＴＡ ＡＣＫ／ＢＡ、遅延マルチＳＴＡ ＡＣＫ／ＢＡ、スケジュール済みマルチＳＴＡ ＡＣＫ／ＢＡ、通常のＨＥ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、通常のＨＥ ＭＩＭＯ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ／ＭＩＭＯ ＡＣＫ／ＢＡ、スケジュール済みＨＥ ＡＣＫ／ＢＡなど、送信された（アグリゲートされた）（データ）パケットに応じるために受信側ＳＴＡによって使用されるべきＡＣＫスキームをパケットで表示することができる。送信側ＳＴＡは、確認応答側ＳＴＡがＯＦＤＭＡおよび／またはＭＵ−ＭＩＭＯパケットを送信できないことをそれが認識している場合、ＨＥ ＯＦＤＭＡおよび／またはＭＵ ＭＩＭＯ ＡＣＫを表示すべきではない。

ＨＥパケット、データパケット、またはアグリゲートパケットの送信側ＳＴＡは、ＴＴＸＯＰをトリガーし、ＨＥパケット、データパケット、もしくはアグリゲートパケットの送信を進めるトリガーフレームによって表示されるもの、またはアソシエーション中または後にネゴシエートされるものと同じであるＡＣＫスキームをパケットで表示することができる。

ＨＥパケット、データパケット、またはアグリゲートパケットの送信側ＳＴＡは、トリガーフレームまたはＭＵＩフレームによって、ならびに／または、ＨＥパケット、データパケット、もしくはアグリゲートパケットの送信を進め、同じ優先順位、同じＴＩＤ、および／もしくは同じバッファされたパケットの送信のためにＴＸＯＰを要求するＵＬＲフレームによって表示されるものと同じであるＡＣＫスキームをパケットで表示することができる。

送信されたパケット、データパケット、またはアグリゲートパケットの受信側ＳＴＡは、送信されたフレームで表示されたＡＣＫスキームを使用すべきである。たとえば、表示されたＡＣＫが即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡである場合、確認応答側ＳＴＡは、即時ＡＣＫ／ＢＡを、たとえば（アグリゲート）パケットの受信後のＳＩＦＳ間隔の後に、パケットが受信されるものと同じＲＵまたはチャネルを介して、送信することができる。即時マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、即時マルチＳＴＡ ＢＡ／ＡＣＫを、たとえばＳＴＡのグループからの（アグリゲート）パケットの受信後のＳＩＦＳ間隔の後に、ＴＴＸＯＰ中に使用される全帯域幅を介して、送信することができる。遅延マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、マルチＳＴＡ ＡＣＫ／ＢＡを、一定期間後に送信して、ＴＴＸＯＰで受信されたパケット／アグリゲートパケットのいずれかまたは一部を確認応答することができる。スケジュール済みＨＥ ＡＣＫ／ＢＡが表示される場合、確認応答側ＳＴＡは、スケジュールされた間隔にＨＥ ＡＣＫ／ＢＡを送信して、ＴＴＸＯＰで受信された任意のパケットを確認応答することができる。

ＨＥパケット、データパケット、および／またはアグリゲートパケットの送信側ＳＴＡは、表示されたＡＣＫスキームに基づいて、各自の送信されたパケットの確認応答を受信するために、適切なモード／帯域幅または時間を使用すべきである。受信されたＨＥパケット、データパケット、および／またはアグリゲートパケットに応じるために受信側ＳＴＡによって使用されるべきＡＣＫスキームは、送信されたパケットに含まれるＴＩＤ情報または優先順位情報によって暗示されてもよい。

送信されたパケットの宛先ではないすべての受信側ＳＴＡは、表示されたパケットの期間、ＴＴＸＯＰの期間および／または表示されたＡＣＫタイプを使用して、省電力のためにそれらが休止またはスリープできる時間を計算することができる。

スケジュールフレームにおける優先順位およびＡＣＫポリシーネゴシエーション手順の例は、本明細書において開示される。１つの実施形態において、優先順位およびＡＣＫポリシーネゴシエーション手順のためにスケジュールフレームを導入することが提案されてもよい。前述のように、任意のＳＴＡは、ＳＴＡが１つまたは複数のアップリンクＴＸＯＰを要求しているパケットまたはトラフィックの優先順位およびその他の情報を、アップリンク要求フレームでＡＰに提供することができる。しかし、リソースが限られているため、すべてのＵＬＲフレームに応答することは可能ではないことがある。また、トリガーフレームおよび／またはデータまたはアグリゲートフレームごとに各ＵＬＲに順次応答することは効率的ではないことがある。したがって、応答者、たとえばＡＰは、スケジュールフレームを送信して、すべてのＵＬＲフレームにおける限られたリソースおよび要求優先順位およびＡＣＫポリシーを所与として、それらのデータ送信のために選択されたＳＴＡおよび／または選択されたＳＴＡの選択されたＴＳを表示することができる。マルチＵＬＲおよびスケジュールフレーム交換が完了すると、スケジュール済みイニシエータは、その選択され、スケジュールされた、または許可されたデータ送信を送信することができる。優先順位およびＡＣＫポリシーネゴシエーション手順により、マルチＳＴＡは、ＡＰとの送信に使用可能な最大リソースを見出してネゴシエートした。

ＳＴＡ、たとえばＡＰは、スケジュールフレーム、たとえばスケジュール済みＨＥ ＭＵ初期化フレーム（ＳＭＵＩ）を使用して、ＳＵまたはＭＵフレームの送信をスケジュールすることができる。スケジュールフレームまたはＳＭＵＩフレームの内容は、ＳＴＡ／ＡＰが受信した１つまたは複数のＵＬＲフレームに基づいてもよい。

スケジュールフレームまたはＳＭＵＩフレームは、以下のフィールド、すなわちプリアンブル、フレームボディ、およびＦＣＳフィールドのうちの１つまたは複数を含むことができる。プリアンブルフィールドおよび／またはフレームボディおよび／またはトリガーフレームもしくはＭＵＩフレームの任意の他の部分は、本明細書において開示される１つまたは複数のサブフィールドを含むことができる。

宛先アドレス（ＤＡ）サブフィールドは、スケジュールフレームまたはＳＭＵＩフレームが向けられているＳＴＡまたはＳＴＡのグループを表示することができる。スケジュールフレームまたはＳＭＵＩは、受信側ＳＴＡによってＳＵまたはＭＵ送信ＴＸＯＰの送信をスケジュールするために使用されてもよい。

トラフィック識別子（ＴＩＤ）サブフィールドは、トリガーフレームまたはＳＭＵＩフレームがトリガーフレームであるトラフィックフローのＩＤの１つまたは複数を表示することができる。ＴＩＤフィールドはまた、１つまたは複数のＴＩＤを表示するために、ハッシュまたはビットマップまたは組み合わせとして実施されてもよい。

優先順位は、スケジュールフレームまたはＳＭＵＩフレームがスケジュールするよう意図されている送信のパケットのトラフィックの優先順位を表示することができる。優先順位フィールドは、値として実施されてもよく、値はこの優先順位、および／またはそれよりも高い優先順位のトラフィックのみが、スケジュールフレームまたはＳＭＵＩフレームによってスケジュールされるＴＸＯＰを使用して送信されてもよいことを暗示する。あるいは、優先順位フィールドは、ビットマップとして実施されてもよく、ビットマップはスケジュールフレームまたはＳＭＵＩフレームに続いて送信されることを許容されるトラフィック優先順位を表示する。優先順位フィールドの「０」またはすべて「１」の値は、すべてのトラフィック優先順位が、スケジュールフレームまたはＳＭＵＩフレームによってスケジュールされたＴＸＯＰにおいて許容されることを表示するために使用されてもよい。

パケット期間サブフィールドは、受信側ＳＴＡが送信すべきＵＬまたはＰ２Ｐアグリゲートパケットの期間を表示するために使用されてもよい。受信側ＳＴＡが、表示されるトラフィックまたはそれ以上について送信するのに十分なパケットを有していない場合、受信側ＳＴＡは、スケジュールフレームまたはＳＭＵＩフレームに表示されているよりも優先順位が低いアグリゲートパケットでパケットを送信するか、またはパケットを含めることができる。

ＴＸＯＰタイプサブフィールドは、トリガーフレームまたはＭＵＩフレームによってトリガーされるＴＸＯＰのタイプを表示するために使用されてもよい。ＴＸＯＰタイプは、ＳＵ ＴＸＯＰ、ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰであってもよい。要求されるＴＸＯＰについて以下のように追加の情報が含まれてもよい。

もう１つのサブフィールドは、帯域幅またはＲＵサブフィールドを含み、ＳＴＡの各々について割り当てを提供することができる。ＴＸＯＰのＳＵおよびＭＵタイプの場合、スケジュールされるＴＸＯＰにおいて使用されるべき受信側ＳＴＡの各々について割り当てられている帯域幅および／またはＵＲの数が表示されてもよい。スケジュールされるＴＸＯＰにおいて使用するためにＳＴＡに割り当てられる帯域幅またはＲＵは、スケジュールフレームまたはＳＭＵＩフレームに使用される帯域幅およびＲＵと同じであってもよい。

もう１つのサブフィールドは、空間ストリームの数を含むことができる。ＳＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＭＩＭＯ ＴＸＯＰ、ＭＵ ＯＦＤＭＡ、およびＭＩＭＯ ＴＸＯＰの場合、空間ストリームの数が、受信側ＳＴＡの各々について表示されてもよい。トリガーされるＴＸＯＰにおいて使用するためのＳＴＡの空間チャネルは、そのＳＴＡのスケジュールフレームまたはＳＭＵＩフレームに使用されるものと同じであってもよい。

ＴＸＯＰの期間は、すべてのＴＸＯＰについて表示されてもよい。要求されるＴＸＯＰが周期的なものであるという定期的表示が表示されてもよい。ＴＸＯＰ周波数フィールドは、ＳＵ／ＭＵ ＴＸＯＰの周波数または間隔を表示するために使用されてもよい。周波数は、ｎｓ、ｍｓ、ＴＵ、または任意のその他の時間単位の数で指定されてもよい。ＡＣＫタイプフィールドは、トリガーされるＴＸＯＰで送信されるパケットのスケジュールフレームまたはＳＭＵＩフレームの送信側ＳＴＡによって使用されるＡＣＫのタイプを表示するために使用されてもよい。ＡＣＫタイプは、本明細書において開示される１つまたは複数のタイプを含むことができる。

通常のＡＣＫタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＡＣＫであってもよい。

通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい）。

遅延の通常のＢＡタイプは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、８０＋８０ＭＨｚ、および１６０ＭＨｚ帯域幅のようなレガシーチャネル幅上の、または１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚのような、たとえばサブ１ＧＨｚ帯域のダウンクロックされたチャネル幅上のレガシーＳＵ ＢＡであってもよい。

遅延マルチＳＴＡ ＡＣＫタイプは、後の時点にマルチＳＴＡ ＡＣＫパケットの一部として送信されるマルチＳＴＡ ＡＣＫであってもよく、これはレガシー帯域幅上で送信されてもよい）。

即時マルチＳＴＡ ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットの送信の直後にマルチＳＴＡ ＢＡパケットの一部として送信されるマルチＳＴＡ ＢＡであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅上で送信されてもよい）。

スケジュール済みマルチＳＴＡ ＢＡタイプは、スケジュールされた時間に送信されるマルチＳＴＡ ＢＡパケットの一部として送信されるマルチＳＴＡ ＢＡであってもよく、マルチＳＴＡ ＡＣＫはレガシー帯域幅またはリソース割り当てフレームによって割り当てられるリソース上で送信されてもよい。

即時ＨＥ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さいチャネル、たとえば５ＭＨｚチャネル、ならびに／またはデータパケットおよびアグリゲートパケットが送信されるＭＩＭＯチャネル上で、送信されてもよい。

即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡであってもよい。ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば同じＯＦＤＭＡ ＲＵ、またはレガシー帯域幅よりも小さい、たとえば５ＭＨｚチャネルの、データパケットおよびアグリゲートパケットが送信されるチャネル上で、送信されてもよい。

即時ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡタイプは、たとえばＳＩＦＳ間隔後など、データパケットまたはアグリゲートパケットの受信直後に送信されてもよいＨＥ ＭＩＭＯ ＡＣＫ／ＢＡであってもよい。ＨＥ ＭＩＭＯ ＡＣＫ／ＢＡは、データパケットまたはアグリゲートパケットが送信されるものと同じリソースを使用して、たとえば、データパケットおよびアグリゲートパケットが送信されるものと同じＭＩＭＯチャネル上で、送信されてもよい。

スケジュール済みＨＥ ＡＣＫ／ＢＡタイプは、たとえばＡＣＫ ＲＡＷで、スケジュールされた時間において送信されてもよいＨＥ ＡＣＫであってもよい。ＨＥ ＡＣＫは、リソース割り当てフレームによって割り当てられたリソースを使用して送信されてもよい。

もう１つの設計において、ＡＣＫタイプフィールドは、ＡＣＫサブタイプおよびタイミングタイプという２つのサブフィールドを使用するものとして実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ、ＨＥ ＡＣＫ、ＨＥ ＯＦＤＭＡ ＡＣＫ、ＨＥ ＭＩＭＯ ＡＣＫであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

さらにもう１つの設計において、ＡＣＫタイプは、ＡＣＫサブタイプ、リソースタイプ、およびタイミングタイプという３つのサブフィールドを使用して実施されてもよい。ＡＣＫサブタイプは、通常のＡＣＫ、通常のＢＡ、マルチＳＴＡ ＡＣＫ、ＨＥ ＡＣＫであってもよい。リソースタイプは、レガシー帯域幅、ＯＦＤＭＡ、ＭＩＭＯ、ＯＦＤＭＡ／ＭＩＭＯであってもよい。タイミングタイプは、即時、遅延、およびスケジュール済みであってもよい。

スケジュールフレームまたはＳＭＵＩフレームの任意の部分またはその任意の組み合わせが、アクションフレーム、アクションＮｏ Ａｃｋフレーム、または管理、制御フレーム、拡張フレーム、ＮＤＰフレーム、ＮＤＰ搬送ＭＡＣ情報フレームの任意の他のタイプのような新しい制御フレームまたは新しい管理フレームとして実施されてもよく、また、情報要素、サブ要素、または管理、制御、拡張、ＮＤＰもしくはデータフレームのフィールドもしくはサブフィールドのセットもしくはサブセット、またはＭＡＣ／ＰＬＣＰヘッダの一部として実施されてもよいことは留意する価値がある。

ＡＣＫ／ＢＡ／マルチＳＴＡ ＡＣＫ／ＢＡ、または確認応答フレーム、制御フレーム、拡張フレーム、管理フレーム、データフレーム、またはＮＤＰフレームの任意の他のタイプは、スケジュールフレームとして使用されてもよい。

ＨＥ ＳＵ／ＭＵ送信ネゴシエーション手順は、本明細書において説明されるようなものであってもよい。ＳＴＡ、たとえばＡＰは、スケジュールフレームまたはＳＭＵＩフレームを送信して、ＳＵまたはＭＵフレームの送信をスケジュールすることができる。スケジュールフレームまたはＳＭＵＩフレームによってスケジュールされるＴＸＯＰは、スケジュールされるＴＸＯＰ（ＳＴＸＯＰ）と称されてもよい。スケジュールフレームまたはＳＭＵＩフレームの送信は、スケジュールフレームまたはＳＭＵＩフレームの送信側ＳＴＡによって受信された１つまたは複数のＵＬＲフレームに基づいてもよい。

ＳＴＡ、たとえばＡＰは、ＳＴＸＯＰが使用されるべきＴＩＤをスケジュールフレームまたはＭＵＩフレームで表示することができる。ＳＴＡ、たとえばＡＰは、ＳＴＸＯＰが使用されるべきトラフィックの優先順位をスケジュールフレームまたはＳＭＵＩフレームで表示することができる。たとえば、送信側ＳＴＡは、優先順位、および／またはそれよりも高い優先順位のトラフィックのみが、スケジュールフレームまたはＳＭＵＩフレームによってスケジュールされるＴＸＯＰを使用して受信側ＳＴＡによって送信されてもよいことを表示することができる。

ＳＴＡ、たとえばＡＰは、たとえば通常のＡＣＫ／ＢＡ、遅延ＢＡ、スケジュール済みＡＣＫ／ＢＡ、即時マルチＳＴＡ ＡＣＫ／ＢＡ、遅延マルチＳＴＡ ＡＣＫ／ＢＡ、スケジュール済みマルチＳＴＡ ＡＣＫ／ＢＡ、通常のＨＥ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡ、通常のＨＥ ＭＩＭＯ ＡＣＫ／ＢＡ、通常のＨＥ ＯＦＤＭＡ／ＭＩＭＯ ＡＣＫ／ＢＡ、スケジュール済みＨＥ ＡＣＫ／ＢＡなど、アグリゲートされたデータパケットであってもよい受信されたパケットに応じて、ＳＴＸＯＰで使用されるべきＡＣＫスキームをスケジュールフレームまたはＳＭＵＩフレームで表示することができる。ＳＴＡ、たとえばＡＰは、確認応答側ＳＴＡがＯＦＤＭＡおよび／またはＭＵ−ＭＩＭＯパケットを送信できないことをそれが認識している場合、ＨＥ ＯＦＤＭＡおよび／またはＭＵ−ＭＩＭＯ ＡＣＫを表示すべきではない。

ＳＴＸＯＰのパケット、データパケットまたはアグリゲートパケットの受信側ＳＴＡは、トリガーフレームまたはＭＵＩフレームで表示されたＡＣＫスキームを使用すべきである。たとえば、表示されたＡＣＫが即時ＨＥ ＯＦＤＭＡ ＡＣＫ／ＢＡである場合、確認応答側ＳＴＡは、即時ＡＣＫ／ＢＡを、たとえばパケットまたはアグリゲートパケットの受信後のＳＩＦＳ間隔の後に、パケットが受信される同じＲＵまたはチャネルを介して、送信することができる。即時マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、即時マルチＳＴＡ ＢＡ／ＡＣＫを、たとえばＳＴＡのグループからの１つまたは複数のアグリゲートパケットの受信後のＳＩＦＳ間隔の後に、ＳＴＸＯＰ中に使用される全帯域幅を介して、送信することができる。遅延マルチＳＴＡ ＢＡ／ＡＣＫが表示される場合、確認応答側ＳＴＡは、マルチＳＴＡ ＡＣＫ／ＢＡを、一定期間後に送信して、ＳＴＸＯＰで受信されたパケット／アグリゲートパケットのいずれかまたは一部を確認応答することができる。スケジュール済みＨＥ ＡＣＫ／ＢＡが表示される場合、確認応答側ＳＴＡは、スケジュールされた間隔にＨＥ ＡＣＫ／ＢＡを送信して、ＳＴＸＯＰで受信された任意のパケットを確認応答することができる。

スケジュールフレームまたはＳＭＵＩフレームの宛先となることができる、ＳＴＸＯＰのパケット、データパケットまたはアグリゲートパケットの送信側ＳＴＡは、パケットの期間を使用してＳＴＸＯＰ中に送信すべきパケットのサイズおよび期間を計算することができる。これらのＳＴＡはまた、スケジュールフレームまたはＳＭＵＩフレームで表示されたＡＣＫスキームを検査すべきであり、適切なモード／帯域幅または時間を使用して、それらの送信されたパケットの確認応答を受信する必要がある。

ＳＴＸＯＰで使用されるべきＡＣＫスキームは、スケジュールフレームまたはＳＭＵＩフレームに含まれるＴＩＤ情報または優先順位情報によって暗示されてもよい。スケジュールフレームまたはＳＭＵＩフレームの宛先ではないすべての受信側ＳＴＡは、パケットの期間、ＳＴＸＯＰの期間および／または表示されたＡＣＫタイプを使用して、省電力のためにそれらがスリープできる時間を計算することができる。

優先順位およびＡＣＫポリシー表示およびネゴシエーション手順の例は、本明細書において開示される。

図５は、ＵＲＬ、および／またはトリガーフレーム、および／またはＭＵデータフレームにおける優先順位およびＡＣＫポリシー表示手順５００を示す第１の例である。ＳＴＡは、ＳＴＡが１つまたは複数のアップリンクＴＸＯＰを要求しているパケットまたはトラフィックの優先順位およびその他の情報を、ＵＬＲフレームでＡＰに提供することができる。具体的には、ＳＴＡ１は、そのバッファまたは予想されるトラフィックを調べ、ＴＳ１がビデオストリームでありＴＳ２がベストエフォートトラフィックである２つのトラフィックストリーム（ＴＳ）を見つけることができ、したがってそれはバッファに入れられているトラフィックまたは将来予想されるトラフィックについてＵＬまたはＤＬ ＴＸＯＰを要求することができる５０６。また、ＳＴＡ１は、ＴＳ１およびＴＳ２の優先順位をそれぞれ、ＶＩおよびＢＥとしてＵＬＲで表示することができる。ＳＴＡ１は、ＴＳ１およびＴＳ２の要求されるＡＣＫタイプをそれぞれ、ＭＵ ＢＡおよび遅延ＭＵ ＢＡとしてＵＬＲ５０６で表示することができる。同様に、ＳＴＡ２は、その予想されるトラフィックストリームＴＳ１がビデオストリームであることを調べることができ、したがって将来予想されるトラフィックについてＤＬ ＴＸＯＰを要求することができる５０２。またＳＴＡ２は、ＴＳ１の優先順位をＶＩとして、ＴＳ１の要求されるＡＣＫタイプがＭＵ ＢＡであることをＵＬＲ５０２で表示することができる。同様に、ＳＴＡ３は、そのバッファを調べ、ＴＳ１がビデオストリームでありＴＳ２がベストエフォートトラフィックである２つのトラフィックストリーム（ＴＳ）を見つけることができ、したがってそれはバッファに入れられているトラフィックについてＵＬ ＴＸＯＰを要求することができる５０４。また、ＳＴＡ３は、ＴＳ１およびＴＳ２の優先順位をそれぞれ、ＶＩおよびＢＥとしてＵＬＲ５０４で表示することができる。ＳＴＡ１は、ＴＳ１およびＴＳ２の要求されるＡＣＫタイプをそれぞれ、ＭＵ ＢＡおよび遅延ＭＵ ＢＡとしてＵＬＲ５０６で表示することができる。

ＳＴＡ１およびＳＴＡ２のＡＰからのＭＵデータパケットまたはフレーム５０８は、現在のＭＵデータフレームを確認応答するために使用されるべき順次ＡＣＫを表示するために使用されてもよいＡＣＫタイプを、そのプリアンブルまたはフレームボディで搬送することができる。受信側ＳＴＡ１およびＳＴＡ２は、送信されたフレームの表示されたＡＣＫスキームを使用すべきである、すなわちＳＴＡ１ ５１０およびＳＴＡ２ ５１２に対応する２つのＡＣＫは、データパケットの受信後のＳＩＦＳ間隔の後に順次返送されてもよい。送信されたパケットの宛先ではないその他の受信側ＳＴＡ、たとえばＳＴＡ３およびＳＴＡ４は、表示されたパケットの期間、ＴＸＯＰの期間、および／または表示されたＡＣＫタイプを使用して、省電力のためにそれらが休止またはスリープできる時間を計算することができる。

ＡＰは、受信側ＳＴＡによってＳＵまたはＭＵ送信ＴＸＯＰの送信をトリガーするために、トリガーフレーム５１４を使用することができる。トリガーフレームの内容は、ＡＰが受信した任意のＵＬＲフレームに基づいてもよい。たとえば、ＵＬＲ１およびＵＬＲ３に基づくトリガーフレームは、それぞれＳＴＡ１およびＳＴＡ３のＵＬデータ送信をトリガーすることができ、優先順位、ＡＣＫポリシー、およびＴＸＯＰをトリガーフレームで表示することができ、たとえば、遅延ＭＵ ＢＡおよび優先順位ＶＩは、ＳＴＡ１ ５１４のトリガーフレームで表示され、ＴＸＯＰおよび優先順位ＶＩは、ＳＴＡ３ ５１８のトリガーフレームで表示される。トリガーフレームによってトリガーされるＴＸＯＰは、トリガーされるＴＸＯＰ（ＴＴＸＯＰ）と称されてもよい。

ＴＴＸＯＰのＳＴＡ１ ５１６およびＳＴＡ３ ５２０からのＵＬデータ送信の受信側ＳＴＡ、たとえばＡＰは、たとえばＳＴＡ１およびＳＴＡ３のマルチＳＴＡまたはＭＵ ＢＡがＡＰ５２２によって送信される、ＴＴＸＯＰ中に、ＳＴＡ１ ５１６およびＳＴＡ３ ５２０からのデータパケットの受信後のＳＩＦＳ間隔の後にＡＣＫを確認応答するために、トリガーフレームで表示されたＡＣＫスキームを使用すべきである。

図６は、優先順位およびＡＣＫポリシー表示手順６００の第２の例を示す。ＳＴＡ１は、２つのＴＩＤ６０６を表示する。ＴＳ１について、ＳＴＡ１は、優先順位ＶＩ、およびＨＥ ＯＦＤＭＡ、および／またはＭＵ−ＭＩＭＯ ＴＸＯＰ、およびＭＵ ＢＡ、および／または即時ＨＥ ＯＦＤＭＡ ＡＣＫを要求する。ＴＳ２について、ＳＴＡ１は、優先順位にＢＥを表示し、ＳＵおよび／またはＭＵ ＴＸＯＰを要求し、遅延ＭＵ ＢＡを要求する。ＳＴＡ２は、ＴＳ１の優先順位ＶＩが表示されているので、１つのＴＩＤ６０２を表示し、ＳＴＡ２はＨＥ ＭＵ−ＭＩＭＯ ＴＸＯＰおよびＭＵ ＢＡを要求する。ＳＴＡ３は、２つのＴＩＤ６０４を表示し、すなわち、優先順位ＶＩにＴＳ１を表示し、ＨＥ ＯＦＤＭＡ、および／またはＭＵ−ＭＩＭＯ ＴＸＯＰ、および両ＭＵ ＢＡ、および／または即時ＨＥ ＯＦＤＭＡ ＡＣＫを要求し、優先順位ＢＥにＴＳ２を表示し、ＵＳおよび／またはＭＵ ＴＸＯＰを要求し、遅延ＭＵ ＢＡを要求する。

ＡＰは、ＯＦＤＭＡ ＭＵパケット６０８をＳＴＡ１およびＳＴＡ２に送信し、ＡＣＫタイプが即時ＨＥ ＯＦＤＭＡ ＡＣＫであることを表示する。ＳＴＡ１およびＳＴＡ２がパケットを正常に受信した後、ＳＴＡは、ＡＣＫポリシー表示に従い、ＳＴＡ１およびＳＴＡ２がＭＵパケットを受信するものと同じＯＦＤＭＡリソースを使用してＡＣＫ６１０を送信する。ＡＰは、トリガーフレーム６１２をＳＴＡ２およびＳＴＡ３に送信し、ＴＴＸＯＰがＵＬ ＭＵ−ＭＩＭＯ ＴＸＯＰであり、使用されるＡＣＫタイプがＭＵ ＢＡ／ＡＣＫであるべきことを表示する。次いで、ＳＴＡ２およびＳＴＡ３は、それらのＵＬパケット６１４をＵＬ ＭＵ−ＭＩＭＯを使用して送信する。次いで、ＡＰは、ＵＬ ＭＵ−ＭＩＭＯデータパケット６１４の受信を確認応答するために、フルチャネルを介してＭＵ ＢＡ／ＡＣＫ６１６を送信するものとする。ＡＰは、トリガーフレーム６１８をＳＴＡ１およびＳＴＡ３に送信し、ＴＴＸＯＰがＵＬ ＯＦＤＭＡ ＴＸＯＰであり、使用されるＡＣＫタイプが即時ＨＥ ＯＦＤＭＡ ＡＣＫであるべきことを表示する。次いで、ＳＴＡ２およびＳＴＡ３は、それらのＵＬパケット６２０および６２２を、トリガーフレームで表示されてもよいリソースを介してＵＬ ＯＦＤＭＡを使用して送信する。次いで、ＡＰは、ＵＬ ＯＦＤＭＡデータパケットの受信を確認応答するために、ＯＦＤＭＡ ＢＡ／ＡＣＫ６２４をＳＴＡ１およびＳＴＡ３に送信するものとする。ＤＬ ＯＦＤＭＡ ＢＡ／ＡＣＫは、ＵＬ ＯＦＤＭＡフレームが受信されたものと同じリソースを介して送信されてもよい。

図７は、スケジュールフレームにおける優先順位およびＡＣＫポリシーネゴシエーション手順の１つの例である。任意のＳＴＡは、ＳＴＡが１つまたは複数のアップリンクＴＸＯＰを要求しているパケットまたはトラフィックの優先順位およびその他の情報を、ＵＬＲフレームでＡＰに提供することができる。具体的には、ＳＴＡ１は、そのバッファまたは予想されるトラフィックを調べ、ＴＳ１がビデオストリームでありＴＳ２がベストエフォートトラフィックである２つのトラフィックストリーム（ＴＳ）を見つけることができ、したがってそれはバッファに入れられているトラフィックまたは将来予想されるトラフィックについてＵＬまたはＤＬ ＴＸＯＰを要求することができる。また、ＳＴＡ１は、ＴＳ１およびＴＳ２の優先順位をそれぞれ、ＶＩおよびＢＥとしてＵＬＲ７０６で表示することができる。ＳＴＡ１は、ＴＳ１およびＴＳ２の要求されるＡＣＫタイプをそれぞれ、ＭＵ ＢＡおよび遅延ＭＵ ＢＡとしてＵＬＲ７０６で表示することができる。同様に、ＳＴＡ２は、その予想されるトラフィックストリームＴＳ１がビデオストリームであることを調べることができ、したがって将来予想されるトラフィックについてＤＬ ＴＸＯＰを要求することができる。またＳＴＡ２は、ＴＳ１の優先順位をＶＩとして、ＴＳ１の要求されるＡＣＫタイプがＭＵ ＢＡであることをＵＬＲ７０２で表示することができる。同様に、ＳＴＡ３は、そのバッファを調べ、ＴＳ１がビデオストリームでありＴＳ２がベストエフォートトラフィックである２つのトラフィックストリーム（ＴＳ）を見つけることができ、したがってＳＴＡ３はバッファに入れられているトラフィックについてＵＬ ＴＸＯＰを要求することができる７０４。また、ＳＴＡ３は、ＴＳ１およびＴＳ２の優先順位をそれぞれ、ＶＩおよびＢＥとしてＵＬＲ７０４で表示することができる。ＳＴＡ１は、ＴＳ１およびＴＳ２の要求されるＡＣＫタイプをそれぞれ、ＭＵ ＢＡおよび遅延ＭＵ ＢＡとしてＵＬＲ７０６で表示することができる。

ＡＰは、受信側ＳＴＡによってＳＵまたはＭＵ送信ＴＸＯＰの送信をスケジュールするために、スケジュールフレーム７０８を使用することができる。トリガーフレーム７０８の内容は、ＡＰが受信した１つまたは複数のＵＬＲフレームに基づいてもよい。たとえば、使用可能なシステムリソースを所与として、ＵＬＲ１およびＵＬＲ２に基づき、ＡＰは、ＳＴＡ１およびＳＴＡ３のＵＬデータ送信を同時にネゴシエートするために、スケジュールフレーム７０８を送信することができ、優先順位およびＡＣＫポリシーをスケジュールフレームで表示することができ、ＭＵ ＢＡおよび優先順位ＶＩがＳＴＡ１およびＳＴＡ２について表示される。スケジュールフレーム７０８によってトリガーされるＴＸＯＰは、スケジュールされるＴＸＯＰ（ＳＴＸＯＰ）と称されてもよい。

ＳＴＸＯＰのＳＴＡ１およびＳＴＡ３からのＵＬデータ送信の受信側ＳＴＡ、たとえばＡＰは、たとえばＳＴＡ１およびＳＴＡ２のマルチＳＴＡまたはＭＵ ＢＡがＡＰ７１４によって送信される、ＳＴＸＯＰ中に、ＳＴＡ１ ７１０およびＳＴＡ２ ７１２からのデータパケットの受信後のＳＩＦＳ間隔の後にＡＣＫを確認応答するために、スケジュールフレームで表示されたＡＣＫスキームを使用すべきである。優先順位およびＡＣＫポリシーネゴシエーション手順を使用して、マルチＳＴＡは、ＡＰとの送信に使用可能な最大リソースを見出してネゴシエートした。また、スケジュールフレームによって複数のＵＬＲに同時に応答することは、示されているように、トリガーフレームおよび／またはデータ、またはアグリゲートフレームごとに各ＵＬＲに順次応答することに比べて、より効率的となることができる。

アグリゲートブロック確認応答のためのＡＰと選択されたＳＴＡのグループとの間の合意またはセッションの確立、ならびにＡＰとＳＴＡのグループとの間、またはＳＴＡのグループ内の要件もしくは条件が変化する場合にそのような合意またはセッションを終了する能力が要求されてもよい。管理フレームは、ブロック確認応答セッションに参加する数および固有のＳＴＡ、および確認応答フィードバックが即時であるべきか、遅延であるべきか、または時間依存のトラフィックについて最大もしくは限定された遅延に設定すべきかどうかをスケジュールするために使用されてもよい。ＡＰとＳＴＡのグループとの間のアグリゲートブロック確認応答セッションの確立は、アグリゲーションブロックＡＣＫ（Ａ−ＢＡ）セッション要求アクションフレームを介して送信機によってスケジュールされてもよい。

図８は、アグリゲーションブロックＡＣＫ（Ａ−ＢＡ）セッションスケジューリングフレームの例である。１つまたは複数のＡ−ＢＡセッション要求フレーム８００は、アグリゲートブロックＡＣＫポリシー、ＴＩＤ、バッファサイズ、セッション期間、および開始フレームシーケンス番号のような、セッションについて送信機の要求された設定を搬送することができる。Ａ−ＢＡセッション要求フレーム８００は、フレーム制御フィールド８０２、期間フィールド８０４、ＤＡ８０６、ＳＡ８０８、ＢＳＳＩＤ８１０、シーケンス制御フィールド８１２、フレームボディフィールド８１４、およびＦＣＳフィールド８１６を備えることができる。フレームボディフィールド８１４は、カテゴリＡ−ＢＡフィールド８１８、アクションフィールド８２０、および１つまたは複数の追加のＩＥ８２２を備えることができる。正常に受信されたＡ−ＢＡセッション要求フレームは、通常のＡＣＫまたは通常のアグリゲートＡＣＫにより受信されると確認応答されてもよく、次いで合意されたセッション設定およびその他の固有の能力情報を伴う受信機から送信機へのＡ−ＢＡセッション応答アクションフレームによって後続されてもよい。正常に受信されたＡ−ＢＡセッション応答フレームはまた、通常のＡＣＫまたは通常のアグリゲートＡＣＫによって受信されると確認応答されてもよい。

Ａ−ＢＡセッションの終了は、Ａ−ＢＡセッション終了要求アクションフレームによって搬送されてもよい。送信機または受信機は、このアクションフレームの確認応答された受信の後にこのセッションの終了を要求することができる。Ａ−ＢＡセッション終了要求フレームは、通常のＡＣＫまたは通常のアグリゲートＡＣＫによって受信されると確認応答されてもよい。

ＭＵ ＢＡの能力は、たとえば、能力フィールド、別のフィールド、サブフィールド、またはビーコンに含まれているＩＥ、プローブ要求およびプローブ応答フレーム、アソシエーション要求およびアソシエーション応答フレーム、またはその他のタイプの管理、制御または拡張フレームで表示されてもよい。ＭＵ ＢＡを使用する能力は、アソシエーションの時点および任意の他の時点において交換されてもよい。

ＤＬ ＭＵ ＢＡアグリゲーションの方法および手順が、本明細書において開示される。１つの実施形態において、グループアドレスは、本明細書において説明される以下の方法および手順の１つまたは任意の組み合わせによって、ＭＵ ＢＡフレーム内の各々個々のＳＴＡをアドレッシングするために信号伝達されてもよい。

たとえば、グループアドレス情報、グループＩＤ ＭＵ ＢＡを含むグループ情報は、ビーコン、アソシエーション要求、およびアソシエーション応答フレーム、またはＴＧａｘ ＨＥの新しい定義された管理フレームのような、既存の管理フレームによって送信されてもよい。たとえば、アソシエーション中に、ＳＴＡは、ＭＵ ＢＡフレームのデコードに使用されてもよいグループＩＤを割り当てられてもよい。グループ情報は、ＰＬＣＰヘッダおよび／またはＭＡＣヘッダで信号伝達されてもよい。グループ情報は、ＵＬ ＭＵ送信のためにＳＴＡのグループを信号伝達するポールフレーム、またはトリガーフレームのような制御フレームによって信号伝達されてもよい。

ポールまたはトリガーフレームは、空間ストリーム／周波数トーン割り当て、ＵＬ ＭＵ送信のＰＰＤＵ長さを含む期間、トリガーＰＰＤＵの最後に基づくＭＵ ＳＴＡ内の時間同期、周波数オフセット修正、および／または電力制御情報を含む、送信を許可されるＳＴＡのグループＩＤ情報の１つまたは任意の組み合わせを含むことができる。

特徴および要素は特定の組み合わせで好ましい実施形態において説明されるが、各々の特徴または要素は、好ましい実施形態の他の特徴および要素を使用せずに単独で使用するか、または本発明のその他の特徴および要素を伴うまたは伴わないさまざまな組み合わせで使用されることができる。本明細書において説明される解決策はＩＥＥＥ８０２．１１の固有のプロトコルを考慮するが、本明細書において説明される解決策がこのシナリオに制限されることなく、その他のワイヤレスシステムにも適用可能であることを理解されたい。ＳＩＦＳは、設計および手順の例においてさまざまなフレーム間スペーシングを表示するために使用されるが、ＲＩＦＳまたはその他の合意された時間間隔のようなその他のすべてのフレーム間スペーシングが同解決策において適用されてもよい。

特徴および要素は、特定の組み合わせにおいて上記で説明されるが、各々の特徴または要素は、単独で使用されるか、または他の特徴および要素との任意の組み合わせで使用されてもよいことを、当業者であれば理解するであろう。加えて、本明細書において説明される方法は、コンピュータまたはプロセッサにより実行するためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施されてもよい。コンピュータ可読媒体の例は、（有線またはワイヤレス接続を介して送信される）電子信号およびコンピュータ可読ストレージ媒体を含む。コンピュータ可読ストレージ媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、これらに限定されることはない。ソフトウェアと共同してプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用する無線周波数送受信機を実施するために使用されてもよい。

Claims (15)

1. ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）のステーション（ＳＴＡ）によって実行される方法であって、
   前記ＳＴＡからＡＰに、第１のトラフィック優先順位の表示と、１つまたは複数のトラフィック識別子（ＩＤ）に対応する１つまたは複数のキューサイズとを送信するステップと、
   前記送信するステップに応答して、前記ＡＰからフレームを受信するステップであって、前記フレームは、マルチユーザトラフィックのためのトリガーフレームであり、第２のトラフィック優先順位を表示する、ステップと、
   前記表示された第２のトラフィック優先順位よりも大きいかまたは等しい優先順位を有する１つまたは複数のＭＵフレームを、前記ＳＴＡによって送信するステップと
   を含む方法。
2. 前記送信された１つまたは複数のＭＵフレームの１つまたは複数の確認応答を、前記ＳＴＡによって受信するステップであって、前記１つまたは複数の確認応答は、前記１つまたは複数のＭＵフレームの正確なデコーディングまたは不正確なデコーディングのいずれかを表示する、ステップ
   をさらに含む、請求項１に記載の方法。
3. マルチユーザ（ＭＵ）ブロック確認応答（ＢＡ）フレームをサポートしている能力の表示を、前記ＳＴＡから前記ＡＰに送信するステップ
   をさらに含む、請求項１に記載の方法。
4. 前記１つまたは複数のＭＵフレームは、ＡＣＫタイプの表示を含む、請求項１に記載の方法。
5. 前記１つまたは複数の確認応答のＡＣＫタイプは、ＭＩＭＯ ＡＣＫタイプである、請求項２に記載の方法。
6. 前記１つまたは複数の確認応答のＡＣＫタイプは、ＯＦＤＭＡ ＡＣＫタイプである、請求項２に記載の方法。
7. ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）における動作のためのステーション（ＳＴＡ）であって、
   前記ＳＴＡからＡＰに、第１のトラフィック優先順位の表示と、１つまたは複数のトラフィック識別子（ＩＤ）に対応する１つまたは複数のキューサイズとを送信するように構成された送信機と、
   前記ＡＰからフレームを受信するように構成された受信機であって、前記フレームは、マルチユーザトラフィックのためのトリガーフレームであり、第２のトラフィック優先順位を表示する、受信機と
   を備え、
   前記送信機は、前記表示された第２のトラフィック優先順位よりも大きいかまたは等しい優先順位を有する１つまたは複数のＭＵフレームを送信するようにさらに構成される
   ＳＴＡ。
8. 前記受信機は、前記送信された１つまたは複数のＭＵフレームの１つまたは複数の確認応答を受信するようにさらに構成され、前記１つまたは複数の確認応答は、前記１つまたは複数のＭＵフレームの正確なデコーディングまたは不正確なデコーディングのいずれかを表示する、請求項７に記載のＳＴＡ。
9. 前記送信機は、マルチユーザ（ＭＵ）ブロック確認応答（ＢＡ）フレームをサポートしている能力の表示を、前記ＡＰに送信するようにさらに構成される、請求項７に記載のＳＴＡ。
10. 前記フレームは、ＡＣＫタイプの表示を含む、請求項７に記載のＳＴＡ。
11. 前記１つまたは複数の確認応答のＡＣＫタイプは、ＭＩＭＯ ＡＣＫタイプである、請求項８に記載のＳＴＡ。
12. 前記１つまたは複数の確認応答のＡＣＫタイプは、ＯＦＤＭＡ ＡＣＫタイプである、請求項８に記載のＳＴＡ。
13. ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）のアクセスポイント（ＡＰ）において使用する方法であって、
    マルチユーザ（ＭＵ）ブロック確認応答（ＢＡ）フレームをサポートしているＳＴＡの能力の表示を、前記ＡＰにより前記ＳＴＡから受信するステップと、
    １つまたは複数のマルチユーザ（ＭＵ）フレームを、前記ＡＰにより前記ＳＴＡに送信するステップであって、前記１つまたは複数のＭＵフレームは、確認応答タイプの表示を含む、ステップと、
    前記確認応答タイプの確認応答フレームを、前記ＡＰにより前記ＳＴＡから受信するステップと
    を含む方法。
14. 前記確認応答タイプは、ＭＩＭＯ ＡＣＫタイプである、請求項１３に記載の方法。
15. 前記確認応答タイプは、ＯＦＤＭＡ ＡＣＫタイプである、請求項１３に記載の方法。

Images