JP2020005266A - 無線通信装置及び無線通信方法 - Google Patents

Abstract

【課題】システム効率の低下を抑制しつつユーザ多重送信を行う。【解決手段】本発明の一態様としての無線通信装置は、アップリンクのユーザ多重送信に必要な第１情報を含む第１フレームを、前記第１情報の送信要求を受けること無く、送信する第１回路を備える。【選択図】図１

Description

本発明の実施形態は、無線通信装置及び無線通信方法に関する。

複数の無線通信端末（以下、端末）宛ての送信または複数の端末からの受信を同時に行うＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）と呼ばれる通信方式が知られている。１つまたは複数のサブキャリアをリソースブロックとして端末に割り当て、リソースブロックベースで、複数の端末宛ての送信または複数の端末からの受信を同時に行うＯＦＤＭＡは、特にリソースブロックベースのＯＦＤＭＡと呼ぶ場合もある。基地局から複数の端末宛ての同時送信はダウンリンクＯＦＤＭＡ送信、複数の端末から基地局への同時送信はＵＬ−ＯＦＤＭＡ送信に相当する。

複数の端末から基地局に空間多重で（同一周波数帯域で同時に）ストリームを送信し、基地局が複数のアンテナでこれらストリームを同時に受信する、アップリンクマルチユーザＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）と呼ばれる通信方式が知られている。また、基地局から複数の端末に空間多重で（同一周波数帯域で同時に）ストリームを送信し、各端末で自端末宛のストリームを受信するダウンリンクマルチユーザＭＩＭＯと呼ばれる方式も知られている。

アップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）またはアップリンクマルチユーザＭＩＭＯ（ＵＬ−ＭＵ−ＭＩＭＯ：Ｕｐｌｉｎｋ Ｍｕｔｉ−Ｕｓｅｒ ＭＵ−ＭＩＭＯ）の通信を行う場合、各端末のアップリンク送信のタイミングを揃えるために、基地局からトリガーフレームを送信することが考えられる。各端末はトリガーフレームの受信から一定時間後に送信することで、送信のタイミングを揃え、アップリンク多重送信（ＵＬ−ＯＦＤＭまたはＵＬ-ＭＵ-ＭＩＭＯ）が実現される。トリガーフレームの送信前には、ＵＬ−ＯＦＤＭＡまたはＵＬ-ＭＵ-ＭＩＭＯの対象となる端末の選定や送信のパラメータ情報など、アップリンク多重送信に必要な事項の決定を含むスケジューリングが必要であるが、通信のリソースは限られているため、できるだけシステム効率を高めることができるようなスケジューリングが望まれる。仮に送信するデータを有さない端末を対象端末として選択すると、その端末に割り当てた通信リソースがアップリンク送信期間で有効活用されず、システム効率が低下する可能性がある。また、必要事項の決定を効率的に行うために基地局が各端末から事前に情報を収集しようとすると、基地局の処理が複雑になるとともに、収集の期間が長くなるとシステム効率が低下する可能性がある。

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

本発明の実施形態は、システム効率の低下を抑制しつつユーザ多重送信を実現する。

本発明の一態様としての無線通信装置は、アップリンクのユーザ多重送信に必要な第１情報を含む第１フレームを、前記第１情報の送信要求を受けること無く、送信する第１回路を備える。

本発明の実施形態に係る無線通信装置の機能ブロック図。 ＵＬ−ＭＵ−ＭＩＭＯ送信およびＵＬ−ＯＦＤＭＡ送信の概要の説明図。 ＯＦＤＭＡ通信とリソースブロックの割り当てを説明するための図。 基地局と複数の端末とを含む無線通信グループを示す図。 ＭＡＣフレームの基本的なフォーマット例を示す図。 情報エレメントのフォーマット例を示す図。 本発明の実施形態に係る動作シーケンスの例を示す図。 通知情報フィールドを含むフォーマット例を示す図。 アクセスカテゴリ別にＵＬ−ＭＵ送信の要求の有無を表すフォーマットの例を示す図。 アクセスカテゴリ別の送信用のデータ有無を通知する具体的な動作例を示す図。 トリガーフレームのフォーマット例を示す図。 トリガーフレームを含む物理パケットのフォーマット例を示す図。 複数の端末からＵＬ−ＭＵ−ＭＩＭＯ送信される物理パケットの概略構成を示す図。 本発明の実施形態に係る動作シーケンスの他の例を示す図。 本発明の実施形態に係る動作シーケンスのさらに他の例を示す図。 本発明の実施形態に係る端末の動作の一例のフローチャートを示す図。 本発明の実施形態に係る基地局の動作の一例のフローチャートを示す図。 本発明の実施形態に係る基地局の動作の他の例のフローチャートを示す図。 第２の実施形態に係る基地局または端末の機能ブロック図。 第３の実施形態に係る端末または基地局の全体構成例を示したものである。 第３の実施形態に係る基地局または端末に搭載される無線通信装置のハードウェア構成例を示す図。 本発明の実施形態に係る無線通信端末の斜視図。 本発明の実施形態に係るメモリーカードを示す図。 コンテンション期間のフレーム交換の一例を示す図。

以下、図面を参照しながら、本発明の実施形態について説明する。無線ＬＡＮの規格として知られているＩＥＥＥ Ｓｔｄ ８０２．１１−２０１２およびＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３、ならびに、次世代無線ＬＡＮ規格であるＩＥＥＥ Ｓｔｄ ８０２．１１ａｘ用の仕様フレームワーク文書（Specification Framework Document）であるＩＥＥＥ ８０２．１１−１５／０１３２ｒ１５は、本明細書においてその全てが参照によって組み込まれる（ｉｎｃｏｒｐｏｒａｔｅｄ ｂｙ ｒｅｆｅｒｅｎｃｅ）ものとする。

（第１の実施形態）
図１に、第１の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局（以下、基地局）、または無線通信基地局と通信する無線通信端末（以下、端末）に実装されることができる。基地局は、主に中継機能を有する点で端末とは異なり、その他は基本的に端末と同様の通信機能を有するため、端末の一形態であると考えることができる。以下の説明で端末と言うときは、特に両者を区別する必要がない限り、基地局を指してもよい。

本実施形態では、アップリンクＭＵ−ＭＩＭＯ（ＵＬ−ＭＵ−ＭＩＭＯ：Ｕｐｌｉｎｋ Ｍｕｔｉ−Ｕｓｅｒ ＭＵ−ＭＩＭＯ）およびアップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）の少なくともいずれかのアップリンクマルチユーザ（ＵＬ−ＭＵ）送信を行う場合を想定する。なお、基地局および端末は、ＵＬ−ＭＵ（ＵＬ−ＭＵ−ＭＩＭＯまたはＵＬ−ＯＦＤＭＡ）のみならず、ダウンリンクＭＵ−ＭＩＭＯ（ＤＬ−ＭＵ−ＭＩＭＯ）およびダウンリンクＯＦＤＭＡ（ＤＬ−ＯＦＤＭＡ）の少なくともいずれかのダウンリンクマルチユーザ（ＤＬ−ＭＵ）送信を実施する能力を有していてもよい。ＵＬ−ＭＵ送信は、アップリンクのユーザ多重送信に対応し、ＤＬ−ＭＵ送信は、ダウンリンクのユーザ多重送信に対応する。なお、ＵＬ−ＭＵ送信としてＵＬ−ＭＵ−ＭＩＭＯとＵＬ−ＯＦＤＭＡを組み合わせた通信方式、およびＤＬ−ＭＵ送信ＤＬ−ＭＵ−ＭＩＭＯとＤＬ−ＯＦＤＭＡを組み合わせた通信方式も可能である。

図２（Ａ）にＵＬ−ＭＵ−ＭＩＭＯ送信の概要を示す。ＵＬ−ＭＵ−ＭＩＭＯ送信では、複数の端末から基地局に空間多重で（同一周波数帯域で同時に）、データストリーム（以下ストリーム）を送信し、基地局が複数のアンテナでこれらストリームを同時に受信する。図の例では、複数の端末１〜４（ＳＴＡ１〜ＳＴＡ４）が、基地局であるアクセスポイント（ＡＰ）に、１チャネル（ここではチャネルＭと記述している）幅の同一周波数帯域で同時にストリームを送信、すなわち空間多重送信する。アクセスポイントが、これらのストリームを同時に受信し、ＭＩＭＯ復調することで、各端末のフレームに分離する。ＵＬ−ＭＵ−ＭＩＭＯ送信では、同時に複数の端末からフレームを送信できるため、システムスループットを向上させることができる。なお、ＵＬ−ＭＵ−ＭＩＭＯ送信の最大の多重可能なデータストリームの数は、アクセスポイントのアンテナ数によって制限される。一例として、アクセスポイントが４つのアンテナを有する場合、最大多重可能ストリーム数は４である。各端末が１つのアンテナを備える場合、それぞれ１ストリームのみを送信可能である。ある１台の端末が、複数のアンテナを備えて、複数のストリームの送信を行うことも可能である。なお、ＤＬ−ＭＵ−ＭＩＭＯの場合、通信の方向が、アクセスポイントから各端末への方向になる点が異なる。ＤＬ−ＭＵ−ＭＩＭＯでは、基地局から複数の端末に空間多重で（同一周波数帯域で同時に）ストリームを送信し、各端末は自端末宛のストリームを受信して復号する。

図２（Ｂ）にＵＬ−ＯＦＤＭＡ送信の概要を示す。ＵＬ−ＯＦＤＭＡでは、１つまたは複数のサブキャリアをリソースブロック（サブチャネル、リソースユニット、周波数ブロックと呼んでもよい）として端末に割り当て、リソースブロックベースで、複数の端末からの受信を同時に行う。図の例では、１チャネル（ここではチャネルＭと記述している）内の連続した周波数領域内で１つまたは複数の連続するサブキャリアを一単位とするリソースブロックを端末に各々割り当てて、複数端末から同時に受信を行う。より詳細には、アクセスポイント（ＡＰ）が、１チャネルに含まれる４つのリソースブロック（ＲＢ）１〜４を、複数の端末１〜４（ＳＴＡ１〜４）にそれぞれ割り当て、複数の端末１〜４からそれぞれに割り当てられたリソースブロックで同時に送信する。これにより、端末１〜４から基地局へのＵＬ−ＯＦＤＭＡ送信を行う。各端末に割り当てるリソースブロックは、互いに異なり、互いに重複しない。なお、ＤＬ−ＯＦＤＭＡの場合、通信の方向が、アクセスポイントから各端末への方向になる点が異なる。ＤＬ−ＯＦＤＭＡでは、１つまたは複数のサブキャリアをリソースブロックとして端末に割り当て、リソースブロックベースで、アクセスポイントから複数の端末に同時に送信を行う。

ＯＦＤＭＡについてさらに詳細に説明する。図３に、周波数領域に複数のチャネルが配置される様子を示す。チャネル間にはガードバンドが設けられている。１つのチャネルの帯域幅は、例えば２０ＭＨｚである。そのうちの１つのチャネル（ここではチャネルＭ）の連続する帯域を用いてＯＦＤＭＡ通信を行う場合が、図２（Ｂ）に対応する。チャネルＭの連続する帯域（例えば２０ＭＨｚ幅帯域）には互いに直交する複数のサブキャリア（２０ＭＨｚ帯域の場合、例えば５２本）が配置されており、これらのサブキャリアに基づき、１つまたは複数の連続するサブキャリアを一単位とするリソースブロックを端末１、端末２、・・・端末Ｋ（Ｋは２以上の整数。図２（Ｂ）の例ではＫ＝４）に割り当てる。なお、リソースブロックごとの帯域幅（あるいはサブキャリア数）は各リソースブロックで共通とするが、リソースブロックごとに帯域幅（あるいはサブキャリア数）が異なることを許容してもよい。また、各端末に割り当てるリソースブロック数は、端末１台あたり１つのリソースブロックであることに限定されず、１台に複数のリソースブロックを割り当ててもよいし、端末ごとに割り当てるリソースブロック数が異なってもよい。リソースブロックが複数のサブキャリアで構成される場合は、リソースブロックに含まれる各サブキャリアの配置が連続していても連続していなくてもよい。１台の端末に、リソースブロックとして、非連続に配置された複数のサブキャリアを割り当てることも可能である。

また、図３の例では、各端末に割り当てるリソースブロック間に少なくとも１つのサブキャリアが、ガードサブキャリアとして配置されている。リソースブロック間に配置するガードサブキャリアの個数は、事前にシステムまたは仕様で定められていてもよいし、任意に定めてもよい。また、リソースブロック間にガードサブキャリアを配置することは必須ではなく、リソースブロック間にガードサブキャリアを配置しないことを許容してもよい。

またＯＦＤＭＡ通信で使用するチャネル数は、１つに限定されず、２つ以上のチャネルを用いてＯＦＤＭＡ通信を行うことも可能である。この際、チャネルごとに独立して、上述のように各チャネル内でリソースブロックの割り当てを行ってもよい。この際、１つの端末が異なるチャネルに属する複数のリソースブロックの割り当てを受けることを許容してもよい。またチャネルごとに独立してリソースブロックの割り当てを行うのではなく、複数のチャネルを結合した連続した周波数領域を定義し、当該結合後の周波数領域内でリソースブロックの割り当てを行ってもよい。例えば周波数的に隣接する２０ＭＨｚ幅の２つのチャネルを結合して４０ＭＨｚの周波数領域を定義し、当該４０ＭＨｚの周波数領域内の互いに直交するサブキャリア群に基づきリソースブロックの割り当てを行ってもよい。同様に、２０ＭＨｚ幅の４つのチャネルを結合して８０ＭＨｚの周波数領域、８つのチャネルを結合して１６０ＭＨｚの周波数領域を定義してもよい。この場合、それぞれの周波数領域内で互いに直交するサブキャリア群に基づき、リソースブロックの割り当てを行えばよい。

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

なお、ＯＦＤＭＡは上述したリソースブロックベースのＯＦＤＭＡ以外に、チャネルベースでのＯＦＤＭＡも可能である。この場合のＯＦＤＭＡを特にＭＵ−ＭＣ（Ｍｕｌｔｉ−Ｕｓｅｒ Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ）と呼ぶことがある。ＭＵ−ＭＣでは、基地局が複数のチャネルを複数の端末に割り当て、当該複数のチャネルを同時に用いて、複数端末宛て同時送信もしくは複数端末からの同時受信を行う。以降に説明する本実施形態のＯＦＤＭＡでは、リソースブロックベースのＯＦＤＭＡを想定するが、以降の説明のリソースブロックをチャネルに読み替えるなど、チャネルベースのＯＦＤＭＡに即して必要な読み替えを行うことで、チャネルベースのＯＦＤＭＡの実施形態も実現可能である。

ＯＦＤＭＡと、ＭＵ−ＭＩＭＯとを組み合わせた通信方式（ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯと呼ぶ）も可能である。この通信方式では、複数のリソースブロックのそれぞれを、複数の端末に割り当て、複数のリソースブロックのそれぞれで同時に、リソースブロック単位でのＭＵ−ＭＩＭＯ送信を行うことになる。アップリンクのＯＦＤＭＡ＆ＭＵ−ＭＩＭＯ、ダウンリンクのＯＦＤＭＡ＆ＭＵ−ＭＩＭＯのいずれも可能である。以降の説明でＯＦＤＭＡまたはＭＵ−ＭＩＭＯを指すときは、ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯでもよいものとする。

