図面 (/)

技術 無線通信装置及び無線通信方法

出願人 株式会社東芝東芝デバイス&ストレージ株式会社
発明者 足立朋子松尾綾子
出願日 2019年12月6日 (1年0ヶ月経過) 出願番号 2019-221621
公開日 2020年3月5日 (9ヶ月経過) 公開番号 2020-036379
状態 未査定
技術分野 移動無線通信システム
主要キーワード ウェアラブルデバイス FS値 制限幅 パワーセーブ動作 拡張レベル アイドル情報 外部アダプタ チャネル拡張
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年3月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

複数の無線通信端末宛同時送信もしくは複数の無線通信端末からの同時受信を実現するために必要な各無線通信端末の特性を通知し、無線通信基地局で各無線通信端末の特性に基づいて、同時に送信または受信する無線通信端末グループの候補を生成可能にする。

解決手段

本発明の実施形態としての通信処理装置は、無線通信装置に搭載される集積回路であって、前記無線通信装置が所定の周波数帯域内の複数のチャネルのうち、1つもしくは連続した2つ以上のチャネルの集合であるチャネルセットごとに分離して前記他の無線通信装置と信号を送受信できる前記チャネルセットの個数を表す第1情報を通知する制御回路を備える。

概要

背景

従来の技術として、基準チャネルに対し拡張チャネルが与えられた場合に、無線通信端末自身及び通信相手である無線通信端末が、対応できるオプションチャネル幅と、実際に使用するチャネル幅を、互いに通知し合って把握する方法がある。ここで基準チャネルは、無線通信端末がベースとして使用するチャネルであり、単一のチャネル幅を有する。拡張チャネルは、基準チャネルに追加して用いるチャネルであり、1または複数のチャネル幅を与えることが可能である。また、ここで言う“無線通信端末”は、無線通信基地局通信する無線通信端末のみならず、無線通信基地局を指してもよい。以下では、無線通信端末を端末、無線通信基地局を基地局と呼ぶ。

RTS (Request To Send)フレームにより基準チャネルと同時に、拡張チャネルを割り当てる場合に、RTSフレームの受信側の端末で、各チャネルのキャリアセンス状態に応じて、使用可能なチャネル幅を判断し、そのチャネル幅でCTS(Clear To Send)フレームをRTSフレームへの応答として送信する方法がある。この方法では、使用可能なチャネル幅のCTSフレームを送信することで、RTSフレーム送信側の端末に、自端末から送信するデータフレーム用の適切なチャネル拡張幅を通知できる。

また、端末から接続要求を基地局に送信する際に、端末側で、同時に使用できる周波数帯域の数を示す周波数帯域情報を入れる方法がある。各RF回路が2連続の周波数帯域のいずれか一方だけを排他的に使用できる前提があり、このようなハードウェア構成の制限により、同時に使用可能な周波数帯域の数が制限されている。この場合に、その周波数帯域の数の制限を基地局が把握できるように、端末が、上記の周波数帯域情報を接続要求に含めて、基地局に送信する。

前述した拡張チャネルを用いる従来技術では、基準チャネルをベースにどれだけ拡張チャネルを取れるかという能力通知もしくはキャリアセンス結果の通知を行うものであり、基準チャネルをベースとして使う制約がある。基準チャネルが各端末で同じ場合は、相手端末と同時に通信できる端末が1台に制限される。後者の同時に使用できる周波数帯域の数を通知する従来技術では、上述したハードウェア構成の制限により、同時に使用可能な周波数帯域の数に制限がある。

このような基準チャネルをベースにしたチャネル利用の制約や、周波数帯域の数の制約を離れて、キャリアセンス下で、複数のチャネルを複数の端末に割り当て、複数端末宛て同時送信もしくは複数端末からの同時受信をするOFDMA(Orthogonal Frequency Division Multiple Access)通信を行うことを考える。ここでOFDMAは、複数の端末にサブキャリア単位で割り当てる方式だけでなく、チャネル単位での割り当てる方式も含めるとする。OFDMA通信で利用する複数のチャネルは、無線通信システムとして利用する全てのチャネルであっても、その一部の複数チャネルであってもよい。

概要

複数の無線通信端末宛て同時送信もしくは複数の無線通信端末からの同時受信を実現するために必要な各無線通信端末の特性を通知し、無線通信基地局で各無線通信端末の特性に基づいて、同時に送信または受信する無線通信端末グループの候補を生成可能にする。本発明の実施形態としての通信処理装置は、無線通信装置に搭載される集積回路であって、前記無線通信装置が所定の周波数帯域内の複数のチャネルのうち、1つもしくは連続した2つ以上のチャネルの集合であるチャネルセットごとに分離して前記他の無線通信装置と信号を送受信できる前記チャネルセットの個数を表す第1情報を通知する制御回路を備える。

目的

この問題は、MU−MCのみならず、MU−MIMOの場合でも、SIFS後で複数の端末から同時にアップリンク受信するときには共通の課題である

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

SMA/CA動作を行い、複数のチャネルキャリアセンス状態ビット表現する、無線通信装置

請求項2

前記ビットは8ビットである請求項1に記載の無線通信装置。

請求項3

他の無線通信装置からフレームを受信し、前記フレームの受信に基づき、前記複数のチャネルのキャリアセンス状態を判定する請求項1又は2に記載の無線通信装置。

請求項4

少なくとも1つのアンテナを備えた請求項1〜3のいずれか一項に記載の無線通信装置。

請求項5

無線通信装置によって実行される無線通信方法であって、CSMA/CA動作を行い、複数のチャネルのキャリアセンス状態をビットで表現する、無線通信方法。

技術分野

0001

本発明の実施形態は、無線通信装置及び無線通信方法に関する。

背景技術

0002

従来の技術として、基準チャネルに対し拡張チャネルが与えられた場合に、無線通信端末自身及び通信相手である無線通信端末が、対応できるオプションチャネル幅と、実際に使用するチャネル幅を、互いに通知し合って把握する方法がある。ここで基準チャネルは、無線通信端末がベースとして使用するチャネルであり、単一のチャネル幅を有する。拡張チャネルは、基準チャネルに追加して用いるチャネルであり、1または複数のチャネル幅を与えることが可能である。また、ここで言う“無線通信端末”は、無線通信基地局通信する無線通信端末のみならず、無線通信基地局を指してもよい。以下では、無線通信端末を端末、無線通信基地局を基地局と呼ぶ。

0003

RTS (Request To Send)フレームにより基準チャネルと同時に、拡張チャネルを割り当てる場合に、RTSフレームの受信側の端末で、各チャネルのキャリアセンス状態に応じて、使用可能なチャネル幅を判断し、そのチャネル幅でCTS(Clear To Send)フレームをRTSフレームへの応答として送信する方法がある。この方法では、使用可能なチャネル幅のCTSフレームを送信することで、RTSフレーム送信側の端末に、自端末から送信するデータフレーム用の適切なチャネル拡張幅を通知できる。

0004

また、端末から接続要求を基地局に送信する際に、端末側で、同時に使用できる周波数帯域の数を示す周波数帯域情報を入れる方法がある。各RF回路が2連続の周波数帯域のいずれか一方だけを排他的に使用できる前提があり、このようなハードウェア構成の制限により、同時に使用可能な周波数帯域の数が制限されている。この場合に、その周波数帯域の数の制限を基地局が把握できるように、端末が、上記の周波数帯域情報を接続要求に含めて、基地局に送信する。

0005

前述した拡張チャネルを用いる従来技術では、基準チャネルをベースにどれだけ拡張チャネルを取れるかという能力通知もしくはキャリアセンス結果の通知を行うものであり、基準チャネルをベースとして使う制約がある。基準チャネルが各端末で同じ場合は、相手端末と同時に通信できる端末が1台に制限される。後者の同時に使用できる周波数帯域の数を通知する従来技術では、上述したハードウェア構成の制限により、同時に使用可能な周波数帯域の数に制限がある。

0006

このような基準チャネルをベースにしたチャネル利用の制約や、周波数帯域の数の制約を離れて、キャリアセンス下で、複数のチャネルを複数の端末に割り当て、複数端末宛て同時送信もしくは複数端末からの同時受信をするOFDMA(Orthogonal Frequency Division Multiple Access)通信を行うことを考える。ここでOFDMAは、複数の端末にサブキャリア単位で割り当てる方式だけでなく、チャネル単位での割り当てる方式も含めるとする。OFDMA通信で利用する複数のチャネルは、無線通信システムとして利用する全てのチャネルであっても、その一部の複数チャネルであってもよい。

発明が解決しようとする課題

0007

OFDMA通信を行う場合に、基地局は、各端末に適切にチャネルを割り当てることで、複数チャネルの利用効率を高めることが望まれる。そのために、基地局は、各端末から、チャネル割り当ての判断に用いて有効な端末の特性情報収集する必要がある。しかしながら、具体的にどのような情報を収集すれば、すなわち各端末がどのような情報を基地局に通知すれば、適切なチャネル割り当てを実現できるのかは、従来技術には開示されていなかった。

課題を解決するための手段

0008

本発明の実施形態としての通信処理装置は、無線通信装置に搭載され、制御回路を備える。前記制御回路は、前記無線通信装置が所定の周波数帯域内の複数のチャネルのうち、1つもしくは連続した2つ以上のチャネルの集合であるチャネルセットごとに分離して信号を送受信できる前記チャネルセットの個数を表す第1情報を通知する。

0009

本発明の実施形態としての通信処理装置は、無線通信装置に搭載され、受信処理回路と制御回路とを備える。前記受信処理回路は、所定の周波数帯域内の複数のチャネルのうち、1つもしくは連続した2つ以上のチャネルの集合であるチャネルセットごとに分離して前記無線通信装置と信号を送受信できる前記チャネルセットの個数を表す第1情報を受信する。前記制御回路は、前記第1情報に応じて、前記複数のチャネルの中からチャネル割り当てを行う。

図面の簡単な説明

0010

本発明の実施形態に係る無線通信装置の機能ブロック図。
1つのチャネルセットで複数のチャネルをカバーする例を示す図。
1つのチャネルセットで1つのチャネルをカバーする例を示す図。
キャリアセンスを実施した場合の動作例を示す図。
キャリアセンスでビジーとなったチャネルを示す情報を通知する方法を説明する図。
duplicate送信をどのチャネルを用いて行っているかの情報を通知するフレームの例を示す図。
図6のフレームに対する応答フレームの例を示す図。
AV情報まで管理して、キャリアセンスをチャネルごとに実施する場合の例を示す図。
チャネルセットが2つの場合に、各チャネルセットでどのようにチャネルをカバーするかのバリエーションを示す図。
MU−MCに関する端末の能力を通知する情報エレメントの例を示す図。
キャリアセンス分離能力を通知する情報エレメントの例を示す図。
Extended Capabilitiesエレメントの例を示す図。
MU−MCの対応可否とキャリアセンス分離能力に関する情報を合わせて通知する情報エレメントの例を示す図。
基地局と複数の端末とにより形成される無線通信グループを示す図。
基地局の配下の端末のキャリアセンス分離能力の例を示す図。
基地局による複数の端末へのチャネル割り当ての例を示す図。
離れた位置の複数のチャネルを端末に割り当てる例を示す図。
基地局による複数の端末へのチャネル割り当ての他の例を示す図。
グループとそれに属する端末を通知する情報エレメントの例を示す図。
基地局が複数の端末とMU−MCを実施した例を示す図。
使用するチャネルが確定する前のチャネルセットの割り当て例を示す図。
使用するチャネルが確定した後のチャネルセットの割り当て例を示す図。
使用するチャネルが確定した後のチャネルセットの別の割り当て例を示す図。
チャネルが連続することの意味を説明する図
本発明の実施形態に係る端末の動作例を示すフローチャート
本発明の実施形態に係る基地局の動作例を示すフローチャート。
ガードバンドの例を示す図。
本発明の実施形態に係る無線通信装置のハードウェア構成例を示す図。
本発明の実施形態に係る無線機器の斜視図。
本発明の実施形態に係るメモリーカードを示す図。
コンテンション期間フレーム交換の一例を示す図。
IEEE802.11n規格およびIEEE802.11ac規格における基準チャネルおよび拡張チャネルの例を示す図。
IEEE802.11ac規格における基準チャネルおよび拡張チャネルの他の例を示す図。
リソースブロックベースのOFDMAの説明図。

実施例

0011

以下、図面を参照しながら、本発明の実施形態について説明する。無線LANの規格して知られているIEEE Std 802.11TM-2012およびIEEE Std 802.11acTM-2013は、本明細書においてその全てが参照によって組み込まれる(incorporated by reference)ものとする。

0012

(第1の実施形態)
図1に、第1の実施形態に係る無線通信装置の機能ブロック図を示す。この無線通信装置は、無線通信基地局または無線通信基地局と通信する無線通信端末に実装されることができる。無線通信基地局(以下、基地局)も、無線通信端末の一形態である。以下では無線通信端末(以下、端末)と言うときは、説明上、特に両者を区別する必要はない限り、基地局も含んでもよい。

0013

本実施形態では、基地局が複数の基準チャネル幅(例えば20MHz幅)のチャネルを複数の端末に割り当て、複数端末宛て同時送信もしくは複数端末からの同時受信をするOFDMA(Orthogonal Frequency Division Multiple Access)通信を行う場合を想定する。本明細書において、このようなOFDMAの通信を、特に、Multi−User Multi−Channel (MU−MC)通信、またはチャネルベースOFDMA通信と表現する。

0014

但し、複数の端末にサブキャリア単位で割り当てる方式であっても、連続した周波数領域内で(例えば20MHzチャネル幅や40MHzチャネル幅、80MHzチャネル幅、160MHzチャネル幅内で)複数の連続するサブキャリア一単位とするリソースブロック(サブチャネルと呼んでも良い)を、MU−MCにおけるチャネルの代わりとして用いて、端末に各々割り当てるとき、MU−MCの場合と同様に、本実施形態およびそれ以降の実施形態を適用できる。

0015

例えば、図34に示すように、周波数領域に複数のチャネルが配置されており、1つのチャネルの周波数領域は例えば20MHzである。1つのチャネルの帯域幅の周波数領域または、複数のチャネルを束ねた帯域幅の周波数領域が、それぞれ連続する周波数領域に対応する。連続する周波数領域には、周波数的に連続する複数のサブキャリアが互いに直交して配置されている。1つまたは連続する複数のサブキャリアを一単位とするリソースブロックを、1つまたは複数割り当てる。図34の例では1つのチャネルの周波数領域において、端末1、2にリソースブロックを割り当てている。端末に各々割り当てたリソースブロックで、複数端末宛て同時送信もしくは複数端末からの同時受信をする。このようなOFDMA通信を、特にリソースブロックベースのOFDMA通信と表現する。この場合、以降で説明する実施形態のチャネルをリソースブロックに置き換えれば、同様に以降の実施形態を適用することができる。図34では、端末1と端末2に割り当てるリソースブロックに2つのサブキャリアがガードサブキャリアとして配置されている。ガードサブキャリアの個数は2に限定されず、1以上であれば任意でよい。また、端末に割り当てるリソースブロック間にガードサブキャリアを配置することは必須ではなく、リソースブロック間にガードサブキャリアを配置しないことも可能である。1リソースブロック当たりのサブキャリア数は同じでもよいし、1リソースブロックのサブキャリア数が異なることを許容してもよい。なお、例えばリソースブロックベースのOFDMA通信で使用する周波数領域の帯域幅に応じて、当該周波数領域に配置されるサブキャリアの帯域幅が異なってもよい。例えば1つのチャネル(例えば20MHz)がリソースブロックベースのOFDMA通信で使用されるときは、当該チャネル内に配置されるサブキャリアの帯域幅は、2つのチャネルを束ねた40MHzの帯域幅の周波数領域に配置されるサブキャリアの帯域幅よりも小さくてもよい。

