JP2021150777A - 通信装置、通信装置の制御方法、およびプログラム - Google Patents

Abstract

【課題】通信装置が利用可能な再送方式を判断するための技術を提供する。【解決手段】通信装置は、ＩＥＥＥ８０２．１１シリーズの規格に準拠し、ＨＡＲＱ（ハイブリッド自動再送要求）を用いて他の通信装置とデータ通信を行う。該通信装置は、該通信装置のＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態 に基づいて、該他の通信装置とのデータ通信において該通信装置が利用可能な前記ＨＡＲＱの再送タイプを判断する。【選択図】図４

Description

本発明は、無線通信技術に関する。

近年、情報通信技術の発展とともにインターネット使用量が年々増加しており、需要の増加に応えるべく様々な通信技術の開発が進められている。中でも無線ローカルエリアネットワーク（ＷＬＡＮ）技術は、携帯端末によるパケットデータ、音声、ビデオなどのインターネット通信におけるスループット向上を実現しており、現在も様々な技術開発が盛んに行われている。

ＷＬＡＮ技術の発展において、無線通信技術の標準化機構であるＩＥＥＥ(Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ)８０２による数多くの標準化作業が、重要な役割を果たしている。標準ＷＬＡＮ通信規格の一つとして、ＩＥＥＥ８０２．１１シリーズの規格が知られており、ＩＥＥＥ８０２．１１ｎ／ａ／ｂ／ｇ／ａｃまたはＩＥＥＥ８０２．１１ａｘなどの規格がある。特許文献１によれば、ＩＥＥＥ８０２．１１ａｘではＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）により最大９．６ギガビット毎秒（Ｇｂｐｓ）という高いピークスループットに加え、混雑状況下での通信速度向上を実現している。

さらなるスループット向上のために、ＩＥＥＥ８０２．１１ａｘの後継規格として、ＩＥＥＥ８０２．１１ ＥＨＴ（ｅｘｔｒｅｍｅｌｙ ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ）と呼ばれるＳｔｕｄｙ Ｇｒｏｕｐが発足した。ＥＨＴが目指すスループット向上を実現するうえで、アクセスポイント（ＡＰ）とステーション（ＳＴＡ）の間でＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ（ハイブリッド自動再送要求））ｗｉｔｈ ｓｏｆｔ ｃｏｍｂｉｎｉｎｇ技術を適用することが検討されている。

ＨＡＲＱは、ＡＲＱ（自動再送要求）と誤り訂正符号（ＦＥＣ（前方誤り訂正））の技術を組み合わせた技術である。送信装置から送信された、冗長な誤り訂正符号が付加されたパケットを受信した受信装置は、当該パケットを正しく復号した場合、ＡＣＫ（肯定応答／確認応答）パケットを送信装置に送信する。正しく復号できなかった場合はＮＡＣＫ（否定応答）を送信し、送信装置からの再送を待つ。送信装置は、受信装置にデータパケットを再送する場合、前回と同じデータを再度送信する。

ＨＡＲＱのタイプとしては主に、Ｃｈａｓｅ Ｃｏｍｂｉｎｉｎｇ（チェース合成）（以下、ＣＣ）、Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ（インクリメンタルリダンタンシ）（以下、ＩＲ）がある。これらは再送時での挙動が異なる。ＣＣでは、送信装置は、ＮＡＣＫの対象となるパケットと同一のパケットを再送する。受信装置は再送されたパケットを受信後、受信バッファに蓄積されているパケットと最大比合成（ＭＲＣ：Ｍａｘｉｍａｌ Ｒａｔｉｏ Ｃｏｍｂｉｎｉｎｇ）を行い、復号処理を行う。このＣＣタイプでは、電力干渉やＳＩＮＲ（信号対雑音干渉比）が向上する。一方で、チャネル状態が良好な場合に、符号語の冗長ビットをいつもすべて再送してしまう欠点がある。一方、ＩＲでは、送信装置は再送時、その再送回数に応じて異なる符号化を行い、送信する。このＩＲでは、パケットを合成することにより符号化利得が向上し、ＣＣよりも大きなパケット誤り低減効果を実現できる。一方で処理が複雑となり、送信装置と受信装置において、必要なメモリ数（バッファ容量）が大きくなりがちとなる。

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

上記のように、ＥＨＴでは、ＨＡＲＱ ｗｉｔｈ ｓｏｆｔ ｃｏｍｂｉｎｉｎｇ技術を適用することが検討されているが、通信装置がいずれのタイプを利用可能とするかを判断するための仕組みは定義されていなかった。

上記課題を鑑み、本発明は、通信装置が利用可能な再送方式を判断するための技術を提供することを目的とする。

上記目的を達成するため、本発明の一態様に係る通信装置は、以下の構成を有する。すなわち、ＩＥＥＥ８０２．１１シリーズの規格に準拠し、ＨＡＲＱ（ハイブリッド自動再送要求）を用いて他の通信装置とデータ通信を行う通信手段と、前記通信装置のＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態 に基づいて、前記通信手段による前記他の通信装置とのデータ通信において前記通信装置が利用可能な前記ＨＡＲＱの再送タイプを判断する判断手段と、を有する。

本発明によれば、通信装置が利用可能な再送方式を判断するための技術が提供される。

ネットワーク構成例を示す。 ＡＰおよびＳＴＡのハードウェア構成例を示す。 ＡＰおよびＳＴＡの機能構成例を示す。 ＳＴＡがデータ送受信を行うまでのフローチャートである。 ＨＡＲＱの能力情報の例を示す。 ＨＡＲＱ ｔｙｐｅが示す値と当該値の意味の対応付けの例を示す。 ＡＰがデータ送受信を行うまでのフローチャートである。 ＡＰがデータ送受信を行うまでの別のフローチャートである。 トリガーフレームの構成例を示す。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［実施形態１］
図１に、実施形態１におけるネットワークの構成例を示す。図１では、無線通信装置として、１つのアクセスポイント（ＡＰ１０２）と３つのステーション（ＳＴＡ１０３、ＳＴＡ１０４、ＳＴＡ１０５）を含んだネットワーク構成が示されている。図１に示すように、ＡＰ１０２が形成するネットワークは円１０１で示される。本実施形態では、ＳＴＡ１０３〜１０５はＡＰ１０２とフレームを送受信できるものとする。ＳＴＡ１０３〜１０５およびＡＰ１０２は、ＨＡＲＱ（ハイブリッド自動再送要求）のＩＲタイプ（ＨＡＲＱ−ＩＲ）とＣＣタイプ（ＨＡＲＱ−ＣＣ）両方にて通信が可能な無線通信装置であるものとする。なお、図１に示す構成は一例であり、例えばさらに広範な領域に多数の無線通信装置を含むネットワークに対して、また、様々な無線通信装置の位置関係に対して、以下の議論を適用可能である。

図２に、本実施形態におけるＡＰおよびＳＴＡのハードウェア構成例を示す。ＡＰとＳＴＡはそれぞれ、そのハードウェア構成の一例として、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、通信部２０６およびアンテナ２０７を有する。

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

