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

Abstract

【課題】複数リンクを用いた通信において効率的な確認応答制御を実現する技術を提供する。【解決手段】ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置は、複数のリンクを用いて複数のデータフレームを通信相手装置へ送信し、送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを通信相手装置に送信し、要求フレームを送信することに応答して通信相手装置からＡｃｋフレームを受信する。要求フレームは、複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含む。シーケンス情報は、各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含む。【選択図】図４

Description

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

ＩＥＥＥ（Institute of Electrical and Electronics Engineers、米国電気電子技術者協会）が策定している無線ＬＡＮ（Local Area Network）通信規格として、ＩＥＥＥ８０２．１１シリーズが知られている。ＩＥＥＥ８０２．１１シリーズ規格としては、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ規格などの規格がある（特許文献１）。

ＩＥＥＥ８０２．１１ａｘ規格では、複数の無線パケットの受信について、一つのフレームで確認応答（Acknowledgement（ＡＣＫ））を送信できるＢｌｏｃｋＡｃｋフレームの拡張仕様が開示されている。ＩＥＥＥ８０２．１１ａｘ規格では、ＢｌｏｃｋＡｃｋフレーム中のＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐで表現できるＭＰＤＵ（MAC（Media Access Control） Protocol Data Unit）の数を、ＩＥＥＥ８０２．１１ａｃまでの６４から２５６に拡張する仕様が開示されている。一度に確認応答が行えるＭＰＤＵ数が増えることで、スループットの向上を実現している。

特開２０１８－５０１３３号公報

ＩＥＥＥでは、さらなるスループットの向上や周波数利用効率の改善のため、ＩＥＥＥ８０２．１１シリーズの新たな規格として、ＩＥＥＥ８０２．１１ｂｅ規格の策定が検討されている。ＩＥＥＥ８０２．１１ｂｅ規格では、一度に確認応答が行えるＭＰＤＵの数をさらに５１２や１０２４へ拡張することが提案されている。また、ＩＥＥＥ８０２．１１ｂｅ規格では、無線装置間で複数の無線リンクを用いて通信するＭｕｌｔｉ－Ｌｉｎｋ通信や複数の無線アクセスポイントが一つの無線端末と接続し通信するＭｕｌｔｉ－ＡＰ通信の方式が検討され、複数リンク間にまたがった確認応答の方式についても検討が進められている。

無線装置間で複数のリンクを使用して通信を行う場合、送信側装置は、各リンクで異なる塊のシーケンス番号のデータフレームを送信することが想定される。このとき、受信側装置は、各リンクで一部分が歯抜けのシーケンス番号のデータフレームが受信し得る。従来では、このような場合に対して効率的な確認応答の方式が提案されていなかった。

上記課題を鑑み、本発明は、複数リンクを用いた通信において効率的な確認応答制御を実現するための技術を提供することを目的とする。

上記目的を達成するため、本発明の一態様に係る無線通信装置は、以下の構成を有する。すなわち、ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含む。

本発明によれば、複数リンクを用いた通信において効率的な確認応答制御が実現される。

ネットワーク構成例を示す図である。 通信装置（ＳＴＡ、ＡＰ）のハードウェア構成例を示す。 通信装置（ＳＴＡ、ＡＰ）の機能構成例を示す。 ＡＰとＳＴＡ間におけるデータ通信のための通信シーケンス図を示す。 ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。 ＡＣＫ Ｉｎｆｏサブフィールドの構成例１～３を示す。 ＡＣＫ Ｉｎｆｏサブフィールドの構成例４～６を示す。 データフレーム送信側によるフレーム送信処理のフローチャートである。 データフレーム生成・送信処理のフローチャートである。 ＢＡＲフレーム生成・送信処理のフローチャートである。 データフレーム送信側によるフレーム受信処理のフローチャートである。 ＢＡフレーム受信処理のフローチャートである。 データフレーム受信側によるフレーム受信処理のフローチャートである。 シーケンス番号確認処理のフローチャートである。 ＢＡフレーム生成・送信処理のフローチャートである。

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

（ネットワークの構成）
図１に、本実施形態によるネットワークの構成例を示す。図１は、通信装置（無線通信装置）として、１つのＡＰ（アクセスポイント）（ＡＰ１０２）と１つのＳＴＡ（ステーション／端末装置）（ＳＴＡ１０３）を含んだ構成を示している。なお、本実施形態の説明は、ＡＰとＳＴＡどちらにも適用可能であり、どちらかに限定されない。図１に示すように、ＡＰ１０２が形成するネットワークは円１０１で示される。

本実施形態では、ＳＴＡ１０３は、ＡＰ１０２と無線リンク１０４および１０５を介してフレームを送受信できるものとする。無線リンク１０４、１０５は２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ帯の周波数バンドのチャネルを使用することができるが、使用する周波数バンドはこれに限定されるものではなく、６０ＧＨｚ帯のように別の周波数バンドを使用しても良い。ＳＴＡ１０３とＡＰ１０２のＭｕｌｔｉ－Ｌｉｎｋ通信のＣａｐａｂｉｌｉｔｙ情報に応じて、無線リンク１０４、１０５として、２．４ＧＨｚ帯と５ＧＨｚ帯のチャネルを組み合わせて使用しても良いし、６ＧＨｚ帯の中から複数のチャネルを選択して組み合わせて使用しても良い。また、複数のＡＰと一つのＳＴＡ間の通信を扱うＭｕｌｔｉ－ＡＰ通信の場合も同様に、本実施形態を適用することができる。本実施形態においては、無線リンク１０４、１０５の二本の無線リンクを対象に説明するが、これに限定されず、三本以上のリンクを使用する場合にも、本実施形態を適用することができる。

なお、図１に示すネットワーク構成は一例であり、例えばさらに広範な領域に多数の通信装置を含むネットワークに対して、また、様々な通信装置の位置関係に対して、以下の議論を適用可能である。

（通信装置の構成）
次に、本実施形態による通信装置（ＡＰ、ＳＴＡ）の構成について説明する。図２に、本実施形態に係るＡＰのハードウェア構成例を示す。ＡＰは、そのハードウェア構成の一例として、記憶部２０１、制御部２０２、機能部２０３、入力部２０４、出力部２０５、１つ以上の通信部２０６及び１つ以上のアンテナ２０７を有する。なお、ＳＴＡもＡＰと同様のハードウェア構成を有し、以下の説明をＳＴＡに適用可能である。

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

制御部２０２は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等のプロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（Field Programmable Gate Array）等により構成される。制御部２０２は、記憶部２０１に記憶されたプログラムを実行することによりＡＰ全体を制御する。なお、制御部２０２は、記憶部２０１に記憶されたプログラムとＯＳ（Operating System）との協働によりＡＰ全体を制御するようにしてもよい。

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

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

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

無線アンテナ２０７は、それぞれサブＧＨｚ帯、２．４ＧＨｚ帯、５ＧＨｚ帯、及び６ＧＨｚ帯のいずれかが受信可能なアンテナである。無線アンテナ２０７はＭＩＭＯ（Multi-Input Multi-Output）送受信を実現するために、物理的に一本以上のアンテナで構成されても良い。

ＡＰは、複数のリンクを使用して通信を行う場合、図２に示すように、通信部２０６とアンテナ２０７をそれぞれ複数備えてもよい（図２は一例として通信部２０６とアンテナ２０７はそれぞれ２つ）。この場合、無線リンクごとに一つの通信部２０６、アンテナ２０７を割り当ててもよいし、複数のリンクで一つの通信部２０６、アンテナ２０７を共用しても良い。

図３に、本実施形態によるＡＰの機能構成例を示す。ＡＰは、その機能構成の一例として、フレーム解析部３０１、フレーム生成部３０２、接続管理部３０３、フレーム送受信部３０４を有する。なお、ＳＴＡもＡＰと同様の機能構成を有し、以下の説明をＳＴＡに適用可能である。

フレーム解析部３０１は、通信相手装置（対向の通信装置）から受信したフレームを解析する。フレーム生成部３０２は、通信相手装置へ送信するフレーム（無線フレーム）を生成する。接続管理部３０３は、通信相手装置との間の接続を管理する。例えば、接続管理部３０３は、各通信相手装置に対して、接続中のＢｌｏｃｋＡｃｋ（ＢＡ）の取り決め・合意（ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ）や、データのシーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）の管理を行う。ＢｌｏｃｋＡｃｋ ＡｇｒｅｅｍｅｎｔやＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒは、接続内のＴＩＤ（Traffic Identifier（トラフィック（データ）の種別を表す識別子））ごとに管理される。フレーム送受信部３０４は、通信相手装置との間で、通信部２０６とアンテナ２０７（図２）を介してフレームを送受信する。

（ＡＰとＳＴＡ間の通信シーケンス）
図４に、ＡＰ１０２とＳＴＡ１０３間におけるデータ通信のための通信シーケンス図を示す。本シーケンスの処理は、ＡＰ１０２およびＳＴＡ１０３のそれぞれの電源が投入されたことに応じて開始されうる。あるいは、本シーケンスの処理は、ＡＰ１０２およびＳＴＡ１０３の少なくとも一方が、ユーザまたはアプリケーションから無線通信の開始を指示されたことに応じて開始されてもよい。ここでは、図１のようにＡＰ１０２とＳＴＡ１０３間で二つの無線リンク１０４、１０５が構成されているものとして説明する。

