JP6594319B2 - 無線通信装置 - Google Patents

Description

本発明の実施形態は、無線通信用集積回路、無線通信端末および無線通信方法に関する。

ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３において、ダウンリンクマルチユーザＭＩＭＯ（Ｄｏｗｎｌｉｎｋ Ｍｕｌｔｉ−Ｕｓｅｒ ＭＩＭＯ：ＤＬ−ＭＵ−ＭＩＭＯ）送信を実施する方法として、同じマルチユーザ送信の対象となる複数の無線通信端末に、グループ識別子（Ｉｄｅｎｔｉｆｉｅｒ；ＩＤ）を予め割り当てる方法が開示されている。この方法では、実際にＤＬ−ＭＵ−ＭＩＭＯの物理パケットを送信する際に、物理パケットのヘッダ（ＶＨＴ−ＳＩＧ−Ａフィールド）に、そのグループＩＤを入れる。また、ＤＬ−ＭＵ−ＭＩＭＯとは別に、周波数チャネルの幅（帯域幅）を基準の２０ＭＨｚ幅から拡張して送信する際に、物理パケットの送信で実際に使用している周波数チャネルの幅（帯域幅）を、当該物理パケット内のスクランブルシーケンス（ｓｃｒａｍｂｌｉｎｇ ｓｅｑｕｅｎｃｅ）で通知していることを当該物理パケット内のＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ； 媒体アクセス制御）フレームの送信先アドレスである無線通信端末に把握させるために、当該ＭＡＣフレームの送信元アドレス （ＴＡ： Ｔｒａｎｓｍｉｔｔｉｎｇ ＳＴＡ Ａｄｄｒｅｓｓ）フィールドの個別／グループビット（Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐ ｂｉｔ：Ｉ／Ｇビット）に１を立てる方法が開示されている。Ｉ／Ｇビットは、ＴＡフィールドの最初のビットであり、１は通常の使用では、「グループ」を表し、すなわち当該アドレスフィールドがグループアドレスであることを示す。通常、ＴＡフィールドに送信元アドレスを格納するときには送信元アドレスはある１つの無線通信端末のＭＡＣアドレスを示すことからユニキャストアドレスとなるため、Ｉ／Ｇビットは、「個別」を表す０に設定するが、Ｉ／Ｇビットに敢えて１を立てることで、物理パケットの送信で実際に使用している周波数チャネルの幅（帯域幅）を、当該物理パケット内のスクランブルシーケンス（ｓｃｒａｍｂｌｉｎｇ ｓｅｑｕｅｎｃｅ）で通知していることを、ＭＡＣフレームを受信した無線通信端末に把握させることができる。Ｉ／Ｇビットを１にした送信元アドレスは“ｂａｎｄｗｉｄｔｈ ｓｉｇｎａｌｉｎｇ ＴＡ”と呼ばれる。

ＩＥＥＥ ８０２．１１−１４／０５９８ｒ０では、上記ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３のグループＩＤを利用した、アップリンクマルチユーザＭＩＭＯ（Ｕｐｌｉｎｋ Ｍｕｌｔｉ−Ｕｓｅｒ ＭＩＭＯ： ＵＬ−ＭＵ−ＭＩＭＯ）が提案されている。無線通信端末からユニキャストで送信されたＲＴＳ（Ｒｅｑｕｅｓｔ ｔｏ Ｓｅｎｄ）フレームへの応答として、基地局がＲＴＳフレームのＳＩＦＳ（Ｓｈｏｒｔ ＩｎｔｅｒＦｒａｍｅ Ｓｐａｃｅ）後に送信するＣＴＳ（Ｃｌｅａｒ ｔｏ Ｓｅｎｄ）フレームの受信先アドレスフィールド（ＲＡ： Ｒｅｃｅｉｖｉｎｇ ＳＴＡ Ａｄｄｒｅｓｓ）に、グループＩＤを入れる。具体的には、６オクテットのＭＡＣアドレスフィールドの先頭に、６ビットのグループＩＤを入れ、その後に４２ビットの事前に定義したパターン（ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）を入れる。このようにグループＩＤを入れたＣＴＳフレームを、通常のＣＴＳフレームと区別して、Ｇ ＣＴＳフレーム（ＣＴＳ ｆｒａｍｅ ｗｉｔｈ Ｇｒｏｕｐ ＩＤ）と呼んでいる。Ｇ ＣＴＳフレームを受信した無線通信端末のうち、グループＩＤが一致する複数の無線通信端末が、Ｇ ＣＴＳフレームのＳＩＦＳ後にＵＬ−ＭＵ−ＭＩＭＯ送信を実施する。このＵＬ−ＭＵ−ＭＩＭＯ送信に対し、基地局は、応答を送信するときにも、ＲＡフィールドにグループＩＤを入れたＡＣＫフレームを送信する。このグループＩＤを入れたＡＣＫフレームをＧ ＡＣＫフレーム（ＡＣＫ ｆｒａｍｅ ｗｉｔｈ Ｇｒｏｕｐ ＩＤ）と呼んでいる。

ＩＥＥＥ ８０２．１１−１４／０５９８ｒ０で提案されている方法では、６ビットのグループＩＤと、事前に定義された４２ビットのパターンとからなる４８ビットのアドレス（Ｇｒｏｕｐ ＩＤ＋ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）が、無線通信グループであるＢＳＳ（Ｂａｓｉｓ Ｓｅｒｖｉｃｅ Ｓｅｔ）内に実際に存在する、いずれかの無線通信端末のＭＡＣアドレスと一致する可能性がある。また、予めＢＳＳを構成する無線通信端末のＭＡＣアドレスと重複しないように、アドレス（Ｇｒｏｕｐ ＩＤ＋ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）を定義しておいても、新たな無線通信端末が途中から、ＢＳＳに加入することもあるため、そのように将来加入する無線通信端末のＭＡＣアドレスが、上記のアドレス（Ｇｒｏｕｐ ＩＤ＋ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）と被る可能性を回避することはできない。仮に同じＭＡＣアドレスを使用する無線通信端末が存在した場合、無線通信端末は、受信したＣＴＳフレームが、Ｇ ＣＴＳフレームなのか、自端末宛の通常のＣＴＳフレームなのか区別できなくなる問題が発生する。また仮に、当該アドレス（Ｇｒｏｕｐ ＩＤ＋ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）の値と同じＭＡＣアドレスを有する無線通信端末が途中でＢＳＳに加入した場合に、基地局が、新規の値のアドレス（Ｇｒｏｕｐ ＩＤ＋ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）を定義し直す方法も考えられるが、各無線通信端末にこの定義し直した新規の値を通知しなければならない。これは、効率的な伝送に対するオーバーヘッドになり、各無線通信端末に通知するまでの間、ＵＬ−ＭＵ−ＭＩＭＯ送信を行うこともできないし、ＵＬ−ＭＵ−ＭＩＭＯ用のグループＩＤとＤＬ−ＭＵ−ＭＩＭＯ用のグループＩＤを共通にしている場合でグループＩＤを変更する場合にはＤＬ−ＭＵ−ＭＩＭＯ送信を行うこともできない。

米国特許第８５０３３５７号

ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３ ＩＥＥＥ ８０２．１１−１４／０５９８ｒ０

本発明の実施形態は、受信先アドレスフィールドの値が、無線通信端末で使用されるＭＡＣアドレスと一致する可能性を回避しつつ、受信先アドレスフィールドを有効に活用する。

本発明の実施形態としての無線通信用集積回路は、ベースバンド集積回路を備える。前記ベースバンド集積回路は、送信元アドレスが第１の無線通信装置であり、受信先アドレスが自装置である第１フレームを受信したことに応じて、第１アドレス処理を用いて第２フレームを生成し、前記第２フレームをＲＦ集積回路を介して送信する。前記第１アドレス処理は、前記第２フレームの受信先アドレスフィールドにおける第１領域に第１の値を設定する。前記第１の値は、前記第１の無線通信装置および前記第２フレームを受信可能な他の無線通信装置のアドレスにおける前記第１領域に設定することができる値とは異なる値である。

第１の実施形態に係る無線通信装置の機能ブロック図。 第１の実施形態に係る無線通信システムを示す図。 第１の実施形態に係る基地局および端末間の動作シーケンスの例を示す図。 第１の実施形態に係るＣＴＳフレームのフォーマット例を示す図。 第１の実施形態に係る送達確認応答フレームのフォーマット例を示す図。 第１の実施形態に係る送達確認応答フレームの他のフォーマット例を示す図。 送達確認応答フレームを端末毎に個別に送信するシーケンスの例を示す図。 第１の実施形態に係る基地局の基本的な動作例のフローチャート。 第１の実施形態に係る端末の基本的な動作例のフローチャート。 第２の実施形態に係る基地局および端末間の動作シーケンスの例を示す図。 各端末が順番に送達確認応答フレームを送信するシーケンスの例を示す図。 第３の実施形態に係る基地局および端末間の動作シーケンスの例を示す図。 第３の変形例に係る基地局および端末間の動作シーケンスの例を示す図。 第４の変形例に係る基地局および端末間の動作シーケンスの例を示す図。 本発明の実施形態に係る端末および基地局の全体構成図。 本発明の実施形態に係る無線通信装置のハードウェアブロック図。 本発明の実施形態に係る無線機器の斜視図。 本発明の実施形態に係るメモリーカードを示す図。 コンテンション期間のフレーム交換の一例を示す図。 アップリンクＯＦＤＭＡにおいて各端末へのリソースユニットの割り当てを説明する図。

以下、図面を参照しながら本実施の形態について詳細に説明する。無線ＬＡＮの規格書として知られているＩＥＥＥ Ｓｔｄ ８０２．１１ＴＭ−２０１２およびＩＥＥＥ Ｓｔｄ ８０２．１１ａｃＴＭ−２０１３は、本明細書においてその全てが参照によって組み込まれる（ｉｎｃｏｒｐｏｒａｔｅｄ ｂｙ ｒｅｆｅｒｅｎｃｅ）ものとする。

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

（第１の実施形態）
図１に、第１の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局または無線通信基地局と通信する無線通信端末に実装されることができる。無線通信基地局（以下、基地局）も、無線通信端末（以下、端末）の一形態である。以下では端末と言うときは、説明上、特に両者を区別する必要がない限り、基地局も含んでもよい。

図１に示されるように、端末（非基地局の端末および基地局）に搭載される無線通信装置は、上位処理部９０、ＭＡＣ処理部１０、ＰＨＹ（Ｐｈｙｓｉｃａｌ；物理）処理部５０、ＭＡＣ／ＰＨＹ管理部６０、アナログ処理部７０（アナログ処理部１〜Ｎ）及びアンテナ８０（アンテナ１〜Ｎ）を含む。Ｎは１以上の整数である。図では、Ｎ個のアナログ処理部と、Ｎ個のアンテナが一対ずつ接続されているが、必ずしもこの構成に限定されるものではない。例えばアナログ処理部の個数が１つで、２つ以上のアンテナがこのアナログ処理部に共通に接続されてもよい。ＭＡＣ処理部１０、ＭＡＣ／ＰＨＹ管理部６０、およびＰＨＹ処理部５０は、他の端末（基地局を含む）との通信に関する処理を行う制御部またはベースバンド集積回路の一形態に相当する。アナログ処理部７０は、例えばアンテナ８０を介して信号を送受信する無線通信部またはＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）集積回路の一形態に相当する。本実施形態に係る無線通信用集積回路は、当該ベースバンド集積回路（制御部）およびＲＦ集積回路の少なくとも前者を含む。ベースバンド集積回路の機能は、ＣＰＵ等のプロセッサで動作するソフトウェア（プログラム）によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはＲＯＭ、ＲＡＭ等のメモリ、ハードディスク、ＳＳＤなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発性メモリでもよい。

上位処理部９０は、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ：媒体アクセス制御）層に対して上位層のための処理を行う。上位処理部９０は、ＭＡＣ処理部１０との間で信号をやり取りできる。上位層としては、代表的なものとしては、ＴＣＰ／ＩＰやＵＤＰ／ＩＰ、さらにその上層のアプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部９０は、ＭＡＣ層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。上位処理部９０を介して有線インフラに接続するようになっていてもよい。

ＭＡＣ処理部１０は、ＭＡＣ層のための処理を行う。前述のように、ＭＡＣ処理部１０は、上位処理部９０との間で信号をやり取りできる。更に、ＭＡＣ処理部１０は、ＰＨＹ処理部５０との間で、信号をやり取りできる。ＭＡＣ処理部１０は、ＭＡＣ共通処理部２０と送信処理部３０と受信処理部４０を含む。

ＭＡＣ共通処理部２０は、ＭＡＣ層での送受信に共通する処理を行う。ＭＡＣ共通処理部２０は、上位処理部９０、送信処理部３０、受信処理部４０及びＭＡＣ／ＰＨＹ管理部６０と接続し、夫々との間で信号のやり取りをする。

送信処理部３０及び受信処理部４０は、相互に接続している。また、送信処理部３０及び受信処理部４０は、夫々ＭＡＣ共通処理部２０及びＰＨＹ処理部５０に接続している。送信処理部３０は、ＭＡＣ層での送信処理を行う。受信処理部４０は、ＭＡＣ層での受信処理を行う。

ＰＨＹ処理部５０は、ＰＨＹ層のための処理を行う。前述のように、ＰＨＹ処理部５０は、ＭＡＣ処理部１０との間で信号をやり取りできる。ＰＨＹ処理部５０は、アナログ処理部７０を介してアンテナ８０に接続されている。

ＭＡＣ／ＰＨＹ管理部６０は、上位処理部９０、ＭＡＣ処理部１０（より詳細には、ＭＡＣ共通処理部２０）及びＰＨＹ処理部５０の夫々と接続されている。ＭＡＣ／ＰＨＹ管理部６０は、無線通信装置におけるＭＡＣ動作及びＰＨＹ動作を管理する。

アナログ処理部７０は、アナログ／デジタル及びデジタル／アナログ（ＡＤ／ＤＡ）変換器やＲＦ回路を含み、ＰＨＹ処理部５０からのデジタル信号を所望の周波数のアナログ信号に変換してアンテナ８０から送信、またアンテナ８０から受信した高周波のアナログ信号をデジタル信号に変換する。なお、ここでは、ＡＤ／ＤＡ変換をアナログ処理部７０で行っているが、ＰＨＹ処理部５０にＡＤ／ＤＡ変換機能を持たせる構成も可能である。

本実施形態に係る無線通信装置は、１チップ内にアンテナ８０を構成要素として含む（一体化する）ことで、このアンテナ８０の実装面積を小さく抑えることができる。更に、本実施形態に係る無線通信装置は、図１に示されるように、送信処理部３０及び受信処理部４０が、Ｎ本のアンテナ８０を共用している。送信処理部３０及び受信処理部４０がＮ本のアンテナ８０を共用することにより、図１の無線通信装置を小型化できる。なお、本実施形態に係る無線通信装置は、図１に例示されたものと異なる構成を備えても勿論よい。

無線媒体への信号送信に際して、ＰＨＹ処理部５０は、送信処理部３０からＭＡＣフレームを受け取る。ＰＨＹ処理部５０は、ＭＡＣフレームにプリアンブル及びＰＨＹヘッダの追加や符号化、変調などの処理を行ってＰＨＹパケットに変換する。アナログ処理部７０は、デジタル信号であるＰＨＹパケットを、所望の周波数のアナログ信号に変換する。アンテナ８０は、アナログ処理部７０からのアナログ信号を無線媒体に輻射する。なお、ＰＨＹ処理部５０は、信号送信の期間中に、無線媒体がビジーであることを示す信号を、ＭＡＣ処理部１０（より正確には受信処理部４０）へ出力する。

また、ＰＨＹ処理部５０は、ＭＩＭＯ技術を拡張したアップリンクマルチユーザＭＩＭＯ（Ｕｐｌｉｎｋ Ｍｕｌｔｉ−Ｕｓｅｒ ＭＩＭＯ：ＤＬ−ＭＵ−ＭＩＭＯ）およびＤＬ−ＭＵ−ＭＩＭＯ（Ｄｏｗｎｌｉｎｋ Ｍｕｌｔｉ−Ｕｓｅｒ ＭＩＭＯ：ＤＬ−ＭＵ−ＭＩＭＯ）の少なくとも一方に関する処理を行う。第１の実施形態および後述する第３の実施形態では、少なくともＵＬ−ＭＵ−ＭＩＭＯに関する処理を行うものとする。また、後述する第２の実施形態では、少なくともＤＬ−ＭＵ−ＭＩＭＯに関する処理を行うものとする。ＵＬ−ＭＵ−ＭＩＭＯは、基地局が、複数台の端末から空間多重で（同一周波数帯域で同時に）送信されるストリームを複数のアンテナで同時に受信し、受信信号をＭＩＭＯ復調することで、各端末のフレームへ分離する。これにより、基地局は、複数台の端末から同一の周波数帯域で同時に送信されるフレームを受信できる。またＤＬ−ＭＵ−ＭＩＭＯでは、基地局が複数のアンテナから、複数台の端末に対しそれぞれストリームを空間多重で送信し、各端末が受信信号をＭＩＭＯ復調することでフレームに分離し、自端末宛のフレームを受信する。これにより、基地局は、複数台の端末へ同時にフレームを同一の周波数帯域でそれぞれ送信できる。

ここで、ＤＬ−ＭＵ−ＭＩＭＯでは、ビームフォーミングと呼ばれる技術を用いる。ビームフォーミングでは、各ストリームで互いに干渉が最小もしくは小さくなるようなビームを形成して送信する。これにより、空間多重が可能となり、基地局は複数台の端末と同時に、同一の周波数帯域で受信または送信することができる。このようなビームフォーミングを行うため、基地局は、自装置のアンテナと各端末のアンテナとの間の伝搬路応答（アップリンクの伝搬路応答、ダウンリンクの伝搬路応答）の情報を取得する必要がある。例えば、ダウンリンクの伝搬路応答の場合、基地局が、各端末に対してそれぞれ伝搬路推定用のフレーム（既知のビットパターンを含む）を送信処理部３０で生成して送信し、端末が推定した伝搬路応答の値を含むフレームを、それぞれフィードバックさせて受信処理部４０で受信することで、各端末とのダウンリンクの伝搬路応答を取得する。アップリンクの伝搬路応答を取得する場合、各端末に伝搬路推定用のフレーム（既知のビットパターンを含む）を送信させ、基地局が各端末から受信したフレームの信号に基づき、伝搬路応答をＰＨＹ処理部５０で推定する。ＰＨＹ処理部５０では、これらのダウンリンクの伝搬路応答を用いてビームフォーミングを行い、またアップリンクの伝搬路応答を用いてＭＩＭＯ復調を行う。これらのダウンリンクの伝搬路応答およびアップリンクの伝搬路応答に関する情報は、ＰＨＹ処理部５０内のバッファまたはＰＨＹ処理部５０からアクセス可能なメモリに格納してもよい。または、ＭＡＣ／ＰＨＹ管理部６０またはＭＡＣ／ＰＨＹ管理部６０からアクセス可能なメモリ等に格納してもよい。なお、ダウンリンクの伝搬路応答を取得する方法、またはアップリンクの伝搬路応答を推定する方法は、ここで述べた方法に限定されるものではない。

ＵＬ−ＭＵ−ＭＩＭＯでは、基地局は、各端末からフレーム（より詳細には、ＭＩＭＯ変調後のＰＨＹパケット）を複数のアンテナで、空間多重で受信し、事前に推定したアップリンクの伝搬路応答から、ＰＨＹ処理部５０で受信信号をＭＩＭＯ復調することで、各フレームに分離する。この際、ＺＦ（Ｚｅｒｏ−Ｆｏｒｃｉｎｇ）法、ＭＭＳＥ（Ｍｉｎｉｍｕｍ Ｍｅａｎ Ｓｑｕａｒｅ Ｅｒｒｏｒ）法、または、最尤推定法など、任意の手法を用いることができる。なお、後述する変形例で説明するように、複数の端末がアップリンクする複数のフレームの先頭側（物理ヘッダ内）に互いに直交するプリアンブルを追加し、これらのプリアンブルを利用して端末毎ノアップリンクの伝搬路応答を推定することも可能である。この場合、事前にアップリンクの伝搬路応答を推定しないで、ＵＬ−ＭＵ−ＭＩＭＯを実現できる。各端末では、予め定められたタイミング（例えば、後述するように基地局から受信されるＣＴＳフレームの受信完了から（正確には、当該ＣＴＳフレームを内包する物理パケットが無線媒体を占有終了する時点から。以降も同様）ＳＩＦＳ経過後）にフレームを送信するようＭＡＣ／ＰＨＹ管理部６０でＭＡＣ処理部１０およびＰＨＹ処理部５０を制御することで、各端末から空間多重でフレームが送信される。

ＤＬ−ＭＵ−ＭＩＭＯでは、基地局は、複数のアンテナから各端末にフレームをビームフォーミングで送信する。ＰＨＹ処理部５０は、ダウンリンクの伝搬路応答に基づき算出される送信ウェイトを利用してビームフォーミング送信用の信号を送信系統毎に生成する。その後、アナログ処理部７０の処理を経て、各送信系統に対応するアンテナから空間に輻射する。各端末では、ＰＨＹ処理部５０で受信信号を復調することで、自端末宛のフレーム（例えばＲＡが自端末のＭＡＣアドレスのフレーム）を取得する。

無線媒体からの信号受信に際して、アナログ処理部７０は、アンテナ８０が受信したアナログ信号を、ＰＨＹ処理部５０が処理可能な基底帯域（Ｂａｓｅｂａｎｄ）の信号に変換し、デジタル信号に変換する。ＰＨＹ処理部５０は、アナログ処理部７０からデジタルの受信信号を受け取り、その受信レベルを検出する。検出した受信レベルを、キャリアセンスレベル（閾値）と比較し、受信レベルが、キャリアセンスレベル以上であれば、ＰＨＹ処理部５０は媒体（ＣＣＡ；Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ）がビジーであるということを示す信号を、ＭＡＣ処理部１０（より正確には、受信処理部４０）へ出力する。受信レベルが、キャリアセンスレベル未満であれば、ＰＨＹ処理部５０は、媒体（ＣＣＡ）がアイドルであるということを示す信号を、ＭＡＣ処理部１０（より正確には受信処理部４０）へ出力する。