以下の説明において、ＵＬ−ＯＦＤＭＡおよびＵＬ−ＭＵ−ＭＩＭＯの少なくとも一方を実施する能力を有する端末をＵＬ−ＭＵ端末と呼ぶことがある。当該能力を有さない端末をレガシー端末と呼ぶことがある。ＵＬ−ＭＵ通信を実施する能力を有効（Ｅｎａｂｌｅ）または無効（Ｄｉｓａｂｌｅ）に切り替え可能な場合、当該能力が有効になっている端末をＵＬ−ＭＵ端末として考えればよい。ＵＬ−ＭＵ端末は、ＤＬ−ＯＦＤＭＡおよびＤＬ−ＭＵ−ＭＩＭＯの少なくとも一方を実施する能力をさらに備えていてもよい。また、ＵＬ−ＭＵ端末のうち今回のＵＬ-ＭＵ通信の対象として基地局に指定された端末は、ＵＬ-ＭＵの対象端末に相当し、今回のＵＬ-ＭＵの対象として基地局に指定されなかった端末は、ＵＬ-ＭＵの非対象端末に相当する。

図１に示されるように、端末（非基地局の端末及び基地局）に搭載される無線通信装置は、上位処理部９０、ＭＡＣ処理部１０、ＰＨＹ（Ｐｈｙｓｉｃａｌ：物理）処理部５０、ＭＡＣ／ＰＨＹ管理部６０、アナログ処理部７０（アナログ処理部１〜Ｎ）及びアンテナ８０（アンテナ１〜Ｎ）を含む。Ｎは１以上の整数である。図では、Ｎ個のアナログ処理部と、Ｎ個のアンテナが、一対ずつ接続されているが、必ずしもこの構成に限定されるものではない。例えばアナログ処理部の個数が１つで、２つ以上のアンテナがこのアナログ処理部に共通に接続されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＭＡＣ／ＰＨＹ管理部６０は、管理情報ベース（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ：ＭＩＢ）を保持する。ＭＩＢは、自端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、自端末が、ＵＬ−ＭＵ対応端末であるか否か、また、ＵＬ−ＭＵ対応端末の場合にＵＬ−ＭＵを実施する能力の機能のオン／オフの情報も保持されていてもよい。ＭＩＢを保持・管理するためのメモリは、ＭＡＣ／ＰＨＹ管理部６０に内包させてもよいし、ＭＡＣ／ＰＨＹ管理部６０に内包せずに別に設けるようにしてもよい。ＭＩＢを保持・管理するためのメモリをＭＡＣ／ＰＨＹ管理部６０とは別に設ける場合に、ＭＡＣ／ＰＨＹ管理部６０は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。メモリはＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。また、メモリでなく、ＳＳＤやハードディスク等の記憶装置でもよい。基地局では、非基地局としての他の端末のこれらの情報も、当該端末からの通知により、取得することができる。その場合、ＭＡＣ／ＰＨＹ管理部６０は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、ＭＩＢとは別に保持・管理するようにしてもよい。その場合、ＭＡＣ／ＰＨＹ管理部６０あるいはＭＡＣ共通処理部２０が、その別のメモリを参照・書き換えが可能なようにする。また基地局のＭＡＣ／ＰＨＹ管理部６０は、ＵＬ−ＭＵ送信にあたり、非基地局としての端末に関する各種の情報、または端末からの要求に基づき、ＵＬ−ＭＵ通信用のリソースブロックを同時に割り当てる端末を選定する（すなわち今回のＵＬ−ＭＵの対象となる端末を選定する）グルーピング機能も備えていてもよい。また、ＭＡＣ／ＰＨＹ管理部６０またはＭＡＣ処理部１０は、送信するＭＡＣフレームおよび物理ヘッダに適用する伝送レートを管理してもよい。また基地局のＭＡＣ／ＰＨＹ管理部６０は、基地局がサポートするレートセットであるサポートレートセットを定義してもよい。サポートレートセットは、自局に接続する端末がサポートすることが必須のレートと、オプションのレートを含んでもよい。

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

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

管理フレームに関連して、送信処理部３０は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。非基地局としての端末の通知手段は、ＵＬ−ＭＵ対応端末、ＩＥＥＥ８０２．１１ｎ対応端末、ＩＥＥＥ８０２．１１ａｃ対応端末のいずれに対応しているかの情報を、管理フレームに入れて送信することで、基地局に自端末の種別を通知してもよい。この管理フレームとしては、例えば端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームや、あるいはリアエソシエーションプロセスで用いられるＲｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームがある。基地局の通知手段は、非基地局の端末に、ＵＬ−ＭＵ通信への対応可否の情報を、管理フレームを介して通知してもよい。これに用いる管理フレームとしては、例えばＢｅａｃｏｎフレームや、非基地局端末が送信したＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームに対する応答であるＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームがある。基地局は、自装置に接続している端末群をグループ化する機能を有していてもよい。基地局の上記の通知手段は、各端末にそれぞれ割り当てられたグループのグループＩＤを、管理フレームを介して通知してもよい。この管理フレームとしては、例えばＧｒｏｕｐ ＩＤ Ｍａｎａｇｅｍｅｎｔフレームがある。グループＩＤは、例えばＩＥＥＥ Ｓｔｄ ８０２．１１ａｃ−２０１３で規定されたグループＩＤでもよい。また、基地局は、当該グループ単位でＵＬ−ＭＵ通信をする場合に、当該グループに属する端末が使用するリソースブロックを特定するために必要な情報を、任意の管理フレームを介して通知してもよい。

受信処理部４０は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、基地局の受信手段は、非基地局としての端末からＵＬ−ＭＵ通信への対応可否の情報を受信してもよい。また、当該端末がレガシー端末（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末など）の場合に対応可能なチャネル幅（利用可能な最大のチャネル幅）の情報を受信してもよい。端末の受信手段は、基地局からＵＬ−ＭＵ通信への対応可否の情報を受信してもよい。

上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末（基地局を含む）間で送受信することが可能である。例えばＵＬ−ＭＵ対応端末は、自身がＵＬ−ＭＵ送信で使用することを希望するリソースブロック、または、チャネル、またはこれらの両方を、キャリアセンスで非干渉のチャネル、または、非干渉のリソースブロック、またはこれらの両方から、選択してもよい。そして、選択したリソースブロックまたはチャネルまたはこれらの両方に関する情報を、基地局に通知してもよい。この場合、基地局は当該情報に基づき、ＵＬ−ＭＵ通信のためのリソースブロック割り当てを各ＵＬ−ＭＵ対応端末に対して行ってもよい。なお、ＵＬ−ＭＵ通信で利用するチャネルは、無線通信システムとして利用可能な全てのチャネルであっても、一部（１つまたは複数）のチャネルであってもよい。

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

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

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

受信処理部４０は、上述したキャリアセンス情報を管理する。キャリアセンス情報は、例えばチャネルごとに管理する。このキャリアセンス情報は、ＰＨＹ処理部５０から入力される媒体（ＣＣＡ）のビジー／アイドルに関する物理的なキャリアセンス（Ｐｈｙｓｉｃａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス（Ｖｉｒｔｕａｌ Ｃａｒｒｉｅｒ Ｓｅｎｓｅ）情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、ＩＥＥＥ８０２．１１規格において、媒体予約時間は、ＭＡＣヘッダの中のＤｕｒａｔｉｏｎフィールドに記載される。ＭＡＣ処理部１０は、他の無線通信装置宛ての（自己宛てでない）ＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれる。媒体予約時間は無線媒体へのアクセスの抑制を指示する期間の長さ、すなわち無線媒体へのアクセスを延期させる期間の長さを表しているといえる。

ここで、データフレームは、複数のＭＡＣフレームもしくは複数のＭＡＣフレームのペイロード部分を連接するようになっていてもよい。前者はＩＥＥＥ８０２．１１規格ではＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＰＤＵ、後者はＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＳＤＵ（ＭＡＣ ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）と呼ばれる。Ａ−ＭＰＤＵの場合は、ＰＳＤＵの中に複数のＭＰＤＵが連接されることになる。またデータフレームのみならず、管理フレームや制御フレームも連接対象となる。Ａ−ＭＳＤＵの場合には、１つのＭＰＤＵのフレームボディ中に、複数のデータペイロードであるＭＳＤＵが連接されることになる。Ａ−ＭＰＤＵ、およびＡ−ＭＳＤＵのいずれも、複数のＭＰＤＵの連接、および複数のＭＳＤＵの連接を、受信側端末で適切に分離できるように、データフレームに区切り情報（長さ情報など）が格納されている。Ａ−ＭＰＤＵおよびＡ−ＭＳＤＵの両方を組み合わせて用いてもよい。またＡ−ＭＰＤＵは、複数のＭＡＣフレームではなく、１つのＭＡＣフレームのみを対象としてもよく、この場合も区切り情報をデータフレームに格納する。また、データフレームがＡ−ＭＰＤＵなどの場合は、複数のＭＡＣフレームに対する応答をまとめて送信する。この場合の応答には、ＡＣＫフレームではなく、ＢＡ（ＢｌｏｃｋＡＣＫ）フレームが用いられる。以降の説明および図では、ＭＰＤＵの表記を用いることがあるが、これは単一のＭＡＣフレームのみならず、上述したＡ−ＭＰＤＵまたはＡ−ＭＳＤＵの場合も含むものとする。

ＩＥＥＥ８０２．１１規格では、基地局が中心となり構成するＢＳＳ（これをインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ＢＳＳと呼ぶ）に、非基地局の端末が加入し、ＢＳＳ内でデータフレームの交換ができるようになるために経る手順（ｐｒｏｃｅｄｕｒｅ）が、段階的に複数規定されている。例えば、アソシエーション（ａｓｓｏｃｉａｔｉｏｎ）という手順があり、非基地局の端末から、当該端末が接続を要求する基地局に対して、アソシエーション要求（Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）フレームを送信する。基地局は、アソシエーション要求フレームに対するＡＣＫフレームを送信後、アソシエーション要求フレームに対する応答であるアソシエーション応答（Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）フレームを送信する。

端末はアソシエーション要求フレームに自端末の能力（ｃａｐａｂｉｌｉｔｙ）を格納し、それを送信することで基地局に自端末の能力の通知をすることができる。例えば、端末はアソシエーション要求フレームの中に、自端末が対応可能なチャネルまたはリソース（リソースブロックまたはストリーム）またはこれらの両方や、自端末が対応する規格を特定するための情報を入れて送信してもよい。他の基地局へ再接続するための再アソシエーション（ｒｅａｓｓｏｃｉａｔｉｏｎ）という手順で送信するフレームにも、この情報を入れるようにしてもよい。この手順では、端末から、再接続を要求する他の基地局に対して、再アソシエーション要求（Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するＡＣＫフレームを送信後、再アソシエーション要求フレームに対する応答である再アソシエーション応答（Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）フレームを送信する。

管理フレームとして、アソシエーション要求フレームおよび再アソシエーション要求フレーム以外にも、ビーコンフレーム、プローブ応答（Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅ）フレームなどを用いてもよい。ビーコンフレームは基本的に基地局が送信するもので、ＢＳＳの属性を示すパラメータとともに、基地局自身の能力を通知するパラメータも格納できる。そこで、この基地局自身の能力を通知するパラメータとして、基地局がＵＬ−ＭＵ通信への対応可否の情報を加えるようにしてもよい。また他のパラメータとして、基地局のサポートレート（Ｓｕｐｐｏｒｔｅｄ Ｒａｔｅ）の情報を通知してもよい。サポートレートは、必須のレートとオプションのレートとを含んでもよい。プローブ応答フレームは、ビーコンフレームを送信する端末からプローブ要求（Ｐｒｏｂｅ Ｒｅｑｕｅｓｔ）フレームを受信すると、それに応答して送信するフレームである。プローブ応答フレームは、基本的にはビーコンフレームと同一の内容を通知するものであるため、プローブ応答フレームを用いても基地局は、プローブ要求フレームを送信した端末に、自局の能力（ＵＬ−ＭＵ通信への対応可否、サポートレートなど）を通知することができる。ＵＬ−ＭＵ対応端末にこの通知を行うことで、端末は例えば自端末のＵＬ−ＭＵ通信の機能を有効にするといったことも可能となる。

なお、端末は自端末の能力について基地局へ通知する情報として、基地局のサポートレートのうち自端末が実行可能なレートの情報を通知してもよい。ただし、サポートレートのうち必須のレートについては、基地局へ接続する端末はその必須のレートを実行する能力を有するものとする。

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

図４に、本実施形態に従った無線通信システムを示す。このシステムは、基地局（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）１００と、複数の端末（ＳＴＡ：ＳＴＡｔｉｏｎ）１〜８とを備える。基地局１００と、配下の端末１〜８により、ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）１が形成される。このシステムは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃａｒｒｉｅｒ Ａｖｏｉｄａｎｃｅ）を用いるＩＥＥＥ８０２．１１規格に準じた無線ＬＡＮシステムである。なお、ＢＳＳ１内に本実施形態に係る端末（ＵＬ−ＭＵ端末）以外のレガシー端末（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末など）が存在していてもかまわない。

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

これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しない場合もあり得る。また図５には示されていない他のフィールドが存在してもよい。例えば、Ａｄｄｒｅｓｓ４フィールドがさらに存在してもよい。また後述するように、通知フィールド（あるいは制御フィールドと呼んでもよい）が、ＭＡＣヘッダ内にフィールドまたはサブフィールドとして存在してもよい。

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

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

Ｄｕｒａｔｉｏｎ／ＩＤフィールドは前述したように媒体予約時間を記載し、他の端末宛てのＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、前述したように、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）と呼ばれる。ＱｏＳフィールドは、フレームの優先度を考慮して送信を行うＱｏＳ制御を行うために用いられる。ＨＴ Ｃｏｎｔｒｏｌフィールドは、ＩＥＥＥ８０２．１１ｎで導入されたフィールドであり、ＱｏＳデータフレームまたは管理フレームのときに、オーダーフィールドが１に設定されていると存在する。ＨＴ Ｃｏｎｔｒｏｌフィールドは、ＩＥＥＥ８０２．１１ａｃのＶＨＴ （Ｖｅｒｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）Ｃｏｎｔｒｏｌフィールドにも、次世代無線ＬＡＮ規格であるＩＥＥＥ８０２．１１ａｘのＨＥ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ） Ｃｏｎｔｒｏｌフィールドにも拡張可能であり、各々ＩＥＥＥ８０２．１１ｎ、ＩＥＥＥ８０２．１１ａｃ、あるいはＩＥＥＥ８０２．１１ａｘの各種機能に応じた通知をすることができる。

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

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

図７に、本実施形態に係る基地局（ＡＰ）１０１と、端末（ＳＴＡ）１〜端末（ＳＴＡ）４を含む複数の端末との動作シーケンス例を示す。端末１〜４を含む複数の端末はＵＬ-ＭＵ対応端末である。図には端末１〜４以外の端末は示されていないが、実際には、図４に示したように他の端末５〜８が存在してよい。

