JP2018518908A

JP2018518908A - ワイヤレスネットワークにおいてマルチユーザアップリンク媒体アクセス制御プロトコルを実装するためにバッファステータス報告を要求するための方法および装置

Info

Publication number: JP2018518908A
Application number: JP2017564909A
Authority: JP
Inventors: アルフレッド・アスタージャディ; シモン・マーリン; ジョージ・チェリアン
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2015-06-22
Filing date: 2016-06-09
Publication date: 2018-07-12
Anticipated expiration: 2036-06-09
Also published as: CN107771401A; ES2833350T3; WO2016209634A1; KR102094370B1; CN107771401B; JP6721616B2; BR112017027631A2; EP3311617B1; KR20180019591A; EP3311617A1; TW201701712A; US10536948B2; US10999852B2; US20160374093A1; US20200128551A1; CA2984641A1

Abstract

アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法および装置が提供される。一態様では、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法が提供される。方法は、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するステップであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップを含む。方法は、要求フレームを1つまたは複数の局の各々に送信するステップを含む。方法は、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するステップを含む。

Description

本開示のいくつかの態様は、一般にワイヤレス通信に関し、より詳細には、ワイヤレスネットワークにおいてマルチユーザアップリンク媒体アクセス制御(MAC)プロトコルを実装するためにバッファステータス報告を要求するための方法および装置に関する。

多くの電気通信システムでは、いくつかの相互作用する空間的に分離されたデバイス間でメッセージを交換するために、通信ネットワークが使用される。ネットワークは、たとえば、メトロポリタンエリア、ローカルエリア、またはパーソナルエリアとすることができる地理的範囲に従って分類される場合がある。そのようなネットワークは、それぞれ、ワイドエリアネットワーク(WAN)、メトロポリタンエリアネットワーク(MAN)、ローカルエリアネットワーク(LAN)、またはパーソナルエリアネットワーク(PAN)と呼ばれ得る。ネットワークはまた、様々なネットワークノードおよびデバイスを相互接続するために使用されるスイッチング/ルーティング技法(たとえば、回線交換対パケット交換)、送信のために用いられる物理媒体のタイプ(たとえば、ワイヤード対ワイヤレス)、および使用される通信プロトコルのセット(たとえば、インターネットプロトコルスイート、SONET(同期光ネットワーキング)、イーサネット(登録商標)など)によって異なる。

ワイヤレスネットワークは、ネットワーク要素がモバイルであり、したがって動的な接続性の必要性を有するとき、またはネットワークアーキテクチャが固定トポロジではなくアドホックトポロジで形成される場合、好適であることが多い。ワイヤレスネットワークは、無線、マイクロ波、赤外線、光などの周波数帯域内の電磁波を使用して、無誘導伝搬モードにおいて無形物理媒体を用いる。ワイヤレスネットワークは、有利には、固定ワイヤードネットワークと比較すると、ユーザモビリティおよび迅速なフィールド展開を容易にする。

ワイヤレス通信システムに要求される帯域幅要件の増加の問題に対処するために、高いデータスループットを達成しながら、複数のユーザ端末がチャネルリソースを共有することによって単一のアクセスポイントと通信することを可能にするための異なる方式が開発されている。通信リソースが限られているので、アクセスポイントと複数の端末との間を通過するトラフィックの量を低減することが望ましい。たとえば、複数の端末がアップリンク通信をアクセスポイントに送るとき、すべての送信のアップリンクを完了するためにトラフィックの量を最小限に抑えることが望ましい。したがって、ワイヤレスネットワークにおいてマルチユーザアップリンク媒体アクセス制御(MAC)プロトコルを実装するためにバッファステータス報告を要求するための方法および装置が必要とされている。

添付の特許請求の範囲内のシステム、方法およびデバイスの様々な実装形態は、各々がいくつかの態様を有し、そのうちのいずれも、本明細書で説明する望ましい属性を単独で担うものではない。添付の特許請求の範囲を限定することなしに、いくつかの顕著な特徴について明細書で説明する。

本明細書で説明する主題の1つまたは複数の実装形態の詳細は、添付の図面および以下の説明に記載されている。他の特徴、態様、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。以下の図の相対寸法は、一定の縮尺で描かれていない場合があることに留意されたい。

本開示の一態様は、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法を提供する。方法は、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するステップであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップを含む。方法は、要求フレームを1つまたは複数の局の各々に送信するステップを含む。方法は、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するステップを含む。

本開示の別の態様は、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るためのワイヤレスデバイスを提供する。ワイヤレスデバイスは、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するように構成されたプロセッサであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、プロセッサを備える。ワイヤレスデバイスは、要求フレームを1つまたは複数の局に送信するように構成された送信機を備える。ワイヤレスデバイスは、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するように構成された受信機を備える。

本開示の別の態様は、実行されると、ワイヤレスデバイスに方法を実行させるコードを含む、非一時的コンピュータ可読媒体を提供する。方法は、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するステップであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップを含む。方法は、要求フレームを1つまたは複数の局の各々に送信するステップを含む。方法は、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するステップを含む。

本開示の別の態様は、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るためのワイヤレスデバイスを提供する。ワイヤレスデバイスは、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するための手段を備える。要求フレームは、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する。ワイヤレスデバイスは、要求フレームを1つまたは複数の局に送信するための手段を備える。ワイヤレスデバイスは、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するための手段を備える。

本開示の別の態様は、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法を提供する。方法は、アップリンクバッファ報告を要求する要求フレームを受信するステップであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップを含む。方法は、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成するステップを含む。方法は、報告フレームをワイヤレスデバイスに送信するステップを含む。

本開示の別の態様は、アップリンクデータ送信用にマルチユーザ通信リソースを割り振るための局を提供する。局は、アップリンクバッファ報告を要求する要求フレームを受信するように構成された受信機であって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、受信機を備える。局は、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成するように構成されたプロセッサを備える。局は、報告フレームをワイヤレスデバイスに送信するように構成された送信機を備える。

本開示の別の態様は、実行されると、局に方法を実行させるコードを含む、非一時的コンピュータ可読媒体を提供する。方法は、アップリンクバッファ報告を要求する要求フレームを受信するステップであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップを含む。方法は、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成するステップを含む。方法は、報告フレームをワイヤレスデバイスに送信するステップを含む。

本開示の別の態様は、アップリンクデータ送信用にマルチユーザ通信リソースを割り振るための局を提供する。局は、アップリンクバッファ報告を要求する要求フレームを受信するための手段であって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、手段を備える。局は、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成するための手段を備える。局は、報告フレームをワイヤレスデバイスに送信するための手段を備える。

いくつかの実装形態による、アクセスポイント(AP)とユーザ端末(STA)とを有するマルチユーザワイヤレス通信システムを示す図である。図1のワイヤレス通信システム内で用いられ得るワイヤレスデバイスにおいて利用され得る様々な構成要素を示す図である。いくつかの実装形態による、アクセスポイントと複数の局との間のマルチユーザ(MU)アップリンク通信をセットアップするためのフレーム交換の時間図である。いくつかの実装形態による、アクセスポイントと複数の局との間のマルチユーザ(MU)アップリンク通信をセットアップするためのフレーム交換の別の時間図である。いくつかの実装形態による、局からのアップリンクバッファステータス報告を要求するためのトリガフレームのフォーマットを示す図である。いくつかの実装形態による、局からのアップリンクバッファステータス報告を要求するための送信可(CTS:clear to send)-to-selfフレームのフォーマットを示す図である。いくつかの実装形態による、アップリンクバッファステータスを報告するためのサービス品質(QoS)ヌルフレームのフォーマットを示す図である。いくつかの実装形態による、アップリンクバッファステータスを報告するためのサービス品質(QoS)データフレームのフォーマットを示す図である。いくつかの実装形態による、アップリンクバッファステータスを報告するための省電力(PS)ポールフレームのフォーマットを示す図である。いくつかの実装形態による、アップリンクバッファステータスを報告するための高効率(HE)制御フレームのフォーマットを示す図である。いくつかの実装形態による、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法の一態様のフローチャートである。いくつかの実装形態による、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための別の方法の一態様のフローチャートである。

新規のシステム、装置、および方法の様々な態様について、添付の図面を参照しながら以下でより十分に説明する。しかしながら、本開示の教示は、多くの異なる形態で具現化され得、本開示全体にわたって提示される任意の特定の構造または機能に限定されるものとして解釈されるべきではない。むしろ、これらの態様は、本開示が徹底的で完全になり、本開示の範囲を当業者に十分に伝えるようにするために提供されるものである。本明細書の教示に基づいて、本開示の範囲が、本発明の任意の他の態様とは無関係に実装されるにせよ、本発明の任意の他の態様と組み合わせて実装されるにせよ、本明細書で開示する新規のシステム、装置、および方法の任意の態様を包含するものであることを当業者は諒解されたい。たとえば、本明細書に記載する任意の数の態様を使用して、装置が実装されてもよく、または方法が実施されてもよい。加えて、本発明の範囲は、本明細書に記載する本発明の様々な態様に加えて、またはそれ以外の、他の構造、機能、または構造および機能を使用して実施されるそのような装置または方法を包含するものである。本明細書で開示する任意の態様は請求項の1つまたは複数の要素によって具現化され得ることを理解されたい。

特定の態様について本明細書で説明するが、これらの態様の多くの変形および置換が本開示の範囲内に入る。好ましい態様のいくつかの利益および利点について述べるが、本開示の範囲は、特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、異なるワイヤレス技術、システム構成、ネットワーク、および送信プロトコルに広く適用可能であるものであり、それらのうちのいくつかが例として図および好ましい態様の以下の説明において示される。詳細な説明および図面は、限定ではなく本開示を説明するものにすぎず、本開示の範囲は、添付の特許請求の範囲およびその等価物によって定義される。

ワイヤレスネットワーク技術は、様々なタイプのワイヤレスローカルエリアネットワーク(WLAN)を含み得る。WLANは、広く使用されているネットワーキングプロトコルを用いて、近くのデバイスを互いに相互接続するために使用され得る。本明細書で説明する様々な態様は、Wi-Fiまたは、より一般的には、ワイヤレスプロトコルのIEEE802.11ファミリーの任意のメンバーなど、任意の通信規格に適用することができる。

いくつかの態様では、ワイヤレス信号は、直交周波数分割多重(OFDM)、直接シーケンススペクトラム拡散(DSSS)通信、OFDMとDSSS通信の組合せ、または他の方式を使用して、高効率802.11プロトコルに従って送信され得る。高効率802.11プロトコルの実装形態は、インターネットアクセス、センサー、メータリング、スマートグリッドネットワーク、または他のワイヤレス適用例に使用され得る。有利には、この特定のワイヤレスプロトコルを実装するいくつかのデバイスの態様は、他のワイヤレスプロトコルを実装するデバイスよりも少ない電力を消費することができ、短距離にわたってワイヤレス信号を送信するために使用され得、および/または人間などの物体によって妨害される可能性が低い信号を送信することが可能であり得る。

いくつかの実装形態では、WLANは、ワイヤレスネットワークにアクセスする構成要素である様々なデバイスを含む。たとえば、2つのタイプのデバイス、すなわち、アクセスポイント(「AP」)およびクライアント(局または「STA」とも呼ばれる)があり得る。一般に、APはWLAN用のハブまたは基地局として働き、STAはWLANのユーザとして働く。たとえば、STAは、ラップトップコンピュータ、携帯情報端末(PDA)、モバイルフォンなどであり得る。一例では、STAは、インターネットまたは他のワイドエリアネットワークへの一般的な接続性を得るために、Wi-Fi(たとえば、802.11axなどのIEEE802.11プロトコル)準拠のワイヤレスリンクを介してAPに接続する。いくつかの実装形態では、STAはAPとして使用される場合もある。

