[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

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

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

Info

Publication number
JPWO2016088727A1
JPWO2016088727A1 JP2016562623A JP2016562623A JPWO2016088727A1 JP WO2016088727 A1 JPWO2016088727 A1 JP WO2016088727A1 JP 2016562623 A JP2016562623 A JP 2016562623A JP 2016562623 A JP2016562623 A JP 2016562623A JP WO2016088727 A1 JPWO2016088727 A1 JP WO2016088727A1
Authority
JP
Japan
Prior art keywords
integrated circuit
channel
information
wireless communication
frame
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.)
Pending
Application number
JP2016562623A
Other languages
English (en)
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
Original Assignee
Toshiba 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 filed Critical Toshiba Corp
Publication of JPWO2016088727A1 publication Critical patent/JPWO2016088727A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/20—Negotiating bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B17/00—Monitoring; Testing
    • H04B17/30—Monitoring; Testing of propagation channels
    • H04B17/309—Measuring or estimating channel quality parameters
    • H04B17/345—Interference values
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0037—Inter-user or inter-terminal allocation
    • H04L5/0039—Frequency-contiguous, i.e. with no allocation of frequencies for one user or terminal between the frequencies allocated to another
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0058—Allocation criteria
    • H04L5/0064—Rate requirement of the data, e.g. scalable bandwidth, data priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0091—Signaling for the administration of the divided path
    • H04L5/0092—Indication of how the channel is divided
    • 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
    • H04W48/10—Access restriction or access information delivery, e.g. discovery data delivery using broadcasted information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0001—Arrangements for dividing the transmission path
    • H04L5/0003—Two-dimensional division
    • H04L5/0005—Time-frequency
    • H04L5/0007—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0001—Arrangements for dividing the transmission path
    • H04L5/0014—Three-dimensional division
    • H04L5/0023—Time-frequency-space
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0453—Resources in frequency domain, e.g. a carrier in FDMA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Databases & Information Systems (AREA)

Abstract

【課題】システム全体でのチャネル利用効率を向上させる。【解決手段】本発明の一態様としての無線通信用集積回路は、ベースバンド集積回路を備える。前記ベースバンド集積回路は、ＲＦ集積回路を介して、所定のチャネルをベースに拡張して利用可能な最大の帯域幅よりも小さな第１帯域幅を指定する第１情報を送信し、前記ＲＦ集積回路を介して、前記最大の帯域幅で使用される複数のチャネルのうち、前記第１帯域幅で使用されるチャネルとは異なるチャネルを少なくとも１つ含む複数のチャネルを指定する第２情報を送信する。

Description

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