制御部２０２は、例えば、ＣＰＵやＭＰＵ等のプロセッサー、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）等の１つ以上により構成される。ここで、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの頭字語である。制御部２０２は、記憶部２０１に記憶されたプログラムを実行することによりＡＰ（ＳＴＡ）全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働によりＡＰ（ＳＴＡ）全体を制御するようにしてもよい。また、制御部２０２には、ＨＡＲＱの誤り訂正符号を生成、復号するための回路が含まれていても良い。また、制御部２０２は、機能部２０３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部２０３は、ＡＰ（ＳＴＡ）が所定の処理を実行するためのハードウェアである。例えば、ＡＰ（ＳＴＡ）がカメラである場合、機能部２０３は撮像部であり、撮像処理を行う。また、例えば、ＡＰ（ＳＴＡ）がプリンタである場合、機能部２０３は印刷部であり、印刷処理を行う。また、例えば、ＡＰ（ＳＴＡ）がプロジェクタである場合、機能部２０３は投影部であり、投影処理を行う。機能部２０３が処理するデータは、記憶部２０１に記憶されているデータであってもよいし、後述する通信部２０６を介して他の通信装置と通信したデータであってもよい。

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

通信部２０６は、ＩＥＥＥ８０２．１１シリーズの規格に準拠した無線通信の制御や、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信の制御を行う。本実施形態では、通信部２０６は、少なくともＩＥＥＥ８０２．１１ａｘ規格に準拠した処理を実行することができる。また、通信部２０６はアンテナ２０７を制御して、無線通信のための無線信号の送受信を行う。ＡＰ（ＳＴＡ）は通信部２０６を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置と通信する。

アンテナ２０７はそれぞれサブＧＨｚ帯、２．４ＧＨｚ帯、５ＧＨｚ帯、及び６ＧＨｚ帯における無線信号のいずれかを受信可能なアンテナである。アンテナ２０７はＭＩＭＯ（Ｍｕｌｔｉ−Ｉｎｐｕｔ ａｎｄ Ｍｕｌｔｉ−Ｏｕｔｐｕｔ）送受信を実現するために、物理的に一本以上のアンテナで構成されても良い。

図３は、本実施形態におけるＡＰおよびＳＴＡの機能構成例を示す。ＡＰとＳＴＡはそれぞれ、その機能構成の一例として、能力情報生成部３０１、ＭＡＣフレーム生成部３０２、ＭＡＣフレーム送受信部３０３、解析部３０４、ＩＲ可否判定部３０５、再送タイプ決定部３０６、およびデータ送受信部３０７を有する。

能力情報生成部３０１は、ＡＰ（ＳＴＡ）における能力（Ｃａｐａｂｉｌｉｔｙ）に関する情報（能力情報（Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ））を生成する。本実施形態では、能力情報生成部３０１は、ＨＡＲＱのサポートの有無（ＨＡＲＱによるデータ通信は可能か否か）、ＨＡＲＱをサポートするにはサポートするＨＡＲＱのタイプといった情報を含む、ＨＡＲＱの能力情報（ＨＡＲＱ ｅｌｅｍｅｎｔ）を生成する。

ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）フレーム生成部３０３は、必要に応じて能力情報生成部３０１により生成された能力情報を格納したＭＡＣフレームを生成する。当該ＭＡＣフレームは、ＩＥＥＥ８０２．１１シリーズの規格に準拠するＭＡＣフレームであり、例えば、Ｂｅａｃｏｎフレーム、Ｐｒｏｂｅ Ｒｅｑｕｅｓｔフレーム、Ｐｒｏｂｅ Ｒｅｓｐｏｎｓｅフレーム、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム、Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレーム、Ｒｅａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレーム、Ａｃｔｉｏｎフレームといったマネージメントフレーム、またトリガー（Ｔｒｉｇｇｅｒ）フレームといったコントロールフレームである。

図５に、ＨＡＲＱの能力情報（ＨＡＲＱ ｅｌｅｍｅｎｔ）フォーマットの例を示す。図５のＨＡＲＱ ｅｌｅｍｅｎｔ５００は、自身がどの形式での通信を希望しているかを示すためのｅｌｅｍｅｎｔである。ＨＡＲＱ ｅｌｅｍｅｎｔ５００は、ＩＥＥＥ８０２．１１シリーズの規格で規定される他のＩｎｆｏｍａｔｉｏｎ Ｅｌｅｍｅｎｔ（情報要素）と同様、Ｅｌｅｍｅｎｔを識別するＥｌｅｍｅｎｔ ＩＤフィールド５０１と、Ｅｌｅｍｅｎｔのデータ長を示すＬｅｎｇｔｈフィールド５０２と、Ｅｌｅｍｅｎｔ固有の情報から構成される。ＨＡＲＱ ｅｌｅｍｅｎｔ５００は、前述のＭＡＣフレームに付加することのできる情報である。

ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３は、ＨＡＲＱをサポートするか否か（ＨＡＲＱを用いたデータ通信は可能か否か）を示す情報であり、例えば、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３は、０の場合はＨＡＲＱのサポート有りで、１の場合はＨＡＲＱのサポート無しであることを示す。なお、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３を使用せずに、ＭＡＣフレーム内にＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれるか否かに基づいて、フレームの受信側装置は、ＨＡＲＱのサポートの有無を判断してもよい。ＨＡＲＱ ｔｙｐｅフィールド５０４は、ＨＡＲＱのサポートが有る場合に、サポートするＨＡＲＱのタイプを示す情報である。ＨＡＲＱ ｔｙｐｅフィールド５０４の値は、例えば図６に示すような値が対応付けられる。図６に、ＨＡＲＱ ｔｙｐｅが示す値と当該値の意味の対応付けの例を示す。図６の対応付けは一例であり、他の手法による対応付けであってもよい。例えば、所定のタイプと当該所定のタイプに対応するビットを規定し、ＡＰ１０２がＢｅａｃｏｎフレームにて当該所定のタイプをサポートしていることを示す場合には、そのタイプに応じたビットの値を１としてもよい。この場合、ＳＴＡ１０３〜１０５はＡＰ１０２がサポートするタイプに応じて、ＨＡＲＱのタイプを決定することが可能になる。もしくは、値が０の場合はＨＡＲＱ−ＣＣのみ、値が１の場合はＨＡＲＱ−ＣＣおよびＨＡＲＱ−ＩＲにサポートするものとして設定されてもよい。この場合、値が高いほど、ＡＰ１０２がより高度なタイプに対応しているものと考えることができ、サポートするＨＡＲＱのタイプの種類やその組み合わせに対して、表示するビットサイズを少なく保つことが可能となる。また、複数のＨＡＲＱのタイプをサポートする場合には、ＨＡＲＱ ｅｌｅｍｅｎｔを複数付与することによって、サポートの表現をしてもよい。

