JP7292023B2 - 通信装置、制御方法、及びプログラム - Google Patents

Description

本発明は、無線通信の干渉制御技術に関する。

無線通信で送受信される情報が、テキストデータから画像データへ、画像データから動画データへと高度化しており、通信量も拡大している。一方、無線通信で使用可能な周波数帯には限りがあるため、時間、周波数、符号、空間等の様々な次元において高密度に信号を多重し、通信容量を増やし、周波数利用効率を向上させることが要求されている。

このような背景において、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）では、変調方式の高度な多値化、チャネルボンディングやＭＩＭＯ（Ｍｕｌｔｉｐｌｅ－Ｉｎｐｕｔ ａｎｄ Ｍｕｌｔｉｐｌｅ－Ｏｕｔｐｕｔ、多入力多出力）等の手法の導入により通信容量の拡大が試みられている。例えば、ＩＥＥＥ（米国電気電子技術者協会）では、高効率（ＨＥ：Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ）な次世代の無線ＬＡＮ規格としてＩＥＥＥ８０２．１１ａｘが検討されている。ＩＥＥＥ８０２．１１ａｘでは、周波数利用効率を向上させるため、従来は２０ＭＨｚの周波数帯域幅を単位として用いていた周波数チャネルの構造を、より狭い周波数帯域幅を単位として複数の端末に割り当て可能としたＯＦＤＭＡの採用が提案されている。なお、ＯＦＤＭＡは、Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（直交周波数分割多元接続）の頭字語であり、複数のユーザの信号を多重するマルチユーザ（ＭＵ：Ｍｕｌｔｉ Ｕｓｅｒ）通信方式である。

ＩＥＥＥ８０２．１１ａｘでは、ＯＦＤＭＡにより、２０ＭＨｚ幅の周波数帯域の少なくとも一部が、最大９ユーザに割り当てられる。ユーザ数が１の場合は２０ＭＨｚ幅の周波数帯域のすべてがそのユーザに割り当てられてもよく、一方で、ユーザ数が２以上の場合は、各ユーザに対して２０ＭＨｚ幅の周波数帯域のそれぞれ重ならない一部が割り当てられる。同様に、４０ＭＨｚ、８０ＭＨｚ、及び１６０ＭＨｚ幅の周波数帯域が使用される場合には、それぞれ最大１８、３７、及び７４ユーザに、その周波数帯域の少なくとも一部が割り当てられる。

ＩＥＥＥ８０２．１１ａｘで検討されているＯＦＤＭＡによるＭＵ通信方式では、サブキャリアの間隔が、従来規格であるＩＥＥＥ８０２．１１ａ／ｇ／ｎ／ａｃのＯＦＤＭで用いられてきた３１２．５ｋＨｚから、７８．１２５ｋＨｚに変更される。なお、このため、ＩＥＥＥ８０２．１１ａｘ規格より前のＩＥＥＥ８０２．１１シリーズの規格に対応する無線ＬＡＮ機器（以下、「レガシー機器」と呼ぶ。）は、基本的に、ＩＥＥＥ８０２．１１ａｘのＭＵ通信方式で通信される信号を復調することはできない。一方、ＩＥＥＥ８０２．１１ａｘに対応する無線ＬＡＮ機器（以下、「ＨＥ機器」と呼ぶ。）は、レガシー機器が通信する信号を復調することや、レガシー機器が復調できる信号を送信することができるように構成される。

レガシー機器間では、通信の干渉回避のために、送信側装置がＲＴＳ（Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信し、受信側装置がＣＴＳ（Ｃｌｅａｒ Ｔｏ Ｓｅｎｄ）フレームを送信することができる。これらのＲＴＳ／ＣＴＳは、近隣の無線ＬＡＮ機器に対してチャネルを占有することが予想される期間の情報として、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ、いわゆる送信禁止期間）を含む。ＲＴＳフレームを送信した送信側装置とＣＴＳフレームを送信した受信側装置の周囲に存在する他の無線ＬＡＮ機器は、ＲＴＳフレーム又はＣＴＳフレームを受信すると、通知されたＮＡＶの期間においては信号を送信しないようにする。ＨＥ機器は、レガシー機器が送信した信号を正しく復調することができるため、ＮＡＶの期間に信号を送信しない。これにより、ＲＴＳフレームを送信した送信側装置とＣＴＳフレームを送信した受信側装置の周囲に存在する他の無線ＬＡＮ機器は、レガシー機器とＨＥ機器のいずれであっても、信号を送信しないようになるため、送信側装置が送信する信号に対する干渉が抑制される。なお、レガシー機器間の通信では、送信側装置から発行されるＲＴＳフレームと受信側装置から発行されるＣＴＳフレームは、同一チャネル内で複数の機器から同時に送信されることはない。

一方、ＩＥＥＥ８０２．１１ａｘでは、ＲＴＳフレームとＣＴＳフレームをＭＵ通信方式に適応させるために、ＭＵ－ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ ＲＴＳ）とフレーム、同時ＣＴＳ応答（ｓｉｍｕｌｔａｎｅｏｕｓ ＣＴＳ ｒｅｓｐｏｎｓｅｓ）フレームの組み合わせが用いられる（特許文献１）。具体的には、アクセスポイント（ＡＰ）が、ＭＵ―ＲＴＳフレームを送信する。ＭＵ－ＲＴＳフレームは、ＨＴ（Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）対応のレガシー機器（８０２．１１ｎ以降の無線ＬＡＮ機器）が復調できるＨＴ ＰＰＤＵ（（ＰＬＣＰ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ） Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ））、もしくはすべてのレガシー機器が復調できるｎｏｎーＨＴ ＰＰＤＵまたはｎｏｎーＨＴ Ｄｕｐｌｉｃａｔｅ ＰＰＤＵの形式（フォーマット）で送信される。ＭＵ－ＲＴＳフレームを復調できるレガシー機器は、当該フレームに含まれるＤｕｒａｔｉｏｎ Ｆｉｅｌｄの値を用いてＮＡＶを更新することができる。ＭＵ通信を行う各端末は、ＡＰからのＭＵ－ＲＴＳに応答して同時に同一内容のＣＴＳフレームを送信する。各端末がＣＴＳフレームを送信することで、当該ＣＴＳフレームを受信できる端末は、ＡＰからのＭＵ－ＲＴＳフレームを受信できなくても、ＮＡＶを適切に設定することができる。なお、当該ＣＴＳフレームは、レガシー機器でも復調できる形式で送信される。