Claims (37)

  1. ＲＦ集積回路を介して、所定のチャネルをベースに拡張して利用可能な最大の帯域幅よりも小さな第１帯域幅を指定する第１情報を送信し、前記ＲＦ集積回路を介して、前記最大の帯域幅で使用される複数のチャネルのうち、前記第１帯域幅で使用されるチャネルとは異なるチャネルを少なくとも１つ含む複数のチャネルを指定する第２情報を送信する、ベースバンド集積回路
    を備えた無線通信用集積回路。
  2. 前記第１情報は、前記所定チャネルをベースに、指定された帯域幅まで使用するチャネル数を拡張して利用可能な第１無線通信装置に対する情報であり、
    前記第２情報は、指定された複数のチャネルを利用可能な第２無線通信装置に対する情報である
    請求項１に記載の無線通信用集積回路。
  3. 前記第２無線通信装置は、前記指定された複数のチャネルを、前記第１無線通信装置とは異なる単位で独立に利用可能な装置である
    請求項２に記載の無線通信用集積回路。
  4. 前記ベースバンド集積回路は、前記ＲＦ集積回路を介して、前記第１情報を第１フィールドに設定し、前記第２情報を第２フィールドに設定したフレームを送信する
    請求項１ないし３のいずれか一項に記載の無線通信用集積回路。
  5. 前記送信処理部は、前記ＲＦ集積回路を介して、前記第１情報を第１フィールドに設定した第１フレームを送信し、前記ＲＦ集積回路を介して、前記第２情報を第２フィールドに設定した第２フレームを送信する
    請求項１ないし３のいずれか一項に記載の無線通信用集積回路。
  6. 前記第２情報で指定する前記複数のチャネルは、前記最大の帯域幅で使用される前記チャネルのすべてを少なくとも含む
    請求項１ないし５のいずれか一項に記載の無線通信用集積回路。
  7. 前記第２情報は、前記複数のチャネルを、前記複数のチャネルのチャネル番号に基づき指定する
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  8. 前記第２情報は、予め定めたチャネルから周波数領域で連続する複数のチャネルを指定し、前記複数のチャネルのチャネル数または前記複数のチャネルに対応する帯域幅に関する情報を含む
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  9. 前記第２情報は、周波数領域で連続する複数のチャネルを指定し、前記連続する複数のチャネルの最小チャネル番号と最大チャネル番号を含む
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  10. 前記第２情報は、周波数領域で連続する複数のチャネルを指定し、前記連続する複数のチャネルのうち最小チャネル番号または最大チャネル番号と、前記連続する複数のチャネルのチャネル数または前記連続する複数のチャネルに対応する帯域幅に関する情報とを含む
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  11. 前記第２情報は、周波数領域で連続する複数のチャネルを指定し、前記複数のチャネルの中心周波数と、前記連続する複数のチャネルのチャネル数または前記連続する複数のチャネルに対応する帯域幅に関する情報とを含む
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  12. 前記連続する複数のチャネルが、前記周波数領域内で複数の分離した箇所に存在し、前記第２情報は、前記箇所ごとに前記連続する複数のチャネルを指定する
    請求項９ないし１１のいずれか一項に記載の無線通信用集積回路。
  13. 前記第２情報は、前記第２情報で指定する複数のチャネルに対応する帯域幅を前記第１情報で表現する場合の値と同じ値を有する情報である
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  14. 前記第２情報は、前記第１帯域幅で使用されるすべてのチャネルとは異なる別のチャネルを特定する情報を含み、前記第１帯域幅で使用される前記チャネルを特定する情報は含まない
    請求項１ないし６のいずれか一項に記載の無線通信用集積回路。
  15. 前記ベースバンド集積回路は、指定する帯域幅を前記最大の帯域幅よりも小さい前記第１帯域幅に制限するか否かを判断し、前記第１帯域幅に制限すると決定した場合に、前記第１情報を送信する
    請求項１ないし１４のいずれか一項に記載の無線通信用集積回路。
  16. 前記ベースバンド集積回路は、ＯＦＤＭＡ通信で使用される帯域幅もしくはシステムで使用される帯域幅と、前記最大の帯域幅との関係に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  17. 前記ベースバンド集積回路は、ユーザにより設定された情報に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  18. 前記ベースバンド集積回路は、自装置においてＯＦＤＭＡ通信の機能が有効か否かに基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  19. 前記ベースバンド集積回路は、前記第１情報の送信先となる第１無線通信装置により使用されている帯域幅に対応するチャネルの少なくとも１つにおける信号干渉の測定に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  20. 前記ベースバンド集積回路は、前記第１情報の送信先となる第１無線通信装置により使用されている帯域幅に対応するチャネルの少なくとも１つの利用頻度に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  21. 前記ベースバンド集積回路は、前記第１情報の送信先となる第１無線通信装置により使用されている帯域幅に対応するチャネルの少なくとも１つについて、ＯＦＤＭＡ用のＲＴＳフレームを送信するための送信権を獲得できた頻度に応じて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  22. 前記ベースバンド集積回路は、前記第１情報の送信先となる第１無線通信装置により使用されている帯域幅に対応するチャネルの少なくとも１つについて、ＯＦＤＭＡ用に送信したＲＴＳフレームに対するＣＴＳフレームの応答の頻度、またはＣＴＳフレームの応答に応じて前記ＯＦＤＭＡで送信したフレームの送信成功の頻度に応じて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  23. 前記ベースバンド集積回路は、前記第１情報の送信先となる第１無線通信装置の台数と、前記２情報の送信先となる第２無線通信装置の台数との関係に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  24. 前記第１情報の送信先は、利用可能な最大の帯域幅が第３帯域幅の第３無線通信装置と、利用可能な最大の帯域幅が前記第３帯域幅より大きい第４帯域幅の第４無線通信装置とであり、
    前記ベースバンド集積回路は、前記第４無線通信装置の台数と、前記第２無線通信装置の台数との関係に基づいて、前記第１帯域幅への制限の可否を判断する
    請求項１５に記載の無線通信用集積回路。
  25. 前記ベースバンド集積回路は、前記第１帯域幅への制限を行わないと判断した場合は、前記ＲＦ集積回路を介して、前記第１帯域幅より大きく前記最大の帯域幅以下の帯域幅を指定する第３情報を送信する
    請求項１５ないし２４のいずれか一項に記載の無線通信用集積回路。
  26. 無線通信基地局として動作する
    請求項１ないし２５のいずれか一項に記載の無線通信用集積回路。
  27. ＩＥＥＥ８０２．１１規格に従って通信する
    請求項１ないし２６のいずれか一項に記載の無線通信用集積回路。
  28. 前記第１情報の送信先となる第１無線通信装置は、ＩＥＥＥ８０２．１１ａｃまたはＩＥＥＥ８０２．１１ｎ対応の無線通信装置である
    請求項２７に記載の無線通信用集積回路。
  29. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路は、前記第１情報および前記第２情報をＤＡ変換し、
    前記ＲＦ集積回路は、ＤＡ変換後の前記第１情報および前記第２情報を無線周波数にアップコンバートする
    請求項１ないし２８のいずれか一項に記載の無線通信用集積回路。
  30. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路および前記ＲＦ集積回路が１つの集積回路で構成された
    請求項１ないし２９のいずれか一項に記載の無線通信用集積回路。
  31. ＲＦ集積回路を介して、所定のチャネルをベースに拡張して利用可能な最大の帯域幅よりも小さな帯域幅を指定する第１情報を受信し、
    前記ＲＦ集積回路を介して、前記最大の帯域幅で使用される複数のチャネルのうち、前記第１帯域幅で使用されるチャネルとは異なるチャネルを少なくとも１つ含む複数のチャネルを指定する第２情報を受信する、ベースバンド集積回路を備え、
    前記ベースバンド集積回路は、少なくとも前記第２情報に基づいて、使用する複数のチャネルを特定する、無線通信用集積回路。
  32. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路は、前記第１情報および前記第２情報をＡＤ変換し、
    前記ＲＦ集積回路は、ＡＤ変換後の前記第１情報および前記第２情報を無線周波数からベースバンドにダウンコンバートする
    請求項３１に記載の無線通信用集積回路。
  33. 所定のチャネルをベースに拡張して利用可能な最大の帯域幅よりも小さな第１帯域幅が他の装置に指定されている場合に、前記最大の帯域幅で使用される複数のチャネルのうち、前記第１帯域幅で使用されるチャネルとは異なるチャネルを少なくとも１つ含む複数のチャネルを指定する情報を、ＲＦ集積回路を介して、受信する、ベースバンド集積回路を備え、
    前記ベースバンド集積回路は、前記情報に基づいて、使用する複数のチャネルを特定する、無線通信用集積回路。
  34. 前記ベースバンド集積回路は、前記ＲＦ集積回路を介して、前記複数のチャネルを指定する前記情報と、前記第１帯域幅を指定する情報とを含むフレームを受信し、前記フレームから前記複数のチャネルを指定する前記情報を特定し、特定した情報に基づき、前記使用する複数のチャネルを特定する
    請求項３３に記載の無線通信用集積回路。
  35. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路は、前記情報をＡＤ変換し、
    前記ＲＦ集積回路は、ＡＤ変換後の前記情報を無線周波数からベースバンドにダウンコンバートする
    請求項３３または３４に記載の無線通信用集積回路。
  36. ＩＥＥＥ８０２．１１規格に従って通信する
    請求項３１ないし３５のいずれか一項に記載の無線通信用集積回路。
  37. 前記ＲＦ集積回路をさらに備え、
    前記ベースバンド集積回路および前記ＲＦ集積回路が１つの集積回路で構成された
    請求項３１ないし３６のいずれか一項に記載の無線通信用集積回路。