初めに、Ｆ４０１にて、ＡＰ１０２とＳＴＡ１０３は、ＩＥＥＥ８０２．１１規格に従接続処理を行うことにより、無線接続を確立する。本実施形態は、通信の暗号化なしの場合および暗号化ありの場合のいずれにも適用可能である。また、暗号化ありの場合の暗号化方式（セキュリティ方式）が、ＷＥＰ（Wired Equivalent Privacy）、ＷＰＡ（Wi-Fi Protected Access）１、ＷＰＡ２、ＷＰＡ３、ＷＰＳ（Wi-Fi Protected Setup）や、他の方式であっても、本実施形態を適用可能である。接続確立は、一つの代表するリンク（例えばリンク１０４）でのみ行い、副次的にもう一方のリンクの接続も行うようにしても良いし、それぞれのリンクで独立して接続が確立されても良い。

本例では、ＡＰ１０２からＳＴＡ１０３へデータ送信をする例を示す。Ｆ４０１にて接続確立後、Ｆ４０２においてＡＰ１０２は、ＡＤＤＢＡ ＲｅｑｕｅｓｔフレームをＳＴＡ１０３へ送信し、Ｆ４０３でその確認応答としてＡＣＫフレームを受信する。次にＳＴＡ１０３は、Ｆ４０４にてＡＤＤＢＡ ＲｅｓｐｏｎｓｅフレームをＡＰ１０２へ送信し、Ｆ４０５でその確認応答としてＡＣＫフレームを受信する。本ＡＤＤＢＡ ＲｅｑｕｅｓｔとＡＤＤＢＡ Ｒｅｓｐｏｎｓｅのやりとり（Ｆ４０２～Ｆ４０５の処理）が完了すると、ＡＰ１０２とＳＴＡ１０３の間で、ＡＰ１０２⇒ＳＴＡ１０３へのデータ送信に関して、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔが構築される。ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔの構築は，リンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行い、副次的にもう一方のリンクでも構築されるようにしても良い。

ここで、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔについて説明する。ＡＤＤＢＡ ＲｅｑｕｅｓｔフレームとＡＤＤＢＡ Ｒｅｓｐｏｎｓｅフレームには、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータが含まれ、当該フレームを受信した通信装置は、当該パラメータに合意する場合にＡＣＫフレームを送信する。ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータは、Ｉｍｍｅｄｉａｔｅ（Ｉｍｍｅｄｉａｔｅ ＢｌｏｃｋＡｃｋ）またはＤｅｌａｙ（Ｄｅｌａｙｅｄ ＢｌｏｃｋＡｃｋ）に設定される。図４の例はＩｍｍｅｄｉａｔｅ設定の場合であり、ＡＰ１０２は要求フレームとしてＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔ（ＢＡＲ）フレームを送信し、ＳＴＡ１０３は当該フレームを受信したことを受けて、ＢｌｏｃｋＡｃｋフレームを返信する。一方、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙがＤｅｌａｙｅｄ設定の場合（不図示）、ＳＴＡ１０３は（Ｆ４０８のＢｌｏｃｋＡｃｋフレームの返信の代わりに）ＡＣＫフレームを返信する。そしてＳＴＡ１０３は、その後に取得したＴＸＯＰ（Transmission Opportunity）期間でＢｌｏｃｋＡｃｋフレームを送信することになる。

また、ＡＤＤＢＡ Ｒｅｑｕｅｓｔフレームには、１つのＢＡセッションにおいて送信するデータの開始番号に関する情報（Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ）の各種パラメータ（Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ（開始シーケンス番号）等）が含まれる。Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの初期値は、ＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅのやりとりによって決定されうる。その後のＳｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒの更新はＩＥＥＥ８０２．１１規格規定の方法に従いうる。

また、ＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームには、自装置がサポートするＢＡ Ｔｙｐｅ／ＢＡＲ Ｔｙｐｅが含まれ得る。例えば、当該フレームには、図５～図７を用いて後述するＮｅｗ ＢＡ／Ｎｅｗ ＢＡＲをサポートするか否かの情報が含まれ得る（後述する構成例１～７のいずれか１つ以上をサポートするかの情報も含まれ得る）。当該フレームを受信した通信装置は、通信相手装置のサポートするＢＡ Ｔｙｐｅ／ＢＡＲ Ｔｙｐｅを記録・管理する。

本実施形態では、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３が、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時に、ＴＩＤに対する上記の各種パラメータや情報を記憶部２０１に記録し、管理する。

ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔが構築された後、ＡＰ１０２は、通信相手装置（対向の通信装置）であるＳＴＡ１０３からのＡＣＫフレームの受信前に、複数のデータフレームを送信することが可能になる。例えば、ＡＰ１０２は、Ｆ４０６（データ送信処理）において複数のＭＰＤＵ（データフレーム）を送信し、ＳＴＡ１０３は複数のＭＰＤＵの確認応答としてＦ４０８においてＢｌｏｃｋ Ａｃｋフレームを送信する。上記のように、図４の例は、ＢｌｏｃｋＡｃｋＰｏｌｉｃｙパラメータにＩｍｍｅｄｉａｔｅが設定されている場合である。ＡＰ１０２がＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームを送信（Ｆ４０７）した後に（送信したことに応答して）、ＳＴＡ１０３はＢｌｏｃｋＡｃｋフレームを返信（Ｆ４０８）する。

ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームの送信（Ｆ４０７）やＢｌｏｃｋＡｃｋフレームの返信（Ｆ４０８）は、リンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行ってもよい。この場合、当該代表リンクで搬送される情報の中に、もう一方のリンク向けの情報を含むようにしても良い。

図４の例では、ＡＰ１０２はＦ４０７でＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレームをＳＴＡ１０３へ送信している。これに代えて、ＡＰ１０２は、Ｆ４０６のＭＰＤＵ群の内の少なくとも一つのＭＰＤＵ内のＱｏＳ Ｃｏｎｔｒｏｌフィールドに含まれるＡｃｋ ＰｏｌｉｃｙサブフィールドをＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔに設定してもよい。すなわち、ＡＰ１０２は、ＭＰＤＵ群の内の少なくとも一つにおいて、ＳＴＡ１０３に対してＢｌｏｃｋＡｃｋフレームを要求するＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔ（要求情報）を含めてもよい。これにより、ＡＰ１０２は、ＢｌｏｃｋＡｃｋＲｅｑｕｅｓｔフレーム（Ｆ４０７）を送信せずに、ＳＴＡ１０３へＢｌｏｃｋＡｃｋフレームを要求することができる。このとき、Ｉｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔの送信、ＢｌｏｃｋＡｃｋフレームの返信はリンクごとに独立して実行しても良いし、一つの代表リンク（例えばリンク１０４）でのみ行ってもよい。この場合、当該代表リンクで搬送される情報の中に、もう一方のリンク向けの情報を含むようにしても良い。

Ｆ４０８で返信されるＢｌｏｃｋＡｃｋフレームには、Ｆ４０６のデータ送信において送信されたデータフレームのシーケンス番号に基づいて設定された情報が含まれる。従来の８０２．１１仕様においては、ＢｌｏｃｋＡｃｋフレームで返すシーケンス番号は連続していることが前提となっていた。例えば、Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを開始点とするＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐで表現できるビット数分のデータフレーム（パケット）について、受信できたか否かをＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐで示す仕様になっていた。この場合、図４のシーケンスのようにデータを複数のリンクでそれぞれ送信する場合に問題となる。例えば、データの送信側装置が、リンク１０４でシーケンス番号１、３のデータを、リンク１０５でシーケンス番号２、４のデータを送信する場合を考える。この場合、データの受信側装置は、リンク１０４ではシーケンス番号２、４のデータ、リンク１０５ではシーケンス番号１、３のデータをそれぞれ受信できない。そのため、当該受信側装置は、これらのシーケンス番号を、ロスフレームとしてＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐ上で表現してしまう。各リンクにおいて、ロスフレームとして表現されたシーケンス番号のデータは、別リンクで送信されているにも関わらず、送信側装置による再送処理に入ることが想定され、不必要な再送による帯域消費を生じてしまう。

本実施形態では、データ送信側装置は、ＢｌｏｃｋＡｃｋ ＲｅｑｕｅｓｔフレームもしくはＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔに設定されるすくなくとも一つのデータフレームにおいて、各リンクで送信した／送信していないデータのシーケンス番号の情報を含めて送信するように動作可能に構成される。なお、以下ではＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームを例に説明するが、同様の説明をＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔにも適用可能である。また、データ受信側装置は、ＢｌｏｃｋＡｃｋフレームにおいて、各リンクで受信した／受信しなかったデータのシーケンス番号の情報を含めて送信するように動作可能に構成される。

（ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成）
続いて、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成について説明する。なお、図４ではＡＰ１０２⇒ＳＴＡ１０３へのデータ送信の例を示したが、以下の説明は、ＳＴＡ１０３⇒ＡＰ１０２へのデータ送信にも同様に適用可能である。

図５（ａ）～（ｃ）に、８０２．１１ａｘ規格におけるＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームの構成を示す。図５（ａ）～（ｃ）共通の説明として、Ｏｃｔｅｓｔｓ、Ｂｉｔｓはそれぞれのフィールドのサイズを示す。ｖａｒｉａｂｌｅと示されているフィールドは可変長であることを意味する。図中（Ｒ）と示している箇所は、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームの場合に有効になり、ＢｌｏｃｋＡｃｋフレームの場合は無効になることを意味する。また、参照符号の付いていないフィールドの説明は割愛する。

図５（ａ）に、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレーム全体の構成を示す。ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレーム及びＢｌｏｃｋＡｃｋフレームは、ＭＡＣ ｈｅａｄｅｒフィールド５０１、ＢＡ（Ｒ） Ｃｏｎｔｒｏｌフィールド５０２、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３とＦＣＳフィールドから構成される。