0016

サブキャリア単位の方式をMU−MCと組み合わせて行うことを許容してもよい。例えば、複数の20MHzチャネル各々で端末にサブキャリアあるいはリソースブロック単位で割り当てることを許容してもよい。この場合、同じチャネルに属する各リソースブロック内のサブキャリア数は同じとするが、各リソースブロックでサブキャリア数が異なることを許容してもよい。端末には、1つのチャネルの中の1つまたは複数のリソースブロックを割り当ててもよいし、複数のチャネルに属する複数のリソースブロックを割り当ててもよい。

0017

なお、後方互換の観点からは少なくとも後方互換の対象となるレガシーの端末での基本チャネル幅(IEEE802.11a/b/g/n/ac規格対応端末をレガシーとするなら20MHzチャネル幅)でPHYパケットを受信・復号できることが要求される。このため、後述のNAV(Network Allocation Vector)情報をリソースブロックについて取得したい場合、チャネル単位でNAV情報を取得し、当該チャネルに含まれるリソースブロックに、当該チャネルのNAV情報を共通に適用してもよい。

0018

またサブキャリア単位の方式をMU−MCと組み合わせて行う場合、具体的には例えば複数の20MHzチャネル各々で端末にサブキャリアあるいはリソースブロック単位で割り当てるという場合には、以降に記載のMU−MCでのチャネルを基準にした実施形態で考えればよい。

0019

以下、チャネルベースのOFDMA通信を想定して説明を続ける。非基地局の各端末および基地局では、所定の周波数帯域内の複数のチャネルのうち、1つまたは複数の連続するチャネルをチャネルセットとし、チャネルセットごとに独立して基地局および各端末と信号を送受信可能である。一例としてチャネルセット毎にキャリアセンスのビジー・アイドルの判断を独立して行うことが可能である。基地局は、MU−MC通信を行うにあたって、非基地局の各端末から、各々で独立に設定可能なチャネルセットの個数を表す情報を取得し、取得した情報に基づき、各端末へMU−MC通信のためのチャネル割り当てを行う。これにより、複数のチャネルの利用効率を上げる、適切なチャネル割り当てが実現される。MU−MC通信で利用する複数のチャネルは、無線通信システムとして利用する全てのチャネルであっても、その一部の複数チャネルであってもよい。以下の説明において、チャネルセットを、1つまたは連続する複数のチャネルに割り当てる、と表現することがある。これは、当該1つまたは連続する複数のチャネルの集合を1セットとして信号の送受信を行えるように、無線通信装置の送受信部(アナログ処理部、PHY処理部等)を設定することを意味する。

0020

図1に示されるように、端末(非基地局の端末および基地局)に搭載される無線通信装置は、上位処理部90、MAC処理部10、PHY(Physical;物理)処理部50、MAC/PHY管理部(制御回路)60、アナログ処理部70(アナログ処理部1〜N)及びアンテナ80(アンテナ1〜N)を含む。MAC処理部10、MAC/PHY管理部60、およびPHY処理部50は、他の端末(基地局を含む)との通信に関する処理を行う通信処理装置の一形態に相当する。アナログ処理部70は、例えばアンテナ80を介して信号を送受信する無線通信部の一形態に相当する。通信処理装置の機能、または上位処理部90、MAC処理部10、PHY(Physical;物理)処理部50、MAC/PHY管理部60のデジタル領域の処理の全部あるいは一部は、CPU等のプロセッサで動作するソフトウェアプログラム)によって行われてもよいし、ハードウェアによって行われてもよいし、ソフトウェアとハードウェアの両方によって行われてもよい。ソフトウェアはROM、RAM等のメモリハードディスクSSDなどの記憶媒体に格納してプロセッサにより読み出して実行してもよい。端末(非基地局の端末および基地局)は、上位処理部90、MAC処理部10、PHY(Physical;物理)処理部50、MAC/PHY管理部60の全部または一部の処理、または通信処理装置の処理を行うプロセッサを備えていてもよい。

0021

上位処理部90は、MAC(Medium Access Control;媒体アクセス制御)層に対して上位層のための処理を行う。上位処理部90は、MAC処理部10との間で信号をやり取りできる。上位層としては、代表的なものとしては、TCP/IPやUDP/IP、さらにその上層アプリケーション層などが挙げられるが、本実施形態はこれに限定されない。上位処理部90は、MAC層と上位層との間でデータをやり取りするためのバッファを備えていてもよい。バッファはDRAM等の揮発性メモリでもよいし、NANDMRAM等の不揮発メモリでもよい。

0022

MAC処理部10は、MAC層のための処理を行う。前述のように、MAC処理部10は、上位処理部90との間で信号をやり取りできる。更に、MAC処理部10は、PHY処理部50との間で、信号をやり取りできる。MAC処理部10は、MAC共通処理部20と送信処理部30と受信処理部40を含む。MAC処理部10は、端末(基地局を含む)に送信する情報を記憶装置アクセスして情報を読み出してもよいし、当該端末から受信した情報を記憶装置に格納してもよい。記憶装置は、MAC処理部10が備えるバッファ(内部メモリ)でも、MAC処理部10の外に備えられたバッファ(外部メモリ)でもよい。記憶装置は、DRAM等の揮発性メモリでも、NAND、MRAM等の不揮発メモリでもよい。また、記憶装置は、メモリ以外に、SSD、ハードディスク等でもよい。

0023

MAC共通処理部20は、MAC層での送受信に共通する処理を行う。MAC共通処理部20は、上位処理部90、送信処理部30、受信処理部40及びMAC/PHY管理部60と接続し、夫々との間で信号のやり取りをする。

0024

送信処理部30及び受信処理部40は、相互に接続している。また、送信処理部30及び受信処理部40は、夫々MAC共通処理部20及びPHY処理部50に接続している。送信処理部30は、MAC層での送信処理を行う。受信処理部40は、MAC層での受信処理を行う。

0025

PHY処理部50は、PHY層のための処理を行う。前述のように、PHY処理部50は、MAC処理部10との間で信号をやり取りできる。PHY処理部50は、アナログ処理部70を介してアンテナ80に接続されている。

0026

MAC/PHY管理部60は、上位処理部90、MAC処理部10(より詳細には、MAC共通処理部20)及びPHY処理部50の夫々と接続されている。MAC/PHY管理部60は、無線通信装置におけるMAC動作及びPHY動作を管理する。

0027

アナログ処理部70は、アナログデジタル及びデジタル/アナログ(AD/DA)変換器やRF回路を含み、PHY処理部50からのデジタル信号を所望の周波数のアナログ信号に変換してアンテナ80から送信、またアンテナ80から受信した高周波のアナログ信号をデジタル信号に変換する。なお、ここでは、AD/DA変換をアナログ処理部70で行っているが、PHY処理部50にAD/DA変換機能を持たせる構成も可能である。

0028

本実施形態では、1つまたは連続する2以上のチャネルを含むチャネルの集合をチャネルセットと呼ぶ。端末は、チャネルセット単位で、独立して信号の送受信あるいは信号処理を行うことができる。一例として、各チャネルセットで、それぞれ独立して(チャネルセット単位で)、キャリアセンスがビジーかアイドルかの判定が行うことができる。端末は、このように独立してキャリアセンスがビジーかアイドルかの判定が行うことができるチャネルセットを最大N個(Nは1以上の整数)持つ。端末がチャネルセットを複数持つことができる場合に、各チャネルセットがそれぞれ異なるチャネルのみ(例えばそれぞれ異なる1つのチャネル)を含んでもよいし、同じチャネルがチャネルセット間で重複していてもかまわないし、各チャネルセットのチャネルを全て同じにすることも可能である。キャリアセンスを行うときと、キャリアセンスを行ってアイドルが判断された後で通信をするときとの間で、チャネルセットの内容を変更するなど、端末が持っているチャネルセット数の範囲で、各チャネルセットを任意に設定できてもよい。チャネルセットの詳細は後述する。

0029

一実施形態として、端末がチャネルセットを最大N個(Nは1以上の整数)持つことができる場合には、N個のアナログ処理部70とN本のアンテナ80を持つ。この場合、N個のアナログ処理部70と、N個のPHY処理部50が設けられ、PHY処理部とアナログ処理部が1対ずつ接続するようになっていてもよい。また、N個のPHY処理部50が設けられる場合に、これらの各々に対応する送信処理部30及び受信処理部40が設けられてもよい。更に、N個のPHY処理部50に跨る共通PHY処理部が設けられてもよい。また、図1のようにN個のアナログ処理部70を持つ代わりに、1個のアナログ処理部70で、アンテナ80と接続するようにしてもよい。この場合、アナログ処理部70は、各チャネルからアンテナ80経由で受信した信号及び雑音を、デジタルフィルタで分離できればよい。従って、アンテナ80を複数本持つ必要はなく、1本でもよい。また送信の場合には、アナログ処理部70は、PHY処理部50から指定されたチャネル及びチャネル帯域幅で送信できるようにデジタルフィルタを調整する。

0030

本実施形態に係る無線通信装置は、1チップ内にアンテナ80を構成要素として含む(一体化する)ことで、このアンテナ80の実装面積を小さく抑えることができる。更に、本実施形態に係る無線通信装置は、図1に示されるように、送信処理部30及び受信処理部40が、N本のアンテナ80を共用している。送信処理部30及び受信処理部40がN本のアンテナ80を共用することにより、図1の無線通信装置を小型化できる。なお、本実施形態に係る無線通信装置は、図1に例示されたものと異なる構成を備えても勿論よい。

0031

無線媒体への信号送信に際して、PHY処理部50は、送信処理部30からMACフレームを受け取る。PHY処理部50は、MACフレームにプリアンブル及びPHYヘッダの追加や符号化、変調などの処理を行ってPHYパケットに変換する。アナログ処理部70は、デジタル信号であるPHYパケットを、所望の周波数のアナログ信号(例えば、中心周波数2412MHzの20MHz幅のアナログ信号)に変換する。アンテナ80は、アナログ処理部70からのアナログ信号を無線媒体に輻射する。なお、PHY処理部50は、信号送信の期間中に、無線媒体がビジーであることを示す信号を、MAC処理部10(より正確には受信処理部40)へ出力する。

0032

無線媒体からの信号受信に際して、アナログ処理部70は、アンテナ80が受信したアナログ信号を、PHY処理部50が処理可能な基底帯域(Baseband)の信号に変換し、デジタル信号に変換する。PHY処理部50は、アナログ処理部70からデジタルの受信信号受け取り、その受信レベルを検出すると共に、そのPHY方式の判定を行う。PHY方式としては、例えばOFDMスペクトル拡散などの変調方式符号化方式がある。PHY処理部50は、受信信号のPHY方式が判別できた場合、すなわち自身がそのPHY方式に対応している場合には、そのPHY方式に応じてキャリアセンスレベルを選択し、選択したキャリアセンスレベルと、受信信号のレベル(受信レベル)とを比較する。一方、PHY処理部50は、受信信号のPHY方式が判別できなかった場合には、すなわち自身がそのPHY方式に対応していない場合には、無線通信システムで使用するチャネル間隔での最小変調符号化感度(Minimum Modulation and Coding Rate Sensitivity)より20dB高い値をキャリアセンスレベルとして選択する。例えば20MHzのチャネル間隔を用いる場合には、最小変調符号化感度が−82dBであるので、キャリアセンスレベルとして−62dBを選択する。そして、選択したキャリアセンスレベルと、受信レベルとを比較する。受信レベルが、選択したキャリアセンスレベル以上であれば、PHY処理部50は媒体(CCA;Clear Channel Assessment)がビジーであるということを示す信号を、MAC処理部10(より正確には、受信処理部40)へ出力する。受信レベルが、選択したキャリアセンスレベル未満であれば、PHY処理部50は、媒体(CCA)がアイドルであるということを示す信号を、MAC処理部10(より正確には受信処理部40)へ出力する。無線通信装置が、キャリアセンスがビジーかアイドルかの判定が行えるチャネルセットを複数持つ場合には、PHY処理部50は、各アナログ処理部70から入力されるデジタル信号を別々に管理する。PHY処理部50は、MAC処理部10(より正確には受信処理部40)に、チャネルセットごとのキャリアセンス情報(CCAがアイドルかビジーかの情報)を出力する。

0033

PHY処理部50は、受信信号のPHY方式が適切な(即ち、無線通信装置が対応する)ものであれば、復調処理復号化処理、プリアンブル及びPHYヘッダを取り除く処理などを行って、ペイロードを抽出する。IEEE802.11規格ではこのペイロードをPHY側ではPSDU(Physical Layer Convergence Procedure (PLCP) Service Data Unit)と呼んでいる。PHY処理部50は、抽出したペイロードをMACフレームとして受信処理部40に渡す。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に通知する。

0034

MAC共通処理部20は、上位処理部90から送信処理部30への送信データの受け渡し、及び受信処理部40から上位処理部90への受信データの受け渡しを、夫々仲介する。また、MAC共通処理部20は、MAC/PHY管理部60からの指示を一旦受け取り、当該指示を送信処理部30または受信処理部40またはこれらの両方に適したものに変換して出力する。

0035

MAC/PHY管理部60は、例えばIEEE802.11規格におけるSME(Station Management Entity)に相当する。その場合、MAC/PHY管理部60とMAC共通処理部20との間のインタフェースは、IEEE802.11規格におけるMLMESAP(MAC subLayer Managament Entity Service Access Point)に相当し、MAC/PHY管理部60とPHY処理部50との間のインタフェースは、IEEE802.11無線LANにおけるPLME SAP(Physical Layer Management Entity Service Access Point)に相当する。

0036

なお、図1において、MAC/PHY管理部60は、MAC管理のための機能部とPHY管理のための機能部とが一体であるかのように描かれているが、分けて実装されてもよい。

0037

MAC/PHY管理部60は、管理情報ベース(Management Information Base;MIB)を保持する。MIBは、端末の能力や各種機能が夫々有効か無効かなどの各種情報を保持する。例えば、各端末で設定可能なチャネルセットの個数(最大数等)に関する情報や、各端末がMU−MCに対応するか否かといった情報も保持される。これらの情報は、後述するように各端末からの通知を持って、他の端末(基地局等)で取得されることができる。これらの端末に関する各種情報を記憶するためのメモリは、MAC/PHY管理部60に内包させてもよいし、MAC/PHY管理部60に内包せずに別に設け、そこにMIBを保持・管理してもよい。その場合、MAC/PHY管理部60は、その別のメモリを参照・書き換えが可能なようになっていてもよい。基地局としての端末のMAC/PHY管理部60は、非基地局としての端末に関する各種の情報(例えば上記のチャネルセットの最大数等)に基づき、複数のチャネルを同時に割り当てる端末を選定するグルーピング機能も備えている。

0038

MAC処理部10は、データフレーム、制御フレーム及び管理フレームの3種類のMACフレームを扱い、MAC層において規定される各種処理を行う。ここで、3種類のMACフレームについて説明する。

0039

管理フレームは、他の端末との間の通信リンクの管理のために用いられる。管理フレームとしては、例えば、IEEE802.11規格におけるBasic Service Set(BSS)である無線通信グループを形成するために、グループの属性及び同期情報報知するビーコン(Beacon)フレームや、認証のためにまたは通信リンク確立のために交換されるフレームなどがある。なお、ある端末が、もう一台の端末と互いに無線通信を実施するために必要な情報交換を済ませた状態を、通信リンクが確立していると、ここでは表現する。必要な情報交換として、例えば、自端末が対応する機能の通知や、方式の設定に関するネゴシエーションなどがある。管理フレームは、送信処理部30が、MAC/PHY管理部60からMAC共通処理部20を介して受けた指示に基づいて生成する。