図において、双方向矢印付きの実線で示される短い区間は、ｓｈｏｒｔ ｉｎｔｅｒｆｒａｍｅ ｓｐａｃｅ（ＳＩＦＳ）を表す。ただし、参照符号Ｔ１が付されている区間は、ＳＩＦＳまたは他の一定時間（ＩＦＳ）を表す。太線の矢印で示される区間５０１Ａ、５０３Ａ、５０５Ａは、ＤＩＦＳ／ＡＩＦＳ[ＡＣ]時間と、ＣＳＭＡ／ＣＡのバックオフ（ＢａｃｋＯｆｆ）時間との合計（キャリアセンス時間あるいは待機時間）を表している。ただし、ＳＩＦＳおよびＤＩＦＳ／ＡＩＦＳ[ＡＣ]時間は一例であり、予め定めた一定時間であれば、別の時間（ＩＦＳ）でもよい。ＤＩＦＳ／ＡＩＦＳ［ＡＣ］時間は、ＤＩＦＳおよびＡＩＦＳ［ＡＣ］のいずれか一方の時間を意味する。ＱｏＳ対応でない場合はＤＩＦＳ時間を指し、ＱｏＳ対応の場合は、送信するデータのアクセスカテゴリ（ＡＣ：Ａｃｃｅｓｓ Ｃａｔｅｇｏｒｙ）（後述）に応じて決まるＡＩＦＳ［ＡＣ］時間を指す。

本動作シーケンス例では、基地局および端末１〜４を含む個々の端末との間で、基本のチャネル幅（または複数のチャネルを結合した帯域幅）で個別に通信が行われている状況の中、基地局がＵＬ-ＭＵ（ＵＬ-ＯＦＤＭＡまたはＵＬ-ＭＩＭＯ）送信の開始を決定する。基地局が、ＵＬ−ＭＵ送信の開始を決定すると、ＵＬ-ＭＵ送信のトリガーとなるトリガーフレーム（より詳細にはトリガーフレームを含む物理パケット）５０７を送信し、端末１〜４がトリガーフレームの受信から一定時間Ｔ１後にデータフレーム（より詳細にはデータフレームを含む物理パケット）５０９、５１０、５１１、５１２を送信する。これにより、端末１〜４から基地局へのＵＬ-ＭＵ送信が行われる。なお、ＵＬ−ＭＵ通信に対し、個々の端末と基地局との間で基本のチャネル幅（または複数のチャネルを結合した帯域幅）で個別に行う通信を、シングルユーザ通信と呼ぶことがある。以下、本シーケンスについてさらに詳細に説明する。

ＵＬ-ＭＵ送信が開始される前では、基地局１０１と端末１〜４を含む個々の端末との間では通常のシングルユーザ通信が行われている。つまり、端末１において、アップリンク送信用のデータが保持されている場合、端末１が、無線媒体へのアクセス権を獲得するため、ＤＩＦＳ／ＡＩＦＳ[ＡＣ]とランダムに決定したバックオフ時間とのキャリアセンス時間（待機時間）の間、キャリアセンスを行ってＣＣＡ値を測定し、媒体（ＣＣＡ）がアイドルと判断されると、例えば１フレームを送信するアクセス権を獲得する。端末１は、送信するデータを含むデータフレーム（より詳細にはデータフレームを含む物理パケット）５０１を送信し、基地局がこのデータフレーム５０１を正常に受信すると、データフレーム５０１の受信完了からＳＩＦＳ時間後に、送達確認応答フレームであるＡＣＫフレーム（より詳細にはＡＣＫフレームを含む物理パケット）５０２を返す。端末１はＡＣＫフレーム５０２を受信することで、データフレーム５０１の送信が成功したと判断する。なお、基地局に送信するデータフレームはアグリゲーションフレーム（Ａ-ＭＰＤＵ等）でもよく、基地局が応答する送達確認応答フレームはＢＡフレームでもよい（以下同様）。端末２も同様にしてアクセス権を獲得してデータフレーム５０３を送信し、基地局がデータフレーム５０３の受信完了からＳＩＦＳ時間後に、ＡＣＫフレーム５０４を送信する。また、端末３も、同様にしてアクセス権を獲得してデータフレーム５０５を送信し、また基地局がデータフレーム５０５の受信完了からＳＩＦＳ時間後に、ＡＣＫフレーム５０６を送信する。図の例では、端末１〜３のみが基地局にデータフレームを送信する例が示されるが、端末４および図示しない端末５〜８も同様にして、フレーム交換を行ってよい。また図の例では、端末１、端末２、端末３の順に通信が行われているが、これはアクセス権を獲得した順に過ぎず、どのような順序で通信が行われてもかまわない。

ここで各端末は、基地局に送信するデータフレーム５０１、５０３、５０５等において、基地局がＵＬ−ＭＵに必要な情報である通知情報（あるいは制御情報と呼んでもよい）を、通知フィールド（制御フィールド）に設定する。つまり、データフレームは、基地局に上記データを送信する役割の他、ＵＬ−ＭＵに必要な通知情報を送信する役割を有する。さらに換言すれば、データフレームは、当該通知情報とは異なる目的の情報（上記データ）を、フレームボディフィールドに含んでいる。なお、通知情報はシングルユーザ送信されるデータフレームに設定する他、ＵＬ−ＭＵ送信するデータフレームに設定することも可能である。

通知情報の一例として、ＵＬ−ＭＵ送信の要求の有無に関する情報、ＵＬ−ＭＵ送信を希望するデータの有無に関する情報、ＵＬ−ＭＵ送信を希望するデータのデータ種別に関する情報等がある。また、ＵＬ−ＭＵ送信を希望するデータのデータ量に関する情報（データの個数またはサイズまたはこれらの両方など）がある。また、希望する通信方式（ＯＦＤＭＡかＭＵ−ＭＩＭＯのいずれかの通信方式）がある。また、通信方式に応じて、希望するリソース（ＯＦＤＭＡではリソースブロック、ＭＵ−ＭＩＭＯではストリーム）またはリソース数でもよい。希望するリソースは、リソース番号またはストリーム番号で特定してもよいし、その他の方法で特定してもよい。また、端末におけるデータの発生周期の情報でもよい。また、アプリケーションで許容される通信遅延（許容遅延）の値などもあり得る。通知情報は、ここで述べた例の情報の少なくとも１つを含んでもよいし、ここで述べていない種類の情報を含んでもよい。通知情報は、基地局から通知情報の送信要求が行われない状態で、個々の端末から自発的に送信される。つまり、個々の端末が通常のシングルユーザ通信で送信するフレームに相乗りする形で、通知情報を送信する。また、前述したように、複数の端末からＵＬ―ＭＵ送信される複数のフレーム（データフレーム等）に個々の端末で通知情報を設定して、当該フレームに相乗りする形で送信することも可能である。この場合、ＵＬ−ＭＵ送信しながら、次のＵＬ−ＭＵ送信に必要な事項を決定するための通知情報を送信することができる。通知情報の内容の詳細については後述する。

ここで通知情報を設定する通知フィールドは、図８（Ａ）に示すように、ＭＡＣヘッダ内に新規フィールドとして設けてもよい。または、既存のフィールド（既存の規格で定義されたフィールド）内の予約領域を通知フィールドとして利用してもよい。また、通知フィールドは、図８（Ｂ）に示すように、物理ヘッダ内に設けてもよいし、物理ヘッダ内の既存のフィールド内の予約領域を通知フィールドとして利用してもよい。または、通知フィールドを、ＭＡＣヘッダではなく、フレームのボディフィールドに設定してもよい。例えば基地局に送信するデータフレームがＡ−ＭＰＤＵの場合に、データフレームのペイロードに格納する複数のＭＡＣフレームのうちの１つを管理フレームとし、その管理フレームのフレームボディフィールドを通知フィールドとしてもよい。このとき、通知フィールドは、具体的には、先に図６に示したような情報エレメントの形式を有してもよく、通知フィールドを設定する情報エレメントに、新規にエレメントＩＤを割り当ててもよい。また、Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのサブタイプとして、通知フィールドを含むフレームに対して新規の値を定義してもよい。既存の管理フレームのフレームボディに、通知フィールドの情報エレメントを追加的に設定してもよい。通知フィールドの具体的なフォーマットは、設定する通知情報の内容に依存する。

ここで、各端末が通知フィールドで通知する通知情報について説明する。上述したように、通知情報は、基地局がＵＬ−ＭＵの必要事項の決定等を含むスケジューリングを行うために用いられる。

通知情報の第１の例として、ＵＬ−ＭＵ送信の要求有無に関する情報がある。基地局に送信する残りのデータが送信バッファ（送信キュー）に存在する場合などは、ＵＬ−ＭＵ送信の要求があるといえる。通知情報のフォーマット例として、１ビットを用い、ビット１のとき、ＵＬ−ＭＵ送信の要求がある、ビット０のとき、ＵＬ−ＭＵ送信の要求がないとしてもよい。あるいは、ビット関係をこの逆にしてもよい。基地局では、ＵＬ−ＭＵ送信の対象端末を選定する際、ＵＬ−ＭＵ送信の要求を有する端末の中から選定してもよい。なお、変形例として、パワーセーブモードにある端末にダウンリンク用の残りのデータの存在の有無を通知するために用いるｍｏｒｅ ｄａｔａフィールドを、第１の例の通知情報として流用してもよい。例えば、ｍｏｒｅ ｄａｔａフィールドのビットを１にすることで、送信用のデータの有を通知してもよい。また、ＵＬ−ＭＵ送信の要求が存在しないときは、そもそも通知フィールドを設けないという方法も可能である。

なお、端末が、基地局に送信するデータを有しているが、ＵＬ−ＭＵ送信で送信せずに、シングルユーザ送信で送信したい状況もあり得る。ＵＬ−ＭＵ送信では複数の端末でリソース（例えば１チャネル幅帯域）を共有するため、１端末で１チャネル帯域幅を利用できるシングルユーザ送信に比べて、同じデータサイズを送る場合のフレーム長（物理パケット長）が長くなる。フレーム長が長くなると、その分、送信に失敗する可能性（受信側でフレームエラーが検出される可能性等）が高くなる。このため、端末は、確実に送信したい場合はシングルユーザ送信を行い、ＵＬ−ＭＵ送信を行いたくない状況もあり得る。このような場合は、端末は、送信の要求はない（残りのデータはない）ことを示す情報を通知フィールドに設定し、当該データは、通常通り、ＣＳＭＡ／ＣＡベースで、シングルユーザ送信すればよい。

通知情報の第２の例として、端末におけるデータ種別毎のＵＬ−ＭＵ送信の要求の有無（すなわち、データ種別毎のＵＬ−ＭＵ送信用のデータの有無）を特定するための情報でもよい。データ種別として、ＩＥＥＥ８０２．１１規格のＴＩＤ（Ｔｒａｆｆｉｃ ＩＤ：トラヒック種別）またはＡＣ（Ａｃｃｅｓｓ Ｃａｔｅｇｏｒｙ：アクセスカテゴリ）でもよい。以下ではデータ種別としてＡＣをベースに説明するが、ＴＩＤを代わりに用いてもかまわない（通知情報の第３の例以降の説明の場合も同様）。

アクセスカテゴリ（ＡＣ）を利用した優先制御方式としてＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）がある。ＥＤＣＡについて簡単に説明する。ＩＥＥＥ８０２．１１規格の無線ＬＡＮでは、上位層（ＬＬＣ層等）からＭＡＣ層にデータが渡される際に、端末がＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）に対応する場合には、データとともにトラヒック種別（ＴＩＤ）が通知される。なお既存の規格ではＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｃの対応端末は、ＱｏＳに対応する。

当該データは、例えばトラヒック種別に基づいて、４つのＡＣに分類される。一例として、ＴＩＤの値は、０〜１５まで存在し、０〜７はＥＤＣＡ環境にある端末（基地局を含む）で使用され、８〜１５はＨＣＣＡ（ｈｙｂｒｉｄ ｃｏｏｒｄｉｎａｔｉｏｎ ｆｕｎｃｔｉｏｎ （ＨＣＦ） ｃｏｎｔｒｏｌｌｅｄ ｃｈａｎｎｅｌ ａｃｃｅｓｓ （ＨＣＣＡ））環境あるいはＨＥＭＭ（ＨＣＣＡ、ＥＤＣＡ ｍｉｘｅｄ ｍｏｄｅ）環境にある端末（基地局を含む）で使用される。ここではＥＤＣＡ環境を想定し、ＴＩＤの値が０〜７のいずれであるかに応じて、４つのＡＣのいずれか１つに分類される。

ＡＣの種類として、ＢＡＣＫＧＲＯＵＮＤ（ＡＣ＿ＢＫ）、ＢＥＳＴ ＥＦＦＯＲＴ（ＡＣ＿ＢＥ）、ＶＩＤＥＯ（ＡＣ＿ＶＩ）、ＶＯＩＣＥ（ＡＣ＿ＶＯ）が定められている。４つのＡＣに対して送信バッファ（送信キュー）がそれぞれ設けられ、分類されたデータは、該当する送信バッファに格納される。送信バッファ（送信キュー）は、メモリでもよいし、ＳＳＤ、ハードディスク等でもよい。送信バッファがメモリの場合、当該メモリはＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。

各ＡＣには、ＥＤＣＡパラメータが定められており、このパラメータで送信時の媒体アクセスの優先度の差が決定される。パラメータの例としては、ＡＩＦＳ［ＡＣ］、およびコンテンションウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ Ｗｉｎｄｏｗ：ＣＷ）の最小値ＣＷｍｉｎおよび最大値ＣＷｍａｘなどがある。ＡＩＦＳ［ＡＣ］、ＣＷｍｉｎおよびＣＷｍａｘは、媒体アクセスの優先度の高いＡＣほど、小さい値に設定される。パラメータのその他の例としては、ＴＸＯＰの上限値であるＴＸＯＰ ｌｉｍｉｔもある。

端末では、ＣＳＭＡ／ＣＡに基づくデータ送信のための手順が、送信用のデータを有するＡＣごとに独立して行われる。すなわち、ＡＣごとに、ＡＩＦＳ［ＡＣ］と、バックオフ時間とを含む待機時間の間、キャリアセンスを行い、最初に待機時間がゼロになったＡＣがアクセス権を獲得する。待機時間が同時にゼロになったＡＣが複数存在する場合は、媒体アクセスの優先度の高いＡＣがアクセス権を獲得する。なお、バックオフ時間（ランダム時間）は、コンテンションウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ Ｗｉｎｄｏｗ：ＣＷ）からランダムに選ばれる整数にスロット時間をかけたものである。ＣＷの初期値はＣＷｍｉｎで与えられ、再送するたびにＣＷの値はＣＷｍａｘになるまで増やされる。

図９に、ＡＣ別にＵＬ−ＭＵ送信の要求の有無（ＵＬ−ＭＵ送信用のデータの有無）を表すフォーマットの例を示す。ＢＡＣＫＧＲＯＵＮＤ（ＡＣ＿ＢＫ）、ＢＥＳＴ ＥＦＦＯＲＴ（ＡＣ＿ＢＥ）、ＶＩＤＥＯ（ＡＣ＿ＶＩ）およびＶＯＩＣＥ（ＡＣ＿ＶＯ）のそれぞれに対して１ビットが設けられている。これらのＡＣのそれぞれに該当する送信キューにデータが存在するときはビット１、存在しないときは０とすることができる。あるいは、ビットの関係をこの逆としてもよい。この例では、各ＡＣの送信用のデータの有無を表すために、４つのビットが必要になる。