図５（ｂ）に、ＢＡ（Ｒ） Ｃｏｎｔｒｏｌフィールド５０２の構成を示す。ＢＡ（Ｒ） Ｃｏｎｔｒｏｌフィールド５０２は、ＢＡ（Ｒ） Ａｃｋ Ｐｏｌｉｃｙサブフィールド、ＢＡ（Ｒ） Ｔｙｐｅサブフィールド５０４、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＴＩＤ＿ＩＮＦＯサブフィールドから構成される。ＢＡ（Ｒ） Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３は、ＢＡ（Ｒ） Ｔｙｐｅサブフィールド５０４に設定される情報に応じてそのフォーマットが規定される。ＩＥＥＥ８０２．１１ａｘ規格においては、ＢＡ（Ｒ） Ｔｙｐｅ０、４～５、７～９、１１～１５がＲｅｓｅｒｖｅｄ領域に指定されており、本実施形態では、このＲｅｓｅｒｖｅｄ領域の内の少なくとも一つを使用して、新たなＢＡ（Ｒ） Ｔｙｐｅを規定する。なお、本実施形態において提案する新規のＢＡ（Ｒ） Ｔｙｐｅを、Ｎｅｗ ＢＡ（Ｒ）と称する。

図５（ｃ）に、Ｎｅｗ ＢＡ（Ｒ）で規定されるＢＡ（Ｒ） Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３の構成を示す。ＢＡ（Ｒ） Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３は、ＢＡ（Ｒ） Ｓｕｂｔｙｐｅサブフィールド５０７、ＡＣＫ Ｉｎｆｏサブフィールド５０６から構成される。ＢＡ（Ｒ） Ｓｕｂｔｙｐｅサブフィールド５０７は、Ｂｉｔｓに記載の通り０が設定されてもよい。この場合、ＢＡ（Ｒ） Ｓｕｂｔｙｐｅに相当する情報をＢＡ（Ｒ） Ｔｙｐｅサブフィールド５０４内のＲｅｓｅｒｖｅｄ領域、もしくはＲｅｓｅｒｖｅｄサブフィールド５０５のＲｅｓｅｒｖｅｄ領域を用いて表現しても良い。なお、ここで提示したＢＡ（Ｒ） Ｓｕｂｔｙｐｅ、ＡＣＫ Ｉｎｆｏの名称は一例であり、これに限定されない。

（ＡＣＫ Ｉｎｆｏサブフィールドの構成）
本実施形態における、図５（ｃ）におけるＡＣＫ Ｉｎｆｏサブフィールド５０６（シーケンス情報）のいくつかの構成例について、図６と図７を用いて説明する。なお、以下に記載する各部の名称、サイズ、格納する順番については一例であり、同様な機能を果たすものであればこれに限定されない。以下では、ＡＰ１０２（データ送信側装置）が送信するＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームを例に説明する。

≪送信したＭＰＤＵを示すＡＣＫ Ｉｎｆｏサブフィールドの構成（構成例１～３）≫
図６（ａ）～（ｃ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例１～３を示す。構成例１～３に示すＡＣＫ Ｉｎｆｏサブフィールド５０６は、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームに格納される。構成例１～３は、ＡＰ１０２が送信したＭＰＤＵ（データフレーム）に関する情報を送信する場合の構成例である。構成例１～３共通の構成として、ＡＣＫ Ｉｎｆｏサブフィールド５０６は、ＡＣＫ Ｉｎｆｏ全体のメタ情報を含むＡＣＫ Ｉｎｆｏヘッダ部（ＡＣＫ Ｉｎｆｏヘッダ部６０１、６０７、６１４に対応）と、送信したフレーム群（データフレーム群）を特定する特定情報（フレーム群６０２、６０３、６０９、６１０、６１５、６１６に対応）を含むＡＣＫ Ｉｎｆｏデータ部で構成される。なお、ここで示したＡＣＫ Ｉｎｆｏヘッダ、ＡＣＫ Ｉｎｆｏデータという名称は一例であり、これに限定されない。

ＡＰ１０２は、リンクごとにＳＴＡ１０３へ送信したデータを、シーケンス番号が連番である一連のデータの塊ごとに、フレーム群として区別する。つまり、送信したデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。送信したすべてのフレーム群についての情報をＡＣＫ Ｉｎｆｏサブフィールド５０６に含めることによって、ＳＴＡ１０３へ確認応答を依頼するフレームについての情報を提供することができる。ＳＴＡ１０３は依頼されたフレームについて、確認応答を送信すれば良い。ＡＣＫ Ｉｎｆｏヘッダ部に含まれるデータ長はＡＣＫ Ｉｎｆｏヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。

＜構成例１＞
図６（ａ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例１を示す。構成例１におけるＡＣＫ Ｉｎｆｏヘッダ部６０１は、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長（後続の全てのフレーム群を指定する情報のデータ長）を示す情報を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり２４ビットの構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。

ＩＥＥＥ８０２．１１においてＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ（シーケンス番号）は１２ビットで表現され、０～４０９５の値で表現される。構成例１では、フレーム群６０２、６０３の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）６０４と終了シーケンス番号（Ｅｎｄ ＳＮ）６０５を用いる。開始シーケンス番号６０４と終了シーケンス番号６０５はそれぞれ１２ビットで表現可能である。開始シーケンス番号６０４は、各送信フレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。終了シーケンス番号６０５は、各送信フレーム群の終了に相当するＭＰＤＵのシーケンス番号を示す。

＜構成例２＞
図６（ｂ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例２を示す。構成例２におけるＡＣＫ Ｉｎｆｏヘッダ部６０７は、構成例１と同様に、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１２＋Ｃｏｕｎｔ Ｓｉｚｅ部６０８で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例２では、ＡＣＫ Ｉｎｆｏヘッダ部６０７は、さらにＣｏｕｎｔ Ｓｉｚｅ部６０８を含む。Ｃｏｕｎｔ Ｓｉｚｅ部６０８は、フレーム群６０９、６１０のＣｏｕｎｔ部（Ｃｏｕｎｔ部６１２に対応）のサイズを示す。

構成例２では、フレーム群６０９、６１０の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）６１１とＣｏｕｎｔ部６１２を用いる。開始シーケンス番号６１１は、構成例１と同様に、各送信フレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。Ｃｏｕｎｔ部６１２は、開始シーケンス番号６１１から開始し、何個分の連続するシーケンス番号を持つＭＰＤＵを送信したかの個数を示す情報を保持する。Ｃｏｕｎｔ Ｓｉｚｅ部６０８で指定するＣｏｕｎｔ部のサイズが小さいと、フレーム群として表現できる最大ＭＰＤＵ数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Ｃｏｕｎｔ Ｓｉｚｅ部６０８で指定するＣｏｕｎｔ部のサイズが大きいと、フレーム群として表現できる最大ＭＰＤＵ数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのＣｏｕｎｔ Ｓｉｚｅを使用するかは本例においては限定しない。開始シーケンス番号は、１２ビットで表現可能である。

本構成例では、一つのフレーム群内で表現できるＭＰＤＵ数の上限がＣｏｕｎｔ Ｓｉｚｅ部６０８によって規定されるため、連続するシーケンス番号を持つＭＰＤＵであっても別のフレーム群として表現される場合がある。

＜構成例３＞
図６（ｃ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例３を示す。構成例３におけるＡＣＫ Ｉｎｆｏヘッダ部６１４は、構成例１と同様に、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１６＋各フレームのＣｏｕｎｔ Ｓｉｚｅ部で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例３では、フレーム群６１５、６１６の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）６１７とＣｏｕｎｔ Ｓｉｚｅ部６１８とＣｏｕｎｔ部６１９を用いる。構成例２でＡＣＫ Ｉｎｆｏヘッダ部６０７に格納したＣｏｕｎｔ Ｓｉｚｅ部６０８を、Ｃｏｕｎｔ Ｓｉｚｅ部６１８としてそれぞれのフレーム群内に格納する。これにより、ヘッダ部でＣｏｕｎｔ Ｓｉｚｅを固定せずに、各フレーム群で適切なＣｏｕｎｔ Ｓｉｚｅを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はＣｏｕｎｔ Ｓｉｚｅを大きく設定し、少ない場合は小さく設定することで、適切なＣｏｕｎｔ Ｓｉｚｅが設定できる。

≪送信していないＭＰＤＵを示すＡＣＫ Ｉｎｆｏサブフィールドの構成（構成例４～６）≫
図７（ａ）～（ｃ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例４～６を示す。構成例４～６に示すＡＣＫ Ｉｎｆｏサブフィールド５０６は、データフレームの送信側から送信されるＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームに格納される。構成例４～６は、ＡＰ１０２が送信していないＭＰＤＵに関する情報を送信する場合の構成例である。構成例４～６共通の構成として、ＡＣＫ Ｉｎｆｏサブフィールド５０６は、ＡＣＫ Ｉｎｆｏ全体のメタ情報を含むＡＣＫ Ｉｎｆｏヘッダ部（ＡＣＫ Ｉｎｆｏヘッダ部７２１、７２４、７２７に対応）と、送信したフレーム群（データフレーム群）を特定する特定情報（フレーム群７０２、７０３、７０９、７１０、７１５、７１６に対応）を含むＡＣＫ Ｉｎｆｏデータ部で構成される。なお、ここで示したＡＣＫ Ｉｎｆｏヘッダ、ＡＣＫ Ｉｎｆｏデータという名称は一例であり、これに限定されない。

