JP2017059911A - 無線通信装置および無線通信方法 - Google Patents

Abstract

【課題】複数の無線通信端末へ送達確認応答を効率的に送信する。【解決手段】本発明の実施形態としての無線通信用集積回路は、ベースバンド集積回路を備える。前記ベースバンド集積回路は、複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、ＲＦ集積回路を介して送信し、前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記ＲＦ集積回路を介して受信し、前記複数の第２フレームそれぞれの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記ＲＦ集積回路を介して送信する。前記ベースバンド集積回路は、前記情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定する。【選択図】図１２

Description

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

アクセスポイントと無線通信端末（以下、端末と呼ぶ）間で通信を行う無線通信システムが知られている。例えば、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）を採用する無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）が広く知られている。無線ＬＡＮで、端末ごとに異なる周波数成分を通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う周波数多重通信を考える。ここでは、周波数成分を、１つまたは複数のサブキャリアを含むリソースユニットとして定義し、リソースユニットを最小単位の通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う直交周波数分割多元接続方式（ＯＦＤＭＡ；Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）を考える。アクセスポイントから複数の端末宛ての同時送信はダウンリンクＯＦＤＭＡ（ＤＬ−ＯＦＤＭＡ）送信、複数の端末からアクセスポイントへの同時送信はアップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）送信に相当する。

アップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）通信を行う場合、各端末に対する送達確認応答としては、アクセスポイントが各端末に対して順次、送達確認応答を返信する方法が考えられる。また、各端末に割り当てたリソースユニットと同一のリソースユニットを利用して、ＤＬ−ＯＦＤＭＡにて各端末に送達確認応答を返信する方法が考えられる。

各端末に順次、送達確認応答を返信する場合は、すべての端末に送達確認応答の返信が完了するまでの時間が長くなり、オーバーヘッドが大きくなる。このため、システムスループットの改善効果が小さい。また、ＤＬ−ＯＦＤＭＡで各端末に送達確認応答を返信する場合、第３者であるレガシー端末が、これらの送達確認応答を受信するとフレームの受信エラー（ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｏｄｅ）エラーなど）が発生する。このため、キャリアセンスを利用して行う無線媒体への次のアクセス権獲得時に、バックオフ前の一定時間としてＥＩＦＳ（Ｅｘｔｅｎｄｅｄ ＩｎｔｅｒＦｒａｍｅ Ｓｐａｃｅ）時間が起動され、ＤＩＦＳ（Ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｏｒｄｉｎａｔｉｏｎ ｆｕｎｃｔｉｏｎ ＩｎｔｅｒＦｒａｍｅ Ｓｐａｃｅ）時間またはＡＩＦＳ（Ａｒｂｉｔｒａｔｉｏｎ ＩｎｔｅｒＦｒａｍｅ Ｓｐａｃｅ）時間が起動されるＯＦＤＭＡ対応端末との間で、不公平が生じてしまう。つまり、後方互換性の問題が発生する。

特表２０１２−５１０７３４号公報

ＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ（ＴＭ）−２０１３ ＩＥＥＥ Ｓｔｄ ８０２．１１（ＴＭ）−２０１２

本発明の実施形態は、複数の無線通信端末へ送達確認応答を効率的に送信することを目的とする。

本発明の実施形態としての無線通信用集積回路は、ベースバンド集積回路を備える。前記ベースバンド集積回路は、複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、ＲＦ集積回路を介して送信し、前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記ＲＦ集積回路を介して受信し、前記複数の第２フレームそれぞれの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記ＲＦ集積回路を介して送信する。前記ベースバンド集積回路は、前記情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定する。

第１の実施形態に係る無線通信システムを示す図。 リソースユニットの割り当てを説明するための図。 リソースユニットの様々な構成を説明するための図。 ＭＡＣフレームの基本的なフォーマット例を示す図。 情報エレメントのフォーマット例を示す図。 本発明の第１〜第３の実施形態に係る動作シーケンスの例を示す図。 トリガーフレームを含む物理パケットのフォーマット例を示す図。 トリガーフレームのフォーマット例を示す図。 端末情報フィールドの構成例を示す図。 トリガーフレームを含む物理パケットのフォーマット例を示す図。 トリガーフレームの他のフォーマット例を示す図。 送達確認応答フレームのフォーマット例を示す図。 グルーピング情報の例を示す図。 送達確認応答フレームの他のフォーマット例を示す図。 送達確認応答フレームのさらに他のフォーマット例を示す図。 本発明の実施形態に係るアクセスポイントに搭載される無線通信装置の機能ブロック図。 本発明の実施形態に係る端末に搭載される無線通信装置の機能ブロック図。 第１の実施形態に係るアクセスポイントの動作のフローチャートを示す図。 第１の実施形態に係る端末の動作のフローチャートを示す図。 ＵＬ−ＭＵ−ＭＩＭＯの概念を説明する図。 フレームの先頭側にプリアンブルが配置された例を示す図。 ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの概念を説明する図。 ビットマップのフォーマット例を示す図。 送達確認応答フレームのさらに他のフォーマット例を示す図。 端末またはアクセスポイントの全体構成の例を示す図。 第４の実施形態に係る端末またはアクセスポイントに搭載される無線通信装置のハードウェア構成例を示す図。 第５の実施形態に係る端末の斜視図。 第５の実施形態に係るメモリーカードを示す図。 コンテンション期間のフレーム交換の一例を示す図。

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

（第１の実施形態）
図１は、第１の実施形態に係る無線通信システムを示す。

図１の無線通信システムは、基地局であるアクセスポイント（ＡＰ）１１と、複数の無線通信端末（以下、端末または端末と呼ぶことがある）１、２、３、４とを具備する。この無線通信ネットワークは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）を採用する無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。アクセスポイント１１も、中継機能等を有する点を除き、端末１〜４と同様の機能を有するため、端末の一形態である。アクセスポイント１１と各端末１〜４間の無線通信方式は任意でよいが、ここではＩＥＥＥ８０２．１１規格に従った無線通信方式を想定する。ただし、本実施形態はこれに限定されるものではない。以下の説明で、端末というときは、文脈上明らかにアクセスポイントでない場合を除き、アクセスポイントの場合も含んでよいものとする。

アクセスポイント１１は、少なくとも１つのアンテナを備える。ここでは、アクセスポイント１１は、複数のアンテナ１２Ａ、１２Ｂ、１２Ｃ、１２Ｄを備える。アクセスポイント１１は、複数の端末とアンテナ１２Ａ〜１２Ｄを介して、ＭＡＣフレーム（以下、フレームと呼ぶ場合もある）の送受信を行って通信を制御する無線通信装置（後述する図１６参照）を搭載する。無線通信装置は、アンテナ１２Ａ〜１２Ｄに接続されてフレームを送受信する無線通信部と、端末１〜４との通信を制御する通信制御装置とを備える。無線通信部は、一例としてＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）集積回路により形成され、通信制御装置は、一例としてベースバンド集積回路により形成されるが、この構成に限定されるものではない。

各端末１〜４は、１つまたは複数のアンテナを備える。図１の例では、端末１、３，４は、１本のアンテナ１Ａ、３Ａ、４Ａを備え、端末２は２本のアンテナ２Ａ、２Ｂを備えている。各端末は、無線通信装置（後述する図１７参照）を搭載する。各端末に搭載される無線通信装置は、各々のアンテナに接続されフレームを送受信する無線通信部と、アクセスポイント１１との通信を制御する通信制御装置とを備える。無線通信部は、一例としてＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）集積回路により形成され、通信制御装置は、一例としてベースバンド集積回路により形成されるが、この構成に限定されるものではない。

アクセスポイント１１は、各端末との間で無線ネットワーク（第１ネットワークと呼ぶ）を形成する。また、アクセスポイント１１は、これとは別に、有線または無線またはこれらのハイブリッドである他のネットワーク（第２ネットワークと呼ぶ）に接続されてもよい。アクセスポイント１１は、これら第１ネットワークおよび第２ネットワーク間で通信を中継する。また第１ネットワーク内の複数の端末間での通信も中継する。各端末１〜４で生成されたデータフレーム等のフレームは、アクセスポイント１１に送信される。アクセスポイント１１は、当該データフレームをその受信先アドレスに応じて、第１ネットワーク内の他の端末、あるいは第２ネットワークに送信する。なお、本明細書で述べるフレームは、例えばＩＥＥＥ８０２．１１規格でフレームと呼ばれているもののみならず、パケットと呼ばれているものであってもよい。

ここでアクセスポイント１１と端末１〜４間では、端末ごとに異なる周波数成分を通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う周波数多重通信が可能である。より詳細に、周波数成分を、１つまたは複数のサブキャリアを含むリソースユニットとして定義し、リソースユニットを最小単位の通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う直交周波数分割多元接続方式（ＯＦＤＭＡ；Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）が可能である。アクセスポイントから複数の端末宛ての同時送信はダウンリンクＯＦＤＭＡ（ＤＬ−ＯＦＤＭＡ）送信、複数の端末からアクセスポイントへの同時送信はアップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）送信に相当する。本実施形態では、ＵＬ−ＯＦＤＭＡおよびＤＬ−ＯＦＤＭＡのうち、少なくともＵＬ−ＯＦＤＭＡが可能である。リソースユニットのことを、サブチャネル、リソースブロック、周波数ブロックなどと呼んでもよい。ＵＬ−ＯＦＤＭＡおよびＤＬ−ＯＦＤＭＡの少なくともＵＬ−ＯＦＤＭＡを実施可能な端末をＯＦＤＭＡ対応端末と呼んでもよい。図１では、非アクセスポイントの端末として、ＯＦＤＭＡ対応端末である端末１〜４のみが示されているが、他のＯＦＤＭＡ対応端末およびレガシー端末が存在してもよい。

図２に、１つのチャネル（ここではチャネルＭと記述している）の連続した周波数領域内に確保したリソースユニット（ＲＵ＃１、ＲＵ＃２、・・・ＲＵ＃Ｋ）を示す。チャネルＭには、互いに直交する複数のサブキャリアが配置されており、１つまたは複数の連続するサブキャリアを含む複数のリソースユニットがチャネルＭ内に定義されている。リソースユニット間には、１つ以上のサブキャリア（ガードサブキャリア）が配置されてもよいが、ガードサブキャリアは必須ではない。チャネル内の各サブキャリアには、サブキャリアを識別するための番号が付与されていてもよい。１つのチャネルの帯域幅は、一例として、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚなどであるが、これらに限定されない。２０ＭＨｚの複数のチャネルをまとめて１つのチャネルとしてもよい。帯域幅に応じてチャネル内のサブキャリア数またはリソースユニット数が異なってもよい。複数の端末がそれぞれ異なるリソースユニットを同時に用いることで、ＵＬ-ＯＦＤＭＡまたはＤＬ-ＯＦＤＭＡが実現される。

リソースユニットの帯域幅（あるいはサブキャリア数）は、各リソースユニットで共通でもよいし、リソースユニットごとに帯域幅（あるいはサブキャリア数）が異なってもよい。図３に、１つのチャネル内におけるリソースユニットの配置パターン例を模式的に示す。紙面に沿って横方向が周波数領域方向に対応する。図３（Ａ）は、同じ帯域幅の複数のリソースユニット（ＲＵ＃１、ＲＵ＃２、・・・ＲＵ＃Ｋ）を配置した例を示す。図３（Ｂ）は、図３（Ａ）より大きな帯域幅の複数のリソースユニット（ＲＵ＃１１−１、ＲＵ＃１１−２、・・・、ＲＵ＃１１−Ｌ）を配置した例を示す。図３（Ｃ）は３種類の大きさの帯域幅のリソースユニットを配置した例を示す。リソースユニット（ＲＵ＃１２−１、ＲＵ＃１２−２）が最も大きな帯域幅を有し、リソースユニットＲＵ＃１２−（Ｌ−１）は図３（Ｂ）と同じ帯域幅、リソースユニット（ＲＵ＃Ｋ−１、ＲＵ＃Ｋ）は図３（Ａ）と同じ帯域幅である。

一例として、２０ＭＨｚチャネル幅全体を使う場合、２０ＭＨｚチャネル幅内に配置される２５６サブキャリア（トーン）に対し、リソースユニットが２６個（トーン）で設定できる。つまり、２０ＭＨｚチャネル幅では９つのリソースユニットが設定され、リソースユニットの帯域幅としては２．５ＭＨｚ幅より小さくなる。４０ＭＨｚチャネル幅では、一例として、リソースユニットは１８個設定される。８０ＭＨｚチャネル幅では、一例として、リソースユニットは、３７個設定される。これを発展させると、例えば１６０ＭＨｚチャネル幅または８０＋８０ＭＨｚチャネル幅では、７４個のリソースユニットが設定される。もちろんリソースユニットの幅は特定の値に制限されず、様々なサイズのリソースユニットを配置することもできる。

なお、各端末に割り当てるリソースユニット数は、特定の値に制限されず、１つまたは複数のリソースユニットでもよい。端末が複数のリソースユニットを用いる場合、周波数的に連続する複数のリソースユニットを用いてもよいし、離れた箇所にある複数のリソースユニットを用いることを許容してもよい。

１つのリソースユニット内のサブキャリアは周波数領域で連続しているとするが、非連続に配置された複数のサブキャリアからリソースユニットを定義してもよい。ＵＬ−ＯＦＤＭＡ通信で使用するチャネルは１つに限定されず、チャネルＭと周波数領域で離れた位置に配置された別のチャネル（図３ではチャネルＮを参照）内にも、チャネルＭと同様にしてリソースユニットを確保し、チャネルＭとチャネルＮの両方内のリソースユニットを用いてもよい。チャネルＭとチャネルＮとでリソースユニットの配置方法は同じであっても、異なってもよい。チャネルＮの帯域幅は、一例として、上述のように、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚなどであるが、これらに限定されない。３つ以上のチャネルを用いることも可能である。なお、チャネルＭとチャネルＮをまとめて１つのチャネルとして考えても良い。

なお、ＯＦＤＭＡ対応端末は、少なくとも後方互換の対象となるレガシー端末（ＯＦＤＭＡを実施する能力のない端末）での基本チャネル幅（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末をレガシー端末とするなら２０ＭＨｚチャネル幅）のチャネルで、フレームを含む物理パケットを受信・復号（復調および誤り訂正符号の復号等を含む）できるものとする。キャリアセンスに関しては基本チャネル幅の単位で行うものとする。キャリアセンスは、ＣＣＡ（Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ）のビジー／アイドルに関する物理的なキャリアセンス（Ｐｈｙｓｉｃａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）と、受信したフレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス（Ｖｉｒｔｕａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）との両方を包含してもよい。後者のように、仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれる。なお、チャネル単位で行ったＣＣＡまたはＮＡＶに基づくキャリアセンス情報は、チャネル内の全リソースユニットに共通に適用してもよい。この場合、例えばキャリアセンス情報がアイドルを示すチャネルに属するリソースユニットはすべてアイドルとなる。

なお、ＯＦＤＭＡは上述したリソースユニットベースのＯＦＤＭＡ以外に、チャネルベースでのＯＦＤＭＡも可能でもよい。この場合のＯＦＤＭＡを特にＭＵ−ＭＣ（Ｍｕｌｔｉ−Ｕｓｅｒ Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ）と呼ぶことがある。ＭＵ−ＭＣでは、アクセスポイントが複数のチャネル（１つのチャネル幅は例えば２０ＭＨｚなど）を複数の端末に割り当て、当該複数のチャネルを同時に用いて、複数端末宛て同時送信もしくは複数端末からの同時受信をチャネルベースで行う。以降に説明するＯＦＤＭＡでは、リソースユニットベースのＯＦＤＭＡを想定するが、以降の説明のリソースユニットをチャネルに読み替えるなど、必要な読み替えを行うことで、チャネルベースのＯＦＤＭＡの実施形態も実現可能である。

図４（Ａ）は、ＭＡＣフレームの基本的なフォーマット例を示す。本実施形態に係るデータフレーム、管理フレームおよび制御フレーム（各フレームの詳細は後述する実施形態で説明）は、このようなフレームフォーマットをベースとする。本フレームフォーマットは、ＭＡＣヘッダ（ＭＡＣ ｈｅａｄｅｒ）、フレームボディ（Ｆｒａｍｅ ｂｏｄｙ）及びＦＣＳの各フィールドを含む。ＭＡＣヘッダは、図４（Ｂ）に示すように、Ｆｒａｍｅ Ｃｏｎｔｒｏｌ、Ｄｕｒａｔｉｏｎ／ＩＤ、Ａｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２、Ａｄｄｒｅｓｓ３， Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ、ＱｏＳ Ｃｏｎｔｒｏｌ及び ＨＴ（Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ） ｃｏｎｔｒｏｌの各フィールドを含む。

これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しない場合もあり得る。例えばＡｄｄｒｅｓｓ３フィールドが存在しない場合もある。また、ＱｏＳ ＣｏｎｔｒｏｌおよびＨＴ Ｃｏｎｔｒｏｌフィールドの両方または一方が存在しない場合もある。またフレームボディフィールドが存在しない場合もあり得る。また図５には示されていない他のフィールドが存在してもよい。例えば、Ａｄｄｒｅｓｓ４フィールドがさらに存在してもよい。

Ａｄｄｒｅｓｓ１のフィールドには、受信先アドレス（Ｒｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓ；ＲＡ）が、Ａｄｄｒｅｓｓ２のフィールドには送信元アドレス（Ｔｒａｎｓｍｉｔｔｅｒ Ａｄｄｒｅｓｓ；ＴＡ）が入り、Ａｄｄｒｅｓｓ ３のフィールドにはフレームの用途に応じてＢＳＳの識別子であるＢＳＳＩＤ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ ＩＤｅｎｔｉｆｉｅｒ）（全てのビットに１を入れて全てのＢＳＳＩＤを対象とするｗｉｌｄｃａｒｄ ＢＳＳＩＤ場合もある）か、あるいはＴＡが入る。

Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドには、前述したようにタイプ（Ｔｙｐｅ）、サブタイプ（Ｓｕｂｔｙｐｅ）という２つのフィールド等を設定する。データフレームか、管理フレームか、制御フレームかの大別はＴｙｐｅフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のＢＡフレーム、ＢＡＲフレーム、Ｂｅａｃｏｎフレームといった識別はＳｕｂｔｙｐｅフィールドで行われる。後述するトリガーフレームも、タイプおよびサブタイプの組み合わせで区別してもよい。

Ｄｕｒａｔｉｏｎ／ＩＤフィールドは媒体予約時間を記載し、他の端末宛てのＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、前述したように、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれる。ＱｏＳフィールドは、フレームの優先度を考慮して送信を行うＱｏＳ制御を行うために用いられる。ＨＴ Ｃｏｎｔｒｏｌフィールドは、ＩＥＥＥ８０２．１１ｎで導入されたフィールドである。

管理フレームでは、固有のＥｌｅｍｅｎｔ ＩＤ（ＩＤｅｎｔｉｆｉｅｒ）が割り当てられた情報エレメント（Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ；ＩＥ）をＦｒａｍｅ Ｂｏｄｙフィールドに設定する。フレームボディフィールドには、１つまたは複数の情報エレメントを設定できる。情報エレメントは、図５に示すように、Ｅｌｅｍｅｎｔ ＩＤフィールド、Ｌｅｎｇｔｈフィールド、情報（Ｉｎｆｏｒｍａｔｉｏｎ）フィールドの各フィールドを有する。情報エレメントは、Ｅｌｅｍｅｎｔ ＩＤで識別される。情報フィールドは、通知する情報の内容を格納し、Ｌｅｎｇｔｈフィールドは、情報フィールドの長さ情報を格納する。

ＦＣＳフィールドには、受信側でフレームの誤り検出のため用いられるチェックサム符号としてＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）情報が設定される。ＦＣＳ情報の例としては、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｏｄｅ）などがある。