JP2016562623A 2014-12-01 2015-11-30 無線通信装置および無線通信方法 Pending JPWO2016088727A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014243502 2014-12-01
JP2014243502 2014-12-01
PCT/JP2015/083662 WO2016088727A1 (ja) 2014-12-01 2015-11-30 無線通信用集積回路

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018230336A Division JP6656348B2 (ja) 2014-12-01 2018-12-07 無線通信装置および無線通信方法

Publications (1)

Publication Number Publication Date
JPWO2016088727A1 true JPWO2016088727A1 (ja) 2017-07-20

Family

ID=56091669

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2016562623A Pending JPWO2016088727A1 (ja) 2014-12-01 2015-11-30 無線通信装置および無線通信方法
JP2018230336A Active JP6656348B2 (ja) 2014-12-01 2018-12-07 無線通信装置および無線通信方法
JP2020012393A Active JP6949156B2 (ja) 2014-12-01 2020-01-29 無線通信装置および無線通信方法

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2018230336A Active JP6656348B2 (ja) 2014-12-01 2018-12-07 無線通信装置および無線通信方法
JP2020012393A Active JP6949156B2 (ja) 2014-12-01 2020-01-29 無線通信装置および無線通信方法

Country Status (5)

Country Link
US (4) US10728802B2 (ja)
EP (1) EP3229543B1 (ja)
JP (3) JPWO2016088727A1 (ja)
CN (1) CN106664701B (ja)
WO (1) WO2016088727A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016088727A1 (ja) 2014-12-01 2016-06-09 株式会社 東芝 無線通信用集積回路
CN106688291B (zh) 2014-12-01 2020-06-09 株式会社东芝 无线通信装置以及无线通信方法
WO2016111264A1 (ja) * 2015-01-06 2016-07-14 シャープ株式会社 端末装置および基地局装置
US10966180B2 (en) 2015-07-07 2021-03-30 Kabushiki Kaisha Toshiba Wireless device and wireless communication method
KR102401468B1 (ko) * 2015-07-21 2022-05-24 삼성전자주식회사 무선통신 시스템에서 채널 선택 방법 및 장치
EP3657723B1 (en) 2015-10-30 2024-04-10 International Semiconductor Group Wireless communication device and wireless communication method
JP6619311B2 (ja) 2015-10-30 2019-12-11 株式会社東芝 無線通信装置および無線通信方法
EP3163965A1 (en) 2015-10-30 2017-05-03 Kabushiki Kaisha Toshiba Wireless communication terminal and wireless communication method
WO2017102036A1 (en) * 2015-12-18 2017-06-22 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for resource allocation in machine type communication devices
JP6402121B2 (ja) 2016-01-06 2018-10-10 株式会社東芝 無線通信装置および無線通信方法
US11778663B1 (en) * 2016-09-20 2023-10-03 Marvell Asia Pte, Ltd. Methods and systems for enabling communications from a station to an access point using a backoff counter and carrier sensing
CN106507289A (zh) * 2016-12-07 2017-03-15 广东欧珀移动通信有限公司 一种无线网络的接入方法及移动终端
CN109246755B (zh) * 2017-05-24 2021-12-07 瑞昱半导体股份有限公司 合作式服务集的网络主控装置与网络通信方法
CN109428747B (zh) * 2017-08-25 2022-03-04 展讯通信（上海）有限公司 本地振荡器带宽调整方法、接收机、计算机介质及系统
JP6911789B2 (ja) * 2018-02-13 2021-07-28 日本電信電話株式会社 無線通信システムおよび無線通信方法
JP6897604B2 (ja) * 2018-03-02 2021-06-30 日本電信電話株式会社 無線通信方法および基地局
US11297679B2 (en) * 2018-03-23 2022-04-05 Lg Electronics Inc. Method and apparatus for transmitting data over NCCB in wireless LAN system
US10673701B2 (en) * 2018-04-24 2020-06-02 Dell Products L.P. PHY ability auto-negotiation system
EP3817484A4 (en) * 2018-08-06 2021-09-08 Sony Group Corporation COMMUNICATION DEVICE
JP7062086B2 (ja) * 2018-11-27 2022-05-02 三菱電機株式会社 移動通信システムの無線局、及び移動通信システム
JP6701317B2 (ja) * 2018-12-25 2020-05-27 キヤノン株式会社 通信装置及びプログラム
JPWO2022195846A1 (ja) * 2021-03-19 2022-09-22

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013151847A2 (en) * 2012-04-04 2013-10-10 Qualcomm Incorporated Wireless channelization

