JP7467643B2 - 情報指示方法及び通信装置 - Google Patents

Description

この出願は、2020年1月11日に中国国家知識産権局に出願された「情報指示方法及び通信装置」と題される中国特許出願第202010028819．4号の優先権を主張し、更に、2020年3月12日に中国国家知識産権局に出願された「情報指示方法及び通信装置」と題される中国特許出願第202010172693．8号の優先権を主張し、該出願はその全体が参照により本願に組み入れられる。

この出願は、ワイヤレスフィデリティ技術の分野に関し、特に、情報指示方法及び通信装置に関する。

直交周波数分割多元接続（orthogonal frequency division multiple access，OFDMA）送信をサポートするために、周波数帯域リソースが802．11axにおける幾つかのリソースユニットに分割され、また、各ステーション又はステーションの各グループがリソースユニットのうちの1つのみで送信を実行することができる。言い換えると、以下が、すなわち、1つのステーション又は複数のユーザに1つのリソースユニットのみが割り当てられるということが現在サポートされる。しかしながら、以下が、すなわち、複数のリソースユニットが1つ以上のステーションに割り当てられるということが将来サポートされてもよい。複数のリソースユニットを1つ以上のステーションにどのように割り当てるかが現在解決されるべき問題である。

この出願は、情報指示方法及び通信装置を提供する。シグナリングオーバーヘッドを低減するべく、複数のリソースユニットが1つ以上のステーションに割り当てられることを示すためのHE－SIG Bを送信するために2つのコンテンツチャネルが使用される。

第1の態様によれば、情報指示方法が提供される。方法は以下を含む。

アクセスポイント（access point，AP）はリソース指示情報を決定する。リソース指示情報は複数のビットシーケンスを含む。複数のビットシーケンスにおける第1のビットシーケンスは、第1のリソースユニットに対応する。第1のリソースユニットは、第1のステーション（station，STA）又は複数のSTAに割り当てられるリソースブロックセット内のリソースユニットである。リソースブロックセットは少なくとも2つのリソースユニットを含む。

APはリソース指示情報を送信する。

任意選択で、第1の態様におけるリソース指示情報については、特定の実施形態におけるリソース指示情報の実施を参照されたい。

第2の態様によれば、情報指示方法が提供される。方法は以下を含む。

アクセスポイント（access point，AP）は第1の指示情報を生成する。第1の指示情報は、複数のステーション（station，STA）が不連続帯域幅で全帯域幅マルチユーザ（multi use multiple input multiple output，MU－MIMO）送信を実行することを示すために使用される。

APは第1の指示情報を送信する。

任意選択で、第2の態様における第1の指示情報については、特定の実施形態における指示情報の実施を参照されたい。

第3の態様によれば、通信装置が提供される。通信装置は、第1の態様又は第1の態様の想定し得る実施のいずれか1つに係る方法を実行するように構成されるモジュールを含む、或いは、通信装置は、第2の態様又は第2の態様の想定し得る実施のいずれか1つに係る方法を実行するように構成されるモジュールを含む。

第4の態様によれば、この出願の一実施形態は、コンピュータプログラムを記憶するように構成されるコンピュータ可読記憶媒体を提供する。コンピュータプログラムは、第1の態様又は第1の態様の想定し得る実施のいずれか1つを実行するための命令、或いは、第2の態様又は第2の態様の想定し得る実施のいずれか1つを実行するための命令を含む。

第5の態様によれば、この出願の一実施形態はコンピュータプログラムを提供する。コンピュータプログラムは、第1の態様又は第1の態様の想定し得る実施のいずれか1つを実行するための命令、或いは、第2の態様又は第2の態様の想定し得る実施のいずれか1つを実行するための命令を含む。

第6の態様によれば、この出願の一実施形態は、通信システムを提供する。通信システムは、第3の態様で提供される通信装置及びステーションを含む。

この出願の一実施形態が適用可能である無線ローカルエリアネットワークのネットワークアーキテクチャを示す。 この出願の一実施形態に係るアクセスポイント及びステーションの内部構造の図である。 この出願の一実施形態に係るアクセスポイント及びステーションの内部構造の他の図である。 802．11axにおける80Mマルチユーザパンクチャリングモード1を示す。 802．11axにおける80Mマルチユーザパンクチャリングモード2を示す。 802．11axにおける160Mマルチユーザパンクチャリングモード1を示す。 802．11axにおける160Mマルチユーザパンクチャリングモード2を示す。 この出願の一実施形態に係るHE MU PPDUのフレーム構造の概略図である。 この出願の一実施形態に係るHE－SIG－Bの構造の概略図である。 この出願の一実施形態に係る40MHzのHE－SIG－Bのフレーム構造の概略図である。 この出願の一実施形態に係るEHT PPDUのフレーム構造の概略図である。 この出願の一実施形態に係る80MHzスペクトル帯域幅を1人のユーザに割り当てるためのリソース分割の概略図である。 この出願の一実施形態に係るシングルユーザパンクチャード送信方法の概略フローチャートである。 この出願の一実施形態に係る80MHzスペクトル帯域幅を4人のユーザに割り当てるためのリソース分割の概略図である。 この出願の一実施形態に係る全帯域幅MU－MIMOパンクチャード送信方法の概略フローチャートである。 この出願の一実施形態に係る異なるユーザに割り当てられるリソースユニット間の重複の概略図である。 この出願の一実施形態に係る160MHzスペクトル帯域幅を2人のユーザに割り当てるためのリソース分割の概略図である。 この出願の一実施形態に係る160MHzスペクトル帯域幅を5人のユーザに割り当てるためのリソース分割の概略図である。 この出願の一実施形態に係るトリガフレームのフレーム構造の概略図である。 この出願の一実施形態に係るトリガフレーム内のユーザ情報フィールドの構造の概略図である。 この出願の一実施形態に係るアップリンク全帯域幅MU－MIMOパンクチャード送信方法の概略フローチャートである。 この出願の一実施形態に係るAPの構造の概略図である。

この出願の実施形態の目的、技術的解決策、及び、利点をより明確にするために、以下では、添付の図面を参照してこの出願の実施形態を更に詳しく説明する。

この出願の実施形態は、無線ローカルエリアネットワーク（wireless local area network，WLAN）のシナリオに適用されてもよく、また、IEEE 802．11システム規格、例えばIEEE 802．11ax規格、或いは、次世代規格又は更なる次世代規格に適用されてもよい。或いは、この出願の実施形態は、無線ローカルエリアネットワークシステム、例えば、モノのインターネット（internet of things，IoT）又は車両のインターネット（Vehicle to X，V2X）に適用されてもよい。確かに、この出願の実施形態は、他の想定し得る通信システム、例えば、グローバル・システム・フォー・モバイル・コミュニケーションズ（global system for mobile communications，GSM）、符号分割多元接続（code division multiple access，CDMA）システム、広帯域符号分割多元接続（wideband code division multiple access，WCDMA(登録商標)）システム、汎用パケット無線サービス（general packet radio service，GPRS）、ロングタームエボリューション（long term evolution，LTE）システム、LTE周波数分割複信（frequency division duplex，FDD）システム、LTE時分割複信（time division duplex，TDD）システム、ユニバーサル移動体通信システム（universal mobile telecommunication system，UMTS）、ワールドワイド・インタオペラビリティ・フォー・マイクロウェーブ・アクセス（worldwide interoperability for microwave access，WiMAX）通信システム、及び、将来の5G通信システムに更に適用されてもよい。

例えば、図1は、この出願の一実施形態が適用可能なWLANのネットワークアーキテクチャの図である。図1は、WLANが1つのAPとAPに関連付けられるSTA1及びSTA2とを含む例を使用する。APは、STA1及びSTA2のための無線リソースをスケジュールし、スケジュールされた無線リソースでSTA1及びSTA2のためのデータを送信することができる。データは、アップリンクデータ情報及び／又はダウンリンクデータ情報を含む。図1におけるAPの数及びSTAの数は単なる一例にすぎないことが理解されるべきである。より多くの又はより少ないAP及びSTAが存在し得る。APは、STA1又はSTA2と通信してもよく、或いは、STA1及びSTA2と通信してもよい。WLANが複数のAP及び複数のSTAを含む場合、この出願のこの実施形態はAP間の通信にも適用可能であることが理解されるべきである。例えば、APは、分散システム（distributed system，DS）を使用することによって互いに通信することができる。任意のAPは、APと関連付けられたSTA及び／又はAPに関連付けられないSTAのための無線リソースをスケジュールし、スケジュールされた無線リソースでSTAのためのデータを送信することができる。この出願のこの実施形態は、STA間の通信にも適用可能である。

この出願のこの実施形態におけるステーションSTAは、無線通信機能を有する様々なユーザ端末、ユーザ装置、アクセス装置、加入者ステーション、加入者ユニット、モバイルステーション、ユーザエージェント、ユーザ機器などであってもよい。ユーザ端末は、無線通信機能を有する無線モデムに接続される様々なハンドヘルドデバイス、車載デバイス、ウェアラブルデバイス、コンピューティングデバイス、又は、他の処理デバイス、及び、無線媒体を使用することによってネットワーク通信を実行するように構成される様々な形態のユーザ機器（user equipment，UE）、モバイルステーション（mobile station，MS）、端末（terminal）、端末機器（terminal equipment）、ポータブル通信デバイス、ハンドヘルドデバイス、ポータブルコンピューティングデバイス、エンターテイメントデバイス、ゲームデバイス又はシステム、全地球測位システムデバイス、又は、任意の他の適切なデバイスなどを含むことができる。本明細書では、説明を容易にするために、前述のデバイスがまとめてステーション又はSTAと称される。この出願のこの実施形態におけるアクセスポイントAPは、無線通信ネットワークに配備されるとともにAPと関連付けられるSTAに無線通信機能を与える装置である。アクセスポイントAPは、通信システムのハブとして使用され得る。APは、基地局、ルータ、ゲートウェイ、リピータ、通信サーバ、スイッチ、又は、ブリッジなどの通信デバイスであってもよい。基地局は、様々な形態のマクロ基地局、マイクロ基地局、中継局などを含み得る。本明細書では、説明を簡単にするために、前述のデバイスがまとめてアクセスポイントAPと称される。

具体的には、この出願におけるAP及びSTAは、IEEE 802．11システム規格が適用可能なAP及びSTAであってもよい。図2は、この出願の一実施形態に係るAP及びSTAの内部構造の図である。802．11システム規格では、802．11における物理層（physical，PHY）及び媒体アクセス制御（media access control，MAC）部分に主に焦点が当てられる。したがって、この出願のこの実施形態で提供されるSTAは、一般に、802．11システム規格におけるMAC層及びPHY層をサポートする端末製品、例えば携帯電話又はノートブックコンピュータである。図2はマルチアンテナAP及びシングルアンテナSTAの構造の図であるが、実際のシナリオでは、AP及びSTAがそれぞれ複数のアンテナを含むことができ、それぞれが3つ以上のアンテナを有するデバイスであってもよいことに留意すべきである。

図3は、この出願の一実施形態に係るAP及びSTAの内部構造の他の図である。AP及びSTAはそれぞれ、最下層に属する、PHYベースバンドモジュール、MAC層モジュール、論理リンク制御（logical link control，LLC）層モジュール、及び、無線周波数モジュール、すなわち、アンテナ、並びに、上位層に属する、インターネットプロトコル（internet protocol，IP）処理モジュール、送信制御プロトコル（transmission control protocol，TCP）／ユーザデータグラムプロトコル（user datagram protocol，UDP）処理モジュール、及び、アプリケーション層モジュールを含む。最下層と上位層との間では、上位層インタフェースを用いて情報送信が実現される。

APはSTAと通信する。APは、STAにリソースを割り当てることができる。STAは、割り当てられたリソース上でデータ送信を実行する。例えば、802．11ax、例えば802．11acの前のWi－Fiプロトコルは、送信が20MHz、40MHz、80MHz、及び160MHzの4種類の帯域幅を含む隣接する帯域幅を占有する必要があることを要求する。1つの20MHzはプライマリ20MHzとして示される。帯域幅内の20MHzが別のステーションの送信によって占有される場合、PPDU送信帯域幅は低減される必要がある。低減された帯域幅は、プライマリ20MHzを含む必要がある。プライマリ20MHzに連続する他の全ての20MHzは、アイドルであり、利用可能である。例えば、隣接する80M帯域幅における最初の20MHzはプライマリ20MHzであるが、第2の20MHzチャネルはビジーである。この場合、隣接する帯域幅の要件にしたがって、プライマリ20MHzのPPDUのみを送信することができ、すなわち、アイドル40MHzは80MHz帯域幅で浪費される。

より多くのチャネルを集約してより大きな利用可能帯域幅を形成するために、802．11axプロトコルでプリアンブルパンクチャード送信方式が提案される。不連続チャネルを一緒に集約することができる。前述の例において、アクセスポイントは、アイドルチャネルをより効率的に使用するために、20MHz＋40MHzのPPDUを送信できるようにされる。具体的には、802．11ax規格で定められる4つのタイプの送信帯域幅では、4つのタイプの送信帯域幅における80MHz帯域幅及び160MHz帯域幅でのみプリアンブルパンクチャード送信方式を実施することが可能である。以下、802．11axで提案される4つのプリアンブルパンクチャード送信方式について個別に説明する。

80MHz帯域幅は、プライマリ20MHz P20、セカンダリ20MHz S20、及びセカンダリ40MHz S40を含む。ここで、S40は、S40－L（S40における左20MHz）とS40－R（S40における右20MHz）とに更に分けられる。80MHzに対応するプリアンブルパンクチャード送信方式が図4及び図5に示される。図4において、80MHz帯域幅では、S20のみがパンクチャされる。図5において、80MHz帯域幅では、S40における1つの20MHzのみがパンクチャされる。

160MHz帯域幅は、プライマリ20MHz P20、セカンダリ20MHz S20、セカンダリ40MHz S40、及びセカンダリ80MHz S80を含む。ここで、S40は、S40－LとS40－Rとに更に分けられる。160MHzに対応するプリアンブルパンクチャ方式が図6及び図7に示される。図6では、160MHz帯域幅におけるプライマリ80MHz（P20、S20、S40を含む）でS20のみがパンクチャされ、セカンダリ80MHzで20MHzがパンクチャされ得る。これは、802．11axにおけるHE－SIG－Bフィールドを使用して示される。図7では、160MHz帯域幅におけるプライマリ80MHz（P20、S20、S40を含む）のプライマリ40MHz（P20及びS20を含む）がパンクチャされず、セカンダリ40MHz及びセカンダリ80MHzにおける20MHzがパンクチャされ得る。これは、802．11axにおけるHE－SIG－Bフィールドを使用して示される。

802．11axにおける80MHz帯域幅に関する2つのプリアンブルパンクチャード送信方式及び160MHz帯域幅に関する2つのプリアンブルパンクチャード送信方式は、指示情報を使用して指示され得る。指示情報は、802．11axにおけるPPDUプリアンブルの高効率信号A（high efficiency signal A，HE－SIG－A）フィールドに位置される。80MHz帯域幅における第2のプリアンブルパンクチャリングモード及び160MHz帯域幅における2つのプリアンブルパンクチャリングモードがいずれも特定のパンクチャされた20MHzを具体的に示すことができないことに留意すべきである。受信端は、次のフィールドの共通情報部分フィールド内、すなわち、802．11axにおけるHE PPDUプリアンブルのHE－SIG－Bフィールド内のリソース割り当て指示情報を更に解析する必要がある。HE－SIG－Bは、主に、複数のステーションに関して、OFDMA及びMU－MIMOを含むダウンリンクマルチユーザ送信を実行し、リソースユニット割り当て情報及びステーション送信パラメータを提供するために使用される。言い換えると、802．11axにおけるプリアンブルパンクチャード送信方式は、マルチユーザ送信にのみ適用可能である。

図8は、802．11axプロトコルで提案されるマルチユーザフレームフォーマット、すなわち、高効率マルチユーザ物理プロトコルデータユニット（high efficiency multi－user physical protocol data unit，HE MU PPDU）を示す。フレームフォーマットは、3つの部分、すなわち、レガシープリアンブル（legacy preamble，L－preamble）、高効率プリアンブル（high efficiency preamble，HE－preamble）、及び物理層収束プロトコルサービスデータユニット（physical layer convergence protocol service data unit，PSDU）を含む。HEプリアンブルは、繰り返しレガシー信号（repeated legacy signal，RL－SIG）、HE－SIG－A、高効率信号B（high efficiency signal B，HE－SIG－B）、高効率ショートトレーニングフィールド（high efficiency－short training field，HE－STF）、及び、高効率ロングトレーニングフィールド（high efficiency－long training field，HE－LTF）などのフィールドを更に含む。

図9は、802．11axプロトコルで提案されるHE－SIG Bフィールドフォーマットを示す。HE－SIG－Bは2つの部分に分けられる。第1の部分は、共通フィールドであり、1～N個のリソースユニット割り当てサブフィールド（RU Allocation subfield）、80MHz以上の帯域幅用の中央26トーン（Center 26－Tone）リソースユニット指示フィールド、チェックのために使用される巡回冗長コード（Cyclic Redundancy Code，CRC）、及び、巡回復号のために使用されるテール（Tail）サブフィールドを含む。加えて、ユーザ固有フィールド（User Specific field）には、リソースユニット割り当てシーケンスにおいて1～M個のユーザフィールドがある。ここで、一般に、M個のユーザフィールドの2つおきが1つのグループ内にあり、2つおきのユーザフィールドの後には、1つのCRCと、最後のグループを除く1つのテールフィールドとが続く。最後のグループは、1つ又は2つのユーザフィールドを含むことができる。したがって、最後のグループ内のユーザフィールドは破線を使用して示される。ユーザフィールドの最後のグループの後のテールフィールドの後にパディング（Padding）フィールドが続いてもよい。