ＡＰ１０２はリンクごとにＳＴＡ１０３へ送信していないデータをシーケンス番号が連番である一連のデータの塊ごとに、フレーム群として区別する。つまり、送信していないデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。送信していないすべてのフレーム群についての情報をＡＣＫ Ｉｎｆｏサブフィールド５０６に含めることによって、ＳＴＡ１０３へ確認応答を依頼するフレームについての情報を提供することができる。ＳＴＡ１０３は依頼されたフレームについて、確認応答を送信すれば良い。

構成例４～６が構成例１～３と異なる点は、ＡＣＫ Ｉｎｆｏヘッダ部に新しく送信したフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報を含むことである。これは、構成例４～６においては、ＡＣＫ Ｉｎｆｏデータ部に送信していないＭＰＤＵに関する情報を含むため、それのみではどこからどこまでのシーケンス番号を送信したか、特定することができないためである。ＡＣＫ Ｉｎｆｏサブフィールド５０６全体として表現するフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報と、送信していないＭＰＤＵのシーケンス番号を組み合わせることで、送信したＭＰＤＵのシーケンス番号を特定することができる。ＡＣＫ Ｉｎｆｏヘッダ部に含まれるデータ長はＡＣＫ Ｉｎｆｏヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。

＜構成例４＞
図７（ａ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例４を示す。構成例４におけるＡＣＫ Ｉｎｆｏヘッダ部７２１は、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長を示す情報７０１を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり２４ビットの構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。

ＩＥＥＥ８０２．１１においてＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ（シーケンス番号）は１２ビットで表現され、０～４０９５の値で表現される。構成例４では、フレーム群７０２、７０３の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）７０４と終了シーケンス番号（Ｅｎｄ ＳＮ）７０５を用いる。開始シーケンス番号７０４と終了シーケンス番号７０５はそれぞれ１２ビットで表現可能である。開始シーケンス番号７０４は、各送信していないフレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。終了シーケンス番号７０５は、送信していないフレーム群の終了に相当するＭＰＤＵのシーケンス番号を示す。構成例４ではＡＣＫ Ｉｎｆｏヘッダ部７２１内に送信したフレーム群の開始シーケンス番号７２２と終了シーケンス番号７２３を含む。

＜構成例５＞
図７（ｂ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例５を示す。構成例５におけるＡＣＫ Ｉｎｆｏヘッダ部６０７は、構成例４と同様に、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１２＋Ｃｏｕｎｔ Ｓｉｚｅ部７０８で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例５では、ＡＣＫ Ｉｎｆｏヘッダ部７２４は、さらにＣｏｕｎｔ Ｓｉｚｅ部７０８を含む。Ｃｏｕｎｔ Ｓｉｚｅ部７０８は、フレーム群７０９、７１０のＣｏｕｎｔ部（Ｃｏｕｎｔ部７１２に対応）のサイズ、さらにＡＣＫ Ｉｎｆｏヘッダ部７２４に含まれるＣｏｕｎｔ部７２６のサイズも示す。

構成例５では、フレーム群７０９、７１０の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）７１１とＣｏｕｎｔ部７１２を用いる。開始シーケンス番号７１１は、構成例４と同様に、送信していないフレーム群の先頭に相当するＭＰＤＵのシーケンス番号を示す。Ｃｏｕｎｔ部７１２は、開始シーケンス番号７１１から開始し、何個分の連続するシーケンス番号を持つＭＰＤＵを送信していないかの個数を示す情報を保持する。Ｃｏｕｎｔ Ｓｉｚｅ部７０８で指定するＣｏｕｎｔ部のサイズが小さいと、フレーム群として表現できる最大ＭＰＤＵ数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Ｃｏｕｎｔ Ｓｉｚｅ部７０８で指定するＣｏｕｎｔ部のサイズが大きいと、フレーム群として表現できる最大ＭＰＤＵ数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのＣｏｕｎｔ Ｓｉｚｅを使用するかは本例においては限定しない。開始シーケンス番号は１２ビットで表現可能である。

本構成例では、一つのフレーム群内で表現できるＭＰＤＵ数の上限がＣｏｕｎｔ Ｓｉｚｅ部７０８によって規定されるため、連続するシーケンス番号を持つＭＰＤＵであっても別のフレーム群として表現される場合がある。

また、本構成例では、ＡＣＫ Ｉｎｆｏヘッダ部７２４は、送信したフレーム群の開始シーケンス番号７２５とそこから終了シーケンス番号までの総数（個数）を意味するＣｏｕｎｔ部７２６を含む。ＡＣＫ Ｉｎｆｏヘッダ部７２４内のＣｏｕｎｔ部７２６のサイズはＣｏｕｎｔ Ｓｉｚｅ部７０８で規定せず、１２ビットに固定する、もしくはＣｏｕｎｔ部７２６の情報を示すＣｏｕｎｔ Ｓｉｚｅ部を別途ＡＣＫ Ｉｎｆｏヘッダ部に保持しても良い。

＜構成例６＞
図７（ｃ）に、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成例６を示す。構成例６におけるＡＣＫ Ｉｎｆｏヘッダ部７２７は、構成例４と同様に、ＡＣＫ Ｉｎｆｏデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のＡＣＫ Ｉｎｆｏ部のデータ長をビット単位、バイト単位、フレーム群数（本例においては１フレーム群あたり１６＋各フレームのＣｏｕｎｔ Ｓｉｚｅ部で示すビット数の構成）単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例６では、フレーム群７１５、７１６の表現方法として、各フレーム群における開始シーケンス番号（Ｓｔａｒｔ ＳＮ）７１７とＣｏｕｎｔ Ｓｉｚｅ部７１８とＣｏｕｎｔ部７１９を用いる。構成例５でＡＣＫ Ｉｎｆｏヘッダ部６０７に格納したＣｏｕｎｔ Ｓｉｚｅ部７０８をそれぞれのフレーム群内に格納する。これにより、ヘッダ部でＣｏｕｎｔ Ｓｉｚｅを固定せずに、各フレーム群で適切なＣｏｕｎｔ Ｓｉｚｅを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はＣｏｕｎｔ Ｓｉｚｅを大きく設定し、少ない場合は小さく設定することで、適切なＣｏｕｎｔ Ｓｉｚｅが設定できる。

また、本構成例では、ＡＣＫ Ｉｎｆｏヘッダ部７２７は、送信したフレーム群の開始シーケンス番号７２８とそこから終了シーケンス番号までの総数を意味するＣｏｕｎｔ部７３０、Ｃｏｕｎｔ部７３０のサイズ情報を示すＣｏｕｎｔＳｉｚｅ部７２９を含む。

［構成例７］
構成例７は、８０２．１１規格に規定されているＢＡ Ｔｙｐｅ：Ｃｏｍｐｒｅｓｓｅｄで使用されるＣｏｍｐｒｅｓｓｅｄ ＢｌｏｃｋＡｃｋ Ｖａｒｉａｎｔの書式を流用した構成である。この構成では、ＡＣＫ Ｉｎｆｏサブフィールド５０６（シーケンス情報）の中にＦｒａｇｍｅｎｔ Ｎｕｍｂｅｒ（４ビット）、Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ（１２ビット）、Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐ（８もしくは３２バイト）を格納する。Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐのサイズ、一度に表現できるＭＳＤＵ／Ａ－ＭＳＤＵの最大数は、Ｆｒａｇｍｅｎｔ Ｎｕｍｂｅｒの値に応じて定められ、８０２．１１ａｘ規格に準ずる。Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒは、送信したデータフレーム（ＭＰＤＵ）の開始シーケンス番号を示す値が設定され、当該開始シーケンス番号を開始点としてそれ以降のデータフレームについて、Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐの各ビットを対応付けて送信済みか否かを表現する。ビットが１に設定されているフレームは送信済み、ビットが０に設定されているフレームは送信していないと判定することができる。０、１の意味合いは逆でも良い。

以上、構成例１～７について、ＡＰ１０２（データ送信側装置）が送信するＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームを例に説明したが、ＳＴＡ１０３（データ受信側装置）が送信するＢｌｏｃｋＡｃｋフレームにも上記の構成に基づく構成を適用できる。例えば、構成例１～３については、受信したＭＰＤＵを示すＡＣＫ Ｉｎｆｏサブフィールドの構成として、上記の構成例１～３の説明における「送信したフレーム（群）」を「受信したフレーム（群）」に読み替えればよい。また、構成例４～６については、受信していないＭＰＤＵを示すＡＣＫ Ｉｎｆｏサブフィールドの構成として、上記の構成例４～６の説明における「送信していないフレーム（群）」を「受信できなかったフレーム（群）」に、「送信したフレーム（群）」を「受信したフレーム（群）」に読み替えればよい。また、構成例７については、Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒに、受信したデータフレーム（ＭＰＤＵ）の開始シーケンス番号を示す値を設定すればよい。また、Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐの各ビットに、データ送信側装置により送信されたデータフレームに対する受信結果を設定すればよい。構成例７を用いる場合のＢＡフレームに関する処理例については後述する。

また、Ｉｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔに設定されたデータフレームにも、上記の構成例１～６に基づく構成を適用できる。例えば、当該データフレームにおけるＢＡＲ ＣｏｎｔｒｏｌフィールドとＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールドに、上記の構成例１～６の構成を同様に適用すればよい。