Family Cites Families (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4266192B2 (ja) 2004-03-05 2009-05-20 株式会社東芝 無線通信装置及び無線通信方法
US8406331B2 (en) 2004-06-24 2013-03-26 Koninklijke Philips Electronics N.V. Method for signaling the status of a subcarrier in a MC network and a method for adaptively allocating the subcarriers in a MC network
JP4394590B2 (ja) * 2005-02-22 2010-01-06 株式会社日立コミュニケーションテクノロジー パケット中継装置および通信帯域制御方法
JP3762422B2 (ja) 2005-03-07 2006-04-05 富士通株式会社 通信システム
US7224938B2 (en) 2005-03-11 2007-05-29 Freescale Semiconductor Inc. Method of communicating with a network device
TWI259693B (en) 2005-04-27 2006-08-01 Inst Information Industry Contention window adjustment methods capable of load-adaptive backoff in a local area network and machine-readable storage medium therefor
JP4284354B2 (ja) 2006-12-26 2009-06-24 株式会社東芝 無線通信装置
US8363578B1 (en) * 2007-04-23 2013-01-29 Marvell International Ltd. Bandwidth selection method and apparatus
US8290503B2 (en) 2009-02-01 2012-10-16 Qualcomm Incorporated Multichannel dynamic frequency selection
US8559323B2 (en) 2010-03-10 2013-10-15 Cisco Technology, Inc. Downlink OFDMA for service sets with mixed client types
CN102687422B (zh) * 2010-06-29 2014-12-17 Lg电子株式会社 在wlan系统中发送数据帧的方法和装置
EP2589191B1 (en) * 2010-06-30 2016-01-06 Telefonaktiebolaget LM Ericsson (publ) Method for channel estimation using cell specific reference symbols
US8761689B2 (en) * 2010-07-09 2014-06-24 Blackberry Limited Methods and apparatus for use in communicating data which includes the selection of an RF channel for communications
EP2405699B1 (en) * 2010-07-09 2013-08-21 Research In Motion Limited Methods and apparatus for use in communicating data which includes the selection of an RF channel for communications
US9253128B2 (en) * 2010-10-06 2016-02-02 International Business Machines Corporation Instant messaging with browser collaboration
JP5472027B2 (ja) * 2010-10-15 2014-04-16 セイコーエプソン株式会社 無線通信装置およびそれを有する周辺装置
US9281928B2 (en) 2011-04-18 2016-03-08 Broadcom Corporation Range extension within single user, multiple user, multiple access, and/or MIMO wireless communications
WO2012148244A2 (en) * 2011-04-29 2012-11-01 Samsung Electronics Co., Ltd. Apparatus and method of resource allocation for data and control channels in a wireless communication system
US8811426B1 (en) 2011-05-06 2014-08-19 Marvell International Ltd. Method and apparatus for dynamically switching an operating bandwidth of a wireless transceiver
US9241287B2 (en) * 2011-09-13 2016-01-19 Qualcomm Incorporated Narrow bandwidth operation in LTE
JP2013219687A (ja) 2012-04-11 2013-10-24 Sharp Corp 無線通信装置、無線通信方法
EP3496491A1 (en) * 2012-07-19 2019-06-12 Nippon Telegraph and Telephone Corporation Wireless communication system and wireless communication method
CN104871620B (zh) * 2012-07-19 2019-04-16 日本电信电话株式会社 无线通信系统以及无线通信方法
WO2014027808A1 (en) 2012-08-13 2014-02-20 Lg Electronics Inc. Channelization method in whitespace band and apparatus for the same
US9301319B2 (en) 2013-01-14 2016-03-29 Qualcomm Incorporated Systems and methods for modifying carrier sense multiple access (CSMA) for dense networks
US9923822B2 (en) 2013-08-28 2018-03-20 Qualcomm Incorporated Methods and apparatus for multiple user uplink
US20160278081A1 (en) 2013-11-07 2016-09-22 Lg Electronics Inc. Method and device for receiving multiuser uplink in wireless lan
WO2015070230A1 (en) * 2013-11-11 2015-05-14 Marvell World Trade Ltd. Medium access control for multi-channel ofdm in a wireless local area network
US9825678B2 (en) 2013-11-26 2017-11-21 Marvell World Trade Ltd. Uplink multi-user multiple input multiple output for wireless local area network
CN112217624A (zh) * 2013-11-27 2021-01-12 马维尔亚洲私人有限公司 用于无线局域网的正交频分多址的通信方法和通信设备
CN104780618B (zh) 2014-01-13 2019-03-12 中兴通讯股份有限公司 利用码分复用的争用仲裁
EP3136807A4 (en) 2014-04-21 2017-12-20 Kabushiki Kaisha Toshiba Integrated circuit for radio communication
JP6454721B2 (ja) 2014-04-21 2019-01-16 株式会社東芝 無線通信装置および無線通信方法
WO2015163335A1 (ja) 2014-04-21 2015-10-29 株式会社 東芝 無線通信端末、メモリーカード、および無線通信方法
WO2015163480A1 (en) 2014-04-21 2015-10-29 Kabushiki Kaisha Toshiba Wireless communication terminal, memory card, wireless communication device and wireless communication method
US9819460B2 (en) 2014-07-04 2017-11-14 Newracom, Inc. Downlink physical layer protocol data unit format in a high efficiency wireless LAN
US10085258B2 (en) * 2014-07-04 2018-09-25 Newracom, Inc. Frame transmitting method and frame receiving method
CN106576102B (zh) 2014-08-10 2020-06-16 Lg 电子株式会社 在无线通信系统中使站能够接收信号的方法和设备
KR20160019383A (ko) * 2014-08-11 2016-02-19 뉴라컴 인코포레이티드 고효율 무선랜의 물리계층 프로토콜 데이터 유닛 포맷
WO2016028130A1 (en) 2014-08-22 2016-02-25 Samsung Electronics Co., Ltd. Apparatus and method for operating resource in wireless local area network system supporting multi-user transmission scheme
JP6594319B2 (ja) 2014-08-29 2019-10-23 株式会社東芝 無線通信装置
KR102438318B1 (ko) * 2014-10-10 2022-08-30 뉴라컴 인코포레이티드 고효율 무선랜에서 동적 자원 할당
US10531433B2 (en) 2014-10-29 2020-01-07 Qualcomm Incorporated Methods and apparatus for multiple user uplink access
US9980292B2 (en) 2014-10-29 2018-05-22 Mediatek Inc. Contention based uplink orthogonal frequency-division multiple access (OFDMA)
WO2016087917A1 (ko) * 2014-11-19 2016-06-09 뉴라컴 인코포레이티드 고효율 무선랜에서 bss 식별정보에 기초한 ppdu프로세싱 방법 및 장치
US9699807B2 (en) 2014-11-19 2017-07-04 Intel IP Corporation High-efficiency Wi-Fi (HEW) station and access point (AP) and method for random access contention
US10098151B2 (en) * 2014-11-26 2018-10-09 Newracom, Inc. Transmission method for multi user in wireless local area network
CN106688291B (zh) 2014-12-01 2020-06-09 株式会社东芝 无线通信装置以及无线通信方法
WO2016088727A1 (ja) 2014-12-01 2016-06-09 株式会社 東芝 無線通信用集積回路
WO2016090372A1 (en) 2014-12-05 2016-06-09 Marvell Semiconductor, Inc. Trigger frame format for orthogonal frequency division multiple access (ofdma) communication
US10091822B2 (en) 2014-12-23 2018-10-02 Mediatek Inc. Allocation of uplink resources in orthogonal frequency-division multiple access (OFDMA) wireless networks
WO2016105128A1 (ko) 2014-12-25 2016-06-30 엘지전자 주식회사 무선랜 시스템에서 상향링크 다중 사용자 데이터에 대한 확인응답 신호 송수신 방법 및 이를 위한 장치
KR102129283B1 (ko) 2014-12-31 2020-07-03 주식회사 윌러스표준기술연구소 다중 사용자 상향 전송을 위한 무선 통신 단말 및 무선 통신 방법
US9930695B2 (en) 2015-02-03 2018-03-27 Intel IP Corporation Orthogonal frequency-division multiple access distributed channel access
US10111258B2 (en) 2015-02-13 2018-10-23 Qualcomm Incorporated Methods and systems for receiver initiated protection of a wireless communication exchange
WO2016154818A1 (zh) 2015-03-27 2016-10-06 华为技术有限公司 多站点接入方法、装置及系统
US10531380B2 (en) 2015-04-09 2020-01-07 Lg Electronics Inc. Method and device for transmitting/receiving frame related to multi-user transmission in wireless LAN system
US10264602B2 (en) 2015-04-15 2019-04-16 Apple Inc. Controlled OFDMA random access
WO2016172620A1 (en) 2015-04-24 2016-10-27 Newracom, Inc. Preamble and payload for high efficiency (he) transmission
WO2016175328A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信装置
WO2016175329A1 (ja) 2015-04-30 2016-11-03 株式会社 東芝 無線通信端末および無線通信方法
US20160330722A1 (en) 2015-05-08 2016-11-10 Spreadtrum Hong Kong Limited Apparatus and method for providing a unifying identifier on wireless networks
WO2016186420A1 (ko) 2015-05-15 2016-11-24 주식회사 윌러스표준기술연구소 다중 사용자 상향 전송을 위한 무선 통신 단말 및 무선 통신 방법
CN107535006B (zh) 2015-05-27 2020-10-16 华为技术有限公司 一种信道接入方法及装置
US20160353435A1 (en) 2015-05-28 2016-12-01 Chittabrata Ghosh Random access with multiple time slots in a high efficiency wireless local-area network
US9955459B2 (en) 2015-06-05 2018-04-24 Intel IP Corporation Orthogonal frequency division multiple access uplink resource allocation
WO2016204574A1 (ko) 2015-06-17 2016-12-22 주식회사 윌러스표준기술연구소 복수의 무선 통신 단말로부터 데이터를 수신하는 무선 통신 방법 및 무선 통신 단말
GB2539693B (en) 2015-06-24 2019-06-19 Canon Kk Emission of a signal in unused resource units to increase energy detection of an 802.11 channel
CN107852745B (zh) 2015-07-02 2020-03-31 华为技术有限公司 关联的建立方法及装置
US10966180B2 (en) 2015-07-07 2021-03-30 Kabushiki Kaisha Toshiba Wireless device and wireless communication method
US10225866B2 (en) 2015-09-16 2019-03-05 Qualcomm Incorporated Systems, methods, and devices for enhanced OFDMA random access
EP3657723B1 (en) 2015-10-30 2024-04-10 International Semiconductor Group Wireless communication device and wireless communication method
JP2017085508A (ja) 2015-10-30 2017-05-18 株式会社東芝 無線通信システムおよび無線通信方法
EP3163965A1 (en) 2015-10-30 2017-05-03 Kabushiki Kaisha Toshiba Wireless communication terminal and wireless communication method
US20170188362A1 (en) 2015-12-26 2017-06-29 Intel IP Corporation Orthogonal frequency-division multiple (OFDM) access distributed channel access with uplink OFDM multiple input multiple output (MIMO)
JP6402121B2 (ja) 2016-01-06 2018-10-10 株式会社東芝 無線通信装置および無線通信方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013151847A2 (en) * 2012-04-04 2013-10-10 Qualcomm Incorporated Wireless channelization
JP2015515826A (ja) * 2012-04-04 2015-05-28 クアルコム，インコーポレイテッド ワイヤレスチャネライゼーション

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
IEEE STD 802.11AC-2013, JPN6018035246, 11 December 2013 (2013-12-11), pages pages 71, 91, 98-99, 186-187 *
IEEE STD 802.11N-2009, JPN6018035245, 29 October 2009 (2009-10-29), pages pages 56, 76-79 *

Also Published As

Publication number Publication date
EP3229543A4 (en) 2018-07-18
US20200314697A1 (en) 2020-10-01
US20220191741A1 (en) 2022-06-16
WO2016088727A1 (ja) 2016-06-09
CN106664701B (zh) 2020-10-09
US20170181039A1 (en) 2017-06-22
CN106664701A (zh) 2017-05-10
US20230397052A1 (en) 2023-12-07
JP6949156B2 (ja) 2021-10-13
JP6656348B2 (ja) 2020-03-04
US11778513B2 (en) 2023-10-03
JP2020080546A (ja) 2020-05-28
US10728802B2 (en) 2020-07-28
EP3229543A1 (en) 2017-10-11
US11297538B2 (en) 2022-04-05
JP2019083529A (ja) 2019-05-30
EP3229543B1 (en) 2021-05-05

Similar Documents

Publication Publication Date Title
JP6949155B2 (ja) 無線通信装置および無線通信方法
JP6949156B2 (ja) 無線通信装置および無線通信方法
JP2021193853A (ja) 無線通信装置および無線通信方法
JP2021193854A (ja) 無線通信装置及び無線通信方法
JP6619311B2 (ja) 無線通信装置および無線通信方法
JP2017085508A (ja) 無線通信システムおよび無線通信方法
JP2020129804A (ja) 無線通信装置および無線通信方法
JP2019193315A (ja) 無線通信装置および無線通信方法
JP2017085504A (ja) 無線通信端末および無線通信方法
JP2017085506A (ja) 無線通信端末および無線通信方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170228

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170228

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20170908

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20170912

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180604

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180907