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

Abstract

【課題】マルチユーザ通信において、効率的に干渉抑制制御を行う。【解決手段】１以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能な通信装置は、該マルチユーザ通信により送信または受信する予定の信号に基づいてＭＵ−ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信するかを決定し、該ＭＵ−ＲＴＳフレームを送信すると決定された場合に、該マルチユーザ通信の前に該ＭＵ−ＲＴＳフレームを送信する。【選択図】図８

Description

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

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

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

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

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

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

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

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

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

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

上記目的を達成するため、本発明の一態様に係る通信装置は、以下の構成を有する。すなわち、１以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能な通信装置であって、前記マルチユーザ通信により送信または受信する予定の信号に基づいてＭＵ−ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信するかを決定する決定手段と、前記決定手段により前記ＭＵ−ＲＴＳフレームを送信すると決定された場合に、前記マルチユーザ通信の前に前記ＭＵ−ＲＴＳフレームを送信する送信手段と、を有する。

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

実施形態におけるネットワーク構成例を示す。 実施形態におけるＡＰのハードウェア構成例を示す。 実施形態におけるＡＰの機能構成例を示す。 実施形態においてＡＰが実行するＭＵ通信処理の流れの例を示す。 実施形態１−１における、ＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態１−２におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態１−３におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態２−１におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態２−２におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態３−１におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 実施形態３におけるＴｒｉｇｇｅｒフレーム種別に対するＭＵ−ＲＴＳフレーム送信実行有無の対応表を示す。 実施形態３−２におけるＡＰが実行するＭＵ通信準備処理の流れの例を示す。 ＡＰが実行するＵＬ ＭＵ通信処理の流れの例を示す。 ＡＰが実行するＤＬ ＭＵ通信処理の流れの例を示す。

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

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

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

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

一方、上述したようにＭＵ−ＲＴＳ／ＣＴＳ処理はデータ通信に対するオーバーヘッドになるため、すべてのＭＵ ＵＬ通信時にＭＵ−ＲＴＳ／ＣＴＳ処理を実施すると帯域の使用効率を低下させてしまう。以下に説明するいくつかの実施形態では、直後に行われるＭＵ通信における信号の特徴に応じてＭＵ−ＲＴＳ送信を行うか行わないかを切り替える処理について説明する。当該特徴としては、通信するデータのサイズ（実施形態１）、通信で帯域を使用する期間の長さ（実施形態２）、通信に使用するＴｒｉｇｇｅｒフレームの種別（実施形態３）のいずれか、またはその複数が利用される。

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

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

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

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

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

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

図３は、以下に説明するいくつかの実施形態におけるＡＰ１３の機能構成例を示す。ＡＰ１３は、その機能構成の一例として、送受信部３０１、通信解析部３０２、データサイズ決定部３０３、使用時間決定部３０４、判定部３０５、エラー管理部３０６、及びＵＩ制御部３０７を有する。

送受信部３０１は、通信部２０６（図２）を制御し、信号の送受信を行う。例えば送受信部３０１は、指定された周波数チャネルにおいて、ＭＵ−ＲＴＳを送信する。通信解析部３０２は、対向機との間の通信の内容を解析する。データサイズ決定部３０３は、ＭＵ−ＲＴＳフレームを送信するか否かを決定するために必要なデータサイズを、例えば計算処理により決定する。使用時間決定部３０４は、ＭＵ−ＲＴＳフレームを送信するか否かを決定するために必要な帯域使用時間を、例えば計算処理により決定する。判定部３０５は、マルチユーザ通信により送信または受信する予定の信号に基づいて、ＭＵ−ＲＴＳフレームを送信するか否かについての判定（決定）を行う。エラー管理部３０６は、ＭＵ通信が成功せずにエラーとなってしまった回数や連続エラー回数を管理する。エラーの判定方法としては、ＵＬ ＭＵ通信の場合、対向ＳＴＡからのＵＬ ＭＵパケットが受信されない場合にエラーと判定することができる。例えば、特定ＳＴＡからＵＬ ＭＵパケットが連続でｎ回（ｎ＝３など）受信できなかった場合に当該ＳＴＡに対するＵＬ ＭＵ通信がエラー状態と判定しても良い。ＤＬ（ダウンリンク） ＭＵ通信の場合、対向ＳＴＡからのＡＣＫが受信されない場合にエラーと判定することができる。こちらもＵＬ（アップリンク） ＭＵ通信と同様に、連続エラー回数でエラー状態を判定しても良い。連続エラー回数は通信が成功すると０にリセットされる。ＵＩ制御部３０７は、ＡＰ１３の不図示のユーザによるＡＰ１３に対する操作を受け付けるためのタッチパネル又はボタン等のユーザインタフェースに関わるハードウェアおよびそれらを制御するプログラムを含んで構成される。

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

