JP7316774B2 - 通信装置およびその制御方法 - Google Patents

Description

本発明は、通信装置およびその制御方法に関する。

近年、多数の無線機器が存在する環境での無線媒体の効率的な利用を目指すＩＥＥＥ８０２．１１ａｘ規格が、ドラフト規格として発行されている。このドラフト規格では、アクセスポイントからのトリガーフレーム（ＴＦ：Trigger Frame）と呼ばれるリソースユニット割り当てを含む起動信号を契機に、複数の端末が同時にフレームを送信することで、無線媒体の効率的な利用を目指している。この規格によれば、無線アクセスポイントが複数の端末へ起動信号を送信し、その起動信号を受信した端末が規定時間後に応答データを送信し、その応答データを無線アクセスポイントが受信する。

このトリガーフレームを受信した端末は、ＳＩＦＳ（Short Inter Frame Space）と呼ばれる時間経過後に、割り当てられたリソースユニットを使ってデータを送信することになっている。しかし、このリソースユニットを使用した送信において、端末は事前準備を必要とする。特許文献１では、端末がアクセスポイントに対して準備に必要な時間を要求し、アクセスポイントがそれに基づいたｐａｄｄｉｎｇをトリガーフレームに付加する技術が開示されている。

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

しかし、多くの端末が存在する環境においては、端末の送信準備の能力もまちまちであり、それにともない端末の要求時間にも差異が生ずる。要求時間に差異がある端末群に複数のトリガーフレームを送信する場合、それぞれのＴＦの宛先を適切に設定しないと、過剰なｐａｄｄｉｎｇの付加による時間や無線媒体の無駄が発生してしまうことになる。

本発明は、ｐａｄｄｉｎｇの付加による不要な遅延時間の発生を低減することを目的とする。

本発明の一態様による通信装置は以下の構成を備える。すなわち、
複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置であって、
前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得手段と、
前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択手段と、
前記選択手段により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信手段と、を備え、
前記選択手段は、前記複数の端末から取得した前記能力情報に基づいて準備時間が等しい端末が連続するように前記複数の端末の選択順を決定し、前記選択順に従って前記１つのトリガーフレームの宛先となる端末を選択する。

本発明によれば、ｐａｄｄｉｎｇの付加による不要な遅延時間の発生を低減することができる。

実施形態による通信システムの構成例を示す図。 アクセスポイントおよび端末のハードウェア構成例を示すブロック図。 ＴＦのデータ構成例を示す図。 ＴＦのＣｏｍｍｏｎ Ｉｎｆｏのデータ構成例を示す図。 ＮＦＲＰ ＴＦ以外のＰｅｒ Ｕｓｅｒ Ｉｎｆｏのデータ構成例を示す図。 実施形態１による端末テーブルの例を示す図。 実施形態１のシーケンスを説明する図。 （ａ）は管理フレーム受信処理を示すフローチャート、（ｂ）はＴＦ送信／データ受信／応答送信の処理を示すフローチャート（ｃ）は実施形態１による全トリガーフレーム送信処理を示すフローチャート。 実施形態２による全トリガーフレーム送信処理を示すフローチャート。 実施形態２におけるＴＦ送信処理テーブルの例を示す図。 ＮＦＲＰ ＴＦのＰｅｒ Ｕｓｅｒ Ｉｎｆｏのデータ構成例を示す図。

以下、添付の図面を参照して、本発明の実施形態について説明する。

＜実施形態１＞
図１は実施形態に係る通信システムの構成例を示すブロック図である。ＡＰ１０１は、ＩＥＥＥ８０２．１１ａｘに対応したアクセスポイントである。端末１０２は、ＩＥＥＥ８０２．１１ａｘに対応しており、ＡＰ１０１が構築した無線ネットワーク１００に接続されている。ここで、それぞれの端末１０２に付されている－（ハイフン）と数字は、同種の端末であることを示している。なお、端末１０２－ＭのＭは、ＩＥＥＥ８０２．１１規格のＡＩＤ（Association Identifier）の最大値である２００７までを取り得る。このような構成において、ＡＰ１０１が端末１０２に対してトリガーフレーム（ＴＦ）を送信すると、端末１０２は、ＴＦにより割り当てられたリソースユニットを用いてデータの送信（アップリンク伝送（Ｕｐ Ｌｉｎｋ））を行う。なお、リソースユニットは、ＲＵ（（Resource Unit）とも記載される。

図２に、ＡＰ１０１と端末１０２のハードウェア構成を示す。図２では、ＡＰ１０１と端末１０２で共通の構成が示されており、ＡＰ１０１が備える固有の構成、端末１０２が備える固有の構成などは省略されている。

記憶部２０１はＲＯＭやＲＡＭ等のメモリにより構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部２０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体を用いてもよい。また、記憶部２０１が複数のメモリ等を備えていてもよい。

制御部２０２はＣＰＵやＭＰＵ等のプロセッサーにより構成され、記憶部２０１に記憶されたプログラムを実行することにより、ＡＰ１０１、端末１０２のそれぞれにおける各種処理を実現する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により、それぞれの端末を制御するようにしてもよい。また、制御部２０２がマルチコア等の複数のプロセッサーから成り、それぞれの端末を制御するようにしてもよい。また、制御部２０２は、機能部２０３を制御して、アクセスポイント機能、撮像や印刷、投影等の所定の処理を実行する。機能部２０３は、ＡＰ１０１、端末１０２が所定の処理を実行するためのハードウェアである。

入力部２０４は、ユーザからの各種操作の受付を行う。出力部２０５は、ユーザに対して各種出力を行う。ここで、出力部２０５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくともひとつを含む。なお、タッチパネルのように入力部２０４と出力部２０５の両方を１つのモジュールで実現するようにしてもよい。

通信制御部２０６は、ＩＥＥＥ８０２．１１シリーズやＷｉ－Ｆｉに準拠した無線通信の制御や、ＩＰ（Internet Protocol）通信の制御をおこなう。さらに詳しく言えば、ＩＥＥＥ８０２．１１ａｘ制御部２０７または非ＩＥＥＥ８０２．１１ａｘ制御部２０８を切り替えることにより、ＩＥＥＥ８０２．１１ａｘに対応するＡＰ／端末、または、対応しないＡＰ／端末として動作可能になっている。さらに、通信制御部２０６はアンテナ２０９を制御して、無線通信のための無線信号の送受信を行う。

図３Ａに実施形態１によるトリガーフレーム（ＴＦ：Trigger Frame）の構成例を示す。ＴＦ３００は、ＩＥＥＥ８０２．１１ａｘから新規に導入されたフレームで、複数の端末（Ｕｓｅｒ）がＡＰ宛てに同時にフレーム送信するために必要な起動タイミングとフレームを用いる無線チャネル情報などを示すものである。

３０１は、ＩＥＥＥ８０２．１１シリーズに共通なＦｒａｍｅ Ｃｏｎｔｒｏｌであり、本実施形態では、ＩＥＥＥ８０２．１１ａｘのトリガーフレームであることを示す値が入る。Ｆｒａｍｅ Ｃｏｎｔｒｏｌ３０１の長さは、２オクテット（バイト）である。３０２はＤｕｒａｔｉｏｎであり、長さは２オクテットである。３０３はＲＡ（Receiver Address）であり、長さは６オクテットである。３０４はＴＡ（Transmitter Address）であり、長さは６オクテットである。３０５はＣｏｍｍｏｎ Ｉｎｆｏであり、このＴＦの宛先である複数の端末に共通な情報を示す。Ｃｏｍｍｏｎ Ｉｎｆｏ３０５の長さは、８オクテット以上であり、詳細は図３Ｂの参照により後述する。

３０６はＰｅｒ Ｕｓｅｒ Ｉｎｆｏであり、このＴＦの宛先に対する個別情報を示す。Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６の長さは、５オクテット以上であり、詳細は図３Ｃの参照により後述する。３０７はＰａｄｄｉｎｇであり、このＴＦを受信した端末群に時間的猶予を与えるためのものである。３０８はＦＣＳ（Frame Check Sequence）である。

図３ＢはＣｏｍｍｏｎ Ｉｎｆｏ３０５のデータ構成例を示している。３１１はＴｒｉｇｇｅｒ Ｔｙｐｅ（種別）であり、長さが４ビットのサブフィールドである。このサブフィールドの詳細は、図３Ｂのテーブル３１の「Description」に示すとおりである。たとえば、ＢＳＲＰ ＴＦの場合はＴｒｉｇｇｅｒ Ｔｙｐｅは４、ＢＱＲＰ ＴＦの場合はＴｒｉｇｇｅｒ Ｔｙｐｅは６、ＮＦＲＰ ＴＦの場合はＴｒｉｇｇｅｒ Ｔｙｐｅは７となる。なお、ＢＳＲＰはBuffer Status Report Poll、ＢＱＲＰはBandwidth Query Report Poll、ＮＦＲＰはNDP (Null Data Packet) Feedback Reportである。