米国特許出願公開第２０１７／０２７９５６８号明細書

ＭＵ－ＲＴＳ／ＣＴＳ処理はデータ通信に対するオーバーヘッドになるため、すべてのＭＵ通信時にＭＵ－ＲＴＳ／ＣＴＳ処理を実施すると帯域の使用効率を低下させてしまう。一方、ＭＵ－ＲＴＳ／ＣＴＳ処理を実施しない場合にレガシー機器や隠れ端末の影響で送信パケットが干渉してしまうという問題がある。

本発明は上記課題に鑑みなされたものであり、マルチユーザ通信において、効率的に干渉抑制制御を行うことを目的とする。

上記目的を達成するため、本発明の一態様に係る通信装置は、以下の構成を有する。すなわち、１以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能なＩＥＥＥ８０２．１１ａｘ規格に対応し、特定のＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）で外部から識別されるアクセスポイントとして機能する通信装置であって、前記マルチユーザ通信がアップリンクにおける通信の場合に、前記ＩＥＥＥ８０２．１１ａｘ規格より前のＩＥＥＥ８０２．１１シリーズの規格に対応するが、前記ＩＥＥＥ８０２．１１ａｘ規格をサポートしない装置であるＩＥＥＥ８０２．１１ａｘ非サポート機器が前記特定のＢＳＳに属するか否かに関わらず前記通信装置の周囲に存在するかを外部から取得した情報に基づいて判定する判定手段と、前記判定手段により前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定された場合に、前記マルチユーザ通信によるデータ通信の前に、ＭＵ－ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信する送信手段と、を有する。

本発明によれば、マルチユーザ通信において、効率的に干渉抑制制御を行うことが可能となる。

実施形態におけるネットワーク構成例を示す。 ＵＬ ＭＵ通信をＭＵ－ＲＴＳ送信なしで実行する際のタイムチャートを示す。 実施形態におけるＡＰのハードウェア構成例を示す。 実施形態におけるＡＰの機能構成例を示す。 実施形態においてＡＰが実行するＭＵ通信処理の流れの例を示す。 実施形態１におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態１におけるＭＵ通信処理の流れの例を示す。 実施形態２におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態２におけるＭＵ通信処理の流れの例を示す。

以下、添付の図面を参照して、本発明をその実施形態の一例に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

［ネットワーク構成］
図１に、以下に説明するいくつかの実施形態におけるネットワークの構成例を示す。図１は、ＨＥ機器として３つのステーション（ＳＴＡ１１、ＳＴＡ１２、ＳＴＡ１５）、１つのアクセスポイント（ＡＰ１３）、レガシーＳＴＡ１４、及びＳＴＡ１９（ＨＥ機器でもレガシー機器でも良い）を含んだ構成を示している。なお、レガシーＳＴＡ１４は図１ではＳＴＡとして示すが、レガシー機器であれば良く、ＡＰとＳＴＡとのいずれであってもよい。図１に示すように、ＡＰ１３の送信する信号が受信可能な範囲は円１６で示され、ＡＰ１３が送信した信号は、ＳＴＡ１１、ＳＴＡ１２、レガシーＳＴＡ１４、及びＳＴＡ１５において受信可能である。またＳＴＡ１２の送信する信号が受信可能な範囲は円１７で示され、ＳＴＡ１２が送信した信号は、ＡＰ１３では受信できるが、レガシーＳＴＡ１４において受信できないものとする。同様に、ＳＴＡ１５の送信する信号が受信可能な範囲は円１８で示され、ＳＴＡ１５が送信した信号は、ＡＰ１３、ＳＴＡ１９では受信できるが、レガシーＳＴＡ１４において受信できないものとする。なお図示をしていないが、レガシーＳＴＡ１４が送信した信号は、ＡＰ１３で受信できるとする。ただし、これは一例であり、例えば広範な領域に多数のＨＥ機器及びレガシー機器を含むネットワークに対して、また、様々な通信装置の位置関係に対して、以下の議論を適用可能である。

図１の例において、２つのＳＴＡ（ＳＴＡ１２及びＳＴＡ１５）は、ＡＰ１３との間で、ＭＵ通信（マルチユーザ通信）を行う。ＭＵ通信を行うために、ＡＰ１３は、ＭＵ－ＲＴＳ（ＭＵ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信することができる。ＳＴＡ１２及びＳＴＡ１５は、受信したＭＵ ＲＴＳフレームに対して同時ＣＴＳ（Ｓｉｍｕｌｔａｎｅｏｕｓ Ｃｌｅａｒ Ｔｏ Ｓｅｎｄ）フレーム（以下、ＣＴＳフレーム）を送信することができる。なお、ＭＵ ＲＴＳフレームには、そのＭＵ－ＲＴＳフレームに応答してＣＴＳフレームを送信すべきＳＴＡを指定する情報と、ＣＴＳフレームを送信すべき周波数を指定する情報とが含まれる。このため、ＳＴＡ１２及びＳＴＡ１５は、ＭＵ ＲＴＳフレームにおいて自身がＣＴＳフレームを送信すべきＳＴＡとして指定されている場合に、指定された周波数でＣＴＳフレームを送信することができる。ここで、ＳＴＡ１１はＭＵ－ＲＴＳフレームを受信することができるが、ＣＴＳフレーム送信すべきＳＴＡを指定する情報に自身の情報が含まれていないため、ＣＴＳフレームを送信しない。