図６に、本実施形態に係るアクセスポイント１１と、端末１〜４との動作シーケンス例を示す。

本動作シーケンスの始まる前では、前提として、アクセスポイントと端末１〜４の一部または全部との間でＣＳＭＡ／ＣＡベースで個別に通信（シングルユーザ通信）が行われている。シングルユーザ通信では、例えば基本チャネル幅（例えば２０ＭＨｚ）の１チャネルでアクセスポイントおよび端末間で通信が行われている。シングルユーザ通信の例として、端末でアップリンク送信用のデータが保持されている場合、ＣＳＭＡ／ＣＡに従って、無線媒体へのアクセス権を獲得する。このため、端末はＤＩＦＳ／ＡＩＦＳ[ＡＣ]と、ランダムに決定したバックオフ時間とのキャリアセンス時間（待機時間）の間、キャリアセンスを行い、媒体（ＣＣＡ）がアイドルと判断されると、例えば１フレームを送信するアクセス権を獲得する。端末は、送信するデータを含むデータフレーム（より詳細にはデータフレームを含む物理パケット）を送信し、アクセスポイントがこのデータフレームを正常に受信すると、データフレームの受信完了からＳＩＦＳ時間後に、送達確認応答フレームであるＡＣＫフレーム（より詳細にはＡＣＫフレームを含む物理パケット）を返す。端末はＡＣＫフレームを受信することで、データフレームの送信が成功したと判断する。なお、アクセスポイントに送信するデータフレームはアグリゲーションフレーム（Ａ-ＭＰＤＵ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ （ＭＡＣ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）等）でもよく、アクセスポイントが応答する送達確認応答フレームはＢＡ（Ｂｌｏｃｋ Ａｃｋ）フレームでもよい（以下同様）。なお、ＤＩＦＳ／ＡＩＦＳ［ＡＣ］時間は、ＤＩＦＳおよびＡＩＦＳ［ＡＣ］のいずれか一方の時間を意味する。ＱｏＳ対応でない場合はＤＩＦＳ時間を指し、ＱｏＳ対応の場合は、送信するデータのアクセスカテゴリ（ＡＣ：Ａｃｃｅｓｓ Ｃａｔｅｇｏｒｙ）に応じて決まるＡＩＦＳ［ＡＣ］時間を指す。

ここでアクセスポイントが、任意のタイミングでＵＬ−ＯＦＤＭＡの開始を決定する。本例ではＵＬ−ＯＦＤＭＡ送信をシングルユーザ通信と同じチャネル（基本チャネル幅２０ＭＨｚの１チャネル）で行う場合を想定する。つまり、基本チャネル幅２０ＭＨｚのチャネル内に定義された複数のリソースユニットを用いてＵＬ−ＯＦＤＭＡ送信を行う場合を想定する。ただし、４０ＭＨｚ、８０ＭＨｚなど、他のチャネル幅でＵＬ−ＯＦＤＭＡ送信を行うことも可能である。

アクセスポイントは、ＵＬ−ＯＦＤＭＡの実施を決定すると、ＵＬ−ＯＦＤＭＡに必要な事項を決定して、トリガーフレーム５０１を生成する。アクセスポイントは、当該トリガーフレーム５０１（より詳細にはトリガーフレームを含む物理パケット）を、ＣＳＭＡ／ＣＡに従って獲得したアクセス権に基づき送信する。トリガーフレーム５０１は、シングルユーザ通信と同じチャネルの基本チャネル幅のチャネルで送信する。トリガーフレームを含む物理パケットは、一例として、トリガーフレームの先頭に物理ヘッダを付加したものである。物理ヘッダは、一例として、図７に示すように、ＩＥＥＥ８０２．１１規格で定義されているＬ−ＳＴＦ（Ｌｅｇａｃｙ−Ｓｈｏｒｔ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、Ｌ−ＬＴＦ（Ｌｅｇａｃｙ−Ｌｏｎｇ ＴｒａｉｎｉｎｇＦｉｅｌｄ）、Ｌ−ＳＩＧ（Ｌｅｇａｃｙ Ｓｉｇｎａｌ Ｆｉｅｌｄ）、を含む。Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧは、例えば、ＩＥＥＥ８０２．１１ａなどのレガシー規格の端末が認識可能なフィールドであり、それぞれ信号検出、周波数補正（伝搬路推定）、伝送速度などの情報が格納される。ここで述べた以外のフィールド（例えばレガシー端末が認識できず、ＵＬ−ＯＦＤＭＡ対応端末が認識できるフィールド）が含まれてもよい。トリガーフレーム５０１は、ＵＬ−ＯＦＤＭＡ対応端末の他、レガシー端末も受信および復号可能なフレームでもよい。なお、図７の「・・・」は、この箇所に図示されている以外のフィールドが存在しても、存在しなくてもよいことを意味する。

以下、トリガーフレーム５０１の生成について詳細に説明する。

ここでトリガーフレーム５０１の生成にあたり必要なＵＬ−ＯＦＤＭＡに必要な事項の決定として、例えばＵＬ−ＯＦＤＭＡを行う端末を選択する。選択の方法としては、例えば事前に各端末からＵＬ−ＯＦＤＭＡ送信の要求有無を収集し、要求有りの端末から選択してもよい。

または、各端末における送信用のデータ量に基づき、データ量が最も大きい端末から優先的に選択してもよいし、データ量が同じくらいの端末を選択してもよい。

また、アクセスポイントが端末をグループ化して管理している場合に、同じグループに属する全部または一部の端末を選択、またはグループを選択してもよい。この場合、アクセスポイントは、アソシエーションプロセスまたはその後の任意のタイミングで、自局に属する端末群をグルーピングし、各端末に各グループの識別情報（ＩＥＥＥ８０２．１１ａｃのグループＩＤでもよいし、これとは別に定義されるグループＩＤでもよい）と、各グループに属する端末群のリストとを表したグルーピング情報を管理フレーム等で通知しているものとする。各端末にすべてのグループに関するリストを送っても良いし、自端末が属するグループのリストのみを送っても良い。グループを選択する基準として、各グループに属する端末ごとのＵＬ−ＯＦＤＭＡ送信の要求の有無、送信用データ量などの項目を考慮してもよい。

または、ラウンドロビンで、端末またはグループを選択してもよいし、ランダムで端末またはグループを選択してもよい。

または、次に送信するデータのサイズが同じ、または近いと推定されるデータを有する端末を選択、またはデータの発生周期が同じ、または発生周期が近い端末（発生周期が一定値以内に含まれる端末、または発生周期が最も近い所定数の端末など）を選択することも可能である。

また、送信するデータのデータ種別が同じ端末を選択してもよい。データ種別として、ＱｏＳ対応の場合には、ＡＣ（Ａｃｃｅｓｓ Ｃａｔｅｇｏｒｙ：アクセスカテゴリ）でもよい。また、データ種別は、ＴＩＤ（Ｔｒａｆｆｉｃ ＩＤ：トラヒック種別）でもよい。

なお、選択する端末数は、ＯＦＤＭＡのため、利用可能なリソースユニット数以下で選択する。選択する端末数の下限が定められている場合に、下限以上の端末数を選択してもよい。ここで述べた端末の選択例は一例に過ぎず、ここで述べた以外の方法で端末を選択してもよい。

またアクセスポイントは、選択した端末に対し、ＵＬ−ＯＦＤＭＡで使用させる少なくとも１つのリソースユニットを決定する。さらに、アクセスポイントは、端末が送信する最大のパケット長（ＰＰＤＵ（Ｐｈｙｓｉｃａｌ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）長）を共通にまたは個別に決定してもよい。例えば各端末から、次の送信に必要なＴＸＯＰ長またはデータ量またはこれらの両方を含む情報を取得している場合に、各端末から通知されたＴＸＯＰ長またはデータ量（ＰＰＤＵ長等）を利用して、ＰＰＤＵ長を決定してもよい。共通にパケット長を決定する場合、例えば、端末の中でＴＸＯＰまたはデータ量が最も長いものに基づき、ＰＰＤＵ長を決定してもよい。ここで述べた以外の項目を設定してもよい。例えば、誤り訂正符号方式、ＰＨＹまたはＭＡＣまたはこれらの両方の送信レートを規定するＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ：変調符号化方式）、の少なくとも１つを設定してもよい。具体的に、各端末のＰＰＤＵ長が等しくまたは近くなるように、端末毎のＭＣＳを決定してもよい。ＭＣＳはフレームのみならず、物理ヘッダ（プリアンブル）に対しても指定可能な場合は、物理ヘッダに対して適用するＭＣＳを決定してもよい。また、各端末の送信電力を決定してもよい。例えば各端末から受信する受信電力（ＲＳＳＩ等）が同じまたは一定の範囲内に収まるような送信電力を、測定により決定してもよい。

アクセスポイントは、ＵＬ−ＯＦＤＭＡを行う端末、当該端末に割り当てるリソースユニット等、ＵＬ−ＯＦＤＭＡ通信の実施に必要な事項が決定したら、トリガーフレーム５０１を生成する。トリガーフレーム５０１は、ＵＬ−ＯＦＤＭＡ送信の実施にあたり端末に通知する必要のある情報（通知情報）を含む。

図８にトリガーフレームのフォーマット例を示す。トリガーフレーム５０１は、図５に示した一般的なＭＡＣフレームのフォーマットをベースに定義される。トリガーフレームのヘッダまたはフレームボディフィールドには、制御フィールドと、少なくともＵＬ−ＯＦＤＭＡを行う端末の台数分の端末情報（ＳＴＡ Ｉｎｆｏ．）フィールドとを備える。

Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプは制御フレームを表す値とし、サブタイプの値は、トリガーフレーム用に新規に定義した値とすればよい。ただし、トリガーフレームのフレームタイプは、制御フレームではなく、管理フレームまたはデータフレームとする構成も排除されない。既存の管理フレームのフレームボディフィールドにトリガーフレーム５０１の役割として必要な情報（制御フィールドおよび端末情報フィールドの情報）を情報エレメントとして追加してもよい。サブタイプの値も既存の規格の値を流用してもよい。

トリガーフレーム５０１のＲＡ（受信先アドレス）は、一例として、ブロードキャストアドレスまたはマルチキャストアドレスとし、当該アドレスを、アドレス１フィールドに設定すればよい。またＴＡ（送信元アドレス）は、アクセスポイントのＭＡＣアドレスまたはＢＳＳＩＤを、アドレス２フィールドに設定すればよい。

図６のシーケンス例では、トリガーフレームのフレームボディフィールドには、４台の端末１〜４を選定したため、４つの端末情報フィールド（ＳＴＡ ｉｎｆｏフィールド）１〜４を設定する。各端末情報フィールドには、端末に個別に通知する情報を設定する。制御フィールドには、ＵＬ-ＯＦＤＭＡの対象として選択された端末１〜４に共通に通知する情報を設定する。

制御フィールドに設定する情報の例として、例えば、端末情報フィールドの個数に関する情報を設定する。端末情報フィールドの数は、選択された端末数に応じて変動し得るため、端末情報フィールドに関する数を、制御フィールドに設定することが考えられる。

また、トリガーフレームでＵＬ−ＯＦＤＭＡの送信タイミングを共通に指定する場合には、送信タイミングに関する情報を設定してもよい。なお、トリガーフレームの受信完了から予め定めた一定時間（予め定めた値のＩＦＳ）後にアップリンク送信を行うことが定められている場合は、各端末でこの時間の値は既知であるため通知は不要である。

また、各端末でアップリンク送信するパケット長または時間長が共通の場合は、パケット長または時間長またはこれらの両方を特定する情報を、制御フィールドに設定してもよい。

また、ＵＬ−ＯＦＤＭＡを行う対象となる端末として、端末のグループを選択した場合は、当該グループを識別する情報（グループＩＤ）を、制御フィールドに設定してもよい。この際、当該グループに属するすべての端末が、ＵＬ-ＯＦＤＭＡの対象端末とのルールがあるときは、各端末が、複数の端末情報フィールドのいずれで自端末の情報が通知されているかが把握可能な限り、後述する各端末情報フィールドに端末の識別子を設定することを省略してもよい。例えば、自端末が先頭または末尾から何番目の端末情報フィールドを割り当てられているかを事前にアクセスポイントから通知されている場合は、端末の識別子の設定を省略することが考えられる。グループに属するリストでの自端末の位置から端末情報フィールドを特定可能な場合も、端末の識別子の設定を省略することが考えられる。また、各端末がＵＬ−ＯＦＤＭＡで使用するリソースユニットを事前に通知されており、使用するリソースユニットに応じて、複数の端末情報フィールドのいずれで情報が通知されているかが定まっている場合も同様である。

また、端末情報フィールド１〜ｎのサイズが可変長の場合は、端末情報フィールド１〜ｎのサイズを特定する情報を制御フィールドに設定してもよい。各端末情報フィールドのサイズは共通でもよいし、個別にサイズが指定可能であってもよい。

端末情報フィールド１〜ｎのフォーマット例を図９に示す。各端末情報フィールドは、一例として、端末の識別子を設定するフィールド（ＳＴＡ ＩＤフィールド）およびリソースユニットを指定する情報を設定するフィールド（ＲＵ＃フィールド）等を含む。これ以外にも、端末に個別に通知する種々のフィールド（図ではotherフィールドとして表している）を含んでもよい。

ＳＴＡ ＩＤフィールドには、各端末の識別子を設定する。端末の識別子は、端末のアソシエーションＩＤ（ＡＩＤ）、ＭＡＣアドレス、その他、端末のユニークなＩＤでもよい。アソシエーションＩＤは、端末がアクセスポイントのＢＳＳに属するためにアクセスポイントとの間で行うアソシエーションプロセス時に付与される識別子である。

また、ＲＵ＃フィールドには、該当する端末がＵＬ−ＯＦＤＭＡで使用するリソースユニットを指定する情報を設定する。指定するリソースユニットの数は複数であってもよい。リソースユニットを指定する情報の形式は、当該リソースユニットを特定可能な限り、どのような形式でもよい。例えばリソースユニットの番号によって指定してもよい。高周波側または低周波側から何番目のリソースユニットかを指定してもよい。ＵＬ-ＯＦＤＭＡで使用するチャネルの識別子との組み合わせでリソースユニットを指定することもあり得る。端末情報フィールドごとにリソースユニットが事前に対応づけられている場合は、ＲＵ＃フィールドを省略してもよい。例えば、端末情報フィールド１にリソースユニット１（ＲＵ＃１）が対応づけられている場合、端末情報フィールド１で指定された端末は、リソースユニット１（ＲＵ＃１）を使用することを判断できる。なお、ＲＵ＃１の表記は、図３に対応している必要はない。端末情報フィールドとリソースユニットとの対応づけは、アクセスポイントが決定して事前に各ＯＦＤＭＡ対応端末に通知してもよいし、システムまたは規格で定められてもよい。なお、複数のリソースユニットの集合を識別する識別子を別途定義し、当該集合の識別子を１つまたは複数、ＲＵ＃フィールドで指定する構成も考えられる。この場合、端末は、当該集合の識別子から利用可能なリソースユニットを把握することができるものとする。

otherフィールドには、他のパラメータ例として、送信を許可するパケット長（ＰＰＤＵ長など）、誤り訂正符号方式、ＰＨＹまたはＭＡＣまたはこれらの両方の送信レートを規定するＭＣＳ、の少なくとも１つに関する情報を設定してもよい。パケット長の単位は、データサイズでもよいし、時間長（空間での占有時間長）でもよい。パケット長が各端末で共通の場合は、パケット長に関する情報は、端末情報フィールドでの設定を省略し、制御フィールドに設定してもよい。なおパケット長の最大値は、規格またはシステムで事前に決められていてもよく、この場合最大値以下の範囲で、パケット長を指定してもよい。なお、パケット長の代わりに、ＭＡＣフレーム長またはＭＳＤＵ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ （ＭＡＣ） ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）長などを用いることも可能である。また、さらに別のパラメータ例として、各端末が送信すべきデータ種別の情報を指定してもよい。データ種別として、アクセスカテゴリ（ＡＣ）またはトラヒック情報（ＴＩＤ：Ｔｒａｆｆｉｃ ＩＤ）を設定してもよい。指定するデータ種別は、端末ごとに異なってもよいし、各端末で共通でもよい。また複数のデータ種別を指定してもよい。また各端末の送信電力を指定する情報を設定してもよい。また、ＵＬ−ＯＦＤＭＡの送信タイミングを端末に個別に指定する場合（ＵＬ−ＯＦＤＭＡの送信タイミングを端末間で調整する場合）には、送信タイミングに関する情報を設定してもよい。例えば予め定められた送信タイミングに対する調整量を設定してもよい。

図８の例では、制御フィールドおよび端末情報フィールドを、ヘッダまたはフレームボディフィールドに設定する例を示したが、制御フィールドおよび端末情報フィールドに設定する情報の一部または全部を、図に示すように、物理ヘッダ内に配置してもよい。図１０の物理ヘッダは、Ｌ−ＳＴＦ（Ｌｅｇａｃｙ−Ｓｈｏｒｔ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、Ｌ−ＬＴＦ（Ｌｅｇａｃｙ−Ｌｏｎｇ ＴｒａｉｎｉｎｇＦｉｅｌｄ）、Ｌ−ＳＩＧ（Ｌｅｇａｃｙ Ｓｉｇｎａｌ Ｆｉｅｌｄ）の後に、制御フィールド、端末数分の端末情報フィールドを含む。通知する必要のある情報がすべて物理ヘッダ内に設定される場合は、ＭＡＣフレームから制御フィールドおよび端末情報フィールドを省略してもよい。

なお、図１１に示すように、制御フィールドを省略するトリガーフレームの構成もあり得る。端末情報フィールド数が固定であり、それ以外に制御フィールドで通知する情報が存在しない、もしくは、端末に通知する必要がある情報をすべて端末情報フィールドで個別に通知する場合は、制御フィールドを省略してもよい。端末情報フィールド数を固定にする場合、ＵＬ-ＯＦＤＭＡの対象として指定する端末数が端末情報フィールド数より少ない場合は、一部の端末情報フィールドを使用しない構成も可能である。

また上述した制御フィールドと端末情報フィールドの設定例は一例であり、端末情報フィールドに設定すると説明した情報の一部を、制御フィールドに設定してもよい。例えば、端末を指定する情報を端末情報フィールドではなく、制御フィールドに設定し、これによりＳＴＡ ＩＤフィールドを省略してもよい。この場合、制御フィールドで指定された端末が使用する端末情報フィールドの位置も、制御フィールドで指定されていてもよいし、端末が使用する端末情報フィールドの位置は、事前にアクセスポイントから別途通知されていてもよい。

アクセスポイントから送信されたトリガーフレーム５０１は端末１〜４で受信される。端末１〜４は、トリガーフレーム５０１を復号し、ＦＣＳ検査（ＣＲＣ検査等）で受信に成功したと判断すると、自端末が端末情報フィールド１〜ｎのいずれかで指定されているかを検査する。これは、例えば端末情報フィールド１〜ｎのＳＴＡ ＩＤフィールドに自端末の識別子が設定されているかを調べることで判断できる。制御フィールドに、自端末の属するグループＩＤが設定されている場合のみ、当該端末情報フィールドのＳＴＡ ＩＤフィールドを検査してもよい。あるいは、自端末の属するグループＩＤが設定されている場合に自端末が常に指定されたとのルールがある場合は、そのことをもって自端末が指定されたと判断してもよい。あるいは、制御フィールドに、ＵＬ-ＯＦＤＭＡの対象となる端末を特定する情報がグループＩＤではなく、個々の端末の識別子を設定されている場合には、当該制御フィールドで自端末の識別子が設定されているか否かで、自端末が指定されたかを判断してもよい。ここで述べた以外の方法で判断することも可能である。