３１２はＬｅｎｇｔｈであり、長さは１２ビットである。Ｌｅｎｇｔｈ３１２の値は、ＴＦに対する応答データの時間（duration）を示し、ＩＥＥＥ８０２．１１のフレームにおける物理層のＬ－ＳＩＧフィールドに反映される。ここで、Ｌ－ＳＩＧ（Legacy Signal Fieldまたはnon-HT SIGnal field）は、そのフィールドを持つフレームの継続時間を示すものである。３１３はＣａｓｃａｄｅ Ｉｎｄｉｃａｔｉｏｎであり、長さは１ビットである。なお、Ｃａｓｃａｄｅ Ｉｎｄｉｃａｔｉｏｎ３１３の領域をＭｏｒｅ ＴＦと記すこともある。３１４はＣＳ（Carrier Sense） Ｒｅｑｕｉｒｅｄであり、長さは１ビットである。

３１５は、ＢＷ（Bandwidth）であり、長さは２ビットである。このサブフィールドの詳細は、図３Ｂのテーブル３２の「Description」に示すとおりである。たとえば、動作チャネルの帯域が２０ＭＨｚの場合は、このサブフィールドの値が０となる。３１６は、ＧＩ Ａｎｄ ＬＴＦ Ｔｙｐｅ（Guard Interval And Long Training Field Type）であり、長さは２ビットである。３１７はＭＵ－ＭＩＭＯ ＬＴＦ Ｍｏｄｅであり、長さは１ビットである。３１８はＮｕｍｂｅｒ ｏｆ ＨＥ ＬＴＦ Ｓｙｍｂｏｌｓであり、長さは３ビットである。３１９は、ＳＴＢＣ（Space Time Block Code）であり、長さは１ビットである。

３２０はＬＤＰＣ（Low Density Parity Check） Ｅｘｔｒａ Ｓｙｍｂｏｌ Ｓｅｇｍｅｎｔであり、長さは１ビットである。３２１はＡＰ ＴＸ Ｐｏｗｅｒであり、長さは６ビットである。３２２はＰａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎであり、長さは３ビットである。３２３はＳｐａｔｉａｌ Ｒｅｕｓｅであり、長さは１６ビットである。３２４はＤｒｏｐｐｅｒであり、長さは１ビットである。３２５はＨＥ－ＳＩＧ－Ａ Ｒｅｓｅｒｖｅｄであり、長さは９ビットである。なお、ＨＥ－ＳＩＧ－Ａという表記は、ＨＥ－ＳＩＧ－Ａ１からＨＥ－ＳＩＧ－Ａ４までを代表させた表現である。３２６はＲｅｓｅｒｖｅｄであり、長さは１ビットである。３２７はＴｒｉｇｇｅｒ Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍｏｎ Ｉｎｆｏであり、長さはｖａｒｉａｂｌｅ（可変長）である。この部分によって、Ｔｒｉｇｇｅｒ Ｔｙｐｅ３１１に応じた付加情報を示す構成となっている。

次に、図３Ｃを参照して、Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６の詳細を説明する。３２８はＡＩＤ１２である。この値と同じＡＩＤの値を持つ端末が、このＰｅｒ Ｕｓｅｒ Ｉｎｆｏの宛先となり、そこで割り当てられたＲＵを使うことになる。なお、ＡＩＤの値との合致判断は、１２ ＬＳＢｓ（Least Significant Bits）によっておこなう。ここで、ＡＩＤ１２＝０は、特定の端末宛てではなく、ＡＰにアソシエート（接続）している任意の端末宛てであることを示す。また、ＡＩＤ１２＝２０４５は、ＡＰにアソシエートしていない任意の端末宛てであることを示す。さらに、ＡＩＤ１２＝２０４６は、ＲＵ（リソースユニット）が未割当てであることを示す。３２９はＲＵ Ａｌｌｏｃａｔｉｏｎであり、ＲＵのインデックスである。３３０はＦＥＣ Ｃｏｄｉｎｇ Ｔｙｐｅであり、ＴＦへの応答データの符号化タイプを示す。３３１はＭＣＳ（Modulation and Coding Scheme）であり、ＴＦへの応答フレームで使用される符号化方式を示す。３３２は、ＴＦへの応答フレームのＤＣＭ（Dual Carrier Modulation）である。

３３３はＳＳ Ａｌｌｏｃａｔｉｏｎ／ＲＡ－ＲＵ Ｉｎｆｏｒｍａｔｉｏｎであり、端末のＡＩＤが０でも２０４５でもないときは、ＴＦへの応答フレームのｓｐａｔｉａｌ ｓｔｒｅａｍであることを示す。また、端末のＡＩＤが０または２０４５のときは、ＳＳ Ａｌｌｏｃａｔｉｏｎ／ＲＡ－ＲＵ Ｉｎｆｏｒｍａｔｉｏｎ３３３は、ＲＡ－ＲＵ（Random Access Resource Unit）であることを示す。３３４はＴａｒｇｅｔ ＲＳＳＩ（Received Signal Strength Indicator）であり、ＡＰが期待するＴＦへの応答フレームのＡＰにおける受信電力である。３３５はＲｅｓｅｒｖｅｄである。３３６は、Ｔｒｉｇｇｅｒ Ｄｅｐｅｎｄｅｎｔ Ｕｓｅｒ Ｉｎｆｏであり、Ｔｒｉｇｇｅｒ Ｔｙｐｅ３１１に依存して内容が変わる部分である。

図４Ａ、図４Ｂを用いて実施形態１の通信システムにおける動作を説明する。通信システムにおける機器の構成は、図１のＡＰ１０１と４台の端末１０２－１～１０２－４とする。以下、端末１０２－１～１０２－４をＳＴＡ１～４と記載する場合もある。

図４Ａは、ＡＰ１０１が管理する端末テーブル４００を示す。端末テーブル４００は記憶部２０１に保持されている。４０１はテーブルのインデックスである。なお、以降の説明では、インデックス番号を付記して端末名称として用いることがある。つまり、インデックス＝１の端末がＳＴＡ１または端末１０２－１となる。４０２は端末のＭＡＣアドレスである。ＭＡＣアドレス４０２は、４８ビットを８ビット毎にコロン（：）で区切った表示形式となっている。４０３はＡＩＤであり、ＡＰ１０１とＳＴＡとの間でＡｓｓｏｃｉａｔｉｏｎ（接続）が確立したときに、ＡＰ１０１からＳＴＡに通知する識別子である。

４０４はＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅであり、ＩＥＥＥ８０２．１１規格のＭａｎａｇｅｍｅｎｔフレーム内のＨＥ ＣａｐａｂｉｌｉｔｉｅｓのＴｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ Ｄｕｒａｔｉｏｎによって通知される情報である。なお、ＨＥは、High Efficiencyの略である。ここで、Ｔｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ Ｄｕｒａｔｉｏｎは２ｂｉｔ数で、０／１／２が、それぞれＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの０（ゼロ）μｓｅｃ／８μｓｅｃ／１６μｓｅｃに相当する。このＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅという名称は、Ｔｒｉｇｇｅｒ Ｆｒａｍｅによって指定されたＲＵ（リソースユニット）を使った送信のための準備時間の最小値という意味に由来する。なお、Ｍａｎａｇｅｍｅｎｔフレームとは、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｅｓｔ、Ａｕｔｈｅｎｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔなどである。ＡＰ１０１は、Ｔｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ Ｄｕｒａｔｉｏｎを参照することにより、ＳＴＡとの接続処理において、そのＳＴＡがＲＵを使うために必要とする準備時間を把握できる。

以下では、ＡＰ１０１が１台、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが８μｓｅｃの端末が２台（端末１０２－１、１０２－３）、１６μｓｅｃの端末が２台（端末１０２－２、１０２－４）から構成されている通信システムを例として説明する。

図４Ｂは、実施形態１の通信システムにおける動作シーケンスを示す図である。比較のために、図４Ｂの左側に一般的な動作シーケンスを、右側に本実施形態の制御を適用した場合の動作シーケンスを示す。図４Ｂにおいて、時間は下から上へ進行している。なお、図４Ｂにおいて、４０５はＭＡＣ ｈｅａｄｅｒであり、図３ＡのＦｒａｍｅ Ｃｏｎｔｒｏｌ３０１からＴＡ３０４をひとまとめに表現したものである。また、Ｃｏｍｍｏｎ Ｉｎｆｏ３０５からＦＣＳ３０８までは、図３Ａの符号をそのまま用いている。図４Ｂの動作シーケンスは、ＡＰ１０１がＢａｓｉｃ Ｔｒｉｇｇｅｒ Ｆｒａｍｅを送信し、宛先端末からデータを受信し、応答を送信する、という一連のシーケンスを２回繰り返した様子を示している。