図３の説明に戻り、ＭＡＣフレーム送受信部３０３は、通信部２０６を介して、ＭＡＣフレーム生成部３０２により生成されたＭＡＣフレームを送信し、相手機器からのＭＡＣフレームを受信する。解析部３０４は、ＭＡＣフレーム送受信部３０３により受信されたＭＡＣフレームを解析し、所定の情報を抽出する。例えば解析部３０４は、受信されたＭＡＣフレームを解析し、相手機器（ＭＡＣフレームの送信元の機器）のＨＡＲＱのサポートの有無等を抽出する。解析部３０４は、当該解析の結果に基づいて、相手機器がＨＡＲＱを用いたデータ通信を行うことができるか否か（相手機器との間でＨＡＲＱを用いたデータ通信を行うか否か）を判定する。ＩＲ可否判定部３０５は、相手機器との間の接続帯域幅や自機器のバッファ空き容量等を確認することにより、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができるか否かを判定する。再送タイプ決定部３０６は、相手機器との再送通信方式（以下、再送タイプ）、すなわち、ＨＡＲＱ−ＩＲ、ＨＡＲＱ−ＣＣ、またはＡＲＱ（自動再送要求）のいずれかを決定する。当該決定は、解析部３０４による解析の結果、ＩＲ可否判定部３０５による判定の結果、ＭＡＣフレーム送受信部３０３により受信されるＭＡＣフレームの種別、のうちの少なくとも１つに基づいて、行われ得る。ＡＲＱは、ＩＥＥＥ８０２．１１ａｘ等、従来のＩＥＥＥ８０２．１１シリーズの規格でサポートされている再送タイプである。データ送受信部３０７は、再送タイプ決定部３０６により決定された再送タイプを用いて、データフレームの送受信を行う。

（処理の流れ）
本実施形態では、ＳＴＡが、ＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態に基づいて、相手機器（ＡＰ）とのデータ通信において利用可能な再送タイプ（ＨＡＲＱ−ＩＲ、ＨＡＲＱ−ＣＣ、ＡＲＱ）を判断する。その上で、ＳＴＡは、ＡＰとのデータ通信に使用する再送タイプを決定する。当該規格に準拠した通信に関する状態の一例は、ＳＴＡにおけるＨＡＲＱについての能力（性能）である。上述したように、ＨＡＲＱ−ＩＲでは、パケットを合成することにより符号化利得が向上し、ＨＡＲＱ−ＣＣよりも大きなパケット誤り低減効果を実現できる一方で、処理が複雑となり、必要なバッファ容量が大きくなり得る。本実施形態では、ＳＴＡ１０３とＳＴＡ１０４は、ＨＡＲＱ−ＩＲを用いたデータ通信に必要なバッファ領域（バッファ空き容量）を確保できているが、ＳＴＡ１０５はそのようなバッファ領域を確保できていないものとする。

図４に、ＳＴＡ１０３〜１０５により実行される、データ送受信を行うまでの処理のフローチャートを示す。ＳＴＡ１０３〜１０５を総称する場合は、ＳＴＡと表現する。図４に示すフローチャートは、ＳＴＡの制御部２０２が記憶部２０１に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、ＳＴＡがＡＰ１０２と接続を開始（要求）するときに開始され得る。なお、ＳＴＡがＡＰ１０２との接続中に、例えばＡｃｔｉｏｎフレームを受信したことをトリガーとして開始されてもよい。

まず、ＳＴＡの解析部３０４は、ＡＰ１０２とＨＡＲＱを用いたデータ通信を行うか否かを判断する（Ｓ４０１）。解析部３０４は、例えば、ＭＡＣフレーム送受信部３０３により受信された、ＡＰ１０２が定期的に送信するＢｅａｃｏｎフレームや、送信されたＰｒｏｂｅ Ｒｅｑｕｅｓｔフレームに対する返信であるＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを解析する。具体的には、解析部３０４は、受信した前述のフレームに、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５を参照）が含まれているか否か（ＡＰ１０２がＨＡＲＱをサポートしているか否か）により、ＡＰ１０２とＨＡＲＱを用いたデータ通信を行うか否かを判断してもよい。また、解析部３０４は、受信した前述のフレームにＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれる場合に、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値が１であるか否か（ＡＰ１０２がＨＡＲＱをサポートしているか否か）により、ＡＰ１０２とＨＡＲＱを用いたデータ通信を行うか否かを判断してもよい。解析部３０４は、ＡＰ１０２がＨＡＲＱをサポートしていると判断した場合に、ＨＡＲＱを用いたデータ通信を行うと判断し、そうでない場合に、ＨＡＲＱを用いたデータ通信を行わないと判断する。

解析部３０４により、ＨＡＲＱを用いたデータ通信を行わないと判断された場合（Ｓ４０１でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱを用いたデータ通信を行わず、ＡＲＱを用いたデータ通信を行うことを決定する（Ｓ４０２）。一方、解析部３０４は、ＡＰ１０２がＨＡＲＱを用いたデータ通信を行うと判断した場合（Ｓ４０１でＹｅｓ）、ＡＰ１０２がＨＡＲＱ−ＩＲを用いたデータ通信を行うことができるか否か、すなわち、ＨＡＲＱ−ＩＲをサポートするか否かを判断する（Ｓ４０３）。具体的には、解析部３０４は、ＨＡＲＱ ｅｌｅｍｅｎｔ５００内のＨＡＲＱ ｔｙｐｅフィールド５０４の値（図６を参照）を確認する。解析部３０４により、ＡＰ１０２がＨＡＲＱ−ＣＣのみサポートしていると判断された場合（Ｓ４０３でＮｏ）、ＭＡＣフレーム送受信部３０３は希望再送タイプがＨＡＲＱ−ＣＣであることをＡＰ１０２に通知する（Ｓ４０８）。具体的な処理例としては、まずＭＡＣフレーム生成部３０２は、例えば、ＡＰ１０２との接続時に希望する再送タイプとして、ＨＡＲＱ−ＣＣを指定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成する。当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームは、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５）を有し、希望する再送タイプはＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３により指定され得る。そして、ＭＡＣフレーム送受信部３０３は当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信する。

一方、解析部３０４により、ＡＰ１０２がＨＡＲＱ−ＩＲのみ、または、ＨＡＲＱ−ＣＣとＨＡＲＱ−ＩＲをサポートしていると判断された場合（Ｓ４０３でＹｅｓ）、処理はＳ４０４へ進む。Ｓ４０４では、ＩＲ可否判定部３０５は、ＨＡＲＱ−ＩＲを用いた通信に使用可能なバッファ領域（バッファ空き容量）を確認する。具体的な処理例としては、ＩＲ可否判定部３０５は、ＳＴＡ自身が確保できるバッファ空き容量、もしくはメモリ空き容量を確認する。メモリ空き容量を確認するタイミングは、より最適なメモリ使用を行うために、ＡＰ１０２との接続の直前に行うことが望ましいが、これに限らない。例えば、ＩＲ可否判定部３０５は、ＳＴＡの電源起動時にバッファ空き容量を確認し、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断した場合、接続直前での確認を実施しなくてもよい。また、ＩＲ可否判定部３０５は、ＡＰ１０２との接続中に、より優先するべきアプリケーションが起動されている場合に、当該アプリケーション起動後に確保できるバッファ空き容量を確認してもよい。これにより、優先したアプリケーションへのメモリ確保が可能となる。ＩＲ可否判定部３０５は、ほかのアプリケーションの動作とは関係なく、定期的にＳＴＡ内部で確保できるバッファ容量を確認してもよい。ＨＡＲＱ−ＣＣおよびＨＡＲＱ−ＩＲを用いたデータ通信のために必要なバッファ空き容量を定め、その閾値を超える、あるいは下回る変化があった時に、ＳＴＡは、図４のフローチャートのＳ４０４の処理から開始してもよい。バッファ空き容量とは、製品に組み込まれるメモリサイズに加え、製品の接合部で増設されるメモリ容量も含めてよい。