また、ＵＬ−ＯＦＤＭＡの対象として指定された端末は、自端末が使用するリソースユニットを特定する。例えば、端末情報フィールドのＲＵ＃フィールドに設定された情報から、使用するリソースユニットを特定する。端末情報フィールドに予めリソースユニットが対応づけられている場合は、端末情報フィールドの位置からリソースユニットを特定してもよい。端末情報フィールドの位置は先頭または末尾から何個目の端末情報フィールドであるかを計数することで判断してもよいし、端末情報フィールドの位置を示す番号を設定するフィールドが端末情報フィールドに存在するときは、当該フィールドの値から判断してもよい。

本例では端末１〜４がトリガーフレーム５０１を受信し、自端末が指定されていると判断する。端末１〜４は、アップリンク送信用のデータを含むデータフレーム５１１、５１２、５１３、５１４（より詳細には当該データフレームを含むパケット）を生成して、自端末に指定されたリソースユニットで、アクセスポイントに送信する。送信電力、ＭＣＳ、パケット長などのパラメータを指定されている場合、当該パラメータにしたがって、データフレームを生成および送信する。例えば、端末１はリソースユニット＃１、端末２はリソースユニット＃２、端末３はリソースユニット＃３、端末４はリソースユニット＃４を指定されている。また、パケット長が指定されている場合、必要に応じてＰａｄｄｉｎｇを行い、指定されたパケット長に調整してもよい。

各データフレームの送信は、端末１〜４によるトリガーフレーム５０１の受信完了から時間Ｔ１後に行われ、これらのデータフレームは、アクセスポイントで同時に受信される。これによりＵＬ−ＯＦＤＭＡ送信が行われる。時間Ｔ１は、一例として、予め定義されたＩＦＳ時間［μｓ］を用いることができる。予め定義されたＩＦＳ時間は、ＩＥＥＥ８０２．１１無線ＬＡＮのＭＡＣプロトコル仕様で規定されているフレーム間のタイムインターバルであるＳＩＦＳ時間（＝１６μｓ）でもよいし、これより大きな値または小さな値でもよい。時間Ｔ１の値が制御フィールドまたは端末情報フィールドまたはこれらの両方に格納されており、端末１〜４は制御フィールドまたは端末情報フィールドまたはこれらの両方から時間Ｔ１の値を取得してもよい。その他、時間Ｔ１は、ビーコンフレームあるいはその他の管理フレームなど、別の方法で事前に通知されてもよい。

アクセスポイントが端末１〜４の送信タイミングの調整量をトリガーフレームの端末情報フィールドまたは制御フィールドで通知している場合は、端末１〜４は通知された調整量だけ送信タイミングを調整してデータフレームを送信してもよい。

なお、端末１〜４が送信するデータフレーム５１１、５１２、５１３、５１４は、異なる内容のフレームであっても、同一の内容のフレームでもよい。一般的な表現として、複数の端末が第Ｘのフレームを送信またはアクセスポイントが複数の第Ｘフレームを受信すると表現するとき、これらの第Ｘのフレームの内容は同じであっても、異なってもよい。

なお、端末が、アップリンク送信するデータがない場合、その端末は、予め定めた形式のフレーム、例えば物理ヘッダは存在するもののデータフィールドが存在しないパケット、物理ヘッダおよびＭＡＣヘッダは存在するもののフレームボディフィールドが存在しないフレームを送信してもよい。あるいは、その端末は、送信動作は何も行わないようにしてもよい。アクセスポイントでは、このようなパケットまたはフレームを受信した場合、または何も受信しなかった場合、当該端末は送信すべきデータが存在しなかったと判断してもよい。

アクセスポイントは、端末１〜４からＯＦＤＭＡで送信されるデータフレーム５１１〜５１４（より詳細にはデータフレームを含む物理パケット）を受信する。アクセスポイントは、データフレーム５１１〜５１４を、端末１〜４に指定したリソースユニットで、それぞれ受信する。その他のリソースユニットでは、どの端末からもデータフレームの送信は行わない。なお、変形例として、アクセスポイントでどの端末１〜４にも指定されていないリソースユニットが存在すると判断できる状況の場合に、端末１〜４またはこれらとは別のＯＦＤＭＡ対応端末が、当該指定されていないリソースユニットを利用して、データフレームをアップリンク送信する構成も考えられる。この場合、複数の端末から同じリソースユニットで送信された場合はアクセスポイント側で信号が衝突するため受信エラーとなる可能性がある。

アクセスポイント１１は、ＵＬ−ＯＦＤＭＡ送信された複数の端末からのデータフレームを受信すると、各受信したデータフレームのＣＲＣ（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｏｄｅ）を検査する。これにより、各端末が送信したデータフレームを、正しく受信できたか否かを判断する。アクセスポイント１１は、各端末に対する検査の結果に基づき、これらの端末に対する検査結果を含む送達確認応答フレームを生成する。アクセスポイントは、各データフレームの受信から一定時間Ｔ２後に、送達確認応答フレーム５２１（より詳細には送達確認応答フレームを含む物理パケット）を端末１〜４に送信する。一定時間Ｔ２は、一例として、ＩＥＥＥ８０２．１１無線ＬＡＮのＭＡＣプロトコル仕様で規定されているフレーム間のタイムインターバルであるＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒ−ｆｒａｍｅ Ｓｐａｃｅ）時間（＝１６μｓ）または、その他の事前に定義した時間（ＩＦＳ）を用いることができる。あるいは、Ｔ２の値を、トリガーフレーム５０１の制御フィールドもしくは別のフレームを利用して予め各端末に通知してもよい。各端末は、送達確認応答フレーム５２１で自端末の検査結果を確認することで、自端末が送信したデータフレームがアクセスポイントで正しく受信されたかを把握する。検査結果が失敗を示す場合は、各端末は、必要に応じてデータフレームの再送を行う。データフレームの再送は、ＣＳＭＡ／ＣＡに従って獲得した無線媒体へのアクセス権に基づき、シングルユーザ送信で行ってもよいし、次回のＵＬ−ＯＦＤＭＡで送信してもよい。

ここで、送達確認応答フレーム５２１は、本実施形態の特徴の１つとなるフレームであり、グループＡＣＫ（Ｇ−ＡＣＫ）フレームと呼ぶことがある。Ｇ−ＡＣＫフレームを利用することで、端末１〜４への送達確認応答を効率的に行うことができる。Ｇ−ＡＣＫフレーム５２１は、一例として、レガシー端末も受信可能な２０ＭＨｚチャネル幅（プライマリチャネルなど）で送信する。レガシー端末でもＧ−ＡＣＫフレーム５２１が正常に受信できるため、Ｇ−ＡＣＫフレーム５２１の送信完了後に、ＯＦＤＭＡ対応端末とレガシー端末が無線媒体へのアクセス権の獲得しようとする場合において、これらの端末間で不公平が生じるのを防止できる。すなわち、バックオフ前に行うキャリアセンスの一定時間として、ＯＦＤＭＡ対応端末とレガシー端末のいずれも、ＤＩＦＳもしくはＡＩＦＳ時間を起動するため（レガシー端末でこれらより長いＥＩＦＳ時間が起動されない）、チャネルアクセスの際、これらの端末間で不公平は生じない。

図１２に、送達確認応答フレーム（Ｇ−ＡＣＫフレーム）５２１のフォーマット例を示す。Ｇ−ＡＣＫフレーム５２１は、図５に示した一般的なＭＡＣフレームのフォーマットをベースに定義される。Ｇ−ＡＣＫフレームのヘッダまたはフレームボディフィールドは、ＧＡ Ｃｏｎｔｒｏｌフィールドと、ビットマップ（Ｂｉｔｍａｐ）フィールドと新たに備える。

Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプは制御フレームを表す値とし、サブタイプの値は、Ｇ−ＡＣＫフレーム用に新規に定義した値とすればよい。ただし、Ｇ−ＡＣＫのフレームタイプは、制御フレームではなく、管理フレームまたはデータフレームとする構成も排除されない。また、サブタイプの値も、既存の規格の値を流用してもよい。例えば、通常のＡＣＫフレームと同じサブタイプの値を用いてもよい。この場合、ＵＬ−ＯＦＤＭＡを行った端末が受信する、サブタイプがＡＣＫの送達確認応答フレームはＧ−ＡＣＫフレームであるとのルールを定めておけばよい。

Ａｄｄｒｅｓｓ１フィールド（ＲＡフィールド）には、ブロードキャストアドレスまたはマルチキャストアドレスを設定する。または、Ａｄｄｒｅｓｓ１フィールドには、ＵＬ−ＯＦＤＭＡの対象として指定した端末のうちの１つの端末のＭＡＣアドレス（ユニキャストアドレス）を設定する方法も可能である。この場合、トリガーフレームを受信した端末は、トリガーフレームで指定された他の端末の識別情報を記憶しておき、このＡｄｄｒｅｓｓ１フィールドに自端末ではないが、当該他の端末のＭＡＣアドレスが設定されている場合は、このＧ−ＡＣＫフレームは自端末宛でもあると解釈すればよい。あるいは、ＵＬ−ＯＦＤＭＡでデータフレームを送信後、一定時間Ｔ２後にＧ−ＡＣＫフレームを受信した場合には、Ａｄｄｒｅｓｓ１フィールドの宛先に関わらず、自端末宛ての検査結果を含むＧ−ＡＣＫフレームと解釈してもよい。Ａｄｄｒｅｓｓ２フィールドには、送信元であるアクセスポイントのＭＡＣアドレスまたはＢＳＳＩＤが設定される。Ｄｕｒａｔｉｏｎ／ＩＤフィールドおよびＦＣＳフィールド等、他のフィールドは図５で説明した通りであるため、説明を省略する。なお、図１２に示したフィールドの一部のフィールドが存在しなくてもよい。例えばＡｄｄｒｅｓｓ２フィールドが存在しない構成もあり得る。

ＧＡ Ｃｏｎｔｒｏｌフィールドは、送達確認応答の送信対象となる端末に共通に通知する情報、または個別に通知する情報、またはこれらの両方を設定する。例えば、ビットマップフィールド長を表す情報を設定してもよい。また、後述するように、各端末に、ビットマップフィールドに設定されるビットマップのどのビットが各端末のＣＲＣ結果に対応するかの情報を設定してもよい。ビットマップフィールド長が、各端末で既知である場合など、ＧＡ Ｃｏｎｔｏｌフィールドを省略する構成も可能である。

ビットマップフィールドには、ＵＬ−ＯＦＤＭＡにより複数の端末から受信したデータフレームのＦＣＳ検査結果（ＣＲＣ結果）を１ビットで表したビットマップを設定する。ＣＲＣ＝ＯＫ（受信成功）の場合には“１”、ＣＲＣ＝ＮＧ（受信失敗）の場合には“０”で表す。“１”と“０”は逆でもよい。１つの端末が１つのデータフレームを送信する場合を想定し、ビットマップフィールドとして最低限必要なビット長は、ＵＬ−ＯＦＤＭＡで送信を行った端末数である。図６のシーケンス例では、４台の端末からＵＬ−ＯＦＤＭＡにて送信が行われるため、最低限、４ビットが必要である。

ビットマップフィールド長は、ＵＬ−ＯＦＤＭＡ多重数に応じて可変であってもよいし、固定であってもよい。固定の場合には、例えばビットマップフィールドのビットサイズは、ＵＬ−ＯＦＤＭＡ送信で利用可能なリソースユニット数（または最大端末数）と同じとする。この場合、利用可能な最大リソースユニット数（または最大端末数）から、ＵＬ−ＯＦＤＭＡ送信で利用したリソースユニット数（または端末数）を減じた値と等しいビット数は、ビットマップフィールド内でリザーブのビット扱いとなる。

ビットマップフィールド長がバイト単位になるように、最低限必要なビット数に応じて、８ビット単位でフィールド長を切り上げてもよい。例えば、最低限必要なビット数が４ビットの場合、ビットマップフィールドの長さは、８ビット（１バイト）になる。この場合、最低限必要なビットに付加されたビット数（４ビット）は、リザーブのビット扱いとなる。

なお、各端末はトリガーフレームで、ＵＬ−ＯＦＤＭＡを許可されたリソースユニット数（または端末数）を把握可能であるため、ビットマップフィールド長が可変の場合、あるいはバイト単位である場合も、各端末はビットマップフィールド長を把握できる。またビットマップフィールド長は、ＧＡ Ｃｏｎｔｒｏｌフィールドから把握してもよい。

ＵＬ−ＯＦＤＭＡで各端末が送信したデータフレームと、ビットマップフィールドに設定されるビットマップのビット位置との対応関係について説明する。

（第１の例）トリガーフレームにおける端末情報フィールドの位置と、ビットマップフィールドのビット位置とを対応づける。例えば、トリガーフレームに端末情報フィールド１、端末情報フィールド２、端末情報フィールド３、端末情報フィールド４がこの順で設けられている。端末情報フィールド１〜４に、それぞれ端末１、端末２、端末３、端末４の識別情報（ＡＩＤまたはＡＩＤの一部（ｐａｒｔｉａｌ ＡＩＤ）等）が設定されている。この場合、ビットマップフィールドのビットマップの最下位ビットから順に、端末１が送信したデータフレームのＣＲＣ結果、端末２が送信したデータフレームのＣＲＣ結果、端末３が送信したデータフレームのＣＲＣ結果、端末４が送信したデータフレームのＣＲＣ結果を反映させる。例えば、端末１〜４が送信したデータフレームのＣＲＣ結果がそれぞれＯＫ、ＮＧ、ＮＧ、ＯＫだった場合には、ビットマップは、最下位ビットから順に“１”、“０”、“０”、“１”と表される。端末情報フィールド１〜４に、それぞれ順に端末３、端末２、端末４、端末１の識別情報が設定されていた場合には、ビットマップの最下位ビットから順に、端末３、端末２、端末４、端末１がそれぞれ送信したデータフレームのＣＲＣ結果を反映させる。

ここでは、最下位ビットから順にＣＲＣ結果を反映させたが、最上位ビットから順に反映させてもよい。また、最下位ビットまたは最上位ビット以外の所定ビットから、下位ビットまたは上位ビット方向に、各端末のＣＲＣ結果を順に反映させてもかまわない。この場合、最上位ビットと最下位ビットが連続しているとみなせばよい。ここで述べた方法以外にも、各端末情報フィールドと、ビットマップのビット位置との対応が一意に定まる限り、任意の方法を用いることができる。これによりＵＬ−ＯＦＤＭＡを行った各端末は、自端末の識別情報が設定された端末情報フィールドの位置に応じて、ビットマップにおける自端末のビットを特定できる。

また端末情報フィールドに端末情報フィールドを識別する番号（端末情報フィールド番号）が設定されている場合、当該番号と、ビットマップのビット位置とを対応づけるようにしてもよい。

このように、各端末は、トリガーフレームを受信することで、自端末がＵＬ−ＯＦＤＭＡの対象として選択されたことを把握すると共に、自端末が複数の端末情報フィールドのうちのどの端末情報フィールドで通知されたかを把握する。これにより、各端末は、Ｇ−ＡＣＫフレームに設定されたビットマップにおいて、自端末が送信したデータフレームに対するＣＲＣ結果が、ビットマップのどのビット位置に対応しているかを、Ｇ−ＡＣＫフレーム内に各端末のビット位置を特定するための情報を含む特別なフィールドを含まなくても把握することができる。

（第２の例）リソースユニット番号（ＲＵ＃）を、ビットマップのビットに対応づける。例えばリソースユニット１〜ｎがＵＬ−ＯＦＤＭＡで使用され得る場合に、リソースユニット１〜ｎを、ビットマップの最下位ビット（または最上位ビット）から順番に対応づける。この場合、リソースユニット１を指定された端末は、リソースユニット１に対応するビット位置で、自端末が送信したデータフレームのＣＲＣ結果を確認すればよい。複数のリソースユニットを割り当てられ、複数のデータフレームをそれぞれ異なるリソースユニットで送信した場合も、各リソースユニットに対応するビット位置で、各データフレームのＣＲＣ結果を確認すればよい。

また、複数のリソースユニットを割り当てられ、１つのデータフレームを、割り当てられた複数のリソースユニットに跨って送信する場合には、割り当てられた複数のリソースユニットに対応する全てのビット位置で同一のＣＲＣ結果を反映してもよいし、いずれのビット位置のみに反映させてもよい。もしくは、ビットマップフィールド長がリソースユニット数ではなく、送信端末数に対応している場合には、各端末の最も小さい（または大きい）リソースユニットの順番で、ビットマップの最下位ビット（または最上位ビット）から、各端末のＣＲＣ結果を対応づけるようになっていてもよい。例えば、ＵＬ−ＯＦＤＭＡとして端末１、２、３、４を指定し、各端末に対する割当てリソースユニットがそれぞれＲＵ＃２とＲＵ＃３、ＲＵ＃１とＲＵ＃８、ＲＵ＃５とＲＵ＃６、ＲＵ＃４とＲＵ＃７であった場合、ビットマップ（ビットマップフィールド長４ビット）のビット位置は、最下位ビットからそれぞれ端末２、端末１、端末４、端末３の順番に対応づけられる。

第２の例の場合も、第１の例の場合と同様、Ｇ−ＡＣＫフレーム内に各端末のビット位置を特定するための情報を含む特別なフィールドを含まなくても把握することが可能となり、必要以上のオーバーヘッドは生じない。

（第３の例）ビットマップにおける各端末のＣＲＣ結果の位置を、トリガーフレームにおける共通情報フィールドあるいは各端末情報フィールド、あるいはこれらの両方で指定する。あるいは、各端末のＣＲＣ結果の位置を、Ｇ−ＡＣＫフレームにおけるＧＡ Ｃｏｎｔｒｏｌフィールドで指定する。例えば端末１はビットマップの最下位ビット、端末２は最下位ビットから３ビット目などのように指定することも可能である。なお、この場合、ビットマップにおける各端末のビット位置と、各端末の識別情報が設定された端末情報フィールドの位置は必ずしも関連性はない。

（第４の例）トリガーフレームにおいてグループＩＤ等のグループ識別情報によりＵＬ−ＯＦＤＭＡの対象端末を指定した場合、以下のようにして各端末のＣＲＣ結果と、ビットマップのビット位置とを対応づける。

アクセスポイントからグルーピングの結果として、各端末に送信した各グループのリストには、グループに属する端末の識別情報（ＡＩＤまたはその一部等）が順番に配置されているとする。各端末の順位に応じて（例えば先頭から順番に）、各端末に、ビットマップ内の最下位ビットから順番にビットを割り当てる。つまり、図１３に示すように、グループごとに、リストで各端末が列挙された順に応じて、各端末に順位を設定し、この順位に応じてビットマップのビットを各端末に割り当てる。このルールは各端末でも共通に認識されている。例えば、グループ番号１の場合は、端末１、２、３のＣＲＣ結果を、ビットマップ内の最下位ビットから順番に割り当てる。つまり、順位１の端末のＣＲＣ結果を最下位ビットに、順位２の端末のＣＴＣ結果を最下位ビットから２ビット目に、順位３の端末のＣＲＣ結果を最下位ビットから３ビット目に割り当てる。グループ番号２の場合も同様にして端末２、３、４のＣＲＣ結果をビットマップに割り当てる。この例では、最下位ビットから順番に割り当てる例を示したが、最上位ビットから順番に割り当ててもよいし、これら以外のビットを起点として割り当てを行ってもよい。