0040

管理フレームに関連して、送信処理部30は、他の端末に管理フレームを介して各種情報を通知する通知手段(制御回路)を有する。非基地局としての端末の通知手段は、当該端末の無線通信装置で設定可能なチャネルセットの個数を表す情報を、管理フレームに入れて送信することで、基地局に当該情報を通知してもよい。当該情報を管理フレームで送信するように当該通知手段を制御する通知制御手段が、MAC/PHY管理部60に備えられていてもよい。チャネルセットの個数を表す情報は、一例として、チャネルセットの最大数でもよいし、これ以外の数、例えば、端末の状態に応じて決定したチャネルセットの個数でもよい。例えば、端末の電池残量が少ない場合は、最大数より少ないチャネルセット数を通知することで通信のチャネル数を減らして、消費電力下げることが考えられる。また、基地局の通知手段は、非基地局の端末に、MU−MC方式が可能な旨を表す情報や、当該非基地局の端末で設定可能なチャネルセットの要求数を表す情報を、管理フレームを介して通知してもよい。また、基地局の通知手段は、各端末に割り当てたチャネルを指定する情報を、管理フレームを介して各端末に通知してもよい。MAC/PHY管理部60は、これらの情報を管理フレームで送信するよう通知手段を制御する通知制御手段を備えてもよい。

0041

また、受信処理部40は、他の端末から管理フレームを介して各種情報を受信する受信手段(受信処理回路)を有する。一例として、非基地局としての端末の受信手段は、基地局としての端末からMU−MC方式が可能な旨を通知する情報を受信する。上記の非基地局としての端末の送信処理部30の通知手段は、このMU−MC方式が可能な旨の情報への応答として、上記のチャネルセット数の情報を、基地局に通知してもよい。また、非基地局としての端末の受信処理部40の受信手段は、基地局から上記のチャネルセットの要求数を通知する情報を受信してもよい。当該端末の通知手段は、当該端末の無線通信装置で設定可能なチャネルセット数が、当該要求数以上の場合に、チャネルセット数を表す情報を通知してもよい。また、基地局としての端末の受信処理部40の受信手段は、非基地局の端末から送信されるチャネルセット数を表す情報を、管理フレームを介して受信し、チャネル割り当てを行うMAC/PHY管理部60に通知してもよい。

0042

上述した管理フレームを介して送受信する情報の例は、ほんの一例であり、後述するように、チャネルセット間にガードバンドが必要か否か応じたガードバンドに関する情報、チャネルセット内の最大チャネル数または最大チャネル幅の制約に関する情報など、その他種々の情報を、管理フレームを介して、端末(基地局を含む)間で送受信することが可能である。

0043

データフレームは、他の端末との間で通信リンクが確立した状態で、データを当該他の端末に送信するために用いられる。例えばユーザのアプリケーション操作によって、端末においてデータが生成され、係るデータがデータフレームによって搬送される。具体的には、生成されたデータは、上位処理部90からMAC共通処理部20を介して送信処理部30に渡され、送信処理部30でデータをフレームボディフィールドに入れたデータフレームが生成され、PHY処理部50、アナログ処理部70及びアンテナ80を介して送信される。また、受信処理部40が、PHY処理部50を介してデータフレームを受信すると(受信したMACフレームがデータフレームであると把握すると)、そのフレームボディフィールドの情報をデータとして抽出し、MAC共通処理部20を介して上位処理部90に渡す。この結果、データの書き込み、再生などのアプリケーション上の動作が生じる。

0044

制御フレームは、管理フレーム及びデータフレームを、他の無線通信装置との間で送受信(交換)するときの制御のために用いられる。制御フレームとしては、例えば、管理フレームまたはデータフレームの交換を開始する前に、媒体を予約するために他の無線通信装置との間で交換するRTS(Request to Send)フレーム、CTS(Clear to Send)フレームなどがある。また、他の制御フレームの例として、受信した管理フレーム及びデータフレームの送達確認のために送信されるACK(Acknowledgement)フレーム、BA(Block Ack)フレームなどがある。これらの制御フレームも送信処理部30で生成される。CTSフレームやACKフレーム、BAフレームなど、受信したMACフレームへの応答として送信される制御フレームに関しては、受信処理部40で応答フレームの送信判断をして、フレーム生成に必要な情報(制御フレームの種別送信先端末アドレス情報など)を送信指示とともに送信処理部30に出す。送信処理部30が、当該フレーム生成に必要な情報に基づき、適切な制御フレームを生成する。

0045

MAC処理部10は、CSMA(Carrier Sense Multiple Access)に基づきMACフレームを送信する場合、媒体上でのアクセス権送信権)を獲得する必要がある。送信処理部30は、受信処理部40からのキャリアセンス情報に基づいて、送信タイミングを計る。送信処理部30は、係る送信タイミングに従って、PHY処理部50に送信指示を与えて、MACフレームを渡す。送信指示に加えて、送信処理部30は、送信に使用される変調方式及び符号化方式を合わせて指示してもよい。これらに加えて、送信処理部30は、送信電力を指示してもよい。MAC処理部10は、アクセス権を一旦獲得すると、媒体を占有可能な時間の間は、QoS(Quality of Service)属性などの制限を伴うものの、他の無線通信装置との間でMACフレームを連続して交換できる。アクセス権は、無線通信装置が所定のフレーム(例えばRTSフレーム)を送信し、他の無線通信装置から応答フレーム(例えばCTSフレーム)を正しく受信した場合に、獲得される。この所定のフレームが、他の無線通信装置によって受信されると、当該他の無線通信装置は、最小フレーム間隔(Short InterFrame Space)後に、上記応答フレームを送信する。

0046

受信処理部40は、キャリアセンス情報を管理する。このキャリアセンス情報は、PHY処理部50が入力する媒体(CCA:Clear Channel Assessment)のビジー/アイドルに関する物理的なキャリアセンス(Physical Carrier Sense)情報と、受信フレームの中に記載されている媒体予約時間に基づく仮想的なキャリアセンス(Virtual Carrier Sense)情報との両方を包含する。いずれか一方のキャリアセンス情報がビジーを示すならば、媒体がビジーであるとみなされ、その間送信は禁止される。なお、IEEE802.11規格において、媒体予約時間は、MACヘッダの中のいわゆるDuration/IDフィールドに記載される。MAC処理部10は、他の無線通信装置宛ての(自己宛てでない)MACフレームを受信した場合に、当該MACフレームを含むPHYパケットの終わりから媒体予約時間に亘って、媒体が仮想的にビジーであると判定する。このような仮想的に媒体をビジーであると判定する仕組み、或いは、仮想的に媒体をビジーであるとする期間は、NAV(Network Allocation Vector)と呼ばれる。

0047

端末が、キャリアセンスがビジーかアイドルかの判定が行えるチャネルセットを複数持つ場合、本実施形態では各チャネルセットで行うキャリアセンスとは、特にCCAがビジーかアイドルかという物理的なキャリアセンスを指すものとする。この場合、PHY処理部50からは、チャネルセットごとのCCAのビジー・アイドル情報が、受信処理部40に入力される。受信処理部40は、チャネルセットごとのCCAのビジー・アイドル情報と、受信したMACフレームのNAV情報(仮想的に媒体がビジーであるとする期間の情報)に基づき、送信可否を判断する。

0048

なお、各チャネルセットで、仮想的なキャリアセンスも行えるようにしてもよい。この場合は、PHY処理部50から受信処理部40へは、チャネルセットごとにMACフレームも渡されることになり、受信処理部40では、チャネルセットごとに仮想キャリアセンス情報(NAV情報)を管理することになる。

0049

<チャネルセットの詳細>
次に、キャリアセンスがビジーかアイドルかの判定が行えるチャネルセットについて、具体的に説明する。

0050

図2は、複数のチャネルに1つのチャネルセットを割り当てる場合の例を示す。具体的に、図2(a)は、2つの連続したチャネル(各チャネルをch.1、ch.2と表示)に、1つのチャネルセットを割り当てる例を示している。図2(b)は、3つの連続したチャネル(各チャネルをch.1、ch.2、ch.3と表示)に、1つのチャネルセットを割り当てる例を示している。本実施形態では、図2(a)のように、一方のチャネル(ch.2)に信号もしくは雑音がある場合、チャネルセットとして(すなわちch.1、ch.2ともに)、ビジーであると判断する。当然、両方のチャネルに信号もしくは雑音がある場合にも、ビジーであると判断する。また(b)のように、少なくともある一つのチャネル(この例ではch.2)に信号もしくは雑音がある場合、チャネルセットとして(すなわちch.1、ch.2、ch.3全て)、ビジーであると判断する。当然、一つのチャネルだけでなく、2つ、あるいは全てのチャネルで信号もしくは雑音を受信した場合も、ビジーであると判断する。

0051

このように、1つまたは連続した2つ以上のチャネルに一チャネルセットを割り当てた場合に、そのセット内に含まれるチャネルでのキャリアセンス把握状態の和(OR)を、チャネルセットとしてのキャリアセンス状態とする、と言うことができる。IEEE802.11ac規格では、帯域運用(bandwidth operation)として動的(dynamic)と静的(static)の2つのキャリアセンスの動作が規定されているが、それに倣うなら、本実施形態でのチャネルセット内では静的動作を行う、と言うことができる。

0052

図3は、複数のチャネル各々に、別々のチャネルセットを割り当てた場合の例である。具体的に、図3(a)は、2つのチャネル(各チャネルをch.1、ch.2と表示)に、各々チャネルセットを割り当て、図3(b)は、3つのチャネル(各チャネルをch.1、ch.2、ch.3と表示)に、各々チャネルセットを割り当てた場合を示している。なお、図2のように、1つのチャネルセットが複数のチャネルをカバーする場合、複数のチャネルが連続している必要があったが、図3のように、チャネルセットを複数設定する場合は、チャネルセット間でチャネルが連続している必要はない。図3では、たまたまチャネルセット間でチャネルが連続している例が示されているに過ぎない。図3(a)のように、ch.1、ch.2にそれぞれ別々のチャネルセットを割り当てる場合、一方のチャネル(ch.2)に信号もしくは雑音がある場合でも、もう一方のチャネル(ch.1)をアイドルとして把握でき、アイドルと把握した方のチャネルを使用できる。また図3(b)のように、いずれかのチャネル(ch.2)に信号もしくは雑音がありビジーである場合でも、チャネル間で独立してチャネル状態を区別でき、残りのチャネル(ch.1とch.3)をアイドルとして把握でき、それらのアイドルと把握したチャネルを使用できる。

0053

IEEE802.11ac規格でのキャリアセンスに関する帯域運用の概念に倣うなら、本実施形態でのチャネルセット間の動作は、動的動作となる、と言うことができる。

0054

例えば、チャネルセットとして最大2つを運用することができ、図3(a)のように一方のチャネルセットをch.1に、もう一方のチャネルセットをch.2に割り当てる場合には、図1においてNは2となり、例えば、アンテナ1とアナログ処理部1をch.1に、アンテナ2とアナログ処理部2をch.2に、対応させることになる。無線通信装置に設定可能な最大のチャネルセット数(最大セット数)は、アンテナとアナログ処理部の対の数と対応する、あるいはもっとブレイクダウンすれば、RF回路の数と対応する、と言うことができる。ただし、前述したようにデジタルフィルタ処理を用いることで、アンテナとアナログ処理部の個数はこのような制約を受けることなく、適宜、変更可能である。

0055

キャリアセンシング状態の把握−基準チャネルの概念がある場合の関係>
図3(a)をベースに、より具体的に、チャネルを基準チャネルと拡張チャネルで区別してキャリアセンスを実施した場合の動作例を示したのが、図4である。無線通信システム(BSS)がCSMA/CA(Carrier Sense Multiple Access with Carrier Avoidance)を用いている場合で、拡張チャネル側のキャリアセンス状態をモニターする実装負荷を軽減するために、拡張チャネル側のキャリアセンス状態をモニターする時間を制限する方法がある。図4は、それに基づいた説明を行うためのものである。図4では、基準チャネルを“primary”、拡張チャネルを“secondary”と示してある。

0056

基準チャネルは、物理的なキャリアセンスに加え、仮想キャリアセンスも実施するチャネルであり、拡張チャネルは、物理的なキャリアセンスのみを実施するチャネルである。IEEE802.11n規格およびIEEE802.11ac規格における基準チャネルおよび拡張チャネルの例を、図32および図33に示す。図32および図33に示されるものは、IEEEの規格書から抜粋したものである。図32に示すように、基準となる20MHzに対し、40MHzへのチャネル拡張の場合は、基準チャネル(primary)と拡張チャネル(secondary)が用いられる。80MHzへのチャネル拡張の場合は、基準チャネル(primary)と拡張チャネル(secondary、secondary40)が用いられる。160MHzへのチャネル拡張の場合は、基準チャネル(primary)と拡張チャネル(secondary、secondary40、secondary80)が用いられる。図33のように、secondary80が、secondaryから離れて位置する構成もある(80+80MHzチャネル拡張)。図32および図33ではprimaryと表示したチャネルに対し、secondaryと表示したチャネルが連続しているが、本実施形態では拡張チャネルが基準チャネルに連続したものに限定する必要はない。

0057

また、基準チャネルと拡張チャネルが、無線通信システム(BSS)として常に固定である必要もなく、端末ごとに独立に基準チャネルを決めてもよい。また、さらに通信のその時々フェーズで、基準チャネルを変更するようにしてもよい。

0058

図4では、基準チャネルがch.1、拡張チャネルがch.2としてある。一例として、基準チャネル(ch.1)が、図32および図33のprimaryに対応し、拡張チャネル(ch.2)が、図32および図33のsecondaryに対応してもよい。横軸を時間に取り、各チャネルでの送受信の状態を示してある。各横軸の上側で、当該端末の送信状況、各横軸の下側で、当該端末での受信状況を示している。ここでは、当該端末(便宜的にSTA101とする)に、別のある端末(これを便宜的にSTA102とする)がch.1とch.2を用いて、RTSフレームを送信している場合を示す。STA102が送信するRTSフレームは、図4中で、“RTS(1)”と表示している。()の中の数字は、宛先の下一桁を便宜的に示しているものとする。この場合は、RTSフレームはSTA101に送信しているので、STA101の識別番号の101の下一桁1を記載してある。

0059

ここでRTSフレームは例えば、全く同じ20MHzチャネル幅のPHYパケットとして、基準チャネルおよび拡張チャネルで同時に送信される、IEEE802.11n規格やIEEE802.11ac規格で言うところのduplicatePPDU(Physical Layer Convergence Procedure (PLCP) protocol data unit)である。この場合、当然、MACフレームレベルでも同じフレームとなっている。なお、本実施形態の拡張チャネルでは、IEEE802.11n規格の40MHzチャネル拡張(図32)や、IEEE802.11ac規格での80MHzや160MHzチャネル拡張(図32)のように、拡張チャネルを基準チャネルから連続で取るといった制限や、IEEE802.11ac規格での80+80MHzチャネル拡張(図33)のように予め定義してあるという制限を設けなくてもよい。

0060

なお、後方互換を考慮し、レガシーの端末にNAVを張らせるためには、このduplicatePPDUは、レガシーの端末で復号可能な方式で送信されるのが望ましい。例えば、IEEE802.11n規格で新規に規定されたPHYフォーマットは、HTフォーマットと呼び、それ以前のIEEE802.11a規格やIEEE802.11g規格で規定されたPHYフォーマットは、non−HTフォーマットと呼ぶ。IEEE802.11n規格やIEEE802.11ac規格では、duplicate PPDUはnon−HTフォーマットで送信され、これをnon−HT duplicate PPDUと呼んでいる。