本明細書で説明する技法は、直交多重化方式に基づく通信システムを含む様々なブロードバンドワイヤレス通信システムに使用され得る。そのような通信システムの例としては、空間分割多元接続(SDMA)、時分割多元接続(TDMA)、直交周波数分割多元接続(OFDMA)システム、シングルキャリア周波数分割多元接続(SC-FDMA)システムなどがある。SDMAシステムは、十分に異なる方向を利用して、複数のユーザ端末に属するデータを同時に送信することができる。TDMAシステムは、送信信号を異なるタイムスロットに分割することによって、複数のユーザ端末が同じ周波数チャネルを共有することを可能にすることができ、各タイムスロットは、異なるユーザ端末に割り当てられる。TDMAシステムは、GSM(登録商標)または当技術分野で知られている何らかの他の規格を実装し得る。OFDMAシステムは、システム帯域幅全体を複数の直交サブキャリアに分割する変調技法である直交周波数分割多重(OFDM)を利用する。これらのサブキャリアは、トーン、ビンなどと呼ばれることもある。OFDMでは、各サブキャリアは、データによって独立して変調され得る。OFDMシステムは、IEEE802.11または当技術分野で知られている何らかの他の規格を実装し得る。SC-FDMAシステムは、システム帯域幅にわたって分散されたサブキャリア上で送信するためのインターリーブFDMA(IFDMA)、隣接するサブキャリアのブロック上で送信するための局所化FDMA(LFDMA)、または隣接するサブキャリアの複数のブロック上で送信するための拡張FDMA(EFDMA)を利用し得る。一般に、変調シンボルは、OFDMでは周波数領域において、SC-FDMAでは時間領域において送られる。SC-FDMAシステムは、3GPP-LTE(第3世代パートナーシッププロジェクトロングタームエボリューション)または他の規格を実装し得る。

本明細書の教示は、様々なワイヤード装置またはワイヤレス装置(たとえば、ノード)に組み込まれてもよい(たとえば、それらの装置の内部に実装されるか、またはそれらの装置によって実行されてもよい)。いくつかの態様では、本明細書の教示に従って実装されるワイヤレスノードは、アクセスポイントまたはアクセス端末を含み得る。

アクセスポイント(「AP」)は、ノードB、無線ネットワークコントローラ(「RNC」)、eノードB、基地局コントローラ(「BSC」)、基地トランシーバ局(「BTS」)、基地局(「BS」)、トランシーバ機能(「TF」)、無線ルータ、無線トランシーバ、基本サービスセット(「BSS」)、拡張サービスセット(「ESS」)、無線基地局(「RBS」)、または何らかの他の用語を含み得るか、それらとして実装され得るか、またはそれらとして知られ得る。

局「STA」はまた、ユーザ端末、アクセス端末(「AT」)、加入者局、加入者ユニット、移動局、リモート局、リモート端末、ユーザエージェント、ユーザデバイス、ユーザ機器、または何らかの他の用語を含み得るか、それらとして実装され得るか、またはそれらとして知られ得る。いくつかの実装形態では、アクセス端末は、セルラー電話、コードレス電話、セッション開始プロトコル(「SIP」)電話、ワイヤレスローカルループ(「WLL」)局、携帯情報端末(「PDA」)、ワイヤレス接続機能を有するハンドヘルドデバイス、またはワイヤレスモデムに接続された何らかの他の適切な処理デバイスを含み得る。したがって、本明細書で教示する1つまたは複数の態様は、電話(たとえば、セルラーフォンまたはスマートフォン)、コンピュータ(たとえば、ラップトップ)、ポータブル通信デバイス、ヘッドセット、ポータブルコンピューティングデバイス(たとえば、携帯情報端末)、エンターテインメントデバイス(たとえば、音楽デバイスもしくはビデオデバイス、または衛星ラジオ)、ゲームデバイスもしくはゲームシステム、全地球測位システムデバイス、またはワイヤレス媒体を介して通信するように構成された任意の他の適切なデバイスに組み込まれ得る。

図1は、いくつかの実装形態による、アクセスポイント(AP)とユーザ端末(STA)とを有するマルチユーザワイヤレス通信システム100を示す。簡単にするために、ただ1つのアクセスポイント102が図1に示されている。アクセスポイントは、一般に、ユーザ端末と通信する固定局であり、基地局と呼ばれるか、または何らかの他の用語を使用して呼ばれることもある。局(「STA」)としても知られるユーザ端末は、固定であってもモバイルであってもよく、移動局もしくはワイヤレスデバイスと呼ばれるか、または何らかの他の用語を使用して呼ばれることもある。アクセスポイント102は、ダウンリンクおよびアップリンク上で任意の所与の瞬間において1つまたは複数のユーザ端末104a、104b、104c、104d(以下ではまとめてユーザ端末104a〜104d)と通信してもよい。ダウンリンク(すなわち、順方向リンク)は、AP102からユーザ端末104a〜104dのうちのいずれかへの任意の通信リンクであり、アップリンク(すなわち、逆方向リンク)は、ユーザ端末104a〜104dからAP102への任意の通信リンクである。ユーザ端末は、別のユーザ端末とピアツーピアで通信する場合もある。

システム100は、ダウンリンクおよびアップリンク上でのデータ送信のために複数の送信アンテナおよび複数の受信アンテナを用いる場合がある。たとえば、AP102は、N_ap個のアンテナ(図1には示されていない)を備え、ダウンリンク送信では多入力(MI)を表し、アップリンク送信では多出力(MO)を表す。K個の選択されたユーザ端末104a〜104d(たとえば、STA104a〜104d)のセットは、ダウンリンク送信では多出力を集合的に表し、アップリンク送信では多入力を集合的に表す。各選択されたユーザ端末は、ユーザ固有のデータをアクセスポイントに送信し得、および/またはユーザ固有のデータをアクセスポイントから受信し得る。一般に、各選択されたユーザ端末は、1つまたは複数のアンテナ(すなわち、N_ut≧1)(図1には示されていない)を備え得る。K個の選択されたユーザ端末は同じ数のアンテナを有することができ、または、1つもしくは複数のユーザ端末は異なる数のアンテナを有し得る。

システム100は、時分割複信(TDD)システムまたは周波数分割複信(FDD)システムであり得る。TDDシステムの場合、ダウンリンクおよびアップリンクは同じ周波数帯域を共有する。FDDシステムの場合、ダウンリンクおよびアップリンクは異なる周波数帯域を使用する。システム100は、送信のために単一のキャリアまたは複数のキャリアを利用する場合もある。各ユーザ端末は、単一のアンテナ(たとえば、コストを抑えるために)または複数のアンテナ(たとえば、追加コストがサポートされ得る場合)を備え得る。システム100はまた、送信/受信を異なるタイムスロットに分割することによって、ユーザ端末104a〜104dが同じ周波数チャネルを共有する場合、TDMAシステムであり得、各タイムスロットは、異なるユーザ端末104a〜104dに割り当てられ得る。図1に示すように、AP102は、以下の図2〜図8でより詳細に説明するように、1つまたは複数のタスクを実行するように構成され得るマルチユーザ(MU)アップリンク(UL)モジュール224を含み得る。さらに、ユーザ端末104a〜104dの各々は、MU-ULモジュール224を含み得る。MU-ULモジュール224について、以下の図2に関してより詳細に説明する。

図2は、ワイヤレス通信システム100内で用いられ得るワイヤレスデバイス202において利用され得る様々な構成要素を示す。ワイヤレスデバイス202は、本明細書で説明する様々な方法を実装するように構成され得るデバイスの一例である。ワイヤレスデバイス202は、AP102またはユーザ端末104a〜104dのうちの1つを実装し得る。

ワイヤレスデバイス202は、ワイヤレスデバイス202の動作を制御するプロセッサ204を含み得るMU-ULモジュール224を含み得る。プロセッサ204は、中央処理装置(CPU)と呼ばれることもある。いくつかの実装形態では、MU-ULモジュール224は加えて、メモリ206を備え得、メモリ206は、読取り専用メモリ(ROM)とランダムアクセスメモリ(RAM)の両方を含む場合があり、命令およびデータをプロセッサ204に提供する。メモリ206の一部分は、不揮発性ランダムアクセスメモリ(NVRAM)を含む場合もある。プロセッサ204は、メモリ206内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行し得る。メモリ206中の命令は、本明細書で説明する方法を実装するように実行可能であり得る。

プロセッサ204は、1つまたは複数のプロセッサを用いて実装される処理システムの構成要素を備え得るか、またはその構成要素であり得る。1つまたは複数のプロセッサは、汎用マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、コントローラ、状態機械、ゲート論理、個別ハードウェア構成要素、専用ハードウェア有限状態機械、または情報の計算もしくは他の操作を実行することができる任意の他の適切なエンティティの任意の組合せを用いて実装され得る。

処理システムは、実行されると、装置またはプロセッサ204に本出願で説明する任意の方法を実行させるコードを含む、非一時的コンピュータ可読媒体を含む場合もある。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかにかかわらず、任意のタイプの命令を意味するように広く解釈されるべきである。命令は、(たとえば、ソースコードフォーマット、バイナリコードフォーマット、実行可能コードフォーマット、または任意の他の適切なコードのフォーマットにおける)コードを含み得る。命令は、1つまたは複数のプロセッサによって実行されると、処理システムに本明細書で説明する様々な機能を実行させる。

したがって、いくつかの実装形態では、プロセッサ204および/またはメモリ206は、1つもしくは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するための手段および/またはアップリンクバッファ内のデータの量もしくはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成するための手段の少なくとも一部分を備えるか、または形成し得る。

ワイヤレスデバイス202は、ワイヤレスデバイス202と遠隔地との間のデータの送信および受信を可能にする送信機210および受信機212を含み得るハウジング208を含む場合もある。送信機210および受信機212は、組み合わされてトランシーバ214になる場合がある。単一または複数のトランシーバアンテナ216は、ハウジング208に取り付けられ、トランシーバ214に電気的に結合され得る。したがって、いくつかの実装形態では、送信機210は、要求フレームを1つもしくは複数の局に送信するための手段および/または報告フレームをアクセスポイントに送信するための手段の少なくとも一部分を備えるか、または形成し得る。同様に、受信機212は、1つもしくは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信するための手段および/またはアップリンクバッファ報告を要求する要求フレームを受信するための手段の少なくとも一部分を備えるか、または形成し得る。

ワイヤレスデバイス202は、トランシーバ214によって受信された信号のレベルを検出および定量化するために使用され得る信号検出器218を含む場合もある。信号検出器218は、そのような信号を、総エネルギー、シンボル当たりのサブキャリア当たりのエネルギー、電力スペクトル密度および他の信号として検出し得る。ワイヤレスデバイス202は、信号を処理する際に使用するためのデジタル信号プロセッサ(DSP)220を含む場合もある。

ワイヤレスデバイス202の様々な構成要素は、データバスに加えて、電力バス、制御信号バス、およびステータス信号バスを含み得るバスシステム222によって互いに結合され得る。

本開示のいくつかの態様は、複数のユーザ端末からAPにアップリンク(UL)信号を送信することをサポートする。いくつかの実装形態では、UL信号は、マルチユーザMIMO(MU-MIMO)システムにおいて送信され得る。代替的に、UL信号は、マルチユーザFDMA(MU-FDMA)システムまたは同様のFDMAシステムにおいて送信され得る。これらの実装形態では、UL-MU-MIMO送信またはUL-FDMA送信は、複数のユーザ端末からAPに同時に送られ得、ワイヤレス通信における効率を上げることができる。

ますます多くのワイヤレスデバイスおよびモバイルデバイスは、ワイヤレス通信システムに要求される帯域幅要件をますます強調する。通信リソースが限られているので、APと複数のSTAとの間を通過するトラフィックの量を低減することが望ましい。たとえば、複数の端末がアップリンク通信をアクセスポイントに送るとき、すべての送信のアップリンクを完了するためにトラフィックの量を最小限に抑えることが望ましい。したがって、本明細書で説明する実装形態は、通信交換と、スケジューリングと、APへのアップリンク送信のスループットを増加させるための特定のフレームとを利用することをサポートする。

ULリソースの効率的な割振りのために、APは、そのAPに関連付けられたSTAのアップリンクバッファステータスを判定するための何らかの機構を有するべきである。これは、APが、リソース(たとえば、周波数帯域幅、チャネルおよびそれらの帯域幅またはチャネル内の持続時間)を、アップリンクバッファにおいて送信する準備ができている待ち行列に入れられたアップリンクデータを有するSTAに割り振ることを可能にする。さらに、特定のAPに関連付けられたSTAのアップリンクバッファステータスを判定することができることは、そのAPが、STAの各々における送信のために待ち行列に入れられたアップリンクデータの量に基づいて、それらのリソースの割振りを最適化することを可能にし得る。したがって、本出願では、バッファステータス報告機構が、特定のAPに関連付けられた各STAにおける送信のために待ち行列に入れられたデータの量に関する情報をAPに提供し得る、実装形態について説明する。