ＭＵ－ＲＴＳフレームは、ＨＴ ＰＰＤＵ、もしくは、ｎｏｎーＨＴ ＰＰＤＵ、またはｎｏｎーＨＴ Ｄｕｐｌｉｃａｔｅ ＰＰＤＵ形式（フォーマット）で送信される。ＨＴ ＰＰＤＵの形式で送信されたＭＵ－ＲＴＳフレームは、ＨＴ対応のレガシー機器（８０２．１１ｎ以降の無線ＬＡＮ機器）が復調できる。ｎｏｎーＨＴ ＰＰＤＵまたはｎｏｎーＨＴ Ｄｕｐｌｉｃａｔｅ ＰＰＤＵの形式で送信されたＭＵ－ＲＴＳフレームは、すべてのレガシー機器が復調できる。ＭＵ－ＲＴＳフレームを復調できるレガシー機器は、ＭＵ－ＲＴＳフレームに含まれるＤｕｒａｔｉｏｎ Ｆｉｅｌｄの値を用いてＮＡＶを更新することができる。図１の例では、ＳＴＡ１９は、ＡＰ１３からの信号を直接受信することができない。しかし、ＳＴＡ１９は、ＳＴＡ１２とＳＴＡ１５が送信するＣＴＳフレームを受信できるため、ＣＴＳフレームに含まれるＤｕｒａｔｉｏｎフィールドの値を用いてＮＡＶを適切に設定することができる。ＮＡＶの期間には、該当するＭＵ通信期間が設定され、その間に各ＳＴＡがデータ送信を行わないことで、信号の干渉を抑制することができる。アップリンクの場合、ＭＵ通信期間はＴｒｉｇｇｅｒフレーム（アップリンク送信を制御するためのフレーム）、ＵＬ ＰＰＤＵ（マルチユーザ通信におけるアップリンクのＰＰＤＵ）、ＭＵ－ＡＣＫフレームまでの期間となる。ＵＬ ＰＰＤＵは、例えば、ＵＬ ＨＥ ＭＵ ＰＰＤＵ（Ｕｐｌｉｎｋ Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ Ｍｕｌｔｉ－ｕｓｅｒ ｐｈｙｓｉｃａｌ ｌａｙｅｒ （ＰＨＹ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）である。

一方、上述したようにＭＵ－ＲＴＳ／ＣＴＳ処理はデータ通信に対するオーバーヘッドになるため、すべてのＭＵ ＵＬ通信時にＭＵ－ＲＴＳ／ＣＴＳ処理を実施すると帯域の使用効率を低下させてしまう。以下に説明するいくつかの実施形態では、ＡＰの周囲に存在するＳＴＡの情報に応じてＭＵ－ＲＴＳ送信を行うか行わないかを切り替える処理について説明する。

実施形態の説明に入る前に、図２を参照して、レガシー機器がＡＰの周囲に存在する場合に、ＭＵ－ＲＴＳを送信しないことによる信号の干渉問題について説明する。図２は、ＵＬ ＭＵ通信をＭＵ－ＲＴＳ送信なしで実行する際のタイムチャートを示す。図２におけるＡＰ１３、ＳＴＡ１１、ＳＴＡ１２、レガシーＳＴＡ１４、及びＳＴＡ１５は、それぞれ図１に示すように配置されているものとする。

ＡＰ１３ははじめにＵＬ ＭＵ通信を始めるためのＴｒｉｇｇｅｒフレーム２０１をＨＥ ＰＰＤＵ形式で送信する。ＳＴＡ１１、ＳＴＡ１２、及びＳＴＡ１５はＡＰ１３の信号が届く範囲に存在するため、Ｔｒｉｇｇｅｒフレーム２０１を受信することができる。ＳＴＡ１１とＳＴＡ１５はＴｒｉｇｇｅｒフレーム２０１を受信して、当該フレームに含まれるＰｅｒＵｓｅｒＩｎｆｏフィールドに自ＳＴＡの情報が含まれることを確認し、後続のＵＬ ＭＵ通信に備える。また、ＳＴＡ１２は、自ＳＴＡの情報が含まれないことを確認し、Ｄｕｒａｔｉｏｎフィールドに含まれる値をもとにＮＡＶの期間２０４を設定する。ここでＮＡＶの期間２０４を設定することで、ＳＴＡ１２に対しては、ＭＵ－ＲＴＳでのＮＡＶの設定と同様に、後続のＵＬ ＰＰＤＵ２０２とＭＵ－ＡＣＫ２０３までを含めた期間、干渉抑制が働く。

一方、レガシー機器であるレガシーＳＴＡ１４は、ＨＥ ＰＰＤＵ形式のＴｒｉｇｇｅｒフレーム２０１を復調することができず、Ｄｕｒａｔｉｏｎフィールドを知ることができない。ただしＨＥ ＰＰＤＵ形式のＴｒｉｇｇｅｒフレーム２０１にはレガシー機器との互換性のためにＬ－ＳＩＧフィールドが設けられており、当該フレームに含まれるＬ－ＳＩＧ ＬＥＮＧＴＨフィールドにＴｒｉｇｇｅｒフレーム２０１のサイズ情報が含まれる。このため、レガシーＳＴＡ１４は当該サイズ情報を用いてＴｒｉｇｇｅｒフレーム２０１の送信期間としてＮＡＶの期間２０５を設定することができる。ＮＡＶの期間２０５が終わると、レガシーＳＴＡ１４は、Ｔｒｉｇｇｅｒフレーム２０１をエラーフレームとみなし、ＥＩＦＳ（Ｅｘｔｅｎｄｅｄ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）２０６後にバックオフ期間を経てデータ２０７の送信が可能になる。このデータ２０７の送信がＵＬ ＰＰＤＵ２０２と干渉してしまう可能性がある。

