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

無線通信装置および無線通信方法 Download PDF

Info

Publication number
JP6482653B2
JP6482653B2 JP2017515638A JP2017515638A JP6482653B2 JP 6482653 B2 JP6482653 B2 JP 6482653B2 JP 2017515638 A JP2017515638 A JP 2017515638A JP 2017515638 A JP2017515638 A JP 2017515638A JP 6482653 B2 JP6482653 B2 JP 6482653B2
Authority
JP
Japan
Prior art keywords
frame
terminal
terminals
base station
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017515638A
Other languages
English (en)
Other versions
JPWO2016175329A1 (ja
Inventor
足立　朋子
朋子 足立
綾子 松尾
綾子 松尾
旦代　智哉
智哉 旦代
浩樹 森
浩樹 森
谷口　健太郎
健太郎 谷口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Toshiba Electronic Devices and Storage Corp
Original Assignee
Toshiba Corp
Toshiba Electronic Devices and Storage Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp, Toshiba Electronic Devices and Storage Corp filed Critical Toshiba Corp
Publication of JPWO2016175329A1 publication Critical patent/JPWO2016175329A1/ja
Application granted granted Critical
Publication of JP6482653B2 publication Critical patent/JP6482653B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/06—Receivers
    • H04B1/16—Circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38—Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • H04B1/40—Circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/002—Transmission of channel access control information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/04—Scheduled or contention-free access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0808—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using carrier sensing, e.g. as in CSMA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Description

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

Claims (15)

  1. 第１フィールドを受信し、多重化して送信される複数の第２フィールドのうちの少なくとも１つを受信し、
    前記第１フィールドに自装置を特定する第１情報が設定されていない場合に、自装置に関するパラメータの値が第１値のときは、前記複数の第２フィールドのうちの１つを復号してフレームを取得し、前記パラメータの値が第２値のときは、前記複数の第２フィールドのいずれの復号も行わない、受信部と、
    前記フレームに設定されている値に示される期間の間、無線媒体へのアクセスを抑制するよう制御する制御部と、
    無線通信装置。
  2. 前記多重化は、少なくとも、周波数多重および空間多重のいずれか１つである
    請求項１に記載の無線通信装置。
  3. 前記第１フィールドは、複数の無線通信装置に共通のフィールドであり、
    前記複数の第２フィールドは、前記複数の無線通信装置のそれぞれの個別のフィールドである、
    請求項１または２に記載の無線通信装置。
  4. 前記第１フィールドは、前記複数の第２フィールドを各々の復号するための第２情報を含む
    請求項１ないし３のいずれか一項に記載の無線通信装置。
  5. 前記複数の第２フィールドは、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）で送信され、
    前記第２情報は、
    誤り訂正符号の方式に関する情報、
    前記複数の第２フィールドの送信に用いられている複数のリソースブロックを特定するための情報
    の少なくとも一方を含む
    請求項４に記載の無線通信装置。
  6. 前記複数のリソースブロックを特定するための情報は、前記複数のリソースブロックの個数に関する情報、前記複数のリソースブロック間のサブキャリア間隔に関する情報、および前記複数のリソースブロックの個々の識別子、のうち少なくとも１つを含む
    請求項５に記載の無線通信装置。
  7. 前記複数の第２フィールドはマルチユーザＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）で送信され、
    前記第２情報は、
    誤り訂正符号の方式に関する情報、
    ストリーム数に関する情報
    の少なくとも一方を含む
    請求項４に記載の無線通信装置。
  8. 前記複数の第２フィールドのそれぞれは、第３フィールドと第４フィールドとを含み、
    前記受信部は、前記複数の第２フィールドのうちの１つの前記第３フィールドから第３情報を取得し、前記第３情報に基づき前記第４フィールドを復号することで、前記第４フィールドから前記フレームを取得する
    請求項１ないし７のいずれか一項に記載の無線通信装置。
  9. 前記第３情報は、前記フレームに適用されている変調符号化方式に関する情報を含み、 前記受信部は、自装置が対応可能な変調符号化方式を設定している第３フィールドを特定し、特定した第３フィールドに設定されている前記変調符号化方式に基づいて前記第４フィールドを復号して前記フレームを取得する
    請求項８に記載の無線通信装置。
  10. 前記受信部は、前記自装置が対応可能な変調符号化方式を設定している前記第３フィールドが複数存在する場合は、符号化率または伝送レートが所定の条件を満たす変調符号化方式を設定している前記第３フィールドを特定し、特定した第３フィールドに設定されている変調符号化方式に基づき前記第４フィールドを復号して前記フレームを取得する
    請求項９に記載の無線通信装置。
  11. 前記複数の第２フィールドのそれぞれは、前記フレームが設定される第３フィールドと、値が設定される第４フィールドとを備え、
    前記受信部は、前記フレームから前記値を抽出する代わりに、複数の前記第４フィールドのうちの１つから前記値を抽出し、
    前記制御部は、前記抽出された値に示される期間の間、前記無線媒体へのアクセスを抑制するよう制御する
    請求項１に記載の無線通信装置。
  12. 前記第１フィールドに、前記フレーム毎の値が設定されており、
    前記受信部は、前記フレームから前記値を抽出する代わりに、前記第１フィールドから、前記フレーム毎の値のうちの１つを抽出し、
    前記制御部は、前記抽出された値に示される期間の間、前記無線媒体へのアクセスを抑制するよう制御する
    請求項１に記載の無線通信装置。
  13. 前記リソースブロックは、１つまたは複数のサブキャリアを含む
    請求項５または６に記載の無線通信装置。
  14. 前記制御部は、ＩＥＥＥ８０２．１１規格に従って通信を制御する
    請求項１ないし１３のいずれか一項に記載の無線通信装置。
  15. 無線通信装置による無線通信方法であって、
    第１フィールドを受信し、多重化して送信される複数の第２フィールドの少なくとも１つを受信し、
    前記第１フィールドに自装置を特定する第１情報が設定されていない場合に、自装置に関するパラメータの値が第１値のときは、前記複数の第２フィールドのうちの１つを復号してフレームを取得し、前記パラメータの値が第２値のときは、前記複数の第２フィールドのいずれの復号も行わず、
    前記フレームに設定されている値に示される期間の間、前記無線媒体へのアクセスを抑制するよう制御する
    無線通信方法。
JP2017515638A 2015-04-30 2016-04-28 無線通信装置および無線通信方法 Active JP6482653B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2015093442 2015-04-30
JP2015093442 2015-04-30
PCT/JP2016/063508 WO2016175329A1 (ja) 2015-04-30 2016-04-28 無線通信端末および無線通信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2019020903A Division JP6771605B2 (ja) 2015-04-30 2019-02-07 無線通信装置および無線通信方法

Publications (2)

Publication Number Publication Date
JPWO2016175329A1 JPWO2016175329A1 (ja) 2018-02-08
JP6482653B2 true JP6482653B2 (ja) 2019-03-13

Family

ID=57199139

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2017515638A Active JP6482653B2 (ja) 2015-04-30 2016-04-28 無線通信装置および無線通信方法
JP2019020903A Active JP6771605B2 (ja) 2015-04-30 2019-02-07 無線通信装置および無線通信方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2019020903A Active JP6771605B2 (ja) 2015-04-30 2019-02-07 無線通信装置および無線通信方法

Country Status (3)

Country Link
US (3) US10721747B2 (ja)
JP (2) JP6482653B2 (ja)
WO (1) WO2016175329A1 (ja)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016088726A1 (ja) 2014-12-01 2016-06-09 株式会社 東芝 無線通信端末及び無線通信方法
EP3229543B1 (en) 2014-12-01 2021-05-05 Kabushiki Kaisha Toshiba Wireless communication device
WO2016175329A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信端末および無線通信方法
WO2016175328A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信装置
US10966180B2 (en) 2015-07-07 2021-03-30 Kabushiki Kaisha Toshiba Wireless device and wireless communication method
JP6488206B2 (ja) 2015-07-08 2019-03-20 株式会社東芝 無線通信装置および無線通信方法
JP6628997B2 (ja) 2015-07-23 2020-01-15 株式会社東芝 無線通信装置および無線通信方法
US10291299B2 (en) 2015-09-07 2019-05-14 Kabushiki Kaisha Toshiba Wireless communication device
US10911185B2 (en) 2015-09-10 2021-02-02 Kabushiki Kaisha Toshiba Wireless communication device and wireless communication method
EP3163965A1 (en) 2015-10-30 2017-05-03 Kabushiki Kaisha Toshiba Wireless communication terminal and wireless communication method
US10368358B2 (en) 2015-10-30 2019-07-30 Kabushiki Kaisha Toshiba Wireless communication device and wireless communication method for providing opportunity of fair transmission to terminals
JP6619311B2 (ja) 2015-10-30 2019-12-11 株式会社東芝 無線通信装置および無線通信方法
JP7146398B2 (ja) * 2015-11-11 2022-10-04 ソニーグループ株式会社 通信装置および通信方法
US10524289B2 (en) 2015-12-25 2019-12-31 Kabushiki Kaisha Toshiba Wireless communication device
JP6402121B2 (ja) 2016-01-06 2018-10-10 株式会社東芝 無線通信装置および無線通信方法
JP6640670B2 (ja) 2016-07-15 2020-02-05 株式会社東芝 無線通信装置および無線通信方法
JP6761316B2 (ja) 2016-09-20 2020-09-23 株式会社東芝 無線通信装置および無線通信方法
JP6612702B2 (ja) 2016-09-20 2019-11-27 株式会社東芝 無線通信装置および無線通信方法
JP7077954B2 (ja) 2016-12-07 2022-05-31 ソニーグループ株式会社 通信装置、通信方法およびプログラム
CN111247710A (zh) * 2017-10-26 2020-06-05 松下电器（美国）知识产权公司 通信系统以及通信方法
US11102653B2 (en) * 2017-12-11 2021-08-24 Intel Corporation Protection from counterfeit ranging
CN110677871B (zh) * 2018-07-03 2022-07-12 华为技术有限公司 数据发送方法及发送设备、数据接收方法及接收设备
JP2020014102A (ja) * 2018-07-18 2020-01-23 富士通株式会社 送受信装置，送受信システム，送信装置および受信装置
US11095391B2 (en) * 2018-12-19 2021-08-17 Nxp Usa, Inc. Secure WiFi communication
JP7337101B2 (ja) * 2019-01-10 2023-09-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 基地局、端末及び通信方法
US20200267766A1 (en) * 2019-02-15 2020-08-20 Yongho Seok Signaling individualized transmission duration threshold for rts/cts
US11564272B2 (en) * 2019-03-08 2023-01-24 Qualcomm Incorporated Considerations for multi-link aggregation
EP3955675A1 (en) 2019-04-11 2022-02-16 Ntt Docomo, Inc. Base station device and user device
JP7392374B2 (ja) * 2019-10-08 2023-12-06 ヤマハ株式会社 無線送信装置、無線受信装置、無線システム及び無線送信方法
US11683767B2 (en) * 2020-05-12 2023-06-20 Qualcomm Incorporated Synchronization short inter-frame space (SIFS)
WO2022081025A1 (en) * 2020-10-12 2022-04-21 Goat Software Limited Data transmission system, communications adapter and method

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4005974B2 (ja) 2004-01-09 2007-11-14 株式会社東芝 通信装置、通信方法、および通信システム
WO2005071909A1 (en) 2004-01-26 2005-08-04 Samsung Electronics Co., Ltd. Method and apparatus for setting, transmitting and receiving data for virtual carrier sensing in wireless network communication
KR100586886B1 (ko) * 2004-08-13 2006-06-08 삼성전자주식회사 무선랜 통신 방법 및 장치
TWI487355B (zh) 2006-01-04 2015-06-01 內數位科技公司 Ｗｌａｎ系統中提供多模式有效率操作方法及系統
US8014818B2 (en) 2006-01-04 2011-09-06 Interdigital Technology Corporation Methods and systems for providing efficient operation of multiple modes in a WLAN system
US9203560B2 (en) 2008-04-04 2015-12-01 Qualcomm Incorporated Methods and apparatus for delayed block acknowledgement in a wireless local area network (WLAN)
US9197298B2 (en) 2009-06-05 2015-11-24 Broadcom Corporation Group identification and definition within multiple user, multiple access, and/or MIMO wireless communications
US8923172B2 (en) 2009-08-24 2014-12-30 Qualcomm Incorporated Deterministic backoff channel access
KR20110027533A (ko) * 2009-09-09 2011-03-16 엘지전자 주식회사 다중 안테나 시스템에서 제어정보 전송 방법 및 장치
US8774088B2 (en) 2010-04-01 2014-07-08 Intel Corporation Legacy operations in a MU MIMO wireless network
EP2561625B1 (en) 2010-04-19 2021-12-15 Samsung Electronics Co., Ltd. Method and system for multi-user transmit opportunity for multi-user multiple-input-multiple-output wireless networks
US8498245B2 (en) * 2010-05-15 2013-07-30 Ralink Technology Corp. Method of arranging packets in a wireless communication system and related device
US8411631B2 (en) 2010-06-11 2013-04-02 Intel Corporation Response mechanisms for wireless networks using wide bandwidth
US8989213B2 (en) 2010-09-15 2015-03-24 Qualcomm Incorporated Physical layer header with access point identifier
US8416799B2 (en) * 2011-05-05 2013-04-09 Hitachi, Ltd. Systems, methods and apparatuses for wireless communication
EP2820909B1 (en) 2012-03-01 2017-09-06 Interdigital Patent Holdings, Inc. Multi-user parallel channel access in wlan systems
US10932229B2 (en) 2012-04-30 2021-02-23 Interdigital Patent Holdings, Inc. Method and apparatus for supporting coordinated orthogonal block-based resource allocation (COBRA) operations
US9397805B2 (en) 2013-04-15 2016-07-19 Qualcomm Incorporated Systems and methods for backwards-compatible preamble formats for multiple access wireless communication
JP5653482B2 (ja) 2013-06-24 2015-01-14 株式会社東芝 無線通信装置および無線通信装置の制御方法
US10257806B2 (en) 2013-11-11 2019-04-09 Marvell World Trade Ltd. Medium access control for multi-channel OFDM in a wireless local area network
WO2015081288A1 (en) 2013-11-27 2015-06-04 Marvell Semiconductor, Inc. Medium access protection and bandwidth negotiation in a wireless local area network
US9717086B2 (en) 2013-11-27 2017-07-25 Marvell World Trade Ltd. Orthogonal frequency division multiple access for wireless local area network
US20150296454A1 (en) 2014-04-15 2015-10-15 Newracom, Inc. Method for low-power communications in wireless local area network and apparatus for the same
US10021722B2 (en) * 2014-06-08 2018-07-10 Lg Electronics Inc. Method and device for receiving frame in wireless LAN
US20170171878A1 (en) 2014-07-03 2017-06-15 Lg Electronics Inc. Method and device for transmitting uplink multi-user data in wireless communication system
KR20160019383A (ko) 2014-08-11 2016-02-19 뉴라컴 인코포레이티드 고효율 무선랜의 물리계층 프로토콜 데이터 유닛 포맷
JP6459015B2 (ja) 2015-01-08 2019-01-30 マーベル ワールド トレード リミテッド 方法および装置
WO2016175329A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信端末および無線通信方法
WO2016175328A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信装置

Also Published As

Publication number Publication date
JPWO2016175329A1 (ja) 2018-02-08
US20210112567A1 (en) 2021-04-15
JP6771605B2 (ja) 2020-10-21
JP2019075830A (ja) 2019-05-16
US10721747B2 (en) 2020-07-21
US20200260467A1 (en) 2020-08-13
US20180007701A1 (en) 2018-01-04
US10887895B2 (en) 2021-01-05
WO2016175329A1 (ja) 2016-11-03
US11627586B2 (en) 2023-04-11

Similar Documents

Publication Publication Date Title
JP6482653B2 (ja) 無線通信装置および無線通信方法
JP6482652B2 (ja) 無線通信装置および無線通信方法
JP6818830B2 (ja) 無線通信装置、無線通信端末および無線通信方法
JP6640670B2 (ja) 無線通信装置および無線通信方法
JP6402121B2 (ja) 無線通信装置および無線通信方法
JP6986052B2 (ja) 無線通信装置および無線通信方法
JP6568584B2 (ja) 無線通信装置、無線通信端末および無線通信方法
WO2016080335A1 (ja) 無線通信用集積回路、無線通信端末および無線通信方法
JP6876847B2 (ja) 無線通信装置および無線通信方法
JP2017085508A (ja) 無線通信システムおよび無線通信方法
JP2020014215A (ja) 無線通信装置
JP7146042B2 (ja) 無線通信装置および無線通信方法
JP2016213568A (ja) 無線通信用集積回路
JP7130090B2 (ja) 無線通信装置および無線通信方法
JP2017092686A (ja) 無線通信用集積回路、無線通信端末および無線通信方法
JP2017085506A (ja) 無線通信端末および無線通信方法
JP2017085504A (ja) 無線通信端末および無線通信方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170914

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20171113

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20171114

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180824

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181019

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181106

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190104

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190115

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190212

R150 Certificate of patent or registration of utility model

Ref document number: 6482653

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313117

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250