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