（ＡＣＫ Ｉｎｆｏサブフィールドの構成の通知方法）
ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームの送信側は、構成例１～７のいずれかでＡＣＫ Ｉｎｆｏサブフィールド５０６を構成するかを該フレームにおいて特定（指定）し、受信側に通知することができる。例えば、構成例１～７のいずれを用いるかを、ＢＡＲ Ｔｙｐｅサブフィールド５０４、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＢＡＲ Ｓｕｂｔｙｐｅサブフィールド５０７の少なくともいずれかを用いて、特定することができる。

例えば、ＢＡＲ Ｔｙｐｅサブフィールド５０４のＲｅｓｅｒｖｅｄを意味するＢＡＲ Ｔｙｐｅ０を、構成例１～７のいずれかを用いることを意味するＢＡＲ Ｔｙｐｅと規定しても良い。さらに、構成例１～７の中のいずれを使うかを、ＢＡＲ Ｔｙｐｅサブフィールド５０４の他のＲｅｓｅｒｖｅｄ領域、Ｒｅｓｅｒｖｅｄサブフィールド５０５、ＢＡＲ Ｓｕｂｔｙｐｅサブフィールド５０７の内の少なくとも３ビットを使用することで特定しても良い。具体的には、ＢＡＲ Ｓｕｂｔｙｐｅサブフィールド５０７を使用する場合、ＢＡＲ Ｓｕｂｔｙｐｅサブフィールド５０７に００００というビットを指定した場合は構成例１を使用し、０００１というビットを指定した場合は構成例２を使用するといったように定義してもよい。

また、既存のＢＡＲ Ｔｙｐｅサブフィールド５０４と所定の（サブ）フィールドとを組み合わせて、構成例１～７のいずれかを用いることを特定してもよい。例えば、ＢＡＲ Ｔｙｐｅサブフィールド５０４をＭｕｌｔｉ－ＴＩＤやＭｕｌｔｉ－ＳＴＡに設定する場合を想定する。ＢＡＲ Ｔｙｐｅサブフィールド５０４をＭｕｌｔｉ－ＴＩＤに設定する場合、Ｒｅｓｅｒｖｅｄサブフィールド５０５の領域を使って構成例１～７のいずれかを用いることを特定してもよい。

なお、通信相手装置が、本実施形態によるＮｅｗ ＢＡＲ（すなわち構成例１～７のＡＣＫ Ｉｎｆｏサブフィールド５０６の構成）をサポートしているかどうか（Ｎｅｗ ＢＡＲ Ｔｙｐｅに対する能力情報を有するか）は、規格上対応必須と定めてもよい。あるいは、図４の例の場合、ＡＰ１０２とＳＴＡ１０３間でのＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを介して（ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時に）、能力情報を交換してもよい。あるいは、他のマネージメントフレームのやり取りを介して、能力をネゴシエートしても良い。より具体的には、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時に（図４参照）、例えばＡＤＤＢＡ Ｅｘｔｅｎｔｉｏｎ Ｅｌｅｍｅｎｔ内のＡＤＤＢＡ Ｃａｐａｂｉｌｉｔｉｅｓ Ｆｉｅｌｄ内のＲｅｓｅｒｖｅｄビットを使用してネゴシエーションすることができる。なお、ネゴシエーションはこの方法に限定されない。ネゴシエーションによって決定されたＮｅｗ ＢＡＲのサポートの可否は、接続管理部３０３にＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔの属性として記録されうる。

なお、上記では、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームの送信側によるＡＣＫ Ｉｎｆｏサブフィールドの構成の通知方法について説明したが、同様の説明をＢｌｏｃｋＡｃｋフレームの送信側のＡＣＫ Ｉｎｆｏサブフィールドの構成の通知方法に適用できる。この場合、上記説明において、「ＢＡＲ」を「ＢＡ」に読み替えればよい。また、Ｉｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔに設定されたデータフレームを用いる場合も、当該データフレームにおけるＢＡＲ ＣｏｎｔｒｏｌフィールドやＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールドを用いることにより、ＡＣＫ Ｉｎｆｏサブフィールドの構成を通知可能である。

＜データフレーム送信側の処理＞
次に、図８～図１２を用いて、データフレーム送信側の処理について説明する。ここでは、図４のようにデータフレーム送信側の装置がＡＰ１０２である場合を例に説明するが、本説明は、ＳＴＡ１０３が動作主体である場合にも同様に適用可能である。

（フレーム送信処理）
図８を用いて、本実施形態における、データフレーム送信側によるフレーム送信処理について説明する。図８は、データフレーム送信側によるフレーム送信処理のフローチャートである。当該処理は、ＡＰ１０２が通信相手装置（図４の例ではＳＴＡ１０３）と無線接続を確立し、ＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを終えた後に開始されうる。

なお、上述のように、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３は、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時（図４のＦ４０２～Ｆ４０５）に、ＢＡセッションにおけるＳｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ等の各種パラメータを記憶部２０１に記録し、管理しているものとする。さらに、ＡＰ１０２とＳＴＡ１０３それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ Ｔｙｐｅ（本実施形態のＮｅｗ ＢＡ（Ｒ）による新たなＢＡ（Ｒ） Ｔｙｐｅも含みうる）の情報を記憶部２０１に記録し、管理しているものとする。

ＡＰ１０２のフレーム生成部３０２が、通信相手装置（ＳＴＡ１０３）へのフレームを生成すると、フレーム送受信部３０４は、当該フレーム送信処理を開始する。フレーム送受信部３０４は、フレーム送信処理として初めに、送信するフレームがデータフレームかの判定を行う（Ｓ８０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ中のＴｙｐｅフィールドが、“１０”であるかどうかを確認することにより、判定可能である。“１０”の場合データフレーム、それ以外の場合はデータフレームでないと判定できる。

送信するフレームがデータフレームであると判定した場合（Ｓ８０１でＹｅｓ）、フレーム送受信部３０４は、データフレーム生成・送信処理を実行する（Ｓ８０２）。Ｓ８０２の処理の詳細は、図９を用いて後述する。Ｓ８０２の処理の後、フレーム生成部３０２は、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔ（ＢＡＲ）フレームを生成して送信するかの判定を行う（Ｓ８０３）。これは、例えば、フレーム送受信部３０４が最後にＢｌｏｃｋＡｃｋフレームを受信して以降の累計のデータフレーム（ＭＰＤＵ）の送信数に応じて判定してもよいし、その他の規則に従って判定してもよい。

ＢＡＲフレームを生成して送信すると判定した場合（Ｓ８０３でＹｅｓ）、フレーム生成部３０２はＢＡＲフレームを送信し、フレーム送受信部３０４は、ＢＡＲフレーム生成・送信処理を実行し（Ｓ８０４）、その後終了する。Ｓ８０４の処理の詳細は、図１０を用いて後述する。ＢＡＲフレームを生成しないと判定した場合（Ｓ８０３でＮｏ）、ＡＰ１０２はフレーム送信処理を終了する。

Ｓ８０１で、送信するフレームがデータフレームでないと判定した場合（Ｓ８０１でＮｏ）、ＡＰ１０２は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ８０５）、処理を終了する。Ｓ８０５の処理については、本実施形態との関連が低いため、説明を割愛する。

（データフレーム生成・送信処理）
次に、図９を用いてＳ８０２のデータフレーム生成・送信処理の一例について説明する。図９は、データフレーム生成・送信処理のフローチャートである。なお、データフレーム（ＭＰＤＵ）のシーケンス番号は、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＳｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌフィールド内のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒによって示され、０～４０９５の範囲の値を持つ。

ＡＰ１０２の接続管理部３０３は、フレーム送受信部３０４により送信予定のデータフレームのシーケンス番号を送信済みとして（送信済みシーケンス番号として）記憶部２０１に記録し、管理する（Ｓ９０１）。接続管理部３０３は、当該番号の情報を用いて、任意のシーケンス番号のデータが送信済みかどうかを判定することができる。接続管理部３０３で管理するシーケンス番号は、無線接続が確立した段階（図４の例ではＦ４０１）で、当該接続に関する送信シーケンス番号の管理を開始する。管理の開始時点では、すべてのシーケンス番号０～４０９５が未送信シーケンス番号とし て、記憶部２０１に記録される。なお、最初に送信するフレームのシーケンス番号は０から開始しても良いが、これに限定されない。４０９５にシーケンス番号が達した場合、次のフレームのシーケンス番号は０に戻る。

次に、フレーム生成部３０２は、Ａｃｋ Ｐｏｌｉｃｙを設定する（ＱｏＳ ＣｏｎｔｒｏｌフィールドにおけるＡｃｋ Ｐｏｌｉｃｙサブフィールドを設定する）（Ｓ９０２）。例えばＮｅｗ ＢＡＲをサポートすることを、ＱｏＳ ＣｏｎｔｒｏｌフィールドのＢｉｔ５、Ｂｉｔ６を使って示すことができる。例えば、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時に、ＡＰ１０２とＳＴＡ１０３がＮｅｗ ＢＡＲをサポートすると確認された場合に、フレーム生成部３０２は、ＱｏＳ ＣｏｎｔｒｏｌフィールドでＢｉｔ５：１、Ｂｉｔ６：０に設定することができる。また、Ｎｅｗ ＢＡＲをサポートすることを示すことで、当該データフレームにおいてＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔが設定されていることを示すことができる。