図４Ｂの左側に示されている一般的な動作シーケンスでは、ＡＰ１０１は、第１のＴＦを構築する際に、ＡＩＤの番号順にＡＩＤ＝１（ＳＴＡ１）とＡＩＤ＝２（ＳＴＡ２）の端末を選択し、Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６のパラメータを決定する。さらに、ＴＦ３００のＰａｄｄｉｎｇ３０７の長さが、ＳＴＡ１とＳＴＡ２のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの最大値である１６μｓｅｃに相当する値に設定される。このように、ｐａｄｄｉｎｇ３０７を最も大きなＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅに対応した値とすることで、全ての端末が準備時間を確保できるようしている。最後にＦＣＳ３０８を算出し、ＴＦの送信を完了する。

この第１のＴＦを受けた２台の端末（ＳＴＡ１，ＳＴＡ２）は、それぞれＨＥ ＴＢ ＰＰＤＵ４０６をＡＰ１０１に向けて送信する。ＨＥ ＴＢ ＰＰＤＵは「High Efficiency Trigger Based Physical layer Protocol Data Unit」である。これらのＨＥ ＴＢ ＰＰＤＵを受けたＡＰ１０１は、Ｍｕｌｔｉ－ＳＴＡ ＢＡ４０７を２台の端末（ＳＴＡ１，ＳＴＡ２）に返す。ＢＡは、「Block Ack」である。続いて、ＳＴＡ３とＳＴＡ４を宛先とする第２のＴＦ３００の送信においても同様な処理が行われる。このような一般的な動作シーケンスでは、第１と第２のＴＦのｐａｄｄｉｎｇの長さは、いずれも１６μｓｅｃに相当する値となる。

次に、図４Ｂの右側に示されている、本実施形態による動作シーケンスを説明する。このシーケンスでは、ＡＰ１０１は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが同じ値を持つ端末群をＴＦ３００の宛先とする。つまり、第１のＴＦの宛先として、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが１６μｓｅｃであるＳＴＡ２とＳＴＡ４を選択する。次に、第２のＴＦの宛先として、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが８μｓｅｃであるＳＴＡ３とＳＴＡ４を選択する。このようにＴＦの宛先端末を選択すると、第１のＴＦではｐａｄｉｎｇの長さが１６μｓｅｃとなるが、第２のＴＦではｐａｄｉｎｇの長さを８μｓｃｅとすることができる。したがって、図４Ｂの左側の一般的な動作シーケンスと比べて、本実施形態の動作シーケンスでは８μｓｅｃの時間短縮が達成される。なお、選択順は同じＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを有する端末が連続すればよく、例えば、ＳＴＡ１→ＳＴＡ３→ＳＴＡ２→ＳＴＡ４の順であってもよい。

なお、ＴＦの宛先として、接続中の任意の端末を指定するときは、Ｕｓｅｒ ＩｎｆｏのＡＩＤ１２を０（ゼロ）にする。このときのｐａｄｄｉｎｇ３０７は、アソシエートしている端末群のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの最大値に相当する値とする。また、ＴＦの宛先として、未接続の端末を許容するときは、Ｕｓｅｒ ＩｎｆｏのＡＩＤ１２を２０４５にする。このときのｐａｄｄｉｎｇ３０７は、１６μｓｅｃに相当する値とする。ここで１６μｓｅｃは、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの規定値の最大値である。以上のようにｐａｄｄｉｎｇ３０７を設定することで、ＡＩＤを特定できない端末にＲＵを割り当てることになっても、そのＲＵ利用のための十分な準備時間を端末に確保させることができる。

以上の動作を図５のフローチャートを参照してさらに説明する。ここで、特に断りがない限り、処理の主体はＡＰ１０１の制御部２０２である。図５（ａ）は、管理フレーム受信処理を説明するフローチャートである。この処理により、ＡＰ１０１は、無線ネットワーク１００に接続された複数の端末から、トリガーフレームにより使用するＲＵが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する。まず、Ｓ５０１で、ＡＰ１０１は、端末との接続や再接続の処理を行う。その際、ＭＡＣアドレスとＡＩＤを関連付けて、管理情報として保持する。Ｓ５０２で、ＡＰ１０１は、端末からのＭａｎａｇｅｍｅｎｔフレームに含まれるＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを取得する。ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅは、ＲＵの指定を受け付けた端末が送信を開始するのに必要な準備時間を示す。

図５（ｃ）は、全トリガーフレーム送信処理を説明するフローチャートである。Ｓ５２１において、ＡＰ１０１は、ＴＦのタイプとＴＦの宛先端末を決定する。ここで、ＴＦのタイプ、ユースケース、システムの状態などによっては、全ての端末が宛先となるとは限らない。Ｓ５２２において、ＡＰ１０１は、Ｓ５０１で取得したＭＡＣアドレスとＡＩＤ、Ｓ５０２で取得したＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを用いて端末テーブル４００を生成する。Ｓ５２３において、ＡＰ１０１は、同じＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを有する端末が連続するように端末の選択順を決定する。例えば、端末テーブル４００の例の場合、ｉｎｄｅｘが２→４→１→３のように選択順が決定される。

Ｓ５２４において、ＡＰ１０１は、複数の端末から１つのＴＦの宛先となる端末を選択する。例えば、ＴＦが含みうる最大宛先数以下の端末が選択される。図４の例では、宛先数を２とする（ＨＥ ＴＢ ＰＰＤＵに用いられるＲＵの割り当て方に起因して決定される）が、これに限られるものではない。ＡＰ１０１は、Ｓ５２３で決定された選択順に従って２つずつの端末を宛先端末として選択する。そして、Ｓ５２５において、ＡＰ１０１は、Ｓ５２４で選択された宛先端末へトリガーフレームを送信し、対応するデータを受信し、応答を送信する。Ｓ５２６でトリガーフレームを未送信の端末があれば（Ｓ５２６でＮＯ）、処理はＳ５２４に戻り、次の選択順の端末が宛先端末に選択される。すべての端末についてトリガーフレームの送信を終えたると（Ｓ５２６でＹＥＳ）、本処理は終了する。

図５（ｂ）は、Ｓ５２５におけるＴＦ送信／データ受信／応答送信の処理を説明するフローチャートである。Ｓ５１１で、ＡＰ１０１は、ＴＦにおける最後のＰｅｒ Ｕｓｅｒ Ｉｎｆｏに続いて付加されるＰａｄｄｉｎｇ３０７の長さを決定し、ＴＦを送信する。すなわち、ＡＰ１０１は、Ｓ５２４で選択された端末の準備時間を確保するためのパディングを付加して、選択された端末のためのＴＦを送信する。Ｓ５１２で、ＡＰ１０１は、ＴＦ３００の宛先端末からの応答フレーム（ＨＥ ＴＢ ＰＰＤＵ４０６）を受信する。Ｓ５１３で、ＡＰ１０１は、応答フレームの受信からＳＩＦＳの期間が経過した後、Ｍｕｌｔｉ－ＳＴＡ ＢＡ４０７（Ｂｌｏｃｋ Ａｃｋ）を送信する。Ｓ５１４の処理は、実施形態２で必要となる処理であり、実施形態１では省略される。

以上のように、実施形態１によれば、トリガーフレーム中のｐａｄｄｉｎｇを必要最小限の長さにすることができ、無線媒体の利用効率が向上する。結果、ＩＥＥＥ８０２．１１ａｘが目指すシステム全体のスループット向上にも寄与することができる。

＜実施形態２＞
前述の実施形態１では、ＴＦに含めるＰｅｒ Ｕｓｅｒ Ｉｎｆｏが２個の例であった。これは、ＨＥ ＴＢ ＰＰＤＵ４０６が使うＲＵの割り当て方に起因している。しかしながら、ＩＥＥＥ８０２．１１ａｘ規格では、２０ＭＨｚ帯で運用するときは、最大宛先数は９であり、１つのＴＦに最大９個までのＰｅｒ Ｕｓｅｒ Ｉｎｆｏを指定可能である。そこで、Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏを２に限定しない実施形態の動作を説明する。実施形態２によれば、端末がＭａｎａｇｅｍｅｎｔフレーム（ＨＥ ＣａｐａｂｉｌｉｔｉｅｓのＴｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ Ｄｕｒａｔｉｏｎ）で通知した値とは異なる値がｐａｄｄｉｎｇ３０７の値に反映される場合がある。

