WO2020079972A1

WO2020079972A1 - 通信装置およびその制御方法

Info

Publication number: WO2020079972A1
Application number: PCT/JP2019/034340
Authority: WO
Inventors: 雅智大内
Original assignee: キヤノン株式会社
Priority date: 2018-10-19
Filing date: 2019-09-02
Publication date: 2020-04-23
Also published as: JP7316774B2; JP2020065238A; US20210243792A1

Abstract

複数の端末に対してアップリンク伝送を実行させるためのトリガーフレームを送信する通信装置は、リソースユニットが指定されてから送信を開始するまでに必要な準備時間を示す能力情報を複数の端末のそれぞれから取得し、１つのトリガーフレームの宛先となる端末を複数の端末から選択し、選択された端末の準備時間を確保するためのパディングを付加して、選択された端末のためのトリガーフレームを送信する。通信装置は、付加されるパディングの総和が小さくなるように、能力情報に基づいて複数の端末からトリガーフレームの対象となる端末を選択する。

Description

通信装置およびその制御方法

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

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

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

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

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

　本発明は、ｐａｄｄｉｎｇの付加による不要な遅延時間の発生を低減する技術を提供する。

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

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

　本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

　添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
図１は、実施形態による通信システムの構成例を示す図である。図２は、アクセスポイントおよび端末のハードウェア構成例を示すブロック図である。図３Ａは、ＴＦのデータ構成例を示す図である。図３Ｂは、ＴＦのＣｏｍｍｏｎＩｎｆｏのデータ構成例を示す図である。図３Ｃは、ＮＦＲＰＴＦ以外のＰｅｒＵｓｅｒＩｎｆｏのデータ構成例を示す図である。図４Ａは、実施形態１による端末テーブルの例を示す図である。図４Ｂは、実施形態１のシーケンスを説明する図である。図５Ａは、管理フレーム受信処理を示すフローチャートである。図５Ｂは、ＴＦ送信／データ受信／応答送信の処理を示すフローチャートである。図５Ｃは、実施形態１による全トリガーフレーム送信処理を示すフローチャートである。図６Ａは、実施形態２による全トリガーフレーム送信処理を示すフローチャートである。図６Ｂは、実施形態２による全トリガーフレーム送信処理を示すフローチャートである。図７は、実施形態２におけるＴＦ送信処理テーブルの例を示す図である。図８は、ＮＦＲＰＴＦのＰｅｒＵｓｅｒＩｎｆｏのデータ構成例を示す図である。

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

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

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

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

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

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

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

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

　３０１は、ＩＥＥＥ８０２．１１シリーズに共通なＦｒａｍｅＣｏｎｔｒｏｌであり、本実施形態では、ＩＥＥＥ８０２．１１ａｘのトリガーフレームであることを示す値が入る。ＦｒａｍｅＣｏｎｔｒｏｌ３０１の長さは、２オクテット（バイト）である。３０２はＤｕｒａｔｉｏｎであり、長さは２オクテットである。３０３はＲＡ（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

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