0061

例えば、図1のアンテナ80及びアナログ処理部70では、ch.1とch.2の信号を別々に受信し、PHY処理部50で夫々の信号が入力されると、duplicatePPDUであると判断する。PHY処理部50は、受信処理部40にMACフレームとしてPPDUのペイロードを入力する際に、duplicate PPDUであることを通知する。例えばIEEE802.11規格(IEEE802.11n規格やIEEE802.11ac規格など一連拡張規格を含む)を参照するなら、物理層からMAC層へMACフレームの入力を開始する際に、PHY−RXSTART.indicationというPHY−SAPサービスプリミティブを用いるが、その中にRXVECTORというパラメータを入れて渡す。そのRXVECTORで、duplicate PPDUであるか否かを通知するパラメータを定義して用いればよい。図32図33のように無線通信システム(BSS)として拡張チャネルの取り方を予め定義してあり、必ず基準チャネルをベースに拡張チャネルを広げていく方法であれば、duplicate PPDUとしてのチャネル幅の情報をRXVECTORに入れて、受信処理部40に通知する。よって、このような方法で足りる。

0062

しかし、基準チャネルを基準にせずに、その時々で拡張チャネルを、複数のチャネル候補から判断して使用する場合には、duplicateとしてどの2つ以上のチャネルを組み合わせて用いたものであるかを知る必要がある。このために、PHY処理部50により使用していると判断されたチャネルの情報(例えばチャネル番号、図4の場合は、ch.1とch.2となる)も合わせて、受信処理部40に通知できるようにパラメータを定義して用いなければならない。もしくは、受信処理部40で、CCAの情報と組み合わせて、duplicateとしてどの2つ以上のチャネルを組み合わせて用いたものであるかを判断する必要がある。具体的に、同時にCCAがビジーであると通知されたチャネルがどこかという情報と、duplicatePPDUを受信したというRXVECTORに基づく情報により、どの2つ以上のチャネルかを判断する必要がある。PHY処理部50から受信処理部40にCCAがビジーであると通知する信号は、例えばIEEE802.11規格では、PHY−CCA.indicationプリミティブに相当する。

0063

PHY−CCA.indicationプリミティブには、ビジー(BUSY)かアイドル(IDLE)を示すSTATEパラメータに加え、図32図33のようなチャネル拡張を行っている場合には、どの拡張レベルまでビジーかを示すchannel−listパラメータというものが用意されている。

0064

IEEE802.11ac規格では、このchannel−listパラメータとして定義されている変数(elementと表現されている)は、図5の矢印の左側のようになっている。channel−listパラメータには、primary、secondary、secondary40、secondary80のいずれかの値が設定される。例えば80MHzチャネル幅を用いている場合を考える。この場合には、図32図33のprimaryチャネル、secondaryチャネル、secondary40チャネルを使っているわけだが、そのうち、secondary40チャネルの領域でCCAがビジーと検出され、primaryチャネルとsecondaryチャネルではCCAがアイドルであったとする。この場合には、STATEパラメータがビジーで、secondary40をchannel−listパラメータに設定する。secondary40チャネルとprimaryチャネルの領域でCCAがアイドルであっても、secondaryチャネルでCCAがビジーであれば、STATEパラメータがビジーで、secondaryをchannel−listパラメータに設定する。secondary40チャネルとsecondaryチャネルの領域でCCAがアイドルであっても、primaryチャネルでCCAがビジーであれば、STATEパラメータがビジーで、primaryをchannel−listパラメータに設定する。しかし、この通知方法は、基準チャネルから拡張する順番が決まっており、基準チャネルを含めたどの括りまでが使用できるかを判断する場合には有効であるが、このような制約がない場合には使用できない。

0065

そこで、例えば図5の矢印の右側のように、CCAがビジーのチャネルをビットで表現できるようにする。例えば、CCAがビジーのチャネルに対応するビットに1を立てることで、どのチャネルがビジーであるかを識別できるようにする。図4に示したように、duplicatePPDUの形式でRTSフレームを受信しているときには、ch.1とch.2の両方がビジーになる。受信処理部40では、ch.1とch.2が同時にビジーであることを、図5の矢印の右側のビット表現の通知で把握し、それに伴い受信したRX−START.indicationで、duplicate PPDUを受信したことを把握すると、ch.1とch.2を用いたduplicate PPDUを受信したのだと判断できる。

0066

別の方法として、PHY−CCA.indicationプリミティブを直接、チャネルセットごとに、受信処理部40に出すようにしてもよい。そして、PHYパケットに関しては、duplicatePPDUの場合には、受信した信号を1つのPHYパケットにして扱うのではなく、個別のPPDUとして処理し、チャネルセットごとに、受信処理部40にMPDUとして渡すようにしてもよい。すなわち、RX−START.indicationについて特に言及するなら、チャネルセットごとにRX−START.indicationを出す。この場合、受信処理部40は、各チャネルセットがチャネルとどのような対応になっているのかを判断する。図4の場合、チャネルセット1がch.1に、チャネルセット2がch.2に対応していると判断する。また、受信処理部40は、チャネルセットごとに並列にMPDUを受信処理できるようにする。受信処理部40は、チャネルセットごとにNAV情報を保持できるようにしておくことが望ましい。

0067

図4に示したように、duplicatePPDUで送信されたRTSフレームを受信すると、STA101ではそのRTSフレームに対し、どのチャネルを使ってCTSフレームを送信できるのかを判断する。その際、受信処理部40は、基準チャネルに関しては、それまでに受信したフレームによるNAVの期間内かというような、1チャネルのみの利用のときにCSMA/CAで実施される判断を用いる。一方、拡張チャネル(ch.2)に関しては、duplicate PPDUで受信したRTSフレームの受信開始した時点(T_1)からある固定時間遡った時点(T_2)までの間に、拡張チャネル(ch.2)でCCAがビジーと検出されたかを確認する。つまり、受信処理部40は、拡張チャネル側については継続してCCA情報を観測しておく必要がなく、ある限られた期間のCCA情報だけを使えばよいようにしている。ここで、ある固定時間とは、例えばIEEE802.11規格でのPIFS(Point Coordination Function (PCF) InterFrame space)である。PIFSは、CSMA/CAで優先権を持ったアクセスを得るために用いられるフレーム間隔(IFS:Interframe space)である。PIFSは、応答フレームの送信やバースト送信時に用いられるSIFS(Short InterFrame Space)に、CCAを検出するための最小時間や送受信切替時間から規定されるSlot Timeを足した値として定義されている。図4では、時刻T_2からRTSの受信開始時までの間に、拡張チャネルではCCAがビジーとなっている(STA102は隠れ端末などの理由で、RTSフレーム送信前の拡張チャネルでのCCAのビジーを検知していない)。このため、受信処理部40はch.2は使用中であると判断して、ch.1のみでCTSフレームを生成するように、送信処理部30に指示を出す。そして送信処理部30は、RTSフレームを含むPHYパケットの受信を終了した時刻T_3からSIFS経過後に、CTSフレーム(図4では“CTS”と表示)をch.1から送信する。このとき、例えば送信処理部30には、受信処理部40からRTSフレームを含むPHYパケットの受信を終了した時刻T_3を、CTSフレームの送信指示とともに通知されるようにしておく。これにより、送信処理部30は、T_3からのタイミングを計って、T_3からSIFS経過後に、PHY処理部50からCTSフレームの入ったPPDUを送信するように、PHY処理部50に送信指示を出すことができる。

0068

図4の例では、基準チャネルに対し拡張チャネルが1つの場合であったが、例えば図3(b)のように、基準チャネルをch.1とし、拡張チャネルをch.2とch.3にするといったように、拡張チャネルが複数あってもよい。この場合は複数の拡張チャネルに対して、RTSフレーム受信開始のPIFS前まで遡った期間の中で、CCAがビジーになったかどうかを判断すればよい。そして、その条件でCCAがビジーでない拡張チャネルがあれば、その拡張チャネルでもCTSフレームを送信する。

0069

図4において、ch.1でSTA101から送信されたCTSフレームを受信したSTA102は、ch.2がSTA101で使えないと判断されたことを把握して、ch.1を用いて、データフレームをSTA101に送信する。このデータフレームは、図4で、“DATA(1)”と表示している。()の中の数字は宛先の下一桁を便宜的に示しているものとする。この場合は、データフレームはSTA101に送信しているので、STA101の識別番号の101の下一桁1を記載してある。STA101は、データフレームをCTSフレーム受信からSIFS後に送信する。そして図4では、STA101が正しくデータフレームを受信したことにより、データフレーム受信からSIFS後にACKフレームを送信する、というようにシーケンスが続いている。

0070

[データフレームはアグリゲーションされていてもよい。ACKフレームの代わりにBAフレームでもよい]
ここで、データフレームは、複数のMACフレームもしくは複数のMACフレームのペイロード部分連接するようになっていてもよい。前者はIEEE802.11規格ではA(Aggregated)−MPDU、後者はA(Aggregated)−MSDU(MAC service data unit)と呼ばれる。また、データフレームがA−MPDUの場合などのように、複数のMACフレームに対する応答をまとめて送信する場合には、ACKフレームではなく、BA(BlockACK)フレームが用いられる。

0071

[各チャネルのNAVを把握できるとき]
受信処理部40でチャネルセットごとにMPDUを受信処理し、NAV情報が把握できるようになっている場合は、上記のように基準チャネルと拡張チャネルの関係で動作するのではなく、NAVを把握していてかついずれか1つ正しく受信したMPDUの用いているチャネル(チャネルセットが複数の連続したチャネルをカバーしている場合は、その複数の連続したチャネルから成るチャネルセット)を、仮想的に基準チャネルにしてもよい。すなわち、そのようなチャネルを、NAV情報を利用して、RTSフレームに対しCTSフレームを応答として送信するかの判断を行う基準チャネルにする。そして、他の利用対象のチャネル(もしくはチャネルセット)を拡張チャネルのように処理する。すなわち、RTSフレームの受信開始からある固定時間遡った時点までの間にCCAがビジーであるかの判断を行う拡張チャネルにする。

0072

[duplicateの情報をMACレベルで通知する新規フレーム
なお、図4において、RTSフレームの代わりに、duplicatePPDU送信をどのチャネルを用いて行っているかの情報を通知できるような新規フレームを定義してもよい。新規フレームのフォーマットの例を、図6に示す。IEEE802.11規格では、MACフレームは、MACヘッダ部の後にフレームボディ部があり、最後にフレームボディ部の誤りを受信側で検出できるようにFCS(Frame Check Sequence)があるのが基本構成である。MACヘッダ部は、Frame Controlフィールド、Durationフィールド(前述のDuration/IDフィールドと同一。特にNAV設定のための期間が記載されている場合にDurationフィールドと表現する)、複数のアドレスフィールド図6の場合は2つのアドレスフィールド、フレームの送信先アドレスであるRA(Receiving Address、またはReceiving STA Address)とフレームの送信元アドレスであるTA(Transmitting Address、またはTransmitting STA Address))、また必要に応じ制御フィールドとからなる。アドレスフィールドにはMACアドレスが入る。IEEE802.11規格では、MACアドレスは6オクテットである。

0073

この新規フレームのフレームボディ部に、重複送信しているチャネル情報を入れるフィールドを設ける。図6ではduplicate channel informationフィールドとなっている。duplicate channel informationフィールドは、例えば1オクテット(=バイト)長、つまり8ビット長であり、各ビットがチャネルの識別子と1対1に対応している。使用しているチャネルに対応するビットに1を立て、それ以外を0にする。図6ではch.1がbit 0に、ch.2がbit 1に、…というように対応しているが、ここでのチャネルの識別子とビットの対応関係は、少なくとも無線通信システム(BSS)として共通の認識ができればどのような形でもよく、必ずしも図6の形式に従う必要はない。また、図6の例では、8つのチャネルが識別できるようになっているが、より多くのチャネルを表現したい場合は、duplicate channel informationフィールドの長さをより長くすればよい。例えば、図4のRTSフレームのように、ch.1とch.2を占有するduplicatePPDUを送信する場合には、図6の定義に従えば、bit 0とbit 1に1を立て、残りのビットに0を立てる。このようなフレームを用いれば、どのチャネルがduplicateで使われているかを、duplicate PPDUを受信した端末側の受信処理部40で判断できる。よって、duplicateで使われているチャネルのうちで、適切なチャネルを用いて応答フレームを返すことができる。

0074

図6に示した新規フレームに対する応答フレームとしては、CTSフレームを返してもいいが、図6の新規フレームに対応して、それに対応する応答フレームを新規で定義してもよい。新規に定義した応答フレームの例を、図7に示す。図7におけるduplicate channel informationフィールドは、当該応答フレームでどのチャネルを用いているかの情報を示す。図4のCTSフレームのように、応答フレームとしてch.1のみを返す場合には、図7でのduplicate channel informationフィールドのbit 0に1を立て、残りのビットを0にする。

0075

なお、図6図7のように、duplicatePPDUで送信するチャネル情報を通知する場合に、必ず基準チャネルは用いるというような規則がある場合には、基準チャネルの情報は省略して、他の拡張チャネルの情報だけを通知するのでもよい。図6および図7に示した新規フレームは、RTSフレーム、CTSフレームの代わりとして定義するなら、制御フレームに相当する。IEEE802.11規格では、フレーム種別の識別は、図6図7でのFrame Controlフィールドの中のType、Subtypeという2つのフィールドで行う。制御フレームであれば、TypeはMSB(Most Significant Bit)の表記で“01”となる。Subtypeとしては、他の制御フレームと被らないような新規値が割り当てられる。

0076

<キャリアセンス状態の把握−NAVまで情報を把握する場合>
図4で説明したキャリアセンス方法の代わりに、各チャネルセットでNAV情報まで管理して、キャリアセンスをチャネルごとに実施する場合の例を次に示す。

0077

端末の受信処理部40は、IEEE802.11規格に倣うなら、PHY処理部50からチャネルセットごとに、PHY−CCA.indicationプリミティブとRX−START.indicationプリミティブに始まるMPDU受信のための信号を受信する。そして、受信処理部40は、CCA情報と、少なくともMPDUで設定されるNAV情報に関しては、チャネルセットごとに管理する。

0078

図8では、ch.1をチャネルセット1とし、ch.2をチャネルセット2と設定しており、ある端末(便宜的にSTA101とする)に、別のある端末(これを便宜的にSTA102とする)が、ch.1とch.2を用いて、RTSフレームを送信している。このRTSフレームは、図8中で、“RTS(1)”と表示している。()の中の数字は宛先の下一桁を便宜的に示しているものとする。この場合は、RTSフレームはSTA101に送信しているので、STA101の識別番号の101の下一桁1を記載してある。

0079

しかし、STA101は、ch.2でRTSフレームに先行して、他の端末宛てのMACフレームを受信している(STA102は隠れ端末などの理由で、このMACフレームを認識していない)。その結果、STA101の受信処理部40では、ch.1すなわちチャネルセット1は、NAVが張られて(設定されて)いないが、ch.2すなわちチャネルセット2はNAVが張られて(設定されて)いると把握している状態とする。NAVは、受信したMACフレームのMACヘッダ(MAC header)に含まれるDuration/IDフィールドがDuration値として用いられている場合に、その値で規定される期間だけ、受信したフレームの終わりから設定される。

0080

ch.2でのNAVが、図8のように、CTSフレームの送信タイミングにかかっているとする。厳密には、受信処理部40でRTSフレームの受信を把握して、CTSフレームの送信判断を下す時点で、NAVが張られていると判断される状況である。すると、STA101の受信処理部40では、受信したduplicatePPDUのRTSフレームに対し、チャネル、言い換えればチャネルセットごとに、MACレベルまでのキャリアセンス(NAVに基づく仮想キャリアセンス)を実施する。この結果、ch.1ではCTSフレームを送信できること、ch.2ではCTSフレームを送信できないことを決定し、ch.1のみでCTSフレームを送信することになる。CTSフレームの送信後のフレームシーケンスはこの場合、図4と同じになる。