上述した例では、端末から１つのデータフレームを送信する場合を主に想定したが、端末が複数のリソースユニットを割り当てられ、各リソースユニットでそれぞれ別々のデータフレームを送信する場合も考えられる。この場合も、第２の例で前述したように、各データフレームのＣＲＣ結果を特定できる。その他の場合では、制御フィールドまたは端末情報フィールドで、各端末が自端末の複数のビット位置を特定するための情報を設定してもよい。ビット位置を特定可能な限り、端末に割り当てる複数のビットは連続していても、連続していなくてもよい。また各端末が利用するリソースユニット数が把握できる場合は、これまで述べた例と同様にして実施可能である。例えば、端末１〜ｎにそれぞれ連続する複数のビットを、ビットマップの最下位または最上位から順番に割り当てるようにしてもよい。同じ端末に割り当てた複数のビットと、当該端末が送信した複数のデータフレームとの対応関係は、各データフレームを送信したリソースユニット番号に応じて対応づければよい。例えばリソースユニット番号の小さい（または大きい）データフレームから順番に、割り当てた複数のビットの先頭または末尾から順番にＣＲＣ結果を割り当てるようにしてもよい。別の方法で、当該対応関係を把握する構成にしてもよい。

アクセスポイントによる送達確認応答フレーム（Ｇ−ＡＣＫフレーム）５２１の送信後、トリガーフレームの送信から再度同様のシーケンスが繰り返し行われてもよいし、別のシーケンスが行われてもよい

上述した実施形態では、トリガーフレームで各端末にＵＬ−ＯＦＤＭＡで使用するリソースユニットを指定したが、事前に各端末が使用するリソースユニットが決まっている場合は、トリガーフレームでリソースユニットの指定を省略してもよい。

またトリガーフレームの制御フィールドまたは各端末情報フィールドまたはこれらの両方で、各端末にランダムにリソースユニットを選択することを指示する情報を設定し、各端末が自端末で使用するリソースユニットをランダムに選択してもよい。選択可能なリソースユニットの範囲は、トリガーフレームの制御フィールドまたは各端末情報フィールドまたはこれらの両方で通知してもよいし、トリガーフレームの送信前に任意または専用のフレームで通知してもよいし、システムまたは仕様で決められていても良い。トリガーフレームで指定された複数の端末間で、選択するリソースユニットが重複しなければ、各端末が送信するデータフレームはアクセスポイントで正常に受信され、前述した方法を用いてＧ−ＡＣＫフレームを生成することが可能である。一部の端末で、選択するリソースユニットが重複し、これらの端末が送信したデータフレームに対しアクセスポイントで受信エラーが検出された場合は、当該端末を指定した端末情報フィールドに対応するビットマップ内のビット位置にＣＲＣ結果として失敗を示す値を設定すればよい。変形例として、一部の端末には使用するリソースユニットを指定し、残りの端末にはランダムでリソースユニットを選択させてもよい。ランダムに選択させる際、当該一部の端末に指定したリソースユニットを除くリソースユニット範囲で選択させるようにしてもよい。

上述したＧ−ＡＣＫフレームの説明では、各端末から送信するデータフレームは単体のフレーム（アグリゲートされていないフレーム）であったが、各端末から送信するフレームは、複数のデータフレームを含むアグリゲーションフレームでもよい。この場合、各端末には、アグリゲーションフレームに含まれている複数のデータフレームのそれぞれのＣＲＣ結果を通知する必要がある。なお、アグリゲーションフレームに含まれるデータフレーム数は複数でなく、１つの場合も可能である。またアグリゲートされるフレームはデータフレームに限定されず、管理フレームまたは制御フレームでもよいし、これら複数種類のフレームの組み合わせでもよい。以下ではデータフレームを想定して説明する。各端末からアグリゲーションフレームがＵＬ−ＯＦＤＭＡで送信された場合に、各端末の複数のＣＲＣ結果をすべて含むことが可能な送達確認応答フレーム（Ｇ−ＡＣＫフレーム）のフォーマット例を図１４に示す。

図１４のＧ−ＡＣＫフレームは、Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールド、Ｄｕｒａｔｉｏｎ／ＩＤフィールド、Ａｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２、ＦＣＳフィールドの他に、ＵＬ−ＯＦＤＭＡで指定する端末数分のビットマップフィールドを備える。また、各ビットマップフィールドに対応して、開始シーケンス番号（Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）フィールドを備える。図６のシーケンス例では４台の端末が指定されたため、４つのビットマップフィールドと、これらに対応する４つの開始シーケンス番号フィールドが存在する。ビットマップフィールドは、ビットマップフィールドに対応する端末が送信したアグリゲーションフレーム内の各データフレームのＣＲＣ結果を特定するためのビットマップを含む。なお、図１４に示したフィールドの一部のフィールドが存在しなくてもよい。例えばＡｄｄｒｅｓｓ２フィールドが存在しない構成もあり得る。

各ビットマップフィールドが、いずれの端末が送信したアグリゲーションフレーム内の複数のデータフレームのＣＲＣ結果を反映しているかは、図１２のＧ−ＡＣＫフレームの場合にビットマップのビット位置と端末のＣＲＣ結果との対応をとるのと同様にして把握できる。一例として、トリガーフレームの端末情報フィールド１〜ｎが、それぞれ順番に先頭（または末尾）のビットマップフィールドから順番に対応づけられており、端末情報フィールド１〜ｎで指定された端末は、先頭から順番にビットマップフィールド１〜ｎを特定してもよい。またはトリガーフレームの制御フィールドまたは端末情報フィールドまたはこれらの両方で、各端末に対するビットマップフィールドの位置を具体的に特定してもよい。またリソースユニット番号にビットマップフィールドの位置を対応付け、各端末は、使用したリソースユニット番号に対応するビットマップフィールドを特定してもよい。この場合、端末が複数のリソースユニットを割り当てられ、リソースユニットごとにアグリゲーションフレームを送信する場合、端末は、割り当てられた複数のリソースユニットに対応づけられた複数のビットマップフィールドを特定してもよい。ここで述べた以外の方法で、各端末は自端末に関連するビットマップフィールドを特定してもよい。

図１４のＧ−ＡＣＫフレームのビットマップフィールド数は、図１２の場合のビットマップのビット数と同様に、ＵＬ−ＯＦＤＭＡで送信可能なリソースユニット数（または最大端末数）でもよい。

各ビットマップフィールド長は、アグリゲーションフレーム内に集約可能な最大フレーム数とする。例えば、集約可能な最大フレーム数が８の場合には、各ビットマップフィールド長は８ビットとなる。なお、集約可能な最大データフレーム数は、システムまたは仕様等で、予め定められている。集約可能な最大フレーム数が端末に応じて異なる構成も可能である。この場合、端末ごとにビットマップフィールド長が異なることを許容してもよい。

開始シーケンス番号フィールドは、端末が送信したアグリゲーションフレームに含まれるデータフレームのうち、ＣＲＣ検査結果が成功のデータフレームの最小のシーケンス番号を特定する情報を設定する。シーケンス番号は、データフレームを送信する都度、インクリメントされる番号であり、図５に示したＭＡＣフレームフォーマットのＳｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌフィールド内に設定される。したがって、端末が送信するアグリゲーションフレーム内には、複数のシーケンス番号が集約されていると言える。

例えば、ＵＬ−ＯＦＤＭＡの対象として指定された端末のうちの１つが、シーケンス番号がそれぞれ３、４、５、６である４つのデータフレームを集約したアグリゲーションフレームを送信した場合を考える。アクセスポイント１１が、該アグリゲーションフレームを受信し、アグリゲーションフレームをデアグリゲート（分割）後、分割した各データフレームのＣＲＣ検査をそれぞれ行う。ＣＲＣ検査の結果、ＣＲＣ結果が成功（ＯＫ）であったデータフレームのシーケンス番号のうち、最も小さいシーケンス番号の値を、対応する開始シーケンス番号フィールドに設定する。例えば、シーケンス番号３、４、５、６のデータフレームのＣＲＣ結果がそれぞれＯＫ、ＮＧ、ＯＫ、ＯＫだった場合には、開始シーケンス番号フィールドには、“３”が設定される。一方、シーケンス番号３、４、５、６のデータフレームのＣＲＣ結果がそれぞれＮＧ、ＮＧ、ＯＫ、ＯＫだった場合には、開始シーケンス番号フィールドには、“５”が設定される。

アクセスポイントは、開始シーケンス番号フィールドに設定した値（最小シーケンス番号）を、対応するビットマップフィールドの開始ビットに対応させ、当該最小シーケンス番号のデータフレームのＣＲＣ結果を、当該開始ビットに反映させる。開始ビットの次以降のビットは、最小シーケンス番号の次のシーケンス番号を起点として順次１ずつ増えたシーケンス番号のＣＲＣ結果を反映させる。すなわち、ビットマップのビット位置ｎのビットには、（開始シーケンス番号＋ｎ）のシーケンス番号のデータフレームのＣＲＣ結果を反映させる。ビットマップの開始ビット（例えば先頭ビット）はビット位置０とする。すなわち、位置０のビットが、開始シーケンス番号のＣＲＣ結果に対応する。

例えば、ビットマップフィールド長が８ビットであり、シーケンス番号３、４、５、６のＣＲＣ結果がそれぞれＯＫ、ＮＧ、ＯＫ、ＯＫだった場合には、開始シーケンス番号フィールドには“３”が設定される。ビットマップフィールドは、シーケンス番号３と５と６のビット位置に対応するビットが“１”となるため、１０１１００００となる。

一方、シーケンス番号＝３、４、５、６のＣＲＣ結果がそれぞれＮＧ、ＮＧ、ＯＫ、ＯＫだった場合には、開始シーケンス番号フィールドには、“５”が設定される。ビットマップフィールドは、シーケンス番号５と６のビット位置に対応するビットが“１”となるため、１１００００００となる。

なお、データフレームの欠落によりアクセスポイントに受信されなかった（届かなかった）データフレームについてはＣＲＣ結果をＮＧとして扱えばよい。

このように、ビットマップ内のビット位置とシーケンス番号との関係は、開始シーケンス番号フィールドに設定された値（最小シーケンス番号）に依存する。すなわち、開始シーケンス番号フィールドの値により、ビットマップの各ビット位置に該当するシーケンス番号を特定できる。

Ｇ−ＡＣＫフレームを受信した端末は、Ｇ−ＡＣＫフレーム内の複数のビットマップフィールドのうち、自端末用のビットマップフィールド位置を、上述した方法によって特定する。そして、端末は、自端末に対応する開始シーケンス番号フィールドに設定された値と、ビットマップフィールドに設定されたビットマップとから、アグリゲーションフレームで送信した複数のデータフレームのそれぞれのＣＲＣ結果を把握する。

例えば、シーケンス番号３、４、５、６の４つのデータフレームを集約したアグリゲーションフレームを送信した場合に、Ｇ−ＡＣＫフレーム内の開始シーケンス番号フィールドに“５”が設定されていた場合には、シーケンス番号５より小さいシーケンス番号３、４のＣＲＣ結果は失敗であったと判断する。シーケンス番号５、６のＣＲＣ結果は、ビットマップの開始ビットおよびその次のビットを確認することで把握できる。

なお、開始シーケンス番号フィールドに設定されたシーケンス番号のデータフレームはビットマップの開始を参照するまでもなくＣＲＣ結果が成功であることが分かるため、ビットマップの開始ビットの確認は省略してもよい。このため、変形例として、ビットマップの開始ビット以降のビットに、ＣＲＣ結果が成功した最小シーケンス番号の次のシーケンス番号以降のデータフレームのＣＲＣ結果を反映させるようにしてもよい。

端末は、ＣＲＣ結果が失敗であったデータフレーム（アクセスポイントにより正常に受信できていなかたことが確認されたデータフレーム）に関しては、必要に応じて、当該データフレームの再送を行えばよい。

図１５に、図１４のＧ−ＡＣＫフレームフォーマットにＧＡ Ｃｏｎｔｒｏｌフィールドを追加した例を示す。ＧＡ Ｃｏｎｔｒｏｌフィールドを利用して、各端末に共通する、または個別の情報を通知してもよい。例えば、開始シーケンス番号フィールドの個数またはビットマップフィールドの個数またはこれらの両方を通知してもよい。また、開始シーケンス番号フィールド長またはビットマップフィールド長を通知してもよい。これによりビットマップフィールド長が可変の場合にも、各端末はビットマップフィールドを特定できる。ビットマップフィールド長は各端末で共通でもよいし、端末ごとに決めても良い。

また端末から受信したアグリゲーションフレーム内の複数のデータフレームのＣＲＣ結果がすべて失敗（ＮＧ）であった場合や、端末からアグリゲーションフレームを受信しなかった場合などは、その旨のみを通知し、その端末については開始シーケンス番号フィールドおよびビットマップフィールドの組をＧ−ＡＣＫフレームに設けないようにすることも可能である。これよりＧ−ＡＣＫフレーム長を節約できる。これを実現するための仕組みとして、ＧＡ Ｇｏｎｔｒｏｌフィールドを利用してもよい。各端末に、開始シーケンス番号フィールドおよびビットマップフィールドの組の有無を通知してもよい。

例えば、ＧＡ Ｃｏｎｔｒｏｌフィールドに、各端末に開始シーケンス番号フィールドおよびビットマップフィールドの組の有無を通知するビット列を設定する。ビット列のどのビットにどの端末への通知が反映されるかは、図１２のＧ−ＡＣＫフレームのビットマップと同様の仕組みで実現すればよい。

例えばビット列が１バイトの場合で、ビット列として、“１０１１００００”が設定されていたとする。先頭ビットから順番に端末１、２、３、４が対応するとする（残りの後ろ側の４ビットはリザーブビットである）。この場合、端末１、３、４に対しては、開始シーケンス番号フィールドおよびビットマップフィールドの組が設定されているが、端末２に対しては設定されていないことを意味する。この場合、端末２の動作としては、ＧＡ Ｃｏｎｔｒｏｌフィールドに設定されたビット列の自端末のビットの値を調べて、当該組が設定されていないことを把握したら、自端末が送信したアグリゲーションフレーム内の複数のデータフレームのＣＲＣ結果はすべて失敗であった（またはアグリゲーションフレームがアクセスポイントに届かなかった）と判断する。これにより、Ｇ−ＡＣＫフレーム長を短くできるとともに、開始シーケンス番号フィールドおよびビットマップフィールドの組の値を調べる動作を不要にできる利点がある。

一方、端末１、３、４については、ビット列の自端末のビットの値を調べて、上記組が設定されてことを把握したら（ビット値が１であることを確認したら）、自端末用の開始シーケンス番号フィールドおよびビットマップフィールドを特定する。例えば、ビット列において先頭からビット値が１になっている箇所を全て調べ、自端末のビット値１が先頭ビットから数えて何番目の１かを特定し、先頭（または末尾等）から数えて、当該特定した番号の位置に配置されている、開始シーケンス番号フィールドおよびビットマップフィールドの組を、自端末用として特定する。

なお、ビット列における自端末用のビット位置、および自端末用の開始シーケンス番号フィールドおよびビットマップフィールド位置を特定する方法は、ここで述べた方法以外にも、これまで説明してきた種々の方法と同様の方法を適用して可能な方法であれば、何でもかまわない。

図１６は、アクセスポイント１１に搭載される無線通信装置の機能ブロック図である。アクセスポイント１１は、端末１〜４側のネットワークに接続され、さらに別のネットワークに接続されてもよい。図１６では、端末１〜４側のネットワークに接続される無線通信装置の構成を示している。

無線通信装置は、制御部１０１と、送信部１０２と、受信部１０３と、アンテナ１２Ａ、１２Ｂ、１２Ｃ、１２Ｄと、バッファ１０４とを備えている。アンテナの個数はここでは４つであるが、少なくとも１つのアンテナを備えていればよい。制御部１０１は、端末との通信を制御する通信制御装置に対応し、送信部１０２と受信部１０３は、フレームを送受信する無線通信部を形成する。制御部１０１の処理、および送信部１０２と受信部１０３のデジタル領域の処理の全部または一部は、ＣＰＵ等のプロセッサで動作するソフトウェア（プログラム）によって行われてもよいし、ハードウェアによって行われてもよいし、これらのソフトウェアとハードウェアの両方によって行われてもよい。アクセスポイントは、制御部１０１、送信部１０２および受信部１０３の全部または一部の処理を行うプロセッサを備えてもよい。

バッファ１０４は、上位層と制御部１０１との間で、フレーム等を受け渡しするための記憶部である。バッファ１０４はＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。上位層は、別のネットワークから受信したフレームを第１のネットワークへの中継のためバッファ１０４に格納してもよい。また、端末側のネットワークから受信したフレームまたはそのペイロードを、制御部１０１からバッファ１０４を介して受けとってもよい。上位層は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理を行ってもよい。または、上位層は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰ制御部１０１で行い、上位層では、それより上位のアプリケーション層の処理を行ってもよい。上位層の動作は、ＣＰＵ等のプロセッサによるソフトウェア（プログラム）の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。

制御部１０１は、主としてＭＡＣ層の処理、物理層の処理の一部（例えばＯＦＤＭＡ関連の処理等）を行う。制御部１０１は、送信部１０２および受信部１０３を介して、フレームを送受信することで、各端末との通信を制御する。また制御部１０１は、定期的にアクセスポイントのＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）の属性および同期情報等を通知するため、ビーコンフレームを送信するよう制御してもよい。また、制御部１０１は、クロックを生成するクロック生成部を含み、クロック生成部で生成するクロックを利用して、内部時間を管理してもよい。制御部１０１は、クロック生成部で作ったクロックを、外部に出力してもよい。あるいは、制御部１０１は、外部のクロック生成部で生成してクロックの入力を受け、当該クロックを利用して、内部時間を管理してもよい。

制御部１０１は、端末からのアソシエーション要求を受けて、アソシエーションプロセスを行い、お互いの能力・属性等の必要な情報（ＯＦＤＭＡを実施可能か否かの能力情報を含んでもよい）を交換することで、当該端末と無線リンクを確立する。必要に応じて、事前に端末との間で認証プロセスを行ってもよい。制御部１０１は、バッファ１０４を定期的に確認することで、バッファ１０４の状態を把握する。または、制御部１０１は、バッファ１０４等の外部からのトリガによりバッファ１０４の状態を確認する。

制御部１０１は、任意のタイミングで前述した方法により、無線リンクを確立した端末（ＯＦＤＭＡ対応端末）の中から、ＵＬ−ＯＦＤＭＡを許可する複数の端末を選択し、また各端末に利用させるリソースユニットを特定する。また、パケット長やＭＣＳ等、その他のパラメータを必要に応じて決定する。これらの詳細は前述したとおりである。なお、リソースユニットとリソースユニット番号との対応や、ＯＦＤＭＡで使用するチャネルに関する情報は、事前に端末に通知してもよいし、またはシステムまたは仕様で定まっていてもよい。トリガーフレームでこれらの一部または全部の情報を通知してもよい。制御部１０１は、選択した端末を指定する情報、リソースユニットを指定する情報、およびその他のパラメータ等を、トリガーフレームにおける制御フィールドまたは端末情報フィールドまたはこれらの両方に設定する。

制御部１０１は、生成したトリガーフレームを、例えばレガシー端末も受信可能な２０ＭＨｚチャネル幅で、送信部１０２から送信する。一例として、送信前にＣＳＭＡ／ＣＡに従って、キャリアセンスを行い、無線媒体へのアクセス権を獲得できたら、トリガーフレームを送信部１０２に出力する。送信部１０２は、入力されたトリガーフレームに符号化および変調処理、および物理ヘッダの付加など、所望の物理層の処理を行って物理パケットを生成する。また物理パケットに対して、ＤＡ変換、所望帯域成分を抽出するフィルタ処理、周波数変換（アップコンバート）等を行い、これらにより得られた信号をプリアンプで増幅して、１つまたは複数のアンテナから空間に電波として放射する。なお、アンテナ毎に送信系統を備え、送信系統毎に物理層の処理を行って、同時に同じ信号を送信してもよい。または、複数のアンテナを使って、送信の指向性を制御することも可能である。