本処理では、ＡＰ１３は、まずＭＵ通信準備処理を開始する（Ｓ４０１）。本処理については、図５〜図１１を用いて後述する。その後、ＡＰ１３は、ＭＵ通信処理を開始し、８０２．１１ａｘ規格で定められた仕様に従ってＭＵ通信を実行する。すなわち、まずＳ４０２で、通信解析部３０２は、開始するＭＵ通信がＵＬ ＭＵ通信かＤＬ ＭＵ通信かを判別する。開始するＭＵ通信がＵＬ ＭＵ通信の場合は（Ｓ４０２でＹＥＳ）、Ｓ４０３で送受信部３０１は、Ｔｒｉｇｇｅｒフレームを送信し、対向の各ＳＴＡにＲＵ（Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）の割り当てを行う。次にＳ４０４において、送受信部３０１は、各ＳＴＡよりマルチユーザ通信におけるアップリンクのＰＰＤＵ（以下、ＵＬ ＰＰＤＵ）を受信したか否かを判定する。ＵＬ ＰＰＤＵは、例えば、ＵＬ ＨＥ ＭＵ ＰＰＤＵ（Ｕｐｌｉｎｋ Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ Ｍｕｌｔｉ−ｕｓｅｒ ｐｈｙｓｉｃａｌ ｌａｙｅｒ （ＰＨＹ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）である。

特定のＳＴＡからＵＬ ＰＰＤＵを受信したと判定した場合には（Ｓ４０４でＹＥＳ）、Ｓ４０５でエラー管理部３０６は、そのＳＴＡに対応する連続エラー回数をリセットする。そして、Ｓ４０６で送受信部３０１は、そのＳＴＡにＭＵ ＡＣＫフレームを送信する。最後にＳ４０６にて、送受信部３０１は、ＵＬ ＭＵデータの受信の確認応答としてＭＵ ＡＣＫフレームを対向の各ＳＴＡに向けて送信し、終了する。一方、特定のＳＴＡからＵＬ ＰＰＤＵを受信しなかったと判定した場合には（Ｓ４０４でＮＯ）、Ｓ４０７でエラー管理部３０６は、そのＳＴＡに対応するエラー回数（累計エラー回数と連続エラー回数の両方）をインクリメントする。最後にＳ４０６にて、送受信部３０１は、ＵＬ ＭＵデータの受信の確認応答としてＭＵ ＡＣＫ処理を行う。Ｓ４０７からのＳ４０６におけるＭＵ ＡＣＫ処理としては、ＭＵ ＡＣＫフレームを送信する場合と送信しない場合がある。ＭＵ ＡＣＫフレームがＢＬＯＣＫ ＡＣＫ方式で送信される場合は、送受信部３０１は、ＢＬＯＣＫ ＡＣＫのうち、受信したＡ−ＭＰＤＵに対応するビットを立てることで、どのＡ−ＭＰＤＵを受信したかをＳＴＡに通知することができる。Ａ−ＭＰＤＵが受信されなかった場合に、送受信部３０１は、対応するビットを立てずにＢＬＯＣＫ ＡＣＫフレームを送信することで、データを受信できなかったことを通知することができる。一方、ＭＵ ＡＣＫフレームがＢＬＯＣＫ ＡＣＫ方式で送信されない場合は、送受信部３０１は、データを受信した際にＡＣＫフレームを返し、受信しなかった際はＡＣＫフレームを返さないという制御を行うことで、ＳＴＡにデータを受信したか、していないかを通知することができる。よって、Ｓ４０６で送受信部３０１は、ＢＬＯＣＫ ＡＣＫ方式の場合はＭＵ ＡＣＫフレームを送信し、そうでない場合はＭＵ ＡＣＫフレームを送信しない。なお、Ｓ４０４、Ｓ４０５およびＳ４０７の処理は、ＴｒｉｇｇｅｒフレームにおいてＲＵを割り当てた各ＳＴＡについて行われる。

一方、Ｓ４０２でＤＬ ＭＵ通信と判定された場合（Ｓ４０２でＮＯ）、Ｓ４０８にて送受信部３０１は、マルチユーザ通信におけるアップリンクのＰＰＤＵ（以下、ＤＬ ＰＰＤＵ）を対向の各ＳＴＡに送信する。ＤＬ ＰＰＤＵは、例えば、ＤＬ ＨＥ ＭＵ ＰＰＤＵ（Ｄｏｗｎｌｉｎｋ Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ Ｍｕｌｔｉ−ｕｓｅｒ ｐｈｙｓｉｃａｌ ｌａｙｅｒ （ＰＨＹ） ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）である。Ｓ４０９で、送受信部３０１は、対向の各ＳＴＡより確認応答としてＡＣＫフレームを受信したか否かを判定する。特定のＳＴＡからＡＣＫフレームを受信したと判定した場合には（Ｓ４０９でＹＥＳ）、Ｓ４１１でエラー管理部３０６は、そのＳＴＡに対応する連続エラー回数をリセットし、終了する。特定のＳＴＡからＡＣＫフレームを受信しなかったと判定した場合には（Ｓ４０９でＮＯ）、Ｓ４１０でエラー管理部３０６は、そのＳＴＡに対応するエラー回数（累計エラー回数と連続エラー回数の両方）をインクリメントする。

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

（実施形態１）
実施形態１では、ＡＰ１３が、ＭＵ通信において通信するデータサイズに基づいて、ＭＵ−ＲＴＳを送信するか否かを切り替える処理について説明する。