0081

[拡張チャネルのチャネル幅は、基準チャネルのチャネル幅の2のべき乗に限られない] 各チャネルセットで取れるチャネル幅や拡張チャネル幅は、20MHz、40MHz、80MHz、160MHzというように、20MHzの2のべき乗の幅であってもいい。ただし、これに限らず、例えば20MHzの整数倍の60MHzや100MHzの幅でもよい。

0082

本実施形態では、端末の能力(Capability)として、このようにキャリアセンスを分離して把握できるチャネルセットを、端末として同時にいくつ設定できるかを基地局が把握し、その情報をMU−MCのグルーピングに用いる。

0083

当該キャリアセンスがビジーかアイドルかの判定が行えるチャネルセットを最大で同時にいくつ持つことができるかを、便宜的に、“キャリアセンス分離能力”と表現することとする。

0084

特に、MU−MCを適用する場合、MU−MCで使う複数のチャネルは同一周波数帯域内のチャネルを基本とすることを考えると、MU−MCで使うチャネル数は、同一周波数帯域の中でキャリアセンスのビジー・アイドル把握が独立にできるチャネルセットの最大数に依存する。

0085

例えば端末は、このキャリアセンス分離能力の値をMIBに保持している。端末は、この値を管理フレームに入れて通知するときには、MAC/PHY管理部70からMAC共通処理部30に管理フレームの生成指示に、パラメータとしてこの値を入れる。別の様態としては、MAC共通処理部30にメモリを内包し、そこにこのキャリアセンス分離能力の値を保持してもよい。この場合、MAC共通処理部30が、MAC/PHY管理部70から管理フレームの生成指示を受けた場合に、この内包メモリからキャリアセンス分離能力の値を読み出し、管理フレームのフレームボディにパラメータとして入れるようにしてもよい。あるいは、MIBを保持するのとは別のメモリを設け、そこにこのキャリアセンス分離能力の値を保持してもよい。この場合、MAC共通処理部30が、MAC/PHY管理部70から管理フレームの生成指示を受けた場合に、この別のメモリからキャリアセンス分離能力の値を読み出して、管理フレームのフレームボディにパラメータとして入れるようにしてもよい。

0086

[チャネルセットとチャネルの対応関係]
図2では、キャリアセンス状態がビジーかアイドルかの判定が行えるチャネルセットを1つ、2つの連続したチャネルまたは3つの連続したチャネルをカバーするように割り当てた例を示しているが、これに限定されず、もっと多くの連続したチャネルをカバーするようにチャネルセットを割り当ててもよいし、もっと多くのチャネルセットをチャネルに別個に割り当ててもよい。

0087

例えば、2つのチャネルセットを複数のチャネル上に割り当てた例を図9に示す。キャリアセンスのビジーかアイドルかの判定が行えるチャネルセットを2つまで持つことができる(つまりキャリアセンス分離能力が2の場合)。。無線通信システム(BSS)で利用できるチャネルが8つあるとして、例えば図9(1)のように、4チャネルずつをそれぞれ1つのチャネルセットでカバーしてもよいし、図9(2)のように、各チャネルセットでそれぞれカバーするチャネルの数が異なるようにしてもよい。また図9(3)のように、2つのチャネルセットでカバーするチャネルを無線通信システムで利用できるチャネルの一部に限定してもよい。さらに図9(4)のように、チャネルセット間に1つまたは複数の他のチャネルが介在することにより、各チャネルセットが互いに分離されていてもよい。端末は、キャリアセンス分離能力H(Hは1以上の整数)に応じて、H個もしくはそれ以下の個数のチャネルセットを、それぞれ任意に1つまたは複数の連続するチャネルに割り当てることができるように構成されていてもよい。あるいは、端末は、H個もしくはそれ以下の個数のチャネルセットを、特定の割り当てパターンでのみ、チャネルに割り当てることができるように構成されていてもよい。

0088

<非基地局である端末から基地局への通知方法>
非基地局の端末は、上記キャリアセンス分離能力の値を、接続する基地局に通知する。

0089

IEEE802.11規格では、基地局が中心となり構成するBSS(これをインフラストラクチャ(Infrastructure)BSSと呼ぶ)に、非基地局の端末が加入し、BSS内でデータフレームの交換ができるようになるために経る手順(procedure)が、段階的に複数規定されている。当該複数の手順では、制限された管理フレームの送信と、その管理フレームへの送達確認応答としてACKフレームを送信することが許されている。ただし、ACKフレームの送信が許される管理フレームは、単一の端末のアドレス送信宛先として指定するユニキャスト(unicast)フレームとする。そこで、上記キャリアセンス分離能力の値を、非基地局の端末が、接続する基地局に通知するために、これらの手順の中で、非基地局の端末が、基地局宛てに送信する管理フレームのうちの1つに、上記キャリアセンス分離能力の値を入れることができる。すなわち、端末の無線通信装置の通知手段は、管理フレームにキャリアセンス分離能力の値を入れることにより、接続する基地局に当該分離能力の値を通知する。端末の無線通信装置の送信処理部30はこのような通知手段を含む。なお、端末が、当該H個もしくはそれ以下の個数のチャネルセットを、1つまたは複数の特定の割り当てパターンでのみ、設定できる場合に、当該送信処理部30の通知手段は、その特定の割り当てパターンの情報を管理フレームに入れることにより、接続する基地局に当該情報を通知してもよい。

0090

[使用するフレームの例]
例えば、アソシエーション(Association)という手順があり、非基地局の端末から、接続を要求する基地局に対して、アソシエーション要求(Association Request)フレームを送信する。基地局は、アソシエーション要求フレームに対するACKフレーム送信後、アソシエーション要求フレームに対する応答フレームのアソシエーション応答(Association Response)フレームを送信する。そこで例えば、端末はアソシエーション要求フレームの中にキャリアセンス分離能力の値を入れて送信する。

0091

当然、他の基地局へ再接続するための再アソシエーション(reassociation)という手順にもこの通知を入れるようにしてもよい。この手順では、非基地局の端末から、再接続を要求する他の基地局に対して、再アソシエーション要求(Reassociation Request)フレームを送信する。当該他の基地局は、再アソシエーション要求フレームに対するACKフレーム送信後、再アソシエーション要求フレームに対する応答フレームの再アソシエーション応答(Reassociation Response)フレームを送信する。そこで、端末は再アソシエーション要求フレームの中に、キャリアセンス分離能力の値を入れて送信する。

0092

以降、アソシエーション要求フレームの中に端末のキャリアセンス分離能力の値を入れる方法について記載するが、再アソシエーション要求フレームであっても、他の管理フレームであっても、同様に適用できる。

0093

[キャリアセンス分離能力の通知用のフィールドを設ける]
例えばアソシエーション要求フレームのフレームボディ中に、キャリアセンス分離能力の値を通知するための新規情報エレメント(Information Element)を追加する。

0094

この新規情報エレメントは、例えばMU−MCに関する端末の能力(Capability)を通知するためのものとする。その場合、例えば新規情報エレメント名はMU−MC Capabilitiesとし、図10のようなフォーマットとする。図10での“Element ID”フィールドは、この新規情報エレメントに固有の値を割り当てる。“Length”フィールドは、続く“Maximum Carrier Sense Partitioning Sets”フィールドのオクテット長を表す。

0095

なお、IEEE802.11規格で情報エレメントは、“Element ID”フィールドと、“Length”フィールドと、“Length”フィールドに続くフィールドで定義されている。“Length”フィールドに続くフィールドは、一般的に情報(Information)フィールドと表現される。“Length”フィールドは、この情報フィールドの長さを示す。ここでは“Maximum Carrier Sense Partitioning Sets”フィールドは、例えば1オクテット長としているので、“Length”フィールドには1という値が入る。

0096

“Maximum Carrier Sense Partitioning Sets”フィールドに、キャリアセンス分離能力の値を入れる。例えば、キャリアセンス分離能力が1であれば1を、2であれば2を、…というように、このフィールドに値を入れる。あるいは、端末としてキャリアセンス分離能力は最低でも1はあり、0のときの値を有意にするため、キャリアセンス分離能力が1であれば0を、2であれば1を、…というように、キャリアセンス分離能力−1の値を、このフィールドに入れるようにしてもよい。あるいは、例えば無線通信システムあるいは規定あるいは仕様として、端末のキャリアセンス分離能力を2のべき乗になるように指定するのであれば、このフィールドの値が0の場合はキャリアセンス分離能力が1、1の場合はキャリアセンス分離能力が2、2の場合はキャリアセンス分離能力が4、…というようなルールを作り、このルールに従った値を入れるようにしてもよい。

0097

いずれにせよ、表現できるキャリアセンス分離能力の最大値は“Maximum Carrier Sense Partitioning Sets”フィールドの長さに制限される。よって、無線通信システムあるいは規定あるいは仕様として許容するキャリアセンス分離能力の最大値を表すことができるように、当該フィールドの長さを設定する。そして、指定された当該フィールドの長さが、無線通信システムあるいは規定あるいは仕様として許容するキャリアセンス分離能力の最大値よりも大きい値を表現できるようになっている場合には、当該許容するキャリアセンス分離能力の最大値以上のフィールド値に対しては、将来の利用拡張のために予約(Reserved)としておいてもよい。

0098

[CCAおよびNAV別のキャリアセンス分離能力に関する通知]
ここで、キャリアセンス分離能力とは、PHYレベルでCCAでキャリアセンスを分離できる能力でもよいし、MACレベルでNAVまでキャリアセンスを分離できる能力でもよい。

0099

そのどちらも、無線通信システムあるいは規定あるいは仕様として許容するのであれば、例えばどの程度まで端末がその分離能力としてサポートするかに関する情報も、そのような情報が通知先で識別できるように表せるようにしてもよい。

0100

例えば、キャリアセンス分離能力を通知する情報エレメントのフォーマットを、図10の代わりに図11のようにする。ここでは例えば“Maximum Carrier Sense Partitioning Sets”フィールドの代わりに“Carrier Sense Partitioning Capabilities”フィールドとしている。さらにそのフィールド中を、キャリアセンス分離能力の値を通知する“Maximum Carrier Sense Partitioning Sets”サブフィールドと、“CCA/NAV”サブフィールドに分けている。“CCA/NAV”サブフィールドでは、端末で各チャネルセットでキャリアセンスがCCAで実施できるときは、例えば0を設定し、端末で各チャネルでNAVレベルまでキャリアセンスを実施できるときは1を設定する。図11では、“Maximum Carrier Sense Partitioning Sets”サブフィールドは3ビット、“CCA/NAV”サブフィールドは1ビットにしており、残りの部分をReservedにしているが、サブフィールドの割り当ては、これに限らない。

0101

[MU−MCの対応通知と合わせてキャリアセンス分離能力を通知する]
キャリアセンス分離能力の通知は、端末がMU−MCに対応する場合に行うようにしてもよい。すなわち、端末がMU−MCに対応しない場合は、キャリアセンス分離能力を通知しないようにしてもよい。

0102

MU−MCに対応することの通知には、例えばアソシエーション要求フレームや再アソシエーション要求フレームに入れられる“Extended Capabilities”エレメントを用いる。“Extended Capabilities”エレメントは、図12のようになっている。“Capabilities”フィールドは可変長であり、Bit 0から順次(一部Reservedとなるビットも許す)各種能力の通知が割り当てられている。通知したい能力に応じて、必要な長さまで入れるようになっている。そこで現状Resevedとなっているあるビットを、MU−MCに対応するか否かを示すために用いることができる。例えば、このビットをMU−MCに対応しない場合は0とし、MU−MCに対応する場合は1とする。

0103

エレメントでMU−MCに対応するとの通知をする場合には、図10または図11に示したように、キャリアセンス分離能力を通知するための新規エレメントを、アソシエーション要求フレームや再アソシエーション要求フレームに別途追加する。

0104

あるいは、“Extended Capabilities”エレメントの中で、MU−MCに対応可否を示すビットに加え、キャリアセンス分離能力に関する情報も、ビットフィールドとして定義してもよい。MU−MCに対応するとの通知を行う場合に、それらのビットフィールドの値も有効となるようにしておけばよい。

0105

あるいは、図13のように、MU−MCの対応可否とキャリアセンス分離能力に関する情報を合わせて通知する新規情報エレメントを、定義するようにしてもよい。例えば、この新規情報エレメントを、同時送信機能に関して通知するエレメントとし、その情報フィールド(図13では“Simultaneous Transmission Capabilities”と示されている部分)の一部を、MU−MCの対応可否とキャリアセンス分離能力に関する情報の通知に使う。Bit 3(4ビット目)の“MU−MC”サブフィールドが、MU−MCの対応可否を示し、MU−MCに対応しない場合は0とし、MU−MCに対応する場合は1とする。Bit 4−6(5−7ビット目)の3ビットに割り当てた“Maximum Carrier Sense Partitioning Sets”サブフィールドと、Bit 7(8ビット目)に割り当てた“CCA/NAV”サブフィールドは、図11と同様の定義である。

0106

“MU−MC”サブフィールドは、ダウンリンク(Downlink:DL)対応か、アップリンク(Uplink:UL)対応かを識別できるように、2ビット用意するようにしてもよい。また、図13の情報フィールドでReservedと示されているサブフィールドには、例えばMU−MIMO(Multi−User Multiple Input,Multiple Output)に関する情報を入れるようにしてもよい。例えば、MU−MIMOに関連する能力を通知するため、情報フィールドが1オクテットでは足りない場合には、オクテット長を伸ばすようにしてもよい。

0107

[規格上、デフォルトの分離能力までなら通知せず、それ以上のときに通知する例]
なお、上記で扱った情報のうち、他の情報を通知することで、その情報が必須となるものがあれば、通知を省略できる。例えば、ある新しい規格あるいは仕様に対応する能力を定義し、それに対応していれば自ずとMU−MCには対応できる、というのであれば、MU−MCの通知をしなくてもよい。また、ある新しい規格あるいは仕様に端末が対応していれば、キャリアセンス分離能力としてデフォルトで2以上は対応できなければならない、というときには、キャリアセンス分離能力の値を通知するフィールドで、3以上が表現できるようになっていてもよい。

0108

<基地局からのMU−MC対応通知>
ここで図14のように、1つの基地局(AP:Access Point)100が、複数の非基地局である端末(STA:STAtion)101〜108と、無線通信システムあるいは無線通信グループ(BSS)1を構成しているとする。このBSS1で、AP100は、少なくともMU−MCが有効な状態にしてあるとする。また実際に、一部の複数の端末との間で、AP100は、MU−MCを実施していてもよい。MU−MCは、例えばダウンリンク(DL−MU−MC)に限定されていてもよい。つまり、基地局から複数のチャネルを用いて、一部の複数の端末宛てにPPDUを送信する方向に限定されていてもよい。その場合、以降の説明でのMU−MCを、DL−MU−MCに読み替える。MU−MCがアップリンク(UL−MU−MC)に限定される場合も、同様である。ここでは、一部の複数の端末へのDL送信時にPPDUを同時に送信する場合を示すが、送信するタイミングは同時に限定されるものではなく、端末ごとに独立したタイミングで送信することを排除するものではない。

0109