ＰＨＹ処理部５０は、受信信号に対し、復調処理（ＭＩＭＯ復調を含む）、プリアンブル及びＰＨＹヘッダを取り除く処理などを行って、ペイロードを抽出する。ＩＥＥＥ８０２．１１規格ではこのペイロードをＰＨＹ側ではＰＳＤＵ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｃｅｄｕｒｅ （ＰＬＣＰ） ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）と呼んでいる。ＰＨＹ処理部５０は、抽出したペイロードを受信処理部４０に渡し、受信処理部４０はこれをＭＡＣフレームとして扱う。ＩＥＥＥ８０２．１１規格では、このＭＡＣフレームを、ＭＰＤＵ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ （ＭＡＣ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）と呼んでいる。加えて、ＰＨＹ処理部５０は、受信信号を受信開始した際に、その旨を受信処理部４０に通知し、また受信信号を受信終了した際に、その旨を受信処理部４０に通知する。また、ＰＨＹ処理部５０は、受信信号が正常にＰＨＹパケットとして復号できた場合（エラーを検出しなければ）、受信信号の受信終了を通知すると共に、媒体がアイドルであるということを示す信号を、受信処理部４０に渡す。ＰＨＹ処理部５０は、受信信号にエラーを検出した場合には、エラー種別に即した適切なエラーコードをもって、受信処理部４０にエラーを検出したことを通知する。また、ＰＨＹ処理部５０は、媒体がアイドルになったと判定した時点で、媒体がアイドルであることを示す信号を受信処理部４０に通知する。

ＭＡＣ共通処理部２０は、上位処理部９０から送信処理部３０への送信データの受け渡し、及び受信処理部４０から上位処理部９０への受信データの受け渡しを、夫々仲介する。ＩＥＥＥ８０２．１１規格では、このＭＡＣデータフレームの中のデータを、ＭＳＤＵ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ （ＭＡＣ） ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）と呼んでいる。また、ＭＡＣ共通処理部２０は、ＭＡＣ／ＰＨＹ管理部６０からの指示を一旦受け取り、当該指示を送信処理部３０及び受信処理部４０に適したものに変換して出力する。

ＭＡＣ／ＰＨＹ管理部６０は、例えばＩＥＥＥ８０２．１１規格におけるＳＭＥ（Ｓｔａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）に相当する。その場合、ＭＡＣ／ＰＨＹ管理部６０とＭＡＣ共通処理部２０との間のインターフェースは、ＩＥＥＥ８０２．１１規格におけるＭＬＭＥ ＳＡＰ（ＭＡＣ ｓｕｂＬａｙｅｒ Ｍａｎａｇａｍｅｎｔ Ｅｎｔｉｔｙ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）に相当し、ＭＡＣ／ＰＨＹ管理部６０とＰＨＹ処理部５０との間のインターフェースは、ＩＥＥＥ８０２．１１無線ＬＡＮにおけるＰＬＭＥ ＳＡＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）に相当する。

なお、図１において、ＭＡＣ／ＰＨＹ管理部６０は、ＭＡＣ管理のための機能部とＰＨＹ管理のための機能部とが一体であるかのように描かれているが、分けて実装されてもよい。

ＭＡＣ／ＰＨＹ管理部６０は、管理情報ベース（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ；ＭＩＢ）を保持する。ＭＩＢは、自端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、自端末が、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯに対応するか否かといった情報も保持されていてもよい。ＭＩＢを保持・管理するためのメモリは、ＭＡＣ／ＰＨＹ管理部６０に内包させてもよいし、ＭＡＣ／ＰＨＹ管理部６０に内包せずに別に設けるようにしてもよい。ＭＩＢを保持・管理するためのメモリをＭＡＣ／ＰＨＹ管理部６０とは別に設ける場合に、ＭＡＣ／ＰＨＹ管理部６０は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。基地局では、他の非基地局端末でのこれらの情報も、非基地局としての各端末からの通知により、取得することができ、前述した伝搬路応答や各種ウェイトに関する情報と合わせて、自端末に関する情報とともに記憶させてもよい。その場合、ＭＡＣ／ＰＨＹ管理部６０は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、ＭＩＢとは別に保持・管理するようにしてもよい。その場合、ＭＡＣ／ＰＨＹ管理部６０あるいはＭＡＣ共通処理部２０が、その別のメモリを参照・書き換えが可能なようにする。

また、基地局としての端末のＭＡＣ／ＰＨＹ管理部６０あるいはＭＡＣ共通処理部２０は、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯを行うためのグループの生成およびグループ識別子（以下、グループＩＤ）の付与を管理する。基地局は、通信リンクが確立（後述）した複数の端末の中から、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯを行う端末を組み合わせて、端末のグループを生成し、各グループに属する端末群をＭＡＣアドレス（または後述するアソシエーションＩＤ）に基づき管理する。例えば、通信リンクが確立した端末が１０台（仮に端末１〜１０とする）存在したとすると、１番目のグループとして端末１〜４、２番目のグループとして無線端末１、３、５、６、３番目のグループとして端末６〜１０を組み合わせる。各グループにはユニークなグループＩＤ（グループ識別子）を付与する。この際、ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３でＤＬ−ＭＵ−ＭＩＭＯ用に規定されたグループＩＤを用いてもよい。ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯ通信は、グループＩＤによりグループを指定して、グループ単位で複数端末の多重送信を行う。基地局は、グルーピングの結果をグループＩＤとして各端末に、管理フレーム（詳細は後述）を用いて通知することで、各端末は自装置がいずれのグループに属しているかを把握できる。グルーピングの方法としては、例えば各端末とのダウンリンクまたはアップリンクの伝搬路応答を利用して相関の低い端末を同じグループにまとめてもよいし、その他の方法を用いてグルーピングしてもよい。

ＭＡＣ処理部１０は、データフレーム、制御フレーム及び管理フレームの３種類のＭＡＣフレームを扱い、ＭＡＣ層において規定される各種処理を行う。ここで、３種類のＭＡＣフレームについて説明する。

管理フレームは、他の端末との間の通信リンクの管理のために用いられる。管理フレームとしては、例えば、ＩＥＥＥ８０２．１１規格におけるＢａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ（ＢＳＳ）を形成するために、ＢＳＳの属性及び同期情報を報知するビーコン（Ｂｅａｃｏｎ）フレームや、認証のためにまたは通信リンク確立のために交換されるフレームなどがある。なお、ある端末が、もう一台の端末と互いに無線通信を実施するために必要な情報交換を済ませた状態を、通信リンクが確立していると、ここでは表現する。必要な情報交換として、例えば、自端末が対応する機能の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部３０が、ＭＡＣ／ＰＨＹ管理部６０からＭＡＣ共通処理部２０を介して受けた指示に基づいて生成する。

管理フレームに関連して、送信処理部３０は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。非基地局としての端末の通知手段は、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否の情報を、管理フレームに入れて送信することで、基地局に当該情報を通知してもよい。この管理フレームは例えば非基地局端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームや、あるいはリアエソシエーションプロセスで用いられるＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームである。当該情報を管理フレームで送信するように当該通知手段を制御する通知制御手段が、ＭＡＣ／ＰＨＹ管理部６０に備えられていてもよい。また、基地局の通知手段は、非基地局の端末に、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否の情報を、管理フレームを介して通知してもよい。この管理フレームは例えばＢｅａｃｏｎフレームや、非基地局端末が送信したＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームに対する応答であるＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームである。ＭＡＣ／ＰＨＹ管理部６０は、これらの情報を管理フレームで送信するよう通知手段を制御する通知制御手段を備えてもよい。また、基地局の通知手段は、各端末にそれぞれを割り当てたグループのグループＩＤを、管理フレームを介して通知してもよい。この管理フレームは例えばＧｒｏｕｐ ＩＤ Ｍａｎａｇｅｍｅｎｔフレームである。ＭＡＣ／ＰＨＹ管理部６０は、グループＩＤを管理フレームで送信するよう通知手段を制御する通知制御手段を備えてもよい。

また、受信処理部４０は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、非基地局としての端末の受信手段は、基地局としての端末からＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否の情報を受信してもよい。また、基地局としての端末の受信手段は、非基地局としての端末からＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否の情報を受信してもよい。上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末（基地局を含む）間で送受信することが可能である。

データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、係るデータがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部９０からＭＡＣ共通処理部２０を介して送信処理部３０に渡され、送信処理部３０でデータをフレームボディフィールドに入れたデータフレームが生成され、ＰＨＹ処理部５０、アナログ処理部７０及びアンテナ８０を介して送信される。また、受信処理部４０が、ＰＨＹ処理部５０を介してデータフレームを受信すると（受信したＭＡＣフレームがデータフレームであると把握すると）、そのフレームボディフィールドの情報をデータとして抽出し、ＭＡＣ共通処理部２０を介して上位処理部９０に渡す。この結果、データの書き込み、再生などのアプリケーション上の動作が生じる。

制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信（交換）するときの制御のために用いられる。制御フレームとしては、例えば、管理フレーム及びデータフレームの交換を開始する前に、媒体を予約するために他の無線通信装置との間で交換するＲＴＳ（Ｒｅｑｕｅｓｔ ｔｏ Ｓｅｎｄ）フレーム、ＣＴＳ（Ｃｌｅａｒ ｔｏ Ｓｅｎｄ）フレームなどがある。また、他の制御フレームの例として、受信した管理フレーム及びデータフレームの送達確認のために送信されるＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレーム、ＢＡ（ＢｌｏｃｋＡｃｋ）フレームなどの送達確認応答フレームがある。これらの制御フレームも送信処理部３０で生成される。ＣＴＳフレームやＡＣＫフレーム、ＢＡフレームなど、受信したＭＡＣフレームへの応答として送信される制御フレームに関しては、受信処理部４０で応答フレームの送信判断をして、フレーム生成に必要な情報（制御フレームの種別、ＲＡフィールド等に設定する情報など）を送信指示とともに送信処理部３０に出す。送信処理部３０が、当該フレーム生成に必要な情報に基づき、適切な制御フレームを生成する。

本実施形態では、基地局としての端末が、非基地局としての端末からＲＴＳフレームを受信したときに応答するＣＴＳフレームで、グループＩＤを指定することで、当該グループＩＤのグループに属する端末群に、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行う。後に図４で詳細に説明するように、ＣＴＳフレームのＲＡフィールドの所定の第１領域、具体的に、個別／グループビット（Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐ ｂｉｔ：Ｉ／Ｇビット：Ｉ／Ｇビット）を“１”（第１の値）にし、ＲＡフィールドの所定の第２領域（例えば３〜８ビット目）に、グループＩＤ（ＲＴＳフレームを送信した端末が属するグループのグループＩＤ）を設定したＣＴＳフレームを応答する。なお、第１〜第３の実施形態ではＲＡフィールドの所定の第２領域にグループＩＤを設定する例を示すが、本発明にこれらに限定されるものではなく、後述する第１〜第４の変形例に示すように、Ｉ／Ｇビットに１を設定することをベースとして、種々の実施の態様が可能である。

基地局の受信処理部４０がＲＴＳフレームを受信すると、上記のＣＴＳフレームを生成するための情報を送信処理部３０に渡し、送信処理部３０が、当該情報を利用してＣＴＳフレームを生成する。送信処理部３０は従来のＣＴＳフレーム生成処理に加えて、この場合、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示をＣＴＳフレームで行うか否かの判断が追加され、それに応じて通常のＣＴＳフレームを生成するか、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行うＣＴＳフレームを生成することになる。このＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行うか否かの判断は、ＭＡＣ共通処理部２０やＭＡＣ／ＰＨＹ管理部６０で行うようにして、送信処理部３０はその許可もしくは指示の判断を受けて所望のＣＴＳフレームを生成するようにしてもよい。あるいは受信処理部４０がＲＴＳフレームを受信した際に、受信処理部４０でＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示をＣＴＳフレームで行うか否かの判断を行い、それに応じてＣＴＳフレームのＲＡフィールドを指定して、送信処理部３０にＣＴＳフレーム生成の指示とともに通知するようにしてもよい。この場合でも、受信処理部４０自身がＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行うか否かの判断は、ＭＡＣ共通処理部２０やＭＡＣ／ＰＨＹ管理部６０で行うようにして、受信処理部４０ではその許可もしくは指示の判断を受けて送信処理部３０に所望のＣＴＳフレームの生成指示を出すようにしてもよい。Ｉ／Ｇビットを１にしたＣＴＳフレームとすることで、当該ＣＴＳフレームのＲＡフィールドの値が、ＢＳＳ内の端末のＭＡＣアドレス、もしくは将来ＢＳＳに加入する端末のＭＡＣアドレスに一致する可能性はないため、特段問題を生じさせずに、、ＲＡフィールドにグループＩＤを設定できる。

また、このＣＴＳフレームを受信した端末の受信処理部４０は、フレームコントロールフィールドからフレーム種別（タイプおよびサブタイプ）が、制御およびＣＴＳであることを判定する。そして、ＲＡフィールドのＩ／Ｇビットが１であることから、当該ＣＴＳフレームがＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するものであること、かつＲＡフィールド内の所定の第２領域にグループＩＤが入っていることを把握できる。そして、当該所定の第２領域からグループＩＤを抽出する。ＭＡＣ／ＰＨＹ管理部６０は、当該抽出したグループＩＤと、自端末が属しているグループのグループＩＤを比較し、両者が一致する場合は、予め定められたタイミングでＵＬ−ＭＵ−ＭＩＭＯ送信（端末レベルでの観点からは個々に基地局にフレームを送信）を行うようＭＡＣ処理部１０およびＰＨＹ処理部５０を制御する。通常の場合、基地局からフレームを受信した端末は、フレーム種別（タイプおよびサブタイプ）が、制御およびＣＴＳであれば、ＲＡフィールドのＩ／Ｇビット（先頭ビット）は０であることを期待する。これは、通常であれば、ＲＴＳフレームのＴＡフィールドの値をコピーしてＣＴＳフレームのＲＡフィールドに入れるためである。しかしながら、本実施形態に係るＣＴＳフレームは、ＲＡフィールドのＩ／Ｇビットが１であることから、上記のようにＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するフレームとして利用できる。この詳細についてはさらに後で述べる。なお、ＲＴＳフレームを基地局に送信した非基地局端末は、ＲＴＳフレーム送信のＳＩＦＳ後にＣＴＳフレームを受信した場合には、そのＣＴＳフレームがＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するものであれば、グループＩＤを抽出・自端末が属しているグループのグループＩＤと比較することは省略して、ＣＴＳフレーム受信完了のＳＩＦＳ後にフレームを送信するようにしてもよい。

また、本実施形態では、基地局は、複数端末からのＵＬ−ＭＵ−ＭＩＭＯ送信への応答となる送達確認応答フレームを送信する際、送達確認応答フレームのＲＡフィールドのＩ／Ｇビットを１にし、残りのフィールド領域の一部（ここではＣＴＳフレームと同じ所定の第２領域とするが、これに限定されない）に、グループＩＤを入れてもよい。フレーム種別は、送達確認を表す値（例えばＡｃｋまたはＢｌｏｃｋＡｃｋなど）を設定する。受信処理部４０が、ＵＬ−ＭＵ−ＭＩＭＯ送信された各端末からのデータフレームを受信すると、送達確認応答フレームを生成するための情報（端末毎のデータフレームの成功可否情報（ＡＣＫ情報）、ＲＡフィールドに設定する値、フレーム種別の値等）を送信処理部３０に渡し、送信処理部３０が、当該情報を利用して送達確認応答フレームを生成する。グループＩＤが入った送達確認応答フレームを生成するか否かは、送信処理部３０もしくは受信処理部４０でＵＬ−ＭＵ−ＭＩＭＯ送信を受信したことにより判断するか、あるいは、ＣＴＳフレームでのＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示する判断を行った結果と連動するようにする。ＣＴＳフレームでのＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示する判断を行った結果と連動するとは、具体的には、ＣＴＳフレーム時にいずれかの処理部または管理部でＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示する判断を行った結果を、同一フレーム交換シーケンス（ＩＥＥＥ８０２．１１規格では、ＴＸＯＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｐｐｏｒｔｕｎｉｔｙ；送信権獲得期間）に当たる）内では保持・参照できるようにし、送達確認応答フレームを生成する場合にその保持した結果を参照してそれに応じてＲＡフィールドに入れる値を決める。この際に用いる送達確認応答フレームのフォーマットは、ＢＡフレームを再利用したもの、新規に定義したフレームなどがあり得るが、詳細は後述する。これによれば、当該送達確認応答フレームのＲＡフィールドの値が、ＢＳＳ内の端末のＭＡＣアドレス、もしくは将来ＢＳＳに加入する端末のＭＡＣアドレスに一致する可能性はないため、特段問題を発生させずに、送達確認応答フレームのＲＡフィールドにグループＩＤを設定できる。上記の送達確認応答フレームを受信した端末の受信処理部４０は、フレームコントロールフィールドからフレーム種別が送達確認であることを（例えばフレームタイプおよびサブタイプが、制御およびＢｌｏｃｋＡｃｋ（またはＡｃｋ）であるなど）を判定する。そして、ＲＡフィールドのＩ／Ｇビットが１であることから、ＲＡフィールド内の所定の第２領域にグループＩＤが設定されていることを把握し、当該所定の第２領域からグループＩＤを抽出し、ＭＡＣ／ＰＨＹ管理部６０に通知する。ＭＡＣ／ＰＨＹ管理部６０は、当該抽出されたグループＩＤと、自端末が属しているグループＩＤを比較し、両者が一致する場合は、その旨を受信処理部４０に通知し、受信処理部４０（もしくはＭＡＣ／ＰＨＹ管理部６０）は、自端末のＡＣＫ情報を送達確認応答フレームから特定し、当該ＡＣＫ情報に基づきフレーム送信の成功可否を判断する。

ＭＡＣ処理部１０は、ＣＳＭＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）に基づきＭＡＣフレームを送信する場合、媒体上でのアクセス権（送信権）を獲得する必要がある。送信処理部３０は、受信処理部４０からのキャリアセンス情報に基づいて、送信タイミングを計る。送信処理部３０は、係る送信タイミングに従って、ＰＨＹ処理部５０に送信指示を与えて、ＭＡＣフレームを渡す。送信指示に加えて、送信処理部３０は、送信に使用される変調方式及び符号化方式を合わせて指示してもよい。これらに加えて、送信処理部３０は、送信電力を指示してもよい。ＭＡＣ処理部１０は、アクセス権（送信権）獲得後、媒体を占有可能な時間の間（ＴＸＯＰ）が得られると、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）属性などの制限を伴うものの、他の無線通信装置との間でＭＡＣフレームを連続して交換できる。ＴＸＯＰは、例えば、無線通信装置が後述のＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃａｒｒｉｅｒ Ａｖｏｉｄａｎｃｅ）に基づき所定のフレーム（例えばＲＴＳフレーム）を送信し、他の無線通信装置から応答フレーム（例えばＣＴＳフレーム）を正しく受信した場合に、獲得される。この所定のフレームが、当該他の無線通信装置によって受信されると、当該他の無線通信装置は、最小フレーム間隔（Ｓｈｏｒｔ ＩｎｔｅｒＦｒａｍｅ Ｓｐａｃｅ）後に、上記応答フレームを送信する。また、ＲＴＳフレームを用いないでＴＸＯＰを獲得する方法として、例えば直接ユニキャストで送達確認応答フレームの送信を要求するデータフレーム（後述のようにフレームまたはペイロードが連接された形状のフレームであってもよい）あるいは管理フレームを送信し、それに対する送達確認応答フレーム（ＡＣＫフレームやＢｌｏｃｋＡｃｋフレーム）を正しく受信する場合がある。あるいは、送達確認応答フレームの送信を要求しないフレームであって、そのフレームのＤｕｒａｔｉｏｎフィールド（後述）に当該フレームを送信する以上の期間を設定したものを送信した場合には、当該フレームを送信した段階からＤｕｒａｔｉｏｎフィールドに記載された期間のＴＸＯＰを獲得したと解釈してもよい。

受信処理部４０は、キャリアセンス情報を管理する。このキャリアセンス情報は、ＰＨＹ処理部５０が入力する媒体（ＣＣＡ）のビジー／アイドルに関する物理的なキャリアセンス（Ｐｈｙｓｉｃａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス（Ｖｉｒｔｕａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、ＩＥＥＥ８０２．１１規格において、媒体予約時間は、ＭＡＣヘッダの中のいわゆるＤｕｒａｔｉｏｎ／ＩＤフィールド（以下では単にＤｕｒａｔｉｏｎフィールドと記述）に記載される。ＭＡＣ処理部１０は、他の無線通信装置宛ての（自己宛てでない）ＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含むＰＨＹパケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれる。受信処理部４０は、ＮＡＶの間に他無線通信装置から自装置の属するグループへのＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示を含むフレーム（後述する本実施形態に係るＣＴＳフレーム（図４参照）など）を受信した場合は、ＮＡＶを設定している間であっても、当該許可または指示に応じてフレームのＵＬ−ＭＵ−ＭＩＭＯ送信を行うことを許容する。

ここで、データフレームは、複数のＭＡＣフレームもしくは複数のＭＡＣフレームのペイロード部分を連接するようになっていてもよい。前者はＩＥＥＥ８０２．１１規格ではＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＰＤＵ、後者はＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＳＤＵ（ＭＡＣ ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）と呼ばれる。また、データフレームがＡ−ＭＰＤＵの場合などのように、複数のＭＡＣフレームに対する応答をまとめて送信する場合には、ＡＣＫフレームではなく、ＢＡ（ＢｌｏｃｋＡＣＫ）フレームが用いられる。

非基地局の端末は、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を、接続する基地局に通知してもよい。ＩＥＥＥ８０２．１１規格では、基地局が中心となり構成するＢＳＳ（これをインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ＢＳＳと呼ぶ）に、非基地局の端末が加入し、ＢＳＳ内でデータフレームの交換ができるようになるために経る手順（ｐｒｏｃｅｄｕｒｅ）が、段階的に複数規定されている。そこで、上記ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を、非基地局の端末が、接続する基地局に通知するために、これらの手順の中で、非基地局の端末が、基地局宛てに送信する管理フレームに、上記ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を入れてもよい。