APは、STAに割り当てられたRUを示すためにリソース割り当て情報をHE－SIG－Bに付加することができる。直交周波数分割多元接続（orthogonal frequency division multiple access，OFDMA）技術及びマルチユーザ多入力多出力（multiple user multiple input multiple output，MU－MIMO）技術が適用される場合、スペクトル帯域幅は、WLANプロトコルにおいて幾つかのリソースユニット（resource unit，RU）に分割される。IEEE 802．11axプロトコルは、スペクトル帯域幅が、26トーンRU、52トーンRU、106トーンRU、242トーンRU（20MHz帯域幅における最大のRU）、484トーンRU（40MHz帯域幅における最大のRU）、996トーンRU（80MHz帯域幅における最大のRU）、及び、2＊996トーンRU（160MHz帯域幅における最大のRU）を含む20MHz、40MHz、80MHz、及び、160MHz用の複数のタイプのRUに分割され得ることを定める。各RUは連続トーンを含む。例えば、26トーンRUは、26個の連続トーンを含むRUである。スペクトル帯域幅リソース分割は、1つ以上の8ビットシーケンスを使用して示される。ここで、8ビットごとがスペクトル帯域幅における1つの20MHzに対応する。

例えば、802．11axプロトコルでは、リソースユニット割り当てサブフィールドのインデックステーブルが表1に示される。インデックステーブルは割り当てられたリソースを示すために使用されるため、インデックステーブルはリソース割り当て情報テーブルと呼ばれることもある。

コンテンツチャネル（Content Channel，CC）の概念は、802．11axプロトコルに更に導入される。帯域幅が20MHzのみである場合、HE－SIG－Bはただ1つのCCを含む。CCは、20MHzにおいて割り当てられたRUを示すために使用される1つのリソースユニット割り当てサブフィールドを含む。リソースユニット割り当てサブフィールドは、インデックス方式で20MHz帯域幅内の全ての想定し得るRU順列及び組み合わせ方式を示すために使用され得る8ビットを占有する。そのサイズが106トーンRU以上であるRUの場合には、RUのSU／MU－MIMO送信におけるユーザの数又はユーザ情報フィールドの数、例えば表1の文字x又はyが更に示される必要がある。詳細については、802．11axプロトコルを参照されたい。

送信帯域幅が20MHzよりも大きい場合、L－プリアンブル及びHE－プリアンブルにおけるRL－SIGフィールド及びHE－SIG－Aフィールドは20MHzごとに繰り返し送信され、また、HE－SIG Bは「1212」送信方法を使用する。すなわち、HE－SIG Bが2つのCCを含む。送信帯域幅における奇数番目の20MHzごとに1つのCCが送信される。CCは、奇数番目の20MHzのサブチャネルのリソース割り当て情報と、奇数番目の20MHzのサブチャネルで送信されるステーション情報とを含む。その他のCCは、送信帯域幅で偶数番目の20MHzごとに送信される。その他のCCは、偶数番目の20MHzのサブチャネルのリソース割り当て情報と、偶数番目の20MHzのサブチャネルで送信されるステーション情報とを含む。リソースユニット割り当てサブフィールドのコンテンツは、2つのCCのそれぞれに部分的に表示されることが理解されるべきである。2つのCCを読み取ることによって、STAは、スペクトル帯域幅リソースを分割した後に取得されるRUを知ることができる。

例えば、図10は、40MHz HE－SIG－Bの構造を示す。帯域幅が40MHzである場合、CC1及びCC2の2つのCCが存在する。CC1は、奇数番目の20MHz（すなわち、第1の20MHz）を含む範囲のリソースユニット割り当てサブフィールドと、対応するユーザ固有フィールドとを含む。CC2は、偶数番目の20MHz（すなわち、第2の20MHz）を含む範囲のリソースユニット割り当てサブフィールドと、対応するユーザ固有フィールドとを含む。

別の例の場合、帯域幅が80MHzであるとき、2つのCCも存在する。2つのCCはそれぞれCC1及びCC2である。CC1は、奇数番目の242トーンRU（すなわち、第1の20MHz及び第3の20MHz）及び対応するユーザ固有フィールドを含む範囲内にリソースユニット割り当てサブフィールドを含む。CC2は、偶数の242トーンRU（すなわち、2番目の20MHz及び4番目の20MHz）を含む範囲のリソースユニット割り当てサブフィールドと、対応するユーザ固有フィールドとを含む。

表1に示されるリソースユニット割り当てサブフィールドに関して複数のRU割り当てモードが設定されるが、最大で160MHzの割り当てがサポートされ、将来的にはより大きな帯域幅、例えば320MHzの割り当てがサポートされ得る。現在、802．11axプロトコルは、320MHzにおいて全ての想定し得るRU順列及び組み合わせ方式を定めず、320MHz帯域幅に関する割り当て指示方式を有さない。

加えて、送受信の複雑さを低減するために、OFDMA送信では、情報送信のために各ステーション又はステーションの各グループにただ1つのリソースブロックが割り当てられてもよい。ここで、ステーションの各グループは、そのステーションのグループが対応するリソースブロックでMU－MIMO送信を実行することを示す。言い換えると、以下が現在サポートされる。すなわち、1つのRUのみが1つのユーザに割り当てられる。以下はサポートされない。すなわち、1人のユーザに複数のRUが割り当てられる。スペクトル利用率を高めるために、将来、複数のRUが1人のユーザに割り当てられることがサポートされ得る。1人のユーザに複数のRUをどのように割り当てるかは、現在解決されるべき問題である。

加えて、APは1つのSTAと通信することができる。これは、シングルユーザ送信とも呼ばれる。802．11axプロトコルでは、シングルユーザ送信が隣接する帯域幅でのみサポートされる。しかしながら、スペクトル利用率を高めるために、802．11axの次世代プロトコル、例えば802．11beでは、シングルユーザ送信が不連続な帯域幅でサポートされてもよい。言い換えると、帯域幅内の幾つかのサブチャネルをパンクチャできるようにされる（例えば、20MHzが単位として用いられる）。同様に、APも複数のSTAと通信してもよい。例えば、複数のSTAは、全帯域幅MU－MIMO送信を実行する。しかしながら、802．11axプロトコルでは、802．11axプロトコルが隣接する帯域幅でのみサポートされ、シングルユーザ送信は隣接する帯域幅でのみサポートされる。将来、全帯域幅MU－MIMO送信は、不連続帯域幅でサポートされてもよい。シングルユーザパンクチャード送信及び全帯域幅MU－MIMO送信の場合、APがSTAに割り当てられたRUをどのように示すかは、現在解決されるべき問題である。シングルユーザパンクチャード送信は、1つのステーションが複数の不連続なRUで送信を実行することを示すことを理解すべきである。同様に、全帯域幅MU－MIMOパンクチャード送信は、ステーションのグループが不連続なRUでMU－MIMO送信を実行することを示す。

前述の技術的問題を解決するために、この出願の一実施形態は情報指示方法を提供する。この方法において、APは、シングルユーザパンクチャされたPPDU又はマルチユーザパンクチャされたPPDUを示すためにPPDUプリアンブル内のフィールドを再利用することができる。加えて、APは、シングルユーザ送信において複数のRUが1つのステーションに割り当てられること、又は、マルチユーザ送信において複数のRUが1つ以上のステーションに割り当てられることを示すために、リソース割り当て情報テーブル内のビットシーケンスを再使用する。802．11axにおけるMUパンクチャード送信方法と比較して、この出願ではシグナリングオーバーヘッドを低減することができる。

以下、添付図面を参照して、この出願の実施形態に係るシングルユーザパンクチャード送信方法及び全帯域幅MU－MIMOパンクチャード送信方法について個別に説明する。

現在の802．11ax規格において、シングルユーザ送信及び全帯域幅MU－MIMO送信は、隣接する帯域幅でのみサポートされる。言い換えると、帯域幅内のサブチャネルをパンクチャできるようにされない。しかしながら、スペクトル利用率を高めるために、802．11axの次世代プロトコル、例えば802．11be規格では、シングルユーザパンクチャード送信及び全帯域幅MU－MIMOパンクチャード送信がサポートされ得る。言い換えると、全帯域幅MU－MIMOにおける単一のユーザ及び複数のユーザは、パンクチャされた帯域幅で送信を実行できるようにされる。

したがって、この出願のこの実施形態では、APがダウンリンクシングルユーザパンクチャード送信を実行する必要がある場合、送信されるべきPPDUがシングルユーザパンクチャされたPPDUであるか又はマルチユーザパンクチャされたPPDUであるかを示すことが更に必要とされる。同様に、APがダウンリンク全帯域幅MU－MIMO送信を実行する必要があるとき、PPDUが全帯域幅MU－MIMOパンクチャード送信によって送信されるべきであることを示すことが更に必要とされる。

具体的には、この出願のこの実施形態では、第1の指示情報を使用して、送信されるべきPPDUが異なる送信モードと見なされ得るシングルユーザパンクチャされたPPDUであるか又はマルチユーザパンクチャされたPPDUであるかをSTAに通知することができる。シングルユーザパンクチャされたPPDUは第1の送信モードにあり、マルチユーザパンクチャされたPPDUは第2の送信モードにあることが理解され得る。この場合、第1の指示情報は、第1の送信モード及び第2の送信モードを示すために使用され得る。具体的には、指示情報は、PPDUの1つ以上のフィールドで伝えられ得る。以下では、第1の指示情報の幾つかの実施を説明するために、一例としてPPDUの想定し得る構造を使用する。

別の実施において、この出願のこの実施形態では、シングルユーザ全帯域幅送信、シングルユーザ全帯域幅パンクチャード送信、全帯域幅MU－MIMO送信、全帯域幅MU－MIMOパンクチャード送信、又は、OFDMA送信によってPPDUが送信されるべきであることをSTAに通知するために第1の指示情報が使用され得る。MU－MIMO送信は、OFDMA送信におけるリソースブロックに関しても許容される。OFDMA送信におけるリソースブロックもパンクチャされ得る。

任意選択で、シングルユーザ全帯域幅パンクチャード送信及び全帯域幅MU－MIMOパンクチャード送信は、モードAに組み合わされてもよい。このモードでは、EHT信号フィールドは、リソース割り当てに関する情報、例えばパンクチャリングに関する情報を含む。これは、解決策（4）で具体的に言及される。

任意選択で、全帯域幅MU－MIMO送信及びOFDMA送信は、モードBに組み合わされてもよい。このモードでは、EHT信号フィールドがRUリソース割り当て情報などのリソース割り当てに関する情報を含むかどうかが、802．11axにおける圧縮モード指示フィールドなどの別のフィールドを使用して更に決定される。リソース割り当てに関連する情報を含まないEHT信号フィールドは、全帯域幅MU－MIMO送信で使用されてもよく、任意選択でシングルユーザ送信で使用されてもよい。リソース割り当てに関連する情報を含むEHT信号フィールドは、OFDMA送信で、及び任意選択でシングルユーザ送信で使用されてもよい。

この出願のこの実施形態におけるPPDUは、EHT PPDUであってもよい。図11は、EHT PPDUのフレーム構造の一例を示す。図11に示されるように、EHT PPDUは、Lプリアンブルフィールド、二位相偏移変調（binary phase shift keying，BPSK）シンボルフィールド、超高スループット（extremely high throughput，EHT）信号フィールド、超高スループットショートトレーニングフィールド（extremely high throughput short training field，EHT－STF）、超高スループットロングトレーニングフィールド（extremely high throughput long training field，EHT－LTF）、及びデータ（data）フィールドなどのフィールドを含み得る。Lプリアンブルフィールドは、レガシー信号フィールド（legacy signal field，L－STF）及びレガシーロングトレーニングフィールド（legacy long training field，L－LTF）を含み得る。BPSKシンボルフィールドは、L－SIGフィールド、RL－SIGフィールド、及びU－SIGフィールドを含み得る。

この出願のこの実施形態において、STAに割り当てられたRUを示すために使用されるリソース指示情報は、EHT信号フィールドで伝えられ得る。EHT信号フィールドは、共通フィールド及びユーザ固有フィールドを含み得る。リソース割り当て情報は、共通フィールドで伝えられてもよい。ステーションの識別子は、ユーザ固有フィールドで送信され得る。

U－SIGフィールドは、バージョン非依存情報（version independent info）フィールド及びバージョン依存情報（version dependent info）フィールドを含み得る。バージョン非依存情報フィールドは、3ビットWi－Fiバージョンフィールド、1ビットダウンリンク／アップリンク・フィールド、少なくとも6ビットを伴うBSSカラー・フィールド、少なくとも7ビットを伴うTxOPフィールド、少なくとも4ビットを伴うCRCフィールド、及び6ビットテールフィールドを含み得る。更に、バージョン非依存情報フィールドは、帯域幅フィールドを更に含んでもよい。バージョン依存情報フィールドは、PPDUフォーマットフィールドなどを含むことができ、変調符号化方式フィールド、空間フローフィールド、符号化フィールドなどのうちの1つ以上を更に含むことができる。

第1の指示情報の一実施において、第1の指示情報は、U－SIGフィールド内の1つのフィールドで伝えられ得る。説明を簡単にするために、この出願のこの実施形態では、このフィールドが第1のフィールドと称される。第1のフィールドは、U－SIGフィールド内の所定のフィールドであってもよく、又は、U－SIGフィールド内に新たに付加されたフィールドであってもよい。第1のフィールドは、2ビット以上を占有し得る。例えば、第1のフィールドの値が第1の値、例えば「00」である場合、それはシングルユーザPPDUを示し、パンクチャリングはなく、第1のフィールドの値が第2の値、例えば「01」である場合、それはシングルユーザPPDU及びパンクチャリングを示すことができ、第1のフィールドの値が第3の値、例えば「10」である場合、それはマルチユーザPPDUを示し、パンクチャリングはなく、或いは、第1のフィールドの値が第4の値、例えば「11」である場合、それはマルチユーザPPDU及びパンクチャリングを示し得る。この出願のこの実施形態において、第1のフィールドの値は、幾つかの実施形態では、第1のフィールドで伝えられる値としても理解され得ることに留意すべきである。

例えば、第1のフィールドは、U－SIGフィールド内の所定のフィールド、例えばPPDUフォーマットフィールドであってもよい。第1のフィールドがU－SIGフィールド内の新たに付加されたフィールドである場合、第1のフィールドはEHT信号フィールド内の共通フィールドの前に位置されることを理解すべきである。

第1の指示情報の別の実施において、第1の指示情報は、代わりに、U－SIGフィールド内の2つのフィールドで伝えられてもよい。説明を容易にするために、この出願のこの実施形態では、2つのフィールドがそれぞれ第1のフィールド及び第2のフィールドと呼ばれる。第1のフィールド及び第2のフィールドは、両方ともU－SIGフィールド内の所定のフィールド又はU－SIGフィールド内の新たに付加されたフィールドであり得る。或いは、第1のフィールドはU－SIGフィールド内の所定のフィールドであり、第2のフィールドはU－SIGフィールド内に新たに付加されたフィールドである。或いは、第1のフィールドはU－SIGフィールドに新たに付加されたフィールドであり、第2のフィールドはU－SIGフィールド内の所定のフィールドである。第1のフィールドは、シングルユーザPPDU又はマルチユーザPPDUを含む、送信されるべきPPDUのフォーマットを示すために使用される。第2のフィールドは、パンクチャード送信を実行するか否かを示すために使用される。例えば、第2のフィールドは、1つ以上のビットを占有する。第2のフィールドの値が第1の値、例えば「1」である場合、それはパンクチャリングを示すことができる。これに対応して、第2のフィールドの値が第2の値、例えば「0」である場合、それはパンクチャリングがないことを示すことができる。

例えば、第1のフィールドはPPDUフォーマットフィールドであり、第2のフィールドは、U－SIGフィールド内の新たに付加されたフィールド、例えばパンクチャリングフィールドであってもよい。第2のフィールドの値がパンクチャリングを示す場合、PPDUにおけるEHT信号フィールドに含まれる共通フィールドが存在し、また、EHT信号フィールドはリソース割り当て情報を伝えることができることに留意すべきである。例えば、EHT信号フィールドは、リソース割り当て情報を伝えるために使用されるリソースユニット割り当てサブフィールドを含み、或いは、EHT信号フィールドはビットマップを含み、ビットマップはパンクチャされた帯域幅リソースを示すために用いられる。第2のフィールドの値がパンクチャリングがないことを示す場合、PPDUにおけるEHT信号フィールドに含まれる共通フィールドは存在しなくてもよい。

別の例では、第1のフィールドがPPDUフォーマットフィールドであり、第2のフィールドが帯域幅フィールドである。帯域幅フィールドは、帯域幅がパンクチャリングモードの帯域幅であるか又は非パンクチャリングモードの帯域幅であるかどうかを示すために使用される。

例えば、802．11axでは、帯域幅を示すために3ビットがある。最初の4つの値は、20M、隣接40M、隣接80M、及び、隣接160Mを示す。最後の4つの値は、パンクチャされた80M帯域幅及びパンクチャされた160M帯域幅を示す。例えば、802．11beでは、帯域幅フィールドが4ビットを占有し得る。言い換えると、帯域幅フィールドの値は［0，15］にある、すなわち16個の値である。16個の値の最初の5つの値は、20M、隣接40M、隣接80M、隣接160M、及び隣接320Mを示すために使用される。任意選択で、1つの値が含まれて240Mを示すために使用されてもよい。16個の値のうち未使用の値はそれぞれ、パンクチャされた40M、パンクチャされた80M、パンクチャされた160M、及びパンクチャされた320Mを示す。例えば、16個の値のうちの6番目の値は、パンクチャされた40Mを示すために使用され、7番目の値は、パンクチャされた80Mを示すために使用される。この解決策では、80MシングルユーザパンクチャされたPPDUが送信される場合、PPDUフォーマットフィールドはシングルユーザPPDUを示し、帯域幅フィールドの値はパンクチャされた80Mを示す複数の値のうちの1つである。