（実施形態１−１）
実施形態１−１におけるＭＵ通信準備処理を、図５を参照して説明する。図５は、実施形態１−１におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。まず、Ｓ６０１で通信解析部３０２は、これから開始するＭＵ通信がＵＬ（アップリンク）かＤＬ（ダウンリンク）かを判定する。開始するＭＵ通信がＤＬの場合は（Ｓ５０１でＹＥＳ）、Ｓ５０２でデータサイズ決定部３０３は、データサイズを、送信予定のＤＬ ＰＰＤＵ のサイズに決定する。開始するＭＵ通信がＵＬの場合は（Ｓ５０１でＮＯ）、Ｓ５０３にてデータサイズ決定部３０３は、データサイズを、受信予定のＵＬ ＰＰＤＵのサイズに決定する。受信予定のＵＬ ＰＰＤＵのサイズは、（Ｓ４０３で送信する）ＴｒｉｇｇｅｒフレームのＣｏｍｍｏｎ Ｉｎｆｏフィールド内のＬｅｎｇｔｈフィールドに設定される値に一致するため、データサイズ決定部３０３は、これを利用しても良い。また、このＬｅｎｇｔｈフィールドの値は、各対向ＳＴＡの送信待ちデータ量から決定され得る。各ＳＴＡの送信待ちデータ量はＢｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ（ＢＳＲ）にてＡＰ１３へ通知され得る。送受信部３０１がＢＳＲを受信していない場合には、ＢＳＲＰ Ｔｒｉｇｇｅｒフレームを各ＳＴＡへ送信し、ＢＳＲを要求しても良い。なお、複数のＳＴＡ向けにＴｒｉｇｇｅｒフレームにおいてＲＵを割り当てる場合、当該複数のＳＴＡのうち、最も送信待ちデータ量が多いＳＴＡの送信待ちデータ量に基づいて、データサイズを決定することができる。

Ｓ５０２またはＳ５０３でデータサイズが決定すると、Ｓ５０４にて判定部３０５は、決定したデータサイズがあらかじめ設定されたＲＴＳ閾値を超えるかどうかを判定する。ＲＴＳ閾値は、ＳＵ（Ｓｉｎｇｌｅ Ｕｓｅｒ）用とＭＵ用で同じ値でも良いし、別の値でも良い。ＭＵの場合は、ＡＰ１３は、複数の対向ＳＴＡとやりとりする分、隠れ端末の影響により通信が失敗する確率がＳＵの場合より高いと想定される。このことを考慮して、ＭＵ用のＲＴＳ閾値をＳＵ用のＲＴＳ閾値よりも小さな値に設定しても良い。決定したデータサイズがＲＴＳ閾値を超える場合（Ｓ５０４でＹＥＳ）、Ｓ５０５にて送受信部３０１は、ＭＵ−ＲＴＳフレームを送信し、Ｓ５０６にてＣＴＳフレームを受信し終了する。ここで、送受信部３０１は、ＭＵ−ＲＴＳフレームをＨＴ ＰＰＤＵの形式で送信しても良いし、ｎｏｎ―ＨＴ ＰＰＤＵの形式で送信しても良い。一方、決定したデータサイズがＲＴＳ閾値を超えない場合（Ｓ５０４でＮＯ）、Ｓ５０７にてＡＰ１３はＭＵ−ＲＴＳフレームを送信せずに終了する。

このように、実施形態１−１では、これから開始するＭＵ通信に対して決定したデータサイズがＲＴＳ閾値を超える場合はＭＵ−ＲＴＳを送信し、そうでない場合はＭＵ−ＲＴＳを送信しない。すなわち、ＭＵ通信において、より長い期間を占有するデータを送受信する際に、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳを送信する。これにより、隠れ端末がＣＴＳフレームを受信し得るため、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態１−２）
実施形態１−２におけるＭＵ通信準備処理を、図６を参照して説明する。図６は、実施形態１−２におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ６０１及びＳ６０４〜Ｓ６０７は、実施形態１−１で説明した図５のＳ５０１及びＳ５０４〜Ｓ５０７とそれぞれ同じ処理のため、説明を省略する。

開始するＭＵ通信がＤＬの場合（Ｓ６０１でＹＥＳ）、Ｓ６０２でデータサイズ決定部３０３は、データサイズを、送信予定のＤＬ ＰＰＤＵのサイズと、ＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）に相当するサイズと、ＡＣＫフレームのサイズとの合計に決定する。

ＳＩＦＳは、使用するＰＨＹ仕様によって一意に決まる時間である。ＳＩＦＳに相当するサイズは、［ＳＩＦＳ×使用するデータレート］により計算することができる。データレートはＤＬ ＰＰＤＵの送信に使うレートを用いても良いし、ＰＨＹ仕様で定める最低レートを用いても良い。

ＡＣＫフレームのサイズは、対向ＳＴＡが送信してくると期待するＡＣＫフレームのサイズである。例えばＤＬ ＰＰＤＵに含まれるＭＰＤＵがただ一つであった場合は、対向ＳＴＡからＡＣＫフレームが送信されると期待される。一方、ＤＬ ＰＰＤＵに含まれるＭＰＤＵが複数の場合は、対向ＳＴＡからＢＬＯＣＫ ＡＣＫフレームが送信されると期待される。