例えば、アソシエーション（ａｓｓｏｃｉａｔｉｏｎ）という手順があり、非基地局の端末から、当該端末が接続を要求する基地局に対して、アソシエーション要求（Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）フレームを送信する。基地局は、アソシエーション要求フレームに対するＡＣＫフレーム送信後、アソシエーション要求フレームに対する応答フレームのアソシエーション応答（Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）フレームを送信する。アソシエーション要求フレームに端末は自端末の能力（ｃａｐａｂｉｌｉｔｙ）を入れ、それを送信することで基地局に自端末の能力の通知をする。そこで例えば、端末はアソシエーション要求フレームの中にＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を入れて送信してもよい。当然、他の基地局へ再接続するための再アソシエーション（ｒｅａｓｓｏｃｉａｔｉｏｎ）という手順にもこの通知を入れるようにしてもよい。この手順では、非基地局の端末から、再接続を要求する他の基地局に対して、再アソシエーション要求（Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するＡＣＫフレーム送信後、再アソシエーション要求フレームに対する応答フレームの再アソシエーション応答（Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）フレームを送信する。そこで、端末は再アソシエーション要求フレームの中に、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を入れて送信する。管理フレームとして、アソシエーション要求フレームや再アソシエーション要求フレーム以外にも、後述するように、ビーコンフレーム、プローブ応答（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ）フレームなどを用いてもよい。ビーコンフレームは基本的に基地局が送信するもので、ＢＳＳの属性を示すパラメータとともに、基地局自身の能力を通知するパラメータも入れられる。そこで、この基地局自身の能力を通知するパラメータとして、基地局がＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を加えるようにしてもよい。プローブ応答フレームは後述のようにビーコンフレームを送信する端末がプローブ要求（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ）フレームを受信すると、送信するフレームであり、基本的にはビーコンフレームと同一の内容を通知するものであるため、これを用いても基地局はプローブ要求フレームを送信した端末にＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応可否を通知することができる。

なお、上記で扱った情報のうち、他の情報を通知することで、その情報が必須となるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯには対応できる、というのであれば、ＵＬ−ＭＵ−ＭＩＭＯまたはＤＬ−ＭＵ−ＭＩＭＯへの対応の通知をしなくてもよい。

図２に、本発明の実施形態に従った無線通信システムを示す。１つの基地局（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）１００が、複数の非基地局である端末（ＳＴＡ：ＳＴＡｔｉｏｎ）１０１〜１０８と、無線通信システムあるいはＢＳＳ１を構成しているとする。このＢＳＳ１で、基地局１００は、ＵＬ−ＭＵ−ＭＩＭＯが有効な状態にしてあるとする。基地局１００は、ＢＳＳ１内の端末群をグループ化しており、ここでは、少なくとも端末１０１、１０２、１０３を同じグループにまとめ、当該グループにグループＩＤ（例えばＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３でＤＬ−ＭＵ−ＭＩＭＯ用に規定されたグループＩＤでもよい）を付与し、端末１０１〜１０３にグループＩＤを通知しているものとする。また、端末１０１〜１０３は、ＵＬ−ＭＵ−ＭＩＭＯに対応可能であり、ＵＬ−ＭＵ−ＭＩＭＯが有効な状態にしてあるとする。なお、１つの端末が複数のグループに属してもかまわず、その場合は、端末には各グループのグループＩＤが通知される。

基地局１００は、例えばＭＩＢで、基地局１００自身がＵＬ−ＭＵ−ＭＩＭＯに対応できることを情報として保持している。端末１０１〜１０３も、例えばこのＭＩＢを持っていて、ＵＬ−ＭＵ−ＭＩＭＯへの対応可否が、同様に設定されているものとする。基地局１００は、例えばさらにＵＬ−ＭＵ−ＭＩＭＯが使える状態（有効な状態）になっているか否かを示すＭＩＢを持っている。基地局１００は、ＵＬ−ＭＵ−ＭＩＭＯが有効な場合に、送信処理部３０で生成する管理フレームに、ＵＬ−ＭＵ−ＭＩＭＯが使用可能な旨を情報として入れてもよい。管理フレームとして、例えばビーコンフレーム、プローブ応答（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ）フレームなどを用いてもよい。プローブ応答フレームは、管理フレームのプローブ要求（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ）フレームを、ビーコンフレームを送信する端末（インフラストラクチャＢＳＳの場合には基地局）が受信し、当該端末（基地局）が、プローブ要求フレームで要求される条件に合致したＢＳＳを構成している場合に、受信したプローブ要求フレームへの応答として送信するフレームである。ビーコンフレームは、報知フレームであり、つまりビーコンフレームの受信先アドレス（ＲＡ）は、ブロードキャストアドレスである。一方、プローブ応答フレームのＲＡは、ある端末のアドレスを指定するユニキャストアドレスである。ＲＡは、ＭＡＣフレームの先頭に設けられるＭＡＣヘッダ部の複数のアドレスフィールドの先頭に設定される。なお、ビーコンフレームやプローブ応答フレームで、ＵＬ−ＭＵ−ＭＩＭＯが使用可能な旨の情報はＢＳＳの属性を示すパラメータとして入れられることになる。ＵＬ−ＭＵ−ＭＩＭＯに対応できることは能力であり、これも前述のようにビーコンフレームやプローブ応答フレームに入れることができる。

図３は、図２に示した基地局１００および端末１０１〜１０３の動作シーケンスの例を示す。端末１０１〜１０３がそれぞれ基地局１００に送信したいデータを有しており、これらのデータを含むデータフレームを、端末１０１〜１０３から基地局１００へＵＬ−ＭＵ−ＭＩＭＯで送信する場合のシーケンスを示す。上述したように、端末１０１〜１０３は、基地局１００により同じグループにまとめられており、当該グループのグループＩＤを事前に通知されている。

端末１０２が、データフレームを送信しようとして媒体を観測した結果、媒体がビジーであると検出し、例えばＤＩＦＳと呼ばれる期間と、それに続くランダムに決定したバックオフ期間の間、キャリアセンスを行い、キャリアセンス結果がアイドルとして、アクセス権（送信権）を獲得したとする。この場合、端末１０２は、基地局１００からデータフレームの送信許可を得るため、データフレームの送信許可を要求するＲＴＳフレーム７１を送信する。端末１０２はＲＴＳフレーム７１を送信する段階で、ＣＴＳフレーム受信後のデータフレーム送信がＵＬ−ＭＵ−ＭＩＭＯ送信になることを想定していなくてもよい。ＲＴＳフレーム７１のフレーム種別（タイプ、サブタイプ）は、制御およびＲＴＳ（送信許可要求）である。ＲＴＳフレーム７１の送信元アドレス（ＴＡ）は端末１０２のＭＡＣアドレス、受信先アドレス（ＲＡ）は基地局１００のＭＡＣアドレスである。このＲＴＳフレーム７１は基地局１００で受信されるとともに、端末１０１、１０３にも受信されるとする。端末１０１、１０３は、ＲＴＳフレーム７１を受信すると、ＲＴＳフレーム７１のＤｕｒａｔｉｏｎフィールドに記載された値に基づきＮＡＶを設定する。また端末１０１、１０３は、当該ＲＴＳフレーム７１のＴＡから、基地局１００にＲＴＳフレーム７１が送信されたことを把握する。

基地局１００は、ＲＴＳフレーム７１を受信すると、フレーム種別、ＴＡ、ＲＡ等を確認し、フレーム種別（タイプ、サブタイプ）が、制御およびＲＴＳ（送信許可要求）、ＴＡが端末１０２、ＲＡが基地局１００であることを把握する。基地局１００は、ＴＡフィールドに格納されたＭＡＣアドレスから端末１０２が属するグループを把握する。基地局１００は、端末１０２が属するグループ内の端末群（端末１０１〜１０３）に、データフレームのＵＬ−ＭＵ−ＭＩＭＯ送信を許可すべく、ＲＡフィールドの所定の第１領域（ここでは先頭ビット）を“１”に設定し、端末１０２が属するグループのグループＩＤを表す値を、ＲＡフィールドの先頭ビット以外の所定の第２の領域に設定したＣＴＳフレーム（本実施形態に係るＣＴＳフレーム）を生成する。ＲＡフィールド内の先頭ビットおよび当該所定の第２領域以外の残りの領域は、予約領域としてもよいし、事前に定義したパターンを設定してもよい。予約領域の場合、予約領域内の各ビットには任意の値（１または０）を設定してかまわない。基地局１００は、このように生成した本実施形態に係るＣＴＳフレーム７２を、ＲＴＳフレーム７１の受信完了からＳＩＦＳと呼ばれる期間の経過後に送信する。なおＣＴＳフレームでは、ＴＡフィールドは存在しない。なお、基地局１００が端末１０２からＲＴＳフレーム７１を受信すると、前述のように端末１０２が属するグループ内の端末群（端末１０１〜１０３）にＵＬ−ＭＵ−ＭＩＭＯ送信を許可するか否かの判断を行い、ＵＬ−ＭＵ−ＭＩＭＯ送信を許可すると判断した場合にデータフレームのＵＬ−ＭＵ−ＭＩＭＯ送信を許可するＣＴＳフレーム７２を送信することになる。

図４（Ａ）は、本実施形態に係るＣＴＳフレームのフォーマットを示す。ＣＴＳフレームは、フレームコントロール（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールド、デュレーション（Ｄｕｒａｔｉｏｎ）フィールド、ＲＡフィールド、ＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ
Ｓｅｑｕｅｎｃｅ）フィールドからなる。

フレームコントロールフィールドは、フレームの種別などを表す情報が設定される。フレーム種別の識別は、フレームコントロールフィールドの中のタイプ（Ｔｙｐｅ）、サブタイプ（Ｓｕｂｔｙｐｅ）という２つのフィールドで行う。ＣＴＳフレームの場合、フレームタイプ（Ｆｒａｍｅ Ｔｙｐｅ）は、制御（Ｃｏｎｔｒｏｌ）を表す値が設定され、フレームサブタイプ（Ｆｒａｍｅ Ｓｕｂｔｙｐｅ）は、ＣＴＳ（送信許可）を表す値が設定される。ＦＣＳフィールドには、フレームのＦＣＳ情報が設定される。ＦＣＳ情報は、受信側でフレームボディ部の誤り検出のため用いられる。Ｄｕｒａｔｉｏｎフィールドは前述した通り、媒体予約時間が設定される。

ＲＡフィールドは６オクテット（４８ビット）の長さを有する。ＲＡフィールドには、通常のＣＴＳフレームでは受信先の端末のＭＡＣアドレスを格納するが、本実施形態に係るＣＴＳフレームでは、ＲＡフィールドには、別途定義したフォーマットの情報を設定する。図４（Ｂ）に、本実施形態に係るＣＴＳフレームにおけるＲＡフィールドのフォーマット例を示す。このようなフォーマットを有するＲＡを、本明細書では、グループＩＤシグナリングＲＡ（Ｇｒｏｕｐ ＩＤ ｓｉｇｎａｌｉｎｇ ＲＡ）と呼ぶ。先頭ビットは、個別／グループ（Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐ）アドレスを格納するフィールドであり、グループを示す“１”（第１の値）が設定される。Ｉ／Ｇビットは、ＲＡフィールドの所定の第１領域に対応する。本実施形態では、Ｉ／Ｇビットは先頭ビットであるが、他の位置のビットがＩ／Ｇビットとして定義されても構わない。また、所定の第１領域は１ビットでなく、２ビット以上の複数ビットとすることも可能である。このとき複数ビットは連続するビットでなく、離れた位置のビットであってもよい。なお、ＭＡＣアドレスは、先頭ビットが個別／グループアドレスを表し、個々の端末（機器）のＭＡＣアドレス（６オクテット）は、Ｉ／Ｇビットが“０”になっている。通常の送信（ユニキャスト送信）では、装置のＭＡＣアドレスがＲＡフィールドにそのまま設定されるため、ＲＡフィールドのＩ／Ｇビットは“０”である。なお、ブロードキャストまたはマルチキャスト送信では、ＲＡフィールドのＩ／Ｇビットは“１”に設定される。通常、ＣＴＳフレームの送信はＲＴＳフレームのＴＡアドレスをコピーして用いるか、後述のようにＲＴＳフレームの受信なく自主的にＣＴＳフレームを送信する場合には自端末のＭＡＣアドレスを入れるため、ユニキャストであることから、ＲＡフィールドのＩ／Ｇビットは“０”であるが、本実施形態に係るＣＴＳフレームでは、Ｉ／Ｇビットを“１”に設定することを特徴の１つとする。

２番目のビットは、予約（Ｒｅｓｅｒｖｅｄ）フィールドである。３番目から８番目の６ビットは、上述した所定の第２領域に相当し、グループＩＤが設定される。残りの４０ビットは、予約フィールドである。予約フィールドには、任意の値を設定（例えばオール０）して構わない。２つの予約フィールドのいずれか一方または両方を、事前に定義したパターン（ｐｒｅｄｅｆｉｎｅｄ ｐａｔｔｅｒｎ）を設定するように変更しても構わない。このパターンを利用することで、グループＩＤで指定したグループ内の端末群に、追加の情報、例えば当該ＣＴＳフレームがＵＬ−ＭＵ−ＭＩＭＯ送信を許可するために送信されたものであることを再確認するための情報、を通知することが可能である。また例えば図４（Ｂ）で予約フィールドとしている部分のうち、２オクテットをＵＬ−ＭＵ−ＭＩＭＯ送信時のデータフレームが媒体を占有する時間、つまりデータフレームを格納する物理パケット長を指定するために用いるようにしてもよい。

ここでは、３番目から８番目の６ビットからなる所定の第２領域にグループＩＤを設定したが、グループＩＤを設定する領域は、ここに限定されるものではない。各端末および基地局で、ＲＡフィールドにおけるグループＩＤが設定された領域を共通に認識できるかぎり、任意の領域を、グループＩＤの設定領域として定義できる。グループＩＤの設定領域は、システムまたは仕様として事前に定義しておいてもよいし、グループＩＤの設定領域を基地局が決定して、基地局から同じＢＳＳ内の各端末に管理フレームを介して、グループＩＤの設定領域を通知するようにしてもよい。この際、グループ毎に、グループＩＤの設定領域の位置が異なってもよく、この場合は、グループごとに、それぞれ個別の設定領域を通知すればよい。

端末１０１〜１０３は、基地局１００から送信された図４のフォーマットのＣＴＳフレーム７２を受信し、フレーム種別（フレームタイプ、フレームサブタイプ）と、ＲＡフィールドを確認する。フレームタイプが制御（Ｃｏｎｔｒｏｌ）、フレームサブタイプがＣＴＳであり、ＲＡフィールドの先頭ビット（個別／グループＩＤ）の値が１であることから、本フレームが、本実施形態に係るＣＴＳフレームであること、すなわち、ＵＬ−ＭＵ−ＭＩＭＯ送信を許可もしくは指示するＣＴＳフレームであることを把握する。また、ＲＡフィールドの所定の第２領域（３〜８ビット目）にグループＩＤが設定されていることを把握する。

端末１０１〜１０３は、ＲＡフィールドの３〜８ビット目からグループＩＤを抽出し、抽出したグループＩＤと、自端末が属するグループのグループＩＤとを比較する。自端末が複数のグループに属していれば、自端末が属している各グループのグループＩＤと比較する。比較の結果、基地局から通知されたグループＩＤのグループに自端末が属していると判断した場合は、ＵＬ−ＭＵ−ＭＩＭＯ送信を行うことを決定する。すなわち、基地局へ送信するデータを含むデータフレームを生成し、本実施形態に係るＣＴＳフレームの受信完了からＳＩＦＳ経過後に、同じグループに属する他の端末とともに、空間多重でデータフレーム（より詳細にはデータフレームを含む物理パケット）を送信する。あるいは、比較の結果、基地局から通知されたグループＩＤのグループに自端末が属していると判断した上で、自端末から基地局に送信するデータフレームがある場合に、ＵＬ−ＭＵ−ＭＩＭＯ送信を行うことを決定するようにしてもよい。この場合には、自端末から基地局に送信するデータフレームがなければ、ＣＴＳフレームの受信完了からＳＩＦＳ経過してもデータフレームを送信しない。あるいは、比較の結果、基地局から通知されたグループＩＤのグループに自端末が属していると判断した上で、自端末から基地局に送信するデータフレームがない場合には、ペイロード部が空のデータパケット（ＩＥＥＥ８０２．１１規格では、例えばＱｏＳ Ｎｕｌｌフレームなど）を送信するようにしてもよい。この場合、さらにペイロード部が空のデータパケットを受信した基地局では、送信元の端末が当該ＴＸＯＰでのそれ以降のアップリンク送信機会にデータフレームを送信しないと解釈するようにすることで、例えば、当該ＴＸＯＰでのそれ以降のアップリンク送信機会には当該送信元の端末分を差し引いた多重数であるとして複数の受信アンテナを残りの端末からのフレーム受信に用いて受信性能を向上させることができる。端末１０１及び端末１０３では、送信するデータフレームがあってＲＴＳフレーム７１を送信した端末１０２とは異なり、このような状況が起こりうる。また、前述のようにＣＴＳフレーム７２の中でＵＬ−ＭＵ−ＭＩＭＯ送信時のデータフレームを格納する物理パケット長が指定されている場合には、端末１０１〜１０３は各々送信するデータフレームがその長さになるよう、あるいはその長さ以下になるように調整するような仕組みにしてもよい。端末１０１〜１０３が各々送信するデータフレームがその長さになるように調整する方法は、ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３でＤＬ−ＭＵ−ＭＩＭＯ送信をする際に用いられる調整手法を参照すればよい。このようにすれば、ＵＬ−ＭＵ−ＭＩＭＯ送信の終了時間を決めることができ、基地局はその終了時間のＳＩＦＳ後に送達確認応答フレームをＵＬ−ＭＵ−ＭＩＭＯ送信を行った端末、この場合は端末１０１〜１０３に送信することができる。

本例では、端末１０１〜１０３が属するグループのグループＩＤが指定されていることから、端末１０１〜１０３からＣＴＳフレームの受信完了からＳＩＦＳ経過後に、データフレーム７３、７４、７５が基地局１００へ空間多重で送信される。なお、ＳＩＦＳは一例であり、固定時間であれば他の時間またはＩＦＳでもよい。ＳＩＦＳより長いＩＦＳでもよい。このことは、本明細書の全体に対して適用される。ＤＩＦＳ等、他の種類のＩＦＳについても同様に、固定時間であれば他の時間またはＩＦＳでもよい。端末１０１、１０３は、端末１０２が送信したＲＴＳフレーム７１を受信しており、そのＲＡフィールドから基地局１００へＲＴＳフレーム７１が送信されたことを把握しているため、ＣＴＳフレーム７２が基地局１００から受信されたと判断できる（前述したようにＣＴＳフレームにはＴＡフィールドは存在しない）。なお、隠れ端末等の理由で、端末１０１または１０３がＲＴＳフレーム７１を受信できていない可能性もある。その場合は、ＣＴＳフレーム７２の送信元は、自端末が接続している基地局１００であると見なしてもよいし、データフレームの送信を行わないようにしてもよい。なお、各データフレーム７３、７４、７５のＲＡフィールドには、基地局１００のＭＡＣアドレスが格納され、ＴＡフィールドには各端末のＭＡＣアドレスが格納される。なお、各データフレーム７３、７４、７５のＲＡフィールドおよびＴＡフィールドの先頭ビット（個別／グループＩＤ）は“０”である。なお、本例では、端末１０２は、自端末のＭＡＣアドレスをＴＡフィールドに設定したＲＴＳフレームを送信した後、自端末が属するグループのグループＩＤが設定されたＣＴＳフレームを受信するが、ＲＡフィールドに自端末のＭＡＣアドレスを設定したＣＴＳフレームは受信しない。この場合においても、端末１０２は、ＲＡフィールドに自端末のＭＡＣアドレスを設定したＲＴＳフレームの再送を行う必要はない（すなわち当該ＲＴＳフレームの再送をキャンセルする）。この判断は、ＭＡＣ／ＰＨＹ管理部６０および受信処理部４０が行えばよい。

このように、図４に示したフォーマットを有する本実施形態に係るＣＴＳフレームは、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を通知するとともに、ＵＬ−ＭＵ−ＭＩＭＯ送信の開始タイミングを決めるトリガとしても機能する。なお、端末１０１〜１０３から基地局１００に送信するデータフレームの個数もしくは長さは前述のようにＣＴＳフレームの中で通知しない場合には事前に定義しておき、これに従うものとする。

ここで、基地局１００が、ＲＴＳフレーム（図３のＲＴＳフレーム７１参照）の受信をトリガとし、図４に示したフォーマットを有する本実施形態に係るＣＴＳフレームを送信することで、ＵＬ−ＭＵ−ＭＩＭＯの送信を許可または指示できる理由について詳しく説明する。

ＩＥＥＥ Ｓｔｄ ８０２．１１−２０１２では、ＲＴＳフレームの送信時に、自端末からのＲＴＳフレーム送信の長さと送信先からのＣＴＳフレーム送信とを考慮して、ＲＴＳフレームのＤｕｒａｔｉｏｎ値を設定する。Ｄｕｒａｔｉｏｎ値が、送信先以外の端末でのＮＡＶ設定に用いられる。またＩＥＥＥ Ｓｔｄ ８０２．１１−２０１２では９．３．２．４節に、ＲＴＳフレームの送信先以外の端末で、当該ＲＴＳフレームの受信に起因して設定したＮＡＶをリセットする動作が記述されている。具体的に、ＲＴＳフレームの受信完了から、２×ＳＩＦＳ（図３のＣＴＳフレーム７２の前後のＳＩＦＳ参照）と、ＣＴＳフレームの送信時間（ＣＴＳフレームの伝送レートは、ＲＴＳフレームの伝送レートで決まる）と、２×ＳｌｏｔＴｉｍｅとを加算した時間だけ経過しても、ＣＣＡ検出（例えばＣＴＳフレーム７２の後のＳＩＦＳ後のＣＣＡ検出）できなければ、ＮＡＶをリセットする。なお、ＳｌｏｔＴｉｍｅは、ＣＣＡを検出できる時間であり、余裕を見て、２倍の時間を取っている。