図１０に、図９のフォーマットを用いて各ＡＣの送信用のデータ有無を通知する具体的な動作例を示す。ＡＣごとに送信キューが設けられ、ＡＣ＿ＶＯの送信キューには、１つのＭＳＤＵ（ＭＰＤＵ、ＰＳＤＵ、またはＰＰＤＵなどでもよい）が存在する。ＡＣ＿ＶＩの送信キューには２つのＭＳＤＵが存在し、ＡＣ＿ＢＫの送信キューにはＭＳＤＵが存在せず、ＡＣ＿ＢＥの送信キューには１つのＭＳＤＵが存在する。各ＭＳＤＵのサイズは同じである必要はなく、図の例でもＡＣ間でＭＳＤＵのサイズが異なっている。送信時にＡＣごとに独立してＣＳＭＡ／ＣＡに従った手順が同時に開始され、ＡＣ＿ＶＯが最初に待機時間がゼロになり、アクセス権を獲得したとする。この場合、ＡＣ＿ＶＯの送信キューの先頭のＭＳＤＵが読み出され、当該送信キューは空になる。読み出されたＭＳＤＵに基づきＭＡＣフレームのボディフィールドが生成され、またボディフィールドにＭＡＣヘッダが付加されることで、ＭＡＣフレームが生成される。この際、ＭＡＣヘッダの通知フィールドには、ＡＣ別に送信用の残りのデータ有無を表す情報が設定される。ＡＣ＿ＶＯの送信キューは空のためビット０、ＡＣ＿ＶＩの送信キューにはＭＳＤＵが存在する（２つ）ためビット１、ＡＣ＿ＢＫの送信キューは空のためビット０、ＡＣ＿ＢＥにはＭＳＤＵが存在する（１つ）のためビット１がそれぞれ該当するサブフィールドに設定される。生成されたＭＡＣフレームは、獲得したアクセス権に基づくＴＸＯＰ内で、基地局に送信される。なお図の例では、ＭＡＣフレームの送信からＳＩＦＳ時間後に基地局から送達確認応答フレーム（ＢＡフレームまたはＡＣＫフレーム等）が端末１で受信されている。

なお、既存のＩＥＥＥ８０２．１１規格では、基地局が送信するＭＡＣフレーム（ビーコンフレーム等）のＭＡＣヘッダのＦｒａｍｅ Ｃｏｎｔｒｏｌフィールド内のｍｏｒｅ ｄａｔａフィールドにビット１を設定した場合、同じアクセスカテゴリ（ＡＣ）のデータが基地局にまだ存在すると解釈されるが、これでは、他のＡＣの送信キューの状態を端末に伝えられない問題がある。これに対して、第２の例の通知情報では複数のＡＣの送信キューの状態を伝えることができるため、基地局はＵＬ−ＭＵ通信を効率的に行うことができる。

通知情報の第３の例として、ＡＣごとに、送信の優先度（前述した媒体アクセスの優先度とは区別される）を設定してもよい。例えば「高」、「中」および「下」の優先度を、ＡＣごとに設定してもよい。３つより少ないまたは多い個数の優先度を定義してもよい。なお、送信用のデータが存在しない場合は、送信の優先度を「下」にしてもよいし、送信用のデータが存在しないことを示す「無」などの優先度を別途、定義してもよい。本第３の例を、第２の例と組み合わせて通知情報を定義してもよい。この場合、ＡＣ別に、送信用のデータの有無と、送信の優先度とが設定される。

通知情報の第４の例として、複数のＡＣ（ＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＫおよびＡＣ＿ＢＥ）のうち、最もデータ送信したいＡＣ、すなわち最も送信の優先度の高いＡＣを指定してもよい。この場合、これら４つのＡＣのうちの１つを指定するために、２ビットが必要になる。例えば、ＡＣ−ＶＯの場合「００」、ＡＣ−ＶＩの場合「０１」、ＡＣ−ＢＫの場合「１１」、 ＡＣ−ＢＥの場合「１０」のように指定してもよい。本第４の例を、第２の例と組み合わせて通知情報を定義してもよい。この場合、ＡＣごとに、データ送信の有無を表すビット（例えば４ビット）と、本例の１つのＡＣを指定するビット（例えば２ビット）とが必要になる。

通知情報の第５の例として、全部または一部のＡＣ別の送信用のデータ量を特定するための情報でもよい。データ量は、ＡＣ別の送信キューに存在しているデータ（ここではＭＳＤＵとするが、ＰＰＤＵでもよいし、その他のＰＤＵまたはＳＤＵでもよい）の個数または各ＭＳＤＵのサイズ、またはこれらの両方でもよい。または、送信キューに残っているＭＳＤＵの合計データサイズでもよい。また、サイズではなく、時間長でもよい。ここで述べた以外にも、データ量を特定可能な情報であるならば、何でもよい。例えば送信をアグリゲーションフレーム（Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵなど）の送信で行う場合に、何個分のアグリゲーションフレームが存在するかの情報でもよい。データ量を表現する際の量子化方法は任意の方法でよい。例えば、基本の単位を時間長である３２μｓとし、３２μｓの整数倍でデータ量を表してもよい。このときデータ量を設定するためのフィールド長が８ビットであれば、例えば３２μｓ〜８１６０μｓを表すことができる。なお、３２μｓは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また８ビットも一例であり、他の長さのフィールド長を用いてもよい。また、他の量子化方法として、基本の単位をサイズである４０９６オクテットとし、４０９６オクテットの整数倍で、データ量を表してもよい。例えばデータ量を設定するためのフィールド長が４ビットで、フィールドの値が１のとき４０９６オクテットを表し、２のとき８１９２オクテットを表すなどとできる。実際のデータ量が、４０９６オクテットの整数倍に一致しない場合は、当該実際のデータ量より大きい値で、最も近い値を採用すればよい。フィールドの値が１５の場合は、データ量が５７３４４オクテットより大きいことを示してもよい。なお、４０９６オクテットは一例であり、他のサイズを基本の単位として用いてもよい。また４ビットも一例であり、他の長さのフィールド長を用いてもよい。

通知情報の第６の例として、端末における送信用のデータ量（ＡＣ別でない）を特定するための情報でもよい。具体的に、送信バッファ（送信キュー）に残っている送信用のデータ（ここではＭＳＤＵとするが、ＰＰＤＵでもよいし、その他のＰＤＵまたはＳＤＵでもよい）の個数または各ＭＳＤＵのサイズ、またはこれらの両方でもよい。または、送信用に残っているＭＳＤＵの合計サイズでもよいし、ここで述べた以外の情報でもよい。また、サイズではなく、時間長でもよい。ここで述べた以外にも、データ量を特定可能な情報であるならば、何でもよい。例えば送信をアグリゲーションフレーム（Ａ−ＭＰＤＵまたはＡ−ＭＳＤＵなど）の送信で行う場合に、何個分のアグリゲーションフレームが存在するかの情報でもよい。データ量を表現する際の量子化方法は任意の方法でよい。例えば、基本の単位を時間長である３２μｓとし、３２μｓの整数倍でデータ量を表してもよい。このときデータ量を設定するためのフィールド長が８ビットであれば、例えば３２μｓ〜８１６０μｓを表すことができる。なお、３２μｓは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また８ビットも一例であり、他の長さのフィールド長を用いてもよい。また、他の量子化方法として、基本の単位をサイズである４０９６オクテットとし、４０９６オクテットの整数倍で、データ量を表してもよい。例えばデータ量を設定するためのフィールド長が４ビットで、フィールドの値が１のとき４０９６オクテットを表し、２のとき８１９２オクテットを表すなどとできる。実際のデータ量が、４０９６オクテットの整数倍に一致しない場合は、当該実際のデータ量より大きい値で、最も近い値を採用すればよい。フィールドの値が１５の場合は、データ量が５７３４４オクテットより大きいことを示してもよい。なお、４０９６オクテットは一例であり、他のサイズを基本の単位として用いてもよい。また４ビットも一例であり、他の長さのフィールド長を用いてもよい。

通知情報の第７の例として、全部または一部のＡＣ別に、次の送信に必要なＴＸＯＰ長を特定するための情報でもよい。ＴＸＯＰ長は、例えば、基本の単位を３２μｓとし、３２μｓの整数倍で表してもよい。このときＴＸＯＰ長を設定するためのフィールド長が８ビットであれば、例えば３２μｓ〜８１６０μｓを表すことができる。なお、３２μｓは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また８ビットも一例であり、他の長さのフィールド長を用いてもよい。ＴＸＯＰ長ではなく、全部または一部のＡＣ別に、次の送信に必要なデータ量でもよい。データ量は、ＰＰＤＵまたはＭＳＤＵ等のデータ長でもよい。データ量の表現方法は、第５または第６の例の通知情報と同様である。ここではＡＣ別に、次の送信に必要なＴＸＯＰ長またはデータ量を特定するための情報を示したが、ＡＣ別ではなく、端末における次の送信に必要なＴＸＯＰ長またはデータ量を特定するための情報でもよい。

通知情報の第８の例として、端末がＯＦＤＭＡとＭＵ−ＭＩＭＯのいずれ（前述したようにＭＵ−ＭＩＭＯ＆ＯＦＤＭＡでもよい。以下同様）を希望するかに関する情報でもよい。端末がいずれか一方のみの通信方式に対応可能であり、アソシエーションプロセス時等に基地局に、自端末が対応可能な通信方式を通知済みの場合は、本情報の通知を省略してもよい。

通知情報の第９の例として、ＵＬ−ＭＵ通信方式（ＯＦＤＭＡまたはＭＵ−ＭＩＭＯ）に応じて、希望するリソース（ＯＦＤＭＡではリソースブロック、ＭＵ−ＭＩＭＯではストリーム）を特定する情報、またはリソース数を表す情報、またはこれらの両方でもよい。希望するリソースの特定は、リソース番号またはストリーム番号で行ってもよいし、別の方法で行ってもよい。別の方法の例として、リソース番号の範囲を指定することで、希望するリソースを特定してもよい。例えばリソース番号１〜８まであるときに、「リソース番号６〜８」のように範囲を指定してもよい。この際、複数の範囲を指定してもよい。

上述した第１〜第９の例で示した各種の通知情報はそれぞれ単独で用いられる他、矛盾しない限り、任意の組み合わせで用いてもよい。例えば第１の例と第２の例との両方を組み合わせて通知情報を定義してもよい。また３つ以上の通知情報を組み合わせてもよい。第１〜第９の例は一例であり、これら以外の情報を通知情報として用いることも可能である。例えば端末におけるデータの発生周期を表す情報を用いてもよい。当該発生周期は、前述したＡＣ別またはＴＩＤ別の情報でもよい。また、端末におけるアプリケーションで許容される通信遅延（許容遅延）の値を表す情報でもよい。また、ＩＥＥＥ８０２．１１規格で定められたＴＳＰＥＣ（Ｔｒａｆｆｉｃ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）関連の情報（例えば平均データレート、ＭＳＤＵ長、最小物理レート等）を、通知情報として送信してもよい。複数の通知情報を送信する場合、１つのフレームで送信してもよいし、複数のフレームに分けて送信してもよい。

ここで通知情報の一部または全部を、ＱｏＳ Ｃｏｎｔｒｏｌフィールドなど、既存のフィールドを利用して設定してもよい。このとき、既存のフィールド内の予約領域を用いてもよいし、既存のフィールドが複数のパターンのフォーマットを有するときは、通知情報を設定するためのパターンを新たに定義し、新たなパターンのフォーマットで通知情報を設定してもよい。また、既存のフィールドの値そのものを、通知情報として利用することも可能である。例えば、ＱｏＳ Ｃｏｎｔｒｏｌフィールドのフォーマットは、Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのサブタイプに応じて異なるが、一例としてＴＩＤサブフィールドと、ＴＸＯＰ Ｄｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔｅｄサブフィールドを含む。ＴＩＤサブフィールドには、現在送信しているデータのＴＩＤが設定され、ＴＸＯＰ Ｄｕｒａｔｉｏｎ Ｒｅｑｕｅｓｔｅｄサブフィールドには、次のＴＸＯＰとして必要な値が設定される。これらのサブフィールドの値を通知情報としてもよい。

基地局は、各端末から通知フィールドで通知される通知情報を、内部の記憶装置に記憶し、端末毎の通知情報を管理することで、端末ごとの状態を管理する。なお、前述したように通知フィールドでの通知情報の通知は、既存のフィールドを利用している場合も含む。基地局は、任意のタイミング、予め定めたタイミング、または予め定めた条件が成立したタイミング等で、ＵＬ−ＭＵ送信の実施を決定する。予め定めたタイミングとして、一定のビーコンインターバル周期ごとでもよいし、その他のタイミングでもよい。予め定めた条件としては、ＵＬ−ＭＵ送信の希望を有する端末が一定数以上存在することでもよいし、電波の状況（ビジー率、利用率、あるいはその他の指標でもよい）が所定の基準を満たすことを要件してもよい。基地局は、端末１〜４からシングルユーザ送信されるデータフレームの受信とは独立して、ＵＬ−ＭＵ送信の実施を決定すればよい。

基地局は、ＵＬ−ＭＵ送信の実施を決定すると、ＵＬ−ＭＵ通信に必要な事項を決定する。例えばＵＬ−ＭＵ送信の対象端末を選定する。選定の方法としては、ＵＬ−ＭＵ送信の要求を有する端末から選択してもよい。この際、特定のデータ種別（ＡＣまたはＴＩＤなど）の送信用データを有している端末の中から選択してもよい。また特定のデータ種別のデータ量または次の送信に必要なＴＸＯＰ長またはデータ量が最も大きい端末から優先的に選択する、またはデータ量または次の送信に必要なＴＸＯＰ長またはデータ量が同じくらいの端末を選択するなど、データ量または次の送信に必要なＴＸＯＰ長またはデータ量に基づいて対象端末を選択してもよい（詳細は後述）。また特定のデータ種別の送信の優先度が最も高い端末など、特定のデータ種別の送信の優先度に基づいて端末を選択してもよい。また、基地局が端末をグループ化している場合に、同じグループに属する端末を選択してもよい。またグループを選択する基準として、各グループに属する端末ごとのＵＬ−ＭＵ送信の要求の有無、特定のデータ種別のデータ量または優先度などの項目を考慮してもよい。または、ラウンドロビンで選択する方法でもよいし、ランダムで選択する方法でもよい。または、送信するデータのサイズが同じ、または近いと推定されるデータを有する端末を選択する方法、またはデータの発生周期が同じ、または発生周期が近い端末（発生周期が一定値以内に含まれる端末、または発生周期が最も近い所定数の端末など）を選択する方法でもよい。または、事前に各端末との伝搬路応答を把握している場合は、空間相関の小さい（干渉の小さい）端末の組み合わせを選択してもよい。選択する端末数は、通信方式に応じて、多重可能最大数以下の範囲内とする。ＯＦＤＭＡであれば、利用可能な最大のリソースブロック数、ＭＵ−ＭＩＭＯであれば、利用可能な最大の空間リソース数（最大ストリーム数）以下の範囲で選択する。選択する端末数の下限が定められており、下限以上端末数を選択してもよい。

また、基地局は、選定した対象端末に対して、ＵＬ−ＭＵ送信で使用するリソースの割り当てを行う。リソースは、ＯＦＤＭＡであれば、リソースブロック（１つまたは複数のサブキャリア）であり、ＭＵ−ＭＩＭＯであれば、空間リソース（ストリーム）である。リソースの割り当てでは、対象端末間で重複しないようにリソースを割り当てる。事前に端末ごとに使用可能なリソースが定まっている場合（例えば基地局とのアソシ−エーション時またはその後の任意のタイミングで決められた場合、あるいは、端末の能力に応じて、使用可能なリソースが定まっている場合など）には、事前に定められたリソースを割り当てるようにする。上述した対象端末を選定する際の処理では、端末ごとに使用可能なリソースを考慮し、端末間で使用可能なリソースが重複しないように、対象端末を選定してもよい。