ＡＣＫフレームの場合、ＭＡＣフレームは１４オクテットで規定され、これにＡＣＫフレーム送信に使用するＰＨＹ仕様に応じたプリアンブル、ヘッダが付与される。例えば８０２．１１ｂのロングフレームフォーマットを使用する際はＰＬＣＰプリアンブルが１４４ビット、ＰＬＣＰヘッダが４８ビット付与される。よって、１４４＋４８＋１４×８＝３０４ビット分のデータがＡＣＫフレームのサイズとなる。

ＢＬＯＣＫ ＡＣＫフレームの場合、ＭＡＣヘッダ部が１６オクテット、ＭＡＣボディ部はＢｌｏｃｋＡｃｋタイプによって可変長になる。例えばＭｕｌｔｉ−ＴＩＤ ＢｌｏｃｋＡｃｋの場合、ＢｌｏｃｋＡｃｋＢｉｔｍａｐが８オクテットとすると、１２オクテットのＰｅｒ ＡＩＤ ＴＩＤ Ｉｎｆｏが送信するＴＩＤの数分繰り返される。ＢＡ ＣｏｎｔｒｏｌフィールドとＦＣＳフィールドは合わせて６オクテットなので、ＭＡＣボディ部は６＋１２×ＴＩＤ数オクテットで計算できる。これに使用するＰＨＹ仕様に応じたプリアンブル、ヘッダが付与される。例えば８０２．１１ｂのロングフレームフォーマットを使用する際は１４４＋４８＋（１６＋６＋１２×ＴＩＤ）×８ビット分のデータがＢＬＯＣＫ ＡＣＫフレームのサイズとなる。

なお、ＡＣＫフレームのサイズは、別の方法でも算出可能である。例えば、ＤＬ ＰＰＤＵに含まれるＴＲＳ Ｃｏｎｔｒｏｌフィールドを利用して、ＤＬ ＰＰＤＵにＴｒｉｇｇｅｒフレームの役割を担わせる。これにより、ＤＬ ＰＰＤＵに対するＡＣＫフレームをＵＬ ＰＰＤＵとして各対向機に送信させることが可能になる。この場合、ＴＲＳ Ｃｏｎｔｒｏｌフィールドに含まれるＨＥ ＴＢ ＰＰＤＵ Ｌｅｎｇｔｈが後続のＡＣＫ部分に相当するサイズになるため、これを使ってデータサイズを算出することが可能となる。

一方、開始するＭＵ通信がＵＬの場合（Ｓ６０１でＮＯ）、Ｓ６０３でデータサイズ決定部３０３は、データサイズを、（Ｓ４０３で送信する）Ｔｒｉｇｇｅｒフレーム（ＴＦ）のサイズと、受信予定のＵＬ ＰＰＤＵのサイズと、その後に送信予定のＭＵ−ＡＣＫフレームのサイズと、２つのＳＩＦＳに相当するサイズとの合計に決定する。

Ｔｒｉｇｇｅｒフレームは、ＭＡＣヘッダ部が１６オクテット、ＭＡＣボディ部が１２＋ＵｓｅｒＩｎｆｏフィールド×ユーザ数＋パディング長でサイズが規定される。ＵｓｅｒＩｎｆｏフィールドは、固定長の５オクテット＋Ｔｒｉｇｇｅｒフレームタイプによって異なる可変部で規定される。ＵＬ ＭＵの開始に使用されるＢａｓｉｃ Ｔｒｉｇｇｅｒ Ｖａｒｉａｎｔでは、可変部は１オクテットで規定される。パディング長は、接続するＳＴＡの送信するＭａｎａｇｅｍｅｎｔフレームに含まれるＨＥ Ｃａｐａｂｉｌｉｔｉｅｓエレメントから規定される。ＨＥ Ｃａｐａｂｉｌｉｔｉｅｓエレメントには、２ビットのＴｒｉｇｇｅｒ Ｆｒａｍｅ ＭＡＣ Ｐａｄｄｉｎｇ Ｄｕｒａｔｉｏｎが含まれこの値によって各ＳＴＡがＡＰに要求するパディング長を規定する。値が０のときパディングなし、１のとき８μ秒、２のとき１６μ秒のパディング時間を要求する。ＡＰ１３は、ＵＬ ＭＵ通信の対象とする全ＳＴＡの要求のうち最大のものを採用してパディング長を決定する。パディング長は、パディング時間×使用するデータレートで計算される。

受信予定のＵＬ ＰＰＤＵのサイズは、実施形態１−１記載の方法と同様に決定できるため説明を省略する。また、送信予定のＭＵ−ＡＣＫフレームのサイズ、ＳＩＦＳに相当するサイズはＤＬの場合と同様であるため説明を省略する。

このように、実施形態１−２では、実施形態１−１と同様に、ＭＵ通信において、より長い期間を占有するデータを送受信する際に、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳを送信する。これにより、隠れ端末がＣＴＳフレームを受信し得るため、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態１−３）
実施形態１−３におけるＭＵ通信準備処理を、図７を参照して説明する。図７は、実施形態１−３におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ７０１のデータサイズの決定処理については、実施形態１−１で説明した図５のＳ５０１〜Ｓ５０３、もしくは実施形態１−２で説明した図６のＳ６０１〜Ｓ６０３のいずれかの処理を実行するものとする。また、Ｓ７０３、Ｓ７０４、Ｓ７０６は、実施形態１−１で説明した図５のＳ５０５、Ｓ５０６、Ｓ５０７とそれぞれ同じ処理のため説明を省略する。また、ＲＴＳ閾値については、実施形態１−１と同様に規定されるものとする。