図3Aは、いくつかの実装形態による、アクセスポイント(たとえば、図1のAP102)と複数の局(たとえば、STA104a〜104d)との間のマルチユーザ(MU)アップリンク通信をセットアップするためのフレーム交換の時間図300を示す。ダウンリンク方向に(たとえば、APからSTAに)送られるメッセージまたはフレームは、斜めのハッチパターンを有するように示されているが、アップリンク方向に(たとえば、STAからAPに)送られるメッセージまたはフレームは、パターンなしで示されている。図3Aは、AP102を含むワイヤレスLANの存在を通知するためにAP102によって周期的に送信され得るビーコンフレーム302を示す。AP102がチャネルリソースを2つ以上のSTAに最適にスケジュールするために、AP102は、ポーリングフレームを送ることによって、1つまたは複数のSTAからのアップリンクバッファ報告(図3Aの306、308、310)を請求し得る。本出願は、この目的でポーリングフレームとして働き得る少なくとも2つのフレーム、すなわち、マルチユーザモードである間にSTAからのアップリンクバッファ報告を請求するためのトリガフレーム(図3Aの304、314、図3Bの354、364、および図4の400)と、シングルユーザモードでSTAからのアップリンクバッファ報告を請求するための特別に修正された送信可(CTS)-to-selfフレーム(図3Aの326および図5の500)とを企図する。そのようなフレームは、「要求フレーム304、314、326、354、364、400、500」として知られ得る。本出願は、アップリンクバッファ報告をAPに送り返すためにポーリングされたSTAによって利用され得る少なくとも4つの報告フレーム、すなわち、サービス品質(QoS)ヌルフレーム(600、図6参照)と、QoSデータフレーム(700、図7参照)と、PSポールフレーム(800、図8参照)と、HE制御フレーム(900、図9参照)とを企図する。そのようなフレームは、「報告フレーム306、308、310、322、328、600、700、800、900」として知られ得る。図3Aは、トリガフレーム304、314を使用したMUモードにおける請求の2つの例と、CTS-to-selfフレーム326を使用したSUモードにおける請求の1つの例とを示す。

MUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第1の例では、AP102は、トリガフレーム304を送信し得、任意の関連するSTAによるトリガフレーム304の受信は、受信側STAに、STAからのアップリンクバッファ報告に対するAP102からの要求を示すことになる。トリガフレーム304は加えて、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を1つまたは複数の受信側STAに割り振るための情報を含み得る。トリガフレーム304は、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する場合もある。次いで、トリガフレーム304によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、それらのアップリンクバッファ報告を送信し得る。たとえば、トリガフレーム304が第1、第2および第3のSTA(たとえば、図1のSTA104a、104b、104c)の各々にアドレッシングされ、それらに対するリソース割振りを含んでいたと仮定すると、図示のように、割り振られたリソースにおいて、第1のSTAは、アップリンクバッファ報告を含むPSポール1フレーム306を送信し得、第2のSTAは、アップリンクバッファ報告を含むPSポール2フレーム308を送信し得、第3のSTAは、アップリンクバッファ報告を含むPSポール3フレーム310を送信し得る。アップリンクバッファ報告を含むPSポールフレーム306、308、310を正確に受信したことに応答して、AP102は、確認応答(ACK)フレーム312を第1、第2および第3のSTAに送信し得る。これは、マルチユーザ(MU)送信機会(TXOP)の間にフレームが交換されるとき、好ましい方法であり得る。いくつかの他の実装形態では、予定受信側STAは、ランダムな時間にアップリンクバッファ報告を含むフレームを送るように構成され得、トリガフレームは、ランダムアクセスを可能にするトリガフレーム(たとえば、TF-Rトリガフレーム)である。報告フレーム(たとえば、PSポールフレーム306、308、310)内のアップリンクバッファ報告を受信すると、AP102は、1つまたは複数の局の各々からの受信されたアップリンクバッファ報告に基づいてアップリンクデータ送信用に通信リソースを1つまたは複数の局(たとえば、局104a〜104c)に割り振るメッセージを送り得る。したがって、各局は、局からのアップリンクバッファ報告に少なくとも部分的に基づいてアップリンクデータ送信用に通信リソースの一部分を局に割り振るメッセージをアクセスポイント102から受信し得る。

MUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第2の例では、AP102は、トリガフレーム314を送信し得、任意の関連するSTAによるトリガフレーム314の受信は、STAからのアップリンクバッファ報告に対するAPからの要求を示すことになる。トリガフレーム304と同様に、トリガフレーム314は加えて、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を1つまたは複数の受信側STAに割り振るための情報、ならびにアップリンクバッファ報告のフォーマットがアップリンクバッファ内の待ち行列に入れられたデータの量またはアップリンクバッファ内の待ち行列に入れられたデータを送信するための要求される時間の量のいずれかであるという要求を含み得る。次いで、トリガフレーム314によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、それらのアップリンクバッファ報告を送信し得る。たとえば、トリガフレーム314が第5のSTA(図1に示されていない)にアドレッシングされ、そのSTAに対するリソース割振りを含んでいたと仮定すると、第5のSTAは、割り振られたリソースにおいて、アップリンクバッファ報告を含むQoSヌルフレーム322を送信し得る。図3Aは加えて、トリガフレーム314の後に、それらのそれぞれのリソース割振りにおいて、AP102によって第3および第5のSTAにそれぞれ送信されたダウンリンクデータフレーム316および318を示す。図3Aは加えて、ダウンリンクデータフレーム316を受信したことに応答して第3のSTAによって送信されたACKおよびアップリンクデータフレーム320を示す。フレーム316、318および320は、アップリンクバッファ報告の請求および提供に直接関係しないが、MU通信方式における文脈および強調のために示されている。アップリンクバッファ報告を含むQoSヌルフレーム322を正確に受信したことに応答して(ならびにACKおよびアップリンクデータフレーム320を正確に受信したことに応答して)、AP102は、ブロック確認応答(BA)フレーム324を第3および第5のSTAに送信し得る。フレーム304から324は、マルチユーザ実装形態の一部として示されている。

SUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第1の例では、AP102は、CTS-to-selfフレーム326を送信し得、関連するSTAによるCTS-to-selfフレーム326の受信は、STAからのアップリンクバッファ報告に対するAP102からの要求を示すことになる。そのようなSUモード動作では、受信側STAは、その送信パラメータの制御を有し得、このことは、ネットワークにおける送信電力不均衡の場合は特に、SUモードにおいて望ましい。CTS-to-selfフレームの受信機アドレス(RA)がフレームを生成した同じデバイスに関連付けられた識別子によってポピュレートされる、CTS-to-selfフレームの従来の利用とは対照的に、CTS-to-selfフレーム326の受信機アドレス(RA)は、アップリンクバッファ報告が請求されるべきターゲットSTAに関連付けられた識別子によってポピュレートされる。CTS-to-selfフレーム326は加えて、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を受信側STAに割り振る情報と、アップリンクバッファ報告のフォーマットがアップリンクバッファ内の待ち行列に入れられたデータの量またはアップリンクバッファ内の待ち行列に入れられたデータを送信するための要求される時間の量のいずれかであるという要求とを含み得る。次いで、CTS-to-selfフレーム326によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、そのアップリンクバッファ報告を送信し得る。たとえば、CTS-to-selfフレーム326が第8のSTA(図1に示されていない)にアドレッシングされ、そのSTAに対するリソース割振りを含んでいたと仮定すると、第8のSTAは、割り振られたリソースにおいて、アップリンクバッファ報告を含むPSポールフレーム328を送信し得る。アップリンクバッファ報告を含むPSポールフレーム328を正確に受信したことに応答して、AP102は、ACKフレーム330を第8のSTAに送信し得る。これは、シングルユーザ(SU)送信機会(TXOP)の間にフレームが交換されるとき、好ましい方法であり得る。フレーム326から330は、シングルユーザ実装形態の一部として示されている。

図3Bは、いくつかの実装形態による、アクセスポイント(たとえば、図1のAP102)と複数の局(たとえば、STA104a〜104d)との間のマルチユーザ(MU)アップリンク通信をセットアップするためのフレーム交換の別の時間図350を示す。ダウンリンク方向に(たとえば、APからSTAに)送られるメッセージまたはフレームは、斜めのハッチパターンを有するように示されているが、アップリンク方向に(たとえば、STAからAPに)送られるメッセージまたはフレームは、パターンなしで示されている。図3Bは、AP102を含むワイヤレスLANの存在を通知するためにAP102によって周期的に送信され得るビーコンフレーム352を示す。AP102がチャネルリソースを2つ以上のSTAに最適にスケジュールするために、AP102は、ポーリングフレームを送ることによって、1つまたは複数のSTAからのアップリンクバッファ報告を請求し得る。そのようなフレームは、「要求フレーム304、314、326、354、364、400、500」として知られ得る。本出願は、アップリンクバッファ報告をAPに送り返すためにポーリングされたSTAによって利用され得る少なくとも4つの報告フレーム、すなわち、サービス品質(QoS)ヌルフレーム(600、図6参照)と、QoSデータフレーム(700、図7参照)と、PSポールフレーム(800、図8参照)と、HE制御フレーム(900、図9参照)とを企図する。そのようなフレームは、「報告フレーム306、308、310、322、328、600、700、800、900」として知られ得る。図3Bは、トリガフレーム354、364を使用したMUモードにおける請求の2つの例と、トリガフレーム376を使用したSUモードにおける請求の1つの例とを示す。

MUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第1の例では、AP102は、トリガフレーム354を送信し得、任意の関連するSTAによるトリガフレーム354の受信は、受信側STAに、STAからのアップリンクバッファ報告に対するAP102からの要求を示すことになる。トリガフレーム354は加えて、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を1つまたは複数の受信側STAに割り振るための情報を含み得る。トリガフレーム354は、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する場合もある。次いで、トリガフレーム354によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、それらのアップリンクバッファ報告を送信し得る。たとえば、トリガフレーム354が第1、第2および第3のSTA(たとえば、図1のSTA104a、104b、104c)の各々にアドレッシングされ、それらに対するリソース割振りを含んでいたと仮定すると、図示のように、割り振られたリソースにおいて、第1のSTAは、アップリンクバッファ報告を含むHE制御1フレーム356を送信し得、第2のSTAは、アップリンクバッファ報告を含むHE制御2フレーム358を送信し得、第3のSTAは、アップリンクバッファ報告を含むHE制御3フレーム360を送信し得る。アップリンクバッファ報告を含むHE制御フレーム356、358、360を正確に受信したことに応答して、AP102は、確認応答(ACK)フレーム362を第1、第2および第3のSTAに送信し得る。これは、マルチユーザ(MU)送信機会(TXOP)の間にフレームが交換されるとき、好ましい方法であり得る。いくつかの他の実装形態では、予定受信側STAは、ランダムな時間にアップリンクバッファ報告を含むフレームを送るように構成され得、トリガフレームは、ランダムアクセスを可能にするトリガフレーム(たとえば、TF-Rトリガフレーム)である。報告フレーム(たとえば、HE制御フレーム356、358、360)内のアップリンクバッファ報告を受信すると、AP102は、1つまたは複数の局の各々からの受信されたアップリンクバッファ報告に基づいてアップリンクデータ送信用に通信リソースを1つまたは複数の局(たとえば、局104a〜104c)に割り振るメッセージを送り得る。したがって、各局は、局からのアップリンクバッファ報告に少なくとも部分的に基づいてアップリンクデータ送信用に通信リソースの一部分を局に割り振るメッセージをアクセスポイント102から受信し得る。

MUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第2の例では、AP102は、トリガフレーム364を送信し得、任意の関連するSTAによるトリガフレーム364の受信は、STAからのアップリンクバッファ報告に対するAPからの要求を示すことになる。トリガフレーム354と同様に、トリガフレーム364は加えて、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を1つまたは複数の受信側STAに割り振るための情報、ならびにアップリンクバッファ報告のフォーマットがアップリンクバッファ内の待ち行列に入れられたデータの量またはアップリンクバッファ内の待ち行列に入れられたデータを送信するための要求される時間の量のいずれかであるという要求を含み得る。次いで、トリガフレーム364によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、それらのアップリンクバッファ報告を送信し得る。たとえば、トリガフレーム364が第5のSTA(図1に示されていない)にアドレッシングされ、そのSTAに対するリソース割振りを含んでいたと仮定すると、第5のSTAは、割り振られたリソースにおいて、アップリンクバッファ報告を含むHE制御5フレーム372を送信し得る。図3Bは加えて、トリガフレーム364の後に、それらのそれぞれのリソース割振りにおいて、AP102によって第3および第5のSTAにそれぞれ送信されたダウンリンクデータフレーム366および368を示す。図3Bは加えて、ダウンリンクデータフレーム366を受信したことに応答して第3のSTAによって送信されたACKおよびアップリンクデータフレーム370を示す。フレーム366、368および370は、アップリンクバッファ報告の請求および提供に直接関係しないが、MU通信方式における文脈および強調のために示されている。アップリンクバッファ報告を含むHE制御5フレーム372を正確に受信したことに応答して(ならびにACKおよびアップリンクデータフレーム370を正確に受信したことに応答して)、AP102は、ブロック確認応答(BA)フレーム374を第3および第5のSTAに送信し得る。フレーム354から374は、マルチユーザ実装形態の一部として示されている。

SUモードにおけるトリガフレームを介したアップリンクバッファ報告の請求に関係する第1の例では、AP102は、トリガフレーム376を送信し得、関連するSTAによるトリガフレーム376の受信は、STAからのアップリンクバッファ報告に関するAP102からの要求を示すことになる。そのようなSUモード動作では、受信側STAは、その送信パラメータの制御を有し得、このことは、ネットワークにおける送信電力不均衡の場合は特に、SUモードにおいて望ましい。トリガフレーム376は、それぞれのアップリンクバッファ報告を送信するためにリソース(たとえば、1つまたは複数の周波数帯域またはチャネルおよびそれらの周波数帯域またはチャネルに関連付けられた持続時間)を受信側STAに割り振る情報と、アップリンクバッファ報告のフォーマットがアップリンクバッファ内の待ち行列に入れられたデータの量またはアップリンクバッファ内の待ち行列に入れられたデータを送信するための要求される時間の量のいずれかであるという要求とを含み得る。次いで、トリガフレーム376によってアドレッシングされたSTAは、割り振られたリソース上で、要求されたフォーマットで、そのアップリンクバッファ報告を送信し得る。たとえば、トリガフレーム376が第6のSTA(図1に示されていない)にアドレッシングされ、そのSTAに対するリソース割振りを含んでいたと仮定すると、第6のSTAは、割り振られたリソースにおいて、アップリンクバッファ報告を含むQoSヌルまたはQoSデータフレーム378を送信し得る。アップリンクバッファ報告を含むHE制御フレーム376を正確に受信したことに応答して、AP102は、ACKフレーム370を第6のSTAに送信し得る。これは、シングルユーザ(SU)送信機会(TXOP)の間にフレームが交換されるとき、好ましい方法であり得る。フレーム376から380は、シングルユーザ実装形態の一部として示されている。

図4は、いくつかの実装形態による、アップリンクバッファステータスを報告するためのトリガフレーム400のフォーマットを示す。トリガフレーム400は、図3Aおよび図3Bに関して前に説明したトリガフレーム304、314、354、364、376に対応し得る。トリガフレーム400は、以下のフィールド、すなわち、フレーム制御(FC)フィールド404と、持続時間/識別情報(ID)フィールド406と、受信機アドレス(a1)フィールド408と、送信機アドレス(a2)フィールド410と、サービス品質(QoS)制御フィールド416と、高スループット(HT)制御フィールドの高効率変形態であり得る高効率(HE)制御フィールド418とを含むMACヘッダ402を含み得る。トリガフレーム400は加えて、フレーム本体フィールド462と、フレーム検査シーケンス(FCS)フィールド420とを含み得る。a1フィールド408およびa2フィールド410の各々は、48ビット(6オクテット)値であるデバイスのフルMACアドレスを含み得るか、または代替的に、これらのフィールドのうちのいずれかは、短いMACヘッダフォーマットに基づく関連識別情報(AID)を含み得る。

加えて、上記で説明したフィールドの各々は、1つまたは複数のサブフィールドまたはフィールドを含み得る。たとえば、フレーム制御フィールド404は、以下の複数のサブフィールド、すなわち、プロトコルバージョンサブフィールド422、タイプサブフィールド424、サブタイプサブフィールド426、to分散システム(DS)サブフィールド428、from DSサブフィールド430、モアフラグメントサブフィールド432、再試行サブフィールド434、電力管理サブフィールド436、モアデータサブフィールド438、保護サブフィールド440および順序サブフィールド442のうちの1つまたは複数を含み得る。いくつかの実装形態では、モアデータサブフィールド438内の1の値は、フレーム400が1つまたは複数のSTAからのアップリンクバッファ報告を要求するための要求フレームであることを示し得る。いくつかの実装形態では、トリガフレーム400は、たとえば、フレーム制御フィールド404のタイプフィールド424および/またはサブタイプフィールド426に示されている「制御」タイプを有する任意のフレームおよびHE制御フィールド418を有する任意のフレームを含み得る。

HE制御フィールド418は、2バイト(たとえば、16ビット)を含み得、制御IDサブフィールド470と、AC制約サブフィールド472と、要求されるスケーリング係数サブフィールド474と、予約済みサブフィールド476とを含み得る。AC制約サブフィールド472は、1ビットを含み得る。AC制約サブフィールド472内の0および1の値の一方は、すべてのアクセスクラスまたはカテゴリーのデータに対して有効であるアップリンクバッファ報告が要求されることを示し得るが、AC制約サブフィールド472内の0および1の値の他方は、たとえば、QoS制御フィールド416に示すような、特定のアクセスクラスまたはカテゴリーのデータ(トラフィック)に対して有効なアップリンクバッファ報告が生成側APによって要求されることを示し得る。要求されるスケーリング係数サブフィールド474は、バッファされたアップリンクデータの量またはバッファされたアップリンクデータを送信するための要求される時間の量を示すときにアップリンクバッファ報告が使用すべき要求されるスケーリング係数またはグラニュラリティを示すために利用される1ビットまたは2ビットを含み得る。たとえば、0、1、2、または3の値は、グラニュラリティ、すなわち、たとえば、バッファされたアップリンクデータの量が報告のために要求されるときの、それぞれ、単位当たり4バイト、16バイト、64バイトおよび256バイトのステップサイズを示し得る。同様に、0、1、2、または3の値は、グラニュラリティ、すなわち、たとえば、バッファされたアップリンクデータを送信するための要求される時間が報告のために要求されるときの、それぞれ、単位当たり4μs、8μs、16μs、および32μsのステップサイズを示し得る。いくつかの実装形態では、HEアグリゲート(A-)制御フィールドの一部として、2つ以上のHE制御フィールド418がフレーム400に含まれ得る。QoS制御フィールド416は、以下のサブフィールド、すなわち、トラフィック識別子(TID)サブフィールド450、サービス期間終了サブフィールド452、ACKポリシーサブフィールド454、予約済みフィールド456、および可変フィールド458のうちの1つまたは複数を含み得る。いくつかの実装形態では、予約済みフィールド456は、フレーム400がアグリゲート媒体アクセス制御サービスデータユニット(A-MSDU)を搬送するという指示を含み得る。QoS制御フィールド416は、長さが2バイト(16ビット)であり得、いくつかの実装形態では、上述のサブフィールドの間で、次のように、すなわち、それぞれ、4ビット、1ビット、2ビット、1ビットおよび8ビットに分割され得る。TIDサブフィールド450は4ビットを有し、そのフレーム(たとえば、MPDU)についてAPとSTAとの間で送信されるデータのトラフィック識別子、アクセスカテゴリーまたはアクセスクラスを示し得る。いくつかの実装形態では、TIDサブフィールド450内の値は、アップリンクバッファ報告がAP102によって請求されるトラフィック識別子、アクセスカテゴリーまたはクラスを示し得る。そのようなトラフィック識別子は、0から14の任意の値によって識別され得、そのようなアクセスカテゴリーまたはクラスは、バックグラウンドデータ、ベストエフォートデータ、ビデオデータおよびボイスデータのうちのいずれかであり得る。これらのトラフィック識別子、アクセスカテゴリーまたはクラスは、HE制御フィールド418内のAC制約サブフィールド472に関して前に説明したものに対応し得る。

いくつかの実装形態では、TIDフィールド450の最上位ビット(たとえば、第1のビット)は、QoS制御フィールド416のいくつかのフィールドがオーバーロードされていることをシグナリングするために使用され得る。一例として、1に設定されたTIDフィールド450の最上位ビット(たとえば、第1のビット)は、以下のフィールド、すなわち、TIDフィールド450の3つのLSB(たとえば、第2〜第4のビット)のうちの1つまたは複数、サービス期間終了フィールド452、ACKポリシーフィールド454および可変フィールド458のうちの1つまたは複数が、TIDフィールド450の最上位ビットが0に設定されるときとは異なる解釈を有する値を含むことを示す。いくつかの実装形態では、TIDフィールド450の3つのLSBは、バッファされたアップリンクデータの量またはバッファされたアップリンクデータを送信するための要求される時間の量を示すときにアップリンクバッファ報告が使用すべき要求されるグラニュラリティを示すスケーリング係数を含み得る。たとえば、TIDフィールド450の第1のビットが「0」である場合、第2〜第4のビット(B1〜B3)は、バッファ報告が要求されるトラフィックタイプのトラフィック識別子を含み得る。しかしながら、TIDフィールド450の第1のビットが「1」(たとえば、非ゼロ)である場合、TIDフィールド450の少なくとも第2および第3のビット(B1〜B2)は、要求されるスケーリング係数を含み得る。この場合、TIDフィールド450の第2および第3のビットにおける0の値(たとえば、「00」)は、結果として生じるバッファ報告において、アップリンクバッファ内のデータを送信するための要求される時間の量が要求されることと、結果として生じるバッファ報告において、単位当たり8μsの暗黙的なスケーリング係数が使用されるべきであることとを示す。これに反して、TIDフィールド450の第2および第3のビットにおける1から3の値は、結果として生じるバッファ報告において、アップリンクバッファ内のデータの量が要求されることを暗黙的に示す。TIDフィールド450の第2および第3のビットにおける1の値(たとえば、「01」)は、単位当たり8バイトのスケーリング係数またはグラニュラリティを示し、0から約32Kbyteの値範囲を与え得る。同様に、TIDフィールド450の第2および第3のビットにおける2の値(たとえば、「10」)は、単位当たり256バイトのスケーリング係数またはグラニュラリティを示し、0から約1Mbyteの値範囲を与え得る。TIDフィールド450の第2および第3のビットにおける3の値(たとえば、「11」)は、単位当たり4096バイトのスケーリング係数またはグラニュラリティを示し、0から約16Mbyteの値範囲を与え得る。スケーリング係数が存在しない場合、デフォルトのスケーリング係数が仮定され得る(たとえば、1)。同様に、QoS制御フィールド416の残りのフィールドは、可変フィールド458が、長さが8ビット(すなわち、B8からB15)から、たとえば、11ビット(すなわち、B4からB15)のより長い長さに拡張されるように解釈され得る。いくつかの実装形態では、たとえば、11ビットを有する修正済み可変フィールド458は、バッファ報告が要求側デバイスに送信され得る次のサービス期間の開始時間を示すために利用され得る。このようにして、バッファされたアップリンクデータを送信するための要求される時間の量(要求されるTXOP持続時間(TXOP Duration Requested))および/またはバッファされたアップリンクデータの量(待ち行列サイズ(Queue Size))のためのより広範囲の値をシグナリングすることが可能である。いくつかの実装形態では、ACKポリシーフィールド454がオーバーロードされているので、それがない場合、QoS制御フィールド416を含むフレーム400の予定受信機は、フレーム400の他の部分からまたは(たとえば、A-MPDUの一部としての)PPDUに含まれる他のフレームから得られ得る所定のACKポリシー値を使用し得る。QoS制御フィールド416は、HE制御フィールド418の外部にかつHE制御フィールド418に隣接して位置するものとして示されているが、いくつかの実装形態では、QoS制御フィールド416は、同じくまたは代替的に、HE制御フィールド418内に位置してもよい。また他の実装形態では、QoS制御フィールドは、フレーム400のPHYヘッダに位置してもよい(PHYヘッダは図4に示されていない)。