上述した対象端末の選定およびリソースの割り当て以外にも、対象端末に指定する他のパラメータ情報の決定を行ってもよい。一例として、基地局は、対象端末が送信するＰＰＤＵ長を共通に決定してもよい。例えば対象端末から次の送信に必要なＴＸＯＰ長またはデータ量またはこれらの両方を含む通知情報を受信している場合に、対象端末から通知されたＴＸＯＰ長またはデータ量（ＰＰＤＵ長等）を利用して、ＰＰＤＵ長を決定してもよい。例えば、対象端末の中でＴＸＯＰまたはデータ量が最も長いものに基づき、ＰＰＤＵ長を決定してもよい。詳細は、トリガーフレームの生成の説明で記述する。

なお、基地局は、対象端末の選定、リソースの割り当て、および他のパラメータ情報の決定にあたり、端末から既存のフィールドを介して通知情報が通知されている場合は、当該既存のフィールドに格納された情報を利用してスケジューリングを行っても良い。

基地局は、ＵＬ−ＭＵ通信の対象端末と、対象端末に割り当てるリソース等、ＵＬ−ＭＵ通信の実施内容が決定したら、トリガーフレーム５０７を生成する。

ここで、トリガーフレーム５０７は、図５に示した一般的なＭＡＣフレームのフォーマットをベースに定義すればよい。一例として、Ｆｒａｍｅ Ｃｏｎｔｒｏｌフィールドのタイプは制御フレームを表す値とし、サブタイプの値は、トリガーフレーム用に新規に定義した値とすればよい。ただし、トリガーフレームのフレームタイプは、制御フレームではなく、管理フレームまたはデータフレームとする構成も排除されない。また、サブタイプの値も既存の規格の値を流用してもよい。例えば既存の管理フレームのフレームボディフィールドにトリガーフレーム５０７の役割として必要な情報を、情報エレメントとして追加してもよい。

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

トリガーフレームのフレームボディフィールドには、ＵＬ−ＭＵ送信の対象端末数に応じた個数の端末情報フィールド（ＳＴＡ Ｉｎｆｏ． Ｆｉｅｌｄ）を、図１１（Ａ）に示すように設定する。図７のシーケンス例では、端末１〜４を選定したため、４つの端末情報フィールド（ＳＴＡ ｉｎｆｏフィールド）１〜４を設定する。各端末情報フィールドには、当該端末に個別に通知する情報を設定する。端末情報フィールドに設定する情報の例を以下に示す。

一例として、端末情報フィールドには、選定した端末の識別子を設定する。端末の識別子は、端末のＭＡＣアドレスでもよいし、アソシエーションＩＤ（ＡＩＤ）、その他、端末間でユニークなＩＤでもよい。

また、端末情報フィールドには、ＵＬ−ＭＵ送信時に端末が個別に使用するパラメータ情報を設定してもよい。以下、パラメータ情報の例を示す。

パラメータ情報の例として、送信を許可するデータ長、誤り訂正符号方式、ＰＨＹまたはＭＡＣまたはこれらの両方の送信レートを規定するＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ：変調符号化方式）、の少なくとも１つがある。データ長は、物理パケット長でもよいし、物理ヘッダ長が固定ならば、ＭＡＣフレーム長またはＭＳＤＵ長でもよいし、その他の部分の長さでもよい。データ長の単位は、データサイズでもよいし、時間長（空間での占有時間長）でもよい。データ長は各端末で共通でもよいし、端末ごとに異なることを許容してもよい。なおデータ長（ＰＰＤＵ長など）の最大値は、規格またはシステムで事前に決められていてもよく、この場合最大値以下の範囲で、データサイズを指定する。

基地局ではデータ長（例えばＰＰＤＵ長）を決定する際、例えば、対象端末の中で最も大きいＰＰＤＵ長を推定または算出し、その端末のＰＰＤＵ長をアップリンク送信のデータ長として設定してもよい。また、基地局は、対象端末を選定する際、端末が要求するＰＰＤＵ長に基づき、ＰＰＤＵ長が同じまたは互いに近い端末を選定してもよい。端末毎に送信するＰＰＤＵ長が異なると、ＰＰＤＵ長の短い端末の送信完了後、ＰＰＤＵ長の長い端末の送信完了までの間、ＰＰＤＵ長の短い端末に割り当てられたリソースで無駄が生じ、システムの効率も低下する可能性がある。そこで、ＰＰＤＵ長が近い端末を選択することで、システム効率を高めることが可能となる。

また、基地局では、ＵＬ−ＭＵ通信を行う各対象端末のＰＰＤＵ長が等しくまたは近くなるように、対象端末毎のＭＣＳを決定し、当該ＭＣＳの情報を端末情報フィールドで指定してもよい。例えば同じデータサイズでも、適用するＭＣＳが異なれば、占有時間長は異なる。そこで、各端末でデータサイズが異なる場合は、ＭＣＳを調整することで、各端末のＰＰＤＵの占有時間長が同じになるまたは近づくようにしてもよい。ＭＣＳはＭＡＣフレームに適用するＭＣＳの他、物理ヘッダの一部または全部のフィールドについてＭＣＳを指定可能な場合は、当該物理ヘッダのフィールドに対するＭＣＳを指定してもよい。

またパラメータ情報の他の例として、各端末が送信すべきデータ種別の情報を指定してもよい。データ種別として、アクセスカテゴリ（ＡＣ）またはトラヒック情報（ＴＩＤ：Ｔｒａｆｆｉｃ ＩＤ）の情報を設定してもよい。指定するデータ種別は、端末ごとに異なってもよいし、各端末で共通でもよい。また１つの端末に、複数のデータ種別を指定してもよい。

またパラメータ情報の他の例として、ＵＬ−ＭＵの通信方式に関する情報を指定してもよい。例えば、基地局が、ＯＦＤＭＡおよびＭＵ−ＭＩＭＯのいずれかを指定して端末にＵＬ−ＭＵ送信させる可能な仕組みを採用する場合、ＯＦＤＭＡおよびＭＵ−ＭＩＭＯのいずれかを指定する情報を指定する。端末は、トリガーフレームで指定された通信方式でＵＬ−ＭＵ送信を行う。この場合、基地局は、端末とのアソシエーションプロセス時またはその後の任意のタイミングで、端末が対応可能な通信方式を取得し、使用する通信方式に対応する端末の中から対象端末を選択してもよい。

また、パラメータ情報のさらに他の例として、使用するＵＬ−ＭＵの通信方式に応じて、端末に割り当てた１つまたは複数のリソースを指定する情報を、端末情報フィールドに設定してもよい。例えば、ＵＬ−ＯＦＤＭＡの場合、端末に割り当てた１つまたは複数のリソースブロックを指定する情報を、端末情報フィールドに設定してもよい。リソースブロックを指定する情報の形式は、当該リソースブロックを特定可能な限り、どのような形式でもよい。例えばリソースブロックの番号によって指定してもよい。高周波側または低周波側から何番目のリソースブロックかを指定してもよい。またＵＬ−ＭＵ−ＭＩＭＯ送信の場合、端末に割り当てたストリームを指定する情報、一例として、フレームに付加するプリアンブル（伝搬路応答の推定のためのプリアンブル）のパターンの情報を指定してもよい。この際、各端末のプリアンブルは、端末間で互いに直交するように選択するものとする（詳細は後述する）。また、ＵＬ−ＭＵ−ＭＩＭＯ送信の場合は、端末に許可するストリーム数を指定してもよい。端末が対応可能なストリーム数は、事前に端末の能力情報として基地局で取得済みであるとする。

トリガーフレームのフレームボディフィールドに、端末情報フィールドとは別に、図１１（Ｂ）に示すように、対象端末間で共通に情報（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）を通知するための共通情報フィールドを設けてもよい。共通情報フィールドでは、対象端末に共通に通知する情報を設定する。例えば各端末に指定する送信データサイズが共通の場合、端末情報フィールドではなく、共通情報フィールドに設定してもよい。また使用するＵＬ−ＭＵ通信方式を端末情報フィールドではなく、共通情報フィールドに設定してもよい。また、複数の対象端末としてグループを選択した場合は、当該グループのグループＩＤを共通情報フィールドに指定してもよい。このとき、当該グループに属するすべての端末が対象端末のときは、端末情報フィールドに個々の端末の識別子を設定することを省略してもよい。ただし、各端末は自端末が何番目の端末情報フィールドを割り当てられているかを、事前に基地局から通知されているなどして把握しているものとする。

ここでは端末情報フィールドおよび共通情報フィールドをフレームボディフィールドに設定する例を示したが、端末情報フィールドおよび共通情報フィールドに設定する情報の一部または全部を、ＭＡＣヘッダ内に配置してもかまわない。また、端末情報フィールドおよび共通情報フィールドに設定する情報の一部または全部を、図１２に示すように、物理ヘッダ内に配置してもよい。図１２の物理ヘッダは、Ｌ−ＳＴＦ（Ｌｅｇａｃｙ−Ｓｈｏｒｔ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、Ｌ−ＬＴＦ（Ｌｅｇａｃｙ−Ｌｏｎｇ ＴｒａｉｎｉｎｇＦｉｅｌｄ）、Ｌ−ＳＩＧ（Ｌｅｇａｃｙ Ｓｉｇｎａｌ Ｆｉｅｌｄ）、共通情報フィールド、端末情報フィールドを含む。端末情報フィールドは端末数分のフィールドを含む。Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧは、例えば、ＩＥＥＥ８０２．１１ａなどのレガシー規格が認識可能なフィールドであり、信号検出、周波数補正、伝送速度などの情報が格納される。必要な情報がすべて物理ヘッダ内の端末情報フィールドまたは共通情報フィールドまたはこれらの両方に設定される場合は、ＭＡＣフレームから端末情報フィールドおよび共通情報フィールドを省略してもよい。

基地局からトリガーフレーム５０７を受信し、当該トリガーフレーム５０７で指定された端末１〜４は、トリガーフレーム５０７の受信完了から一定時間Ｔ１後に、アップリンク送信用のデータを含むデータフレーム５０９、５１０、５１１、５１２（より詳細には当該データフレームを含む物理パケット）を、基地局に送信する。データフレーム５０９〜５１２の送信は、トリガーフレーム５０７で指定されたリソース（リソースブロックまたは空間リソース（プリアンブルパターンに対応））を用いて行う。端末１〜４が送信するデータフレームの送信タイミングは互いに同期されるため、この結果、端末１〜４から送信されるデータフレーム５０９〜５１２は、周波数多重または空間多重で送信されることになる。端末１〜４は、基地局に送信すべきデータが存在しないときは、予め定めた形式のフレーム、例えばＮｕｌｌ Ｐａｃｋｅｔ（ヌルパケット）を送信してもよい。ヌルパケットは、ボディフィールドが存在しないフレームを指す。あるいは、端末１〜４は、基地局に送信すべきデータが存在しないときは、何も送信しないようにしてもよい。基地局では、ヌルパケットを受信した場合、または何も受信しなかった場合は、当該端末は送信すべきデータが存在しなかったと判断してもよい。

ここで、図７の一定時間Ｔ１は、一例として、ＩＥＥＥ８０２．１１無線ＬＡＮのＭＡＣプロトコル仕様で規定されているフレーム間のタイムインターバルであるＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒ−ｆｒａｍｅ Ｓｐａｃｅ）時間（＝１６μｓ）でもよいし、これより長い時間でもよい。一定時間Ｔ１の値が共通情報フィールドに格納されており、端末１〜４は共通情報フィールドから一定時間Ｔ１の値を取得してもよい。その他、一定時間Ｔ１は、ビーコンフレームあるいはその他の管理フレームなど、別の方法で事前に通知されてもよい。

端末１〜４は、端末情報フィールドおよび共通情報フィールドで指定された条件がある場合は、その条件を満たすようにデータフレームの生成および送信（より詳細にはデータフレームを含む物理パケットの生成および送信）を行う。

例えば、トリガーフレーム５０７にて、各端末が送信すべきアクセスカテゴリ（ＡＣ）の情報が指定されている場合は、当該指定されたＡＣ（指定ＡＣと呼ぶ）に属するデータ（ここではＭＳＤＵとする）を選択し、当該ＭＳＤＵを含むデータフレームを送信する。送信するデータフレームがアグリゲーションフレームなど、複数のＭＳＤＵをデータフレームに含めることが可能な場合、または、複数のリソースが指定されており、リソース毎にＭＳＤＵが送信可能な場合、または、指定ＡＣに属するＭＳＤＵが存在しない場合などは、指定ＡＣ以外のＡＣ（非指定ＡＣと呼ぶ）に属するＭＳＤＵを含めるようにしてもよい。この際、指定ＡＣと非指定ＡＣからそれぞれＭＳＤＵをいくつ選択するか、また、非指定ＡＣのうちどのＡＣを選択するかは、任意の方法で決めてよい。一例として、指定ＡＣに属するＭＳＤＵを少なくとも１つ選択し、それ以外は自由に各ＡＣからＭＳＤＵを選択するようにしてもよい。なお、トリガーフレーム５０７でＡＣが指定された場合は、前述したＥＤＣＡの機能（各ＡＣで独立してＣＳＭＡ／ＣＡの手続を行って最も速くアクセス権を獲得したＡＣが送信をする機能）は、一時的に行わないようにしてもよいし、ＥＤＣＡのパラメータを強制的に所定値に設定して確実に当該ＡＣがアクセス権を獲得できるように制御してもよい。

また、トリガーフレーム５０７でＰＰＤＵ長等のデータ長に関する条件が指定されている場合は、当該データ長の条件を満たすように、データフレームの生成および送信を行う。例えばＰＰＤＵ長が指定された値に満たない場合は、ＭＡＣフレームの末尾にパディングデータを付加してもよいし、あるいは、不足している分の時間の間は、何もデータを送信しない（ヌルデータを送信する）ようにしてもよい。また、対象端末は、トリガーフレームでＭＣＳが指定されている場合は、指定されたＭＣＳを適用して、ＭＡＣフレームまたは物理パケットを生成する。

基地局は、端末１〜４からＯＦＤＭＡまたはＭＵ−ＭＩＭＯで送信されるデータフレーム５０９〜５１２（より詳細にはデータフレームを含む物理パケット）を受信する。ＯＦＤＭＡの場合は、端末１〜４から送信されたデータフレームをそれぞれのリソースブロックで受信し、ＭＵ−ＭＩＭＯの場合は各ストリームから端末ごとのデータフレームを受信する。基地局は、各端末から送信されたデータフレームを正しく受信すると、各データフレームの受信からＳＩＦＳ時間の経過後に、送達確認応答フレーム５１３を端末１〜４に送信する。なお、ＳＩＦＳ時間は一例であり、他に定義した時間（ＩＦＳ）でもかまわない。