Ｓ７０１で決定されたデータサイズがＲＴＳ閾値を超えるデータサイズと判定された場合は（Ｓ７０２でＹＥＳ）、処理はＳ７０３進む。一方、Ｓ７０１で決定されたデータサイズがＲＴＳ閾値を超えないと判定された場合は（Ｓ７０２でＮＯ）、Ｓ７０５にてエラー管理部３０６は、ＭＵ通信がエラー状態かを判定する。本判定は、エラー管理部３０６が、管理しているＳＴＡごとのＭＵ送信の累計エラー回数または連続エラー回数をもとに行う。例えば、対象のＳＴＡに対する連続エラー回数がｎ回（例えばｎ＝３）のときに、エラー管理部３０６はエラー状態と判定することができる。ただし、エラー判定の方法はこれに限定されず、累計エラー回数がｍ回（例えばｍ＝１０）などのときにエラーと判定しても良い。Ｓ７０５でエラー状態と判定された場合（Ｓ７０５でＹＥＳ）、処理はＳ７０３に進み、エラー状態と判定されなかった場合（Ｓ７０５でＮＯ）、処理はＳ７０６に進む。

このように、実施形態１−３では、決定したデータサイズがＲＴＳ閾値を超えなくても、ＭＵ通信の成功確率が低い状況において、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳを送信する。これにより、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態２）
実施形態１では、ＡＰ１３が、ＭＵ通信における帯域使用時間に基づいて、ＭＵ−ＲＴＳを送信するか否かを切り替える処理について説明する。

（実施形態２−１）
実施形態２−１におけるＭＵ通信準備処理を、図８を参照して説明する。図８は、実施形態２−１におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ８０１、Ｓ８０４〜Ｓ８０７は、実施形態１−１で説明した図５のＳ５０１、Ｓ５０４〜Ｓ５０７とそれぞれ同じ処理のため説明を省略する。ただし、Ｓ８０４におけるＲＴＳ閾値は、データサイズの閾値ではなく、帯域使用時間の閾値として規定される。

開始するＭＵ通信がＤＬの場合（Ｓ８０１でＹＥＳ）、Ｓ８０２で使用時間決定部３０４は、帯域使用時間を、ＤＬ ＰＰＤＵとＡＣＫフレームの時間とＳＩＦＳとの合計と決定する。この値は、ＤＬ ＰＰＤＵのＭＡＣヘッダ部に含まれるＤｕｒａｔｉｏｎフィールド値に設定される値を利用することができる。開始するＭＵ通信がＵＬの場合（Ｓ８０１でＮＯ）、Ｓ８０３で使用時間決定部３０４は、帯域使用時間を、ＴｒｉｇｇｅｒフレームとＵＬ ＰＰＤＵとＭＵ−ＡＣＫフレームの時間＋ＳＩＦＳ×２と決定する。この値は、ＴｒｉｇｇｅｒフレームのＭＡＣヘッダ部に含まれるＤｕｒａｔｉｏｎフィールド値に設定される値を利用することができる。

このように、実施形態２−１では、これから開始するＭＵ通信に対する帯域使用時間がＲＴＳ閾値を超える場合はＭＵ−ＲＴＳを送信し、そうでない場合はＭＵ−ＲＴＳを送信しない。すなわち、ＭＵ通信において、より長い期間を占有するデータを送受信する際に、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳを送信する。これにより、隠れ端末がＣＴＳフレームを受信し得るため、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態２−２）
実施形態２−２におけるＭＵ通信準備処理を、図９を参照して説明する。図９は、実施形態２−２におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ９０１の帯域使用時間の計算については、実施形態２−１で説明した図６のＳ８０２〜Ｓ８０３を実行する。Ｓ９０３〜Ｓ９０６は、実施形態１−３で説明した図７の７０３〜Ｓ７０６とそれぞれ同じ処理のため説明を省略する。また、Ｓ９０２については、実施形態２−１で説明した図８のＳ８０４と同じ処理のため説明を省略する。

このように、実施形態２−２では、決定した帯域使用時間がＲＴＳ閾値を超えなくても、ＭＵ通信の成功確率が低い状況において、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳを送信する。これにより、信号の衝突が起きる可能性を抑え、ＭＵ通信の成功確率を向上させることが可能となる。

（実施形態３）
実施形態３では、ＡＰ１３が、送信しようとしているＴｒｉｇｇｅｒフレームの種別を判断し、それに応じてＭＵ−ＲＴＳフレームを送信するかしないかを切り替える処理について説明する。

（実施形態３−１）
実施形態３−１におけるＭＵ通信準備処理を、図１０を参照して説明する。図１０は、実施形態３−１におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ１００５〜Ｓ１００７については、実施形態１において説明した図５のＳ５０５〜Ｓ５０７とそれぞれ同じ処理のため説明を省略する。