ＨＡＲＱ−ＩＲを用いたデータ通信に必要なバッファ空き容量は、ＡＰ１０２とＳＴＡ１０３〜１０５が接続する周波数帯域（接続帯域）の幅によって変化しうる。例えば、８０ＭＨｚで接続した場合と３２０ＭＨｚで接続した場合で必要なバッファ空き容量には、約４倍の差が生じる。また、通信中、メモリ上にデータを滞留させる時間（滞留時間）によっても必要なバッファ空き容量は異なる。規格に従って滞留時間を可変とした場合、滞留時間を１ｍｓとするか、５ｍｓとするかで５倍の差が生じうる。これらの情報は接続処理を行う際に、ＳＴＡは、ＡＰ１０２から送信されるＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームによって知ることができる。ＩＲ可否判定部３０５は、データ通信するときの接続帯域の幅や滞留時間によって、ＨＡＲＱ−ＣＣやＨＡＲＱ−ＩＲを用いたデータ通信に必要なバッファ空き容量の閾値を変更（設定）する。この上で、ＩＲ可否判定部３０５は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことが可能か否か（ＨＡＲＱ−ＩＲを利用可能か否か）を判断する（Ｓ４０５）。

バッファ空き容量が閾値に満たないなど、ＩＲ可否判定部３０５がＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断した場合（Ｓ４０５でＮｏ）、ＭＡＣフレーム送受信部３０３は希望再送タイプがＨＡＲＱ−ＣＣであることをＡＰ１０２に通知する（Ｓ４０８）。Ｓ４０８の具体的な処理例は上述の通りである。バッファ空き容量が閾値以上であるなど、ＩＲ可否判定部３０５がＨＡＲＱ−ＩＲを用いたデータ通信を行うことができると判断した場合（Ｓ４０５でＹｅｓ）、ＭＡＣフレーム送受信部３０３は希望再送タイプがＨＡＲＱ−ＩＲであることをＡＰ１０２に通知する（Ｓ４０６）。具体的な処理例としては、まずＭＡＣフレーム生成部３０２は、例えば、ＡＰ１０２との接続時に希望する再送タイプとして、ＨＡＲＱ−ＩＲを指定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを生成する。当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームは、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５）を有し、希望する再送タイプはＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３により指定され得る。そして、ＭＡＣフレーム送受信部３０３は当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信する。

ＭＡＣフレーム送受信部３０３は、希望再送タイプがＨＡＲＱ−ＩＲであることをＡＰ１０２に通知した（Ｓ４０６）後、当該通知に対する応答を待つ。応答が受信された場合に、解析部３０４は、当該応答が拒否応答か否かを判断する（Ｓ４０７）。具体的な処理例としては、Ｓ４０６にて、ＡＰ１０２との接続時に希望する再送タイプとして、ＨＡＲＱ−ＩＲを指定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信した場合、ＭＡＣフレーム送受信部３０３はＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームの受信を待つ。ＭＡＣフレーム送受信部３０３によりＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームが受信された場合、解析部３０４は、当該フレームを解析し、ＨＡＲＱ−ＩＲを用いたデータ通信を拒否することを示す情報が含まれているか否かを判断する。ＨＡＲＱ−ＩＲを用いたデータ通信を拒否することを示す情報が含まれている場合に、解析部３０４は、応答が拒否応答であると判断し、それ以外の場合に、応答が拒否応答でないと判断する。拒否応答を受信（取得）していないと判断された場合（Ｓ４０７でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことを決定する（Ｓ４１０）。

解析部３０４により、拒否応答を受信（取得）したと判断された場合（Ｓ４０７でＹｅｓ）、ＭＡＣフレーム送受信部３０３は希望再送タイプがＨＡＲＱ−ＣＣであることをＡＰ１０２に通知してもよい（Ｓ４０８）。ＭＡＣフレーム送受信部３０３は、希望再送タイプがＨＡＲＱ−ＣＣであることをＡＰ１０２に通知した（Ｓ４０８）後、当該通知に対する応答を待つ。応答が受信された場合に、解析部３０４は、当該応答が拒否応答か否かを判断する（Ｓ４０９）。具体的な処理例としては、Ｓ４０８にて、ＡＰ１０２との接続時に希望する再送タイプとして、ＨＡＲＱ−ＣＣを指定したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを送信した場合、ＭＡＣフレーム送受信部３０３はＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームの受信を待つ。ＭＡＣフレーム送受信部３０３によりＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームが受信された場合、解析部３０４は、当該フレームを解析し、ＨＡＲＱ−ＣＣを用いたデータ通信を拒否することを示す情報が含まれているか否かを判断する。ＨＡＲＱ−ＣＣを用いたデータ通信を拒否することを示す情報が含まれている場合に、解析部３０４は、応答が拒否応答であると判断し、それ以外の場合に、応答が拒否応答でないと判断する。拒否応答を受信（取得）していないと判断された場合（Ｓ４０９でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことを決定する（Ｓ４１１）。

解析部３０４により、拒否応答を受信（取得）したと判断された場合（Ｓ４０９でＹｅｓ）、再送タイプ決定部３０６は、ＡＲＱを用いたデータ通信を行うことを決定する（Ｓ４０２）。なお、他の再送タイプを用いたデータ通信が可能である場合は、ＭＡＣフレーム送受信部３０３は、希望再送タイプが当該他の再送タイプであることをＡＰ１０２に通知してもよい。また、ＳＴＡはタイマー（不図示）を設置し、ＭＡＣフレーム送受信部３０３は、一定時間に応答（例えばＡｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）を受信しなかったことをもって、ＡＰ１０２により希望再送タイプが拒否されたと認識してもよい。この場合、ＭＡＣフレーム送受信部３０３は、希望再送タイプがＡＲＱや別のＨＡＲＱのタイプであることをＡＰ１０２に通知してもよい。

その後、データ送受信部３０７は、再送タイプ決定部３０６により決定された再送タイプを用いて、データの送受信を行う（Ｓ４１２）。

なお、ＳＴＡは、図４に示す処理をＡＰ１０２との接続後に行う場合、例えばＡｃｔｉｏｎフレームを用いて希望再送タイプを通知してもよい（再送タイプ（接続タイプ）変更通知）。もしくは、データを一斉に送信する合図となるＵＬ（アップリンク）やＤＬ（ダウンリンク）のＴｒｉｇｇｅｒフレームをはじめとしたコントロールフレームを用いてもよい。