図3Aに関して前に説明したように、CTS-to-selfフレームは、シングルユーザモードでSTAからのアップリンクバッファ報告を請求または要求するためにAPによって利用され得る。図5は、いくつかの実装形態による、局からのアップリンクバッファステータス報告を要求するための修正済み送信可(CTS)-to-selfフレーム500のフォーマットを示す。CTS-to-selfフレーム500は、図4に関して前に説明したように、少なくとも6つのフィールド、すなわち、フレーム制御(FC)フィールド404と、持続時間フィールド406と、受信機アドレス(RA)フィールド408(受信機アドレス(a1)とも呼ばれる)と、送信機アドレス(TA)フィールド410と、フレーム検査シーケンス(FCS)フィールド420とを含み得る。

フレーム制御フィールド404は、図4に関して前に説明したように、複数のサブフィールド、すなわち、プロトコルバージョンサブフィールド422、タイプサブフィールド424、サブタイプサブフィールド426、to分散システム(DS)サブフィールド428、from DSサブフィールド430、モアフラグメントサブフィールド432、再試行サブフィールド434、電力管理サブフィールド436、モアデータサブフィールド438、保護サブフィールド440および順序サブフィールド442のうちの1つまたは複数を含み得る。

持続時間フィールド406は、図3Aに関して前に説明したように、受信側STAがアップリンクバッファ報告を含む後続フレームを送信するための持続時間を示し得る。RAフィールド408は、CTS-to-selfフレーム400に対する予定受信側STAの識別情報またはアドレスを含み得るが、このことは、RAフィールド408がCTS-to-selfフレームを生成するデバイスの識別情報またはアドレスを含まなければならない、CTS-to-selfフレームの従来の利用に反している。さらに、従来は、CTSフレームは、送信要求(RTS:request to send)フレームを受信したことに応答して生成および送信される。本出願では、少なくともCTSフレーム400が必ずしもそのようなRTSフレームの受信に応答して生成および送信されるとは限らないという点で、柔軟性の増大が企図される。TAフィールド410は、生成側デバイス(たとえば、AP)の識別情報またはアドレスを含み得る。HE制御フィールド418は、少なくとも、図4のトリガフレーム400に関して前に説明した機能を有する4つのサブフィールドの各々を含み得る。最後に、FCSフィールド420は、誤り検査の目的で受信側デバイスによって利用される情報を含み得る。CTS-to-selfフレーム500の実装形態について、特定のフォーマットを有するものとして説明したが、本出願はそのように限定されず、CTS-to-selfフレーム500は、任意の他の新しいフレームフォーマットまたは構成を有し得る。

図6〜図8は、要求された報告を送信するために使用され得る異なるタイプのフレームのフォーマットについて説明する。図6は、いくつかの実装形態による、アップリンクバッファステータスを報告するためのサービス品質(QoS)ヌルフレーム600のフォーマットを示す。QoSヌルフレーム600は、図3Aおよび図3Bに関して前に説明したQoSヌルフレーム322および378に対応し得る。QoSヌルフレーム600は、少なくとも以下のフィールド(そのうちのいくつかについては図4のトリガフレーム400に関して前に説明した)、すなわち、フレーム制御(FC)フィールド404と、持続時間/識別情報(ID)フィールド406と、受信機アドレス(a1)フィールド408と、送信機アドレス(a2)フィールド410と、宛先アドレス(a3)フィールド412と、シーケンス制御フィールド460と、第4のアドレス(a4)フィールド414と、サービス品質(QoS)制御フィールド416と、高効率(HE)制御フィールド418とを含むMACヘッダ402を含み得る。QoSヌルフレーム600は加えて、フレーム検査シーケンス(FCS)フィールド420を含み得る。図3Aおよび図3Bに関して説明したフレーム交換を参照すると、トリガフレーム(たとえば、トリガフレーム304、314)またはCTS-to-selfフレーム(たとえば、CTS-to-selfフレーム326)を受信したことに応答して、受信側STAは、a1アドレスフィールド408またはa3アドレスフィールド412のいずれかにAP102のMACアドレスを含み、a2フィールド410にそれ自体のMACアドレスを含む、QoSヌルフレーム600を送信し得る。これは、AP102を受信側として確立し、生成側STAをQoSヌルフレーム600の送信元として確立する。

加えて、上記で説明したフィールドの各々は、1つまたは複数のサブフィールドまたはフィールドを含み得る。たとえば、図6に示すように、フレーム制御フィールド404は、図4に関して前に説明したトリガフレーム400のフレーム制御フィールド404に関して前に説明したサブフィールド、すなわち、プロトコルバージョンサブフィールド422、タイプサブフィールド424、サブタイプサブフィールド426、to分散システム(DS)サブフィールド428、from DSサブフィールド430、モアフラグメントサブフィールド432、再試行サブフィールド434、電力管理サブフィールド436、モアデータサブフィールド438、保護サブフィールド440および順序サブフィールド442のうちの1つまたは複数を含み得る。いくつかの実装形態では、モアデータサブフィールド438は、生成側STAによって送信するためのアップリンクバッファデータの存在をシグナリングするために利用され得る。したがって、APは、フレーム制御フィールド404のモアデータサブフィールド438に示されているアップリンクデータの存在を判定し得る。しかしながら、モアデータサブフィールド438は長さが1ビットしかないので、このサブフィールドは、バッファされたデータの量またはそのデータを送信するための要求される時間の長さではなく、存在のみを示し得る。

QoS制御フィールド416は、図4のトリガフレーム400に関して前に説明したサブフィールド、すなわち、トラフィックインジケータ(TID)サブフィールド450、サービス期間終了サブフィールド452、ACKポリシーサブフィールド454、予約済みフィールド456、および可変フィールド458のうちの1つまたは複数を含み得る。可変サブフィールド458は、生成側STAにおいてアップリンク送信のために現在バッファされている、トラフィックインジケータサブフィールド450に示されているアクセスカテゴリーまたはアクセスクラスのアップリンクデータの量を示すために利用され得る8ビットを有する。代替的に、可変サブフィールド458は、トラフィックインジケータサブフィールド450に示されているアクセスクラスまたはカテゴリーを有する、現在バッファされているアップリンクデータを送信するために生成側STAによって要求される時間の量を示し得る。したがって、QoSヌルフレーム600を受信するAP102は、サービス品質制御フィールド416に示されている、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量を判定し得る。いくつかの実装形態では、可変サブフィールド458の8ビットがバッファされたデータの量を示すか、バッファされたデータを送信するための要求される時間の量を示すかは、前に受信されたトリガフレーム(たとえば、図4により詳細に示されている、図3Aおよび図3Bのトリガフレーム304、314、354、364、376)またはCTS-to-selfフレーム(たとえば、図5により詳細に示されている、図3AのCTS-to-selfフレーム326)に含まれる指示に基づいて判定され得る。一般に、APがUL送信パラメータを制御している場合、データの量が可変サブフィールド458に示され、生成側STAがそれ自体のUL送信パラメータを制御している場合、バッファされたデータを送信するための要求される時間の量が可変サブフィールド458に示される。したがって、そのような実装形態では、QoSヌルフレーム600を受信するAP102は、アップリンク送信パラメータがアクセスポイントによって制御されるか、QoSヌルフレーム600(たとえば、報告フレーム)を生成する局によって制御されるかに基づいて、アップリンクバッファ報告がアップリンクバッファ内のデータの量を示すか、アップリンクバッファ内のデータを送信するための要求される時間の量を示すかを判定し得る。

可変サブフィールド458は8ビットを有するので、256個の潜在的な値(たとえば、2⁸=256)のうちのいずれか1つをとり得る。したがって、可変サブフィールド458がトラフィックインジケータサブフィールド450に示されているトラフィックカテゴリーまたはトラフィックストリームを有するアップリンクバッファデータの量の指示を含む場合、トラフィックの量は、256個の潜在的な値における各増分が256オクテット(たとえば、各オクテットは1バイトまたは8ビットである)の待ち行列に入れられたデータを示すように示され得る。したがって、0から253の値は、256オクテットのステップで待ち行列に入れられたアップリンクデータの0オクテットから64,768オクテット(たとえば、253×256=64,768)までのデータの量を示すことになり、254の値は、64,768オクテット以上の待ち行列に入れられたアップリンクデータを示すことになり、255の値は、不特定のまたは未知のデータの量を示すことになる。代替的に、可変サブフィールド458がトラフィックインジケータサブフィールド450に示されているトラフィックカテゴリーまたはトラフィックストリームを有するアップリンクバッファデータを送信するための要求される時間の指示を含む場合、要求される時間は、256個の潜在的な値における各増分が32μsの要求される送信時間を示す(最大で8,160μsの最大送信時間(たとえば、32μs×255=8,160μs))ように示され得る。

しかしながら、いくつかの802.11ax通信実装形態などのいくつかの実装形態では、待ち行列に入れられたデータについて、256オクテットの待ち行列に入れられたデータまたは32μsの要求される送信時間のいずれかの増分よりも高い分解能またはそれよりも高いグラニュラリティを有するアップリンクバッファステータスを示すことができることが望ましい場合がある。これは、トラフィックの量を示す実装形態では、送信レートが1Mbpsを下回る場合に、要求される送信時間の実装形態では、送信レートが1Mbpsよりもはるかに大きい場合に、特に当てはまる場合がある。分解能(たとえば、グラニュラリティ)の増加は、QoS制御フィールド416において搬送される情報をさらに最適化することによって達成され得る。たとえば、上記で説明した待ち行列に入れられたデータの量の増分(たとえば、単位当たり256オクテット)または要求される送信時間の増分(たとえば、単位当たり32μs)は、送信ビットレートに基づいてまたはQoS制御フィールド416にさらに含まれる指示に基づいてのいずれかで低減され得る。たとえば、いくつかの実装形態では、QoSヌルフレーム600が(たとえば)6Mbps以下で送信されるとき、待ち行列に入れられたデータの量の増分は、単位当たり256オクテットではなく、単位当たり16オクテットであり得る。同様に、QoSヌルフレーム600が(たとえば)54Mbps以上で送信される場合、待ち行列に入れられたデータに対する要求される送信時間の増分は、32μsではなく、4μsであり得る。したがって、送信ビットレートに基づくとき、待ち行列に入れられたデータの増分と要求される送信時間の増分との間に反比例関係がある。したがって、そのような実装形態では、AP102は、QoSヌルフレーム600(たとえば、報告フレーム)の送信レートに基づいて、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量を示す、グラニュラリティを判定し得る。いくつかの他の実装形態では、どちらの単位当たりの増分が利用されるべきかを判定するために、QoSヌルフレーム600に含まれる任意の他の情報が利用され得る。また他の実装形態では、QoS制御フィールド416は長さが2バイト(16ビット)であるので、1ビット(たとえば、ビット7)を有する予約済みサブフィールド456は、2つの上記の増分のうちのどちらが利用されるべきかをシグナリングするために利用され得る。たとえば、QoS制御フィールド416の予約済みサブフィールド456内のビット7が1の値に設定される場合、増分の一方(たとえば、待ち行列に入れられたデータの量の場合は単位当たり256オクテットまたは16オクテットのうちの1つ、および送信のための要求される時間の場合は32μsまたは4μsのうちの1つ)が利用され得るが、0の設定値は、他方の増分の使用をシグナリングし得る。したがって、そのような実装形態では、AP102は、アップリンクバッファ報告が、QoSヌルフレーム600(たとえば、報告フレーム)のサービス品質制御フィールド416に示されている、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量を示す、グラニュラリティを判定し得る。さらに、いくつかの他の実装形態では、1ビット(たとえば、ビット7)を有する予約済みサブフィールド456は、待ち行列に入れられたデータの量または要求される送信時間がすべてのトラフィッククラス、アクセスクラスまたはカテゴリーに適用されることをシグナリングするために利用され得る。