送達確認応答フレーム５１３の送信として、例えばＢＡフレームを端末毎に、それぞれデータフレームが受信されたリソースブロックで送信する。基地局に送信されたデータフレームがＡ−ＭＰＤＵでなく、通常（単一）のＭＰＤＵを含む場合は、ＢＡフレームではなくＡＣＫフレームでもよい（なお、通常のＭＰＤＵの場合にＢＡフレームを返すことも可能である）。このように端末毎にそれぞれのリソースブロックでＢＡ（またはＡＣＫ）フレームを送信することは、ダウンリンクのＯＦＤＭＡで送達確認応答フレームを送信することに相当する。この場合、各端末はそれぞれのリソースブロックでＢＡ（またはＡＣＫ）フレームを受信する（そのようにリソースブロック単位で信号を受信できるように、受信フィルタを設定しておく）。または、ＢＡフレーム（またはＡＣＫフレーム）を端末毎に、それぞれストリームで同時送信することも可能である。つまり、ダウンリンクのＭＵ−ＭＩＭＯで送達確認応答フレームを送信する。ダウンリンクのＭＵ−ＭＩＭＯは、ＩＥＥＥ８０２．１１ａｃで規定されている。なお、アップリンク送信がＯＦＤＭＡで、ダウンリンク送信がＭＵ−ＭＩＭＯ、またはアップリンク送信がＭＵ−ＭＩＭＯで、ダウンリンク送信がＯＦＤＡＭであることも排除されない。

または、端末１〜４用の送達確認応答をすべて含む単一のフレームを送信（シングルユーザ送信）してもよい。この場合、このフレームのことを、Ｍｕｌｔｉ−ＳＴＡ ＢＡフレームと呼んでもよい。具体的な構成としては、例えばＩＥＥＥ８０２．１１規格で定義されたＭｕｌｔｉ−ＴＩＤ ＢＡフレームを流用してもよい。一例として、Ｍｕｌｔｉ−ＴＩＤ ＢＡフレームのＢＡ情報フィールドを端末数分配置し、各ＢＡ情報フィールドのＴＩＤ情報サブフィールド内の予約フィールドに、端末の識別子（例えばＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）またはＡＩＤの一部）を設定する。各ＢＡ情報フィールドのＢｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐサブフィールドには通常通り、送達確認応答を返すべきデータフレーム５０９〜５１２に応じて値を設定すればよい。Ｍｕｌｔｉ−ＳＴＡ ＢＡフレームのＲＡ（受信先アドレス）は、端末１〜４が共通に属するグループのマルチキャストアドレス、またはブロードキャストアドレスとすればよい。このようにすることで、１つのフレームで複数の端末にＢＡを通知できる。またＦｒａｍｅ Ｃｏｎｔｒｏｌフィールドのサブタイプは、新たに値を定義してもよい。

また端末１〜４にＢＡフレームではなくＡＣＫフレームを返す場合は、各ＢＡ情報フィールドのＴＩＤ情報サブフィールド内の予約フィールドにおける一部のフィールドを端末の識別子とし、残りの一部のフィールドのビットを立てる（１にする）ようにする。そして、当該ビットを立てた場合に、Ｂｌｏｃｋ Ａｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐサブフィールドは省略する（存在しない）。これにより、１つのフレームで複数の端末のＡＣＫを通知できる。ここで述べた例は、一例であり、Ｍｕｌｔｉ−ＴＩＤ ＢＡフレーム以外の既存のフレームを流用してもよいし、既存のフレームを流用するのではなく、新規にフレームを定義してもよい。

ここでは送達確認応答フレーム５１３を端末１〜４に一度に送信する場合を示したが、端末１〜４に順番にＢＡフレームまたはＡＣＫフレームを返す方法も可能である。順番に返す際、１番目の端末には、アップリンク送信されたデータフレームの受信完了後にＢＡフレームを返し、２番目以降の端末についてはＢＡＲフレームを送信し、その応答としてＢＡフレームを受信することを順番に行ってもよい。あるいは、２番目以降の端末については、ＢＡＲフレームは送信せずにＢＡフレームを送信し、応答としてＡＣＫフレームを受信することを順番に繰り返してもよい。どの端末が１番目かはトリガーフレーム５０７の共通情報フィールドまたは端末情報フィールド等で通知してもよいし、別の方法で通知してもよい。トリガーフレーム５０７で通知する場合、例えば一番先頭の端末情報フィールドを割り当てられた端末が１番目の端末などと暗示的な通知を行ってもよい。ここで述べた以外の方法で通知してもよい。

送達確認応答フレーム５１３の送信後に、端末１〜４によるＵＬ−ＭＵ送信と、基地局による送達確認応答フレームの送信が繰り返し行われてもよい。

上述したように、端末１、２、３、４がＵＬ−ＭＵ−ＭＩＭＯ送信する物理パケットのヘッダ内には、アップリンクの伝搬路応答の推定のためのプリアンブルを追加してもよい。このとき、各端末のプリアンブルは互いに直交する関係になるようにする。直交するとは、プリアンブルのビット列の各値を成分とするベクトルの内積がゼロになることである。

図１３に、端末１〜４がＵＬ−ＭＵ−ＭＩＭＯ送信する物理パケットの概略構成を示す。各物理パケットのヘッダ内には、Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧ以外に、プリアンブル１〜４等のフィールドが配置されている。プリアンブル１〜４より前のＬ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧ等のフィールドは、各端末で同じ値が設定されている。つまり、同じ値が設定されるように事前に基地局から各端末に必要な情報が通知されているか、システムまたは規格で事前に決められているか、もしくはこれらの両方である。Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧの“Ｌ”はレガシーを表し、これらのフィールドは、レガシー端末でも認識可能なフィールドである。

プリアンブル１〜４より後のフィールド（ＭＡＣフレームが格納されているデータフィールドを含む）は、端末ごとに異なる内容（もしくは同じ内容でもよい）が設定されている。基地局では、プリアンブル１〜４より後のフィールドを、端末間で空間的に分離するため、プリアンブル１〜４を用いる。基地局は、通知フレームにおける端末情報フィールド１〜４で、端末１〜４で互いに直交するプリアンブルパターンを指定しておいてもよい。

基地局は、プリアンブル１〜４を利用して、各端末１〜４の各々のアンテナと、基地局の複数のアンテナとの間のアップリンクの伝搬路情報を算出し、算出した伝搬路情報を利用して、プリアンブル１〜４より後の端末毎のフィールドを復号する。なお、物理パケットのヘッダ内のプリアンブル１〜４より後に、各データフィールドのＭＣＳ（変調符号化方式）に関する情報などを格納したフィールド等が、別途配置されていてもよい。

図７のシーケンス例では、端末１〜４は、通知情報を設定する通知フィールドをデータフレームに設けたが、通知フィールドは、管理フレームに設けてもよい。例えば基地局とのアソシエーションプロセスを行う際に送信するアソシエーション要求フレームでもよいし、認証要求フレームでもよいし、その他の種類の管理フレームでもよい。また、データフレームおよび管理フレーム以外に、制御フレームに通知フィールドを設けることも排除されない。また、前述したように、通知情報を設定する通知フィールドを、シングルユーザ送信するフレームではなく、ＵＬ−ＭＵ送信するフレームに設けてもよい。

図７のシーケンス例では、個々の端末から、基地局にそれぞれ任意のタイミングでシングルユーザ送信するフレーム（より詳細にはフレームを含む物理パケット）で通知情報を送信したため、基地局が通知情報を受信するタイミングと、基地局がＵＬ−ＭＵ送信の開始を決定するタイミングとの間に大きな時間の隔たりが生じる場合もある。つまり、端末が基地局に最後の通知情報を送信してから、ＵＬ−ＭＵ通信が開始されるまで、大きな時間が経過する場合もあり得る。この場合、端末側のアプリケーションの動作や、タイムアウト、あるいはシングルユーザ送信でのデータ送信完了などにより、端末において送信用のデータが存在しなくなる場合もある。このような端末を対象端末としてトリガーフレームで指定すると、当該端末に割り当てたリソース（リソースブロック、または空間リソース（プリアンブルパターンに対応））が無駄になってしまう。そこで、基地局は、ＵＬ−ＭＵ通信の開始を決定した場合、トリガーフレームの送信前に、問い合わせフェーズを設け、ＵＬ−ＭＵ送信の要求を有するかを各端末に問い合わせ、ＵＬ−ＭＵ送信の要求を有する端末の中から対象端末を選定してもよい。この際、ＵＬ−ＭＵ送信の要求を有するかを問い合わせる対象となる端末は、通知情報でＵＬ−ＭＵ送信の要求がある旨を送信した、または当該要求があることを特定可能な情報を送信した端末にしてもよい。これにより問い合わせる端末の数を絞ることができるため、問い合わせ期間の長さを短くできる。また、ＵＬ−ＭＵ送信の要求のない端末へ問い合わせる可能性が減るため、効率的な問い合わせが可能になる。

図１４に、トリガーフレームの送信前に行う問い合わせフェーズの動作シーケンスの例を示す。問い合わせフィーズの前では、図７におけるトリガーフレームの送信前のように、個々の端末と基地局との間でシングルユーザの通信が行われているものとする。

図１４に示すように、基地局がＵＬ−ＭＵ送信の開始を決定すると、ＵＬ−ＭＵ通信の候補端末を決定し、候補端末のうちの１つ（ここでは端末１）に問い合わせフレーム５３１を送信する。端末１は、問い合わせフレーム５３１の受信からＳＩＦＳ時間後に、ＵＬ−ＭＵ送信の要求の有無を表す情報を含む要求フレーム５３２を送信する。

問い合わせフレーム５３１および要求フレーム５３２は、図５に示した一般的なＭＡＣフレームのフォーマットをベースに定義すればよい。問い合わせフレームは、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として、問い合わせフレームは制御フレームである。問い合わせフレーム５３１用に新規にサブタイプの値を定義しても構わない。問い合わせフレーム５３１のＲＡは端末１のＭＡＣアドレスであり、ＴＡは基地局のＢＳＳＩＤまたはＭＡＣアドレスである。ただし、ＲＡをブロードキャストアドレスまたはマルチキャストアドレスとし、フレームボディフィールドに端末１の識別子（ＡＩＤまたはＭＡＣアドレスなど）を設定してもかまわない。なお、フレームボディフィールド等に、現時点で確定しているＵＬ−ＭＵ通信の条件（例えば通信方式など）があれば、当該条件を設定してもよい。

要求フレーム５３２は、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として要求フレーム５３２は制御フレームである。要求フレーム５３２用に新規にサブタイプの値を定義しても構わない。要求フレーム５３２は、ＵＬ−ＭＵ送信の要求の有無を特定するための情報を含む。一例として、ＵＬ−ＭＵ送信用のデータの有無を表すビットをＭＡＣヘッダまたはボディフィールドまたは物理ヘッダに設けてもよい。また、要求フレーム５３２は、前述した通知情報（第１〜第９の例参照）を含んでも構わず、この場合、ＵＬ−ＭＵ通信の開始直前に、最新の通知情報を送信できる。

基地局は、他の候補端末についてもそれぞれ順番に選択し、問い合わせフレームの送信と要求フレームの受信を繰り返し行う。図の例では、端末１の次に端末２に問い合わせフレーム５３３を送信し、そのＳＩＦＳ時間後に、端末２から要求フレーム５３４を受信する。そして、要求フレーム５３４の受信からＳＩＦＳ時間後に、問い合わせフレーム５３５を端末３に送信し、そのＳＩＦＳ時間後に、端末３から要求フレームを受信する。その後、端末４にも問い合わせフレームを送信し、そのＳＩＦＳ時間後に、端末４から要求フレーム５３６を送信する。端末１〜４以外の候補端末が存在し、同様のプロセスが行われてもかまわない。

基地局は、すべての候補端末に対する問い合わせが完了すると、ＵＬ−ＭＵ送信に必要な事項を決定（対象端末の選定等）を行って、トリガーフレーム５０７を生成し、トリガーフレーム５０７を送信する。トリガーフレーム５０７の構成、およびトリガーフレーム５０７の送信以降のシーケンスは、図７の場合と同様であるため説明を省略する。なお、本シーケンス例でも、通知情報を設定する通知フィールドを、ＵＬ−ＭＵ送信するフレームに設けてもよい。

図１４のシーケンス例では、基地局がＵＬ−ＭＵ送信の開始を決定するタイミング（問い合わせフェーズを開始するタイミング）については特に特定しなかったが、端末からの要求に応じて、基地局がＵＬ−ＭＵ送信の開始を決定することも可能である。この場合のシーケンス例を図１５に示す。

基地局のＢＳＳに属する端末のうちの１つ（ここでは端末１）が、要求フレーム５２１を送信する。より詳細には、端末１が、アップリンク送信用のデータを保持しており、ＣＳＭＡ／ＣＡに従って、アクセス権を獲得する。すなわち、ＤＩＦＳ／ＡＩＦＳ［ＡＣ］時間とランダムに決定したバックオフ時間とのキャリアセンス時間（待機時間）の間、キャリアセンスを行って、無線媒体がアイドルであることにより、アクセス権を獲得する。端末２〜４も、アップリンク送信用のデータを保持しており、アクセス権の獲得を試みるが、端末１がアクセス権を獲得したものとする。

端末１は、アクセス権に基づくＴＸＯＰの間に、要求フレーム５２１を送信する。要求フレーム５２１は、図１４のシーケンス例で用いた要求フレームと同様にして定義すればよい。基地局は、要求フレーム５２１の受信により、ＵＬ−ＭＵ送信の開始を決定する。

基地局は、端末１以外の端末の中から、ＵＬ−ＭＵ通信の候補端末を選択し、選択した候補端末を指定する情報を含む問い合わせフレーム５２２を送信する。より詳細に、基地局は、要求フレーム５２１の受信からＳＩＦＳ時間後に、問い合わせフレーム５２２を送信する。問い合わせフレーム５２２は、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として、問い合わせフレーム５２２は制御フレームである。問い合わせフレーム５２２用に新規にサブタイプの値を定義しても構わない。一例として、問い合わせフレーム５２２のＲＡはブロードキャストアドレスまたはマルチキャストアドレス、ＴＡは基地局のＢＳＳＩＤまたはＭＡＣアドレスである。

問い合わせフレーム５２２のフレームボディフィールドまたはＭＡＣヘッダまたは物理ヘッダに、候補端末を指定するためのフィールドを設け、当該フィールドに候補端末を指定する情報を設定する。例えば候補端末の識別子を格納するフィールド（端末ＩＤフィールドと呼んでもよい）を、例えば候補端末数だけ設け、各端末ＩＤフィールドに、選択した候補端末の識別子（ＡＩＤまたはＭＡＣアドレスなど）を設定する。または、各候補端末が共通に属するグループのグループＩＤをフィールドに設定してもよく、この場合、当該グループに端末１が属していてもかまわない。

問い合わせフレーム５２２を受信した端末は、問い合わせフレーム５２２で自端末が指定されているかを確認する。例えば端末ＩＤフィールドのいずれかに自端末の識別子が設定されているか、またはフィールドに設定されているグループＩＤのグループに自端末が属しているかで自端末が指定されているか判断する。端末（端末１を除く）は、候補端末として指定されていた場合は、ＣＳＭＡ／ＣＡに基づきアクセス権を獲得して、要求フレームを送信する。図の例では、端末２〜４が、それぞれアクセス権を獲得して、要求フレーム５２３、５２５、５２７を送信している。

基地局は、候補端末のすべてから要求フレームを受信した場合、もしくは、予め定めた時間が経過した場合は、問い合わせフェーズを終了する。基地局は、問い合わせフェーズを終了すると、ＵＬ−ＭＵに必要な事項の決定（対象端末の選定およびパラメータ情報の決定等）を行う。基地局は、ＣＳＭＡ／ＣＡに基づき、無線媒体へのアクセス権を獲得して、上記の決定基づき生成したトリガーフレーム５０７を送信する。トリガーフレーム５０７の送信以降のシーケンスは、図７の場合と同様であるため説明を省略する。なお、本シーケンス例でも、通知情報を設定する通知フィールドを、ＵＬ−ＭＵ送信するフレームに設けてもよい。