まず、実施形態２を実現するためのＴＦ送信処理テーブルについて、図７を用いて説明する。図７のＴＦ送信処理テーブル７００は、実施形態１の端末テーブル４００に２つの情報を追加したものである。インデックス４０１、ＭＡＣアドレス４０２、ＡＩＤ４０３、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ４０４は図４と同じである。７０１はＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐである。ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐ７０１は、端末からのＭａｎａｇｅｍｅｎｔフレームによって通知されたＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅとは異なる値を、その端末のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅとして一時的に扱うための変数である。ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐ７０１の役割は、図６のフローチャートを参照した説明により、より明らかとなる。

７０２は送信済みフラグであり、値はクリア状態またはセット状態を示す１ｂｉｔ値である。送信済みフラグ７０２がクリア状態のときは、対応するｉｎｄｅｘの端末に対してＴＦが未だ送信されていないことを示す。それに対して、ＴＦが送信された端末については、送信済みフラグ７０２がセット状態になる。

続いて、図５（ａ）、（ｂ）と図６のフローチャートを参照して、実施形態２によるＴＦの生成と送信の動作について説明する。ここで、特に断りがない限り、処理の主体はＡＰ１０１の制御部２０２である。

まず、制御フローの基本的な考え方を示す。それは、「可能な限り、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの小さい端末のみでＴＦを構成する。しかし、そのように構成することによって送信ＴＦの総数が増える場合は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が大きい端末と一緒のＴＦで指定するように構成する」、ということである。このように複数のＴＦを構成するのは、ｐａｄｄｉｎｇを除いたＴＦの長さがｐａｄｄｉｎｇ長の差よりも長いことによる。つまり、宛先がＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝０μｓｅｃの端末のみから成るＴＦを独立に送信するよりも、宛先にＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８また１６μｓｅｃの端末を含めて送信した方が無線媒体の占有時間が短くなる。したがって、本実施形態では、送信されるＴＦの数（総数）が増加しない限りにおいて、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ（準備時間）が異なる端末を１つのトリガーフレームに混在させないように端末が選択される。

図５（ａ）のＳ５０１で、ＡＰ１０１は、端末との接続や再接続の処理をおこなう。その際、ＴＦ送信処理テーブルのＭＡＣアドレス４０２とＡＩＤ４０３を更新する。Ｓ５０２で、ＡＰ１０１は、端末からのＭａｎａｇｅｍｅｎｔフレームに含まれるＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを取得し、ＴＦ送信処理テーブル７００のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ４０４を設定・更新する。

図５（ｂ）のＳ５１１からＳ５１４は、ＴＦ送信／データ受信／応答送信の一連の処理である。Ｓ５１１～Ｓ５１３における動作は実施形態１と同様である。すなわち、Ｓ５１１で、ＡＰ１０１は、ＴＦにおける最後のＰｅｒ Ｕｓｅｒ Ｉｎｆｏに続いて付加されるＰａｄｄｉｎｇ３０７の長さを決定し、これを付加してＴＦを送信する。Ｓ５１２で、ＡＰ１０１は、ＴＦ３００の宛先端末からの応答フレームを受信する。Ｓ５１３で、ＡＰ１０１は、Ｍｕｌｔｉ－ＳＴＡ ＢＡ（Ｂｌｏｃｋ Ａｃｋ）を送信する。Ｓ５１４で、ＡＰ１０１は、ＴＦ送信処理テーブルのＴＦ送信済みフラグ７０２をセット状態にする。

なお、ＴＦ送信から応答送信までの一連の処理でエラーが発生した場合の処理は一般的なエラー処理となるため、説明を省略する。以下の説明ではこれらの一連の処理が正常に進む場合について記している。

Ｓ６０１で、ＡＰ１０１は、ＴＦのタイプとＴＦの宛先端末を決定する。ここで、ＴＦのタイプ、ユースケース、システムの状態などによっては、全ての端末が宛先となるとは限らない。Ｓ６０２で、ＡＰ１０１は、ＴＦ送信処理テーブル７００の初期化をおこなう。ＴＦ送信処理テーブル７００の初期化とは、ＴＦの宛先端末に関して、テーブル内のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐ７０１をＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ４０４と同じ値にセットし、かつ、送信済みフラグ７０２をクリア状態にすることである。ここで、ＴＦの宛先ではない端末については、送信済みフラグ７０２を便宜的にセット状態にする。送信済みフラグ７０２をセット状態にすることによって、その端末を、Ｓ６０３以降の処理の対象外、つまり、ＴＦの宛先の対象外にすることができる。

次にＳ６０３で、ＡＰ１０１は、利用可能な無線帯域を基に１つのＴＦ当たりの最大宛先数を決定する。たとえば、２０ＭＨｚの帯域で２６ｔｏｎｅから成るＲＵ（リソースユニット）を割り当てる場合は、最大宛先数は９となる。ここで、この最大宛先数は、Ｓ６０１から始まる全トリガーフレーム送信処理において一定であるとしている。次に、Ｓ６０４で、ＡＰ１０１は、宛先端末の全てにＴＦを送信するために必要なＴＦの数を算出する。このＴＦ数は、ＴＦのタイプがＮＦＲＰ以外のときは、天井関数（宛先端末の総数／１ＴＦ当たりの最大宛先数）で算出することが可能である。ここで、天井関数（ｘ）とは、実数ｘ対して、ｘ以上の最小の整数を返すものである。すなわち、送信されるＴＦの数は、ＴＦの送信対象である複数の端末の台数を最大宛先数で割って得られた実数値以上で最小の整数値である。Ｓ６０５で、ＡＰ１０１は、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔの初期値として０（ゼロ）を設定する。

Ｓ６０６で、ＡＰ１０１は、ＴＦ送信処理テーブル７００に存在する宛先端末の内、「ＭｉｎＴｒｉｇＰｒｏｃ_ｔｍｐ＝ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔ」、かつ、「送信済みフラグ＝クリア」の端末数をカウントする。そして、ＡＰ１０１は、得られた端末数をＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅとする。Ｓ６０７で、ＡＰ１０１は、ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅがＳ６０３で決定された最大宛先数以上であるかを判定する。「ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ≧最大宛先数」と判定された場合（Ｓ６０７でＹＥＳ）、処理はＳ６０８に進む。

Ｓ６０８で、ＡＰ１０１は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔである端末群から、最大宛先数に相当する数の端末を選択する。Ｓ６０９で、ＡＰ１０１は、Ｓ６０８で選択した端末との間で、図５（ｂ）に示したＴＦ送信／データ受信／応答送信の一連の処理（Ｓ５１１～Ｓ５１４）を実行する。その後、処理はＳ６０６に戻る。

他方、Ｓ６０７において「ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ＜最大宛先数」と判定された場合（Ｓ６０７でＮＯ）、処理はＳ６１０に進む。Ｓ６１０で、ＡＰ１０１は、ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅが１以上であるか否かを判定する。「ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ≧１」の場合（Ｓ６１０でＹＥＳ）、処理はＳ６１１に進み、そうでない場合処理はＳ６１４へ進む。Ｓ６１１では、ＡＰ１０１は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔである端末群を選択してＴＦ送信を行った場合に、すべての端末に送信されるＴＦ数が増加するか否かを判定する。

具体的には、［１＋天井関数（（「送信済みフラグ＝クリア」の端末数－ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ）／最大宛先数）≦天井関数（（「送信済みフラグ＝クリア」の端末数）／最大宛先数）］による判定をおこなう。この判断式の左辺の第一項の「１」は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐ＝ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔである端末を宛先とした「１つ」のＴＦを送信することを意味する。続く左辺の第二項は、ＴＦ送信処理テーブル７００において「送信済みフラグ＝クリア」となっている端末の集合から、第一項の１つのＴＦの宛先となった端末を除いた集合に存在するすべての端末にＴＦを送信するのに必要なＴＦ数である。また、比較式の右辺は、単純に天井関数を用いて、ＴＦが未送信となっている全ての端末（「送信済みフラグ＝クリア」となっている全ての端末）にＴＦを送信するのに必要なＴＦ数を計算している。

よって、上記判断式による判断は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔに等しい端末のみをＴＦの宛先とした場合に、全トリガーフレーム送信処理で送信されるＴＦ数が増加するか否かを判断していることになる。言い換えると、Ｓ６０４で求めたＴＦ数が増加するか否かを判断することになる。

たとえば、送信済みフラグ＝クリアの端末の全数が１３、ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅの数が４、最大端末数が９であるときは、Ｓ６１１の判断式の左辺は２、右辺は２となる。これは、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔに等しい端末のみをＴＦの宛先とした場合でも、必要な送信ＴＦの総数に変わりがないことを示している。この場合は、ＴＦ数は増加しないので（Ｓ６１１でＮＯ）、処理はＳ６１２に進む。Ｓ６１２で、ＡＰ１０１は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔに等しい端末を選択する。そして、Ｓ６１３で、ＡＰ１０１は、Ｓ６１２で選択した端末に対して、ＴＦ送信／データ受信／応答送信の一連の処理をおこなう。こうして、ＡＰ１０１は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔの端末のみを宛先としたＴＦを送信する。