APが各STAにデータを送信するように指示す場合、APは、APによって各STAに割り当てられたRUを各STAに通知する必要がある。具体的には、APは、表1のビットシーケンス、すなわちリソース割り当て情報テーブルを使用して、各STAに割り当てられたRUを示すことができる。1つ以上のビットシーケンスは、スペクトル帯域幅リソースを対応して幾つかのリソースブロックセットに分割することを示す。1つのリソースブロックセットは、1つ以上のリソースブロックを含み得る。ビットシーケンスの数は、U－SIGフィールドの帯域幅に依存し、帯域幅／20MHzに等しい。ここで、帯域幅は20MHzの倍数である。分割不可能な帯域幅は、別途記載される。1つのSTAに対して1つのリソースブロックセットが割り当てられる。リソースブロックは、サイズや位置などの属性を含む。各リソースブロックセットは、1つのユーザ情報フィールド又はユーザ情報フィールドの1つのグループに対応する。これは、802．11axのHE－SIG Bに含まれるリソースユニット割り当てフィールド及び1つ以上のユーザ情報フィールドと同様である。1つのリソースブロックセットが1つのユーザ情報フィールドに対応する場合、それは、リソースブロックセットが送信のためにユーザに割り当てられることを示す。1つのリソースブロックセットがユーザ情報フィールドの1つのグループに対応する場合、それは、リソースブロックセットが送信のためにユーザの1つのグループに割り当てられることを示す。ユーザ情報フィールドの1つのグループについて、例えば、MU－MIMO送信のために使用され得るリソースブロックについて、ユーザ情報フィールドのグループに含まれるユーザ情報フィールドの数は、リソースユニット割り当てフィールド、例えば表中の文字x又はyを使用して示されることが理解されるべきである。詳細は802．11axと同様である。1つ以上のリソースブロック割り当てフィールドを用いて示される帯域幅に対して行なわれる分割によって得られる1つ以上のリソースブロックセットと1つ以上の後続のユーザ情報フィールドとの間の対応関係に基づき、ユーザは、対応関係を受信した後でのみ、ユーザのダウンリンクデータが送信される特定のリソースブロックセットを知ることができる。

この出願のこの実施形態では、802．11ax規格のリソース割り当て情報テーブルを使用することができる。言い換えると、表1のビットシーケンスは、1つのリソースブロックセットが送信のために1つのSTAに割り当てられることを示す。リソースブロックセットは少なくとも2つのリソースユニットを含む。この出願のこの実施形態で使用されるビットシーケンスは、所定のビットシーケンスであってもよく、又は、未定義のビットシーケンス、すなわち、予約済みビットシーケンス、例えば「011101 x 1 x 0」、「01111 y 2 y 1 y 0」、「11011 y 2 y 1 y 0」、又は「111 x 4 x 3 x 2 x 1 x 0」であってもよいことが理解されるべきである。以下の説明では、以下の例が使用される。すなわち、この出願のこの実施形態で使用されるビットシーケンスは表1の予約済みビットシーケンスであり、予約済みビットシーケンスはmビットを占有する。以下の説明では、mは8以上である。

以下では、シングルユーザパンクチャード送信シナリオと全帯域幅MU－MIMOパンクチャード送信シナリオとを用いてこの出願の実施形態で提供される解決策を個別に説明する。

この出願の一実施形態は、シングルユーザパンクチャード送信方法を提供する。この方法では、1つのリソースブロックセットが1人のユーザ（STA）に割り当てられること、すなわち、送信が複数のRUで実施されることを示すために、複数の予約済みビットシーケンスが使用され、また、複数の予約済みビットシーケンスは、スペクトル帯域幅がパンクチャされる特定の位置を示すために更に使用され得る。1つの予約済みビットシーケンスは、1つのリソースブロックセット内の1つのRUに対応する。異なる予約済みビットシーケンスは、異なるタイプの割り当てられたRUを示す。例えば、リソースブロックセット内の1つのRUが242トーンRUであることを示すために、予約済みビットシーケンスの値は第1の値であり、リソースブロックセット内の1つのRUが484トーンRUであることを示すために、予約済みビットシーケンスの値は第2の値であり、リソースブロックセット内の1つのRUが996トーンRUであることを示すために、予約済みビットシーケンスの値は第3の値であり、以下同様である。242トーンRU、484トーンRU、及び996トーンRUも異なるタイプのRUと見なされ得ることが理解されるべきである。

表1中、「01110001」は「242（0）として示される242トーンRUヌル（0ステーション）」を示す。この出願のこの実施形態では、予約済みビットシーケンスは、同様にRU（同じ）として示され得る。ここで、「RU」は、RUのタイプ、例えば、242トーンRU又は484トーンRUを示す。「同じ」リソースユニット割り当てフィールドを伝えるリソースブロック及び「同じ」リソースユニット割り当てフィールドを伝える別のリソースブロックが、1つのリソースブロックセットに割り当てられる。言い換えると、複数のリソースブロックは、1人のユーザ又はユーザの1つのグループに割り当てられる。ここでのリソースブロックは、242トーンリソースブロック以上のリソースブロックを示すことに留意すべきである。1つのリソースブロックセットが1つのSTAに割り当てられていることが示されている場合、予約済みビットシーケンスはRU（同じ、1）として示され得る。ここで、「1」は、リソースブロックセットが送信のために割り当てられるSTAの数を示す。シングルユーザパンクチャード送信シナリオでは、STAは1つしかない。例えば、表1では予約済みビットシーケンスは「111 x 4 x 3 x 2 x 1 x 0」である。この場合、「11100000」が242（同じ、1）として示され、「11100001」が484（同じ、1）として示され得る。

理解を容易にするために、図12を参照して、1つのリソースブロックセットが送信のために1つのSTA（図12のSTA1）に割り当てられることを示すべく、表1の予約済みビットシーケンスがこの出願のこの実施形態でどのように使用されるかを以下で説明する。図12は、80MHzを割り当てる概略図である。例えば、80MHz帯域幅は4つのサブチャネルに分割され、各サブチャネルは20MHzである又は242トーンRUと見なされ得る。左から右に、4つのサブチャネルの番号はそれぞれ1～4であり、4つのサブチャネルはそれぞれRU1、RU2、RU3、及びRU4として示される。

APは80MHzリソースを割り当てるため、PPDU内のHE－SIG－BフィールドはCC1及びCC2を含み、CC1は2つのリソースユニット割り当てフィールドを含み、CC2は2つのリソースユニット割り当てフィールドを含むことが理解されるべきである。4つのリソースユニット割り当てフィールドのそれぞれは、1つの予約済みビットシーケンスを伝える。

例えば、APによってSTAに割り当てられた複数のRUは不連続である。例えば、APは、RU1、RU3、及びRU4をSTA1に割り当てる、すなわち、80MHz帯域幅におけるRU2がパンクチャされる。言い換えると、この出願のこの実施形態において、シングルユーザ送信シナリオでは、不連続な帯域幅がサポートされ、すなわち、帯域幅における約20MHzをパンクチャできるようにされる。この場合、APは、STA1の送信のために使用される複数のRUに加えて、パンクチャされたRUを示す必要がある。

第1の例において、予約済みビットシーケンスは、割り当てられたリソースブロックセットに含まれる各RUのタイプ、及び、複数のRUが送信のために割り当てられるSTAの総数を示すために使用され得る。CCに含まれるリソース割り当て情報は、RU（同じ、1）と称され得る。RUがパンクチャされる場合、CCに含まれるリソース割り当て情報はRU（0）して示される。例えば、表1において、「01110001」は、242トーンRUがパンクチャされて242（0）として示されることを示す。

例えば、図12に示されるスペクトルリソースの場合、CH1、すなわち第1の242トーンRUは、242（同じ、1）を使用して示され得る。同様に、第2の242トーンRUは242（0）を使用して示され、第3の242トーンRUは242（同じ、1）を使用して示され、第4の242トーンRUは242（同じ、1）を使用して示され得る。同様に、802．11ax規格に記載されたCCについては、CC1に対して奇数番目のチャネルのリソース割り当て情報（すなわち、リソース割り当てテーブル内のmビットシーケンス）が設定され、CC2に対して偶数番目のチャネルのリソース割り当て情報が設定される。すなわち、CC1に対して第1の20Mを示す242（同じ、1）が設定され、CC2に対して第2の20Mを示す242（0）が設定され、CC1に対して第3の20Mを示す242（同じ、1）が設定され、CC2に対して第4の20Mを示す242（同じ、1）が設定される。言い換えると、RU1、RU3、及びRU4がSTA1に割り当てられ、RU2がパンクチャされ、RU1、RU3、及びRU4が全て242トーンRUであることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋242（同じ、1）であってもよく、また、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、1）であってもよい。

別の例として、RU1、RU3、及びRU4がSTA1に割り当てられ、RU2がパンクチャされ、RU1が242トーンRUであり、RU3及びRU4が両方とも484トーンRUであることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋484（同じ、1）であってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋484（同じ、1）であってもよい。この例では、RU3及びRU4は、連続しており、484トーンの分割粒度でSTA1に割り当てられる。これは前述の例とは異なる。この設計では、STA1は、CC1及びCC2を受信する。全ての割り当てられたRUは、CC1とCC2の両方を解釈する代わりに、CC1又はCC2のみを解釈することによって取得され得る。

シングルユーザパンクチャード送信シナリオでは、送信のために複数のRUが割り当てられるSTAの数はデフォルトで1であることが理解されるべきである。したがって、CC1に含まれるリソース割り当て情報は、242（同じ）＋242（同じ）であってもよく、また、CC2に含まれるリソース割り当て情報は、242（同じ）＋242（同じ）であってもよい。同様に、CC1に含まれるリソース割り当て情報は、484（同じ）＋484（同じ）であってもよく、また、CC2に含まれるリソース割り当て情報は、484（同じ）＋484（同じ）であってもよい。

シングルユーザパンクチャード送信シナリオでは、リソース割り当て情報をSTAに送信するときに、APは受信端の受信アドレスを示すことができる。受信アドレスは、STAの識別子、すなわち、関連付け識別子を伝えることができる。STAは、受信アドレスに基づいて、リソース指示情報がSTAに送信されるかどうかを決定することができるため、想定し得る形態において、CC1及びCC2は、リソースユニット割り当てフィールドに対応するユーザ情報フィールドを含まなくてもよく、又は、含まれるユーザ情報フィールドは、STAの識別子を含まなくてもよい。

当然ながら、別の想定し得る設計において、CC1及びCC2は、それぞれのリソースユニット割り当てフィールドに対応するユーザ情報フィールドも含み得る。例えば、CC1は、STA1のユーザ情報フィールドを含み、CC2も、STA1のユーザ情報フィールドを含む。STA1の識別子は、CC1内のユーザ情報フィールド及びCC2内のユーザ情報フィールドで伝えられ得る。例えば、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋242（同じ、1）及びSTA1のユーザ情報フィールドであってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、1）及びSTA1のユーザ情報フィールドであってもよい。この設計態様において、APはリソース割り当て情報を送信するときに指定された受信アドレスにSTAの識別子を付加しないが、STAは、CC1及びCC2内のユーザ情報フィールドを読み取ることによって、APによってSTAに割り当てられたRUを依然として決定することができる。

第1の例の別の実施において、第2の例では、予約済みビットシーケンスを使用して、割り当てられたリソースブロックセットに含まれる各RUのタイプ及びユーザ情報フィールドの数を示すことができる。CCに含まれるリソース割り当て情報は、RU（同じ、k）として示される。ここで、kは、ユーザ情報フィールドの数を示すために使用される。例えば、予約済みビットシーケンスの値は、リソースブロックセット内の1つのRUが242トーンRUであり且つユーザ情報フィールドの対応する数が特定の値であることを示すために第4の値であり、予約済みビットシーケンスの値は、リソースブロックセット内の1つのRUが484トーンRUであり且つ対応するユーザ情報フィールドの数が特定の値であることを示すために第5の値であり、以下同様であることが理解されるべきである。例えば、予約済みビットシーケンスの値は、リソースブロックセット内の1つのRUが242トーンRUであり且つユーザ情報フィールドの対応する数が特定の値、例えば1であることを示すに第4の値であることが理解されるべきである。例えば、予約済みビットシーケンスの値は、リソースブロックセット内の1つのRUが242トーンRUであり且つ対応するユーザ情報フィールドの数が特定の値、例えば2であることを示すために第5の値であることが理解されるべきである。受信ビットシーケンスの値は、リソースブロックセット内の1つのRUが484トーンRUであり且つユーザ情報フィールドの対応する数が特定の値、例えば1であることを示すために第12の値であり、以下同様である。

例えば、図12に示されるスペクトル帯域幅に対応して、RU1、RU3、及びRU4がSTA1に割り当てられることを示すために、CC1に含まれるリソース割り当て情報は242（同じ、1）＋242（同じ、0）及びSTA1のユーザ情報フィールドであってもよく、また、CC2に含まれるリソース割り当て情報は242（0）＋242（同じ、1）及びSTA1のユーザ情報フィールドであってもよい。RU2はパンクチャされる。RU1、RU3、及びRU4は、全て242トーンRUである。RU1に対応するユーザ情報フィールドの数は1である。RU2に対応するユーザ情報フィールドの数は0である。RU3に対応するユーザ情報フィールドの数は0である。RU4に対応するユーザ情報フィールドの数は1である。或いは、RU1、RU3、及びRU4がSTA1に割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、0）＋242（同じ、1）及びSTA1のユーザ情報フィールドであってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、1）及びSTA1のユーザ情報フィールドであってもよい。RU2はパンクチャされる。RU1、RU3、及びRU4は、全て242トーンRUである。RU1に対応するユーザ情報フィールドの数は0である。RU2に対応するユーザ情報フィールドの数は1である。RU3に対応するユーザ情報フィールドの数は0である。RU4に対応するユーザ情報フィールドの数は1である。

或いは、RU1、RU3、及びRU4がSTA1に割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋484（同じ、0）及びSTA1のユーザ情報フィールドであってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋484（同じ、1）及びSTA1のユーザ情報フィールドであってもよい。RU2はパンクチャされる。RU1は、242トーンRUである。RU3及びRU4は、484トーンRUを形成する。CC1に設定されてRU1に対応するユーザ情報フィールドの数は1である。CC2に設定されてRU2に対応するユーザ情報フィールドの数は0である。CC1に設定されてRU3に対応するユーザ情報フィールドの数は0である。CC2に設定されてRU4に対応するユーザ情報フィールドの数は1である。ユーザフィールドは、STA1の識別子を伝えてもよく、又は、STA1の識別子を伝えなくてもよい。

この出願のこの実施形態は、STA1がCC1及びCC2からSTA1の識別子を取得できることを条件として、STA1の識別子を伝える特定のユーザ情報フィールドを限定しないことを理解すべきである。

APが80MHz帯域幅を割り当てることは、前述の実施形態における一例としてのみ使用されることに留意すべきである。この出願のこの実施形態は、他の帯域幅、例えば、40MHz、160MHzにも適用可能であり、更には、現在の802．11axプロトコルに基づく漸進的変化によって得られる次世代プロトコル802．11beでサポートされる320MHz帯域幅にも適用可能であることを理解すべきである。差異は、CC1に含まれるリソース割り当て情報の異なる数である。例えば、160MHzの場合、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋242（同じ、1）＋242（同じ、1）＋242（同じ、1）であってもよく、CC2に含まれるリソース割り当て情報は、242（同じ、1）＋242（同じ、1）＋242（同じ、1）＋242（同じ、1）であってもよく、以下同様である。ここでは詳細は説明されない。

プリアンブル内の1つ以上のフィールドがシングルユーザパンクチャード送信を示す場合、テーブル内の242（1）を242（同じ、1）の変形として再利用して、242（1）ビットシーケンスに対応するRUが1つのSTAに割り当てられることを示すことができることに留意すべきである。同様に、484の変形（同じ、1）も484（1）として示され得る。或いは、テーブル内の484（1）は、484（1）ビットシーケンスに対応するRUが1つのSTAに割り当てられることを示すために再利用されてもよい。同様に、以下が更に含まれる。すなわち、996（同じ、1）に取って代わるために表1の996（1）が使用され、また、996＊2（同じ、1）に取って代わるために新たに付加された996＊2（1）が使用される。

図13は、この出願の一実施形態に係るダウンリンクシングルユーザパンクチャード送信方法を示す。方法は、以下のステップを含むことができる。

S1301．APはPPDUを生成する。PPDUのプリアンブルは、第1のフィールド及び第2のフィールドを含み得る。第1のフィールドは、送信されるべきPPDUがシングルユーザパンクチャされたPPDUであることを示すために用いられる。第2のフィールドは、複数のリソースユニット割り当てフィールドを含む。各リソースユニット割り当てフィールドは、第1のSTAに割り当てられたリソースブロックセット内の1つのRUを示すために使用される。

S1302．APは、PPDUを第1のSTAに送信する。

S1303．第1のSTAは、PPDUを受信し、割り当てられたリソースブロックセットに基づいてデータ情報を受信又は送信する。

第1のフィールドは前述のU－SIGフィールド内に位置されてもよいことが理解されるべきである。第1のフィールドは、前述の第1の指示情報を伝えるために使用される1つ以上のサブフィールドを含む。第1の指示情報をU－SIGフィールドに付加する具体的な態様については、前述の実施形態の説明を参照されたい。ここでは詳細を繰り返さない。第2のフィールドは、前述のEHT－SIGフィールドにおける共通フィールドであってもよい。第2のフィールドは、複数のリソースユニット割り当てフィールドを含む。各リソースユニット割り当てフィールドは、第1のSTAに割り当てられたリソースブロックセット内の1つのRUを示すために使用される前述の予約済みビットシーケンスを伝えることができる。確かに、パンクチャリング位置は、予約済みビットシーケンスを使用することによっても示される。具体的な実施については、シングルユーザパンクチャード送信シナリオにおける前述の実施形態を参照されたい。ここでは詳細を繰り返さない。