以上の通り、ＵＬ ＭＵ通信において、レガシー機器が存在するか否かで干渉抑制の働きに違いがある。つまり、レガシー機器が存在しない場合はＭＵ－ＲＴＳ送信をしなくてもＴｒｉｇｇｅｒフレームによって後続のＭＵ通信を含む期間で干渉抑制が可能であるが、レガシー機器が存在する場合はそのような干渉抑制が不可能である。以下に説明する実施形態では、ＭＵ ＵＬ通信においてＡＰの周囲にレガシー機器が存在する場合にＭＵ－ＲＴＳを送信し、存在しない場合にはＭＵ－ＲＴＳを送信しない処理について説明する。

［ＡＰの構成］
図３に、以下に説明するいくつかの実施形態におけるＡＰ１３のハードウェア構成例を示す。ＡＰ１３は、そのハードウェア構成の一例として、記憶部３０１、制御部３０２、機能部３０３、入力部３０４、出力部３０５、通信部３０６及びアンテナ３０７を有する。

記憶部３０１は、ＲＯＭ、ＲＡＭの両方、または、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部３０１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。

制御部３０２は、例えば、ＣＰＵやＭＰＵ等のプロセッサー、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサー）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）等により構成される。ここで、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの頭字語である。制御部３０２は、記憶部３０１に記憶されたプログラムを実行することによりＡＰ１３全体を制御する。なお、制御部３０２は、記憶部３０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働によりＡＰ１３全体を制御するようにしてもよい。

また、制御部３０２は、機能部３０３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部３０３は、ＡＰ１３が所定の処理を実行するためのハードウェアである。例えば、ＡＰ１３がカメラである場合、機能部３０３は撮像部であり、撮像処理を行う。また、例えば、ＡＰ１３がプリンタである場合、機能部３０３は印刷部であり、印刷処理を行う。また、例えば、ＡＰ１３がプロジェクタである場合、機能部３０３は投影部であり、投影処理を行う。機能部３０３が処理するデータは、記憶部３０１に記憶されているデータであってもよいし、後述する通信部３０６を介して他のデバイスと通信したデータであってもよい。

入力部３０４は、ユーザからの各種操作の受付を行う。出力部３０５は、ユーザに対して各種出力を行う。ここで、出力部３０５による出力とは、画面上への表示や、スピーカーによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部３０４と出力部３０５の両方を１つのモジュールで実現するようにしてもよい。

通信部３０６は、通信処理を実行する。通信部３０６は、少なくともＩＥＥＥ８０２．１１ａｘ規格に準拠した通信処理を実行することができる。また、通信部３０６は、アンテナ３０７を制御して、無線通信のための無線信号の送受信を行う。ＡＰ１３は通信部３０６を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置と通信する。

図４は、以下に説明するいくつかの実施形態におけるＡＰ１３の機能構成例を示す。ＡＰ１３は、その機能構成の一例として、送受信部４０１、通信解析部４０２、レガシー機器検出部４０３、エラー管理部４０４、及びＵＩ制御部４０５を有する。

送受信部４０１は、通信部３０６（図３）を制御し、信号の送受信を行う。例えば送受信部４０１は、指定された周波数チャネルにおいて、ＭＵ－ＲＴＳフレームを送信する。なお、送受信部４０１は、ＭＵ－ＲＴＳフレームをＨＴ ＰＰＤＵ形式で送信しても良いし、ｎｏｎ―ＨＴ ＰＰＤＵ形式で送信しても良い。また、レガシー機器検出部４０３により、レガシー機器が存在すると判定された際に、ＭＵ－ＲＴＳフレームをｎｏｎ―ＨＴ ＰＰＤＵ形式で送信するように制御しても良いがこれに限定されない。通信解析部４０２は、対向機との間の通信の内容を解析する。レガシー機器検出部４０３は、ＭＵ通信で用いられる周波数帯域において、レガシー機器が存在しているかを検出する。レガシー機器検出部４０３は、例えば、一定時間内に当該周波数帯域の少なくとも一部において他機器から送信されたＭａｎａｇｅｍｅｎｔフレームを検出した場合に、当該フレーム中にＨＥ Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔが含まれるか否かを判定する。レガシー機器が送信するＭａｎａｇｅｍｅｎｔフレームは、ＨＥ Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔを含まない。そのため、レガシー機器検出部４０３は、ＨＥ Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔを含まないＭａｎａｇｅｍｅｎｔフレームを送信した機器を、レガシー機器とみなすことができる。なお、レガシー機器はＡＰでもＮｏｎ－ＡＰ ＳＴＡでも良いし、ＡＰ１３と同一ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）に所属していても、他のＢＳＳに所属していても良い。また、レガシー機器検出部４０３は、他機器が送信するＭａｎａｇｅｍｅｎｔフレームの中にＨＴ（Ｈｉｇｈ Ｔｒｏｕｇｈｐｕｔ） Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔが含まれるか否かによって、レガシー機器がＨＴ対応レガシー機器か、ＨＴ非対応レガシー機器かを判定しても良い。ＭａｎａｇｅｍｅｎｔフレームにＨＴ Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔが含まれる場合、レガシー機器検出部４０３は、当該フレームを送信した機器を、ＨＴ対応レガシー機器と判定する。

エラー管理部４０４はＭＵ通信が成功せずにエラーとなってしまった回数や連続エラー回数を管理する。エラーの判定方法としては、ＵＬ ＭＵの対象ＳＴＡからのＵＬ ＰＰＤＵ（データパケット）が受信されない場合にエラーとすることができる。例えば、特定ＳＴＡからＵＬ ＰＰＤＵを連続で所定の回数であるｎ回（ｎ＝３など）受信できなかった場合（エラー回数が所定の回数を上回った場合）に当該ＳＴＡに対するＵＬ ＭＵ通信がエラー状態と判定しても良い。ＵＩ制御部４０５は、ＡＰ１３の不図示のユーザによるＡＰ１３に対する操作を受け付けるためのタッチパネル又はボタン等のユーザインタフェースに関わるハードウェアおよびそれらを制御するプログラムを含んで構成される。

