以下、図面を参照しながら、本発明の実施形態について、説明する。無線LANの規格として知られているIEEE Std 802.11TM−2012およびIEEE Std 802.11acTM−2013は、本明細書においてその全てが参照によって組み込まれる(incorporated by reference)ものとする。
以下、図面を参照しながら、本発明の実施形態について説明する。
(第1の実施形態)
図1に、第1の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局または無線通信基地局と通信する無線通信端末に実装されることができる。無線通信基地局(以下、基地局)も、中継機能を有する点を除き、無線通信端末(以下、端末)と同様の機能を有するため、端末の一形態である。本実施形態の機能は基本的に基地局及び非基地局の端末のどちらでも実現可能であり、以下の説明で端末と言うときは、特に両者を区別する必要がない限り、基地局も含んでもよい。
本実施形態では、基地局が複数のチャネルを非基地局の複数の端末に割り当て、複数端末宛て同時送信もしくは複数端末からの同時受信をするOFDMA (Orthogonal Frequency Division Multiple Access)通信を行う場合を想定する。本明細書において、このようなOFDMAの通信を、特に、Multi−User Multi−Channel (MU−MC)通信と表現する。但しサブキャリア単位(リソースユニット(RU))ベースで端末割り当てを行うOFDMAをIEEE802.11無線LANに適用した場合においても、CCA(Clear Channel Assessment)検出をMU−MCの場合と同様に基準チャネル幅(例えば20MHz)単位で行う場合には、以降に説明するMU−MCを想定した実施形態を、RUベースで端末割り当てを行うOFDMAにも適用することができる。その理由は、RUベースで端末割り当てを行うOFDMAでも、後方互換性を保つために従来のIEEE802.11無線LANが使用するのと同様のチャネル幅に従い(例えば20MHz用、40MHz用、80MHz用というように)、RU配分を決めると想定できるからである。但し、干渉を検出し使用するチャネル幅が変わると(例えば80MHzから40MHzに変更)、RUで使用するトーン数及び配置が変わることも考えられる。基地局から複数の端末へのダウンリンクのMU−MC送信は、ダウンリンクMU−MC(DL−MU−MC)送信、複数の端末から基地局へのアップリンクのMU−MC送信は、アップリンクMU−MC(UL−MU−MC)送信と呼ぶ。以下で、MU−MC通信と言うときは、主にDL−MU−MC通信を想定するが、本実施形態はUL−MU−MC通信の場合にも適用可能である。
本実施形態に係る基地局及び端末は、所定の周波数帯域(システムの動作周波数帯域)内の複数のチャネル(1つのチャネルは例えば20MHz幅など)ごとに、独立して信号を送受信可能である。このようにチャネルごとに信号を送受信できることで、効率的なMU−MC通信を行うことができる。このようにチャネルごとに独立して信号を送受信可能な方式に対応する端末を本実施形態では、MU−MC対応端末(IEEE802.11ax対応端末)と呼ぶことがある(サブキャリア単位(リソースユニット)ベースでの端末割り当てを行うOFDMAを想定する場合には、そのようなOFDMA対応端末をIEEE802.11ax対応端末とすればよい)。MU−MC対応端末は、チャネル単位でCCA(Clear Channel Assessment)を検出でき、干渉のない任意のチャネルで通信できることができる。基地局または端末は、必ずしも複数のチャネルのすべてについて個々に信号を送受信できる必要はなく、例えばチャネル1〜8があった場合に、チャネル1〜6についてはチャネルごとに信号が送受信可能であるが、チャネル7、8については、チャネル7,8をまとめたチャネルセットでのみで信号が送受信な形態であってもよい。この場合、チャネルセット単位でキャリアセンスのビジー・アイドルの判断を行うことが可能であるとする。
ここで、サブキャリア単位(リソースユニット)ベースでの端末割り当てを行うOFDMAについて説明しておく。リソースユニットベースのOFDMAでは、1つまたは複数のサブキャリアを含むリソースユニット(サブチャネル、リソースブロック、周波数ブロックなどと呼んでもよい)を、通信リソースとして端末に割り当て、リソースユニットベースで、複数の端末と同時に通信する。
リソースユニットは、通信を行うリソースの最小単位となる周波数成分である。図27に、1つのチャネル(ここではチャネルMと記述している)内の連続した周波数領域に確保したリソースユニット(RU#1、RU#2、・・・RU#K)を示す。チャネルMには、互いに直交する複数のサブキャリアが配置されており、1つまたは複数のサブキャリアを含む複数のリソースユニットがチャネルM内に定義されている。リソースユニット間には、1つ以上のサブキャリア(ガードサブキャリア)が配置されてもよいが、ガードサブキャリアは必須ではない。チャネル内の各リソースユニットまたは各サブキャリアは、リソースユニットまたはサブキャリアを識別するための識別情報が設定されていてもよい。1つのチャネルの帯域幅は、一例として、20MHz、40MHz、80MHz、160MHzなどであるが、これらに限定されない。20MHzの複数のチャネルをまとめて1つのチャネルとしてもよい。帯域幅に応じてチャネル内のサブキャリア数またはリソースユニット数が異なってもよい。複数の端末がそれぞれ異なるリソースユニットを同時に用いることで、OFDMA通信が実現される。
リソースユニットの帯域幅(あるいはサブキャリア数)は、各リソースユニットで共通でもよいし、リソースユニットごとに帯域幅(あるいはサブキャリア数)が異なってもよい。図28に、1つのチャネル内におけるリソースユニットの配置パターン例を模式的に示す。紙面に沿って横方向が周波数領域方向に対応する。図28(A)は、同じ帯域幅の複数のリソースユニット(RU#1、RU#2、・・・RU#K)を配置した例を示す。図28(B)は、図28(A)より大きな帯域幅の複数のリソースユニット(RU#11−1、RU#11−2、・・・、RU#11−L)を配置した例を示す。図28(C)は3種類以上の帯域幅のリソースユニットを配置した例を示す。リソースユニット(RU#12−1、RU#12−2)が最も大きな帯域幅を有し、リソースユニットRU#11−(L−1)は図28(B)のリソースユニットと同じ帯域幅、リソースユニット(RU#K−1、RU#K)は図28(A)のリソースユニットと同じ帯域幅である。
各端末がOFDMAで使用するリソースユニット数は、1つまたは複数であり、特定の値に制限されない。端末が複数のリソースユニットを用いる場合、周波数的に連続する複数のリソースユニットをボンディングして1つのリソースユニットとして用いてもよいし、離れた箇所にある複数のリソースユニットを用いることを許容してもよい。図28(B)のリソースユニット#11−1は、図28(A)のリソースユニット#1と#2をボンディングしたリソースユニットの一例と考えても良い。
1つのリソースユニット内のサブキャリアは周波数領域で連続していてもよいし、非連続に配置された複数のサブキャリアからリソースユニットを定義してもよい。OFDMAで使用するチャネルは1つに限定されず、チャネルMに加えて、周波数領域で離れた位置に配置された別のチャネル(図27のチャネルNを参照)内にも、チャネルMと同様にしてリソースユニットを確保し、チャネルMとチャネルNの両方内のリソースユニットを用いてもよい。チャネルMとチャネルNとでリソースユニットの配置方法は同じであっても、異なってもよい。1つのチャネルの帯域幅は、一例として、上述のように、20MHz、40MHz、80MHz、160MHzなどであるが、これらに限定されない。3つ以上のチャネルを用いることも可能である。なお、チャネルMとチャネルNをまとめて1つのチャネルとして考えることも可能である。
なお、OFDMAを実施する端末は、少なくとも後方互換の対象となるレガシー端末での基本チャネル幅(IEEE802.11a/b/g/n/ac規格対応端末をレガシー端末とするなら20MHzチャネル幅)のチャネルで、フレームを含む物理パケットを受信および復号(復調および誤り訂正符号の復号等を含む)できるものとする。キャリアセンスに関しては、基本チャネル幅の単位で行うものとする。
キャリアセンスは、CCA(Clear Channel Assessment)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)と、受信したフレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)との両方を包含してもよい。後者のように、仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、NAV(Network Allocation Vector)と呼ばれる。なお、チャネル単位で行ったCCAまたはNAVに基づくキャリアセンス情報は、チャネル内の全リソースユニットに共通に適用してもよい。例えばキャリアセンス情報がアイドルを示すチャネルに属するリソースユニットは、すべてアイドルと判断してもよい。
以上、図27および図28に基づきリソースユニットベースのOFDMAを説明したが、以降では、チャネルベースのOFDMA(MU−MC)を想定した実施形態を説明する。ただし、前述したように、CCAを基準チャネル幅(例えば20MHz)単位で行う場合には、当該MU−MCを想定した実施形態を、リソースユニットベースのOFDMAにも適用できる。
基地局は、上述したMU−MC対応端末以外にも、所定のチャネル(基準チャネル)をベースに、指定された帯域幅(チャネル幅)まで、使用するチャネル数を拡張して通信する端末の収容も想定する。このような端末を、基準チャネルからの拡張といった制約がなく、チャネル毎に独立して信号が送受信可能なMU−MC対応端末に対して、レガシー端末と呼ぶ。具体的に、レガシー端末としては、主にIEEE802.11n対応端末、802.11ac対応端末が想定される。
IEEE802.11ac対応端末は、基準チャネルをベースに、40MHz、80MHz、または160MHzにチャネル拡張して動作する機能を有する。160MHzへの拡張はオプションである。IEEE802.11n対応端末は、基準チャネルをベースに、40MHzまでチャネル拡張して動作可能である。40MHzへの拡張はオプションである。
図29及び図30に、IEEE802.11n規格及びIEEE802.11ac規格における基準チャネル及び拡張チャネルの例を示す。図29及び図30に示されるものは、IEEEの規格書から抜粋したものである。図29に示すように、基準となる20MHz幅のチャネル(primary)に対し、40MHzへのチャネル拡張の場合は、基準チャネル(primary)に加えて、それと連続した拡張チャネル(secondary)が用いられる。80MHzへのチャネル拡張の場合は、基準チャネル(primary)と拡張チャネル(secondary、primaryあるいはsecondaryと連続したsecondary40)が用いられる。160MHzへのチャネル拡張の場合は、基準チャネル(primary)と拡張チャネル(secondary、secondary40、secondary80)が用いられる。図29ではsecondary80はprimaryあるいはsecondaryあるいはsecondary40と連続した1つのチャネルの塊(セグメント)を構成するが、図30のように、secondary80が、primaryからsecondary40までの連続したチャネルの塊(セグメント)から離れて位置する構成もある。この場合のチャネル幅(帯域幅)を、160MHzチャネル幅を区別して、80+80MHzチャネル幅と呼ぶ。ただし、本実施形態で使用するチャネルには、IEEE802.11n規格の40MHzチャネル拡張(図29)や、IEEE802.11ac規格での80MHzや160MHzチャネル拡張(図29)や、IEEE802.11ac規格での80+80MHzチャネル拡張(図30)のように基準チャネルに対しての各拡張チャネルの拡張ルールを予め定義してあるという制限を設けなくてもよい。
上述したMU−MCシステムで利用する複数のチャネルは、例えば図29に示したような160MHzチャネル幅に対応する、8個の20MHz幅チャネルでもよいし、図30に示したような80+80MHzチャネル幅に対応する、8個の20MHz幅チャネルでもよい。または、これら8個のチャネルの一部(例えばprimaryとsecondary)または全部を含む、より多数(9個以上)の20MHz幅のチャネルでもよい。また、チャネル帯域幅は20MHzであることに制限されず、別のチャネル幅の単位でもよい。
図1に示されるように、端末(非基地局の端末及び基地局)に搭載される無線通信装置は、上位処理部90、MAC処理部10、PHY(Physical:物理)処理部50、MAC/PHY管理部60、アナログ処理部70(アナログ処理部1〜N)及びアンテナ80(アンテナ1〜N)を含む。Nは1以上の整数である。図では、N個のアナログ処理部と、N個のアンテナが、一対ずつ接続されているが、必ずしもこの構成に限定されるものではない。例えばアナログ処理部の個数が1つで、2つ以上のアンテナがこのアナログ処理部に共通に接続されてもよい。
MAC処理部10、MAC/PHY管理部60、及びPHY処理部50は、他の端末(基地局を含む)との通信に関する処理を行う制御部または無線通信用集積回路の一形態に相当する。アナログ処理部70は、例えばアンテナ80を介して信号を送受信する無線通信部またはRF(Radio Frequency)集積回路の一形態に相当する。本実施形態に係る無線通信用集積回路は、当該ベースバンド集積回路(制御部)およびRF集積回路の少なくとも前者を含む。ベースバンド集積回路の機能は、CPU等のプロセッサで動作するソフトウェア(プログラム)によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはROM、RAM等のメモリ、ハードディスク、SSDなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはSRAM、DRAM等の揮発性メモリでも、NAND、MRAM等の不揮発性メモリでもよい。
上位処理部90は、MAC(Medium Access Control:媒体アクセス制御)層に対して上位層のための処理を行う。上位処理部90は、MAC処理部10との間で信号をやり取りできる。上位層としては、代表的なものとしては、TCP/IPやUDP/IP、さらにその上層のアプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部90は、MAC層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。上位処理部90を介して有線インフラに接続するようになっていてもよい。
MAC処理部10は、MAC層のための処理を行う。前述のように、MAC処理部10は、上位処理部90との間で信号をやり取りできる。更に、MAC処理部10は、PHY処理部50との間で、信号をやり取りできる。MAC処理部10は、MAC共通処理部20と送信処理部30と受信処理部40を含む。
MAC共通処理部20は、MAC層での送受信に共通する処理を行う。MAC共通処理部20は、上位処理部90、送信処理部30、受信処理部40及びMAC/PHY管理部60と接続され、夫々との間で信号のやり取りをする。
送信処理部30及び受信処理部40は、相互に接続している。また、送信処理部30及び受信処理部40は、それぞれMAC共通処理部20及びPHY処理部50に接続している。送信処理部30は、MAC層での送信処理を行う。受信処理部40は、MAC層での受信処理を行う。
PHY処理部50は、PHY層のための処理を行う。前述のように、PHY処理部50は、MAC処理部10との間で信号をやり取りできる。PHY処理部50は、アナログ処理部70を介してアンテナ80に接続されている。
MAC/PHY管理部60は、上位処理部90、MAC処理部10(より詳細には、MAC共通処理部20)及びPHY処理部50の夫々と接続されている。MAC/PHY管理部60は、無線通信装置におけるMAC動作及びPHY動作を管理する。
アナログ処理部70は、アナログ/デジタル及びデジタル/アナログ(AD/DA)変換器やRF回路を含み、PHY処理部50からのデジタル信号を所望の周波数のアナログ信号に変換してアンテナ80から送信、またアンテナ80から受信した高周波のアナログ信号をデジタル信号に変換する。なお、ここでは、AD/DA変換をアナログ処理部70で行っているが、PHY処理部50にAD/DA変換機能を持たせる構成も可能である。
本実施形態に係る無線通信装置は、1チップ内にアンテナ80を構成要素として含む(一体化する)ことで、このアンテナ80の実装面積を小さく抑えることができる。更に、本実施形態に係る無線通信装置は、図1に示されるように、送信処理部30及び受信処理部40が、N本のアンテナ80を共用している。送信処理部30及び受信処理部40がN本のアンテナ80を共用することにより、図1の無線通信装置を小型化できる。なお、本実施形態に係る無線通信装置は、図1に例示されたものと異なる構成を備えても勿論よい。
無線媒体からの信号受信に際して、アナログ処理部70は、アンテナ80が受信したアナログ信号を、PHY処理部50が処理可能な基底帯域(Baseband)の信号に変換し、デジタル信号に変換する。PHY処理部50は、アナログ処理部70からデジタルの受信信号を受け取り、その受信レベルを検出する。検出した受信レベルを、キャリアセンスレベル(閾値)と比較し、受信レベルが、キャリアセンスレベル以上であれば、PHY処理部50は媒体(CCA:Clear Channel Assessment)がビジーであるということを示す信号を、MAC処理部10(より正確には、受信処理部40)へ出力する。受信レベルが、キャリアセンスレベル未満であれば、PHY処理部50は、媒体(CCA)がアイドルであるということを示す信号を、MAC処理部10(より正確には受信処理部40)へ出力する。
PHY処理部50は、受信信号に対し、復調処理、プリアンブル及びPHYヘッダを取り除く処理などを行って、ペイロードを抽出する。IEEE802.11規格ではこのペイロードをPHY側ではPSDU(physical layer convergence procedure (PLCP) service data unit)と呼んでいる。PHY処理部50は、抽出したペイロードを受信処理部40に渡し、受信処理部40はこれをMACフレームとして扱う。IEEE802.11規格では、このMACフレームを、MPDU(medium access control (MAC) protocol data unit)と呼んでいる。なお、A−MPDUを用いる場合の詳細は後述する。加えて、PHY処理部50は、受信信号を受信開始した際に、その旨を受信処理部40に通知し、また受信信号を受信終了した際に、その旨を受信処理部40に通知する。また、PHY処理部50は、受信信号が正常にPHYパケットとして復号できた場合(エラーを検出しなければ)、受信信号の受信終了を通知すると共に、媒体がアイドルであるということを示す信号を、受信処理部40に渡す。PHY処理部50は、受信信号にエラーを検出した場合には、エラー種別に即した適切なエラーコードをもって、受信処理部40にエラーを検出したことを通知する。また、PHY処理部50は、媒体がアイドルになったと判定した時点で、媒体がアイドルであることを示す信号を受信処理部40に通知する。
MAC共通処理部20は、上位処理部90から送信処理部30への送信データの受け渡し、及び受信処理部40から上位処理部90への受信データの受け渡しを、夫々仲介する。IEEE802.11規格では、このMACデータフレームの中のデータを、MSDU(medium access control (MAC) service data unit)と呼んでいる。なお、A−MSDUを用いる場合の詳細は後述する。また、MAC共通処理部20は、MAC/PHY管理部60からの指示を一旦受け取り、当該指示を送信処理部30及び受信処理部40に適したものに変換して出力する。
MAC/PHY管理部60は、例えばIEEE802.11規格におけるSME(Station Management Entity)に相当する。その場合、MAC/PHY管理部60とMAC共通処理部20との間のインタフェースは、IEEE802.11規格におけるMLME SAP(MAC subLayer Managament Entity Service Access Point)に相当し、MAC/PHY管理部60とPHY処理部50との間のインタフェースは、IEEE802.11無線LAN(Local Area Network)におけるPLME SAP(Physical Layer Management Entity Service Access Point)に相当する。
なお、図1において、MAC/PHY管理部60は、MAC管理のための機能部とPHY管理のための機能部とが一体であるかのように描かれているが、分けて実装されてもよい。
MAC/PHY管理部60は、管理情報ベース(Management Information Base:MIB)を保持する。MIBは、自端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、自端末が、MU−MU対応端末であるか否か、MU−MC方式への対応可否といった情報も保持されていてもよい。MIBを保持・管理するためのメモリは、MAC/PHY管理部60に内包させてもよいし、MAC/PHY管理部60に内包せずに別に設けるようにしてもよい。MIBを保持・管理するためのメモリをMAC/PHY管理部60とは別に設ける場合に、MAC/PHY管理部60は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。基地局では、他の非基地局としての各端末のこれらの情報も、これらの各端末からの通知により、取得することができる。その場合、MAC/PHY管理部60は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、MIBとは別に保持・管理するようにしてもよい。その場合、MAC/PHY管理部60あるいはMAC共通処理部20が、その別のメモリを参照・書き換えが可能なようにする。また基地局のMAC/PHY管理部60は、MU−MC通信にあたり、非基地局としての端末に関する各種の情報、または端末からの要求に基づき、MU−MC通信用のチャネルを同時に割り当てる端末を選定するグルーピング機能も備えていてもよい。
MAC処理部10は、データフレーム、制御フレーム及び管理フレームの3種類のMACフレームを扱い、MAC層において規定される各種処理を行う。ここで、3種類のMACフレームについて説明する。
管理フレームは、他の端末との間の通信リンクの管理のために用いられる。管理フレームとしては、例えば、IEEE802.11規格におけるBasic Service Set(BSS)である無線通信グループを形成するために、グループの属性及び同期情報を報知するビーコン(Beacon)フレームや、認証のためにまたは通信リンク確立のために交換されるフレームなどがある。なお、ある端末が、もう一台の端末と互いに無線通信を実施するために必要な情報交換を済ませた状態を、通信リンクが確立していると、ここでは表現する。必要な情報交換として、例えば、自端末が対応する機能の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部30が、MAC/PHY管理部60からMAC共通処理部20を介して受けた指示に基づいて生成する。
管理フレームに関連して、送信処理部30は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。非基地局としての端末の通知手段は、MU−MC対応端末、IEEE802.11n対応端末、IEEE802.11ac対応端末のいずれに対応しているかの情報を、管理フレームに入れて送信することで、基地局に自端末の種別を通知してもよい。この管理フレームとしては、例えば非基地局端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるAssociation
Requestフレームや、あるいはリアエソシエーションプロセスで用いられるReassociation Requestフレームがある。当該情報を管理フレームで送信するように当該通知手段を制御する通知制御手段が、MAC/PHY管理部60に備えられていてもよい。なお、基地局の通知手段は、非基地局の端末に、MU−MC通信への対応可否の情報を、管理フレームを介して通知してもよい。この管理フレームとしては、例えばBeaconフレームや、非基地局端末が送信したProbe Requestフレームに対する応答であるProbe Responseフレームがある。MAC/PHY管理部60は、これらの情報を管理フレームで送信するよう通知手段を制御する通知制御手段を備えてもよい。また、基地局は、自装置に接続している端末群をグループ化する機能を有し、上記の通知手段は、各端末にそれぞれ割り当てられたグループのグループIDを、管理フレームを介して通知してもよい。この管理フレームとしては、例えばGroup ID Managementフレームがある。MAC/PHY管理部60は、グループIDを管理フレームで送信するよう通知手段を制御する通知制御手段を備えてもよい。グループIDは、例えばIEEE Std 802.11ac−2013で規定されたグループIDでもよい。
また、受信処理部40は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、基地局の受信手段は、非基地局としての端末からMU−MC対応端末か否かの情報、レガシー端末(IEEE802.11n対応端末、IEEE802.11ac対応端末)の場合に対応可能なチャネル幅(利用可能な最大のチャネル幅)の情報を受信してもよい。なお、基地局または端末の受信手段は、端末または基地局からMU−MC通信への対応可否の情報を受信してもよい。
上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末(基地局を含む)間で送受信することが可能である。例えばMU−MC対応端末は、自身がMU−MC通信で使用を希望するチャネルを、キャリアセンスで非干渉のチャネルから選択して、選択したチャネルに関する情報を基地局に通知してもよい。この場合、基地局は、取得した情報に基づき、各MU−MC端末へMU−MC通信のためのチャネル割り当てを行ってもよい。なお、MU−MC通信で利用する複数のチャネルは、無線通信システムとして利用する全てのチャネルであっても、その一部の複数チャネルであってもよい。
データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、係るデータがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部90からMAC共通処理部20を介して送信処理部30に渡され、送信処理部30でデータをフレームボディフィールドに入れたデータフレームが生成され、PHY処理部50、アナログ処理部70及びアンテナ80を介して送信される。また、受信処理部40が、PHY処理部50を介してデータフレームを受信すると(受信したMACフレームがデータフレームであると把握すると)、そのフレームボディフィールドの情報をデータとして抽出し、MAC共通処理部20を介して上位処理部90に渡す。この結果、データの書き込み、再生などのアプリケーション上の動作が生じる。
制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信(交換)するときの制御のために用いられる。制御フレームとしては、例えば、管理フレーム及びデータフレームの交換を開始する前に、媒体を予約するために他の無線通信装置との間で交換するRTS(Request to Send)フレーム、CTS(Clear to Send)フレームなどがある。また、他の制御フレームの例として、受信した管理フレーム及びデータフレームの送達確認のために送信されるACK(Acknowledgement)フレーム、BA(BlockACK)フレームなどの送達確認応答フレームがある。これらの制御フレームも送信処理部30で生成される。CTSフレームやACKフレーム、BAフレームなど、受信したMACフレームへの応答として送信される制御フレームに関しては、受信処理部40で応答フレームの送信判断をして、フレーム生成に必要な情報(制御フレームの種別、RAフィールド等に設定する情報など)を送信指示とともに送信処理部30に出す。送信処理部30が、当該フレーム生成に必要な情報に基づき、適切な制御フレームを生成する。
MAC処理部10は、CSMA(Carrier Sense Multiple Access)に基づきMACフレームを送信する場合、媒体上でのアクセス権(送信権)を獲得する必要がある。送信処理部30は、受信処理部40からのキャリアセンス情報に基づいて、送信タイミングを計る。送信処理部30は、係る送信タイミングに従って、PHY処理部50に送信指示を与えて、MACフレームを渡す。送信指示に加えて、送信処理部30は、送信に使用される変調方式及び符号化方式を合わせて指示してもよい。これらに加えて、送信処理部30は、送信電力を指示してもよい。MAC処理部10は、アクセス権(送信権)獲得後、媒体を占有可能な時間(Transmission Opportunity;TXOP)が得られると、QoS(Quality of Service)属性などの制限を伴うものの、他の無線通信装置との間でMACフレームを連続して交換できる。TXOPは、例えば、無線通信装置がCSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)に基づき所定のフレーム(例えばRTSフレーム)を送信し、他の無線通信装置から応答フレーム(例えばCTSフレーム)を正しく受信した場合に、獲得される。この所定のフレームが、当該他の無線通信装置によって受信されると、当該他の無線通信装置は、最小フレーム間隔(Short InterFrame Space;SIFS)後に、上記応答フレームを送信する。また、RTSフレームを用いないでTXOPを獲得する方法として、例えば直接ユニキャストで送達確認応答フレームの送信を要求するデータフレーム(後述のようにフレームまたはペイロードが連接された形状のフレームであってもよい)あるいは管理フレームを送信し、それに対する送達確認応答フレーム(ACKフレームやBlockACKフレーム)を正しく受信する場合がある。あるいは、送達確認応答フレームの送信を要求しないフレームであって、そのフレームのDurationフィールド(後述する図7参照)に当該フレームを送信する以上の期間を設定したものを送信した場合には、当該フレームを送信した段階からDurationフィールドに記載された期間のTXOPを獲得したと解釈してもよい。
受信処理部40は、キャリアセンス情報を管理する。キャリアセンス情報は、例えばチャネルごとに(または前述したチャネルセットごとに)管理する。このキャリアセンス情報は、PHY処理部50から入力される媒体(CCA)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、IEEE802.11規格において、媒体予約時間は、MACヘッダの中のいわゆるDuration/IDフィールド(以下では単にDurationフィールドと記述)に記載される。MAC処理部10は、他の無線通信装置宛ての(自己宛てでない)MACフレームを受信した場合に、当該MACフレームを含むPHYパケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、NAV(Network Allocation Vector)と呼ばれる。
ここで、データフレームは、複数のMACフレームもしくは複数のMACフレームのペイロード部分を連接するようになっていてもよい。前者はIEEE802.11規格ではA(Aggregated)−MPDU、後者はA(Aggregated)−MSDU(MAC service data unit)と呼ばれる。A−MPDUの場合は、PSDUの中に複数のMPDUが連接されることになる。またデータフレームのみならず、管理フレームや制御フレームも連接対象となる。A−MSDUの場合には、1つのMPDUの中のフレームボディ中に複数のデータペイロードであるMSDUが連接されることになる。A−MPDU、A−MSDUいずれも連接を受信側端末で適切に分離できるように区切り情報(長さ情報など)が入れられている。A−MPDU、A−MSDUの両方を組み合わせて用いてもよい。またA−MPDUは区切り情報を入れて1つのMACフレームを入れるのみの構成であってもよい。また、データフレームがA−MPDUの場合などのように、複数のMACフレームに対する応答をまとめて送信する場合には、ACKフレームではなく、BA(BlockACK)フレームが用いられる。
IEEE802.11規格では、基地局が中心となり構成するBSS(これをインフラストラクチャ(Infrastructure)BSSと呼ぶ)に、非基地局の端末が加入し、BSS内でデータフレームの交換ができるようになるために経る手順(procedure)が、段階的に複数規定されている。例えば、アソシエーション(association)という手順があり、非基地局の端末から、当該端末が接続を要求する基地局に対して、アソシエーション要求(Association Request)フレームを送信する。基地局は、アソシエーション要求フレームに対するACKフレーム送信後、アソシエーション要求フレームに対する応答フレームのアソシエーション応答(Association Response)フレームを送信する。アソシエーション要求フレームに端末は自端末の能力(capability)を入れ、それを送信することで基地局に自端末の能力の通知をする。そこで例えば、端末はアソシエーション要求フレームの中に、自端末が対応可能なチャネル幅や、自端末が対応する規格を特定するための情報を入れて送信してもよい。当然、他の基地局へ再接続するための再アソシエーション(reassociation)という手順にもこの通知を入れるようにしてもよい。この手順では、非基地局の端末から、再接続を要求する他の基地局に対して、再アソシエーション要求(Reassociation Request)フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するACKフレーム送信後、再アソシエーション要求フレームに対する応答フレームの再アソシエーション応答(Reassociation Response)フレームを送信する。管理フレームとして、アソシエーション要求フレームや再アソシエーション要求フレーム以外にも、後述するように、ビーコンフレーム、プローブ応答(Probe Response)フレームなどを用いてもよい。ビーコンフレームは基本的に基地局が送信するもので、BSSの属性を示すパラメータとともに、基地局自身の能力を通知するパラメータも入れられる。そこで、この基地局自身の能力を通知するパラメータとして、基地局がMU−MC通信への対応可否の情報を加えるようにしてもよい。プローブ応答フレームは後述のようにビーコンフレームを送信する端末がプローブ要求(Probe Request)フレームを受信すると、送信するフレームである。プローブ応答フレームは、基本的にはビーコンフレームと同一の内容を通知するものであるため、これを用いても基地局はプローブ要求フレームを送信した端末に、MU−MC通信への対応可否を通知することができる。なお、本実施形態ではMU−MC通信を前提とし、それありきとする場合には、MU−MC通信への対応は自明の必須要件となるため、MU−MC通信への対応可否の通知は必須ではないが、MU−MC端末にはこの通知を行うことで、例えば送信フィルタまたは受信フィルタの設定といったMU−MC通信用の設定を行わせることも可能となる。
なお、上記で扱った情報のうち、他の情報を通知することで、その情報が必須となるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとMU−MC対応端末である、というのであれば、MU−MC対応端末であることの通知をしなくてもよい。
本実施形態では、基地局が、レガシー端末(IEEE802.11n対応端末、IEEE802.11ac端末)、及びMU−MC対応端末が共存することを想定した上で、MU−MC通信を高いチャネル効率を維持して行うことを実現することを特徴の1つとする。
図2に、本実施形態に従った基地局(AP:Access Point)100と、複数の非基地局である端末(STA:STAtion)101〜108とを備えた、無線通信システムあるいはBSS1を示す。複数の端末101〜108には、MU−MC対応端末と、レガシー端末(IEEE802.11n対応端末、IEEE802.11ac対応端末の少なくとも一方)が含まれる。
IEEE802.11acでは、帯域運用(bandwidth operation)の方法として、RTSフレーム及びCTSフレームの交換において、基準チャネルを基準に、干渉がないと判断した最大のチャネル幅で応答(CTSフレーム)を返すダイナミック(dynamic)と言われる方法と、RTSフレームの送信に使用された1つ以上のチャネルのいずれかで干渉があれば、いずれのチャネルでも応答(CRSフレーム)を返さないスタティック(static)と言われる方法がある。前者の方法による応答をダイナミック応答、後者の方法による応答をスタティック応答と呼ぶ。また、ダイナミック応答を行う端末を、ダイナミック動作端末、スタティック応答を行う端末をスタティック動作端末と呼ぶことがある。前述したように、IEEE802.11acでは、20MHz幅の基準チャネルをベースに、40MHz、80MHz、または160MHzにチャネル拡張することが規定されている。80MHzまでが対応必須であり、160MHzはオプションである。IEEE802.11nでは、20MHz幅の基準チャネルをベースに、40MHzにチャネル拡張することが規定されている。40MHzへの拡張はオプションである。以下、IEEE802.11ac対応端末を想定して、ダイナミック応答とスタティック応答について、具体例を用いて説明する。
図3は、RTSフレームの送信側がダイナミック動作端末、CTSフレームの送信側(RTSフレームの受信側)もダイナミック動作端末である場合の動作シーケンスの例を示す。一例として、RTSフレームの送信側がIEEE802.11ac対応基地局、CTSフレームの送信側がIEEE802.11ac対応端末である場合を想定する。この場合、ダイナミック動作するRTSフレームの送信側はMU−MC対応基地局であってもよい。なお、RTSフレームの送信側がダイナミック動作端末であるとは、当該ダイナミック動作端末が仮に他の端末からRTSフレームを受信した場合にダイナミック応答が可能で、またダイナミック応答のCTSフレームに合わせて動的にTXOPとして用いる占有チャネル幅を変更できる端末であることを意味する。
ここでは、複数のチャネルとして、チャネル番号(ch.#)が1〜4のチャネル(チャネル1〜4)が存在し、チャネル2が基準チャネルであるprimaryチャネル、チャネル1が secondaryチャネル、チャネル3及び4が、secondary40チャネルに対応するとする(前述した図29、図30参照)。無線通信システム(BSS)がCSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)を用いており、チャネル1〜4のチャネル毎に、基地局はキャリアセンスを実施できるとするが、非基地局としての端末は、ここでは802.11ac対応端末を想定しており、かつダイナミック動作すると想定しているので、primary、secondary、secondary40の単位でキャリアセンスを行う。基準チャネル(primary)は、物理的なキャリアセンスに加え、仮想キャリアセンスも実施するチャネルであり、拡張チャネル(secondary、secondary40)は、物理的なキャリアセンスのみを実施するチャネルでもよい。つまり、拡張チャネル側のキャリアセンス状態をモニターする実装負荷を軽減するために、拡張チャネル側のキャリアセンス状態をモニターする時間を制限してもよい。
図3では、横軸を時間に取り、チャネル1〜4のそれぞれでの送受信の状態を示してある。各横軸の上側に、当該基地局の送信状況、各横軸の下側に、当該基地局の受信状況を示している。ここでは、基地局(AP100)が、端末(例えばSTA108)にチャネル1〜4を用いて、RTSフレームを送信するとする。
ここでRTSフレームは例えば、全く同じ20MHz幅のPHYパケットとして、チャネル1〜4で同時に送信される、IEEE802.11n規格やIEEE802.11ac規格で言うところのduplicate PPDU(physical layer convergence procedure (PLCP) protocol data unit)である。この場合、当然、MACフレームレベルでも同じフレームとなっている。
基地局からduplicate PPDUで送信されたRTSフレームを受信すると、端末ではそのRTSフレームに対し、どのチャネルを使ってCTSフレームを送信できるのかを判断する。その際、受信処理部40は、基準チャネルに関しては、それまでに受信したフレームによるNAVの期間内かというような、1チャネルのみの利用のときにCSMA/CAで実施される判断を用いる。一方、拡張チャネルに対応するチャネル1、3、4に関しては、duplicate PPDUで受信したRTSフレームの受信開始した時刻(T_1)からある固定時間遡った時点(T_2)までの間に、チャネル2〜4で、CCAがビジーと検出されたかを確認する。つまり、受信処理部40は、拡張チャネル側については継続してCCA情報を観測しておく必要がなく、ある限られた期間のCCA情報だけを使えばよいようにしている。
ここで、ある固定時間とは、例えばIEEE802.11規格でのPIFS(point coordination function (PCF) interframe space)である。PIFSは、CSMA/CAで優先権を持ったアクセスを得るために用いられるフレーム間隔(IFS:Interframe space)である。PIFSは、応答フレームの送信やバースト送信時に用いられるSIFS(short interframe space)に、CCAを検出するための最小時間や送受信切替時間から規定されるSlot Timeを足した値として定義されている。
図3では、時刻T_2からRTSの受信開始時までの間に、チャネル3ではCCAがビジーとなっている(AP100は隠れ端末などの理由で、RTSフレーム送信前のチャネル3でのCCAのビジーを検知していない)。このため、受信処理部40は、チャネル3は使用中であると判断する。端末はダイナミック動作端末であるため、primaryチャネルであるチャネル2を基準に、干渉のない最大のチャネル幅のチャネルでCTSフレームを応答する。チャネル1は干渉がなく、チャネル3、4についてはチャネル4については干渉がないもののチャネル3で干渉がある。よって、primaryを基準にしたときの干渉のない最大のチャネル幅は、チャネル2とチャネル1を合わせた40MHzチャネル幅である(すなわちprimaryとsecondary)。よって、端末は、チャネル1とチャネル2でCTSフレームを送信する。実線の枠で囲まれた“CTS”がCTSフレームを表す。点線の枠で囲まれた“CTS”はCTSフレームを送信しないことを表す。
チャネル1、2でCTSフレームを受信した基地局は、チャネル3、4が端末で使えないと判断されたことを把握して、チャネル1、2(すなわちprimaryとsecondary)を用いて、データフレームを端末に送信する。このデータフレームは、“DATA”と表示している。基地局は、データフレームを、チャネル1、2でのCTSフレーム受信からSIFS後に送信する。端末が正しくチャネル1、2でデータフレームを受信したことにより、データフレーム受信からSIFS後にチャネル1、2でACKフレームを送信する。
上述した例では、チャネル3に干渉があったため、チャネル4に干渉がなかったにもかかわらず、チャネル3を利用できない(つまりsecondary40を利用できない)。仮に、チャネル2に干渉がなく、チャネル1に干渉があった場合は、チャネル3、4の干渉の有無に拘わらず、チャネル2、すなわち、基準チャネルそのものが、primaryを基準にしたときの干渉のない最大のチャネル幅となり、チャネル2のみでCTSフレームを返す。したがって、チャネル3、4に干渉がなかったにもかかわらず、チャネル3、4を利用できない(つまりsecondary40を利用できない)。また、基準チャネルであるチャネル2そのものに干渉があった場合は、チャネル1、3、4の干渉有無に拘わらず、CTSフレームをどのチャネルでも返さず、チャネル1、3、4を利用できない。チャネル1〜4のすべてで干渉がなかった場合は、チャネル1〜4のすべてでCTSフレームを返す。このようにRTSフレーム送信側及びCTSフレーム送信側がいずれもダイナミック動作端末の場合、一部のチャネルに干渉がないにも拘わらず、当該干渉のないチャネルを利用出来ない場合があるため、チャネルの利用効率があまりよいとは言えない。
図4は、RTSフレームの送信側がダイナミック動作端末、CTSフレームの送信側がスタティック動作端末である場合の動作例を示す。一例として、RTSフレームの送信側がIEEE802.11ac対応基地局、CTSフレームの送信側がIEEE802.11ac対応端末である場合を想定する。この場合、ダイナミック動作するRTSフレームの送信側はMU−MC対応基地局であってもよい。図3と同様に、基地局からチャネル1〜4のそれぞれでRTSフレームが端末に送信される。端末では、どのチャネルを使ってCTSフレームを送信できるのかを判断する。端末は、図3と同様に、チャネル1、2、4では干渉がないものの、チャネル3ではCCAがビジーとなっている(AP100は隠れ端末などの理由で、RTSフレーム送信前のチャネル3でのCCAのビジーを検知していない)。このため、端末はチャネル3は使用中であると判断する。端末はスタティック動作端末であるため、動作チャネル幅(ここでは80MHz)に対応するチャネル1〜4のいずれか1つのチャネルでもビジーを検出すると、CTSフレームを応答しない。チャネル1〜4のすべてに干渉がない場合にのみ、チャネル1〜4でCTSフレームを送信する。本例では、チャネル3がビジーのため、チャネル1、2、4がビジーを検出しないにも拘わらず、CTSフレームをどのチャネルでも送信せず、1つもチャネルも利用できない。したがって、チャネルの利用効率は非常に悪いものとなる。なお、RTSフレームの送信から一定時間以内に、端末からいずれのチャネルでもCTSフレームを受信しないと判断した基地局は、この後、例えば再び、チャネル1〜4でRTSフレームを送信するなどの動作を行うことが考えられる。なお、本例の場合、他の端末(RTSフレームを送信した基地局以外の他の端末)は、基地局が送信したRTSフレームに対するCTSフレームの受信を検出せず、また想定されるCTSのSIFS後の信号検出もしないため、NAVを解除することも可能である(この場合、他の端末から送信が可能になる)。
図4の例では、RTSフレームの送信側がダイナミック動作端末、CTSフレームの送信側がスタティック動作端末としたが、RTSフレームの送信側がスタティック動作端末(例えばスタティック動作をする802.11ac対応基地局)、CTSフレームの送信側がダイナミック動作端末(例えばダイナミック動作をする802.11ac対応端末)である場合も、図4と同様のシーケンスになる。なお、RTSフレームの送信側がスタティック動作端末であるとは、当該RTSフレームを送信するスタティック動作端末が、仮に他の端末からRTSフレームを受信した場合にスタティック応答をし、またダイナミック応答のCTSフレームに合わせて動的にTXOPとして用いる占有チャネル幅を変更できない端末であることを意味する。この場合、RTSフレームの受信側の端末は、ダイナミック動作端末であっても、チャネル1〜4のいずれか1つでもビジーを検出すると、いずれのチャネルでもCTSフレームを返さない。チャネル1〜4のすべてに干渉がない場合にのみ、チャネル1〜4でCTSフレームを送信する。つまり、RTSフレームの受信側のダイナミック動作端末は、RTSフレームの送信側のスタティック動作端末の能力(スタティック)に合わせて応答を行う。これは、仮にRTSフレームの受信側(ダイナミック動作端末)で、チャネル3のビジーを検出して、チャネル1、2のみでCTSフレームを返したとしても、RTSフレームの送信側の端末が制限されたチャネル幅での応答であることを把握できないためである。したがって、チャネルの利用効率は非常に悪いものとなる。RTSフレームの送信側の端末の属性がダイナミックかスタティックかは、RTSフレームを内包するPHYパケットを構成する際のscrambling sequenceの中に入れられていることで、RTSフレームの受信側すなわちCTSフレームの送信側の端末は把握する。RTSフレームの送信側がスタティック動作端末、CTSフレームの送信側がスタティック動作端末の場合も、図4と同様のシーケンスになり、チャネルの利用効率は非常に悪いものとなる。
図3及び図4の例では、primaryチャネルを基準として、secondaryまたはsecondary40までチャネル拡張が可能な場合を示したが、さらにsecondary80までチャネル拡張が可能な場合も同様にして考えることができる。また、RTSフレームの受信側の端末がIEEE802.11ac対応端末であったが、IEEE802.11n対応端末の場合も、スタティック動作端末かダイナミック動作端末かである場合は、それに応じて同様のシーケンスとなる。なお、この場合、チャネル拡張がsecondaryまでのため、IEEE802.11n対応端末へのRTSフレームの送信は、最大で40MHz幅を用いる場合となり、このときチャネル2(primary)とチャネル1(secondary)での送信となる。なおIEEE802.11n対応端末がスタティック、ダイナミックいずれにも対応しない場合には、受信したPHYパケットが占有したチャネル幅と同じチャネル幅で応答する場合が考えられる。すなわち、secondaryでキャリアセンスがビジーであっても40MHzのチャネル幅を占有するPHYパケットを受信したと判断すれば40MHzチャネル幅で応答を返してしまう場合がある。この場合は、他のシステムからの送信があるチャネルであってもそのチャネルで送信してしまうことになり、CSMA/CAが正しく動作しないものとなる。よって他のシステムと複数のチャネルをうまく棲み分けることができない。これは802.11n規格(IEEE Std 802.11n−2009)が規定された際には、まだスタティック、ダイナミックの概念が導入されていなかったためである。
図3及び図4で説明したようなレガシー端末、特にスタティック応答を行うレガシー端末(IEEE802.11n対応端末、IEEE802.11ac対応端末)も収容しつつ、基地局が、DL−MU−MC送信を行うことを考える。本実施形態に係るMU−MC対応端末は、基準チャネルからのチャネル拡張といった制約を受けることなく、チャネルごとに独立して送受信が可能である。したがって、MU−MC通信を行う場合に、本実施形態に係るMU−MC対応端末のみであれば、例えばMU−MC通信で使用する全チャネルで、MU−MC対象となる複数の端末にRTSフレームを送信し、RTSフレームを受信した端末側は、キャリアセンスでビジーを検出しないチャネルで個別にCTSフレームを返せばよい。基地局は、CTSフレームが返ってきたチャネルでデータフレームを同時に送信(DL−MU−MC送信)すればよい。これによれば、各端末でビジーを検出しなかったチャネル以外のチャネルをすべて利用できるため、チャネルの効率的な利用を図ることができる。しかしながら、スタティック応答を行うレガシー端末がMU−MC通信の対象に含まれる場合、前述した理由で、チャネルの利用効率が低下する可能性がある。ダイナミック応答を行うレガシー端末も、スタティック応答を行うレガシー端末ほどではないにせよ、チャネルの利用効率が低下する場合があることは前述したとおりである。したがって、レガシー端末がMU−MC通信の対象に含まれる場合、いずれにせよ、チャネルの利用効率が低下する可能性がある。以下、スタティック応答(またはダイナミック応答)を行うレガシー端末とMU−MC対応端末が混在する場合に、チャネル利用効率が低下する例を示す。
図5に、スタティック応答を行うレガシー端末とMU−MC対応端末が混在する場合の動作例を示す。例えば1つ目の端末が、スタティック応答を行うIEEE802.11ac対応のレガシー端末、2つ目の端末が、MU−MC対応端末であり、レガシー端末がsecondary40(80MHz)までのチャネル拡張に対応し、動作する場合を想定する。図5中で、“RTS(L)”、“RTS(M)”などと表示している()の中のアルファベットットは、宛先の端末がレガシー端末か、MU−MC対応端末かを便宜的に示しているものとする。例えば“RTS(L)”は、RTSフレームをレガシー端末に送信していることを意味している。“RTS(M)”は、データフレームをMU−MC対応端末に送信していることを意味している。この状態で、基地局が、チャネル1〜4(すなわちprimary、secondary、secondary40)でRTSフレームをレガシー端末に、チャネル5〜8でRTSフレームをMU−MC対応端末に同時に送信したとする。レガシー端末では、仮にチャネル2(primaryチャネル)でビジーが検出された場合、前述したようにチャネル1〜4のいずれでもCTSフレームを返さない。MU−MC対応端末では、チャネル5〜8のうち、例えばチャネル5、6でビジーを検出し、チャネル7、8でビジーを検出しなければ、チャネル7、8でCTSフレームを返す。この場合、基地局は、チャネル7、8のみでデータフレームを送信する(この場合、送信先端末が1台のみのDL−MU−MC送信となる)。仮にチャネル1〜4でのRTSフレームの送信先がレガシー端末でなく、別のMU−MC対応端末であったならば、チャネル2がビジーであっても、MU−MC対応端末からチャネル1、3、4でCTSフレームを返すことができたため、2台のMU−MC対応端末を対象に、チャネル1、3、4、7、8でDL−MU−MC送信を行うことができたことになる。このように、スタティック応答(またはダイナミック応答)を行うレガシー端末も収容しつつ、MU−MC通信を行うことを想定する場合に、チャネルの利用効率が低下する問題が発生し得る。
図6に、スタティック応答を行うレガシー端末とMU−MC対応端末が混在する場合の別の動作例を示す。図5の場合と同様に、レガシー端末がsecondary40まで(80MHzチャネル幅まで)のチャネル拡張に対応し、動作する場合に、スタティック動作を行うIEEE802.11ac対応のレガシー端末にチャネル1〜2(primary、secondary)でRTSフレームを送信し、MU−MC対応端末にチャネル3〜8でRTSフレームを送信したとする。この場合、MU−MC対応端末では、チャネル3〜8のうち、例えばチャネル5、6でビジーを検出し、チャネル3、4、7、8でビジーを検出しなければ、チャネル3、4、7、8でCTSフレームを返す。一方、レガシー端末は、secondary40までチャネル拡張されていることを認識しているため、チャネル3、4でMU−MC対応端末宛に送信されたRTSフレームに起因して、secondary40に対応するチャネル3、4でビジーを検出する。このため、チャネル1、2でビジーを検出しなくても、チャネル1〜4のいずれでもCTSフレームを返さない。よって、この場合も、チャネルの利用効率が低下する問題が発生し得る。
レガシー端末が、自端末がスタティック応答及びダイナミック応答のいずれかに対応するかを能力(Capability)として、アソシエーションプロセスなどで通知する手段が仮にあれば、例えばスタティック動作のレガシー端末を最初からMU−MCの対象に含めないように制限することで、チャネルの利用効率を高く維持することも考えられる。しかしながら、現状、そのような手段を有さないことが想定される。したがって、基地局は、レガシー端末として、スタティック応答を行う端末を想定しなければならない。
そこで、本実施形態では、レガシー端末(スタティック動作端末、ダイナミック動作端末のいずれも対象)には、レガシー端末が対応可能な最大の帯域幅(チャネル幅)より小さいチャネル幅(制限されたチャネル幅)を割り当て、当該割り当てたチャネル幅の情報を通知する。より一般的に、所定のチャネル(基準チャネル等)をベースに、指定された帯域幅まで使用するチャネル数を拡張して1つ以上のチャネルを利用可能なレガシー端末(またはそれに実装される無線通信装置)に指定する帯域幅として、所定のチャネルをベースに拡張して利用可能な最大の帯域幅よりも小さな帯域幅を指定する情報(第1情報)を送信する。具体的に、送信処理部30が、当該第1情報を含む管理フレームを生成し、当該管理フレームを送信する。MAC/PHY管理部60は、後述する別の実施形態で説明するように、システムの起動時もしくはその他のタイミングで、レガシー端末の帯域幅を制限するかを判断する判断部を備えていてもよい。判断部で制限すると判断した場合に、当該制限した帯域幅の情報を送信することを、送信処理部30にMAC共通処理部20を介して指示する。送信処理部30は、当該第1情報を含む管理フレームを生成し、当該管理フレームを送信する。管理フレームの具体的な構成例については後述する。ここでは、帯域幅を制限するかの判断を行う判断部をMAC/PHY管理部60が備えるとしたが、受信処理部40または送信処理部30が備える形態、あるいは別途の独立した処理部として存在する形態も考えられる。
一方、基地局は、MU−MC対応端末には、MU−MC通信で実際に使用し得るチャネル幅に対応する複数のチャネルを特定する情報を通知する。この際、当該情報で通知する複数のチャネルは、レガシー端末の帯域幅を狭めたことにより空いたチャネルを少なくとも1つ含む。より一般的に、指定された1つまたは複数のチャネルを利用可能なMU−MC対応端末(またはそれに実装される無線通信装置)に指定するチャネルとして、レガシー端末の最大の帯域幅で使用する複数のチャネルのうち、レガシー端末に割り当てた帯域幅で使用するチャネルとは異なるチャネルを少なくとも1つ含む複数のチャネルを指定する情報(第2情報)を、MU−MC対応端末に通知する。送信処理部30は、当該第2情報を含む管理フレームを生成し、当該管理フレームを送信する。当該第2情報は、前述した第1情報(制限した帯域幅の情報)を通知する管理フレームと同じ管理フレームで送信してもよいし、これとは別の管理フレームで送信する形態も可能である。MU−MC対応端末は、受信した第1情報及び第2情報のうち、第2情報に基づき動作し、第1情報については無視してもよい(ただし後述するように第1情報を利用する形態もあり得る)。また、第2情報はレガシー端末に解釈できない形式で記述することで、第1情報及び第2情報を受信した場合でも、レガシー端末は第1情報に基づき動作させることができる。詳細は後述する。
以上により、レガシー端末は、制限された帯域幅をチャネル幅と認識して応答を行うため、仮にビジーが検出された場合のチャネル効率の低下を大きく抑制することができる。よって、レガシー端末とMU−MC対応端末を共存させてMU−MC通信を行う場合に、MU−MC通信でのチャネル幅を広くとりつつも、システムのチャネル効率を高く維持することが可能になる。
上述したように第1情報(レガシー端末に通知する、制限したチャネル幅の情報)及び第2情報(MU−MC端末に通知する複数のチャネルを特定する情報)は、管理フレームで通知する。
図7に、管理フレームフォーマットの例を示す。ビーコンフレームやプローブ応答等の管理フレームは、このフレームフォーマットを備える。本フレームフォーマットは、MACヘッダ(MAC header)、フレームボディ(Frame body)及びFCSの各フィールドを含む。MACヘッダはFrame Control, Duration, Address, Sequence Control及び HT(High Throughput) controlの各フィールドを含む。ただし、HT Control フィールド等は含まないフレームフォーマットを用いてもよい。管理フレームでは、フレームボディに挿入する一部の情報は管理フレームごとに記載順の決まっている長さが固定長のフィールドを用いるが、その他の情報に関しては、固有のElement
ID(IDentifier)が各々に割り当てられた情報エレメント(Information element;IE)の形式を用いて通知する。情報エレメントは、Element IDで識別され、Element IDフィールド、Lengthフィールド、情報(Information)フィールドの各フィールドを有する。情報フィールドは、通知する情報の内容を格納し、Lengthフィールドは、情報フィールドの長さ情報を格納する。フレームボディには、1つまたは複数の情報エレメントを格納可能である。なおAddressフィールドがAddress 1、Address 2、Address 3の3つある。Address 1のフィールドには宛先アドレス(Receiver Address;RA)が、Address 2のフィールドには送信元アドレス(Transmitter Address;TA)が入り、Address 3のフィールドにはフレームの用途に応じてBSSの識別子であるBSSID(Basic Service Set IDentifier)(全てのビットに1を入れて全てのBSSIDを対象とするwildcard BSSID場合もある)か、TAが入る。
IEEE802.11では、IEEE802.11n対応端末にチャネル幅を通知可能な情報エレメントとして、HT Operationエレメント(HT Operationエレメント)、IEEE802.11ac対応端末に、HT Operationエレメントとの組み合わせでチャネル幅を通知可能な情報エレメントとして、VHT Operationエレメント(VHT Operation element)が定義されている。上述した第1情報(レガシー端末に通知する、制限したチャネル幅の情報)は、HT Operationエレメント及びVHT OperationエレメントのそれぞれのInformationフィールドで通知することができる。
図8にHT Operationエレメントのフォーマットを示す。HT Operation Informationフィールド内のSTA Channel Widthサブフィールド(1ビット)に、使用する動作チャネル幅(20MHzあるいは40MHz)に応じて、0または1の値を設定する。Element IDフィールドには、HT
Operationエレメントに対して予め定義された値(例えば61)を設定する。Lengthフィールドには、Lengthフィールドより後の情報フィールドの合計サイズの値を設定するが、この例では22オクテットとなる。なお、Primary Channelフィールドには、primaryチャネルのチャネル番号を設定する。HT Operation Informationフィールド内のSecondary Channel Offsetサブフィールド(2ビット)は、primaryチャネルに対するsecondaryチャネルの相対的なオフセットを示し、primaryチャネルの上側(高周波側)にsecondaryチャネルを設けるときは、当該サブフィールドの値を1に、下側(低周波側)にsecondaryチャネルを設けるときは、当該サブフィールドの値を3に、secondaryチャネルが存在しない場合は、当該サブフィールドの値を0にする。
図9にVHT Operationエレメントのフォーマットを示す。VHT Operation Informationフィールド内のChannel Widthサブフィールド(1オクテット)に、使用するチャネル幅に応じて、0〜3の値を設定する。Element IDフィールドには、VHT Operationエレメントに対して予め定義された値(例えば192)を設定する。Lengthフィールドには、Lengthフィールドより後の情報フィールドの合計サイズの値を設定するが、この例では5オクテットとなる。
図8のHT Operationエレメント内のSTA Channel Width
サブフィールドに設定する値と、VHT Operationエレメント内のChannel Widthサブフィールドに設定する値が、第1情報(レガシー端末に通知する、制限したチャネル幅の情報)に対応する。
図10は、HT Operationエレメント内のSTA Channel WidthサブフィールドとVHT Operationエレメント内のChannel Widthサブフィールドに設定する値と、チャネル幅との関係を示すテーブルである。このテーブルは、IEEE802.11acの仕様書から抜粋したものである。なお、IEEE802.11acではVHT Operationエレメント内のChannel Widthサブフィールドについて、4〜255の値は予備(Reserved)になっている。
IEEE802.11n対応端末は、STA Channel Widthサブフィールドの値に基づき、チャネル幅を判断する。この値が0であれば、20MHz、1であれば、40MHzと判断する。IEEE802.11ac対応端末は、STA Channel Widthサブフィールドの値と、Channel Widthサブフィールドの値との組に基づき、チャネル幅を判断する。(STA Channel Width サブフィールドの値、Channel Widthサブフィールドの値)が、(0、0)であれば20MHz、(1、0)であれば40MHz、(1、1)であれば80MHz、(1、2)であれば160MHz、(1、3)であれば80+80MHzと判断する。
本実施形態では、これらに加えて、MU−MC対応端末に、MU−MC通信用の複数のチャネルを通知する情報エレメントとして、MU−MC運用エレメント(MU−MC operation element)を新たに定義する。図11にMU−MC Operationエレメントのフォーマット例を示す。新規フィールドであるMU−MC Channel Setsフィールド内に、MU−MC通信で使用する複数のチャネルを特定するための情報を設定する。Element IDフィールドには、MU−MC Operationエレメント用に新たに定義した値を設定する。この値は、IEEE802.11n及び11acで、現時点で予備(Reserved)として未使用である値の中から選択すればよい。これにより、MU−MC Operationエレメントは、MU−MC対応端末が理解でき、レガシー端末が理解できないように仕向けることができる。Lengthフィールドには、Lengthフィールドより後の情報フィールドの合計サイズの値(この例ではnオクテット)を設定する。MU−MC Operationエレメントは、前述したHT Operationエレメント及びVHT Operationエレメントとともに、同じ管理フレーム(ビーコンフレーム、プローブ応答フレーム、アソシエーション応答フレームなど)に含めて、非基地局の端末に通知することができる。
MU−MC Operationエレメント、HT Operationエレメント、及びVHT Operationエレメントは、それぞれ図7で説明した情報エレメントに相当する。これら3つの情報エレメントを、図12に示すように、1つの管理フレームのフレームボディにまとめて格納することができる。これらの情報エレメントの各管理フレーム内での記載順は規定されることになる。なお、MU−MC Operationエレメントを、HT Operationエレメント及びVHT Operationエレメントの組とは別の管理フレームで送信してもかまわない。
ここで、MU−MC対応端末にMU−MC通信で使用する複数のチャネルを特定するための情報を通知するMU−MC Operationエレメント内のMU−MC Channel Setsフィールドのフォーマットとしては、単純にBSSでMU−MC用に使用する全てのチャネル番号を並べて記載する以外にも、様々なバリエーションが可能である。以下、いくつかフォーマットの例を示す。
図13(A)及び図13(B)に、MU−MC Operationエレメントの詳細なフォーマットの例をそれぞれ示す。図13(A)の例では、MU−MC通信で使用する最小チャネル番号(Minimum Channel Number)と、チャネル幅情報(Channel Width Information)を、情報フィールド(MU−MC Channel Setsフィールド)に格納する。例えば周波数領域で連続するチャネル番号1〜8のチャネル1〜8を使用する場合、最小チャネル番号は1、チャネル幅情報は8とする。チャネル幅情報をチャネルの個数ではなく、帯域幅で表してもよく、その場合は例えばチャネル幅が20MHzで、チャネル数が8の場合は、チャネル幅情報を160MHzなどとする。なお、1つのチャネル幅は20MHzなどと予めシステムで決められていてもよいし、管理フレームで1つのチャネル幅を別途通知する構成も可能である。1つのチャネルの幅を定義するサブフィールドを情報フィールド内のサブフィールドとして追加してもよいし、別の情報エレメントで1つのチャネル幅の情報を通知してもよい。チャネル番号と帯域との関係も事前にシステムで決められていても良いし、管理フレームでこれらの関係を別途通知する構成も可能である。当該関係を定義するサブフィールドを情報フィールド内のサブフィールドとして追加してもよいし、別の情報エレメントで当該関係の情報を通知してもよい。
図13(B)の例では、最小チャネル番号(Channel Number (Lower))と、最大チャネル番号(Channel Number (Upper))を、情報フィールド(MU−MC Channel Setsフィールド)に格納する。例えば周波数領域で連続するチャネル番号1〜8のチャネル1〜8を使用する場合、最小チャネル番号は1、最大チャネル番号は8とする。なおここでのチャネル番号は想定する単位チャネル幅(例えば20MHz幅)が互いに重複しないように便宜的に定義したチャネル番号であって、実際は無線LANでのチャネル番号は5MHz間隔で割り振られたものである。したがって、例えば上記便宜的なチャネル番号1〜8は単位チャネル幅として20MHz幅を用いる場合には、5MHz間隔で割り振られたチャネル番号としては、最初のチャネル番号をXとした場合には、X、X+4、X+8、X+12、X+16、X+20、X+24、X+28というように、想定する単位チャネル幅を5MHzで除算した値(単位チャネル幅を20MHzとした場合には4)おきの番号となる。具体的には各チャネルの中心周波数は、規定されているチャネル開始周波数に対し、チャネル開始周波数+5×n_ch(MHz)として定義されている。ここで、n_chは1以上の整数である。2.4GHz帯ではチャネル開始周波数は2407MHz、n_chは1、2、…、13のいずれかの値を取る。5GHz帯ではチャネル開始周波数はdot11ChannelStartingFactor×500kHzとなり、dot11ChannelStartingFactorは8000〜10000のいずれかの値であり、n_chは1、2、…、200のいずれかの値を取る。本実施形態では特に明記していないときには便宜的なチャネル番号を用いるが、実際の5MHz間隔で割り当てられるチャネル番号に置き換える場合には上記のような置き換えとなることに留意する。
図13(A)及び図13(B)に示した例では、使用するチャネルのすべてが周波数領域で連続していたが、使用するチャネルが周波数領域で複数の離れた箇所に配置される場合もあり得る。その場合に対応するフォーマットの例を図14(A)及び図14(B)に示す。
図14(A)の例では、情報エレメント内の情報フィールドに、最小チャネル番号(Minimum Channel Number)とチャネル幅情報(Channel Width Information)のセットを複数設定する。例えば、チャネル1及び2と、チャネル5〜8を使用したい場合、最小チャネル番号1及びチャネル幅情報2(もしくは40MHz)のセットと、最小チャネル番号5及びチャネル幅情報4(もしくは80MHz)のセットを設定する。
図14(B)の例では、最小チャネル番号(Channel Number (Lower))及び最大チャネル番号(Channel Number (Upper))のセットを複数設定する。例えば、チャネル1及び2と、チャネル5〜8を使用したい場合、最小チャネル番号1及び最大チャネル番号2のセットと、最小チャネル番号5及び最大チャネル番号8のセットを設定する。
図14(A)及び図14(B)のフォーマットにおいて、Lengthフィールドは、後ろ側に設定するセット数に応じた長さを指定し、受信側にて、何個のセットが含まれることが分かるようにする。図14(A)及び図14(B)では、チャネルの不連続箇所が1つの場合を示したが、2箇所上であっても同様に、セット数を増やすことで対応可能である。
図15(A)及び図15(B)に、MU−MC Operationエレメントの他のフォーマット例を示す。ここでは、ビーコンフレームやプローブ応答フレームなどを送信しているチャネルを、予め定めたチャネルであるシステムプライマリチャネル(system primary channel)と定義し、このシステムプライマリチャネルを起点として表現することを前提としている。
図15(A)のフォーマットでは、情報フィールドとして、Channel Width Informationフィールドが設けられている。例えば、システムプライマリチャネルがチャネル1であるとしたとき、チャネル1〜8を使用する場合(1チャネルを20MHz幅とする)は、Channel Width Informationフィールドの値を8(全チャネル数)とする。システムプライマリチャネルをカウントから外して考えても良く、その場合は、Channel Width Informationフィールドの値を7とする。システムプライマリチャネルからみて高周波側(上側)及び低周波側(下側)のどちらへ拡張するかの方向を設定するサブフィールドをChannel Width Informationフィールド内に設けてもよい。この場合は、その方向に従って、システムプライマリチャネルを起点として、チャネル数分だけ、使用するチャネルを特定すればよい。Channel Width Informationフィールドには、使用するチャネル数に応じた値を設定したが、図13で説明したように、使用する帯域幅の大きさに応じた値を設定してもよい。ここではシステムプライマリチャネルもMU−MC通信用のチャネルに含める場合を示したが、システムプライマリチャネルをMU−MC通信用のチャネルから除外してもよい。
システムプライマリチャネルからみて上側及び下側の両方向に拡張する場合は、図15(B)のように、Channel Width Informationフィールドをそれぞれフィールド1、フィールド2として、2つ設ければよい。事前に定めた一方のフィールドでシステムプライマリチャネルから上側方向へ連続して使用するチャネル数を設定し、他方のフィールドでシステムプライマリチャネルから下側方向へ連続して使用するチャネル数を設定すればよい。上側を示す値と下側を示す値を、それぞれフィールド1、2にサブフィールドとして設定してもよく、その場合、フィールド1、2のどちらが上側及び下側に対応するかを事前に定めなくても良い。Channel Width Informationフィールド1、2には、使用するチャネル数の値を設定したが、図13で説明したように、使用する帯域幅の大きさに応じた値を設定してもよい。
図16(A)及び図16(B)に、MU−MC Operationエレメントのさらに他のフォーマット例を示す。図16(A)のフォーマットでは、情報フィールドとして、Channel Width Informationフィールド1、2が設けられている。Channel Width Informationフィールド1、2には、前述した図10のテーブルにおけるHT Operationエレメント内のSTA Channel Widthフィールドと、VHT Operationエレメント内のChannel Widthフィールドと同じ定義にしたがって値を設定する。例えば80+80MHzのチャネル幅に対応する複数のチャネルを使用する場合は、STA Channel Widthフィールドが1、Channel Widthフィールドが3のため、これに対応して、Channel Width Informationフィールド1の値を1、Channel Width Informationフィールド2の値を3にする。つまり、使用する複数のチャネルに対応する帯域幅を、STA Channel WidthフィールドおよびChannel Widthフィールドによって表現する場合の値と同じ値を、Channel Width Informationフィールド1およびChannel Width Informationフィールド2に設定する。これによれば、図10のテーブルを再利用できる利点がある。
図16(B)のフォーマットでは、差分拡張情報(Difference Expansion Information)フィールドが設けられている。レガシー端末が使用しているチャネル幅に対応するチャネルと、これに追加したチャネルとをMU−MC通信に使用する場合は、この追加分のチャネルに対応する帯域幅の情報を、レガシー端末が使用しているチャネル幅からの差分情報として、このフィールドに設定する。例えばレガシー端末が使用するチャネル幅が20MHzのみ(チャネル2のprimaryのみ)の場合において、MU−MC通信で80MHzのチャネル幅(チャネル1〜4)を利用する場合は、差分である60MHz幅を示す値を設定する。あるいは、差分60MHzに対応するチャネル数3を表す値を設定することも可能である。このとき60MHz幅の拡張をどちらかの周波数方向(上側か下側か)に行うかを示す情報も合わせて入れることで、柔軟に使用するチャネルを定めることができる。当然、差分として追加するチャネル番号自体を入れるようにしてもよい。MU−MC対応端末は、HT OperationエレメントとVHT Operationエレメントからレガシー端末のチャネル幅を特定し、特定したチャネル幅と、差分拡張情報フィールドの値からMU−MC通信用のチャネル幅を特定し、当該MU−MC通信用のチャネル幅に対応する複数のチャネルを特定することができる。
図17に、MU−MC Operationエレメントのさらに他のフォーマット例を示す。図17のフォーマットでは、情報フィールドとして、中心周波数(Center Frequency)フィールドと、チャネル幅情報(Channel Width Information)フィールドとが設けられている。中心周波数フィールドに、MU−MC通信で使用する複数のチャネルの中心周波数のインデックスを設定する。Channel Width Informationフィールドには、当該複数のチャネルに相当する帯域幅を表す値、もしくは当該複数のチャネルのチャネル数を設定する。
以上、図13〜図17を用いて、MU−MC Operationエレメントのフォーマット例をいくつか示したが、これらは一例であり、他の方法を用いることも当然可能である。例えばMU−MC Operationエレメント内の各ビットをそれぞれチャネルに対応付け、使用するチャネルに対応するビットを1、使用しないチャネルに対応するビットを0に設定するビットマップの方法も可能である。各ビットを単位チャネル幅おきのチャネル番号に対応させることで、表現方法を効率化することができる。この場合、開始チャネル番号を、チャネルの使用の有無に紐付けた前記ビットマップの前に入れるようにすれば、使用するチャネルの情報を冗長少なく表現することができる。
図18は、本実施形態に係るMU−MC通信を行う動作シーケンスの例を示す図である。ここでは、チャネル番号(ch.#)が1〜8のチャネル(チャネル1〜8)が存在し、チャネル2が基準チャネルとしてのprimaryチャネル、チャネル1がsecondaryチャネル、チャネル3及び4が、secondary40チャネル、チャネル5〜8がsecondary80チャネルに対応するとする。ここでは基地局(AP)100が、非基地局としての端末(STA)101、103、104の3台の端末をMU−MC通信の対象として選択した場合を想定する。図18中で、“RTS(1)”などと表示している()の中の数字は、宛先の端末の参照番号の下一桁を便宜的に示しているものとする。例えば“RTS(1)”は、RTSフレームを端末101に送信していることを意味している。“DATA(3)”は、データフレームを端末103に送信していることを意味している。なお、図18の例では、全チャネル数が8であるが、本実施形態はこれに制限されず、チャネル数が5であっても、7であってもよいし、8より大きな数であってもよい。また、システムプライマリチャネルがアナウンス等の用途のために存在してもよい。この場合、システムプライマリチャネルが、これらのチャネル(チャネル1〜8)のうちの1つでもよいし、これらのチャネル1〜8とは別に設けられたチャネルでもよい。
端末101は、スタティック動作を行うレガシー端末であり、端末103、104は本実施形態に係るMU−MC対応端末であるとする。基地局100は、事前にレガシー端末のチャネル幅を20MHz、MU−MC通信のチャネルをチャネル1〜8(1チャネル幅を20MHzとして、チャネル番号1〜8のチャネル1〜8の8個のチャネル。160MHzチャネル幅に対応。)と決定し、図12に示したようなフォーマットの管理フレームで、これらの情報を通知している。管理フレームを受信したレガシー端末である端末101は、IEEE802.11n対応の場合はHT Operationエレメント、IEEE802.11ac対応の場合はHT OperationエレメントとVHT Operationエレメントの両方からチャネル幅が20MHz(つまりprimaryチャネルのチャネル2のみ)であると把握する。なお、レガシー端末101は、MU−MC
Operationエレメントは解釈できない。一方、端末103、104は、MU−MC Operationエレメントから(必要に応じてHT OperationエレメントとVHT Operationエレメントも参照して)、MU−MC通信用のチャネルは、チャネル1〜8(160MHz幅)であると認識する。
基地局は、チャネル2で端末101宛てのRTSフレーム、チャネル1、3〜5で端末103宛のRTSフレーム、チャネル6〜8で端末104宛のRTSフレームを同時に送信する。同じ端末に複数送信するRTSフレームは、前述したように、IEEE802.11n規格やIEEE802.11ac規格で言うところのduplicate PPDU(physical layer convergence procedure (PLCP) protocol data unit)として送信される。この場合、当然、MACフレームレベルでも同じフレームとなっている。
端末101、103、104は、基地局100からduplicate PPDUで送信されたRTSフレームを受信すると、そのRTSフレームに対し、どのチャネルを使ってCTSフレームを送信できるのかを判断する。例えば、duplicate PPDUで受信したRTSフレームの受信開始した時刻からある固定時間遡った時点までの間に、CCAがビジーと検出されたかを確認する。なお、それまでに受信したフレームによるNAVの期間内かというような、1チャネルのみの利用のときにCSMA/CAで実施される判断を用いてもよい。ある固定時間とは、例えばIEEE802.11規格でのPIFS(point coordination function (PCF) interframe space)であるが、AIFS(arbitration interframe space)など他の固定時間でもよい。AIFSの詳細は、後述する他の実施形態で説明する。
図18では、RTSフレームの受信開始時から固定時間遡った時点までの間に、チャネル2、5、6ではCCAがビジーとなっている(基地局100は隠れ端末などの理由で、RTSフレーム送信前のチャネル2、5、6でのCCAのビジーを検知していない)。このため、レガシー端末101は、チャネル2(primary)は使用中であると判断する。MU−MC対応端末103は、チャネル5は使用中であると判断し、MU−MC対応端末104は、チャネル6は使用中であると判断する。端末101はスタティック動作端末であるため、RTSフレームの送信に利用されたいずれかのチャネルで干渉があれば応答(CTSフレーム)を返さない。ここでは、端末101は、チャネル2(primary)のみが動作チャネルと認識しており、チャネル2でビジーが検出されたため、CTSフレームを返さない(仮にチャネル2でビジーが検出されなければ、チャネル2でCTSフレームを返す)。実線の枠で囲まれた“CTS”がCTSフレームを表し、点線の枠で囲まれた“CTS”はCTSフレームを送信しないことを表す。
ここで、もし端末101の動作チャネルがsecondary40まで拡張されている場合(80MHzチャネル幅の場合)に、端末101にチャネル1〜4でRTSフレームが送信された場合、チャネル2でビジーが検出されれば、たとえチャネル1、3、4でビジーが検出されなくても、スタティック応答としてCTSフレームは一切返さない。したがって、本例のようにチャネル2(primary)でビジーが検出される状況では、端末101のチャネル幅を、チャネル2(primary)のみを使用する20MHz幅に制限しておくことで、チャネル幅を80MHzにした場合に比べて、チャネル利用効率の低下を大きく抑制できる。
端末103は、自装置宛てに送信されたRTSフレームを受信したチャネル1、3〜5のうち、チャネル5でビジーを検出し、チャネル1、3、4ではビジーを検出しなかったため、チャネル1、3、4でCTSフレームを返す。つまり、MU−MC対応端末103は、レガシー端末101と異なり、基準チャネル(primary)を基準とした応答を行う必要はなく、チャネル毎に独立してビジーの検出を行い、ビジーが検出されなかったチャネルで個々にCTSフレームを返す。よって、端末103の受信処理部40は、チャネル1、3、4のみでCTSフレームを生成するように、送信処理部30に指示を出す。そして送信処理部30は、RTSフレームを含むPHYパケットの受信を終了した時刻からSIFS経過後に、CTSフレームをチャネル1、3、4から送信する。このとき、例えば送信処理部30には、受信処理部40からRTSフレームを含むPHYパケットの受信を終了した時刻を、CTSフレームの送信指示とともに通知されるようにしておく。これにより、送信処理部30は、当該時刻からのタイミングを計って、SIFS経過後に、PHY処理部50からCTSフレームの入ったPPDUを所定のチャネル(すなわち自分宛てRTSフレームを受信し、当該RTSフレーム以外に固定時間ビジーを検出しなかったチャネル)で送信するように、PHY処理部50に送信指示を出すことができる。
なお、SIFSは一例であり、固定時間であれば他の時間またはIFSでもよい。SIFSより長いIFSでもよい。このことは、本明細書の全体に対して適用される。DIFS等、他の種類のIFSについても同様に、固定時間であれば他の時間またはIFSでもよい。
端末104は、自装置宛てに送信されたRTSフレームを受信したチャネル6〜8のうち、チャネル6でビジーを検出し、チャネル7、8ではビジーを検出しなかったため、チャネル7、8でCTSフレームを返す。つまり、MU−MC対応端末104は、MU−MC対応端末103と同様に、チャネル毎に独立してビジーの検出を行い、ビジーが検出されなかった個々のチャネルでCTSフレームを返す。動作の詳細は、端末103と同様である。
基地局100は、端末103から送信されたCTSフレームをチャネル1、3、4で受信し、端末104から送信されたCTSフレームをチャネル7、8で受信する。チャネル2、5、6ではCTSフレームを受信できなかったことから、チャネル2が端末101で使えず、チャネル5が端末103で使えず、チャネル6が端末104で使えないと判断されたことを把握する。そして、基地局は、チャネル1、3、4を用いて端末103に、チャネル7、8を用いて端末104にそれぞれデータフレームを同時に送信する。すなわち、端末103、104に対しDL−MU−MC送信によりデータフレームを送信する。端末103、104宛のデータフレームは、図では“DATA(3)”及び“DATA(4)”とそれぞれ表示している。基地局100は、これらのデータフレームを、チャネル1、3、4、7、8でのCTSフレーム受信完了からSIFS後に送信する。端末103ではチャネル1、3、4でデータフレームが正しく受信され、データフレーム受信からSIFS後にチャネル1、3、4でACKフレームを送信する。同様に、端末104ではチャネル7、8でデータフレームが正しく受信され、データフレームの受信からSIFS後にチャネル7、8でACKフレームを送信する。ここではチャネルごとにACKフレームを返しているが、前述したBA(BlockAck)フレームを返すようにしてもよいし、また端末ごとに、データフレームを受信したいずれか1つのチャネルを用いてACKフレームもしくはBAフレームを返すようにしてもよい。
なお、図18の例では、レガシーの端末101は20MHz幅をチャネル幅として、primaryチャネル(チャネル2)を使用し、MU−MC通信用のチャネルはチャネル1〜8としたが、レガシー端末とMU−MC通信用とで使用するチャネルを区分することも可能である。例えばレガシー端末は20MHz幅のprimaryチャネル(チャネル2)を使用チャネルとし、MU−MC通信ではチャネル1、3〜8を使用チャネルとしてもよい。この場合、前述したフォーマットの管理フレーム(図7参照)で、レガシー端末には20MHz幅を指定し、MU−MC対応端末にはチャネル1、3〜8を指定すればよい。
図19は、本実施形態に係る基地局の基本的な動作例のフローチャートである。基地局は、システム起動時、もしくはその後の任意もしくは所定の条件が成立したタイミング(詳細は後述する実施形態で説明する)で、レガシー端末(IEEE802.11n対応端末、IEEE802.ac対応端末)のチャネル幅を制限することを決定する(S101)。基地局は、チャネル幅を制限するため、レガシー端末に指定する帯域幅として、所定のチャネル(primary)をベースに拡張して利用可能な最大の帯域幅よりも小さな帯域幅を指定する(同S101)。最大の帯域幅が異なる複数のレガシー端末が存在(例えばIEEE802.11n対応端末、IEEE802.ac対応端末が共存)するときは、これらのレガシー端末のうち最大の帯域幅が最も小さいレガシー端末の最大の帯域幅を基準とし、これより小さな帯域幅を指定してもよい。または、制限したチャネル幅は20MHzチャネル幅など、事前に各レガシー端末が対応可能な最も低いチャネル幅を定めておき、これに一律に決定してもよい。レガシー端末がIEEE802.ac対応端末のみのときは40MHzチャネル幅に、IEEE802.11n対応端末のみのときは20MHzチャネル幅に制限してもよい。
また、基地局は、MU−MC対応端末に対し、MU−MC通信用の複数のチャネルを決定する(S102)。MU−MC通信用の複数のチャネルは、事前にシステムで決めておいてもよい。例えば、レガシー端末が使用しうる最大のチャネル幅(例えばIEEE802.11acが使用しうる最大のチャネル幅である160MHz)に対応する複数のチャネルでもよいし、これを包含するさらに多くのチャネルでもよい。少なくともレガシー端末のチャネル幅を制限したことにより空いた帯域を含むようにチャネルを指定することが望ましい。ステップS101で決定したレガシー端末のチャネル幅(帯域幅)の情報を利用し、当該チャネル幅に対応するチャネルを含まないように指定することも可能である。なお、ステップS101とステップS102の順番は逆になっていてもよい。
基地局は、ステップS101で決定した、制限したチャネル幅の情報(第1情報)と、ステップS102で決定したMU−MC通信用の複数のチャネルを特定する情報(第2情報)とを含む管理フレームを生成し、管理フレームを送信する(S103)。第1情報及び第2情報を送信する管理フレームは、前述したようにビーコンフレームやブローブ応答フレームでもよいし、その他のフレームでもよい。第1情報と第2情報とを別々の管理フレームで送信してもよい。
基地局は、任意のトリガーでMU−MC通信を行うことを決定する(S104)。任意のトリガーは何でも良いが、例えば2つ以上の端末への送信データが発生した場合がある。基地局は、MU−MC通信の対象となる複数の端末を選択する(同S104)。選択する端末は、複数のMU−MC端末のみでもよいし、レガシー端末とMU−MC端末が混在してもよい。後者の場合は、レガシー端末は1台のみであるとする。基地局は、選択した端末に対して使用するチャネルを選択し割り当てる(同S104)。レガシー端末の場合は、制限したチャネル幅に対応するチャネルを選択する。例えば20MHz幅に制限している場合は、primaryチャネル(チャネル2)のみ、40MHz幅に制限している場合は、primaryチャネル(チャネル2)とsecondary(チャネル1)を選択する。MU−MC端末は、レガシー端末に選択した以外の中からチャネルを選択する。なお、選択する端末が、MU−MC端末のみのときは、上記制限したチャネル幅で使用されるチャネルをMU−MC端末に割り当てることも可能である。
基地局は、MU−MC通信用に選択した各端末に対して、それぞれに割り当てたチャネルごとにRTSフレームを同時に送信する(S105)。なお、RTSフレームの送信にあたり、事前にチャネルごとにキャリアセンスにより事前に1フレーム分のチャネルアクセス権を獲得しているものとする。基地局は、送信したRTSフレームへの応答として、各端末からチャネルごとにRTSフレーム送信のSIFS後にCTSフレームを同時に受信することで、続くデータフレームの送信のためのTXOPをチャネルごとに獲得する、すなわちデータフレームを送信するためのチャネルを決定する(S106)。仮に全くCTSフレームを受信しなかったなど、TXOPを継続することが不適と判断した場合には、ステップS104かS105の前に戻るようにしてもよい。基地局は、各端末がCTSフレームを返したチャネルを用いて、獲得したTXOPで、CTSフレーム受信のSIFS後に各端末宛のデータフレームを同時に送信する(S107)。この際、チャネルの単位でデータフレームを個別に送信することの他、同一端末に対しては、2つ以上のチャネルを束ねた帯域でデータフレームを送信することも可能である。なお、端末がMIMO通信に対応している場合は、MIMOでデータフレーム送信を行うことも可能である。この場合、ベースバンド集積回路または制御部は、物理層の処理として、MIMOに関する処理も行う。
基地局は、データフレームを送信したチャネルで、データフレームの送信に成功した端末からデータフレーム送信のSIFS後にACKフレームを受信する(S108)。前述したようにBA(BlockACK)フレームを受信する形態も可能である。同じTXOP内ではステップS107に戻り、ステップS107とS108を繰り返すようにしてもよい。この場合、ステップS108は省略して、TXOPの最後でBAフレームの送信を要求するBAR(BlockAckReq)フレームを送信して、SIFS後にBAフレームを受信するようにしてもよい。あるいはTXOPの最後のデータフレームでACKポリシーフィールドを用いてBAフレームの送信を要求(implicit Block Ack Request)するようにして、SIFS後にBAフレームを受信するようにしてもよい。また、別のTXOPを獲得するために、ステップS108からS104に戻るようにしてもよい。
図20は、本実施形態に係るMU−MC対応端末の基本的な動作例のフローチャートである。MU−MC対応端末は、基地局から、レガシー端末に対する制限したチャネル幅の情報(第1情報)と、MU−MC通信用の複数のチャネルを特定する情報(第2情報)とを含む管理フレームを受信する(S201)。管理フレームは、前述したようにビーコンフレームやブローブ応答フレームでもよいし、その他のフレームでもよい。第1情報と第2情報とを別々の管理フレームで受信してもよい。
MU−MC対応端末は、管理フレームに含まれる第2情報に基づき、MU−MC通信用の複数のチャネルを把握する。MU−MC対応端末は、当該複数のチャネルごとに、あるいは連続する複数のチャネルから成るチャネルセットごとに信号の受信を独立して行うことができる(CCA検出等も含む)ように、受信フィルタ及び送信フィルタを設定する(S202)。MU−MC通信用の複数のチャネルのうち、自端末に割り当てられるチャネルあるいはチャネルセットを予め把握することができるなら、その割り当てられるチャネル(1つもしくは複数)またはチャネルセットごとに信号の受信を独立して行うことができるようにしてさえおけばよい。なお、これらのチャネルとは別途システムプライマリチャネルが定義されている場合は、そのシステムプライマリチャネルでも信号を送受信できるようにしておく。MU−MC対応端末は、管理フレームに含まれる第1情報は基本的に無視することが考えられるが、上述したとおり、第1情報も用いて、MU−MC通信用の複数のチャネルを特定する構成もあり得る。
MU−MC対応端末は、MU−MC通信用のチャネルのうちの一部(または全部)のチャネルでRTSフレームを受信したと判断すると、FCS情報に基づきRTSフレームを正しく受信(復号)できたか、また前述のCCA要件をクリアしたか(CCAが固定時間ビジーでなかったか)を検査する(S203)。MU−MC対応端末は、正しくRTSフレームを受信でき、かつCCA要件をクリアしたチャネルを決定する(S204)。そしてRTSフレームの受信完了からSIFS後にCTSフレームを、決定したチャネルで同時に送信する(S205)。なお、S204でCTSフレームを送信するチャネルがなければ、ステップS203に戻る。MU−MC対応端末は、CTSフレームを送信したチャネルでデータフレームの到来を待機する(S206)。データフレームを受信したと判断する(S207)と、FCS情報に基づきデータフレームを正しく受信(復号)できたか検査する(S208)。正しく受信できた場合、データフレームのボディフィールドからデータを取り出して、上位処理部90に渡す。また、正しく受信できたチャネルごとにACKフレームを生成して、データフレームの受信完了からSIFS後に、ACKフレームを送信する(S208)。ACKフレームの代わりに、BlockACKフレームを生成して、データフレームを正しく受信したいずれかのチャネル(もしくは複数のチャネル)でBlockACKフレームを送信してもよい。同じTXOPが続く場合は、ステップS206に戻る。また受信したデータフレームが即時応答を要求しない場合は、ステップS207の後のS208はなくなり、TXOPの最後などで別途BARフレームを受信してBAフレームを送信するというシーケンスもある。また、ステップS203に戻るシーケンスもある。
以上、本実施形態によれば、レガシー端末が使用するチャネル幅を制限したことにより、レガシー端末は、制限された帯域幅を使用可能なチャネル幅と認識して応答を行うため、チャネル幅が本来対応可能なチャネルで使用が制限されていない場合にはビジーが検出されるチャネルがあっても、チャネル効率の低下、特にレガシー端末がスタティック動作端末の場合のチャネル効率の低下を大きく抑制することができる。よって、レガシー端末とMU−MC対応端末を共存させてMU−MC通信を行う場合に、MU−MC通信の帯域幅を広くとりつつも、システムのチャネル効率を高く維持することが可能になる。
(第2の実施形態)
第1の実施形態では、レガシー端末(IEEE 802.11n、IEEE 802.11ac対応端末)のチャネル幅を制限することで、MU−MC通信時にシステムのチャネルの利用効率を高く維持することを示した。本実施形態では、レガシー端末のチャネル幅の制限の必要性を判断し、必要に応じてレガシー端末のチャネル幅を制限する形態を示す。
基地局は、MU−MC通信で使うチャネル幅(あるいはシステムで使うチャネル幅)に応じて、レガシー端末のチャネル幅の制限を判断する。具体的に、MU−MC通信で使うチャネル幅と、レガシー端末が対応可能なチャネル幅に基づき、レガシー端末のチャネル幅を制限するか判断する。判断のタイミングは、システムの起動時もしくはその後の任意のタイミングが考えられる。
ここで、システム起動時に判断する場合には、レガシー端末が対応可能なチャネル幅は、基地局の動作帯域に応じて特定のチャネル幅に決定することができる。例えば基地局の動作帯域が5GHz帯域であれば、IEEE802.11nとIEEE802.11ac対応端末の両方が、基地局に接続してくる(基地局のBSSに入ってくる)可能性がある。そこで、この場合は、レガシー端末が対応可能なチャネル幅をIEEE802.11acで対応必須の80MHzと見なしてもよい(160MHz対応のレガシー端末の存在の可能性を鑑みて160MHzと見なしてもよい)。また、基地局の動作帯域が2.4GHz帯域であれば、IEEE802.11ac対応端末は存在しないことが分かるため、その場合は、IEEE802.11n対応端末が対応必須の20MHzを、レガシー端末の対応可能なチャネル幅と見なしてもよい(この場合、40MHz対応のレガシー端末の存在の可能性は2.4GHz帯の802.11b対応端末を加味したチャネル割り当てから低いと考えられるが、40MHz対応の可能性を鑑みて40MHzと見なしてもよい)。
レガシー端末が対応可能なチャネル幅に応じて、例えばMU−MC通信で使うチャネル幅と比較する閾値の値を決定し、MU−MC通信で使うチャネル幅が閾値以上のときに、レガシー端末のチャネル幅を制限する。閾値は、例えば、レガシー端末の対応可能なチャネル幅が80MHzであれば、80MHzに設定し、MU−MC通信のチャネル幅が閾値以上であれば、レガシー端末のチャネル幅を、例えば20MHzというように、制限する。一方で、MU−MC通信用のチャネル幅が閾値未満であれば、チャネル幅に制限を掛けないことで、レガシー端末を優先した扱いとする。この場合、MU−MC通信を行うときは、MU−MC対応端末のみをMU−MC通信の対象として選択することが考えられる。
レガシー端末のチャネル幅を制限する場合、制限したチャネル幅に関する情報の通知は、第1の実施形態で説明したように、ビーコンフレームまたはプローブ応答フレームといった管理フレームで行うことができる。なお、一旦通知したチャネル幅を、後から変更する場合は、後述する第10の実施形態で示すフォーマットの管理フレーム(チャネル切替告知フレーム(Channel Switch Announcement frame)や、拡張チャネル切替告知フレーム(Extended Channel Switch Announcement frame))を用いることもできる。
(第3の実施形態)
本実施形態では、ユーザの指示情報に応じて、レガシー端末が使用するチャネル幅の制限の可否を判断する。ユーザは、例えば無線ネットワークのグループ(BSS)の用途に応じて、指示情報を設定することが考えられる。例えばレガシー端末が多数を占めることが事前に予想できる場合は、チャネル幅の制限をしない旨の情報を設定し、MU−MC対応端末が多数を占めることが予想できる場合には、チャネル幅を制限する旨の情報を設定する。ユーザの指示情報は、例えばMIB(Management Information Base)、及びMLME(MAC subLayer Management Entity)SAP(Service Access Point)を介して、基地局のMAC/PHY管理部60に通知することができる。
例えばユーザの指示情報が、レガシー端末のチャネル幅を20MHzに制限するものであったとする。この場合、基地局は、指示情報に従って、レガシー端末のチャネル幅を20MHzに設定する。チャネル幅の制限の可否を判断するタイミングも、基本的にシステムの起動時に行うことが考えられるが、システムの起動後にユーザが指示情報を与え、それを反映する構成も可能である。
上述したように、レガシー端末のチャネル幅を制限する場合、制限したチャネル幅に関する情報の通知は、第1の実施形態で説明したように、ビーコンフレームまたはプローブ応答フレームといった管理フレームで行うことができる。なお、一旦通知したチャネル幅を、後から変更する場合は、上述したように、第10の実施形態で示すフォーマットの管理フレームを用いることもできる。
ユーザの指示情報は、基地局が備える記憶装置に格納しておき、基地局の起動時にこれを読み出してもよいし、ユーザが基地局とネットワークを介して接続された装置から設定用のアプリケーション画面を介して指示情報を与えるようにしてもよい。当該ネットワークは、これまで述べたBSSを形成するネットワークでもよいし、これとは別のネットワークでもよい。
(第4の実施形態)
第2よび第3の実施形態では、システムの起動時もしくは任意のタイミングで、レガシー端末のチャネル幅の制限の可否の判断を行ったが、本実施形態では、基地局でMU−MC通信の機能を有効(オン)にしたときに、レガシー端末のチャネル幅の制限を行う。第2よび第3の実施形態では、システムの起動時からMU−MC通信の機能がオンになっていることを想定していたが、本実施形態では、起動時もしくは起動後の途中からMU−MC通信の機能が無効(オフ)になっており、この後にMU−MC通信の機能をオンにした場合に、レガシー端末のチャネル幅を制限する。なお、MU−MC通信の機能がオン・オフの設定は、例えばMIBで行えばよい。
システムの起動後に、MU−MC通信の機能をオンにする場合としては、例えば、基地局のネットワーク(BSS)が混雑していることを検出した場合、通信するデータ量が多いことを検出した場合、短いフレームのやりとりが多いことを検出した場合などが考えられる。ネットワークが混雑している場合は、例えばACKフレームの受信に失敗した回数または割合に基づき判断できる。通信するデータ量が多いか否かは、例えば各端末への送信データの合計量が所定値より大きいかにより判断できる。また、短いフレームのやりとりが多い場合とは、個々の端末とのやりとりしたMACフレーム(MPDU)数をカウントし、より厳密に把握するには例えば所定値より短いMSDUの数(単純に所定値より短いMPDUの数にしてもよい)をカウントし、単位時間あたりのカウント値の合計または平均が大きければ、短いフレームのやりとりが多いと判断できる。これらの判断の方法は一例であり、他にも同様の状況を判断できる限り任意の方法を用いることができる。
基地局は、MU−MC通信の機能をオンにすることを決定した場合は、MIBにMU−MC通信の機能のオンを設定するとともに、必要に応じて、管理フレームを介してBSSに属するMU−MC対応端末にMU−MC通信の機能をオンにしたことを通知してもよい。また、レガシー端末についてチャネル幅の制限を行うことを決定し、制限したチャネル幅に関する情報を管理フレームで通知すればよい。制限後のチャネル幅は、20MHzなど事前に決めておいてもよい。IEEE802.11nとIEEE802.11ac対応端末が混在するときは20MHz、IEEE802.11ac対応端末のみのときは40MHzなど、存在するレガシー端末の種類に応じて制限後のチャネル幅を制御してもよい。なお、一旦通知したチャネル幅を、後から変更する場合は、上述したように、第10の実施形態で説明する管理フレームを用いてもよい。
以上、本実施形態によれば、基地局でMU−MC通信の機能を有効(オン)にしたときに、レガシー端末のチャネル幅を制限することで、MU−MC通信が行われ得ない状況で、レガシー端末の通信を制限することを防止できる。
(第5の実施形態)
基地局が、通信エリアがオーバーラッピングしている他の基地局のBSSなど他のシステムとの干渉の関係に基づき、レガシー端末のチャネル幅の制限の可否を判断する。例えば、MU−MC通信の効率が下がると判断した場合に、自局に属するレガシー端末についてチャネル幅の制限を行うことを決定する。なお、オーバーラッピングしている他の基地局のBSSを、OBSS(Overlapping BSS)と呼ぶ場合もある。
具体的には、基地局は、システムで使用するチャネル群またはMU−MC通信で使用するチャネル群についてチャネルスキャンを行う。特に、レガシー端末が対応可能なチャネル幅に対応するチャネル群についてチャネルスキャンを行う。チャネルスキャンは、例えばシステムの起動時に行ってもよいし、MU−MC通信の機能のオンをシステムの起動後に行う場合において当該機能をオンにするタイミングに行っても良いし、その他の任意のタイミングで行ってもよい。
チャネルスキャンのビジー率を測定し、ビジー率に応じてチャネル幅の制限の可否の判断をする。ビジー率は、例えばキャリアセンスを行っている時間に対する、ビジー状態と判断している割合の時間によって測定してもよいし、あるいは、他に定義した方法に従って測定を行っても良い。レガシー端末が対応可能なチャネル幅に対応するチャネル群の少なくとも1つについてビジー率が所定値を越える場合には、チャネル幅の制限を行うと判断し、それ以外の場合は制限を行う必要はないと判断してもよい。あるいは、全部もしくは一定数以上のチャネルでビジー率が所定値を越える場合にチャネル幅の制限を行うと判断し、それ以外の場合は制限を行う必要はないと判断してもよい。制限後のチャネル幅は、20MHzなど事前に決めておいてもよい。IEEE802.11nとIEEE802.11ac対応端末が混在するときは20MHz、IEEE802.11ac対応端末のみのときは40MHzなど、存在するレガシー端末の種類に応じて制限後のチャネル幅を制御してもよい。
以上、本実施形態によれば、他のシステムからのチャネル干渉が大きい場合(ビジー率が大きい場合など)に、レガシー端末のチャネル幅を制限することで、レガシー端末のチャネル幅を制限してもレガシー端末に与える影響は少なくできる。よって、レガシー端末の通信に実質的に大きな制約をかけずに、チャネル利用効率の高いMU−MC通信を行うことができる。
(第6の実施形態)
基地局は、レガシー端末が使用しているチャネル(primaryチャネル、secondaryチャネル、secondary40チャネルなど)の利用頻度に基づき、レガシー端末に対するチャネル幅の制限の可否を判断する。チャネルの利用頻度は、そのチャネルがどの程度の回数または時間の間、使用されているかを評価できる限りどのような方法で測定してもかまわない例えば、そのチャネルで一定レベル以上の電波強度を受信している時間の割合(利用率)やビジーの時間の割合(ビジー率)などを用いることができる。実際に各レガシー端末が送信に使用した1つまたは複数のチャネルを把握して統計処理などを行い、利用率を算出するのでもよい。
例えばprimaryチャネルの利用率が一定値以上であれば、BSS内にレガシー端末が多数存在すると判断して、チャネル幅の制限を行わないことを決定し、一定値未満であれば、レガシー端末の台数は少ないと判断して、チャネル幅を20MHzなどへ、制限するようにしてもよい。この場合、MU−MC対応端末は、primaryチャネルでの送信を行わないように制御しておくことで、測定の精度をより高くすることができる。利用率の測定を一定時間ごとに行い、過去のX(Xは2以上の整数)回の測定の平均に基づき同様の判断を行っても良い。また、過去のX回の測定のうちY(Yは1以上X未満の値)回以上の利用率が一定以上であれば、チャネル幅の制限を行わないと判断してもよい。ここで述べた方法以外にも、利用率に基づいてレガシー端末の台数の程度を評価できる限り、任意の方法を用いてもよい。
また、BSS内に属するレガシー端末数と、当該BSS内に属するMU−MC対応端末数との関係に基づいて、レガシー端末のチャネル幅の制限の可否を判断してもよい。例えばレガシー端末数から、MU−MC対応端末数を引いた値が一定値(例えば一定値はマイナス値を含む任意の整数)以上のときは、チャネル幅の制限を行わず、当該差分が一定値未満のときは、チャネル幅の制限を行うようにしてもよい。あるいは、レガシー端末数をMU−MC対応端末数で除算した値でもよい(この場合、一定値は例えば0以上の任意の整数)。また、一定時間ごとにレガシー端末数及びMU−MC対応端末数の計測を行い、過去X回について差分の平均に基づいて、同様の判断を行ってもよい。また、過去のX回の計測のうちY(Yは1以上X未満の値)回以上の差分が一定以上であれば、チャネル幅の制限を行わないと判断してもよい。ここで述べた方法以外にも、レガシー端末数とMU−MC対応端末数の関係を評価できる限り、任意の方法を用いてもよい。ここではレガシー端末をIEEE802.11nとIEEE802.11acとを区別しなかったが、レガシー端末数としてIEEE802.11ac対応端末数のみを用いてもよい。より広い帯域を使用する可能性があるIEEE802.11ac対応端末の影響を重視するためである(レガシー端末数が同じでも、IEEE802.11ac対応端末が多いほど、システムのチャネル効率の低下が懸念される)。
以上、本実施形態によれば、レガシー端末の台数が少ない場合は、または少ないと考えられる場合には、レガシー端末のチャネル幅を制限し、その逆に多い場合または多いと考えられる場合には制限しないことで、レガシー端末へ与える影響が少ない状態で、チャネル幅の制限を行うことができる。
(第7の実施形態)
基地局は、MU−MC通信を意図して、RTSフレーム送信用に獲得したTXOPでのチャネルアクセス頻度に応じて、レガシー端末に対するチャネル幅の制限の可否を判断してもよい。例えば、チャネルアクセス頻度は、MU−MC通信を行いたい複数のチャネルのそれぞれについて、チャネルアクセス予定のチャネルで実際にキャリアセンスした結果送信できた割合であるチャネルアクセス率を用いることができる。一例として、レガシー端末が使用するチャネル、例えばprimaryからsecondary40チャネルまでの計4つの20MHz単位のチャネル(チャネル1〜4)についてチャネルアクセス率を計算する。これらのチャネルにおいて、チャネルアクセス率が一定値未満の低いチャネルが存在する場合は、レガシー端末のチャネル幅を20MHzなどへ制限することを決定してもよい。チャネルアクセス頻度として、チャネルアクセス率の代わりに、連続して送信権を獲得できなかった回数を利用してもよい。この場合、一定回数連続して獲得できなかった場合に、チャネル幅を制限してもよい。ここで述べた以外の指標をチャネルアクセス頻度として用いてもよい。
また、MU−MC通信を意図してチャネルアクセスした際のMU−MC利用頻度に応じて、レガシー端末に対するチャネル幅の制限の可否を判断してもよい。具体的に、MU−MC利用頻度として、RTSフレームを送信したチャネルのそれぞれについて、CTSフレームが返ってきたチャネルの割合であるMU−MC利用率(チャネルアクセスに対する実際のTXOP獲得率)を用いることができる。一例として、レガシー端末が使用するチャネル、例えば、primaryからsecondary40チャネルまでの4つの20MHz単位のチャネルについて、MU−MC利用率を計算する。MU−MC利用率が一定値未満の低いチャネルが存在する場合は、レガシー端末のチャネル幅を20MHzなどへ制限することを決定する。ここでは、MU−MC利用頻度として、CTSフレームが返ってきた割合であるMU−MC利用率を用いたが、RTSフレームを送信したチャネルで実際にどの程度、MU−MC通信に利用できたかを評価できる限り、別の指標を用いてもよい。例えばCTSフレーム送信後のデータフレームの送信の成功率(ACKを受信できた割合)または失敗率でもよい。レガシー端末が使用するチャネルにおいて、成功率が一定値未満、または失敗率が一定値以上のチャネルが存在する場合は、レガシー端末のチャネル幅を20MHzなどへ制限することを決定してもよい。
以上、本実施形態によれば、チャネルアクセス頻度またはMU−MC利用頻度が低い場合に、レガシー端末のチャネル幅を制限することで、レガシー端末のチャネル幅を制限してもレガシー端末に与える影響は少なくできる。よって、レガシー端末の通信に実質的に大きな制約をかけずに、チャネル利用効率の高いMU−MC通信を行うことができる。
(第8の実施形態)
本実施形態は、これまで述べたようなレガシー端末のチャネル幅を制限するのとは少し異なり、レガシー端末を最初から基地局に接続させないことを特徴とする。レガシー端末を最初からBSSに属させないことで、BSS内を基本的にMU−MC対応端末のみとする。これにより、システムのチャネル効率を高く維持することが可能である。
レガシー端末を基地局に接続させないためには、基地局は、アソシエーションプロセスにおいてレガシー端末から受信するアソシエーション要求フレームに対する応答であるアソシエーション応答フレームに、接続の拒否を示す情報を設定すればよい。IEEE802.11規格では状況コード(Status Code)を用いて接続の拒否を示す。状況コードは数値によって表現され、例えば既存のいずれかの値を用いてもよい。既存の状況コードとして使えるものとしては、例えば次のようなものがある。不特定の失敗(unspecified failure)の意味を持ち、拒絶(REFUSED)または不特定の理由による拒絶(REFUSED_REASON_UNSPECIFIED)である“1”、端末から能力情報フィールドにより要求された全ての能力をサポートできない(Cannot support all requested capabilities in the Capability Information field)の意味を持ち、能力の不整合による拒絶(REFUSED_CAPABILITIES_MISMATCH)である“10”、規格外の理由によるアソシエーションの却下(Association denied due to reason outside the scope of this standard)の意味を持つ“12”、(Association denied because AP is unable to handle additional associated STAs)の意味を持つ“17”、要求は拒否された(The request has been declined)意味を持つ“37”。現時点で予備(Reserved)として未使用である数値の中から選択した番号を新たに本実施形態の趣旨を明示した接続拒否として定義して用いてもよい。明示する理由としては、例えば、MU−MC機能に対応しないことによる拒絶や、キャリアセンス要件を満たさないことによる拒絶、などを使うことができる。レガシー端末は、ファームウエアのアップデートなどで、この状況コードを理解できるようにしておいてもよい。レガシー端末は、基地局から受信するアソシエーション応答フレームから状況コードを読み出し解釈することで、自装置の接続が拒否されたことを明示的に認識する。状況コードによって明示的に接続の拒否を通知することで、その後、何度もレガシー端末からアソシエーション要求フレームを送信されること等に起因するシステム効率の低下を防止できる。
ここではアソシエーション応答フレームを利用してレガシー端末に接続拒否を通知したが、これによればIEEE802.11nとIEEE802.11acとで接続可否のポリシーを変えることもできる。例えば、IEEE802.11nとIEEE802.11acの一方に対応する端末は接続拒否し、他方に対応する端末は接続可であるとすることもできる。基地局が送信するビーコンフレームやプローブ応答フレームなどで、事前にレガシー端末の接続は受け付けない(拒否する)ことを通知してもよい。これによれば、最初からレガシー端末からアソシエーション要求フレームを送信することを防止できる。例えばビーコンフレームやプローブ応答フレームの中に入れるサポートレート(Supported Rates)エレメントや拡張サポートレート(Extended Supported Rates)エレメントでBSSメンバーシップセレクター(BSS membership selector)を使い、IEEE802.11n端末を制限したり、IEEE802.11n端末とIEEE802.11ac端末を制限したりすることができる。
レガシー端末の接続を最初から(すなわち、アソシエーションプロセス時に)拒否すること以外に、最初は接続を許可しつつ、途中から接続を切断することも可能である。レガシー端末との接続を切断するため、基地局は、接続切断フレーム(Disassociation Frame)を送信し、接続切断フレームには、接続切断を示す情報を設定すればよい。IEEE802.11規格では、アソシエーション応答フレームの状況コードに対し、接続切断フレームでは理由コード(Reason Code)を用いて接続切断の理由を示す。理由コードの番号として、前述状況コードと同様、既存の値を用いてもよい。既存の理由コードとして使えるものとしては、例えば次のようなものがある。不特定の理由(Unspecified reason)の意味を持つ“1”、接続している全ての端末を処理できないため切断(Disassociated because AP is unable to handle all currently associated STAs)の意味を持つ“5”、不特定のQoS(Quality of Service)関係の理由で切断(Disassociated for unspecified, QoS−related reason)の意味を持つ“32”、QoS基地局が当該QoS端末のための十分な帯域を確保できないため切断(Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA)の意味を持つ“33”。現時点で予備(Reserved)として未使用である数値の中から選択した番号を、新たに本実施形態の趣旨を明示した接続切断として定義して用いてもよい。明示する理由としては、例えば、MU−MC機能に対応しないことによる切断や、キャリアセンス要件を満たさないことによる切断、などを使うことができる。レガシー端末は、基地局から受信する接続切断フレームから理由コードを読み出し解釈することで、自装置の接続が切断されたことを明示的に認識する。理由コードによって明示的に接続の切断を通知することで、その後、レガシー端末から再度アソシエーション要求フレームが送信されること等に起因するシステム効率の低下を防止できる。レガシー端末との切断を決定するタイミングとしては、前述したようなMU−MC通信の機能をオンにすることに応じたタイミングでもよいし、同じく前述したような、BSS内で混雑、大量データのやりとり、または多数フレームのやり取り等が発生していることが検出されたタイミングでもよい。または、最初は基地局のBSS内のレガシー端末のみが属している場合において、1台または複数台の一定数のMU−MC対応端末が当該BSS内に新たに参入したタイミングでもよい。
(第9の実施形態)
第2〜第8の実施形態では、レガシー端末のチャネル幅を制限または基地局への接続を拒否(または切断)する場合を示したが、逆にチャネル幅の制限を解除、または基地局への接続を許可することも可能である。この際の判断の基準としては、第2〜第8の実施形態で制限または拒否(または切断)を決定したのと反対の基準を用いればよい。すなわち、第2〜第8の実施形態で判断した根拠が解消した場合は、チャネル幅の制限を解除、または基地局への接続を許可すればよい。チャネル幅の制限を解除する場合は、後述する第10の実施形態で示すフレームやビーコンフレーム等の管理フレームで、解除後のチャネル幅の情報を通知すればよい。チャネル幅の制限を解除する例として、20MHzチャネル幅に制限していた場合に、40MHzのチャネル幅に戻す場合や、40MHzチャネル幅に制限していた場合に、80MHzのチャネル幅に変更する場合がある。解除後のチャネル幅の情報は、解除前のチャネル幅より大きく、対応可能なチャネル幅以下である第3情報に対応する。また、基地局への接続を許可する場合は、ビーコンフレームやプローブ応答フレームにレガシー端末の接続を拒否するために設けた設定を解除してフレーム送信するようにすればよい。そしてそれ以降、接続要求をレガシー端末から受信した際には接続を許可すればよい。
(第10の実施形態)
第2〜第9の実施形態では、システムの起動時のみならず、途中からレガシー端末のチャネル幅を制限(または制限を解除)する場合を示したが、途中からチャネル幅を制限(または制限を解除)するために使用するフレームの例を示す。一例として、チャネル切替告知(Channel Switch Announcement)フレームや、拡張チャネル切替告知フレーム(Extended Channel Switch Announcement)フレームを用いることができる。
Channel Switch Announcementフレームを用いる場合、Channel Switch AnnouncementフレームにおけるSecondary Channel Offsetエレメント内のSecondary Channel Offsetフィールドに、変更後のチャネル幅に応じた値を設定すればよい。図21(A)にSecondary Channel Offsetエレメントのフォーマット例を示す。Secondary Channel OffsetエレメントのSecondary Channel Offsetサブフィールドで、primaryチャネルに対するsecondaryチャネルの位置を指定する。例えば20MHzから40MHzあるいは40MHzより広いチャネル幅に変更する場合において、primaryチャネルの上側(高周波側)にsecondaryチャネルを設けるときは、当該フィールドの値を1にし、下側(低周波側)にsecondaryチャネルを設けるときは、当該フィールドの値を3にする。また、40MHzあるいは40MHzより広いチャネル幅から20MHzに変更する場合は、当該フィールドの値を0にする。40MHzより広いチャネル幅に変更する場合は合わせて、Wide Bandwidth Channel Switchエレメントを用いる。図21(B)にWide Bandwidth Channel Switchエレメントのフォーマット例を示す。Wide Bandwidth Channel Switchエレメント内のNew Channel Width、New Channel Center Frequency Segment 0の2つのフィールドあるいは、New Channel Center Frequency Segment 1を加えた3つのフィールドを用いることになる。New Channel Widthフィールドで、変更後のチャネル幅を指定する。例えば80MHzであれば1、160MHzであれば2、80+80MHzであれば3を設定する。また、New Channel Center Frequency Segment 0フィールドで、変更後のチャネル幅が80MHzまたは160MHzの場合の中心周波数のインデックスを設定する。変更後のチャネル幅が80+80MHzの場合は、2つの80MHzのうちのprimaryチャネルを含む一方(セグメント0)の中心周波数のインデックスをNew Channel Center Frequency Segment 0フィールドに設定し、2つの80MHzのうちのprimaryチャネルを含まない他方(セグメント1)の中心周波数のインデックスをNew Channel Center Frequency Segment 1フィールドに設定する。
Channel Switch Announcementフレームの代わりに、Extended Channel Switch Announcementフレームを用いることもできる。この場合、Extended Channel Switch Announcementフレーム内のNew Operating Classフィールド及び40MHzより広いチャネル幅へ変更する場合にはWide Bandwidth Channel Switchエレメントを利用してチャネル幅を変更する。Operating Classはチャネル間隔が20MHz幅か40MHz幅かを識別できるように規定されており、そのOperating Classの値をNew Operating Classフィールドに入れる。したがってNew Operating Classフィールドで20MHzから40Hzあるいは40MHzより広いチャネル幅への変更を通知することもできるし、40MHzあるいは40MHzより広いチャネル幅から20MHzへの変更を通知することもできる。なお、これらのフレームの要素はビーコンやプローブ応答フレームにも入れることができる。したがって、途中からチャネル幅の制限するための手段としてビーコンやプローブ応答フレームを用いることもできる。
(第11の実施形態)
第1の実施形態では、MU−MC通信で使用する複数のチャネルを通知するために、新規に定義したMU−MC Operationエレメント(図11、図13〜図17参照)を用いたが、VHT Operationエレメント(図9参照)を流用することも可能である。この場合、VHT OperationエレメントのChannel Widthサブフィールド(1オクテット)の値は、現時点で予備(Reserved)として未使用である値(4〜255)に設定する(図10に示したように現状、0〜3の値が使用されている)。現時点で未使用の値を設定することで、IEEE802.11ac対応端末は、Channel Widthサブフィールドを解釈できないため、IEEE.802.11nレベルでの動作になる。具体的には、IEEE802.11ac対応端末は、HT Operationエレメント(図8参照)に従った動作となる。つまりIEEE802.11ac対応端末は使用チャネル幅を20MHzか40MHzに制限できる。VHT Operationエレメントを利用することで、MU−MC Operationエレメントといった新たな情報エレメントを定義する必要がない利点がある。
現状、Channel Widthサブフィールドの未使用の値(4〜255)のうち、例えば4を80MHzチャネル幅(20MHz幅で連続する4つのチャネル)、5を160MHzチャネル幅(20MHz幅で連続する8個のチャネル)などと定義することができる。このとき、1オクテットの3ビット(例えば下位3ビット)を使って数字の4及び5を表現し、残りの5ビットに中心周波数を表すインデックスを設定するようにしてもよい。
または、例えば4〜255の一部または全部の数字に、使用する複数のチャネルを対応づけて規定しておき、テーブルなどの形式で、基地局及び各端末に事前に保持しておく。例えば数字の4にはチャネル1〜4を対応付け、数字の5にはチャネル1〜8を対応付け、数字の6にはチャネル9〜16を対応付け、数字の7にはチャネル1〜4とチャネル9〜13を対応付けるといったようにする。そして、使用する複数のチャネルに応じた数値を、Channel Widthサブフィールドに設定する。これによれば、テーブル等の情報を事前に用意しておく必要があるものの、短いサブフィールド長でより多くのバリエーションの使用チャネルの指定が可能になる。
上述した2つの例では、Channel Widthサブフィールドのみを使って表現ンしたが、Channel Center Frequency Segment0及び1の各サブフィールドを追加で使用する方法も可能である。Channel Center Frequency Segment0及び1の各サブフィールドの利用方法は、これまで述べた説明と同一とし、Channel Widthサブフィールドの解釈のみ新規に定める。例えば、4〜255のうち、数値4は、80MHzチャネル幅、数値5は160MHz、数値6は80+80チャネル幅などとする。これによれば、VHT Operationエレメントの解釈方法に大きな変更を加えることなく、MU−MC通信で使用する複数のチャネルを通知することが可能になる。なお現行のVHT Operationエレメントでは2つのセグメント(連続したチャネルの塊)までしか表現できないが、IEEE802.11ac対応のレガシー端末がLength値が5以上になることを許容すると期待できれば、図9の、例えばBasic VHT−MCS and NSS
setフィールドの後にSegment 3、Segment 4、…のように必要に応じて追加することができ、3つ以上のセグメントを使用できるようになり、柔軟なチャネル利用が可能となる。
ここで述べた方法以外にも、VHT Operationエレメントを利用して、MU−MC通信で使用する複数のチャネルを通知可能な限り、様々なサブフィールド(Channel Width、Channel Center Frequency Segment0及び1)の利用が可能である。
(第12の実施形態)
図22は、端末(非基地局の端末)または基地局の全体構成例を示したものである。この構成例は一例であり、本実施形態はこれに限定されるものではない。端末または基地局は、1つまたは複数のアンテナ1〜n(nは1以上の整数)と、無線LANモジュール148と、ホストシステム149を備える。無線LANモジュール148は、第1の実施形態に係る無線通信装置に対応する。無線LANモジュール148は、ホスト・インタフェースを備え、ホスト・インタフェースで、ホストシステム149と接続される。接続ケーブルを介してホストシステム149と接続される他、ホストシステム149と直接接続されてもよい。また、無線LANモジュール148が基板にはんだ等で実装され、基板の配線を介してホストシステム149と接続される構成も可能である。ホストシステム149は、任意の通信プロトコルに従って、無線LANモジュール148およびアンテナ1〜nを用いて、外部の装置と通信を行う。通信プロトコルは、TCP/IPと、それより上位の層のプロトコルと、を含んでもよい。または、TCP/IPは無線LANモジュール148に搭載し、ホストシステム149は、それより上位層のプロトコルのみを実行してもよい。この場合、ホストシステム149の構成を簡単化できる。本端末は、例えば、移動体端末、TV、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Webカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ/サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等でもよい。
図23は、無線LANモジュールのハードウェア構成例を示す。この構成は、無線通信装置が非基地局の端末および基地局のいずれに搭載される場合にも適用可能である。つまり、図1に示した無線通信装置の具体的な構成の一例として適用できる。この構成例では、アンテナは1本のみであるが、2本以上のアンテナを備えていてもよい。この場合、各アンテナに対応して、送信系統(216、222〜225)、受信系統(232〜235)、PLL242、水晶発振器(基準信号源)243およびスイッチ245のセットが複数配置され、各セットがそれぞれ制御回路212に接続されてもよい。PLL242または水晶発振器243またはこれらの両方は、本実施形態に係る発振器に対応する。
無線LANモジュール(無線通信装置)は、ベースバンドIC(Integrated Circuit)211と、RF(Radio Frequency)IC221と、バラン225と、スイッチ245と、アンテナ247とを備える。
ベースバンドIC211は、ベースバンド回路(制御回路)212、メモリ213、ホスト・インタフェース214、CPU215、DAC(Digital to Analog Conveter)216、およびADC(Analog to Digital Converter)217を備える。
ベースバンドIC211とRF IC221は同じ基板上に形成されてもよい。また、ベースバンドIC211とRF IC221は1チップで構成されてもよい。DAC216およびADC217の両方またはいずれか一方が、RF IC221に配置されてもよいし、別のICに配置されてもよい。またメモリ213およびCPU215の両方またはいずれか一方が、ベースバンドICとは別のICに配置されてもよい。
メモリ213は、ホストシステムとの間で受け渡しするデータを格納する。またメモリ213は、端末または基地局に通知する情報、または端末または基地局から通知された情報、またはこれらの両方を格納する。また、メモリ213は、CPU215の実行に必要なプログラムを記憶し、CPU215がプログラムを実行する際の作業領域として利用されてもよい。メモリ213はSRAM、DRAM等の揮発性メモリでもよいし、NAND、MRAM等の不揮発メモリでもよい。
ホスト・インタフェース214は、ホストシステムと接続するためのインタフェースである。インタフェースは、UART、SPI、SDIO、USB、PCI Expressなど何でも良い。
CPU215は、プログラムを実行することによりベースバンド回路212を制御するプロセッサである。ベースバンド回路212は、主にMAC層の処理および物理層の処理を行う。ベースバンド回路212、CPU215またはこれらの両方は、通信を制御する通信制御装置、または通信を制御する制御部に対応する。
ベースバンド回路212およびCPU215の少なくとも一方は、クロックを生成するクロック生成部を含み、当該クロック生成部で生成するクロックにより、内部時間を管理してもよい。
ベースバンド回路212は、送信するフレームに、物理層の処理として、物理ヘッダの付加、符号化、暗号化、変調処理など行い、例えば2種類のデジタルベースバンド信号(以下、デジタルI信号とデジタルQ信号)を生成する。
DAC216は、ベースバンド回路212から入力される信号をDA変換する。より詳細には、DAC216はデジタルI信号をアナログのI信号に変換し、デジタルQ信号をアナログのQ信号に変換する。なお、直交変調せずに一系統の信号のままで送信する場合もありうる。複数のアンテナを備え、一系統または複数系統の送信信号をアンテナの数だけ振り分けて送信する場合には、アンテナの数に応じた数のDAC等を設けてもよい。
RF IC221は、一例としてRFアナログICあるいは高周波IC、あるいはこれらの両方である。RF IC221は、フィルタ222、ミキサ223、プリアンプ(PA)224、PLL(Phase Locked Loop:位相同期回路)242、低雑音増幅器(LNA)、バラン235、ミキサ233、およびフィルタ232を備える。これらの要素のいくつかが、ベースバンドIC211または別のIC上に配置されてもよい。フィルタ222、232は、帯域通過フィルタでも、低域通過フィルタでもよい。
フィルタ222は、DAC216から入力されるアナログI信号およびアナログQ信号のそれぞれから所望帯域の信号を抽出する。PLL242は、水晶発振器243から入力される発振信号を用い、発振信号を分周または逓倍またはこれらの両方を行うことで、入力信号の位相に同期した、一定周波数の信号を生成する。なお、PLL242は、VCO(Voltage Controlled Oscillator)を備え、水晶発振器243から入力される発振信号に基づき、VCOを利用してフィードバック制御を行うことで、当該一定周波数の信号を得る。生成した一定周波数の信号は、ミキサ223およびミキサ233に入力される。PLL242は、一定周波数の信号を生成する発振器の一例に相当する。
ミキサ223は、フィルタ222を通過したアナログI信号およびアナログQ信号を、PLL242から供給される一定周波数の信号を利用して、無線周波数にアップコンバートする。プリアンプ(PA)は、ミキサ223で生成された無線周波数のアナログI信号およびアナログQ信号を、所望の出力電力まで増幅する。バラン225は、平衡信号(差動信号)を不平衡信号(シングルエンド信号)に変換するための変換器である。RF IC221では平衡信号が扱われるが、RF IC221の出力からアンテナ247までは不平衡信号が扱われるため、バラン225で、これらの信号変換を行う。
スイッチ245は、送信時は、送信側のバラン225に接続され、受信時は、受信側の低雑音増幅器(LNA)234またはRF IC221に接続される。スイッチ245の制御はベースバンドIC211またはRF IC221により行われてもよいし、スイッチ245を制御する別の回路が存在し、当該回路からスイッチ245の制御を行ってもよい。
プリアンプ224で増幅された無線周波数のアナログI信号およびアナログQ信号は、バラン225で平衡−不平衡変換された後、アンテナ247から空間に電波として放射される。
アンテナ247は、チップアンテナでもよいし、プリント基板上に配線により形成したアンテナでもよいし、線状の導体素子を利用して形成したアンテナでもよい。
RF IC221におけるLNA234は、アンテナ247からスイッチ245を介して受信した信号を、雑音を低く抑えたまま、復調可能なレベルまで増幅する。バラン235は、低雑音増幅器(LNA)234で増幅された信号を、不平衡−平衡変換する。なお、バラン235とLNA234の順番を逆にした構成でもよい。ミキサ233は、バラン235で平衡信号に変換された受信信号を、PLL242から入力される一定周波数の信号を用いてベースバンドにダウンコンバートする。より詳細には、ミキサ233は、PLL242から入力される一定周波数の信号に基づき、互いに90°位相のずれた搬送波を生成する手段を有し、バラン235で変換された受信信号を、互いに90°位相のずれた搬送波により直交復調して、受信信号と同位相のI(In−phase)信号と、これより90°位相が遅れたQ(Quad−phase)信号とを生成する。フィルタ232は、これらI信号とQ信号から所望周波数成分の信号を抽出する。フィルタ232で抽出されたI信号およびQ信号は、ゲインが調整された後に、RF IC221から出力される。
ベースバンドIC211におけるADC217は、RF IC221からの入力信号をAD変換する。より詳細には、ADC217はI信号をデジタルI信号に変換し、Q信号をデジタルQ信号に変換する。なお、直交復調せずに一系統の信号だけを受信する場合もあり得る。
複数のアンテナが設けられる場合には、アンテナの数に応じた数のADCを設けてもよい。ベースバンド回路212は、デジタルI信号およびデジタルQ信号に基づき、復調処理、誤り訂正符号処理、物理ヘッダの処理など、物理層の処理等を行い、フレームを得る。ベースバンド回路212は、フレームに対してMAC層の処理を行う。なお、ベースバンド回路212は、TCP/IPを実装している場合は、TCP/IPの処理を行う構成も可能である。
上述した各部の処理の詳細は、図1の説明から自明であるため、重複する説明は省略する。
(第13の実施形態)
図24(A)及び図24(B)は、それぞれ第13の実施形態に係る無線機器の斜視図である。図24(A)の無線機器はノートPC301であり、図24(B)の無線機器は移動体端末321である。それぞれ、端末(基地局を含む)の一形態に対応する。ノートPC301及び移動体端末321は、それぞれ無線通信装置305、315を搭載している。無線通信装置305、315として、これまで説明してきた端末(基地局を含む)に搭載されていた無線通信装置を用いることができる。無線通信装置を搭載する無線機器は、ノートPCや移動体端末に限定されない。例えば、TV、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン等にも搭載可能である。
また、端末(基地局を含む)に搭載されていた無線通信装置は、メモリーカードにも搭載可能である。当該無線通信装置をメモリーカードに搭載した例を図25に示す。メモリーカード331は、無線通信装置355と、メモリーカード本体332とを含む。メモリーカード331は、外部の装置との無線通信のために無線通信装置335を利用する。なお、図25では、メモリーカード331内の他の要素(例えばメモリ等)の記載は省略している。
(第14の実施形態)
第14の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、バス、プロセッサ部、及び外部インタフェース部を備える。プロセッサ部及び外部インタフェース部は、バスを介してバッファと接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。
(第15の実施形態)
第15の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、クロック生成部を備える。クロック生成部は、クロックを生成して出力端子より無線通信装置の外部にクロックを出力する。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側とを同期させて動作させることが可能となる。
(第16の実施形態)
第16の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、電源部、電源制御部、及び無線電力給電部を含む。電源制御部は、電源部と無線電力給電部とに接続され、無線通信装置に供給する電源を選択する制御を行う。このように、電源を無線通信装置に備える構成とすることにより、電源を制御した低消費電力化動作が可能となる。
(第17の実施形態)
第17の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、SIMカードを含む。SIMカードは、例えば、無線通信装置におけるMAC処理部10、MAC/PHY管理部60、または、制御部112と接続される。このように、SIMカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。
(第18の実施形態)
第18の実施形態では、第16の実施形態に係る無線通信装置の構成に加えて、動画像圧縮/伸長部を含む。動画像圧縮/伸長部は、バスと接続される。このように、動画像圧縮/伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長とを容易に行うことが可能となる。
(第19の実施形態)
第19の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、LED部を含む。LED部は、例えば、MAC処理部10、MAC/PHY管理部60、送信処理回路113、受信処理回路114、制御部112の少なくとも1つと接続される。このように、LED部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
(第20の実施形態)
第20の実施形態では、上述した実施形態に係る無線通信装置の構成に加えて、バイブレータ部を含む。バイブレータ部は、例えば、MAC処理部10、MAC/PHY管理部60、送信処理回路113、受信処理回路114、制御部112の少なくとも1つと接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
(第21の実施形態)
本実施形態では、[1]無線通信システムにおけるフレーム種別、[2]無線通信装置間の接続切断の手法、[3]無線LANシステムのアクセス方式、[4]無線LANのフレーム間隔について説明する。
[1]通信システムにおけるフレーム種別
一般的に無線通信システムにおける無線アクセスプロトコル上で扱うフレームは、前述したように、大別してデータ(data)フレーム、管理(management)フレーム、制御(control)フレームの3種類に分けられる。これらの種別は、通常、フレーム間で共通に設けられるヘッダ部で示される。フレーム種別の表示方法としては、1つのフィールドで3種類を区別できるようにしてあってもよいし、2つのフィールドの組み合わせで区別できるようにしてあってもよい。IEEE802.11規格では、フレーム種別の識別は、MACフレームのフレームヘッダ部にあるFrame Controlフィールドの中のType、Subtypeという2つのフィールドで行う。データフレームか、管理フレームか、制御フレームかの大別はTypeフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のBeaconフレームといった識別はSubtypeフィールドで行われる。
管理フレームは、他の無線通信装置との間の物理的な通信リンクの管理に用いるフレームである。例えば、他の無線通信装置との間の通信設定を行うために用いられるフレームや通信リンクをリリースする(つまり接続を切断する)ためのフレーム、無線通信装置でのパワーセーブ動作に係るフレームがある。
データフレームは、他の無線通信装置と物理的な通信リンクが確立した上で、無線通信装置の内部で生成されたデータを他の無線通信装置に送信するフレームである。データは本実施形態の上位層で生成され、例えばユーザの操作によって生成される。
制御フレームは、データフレームを他の無線通信装置との間で送受(交換)する際の制御に用いられるフレームである。無線通信装置がデータフレームや管理フレームを受信した場合にその送達確認のために送信される応答フレームは、制御フレームに属する。応答フレームは、例えばACKフレームやBlockACKフレームである。またRTSフレームやCTSフレームも制御フレームである。
これら3種類のフレームは、物理層で必要に応じた処理を経て物理パケットとしてアンテナを経由して送出される。なお、IEEE802.11規格(前述のIEEE Std
802.11ac−2013などの拡張規格を含む)では接続確立の手順の1つとしてアソシエーション(association)プロセスがあるが、その中で使われるAssociation RequestフレームとAssociation Responseフレームが管理フレームであり、Association RequestフレームやAssociation Responseフレームはユニキャストの管理フレームであることから、受信側無線通信端末に応答フレームであるACKフレームの送信を要求し、このACKフレームは上述のように制御フレームである。
[2]無線通信装置間の接続切断の手法
接続の切断(リリース)には、明示的な手法と暗示的な手法とがある。明示的な手法としては、接続を確立している無線通信装置間のいずれか一方が切断のためのフレームを送信する。IEEE802.11規格ではDeauthenticationフレームがこれに当たり、管理フレームに分類される。通常、接続を切断するフレームを送信する側の無線通信装置では当該フレームを送信した時点で、接続を切断するフレームを受信する側の無線通信装置では当該フレームを受信した時点で、接続の切断と判定する。その後、非基地局の無線通信端末であれば通信フェーズでの初期状態、例えば接続するBSS探索する状態に戻る。無線通信基地局がある無線通信端末との間の接続を切断した場合には、例えば無線通信基地局が自BSSに加入する無線通信端末を管理する接続管理テーブルを持っているならば当該接続管理テーブルから当該無線通信端末に係る情報を削除する。例えば、無線通信基地局が自BSSに加入する各無線通信端末に接続をアソシエーションプロセスで許可した段階で、AIDを割り当てる場合には、当該接続を切断した無線通信端末のAIDに関連づけられた保持情報を削除し、当該AIDに関してはリリースして他の新規加入する無線通信端末に割り当てられるようにしてもよい。
一方、暗示的な手法としては、接続を確立した接続相手の無線通信装置から一定期間フレーム送信(データフレーム及び管理フレームの送信、あるいは自装置が送信したフレームへの応答フレームの送信)を検知しなかった場合に、接続状態の切断の判定を行う。このような手法があるのは、上述のように接続の切断を判定するような状況では、接続先の無線通信装置と通信距離が離れて無線信号が受信不可あるいは復号不可になるなど物理的な無線リンクが確保できない状態が考えられるからである。すなわち、接続を切断するフレームの受信を期待できないからである。
暗示的な方法で接続の切断を判定する具体例としては、タイマを使用する。例えば、送達確認応答フレームを要求するデータフレームを送信する際、当該フレームの再送期間を制限する第1のタイマ(例えばデータフレーム用の再送タイマ)を起動し、第1のタイマが切れるまで(つまり所望の再送期間が経過するまで)当該フレームへの送達確認応答フレームを受信しないと再送を行う。当該フレームへの送達確認応答フレームを受信すると第1のタイマは止められる。
一方、送達確認応答フレームを受信せず第1のタイマが切れると、例えば接続相手の無線通信装置がまだ(通信レンジ内に)存在するか(言い換えれば、無線リンクが確保できているか)を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第2のタイマ(例えば管理フレーム用の再送タイマ)を起動する。第1のタイマと同様、第2のタイマでも、第2のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第2のタイマが切れると接続が切断されたと判定する。接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。
あるいは、接続相手の無線通信装置からフレームを受信すると第3のタイマを起動し、新たに接続相手の無線通信装置からフレームを受信するたびに第3のタイマを止め、再び初期値から起動する。第3のタイマが切れると前述と同様に接続相手の無線通信装置がまだ(通信レンジ内に)存在するか(言い換えれば、無線リンクが確保できているか)を確認するための管理フレームを送信し、それと同時に当該フレームの再送期間を制限する第2のタイマ(例えば管理フレーム用の再送タイマ)を起動する。この場合も、第2のタイマが切れるまで当該フレームへの送達確認応答フレームを受信しないと再送を行い、第2のタイマが切れると接続が切断されたと判定する。この場合も、接続が切断されたと判定した段階で、前記接続を切断するフレームを送信するようにしてもよい。後者の、接続相手の無線通信装置がまだ存在するかを確認するための管理フレームは、前者の場合の管理フレームとは異なるものであってもよい。また後者の場合の管理フレームの再送を制限するためのタイマは、ここでは第2のタイマとして前者の場合と同じものを用いたが、異なるタイマを用いるようにしてもよい。
[3]無線LANシステムのアクセス方式
例えば、複数の無線通信装置と通信または競合することを想定した無線LANシステムがある。IEEE802.11無線LANではCSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)をアクセス方式の基本としている。ある無線通信装置の送信を把握し、その送信終了から固定時間を置いて送信を行う方式では、その無線通信装置の送信を把握した複数の無線通信装置で同時に送信を行うことになり、その結果、無線信号が衝突してフレーム送信に失敗する。ある無線通信装置の送信を把握し、その送信終了からランダム時間待つことで、その無線通信装置の送信を把握した複数の無線通信装置での送信が確率的に分散することになる。よって、ランダム時間の中で最も早い時間を引いた無線通信装置が1つなら無線通信装置のフレーム送信は成功し、フレームの衝突を防ぐことができる。ランダム値に基づき送信権の獲得が複数の無線通信装置間で公平になることから、Carrier Avoidanceを採用した方式は、複数の無線通信装置間で無線媒体を共有するために適した方式であるということができる。
[4]無線LANのフレーム間隔
IEEE802.11無線LANのフレーム間隔について説明する。IEEE802.11無線LANで用いられるフレーム間隔は、distributed coordination function interframe space(DIFS)、arbitration interframe space(AIFS)、point coordination function interframe space(PIFS)、short interframe space(SIFS)、extended interframe space(EIFS)、reduced interframe space(RIFS)の6種類ある。
フレーム間隔の定義は、IEEE802.11無線LANでは送信前にキャリアセンスアイドルを確認して開けるべき連続期間として定義されており、厳密な前のフレームからの期間は議論しない。従ってここでのIEEE802.11無線LANシステムでの説明においてはその定義を踏襲する。IEEE802.11無線LANでは、CSMA/CAに基づくランダムアクセスの際に待つ時間を固定時間とランダム時間との和としており、固定時間を明確にするため、このような定義になっているといえる。
DIFSとAIFSとは、CSMA/CAに基づき他の無線通信装置と競合するコンテンション期間にフレーム交換開始を試みるときに用いるフレーム間隔である。DIFSは、トラヒック種別による優先権の区別がないとき、AIFSはトラヒック種別(Traffic Identifier:TID)による優先権が設けられている場合に用いる。
DIFSとAIFSとで係る動作としては類似しているため、以降では主にAIFSを用いて説明する。IEEE802.11無線LANでは、MAC層でフレーム交換の開始などを含むアクセス制御を行う。さらに、上位層からデータを渡される際にQoS(Quality of Service)対応する場合には、データとともにトラヒック種別が通知され、トラヒック種別に基づいてデータはアクセス時の優先度のクラス分けがされる。このアクセス時のクラスをアクセスカテゴリ(Access Category:AC)と呼ぶ。従って、アクセスカテゴリごとにAIFSの値が設けられることになる。
PIFSは、競合する他の無線通信装置よりも優先権を持つアクセスができるようにするためのフレーム間隔であり、DIFS及びAIFSのいずれの値よりも期間が短い。SIFSは、応答系の制御フレームの送信時あるいは一旦アクセス権を獲得した後にバーストでフレーム交換を継続する場合に用いることができるフレーム間隔である。EIFSはフレーム受信に失敗した(受信したフレームがエラーであると判定した)場合に発動されるフレーム間隔である。
RIFSは一旦アクセス権を獲得した後にバーストで同一無線通信装置に複数のフレームを連続して送信する場合に用いることができるフレーム間隔であり、RIFSを用いている間は送信相手の無線通信装置からの応答フレームを要求しない。
ここでIEEE802.11無線LANにおけるランダムアクセスに基づく競合期間のフレーム交換の一例を図26に示す。
ある無線通信装置においてデータフレーム(W_DATA1)の送信要求が発生した際に、キャリアセンスの結果、媒体がビジーである(busy medium)と認識する場合を想定する。この場合、キャリアセンスがアイドルになった時点から固定時間のAIFSを空け、その後ランダム時間(random backoff)空いたところで、データフレームW_DATA1を通信相手に送信する。なお、キャリアセンスの結果、媒体がビジーではない、つまり媒体がアイドル(idle)であると認識した場合には、キャリアセンスを開始した時点から固定時間のAIFSを空けて、データフレームW_DATA1を通信相手に送信する。
ランダム時間は0から整数で与えられるコンテンションウィンドウ(Contention Window:CW)の間の一様分布から導かれる擬似ランダム整数にスロット時間をかけたものである。ここで、CWにスロット時間をかけたものをCW時間幅と呼ぶ。CWの初期値はCWminで与えられ、再送するたびにCWの値はCWmaxになるまで増やされる。CWminとCWmaxとの両方とも、AIFSと同様アクセスカテゴリごとの値を持つ。W_DATA1の送信先の無線通信装置では、データフレームの受信に成功し、かつ当該データフレームが応答フレームの送信を要求するフレームであるとそのデータフレームを内包する物理パケットの無線媒体上での占有終了時点からSIFS後に応答フレーム(W_ACK1)を送信する。W_DATA1を送信した無線通信装置は、W_ACK1を受信すると送信バースト時間制限内であればまたW_ACK1を内包する物理パケットの無線媒体上での占有終了時点からSIFS後に次のフレーム(例えばW_DATA2)を送信することができる。
AIFS、DIFS、PIFS及びEIFSは、SIFSとスロット時間との関数になるが、SIFSとスロット時間とは物理層ごとに規定されている。また、AIFS、CWmin及びCWmaxなどアクセスカテゴリごとに値が設けられるパラメータは、通信グループ(IEEE802.11無線LANではBasic Service Set(BSS))ごとに設定可能であるが、デフォルト値が定められている。
例えば、802.11acの規格策定では、SIFSは16μs、スロット時間は9μsであるとして、それによってPIFSは25μs、DIFSは34μs、AIFSにおいてアクセスカテゴリがBACKGROUND(AC_BK)のフレーム間隔はデフォルト値が79μs、BEST EFFORT(AC_BE)のフレーム間隔はデフォルト値が43μs、VIDEO(AC_VI)とVOICE(AC_VO)のフレーム間隔はデフォルト値が34μs、CWminとCWmaxとのデフォルト値は、各々AC_BKとAC_BEとでは31と1023、AC_VIでは15と31、AC_VOでは7と15になるとする。なお、EIFSは、基本的にはSIFSとDIFSと最も低速な必須の物理レートで送信する場合の応答フレームの時間長の和である。なお効率的なEIFSの取り方ができる無線通信装置では、EIFSを発動した物理パケットへの応答フレームを運ぶ物理パケットの占有時間長を推定し、SIFSとDIFSとその推定時間の和とすることもできる。本実施形態では、このようなフレーム間隔のパラメータを用いる無線通信システムを通信レンジの広い干渉システムとして想定する。
なお、各実施形態において基地局または複数の端末が送信するフレームは、異なる内容のフレームであっても、同一の内容のフレームでもよい。一般的な表現として、基地局または複数の端末が第Xのフレームを送信または基地局が複数の第Xフレームを受信すると表現するとき、これらの第Xのフレームの内容は同じであっても、異なってもよい。
なお、各実施形態で記載されているフレームは、Null Data Packetなど、IEEE802.11規格または準拠する規格で、パケットと呼ばれるものを指してもよい。
本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置(CPU)、マイクロプロセッサ、デジタル信号プロセッサ(DSP)、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ(FPGA)、プログラム可能論理回路 (PLD)などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、DSPおよびマイクロプロセッサの組み合わせ、DSPコアと協働する1つ以上のマイクロプロセッサを指してもよい。
別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、プログラム可能読み出し専用メモリ(PROM)、消去可能プログラム可能読み出し専用メモリ(EPROM)、電気的消去可能PROM(EEPROM)、不揮発性ランダムアクセスメモリ(NVRAM)、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。