Ｓ６１４で、ＡＰ１０１は、ＴＦ送信処理テーブル７００を参照して送信済みフラグ＝クリアである端末の数をカウントする。カウント結果が０（ゼロ）でない場合、ＴＦが未送信となっている端末が存在するため、処理はＳ６１５へ進む。Ｓ６１５で、ＡＰ１０１は、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔを次の値に設定する。そして、処理はＳ６０６に戻る。ここで、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔを次の値に設定するとは、現在の値が０の場合は８へ、現在の値が８の場合は１６へ設定することである。なお、現在の値が１６の場合に対する次の値は存在しないが、この制御では、現在の値が１６でＳ６１５に進んでくることはない。ただし、ソフトウェア（プログラム）の実装上は、現在の値が１６でＳ６１５へ処理が進んだ場合には本処理を終了するようにする。

次に、Ｓ６１１においてＴＦ数が増加すると判断され（Ｓ６１１でＹＥＳ）、処理がＳ６１６へ進む場合を説明する。たとえば、「送信済みフラグ＝クリア」である端末の全数が１３、ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅの数が２、最大端末数が９である場合、Ｓ６１１で説明した判断式における左辺は３、右辺は２となり、判断式の関係は成立しなくなる。これは、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐがｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔに等しい端末のみをＴＦの宛先とした場合に、必要なＴＦの全数が増加することを示している。

Ｓ６１６で、ＡＰ１０１は、「ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐ＝ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔ」かつ「送信フラグ＝クリア」である端末のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値を次の値に設定する。ここで、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値を次の値に設定するとは、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔと同様に、現在の値が０の場合は８へ、現在の値が８の場合は１６へ設定することである。そして、処理はＳ６１５へ進み、ＡＰ１０１は、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔを次の値に設定し、処理をＳ６０６に戻す。なお、Ｓ６１５の制御と同様に、現在の値が１６の場合にＳ６１６が実行されることはない。

Ｓ６１４で、「送信済みフラグ＝クリア」である端末のカウント結果が０（ゼロ）の場合、すなわち、ＴＦが未送信となっている端末が存在しない場合は、全トリガーフレーム送信処理は終了する。

なお、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが１６であって、送信ＴＦの総数が増加しない場合は、６０７で最大宛先数を選択しなくてもよい。たとえば、送信済みフラグ＝クリアの端末が１６台で、最大宛先数が９の場合、必要なＴＦ数は２である。このとき、図６のフローチャートに従うと、宛先数（Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６の数）＝９のＴＦと宛先数＝７のＴＦを送信することになる。この場合、宛先数＝８の２つのＴＦを送信するようにしてもよい。

＜＜フローチャート進行例１＞＞
ここで、フローチャートの理解の手助けとして、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が０、８、１６μｓｅｃである端末の数がそれぞれ１２、１１、１７個である場合の図６に示す処理の流れを説明する。

まず、Ｓ６０１でＴＦの宛先端末が決定され、Ｓ６０２でＴＦ送信処理テーブル７００が初期化され、Ｓ６０３で最大宛先数が９に、Ｓ６０４で必要なＴＦ数が５に、Ｓ６０５でｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが０に設定される。ＴＦ送信処理テーブル７００の初期化により、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値がＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐに設定される。

Ｓ６０６でＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅにＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０である端末の数である１２が設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝１２）≧最大宛先数（＝９）であるので、処理はＳ６０７でＹＥＳに分岐し、Ｓ６０８においてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０である９個の端末が選択される。Ｓ６０９において、Ｓ６０８で選択された端末に対応する９個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第１のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアである端末の台数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が０、８、１６μｓｅｃに対して３、１１、１７個となる。

次に、Ｓ６０６で、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０である端末の数（３）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝３）＜最大宛先数（＝９）であるので、処理はＳ６０７でＮｏに分岐する。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝３）≧１であるので、処理はＳ６１０でＹＥＳに分岐する。Ｓ６１１において、上述した判断式において左辺が５、右辺が４となるので、ＴＦ数が増加すると判定され、処理はＹＥＳに分岐する。Ｓ６１６においてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値が０μｓｅｃである端末のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値を次の値（８μｓｅｃ）に設定する。結果、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０、８、１６μｓｅｃに対し、端末の数は０、１４＝（３＋１１）、１７となる。Ｓ６１７でｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが次の値（８μｓｅｃ）に設定される。

次に、Ｓ６０６で、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが８である端末の数（１４）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝１４）≧最大宛先数（＝９）であるので、処理はＳ６０７でＹＥＳに分岐する。Ｓ６０８において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０である９個の端末が選択される。Ｓ６０９において、Ｓ６０８で選択された端末に対応する９個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第２のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアの端末の台数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が、０、８、１６μｓｅｃに対して０、５、１７となる。

次に、Ｓ６０６でＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが８である端末の数（５）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝５）＜最大宛先数（＝９）であるので、処理はＳ６０７でＮＯに分岐する。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝３）≧１であるので、処理はＳ６１０でＹＥＳに分岐する。Ｓ６１１において、上述した判断式において左辺が３、右辺が３になるので、ＴＦ数は増加しないと判定され、処理はＮＯに分岐する。Ｓ６１２において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが８である５個の端末が選択される。Ｓ６１３において、Ｓ６１２で選択された端末に対応する５個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第３のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアの端末の個数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値が０、８、１６μｓｅｃに対して０、０、１７となる。その後、処理はＳ６１４でＮＯに分岐し、Ｓ６１５でｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが次の値（１６μｓｅｃ）に設定される。

Ｓ６０６でＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅにＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である端末の数である１７が設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝１７）≧最大宛先数（＝９）であるので、処理はＳ６０７でＹＥＳに分岐し、Ｓ６０８においてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である９個の端末が選択される。Ｓ６０９において、Ｓ６０８で選択された端末に対応する９個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第４のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアである端末の台数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が０、８、１６μｓｅｃに対して０、０、８個となる。

次に、Ｓ６０６でＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である端末の数（８）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝８）＜最大宛先数（＝９）であるので、処理はＳ６０７でＮＯに分岐する。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝８）≧１であるので、処理はＳ６１０でＹＥＳに分岐する。Ｓ６１１において、上述した判断式において左辺が１、右辺が１になるので、ＴＦ数は増加しないと判定され、処理はＮＯに分岐する。Ｓ６１２において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である８個の端末が選択される。Ｓ６１３において、Ｓ６１２で選択された端末に対応する８個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第５のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアの端末の個数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値が０、８、１６μｓｅｃに対して０、０、０となる。その後、処理はＳ６１４でＹＥＳに分岐し、処理が終了する。

＜＜フローチャート進行例２＞＞
さらにもう一つの例として、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が０、８、１６μｓｅｃである端末の数がそれぞれ０、５、６のときのフローチャートの流れを説明する。

まず、Ｓ６０１でＴＦの宛先端末が決定され、Ｓ６０２でＴＦ送信処理テーブル７００が初期化され、Ｓ６０３で最大宛先数が９に、Ｓ６０４で必要なＴＦ数が２に、Ｓ６０５でｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが０に設定される。ＴＦ送信処理テーブル７００の初期化により、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値がＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐに設定される。

Ｓ６０６でｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが０である端末の数（０）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝０）であるので、処理はＳ６０７でＮＯに分岐し、さらにＳ６１０でＮＯに分岐する。その後、処理はＳ６１４（ＮＯ）からＳ６１５へ進み、ｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが次の値（８μｓｅｃ）に設定される。

次に、Ｓ６０６でＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが８である端末の数（５）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝５）＜最大宛先数（＝９）であるので、処理はＳ６０７でＮＯに分岐する。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝３）≧１であるので、処理はＳ６１０でＹＥＳに分岐する。Ｓ６１１において、上述した判断式において左辺が２、右辺が２になるので、ＴＦ数は増加しないと判定され、処理はＮＯに分岐する。Ｓ６１２において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが８である５個の端末が選択される。Ｓ６１３において、Ｓ６１２で選択された端末に対応する５個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第１のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアの端末の個数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値が０、８、１６μｓｅｃに対して０、０、６となる。その後、処理はＳ６１４でＮＯに分岐し、Ｓ６１５でｐａｄｄｉｎｇ_ｃｕｒｒｅｎｔが次の値（１６μｓｅｃ）に設定される。