従って、ＲＴＳフレームをトリガにした、フレームシーケンスを考える場合には、少なくとも、従来のＣＴＳフレームと同じ長さで、かつＲＴＳの送信レートをベースに一意に定められる送信レートを用いた制御フレームを、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示、および対象となるグループＩＤを通知するための応答フレームとして送信しなくてはならない。

一方、ＣＴＳフレーム、ＡＣＫフレーム、ＢＡ（ＢｌｏｃｋＡｃｋ）フレームといった応答の制御フレームは、その応答を発動するフレーム（ＣＴＳフレームの場合はＲＴＳフレーム、ＡＣＫフレームの場合はＤａｔａフレーム（Ａｇｇｒｅｇａｔｅされた場合も含む）、ＢＡフレームの場合はＤａｔａフレーム（Ａｇｇｒｅｇａｔｅされた場合も含む）となる）のＴＡフィールドをコピーして、当該制御フレームのＲＡフィールドに用いる。そして、ＴＡフィールドは、通常の送信ではフレームを送信する端末のＭＡＣアドレス、すなわちユニキャストアドレスを指定するので、Ｉ／Ｇビットは０に設定しなくてはならない。このため、応答フレームでのＴＡフィールドのＩ／Ｇビットが０であると期待されるフレームを受信して発動される当該応答フレームでは、ＲＡフィールドのＩ／Ｇビットを、グループＩＤがＲＡフィールドに含まれているか否かの識別に用いることができる。すなわち、ＲＡフィールドのＩ／Ｇビットが１であれば、グループＩＤがＲＡフィールドに含まれていると判断することができる。

またＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３での、ｂａｎｄｗｉｄｔｈ ｓｉｇｎａｌｉｎｇ ＴＡを用いるフレームは、ＲＴＳフレーム （もしくはＲＴＳフレームを内包したｃｏｎｔｒｏｌ ｗｒａｐｐｅｒフレーム。なお、ＣＴＳフレームに関しても同様）であり、それに対する応答フレームはＣＴＳフレームとなる。ｂａｎｄｗｉｄｔｈ ｓｉｇｎａｌｉｎｇ ＴＡをコピーして、コピーした値を、ＣＴＳフレームのＲＡフィールドに用いる際に、Ｉ／Ｇビットは１から０に戻すことになっている。つまり、ｂａｎｄｗｉｄｔｈ ｓｉｇｎａｌｉｎｇ ＴＡを用いたフレームを受信して発動される応答フレームでも、ＲＡフィールドはＩ／Ｇビットを０とすることになっている。よって、この点からも、ＲＡフィールドのＩ／Ｇビットを、グループＩＤがＲＡフィールドに含まれているか否か（ＭＡＣアドレスの一部として用いられているか否か）の識別に用いることができる。なお、本実施形態でもｂａｎｄｗｉｄｔｈ ｓｉｇｎａｌｉｎｇ ＴＡを用いるフレームに対応してＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行わない通常の応答フレームを送信すると判断すれば、受信したフレームの送信元アドレスフィールドをコピーした値の先頭ビットの値が１の場合は、コピーした値の先頭ビットの値を０に変更したものを、当該フレームに対する応答フレームの受信先アドレスフィールドに設定するようにすればよい。その場合受信処理部４０は、このように先頭ビットの値を０に変更したアドレスを、送信処理部３０に応答フレームを生成するための情報として渡す。

このようなＲＴＳフレームおよびＣＴＳフレームついての制約のもと、本実施形態では、端末１０２からＲＴＳフレームを受信した基地局１００が、グループＩＤを利用して、端末１０２を含む、当該グループＩＤで指定されるグループに属する端末群に、ＵＬ−ＭＵ−ＭＩＭＯ送信を許可もしくは指示するフレームとして、ＣＴＳフレームのＲＡフィールドを、図４（Ｂ）のように変更したフレーム（本実施形態に係るＣＴＳフレーム）を送信する。そして、このＣＴＳフレームを受信した端末群は、端末１０２を含め、自端末が、当該グループＩＤが示すグループに属すると判断して、ＵＬ−ＭＵ−ＭＩＭＯ送信を行う。具体的な動作として、端末１０１〜１０３は、当該ＣＴＳフレームを受信すると、フレーム種別（タイプ、サブタイプ）が、制御およびＣＴＳであることを把握し、ＲＡフィールドの先頭ビット（Ｉ／Ｇビット）を確認する。当該ビットが１であることを判断すると、第３〜第８番目のビットＢ２−Ｂ７の領域（所定の第２領域）の値をグループＩＤとして抽出する。抽出したグループＩＤが、自端末が属するグループのグループＩＤに一致するか確認し、一致する場合に、ＣＴＳフレームの受信完了からＳＩＦＳ後に、データフレームを送信する。その結果、複数の端末からのＵＬ−ＭＵ−ＭＩＭＯ送信となる。

図３において、基地局１００は、端末１０１〜１０３からＵＬ−ＭＵ−ＭＩＭＯ送信されたデータフレームを受信し、受信信号をＭＩＭＯ復調してストリームごとに分離し、各端末から送信されたデータフレームを取得する。各端末から送信されるデータフレームのＴＡは、各端末のＭＡＣアドレスであり、ＴＡの先頭ビット（Ｉ／Ｇビット）は０である。ＲＡは、基地局１０１のＭＡＣアドレスであり、ＲＡの先頭ビット（Ｉ／Ｇビット）は０である。端末（基地局を含む）のＭＡＣアドレスの先頭ビットとして取ることができる値は０であることが事前に定義されている。なお、基地局にＵＬ−ＭＵ−ＭＩＭＯ送信されるデータフレームあるいはそれを内包する物理パケットには、グループＩＤは入れる必要はない。基地局１００は、各端末のデータフレームの受信に成功したかを、データフレームのＦＣＳフィールドに基づき判断する。基地局１００は、各端末のデータフレームの受信の成功可否情報（ＡＣＫ情報）を格納した送達確認応答フレーム７６を生成し、送達確認応答フレーム７６を、ＵＬ−ＭＵ−ＭＩＭＯ送信信号の受信完了から、ＳＩＦＳ経過後に送信する。

この送達確認応答フレームでも、ＲＡフィールドにグループＩＤを入れる手法を利用できる。ＴＡフィールドが自端末のＭＡＣアドレス、ＲＡフィールドが基地局１００のＭＡＣアドレスであるデータフレームを送信した端末は、その応答として、ユニキャストの応答フレームを受信することを期待する。つまり、ＲＡフィールドが、自端末が送信したデータフレームのＴＡフィールドの値のコピーである応答フレームを受信することを期待する。よって、基地局１００に送信したデータフレームに対する応答フレームのＲＡフィールドのＩ／Ｇビットを、グループＩＤがＲＡフィールドに設定されているかの識別に用いることができる。すなわち、Ｉ／Ｇビットが１であれば、ＲＡフィールドにグループＩＤが設定されていると判断できる。なお、前述のＣＴＳフレーム７２の場合と同様、ＲＡフィールド内のＩ／ＧビットとグループＩＤを指定する領域以外の場所で、例えば事前に定義したパターンを設定するようにしてもよいし、例えば２オクテットをＵＬ−ＭＵ−ＭＩＭＯ送信時のデータフレームが媒体を占有する時間、つまりデータフレームを格納する物理パケット長を指定するために用いるようにしてもよい。送達確認応答フレーム７６の中でＵＬ−ＭＵ−ＭＩＭＯ送信時のデータフレームを格納する物理パケット長が指定されていれば、端末１０１〜１０３は同一ＴＸＯＰ内で続けてデータフレームを送信できる場合に、次に各々が送信するデータフレームをその長さになるよう、あるいはその長さ以下になるように調整するような仕組みを設けることで、次のＵＬ−ＭＵ−ＭＩＭＯ送信の終了時間を決めることができ、基地局はその終了時間のＳＩＦＳ後にその次のＵＬ−ＭＵ−ＭＩＭＯ送信に対する送達確認応答フレームをＵＬ−ＭＵ−ＭＩＭＯ送信を行った端末、この場合は端末１０１〜１０３に送信することができる。

ここで送達確認応答フレームのフォーマットとして、新規フレームを定義してもよいし、ＢＡ（ＢｌｏｃｋＡｃｋ）フレームを再利用し、ＢＡフォーマットを拡張してもよい。

ＢＡフレームを再利用する場合、通常のＢＡフレームと同様、フレームタイプは制御（Ｃｏｎｔｒｏｌ）、フレームサブタイプはＢｌｏｃｋＡｃｋとなる。このようにＢＡフレームを再利用したフレームをＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋと呼んでもよい。図５（Ａ）にＢＡフレームを再利用する場合のフレームフォーマット例を示す。図５（Ｂ）は、ＢＡフレームにおけるＢＡ Ｃｏｎｔｒｏｌフィールドのフォーマットの例を示し、図５（Ｃ）は、ＢＡフレームにおけるＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールドのフォーマットの例を示す。複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであるということは、ＢＡ Ｃｏｎｔｒｏｌフィールドの中で示してもよい。例えばＩＥＥＥ８０２．１１規格では、Ｍｕｌｔｉ−ＴＩＤサブフィールドが１でＣｏｍｐｒｅｓｓｅｄ Ｂｉｔｍａｐサブフィールドが０の場合が現状予約（Ｒｅｓｅｒｖｅｄ）になっているが、これを複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであることを示すために用いるようにしてもよい。あるいは図５（Ｂ）ではビットＢ３−Ｂ８の領域が予約サブフィールドになっているが、この領域の一部または全てを複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであることを示すために定義してもよい。

ＢＡフレームにおけるＲＡフィールドは、図４（Ｂ）に示したフォーマットを有するグループＩＤシグナリングＲＡ（Ｇｒｏｕｐ ＩＤ ｓｉｇｎａｌｉｎｇ ＲＡ）を格納する。ＢＡ ＣｏｎｔｒｏｌフィールドのＭｕｌｔｉ−Ｕｓｅｒサブフィールドには、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールドでレポートするユーザ数（端末数）を通知する。ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールドには、ユーザ（端末）ごとに、アソシエーションＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ：ＡＩＤ）用のサブフィールド（図５（Ｃ）ではＰｅｒ ＴＩＤ Ｉｎｆｏと記載）と、Ｂｌｏｃｋ Ａｃｋ開始シーケンスコントロール（Ｂｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ）サブフィールドと、Ｂｌｏｃｋ Ａｃｋビットマップ（Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐ）サブフィールドとを配置する。アソシエーションＩＤサブフィールドにはユーザ識別を行うためＡＩＤを入れる。Ｂｌｏｃｋ Ａｃｋ開始シーケンスコントロールサブフィールドには、当該ＢｌｏｃｋＡｃｋフレームが示す送達確認情報の最初のＭＳＤＵのシーケンス番号を格納する。Ｂｌｏｃｋ Ａｃｋビットマップサブフィールドには、Ｂｌｏｃｋ Ａｃｋ開始シーケンス番号以降の各シーケンス番号の受信成功可否のビット（ＡＣＫ情報）からなるビットマップ（Ｂｌｏｃｋ Ａｃｋビットマップ）を入れる。なお、当該ＢＡフレームの中に同一ＴＸＯＰでの同一グループＩＤによるＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示をするようなフィールドを設けてもよい。ＢＡ Ｃｏｎｔｒｏｌフィールドとして図５（Ｂ）ではビットＢ３−Ｂ８の領域が予約サブフィールドになっているが、例えばこの領域の一部を同一ＴＸＯＰでの同一グループＩＤによるＵＬ−ＭＵ−ＭＩＭＯ送信の継続許可または指示として使うようにすればよい。ＲＡフィールドの一部に設けるのでもよい。この場合、当該情報は１ビットあれば例えばその値が１であれば継続可能、０であれば継続不可を示すことができ、十分と考えられる。そうすれば、当該ＢＡフレームを受信した端末では同一ＴＸＯＰ内で再びＢＡフレームのＳＩＦＳ後に続けてＵＬ−ＭＵ−ＭＩＭＯ送信をすることができる。

送達確認応答フレーム７６が、ＢＡフレームを再利用したフレームの場合、この送達確認応答フレーム７６を受信した端末は、送達確認応答フレーム７６のフレームコントロールフィールドのフレームタイプおよびフレームサブタイプを確認する。これらが、制御およびＢｌｏｃｋＡｃｋであることを検出すると、次に、ＲＡフィールドのＩ／Ｇビットを確認し、この値が１であることから、このＲＡフィールドが、図４（Ｂ）に示したフォーマットを有するグループＩＤシグナリングＲＡ（Ｇｒｏｕｐ ＩＤ ｓｉｇｎａｌｉｎｇ ＲＡ）を格納していると判断する。そして、ＲＡフィールドの３〜８番目のビットの値をグループＩＤとして抽出し、抽出したグループＩＤと、自端末が属するグループのグループＩＤとを比較する。抽出したグループＩＤが自端末の属するグループのグループＩＤに一致している場合は、自端末が送信した（１つ以上の）データフレームに対するＡＣＫ情報をＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐフィールドから特定し、自端末が送信したデータフレームの送信成功の可否を判断する。例えば、自端末のＡＩＤを格納しているＴＩＤ Ｉｎｆｏサブフィールドを、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド内から特定し、特定したＴＩＤ Ｉｎｆｏサブフィールドに後続するＢｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌサブフィールドに設定された値（開始シーケンス番号）を特定し、開始シーケンス番号以降の各シーケンス番号の送信成功の可否を、Ｂｌｏｃｋ Ａｃｋビットマップから特定する。ＡＩＤのビット長は、ＴＩＤ Ｉｎｆｏサブフィールド長より短くてよく、ＡＩＤをＴＩＤ Ｉｎｆｏサブフィールドの一部の領域（例えば２オクテット（１６ビット）のうち先頭から１１ビット（Ｂ０−Ｂ１０））に格納されている。なお、ＢＡ Ｃｏｎｔｒｏｌフィールドの中で、複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであるということが示されている場合には、送達確認応答フレーム７６のフレームコントロールフィールドのフレームタイプおよびフレームサブタイプから制御およびＢｌｏｃｋＡｃｋであることを検出した後、ＲＡフィールドを確認してＲＡフィールドがグループＩＤシグナリングＲＡを格納していると判別すると、ＢＡ Ｃｏｎｔｒｏｌフィールドを確認して複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであるかを確認する手順を入れるようにしてもよい。この場合に複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットであればＲＡフィールドからグループＩＤを抽出する作業以降を継続し、複数の端末に関する送達確認応答情報を通知するために拡張したＢＡフレームフォーマットでなければ、受信したフレームがエラーであるとして処理する。

複数の端末にＢＡフレームではなくＡＣＫフレームを返す場合は、各ＢＡ情報フィールドのＴＩＤ Ｉｎｆｏサブフィールドにおける１つのビット（例えば２オクテット（１６ビット）のうち、先頭から１２ビット目（先頭をＢ０とすれば、Ｂ１１））をＡＣＫかＢＡかを示すビット（ＡＣＫ／ＢＡビット）として用い、当該ビットにＡＣＫを示す値を設定するようにしてもよい。ＡＣＫを示す値を設定した場合に、Ｂｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐサブフィールドは省略する。これにより、１つのフレームで複数の端末のＡＣＫを通知できる。

上述した例では、ＢＡフレームを再利用してＢＡまたはＡＣＫを応答する場合を示したが、グループＩＤを設定する送達確認応答フレームとして、新規フレームを定義する場合は、例えば図６に示すフォーマットを用いることができる。フレームコントロールフィールドのフレームタイプは制御とし、サブタイプは例えばサブタイプとしてＧｒｏｕｐ ＩＤ Ａｃｋとして新規の値を定義する。ここでサブタイプを従来と同様のＡＣＫとして設定してしまうと、グループＩＤシグナリングＲＡに対応しない端末では、従来のＡＣＫフレーム長と異なるために受信したフレームがエラーであると処理してしまう可能性があるため、サブタイプはＡＣＫとは別の新規の値を定義すべきである。ＲＡフィールドは、図４（Ｂ）に示したフォーマットを有するグループＩＤシグナリングＲＡ（Ｇｒｏｕｐ ＩＤ ｓｉｇｎａｌｉｎｇ ＲＡ）を設定する。Ａｃｋビットマップフィールドには、各端末の受信成功可否を表す情報（ＡＣＫ情報）を格納する。Ａｃｋビットマップフィールドのフォーマットは任意でよいが、一例として、ＢｌｏｃｋＡｃｋの場合のＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド（図５（Ｃ）参照）と同様のフォーマットを採用してもよい。これに限られず、端末とシーケンス番号とＡＣＫ情報との対応関係が明確であれば、どのようなフォーマットを採用としてもよい。なお、ＵＬ−ＭＵ−ＭＩＭＯ送信で送信するデータフレーム数が１つに限定される場合は、シーケンス番号に関する情報を、送達確認応答フレームから省略してもよい。このとき、管理フレームで同じグループに属する各端末の順序を指定する情報を事前に通知しておき、Ａｃｋビットマップフィールドには、当該順序で、各端末について、ＡＣＫ情報を１つずつ配置してもよい。これによれば、Ａｃｋビットマップフィールドには端末を識別する情報（ＡＩＤ等の情報）を入れる必要はないため、ＡＣＫビットマップフィールド長を短くできる利点がある。この場合、送達確認応答フレームを受信した端末は、Ａｃｋビットマップフィールドにおいて、予め通知された自端末の順位に応じた位置のビットを特定し、特定したビットからＡＣＫ情報を抽出する。ＢｌｏｃｋＡｃｋにおける図５（Ｃ）の例のように開始シーケンス番号と、当該開始シーケンス番号以降の各シーケンス番号のＡＣＫ情報を格納する場合も、予め各端末の順位を指定して、同様にして実施可能である。すなわち、予め通知された自端末の順位に応じた位置のフィールドをＡｃｋビットマップフィールドにおいて特定し、特定したフィールドの先頭側の領域から開始シーケンス番号を特定し、後ろ側の領域の各ビットから、当該開始シーケンス番号以降の各シーケンス番号のＡＣＫ情報を抽出すればよい。ここでは、各端末の順位を指定する情報を事前に管理フレームで通知したが、各端末の順位を指定するフィールドを図６の送達確認応答フレームに追加し（たとえばＲＡフィールドとＡｃｋビットマップフィールドの間に追加し）、これを利用して各端末は、自端末の順位を把握してもよい。当該新規フレームにおいても、ＢＡフレームの場合で記述したようにフレーム中に同一ＴＸＯＰでの同一グループＩＤによるＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示を示す情報を設けてもよい。例えば当該情報はグループＩＤシグナリングＲＡとして用いるＲＡフィールドの一部サブフィールドとして入れることができる。

なお、本実施形態では、グループＩＤと、各端末に対するＡＣＫ情報とを１つの送達確認応答フレームに格納して、各端末に同時に送信したが、図７に示すように、各端末に個別に送達確認応答フレーム７６ａ、７６ｂ、７６ｃを生成して、それぞれＳＩＦＳ間隔で、順番に送信するようにしてもよい。この場合、送達確認応答フレームは、公知のＡｃｋフレームもしくはＢＡフレームでよく、個々の送達確認応答フレームのＲＡフィールドには、各端末のＭＡＣアドレス（Ｉ／Ｇビットは０）を設定すればよい。

図８は、本実施形態に係る基地局の基本的な動作例のフローチャートである。

基地局は、ＢＳＳ内の端末からＲＴＳフレームを受信する（Ｓ１０１）。すなわち、フレーム種別（タイプ、サブタイプ）が、制御（Ｃｏｎｔｒｏｌ）およびＲＴＳであるフレームを受信する。基地局は、予めＵＬ−ＭＵ−ＭＩＭＯ送信用のグループを管理しており、ＲＴＳフレームを送信した端末が属するグループを、ＲＴＳフレームのＴＡに基づき特定する（Ｓ１０２）。そして、個別／グループビット（Ｉ／Ｇビット）を１に設定し、当該特定したグループのグループＩＤをＲＡフィールドの所定の第２領域（図４（Ｂ）のＢ２〜Ｂ７ビット、すなわち３〜８番目のビット）に設定したＣＴＳフレームを生成する（Ｓ１０３）。このとき、ＣＴＳフレームのフレームコントロールフィールドのフレーム種別（タイプ、サブタイプ）は、通常のＣＴＳフレームと同様に、制御およびＣＴＳを示す値を設定する。基地局は、生成したＣＴＳフレームを、ＲＴＳフレームの受信完了からＳＩＦＳ後に送信する（同Ｓ１０３）。なお、前述のように厳密にはＳ１０１の後で、Ｓ１０３までの間に、ＲＴＳフレームの送信元端末が属するグループにＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示を送信するか否かの判断を行うことになる。例えばＳ１０１の直後にこの判断を行うようにしてもよいし、Ｓ１０２でグループを特定した後にＲＴＳフレームの送信元端末からだけのシングルユーザ（Ｓｉｎｇｌｅ−Ｕｓｅｒ；ＳＵ）送信をさせるようにするか、あるいは、特定したグループからのＵＬ−ＭＵ−ＭＩＭＯ送信ができるようにするかを、基地局で保持する情報に基づいて判断するようにしてもよい。ＲＴＳフレームの送信元端末からだけのＳＵ送信をさせるように判断した場合には、Ｓ１０３の代わりに通常のＣＴＳフレームを生成し送信し、後述のＳ１０４の代わりにＲＴＳフレームの送信元端末からだけのデータフレームを受信し、Ｓ１０５の代わりに従来の送達確認応答フレームを生成し送信することになる。