Ａｃｋ Ｐｏｌｉｃｙの設定後、ＡＰ１０２とＳＴＡ１０３がサポートするＢＡＲ Ｔｙｐｅに応じて、Ｆｒａｍｅ Ｂｏｄｙに情報を追加する（Ｓ９０３）。例えば、上記のようにＱｏＳ ＣｏｎｔｒｏｌフィールドにおいてＢｉｔ５：１、Ｂｉｔ６：０が設定された場合、フレーム生成部３０２は、図６と図７で説明した、送信した／送信していないシーケンス番号を特定する情報をＦｒａｍｅＢｏｄｙに含めることができる。この場合、受信側であるＳＴＡ１０３は、当該ＦｒａｍｅＢｏｄｙを解析し、ＡＰ１０２により送信されたデータのシーケンス番号の情報を抽出することができる。ＳＴＡ１０３がこのようなＡｃｋ Ｐｏｌｉｃｙを含むデータフレームを受信した場合は、ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔフレームの受信なしにＢｌｏｃｋＡｃｋフレームを返すことができる。続いて、フレーム生成部３０２は、残りのフレーム部を生成して、データフレームを完成させる（Ｓ９０４）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたデータフレームを通信相手装置（ＳＴＡ１０３）に送信する（Ｓ９０５）。

（ＢＡＲフレーム生成・送信処理）
次に、図１０を用いてＳ８０４のＢＡＲフレーム生成・送信処理について説明する。図１０は、ＢＡＲフレーム生成・送信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡＲ Ｔｙｐｅ（本実施形態によるＮｅｗ ＢＡＲ Ｔｙｐｅも含みうる）等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５を参照する。

ＡＰ１０２の接続管理部３０３は、接続のサポートする（自装置とＳＴＡ１０３のサポートする）ＢＡＲ Ｔｙｐｅを確認する（Ｓ１００１）。ここでは、ＡＰ１０２とＳＴＡ１０３はＮｅｗ ＢＡＲをサポートしているものとし、それ以外の場合は、ＩＥＥＥ８０２．１１規格に従った処理が行われ得る。続いて、接続管理部３０３は、送信済みシーケンス番号の確認を行う（Ｓ１００２）。

フレーム生成部３０２は、Ｓ１００１とＳ１００２で確認された情報を用いて、ＢＡＲフレームの生成を行う。まず、フレーム生成部３０２は、ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３におけるＡＣＫ Ｉｎｆｏサブフィールド５０６の構成を決定する（Ｓ１００３）。ここで、フレーム生成部３０２は、Ｓ１００１で確認されたサポートＢＡＲ Ｔｙｐｅに基づいて、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成を決定することができる。確認されたサポートＢＡ Ｔｙｐｅが、上記の構成例１～７のいずれかの構成をサポートすることを示す場合、フレーム生成部３０２は、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成として当該構成例１～７のいずれかを使用することを決定することができる。なお、上記の構成例１～７のいずれかの構成を使用することは、予めＡＰ１０２に固定的に設定されていてもよいし、入力部２０４を介したユーザによる入力操作により、設定（決定）されてもよい。

次に、フレーム生成部３０２は、Ｓ１００３で決定したＡＣＫ Ｉｎｆｏサブフィールド５０６の構成に従って、また、当該構成を特定（指定）するように、ＢＡ Ｃｏｎｔｒｏｌフィールド５０２とＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する（Ｓ１００４）。前述したように、ＡＣＫ Ｉｎｆｏサブフィールド５０６に構成例１～７のいずれかを使用することを、ＢＡＲ Ｃｏｎｔｒｏｌフィールド５０２／ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３における各種サブフィールドで指定することができる。また、フレーム生成部３０２は、Ｓ１００２で確認した送信済みシーケンス番号に基づいて、ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する。ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールドの具体的な内容については、構成例１～７にて説明したいずれかの書式で、Ｓ１００２で確認したシーケンス番号を表現する。

次に、フレーム生成部３０２は、残りのフレーム部を生成して、ＢＡＲフレームを完成させる（Ｓ１００５）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたＢＡＲフレームを通信相手装置（ＳＴＡ１０３）に送信する。

（フレーム受信処理）
次に図１１を用いて、本実施形態における、データフレーム送信側によるフレーム受信処理について説明する。図１１は、フレーム受信処理フローチャートである。ＡＰ１０２のフレーム送受信部３０４が、通信相手装置（ＳＴＡ１０３）から無線フレームを受信すると、フレーム解析部３０１は、受信したフレームの解析処理を開始する。なお、自身宛にフレームでない場合や、フレームが壊れている（例えばＦＣＳ値が不正）場合はこの処理を開始せずにフレームを破棄してもよい。

フレーム解析処理として、初めにフレーム解析部３０１は、受信したフレームがＢＡ（ＢｌｏｃｋＡｃｋ）フレームかの判定を行う（Ｓ１１０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ中のＴｙｐｅフィールドが“０１”かつ、Ｓｕｂｔｙｐｅフィールドが“１００１”であるかどうかを確認することにより、判定可能である。Ｔｙｐｅフィールドが“０１”かつ、Ｓｕｂｔｙｐｅフィールドが“１００１”の場合ＢｌｏｃｋＡｃｋフレーム、それ以外の場合はＢＡフレームでないと判定できる。

受信したフレームがＢＡフレームであると判定した場合（Ｓ１１０１でＹｅｓ）、ＡＰ１０２はＢＡフレーム処理を実行する（Ｓ１１０２）。Ｓ１１０２のＢＡフレーム受信処理につては、図１２を用いて後述する。受信したフレームがＢＡフレームでないと判定した場合（Ｓ１０１１でＮｏ）、ＡＰ１０２は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ１１０３）、処理を終了する。Ｓ１１０３の処理については、本実施形態との関連が低いため、説明を割愛する。

（ＢＡフレーム受信処理）
次に、図１２を用いてＳ１１０２のＢＡフレーム受信処理について説明する。図１２は、ＢＡフレーム受信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ Ｔｙｐｅ（本実施形態によるＮｅｗ ＢＡ Ｔｙｐｅも含みうる）等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５を参照する。

ＡＰ１０２の接続管理部３０３は、接続のサポートする（自装置とＳＴＡ１０３のサポートする）ＢＡ Ｔｙｐｅを確認する（Ｓ１２０１）。この情報は、Ｂｌｏｃｋ Ａｃｋ Ａｇｒｅｅｍｅｎｔ構築時に接続管理部３０３が確認し、記録済である。ＡＰ１０２は、ここで確認したＢＡ Ｔｙｐｅに応じて、以降の処理を切り替えることができる。

次に、ＡＰ１０２の接続管理部３０３は、受信したＢＡフレームに含まれるＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を確認する（Ｓ１２０２）。ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３の書式はＢＡ Ｔｙｐｅに応じて変わりうるが、接続管理部３０３は、当該フィールドに含まれる情報から、ＳＴＡ１０３により受信済みとして記録されたシーケンス番号（受信済みシーケンス番号）を抽出する（Ｓ１２０３）。例えばＢＡ ＴｙｐｅがＣｏｍｐｒｅｓｓｅｄの場合は、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３にＢｌｏｃｋＡｃｋ Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＣｏｎｔｒｏｌとＢｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐが含まれ得る。受信シーケンス番号の開始点と、そこからの各シーケンス番号の受信是非を表すＢｉｔｍａｐから、受信済みとして記録されたシーケンス番号を算出することができる。

次に、接続管理部３０３は、管理している送信済みシーケンス番号の更新を行う（Ｓ１２０４）。ＡＰ１０２は、Ｓ１２０３においてＳＴＡ１０３により受信済みと確認されたフレームについては、再送をする必要がなくなるため、送信済みという管理を行う必要がなくなる。よって、接続管理部３０３は、送信済みという記録を解除する。続いて、接続管理部３０３は、Ｓ１２０４で送信済みの記録を解除したフレームを送信バッファから削除しても良い（Ｓ１２０５）。

＜データフレームの受信側の処理＞
次に、図１３～図１５を用いて、データフレーム受信側の処理について説明する。ここでは、図４のようにデータフレーム受信側の装置がＳＴＡ１０３である場合を例に説明するが、本説明は、ＡＰ１０２が動作主体である場合にも同様に適用可能である。上述のように、ＢＡＲフレームに対するＢＡＲ Ｃｏｎｔｒｏｌフィールド５０２、ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に関する説明は、ＢＡ Ｃｏｎｔｒｏｌフィールド５０２、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に対してそれぞれ適用可能であり、詳細な説明は割愛する。

（フレーム受信処理）
図１３を用いて、本実施形態における、データフレーム受信側によるフレーム受信処理について説明する。図１３は、データフレーム受信側によるフレーム受信処理のフローチャートである。当該処理は、ＳＴＡ１０３が通信相手装置（図４の例ではＡＰ１０２）と無線接続を確立し、ＡＤＤＢＡ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅフレームのやりとりを終えた後に開始されうる。

なお、上述のように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、ＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時（図４のＦ４０２～Ｆ４０５）に、ＢＡセッションにおけるＳｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ等の各種パラメータを記憶部２０１に記録し、管理しているものとする。さらに、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ Ｔｙｐｅ（本実施形態によるＮｅｗ Ｔｙｐｅも含みうる）の情報を記憶部２０１に記録し、管理しているものとする。

ＳＴＡ１０３のフレーム送受信部３０４が、通信相手装置（ＡＰ１０２）からの無線フレームを受信すると、フレーム解析部３０１は、受信したフレームの解析処理を開始する。なお、自身宛にフレームでない場合や、フレームが壊れている（例えばＦＣＳ値が不正）場合は、ＳＴＡ１０３は、この処理を開始せずにフレームを破棄してもよい。