次に、Ｓ６０６でＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である端末の数（６）がＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅに設定される。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝６）＜最大宛先数（＝９）であるので、処理はＳ６０７でＮＯに分岐する。ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅ（＝６）≧１であるので、処理はＳ６１０でＹＥＳに分岐する。Ｓ６１１において、上述した判断式において左辺が１、右辺が１になるので、ＴＦ数は増加しないと判定され、処理はＮＯに分岐する。Ｓ６１２において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐが１６である６個の端末が選択される。Ｓ６１３において、Ｓ６１２で選択された端末に対応する６個のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを持つ「第２のＴＦ」が送信される。結果、ＴＦ送信処理テーブル７００において送信済みフラグ＝クリアの端末の個数は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ_ｔｍｐの値が０、８、１６μｓｅｃに対して０、０、０となる。その後、処理はＳ６１４でＹＥＳに分岐し、処理が終了する。

＜実施形態３＞
実施形態３では、上述したＳ５２１、Ｓ６０１の処理（ＴＦのタイプと宛先端末の決定）において、２つの制約条件を考慮する。

第１の制約条件はＴｒｉｇｇｅｒ Ｔｙｐｅに基づく。実施形態１，２で説明したように、一連の処理で複数のＴＦを送信する際に、各端末をどのＴＦの宛先とするかが調整可能であることが前提となっている。ところが、図３ＢのＴｒｉｇｇｅｒ Ｔｙｐｅ３１１の内、ＭＵ－ＢＡＲ（Multi User Block Ack Request）、ＭＵ－ＲＴＳ、ＧＣＲ ＭＵ－ＢＡＲの場合は、この調整が複雑なものとなる。なぜなら、これらのＴＦの宛先は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅとは独立に、ＴＦ送信時以前に発生したダウンリンクデータによって決定してしまうからである。もし、調整をおこなうとすれば、ダウンリンクのデータを保持し、ある程度の量を蓄積してから、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が同じ端末に対して、ダウンリンク・マルチユーザーを行うことになる。

一方、上記以外のＴｒｉｇｇｅｒ Ｔｙｐｅについては、複数のＴＦにおいて各端末をどのＴＦの宛先とするかの調整が、データの保持などの処理をおこなうことなく実行可能である。したがって、Ｓ６０１では、ＭＵ－ＢＡＲ、ＭＵ－ＲＴＳ、ＧＣＲ ＭＵ－ＢＡＲ以外のタイプのＴＦであることを第１の制約条件とする。より一般化して表現すると、ダウンリンク通信に基づいて宛先端末が決定される種別以外のＴＦであることを第１の制約条件とする。これにより、ダウンリンク通信に基づいて宛先端末が決定される種別以外のＴＦが送信される端末でもって、ＴＦの宛先となる複数の端末が構成される。

次に、第２の制約条件について説明する。Ｓ６０１において宛先端末とすべき複数の端末を決定するための第２の制約条件は、「応答の有効データが同じ長さになるトリガーフレームの送信対象の端末を宛先端末」である。本実施形態では、第２の制約条件は、ＨＥ ＴＢ ＰＰＤＵ４０６の有効情報の差異に基づくものとなる。ＩＥＥＥ８０２．１１ａｘでは、ＴＦへの応答フレームの宛先であるＡＰにおける受信電力の変動を抑えるために、各ＳＴＡのＨＥ ＴＢ ＰＰＤＵの終わりを揃えることにしている。そのため、ＳＴＡは、Ｔｒｉｇｇｅｒ Ｔｙｐｅで指定された情報が存在しない場合でも、長さを揃えるためにフレームにペイロードパディングを追加しなければならない。

ここで、フレームに追加するペイロードパディングの長さについて説明する。たとえば、ＴＦで割り当てるＲＵ（リソースユニット）が２６－ｔｏｎｅから成り、ストリーム数が１、ＭＣＳが２５６－ＱＡＭ、Ｃｏｄｉｎｇ Ｒａｔｅが３／４、ＧＩ（Ｇｕａｒｄ Ｉｎｔｅｒｖａｌ）が１．６μｓｅｃであるとする。この場合、ＨＥ ＴＢ ＰＰＤＵのデータレートは、１０Ｍｂｐｓとなる。このデータレートによって８μｓｅｃで通信できるデータ量は、８０ｂｉｔ＝１０バイトである。つまり、ｐａｄｄｉｎｇ３０７による８μｓｅｃの時間短縮は、１０バイトのペイロードパディングによって相殺されることになる。

以上より、ｐａｄｄｉｎｇ３０７の総和の最小化においては、フレームへのペイロードパディングの追加を発生させないという制約を加えることで、無線媒体の効率的利用の効果が向上する。ここで、各Ｔｒｉｇｇｅｒ Ｔｙｐｅについて、各端末からの有効情報の長さに差異がなくなる、または、フレームへのペイロードパディングの追加が不必要となる条件を示す。

Ｂａｓｉｃ Ｔｒｉｇｇｅｒの場合、各端末の送信バッファ量が同じ値であるときは各端末からの有効情報の長さに差異がなくなる。ここで、送信バッファ量は、ＢＳＲ（Buffer Status Report）によって、各端末から通知される。ＡＰ１０１は、Ｓ６０１において送信バッファ量が同じ端末をＴＦの宛先端末に決定することで効率を向上させることができる。なお、送信バッファ量の値が異なる場合でも、ＲＵ Ａｌｌｏｃａｔｉｏｎ３２９やＭＣＳ３３１によって、ペイロードパディングの発生を抑制できるが、処理が複雑となる。なお、ＭＵ－ＲＴＳの場合で、後続のＴＦがＵＬ（Ｕｐ Ｌｉｎｋ）のみの場合は、Ｂａｓｉｃ Ｔｒｉｇｇｅｒの場合と同じ条件となる。

ＢＦＲＰ（Beamforming Report Poll）の場合、各端末に要求するＣＱＩ（Channel Quality Indication）が同じ数であるときは、各端末からの有効情報の長さに差異がなくなる。したがって、ＡＰ１０１は、Ｓ６０１においてＣＱＩが同じである端末をＴＦの宛先端末に決定することで効率を向上させることができる。また、ＢＳＲＰ（Buffer Status Report Poll）の場合、１つのＴＩＤ（Traffic Identifier）または全ＴＩＤについて通知をする場合、各端末からの有効情報の長さに差異がなくなる。ＢＱＲＰ（Bandwidth Query Report Poll）の場合は、各端末からの有効情報の長さに差異がないため、特に制約条件は存在しない。ＮＦＲＰ（NDP Feedback Report Poll）の場合も、各端末からの有効情報の長さに差異がないため、特に制約条件は存在しない。

なお、ＩＥＥＥ８０２．１１ａｘにおいて、受信側に時間的猶予を与えるフレームへのペイロードパディングの追加という規定には、Ｐａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎと呼ばれるものがある。これは、ＩＥＥＥ８０２．１１ａｘの各ＰＰＤＵのデータ部の後ろに付加されるフィールド（信号）である。たとえば、ＨＥ ＴＢ ＰＰＤＵ４０６の場合、ＡＰは、ＴＦのＰａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎ３２２によって付加フィールドの長さ（ｄｕｒａｔｉｏｎ）、符号化形式、変調方式を指定できる。しかし、本実施形態では、ＨＥ ＴＢ ＰＰＤＵ４０６の送信側である端末の組み合わせを変えても、Ｐａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎの長さに差異は発生しないものとしている。

以上説明したように、実施形態３によれば、Ｓ６０１で第１の制約条件および第２の制約条件を考慮し、複数のＴＦにおける宛先端末の順序を調整することによって、無線媒体の有効利用の実効性を向上させることができる。

＜実施形態４＞
実施形態４では、Ｔｒｉｇｇｅｒ ＴｙｐｅがＮＦＲＰ（Null Data Packet Feedback Report Poll）であり、かつ、端末との接続および切断が少ない場合における、ＴＦ送信／データ受信の効率化を説明する。

まず、ＮＦＲＰ ＴＦの構成を説明する。ＮＦＲＰ ＴＦの宛先指定方法は、他のＴｒｉｇｇｅｒ ＴｙｐｅのＴＦとは異なっている。つまり、Ｐｅｒ Ｕｓｅｒ ＩｎｆｏのＡＩＤ１２によって、ひとつひとつの端末を指定するのではなく、Ｓｔａｒｔｉｎｇ ＡＩＤから規定数の範囲のＡＩＤを持つ端末が宛先となっている。

図８は、ＮＦＲＰ ＴＦにおけるＰｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６のデータ構成例を示す図である。３４１は、Ｓｔａｒｔｉｎｇ ＡＩＤであり、このＴＦの宛先端末群の先頭ＡＩＤを示す。長さは１２ビットである。ここで、Ｓｔａｒｔｉｎｇの意味は、これ以降の連続したＡＩＤ値を持つ端末を宛先とする、という意味である。３４２と３４４は、Ｒｅｓｅｒｖｅｄである。