基地局は、ＣＴＳフレームの送信完了からＳＩＦＳ経過後に、ＣＴＳフレームで通知したグループＩＤのグループに属する端末群からＵＬ−ＭＵ−ＭＩＭＯ送信されるデータフレームを受信する（Ｓ１０４）。基地局は、受信したＵＬ−ＭＵ−ＭＩＭＯ送信信号をＭＩＭＯ復調することでストリーム毎の信号を取得し、信号を復号することで、各端末のデータフレームを得る。基地局は、データフレームのＦＣＳ情報に基づき、受信成功の可否を判定し、受信成功の可否を示す情報（ＡＣＫ情報）を生成する（Ｓ１０５）。端末毎に複数のデータフレームを受信する場合は、各データフレームのＡＣＫ情報を生成する。基地局は、送達確認応答フレームとして、ＲＡフィールドのＩ／Ｇビットを１に設定し、グループＩＤをＲＡフィールドの所定の第２領域（図４（Ｂ）のＢ２〜Ｂ７ビット、すなわち３〜８番目のビット）に設定し、また、各端末のデータフレームに対するＡＣＫ情報を、使用するフレームフォーマットに応じて所定のフィールドに格納した応答フレームを生成する（同Ｓ１０５）。基地局は、生成した応答フレームを、ＵＬ−ＭＵ−ＭＩＭＯ送信信号の受信完了からＳＩＦＳ後に、各端末に同時に送信する（同Ｓ１０５）。継続して同一ＴＸＯＰでの同一グループＩＤによるＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示をする場合には、Ｓ１０４とＳ１０５が同一ＴＸＯＰで繰り返されることになる。

図９は、本実施形態に係る端末の基本的な動作例のフローチャートである。

基地局へ送信するデータを有する端末は、例えばＤＩＦＳおよび必要に応じてバックオフ期間のキャリアセンスによりアクセス権（送信権）を獲得したら、ＲＴＳフレームを基地局に送信する（Ｓ２０１）。ＲＴＳフレームのＴＡアドレスは、当該アクセス権を獲得した端末のＭＡＣアドレス（Ｉ／Ｇビットは０）、ＲＡアドレスは基地局のＭＡＣアドレス（Ｉ／Ｇビットは０）である。以下に説明するステップＳ２０２〜Ｓ２０８は、ステップＳ２０１でＲＴＳフレームを送信した端末以外の端末についても適用される。

端末は、ＲＴＳフレームを受信した基地局から送信されるＣＴＳフレームを受信する（Ｓ２０２）。端末は、当該ＣＴＳフレームのフレームコントロールフィールドに基づきフレーム種別（タイプ、サブタイプ）を調べ、制御およびＣＴＳであることを把握する。そして、当該ＣＴＳフレームのＲＡフィールドのＩ／Ｇビット（先頭ビット）が１であることから、ＲＡフィールドの所定の第２領域（図４（Ｂ）のＢ２〜Ｂ７ビット、すなわち３〜８番目のビット）にグループＩＤが設定されていると判断し、当該所定の第２領域からグループＩＤを読み出す（Ｓ２０３）。

端末は、読み出したグループＩＤと、自端末が属しているグループのグループＩＤと比較する（Ｓ２０４）。両グループＩＤが一致する場合（ＹＥＳ）、基地局からＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示されたグループに属していると判断し、基地局にデータフレームをＵＬ−ＭＵ−ＭＩＭＯ送信することを決定する。そして、端末は、基地局へ送信したいデータを含むデータフレームを生成して、ＣＴＳフレームの受信完了から、ＳＩＦＳ経過後に、基地局にＵＬ−ＭＵ−ＭＩＭＯ送信する（Ｓ２０５）。グループＩＤが一致しない場合は（ＮＯ）、自端末が、基地局からＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示されたグループに属していないと判断し、送信は行わない。

端末は、データフレームの送信後、基地局から送信される送達確認応答フレーム（図５または図６参照）を受信する。端末は、送達確認応答フレームのフレームコントロールフィールドに基づきフレーム種別（タイプ、サブタイプ）を判定する。例えば図５のＢｌｏｃｋＡｃｋを再利用した応答フレームの場合、フレーム種別（タイプ、サブタイプ）は、制御およびＢｌｏｃｋＡｃｋであり、ＲＡフィールドの個別／グループＩＤビットは１である。この場合、端末は、これらのフレーム種別および個別／グループＩＤビットを把握すると、所定の第２領域（図４（Ｂ）のＢ２〜Ｂ７ビット、すなわち３〜８番目のビット）にグループＩＤが設定されていると判断し、当該領域からグループＩＤを読み出す（Ｓ２０６）。端末は、読み出したグループＩＤと、自端末が属しているグループのグループＩＤと比較する（Ｓ２０７）。両グループＩＤが一致すると（ＹＥＳ）、自端末のＡＩＤに対応するＢｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌサブフィールドとＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐサブフィールドを特定し、特定したこれらのサブフィールドから、自端末が送信したデータフレームのＡＣＫ情報を特定し、ＡＣＫ情報に基づきデータフレーム送信の成功可否を判定する（Ｓ２０８）。両グループＩＤが一致しない場合、他のグループに属する端末のＡＣＫ情報が格納されていると判断し、何も行わない。すなわち両グループＩＤが一致しない場合、送達確認応答フレームを受信していないとして処理する。両グループＩＤが一致しない場合と、Ｓ１０８で送信したデータフレームのいずれかが不成功であると判定した場合は、従来の再送処理と同様で、再度自端末が基地局に送信する機会を得た場合に再送対象のデータフレームを送信する。この再度自端末が基地局に送信する機会はＳ２０５のＵＬ−ＭＵ−ＭＩＭＯ送信と同一のＴＸＯＰ内であってもよい。継続して同一ＴＸＯＰでの同一グループＩＤによるＵＬ−ＭＵ−ＭＩＭＯ送信の許可または指示を受けた場合には、同一ＴＸＯＰであればＳ２０５に戻ることになる。なおその場合、Ｓ２０８の処理とＳ２０５の処理は前後してもよい。

ステップＳ２０６において、送達確認応答フレームが図６に示したような新たに定義したフレームの場合、フレーム種別（タイプ、サブタイプ）は、制御および例えばＧｒｏｕｐ ＩＤ Ａｃｋであり、ＲＡフィールドのＩ／Ｇビットは１である。この場合、端末は、これらのフレーム種別およびＩ／Ｇビットを把握すると、所定の第２領域（図４（Ｂ）のＢ２〜Ｂ７ビット、すなわち３〜８番目のビット）にグループＩＤが設定されていると判断し、当該領域からグループＩＤを読み出す（Ｓ２０６）。そして、当該グループＩＤと、自端末が属しているグループのグループＩＤと比較し（Ｓ２０７）、一致する場合は（ＹＥＳ）、Ａｃｋ Ｂｉｔｍａｐフィールドから自端末のＡＣＫ情報を特定し、ＡＣＫ情報に基づきデータフレーム送信の成功可否を判定する（Ｓ２０８）。

以上、本実施形態によれば、端末からのユニキャストのＭＡＣフレームにより誘発されて送信するＭＡＣフレームであって、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示をするＭＡＣフレームを送信する際、ＭＡＣフレームのＲＡフィールドのＩ／Ｇビットを１にし、残りのフィールド領域の一部に、ＭＡＣアドレスよりも短いマルチユーザ用に定義したグループＩＤを入れる。具体的に、端末から受信するＲＴＳフレームに対して、ＲＡフィールドのＩ／Ｇビット（先頭ビット）を“１”にし、ＲＡフィールドの所定の第２領域（３〜８ビット目）に、当該端末が属するグループのグループＩＤを入れたＣＴＳフレームを応答する。これによれば、当該ＣＴＳフレームのＲＡフィールドの値が、ＢＳＳ内の端末のＭＡＣアドレス、もしくは将来ＢＳＳに加入する端末のＭＡＣアドレスに一致する可能性はないため、特段問題を発生させることなく、ＲＡフィールドにグループＩＤを設定できる。また、既存のＲＴＳ−ＣＴＳの枠組みを利用して、ＵＬ−ＭＵ−ＭＩＭＯ送信を実現でき、ＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するためのフレームを新たに定義する必要はない。

また、上記のＣＴＳフレームを受信した端末は、フレームコントロールフィールドからフレーム種別（タイプおよびサブタイプ）が、制御よびＣＴＳであることを判定し、ＲＡフィールドのＩ／Ｇビットが１であることから、当該ＣＴＳフレームがＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するものであること、かつＲＡフィールド内の所定フィールド領域にグループＩＤが入っていることを把握できる。そして端末は、ＲＡフィールドからグループＩＤを読み出し、当該グループＩＤに一致するグループに自端末が属している場合は、予め定められたタイミングでＵＬ−ＭＵ−ＭＩＭＯ送信を行う。通常の場合、フレーム種別（タイプおよびサブタイプ）が、制御およびＣＴＳであれば、ＲＡフィールドのＩ／Ｇビット（先頭ビット）は０である。これは、通常であれば、ＲＴＳフレームのＴＡフィールドの値をコピーしてＣＴＳフレームのＲＡフィールドに入れるためである。しかしながら、本実施形態に係るＣＴＳフレームでは、ＲＡフィールドのＩ／Ｇビットを１に設定するため、ＣＴＳフレームを受信した端末は、本ＣＴＳフレームがＵＬ−ＭＵ−ＭＩＭＯ送信を許可または指示するフレームであり、ＲＡフィールド内にグループＩＤが入っていることを識別できる。

また、本実施形態によれば、複数端末からのＵＬ−ＭＵ−ＭＩＭＯ送信への応答となる送達確認応答フレーム（ＢＡフレームを流用したフレーム、または新規に定義したフレーム等）を送信する際、送達確認応答フレームのＲＡフィールドのＩ／Ｇビットを１にし、残りのフィールド領域の一部に、グループＩＤを入れる。これによれば、当該送達確認応答フレームのＲＡフィールドの値が、ＢＳＳ内の端末のＭＡＣアドレス、もしくは将来ＢＳＳに加入する端末のＭＡＣアドレスに一致する可能性はないため、特段問題を発生させることなく、ＲＡフィールドにグループＩＤを設定できる。

また、上記の送達確認応答フレームを受信した端末は、フレームコントロールフィールドからフレーム種別（タイプおよびサブタイプ）が、制御およびＢｌｏｃｋＡｃｋ（または例えばＧｒｏｕｐ ＩＤ Ａｃｋのように送達確認応答フレームの一種）であることを判定し、ＲＡフィールドのＩ／Ｇビットが１であることから、当該送達確認応答フレームがＵＬ−ＭＵ−ＭＩＭＯ送信に対するＡＣＫ情報を格納したフレームであること、かつＲＡフィールド内の所定の第２領域にグループＩＤが設定されていることを把握できる。そして端末は、ＲＡフィールドの当該所定の第２領域からグループＩＤを読み出し、当該グループＩＤに一致するグループに自端末が属している場合は、予め定められた方法で、自端末のＡＣＫ情報を送達確認応答フレームから特定して、データフレーム送信の成功可否を判断する。なお、システムまたは仕様上、送達確認応答フレームのＲＡフィールドをブロードキャストアドレスまたはマルチキャストアドレス（この場合、Ｉ／Ｇビットは１とする）に設定することが許容されている場合、ＲＡフィールドの値がブロードキャストアドレスまたはマルチキャストアドレスに一致しないことを確認できた場合のみ、所定の第２領域にグループＩＤが入っていると判断してもよい。

なお、本実施形態ではＵＬ−ＭＵ−ＭＩＭＯ送信の場合で説明を行ったが、アップリンクのＯＦＤＭＡ （Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）に適用してもよい。アップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）は、１つまたは複数のサブキャリアをリソースユニット（サブチャネル、リソースブロック、周波数ブロックなどと呼んでもよい）として端末に割り当て、リソースユニットベースで、複数の端末からの受信を同時に行う通信方式である。リソースユニットは、通信を行うリソースの最小単位となる周波数成分である。リソースユニットは、通信を行うリソースの最小単位となる周波数成分である。図２０に、１つのチャネル（ここではチャネルＭと記述している）の連続した周波数領域内に確保したリソースユニット（ＲＵ＃１、ＲＵ＃２、・・・ＲＵ＃Ｋ）を示す。チャネルＭには、互いに直交する複数のサブキャリアが配置されており、１つまたは複数の連続するサブキャリアを含む複数のリソースユニットがチャネルＭ内に定義されている。リソースユニット間には、１つ以上のサブキャリア（ガードサブキャリア）が配置されてもよいが、ガードサブキャリアは必須ではない。チャネル内の各サブキャリアには、サブキャリアを識別するための番号が付与されていてもよい。１つのチャネルの帯域幅は、一例として、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚなどであるが、これらに限定されない。２０ＭＨｚの複数のチャネルをまとめて１つのチャネルとしてもよい。帯域幅に応じてチャネル内のサブキャリア数またはリソースユニット数が異なってもよい。複数の端末がそれぞれ異なるリソースユニットを同時に用いることで、アップリンクＯＦＤＭＡ通信が実現される。なお、リソースユニットを２０ＭＨｚのチャネルとし、２０ＭＨｚのチャネル単位で各端末にリソースユニットを割り当てることも可能である。ＵＬ−ＭＵ−ＭＩＭＯの場合には各端末をストリームにより分離していたが、アップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）の場合には、そのストリームの代わりにリソースユニットで各端末を分離すると置き換えればよい。本実施形態でのＵＬ−ＭＵ−ＭＩＭＯ送信に関する記述を参照すれば、ＲＴＳフレームをある端末が送信し、それに対し、基地局がグループＩＤシグナリングＲＡのＣＴＳフレームを送信することで、そのグループＩＤと一致する複数の端末によるＵＬ−ＯＦＤＭＡ送信が可能となる。またＵＬ−ＯＦＤＭＡ送信後の送達確認応答フレームにもグループＩＤシグナリングＲＡを適用することで、ＵＬ−ＯＦＤＭＡ送信を行った複数の端末への送達確認応答を一つのフレームでまとめて行うことができる。このようなＵＬ−ＭＵ−ＭＩＭＯからＵＬ−ＯＦＤＭＡへの置き換えは後述の実施形態にも適用できる。

（第２の実施形態）
本実施形態では、基地局が、Ｉ／Ｇビットを１にし、所定の第２領域にグループＩＤを設定したＲＡフィールドを含むＣＴＳフレーム（グループＩＤシグナリングＲＡを設定したＣＴＳフレーム）を送信することで、当該グループ内の端末群に対し、ダウンリンクマルチマルチユーザＭＩＭＯ送信の予告（ダウンリンクマルチマルチユーザＭＩＭＯ送信の対象であることの通知）を行う。基地局は、ＣＴＳフレームの送信後、ＳＩＦＳ後に、当該グループ内の端末群に対しデータフレームをダウンリンクマルチマルチユーザＭＩＭＯ送信する。本実施形態では、ＣＴＳ−Ｔｏ−Ｓｅｌｆを流用し、基地局は、端末からのＲＴＳフレームをトリガとすることなく、ＣＴＳフレームを送信する。なお、通常のＣＴＳ−Ｔｏ−Ｓｅｌｆでは、基地局からＣＴＳフレームを送信する場合、ＲＡフィールドには、基地局のＭＡＣアドレス（Ｉ／Ｇビットは０）を設定するが、本実施形態では、ＣＴＳフレームのＲＡフィールドには、当該基地局のＭＡＣアドレスではなく、グループＩＤシグナリングＲＡ（Ｉ／Ｇビットが１、所定の第２領域がグループＩＤ）を設定する。

図１０は、図２に示した基地局１００および端末１０６〜１０８の動作シーケンスの例を示す。基地局１００は、端末１０６〜１０８へ送信するデータを有しており、これらのデータを端末１０６〜１０８へＤＬ−ＭＵ−ＭＩＭＯ送信する場合のシーケンスを示す。端末１０６〜１０８は、予め基地局１００によりＤＬ−ＭＵ−ＭＩＭＯ送信用にグループ化されており、基地局１００からグループＩＤを通知されているとする。

基地局１００が、データフレームを送信しようとして媒体を観測した結果、媒体がビジーであると検出し、例えばＤＩＦＳと、それに続くランダムに決定したバックオフ期間の間、キャリアセンスを行い、キャリアセンス結果がアイドルとして、アクセス権を獲得したとする。この場合、基地局１００は、ＢＳＳ内の端末群にＮＡＶを設定させるため、ＣＴＳフレーム８１を生成して送信する。ＣＴＳフレーム８１は、第１の実施形態で示した図４に示したＣＴＳフレームと同じフォーマットを有する。すなわち、ＲＡフィールドの所定の第１領域、具体的に、先頭ビット（Ｉ／Ｇビット）には１を、所定の第２領域（第３〜第８ビット）には端末１０６〜１０８が属するグループのグループＩＤを設定する。ＲＡフィールド内のその他の領域は、予約フィールドとする。あるいはＲＡフィールド内のその他の領域の一部または全てに、事前に定義したパターンを設定するようにしてもよい。また第１の実施形態と本実施形態の両方の用途としてグループＩＤシグナリングＲＡを用いたＣＴＳフレームを使う場合にその用途を区別するために、ＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示を行う第１の実施形態でのＣＴＳフレームに対し、ＵＬ−ＭＵ−ＭＩＭＯ送信の予告であることを示す本実施形態でのＣＴＳフレームであることをＲＡフィールド内の第１領域と第２領域を除くその他の領域の一部に示すようにしてもよい。この場合、当該情報は１ビットあれば例えばその値が０であればＵＬ−ＭＵ−ＭＩＭＯ送信の許可もしくは指示であり、１であればＵＬ−ＭＵ−ＭＩＭＯ送信の予告であることを示すことができ、十分と考えられる。なお、ＣＴＳフレームのため、ＴＡフィールドは存在しない。

このＣＴＳフレーム８１は、端末１０６〜１０８を含むＢＳＳ内の端末群に受信される。ＣＴＳフレーム８１を受信した端末は、ＣＴＳフレーム８１のフレームコントロールフィールドからフレーム種別（タイプ、サブタイプ）を確認し、制御およびＣＴＳであると把握する。そして、ＲＡフィールドの先頭ビット（Ｉ／Ｇビット）を確認し、このビットの値が１であることを把握する。Ｉ／Ｇビットが１であることから、ＲＡフィールドの値は、自端末のＭＡＣアドレスではないと判断し、Ｄｕｒａｔｉｏｎフィールドに設定されている値に従って、ＮＡＶを設定する。また、端末は、Ｉ／Ｇビットが１であることから、ＲＡフィールドの所定の第２領域（第３〜第８ビット）にグループＩＤが設定されていると判断し、当該所定の第２領域からグループＩＤを読み出す。端末１０６〜１０８は、読み出したグループＩＤを自端末が属するグループのグループＩＤと比較し、両者が一致することから、ＣＴＳフレーム８１の送信完了からＳＩＦＳ後に自端末へ、基地局１００からＤＬ−ＭＵ−ＭＩＭＯ送信されると判断し、受信待ちを行う。ただし、端末は隣接する別の基地局から、図４のフォーマットのＣＴＳフレームを受信する可能性があり、この場合ＣＴＳフレームにはＴＡフィールドが存在しないため自端末が接続している基地局からのＣＴＳフレームか自端末が接続していない別の基地局からのＣＴＳフレームかを上述の説明からだけでは区別できず、接続していない当該別の基地局からのＣＴＳフレームに対し、そのＳＩＦＳ後に自端末へＤＬ−ＭＵ−ＭＩＭＯ送信があると判断し、受信待ちを行ってしまう。そこで、隣接する基地局同士では、事前に互いに重複しないように、グループＩＤを各々のＢＳＳ内のグループに割り当てるようにしてもよい。この方法として、例えば、事前に各基地局に割り当てることができるグループＩＤの範囲を静的に設定してもよいし、あるいは、基地局同士で有線または無線で制御用の通信路を形成し、当該通信路を介してグループＩＤに関する情報を交換することで、それぞれ付与するグループＩＤが重複しないようにしてもよい。無線の場合には、例えば自ＢＳＳで使用している、または使用予定のグループＩＤをビーコンフレームやプローブ応答フレームで通知するようにし、他の基地局はこれらのフレームを受信すると通知されたグループＩＤ以外の値を当該他の基地局が構成するＢＳＳでのグループＩＤとして使用するようにする。当該他の基地局も同様に当該他の基地局が構成するＢＳＳで使用している、または使用予定のグループＩＤを通知するようにすれば、基地局同士でそれぞれが付与するグループＩＤが重複しないようにすることができる。あるいは前述の事前に定義したパターンをＣＴＳフレームに入れるようにし、当該パターンが自ＢＳＳと隣接ＢＳＳで重複しないようにすることで、端末でＣＴＳフレームを区別できるようにしてもよい。当該パターンを用いてＣＴＳフレームを区別するようにする場合にも、基地局同士でそれぞれが付与する当該パターンが重複しないようにする方法としては、上記グループＩＤでの重複を防止する方法を参照すればよい。あるいは、物理パケットのヘッダにＢＳＳＩＤ（インフラストラクチャＢＳＳでは当該ＢＳＳを形成する基地局のＭＡＣアドレスと等価）の一部情報、例えば最後の９ビットを加工して入れるようにし、端末は受信時に物理パケットのヘッダ部分の当該ＢＳＳＩＤ関連情報が自ＢＳＳと一致するか否かでＣＴＳフレームを区別するようにしてもよいし、またさらに当該ＢＳＳＩＤ関連情報とグループＩＤシグナリングＲＡのＣＴＳフレーム中のパターンの組み合わせでＣＴＳフレームを区別するようにしてもよい。

なお、上述したように、通常、端末からのＲＴＳフレームを受信することなく、基地局からＣＴＳフレームを送信する場合（ＣＴＳ−Ｔｏ−Ｓｅｌｆの場合）、ＲＡフィールドには、基地局１００のＭＡＣアドレス（Ｉ／Ｇビットは０）が設定される。しかしながら、本実施形態では、基地局１００のＭＡＣアドレスではなく、Ｉ／Ｇビットを１とし、所定の第２領域をグループＩＤとしたものをＲＡアドレスとして格納することを特徴とする。