［ＡＰの処理の流れ］
続いて、以下に説明するいくつかの実施形態におけるＡＰ１３が実行する処理の流れについて説明する。図５は、実施形態におけるＡＰ１３がＭＵ通信を実行する処理の流れの例を示すフローチャートである。本処理は、例えば、ＡＰ１３の制御部３０２が、記憶部３０１に記憶されたプログラムを実行することによって実現される。ここで、ＳＴＡ（図１の例ではＳＴＡ１２及びＳＴＡ１５）は、ＡＰ１３とＭＵ通信方式で接続されているものとする。

本処理では、ＡＰ１３は、まず、ＭＵ通信に使用される所定の周波数帯域内の周波数チャネルの使用状況を、例えば定期的に、監視する（Ｓ５０１）。なお、所定の周波数帯域内の周波数チャネルの使用状況の監視は、例えば、ＡＰ１３がＢＳＳを確立したことを契機に開始される。この監視において、レガシー機器検出部４０３は、ＡＰ１３の周囲にレガシー機器が存在するか否かを判定する。なお、本監視処理は、Ｓ５０２におけるＭＵ通信準備処理、Ｓ５０３～Ｓ５０８におけるＭＵ通信処理の間もバックグラウンドで実行されていても良い。その場合は、ＡＰ１３の周囲にレガシー機器が存在するか否かの監視結果（判定結果）は随時更新されても良い。

続いて、ＡＰ１３はＭＵ通信準備処理を開始する（Ｓ５０２）。本処理については、以下の実施形態１と実施形態２として後述する。その後、ＡＰ１３はＭＵ通信処理を開始し８０２．１１ａｘ規格で定められた仕様に従ってＭＵ通信を実行する。すなわち、まずＳ５０３で、通信解析部４０２は、開始するＭＵ通信がＵＬ ＭＵ通信かＤＬ ＭＵ通信かを判別する。開始するＭＵ通信がＵＬ ＭＵ通信の場合は（Ｓ５０３でＹＥＳ）、Ｓ５０４で送受信部４０１は、Ｔｒｉｇｇｅｒフレームを送信し、対向の各ＳＴＡにＲＵ（Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）の割り当てを行う。ＲＵの割り当て後に、送受信部４０１が、各ＳＴＡよりＵＬ ＰＰＤＵ（データパケット）を受信すると（Ｓ５０５）、ＵＬ ＰＰＤＵの受信の確認応答としてＭＵ ＡＣＫフレームを各ＳＴＡに向けて送信する（Ｓ５０６）。なお、図５では、ＡＰ１３が各ＳＴＡからＵＬ ＰＰＤＵを受信する例を示しているが、ＵＬ ＰＰＤＵを受信できない場合は、確認応答を返さない等の処理を行うこととなる。

一方、開始するＭＵ通信がＤＬ ＭＵ通信の場合は（Ｓ５０３でＮＯ）、送受信部４０１は、ＤＬ ＰＰＤＵ（データパケット）を対向の各ＳＴＡに送信し（Ｓ５０７）、各ＳＴＡより確認応答としてＡＣＫフレームを受信する（Ｓ５０８）。なお、図５では、Ｓ５０８でＡＰ１３はＡＣＫフレームを受信する例を示しているが、ＡＣＫフレームを受信できない状況も起こり得る。ここで、ＤＬ ＰＰＤＵは、マルチユーザ通信におけるダウンリンクのＰＰＤＵであり、例えば、ＤＬ ＨＥ ＭＵ ＰＰＤＵ（Ｄｏｗｎｌｉｎｋ Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ Ｍｕｌｔｉ－ｕｓｅｒ ｐｈｙｓｉｃａｌ ｌａｙｅｒ （ＰＨＹ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）である。

続いて、図５のＳ５０２のＭＵ通信準備処理についての実施形態を以下に説明する。

（実施形態１）
実施形態１におけるＭＵ通信準備処理を、図６を参照して説明する。図６は、実施形態１におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。まず、Ｓ６０１で通信解析部４０２は、これから開始するＭＵ通信がＵＬ（アップリンク）かＤＬ（ダウンリンク）かを判定する。開始するＭＵ通信がＵＬの場合（Ｓ６０１でＹＥＳ）、Ｓ６０２でレガシー機器検出部４０３は、レガシー機器が存在するかどうかを判定する。当該判定処理は、図５のＳ５０１における監視結果を用いて行われ得る。レガシー機器が存在すると判定された場合は（Ｓ６０２でＹＥＳ）、Ｓ６０３にて送受信部４０１は、ＭＵ－ＲＴＳフレームを送信し、終了する。レガシー機器が存在しないと判定された場合は（Ｓ６０２でＮＯ）、Ｓ６０４にてＡＰ１３はＭＵ－ＲＴＳフレームを送信せずに終了する。Ｓ６０１にてＤＬと判定された場合は（Ｓ６０１でＮＯ）、Ｓ６０３にて送受信部４０１は、ＭＵ－ＲＴＳフレームを送信する。ＭＵ－ＲＴＳフレームの送信後、Ｓ６０５にて送受信部４０１は対向ＳＴＡよりＣＴＳフレームを受信し、終了する。

