以下、図面を参照しながら、本発明の実施形態について説明する。無線LANの規格として知られているIEEE Std 802.11−2012およびIEEE Std 802.11ac−2013、ならびに、次世代無線LAN規格であるIEEE Std 802.11ax用の仕様フレームワーク文書(Specification Framework Document)であるIEEE 802.11−15/0132r15は、本明細書においてその全てが参照によって組み込まれる(incorporated by reference)ものとする。
(第1の実施形態)
図1に、第1の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局(以下、基地局)、または無線通信基地局と通信する無線通信端末(以下、端末)に実装されることができる。基地局は、主に中継機能を有する点で端末とは異なり、その他は基本的に端末と同様の通信機能を有するため、端末の一形態であると考えることができる。以下の説明で端末と言うときは、特に両者を区別する必要がない限り、基地局を指してもよい。
本実施形態では、アップリンクMU−MIMO(UL−MU−MIMO:Uplink Muti−User MU−MIMO)およびアップリンクOFDMA(UL−OFDMA:Orthogonal Frequency Division Multiple Access)の少なくともいずれかのアップリンクマルチユーザ(UL−MU)送信を行う場合を想定する。なお、基地局および端末は、UL−MU(UL−MU−MIMOまたはUL−OFDMA)のみならず、ダウンリンクMU−MIMO(DL−MU−MIMO)およびダウンリンクOFDMA(DL−OFDMA)の少なくともいずれかのダウンリンクマルチユーザ(DL−MU)送信を実施する能力を有していてもよい。UL−MU送信は、アップリンクのユーザ多重送信に対応し、DL−MU送信は、ダウンリンクのユーザ多重送信に対応する。なお、UL−MU送信としてUL−MU−MIMOとUL−OFDMAを組み合わせた通信方式、およびDL−MU送信DL−MU−MIMOとDL−OFDMAを組み合わせた通信方式も可能である。
図2(A)にUL−MU−MIMO送信の概要を示す。UL−MU−MIMO送信では、複数の端末から基地局に空間多重で(同一周波数帯域で同時に)、データストリーム(以下ストリーム)を送信し、基地局が複数のアンテナでこれらストリームを同時に受信する。図の例では、複数の端末1〜4(STA1〜STA4)が、基地局であるアクセスポイント(AP)に、1チャネル(ここではチャネルMと記述している)幅の同一周波数帯域で同時にストリームを送信、すなわち空間多重送信する。アクセスポイントが、これらのストリームを同時に受信し、MIMO復調することで、各端末のフレームに分離する。UL−MU−MIMO送信では、同時に複数の端末からフレームを送信できるため、システムスループットを向上させることができる。なお、UL−MU−MIMO送信の最大の多重可能なデータストリームの数は、アクセスポイントのアンテナ数によって制限される。一例として、アクセスポイントが4つのアンテナを有する場合、最大多重可能ストリーム数は4である。各端末が1つのアンテナを備える場合、それぞれ1ストリームのみを送信可能である。ある1台の端末が、複数のアンテナを備えて、複数のストリームの送信を行うことも可能である。なお、DL−MU−MIMOの場合、通信の方向が、アクセスポイントから各端末への方向になる点が異なる。DL−MU−MIMOでは、基地局から複数の端末に空間多重で(同一周波数帯域で同時に)ストリームを送信し、各端末は自端末宛のストリームを受信して復号する。
図2(B)にUL−OFDMA送信の概要を示す。UL−OFDMAでは、1つまたは複数のサブキャリアをリソースブロック(サブチャネル、リソースユニット、周波数ブロックと呼んでもよい)として端末に割り当て、リソースブロックベースで、複数の端末からの受信を同時に行う。図の例では、1チャネル(ここではチャネルMと記述している)内の連続した周波数領域内で1つまたは複数の連続するサブキャリアを一単位とするリソースブロックを端末に各々割り当てて、複数端末から同時に受信を行う。より詳細には、アクセスポイント(AP)が、1チャネルに含まれる4つのリソースブロック(RB)1〜4を、複数の端末1〜4(STA1〜4)にそれぞれ割り当て、複数の端末1〜4からそれぞれに割り当てられたリソースブロックで同時に送信する。これにより、端末1〜4から基地局へのUL−OFDMA送信を行う。各端末に割り当てるリソースブロックは、互いに異なり、互いに重複しない。なお、DL−OFDMAの場合、通信の方向が、アクセスポイントから各端末への方向になる点が異なる。DL−OFDMAでは、1つまたは複数のサブキャリアをリソースブロックとして端末に割り当て、リソースブロックベースで、アクセスポイントから複数の端末に同時に送信を行う。
OFDMAについてさらに詳細に説明する。図3に、周波数領域に複数のチャネルが配置される様子を示す。チャネル間にはガードバンドが設けられている。1つのチャネルの帯域幅は、例えば20MHzである。そのうちの1つのチャネル(ここではチャネルM)の連続する帯域を用いてOFDMA通信を行う場合が、図2(B)に対応する。チャネルMの連続する帯域(例えば20MHz幅帯域)には互いに直交する複数のサブキャリア(20MHz帯域の場合、例えば52本)が配置されており、これらのサブキャリアに基づき、1つまたは複数の連続するサブキャリアを一単位とするリソースブロックを端末1、端末2、・・・端末K(Kは2以上の整数。図2(B)の例ではK=4)に割り当てる。なお、リソースブロックごとの帯域幅(あるいはサブキャリア数)は各リソースブロックで共通とするが、リソースブロックごとに帯域幅(あるいはサブキャリア数)が異なることを許容してもよい。また、各端末に割り当てるリソースブロック数は、端末1台あたり1つのリソースブロックであることに限定されず、1台に複数のリソースブロックを割り当ててもよいし、端末ごとに割り当てるリソースブロック数が異なってもよい。リソースブロックが複数のサブキャリアで構成される場合は、リソースブロックに含まれる各サブキャリアの配置が連続していても連続していなくてもよい。1台の端末に、リソースブロックとして、非連続に配置された複数のサブキャリアを割り当てることも可能である。
また、図3の例では、各端末に割り当てるリソースブロック間に少なくとも1つのサブキャリアが、ガードサブキャリアとして配置されている。リソースブロック間に配置するガードサブキャリアの個数は、事前にシステムまたは仕様で定められていてもよいし、任意に定めてもよい。また、リソースブロック間にガードサブキャリアを配置することは必須ではなく、リソースブロック間にガードサブキャリアを配置しないことを許容してもよい。
またOFDMA通信で使用するチャネル数は、1つに限定されず、2つ以上のチャネルを用いてOFDMA通信を行うことも可能である。この際、チャネルごとに独立して、上述のように各チャネル内でリソースブロックの割り当てを行ってもよい。この際、1つの端末が異なるチャネルに属する複数のリソースブロックの割り当てを受けることを許容してもよい。またチャネルごとに独立してリソースブロックの割り当てを行うのではなく、複数のチャネルを結合した連続した周波数領域を定義し、当該結合後の周波数領域内でリソースブロックの割り当てを行ってもよい。例えば周波数的に隣接する20MHz幅の2つのチャネルを結合して40MHzの周波数領域を定義し、当該40MHzの周波数領域内の互いに直交するサブキャリア群に基づきリソースブロックの割り当てを行ってもよい。同様に、20MHz幅の4つのチャネルを結合して80MHzの周波数領域、8つのチャネルを結合して160MHzの周波数領域を定義してもよい。この場合、それぞれの周波数領域内で互いに直交するサブキャリア群に基づき、リソースブロックの割り当てを行えばよい。
なお、OFDMAを実施する端末は、少なくとも後方互換の対象となるレガシー端末での基本チャネル幅(IEEE802.11a/b/g/n/ac規格対応端末をレガシー端末とするなら20MHzチャネル幅)で、フレームを含む物理パケットを受信・復号(誤り訂正符号の復号および復調等を含む)できるものとする。この際、キャリアセンスに関してはチャネル単位で行うものとする。キャリアセンスは、CCA(Clear Channel Assessment)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)と、受信したフレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)との両方を包含してもよい。後者のように、仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、NAV(Network Allocation Vector)と呼ばれる。チャネル単位で行ったCCAまたはNAVに基づくキャリアセンス情報は、チャネル内の全リソースブロックに共通に適用してもよい。例えばキャリアセンス情報がアイドルを示すチャネルに属するリソースブロックは、当該チャネルのキャリアセンス情報を共通に適用して、アイドルであるとして処理を行ってもよい。なお、本実施形態に係る端末はチャネル単位でキャリアセンスを行うことに限定されず、端末がリソースブロック単位でキャリアセンスを行う仕組みを実装しているのであれば、リソースブロック単位でキャリアセンス(物理的および仮想的の両方)を行うことを許容してもよい。
なお、OFDMAは上述したリソースブロックベースのOFDMA以外に、チャネルベースでのOFDMAも可能である。この場合のOFDMAを特にMU−MC(Multi−User Multi−Channel)と呼ぶことがある。MU−MCでは、基地局が複数のチャネルを複数の端末に割り当て、当該複数のチャネルを同時に用いて、複数端末宛て同時送信もしくは複数端末からの同時受信を行う。以降に説明する本実施形態のOFDMAでは、リソースブロックベースのOFDMAを想定するが、以降の説明のリソースブロックをチャネルに読み替えるなど、チャネルベースのOFDMAに即して必要な読み替えを行うことで、チャネルベースのOFDMAの実施形態も実現可能である。
OFDMAと、MU−MIMOとを組み合わせた通信方式(OFDMA&MU−MIMOと呼ぶ)も可能である。この通信方式では、複数のリソースブロックのそれぞれを、複数の端末に割り当て、複数のリソースブロックのそれぞれで同時に、リソースブロック単位でのMU−MIMO送信を行うことになる。アップリンクのOFDMA&MU−MIMO、ダウンリンクのOFDMA&MU−MIMOのいずれも可能である。以降の説明でOFDMAまたはMU−MIMOを指すときは、OFDMA&MU−MIMOでもよいものとする。
以下の説明において、UL−OFDMAおよびUL−MU−MIMOの少なくとも一方を実施する能力を有する端末をUL−MU端末と呼ぶことがある。当該能力を有さない端末をレガシー端末と呼ぶことがある。UL−MU通信を実施する能力を有効(Enable)または無効(Disable)に切り替え可能な場合、当該能力が有効になっている端末をUL−MU端末として考えればよい。UL−MU端末は、DL−OFDMAおよびDL−MU−MIMOの少なくとも一方を実施する能力をさらに備えていてもよい。また、UL−MU端末のうち今回のUL-MU通信の対象として基地局に指定された端末は、UL-MUの対象端末に相当し、今回のUL-MUの対象として基地局に指定されなかった端末は、UL-MUの非対象端末に相当する。
図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などの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはDRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。
上位処理部90は、MAC(Medium Access Control:媒体アクセス制御)層に対して上位層のための処理を行う。上位処理部90は、MAC処理部10との間で信号をやり取りできる。上位層としては、代表的なものとしては、TCP/IPやUDP/IP、さらにその上層のアプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部90は、MAC層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。上位処理部90を介して有線インフラに接続するようになっていてもよい。バッファは、メモリでもよいし、SSD、ハードディスク等でもよい。バッファがメモリの場合、当該メモリはDRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。
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(Radio Frequency)回路を含み、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 dataunit)と呼んでいる。加えて、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)と呼んでいる。また、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は、自端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、自端末が、UL−MU対応端末であるか否か、また、UL−MU対応端末の場合にUL−MUを実施する能力の機能のオン/オフの情報も保持されていてもよい。MIBを保持・管理するためのメモリは、MAC/PHY管理部60に内包させてもよいし、MAC/PHY管理部60に内包せずに別に設けるようにしてもよい。MIBを保持・管理するためのメモリをMAC/PHY管理部60とは別に設ける場合に、MAC/PHY管理部60は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。メモリはDRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。また、メモリでなく、SSDやハードディスク等の記憶装置でもよい。基地局では、非基地局としての他の端末のこれらの情報も、当該端末からの通知により、取得することができる。その場合、MAC/PHY管理部60は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、MIBとは別に保持・管理するようにしてもよい。その場合、MAC/PHY管理部60あるいはMAC共通処理部20が、その別のメモリを参照・書き換えが可能なようにする。また基地局のMAC/PHY管理部60は、UL−MU送信にあたり、非基地局としての端末に関する各種の情報、または端末からの要求に基づき、UL−MU通信用のリソースブロックを同時に割り当てる端末を選定する(すなわち今回のUL−MUの対象となる端末を選定する)グルーピング機能も備えていてもよい。また、MAC/PHY管理部60またはMAC処理部10は、送信するMACフレームおよび物理ヘッダに適用する伝送レートを管理してもよい。また基地局のMAC/PHY管理部60は、基地局がサポートするレートセットであるサポートレートセットを定義してもよい。サポートレートセットは、自局に接続する端末がサポートすることが必須のレートと、オプションのレートを含んでもよい。
MAC処理部10は、データフレーム、制御フレーム及び管理フレームの3種類のMACフレームを扱い、MAC層において規定される各種処理を行う。ここで、3種類のMACフレームについて説明する。
管理フレームは、他の端末との間の通信リンクの管理のために用いられる。管理フレームとしては、例えば、IEEE802.11規格におけるBasic Service Set(BSS)である無線通信グループを形成するために、グループの属性及び同期情報を報知するビーコン(Beacon)フレームがある。また、認証のためにまたは通信リンク確立のために交換されるフレームなどもある。なお、ある端末が、もう一台の端末と互いに無線通信を実施するために必要な情報交換を済ませた状態を、通信リンクが確立していると、ここでは表現する。必要な情報交換として、例えば、自端末が対応する機能(例えばUL−MU方式への対応や後述する各種能力など)の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部30が、MAC/PHY管理部60からMAC共通処理部20を介して受けた指示に基づいて生成する。
管理フレームに関連して、送信処理部30は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。非基地局としての端末の通知手段は、UL−MU対応端末、IEEE802.11n対応端末、IEEE802.11ac対応端末のいずれに対応しているかの情報を、管理フレームに入れて送信することで、基地局に自端末の種別を通知してもよい。この管理フレームとしては、例えば端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるAssociation Requestフレームや、あるいはリアエソシエーションプロセスで用いられるReassociation Requestフレームがある。基地局の通知手段は、非基地局の端末に、UL−MU通信への対応可否の情報を、管理フレームを介して通知してもよい。これに用いる管理フレームとしては、例えばBeaconフレームや、非基地局端末が送信したProbe Requestフレームに対する応答であるProbe Responseフレームがある。基地局は、自装置に接続している端末群をグループ化する機能を有していてもよい。基地局の上記の通知手段は、各端末にそれぞれ割り当てられたグループのグループIDを、管理フレームを介して通知してもよい。この管理フレームとしては、例えばGroup ID Managementフレームがある。グループIDは、例えばIEEE Std 802.11ac−2013で規定されたグループIDでもよい。また、基地局は、当該グループ単位でUL−MU通信をする場合に、当該グループに属する端末が使用するリソースブロックを特定するために必要な情報を、任意の管理フレームを介して通知してもよい。
受信処理部40は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、基地局の受信手段は、非基地局としての端末からUL−MU通信への対応可否の情報を受信してもよい。また、当該端末がレガシー端末(IEEE802.11a/b/g/n/ac規格対応端末など)の場合に対応可能なチャネル幅(利用可能な最大のチャネル幅)の情報を受信してもよい。端末の受信手段は、基地局からUL−MU通信への対応可否の情報を受信してもよい。
上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末(基地局を含む)間で送受信することが可能である。例えばUL−MU対応端末は、自身がUL−MU送信で使用することを希望するリソースブロック、または、チャネル、またはこれらの両方を、キャリアセンスで非干渉のチャネル、または、非干渉のリソースブロック、またはこれらの両方から、選択してもよい。そして、選択したリソースブロックまたはチャネルまたはこれらの両方に関する情報を、基地局に通知してもよい。この場合、基地局は当該情報に基づき、UL−MU通信のためのリソースブロック割り当てを各UL−MU対応端末に対して行ってもよい。なお、UL−MU通信で利用するチャネルは、無線通信システムとして利用可能な全てのチャネルであっても、一部(1つまたは複数)のチャネルであってもよい。
データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、当該データがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部90からMAC共通処理部20を介して送信処理部30に渡され、送信処理部30でデータをフレームボディフィールドに入れ、MACヘッダを付加してデータフレームが生成される。そして、PHY処理部50でデータフレームに物理ヘッダを付加して物理パケットが生成され、物理パケットがアナログ処理部70及びアンテナ80を介して送信される。また、PHY処理部50で物理パケットを受信すると、物理ヘッダに基づき物理層の処理を行ってMACフレーム(ここではデータフレーム)を抽出し、データフレームを受信処理部40に渡す。受信処理部40は、データフレームを受けると(受信したMACフレームがデータフレームであると把握すると)、そのフレームボディフィールドの情報をデータとして抽出し、抽出したデータを、MAC共通処理部20を介して上位処理部90に渡す。この結果、データの書き込み、再生などのアプリケーション上の動作が生じる。
制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信(交換)するときの制御のために用いられる。制御フレームとしては、例えば、管理フレーム及びデータフレームの交換を開始する前に、無線媒体を予約するために他の無線通信装置との間で交換するRTS(Request to Send)フレーム、CTS(Clear to Send)フレームなどがある。また、他の制御フレームとして、受信した管理フレーム及びデータフレームの送達確認のための送達確認応答フレームがある。送達確認応答フレームの例として、ACK(Acknowledgement)フレーム、BA(BlockACK)フレームなどがある。CTSフレームも、RTSフレームの応答として送信するため、送達確認応答を表すフレームであるとも言える。CF−Endフレームも、制御フレームの1つである。CF−Endフレームは、CFP(Contention Free Period)の終了をアナウンスするフレーム、つまり、無線媒体へのアクセスを許可するフレームである。これらの制御フレームは送信処理部30で生成される。受信したMACフレームへの応答として送信される制御フレーム(CTSフレームやACKフレーム、BAフレームなど)に関しては、受信処理部40で応答フレーム(制御フレーム)の送信の必要を判断して、フレーム生成に必要な情報(制御フレームの種別、RAフィールド等に設定する情報など)を送信指示とともに送信処理部30に出す。送信処理部30が、当該フレーム生成に必要な情報と送信指示に基づき、適切な制御フレームを生成する。
MAC処理部10は、CSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)に基づき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/IDフィールド(以下、Durationフィールド)に当該フレームの送信に要する時間以上の期間を設定したものを送信した場合には、当該フレームを送信した段階からDurationフィールドに記載された期間のTXOPを獲得したと解釈してもよい。
受信処理部40は、上述したキャリアセンス情報を管理する。キャリアセンス情報は、例えばチャネルごとに管理する。このキャリアセンス情報は、PHY処理部50から入力される媒体(CCA)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、IEEE802.11規格において、媒体予約時間は、MACヘッダの中のDurationフィールドに記載される。MAC処理部10は、他の無線通信装置宛ての(自己宛てでない)MACフレームを受信した場合に、当該MACフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、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のいずれも、複数のMPDUの連接、および複数のMSDUの連接を、受信側端末で適切に分離できるように、データフレームに区切り情報(長さ情報など)が格納されている。A−MPDUおよびA−MSDUの両方を組み合わせて用いてもよい。またA−MPDUは、複数のMACフレームではなく、1つのMACフレームのみを対象としてもよく、この場合も区切り情報をデータフレームに格納する。また、データフレームがA−MPDUなどの場合は、複数のMACフレームに対する応答をまとめて送信する。この場合の応答には、ACKフレームではなく、BA(BlockACK)フレームが用いられる。以降の説明および図では、MPDUの表記を用いることがあるが、これは単一のMACフレームのみならず、上述したA−MPDUまたはA−MSDUの場合も含むものとする。
IEEE802.11規格では、基地局が中心となり構成するBSS(これをインフラストラクチャ(Infrastructure)BSSと呼ぶ)に、非基地局の端末が加入し、BSS内でデータフレームの交換ができるようになるために経る手順(procedure)が、段階的に複数規定されている。例えば、アソシエーション(association)という手順があり、非基地局の端末から、当該端末が接続を要求する基地局に対して、アソシエーション要求(Association Request)フレームを送信する。基地局は、アソシエーション要求フレームに対するACKフレームを送信後、アソシエーション要求フレームに対する応答であるアソシエーション応答(Association Response)フレームを送信する。
端末はアソシエーション要求フレームに自端末の能力(capability)を格納し、それを送信することで基地局に自端末の能力の通知をすることができる。例えば、端末はアソシエーション要求フレームの中に、自端末が対応可能なチャネルまたはリソース(リソースブロックまたはストリーム)またはこれらの両方や、自端末が対応する規格を特定するための情報を入れて送信してもよい。他の基地局へ再接続するための再アソシエーション(reassociation)という手順で送信するフレームにも、この情報を入れるようにしてもよい。この手順では、端末から、再接続を要求する他の基地局に対して、再アソシエーション要求(Reassociation Request)フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するACKフレームを送信後、再アソシエーション要求フレームに対する応答である再アソシエーション応答(Reassociation Response)フレームを送信する。
管理フレームとして、アソシエーション要求フレームおよび再アソシエーション要求フレーム以外にも、ビーコンフレーム、プローブ応答(Probe Response)フレームなどを用いてもよい。ビーコンフレームは基本的に基地局が送信するもので、BSSの属性を示すパラメータとともに、基地局自身の能力を通知するパラメータも格納できる。そこで、この基地局自身の能力を通知するパラメータとして、基地局がUL−MU通信への対応可否の情報を加えるようにしてもよい。また他のパラメータとして、基地局のサポートレート(Supported Rate)の情報を通知してもよい。サポートレートは、必須のレートとオプションのレートとを含んでもよい。プローブ応答フレームは、ビーコンフレームを送信する端末からプローブ要求(Probe Request)フレームを受信すると、それに応答して送信するフレームである。プローブ応答フレームは、基本的にはビーコンフレームと同一の内容を通知するものであるため、プローブ応答フレームを用いても基地局は、プローブ要求フレームを送信した端末に、自局の能力(UL−MU通信への対応可否、サポートレートなど)を通知することができる。UL−MU対応端末にこの通知を行うことで、端末は例えば自端末のUL−MU通信の機能を有効にするといったことも可能となる。
なお、端末は自端末の能力について基地局へ通知する情報として、基地局のサポートレートのうち自端末が実行可能なレートの情報を通知してもよい。ただし、サポートレートのうち必須のレートについては、基地局へ接続する端末はその必須のレートを実行する能力を有するものとする。
なお、上記で扱った情報のうち、他の情報を通知することで、その情報が必須となるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとUL−MU対応端末である、というのであれば、IFDMA対応端末であることの通知を明示的に行わなくてもよい。
図4に、本実施形態に従った無線通信システムを示す。このシステムは、基地局(AP:Access Point)100と、複数の端末(STA:STAtion)1〜8とを備える。基地局100と、配下の端末1〜8により、BSS(Basic Service Set)1が形成される。このシステムは、CSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)を用いるIEEE802.11規格に準じた無線LANシステムである。なお、BSS1内に本実施形態に係る端末(UL−MU端末)以外のレガシー端末(IEEE802.11a/b/g/n/ac規格対応端末など)が存在していてもかまわない。
図5(A)は、MACフレームの基本的なフォーマット例を示す。本実施形態に係るデータフレーム、管理フレームおよび制御フレームは、基本的にこのようなフレームフォーマットを備える。本フレームフォーマットは、MACヘッダ(MAC header)、フレームボディ(Frame body)及びFCSの各フィールドを含む。MACヘッダは、図5(B)に示すように、Frame Control、Duration/ID(単にDurationと呼ぶこともある)、Address1、Address2、Address3, Sequence Control、QoS Control及び HT(High Throughput) controlの各フィールドを含む。
これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しない場合もあり得る。また図5には示されていない他のフィールドが存在してもよい。例えば、Address4フィールドがさらに存在してもよい。また後述するように、通知フィールド(あるいは制御フィールドと呼んでもよい)が、MACヘッダ内にフィールドまたはサブフィールドとして存在してもよい。
Address1のフィールドには受信先アドレス(Receiver Address;RA)が、Address2のフィールドには送信元アドレス(Transmitter Address;TA)が入り、Address 3のフィールドにはフレームの用途に応じてBSSの識別子であるBSSID(Basic Service Set IDentifier)(全てのビットに1を入れて全てのBSSIDを対象とするwildcard BSSID場合もある)か、あるいはTAが入る。
Frame Controlフィールドには、前述したようにタイプ(Type)、サブタイプ(Subtype)という2つのフィールドが設定される。データフレームか、管理フレームか、制御フレームかの大別はTypeフィールドで行われ、大別されたフレームの中での細かい種別、例えば管理フレームの中のBAフレーム、BARフレーム、Beaconフレームといった識別はSubtypeフィールドで行われる。
Duration/IDフィールドは前述したように媒体予約時間を記載し、他の端末宛てのMACフレームを受信した場合に、当該MACフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、前述したように、NAV(Network Allocation Vector)と呼ばれる。QoSフィールドは、フレームの優先度を考慮して送信を行うQoS制御を行うために用いられる。HT Controlフィールドは、IEEE802.11nで導入されたフィールドであり、QoSデータフレームまたは管理フレームのときに、オーダーフィールドが1に設定されていると存在する。HT Controlフィールドは、IEEE802.11acのVHT (Very High Throughput)Controlフィールドにも、次世代無線LAN規格であるIEEE802.11axのHE(High Efficiency) Controlフィールドにも拡張可能であり、各々IEEE802.11n、IEEE802.11ac、あるいはIEEE802.11axの各種機能に応じた通知をすることができる。
管理フレームでは、固有のElement ID(IDentifier)が割り当てられた情報エレメント(Information element;IE)をFrame Bodyフィールドに設定する。フレームボディフィールドには、1つまたは複数の情報エレメントを設定できる。情報エレメントは、図6に示すように、Element IDフィールド、Lengthフィールド、情報(Information)フィールドの各フィールドを有する。情報エレメントは、Element IDで識別される。情報フィールドは、通知する情報の内容を格納し、Lengthフィールドは、情報フィールドの長さ情報を格納する。後述する通知フィールド(制御フィールド)を管理フレームのボディフィールドに設定してもよい。この場合、通知フィールドは、情報エレメントの形式を有してもよい。
FCSフィールドには、受信側でフレームの誤り検出のため用いられるチェックサム符号としてFCS(Frame Check Sequence)情報が設定される。FCS情報の例としては、CRC(Cyclic Redundancy Code)などがある。
図7に、本実施形態に係る基地局(AP)101と、端末(STA)1〜端末(STA)4を含む複数の端末との動作シーケンス例を示す。端末1〜4を含む複数の端末はUL-MU対応端末である。図には端末1〜4以外の端末は示されていないが、実際には、図4に示したように他の端末5〜8が存在してよい。
図において、双方向矢印付きの実線で示される短い区間は、short interframe space(SIFS)を表す。ただし、参照符号T1が付されている区間は、SIFSまたは他の一定時間(IFS)を表す。太線の矢印で示される区間501A、503A、505Aは、DIFS/AIFS[AC]時間と、CSMA/CAのバックオフ(BackOff)時間との合計(キャリアセンス時間あるいは待機時間)を表している。ただし、SIFSおよびDIFS/AIFS[AC]時間は一例であり、予め定めた一定時間であれば、別の時間(IFS)でもよい。DIFS/AIFS[AC]時間は、DIFSおよびAIFS[AC]のいずれか一方の時間を意味する。QoS対応でない場合はDIFS時間を指し、QoS対応の場合は、送信するデータのアクセスカテゴリ(AC:Access Category)(後述)に応じて決まるAIFS[AC]時間を指す。
本動作シーケンス例では、基地局および端末1〜4を含む個々の端末との間で、基本のチャネル幅(または複数のチャネルを結合した帯域幅)で個別に通信が行われている状況の中、基地局がUL-MU(UL-OFDMAまたはUL-MIMO)送信の開始を決定する。基地局が、UL−MU送信の開始を決定すると、UL-MU送信のトリガーとなるトリガーフレーム(より詳細にはトリガーフレームを含む物理パケット)507を送信し、端末1〜4がトリガーフレームの受信から一定時間T1後にデータフレーム(より詳細にはデータフレームを含む物理パケット)509、510、511、512を送信する。これにより、端末1〜4から基地局へのUL-MU送信が行われる。なお、UL−MU通信に対し、個々の端末と基地局との間で基本のチャネル幅(または複数のチャネルを結合した帯域幅)で個別に行う通信を、シングルユーザ通信と呼ぶことがある。以下、本シーケンスについてさらに詳細に説明する。
UL-MU送信が開始される前では、基地局101と端末1〜4を含む個々の端末との間では通常のシングルユーザ通信が行われている。つまり、端末1において、アップリンク送信用のデータが保持されている場合、端末1が、無線媒体へのアクセス権を獲得するため、DIFS/AIFS[AC]とランダムに決定したバックオフ時間とのキャリアセンス時間(待機時間)の間、キャリアセンスを行ってCCA値を測定し、媒体(CCA)がアイドルと判断されると、例えば1フレームを送信するアクセス権を獲得する。端末1は、送信するデータを含むデータフレーム(より詳細にはデータフレームを含む物理パケット)501を送信し、基地局がこのデータフレーム501を正常に受信すると、データフレーム501の受信完了からSIFS時間後に、送達確認応答フレームであるACKフレーム(より詳細にはACKフレームを含む物理パケット)502を返す。端末1はACKフレーム502を受信することで、データフレーム501の送信が成功したと判断する。なお、基地局に送信するデータフレームはアグリゲーションフレーム(A-MPDU等)でもよく、基地局が応答する送達確認応答フレームはBAフレームでもよい(以下同様)。端末2も同様にしてアクセス権を獲得してデータフレーム503を送信し、基地局がデータフレーム503の受信完了からSIFS時間後に、ACKフレーム504を送信する。また、端末3も、同様にしてアクセス権を獲得してデータフレーム505を送信し、また基地局がデータフレーム505の受信完了からSIFS時間後に、ACKフレーム506を送信する。図の例では、端末1〜3のみが基地局にデータフレームを送信する例が示されるが、端末4および図示しない端末5〜8も同様にして、フレーム交換を行ってよい。また図の例では、端末1、端末2、端末3の順に通信が行われているが、これはアクセス権を獲得した順に過ぎず、どのような順序で通信が行われてもかまわない。
ここで各端末は、基地局に送信するデータフレーム501、503、505等において、基地局がUL−MUに必要な情報である通知情報(あるいは制御情報と呼んでもよい)を、通知フィールド(制御フィールド)に設定する。つまり、データフレームは、基地局に上記データを送信する役割の他、UL−MUに必要な通知情報を送信する役割を有する。さらに換言すれば、データフレームは、当該通知情報とは異なる目的の情報(上記データ)を、フレームボディフィールドに含んでいる。なお、通知情報はシングルユーザ送信されるデータフレームに設定する他、UL−MU送信するデータフレームに設定することも可能である。
通知情報の一例として、UL−MU送信の要求の有無に関する情報、UL−MU送信を希望するデータの有無に関する情報、UL−MU送信を希望するデータのデータ種別に関する情報等がある。また、UL−MU送信を希望するデータのデータ量に関する情報(データの個数またはサイズまたはこれらの両方など)がある。また、希望する通信方式(OFDMAかMU−MIMOのいずれかの通信方式)がある。また、通信方式に応じて、希望するリソース(OFDMAではリソースブロック、MU−MIMOではストリーム)またはリソース数でもよい。希望するリソースは、リソース番号またはストリーム番号で特定してもよいし、その他の方法で特定してもよい。また、端末におけるデータの発生周期の情報でもよい。また、アプリケーションで許容される通信遅延(許容遅延)の値などもあり得る。通知情報は、ここで述べた例の情報の少なくとも1つを含んでもよいし、ここで述べていない種類の情報を含んでもよい。通知情報は、基地局から通知情報の送信要求が行われない状態で、個々の端末から自発的に送信される。つまり、個々の端末が通常のシングルユーザ通信で送信するフレームに相乗りする形で、通知情報を送信する。また、前述したように、複数の端末からUL―MU送信される複数のフレーム(データフレーム等)に個々の端末で通知情報を設定して、当該フレームに相乗りする形で送信することも可能である。この場合、UL−MU送信しながら、次のUL−MU送信に必要な事項を決定するための通知情報を送信することができる。通知情報の内容の詳細については後述する。
ここで通知情報を設定する通知フィールドは、図8(A)に示すように、MACヘッダ内に新規フィールドとして設けてもよい。または、既存のフィールド(既存の規格で定義されたフィールド)内の予約領域を通知フィールドとして利用してもよい。また、通知フィールドは、図8(B)に示すように、物理ヘッダ内に設けてもよいし、物理ヘッダ内の既存のフィールド内の予約領域を通知フィールドとして利用してもよい。または、通知フィールドを、MACヘッダではなく、フレームのボディフィールドに設定してもよい。例えば基地局に送信するデータフレームがA−MPDUの場合に、データフレームのペイロードに格納する複数のMACフレームのうちの1つを管理フレームとし、その管理フレームのフレームボディフィールドを通知フィールドとしてもよい。このとき、通知フィールドは、具体的には、先に図6に示したような情報エレメントの形式を有してもよく、通知フィールドを設定する情報エレメントに、新規にエレメントIDを割り当ててもよい。また、Frame Controlフィールドのサブタイプとして、通知フィールドを含むフレームに対して新規の値を定義してもよい。既存の管理フレームのフレームボディに、通知フィールドの情報エレメントを追加的に設定してもよい。通知フィールドの具体的なフォーマットは、設定する通知情報の内容に依存する。
ここで、各端末が通知フィールドで通知する通知情報について説明する。上述したように、通知情報は、基地局がUL−MUの必要事項の決定等を含むスケジューリングを行うために用いられる。
通知情報の第1の例として、UL−MU送信の要求有無に関する情報がある。基地局に送信する残りのデータが送信バッファ(送信キュー)に存在する場合などは、UL−MU送信の要求があるといえる。通知情報のフォーマット例として、1ビットを用い、ビット1のとき、UL−MU送信の要求がある、ビット0のとき、UL−MU送信の要求がないとしてもよい。あるいは、ビット関係をこの逆にしてもよい。基地局では、UL−MU送信の対象端末を選定する際、UL−MU送信の要求を有する端末の中から選定してもよい。なお、変形例として、パワーセーブモードにある端末にダウンリンク用の残りのデータの存在の有無を通知するために用いるmore dataフィールドを、第1の例の通知情報として流用してもよい。例えば、more dataフィールドのビットを1にすることで、送信用のデータの有を通知してもよい。また、UL−MU送信の要求が存在しないときは、そもそも通知フィールドを設けないという方法も可能である。
なお、端末が、基地局に送信するデータを有しているが、UL−MU送信で送信せずに、シングルユーザ送信で送信したい状況もあり得る。UL−MU送信では複数の端末でリソース(例えば1チャネル幅帯域)を共有するため、1端末で1チャネル帯域幅を利用できるシングルユーザ送信に比べて、同じデータサイズを送る場合のフレーム長(物理パケット長)が長くなる。フレーム長が長くなると、その分、送信に失敗する可能性(受信側でフレームエラーが検出される可能性等)が高くなる。このため、端末は、確実に送信したい場合はシングルユーザ送信を行い、UL−MU送信を行いたくない状況もあり得る。このような場合は、端末は、送信の要求はない(残りのデータはない)ことを示す情報を通知フィールドに設定し、当該データは、通常通り、CSMA/CAベースで、シングルユーザ送信すればよい。
通知情報の第2の例として、端末におけるデータ種別毎のUL−MU送信の要求の有無(すなわち、データ種別毎のUL−MU送信用のデータの有無)を特定するための情報でもよい。データ種別として、IEEE802.11規格のTID(Traffic ID:トラヒック種別)またはAC(Access Category:アクセスカテゴリ)でもよい。以下ではデータ種別としてACをベースに説明するが、TIDを代わりに用いてもかまわない(通知情報の第3の例以降の説明の場合も同様)。
アクセスカテゴリ(AC)を利用した優先制御方式としてEDCA(Enhanced Distributed Channel Access)がある。EDCAについて簡単に説明する。IEEE802.11規格の無線LANでは、上位層(LLC層等)からMAC層にデータが渡される際に、端末がQoS(Quality of Service)に対応する場合には、データとともにトラヒック種別(TID)が通知される。なお既存の規格ではIEEE802.11nやIEEE802.11acの対応端末は、QoSに対応する。
当該データは、例えばトラヒック種別に基づいて、4つのACに分類される。一例として、TIDの値は、0〜15まで存在し、0〜7はEDCA環境にある端末(基地局を含む)で使用され、8〜15はHCCA(hybrid coordination function (HCF) controlled channel access (HCCA))環境あるいはHEMM(HCCA、EDCA mixed mode)環境にある端末(基地局を含む)で使用される。ここではEDCA環境を想定し、TIDの値が0〜7のいずれであるかに応じて、4つのACのいずれか1つに分類される。
ACの種類として、BACKGROUND(AC_BK)、BEST EFFORT(AC_BE)、VIDEO(AC_VI)、VOICE(AC_VO)が定められている。4つのACに対して送信バッファ(送信キュー)がそれぞれ設けられ、分類されたデータは、該当する送信バッファに格納される。送信バッファ(送信キュー)は、メモリでもよいし、SSD、ハードディスク等でもよい。送信バッファがメモリの場合、当該メモリはDRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。
各ACには、EDCAパラメータが定められており、このパラメータで送信時の媒体アクセスの優先度の差が決定される。パラメータの例としては、AIFS[AC]、およびコンテンションウィンドウ(Contention Window:CW)の最小値CWminおよび最大値CWmaxなどがある。AIFS[AC]、CWminおよびCWmaxは、媒体アクセスの優先度の高いACほど、小さい値に設定される。パラメータのその他の例としては、TXOPの上限値であるTXOP limitもある。
端末では、CSMA/CAに基づくデータ送信のための手順が、送信用のデータを有するACごとに独立して行われる。すなわち、ACごとに、AIFS[AC]と、バックオフ時間とを含む待機時間の間、キャリアセンスを行い、最初に待機時間がゼロになったACがアクセス権を獲得する。待機時間が同時にゼロになったACが複数存在する場合は、媒体アクセスの優先度の高いACがアクセス権を獲得する。なお、バックオフ時間(ランダム時間)は、コンテンションウィンドウ(Contention Window:CW)からランダムに選ばれる整数にスロット時間をかけたものである。CWの初期値はCWminで与えられ、再送するたびにCWの値はCWmaxになるまで増やされる。
図9に、AC別にUL−MU送信の要求の有無(UL−MU送信用のデータの有無)を表すフォーマットの例を示す。BACKGROUND(AC_BK)、BEST EFFORT(AC_BE)、VIDEO(AC_VI)およびVOICE(AC_VO)のそれぞれに対して1ビットが設けられている。これらのACのそれぞれに該当する送信キューにデータが存在するときはビット1、存在しないときは0とすることができる。あるいは、ビットの関係をこの逆としてもよい。この例では、各ACの送信用のデータの有無を表すために、4つのビットが必要になる。
図10に、図9のフォーマットを用いて各ACの送信用のデータ有無を通知する具体的な動作例を示す。ACごとに送信キューが設けられ、AC_VOの送信キューには、1つのMSDU(MPDU、PSDU、またはPPDUなどでもよい)が存在する。AC_VIの送信キューには2つのMSDUが存在し、AC_BKの送信キューにはMSDUが存在せず、AC_BEの送信キューには1つのMSDUが存在する。各MSDUのサイズは同じである必要はなく、図の例でもAC間でMSDUのサイズが異なっている。送信時にACごとに独立してCSMA/CAに従った手順が同時に開始され、AC_VOが最初に待機時間がゼロになり、アクセス権を獲得したとする。この場合、AC_VOの送信キューの先頭のMSDUが読み出され、当該送信キューは空になる。読み出されたMSDUに基づきMACフレームのボディフィールドが生成され、またボディフィールドにMACヘッダが付加されることで、MACフレームが生成される。この際、MACヘッダの通知フィールドには、AC別に送信用の残りのデータ有無を表す情報が設定される。AC_VOの送信キューは空のためビット0、AC_VIの送信キューにはMSDUが存在する(2つ)ためビット1、AC_BKの送信キューは空のためビット0、AC_BEにはMSDUが存在する(1つ)のためビット1がそれぞれ該当するサブフィールドに設定される。生成されたMACフレームは、獲得したアクセス権に基づくTXOP内で、基地局に送信される。なお図の例では、MACフレームの送信からSIFS時間後に基地局から送達確認応答フレーム(BAフレームまたはACKフレーム等)が端末1で受信されている。
なお、既存のIEEE802.11規格では、基地局が送信するMACフレーム(ビーコンフレーム等)のMACヘッダのFrame Controlフィールド内のmore dataフィールドにビット1を設定した場合、同じアクセスカテゴリ(AC)のデータが基地局にまだ存在すると解釈されるが、これでは、他のACの送信キューの状態を端末に伝えられない問題がある。これに対して、第2の例の通知情報では複数のACの送信キューの状態を伝えることができるため、基地局はUL−MU通信を効率的に行うことができる。
通知情報の第3の例として、ACごとに、送信の優先度(前述した媒体アクセスの優先度とは区別される)を設定してもよい。例えば「高」、「中」および「下」の優先度を、ACごとに設定してもよい。3つより少ないまたは多い個数の優先度を定義してもよい。なお、送信用のデータが存在しない場合は、送信の優先度を「下」にしてもよいし、送信用のデータが存在しないことを示す「無」などの優先度を別途、定義してもよい。本第3の例を、第2の例と組み合わせて通知情報を定義してもよい。この場合、AC別に、送信用のデータの有無と、送信の優先度とが設定される。
通知情報の第4の例として、複数のAC(AC_VO、AC_VI、AC_BKおよびAC_BE)のうち、最もデータ送信したいAC、すなわち最も送信の優先度の高いACを指定してもよい。この場合、これら4つのACのうちの1つを指定するために、2ビットが必要になる。例えば、AC−VOの場合「00」、AC−VIの場合「01」、AC−BKの場合「11」、 AC−BEの場合「10」のように指定してもよい。本第4の例を、第2の例と組み合わせて通知情報を定義してもよい。この場合、ACごとに、データ送信の有無を表すビット(例えば4ビット)と、本例の1つのACを指定するビット(例えば2ビット)とが必要になる。
通知情報の第5の例として、全部または一部のAC別の送信用のデータ量を特定するための情報でもよい。データ量は、AC別の送信キューに存在しているデータ(ここではMSDUとするが、PPDUでもよいし、その他のPDUまたはSDUでもよい)の個数または各MSDUのサイズ、またはこれらの両方でもよい。または、送信キューに残っているMSDUの合計データサイズでもよい。また、サイズではなく、時間長でもよい。ここで述べた以外にも、データ量を特定可能な情報であるならば、何でもよい。例えば送信をアグリゲーションフレーム(A−MPDUまたはA−MSDUなど)の送信で行う場合に、何個分のアグリゲーションフレームが存在するかの情報でもよい。データ量を表現する際の量子化方法は任意の方法でよい。例えば、基本の単位を時間長である32μsとし、32μsの整数倍でデータ量を表してもよい。このときデータ量を設定するためのフィールド長が8ビットであれば、例えば32μs〜8160μsを表すことができる。なお、32μsは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また8ビットも一例であり、他の長さのフィールド長を用いてもよい。また、他の量子化方法として、基本の単位をサイズである4096オクテットとし、4096オクテットの整数倍で、データ量を表してもよい。例えばデータ量を設定するためのフィールド長が4ビットで、フィールドの値が1のとき4096オクテットを表し、2のとき8192オクテットを表すなどとできる。実際のデータ量が、4096オクテットの整数倍に一致しない場合は、当該実際のデータ量より大きい値で、最も近い値を採用すればよい。フィールドの値が15の場合は、データ量が57344オクテットより大きいことを示してもよい。なお、4096オクテットは一例であり、他のサイズを基本の単位として用いてもよい。また4ビットも一例であり、他の長さのフィールド長を用いてもよい。
通知情報の第6の例として、端末における送信用のデータ量(AC別でない)を特定するための情報でもよい。具体的に、送信バッファ(送信キュー)に残っている送信用のデータ(ここではMSDUとするが、PPDUでもよいし、その他のPDUまたはSDUでもよい)の個数または各MSDUのサイズ、またはこれらの両方でもよい。または、送信用に残っているMSDUの合計サイズでもよいし、ここで述べた以外の情報でもよい。また、サイズではなく、時間長でもよい。ここで述べた以外にも、データ量を特定可能な情報であるならば、何でもよい。例えば送信をアグリゲーションフレーム(A−MPDUまたはA−MSDUなど)の送信で行う場合に、何個分のアグリゲーションフレームが存在するかの情報でもよい。データ量を表現する際の量子化方法は任意の方法でよい。例えば、基本の単位を時間長である32μsとし、32μsの整数倍でデータ量を表してもよい。このときデータ量を設定するためのフィールド長が8ビットであれば、例えば32μs〜8160μsを表すことができる。なお、32μsは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また8ビットも一例であり、他の長さのフィールド長を用いてもよい。また、他の量子化方法として、基本の単位をサイズである4096オクテットとし、4096オクテットの整数倍で、データ量を表してもよい。例えばデータ量を設定するためのフィールド長が4ビットで、フィールドの値が1のとき4096オクテットを表し、2のとき8192オクテットを表すなどとできる。実際のデータ量が、4096オクテットの整数倍に一致しない場合は、当該実際のデータ量より大きい値で、最も近い値を採用すればよい。フィールドの値が15の場合は、データ量が57344オクテットより大きいことを示してもよい。なお、4096オクテットは一例であり、他のサイズを基本の単位として用いてもよい。また4ビットも一例であり、他の長さのフィールド長を用いてもよい。
通知情報の第7の例として、全部または一部のAC別に、次の送信に必要なTXOP長を特定するための情報でもよい。TXOP長は、例えば、基本の単位を32μsとし、32μsの整数倍で表してもよい。このときTXOP長を設定するためのフィールド長が8ビットであれば、例えば32μs〜8160μsを表すことができる。なお、32μsは一例であり、他の大きさの時間長を基本の単位として用いてもよい。また8ビットも一例であり、他の長さのフィールド長を用いてもよい。TXOP長ではなく、全部または一部のAC別に、次の送信に必要なデータ量でもよい。データ量は、PPDUまたはMSDU等のデータ長でもよい。データ量の表現方法は、第5または第6の例の通知情報と同様である。ここではAC別に、次の送信に必要なTXOP長またはデータ量を特定するための情報を示したが、AC別ではなく、端末における次の送信に必要なTXOP長またはデータ量を特定するための情報でもよい。
通知情報の第8の例として、端末がOFDMAとMU−MIMOのいずれ(前述したようにMU−MIMO&OFDMAでもよい。以下同様)を希望するかに関する情報でもよい。端末がいずれか一方のみの通信方式に対応可能であり、アソシエーションプロセス時等に基地局に、自端末が対応可能な通信方式を通知済みの場合は、本情報の通知を省略してもよい。
通知情報の第9の例として、UL−MU通信方式(OFDMAまたはMU−MIMO)に応じて、希望するリソース(OFDMAではリソースブロック、MU−MIMOではストリーム)を特定する情報、またはリソース数を表す情報、またはこれらの両方でもよい。希望するリソースの特定は、リソース番号またはストリーム番号で行ってもよいし、別の方法で行ってもよい。別の方法の例として、リソース番号の範囲を指定することで、希望するリソースを特定してもよい。例えばリソース番号1〜8まであるときに、「リソース番号6〜8」のように範囲を指定してもよい。この際、複数の範囲を指定してもよい。
上述した第1〜第9の例で示した各種の通知情報はそれぞれ単独で用いられる他、矛盾しない限り、任意の組み合わせで用いてもよい。例えば第1の例と第2の例との両方を組み合わせて通知情報を定義してもよい。また3つ以上の通知情報を組み合わせてもよい。第1〜第9の例は一例であり、これら以外の情報を通知情報として用いることも可能である。例えば端末におけるデータの発生周期を表す情報を用いてもよい。当該発生周期は、前述したAC別またはTID別の情報でもよい。また、端末におけるアプリケーションで許容される通信遅延(許容遅延)の値を表す情報でもよい。また、IEEE802.11規格で定められたTSPEC(Traffic Specification)関連の情報(例えば平均データレート、MSDU長、最小物理レート等)を、通知情報として送信してもよい。複数の通知情報を送信する場合、1つのフレームで送信してもよいし、複数のフレームに分けて送信してもよい。
ここで通知情報の一部または全部を、QoS Controlフィールドなど、既存のフィールドを利用して設定してもよい。このとき、既存のフィールド内の予約領域を用いてもよいし、既存のフィールドが複数のパターンのフォーマットを有するときは、通知情報を設定するためのパターンを新たに定義し、新たなパターンのフォーマットで通知情報を設定してもよい。また、既存のフィールドの値そのものを、通知情報として利用することも可能である。例えば、QoS Controlフィールドのフォーマットは、Frame Controlフィールドのサブタイプに応じて異なるが、一例としてTIDサブフィールドと、TXOP Duration Requestedサブフィールドを含む。TIDサブフィールドには、現在送信しているデータのTIDが設定され、TXOP Duration Requestedサブフィールドには、次のTXOPとして必要な値が設定される。これらのサブフィールドの値を通知情報としてもよい。
基地局は、各端末から通知フィールドで通知される通知情報を、内部の記憶装置に記憶し、端末毎の通知情報を管理することで、端末ごとの状態を管理する。なお、前述したように通知フィールドでの通知情報の通知は、既存のフィールドを利用している場合も含む。基地局は、任意のタイミング、予め定めたタイミング、または予め定めた条件が成立したタイミング等で、UL−MU送信の実施を決定する。予め定めたタイミングとして、一定のビーコンインターバル周期ごとでもよいし、その他のタイミングでもよい。予め定めた条件としては、UL−MU送信の希望を有する端末が一定数以上存在することでもよいし、電波の状況(ビジー率、利用率、あるいはその他の指標でもよい)が所定の基準を満たすことを要件してもよい。基地局は、端末1〜4からシングルユーザ送信されるデータフレームの受信とは独立して、UL−MU送信の実施を決定すればよい。
基地局は、UL−MU送信の実施を決定すると、UL−MU通信に必要な事項を決定する。例えばUL−MU送信の対象端末を選定する。選定の方法としては、UL−MU送信の要求を有する端末から選択してもよい。この際、特定のデータ種別(ACまたはTIDなど)の送信用データを有している端末の中から選択してもよい。また特定のデータ種別のデータ量または次の送信に必要なTXOP長またはデータ量が最も大きい端末から優先的に選択する、またはデータ量または次の送信に必要なTXOP長またはデータ量が同じくらいの端末を選択するなど、データ量または次の送信に必要なTXOP長またはデータ量に基づいて対象端末を選択してもよい(詳細は後述)。また特定のデータ種別の送信の優先度が最も高い端末など、特定のデータ種別の送信の優先度に基づいて端末を選択してもよい。また、基地局が端末をグループ化している場合に、同じグループに属する端末を選択してもよい。またグループを選択する基準として、各グループに属する端末ごとのUL−MU送信の要求の有無、特定のデータ種別のデータ量または優先度などの項目を考慮してもよい。または、ラウンドロビンで選択する方法でもよいし、ランダムで選択する方法でもよい。または、送信するデータのサイズが同じ、または近いと推定されるデータを有する端末を選択する方法、またはデータの発生周期が同じ、または発生周期が近い端末(発生周期が一定値以内に含まれる端末、または発生周期が最も近い所定数の端末など)を選択する方法でもよい。または、事前に各端末との伝搬路応答を把握している場合は、空間相関の小さい(干渉の小さい)端末の組み合わせを選択してもよい。選択する端末数は、通信方式に応じて、多重可能最大数以下の範囲内とする。OFDMAであれば、利用可能な最大のリソースブロック数、MU−MIMOであれば、利用可能な最大の空間リソース数(最大ストリーム数)以下の範囲で選択する。選択する端末数の下限が定められており、下限以上端末数を選択してもよい。
また、基地局は、選定した対象端末に対して、UL−MU送信で使用するリソースの割り当てを行う。リソースは、OFDMAであれば、リソースブロック(1つまたは複数のサブキャリア)であり、MU−MIMOであれば、空間リソース(ストリーム)である。リソースの割り当てでは、対象端末間で重複しないようにリソースを割り当てる。事前に端末ごとに使用可能なリソースが定まっている場合(例えば基地局とのアソシ−エーション時またはその後の任意のタイミングで決められた場合、あるいは、端末の能力に応じて、使用可能なリソースが定まっている場合など)には、事前に定められたリソースを割り当てるようにする。上述した対象端末を選定する際の処理では、端末ごとに使用可能なリソースを考慮し、端末間で使用可能なリソースが重複しないように、対象端末を選定してもよい。
上述した対象端末の選定およびリソースの割り当て以外にも、対象端末に指定する他のパラメータ情報の決定を行ってもよい。一例として、基地局は、対象端末が送信するPPDU長を共通に決定してもよい。例えば対象端末から次の送信に必要なTXOP長またはデータ量またはこれらの両方を含む通知情報を受信している場合に、対象端末から通知されたTXOP長またはデータ量(PPDU長等)を利用して、PPDU長を決定してもよい。例えば、対象端末の中でTXOPまたはデータ量が最も長いものに基づき、PPDU長を決定してもよい。詳細は、トリガーフレームの生成の説明で記述する。
なお、基地局は、対象端末の選定、リソースの割り当て、および他のパラメータ情報の決定にあたり、端末から既存のフィールドを介して通知情報が通知されている場合は、当該既存のフィールドに格納された情報を利用してスケジューリングを行っても良い。
基地局は、UL−MU通信の対象端末と、対象端末に割り当てるリソース等、UL−MU通信の実施内容が決定したら、トリガーフレーム507を生成する。
ここで、トリガーフレーム507は、図5に示した一般的なMACフレームのフォーマットをベースに定義すればよい。一例として、Frame Controlフィールドのタイプは制御フレームを表す値とし、サブタイプの値は、トリガーフレーム用に新規に定義した値とすればよい。ただし、トリガーフレームのフレームタイプは、制御フレームではなく、管理フレームまたはデータフレームとする構成も排除されない。また、サブタイプの値も既存の規格の値を流用してもよい。例えば既存の管理フレームのフレームボディフィールドにトリガーフレーム507の役割として必要な情報を、情報エレメントとして追加してもよい。
トリガーフレーム507のRA(受信先アドレス)は、一例として、ブロードキャストアドレスまたはマルチキャストアドレスとし、当該アドレスを、アドレス1フィールドに設定すればよい。またTA(送信元アドレス)は、基地局のMACアドレスまたはBSSIDとすればよい。
トリガーフレームのフレームボディフィールドには、UL−MU送信の対象端末数に応じた個数の端末情報フィールド(STA Info. Field)を、図11(A)に示すように設定する。図7のシーケンス例では、端末1〜4を選定したため、4つの端末情報フィールド(STA infoフィールド)1〜4を設定する。各端末情報フィールドには、当該端末に個別に通知する情報を設定する。端末情報フィールドに設定する情報の例を以下に示す。
一例として、端末情報フィールドには、選定した端末の識別子を設定する。端末の識別子は、端末のMACアドレスでもよいし、アソシエーションID(AID)、その他、端末間でユニークなIDでもよい。
また、端末情報フィールドには、UL−MU送信時に端末が個別に使用するパラメータ情報を設定してもよい。以下、パラメータ情報の例を示す。
パラメータ情報の例として、送信を許可するデータ長、誤り訂正符号方式、PHYまたはMACまたはこれらの両方の送信レートを規定するMCS(Modulation and Coding Scheme:変調符号化方式)、の少なくとも1つがある。データ長は、物理パケット長でもよいし、物理ヘッダ長が固定ならば、MACフレーム長またはMSDU長でもよいし、その他の部分の長さでもよい。データ長の単位は、データサイズでもよいし、時間長(空間での占有時間長)でもよい。データ長は各端末で共通でもよいし、端末ごとに異なることを許容してもよい。なおデータ長(PPDU長など)の最大値は、規格またはシステムで事前に決められていてもよく、この場合最大値以下の範囲で、データサイズを指定する。
基地局ではデータ長(例えばPPDU長)を決定する際、例えば、対象端末の中で最も大きいPPDU長を推定または算出し、その端末のPPDU長をアップリンク送信のデータ長として設定してもよい。また、基地局は、対象端末を選定する際、端末が要求するPPDU長に基づき、PPDU長が同じまたは互いに近い端末を選定してもよい。端末毎に送信するPPDU長が異なると、PPDU長の短い端末の送信完了後、PPDU長の長い端末の送信完了までの間、PPDU長の短い端末に割り当てられたリソースで無駄が生じ、システムの効率も低下する可能性がある。そこで、PPDU長が近い端末を選択することで、システム効率を高めることが可能となる。
また、基地局では、UL−MU通信を行う各対象端末のPPDU長が等しくまたは近くなるように、対象端末毎のMCSを決定し、当該MCSの情報を端末情報フィールドで指定してもよい。例えば同じデータサイズでも、適用するMCSが異なれば、占有時間長は異なる。そこで、各端末でデータサイズが異なる場合は、MCSを調整することで、各端末のPPDUの占有時間長が同じになるまたは近づくようにしてもよい。MCSはMACフレームに適用するMCSの他、物理ヘッダの一部または全部のフィールドについてMCSを指定可能な場合は、当該物理ヘッダのフィールドに対するMCSを指定してもよい。
またパラメータ情報の他の例として、各端末が送信すべきデータ種別の情報を指定してもよい。データ種別として、アクセスカテゴリ(AC)またはトラヒック情報(TID:Traffic ID)の情報を設定してもよい。指定するデータ種別は、端末ごとに異なってもよいし、各端末で共通でもよい。また1つの端末に、複数のデータ種別を指定してもよい。
またパラメータ情報の他の例として、UL−MUの通信方式に関する情報を指定してもよい。例えば、基地局が、OFDMAおよびMU−MIMOのいずれかを指定して端末にUL−MU送信させる可能な仕組みを採用する場合、OFDMAおよびMU−MIMOのいずれかを指定する情報を指定する。端末は、トリガーフレームで指定された通信方式でUL−MU送信を行う。この場合、基地局は、端末とのアソシエーションプロセス時またはその後の任意のタイミングで、端末が対応可能な通信方式を取得し、使用する通信方式に対応する端末の中から対象端末を選択してもよい。
また、パラメータ情報のさらに他の例として、使用するUL−MUの通信方式に応じて、端末に割り当てた1つまたは複数のリソースを指定する情報を、端末情報フィールドに設定してもよい。例えば、UL−OFDMAの場合、端末に割り当てた1つまたは複数のリソースブロックを指定する情報を、端末情報フィールドに設定してもよい。リソースブロックを指定する情報の形式は、当該リソースブロックを特定可能な限り、どのような形式でもよい。例えばリソースブロックの番号によって指定してもよい。高周波側または低周波側から何番目のリソースブロックかを指定してもよい。またUL−MU−MIMO送信の場合、端末に割り当てたストリームを指定する情報、一例として、フレームに付加するプリアンブル(伝搬路応答の推定のためのプリアンブル)のパターンの情報を指定してもよい。この際、各端末のプリアンブルは、端末間で互いに直交するように選択するものとする(詳細は後述する)。また、UL−MU−MIMO送信の場合は、端末に許可するストリーム数を指定してもよい。端末が対応可能なストリーム数は、事前に端末の能力情報として基地局で取得済みであるとする。
トリガーフレームのフレームボディフィールドに、端末情報フィールドとは別に、図11(B)に示すように、対象端末間で共通に情報(Common Information)を通知するための共通情報フィールドを設けてもよい。共通情報フィールドでは、対象端末に共通に通知する情報を設定する。例えば各端末に指定する送信データサイズが共通の場合、端末情報フィールドではなく、共通情報フィールドに設定してもよい。また使用するUL−MU通信方式を端末情報フィールドではなく、共通情報フィールドに設定してもよい。また、複数の対象端末としてグループを選択した場合は、当該グループのグループIDを共通情報フィールドに指定してもよい。このとき、当該グループに属するすべての端末が対象端末のときは、端末情報フィールドに個々の端末の識別子を設定することを省略してもよい。ただし、各端末は自端末が何番目の端末情報フィールドを割り当てられているかを、事前に基地局から通知されているなどして把握しているものとする。
ここでは端末情報フィールドおよび共通情報フィールドをフレームボディフィールドに設定する例を示したが、端末情報フィールドおよび共通情報フィールドに設定する情報の一部または全部を、MACヘッダ内に配置してもかまわない。また、端末情報フィールドおよび共通情報フィールドに設定する情報の一部または全部を、図12に示すように、物理ヘッダ内に配置してもよい。図12の物理ヘッダは、L−STF(Legacy−Short Training Field)、L−LTF(Legacy−Long TrainingField)、L−SIG(Legacy Signal Field)、共通情報フィールド、端末情報フィールドを含む。端末情報フィールドは端末数分のフィールドを含む。L−STF、L−LTF、L−SIGは、例えば、IEEE802.11aなどのレガシー規格が認識可能なフィールドであり、信号検出、周波数補正、伝送速度などの情報が格納される。必要な情報がすべて物理ヘッダ内の端末情報フィールドまたは共通情報フィールドまたはこれらの両方に設定される場合は、MACフレームから端末情報フィールドおよび共通情報フィールドを省略してもよい。
基地局からトリガーフレーム507を受信し、当該トリガーフレーム507で指定された端末1〜4は、トリガーフレーム507の受信完了から一定時間T1後に、アップリンク送信用のデータを含むデータフレーム509、510、511、512(より詳細には当該データフレームを含む物理パケット)を、基地局に送信する。データフレーム509〜512の送信は、トリガーフレーム507で指定されたリソース(リソースブロックまたは空間リソース(プリアンブルパターンに対応))を用いて行う。端末1〜4が送信するデータフレームの送信タイミングは互いに同期されるため、この結果、端末1〜4から送信されるデータフレーム509〜512は、周波数多重または空間多重で送信されることになる。端末1〜4は、基地局に送信すべきデータが存在しないときは、予め定めた形式のフレーム、例えばNull Packet(ヌルパケット)を送信してもよい。ヌルパケットは、ボディフィールドが存在しないフレームを指す。あるいは、端末1〜4は、基地局に送信すべきデータが存在しないときは、何も送信しないようにしてもよい。基地局では、ヌルパケットを受信した場合、または何も受信しなかった場合は、当該端末は送信すべきデータが存在しなかったと判断してもよい。
ここで、図7の一定時間T1は、一例として、IEEE802.11無線LANのMACプロトコル仕様で規定されているフレーム間のタイムインターバルであるSIFS(Short Inter−frame Space)時間(=16μs)でもよいし、これより長い時間でもよい。一定時間T1の値が共通情報フィールドに格納されており、端末1〜4は共通情報フィールドから一定時間T1の値を取得してもよい。その他、一定時間T1は、ビーコンフレームあるいはその他の管理フレームなど、別の方法で事前に通知されてもよい。
端末1〜4は、端末情報フィールドおよび共通情報フィールドで指定された条件がある場合は、その条件を満たすようにデータフレームの生成および送信(より詳細にはデータフレームを含む物理パケットの生成および送信)を行う。
例えば、トリガーフレーム507にて、各端末が送信すべきアクセスカテゴリ(AC)の情報が指定されている場合は、当該指定されたAC(指定ACと呼ぶ)に属するデータ(ここではMSDUとする)を選択し、当該MSDUを含むデータフレームを送信する。送信するデータフレームがアグリゲーションフレームなど、複数のMSDUをデータフレームに含めることが可能な場合、または、複数のリソースが指定されており、リソース毎にMSDUが送信可能な場合、または、指定ACに属するMSDUが存在しない場合などは、指定AC以外のAC(非指定ACと呼ぶ)に属するMSDUを含めるようにしてもよい。この際、指定ACと非指定ACからそれぞれMSDUをいくつ選択するか、また、非指定ACのうちどのACを選択するかは、任意の方法で決めてよい。一例として、指定ACに属するMSDUを少なくとも1つ選択し、それ以外は自由に各ACからMSDUを選択するようにしてもよい。なお、トリガーフレーム507でACが指定された場合は、前述したEDCAの機能(各ACで独立してCSMA/CAの手続を行って最も速くアクセス権を獲得したACが送信をする機能)は、一時的に行わないようにしてもよいし、EDCAのパラメータを強制的に所定値に設定して確実に当該ACがアクセス権を獲得できるように制御してもよい。
また、トリガーフレーム507でPPDU長等のデータ長に関する条件が指定されている場合は、当該データ長の条件を満たすように、データフレームの生成および送信を行う。例えばPPDU長が指定された値に満たない場合は、MACフレームの末尾にパディングデータを付加してもよいし、あるいは、不足している分の時間の間は、何もデータを送信しない(ヌルデータを送信する)ようにしてもよい。また、対象端末は、トリガーフレームでMCSが指定されている場合は、指定されたMCSを適用して、MACフレームまたは物理パケットを生成する。
基地局は、端末1〜4からOFDMAまたはMU−MIMOで送信されるデータフレーム509〜512(より詳細にはデータフレームを含む物理パケット)を受信する。OFDMAの場合は、端末1〜4から送信されたデータフレームをそれぞれのリソースブロックで受信し、MU−MIMOの場合は各ストリームから端末ごとのデータフレームを受信する。基地局は、各端末から送信されたデータフレームを正しく受信すると、各データフレームの受信からSIFS時間の経過後に、送達確認応答フレーム513を端末1〜4に送信する。なお、SIFS時間は一例であり、他に定義した時間(IFS)でもかまわない。
送達確認応答フレーム513の送信として、例えばBAフレームを端末毎に、それぞれデータフレームが受信されたリソースブロックで送信する。基地局に送信されたデータフレームがA−MPDUでなく、通常(単一)のMPDUを含む場合は、BAフレームではなくACKフレームでもよい(なお、通常のMPDUの場合にBAフレームを返すことも可能である)。このように端末毎にそれぞれのリソースブロックでBA(またはACK)フレームを送信することは、ダウンリンクのOFDMAで送達確認応答フレームを送信することに相当する。この場合、各端末はそれぞれのリソースブロックでBA(またはACK)フレームを受信する(そのようにリソースブロック単位で信号を受信できるように、受信フィルタを設定しておく)。または、BAフレーム(またはACKフレーム)を端末毎に、それぞれストリームで同時送信することも可能である。つまり、ダウンリンクのMU−MIMOで送達確認応答フレームを送信する。ダウンリンクのMU−MIMOは、IEEE802.11acで規定されている。なお、アップリンク送信がOFDMAで、ダウンリンク送信がMU−MIMO、またはアップリンク送信がMU−MIMOで、ダウンリンク送信がOFDAMであることも排除されない。
または、端末1〜4用の送達確認応答をすべて含む単一のフレームを送信(シングルユーザ送信)してもよい。この場合、このフレームのことを、Multi−STA BAフレームと呼んでもよい。具体的な構成としては、例えばIEEE802.11規格で定義されたMulti−TID BAフレームを流用してもよい。一例として、Multi−TID BAフレームのBA情報フィールドを端末数分配置し、各BA情報フィールドのTID情報サブフィールド内の予約フィールドに、端末の識別子(例えばAID(Association ID)またはAIDの一部)を設定する。各BA情報フィールドのBlock Ack Starting Sequence ControlサブフィールドおよびBlock Ack Bitmapサブフィールドには通常通り、送達確認応答を返すべきデータフレーム509〜512に応じて値を設定すればよい。Multi−STA BAフレームのRA(受信先アドレス)は、端末1〜4が共通に属するグループのマルチキャストアドレス、またはブロードキャストアドレスとすればよい。このようにすることで、1つのフレームで複数の端末にBAを通知できる。またFrame Controlフィールドのサブタイプは、新たに値を定義してもよい。
また端末1〜4にBAフレームではなくACKフレームを返す場合は、各BA情報フィールドのTID情報サブフィールド内の予約フィールドにおける一部のフィールドを端末の識別子とし、残りの一部のフィールドのビットを立てる(1にする)ようにする。そして、当該ビットを立てた場合に、Block Ack Starting Sequence ControlサブフィールドおよびBlock Ack Bitmapサブフィールドは省略する(存在しない)。これにより、1つのフレームで複数の端末のACKを通知できる。ここで述べた例は、一例であり、Multi−TID BAフレーム以外の既存のフレームを流用してもよいし、既存のフレームを流用するのではなく、新規にフレームを定義してもよい。
ここでは送達確認応答フレーム513を端末1〜4に一度に送信する場合を示したが、端末1〜4に順番にBAフレームまたはACKフレームを返す方法も可能である。順番に返す際、1番目の端末には、アップリンク送信されたデータフレームの受信完了後にBAフレームを返し、2番目以降の端末についてはBARフレームを送信し、その応答としてBAフレームを受信することを順番に行ってもよい。あるいは、2番目以降の端末については、BARフレームは送信せずにBAフレームを送信し、応答としてACKフレームを受信することを順番に繰り返してもよい。どの端末が1番目かはトリガーフレーム507の共通情報フィールドまたは端末情報フィールド等で通知してもよいし、別の方法で通知してもよい。トリガーフレーム507で通知する場合、例えば一番先頭の端末情報フィールドを割り当てられた端末が1番目の端末などと暗示的な通知を行ってもよい。ここで述べた以外の方法で通知してもよい。
送達確認応答フレーム513の送信後に、端末1〜4によるUL−MU送信と、基地局による送達確認応答フレームの送信が繰り返し行われてもよい。
上述したように、端末1、2、3、4がUL−MU−MIMO送信する物理パケットのヘッダ内には、アップリンクの伝搬路応答の推定のためのプリアンブルを追加してもよい。このとき、各端末のプリアンブルは互いに直交する関係になるようにする。直交するとは、プリアンブルのビット列の各値を成分とするベクトルの内積がゼロになることである。
図13に、端末1〜4がUL−MU−MIMO送信する物理パケットの概略構成を示す。各物理パケットのヘッダ内には、L−STF、L−LTF、L−SIG以外に、プリアンブル1〜4等のフィールドが配置されている。プリアンブル1〜4より前のL−STF、L−LTF、L−SIG等のフィールドは、各端末で同じ値が設定されている。つまり、同じ値が設定されるように事前に基地局から各端末に必要な情報が通知されているか、システムまたは規格で事前に決められているか、もしくはこれらの両方である。L−STF、L−LTF、L−SIGの“L”はレガシーを表し、これらのフィールドは、レガシー端末でも認識可能なフィールドである。
プリアンブル1〜4より後のフィールド(MACフレームが格納されているデータフィールドを含む)は、端末ごとに異なる内容(もしくは同じ内容でもよい)が設定されている。基地局では、プリアンブル1〜4より後のフィールドを、端末間で空間的に分離するため、プリアンブル1〜4を用いる。基地局は、通知フレームにおける端末情報フィールド1〜4で、端末1〜4で互いに直交するプリアンブルパターンを指定しておいてもよい。
基地局は、プリアンブル1〜4を利用して、各端末1〜4の各々のアンテナと、基地局の複数のアンテナとの間のアップリンクの伝搬路情報を算出し、算出した伝搬路情報を利用して、プリアンブル1〜4より後の端末毎のフィールドを復号する。なお、物理パケットのヘッダ内のプリアンブル1〜4より後に、各データフィールドのMCS(変調符号化方式)に関する情報などを格納したフィールド等が、別途配置されていてもよい。
図7のシーケンス例では、端末1〜4は、通知情報を設定する通知フィールドをデータフレームに設けたが、通知フィールドは、管理フレームに設けてもよい。例えば基地局とのアソシエーションプロセスを行う際に送信するアソシエーション要求フレームでもよいし、認証要求フレームでもよいし、その他の種類の管理フレームでもよい。また、データフレームおよび管理フレーム以外に、制御フレームに通知フィールドを設けることも排除されない。また、前述したように、通知情報を設定する通知フィールドを、シングルユーザ送信するフレームではなく、UL−MU送信するフレームに設けてもよい。
図7のシーケンス例では、個々の端末から、基地局にそれぞれ任意のタイミングでシングルユーザ送信するフレーム(より詳細にはフレームを含む物理パケット)で通知情報を送信したため、基地局が通知情報を受信するタイミングと、基地局がUL−MU送信の開始を決定するタイミングとの間に大きな時間の隔たりが生じる場合もある。つまり、端末が基地局に最後の通知情報を送信してから、UL−MU通信が開始されるまで、大きな時間が経過する場合もあり得る。この場合、端末側のアプリケーションの動作や、タイムアウト、あるいはシングルユーザ送信でのデータ送信完了などにより、端末において送信用のデータが存在しなくなる場合もある。このような端末を対象端末としてトリガーフレームで指定すると、当該端末に割り当てたリソース(リソースブロック、または空間リソース(プリアンブルパターンに対応))が無駄になってしまう。そこで、基地局は、UL−MU通信の開始を決定した場合、トリガーフレームの送信前に、問い合わせフェーズを設け、UL−MU送信の要求を有するかを各端末に問い合わせ、UL−MU送信の要求を有する端末の中から対象端末を選定してもよい。この際、UL−MU送信の要求を有するかを問い合わせる対象となる端末は、通知情報でUL−MU送信の要求がある旨を送信した、または当該要求があることを特定可能な情報を送信した端末にしてもよい。これにより問い合わせる端末の数を絞ることができるため、問い合わせ期間の長さを短くできる。また、UL−MU送信の要求のない端末へ問い合わせる可能性が減るため、効率的な問い合わせが可能になる。
図14に、トリガーフレームの送信前に行う問い合わせフェーズの動作シーケンスの例を示す。問い合わせフィーズの前では、図7におけるトリガーフレームの送信前のように、個々の端末と基地局との間でシングルユーザの通信が行われているものとする。
図14に示すように、基地局がUL−MU送信の開始を決定すると、UL−MU通信の候補端末を決定し、候補端末のうちの1つ(ここでは端末1)に問い合わせフレーム531を送信する。端末1は、問い合わせフレーム531の受信からSIFS時間後に、UL−MU送信の要求の有無を表す情報を含む要求フレーム532を送信する。
問い合わせフレーム531および要求フレーム532は、図5に示した一般的なMACフレームのフォーマットをベースに定義すればよい。問い合わせフレームは、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として、問い合わせフレームは制御フレームである。問い合わせフレーム531用に新規にサブタイプの値を定義しても構わない。問い合わせフレーム531のRAは端末1のMACアドレスであり、TAは基地局のBSSIDまたはMACアドレスである。ただし、RAをブロードキャストアドレスまたはマルチキャストアドレスとし、フレームボディフィールドに端末1の識別子(AIDまたはMACアドレスなど)を設定してもかまわない。なお、フレームボディフィールド等に、現時点で確定しているUL−MU通信の条件(例えば通信方式など)があれば、当該条件を設定してもよい。
要求フレーム532は、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として要求フレーム532は制御フレームである。要求フレーム532用に新規にサブタイプの値を定義しても構わない。要求フレーム532は、UL−MU送信の要求の有無を特定するための情報を含む。一例として、UL−MU送信用のデータの有無を表すビットをMACヘッダまたはボディフィールドまたは物理ヘッダに設けてもよい。また、要求フレーム532は、前述した通知情報(第1〜第9の例参照)を含んでも構わず、この場合、UL−MU通信の開始直前に、最新の通知情報を送信できる。
基地局は、他の候補端末についてもそれぞれ順番に選択し、問い合わせフレームの送信と要求フレームの受信を繰り返し行う。図の例では、端末1の次に端末2に問い合わせフレーム533を送信し、そのSIFS時間後に、端末2から要求フレーム534を受信する。そして、要求フレーム534の受信からSIFS時間後に、問い合わせフレーム535を端末3に送信し、そのSIFS時間後に、端末3から要求フレームを受信する。その後、端末4にも問い合わせフレームを送信し、そのSIFS時間後に、端末4から要求フレーム536を送信する。端末1〜4以外の候補端末が存在し、同様のプロセスが行われてもかまわない。
基地局は、すべての候補端末に対する問い合わせが完了すると、UL−MU送信に必要な事項を決定(対象端末の選定等)を行って、トリガーフレーム507を生成し、トリガーフレーム507を送信する。トリガーフレーム507の構成、およびトリガーフレーム507の送信以降のシーケンスは、図7の場合と同様であるため説明を省略する。なお、本シーケンス例でも、通知情報を設定する通知フィールドを、UL−MU送信するフレームに設けてもよい。
図14のシーケンス例では、基地局がUL−MU送信の開始を決定するタイミング(問い合わせフェーズを開始するタイミング)については特に特定しなかったが、端末からの要求に応じて、基地局がUL−MU送信の開始を決定することも可能である。この場合のシーケンス例を図15に示す。
基地局のBSSに属する端末のうちの1つ(ここでは端末1)が、要求フレーム521を送信する。より詳細には、端末1が、アップリンク送信用のデータを保持しており、CSMA/CAに従って、アクセス権を獲得する。すなわち、DIFS/AIFS[AC]時間とランダムに決定したバックオフ時間とのキャリアセンス時間(待機時間)の間、キャリアセンスを行って、無線媒体がアイドルであることにより、アクセス権を獲得する。端末2〜4も、アップリンク送信用のデータを保持しており、アクセス権の獲得を試みるが、端末1がアクセス権を獲得したものとする。
端末1は、アクセス権に基づくTXOPの間に、要求フレーム521を送信する。要求フレーム521は、図14のシーケンス例で用いた要求フレームと同様にして定義すればよい。基地局は、要求フレーム521の受信により、UL−MU送信の開始を決定する。
基地局は、端末1以外の端末の中から、UL−MU通信の候補端末を選択し、選択した候補端末を指定する情報を含む問い合わせフレーム522を送信する。より詳細に、基地局は、要求フレーム521の受信からSIFS時間後に、問い合わせフレーム522を送信する。問い合わせフレーム522は、制御フレーム、管理フレームおよびデータフレームのいずれの種別でも構わない。一例として、問い合わせフレーム522は制御フレームである。問い合わせフレーム522用に新規にサブタイプの値を定義しても構わない。一例として、問い合わせフレーム522のRAはブロードキャストアドレスまたはマルチキャストアドレス、TAは基地局のBSSIDまたはMACアドレスである。
問い合わせフレーム522のフレームボディフィールドまたはMACヘッダまたは物理ヘッダに、候補端末を指定するためのフィールドを設け、当該フィールドに候補端末を指定する情報を設定する。例えば候補端末の識別子を格納するフィールド(端末IDフィールドと呼んでもよい)を、例えば候補端末数だけ設け、各端末IDフィールドに、選択した候補端末の識別子(AIDまたはMACアドレスなど)を設定する。または、各候補端末が共通に属するグループのグループIDをフィールドに設定してもよく、この場合、当該グループに端末1が属していてもかまわない。
問い合わせフレーム522を受信した端末は、問い合わせフレーム522で自端末が指定されているかを確認する。例えば端末IDフィールドのいずれかに自端末の識別子が設定されているか、またはフィールドに設定されているグループIDのグループに自端末が属しているかで自端末が指定されているか判断する。端末(端末1を除く)は、候補端末として指定されていた場合は、CSMA/CAに基づきアクセス権を獲得して、要求フレームを送信する。図の例では、端末2〜4が、それぞれアクセス権を獲得して、要求フレーム523、525、527を送信している。
基地局は、候補端末のすべてから要求フレームを受信した場合、もしくは、予め定めた時間が経過した場合は、問い合わせフェーズを終了する。基地局は、問い合わせフェーズを終了すると、UL−MUに必要な事項の決定(対象端末の選定およびパラメータ情報の決定等)を行う。基地局は、CSMA/CAに基づき、無線媒体へのアクセス権を獲得して、上記の決定基づき生成したトリガーフレーム507を送信する。トリガーフレーム507の送信以降のシーケンスは、図7の場合と同様であるため説明を省略する。なお、本シーケンス例でも、通知情報を設定する通知フィールドを、UL−MU送信するフレームに設けてもよい。
図14および図15で示した問い合わせフェーズのシーケンス例は一例であり、ここで示した以外のシーケンスでも構わない。例えば、図15のシーケンス例では基地局は要求フレーム523、525、527に対して送達確認応答フレームを返さなかったが、送達確認応答フレームを返すようにしてもよい。また図14のシーケンス例では、候補端末のすべてに問い合わせフレームを順番に送信したが、基地局は最初に1回のみ、複数の候補端末を指定する情報(各候補端末の識別子、またはグループID等)を含む問い合わせフレームを送信し、問い合わせフレームで指定された端末がSIFS時間ずつ空けて順番に要求フレームを送信するようにしてもよい。この場合、この問い合わせフレームには、要求フレームを送信する候補端末の順序を特定する情報が含まれており、この情報から自端末の順位を把握し、さらに要求フレーム長(要求フレーム長は、固定長等、予め分かっているものとする)から、自端末が送信する要求フレームのタイミングを把握してもよい。あるいは、自端末の識別子が格納されたフィールドが問い合わせフレームの何番目に設定されているかに応じて、自端末の順位を間接的に把握してもよい。ここで述べた以外にも、問い合わせフェーズとして様々なシーケンス例が可能である。
また、図14または図15のシーケンスのバリエーションとして、トリガーフレームで指定された端末が、トリガーフレームに応答して、UL−MUで送信要求を送信することも可能である。例えば各端末は、QoS Nullデータを送信し、そのMACヘッダに送信バッファの情報(送信バッファ内のデータ量など)を入れるようにする。この場合、トリガーフレームで指定するUL−MUのPPDU長は、例えばMACヘッダの最大長によって制限する。トリガーフレームでは、送信要求を収集するための意図であることを通知するための情報を設定してもよい。トリガーフレームで指定された端末は、この情報が設定されている場合に、送信バッファ情報を送信するようにしてもよい。当然、MACヘッダの最大長より長いPPDU長を指定してしてもよく、この場合は、そのサイズ以下に納まるように、フレームボディフィールドにデータを入れつつ、MACヘッダに送信要求(送信バッファ情報等)を入れたフレームを送信するようにしてもよい。
他のバリエーションとして、以下に説明するランダムアクセスOFDMAと呼ばれる方式を用いて1つまたは複数の端末がUL−MUするフレームに、送信バッファ情報を入れるようにしてもよい。この際、端末から送信するフレームは、上記のバリエーションの場合と同様である。端末は、送信要求がある、つまり送信バッファ内にアップリンク送信用のデータがある場合に、後述するランダムアクセス用トリガーフレームで端末が未指定のリソースブロック(どの端末も指定されていないリソースブロック、すなわち、任意の端末が利用可能であるリソースブロック)をランダムに選択して、選択したリソースブロックを介して、送信要求を入れたフレームを送信する。
ランダムアクセスOFDMAについて説明する。ランダムアクセスOFDMAでは、上述したUL−OFDMAの場合と同様、基地局がトリガーフレームを送信し、トリガーフレームに応答して1つまたは複数の端末が同時にアップリンク送信する。ただし、このトリガーフレームでは、端末の指定は行わず、使用するリソースブロックのみを指定する。ただし、一部のリソースブロックに対しては端末の指定を行い、別のリソースブロックに対しては端末の指定を行わない場合もある。いずれの場合も、トリガーフレームを受信した端末(例えばどのリソースブロックも指定されていない端末)は、端末の指定がないリソースブロック(端末未指定リソースブロック)から、ランダムにリソースブロックを選択して使用する。このように端末未指定リソースブロックの指定を含むトリガーフレームを、ランダムアクセス用トリガーフレームと呼ぶことがある。基地局が送信するトリガーフレームとして、ランダムアクセス用トリガーフレームを用いることで、トリガーフレームで指定されていない端末が、端末未指定リソースブロックからランダムにリソースブロックを選択して、フレームを送信することができる。なお、端末がランダムにリソースブロックを選択する方法は、乱数を利用して選択する方法など任意の方法でかまわない。ランダムアクセス用トリガーフレームの構成は端末未指定リソースブロックを表現できる限り、任意でかまわない。例えば図11(A)のフォーマットにおいて、STA Infoフィールドに、端末の識別子の代わりに、所定の識別子(どの端末にも割り当てられない識別子)とリソースブロックの識別子とを設定し、この所定の識別子が設定されたリソースブロックは、端末未指定リソースブロックであると解釈してもよい。
図16に、本発明の実施形態に係る端末の動作の一例のフローチャートを示す。この端末の動作は、図7に示したシーケンス例における端末の動作に対応する。端末は、送信用のデータを保持している場合(S101のYES)、CSMA/CAに従って無線媒体へのアクセス権を獲得し、当該データを含むデータフレームを生成し、TXOPの間、データフレーム(より詳細にはデータフレームを含む物理パケット)を送信する(S102)。ここでデータフレームまたは物理パケットの物理ヘッダは、前述した通知フィールドを含み、通知フィールドには、通知情報(前述した第1〜第9の例の通知情報を参照)を設定する。このように、通知情報は、端末が自発的に送信するデータフレームに格納されて送られる、すなわち、基地局から通知情報の送信要求を受けること無く送信される。本例では、データフレームに通知情報を含める例を示しているが、管理フレームまたは制御フレームに通知情報を含めて送ることも可能である。端末は、基地局からトリガーフレームを受信しない間は(S103のNO)、上記と同様の処理を繰り返す。端末は、基地局からトリガーフレームを受信した場合は(S103のYES)、自端末がUL−MU送信の対象端末として指定されているかを判断し、自端末が指定されている場合は(S104のYES)、トリガーフレームの受信完了から一定時間後に、送信用のデータを含むデータフレーム(より詳細にはデータフレームを含む物理パケット)を送信する(S105)。
トリガーフレームで、送信するデータまたはデータフレーム等に関する条件が指定されている場合は、その条件を満たすようにデータフレームを生成および送信する。送信用のデータが存在しない場合は、ヌルパケットを送信または何も送信しないようにしてもよい。ここではデータフレームを送信したが、管理フレームまたは制御フレームを送信してもよい。当該データフレームに、通知情報を設定する通知フィールドを設けてもよい。端末は、データフレームの送信からSIFS時間後、基地局から送達確認フレームを受信する。なお、端末は、送達確認応答フレームの受信からSIFS後にさらにデータフレームを送信する構成も可能である。
図17に、本発明の実施形態に係る基地局の動作の一例のフローチャートを示す。この基地局の動作は、図7に示したシーケンス例における基地局の動作に対応する。基地局は、端末からデータフレーム等のフレームを受信したら(S201)、フレームから通知情報を取得し(通知フィールドが存在するフレームの場合)、通知情報に基づき、UL−MU送信の要求の有無等、端末の状態を管理する(S202)。基地局は、UL−MU通信の開始を決定するまで、上記の処理を繰り返す。UL−MU通信の開始を決定すると(S203のYES)、UL−MU通信の対象端末、および送信の際のパラメータ情報等、必要事項の決定を行い(S204)、対象端末にトリガーフレームを送信する(S205)。基地局は、トリガーフレームの送信から一定時間後に対象端末から同時に送信されるデータフレーム等のフレームを受信する(S206)。基地局は、フレームの受信からSIFS時間後に、対象端末に送達確認応答フレームを送信する。この後、基地局は、再度必要事項の決定の処理(S204)に戻ってもよいし、トリガーフレームの送信処理(S205)に戻ってもよいし、UL−MU送信の受信処理(S206)に戻ってもよい。あるいは、ステップS201など他のステップの処理に戻ってもよい。基地局は、端末からUL−MU送信されるフレームに通知情報が設定されている場合は、当該通知情報を次以降のUL−MU送信に必要な事項を決定するために用いる。
図18に、本発明の実施形態に係る基地局の動作の他の例のフローチャートを示す。図17との差分は、基地局が、UL−MU送信の開始を決定した後、トリガーフレームの送信前に、図14または図15に示したような問い合わせフェーズ(S207)を実行することにある。例えば、問い合わせフェーズでは、問い合わせフェーズ前に収集した通知情報に基づき、UL−MU送信を行う候補端末を選択し、選択した候補端末にUL−MU通信の実行要求の有無等に関する問い合わせフレームを送信する。そして、候補端末からUL−MU通信の実行要求の有無等を通知する要求フレームを受信する。問い合わせフェーズ後の必要事項の決定(S204)では、例えば、候補端末のうち、UL−MU通信の実行要求有りを通知した端末の中から対象端末を選択する。つまり、問い合わせフェーズ前に収集した通知情報でラフな推定を行い、問い合わせフェーズでの問い合わせにより、より精度の高い推定を行っているということができる。UL−MU送信の実行後、再度、問い合わせフェーズに戻ってもよいし、その他のステップの処理に戻ってもよい。
本実施形態では、UL−MU通信の必要事項の決定のために通知情報を送信したが、変形例として、HCCA環境において、基地局の通信対象となる端末を決定、または端末にデータ送信させるTIDを決定するために、各端末から基地局に通知情報を送信することも可能である。HCCA環境では、基地局が端末にQoS CF−Pollフレームを送信し、端末は、当該フレームで指定されたTXOPの間、フレームを送信することを許容される。QoS CF−PollフレームではTIDが指定される。そこで、基地局が、端末およびTIDの少なくとも一方を指定するための判断材料として、前述した第1〜第9の例の少なくとも1つまたはこれらの任意の組み合わせに係る通知情報を各端末が送信することも可能である。
以上、本実施形態によれば、各端末が、基地局から要求を受けること無く、通知情報を含むフレームを送信することで、基地局は効率的に通知情報を収集できる。また、各端末は、CSMA/CAベースで通常に基地局にシングルユーザ送信するフレーム(データフレーム、アソシエーション要求フレームなど)に通知情報を含めることで、システム効率の低下を抑制しつつ、基地局は通知情報を収集できる。また、基地局は、問い合わせフェーズを設けることで、アップリンク用のデータを有する端末をより確実に絞り込むことができる。
(第2の実施形態)
図19は、第2の実施形態に係る基地局(アクセスポイント)400の機能ブロック図である。このアクセスポイントは、通信処理部401と、送信部402と、受信部403と、アンテナ42A、42B、42C、42Dと、ネットワーク処理部404と、有線I/F405と、メモリ406とを備えている。アクセスポイント400は、有線I/F405を介して、サーバ407と接続されている。通信処理部401は、第1の実施形態で説明したMAC処理部10およびMAC/PHY管理部60と同様な機能を有している。送信部402および受信部403は、第1の実施形態で説明したPHY処理部50およびアナログ処理部70と同様な機能を有している。ネットワーク処理部404は、第1の実施形態で説明した上位処理部90と同様な機能を有している。ここで、通信処理部401は、ネットワーク処理部404との間でデータを受け渡しするためのバッファを内部に保有してもよい。このバッファは、DRAM等の揮発性メモリでもよいし、NAND、MRAM等の不揮発メモリでもよい。
ネットワーク処理部404は、通信処理部401とのデータ交換、メモリ406とのデータ書き込み・読み出し、および、有線I/F405を介したサーバ407との通信を制御する。ネットワーク処理部404は、TCP/IPやUDP/IPなど、MAC層の上位の通信処理やアプリケーション層の処理を行ってもよい。ネットワーク処理部の動作は、CPU等のプロセッサによるソフトウェア(プログラム)の処理によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。
一例として、通信処理部401は、ベースバンド集積回路に対応し、送信部402と受信部403は、フレームを送受信するRF集積回路に対応する。通信処理部401とネットワーク処理部404とが1つの集積回路(1チップ)で構成されてもよい。送信部402および受信部403のデジタル領域の処理を行う部分とアナログ領域の処理を行う部分とが異なるチップで構成されてもよい。また、通信処理部401が、TCP/IPやUDP/IPなど、MAC層の上位の通信処理を実行するようにしてもよい。また、アンテナの個数はここでは4つであるが、少なくとも1つのアンテナを備えていればよい。
メモリ406は、サーバ407から受信したデータや、受信部402で受信したデータの保存等を行う。メモリ406は、例えば、DRAM等の揮発性メモリでもよいし、NAND、MRAM等の不揮発メモリでもよい。また、SSDやHDD、SDカード、eMMC等であってもよい。メモリ406が、基地局400の外部にあってもよい。
有線I/F405は、サーバ407とのデータの送受信を行う。本実施形態では、サーバ407との通信を有線で行っているが、サーバ407との通信を無線で実行するようにしてもよい。
サーバ407は、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばHTTPサーバ(Webサーバ)、FTPサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。PCやスマートフォン等のユーザが操作する通信装置でもよい。また、基地局400と無線で通信してもよい。
基地局400のBSSに属するSTAが、サーバ407に対するデータの転送要求を発行した場合、このデータ転送要求に関するパケットが、基地局400に送信される。基地局400は、アンテナ42A〜42Dを介してこのパケットを受信し、受信部403で物理層の処理等を、通信処理部401でMAC層の処理等を実行する。
ネットワーク処理部404は、通信処理部401から受信したパケットの解析を行う。具体的には、宛先IPアドレス、宛先ポート番号等を確認する。パケットのデータがHTTP GETリクエストのようなデータ転送要求である場合、ネットワーク処理部404は、このデータ転送要求で要求されたデータ(例えば、HTTP GETリクエストで要求されたURLに存在するデータ)が、メモリ406にキャッシュ(記憶)されているかを確認する。メモリ406には、URL(またはその縮小表現、例えばハッシュ値や、代替となる識別子)とデータとを対応づけたテーブルが格納されている。ここで、データがメモリ406にキャッシュされていることを、メモリ406にキャッシュデータが存在すると表現する。
メモリ406にキャッシュデータが存在しない場合、ネットワーク処理部404は、有線I/F405を介して、サーバ407に対してデータ転送要求を送信する。つまり、ネットワーク処理部404は、STAの代理として、サーバ407へデータ転送要求を送信する。具体的には、ネットワーク処理部404は、HTTPリクエストを生成し、TCP/IPヘッダの付加などのプロトコル処理を行い、パケットを有線I/F405へ渡す。有線I/F405は、受け取ったパケットをサーバ407へ送信する。
有線I/F405は、データ転送要求に対する応答であるパケットをサーバ407から受信する。ネットワーク処理部404は、有線I/F405を介して受信したパケットのIPヘッダから、STA宛のパケットであることを把握し、通信処理部401へパケットを渡す。通信処理部401はこのパケットに対するMAC層の処理等を、送信部402は物理層の処理等を実行し、STA宛のパケットをアンテナ42A〜42Dから送信する。ここで、ネットワーク処理部404は、サーバ407から受信したデータを、URL(またはその縮小表現)と対応づけて、メモリ406にキャッシュデータとして保存する。
メモリ406にキャッシュデータが存在する場合、ネットワーク処理部404は、データ転送要求で要求されたデータをメモリ406から読み出して、このデータを通信処理部401へ送信する。具体的には、メモリ406から読み出したデータにHTTPヘッダ等を付加して、TCP/IPヘッダの付加等のプロトコル処理を行い、通信処理部401へパケットを送信する。このとき、一例として、パケットの送信元IPアドレスは、サーバと同じIPアドレスに設定し、送信元ポート番号もサーバと同じポート番号(通信端末が送信するパケットの宛先ポート番号)に設定する。したがって、STAから見れば、あたかもサーバ407と通信をしているかのように見える。通信処理部401はこのパケットに対するMAC層の処理等を、送信部402は物理層の処理等を実行し、STA宛のパケットをアンテナ42A〜42Dから送信する。
このような動作により、頻繁にアクセスされるデータは、メモリ406に保存されたキャッシュデータに基づいて応答することになり、サーバ407と基地局400間のトラフィックを削減できる。なお、ネットワーク処理部404の動作は、本実施形態の動作に限定されるものではない。STAの代わりにサーバ407からデータを取得して、メモリ406にデータをキャッシュし、同一のデータに対するデータ転送要求に対しては、メモリ406のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題はない。
図19と同じブロック構成で、キャッシュ機能を備えた端末(STA)を実現することができる。この場合、有線I/F405を省略してもよい。本実施形態の端末を、第1の実施形態の端末として適用可能である。例えば、端末は、メモリ406にキャッシュされているデータを読み出し、読み出したデータを含むデータフレーム(より詳細には物理ヘッダを付加した物理パケット)を、基地局に送信する。当該データはサーバ407から取得したデータであっても、別の方法で取得したデータ(例えばサーバ407以外の外部装置から取得したデータ、またはユーザが指定したファイルデータなど)であってもよい。また、端末は、第1の実施形態で説明した各例の通知情報(制御情報)を、メモリ406にキャッシュされている基地局への送信用のデータに基づき生成してもよい。端末は、生成した通知情報を、図6のデータフレーム501、503、505を介して送信してもよいし、データフレーム509〜512を介して送信してもよい。また、端末は、メモリ406にキャッシュされている基地局への送信用のデータを、図6のデータフレーム501、503、505を介して送信してもよいし、アップリンクマルチユーザ送信で図6のデータフレーム509〜512を介して送信してもよい。
なお、マルチホップネットワークの場合、端末は、非基地局としての端末の役割と、基地局としての役割との両方を備える。端末は、基地局として動作する場合に、他の端末から受信したデータを、別の基地局へ当該データを転送する端末として動作する場合のため、メモリにキャッシュしておけばよい。
本実施形態の基地局を第1の実施形態に適用する場合、以下の動作を行ってもよい。基地局は、端末に送信するデータをメモリ406から読み出し、読み出したデータを含むフレーム(トリガーフレーム、問い合わせフレーム、またはデータフレーム等)を生成および送信してもよい。また、メモリ406における各端末への送信用のデータそのものを、トリガーフレーム等のフレームに追加してもよい。メモリ406における各端末への送信用のデータは、各端末からのデータ転送要求を受けて取得したものに限らず、当該データ転送要求とは関係無しに、サーバ407またはサーバ407以外の外部装置から送信されたデータでもよい。例えば各端末宛てのプッシュデータまたは電子メールデータなどでもよい。なお、基地局は、複数の端末に対してダウンリンクのマルチユーザ方式(DL−OFDMA、DL−MU−MIMO、またはこれらを組み合わせた方式(DL−OFDMA&DL−MU−MIMO)等)で、メモリ406における複数の端末への送信用のデータを送信してもよい。
(第3の実施形態)
図20は、端末または基地局の全体構成例を示したものである。この構成例は一例であり、本実施形態はこれに限定されるものではない。端末または基地局は、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カメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ/サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等でもよい。
図21は、無線LANモジュールのハードウェア構成例を示す。この構成は、無線通信装置が非基地局の端末および基地局のいずれに搭載される場合にも適用可能である。つまり、図1に示した無線通信装置の具体的な構成の一例として適用できる。この構成例では、少なくとも1本のアンテナ247を備える。複数のアンテナを備える場合、各アンテナに対応して、送信系統(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は、帯域通過フィルタでも、低域通過フィルタでもよい。RF IC221は、スイッチ245を介して、アンテナ247に結合されている。
フィルタ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に接続され、受信時は、受信側のバラン234またはRF IC221に接続される。スイッチ245の制御はベースバンドIC211またはRF IC221により行われてもよいし、スイッチ245を制御する別の回路が存在し、当該回路からスイッチ245の制御を行ってもよい。
プリアンプ224で増幅された無線周波数のアナログI信号およびアナログQ信号は、バラン225で平衡−不平衡変換された後、アンテナ247から空間に電波として放射される。
アンテナ247は、チップアンテナでもよいし、プリント基板上に配線により形成したアンテナでもよいし、線状の導体素子を利用して形成したアンテナでもよい。
RF IC221におけるLNA234は、アンテナ247からスイッチ245を介して受信した信号を、雑音を低く抑えたまま、復調可能なレベルまで増幅する。バラン235は、低雑音増幅器(LNA)234で増幅された信号を、不平衡−平衡変換する。ミキサ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の処理を行う構成も可能である。
(第4の実施形態)
図22(A)及び図22(B)は、それぞれ第4の実施形態に係る無線通信端末の斜視図である。図22(A)の無線通信端末はノートPC301であり、図22(B)の無線通信端末は移動体端末321である。それぞれ、端末(基地局を含む)の一形態に対応する。ノートPC301及び移動体端末321は、それぞれ無線通信装置305、315を搭載している。無線通信装置305、315として、これまで説明してきた端末(基地局を含む)に搭載されていた無線通信装置を用いることができる。無線通信装置を搭載する無線通信端末は、ノートPCや移動体端末に限定されない。例えば、TV、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Webカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ/サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等にも搭載可能である。
また、端末(基地局を含む)に搭載されていた無線通信装置は、メモリーカードにも搭載可能である。当該無線通信装置をメモリーカードに搭載した例を図23に示す。メモリーカード331は、無線通信装置355と、メモリーカード本体332とを含む。メモリーカード331は、外部の装置(無線通信端末または基地局、またはこれらの両方等)との無線通信のために無線通信装置335を利用する。なお、図23では、メモリーカード331内の他の要素(例えばメモリ等)の記載は省略している。
(第5の実施形態)
第5の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、バス、プロセッサ部、及び外部インタフェース部を備える。プロセッサ部及び外部インタフェース部は、バスを介してバッファと接続される。プロセッサ部ではファームウエアが動作する。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。ファームウエアが動作するプロセッサ部は、本実施形態に係る通信処理装置または制御部の処理を行うプロセッサであってもよいし、当該処理の機能拡張または変更に係る処理を行う別のプロセッサであってもよい。ファームウエアが動作するプロセッサ部を、本実施形態に係る基地局あるいは無線通信ン端末あるいはこれらの両方が備えてもよい。または当該プロセッサ部を、基地局に搭載される無線通信装置内の集積回路、または無線通信端末に搭載される無線通信装置内の集積回路が備えてもよい。
(第6の実施形態)
第6の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、クロック生成部を備える。クロック生成部は、クロックを生成して出力端子より無線通信装置の外部にクロックを出力する。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側とを同期させて動作させることが可能となる。
(第7の実施形態)
第7の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、電源部、電源制御部、及び無線電力給電部を含む。電源制御部は、電源部と無線電力給電部とに接続され、無線通信装置に供給する電源を選択する制御を行う。このように、電源を無線通信装置に備える構成とすることにより、電源を制御した低消費電力化動作が可能となる。
(第8の実施形態)
第8の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、SIMカードを含む。SIMカードは、例えば、無線通信装置におけるMAC処理部10、MAC/PHY管理部60、または、制御部112と接続される。このように、SIMカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。
(第9の実施形態)
第9の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、動画像圧縮/伸長部を含む。動画像圧縮/伸長部は、バスと接続される。このように、動画像圧縮/伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長とを容易に行うことが可能となる。
(第10の実施形態)
第10の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、LED部を含む。LED部は、例えば、MAC処理部10、MAC/PHY管理部60、送信処理回路113、受信処理回路114、制御部112の少なくとも1つと接続される。このように、LED部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
(第11の実施形態)
第11の実施形態では、上述したいずれかの実施形態に係る無線通信装置の構成に加えて、バイブレータ部を含む。バイブレータ部は、例えば、MAC処理部10、MAC/PHY管理部60、送信処理回路113、受信処理回路114、制御部112の少なくとも1つと接続される。このように、バイブレータ部を無線通信装置に備える構成とすることにより、無線通信装置の動作状態を、ユーザに容易に通知することが可能となる。
(第12の実施形態)
第12の実施形態では、上述したいずれかの実施形態に係る無線通信装置(基地局の無線通信装置または無線通信端末の無線通信装置、またはこれらの両方)の構成に加えて、ディスプレイを含む。ディスプレイは、図示しないバスを介して、無線通信装置のMAC処理部に接続されてもよい。このようにディスプレイを備える構成とし、無線通信装置の動作状態をディスプレイに表示することで、無線通信装置の動作状態をユーザに容易に通知することが可能となる。
(第13の実施形態)
本実施形態では、[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におけるランダムアクセスに基づく競合期間のフレーム交換の一例を図24に示す。
ある無線通信装置においてデータフレーム(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とその推定時間の和とすることもできる。
本実施形態で用いられる用語は、広く解釈されるべきである。例えば用語“プロセッサ”は、汎用目的プロセッサ、中央処理装置(CPU)、マイクロプロセッサ、デジタル信号プロセッサ(DSP)、コントローラ、マイクロコントローラ、状態マシンなどを包含してもよい。状況によって、“プロセッサ”は、特定用途向け集積回路、フィールドプログラマブルゲートアレイ(FPGA)、プログラム可能論理回路(PLD)などを指してもよい。“プロセッサ”は、複数のマイクロプロセッサのような処理装置の組み合わせ、DSPおよびマイクロプロセッサの組み合わせ、DSPコアと協働する1つ以上のマイクロプロセッサを指してもよい。
別の例として、用語“メモリ”は、電子情報を格納可能な任意の電子部品を包含してもよい。“メモリ”は、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、プログラム可能読み出し専用メモリ(PROM)、消去可能プログラム可能読み出し専用メモリ(EPROM)、電気的消去可能PROM(EEPROM)、不揮発性ランダムアクセスメモリ(NVRAM)、フラッシュメモリ、磁気または光学データストレージを指してもよく、これらはプロセッサによって読み出し可能である。プロセッサがメモリに対して情報を読み出しまたは書き込みまたはこれらの両方を行うならば、メモリはプロセッサと電気的に通信すると言うことができる。メモリは、プロセッサに統合されてもよく、この場合も、メモリは、プロセッサと電気的に通信していると言うことができる。
なお、各実施形態で述べるフレームは、例えばIEEE802.11規格でフレームと呼ばれているもののみならず、Null Data Packetなど、パケットと呼ばれているものを指してもよい。基地局が複数のフレームまたは複数の第Xフレームを送信または受信すると表現する場合、これらのフレームまたは第Xフレームは同じものであっても異なるものであってもよい。Xには状況に応じて任意の値を入れることができる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。