各アンテナで受信された信号は、受信部１０３において、それぞれアンテナに対応する受信系統ごとに処理される。例えば、トリガーフレームの送信後に、トリガーフレームで指定した複数の端末からＯＦＤＭＡで返信されるデータフレームの信号が、各アンテナで同時に受信される。各受信信号は、それぞれ受信系統において低雑音増幅器（ＬＮＡ：Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）により増幅され、周波数変換（ダウンコンバート）され、フィルタリング処理で所望帯域成分が抽出される。各抽出された信号は、さらにＡＤ変換によりデジタル信号に変換されて、復調および誤り訂正復号、物理ヘッダの処理等、物理層の処理を経た後、それぞれ制御部１０１にデータフレームが入力される。ここで受信系統ごとに、対応する周波数帯域が異なってもよく、リソースユニット単位で受信系統が配置されてもよい。あるいは、各受信系統が同じ周波数帯域に対応し、これらの受信系統で受信された信号をダイバーシティ技術により合成してもよい。この場合、各リソースユニットの信号はデジタルフィルタ処理で抽出してもよい。ＯＦＤＭＡ受信を行わない場合は、１本のアンテナのみ受信部１０３に接続し、残りのアンテナは受信部１０３に接続しない構成で受信を行うことも可能である。

制御部１０１は、各端末からＵＬ−ＯＦＤＭＡで同時に受信したデータフレームのＣＲＣ検査を行い、各ＣＲＣ結果をビットマップに反映し、図１２等のフォーマットで、ビットマップを含む送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を生成する（図１２参照）。ビットマップの生成方法は前述したとおりである。受信したフレームがアグリゲーションフレームの場合は、アグリゲーションフレーム内の複数のデータフレームごとにＣＲＣ検査を行い、図１４または図１５等のフォーマットでＧ−ＡＣＫフレームを生成する。

制御部１０１は、各端末からのデータフレームの受信完了から予め定めた時間後に、Ｇ−ＡＣＫフレーム（送達確認応答フレーム）を、送信部１０２から送信するよう制御する。Ｇ−ＡＣＫフレームは、例えばレガシー端末も受信可能な２０ＭＨｚチャネル幅で、送信する。送信部１０２は、Ｇ−ＡＣＫフレームに符号化および変調処理、および物理ヘッダの付加など、所望の物理層の処理を行って物理パケットを生成する。また物理パケットに対して、ＤＡ変換、所望帯域成分を抽出するフィルタ処理、周波数変換（アップコンバート）等を行い、これらにより得られた信号をプリアンプで増幅して、１つまたは複数のアンテナから空間に電波として放射する。なお、アンテナ毎に送信系統を備え、送信系統毎に物理層の処理を行って、同時に同じ信号を送信してもよい。または、複数のアンテナを使って、送信の指向性を制御することも可能である。

なお、制御部１０１は、トリガーフレーム等で各端末に通知する情報、または各端末から通知された情報、またはこれらの両方を格納するための記憶装置にアクセスして当該情報を読み出してもよい。記憶装置は、内部メモリでも、外部メモリでもよく、揮発性メモリでも不揮発メモリでもよい。また、記憶装置は、メモリ以外に、ＳＳＤ、ハードディスク等でもよい。

上述した、制御部１０１と送信部１０２の処理の切り分けは一例であり、上述した形態とは別の形態も可能である。例えばデジタル領域の処理およびＤＡ変換までは制御部１０１で行い、ＤＡ変換より後の処理を送信部１０２で行うようにしてもよい。制御部１０１と受信部１０３の処理の切り分けも同様に、ＡＤ変換より前までの処理を受信部１０３で行い、ＡＤ変換後の処理を含むデジタル領域の処理を制御部１０１で行うようにしてもよい。一例として、本実施形態に係るベースバンド集積回路は、制御部１０１と、送信部１０２の物理層の処理を行う部分とＤＡ変換を行う部分と、受信部１０３のＡＤ変換以降の処理を行う部分とに対応し、ＲＦ集積回路は、送信部１０２のＤＡ変換より後の処理を行う部分と、受信部１０３のＡＤ変換より前の処理を行う部分に対応する。本実施形態に係る無線通信用集積回路は、ベースバンド集積回路およびＲＦ集積回路のうち、少なくともベースバンド集積回路を含む。ここで述べた以外の方法でブロック間の処理、あるいはベースバンド集積回路およびＲＦ集積回路間の処理を切り分けてもよい。

図１７は、端末に搭載される無線通信装置の機能ブロック図である。端末１〜４に搭載される無線通信装置は、いずれも図１７の構成を有する。

無線通信装置は、制御部２０１と、送信部２０２と、受信部２０３と、少なくとも１つのアンテナ１と、バッファ２０４とを備えている。制御部２０１は、アクセスポイント１１との通信を制御する通信制御装置に対応し、送信部２０２と受信部２０３は、フレームを送受信する無線通信部を形成する。制御部２０１の処理、および送信部２０２と受信部２０３のデジタル領域の処理の全部または一部は、ＣＰＵ等のプロセッサで動作するソフトウェア（プログラム）によって行われてもよいし、ハードウェアによって行われてもよいし、これらのソフトウェアとハードウェアの両方によって行われてもよい。アクセスポイントは、制御部２０１、送信部２０２および受信部２０３の全部または一部の処理を行うプロセッサを備えてもよい。

バッファ２０４は、上位層と制御部２０１との間で、フレーム等を受け渡しするための記憶部である。バッファ２０４はＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。上位層は、他の端末、アクセスポイント１１、またはサーバ等の他のネットワーク上の装置に送信するフレームを生成して、バッファ２０４に格納したり、当該端末、アクセスポイントまたは装置等から受信したフレームを制御部２０１からバッファ２０４を介して受け取ったりする。上位層は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理を行ってもよい。また、ＴＣＰ／ＩＰやＵＤＰ／ＩＰは制御部２０１で処理し、上位層は、これより上位のアプリケーション層の処理を行ってもよい。上位層の動作は、ＣＰＵ等のプロセッサによるソフトウェア（プログラム）の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。

制御部２０１は、主としてＭＡＣ層の処理を行う。制御部２０１は、送信部２０２および受信部２０３を介して、アクセスポイント１１とフレームを送受信することで、アクセスポイント１１との通信を制御する。また、制御部２０１は、クロックを生成するクロック生成部を含み、クロック生成部で生成するクロックを利用して、内部時間を管理してもよい。制御部２０１は、クロック生成部で作ったクロックを、外部に出力してもよい。あるいは、制御部２０１は、外部のクロック生成部で生成してクロックの入力を受け、当該クロックを利用して、内部時間を管理してもよい。

制御部２０１は、一例としてビーコンフレームを受信してアクセスポイント１１のＢＳＳの属性および同期情報を把握した後、アクセスポイント１１にアソシエーション要求を行ってアソシエーションプロセスを行う。これにより、お互いの能力・属性等の必要な情報（ＯＦＤＭＡを実施可能か否かの能力情報を含んでもよい）を交換することで、当該アクセスポイント１１と無線リンクを確立する。必要に応じて、事前に端末との間で認証プロセスを行ってもよい。制御部２０１は、バッファ２０４を定期的に確認することで、バッファ２０４の状態を把握する。または、制御部２０１は、バッファ２０４等の外部からのトリガによりバッファ２０４の状態を確認する。制御部２０１は、アクセスポイント１１へ送信するデータフレーム等のフレームの存在を確認したら、当該フレームを読み出して、送信部２０２およびアンテナ１を介して送信してもよい。

送信部２０２は、制御部２０１から入力されたフレームに符号化および変調処理、および物理ヘッダの付加など、所望の物理層の処理を行って物理パケットを生成する。また、物理パケットに対して、ＤＡ変換や、所望帯域成分を抽出するフィルタ処理、周波数変換（アップコンバート）等を行い、これらにより得られた信号をプリアンプで増幅して、１つまたは複数のアンテナから空間に電波として放射する。なお、複数のアンテナを備える場合、アンテナ毎に送信系統を備え、送信系統毎に物理層の処理を行って、同時に同じ信号を送信してもよい。または、複数のアンテナを使って、送信の指向性を制御することも可能である。

アンテナ１で受信された信号は、受信部２０３において処理される。受信された信号は、受信部２０３においてＬＮＡにより増幅され、周波数変換（ダウンコンバート）され、ファイルタリング処理で所望帯域成分が抽出される。抽出された信号は、さらにＡＤ変換によりデジタル信号に変換されて、復調および誤り訂正復号、物理ヘッダの処理等の物理層の処理を経た後、制御部２０１にデータフレーム等のフレームが入力される。

制御部２０１は、アクセスポイント１１からトリガーフレームが受信された場合、トリガーフレームにおいて自端末がＵＬ−ＯＦＤＭＡの対象として指定されているかを確認する。確認の方法は、前述したように、自端末の識別情報がいずれかの端末情報フィールドまたは制御フィールドに格納されているかで確認してもよい。または、制御フィールドでグループＩＤが指定されている場合に、グループＩＤに属するすべての端末がＯＦＤＭＡの対象端末とのルールがある場合は、当該グループＩＤに属するかで、自端末が指定されているかを判断してもよい。なお、この場合、端末は、アクセスポイント１１から、グループ毎に端末のリストを格納したグルーピング情報を取得しておく。

制御部２０１は、自端末がＵＬ−ＯＦＤＭＡの対象として指定されている場合は、必要に応じて、自端末が利用するリソースユニットおよびその他のパラメータの情報を、制御フィールドまたは端末情報フィールドまたはこれらの両方から取得する。制御部２０１は、当該パラメータに従って、バッファ２０４に格納されているデータフレームを読み出して、トリガーフレームの受信から予め定めた時間後にアクセスポイント１１に送信するように制御する。読み出すデータフレームの例として、例えばパケット長が指定されている場合は、送信するパケットが当該パケット長以下になるようにデータフレームを選択および読み出し、アクセスカテゴリが指定されている場合は、指定されたアクセスカテゴリのデータフレームを読み出す。なお、パケット長が、指定されたパケット長に満たない場合は、パディングデータをデータフレームの末尾に付加してもよい。また、送信するタイイングの調整量が指定されている場合は、トリガーフレームの受信から予め定めた時間に対して調整量だけずらしたタイミングで送信する。データフレームは、送信部２０２およびアンテナ１を介して物理パケットとして送信される。送信部２０２の動作は上述した通りである。

制御部２０１は、ＵＬ−ＯＦＤＭＡによるデータフレームの送信後、アクセスポイント１１から送信される送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を待機する。制御部２０１は、アクセスポイント１１から送達確認応答フレームを受信した場合は、送達確認応答フレーム内のビットマップフィールドを確認する（図１２参照）。制御部２０１は、ビットマップフィールド内の、自端末が送信したデータフレームのＣＲＣ結果が反映されたビット位置を特定する。自端末のＣＲＣ結果が反映されたビット位置を特定する方法は、前述した通りである。制御部２０１は、特定したビット位置のビット値に応じて、データフレームがアクセスポイント１１で正しく受信されたかを判断する。送信したフレームがアグリゲーションフレームである場合は、開始シーケンス番号フィールドから受信に成功した最小シーケンス番号を特定するとともに、ビットマップフィールドから、最小シーケンス番号以降のシーケンス番号のＣＲＣ結果を把握する。最小シーケンス番号未満のシーケンス番号についてはＣＲＣ結果が失敗であったと判断する。自端末用の開始シーケンス番号フィールドおよびビットマップフィールドを特定する方法は前述した通りである。

制御部２０１は、データフレームがアクセスポイントで正しく受信されなかったことが確認された場合は、必要に応じて、データフレームの再送処理を行う。再送の方法は任意でよい。例えば次回、トリガーフレームで自端末が指定された際に、ＵＬ−ＯＦＤＭＡでデータフレームを再送してもよいし、ＣＳＭＡ／ＣＡベースでキャリアセンスによりアクセス権を獲得して、データフレームを再送してもよい。これら以外の方法で再送を行ってもよい。

なお、ここでの説明では主に、ＵＬ−ＯＦＤＭＡにより送信するフレームは、データフレームである場合を例にしたが、管理フレームまたは制御フレームでもよい。

制御部２０１は、アクセスポイント１１に通知する情報、またはアクセスポイント１１から通知した情報、またはこれらの両方を格納するための記憶装置にアクセスして情報を読み出してもよい。記憶装置は、内部メモリでも、外部メモリでもよく、揮発性メモリでも不揮発メモリでもよい。また、記憶装置は、メモリ以外に、ＳＳＤ、ハードディスク等でもよい。

上述した、制御部２０１と送信部２０２の処理の切り分けは一例であり、上述した形態とは別の形態も可能である。例えばデジタル領域の処理およびＤＡ変換までは制御部２０１で行い、ＤＡ変換より後の処理を送信部２０２で行うようにしてもよい。制御部２０１と受信部２０３の処理の切り分けも同様に、ＡＤ変換より前までの処理を受信部２０３で行い、ＡＤ変換後の処理を含むデジタル領域の処理を制御部２０１で行うようにしてもよい。一例として、本実施形態に係るベースバンド集積回路は、制御部２０１と、送信部２０２の物理層の処理を行う部分とＤＡ変換を行う部分と、受信部２０３のＡＤ変換以降の処理を行う部分とに対応し、ＲＦ集積回路は、送信部２０２のＤＡ変換より後の処理を行う部分と、受信部２０３のＡＤ変換より前の処理を行う部分に対応する。本実施形態に係る無線通信用集積回路は、ベースバンド集積回路およびＲＦ集積回路のうち、少なくともベースバンド集積回路を含む。ここで述べた以外の方法でブロック間の処理、あるいはベースバンド集積回路およびＲＦ集積回路間の処理を切り分けてもよい。

図１８は、第１の実施形態に係るアクセスポイントの動作のフローチャートである。アクセスポイントの制御部１０１は、ＵＬ−ＯＦＤＭＡの対象となる複数の端末（または複数の無線通信装置）を選択し、また、選択した端末に利用させるリソースユニットを選択する（Ｓ１０１）。また、必要に応じて、ＭＣＳまたはパケット長などのパラメータを決定する。選択した端末およびリソースユニットを指定する情報、および決定したパラメータの情報を設定したトリガーフレームを生成する（Ｓ１０２）。アクセスポイントの制御部１０１は、キャリアセンスによりトリガーフレーム送信用のアクセス権を獲得した後、トリガーフレームを、送信部１０１を介して送信する（Ｓ１０３）。

アクセスポイントの制御部１０１は、トリガーフレームの送信後、トリガーフレームで指定した複数の端末から、それぞれ指定したリソースユニットで送信されるデータフレーム等のフレームの受信を待機する。制御部１０１は、これらの複数の端末から送信されるデータフレーム等のフレームを、受信部１０２を介して同時に受信すると（Ｓ１０４）、フレームの受信にそれぞれ成功したか否かの検査（ＣＲＣ検査等）を行う。制御部１０１は、フレームの受信の成功可否に関する検査結果（ＣＲＣ結果）を各端末用のビットに反映させたビットマップを生成し、生成したビットマップ等を設定した送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を生成する（Ｓ１０５）（図１２参照）。なお、各端末から受信したフレームがアグリゲーションフレームの場合は、アグリゲーションフレーム内の複数のデータフレームのＣＲＣ検査を行い、受信に成功した最も小さいシーケンス番号を特定し、図１４または図１５等のフォーマットで、Ｇ−ＡＣＫフレームを生成すればよい。制御部１０１は、生成した送達確認応答フレームを、各端末からデータフレームの受信完了後、予め定めた時間経過後に送信する（Ｓ１０５）。

図１９は、第１の実施形態に係る端末の動作のフローチャートである。端末の制御部２０１は、アクセスポイントから送信されるトリガーフレームを、受信部２０２を介して受信する（Ｓ２０１）。トリガーフレームには、ＵＬ−ＯＦＤＭＡの対象として複数の端末を指定する情報、および各端末が利用するリソースユニットを指定する情報、その他、必要なパラメータに関する情報が、制御フィールドまたは端末情報フィールドまたはこれらの両方に設定されている。

端末の制御部２０１は、トリガーフレームで自端末がＵＬ−ＯＦＤＭＡの対象として指定されているかを調べ（Ｓ２０２）、指定されている場合は、自端末が利用するリソースユニット、および必要に応じて、送信に必要なパラメータを把握する。当該パラメータに従ってデータフレームを生成し、トリガーフレームの受信完了から、予め定められた時間の経過後、データフレーム（より詳細には、データフレームを含む物理パケット）を、トリガーフレームで指定されたリソースユニットを用いて、送信部２０２を介して、アクセスポイントに送信する（Ｓ２０３）。

端末の制御部２０１は、データフレームの送信後、予め定めた時間の経過後に、アクセスポイントから送信される送達確認応答フレームを受信する（Ｓ２０４）。送達確認応答フレームは、アクセスポイントが各端末からのフレームの受信にそれぞれ成功したか否かの検査結果をビットに割り当てたビットマップを含む。端末の制御部２０１は、ビットマップから自端末用のビット位置を特定し、ビットの値に基づいて、アクセスポイントでフレーム受信が成功したか否か（自端末のフレーム送信が成功したか否か）の検査結果を把握する（Ｓ２０５）。

以上のように、本実施形態によれば、ＵＬ−ＯＦＤＭＡ送信に対する各端末への送達確認応答として、全端末に対する受信成功可否の検査結果（ＣＲＣ結果等）をビットに反映させたビットマップを含む送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信する。つまり、複数の端末に対する送達確認応答を順次返信する必要はなく、複数の端末に対する送達確認応答を１フレームで実現できる。よって、送達確認応答のオーバーヘッドを削減し、複数の端末へ送達確認応答を効率的に行うことができる。

また、複数の端末に対する送達確認応答の方法として、複数の端末の検査結果をビットマップに集約できるため、各端末のそれぞれに対する送達確認応答フレームを集約したスーパーフレームを送信する方法に比べて、フレーム長を短縮できる。よって、複数の端末へ送達確認応答の効率化を図ることができる。

また、本実施形態では、ビットマップを含む送達確認応答フレームを、レガシー端末でも受信可能な２０ＭＨｚチャネル幅で送信する。よって、レガシー端末およびＯＦＤＭＡ対応端末のいずれでも、送達確認応答フレームを正常に受信できる。このため、当該送達確認応答フレームの送信完了後に、レガシー端末およびＯＦＤＭＡ対応端末のそれぞれでＣＳＭＡ／ＣＡに従ってキャリアセンスによるアクセス権の獲得動作が発生した場合、いずれも、バックオフ前の一定期間のキャリアセンス時間として、ＤＩＦＳまたはＡＩＦＳ時間を起動する（レガシー端末でＥＩＦＳ時間は起動されない）。よって、レガシー端末およびＯＦＤＭＡ対応端末間で不公平は発生しない。

また、本実施形態では、ビットマップフィールドにおける各端末に対する検査結果のビット位置は、一例として、事前のトリガーフレーム内で各端末を指定した端末情報フィールドの位置と１対１での対応付けを図る。よって、各端末は、アクセスポイントからトリガーフレームでビットマップフィールドの各端末のビット位置を明示的に指定されなくても、ビットマップフィールドにおける自端末のＣＲＣ結果が格納されたビット位置を把握できる。よって、トリガーフレームの構成も短くできる。なお、トリガーフレームまたは送達確認応答フレームで、各端末のビット位置を明示的に指定することも、もちろん可能である。

また、各端末がＵＬ−ＯＦＤＭＡにおいて複数のデータフレームを集約したアグリゲーションフレームを送信した場合においても、端末毎に複数のデータフレームの検査結果を各々のビットマップに反映させることで（図１４または図１５参照）、各端末に対し、高効率に送達確認応答を行うことができる。

（第２の実施形態）
第１の実施形態では、複数の端末からアクセスポイントにＵＬ−ＯＦＤＭＡでフレームを送信する場合に、各端末のＣＲＣ結果を反映したビットマップを含む１つの送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信することで、送達確認応答を高効率に行った。複数の端末が同時にアップリンク送信する技術としては、ＵＬ−ＯＦＤＭＡ以外に、アップリンクマルチユーザＭＩＭＯ（Ｍｕｌｔｉ−Ｉｎｐｕｔ Ｍｕｌｔｉ−Ｏｕｔｐｕｔ）（以下、ＵＬ−ＭＵ−ＭＩＭＯ）が知られている。