この出願の一実施形態は、全帯域幅MU－MIMOパンクチャード送信方法を更に提供する。この方法では、MIMO送信のために1つのリソースブロックセット（すなわち、複数のRU）がステーションの1つのグループ（複数のSTA）に割り当てられることを示すために、複数の予約済みビットシーケンスが使用され、これらの予約済みビットシーケンスは、周波数帯域幅がパンクチャされる特定の位置を示すために更に使用され得る。1つの予約済みビットシーケンスは、1つのリソースブロックセット内の1つのRUに対応する。STAのこのグループが全帯域幅MU－MIMO送信を実行するSTAであってもよいことを理解すべきである。同様に、このシナリオでは、リソース割り当て情報テーブル内の1つのmビットシーケンスが1つのRUを示す。RUは、n個のSTAに割り当てられたリソースブロックセット内の1つのRUであり、MU－MIMO送信を実行するためにn個のユーザによって使用される。例えば、リソース割り当て情報テーブル内の1つのmビットシーケンスは242トーンRUを示し、242トーンRUは、4つのSTAによって実行されるMU－MIMO送信のために4つのSTAに割り当てられる。簡潔にするために、mビットシーケンスは242（同じ、4）として示される。具体的には、mビットシーケンスは、1つの242トーンRUを示す。242トーンRUは、4つのSTAによって実行されるMU－MIMO送信のために4つのSTAに割り当てられたリソースブロックセット内の1つのRUである。

以下、図14を参照して、MIMO送信のために複数のRUがSTAの1つのグループに割り当てられることを示すために表1の予約済みビットシーケンスがこの出願の一実施形態においてどのように使用されるかを説明し、図14は、80MHzを割り当てる概略図である。例えば、80MHz帯域幅は4つのサブチャネルに分割され、各サブチャネルは20MHzである又は242トーンRUと見なされ得る。左から右に、4つのサブチャネルの番号はそれぞれ1～4であり、4つのサブチャネルはそれぞれRU1、RU2、RU3、及びRU4として示される。図14は、MIMO送信のために複数のRUがSTAの1つのグループ（STA1～STA4）に割り当てられることをAPが示す例を示す。この出願のこの実施形態では、複数のSTAの数が限定されないことを理解すべきである。

具体的には、第1の例において、予約済みビットシーケンスは、割り当てられたリソースブロックセットに含まれる各RUのタイプ及びリソースブロックセットが送信のために割り当てられるSTAの総数を示すために使用され得る。CCに含まれるリソース割り当て情報は、RU（同じ、n）として示される。ここで、nは、リソースブロックセットが送信のために割り当てられるSTAの総数を表わす。RUがパンクチャされる場合、CCに含まれるリソース割り当て情報はRU（0）して示される。例えば、表1において、「01110001」は、242トーンRUがパンクチャされて（0）として示されることを示す。

例えば、3つの不連続なRU（RU1、RU3、及びRU4）が送信のために4つのSTAに割り当てられ、RU2がパンクチャされ、RU1、RU3、及びRU4が全て242トーンRUであることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、4）＋242（同じ、4）であってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、4）であってもよい。

想定し得る設計では、各CCが2つのSTAのユーザ情報フィールドを含むことを理解すべきである。例えば、CC1に含まれるリソース割り当て情報は、242（同じ、4）＋242（同じ、4）、STA1のユーザ情報フィールド、及びSTA2のユーザ情報フィールドであってもよく、また、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、4）、STA3のユーザ情報フィールド、及びSTA4のユーザ情報フィールドであってもよい。

他の例として、3つの不連続なRU（RU1、RU3、及びRU4）が送信のために4つのSTAに割り当てられ、RU2がパンクチャリングされ、RU1が242トーンRUであり、RU3及びRU4が484トーンRUを形成することを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、4）＋484（同じ、4）であってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋484（同じ、4）であってもよい。この例では、RU3及びRU4は、連続しており、484トーンの分割粒度でSTA1に割り当てられる。これは前述の例とは異なる。この設計では、STA1は、CC1及びCC2を受信する。割り当てられたRUは、CC1とCC2の両方を解釈する代わりに、より大きなリソースブロックを形成するべくCC1又はCC2のみを解釈することによって取得され得る。

第1の例の別の実施において、第2の例では、予約済みビットシーケンスを使用して、割り当てられたリソースブロックセットに含まれる各RUのタイプ及びユーザ情報フィールドの数を示すことができる。CCに含まれるリソース割り当て情報は、RU（同じ、k）として示される。ここで、kはユーザ情報フィールドの数である。

例えば、3つの不連続なRU（RU1、RU3、及びRU4）が送信のために4つのSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、1）＋242（同じ、1）であってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋242（同じ、2）であってもよい。RU2はパンクチャされる。RU1、RU3、及びRU4は、全て242トーンRUである。CC1に設定されてRU1に対応するユーザ情報フィールドの数は1である。CC2に設定されてRU2に対応するユーザ情報フィールドの数は1である。CC1に設定されてRU3に対応するユーザ情報フィールドの数は0である。CC2に設定されてRU4に対応するユーザ情報フィールドの数は2である。

或いは、3つの不連続なRU（RU1、RU3、及びRU4）が送信のために4つのSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、2）＋484（同じ、0）であってもよく、CC2に含まれるリソース割り当て情報は、242（0）＋484（同じ、2）であってもよい。RU2はパンクチャされる。RU1は、242トーンRUである。RU3及びRU4は、484トーンRUを形成する。CC1に設定されてRU1に対応するユーザ情報フィールドの数は2である。CC2に設定されてRU2に対応するユーザ情報フィールドの数は0である。CC1に設定されてRU3に対応するユーザ情報フィールドの数は0である。CC2に設定されてRU4に対応するユーザ情報フィールドの数は2である。

想定し得る設計では、各CCが2つのSTAのユーザ情報フィールドを含むことを理解すべきである。例えば、CC1及びCC2は、STA1及びSTA2のユーザ情報フィールドを含み、CC2は、STA3及びSTA4のユーザ情報フィールドも含む。

第1の例及び第2の例の別の実施では、予約済みビットシーケンスを使用して、242（同じ）、484（同じ）、996（同じ）、及び996＊2（同じ）を含む割り当てられたリソースブロックセットに含まれる各RUのタイプを示すことができる。ここで、n又はkを加える必要はない。言い換えると、第1の例の場合、複数のRUが送信のために割り当てられるSTAの総数は、他のシグナリングを使用して示されてもよく、また、第2の例の場合、2つのCCのユーザ情報フィールドの総数は、複数のRUが送信のために割り当てられるSTAの総数である。例えば、APは、第2の指示情報を使用して、複数のRUが送信のために割り当てられるSTAの総数、又は、ユーザ情報フィールドの数を示す。第2の指示情報の実施については、前述の実施形態における第1の指示情報の実施を参照されたい。ここでは詳細は説明されない。

想定し得る設計において、第2の指示情報は、PPDUの第1のフィールドで伝えられ得る。第1のフィールドは、PPDU内のEHT－SIGフィールドの共通フィールドの前に位置されてもよく、例えば、U－SIGフィールド又は他の想定し得るフィールドであってもよい。例えば、U－SIGフィールドは、複数のビットを占有する。複数のビットの幾つかは、割り当てにおけるSTAの総数n又はユーザ情報フィールドの数kを示すために使用される。

APが例えば16個のSTAとの同時通信をサポートできる場合、すなわち、nの値の範囲が［1，16］であり、少なくとも4つのタイプのRUがある場合には、表1に示される予約済みビットシーケンスが明らかに全てのケースを示すことができないことを理解すべきである。したがって、この出願のこの実施形態において、使用されるビットシーケンスは、8ビットよりも多い、例えば9ビットを占有し得る。例えば、APが予約済みビットシーケンスを使用して複数のRUを16個のSTAに割り当てることを実施するために、表1の予約済みビットシーケンスが使用され、予約済みビットシーケンスが9ビットを占有する。言い換えると、この出願のこの実施形態におけるmは8以上である。

他の別の実施態様では、この出願のこの実施形態における第1の指示情報が全帯域幅MU－MIMOパンクチャード送信シナリオを示すために使用される場合、この出願のこの実施形態における他の指示情報は、1つのリソースブロックセットが送信のために複数のSTAに割り当てられることを示すとともに、スペクトル帯域幅がパンクチャされる位置を示すために更に使用され得る。指示情報は、例えば、PPDU内のEHTフィールドの共通フィールドで伝えられ得る。例えば、帯域幅パンクチャリングビットマップを示すために共通フィールド内に1つのフィールドが新たに規定されてもよい。例えば、80MHz帯域幅の場合、フィールドが4ビットを占有し得る。言い換えると、この出願のこの実施形態では、特定のパンクチャされた20MHzを示すために4ビット帯域幅パンクチャリングビットマップが使用され得る。例えば、フィールドの値「1011」は、第2の20MHzがパンクチャされることを示してもよく、また、「1111」は、80MHzがパンクチャされないことを示してもよい。或いは、例えば、320MHz帯域幅の場合、フィールドは、15ビット又は16ビットを占有し得る。或いは、フィールドによって占有されるビット数は固定され、すなわち、数は帯域幅に伴って変化しない。例えば、フィールドによって占有されるビットの数は、最大帯域幅に含まれる20Mの数、例えば16ビットである。フィールドは、複数のRUを複数のSTAに割り当てることを実施するとともに複数の不連続なRUの割り当てをサポートするために使用され得る。

帯域幅パンクチャリングビットマップは、低周波数から高周波数までの複数の20MHzが帯域幅内でアイドルであるかどうかを示すために、利用可能なチャネルビットマップと置き換えることもできることを理解すべきである。例えば、対応する20MHzがアイドルであることを示すために、利用可能なチャネルビットマップに関して第1の値、例えば1が設定され、対応する20MHzがビジーであることを示すために、利用可能なチャネルビットマップに関して第2の値、例えば0が設定される。加えて、利用可能なチャネルビットマップは、高周波から低周波までの複数の20MHzが帯域幅内でアイドルであるかどうかも示すことができる。

APがプリアンブル内の1つ以上のフィールドを用いてシングルユーザパンクチャード送信を指示する場合、表1中の242（1）を242（同じ、1）の変形として再利用して、242（1）ビットシーケンスに対応するRUが1つのSTAに割り当てられることを示すことができることに留意すべきである。同様に、表1中の484（1）は、242（1）ビットシーケンスに対応するRUが1つのSTAに割り当てられることを示すために、484（同じ、1）の変形として再利用され得る。同様に、表1中の996（1）は、996（同じ、1）に取って代わるために再利用され、新たに付加された996＊2（1）は、996＊2（同じ、1）に取って代わるために再利用される。

図15は、この出願の一実施形態に係るダウンリンク全帯域幅MU－MIMOパンクチャード送信方法を示す。方法は、以下のステップを含むことができる。

S1501．APはPPDUを生成する。PPDUのプリアンブルは、第1のフィールド及び第2のフィールドを含み得る。第1のフィールドは、送信されるべきPPDUがシングルユーザパンクチャされたPPDUであることを示すために用いられる。第2のフィールドは、複数のリソースユニット割り当てフィールドを含む。各リソースユニット割り当てフィールドは、STAの1つのグループに割り当てられたリソースブロックセット内の1つのRUを示すために使用される。

S1502．APはPPDUを送信する。

S1503．STAのグループはPPDUを受信する。STAのグループのそれぞれは、割り当てられたリソースブロックセットに基づいてデータ情報を受信又は送信する。

第1のフィールドは、第1の指示情報を伝えるために使用される前述のU－SIGフィールドであってもよいことが理解されるべきである。第1の指示情報をU－SIGフィールドに付加する具体的な態様については、前述の実施形態の説明を参照されたい。ここでは詳細を繰り返さない。或いは、この出願のこの実施形態がダウンリンク全帯域幅MU－MIMOパンクチャード送信シナリオで特に適用される場合、PPDUは、APがダウンリンク全帯域幅MU－MIMO送信を実行する必要があるときに生成され得る。PPDUのプリアンブルは、ユーザのグループがダウンリンク全帯域幅MU－MIMOパンクチャード送信を実行することを示す。これは、シングルユーザパンクチャード送信シナリオと同様である。具体的な方法は以下の通りである。すなわち、U－SIGフィールドのPPDUフォーマットフィールド内の1つの値がマルチユーザ送信を示し、パンクチャリングフィールド又は帯域幅フィールド内の1つ以上の値がパンクチャード送信を示す。帯域幅フィールドによって示されるパンクチャード送信方法は、802．11axと同様である。帯域幅フィールドの幾つかの値は、パンクチャされた帯域幅を示す。例えば、第5の値はパンクチャード方式1における80Mを示し、第6の値はパンクチャード方式2における80M帯域幅を示す。2つの値のうちの1つがパンクチャリングを示し得る。

U－SIGフィールドは、圧縮フィールドを更に含む。圧縮フィールドが第1の値、例えば1に設定される場合、それは、EHT SIGフィールドの共通フィールドのリソースユニット割り当てフィールド又は帯域幅パンクチャリングビットマップ／利用可能チャネルビットマップが存在しないことを示す。圧縮フィールドが第1の値に設定され、指示情報が非パンクチャリングを示す際には、この場合、U－SIGフィールド又は他のフィールドに位置されてHE－SIG A内の「HE－SIG－Bシンボル又はマルチユーザ多入力多出力ステーションの数」と同様のサブフィールドは、マルチユーザ多入力多出力ステーションの数を示す。

圧縮フィールドが第2の値、例えば0に設定される場合、それは、EHT SIGフィールドの共通フィールドのリソースユニット割り当てフィールド又は帯域幅パンクチャリングビットマップ／利用可能チャネルビットマップが存在することを示す。圧縮フィールドが第2の値に設定され、指示情報が非パンクチャリングを示す際には、この場合、U－SIGフィールド又は別のフィールドに位置されて表2のHE－SIG A内の「HE－SIG－Bシンボル又はマルチユーザ多入力多出力ステーションの数」と同様のサブフィールドは、EHT－SIGフィールド内のOFDMシンボルの数を示す。圧縮フィールドが第2の値に設定され、指示情報がパンクチャリングを示す際には、この場合、U－SIGフィールド又は別のフィールドに位置されてHE－SIG A内の「HE－SIG－Bシンボル又はマルチユーザ多入力多出力ステーションの数」と同様のサブフィールドは、マルチユーザ多入力多出力ステーションの数を示す。

第2のフィールドは、前述のEHT－SIGフィールドにおける共通フィールドであってもよい。第2のフィールドは、複数のリソースユニット割り当てフィールドを含む。各リソースユニット割り当てフィールドは、STAのグループに割り当てられたリソースブロックセット内の1つのRUを示すために使用される前述の予約済みビットシーケンスを伝えることができる。確かに、パンクチャリング位置は、予約済みビットシーケンスを使用することによっても示される。具体的な実施については、シングルユーザパンクチャード送信シナリオにおける前述の実施形態を参照されたい。ここでは詳細を繰り返さない。

想定し得る適用シナリオ、例えば、ダウンリンクOFDMA PPDU送信シナリオにおいて、この出願のこの実施形態では、リソース割り当て情報テーブル内の予約済みビットシーケンスが、242トーンRU以上の複数のRUがデータ送信のために単一のステーション又はステーションのグループに割り当てられることを示すために使用され得る。ステーションのグループの場合、ステーションのグループは、242トーンRU以上の複数のRUに対してMU－MIMO送信を実行する。

図16を参照すると、この出願の一実施形態では、異なるステーションに割り当てられた複数のRUに含まれる周波数帯域間で重複が許容されないことが想定されることに留意すべきである。図16は、160MHzを割り当てる概略図である。図16では、例えば、160MHz帯域幅が8つのサブチャネルに分割され、各サブチャネルは242トーンRUである。左から右へ、8つのサブチャネルの番号はそれぞれCH1～CH8であり、8つのサブチャネルはそれぞれRU1、RU2、RU3、RU4、RU5、RU6、RU7、及びRU8として示される。RU2及びRU6はパンクチャされる。異なるステーションに割り当てられる複数のRUの周波数帯域範囲間で重複は許容されない。具体的には、図14に示されるように、2つのステーションにリソースが割り当てられる。RU1、RU3、及びRU4が1つのステーションに割り当てられてもよく、また、RU5、RU7、及びRU8が他のステーションに割り当てられてもよい。しかしながら、RU1及びRU5を一方のステーションに割り当て、RU3、RU4、RU7、及びRU8を他方のステーションに割り当てることは許容されない。この出願のこの実施形態は、ステーションに割り当てられる複数のRUに含まれる周波数帯域間に重複が存在する場合に使用されてもよいことが理解されるべきである。この場合、複数のRUを同じステーションに割り当てるモードは限定されるが無作為ではない。

この出願のこの実施形態では、異なるステーションに割り当てられる複数のRU間で重複が許容されないため、この出願のこの実施形態では、複数の割り当てられたRUにおける同じSTAに割り当てられる特定のRUを示すために、最後の割り当てられたRUがSTAに対して示され得る。言い換えると、この出願のこの実施形態では、以下が示され得る。すなわち、割り当てられたRUは、STAに割り当てられた複数のRUに属する最後のRUである。或いは、STAに割り当てられた複数のRUにおける最後のRUは、異なるSTAに割り当てられたRU間を区別するための識別子として使用されてもよいと考えられ得る。言い換えると、最後のRUは前のSTAの最後のRUに属するが、最後のRUに続く最初のRUは現在のSTAに割り当てられる。

想定し得る実施では、割り当てられたリソースブロックセット内の各RUのタイプに加えて、予約済みビットシーケンスは、第3の指示情報、及び、242トーンRU以上の複数のRUが送信のために割り当てられるステーションの総数を更に示すことができる。第3の指示情報は、STAに割り当てられた複数のRUにおける最後のRUを示すために使用される。