また、ＩＲ可否判定部３０５による、ＨＡＲＱ−ＩＲを用いた通信を行うためのバッファ空き容量や、接続帯域（接続するときの周波数帯域）の確認は、Ｓ４０１の前に行われてもよい。またＳＴＡは、この確認結果を、ＨＡＲＱを用いたデータ通信を行うかどうかの指標として用いてもよい。また、図４の処理では、ＩＲ可否判定部３０５が、接続帯域の幅および受信データの滞留時間をもとにＨＡＲＱ−ＩＲに必要なバッファ空き容量の閾値を設定し、その後、再送タイプ決定部３０６が当該閾値に基づいてＨＡＲＱのタイプを決定した。閾値の設定とＨＡＲＱのタイプの決定との処理順序は逆であってもよい。すなわち、再送タイプ決定部３０６が希望するＨＡＲＱタイプをＨＡＲＱ−ＩＲと定め、その後、ＩＲ可否判定部３０５がＨＡＲＱ−ＩＲに必要なバッファ空き容量を計算し、現在のバッファ空き容量で通信できる周波数帯域幅から、ＳＴＡが希望する周波数帯域幅を求めてもよい。これにより、相手機器が特定のＨＡＲＱのタイプにのみ対応していたとしても、示されたタイプでのデータ通信が可能となる。

図４の例では、ＨＡＲＱのタイプを決定するために接続帯域の幅およびデータの滞留時間を用いたが、これは一例に過ぎず、メモリの使用に関する他の処理をＳ４０５に適用してもよい。例えば、Ｇｒｅｅｎ ｆｉｅｌｄの使用の有無、Ａ−ＭＳＤＵ（Ａｇｇｒｅｇａｔｉｏｎ ＭＡＣ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）の使用の有無、Ａ−ＭＳＤＵやＡ−ＭＰＤＵ（Ａｇｇｒｅｇａｔｉｏｎ ＭＡＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）の受信時の最大サイズ、ＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）を含めた最大のデータレート、ビームフォーミング処理の有無、認証方式（ＰＳＫ、ＳＡＥ、ＥＡＰ）や暗号化方式（ＴＫＩＰ、ＡＥＳ）を含めたセキュリティ方式、ＦＴＭ（Ｆｉｎｅ Ｔｉｍｉｎｇ Ｍｅａｓｕｒｅｍｅｎｔ）処理の有無、Ｗｉ−Ｆｉ ＤｉｒｅｃｔやＷｉ−Ｆｉ Ａｗａｒｅ処理の有無、ＬＤＰＣ（低密度パリティ検査符号）やＢｌｏｃｋ ＡＣＫの処理の有無、ＣＳＩ（チャネル状態情報）情報の送受信の有無、Ｂｅａｃｏｎ ＲｅｐｏｒｔなどのＳＴＡ周辺の情報を送信するかどうか、などを元に、ＨＡＲＱのタイプを決定してもよい、もしくはＨＡＲＱのタイプによって、上記の閾値を変更するものであってもよい。

このように、本実施形態によれば、ＳＴＡは、自身のバッファ空き容量を確認し、ＡＰ１０２のサポートする機能（能力）の情報を取得することによって、データ通信に使用するＨＡＲＱのタイプを決定することができる。また、ＡＰ１０２は、ＳＴＡごとに、ＨＡＲＱ−ＣＣ、ＨＡＲＱ−ＩＲ、またはＡＲＱを用いたデータ通信を行うことを決めることができ、ＳＴＡに適した通信方式を採用することができるようになる。

［実施形態２］
本実施形態では、ＡＰが、ＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態に基づいて、相手機器（ＳＴＡ）とのデータ通信において利用可能な再送タイプ（ＨＡＲＱ−ＩＲ、ＨＡＲＱ−ＣＣ、ＡＲＱ）を判断する。その上で、ＡＰは、ＳＴＡとのデータ通信に使用する再送タイプを決定する。当該規格に準拠した通信に関する状態の一例は、ＡＰにおけるＨＡＲＱについての能力（性能）である。以下、実施形態１と異なる点について説明する。本実施形態では、ＳＴＡ１０３、ＳＴＡ１０４は、ＨＡＲＱ−ＩＲを用いたデータ通信に必要なバッファ領域（バッファ空き容量）を確保できているが、ＳＴＡ１０５はそのようなバッファ領域をできていないものとする。

図７に、ＡＰ１０２により実行される、データ送受信を行うまでの処理のフローチャートを示す。図７に示すフローチャートは、ＡＰ１０２の制御部２０２が記憶部２０１に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、ＳＴＡ１０３〜ＳＴＡ１０５がＡＰ１０２に接続を要求してきたときに開始され得る。

まず、ＩＲ可否判定部３０５は、ＡＰとしての動作開始時に希望する最大の周波数帯域（接続帯域）の幅、および、ＨＡＲＱ−ＩＲを用いた通信に使用可能なバッファ領域（バッファ空き容量）を確認する（Ｓ７０１）。ＩＲ可否判定部３０５は、確認した容量の値から、希望する最大の接続帯域幅にてＨＡＲＱ−ＩＲを用いたデータ通信を行うことができるか否か（ＨＡＲＱ−ＩＲを利用可能か否か）を判断する（Ｓ７０２）。なお、ＩＲ可否判定部３０５は、追加的または代替的に、ＡＰ１０２が現在接続しているＳＴＡの数に基づいて、当該判断を行ってもよい。また、ＩＲ可否判定部３０５は、追加的または代替的に、トリガーフレームを用いた複数ＳＴＡへの同時ＤＬ通信（ダウンリンク通信）またはＵＬ通信（アップリンク通信）を行うかどうかに基づいて、当該判断を行ってもよい。また、ＩＲ可否判定部３０５は、ＡＰ１０２に現在搭載されているチップが持つ機能、通信する周波数帯域で送受信される周囲のフレーム数などの環境によって、当該判断を行ってもよい。

ＩＲ可否判定部３０５が、ＨＡＲＱ−ＩＲのために必要な空きバッファ容量を確保できない等、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断した場合（Ｓ７０２でＮｏ）、ＭＡＣフレーム送受信部３０３は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことができることをＳＴＡに通知する（Ｓ７０４）。Ｓ７０４の具体的な処理例としては、まずＭＡＣフレーム生成部３０２は、ＨＡＲＱのタイプとしてＨＡＲＱ−ＣＣを指定したＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを生成する。当該ＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームは、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５）を有し、可能な再送タイプはＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３により指定され得る。そして、ＭＡＣフレーム送受信部３０３は当該ＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを送信する。一方、ＩＲ可否判定部３０５が、ＨＡＲＱ−ＩＲのために必要な空きバッファ容量を確保できる等、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができると判断した場合（Ｓ７０２でＹｅｓ）、ＭＡＣフレーム送受信部３０３は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができることをＳＴＡに通知する（Ｓ７０３）。Ｓ７０３の具体的な処理例としては、まずＭＡＣフレーム生成部３０２は、ＨＡＲＱのタイプとしてＨＡＲＱ−ＩＲを指定したＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを生成する。当該ＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームは、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５）を有し、可能な再送タイプはＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３により指定され得る。そして、ＭＡＣフレーム送受信部３０３は当該ＢｅａｃｏｎフレームやＰｒｏｂｅ Ｒｅｓｐｏｎｓｅフレームを送信する。なお、ＩＲ可否判定部３０５がＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断した場合、ＭＡＣフレーム生成部３０２は、送信するフレームにおいてＨＡＲＱ ｅｌｅｍｅｎｔ５００を付与しなくてもよいし、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値を０にしてもよい。