３４３は、Ｆｅｅｄｂａｃｋ Ｔｙｐｅであり、長さは４ビットである。このサブフィールドが０のときは、ＴＦは、Ｒｅｓｏｕｒｃｅ Ｒｅｑｕｅｓｔの用途となる。３４５は、Ｔａｒｇｅｔ ＲＳＳＩ（Receive Signal Strength Indicator）であり、長さは７ビットである。３４６は、Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｆｌａｇであり、長さは１ビットである。Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｆｌａｇ３４６は、ＮＤＰが使用するストリーム数を示しており、ビット情報が０の場合はストリーム数が１、ビット情報が１の場合はストリーム数が２であることを示している。

以上のような構造を持つＮＦＲＰ ＴＦの宛先となる端末は、そのＡＩＤが「Ｓｔａｒｔｉｎｇ ＡＩＤ３４１の値」から「Ｓｔａｒｔｉｎｇ ＡＩＤ３４１の値＋規定数（Ｎ）－１」までの端末となる。規定数（Ｎ）は、「定数ｋ」と「ＢＷ３１５の値＋１」と「Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｆｌａｇ３４６の示す内容」との乗算値となる。定数ｋは、ＮＦＲＰ ＴＦが送信要求するＮＤＰの無線媒体上のＯＦＤＭＡのサブキャリアの使い方によって決定され、ＢＷ３１５の値が０（２０ＭＨｚを示す(図３Ｂを参照)）のときは、ｋ＝１８である。この場合、「Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｆｌａｇ３４６の示す内容」が１であれば、規定数（Ｎ）は、１８となる。なお、ＯＦＤＭＡは、Orthogonal Frequency Division Multiple Accessである。

よって、以上のような構成のＮＦＲＰ ＴＦに対して、実施形態１～２に示したような制御を行うとすれば、同じＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを持つ端末のＡＩＤが連続していることが前提となる。そのため、ＡＰ１０１は、システムの端末構成が固定化した後に、同じＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを持つ端末が連続するように、ＡＩＤの再割り当てを行う。

または、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値によって、ＡＩＤの割り当て範囲を３つの区分に分割しておいてもよい。たとえば、上述した規定数（Ｎ）が１８の場合、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝０の１８台の端末に対しては、ＡＩＤを１から順に割りあてる。同様に、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８の１８台の端末に対しては、ＡＩＤを１９から順に割り当て、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝１６の１８台の端末に対しては、３７から順に割り当てる。このようにすると、ＡＩＤの再割り当てをおこなうことなく、かつ、３個のＴＦのｐａｄｄｉｎｇの和を最小にしつつ、全ての端末にＮＦＲＰ ＴＦを送信することができる。

＜実施形態５＞
実施形態５は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が全て等しい場合である。このときは、図５（ｃ）、図６に示した処理をより単純にすることができる。つまり、ＴＦ送信処理テーブルのインデックス４０１またはＡＩＤ４０３の順に、最大宛先数になるまで順次に端末を宛先端末として選択し、Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏを割り当てていけばよい。例えば、Ｓ５２１またはＳ６０１において、無線通信システム内のすべての端末のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが等しい場合に、この処理を実行するようにしてもよい。また、全ての端末のＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが０（ゼロ）のときは、ｐａｄｄｉｎｇ３０７は存在しない。

＜実施形態６＞
実施形態６では、準備時間が長い端末に対応したフィールド（Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ）の後に準備時間が短い端末に対応したフィールドを配置することで、ｐａｄｄｉｎｇ３０７により確保する時間を不要にするもしくは減少させる。なお、以下の説明は、ＮＦＲＰ ＴＦ以外のＴＦに適用されるものとする。

実施形態６では、ＴＦの送信処理においてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの値が大きい端末から順にＰｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６を並べる。たとえば、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８（μｓｅｃ）の端末に対するＰｅｒ Ｕｓｅｒ Ｉｎｆｏの後に、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝０（μｓｅｃ）の端末に対するＰｅｒ Ｕｓｅｒ Ｉｎｆｏが３個並んだＴＦについて考える。この場合、ＴＦのＰｅｒ Ｕｓｅｒ Ｉｎｆｏは、５バイト（オクテット）以上あることから、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８の端末にとっては、自身がＲＵの準備を開始してからＴＦの終端になるまでに、１５バイト以上の時間的猶予が存在することになる。よって、１５バイトの伝送媒体時間が８μｓｅｃ以上であれば、ｐａｄｄｉｎｇ３０７は必要のないものとなる。

以上の考え方は、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝１６（μｓｅｃ）の端末のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを先頭の方に配置する場合も同様である。また、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝１６（μｓｅｃ）の端末とＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８（μｓｅｃ）の端末の組み合わせであっても、Ｐｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６の配置による効果が得られる。ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝８の端末に対応するＰｅｒ Ｕｓｅｒ ＩｎｆｏをＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅ＝１６の端末に対応するＰｅｒ Ｕｓｅｒ Ｉｎｆｏの後ろに並べることでＰａｄｄｉｎｇ３０７を８μｓｅｃにできる可能性がある。したがって、例えば、ＡＰ１０１は、Ｓ５２５またはＳ６０９においてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの異なる端末が宛先端末として選択されている場合に、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの大きい端末のＰｅｒ Ｕｓｅｒ Ｉｎｆｏを先頭の方に配置する。これにより、Ｐａｄｄｉｎｇ３０７で確保する時間を短縮することができる。あるいは、Ｓ５２３において、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの大きい端末に続いてＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅの小さい所定数の端末が並ぶように決定されてもよい。

なお、本実施形態に限らないことであるが、１つのＴＦにおいては、ある１つの端末に割り当てるＲＵ（リソースユニット）は１つである。つまり、端末は、あるＰｅｒ Ｕｓｅｒ Ｉｎｆｏ３０６を解析した後は、後続のＰｅｒ Ｕｓｅｒ Ｉｎｆｏの処理をおこなうことなくＲＵの準備を進めることができる。また、ここまでの実施形態では、ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅをＲＵの準備時間として扱ってきた。しかし、ＦＣＳ３０８の処理時間を考慮して、ＴＦ構成において、ｐａｄｄｉｎｇ３０７とＦＣＳ３０８の順序を入れ替えてもよい。

＜実施形態７＞
次に、さらなる実施形態として、１つのＴＦの宛先を複数の端末から選択する条件として、端末のＤｅｖｉｃｅ Ｃｌａｓｓを加えた例を説明する。

まず、Ｄｅｖｉｃｅ Ｃｌａｓｓを考慮する背景について説明する。Ｄｅｖｉｃｅ Ｃｌａｓｓとは、端末のＡｂｓｏｌｕｔｅ Ｔｒａｎｓｍｉｔ ｐｏｗｅｒ（絶対送信電力）のａｃｃｕｒａｃｙ（精度）とＲＳＳＩ測定の精度とによって、端末をＣｌａｓｓ ＡとＢの２種類に分類したものである。ＲＳＳＩとは、「Received Signal Strength Indicator」である。さらに具体的には、Ｃｌａｓｓ Ａ端末とは、絶対送信電力とＲＳＳＩ測定の精度を、ともに±３ｄＢ以内とする能力を備えた端末である。また、Ｃｌａｓｓ Ｂ端末とは、送信電力の精度を±９ｄＢ、ＲＳＳＩ測定の精度を±５ｄＢ、相対（Ｒｅｌａｔｉｖｅ）送信電力の精度を±３ｄＢとする能力を備えた端末である。なお、ＩＥＥＥ８０２．１１ａｘでは、端末は、自身のＤｅｖｉｃｅ ＣｌａｓｓをＡＰ（アクセスポイント）に通知することになっている。この通知は、例えば、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔなどのマネジメントフレーム内のＨＥ ＰＨＹ Ｃａｐａｂｉｌｉｔｉｅｓ 情報要素によってなされる。

Ｃｌａｓｓ Ａの端末とＣｌａｓｓ Ｂの端末が混在する環境において、Ｃｌａｓｓ Ｂのような送信電力の精度が悪い端末の信号をＯＦＤＭＡ方式によって多重させると、その多重通信を受けたＡＰで各端末からの受信電力に大きな差が発生する可能性がある。この受信電力の差は、ＯＦＤＭＡの直交性を崩し、キャリア間干渉の影響を大きくする。特に、受信電力が小さいときの受信電力の差による影響は大きく、ＡＰの受信性能が劣化する。よって、ＡＰでは、ＯＦＤＭＡ多重通信のためのＴＦ（トリガーフレーム）の宛先を選択する際に、Ｃｌａｓｓ Ａ端末とＣｌａｓｓ Ｂ端末を区別した対応が必要となる。