第3の指示情報は、第1の識別情報及び第2の識別情報を含み得る。第1の識別情報及び第2の識別情報の変更は、前のSTAの最後のRUを示すことができる。言い換えると、第1の識別情報及び第2の識別情報の変更は、異なるSTAに割り当てられたRUの周波数境界を示す。例えば、1つのリソースユニット割り当てサブフィールドに含まれるリソース割り当て情報は、RU（同じ、A、n）として示されてもよい。ここで、「RU」は、RUのタイプ、例えば、242トーンRU又は484トーンRUを示し、「同じ」は、リソースユニット割り当てサブフィールドで伝えられる予約済みビットシーケンスが同じであることを意味し、「A」は、第1の識別情報を示し、「n」は、242トーンRU以上の複数のRUが送信のために割り当てられるステーションの総数を示す。「A」が第1のSTAの複数のRUにおける最後のRUを示す場合、第2の識別情報「B」は、第2のSTAの複数のRUにおける最後のRUを示すために使用され得ることを理解すべきである。言い換えると、CC内の1つのリソースユニット割り当てフィールドに含まれるリソース割り当て情報は、RU（同じ、B、n）として示されてもよい。RU（x、y、z）において、RUはサイズを表わし、xは同じを表わし、yはA又はBを表わし、zはnを表わすことに留意すべきである。ここで、RU（x、y、z）は、1つのパラメータが異なる限り、1つの予約済みビットシーケンスを用いて示される必要がある。

別の実施態様では、割り当てられたRUのタイプに加えて、予約済みビットシーケンスは、242トーンRU以上の複数のRUが送信のために割り当てられるステーションのユーザ情報フィールドの総数及び第3の指示情報を更に示すことができる。例えば、1つのリソースユニット割り当てサブフィールドに含まれるリソース割り当て情報は、RU（同じ、A、k）又はRU（同じ、B、k）として示されてもよい。ここで、kはユーザ情報フィールドの数である。これは前述の実施形態と同様である。

以下、理解を容易にするために、図17及び図18を参照して、242トーンRU以上の複数のRUがデータ送信のために割り当てられる1つ以上のSTAをAPがどのように示すかについて説明する。

図17は、160MHzを割り当てる概略図である。例えば、160MHz帯域幅が8つのサブチャネルに分割され、各サブチャネルは242トーンRUである。左から右へ、8つのサブチャネルの番号はそれぞれCH1～CH8であり、8つのサブチャネルはそれぞれRU1、RU2、RU3、RU4、RU5、RU6、RU7、及びRU8として示される。RU2及びRU6は、複数の小さいリソースブロックに分割される。APが、RU1、RU3、及びRU4をSTA1に割り当てるとともにRU5、RU7、及びRU8をSTA2に割り当てると仮定する。STA1及びSTA2は、160MHz帯域幅でシングルユーザ送信を行なう。RU2及びRU6は、他のSTAに割り当てられてもよい。

第1の例において、予約済みビットシーケンスは、割り当てられたリソースブロックセットに含まれる各RUのタイプ、第3の指示情報、及び、242トーンRU以上の複数のRUが送信のために割り当てられるSTAの総数を示すために使用され得る。CCに含まれるリソース割り当て情報は、RU（同じ、A又はB、1）として示され得る。

例えば、同じビットシーケンスに対応するRUが同じSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋242（同じ、A、1）＋242（同じ、B、1）＋242（同じ、B、1）であってもよく、CC2に含まれるリソース割り当て情報は、X＋242（同じ、A、1）＋Y＋242（同じ、B、1）であってもよい。A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。242トーンRU以上の複数のRUが送信のために割り当てられるSTAの総数は1であるため、CC1は、STA1の1つのユーザ情報フィールド及びSTA2の1つのユーザ情報フィールドを含むことができ、また、CC2は、STA1の1つのユーザ情報フィールド及びSTA2の1つのユーザ情報フィールドを含むことができる。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

或いは、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋484（同じ、A、1）＋242（同じ、B、1）＋484（同じ、B、1）であってもよく、CC2に含まれるリソース割り当て情報は、X＋484（同じ、A、1）＋Y＋484（同じ、B、1）であってもよく、同じビット列に対応するRUが同じSTAに割り当てられることを示す。A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。CC1は、STA1の1つのユーザ情報フィールド及びSTA2の1つのユーザ情報フィールドを含むことができ、CC2は、STA1の1つのユーザ情報フィールド及びSTA2の1つのユーザ情報フィールドを含むことができることを理解すべきである。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

第1の例の別の実施において、予約済みビットシーケンスは、割り当てられたRUのタイプ、第3の指示情報、及び、242トーンRU以上の複数のRUが送信のために割り当てられるSTAのユーザ情報フィールドの総数を示すために使用されてもよい。CCに含まれるリソース割り当て情報は、RU（同じ、A又はB、k）として示され得る。kの値は0又は1であることを理解すべきである。ここで、RU（同じ、A又はB、0）は、CCに含まれるリソースビットシーケンスに対応するユーザ情報フィールドの数が0であることを更に示すことができ、また、RU（同じ、A又はB、1）は、CCに含まれるリソースビットシーケンスに対応するユーザ情報フィールドの数が1であることを更に示すことができる。

この場合、同じビットシーケンスに対応するRUが同じSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋242（同じ、A、0）＋242（同じ、B、0）＋242（同じ、B、0）であってもよく、また、CC2に含まれるリソース割り当て情報は、X＋242（同じ、A、0）＋Y＋242（同じ、B、1）であってもよい。A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。この場合、CC1は、STA1のユーザ情報フィールドを含んでもよく、また、CC2は、STA2のユーザ情報フィールドを含んでもよい。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

或いは、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋484（同じ、A、0）＋242（同じ、B、0）＋484（同じ、B、0）であってもよく、また、CC2に含まれるリソース割り当て情報は、X＋484（同じ、A、0）＋Y＋484（同じ、B、1）であってもよい。CC1はSTA1のユーザ情報フィールドを含むことができ、CC2はSTA2のユーザ情報フィールドを含むことができることを理解すべきである。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

図18は、160MHzを割り当てる概略図である。例えば、160MHz帯域幅が8つのサブチャネルに分割され、各サブチャネルは242トーンRUである。左から右へ、8つのサブチャネルの番号はそれぞれCH1～CH8であり、8つのサブチャネルはそれぞれRU1、RU2、RU3、RU4、RU5、RU6、RU7、及びRU8として示される。RU2及びRU6は、複数の小さいリソースブロックに分割される。APが、RU1、RU3、及びRU4をSTA1に割り当てるとともに、RU5、RU7、及びRU8をSTA2、STA3、STA4、及びSTA5の4つのSTAに割り当てると仮定する。STA1～STA4は、160MHz帯域幅で全帯域幅MU－MIMO送信を行なう。

第1の例において、予約済みビットシーケンスは、割り当てられたリソースブロックセットに含まれる各RUのタイプ、第3の指示情報、及び、242トーンRU以上の複数のRUが送信のために割り当てられるSTAの総数を示すために使用され得る。この場合、CCに含まれるリソース割り当て情報は、RU（同じ、A又はB、n）として示され得る。

例えば、同じビットシーケンスに対応するRUが同じSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋242（同じ、A、1）＋242（同じ、B、4）＋242（同じ、B、4）であってもよく、CC2に含まれるリソース割り当て情報は、X＋242（同じ、A、0）＋Y＋242（同じ、B、0）であってもよい。A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。この場合、CC1は、STA1～STA5のユーザ情報フィールドを含み、また、CC2は、CH2及びCH6に対応するユーザ情報フィールドを含む。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

或いは、同じビットシーケンスに対応するRUが同じSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋484（同じ、A、1）＋242（同じ、B、4）＋484（同じ、B、4）であってもよく、CC2に含まれるリソース割り当て情報は、X＋484（同じ、A、0）＋Y＋484（同じ、B、0）であってもよく、A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。この場合、CC1は、STA1～STA5のユーザ情報フィールドを含み、また、CC2は、CH2及びCH6に対応するユーザ情報フィールドを含む。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

第1の例の別の実施において、予約済みビットシーケンスは、割り当てられたリソースブロックセットに含まれる各RUのタイプ、第3の指示情報、及び、242トーンRU以上の複数のRUが送信のために割り当てられるSTAのユーザ情報フィールドの総数を示すために使用されてもよい。CCに含まれるリソース割り当て情報は、RU（同じ、A又はB、k）として示され得る。kの値は0－5であることを理解すべきである。例えば、RU（同じ、A又はB、0）は、CCに含まれるリソースビットシーケンスに対応するユーザ情報フィールドの数が0であることを更に示すことができ、また、RU（同じ、A又はB、1）は、CCに含まれるリソースビットシーケンスに対応するユーザ情報フィールドの数が1であることを更に示すことができる。

この場合、同じビットシーケンスに対応するRUが同じSTAに割り当てられることを示すために、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋242（同じ、A、0）＋242（同じ、B、0）＋242（同じ、B、5）であってもよく、CC2に含まれるリソース割り当て情報は、X＋242（同じ、A、0）＋Y＋242（同じ、B、0）であってもよい。A及びBの変更は、STA1の複数のRUにおける最後のRUである特定のRUを示す。この場合、CC1は、STA1～STA5のユーザ情報フィールドを含み、また、CC2は、CH2及びCH6に対応するユーザ情報フィールドを含む。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

或いは、CC1に含まれるリソース割り当て情報は、242（同じ、A、1）＋484（同じ、A、0）＋242（同じ、B、0）＋484（同じ、B、5）であってもよく、また、CC2に含まれるリソース割り当て情報は、X＋484（同じ、A、0）＋Y＋484（同じ、B、1）であってもよい。CC1は、STA1～STA5のユーザ情報フィールドを含み、CC2は、CH2及びCH6に対応するユーザ情報フィールドを含むことを理解すべきである。ここで、X及びYは、20MHzを分割することによって得られる複数の小さいリソースブロックを別々に示す。これは、802．11ax規格を使用して具体的に示すことができ、すなわち、表1の現在規定されるビットシーケンスを使用して示すことができる。

この出願の一実施形態は、STAのアップリンクデータ送信のために使用される情報指示方法を更に提供する。アップリンクマルチユーザデータ送信シナリオでは、複数のSTAがアップリンクデータ情報を同時に送信する必要があるとき、APは、最初に、マルチユーザデータ送信に関与する各STAにトリガフレームを送信してトリガフレーム内の各STAに割り当てられたRUを示す。その後、トリガフレームを受信した後、各STAは、応答として、アップリンクOFDMAフレーム、又はMU－MIMOフレーム、又はOFDMAとMU－MIMOとのハイブリッドフレームを送信する。その後、APは、受信したアップリンクOFDMAフレーム、又は受信したMU－MIMOフレーム、又はOFDMAとMU－MIMOの受信したハイブリッドフレームに基づいて確認応答フレームを送信して、各STAをトリガし、APによって割り当てられたRUでアップリンクデータ情報を送信することができる。

トリガフレームの構造が図19に示される。この構造は、フレーム制御フィールド、持続時間フィールド、受信アドレスフィールド、送信アドレスフィールド、共通情報フィールド、ユーザ情報リストフィールド、パディングフィールド、及び、フレームチェックシーケンスフィールドを含む。共通情報フィールド及びユーザ情報リストフィールドは、前述のダウンリンクマルチユーザ送信におけるHE－SIG Bの共通フィールド及び複数のユーザ情報フィールドと同様である。例えば、共通情報フィールドは、トリガタイプフィールド、アップリンク長フィールド、更なるトリガフレームフィールド、キャリアセンス必要フィールド、帯域幅フィールド、及びトリガフレームタイプに基づく共通情報フィールドを含む。

図20に示されるように、ユーザ情報フィールドは、関連付け識別子フィールド、リソースユニット割り当てフィールド、アップリンク符号化タイプフィールド、アップリンク変調符号化方式フィールド、アップリンクデュアルキャリア変調フィールド、空間ストリーム割り当て又はランダムアクセスリソースユニット情報フィールド、アップリンク受信信号強度指示フィールド、予約済みフィールド、及びトリガフレームタイプに基づくユーザ情報リストフィールドを含んでもよい。

この出願のこの実施形態において、複数のSTAは、不連続な帯域幅で全帯域幅マルチユーザMU－MIMO送信を実行できるようにされる。この場合、802．11axにおけるアップリンクトリガフレームスケジューリング方法が依然として使用される場合、幾つかの不連続なRUでMU－MIMO送信に繰り返し関与する必要がある全てのユーザのユーザ情報フィールドの数は、比較的高いシグナリングオーバーヘッドで増大する。図12が一例として使用される。アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信シナリオでは、トリガフレームは、20M（RU1）及び40M（484トーンのリソースブロックに対応する、RU3及びRU4）での送信におけるSTA1～STA4のユーザ情報フィールドを含む必要がある。合計8つのユーザ情報フィールドが含まれる必要がある。

これを考慮して、この出願の一実施形態は、パンクチャされた帯域幅に起因する複数の不連続なリソースブロックに対応するMU－MIMOユーザグループの情報の繰り返し送信を回避するために、アップリンクマルチユーザMU－MIMOパンクチャード送信のために使用されるトリガフレームの新たな構造を提供し、それによってシグナリングオーバーヘッドを低減する。

想定し得る設計では、トリガフレームのトリガタイプフィールドに新たなタイプ、すなわち、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信を付加することができる。

例えば、図19に示されるトリガタイプフィールドは、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信も示し得る。トリガタイプフィールドは複数のビットを含むことを理解すべきである。トリガタイプフィールド内の1つの値は、トリガフレームがアップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信をトリガするために使用されることを示すために使用される。

他の想定し得る設計では、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信を示すために、トリガフレームの共通情報フィールドにフィールドを付加することができる。

例えば、図19に示されるトリガフレームの共通情報フィールドで、フィールド、例えば第1のフィールドが新たに規定される。第1のフィールドは、1つ以上のビットを占有し得る。第1のフィールドの値は、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信を示すために、第1の値（例えば、1）である。第1のフィールドの値は、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信がないことを示すために、第2の値（例えば、0）である。

加えて、図20に示されるトリガフレームにおけるユーザ情報フィールド内のリソースユニット割り当てフィールドは、帯域幅パンクチャリングビットマップフィールドと置き換えられてもよい。言い換えると、リソースユニット割り当てフィールドは、帯域幅内の低周波数から高周波数までの各20MHzがパンクチャされるかどうか又はプライマリ20MHzチャネルを除く帯域幅内の低周波数から高周波数までの各20MHzがパンクチャされるかどうかを示すために使用される。例えば、80MHz帯域幅の場合、リソースユニット割り当てフィールドは4ビットを占有することができる。言い換えると、この出願のこの実施形態では、特定のパンクチャされた20MHzを示すために4ビット帯域幅パンクチャリングビットマップが使用され得る。例えば、フィールドの値「1011」は、第2の20MHzがパンクチャされることを示してもよく、また、「1111」は、80MHzがパンクチャされないことを示してもよい。或いは、例えば、320MHz帯域幅の場合、リソースユニット割り当てフィールドは、15ビット（プライマリ20MHzを除く各20MHz）又は16ビット（各20MHz）を占有してもよい。或いは、リソースユニット割り当てフィールドによって占有されるビットの数は固定され、すなわち、数が帯域幅に伴って変化しない。例えば、リソースユニット割り当てフィールドによって占有されるビットの数は、最大帯域幅に含まれる20Mの数、例えば16ビットである。リソースユニット割り当てフィールドは、複数のRUを1つ以上のSTAに割り当てることを実施するとともに複数の不連続なRUの割り当てをサポートするために使用することができる。

他の想定し得る実施において、帯域幅パンクチャリングビットマップフィールドは、帯域幅内の低周波数から高周波数までの特定の利用可能な20MHz又はプライマリ20MHzチャネルを除く帯域幅内の低周波数から高周波数までの特定の利用可能な20MHzを示すために、利用可能なチャネルビットマップと置き換えられる。

図21は、この出願の一実施形態に係るアップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信方法を示す。方法は、以下のステップを含むことができる。

S2101．APはトリガフレームを生成する。トリガフレームは、第1のフィールド及び第2のフィールドを含む。第1のフィールドは、アップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信をスケジュールするためにトリガフレームが使用されることを示すために使用される。第2のフィールドは、複数のSTAの識別子を示すために使用される。

S2102．APはトリガフレームを送信する。

S2103．STAのグループのそれぞれは、トリガフレームを受信する。各STAは、割り当てられたリソースブロックセットに基づいてアップリンクデータ情報を送信する。

S2104．APは、1つ以上のSTAによって送信されたアップリンクマルチユーザ送信に関する情報を受信し、確認応答情報をフィードバックする。

第1のフィールドは、トリガフレームの共通情報フィールドであってもよい。第2のフィールドは、ユーザ情報フィールドであってもよい。具体的な実施については、前述の実施形態の説明を参照されたい。トリガフレームの共通情報フィールドは、アップリンク長フィールド、更なるトリガフレームフィールド、キャリアセンス必要フィールド、及び帯域幅フィールドのうちの1つ以上、帯域幅パンクチャリングビットマップフィールド又は利用可能チャネルビットマップなどを更に含むことを理解すべきである。共通情報フィールドは、アップリンク符号化タイプフィールド、アップリンク変調符号化方式フィールド、アップリンクデュアルキャリア変調フィールド、空間ストリーム割り当て又はランダムアクセスリソースユニット情報フィールド、及びアップリンク受信信号強度指示フィールドのうちの1つ以上を更に含む。

ステップS2104において、各STAは、所定間隔後にアップリンクマルチユーザ送信を送ることを理解すべきである。所定間隔はSIFS時間である。アップリンクマルチユーザ送信は、アップリンクMU－MIMO送信である。ステップS2104において、確認応答情報は、ダウンリンクOFDMA確認応答、又はマルチユーザブロック確認応答であってもよい。

この出願における前述の解決策において、リソース割り当て情報テーブル内のビットシーケンスは、1つのSTAに割り当てられたリソースブロックセット、又は複数のSTAに割り当てられたリソースブロックセットを示すために使用され得る。1つのビットシーケンスは、リソースブロックセット内の1つのRUに対応する。