基地局１００は、ＣＴＳフレーム８１の送信完了からＳＩＦＳ経過後、ＣＴＳフレーム８１で指定したグループ内の端末１０６〜１０８に、それぞれ宛のデータフレームを、ＤＬ−ＭＵ−ＭＩＭＯ送信する（これらのデータフレームをまとめて８２としている）。この際、ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃの規格に合わせて、各端末に送信する物理パケットのヘッダ（ＶＨＴ−ＳＩＧ−Ａフィールド）に、グループＩＤを入れてもよい。端末１０６〜１０８は、基地局１００からＤＬ−ＭＵ−ＭＩＭＯ送信される信号を受信待ちし、受信した信号をＭＩＭＯ復調することで、自端末宛のデータフレームを抽出する。なお、各端末は、物理パケットのヘッダに含まれるグループＩＤが、自端末が属するグループのグループＩＤに一致するときのみ、データフレームの復号を行うようにしてもよい。各端末は、データフレームのＦＣＳ情報に基づき受信成功の可否を判定し、成功可否の判定結果（ＡＣＫ情報）を示す送達確認応答フレーム８３、８４、８５を生成する。端末１０６〜１０８は、基地局１００からのＭＩＭＯ信号の受信完了後、ＳＩＦＳ経過後に、基地局１００に送達確認応答フレーム８３〜８５をＵＬ−ＭＵ−ＭＩＭＯで送信する。なお、送達確認応答フレーム８３〜８５のフォーマットは、通常のＡＣＫフレームでも、ＢＡフレームでもよい。ここでは、送達確認応答フレーム８３〜８５をＵＬ−ＭＵ−ＭＩＭＯ送信したが、図１１に示すように、端末１０６〜１０８が、送達確認応答フレーム８３ａ、８４ａ、８５ａをＳＩＦＳ間隔ずつあけて順番に送信してもよい。送達確認応答フレームを出力する順序は、グループ毎に事前に基地局１００から各グループ内の端末に、管理フレームを介して通知しておけばよい。あるいはＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３を参照し、端末１０６宛てのデータフレームではＡ−ＭＰＤＵ構成を用いて送達確認応答要求（ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔ；ＢＡＲ）フレームを入れずに端末１０６に送達確認応答フレーム送信を促すようにし（この手法をｉｍｐｌｉｃｉｔ ＢＡＲと呼ぶ）、端末１０７および端末１０８宛てのデータフレームではｉｍｐｌｉｃｉｔ ＢＡＲはせず、その結果、データフレーム８２送信完了からＳＩＦＳ後に端末１０６から送達確認応答フレームを受信し、端末１０６からの送達確認応答フレームの受信完了からＳＩＦＳ後に端末１０７に送達確認応答要求フレームを送信して（この手法をｅｘｐｌｉｃｉｔ ＢＡＲと呼ぶ）、その結果、端末１０７宛て送達確認応答要求フレームの送信完了からＳＩＦＳ後に端末１０７から送達確認応答フレームを受信し、端末１０７からの送達確認応答フレームの受信完了からＳＩＦＳ後に端末１０８に送達確認応答要求フレームを送信して、その結果、端末１０８宛て送達確認応答要求フレームの送信完了からＳＩＦＳ後に端末１０８から送達確認応答フレームを受信するようにしてもよい。

以上、本実施形態によれば、基地局が、グループＩＤシグナリングＲＡを設定したＣＴＳフレームを送信することで、ＣＴＳフレームを利用して、ダウンリンクマルチマルチユーザＭＩＭＯ送信の対象であることを、当該グループＩＤのグループ内の端末群に通知することができる。

（第３の実施形態）
第１の実施形態では、ＲＴＳフレームの受信を、基地局によるアップリンクマルチマルチユーザＭＩＭＯ送信の許可または指定の通知を行うＣＴＳフレームの送信のトリガとしたが、本実施形態では、基地局は、端末からＲＴＳフレームを受信することなく、ＣＴＳフレームを送信する。ＲＴＳフレームの送信が不要なため、高速にＵＬ−ＭＵ−ＭＩＭＯ送信を開始できる。

図１２は、図２に示した基地局１００および端末１０１〜１０３の動作シーケンスの例を示す。端末１０１〜１０３は、基地局１００へ送信するデータを有しており、これらのデータを基地局１００へＵＬ−ＭＵ−ＭＩＭＯ送信する場合のシーケンスを示す。端末１０１〜１０３は、予め基地局１００によりＵＬ−ＭＵ−ＭＩＭＯ送信用に同じグループにグループ化され、グループＩＤを通知されているとする。

基地局１００が、データフレームを送信しようとして媒体を観測した結果、媒体がビジーであると検出し、例えばＤＩＦＳと、それに続くランダムに決定したバックオフ期間の間、キャリアセンスを行い、キャリアセンス結果がアイドルとして、アクセス権を獲得したとする。このとき、基地局１００は、第１の実施形態で示した図４に示したものと同じフォーマットを有するＣＴＳフレーム９１を生成して送信する。すなわち、ＣＴＳフレーム９１のＲＡフィールドの先頭ビット（Ｉ／Ｇビット）は１であり、ＲＡフィールド内の所定の第２領域（第３〜第８ビット）には、端末１０１〜１０３が属するグループのグループＩＤを設定する。ＲＡフィールド内のその他の領域は、予約フィールドであるとする。あるいはＲＡフィールド内のその他の領域の一部または全てに、事前に定義したパターンを設定するようにしてもよい。なお、ＣＴＳフレームであるため、ＴＡフィールドは存在しない。

このＣＴＳフレーム９１は、端末１０１〜１０３を含むＢＳＳ内の端末群に受信される。ＣＴＳフレーム９１を受信した端末は、ＣＴＳフレーム９１のフレームコントロールフィールドからフレーム種別（タイプ、サブタイプ）を確認し、制御およびＣＴＳであると把握する。そして、ＲＡフィールドの先頭ビット（Ｉ／Ｇビット）を確認し、端末はこのビットの値が１であることを把握する。端末は、Ｉ／Ｇビットが１であることから、ＲＡフィールドの所定の第２領域にグループＩＤが設定されていると判断し、当該所定の第２領域からグループＩＤを読み出す。端末は、読み出したグループＩＤを自端末が属するグループのグループＩＤと比較する。端末１０１〜１０３以外の端末は、両者が一致しないため、自端末はＵＬ−ＭＵ−ＭＩＭＯ送信の対象として指定されていないと判断する。一方、端末１０１〜１０３では、両者が一致するため、ＵＬ−ＭＵ−ＭＩＭＯ送信の対象として指定されたと判断する。端末１０１〜１０３は、ＣＴＳフレーム９１の受信完了からＳＩＦＳ後に、データフレーム９２、９３、９４を基地局１００にＵＬ−ＭＵ−ＭＩＭＯ送信する。なお、データフレーム９２、９３、９４のＴＡは、端末１０１〜１０３のＭＡＣアドレス（Ｉ／Ｇビットは０である）、ＲＡは、基地局１００のＭＡＣアドレス（Ｉ／Ｇビットは０）である。この動作では、端末１０１〜１０３は、ＣＴＳフレーム９１を受信した場合、自端末が接続している基地局から当該ＣＴＳフレーム９１が受信されたものとみなす。これにより、ＣＴＳフレーム９１にＴＡフィールドが存在しなくても、データフレームの送信先を当該基地局と判断できるため、ＵＬ−ＭＵ−ＭＩＭＯ送信を実現できる。ただし、端末は隣接する別の基地局から、図４のフォーマットのＣＴＳフレームを受信する可能性があり、この場合ＣＴＳフレームにはＴＡフィールドが存在しないため自端末が接続している基地局からのＣＴＳフレームか自端末が接続していない別の基地局からのＣＴＳフレームかを上述の説明からだけでは区別できず、接続していない当該別の基地局へデータフレームを送信してしまう。そこで、隣接する基地局同士では、事前に互いに重複しないように、グループＩＤを各々のＢＳＳ内のグループに割り当てるようにしてもよい。この方法として、例えば、事前に各基地局に割り当てることができるグループＩＤの範囲を静的に設定してもよいし、あるいは、基地局同士で有線または無線で制御用の通信路を形成し、当該通信路を介してグループＩＤに関する情報を交換することで、それぞれ付与するグループＩＤが重複しないようにしてもよい。無線の場合には、例えば自ＢＳＳで使用している、または使用予定のグループＩＤをビーコンフレームやプローブ応答フレームで通知するようにし、他の基地局はこれらのフレームを受信すると通知されたグループＩＤ以外の値を当該他の基地局が構成するＢＳＳでのグループＩＤとして使用するようにする。当該他の基地局も同様に当該他の基地局が構成するＢＳＳで使用している、または使用予定のグループＩＤを通知するようにすれば、基地局同士でそれぞれが付与するグループＩＤが重複しないようにすることができる。あるいは前述の事前に定義したパターンをＣＴＳフレームに入れるようにし、当該パターンが自ＢＳＳと隣接ＢＳＳで重複しないようにすることで、端末でＣＴＳフレームを区別できるようにしてもよい。当該パターンを用いてＣＴＳフレームを区別するようにする場合にも、基地局同士でそれぞれが付与する当該パターンが重複しないようにする方法としては、上記グループＩＤでの重複を防止する方法を参照すればよい。あるいは、物理パケットのヘッダにＢＳＳＩＤ（インフラストラクチャＢＳＳでは当該ＢＳＳを形成する基地局のＭＡＣアドレスと等価）の一部情報、例えば最後の９ビットを加工して入れるようにし、端末は受信時に物理パケットのヘッダ部分の当該ＢＳＳＩＤ関連情報が自ＢＳＳと一致するか否かでＣＴＳフレームを区別するようにしてもよいし、またさらに当該ＢＳＳＩＤ関連情報とグループＩＤシグナリングＲＡのＣＴＳフレーム中のパターンの組み合わせでＣＴＳフレームを区別するようにしてもよい。

以降のシーケンスは、第１の実施形態の図３と同様である。すなわち、基地局１００は、端末１０１〜１０３からＵＬ−ＭＵ−ＭＩＭＯ送信されたデータフレームの信号を、ＭＩＭＯ復調してストリームごとに分離し、各端末のデータフレームを取得する。各端末から送信されるデータフレームのＴＡは、各端末のＭＡＣアドレス（個別／グループフィールドは０）であり、ＲＡは、基地局１０１のＭＡＣアドレス（個別／グループフィールドは０）である。基地局１００は、各端末のデータフレームの受信に成功したかをデータフレームのＦＣＳフィールド内のＦＣＳ情報に基づき判断する。基地局１００は、各端末のデータフレームの受信の成功可否情報（ＡＣＫ情報）を格納した送達確認応答フレーム９５を生成し、送達確認応答フレーム９５を、ＵＬ−ＭＵ−ＭＩＭＯ送信信号の受信完了から、ＳＩＦＳ経過後に送信する。この送達確認応答フレーム９５でも、ＲＡフィールドにグループＩＤを入れる手法を利用できる。その詳細な説明は、第１の実施形態の説明で述べた通りであるため省略する。

以上、本実施形態によれば、基地局から、Ｉ／Ｇビットを１にし、かつグループＩＤを設定したＲＡフィールドを有するＣＴＳフレームを、端末からのＲＴＳフレームの受信をトリガとすることなく、送信する。よって、第１の実施形態の効果に加え、ＲＴＳフレームの送信が不要な分、高速にＵＬ−ＭＵ−ＭＩＭＯ送信を開始できる。

以下、上述した各実施形態に基づく変形例を説明する。これまではＲＡフィールドのＩ／Ｇビットを１にし、ＲＡフィールド内の所定の第２領域にグループＩＤを設定したが、以下の各変形例では、グループＩＤを設定しない形態を示す。各変形例に示す形態または技術的思想は、上述した各実施形態に適用することが可能である。
（第１の変形例）
第１の実施形態では、ＲＴＳフレームに対する応答として、Ｉ／Ｇビットを１にし、所定の第２領域にグループＩＤを設定したＲＡフィールドを含むＣＴＳフレームを送信することで、当該グループ内の端末群に対し、アップリンク多重送信（ＵＬ−ＭＵ−ＭＩＭＯ送信またはＵＬ−ＯＦＤＭＡ送信）の許可もしくは指示を行った。この場合、アップリンク多重送信を行うのはＣＴＳフレームで指定されたグループＩＤのグループに属する端末に限定されるが、当該グループに属する端末に限定しない方法も可能である。

具体的に、基地局は、ＲＴＳフレームに対する応答として、ＲＡフィールドのＩ／Ｇビットを１にしたＣＴＳフレームを送信する。ＲＡフィールドのうちＩ／Ｇビット以外の領域は、任意の値にしてもよいし、予め定めた値（ビットパターン）を設定してもよい。これにより、基地局は、任意の端末に対してアップリンク多重送信を指示する。ＲＴＳフレームを送信した端末、および当該ＲＴＳフレームを受信した他の端末（基地局を除く）は、基地局から送信されるＣＴＳフレームを受信した場合、Ｉ／Ｇビットが１になっていることから、第１の実施形態で説明した理由により、アップリンク多重送信を許可または指示していると判断できる。

端末は、アップリンク送信したいデータを有するか否か等の理由に応じて、アップリンク送信を行うか否かを自由に決定する。端末は、アップリンク送信を行うことを決定した場合、ＵＬ−ＯＦＤＭＡの場合は、複数のリソースユニットから事前に定めた方法でリソースユニットを選択し、選択したリソースユニットで、ＣＴＳフレームの受信完了からＳＩＦＳ等の事前に定めた時間の経過後に、データフレームをアップリンク送信する。ＵＬ−ＭＵ−ＭＩＭＯの場合は、複数の空間リソース（空間、時間または周波数的に互いに直交関係にある複数のプリアンブル）から事前に定めた方法で空間リソースを選択し、選択した空間リソースでＣＴＳフレームの受信完了からＳＩＦＳ等の事前に定めた時間の経過後に、データフレームをアップリンク送信すればよい。

空間リソースについて説明する。ＵＬ−ＭＵ−ＭＩＭＯの場合、基地局は事前に複数の端末から取得したアップリンクの伝搬路応答を用いて受信を行う方法以外に、複数の端末からそれぞれ送信するフレームに互いに直交するプリアンブルをフレームの先頭側（物理ヘッダ内）に付与することで、基地局は当該プリアンブルを利用して端末毎のアップリンクの伝搬路応答を把握し、把握した伝搬路応答に基づきプリアンブルより後の部分を復号することも可能である。端末間のプリアンブルの直交化の方法として、時間的、周波数的、符号的のいずれの方法を用いてもよい。時間直交の場合には、プリアンブルフィールドが複数の区間に分割され、各端末が互いに異なる区間でプリアンブルデータを送信する。ある区間には、いずれか１台数端末のみがプリアンブルデータを送信していることになる。つまり端末間でプリアンブルデータを送信する時間的な位置が異なっている。ある端末がプリアンブルデータを送信する間、他の端末は何も送信しない期間になる。時間直交の場合、プリアンブルは、送信するプリアンブルデータのみならず、どの時間で送信するかに関する情報も含んでいる。周波数直交の場合には、各端末が互いに直交関係にある周波数でプリアンブルデータを送信する。周波数直交の場合、プリアンブルは、送信するプリアンブルデータのみならず、どの周波数（サブキャリア）で送信するかに関する情報も含んでいる。符号直交の場合には、各端末がそれぞれ直交行列の互いに異なる行（または互いに異なる列）に含まれる複数の値（複数の値のそれぞれに対応するシンボル）を配置したプリアンブルデータを送信する。直交行列の各行（または各列）は互いに直交の関係にある。いずれの直交化の方法でも、アクセスポイント１１では各端末のプリアンブルの識別が可能となる。

同じリソース（リソースユニットまたは空間リソース）を複数の端末が選択した場合、基地局ではこれらの端末から送信されたデータフレームの復号に失敗するが、端末の選択が重複しなかったリソースについては、基地局は正常にこれらのリソースで送信されたデータフレームを復号することで、アップリンク多重送信（ＵＬ−ＭＵ−ＭＩＭＯ送信またはＵＬ−ＯＦＤＭＡ送信）が実現される。なお、アップリンク多重送信がＵＬ−ＭＵ−ＭＩＭＯかＵＬ−ＯＦＤＭＡのどちらの方式かは、事前に定めておいてもよいし、ＣＴＳフレームのＲＡフィールドにどちらかの方式かを指定する領域を設け、当該領域に方式を指定する情報を基地局が設定してもよい。

別の動作例として、ＲＴＳフレームに対してＣＴＳフレームではなく、アップリンク多重送信用のトリガーフレームを基地局が送信する構成も可能である。この場合、トリガーフレームのＲＡフィールドのＩ／Ｇビットを１に設定する。ＲＴＳフレームを送信した端末、および当該ＲＴＳフレームを受信した他の端末（基地局を除く）は、基地局から送信されるフレームを受信した場合、Ｉ／Ｇビットが１になっていることから、受信したフレームが、トリガーフレームであると判断する。Ｉ／Ｇビットを１にすることでトリガーフレームであることを通知しているため、Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプおよびサブタイプの値は既存のものを流用してもよい。トリガーフレームは任意のフォーマットで構成すればよい。トリガーフレームに、使用可能な複数のリソースを特定する情報を設定するフィールドを設け、トリガーフレームを受信し、かつアップリンク送信を行うことを決定した端末は、当該フィールドで指定された複数のリソースの中から使用するリソースを選択してもよい。ＣＴＳフレームの場合と同様に、ＵＬ−ＭＵ−ＭＩＭＯかＵＬ−ＯＦＤＭＡのどちらかの方式かを指定する領域をトリガーフレームに設け、当該領域に方式を指定する情報を基地局が設定してもよい（このことは以下で説明する他の変形例および実施形態についても同様に適用される）。またトリガーフレームにアップリンク多重送信を許可または指示する複数の端末を指定する情報を含め、当該情報で指定される端末のみがアップリンク送信可能でもよい。

（第２の変形例）
第１の変形例で複数の端末からアップリンク多重送信した複数のデータフレームに対する送達確認応答として、図５（Ａ）〜図５（Ｃ）で説明したＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋを用いてもよい。ただし、このときＲＡフィールドのＩ／Ｇビットを１にするものとし、ＲＡフィールド内の他の領域は、任意の値、または予め定めた値（ビットパターン）を設定してもよい。ただし、ＲＡフィールドのビット列がブロードキャストアドレスまたはマルチキャストアドレスに一致しないものとする。または、当該他の領域には、アップリンク多重送信を行った端末のうちの１台の端末を選択し、選択した端末のアドレスのＩ／Ｇビット以外のアドレス部分を設定してもよい。選択する端末は、ランダムに選択してもよいし、事前に基地局とＲＴＳフレームおよびＣＴＳフレームの交換を行った端末がアップリンク送信を行っている場合は、当該端末を選択してもよい。

アップリンク送信を行った端末は、ＲＡフィールドのＩ／Ｇビットが１であり、かつＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプおよびサブタイプが制御（Ｃｏｎｔｒｏｌ）およびＢｌｏｃｋＡｃｋであるフレームを受信した場合は、当該フレームをＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋであると認識する。上述した他の領域に予め定めたビットパターンまたは端末のアドレス部分を設定する場合は、当該ビットパターンまたはアドレス部分が設定されていることを条件としてもよい。アドレス部分が設定されていることを条件とする場合は、アップリンク送信を行った端末は、ＲＴＳフレームを送信した端末等のアドレスを、当該ＲＴＳフレームの受信時に記憶しておくものとする。

本変形例で述べたＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋの構成を、第１の実施形態で用いてもよい。すなわち、第１の実施形態ではＲＡフィールドの所定の第２領域にグループＩＤを設定したが、グループＩＤを設定せずに、本変形例と同様のＲＡフィールドのフォーマットを用いてもよい。

（第３の変形例）
第１の変形例では、ＣＴＳフレームの受信をトリガとして、複数の端末が、送信したいデータを含むデータフレームをアップリンク多重送信（ＵＬ−ＭＵ−ＭＩＭＯ送信またはＵＬ−ＯＦＤＭＡ送信）を行ったが、データを送信するのではなく、アップリンク多重送信の要求（すなわち送信したいデータを保有している旨の通知）を、送信するようにしてもよい。すなわち、図１３に示すように、基地局は、アップリンク送信の要求を持っている端末を知るために、ＲＴＳフレーム７１に対する応答として、ＲＡフィールドのＩ／Ｇビットを１に設定したＣＴＳフレーム４００を送信する。ＲＴＳフレーム７１を送信した端末、および当該ＲＴＳフレームを受信した他の端末（ここでは少なくとも端末１０２、１０３を含む）は、基地局から送信されるＣＴＳフレーム４００を受信した場合、Ｉ／Ｇビットが１になっていることを確認し、アップリンク送信の要求を持っている場合は、事前に定義された要求通知用のフレーム（要求フレーム）４０１〜４０３を送信する。当該フレームは、Ｎｕｌｌ Ｄａｔａ Ｐａｃｋｅｔ（ＮＤＰ）でもよい。このときのフレーム送信は、ＵＬ−ＭＵ−ＭＩＭＯ送信またはＵＬ−ＯＦＤＭＡ送信（第１の変形例と同様の方法で送信）でもよい。あるいは、ＣＳＭＡ／ＣＡベースで、ユニキャストでフレームを送信してもよい。ＣＳＭＡ／ＣＡベースの場合、アップリンク送信の要求を受け付けるための時間の制限を設け、当該時間の間のみ受け付けても良いし、一定数の端末から要求を受け付けた時点で、受け付けを終了してもよい。端末１０２は、ＲＴＳフレーム７１を送信しているため、要求フレーム４０２を送信しなくてもよい。基地局は、端末１０２から要求フレーム４０２を受信しなくても、端末１０２はアップリンク送信の要求を有していると解釈すればよい。端末１０２は、ＣＴＳフレーム４００のＲＡフィールドのＩ／Ｇビットが１になっていることで、自端末のアップリンク送信の要求が基地局に届いたと解釈することができる。ＣＴＳフレーム４００のＲＡフィールドのＩ／Ｇビット以外の領域に、要求フレームの送信で使用可能なリソース（リソースユニットまたは空間リソース）の情報を設定してもよい。端末１０１〜１０３は、当該情報で指定されたリソースの中から、ランダム選択等、所定の方法で選択したリソースで、要求フレームを送信してもよい。