ＳＴＡはＡＰ１０２に対して接続を要求する場合、ＡｕｔｈｅｎｔｉｃａｔｉｏｎフレームをＡＰ１０２に対して送信する。ＭＡＣフレーム送受信部３０３が当該該Ａｕｔｈｅｎｔｉｃａｔｉｏｎフレームを受信しない場合は（Ｓ７０５でＮｏ）、処理はＳ７０１へ戻る。ＭＡＣフレーム送受信部３０３は、当該Ａｕｔｈｅｎｔｉｃａｔｉｏｎフレームを受信した場合（Ｓ７０５でＹｅｓ）、Ａｕｔｈｅｎｔｉｃａｔｉｏｎフレームを返信する（Ｓ７０６）。なお、Ｓ７０５とＳ７０６の処理（すなわちＡｕｔｈｅｎｔｉｃａｔｉｏｎプロセス）についてはこれに限らない。処理形態によっては、Ｓ７０５とＳ７０６の処理は省略され得る。また、ＳＡＥ（Ｓｉｍｕｌｔａｎｅｏｕｓ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｏｆ Ｅｑｕａｌｓ）で接続するときは、Ｓ７０５とＳ７０６におけるフレーム送受信の代わりに、ＳＡＥ ｃｏｍｍｉｔの送受信、ＳＡＥ ｃｏｎｆｉｒｍの送受信を行ってもよい。

次に、ＭＡＣフレーム送受信部３０３がＳＴＡからＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信した場合（Ｓ７０７でＹｅｓ）、処理はＳ７０８へ進む。Ｓ７０８において、解析部３０４は、受信したＡｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームに、ＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５を参照）が含まれているか否かを確認することにより、ＳＴＡがＨＡＲＱを用いた通信を希望しているか否かを判断する。Ｓ７０８では、解析部３０４は、当該受信したフレームにＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれる場合に、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３が１であるか否かに基づいて、ＳＴＡがＨＡＲＱを用いた通信を希望しているか否かを判断してもよい。解析部３０４により、ＳＴＡがＨＡＲＱを用いた通信を希望していないと判断された場合（Ｓ７０８でＮｏ）、再送タイプ決定部３０６は、ＡＲＱを用いたデータ通信を行うことを決定する（Ｓ７０９）。その後、ＭＡＣフレーム送受信部３０３は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信する（Ｓ７１７）。当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームには、ＨＡＲＱ ｅｌｅｍｅｎｔ５００は含まれない、または、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値が１であるＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれ得る。

解析部３０４は、ＳＴＡがＨＡＲＱを用いた通信を希望していると判断した場合（Ｓ７０８でＹｅｓ）、さらに、ＳＴＡの希望がＨＡＲＱ−ＩＲかＨＡＲＱ−ＣＣかを判断する（Ｓ７１０）。解析部３０４は例えば、ＨＡＲＱ ｅｌｅｍｅｎｔ５００におけるＨＡＲＱ ｔｙｐｅフィールド５０４の値を確認することで当該判断を行うことができる。解析部３０４によりＳＴＡがＨＡＲＱ−ＩＲを希望していると判断された場合（Ｓ７１０でＹｅｓ）、ＩＲ可否判定部３０５は、ＡＰ１０２自身がＨＡＲＱ−ＩＲを用いたデータ通信を行うことができるか否かを判断する（Ｓ７１１）。Ｓ７１１の処理では、Ｓ７０１とＳ７０２の処理において用いた判断基準を再度用いてもよいし、Ｓ７０１とＳ７０２の処理における結果をそのまま用いてもよい。また、Ｓ７０１とＳ７０２の処理においてバッファ空き容量を確認した時点と、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信した時点でのバッファ空き容量の変化量、を元にＳ７１１における判断が行われてもよい。

判断の結果、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断された場合（Ｓ７１１でＮｏ）、ＭＡＣフレーム送受信部３０３は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができない（拒否する）ことをＳＴＡに通知する（拒否通知を送信する）。このとき用いるフレームは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームでもよいし、別のフレームでもよい。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを用いる場合、ＭＡＣフレーム生成部３０２は、ＨＡＲＱ−ＩＲを用いたデータ通信を拒否することを示す情報を含め、ＭＡＣフレーム送受信部３０３が当該フレームを拒否応答（拒否通知）として送信する。また、ＭＡＣフレーム送受信部３０３は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信しないことで、ＨＡＲＱ−ＩＲを用いたデータ通信を拒否することを通知してもよい。

一方、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができると判断された場合（Ｓ７１１でＹｅｓ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことを決定する（Ｓ７１２）。その後、ＭＡＣフレーム送受信部３０３は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信する（Ｓ７１７）。当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームには、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値が０、ＨＡＲＱ ｔｙｐｅフィールド５０４の値が１であるＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれ得る。

解析部３０４によりＳＴＡがＨＡＲＱ−ＣＣを希望していると判断された場合（Ｓ７１０でＮｏ）、ＩＲ可否判定部３０５は、ＡＰ１０２自身がＨＡＲＱ−ＣＣを用いたデータ通信を行うことができるか否かを判断する（Ｓ７１４）。Ｓ７１４の処理では、Ｓ７０１とＳ７０２の処理において用いた判断基準を再度用いてもよいし、Ｓ７０１とＳ７０２の処理における結果をそのまま用いてもよい。また、Ｓ７０１とＳ７０２の処理においてバッファ空き容量を確認した時点と、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔフレームを受信した時点でのバッファ空き容量の変化量、を元にＳ７１４における判断が行われてもよい。

判断の結果、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことができないと判断された場合（Ｓ７１４でＮｏ）、ＭＡＣフレーム送受信部３０３は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことができない（拒否する）ことをＳＴＡに通知する（拒否通知を送信する）。このとき用いるフレームは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームでもよいし、別のフレームでもよい。Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを用いる場合、ＭＡＣフレーム生成部３０２は、ＨＡＲＱ−ＣＣを用いたデータ通信を拒否することを示す情報を含め、ＭＡＣフレーム送受信部３０３が当該フレームを拒否応答（拒否通知）として送信する。また、ＭＡＣフレーム送受信部３０３は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信しないことで、ＨＡＲＱ−ＣＣを用いたデータ通信を拒否することを通知してもよい。

一方、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことができると判断された場合（Ｓ７１４でＹｅｓ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことを決定する（Ｓ７１５）。その後、ＭＡＣフレーム送受信部３０３は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信する（Ｓ７１７）。当該Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームには、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値が０、ＨＡＲＱ ｔｙｐｅフィールド５０４の値が０であるＨＡＲＱ ｅｌｅｍｅｎｔ５００が含まれ得る。