図１４および図１５で示した問い合わせフェーズのシーケンス例は一例であり、ここで示した以外のシーケンスでも構わない。例えば、図１５のシーケンス例では基地局は要求フレーム５２３、５２５、５２７に対して送達確認応答フレームを返さなかったが、送達確認応答フレームを返すようにしてもよい。また図１４のシーケンス例では、候補端末のすべてに問い合わせフレームを順番に送信したが、基地局は最初に１回のみ、複数の候補端末を指定する情報（各候補端末の識別子、またはグループＩＤ等）を含む問い合わせフレームを送信し、問い合わせフレームで指定された端末がＳＩＦＳ時間ずつ空けて順番に要求フレームを送信するようにしてもよい。この場合、この問い合わせフレームには、要求フレームを送信する候補端末の順序を特定する情報が含まれており、この情報から自端末の順位を把握し、さらに要求フレーム長（要求フレーム長は、固定長等、予め分かっているものとする）から、自端末が送信する要求フレームのタイミングを把握してもよい。あるいは、自端末の識別子が格納されたフィールドが問い合わせフレームの何番目に設定されているかに応じて、自端末の順位を間接的に把握してもよい。ここで述べた以外にも、問い合わせフェーズとして様々なシーケンス例が可能である。

また、図１４または図１５のシーケンスのバリエーションとして、トリガーフレームで指定された端末が、トリガーフレームに応答して、ＵＬ−ＭＵで送信要求を送信することも可能である。例えば各端末は、ＱｏＳ Ｎｕｌｌデータを送信し、そのＭＡＣヘッダに送信バッファの情報（送信バッファ内のデータ量など）を入れるようにする。この場合、トリガーフレームで指定するＵＬ−ＭＵのＰＰＤＵ長は、例えばＭＡＣヘッダの最大長によって制限する。トリガーフレームでは、送信要求を収集するための意図であることを通知するための情報を設定してもよい。トリガーフレームで指定された端末は、この情報が設定されている場合に、送信バッファ情報を送信するようにしてもよい。当然、ＭＡＣヘッダの最大長より長いＰＰＤＵ長を指定してしてもよく、この場合は、そのサイズ以下に納まるように、フレームボディフィールドにデータを入れつつ、ＭＡＣヘッダに送信要求（送信バッファ情報等）を入れたフレームを送信するようにしてもよい。

他のバリエーションとして、以下に説明するランダムアクセスＯＦＤＭＡと呼ばれる方式を用いて１つまたは複数の端末がＵＬ−ＭＵするフレームに、送信バッファ情報を入れるようにしてもよい。この際、端末から送信するフレームは、上記のバリエーションの場合と同様である。端末は、送信要求がある、つまり送信バッファ内にアップリンク送信用のデータがある場合に、後述するランダムアクセス用トリガーフレームで端末が未指定のリソースブロック（どの端末も指定されていないリソースブロック、すなわち、任意の端末が利用可能であるリソースブロック）をランダムに選択して、選択したリソースブロックを介して、送信要求を入れたフレームを送信する。

ランダムアクセスＯＦＤＭＡについて説明する。ランダムアクセスＯＦＤＭＡでは、上述したＵＬ−ＯＦＤＭＡの場合と同様、基地局がトリガーフレームを送信し、トリガーフレームに応答して１つまたは複数の端末が同時にアップリンク送信する。ただし、このトリガーフレームでは、端末の指定は行わず、使用するリソースブロックのみを指定する。ただし、一部のリソースブロックに対しては端末の指定を行い、別のリソースブロックに対しては端末の指定を行わない場合もある。いずれの場合も、トリガーフレームを受信した端末（例えばどのリソースブロックも指定されていない端末）は、端末の指定がないリソースブロック（端末未指定リソースブロック）から、ランダムにリソースブロックを選択して使用する。このように端末未指定リソースブロックの指定を含むトリガーフレームを、ランダムアクセス用トリガーフレームと呼ぶことがある。基地局が送信するトリガーフレームとして、ランダムアクセス用トリガーフレームを用いることで、トリガーフレームで指定されていない端末が、端末未指定リソースブロックからランダムにリソースブロックを選択して、フレームを送信することができる。なお、端末がランダムにリソースブロックを選択する方法は、乱数を利用して選択する方法など任意の方法でかまわない。ランダムアクセス用トリガーフレームの構成は端末未指定リソースブロックを表現できる限り、任意でかまわない。例えば図１１（Ａ）のフォーマットにおいて、ＳＴＡ Ｉｎｆｏフィールドに、端末の識別子の代わりに、所定の識別子（どの端末にも割り当てられない識別子）とリソースブロックの識別子とを設定し、この所定の識別子が設定されたリソースブロックは、端末未指定リソースブロックであると解釈してもよい。

図１６に、本発明の実施形態に係る端末の動作の一例のフローチャートを示す。この端末の動作は、図７に示したシーケンス例における端末の動作に対応する。端末は、送信用のデータを保持している場合（Ｓ１０１のＹＥＳ）、ＣＳＭＡ／ＣＡに従って無線媒体へのアクセス権を獲得し、当該データを含むデータフレームを生成し、ＴＸＯＰの間、データフレーム（より詳細にはデータフレームを含む物理パケット）を送信する（Ｓ１０２）。ここでデータフレームまたは物理パケットの物理ヘッダは、前述した通知フィールドを含み、通知フィールドには、通知情報（前述した第１〜第９の例の通知情報を参照）を設定する。このように、通知情報は、端末が自発的に送信するデータフレームに格納されて送られる、すなわち、基地局から通知情報の送信要求を受けること無く送信される。本例では、データフレームに通知情報を含める例を示しているが、管理フレームまたは制御フレームに通知情報を含めて送ることも可能である。端末は、基地局からトリガーフレームを受信しない間は（Ｓ１０３のＮＯ）、上記と同様の処理を繰り返す。端末は、基地局からトリガーフレームを受信した場合は（Ｓ１０３のＹＥＳ）、自端末がＵＬ−ＭＵ送信の対象端末として指定されているかを判断し、自端末が指定されている場合は（Ｓ１０４のＹＥＳ）、トリガーフレームの受信完了から一定時間後に、送信用のデータを含むデータフレーム（より詳細にはデータフレームを含む物理パケット）を送信する（Ｓ１０５）。
トリガーフレームで、送信するデータまたはデータフレーム等に関する条件が指定されている場合は、その条件を満たすようにデータフレームを生成および送信する。送信用のデータが存在しない場合は、ヌルパケットを送信または何も送信しないようにしてもよい。ここではデータフレームを送信したが、管理フレームまたは制御フレームを送信してもよい。当該データフレームに、通知情報を設定する通知フィールドを設けてもよい。端末は、データフレームの送信からＳＩＦＳ時間後、基地局から送達確認フレームを受信する。なお、端末は、送達確認応答フレームの受信からＳＩＦＳ後にさらにデータフレームを送信する構成も可能である。

図１７に、本発明の実施形態に係る基地局の動作の一例のフローチャートを示す。この基地局の動作は、図７に示したシーケンス例における基地局の動作に対応する。基地局は、端末からデータフレーム等のフレームを受信したら（Ｓ２０１）、フレームから通知情報を取得し（通知フィールドが存在するフレームの場合）、通知情報に基づき、ＵＬ−ＭＵ送信の要求の有無等、端末の状態を管理する（Ｓ２０２）。基地局は、ＵＬ−ＭＵ通信の開始を決定するまで、上記の処理を繰り返す。ＵＬ−ＭＵ通信の開始を決定すると（Ｓ２０３のＹＥＳ）、ＵＬ−ＭＵ通信の対象端末、および送信の際のパラメータ情報等、必要事項の決定を行い（Ｓ２０４）、対象端末にトリガーフレームを送信する（Ｓ２０５）。基地局は、トリガーフレームの送信から一定時間後に対象端末から同時に送信されるデータフレーム等のフレームを受信する（Ｓ２０６）。基地局は、フレームの受信からＳＩＦＳ時間後に、対象端末に送達確認応答フレームを送信する。この後、基地局は、再度必要事項の決定の処理（Ｓ２０４）に戻ってもよいし、トリガーフレームの送信処理（Ｓ２０５）に戻ってもよいし、ＵＬ−ＭＵ送信の受信処理（Ｓ２０６）に戻ってもよい。あるいは、ステップＳ２０１など他のステップの処理に戻ってもよい。基地局は、端末からＵＬ−ＭＵ送信されるフレームに通知情報が設定されている場合は、当該通知情報を次以降のＵＬ−ＭＵ送信に必要な事項を決定するために用いる。

図１８に、本発明の実施形態に係る基地局の動作の他の例のフローチャートを示す。図１７との差分は、基地局が、ＵＬ−ＭＵ送信の開始を決定した後、トリガーフレームの送信前に、図１４または図１５に示したような問い合わせフェーズ（Ｓ２０７）を実行することにある。例えば、問い合わせフェーズでは、問い合わせフェーズ前に収集した通知情報に基づき、ＵＬ−ＭＵ送信を行う候補端末を選択し、選択した候補端末にＵＬ−ＭＵ通信の実行要求の有無等に関する問い合わせフレームを送信する。そして、候補端末からＵＬ−ＭＵ通信の実行要求の有無等を通知する要求フレームを受信する。問い合わせフェーズ後の必要事項の決定（Ｓ２０４）では、例えば、候補端末のうち、ＵＬ−ＭＵ通信の実行要求有りを通知した端末の中から対象端末を選択する。つまり、問い合わせフェーズ前に収集した通知情報でラフな推定を行い、問い合わせフェーズでの問い合わせにより、より精度の高い推定を行っているということができる。ＵＬ−ＭＵ送信の実行後、再度、問い合わせフェーズに戻ってもよいし、その他のステップの処理に戻ってもよい。

本実施形態では、ＵＬ−ＭＵ通信の必要事項の決定のために通知情報を送信したが、変形例として、ＨＣＣＡ環境において、基地局の通信対象となる端末を決定、または端末にデータ送信させるＴＩＤを決定するために、各端末から基地局に通知情報を送信することも可能である。ＨＣＣＡ環境では、基地局が端末にＱｏＳ ＣＦ−Ｐｏｌｌフレームを送信し、端末は、当該フレームで指定されたＴＸＯＰの間、フレームを送信することを許容される。ＱｏＳ ＣＦ−ＰｏｌｌフレームではＴＩＤが指定される。そこで、基地局が、端末およびＴＩＤの少なくとも一方を指定するための判断材料として、前述した第１〜第９の例の少なくとも１つまたはこれらの任意の組み合わせに係る通知情報を各端末が送信することも可能である。

以上、本実施形態によれば、各端末が、基地局から要求を受けること無く、通知情報を含むフレームを送信することで、基地局は効率的に通知情報を収集できる。また、各端末は、ＣＳＭＡ／ＣＡベースで通常に基地局にシングルユーザ送信するフレーム（データフレーム、アソシエーション要求フレームなど）に通知情報を含めることで、システム効率の低下を抑制しつつ、基地局は通知情報を収集できる。また、基地局は、問い合わせフェーズを設けることで、アップリンク用のデータを有する端末をより確実に絞り込むことができる。

（第２の実施形態）
図１９は、第２の実施形態に係る基地局（アクセスポイント）４００の機能ブロック図である。このアクセスポイントは、通信処理部４０１と、送信部４０２と、受信部４０３と、アンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄと、ネットワーク処理部４０４と、有線Ｉ／Ｆ４０５と、メモリ４０６とを備えている。アクセスポイント４００は、有線Ｉ／Ｆ４０５を介して、サーバ４０７と接続されている。通信処理部４０１は、第１の実施形態で説明したＭＡＣ処理部１０およびＭＡＣ／ＰＨＹ管理部６０と同様な機能を有している。送信部４０２および受信部４０３は、第１の実施形態で説明したＰＨＹ処理部５０およびアナログ処理部７０と同様な機能を有している。ネットワーク処理部４０４は、第１の実施形態で説明した上位処理部９０と同様な機能を有している。ここで、通信処理部４０１は、ネットワーク処理部４０４との間でデータを受け渡しするためのバッファを内部に保有してもよい。このバッファは、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。

ネットワーク処理部４０４は、通信処理部４０１とのデータ交換、メモリ４０６とのデータ書き込み・読み出し、および、有線Ｉ／Ｆ４０５を介したサーバ４０７との通信を制御する。ネットワーク処理部４０４は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理やアプリケーション層の処理を行ってもよい。ネットワーク処理部の動作は、ＣＰＵ等のプロセッサによるソフトウェア（プログラム）の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。

一例として、通信処理部４０１は、ベースバンド集積回路に対応し、送信部４０２と受信部４０３は、フレームを送受信するＲＦ集積回路に対応する。通信処理部４０１とネットワーク処理部４０４とが１つの集積回路（１チップ）で構成されてもよい。送信部４０２および受信部４０３のデジタル領域の処理を行う部分とアナログ領域の処理を行う部分とが異なるチップで構成されてもよい。また、通信処理部４０１が、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理を実行するようにしてもよい。また、アンテナの個数はここでは４つであるが、少なくとも１つのアンテナを備えていればよい。

メモリ４０６は、サーバ４０７から受信したデータや、受信部４０２で受信したデータの保存等を行う。メモリ４０６は、例えば、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。また、ＳＳＤやＨＤＤ、ＳＤカード、ｅＭＭＣ等であってもよい。メモリ４０６が、基地局４００の外部にあってもよい。

有線Ｉ／Ｆ４０５は、サーバ４０７とのデータの送受信を行う。本実施形態では、サーバ４０７との通信を有線で行っているが、サーバ４０７との通信を無線で実行するようにしてもよい。

サーバ４０７は、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばＨＴＴＰサーバ（Ｗｅｂサーバ）、ＦＴＰサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。ＰＣやスマートフォン等のユーザが操作する通信装置でもよい。また、基地局４００と無線で通信してもよい。

基地局４００のＢＳＳに属するＳＴＡが、サーバ４０７に対するデータの転送要求を発行した場合、このデータ転送要求に関するパケットが、基地局４００に送信される。基地局４００は、アンテナ４２Ａ〜４２Ｄを介してこのパケットを受信し、受信部４０３で物理層の処理等を、通信処理部４０１でＭＡＣ層の処理等を実行する。

ネットワーク処理部４０４は、通信処理部４０１から受信したパケットの解析を行う。具体的には、宛先ＩＰアドレス、宛先ポート番号等を確認する。パケットのデータがＨＴＴＰ ＧＥＴリクエストのようなデータ転送要求である場合、ネットワーク処理部４０４は、このデータ転送要求で要求されたデータ（例えば、ＨＴＴＰ ＧＥＴリクエストで要求されたＵＲＬに存在するデータ）が、メモリ４０６にキャッシュ（記憶）されているかを確認する。メモリ４０６には、ＵＲＬ（またはその縮小表現、例えばハッシュ値や、代替となる識別子）とデータとを対応づけたテーブルが格納されている。ここで、データがメモリ４０６にキャッシュされていることを、メモリ４０６にキャッシュデータが存在すると表現する。

メモリ４０６にキャッシュデータが存在しない場合、ネットワーク処理部４０４は、有線Ｉ／Ｆ４０５を介して、サーバ４０７に対してデータ転送要求を送信する。つまり、ネットワーク処理部４０４は、ＳＴＡの代理として、サーバ４０７へデータ転送要求を送信する。具体的には、ネットワーク処理部４０４は、ＨＴＴＰリクエストを生成し、ＴＣＰ／ＩＰヘッダの付加などのプロトコル処理を行い、パケットを有線Ｉ／Ｆ４０５へ渡す。有線Ｉ／Ｆ４０５は、受け取ったパケットをサーバ４０７へ送信する。