この出願の前述の実施形態において、この出願の実施形態で提供される方法は、AP、STA、及びAPとSTAとの間の相互作用の観点から別々に説明される。この出願の実施形態において提供される方法で機能を実現するために、ネットワークデバイス及び端末は、ハードウェア構造、ソフトウェアモジュール、又はハードウェア構造とソフトウェアモジュールとの組み合わせの形態で機能を実現するべく、ハードウェア構造及び／又はソフトウェアモジュールを含み得る。複数の機能における1つの機能がハードウェア構造、ソフトウェアモジュール、又はハードウェア構造とソフトウェアモジュールとの組み合わせの態様で実現されるかどうかは、技術的解決策の特定の用途及び設計制約条件に依存する。

以下、添付図面を参照して、この出願の実施形態における前述の方法を実施するための通信装置について説明する。したがって、前述の内容は、後続の実施形態で全て使用されてもよい。繰り返される内容は再び記載されない。

図22は、通信装置の構造の概略図である。通信装置は、AP側に適用される装置であってもよく、又は、AP側に適用される装置における構成要素（例えば、チップ又は回路）であってもよい。通信装置は、前述の方法の実施形態においてAPによって実現される機能を果たすように構成される。図22に示されるように、通信装置は、処理モジュール2201及びトランシーバモジュール2202を含むことができる。

幾つかの実施形態において、処理モジュール2201は、リソース指示情報を決定するように構成される。リソース指示情報は複数のビットシーケンスを含む。複数のビットシーケンスにおける第1のビットシーケンスは、第1のリソースユニットに対応する。第1のリソースユニットは、第1のSTA又は複数のSTAに割り当てられるリソースブロックセットにおけるリソースユニットである。リソースブロックセットは少なくとも2つのリソースユニットを含む。

トランシーバモジュール2202は、リソース指示情報を送信するように構成される。

幾つかの他の実施形態において、処理モジュール2201は、第1の指示情報を生成するように構成される。第1の指示情報は、複数のSTAが不連続帯域幅で全帯域幅マルチユーザMU－MIMO送信を実行することを示すために使用される。

トランシーバモジュール2202は、第1の指示情報を送信するように構成される。

通信装置が前述の方法におけるAPであり、通信装置が前述の方法におけるAPの任意の機能を有することを理解すべきである。

以上は、この出願のこの実施形態における通信装置について説明する。以下は、通信装置の想定し得る製品形態について説明する。図22に記載される通信装置の機能を有する任意の形態の任意の製品がこの出願の実施形態の保護範囲内に入ることを理解すべきである。以下の説明は、単なる一例であり、この出願のこの実施形態における通信装置の製品形態がそれに限定されることを示すものでないことを更に理解すべきである。

想定し得る製品形態において、この出願のこの実施形態における通信装置は、一般的なバスシステム構造を使用して実装され得る。

通信装置は、プロセッサと、プロセッサに内部接続されてプロセッサと通信するトランシーバとを含む。幾つかの実施形態において、プロセッサは、リソース指示情報を決定するように構成される。リソース指示情報は複数のビットシーケンスを含む。複数のビットシーケンスにおける第1のビットシーケンスは、第1のリソースユニットに対応する。第1のリソースユニットは、第1のSTA又は複数のSTAに割り当てられるリソースブロックセットにおけるリソースユニットである。リソースブロックセットは少なくとも2つのリソースユニットを含む。トランシーバは、リソース指示情報を送信するように構成される。任意選択で、通信装置はメモリを更に含んでもよい。メモリは、プロセッサによって実行されるべき命令を記憶するように構成される。

他の実施形態において、プロセッサは、第1の指示情報を生成するように構成される。第1の指示情報は、複数のSTAが不連続帯域幅で全帯域幅マルチユーザMU－MIMO送信を実行することを示すために使用される。トランシーバは、第1の指示情報を送信するように構成される。任意選択で、通信装置はメモリを更に含んでもよい。メモリは、プロセッサによって実行されるべき命令を記憶するように構成される。

想定し得る製品形態において、この出願のこの実施形態における通信装置は、汎用プロセッサを使用して実装され得る。

通信装置を実装するための汎用プロセッサは、処理回路と、処理回路に内部接続されて処理回路と通信する出力インタフェースとを含む。処理回路は、リソース指示情報を決定するように構成される。リソース指示情報は複数のビットシーケンスを含む。複数のビットシーケンスにおける第1のビットシーケンスは、第1のリソースユニットに対応する。第1のリソースユニットは、第1のSTA又は複数のSTAに割り当てられるリソースブロックセットにおけるリソースユニットである。リソースブロックセットは少なくとも2つのリソースユニットを含む。出力インタフェースは、リソース指示情報を送信するように構成される。任意選択で、汎用プロセッサは、記憶媒体を更に含んでもよい。記憶媒体は、処理回路によって実行されるべき命令を記憶するように構成される。

通信装置を実装するための汎用プロセッサは、処理回路と、処理回路に内部接続されて処理回路と通信する入力インタフェースとを含む。処理回路は、第1の指示情報を生成するように構成される。第1の指示情報は、複数のSTAが不連続帯域幅で全帯域幅マルチユーザMU－MIMO送信を実行することを示すために使用される。入力インタフェースは、第1の指示情報を送信するように構成される。任意選択で、汎用プロセッサは、記憶媒体を更に含んでもよい。記憶媒体は、処理回路によって実行されるべき命令を記憶するように構成される。

想定し得る製品形態において、この出願のこの実施形態における通信装置は、1つ以上のFPGA（フィールドプログラマブルゲートアレイ）、PLD（プログラマブルロジックデバイス）、コントローラ、状態機械、ゲートロジック、個別のハードウェアコンポーネント、任意の他の適切な回路、又は、この出願に記載された機能を実行できる回路の任意の組み合わせを使用することによって更に実装され得る。

前述の様々な製品形態の通信装置が方法の実施形態におけるAPの任意の機能を有することを理解すべきである。ここでは詳細を繰り返さない。

要するに、従来技術では、シングルユーザ送信中及び全帯域幅マルチユーザMU－MIMO送信中にパンクチャされたチャネルを使用できるようにされない。この出願は、シングルユーザ送信中及び全帯域幅マルチユーザMU－MIMO送信中にパンクチャされたチャネルを使用することを可能にするために提案される技術的解決策である。具体的には、この出願の実施形態は、シングルユーザパンクチャード送信方法及び全帯域幅MU－MIMOパンクチャード送信方法を提供する。以下では、2つの方法を実施するための関連する解決策を個別に説明する。

以下では、m≧8、例えば、m＝8又はm＝9；n＝1～16のうちの1つ；及び、パンクチャされた242トーンRU（すなわち、20M）がmビットシーケンスを使用することによって示されてもよいことに留意すべきである。簡単に説明すると、「242（0）」はmビットシーケンスをマークするために使用される。言い換えると、「242（0）」はmビットシーケンスを表わすと考えられてもよい。mビットシーケンスは、ヌル242トーンRUを示す又はパンクチャされた242トーンRUを示す。

（1）シングルユーザパンクチャード送信方法に関する解決策
実施形態1：U－SIGフィールド内の1つ以上のフィールドは、送信されるべきPPDUがシングルユーザパンクチャされたPPDUであるかどうかを示すために使用される。

実施形態2：シングルユーザパンクチャード送信中の特定のパンクチャリング位置をどのように示すか？

具体的な解決策1：
リソース割り当てテーブル内のmビットシーケンスはRUを示す。RUは、ユーザに割り当てられた複数のRUのうちの1つである。ここで、m≧8である。

例えば、リソース割り当てテーブル内のmビットシーケンスは、242トーンRUを示す。242トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。簡単に説明すると、「242（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「242（同じ、1）」は、mビットシーケンスを表わすと考えられてもよい。mビットシーケンスは242トーンRUを示す。242トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。

したがって、図12に示されるパンクチャリングでは、第1の242トーンRU（すなわち、20M）が242（同じ、1）を使用して示され、第2の242トーンRUが242（0）を使用して示され、第3の242トーンRUが242（同じ、1）を使用して示され、第4の242トーンRUが242（同じ、1）を使用して示される。802．11ax規格に記載されたCCの場合、CC1に対して奇数番目のチャネル（すなわち、リソース割り当てテーブル内のmビットシーケンス）のリソース割り当て情報が設定され、CC2に対して偶数番目のチャネルのリソース割り当て情報が設定される。この場合、CC1に対して第1の20Mを示す242（同じ、1）が設定され、CC2に対して第2の20Mを示す242（0）が設定され、CC1に対して第3の20Mを示す242（同じ、1）が設定され、CC2に対して第4の20Mを示す242（同じ、1）が設定される。CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、1）及び242（同じ、1）を含み、CC2の場合、242（0）及び242（同じ、1）を含む。

任意選択で、CC1及びCC2は1つのユーザ情報フィールドを更に別々に含み、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、1）、242（同じ、1）、及びSTA1のユーザ情報フィールドを含み、CC2の場合、242（0）、242（同じ、1）、及びSTA1のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは、484トーンRUを示す。484トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。簡単に説明すると、「484（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「484（同じ、1）」は、mビットシーケンスを表わすと考えられてもよい。mビットシーケンスは484トーンRUを示す。484トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。図12に示されるパンクチャリングの場合、CC1及びCC2で伝えられる情報はそれぞれ、更に、CC1の場合、242（同じ、1）及び484（同じ、1）を含んでもよく、CC2の場合、242（0）及び484（同じ、1）を含んでもよい。

任意選択で、CC1及びCC2は1つのユーザ情報フィールドを更に別々に含み、また、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、1）、484（同じ、1）、及びSTA1のユーザ情報フィールドを含み、CC2の場合、242（0）、484（同じ、1）、及びSTA1のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを更に理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスが996RUを示し、996RUはユーザに割り当てられた複数のRUのうちの1つである。例えば、リソース割り当てテーブル内のmビットシーケンスが2＊996RUを示し、2＊996RUはユーザに割り当てられた複数のRUのうちの1つである。この任意選択的な解決策は、前述の解決策と同様である。ここでは詳細は説明されない。

具体的な解決策2：
リソース割り当てテーブル内のmビットシーケンスはRUを示す。RUは、ユーザに割り当てられた複数のRUのうちの1つである。RUに対応するユーザ情報フィールドの数は0である。リソース割り当てテーブル内の他のmビットシーケンスはRUを示す。RUは、ユーザに割り当てられた複数のRUのうちの1つである。RUに対応するユーザ情報フィールドの数は1である。ここで、m≧8である。

例えば、リソース割り当てテーブル内のmビットシーケンスは、242トーンRUを示す。242トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。242トーンRUに対応するユーザ情報フィールドの数は0である。簡単に説明すると、「242（同じ、0）」はmビットシーケンスをマークするために使用される。言い換えると、「242（同じ、0）」がmビットシーケンスを表わし、mビットシーケンスが242トーンRUを示し、242トーンRUがユーザに割り当てられた複数のRUのうちの1つであり、242トーンRUに対応するユーザ情報フィールドの数が0であると考えられてもよい。リソース割り当てテーブル内の他のmビットシーケンスは、242トーンRUを示す。242トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。242トーンRUに対応するユーザ情報フィールドの数は1である。簡単に説明すると、「242（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「242（同じ、1）」がmビットシーケンスを表わし、mビットシーケンスが242トーンRUを示し、242トーンRUがユーザに割り当てられた複数のRUのうちの1つのRUであり、242トーンRUに対応するユーザ情報フィールドの数が1であると考えられてもよい。

CC1及びCC2が1つのユーザ情報フィールドを別々に含む場合、図12に示されるシングルユーザパンクチャリングでは、CC1及びCC2で伝えられる情報が以下のうちの1つを含む。
（1）CC1の場合、242（同じ、1）、242（同じ、0）、及びSTA1のユーザ情報フィールド；及び、CC2の場合、242（0）、242（同じ、1）、及びSTA1のユーザ情報フィールド、又は、
（2）CC1の場合、242（同じ、0）、242（同じ、1）、及びSTA1のユーザ情報フィールド；及び、CC2の場合、242（0）、242（同じ、1）、及びSTA1のユーザ情報フィールド。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは、484トーンRUを示す。484トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。484トーンRUに対応するユーザ情報フィールドの数は0である。簡単に説明すると、「484（同じ、0）」はmビットシーケンスをマークするために使用される。言い換えると、「484（同じ、0）」がmビットシーケンスを表わし、mビットシーケンスが484トーンRUを示し、484トーンRUがユーザに割り当てられた複数のRUのうちの1つであり、484トーンRUに対応するユーザ情報フィールドの数が0であると考えられてもよい。他の例の場合、リソース割り当てテーブル内のmビットシーケンスは484トーンRUを示す。484トーンRUは、ユーザに割り当てられた複数のRUのうちの1つである。484トーンRUに対応するユーザ情報フィールドの数は1である。簡単に説明すると、「484（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「484（同じ、1）」がmビットシーケンスを表わし、mビットシーケンスが484トーンRUを示し、484トーンRUがユーザに割り当てられた複数のRUのうちの1つであり、484トーンRUに対応するユーザ情報フィールドの数が1であると考えられてもよい。

CC1及びCC2が1つのユーザ情報フィールドを別々に含む場合、図12に示されるシングルユーザパンクチャリングでは、CC1及びCC2で伝えられる情報が更に以下のいずれか1つであってもよい。
（1）CC1の場合、242（同じ、1）、484（同じ、0）、及びSTA1のユーザ情報フィールド；及び、CC2の場合、242（0）、484（同じ、1）、及びSTA1のユーザ情報フィールド、又は、
（2）CC1の場合、242（同じ、0）、484（同じ、1）、及びSTA1のユーザ情報フィールド；及び、CC2の場合、242（0）、484（同じ、1）、及びSTA1のユーザ情報フィールド。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを更に理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスが996RUを示し、996RUがユーザに割り当てられた複数のRUのうちの1つであり、996RUに対応するユーザ情報フィールドの数が0である。他の例に関し、リソース割り当てテーブル内のmビットシーケンスは996RUを示し、996RUはユーザに割り当てられた複数のRUのうちの1つであり、996RUに対応するユーザ情報フィールドの数は1である。他の例の場合には、リソース割り当てテーブル内のmビットシーケンスが2＊996RUを示し、2＊996RUがユーザに割り当てられた複数のRUのうちの1つであり、2＊996RUに対応するユーザ情報フィールドの数が0である。他の例に関し、リソース割り当てテーブル内のmビットシーケンスは2＊996RUを示し、2＊996RUはユーザに割り当てられた複数のRUのうちの1つであり、996RUに対応するユーザ情報フィールドの数は1である。

（2）ダウンリンク全帯域幅MU－MIMOパンクチャード送信方法に関する解決策
実施形態1：U－SIGフィールド内の1つ以上のフィールドは、送信されるべきPPDUが全帯域幅MU－MIMOパンクチャード送信におけるPPDUであるかどうかを示すために使用される。

実施形態2：全帯域幅MU－MIMO送信中に特定のパンクチャリング位置をどのように示すか？

図14に示される全帯域幅MU－MIMOパンクチャード送信は、以下の複数の解決策を使用して実施され得る。

具体的な解決策1：
リソース割り当てテーブル内のmビットシーケンスはRUを示す。RUは、n人のユーザによって実行されるMU－MIMOに関してn人のユーザに割り当てられる複数のRUのうちの1つである。ここで、m≧8であり、n＝1～16のいずれかである。リソース割り当てテーブル内のmビットシーケンスは、242トーンRUを示す。242トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられた複数のRUのうちの1つである。簡単に説明すると、「242（同じ、4）」はmビットシーケンスをマークするために使用される。言い換えると、「242（同じ、4）」は、mビットシーケンスを表わすと考えられてもよい。mビットシーケンスは242トーンRUを示す。242トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられた複数のRUのうちの1つである。

したがって、図14に示される全帯域幅MU－MIMOパンクチャード送信の場合には、第1の20Mが242（同じ、4）を使用して示され、第2の20Mが242（0）を使用して示され、第3の20Mが242（同じ、4）を使用して示され、第4の20Mが242（同じ、4）を使用して示される。奇数番目のチャネル及び偶数番目のチャネルのリソース割り当て情報（すなわち、リソース割り当てテーブル内のmビットシーケンス）を設定するための方法において、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、4）及び242（同じ、4）を含み、CC2の場合、242（0）及び242（同じ、4）を含む。

任意選択で、各CCが2つのユーザ情報フィールドを含む場合、例えば、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、4）、242（同じ、4）、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含み、CC2の場合、242（0）、242（同じ、4）、STA3のユーザ情報フィールド及びSTA4のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは、484トーンRUを示す。484トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。簡単に説明すると、「484（同じ、4）」はmビットシーケンスをマークするために使用される。言い換えると、「484（同じ、4）」がmビットシーケンスを表わすと考えられてもよい。mビットシーケンスは484トーンRUを示す。484トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。この場合、CC1及びCC2で伝えられる情報はそれぞれ、更に、CC1の場合、242（同じ、4）及び484（同じ、4）を含んでもよく、CC2の場合、242（0）及び484（同じ、4）を含んでもよい。

任意選択で、各CCが2つのユーザ情報フィールドを含む場合、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、4）、484（同じ、4）、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含み、CC2の場合、242（0）、484（同じ、4）、STA3のユーザ情報フィールド及びSTA4のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを更に理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは996RUを示し、また、996RUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。例えば、リソース割り当てテーブル内のmビットシーケンスは2＊996RUを示し、また、2＊996RUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。この任意選択的な解決策は、前述の解決策と同様である。ここでは詳細は説明されない。

確かに、mビットシーケンスは、n人のユーザによって実行されるMU－MIMOに関してn人のユーザに割り当てられる複数のRUのうちの1つを示すことができる。ここで、n＝1～16のいずれかである。n＝4の例は、一例として使用されているにすぎない。nの具体的な値は、この出願のこの実施形態では限定されない。