ＵＬ−ＭＵ−ＭＩＭＯでは、複数の端末が同じタイミングで、それぞれ同一周波数帯でフレームをアクセスポイントに送信（空間多重送信）することで、アップリンク送信の高効率化を図ることが可能となる。この場合も、アクセスポイントは複数の端末から同時にフレームを受信するため、各端末に対し送達確認応答を送信する場合に、背景技術の欄で述べたような、効率が低下する問題が発生する。そこで、第１の実施形態と同様に、ＵＬ−ＭＵ−ＭＩＭＯの場合も、各端末のＣＲＣ結果を反映したビットマップを含む１つの送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信することで、送達確認応答を高効率に行うことができる。

ＵＬ−ＭＵ−ＭＩＭＯの場合の実施形態は、基本的に第１の実施形態の説明におけるＵＬ−ＯＦＤＭＡをＵＬ−ＭＵ−ＭＩＭＯに読み替え、リソースユニットをプリアンブルに読み替えればよい。そのため、本実施形態は、第１の実施形態と同様、図１〜図１９を用いて説明可能である。ただし、リソースユニットに関する説明図（図２および図３）は不要である。

以下では、ＵＬ−ＭＵ−ＭＩＭＯの場合の基本的な動作および技術について説明し、それ以外については第１の実施形態の説明で記述した各種の変形、拡張、組み合わせ、例外等が適用できることが自明であるため説明を省略する。例えばグループＩＤを利用する形態、ビットマップフィールド長に関する形態、アグリゲーションフレームを送信する形態、トリガーフレームおよびＧ−ＡＣＫフレームの受信先アドレスのバリエーション、送信用のパラメータのバリエーション、検査結果とビットマップの対応付けなど、すべて本実施形態でも有効である。

図２０は、ＵＬ−ＭＵ−ＭＩＭＯの概念を説明するための図である。アクセスポイントが、４台の端末１〜４とＵＬ−ＭＵ−ＭＩＭＯを行う状況を想定する。端末１〜４は、同じチャネル（２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚなど帯域幅は任意でよい）を利用して、同時にデータフレーム等のフレームを、データストリームとして送信する。アクセスポイントは、これらのデータフレームを同時に受信するが、後述するように各データフレームの物理ヘッダに含まれるプリアンブルを利用して、これらのデータフレームを分離する。このように複数の端末が同じ周波数帯域（チャネル）を利用して、ユーザ多重送信することができる。

図６を用いて、本実施形態のシーケンス例を説明する。アクセスポイント１１は、ＵＬ−ＭＵ−ＭＩＭＯの実施を決定すると、第１の実施形態と同様にして、ＵＬ−ＭＵ−ＭＩＭＯの対象となる端末を選択し、必要に応じて、後述する端末毎のプリアンブルに関する情報、その他のパラメータ（第１の実施形態の説明で記述した送信電力、ＭＣＳ、パケット長等に加え、端末毎のストリーム数などの情報を含んでもよい）を決定する。アクセスポイント１１は、第１の実施形態と同様にして、トリガーフレーム５０１（図８参照）を生成し、トリガーフレーム５０１を送信する。トリガーフレーム５０１は、例えばレガシー端末も受信可能な基本チャネル幅２０ＭＨｚで送信する。なお、トリガーフレームを、１本のアンテナから送信してもよいし、複数のアンテナから同時に送信してもよい。

トリガーフレーム５０１を受信した端末１〜４は、自端末がＵＬ−ＭＵ−ＭＩＭＯの対象として指定されたかを第１の実施形態と同様にして判断する。自端末が指定されたと判断した端末は、必要に応じて、端末情報フィールドまたは制御フィールドまたはこれらの両方から送信に必要なパラメータを特定する。端末情報フィールドに予めプリアンブルが対応づけられている場合は、端末情報フィールドの位置からプリアンブルを特定してもよい。

本例では、端末１〜４が、自端末が指定されていると判断し、アップリンク送信用のデータを含むデータフレーム５１１、５１２、５１３、５１４（より詳細には当該データフレームを含むパケット）を生成して、アクセスポイントに送信する。プリアンブル、送信電力、ＭＣＳ、パケット長、などのパラメータを指定されている場合、当該パラメータにしたがって、データフレームを生成および送信する。パケットの物理ヘッダ内には、プリアンブルが含まれる。図２１に、端末１〜４が送信するデータフレームを含む物理パケットの構成を示す。図２１のように、プリアンブルは、例えばＬ−ＳＩＧフィールドとフレームとの間のプリアンブルフィールドに配置される。端末１〜４のプリアンブル１〜４は互いに直交している。端末１〜４は、トリガーフレーム５０１の受信完了から時間Ｔ１後に各データフレームを送信する。第１の実施形態と同様に、アクセスポイント１１で同時に受信されるよう、端末毎に送信タイミングが調整されてもよい。なお、プリアンブル１〜４より前に配置されたＬ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧ等は、複数の端末で同じ信号である。

アクセスポイント１１は、ＵＬ−ＭＵ−ＭＩＭＯによって伝送された各端末のデータフレームを同時に重ね合わさった信号として受信する。アクセスポイント１１では、これらの信号を端末毎の信号に空間的に分離する必要がある。具体的には、アクセスポイント１１は、各端末が送信するデータフレームの物理ヘッダ内に付加されたプリアンブルを利用して、各端末からアクセスポイント１１へのアップリンクの無線伝搬路応答をそれぞれ推定する。プリアンブルは、各端末間で互いに直交しており、各端末の混信した信号から端末毎のプリアンブルを正しく認識可能である。アクセスポイント１１は、プリアンブルに基づき推定したアップリンクの伝搬路応答を用いることで、各端末から受信したデータフレームを、ＭＩＭＯ復調技術を用いて、正しく空間的に分離することが出来る。例えばＺＦ（Ｚｅｒｏ−Ｆｏｒｃｉｎｇ）法、または、ＭＭＳＥ（Ｍｉｎｉｍｕｍ Ｍｅａｎ Ｓｑｕａｒｅ Ｅｒｒｏｒ）法、または、最尤推定法等、任意の方法を用いることができる。

端末間のプリアンブルの直交化の方法として、時間的、周波数的、符号的のいずれの方法を用いてもよい。時間直交の場合には、プリアンブルフィールドが複数の区間に分割され、各端末が互いに異なる区間で順次プリアンブルを送信する。ある区間には、いずれか１台数端末のみがプリアンブルを送信していることになる。つまり端末間でプリアンブルを送信する時間的な位置が異なっている。ある端末がプリアンブルを送信する間、他の端末は何も送信しない期間になる。時間直交の場合、プリアンブルは、送信する値（ビット列）のみならず、どの時間で送信するかに関する情報も含んでいる。周波数直交の場合には、各端末が互いに直交関係にある周波数でプリアンブルを送信する。周波数直交の場合、プリアンブルは、送信する値のみならず、どの周波数（サブキャリア）で送信するかに関する情報も含んでいる。符号直交の場合には、各端末がそれぞれ直交行列の互いに異なる行（または互いに異なる列）の複数の値を配置（複数の値のそれぞれに対応するシンボルを配置）したプリアンブルを送信する。直交行列の各行（または各列）は互いに直交の関係にある。いずれの直交化の方法でも、アクセスポイント１１では各端末のプリアンブルの識別が可能となる。

アクセスポイント１１は、各端末が使用するプリアンブルに関する情報を、上記パラメータとしてトリガーフレームで通知してもよい。具体的には、時間直交の場合にはプリアンブルの値（ビット列）と、当該値のシンボルを送信するタイミングを指定してもよい。周波数直交の場合にはプリアンブルの値と、その値を送信する周波数（サブキャリア）を指定してもよい。符号直交の場合には、プリアンブルの送信に利用する直交行列の列または行に設定されている複数の値を特定する情報（または直交行列の行または列を識別する情報）を指定してもよい。このような指定の情報は、端末毎の端末情報フィールドに設定すればよい。例えば、図９の端末情報フィールドのＲＵ＃フィールドを、プリアンブルフィールドに置換し、ここに当該情報を設定すればよい。各端末にプリアンブルを識別する値を指定することで、プリアンブルの通知を行ってもよい。あるいは、この情報をトリガーフレームで通知するのではなく、トリガーフレームの送信前に通知してもよい。あるいは、各端末が利用するプリアンブルは、予め定まっていても良い。いずれにしても、各端末はＵＬ−ＭＵ−ＭＩＭＯにより送信を行う際には、それぞれが送信するプリアンブルは、把握出来ている。

アクセスポイント１１は、ＵＬ−ＭＵ−ＭＩＭＯ送信された複数の端末からのデータフレームを受信すると、各データフレームの誤り検査を行う。第１の実施形態と同様に、各端末のデータフレームの検査結果（ＣＲＣ結果等）を各々のビットに反映させたビットマップを生成する。ビットマップのビット位置と、各端末のＣＲＣ結果との対応は、第１の実施形態と同様である。ビットマップフィールドとして最低限必要なビットサイズは、ＵＬ−ＭＵ−ＭＩＭＯにて送信される合計ストリーム数（または端末数）となる。図６の例の場合には、４台の端末から１データストリームが送信されるため、ビットマップフィールドとして必要なビット数は最低で４ビットである。ただし、端末が複数のアンテナを備え、複数のフレーム（データストリーム）を送信する場合は、データストリームごとにＣＲＣ結果を反映させるビットが必要となる。この場合、ビットマップフィールドとして必要なビット数は、各端末のデータストリーム数の合計となる。

なお、端末が複数のアンテナを備え、複数のフレーム（データストリーム）を送信可能な場合を考慮する場合、アクセスポイント１１は、トリガーフレームで端末毎に、送信するデータストリーム数と、データストリーム数が複数の場合にそれぞれで使用するプリアンブルに関する情報を通知してもよい。なお、アクセスポイントが同時に受信可能なデータストリーム数の上限は、一例として、アクセスポイントが備えるアンテナの本数に一致する。アクセスポイントは、この上限と、端末毎の送信可能なデータストリーム数の上限（一例として、端末が備えるアンテナの本数に一致）を考慮して、端末毎のデータストリーム数を決定してもよい。また、複数のフレームと、ビットマップの各ビット位置との対応づけは、各フレームを送信したプリアンブルを介して行えばよい。

アクセスポイント１１は、生成したビットマップに基づき、図１２のようなフォーマットの送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を生成する。そして、複数の端末からのデータフレームの受信完了から一定時間Ｔ２（ＳＩＦＳ時間等）後に、当該送達確認応答フレームを送信する。送達確認応答フレームは、例えばレガシー端末が受信可能な基本チャネル幅２０ＭＨｚで送信する。

アクセスポイントおよび端末のブロック図は、第１の実施形態の図１６および図１７と同じであり、その動作の説明も、ＵＬ−ＯＦＤＭＡがＵＬ−ＭＵ−ＭＩＭＯの動作に置き換わる点以外は同じである。よって、アクセスポイントおよび端末の動作は、第２の実施形態のこれまでの説明と、第１の実施形態の図１６および図１７の説明から自明なため、省略する。

以上のように、本実施形態によれば、ＵＬ−ＭＵ−ＭＩＭＯ送信に対する各端末への送達確認応答として、複数の端末に対する送達確認応答を順次返信するのではなく、全端末に対する受信成功可否の検査結果（ＣＲＣ結果等）をビットに反映させたビットマップを含む送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信する。つまり、複数の端末に対する送達確認応答を１フレームで実現できる。よって、オーバーヘッドを削減し、複数の端末へ送達確認応答を効率的に行うことができる。

また、本実施形態では、ビットマップを含む送達確認応答フレームを、レガシー端末でも受信可能な２０ＭＨｚチャネル幅で送信する。よって、レガシー端末およびＵＬ−ＭＵ−ＭＩＭＯ対応端末のいずれでも、送達確認応答フレームを正常に受信できる。このため、当該送達確認応答フレームの送信完了後に、これらの端末間でＣＳＭＡ／ＣＡに従ってキャリアセンスによるアクセス権の獲得動作が発生した場合、いずれも、バックオフ前の一定期間のキャリアセンス時間として、ＤＩＦＳまたはＡＩＦＳ時間を起動する（レガシー端末でＥＩＦＳ時間は起動されない）。よって、レガシー端末およびＵＬ−ＭＵ−ＭＩＭＯ対応端末間の不公平は発生しない。

その他、第１の実施形態の説明で述べたのと同様の効果を得ることができる。

（第３の実施形態）
第１の実施形態ではＵＬ−ＯＦＤＭＡ、第２の実施形態ではＵＬ−ＭＵ−ＭＩＭＯを行った場合の送達確認応答を効率的に行う形態を示した。ＵＬ−ＯＦＤＭＡおよびＵＬ−ＭＵ−ＭＩＭＯ以外に、複数の端末からアクセスポイントへのアップリンク多重送信として、ＯＦＤＭＡとＭＵ−ＭＩＭＯを組み合わせた通信方式（ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯと呼ぶ）も可能である。アップリンクのＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ（ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ）の場合、複数のリソースユニットごとに、複数の端末がＵＬ−ＭＵ−ＭＩＭＯ送信を行うことになる。

ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合も、アクセスポイントは複数の端末から同時にフレームを受信するため、各端末に対し送達確認応答を送信する場合に、背景技術の欄で述べたような、効率が低下する問題が発生する。そこで、第１および第２の実施形態と同様に、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合も、各端末のＣＲＣ結果を反映したビットマップを含む１つの送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信することで、送達確認応答を高効率に行うことができる。

ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合の実施形態は、基本的に第１および第２の実施形態を組み合わせたものに相当する。本実施形態では、利用可能なリソースユニット毎に少なくとも１台または複数の端末を選択するとともに、同じリソースユニットに属する複数の端末に、ＭＵ−ＭＩＭＯ送信用にそれぞれ異なるプリアンブルを割り当てる。リソースユニットが異なる端末間では、同じプリアンブルが割り当てられても問題ない。

以下、第１および第２の実施形態で用いた図１〜図１９、図２１、および追加の図２２〜図２４を用いて、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合の基本的な実施形態について説明する。第１または第２またはこれらの両方の実施形態の説明で記述した各種の変形、拡張、組み合わせ、例外等は、本実施形態でも適用でき、これらについては自明であるため説明を省略する。例えばグループＩＤを利用する形態、ビットマップフィールド長に関する形態、アグリゲーションフレームを送信する形態、トリガーフレームおよびＧ−ＡＣＫフレームの受信先アドレスのバリエーション、送信用のパラメータのバリエーション、検査結果とビットマップの対応付けなど、すべて本実施形態でも有効である。

図２２は、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの概念を説明するための図である。アクセスポイントが４つのリソースユニットＲＵ＃１、ＲＵ＃２、ＲＵ＃３、ＲＵ＃４を利用する。７台の端末（ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ対応端末）１〜７が存在する状況を想定する。ＲＵ＃１〜ＲＵ＃４の表記は、便宜上定めたもので、図３に対応している必要はない。アクセスポイントは、リソースユニットＲＵ＃１に端末２、７を割り当て、リソースユニットＲＵ＃２に端末６を割り当て、リソースユニットＲＵ＃３に端末１、３、５を割り当て、リソースユニットＲＵ＃４に端末４を割り当てている。なお、同じ端末が複数のリソースユニットに割り当てられてもかまわない。図２２の例では、端末２、７がリソースユニットＲＵ＃１、端末６がリソースユニットＲＵ＃２、端末１、３、５がリソースユニットＲＵ＃３、端末４がＲＵ＃４を用いて、それぞれ同時にフレーム（データストリーム）を送信する。個々のリソースユニット内では、第２の実施形態で述べたＵＬ−ＭＵ−ＭＩＭＯが行われ、第２の実施形態と同様のパケットフォーマット（端末間のフレームを分離するために利用するプリアンブルを含むパケットフォーマット）を有するパケットが送信される。リソースユニットＲＵ＃２、ＲＵ＃４では端末が１台のみしか存在しないため、第１の実施形態と同様のパケットフォーマットを送信することも可能である。ただし、ここでは、１台の端末しか存在しないリソースユニットでも、第２の実施形態と同様のパケットフォーマットを利用することを想定する。このようにＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯでは、ＵＬ−ＯＦＤＭＡまたはＵＬ−ＭＵ−ＭＩＭＯに比べて、より多くの端末を多重することができる。

図６を用いて、本実施形態のシーケンス例を説明する。アクセスポイント１１は、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの実施を決定すると、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯで利用するリソースユニット毎に、少なくとも１台の端末を選択し、必要に応じて、各リソースユニットに属する端末毎のプリアンブルを決定し、その他のパラメータ（第１の実施形態の説明で記述した送信電力、ＭＣＳ、パケット長等）を決定する。アクセスポイント１１は、トリガーフレーム５０１を生成し、トリガーフレーム５０１を送信する。トリガーフレーム５０１は、例えばレガシー端末も受信可能な基本チャネル幅２０ＭＨｚで送信する。なお、トリガーフレームを、１本のアンテナから送信してもよいし、複数のアンテナから同時に送信してもよい。

本実施形態のトリガーフレームの端末情報フィールドでは、図９のＲＵ＃フィールドに、リソースユニットを指定する情報に加えて、プリアンブルを指定する情報を設定してもよい。つまり、本実施形態のトリガーフレームでは、同一のリソースユニットの指定情報が設定されたＲＵ＃フィールドを有する複数の端末情報フィールドが存在する場合がある。これら以外のパラメータの情報については、第１または第２の実施形態と同様にして、その他のフィールド（ｏｔｈｅｒフィールド）に設定すればよい。なお、端末情報フィールドに、プリアンブルまたはリソースユニットまたはこれらの両方が対応づけられていてもよく、この場合、プリアンブルまたはリソースユニットまたはこれらの両方を指定する情報の設定は不要である。

トリガーフレーム５０１を受信した端末１〜４は、自端末がＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの対象として指定されたかを第１または第２の実施形態と同様にして判断する。自端末が指定されたと判断した場合、端末は、必要に応じて、端末情報フィールドまたは制御フィールドまたはこれらの両方から、アップリンク送信に必要なパラメータを特定する。端末情報フィールドに予めプリアンブルまたはリソースユニットまたはこれらの両方が対応づけられている場合は、端末情報フィールドの位置からプリアンブルまたはリソースユニットまたはこれらの両方を特定してもよい。

本例では、端末１〜４が、自端末が指定されていると判断し、自端末が使用するリソースユニットを特定し、また、自端末が利用するプリアンブルを特定する。これらを特定する方法は、第１および第２の実施形態と同様である。端末１〜４は、アップリンク送信用のデータを含むデータフレーム５１１、５１２、５１３、５１４（より詳細には当該データフレームを含むパケット）を生成して、それぞれ該当するソースユニット、およびプリアンブルを用いて、アクセスポイントに送信する。送信電力、ＭＣＳ、パケット長、などのパラメータを指定されている場合、当該パラメータにしたがって、データフレームを生成および送信する。パケットの物理ヘッダ内には、プリアンブルが含まれる。端末１〜４は、トリガーフレーム５０１の受信完了から時間Ｔ１後に各データフレームを送信する。第１の実施形態と同様に、アクセスポイント１１で同時受信が高精度に行われるよう、端末毎に送信タイミングが調整されてもよい。

アクセスポイント１１は、各リソースユニットで、１つまたは複数の端末のデータフレームを同時に重ね合わさった信号として受信する。アクセスポイント１１では、リソースユニット毎に、端末毎のデータフレーム（同じ端末が複数のデータフレームを送信した場合も含む）を、物理ヘッダ内のプリアンブルを利用して分離する。この詳細は第２の実施形態で述べた通りである。