なお、ＡＰ１０２は、Ｓ７１３およびＳ７１６にて拒否通知を送信した後に、ＳＴＡから再度接続が要求された場合は、Ｓ７０５から処理を開始してもよいし、Ｓ７０７から処理を開始してもよい。また、ＡＰ１０２は、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅフレームを送信した後は、４ｗａｙ ｈａｎｄｓｈａｋｅを実施してもよいし、実施しなくてもよい。

その後、データ送受信部３０７は、再送タイプ決定部３０６により決定された再送タイプを用いて、データの送受信を行う（Ｓ７１８）。

図８に、ＡＰ１０２により実行される、ＡＰがデータ送受信を行うまでの処理の別のフローチャートを示す。図８に示すフローチャートは、ＡＰ１０２の制御部２０２が記憶部２０１に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、ＡＰ１０２が接続中のＳＴＡが１以上存在し、当該ＳＴＡとデータを送受信しようとするときに開始され得る。また、ＳＴＡ１０３〜ＳＴＡ１０５がＡＰ１０２に接続を要求してきたときに開始されてもよい。

まず、ＡＰ１０２の制御部２０２は、ＡＰ１０２自身および接続中の１以上の各ＳＴＡがＨＡＲＱをサポートしているか（ＨＡＲＱに対応可能か）否かを確認する（Ｓ８０１）。すなわち、ＡＰ１０２は、接続中の各ＳＴＡに対して、ＨＡＲＱを用いたデータ通信を行うか否かを決定する。具体的な処理例としては、制御部２０２は、ＡＰ１０２自身については、ＡＰ１０２に対して適用されている設定／構成を確認する。また、各ＳＴＡについては、ＡＰ１０２は既に受信していたＭＡＣフレームにＨＡＲＱ ｅｌｅｍｅｎｔ５００（図５）が含まれるか否か、含まれる場合には、ＨＡＲＱ ｓｕｐｐｏｒｔフィールド５０３の値が１であるか否かを確認する。

ＡＰ１０２がＨＡＲＱをサポートしていないと判断された場合（Ｓ８０１でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱを用いたデータ通信を行わず、ＡＲＱを用いたデータ通信を行うことを決定する（Ｓ８０２）。接続中のＳＴＡのうちＨＡＲＱをサポートしていないＳＴＡがあると判断された場合（Ｓ８０１でＮｏ）、再送タイプ決定部３０６は、当該ＨＡＲＱのサポートが無いＳＴＡに対して、ＡＲＱを用いたデータ通信を行うことを決定する（Ｓ８０２）。なお、接続中のＳＴＡのうちＨＡＲＱをサポートしていないＳＴＡがあると判断された場合（Ｓ８０１でＮｏ）、再送タイプ決定部３０６は、当該接続中の全てのＳＴＡに対して、ＡＲＱを用いたデータ通信を行うことを決定してもよい（Ｓ８０２）。また、接続中のＳＴＡの全てがＨＡＲＱをサポートしている場合であっても、当該全てのＳＴＡに対してＨＡＲＱを用いたデータ通信ができない場合に、再送タイプ決定部３０６は、一部のＳＴＡに対して、ＡＲＱを用いたデータ通信を行うことを決定してもよい。また、Ｓ８０１に替えて、ＡＰ１０２は、ＳＴＡごとに個別でＨＡＲＱのタイプを設定しているか否か、ＡＰ１０２がＡＲＱとＨＡＲＱの切り替えができる能力を持っているか否かに基づいて、ＨＡＲＱを用いたデータ通信を行うか否かを決定してもよい。

ＡＰ１０２および接続中の各ＳＴＡがＨＡＲＱをサポートしていると判断された場合（Ｓ８０１でＹｅｓ）、ＩＲ可否判定部３０５は、ＨＡＲＱを用いたデータ通信を行うＡＰ１０２と各ＳＴＡの各組において、接続帯域（周波数帯域）の幅、および、ＨＡＲＱ−ＩＲを用いた通信に使用可能なバッファ領域（バッファ空き容量）を確認する（Ｓ８０３）。続いて、ＩＲ可否判定部３０５は、確認した容量の値から、当該接続帯域幅にてＨＡＲＱ−ＩＲを用いたデータ通信を行うことができるか否か（ＨＡＲＱ−ＩＲが利用可能か否か）を判断する（Ｓ８０４）。ＩＲ可否判定部３０５が、ＨＡＲＱ−ＩＲのために必要な空きバッファ容量を確保できない等、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができないと判断した場合（Ｓ８０４でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことを決定する（Ｓ８０７）。一方、ＩＲ可否判定部３０５は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことができると判断した場合（Ｓ８０４でＹｅｓ）、さらにＳＴＡがＨＡＲＱ−ＩＲをサポートしているか否かを判断する（Ｓ８０５）。当該判断は、ＭＡＣフレーム送受信部３０３が、トリガーフレームなどのコントロールフレームにＨＡＲＱ ｅｌｅｍｅｎｔ５００を含めて送受信することにより行われ得る。また、当該判断は、ＭＡＣフレーム送受信部３０３が既に受信していたＭＡＣフレームの内容に基づいて行われてもよい。

ＳＴＡがＨＡＲＱ−ＩＲをサポートしていないと判断された場合（Ｓ８０５でＮｏ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＣＣを用いたデータ通信を行うことを決定する（Ｓ８０７）。ＳＴＡがＨＡＲＱ−ＩＲをサポートしていると判断された場合（Ｓ８０５でＹｅｓ）、再送タイプ決定部３０６は、ＨＡＲＱ−ＩＲを用いたデータ通信を行うことを決定する（Ｓ８０６）。

Ｓ８０２、Ｓ８０６、Ｓ８０７の決定の後、処理はＳ８０８に進む。Ｓ８０８では、ＭＡＣフレーム送受信部３０３は、決定した再送タイプをＳＴＡに通知する。当該通知は、トリガーフレームを用いて行われ得る。また、当該通知は、ＡｃｔｉｏｎフレームやＢｌｏｃｋ Ａｃｋ Ｒｅｑｕｅｓｔフレームなどの他のコントロールフレームを用いて行われてもよい。決定した再送タイプの通知後、データ送受信部３０７は、再送タイプ決定部３０６により決定された再送タイプを用いて、データの送受信を行う（Ｓ８０９）。Ｓ８０８の通知においてトリガーフレームが使用され、当該トリガーフレームが同時データ通信を指示するものであった場合、ＳＴＡは、指示されたＤｕｒａｔｉｏｎ ｔｉｍｅの間においてのみ、決定された再送タイプを用いてデータ通信を行ってもよい。

