JP2022068653A

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

Info

Publication number: JP2022068653A
Application number: JP2020177444A
Authority: JP
Inventors: 祐樹藤森; Yuki Fujimori
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2020-10-22
Filing date: 2020-10-22
Publication date: 2022-05-10
Also published as: US20230254089A1; WO2022085370A1

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

ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信手段と、
前記受信手段により受信された前記複数のデータフレームに対する確認応答（Ａｃｋ）フレームを生成する生成手段と、
前記生成手段により生成された前記Ａｃｋフレームを前記通信相手装置に送信する送信手段と、を有し、
前記生成手段は、前記Ａｃｋフレームに、前記受信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１つ以上のデータフレーム群を特定する特定情報を含めることを特徴とする通信装置。
前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを前記Ａｃｋフレームに含めることを特徴とする請求項１に記載の通信装置。
前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを前記Ａｃｋフレームに含めることを特徴とする請求項１に記載の通信装置。
前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを前記Ａｃｋフレームに含めることを特徴とする請求項１に記載の通信装置。
前記生成手段は、前記１つ以上のデータフレーム群の終了を示す情報を、前記Ａｃｋフレームに含めることを特徴とする請求項１から３のいずれか１項に記載の通信装置。
前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項５に記載の通信装置。
ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信手段と、
前記受信手段により受信された前記複数のデータフレームに対する確認応答（Ａｃｋ）フレームを生成する生成手段と、
前記生成手段により生成された前記Ａｃｋフレームを前記通信相手装置に送信する送信手段と、を有し、
前記生成手段は、前記Ａｃｋフレームに、前記受信された複数のデータフレームの情報と、前記受信手段により受信されなかった１つ以上のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１つ以上のデータフレーム群を特定する特定情報とを含めることを特徴とする通信装置。
前記生成手段は、前記Ａｃｋフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項７に記載の通信装置。
前記生成手段は、前記Ａｃｋフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含めることを特徴とする請求項７に記載の通信装置。
前記生成手段は、前記Ａｃｋフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含めることを特徴とする請求項７に記載の通信装置。
前記生成手段は、前記１つ以上のデータフレーム群の終了を示す情報を、前記Ａｃｋフレームに含めることを特徴とする請求項７から１０のいずれか１項に記載の通信装置。
前記１つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項１１に記載の通信装置。
前記Ａｃｋフレームは、生成手段により生成された前記Ａｃｋフレームの構成を示す情報を含むことを特徴とする請求項１から１２のいずれか１項に記載の通信装置。
ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信工程と、
前記受信工程において受信された前記複数のデータフレームに対する確認応答（Ａｃｋ）フレームを生成する生成工程と、
前記生成工程において生成された前記Ａｃｋフレームを前記通信相手装置に送信する送信工程と、を有し、
前記生成工程では、前記Ａｃｋフレームに、前記受信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１つ以上のデータフレーム群を特定する特定情報を含めることを特徴とする制御方法。
ＩＥＥＥ８０２．１１規格シリーズに準拠する通信装置の制御方法であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信工程と、
前記受信工程において受信された前記複数のデータフレームに対する確認応答（Ａｃｋ）フレームを生成する生成工程と、
前記生成工程において生成された前記Ａｃｋフレームを前記通信相手装置に送信する送信工程と、を有し、
前記生成工程では、前記Ａｃｋフレームに、前記受信された複数のデータフレームの情報と、前記受信工程において受信されなかった１つ以上のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した１つ以上のデータフレーム群を特定する特定情報とを含めることを特徴とする制御方法。
コンピュータを、請求項１から１３のいずれか１項に記載の通信装置として機能させるためのプログラム。