アクセスポイント１１は、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ送信された複数の端末からのデータフレームを受信すると、各データフレームの誤り検査を行う。第１の実施形態と同様に、各端末のデータフレームの検査結果（ＣＲＣ結果等）を各々のビットに反映させたビットマップを生成する。

ビットマップフィールドとして最低限必要なビットサイズは、リソースユニット毎にＭＵ−ＭＩＭＯにて送信される端末数（端末が複数のデータストリームを送信する場合を考慮する場合は、データストリーム数）の合計である。図２２の例では、最低限必要なビットサイズは、７ビットである。ビットマップのサイズは、第１の実施形態の説明で述べたように、バイト単位としてもよく、この場合、図２２の例では８ビットとなる。各端末のＣＲＣ結果を反映させるビット位置は、第１または第２の実施形態と同様にして、各端末を指定した端末情報フィールドの位置に応じて決定してもよい。例えば各端末が１データストリームを送信する場合、先頭の端末情報フィールドで指定した端末は、ビットマップの先頭ビット（または末尾ビット、所定ビット）に、当該端末用のＣＲＣ結果を反映させればよい。同様にして、２番目〜ｎ番目の端末情報フィールドで指定した端末は、ビットマップの先頭（または末尾ビット、所定ビット）から２番目〜ｎ番目のビットに、当該端末のＣＲＣ結果を反映させればよい。

複数のデータストリームを送信する端末が存在する場合、当該データストリーム数分の連続するビットを確保すればよい。例えば先頭の端末情報フィールドで指定する端末が２データストリーム送信し、その他の端末が１データストリームを送信する場合を考える。この場合は、２データストリームを送信する端末については、例えば、ビットマップの先頭および２番目のビットに、各データストリームに対応するデータフレームのＣＲＣ結果を反映させればよい。当該２つのデータフレームと２つのビットとの対応は、各データフレームのプリアンブルを介して対応づけしてもよい。例えば端末に２データストリームに対応して２つのプリアンブルの番号を指定した際に、より番号の小さいプリアンブルに対応するデータフレームのＣＲＣ結果が、２つのビットの先頭側のビットに対応するとしてもよい。あるいは、複数のプリアンブルごとに予め優先順位が設定されており、優先順位の高い順に２つのビットの先頭から割り当てるようにしてもよい。ここで述べた方法以外で対応をとってもよい。なお、２番目〜ｎ番目の端末情報フィールドで指定した端末は、それぞれ１データストリームを送信するため、ビットマップの先頭から３番目〜ｎ番目のビットに、当該端末のＣＲＣ結果を反映させればよい。この場合、各端末は、トリガーフレームの端末情報フィールド等を解析することで、他の端末が使用するデータストリーム数を把握することで、自端末のＣＲＣ結果が反映されたビット位置を特定可能である。なお、本段落で記述した「先頭」は、「末尾」または「所定位置」に置き換えてもよい。

また、ビットマップサイズは固定長でもよい。この場合、一例として、“利用可能なリソースユニットの最大多重数”と“１リソースユニットにおけるＭＵ−ＭＩＭＯの最大多重数”とを乗じた値のビット数を、ビットマップとして用意することができる。これらは、規格または仕様で規定されてもよいし、アクセスポイントが複数の選択肢の中から決定してもよい。

例えば図２２のように、リソースユニットが４つ利用可能で、各リソースユニットでＭＵ−ＭＩＭＯの最大多重数が４の場合、４×４＝１６ビットのビットマップが必要である。このとき、４つのリソースユニットのうち、実際に利用されないリソースユニットが発生したり、４つのリソースユニットのうち多重数が４未満のリソースユニットが発生したりした場合、検査結果が割り当てられないビットが発生し、そのビットは、リザーブビットとして扱われる。なお、アクセスポイントの動作モードに応じて、利用可能なリソースユニットの最大多重数が変化する場合や、リソースユニットごとに利用可能な最大多重数が変化する場合もある。その場合は、動作モードに応じたビットサイズのビットマップを用意することも可能である。

図２３（Ａ）は、ビットマップのフォーマット例を示す。この例では、４つのリソースユニットが利用可能であり、１リソースユニット当たりＭＵ−ＭＩＭＯで最大４多重が可能な場合の固定長（１６ビット）のビットマップのフォーマット例である。先頭から４ビットごとに、リソースユニットＲＵ＃１、ＲＵ＃２、ＲＵ＃３、ＲＵ＃４を順番に割り当てている。各リソースユニットでは、先頭側から空間リソースとして、Ｓ１ビット、Ｓ２ビット、Ｓ３ビット、Ｓ４ビットが割り当てられており、それぞれＭＵ−ＭＩＭＯで多重送信されるデータフレームの検査結果（ＣＲＣ結果）が割り当てられる。各リソースユニットにおいて、Ｓ１ビット、Ｓ２ビット、Ｓ３ビット、Ｓ４ビットと、各端末のＣＲＣ結果との対応に関して、トリガーフレームで各端末が指定された端末情報フィールドの位置の先頭側に近いほど、先頭側のビットを割り当てるようにしてもよい。この場合、各端末はトリガーフレームを解析することで、自端末と同じリソースユニットを割り当てられた端末（自端末を含む）が指定された端末情報フィールドの中で、自端末が指定された端末情報フィールドが何番目かを把握する。そして、自端末が指定されたリソースユニットに対応するビット範囲（Ｓ１ビット〜Ｓ４ビット）をビットマップから特定し、特定したビット範囲の先頭から、上記把握した番号の位置のビットを、自端末用のビットとして特定してもよい。これにより、トリガーフレームを受信することで、Ｇ−ＡＣＫフレーム内に各端末のＣＲＣ結果を示すビット位置を特定するための情報を含む特別なフィールドを含まなくても、自端末のＣＲＣ結果を示すビット位置を把握することが可能となる。

自端末が複数のデータストリームを送信する場合、または自端末と同じリソースユニットで複数のデータストリームを送信する他の端末が存在する場合は、前述した例に倣えばよい。すなわち、複数のデータストリームを送信する端末が存在する場合、当該データストリーム数分の連続するビットをその端末が使用するようにすればよい。リソースユニットＲＵ＃１で端末１が２データストリーム送信し、端末２が１データストリームを送信する場合を考える。この場合は、２データストリームを送信する端末１については、例えば、リソースユニットＲＵ＃１に対応するビット範囲（Ｓ１〜Ｓ４）の先頭および２番目のビットに、各データストリームに対応するデータフレームのＣＲＣ結果を反映させればよい。当該２つのデータフレームと２つのビットとの対応は、上述したように、各データフレームのプリアンブルを介して対応づけしてもよい。一方端末２については、当該ビット範囲の先頭から３番目のビットに、当該端末のＣＲＣ結果が反映させればよい。この場合、端末２は、トリガーフレームを解析することで、自端末と同じリソースユニットを、自端末より先頭側に位置する端末情報フィールドで指定された端末１が使用すること、かつ端末１が使用するデータストリーム数を把握する。これにより、自端末のＣＲＣ結果が反映されたビット位置を特定可能である。端末１は、自端末が先頭の端末情報フィールドで指定されており、かつリソースユニットＲＵ＃１を利用し、かつ２データストリームを送信することを把握する。これにより、リソースユニットＲＵ＃１に対応するビット範囲（Ｓ１〜Ｓ４）の先頭および２番目のビットに、自端末のＣＲＣ結果が反映されていると判断できる。各データフレームと、これら２つのビットは、上記したようにプリアンブルを介して把握すればよい。

あるいは、空間リソースのＳ１〜Ｓ４ごとにプリアンブルをそれぞれ用意し（つまり、同じ空間リソースに属する端末は同じプリアンブルを利用する）、各端末が利用するリソースユニットとプリアンブルとから一意に、ビットを割り当ててもよい。例えば端末１が、空間リソースＳ２に対応するプリアンブルを利用し、かつリソースユニットＲＵ＃３を利用する場合は、先頭から１０番目のビット（ＲＵ＃３、Ｓ２、）を割り当てる。端末は、自端末が指定されたリソースユニットとプリアンブルとから一意にビットを特定できる。

なお、図２３（Ａ）の説明で記述した「先頭」は、「末尾」あるいは「所定位置」に置き換えてもよい。

図２３（Ｂ）は、ビットマップの他のフォーマット例を示す。このフォーマットも、図２３（Ａ）と同様、４つのリソースユニットが利用可能であり、１リソースユニット当たりＭＵ−ＭＩＭＯで最大４多重が可能な場合の固定長（１６ビット）のビットマップのフォーマット例である。先頭から４ビットごとに、空間リソースＳ１、Ｓ２、Ｓ３、Ｓ４を順番に割り当てている。各空間リソースでは、先頭側からＲＵ＃１ビット、ＲＵ＃２ビット、ＲＵ＃３ビット、ＲＵ＃４ビットが割り当てられており、それぞれリソースユニットＲＵ＃１〜ＲＵ＃４で送信されるデータフレームの検査結果（ＣＲＣ結果）が割り当てられる。アクセスポイントは、同じリソースユニットを利用する端末間では、先頭側に近い端末情報フィールドで指定された端末ほど、先頭側の空間リソースの該当するＲＵ＃ビットを割り当てる。この場合、各端末はトリガーフレームを解析することで、自端末と同じリソースユニットを割り当てられた端末（自端末を含む）が指定された端末情報フィールドの中で、自端末が指定された端末情報フィールドが何番目かを把握する。把握した番号の位置に対応する空間リソース（Ｓ１〜Ｓ４のいずれか）をビットマップにおいて特定し、特定した空間リソース内の該当するリソースユニットのＲＵ＃ビットを、自端末用のビットとして特定してもよい。

自端末が複数のデータストリームを送信する場合、または自端末と同じリソースユニットで複数のデータストリームを送信する他の端末が存在する場合は、上述した例に倣えばよい。すなわち、複数のデータストリームを送信する端末が存在する場合、当該データストリーム数分の連続する空間リソースにその端末を割り当てるようにすればよい。リソースユニットＲＵ＃１で端末１が２データストリームを送信し、端末２が１データストリームを送信する場合を考える。この場合は、２データストリームを送信する端末１については、例えば、空間リソースＳ１、Ｓ２のビットＲＵ＃１に、各データストリームに対応するデータフレームのＣＲＣ結果を反映させればよい。当該２つのデータフレームと２つのビットとの対応は、上述したように、各データフレームのプリアンブルを介して対応づけしてもよい。一方端末２については、３番目の空間リソースＳ３のビットＲＵ＃１に、当該端末のＣＲＣ結果を反映させればよい。この場合、端末２は、トリガーフレームを解析することで、自端末と同じリソースユニットを、自端末より先頭側に位置する端末情報フィールドで指定された端末１が使用すること、かつ端末１が使用するデータストリーム数を把握する。これにより、自端末のＣＲＣ結果が反映されたビット位置を特定可能である。端末１は、自端末が先頭の端末情報フィールドで指定されており、かつリソースユニットＲＵ＃１を利用し、かつ２データストリームを送信することを把握する。これにより、空間リソースＳ１、Ｓ２のビットＲＵ＃１に、自端末のＣＲＣ結果が反映されていると判断できる。各データフレームと、これら２つのビットは、上記したようにプリアンブルを介して把握すればよい。

あるいは、空間リソースＳ１〜Ｓ４に対応してプリアンブルをそれぞれ用意し（つまり、同じ空間リソースに属する端末は同じプリアンブルを利用する）、各端末が利用するリソースユニットとプリアンブルとから一意に、ビットを割り当ててもよい。例えば端末１が、空間リソースＳ２に対応するプリアンブルを利用し、かつリソースユニットＲＵ＃３を利用する場合は、先頭から７番目のビット（Ｓ２、ＲＵ＃３）を割り当てる。端末は、自端末が指定されたリソースユニットとプリアンブルとから一意にビットを特定できる。

なお、図２３（Ｂ）の説明で記述した「先頭」は、「末尾」あるいは「所定位置」に置き換えてもよい。

図２３（Ａ）および図２３（Ｂ）で示した例は一例であり、他のフォーマットも可能である。例えば、トリガーフレームにおける端末情報フィールドの順に、当該端末情報フィールドで指定された端末に対するＣＲＣ結果（ＡＣＫ応答）のビット位置が決定されてもよい。
例えば、端末情報フィールド１で端末１に対し、リソースユニットＲＵ＃２と空間リソース（ストリーム）１が指定され、
端末情報フィールド２で端末２に対し、リソースユニットＲＵ＃１とストリーム３が指定され、
端末情報フィールド３で端末３に対し、リソースユニットＲＵ＃１とストリーム１が指定され、
端末情報フィールド４で端末４に対し、リソースユニットＲＵ＃３とストリーム２が指定され、
端末情報フィールド５以降で指定された端末５以降についても同様にして、リソースユニットとストリームが指定されたとするとする。
この場合、図２３（Ｃ）に示すように、ビットマップのビット配置は下位ビットから順に
リソースユニットＲＵ＃２とストリーム１で送信した端末のＣＲＣ結果
リソースユニットＲＵ＃１とストリーム３で送信した端末のＣＲＣ結果
リソースユニットＲＵ＃１とストリーム１で送信した端末のＣＲＣ結果
リソースユニットＲＵ＃３とストリーム２で送信した端末のＣＲＣ結果
を割り当て、端末情報フィールド５以降で指定された端末５以降についても同様にして割り当てを行う。

図２４は、本実施形態に係る送達確認応答フレーム（Ｇ−ＡＣＫフレーム）の他のフォーマット例を示す。図１２に示したフォーマットに対して、Ｉｎｄｉｃａｔｏｒフィールドが追加されている。図２４のフォーマットは、第１の実施形態の場合のＵＬ−ＯＦＤＭＡ、第２の実施形態の場合のＵＬ−ＭＵ−ＭＩＭＯ、第３の実施形態の場合のＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのいずれのアップリンクユーザ多重方式の場合にも共通して適用可能なＧ−ＡＣＫフレームフォーマットの例である。

Ｉｎｄｉｃａｔｏｒフィールドには、ＵＬ−ＯＦＤＭＡ、ＵＬ−ＭＵ−ＭＩＭＯ、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのいずれの方式の送達確認応答かを識別する情報を設定する。一例として、アクセスポイントは、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合に“０”、ＵＬ−ＭＵ−ＭＩＭＯの場合に“１”、ＵＬ−ＯＦＤＭＡの場合に“２”を設定する。この数値の設定はあくまで一例であり、別の値を設定してもかまわない。アクセスポイントは、ＵＬ−ＯＦＤＭＡ、ＵＬ−ＭＵ−ＭＩＭＯ、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのいずれかに応じて、ビットマップフィールドの構成を、第１〜第３の実施形態の説明で述べたように決定すればよい。

ビットマップサイズを固定にする場合、本実施形態ではＩｎｄｉｃａｔｏｒフィールドの値に応じて、ビットマップのサイズを決定してもよい。仮にＵＬ−ＯＦＤＭＡ、ＵＬ−ＭＵ−ＭＩＭＯ、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのすべてに対応可能な固定のビットマップサイズを採用すると、より小さいビットマップサイズで済む方式では、不必要なリザーブビットが発生する。Ｉｎｄｉｃａｔｏｒフィールドを利用することで、各方式に適合したビットマップサイズを利用できる。なお、Ｉｎｄｉｃａｔｏｒフィールドを、ＧＡ Ｃｏｎｔｒｏｌフィールドのサブフィールドとして扱ってもよい。

ＵＬ−ＯＦＤＭＡ、ＵＬ−ＭＵ−ＭＩＭＯ、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのいずれのアップリンクユーザ多重方式を実行するかは、システムで事前に決められていても良いし、アクセスポイントが送信するトリガーフレームで指定してもよい。後者の場合、アクセスポイントは、アップリンクユーザ多重方式を指定する情報を、制御フィールドまたは端末情報フィールドまたはこれらの両方に設定すればよい。

ここで、実行するアップリンクユーザ多重方式に応じて、トリガーフレームにおける端末情報フィールドのフォーマットを変更できるようにしてもよい。例えば図２４のＩｎｄｉｃａｔｏｒと同様のフィールド（ここでは同じくＩｎｄｉｃａｔｏｒフィールドと呼ぶ）を、制御フィールドまたは端末情報フィールドに追加する。Ｉｎｄｉｃａｔｏｒフィールドを、端末情報フィールドに追加する場合、例えば図９において、ＳＴＡ ＩＤフィールドの次に配置してもよい。ＩｎｄｉｃａｔｏｒフィールドがＵＬ−ＯＦＤＭＡを示す場合は、この後のフィールドとして、図９に示すようなリソースユニットを指定するフィールド（ＲＵ＃フィールド）等を配置する。ＩｎｄｉｃａｔｏｒフィールドがＵＬ−ＭＵ−ＭＩＭＯを示す場合は、この後のフィールドとして、ＲＵ＃フィールドの代わりに、プリアンブルを指定するフィールド、および必要に応じて、データストリーム数を指定するフィールド等を配置する。ＩｎｄｉｃａｔｏｒフィールドがＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯを示す場合は、この後のフィールドとして、ＲＵ＃フィールド、プリアンブルを指定するフィールド、および必要に応じて、データストリーム数を指定するフィールド等を配置する。

あるいは、実行するアップリンクユーザ多重方式に拘わらず、トリガーフレームにおける端末情報フィールドのフォーマットを固定にしてもよい。この場合、最も多くの情報を必要とするＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯに応じた情報を設定可能なように端末情報フィールドを設定する。ＳＴＡ ＩＤフィールド、ＵＬ−ＯＦＤＭＡの実施有無の情報を設定するフィールド（フィールドＡと呼ぶ）、ＲＵ＃フィールド、ＭＵ−ＭＩＭＯの実施有無の情報を設定するフィールド（フィールドＢと呼ぶ）、プリアンブルを指定するフィールド等を用意しておく。ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯを実施する場合は、フィールドＡおよびフィールドＢとも「有」を示す値を設定し、ＲＵ＃フィールドおよびプリアンブルを指定するフィールド等にも値を設定する。ＵＬ−ＭＵ−ＭＩＭＯを実施する場合は、フィールドＡは「無」、フィールドＢは「有」を示す値を設定し、ＲＵ＃フィールドの設定は不要で（Ｎ／Ａを示す値を設定してもよい）、プリアンブルを指定するフィールド等にも値を設定する。ＵＬ−ＯＦＤＭＡを実施する場合は、フィールドＡは「有」、フィールドＢは「無」を示す値を設定し、ＲＵ＃フィールドにも値を設定し、プリアンブルを指定するフィールドの設定は不要である（Ｎ／Ａを示す値を設定してもよい）。トリガーフレームを受信した端末も、ここで述べたのと同様のルールで、トリガーフレームを解釈すればよい。このようにトリガーフレームを構成することで、いずれの方式にも同じフォーマットを利用できる。

アクセスポイントおよび端末のブロック図は、図１６および図１７と同じであり、その動作の説明も、ＵＬ−ＯＦＤＭＡとＭＩ−ＭＩＭＯを組み合わせた構成に合わせた説明にすること以外は基本的に、同じである。よって、アクセスポイントおよび端末の動作は、第３の実施形態のこれまでの説明と、第１および第２の実施形態の説明から自明なため、省略する。

以上のように、本実施形態によれば、ＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ送信に対する各端末への送達確認応答として、全端末に対する受信成功可否の検査結果（ＣＲＣ結果等）をビットに反映させたビットマップを含む送達確認応答フレーム（Ｇ−ＡＣＫフレーム）を送信する。つまり、複数の端末に対する送達確認応答を１フレームで実現できる。よって、送達確認応答のオーバーヘッドを削減し、複数の端末へ送達確認応答を効率的に行うことができる。

