以下、図面を参照しながら、本発明の実施形態について説明する。無線LANの規格として知られているIEEE Std 802.11(TM)-2012およびIEEE Std 802.11ac(TM)-2013、次世代無線LAN規格であるIEEE Std 802.11ax用の仕様フレームワーク文書(Specification Framework Document)である2016年5月25日付けでアップロードされたIEEE 802.11-15/0132r17は、本明細書においてその全てが参照によって組み込まれる(incorporated by reference)ものとする。
(第1の実施形態)
図1に、第1の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局(以下、基地局またはアクセスポイント)、または基地局と通信する無線通信端末(以下、端末)に適用することができる。基地局は、主に中継機能を有する点を除いて、基本的に端末と同様の通信機能を有するため、端末の一形態である。機能ブロックの動作は、基本的に両者で共通であるが、基地局と非基地局の端末とで異なる部分もある。以下の説明で端末と言うときは、特に両者を区別する必要がない限り、基地局を指してもよい。
図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を介して信号を送受信する無線通信部(送信部および受信部)の一形態に相当する。制御部の機能は、CPU等のプロセッサで動作するソフトウェア(プログラム)によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはROM、RAM等のメモリ、ハードディスク、SSDなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。メモリはSRAM、DRAM等の揮発性メモリでも、NAND、MRAM等の不揮発性メモリでもよい。
上位処理部90は、MAC(Medium Access Control:媒体アクセス制御)層に対して上位層のための処理を行う。上位処理部90は、MAC処理部10との間で信号をやり取りできる。上位層としては、代表的なものとしては、TCP/IPやUDP/IP、さらにその上層のアプリケーション層などが挙げられるが、これに限定されない。上位処理部90は、MAC層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。上位処理部90を介して有線インフラに接続するようになっていてもよい。バッファは、メモリでもよいし、SSD、ハードディスク等でもよい。バッファがメモリの場合、当該メモリはSRAM、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は、アップリンクマルチユーザ(UL-MU:Uplink Multiuser)通信として、マルチユーザMIMO(Multi-user Multiple-Input Multiple-Output:MU-MIMO)または直交周波数分割多重アクセス(Orthogonal Frequency Division Multiplexing Access:OFDMA)に関する処理を行う。アップリンクのMU-MIMOは、UL-MU-MIMO、アップリンクのOFDMAはUL-OFDMAと記述する。ダウンリンクのMU-MIMOは、DL-MU-MIMO、ダウンリンクのOFDMAはDL-OFDMAと記述する。
UL-MU-MIMOは、基地局が、複数台の端末から空間多重で(同一周波数帯域で同時に)送信されるフレームを、複数のアンテナで同時に受信し、受信信号をMIMO復調することで、各端末のフレームへ分離する通信方式である。各端末から送信されるフレームの先頭に付加されるプリアンブル信号を利用して、基地局は、アップリンクの伝搬路応答を推定する。このプリアンブル信号は、端末間で互いに直交している。基地局は、伝搬路応答を利用して、プリアンブル信号より後のフィールドを正しく空間的に分離(復号)出来る。プリンアンブル信号は、本実施形態に係るリソースの一例に対応する。
OFDMAは、1つまたは複数のサブキャリアを含む複数のリソースユニットを複数の端末にそれぞれ割り当て、基地局と複数の端末との間で同時に送受信を同時に行う方式である。リソースユニットは、通信を行うリソースの最小単位となる周波数成分であり、本実施形態に係るリソースの一例に対応する。
UL-MU-MIMOとOFDMAのさらなる詳細は、後述する。なお、PHY処理部50は、UL-MU-MIMOとUL-OFDMAを組み合わせた方式に関する処理を行ってもよい。
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)と呼んでいる。加えて、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-MIMOまたはUL-OFDMA)に対応か否か、また、UL-MU対応の場合にUL-MU能力の有効(オン)/無効(オフ)の情報も保持されていてもよい。MIBを保持・管理するためのメモリは、MAC/PHY管理部60に内包させてもよいし、MAC/PHY管理部60に内包せずに別に設けるようにしてもよい。MIBを保持・管理するためのメモリをMAC/PHY管理部60とは別に設ける場合に、MAC/PHY管理部60は、その別のメモリを参照でき、またメモリ内の書き換え可能なパラメータに関しては書き換えを行うことができる。メモリはSRAM、DRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。また、メモリでなく、SSDやハードディスク等の記憶装置でもよい。基地局では、非基地局としての他の端末のこれらの情報も、当該端末からの通知により、取得することができる。その場合、MAC/PHY管理部60は、他の端末に関する情報を参照・書き換えが可能になっている。あるいはこれらの他の端末に関する情報を記憶するためのメモリは、MIBとは別に保持・管理するようにしてもよい。その場合、MAC/PHY管理部60あるいはMAC共通処理部20が、その別のメモリを参照・書き換えが可能なようにする。また基地局のMAC/PHY管理部60は、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への対応可否、UL-MU能力のオン/オフの情報など)の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部30が、MAC/PHY管理部60からMAC共通処理部20を介して受けた指示に基づいて生成する。
管理フレームに関連して、送信処理部30は、他の端末に管理フレームを介して各種情報を通知する通知手段を有する。この管理フレームとしては、例えば端末が基地局との間で認証を行う手順の一つであるアソシエーションプロセスで用いられるAssociation Requestフレームや、あるいはリアエソシエーションプロセスで用いられるReassociation Requestフレームがある。基地局は、非基地局の端末に、UL-MUへの対応可否およびUL-MU能力のオン/オフの情報等を、管理フレームを介して通知してもよい。これに用いる管理フレームとしては、例えばBeaconフレームや、非基地局端末が送信したProbe Requestフレームに対する応答であるProbe Responseフレームがある。基地局は、自装置に接続している端末群をグループ化する機能を有していてもよい。基地局の上記の通知手段は、各端末にそれぞれが属するグループのグループ識別子であるグループIDを、管理フレームを介して通知してもよい。この管理フレームとしては、例えばGroup ID Managementフレームがある。グループIDは、例えばIEEE Std 802.11ac-2013でダウンリンクMU-MIMO(Multi-User Multi-Input Multi-Output)(DL-MU-MIMO)のために規定されたグループID(6ビット)をUL-MUの場合も包含するように拡張したものでもよいし、これとは別の方法で定義したグループIDでもよい。
ここでアソシエーションID(AID)について説明する。AIDは、端末が基地局に接続し、基地局下のBSSでデータフレーム交換が行えるようにするためのアソシエーションプロセスで、基地局から割り当てられる端末の識別子(端末識別子)である。アソシエーションプロセスは具体的には、端末から基地局宛てにAssociation Requestフレームを送信し、基地局から端末宛てにAssociation Responseフレームを送信し、Association Responseフレームの中の端末Status Codeフィールドが”0”すなわちsuccessである場合に成功するプロセスである。Association Requestフレーム、Association Responseフレームの双方には、送信端末の通信能力(Capability)が入れられており、それにより、受信した双方が相手の通信能力を把握する。Association Responseフレームの中の端末Status Codeフィールドが”0”すなわちsuccessである場合には、同フレーム中のAIDフィールド(16ビット)からAIDを抽出し、当該フレームの送信先端末のAIDとして使われる。すなわち、この時点で、基地局から端末にAIDが割り当てられたことになり、端末としてはAIDが有効の状態となる。当該基地局が端末との間で接続(Association)している状態では、端末のAIDが有効である。一方、基地局から当該端末にDisassociationフレームを送信し、当該端末が受信すると、あるいは当該端末から基地局にDisassociationフレームを送信すると、当該端末のAIDは無効(null)となる。どの基地局ともアソシエーションプロセスを経ていない状態の端末では当然、AIDは無効である。AIDが無効の状態は、AIDが未指定の状態とも言うこともできる。
受信処理部40は、他の端末から管理フレームを介して各種情報を受信する受信手段を有する。一例として、基地局の受信手段は、非基地局としての端末からUL-MUの対応可否またはその能力のオン/オフの情報を受信してもよい。また、当該非基地局としての端末がレガシー端末(IEEE802.11a/b/g/n/ac規格対応端末など)の場合に、対応可能なチャネル幅(利用可能な最大のチャネル幅)の情報を受信してもよい。当該端末の受信手段は、基地局からUL-MU対応可否の情報を受信してもよい。
上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、その他種々の情報を、管理フレームを介して、端末(基地局を含む)間で送受信することが可能である。例えばUL-MU対応端末は、自身がUL-MU送信で使用することを希望するリソースに関する情報を、基地局に通知してもよい。この場合、基地局は当該情報に基づき、UL-MU通信のためのリソースの割り当てを各端末に対して行ってもよい。
データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、当該データがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部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(Block Ack)フレームなどがある。CTSフレームも、RTSフレームの応答として送信するため、送達確認応答を表すフレームであるとも言える。CF-Endフレームも、制御フレームの1つである。CF-Endフレームは、CFP(Contention Free Period)あるいはアクセス権(送信権)獲得後、媒体を占有可能な時間を表すTXOP(Transmission Opportunity;TXOP)の終了をアナウンスするフレーム、つまり、無線媒体へのアクセスを許可するフレームである。これらの制御フレームは送信処理部30で生成される。受信したMACフレームへの応答として送信される制御フレーム(CTSフレームやACKフレーム、BAフレームなど)に関しては、受信処理部40で応答フレーム(制御フレーム)の送信の必要を判断して、フレーム生成に必要な情報(制御フレームの種別、RA(Receiver Address)フィールド等に設定する情報など)を送信指示とともに送信処理部30に出す。送信処理部30は、当該フレーム生成に必要な情報と送信指示に基づき、適切な制御フレームを生成する。
MAC処理部10は、CSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)に基づきMACフレームを送信する場合、無線媒体上でのアクセス権(送信権)を獲得する必要がある。送信処理部30は、受信処理部40からのキャリアセンス情報に基づいて、送信タイミングを計る。送信処理部30は、係る送信タイミングに従って、PHY処理部50に送信指示を与えて、さらにMACフレームを渡す。送信指示に加えて、送信処理部30は、送信に使用される変調方式及び符号化方式を合わせて指示してもよい。これらに加えて、送信処理部30は、送信電力を指示してもよい。MAC処理部10は、アクセス権(送信権)獲得後、媒体を占有可能な時間を表すTXOP(Transmission Opportunity;TXOP)が得られると、QoS(Quality of Service)属性などの制限を伴うものの、他の無線通信装置との間でMACフレームを連続して交換できる。TXOPは、例えば、無線通信装置がCSMA/CAに基づき所定のフレーム(例えばRTSフレーム)を送信し、他の無線通信装置から応答フレーム(例えばCTSフレーム)を正しく受信した場合に、獲得される。この所定のフレームが、当該他の無線通信装置によって受信されると、当該他の無線通信装置は、最小フレーム間隔(Short InterFrame Space;SIFS)後に、上記応答フレームを送信する。また、RTSフレームを用いないでTXOPを獲得する方法として、例えば直接ユニキャストで、送達確認応答フレームの送信を要求するデータフレーム(後述のようにフレームが連接された形状のフレーム、またはペイロードが連接された形状のフレームであってもよい)あるいは管理フレームを送信し、それに対する送達確認応答フレーム(ACKフレームやBlockACKフレーム)を正しく受信する場合がある。あるいは、他の無線通信装置に送達確認応答フレームの送信を要求しないフレームであって、そのフレームのDuration/IDフィールドに当該フレームの送信に要する時間以上の期間を設定したものを送信した場合には、当該フレームを送信した段階からDuration/IDフィールドに記載された期間の使用権を獲得したと解釈してもよい。
受信処理部40は、上述したキャリアセンス情報を管理する。このキャリアセンス情報は、PHY処理部50から入力される媒体(CCA)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、IEEE802.11規格において、媒体予約時間は、MACヘッダの中のDuration/IDフィールドに記載される。MAC処理部10は、他の無線通信装置宛ての(自己宛てでない)MACフレームを受信した場合に、当該MACフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、NAV(Network Allocation Vector)と呼ばれる。媒体予約時間は無線媒体へのアクセスの抑制を指示する期間の長さ、すなわち無線媒体へのアクセスを延期させる期間の長さを表しているといえる。
受信処理部40は、キャリアセンス情報に基づき無線媒体へのアクセスを管理する。MACフレームを送信する場合は、キャリアセンス情報に基づき、バックオフアルゴリズムを利用して、無線媒体の状態を判定し、無線媒体がアイドル状態であれば、アクセス権を獲得し、送信処理部30を用いて、MACフレームを送信する。また、受信処理部40は、アクセスカテゴリ(AC)を利用した優先制御であるEDCA(Enhanced Distributed Channel Access)を実行する。EDCAではACごとに、EDCAパラメータとして、コンテンションウィンドウの最小値CWmin、最大値CWmax、AIFSN(AIFS Number)、およびTXOPリミット(TXOPの上限値)が定義されている。本実施形態では、これらのパラメータを、UL-MU送信の履歴、またはUL-MU送信の能力の有効または無効の設定状態に応じて、変更するよう制御することを特徴の1つとする。UL-MU送信の履歴は、一例として、UL-MU送信の実行有無、UL-MU送信の実行回数、およびUL-MU送信の成功または失敗の実行結果、UL-MU送信(例えば基準となるUL-MU送信、所定の時点で行ったUL-MU送信など)からの経過時間のうちの少なくとも1つを含む。なお、EDCAパラメータの制御は、受信処理部40でなく、MAC/PHY管理部60で行ってもよいし、MAC処理部10内の別の処理回路が行ってもよい。なお、EDCAおよびEDCAパラメータの詳細は後述する。
ここで、データフレームは、複数のMACフレームもしくは複数のMACフレームのペイロード部分を連接するようになっていてもよい。前者はIEEE802.11規格ではA(Aggregate)-MPDU、後者はA(Aggregate)-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(Block Ack)フレームが用いられる。以降の説明および図では、MPDUの表記を用いることがあるが、これは、上述した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)の情報を通知してもよい。サポートレートは、基地局が形成するBSSに参加する端末が対応必須のレートと、オプションのレートとを含んでもよい。プローブ応答フレームは、ビーコンフレームを送信する端末からプローブ要求(Probe Request)フレームを受信すると、それに応答して送信するフレームである。プローブ応答フレームは、基本的にはビーコンフレームと同一の内容を通知するものであるため、プローブ応答フレームを用いても基地局は、プローブ要求フレームを送信した端末に、自局の能力を通知することができる。UL-MU対応端末にこの通知を行うことで、端末が例えば自端末のUL-MU通信の機能を有効にするといった動作を行ってもよい。
なお、端末は自端末の能力について基地局へ通知する情報として、基地局のサポートレートのうち自端末が実行可能なレートの情報を通知してもよい。ただし、サポートレートのうち必須のレートについては、基地局へ接続する端末はその必須のレートを実行する能力を有するものとする。
なお、上記で扱った情報のうち、ある情報を通知することで、別の情報の内容が決まるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとUL-MU対応端末である、という場合を考える。この場合、上記ある情報として、規格あるいは仕様に対応する能力の有を通知し、上記別の情報として、UL-MU対応端末であることの通知を明示的に行わなくてもよい。
図2に、本実施形態に従った無線通信システムを示す。このシステムは、基地局(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システムである。端末1~8には、少なくとも複数のUL-MU対応端末(以下、HE(High Efficiency)端末と呼ぶ場合もある)が含まれ、これ以外のレガシー端末が含まれてもよい。レガシー端末には、QoSに対応しているがUL-MUに対応していないNon-HE端末と、QoSおよびUL-MUのいずれにも対応していないNon-QoS端末がある。レガシー端末とは、具体的には、IEEE802.11a/b/g/n/ac規格対応端末などである。UL-MU対応端末は、基地局100との間で、UL-MU-MIMOまたはUL-OFDMA等のUL-MU通信が可能である。
図3(A)は、MACフレームの基本的なフォーマット例を示す。本実施形態に係るデータフレーム、管理フレームおよび制御フレームは、このようなフレームフォーマットをベースとする。本フレームフォーマットは、MACヘッダ(MAC header)、フレームボディ(Frame body)及びFCSの各フィールドを含む。MACヘッダは、図3(B)に示すように、Frame Control、Duration/ID、Address1、Address2、Address3、 Sequence Control、QoS Control及び HT(High Throughput) controlの各フィールドを含む。
これらのフィールドは必ずしもすべて存在する必要はなく、一部のフィールドが存在しない場合もあり得る。例えばAddress3フィールドが存在しない場合もある。また、QoS ControlおよびHT Controlフィールドの両方または一方が存在しない場合もある。またフレームボディフィールドが存在しない場合もあり得る。また図3には示されていない他のフィールドが存在してもよい。例えば、Address4フィールドがさらに存在してもよい。後述するトリガーフレームの場合、共通情報フィールドおよび端末情報フィールドが、フレームボディフィールドまたはMACヘッダに存在してもよい。
Address1のフィールドには、受信先アドレス(Receiver Address;RA)が、Address2のフィールドには送信元アドレス(Transmitter Address;TA)が入り、Address3のフィールドにはフレームの用途に応じてBSSの識別子であるBSSID(Basic Service Set IDentifier)か、あるいはTAが入る。BSSIDは、全てのBSSIDを対象とするwildcard BSSID(全てのビットが1)の場合もある。
Frame Controlフィールドには、タイプ(Type)、サブタイプ(Subtype)という2つのフィールド等が含まれる。データフレームか、管理フレームか、制御フレームかの大別はTypeフィールドで行われ、大別されたフレームの中での細かい種別はSubtypeフィールドで行われる。例えば制御フレームには、BA(Block Ack)フレーム、BAR(Block Ack Request)フレーム、RTS(Request to Send)フレーム、CTS(Clear to Send)フレームといったフレームが存在するが、これらのフレームの識別はSubtypeフィールドで行われる。後述するトリガーフレームも、タイプおよびサブタイプの組み合わせで区別してもよい。一例としてトリガーフレームは制御フレーム(タイプが“制御”)に分類される。
Duration/IDフィールドは媒体予約時間を記載し、他の端末宛てのMACフレームを受信した場合に、当該MACフレームを含む物理パケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、前述したように、NAV(Network Allocation Vector)と呼ばれる。QoSフィールドは、フレームの優先度を考慮して送信を行うQoS制御を行うために用いられる。HT Controlフィールドは、IEEE802.11nで導入されたフィールドである。HT(High Throughput) Controlフィールドは、QoSデータあるいは管理フレームのときに、オーダーフィールドが1に設定されていると存在するものである。HT ControlフィールドはVHT (Very High Throughput) Controlフィールドにも、HE (High Efficient) Controlフィールドにも拡張可能で、各々IEEE802.11n、IEEE802.11ac、あるいはIEEE802.11axの各種機能に応じた通知をすることができる。
管理フレームでは、固有のElement ID(IDentifier)が割り当てられた情報エレメント(Information element;IE)をFrame Bodyフィールドに設定する。フレームボディフィールドには、管理フレームの種類に応じた固有のフィールドの後に、1つまたは複数の情報エレメントを設定できる。情報エレメントは、図4に示すように、Element IDフィールド、Lengthフィールド、情報(Information)フィールドの各フィールドを有する。情報エレメントは、Element IDで識別される。情報フィールドは、通知する情報の内容を格納し、Lengthフィールドは、情報フィールドの長さ情報を格納する。
FCSフィールドには、受信側でフレームの誤り検出のため用いられるチェックサム符号としてFCS(Frame Check Sequence)情報が設定される。FCS情報の例としては、CRC(Cyclic Redundancy Code)などがある。
(本実施形態の第1の動作例)
図5に、本実施形態に係る基地局(AP)101と、端末(STA)1~端末8との動作シーケンスの第1の例を示す。図では端末1~8のうち、端末1と端末2のみが示されている。端末1~4はHE端末であり、端末5~8は、レガシー端末(Non-HE端末もしくはNon-Qos端末)である場合を想定する。
前提として、基地局と端末1~8の一部または全部との間でCSMA/CAベースで個別に通信(シングルユーザ通信)が行われている。シングルユーザ通信では、例えば基本チャネル幅(例えば20MHz)の1チャネルで、基地局および端末間で個別に通信が行われている。シングルユーザ通信の例として、端末でアップリンク送信用のデータが保持されている場合、CSMA/CAに従って、無線媒体へのアクセス権を獲得する。このため、端末は固定時間であるDIFS/AIFSと、ランダムに決定したバックオフ時間との合計であるキャリアセンス時間(待機時間)の間、キャリアセンスを行い、媒体(CCA)がアイドルであると判断されると、媒体へのアクセス権を獲得する。端末は、送信するデータを含むデータフレーム(より詳細にはデータフレームを含む物理パケット)を送信する。データフレームのRAは基地局のMACアドレス(すなわちBSSID)、TAは、端末のMACアドレスである。基地局がこのデータフレームを正常に受信すると、データフレームの受信完了からSIFS後に、送達確認応答フレームであるACKフレーム(より詳細にはACKフレームを含む物理パケット)を返す。端末はACKフレームを受信することで、データフレームの送信が成功したと判断する。なお、基地局に送信するデータフレームはアグリゲーションフレーム(A-MPDU等)でもよく、基地局が応答する送達確認応答フレームはBAフレームでもよい(以下同様)。
DIFS/AIFSは、DIFSおよびAIFSのいずれか一方の時間を意味する。QoS対応でない場合はDIFSを指し、QoS対応の場合は、送信するデータのアクセスカテゴリ(AC:Access Category)に応じて決まるAIFS(以下、AIFS[AC]と記述する場合がある)を指す。なお、物理パケットの基本的な構成は、データフィールドに格納されるMACフレームに、物理ヘッダを付加したものである。物理ヘッダは、一例として、図6に示すように、IEEE802.11規格で定義されているL-STF(Legacy-Short Training Field)、L-LTF(Legacy-Long TrainingField)、L-SIG(Legacy Signal Field)、を含む。L-STF、L-LTF、L-SIGは、例えば、IEEE802.11aなどのレガシー規格の端末が認識可能なフィールドであり、それぞれ信号検出、周波数補正(伝搬路推定)、伝送速度(伝送レート)などの情報が格納される。ここで述べた以外のフィールド(例えばレガシー規格の端末が認識できず、UL-MU対応端末が認識できるフィールド)が含まれてもよい。例えばIEEE802.11axで検討されているHE-SIG-A(およびHE-SIG-B)、HE-STFおよびHE-LTFなどが入ってもよい。
ここで、上記のバックオフ時間は、0から整数で与えられるコンテンションウィンドウ(Contention Window:CW)からランダムに選択される整数に、スロット時間(例えば9μs)をかけたものである。CWの初期値は、最小値(CWmin)であり、再送するたびにCWの値は、最大値(CWmax)になるまで段階的に増やされる。CWminとCWmaxの両方とも、AIFSと同様、AC(アクセスカテゴリ)ごとの値を持つ。
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)が定められている。各ACの優先度は低い方から順にAC_BK、AC_BE、AC_VI、AC_VOである。4つのACに対して送信バッファ(送信キュー)がそれぞれ設けられ、分類されたデータは、該当する送信バッファに格納される。送信バッファは、メモリでもよいし、SSD、ハードディスク等でもよい。送信バッファがメモリの場合、当該メモリはDRAM、SRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。
各ACには、複数のEDCAパラメータが定められており、このパラメータで送信時の媒体アクセスの優先度の差が決定される。パラメータの例としては、CWmin、CWmax、AIFSN、およびTXOPリミット(Max TXOP)などがある。CWminおよびCWmaxは、CWの最小値および最大値である。AIFSNは、AIFS Numberのことであり、AIFSの時間長に対応する。TXOPリミットは、獲得可能なTXOPの上限値(最大値)を表す。AIFSN、CWminおよびCWmaxは、媒体アクセスの優先度の高いACほど、小さい値に設定される。逆にTXOPリミットは、媒体アクセスの優先度の高いACほど、大きい値に設定される傾向にあるが、但しAC_VIの方がAC_VOよりも基本的に大きい値となる。これはトラヒック種別の特性を考慮したものである。
図7に、アクセスカテゴリごとの複数のEDCAパラメータの値の例を示す。QoS対応でない場合(Non-QoS端末の場合)、便宜上、アクセスカテゴリをLegacy DCF(Distributed Coordination Function)と表記している。DCFとはEDCAと類似するが、QoS制御(ACに基づく優先制御)の概念がないアクセス方式である。Max TXOP(TXOPリミット)の値が0の場合、1フレーム(より詳細には1MSDU)のみ送信可能であることを意味する。図7のEDCAパラメータの値はデフォルト値であり、EDCAパラメータの値は、基地局(BSS)ごとに事前に設定することも可能である。本実施形態では、図示のデフォルトのEDCAパラメータ値または基地局が事前に設定したEDCAパラメータ値を、通常のEDCAパラメータ値と呼ぶ。例えば図示のTXOPリミット値は、通常のTXOPリミット値と呼ぶことがある。
EDCA環境では、端末(HE端末およびQoS端末)では、CSMA/CAに基づくデータ送信のための手順が、送信用のデータを有するACごとに独立して行われる。すなわち、ACごとに、ACの種類に応じたAIFS[AC]と、バックオフ時間とを含む待機時間の間、キャリアセンスを行い、最初に待機時間がゼロになったACが、アクセス権を獲得する。待機時間が同時にゼロになったACが複数存在する場合は、媒体アクセスの優先度の高いACがアクセス権を獲得する。なお、Non-QoS端末では、前述したように、DIFSとバックオフ時間とを含む待機時間、キャリアセンスを行い、待機時間の終わりまでの間、媒体(CCA)がアイドルであると判断されると、媒体へのアクセス権を獲得する。
図5において、基地局がUL-MUのトリガーフレーム51を送信バッファに保持しているとする。トリガーフレーム51では、UL-MU送信用に複数の端末を指定する情報、各端末がUL-MU送信で利用する各種パラメータの情報などを含む。パラメータの情報の例として、UL-MU送信で利用するリソースの情報、送信パケット長の情報、送信電力等の情報がある。また、UL-MU送信で送信するデータのACを指定または推奨する情報でもよい。当該パラメータの情報は端末ごとに個別に指定されるものと、複数の端末に共通に指定されるものがあってもよい。MACヘッダに設定するRAは、一例として、ブロードキャストアドレスまたはマルチキャストアドレスである。TAは、基地局のMACアドレス(BSSID)である。トリガーフレームのフォーマット例は後述する。
また、端末1がAC_VO(アクセスカテゴリがVoice)のデータ、端末2が、AC_BE(アクセスカテゴリがBestEffort)のデータを、それぞれ該当するACの送信バッファに保持している。基地局、端末1および端末2とも、これらの以外のACについては、データを保持していないとする。トリガーフレームに適用するEDCAパラメータは、最も優先的なACであるVO(Voice)のパラメータの値と同じとする。ただし、トリガーフレームは、他のACのパラメータの値と同じものを用いてもよいし、トリガーフレーム用の値を別途、定義することも可能である。
基地局、端末1および端末2は、それぞれACに応じたAIFS[AC]とバックオフ時間との合計である待機時間の間、キャリアセンスを行う。基地局、端末1、端末2のいずれとも、キャリアが検知されることなくAIFS[AC]が経過し、続くバックオフ時間も引き続き、キャリアセンスを行う。バックオフ時間のある時点(t1とする)におけるバックオフカウンタの値の例を図8(A)に示す。時点t1では基地局のバックオフカウンタ(AC_CW)は3、端末1のバックオフカウンタ(EDCA_CW_VO)は4、端末2のバックオフカウンタ(EDCA_CW_BE)は15を指している。したがって、この後、基地局のバックオフカウンタが最も早く0になることが分かる。
キャリアが検知されることなく、基地局のバックオフカウンタが0になると、すなわちバックオフ時間が経過すると、基地局は、無線媒体へのアクセス権を獲得し、トリガーフレーム51を送信する。より詳細には、トリガーフレーム51に物理ヘッダを付加した物理パケットが送信される。トリガーフレーム51は、端末1および端末2(および図示していないその他の端末)で受信される。端末1および端末2は、トリガーフレーム51を運ぶ信号の受信により、キャリアが検知されたと判断し、バックオフ動作を停止する。すなわち、端末1および端末2のバックオフカウンタは停止される。この時点(t2とする)の基地局、端末1および端末2におけるそれぞれのバックオフカウンタの値を、図8(B)に示す。基地局ではカウンタ値が0であり、端末1では1(=4-3)、端末2では12(=15-3)である。
トリガーフレーム51を受信した端末1および端末2は、トリガーフレーム51で自端末が指定されていることを検知すると、該当するAC用の送信バッファからデータを読み出し、データを含むデータフレームを生成する。そして、当該データフレームに物理ヘッダを付加した物理パケット(PPDU)52、53を、トリガーフレーム51の受信完了から予め定めた時間後にUL-MU送信する。トリガーフレームで、複数の端末に共通の物理パケット長(PPDU長)が指定されている場合、端末1および端末2は、当該指定された長さの物理パケットを生成する。生成するパケット長が当該指定された長さに満たない場合は、パディングデータを末尾に付加することで、物理パケット長を調整する。
予め定めた時間は、SIFSでもよいし、これより大きな値でもよい。UL-MUは、例えば、UL-MU-MIMOまたはUL-OFDMAまたはこれらを組み合わせた方式(UL-MU-MIMO&OFDMA)である。どの方式を用いるかは、BSSで事前に決められていてもよいし、トリガーフレームで指定されていてもよい。
物理パケット52、53を受信した基地局は、これらの物理パケットの受信完了から予め定めた時間(SIFS等)後に、送達確認応答フレーム54を送信する。ここでは、送達確認応答フレームとして、端末1および端末2への送達確認をまとめて含むMulti-STA BAフレーム(以下、M-BAフレーム)54を送信する。M-BAフレームのフォーマット例は後述する。なお、送達確認応答の方法は、M-BAフレームの送信以外の方法でもよい。例えば、端末1および端末2に順次、ACKフレーム(またはBAフレーム)をシングルユーザ送信してもよい。または端末1および端末2にACKフレーム(またはBAフレーム)を、DL-MU送信してもよい。DL-MUは、たとえばDL-MU-MIMOまたはDL-OFDMAまたはこれらを組み合わせた方式(DL-MU-MIMO&OFDMA)である。
M-BAフレーム54を受信した端末1および端末2は、M-BAフレーム54に含まれる自端末宛の情報を確認することで、データフレームの送信成功可否を確認する。端末1および端末2は、送信に失敗したと判断した場合は、該当するデータフレームを次回以降の機会で再送することを決定する。ここでは端末1および端末2とも送信に成功した場合を想定する。
M-BAフレーム54の送信後、基地局は、送信したいデータまたはフレームを有さず、端末1および端末2は、依然として、それぞれ先ほど送信したデータと同じAC用の送信バッファに、データを保持しているとする。つまり、端末1および端末2は、トリガーフレーム51の受信前のキャリアセンスでアクセス権の獲得対象としていたデータを、UL-MU送信しており、引き続き同じAC用の送信バッファに、送信用のデータを有している。
このため、端末1および端末2は、M-BAフレームの受信完了から予め定めた時間(SIFS等)後に、キャリアセンスを開始する。具体的に、端末1および端末2は、それぞれAIFS[AC]とバックオフ時間との合計である待機時間の間、キャリアセンスを行う。この際、バックオフ時間は、トリガーフレーム51の信号の受信時に停止したときのバックオフカウンタの値(図8(B)参照)が示す時間を用いる。したがって、端末1、端末2のいずれとも、AIFS[AC]が経過した時点でのバックオフカウンタの値は、図8(B)の値となる。したがって、この後、端末1のバックオフカウンタが最も早く0になることが分かる。
端末1で、キャリアが検知されることなく、バックオフカウンタが0になると、すなわちバックオフ時間が経過すると、端末1は、該当するAC用の送信バッファからデータを読み出してデータフレームを生成し、データフレームを含む物理パケット(PPDU)55を送信する。なお、端末は、データフレームの生成の際、該当するACのTXOPリミット値(図7参照)の範囲内でTXOPを決定し、当該長さからパケット長を引いた値を、MACヘッダのDuration/IDフィールドに設定する。1フレームのみの送信(今回の送信のみ)の場合は、所定値(例えば0)を設定すればよい。
物理パケット55は、基地局で受信され、受信完了からSIFS後に、端末1宛に送達確認応答フレームが送信される。図の例では、BAフレーム56が送信されているが、送信したデータフレームがA-MPDUでなければ、ACKフレームの場合もある。端末2は、物理パケット55を運ぶ信号の受信により、キャリアが検知されたと判断し、バックオフ動作を停止する。すなわち、端末2のバックオフカウンタが停止される。この時点(t3とする)の端末1および端末2におけるそれぞれのバックオフカウンタの値を、図8(C)に示す。基地局では送信するフレームが存在しないため、バックオフカウンタは存在せず(図では、このことをNo Frameと表記している)、端末1では0、端末2では11(=12-1)である。
以降も同様にして、シーケンスが継続される。端末2では、次回のキャリアセンス時に、t3時点のバックオフカウンタ値を引き続き用いる。端末1は、さらに送信するデータを有する場合は、該当するACに応じて、新たにCWからランダムに値を選択して、バックオフ時間を算出する。
上述したシーケンスでは、端末1および端末2ともUL-MU送信に成功したが、失敗した場合も同様にして、バックオフカウンタの値を引き継いでもよい。通常、EDCAでは失敗した場合、バックオフカウンタの値は取り直すが、その際バックオフカウンタを選択するCWの値は、失敗する度、最大値(CWmax)になるまで段階的に増やされる。この通常動作を適用するようにしてもよい。また変形例として、UL-MU送信に失敗した場合は、バックオフカウンタの値を引き継ぎ、成功した場合は、新たにバックオフ時間を決定し直してもよい。
上述したシーケンスでは、トリガーフレーム受信前にバックオフ動作の対象となっていたACと、UL-MU送信の対象となったACが同じであったが、両ACが異なる場合もあり得る。例えばトリガーフレームで推奨または指定されていたACと、バックオフ動作の対象となっていたACが異なる場合がある。その場合も、トリガーフレーム受信時に停止したバックオフカウンタ値を、次回のSU送信用のバックオフ動作に使い回してもよい。なお、トリガーフレームでACが指定されている場合は、端末は、当該ACに属するデータを送信し、当該ACに属するデータが送信バッファに存在しない場合は、UL-MU送信しないか、もしくはデータが存在しない旨の通知を含むフレームを送信してもよい。トリガーフレームでACが推奨されている場合は、可能なかぎり、当該ACに属するデータを送信する。例えば、推奨されるACに属するデータが送信バッファに存在する場合は、そのデータを送信し、存在しない場合は、他のACに属するデータを送信してもよい。
トリガーフレーム受信前にバックオフ動作の対象となっていたACが複数であり、そのうちの1つが、UL-MU送信の対象となったACである場合も同様に、トリガーフレーム受信時に停止した各AC用のバックオフカウンタ値を、次のバックオフ動作時に使い回してもよい。
トリガーフレームではUL-MU送信の複数の端末を指定したが、端末の指定を行わず、端末側でランダムに、ランダムアクセスが許可されたリソース群(例えばOFDMAの場合、リソースユニット群)からリソースを選択してUL-MU送信する(ランダムアクセスする)ことを許容するトリガーフレームを用いてもよい。このようなトリガーフレームを、ランダムアクセス用トリガーフレーム:Trigger Frame For Random Access:TF-R)と呼んでもよい。この場合、図9のフローチャートにおいて、トリガーフレームで自端末が指定されたかの判断(図9のS13)を、端末側でランダムアクセスするかの判断に置き換えればよい。そして、ランダムアクセスを行う場合は、図9のステップS14に進むようにすればよい。TF-Rを受信した端末は、ランダムバックオフ手法に類似した方法に基づきリソースを選択する。例えば予めランダムに選択したランダムバックオフカウンタ値から、ランダムアクセスが許可されたリソース数を引き、0以下になると選択権があるとして、リソースの選択を行う。0より大きい場合は、今回のランダムアクセスを見送り、次回のTF-Rの受信時に、減算後のランダムバックオフカウンタ値を利用して、同様にして選択権の有無を判断する。TF-Rおよびランダムアクセスの詳細については後述する。
図9は、本実施形態の第1の動作例に係る端末の動作のフローチャートである。
端末が、バックオフ動作時に基地局からトリガーフレームを受信すると(S11)、バックオフ動作を停止、すなわちバックオフカウンタを停止する(S12)。このときのバックオフカウンタ値はそのまま維持しておく。つまり、このときのバックオフカウンタ値を記憶装置に記憶しておく。端末は、トリガーフレームに基づき、自端末がUL-MU用に指定されているか判断する(S13)。自端末が指定されている場合は(YES)、該当するAC用の送信バッファからデータを読み出し、当該データを含むデータフレームを生成し、当該データフレームを含む物理パケットを、トリガーフレームの受信完了から予め定めた時間後にUL-MU送信する(S14)。前述したように、データを読み出すACは、バックオフ動作の対象となっていたACの場合、これとは異なるACの場合のいずれもあり得るが、ここではACが同じ場合を想定する。
端末は、UL-MU送信後、基地局から送信される送達確認応答フレーム(M-BAフレーム等)を受信し、送達確認応答フレームを検査することで、UL-MU送信が成功したかを判断する(S15)。送信に失敗したデータが存在する場合は、次回以降の送信(UL-MU送信またはSU送信)の機会でそのデータを再送することを決定する。
端末は、トリガーフレームで自端末が指定されていなかった場合(S13のNO)、またはUL-MU送信後もUL送信したいデータが存在する場合(S16のYES)、SU送信用のアクセス権を獲得するため、キャリアセンスを行う。キャリアセンスは、該当するACのEDCAパラメータに応じて、固定時間であるAIFS[AC]と、バックオフ時間との合計である待機時間の間行う。このとき、バックオフ時間は、ステップS12で停止したときのバックオフカウンタ値を用いる(S17)。端末は、キャリアセンスの間、キャリア検知がなければ、無線媒体へのアクセス権を獲得する(S18のYES)。端末は、アクセス権を獲得できた場合は、該当するAC用の送信バッファからデータを読み出してデータフレームを生成し、データフレームを含む物理パケットをSU送信する(S19)。なお、前述したシーケンス例では、端末3、4(HE端末)が、ステップS13において、トリガーフレームで自端末が指定されていなかった端末に相当する。端末5~8(レガシー端末)は、トリガーフレーム51の受信などでバックオフ動作を停止した場合は、その後、SU送信に成功するまで、キャリアセンス時にバックオフ時間として、直前のバックオフカウンタ値の値を使い回し続ければよい。
以上、バックオフ動作時にトリガーフレームが受信された場合にバックオフカウンタを停止し、そのときのカウンタ値を、UL-MU送信後に行うシングルユーザ(SU)送信用のバックオフ動作に流用する。一般的な動作であれば、次回のSU送信時に、新たにCWからランダムに値を選択して、バックオフ時間を算出するが、本実施形態では、トリガーフレームの受信時に停止したバックオフカウンタの値を再利用するため、トリガーフレーム受信までに行ったバックオフ動作を無駄にすることを防止できる。UL-MU送信した端末と、それ以外の端末とで無線媒体の使用のフェアネスの問題は存在するものの、EDCA環境でUL-MU送信を行う場合に、UL-MU送信した端末のバックオフ動作が無駄になることを防止できる。
(本実施形態の第2の動作例)
図10に、本実施形態に係る基地局(AP)101と、端末(STA)1~端末8との動作シーケンスの第2の例を示す。本シーケンスは、端末が、UL-MU送信の履歴に応じて、EDCAパラメータのうちの1つであるTXOPリミットの値を変更するよう制御し、変更した値を用いて、SU送信の際のTXOPを決定することを特徴の1つとする。TXOPリミットの値の制御は、図1のMAC処理部10またはMAC/PHY管理部60のいずれで行ってもよい。
以下の説明では、UL-MU送信の履歴が、予め定めた変更条件が満たす場合に、TXOPリミットの値を減じる例を示す。変更条件は、トリガーフレ-ムで自端末が指定され、かつUL-MU送信に成功した場合に、予め定めた時点から一定時間経過していないこととする。変更条件が満たされる場合は、TXOPリミットの値を減じ、変更条件が満たされない場合は、通常のTXOPリミット値(図7のデフォルト値)を用いる。
なお、図では端末1~8のうち、端末1と端末2と端末3のみが示されている。端末1~4はHE端末であり、端末5~8は、レガシー端末(Non-HE端末もしくはNon-Qos端末)であるとする。
図10において、基地局がUL-MUのトリガーフレーム61を送信バッファに保持している。また、端末1がAC_VO(アクセスカテゴリがVoice)のデータ、端末2と端末3が、それぞれAC_BE(アクセスカテゴリがBestEffort)のデータを、それぞれ該当するACの送信バッファに保持している。端末1~端末3とも、これらの以外のACについては、データは保持していないとする。トリガーフレームに適用するEDCAパラメータの値は、AC_VOのEDCAパラメータの値と同じとする。
基地局と端末1~端末3は、AIFS[AC]とバックオフ時間との合計の間、キャリアセンスを行う。基地局、端末1~端末3のいずれとも、キャリアが検知されることなくAIFS[AC]が経過し、続くバックオフ時間の間も引き続き、キャリアセンスを継続している状態を想定する。
基地局のバックオフカウンタが最初に0になったとする。基地局は、無線媒体へのアクセス権を獲得し、トリガーフレーム61を送信する。より詳細には、トリガーフレーム51に物理ヘッダを付加した物理パケットが送信される。トリガーフレーム61では、端末1~3を指定する情報が指定されており、また端末1~3に対してそれぞれUL-MU用のパラメータ(使用するリソース、パケット長、送信電力など)が指定されている。トリガーフレーム61は、端末1~端末3(および図示していないその他の端末)で受信される。端末1~端末3は、トリガーフレーム61の信号の受信により、キャリアが検知されたと判断し、バックオフ動作を停止(バックオフカウンタを停止)する。停止時のバックオフカウンタの値は記憶しておく。
トリガーフレーム61を受信した端末1~端末3は、トリガーフレーム61を解析することで、自端末が指定されていることを検知する。端末1~端末3は、タイマーに一定時間を設定し、トリガーフレーム61の受信完了時点またはそれより後の時点、例えば固定時間後、あるいは自端末がUL-MU送信完了時点で、当該タイマーを起動させる。ここでは、端末1~端末3は、トリガーフレーム61の受信完了時点でタイマーを起動させたとする。タイマーに設定する一定時間の値は、ここではトリガーフレームの送信周期であるとする。本例では、トリガーフレーム61の送信完了から次のトリガーフレーム(図のトリガーフレーム68)の送信開始までの時間長あるいは次のトリガーフレームの送信を十分に包含するよう余分な値を付加した時間長に相当する。一定時間は、これに限定されず、これより長いまたは短い時間でもよい。例えば次のビーコンフレームの送信までの時間長でもよいし、トリガーフレームの送信周期の整数倍、例えば2倍、などでもよい。タイマーを起動させる時点が、トリガーフレーム61の受信完了より後の場合は、それに応じてタイマーに設定する時間長を調整してもよい。タイマーに設定する値は、事前に決められていても良いし、基地局が決定して、各端末に当該値の情報を通知してもよい。通知には、トリガーフレームを利用してもよいし、これとは別のフレーム(ビーコンフレーム)などを利用してもよい。なお、当該タイマーの最初の起動は自端末がUL-MU送信をするとした時点、あるいはUL-MU送信要求を基地局に管理フレームあるいはQoSデータフレームのヘッダなどを用いて通知した時点でもよい。
端末1~3は、該当するAC用の送信バッファからデータを読み出してデータフレームを生成し、トリガーフレーム61の受信完了から予め定めた固定時間後に、データフレームにそれぞれ物理ヘッダを付加した物理パケット62~64をUL-MU送信する。予め定めた時間は、SIFSでもよいし、これより大きな値または小さな値でもよい。
物理パケット62~64を受信した基地局は、これらのパケットの受信完了から予め定めた時間(SIFS等)後に、送達確認応答フレーム65を送信する。ここでは、送達確認応答フレームとして、端末1~端末3への送達確認をまとめて含むM-BAフレーム65を送信する。本実施形態の第1の動作例の説明で述べたように、送達確認応答の方法は、M-BAフレームの送信以外の方法でもよい。
M-BAフレーム65を受信した端末1~端末3は、M-BAフレーム65に含まれる自端末宛の情報を確認することで、データフレームの送信の成功可否を確認する。ここでは端末1~端末3とも送信に成功した場合を想定する。仮に送信に失敗したと判断した場合は、送信に失敗したデータを再送することを決定する。送信に失敗した端末は、トリガーフレーム61によるタイマーを(再)起動しないようにしてもよいし、そのままタイマーの動作を継続させてもよい。送信に失敗した端末でトリガーフレーム61によるタイマーを起動しないようにするためには、例えばUL-MU送信から固定時間後に送信される送達確認応答フレーム65の有無、また当該送達確認応答フレーム65に少なくとも自端末のUL-MU送信に関する送達確認応答が含まれるかを確認し、それに基づいてタイマーを起動するかを判断する。ここではタイマーを継続させるとする。
この後、基地局は、送信すべきフレームを内部に保持しておらず、一方、端末1~端末3は、依然として、それぞれ物理パケット62~64で送信したデータフレームと同じACの送信バッファに、送信用のデータを保持しているとする。
端末1~端末3は、M-BAフレームの受信完了から予め定めた時間(SIFS等)後に、保持しているデータのSU送信用に、キャリアセンスを開始する。具体的に、端末1~端末3は、それぞれAIFS[AC]とバックオフ時間との合計である待機時間の間、キャリアセンスを行う。この際、バックオフ時間は、前述した第1の動作例と同様に、トリガーフレーム61の受信の際に停止したときのバックオフカウンタ値を用いてもよい。ただし、この動作の一例であり、端末1~端末3で、CWからバックオフ時間を新たに決定しなおしてもよい。
端末1~端末3のうち、端末1が最初にバックオフカウンタが0になったとする。端末1は、該当するACの送信バッファからデータを読み出してデータフレームを生成し、当該データフレームに物理ヘッダを付加した物理パケット(PPDU)66を送信する。データフレームの生成の際、該当するACのTXOPリミット値の範囲内でTXOPを決定し、当該長さからパケット長を引いた値を、MACヘッダのDuration/IDフィールドに設定する。1フレームのみの送信(今回の送信のみ)の場合は、所定値(例えば0)を設定すればよい。この時点では、端末1は、タイマーがタイムアウトしていないため、変更条件が満たされると判断する。したがって、端末1は、当該ACのTXOPリミット値として、通常の値(図7のMax TXOPのデフォルト値)より小さくしたTXOPリミット値(第2TXOPリミット値)を用いて、TXOPを決定する。
一例として、該当するACの変更前のTXOPリミット(第1TXOPリミット)を、Old_Max_TXOP、変更後のTXOPリミット(第2TXOPリミット)を、NEW_Max_TXOPとすると、以下の(式1)に従って変更する。“×”は乗算を表す。αは、0以上1未満の係数である。
NEW_Max_TXOPper AC=α×Old_Max_TXOPper AC (式1)
端末1は、NEW_Max_TXOPper AC以下の範囲で、TXOPを決定し、決定した時間長に応じた値を、物理パケット66で送信するデータフレームのMACヘッダのDuration/IDフィールドに設定する。具体的には、決定したTXOPから、物理パケット66のパケット長(PPDU長)を減じた値を、Duration/IDフィールドに設定する。なお、αが0のとき、第2TXOPリミット値は0となり、これは前述したように1フレームのみ送信可能であることを意味する。
第2TXOPリミットの別の算出例として、第1TXOPリミット値から、UL-MUで送信した物理パケット62のパケット長(PPDU長)を減算してもよい。または、第1TXOPリミット値から、当該物理パケット長に依存した値(例えばパケット長が長いほど大きく、短いほど小さくなる値)を減算してもよい。
物理パケット66を受信した基地局は、受信完了から予め定めた時間(SIFS等)後に、送達確認応答フレーム67(より詳細には送達確認応答フレーム67に物理ヘッダを付加した物理パケット)を送信する。ここでは、物理パケット66でデータフレームとしてアグリゲーションフレームが運ばれ、送達確認応答フレームとしてBAフレームが送信される。
BAフレーム67を受信した端末1は、TXOP内であれば、引き続き、該当するAC用の送信バッファからデータを読み出してデータフレームを生成し、当該データフレームを含む物理パケットを送信してもよい。この際、データフレームのMACヘッダのDuration/IDフィールドには、TXOPの残り時間に応じた値を設定する。例えばBAフレーム67のMACヘッダのDuration/IDフィールドに設定されている値から、SIFSと、今回送信する物理パケットのパケット長を引いた値を設定してもよい。または、物理パケット66でDuration/IDフィールドに設定した値から、物理パケット66の送信完了時点から今回物理パケットの送信開始までの時間長と、今回送信する物理パケットのパケット長とを引いた値を設定してもよい。
以降、端末1は、TXOP内であれば、データフレームを含む物理パケットの送信と送達確認応答フレームの受信を、SIFS間隔で繰り返し行うことができる。
端末1は、TXOP終了後、トリガーフレーム68の受信前でかつタイマーがまだタイムアウトしていない状態で、さらに当該ACに属するデータの送信用に、キャリアセンスを行い、キャリアセンス結果がアイドルとして、アクセス権を獲得したとする。このとき使用するTXOPリミット値は、上述の第2TXOPリミットを引き続き用いてもよい。または第2TXOPリミット値を、α×Old_Max_TXOPper ACとみなして、式1に適用して、さらに小さくした値を算出してもよい。この際、αは固定でもよいし、TXOPリミットを更新するごとに、αの値を小さくまたは大きくしてもよい。
端末1は、タイマーがタイムアウトした場合は、変更条件が満たされないと判断して、TXOPリミットの値を、第1TXOPリミット値(通常のTXOPリミット値)に戻す。トリガーフレーム68で再度自端末が指定された場合は、再び当該タイマーを起動し、変更条件が満たされたとして、当該タイマーが起動中(タイムアウトする前)にSU送信のアクセス権を獲得した場合には当該SU送信で用いるTXOPリミット値を小さくする。トリガーフレーム61により起動した当該タイマーがタイムアウトする前に再びトリガーフレーム68で再度自端末が指定された場合は、当該タイマーをリセットし(タイムアウト時間を初期値に戻し)起動する。
上述したシーケンスでは、SU送信用のキャリアセンスで、端末1がアクセス権を獲得できた場合の動作を例に説明したが、端末2または端末3がアクセス権を獲得した場合も同様の動作が行われる。
端末4では、トリガーフレーム61で指定されていないため、SU送信用のデータフレーム生成時に、第1TXOPリミット値(通常のTXOPリミット値)を用いてTXOPを決定する。端末5~8(レガシー端末)も同様に、SU送信用のデータフレーム生成時に、第1TXOPリミット値(通常のTXOPリミット値)を用いてTXOPを決定する。本実施形態ではレガシー端末は、通常のTXOPリミット値を用いる。
図11(A)に、第1TXOPリミット値内でTXOPを決定して、TXOP内でデータフレームを含む物理パケットの送信と送達確認応答フレーム(BAフレーム)の受信とを繰り返し行うシーケンス例を示す。図11(B)に、第1TXOPリミット値より低い第2TXOPリミット値内でTXOPを決定し、TXOP内でデータフレームを含む物理パケットの送信と送達確認応答フレーム(BAフレーム)の受信とを繰り返し行うシーケンス例を示す。図11(A)および図11(B)で破線の矩形は、基地局から受信するフレーム(ここではBAフレーム)であることを示す。
図11(A)の方が、長いTXOPを設定できるため、より多くのデータをSU送信できる。よって、トリガーフレームで指定されかつUL-MU送信に成功した端末(第2TXOPリミット値が適用される端末)と、それ以外の端末(第1TXOPリミット値が適用される端末)とで、無線媒体の使用に関してフェアネスの維持が可能となる。またUL-MU送信に成功した端末のSU送信はTXOPリミットが制限されているため、無線媒体の占有期間が少なくなり、基地局がトリガーフレームを送信可能な期間を確保しやすくなる。
上述したシーケンスでは、トリガーフレームで指定された端末は、UL-MU送信に失敗した場合も、タイマーの動作を維持して、タイマーがタイムアウトする前までは、第2TXOPリミット値を用いるようにした。UL-MU送信に失敗したものの、送信の機会を与えられたという点では、その他の端末に比べて優位であったといえるためである。別の方法として、トリガーフレームで指定された端末であっても、UL-MU送信に失敗した場合は、当該トリガーフレームによるタイマーの(再)起動をしないようにしてもよい。この場合は、送信が成功しなかったという点を重視した対応といえる。
上述したシーケンスでは、第1TXOPリミット値に基づき式1を計算して、第2TXOPリミット値を算出したが、予め第2TXOPリミット値をデータベースに格納しておいてもよい。この場合、端末は、当該データベースから、第2TXOPリミット値を読み出せばよい。第1TXOPリミットより段階的に小さくしたTXOPリミットの値を複数(第2TXOPリミット~第mTXOPリミット。mは3以上の整数)データベースに格納してもよい。この場合、タイマーがタイムアウトする前まで期間において、キャリアセンスでSU送信用のアクセス権を獲得するごとに、段階的に低い値のTXOPリミット値を用いるようにしてもよい。
上述したシーケンスでは、EDCAパラメータのうち、TXOPリミットのみを小さく変更したが、他のEDCAパラメータをTXOPリミットと共に変更してもよい。一例として、CWmin、CWmaxまたはこれらの両方を、大きくなるよう変更してもよい。または、AIFSNを、大きくなるよう変更してもよい。変更の方法は、TXOPリミットと同様の方法を用いればよい。例えば、一定の係数を乗じてもよいし、または、データベースに予め、候補となる1つ、または段階的に大きくした複数の値を格納しておく方法でもよい。AIFSNやCWmin、CWmaxを変更する場合、これらの値は次のSU送信のために予め用いられるものであるため、すでにバックオフカウンタのカウントダウンが開始されている状態でタイマーがタイムアウトした場合の挙動を考える必要がある。すでにバックオフカウンタのカウントダウンが開始されている状態でタイマーがタイムアウトした場合は、例えばそのままカウントダウンを継続してアクセス権の獲得を試み、新たにバックオフカウンタを取り直す際に変更されたAIFSNやCWmin、CWmax値を適用する。前述のTXOPリミットに関しても同様のタイミングで適用するようにしてもよい。あるいは、CWmin、CWmaxに関してはすでにカウントダウンされている現状値と新たに用いるパラメータから導出されたバックオフカウンタ初期値を比較し、新たに導出された初期値の方が小さければ現状のカウントダウン値を当該初期値で置き換えるようにしてもよい。
図12は、本実施形態の第2の動作例に係る端末の動作のフローチャートである。
端末が、基地局からトリガーフレームを受信すると(S101)、トリガーフレームに基づき、自端末がUL-MU用に指定されているか判断する(S102)。自端末が指定されている場合は、トリガーフレームの受信完了から予め定めた時間後に、データフレームを含む物理パケットをUL-MU送信する(S103)。端末は、UL-MU送信後、基地局から送信される送達確認応答フレーム(M-BAフレーム等)を受信し、送達確認応答フレームを検査することで、UL-MU送信が成功したかを判断する(S104)。送信に失敗したデータが存在する場合は、次回以降の送信(UL-MU送信またはSU送信)の機会で再送信することを決定する。
端末は、UL-MU送信後もUL送信したいデータが存在する場合、SU送信用のアクセス権を獲得するため、AIFS[AC]とランダムに決定したバックオフ時間との合計である待機時間の間、キャリアセンスを行う。端末は、キャリアセンスの間、キャリア検知がなければ、無線媒体へのアクセス権を獲得する。端末は、アクセス権を獲得できた場合は、該当するACの送信バッファからデータを読み出してデータフレームを生成する。この際、使用するTXOPリミット値を決定し、当該TXOPリミット値以下の範囲内でTXOPを決定する。具体的に、変更条件が満たされるかを判断し(S106)、変更条件が満たされない場合は、第1TXOPリミット値を用いることを決定し、第1TXOPリミット値以下の範囲で、TXOPを決定する(S109)。一方、変更条件が満たされる場合は、第1TXOPリミット値より小さい第2TXOPリミット値以下の範囲で、TXOPを決定する(S107)。一例として、第1TXOPリミット値は、予めシステムで定められたデフォルト値(図7参照)、または基地局がBSS内で事前に設定した値である。
端末は、決定したTXOPに応じた値を、送信するデータフレームのMACヘッダのDuration/IDフィールドに設定する。そして、データフレームを含む物理パケットをSU送信する(S108)。この後、次のトリガーフレームを受信しておらず(S110のNO)、かつ送信したいデータが存在する場合は、ステップS105に戻る。前述したように、SU用のアクセス権を獲得するごとに、TXOPリミット値をさらに段階的に下げていってもよい。基地局から、次のトリガーフレームを受信した場合は(S110のYES)、ステップS102に戻る。
ここで、変更条件の例を詳細に説明する。前述した第2のシーケンス例のように、第1の変更条件としては、トリガーフレームで自端末が指定されかつUL-MU送信に成功した場合に、トリガーフレームの受信完了(または送信開始)から一定時間内に含まれるか否かがある。一定時間に含まれる場合は、変更条件が満たされ、含まれない場合は、変更条件が満たされない。一定時間の長さは、例えばトリガーフレームが一定周期で送信される場合に、当該一定周期の長さでもよい。あるいは、これより短くしても長くしてもよい。
具体的な実装例としては、前述したように、トリガーフレームの受信完了時に、当該一定時間の長さ(例えばトリガーフレームの周期長)を設定したタイマーを起動し、タイマーがタイムアウトしない間は、変更条件が満たされると判断する。タイマーが起動していないまたはタイムアウトした場合は、変更条件が満たされないと判断する。この場合、少なくとも次のトリガーフレームの受信までは、変更条件は満たされないと判断され続ける。
タイマーを動作させる起点は、トリガーフレームの受信完了時点に限定されない。トリガーフレームの受信完了より後、例えばM-BAフレームの受信で自装置の送信が成功したことを確認した時点で、タイマーを設定してもよい。この場合、タイマーに設定する値は、次のトリガーフレームの受信までの残り時間などでもよい。どの時点でタイマーを設定するかに応じて、タイマーに設定する値は、適宜調整すればよい。
ここでタイマーに設定する値(以下、タイマー設定値)を決定する例を示す。タイマー設定値は、端末で決定する方法と、基地局で決定する方法がある。
端末でタイマー設定値を決定する場合、例えばトリガーフレームの送信周期を観測し、トリガーフレームの送信周期の整数倍にタイマー設定値を決定する。送信周期の整数倍から、トリガーフレームのパケット長(PPDU長)を引いた値を、タイマー設定値に決定してもよい。端末が持っているトラヒック(送信バッファのデータ量等)に応じて、送信周期に乗じる整数を決定してもよい。例えばAC_VOの送信バッファに蓄積されているデータ量が多いほど、整数の値を小さく、あるいは、当該データ量が少ないほど、整数の値を大きくしてもよい。あるいは、これとは逆の関係に設定してもよい。
または、基地局がトリガーフレームの送信周期を予めBSS内の複数の端末に通知し、各端末が、当該自端末のトラヒック(データ量)と、通知された送信周期とから、タイマー設定値を決めてもよい。例えば送信周期に応じた閾値を設定し、トラヒックが閾値以下であれば、タイマー設定値を大きな値、閾値より大きければ、タイマー設定値を小さな値に設定する。あるいは、これとは逆の関係に設定してもよい。送信周期が長いほど、閾値を大きな値に設定してもよい。
基地局でタイマー設定値を決定する場合、例えば、当該基地局がBSSに属する端末からバッファステータスレポート(Buffer Status Report:BSR)を受信し、BSRを用いて、タイマー設定値を決定する。BSRは、例えばACごとのトラフィックの情報を含む。BSRは、QoS ControlフィールドまたはHE Controlフィールドに入れられてもよいし、管理フレームの情報エレメントとして送信されてもよい。BSRは、端末によって自発的に送信されてもよいし、基地局から端末にBSRの送信要求を送り、当該要求に応じて端末がBSRを送信してもよい。当該送信要求がトリガーフレームに含まれていても良い。
基地局は、端末ごとにタイマー設定値を決定してもよい。例えば、端末が持っているトラヒックが多いほど、タイマー設定値を小さく、あるいは、少ないほどタイマー設定値を大きくする。あるいは、これとは逆の関係に設定してもよい。また、基地局は、複数の端末に共通にタイマー設定値を決定してもよい。この場合は、複数の端末のトラヒック(データ量)を、統計処理(例えば平均)して、タイマー設定値を決めればよい。タイマー設定値はACごとに決定してもよい。基地局は、端末ごと、または端末に共通に決定したタイマー設定値を、各端末に通知する。通知には、トリガーフレームを利用してもよいし、ビーコンフレーム等の管理フレームを利用してもよいし、その他のフレームを利用してもよい。
変更条件の第2の例としては、トリガーフレームで自端末が指定されかつUL-MU送信に成功した場合に、その後、所定のフレームを受信したかがある。所定のフレームとして、ビーコンフレームでもよい。ビーコンフレームを受信する前までは、変更条件が満たされると判断し、ビーコンフレームを受信した場合は、変更条件が満たさなくなったと判断する。この後、次のトリガーフレームで自端末が指定されかつUL-MU送信に成功した場合に、再度、変更条件が満たされると判断される。トリガーフレームの周期は、ビーコンフレームの周期より短いことを想定するが、長くてもよい。ここでは所定のフレームとしてビーコンフレームの場合を記述したが、別のフレームでもよい。所定のフレームを受信するタイミングが事前に分かっている場合は、前述したタイマーを利用した方法でも同様の動作を実現可能である。受信したフレームの種別は、例えばMACヘッダのフレームコントロールフィールドのタイプおよびサブタイプを解析することで判断してもよい。
変更条件の第3の例として、トリガーフレームの受信回数と、トリガーフレームに応答してフレームの送信(UL-MU送信)に成功した回数に基づいて、変更条件の成否を判断してもよい。例えば、トリガーフレームの受信回数に対するフレーム送信の成功回数の比が、閾値以上の場合に変更条件が満たされ、当該比が閾値未満の場合、変更条件が満たされないと判断してもよい。一例として、変更条件が満たされる場合は、第2TXOPリミット値、満たされない場合は第1TXOPリミット値を用いる。このように、トリガーフレームの受信回数とフレーム送信の成功回数に基づいて、使用するTXOPリミット値を制御する。
変更条件の第4の例として、トリガーフレームに応答してフレームの送信(UL-MU送信)に成功した回数と、シングルユーザ送信でフレームの送信に成功した回数とに基づいて、変更条件の成否を判断してもよい。例えばシングルユーザ送信の成功回数に対するUL-MU送信の成功回数の比が閾値以上の場合に変更条件が満たされ、当該比が閾値未満の場合、変更条件が満たされないと判断してもよい。一例として、変更条件が満たされる場合は、第2TXOPリミット値、満たされない場合は第1TXOPリミット値を用いる。このように、シングルユーザ送信の成功回数とUL-MU送信の成功回数に基づいて、使用するTXOPリミット値を制御する。つまり、この場合、UL-MU送信の履歴に加えて、SU送信の履歴を用いて、TXOPリミットの値を変更するよう制御する。SU送信の履歴は、SU送信の実行有無、SU送信の実行回数、およびSU送信の成功または失敗の実行結果、SU送信(例えば基準となるSU送信、所定の時点で行ったSU送信など)からの経過時間のうちの少なくとも1つを含む。
上述した変更条件の第3および第4の例において、トリガーフレームに応答してフレームの送信(UL-MU送信)に成功した回数の代わりに、トリガーフレームに応答してフレームを送信した回数(自装置が指定された回数)を用いてもよい。
上述した第1の変更条件の例では、タイマーがタイムアウトするまでは変更条件が満たされるとして第2TXOPリミット値が用いたが、経過時間に応じて、第2TXOPリミット値を段階的に変更してもよい。例えばタイムアウトが近づくほど、第2TXOPリミット値が、第1TXOPリミット値に近づくように大きくしてもよい。
また、上述した第3の変更条件の例では、トリガーフレームの受信回数に対するフレーム送信の成功回数の比が閾値以上の場合に、変更条件が満たされるとして、第2TXOPリミット値を用いた。別の方法として、当該比が大きくなるほど、第1TXOPリミット値との差が大きくなるように、TXOPリミット値を変更(TXOPリミット値を小さく)してもよい。あるいは、当該比が小さくなるほど、第1TXOPリミット値との差が小さくなるように、TXOPリミット値を制御(TXOPリミット値を大きく)してもよい。
また、第4の変更条件の例では、シングルユーザ送信の成功回数に対するUL-MU送信の成功回数の比が閾値以上の場合に、変更条件が満たされるとして、第2TXOPリミット値を用いた。別の方法として、当該比が大きくなるほど、第1TXOPリミット値との差が大きくなるように、TXOPリミット値を変更(TXOPリミット値を小さく)してもよい。あるいは、当該比が小さくなるほど、第1TXOPリミット値との差が小さくなるように、TXOPリミット値を制御(TXOPリミット値を大きく)してもよい。
上述した第2の動作例では端末側の動作によりTXOPリミット値の変更を行ったが、基地局側で、各端末のUL-MU送信の履歴に基づき、各端末で使用するTXOPリミット値を決定し、決定したTXOPリミット値を、各端末に通知してもよい。通知には、トリガーフレーム、またはビーコンフレーム等のその他のフレームを用いることができる。基地局で各端末が使用するTXOPリミット値を決定する方法は、上述した端末が決定する場合と同様のアルゴリズムを用いればよい。複数の端末のうち少なくとも1つの端末のみ基地局が、使用するTXOPリミット値を決定し、残りの端末は自端末で、使用するTXOPリミット値を決定することも可能である。この場合、基地局は、当該少なくとも1つの端末のみ、通知を行えばよい。
上述した第1~第4の変更条件のうち使用する変更条件は、予め端末に記憶されていてもよいし、基地局が、当該変更条件を特定する情報を、各端末に通知してもよい。通知には、一例として、トリガーフレーム、またはビーコンフレーム等の他のフレームを用いることができる。
以上のように第2の動作例では、UL-MU送信したデータと同一のACに属するデータについて、TXOPリミット値を小さく変更したが、他のACについても、TXOPリミット値を変更してもよい。ただし、TXOPリミット値の下限値は0であるとし、TXOPリミットのデフォルト値が0である場合は、これ以上小さくしない。小さくしてもよいが、この場合は、TXOPリミット値が0であるとみなして、TXOPを決定するものとする。
例えば、図12のステップS103でUL-MU送信したデータが属するAC(仮にAC-1と記載)と、その後のステップS108のSUで送信しようとするデータが属するAC(仮にAC-2と記載)が異なる場合を考える。この場合も、図12の動作フローに従って、AC-2に属するデータのSU送信用に、ステップS107でTXOPリミット値の変更を行ってもよい。あるいは、AC-1とAC-2が異なる場合、図12の動作フローの適用外とし、TXOPリミット値の変更を行わない(通常のTXOPリミット値を使う)ようにしてもよい。
また、上述した第2の動作例では、UL-MU送信するデータのACを端末側で決定する場合を想定したが、第1の動作例と同様に、基地局がトリガーフレームでACを推奨または指定してもよい。トリガーフレームでACが推奨または指定されたいた場合の動作は、第1の動作例と同様でよい。
また、上述し第2の動作例において、第1の動作例と同様に、基地局は、トリガーフレームとして、ランダムアクセス用トリガーフレーム(TF-R)を送信してもよい。この場合、図12のフローチャートにおいて、トリガーフレームで自端末が指定されたかの判断(図12のS102)を、端末側でランダムアクセスするかの判断に置き換えればよい。そして、ランダムアクセスを行うことを決定した場合は、図12のステップS103に進むようにすればよい。
なお、上述した第2の動作例において、決定したTXOPから送信パケット長を引いた値を、MACヘッダのDuration/IDフィールドに無線媒体の予約時間として設定したが、物理ヘッダに同様のフィールドが存在する場合は、物理ヘッダに当該予約時間を設定してもよい。また、決定したTXOPの値を格納するフィールドが物理ヘッダまたはMACヘッダ内に存在する場合は、当該TXOPの値を当該フィールドに格納してもよい。
(本実施形態の第3の動作例)
端末で、UL-MU能力の有効(Able)および無効(Disable)を切り替え可能である場合を想定する。端末は、UL-MU能力の有効または無効の設定状態に応じて、TXOPリミット値を変更してもよい。例えば端末内部でアンテナを共用する他システム(LTE(Long Term Evolution)、Bluetooth(登録商標)など)が存在する場合を考える。無線LAN回路と、他システムとの間で電波干渉問題がある場合、端末内でUL-MU能力を無効にして、この干渉問題を緩和することが考えられる。UL-MUが可能な環境では、基地局からのトリガーフレームに応じてUL-MU送信する場合に、トリガーフレームで指定された条件で送信を行う必要がある(例えば基地局が指定した送信電力で送信する必要がある)ため、このことが他システムとの干渉を引き起こす可能性がある。そこで、端末はUL-MU能力を無効にして、SUモードに移行することが考えられる。
端末は、UL-MU能力が無効のときは、図7に示す通常のTXOPリミット値(第1TXOPリミット値)を用いる。UL-MU能力が有効のときは、優先度を低めた(値を小さくした)TXOPリミット値を用いる。TXOPリミット値の変更は、TXOPリミットのデフォルト値が0より大きいAC-VOとAC-VIのみを対象としてもよい。この変更後のTXOPリミット値は、予め定められていてもよいし、基地局が決定して、端末に通知してもよい。基地局からの通知は、ビーコンフレームやアソシエーション応答フレーム等の管理フレームを用いてもよいし、他の種類のフレームを用いてもよい。また前述の他の動作例、例えばタイマーに基づく動作とUL-MU能力の有効・無効設定を連動させるようにしてもよい。タイマーが起動しており、変更条件が満たされるとしている場合にはUL-MU能力を有効と設定、タイマーが起動しておらず(タイムアウトした場合も含む)、変更条件が満たされないとする場合にはUL-MU能力を無効と設定するというような連動である。
ここでは、EDCAパラメータとしてTXOPリミットを対象に述べたが、CWmin、CWmaxまたはAIFSNなど、他のEDCAパラメータの値を、同様にして制御してもよい。例えば、UL-MU能力が無効のときは、図7に示す通常のパラメータ値を用い、UL-MU能力が有効のときは、優先度を低めた(値を大きくした)パラメータ値を用いる。あるいは、UL-MU能力が無効のときは、図7に示す通常のパラメータ値よりも低いパラメータ値を用い、UL-MU能力が有効のときは、図7に示す通常のパラメータ値を用いてもよい。ここで述べた以外の方法を用いてもよい。TXOPリミット、CWmin、CWmaxまたはAIFSNの任意の組み合わせの値を、同様にして制御してもよい。
端末は、UL-MU能力の有効または無効を表す情報を、基地局に通知する。通知は、例えばHE Controlフィールドに無効フィールドを設け、当該フィールドにビットを立てることで、行ってもよい。あるいは、通知は、既存のフィールドの予約領域を使って行ってもよいし、任意の管理フレームで情報エレメントとして有効または無効の情報を通知する方法でもよい。無効の通知を受けた基地局は、当該端末は、UL-MU送信を実行できない端末として認識し、UL-MUのスケジューリングの対象から除外するなどの処理を行う。
図13は、本実施形態の第3の動作例に係る端末の動作のフローチャートである。端末は、任意のタイミングで、UL-MU能力の有効または無効を決定する(S121)。例えば、端末内でアンテナを共用する他システムとの干渉を測定し、測定値が一定値以上であれば、無効を決定する。または、予め定めた他システムが動作中の場合は、常に無効を決定するなど、別の判断方法を用いてもよい。端末は、有効または無効を決定した場合は、有効または無効を表す情報を、基地局に通知する(S122)。端末は、UL-MU能力の無効を決定した場合は、SUモードに移行し、TXOPリミット値として、通常のTXOPリミット値(第1TXOPリミット値)を用いることを決定する。一方、UL-MU能力が有効の場合は、第1TXOPリミット値より低い第2TXOPリミット値を用いることを決定する(S124)。
上述した説明では、端末側でTXOPリミット値の変更を制御したが、端末のUL-MU能力の有効または無効の設定状態に基づき、基地局側で、当該端末が使用するTXOPリミット値を決定してもよい。この場合、基地局は、決定したTXOPリミット値を端末に通知する。複数の端末のうち少なくとも1つの端末のみ基地局で、当該端末が使用するTXOPリミット値を決定し、残りの端末は自端末で、使用するTXOPリミット値を決定することも可能である。この場合、基地局は、当該少なくとも1つの端末のみ、通知を行えばよい。
(本実施形態の第4の動作例)
基地局によるトリガーフレームの送信について説明する。以下の説明は、トリガーフレームがTF-Rの場合も適用可能である。
基地局は、一例として、トリガーフレームを周期的に送信する。基地局は、トリガーフレームの送信前にキャリアセンスを行う。前述したように、固定時間(AIFS等)とランダムに決めたバックオフ時間との間、キャリアセンスを行い、キャリアが検知されなければ、アクセス権を獲得し、トリガーフレームを送信する。この場合のトリガーフレームの送信シーケンス例を図14(A)に示す。トリガーフレーム51A、51B、51Cを所定の周期で送信している。送信前に、AIFSとバックオフ時間との間、キャリアセンスを行っている。
または、キャリアセンスの別の方法として、ビーコンフレームと同様に送信前にPIFSの間キャリアセンスを行い、キャリアが検知されなければ、アクセス権を獲得し、トリガーフレームを送信してもよい。この場合のトリガーフレームの送信シーケンスの例を図14(B)に示す。送信前に、PIFSの間、キャリアセンスを行っている。これは、ビーコンフレームの送信の場合と同様の動作である。これにより、トリガーフレームを、管理フレームであるビーコンフレームのように送信できる。なお、PIFSの代わりに、別の固定時間を用いてもよい。
基地局は、キャリアセンスでキャリアが検知された場合(ビジーの場合)、アクセス権を獲得できず、送信周期のタイミングでトリガーフレームを送信できない。この場合、基地局は、再度キャリアセンスを行い、アイドル状態を示すキャリアセンス結果が得られるまで、キャリアセンスを繰り返し行ってもよい。これにより、トリガーフレームの送信タイミングが遅れることとなる。この場合のシーケンス例を図15(A)に示す。トリガーフレーム51Aの送信が、送信周期のタイミングより遅れて送信されている。この動作は、ビーコンフレームの送信のためのキャリアセンスでビジーとなった場合と同様である。つまり、ビーコンフレームの送信では、キャリアセンスビジーとしてアクセス権を獲得できなかったときは、獲得できるまで、キャリアセンスを繰り返す。
基地局は、繰り返しキャリアセンスを行う間に、一定の条件が満たされた場合は、トリガーフレームの送信を中止(断念)し、次回の送信タイミングまで待ってもよい。一定の条件として、例えば次の送信タイミングまでの残り時間が一定値以下になった場合は、今回のトリガーフレームの送信を中止することを決定してもよい。または、送信周期のタイミングから閾値時間を越えた場合は、今回のトリガーフレームの送信を中止することを決定してもよい。閾値時間は、送信周期の長さに応じて決定してもよい。例えば、閾値時間は、送信周期の長さの2分の1でもよい。この場合のシーケンス例を図15(B)に示す。キャリアセンスのビジーが続いたため、トリガーフレーム51Aの送信が、送信周期のタイミングから、送信周期長の2分の1経過しても送信できない。このため、トリガーフレーム51Aの送信を中止する。
トリガーフレームの送信周期は、固定でもよいし、変更可能でもよい。送信周期を変更する場合も、キャリアセンスの方法は、上述と同様でよい。送信周期が変更可能な場合、例えば、基地局は、BSSに属する端末からバッファステータスレポート(BSR)を受信する。BSRは、例えばACごとに、トラヒック(送信バッファに存在するデータ量等)の情報を含む。BSRは、QoS ControlフィールドまたはHE Controlフィールドに入れられてもよいし、管理フレームで情報エレメントとして送信されてもよい。BSRは、端末が自発的に送信してもよいし、基地局からBSRの送信要求を送り、当該要求に応じて端末が送信してもよい。当該要求がトリガーフレームに含まれていても良い。
基地局は、複数の端末から受信したBSRに基づき、トリガーフレームの送信周期を決定してもよい。例えば端末数と、各端末の保有するデータ量とに応じて、送信周期を決定する。具体的に、一定量以上のデータを有する端末が多いほど、送信周期を短くまたは長くしてもよい。また、端末数が一定数以上で、各端末のデータ量が多いほど、送信周期を短くまたは長くしてもよい。この判断は、特定のACのデータ量を対象に行ってもよいし、すべてのACをまとめたデータ量について行ってもよい。
前述したように、基地局は、トリガーフレームで、UL-MU送信を行うACを推奨または指定してもよい。この場合、推奨または指定するACは、すべての端末で共通のACでもよいし、端末ごとに個別に推奨または指定したACでもよい。共通に推奨または指定する場合、基地局は、当該ACのTXOPリミット値内でTXOPを決定し、トリガーフレームのMACヘッダ内のDuration/IDフィールドに、NAVの期間(TXOP値からトリガーフレームのパケット長を引いた値)を設定してもよい。これにより、基地局は、BSS内にNAVを設定し、UL-MUの実施中に隠れ端末等による送信を防止することができる。
トリガーフレームの送信、UL-MU送信、およびM-BAフレームの送信を、継続して繰り返すバースト送信が行われてもよい。バースト送信の例を図16に示す。最初にキャリアセンスにより無線媒体がアイドルとして獲得したアクセス権によりトリガーフレーム61を送信して、複数の端末からのUL-MU送信、および基地局からのM-BAフレーム送信が行われる。この後、基地局は、キャリアセンスで無線媒体の検査を行うことなく、PIFS後に、トリガーフレーム69を送信する。以降、同様のシーケンスが繰り返される。このようなバースト送信では、基地局は、バースト送信の起点となるトリガーフレーム61を送信するためのキャリアセンスを最初に一回だけ行い、バースト送信期間中のトリガーフレーム69、70等の送信前にはキャリアセンスが不要なため、効率的な通信が可能となる。バースト送信終了後は、基地局は、任意の時点で再度バースト送信を行う場合は、再度キャリアセンスを行ってアクセス権を獲得する。このようなバースト送信を行う場合に、トリガーフレームの送信周期は、バースト送信の起点となるトリガーフレーム61から、次のバースト送信の起点となるトリガーフレーム71までの間隔でもよい。前述した本実施形態の第2の動作例において、タイマーにトリガーフレームの送信周期またはこの整数倍に応じた値を設定する例を述べたが、この送信周期は、バースト送信の起点となるトリガーフレームの送信周期でもよい。
以下、トリガーフレームのフォーマット、M-BAフレームのフォーマット、UL-MU-MIMO、およびUL-OFDMAについて詳細に説明する。
(トリガーフレーム)
図17(A)にトリガーフレームのフォーマット例を示す。このフォーマットは、図3に示した一般的なMACフレームのフォーマットをベースとしており、Frame Controlフィールド、Duration/IDフィールド、Address1フィールド、Address2フィールド、共通情報フィールド(Common Info.)フィールドと、複数の端末情報フィールド(Per User Info.)フィールドと、FCSフィールドとを含んでいる。Frame ControlフィールドのTypeおよびSubtypeでトリガーフレームであることを指定する。Typeは、一例として“制御”であり、Subtypeはトリガーフレームに対応する新たな値を定義してもよい。ただし、Typeを“管理”または、“データ”にしたトリガーフレームを定義してもかまわない。なお、Subtypeとして新たな値に定義する代わりに、トリガーフレームであることを通知するフィールドをMACヘッダの予約フィールドを利用して表現してもよい。
Address1フィールドには、RAとして、ブロードキャストアドレスまたはマルチキャストアドレスを設定すればよい。Address2フィールドにはTAとして、基地局のMACアドレス(BSSID)を設定すればよい。ただし、Address1フィールド、Address2フィールドまたはこれらの両方が、省略される場合もあり得る。共通情報フィールドには、UL-MU送信を指定する複数の端末に共通に通知するパラメータ情報を設定する。例えば端末情報フィールドのフォーマットを指定する情報、応答で送信するパケット長を指定する情報、トリガーフレームの目的を示す情報、応答で送信するフレームの種類、を設定してもよい。また、送信するデータが属するACを推奨または指定する情報を設定してもよい。また、端末情報フィールドの個数の情報を設定してもよい。また複数の端末が同じグループIDに属する場合に、当該グループIDを設定してもよい。また共通情報フィールドに本実施形態の第2の動作例で説明したタイマー設定値を設定してもよい。この場合、一例として、図17(B)に示す共通情報フィールドのフォーマットを用いてもよい。この例では、Type-dependent Common Infoサブフィールドの前に、タイマー設定値を通知するTimer Valueサブフィールドが設けられている。ただし、図17(B)のフォーマットは一例であり、他のサブフィールドが存在してもよいし、一部のサブフィールドが省略されてもよい。Timer Valueサブフィールドの位置も図17(B)の位置に限定されない。
複数の端末情報フィールドには、UL-MU送信用の端末を指定する情報(AID等の端末の識別子)、および端末に個々に通知するパラメータ情報を設定する。例えば、端末がUL-MU送信で使用するリソースに関する情報を指定する。また、端末が使用する送信電力、MCS等を指定する情報を設定してもよい。トリガーフレームを受信した端末は、共通情報フィールドと、自端末の識別子が設定された端末情報フィールドで指定されたパラメータ情報に従って、UL-MU送信を行う。共通情報フィールドにグループIDが設定される場合など、端末情報フィールドから端末の識別子を省略する場合もあり得る。また端末情報フィールドに本実施形態の第2の動作例で説明したタイマー設定値を設定してもよい。この場合、一例として、図17(C)に示す端末情報フィールドのフォーマットを用いてもよい。この例では、Type-dependent Per User Info variableサブフィールドの前に、タイマー設定値を通知するTimer Valueサブフィールドが設けられている。ただし、図17(C)のフォーマットは一例であり、他のサブフィールドが存在してもよいし、一部のサブフィールドが省略されてもよい。Timer Valueサブフィールドの位置も図17(C)の位置に限定されない。
ランダムアクセス用トリガーフレーム(TF-R)の場合は、一例として図17と同じフォーマットを利用できる。例えば端末情報フィールドに、特定の端末に使用を限定しないことを示す情報を設定する。具体的に、未使用のAIDの値である“X”を指定してもよい。Xの値は、ビーコンフレーム等の管理フレームで事前に基地局から各端末に通知されていてもよい。“X”が設定されたリソース(例えばOFDMAの場合はリソースユニット)は、どの端末が使用してもよいリソース、すなわち、ランダムアクセス用のリソースである。端末は、Xが設定されている端末情報フィールドをランダムに選択して、そこに記載されているリソースをUL-MU送信に使用する。TF-Rの場合、すべての端末情報フィールドにXが設定されていてもよいし、一部の端末情報フィールドには、端末のAIDが設定されてもよい。その場合、その一部の端末情報フィールドに設定されているリソースは、当該AIDの端末が利用する。いずれかの端末情報フィールドで自装置のAIDが設定されている端末であっても、自端末に指定されたリソースに加えて、Xが設定されている端末情報フィールドに記載されたリソースを用いることを許容してもよい。TF-Rを受信した端末は、ランダムバックオフ手法に類似した方法に基づきリソースを選択する。例えば予めランダムに選択したランダムバックオフカウンタ値から、“X”が設定されたリソース数を引き、0以下になると選択権があるとして、リソースの選択を行う。0より大きい場合は、今回のランダムアクセスを見送り、次回のTF-Rの受信時に、減算後のランダムバックオフカウンタ値を利用して、同様にして選択権の有無を判断する。なお、ランダムアクセス用トリガーフレームの実現方法は、ここで述べた以外の方法でもかまわない。
なお、ランダムアクセス用のリソースの使用を、特定の端末群または特定のグループIDをもつグループに限定する構成も可能である。前者の場合、複数のAIDを設定するようにしてもよい。後者の場合、端末情報フィールドにグループIDを設定するようにしてもよい。
(Multi-STA BAフレーム)
Multi-STA BAフレームは、複数の端末に対する送達確認を1フレームで行うためにBlock Ackフレーム(BAフレーム)を流用したものである。フレームタイプは、通常のBAフレームと同様、制御(Control)、フレームサブタイプはBlockAckとすればよい。図18(A)にMulti-STA BAフレームのフォーマット例を示す。図18(B)は、BAフレームにおけるBA Controlフィールドのフォーマットの例を示し、図18(C)は、BAフレームにおけるBA Informationフィールドのフォーマットの例を示す。BAフレームを再利用する場合、複数の端末に関する送達確認応答を通知するために拡張したBAフレームフォーマットであるということを、BA Controlフィールドの中で示してもよい。例えばIEEE802.11規格では、Multi-TIDサブフィールドが1、かつCompressed Bitmapサブフィールドが0の場合が、現状予約(Reserved)になっている。これを複数の端末に関する送達確認応答を通知するために拡張したBAフレームフォーマットであることを示すために用いるようにしてもよい。あるいは図18(B)ではビットB3-B8の領域が予約サブフィールドになっているが、この領域の一部または全てを、複数の端末に関する送達確認応答を通知するために拡張したBAフレームフォーマットであることを示すために定義してもよい。あるいは、このような通知を明示的に行わなくても良い。
BAフレームにおけるRAフィールドは、一例として、ブロードキャストアドレス、またはマルチキャストアドレスでもよい。BA ControlフィールドのMulti-Userサブフィールドには、BA Informationフィールドでレポートするユーザ数(端末数)を設定してもよい。BA Informationフィールドには、ユーザ(端末)ごとに、アソシエーションID用のサブフィールド、Block Ack開始シーケンスコントロール(Block Ack Starting Sequence Control)サブフィールドと、Block Ackビットマップ(Block Ack Bitmap)サブフィールドとを配置する。
アソシエーションIDサブフィールドにはユーザ識別を行うためAIDを設定する。より詳細には、図18(C)に示すように、一例として、Per TID Infoフィールドの一部を、アソシエーションID用のサブフィールドとして使う。現状、12ビット(B0からB11)が予約領域となっている。この先頭の11ビット(B0-B10)をアソシエーションID用のサブフィールドとして使う。Block Ack開始シーケンスコントロールサブフィールドおよびBlock Ackビットマップサブフィールドは、端末が送信するフレームが単一のデータフレームである場合(アグリゲーションフレームではない場合)は、省略すればよい。別の例としては、パーシャルステート動作を用い、対応するシーケンス番号をBlock Ackビットマップサブフィールドで表現するようにする。端末が送信するフレームがアグリゲーションフレームのときは、Block Ack開始シーケンスコントロールサブフィールドには、当該BlockAckフレームが示す送達確認応答の最初のMSDU(medium access control (MAC) service data unit)のシーケンス番号を格納する。Block Ackビットマップサブフィールドには、Block Ack開始シーケンス番号以降の各シーケンス番号の受信成功可否のビットからなるビットマップ(Block Ackビットマップ)を入れればよい。
(UL-MU-MIMO)
UL-MU-MIMOは、複数の端末が同じタイミングで、それぞれ同一周波数帯でフレームを基地局に送信(空間多重送信)することで、アップリンク送信の高効率化を図るものである。図19は、MU-MIMOの概念を説明するための図である。基地局が、4台の端末1~4(図ではSTA1~4と表記)とUL-MU-MIMOを行う状況を想定する。端末1~4は、同じチャネル(20MHz、40MHz、80MHzなど帯域幅は任意でよい)を利用して、同時にフレームを送信する。基地局は、これらのフレームを同時に受信するが、各フレームの物理ヘッダに含まれるプリアンブル信号を利用して、これらのフレームを分離できる。以下、これについて詳細に説明する。
基地局は、UL-MU-MIMOによって伝送された各端末のフレームを同時に重ね合わさった信号として受信する。UL-MU-MIMOでは、基地局は、複数の端末から同時に受信した信号から各端末のフレームを空間的に分離する必要がある。このために、基地局は、複数の端末のそれぞれとのアップリンクの伝搬路応答を利用する。基地局は、各端末のアップリンクの伝搬路応答を、複数の端末が送信するフレームの先頭側に付加されるプリアンブル信号を利用して推定できる。このプリアンブル信号は、詳細には、フレームの先頭側に配置される物理ヘッダ内のプリアンブル信号用のフィールドに含まれる。
図20に、端末1~4が送信するフレームを含む物理パケットの構成の例を示す。図20のように、プリアンブル信号は、例えばL-SIGフィールドとフレームとの間のプリアンブル信号用のフィールドに配置される。端末1~4のプリアンブル信号1~4は互いに直交している。なお、プリアンブル信号1~4より前に配置されたL-STF(Legacy-Short Training Field)、L-LTF(Legacy-Long TrainingField)、L-SIG(Legacy Signal Field)等は、例えば、IEEE802.11aなどのレガシー規格の端末が認識可能なフィールドであり、それぞれ信号検出、周波数補正(伝搬路推定)、伝送速度などの情報が格納される。L-STF、L-LTF、L-SIGは、UL-MU-MIMO送信する複数の端末で同じ信号である。上述のプリンアンブル信号は、本実施形態に係るリソースの一例に対応する。以下、プリアンブル信号について説明する。
プリアンブル信号は、既知ビット列あるいは既知のシンボル列で構成される。基地局は、既知ビット列を利用して、アップリンクの伝搬路応答を推定することで、プリアンブル信号より後のフィールドを正しく空間的に分離(復号)出来る。これは、公知の手法、例えばZF(Zero-Forcing)法、または、MMSE(Minimum Mean Square Error)法、または、最尤推定法等、任意の方法を用いて行うことができる。プリアンブル信号は、一例として、MACフレームの先頭側に配置される物理ヘッダ(PHYヘッダ)内に配置される。物理ヘッダ内のプリアンブル信号より前のフィールドでは各端末から同じ信号が送信されるため、基地局はこれらの信号を同時に受信しても復号可能である。一方、各端末のプリアンブル信号は互いに直交している。このため、基地局が、各端末から同時に受信したプリアンブル信号を個別に識別できる。これにより、基地局は、端末毎のプリアンブル信号を用いて、各端末から基地局へのアップリンクの伝搬路を推定できる。プリアンブル信号より後では、端末毎に別個の信号が送られるが、推定した伝搬路応答を利用して、これらの信号を分離できる。
端末間のプリアンブル信号の直交化の方法として、時間的、周波数的および符号的のいずれの方法を用いることができる。時間直交の場合には、プリアンブル信号用のフィールドが複数の区間に分割され、各端末のプリアンブル信号が異なる区間で送信される。ある区間には、いずれか1台数端末のみがプリアンブル信号を送信する。つまり、ある端末がプリアンブル信号を送信する間、他の端末は何も送信しない期間になる。周波数直交の場合には、各端末が互いに直交関係にある周波数でプリアンブル信号を送信する。符号直交の場合には、各端末がそれぞれ直交行列の互いに異なる行(または互いに異なる列)に含まれる値列を配置した信号を送信する。直交行列の各行(または各列)は互いに直交の関係にある。いずれの直交化の方法でも、基地局では各端末のプリアンブル信号を識別可能である。
各端末に互いに直交するプリアンブル信号を使用させるために、各端末が使用するプリアンブル信号およびその送信方法の情報を、基地局は与えておく必要がある。この情報は、UL-MU-MIMOで使用するリソースに相当する。具体的には、時間直交の場合には、どのタイミングでそれぞれプリアンブル信号(プリアンブル信号は端末間で同じでもよいし、異なってもよい)を送信するか、周波数直交の場合にはどの周波数でそれぞれプリアンブル信号(プリアンブル信号は端末間で同じでもよいし、異なってもよい)を送信するか、符号直交の場合にはどの符号化パターン(直交行列のどの行または列のパターン)を用いてプリアンブル信号を送信するか、の情報(リソースの情報)が必要となる。
(OFDMA)
OFDMAは、1つまたは複数のサブキャリアを含むリソースユニットを端末に割り当て、リソースユニットベースで、基地局と複数の端末との間で送受信を同時に行う。リソースユニットは、通信を行うリソースの最小単位となる周波数成分である。
図21に、1つのチャネル(ここではチャネルMと記述している)の連続した周波数領域内に確保したリソースユニット(RU#1、RU#2、・・・RU#K)を示す。チャネルMには、互いに直交する複数のサブキャリアが配置されており、1つまたは複数のサブキャリアを含む複数のリソースユニットがチャネルM内に定義されている。リソースユニット間には、1つ以上のサブキャリア(ガードサブキャリア)が配置されてもよいが、ガードサブキャリアは必須ではない。チャネル内の各リソースユニットまたは各サブキャリアには、リソースユニットまたはサブキャリアを識別するための識別情報が設定されていてもよい。1つのチャネルの帯域幅は、一例として、20MHz、40MHz、80MHz、160MHzなどであるが、これらに限定されない。20MHzの複数のチャネルをまとめて1つのチャネルとしてもよい。帯域幅に応じてチャネル内のサブキャリア数またはリソースユニット数が異なってもよい。複数の端末がそれぞれ異なるリソースユニットを同時に用いることで、OFDMA通信が実現される。
リソースユニットの帯域幅(あるいはサブキャリア数)は、各リソースユニットで共通でもよいし、リソースユニットごとに帯域幅(あるいはサブキャリア数)が異なってもよい。図22に、1つのチャネル内におけるリソースユニットの配置パターン例を模式的に示す。紙面に沿って横方向が周波数領域方向に対応する。図22(A)は、同じ帯域幅の複数のリソースユニット(RU#1、RU#2、・・・RU#K)を配置した例を示す。図22(B)は、図22(A)より大きな帯域幅の複数のリソースユニット(RU#11-1、RU#11-2、・・・、RU#11-L)を配置した例を示す。図22(C)は3種類以上の帯域幅のリソースユニットを配置した例を示す。リソースユニット(RU#12-1、RU#12-2)が最も大きな帯域幅を有し、リソースユニットRU#11-(L-1)は図22(B)のリソースユニットと同じ帯域幅、リソースユニット(RU#K-1、RU#K)は図22(A)のリソースユニットと同じ帯域幅を有する。
一例として、20MHzチャネル幅全体を使う場合、20MHzチャネル幅内に配置される256個のサブキャリア(トーン)に対し、リソースユニットが26個で設定できる。つまり、20MHzチャネル幅では9つのリソースユニットが設定され、リソースユニットの帯域幅としては2.5MHz幅より小さくなる。40MHzチャネル幅では、一例として、リソースユニットは18個設定される。80MHzチャネル幅では、一例として、リソースユニットは、37個設定される。これを発展させると、例えば160MHzチャネル幅または80+80MHzチャネル幅では、74個のリソースユニットが設定される。もちろんリソースユニットの幅は特定の値に制限されず、様々なサイズのリソースユニットを配置することもできる。
なお、各端末が使用するリソースユニット数は、特定の値に制限されず、1つまたは複数のリソースユニットを用いてもよい。端末が複数のリソースユニットを用いる場合、周波数的に連続する複数のリソースユニットをボンディングして1つのリソースユニットとして用いてもよいし、離れた箇所にある複数のリソースユニットを用いることを許容してもよい。図22(B)のリソースユニット#11-1は、図22(A)のリソースユニット#1と#2をボンディングしたリソースユニットの一例と考えても良い。
1つのリソースユニット内のサブキャリアは周波数領域で連続していてもよいし、非連続に配置された複数のサブキャリアからリソースユニットを定義してもよい。OFDMAで使用するチャネルは1つに限定されず、チャネルMに加えて、周波数領域で離れた位置に配置された別のチャネル(図21ではチャネルNを参照)内にも、チャネルMと同様にしてリソースユニットを確保し、チャネルMとチャネルNの両方内のリソースユニットを用いてもよい。チャネルMとチャネルNとでリソースユニットの配置方法は同じであっても、異なってもよい。1つのチャネルの帯域幅は、一例として、上述のように、20MHz、40MHz、80MHz、160MHzなどであるが、これらに限定されない。3つ以上のチャネルを用いることも可能である。なお、チャネルMとチャネルNをまとめて1つのチャネルとして考えることも可能である。
キャリアセンスは、CCA(Clear Channel Assessment)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)と、受信したフレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)との両方を包含してもよい。なお、チャネル単位で行ったCCAまたはNAVに基づくキャリアセンス情報は、チャネル内の全リソースユニットに共通に適用してもよい。例えばキャリアセンス情報がアイドルを示すチャネルに属するリソースユニットは、すべてアイドルと判断してもよい。
なお、OFDMAは、上述したリソースユニットベースのOFDMA以外に、チャネルベースでのOFDMAも可能である。この場合のOFDMAを、特にMU-MC(Multi-User Multi-Channel)と呼ぶことがある。MU-MCでは、クセスポイントが複数のチャネル(1つのチャネル幅は例えば20MHzなど)を複数の端末に割り当て、当該複数のチャネルを同時に用いて、複数端末宛て同時送信もしくは複数端末からの同時受信を行う。
(第2の実施形態)
図23は、第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との間でデータを受け渡しするためのバッファを内部に保有してもよい。このバッファは、SRAM、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から受信したデータや、受信部403で受信したデータの保存等を行う。メモリ406は、例えば、SRAM、DRAM等の揮発性メモリでもよいし、NAND、MRAM等の不揮発メモリでもよい。また、SSDやHDD、SDカード、eMMC等であってもよい。メモリ406が、基地局400の外部にあってもよい。
有線I/F405は、サーバ407とのデータの送受信を行う。本実施形態では、サーバ407との通信を有線で行っているが、サーバ407との通信を無線で実行するようにしてもよい。この場合、有線I/F405の代わりに、無線I/Fを用いればよい。
サーバ407は、データの送信を要求するデータ転送要求を受けて、要求されたデータを含む応答を返す通信装置であり、例えばHTTPサーバ(Webサーバ)、FTPサーバ等が想定される。ただし、要求されたデータを返す機能を備えている限り、これに限定されるものではない。PCやスマートフォン等のユーザが操作する通信装置でもよい。
基地局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/Fを405介して、サーバ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のキャッシュデータから応答するような一般的なキャッシュプロキシであれば、別の動作でも問題はない。
なお、本実施形態では、キャッシュ機能を備えた基地局について説明を行ったが、図23と同じブロック構成で、キャッシュ機能を備えた端末(STA)を実現することもできる。この場合、有線I/F405を省略してもよい。
(第3の実施形態)
図24は、端末または基地局の全体構成例を示したものである。この構成例は一例であり、本実施形態はこれに限定されるものではない。端末または基地局は、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カメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ/サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等でもよい。
図25は、無線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 Converter)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の実施形態)
図26(A)及び図26(B)は、それぞれ第4の実施形態に係る無線通信端末の斜視図である。図26(A)の無線通信端末はノートPC301であり、図26(B)の無線通信端末は移動体端末321である。それぞれ、端末(基地局を含む)の一形態に対応する。ノートPC301及び移動体端末321は、それぞれ無線通信装置305、315を搭載している。無線通信装置305、315として、これまで説明してきた端末(基地局を含む)に搭載されていた無線通信装置を用いることができる。無線通信装置を搭載する無線通信端末は、ノートPCや移動体端末に限定されない。例えば、TV、デジタルカメラ、ウェアラブルデバイス、タブレット、スマートフォン、ゲーム装置、ネットワークストレージ装置、モニタ、デジタルオーディオプレーヤ、Webカメラ、ビデオカメラ、プロジェクト、ナビゲーションシステム、外部アダプタ、内部アダプタ、セットトップボックス、ゲートウェイ、プリンタサーバ、モバイルアクセスポイント、ルータ、エンタープライズ/サービスプロバイダアクセスポイント、ポータブル装置、ハンドヘルド装置等にも搭載可能である。
また、端末(基地局を含む)に搭載されていた無線通信装置は、メモリーカードにも搭載可能である。当該無線通信装置をメモリーカードに搭載した例を図27に示す。メモリーカード331は、無線通信装置355と、メモリーカード本体332とを含む。メモリーカード331は、外部の装置(無線通信端末または基地局、またはこれらの両方等)との無線通信のために無線通信装置335を利用する。なお、図27では、メモリーカード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)などがある。
フレーム間隔の定義は、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におけるランダムアクセスに基づく競合期間のフレーム交換の一例を図28に示す。
ある無線通信装置においてデータフレーム(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には状況に応じて任意の値を入れることができる。また、これら複数のフレームまたは複数の第Xフレームは、同時に送信または受信されるもののみならず、時間的に異なるタイミングで送信または受信されるものであってもよい。また、第1フレーム、第2フレーム等を時間的に異なる時点で送信または受信すると表現する場合は、第1、第2等の表現は、単にフレームを区別するための表現に過ぎず、これらのフレームの種類・内容の異同は問わない。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
出願時における特許請求の範囲の記載を以下に付記する。
[1]
アップリンクマルチユーザ送信の履歴、またはアップリンクマルチユーザ送信の能力の有効または無効の状態に応じて、無線媒体を占有可能な時間の上限を定める第1パラメータの値を変更する制御部
を備えた無線通信装置。
[2]
前記第1パラメータに従って決定される前記無線媒体の占有時間に応じた情報を含む第1フレームを、キャリアセンスに基づき獲得されたアクセス権に基づいて前記無線媒体へ送信する送信部
をさらに備えた[1]に記載の無線通信装置。
[3]
前記アップリンクマルチユーザ送信を指示する第2フレームを受信する受信部と、
前記第2フレームに応答して、第3フレームを送信する送信部と、を備え、
前記制御部は、前記第3フレームの送信が成功した場合に、前記第1パラメータの値を小さくする
[1]に記載の無線通信装置。
[4]
前記アップリンクマルチユーザ送信を指示する第2フレームを受信する受信部と、
前記第2フレームに応答して、第3フレームを送信する送信部と、を備え、
前記制御部は、前記第2フレームの受信回数と、前記第3フレームの送信に成功した回数とに基づいて、前記第1パラメータの値を変更する
[1]に記載の無線通信装置。
[5]
前記制御部は、シングルユーザ送信の履歴をさらに用いて前記第1パラメータの値を変更する
[1]ないし[4]のいずれか一項に記載の無線通信装置。
[6]
前記アップリンクマルチユーザ送信を指示する第2フレームを受信する受信部と、
前記第2フレームに応答して、第3フレームを送信する送信部と、を備え、
前記送信部は、前記無線媒体へキャリアセンスに基づき獲得されたアクセス権に基づいて、第4フレームを送信し、
前記第3フレームの送信に成功した回数と、前記第4フレームの送信に成功した回数とに基づいて、前記第1パラメータの値を変更する
[1]に記載の無線通信装置。
[7]
前記制御部は、前記第1パラメータの値に第1係数を乗じることによって前記第1パラメータの値を小さくする
[1]ないし[6]のいずれか一項に記載の無線通信装置。
[8]
前記制御部は、前記第1パラメータの値から、前記第3フレームの長さに応じた値を減算することにより、前記第1パラメータの値を小さくする
[3]ないし[4]のいずれか一項に記載の無線通信装置。
[9]
前記アップリンクマルチユーザ送信後の予め定めた時点からの経過時間に応じて、前記第1パラメータの値を変更する
[1]ないし[8]のいずれか一項に記載の無線通信装置。
[10]
前記予め定めた時点から一定時間を経過した場合は、前記第1パラメータの値を所定値に変更する
[9]に記載の無線通信装置。
[11]
前記制御部は、前記受信部で予め定めた第5フレームが受信された場合に、前記第1パラメータの値を所定値に変更する
[1]ないし[10]のいずれか一項に記載の無線通信装置。
[12]
前記制御部は、前記アップリンクマルチユーザ送信の前記履歴に応じて、前記無線媒体のキャリアセンスを行う期間長に関する第2パラメータの値を変更し、変更後の前記第2パラメータに従って決定した期間の間、前記キャリアセンスを行う
[1]ないし[11]のいずれか一項に記載の無線通信装置。
[13]
アップリンクマルチユーザ送信を指示する第7フレームを受信する受信部と、
前記第7フレームに応答して、第8フレームを送信する送信部と、
前記制御部は、前記第8フレームまたは第9フレームを送信するための前記無線媒体へのアクセス権を獲得するために第1期間の間、前記無線媒体の第1キャリアセンスを行い、前記第1キャリアセンスの間に前記第7フレームが受信された場合に、前記第1キャリアセンスを停止し、前記第8フレームの送信後、前記第9フレームを送信するためのアクセス権を獲得するため第2キャリアセンスを行い、
前記無線媒体の第1キャリアセンスを行っている途中で前記第7フレームが受信された場合の前記第2キャリアセンスを行う期間の長さは、前記第1期間の長さから、前記第1期間の開始から前記第7フレームの受信前までに行った前記第1キャリアセンスの時間長を引いた長さである
[1]ないし[12]のいずれか一項に記載の無線通信装置。
[14]
前記アップリンクマルチユーザ送信の前記履歴は、前記アップリンクマルチユーザ送信の実行有無、前記アップリンクマルチユーザ送信の実行回数、および前記アップリンクマルチユーザ送信の成功または失敗の実行結果、前記アップリンクマルチユーザ送信からの経過時間のうちの少なくとも1つを含む
[1]ないし[13]のいずれか一項に記載の無線通信装置。
[15]
少なくとも1つのアンテナをさらに備えた
[1]ないし[14]のいずれか一項に記載の無線通信装置。
[16]
アップリンクマルチユーザ送信を指示する第1フレームを送信する送信部と、
前記アップリンクマルチユーザ送信される複数の第2フレームを受信する受信部と、を備え、
前記複数の第2フレームの送信元の少なくとも1つに対して、前記アップリンクマルチユーザ送信の履歴、または前記少なくとも1つの送信元のアップリンクマルチユーザ送信の能力の有効または無効の状態に応じて、前記無線媒体を占有可能な時間の上限を定める第1パラメータの値を決定し、
前記送信部は、前記第1パラメータの値を表す情報を含む第3フレームを送信する
無線通信装置。
[17]
少なくとも1つのアンテナをさらに備えた
[16]に記載の無線通信装置。
[18]
アップリンクマルチユーザ送信を指示する第1フレームを受信する受信部と、
前記第1フレームに応答して、第2フレームを送信する送信部と、
前記第2フレームまたは第3フレームを送信するためのアクセス権を獲得するために第1期間の間、無線媒体の第1キャリアセンスを行っている途中で前記第1フレームが受信された場合に、前記第1キャリアセンスを停止し、前記第2フレームの送信後、前記第3フレームを送信するためのアクセス権を獲得するため第2キャリアセンスを行うよう制御する制御部と、を備え、
前記無線媒体の第1キャリアセンスを行っている途中で前記第1フレームが受信された場合の前記第2キャリアセンスの期間の長さは、前記第1期間の長さから、前記第1期間の開始から前記第1フレームの受信前までに行った前記第1キャリアセンスの時間長を引いた長さに等しい
無線通信装置。
[19]
アップリンクマルチユーザ送信の履歴、またはアップリンクマルチユーザ送信の能力の有効または無効の状態に応じて、無線媒体を占有可能な時間の上限を定める第1パラメータの値を変更する
無線通信方法。
原出願の特許査定時における特許請求の範囲の記載を以下に付記する。
[項目1]
無線通信装置であって、
前記無線通信装置にアップリンクマルチユーザ送信を実行することを指示する第1フレームを受信する受信部と、
前記第1フレームに応答して、前記アップリンクマルチユーザ送信で第2フレームを送信する送信部と、
制御部と、を備え、
前記受信部は、タイマーに設定する値を特定する情報を含む第3フレームを受信し、
前記受信部は、前記第2フレームに対する応答フレームである第4フレームを受信し、 前記制御部は、前記第4フレームを受信すると、前記情報に基づいて設定した前記タイマーを起動している場合にはリセットの上、前記タイマーを起動し、
前記制御部は、前記タイマーがタイムアウトすると、無線媒体のキャリアセンスの期間を決定する第1パラメータの値を変更する
無線通信装置。
[項目2]
前記第1パラメータは、コンテンションウィンドウの最小値及び最大値のうちの少なくとも1つを表すパラメータである
項目1に記載の無線通信装置。
[項目3]
前記第3フレームは、管理フレームである
項目1~2のいずれか一項に記載の無線通信装置。
[項目4]
前記管理フレームは、ビーコンフレームである
項目3に記載の無線通信装置。
[項目5]
前記無線通信装置は、前記アップリンクマルチユーザ送信の能力の有効又は無効の設定が可能になっており、
前記制御部は、前記アップリンクマルチユーザ送信の能力の設定が無効になっているときは、前記第4フレームの受信に応じた前記タイマーの設定、及び前記タイマーのタイムアウトに応じた前記第1パラメータの値の変更を行わず、前記第1パラメータの値として所定値を用いる
項目1~4のいずれか一項に記載の無線通信装置。
[項目6]
前記制御部は、前記アップリンクマルチユーザ送信の能力の設定が有効になっているときは、前記第4フレームの受信に応じて前記タイマーを設定し、前記タイマーのタイムアウトに応じて、前記第1パラメータの値の変更を行い、
前記第1パラメータの値の変更として、前記第1パラメータの値を第1値から第2値に変更し、
前記所定値は、前記第2値である
項目5に記載の無線通信装置。
[項目7]
無線通信装置であって、
前記無線通信装置にアップリンクマルチユーザ送信を実行することを指示する第1フレームを受信する受信部と、
前記第1フレームに応答して、前記アップリンクマルチユーザ送信で第2フレームを送信する送信部と、
制御部と、を備え、
前記受信部は、前記第2フレームに対する応答フレームである第3フレームを受信し、 前記制御部は、前記第3フレームを受信すると、タイマーを起動している場合にはリセットの上、前記タイマーを起動し、前記タイマーがタイムアウトすると、無線媒体のキャリアセンスの期間を決定する第1パラメータの値を第1値から第2値に変更し、 前記受信部は、前記第1値及び前記第2値の少なくとも一方の値を特定する情報を含む第4フレームを受信し、
前記第1パラメータの前記第1値及び前記第2値の少なくとも一方は、前記情報により特定される前記少なくとも一方の値である
無線通信装置。
[項目8]
前記第1パラメータは、コンテンションウィンドウの最小値及び最大値のうちの少なくとも1つを表すパラメータである
項目7に記載の無線通信装置。
[項目9]
前記第4フレームは、管理フレームである
項目7~8のいずれか一項に記載の無線通信装置。
[項目10]
前記管理フレームは、ビーコンフレームである
項目9に記載の無線通信装置。
[項目11]
前記無線通信装置は、前記アップリンクマルチユーザ送信の能力の有効又は無効の設定が可能になっており、
前記制御部は、前記アップリンクマルチユーザ送信の能力の設定が無効になっているときは、前記第3フレームの受信に応じた前記タイマーの起動、及び前記タイマーのタイムアウトに応じた前記第1パラメータの値の変更を行わず、前記第1パラメータの値として所定値を用いる
項目7~10のいずれか一項に記載の無線通信装置。
[項目12]
前記所定値は、前記第2値である
項目11に記載の無線通信装置。
[項目13]
無線通信装置により実行される無線通信方法であって、
前記無線通信装置にアップリンクマルチユーザ送信を実行することを指示する第1フレームを受信するステップと、
前記第1フレームに応答して、前記アップリンクマルチユーザ送信で第2フレームを送信するステップと、
タイマーに設定する値を特定する情報を含む第3フレームを受信するステップと、
前記第2フレームに対する応答フレームである第4フレームを受信するステップと、
前記第4フレームを受信すると、前記情報に基づいて設定した前記タイマーを起動している場合にはリセットの上、前記タイマーを起動するステップと、
前記タイマーがタイムアウトすると、無線媒体のキャリアセンスの期間を決定する第1パラメータの値を変更するステップと、
を備えた無線通信方法。
[項目14]
無線通信装置により実行される無線通信方法であって、
前記無線通信装置にアップリンクマルチユーザ送信を実行することを指示する第1フレームを受信するステップと、
前記第1フレームに応答して、前記アップリンクマルチユーザ送信で第2フレームを送信するステップと、
前記第2フレームに対する応答フレームである第3フレームを受信するステップと、
前記第3フレームを受信すると、タイマーを起動している場合にはリセットの上、前記タイマーを起動するステップと、
前記タイマーがタイムアウトすると、無線媒体のキャリアセンスの期間を決定する第1パラメータの値を第1値から第2値に変更するステップと、
前記第1値及び前記第2値の少なくとも一方の値を特定する情報を含む第4フレームを受信するステップと、を備え、
前記第1パラメータの前記第1値及び前記第2値の少なくとも一方は、前記情報により特定される前記少なくとも一方の値である
無線通信方法。