基地局は、アップリンク送信の要求を通知した端末の中からアップリンク多重送信を行う端末を選定し、選定した端末にトリガーフレーム４０４を送信してもよい。トリガーフレーム４０４のフォーマットは任意に定めればよい。Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプおよびサブタイプの値を、トリガーフレームに対して新たに定義してもよい。ＲＡフィールドにはブロードキャストアドレスまたはマルチキャストアドレスを設定してもよいし、ＲＡフィールドを設けないフォーマットも可能である。トリガーフレームに、選定した端末毎に、アップリンク送信で使用するリソースを特定する情報を設定するフィールドを設け、各端末は当該フィールドで指定されたリソースを用いてもよい。トリガーフレームは要求フレームの受信からＳＩＦＳ等の一定時間後に送信してもよいし、ＣＳＭＡ／ＣＡベースでアクセス権を獲得して、トリガーフレーム４０４を送信してもよい。トリガーフレーム４０４を受信しかつ選定された端末（ここでは端末１０１〜１０２）は、トリガーフレーム４０４の受信完了からＳＩＦＳ等の予め定めた時間後にデータフレーム４０５、４０６を、アップリンク多重送信（ＵＬ−ＭＵ−ＭＩＭＯ送信またはＵＬ−ＯＦＤＭＡ送信）する。この後、基地局は、第２の変形例と同様にして送達確認応答フレームを送信してもよい。

本変形例では端末１０２が送信したＲＴＳフレーム７１に対して、基地局はＣＴＳフレーム４００を送信したが、送信するフレームは、ＣＴＳフレームに限定されない。例えばトレーガーフレームを送信してもよい。この場合、ＲＴＳフレーム７１を受信し、かつトリガーフレームを受信した端末は、アップリンク送信の要求を有する場合は、要求フレームを送信する。

（第４の変形例）
第２の実施形態では、基地局は、ＤＬ−ＭＵ−ＭＩＭＯ送信を行う場合に事前にダウンリンクの伝搬路応答を取得していることを想定していたが、当該ダウンリンクの伝搬路応答を複数の端末から取得するために、複数の端末がＵＬ−ＯＦＤＭＡまたはＵＬ−ＭＵ−ＭＩＭＯでダウンリンクの伝搬路応答を基地局に送信してもよい。基地局が、複数の端末からダウンリンクの伝搬路応答を取得するため、図１４に示すように、サウンディング用のフレーム４１１を送信する。当該フレームとして、Ｎｕｌｌ Ｄａｔａ Ｐａｃｋｅｔ（ＮＤＰ）を用いてもよい。ＮＤＰはデータフィールドを有さない物理パケットである（つまりＭＡＣヘッダも含まない）。基地局が複数のアンテナを有する場合、複数のアンテナから同時にＮＤＰの信号を送信してもよい。ＮＤＰの送信前に、任意の端末からＲＴＳフレームなど、ＮＤＰの送信のトリガとなるフレーム（第１の変形例のＲＴＳフレームに相当）を受信し、当該受信に対する応答としてＮＤＰを送信してもよい。当該フレームを送信した端末および当該フレームを受信した端末は、当該フレームに対する応答としてＮＤＰを受信したことで、伝搬路応答を取得してフィードバックすることを判断してもよい。

このＮＤＰを受信した複数の端末１０１〜１０３は、ＮＤＰに基づき伝搬路を推定してダウンリンクの伝搬路応答を取得し、取得した伝搬路応答を含むフレーム４１１〜４１３を、ＮＤＰの受信完了からＳＩＦＳ等の予め定めた時間後に、アップリンク多重送信（ＵＬ−ＯＦＤＭＡまたはＵＬ−ＭＵ−ＭＩＭＯ）する。アップリンク多重送信の方法は第１の変形例と同様で良い。フレームの種類は管理フレームでも、データフレームでもよい。なお、一例として、当該フレームの送信元アドレスは自端末、受信先アドレスは基地局である。伝搬路応答を返す複数の端末は、事前に何らかの方法でダウンリンク送信があることを基地局から通知されていた端末でもよいし、ＮＤＰを受信した全端末でもよい。あるいは、自端末が伝搬路応答を返すかをランダムに決定してもよい。なお、２台以上の端末が同じリソースで送信した場合は、基地局はこれらの端末からのフレームを正常に復号できないことになる。

基地局は、複数の端末からアップリンク多重送信されたフレームを受信して、正常に復号できた端末についてはダウンリンクの伝搬路応答を取得する。基地局は、復号に成功したフレームを送信した端末を特定し、特定した端末に対するＡＣＫをまとめて含む送達確認応答フレーム４１４を生成して、送信する。このとき、送達確認応答フレーム４１４として、前述したＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋを利用する。ＲＡフィールドにおけるＩ／Ｇビットを１にし、それ以外の領域は、任意の値にしてもよいし、予め定めた値（ビットパターン）を設定してもよい。サウンディング用のフレーム４１１の送信のトリガとなるフレーム（第１の変形例のＲＴＳフレームに相当）を送信した端末が存在する場合に、当該端末のアドレスのＩ／Ｇビット以外のアドレス部分を設定してもよい。

第１の実施形態の説明で述べたように、Ｍｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋを利用して、複数の端末にＢＡではなくＡＣＫを返す場合は、各ＢＡ情報フィールドのＴＩＤ Ｉｎｆｏサブフィールドにおける１つのビット（例えば先頭から１２ビット目（先頭をＢ０とすれば、Ｂ１１））をＡＣＫかＢＡかを示すビット（ＡＣＫ／ＢＡビット）として用い、当該ビットにＡＣＫを示す値を設定すればよい。この場合、Ｂｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐサブフィールドは省略してよい。これにより、１つのフレームで複数の端末のＡＣＫを通知できる。

アップリンク多重送信した複数の端末は、送達確認応答フレーム４１４を受信し、Ｉ／Ｇビットが１であることから当該フレームはＭｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋであると判断し、自端末のＡＩＤが格納されているＴＩＤ Ｉｎｆｏサブフィールドが存在するかで、送信が成功したか否かを判断する。Ｉ／Ｇビットを１にすることで、既存のＢＡフレームを流用して（つまりフレームタイプおよびサブタイプを新たに定義したり、新たなフレームフォーマットを定義することなく）、Ｍｕｌｔｉ−Ｓｔａｔｉｏｎ Ｂｌｏｃｋ Ａｃｋを実現できる。上述した他の領域に予め定めたビットパターンまたは端末のアドレス部分を設定する場合は、当該ビットパターンまたはアドレス部分が設定されていることを条件としてもよい。

上述した例では、基地局は、サウンディング用のフレームを送信し、複数の端末からダウンリンクの伝搬路応答をアップリンク多重で取得したが、別の情報をアップリンク多重で取得し、それに対するＡＣＫをまとめて含む送達確認応答フレームを送信してもよい。例えば基地局が、複数の端末がＵＬ−ＯＦＤＭＡで使用することを希望するリソースユニットの情報を把握したい場合に、当該情報の送信を要求するフレームを送信し、当該フレームを受信した複数の端末が、当該情報を含むフレームをアップリンク多重送信（ＵＬ−ＯＦＤＭＡまたはＵＬ−ＭＵ−ＭＩＭＯ）してもよい。このときのアップリンク多重送信でＵＬ−ＯＦＤＭＡを用いる場合は、任意のリソースユニットを用いるか、事前に指定されている場合はその指定されたリソースユニットを用いてもよい。基地局は、複数の端末からアップリンク多重送信されたフレームを受信して、正常に復号できた端末については上記情報を取得する。基地局は、上述と同様に、復号に成功したフレームを送信した端末を特定し、特定した端末に対するＡＣＫをまとめて含む送達確認応答フレームを生成して、送信する。この後、基地局は、これまで述べてきたＣＴＳフレームまたはトリガーフレームを送信して、ＵＬ−ＯＦＤＭＡを開始する場合に、上記取得した情報に基づき、ＵＬ−ＯＦＤＭＡで各端末が使用するリソースユニットを指定してもよい。

（第４の実施形態）
図１５は、端末（基地局を含む）の全体構成例を示したものである。この構成例は一例であり、本実施形態はこれに限定されるものではない。端末は、１つまたは複数のアンテナ１〜ｎ（ｎは１以上の整数）と、無線ＬＡＮモジュール１４８と、ホストシステム１４９を備える。無線ＬＡＮモジュール１４８は、第１〜第３のいずれかの実施形態に係る無線通信装置に対応する。無線ＬＡＮモジュール１４８は、ホスト・インターフェースを備え、ホスト・インターフェースで、ホストシステム１４９と接続される。接続ケーブルを介してホストシステム１４９と接続される他、ホストシステム１４９と直接接続されてもよい。また、無線ＬＡＮモジュール１４８が基板にはんだ等で実装され、基板の配線を介してホストシステム１４９と接続される構成も可能である。ホストシステム１４９は、任意の通信プロトコルに従って、無線ＬＡＮモジュール１４８およびアンテナ１〜ｎを用いて、外部の装置と通信を行う。通信プロトコルは、ＴＣＰ／ＩＰと、それより上位の層のプロトコルとを含んでもよい。または、ＴＣＰ／ＩＰは無線ＬＡＮモジュール１４８に搭載し、ホストシステム１４９は、それより上位層のプロトコルのみを実行してもよい。この場合、ホストシステム１４９の構成を簡単化できる。本端末は、例えば、移動体端末、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等でもよい。

図１６は、無線ＬＡＮモジュールのハードウェア構成例を示す。この構成は、無線通信装置が非基地局の端末および基地局のいずれに搭載される場合にも適用可能である。つまり、図１に示した無線通信装置の具体的な構成の一例として適用できる。この構成例では、アンテナは１本のみであるが、２本以上のアンテナを備えていてもよい。この場合、各アンテナに対応して、送信系統（２１６、２２２〜２２５）、受信系統（２３２〜２３５）、ＰＬＬ２４２、水晶発振器２４３およびスイッチ２４５のセットが複数配置され、各セットがそれぞれ制御回路２１２に接続されてもよい。

無線ＬＡＮモジュール（無線通信装置）は、ベースバンドＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）２１１と、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ＩＣ２２１と、バラン２２５と、スイッチ２４５と、アンテナ２４７とを備える。

ベースバンドＩＣ２１１は、ベースバンド回路（制御回路）２１２、メモリ２１３、ホスト・インターフェース２１４、ＣＰＵ２１５、ＤＡＣ（Ｄｉｇｉｔａｌ ｔｏ Ａｎａｌｏｇ Ｃｏｎｖｅｔｅｒ）２１６、およびＡＤＣ（Ａｎａｌｏｇ ｔｏ Ｄｉｇｉｔａｌ Ｃｏｎｖｅｒｔｅｒ）２１７を備える。

ベースバンドＩＣ２１１とＲＦ ＩＣ２２１は同じ基板上に形成されてもよい。また、ベースバンドＩＣ２１１とＲＦ ＩＣ２２１は１チップで構成されてもよい。ＤＡＣ２１６およびＡＤＣ２１７の両方またはいずれか一方が、ＲＦ ＩＣ２２１に配置されてもよいし、別のＩＣに配置されてもよい。またメモリ２１３およびＣＰＵ２１５の両方またはいずれか一方が、ベースバンドＩＣとは別のＩＣに配置されてもよい。

メモリ２１３は、ホストシステムとの間で受け渡しするデータを格納する。またメモリ２１３は、端末または基地局に通知する情報、または端末または基地局から通知された情報、またはこれらの両方を格納する。また、メモリ２１３は、ＣＰＵ２１５の実行に必要なプログラムを記憶し、ＣＰＵ２１５がプログラムを実行する際の作業領域として利用されてもよい。メモリ２１３はＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。

ホスト・インターフェース２１４は、ホストシステムと接続するためのインターフェースである。インターフェースは、ＵＡＲＴ、ＳＰＩ、ＳＤＩＯ、ＵＳＢ、ＰＣＩ Ｅｘｐｒｅｓｓなど何でも良い。

ＣＰＵ２１５は、プログラムを実行することによりベースバンド回路２１２を制御するプロセッサである。ベースバンド回路２１２は、主にＭＡＣ層の処理および物理層の処理を行う。ベースバンド回路２１２、ＣＰＵ２１５またはこれらの両方は、通信を制御する通信制御装置、または通信を制御する制御部に対応する。

ベースバンド回路２１２およびＣＰＵ２１５の少なくとも一方は、クロックを生成するクロック生成部を含み、当該クロック生成部で生成するクロックにより、内部時間を管理してもよい。

ベースバンド回路２１２は、送信するフレームに、物理層の処理として、物理ヘッダの付加、符号化、暗号化、変調処理（ＭＩＭＯ変調を含んでもよい）など行い、例えば２種類のデジタルベースバンド信号（以下、デジタルＩ信号とデジタルＱ信号）を生成する。

ＤＡＣ２１６は、ベースバンド回路２１２から入力される信号をＤＡ変換する。より詳細には、ＤＡＣ２１６はデジタルＩ信号をアナログのＩ信号に変換し、デジタルＱ信号をアナログのＱ信号に変換する。なお、直交変調せずに一系統の信号のままで送信する場合もありうる。複数のアンテナを備え、一系統または複数系統の送信信号をアンテナの数だけ振り分けて送信する場合には、アンテナの数に応じた数のＤＡＣ等を設けてもよい。

ＲＦ ＩＣ２２１は、一例としてＲＦアナログＩＣあるいは高周波ＩＣ、あるいはこれらの両方である。ＲＦ ＩＣ２２１は、フィルタ２２２、ミキサ２２３、プリアンプ（ＰＡ）２２４、ＰＬＬ（Ｐｈａｓｅ Ｌｏｃｋｅｄ Ｌｏｏｐ：位相同期回路）２４２、低雑音増幅器（ＬＮＡ）、バラン２３５、ミキサ２３３、およびフィルタ２３２を備える。これらの要素のいくつかが、ベースバンドＩＣ２１１または別のＩＣ上に配置されてもよい。フィルタ２２２、２３２は、帯域通過フィルタでも、低域通過フィルタでもよい。

フィルタ２２２は、ＤＡＣ２１６から入力されるアナログＩ信号およびアナログＱ信号のそれぞれから所望帯域の信号を抽出する。ＰＬＬ２４２は、水晶発振器２４３から入力される発振信号を用い、発振信号を分周または逓倍またはこれらの両方を行うことで、入力信号の位相に同期した、一定周波数の信号を生成する。なお、ＰＬＬ２４２は、ＶＣＯ（Ｖｏｌｔａｇｅ Ｃｏｎｔｒｏｌｌｅｄ Ｏｓｃｉｌｌａｔｏｒ）を備え、水晶発振器２４３から入力される発振信号に基づき、ＶＣＯを利用してフィードバック制御を行うことで、当該一定周波数の信号を得る。生成した一定周波数の信号は、ミキサ２２３およびミキサ２３３に入力される。ＰＬＬ２４２は、一定周波数の信号を生成する発信装置の一例に相当する。

ミキサ２２３は、フィルタ２２２を通過したアナログＩ信号およびアナログＱ信号を、ＰＬＬ２４２から供給される一定周波数の信号を利用して、無線周波数にアップコンバートする。プリアンプ（ＰＡ）は、ミキサ２２３で生成された無線周波数のアナログＩ信号およびアナログＱ信号を、所望の出力電力まで増幅する。バラン２２５は、平衡信号（差動信号）を不平衡信号（シングルエンド信号）に変換するための変換器である。ＲＦ ＩＣ２２１では平衡信号が扱われるが、ＲＦ ＩＣ２２１の出力からアンテナ２４７までは不平衡信号が扱われるため、バラン２２５でこれらの信号変換を行う。

スイッチ２４５は、送信時は、送信側のバラン２２５に接続され、受信時は、受信側のバラン２３４またはＲＦ ＩＣ２２１に接続される。スイッチ２４５の制御はベースバンドＩＣ２１１またはＲＦ ＩＣ２２１により行われてもよいし、スイッチ２４５を制御する別の回路が存在し、当該回路からスイッチ２４５の制御を行ってもよい。

プリアンプ２２４で増幅された無線周波数のアナログＩ信号およびアナログＱ信号は、バラン２２５で平衡−不平衡変換された後、アンテナ２４７から空間に電波として放射される。

アンテナ２４７は、チップアンテナでもよいし、プリント基板上に配線により形成したアンテナでもよいし、線状の導体素子を利用して形成したアンテナでもよい。

ＲＦ ＩＣ２２１におけるＬＮＡ２３４は、アンテナ２４７からスイッチ２４５を介して受信した信号を、雑音を低く抑えたまま、復調可能なレベルまで増幅する。バラン２３５は、低雑音増幅器（ＬＮＡ）２３４で増幅された信号を、不平衡−平衡変換する。ミキサ２３３は、バラン２３５で平衡信号に変換された受信信号を、ＰＬＬ２４２から入力される一定周波数の信号を用いてベースバンドにダウンコンバートする。より詳細には、ミキサ２３３は、ＰＬＬ２４２から入力される一定周波数の信号に基づき、互いに９０°位相のずれた搬送波を生成する手段を有し、バラン２３５で変換された受信信号を、互いに９０°位相のずれた搬送波により直交復調して、受信信号と同位相のＩ（Ｉｎ−ｐｈａｓｅ）信号と、これより９０°位相が遅れたＱ（Ｑｕａｄ−ｐｈａｓｅ）信号とを生成する。フィルタ２３２は、これらＩ信号とＱ信号から所望周波数成分の信号を抽出する。フィルタ２３２で抽出されたＩ信号およびＱ信号は、ゲインが調整された後に、ＲＦ ＩＣ２２１から出力される。

ベースバンドＩＣ２１１におけるＡＤＣ２１７は、ＲＦ ＩＣ２２１からの入力信号をＡＤ変換する。より詳細には、ＡＤＣ２１７はＩ信号をデジタルＩ信号に変換し、Ｑ信号をデジタルＱ信号に変換する。なお、直交復調せずに一系統の信号だけを受信する場合もあり得る。

複数のアンテナが設けられる場合には、アンテナの数に応じた数のＡＤＣを設けてもよい。ベースバンド回路２１２は、デジタルＩ信号およびデジタルＱ信号に基づき、復調処理、誤り訂正符号処理、物理ヘッダの処理など、物理層の処理（ＭＩＭＯ復調を含んでもよい）等を行い、フレームを得る。ベースバンド回路２１２は、フレームに対してＭＡＣ層の処理を行う。なお、ベースバンド回路２１２は、ＴＣＰ／ＩＰを実装している場合は、ＴＣＰ／ＩＰの処理を行う構成も可能である。

上述した各部の処理の詳細は、図１の説明から自明であるため、重複する説明は省略する。

（第５の実施形態）
図１７（Ａ）および図１７（Ｂ）は、それぞれ第５の実施形態に係る無線機器の斜視図である。図１７（Ａ）の無線機器はノートＰＣ３０１であり、図１７（Ｂ）の無線機器は移動体端末３２１である。それぞれ、端末（基地局を含む）の一形態に対応する。ノートＰＣ３０１および移動体端末３２１は、それぞれ無線通信装置３０５、３１５を搭載している。無線通信装置３０５、３１５として、これまで説明してきた端末（基地局を含む）に搭載されていた無線通信装置を用いることができる。無線通信装置を搭載する無線機器は、ノートＰＣや移動体端末に限定されない。例えば、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン等にも搭載可能である。

また、端末（基地局を含む）に搭載されていた無線通信装置は、メモリーカードにも搭載可能である。当該無線通信装置をメモリーカードに搭載した例を図１８に示す。メモリーカード３３１は、無線通信装置３５５と、メモリーカード本体３３２とを含む。メモリーカード３３１は、外部の装置との無線通信のために無線通信装置３３５を利用する。なお、図１８では、メモリーカード３３１内の他の要素（例えばメモリ等）の記載は省略している。

（第６の実施形態）
第６の実施形態では、第１〜５のいずれかの実施形態に係る無線通信装置の構成に加えて、バス、プロセッサ部、及び外部インターフェース部を備える。プロセッサ部及び外部インターフェース部は、バスを介してバッファと接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。

（第７の実施形態）
第７の実施形態では、第１〜５のいずれかの実施形態に係る無線通信装置の構成に加えて、クロック生成部を備える。クロック生成部は、クロックを生成して出力端子より無線通信装置の外部にクロックを出力する。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側とを同期させて動作させることが可能となる。

（第８の実施形態）
第８の実施形態では、第１〜５のいずれかの実施形態に係る無線通信装置の構成に加えて、電源部、電源制御部、及び無線電力給電部を含む。電源制御部は、電源部と無線電力給電部とに接続され、無線通信装置に供給する電源を選択する制御を行う。このように、電源を無線通信装置に備える構成とすることにより、電源を制御した低消費電力化動作が可能となる。

（第９の実施形態）
第９の実施形態では、第８の実施形態に係る無線通信装置の構成に加えて、ＳＩＭカードを含む。ＳＩＭカードは、例えば、無線通信装置におけるＭＡＣ処理部１０、ＭＡＣ/ＰＨＹ管理部６０、または、制御部１１２と接続される。このように、ＳＩＭカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。

（第１０の実施形態）
第１０の実施形態では、第６の実施形態に係る無線通信装置の構成に加えて、動画像圧縮／伸長部を含む。動画像圧縮／伸長部は、バスと接続される。このように、動画像圧縮／伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長とを容易に行うことが可能となる。

（第１１の実施形態）
第１１の実施形態では、第１〜５のいずれかの実施形態に係る無線通信装置の構成に加えて、ＬＥＤ部を含む。ＬＥＤ部は、例えば、ＭＡＣ処理部１０、ＭＡＣ/ＰＨＹ管理部６０、送信処理回路１１３、受信処理回路１１４、制御部１１２の少なくとも１つと接続される。このように、ＬＥＤ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。

（第１２の実施形態）
第１２の実施形態では、第１〜５のいずれかの実施形態に係る無線通信装置の構成に加えて、バイブレータ部を含む。バイブレータ部は、例えば、ＭＡＣ処理部１０、ＭＡＣ/ＰＨＹ管理部６０、送信処理回路１１３、受信処理回路１１４、制御部１１２の少なくとも１つと接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。