いくつかの他の実装形態では、HE制御フィールド418は、QoS制御フィールド416に関して前に説明したように、アップリンクバッファ報告の情報を示すために利用され得る。たとえば、HE制御フィールド418は、少なくとも以下の4つのサブフィールド、すなわち、AC制約サブフィールド620と、スケーリング係数サブフィールド622と、待ち行列サイズまたは要求されるTXOP持続時間フィールド624と、予約済みフィールド626とを含み得る。AC制約サブフィールド620は、1ビットの長さを有し得、後続のアップリンクバッファ報告が特定のトラフィックカテゴリーまたはクラスの値を示すか、すべてのトラフィックカテゴリーまたはクラスの値を示すかを示し得る。スケーリング係数サブフィールド622は、図4の要求されるスケーリング係数サブフィールド474について前に説明したように、2ビットの長さを有し得、バッファされたアップリンクデータの量またはバッファされたアップリンクデータを送信するための要求される時間のいずれかの後続の指示のグラニュラリティまたはステップサイズを示し得る。待ち行列サイズまたは要求されるTXOP持続時間フィールド624は、バッファされたアップリンクデータの量またはそのバッファされたアップリンクデータを送信するための要求される時間のうちのどちらがフレーム600に含まれるかを示すための第1のビットを含み得る。待ち行列サイズまたは要求されるTXOP持続時間フィールド624の残りのビットは、スケーリング係数サブフィールド622に示されているグラニュラリティまたはステップサイズを使用して、第1のビットの値に基づいて、バッファされたアップリンクデータの量またはそのバッファされたアップリンクデータを送信するための要求される時間を示す。

図7は、いくつかの実装形態による、アップリンクバッファステータスを報告するためのサービス品質(QoS)データフレーム700のフォーマットを示す。QoSデータフレーム700は、図6のQoSヌルフレーム600について前に説明したフィールドおよびサブフィールドの各々を含み得、加えて、任意のタイプのデータペイロードを保持するように構成され得るフレーム本体フィールド462を含み得る。アップリンクバッファ内の待ち行列に入れられたデータの量または送信時間の要求される量のいずれかの指示は、図6のQoSヌルフレーム600について前に説明した任意の方法で、QoSデータフレーム700に示され得る。QoSデータフレーム700またはQoSヌルフレーム600を利用することは、TIDごとのバッファ報告の報告を可能にする。しかしながら、QoSデータフレーム700またはQoSヌルフレーム600に関して説明したように、QoS制御フィールド416の使用に対していくつかの制限がある。Ack、BlockAckなどのより短いフレームは従来、QoS制御フィールドを含まないので、QoS制御フィールドを利用することは従来、QoSヌルフレームまたはQoSデータフレームに限定される場合がある。図9に関して説明するように、この概念はHE制御フレームに拡張され得る。さらに、QoSヌルフレームおよびQoSデータフレームは、複数のQoSフレームがTIDごとに送信されない限り、TIDごとにバッファステータスを報告することに限定される場合がある。加えて、報告内で送られる指示の範囲またはグラニュラリティは、図6および図7に示すように、可変フィールド458の8ビットに限定される。図9のHE制御フレームの使用は、このビット数を増加させることができる。

図8は、いくつかの実装形態による、アップリンクバッファステータスを報告するための省電力(PS)ポールフレーム800のフォーマットを示す。PSポールフレーム800は、図3AのPSポールフレーム328に対応し得る。PSポールフレーム800は、図7に関して前に説明したように、少なくとも、フレーム制御フィールド404と、持続時間フィールド406と、アドレス1フィールド408と、アドレス2フィールド410と、FCSフィールド420とを含み得る。PSポールフレームはトラフィック指示に関係しない、たとえば、PSポールフレームは任意の特定のトラフィッククラス、アクセスクラスまたはカテゴリーに固有のものではないので、PSポールフレーム800内のシグナリングは累積的であり、たとえば、すべてのデータアクセスクラスまたはカテゴリーに有効である。持続時間フィールド406は、2バイト(たとえば、16ビット)の長さを有し得、複数のサブフィールド、すなわち、スケーリング係数サブフィールド820と、待ち行列サイズまたは要求されるTXOP指示サブフィールド822と、待ち行列サイズまたは要求されるTXOP持続時間フィールド824と、予約済みフィールド826とを含み得る。持続時間フィールド406の16ビットがビット0からビット15として連続的に標示されるPSポールフレーム800では、ビット14およびビット15が1の値を有するとき、ビット0からビット13は予約済みビットと見なされる。したがって、生成側STAは、これらの14ビット(たとえば、ビット0からビット13)において、待ち行列に入れられたデータの量または要求される送信時間を示し得る。いくつかの実装形態では、これらの14ビットのうちの1つ(たとえば、ビット0からビット13のうちのビット0またはビット13)は、待ち行列に入れられたデータの量または要求される送信時間のうちのどちらがビット0からビット13の残りのビット(たとえば、待ち行列サイズまたは要求されるTXOP指示サブフィールド822の1ビット)に示されるかを選択的に示すために利用され得る。たとえば、0は、待ち行列に入れられたデータの量または要求される送信時間の一方が待ち行列サイズまたは要求されるTXOP持続時間フィールド824に示されることを示し得るが、1は、待ち行列に入れられたデータの量または要求される送信時間の他方が待ち行列サイズまたは要求されるTXOP持続時間フィールド824に示されることを示し得る。スケーリング係数サブフィールド820は、図6のスケーリング係数サブフィールド622について前に説明したように、待ち行列サイズまたは要求されるTXOP持続時間フィールド824に示されている値のグラニュラリティまたはステップサイズを示し得る。したがって、PSポールフレーム800(たとえば、報告フレーム)を受信するAP102は、持続時間フィールド406に示されている、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量を判定し得る。AP102は加えて、持続時間フィールドの少なくとも1ビット(たとえば、持続時間フィールド406のビット0またはビット13)によって与えられる指示に基づいて、アップリンクバッファ報告がアップリンクバッファ内のデータの量を示すか、アップリンクバッファ内のデータを送信するための要求される時間の量を示すかを判定し得る。いくつかの実装形態では、これらの13ビットの各増分の単位は所定であってもよく、図6のQoSヌルフレーム600の可変サブフィールド458について前に説明したものと同じであっても、それとは異なっていてもよい。いくつかの他の実装形態では、これらの13ビットの各増分の単位は、予約済みサブフィールド456、可変サブフィールド458に関して前に説明した方法のうちのいずれかで、または図6のQoSヌルフレーム600の送信データレートに暗黙的に基づいてシグナリングされ得る。持続時間フィールド406の上記の追加の機能について、図8のPSポールフレーム800に関して説明したが、この機能は、図6および図7に関して説明したフレームに等しく適用され得る。

図9は、いくつかの実装形態による、アップリンクバッファステータスを報告するための高効率(HE)制御フレーム900のフォーマットを示す。HE制御フレーム900は、図3Aおよび図3Bに関して前に説明したHE制御フレーム356、358、360、372に対応し得る。HE制御フレーム900は極めて短いフレームであり得るので、要求されるバッファ報告を単一のフレーム内のすべてのTIDに、またはTIDごとに提供するために、最小信号オーバーヘッドが要求される。HE制御フレーム900は、図4のトリガフレーム400に関して前に説明した各フィールドを含み得る。図4のトリガフレーム400について前に説明したように、HE制御フレーム900は、たとえば、フレーム制御フィールド404のタイプフィールド424および/またはサブタイプフィールド426に示されている「制御」タイプを有する任意のフレームおよびHE制御フィールド418を有する任意のフレームを含み得る。従来の制御フレームはQoS制御フィールドを含まないことに留意されたい。

QoS制御フィールド416は、以下のサブフィールド、すなわち、トラフィック識別子(TID)サブフィールド450、サービス期間終了サブフィールド452、ACKポリシーサブフィールド454、予約済みフィールド456、および可変フィールド458のうちの1つまたは複数を含み得る。いくつかの実装形態では、予約済みフィールド456は、フレーム900がアグリゲート媒体アクセス制御サービスデータユニット(A-MSDU)を搬送するという指示を含み得る。QoS制御フィールド416は、長さが2バイト(16ビット)であり得、いくつかの実装形態では、上述のサブフィールドの間で、次のように、すなわち、それぞれ、4ビット、1ビット、2ビット、1ビットおよび8ビットに分割され得る。TIDサブフィールド450は4ビットを有し、要求フレームが前にバッファ報告を要求したトラフィック識別子、アクセスカテゴリーまたはアクセスクラスを示し得る。いくつかの実装形態では、TIDサブフィールド450内の値は、含まれるアップリンクバッファ報告が属するトラフィック識別子、アクセスカテゴリーまたはクラスを示し得る。そのようなトラフィック識別子は、0から7の任意の値によって識別され得、そのようなアクセスカテゴリーまたはクラスは、バックグラウンドデータ、ベストエフォートデータ、ビデオデータおよびボイスデータのうちのいずれかであり得る。

いくつかの実装形態では、TIDフィールド450の最上位ビット(たとえば、第1のビット)は、QoS制御フィールド416のいくつかのフィールドがオーバーロードされていることをシグナリングするために使用され得る。一例として、1に設定されたTIDフィールド450の最上位ビット(たとえば、第1のビット)は、以下のフィールド、すなわち、TIDフィールド450の3つのLSB(たとえば、第2〜第4のビット)のうちの1つまたは複数、サービス期間終了フィールド452、ACKポリシーフィールド454および可変フィールド458のうちの1つまたは複数が、TIDフィールド450の最上位ビットが0に設定されるときとは異なる解釈を有する値を含むことを示す。いくつかの実装形態では、TIDフィールド450の3つのLSBは、バッファされたアップリンクデータの量またはバッファされたアップリンクデータを送信するための要求される時間の量を示すときにアップリンクバッファ報告が使用すべき要求されるグラニュラリティを示すスケーリング係数を含み得る。たとえば、TIDフィールド450の第1のビットが「0」である場合、第2〜第4のビット(B1〜B3)は、バッファ報告が要求され、含まれるバッファ報告が属するトラフィックタイプのトラフィック識別子を含み得る。しかしながら、TIDフィールド450の第1のビットが「1」(たとえば、非ゼロ)である場合、TIDフィールド450の少なくとも第2および第3のビット(B1〜B2)は、要求されるスケーリング係数(たとえば、含まれるバッファ報告において使用されるスケーリング係数)を含み得る。この場合、TIDフィールド450の第2および第3のビットにおける0の値(たとえば、「00」)は、アップリンクバッファ内のデータを送信するための要求される時間の量がバッファ報告に含まれることと、結果として生じるバッファ報告において、単位当たり8μsの暗黙的なスケーリング係数が使用されることとを示す。これに反して、TIDフィールド450の第2および第3のビットにおける1から3の値は、アップリンクバッファ内のデータの量がバッファ報告に含まれることを暗黙的に示す。TIDフィールド450の第2および第3のビットにおける1の値(たとえば、「01」)は、単位当たり8バイトのスケーリング係数またはグラニュラリティを示し、0から約32Kbyteの値範囲を与え得る。同様に、TIDフィールド450の第2および第3のビットにおける2の値(たとえば、「10」)は、単位当たり256バイトのスケーリング係数またはグラニュラリティを示し、0から約1Mbyteの値範囲を与え得る。TIDフィールド450の第2および第3のビットにおける3の値(たとえば、「11」)は、単位当たり4096バイトのスケーリング係数またはグラニュラリティを示し、0から約16Mbyteの値範囲を与え得る。スケーリング係数が存在しない場合、デフォルトのスケーリング係数が仮定され得る(たとえば、1)。同様に、QoS制御フィールド416の残りのフィールドは、可変フィールド458が、長さが8ビット(すなわち、B8からB15)から、たとえば、11ビット(すなわち、B4からB15)のより長い長さに拡張されるように解釈され得る。たとえば、11ビットを有する修正済み可変フィールド458は、TIDフィールド450に示されているフォーマットで、バッファされたアップリンクデータを送信するための要求される時間の量またはバッファされたアップリンクデータの量のいずれかの指示を含み得る。このようにして、バッファされたアップリンクデータを送信するための要求される時間の量(要求されるTXOP持続時間(TXOP Duration Requested))および/またはバッファされたアップリンクデータの量(待ち行列サイズ(Queue Size))のためのより広範囲の値をシグナリングすることが可能である。いくつかの実装形態では、ACKポリシーフィールド454がオーバーロードされているので、それがない場合、QoS制御フィールド416を含むフレーム900の予定受信機は、フレーム900の他の部分からまたは(たとえば、A-MPDUの一部としての)PPDUに含まれる他のフレームから得られ得る所定のACKポリシー値を使用し得る。QoS制御フィールド416は、HE制御フィールド418の外部にかつHE制御フィールド418に隣接して位置するものとして示されているが、いくつかの実装形態では、QoS制御フィールド416は、同じくまたは代替的に、HE制御フィールド418内に位置してもよい。また他の実装形態では、QoS制御フィールドは、フレーム900のPHYヘッダに位置してもよい(PHYヘッダは図9に示されていない)。