図９に、Ｓ８０８の通知に用いられ得るトリガーフレームの例を示す。なお、Ｓ８０８の通知は、図９に示す構成を有する他のフレームにより行われてもよい。図９のトリガーフレーム９００において、Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９０５にすべてのＳＴＡに共通するパラメータが記述される。Ｔｒｉｇｇｅｒ Ｔｙｐｅフィールド９０９はトリガーフレームの種類を示す。ＵＬ Ｌｅｎｇｔｈフィールド９１０はデータフレームの最大の長さを示す。Ｕｓｅｒ Ｉｎｆｏフィールド９０６に各ＳＴＡにて定める情報を示す。ＡＩＤフィールド９１１は、どのＳＴＡのストリームかを対応付けるためのフィールドである。これを見ることで、ＳＴＡは自分への指示かどうかを判断することができる。ＲＵ Ａｌｌｏｃａｔｉｏｎフィールド９１２は、各ＳＴＡに割り当てた通信帯域幅やどこの帯域を割り当てたかという場所情報が含まれる。ＨＡＲＱ ｔｙｐｅフィールド９１３はＨＡＲＱを用いたデータ通信を行うか、ＨＡＲＱを用いたデータ通信を行う場合はＨＡＲＱのタイプを示す情報が含まれる。この値を見ることで、ＳＴＡは自分がどの通信方式で通信すればよいかを判断することができるようになる。また、ＨＡＲＱ ｔｙｐｅフィールド９１３を、Ｕｓｅｒ Ｉｎｆｏフィールド９０６の内部に配置することで、ＳＴＡごとでＨＡＲＱのタイプ変更が可能となる。ＨＡＲＱ ｔｙｐｅフィールド９１３は別のところに配置してもよい。例えば、Ｃｏｍｍｏｎ Ｉｎｆｏフィールド９０６の内部に配置すると、ＳＴＡに一括してＨＡＲＱ ｔｙｐｅを通知することができる。

このように、本実施形態によれば、ＡＰは、自身のＨＡＲＱについての能力に基づいて、ＳＴＡとの通信における再送タイプを決定することができる。また、データの送受信に使用するＨＡＲＱのタイプを、ＳＴＡとＡＰとの間で交換することができる。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１ ネットワーク １０２ ＡＰ（アクセスポイント）、１０３〜１０５ ＳＴＡ（ステーション）

Claims (14)

1. 通信装置であって、
   ＩＥＥＥ８０２．１１シリーズの規格に準拠し、ＨＡＲＱ（ハイブリッド自動再送要求）を用いて他の通信装置とデータ通信を行う通信手段と、
   前記通信装置のＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態に基づいて、前記通信手段による前記他の通信装置とのデータ通信において前記通信装置が利用可能な前記ＨＡＲＱの再送タイプを判断する判断手段と、
   を有することを特徴とする通信装置。
2. 前記判断手段は、前記通信に関する状態として、前記通信装置における、前記ＨＡＲＱを用いたデータ通信に使用可能なメモリのバッファ空き容量に基づいて、前記利用可能な前記ＨＡＲＱの再送タイプを判断することを特徴とする請求項１に記載の通信装置。
3. 前記判断手段は、前記バッファ空き容量が閾値以上である場合に、第１の再送タイプまたは第２の再送タイプを利用可能であると判断し、前記バッファ空き容量が閾値に満たない場合に、第２の再送タイプを利用可能であると判断することを特徴とする請求項２に記載の通信装置。
4. 前記第１の再送タイプは、ＩＲ（Ｉｎｃｒｅｍｅｎｔａｌ Ｒｅｄｕｎｄａｎｃｙ）タイプであり、前記第２の再送タイプは、ＣＣ（Ｃｈａｓｅ Ｃｏｍｂｉｎｉｎｇ）タイプであることを特徴とする請求項３に記載の通信装置。
5. 前記閾値は、前記通信装置と前記他の通信装置とが接続する周波数帯域の幅と、前記通信装置のメモリにおいてデータを滞留させる時間の少なくとも一方に基づいて設定されることを特徴とする請求項３または４に記載の通信装置。
6. 複数の前記他の通信装置が前記通信装置に接続されている場合、前記判断手段は、前記他の通信装置の数に基づいて、前記利用可能な前記ＨＡＲＱの再送タイプを判断することを特徴とする請求項１に記載の通信装置。
7. 複数の前記他の通信装置が前記通信装置に接続されている場合、前記判断手段は、トリガーフレームを用いて前記複数の前記他の通信装置とアップリンク通信またはダウンリンク通信を行うかどうかに基づいて、前記利用可能な前記ＨＡＲＱの再送タイプを判断することを特徴とする請求項１に記載の通信装置。
8. 前記他の通信装置により利用することが可能な前記ＨＡＲＱの再送タイプの情報を取得する取得手段と、
   前記通信装置が利用可能な前記ＨＡＲＱの再送タイプと、前記他の通信装置により利用することが可能な前記ＨＡＲＱの再送タイプとに基づいて、前記データ通信に使用する再送タイプを決定する決定手段と、を更に有し、
   前記通信手段は、前記決定手段により決定された再送タイプを用いて前記データ通信を行うことを特徴とする請求項１から７のいずれか１項に記載の通信装置。
9. 前記取得手段は、マネージメントフレームの送受信により、前記他の通信装置により利用することが可能な前記ＨＡＲＱの再送タイプの情報を取得することを特徴とする請求項８に記載の通信装置。
10. 前記決定手段により、前記他の通信装置との前記データ通信に使用する再送タイプが決定された後、前記他の通信装置に対して、前記通信装置との前記データ通信のための周波数帯域の幅およびデータレートの情報を通知する通知手段を更に有し、
    前記通知手段による前記通知の後、前記通信手段は、前記データ通信を行うことを特徴とする請求項８または９に記載の通信装置。
11. 複数の前記他の通信装置が前記通信装置に接続されている場合、
    前記決定手段は、前記他の通信装置のそれぞれに対して前記データ通信に使用する再送タイプを決定し、
    前記通知手段は、前記他の通信装置のそれぞれに対して、使用する再送タイプ、前記通信装置と前記データ通信のための周波数帯域の幅およびデータレートの情報を通知し、
    前記通知手段による前記通知の後、前記通信手段は、前記決定手段により決定された再送タイプを用いて、前記他の通信装置のそれぞれに対して前記データ通信を行うことを特徴とする請求項１０に記載の通信装置。
12. 前記通知手段は、前記通知を、トリガーフレーム、Ａｃｔｉｏｎフレーム、Ｂｌｏｃｋ Ａｃｋ Ｒｅｑｕｅｓｔフレームのいずれかを用いて行うことを特徴とする請求項１１に記載の通信装置。
13. 通信装置の制御方法であって、
    ＩＥＥＥ８０２．１１シリーズの規格に準拠し、ＨＡＲＱ（ハイブリッド自動再送要求）を用いて他の通信装置とデータ通信を行う通信工程と、
    前記通信装置のＩＥＥＥ８０２．１１シリーズの規格に準拠した通信に関する状態 に基づいて、前記通信工程における前記他の通信装置とのデータ通信において前記通信装置が利用可能な前記ＨＡＲＱの再送タイプを判断する判断工程と、
    を有することを特徴とする通信装置の制御方法。
14. コンピュータを、請求項１から１１のいずれか１項に記載の通信装置として機能させるためのプログラム。

Images