フレームの解析処理として、初めにフレーム解析部３０１は、受信したフレームがデータフレームかの判定を行う（Ｓ１３０１）。これは、例えば、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＦｒａｍｅ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ中のＴｙｐｅフィールドが“１０”であるかどうかを確認することにより、判定可能である。“１０”の場合はデータフレーム、それ以外の場合はデータフレームでないと判定できる。

受信したフレームがデータフレームであると判定した場合（Ｓ１３０１でＹｅｓ）、接続管理部３０３は、データフレームのシーケンス番号の確認処理を実行する（Ｓ１３０２）。Ｓ１３０２の処理の詳細は、図１４を用いて後述する。Ｓ１３０２の処理の後、フレーム解析部３０１は、受信したフレームがＢｌｏｃｋＡｃｋフレームを要求するデータフレームかを判定する（Ｓ１３０３）。これは、例えば、データフレームが含むＭＰＤＵの内、少なくとも１つ以上のＭＰＤＵ内のＱｏＳ Ｃｏｎｔｒｏｌフィールドに含まれるＡｃｋ ＰｏｌｉｃｙサブフィールドがＩｍｐｌｉｃｉｔ ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔ（“００”）に設定されているかどうかを確認することにより、判定可能である。“００”に設定されている場合、フレーム解析部３０１は、受信したフレームはＢｌｏｃｋＡｃｋフレームを要求するデータフレームと判定し（Ｓ１３０３でＹｅｓ）、処理はＳ１３０４へ進む。“００”に設定されてない場合、フレーム解析部３０１は、受信したフレームはＢｌｏｃｋＡｃｋフレームを要求するデータフレームでないと判定し、フレーム受信処理を終了する。Ｓ１３０４では、ＡＰ１０２はＢｌｏｃｋＡｃｋ（ＢＡ）フレーム生成・送信処理を行う。Ｓ１３０４の処理の詳細は、図１５を用いて後述する。

Ｓ１３０１で、受信したフレームがデータフレームでないと判定した場合（Ｓ１３０１でＮｏ）、フレーム解析部３０１は、受信したフレームがＢＡＲ（ＢｌｏｃｋＡｃｋ Ｒｅｑｕｅｓｔ）フレームかどうかを判定する（Ｓ１３０５）。例えば、データフレームにおける、前述のＴｙｐｅフィールドが“０１”であり、かつ、ＭＡＣヘッダ内のＦｒａｍｅ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ中のＳｕｂｔｙｐｅフィールドが“１０００”である場合に、ＢＡＲフレームと特定できる。フレーム解析部３０１は、受信したフレームがＢＡＲフレームと判定した場合は（Ｓ１３０５でＹｅｓ）、処理はＳ１３０４へ進み、ＳＴＡ１０３は、ＢＡフレーム生成・送信処理を実行する。ＢＡＲフレームには、データの開始番号に関する情報が含まれ得る。Ｓ１３０５で、受信したフレームがＢＡＲフレームでないと判定した場合は（Ｓ１３０５でＮｏ）、ＳＴＡ１０３は、ＩＥＥＥ８０２．１１規格準拠の各種フレームに対応する処理を実行し（Ｓ１３０６）、処理を終了する。Ｓ１３０６の処理については、本実施形態との関連が低いため、説明を割愛する。

（データフレームのシーケンス番号確認処理）
次に、図１４を用いてＳ１３０２のデータフレームのシーケンス番号の確認処理について説明する。図１４はデータフレームのシーケンス番号確認処理のフローチャートである。なお、データフレーム（ＭＰＤＵ）のシーケンス番号は、ＩＥＥＥ８０２．１１規格で規定されるＭＡＣフレームフォーマット内のＭＡＣヘッダに含まれるＳｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌフィールド内のＳｅｑｕｅｎｃｅ Ｎｕｍｂｅｒによって示され、０～４０９５の範囲の値を持つ。接続管理部３０３は、無線接続が確立した段階（図４の例ではＦ４０１）で、当該接続に関する受信シーケンス番号（受信済みのデータフレームのシーケンス番号）の管理を開始する。管理の開始時点では、すべてのシーケンス番号０～４０９５が未受信シーケンス番号（受信済みとして記録されていないデータフレームのシーケンス番号）として、記憶部２０１に記録される。

ＳＴＡ１０３の接続管理部３０３は、データフレーム（ＭＰＤＵ）のシーケンス番号が未受信シーケンス番号かを確認する（Ｓ１４０１）。すなわち、接続管理部３０３は、受信したデータフレームシーケンス番号の情報を、記憶部２０１に記録されている受信シーケンス番号と照合し、受信したデータフレームのシーケンス番号が未受信シーケンス番号かどうかを判定する。

受信したデータフレームのシーケンス番号が未受信シーケンス番号である場合（Ｓ１４０１でＹｅｓ）、接続管理部３０３は、当該シーケンス番号を受信シーケンス番号として新たに記憶部２０１に記録し（Ｓ１４０２）、終了する。一方、受信したデータフレームのシーケンス番号が受信シーケンス番号である場合（Ｓ１４０１でＮｏ）、受信したデータフレームは既に受信済みであり、重複フレームとみなして、当該データフレームを破棄し（Ｓ１４０３）、終了する。

（ＢＡフレーム生成・送信処理）
次に、図１５を用いてＳ１３０４のＢｌｏｃｋＡｃｋ（ＢＡ）フレーム生成・送信処理について説明する。図１５は、ＢＡフレーム生成・送信処理のフローチャートである。なお、上述したように、ＳＴＡ１０３とＡＰ１０２それぞれの接続管理部３０３は、通信相手装置のサポートするＢＡ Ｔｙｐｅ（本実施形態によるＮｅｗ ＢＡ Ｔｙｐｅも含みうる）や、ＢＡセッションにおけるＳｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ等の情報を記憶部２０１に記録し、管理しているものとする。また、フレームの生成に関し、図５を参照する。

ＳＴＡ１０３の接続管理部３０３は、接続のサポートする（自装置とＡＰ１０２のサポートする）ＢＡ Ｔｙｐｅを確認する（Ｓ１５０１）。ここで確認したＢＡ Ｔｙｐｅのサポート状況に応じて、フレーム生成部３０２は、Ｓ１５０４、Ｓ１５０５で生成するＢｌｏｃｋＡｃｋフレームの内容を決定することができる。次に、ＳＴＡ１０３の接続管理部３０３は、ＢＡセッションにおけるＳｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒを確認する（Ｓ１５０２）。前述したように、Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ ＮｕｍｂｅｒはＢｌｏｃｋＡｃｋ Ａｇｒｅｅｍｅｎｔ構築時に初期値が決定され、ＩＥＥＥ８０２．１１規格規定の方法に従ってその後更新されうる。続いて、接続管理部３０３は、受信シーケンス番号（受信済みとして記録されたシーケンス番号）の確認を行う（Ｓ１５０３）。

フレーム生成部３０２は、Ｓ１００１～Ｓ１００３で確認された情報を用いて、Ｂｌｏｃｋ Ａｃｋフレームの生成を行う。まず、フレーム生成部３０２は、ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３におけるＡＣＫ Ｉｎｆｏサブフィールド５０６の構成を決定する（Ｓ１５０４）。ここで、フレーム生成部３０２は、Ｓ１５０１で確認されたサポートＢＡ Ｔｙｐｅに基づいて、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成を決定することができる。確認されたサポートＢＡ Ｔｙｐｅが、上記の構成例１～６のいずれかの構成をサポートすることを示す場合、フレーム生成部３０２は、ＡＣＫ Ｉｎｆｏサブフィールド５０６の構成として当該構成例１～７のいずれかを使用することを決定することができる。なお、上記の構成例１～７のいずれかの構成を使用することは、予めＳＴＡ１０３に固定的に設定されていてもよいし、入力部２０４を介したユーザによる入力操作により、設定（決定）されてもよい。また、フレーム生成部３０２は、Ｓ１００３で確認されたシーケンス番号の受信状況に応じて。最も小さなデータサイズでＡＣＫ Ｉｎｆｏサブフィールド５０６を構成するように構成例１～７のいずれかを使用することを決定してもよい。

次に、フレーム生成部３０２は、Ｓ１５０４で決定したＡＣＫ Ｉｎｆｏサブフィールド５０６の構成に従って、また、当該構成を特定（指定）するように、ＢＡ Ｃｏｎｔｒｏｌフィールド５０２とＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３を生成する（Ｓ１５０５）。前述したように、ＡＣＫ Ｉｎｆｏサブフィールド５０６に構成例１～７のいずれかを使用することを、ＢＡ Ｃｏｎｔｒｏｌフィールド５０２／ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３における各種サブフィールドで指定することができる。

続いてフレーム生成部３０２は、図５（ａ）記載のＭＡＣ ｈｅａｄｅｒフィールド５０１、ＦＳＣフィールドを生成しＭＡＣフレームとして完成させ、ＰＨＹ部も生成してＢｌｏｃｋＡｃｋフレームを完成させる（Ｓ１５０６）。最後に、フレーム送受信部３０４は、フレーム生成部３０２により生成されたＢｌｏｃｋＡｃｋフレームを通信相手装置（ＡＰ１０２）へ送信する（Ｓ１５０７）。

送信したフレームの確認応答や、確認応答を一定時間受信しなかった際の再送処理は、ＩＥＥＥ８０２．１１規格の規定に従って実行される。ＳＴＡ１０３は。ＢｌｏｃｋＡｃｋフレームを正しく送信し、ＡＰ１０２から確認応答を受信した場合、受信済みの記録をリセットする、例えば、ＳＴＡ１０３の接続管理部３０３は、管理している受信シーケンス番号のうち、当該ＢｌｏｃｋＡｃｋフレームで通知が完了したシーケンス番号については、受信済みの記録をリセットする。これにより、シーケンス番号が一周した際にシーケンス番号の管理が可能となる。