なお、ＡＰ１３は、Ｓ６０２でＹＥＳのとき、ＭＵ通信において通信するデータサイズが所定の閾値より大きいかを判定するようにし、当該データサイズが当該閾値より場合に、Ｓ６０３で送受信部４０１が、ＭＵ－ＲＴＳフレームを送信してもよい。当該データサイズは、例えば、ＵＬ ＰＰＤＵのサイズである。また、Ｓ６０２でＹＥＳのとき、送受信部４０１がＣＴＳ－ｔｏ－ｓｅｌｆ機能に基づいてＣＴＳフレームを送信し、レガシー機器（レガシーＳＴＡ１４）にＮＡＶを設定させてもよい。この場合、ＣＴＳ－ｔｏ－ｓｅｌｆ機能に基づくＣＴＳフレームの送信によってもエラー管理部４０４によりエラーがＭＵ通信がエラー状態と判断された場合に、Ｓ６０３で送受信部４０１が、ＭＵ－ＲＴＳフレームを送信してもよい。

続いて、図７を用いて、本実施形態におけるＵＬ ＭＵ通信のシーケンスについて説明する。図７は、本実施形態におけるＡＰ１３が実行するＵＬ ＭＵ通信処理の流れの例を示す図である。ＡＰ１３、ＳＴＡ１２、レガシーＳＴＡ１４、及びＳＴＡ１５は、それぞれ図１に示すように配置されているものとする。なお、ＳＴＡ１１とＳＴＡ１９については本シーケンス図からは省略する。

本シーケンス開始時には、ＡＰ１３のレガシー機器検出部４０３は、レガシー機器（レガシーＳＴＡ１４）を検出していない状態と仮定する。ＡＰ１３は、ＵＬ ＭＵ通信を開始する際、Ｓ５０１とＳ５０２を経て、ＭＵ－ＲＴＳを送信せずにＳ５０３～Ｓ５０６のＵＬ ＭＵ通信処理を開始する。ＵＬのＭＵ通信処理では、Ｍ７０１でＡＰ１３は、ＴｒｉｇｇｅｒフレームをＭＵ通信対象のＳＴＡ１２とＳＴＡ１５に送信し、ＲＵ（Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）の割り当てを行う（Ｓ５０４）。ＳＴＡ１２とＳＴＡ１５は、それぞれ割り当てられたＲＵを用いてＭ７０２においてＵＬ ＰＰＤＵをＡＰに送信する（Ｓ５０５）。ＵＬ ＰＰＤＵを受信したＡＰ１３は、Ｍ７０３において、ＳＴＡ１２とＳＴＡ１５に対してＭＵ ＡＣＫフレームを送信する（Ｓ５０６）。レガシー機器が検出されていない状態では、Ｍ７０１～Ｍ７０３の処理が繰り返し実行されることで、ＭＵ－ＲＴＳ／ＣＴＳ処理によるオーバーヘッドなしに、ＵＬ ＭＵ通信を行うことができる。

ここで、Ｍ７０４にてＡＰ１３が、レガシーＳＴＡ１４からのＭａｎａｇｅｍｅｎｔフレームを受信すると仮定する。ＡＰ１３は、Ｓ５０１の監視処理において、Ｍａｎａｇｅｍｅｎｔフレームを解析する。これにより、ＡＰ１３は例えばＨＥ Ｃａｐａｂｉｌｉｔｉｅｓ ＩＥが付与されていないことから当該フレームを送信した機器はレガシー機器であることを判定することができる。これにより、以降のＵＬ ＭＵ通信において、レガシー機器が存在すると判定され（Ｓ６０２でＹＥＳ）、Ｍ７０５にてＡＰ１３は、ＭＵ－ＲＴＳフレームを送信する（Ｓ６０３）。ＭＵ－ＲＴＳを受信したＳＴＡ１２とＳＴＡ１５は、Ｍ７０６でＣＴＳフレームをＡＰ１３に送信する。レガシーＳＴＡ１４はＭＵ－ＲＴＳフレームを受信し（本例では、ＭＵ－ＲＴＳフレームはレガシーＳＴＡ１４が復調できる形式とする）、当該フレームに含まれるＤｕｒａｔｉｏｎフィールドの値を用いて、Ｍ７０９におけるＭＵ－ＡＣＫフレームの送受信までのＭＵ通信の間を、ＮＡＶの期間として設定することができる。Ｍ７０７～Ｍ７０９についてはＭ７０１～Ｍ７０３と同様であるため、説明を省略する。なお、図７の例では、レガシーＳＴＡ１４はＭＵ－ＲＴＳフレームを復調できると仮定したが、ＭＵ－ＲＴＳフレームを復調できない場合であっても、ＳＴＡ１２やＳＴＡ１５が送信するＣＴＳフレームを復調できる場合に、上述したように、ＮＡＶを適切に設定することが可能となる。