開始するＭＵ通信がＤＬの場合（Ｓ１００１でＹＥＳ）、処理はＳ１００２に進む。Ｓ１００２は、実施形態１〜２のＤＬ通信処理に準ずる。例えば実施形態１−１においてはＳ５０２以降のフローに従う。開始するＭＵ通信がＵＬの場合（Ｓ１００１でＮＯ）、Ｓ１００３にて、通信解析部３０２は、Ｔｒｉｇｇｅｒフレームの種別を判断する。図１１に、Ｔｒｉｇｇｅｒフレーム種別に対するＭＵ−ＲＴＳフレーム送信実行有無の対応表１１００を示す。通信解析部３０２は、図１１に示すような対応表１１００を参照することで、各Ｔｒｉｇｇｅｒフレーム種別に対するＭＵ−ＲＴＳの送信制御を切り替える。なお、図１１に示す対応表１１００は一例であり、これに限定されない。また、この対応表１１００は動的に更新されても良い。また、Ｔｒｉｇｇｅｒフレーム種別とＭＵ−ＲＴＳ送信との関係は、各Ｔｒｉｇｇｅｒフレームに対する応答に使用されるデータサイズや帯域使用時間をもとに規定してもよい。例えば、Ｔｒｉｇｇｅｒフレームに対する応答がとりうる最大のサイズを計算し、当該サイズが、設定したＲＴＳ閾値を上回る場合にＭＵ−ＲＴＳを送信するように規定しても良い。図１１に示す対応表１１００を用いると、Ｓ１００３でこれから送るＴｒｉｇｇｅｒフレームの種別がＢａｓｉｃタイプと判断された場合、Ｓ１００４で通信解析部３０２は、当該Ｔｒｉｇｇｅｒフレームの種別がＭＵ−ＲＴＳ送信に対応すると判断し、処理はＳ１００５に進む。一方、Ｓ１００３でこれから送るＴｒｉｇｇｅｒフレームの種別がＢＦＲＰタイプと判断された場合、Ｓ１００４で通信解析部３０２は、当該Ｔｒｉｇｇｅｒフレームの種別がＭＵ−ＲＴＳ送信に対応しないと判断し、処理はＳ１００７に進む。

このように、実施形態３−１では、Ｔｒｉｇｇｅｒフレーム種別とＭＵ−ＲＴＳ制御の対応表を用いることで、データサイズや帯域使用時間を決定することなく、ＭＵ−ＲＴＳの送信制御を切り替えることが可能となる。

（実施形態３−２）
実施形態３−２におけるＭＵ通信準備処理を、図１２を参照して説明する。図１２は、実施形態３−２におけるＡＰ１３が実行するＭＵ通信準備処理の流れの例を示す。Ｓ１２０１〜Ｓ１２０３は、実施形態３−１において説明した図１０のＳ１００１〜Ｓ１００３、Ｓ１２０５〜１２０８は、実施形態１−３において説明した図７のＳ７０３〜Ｓ７０６とそれぞれ同様の処理のため説明を省略する。Ｓ１２０４で、これから送るＴｒｉｇｇｅｒフレームの種別がＭＵ−ＲＴＳ送信に対応しない判断された場合、処理はＳ１２０７に進む。

このように、実施形態３−２では、ＭＵ通信の成功確率が低い状況において、対向ＳＴＡの先に存在するかもしれない隠れ端末へのＮＡＶ設定を目的としたＭＵ−ＲＴＳフレームを送信することで、ＭＵ通信の成功確率を上昇させることが可能となる。

［ＡＰと各ＳＴＡの処理の流れ］
図１３を用いて、上記の実施形態を活用したＵＬ ＭＵ通信のシーケンスについて説明する。図１３は、ＡＰ１３が実行するＵＬ ＭＵ通信処理の流れの例を示す図である。ＡＰ１３、ＳＴＡ１１、ＳＴＡ１２、ＳＴＡ１４については、それぞれ図１に示すように配置されているものとする。ＡＰ１３は、ＵＬ ＭＵ通信を開始する際、実施形態１〜３に記載のＭＵ通信準備処理のいずれかを行い、ＭＵ−ＲＴＳフレームを送るか否かを判断する。Ｍ１３０１から始まるＭＵ通信ではＭＵ−ＲＴＳフレームを送らないと判断したと仮定する。一方、Ｍ１３０４から始まるＭＵ通信ではＭＵ−ＲＴＳフレームを送ると判断したと仮定する。

Ｍ１３０１でＡＰ１３は、ＭＵ−ＲＴＳフレームの送信なしにＴｒｉｇｇｅｒフレームの送信を行う。ここでＭＵ ＵＬ通信の対象はＳＴＡ１１とＳＴＡ１２とする。Ｔｒｉｇｇｅｒフレームを受信したＳＴＡ１１とＳＴＡ１２は、Ｍ１３０２にて割り当てられたＲＵ（Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）を用いてＵＬ ＰＰＤＵをＡＰ１３宛に送信する。ここでＳＴＡ１２からのＵＬ ＰＰＤＵはＡＰ１３に届かなかったとする。その場合、ＡＰ１３は、ＳＴＡ１２向けのエラー回数をインクリメントしエラー回数を管理する。Ｍ１３０３においてＡＰ１３は、ＭＵ ＡＣＫフレームをＳＴＡ１１とＳＴＡ１２に送信し、ＭＵ通信を終了する。ＡＰ１３は、ＳＴＡ１２からのＵＬ ＰＰＤＵを受信できなかったので、ＢＬＯＣＫ ＡＣＫフレームの対応するＢＬＯＣＫ ＡＣＫを０にして、未受信である旨を通知しても良い。ここで、ＡＰ１３は、ＳＴＡ１２からのＵＬ ＰＰＤＵを受信できなかったので、再度、Ｔｒｉｇｇｅｒフレームを送信して、ＳＴＡ１２にＵＬ ＰＰＤＵの再送を要求しても良い。