（構成例７によるＢＡフレーム）
構成例７によるＢＡフレームの例と該フレームを用いた処理例について説明する。なお、図４のようにデータフレーム送信側の装置がＡＰ１０２である場合を例に説明するが、本説明は、ＳＴＡ１０３が動作主体である場合にも同様に適用可能である。また、フレームの生成に関し、図５を参照する。

ＳＴＡ１０３は、ＡＰ１０２から送信されたデータフレームのシーケンス番号をＢＡＲフレームにおけるＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎ（ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に設定される情報）によって取得することができる。ＳＴＡ１０３は、当該送信されたデータフレームのシーケンス番号を、ＡＣＫ Ｉｎｆｏサブフィールド５０６の中にＢｌｏｃｋＡｃｋＢｉｔｍａｐで表現する各ビットとシーケンス番号の対応付けに利用することで、Ｂｉｔｍａｐのビットを効率的に使用することができる。

ＢＡ Ｉｎｆｏｒｍａｔｉｏｎ（ＢＡ Ｉｎｆｏｒｍａｔｉｏｎフィールド５０３に設定される情報）は、構成例７に関して上述したように、Ｆｒａｇｍｅｎｔ Ｎｕｍｂｅｒ（４ビット）、Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ（１２ビット）、Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐ（８もしくは３２バイト）を格納する。Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐのサイズ、一度に表現できるＭＳＤＵ／Ａ－ＭＳＤＵの最大数は、Ｆｒａｇｍｅｎｔ Ｎｕｍｂｅｒの値に応じて定められ、８０２．１１ａｘ規格に準ずる。Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒは、ＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎ中に提示された、ＡＰ（通信相手装置）が送信したフレームの開始シーケンス番号を示す値が設定される。以降のフレームについては、ＡＰ１０２がＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎによって送信済みと提示したシーケンス番号のみついて、Ｂｌｏｃｋ Ａｃｋ Ｂｉｔｍａｐの各ビットを対応付けて送信済みか否かを表現する。ビットが１に設定されているフレームは送信済み、ビットが０に設定されているフレームは送信していないと判定することができる。０、１の意味合いは逆でも良い。

具体例として、例えばＡＰ１０２がシーケンス番号１、３、５を送信したとＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎによって提示し、ＳＴＡ１０３はシーケンス番号３番のみ受信できていない例を想定する。この場合、ＳＴＡ０３がＢｌｏｃｋＡｃｋフレームに含めるＢＡ Ｉｎｆｏｒｍａｔｉｏｎにおいて、ＳｔａｒｔｉｎｇＳｅｑｕｅｎｃｅＮｕｍｂｅｒを１、ＦｒａｇｍｅｎｔＮｕｂｅｒを０に設定し、ＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐ長を最小の８バイトに設定する。ＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐでは、１ビット目がシーケンス番号１、２ビット目がシーケンス番号３、３ビット目がシーケンス番号５に対応する。それ以降のビットは使用されないが、未受信として０が設定され得る。本例では、シーケンス番号１、５が受信成功、３が受信失敗なので、ＢｌｏｃｋＡｃｋ Ｂｉｔｍａｐとして“１０１”の内容を含むＢｌｏｃｋＡｃｋフレームがＳＴＡ１０３からＡＰ１０２へ送信される。ＡＰ１０２は当該ＢｌｏｃｋＡｃｋフレームを受信し、自身が送信したＢＡＲ Ｉｎｆｏｒｍａｔｉｏｎと照らし合わせることで、各ビットが対応づくフレームを特定できる。この例の場合、シーケンス番号３は送信失敗とみなし、再送処理される。

送信したフレームの確認応答や、確認応答を一定時間受信しなかった際の再送処理は、ＩＥＥＥ８０２．１１規格の規定に従って実行される。ＳＴＡ１０３は。ＢｌｏｃｋＡｃｋフレームを正しく送信し、ＡＰ１０２から確認応答を受信した場合、受信済みの記録をリセットする、例えば、ＳＴＡ１０３の接続管理部３０３は、管理している受信シーケンス番号のうち、当該ＢｌｏｃｋＡｃｋフレームで通知が完了したシーケンス番号については、受信済みの記録をリセットする。これにより、シーケンス番号が一周した際にシーケンス番号の管理が可能となる。

図８～図１５に示す処理のフローは本提案を実現する一例であり、同じ機能を果たすものであれば各処理の順番は限定されない。また、この処理フローに記載されていない処理についてはＩＥＥＥ８０２．１１規格規定の処理に従う。

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

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

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

Claims (37)

1. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
   複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
   前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
   前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
   前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
   前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
2. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
   複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
   前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
   前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
   前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
3. 前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報を含むことを特徴とする請求項１または２に記載の通信装置。
4. 前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項１または２に記載の通信装置。
5. 前記特定情報は、前記各リンクで送信した各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを含むことを特徴とする請求項１または２に記載の通信装置。
6. 前記シーケンス情報は、前記各リンクで送信した前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
7. 前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項６に記載の通信装置。
8. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
   複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
   前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
   前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
   前記要求フレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
   前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
9. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
   複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
   前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
   前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
   前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする通信装置。
10. 前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含め、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項８または９に記載の通信装置。
11. 前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項８または９に記載の通信装置。
12. 前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信していない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含むことを特徴とする請求項８または９に記載の通信装置。
13. 前記シーケンス情報は、前記各リンクで送信していない前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項８から１２のいずれか１項に記載の通信装置。
14. 前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項１３に記載の通信装置。
15. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信手段と、
    前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信手段と、
    前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信したデータフレームのシーケンス番号を識別する情報とを含むことを特徴とする通信装置。
16. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    前記シーケンス情報は、前記各リンクで送信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレーム群に含まれるデータフレームに対する受信結果を含む、通信装置。
17. 前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報を含むことを特徴とする請求項１６に記載の通信装置。
18. 前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項１６に記載の通信装置。
19. 前記特定情報は、前記各リンクで送信された各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを含むことを特徴とする請求項１６に記載の通信装置。
20. 前記シーケンス情報は、前記各リンクで送信した前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項１６から１９のいずれか１項に記載の通信装置。
21. 前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項２０に記載の通信装置。
22. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信されていない複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    前記シーケンス情報は、前記各リンクで送信されていない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、通信装置。
23. 前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項２２に記載の通信装置。
24. 前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含むことを特徴とする請求項２２に記載の通信装置。
25. 前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの情報として、前記送信した複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含み、前記特定情報は、前記各リンクで送信されていない各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含むことを特徴とする請求項２２に記載の通信装置。
26. 前記シーケンス情報は、前記各リンクで送信されていない前記１つ以上のデータフレーム群の終了を示す情報を含むことを特徴とする請求項２２から２５のいずれか１項に記載の通信装置。
27. 前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項２６に記載の通信装置。
28. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信手段と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信手段と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信手段と、を有し、
    前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信されたデータフレームのシーケンス番号を識別する情報とを含み、
    前記Ａｃｋフレームは、前記シーケンス情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、通信装置。
29. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
30. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信手段であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信手段と、
    前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信手段と、を有し、
    前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
31. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    前記要求フレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
32. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する送信工程であって、前記複数のデータフレームの少なくとも一つのデータフレームは、前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求情報を含む、送信工程と、
    前記要求情報を送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    前記少なくとも一つのデータフレームは、前記複数のリンクの各リンクで送信していない複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの情報と、前記各リンクで送信していない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含むことを特徴とする制御方法。
33. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    複数のリンクを用いて複数のデータフレームを通信相手装置へ送信する第１の送信工程と、
    前記送信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを要求する要求フレームを前記通信相手装置に送信する第２の送信工程と、
    前記要求フレームを送信することに応答して前記通信相手装置から前記Ａｃｋフレームを受信する受信工程と、を有し、
    前記要求フレームは、前記複数のリンクの各リンクで送信した複数のデータフレームのシーケンス番号に関するシーケンス情報を含み、
    前記シーケンス情報は、前記各リンクで送信した複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信したデータフレームのシーケンス番号を識別する情報とを含むことを特徴とする制御方法。
34. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    前記シーケンス情報は、前記各リンクで送信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレーム群に含まれるデータフレームに対する受信結果を含む、制御方法。
35. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信されていない複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    前記シーケンス情報は、前記各リンクで送信されていない複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１以上のデータフレーム群を特定する特定情報を含み、
    前記Ａｃｋフレームは、前記特定情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、制御方法。
36. ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
    通信相手装置から、複数のリンクを用いて送信された複数のデータフレームを受信する第１の受信工程と、
    前記通信相手装置から、前記複数のリンクの各リンクで送信された複数のデータフレームのシーケンス番号に関するシーケンス情報を受信する第２の受信工程と、
    前記受信した複数のデータフレームに対する確認応答（Ａｃｋ）フレームを送信する送信工程と、を有し、
    前記シーケンス情報は、前記各リンクで送信された複数のデータフレームの開始シーケンス番号と、当該開始シーケンス番号を開始点として送信されたデータフレームのシーケンス番号を識別する情報とを含み、
    前記Ａｃｋフレームは、前記シーケンス情報により特定される、前記各リンクで送信された１以上のデータフレームに対する受信結果を含む、通信装置。
37. コンピュータを、請求項１から２８のいずれか１項に記載の通信装置として機能させるためのプログラム。

Images