AP100の構成は図1と同様であるか、もしくは図1の上位処理部90を介して有線インフラに接続するようになっていてもよい。すなわち、AP100は、STA101〜108と形成するネットワークとは別のネットワークに接続されてもよい。なお、複数の端末へのフレーム送信、また複数の端末からのフレーム受信を行うため、図1のPHY処理部50とMAC処理部10(複数の端末へのフレーム送信の場合には特に送信処理部30、複数の端末からのフレーム受信の場合には特に受信処理部40)が、各々複数の端末宛てもしくは複数端末からのPPDU、MPDUを処理できるようになっている必要がある。

0110

AP100は、例えばMIBで、AP100自身がMU−MCに対応できることを情報として保持している。このMIBは、例えば、dot11MuMcOptionImplementedであり、その値が“TRUE”となっている(MU−MCに対応していないときはこのMIBは存在しないか、あるいは値が“FALSE”となっている)。前述の非基地局である端末も、例えばこのMIBを持っていて、MU−MCへの対応可否が、同様に設定されているものとする。

0111

AP100は、dot11MuMcOptionImplementedが“TRUE”であると、例えばさらにMU−MCが使える状態(有効な状態)になっているか否かを示すMIBを持っている。これは例えば、dot11MuMcOptionEnabledとし、MU−MCが有効な状態になっていれば“TRUE”、有効でない状態は“FALSE”となる。AP100は、このdot11MuMcOptionEnabledが“TRUE”である場合に、送信処理部30で生成する管理フレームであるビーコンフレームに、MU−MCが可能な旨を情報として入れる。

0112

ビーコンフレームにMU−MCが可能な旨を情報として入れる方法としては、前述のアソシエーション要求フレームなどを例にした場合と同様に、ビーコンフレームのフレームボディ中に、適当な情報エレメントを入れればよい。情報エレメントは、例えば前述のように、“Extended Capabilities”エレメントとして、そこに新規定義を追加するようにしてもいいし、あるいは新規情報エレメントを定義するようにしてもよい。

0113

またAP100は、dot11MuMcOptionEnabledが“TRUE”である場合に、送信処理部30で生成する管理フレームのプローブ応答(Probe Response)フレームに、MU−MCが可能な旨を情報として入れるようにしてもよい。プローブ応答フレームは、管理フレームのプローブ要求(Probe Request)フレームを、ビーコンフレームを送信する端末(インフラストラクチャBSSの場合には基地局)が受信し、当該端末が、プローブ要求フレームで要求される条件に合致したBSSを構成している場合に、受信したプローブ要求フレームへの応答として送信するフレームである。AP100の受信処理部40が、プローブ要求フレームの受信を把握すると、MAC共通処理部20にプローブ要求フレームを受信した旨と、当該プローブ要求フレームボディに記載された内容を通知する。MAC共通処理部20は、プローブ要求フレームに対しプローブ応答フレームを送信すると判断した場合には、プローブ応答フレームの送信指示を、送信処理部30に出力する。送信処理部30は、プローブ要求フレームの送信元端末のアドレス(TA。なお管理フレームの場合にはMACフレームで運ぶデータはすなわち管理フレームのフレームボディであるためTAはデータの送信元アドレスであるSource Address(SA)と同じ。)を送信先アドレス(RA。なお管理フレームの場合にはMACフレームで運ぶデータはすなわち管理フレームのフレームボディであるためRAはデータの送信先アドレスであるDestination Address(DA)と同じ。)に設定したプローブ応答フレームを生成し、プローブ応答フレームの送信指示を、PHY処理部50に出力する。

0114

ビーコンフレームは、報知フレームであり、つまりビーコンフレームの送信先アドレス(RA)は、ブロードキャストアドレスである。一方、プローブ応答フレームのRAは、ある端末のアドレスを指定するユニキャストアドレスである。RAは、MACフレームの先頭に設けられるMACヘッダ部の複数のアドレスフィールドの先頭に設定される。

0115

なお、ビーコンフレームやプローブ応答フレームは、BSSの属性を示すために送信されるものである。BSSの属性は、それを送信する端末自身の能力や属性をベースに決められるものではあるものの、ビーコンフレームとプローブ応答フレームで通知される属性は、そのフレームを送信する端末自身の個々の能力や属性とは異なるものである。

0116

上記では、AP100はdot11MuMcOptionEnabledが“TRUE”である場合に、ビーコンフレームまたはプローブ応答フレームに、MU−MCが可能な旨を情報として入れることを示した。別の方法として、MU−MCに対応できることは、MU−MCが使える状態にあるとして、MIBを、例えばdot11MuMcOptionImplementedとdot11MuMcOptionEnabled属性のうち、dot11MuMcOptionImplemented属だけを保持するようにしてもよい。そのような場合、dot11MuMcOptionImplementedが“TRUE”である場合に、ビーコンフレームまたはプローブ応答フレームに、MU−MCが可能な旨を情報として入れるようにしてもよい。

0117

<基地局からのビーコン/プローブ応答でのMU−MC通知に呼応して通知>
例えば図14で、STA109がBSS1に加入する際に、AP100が送信するビーコンフレームまたはプローブ応答フレームを受信する。STA109は、そのフレームの中でMU−MCが可能な旨が通知されていることを把握すると、前述のキャリアセンス分離能力の値をアソシエーション要求フレームに入れて通知する。より詳細には、STA109の無線通信装置の送信処理部30が、キャリアセンス分離能力の値を含むアソシエーション要求フレームを、AP100に送信する。

0118

<基地局でのグルーピング候補生成>
[基地局でのキャリアセンス分離能力の収集]
図14で、AP100が、STA109からアソシエーション要求フレームを受信すると、MAC/PHY管理部60が、当該STA109からのアソシエーション要求を受け付けるか否かを判断する。そして、その判断の結果をアソシエーション応答フレームに入れて送信するように、MAC共通処理部20を介して送信処理部30に指示を出す。その判断の結果は、IEEE802.11規格では、アソシエーション応答フレームのフレームボディ中に入れられるステータスコード(Status Code)フィールドに示される。当該STA109からのアソシエーション要求を受け付ける場合には、ステータスコードフィールドには、成功であること(successful)を示す値0が入れられる。当該STA109からのアソシエーション要求を受け付けない場合には、受け付けない理由などを示す不成功(failure)のコードが、値1以上で定義されており、そのいずれかの適当な値を入れる。

0119

STA109からのアソシエーション要求を受け付ける場合、AP100ではアソシエーション要求フレームから、STA109の送信元アドレス(ここではすなわちSTA109のMACアドレス)と、STA109の情報を抽出し、保持しておく。抽出するSTA109の情報は、キャリアセンス分離能力の値を含む。抽出処理は、例えば、MAC/PHY管理部60で行い、MAC/PHY管理部60から書き込みができる記憶領域に、抽出した情報を保持するようにしてもよい。この場合、STA109のMACアドレスはAP100内でアソシエーション要求を受け付けた場合に便宜的に各端末(この場合STA109)に割り当てる識別子(例えばIEEE802.11規格でのAID(Association ID))に変換して保持するようにしてもよい。AIDは1から2007までの値となっているため、11ビットまでで表現可能であり、MACアドレスの6オクテットよりも少ない情報量で表現することができるため、記憶容量を減らすことができる。また、この抽出処理は、MAC/PHY管理部60でアソシエーション要求を受け付けるか否かの判断を下す前に、予め受信処理部40で行って、受信処理部40から書き込める記憶領域に保持してもよい。その場合、MAC/PHY管理部60でアソシエーション要求を受け付けないと判断された際には、MAC共通処理部20が当該記憶領域にアクセスし、該当する端末の情報を削除する。MAC/PHY管理部60でアソシエーション要求を受け付けると判断した際には、MAC共通処理部20が当該記憶領域にアクセスし、該当する端末のMACアドレスを端末ごとにAP100内で便宜的に割り当てた識別子(例えばAID)に置き換えるようにしてもよい。いずれにせよ、端末の情報を保持する記憶領域では、各端末の情報が、例えば端末のMACアドレス、またはAP100内で各端末に便宜的に割り当てた識別子(例えばAID)と紐付されていればよい。これにより、端末のMACアドレスまたはAP100内で各端末に便宜的に割り当てた識別子を指定すれば、該当する端末の情報が抽出できる。端末の情報を保持する記憶領域は、前述のMIBと同じ領域でもよい。

0120

[MU−MCに対応しない端末(STA)が混在する場合]
例えば、キャリアセンス分離能力の通知ができない端末、あるいはMU−MCに対応しないレガシーの端末からアソシエーション要求フレームを受信した場合には、AP100は、当該端末のキャリアセンス分離能力の値を1として記憶するようにしてもよい。

0121

例えば、IEEE802.11ac規格の80+80MHzチャネル拡張(図33参照)に対応できることを、アソシエーション要求フレームで端末(STA)が通知してきた場合には、AP100は、当該端末のキャリアセンス分離能力の値を2として記憶するようにしてもよい。なぜなら80+80MHzチャネル拡張に対応できるということは、secondary80をprimaryチャネルを含む連続した80MHzチャネルとは非連続に設定可能であることを意味し、チャネルセットを2つ持てると解釈できるからである。VHTCapabilitiesエレメントの中のSupported Channel
Width Setサブフィールドが2である場合に、160MHzチャネル幅とともに80+80MHzチャネル幅にも対応することを意味し、この場合が該当する。

0122

CCAレベルまでのキャリアセンス分離能力なのか、NAVレベルまでのキャリアセンス分離能力なのかの情報も、AP100で保持する場合には、レガシーの端末に関しては、CCAレベルまでのキャリアセンス分離能力に対応するとして、情報を保持するようにしてもよい。

0123

基地局自身のキャリアセンス分離能力の保持]
AP100では、自端末としてのキャリアセンス分離能力の値も、例えばMIBで保持しているとする。AP100は、自端末としてのキャリアセンス分離能力に合わせて、MU−MCで用いるチャネルの数を選択する。例えば、AP100のキャリアセンス分離能力の値を8とする。その場合には、MU−MCで用いるチャネルの数は、8以下で選択することが望ましい。このようにすることで、例えば、各チャネルにそれぞれ、キャリアセンス状態がビジーかアイドルかの判定が行えるチャネルセットを割り当てることで、各チャネルのキャリアセンス情報を分離できる。よって、一部のチャネルが信号または雑音により使えない状態であっても、その一部のチャネルを除いて、効率的に通信を実現できる。AP100は、自端末としてのキャリアセンス分離能力に加えて、例えば各チャネルでのトラヒック量を加味して、MU−MCで用いるチャネルの数やチャネルセットのチャネルへの割り当てを行うようにしてもよい。例えば一部のチャネルが、1つまたは複数の他のBSS(OBSS:OverlappingBSS)にも利用されているなどによりチャネル利用が混雑していれば(つまりチャネルが占有される割合が高ければ)、その一部チャネルについては各チャネルにそれぞれチャネルセットを割り当てるようにし、他の比較的空いている(つまり占有される割合が低いチャネル)チャネルについては複数の連続したチャネルを1つのチャネルセットでカバーするようにする。これにより、AP100のキャリアセンス分離能力以上のチャネル数をMU−MCに用いることができ、また他の端末との間で用いるチャネル幅をより広く割り当てられることでより高速伝送レートを用いたデータフレームの交換ができる。

0124

[端末のグルーピング]
AP100では、配下の端末のキャリアセンス分離能力の情報を、例えば図15のように把握しているとする。

0125

AP100では、これらの配下の端末のキャリアセンス分離能力の情報を利用して、MU−MCを実施する際の、AP100が同時にフレームを送信する端末のグループ、またはAP100が同時にフレームを受信する端末のグループの候補を決める。この処理は、AP100のMAC/PHY管理部60が行う。

0126

例えば、図16のように、BSS1でMU−MCとして使用するチャネルを、最大でch.1からch.8の8チャネルとする場合を考える。この場合、できるだけ、選択する端末のキャリアセンス分離能力の値の和が、使用する最大のチャネル数と同じになるように、同一グループとして端末を選択する方法がある。グループは、MU−MCを行う端末をすべて網羅できるように生成する。後述するように、異なるグループ間で同じ端末が含まれることを許容してもよい。グループは予め静的に生成し、MU−MCを行う対象となる端末に変更が生じるごとに再作成してもよい。あるいは、MU−MCのダウンリンク(またはアップリンク)の通信を行う都度、あるいは一定時間間隔ごとに、グループを生成することも可能である。各グループ内での各端末には、当該端末のキャリアセンス分離能力の値と同一のチャネル数を割り当てることが好ましい。このようにすれば、各端末で割り当てられた各チャネルで、キャリアセンス状態がビジーかアイドルかの判定を行うことができ、一部のチャネルが信号または雑音により使えない状態であっても、その一部のチャネルを除いて、効率的に通信を実現できる。

0127

図16では、グループ1をキャリアセンス分離能力3のSTA101、キャリアセンス分離能力2のSTA103、キャリアセンス分離能力3のSTA104の3端末とし、各々に、そのキャリアセンス分離能力の値分のチャネルを割り当てている。同様にグループ2は、STA106、STA107、STA108とし、グループ3はSTA102、STA105、STA109としている。例えば、グループ1のSTA101では、ch.1、ch.2,ch.3を割り当てられており、それぞれにチャネルセットを割り当てることで、ch.1、ch.2,ch.3を別々にキャリアセンスしてビジーかアイドルかの判定を行うことができる。一部のチャネル、例えばch.1が、信号または雑音により使えない状態であっても、ch.2,ch.3を用いて通信を行うことができる。

0128

図16では、各端末に割り当てるチャネルは、連続したチャネルとしているが、必ずしも連続でなくてもよい。例えばキャリアセンス分離能力2のSTA103に対して、図17のようにch.1とch.5を割り当てるようにしてもよい。端末によって、無線環境に応じてチャネルを分離して割り当てた方が、好適な場合もあると考えられるためである。

0129

実際にMU−MCを実施する際には、そのMU−MCで使用するグループを、AP100は選択することになるが、必ずしも選択したグループ内の全ての端末との間でMU−MCを実施しなくてもよい。図16で選択した同一グループ内の端末は候補であり、該当グループが選択された場合に、絶対にMU−MCでのフレームの送信先またはフレームの送信元になるとしなくてもよい。AP100が、MU−MCを実施するために使用するグループを選択したときに、当該グループ内の対象となる端末を制限してもよい。またはMU−MCを実施したい端末の要求を、別途当該端末から受信した際に、その要求を最も満足するグループを選択し、グループの中で要求を行った端末に、MU−MCを実施してもよい。このような場合には、MU−MCの実施で使用する各端末に割り当てるチャネルは、MU−MCの実施中よりも、MU−MC開始時に通知した方が、融通が利いていいとも考えられる。

0130

[グループ内の端末のキャリアセンス分離能力の和は、基地局自身のキャリアセンス分離能力値以下]
MU−MCで用いる最大のチャネル数を、AP100のキャリアセンス分離能力の値以下として選択している場合には、各グループで選択する端末のキャリアセンス分離能力の値の和が、AP100自身のキャリアセンス分離能力の値以下となる。

0131

あるいは例えば、図18のように、MU−MCとして使用する最大のチャネル数はch.1からch.8の8つだが、必ずしも各グループで各端末に割り当てるチャネルの合計が、8に一致しなくてもよい。また、前述したように、同一の端末が複数のグループに属することを許容してもよい。図18では、STA106はグループ1とグループ2に属している。この場合も、各グループで選択する端末のキャリアセンス分離能力の値の和が、AP100自身のキャリアセンス分離能力の値以下となる。

0132

[キャリアセンス分離能力以下の個数のチャネルを割り当て]
図16図18では、端末のキャリアセンス分離能力と同一のチャネル数を端末に割り当てる例を示したが、端末のキャリアセンス分離能力よりも少ない数のチャネルを割り当てることでも、チャネルの効率的な利用は確保される。この場合、キャリアセンス分離能力の高い端末の方が、よりチャネル割り当てに柔軟性があることになり、より多くのグループに属することができる。