（第１３の実施形態）
本実施形態では、［１］無線通信システムにおけるフレーム種別、［２］無線通信装置間の接続切断の手法、［３］無線ＬＡＮシステムのアクセス方式、［４］無線ＬＡＮのフレーム間隔について説明する。
［１］通信システムにおけるフレーム種別
一般的に無線通信システムにおける無線アクセスプロトコル上で扱うフレームは、前述したように、大別してデータ（ｄａｔａ）フレーム、管理（ｍａｎａｇｅｍｅｎｔ）フレーム、制御（ｃｏｎｔｒｏｌ）フレームの３種類に分けられる。これらの種別は、通常、フレーム間で共通に設けられるヘッダ部で示される。フレーム種別の表示方法としては、１つのフィールドで３種類を区別できるようにしてあってもよいし、２つのフィールドの組み合わせで区別できるようにしてあってもよい。ＩＥＥＥ８０２．１１規格では、フレーム種別の識別は、ＭＡＣフレームのフレームヘッダ部にあるＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドの中のＴｙｐｅ、Ｓｕｂｔｙｐｅという２つのフィールドで行う。データフレームか、管理フレームか、制御フレームかの大別はＴｙｐｅフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のＢｅａｃｏｎフレームといった識別はＳｕｂｔｙｐｅフィールドで行われる。

管理フレームは、他の無線通信装置との間の物理的な通信リンクの管理に用いるフレームである。例えば、他の無線通信装置との間の通信設定を行うために用いられるフレームや通信リンクをリリースする（つまり接続を切断する）ためのフレーム、無線通信装置でのパワーセーブ動作に係るフレームがある。

データフレームは、他の無線通信装置と物理的な通信リンクが確立した上で、無線通信装置の内部で生成されたデータを他の無線通信装置に送信するフレームである。データは本実施形態の上位層で生成され、例えばユーザの操作によって生成される。

制御フレームは、データフレームを他の無線通信装置との間で送受（交換）する際の制御に用いられるフレームである。無線通信装置がデータフレームや管理フレームを受信した場合にその送達確認のために送信される応答フレームは、制御フレームに属する。応答フレームは、例えばＡＣＫフレームやＢｌｏｃｋＡｃｋフレームである。またＲＴＳフレームやＣＴＳフレームも制御フレームである。

これら３種類のフレームは、物理層で必要に応じた処理を経て物理パケットとしてアンテナを経由して送出される。なお、ＩＥＥＥ８０２．１１規格（前述のＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３などの拡張規格を含む）では接続確立の手順の１つとしてアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）プロセスがあるが、その中で使われるＡｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームとＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームが管理フレームであり、Ａｓｓｏｃｉａｔｉｏｎ ＲｅｑｕｅｓｔフレームやＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームはユニキャストの管理フレームであることから、受信側無線通信端末に応答フレームであるＡＣＫフレームの送信を要求し、このＡＣＫフレームは上述のように制御フレームである。

［２］無線通信装置間の接続切断の手法
接続の切断（リリース）には、明示的な手法と暗示的な手法とがある。明示的な手法としては、接続を確立している無線通信装置間のいずれか一方が切断のためのフレームを送信する。ＩＥＥＥ８０２．１１規格ではＤｅａｕｔｈｅｎｔｉｃａｔｉｏｎフレームがこれに当たり、管理フレームに分類される。通常、接続を切断するフレームを送信する側の無線通信装置では当該フレームを送信した時点で、接続を切断するフレームを受信する側の無線通信装置では当該フレームを受信した時点で、接続の切断と判定する。その後、非基地局の無線通信端末であれば通信フェーズでの初期状態、例えば接続するＢＳＳ探索する状態に戻る。無線通信基地局がある無線通信端末との間の接続を切断した場合には、例えば無線通信基地局が自ＢＳＳに加入する無線通信端末を管理する接続管理テーブルを持っているならば当該接続管理テーブルから当該無線通信端末に係る情報を削除する。例えば、無線通信基地局が自ＢＳＳに加入する各無線通信端末に接続をアソシエーションプロセスで許可した段階で、ＡＩＤを割り当てる場合には、当該接続を切断した無線通信端末のＡＩＤに関連づけられた保持情報を削除し、当該ＡＩＤに関してはリリースして他の新規加入する無線通信端末に割り当てられるようにしてもよい。

一方、暗示的な手法としては、接続を確立した接続相手の無線通信装置から一定期間フレーム送信（データフレーム及び管理フレームの送信、あるいは自装置が送信したフレームへの応答フレームの送信）を検知しなかった場合に、接続状態の切断の判定を行う。このような手法があるのは、上述のように接続の切断を判定するような状況では、接続先の無線通信装置と通信距離が離れて無線信号が受信不可あるいは復号不可になるなど物理的な無線リンクが確保できない状態が考えられるからである。すなわち、接続を切断するフレームの受信を期待できないからである。

暗示的な方法で接続の切断を判定する具体例としては、タイマを使用する。例えば、送達確認応答フレームを要求するデータフレームを送信する際、当該フレームの再送期間を制限する第１のタイマ（例えばデータフレーム用の再送タイマ）を起動し、第１のタイマが切れるまで（つまり所望の再送期間が経過するまで）当該フレームへの送達確認応答フレームを受信しないと再送を行う。当該フレームへの送達確認応答フレームを受信すると第１のタイマは止められる。

一方、送達確認応答フレームを受信せず第１のタイマが切れると、例えば接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマ（例えば管理フレーム用の再送タイマ）を起動する。第１のタイマと同様、第２のタイマでも、第２のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマが切れると接続が切断されたと判定する。接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。

あるいは、接続相手の無線通信装置からフレームを受信すると第３のタイマを起動し、新たに接続相手の無線通信装置からフレームを受信するたびに第３のタイマを止め、再び初期値から起動する。第３のタイマが切れると前述と同様に接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマ（例えば管理フレーム用の再送タイマ）を起動する。この場合も、第２のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマが切れると接続が切断されたと判定する。この場合も、接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。後者の、接続相手の無線通信装置がまだ存在するかを確認するための管理フレームは、前者の場合の管理フレームとは異なるものであってもよい。また後者の場合の管理フレームの再送を制限するためのタイマは、ここでは第２のタイマとして前者の場合と同じものを用いたが、異なるタイマを用いるようにしてもよい。

［３］無線ＬＡＮシステムのアクセス方式
例えば、複数の無線通信装置と通信または競合することを想定した無線ＬＡＮシステムがある。ＩＥＥＥ８０２．１１無線ＬＡＮではＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃａｒｒｉｅｒ Ａｖｏｉｄａｎｃｅ）をアクセス方式の基本としている。ある無線通信装置の送信を把握し、その送信終了から固定時間を置いて送信を行う方式では、その無線通信装置の送信を把握した複数の無線通信装置で同時に送信を行うことになり、その結果、無線信号が衝突してフレーム送信に失敗する。ある無線通信装置の送信を把握し、その送信終了からランダム時間待つことで、その無線通信装置の送信を把握した複数の無線通信装置での送信が確率的に分散することになる。よって、ランダム時間の中で最も早い時間を引いた無線通信装置が１つなら無線通信装置のフレーム送信は成功し、フレームの衝突を防ぐことができる。ランダム値に基づき送信権の獲得が複数の無線通信装置間で公平になることから、Ｃａｒｒｉｅｒ Ａｖｏｉｄａｎｃｅを採用した方式は、複数の無線通信装置間で無線媒体を共有するために適した方式であるということができる。

［４］無線ＬＡＮのフレーム間隔
ＩＥＥＥ８０２．１１無線ＬＡＮのフレーム間隔について説明する。ＩＥＥＥ８０２．１１無線ＬＡＮで用いられるフレーム間隔は、ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｏｒｄｉｎａｔｉｏｎ ｆｕｎｃｔｉｏｎ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＤＩＦＳ）、ａｒｂｉｔｒａｔｉｏｎ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＡＩＦＳ）、ｐｏｉｎｔ ｃｏｏｒｄｉｎａｔｉｏｎ ｆｕｎｃｔｉｏｎ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＰＩＦＳ）、ｓｈｏｒｔ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＳＩＦＳ）、ｅｘｔｅｎｄｅｄ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＥＩＦＳ）、ｒｅｄｕｃｅｄ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＲＩＦＳ）の６種類ある。

フレーム間隔の定義は、ＩＥＥＥ８０２．１１無線ＬＡＮでは送信前にキャリアセンスアイドルを確認して開けるべき連続期間として定義されており、厳密な前のフレームからの期間は議論しない。従ってここでのＩＥＥＥ８０２．１１無線ＬＡＮシステムでの説明においてはその定義を踏襲する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＣＳＭＡ／ＣＡに基づくランダムアクセスの際に待つ時間を固定時間とランダム時間との和としており、固定時間を明確にするため、このような定義になっているといえる。

ＤＩＦＳとＡＩＦＳとは、ＣＳＭＡ／ＣＡに基づき他の無線通信装置と競合するコンテンション期間にフレーム交換開始を試みるときに用いるフレーム間隔である。ＤＩＦＳは、トラヒック種別による優先権の区別がないとき、ＡＩＦＳはトラヒック種別（Ｔｒａｆｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ：ＴＩＤ）による優先権が設けられている場合に用いる。

ＤＩＦＳとＡＩＦＳとで係る動作としては類似しているため、以降では主にＡＩＦＳを用いて説明する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＭＡＣ層でフレーム交換の開始などを含むアクセス制御を行う。さらに、上位層からデータを渡される際にＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）対応する場合には、データとともにトラヒック種別が通知され、トラヒック種別に基づいてデータはアクセス時の優先度のクラス分けがされる。このアクセス時のクラスをアクセスカテゴリ（Ａｃｃｅｓｓ Ｃａｔｅｇｏｒｙ；ＡＣ）と呼ぶ。従って、アクセスカテゴリごとにＡＩＦＳの値が設けられることになる。

ＰＩＦＳは、競合する他の無線通信装置よりも優先権を持つアクセスができるようにするためのフレーム間隔であり、ＤＩＦＳ及びＡＩＦＳのいずれの値よりも期間が短い。ＳＩＦＳは、応答系の制御フレームの送信時あるいは一旦アクセス権を獲得した後にバーストでフレーム交換を継続する場合に用いることができるフレーム間隔である。ＥＩＦＳはフレーム受信に失敗した（受信したフレームがエラーであると判定した）場合に発動されるフレーム間隔である。

ＲＩＦＳは一旦アクセス権を獲得した後にバーストで同一無線通信装置に複数のフレームを連続して送信する場合に用いることができるフレーム間隔であり、ＲＩＦＳを用いている間は送信相手の無線通信装置からの応答フレームを要求しない。

ここでＩＥＥＥ８０２．１１無線ＬＡＮにおけるランダムアクセスに基づく競合期間のフレーム交換の一例を図１９に示す。

ある無線通信装置においてデータフレーム（Ｗ＿ＤＡＴＡ１）の送信要求が発生した際に、キャリアセンスの結果、媒体がビジーである（ｂｕｓｙ ｍｅｄｉｕｍ）と認識する場合を想定する。この場合、キャリアセンスがアイドルになった時点から固定時間のＡＩＦＳを空け、その後ランダム時間（ｒａｎｄｏｍ ｂａｃｋｏｆｆ）空いたところで、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。なお、キャリアセンスの結果、媒体がビジーではない、つまり媒体がアイドル（ｉｄｌｅ）であると認識した場合には、キャリアセンスを開始した時点から固定時間のＡＩＦＳを空けて、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。

ランダム時間は０から整数で与えられるコンテンションウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ Ｗｉｎｄｏｗ：ＣＷ）の間の一様分布から導かれる擬似ランダム整数にスロット時間をかけたものである。ここで、ＣＷにスロット時間をかけたものをＣＷ時間幅と呼ぶ。ＣＷの初期値はＣＷｍｉｎで与えられ、再送するたびにＣＷの値はＣＷｍａｘになるまで増やされる。ＣＷｍｉｎとＣＷｍａｘとの両方とも、ＡＩＦＳと同様アクセスカテゴリごとの値を持つ。Ｗ＿ＤＡＴＡ１の送信先の無線通信装置では、データフレームの受信に成功し、かつ当該データフレームが応答フレームの送信を要求するフレームであるとそのデータフレームを内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ後に応答フレーム（Ｗ＿ＡＣＫ１）を送信する。Ｗ＿ＤＡＴＡ１を送信した無線通信装置は、Ｗ＿ＡＣＫ１を受信すると送信バースト時間制限内であればまたＷ＿ＡＣＫ１を内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ後に次のフレーム（例えばＷ＿ＤＡＴＡ２）を送信することができる。

ＡＩＦＳ、ＤＩＦＳ、ＰＩＦＳ及びＥＩＦＳは、ＳＩＦＳとスロット時間との関数になるが、ＳＩＦＳとスロット時間とは物理層ごとに規定されている。また、ＡＩＦＳ、ＣＷｍｉｎ及びＣＷｍａｘなどアクセスカテゴリごとに値が設けられるパラメータは、通信グループ（ＩＥＥＥ８０２．１１無線ＬＡＮではＢａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ（ＢＳＳ））ごとに設定可能であるが、デフォルト値が定められている。

例えば、８０２．１１ａｃの規格策定では、ＳＩＦＳは１６μｓ、スロット時間は９μｓであるとして、それによってＰＩＦＳは２５μｓ、ＤＩＦＳは３４μｓ、ＡＩＦＳにおいてアクセスカテゴリがＢＡＣＫＧＲＯＵＮＤ（ＡＣ＿ＢＫ）のフレーム間隔はデフォルト値が７９μｓ、ＢＥＳＴ ＥＦＦＯＲＴ（ＡＣ＿ＢＥ）のフレーム間隔はデフォルト値が４３μｓ、ＶＩＤＥＯ（ＡＣ＿ＶＩ）とＶＯＩＣＥ（ＡＣ＿ＶＯ）のフレーム間隔はデフォルト値が３４μｓ、ＣＷｍｉｎとＣＷｍａｘとのデフォルト値は、各々ＡＣ＿ＢＫとＡＣ＿ＢＥとでは３１と１０２３、ＡＣ＿ＶＩでは１５と３１、ＡＣ＿ＶＯでは７と１５になるとする。なお、ＥＩＦＳは、基本的にはＳＩＦＳとＤＩＦＳと最も低速な必須の物理レートで送信する場合の応答フレームの時間長の和である。なお効率的なＥＩＦＳの取り方ができる無線通信装置では、ＥＩＦＳを発動した物理パケットへの応答フレームを運ぶ物理パケットの占有時間長を推定し、ＳＩＦＳとＤＩＦＳとその推定時間の和とすることもできる。本実施形態では、このようなフレーム間隔のパラメータを用いる無線通信システムを通信レンジの広い干渉システムとして想定する。

なお、本実施形態において各端末が送信するフレームは、異なる内容のフレームであっても、同一の内容のフレームでもよい。一般的な表現として、複数の端末が第Ｘのフレームを送信または基地局が複数の第Ｘフレームを受信すると表現するとき、これらの第Ｘのフレームの内容は同じであっても、異なってもよい。

また、複数の端末から基地局へのアップリンク多重送信では、上述したＵＬ−ＭＵ−ＭＩＭＯおよびＵＬ−ＯＦＤＭＡ以外に、ＯＦＤＭＡとＭＵ−ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）を組み合わせた通信方式（ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯと呼ぶ）も可能である。ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合、リソースユニットごとに、複数の端末が同じリソースユニットを利用して、ＭＵ−ＭＩＭＯ送信を行うことになる。前述した各実施形態または各変形例では、アップリンク多重送信として、ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯを用いてもよい。

本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路 （ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。

別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
［付記］
［１］
無線通信装置であって、
送信許可を要求する第１フレームに応答して送信される、送信を許可する第２フレームを受信する受信部と、
前記第２フレームにおける受信先アドレスフィールドの第１領域に予め定めた第１の値が設定されているか判断する制御部と、
送信部と、を備え、
前記第１の値は、前記無線通信装置のアドレスにおける前記第１領域の値とは異なる値であり、
前記第１の値は、前記第２フレームを受信可能な他の無線通信装置のアドレスにおける前記第１領域の値とは異なる値であり、
前記送信部は、前記第２フレームにおける前記受信先アドレスフィールドの前記第１領域に前記第１の値が設定されている場合は、送信が禁止されている時間内であっても、第３フレームを送信し、
前記第３フレームは、前記他の無線通信装置から送信される第４フレームと多重される
無線通信装置。
［２］
前記第１領域は、前記第１フレームにおける前記受信先アドレスフィールドの先頭ビットである
［１］に記載の無線通信装置。
［３］
前記第３フレームは、前記第２フレームを受信した前記他の無線通信装置から送信される前記第４フレームと空間多重またはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）で送信される
［１］に記載の無線通信装置。
［４］
前記送信部は、送信元アドレスフィールドに前記無線通信装置のアドレスを設定し、受信先アドレスフィールドに、前記第２フレームの送信元アドレスを設定した、前記第１フレームを送信する
［３］に記載の無線通信装置。
［５］
前記受信部は、前記第１フレームが送信された後、前記受信先アドレスフィールドの前記第１領域に前記第１の値が設定された前記第２フレームを受信し、
前記送信部は、前記第２フレームの前記受信先アドレスフィールドに前記自装置のアドレスが設定されていなくても、前記第１フレームを再送しない
［４］に記載の無線通信装置。
［６］
前記受信部は、前記第３フレームの送信後、第５フレームを受信し、
前記制御部は、前記第５フレームの受信先アドレスフィールドにおける前記第１領域に前記第１の値が設定されている場合、前記第５フレームに前記無線通信装置と前記他の無線通信装置との送達確認情報が含まれていることを決定し、前記第５フレームから前記無線通信装置の前記送達確認情報を特定し、特定した前記送達確認情報に基づき、前記第３フレームの送信の成功可否を確認する
［１］に記載の無線通信装置。
［７］
少なくとも１つのアンテナをさらに備えた［１］ないし［６］のいずれか一項に記載の無線通信装置。

１０：ＭＡＣ処理部
２０：ＭＡＣ共通処理部
３０：送信処理部
４０：受信処理部
５０：ＰＨＹ処理部
６０：ＭＡＣ／ＰＨＹ管理部
７０：アナログ処理部（アナログ処理部１〜Ｎ）
８０：アンテナ（アンテナ１〜Ｎ）
９０：上位処理部
１１１：ベースバンド部
１２１：ＲＦ部
１２２：送信回路
１２３：受信回路
１１２：制御回路
１１３：送信処理回路
１１４：受信処理回路
１１５、１１６、２１５、２１６：ＤＡ変換回路
１１７、１１８、２１７、２１８：ＡＤ変換回路
３０１：ノートＰＣ
３０５、３１５、３５５：無線通信装置
３２１：移動体端末
３３１：メモリーカード
３３２：メモリーカード本体

Claims (8)

1. 送信元アドレスが第１の無線通信装置のアドレスであり、受信先アドレスが自装置のアドレスであり、送信許可を要求するフレームである第１フレームを受信する受信部と、
   前記第１フレームの受信に応じて、第１アドレス処理または第２アドレス処理を用いて生成した、送信を許可するフレームである第２フレームを送信する送信部とを備え、
   前記第１アドレス処理は、前記第２フレームの受信先アドレスフィールドにおける第１領域に予め定めた第１の値を設定する処理であり
   前記第２アドレス処理は、前記第１フレームの送信元アドレスフィールドの値をコピーして、前記第２フレームの受信先アドレスフィールドに設定する処理であり、
   前記第１の値は、前記第１の無線通信装置のアドレスにおける前記第１領域の値とは異なる値であり、
   前記第１の値は、前記第２フレームを受信可能な他の無線通信装置のアドレスにおける前記第１領域の値とは異なる値であり、
   前記送信部は、前記第１の無線通信装置および前記他の無線通信装置による多重送信を許可するときは前記第１アドレス処理を用いて生成した前記第２フレームを送信し、前記第１の無線通信装置のみの送信を許可するときは、前記第２アドレス処理を用いて生成した前記第２フレームを送信する、
   無線通信装置。
2. 前記第１領域は、前記第２フレームの受信先アドレスフィールドの先頭ビットである
   請求項１に記載の無線通信装置。
3. 前記第１の値は１である
   請求項２に記載の無線通信装置。
4. 前記受信部は、前記第１アドレス処理を用いて生成した前記第２フレームの送信後に、空間多重またはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）で送信される複数の第３フレームを受信する
   請求項１ないし３のいずれか一項に記載の無線通信装置。
5. 前記送信部は、前記第１アドレス処理を用いて生成された第４フレームを送信し、前記第４フレームは、前記複数の第３フレームの受信の成否を示す情報を含む
   請求項４に記載の無線通信装置。
6. 前記第１領域は、先頭ビットであり
   前記第１の無線通信装置および前記他の無線通信装置の各アドレスにおける前記先頭ビットの値は０であり、
   前記第２アドレス処理は、前記第１フレームの送信元アドレスフィールドをコピーした値の前記先頭ビットの値が１の場合は、前記コピーした値の前記先頭ビットの値を０に変更したものを、前記第２フレームの受信先アドレスフィールドに設定する
   請求項１に記載の無線通信装置。
7. 少なくとも１つのアンテナをさらに備えた請求項１ないし６のいずれか一項に記載の無線通信装置。
8. 空間多重またはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）で送信される第１フレームと第２フレームとを受信し、前記第１フレームは送信元アドレスが第１無線通信装置のアドレスであり、受信先アドレスが自装置のアドレスであり、前記第２フレームは、送信元アドレスが第２の無線通信装置のアドレスであり、受信先アドレスが自装置のアドレスである、受信部と、
   前記第１フレームと前記第２フレームとの受信の成否を表す第３フレームを第１アドレス処理を用いて生成し、送信する送信部とを備え、
   前記第１アドレス処理は、前記第３フレームの受信先アドレスフィールドにおける第１領域に予め定めた第１の値を設定する処理であり
   前記第１の値は、前記第１無線通信装置のアドレスにおける前記第１領域の値とは異なる値であり、
   前記第１の値は、第２無線通信装置のアドレスにおける前記第１領域の値とは異なる値である
   無線通信装置。

Images