また、本実施形態では、ビットマップを含む送達確認応答フレームを、レガシー端末でも受信可能な２０ＭＨｚチャネル幅で送信する。よって、レガシー端末およびＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ対応端末のいずれでも、送達確認応答フレームを正常に受信できる。このため、当該送達確認応答フレームの送信完了後に、これらの端末間でＣＳＭＡ／ＣＡに従ってキャリアセンスによるアクセス権の獲得動作が発生した場合、いずれも、バックオフ前の一定期間のキャリアセンス時間として、ＤＩＦＳまたはＡＩＦＳ時間を起動する（レガシー端末でＥＩＦＳ時間は起動されない）。よって、レガシー端末およびＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ対応端末間で不公平は発生しない。

その他、第１または第２またはこれらの両方の実施形態の説明で述べたのと同様の効果を得ることができる。

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

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

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

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

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

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

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

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

ベースバンド回路１１２およびＣＰＵ１１５の少なくとも一方は、クロックを生成するクロック生成部を含み、当該クロック生成部で生成するクロックにより、内部時間を管理してもよい。ベースバンド回路１１２は、物理層の処理として、物理ヘッダの付加、符号化、暗号化、変調処理など行い、例えば２種類のデジタルベースバンド信号（以下、デジタルＩ信号とデジタルＱ信号）を生成する。

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

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

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

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

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

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

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

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

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

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

また制御回路１１２は、ＭＩＭＯに関する処理を行ってもよい。例えば、伝搬路推定の処理、送信ウェイト計算処理、ストリームの生成および分離処理等を行う。また、ＵＬ−ＯＦＤＭＡ、ＵＬ−ＭＵ−ＭＩＭＯ、およびＵＬ−ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの少なくとも１つに関する処理を行う。

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

（第５の実施形態）
図２６（Ａ）および図２６（Ｂ）は、それぞれ第５の実施形態に係る端末の斜視図である。図２６（Ａ）の端末はノートＰＣ３０１であり、図２６（Ｂ）の端末は移動体端末３２１である。ノートＰＣ３０１および移動体端末３２１は、それぞれ無線通信装置３０５、３１５を搭載している。無線通信装置３０５、３１５として、これまで説明してきた端末に搭載されていた無線通信装置（図１７、図２６等）、またはアクセスポイント１１に搭載されていた無線通信装置（図１６、図２６等）、またはこれらの両方を用いることができる。無線通信装置を搭載する端末は、ノートＰＣや移動体端末に限定されない。例えば、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等にも搭載可能である。

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

（第６の実施形態）
第６の実施形態では、第１〜第４のいずれかの実施形態に係る無線通信装置（アクセスポイントの無線通信装置または端末の無線通信装置、またはこれらの両方）の構成に加えて、バス、プロセッサ部、及び外部インターフェース部を備える。プロセッサ部及び外部インターフェース部は、バスを介して外部メモリ（バッファ）と接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。ファームウエアが動作するプロセッサ部は、本実施形態に係る通信制御装置または制御部の処理を行うプロセッサであってもよいし、当該処理の機能拡張または変更に係る処理を行う別のプロセッサであってもよい。ファームウエアが動作するプロセッサ部を、本実施形態に係るアクセスポイントあるいは端末、あるいはこれらの両方が備えてもよい。または当該プロセッサ部を、アクセスポイントに搭載される無線通信装置内の集積回路、または端末に搭載される無線通信装置内の集積回路が備えてもよい。

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

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

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

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

（第１１の実施形態）
第１１の実施形態では、第１〜第４のいずれかの実施形態に係る無線通信装置（アクセスポイントの無線通信装置または端末の無線通信装置、またはこれらの両方）の構成に加えて、ＬＥＤ部を含む。ＬＥＤ部は、送信部（１０２または２０２）または受信部（１０３または２０３）または制御部（１０１または２０１）またはこれらのうちの複数と接続される。このように、ＬＥＤ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

（第１２の実施形態）
第１２の実施形態では、第１〜第４のいずれかの実施形態に係る無線通信装置（アクセスポイントの無線通信装置または端末の無線通信装置、またはこれらの両方）の構成に加えて、バイブレータ部を含む。バイブレータ部は、送信部（１０２または２０２）または受信部（１０３または２０３）または制御部（１０１または２０１）またはこれらのうちの複数と接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

（第１３の実施形態）
第１３の実施形態では、第１〜第４のいずれかの実施形態に係る無線通信装置（アクセスポイントの無線通信装置または端末の無線通信装置、またはこれらの両方）の構成に加えて、ディスプレイを含む。ディスプレイは、図示しないバスを介して、無線通信装置の制御部（１０１または２０１）に接続されてもよい。このようにディスプレイを備える構成とし、無線通信装置の動作状態をディスプレイに表示することで、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

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

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

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

制御フレームは、データフレームを他の無線通信装置との間で送受（交換）する際の制御に用いられるフレームである。無線通信装置がデータフレームや管理フレームを受信した場合にその送達確認のために送信される応答フレームは、制御フレームに属する。

これら３種類のフレームは、物理層で必要に応じた処理を経て物理パケットとしてアンテナを経由して送出される。なお、接続確立の手順においては、接続要求フレームと接続受付フレームが管理フレームであり、接続受付フレームへの確認フレームは制御フレームの応答フレームを用いることができる。

［２］無線通信装置間の接続切断の手法
接続の切断には、明示的な手法と暗示的な手法とがある。明示的な手法としては、接続している無線通信装置のいずれか一方が切断のためのフレームを送信する。このフレームは管理フレームに分類される。切断のためのフレームは、例えば接続をリリースするという意味でリリースフレームと呼ぶことがある。通常、リリースフレームを送信する側の無線通信装置ではリリースフレームを送信した時点で、リリースフレームを受信する側の無線通信装置ではリリースフレームを受信した時点で、接続の切断と判定する。その後、通信フェーズでの初期状態、例えば通信相手の無線通信装置を探索する状態に戻る。これは、切断のためのフレームを送信する際には、接続先の無線通信装置と通信距離が離れて無線信号が受信不可あるいは復号不可になるといった、物理的な無線リンクが確保できないことがあるからである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１：アクセスポイント（端末）
１２Ａ、１２Ｂ、１２Ｃ、１２Ｄ：アンテナ
１、２、３、４：無線通信端末（端末）
１Ａ、２Ａ、２Ｂ、３Ａ、４Ａ：アンテナ
５０１：トリガーフレーム
Ｔ１、Ｔ２：期間
１０１、２０１：制御部
１０２、２０２：送信部
１０３、２０３：受信部
１０４、２０４：バッファ
１１１：ベースバンドＩＣ
１１３：メモリ
１１４：ホスト・インターフェース
１１５：ＣＰＵ
１１６：ＤＡＣ
１１７：ＡＤＣ
１２１：ＲＦ ＩＣ
１２２、１３２：フィルタ
１２３、１３３：ミキサ
１２４、１３４：アンプ
１２５、１３５：バラン
１４２：ＰＬＬ
１４３：水晶発振器
１４７：アンテナ
１４５：スイッチ
１４８：無線ＬＡＮモジュール
１４９：ホストシステム
３０１：ノートＰＣ
３０５、３１５、３５５：無線通信装置
３２１：移動体端末
３３１：メモリーカード
３３２：メモリーカード本体

Claims (30)

1. 複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、ＲＦ集積回路を介して送信し、
   前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記ＲＦ集積回路を介して受信し、
   前記複数の第２フレームそれぞれの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記ＲＦ集積回路を介して送信する、ベースバンド集積回路を備え、
   前記ベースバンド集積回路は、前記情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定する
   無線通信用集積回路。
2. 前記ベースバンド集積回路は、
   前記複数の無線通信端末の識別情報を複数の第１フィールドに指定した前記第１フレームを送信し、
   前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を、前記複数の無線通信端末の識別情報が指定された前記第１フィールドの位置に応じて決定する
   請求項１に記載の無線通信用集積回路。
3. 前記ベースバンド集積回路は、
   前記第１フレームは、前記複数の無線通信端末が使用する前記周波数成分を指定する情報を含み、
   前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を、前記複数の無線通信端末に指定した前記周波数成分に応じて決定する
   請求項１に記載の無線通信用集積回路。
4. 前記ベースバンド集積回路は、前記複数の無線通信端末が属するグループの識別情報と、第１の順序で配置した前記複数の無線通信端末の識別情報とを含む第４フレームを送信し、
   前記第１フレームは、前記グループの識別情報を指定しており、
   前記ベースバンド集積回路は、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を、前記第１の順序に応じて決定する
   請求項１に記載の無線通信用集積回路。
5. 前記第１フレームは、前記複数の無線通信端末の識別情報を複数の第１フィールドに指定しており、
   前記複数の無線通信端末から送信される前記複数の第２フレームは、シーケンス番号が付与された複数の第５フレームを集約したものであり、
   前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組を、前記複数の無線通信端末毎に配置しており、
   前記ベースバンド集積回路は、前記第３フレームにおいて各無線通信端末の前記組を配置する位置を、各無線通信端末の識別情報が指定された前記第１フィールドの位置に応じて決定する
   請求項１に記載の無線通信用集積回路。
6. 前記第１フレームは、前記複数の無線通信端末が使用する前記周波数成分を指定する情報を含み、
   前記複数の無線通信端末から送信される前記複数の第２フレームは、シーケンス番号が付与された複数の第５フレームを集約したものであり、
   前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組を、前記複数の無線通信端末毎に配置しており、
   前記ベースバンド集積回路は、前記第３フレームにおいて各無線通信端末の前記組を配置する位置を、各無線通信端末に指定した前記周波数成分に応じて決定する、
   請求項１に記載の無線通信用集積回路。
7. 前記ベースバンド集積回路は、前記複数の無線通信端末が属するグループの識別情報と、第１の順序で配置した前記複数の無線通信端末の識別情報とを含む第４フレームを送信し、
   前記第１フレームは、前記グループの識別情報を指定しており、
   前記複数の無線通信端末から送信される前記複数の第２フレームは、シーケンス番号が付与された複数の第５フレームを集約したものであり、
   前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組を、前記複数の無線通信端末毎に配置しており、
   前記ベースバンド集積回路は、前記第３フレームにおいて各無線通信端末の前記組を配置する位置を、前記第１の順序に応じて決定する、
   請求項１に記載の無線通信用集積回路。
8. 前記ベースバンド集積回路は、前記複数の無線通信端末による周波数多重送信を行うために必要な第１情報、または前記複数の無線通信端末が前記複数の周波数成分ごとに空間多重送信を行うために必要な第２情報を含む前記第１フレームを、前記ＲＦ集積回路を介して送信し、
   前記ベースバンド集積回路は、前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記ＲＦ集積回路を介して受信し、または、前記複数の周波数成分ごとに空間多重で送信される前記複数の第２フレームを受信し、
   前記ベースバンド集積回路は、前記第１情報または前記第２情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定し、
   前記第３フレームは、前記周波数多重送信、および、前記複数の周波数成分ごとの空間多重送信のいずれの方式に対する送達確認応答かを特定するための第３情報を含む
   請求項１に記載の無線通信用集積回路。
9. 前記第１フレームは、前記周波数多重送信、および、前記複数の周波数成分ごとの空間多重送信、のいずれの方式を実行するかを指定する第４情報を含む
   請求項８に記載の無線通信用集積回路。
10. 前記ベースバンド集積回路は、前記第１情報、前記第２情報、空間多重送信を行うために必要な第３情報を含む前記第１フレームを、前記ＲＦ集積回路を介して送信し、
    前記ベースバンド集積回路は、前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記ＲＦ集積回路を介して受信し、または、前記複数の周波数成分ごとに空間多重で送信される前記複数の第２フレームを受信し、または、前記空間多重送信される前記複数の第２フレームを受信し、
    前記ベースバンド集積回路は、前記第１情報、前記第２情報または前記第３情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定し、
    前記第３フレームは、前記周波数多重送信、前記複数の周波数成分ごとの空間多重送信、および、前記空間多重送信のいずれの方式に対する送達確認応答かを特定するための前記第３情報を含む
    請求項８に記載の無線通信用集積回路。
11. 前記第１フレームは、前記周波数多重送信、前記複数の周波数成分ごとの空間多重送信、および、前記空間多重送信のいずれの方式を実行するかを指定する第５情報を含む
    請求項１０に記載の無線通信用集積回路。
12. 無線基地局である請求項１ないし１１のいずれか一項に記載の無線通信用集積回路。
13. ＩＥＥＥ８０２．１１規格に従って通信を制御する
    請求項１ないし１２のいずれか一項に記載の無線通信用集積回路。
14. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路は、前記第１フレームおよび前記第３フレームをＤＡ変換し、
    前記ＲＦ集積回路は、ＤＡ変換後の前記第１フレームおよび前記第３フレームを無線周波数にアップコンバートし、
    前記ＲＦ集積回路は、前記第２フレームをベースバンド周波数にダウンコンバートし、
    前記ベースバンド集積回路は、ダウンコンバート後の前記第２フレームをＡＤ変換する
    請求項１ないし１３のいずれか一項に記載の無線通信用集積回路。
15. 前記ベースバンド集積回路および前記ＲＦ集積回路が１つの集積回路で構成された
    請求項１４に記載の無線通信用集積回路。
16. 複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、ＲＦ集積回路を介して受信し、
    前記周波数多重送信で用いられる複数の周波数成分のうちの少なくとも１つの周波数成分を用いて、第２フレームを、ＲＦ集積回路を介して送信し、
    前記複数の無線通信端末の前記第２フレームの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記ＲＦ集積回路を介して受信し、
    前記第１フレームに含まれる前記情報に基づいて、自端末の前記検査結果が割り当てられた前記ビットの位置を特定する、ベースバンド集積回路
    を備えた無線通信用集積回路。
17. 前記第１フレームは、前記複数の無線通信端末の識別情報を複数の第１フィールドに指定しており、
    前記ベースバンド集積回路は、自端末の前記検査結果を割り当てられた前記ビットの位置を、前記自端末の識別情報が指定された前記第１フィールドの位置に応じて決定する
    請求項１６に記載の無線通信用集積回路。
18. 前記第１フレームは、前記複数の無線通信端末が使用する前記周波数成分を指定する情報を含み、
    前記ベースバンド集積回路は、自端末の前記検査結果を割り当てられた前記ビットの位置を、前記自端末に指定された前記周波数成分に応じて決定する
    請求項１６に記載の無線通信用集積回路。
19. 前記ベースバンド集積回路は、前記複数の無線通信端末が属するグループの識別情報と、第１の順序で配置した前記複数の無線通信端末の識別情報とを含む第４フレームを、前記ＲＦ集積回路を介して受信し、
    前記第１フレームは、自端末が属する前記グループの識別情報を指定しており、
    前記ベースバンド集積回路は、前記自端末の前記検査結果を割り当てられた前記ビットの位置を、前記第１の順序に応じて決定する
    請求項１６に記載の無線通信用集積回路。
20. 前記第１フレームは、前記複数の無線通信端末の識別情報を複数の第１フィールドに指定しており、
    前記第２フレームは、シーケンス番号が付与された複数の５フレームを集約したものであり、
    前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組、を前記複数の無線通信端末毎に配置しており、
    前記ベースバンド集積回路は、自端末用の前記組が配置された位置を、前記第１フレームにおいて前記自端末の前記識別情報が指定された前記第１フィールドの位置に応じて決定する
    請求項１６に記載の無線通信用集積回路。
21. 前記第１フレームは、前記複数の無線通信端末が使用する前記周波数成分を指定する情報を含み、
    前記第２フレームは、シーケンス番号が付与された複数の５フレームを集約したものであり、
    前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組、を前記複数の無線通信端末毎に配置しており、
    前記ベースバンド集積回路は、自端末用の前記組が配置された位置を、前記自端末に指定された前記周波数成分に応じて決定する、
    請求項１６に記載の無線通信用集積回路。
22. 前記ベースバンド集積回路は、前記複数の無線通信端末が属するグループの識別情報と、第１の順序で配置した前記複数の無線通信端末の識別情報とを含む第４フレームを、前記ＲＦ集積回路を介して受信し、
    前記第１フレームは、自端末が属する前記グループの識別情報を指定しており、
    前記第２フレームは、シーケンス番号が付与された複数の５フレームを集約したものであり、
    前記第３フレームは、前記第２フレームに含まれる前記複数の第５フレームのシーケンス番号のうち受信に成功した最も小さいシーケンス番号を特定する情報と、前記最も小さいシーケンス番号以降のシーケンス番号の前記第５フレームの前記検査結果を割り当てた複数のビットを含む第２ビットマップとの組、を前記複数の無線通信端末毎に配置しており、
    前記ベースバンド集積回路は、自端末用の前記組が配置された位置を、前記第１の順序に応じて決定する、
    請求項１６に記載の無線通信用集積回路。
23. 前記第１フレームは、前記複数の周波数成分ごとに空間多重送信を行うために必要な情報を含み、
    前記ベースバンド集積回路は、前記周波数成分と、前記空間多重送信で用いられる複数のプリアンブルのうちの１つプリアンブルとに基づき、前記第２フレームを送信し、
    前記第１フレームに含まれる前記情報に基づいて、自端末の前記検査結果を割り当てられた前記ビットの位置を特定する
    請求項１６ないし１７のいずれか一項に記載の無線通信用集積回路。
24. ＩＥＥＥ８０２．１１規格に従って通信を制御する
    請求項１６ないし２３のいずれか一項に記載の無線通信用集積回路。
25. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路は、前記第１フレームおよび前記第３フレームをＤＡ変換し、
    前記ＲＦ集積回路は、ＤＡ変換後の前記第１フレームおよび前記第３フレームを無線周波数にアップコンバートし、
    前記ＲＦ集積回路は、前記第２フレームをベースバンド周波数にダウンコンバートし、
    前記ベースバンド集積回路は、ダウンコンバート後の前記第２フレームをＡＤ変換する
    請求項１６ないし２４のいずれか一項に記載の無線通信用集積回路。
26. 前記ベースバンド集積回路および前記ＲＦ集積回路が１つの集積回路で構成された
    請求項１６ないし２５のいずれか一項に記載の無線通信用集積回路。
27. 少なくとも１つのアンテナと、
    前記アンテナに接続され、フレームを送受信する無線通信部と、
    複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、前記無線通信部を介して送信し、
    前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを、前記無線通信部を介して受信し、
    前記複数の第２フレームそれぞれの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記無線通信部を介して送信する、制御部とを備え、
    前記制御部は、前記情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定する
    無線通信端末。
28. 少なくとも１つのアンテナと、
    前記アンテナに接続され、フレームを送受信する無線通信部と、
    複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを、前記無線通信部を介して受信し、
    前記周波数多重送信で用いられる複数の周波数成分のうちの少なくとも１つの周波数成分を用いて、第２フレームを、前記無線通信部を介して送信し、
    前記複数の無線通信端末の前記第２フレームの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを、前記無線通信部を介して受信し、
    前記第１フレームに含まれる前記情報に基づいて、自端末の前記検査結果が割り当てられた前記ビットの位置を特定する、制御部と
    を備えた無線通信端末。
29. 複数の無線通信端末による周波数多重送信を行うために必要な情報を含む第１フレームを送信し、
    前記周波数多重送信で用いられる複数の周波数成分で、複数の第２フレームを受信し、
    前記複数の第２フレームそれぞれの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを送信し、
    前記情報に基づいて、前記複数の無線通信端末の前記検査結果を割り当てる複数の前記ビットの位置を決定する
    無線通信方法。
30. 複数の無線通信端末の周波数多重送信を行うために必要な情報を含む第１フレームを受信し、
    前記周波数多重送信で用いられる複数の周波数成分のうちの少なくとも１つの周波数成分を用いて、第２フレームを送信し、
    前記複数の無線通信端末の前記第２フレームの受信に成功したか否かの検査結果を割り当てた複数のビットを含む第１ビットマップを含む第３フレームを受信し、
    前記第１フレームに含まれる前記情報に基づいて、自端末の前記検査結果が割り当てられた前記ビットの位置を特定する、
    無線通信方法。

Images