0133

[グループに関する情報の通知]
このように生成したグループとそれに属する端末、そして場合によってはグループ内で各端末に割り当てたチャネルに関する情報を、MU−MCを実施する前に、MU−MCを実施する対象である端末に予め通知してもよい。これにより例えば、端末側では、MU−MC開始の際に、基地局からグループが指定されただけで、自端末がMU−MCの対象になる、あるいは対象になる可能性がある、と把握でき、通信準備ができるなどのメリットがある。端末は(後述のように少なくとも待ち受けでは)割り当てられた各チャネルに各チャネルセットを割り当てることが前提となっていてもよいし、また基地局がグループ内で各端末に割り当てたチャネルを通知する際に、チャネルセットとチャネルの対応をどうするかの指示を出すようにしてもよい。その指示の際、非連続のチャネルを端末に割り当てる場合には非連続のチャネル間は異なるチャネルセットを割り当てることを暗黙の条件として省略することもできる。グループに関する情報は、MU−MCを実施する対象である複数端末だけを送信先とする(つまり送信先がマルチキャストアドレス)か、ブロードキャストの管理フレームで通知するのが効率がよい。例えば、ビーコンフレームに当該情報を入れるようにしてもよいし、必要に応じて通知が適宜行えるように、新規の管理フレームなどを定義して用いる方法でもよい。当該情報をビーコンフレームに入れる場合でも、新規管理フレームに入れる場合でも、当該情報は管理フレームのフレームボディの中に入れられることになり、IEEE802.11規格に基づく管理フレームならば、前述の情報エレメントを利用すればよい。

0134

なお、作成したグループとそれに属する端末の情報として、端末のMACアドレスを通知するようにすると、前述のようにMACアドレスが6オクテットの場合、情報を示すフィールドが長くなってしまう。そこで、MACアドレスよりも短い識別子が各端末に割り当てられており、かつ割り当てられた識別子を、各端末が把握できている場合には、MACアドレスの代わりに、当該識別子を用いる方が効率がよい。IEEE802.11規格では、前述のように、AIDが、基地局下のBSSの各端末に割り当てられている。さらに、各AIDを、個別のフィールドで通知するよりも、複数のAIDを同時に通知する方が効率がよい。例えば、IEEE802.11規格でのTIM(Traffic IndicationMAP)エレメントのPartial VirtualBitmapフィールド記述方法を利用すればよい。

0135

図19に、各グループとそれに属する端末を通知する情報エレメントの例を示す。これを例えば、MU−MC Groupエレメントとする。この情報エレメントのフィールド部は、252オクテットの1以上の整数(n)倍となっている。252オクテットごとに、各グループとそれに属する端末を通知する。各252オクテットの前半1オクテットは、“MU−MC Group ID”サブフィールドで、各グループの識別子を示す。例えば、グループの識別子を1、2、…と順に割り当てるようにする場合には、グループ識別子が1のグループについては“MU−MC Group ID”サブフィールドは1を、グループ識別子が2のグループについては“MU−MC Group ID”サブフィールドは2を、…というように設定する。“MU−MC Group ID”サブフィールドに各グループ識別子を設定した後ろには、251オクテット長の“AID Bitmap”サブフィールドが続く。“AID Bitmap”フィールドは、ビット位置がAIDを示すようになっており、あるグループに選択された複数の端末のAIDが表現されるようになっている。AIDは1から2007まで割り当てられ、“AID Bitmap”サブフィールドとしては251オクテット、すなわち2008ビットまで表現できるようになっている。このため、AID=1の端末は“AID Bitmap”サブフィールドのBit 1の位置を、AID=2007の端末は“AID Bitmap”サブフィールドのBit 2007の位置を見ることで、自端末が、“MU−MC Group ID”サブフィールドで指定されたグループに属しているかを判断できる。各グループ内で各端末に割り当てるチャネルに関する情報の通知、また各端末におけるチャネルセットとチャネルの対応指示は、この各グループとそれに属する端末を通知する情報エレメントを通知した後に、各グループに係る情報として別途新規の情報エレメントを用いるようにしてもよいし、この各グループとそれに属する端末を通知する情報エレメントの中に入れるようにしてもよい。

0136

図19の代わりに、“MU−MC Group ID”サブフィールドを省略して、251オクテットごとに、AID Bitmapを配置し、先頭側から自動的に、グループ1、グループ2、…に割り当てられるとしてもよい。また“MU−MC Group ID”サブフィールドの代わりに、“Simultaneous Transmission Group ID”サブフィールドとしてもよい。その場合、サブフィールドの領域を分割して、例えば、グループ識別子は2ビットだけで十分とするなら、残りの6ビットの領域の全てまたは一部を、同時送信方法の識別情報を入れるようにしてもよい。この場合、情報エレメントの名前としては、MU−MC Groupエレメントの代わりに、例えばSimultaneous Transmission Groupエレメントとなる。例えば、同時送信方法として、MU−MCだけでなくMU−MIMOもあるとする場合、このグループが両方に適用されるグループなのか、MU−MCだけの場合なのか、MU−MIMOだけの場合なのかという識別情報を入れることが、考えられる。

0137

また、“AID Bitmap”サブフィールドとして、251オクテット用意したのは、AIDの最大値である2007までを表現するためである。したがって、実際に対象とする端末のAIDが最大値まで行かない場合には、通知したいAIDの最大値までのフィールド長でよい。このフィールド値が、そのときどきで変わる可能性がある場合には、前述の“MU−MC Group ID”もしくは“Simultaneous Transmission Group ID”サブフィールドの一部を用いて、続く“AID Bitmap”サブフィールド長を通知するようにすればいい。“AID Bitmap”サブフィールド長を通知するために、“MU−MC Group ID”もしくは“Simultaneous Transmission Group ID”サブフィールド長の長さが足りない場合には、それが表現できるように、“MU−MC Group ID”もしくは“Simultaneous Transmission Group ID”サブフィールド長を、1オクテット長から長く拡張してもよい。ただし、少なくとも“MU−MC Group ID”もしくは“Simultaneous Transmission Group ID”サブフィールド長は、可変長ではなく、固定長であるべきである。

0138

また、対象の端末が、そもそもグループの少なくともいずれか1つに割り当てられているか否かを示すサブフィールド(“AID Bitmap”と同じフォーマットでよい)を、“MU−MC Group ID”もしくは“Simultaneous Transmission Group ID”サブフィールドの前に、設けておくのでもよい。こうすれば、該当する端末だけが、残りのフィールドを処理すればよいことになる。

0139

レガシー端末割り当てチャネル
なお、各端末にチャネルを割り当てる際に、BSS1として基準チャネルが固定であることを要求し、かつ、MU−MCを認識できないようなレガシーの端末を収容する場合に、そのレガシーの端末を含むグループに対して、DL−MU−MCを実施することは可能である。このような場合には、レガシーの端末に通知している基準チャネルを、DL−MU−MCでのレガシーの端末へのチャネルとして割り当てればよい。80+80MHzのチャネル拡張に対応できるレガシーの端末であれば、前述のようにキャリアセンス分離能力値を2とすることもできるので、その場合には、レガシーの端末に通知している基準チャネルと拡張チャネル(例えば図32図33でのprimaryとsecondaryとした2つのチャネル)を割り当てるようにしてもよい。図32図33でのprimaryとsecondaryのチャネルに加えて、secondary40となるチャネルをさらにレガシーの端末が認識できるようになっているのなら、当該チャネルをレガシーの端末にさらに割り当てることもできる。ただし、一部のチャネルに信号または雑音があり使えない場合のチャネル利用効率が下がるため、好ましくない。

0140

<キャリアセンス分離能力がCCAレベルまでかNAVレベルまで可能かに応じたグルーピング>
基地局が、端末のキャリアセンス分離能力がCCAレベルまでのものなのか、NAVレベルまでのものなのかを区別して把握している場合には、グルーピングを行う際にその情報を反映するようにしてもよい。例えば、キャリアセンス分離能力がNAVレベルまでできる端末の方が、複数のチャネルを同時に用いる通信の場合に、複数のチャネルの一部で運用されている他の無線通信システムへ干渉となる可能性を低く抑えることができ、共存に適している、と言うことができる。無線通信システム同士が共存するエリア内で、エリア当たりの通信効率を高め、スループットを向上させるためには、一方の無線通信システムの端末が、もう一方の無線通信システム上のNAVを検知せずに送信することで、もう一方の無線通信システムで送信していた端末で再送が発生することを、できるだけ避けるべきである。従って、キャリアセンス分離能力がCCAレベルまでできる端末よりも、キャリアセンス分離能力がNAVレベルまでできる端末に、同時に用いる複数チャネルをより多く割り当てることが望ましい。また、MU−MCとして、同時に使う複数のチャネルの一部で動作する他の無線通信システムがあると把握している場合には、それらのチャネルには、キャリアセンス分離能力がNAVレベルまでできる端末の割り当てを優先するようにした方がよい。

0141

<MU−MCの実施>
次に、実際にMU−MCを実施する場合について説明する。図20は、AP100がグループ1として、キャリアセンス分離能力値3のSTA101と、キャリアセンス分離能力値2のSTA103と、キャリアセンス分離能力値3のSTA104を相手に、MU−MCを実施した例を示す。データの送信される向きとしては、データフレームに格納されてAP100からSTA101、STA103、STA104に送信されることからDL−MU−MCと言うこともできる。しかしながら、AP100からのRTSフレームに対し、STA101、STA103、STA104からAP100に、CTSフレームが送信されていること、データフレームに対するACKフレームも同様に、STA101、STA103、STA104からAP100に送信されていることからは、UL−MU−MCも行っていると言うことができる。従って、MPDUあるいはPPDUの送信される方向からすれば、アップリンク、ダウンリンクともに実施しているMU−MCと言うことになる。

0142

各端末には、キャリアセンス分離能力の値と同じ数のチャネルを割り当てている。このような場合、待受けるチャネルを、STA101ではch.1からch.3まで、STA103ではch.4とch.5、STA104ではch.6からch.8までなどと、予め定めておけば、各端末は、待ち受けているチャネルで、自端末宛てのフレームを受信できる。図20で、“RTS(X)”のXの値は、RTSフレームの宛先アドレス(RA)をSTA10Xにしているという意味である。

0143

なお、例えば全ての端末が、キャリアセンス分離能力値8以上というように、MU−MCで使われる全チャネル数以上のチャネルに対応可能な場合には、各端末は、MU−MCで使われる全てのチャネルで、チャネルごとに、キャリアセンス状態がビジーかアイドルかの判定が行える。すなわち、端末は、各チャネルに、それぞれチャネルセットを割り当てて、各々のチャネルセットで待ち受けることができる。この場合、待受けチャネルを、特に端末ごとに指定しなくても(自端末宛てのフレームがどのチャネルで送信されるか予め分からなくても)、各端末は自端末宛てのフレームを受信できる。

0144

ここで、各端末が、基地局から割り当てられたチャネルごとに、キャリアセンスがビジーかアイドルかの判定が行えるチャネルセットを割り当てて、待ち受けているとする。STA101では、図20に示すように、ch.1とch.2とch.3で、正常に自端末宛てのフレームを受信する。それぞれがRTSフレームであり、RTSフレームの各々に対してCTSフレームを応答として送信することを判断すると、CTSフレームをch.1とch.2とch.3で同時にAP100宛てに送信する。

0145

STA103では、ch.4とch.5でRTSフレームが送信されているが、STA103は、ch.4のフレームはRTSフレームであると判断でき、かつそれに対してCTSフレームを応答として送信することを判断する。ch.5のフレームに関しては、例えば、干渉などにより正しく受信できなかったと判断したか、あるいはRTSフレームであると判断できたものの、キャリアセンス要件に引っかかり、それに対してCTSフレームを応答として送信できないと判断したとする。

0146

STA104では、ch.7とch.8のフレームは、RTSフレームであると判断でき、かつそれらに対して、各々CTSフレームを応答として送信することを判断する。しかしながら、ch.6のフレームに関しては、例えば干渉などにより正しく受信できなかったと判断したか、あるいはRTSフレームであると認識できたものの、キャリアセンス要件に引っかかり、それに対してCTSフレームを応答として送信できないと判断したとする。

0147

その結果、AP100は、受信したCTSフレームから、どのチャネルを使ってデータフレームが送信できるかを判断する。STA101に関しては、データフレームをch.1からch.3の全てを使って送信できるので、例えば、これらの3チャネルをボンディングして1つのチャネルのように扱い、データフレームをSTA101宛てに送信する(図20では、このデータフレームを“DATA(1)”と示してある)。AP100は、STA103に関しては、ch.4のみを使えると判断し、ch.4のみを使って、STA103宛てにデータフレームを送信する(図20で、このデータフレームを“DATA(3)”と示してある)。AP100は、STA104に関しては、ch.7とch.8を使えると判断し、ch.7とch.8の連続した2チャネルを使って送信できるので、例えば、これらの2チャネルをボンディングして、1つのチャネルのように扱い、データフレームをSTA104宛てに送信する(図20では、このデータフレームを“DATA(4)”と示してある)。そして、各端末では、AP100から送信されたこれらのデータフレームを正しく受信したため、各端末はACKフレームを送信している。STA101、104のように複数のチャネルを使っている場合には、duplicatePPDUとしてACKフレームを送信している(図20ではACKフレームを運ぶ各PPDUは、各々“ACK”と示してある)。

0148

[待受け状態では各チャネルセットを各チャネルに分離するが、データフレーム交換時は各チャネルセットを共通]
ここで、基地局との間で実際にデータフレームを送信するチャネルが確定する前と、確定した後(例えば図20で、CTSフレームをAP100に送信する前と後)について、端末側でのチャネルセットの扱いについて検討する。

0149

図20のSTA103での場合の例をベースに考えると、AP100は、キャリアセンス分離能力値2のSTA103に、ch.4とch.5を割り当てている。そこで、STA103は、少なくとも待ち受け状態では、図21のように、ch.4に、キャリアセンス状態がビジーかアイドルかの判定が行える一方のチャネルセット(チャネルセット1)を、ch.5に、キャリアセンス状態がビジーかアイドルかの判定が行えるもう一方のチャネルセット(チャネルセット2)を割り当てている。STA103の構成としては、例えば図21下図の構成のように、一方のアナログ処理部1をch.4用に、もう一方のアナログ処理部2をch.5用に割り当てる。

0150

そして、図20で示したRTSフレームを受信すると、この段階で、STA103としては、ch.4のみが使えると判断できるので、図22のように、チャネルセット1とチャネルセット2を両方とも、ch.4に割り当てる。STA103の構成としては、例えば図22の下図の構成のように、アナログ処理部1とアナログ処理部2の両方を、ch.4用に割り当てる。

0151

もし、STA103で、ch.4とch.5の両方が使えると判断できた場合には、図23のように、チャネルセット1とチャネルセット2の両方を、ch.4とch.5に割り当てるようにすればいい。STA103の構成としては、例えば図23の下図の構成のように、アナログ処理部1とアナログ処理部2の両方を、ch.4とch.5用に割り当てる。

0152

このように、使うチャネルが確定した段階で、キャリアセンスがビジーかアイドルかの判定が行える複数のチャネルセットを、確定した連続するチャネル全体に割り当てることによって、複数のアンテナでの送受信ができることになり、複数アンテナ受信によるダイバーシチ効果を得ることができる。なお、使うチャネルが確定し、ch.4とch.5の両方が使えると判断できた場合でも、図23のような割り当てを行うことなく、図21のように、各チャネルセットを各チャネルに割り当てたままにすることも可能である。

0153