具体的な解決策2：
リソース割り当てテーブル内のmビットシーケンスはRUを示す。RUは、n人のユーザによって実行されるMU－MIMOに関してn人のユーザに割り当てられる複数のRUのうちの1つである。RUは、k個のユーザ情報フィールドに対応する。例えば、リソース割り当てテーブル内のmビットシーケンスは242トーンRUを示し、242トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つであり、242トーンRUは1つのユーザ情報フィールドに対応する。簡単に説明すると、「242（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「242（同じ、1）」は、mビットシーケンスを表わすと考えられてもよい。mビットシーケンスは242トーンRUを示す。242トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられた複数のRUのうちの1つである。242トーンRUは、1つのユーザ情報フィールドに対応する。

したがって、図14に示される全帯域幅MU－MIMOパンクチャード送信の場合には、第1の20Mが242（同じ、1）を使用して示され、第2の20Mが242（0）を使用して示され、第3の20Mが242（同じ、1）を使用して示され、第4の20Mが242（同じ、2）を使用して示される。奇数番目のチャネル及び偶数番目のチャネルのリソース割り当て情報（すなわち、リソース割り当てテーブル内のmビットシーケンス）を設定するための方法において、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、1）、242（同じ、1）、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含み、CC2の場合、242（0）、242（同じ、2）、STA3のユーザ情報フィールド及びSTA4のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは484トーンRUを示し、484トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つであり、484トーンRUは1つのユーザ情報フィールドに対応する。簡単に説明すると、「484（同じ、1）」はmビットシーケンスをマークするために使用される。言い換えると、「484（同じ、1）」は、mビットシーケンスを表わすと考えられてもよい。mビットシーケンスは484トーンRUを示す。484トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。484トーンRUは、1つのユーザ情報フィールドに対応する。また、484（同じ、2）は、mビットシーケンスを表わす。mビットシーケンスは484トーンRUを示す。484トーンRUは、4人のユーザによって実行されるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つである。484トーンRUは、2つのユーザ情報フィールドに対応する。この場合、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、1）、484（同じ、1）、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含み、CC2の場合、242（0）、484（同じ、2）、STA3のユーザ情報フィールド及びSTA4のユーザ情報フィールドを含む。

mビットシーケンスが他のサイズを伴うRUを更に示し得ることを更に理解すべきである。例えば、リソース割り当てテーブル内のmビットシーケンスは996RUを示し、996RUは、4人のユーザによって行なわれるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つであり、また、996RUは、k個のユーザ情報フィールドに対応し、996（同じ、k）を用いて示される。例えば、リソース割り当てテーブル内のmビットシーケンスは2＊996RUを示し、2＊996RUは、4人のユーザによって行なわれるMU－MIMOに関して4人のユーザに割り当てられる複数のRUのうちの1つであり、また、2＊996RUは、k個のユーザ情報フィールドに対応し、2＊996（同じ、k）を用いて示される。

確かに、mビットシーケンスは、n人のユーザによって実行されるMU－MIMOに関してn人のユーザに割り当てられる複数のRUのうちの1つを示すことができる。ここで、n＝1～16のいずれかである。n＝4の例は、一例として使用されているにすぎない。nの具体的な値は、この出願のこの実施形態では限定されない。

（3）ダウンリンクOFDMA送信
従来技術では、送信及び受信の複雑さを低減するために、OFDMA送信において1のユーザ／ユーザグループに1つのRUのみを割り当てることができる。

この出願の一実施形態は、リソース指示方法を更に提供する。この方法では、複数のRUを1のユーザ／ユーザグループに割り当てることができる。

具体的な解決策1：
リソース指示方法では、1人のユーザに複数のRUを割り当てることができる。方法は以下を含む。

リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRUのうちの1つを示し、また、他のmビットシーケンスは、他のユーザに割り当てられた複数のRUのうちの1つを示す。

例えば、リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRU内の242トーンRUを示す。簡単に説明すると、「242（同じ、A）」はmビットシーケンスをマークするために使用される。他のmビットシーケンスは、他のユーザに割り当てられた複数のRUのうちの1つを示す。簡単に説明すると、他のmビットシーケンスをマークするために「242（同じ、B）」が使用される。

図17に示されるマルチユーザリソース割り当てにおいて、STA1に割り当てられたリソース割り当て情報（すなわち、mビットシーケンス）は、第1の20M、第3の20M、及び第4の20Mを含み、また、3つの20Mに対応するリソース割り当て情報を242（同じ、A）として表わすことができ、STA2に割り当てられたリソース割り当て情報（すなわち、mビットシーケンス）は、第5の20M、第7の20M、及び第8の20Mを含み、3つの20Mに対応するリソース割り当て情報を242（同じ、B）として表わすことができる。第2の20M及び第6の20Mは、小さいRUに分割される20Mである。第2の20Mに対応するリソース割り当て情報（すなわち、mビットシーケンス）がXを使用して表わされ、第6の20Mに対応するリソース割り当て情報（すなわち、mビットシーケンス）がYを使用して表わされると仮定する。奇数番目のチャネル及び偶数番目のチャネルのリソース割り当て情報（すなわち、リソース割り当てテーブル内のmビットシーケンス）を設定するための方法において、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、A）、242（同じ、A）、242（同じ、B）、及び242（同じ、B）を含み、CC2の場合、X、242（同じ、A）、Y、及び242（同じ、B）を含む。

任意選択で、CC1は、STA1のユーザ情報フィールドを更に含み、CC2は、STA2のユーザ情報フィールドを更に含む。言い換えると、CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、A）、242（同じ、A）、242（同じ、B）、242（同じ、B）、及びSTA1のユーザ情報フィールドを含み、CC2の場合、X，242（同じ、A）、Y，242（同じ、B）、及びSTA2のユーザ情報フィールドを含む。

当然ながら、CC1は、もう一つの方法として、STA2のユーザ情報フィールドを含んでもよく、CC2はSTA1のユーザ情報フィールドを含んでもよい。

確かに、CC1は、もう一つの方法として、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含んでもよく、CC2は、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドを含んでもよい。

この方法において、ユーザに割り当てられた複数のRUにおけるRUは、任意のサイズを伴うRU、例えば、242トーンRU、484トーンRU、996RU、又は2＊996RUであってもよく、同様に、他のユーザに割り当てられた複数のRUにおけるRUは、任意のサイズを伴うRU、例えば、242トーンRU、484トーンRU、996RU、又は2＊996RUであってもよいことが理解されるべきである。1回のリソース割り当て中に、特定の場合にしたがって、様々なサイズを伴うRUを組み合わせて割り当てることができる。

例えば、図17のリソース割り当ては、以下のように更に示されてもよい。
CC1の場合、242（同じ、A）、484（同じ、A）、242（同じ、B）、484（同じ、B）、及び
CC2の場合、X、484（同じ、A）、Y、及び484（同じ、B）。

ここで、242（同じ、A）はmビットシーケンスを表わし、シーケンスは、ユーザに割り当てられた複数のRUにおける242トーンRUを示し、484（同じ、A）はmビットシーケンスを示し、シーケンスは、ユーザに割り当てられた複数のRUにおける484トーンRUを示し、242（同じ、B）はmビットシーケンスを示し、シーケンスは、他のユーザに割り当てられた複数のRUにおける242トーンRUを示し、484（同じ、B）はmビットシーケンスを表わし、シーケンスは、他のユーザに割り当てられた複数のRUにおける484トーンRUを示す。

具体的な解決策2：
リソース指示方法は以下を含む。

リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は0である。リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は1である。リソース割り当てテーブル内のmビットシーケンスは、別のユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は0である。リソース割り当てテーブル内のmビットシーケンスは、別のユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は1である。

例えば、リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRUにおける242トーンRUを示し、242トーンRUに対応するユーザフィールドの数は0であり、mビットシーケンスは242（同じ、A、0）を使用して示される。リソース割り当てテーブル内のmビットシーケンスは、ユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は1であり、mビットシーケンスは242（同じ、A、1）を用いて示される。リソース割り当てテーブル内のmビットシーケンスは他のユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は0であり、mビットシーケンスは242（同じ、B、0）を用いて示される。リソース割り当てテーブル内のmビットシーケンスは他のユーザに割り当てられた複数のRUのうちの1つを示し、RUに対応するユーザフィールドの数は1であり、mビットシーケンスは242（同じ、B、1）を用いて示される。

任意選択で、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドがCC1に対して設定され、STA1のユーザ情報フィールド及びSTA2のユーザ情報フィールドもCC2に対して設定される場合、図17のリソース割り当ては、以下のように更に示されてもよい。

CC1の場合、242（同じ、A、1）、242（同じ、A、0）、242（同じ、B、1）、242（同じ、B、0）、STA1のユーザ情報フィールド、及びSTA2のユーザ情報フィールド、及び、CC2の場合、X，242（同じ、A、1）、Y，242（同じ、B、1）、STA1のユーザ情報フィールド、及びSTA2のユーザ情報フィールド。

この方法において、ユーザに割り当てられた複数のRUにおけるRUは、任意のサイズを伴うRU、例えば、242トーンRU、484トーンRU、996RU、又は2＊996RUであってもよく、同様に、他のユーザに割り当てられた複数のRUにおけるRUは、任意のサイズを伴うRU、例えば、242トーンRU、484トーンRU、996RU、又は2＊996RUであってもよいことが理解されるべきである。1回のリソース割り当て中に、特定の場合にしたがって、様々なサイズを伴うRUを組み合わせて割り当てることができる。

具体的な解決策3：
リソース指示方法では、1つのユーザグループに複数のRUを割り当てることができる。方法は以下を含む。

リソース割り当てテーブル内のmビットシーケンスは、ユーザグループに割り当てられた複数のRUのうちの1つを示す。

例えば、リソース割り当てテーブル内のmビットシーケンスは、ユーザグループに割り当てられた複数のRUにおける242トーンRUを示す。図18に示されるように、3つの242トーンRU（すなわち、第5の20M、第7の20M、及び第8の20M）がユーザグループ（ユーザグループはSTA2～STA5を含む）に割り当てられる。3つの242トーンRUのうちのいずれかは、mビットシーケンスを使用して示すことができる。簡単に説明すると、「242（同じ、B、4）」はmビットシーケンスをマークするために使用される。

図18では、第1の20M、第3の20M、及び第4の20Mは、ユーザ：STA1に割り当てられる。3つの20Mのうちのいずれか1つは、他のmビットシーケンスを使用して示されてもよい。簡単に説明すると、他のmビットシーケンスをマークするために「242（同じ、A、1）」が使用される。図18の第2の20M及び第6の20Mはm小さいRUに分割され、11axで既に使用されている既存のビットシーケンスを使用してそれぞれ示されてもよい。簡単な説明のために、第2の20M及び第6の20MはそれぞれX及びYを使用してマークされる。したがって、図18のCC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、A、1）、242（同じ、A、1）、242（同じ、B、4）、及び242（同じ、B、4）を含み、CC2の場合、X、242（同じ、A、1）、Y、及び242（同じ、B、4）を含む。

任意選択で、CC1がSTA1～STA5のユーザ情報フィールドを更に含む場合、CC2は、第2の20Mのユーザ情報フィールド及び第6の20Mのユーザ情報フィールドを更に含む。CC1及びCC2で伝えられる情報はそれぞれ、CC1の場合、242（同じ、A、1）、242（同じ、A、1）、242（同じ、B、4）、242（同じ、B、4）、STA1のユーザ情報フィールド、STA2のユーザ情報フィールド、STA3のユーザ情報フィールド、STA4のユーザ情報フィールド、及びSTA5のユーザ情報フィールドを含み、CC2の場合、X，242（同じ、A、1）、Y，242（同じ、B、4）、第2の20Mのユーザ情報フィールド、及び第6の20Mのユーザ情報フィールドを含む。

上記において、複数のRUが割り当てられる異なるステーションは、A及びBの識別子変更によって識別される。更に、他の態様において、識別子：A及びBは、複数のRUが割り当てられる2つのステーションに別々に割り当てられる。複数のRUが割り当てられるより多くのステーション、例えば3つのステーションを示す必要がある場合、より多くの識別子、例えばA、B、及びCが区別のために必要とされる。

（1）、（2）、及び（3）の全ての解決策は、CC1及びCC2で伝えられる情報について説明する。CC1及びCC2は、EHT－SIGフィールドに含まれる。EHT－SIGフィールドは、PPDUに含まれる。PPDUの構造については、図11を参照されたい。

通信プロセスにおいて、送信端はPPDUを生成して送信する。PPDUは、EHT－SIGフィールドを含む。EHT－SIGフィールドは、CC1及びCC2を含む。CC1及びCC2で伝えられる情報については、（1）、（2）、及び（3）の様々な特定の解決策を参照されたい。

（1）、（2）、及び（3）の全ての解決策では、ビットシーケンスを使用して、1のユーザ／ユーザグループに割り当てられた複数のRUのうちの1つを示すとともに、既存の242（0）に関連してパンクチャされたチャネルを示す。

この方法に加えて、パンクチャされたチャネルを示すためにビットマップも使用され得ることが理解されるべきである。帯域幅パンクチャリングビットマップがEHT共通フィールドに付加される。例えば、4ビットのビットマップが80M帯域幅に関して使用され、16ビットのビットマップ又は15ビットのビットマップが320MHz帯域幅に関して使用される。ビットマップ内の1つのビットは、対応する20Mがパンクチャされることを示すために第1の値に設定され、又は、対応する20Mがパンクチャされないことを示すために第2の値に設定される。或いは、ビットマップ内の1つのビットは、対応する20Mがパンクチャされないことを示すために第1の値に設定され、又は、対応する20Mがパンクチャされることを示すために第2の値に設定される。帯域幅パンクチャリングビットマップは、以下の（4）で具体的に説明される。

帯域幅パンクチャリングビットマップは、以下の（4）で具体的に説明される帯域幅パンクチャリングモードであってもよい。

他の方法では、EHT共通フィールド内のリソース割り当て情報が省かれてもよい。例えば、EHT共通フィールドにおける帯域幅パンクチャリングビットマップ又は帯域幅パンクチャリングモードが省かれてもよい。加えて、U－SIG内の帯域幅フィールドが帯域幅及びパンクチャリングモードフィールドと置き換えられる。これについては、以下の（4）で具体的に説明する。

帯域幅パンクチャリングビットマップ、帯域幅パンクチャリングモード、又は帯域幅及びパンクチャリングモードの方法は、好ましくは（1）及び（2）の解決策で使用され、任意選択で（3）の解決策で使用される。

（1）、（2）、及び（3）の全ての解決策においては、mビットシーケンスがリソース割り当てテーブル内のmビットシーケンスに限定されないことを更に理解すべきである。mビットシーケンスは、他の形態のmビットシーケンスであってもよい。

（4）アップリンク全帯域幅MU－MIMOパンクチャード送信
この実施形態では、以下のケース、すなわち、帯域幅がパンクチャされるため、複数の不連続なリソースブロックがMU－MIMOユーザグループに別々に割り当てられ、その結果、MU－MIMOユーザグループ内のユーザのユーザ情報フィールドが複数回繰り返されることを回避するために、アップリンク全帯域幅MU－MIMOパンクチャード送信に関して指示方法が提供される。図14に示される全帯域幅マルチユーザMU－MIMOパンクチャード送信は一例である。APは、第1の20Mと第3の20M及び第4の20Mを含む40MとをSTA1～STA4に別々に割り当てる。この場合、APによって送信されるトリガフレームは、8つのユーザ情報フィールドを含む必要がある。8つのユーザ情報フィールドにおける4つのユーザ情報フィールドは、第1の20Mが別々に割り当てられるSTA1～STA4の4つのユーザ情報フィールドを含む。8つのユーザ情報フィールドにおける残りの4つのユーザ情報フィールドは、第3の20M及び第4の20Mを含む40Mが別々に割り当てられるSTA1～STA4の4つのユーザ情報フィールドを含む。

APによって送信されるトリガフレームは8つのユーザ情報フィールドを含む必要があることが分かる。これは多くのリソースを浪費する。

この実施形態は、アップリンク全帯域幅MU－MIMOパンクチャード送信のための指示方法を提供する。方法は以下を含む。

トリガフレームが生成されて送信される。トリガフレームは、以下の特徴を有する。

1．トリガフレームのトリガタイプフィールドは、アップリンク全帯域幅MU－MIMOパンクチャード送信を示すことができる。或いは、トリガフレームの共通情報フィールドにビット又はフィールドが付加され、ビット又はフィールドはアップリンク全帯域幅マルチユーザMU－MIMOパンクチャード送信を示す。加えて、アップリンク全帯域幅MU－MIMOパンクチャード送信は、特殊なケース、すなわち、アップリンク全帯域幅シングルユーザパンクチャード送信を任意選択的に更に含む。アップリンク全帯域幅MU－MIMOパンクチャード送信は、ユーザ情報フィールドが帯域幅パンクチャリングビットマップフィールド又は帯域幅パンクチャリングモードフィールドを含むことを示すものとして更に理解され得る。任意選択で、RU割り当てて指示フィールドは含まれないと考えられる。

2．ユーザ情報フィールド内のRU割り当てフィールドは、帯域幅パンクチャリングビットマップフィールド又は帯域幅パンクチャリングモードフィールドと置き換えられる。各20Mは、1ビットを使用して示される。例えば、80M帯域幅は4ビットのビットマップを使用して示され、320MHz帯域幅は16ビットのビットマップを使用して示される。ビットマップ内の1つのビットは、対応する20Mがパンクチャされることを示すために第1の値に設定され、又は、対応する20Mがパンクチャされないことを示すために第2の値に設定される。或いは、ビットマップ内の1つのビットは、対応する20Mがパンクチャされないことを示すために第1の値に設定され、又は、対応する20Mがパンクチャされることを示すために第2の値に設定される。或いは、帯域幅パンクチャリングビットマップの長さは帯域幅に伴って変化しない。例えば、帯域幅パンクチャリングビットマップの長さは16ビットである。他の形態では、帯域幅内のプライマリ20Mチャネルに関してパンクチャリングが許容されないため、前述の複数の形態におけるパンクチャリングビットマップから1ビットが削減され得る。例えば、帯域幅パンクチャリングビットマップの長さは帯域幅に伴って変化しない。この場合、帯域幅パンクチャリングビットマップの長さは15ビットである。プライマリ20Mがパンクチャされるか否かを示す指示は含まれない。帯域幅パンクチャリングビットマップによって示される帯域幅内の各20Mは、高周波数から低周波数へ又は低周波数から高周波数へ配置される。