図10は、いくつかの実装形態による、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法の一態様のフローチャート1000である。図10によって示される方法は、図3Aに関して前に説明したように、アクセスポイント(たとえば、図2のワイヤレスデバイス202としてより詳細に示され得るような、図1のAP102)によって実行される方法に対応し得る。したがって、フローチャート1000内のステップのうちの1つまたは複数は、図2に関して前に説明したMU-ULモジュール224(たとえば、プロセッサ204およびメモリ206の一方または両方)ならびに/あるいは送信機210および/または受信機212によって、またはそれらに関して実行され得る。しかしながら、当業者は、他の構成要素が本明細書で説明するステップのうちの1つまたは複数を実装するために使用され得ることを諒解されよう。ブロックについて、一定の順序で行われるものとして説明する場合があるが、ブロックを並べ替えることができ、ブロックを省略することができ、および/またはさらなるブロックを追加することができる。

フローチャート1000は、1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成することであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、生成することを含み得る、ブロック1002で始まり得る。たとえば、(アクセスポイントとして働く)図2のワイヤレスデバイス202は、図3Aおよび図3Bに関して前に説明したように、また、図4〜図5のうちのいずれかに関してより詳細に説明したように、トリガフレーム304、314、354、364、376またはCTS-to-selfフレーム326(たとえば、要求フレーム)を生成し得る。この要求フレームは、図3〜図5に関して前に説明したように、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する。次いで、フローチャート1000は、ブロック1004に進み得る。

ブロック1004は、要求フレームを1つまたは複数の局の各々に送信することを含み得る。たとえば、ワイヤレスデバイス202(図2)の送信機210は、図3Aおよび図3Bに関して前に説明したように、トリガフレーム304、314、354、364、376またはCTS-to-selfフレーム326(たとえば、要求フレーム)を送信するように構成され得る。次いで、フローチャート1000は、ブロック1006に進み得る。

ブロック1006は、1つまたは複数の局の各々から報告フレーム内のアップリンクバッファ報告を受信することを含み得る。たとえば、ワイヤレスデバイス202(図2)の受信機212は、図6〜図9のうちのいずれかに関してより詳細に説明したように、PSポールフレーム306、308、310、328、QoSヌルフレーム322、378、またはHE制御フレーム356、358、360、372(たとえば、アップリンクバッファ報告を含む報告フレーム)のうちのいずれかを受信するように構成され得る。

図11は、いくつかの実装形態による、アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための別の方法の一態様のフローチャート1100である。図11によって示される方法は、図3Aおよび図3Bに関して前に説明したように、局(たとえば、図2のワイヤレスデバイス202としてより詳細に示され得るような、図1のSTA104a〜104dのうちのいずれか)によって実行される方法に対応し得る。したがって、フローチャート1100内のステップのうちの1つまたは複数は、図2に関して前に説明したMU-ULモジュール224(たとえば、プロセッサ204およびメモリ206の一方または両方)および/または送信機210もしくは受信機212によって、またはそれらに関して実行され得る。しかしながら、当業者は、他の構成要素が本明細書で説明するステップのうちの1つまたは複数を実装するために使用され得ることを諒解されよう。ブロックについて、一定の順序で行われるものとして説明する場合があるが、ブロックを並べ替えることができ、ブロックを省略することができ、および/またはさらなるブロックを追加することができる。

フローチャート1100は、局によって、アップリンクバッファ報告を要求する要求フレームを受信することであって、要求フレームが、アップリンクバッファ報告がアップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、受信することを含み得る、ブロック1002で始まり得る。たとえば、ワイヤレスデバイス202(図2)の受信機212は、図3Aおよび図3Bに関して前に説明したように、トリガフレーム304、314、354、364、376および/またはCTS-to-selfフレーム326(たとえば、要求フレーム)のうちのいずれかを受信するように構成され得る。次いで、フローチャート1100は、ブロック1104に進み得る。

ブロック1104は、アップリンクバッファ内のデータの量またはアップリンクバッファ内のデータを送信するための要求される時間の量のいずれかを選択的に示す要求されたアップリンクバッファ報告を含む報告フレームを生成することを含み得る。たとえば、ワイヤレスデバイス202(図2)のMU-ULモジュール224のプロセッサ204は、報告フレーム(たとえば、図3Aおよび図3Bに関して前に説明し、図6〜図9のうちのいずれかに関してより詳細に説明した、PSポールフレーム306、308、310、328、QoSヌルフレーム322、378、またはHE制御フレーム356、358、360、372のうちのいずれか)を生成するように構成され得る。次いで、フローチャート1100は、ブロック1106に進み得る。

ブロック1106は、報告フレームをアクセスポイントに送信することを含み得る。たとえば、ワイヤレスデバイス202(図2)の送信機210は、図3Aおよび図3Bに関して前に説明したように、PSポールフレーム306、308、310、328、QoSヌルフレーム322、378、またはHE制御フレーム356、358、360、372(たとえば、報告フレーム)のうちのいずれかをAP102に送信するように構成され得る。

当業者は、情報および信号が、様々な異なる技術および技法のうちのいずれかを使用して表され得ることを理解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。

本開示で説明する実装形態に対する様々な修正は、当業者に容易に明らかになり得、本明細書で定義する一般原理は、本開示の趣旨または範囲から逸脱することなく、他の実装形態に適用され得る。したがって、本開示は、本明細書で示す実装形態に限定されるものではなく、本明細書で開示する特許請求の範囲、原理および新規の特徴と一致する最も広い範囲を与えられるべきである。「例示的な」という単語は、本明細書では、「例、事例、または例示の働きをすること」を意味するように排他的に使用される。「例示的な」として本明細書で説明する任意の実装形態は、必ずしも他の実装形態よりも好ましいか、または有利であると解釈されるべきではない。

別個の実装形態の文脈において本明細書で説明するいくつかの特徴は、単一の実装形態において組み合わせて実装されることもある。逆に、単一の実装形態の文脈において説明する様々な特徴は、複数の実装形態において別々に、または任意の適切な部分組合せにおいて実装されることもある。さらに、特徴は特定の組合せで機能すると上記で説明され、最初にそのように特許請求されることさえもあるが、特許請求される組合せからの1つまたは複数の特徴は、場合によっては、その組合せから削除されることがあり、特許請求される組合せは、部分組合せまたは部分組合せの変形形態を対象とすることがある。

上記で説明した方法の様々な動作は、様々なハードウェア構成要素および/もしくはソフトウェア構成要素、回路、ならびに/またはモジュールなどの、動作を実行することが可能な任意の適切な手段によって実行され得る。一般に、図に示す任意の動作は、動作を実行することが可能な対応する機能手段によって実行され得る。

本開示に関して説明する様々な例示的な論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス(PLD)、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサは、マイクロプロセッサであり得るが、代替として、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラまたは状態機械であり得る。プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装される場合もある。

1つまたは複数の態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信されてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体と、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)およびBlu-ray(登録商標)ディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。したがって、いくつかの態様では、コンピュータ可読媒体は、非一時的コンピュータ可読媒体(たとえば、有形媒体)を備え得る。加えて、いくつかの態様では、コンピュータ可読媒体は、一時的コンピュータ可読媒体(たとえば、信号)を備え得る。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。

本明細書で開示する方法は、説明する方法を実現するための1つまたは複数のステップまたはアクションを備える。方法ステップおよび/または方法アクションは、特許請求の範囲から逸脱することなく互いに入れ替えられてもよい。言い換えれば、ステップまたはアクションの特定の順序が指定されない限り、特定のステップおよび/またはアクションの順序および/または使用は、特許請求の範囲から逸脱することなく修正されてもよい。

さらに、本明細書で説明する方法および技法を実行するためのモジュールおよび/または他の適切な手段は、適用可能な場合、ユーザ端末および/または基地局によってダウンロードおよび/または別の方法で取得され得ることを諒解されたい。たとえば、そのようなデバイスは、本明細書で説明する方法を実行するための手段の転送を容易にするためにサーバに結合され得る。代替的に、本明細書で説明する様々な方法は、ユーザ端末および/または基地局が記憶手段(たとえば、RAM、ROM、コンパクトディスク(CD)またはフロッピーディスクなどの物理的記憶媒体など)をデバイスに結合または提供すると様々な方法を取得することができるように、記憶手段を介して提供され得る。さらに、本明細書で説明する方法および技法をデバイスに提供するための任意の他の適切な技法が利用され得る。

上記は本開示の態様を対象としているが、本開示の他の態様およびさらなる態様は、本開示の基本的な範囲から逸脱することなく考案され得、本開示の範囲は、以下の特許請求の範囲によって決定される。

100 マルチユーザワイヤレス通信システム、システム、ワイヤレス通信システム
102 アクセスポイント、AP
104a〜104c 局
104a〜104d ユーザ端末、STA
202 ワイヤレスデバイス
204 プロセッサ
206 メモリ
208 ハウジング
210 送信機
212 受信機
214 トランシーバ
216 トランシーバアンテナ
218 信号検出器
220 デジタル信号プロセッサ(DSP)
222 バスシステム
224 マルチユーザ(MU)アップリンク(UL)モジュール、MU-ULモジュール
300 時間図
302 ビーコンフレーム
304 トリガフレーム、要求フレーム
306 報告フレーム、PSポールフレーム、PSポール1フレーム
308 報告フレーム、PSポールフレーム、PSポール2フレーム
310 報告フレーム、PSポールフレーム、PSポール3フレーム
312 確認応答(ACK)フレーム
314 要求フレーム、トリガフレーム
316 ダウンリンクデータフレーム、フレーム
318 ダウンリンクデータフレーム、フレーム
320 ACKおよびアップリンクデータフレーム、フレーム
322 報告フレーム、QoSヌルフレーム
324 ブロック確認応答(BA)フレーム、フレーム
326 要求フレーム、CTS-to-selfフレーム、フレーム
328 報告フレーム、PSポールフレーム
330 ACKフレーム、フレーム
350 時間図
352 ビーコンフレーム
354 要求フレーム、トリガフレーム、フレーム
356 HE制御フレーム、HE制御1フレーム
358 HE制御フレーム、HE制御2フレーム
360 HE制御フレーム、HE制御3フレーム
362 確認応答(ACK)フレーム
364 要求フレーム、トリガフレーム
366 ダウンリンクデータフレーム、フレーム
368 ダウンリンクデータフレーム、フレーム
370 ACKおよびアップリンクデータフレーム、フレーム
372 HE制御フレーム、HE制御5フレーム
374 ブロック確認応答(BA)フレーム、フレーム
376 トリガフレーム、HE制御フレーム、フレーム
378 QoSヌルまたはQoSデータフレーム、QoSヌルフレーム
380 フレーム
400 要求フレーム、トリガフレーム、フレーム、CTS-to-selfフレーム、CTSフレーム
402 MACヘッダ
404 フレーム制御(FC)フィールド、フレーム制御フィールド
406 持続時間/識別情報(ID)フィールド、持続時間フィールド
408 受信機アドレス(a1)フィールド、a1フィールド、受信機アドレス(RA)フィールド、RAフィールド、a1アドレスフィールド、アドレス1フィールド
410 送信機アドレス(a2)フィールド、a2フィールド、送信機アドレス(TA)フィールド、TAフィールド、アドレス2フィールド
412 宛先アドレス(a3)フィールド、a3アドレスフィールド
414 第4のアドレス(a4)フィールド
416 サービス品質(QoS)制御フィールド、サービス品質制御フィールド、QoS制御フィールド
418 高効率(HE)制御フィールド、HE制御フィールド
420 フレーム検査シーケンス(FCS)フィールド、FCSフィールド
422 プロトコルバージョンサブフィールド
424 タイプサブフィールド
426 サブタイプサブフィールド
428 to分散システム(DS)サブフィールド
430 from DSサブフィールド
432 モアフラグメントサブフィールド
434 再試行サブフィールド
436 電力管理サブフィールド
438 モアデータサブフィールド
440 保護サブフィールド
442 順序サブフィールド
450 トラフィック識別子(TID)サブフィールド、TIDサブフィールド、TIDフィールド、トラフィックインジケータ(TID)サブフィールド、トラフィックインジケータサブフィールド
452 サービス期間終了サブフィールド、サービス期間終了フィールド
454 ACKポリシーサブフィールド、ACKポリシーフィールド
456 予約済みフィールド、予約済みサブフィールド
458 可変フィールド、可変サブフィールド、修正済み可変フィールド
460 シーケンス制御フィールド
462 フレーム本体フィールド
470 制御IDサブフィールド
472 AC制約サブフィールド
474 要求されるスケーリング係数サブフィールド
476 予約済みサブフィールド
500 要求フレーム、CTS-to-selfフレーム、修正済み送信可(CTS)-to-selfフレーム
600 報告フレーム、サービス品質(QoS)ヌルフレーム、QoSヌルフレーム、フレーム
620 AC制約サブフィールド
622 スケーリング係数サブフィールド
624 待ち行列サイズまたは要求されるTXOP持続時間フィールド
626 予約済みフィールド
700 報告フレーム、サービス品質(QoS)データフレーム、QoSデータフレーム
800 報告フレーム、省電力(PS)ポールフレーム、PSポールフレーム
820 スケーリング係数サブフィールド
822 待ち行列サイズまたは要求されるTXOP指示サブフィールド
824 待ち行列サイズまたは要求されるTXOP持続時間フィールド
826 予約済みフィールド
900 報告フレーム、高効率(HE)制御フレーム、HE制御フレーム、フレーム
1000 フローチャート
1100 フローチャート