またAP100側でも、ch.4とch.5に、キャリアセンス状態がビジーかアイドルかの判定が行えるチャネルセットを別々に割り当てていても、STA103からのCTSフレーム受信で使うチャネルが確定することで、データフレームを送信する際には、これらのチャネルセットを、図22あるいは図23でSTA103がしたように、確定した連続するチャネル全体に割り当てることができる。従って、AP100とSTA103の双方で複数のアンテナでの送受信ができることになり、双方の側(AP100とSTA103)でこのように使えるチャネルの確定前後で、チャネルへのチャネルセットの割り当てを変更することが分かっていれば、データフレームを交換する際には、MIMO通信等により、高速化およびロバスト化の効果を得ることができる。

0154

なお、連続していないチャネルが割り当てられている場合で、連続していないチャネルを使うと判断した場合には、それらのチャネルをカバーする周波数帯域に1つのチャネルセットを割り当てるようにしてもよい。しかしながら、チャネルを正しく分離できるという点からは、各チャネルセットを各チャネルに割り当てるままにしておく方が望ましい。

0155

<実際の規格上のチャネル番号と実施形態中のチャネル番号の関係>
上述でキャリアセンスがビジーかアイドルかの判定が行えるチャネルセットでのチャネルは、1つまたは連続した2つ以上のチャネルとしていたが、この連続について補足の説明をする。

0156

IEEE802.11規格でのチャネル番号は、5MHz間隔であり、20MHzのチャネル幅とした場合に、チャネル同士が被らないチャネル番号の間隔は、4つおきとなる。本実施形態でのチャネルセットでの連続するチャネルは、チャネル同士が被らないで連続したチャネルの意味で記載している。実施形態中でのチャネル番号とは便宜的なもので、実際はch.1はIEEE802.11規格での5GHz帯のチャネル番号36、ch.2はIEEE802.11規格での5GHz帯のチャネル番号40、というように解釈すればよい。

0157

[5GHz帯]
IEEE802.11規格での5GHz帯では、基本的にチャネル番号が20MHz間隔で用いられるので、実際に使われているチャネル番号に則ってチャネルを使うことで問題ない。

0158

[2.4GHz帯]
一方、2.4GHz帯では、図24のように、基準チャネルの選択が、北米や中国などでは25MHz間隔(図24(A))で、欧州では30MHz間隔(図24(B))で行われている。そこで、実施形態中のch.1は、IEEE802.11規格での2.4GHz帯のチャネル番号1、ch.2はIEEE802.11規格での2.4GHz帯のチャネル番号6、というように、北米や中国のように25MHz間隔(図24(A))のものとするのでもよい。または、実施形態中のch.1は、IEEE802.11規格での2.4GHz帯のチャネル番号1、ch.2はIEEE802.11規格での2.4GHz帯のチャネル番号7、というように欧州に倣って30MHz間隔((図24(B)))のものとするのでもよい。あるいは図24(C)に示すように、5GHz帯での20MHzチャネル間隔に倣い、実施形態中のch.1はIEEE802.11規格での2.4GHz帯のチャネル番号1、ch.2はIEEE802.11規格での2.4GHz帯のチャネル番号5、というようにするのでもよい。図24(C)は、図24(A)および図24(B)以外に、今後考えられるチャネル選択を例示したものである。ただし、北米や中国、欧州のような場合、別の無線通信システムが、2.4GHz帯のチャネル番号6や7を、少なくとも一部のチャネルとして選択していると、チャネル番号5の周波数帯域と一部周波数帯域が被ることになる。この場合、互いの無線通信システムが影響する周波数帯域が広がり、チャネル利用効率が下がる。

0159

図25は、本実施形態に係る端末の基本的な動作例のフローチャートを示す。

0160

端末は、自端末が対応可能なチャネルセットの個数(キャリアセンス分離能力)として、基地局に通知する値を決定する(S101)。端末は、基地局に通知する値として、自端末が対応可能なチャネルセットの最大数を決定してもよいし、電池残量または通信データ量等の条件に基づいて、最大数以下の値を決定してもよい。自端末が対応可能なチャネルセット数の最大値は、メモリに固定的に保持しておいてもよいし、別の手段で外部(例えば上位層や、外部の装置等)から取得してもよい。

0161

端末は、このように決定したチャネルセット数を表す情報を、基地局に送信する(S102)。例えば、端末は、基地局へ接続するために送信するアソシエーション要求フレームにチャネルセット数を含めることで、チャネルセット数を基地局に通知してもよいし、別の管理フレームで基地局に通知してもよい。なお、本実施形態では、これまでチャネルセット数(キャリアセンス分解能力)を、管理フレームで基地局へ通知する場合を示したが、データフレーム等の他のフレームで通知することを排除するものではない。

0162

端末は、当該端末に割り当てられたチャネルを指定する情報を基地局から通知され、当該情報で指定されたチャネルに、チャネルセットを割り当てる(S103)。この際、指定されたチャネルの1つ1つにチャネルセットを割り当てることが前提になっていてもよいし、基地局から、チャネルとチャネルセットの対応を指示した対応情報の通知を受け、当該対応情報に従って、当該チャネルにチャネルセットを割り当てても良い。端末に割り当てたチャネルを指定する情報、またはチャネルとチャネルセットの対応情報は、アソシエーション要求に対するアソシエーション応答フレームで基地局から通知されてもよいし、ビーコンフレームで通知されてもよいし、新規に定義した管理フレームで通知されてもよい。端末は、基地局から指定されたチャネルに割り当てたチャネルセット単位で、基地局と信号を送受信することで、基地局と通信する(S104)。

0163

図26は、本実施形態に係る基地局の基本的な動作例のフローチャートを示す。

0164

基地局は、各端末からそれぞれ対応可能なチャネルセットの個数(キャリアセンス分離能力)を表す情報を受信する(S201)。例えば、基地局は、当該基地局への接続を要求する端末からアソシエーション要求フレームを受信し、アソシエーション要求フレームから当該情報を抽出する。再アソシエーション要求フレーム等の他の管理フレームから当該情報を取得する構成や、データフレーム等の他の種類のフレームから当該情報を取得する構成も可能である。

0165

基地局は、各端末から取得した情報に基づき、基地局がサポートする複数のチャネルから各端末にチャネルを割り当てる(S202)。具体的に、複数のチャネルを同時に割り当てる端末をグループとして選定し、選定したグループの端末に当該複数のチャネルを割り当てる。

0166

基地局は、各端末に割り当てたチャネルを指定した情報を、管理フレーム等のフレームで各端末に通知する(S203)。例えば、端末からアソシエーション要求フレームでチャネルセット数を表す情報を受信した場合は、アソシエーション応答フレームに当該端末に割り当てたチャネルを指定する情報を含める。あるいは、基地局は、端末ごとに、端末に割り当てたチャネルと、当該チャネルに割り当てるチャネルセットを決定し、これらのチャネルとチャネルセットとの対応情報を各端末に通知してもよい。

0167

基地局は、選定したグループ内の各端末に割り当てたチャネルにチャネルセットを割り当て、各端末とチャネルセット単位で信号を送受信することで、各端末と通信を行う(S204)。

0168

以上、本実施形態によれば、各端末は、各々で設定可能なチャネルセットの個数(例えば最大数)を他の端末に通知することにより、当該他の端末では、各端末へのチャネル割り当てを適切に行って、チャネル利用効率を上げたMU−MC通信が可能となる。また、当該他の端末が基地局であることにより、当該基地局を含む無線通信グループの管理・運営が容易となる。

0169

また、各端末および他の端末ではチャネルセットごとに分離して信号の送受信を行うとともに、チャネルセット単位で、キャリアセンスのビジー・アイドルを把握できる。よって、キャリアセンス前提の環境において、一部のチャネルセットがビジーでも、他のチャネルセットを利用して効率的な通信が可能となる。

0170

また、各端末は、上記他の端末からMU−MC通信方式が可能な旨の情報を受信した場合に、チャネルセットの個数を表す情報を、当該他の端末に通知することにより、効率的な情報伝達が可能となる。

0171

また、上記他の端末は、MU−MC通信方式が可能な旨の情報を、ビーコンフレームもしくはプローブ応答フレームに入れて通知することにより、当該他の端末を含む無線通信グループに接続する前の端末であっても、当該無線通信グループがMU−MC通信方式に対応しているかを把握できる。

0172

(第2の実施形態)
第2の実施形態は、基本的に第1の実施形態に基づくので、その差分のみを記載する。

0173

第2の実施形態では、基地局がMU−MCに対応可能である場合に、基地局が、当該基地局に接続を要求する端末に対して、最低限のキャリアセンス分離能力値を有することを要求する。

0174

基地局のMAC/PHY管理部60は、無線通信システム(BSS)で、MU−MCを実施する際に、チャネル利用効率を上げるため、最低限のキャリアセンス分離能力値を決める。例えば、この最低限のキャリアセンス分離能力値を2とする。この値は、第1の実施形態で、基地局がMU−MCに対応する旨を通知する場合、あるいは端末が自端末のキャリアセンス分離能力を通知する場合と同様、例えば基地局のMIBあるいはメモリに保持される。メモリは、MAC共通処理部30に内包、もしくは別に設けられる。BSSの利用形態トラヒックの特性などに合わせて、要求する最低限のキャリアセンス分離能力値が変わる場合もあることを加味すると、この最低限のキャリアセンス分離能力値は、書き換え可能であることが望ましい。

0175

基地局は、この要求する最低限のキャリアセンス分離能力値を、ビーコンフレームあるいはプローブ応答フレームに入れて送信する。基地局内でのフレームに当該情報を入れる処理方法、及びフレーム内での当該情報の通知方法は、第1の実施形態で基地局がMU−MCに対応する旨を通知する場合、あるいは端末が自端末のキャリアセンス分離能力を通知する場合と同様である。

0176

当該最低限のキャリアセンス分離能力値の情報を、ビーコンフレームあるいはプローブ応答フレームに入れる場合に、基地局がMU−MCに対応する旨を入れなくてもいいし、基地局がMU−MCに対応する旨を合わせて入れるようにしてもよい。

0177

端末は、接続する基地局を探索(scan)する段階で、最低限のキャリアセンス分離能力値が入れられたビーコンフレームもしくはプローブ応答フレームを受信すると、当該最低限のキャリアセンス分離能力値の情報を、基地局の識別子とともに保持する。これは図1の構成でのMAC/PHY管理部60で保持することが望ましい。MAC/PHY管理部60では、基地局のうちで最低限のキャリアセンス分離能力値を通知している基地局に関して、接続する候補となる基地局から基地局を選択する際に、自端末のキャリアセンス分離能力がそのような基地局から通知された最小値を満足するかを加味する。すなわち、自端末のキャリアセンス分離能力を、保持しているメモリ領域から読み出し、基地局で要求されている最低限のキャリアセンス分離能力値と比較する。自能力値要求値以上であれば、当該基地局を接続対象の候補として残す。あるいは、自能力値が要求値未満であれば、MU−MCを要求せずに、当該基地局に接続するという判断を行ってもよい。

0178

基地局に接続する端末に対して、MU−MCに対応することを要求する場合には、例えば、次の手法を利用する。基地局がBSSに加入するには送受信に対応しなくてはならないとするレートを、ベーシックレート(basicrate)として通知するSupported Ratesエレメントというものが、IEEE802.11規格では用意されている。これは、ビーコンフレームまたはプローブ応答フレームなどに入れられる。ベーシックレートは、具体的には、各レート値を示すフィールドのMSBビットに、“1”を立てることで識別できるようになっている。接続を要求する端末は、このSupported Ratesエレメントに、ベーシックレートが1つまたは複数設定されていれば、その全てを満たせる場合にしか、当該基地局に対し接続要求を出せない。そこで、MU−MC用に新たに未使用の値をレート値として定義し、Supported Ratesエレメントでそれをベーシックレートであると示せばよい。

0179

以上、本実施形態によれば、各端末は、各々で処理できるチャネルセットの最大数が、他の端末(基地局等)が要求する最小数(最低限のキャリアセンス分離能力値)を満たす場合に、チャネルセットの最大数を表す情報を通知することで、当該他の端末は、効率的に各端末の能力情報を収集できる。

0180

(第3の実施形態)
第3の実施形態は、基本的に第1及び第2の実施形態に基づくので、第1及び第2の実施形態との差分のみを記載する。

0181

第3の実施形態では、端末が2以上の値のキャリアセンス分離能力を有し、キャリアセンス状態がビジーかアイドルかの判定が行えるチャネルセットを各々別のチャネルに割り当てる場合に、チャネルセット間にガードバンド(周波数上のギャップ)が必要である場合がある。端末は、ガードバンドの必要の有無に応じて、基地局にガードバンドに関する情報を通知する。ガードバンドは、図27に示すように、チャネルセット間に設ける周波数上のギャップである。

0182

例えば、端末でガードバンドが必要である場合に、最低必要なガードバンドが規格あるいは仕様で定まっているとすれば、端末はガードバンド要求だけを、キャリアセンス分離能力値とともに通知すればよい。ガードバンドが不要な場合は、ガードバンド不要を示す情報を含め、何ら情報を通知しなくてもよい。

0183

端末でガードバンドが必要なのが前提で、ガードバンドが必要ないのは拡張機能であるというような場合には、基地局へ通知するフィールド(1ビットフィールドで十分)で、必要の有無に応じた値を設定すればよい。例えば、ガードバンド要求がある場合をデフォルトで“0” (Reservedと同じ値)とし、ガードバンド要求がない場合を“1”とするように定めればよい。

0184

あるいは、端末は、ガードバンドが必要なときだけ、キャリアセンス分離能力値とともに、ガードバンド要求を通知するようにしてもよい。この場合は、基地局へ通知するフィールド(1ビットフィールドで十分)において、ガードバンド要求がない場合がデフォルトで“0”(Reservedと同じ値)、ガードバンド要求がある場合が“1”とするように定めればよい。

0185

ガードバンドが必要な場合に、さらに必要なガードバンド幅を端末が通知する必要がある場合には、ガードバンド要求とともに、その必要なガードバンド幅情報をフレームに入れる。

0186

あるいは、前述のように、端末でガードバンドが必要なことを前提とする場合には、ガードバンド要求の有無の情報を入れずに、必要なガードバンド幅情報だけをフレームに入れるのでよい。

0187

ガードバンド要求に係る通知方法は、第1の実施形態で端末がキャリアセンス分離能力値を通知する場合に準じればよい。

0188

基地局側では、各端末のガードバンド要求の有無も加味して、MU−MCのためのグルーピングを行う。具体的には、各端末のガードバンド要求が満たされるように、各端末へのチャネル割り当てを行い、その上で各グループに属する端末を選択する。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社NTTドコモの「 ユーザ端末及び無線通信方法」が 公開されました。( 2020/10/29)

    【課題・解決手段】ビーム回復手順の実施が想定される場合に、RLMを適切に制御すること。本発明の一態様に係るユーザ端末は、仮想の下り制御チャネルに関する情報を受信する受信部と、前記情報に基づいて、下り制... 詳細

  • 株式会社NTTドコモの「 ユーザ端末及び無線通信方法」が 公開されました。( 2020/10/29)

    【課題・解決手段】同期信号ブロックを利用する無線通信システムにおいて制御チャネルの設定領域の情報を適切に通知するために、本発明のユーザ端末の一態様は、制御リソースセットの構成を示す所定ビット情報を含む... 詳細

  • 株式会社NTTドコモの「 端末、無線通信方法及び基地局」が 公開されました。( 2020/10/29)

    【課題・解決手段】マルチキャリア波形を有するUL信号を適切に送信するために、ユーザ端末は、連続する周波数リソースにわたるマルチキャリア波形を有する上り信号を、上り共有チャネルを用いて送信する送信部と、... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