Ｍ１３０４でＡＰ１３は、Ｔｒｉｇｇｅｒフレームの送信前にＭＵ−ＲＴＳフレームの送信を行う。ＭＵ−ＲＴＳフレームを受信したＳＴＡ１１とＳＴＡ１２は、自身がＭＵ通信の対象であることを判断し、Ｍ１３０５でＣＴＳフレームを送信する。ＳＴＡ１１が送信するＣＴＳフレームはＳＴＡ１４にも受信され、これによりＳＴＡ１４のＮＡＶにＭＵ通信期間が設定される。ＣＴＳフレームを受信したＡＰ１３は、Ｍ１３０６からＴｒｉｇｇｅｒフレームの送信を行う。Ｔｒｉｇｇｅｒフレームを受信したＳＴＡ１１とＳＴＡ１２は、Ｍ１３０７にて割り当てられたＲＵを用いてＵＬ ＰＰＤＵをＡＰ１３宛に送信する。ここでＡＰ１３は、ＳＴＡ１２向けの連続エラー回数をリセットする。ＵＬ ＰＰＤＵを受信したＡＰ１３は、Ｍ１３０８においてＭＵ ＡＣＫフレームをＳＴＡ１１とＳＴＡ１２へ送信し、ＭＵ通信を終了する。

次に、図１４を用いて、上記の実施形態を活用したＤＬ ＭＵ通信のシーケンスについて説明する。図１３は、ＡＰ１３が実行するＤＬ ＭＵ通信処理の流れの例を示す図である。ＡＰ１３、ＳＴＡ１１、ＳＴＡ１２、ＳＴＡ１４については、それぞれ図１に示すように配置されているものとする。ＡＰ１３は、ＤＬ ＭＵ通信を開始する際、実施形態１〜３に記載のＭＵ通信準備処理のいずれかを行い、ＭＵ−ＲＴＳフレームを送るか否かを判断する。Ｍ１４０１から始まるＭＵ通信ではＭＵ−ＲＴＳフレームを送らないと判断したと仮定する。一方、Ｍ１４０３から始まるＭＵ通信ではＭＵ−ＲＴＳフレームを送ると判断したと仮定する。

Ｍ１４０１でＡＰ１３は、ＭＵ−ＲＴＳフレームの送信なしにＤＬ ＰＰＤＵの送信を行う。ここでＭＵ ＤＬ通信の対象はＳＴＡ１１とＳＴＡ１２とする。ＤＬ ＰＰＤＵを受信したＳＴＡ１１とＳＴＡ１２は、それぞれＭ１４０２にてＡＰ１３にＡＣＫフレームを送信する。このＡＣＫフレームは、Ｍ１４０１で受信したＤＬ ＰＰＤＵ内にＴＲＳ Ｃｏｎｔｒｏｌサブフィールドがある場合、当該フィールドで割り当てられたＲＵを用いて送信される。ここでＡＰ１３は、ＳＴＡ１２からのＡＣＫフレームを受信できなかったとする。その場合、ＡＰ１３は、ＳＴＡ１２向けのエラー回数をインクリメントしエラー回数を管理する。

Ｍ１４０３でＡＰ１３は、ＤＬ ＰＰＤＵの送信前にＭＵ−ＲＴＳフレームの送信を行う。ＭＵ−ＲＴＳフレームを受信したＳＴＡ１１とＳＴＡ１２は、自身がＭＵ通信の対象であることを判断し、Ｍ１３０５でＣＴＳフレームを送信する。ＳＴＡ１１が送信するＣＴＳフレームはＳＴＡ１４にも受信され、これによりＳＴＡ１４のＮＡＶにＭＵ通信期間が設定される。ＣＴＳフレームを受信したＡＰ１３は、Ｍ１４０５からＤＬ ＰＰＤＵの送信を行う。ＤＬ ＰＰＤＵを受信したＳＴＡ１１とＳＴＡ１２は、ＡＰ１３宛にＡＣＫフレームを送信する。このＡＣＫフレームはＭ１４０１内にＴＲＳ Ｃｏｎｔｒｏｌサブフィールドがある場合、当該フィールドで割り当てられたＲＵを用いて送信される。ここでＡＰ１３は、ＳＴＡ１２向けの連続エラー回数をリセットし、ＭＵ通信を終了する。

このように、上記に述べた実施形態によれば、通信装置の通信に対する干渉抑制制御を直後の通信内容に応じて適切に実行させることができる。

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

２０１：記憶部、２０２：制御部、２０３：機能部、２０４：入力部、２０５：出力部、２０６：通信部、２０７：アンテナ、３０１：送受信部、３０２：通信解析部、３０３：データサイズ決定部、３０４：使用時間決定部、３０５：判定部、３０６：エラー管理部、３０７：ＵＩ制御部

Claims (16)