Claims

アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法であって、
前記1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するステップであって、前記要求フレームが、前記アップリンクバッファ報告がアップリンクバッファ内のデータの量または前記アップリンクバッファ内の前記データを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップと、
前記要求フレームを前記1つまたは複数の局の各々に送信するステップと、
前記1つまたは複数の局の各々から報告フレーム内の前記アップリンクバッファ報告を受信するステップと
を含む方法。
前記通信リソースが、前記1つまたは複数の局の各々からの前記受信されたアップリンクバッファ報告に基づいて、アップリンクデータ送信用に前記1つまたは複数の局に割り振られる、請求項1に記載の方法。
トリガフレーム、および
送信機アドレスフィールド中のアクセスポイントのアドレスと、受信機アドレスフィールド中の前記1つまたは複数の局のうちの1つのアドレスとを備える送信可(CTS)-to-selfフレーム
のうちの1つとして前記要求フレームを生成するステップをさらに含む、請求項1に記載の方法。
前記報告フレームが、サービス品質ヌルフレーム、サービス品質データフレーム、省電力ポールフレーム、および制御フレームのうちの1つである、請求項1に記載の方法。
前記報告フレームのフレーム制御フィールドのモアデータサブフィールドに示されているアップリンクデータの存在を判定するステップをさらに含む、請求項1に記載の方法。
前記報告フレームの持続時間フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を判定するステップをさらに含む、請求項1に記載の方法。
前記持続時間フィールドの少なくとも1ビットによって与えられる指示に基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを判定するステップをさらに含む、請求項6に記載の方法。
前記報告フレームのサービス品質制御フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を判定するステップをさらに含む、請求項1に記載の方法。
アップリンク送信パラメータがアクセスポイントによって制御されるか、前記報告フレームを生成する前記局によって制御されるかに基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを判定するステップをさらに含む、請求項8に記載の方法。
前記アップリンクバッファ報告が、前記報告フレームの前記サービス品質制御フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、グラニュラリティを判定するステップをさらに含む、請求項8に記載の方法。
前記報告フレームの送信レートに基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、グラニュラリティを判定するステップをさらに含む、請求項1に記載の方法。
アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るためのワイヤレスデバイスであって、
前記1つまたは複数の局の各々からのアップリンクバッファ報告を要求する要求フレームを生成するように構成されたプロセッサであって、前記要求フレームが、前記アップリンクバッファ報告がアップリンクバッファ内のデータの量または前記アップリンクバッファ内の前記データを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、プロセッサと、
前記要求フレームを前記1つまたは複数の局に送信するように構成された送信機と、
前記1つまたは複数の局の各々から報告フレーム内の前記アップリンクバッファ報告を受信するように構成された受信機と
を備えるワイヤレスデバイス。
前記プロセッサが、前記1つまたは複数の局の各々からの前記受信されたアップリンクバッファ報告に基づいて、アップリンクデータ送信用に前記通信リソースを前記1つまたは複数の局に割り振るようにさらに構成される、請求項12に記載のワイヤレスデバイス。
前記プロセッサが、
トリガフレーム、および
送信機アドレスフィールド中の前記ワイヤレスデバイスのアドレスと、受信機アドレスフィールド中の前記1つまたは複数の局のうちの1つのアドレスとを備える送信可(CTS)-to-selfフレーム
のうちの1つとして前記要求フレームを生成するようにさらに構成される、請求項12に記載のワイヤレスデバイス。
前記報告フレームが、サービス品質ヌルフレーム、サービス品質データフレーム、省電力ポールフレーム、および制御フレームのうちの1つである、請求項12に記載のワイヤレスデバイス。
前記プロセッサが、前記報告フレームのフレーム制御フィールドのモアデータサブフィールドに示されているアップリンクデータの存在を判定するように構成される、請求項12に記載のワイヤレスデバイス。
前記プロセッサが、前記報告フレームの持続時間フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を判定するように構成される、請求項12に記載のワイヤレスデバイス。
前記プロセッサが、前記持続時間フィールドの少なくとも1ビットによって与えられる指示に基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを判定するように構成される、請求項17に記載のワイヤレスデバイス。
前記プロセッサが、前記報告フレームのサービス品質制御フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を判定するように構成される、請求項12に記載のワイヤレスデバイス。
前記プロセッサが、アップリンク送信パラメータが前記ワイヤレスデバイスによって制御されるか、前記報告フレームを生成する前記局によって制御されるかに基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを判定するように構成される、請求項19に記載のワイヤレスデバイス。
前記プロセッサが、前記アップリンクバッファ報告が、前記報告フレームの前記サービス品質制御フィールドに示されている、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、グラニュラリティを判定するように構成される、請求項19に記載のワイヤレスデバイス。
前記プロセッサが、前記報告フレームの送信レートに基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、グラニュラリティを判定するように構成される、請求項12に記載のワイヤレスデバイス。
アップリンクデータ送信用にマルチユーザ通信リソースを1つまたは複数の局に割り振るための方法であって、
アップリンクバッファ報告を要求する要求フレームを受信するステップであって、前記要求フレームが、前記アップリンクバッファ報告がアップリンクバッファ内のデータの量または前記アップリンクバッファ内の前記データを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、ステップと、
前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量のいずれかを選択的に示す前記要求されたアップリンクバッファ報告を含む報告フレームを生成するステップと、
前記報告フレームをワイヤレスデバイスに送信するステップと
を含む方法。
前記局からの前記アップリンクバッファ報告に基づいてアップリンクデータ送信用に前記通信リソースの一部分を前記局に割り振るメッセージが、前記ワイヤレスデバイスから受信される、請求項23に記載の方法。
前記要求フレームが、
トリガフレーム、および
送信機アドレスフィールド中の前記ワイヤレスデバイスのアドレスと、受信機アドレスフィールド中の前記局のアドレスとを備える送信可(CTS)-to-selfフレーム
のうちの1つとして前記ワイヤレスデバイスから受信される、請求項23に記載の方法。
サービス品質ヌルフレーム、サービス品質データフレーム、および省電力ポールフレームのうちの1つとして前記報告フレームを生成するステップをさらに含む、請求項23に記載の方法。
アップリンクデータの存在を示すために、前記報告フレームのフレーム制御フィールド内のモアデータサブフィールドを利用するステップをさらに含む、請求項23に記載の方法。
前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を選択的に示すために、前記報告フレームの持続時間フィールドを利用するステップをさらに含む、請求項23に記載の方法。
前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを示すために、前記持続時間フィールドの少なくとも1ビットを利用するステップをさらに含む、請求項28に記載の方法。
前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を選択的に示すために、前記報告フレームのサービス品質制御フィールドを利用するステップをさらに含む、請求項23に記載の方法。
前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかが、アップリンク送信パラメータが前記ワイヤレスデバイスによって制御されるか、前記報告フレームを生成する前記局によって制御されるかに基づく、請求項30に記載の方法。
前記報告フレームのサービス品質制御フィールドにおいて、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すために前記アップリンクバッファ報告が使用するグラニュラリティを示すステップをさらに含む、請求項30に記載の方法。
前記アップリンクバッファ報告が、前記報告フレームの送信レートに基づくグラニュラリティを使用して、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、請求項23に記載の方法。
アップリンクデータ送信用にマルチユーザ通信リソースを割り振るための局であって、
アップリンクバッファ報告を要求する要求フレームを受信するように構成された受信機であって、前記要求フレームが、前記アップリンクバッファ報告がアップリンクバッファ内のデータの量または前記アップリンクバッファ内の前記データを送信するための要求される時間の量のいずれかを示すことを選択的に要求する、受信機と、
前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量のいずれかを選択的に示す前記要求されたアップリンクバッファ報告を含む報告フレームを生成するように構成されたプロセッサと、
前記報告フレームをワイヤレスデバイスに送信するように構成された送信機と
を備える局。
前記受信機が、前記局からの前記アップリンクバッファ報告に基づいてアップリンクデータ送信用に前記通信リソースの一部分を前記局に割り振るメッセージを前記ワイヤレスデバイスから受信するようにさらに構成される、請求項34に記載の局。
前記要求フレームが、
トリガフレーム、および
送信機アドレスフィールド中の前記ワイヤレスデバイスのアドレスと、受信機アドレスフィールド中の前記局のアドレスとを備える送信可(CTS)-to-selfフレーム
のうちの1つとして前記ワイヤレスデバイスから受信される、請求項34に記載の局。
前記プロセッサが、サービス品質ヌルフレーム、サービス品質データフレーム、および省電力ポールフレームのうちの1つとして前記報告フレームを生成するように構成される、請求項34に記載の局。
前記プロセッサが、アップリンクデータの存在を示すために、前記報告フレームのフレーム制御フィールド内のモアデータサブフィールドを利用するようにさらに構成される、請求項34に記載の局。
前記プロセッサが、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を選択的に示すために、前記報告フレームの持続時間フィールドを利用するようにさらに構成される、請求項34に記載の局。
前記プロセッサが、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを示すために、前記持続時間フィールドの少なくとも1ビットを利用するようにさらに構成される、請求項39に記載の局。
前記プロセッサが、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を選択的に示すために、前記報告フレームのサービス品質制御フィールドを利用するようにさらに構成される、請求項34に記載の局。
前記プロセッサが、アップリンク送信パラメータが前記ワイヤレスデバイスによって制御されるか、前記局によって制御されるかに基づいて、前記アップリンクバッファ報告が前記アップリンクバッファ内の前記データの量を示すか、前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すかを判定するようにさらに構成される、請求項41に記載の局。
前記プロセッサが、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示すために前記アップリンクバッファ報告が使用するグラニュラリティを示すために、前記報告フレームのサービス品質制御フィールドを利用するようにさらに構成される、請求項41に記載の局。
前記アップリンクバッファ報告が、前記報告フレームの送信レートに基づくグラニュラリティを使用して、前記アップリンクバッファ内の前記データの量または前記アップリンクバッファ内の前記データを送信するための前記要求される時間の量を示す、請求項34に記載の局。