このように、実施形態１では、ＡＰは、周囲にレガシー機器が存在しないと判定された場合にＭＵ－ＲＴＳフレームを送信し、そうでない場合はＭＵ－ＲＴＳフレームを送信しない。これにより、レガシー機器や隠れ端末がＭＵ－ＲＴＳフレームやＣＴＳフレームを受信し得るため、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態２）
実施形態２におけるＭＵ通信準備処理を、図８を参照して説明する。図８は、実施形態２におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。まず、Ｓ８０１で通信解析部４０２は、これから開始するＭＵ通信がＵＬ（アップリンク）かＤＬ（ダウンリンク）かを判定する。開始するＭＵ通信がＵＬの場合（Ｓ８０１でＹＥＳ）、Ｓ８０２でレガシー機器検出部４０３は、レガシー機器が存在するかどうかを判定する。当該判定処理は、図５のＳ５０１における監視結果を用いて行われ得る。レガシー機器が存在すると判定された場合は（Ｓ８０２でＹＥＳ）、Ｓ８０４で送受信部４０１は、ＭＵ－ＲＴＳフレームを送信し、Ｓ８０６で送受信部４０１は対向のＳＴＡからＣＴＳフレームを受信し、終了する。レガシー機器が存在しないと判定された場合は（Ｓ８０２でＮＯ）、Ｓ８０３にてエラー管理部４０４は、ＭＵ通信がエラー状態かを判定する。当該判定処理は、エラー管理部４０４が管理しているＳＴＡごとのＭＵ送信のエラー回数または連続エラー回数をもとに行われ得る。例えば、ＭＵ ＵＬ通信の対象ＳＴＡに対する連続エラー回数がｎ回（例えばｎ＝３）のときに、エラー管理部４０４は、ＭＵ通信がエラー状態であると判定することができる。ただしエラー判定の方法はこれに限定されず、累計エラー回数がｍ回（例えばｍ＝１０）などとしても良い。Ｓ８０３でエラー状態と判定された場合は（Ｓ８０３でＹＥＳ）、Ｓ８０４で送受信部４０１はＭＵ－ＲＴＳを送信し、Ｓ８０６で送受信部４０１は対向のＳＴＡからＣＴＳフレームを受信し、終了する。Ｓ８０３でエラー状態と判定されなかった場合（Ｓ８０３でＮＯ）、Ｓ８０５でＡＰ１３はＭＵ－ＲＴＳを送信せずに終了する。Ｓ８０１にてＤＬと判定された場合は（Ｓ８０１でＮＯ）、Ｓ８０４にて送受信部４０１は、ＭＵ－ＲＴＳフレームを送信し、Ｓ８０６にて対向のＳＴＡからＣＴＳフレームを受信し、終了する。

なお、ＡＰ１３は、Ｓ８０２でＹＥＳのとき、ＭＵ通信において通信するデータサイズが所定の閾値より大きいかを判定するようにし、当該データサイズが当該閾値より場合に、Ｓ８０４で送受信部４０１が、ＭＵ－ＲＴＳフレームを送信してもよい。当該データサイズは、例えば、ＵＬ ＰＰＤＵのサイズである。また、Ｓ８０２でＹＥＳのとき、送受信部４０１がＣＴＳ－ｔｏ－ｓｅｌｆ機能に基づいてＣＴＳフレームを送信し、レガシー機器（レガシーＳＴＡ１４）にＮＡＶを設定させてもよい。この場合、ＣＴＳ－ｔｏ－ｓｅｌｆ機能に基づくＣＴＳフレームの送信によってもエラー管理部４０４によりエラーがＭＵ通信がエラー状態と判断された場合に、Ｓ８０４で送受信部４０１が、ＭＵ－ＲＴＳフレームを送信してもよい。

続いて、図９を用いて、本実施形態におけるＵＬ ＭＵ通信のシーケンスについて説明する。図９は、本実施形態におけるＡＰ１３が実行するＵＬ ＭＵ通信処理の流れの例を示す図である。ＡＰ１３、ＳＴＡ１２、及びＳＴＡ１５は、それぞれ図１に示すように配置されているものとする。なお、ＳＴＡ１１、レガシーＳＴＡ１４、及びＳＴＡ１９については本シーケンス図からは省略する。

本シーケンス開始時には、ＡＰ１３のレガシー機器検出部４０３は、レガシー機器を検出していない状態と仮定する。ＡＰ１３は、ＵＬ ＭＵ通信を開始する際、Ｓ５０１、Ｓ５０２を経てＭＵ－ＲＴＳを送信せずにＳ５０３～Ｓ５０６のＵＬ ＭＵ通信処理を開始する。ＵＬのＭＵ通信処理では、Ｍ９０１でＡＰ１３は、ＴｒｉｇｇｅｒフレームをＭＵ対象のＳＴＡ１２とＳＴＡ１５に送信し、ＲＵの割り当てを行う（Ｓ５０４）。ＳＴＡ１２とＳＴＡ１５は、それぞれ割り当てられたＲＵを用いてＭ９０２においてＵＬ ＰＰＤＵをＡＰ１３に送信を試みる（Ｓ５０５）。

ここでＳＴＡ１５からのＵＬ ＰＰＤＵがＡＰ１３に到達しない場合を想定する。この場合、Ｍ９０３においてＡＰ１３は、ＳＴＡ１２のみに対してＭＵ ＡＣＫフレームを送信する（Ｓ５０６）。ここで、ＡＰ１３のエラー管理部４０４は、ＵＬ ＭＵ通信がＳＴＡ１５に対して失敗したと判定し、ＳＴＡ１５に対するエラー回数をカウントアップする。なお、ＳＴＡ１５に対するＭＵ通信のエラーはＡＰ１３がＵＬ ＭＵフレーム（ＰＰＤＵ等）を対象ＳＴＡから受信できたか否かで判定され、Ｍ９０１におけるＴｒｉｇｇｅｒフレームがＳＴＡ１５に届かなかった場合も同様にエラーとして処理され得る。エラー管理部４０４において、エラー回数は連続エラー回数と累計エラー回数のどちらか、もしくは両方を管理しても良い。連続エラー回数は当該ＳＴＡからのＵＬ ＰＰＤＵが受信されたときに０回にリセットされる。累計エラー回数も一定時間内の累計回数としても良い。その場合エラー発生から一定時間が経過すると、その分の累計回数はデクリメントされても良い。

レガシー機器が検出されていない状態でのＵＬ ＭＵ通信は、Ｍ９０１～Ｍ９０３の処理が繰り返し実行されることで、ＭＵ－ＲＴＳ／ＣＴＳ処理によるオーバーヘッドなしに、ＵＬ ＭＵ通信を行うことができる。ここで、エラー管理部４０４が、連続エラー回数が３回のときに、Ｓ８０３ではエラー状態と判定する設定であり、Ｍ９０１～Ｍ９０３の処理が３回連続で発生したと仮定する。このとき、以降のＵＬ ＭＵ通信において、Ｓ５０２内のＳ８０３でＭＵ通信エラー状態であると判定され、Ｍ９０４においてＡＰ１３はＭＵ－ＲＴＳを送信する（Ｓ８０４）。ＭＵ－ＲＴＳフレームを受信したＳＴＡ１２とＳＴＡ１５は、Ｍ９０５でＣＴＳフレームをＡＰ１３に送信する。Ｍ９０６～Ｍ９０８についてはＭ７０１～Ｍ７０３と同様なので説明を省略する。