帯域幅パンクチャリングモードフィールドは、帯域幅内の特定のパンクチャされた20Mを示すためにも使用される。この場合、簡単な実施のために、帯域幅パンクチャリングモードフィールドによって示されるモードが制限される。20MHzのうちのいずれか1つ以上については、パンクチャリングは実施されない。モードは、以下を含むことができる（具体的な表は以下で補足される）。

帯域幅パンクチャリングモードフィールドによって示されるパンクチャリングモードは制限されるため、前述の表に含まれるモードは、指示のために6ビットしか必要としない。より多くのパンクチャリングモードが続いて含まれる場合、帯域幅パンクチャリングモードフィールドの長さは、7ビット、8ビット、9ビット、又は他のビット数であってもよい。

他の態様において、帯域幅パンクチャリングモードフィールドによって示される複数のパンクチャリングモードは帯域幅に伴って変化する。帯域幅は、トリガフレーム内の帯域幅フィールドによって示される。具体的には、帯域幅が20M又は40Mである場合、パンクチャリングモードは存在しない。この場合、帯域幅パンクチャリングモードフィールドは0ビットであり得る。帯域幅が80Mである場合、帯域幅パンクチャリングモードフィールドによって示されるモードは、2ビットを必要とするモード番号1～4を含む。帯域幅が160Mである場合、帯域幅パンクチャリングモードフィールドによって示されるモードは、4ビットを必要とするモード番号5～16を含む。帯域幅が240Mである場合、帯域幅パンクチャリングモードフィールドによって示されるモードは、4ビットを必要とするモード番号17～25を含む。帯域幅が320Mである場合、帯域幅パンクチャリングモードフィールドによって示されるモードは、4ビットを必要とするモード番号26～37を含む。好ましい態様は、帯域幅パンクチャリングモードフィールドによって示されるモードが帯域幅に伴って変化するが、長さが変化しないことである。前述の例において、帯域幅パンクチャリングモードフィールドの長さは、全ての帯域幅に必要な最大ビット数、すなわち4である。例えば、帯域幅が80Mである場合、帯域幅パンクチャリングモードフィールドによって示されるモードは、モード番号1～4を含む。ここで、長さ4ビットの帯域幅パンクチャリングモードフィールドの値0～3はそれぞれモード番号1～4を示す。他の値は予約値である。

160M帯域幅が2つの80Mを含むことができ、2つの80Mが連続せず、或いは、160M帯域幅が隣接する160Mを含んでもよいことに留意すべきである。240M帯域幅が160M及び80Mを含むことができ、160M及び80Mが連続せず、或いは、240M帯域幅が隣接する240Mを含んでもよい。320M帯域幅が2つの160Mを含むことができ、2つの160Mが連続せず、或いは、320M帯域幅が隣接する320Mを含んでもよい。

以下は、トリガフレームのシグナリングオーバーヘッドを更に低減するための方法を提供する。全帯域幅パンクチャリングモードでは、重複するAIDを伝えるユーザ情報フィールドを回避することができるだけでなく、ユーザ情報フィールドのRU割り当て指示フィールド／帯域幅パンクチャリングビットマップフィールド／帯域幅パンクチャリングモードフィールドを省くこともできる。これは、具体的には以下の通りである。

1．トリガフレームのトリガタイプフィールドは、アップリンク全帯域幅MU－MIMOパンクチャード送信を示すことができる。アップリンク全帯域幅MU－MIMOパンクチャード送信は、特殊なケース、すなわち、アップリンク全帯域幅シングルユーザパンクチャード送信を任意選択的に更に含む。

2．トリガフレームのユーザ情報フィールドは、リソース割り当て情報、例えば、RU割り当てフィールド、帯域幅パンクチャリングビットマップフィールド、又は帯域幅パンクチャリングモードフィールドを含まない。

3．トリガフレームの共通フィールド内の帯域幅フィールドは、帯域幅パンクチャリングビットマップフィールド又は帯域幅及びパンクチャリングモードフィールドと置き換えられる。

アップリンク全帯域幅MU－MIMOパンクチャード送信は、ユーザ情報フィールドが、リソース割り当てに関する情報、例えば、帯域幅パンクチャリングビットマップフィールド、帯域幅及びパンクチャリングモードフィールド、又はRU割り当て指示フィールドを含まないことを示すものとして更に理解することができる。任意選択で、トリガフレームの共通フィールドは、帯域幅パンクチャリングビットマップフィールド又は帯域幅及びパンクチャリングモードフィールドを含む。

帯域幅パンクチャリングビットマップフィールドは、前述の方法におけるものと同じである。しかしながら、この場合、帯域幅パンクチャリングビットマップフィールドは、所定長、例えば15ビット又は16ビットを有する。帯域幅パンクチャリングビットマップは、全ての20Mがパンクチャされていないことを示すために、全て第1の値、例えば1とすることができる。帯域幅パンクチャリングビットマップが連続した1を含み、他の値が0である場合、それは帯域幅がパンクチャされないことを示す。

20M、40M、80M、160、240M、及び320Mを含む6つの非パンクチャ帯域幅モードが、帯域幅及びパンクチャリングモードフィールドに関して表1のパンクチャリングモードに付加される。言い換えると、少なくとも43のモードが含まれる。帯域幅及びパンクチャリングモードフィールドは6ビットであってもよい。より多くのモードが続いて更に含まれる場合、帯域幅及びパンクチャリングモードフィールドは、7ビット、8ビット、9ビット、又は他のビット数であってもよい。

帯域幅内のプライマリ20Mをパンクチャできないことに留意すべきである。

図14に示される全帯域幅マルチユーザMU－MIMOパンクチャード送信が前述の2つの特徴を有するトリガフレームを使用して示される場合、トリガフレームは4つのユーザ情報フィールドを含むだけでよく、各ユーザ情報フィールドにおけるRU割り当てフィールドは帯域幅パンクチャリングビットマップフィールドと置き換えられる。

同じ技術概念に基づいて、この出願の一実施形態はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体はコンピュータ命令を記憶する。命令がコンピュータで実行されると、コンピュータは、前述の方法の実施形態におけるAP側で情報指示方法を実行できるようにされる。

この出願の一実施形態は、命令を含むコンピュータプログラムプロダクトを提供する。コンピュータプログラムプロダクトがコンピュータで実行されると、コンピュータは、第1の態様及び第2の態様のいずれか1つ或いはこれらの態様の可想定し得る実施のいずれか1つで方法の実施形態を実行できるようにされる。

この出願の一実施形態は、チップシステムを更に提供する。チップシステムは、例えば、前述の態様におけるデータ及び／又は情報を生成又は処理するなど、情報指示方法を実施する際にAPをサポートするように構成されるプロセッサを含む。想定し得る設計では、チップシステムがメモリを更に含む。メモリは、データ送信デバイスに必要なプログラム命令及びデータを記憶するように構成される。チップシステムは、チップを含んでもよく又はチップと他の別個のデバイスとを含んでもよい。

この出願の一実施形態は通信システムを更に提供する。システムは、前述した態様における少なくとも1つの第1のアクセスポイントと少なくとも1つの第1のSTAとを含む。

当業者であれば分かるように、この出願の実施形態は、方法、システム、又は、コンピュータプログラムプロダクトとして提供されてもよい。したがって、この出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、又は、ソフトウェアとハードウェアとの組合せを伴う実施形態の形態を使用することができる。更には、この出願は、コンピュータ使用可能なプログラムコードを含む1つ以上の、コンピュータ使用可能な記憶媒体（ディスクメモリ、光メモリなどを含むがこれらに限定されない）上に実装されるコンピュータプログラムプロダクトの形態を使用し得る。

この出願は、この出願に係る方法、デバイス（システム）、及び、コンピュータプログラムプロダクトのフローチャート及び／又はブロック図に関連して説明される。コンピュータプログラム命令は、フローチャート及び／又はブロック図における各プロセス及び／又は各ブロック並びにフローチャート及び／又はブロック図におけるプロセス及び／又はブロックの組合せを実装するために使用されてもよいことを理解すべきである。これらのコンピュータプログラム命令は、機械を生み出すために汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は、任意の他のプログラマブルデータ処理デバイスのプロセッサに与えられてもよく、それにより、コンピュータ又は任意の他のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の1つ以上のプロセス及び／又はブロック図内の1つ以上のブロックにおける特定の機能を実装するための装置を生み出す。

コンピュータ又は任意の他のプログラマブルデータ処理デバイスに特定の態様で動作するように命令することができるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに記憶することができ、それにより、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生み出す。命令装置は、フローチャートの1つ以上のプロセス及び／又はブロック図の1つ以上のブロックにおける特定の機能を実装する。

これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理デバイスにロードされてもよく、それにより、一連の動作及びステップがコンピュータ又は他のプログラマブルデバイスで実行され、その結果、コンピュータ実施処理がもたらされる。したがって、コンピュータ又は他のプログラマブルデバイス上で実行される命令は、フローチャートの1つ以上のプロセス及び／又はブロック図の1つ以上のブロックにおける特定の機能を実装するためのステップを与える。

明らかに、当業者は、この出願の範囲から逸脱することなく、この出願に対して様々な修正及び変形を行なうことができる。この出願は、以下の特許請求の範囲及びそれらの同等の技術によって規定される保護範囲内に入る限り、この出願のこれらの修正及び変形を網羅することを意図している。

2201 処理モジュール
2202 トランシーバモジュール

Claims (25)

1. アクセスポイントAPによって、物理層プロトコルデータユニットPPDUを生成するステップであって、前記PPDUのプリアンブルがU－SIGフィールドを含み、前記U－SIGフィールドが前記PPDUの送信モードを示す第1の指示情報を含み、前記PPDUの前記送信モードが、シングルユーザ全帯域幅送信、シングルユーザ全帯域幅パンクチャード送信、全帯域幅MU－MIMO送信、全帯域幅MU－MIMOパンクチャード送信、又は、OFDMA送信を含む、ステップと、
   前記APによって、前記PPDUを送信するステップと、
   を含む情報指示方法であって、
   前記PPDUの前記プリアンブルがEHT－SIGフィールドを含み、前記EHT－SIGフィールドが共通フィールド及びユーザ固有フィールドを含み、前記ユーザ固有フィールドが1つ以上のユーザフィールドを含み、前記ユーザフィールドがステーションの関連付け識別子AIDを含み、
   前記第1の指示情報が前記シングルユーザ全帯域幅送信又は前記シングルユーザ全帯域幅パンクチャード送信を示す場合、前記ユーザ固有フィールドが1つのユーザフィールドを含む、情報指示方法。
2. 前記U－SIGフィールドが帯域幅フィールドを含み、前記帯域幅フィールドによって示される前記PPDUの帯域幅が20 MHzよりも大きい場合、各コンテンツチャネルにおける前記ユーザ固有フィールドが1つのユーザフィールドを含む、請求項1に記載の方法。
3. 前記第1の指示情報がPPDUフォーマットフィールド及びパンクチャリングフィールドで伝えられ、
   前記PPDUフォーマットフィールドが前記PPDUのフォーマットを示し、前記PPDUのフォーマットは、シングルユーザPPDU、全帯域幅MU－MIMO PPDU、又は、OFDMA PPDUを含み、
   前記パンクチャリングフィールドが複数のビットを占有し、それらのビットのうちの1つの値は、前記PPDUがパンクチャされないことを示す、
   請求項1または2に記載の方法。
4. 前記シングルユーザ全帯域幅送信、前記シングルユーザ全帯域幅パンクチャード送信、前記全帯域幅MU－MIMO送信、又は、前記全帯域幅MU－MIMOパンクチャード送信を前記第1の指示情報が示す場合に、前記共通フィールドがリソース割り当て情報を含まない、請求項2に記載の方法。
5. 前記第1の指示情報が前記OFDMA送信を示すとき、前記共通フィールドがリソース割り当て情報を含む、請求項2に記載の方法。
6. 前記リソース割り当て情報が1つ以上のビットシーケンスを含み、前記1つ以上のビットシーケンスは、スペクトルリソースがリソースユニットの幾つかのセットに分割されることを示し、前記リソースユニットのセットが1つ以上のリソースユニットを含み、
   前記リソースユニットのセットが1つ以上のステーションに割り当てられる、
   請求項4又は5に記載の方法。
7. 前記ビットシーケンスが9ビットを占有する、請求項6に記載の方法。
8. 前記1つ以上のビットシーケンスのうちの1つがリソースユニットの第1のセットに対応し、前記リソースユニットの第1のセットが1つ以上のステーションに割り当てられる、請求項6に記載の方法。
9. 前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置を示すために使用され、又は、
   前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置並びにSTAの数を示すために使用され、又は、
   前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置並びに前記リソースユニットの幾つかのセットに対応するユーザ情報フィールドの数を示すために使用される、
   請求項6に記載の方法。
10. 前記リソース割り当て情報は、2つの隣り合うSTAにおける前のSTAに割り当てられる前記リソースユニットのセットの最後のリソースユニットを示すために更に使用される、請求項6に記載の方法。
11. 前記PPDUが第2の指示情報を更に含み、前記第2の指示情報がSTAの数を示すために使用される、請求項1から10のいずれか一項に記載の方法。
12. ステーションSTAによって、物理層プロトコルデータユニットPPDUを受信するステップであって、前記PPDUのプリアンブルがU－SIGフィールドを含み、前記U－SIGフィールドが前記PPDUの送信モードを示す第1の指示情報を含み、前記PPDUの前記送信モードが、シングルユーザ全帯域幅送信、シングルユーザ全帯域幅パンクチャード送信、全帯域幅MU－MIMO送信、全帯域幅MU－MIMOパンクチャード送信、又は、OFDMA送信を含む、ステップと、
    前記STAにより、前記第1の指示情報にしたがって前記PPDUの前記送信モードを決定するステップと、
    を含む情報指示方法であって、
    前記PPDUの前記プリアンブルがEHT－SIGフィールドを含み、前記EHT－SIGフィールドが共通フィールド及びユーザ固有フィールドを含み、前記ユーザ固有フィールドが1つ以上のユーザフィールドを含み、前記ユーザフィールドがステーションの関連付け識別子AIDを含み、
    前記第1の指示情報が前記シングルユーザ全帯域幅送信又は前記シングルユーザ全帯域幅パンクチャード送信を示す場合、前記ユーザ固有フィールドが1つのユーザフィールドを含む、情報指示方法。
13. 前記U－SIGフィールドが帯域幅フィールドを含み、前記帯域幅フィールドによって示される前記PPDUの帯域幅が20 MHzよりも大きい場合、各コンテンツチャネルにおける前記ユーザ固有フィールドが1つのユーザフィールドを含む、請求項12に記載の方法。
14. 前記第1の指示情報がPPDUフォーマットフィールド及びパンクチャリングフィールドで伝えられ、
    前記PPDUフォーマットフィールドが前記PPDUのフォーマットを示し、前記PPDUの前記フォーマットは、シングルユーザPPDU、全帯域幅MU－MIMO PPDU、又は、OFDMA PPDUを含み、
    前記パンクチャリングフィールドが複数のビットを占有し、それらのビットのうちの1つの値は、前記PPDUがパンクチャされないことを示す、
    請求項12または13に記載の方法。
15. 前記シングルユーザ全帯域幅送信、前記シングルユーザ全帯域幅パンクチャード送信、前記全帯域幅MU－MIMO送信、又は、前記全帯域幅MU－MIMOパンクチャード送信を前記第1の指示情報が示す場合に、前記共通フィールドがリソース割り当て情報を含まない、請求項12に記載の方法。
16. 前記第1の指示情報が前記OFDMA送信を示すとき、前記共通フィールドがリソース割り当て情報を含む、請求項12に記載の方法。
17. 前記リソース割り当て情報が1つ以上のビットシーケンスを含み、前記1つ以上のビットシーケンスは、スペクトルリソースがリソースユニットの幾つかのセットに分割されることを示し、前記リソースユニットのセットが1つ以上のリソースユニットを含み、
    前記リソースユニットのセットが1つ以上のステーションに割り当てられる、
    請求項15又は16に記載の方法。
18. 前記ビットシーケンスが9ビットを占有する、請求項17に記載の方法。
19. 前記1つ以上のビットシーケンスのうちの1つがリソースユニットの第1のセットに対応し、前記リソースユニットの第1のセットが1つ以上のステーションに割り当てられる、請求項17に記載の方法。
20. 前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置を示すために使用され、又は、
    前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置並びにSTAの数を示すために使用され、又は、
    前記ビットシーケンスは、前記リソースユニットの幾つかのセットのサイズ及び位置並びに前記リソースユニットの幾つかのセットに対応するユーザ情報フィールドの数を示すために使用される、
    請求項17に記載の方法。
21. 前記リソース割り当て情報は、2つの隣り合うSTAにおける前のSTAに割り当てられる前記リソースユニットのセットの最後のリソースユニットを示すために更に使用される、請求項17に記載の方法。
22. 前記PPDUが第2の指示情報を更に含み、前記第2の指示情報がSTAの数を示すために使用される、請求項12から21のいずれか一項に記載の方法。
23. 請求項1から22のいずれか一項に記載の方法を実行するように構成されるモジュールを備える、通信装置。
24. コンピュータプログラムを記憶するように構成され、前記コンピュータプログラムが請求項1から22のいずれか一項に記載の方法を実行するための命令を含む、コンピュータ可読記憶媒体。
25. 請求項1から22のいずれか一項に記載の方法を実行するための命令を含む、コンピュータプログラム。

Images