(57)【要約】      （修正有）【課題】通信リソースを効率的に使用してアップリンク周波数多重送信を行う無線通信装置および無線通信方法を提供する。【解決手段】無線装置は、複数の周波数成分を指定する情報を含み、複数の無線通信端末による周波数多重送信の実施を指示する第１フレームを送信する送信部と、前記複数の周波数成分のうちの少なくとも１つの周波数成分で第２フレームを受信する受信部を備える。第１フレームは、複数の無線通信端末の各々の端末識別子を複数の周波数成分のうちの少なくとも１つに関連づけて指定する第１形態と、複数の無線通信端末が属するグループのグループ識別子を指定する第２形態のいずれか一方の形態を有する。【選択図】図１
2020129804.tif 000002
【特許請求の範囲】
【請求項１】
無線通信装置であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを送信する送信部と、
前記第１フレームに応答して送信される少なくとも１つの第２フレームを受信する受信部と、
を備え、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定され、
前記第１グループ識別子は、前記無線通信装置とアソシエーションを完了した第１無線通信端末群を指定し、
前記第２グループ識別子は、前記無線通信装置とアソシエーション未完了の第２無線通信端末群を指定し、
リソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記第１フレームは、
前記少なくとも１つの組の前記第１フィールドで指定された第１グループ識別子又は第２グループ識別子に該当する無線通信端末群の無線通信端末に
前記第２フレームの送信リソースユニットの選択権があるかを判断させ、
前記選択権がある場合に前記第１フィールドと対になる前記第２フィールドで指定されるリソースユニットの中からランダムに送信リソースユニットを決定させ、
前記送信リソースユニットを介して前記第２フレームを送信させる
無線通信装置。
【請求項２】
前記無線通信装置は、ＩＥＥＥ８０２．１１規格に準拠しており、
前記第１無線通信端末群は、前記無線通信装置によってＡＩＤを割り当てられた無線通信端末群であり、
前記第２無線通信端末群は、前記無線通信装置によってＡＩＤを割り当てられていない無線通信端末群である
請求項１に記載の無線通信装置。
【請求項３】
前記第１グループ識別子及び前記第２グループ識別子は、ＩＥＥＥ８０２．１１規格における複数のＡＩＤのうち、前記無線通信装置とアソシエーションを完了した無線通信端末に割り当てることが可能なＡＩＤ以外のＡＩＤの中から選択されており、
前記第１グループ識別子のＡＩＤと前記第２グループ識別子のＡＩＤは互いに異なる
請求項１又は２に記載の無線通信装置。
【請求項４】
前記第１グループ識別子のＡＩＤと前記第２グループ識別子のＡＩＤは、０又は２００７より大きい値から選択されている
請求項２又は３に記載の無線通信装置。
【請求項５】
前記第１フレームは、前記無線通信端末がアップリンク送信用のデータを有する場合に、前記無線通信端末に前記第２フレームを送信させる
請求項１〜４のいずれか一項に記載の無線通信装置。
【請求項６】
前記第１フレームは、第３フィールドと第４フィールドとの少なくとも１つの組を含み、
無線通信端末の識別子が少なくとも１つの組の前記第３フィールドに設定され、
前記第１情報が、少なくとも１つの組の前記第４フィールドに設定され、
前記第１フレームは、少なくとも１つの組の前記第３フィールドで指定された無線通信端末に、前記第３フィールドと対になる前記第４フィールドで指定された前記リソースユニットを介して、前記第２フレームを送信させる
請求項１〜５のいずれか一項に記載の無線通信装置。
【請求項７】
前記第１フレームは、前記無線通信端末が前記第３フィールドで指定されておらず、かつ前記第１フィールドで指定された前記第１グループ識別子又は前記第２グループ識別子に該当する無線通信端末群の無線通信端末である場合に、前記無線通信端末に前記第２フレームの送信リソースユニットの選択権があるかを判断させ、前記選択権がある場合に前記第１フィールドと対になる前記第２フィールドで指定されるリソースユニットの中からランダムに送信リソースユニットを決定させ、前記送信リソースユニットを介して前記第２フレームを送信させる
請求項６に記載の無線通信装置。
【請求項８】
前記第１フレームは、前記第１フレームを受信した無線通信端末が前記第２フレームの処理対象と異なる場合に、前記第１フレームを受信した前記無線通信端末をスリープに移行させる
請求項１〜７のいずれか一項に記載の無線通信装置。
【請求項９】
前記第１フレームは、前記第１グループ識別子又は前記第２グループ識別子に該当する無線通信端末群の複数の前記無線通信端末が前記第２フレームを送信するのに必要なパラメータを共通にする
請求項１〜８のいずれか一項に記載の無線通信装置。
【請求項１０】
少なくとも１つのアンテナをさらに備えた
請求項１〜９のいずれか一項に記載の無線通信装置。
【請求項１１】
無線通信装置により実行する無線通信方法であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを送信し、
前記第１フレームに応答して送信される少なくとも１つの第２フレームを受信し、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定され、
前記第１グループ識別子は、前記無線通信装置とアソシエーションを完了した第１無線通信端末群を指定し、
前記第２グループ識別子は、前記無線通信装置とアソシエーション未完了の第２無線通信端末群を指定し、
リソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記第１フレームは、
前記少なくとも１つの組の前記第１フィールドで指定された第１グループ識別子又は第２グループ識別子に該当する無線通信端末群の無線通信端末に
前記第２フレームの送信リソースユニットの選択権があるかを判断させ、
前記選択権がある場合に前記第１フィールドと対になる前記第２フィールドで指定されるリソースユニットの中からランダムに送信リソースユニットを決定させ、
前記送信リソースユニットを介して前記第２フレームを送信させる
無線通信方法。
【請求項１２】
無線通信装置であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを受信する受信部と、
制御部と、
送信部とを、備え、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定されており、
前記第１グループ識別子は、基地局とアソシエーションを完了した第１無線通信端末群を指定し、前記第２グループ識別子は、前記基地局とアソシエーション未完了の第２無線通信端末群を指定し、
リソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記制御部は、前記無線通信装置が前記基地局とアソシエーション未完了の場合は、前記第２グループ識別子が設定された前記第１フィールドを特定し、前記無線通信装置が前記基地局とアソシエーションを完了している場合は、前記第１グループ識別子が設定された前記第１フィールドを特定し、
前記送信部は、特定した前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの中からランダムに送信リソースユニットを決定し、前記送信リソースユニットを介して、第２フレームを送信する、
無線通信装置。
【請求項１３】
前記送信部は、前記無線通信装置がアップリンク送信用のデータを有する場合に、前記第２フレームを送信する
請求項１２に記載の無線通信装置。
【請求項１４】
前記第１フレームは、第３フィールドと第４フィールドとの少なくとも１つの組を含み、
無線通信端末の識別子が少なくとも１つの組の前記第３フィールドに設定され、
前記第１情報が、少なくとも１つの組の前記第４フィールドに設定され、
前記送信部は、前記無線通信装置が少なくとも１つの組の前記第３フィールドで指定されている場合に、前記第３フィールドと対になる前記第４フィールドで指定された前記リソースユニットを介して、前記第２フレームを送信する
請求項１２又は１３に記載の無線通信装置。
【請求項１５】
前記送信部は、前記無線通信装置が前記第３フィールドで指定されておらずかつ前記少なくとも１つの組の前記第１フィールドで指定された前記第１グループ識別子又は前記第２グループ識別子に該当する無線通信端末群の無線通信端末である場合に、前記第２フレームの送信リソースユニットの選択権があるかを判断し、前記選択権がある場合に前記第１フィールドと対になる前記第２フィールドで指定されるリソースユニットの中からランダムに送信リソースユニットを決定し、前記送信リソースユニットを介して前記第２フレームを送信する
請求項１４に記載の無線通信装置。
【請求項１６】
前記無線通信装置が前記第２フレームの処理対象と異なる場合に、スリープに移行する
請求項１２〜１５のいずれか一項に記載の無線通信装置。
【請求項１７】
前記送信部は、前記第１グループ識別子又は前記第２グループ識別子に該当する無線通信端末群の他の無線通信端末と共通のパラメータを用いて、前記第２フレームを送信する
請求項１２〜１６のいずれか一項に記載の無線通信装置。
【請求項１８】
少なくとも１つのアンテナをさらに備えた
請求項１２〜１７のいずれか一項に記載の無線通信装置。
【請求項１９】
無線通信装置により実行される無線通信方法であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを受信し、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定されており、
前記第１グループ識別子は、基地局とアソシエーションを完了した第１無線通信端末群を指定し、
前記第２グループ識別子は、前記基地局とアソシエーション未完了の第２無線通信端末群を指定し、
リソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記無線通信装置が前記基地局とアソシエーション未完了の場合は、前記第２グループ識別子が設定された前記第１フィールドを特定し、
前記無線通信装置が前記基地局とアソシエーションを完了している場合は、前記第１グループ識別子が設定された前記第１フィールドを特定し、
特定した前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの中からランダムに送信リソースユニットを決定し、前記送信リソースユニットを介して、第２フレームを送信する、
無線通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、無線通信装置および無線通信方法に関する。
【背景技術】
【０００２】
無線通信端末（以下、端末）ごとに異なる周波数成分を通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う周波数多重通信を考える。
ここでは、周波数成分を、１つまたは複数のサブキャリアを含むリソースユニットとして定義し、リソースユニットを最小単位の通信リソースとして用いて、複数の端末宛ての送信または複数の端末からの受信を同時に行う直交周波数分割多元接続方式（ＯＦＤＭＡ；Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）を考える。基地局から複数の端末宛ての同時送信はダウンリンクＯＦＤＭＡ（ＤＬ−ＯＦＤＭＡ）送信、複数の端末から基地局への同時送信はアップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）送信に相当する。
【０００３】
アップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ）通信を行う場合、各端末のアップリンク送信のタイミングを揃えるために、基地局からトリガーフレームを送信することが考えられる。トリガーフレームを用いて、リソースユニット毎の割り当て端末に関する情報を通知することで、ＵＬ−ＯＦＤＭＡ通信を行う端末と当該端末に使用させるリソースユニットを指定する方法がある。この方法では、端末がスリープモードに遷移していたり、端末にアップリンク送信の要求がなかったりする場合など、通信リソースの使用効率が低下する問題がある。別の方法として、トリガーフレームでは、端末の指定は行わず、使用するリソースユニットのみを指定するものがある。この場合、トリガーフレームを受信した端末は、ランダムバックオフ手法に類似した方法に基づきリソースユニットを選択する。この際、トリガーフレームを受信した端末の数が多いと、同じリソースユニットを選択する可能性が高くなる。複数の端末が同じリソースユニットを使ってフレームを送信すると、基地局ではフレームを正常に受信することができなくなる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ＩＥＥＥ  ８０２．１１−１５／０６０４ｒ１
【非特許文献２】ＩＥＥＥ  Ｓｔｄ  ８０２．１１ａｃ（ＴＭ）−２０１３
【非特許文献３】ＩＥＥＥ  Ｓｔｄ  ８０２．１１（ＴＭ）−２０１２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施形態は、通信リソースを効率的に使用してアップリンク周波数多重送信を行うことを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一態様としての無線装置は、複数の周波数成分を指定する情報を含み、複数の無線通信端末による周波数多重送信の実施を指示する第１フレームを送信する送信部と、前記複数の周波数成分のうちの少なくとも１つの周波数成分で、第２フレームを受信する受信部と、を備え、前記第１フレームは、前記複数の無線通信端末の各々の端末識別子を前記複数の周波数成分のうちの少なくとも１つに関連づけて指定する第１形態と、前記複数の無線通信端末が属するグループのグループ識別子を指定する第２形態のいずれか一方の形態を有する。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態に係る無線通信装置の機能ブロック図。
【図２】リソースユニットの割り当てを説明するための図。
【図３】リソースユニットの様々な構成を説明するための図。
【図４】基地局と複数の端末とを含む無線通信グループを示す図。
【図５】ＭＡＣフレームの基本的なフォーマット例を示す図。
【図６】情報エレメントのフォーマット例を示す図。
【図７】本発明の実施形態に係る動作シーケンスの例を示す図。
【図８】トリガーフレームを含む物理パケットのフォーマット例を示す図。
【図９】トリガーフレームのフォーマット例を示す図。
【図１０】トリガーフレームにおけるＲＵ／ＡＩＤフィールドの構成例を示す図。
【図１１】トリガーフレームの他のフォーマット例を示す図。
【図１２】トリガーフレームのさらに他のフォーマット例を示す図。
【図１３】トリガーフレームのさらに他のフォーマット例を示す図。
【図１４】トリガーフレームのさらに他のフォーマット例を示す図。
【図１５】トリガーフレームのさらに他のフォーマット例を示す図。
【図１６】トリガーフレームのさらに他のフォーマット例を示す図。
【図１７】トリガーフレームのさらに他のフォーマット例を示す図。
【図１８】本発明の実施形態に係る基地局の動作の一例のフローチャートを示す図。
【図１９】トリガーフレームを送信するチャネルを説明する図。
【図２０】本発明の実施形態に係る端末の動作の一例のフローチャートを示す図。
【図２１】第２の実施形態に係る基地局または端末の機能ブロック図。。
【図２２】第３の実施形態に係る端末または基地局の全体構成例を示す図。
【図２３】第３の実施形態に係る端末または基地局に搭載される無線ＬＡＮモジュールのハードウェア構成例を示す。
【図２４】本発明の実施形態に係る無線通信端末の斜視図。
【図２５】本発明の実施形態に係るメモリーカードを示す図。
【図２６】コンテンション期間のフレーム交換の一例を示す図。
【発明を実施するための形態】
【０００８】
以下、図面を参照しながら、本発明の実施形態について説明する。無線ＬＡＮの規格書として知られているＩＥＥＥ  Ｓｔｄ  ８０２．１１（ＴＭ）−２０１２およびＩＥＥＥ
Ｓｔｄ  ８０２．１１ａｃ（ＴＭ）−２０１３は、本明細書においてその全てが参照によって組み込まれる（ｉｎｃｏｒｐｏｒａｔｅｄ  ｂｙ  ｒｅｆｅｒｅｎｃｅ）ものとする。
【０００９】
（第１の実施形態）  
図１に、第１の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局（以下、基地局またはアクセスポイント）、または基地局と通信する無線通信端末（以下、端末）に実装されることができる。基地局は、主に中継機能を有する点を除いて、基本的に端末と同様の通信機能を有するため、端末の一形態である。以下の説明で端末と言うときは、特に両者を区別する必要がない限り、基地局を指してもよい。
【００１０】
本実施形態では、複数の端末から基地局にアップリンクＯＦＤＭＡ（ＵＬ−ＯＦＤＭＡ：Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）送信を行う場合を想定する。ＵＬ−ＯＦＤＭＡでは、１つまたは複数のサブキャリアをリソースユニット（サブチャネル、リソースブロック、周波数ブロックなどと呼んでもよい）として端末に割り当て、リソースユニットベースで、複数の端末からの受信を同時に行う。リソースユニットは、通信を行うリソースの最小単位となる周波数成分である。図３に、１つのチャネル（ここではチャネルＭと記述している）の連続した周波数領域内に確保したリソースユニット（ＲＵ＃１、ＲＵ＃２、・・・ＲＵ＃Ｋ）を示す。チャネルＭには、互いに直交する複数のサブキャリアが配置されており、１つまたは複数の連続するサブキャリアを含む複数のリソースユニットがチャネルＭ内に定義されている。リソースユニット間には、１つ以上のサブキャリア（ガードサブキャリア）が配置されてもよいが、ガードサブキャリアは必須ではない。チャネル内の各サブキャリアには、サブキャリアを識別するための番号が付与されていてもよい。１つのチャネルの帯域幅は、一例として、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚなどであるが、これらに限定されない。２０ＭＨｚの複数のチャネルをまとめて１つのチャネルとしてもよい。帯域幅に応じてチャネル内のサブキャリア数またはリソースユニット数が異なってもよい。複数の端末がそれぞれ異なるリソースユニットを同時に用いることで、アップリンクＯＦＤＭＡ通信が実現される。
【００１１】
リソースユニットの帯域幅（あるいはサブキャリア数）は、各リソースユニットで共通でもよいし、リソースユニットごとに帯域幅（あるいはサブキャリア数）が異なってもよい。図３に、１つのチャネル内におけるリソースユニットの配置パターン例を模式的に示す。紙面に沿って横方向が周波数領域方向に対応する。図３（Ａ）は、同じ帯域幅の複数のリソースユニット（ＲＵ＃１、ＲＵ＃２、・・・ＲＵ＃Ｋ）を配置した例を示し。図３（Ｂ）は、図３（Ａ）より大きな帯域幅の複数のリソースユニット（ＲＵ＃１１−１、ＲＵ＃１１−２、・・・、ＲＵ＃１１−Ｌ）を配置した例を示す。図３（Ｃ）は３種類の帯域幅のリソースユニットを配置した例を示す。リソースユニット（ＲＵ＃１２−１、ＲＵ＃１２−２）が最も大きな帯域幅を有し、リソースユニットＲＵ＃１２−（Ｌ−１）は図３（Ｂ）と同じ帯域幅、リソースユニット（ＲＵ＃Ｋ−１、ＲＵ＃Ｋ）は図３（Ａ）と同じ帯域幅である。
【００１２】
具体例を示す。２０ＭＨｚチャネル幅全体を使う場合、２０ＭＨｚチャネル幅内に配置される２５６サブキャリア（トーン）に対し、リソースユニットが２６個（トーン）設定できる。つまり、２０ＭＨｚチャネル幅では９つのリソースユニットが設定され、リソースユニットの帯域幅としては２．５ＭＨｚ幅より小さくなる。４０ＭＨｚチャネル幅では、リソースユニットは１８個設定される。８０ＭＨｚチャネル幅では３７個設定される（ｄｏｃ．：ＩＥＥＥ  ８０２．１１−１５／０３３０ｒ５参照）。これを発展させると、例えば１６０ＭＨｚチャネル幅または８０＋８０ＭＨｚチャネル幅では、７４個のリソースユニットが設定される。もちろんリソースユニットの幅は特定の値に制限されず、様々なサイズのリソースユニットを配置することもできる。
【００１３】
なお、各端末が使用するリソースユニット数は、特定の値に制限されず、１つまたは複数のリソースユニットを用いてもよい。端末が複数のリソースユニットを用いる場合、周波数的に連続する複数のリソースユニットを用いてもよいし、離れた箇所にある複数のリソースユニットを用いることを許容してもよい。
【００１４】
１つのリソースユニット内のサブキャリアは周波数領域で連続しているとするが、非連続に配置された複数のサブキャリアからリソースユニットを定義してもよい。アップリンクＯＦＤＭＡ通信で使用するチャネルは１つに限定されず、チャネルＭと周波数領域で離れた位置に配置された別のチャネル（図２ではチャネルＮを参照）内にも、チャネルＭと同様にしてリソースユニットを確保し、チャネルＭとチャネルＮの両方内のリソースユニットを用いてもよい。チャネルＭとチャネルＮとでリソースユニットの配置方法は同じであっても、異なってもよい。チャネルＮの帯域幅は、一例として、上述のように、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、１６０ＭＨｚなどであるが、これらに限定されない。３つ以上のチャネルを用いることも可能である。なお、チャネルＭとチャネルＮをまとめて１つのチャネルとして考えても良い。
【００１５】
なお、ＯＦＤＭＡを実施する端末は、少なくとも後方互換の対象となるレガシー端末での基本チャネル幅（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末をレガシー端末とするなら２０ＭＨｚチャネル幅）のチャネルで、フレームを含む物理パケットを受信・復号（復調および誤り訂正符号の復号等を含む）できるものとする。キャリアセンスに関しては基本チャネル幅の単位で行うものとする。キャリアセンスは、ＣＣＡ（Ｃｌｅａｒ  Ｃｈａｎｎｅｌ  Ａｓｓｅｓｓｍｅｎｔ）のビジー／アイドルに関する物理的なキャリアセンス（Ｐｈｙｓｉｃａｌ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ）と、受信したフレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス（Ｖｉｒｔｕａｌ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ）との両方を包含してもよい。後者のように、仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）と呼ばれる。なお、チャネル単位で行ったＣＣＡまたはＮＡＶに基づくキャリアセンス情報は、チャネル内の全リソースユニットに共通に適用してもよい。例えばキャリアセンス情報がアイドルを示すチャネルに属するリソースユニットはすべてアイドルである。
【００１６】
なお、ＯＦＤＭＡは上述したリソースユニットベースのＯＦＤＭＡ以外に、チャネルベースでのＯＦＤＭＡも可能である。この場合のＯＦＤＭＡを特にＭＵ−ＭＣ（Ｍｕｌｔｉ−Ｕｓｅｒ  Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ）と呼ぶことがある。ＭＵ−ＭＣでは、基地局が複数のチャネル（１つのチャネル幅は例えば２０ＭＨｚなど）を複数の端末に割り当て、当該複数のチャネルを同時に用いて、複数端末宛て同時送信もしくは複数端末からの同時受信を行う。以降に説明するＯＦＤＭＡでは、リソースユニットベースのＯＦＤＭＡを想定するが、以降の説明のリソースユニットをチャネルに読み替えるなど、必要な読み替えを行うことで、チャネルベースのＯＦＤＭＡの実施形態も実現可能である。
【００１７】
なお、複数の端末から基地局へのアップリンク多重送信では、上述したＯＦＤＭＡ以外に、ＯＦＤＭＡとＭＵ−ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）を組み合わせた通信方式（ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯと呼ぶ）も可能である。アップリンクＭＵ−ＭＩＭＯ送信は、複数の端末から基地局に空間多重で（同一周波数帯域で同時に）ストリームを送信し、基地局が複数のアンテナでこれらストリームを同時に受信するものである。ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯの場合、複数の端末が同じリソースユニットを利用して、ＭＵ−ＭＩＭＯ送信を行うことになる。以降の説明でＯＦＤＭＡを指すときは、ＯＦＤＭＡ＆ＭＵ−ＭＩＭＯでもよいものとする。
【００１８】
以下の説明において、ＵＬ−ＯＦＤＭＡを実施する能力を有する端末をＵＬ−ＯＦＤＭＡ対応端末（あるいは単純にＯＦＤＭＡ対応端末）などと呼ぶことがある。当該能力を有さない端末をレガシー端末と呼ぶことがある。ＵＬ−ＯＦＤＭＡ通信を実施する能力を有効（Ｅｎａｂｌｅ）または無効（Ｄｉｓａｂｌｅ）に切り替え可能な場合、当該能力が有効になっている端末をＯＦＤＭＡ対応端末として考えればよい。
【００１９】
図１に示されるように、端末（非基地局の端末及び基地局）に搭載される無線通信装置は、上位処理部９０、ＭＡＣ処理部１０、ＰＨＹ（Ｐｈｙｓｉｃａｌ：物理）処理部５０、ＭＡＣ／ＰＨＹ管理部６０、アナログ処理部７０（アナログ処理部１〜Ｎ）及びアンテナ８０（アンテナ１〜Ｎ）を含む。Ｎは１以上の整数である。図では、Ｎ個のアナログ処理部と、Ｎ個のアンテナが、一対ずつ接続されているが、必ずしもこの構成に限定されるものではない。例えばアナログ処理部の個数が１つで、２つ以上のアンテナがこのアナログ処理部に共通に接続されてもよい。
【００２０】
ＭＡＣ処理部１０、ＭＡＣ／ＰＨＹ管理部６０、及びＰＨＹ処理部５０は、他の端末（基地局を含む）との通信に関する処理を行う制御部またはベースバンド集積回路の一形態に相当する。アナログ処理部７０は、例えばアンテナ８０を介して信号を送受信する無線通信部またはＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）集積回路の一形態に相当する。本実施形態に係る無線通信用集積回路は、当該ベースバンド集積回路（制御部）およびＲＦ集積回路の少なくとも前者を含む。通信処理装置またはベースバンド集積回路の機能は、ＣＰＵ等のプロセッサで動作するソフトウェア（プログラム）によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはＲＯＭ、ＲＡＭ等のメモリ、ハードディスク、ＳＳＤなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発性メモリでもよい。
【００２１】
上位処理部９０は、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：媒体アクセス制御）層に対して上位層のための処理を行う。上位処理部９０は、ＭＡＣ処理部１０との間で信号をやり取りできる。上位層としては、代表的なものとしては、ＴＣＰ／ＩＰやＵＤＰ／ＩＰ、さらにその上層のアプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部９０は、ＭＡＣ層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。上位処理部９０を介して有線インフラに接続するようになっていてもよい。バッファは、メモリでもよいし、ＳＳＤ、ハードディスク等でもよい。バッファがメモリの場合、当該メモリはＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発性メモリでもよい。
【００２２】
ＭＡＣ処理部１０は、ＭＡＣ層のための処理を行う。前述のように、ＭＡＣ処理部１０は、上位処理部９０との間で信号をやり取りできる。更に、ＭＡＣ処理部１０は、ＰＨＹ処理部５０との間で、信号をやり取りできる。ＭＡＣ処理部１０は、ＭＡＣ共通処理部２０と送信処理部３０と受信処理部４０を含む。
【００２３】
ＭＡＣ共通処理部２０は、ＭＡＣ層での送受信に共通する処理を行う。ＭＡＣ共通処理部２０は、上位処理部９０、送信処理部３０、受信処理部４０及びＭＡＣ／ＰＨＹ管理部６０と接続され、夫々との間で信号のやり取りをする。
【００２４】
送信処理部３０及び受信処理部４０は、相互に接続している。また、送信処理部３０及び受信処理部４０は、それぞれＭＡＣ共通処理部２０及びＰＨＹ処理部５０に接続している。送信処理部３０は、ＭＡＣ層での送信処理を行う。受信処理部４０は、ＭＡＣ層での受信処理を行う。
【００２５】
ＰＨＹ処理部５０は、物理層（ＰＨＹ層）のための処理を行う。前述のように、ＰＨＹ処理部５０は、ＭＡＣ処理部１０との間で信号をやり取りできる。ＰＨＹ処理部５０は、アナログ処理部７０を介してアンテナ８０に接続されている。
【００２６】
ＭＡＣ／ＰＨＹ管理部６０は、上位処理部９０、ＭＡＣ処理部１０（より詳細には、ＭＡＣ共通処理部２０）及びＰＨＹ処理部５０の夫々と接続されている。ＭＡＣ／ＰＨＹ管理部６０は、無線通信装置におけるＭＡＣ動作及びＰＨＹ動作を管理する。
【００２７】
アナログ処理部７０は、アナログ／デジタル及びデジタル／アナログ（ＡＤ／ＤＡ）変換器およびＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）回路を含み、ＰＨＹ処理部５０からのデジタル信号を所望の周波数のアナログ信号に変換してアンテナ８０から送信、またアンテナ８０から受信した高周波のアナログ信号をデジタル信号に変換する。なお、ここでは、ＡＤ／ＤＡ変換をアナログ処理部７０で行っているが、ＰＨＹ処理部５０にＡＤ／ＤＡ変換機能を持たせる構成も可能である。
【００２８】
本実施形態に係る無線通信装置は、１チップ内にアンテナ８０を構成要素として含む（一体化する）ことで、このアンテナ８０の実装面積を小さく抑えることができる。更に、本実施形態に係る無線通信装置は、図１に示されるように、送信処理部３０及び受信処理部４０が、Ｎ本のアンテナ８０を共用している。送信処理部３０及び受信処理部４０がＮ本のアンテナ８０を共用することにより、図１の無線通信装置を小型化できる。なお、本実施形態に係る無線通信装置は、図１に例示されたものと異なる構成を備えても勿論よい。
【００２９】
無線媒体からの信号受信に際して、アナログ処理部７０は、アンテナ８０が受信したアナログ信号を、ＰＨＹ処理部５０が処理可能な基底帯域（Ｂａｓｅｂａｎｄ）の信号に変換し、さらにデジタル信号に変換する。ＰＨＹ処理部５０は、アナログ処理部７０からデジタルの受信信号を受け取り、その受信レベルを検出する。検出した受信レベルを、キャリアセンスレベル（閾値）と比較し、受信レベルが、キャリアセンスレベル以上であれば、ＰＨＹ処理部５０は媒体（ＣＣＡ：Ｃｌｅａｒ  Ｃｈａｎｎｅｌ  Ａｓｓｅｓｓｍｅｎｔ）がビジーであるということを示す信号を、ＭＡＣ処理部１０（より正確には、受信処理部４０）へ出力する。受信レベルが、キャリアセンスレベル未満であれば、ＰＨＹ処理部５０は、媒体（ＣＣＡ）がアイドルであるということを示す信号を、ＭＡＣ処理部１０（より正確には受信処理部４０）へ出力する。
【００３０】
ＰＨＹ処理部５０は、受信信号に対し、復号（復調および誤り訂正符号の復号等を含む）処理、プリアンブルを含む物理ヘッダ（ＰＨＹヘッダ）を取り除く処理などを行って、ペイロードを抽出する。ＩＥＥＥ８０２．１１規格ではこのペイロードをＰＨＹ側ではＰＳＤＵ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｃｏｎｖｅｒｇｅｎｃｅ  ｐｒｏｃｅｄｕｒｅ
（ＰＬＣＰ）  ｓｅｒｖｉｃｅ  ｄａｔａ  ｕｎｉｔ）と呼んでいる。ＰＨＹ処理部５０は、抽出したペイロードを受信処理部４０に渡し、受信処理部４０はこれをＭＡＣフレームとして扱う。ＩＥＥＥ８０２．１１規格では、このＭＡＣフレームを、ＭＰＤＵ（ｍｅｄｉｕｍ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ  （ＭＡＣ）  ｐｒｏｔｏｃｏｌ  ｄａｔａ
ｕｎｉｔ）と呼んでいる。加えて、ＰＨＹ処理部５０は、受信信号を受信開始した際に、その旨を受信処理部４０に通知し、また受信信号を受信終了した際に、その旨を受信処理部４０に通知する。また、ＰＨＹ処理部５０は、受信信号が正常に物理パケット（ＰＨＹパケット）として復号できた場合（エラーを検出しなければ）、受信信号の受信終了を通知すると共に、媒体がアイドルであるということを示す信号を、受信処理部４０に渡す。ＰＨＹ処理部５０は、受信信号にエラーを検出した場合には、エラー種別に即した適切なエラーコードをもって、受信処理部４０にエラーを検出したことを通知する。また、ＰＨＹ処理部５０は、媒体がアイドルになったと判定した時点で、媒体がアイドルであることを示す信号を受信処理部４０に通知する。
【００３１】
ＭＡＣ共通処理部２０は、上位処理部９０から送信処理部３０への送信データの受け渡し、及び受信処理部４０から上位処理部９０への受信データの受け渡しを、夫々仲介する。ＩＥＥＥ８０２．１１規格では、このＭＡＣデータフレームの中のデータを、ＭＳＤＵ（ｍｅｄｉｕｍ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ  （ＭＡＣ）  ｓｅｒｖｉｃｅ  ｄａｔａ  ｕｎｉｔ）と呼んでいる。また、ＭＡＣ共通処理部２０は、ＭＡＣ／ＰＨＹ管理部６０からの指示を一旦受け取り、当該指示を送信処理部３０及び受信処理部４０に、それぞれ適したものに変換して出力する。
【００３２】
ＭＡＣ／ＰＨＹ管理部６０は、例えばＩＥＥＥ８０２．１１規格におけるＳＭＥ（Ｓｔａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）に相当する。その場合、ＭＡＣ／ＰＨＹ管理部６０とＭＡＣ共通処理部２０との間のインタフェースは、ＩＥＥＥ８０２．１１規格におけるＭＬＭＥ  ＳＡＰ（ＭＡＣ  ｓｕｂＬａｙｅｒ  Ｍａｎａｇａｍｅｎｔ  Ｅｎｔｉｔｙ  Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）に相当し、ＭＡＣ／ＰＨＹ管理部６０とＰＨＹ処理部５０との間のインタフェースは、ＩＥＥＥ８０２．１１無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）におけるＰＬＭＥ  ＳＡＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ  Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）に相当する。
【００３３】
なお、図１において、ＭＡＣ／ＰＨＹ管理部６０は、ＭＡＣ管理のための機能部とＰＨＹ管理のための機能部とが一体であるかのように描かれているが、分けて実装されてもよい。
【００３４】
ＭＡＣ／ＰＨＹ管理部６０は、管理情報ベース（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ：ＭＩＢ）を保持する。ＭＩＢは、自端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、自端末が、ＵＬ−ＯＦＤＭＡ対応か否か、また、ＵＬ−ＯＦＤＭＡ対応の場合にＵＬ−ＯＦＤＭＡを実施する能力の機能のオン／オフの情報も保持されていてもよい。ＭＩＢを保持・管理するためのメモリは、ＭＡＣ／ＰＨＹ管理部６０に内包させてもよいし、ＭＡＣ／ＰＨＹ管理部６０に内包せずに別に設けるようにしてもよい。ＭＩＢを保持・管理するためのメモリをＭＡＣ／ＰＨＹ管理部６０とは別に設ける場合に、ＭＡＣ／ＰＨＹ管理部６０は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。メモリはＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでも、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。また、メモリでなく、ＳＳＤやハードディスク等の記憶装置でもよい。基地局では、非基地局としての他の端末のこれらの情報も、当該端末からの通知により、取得することができる。その場合、ＭＡＣ／ＰＨＹ管理部６０は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、ＭＩＢとは別に保持・管理するようにしてもよい。その場合、ＭＡＣ／ＰＨＹ管理部６０あるいはＭＡＣ共通処理部２０が、その別のメモリを参照・書き換えが可能なようにする。また基地局のＭＡＣ／ＰＨＹ管理部６０は、ＵＬ−ＯＦＤＭＡの実施にあたり、非基地局としての端末に関する各種の情報、または端末からの要求に基づき、ＵＬ−ＯＦＤＭＡ用のリソースユニットを同時に割り当てる端末を選定する（すなわち今回のＵＬ−ＯＦＤＭＡの対象となる端末を選定する）選定機能も備えていてもよい。また、ＭＡＣ／ＰＨＹ管理部６０またはＭＡＣ処理部１０は、送信するＭＡＣフレームおよび物理ヘッダに適用する伝送レートを管理してもよい。また基地局のＭＡＣ／ＰＨＹ管理部６０は、基地局がサポートするレートセットであるサポートレートセットを定義および管理してもよい。サポートレートセットは、基地局に接続する端末がサポートすることが必須であるレートと、オプションのレートを含んでもよい。
【００３５】
ＭＡＣ処理部１０は、データフレーム、制御フレーム及び管理フレームの３種類のＭＡＣフレームを扱い、ＭＡＣ層において規定される各種処理を行う。ここで、３種類のＭＡＣフレームについて説明する。
【００３６】
管理フレームは、他の端末との間の通信リンクの管理のために用いられる。管理フレームとしては、例えば、ＩＥＥＥ８０２．１１規格におけるＢａｓｉｃ  Ｓｅｒｖｉｃｅ  Ｓｅｔ（ＢＳＳ）である無線通信グループを形成するために、グループの属性及び同期情報を報知するビーコン（Ｂｅａｃｏｎ）フレームがある。また、認証のためにまたは通信リンク確立のために交換されるフレームなどもある。なお、ある端末が、もう一台の端末と互いに無線通信を実施するために必要な情報交換を済ませた状態を、通信リンクが確立していると、ここでは表現する。必要な情報交換として、例えば、自端末が対応する機能（例えばＵＬ−ＯＦＤＭＡ方式への対応や後述する各種能力など）の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部３０が、ＭＡＣ／ＰＨＹ管理部６０からＭＡＣ共通処理部２０を介して受けた指示に基づいて生成する。
【００３７】
管理フレームに関連して、送信処理部３０は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。非基地局としての端末の通知手段は、ＵＬ−ＯＦＤＭＡ対応端末、ＩＥＥＥ８０２．１１ｎ対応端末、ＩＥＥＥ８０２．１１ａｃ対応端末のいずれに対応しているかの情報を、管理フレームに入れて送信することで、基地局に自端末の種別を通知してもよい。この管理フレームとしては、例えば端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるＡｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔフレームや、あるいはリアエソシエーションプロセスで用いられるＲｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔフレームがある。基地局の通知手段は、非基地局の端末に、ＵＬ−ＯＦＤＭＡ通信への対応可否の情報を、管理フレームを介して通知してもよい。これに用いる管理フレームとしては、例えばＢｅａｃｏｎフレームや、非基地局端末が送信したＰｒｏｂｅ  Ｒｅｑｕｅｓｔフレームに対する応答であるＰｒｏｂｅ  Ｒｅｓｐｏｎｓｅフレームがある。基地局は、自装置に接続している端末群をグループ化する機能を有していてもよい。基地局の上記の通知手段は、各端末にそれぞれが属するグループのグループ識別子であるグループＩＤを、管理フレームを介して通知してもよい。この管理フレームとしては、例えばＧｒｏｕｐ  ＩＤ  Ｍａｎａｇｅｍｅｎｔフレームがある。グループＩＤは、例えばＩＥＥＥ  Ｓｔｄ  ８０２．１１ａｃ−２０１３でＤＬ−ＭＵ−ＭＩＭＯのために規定されたグループＩＤ（６ビット）をＵＬ−ＯＦＤＭＡの場合も包含するように拡張したものでもよいし、これとは別の方法で定義したグループＩＤでもよい。また、基地局は、当該グループを指定してＵＬ−ＯＦＤＭＡをする場合に、当該グループに属する端末が使用するリソースユニットを決定するために必要な情報が存在すれば、任意の管理フレームを介して通知してもよい（後述するようにグループを指定する場合、端末はランダムバックオフ手法に類似した方法に基づきリソースユニットを選択する機能を備える）。
【００３８】
ここでアソシエーションＩＤ（ＡＩＤ）について説明する。ＡＩＤは、端末が基地局に接続し、基地局下のＢＳＳでデータフレーム交換が行えるようにするためのアソシエーションプロセスで、基地局から割り当てられる端末の識別子（端末識別子）である。アソシエーションプロセスは具体的には、端末から基地局宛てにＡｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔフレームを送信し、基地局から端末宛てにＡｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームを送信し、Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームの中の端末Ｓｔａｔｕｓ  Ｃｏｄｅフィールドが”０”すなわちｓｕｃｃｅｓｓである場合に成功するプロセスである。Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔフレーム、Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームの双方には、送信端末の通信能力（Ｃａｐａｂｉｌｉｔｙ）が入れられており、それにより、受信した双方が相手の通信能力を把握する。Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームの中の端末Ｓｔａｔｕｓ  Ｃｏｄｅフィールドが”０”すなわちｓｕｃｃｅｓｓである場合には、同フレーム中のＡＩＤフィールド（１６ビット）からＡＩＤを抽出し、送信先端末のＡＩＤとして使われることになる。すなわち、この時点で、基地局から端末にＡＩＤが割り当てられたことになり、端末としてはＡＩＤが有効の状態となる。当該基地局が端末との間で接続（Ａｓｓｏｃｉａｔｉｏｎ）している状態では、端末のＡＩＤが有効である。一方、基地局から当該端末にＤｉｓａｓｓｏｃｉａｔｉｏｎフレームを送信し、当該端末が受信すると、あるいは当該端末から基地局にＤｉｓａｓｓｏｃｉａｔｉｏｎフレームを送信すると、当該端末のＡＩＤは無効（ｎｕｌｌ）となる。どの基地局ともアソシエーションプロセスを経ていない状態の端末でも当然、ＡＩＤは無効である。ＡＩＤが無効の状態は、ＡＩＤが未指定の状態とも言うこともできる。
【００３９】
受信処理部４０は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、基地局の受信手段は、非基地局としての端末からＵＬ−ＯＦＤＭＡ通信への対応可否の情報を受信してもよい。また、当該端末がレガシー端末（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末など）の場合に対応可能なチャネル幅（利用可能な最大のチャネル幅）の情報を受信してもよい。端末の受信手段は、基地局からＵＬ−ＯＦＤＭＡサポートの対応可否の情報を受信してもよい。
【００４０】
上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末（基地局を含む）間で送受信することが可能である。例えばＵＬ−ＯＦＤＭＡ対応端末は、自身がＵＬ−ＯＦＤＭＡ送信で使用することを希望するリソースユニット、または、チャネル、またはこれらの両方を、キャリアセンスで非干渉のチャネル、または、非干渉のリソースユニット、またはこれらの両方から、選択してもよい。そして、選択したリソースユニットまたはチャネルまたはこれらの両方に関する情報を、基地局に通知してもよい。この場合、基地局は当該情報に基づき、ＵＬ−ＯＦＤＭＡ通信のためのリソースユニット割り当てを各ＵＬ−ＯＦＤＭＡ対応端末に対して行ってもよい。なお、ＵＬ−ＯＦＤＭＡ通信で利用するチャネルは、無線通信システムとして利用可能な全てのチャネルであっても、一部（１つまたは複数）のチャネルであってもよい。
【００４１】
データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、当該データがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部９０からＭＡＣ共通処理部２０を介して送信処理部３０に渡され、送信処理部３０でデータをフレームボディフィールドに入れ、当該フレームボディフィールドにＭＡＣヘッダを付加してデータフレームが生成される。そして、ＰＨＹ処理部５０で、データフレームに物理ヘッダを付加して物理パケットが生成され、物理パケットが、アナログ処理部７０及びアンテナ８０を介して送信される。また、ＰＨＹ処理部５０で物理パケットを受信すると、物理ヘッダに基づき物理層の処理を行ってＭＡＣフレーム（ここではデータフレーム）を抽出し、データフレームを受信処理部４０に渡す。受信処理部４０は、データフレームを受けると（受信したＭＡＣフレームがデータフレームであると把握すると）、そのフレームボディフィールドの情報をデータとして抽出し、抽出したデータを、ＭＡＣ共通処理部２０を介して上位処理部９０に渡す。この結果、データの書き込み、再生などのアプリケーション上の動作が生じる。
【００４２】
制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信（交換）するときの制御のために用いられる。制御フレームとしては、例えば、管理フレーム及びデータフレームの交換を開始する前に、無線媒体を予約するために他の無線通信装置との間で交換するＲＴＳ（Ｒｅｑｕｅｓｔ  ｔｏ  Ｓｅｎｄ）フレーム、ＣＴＳ（Ｃｌｅａｒ  ｔｏ  Ｓｅｎｄ）フレームなどがある。また、他の制御フレームとして、受信した管理フレーム及びデータフレームの送達確認のための送達確認応答フレームがある。送達確認応答フレームの例として、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレーム、ＢＡ（ＢｌｏｃｋＡＣＫ）フレームなどがある。ＣＴＳフレームも、ＲＴＳフレームの応答として送信するため、送達確認応答を表すフレームであるとも言える。ＣＦ−Ｅｎｄフレームも、制御フレームの１つである。ＣＦ−Ｅｎｄフレームは、ＣＦＰ（Ｃｏｎｔｅｎｔｉｏｎ  Ｆｒｅｅ  Ｐｅｒｉｏｄ）の終了あるいは後述のＴＸＯＰの打切りをアナウンスするフレーム、つまり、無線媒体へのアクセスを許可するフレームである。これらの制御フレームは送信処理部３０で生成される。受信したＭＡＣフレームへの応答として送信される制御フレーム（ＣＴＳフレームやＡＣＫフレーム、ＢＡフレームなど）に関しては、受信処理部４０で応答フレーム（制御フレーム）の送信の必要を判断して、フレーム生成に必要な情報（制御フレームの種別、ＲＡ（Ｒｅｃｅｉｖｅｒ  Ａｄｄｒｅｓｓ）フィールド等に設定する情報など）を送信指示とともに送信処理部３０に出す。送信処理部３０は、当該フレーム生成に必要な情報と送信指示に基づき、適切な制御フレームを生成する。
【００４３】
ＭＡＣ処理部１０は、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃａｒｒｉｅｒ  Ａｖｏｉｄａｎｃｅ）に基づきＭＡＣフレームを送信する場合、無線媒体上でのアクセス権（送信権）を獲得する必要がある。送信処理部３０は、受信処理部４０からのキャリアセンス情報に基づいて、送信タイミングを計る。送信処理部３０は、係る送信タイミングに従って、ＰＨＹ処理部５０に送信指示を与えて、さらにＭＡＣフレームを渡す。送信指示に加えて、送信処理部３０は、送信に使用される変調方式及び符号化方式を合わせて指示してもよい。これらに加えて、送信処理部３０は、送信電力を指示してもよい。ＭＡＣ処理部１０は、アクセス権（送信権）獲得後、媒体を占有可能な時間（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｏｐｐｏｒｔｕｎｉｔｙ；ＴＸＯＰ）が得られると、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）属性などの制限を伴うものの、他の無線通信装置との間でＭＡＣフレームを連続して交換できる。ＴＸＯＰは、例えば、無線通信装置がＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃａｒｒｉｅｒ  Ａｖｏｉｄａｎｃｅ）に基づき所定のフレーム（例えばＲＴＳフレーム）を送信し、他の無線通信装置から応答フレーム（例えばＣＴＳフレーム）を正しく受信した場合に、獲得される。この所定のフレームが、当該他の無線通信装置によって受信されると、当該他の無線通信装置は、最小フレーム間隔（Ｓｈｏｒｔ  ＩｎｔｅｒＦｒａｍｅ  Ｓｐａｃｅ；ＳＩＦＳ）後に、上記応答フレームを送信する。また、ＲＴＳフレームを用いないでＴＸＯＰを獲得する方法として、例えば直接ユニキャストで、送達確認応答フレームの送信を要求するデータフレーム（後述のようにフレームが連接された形状のフレーム、またはペイロードが連接された形状のフレームであってもよい）あるいは管理フレームを送信し、それに対する送達確認応答フレーム（ＡＣＫフレームやＢｌｏｃｋＡＣＫフレーム）を正しく受信する場合がある。あるいは、他の無線通信装置に送達確認応答フレームの送信を要求しないフレームであって、そのフレームのＤｕｒａｔｉｏｎ／ＩＤフィールドに当該フレームの送信に要する時間以上の期間を設定したものを送信した場合には、当該フレームを送信した段階からＤｕｒａｔｉｏｎ／ＩＤフィールドに記載された期間のＴＸＯＰを獲得したと解釈してもよい。
【００４４】
受信処理部４０は、上述したキャリアセンス情報を管理する。このキャリアセンス情報は、ＰＨＹ処理部５０から入力される媒体（ＣＣＡ）のビジー／アイドルに関する物理的なキャリアセンス（Ｐｈｙｓｉｃａｌ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ）情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス（Ｖｉｒｔｕａｌ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ）情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、ＩＥＥＥ８０２．１１規格において、媒体予約時間は、ＭＡＣヘッダの中のＤｕｒａｔｉｏｎ／ＩＤフィールドに記載される。ＭＡＣ処理部１０は、他の無線通信装置宛ての（自己宛てでない）ＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、ＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）と呼ばれる。媒体予約時間は無線媒体へのアクセスの抑制を指示する期間の長さ、すなわち無線媒体へのアクセスを延期させる期間の長さを表しているといえる。
【００４５】
ここで、ＭＰＤＵは、複数のＭＡＣフレームもしくは複数のＭＡＣフレームのペイロード部分を連接するようになっていてもよい。前者はＩＥＥＥ８０２．１１規格ではＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＰＤＵ、後者はＡ（Ａｇｇｒｅｇａｔｅｄ）−ＭＳＤＵ（ＭＡＣ  ｓｅｒｖｉｃｅ  ｄａｔａ  ｕｎｉｔ）と呼ばれる。Ａ−ＭＰＤＵの場合は、ＰＳＤＵの中に複数のＭＰＤＵが連接されることになる。またＭＡＣフレームとしてはデータフレームのみならず、管理フレームや制御フレームも連接対象となる。Ａ−ＭＳＤＵの場合には、１つのＭＰＤＵのフレームボディ中に、複数のデータペイロードであるＭＳＤＵが連接されることになる。Ａ−ＭＰＤＵ、およびＡ−ＭＳＤＵのいずれも、複数のＭＰＤＵの連接、および複数のＭＳＤＵの連接を、受信側端末で適切に分離できるように、フレームに区切り情報（長さ情報など）が格納されている。Ａ−ＭＰＤＵおよびＡ−ＭＳＤＵの両方を組み合わせて用いてもよい。またＡ−ＭＰＤＵは、複数のＭＡＣフレームではなく、１つのＭＡＣフレームのみを対象としてもよく、この場合も区切り情報をフレームに格納する。また、Ａ−ＭＰＤＵなどを受信した場合は、連接されている複数のＭＡＣフレームに対する応答をまとめて送信する。この場合の応答には、ＡＣＫフレームではなく、ＢＡ（ＢｌｏｃｋＡＣＫ）フレームが用いられる。以降の説明および図では、ＭＰＤＵの表記を用いることがあるが、これは、上述したＡ−ＭＰＤＵまたはＡ−ＭＳＤＵの場合も含むものとする。
【００４６】
ＩＥＥＥ８０２．１１規格では、基地局が中心となり構成するＢＳＳ（これをインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）ＢＳＳと呼ぶ）に、非基地局の端末が加入し、ＢＳＳ内でデータフレームの交換ができるようになるために経る手順（ｐｒｏｃｅｄｕｒｅ）が、段階的に複数規定されている。例えば、アソシエーション（ａｓｓｏｃｉａｔｉｏｎ）という手順があり、非基地局の端末から、当該端末が接続を要求する基地局に対して、アソシエーション要求（Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔ）フレームを送信する。基地局は、アソシエーション要求フレームに対するＡＣＫフレームを送信後、アソシエーション要求フレームに対する応答であるアソシエーション応答（Ａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅ）フレームを送信する。
【００４７】
端末はアソシエーション要求フレームに自端末の能力（ｃａｐａｂｉｌｉｔｙ）を格納し、それを送信することで基地局に自端末の能力の通知をすることができる。例えば、端末はアソシエーション要求フレームの中に、自端末が対応可能なチャネルまたはリソースユニットまたはこれらの両方や、自端末が対応する規格を特定するための情報を入れて送信してもよい。他の基地局へ再接続するための再アソシエーション（ｒｅａｓｓｏｃｉａｔｉｏｎ）という手順で送信するフレームにも、この情報を設定するようにしてもよい。
この再アソシエーションの手順では、端末から、再接続を要求する他の基地局に対して、再アソシエーション要求（Ｒｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｑｕｅｓｔ）フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するＡＣＫフレームを送信後、再アソシエーション要求フレームに対する応答である再アソシエーション応答（Ｒｅａｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅ）フレームを送信する。
【００４８】
管理フレームとして、アソシエーション要求フレームおよび再アソシエーション要求フレーム以外にも、ビーコンフレーム、プローブ応答（Ｐｒｏｂｅ  Ｒｅｓｐｏｎｓｅ）フレームなどを用いてもよい。ビーコンフレームは基本的に基地局が送信するもので、ＢＳＳの属性を示すパラメータとともに、基地局自身の能力を通知するパラメータも格納できる。そこで、この基地局自身の能力を通知するパラメータとして、基地局がＵＬ−ＯＦＤＭＡへの対応可否の情報を加えるようにしてもよい。また他のパラメータとして、基地局のサポートレート（Ｓｕｐｐｏｒｔｅｄ  Ｒａｔｅ）の情報を通知してもよい。サポートレートは、基地局が形成するＢＳＳに参加する端末が対応必須のレートと、オプションのレートとを含んでもよい。プローブ応答フレームは、ビーコンフレームを送信する端末からプローブ要求（Ｐｒｏｂｅ  Ｒｅｑｕｅｓｔ）フレームを受信すると、それに応答して送信するフレームである。プローブ応答フレームは、基本的にはビーコンフレームと同一の内容を通知するものであるため、プローブ応答フレームを用いても基地局は、プローブ要求フレームを送信した端末に、自局の能力を通知することができる。ＵＬ−ＯＦＤＭＡ対応端末にこの通知を行うことで、端末が例えば自端末のＵＬ−ＯＦＤＭＡ通信の機能を有効にするといった動作を行ってもよい。
【００４９】
なお、端末は自端末の能力について基地局へ通知する情報として、基地局のサポートレートのうち自端末が実行可能なレートの情報を通知してもよい。ただし、サポートレートのうち必須のレートについては、基地局へ接続する端末はその必須のレートを実行する能力を有するものとする。
【００５０】
なお、上記で扱った情報のうち、ある情報を通知することで、別の情報の内容が決まるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとＵＬ−ＯＦＤＭＡ対応端末である、という場合を考える。この場合、上記ある情報として、規格あるいは仕様に対応する能力の有を通知し、上記別の情報として、ＯＦＤＭＡ対応端末であることの通知を明示的に行わなくてもよい。
【００５１】
図４に、本実施形態に従った無線通信システムを示す。このシステムは、基地局（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）１００と、複数の端末（ＳＴＡ：ＳＴＡｔｉｏｎ）１〜８とを備える。基地局１００と、配下の端末１〜８により、ＢＳＳ（Ｂａｓｉｃ  Ｓｅｒｖｉｃｅ  Ｓｅｔ）１が形成される。このシステムは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃａｒｒｉｅｒ  Ａｖｏｉｄａｎｃｅ）を用いるＩＥＥＥ８０２．１１規格に準じた無線ＬＡＮシステムである。なお、ＢＳＳ１内に本実施形態に係る端末（ＵＬ−ＯＦＤＭＡ端末）以外のレガシー端末（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ規格対応端末など）が存在していてもかまわない。
【００５２】
図５（Ａ）は、ＭＡＣフレームの基本的なフォーマット例を示す。本実施形態に係るデータフレーム、管理フレームおよび制御フレームは、このようなフレームフォーマットをベースとする。本フレームフォーマットは、ＭＡＣヘッダ（ＭＡＣ  ｈｅａｄｅｒ）、フレームボディ（Ｆｒａｍｅ  ｂｏｄｙ）及びＦＣＳの各フィールドを含む。ＭＡＣヘッダは、図５（Ｂ）に示すように、Ｆｒａｍｅ  Ｃｏｎｔｒｏｌ、Ｄｕｒａｔｉｏｎ／ＩＤ、Ａｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２、Ａｄｄｒｅｓｓ３，  Ｓｅｑｕｅｎｃｅ  Ｃｏｎｔｒｏｌ、ＱｏＳ  Ｃｏｎｔｒｏｌ及び  ＨＴ（Ｈｉｇｈ  Ｔｈｒｏｕｇｈｐｕｔ）  ｃｏｎｔｒｏｌの各フィールドを含む。
【００５３】
これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しない場合もあり得る。例えばＡｄｄｒｅｓｓ３フィールドが存在しない場合もある。また、ＱｏＳ  ＣｏｎｔｒｏｌおよびＨＴ  Ｃｏｎｔｒｏｌフィールドの両方または一方が存在しない場合もある。またフレームボディフィールドが存在しない場合もあり得る。また図５には示されていない他のフィールドが存在してもよい。例えば、Ａｄｄｒｅｓｓ４フィールドがさらに存在してもよい。また後述するＲＵ／ＡＩＤフィールドが、ＭＡＣヘッダまたはフレームボディフィールドに存在してもよい。
【００５４】
Ａｄｄｒｅｓｓ１のフィールドには、受信先アドレス（Ｒｅｃｅｉｖｅｒ  Ａｄｄｒｅｓｓ；ＲＡ）が、Ａｄｄｒｅｓｓ２のフィールドには送信元アドレス（Ｔｒａｎｓｍｉｔｔｅｒ  Ａｄｄｒｅｓｓ；ＴＡ）が入り、Ａｄｄｒｅｓｓ  ３のフィールドにはフレームの用途に応じてＢＳＳの識別子であるＢＳＳＩＤ（Ｂａｓｉｃ  Ｓｅｒｖｉｃｅ  Ｓｅｔ
ＩＤｅｎｔｉｆｉｅｒ）（全てのビットに１を入れて全てのＢＳＳＩＤを対象とするｗｉｌｄｃａｒｄ  ＢＳＳＩＤ場合もある）か、あるいはＴＡが入る。ただし、後述するように、本実施形態では、Ａｄｄｒｅｓｓ１およびＡｄｄｒｅｓｓ２フィールドをここで述べたのとは別の方法で使用することを特徴の１つとしている。
【００５５】
Ｆｒａｍｅ  Ｃｏｎｔｒｏｌフィールドには、前述したようにタイプ（Ｔｙｐｅ）、サブタイプ（Ｓｕｂｔｙｐｅ）という２つのフィールド等を設定する。データフレームか、管理フレームか、制御フレームかの大別はＴｙｐｅフィールドで行われ、大別されたフレームの中での細かい種別、例えば制御フレームの中のＢＡフレームかＢＡＲフレーム、また管理フレームの中のＢｅａｃｏｎフレームといった識別はＳｕｂｔｙｐｅフィールドで行われる。後述するトリガーフレームも、タイプおよびサブタイプの組み合わせで区別してもよい。トリガーフレームは制御フレームの一種であることが有望である。
【００５６】
Ｄｕｒａｔｉｏｎ／ＩＤフィールドは媒体予約時間を記載し、他の端末宛てのＭＡＣフレームを受信した場合に、当該ＭＡＣフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、前述したように、ＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）と呼ばれる。ＱｏＳフィールドは、フレームの優先度を考慮して送信を行うＱｏＳ制御を行うために用いられる。
【００５７】
管理フレームでは、固有のＥｌｅｍｅｎｔ  ＩＤ（ＩＤｅｎｔｉｆｉｅｒ）が割り当てられた情報エレメント（Ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ；ＩＥ）をＦｒａｍｅ
Ｂｏｄｙフィールドに設定する。フレームボディフィールドには、１つまたは複数の情報エレメントを設定できる。情報エレメントは、図６に示すように、Ｅｌｅｍｅｎｔ  ＩＤフィールド、Ｌｅｎｇｔｈフィールド、情報（Ｉｎｆｏｒｍａｔｉｏｎ）フィールドの各フィールドを有する。情報エレメントは、Ｅｌｅｍｅｎｔ  ＩＤで識別される。情報フィールドは、通知する情報の内容を格納し、Ｌｅｎｇｔｈフィールドは、情報フィールドの長さ情報を格納する。
【００５８】
ＦＣＳフィールドには、受信側でフレームの誤り検出のため用いられるチェックサム符号としてＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）情報が設定される。ＦＣＳ情報の例としては、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｏｄｅ）などがある。
【００５９】
図７に、本実施形態に係る基地局（ＡＰ）１０１と、端末（ＳＴＡ）１〜端末（ＳＴＡ）８を含む複数の端末との動作シーケンス例を示す。端末１〜８はＵＬ−ＯＦＤＭＡ対応端末である。
【００６０】
本動作シーケンス例では、前提として、基地局と端末１〜８の一部または全部との間でＣＳＭＡ／ＣＡベースで個別に通信（シングルユーザ通信）が行われている。シングルユーザ通信では、例えば基本チャネル幅（例えば２０ＭＨｚ）の１チャネルで基地局および端末間で通信が行われている。シングルユーザ通信の例として、端末でアップリンク送信用のデータが保持されている場合、ＣＳＭＡ／ＣＡに従って、無線媒体へのアクセス権を獲得する。このため、端末はＤＩＦＳ／ＡＩＦＳ[ＡＣ]と、ランダムに決定したバックオフ時間とのキャリアセンス時間（待機時間）の間、キャリアセンスを行い、媒体（ＣＣＡ）がアイドルと判断されると、例えば１フレームを送信するアクセス権を獲得する。端末は、送信するデータを含むデータフレーム（より詳細にはデータフレームを含む物理パケット）を送信し、基地局がこのデータフレームを正常に受信すると、データフレームの受信完了からＳＩＦＳ時間後に、送達確認応答フレームであるＡＣＫフレーム（より詳細にはＡＣＫフレームを含む物理パケット）を返す。端末はＡＣＫフレームを受信することで、データフレームの送信が成功したと判断する。なお、基地局に送信するデータフレームはアグリゲーションフレーム（Ａ-ＭＰＤＵ等）でもよく、基地局が応答する送達確認応答フレームはＢＡフレームでもよい（以下同様）。なお、ＤＩＦＳ／ＡＩＦＳ［ＡＣ］時間は、ＤＩＦＳおよびＡＩＦＳ［ＡＣ］のいずれか一方の時間を意味する。ＱｏＳ対応でない場合はＤＩＦＳ時間を指し、ＱｏＳ対応の場合は、送信するデータのアクセスカテゴリ（ＡＣ：Ａｃｃｅｓｓ  Ｃａｔｅｇｏｒｙ）（後述）に応じて決まるＡＩＦＳ［ＡＣ］時間を指す。
【００６１】
基地局が、任意のタイミングでＵＬ−ＯＦＤＭＡの開始を決定する。本例ではＵＬ−ＯＦＤＭＡ送信をシングルユーザ通信と同じチャネル（基本チャネル幅２０ＭＨｚの１チャネル）で行う場合を想定する。つまり、基本チャネル幅２０ＭＨｚのチャネル内に定義された複数のリソースユニットを用いてＵＬ−ＯＦＤＭＡ送信を行う場合を想定する。ただし、４０ＭＨｚ、８０ＭＨｚなど、他のチャネル幅でＵＬ−ＯＦＤＭＡ送信を行うことも可能である。
【００６２】
基地局が、ＵＬ−ＯＦＤＭＡ送信の開始を決定すると、ＵＬ−ＯＦＤＭＡ送信のトリガーフレーム（より詳細にはトリガーフレームを含む物理パケット）５０１を送信する。トリガーフレーム５０１は、シングルユーザ通信と同じチャネルの基本チャネル幅のチャネルで送信する。トリガーフレームを含む物理パケットは、一例として、トリガーフレームの先頭に物理ヘッダを付加したものである。物理ヘッダは、一例として、図８に示すように、ＩＥＥＥ８０２．１１規格で定義されているＬ−ＳＴＦ（Ｌｅｇａｃｙ−Ｓｈｏｒｔ
Ｔｒａｉｎｉｎｇ  Ｆｉｅｌｄ）、Ｌ−ＬＴＦ（Ｌｅｇａｃｙ−Ｌｏｎｇ  ＴｒａｉｎｉｎｇＦｉｅｌｄ）、Ｌ−ＳＩＧ（Ｌｅｇａｃｙ  Ｓｉｇｎａｌ  Ｆｉｅｌｄ）、を含む。Ｌ−ＳＴＦ、Ｌ−ＬＴＦ、Ｌ−ＳＩＧは、例えば、ＩＥＥＥ８０２．１１ａなどのレガシー規格の端末が認識可能なフィールドであり、それぞれ信号検出、周波数補正（伝搬路推定）、伝送速度（伝送レート）などの情報が格納される。ここで述べた以外のフィールド（例えばレガシー規格の端末が認識できず、ＵＬ−ＯＦＤＭＡ対応端末が認識できるフィールド）が含まれてもよい。
【００６３】
トリガーフレーム５０１は、ＵＬ−ＯＦＤＭＡ対応端末の他、レガシー端末も受信および復号可能なフレームでよい。なお、基地局がトリガーフレームを送信するにあたり、事前にＣＳＭＡ／ＣＡに従ってアクセス権を獲得しているものとする。アクセス権の獲得は前述した端末の場合と同様である。トリガーフレーム５０１のフレームフォーマットおよびその使用方法（解釈ルール）は、本実施形態では複数存在し、そのいずれかによってトリガーフレーム５０１を受信した際の端末の動作も異なる。本シーケンスの説明では代表的な動作の一例を説明し、バリエーションとしての動作は後述する。ここではトリガーフレーム５０１には一例として、ＵＬ−ＯＦＤＭＡ送信で使用可能な複数のリソースユニットを特定する情報と、ＵＬ−ＯＦＤＭＡ送信の候補となる複数の端末を特定する情報が含まれているとする。上記リソースユニットを特定する情報は、例えばチャネル内に定義された複数のリソースユニットの全部または一部を特定する。上記候補となる複数の端末を特定する情報は、例えば少なくとも１つのグループＩＤ、または複数の端末の各々の識別子（ＡＩＤまたはＭＡＣアドレスなど）を含む。ここで述べた以外の例も可能である。
【００６４】
基地局から送信されたトリガーフレーム５０１は端末１〜８で受信される。端末１〜８は、トリガーフレーム５０１を復号し、自端末がトリガーフレーム５０１で指定されたグループＩＤのグループに属しているかを判断する。なお、端末は、アソシエーションプロセス時またはその後の任意のタイミングで基地局から自端末が属するグループのグループＩＤの通知を受けている。自端末以外の端末とグループとの対応の通知も受けていてもよい。自端末がトリガーフレームで指定されたグループＩＤに属しており、かつ、アップリンク送信用のデータを保持している場合、トリガーフレーム５０１で指定された複数のリソースユニットから、自端末が使用するリソースユニットをランダムバックオフ手法に類似した方法に基づき選択する。アップリンク送信用のデータを保持していない端末は、選択する必要はないが、あえて選択する構成も可能である。選択する個数は事前に定められていていてもよいし、トリガーフレーム５０１で指定されてもよいし、その他の方法で把握してもよい。ここでは、上記のグループに属している各端末は、最大１つのリソースユニットが選択可能とする場合を想定する。
【００６５】
ここで、トリガーフレーム５０１ではリソースユニットを特定する情報として、ｎ個のリソースユニット１〜ｎが指定されていたとする。リソースユニット１〜ｎは、ＵＬ−ＯＦＤＭＡで使用するチャネル内で定義された全リソースユニットでもよいし、一部のリソースユニットでもよい。リソースユニット１〜ｎは、例えば各々の識別子または番号であるＲＵ＃１〜ＲＵ＃ｎによって識別されてもよい。複数のリソースユニットの集合を識別する識別子を別途定義し、当該集合の識別子を１つまたは複数、トリガーフレーム５０１で指定する構成も考えられる。この場合、端末は、当該集合の識別子から利用可能なリソースユニットを把握する。
【００６６】
本例では、端末１〜８のうち端末１、３、４、６が共通に属するグループが指定され、端末２、５、７、８の少なくとも１つが属するグループは指定されていなかったとする。
一例として、端末１、３、４、６を含むグループと、端末２、５、７、８を含むグループが基地局で定義されており、前者のグループのグループＩＤのみが指定されていたとする。そして、端末１、３、４、６がそれぞれ、アップリンク用のデータを保持しており、これら全ての端末がリソースユニットの選択権を獲得し、リソースユニット１〜ｎからランダムに、リソースユニット２、４、６、７を選択したとする。端末１、３、４、６は、トリガーフレーム５０７の受信完了から一定時間Ｔ１後に、アップリンク送信用のデータを含むデータフレーム５１１、５１３、５１４、５１６（より詳細には当該データフレームを含む物理パケット）を、基地局に送信する。データフレーム５１１、５１３、５１４、５１６の送信は、端末１〜４がそれぞれ選択したリソースユニット２、４、６、７を用いて行う。
【００６７】
一定時間Ｔ１は、一例として、ＩＥＥＥ８０２．１１無線ＬＡＮのＭＡＣプロトコル仕様で規定されているフレーム間のタイムインターバルであるＳＩＦＳ（Ｓｈｏｒｔ  Ｉｎｔｅｒ−ｆｒａｍｅ  Ｓｐａｃｅ）時間（＝１６μｓ）または、その他の事前に定義した時間（ＩＦＳ）を用いることができる。一定時間Ｔ１は、システムまたは仕様で決められていてもよいし、ビーコンフレームあるいはその他の管理フレームなど、別の方法で事前に通知されてもよい。その他の例として、一定時間Ｔ１の値がトリガーフレーム５０１の所定フィールドに格納されており、端末１〜４は所定フィールドから一定時間Ｔ１の値を取得してもよい。
【００６８】
端末１、３、４、６が送信するデータフレームの送信タイミングは互いに同期され、これによりＵＬ−ＯＦＤＭＡ送信が実行されることになる。なお、端末が、アップリンク送信するデータがないにも拘わらずリソースユニットを選択する動作を行う場合、その端末は、予め定めた形式のフレーム、例えば物理ヘッダとＭＡＣヘッダは存在するもののデータフィールドが存在しないフレームであるＮｕｌｌ  Ｐａｃｋｅｔ（ヌルパケット）を送信してもよい。あるいは、その端末は、リソースユニットの選択はしたものの、送信動作は何も行わないようにしてもよい。基地局では、ヌルパケットを受信した場合、当該端末は送信すべきデータが存在しなかったと判断してもよい。
【００６９】
基地局は、端末１、３、４、６からＯＦＤＭＡで送信されるデータフレーム５１１、５１３、５１４、５１６（より詳細にはデータフレームを含む物理パケット）を受信する。
基地局は、データフレーム５１１、５１３、５１４、５１６を、それぞれリソースユニット２、４、６、７で受信する。その他のリソースユニットでは、どの端末からもデータフレームの送信は行わないため、基地局でも、データフレームの受信は行わない。
【００７０】
基地局は、端末１、３、４、６から送信されたデータフレームを正しく受信すると、各データフレームの受信から一定時間Ｔ２後に、送達確認応答フレーム５２１を端末１、３、４、６に送信する。一定時間Ｔ２は、一例として、ＩＥＥＥ８０２．１１無線ＬＡＮのＭＡＣプロトコル仕様で規定されているフレーム間のタイムインターバルであるＳＩＦＳ（Ｓｈｏｒｔ  Ｉｎｔｅｒ−ｆｒａｍｅ  Ｓｐａｃｅ）時間（＝１６μｓ）または、その他の事前に定義した時間（ＩＦＳ）を用いることができる。
【００７１】
送達確認応答フレーム５１３の送信として、ＢＡフレームを端末１、３、４、６毎に、それぞれデータフレームが受信されたリソースユニットで送信する。基地局に送信されたデータフレームがＡ−ＭＰＤＵでなく、通常（単一）のＭＰＤＵを含む場合は、ＢＡフレームではなくＡＣＫフレームでもよい（なお、通常のＭＰＤＵの場合にＢＡフレームを返すことも可能である）。このように端末１、３、４、６毎にそれぞれのリソースユニットでＢＡ（またはＡＣＫ）フレームを送信することは、ダウンリンクのＯＦＤＭＡで送達確認応答フレームを送信することに相当する。この場合、各端末はそれぞれのリソースユニットでＢＡ（またはＡＣＫ）フレームを受信する（そのようにリソースユニット単位で信号を受信できるように、受信フィルタを設定しておく）。別の方法として、ＢＡフレーム（またはＡＣＫフレーム）を端末１、３、４、６に、ダウンリンクのＭＵ−ＭＩＭＯで送信することも可能である。ダウンリンクのＭＵ−ＭＩＭＯは、ＩＥＥＥ８０２．１１ａｃで規定されている。
【００７２】
さらに別の方法として、端末１、３、４、６用の送達確認応答をすべて含む単一のフレームをチャネル幅帯域で送信（シングルユーザ送信）してもよい。この場合、このフレームのことを、Ｍｕｌｔｉ−ＳＴＡ  ＢＡフレームと呼んでもよい。具体的な構成としては、例えばＩＥＥＥ８０２．１１規格で定義されたＭｕｌｔｉ−ＴＩＤ  ＢＡフレームを流用してもよい。一例として、Ｍｕｌｔｉ−ＴＩＤ  ＢＡフレームのＢＡ情報フィールドを端末数分配置し、各ＢＡ情報フィールドのＴＩＤ情報サブフィールド内の予約フィールドに、端末の識別子（例えばＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ  ＩＤ）またはＡＩＤの一部）を設定する。各ＢＡ情報フィールドのＢｌｏｃｋ  Ａｃｋ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ  Ａｃｋ  Ｂｉｔｍａｐサブフィールドには通常通り、送達確認応答を返すべきデータフレーム５１１、５１３、５１４、５１６に応じて値を設定すればよい。Ｍｕｌｔｉ−ＳＴＡ  ＢＡフレームのＲＡ（受信先アドレス）は、端末１、３、４、６が共通に属するグループのマルチキャストアドレス、またはブロードキャストアドレスとすればよい。このようにすることで、１つのフレームで複数の端末にＢＡを通知できる。またＦｒａｍｅ  Ｃｏｎｔｒｏｌフィールドのサブタイプとして、新たな値を定義してもよい。
【００７３】
端末１、３、４、６に、ＢＡフレームではなくＡＣＫフレームを返す場合は、各ＢＡ情報フィールドのＴＩＤ情報サブフィールド内の予約フィールドにおける一部のフィールドに端末の識別子を設定し、残りの一部のフィールドのビットを立てる（１にする）ようにする。そして、当該ビットを立てた場合に、Ｂｌｏｃｋ  Ａｃｋ  Ｓｔａｒｔｉｎｇ  Ｓｅｑｕｅｎｃｅ  ＣｏｎｔｒｏｌサブフィールドおよびＢｌｏｃｋ  Ａｃｋ  Ｂｉｔｍａｐサブフィールドは省略する（存在しない）。これにより、１つのフレームで複数の端末のＡＣＫを通知できる。別の例としては、パーシャルステート動作を用い、対応するシーケンス番号をＢｌｏｃｋ  Ａｃｋ  Ｂｉｔｍａｐサブフィールドで表現するようにする。
ここで述べた例は、一例であり、Ｍｕｌｔｉ−ＴＩＤ  ＢＡフレーム以外の既存のフレームを流用してもよいし、既存のフレームを流用するのではなく、新規にフレームを定義してもよい。
【００７４】
上述した説明では送達確認応答フレーム５２１を端末１、３、４、６に一度に送信する例を示したが、端末１、３、４、６に順番に、ＢＡフレームまたはＡＣＫフレームを返す方法も可能である。例えば、ＢＡフレームを順番に返す際、任意の１台の端末（例えば端末１）には、データフレームの受信完了からＳＩＦＳ時間後にＢＡフレームを返し、残りの端末については、ＢＡＲフレームを端末から受信し、その応答としてＢＡフレームを送信することを行ってもよい。あるいは残りの端末については、基地局でＢＡＲフレームを受信せずにＢＡフレームを送信し、応答としてＡＣＫフレームを受信することを行ってもよい。ここで述べた以外の方法で、ＢＡフレームまたはＡＣＫフレームを返すことも可能である。
【００７５】
基地局による送達確認応答フレーム５２１の送信後、基地局からのトリガーフレームの送信から再度同様のシーケンスが繰り返し行われてもよい。
【００７６】
上述した動作例では、トリガーフレームでグループＩＤにより指定された端末はリソースユニットの選択権があると、トリガーフレームで指定された複数のリソースユニットからランダムにリソースユニットを選択した。別の動作として、基地局はトリガーフレームで端末毎に個別にリソースユニットを指定し、トリガーフレームで指定された端末は、トリガーフレームで指定されたリソースユニットを選択する動作も可能である。例えばトリガーフレームで端末１、３、４、６の識別子（ＡＩＤ等）を指定するとともに、リソースユニット２、４、６、７の識別子をこれらの端末にそれぞれ個別に指定する。これにより図７と同様のシーケンスが行われる。リソースユニットをいくつか連続して同じ端末に割り当てるようにしてもよい。また、これらの動作（リソースユニットのランダム選択と個別指定）の両方を組み合わせた動作も可能である。また、基地局にまだ接続していない端末も、ＵＬ−ＯＦＤＭＡの対象としてトリガーフレームで指定することも可能である。以下、これらの動作を実現するための、トリガーフレーム５０１の構成例および使用例（解釈例）と、当該構成例に応じた基地局および端末の動作についてさらに詳細に説明する。
【００７７】
図９（Ａ）は、トリガーフレーム５０１の構成例を示す。図５に示したＭＡＣフレームのＭＡＣヘッダに、ＲＵ／ＡＩＤフィールドが追加され、Ａｄｄｒｅｓｓ３フィールド等、一部のフィールドは削除されている。ただし、これらの削除されたフィールドの一部または全部が図７のフレーム構成に存在してもかまわない。図９（Ｂ）は、ＲＵ／ＡＩＤフィールドがＭＡＣヘッダではなく、フレームボディフィールドに存在する場合の例である。フレームボディフィールドにＲＵ／ＡＩＤフィールドを設ける場合、トリガーフレーム５０１が管理フレームであれば、図６に示したように情報エレメントとしてＲＵ／ＡＩＤフィールドを設けることが考えられる。制御フレームまたはデータフレームであれば、ＲＵ／ＡＩＤフィールドを識別可能な形式で、フレームボディフィールドに追加すればよい。以下の説明では、特に区別する必要がある場合を除き、ＲＵ／ＡＩＤフィールドがＭＡＣヘッダにあるかフレームボディフィールドにあるかは問わないものとする。
【００７８】
図１０は、トリガーフレームのＲＵ／ＡＩＤフィールドの構成例と、各フィールド長の例を示す。ここに示したフィールド長はあくまで一例であり、他の値が用いられてもかまわない。例えばここではオクテット（８ビット）単位でフィールド長を示しているが、オクテット単位でなくてもかまわない。「３×ｎ」は、３にｎを乗じた値を意味する。
【００７９】
ＲＵ／ＡＩＤフィールドは、ＲＵフィールド（ＲＵ＿１〜ＲＵ＿ｎ）とＡＩＤフィールド（ＡＩＤ＿１〜ＡＩＤ＿ｎ）とのｎ個の対（組）を含む。本フレームフォーマットの基本的な使用方法として、ＲＵフィールドとＡＩＤフィールドを用いて、リソースユニットの指定と、当該リソースユニットを割り当てる端末の指定を行う。ＲＵフィールドでリソースユニットの識別子を設定し、ＡＩＤフィールドで、当該リソースユニットを割り当てる端末の識別子（ここではＡＩＤ）を設定する。これにより、リソースユニットごとに端末を指定し、各端末が、指定されたリソースユニットを使用する。ここで、フレームコントールフィールドのタイプは“制御”または“管理”とし、サブタイプはトリガーフレームに対応する新たな値を定義する。タイプは“制御”または“管理”ではなく、“データ”でもかまわない。この場合、サブタイプを新たな値に定義する代わりに、トリガーフレームか否かを通知するフィールドをＭＡＣヘッダに別途設け、そのフィールドにビットを立てることでトリガーフレームであることの通知を行ってもかまわない。Ｄｕｒａｔｉｏｎ／ＩＤフィールドには、トリガーフレームの末尾から無線媒体の使用を占有したい期間長を指定する。例えば送達確認応答フレームの末尾までの時間長を指定する。Ｓｅｑｕｅｎｃｅ  ＣｏｎｔｒｏｌおよびＦＣＳフィールドは、通常通り値を設定すればよい。Ａｄｄｒｅｓｓ１フィールドには、ＲＡとして、ブロードキャストアドレスまたはマルチキャストアドレスを設定すればよい。Ａｄｄｒｅｓｓ２フィールドにはＴＡとして、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定すればよい。なお、ｎ（ＲＵフィールドとＡＩＤフィールドの組の個数）は固定でもよいし、可変でもよい。可変の場合、ＲＵ／ＡＩＤフィールドの先頭にｎを定めるフィールドを設けてもよいし、ＲＵ／ＡＩＤフィールドの終わりを通知するフィールドを設けてもよい。終わりを通知するフィールドは、リソースユニットの識別子とＡＩＤの組み合わせにない特別な値でもよい。
【００８０】
以下では、このようなＲＵ／ＡＩＤフィールドの構成を有するフレームフォーマットを利用して、図７で説明したような、端末群をグループＩＤで指定し、当該グループＩＤに属する端末群にランダムバックオフ手法に類似した方法に基づきリソースユニットを選択させて、フレーム送信を行わせる例を示す。
【００８１】
（第１の例）
この場合も、ＲＵフィールド（ＲＵ＿１〜ＲＵ＿ｎ）には、利用可能なリソースユニットの識別子を設定する。図１０の例では、ｎ個のＲＵフィールドが存在し、これらのＲＵフィールドにそれぞれ該当するリソースユニットの識別子を設定する。一方、ｎ個のＡＩＤフィールド（ＡＩＤ＿１〜ＡＩＤ＿ｎ）には、第１の例では、任意の値を設定する。
【００８２】
一方、フレームコントールフィールドのタイプは“制御”または“管理”とし、サブタイプはトリガーフレームに対応する新たな値を定義する。タイプは“制御”または“管理”ではなく、“データ”でもかまわない。この場合、サブタイプを新たな値に定義する代わりに、トリガーフレームか否かを通知するフィールドをＭＡＣヘッダに別途設け、そのフィールドにビットを立てることでトリガーフレームであることの通知を行ってもかまわない。Ｄｕｒａｔｉｏｎ／ＩＤフィールドには、トリガーフレームの末尾から無線媒体の使用を占有したい期間長を指定する。例えば送達確認応答フレームの末尾までの時間長を指定する。Ｓｅｑｕｅｎｃｅ  ＣｏｎｔｒｏｌおよびＦＣＳフィールドは、通常通り値を設定すればよい。
【００８３】
Ａｄｄｒｅｓｓ１フィールドには、候補端末（図７の例では端末１、３、４、６）が属しているグループのグループＩＤを設定する。通常、Ａｄｄｒｅｓｓ１フィールドにはＲＡ（ユニキャストアドレス、ブロードキャストアドレスまたはマルチキャストアドレス）を設定するため、グループＩＤを設定するのは通常とは異なる動作である。このため、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知する必要がある。
そこで、Ａｄｄｒｅｓｓ２フィールドに、基地局のＭＡＣアドレス（ＢＳＳＩＤ）のＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビット（特定位置のビット）を１に変換したものを設定する。通常、Ａｄｄｒｅｓｓ２フィールドにはＴＡを設定するため、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定するのが通常の動作である。ここでは、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知するため、基地局のＭＡＣアドレス（ＢＳＳＩＤ）のＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１に変換したものを設定する。
Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは、ＭＡＣアドレスの８ビット目（ＭＡＣアドレスを伝送するときは先頭からオクテット単位で送信し、各オクテットでは最下位ビットから順に送信するため、Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは、ＭＡＣアドレスを伝送するときの先頭ビットでもある）であり、端末（基地局を含む）のＭＡＣアドレスのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは０である。なお、ブロードキャストアドレスまたはマルチキャストアドレスの場合は１である。そこで、このＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを、０から１に変換することで、端末にＡｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知する（通常は、トリガーフレームの送信は基地局からであるため、Ａｄｄｒｅｓｓ２フィールドに設定するＴＡは基地局のＭＡＣアドレスであり、Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは０であることを利用している）。
よって、端末は、Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットが１であるため、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていると判断できるとともに、トリガーフレームの送信元アドレスが、Ａｄｄｒｅｓｓ２フィールドのビット列のＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１から０に戻したものであると判断することもできる。したがって、端末がデータフレームを送信する際のＲＡとして、Ａｄｄｒｅｓｓ２フィールドのビット列のＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１から０に戻したもの（すなわち基地局のＭＡＣアドレス）を用いることができる。
【００８４】
なお、ｎ（ＲＵフィールドとＡＩＤフィールドの組の個数）は固定でもよいし、可変でもよい。可変の場合、ＲＵ／ＡＩＤフィールドの先頭にｎを定めるフィールドを設けてもよいし、ＲＵ／ＡＩＤフィールドの終わりを通知するフィールドを設けてもよい。終わりを通知するフィールドは、リソースユニットの識別子とＡＩＤの組み合わせにない特別な値でもよい。
【００８５】
上述したように設定されたトリガーフレームを受信した端末は、例えばフレームコントロールフィールドのタイプおよびサブタイプの値から、トリガーフレームを受信したことを把握する。Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐが１であることから、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを把握し、Ａｄｄｒｅｓｓ１フィールドに設定されているグループＩＤを読み出す。当該グループＩＤが示すグループに自端末が属しているかを判断し、属していない場合は、トリガーフレームを廃棄して処理を終了する。当該グループＩＤが示すグループに自端末が属している場合は、ＲＵ／ＡＩＤフィールドを確認し、ｎ個のＲＵフィールドに設定された識別子により示されるリソースユニットを、利用候補となるリソースユニットとして把握する。
ｎ個のＡＩＤフィールドは無視する。端末は、例えば予めランダムに選択したバックオフカウンタ値から利用候補となるリソースユニットの数を引き、０以下になるとリソースユニットの選択権があるとして、利用候補となるリソースユニットの中からランダムに自端末が使用するリソースユニットを選択する。ここでは１つのリソースユニットを選択することを想定するが、前述したように複数のリソースユニットを選択してもよい。ランダムに選択する方法は何でもかまわない。例えば一定の桁数の数字を発生させる乱数器を用いて、乱数値をｎで除算したときの余りの値に１を加算した番号のリソースユニットを特定してもよい。この場合、余りの値がゼロであればリソースユニット１、余りの値がｎ−１であれば、リソースユニットｎを選択する。ここで述べた例は一例に過ぎず、別の方法を用いても、もちろんかまわない。端末は、ランダムに選択したリソースユニットを用いて、上述したようにデータフレームを送信する。なお、データフレームのＲＡ（Ａｄｄｒｅｓｓ１フィールドの値）は基地局のＭＡＣアドレス（ＢＳＳＩＤ）、ＴＡ（Ａｄｄｒｅｓｓ２フィールドの値）は自端末のＭＡＣアドレスである。
【００８６】
上述した第１の例によれば、グループＩＤで指定されたグループに属する端末のみがＵＬ−ＯＦＤＭＡの候補端末となるため、トリガーフレームを受信した全端末が候補端末となる場合よりも、ランダムに選択するリソースユニットが端末間で重複する可能性を低減できる。なお、複数の端末間で同じリソースユニットが選択された場合、基地局で当該リソースユニットで信号干渉が生じ、これら複数の端末からのフレームを正常に受信できなくなる。
【００８７】
（第２の例）
第２の例は、ｎ個のＡＩＤフィールドの設定と、端末の動作が第１の例と異なる。以下第１の例との差分を説明する。ｎ個のＡＩＤフィールドには、ＡＩＤとして未使用の値、もしくは端末に割り当てたＡＩＤを設定する。“ＡＩＤとして未使用の値”とは、基地局が割り当て可能なＡＩＤの値の範囲外の値のことである。例えば基地局が２オクテット（１６ビット）のうちの１４個のビットを使ってＡＩＤを表現する場合、基地局が割り当て可能なＡＩＤの値の範囲が１以上２００７以下であれば、ＡＩＤフィールドの２オクテット（１６ビット）のうち１４個のビット（第０〜第１３ビット）をすべて０もしくは、２００８〜１６３８３内の値に設定する。第１４ビットおよび第１５ビットは固定値（例えば“１１”）を設定する。なお、ここで述べたＡＩＤの未使用の値の設定例は、ＩＥＥＥ８０２．１１規格で定められたＤｕｒａｔｉｏｎ／ＩＤフィールドの予約領域を利用する方法に類似している（ＩＥＥＥ  Ｓｔｄ  ８０２．１１（ＴＭ）−２０１２のテーブル８−３参照）。端末にランダムにリソースユニットの選択を行わせる場合は、該当するＡＩＤフィールドに、ＡＩＤとして未使用の値を設定する。一方、端末が使用するリソースユニットを指定する場合は、該当するＡＩＤフィールドに当該端末に割り当てたＡＩＤを設定する。ｎ個のＡＩＤフィールドにすべて、ＡＩＤとして未使用の値を設定する場合、ｎ個のこれらのフィールドに設定する値はすべて共通の値でもよいし、そうでなくてもよい。
【００８８】
端末は、ＡＩＤフィールドの値が、“ＡＩＤとして未使用の値”であるかを判断し、“ＡＩＤとして未使用の値” （上述の例であれば第０〜第１３ビットが０もしくは２００８以上の値を表すビットで、第１４および第１５ビットが“１１”の場合）であれば、当該リソースユニットが利用可能であると判断する。ＡＩＤとして使用され得る値であれば（上述の例であれば第０〜第１３ビットが１〜２００７内の値を表すビットで、第１４および第１５ビットが“１１”の場合）は、当該リソースユニットは、当該ＡＩＤが自端末のＡＩＤかを判断する。自端末のＡＩＤであれば、自端末が当該リソースユニットの使用を基地局によって指定されているものと判断する。自端末のＡＩＤでなければ、当該リソースユニットは自端末で利用できないと判断する。端末は、自端末に指定されたリソースユニットがあれば、そのリソースユニットを選択する。通信に必要なリソースユニット数が複数（Ｈ個）の場合に、指定されたリソースユニット数がそのＨに満たない場合は、その差分のリソースユニットだけ、利用可能なリソースユニットからランダムに選択すればよい。
【００８９】
上述した第２の例によれば、ＵＬ−ＯＦＤＭＡの候補端末を特定のグループに限定できるとともに、端末ごとに使用させるリソースユニットを指定することも可能となる。これにより例えば端末が複数のリソースユニットを使用する場合に、一部のリソースユニットは基地局が指定し、残りのリソースユニットはランダムに選択することも可能になる。基地局が指定したリソースユニットについては他の端末が使用することがないため、基地局での当該リソースユニットでの端末間の干渉は発生せず、より確実な通信が期待できる。
【００９０】
（第３の例）
第２の例では、ＡＩＤフィールドに、ＡＩＤとして未使用の値、もしくは端末に割り当てたＡＩＤを設定したが、本例では、ＡＩＤとして未割り当ての値、もしくは端末に割り当てたＡＩＤを設定する。第２の例との差分を説明する。ＡＩＤとして未割り当ての値は、ＡＩＤとして未使用の値に加えて、基地局がＡＩＤとして割り当て可能な範囲のＡＩＤの値であるが、まだ割り当てていないＡＩＤを含む。基地局が、各端末に端末とＡＩＤの一覧を通知する場合には、この方法でも、第２の例と同様の動作が可能になる。すなわち、基地局は、端末にランダムにリソースユニットの選択を行わせる場合は、該当するＡＩＤフィールドに、ＡＩＤとして未割り当ての値を設定する。一方、端末が使用するリソースユニットを指定する場合は、該当するＡＩＤフィールドに当該端末に割り当てたＡＩＤを設定する。端末は、ＡＩＤフィールドの値が、“ＡＩＤとして未割り当ての値”であるかを上記の一覧を利用して判断し、“ＡＩＤとして未割り当ての値”であれば、当該するリソースユニットが利用可能であると判断する。ＡＩＤとして割当済みの値であれば、当該値が自端末のＡＩＤかを判断し、自端末のＡＩＤであれば、自端末が当該するリソースユニットの使用を基地局によって指定されているものと判断する。自端末のＡＩＤでなければ、当該リソースユニットは自端末で利用できないと判断する。端末は、自端末に指定されたリソースユニットがあれば、そのリソースユニットを選択する。通信に必要なリソースユニット数が複数（Ｈ個）の場合に、指定されたリソースユニット数がそのＨに満たない場合は、その差分のリソースユニットだけ、利用可能なリソースユニットからランダムに選択すればよい。
【００９１】
上述した第３の例によれば、第２の例と同様の効果を得ることができる。
【００９２】
（第４の例）
第４の例では、基地局は、ＡＩＤフィールドに、グループＩＤのグループに属している端末のうち、該当リソースブロックの使用を禁止する端末のＡＩＤ、もしくは、ＡＩＤとして未使用の値を設定する。第１〜第３の例との差分を説明する。特定の端末の使用は禁止したいが、残りの端末のいずれも使用を許可する場合には、ＡＩＤフィールドに使用を禁止する端末のＡＩＤを設定する。グループＩＤのグループに属しているすべての端末のいずれの使用も許可する場合には、ＡＩＤとして未使用の値を設定する。ＡＩＤとして未使用の値の代わりに、第３の例と同様に、ＡＩＤとして未割り当ての値を用いてもよい。
端末は、ＡＩＤフィールドに自端末のＡＩＤが設定されているリソースユニットについては、自端末はそのリソースユニットは使用できないと判断する。ＡＩＤとして未使用の値（もしくはＡＩＤとして未割り当ての値）が設定されているリソースユニットは利用可能であると判断する。端末は、利用可能なリソースユニットの中からランダムに、自端末が使用するリソースユニットを選択する。
【００９３】
上述した第４の例によれば、あるリソースユニットについて、特定の端末には使用を禁止しつつ、他の端末に対してランダムに当該リソースユニットを選択することを許容できる。
【００９４】
（第５の例）
第５の例では、トリガーフレームのＡｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知する方法が、第１〜第４の例と異なる。
【００９５】
なお、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知する必要がある理由は、通常は、Ａｄｄｒｅｓｓ１フィールドにはユニキャストアドレス、ブロードキャストアドレス、またはマルチキャストアドレスを設定し、グループＩＤが設定されることは想定されていない。したがって、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されているのか、ブロードキャストまたはマルチキャストなどのアドレスが設定されているかを区別できるようにする必要がある。
【００９６】
第１〜第４の例ではグループＩＤが設定されていることを通知するために、Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１に変換したが、本例ではＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットは０を維持する。すなわち、Ａｄｄｒｅｓｓ２フィールドには、通常通り、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定する。その代わりに、グループＩＤが設定されていることは、別のフィールドを用いて端末に通知する。例えば、フレームコントロールフィールドの予約領域を用いて、グループＩＤの有無を設定する。または、図５に示したＱｏＳフィールドをトリガーフレームにも残し、当該ＱｏＳフィールド内の予約領域にグループＩＤの有無を設定する。または、ＭＡＣヘッダに、新規のフィールド、例えば図１１に示すＨＥ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ）コントロールフィールドを設け、当該ＨＥコントロールフィールドに、グループＩＤの有無を設定する。グループＩＤの有無を通知すること以外は、第１〜第４の例と同様である。
【００９７】
（第６の例）
第６の例では、トリガーフレームのＡｄｄｒｅｓｓ１フィールドに、グループＩＤが設定されていることを通知する方法が、第１〜第５の例と異なる。以下、第５の例との差分を中心に説明する。第５の例では、グループＩＤが設定されていることを通知するために、新たなフィールドを設けるか、既存のフィールドの予約領域を用いた。これに対して、第６の例では、ＲＵ／ＡＩＤフィールドのＡＩＤフィールドを利用する。ＡＩＤフィールドに、上述した“ＡＩＤとして未使用の値”をＡＩＤフィールドに設定する。すべてのＡＩＤフィールドに入れてもよいし、特定の１つまたは複数のＡＩＤフィールド、例えば先頭のＡＩＤフィールドにのみ入れてもよい。第６の例では、ＡＩＤフィールドに“ＡＩＤとして未使用の値”が設定されていることは、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを意味する。“ＡＩＤとして未使用の値”の代わりに、“ＡＩＤとして未割り当ての値”を用いてもかまわない。
【００９８】
端末はトリガーフレームを受信すると（受信したフレームが、フレームコントロールフィールドのタイプおよびサブタイプにより、トリガーフレームであることを認識すると）、ＲＵ／ＡＩＤフィールド内のいずれかのＡＩＤフィールド、または特定の１つまたは複数のＡＩＤフィールドの値を確認し、“ＡＩＤとして未使用の値”（あるいは“ＡＩＤとして未割り当ての値”）であれば、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを把握する。あるいは、ＲＵ／ＡＩＤフィールド内の全てのＡＩＤフィールドの値を確認して、すべてが“ＡＩＤとして未使用の値”（あるいは“ＡＩＤとして未割り当ての値”）であれば、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを把握してもよい。端末はＡｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを把握すると、Ａｄｄｒｅｓｓ１フィールドに設定された値を読み出して、当該値が示すグループＩＤのグループに自端末が属しているかを判断する。当該グループに自端末が属している場合は、ＲＵ／ＡＩＤフィールド内の各ＲＵフィールドに設定された値が示すリソースユニットを、自端末が利用可能なリソースユニットとして特定する。前述のように特定したリソースユニットの中からランダムに、自端末が使用するリソースユニットを選択する。以降の動作は第１の例と同様である。
【００９９】
（第７の例）
第７の例では、トリガーフレームのフォーマットとして図１２に示すものを用いる。図９に示したフォーマット例と異なる点は、ＲＵ／ＡＩＤフィールドがＡＩＤ通知フィールド（ＡＩＤ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｆｉｅｌｄ）に置換されたことである。ＡＩＤ通知フィールドには、ｎ個のＡＩＤフィールド（ＡＩＤ＿１、ＡＩＤ＿２、・・・ＡＩＤ＿ｎ）が含まれる。各ＡＩＤフィールドはそれぞれ予め定められたリソースユニットに対応づけられている。例えばＡＩＤ＿１はリソースユニット１、ＡＩＤ＿２はリソースユニット２に対応づけられているなどである。どのＡＩＤフィールドがどのリソースユニットに対応づけられているかは、事前に基地局から各端末に通知してもよいし、システムまたは仕様で予め定められていても良い。各ＡＩＤフィールドおよびその他のフィールドの設定方法はこれまで述べた例と同様である。また、トリガーフレームを受信した場合の端末も動作も、ＲＵフィールドを確認する動作が不要な点以外は、これまでの例と同様である。
【０１００】
（第８の例）
第８の例では、トリガーフレームのフォーマットとして図１３に示すものを用いる。図９に示したフォーマット例と異なる点は、ＲＵ／ＡＩＤフィールドがＲＵ通知フィールド（ＲＵ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｆｉｅｌｄ）に置換されたことである。ＲＵ通知フィールドには、ｎ個のＲＵフィールドが含まれる。各ＲＵフィールドには、第１〜第６の例と同様に、ＵＬ−ＯＦＤＭＡで利用可能なリソースユニットの識別子を設定する。その他のフィールドの設定方法は、第１の例または第５の例と同様である。
【０１０１】
例えば、第１の例に準じて設定するならば、Ａｄｄｒｅｓｓ１フィールドにはグループＩＤを設定し、Ａｄｄｒｅｓｓ２フィールドには基地局のＭＡＣアドレスのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを０から１に置換したものを設定する。またフレームコントロールフィールドのタイプは“制御”または“管理”とし、サブタイプはトリガーフレーム用に新たに定義した値を用いるなどとする。あるいは、タイプを“データ”としてもよい。この場合、サブタイプを新たな値に定義する代わりに、トリガーフレームか否かを通知するフィールドをＭＡＣヘッダに別途設け、そのフィールドにビットを立てることでトリガーフレームであることの通知を行ってもかまわない。
【０１０２】
また、第５の例に準じて設定する場合、Ａｄｄｒｅｓｓ１フィールドにはグループＩＤを設定し、Ａｄｄｒｅｓｓ２には基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定する。また、フレームコントロールフィールドの予約領域またはＱｏＳフィールド（図５参照）内の予約領域等にグループＩＤの有無を設定する。または、ＭＡＣヘッダに、例えば図１１に示すＨＥ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ）コントロールフィールドを設け、当該ＨＥコントロールフィールドに、グループＩＤの有無を設定する。フレームコントロールフィールドの設定は、上記第１の例等と同様である。
【０１０３】
端末はトリガーフレームを受信すると（例えば受信したフレームが、フレームコントロールフィールドのタイプおよびサブタイプにより、トリガーフレームであることを認識すると）、ＲＵ通知フィールド内の各ＲＵフィールドから利用可能なリソースユニットを把握し、把握したリソースユニットの中からランダムにリソースユニットを選択する。以降の動作は第１の例等と同様である。
【０１０４】
（第９の例）
第９の例では、第１〜第６の例と同様にトリガーフレームのフォーマットとして図９に示すものを用いるが、Ａｄｄｒｅｓｓ１フィールドとＡＩＤフィールドの利用方法が異なる。本例では、Ａｄｄｒｅｓｓ１フィールドには、ブロードキャストアドレスまたはマルチキャストアドレスを設定する。当該ブロードキャストアドレスが設定されたフレームは、端末１〜８のいずれも自端末宛として受信するフレームである。マルチキャストアドレスが設定されている場合、ここでは端末１〜８はマルチキャストアドレスの対象であるとし、当該フレームを自端末宛として受信する。ただし、端末１〜８の一部が属さないグループのマルチキャストアドレスを用いることも可能である。ＲＵ／ＡＩＤフィールド内の各ＡＩＤフィールドにはグループＩＤを設定する。各ＡＩＤフィールドにグループＩＤが設定されていることを通知するため、Ａｄｄｒｅｓｓ２フィールドには、基地局のＭＡＣアドレスのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを０から１に置換したものを設定する。前述した他の例では、Ａｄｄｒｅｓｓ１フィールドにグループＩＤが設定されていることを通知するために、Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを０から１に変換したが、本例では、ＡＩＤフィールドにグループＩＤが設定されていることを通知するために、Ｉｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１に変換する。各ＡＩＤフィールドには、ＵＬ−ＯＦＤＭＡの対象となるグループのグループＩＤをすべての共通の値として設定する。各ＡＩＤフィールドにグループＩＤを設定する様子を図１４に示す。グループＩＤの長さは、もともとＡＩＤを設定するＡＩＤフィールドの趣旨から２オクテットに図１４の例ではしているが、グループＩＤを表現するのに１オクテットで十分であれば（例えばグループＩＤが６ビットの場合など）、１オクテットのフィールドにするなど、ＡＩＤフィールド長は変更してもよい。この場合、図１０のフォーマットと区別するための情報をＲＵ／ＡＩＤフィールドの先頭や、前述したような既存のフィールドの予約領域、新たに追加するフィールド等に設定してもよい。
【０１０５】
端末はトリガーフレームを受信すると、受信したフレームのＡｄｄｒｅｓｓ１フィールドのアドレスから自端末で受信すべきフレームと判断し、またフレームコントロールフィールドのタイプおよびサブタイプにより、トリガーフレームであることを認識する。Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットが１であることから、ＡＩＤフィールドのグループＩＤが設定されていることを把握する。端末は、少なくとも１つのＡＩＤフィールドからグループＩＤを読み出し、当該グループＩＤが自端末のグループを示しているかを判断する。自端末のグループを示していないときは、自端末は今回のＵＬ−ＯＦＤＭＡの対象ではないと判断して、当該フレームを廃棄する。一方、上記グループＩＤが自端末のグループＩＤを示しているときは、各ＲＵフィールドからリソースユニットの識別子を読み出して、利用可能なリソースユニットを把握する。そして、把握した利用可能なリソースユニットの中から、ランダムにリソースユニットを選択する。
以降の動作は第１の例等と同様である。
【０１０６】
（第１０の例）
以下、第９の例との差分を説明する。前述した第９の例では、各ＡＩＤフィールドに共通の値のグループＩＤを設定したが、第１０の例では、ＡＩＤフィールドごとに異なるグループＩＤを設定することを許容する。基地局は、リソースユニットごとに利用可能なグループを決定し、当該ＲＵフィールドに対応するＡＩＤフィールドには、当該グループのグループＩＤを設定する。
【０１０７】
トリガーフレームを受信した端末は、各ＡＩＤフィールドに設定されているグループＩＤを検出し、自端末が当該グループＩＤに属しているかを判断する。端末は、自端末が属しているグループＩＤが設定されているＡＩＤフィールドに対応するＲＵフィールドで指定されたリソースユニットのみを、自端末が利用可能なリソースユニットとして把握する。そして、把握した利用可能なリソースユニットの中から、ランダムにリソースユニットを選択する。以降の動作は第１の例等と同様である。
【０１０８】
（第１１の例）
上述した第９の例および第１０の例では、各ＡＩＤフィールドにグループＩＤが設定されていることを通知するため、Ａｄｄｒｅｓｓ２フィールドに基地局のＭＡＣアドレスのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを０から１に置換したものを設定した。これに対して、第１１の例では、別の方法で各ＡＩＤフィールドにグループＩＤが設定されていることを通知する。
【０１０９】
第１１の例では、フレームコントロールフィールドの予約領域などの既存のフィールドの予約領域、または、図１１に示したＨＥコントロールフィールドなどの新たに定義したフィールド等に、各ＡＩＤフィールドにグループＩＤが設定されていることを通知する情報（グループＯＮ情報）を設定する。または、ＲＵフィールドに未使用の領域（予約領域）が存在すれば（例えば上位６ビットですべてのリソースユニットを識別できるときは、末尾の２ビットの領域）、当該領域にグループＯＮ情報を設定してもよい。当該グループＯＮ情報を設定しない場合は、基地局は、各ＡＩＤフィールドにはＡＩＤを設定する（この場合、前述したように、リソースユニットごとに端末を指定したＵＬ−ＯＦＤＭＡを行う）。この場合、基地局は、グループＯＮ情報の代わりに、ＡＩＤが設定されていることを通知する情報（グループＯＦＦ情報）を、上記の領域または新規フィールド等に設定する。Ａｄｄｒｅｓｓ２フィールドには、通常通り、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定する。Ａｄｄｒｅｓｓ１フィールドには、第９の例および第１０の例と同様に、ブロードキャストまたはマルチキャストアドレスを設定する。
【０１１０】
トリガーフレームを受信した端末は、上記の既存のフィールドの予約領域または新たに定義したフィールドにグループＯＮ情報が設定されているかを判断し、当該グループＯＮ情報が設定されている場合は、ＡＩＤフィールドに（ＡＩＤではなく）グループＩＤが設定されていることを把握する。以降の動作は、第９の例または第１０の例と同様である。
【０１１１】
（第１２の例）
第１２の例では、第９〜第１１の例とはさらに別な方法で、各ＡＩＤフィールドにグループＩＤが設定されていることを通知する。なお、第１２の例では、Ａｄｄｒｅｓｓ１フィールドには、第９の例および第１０の例と同様に、ブロードキャストまたはマルチキャストアドレスを設定し、Ａｄｄｒｅｓｓ２フィールドには、通常通り、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定する。
【０１１２】
第１２の例では、グループＩＤが設定されているかＡＩＤが設定されているか否かで、各ＡＩＤフィールド内の所定領域の設定を変更する。例えば基地局が２オクテット（１６ビット）のうちの１４個のビットを使ってＡＩＤを表現可能な場合、第０〜第１３ビットの１４ビットをＡＩＤの値またはグループＩＤ（ＡＩＤよりも短いビット長であるとする）を設定するのに使用し、第１４および第１５ビットの２ビットは、グループＩＤが設定されているか、あるいはＡＩＤが設定されているかを識別するために使用する。例えばＡＩＤを設定するときは、当該２ビットを“１１”（グループＯＦＦ情報）とし、グループＩＤを設定するときは、当該２ビットを“００”にする。ここで示したビット設定は一例であり、別のビット設定でもかまわない。
【０１１３】
トリガーフレームを受信した端末は、各ＡＩＤフィールドの所定領域（本例では第１４３および第１５ビット）を確認し、グループＯＮ情報（例えば“００”）が設定されている場合は、ＡＩＤフィールドにグループＩＤが設定されていることを把握する。グループＯＦＦ情報（例えば“１１”）が設定されている場合は、ＡＩＤフィールドにＡＩＤが設定されていることを把握する。グループＩＤが設定されていることを把握した後の動作は、第９の例または第１０の例と同様である。
【０１１４】
（第１３の例）
第１〜第１２の例では、グループＩＤを設定する場合と設定しない場合の２通りのフレームの使用パターンが存在した。そして、グループＩＤを設定する場合には、Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを１にすることや、既存フィールドの予約領域、新たに定義したフィールド、またはＡＩＤフィールドの所定領域にグループＩＤが設定されていることの情報（グループＯＮ情報）を設定するなど行った。
これに対して、第１３の例では、フレームフォーマット内にグループＩＤフィールドをデフォルトで定義する。この場合のフレームフォーマット例を図１５に示す。グループＩＤフィールドがＳｅｑｕｅｎｃｅ  ＣｏｎｔｒｏｌフィールドとＲＵ／ＡＩＤフィールドとの間に追加されている。グループＩＤフィールド長は１オクテットとしているが、これに限定されるものではない。ＲＵ／ＡＩＤフィールドは、例えば図１０に示したものと同じ構成を用いることができる。ＡＩＤフィールドには、第１の例と同様に、任意の値を設定してもよい（端末はＡＩＤフィールドを読む必要がない場合）。
【０１１５】
あるいは、グループＩＤフィールドで指定するグループに属する端末のうち、特定の端末に特定のリソースユニットを指定する場合には、当該特定のリソースユニットを指定するＲＵフィールドに対応するＡＩＤフィールドに、当該特定の端末のＡＩＤを設定してもよい。そして、グループに属する端末ならばどの端末でも利用してよいリソースユニットを指定するＲＵフィールドに対応するＡＩＤフィールドには、ＡＩＤとして未使用の値、またはＡＩＤとして未割り当ての値を設定してもよい。
【０１１６】
各ＡＩＤフィールドに設定するＡＩＤは、ｐａｒｔｉａｌ  ＡＩＤでもよい（これまでに述べた他の例でも同様）。ｐａｒｔｉａｌ  ＡＩＤは、ＡＩＤの一部であり、少なくとも同じグループに属する端末間ではｐａｒｔｉａｌ  ＡＩＤは重複しないことを想定する。ｐａｒｔｉａｌ  ＡＩＤはＩＥＥＥ８０２．１１規格で定義されたものでもよい。ＡＩＤの代わりにｐａｒｔｉａｌ  ＡＩＤを用いることで、ＡＩＤフィールド長を短くできる。例えばＡＩＤフィールド長を２オクテットから１オクテットに変更できる。個の場合、ＲＵ／ＡＩＤフィールドのサイズも、３×ｎから２×ｎに変更できる。
【０１１７】
なお、Ａｄｄｒｅｓｓ１フィールドには、ブロードキャストまたはマルチキャストアドレスを設定し、Ａｄｄｒｅｓｓ２フィールドには、通常通り、基地局のＭＡＣアドレス（ＢＳＳＩＤ）を設定すればよい。またフレームコントロールフィールドの設定も、第１〜第１２の例と同様である。
【０１１８】
トリガーフレームを受信した端末は、グループＩＤフィールドに指定されたグループに自端末が属するかを判断し、当該グループに属する場合は、ＲＵ／ＡＩＤフィールドに設定された各ＲＵフィールドに設定された値から利用可能なリソースユニットを把握する。
そして、把握したリソースユニットの中から前述の動作に基づきランダムにリソースユニットを選択する。以降の動作は他の動作例と同様である。なお、端末は、グループＩＤフィールドに指定されたグループに自端末が属さないと判断した場合は、Ｄｕｒａｔｉｏｎ／ＩＤフィールドで指定された期間など、任意の時間の間、スリープモード（省電力モード）に遷移してもよい。このスリープモードに遷移する動作は、第１〜第１３の例でも同様に適用可能である。
【０１１９】
あるいは、自端末が、グループＩＤフィールドで指定されたグループに属する場合は、ＡＩＤフィールドに設定されたＡＩＤ（またはｐａｒｔｉａｌ  ＡＩＤ）を検査して、自端末が指定されているかを判断する。自端末が指定されている場合は、該当するＲＵフィールドに設定されたリソースユニットを自端末が使用することを決定する。なお、自端末に指定されたリソースユニット数が、通信に必要なリソースユニット数であるＨ（１以上の整数）個に満たない場合は、ＡＩＤとして未使用の値、またはＡＩＤとして未割り当ての値が設定されたＡＩＤフィールドに対応するＲＵフィールドを特定し、当該ＲＵフィールドで指定されたリソースユニットを、利用可能なリソースユニットとして把握する。そして、把握した利用可能なリソースユニットからＨ個に満たない分のリソースユニットをランダムに追加で選択してもよい。
【０１２０】
（第１４の例）
第１４の例では、トリガーフレームのフレームフォーマットとして、図１６に示すフレームフォーマットを用いる。図１５と異なる点は、ＲＵ／ＡＩＤフィールドが、ＲＵ通知フィールドに置換された点である。ＲＵ通知フィールドの構成は、図１３と同様であり、ＲＵ／ＡＩＤフィールドからＡＩＤフィールドを省略した形を有する。このフォーマットを利用することで、第１３の例でＡＩＤフィールドを無視する場合と同様の動作を、より短いトリガーフレーム長で実現できる。
【０１２１】
（第１５の例）
第１５の例では、トリガーフレームのフレームフォーマットとして、図１７に示すフレームフォーマットを用いる。図１６と異なる点は、ＲＵ通知フィールドが存在しない点である。このフォーマットを利用する場合、ＵＬ−ＯＦＤＭＡで利用可能なリソースユニットが予め定められており、事前に基地局から各端末に通知されているか、システムまたは仕様で事前に定められているとする。これにより各端末にランダムにリソースユニットを指定させてＵＬ−ＯＦＤＭＡを行う仕組みをより短いフレーム長のトリガーフレームで実現できる。
【０１２２】
（第１６の例）
これまでの説明では、基地局に接続済みであり、ＡＩＤを割り当てられている端末をＵＬ−ＯＦＤＭＡの対象としたが、基地局に接続しておらず、ＡＩＤの割り当ても受けていない端末を、トリガーフレームでＵＬ−ＯＦＤＭＡの対象として指定することも可能である。この場合、あるグループＩＤを、ＡＩＤ未指定の端末用として定義しておく。したがって、基地局に接続済みの端末は、このグループＩＤには属さない。基地局は、このグループＩＤを設定したトリガーフレームを、これまで述べた第１〜第１５の例のいずれかに基づいて生成および送信する。トリガーフレームを受信した、ＡＩＤ未割り当ての端末（基地局に未接続の端末）は、自端末がこのグループＩＤに属すると判断する。事前に端末はこのグループＩＤの通知を基地局からビーコンフレーム等で通知されていてもよいし、システムまたは仕様でこのグループＩＤが決められていてもよい。該当した端末は、前述のようにランダムにリソースユニットを選択する。この際の利用可能なリソースユニットのサイズは各々均等としてもよい。端末は、選択したリソースユニットで、アソシエーション要求フレームをアップリンク送信することができる（この場合、基地局は複数の端末からアソシエーション要求フレームを同時に受け付ける）。アソシエーション要求フレームは一例であり、再アソシエーション要求フレーム、プローブ要求フレームなど、他のフレームでもよい。
【０１２３】
また同様の動作を実現するために、ＡＩＤ未指定の端末用のグループＩＤを用いるのではなく、ＡＩＤとして未使用の値を、これまで述べたいずれかのフォーマットのＡＩＤフィールドに設定してもよい。この場合、ＡＩＤとして未使用の値は、これまでの第１〜第１５の例と異なり、ＡＩＤ未指定の端末（基地局に未接続の端末）を指定していることを意味する。ＡＩＤ未指定の端末は、予めシステムまたは仕様等でＡＩＤの範囲（例えば１〜２００７）を認識しており、この範囲外の値を、ＡＩＤとして未使用と判断する。トリガーフレームを受信した、ＡＩＤ未割り当ての端末（基地局に未接続の端末）は、いずれかのＡＩＤフィールドにＡＩＤとして未使用の値が設定されている場合は、自端末が指定されていると判断する。そして、当該端末は、ランダムにリソースユニットを選択し、選択したリソースユニットで、アソシエーション要求フレーム等のフレームをアップリンク送信することができる。
【０１２４】
なお、ＡＩＤ未指定の端末と、第１〜第１５の例で述べたＡＩＤ指定済みの端末とが混在するＵＬ−ＯＦＤＭＡも可能である。この場合、第１６の例を、第１〜第１５の例のいずれか１つまたは複数と組み合わせることで容易に実現可能である。
【０１２５】
（第１７の例）
グループＩＤを、パワーセーブを実施している端末用に設け、これをトリガーフレームで指定してもよい。例えばパワーセーブを実施している端末が基地局に定期的に特定のフレームを送ることが要求されている場合があるとする。例えば定期的にＰＳ−Ｐｏｌｌを送ることが要求されていることなどが考えられる。そこで、そのタイミングに合わせて、基地局が、パワーセーブを実施している端末群のグループＩＤを指定したトリガーフレームを送信して、特定のフレームを複数の端末から受信するようにしてもよい。個々の端末は、通常のシングルユーザ送信する場合に比べて、キャリアセンスおよびバックオフによるアクセス権獲得といったプロセスが不要であるため、一層低消費電力化を図ることができる。
【０１２６】
（第１８の例）
前述した図９〜図１７に示したフレームフォーマットは一例であり、トリガーフレームにはその他のフィールドがさらに存在してもよい。例えばＵＬ−ＯＦＤＭＡで送信する物理パケットのパケット長（ＰＰＤＵ長）を指定する情報を設定するフィールドが存在してもよい。ＵＬ−ＯＦＤＭＡで使用するＭＣＳ（変調符号化方式）または伝送レートを指定する情報を設定してもよい。パケット長またはＭＣＳまたはこれらの両方は、グループＩＤで指定するグループに属する全端末に共通でもよいし、当該グループに属する端末ごとに個別に指定してもよい。または、ＭＣＳの指定は、リソースユニットごとに行ってもよい。ここで述べた情報を設定するフィールドは、トリガーフレーム内の任意の位置でよい。例えば図１１に示したようなＨＥ  Ｃｏｎｔｒｏｌフィールド内に存在してもよいし、フレームボディフィールドに存在してもよいし、ＲＵ／ＡＩＤフィールド内に存在してもよい。ここで述べた例は、一例であり、他にも様々な情報を設定するフィールドが存在してもよい。
【０１２７】
（第１〜第１８の例間の組み合わせ）
上述した第１〜第１８の例はそれぞれ単独で実現可能な他、動作に矛盾の生じない限り、２つ以上を任意に組み合わせてもよい。例えば第１３の例と第４の例を組み合わせて、第１３の例において、ＡＩＤフィールドに、リソースブロックの使用を禁止する端末のＡＩＤを設定してもよい。これ以外の組み合わせももちろん可能である。
【０１２８】
図１８に、本発明の実施形態に係る基地局の動作の一例のフローチャートを示す。基地局は、任意のタイミングでＵＬ−ＯＦＤＭＡの開始を決定したら、ＵＬ−ＯＦＤＭＡの対象端末の指定方式として、個々の端末を個別に指定する個別指定方式か、グループを指定するグループ指定方式かを決定する（Ｓ１０１）。なお、当該方式の決定は、ＵＬ−ＯＦＤＭＡの開始決定前に行っても良いし、事前に予めいずれか一方に決められていてもよい。
【０１２９】
個別指定方式を決定した場合（Ｓ１０２のＮＯ）は、基地局に接続中のＯＦＤＭＡ対応端末の中から今回ＵＬ−ＯＦＤＭＡを行う個々の端末を選択し、また各端末に割り当てるリソースユニットを決定する（Ｓ１０３）。個々の端末を選択する方法は、どのような方法でもかまわない。例えば事前に各端末からＵＬ−ＯＦＤＭＡの要求有無を収集し、要求有りの端末から選択してもよい。または、各端末における送信用のデータ量に基づき、データ量が最も大きい端末から優先的に選択してもよいし、データ量が同じくらいの端末を選択してもよい。また、同じグループに属する端末の中から端末を選択してもよい。この際、グループを選択する基準として、各グループに属する端末ごとのＵＬ−ＯＦＤＭＡ送信の要求の有無、送信用データ量などの項目を考慮してもよい。または、ラウンドロビンで、端末またはグループを選択してもよいし、ランダムで端末またはグループを選択してもよい。または、次に送信するデータのサイズが同じ、または近いと推定されるデータを有する端末を選択、またはデータの発生周期が同じ、または発生周期が近い端末（発生周期が一定値以内に含まれる端末、または発生周期が最も近い所定数の端末など）を選択することも可能である。または、事前に各端末との伝搬路応答（spatial channel characteristics）を把握し、当該伝搬路応答に基づき、空間相関の小さい（干渉の小さい）端末の組み合わせを選択してもよい。なお、選択する端末数は、利用可能な最大リソースユニット数以下であるが、前述したＯＦＤＭＡ＆ＭＩＭＯ方式を利用する場合は、最大リソースユニット数以上の端末数も可能である。選択する端末数の下限が定められている場合に、下限以上の端末数を選択してもよい。ここで述べた端末の選択例は一例に過ぎず、ここで述べた以外の方法で端末を選択してもよい。
【０１３０】
またリソースユニットの割り当て方法も任意でよい。例えばリソースユニットがすべて同じ帯域幅であり、各端末に１つのリソースユニットを割り当てる場合は、任意の１つを各端末に割り当ててもよい。また、複数の帯域幅のリソースユニットが存在する場合、送信用のデータ量が大きい端末ほど、大きい帯域幅のリソースユニットを割り当ててもよい。また、複数のリソースユニットを１台の端末に割り当てる場合に周波数領域で連続して配置されたリソースユニットを選択してもよいし、非連続に配置されたリソースユニットを選択することも可能である。
【０１３１】
なお、ＵＬ−ＯＦＤＭＡのアップリンク送信で使用する帯域は、事前にシステムまたは仕様で決められていても良いし、基地局でＵＬ−ＯＦＤＭＡを行う際に決定してもよい。
あるいは、ここで述べた以外の方法で決定してもよい。
【０１３２】
基地局は、選択した端末の識別子（ＡＩＤ等）と、当該端末に割り当てたリソースユニットの識別子を、トリガーフレームの所定のフィールドに設定する（Ｓ１０４）。所定のフィールドは、使用するフォーマットに依存し、図１０のフォーマットであれば、ＲＵ／ＡＩＤフィールド内のＲＵフィールドおよびＡＩＤフィールドである。Ａｄｄｒｅｓｓ１フィールドには、ＲＡとして、ブロードキャストアドレスまたはマルチキャストアドレスを設定する。また、Ａｄｄｒｅｓｓ２フィールドには、自局のＭＡＣアドレス（ＢＳＳＩＤ）を設定する。またフレームコントロールフィールドのタイプフィールドおよびサブタイプフィールドには、トリガーフレーム用の値を設定してもよい。なお、リソースユニットの識別子は、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ等、複数の帯域間でユニークな値でもよいし、異なる帯域で同じ値の識別子が用いられることを許容してもよい。異なる帯域で同じ値の識別子を用いることを許容する場合、リソースユニットの識別子以外に、使用する帯域を識別する情報をトリガーフレーム内（例えば図１１のＨＥ  Ｃｏｎｔｒｏｌフィールドなど）で通知するか、予め使用する帯域を端末に通知しておけばよい。
【０１３３】
基地局は、トリガーフレームを生成したら、ＣＳＭＡ／ＣＡに従って無線媒体へアクセス権を獲得し、獲得したアクセス権に基づき、トリガーフレーム（より詳細にはトリガーフレームを含む物理パケット）を送信する（Ｓ１０５）。トリガーフレームは、例えばレガシー端末も送受信可能な基本チャネル幅（例えば２０ＭＨｚ）のチャネルで送信する。
なお、ＵＬ−ＯＦＤＭＡのアップリンク送信で使用する帯域は、トリガーフレームを送信した帯域であり、アップリンク送信の帯域が２０ＭＨｚの場合、これはトリガーフレームを送信した帯域と同じである。アップリンク送信の帯域が４０ＭＨｚの場合、トリガーフレームの送信は、当該４０ＭＨｚ内の２つの２０ＭＨｚ幅チャネルでそれぞれ送信してもよい。また、アップリンク送信の帯域が８０ＭＨｚの場合、トリガーフレームの送信は、当該８０ＭＨｚ内の４つの２０ＭＨｚ幅チャネルでそれぞれ送信してもよい。これらの様子を図１９に示す。トリガーフレームの内容はすべて同じでよい。ステップＳ１０５の後、ステップＳ１０１またはＳ１０２に戻ってもよい。
【０１３４】
一方、基地局は、グループ指定方式を決定した場合は、接続中のＯＦＤＭＡ対応端末を分類して生成した１つ以上のグループの中から、今回ＵＬ−ＯＦＤＭＡを許容するグループを選択する（Ｓ１０６）。グループを選択する方法は、どのような方法でもかまわない。例えば事前に各端末からＵＬ−ＯＦＤＭＡの要求有無を収集し、要求有りの端末を含むグループを選択してもよい。または、各端末における送信用のデータ量に基づき、データ量が最も大きい端末を含むグループを選択してもよいし、データ量が同じくらいの端末が最も多く存在するグループを選択してもよい。または、ラウンドロビンでグループを選択してもよいし、ランダムでグループを選択してもよい。または、次に送信するデータのサイズが同じ、または近いと推定されるデータを有する端末が最も多く存在するグループを選択、またはデータの発生周期が同じ、または発生周期が近い端末（発生周期が一定値以内に含まれる端末、または発生周期が最も近い所定数の端末など）が最も多いグループを選択することも可能である。なお、選択するグループはここでは１つを想定するが、前述したように複数のグループを選択することも可能である。ここで述べたグループの選択例は一例に過ぎず、ここで述べた以外の方法でグループを選択してもよい。
【０１３５】
なお、ＵＬ−ＯＦＤＭＡのアップリンク送信で使用する帯域は、事前にシステムまたは仕様で決められていても良いし、基地局でＵＬ−ＯＦＤＭＡを行う際に決定してもよい。
あるいは、ここで述べた以外の方法で決定してもよい。
【０１３６】
基地局は、選択したグループのグループＩＤを、トリガーフレームの所定のフィールドに設定する（Ｓ１０７）。所定のフィールドは、使用するフォーマットおよびその使用形態に依存し、例えば図１０のフォーマットの場合のＲＡフィールド（Ａｄｄｒｅｓｓ１フィールド）である。また、Ａｄｄｒｅｓｓ２フィールドには、自局のＭＡＣアドレス（ＢＳＳＩＤ）のＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットを０から１に反転したものを設定する。またフレームコントロールフィールドのタイプフィールドおよびサブタイプフィールドには、トリガーフレーム用の値を設定してもよい。ここで述べた以外の方法で設定してもよいし、図１０以外のフォーマットを利用してもよい。詳細は前述したため、これ以上の説明は省略する。また、基地局は、使用する帯域を識別する情報をトリガーフレーム内（例えば図１１のＨＥ  Ｃｏｎｔｒｏｌフィールドなど）に設定してもよいし、事前に別のフレームで通知してもよいし、使用する帯域はシステムまたは仕様で事前に決められていてもよい。あるいは、使用する帯域の通知は、トリガーフレームを受信するチャネル（帯域）に応じて黙示に通知してもよい。例えばアップリンク送信で２０ＭＨｚ幅の基本幅のチャネルを使用するときは、前述した図１９に示すように、当該チャネルでトリガーフレームを送信し、４０ＭＨｚ幅のチャネルを使用するときは、当該４０ＭＨｚに含まれる２０ＭＨｚ幅の２つのチャネルのそれぞれでトリガーフレームを送信し、８０ＭＨｚ幅のチャネルを使用するときは、当該８０ＭＨｚに含まれる２０ＭＨｚ幅の４つのチャネルのそれぞれでトリガーフレームを送信する。受信側の端末はトリガーフレームを受信したチャネル（帯域）でアップリンク送信可能であると判断する。なお、端末側では一部のチャネルではトリガーフレームの受信に成功したが、別のチャネルでは受信に失敗した場合、受信に成功したチャネル（帯域）のみに含まれるリソースユニットを選択するように、選択するリソースユニットを制限するようにしてもよい。
【０１３７】
基地局は、トリガーフレームを生成したら、ＣＳＭＡ／ＣＡに従って無線媒体へアクセス権を獲得し、獲得したアクセス権に基づき、トリガーフレーム（より詳細にはトリガーフレームを含む物理パケット）を送信する（Ｓ１０５）。ステップＳ１０５の詳細は上述した通りである。ステップＳ１０５の後、ステップＳ１０１またはＳ１０２に戻ってもよい。
【０１３８】
図１８のグループ指定方式の説明ではグループを選択する他、端末の選択とリソースユニットの割り当てを行ってもよい。この場合、トリガーフレームにはグループＩＤを設定するとともに、選択した端末の識別子（ＡＩＤ等）と当該リソースユニットの識別子との組を設定することで、選択した端末には当該リソースユニットを指定してもよい。なお、選択する端末は、選択したグループに属する端末でもよいし、選択したグループ以外のグループから端末を選択してもよい。また、グループ内でＵＬ−ＯＦＤＭＡの実施を禁止する端末を選択し、選択した端末の識別子をトリガーフレームに設定することで、選択した端末にはリソースユニットの選択とアップリンク送信を行わせないようにしてもよい。ここで述べた動作はあくまで一例であり、前述した第１の例〜第１７の例およびこれらの組み合わせを実現するために様々な動作の変形が可能である。
【０１３９】
図２０に、本発明の実施形態に係る端末の動作の一例のフローチャートを示す。端末は、基地局から送信されるトリガーフレームを受信したら（Ｓ２０１）、トリガーフレームに設定されている情報に基づき、個々の端末を個別に指定する個別指定方式か、グループを指定するグループ指定方式のいずれが指定されているかを判断する（Ｓ２０２）。判断の方法はトリガーフレームのフォーマットおよびその使用方法に応じて異なるが、例えば、Ａｄｄｒｅｓｓ２フィールドのＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐビットが１のときは、グループ指定方式、０のときは個別指定方式と判断する。またはグループ指定方式か個別指定方式かを識別する情報を設定する所定のフィールドに基づいて判断する。ここで述べた以外の方法で判断を行う構成も可能である。詳細は前述した通りである。
【０１４０】
個別指定方式が指定されている場合（Ｓ２０２のＮＯ）、自端末がＵＬ−ＯＦＤＭＡの対象端末として指定されているかを判断する（Ｓ２０３）。例えばＡＩＤフィールドに自端末のＡＩＤが設定されている場合は、自端末が指定されていると判断する。自端末が指定されている場合、自端末に割り当てられたリソースユニットを特定する（Ｓ２０４）。
例えば自端末のＡＩＤが設定されているＡＩＤフィールドに対応するＲＵフィールドで指定されたリソースユニットを、自端末に割り当てられたリソースユニットとして特定する。端末は、アップリンク送信用のデータフレーム等のフレームを生成し、トリガーフレームの受信完了から一定時間後に、特定したリソースユニットで送信する（Ｓ２０５）。トリガーフレームで、送信パケット長（ＰＰＤＵ長）、ＭＣＳ等の条件が指定されている場合は、当該条件を満たすようにフレームの生成および送信を行う。
【０１４１】
一方、グループ指定方式が指定されている場合（Ｓ２０２のＹＥＳ）、トリガーフレームの所定フィールドからグループＩＤを読み出し、当該グループＩＤが示すグループに自端末が属しているかを判断する（Ｓ２０６）。グループＩＤが設定されている所定フィールドは、トリガーフレームのフォーマットおよびその使用方法に応じて異なるが、例えば、ＲＡフィールド（Ａｄｄｒｅｓｓ１フィールド）にグループＩＤが設定されている。または、グループＩＤがＡＩＤフィールドに設定される構成、または図１１のＨＥ  Ｃｏｎｔｒｏｌフィールドに設定される構成も可能である。詳細は前述した通りである。自端末が上記のグループに属している場合は、複数の候補となるリソースユニットの中からランダムにリソースユニットを選択する（Ｓ２０７）。ここでステップＳ２０６とステップＳ２０７の間で、リソースユニットの選択権があるかを判断してもよい。例えば、予めランダムに選択したバックオフカウンタ値から、利用候補となるリソースユニットの数を引き、０以下になった場合に選択権を獲得したとして、ステップＳ２０７に進む。一方、０より大きい場合は、選択権を獲得せず、本フローの動作を終了するか、ステップＳ２０１に戻る。複数の候補となるリソースユニットは、トリガーフレームのＲＵフィールド等で指定されている。また、トリガーフレームに複数のグループＩＤが設定され、グループＩＤごとに、異なる候補となるリソースユニットが指定されている場合は、自端末が属するグループＩＤに対応づけられた、候補となるリソースユニットを特定する。または、複数の候補となるリソースユニットは、システムまたは仕様等で予め決められていてもよい。または、複数の候補となるリソースユニットの集合を識別する識別情報がトリガーフレームに設定されている場合に、当該設定されている識別情報と、識別情報とリソースユニット群とを対応づけた対応情報（テーブル等）とから、候補となるリソースユニットを特定してもよい。当該対応情報は事前に基地局から通知されてもよい。ランダムに選択するリソースユニットの個数は事前に定められていても良いし、選択する個数を指定する情報がトリガーフレームに設定されていてもよい。端末は、アップリンク送信用のデータフレーム等のフレームを生成し、トリガーフレームの受信完了から一定時間後に、ランダムに選択したリソースユニットで送信する（Ｓ２０５）。トリガーフレームで、送信パケット長（ＰＰＤＵ長）、ＭＣＳ等の条件が指定されている場合は、当該条件を満たすようにフレームの生成および送信を行う。
【０１４２】
なお、ステップＳ２０２でグループＩＤが指定されていると判断された場合に、自端末が上記のグループに属するかを判断することに加え、自端末に対して個別にリソースユニットの指定があるかを確認する構成も可能である。この場合、端末は、上記のグループに属する場合でも当該指定されたリソースユニットを使用するものとする。換言すれば、他の端末は、当該端末に対して指定されたリソースユニットが存在するときは、当該リソースユニットを除く候補となるリソースユニットの中からランダムに選択を行うものとする。また自端末が当該グループに属する場合であっても、ＵＬ−ＯＦＤＭＡの禁止対象端末として指定されている場合は、リソースユニットの選択、およびアップリンク送信を行わないものとする。リソースユニット毎に禁止対象端末が指定されている場合は、ランダムにリソースユニットを選択する際、当該指定されたリソースユニット以外のリソースユニットからランダムに選択するものとする。これらの詳細は前述した通りである。ここで述べた動作はあくまで一例であり、前述した第１の例〜第１７の例およびこれらの組み合わせを実現するために様々な動作の変形が可能である。
【０１４３】
以上、本実施形態によれば、アップリンク要求の有無等が精度良く把握出来ている場合などは端末毎にリソースユニットを指定することで効率的な通信を行い、そうでないときは、端末群をグループＩＤにより指定することで、送信候補となる端末数を適度に抑制して、同じリソースユニットを複数の端末が同時に使用する可能性を低減し、これによりリソース効率の低下を抑制できる。また、パワーセーブをしている端末の存在有無や、アップリンク送信の要求有無等の把握が十分にできていない場合にＵＬ−ＯＦＤＭＡを実施する際、グループＩＤを指定することで、個々の端末を指定する場合よりも、リソース利用効率を高めることが期待できる。特にグループに属する端末数が、個別に指定する場合に指定する端末数よりも多い場合に、この効果は高くなると考えられる。ただし、端末数が多すぎるとリソースユニット内での端末間の衝突確率が増えるため、グループに属する端末数に比べて、リソースユニット数が十分に大きくなるように、グループに属する端末数とリソースユニット数間の関係を調整してもよい。一例として、同じグループＩＤに属する端末数に対し、リソースユニット数が十分に大きく取れるように、リソースユニット数を調整する。少なくともグループＩＤに属する端末数よりリソースユニット数を大きくする。例えば、２＾（グループＩＤに属する端末数）−１か、それより大きいリソースユニット数にしてもよい（例えば端末が１つのリソースユニットを選択する場合を想定している）。グループＩＤに属する端末数が４なら、リソースユニット数は１５（＝２＾４−１）以上となるように設定する。前述のように、同じグループに属する端末でリソースユニットにアクセスできる端末の数を制限するような他の手法と組み合わせるようにしてもよい。また本実施形態では個別指定方式とグループ指定方式とで同じフレームフォーマット（図１０など）を流用できる。
【０１４４】
なお、本実施形態では、同じフォーマットのトリガーフレームを複数の異なる形態（例えば端末ごとに個別にリソースユニットを指定する形態と、グループＩＤを指定して端末が使用するリソースユニットは端末側でランダムに選択させる形態）で使用することを示したが、トリガーフレームのフレームフォーマットが、いずれか１つの形態を有するのでも何ら問題ない。
【０１４５】
本実施形態における、グループＩＤで指定した端末がランダムに選択したリソースユニットを用いて送信を行う構成と、ＩＥＥＥ８０２．１１ａｈのＲｅｓｔｒｉｃｔｅｄ  Ａｃｃｅｓｓ  Ｗｉｎｄｏｗ  （ＲＡＷ）  ｏｐｅｒａｔｉｏｎの違いについて説明しておく。ＲＡＷ  ｏｐｅｒａｔｉｏｎでは、１つの時間スロットをリソースユニットとするときに、当該時間スロットに、端末を指定して割り当てるか、あるいはグループ識別子を割り当てる。各端末は時間スロット境界から、（端末が指定されている場合でも）ＣＳＭＡ／ＣＡをベースとするＥＤＣＡ（Ｅｎｈａｎｃｅｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｈａｎｎｅｌ  Ａｃｃｅｓｓ）でアクセスを試みる。一方、本実施形態は周波数領域上に複数のリソースユニットが用意され、それぞれに各々端末が指定されるか、あるいはグループ識別子に示されるグループ（複数の端末）がこれらのリソースユニットにまとめて割り当てられる。そして、各端末が周波数領域における複数のリソースユニットのうち１つをランダムに選択し、トリガーフレームの受信完了から固定時間後にフレームを送信する。従って、ＩＥＥＥ８０２．１１ａｈのＲＡＷ  ｏｐｅｒａｔｉｏｎではＣＳＭＡ／ＣＡをベースとするＥＤＣＡを行うことにより、各端末で衝突回避（ｃｏｌｌｉｓｉｏｎ  ａｖｏｉｄａｎｃｅ）機能が働くが、本実施形態では、この機能は働かない。従って、本実施形態では、できるだけ衝突の発生を回避させるべく、前述のように送信すると期待される端末の数に対し、周波数領域上のリソースユニットの数を調整することがより重要となる。また上述したグループＩＤは、一例であり、他の構成も可能である。例えばグループＩＤはマルチキャストアドレスでもよい。また、グループＩＤとして、ＡＩＤを用いることも可能である。その際、ＡＩＤとして、未使用の値、すなわちアソシエーションした端末に基地局が割り当てる従来用途としてＡＩＤ割り当て可能な範囲外の値（１〜２００７以外の値）を用いる。例えばＡＩＤ  ０を用いて、アソシエーションしていない端末群を指してもよい。
【０１４６】
（第２の実施形態）
図２１は、第２の実施形態に係る基地局（アクセスポイント）４００の機能ブロック図である。このアクセスポイントは、通信処理部４０１と、送信部４０２と、受信部４０３と、アンテナ４２Ａ、４２Ｂ、４２Ｃ、４２Ｄと、ネットワーク処理部４０４と、有線Ｉ／Ｆ４０５と、メモリ４０６とを備えている。アクセスポイント４００は、有線Ｉ／Ｆ４０５を介して、サーバ４０７と接続されている。通信処理部４０１は、第１の実施形態で説明したＭＡＣ処理部１０およびＭＡＣ／ＰＨＹ管理部６０と同様な機能を有している。
送信部４０２および受信部４０３は、第１の実施形態で説明したＰＨＹ処理部５０およびアナログ処理部７０と同様な機能を有している。ネットワーク処理部４０４は、第１の実施形態で説明した上位処理部９０と同様な機能を有している。ここで、通信処理部４０１は、ネットワーク処理部４０４との間でデータを受け渡しするためのバッファを内部に保有してもよい。このバッファは、ＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。
【０１４７】
ネットワーク処理部４０４は、通信処理部４０１とのデータ交換、メモリ４０６とのデータ書き込み・読み出し、および、有線Ｉ／Ｆ４０５を介したサーバ４０７との通信を制御する。ネットワーク処理部４０４は、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理やアプリケーション層の処理を行ってもよい。ネットワーク処理部の動作は、ＣＰＵ等のプロセッサによるソフトウェア（プログラム）の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。
【０１４８】
一例として、通信処理部４０１は、ベースバンド集積回路に対応し、送信部４０２と受信部４０３は、フレームを送受信するＲＦ集積回路に対応する。通信処理部４０１とネットワーク処理部４０４とが１つの集積回路（１チップ）で構成されてもよい。送信部４０２および受信部４０３のデジタル領域の処理を行う部分とアナログ領域の処理を行う部分とが異なるチップで構成されてもよい。また、通信処理部４０１が、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなど、ＭＡＣ層の上位の通信処理を実行するようにしてもよい。また、アンテナの個数はここでは４つであるが、少なくとも１つのアンテナを備えていればよい。
【０１４９】
メモリ４０６は、サーバ４０７から受信したデータや、受信部４０２で受信したデータの保存等を行う。メモリ４０６は、例えば、ＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。また、ＳＳＤやＨＤＤ、ＳＤカード、ｅＭＭＣ等であってもよい。メモリ４０６が、基地局４００の外部にあってもよい。
【０１５０】
有線Ｉ／Ｆ４０５は、サーバ４０７とのデータの送受信を行う。本実施形態では、サーバ４０７との通信を有線で行っているが、サーバ４０７との通信を無線で実行するようにしてもよい。この場合、有線Ｉ／Ｆ４０５の代わりに、無線Ｉ／Ｆを用いればよい。
【０１５１】
サーバ４０７は、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばＨＴＴＰサーバ（Ｗｅｂサーバ）、ＦＴＰサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。ＰＣやスマートフォン等のユーザが操作する通信装置でもよい。
【０１５２】
基地局４００のＢＳＳに属するＳＴＡが、サーバ４０７に対するデータの転送要求を発行した場合、このデータ転送要求に関するパケットが、基地局４００に送信される。基地局４００は、アンテナ４２Ａ〜４２Ｄを介してこのパケットを受信し、受信部４０３で物理層の処理等を、通信処理部４０１でＭＡＣ層の処理等を実行する。
【０１５３】
ネットワーク処理部４０４は、通信処理部４０１から受信したパケットの解析を行う。
具体的には、宛先ＩＰアドレス、宛先ポート番号等を確認する。パケットのデータがＨＴＴＰ  ＧＥＴリクエストのようなデータ転送要求である場合、ネットワーク処理部４０４は、このデータ転送要求で要求されたデータ（例えば、ＨＴＴＰ  ＧＥＴリクエストで要求されたＵＲＬに存在するデータ）が、メモリ４０６にキャッシュ（記憶）されているかを確認する。メモリ４０６には、ＵＲＬ（またはその縮小表現、例えばハッシュ値や、代替となる識別子）とデータとを対応づけたテーブルが格納されている。ここで、データがメモリ４０６にキャッシュされていることを、メモリ４０６にキャッシュデータが存在すると表現する。
【０１５４】
メモリ４０６にキャッシュデータが存在しない場合、ネットワーク処理部４０４は、有線Ｉ／Ｆを４０５介して、サーバ４０７に対してデータ転送要求を送信する。つまり、ネットワーク処理部４０４は、ＳＴＡの代理として、サーバ４０７へデータ転送要求を送信する。具体的には、ネットワーク処理部４０４は、ＨＴＴＰリクエストを生成し、ＴＣＰ／ＩＰヘッダの付加などのプロトコル処理を行い、パケットを有線Ｉ／Ｆ４０５へ渡す。
有線Ｉ／Ｆ４０５は、受け取ったパケットをサーバ４０７へ送信する。
【０１５５】
有線Ｉ／Ｆ４０５は、データ転送要求に対する応答であるパケットをサーバ４０７から受信する。ネットワーク処理部４０４は、有線Ｉ／Ｆ４０５を介して受信したパケットのＩＰヘッダから、ＳＴＡ宛のパケットであることを把握し、通信処理部４０１へパケットを渡す。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ〜４２Ｄから送信する。
ここで、ネットワーク処理部４０４は、サーバ４０７から受信したデータを、ＵＲＬ（またはその縮小表現）と対応づけて、メモリ４０６にキャッシュデータとして保存する。
【０１５６】
メモリ４０６にキャッシュデータが存在する場合、ネットワーク処理部４０４は、データ転送要求で要求されたデータをメモリ４０６から読み出して、このデータを通信処理部４０１へ送信する。具体的には、メモリ４０６から読み出したデータにＨＴＴＰヘッダ等を付加して、ＴＣＰ／ＩＰヘッダの付加等のプロトコル処理を行い、通信処理部４０１へパケットを送信する。このとき、一例として、パケットの送信元ＩＰアドレスは、サーバと同じＩＰアドレスに設定し、送信元ポート番号もサーバと同じポート番号（通信端末が送信するパケットの宛先ポート番号）に設定する。したがって、ＳＴＡから見れば、あたかもサーバ４０７と通信をしているかのように見える。通信処理部４０１はこのパケットに対するＭＡＣ層の処理等を、送信部４０２は物理層の処理等を実行し、ＳＴＡ宛のパケットをアンテナ４２Ａ〜４２Ｄから送信する。
【０１５７】
このような動作により、頻繁にアクセスされるデータは、メモリ４０６に保存されたキャッシュデータに基づいて応答することになり、サーバ４０７と基地局４００間のトラフィックを削減できる。なお、ネットワーク処理部４０４の動作は、本実施形態の動作に限定されるものではない。ＳＴＡの代わりにサーバ４０７からデータを取得して、メモリ４０６にデータをキャッシュし、同一のデータに対するデータ転送要求に対しては、メモリ４０６のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題はない。
【０１５８】
なお、本実施形態では、キャッシュ機能を備えた基地局について説明を行ったが、図２１と同じブロック構成で、キャッシュ機能を備えた端末（ＳＴＡ）を実現することもできる。この場合、有線Ｉ／Ｆ４０５を省略してもよい。（ここにバリエーションを記載）
（第３の実施形態）
図２２は、端末または基地局の全体構成例を示したものである。この構成例は一例であり、本実施形態はこれに限定されるものではない。端末または基地局は、１つまたは複数のアンテナ１〜ｎ（ｎは１以上の整数）と、無線ＬＡＮモジュール１４８と、ホストシステム１４９を備える。無線ＬＡＮモジュール１４８は、第１の実施形態に係る無線通信装置に対応する。無線ＬＡＮモジュール１４８は、ホスト・インターフェースを備え、ホスト・インターフェースで、ホストシステム１４９と接続される。接続ケーブルを介してホストシステム１４９と接続される他、ホストシステム１４９と直接接続されてもよい。また、無線ＬＡＮモジュール１４８が基板にはんだ等で実装され、基板の配線を介してホストシステム１４９と接続される構成も可能である。ホストシステム１４９は、任意の通信プロトコルに従って、無線ＬＡＮモジュール１４８およびアンテナ１〜ｎを用いて、外部の装置と通信を行う。通信プロトコルは、ＴＣＰ／ＩＰと、それより上位の層のプロトコルと、を含んでもよい。または、ＴＣＰ／ＩＰは無線ＬＡＮモジュール１４８に搭載し、ホストシステム１４９は、それより上位層のプロトコルのみを実行してもよい。この場合、ホストシステム１４９の構成を簡単化できる。本端末は、例えば、移動体端末、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等でもよい。
【０１５９】
図２３は、無線ＬＡＮモジュールのハードウェア構成例を示す。この構成は、無線通信装置が非基地局の端末および基地局のいずれに搭載される場合にも適用可能である。つまり、図１に示した無線通信装置の具体的な構成の一例として適用できる。この構成例では、少なくとも１本のアンテナ２４７を備える。複数のアンテナを備える場合、各アンテナに対応して、送信系統（２１６、２２２〜２２５）、受信系統（２３２〜２３５）、ＰＬＬ２４２、水晶発振器（基準信号源）２４３およびスイッチ２４５のセットが複数配置され、各セットがそれぞれ制御回路２１２に接続されてもよい。ＰＬＬ２４２または水晶発振器２４３またはこれらの両方は、本実施形態に係る発振器に対応する。
【０１６０】
無線ＬＡＮモジュール（無線通信装置）は、ベースバンドＩＣ（Ｉｎｔｅｇｒａｔｅｄ
Ｃｉｒｃｕｉｔ）２１１と、ＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）ＩＣ２２１と、バラン２２５と、スイッチ２４５と、アンテナ２４７とを備える。
【０１６１】
ベースバンドＩＣ２１１は、ベースバンド回路（制御回路）２１２、メモリ２１３、ホスト・インターフェース２１４、ＣＰＵ２１５、ＤＡＣ（Ｄｉｇｉｔａｌ  ｔｏ  Ａｎａｌｏｇ  Ｃｏｎｖｅｒｔｅｒ）２１６、およびＡＤＣ（Ａｎａｌｏｇ  ｔｏ  Ｄｉｇｉｔａｌ  Ｃｏｎｖｅｒｔｅｒ）２１７を備える。
【０１６２】
ベースバンドＩＣ２１１とＲＦ  ＩＣ２２１は同じ基板上に形成されてもよい。また、ベースバンドＩＣ２１１とＲＦ  ＩＣ２２１は１チップで構成されてもよい。ＤＡＣ２１６およびＡＤＣ２１７の両方またはいずれか一方が、ＲＦ  ＩＣ２２１に配置されてもよいし、別のＩＣに配置されてもよい。またメモリ２１３およびＣＰＵ２１５の両方またはいずれか一方が、ベースバンドＩＣとは別のＩＣに配置されてもよい。
【０１６３】
メモリ２１３は、ホストシステムとの間で受け渡しするデータを格納する。またメモリ２１３は、端末または基地局に通知する情報、または端末または基地局から通知された情報、またはこれらの両方を格納する。また、メモリ２１３は、ＣＰＵ２１５の実行に必要なプログラムを記憶し、ＣＰＵ２１５がプログラムを実行する際の作業領域として利用されてもよい。メモリ２１３はＳＲＡＭ、ＤＲＡＭ等の揮発性メモリでもよいし、ＮＡＮＤ、ＭＲＡＭ等の不揮発メモリでもよい。
【０１６４】
ホスト・インターフェース２１４は、ホストシステムと接続するためのインターフェースである。インターフェースは、ＵＡＲＴ、ＳＰＩ、ＳＤＩＯ、ＵＳＢ、ＰＣＩ  Ｅｘｐｒｅｓｓなど何でも良い。
【０１６５】
ＣＰＵ２１５は、プログラムを実行することによりベースバンド回路２１２を制御するプロセッサである。ベースバンド回路２１２は、主にＭＡＣ層の処理および物理層の処理を行う。ベースバンド回路２１２、ＣＰＵ２１５またはこれらの両方は、通信を制御する通信制御装置、または通信を制御する制御部に対応する。
【０１６６】
ベースバンド回路２１２およびＣＰＵ２１５の少なくとも一方は、クロックを生成するクロック生成部を含み、当該クロック生成部で生成するクロックにより、内部時間を管理してもよい。
【０１６７】
ベースバンド回路２１２は、送信するフレームに、物理層の処理として、物理ヘッダの付加、符号化、暗号化、変調処理など行い、例えば２種類のデジタルベースバンド信号（以下、デジタルＩ信号とデジタルＱ信号）を生成する。
【０１６８】
ＤＡＣ２１６は、ベースバンド回路２１２から入力される信号をＤＡ変換する。より詳細には、ＤＡＣ２１６はデジタルＩ信号をアナログのＩ信号に変換し、デジタルＱ信号をアナログのＱ信号に変換する。なお、直交変調せずに一系統の信号のままで送信する場合もありうる。複数のアンテナを備え、一系統または複数系統の送信信号をアンテナの数だけ振り分けて送信する場合には、アンテナの数に応じた数のＤＡＣ等を設けてもよい。
【０１６９】
ＲＦ  ＩＣ２２１は、一例としてＲＦアナログＩＣあるいは高周波ＩＣ、あるいはこれらの両方である。ＲＦ  ＩＣ２２１は、フィルタ２２２、ミキサ２２３、プリアンプ（ＰＡ）２２４、ＰＬＬ（Ｐｈａｓｅ  Ｌｏｃｋｅｄ  Ｌｏｏｐ：位相同期回路）２４２、低雑音増幅器（ＬＮＡ）、バラン２３５、ミキサ２３３、およびフィルタ２３２を備える。
これらの要素のいくつかが、ベースバンドＩＣ２１１または別のＩＣ上に配置されてもよい。フィルタ２２２、２３２は、帯域通過フィルタでも、低域通過フィルタでもよい。ＲＦ  ＩＣ２２１は、スイッチ２４５を介して、アンテナ２４７に結合されている。
【０１７０】
フィルタ２２２は、ＤＡＣ２１６から入力されるアナログＩ信号およびアナログＱ信号のそれぞれから所望帯域の信号を抽出する。ＰＬＬ２４２は、水晶発振器２４３から入力される発振信号を用い、発振信号を分周または逓倍またはこれらの両方を行うことで、入力信号の位相に同期した、一定周波数の信号を生成する。なお、ＰＬＬ２４２は、ＶＣＯ（Ｖｏｌｔａｇｅ  Ｃｏｎｔｒｏｌｌｅｄ  Ｏｓｃｉｌｌａｔｏｒ）を備え、水晶発振器２４３から入力される発振信号に基づき、ＶＣＯを利用してフィードバック制御を行うことで、当該一定周波数の信号を得る。生成した一定周波数の信号は、ミキサ２２３およびミキサ２３３に入力される。ＰＬＬ２４２は、一定周波数の信号を生成する発振器の一例に相当する。
【０１７１】
ミキサ２２３は、フィルタ２２２を通過したアナログＩ信号およびアナログＱ信号を、ＰＬＬ２４２から供給される一定周波数の信号を利用して、無線周波数にアップコンバートする。プリアンプ（ＰＡ）は、ミキサ２２３で生成された無線周波数のアナログＩ信号およびアナログＱ信号を、所望の出力電力まで増幅する。バラン２２５は、平衡信号（差動信号）を不平衡信号（シングルエンド信号）に変換するための変換器である。ＲＦ  ＩＣ２２１では平衡信号が扱われるが、ＲＦ  ＩＣ２２１の出力からアンテナ２４７までは不平衡信号が扱われるため、バラン２２５で、これらの信号変換を行う。
【０１７２】
スイッチ２４５は、送信時は、送信側のバラン２２５に接続され、受信時は、受信側のバラン２３４またはＲＦ  ＩＣ２２１に接続される。スイッチ２４５の制御はベースバンドＩＣ２１１またはＲＦ  ＩＣ２２１により行われてもよいし、スイッチ２４５を制御する別の回路が存在し、当該回路からスイッチ２４５の制御を行ってもよい。
【０１７３】
プリアンプ２２４で増幅された無線周波数のアナログＩ信号およびアナログＱ信号は、バラン２２５で平衡−不平衡変換された後、アンテナ２４７から空間に電波として放射される。
【０１７４】
アンテナ２４７は、チップアンテナでもよいし、プリント基板上に配線により形成したアンテナでもよいし、線状の導体素子を利用して形成したアンテナでもよい。
【０１７５】
ＲＦ  ＩＣ２２１におけるＬＮＡ２３４は、アンテナ２４７からスイッチ２４５を介して受信した信号を、雑音を低く抑えたまま、復調可能なレベルまで増幅する。バラン２３５は、低雑音増幅器（ＬＮＡ）２３４で増幅された信号を、不平衡−平衡変換する。ミキサ２３３は、バラン２３５で平衡信号に変換された受信信号を、ＰＬＬ２４２から入力される一定周波数の信号を用いてベースバンドにダウンコンバートする。より詳細には、ミキサ２３３は、ＰＬＬ２４２から入力される一定周波数の信号に基づき、互いに９０°位相のずれた搬送波を生成する手段を有し、バラン２３５で変換された受信信号を、互いに９０°位相のずれた搬送波により直交復調して、受信信号と同位相のＩ（Ｉｎ−ｐｈａｓｅ）信号と、これより９０°位相が遅れたＱ（Ｑｕａｄ−ｐｈａｓｅ）信号とを生成する。フィルタ２３２は、これらＩ信号とＱ信号から所望周波数成分の信号を抽出する。フィルタ２３２で抽出されたＩ信号およびＱ信号は、ゲインが調整された後に、ＲＦ  ＩＣ２２１から出力される。
【０１７６】
ベースバンドＩＣ２１１におけるＡＤＣ２１７は、ＲＦ  ＩＣ２２１からの入力信号をＡＤ変換する。より詳細には、ＡＤＣ２１７はＩ信号をデジタルＩ信号に変換し、Ｑ信号をデジタルＱ信号に変換する。なお、直交復調せずに一系統の信号だけを受信する場合もあり得る。
【０１７７】
複数のアンテナが設けられる場合には、アンテナの数に応じた数のＡＤＣを設けてもよい。ベースバンド回路２１２は、デジタルＩ信号およびデジタルＱ信号に基づき、復調処理、誤り訂正符号処理、物理ヘッダの処理など、物理層の処理等を行い、フレームを得る。ベースバンド回路２１２は、フレームに対してＭＡＣ層の処理を行う。なお、ベースバンド回路２１２は、ＴＣＰ／ＩＰを実装している場合は、ＴＣＰ／ＩＰの処理を行う構成も可能である。
【０１７８】
（第４の実施形態）
図２４（Ａ）及び図２４（Ｂ）は、それぞれ第４の実施形態に係る無線通信端末の斜視図である。図２４（Ａ）の無線通信端末はノートＰＣ３０１であり、図２４（Ｂ）の無線通信端末は移動体端末３２１である。それぞれ、端末（基地局を含む）の一形態に対応する。ノートＰＣ３０１及び移動体端末３２１は、それぞれ無線通信装置３０５、３１５を搭載している。無線通信装置３０５、３１５として、これまで説明してきた端末（基地局を含む）に搭載されていた無線通信装置を用いることができる。無線通信装置を搭載する無線通信端末は、ノートＰＣや移動体端末に限定されない。例えば、ＴＶ、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Ｗｅｂカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ／サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等にも搭載可能である。
【０１７９】
また、端末（基地局を含む）に搭載されていた無線通信装置は、メモリーカードにも搭載可能である。当該無線通信装置をメモリーカードに搭載した例を図２５に示す。メモリーカード３３１は、無線通信装置３５５と、メモリーカード本体３３２とを含む。メモリーカード３３１は、外部の装置（無線通信端末または基地局、またはこれらの両方等）との無線通信のために無線通信装置３３５を利用する。なお、図２５では、メモリーカード３３１内の他の要素（例えばメモリ等）の記載は省略している。
【０１８０】
（第５の実施形態）
第５の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、バス、プロセッサ部、及び外部インタフェース部を備える。プロセッサ部及び外部インタフェース部は、バスを介してバッファと接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。ファームウエアが動作するプロセッサ部は、本実施形態に係る通信処理装置または制御部の処理を行うプロセッサであってもよいし、当該処理の機能拡張または変更に係る処理を行う別のプロセッサであってもよい。ファームウエアが動作するプロセッサ部を、本実施形態に係る基地局あるいは無線通信ン端末あるいはこれらの両方が備えてもよい。または当該プロセッサ部を、基地局に搭載される無線通信装置内の集積回路、または無線通信端末に搭載される無線通信装置内の集積回路が備えてもよい。
【０１８１】
（第６の実施形態）  
第６の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、クロック生成部を備える。クロック生成部は、クロックを生成して出力端子より無線通信装置の外部にクロックを出力する。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側とを同期させて動作させることが可能となる。
【０１８２】
（第７の実施形態）  
第７の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、電源部、電源制御部、及び無線電力給電部を含む。電源制御部は、電源部と無線電力給電部とに接続され、無線通信装置に供給する電源を選択する制御を行う。このように、電源を無線通信装置に備える構成とすることにより、電源を制御した低消費電力化動作が可能となる。
【０１８３】
（第８の実施形態）  
第８の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、ＳＩＭカードを含む。ＳＩＭカードは、例えば、無線通信装置におけるＭＡＣ処理部１０、ＭＡＣ／ＰＨＹ管理部６０、または、制御部１１２と接続される。このように、ＳＩＭカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。
【０１８４】
（第９の実施形態）  
第９の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、動画像圧縮／伸長部を含む。動画像圧縮／伸長部は、バスと接続される。このように、動画像圧縮／伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長とを容易に行うことが可能となる。
【０１８５】
（第１０の実施形態）  
第１０の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、ＬＥＤ部を含む。ＬＥＤ部は、例えば、ＭＡＣ処理部１０、ＭＡＣ／ＰＨＹ管理部６０、送信処理回路１１３、受信処理回路１１４、制御部１１２の少なくとも１つと接続される。このように、ＬＥＤ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
【０１８６】
（第１１の実施形態）  
第１１の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、バイブレータ部を含む。バイブレータ部は、例えば、ＭＡＣ処理部１０、ＭＡＣ／ＰＨＹ管理部６０、送信処理回路１１３、受信処理回路１１４、制御部１１２の少なくとも１つと接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
【０１８７】
（第１２の実施形態）
第１２の実施形態では、上述したいずれかの実施形態に係る無線通信装置（基地局の無線通信装置または無線通信端末の無線通信装置、またはこれらの両方）の構成に加えて、ディスプレイを含む。ディスプレイは、図示しないバスを介して、無線通信装置のＭＡＣ処理部に接続されてもよい。このようにディスプレイを備える構成とし、無線通信装置の動作状態をディスプレイに表示することで、無線通信装置の動作状態をユーザに容易に通知することが可能となる。
【０１８８】
（第１３の実施形態）  
本実施形態では、［１］無線通信システムにおけるフレーム種別、［２］無線通信装置間の接続切断の手法、［３］無線ＬＡＮシステムのアクセス方式、［４］無線ＬＡＮのフレーム間隔について説明する。
［１］通信システムにおけるフレーム種別
一般的に無線通信システムにおける無線アクセスプロトコル上で扱うフレームは、前述したように、大別してデータ（ｄａｔａ）フレーム、管理（ｍａｎａｇｅｍｅｎｔ）フレーム、制御（ｃｏｎｔｒｏｌ）フレームの３種類に分けられる。これらの種別は、通常、フレーム間で共通に設けられるヘッダ部で示される。フレーム種別の表示方法としては、１つのフィールドで３種類を区別できるようにしてあってもよいし、２つのフィールドの組み合わせで区別できるようにしてあってもよい。ＩＥＥＥ８０２．１１規格では、フレーム種別の識別は、ＭＡＣフレームのフレームヘッダ部にあるＦｒａｍｅ  Ｃｏｎｔｒｏｌフィールドの中のＴｙｐｅ、Ｓｕｂｔｙｐｅという２つのフィールドで行う。データフレームか、管理フレームか、制御フレームかの大別はＴｙｐｅフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のＢｅａｃｏｎフレームといった識別はＳｕｂｔｙｐｅフィールドで行われる。
【０１８９】
管理フレームは、他の無線通信装置との間の物理的な通信リンクの管理に用いるフレームである。例えば、他の無線通信装置との間の通信設定を行うために用いられるフレームや通信リンクをリリースする（つまり接続を切断する）ためのフレーム、無線通信装置でのパワーセーブ動作に係るフレームがある。
【０１９０】
データフレームは、他の無線通信装置と物理的な通信リンクが確立した上で、無線通信装置の内部で生成されたデータを他の無線通信装置に送信するフレームである。データは本実施形態の上位層で生成され、例えばユーザの操作によって生成される。
【０１９１】
制御フレームは、データフレームを他の無線通信装置との間で送受（交換）する際の制御に用いられるフレームである。無線通信装置がデータフレームや管理フレームを受信した場合にその送達確認のために送信される応答フレームは、制御フレームに属する。応答フレームは、例えばＡＣＫフレームやＢｌｏｃｋＡＣＫフレームである。またＲＴＳフレームやＣＴＳフレームも制御フレームである。
【０１９２】
これら３種類のフレームは、物理層で必要に応じた処理を経て物理パケットとしてアンテナを経由して送出される。なお、ＩＥＥＥ８０２．１１規格（前述のＩＥＥＥ  Ｓｔｄ
８０２．１１ａｃ−２０１３などの拡張規格を含む）では接続確立の手順の１つとしてアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）プロセスがあるが、その中で使われるＡｓｓｏｃｉａｔｉｏｎ  ＲｅｑｕｅｓｔフレームとＡｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームが管理フレームであり、Ａｓｓｏｃｉａｔｉｏｎ  ＲｅｑｕｅｓｔフレームやＡｓｓｏｃｉａｔｉｏｎ  Ｒｅｓｐｏｎｓｅフレームはユニキャストの管理フレームであることから、受信側無線通信端末に応答フレームであるＡＣＫフレームの送信を要求し、このＡＣＫフレームは上述のように制御フレームである。
【０１９３】
［２］無線通信装置間の接続切断の手法
接続の切断（リリース）には、明示的な手法と暗示的な手法とがある。明示的な手法としては、接続を確立している無線通信装置間のいずれか一方が切断のためのフレームを送信する。ＩＥＥＥ８０２．１１規格ではＤｅａｕｔｈｅｎｔｉｃａｔｉｏｎフレームがこれに当たり、管理フレームに分類される。通常、接続を切断するフレームを送信する側の無線通信装置では当該フレームを送信した時点で、接続を切断するフレームを受信する側の無線通信装置では当該フレームを受信した時点で、接続の切断と判定する。その後、非基地局の無線通信端末であれば通信フェーズでの初期状態、例えば接続するＢＳＳ探索する状態に戻る。無線通信基地局がある無線通信端末との間の接続を切断した場合には、例えば無線通信基地局が自ＢＳＳに加入する無線通信端末を管理する接続管理テーブルを持っているならば当該接続管理テーブルから当該無線通信端末に係る情報を削除する。例えば、無線通信基地局が自ＢＳＳに加入する各無線通信端末に接続をアソシエーションプロセスで許可した段階で、ＡＩＤを割り当てる場合には、当該接続を切断した無線通信端末のＡＩＤに関連づけられた保持情報を削除し、当該ＡＩＤに関してはリリースして他の新規加入する無線通信端末に割り当てられるようにしてもよい。
【０１９４】
一方、暗示的な手法としては、接続を確立した接続相手の無線通信装置から一定期間フレーム送信（データフレーム及び管理フレームの送信、あるいは自装置が送信したフレームへの応答フレームの送信）を検知しなかった場合に、接続状態の切断の判定を行う。このような手法があるのは、上述のように接続の切断を判定するような状況では、接続先の無線通信装置と通信距離が離れて無線信号が受信不可あるいは復号不可になるなど物理的な無線リンクが確保できない状態が考えられるからである。すなわち、接続を切断するフレームの受信を期待できないからである。
【０１９５】
暗示的な方法で接続の切断を判定する具体例としては、タイマを使用する。例えば、送達確認応答フレームを要求するデータフレームを送信する際、当該フレームの再送期間を制限する第１のタイマ（例えばデータフレーム用の再送タイマ）を起動し、第１のタイマが切れるまで（つまり所望の再送期間が経過するまで）当該フレームへの送達確認応答フレームを受信しないと再送を行う。当該フレームへの送達確認応答フレームを受信すると第１のタイマは止められる。
【０１９６】
一方、送達確認応答フレームを受信せず第１のタイマが切れると、例えば接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマ（例えば管理フレーム用の再送タイマ）を起動する。第１のタイマと同様、第２のタイマでも、第２のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマが切れると接続が切断されたと判定する。接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。
【０１９７】
あるいは、接続相手の無線通信装置からフレームを受信すると第３のタイマを起動し、新たに接続相手の無線通信装置からフレームを受信するたびに第３のタイマを止め、再び初期値から起動する。第３のタイマが切れると前述と同様に接続相手の無線通信装置がまだ（通信レンジ内に）存在するか（言い換えれば、無線リンクが確保できているか）を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第２のタイマ（例えば管理フレーム用の再送タイマ）を起動する。この場合も、第２のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第２のタイマが切れると接続が切断されたと判定する。この場合も、接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。後者の、接続相手の無線通信装置がまだ存在するかを確認するための管理フレームは、前者の場合の管理フレームとは異なるものであってもよい。また後者の場合の管理フレームの再送を制限するためのタイマは、ここでは第２のタイマとして前者の場合と同じものを用いたが、異なるタイマを用いるようにしてもよい。
【０１９８】
［３］無線ＬＡＮシステムのアクセス方式
例えば、複数の無線通信装置と通信または競合することを想定した無線ＬＡＮシステムがある。ＩＥＥＥ８０２．１１無線ＬＡＮではＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃａｒｒｉｅｒ  Ａｖｏｉｄａｎｃｅ）をアクセス方式の基本としている。ある無線通信装置の送信を把握し、その送信終了から固定時間を置いて送信を行う方式では、その無線通信装置の送信を把握した複数の無線通信装置で同時に送信を行うことになり、その結果、無線信号が衝突してフレーム送信に失敗する。ある無線通信装置の送信を把握し、その送信終了からランダム時間待つことで、その無線通信装置の送信を把握した複数の無線通信装置での送信が確率的に分散することになる。よって、ランダム時間の中で最も早い時間を引いた無線通信装置が１つなら無線通信装置のフレーム送信は成功し、フレームの衝突を防ぐことができる。ランダム値に基づき送信権の獲得が複数の無線通信装置間で公平になることから、Ｃａｒｒｉｅｒ  Ａｖｏｉｄａｎｃｅを採用した方式は、複数の無線通信装置間で無線媒体を共有するために適した方式であるということができる。
【０１９９】
［４］無線ＬＡＮのフレーム間隔
ＩＥＥＥ８０２．１１無線ＬＡＮのフレーム間隔について説明する。ＩＥＥＥ８０２．１１無線ＬＡＮで用いられるフレーム間隔は、ｄｉｓｔｒｉｂｕｔｅｄ  ｃｏｏｒｄｉｎａｔｉｏｎ  ｆｕｎｃｔｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＤＩＦＳ）、ａｒｂｉｔｒａｔｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＡＩＦＳ）、ｐｏｉｎｔ  ｃｏｏｒｄｉｎａｔｉｏｎ  ｆｕｎｃｔｉｏｎ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＰＩＦＳ）、ｓｈｏｒｔ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＳＩＦＳ）、ｅｘｔｅｎｄｅｄ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＥＩＦＳ）、ｒｅｄｕｃｅｄ  ｉｎｔｅｒｆｒａｍｅ  ｓｐａｃｅ（ＲＩＦＳ）などがある。
【０２００】
フレーム間隔の定義は、ＩＥＥＥ８０２．１１無線ＬＡＮでは送信前にキャリアセンスアイドルを確認して開けるべき連続期間として定義されており、厳密な前のフレームからの期間は議論しない。従ってここでのＩＥＥＥ８０２．１１無線ＬＡＮシステムでの説明においてはその定義を踏襲する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＣＳＭＡ／ＣＡに基づくランダムアクセスの際に待つ時間を固定時間とランダム時間との和としており、固定時間を明確にするため、このような定義になっているといえる。
【０２０１】
ＤＩＦＳとＡＩＦＳとは、ＣＳＭＡ／ＣＡに基づき他の無線通信装置と競合するコンテンション期間にフレーム交換開始を試みるときに用いるフレーム間隔である。ＤＩＦＳは、トラヒック種別による優先権の区別がないとき、ＡＩＦＳはトラヒック種別（Ｔｒａｆｆｉｃ  Ｉｄｅｎｔｉｆｉｅｒ：ＴＩＤ）による優先権が設けられている場合に用いる。
【０２０２】
ＤＩＦＳとＡＩＦＳとで係る動作としては類似しているため、以降では主にＡＩＦＳを用いて説明する。ＩＥＥＥ８０２．１１無線ＬＡＮでは、ＭＡＣ層でフレーム交換の開始などを含むアクセス制御を行う。さらに、上位層からデータを渡される際にＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）対応する場合には、データとともにトラヒック種別が通知され、トラヒック種別に基づいてデータはアクセス時の優先度のクラス分けがされる。このアクセス時のクラスをアクセスカテゴリ（Ａｃｃｅｓｓ  Ｃａｔｅｇｏｒｙ：ＡＣ）と呼ぶ。従って、アクセスカテゴリごとにＡＩＦＳの値が設けられることになる。
【０２０３】
ＰＩＦＳは、競合する他の無線通信装置よりも優先権を持つアクセスができるようにするためのフレーム間隔であり、ＤＩＦＳ及びＡＩＦＳのいずれの値よりも期間が短い。ＳＩＦＳは、応答系の制御フレームの送信時あるいは一旦アクセス権を獲得した後にバーストでフレーム交換を継続する場合に用いることができるフレーム間隔である。ＥＩＦＳはフレーム受信に失敗した（受信したフレームがエラーであると判定した）場合に起動されるフレーム間隔である。
【０２０４】
ＲＩＦＳは一旦アクセス権を獲得した後にバーストで同一無線通信装置に複数のフレームを連続して送信する場合に用いることができるフレーム間隔であり、ＲＩＦＳを用いている間は送信相手の無線通信装置からの応答フレームを要求しない。
【０２０５】
ここでＩＥＥＥ８０２．１１無線ＬＡＮにおけるランダムアクセスに基づく競合期間のフレーム交換の一例を図２６に示す。  
【０２０６】
ある無線通信装置においてデータフレーム（Ｗ＿ＤＡＴＡ１）の送信要求が発生した際に、キャリアセンスの結果、媒体がビジーである（ｂｕｓｙ  ｍｅｄｉｕｍ）と認識する場合を想定する。この場合、キャリアセンスがアイドルになった時点から固定時間のＡＩＦＳを空け、その後ランダム時間（ｒａｎｄｏｍ  ｂａｃｋｏｆｆ）空いたところで、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。なお、キャリアセンスの結果、媒体がビジーではない、つまり媒体がアイドル（ｉｄｌｅ）であると認識した場合には、キャリアセンスを開始した時点から固定時間のＡＩＦＳを空けて、データフレームＷ＿ＤＡＴＡ１を通信相手に送信する。
【０２０７】
ランダム時間は０から整数で与えられるコンテンションウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗ：ＣＷ）の間の一様分布から導かれる擬似ランダム整数にスロット時間をかけたものである。ここで、ＣＷにスロット時間をかけたものをＣＷ時間幅と呼ぶ。
ＣＷの初期値はＣＷｍｉｎで与えられ、再送するたびにＣＷの値はＣＷｍａｘになるまで増やされる。ＣＷｍｉｎとＣＷｍａｘとの両方とも、ＡＩＦＳと同様アクセスカテゴリごとの値を持つ。Ｗ＿ＤＡＴＡ１の送信先の無線通信装置では、データフレームの受信に成功し、かつ当該データフレームが応答フレームの送信を要求するフレームであるとそのデータフレームを内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ時間後に応答フレーム（Ｗ＿ＡＣＫ１）を送信する。Ｗ＿ＤＡＴＡ１を送信した無線通信装置は、Ｗ＿ＡＣＫ１を受信すると送信バースト時間制限内であればまたＷ＿ＡＣＫ１を内包する物理パケットの無線媒体上での占有終了時点からＳＩＦＳ時間後に次のフレーム（例えばＷ＿ＤＡＴＡ２）を送信することができる。
【０２０８】
ＡＩＦＳ、ＤＩＦＳ、ＰＩＦＳ及びＥＩＦＳは、ＳＩＦＳとスロット時間との関数になるが、ＳＩＦＳとスロット時間とは物理層ごとに規定されている。また、ＡＩＦＳ、ＣＷｍｉｎ及びＣＷｍａｘなどアクセスカテゴリごとに値が設けられるパラメータは、通信グループ（ＩＥＥＥ８０２．１１無線ＬＡＮではＢａｓｉｃ  Ｓｅｒｖｉｃｅ  Ｓｅｔ（ＢＳＳ））ごとに設定可能であるが、デフォルト値が定められている。
【０２０９】
例えば、８０２．１１ａｃの規格策定では、ＳＩＦＳは１６μｓ、スロット時間は９μｓであるとして、それによってＰＩＦＳは２５μｓ、ＤＩＦＳは３４μｓ、ＡＩＦＳにおいてアクセスカテゴリがＢＡＣＫＧＲＯＵＮＤ（ＡＣ＿ＢＫ）のフレーム間隔はデフォルト値が７９μｓ、ＢＥＳＴ  ＥＦＦＯＲＴ（ＡＣ＿ＢＥ）のフレーム間隔はデフォルト値が４３μｓ、ＶＩＤＥＯ（ＡＣ＿ＶＩ）とＶＯＩＣＥ（ＡＣ＿ＶＯ）のフレーム間隔はデフォルト値が３４μｓ、ＣＷｍｉｎとＣＷｍａｘとのデフォルト値は、各々ＡＣ＿ＢＫとＡＣ＿ＢＥとでは３１と１０２３、ＡＣ＿ＶＩでは１５と３１、ＡＣ＿ＶＯでは７と１５になるとする。なお、ＥＩＦＳは、基本的にはＳＩＦＳとＤＩＦＳと最も低速な必須の物理レートで送信する場合の応答フレームの時間長の和である。なお効率的なＥＩＦＳの取り方ができる無線通信装置では、ＥＩＦＳを起動した物理パケットへの応答フレームを運ぶ物理パケットの占有時間長を推定し、ＳＩＦＳとＤＩＦＳとその推定時間の和とすることもできる。
【０２１０】
本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置（ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラム可能論理回路（ＰＬＤ）などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、ＤＳＰおよびマイクロプロセッサの組み合わせ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサを指してもよい。
【０２１１】
別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。
【０２１２】
なお、各実施形態で述べるフレームは、例えばＩＥＥＥ８０２．１１規格でフレームと呼ばれているもののみならず、Ｎｕｌｌ  Ｄａｔａ  Ｐａｃｋｅｔなど、パケットと呼ばれているものを指してもよい。基地局が複数のフレームまたは複数の第Ｘフレームを送信または受信すると表現する場合、これらのフレームまたは第Ｘフレームは同じもの（例えば同じ種類または同じ内容）であっても異なるものであってもよい。Ｘには状況に応じて任意の値を入れることができる。また、これら複数のフレームまたは複数の第Ｘフレームは、同時に送信または受信されるもののみならず、時間的に異なるタイミングで送信または受信されるものであってもよい。また、第１フレーム，第２フレーム等を時間的に異なる時点で送信または受信すると表現する場合は、第１、第２等の表現は、単にフレームを区別するための表現に過ぎず、これらのフレームの種類・内容の異同は問わない。
【０２１３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０２１４】
以下、原出願の特許査定時における特許請求の範囲を付記する。
［項目１］
無線通信装置であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを送信する送信部と、
前記第１フレームに応答して送信される少なくとも１つの第２フレームを受信する受信部と、
を備え、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定され、前記第１グループ識別子は、前記無線通信装置に接続された少なくとも１台の第１無線通信端末を表し、前記第２グループ識別子は、前記無線通信装置に接続されていない少なくとも１台の第２無線通信端末を表し、  ランダムアクセス用のリソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記第１フレームは、
前記少なくとも１つの組の前記第１フィールドで指定されたグループ識別子の無線通信端末に第２フレームを送信するかどうかをランダムに決定させ、前記無線通信端末で前記第２フレームを送信することが決定された場合に、前記少なくとも１つの組において前記グループ識別子が設定された前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの少なくとも１つを介して、前記第２フレームを送信させる  無線通信装置。
［項目２］
前記無線通信装置は、ＩＥＥＥ８０２．１１規格に準拠しており、
前記第１無線通信端末は、前記無線通信装置によってＡＩＤを割り当てられた無線通信端末であり、
前記第２無線通信端末は、前記無線通信装置によってＡＩＤを割り当てられていない無線通信端末である
項目１に記載の無線通信装置。
［項目３］
前記第１グループ識別子及び前記第２グループ識別子は、ＩＥＥＥ８０２．１１規格において複数のＡＩＤのうち、前記無線通信装置に接続された無線通信端末に割り当てることが可能なＡＩＤ以外のＡＩＤの中から選択されており、
前記第１グループ識別子のＡＩＤと前記第２グループ識別子のＡＩＤは互いに異なる  項目１又は２に記載の無線通信装置。
［項目４］
前記第１グループ識別子のＡＩＤと前記第２グループ識別子のＡＩＤは、０又は２００７より大きい値から選択されている
項目２又は３に記載の無線通信装置。
［項目５］
少なくとも１つのアンテナをさらに備えた
項目１〜４のいずれか一項に記載の無線通信装置。
［項目６］
無線通信装置により実行する無線通信方法であって、
第１フィールドと第２フィールドとの少なくとも１つの組含む第１フレームを送信し、  前記第１フレームに応答して送信される少なくとも１つの第２フレームを受信し、  第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定され、前記第１グループ識別子は、前記無線通信装置に接続された少なくとも１台の第１無線通信端末を表し、前記第２グループ識別子は、前記無線通信装置に接続されていない少なくとも１台の第２無線通信端末を表し、  ランダムアクセス用のリソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記第１フレームは、前記少なくとも１つの組の前記第１フィールドで指定されたグループ識別子の無線通信端末に第２フレームを送信するかどうかをランダムに決定させ、前記無線通信端末で前記第２フレームを送信することが決定された場合に、前記少なくとも１つの組において前記グループ識別子が設定された前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの少なくとも１つを介して、前記第２フレームを送信させる
無線通信方法。
［項目７］
無線通信装置であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを受信する受信部と、
制御部と、
送信部とを、備え、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定されており、前記第１グループ識別子は、基地局に接続された少なくとも１台の第１無線通信端末を表し、前記第２グループ識別子は、前記基地局に接続されていない少なくとも１台の第２無線通信端末を表し、
ランダムアクセス用のリソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記制御部は、前記無線通信装置が前記基地局に接続されていない場合は、前記少なくとも１つの組において前記第２グループ識別子が設定された前記第１フィールドを特定し、前記無線通信装置が前記基地局に接続されている場合は、前記少なくとも１つの組において前記第１グループ識別子が設定された前記第１フィールドを特定し、
第２フレームを送信するかどうかをランダムに決定し、
前記送信部は、前記第２フレームを送信することが決定された場合に、前記少なくとも１つの組において、特定した前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの少なくとも１つを介して、前記第１フレームの受信から第１時間の経過後に、前記第２フレームを送信する、
無線通信装置。
［項目８］
少なくとも１つのアンテナをさらに備えた
項目７に記載の無線通信装置。
［項目９］
無線通信装置により実行される無線通信方法であって、
第１フィールドと第２フィールドとの少なくとも１つの組を含む第１フレームを受信し、
第１グループ識別子と第２グループ識別子とのうちの１つが選択的に前記少なくとも１つの組の前記第１フィールドに設定されており、前記第１グループ識別子は、基地局に接続された少なくとも１台の第１無線通信端末を表し、前記第２グループ識別子は、前記基地局に接続されていない少なくとも１台の第２無線通信端末を表し、
ランダムアクセス用のリソースユニットを指定する第１情報が、前記少なくとも１つの組の前記第２フィールドに設定され、
前記無線通信装置が前記基地局に接続されていない場合は、前記少なくとも１つの組において前記第２グループ識別子が設定された前記第１フィールドを特定し、前記無線通信装置が前記基地局に接続されている場合は、前記少なくとも１つの組において前記第１グループ識別子が設定された前記第１フィールドを特定し、
第２フレームを送信するかどうかをランダムに決定し、
前記第２フレームを送信することが決定された場合に、前記少なくとも１つの組において、特定した前記第１フィールドと対になる前記第２フィールドで指定されたリソースユニットの少なくとも１つを介して、前記第１フレームの受信から第１時間の経過後に、前記第２フレームを送信する、
無線通信方法。
【図１】
2020129804.tif 000003
【図２】
2020129804.tif 000004
【図３】
2020129804.tif 000005
【図４】
2020129804.tif 000006
【図５】
2020129804.tif 000007
【図６】
2020129804.tif 000008
【図７】
2020129804.tif 000009
【図８】
2020129804.tif 000010
【図９】
2020129804.tif 000011
【図１０】
2020129804.tif 000012
【図１１】
2020129804.tif 000013
【図１２】
2020129804.tif 000014
【図１３】
2020129804.tif 000015
【図１４】
2020129804.tif 000016
【図１５】
2020129804.tif 000017
【図１６】
2020129804.tif 000018
【図１７】
2020129804.tif 000019
【図１８】
2020129804.tif 000020
【図１９】
2020129804.tif 000021
【図２０】
2020129804.tif 000022
【図２１】
2020129804.tif 000023
【図２２】
2020129804.tif 000024
【図２３】
2020129804.tif 000025
【図２４】
2020129804.tif 000026
【図２５】
2020129804.tif 000027
【図２６】
2020129804.tif 000028