このように、実施形態２では、ＡＰの周辺にレガシー機器が存在しない場合であっても、ＭＵ通信の成功確率が低い状況において、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ－ＲＴＳを送信する。これにより、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

３０１：記憶部、３０２：制御部、３０６：通信部、３０７：アンテナ、４０１：送受信部、４０２：通信解析部、４０３：レガシー機器検出部、４０４：エラー管理部、４０５：ＵＩ制御部

Claims (15)

1. １以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能なＩＥＥＥ８０２．１１ａｘ規格に対応し、特定のＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）で外部から識別されるアクセスポイントとして機能する通信装置であって、
   前記マルチユーザ通信がアップリンクにおける通信の場合に、前記ＩＥＥＥ８０２．１１ａｘ規格より前のＩＥＥＥ８０２．１１シリーズの規格に対応するが、前記ＩＥＥＥ８０２．１１ａｘ規格をサポートしない装置であるＩＥＥＥ８０２．１１ａｘ非サポート機器が前記特定のＢＳＳに属するか否かに関わらず前記通信装置の周囲に存在するかを外部から取得した情報に基づいて判定する判定手段と、
   前記判定手段により前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定された場合に、前記マルチユーザ通信によるデータ通信の前に、ＭＵ－ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信する送信手段と、
   を有することを特徴とする通信装置。
2. 前記送信手段は、前記判定手段により前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定されなかった場合に、前記ＭＵ－ＲＴＳフレームを送信しないことを特徴とする請求項１に記載の通信装置。
3. 前記マルチユーザ通信がエラー状態か否かを判定するエラー管理手段を更に有し、
   前記送信手段は、前記判定手段により前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定されなかった場合であっても、前記エラー管理手段により前記マルチユーザ通信がエラー状態と判定された場合は、前記ＭＵ－ＲＴＳフレームを送信することを特徴とする請求項１または２に記載の通信装置。
4. 前記エラー管理手段は、前記ＭＵ－ＲＴＳフレームを送信する対象の他の装置から送信されるデータパケットが受信されなかった場合にカウントするエラーの回数が所定の閾値を上回る場合に、前記マルチユーザ通信がエラー状態であると判定することを特徴とする請求項３に記載の通信装置。
5. 前記エラーの回数は、連続のエラー回数または累計のエラー回数であることを特徴とする請求項４に記載の通信装置。
6. 無線フレームを受信する受信手段と、
   前記判定手段は、前記受信手段で受信したＭａｎａｇｅｍｅｎｔフレームを構成する情報に基づいて、前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在するかを判定することを特徴とする請求項１から５のいずれか１項に記載の通信装置。
7. 前記判定手段は、前記ＭａｎａｇｅｍｅｎｔフレームにＨＥ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ） Ｃａｐａｂｉｌｉｔｉｅｓ Ｅｌｅｍｅｎｔが含まれない場合に、前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在することを判定することを特徴とする請求項６に記載の通信装置。
8. 前記判定手段は、前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定した場合に、更に、前記マルチユーザ通信において通信されるデータサイズが所定の閾値より大きいかを判定し、前記送信手段は、前記判定手段により前記データサイズが前記所定の閾値より大きいと判定された場合に、前記ＭＵ－ＲＴＳフレームを送信することを特徴とする請求項１から７のいずれか１項に記載の通信装置。
9. 前記送信手段は、前記判定手段により前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定された場合に、Ｔｒｉｇｇｅｒフレームを送信する前に、前記ＭＵ－ＲＴＳフレームを送信することを特徴とする請求項１から７のいずれか１項に記載の通信装置。
10. 前記マルチユーザ通信がダウンリンクにおける通信の場合、前記送信手段は、前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在しているかどうかに関わらず、前記マルチユーザ通信によるデータ通信の前に、前記ＭＵ－ＲＴＳフレームを送信することを特徴とする請求項１から９のいずれか１項に記載の通信装置。
11. 前記通信装置は、印刷機能を有する印刷装置であり、前記アクセスポイントとして機能する印刷装置は、前記アクセスポイントを介して外部機器から受信したデータに基づき印刷処理を行うことを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
12. 前記通信装置は、投影機能を有する投影装置であり、前記アクセスポイントとして機能する投影装置は、前記アクセスポイントを介して外部機器から受信したデータに基づき投影部への投影処理を行うことを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
13. 前記投影装置はプロジェクタであることを特徴とする請求項１２に記載の通信装置。
14. １以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能なＩＥＥＥ８０２．１１ａｘ規格に対応し、特定のＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）で外部から識別されるアクセスポイントとして機能する通信装置の制御方法であって、
    前記マルチユーザ通信がアップリンクにおける通信の場合に、前記ＩＥＥＥ８０２．１１ａｘ規格より前のＩＥＥＥ８０２．１１シリーズの規格に対応するが、前記ＩＥＥＥ８０２．１１ａｘ規格をサポートしない装置であるＩＥＥＥ８０２．１１ａｘ非サポート機器が前記特定のＢＳＳに属するか否かに関わらず前記通信装置の周囲に存在するかを外部から取得した情報に基づいて判定する判定工程と、
    前記判定工程において前記ＩＥＥＥ８０２．１１ａｘ非サポート機器が前記通信装置の周囲に存在すると判定された場合に、前記マルチユーザ通信によるデータ通信の前に、ＭＵ－ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信する送信工程と、
    を有することを特徴とする通信装置の制御方法。
15. コンピュータを、請求項１から１３のいずれか１項に記載の通信装置として機能させるためのプログラム。

Images