この対応には、たとえば、以下の三つの方式がある。
・Ｃｌａｓｓ Ａ端末とＢ端末とを同じＴＦの宛先として選択しない。
・Ｃｌａｓｓ Ｂ端末の多重数（宛先数）をＣｌａｓｓ Ａ端末のそれより小さくする。
・Ｃｌａｓｓ ＢのＭＣＳをロバスト性のあるものとする。

以上が、Ｄｅｖｉｃｅ Ｃｌａｓｓに関する背景であり、実施形態７ではこのような背景を考慮して宛先端末の選択を行う。すなわち「ＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅが同じ端末を選択する」というＳ６０８とＳ６１２の処理において、さらに選択条件が加わる。つまり、Ｓ６０８、Ｓ６１２の端末選択において、送信の品質（Ｄｅｖｉｃｅ Ｃｌａｓｓ）が同じ端末同士を優先して選択するという動作になる。

具体例として、Ｓ６０８において、最大宛先数が９で、ＮＵＭ_ＳＴＡ_ｃａｎｄｉｄａｔｅが１５であり、この内、９台がＣｌａｓｓ Ａ端末であり、６台がＣｌａｓｓ Ｂ端末であるとする。このとき、Ｃｌａｓｓ Ａ端末とＣｌａｓｓ Ｂ端末が混在した９台ではなく、Ｃｌａｓｓ Ａの端末のみ９台を選択するという動作になる。残った６台のＣｌａｓｓ Ｂの端末については、Ｓ６１０以降で処理されることになる。

なお、Ｄｅｖｉｃｅ Ｃｌａｓｓを考慮した宛先端末の選択は、上記に限られるものではない。例えば、Ｄｅｖｉｃｅ ＣｌａｓｓＣｌａｓｓ Ａの端末群とＣｌａｓｓ Ｂの端末群を分離し、Ｃｌａｓｓ Ａの端末群とＣｌａｓｓ Ｂの端末群のそれぞれに図６の全トリガーフレーム送信処理を実行するようにしてもよい。

以上のように、上記各実施形態によれば、トリガーフレーム中のｐａｄｄｉｎｇの長さを小さくすることができるので、無線媒体の利用効率が向上するとともに、ＩＥＥＥ ８０２．１１ａｘが目指すシステム全体のスループット向上にも寄与する。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００：無線ネットワーク、１０１：アクセスポイント（ＡＰ）、１０２：端末、２０１：記憶部、２０２：制御部、２０３：機能部、２０４：入力部、２０５：出力部、２０６：通信制御部、２０７：８０２．１１ａｘ制御部、２０８：非８０２．１１ａｘ制御部、２０９：アンテナ

Claims (20)

1. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置であって、
   前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得手段と、
   前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択手段と、
   前記選択手段により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信手段と、を備え、
   前記選択手段は、前記複数の端末から取得した前記能力情報に基づいて準備時間が等しい端末が連続するように前記複数の端末の選択順を決定し、前記選択順に従って前記１つのトリガーフレームの宛先となる端末を選択することを特徴とする通信装置。
2. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置であって、
   前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得手段と、
   前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択手段と、
   前記選択手段により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信手段と、を備え、
   前記選択手段は、前記複数の端末から取得した前記能力情報に基づいて端末を選択し、前記送信手段は、前記選択手段により選択された端末が要求する準備時間のうち最大の準備時間に相当するパディングを付加することを特徴とする通信装置。
3. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置であって、
   前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得手段と、
   前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択手段と、
   前記選択手段により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信手段と、を備え、
   前記選択手段は、前記複数の端末から取得した前記能力情報に基づいて端末を選択し、前記送信手段は、１つのトリガーフレームにおいて、準備時間が長い端末に対応したフィールドの後に準備時間が短い端末に対応したフィールドを配置することで、前記パディングにより確保すべき時間を減少させることを特徴とする通信装置。
4. 前記選択手段は、準備時間が等しい端末が連続するように前記複数の端末の選択順を決定し、前記選択順に従って前記１つのトリガーフレームの宛先となる端末を選択することを特徴とする請求項２または３に記載の通信装置。
5. 前記選択手段は、前記送信されるトリガーフレームの数が増加しない限りにおいて、準備時間が異なる端末を１つのトリガーフレームに混在させないように端末を選択することを特徴とする請求項１から４のいずれか１項に記載の通信装置。
6. 前記送信されるトリガーフレームの数は、前記複数の端末の台数を前記１つのトリガーフレームが含みうる最大宛先数で割って得られた実数値以上で最小の整数値であることを特徴とする請求項１から５のいずれか１項に記載の通信装置。
7. 前記送信手段は、前記選択手段により選択された端末が要求する準備時間のうち最大の準備時間に相当するパディングを付加することを特徴とする請求項１または３に記載の通信装置。
8. ダウンリンク通信に基づいて宛先端末が決定される種別以外のトリガーフレームが送信される端末により前記複数の端末が構成されることを特徴とする請求項１から７のいずれか１項に記載の通信装置。
9. ダウンリンク通信に基づいて宛先端末が決定される種別以外のトリガーフレームとは、ＭＵ－ＢＡＲ、ＭＵ－ＲＴＳ、ＧＣＲ ＭＵ－ＢＡＲ以外の種別のトリガーフレームであることを特徴とする請求項８に記載の通信装置。
10. 応答の有効データが同じ長さになるトリガーフレームの送信対象の端末により前記複数の端末が構成されることを特徴とする請求項１から９のいずれか１項に記載の通信装置。
11. トリガーフレームの種別がＢａｓｉｃ Ｔｒｉｇｇｅｒであり、送信バッファ量が同じ値の端末で前記複数の端末を構成することを特徴とする請求項１０に記載の通信装置。
12. トリガーフレームの種別がＮＦＲＰの場合に、準備時間が同じ端末が連続するようにＡＩＤの割り当てを行う割り当て手段をさらに備えることを特徴とする請求項１から７のいずれか１項に記載の通信装置。
13. 前記送信手段は、１つのトリガーフレームにおいて、準備時間が長い端末に対応したフィールドの後に準備時間が短い端末に対応したフィールドを配置することで、前記パディングにより確保すべき時間を減少させることを特徴とする請求項１または２に記載の通信装置。
14. 前記選択手段は、送信の品質が同じ端末を優先して、１つのトリガーフレームの宛先端末として選択することを特徴とする請求項１から１３のいずれか１項に記載の通信装置。
15. 前記通信装置は、ＩＥＥＥ８０２．１１ａｘに対応したアクセスポイントであり、
    前記準備時間を示す能力情報は、ＩＥＥＥ８０２．１１ａｘで規定されるＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅであることを特徴とする請求項１から１４のいずれか１項に記載の通信装置。
16. 前記取得手段は、Ｍａｎａｇｅｍｅｎｔフレーム内のＨＥ ＣａｐａｂｉｌｉｔｉｅｓのＴｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ ＤｕｒａｔｉｏｎからＭｉｎＴｒｉｇＰｒｏｃＴｉｍｅを取得することを特徴とする請求項１５に記載の通信装置。
17. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置の制御方法であって、
    前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得工程と、
    前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択工程と、
    前記選択工程により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信工程と、を備え、
    前記選択工程では、前記複数の端末から取得した前記能力情報に基づいて準備時間が等しい端末が連続するように前記複数の端末の選択順を決定し、前記選択順に従って前記１つのトリガーフレームの宛先となる端末を選択することを特徴とする通信装置の制御方法。
18. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置の制御方法であって、
    前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得工程と、
    前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択工程と、
    前記選択工程により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信工程と、を備え、
    前記選択工程では前記複数の端末から取得した前記能力情報に基づいて端末を選択し、前記送信工程では、前記選択工程で選択された端末が要求する準備時間のうち最大の準備時間に相当するパディングを付加することを特徴とする通信装置の制御方法。
19. 複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置の制御方法であって、
    前記複数の端末から、前記トリガーフレームにより使用するリソースユニットが指定されてから送信を開始するのに必要な準備時間を示す能力情報を取得する取得工程と、
    前記複数の端末から１つのトリガーフレームの宛先となる端末を選択する選択工程と、
    前記選択工程により選択された端末の準備時間を確保するためのパディングを付加して、前記選択された端末のためのトリガーフレームを送信する送信工程と、を備え、
    前記選択工程では、前記複数の端末から取得した前記能力情報に基づいて端末を選択し、前記送信工程では、１つのトリガーフレームにおいて、準備時間が長い端末に対応したフィールドの後に準備時間が短い端末に対応したフィールドを配置することで、前記パディングにより確保すべき時間を減少させることを特徴とする通信装置の制御方法。
20. 請求項１から１６のいずれか１項に記載された通信装置の各手段としてコンピュータを機能させるためのプログラム。

Images