有線Ｉ／Ｆ４０５は、データ転送要求に対する応答であるパケットをサーバ４０７から受信する。ネットワーク処理部４０４は、有線Ｉ／Ｆ４０５を介して受信したパケットのＩＰヘッダから、ＳＴＡ宛のパケットであることを把握し、通信処理部４０１へパケットを渡す。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ〜４２Ｄから送信する。ここで、ネットワーク処理部４０４は、サーバ４０７から受信したデータを、ＵＲＬ（またはその縮小表現）と対応づけて、メモリ４０６にキャッシュデータとして保存する。

メモリ４０６にキャッシュデータが存在する場合、ネットワーク処理部４０４は、データ転送要求で要求されたデータをメモリ４０６から読み出して、このデータを通信処理部４０１へ送信する。具体的には、メモリ４０６から読み出したデータにＨＴＴＰヘッダ等を付加して、ＴＣＰ／ＩＰヘッダの付加等のプロトコル処理を行い、通信処理部４０１へパケットを送信する。このとき、一例として、パケットの送信元ＩＰアドレスは、サーバと同じＩＰアドレスに設定し、送信元ポート番号もサーバと同じポート番号（通信端末が送信するパケットの宛先ポート番号）に設定する。したがって、ＳＴＡから見れば、あたかもサーバ４０７と通信をしているかのように見える。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ〜４２Ｄから送信する。

このような動作により、頻繁にアクセスされるデータは、メモリ４０６に保存されたキャッシュデータに基づいて応答することになり、サーバ４０７と基地局４００間のトラフィックを削減できる。なお、ネットワーク処理部４０４の動作は、本実施形態の動作に限定されるものではない。ＳＴＡの代わりにサーバ４０７からデータを取得して、メモリ４０６にデータをキャッシュし、同一のデータに対するデータ転送要求に対しては、メモリ４０６のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題はない。

図１９と同じブロック構成で、キャッシュ機能を備えた端末（ＳＴＡ）を実現することができる。この場合、有線Ｉ／Ｆ４０５を省略してもよい。本実施形態の端末を、第１の実施形態の端末として適用可能である。例えば、端末は、メモリ４０６にキャッシュされているデータを読み出し、読み出したデータを含むデータフレーム（より詳細には物理ヘッダを付加した物理パケット）を、基地局に送信する。当該データはサーバ４０７から取得したデータであっても、別の方法で取得したデータ（例えばサーバ４０７以外の外部装置から取得したデータ、またはユーザが指定したファイルデータなど）であってもよい。また、端末は、第１の実施形態で説明した各例の通知情報（制御情報）を、メモリ４０６にキャッシュされている基地局への送信用のデータに基づき生成してもよい。端末は、生成した通知情報を、図６のデータフレーム５０１、５０３、５０５を介して送信してもよいし、データフレーム５０９〜５１２を介して送信してもよい。また、端末は、メモリ４０６にキャッシュされている基地局への送信用のデータを、図６のデータフレーム５０１、５０３、５０５を介して送信してもよいし、アップリンクマルチユーザ送信で図６のデータフレーム５０９〜５１２を介して送信してもよい。

なお、マルチホップネットワークの場合、端末は、非基地局としての端末の役割と、基地局としての役割との両方を備える。端末は、基地局として動作する場合に、他の端末から受信したデータを、別の基地局へ当該データを転送する端末として動作する場合のため、メモリにキャッシュしておけばよい。

本実施形態の基地局を第１の実施形態に適用する場合、以下の動作を行ってもよい。基地局は、端末に送信するデータをメモリ４０６から読み出し、読み出したデータを含むフレーム（トリガーフレーム、問い合わせフレーム、またはデータフレーム等）を生成および送信してもよい。また、メモリ４０６における各端末への送信用のデータそのものを、トリガーフレーム等のフレームに追加してもよい。メモリ４０６における各端末への送信用のデータは、各端末からのデータ転送要求を受けて取得したものに限らず、当該データ転送要求とは関係無しに、サーバ４０７またはサーバ４０７以外の外部装置から送信されたデータでもよい。例えば各端末宛てのプッシュデータまたは電子メールデータなどでもよい。なお、基地局は、複数の端末に対してダウンリンクのマルチユーザ方式（ＤＬ−ＯＦＤＭＡ、ＤＬ−ＭＵ−ＭＩＭＯ、またはこれらを組み合わせた方式（ＤＬ−ＯＦＤＭＡ＆ＤＬ−ＭＵ−ＭＩＭＯ）等）で、メモリ４０６における複数の端末への送信用のデータを送信してもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（第１２の実施形態）
第１２の実施形態では、上述したいずれかの実施形態に係る無線通信装置（基地局の無線通信装置または無線通信端末の無線通信装置、またはこれらの両方）の構成に加えて、ディスプレイを含む。ディスプレイは、図示しないバスを介して、無線通信装置のＭＡＣ処理部に接続されてもよい。このようにディスプレイを備える構成とし、無線通信装置の動作状態をディスプレイに表示することで、無線通信装置の動作状態をユーザに容易に通知することが可能となる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、各実施形態で述べるフレームは、例えばＩＥＥＥ８０２．１１規格でフレームと呼ばれているもののみならず、Ｎｕｌｌ Ｄａｔａ Ｐａｃｋｅｔなど、パケットと呼ばれているものを指してもよい。基地局が複数のフレームまたは複数の第Ｘフレームを送信または受信すると表現する場合、これらのフレームまたは第Ｘフレームは同じものであっても異なるものであってもよい。Ｘには状況に応じて任意の値を入れることができる。

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

以下、原出願における特許査定時の特許請求の範囲の記載を付記する。
［項目１］
アップリンクのユーザ多重送信に必要な第１情報をそれぞれ含む複数の第１フレームを、受信する受信部と、
前記複数の第１フレームに含まれる前記第１情報に基づいて生成した第２フレームを送信する送信部と、を備え、
前記送信部は、前記複数の第１フレームが受信される前に、前記第１情報の送信要求を送信せず、
前記第２フレームは、前記第２フレームの受信から一定時間後に、データを含む第３フレームの送信を指示するフレームであり、
前記第１情報は、複数のデータ種別のうち最も送信の優先度が高いデータ種別を指定する情報を含む
無線通信装置。
［項目２］
前記ユーザ多重送信は、少なくとも周波数多重送信および空間多重送信のいずれか１つである
項目１に記載の無線通信装置。
［項目３］
前記第３フレームの最大長および前記データの最大長の少なくとも一方を決定する制御部を備え、
前記送信部は、前記少なくとも一方の最大長に関する情報を含む前記第２フレームを送信する
項目１または２に記載の無線通信装置。
［項目４］
複数の他の無線通信端末の中から前記ユーザ多重送信を行う複数の対象端末を選択し、前記複数の対象端末のそれぞれに対し前記データのデータ種別を決定する制御部を備え、 前記送信部は、前記複数の対象端末のそれぞれに対し前記データ種別を指定する情報を含む前記第２フレームを送信する
項目１ないし３いずれか一項に記載の無線通信装置。
［項目５］
前記第１情報は、複数のデータ種別毎に、送信用のデータの有無に関する情報を含み、 前記制御部は、前記複数のデータ種別のうち第１データ種別の送信用のデータを有する前記無線通信端末の中から前記複数の対象端末を選択し、
前記送信部は、前記複数の対象端末に対し前記第１データ種別を共通に指定する情報を含む前記第２フレームを送信する
項目４に記載の無線通信装置。
［項目６］
前記第１情報は、複数のデータ種別毎に送信用のデータ量に関する情報を含み、
前記制御部は、前記複数のデータ種別のうち第１データ種別の送信用のデータ量に基づいて前記複数の対象端末を選択し、
前記送信部は、前記複数の対象端末に対し前記第１データ種別を共通に指定する情報を含む前記第２フレームを送信する
項目４に記載の無線通信装置。
［項目７］
前記第１情報は、複数のデータ種別毎に送信の優先度に関する情報を含み、
前記制御部は、前記複数のデータ種別のうち第１データ種別の優先度に基づいて前記複数の対象端末を選択し、
前記送信部は、前記複数の対象端末に対し前記第１データ種別を共通に指定する情報を含む前記第２フレームを送信する
項目４に記載の無線通信装置。
［項目８］
前記データ種別は、ＩＥＥＥ８０２．１１規格で定められたアクセスカテゴリまたはトラヒックＩＤである
項目１ないし７のいずれか一項に記載の無線通信装置。
［項目９］
複数の無線通信端末の中から前記ユーザ多重送信を行う複数の対象端末を選択する制御部を備え、
前記送信部は、前記複数の対象端末を指定する情報を含む前記第２フレームを送信し、 前記第１情報は、前記無線通信端末が希望する前記ユーザ多重送信の通信方式に関する情報を含み、
前記制御部は、第１の通信方式を希望する前記無線通信端末の中から前記複数の対象端末を選択する
項目１ないし８のいずれか一項に記載の無線通信装置。
［項目１０］
複数の無線通信端末の中から前記ユーザ多重送信を行う複数の対象端末を選択し、
前記複数の対象端末が前記ユーザ多重送信で用いるリソースを決定する、制御部を備え、
前記送信部は、前記複数の対象端末に対して前記リソースを指定する情報を含む前記第２フレームを、送信する
項目１ないし９のいずれか一項に記載の無線通信装置。
［項目１１］
前記複数の第１フレームに含まれる前記第１情報に基づき、前記ユーザ多重送信を行う複数の候補端末を、複数の無線通信端末の中から選択する制御部を備え、
前記送信部は、前記複数の候補端末に前記ユーザ多重送信の実行要求の有無に関する問い合わせを行うための第４フレームを送信する
項目１ないし１０のいずれか一項に記載の無線通信装置。
［項目１２］
前記制御部は、前記第４フレームに対し前記ユーザ多重送信の実行要求が有ることを通知する第５フレームを返信した前記候補端末の中から、前記ユーザ多重送信を行う複数の対象端末を選択する
項目１１に記載の無線通信装置。
［項目１３］
少なくとも１つのアンテナ
をさらに備えた項目１ないし１２のいずれか一項に記載の無線通信装置。
［項目１４］
少なくとも１つのアンテナと、
前記アンテナに結合され、フレームを受信する受信部と、
前記アンテナに結合され、フレームを送信する送信部と、
前記受信部および前記送信部に結合された通信処理部と、
前記通信処理部に結合され、前記通信処理部へデータを送信し、別の装置からデータを受信する、ネットワーク処理部と、
前記ネットワーク処理部に結合され、前記他の装置からの第１データをキャッシュする、メモリと、
を備え、
前記受信部は、前記送信部からアップリンクのユーザ多重送信に必要な第１情報の送信要求を送信することなく、前記アンテナを介して、前記第１情報をそれぞれ含む複数の第１フレームを受信し、
前記送信部は、前記アンテナを介して、前記複数の第１フレームに含まれる前記第１情報と前記メモリにキャッシュされている前記第１データとに基づき生成される第２フレームを送信し、
前記第２フレームは、前記第２フレームの受信から一定時間後に、データを含む第３フレームの送信を指示するフレームであり、
前記第１情報は、複数のデータ種別のうち最も送信の優先度が高いデータ種別を指定する情報を含む
無線通信端末。
［項目１５］
前記ユーザ多重送信は、少なくとも周波数多重送信および空間多重送信のいずれか１つである
項目１４に記載の無線通信端末。
［項目１６］
前記通信処理部は、前記第３フレームの最大長および前記データの最大長の少なくとも一方を決定し、
前記送信部は、前記アンテナを介して、前記少なくとも一方の最大長に関する情報を含む前記第２フレームを送信する
項目１４または１５に記載の無線通信端末。
［項目１７］
前記通信処理部は、複数の他の無線通信端末の中から前記ユーザ多重送信を行う複数の対象端末を選択し、前記複数の対象端末のそれぞれに対し前記データのデータ種別を決定し、
前記第２フレームは、前記複数の対象端末のそれぞれに対し前記データ種別を指定する情報を含む
項目１４ないし１６のいずれか一項に記載の無線通信端末。
［項目１８］
前記第１情報は、複数のデータ種別毎に、送信用のデータの有無に関する情報を含み、 前記通信処理部は、前記複数のデータ種別のうち第１データ種別の送信用のデータを有する前記他の無線通信端末の中から、前記複数の対象端末を選択し、
前記第２フレームは、前記複数の対象端末に対し前記第１データ種別を共通に指定する情報を含む
項目１７に記載の無線通信端末。
［項目１９］
前記第１情報は、複数のデータ種別毎に送信用のデータ量に関する情報を含み、
前記通信処理部は、前記複数のデータ種別のうち第１データ種別の送信用のデータ量に基づいて前記複数の対象端末を選択し、
前記第２フレームは、前記複数の対象端末に対し前記第１データ種別を共通に指定する情報を含む
項目１７に記載の無線通信端末。
［項目２０］
無線通信端末による無線通信方法であって、
他の装置からの第１データをメモリにキャッシュし、
アップリンクのユーザ多重送信に必要な第１情報をそれぞれ含む複数の第１フレームを、前記第１情報の送信要求を送信することなく受信し、
前記複数の第１フレームに含まれる前記第１情報と前記メモリにキャッシュされている前記第１データとに基づいて生成される第２フレームを送信し
前記２フレームは、前記第２フレームの受信から一定時間後に、データを含む第３フレームの送信を指示するフレームであり、
前記第１情報は、複数のデータ種別のうち最も送信の優先度が高いデータ種別を指定する情報を含む
無線通信方法。

１０：ＭＡＣ処理部
２０：ＭＡＣ共通処理部
３０：送信処理部
４０：受信処理部
５０：ＰＨＹ処理部
６０：ＭＡＣ／ＰＨＹ管理部
７０：アナログ処理部（アナログ処理部１〜Ｎ）
８０：アンテナ（アンテナ１〜Ｎ）
９０：上位処理部
１４８：無線ＬＡＮモジュール
１４９：ホストシステム
２１１：ベースバンドＩＣ
２１３：メモリ
２１４：ホスト・インターフェース
２１５：ＣＰＵ
２１６：ＤＡＣ
２１７：ＡＤＣ
２２１：ＲＦ ＩＣ
２２２、２３２：フィルタ
２２３、２３３：ミキサ
２２４、２３４：アンプ
２２５、２３５：バラン
２４２：ＰＬＬ
２４３：水晶発振器
２４７：アンテナ
２４５：スイッチ
３０１：ノートＰＣ
３０５、３１５、３５５：無線通信装置
３２１：移動体端末
３３１：メモリーカード
３３２：メモリーカード本体
４２Ａ、４２Ｂ、４２Ｃ、４２Ｄ：アンテナ
４０１：通信処理部
４０２：送信部
４０３：受信部
４０４：ネットワーク処理部
４０５：有線Ｉ／Ｆ
４０６：メモリ

Claims (1)

1. アップリンクのユーザ多重送信に必要な第１情報を含む複数の第１フレームを受信する受信部と、
   前記複数の第１フレームに含まれる前記第１情報に基づいて生成した第２フレームを送信する送信部と、を備え、
   前記第２フレームは、前記第２フレームの受信から一定時間後に、データを含む第３フレームの送信を指示するフレームである
   無線通信装置。

Images