1. １以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能な通信装置であって、
   前記マルチユーザ通信により送信または受信する予定の信号に基づいてＭＵ−ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信するかを決定する決定手段と、
   前記決定手段により前記ＭＵ−ＲＴＳフレームを送信すると決定された場合に、前記マルチユーザ通信の前に前記ＭＵ−ＲＴＳフレームを送信する送信手段と、
   を有することを特徴とする通信装置。
2. 前記決定手段は、前記マルチユーザ通信において送信または受信する予定の信号のデータサイズが所定の閾値を超える場合に、前記ＭＵ−ＲＴＳフレームを送信することを決定することを特徴とする請求項１に記載の通信装置。
3. 前記マルチユーザ通信がアップリンクにおける通信の場合、前記データサイズは、ＵＬ（アップリンク） ＰＰＤＵ （ＰＬＣＰ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）のサイズであることを特徴とする請求項２に記載の通信装置。
4. 前記マルチユーザ通信がアップリンクにおける通信の場合、前記データサイズは、Ｔｒｉｇｇｅｒフレームのサイズと、ＵＬ ＰＰＤＵのサイズと、ＭＵ−ＡＣＫフレームのサイズと、２つのＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）に相当するサイズとの合計であることを特徴とする請求項２に記載の通信装置。
5. 前記マルチユーザ通信がダウンリンクにおける通信の場合、前記データサイズは、ＤＬ ＰＰＤＵのサイズであることを特徴とする請求項２に記載の通信装置。
6. 前記マルチユーザ通信がダウンリンクにおける通信の場合、前記データサイズは、ＤＬ ＰＰＤＵのサイズと、ＡＣＫフレームのサイズと、ＳＩＦＳに相当するサイズとの合計であることを特徴とする請求項２に記載の通信装置。
7. 前記マルチユーザ通信がエラー状態か否かを判定するエラー管理手段を更に有し、
   前記データサイズが前記所定の閾値を超えない場合であっても、前記エラー管理手段により前記マルチユーザ通信がエラー状態と判定された場合は、前記決定手段は、前記ＭＵ−ＲＴＳフレームを送信することを決定することを特徴とする請求項２から６のいずれか１項に記載の通信装置。
8. 前記決定手段は、前記マルチユーザ通信において送信または受信する予定の信号の帯域使用時間が所定の閾値を超える場合に、前記ＭＵ−ＲＴＳフレームを送信することを決定することを特徴とする請求項１に記載の通信装置。
9. 前記マルチユーザ通信がアップリンクにおける通信の場合、前記帯域使用時間は、Ｔｒｉｇｇｅｒフレームと、ＵＬ ＰＰＤＵと、ＭＵ−ＡＣＫフレームとの時間と、２つのＳＩＦＳとの合計であることを特徴とする請求項８に記載の通信装置。
10. 前記マルチユーザ通信がダウンリンクにおける通信の場合、前記帯域使用時間は、ＤＬ ＰＰＤＵと、ＡＣＫフレームとの時間と、ＳＩＦＳとの合計であることを特徴とする請求項８に記載の通信装置。
11. 前記マルチユーザ通信がエラー状態か否かを判定するエラー管理手段を更に有し、
    前記帯域使用時間が前記所定の閾値を超えない場合であっても、前記エラー管理手段により前記マルチユーザ通信がエラー状態と判定された場合は、前記決定手段は、前記ＭＵ−ＲＴＳフレームを送信することを決定することを特徴とする請求項８から１０のいずれか１項に記載の通信装置。
12. 前記マルチユーザ通信がアップリンクにおける通信の場合、前記決定手段は、Ｔｒｉｇｇｅｒフレームの種別に基づいて、前記ＭＵ−ＲＴＳフレームを送信か否かを決定することを特徴とする請求項１に記載の通信装置。
13. 前記決定手段は、Ｔｒｉｇｇｅｒフレーム種別に対するＭＵ−ＲＴＳフレーム送信実行有無の対応表に基づいて、前記ＭＵ−ＲＴＳフレームを送信か否かを決定することを特徴とする請求項１２に記載の通信装置。
14. 前記マルチユーザ通信がエラー状態か否かを判定するエラー管理手段を更に有し、前記エラー管理手段により前記マルチユーザ通信がエラー状態と判定された場合は、前記決定手段は、前記Ｔｒｉｇｇｅｒフレームの種別に関係なく、前記ＭＵ−ＲＴＳフレームを送信することを決定することを特徴とする請求項１２または１３に記載の通信装置。
15. １以上の他の通信装置に対する信号を多重して通信するマルチユーザ通信が可能な通信装置の制御方法であって、
    前記マルチユーザ通信により送信または受信する予定の信号に基づいてＭＵ−ＲＴＳ（Ｍｕｌｔｉ Ｕｓｅｒ Ｒｅｑｕｅｓｔ Ｔｏ Ｓｅｎｄ）フレームを送信するかを決定する決定工程と、
    前記決定工程において前記ＭＵ−ＲＴＳフレームを送信すると決定された場合に、前記マルチユーザ通信の前に前記ＭＵ−ＲＴＳフレームを送信する送信工程と、
    を有することを特徴とする通信装置の制御方法。
16. コンピュータを、請求項１から１４のいずれか１項に記載の通信装置として機能させるためのプログラム。

Images