JP2019513308A - ブロック肯定応答送信のための通信方法及び通信装置 - Google Patents

Abstract

ブロック肯定応答（ブロックＡｃｋ）フレームを送信するための通信方法が与えられる。通信方法は、送信デバイスから複数のフレームを受信するステップであって、フレームのペイロードがフラグメントされるパケット又はフラグメント化されないパケットのいずれかから成る、ステップと、フレームの受信状態を記録するステップと、フレームの受信状態を示すために使用される少なくとも１つのビットマップフィールドを含むブロックＡｃｋフレームを生成するステップであって、パケットのためにビットマップフィールドで割り当てられるビット数が可変である、ステップと、ブロックＡｃｋフレームを送信するステップとを含む。

Description

本開示は、一般に、ブロック肯定応答送信のための通信装置及び通信方法に関する。

ＩＥＥＥ（電気電子技術者協会）８０２．１１ワーキンググループは、現在、８０２．１１ａｘタスクグループの下で次世代のＷＬＡＮ（ワイヤレスローカルエリアネットワーク）技術を標準化する過程にある。タスクグループの主な目標は、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）及び／又は端末ステーション（「非ＡＰ ＳＴＡ」又は本開示の残りにおいて単にＳＴＡ）の高密度シナリオでのシステムスループット／エリアを高めるためのスペクトル効率の向上である。ＩＥＥＥ８０２．１１ａｘ仕様に基づくデバイスは、一般に、高効率（ＨＥ）デバイスと称される。提案されている様々な技術の中で、ＩＥＥＥ８０２．１１ａｘタスクグループがスループット改善目標を達成するために採用した直交周波数分割多元接続（ＯＦＤＭＡ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ−Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）及びアップリンクマルチユーザ送信は、２つの重要な技術である。図１は、ＡＰ１９０及びＡＰ１９０に関連する幾つかのＳＴＡを伴う８０２．１１ａｘ ＷＬＡＮ１００の一例を示す。

特に低いデータ転送速度の状況で送信の信頼性を高めるために８０２．１１で使用される機能のうちの１つがフラグメンテーションと呼ばれる。フラグメンテーションは、ＭＡＣサービスデータユニット（ＭＳＤＵ：ＭＡＣ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）又はＭＡＣ管理プロトコルデータユニット（ＭＭＰＤＵ：ＭＡＣ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）をより小さいＭＡＣレベルフレーム、ＭＡＣプロトコルデータユニット（ＭＰＤＵ：ＭＡＣ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）に分割するプロセスである。簡潔にするために、残りの開示において、用語ＭＳＤＵは、ＭＳＤＵ及びＭＭＰＤＵの両方を表すために使用される。低いデータ転送速度では、フラグメント化されないＭＳＤＵは大量のエアタイムを占める可能性がある。フレーム内のビットエラーは、フレーム全体が再送される結果をもたらす。フラグメンテーションにより、ＭＳＤＵはより小さいセグメントに分割され、また、各セグメントは、ＭＰＤＵにカプセル化されて、別個のＰＬＣＰプロトコルデータユニット（ＰＰＤＵ：ＰＬＣＰ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）で送られる。これにより、エラーのあるセグメントを搬送するＭＰＤＵのみが再送される結果となる。受信部でＭＰＤＵを単一のＭＳＤＵ又はＭＭＰＤＵへと再結合する逆のプロセスは、デフラグメンテーションとして知られる。

８０２．１１ａｘでのＯＦＤＭＡ及びアップリンクマルチユーザ送信の導入により、フラグメンテーションは再び重要になってきた。これは、ダウンリンク（ＤＬ：Ｄｏｗｎｌｉｎｋ）及びアップリンク（ＵＬ：Ｕｐｌｉｎｋ）の両方において、８０２．１１ａｘが、マルチユーザ送信が同時に終了することを強制したという事実に起因する。利用可能な持続時間割当て（ＰＰＤＵ長）を満たすために正確な整数のＭＳＤＵが存在する可能性は低いため、任意の未使用の持続時間割当てにパディングを適用する代わりにＭＳＤＵのフラグメントを送信できることが８０２．１１ａｘワーキンググループで合意された。集約ＭＰＤＵ（Ａ−ＭＰＤＵ：Ａｇｇｒｅｇａｔｅ ＭＰＤＵ）内のフラグメンテーションをサポートするために、８０２．１１ａｘは、「専用」Ｃ−ＢＡフレームとも呼ばれる新たな圧縮ブロック肯定応答（Ｃ−ＢＡ：Ｃｏｍｐｒｅｓｓｅｄ Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）フレームバリアントを導入した。「専用」Ｃ−ＢＡフレームは、Ａ−ＭＰＤＵごとにＭＳＤＵの複数のフラグメントを確認できる。

ＩＥＥＥ８０２．１１−１５／０１３２ｒ１４，Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｆｏｒ ＴＧａｘ，Ｊａｎｕａｒｙ ２０１６ ＩＥＥＥ Ｓｔｄ ８０２．１１−２０１２ ＩＥＥＥ８０２．１１−１６／００５０ｒ１，Ｆｒａｇｍｅｎｔａｔｉｏｎ ｆｏｒ ＭＵ ｆｒａｍｅｓ−Ｆｏｌｌｏｗ ｕｐ ｏｎ ａｃｋｓ

「専用」Ｃ−ＢＡフレームがＡ−ＭＰＤＵで搬送されるＭＳＤＵ又はＭＭＰＤＵの複数のフラグメントを確認できる場合であっても、「専用」Ｃ−ＢＡフレームのＢＡビットマップ内のビットの多くは、Ａ−ＭＰＤＵのＭＰＤＵのうちの僅かだけがフラグメント化されたＭＳＤＵを搬送するときに使用されないままである。

本開示の１つの非限定的で典型的な実施形態は、ブロックＡｃｋフレームの効率を高めることができる装置及び方法を提供することを容易にする。

１つの一般的な態様において、本明細書に開示される技術は、送信デバイスから複数のフレームを受信するステップであって、フレームのペイロードがフラグメントされるパケット又はフラグメント化されないパケットのいずれかから成る、ステップと、フレームの受信状態を記録するステップと、フレームの受信状態を示すために使用される少なくとも１つのビットマップフィールドを含むブロックＡｃｋフレームを生成するステップであって、パケットのためにビットマップフィールドで割り当てられるビット数が可変である、ステップと、ブロックＡｃｋフレームを送信するステップとを備える通信方法を特徴とする。

これらの一般的で特定の態様は、デバイス、システム、方法、及び、コンピュータプログラム、並びに、デバイス、システム、方法、及び、コンピュータプログラムの任意の組み合わせを使用して実施されてもよい。

本開示に記載される装置及び方法は、ブロックＡｃｋフレームの効率を高める。

開示された実施形態の更なる利益及び利点は、明細書及び図面から明らかになる。利益及び／又は利点は、そのような利益及び／又は利点の１つ以上を得るために全て提供される必要はなく、明細書及び図面の様々な実施形態及び特徴によって個別に得られてもよい。

効率的なブロック肯定応答を利用するシステムの特定の実施形態の図である。 ブロックＡｃｋメカニズムのセットアップ及びティアダウンを含むフレーム交換シーケンスの一例の図である。 ８０２．１１ａｘにおけるフラグメンテーションの使用を強調するアップリンクマルチユーザフレーム交換シーケンスの図である。 ８０２．１１ａｘで導入される「専用」Ｃ−ＢＡフレームのフレーム構造の図である。 本開示によって扱われる技術的課題を強調するダウンリンクマルチユーザフレーム交換シーケンスの図である。 第１の実施形態によるシーケンス制御フィールドの構造の図である。 第１の実施形態によるＢＡ情報フィールドの構造の図である。 フラグメント数フィールドの符号化のための符号化テーブルの図である。 第１の実施形態による受信局によって管理されるフラグメントサイズテーブルの図である。 第１の実施形態によるＭＰＤＵの受信状態を記録するために使用されるスコアボードビットマップの図である。 第１の実施形態によるＢＡビットマップの一例の図である。 第１の実施形態による送信局によって管理される送信ウィンドウの図である。 第１の実施形態による送信局によって管理されるフラグメントサイズテーブルの図である。 ＭＳＤＵ全体が受信されないときのシナリオを示す、第１の実施形態によるＢＡビットマップの一例の図である。 第１の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の中央部分である。 第１の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の左側部分である。 第１の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の右側部分である。 第２の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の中央部分である。 第２の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の左側部分である。 第２の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の右側部分である。 第３の実施形態によるＡｄｄブロック肯定応答（ＡＤＤＢＡ：Ａｄｄ Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）拡張要素の図である。 ＡＤＤＢＡ能力フィールドの図である。 単一ＭＳＤＵ当たりの最大フラグメントフィールドの符号化テーブルの図である。 第３の実施形態によるＭＰＤＵの受信状態を記録するために使用されるスコアボードビットマップの図である。 第３の実施形態によるスコアボードビットマップ符号化方式の図である。 第３の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図である。 第３の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の中央部分である。 第３の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の左側部分である。 第３の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の右側部分である。 第４の実施形態によるフラグメント数フィールドを搬送するために使用されるＨＥバリアントＨＴ制御フィールドの構造の図である。 第４の実施形態によるフラグメント数フィールドを搬送するために使用されるＨＥバリアントＨＴ制御フィールドの構造の他の図である。 第５の実施形態にしたがって使用されるＢＡビットマップ符号化の一例の図である。 第５の実施形態にしたがって使用されるＢＡビットマップ符号化の他の例の図である。 第５の実施形態にしたがって使用されるＢＡビットマップ符号化の他の例の図である。 第５の実施形態によるＭＰＤＵの受信状態を記録するために使用されるスコアボードビットマップの図である。 第５の実施形態によるＭＰＤＵの受信状態を記録するために使用されるＢＡビットマップの図である。 第５の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の中央部分である。 第５の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の左側部分である。 第５の実施形態によるブロック肯定応答メカニズムを強調するフレーム交換シーケンスの一例の図の右側部分である。 本開示で導入される効率的なブロック肯定応答メカニズムを達成するために、発信側によって実行される動作のフローチャートである。 本開示で導入される効率的なブロック肯定応答メカニズムを達成するために受信側によって実行される動作のフローチャートである。 発信側の一例のブロック図である。 発信側の一例の詳細なブロック図である。 発信側の送信モジュールのブロック図である。 受信側の一例のブロック図である。 受信側の一例の詳細なブロック図である。 受信側の受信モジュールのブロック図である。

本開示は、以下の図及び実施形態の助けによってより良く理解できる。本明細書に記載される実施形態は、本質的に単なる典型例にすぎず、本開示の想定し得る用途及び使用の幾つかを説明するために使用され、本明細書中に明示的に記載されない別の実施形態に関して本開示を限定するように解釈されるべきでない。

ブロック肯定応答メカニズムは８０２．１１ｅ改正で導入された。ブロック肯定応答メカニズムは、個々のデータフレームのＡＣＫ／ＮＡＣＫをそれぞれが示すＡＣＫフレームのグループではなく単一のブロック肯定応答（ブロックＡｃｋ又はＢＡ：Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）フレームにより確認されるフレームのブロックの転送を可能にする。ブロックＡｃｋフレームには様々な種類がある。当初のブロックＡｃｋフレームは、１０２４ビットのＢＡビットマップを含む基本ブロックＡｃｋバリアントとして知られ、６４個のＭＳＤＵを確認でき、それぞれのＭＳＤＵは最大１６個のフラグメントによりフラグメント化され得る。しかしながら、より高いデータ転送速度では、フラグメンテーションが大きなメリットをもたらさず、８０２．１１ｎは基本ブロックＡｃｋを廃止して圧縮されたブロックＡｃｋバリアントを導入した。圧縮されたブロックＡｃｋバリアントは、フラグメンテーションに関して単一ＭＳＤＵ当たり１６ビットを排除し、それにより、６４ビットＢＡビットマップをもたらす。このため、８０２．１１ｎ及び８０２．１１ａｃは、フラグメント化されたＭＳＤＵ又はＭＭＰＤＵを運ぶＭＰＤＵを集約ＭＡＣプロトコルデータユニット（Ａ−ＭＰＤＵ）で搬送できるようにしない。

フラグメンテーションに関して、８０２．１１ａｘワーキンググループは、様々なデバイス能力に応じるために、以下の４つのタイプ（レベル）のフラグメンテーションを導入した。
−レベル０：フラグメントのサポートなし
−レベル１：「ＶＨＴ」単一ＭＰＤＵのみでのフラグメントのサポート
−レベル２：Ａ−ＭＰＤＵにおける単一ＭＳＤＵ当たり最大１つのフラグメントのサポート
−レベル３：単一Ａ−ＭＰＤＵ当たりＭＳＤＵの複数のフラグメントのサポート
従来のブロックＡｃｋメカニズムは、レベル０、レベル１及びレベル２のフラグメンテーションをサポートできるが、レベル３のフラグメンテーションをサポートできない。前述のレベル３のフラグメンテーションをサポートするために、「専用」Ｃ−ＢＡフレームとも呼ばれる圧縮ブロック肯定応答（Ｃ−ＢＡ：Ｃｏｍｐｒｅｓｓｅｄ Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）バリアントが８０２．１１ａｘに導入された。

図２は、２つの８０２．１１デバイス間のフレーム交換のシーケンス２００の一例を示し、このシーケンスは、ＨＴ即時ブロックＡｃｋ合意を設定し破棄するための管理フレームの交換を伴う。インフラストラクチャ基本サービスセット（ＢＳＳ：Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）では、８０２．１１デバイスのうちの１つがＡＰであり、もう１つがＳＴＡである。シーケンス２００は、３つの別個の段階、すなわち、（ａ）ブロックＡｃｋセットアップ段階２１０と、（ｂ）１つ以上のデータ交換段階２２０と、（ｃ）ブロックＡｃｋティアダウン段階２３０とから成る。ブロックＡｃｋプロトコルとの関連で、２２０に示されるバースト送信を開始する８０２．１１デバイスは発信側として知られ、一方、バースト送信を受信してブロックＡｃｋフレームを準備する受信８０２．１１デバイスは受信側として知られている。他の開示において、発信側及び受信側という用語は、特に、ブロックＡｃｋプロトコルとの関連で使用される。それぞれの個々のブロックＡｃｋ合意は、発信側としての役割を果たす１つの無線デバイスと、受信側としての役割を果たす他の無線デバイスとを有する。ＡＰ及びＳＴＡはいずれも、発信側又は受信側のいずれかとしての役割を果たし得る。

更に、無線デバイスは、１つのブロックＡｃｋ合意のための発信側としての役割を果たしてもよく、同時に、このデバイスは、異なるブロックＡｃｋ合意のための受信側としての役割を果たしてもよい。ブロックＡｃｋメカニズムを使用できる前に、発信側及び受信側はいずれも付加的なリソースを準備する必要がある。受信側は、フレームのバーストを受信するために付加的なバッファを割り当てる必要があるだけでなく、各フレームの受信状態を記録するためにスコアボードを管理する必要もある。同様に、発信側は、送信されるフレームの記録を管理する必要もある。この準備はブロックＡｃｋセットアップ段階２１０で行われる。この段階において、２つの８０２．１１デバイスは、バッファサイズ、関連するフレームのトラフィック識別子（ＴＩＤ：Ｔｒａｆｆｉｃ Ｉｄｅｎｔｉｆｉｅｒ）、ネゴシエーションが有効になる期間などをネゴシエートできる。データ交換段階２２０が完了された時点で、いずれかの当事者がティアダウン段階２３０でブロックＡｃｋ合意を破棄してもよい。レベル３のフラグメンテーションは、レベル３のフラグメンテーションを含むブロックＡｃｋ合意のセットアップ段階中及びティアダウン段階中に付加的なリソースを必要とするため、レガシーブロックＡｃｋアクションフレーム（Ａｄｄ ＢｌｏｃｋＡｃｋｎｏｗｌｅｄｇｍｅｎｔ（ＡＤＤＢＡ）要求、ＡＤＤＢＡ応答、及び、削除ブロック肯定応答（ＤＥＬＢＡ：Ｄｅｌｅｔｅ Ｂｌｏｃｋ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）は、ブロックＡｃｋ合意がレベル３のフラグメンテーションを含むことを示すようにカスタマイズされてもよく、或いは、レベル３のフラグメンテーションを含むブロックＡｃｋ合意を要求する、応答する、及び、削除するために新たなブロックＡｃｋアクションフレームが規定されてもよい。ブロックＡｃｋアクションフィールドと呼ばれる１オクテットフィールドが様々なタイプのブロックＡｃｋアクションフレームを区別するために使用される。ＡＤＤＢＡ要求、ＡＤＤＢＡ応答、及び、ＤＥＬＢＡをそれぞれ示すためにブロックＡｃｋアクションフィールド値０、１、２が使用される。レガシーブロックＡｃｋアクションフレームから区別するために、３、４、５のブロックＡｃｋアクションフィールド値を使用して、レベル３ ＡＤＤＢＡ要求、ＡＤＤＢＡ応答、及び、ＤＥＬＢＡのための新たなブロックＡｃｋアクションフレームをそれぞれ規定してもよい。

図３は、アップリンクマルチユーザフレーム交換シーケンス３００を示す。アップリンクマルチユーザフレーム交換は、トリガーフレームと呼ばれる新たに規定される制御フレームを送信することによってＡＰにより開始される。トリガーフレーム３１０は、ＵＬ送信に使用されるべきリソースユニット（ＲＵ：Ｒｅｓｏｕｒｃｅ Ｕｎｉｔ）割り当て、持続時間割当て（ＰＰＤＵ長）、ＭＣＳ等に関する情報を含む。トリガーフレーム３１０を受信すると、トリガーフレーム３１０によってＲＵが割り当てられるＳＴＡは、ＵＬマルチユーザＰＰＤＵ３２０内のそれぞれのＵＬフレームを返送することができる。８０２．１１ａｘは、ＵＬマルチユーザ送信に関与する全てのＳＴＡがそれぞれの送信を同時に開始するとともに送信を同時に終了しなければならないことを義務付ける。利用可能な持続時間割当て（ＰＰＤＵ長）を満たすためにＳＴＡが常に正確な整数のＭＳＤＵを有している見込みはないため、任意の未使用の持続時間割当てにパディングを適用する代わりにＭＳＤＵのフラグメントの送信がトリガーフレーム３１０によって規定される時間で終了するようにＭＳＤＵのフラグメントが送信されてもよいことが８０２．１１ａｘで合意された。ＵＬマルチユーザＰＰＤＵ３２０において、ＳＴＡ２は、いつでも送信できる状態にあって持続時間割当てに正確に適合する必要な数の整数のＭＳＤＵをたまたま有する。しかしながら、ＳＴＡ１及びＳＴＡ３は、持続時間割当て（ＰＰＤＵ長）を満たすためにフラグメンテーションを適用する必要があり、ＭＳＤＵフラグメント３２２、３２４をそれぞれそれらのそれぞれのＵＬ ＰＰＤＵの最終フレームとして送信する。ＡＰは、ＤＬ ＭＵＰＰＤＵ３３０においてそれぞれのブロックＡｃｋを送信することによってフレーム交換を終了する。

図４は、単一Ａ−ＭＰＤＵ当たりのＭＳＤＵの複数のフラグメントを確認するために８０２．１１ａｘに導入された「専用」Ｃ−ＢＡフレーム４００の構造を示す。「専用」Ｃ−ＢＡフレーム４００は、他のブロックＡｃｋフレームの構造と同じ構造を共有し、フレームコントロールフィールド４１０、持続時間フィールド４２０、受信部アドレス（ＲＡ：Ｒｅｃｅｉｖｅｒ Ａｄｄｒｅｓｓ）フィールド４３０、送信部アドレス（ＴＡ：Ｔｒａｎｓｍｉｔｔｅｒ Ａｄｄｒｅｓｓ）フィールド４４０、ＢＡ制御フィールド４５０、ＢＡ情報フィールド４６０、及び、フレームチェックシーケンス（ＦＣＳ：Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）フィールド４９０から形成される。ＢＡ情報フィールド４６０は、ＢＡ開始シーケンス制御フィールド４７０とＢＡビットマップフィールド４８０とから更に構成される。ＢＡ開始シーケンス制御フィールド４７０は、フラグメント番号サブフィールド４７２と開始シーケンス番号（ＳＳＮ：Ｓｔａｒｔｉｎｇ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）サブフィールド４７４とに分けられる。「専用」Ｃ−ＢＡフレームは、フラグメント番号サブフィールド４７２を０に設定する代わりに、「専用」Ｃ−ＢＡフレームによって確認され得る単一ＭＳＤＵ当たりのフラグメントの最大数を示すゼロでない値Ｘ（Ｘは１よりも大きい整数である）にフラグメント番号サブフィールド４７２が設定されるという点において他のブロックＡｃｋフレームとは異なる。

加えて、ＢＡビットマップフィールド４８０は、ＢＡビットマップ４８０内の各ビットが単一のＭＳＤＵ又はＭＳＤＵのフラグメントの受信の成功を確認するように６４／Ｘ個のブロックに分割され、この場合、ＢＡビットマップの最初のＸ個のビットは、開始シーケンス番号（ＳＳＮ）サブフィールド４７４の値と一致するシーケンス番号（ＳＮ：Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）を有するＭＳＤＵに対応する。ＭＳＤＵの未使用フラグメント数に関しては、ＢＡビットマップ４８０内の対応するビットが初期設定で０に設定される。８０２．１１ａｘでは、Ｘの値が４として合意されており、このことは、「専用」Ｃ−ＢＡフレーム４００が最大１６個のＭＳＤＵしか確認できないことを意味する。加えて、ＢＡビットマップ４８０はそれぞれが４ビットの１６個のブロックに静的に分けられるため、多くのフラグメント化されたＭＳＤＵが存在しない場合にＢＡビットマップビットの多くが未使用のままであることが想定し得る。最悪の場合のシナリオでは、１つのＭＳＤＵのみがフラグメント化されると仮定すると、１つのブロックだけがＭＳＤＵフラグメントを確認するために使用される複数のビットを有し、一方、使用されていない利用可能なＢＡビットマップビットの約７０％に相当する４５ビットをもたらすブロックの残りでは最初のビットのみが使用される。

図５は、前述の想定し得る問題を強調するダウンリンクマルチユーザフレーム交換５００の一例を示す。ＡＰは、それぞれ割り当てられたＲＵにおいてＳＴＡ１、ＳＴＡ２、ＳＴＡ３のためのＡ−ＭＰＤＵを搬送するＤＬ ＭＵ ＰＰＤＵ５１０を送信することによってフレーム交換を開始する。持続時間割当て（ＰＰＤＵ長）を満たすために、ＡＰは３つのＡ−ＭＰＤＵのそれぞれにおいて最後のＭＳＤＵをフラグメント化する。各Ａ−ＭＰＤＵは単一のＭＳＤＵフラグメントのみを搬送するため、これはレベル２のフラグメンテーションと見なされ、また、ＳＴＡは、ＵＬ ＭＵ ＰＰＤＵ５２０において圧縮ブロックＡｃｋをそれぞれ送信することによってフレームの受信の成功を確認する。ＡＰは、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３にそれぞれアドレス指定されるＡ−ＭＰＤＵ５３２、５３４、５３６を搬送する第２のＤＬ ＭＵ ＰＰＤＵ５３０を送信することによってフレーム交換を継続する。フラグメントの比較的大きいサイズに起因して、Ａ−ＭＰＤＵ５３２は４つのＭＰＤＵのみを搬送し、そのうちの３つがＭＳＤＵ＃３の最後の３つのフラグメントであり、一方、最後のＭＰＤＵはＭＳＤＵ＃４の最初のフラグメントを搬送する。Ａ−ＭＰＤＵ５３４に関しては、比較的小さなサイズのＭＳＤＵに起因して、１８個のＭＰＤＵを受け入れることができる。実際に、この場合、Ａ−ＭＰＤＵ５３４で搬送され得るＭＰＤＵの数は、持続時間割当の欠如に起因するのではなくむしろ「専用」Ｃ−ＢＡフレームが１６個の連続するＭＳＤＵしか確認できないという事実に起因して１８個に制限される。したがって、フラグメンテーションを使用するにもかかわらず、Ａ−ＭＰＤＵ５３４は、ＰＰＤＵ終了時刻と一致するべくパディング５３７を必要とする。Ａ−ＭＰＤＵ５３６に関しては、残りの持続時間がフラグメントのために許容される最小サイズよりも小さく、そのため、パディング５３８が適用されなければならないという事実に起因して、３つのＭＰＤＵしか受け入れることができない。最後に、フレームシーケンスは、ＳＴＡがそれぞれＵＬ ＭＵ ＰＰＤＵ５４０における対応する「専用」Ｃ−ＢＡフレームを送信することによって終了する。

上記の知見に基づき、この出願の発明者らは、本開示に到達した。この開示の方法は、フラグメント化されたＭＳＤＵを搬送するＭＰＤＵから構成されるＡ−ＭＰＤＵを確認するためにより効率的なブロックＡｃｋメカニズムを提供する。開示された方法によれば、ブロックＡｃｋのＢＡビットマップは、受信されたＭＰＤＵの受信状態をより一層効率的な態様で記録することができる。結果として、受信側デバイスは、従来技術と比べて数倍多くの所定のＢＡビットマップサイズのＭＳＤＵを確認することができる。その結果、発信側デバイスは、拡張されたシーケンス番号空間に起因して単一のＡ−ＭＰＤＵ内により多くのＭＳＤＵを詰め込むことができる。
以下の節では、本開示で提案される効率的なブロックＡｃｋメカニズムのための様々な実施形態について詳しく説明する。

＜第１の実施形態＞
先に言及されたように、８０２．１１ａｘは、フラグメント化されたＭＳＤＵをＡ−ＭＰＤＵに集約できるようにすることに合意した。しかしながら、フラグメンテーションのサポートは、デバイスが付加的な能力を有することを要する。８０２．１１ａｘは、多様な能力を持つデバイスをサポートすることが期待されるため、一部のデバイスが所要の能力を有する一方で、他のデバイスがそのような能力を有さなくてもよい。様々なデバイス能力に応じるため、８０２．１１ａｘは以下の４つのフラグメンテーションタイプ（レベル）を導入した。
−レベル０：フラグメントのサポートなし発信側は、フラグメント化されたＭＳＤＵを集約しなくてもよい。
−レベル１：「ＶＨＴ」単一ＭＰＤＵのみでのフラグメントのサポート発信側は、ＭＳＤＵの多くても１つのフラグメントを「ＶＨＴ」単一ＭＰＤＵに集約してもよく、受信側者はＡｃｋで応答する。
−レベル２：Ａ−ＭＰＤＵにおける単一ＭＳＤＵ当たり最大１つのフラグメントのサポート発信側は、単一ＭＳＤＵ当たり最大１つのフラグメントをＡ−ＭＰＤＵに集約してもよく、受信側は、他に圧縮ＢＡ（Ｃ−ＢＡ）を伴うＡｃｋ（「ＶＨＴ」単一ＭＰＤＵの場合）で応答する。
−レベル３：単一Ａ−ＭＰＤＵ当たりＭＳＤＵの複数のフラグメントのサポート発信側は、単一ＭＳＤＵ当たり複数のフラグメントをＡ−ＭＰＤＵに集約してもよく、また、受信側は、他に「専用」Ｃ−ＢＡを伴う場合には、Ａｃｋ（「ＶＨＴ」単一ＭＰＤＵの場合）で又はＣ−ＢＡ（Ａ−ＭＰＤＵが単一ＭＳＤＵ当たり最大で１つのフラグメントを伴う場合）で応答する。

「専用」Ｃ−ＢＡフレームによって確認され得る単一ＭＳＤＵ当たりのフラグメントの最大数が４であり、その結果、レベル３のフラグメンテーションにおける単一Ａ−ＭＰＤＵ当たりのＭＳＤＵのフラグメント数が４に等しいことが８０２．１１ａｘにおいて更に合意された。レガシーフラグメンテーションメカニズムでは、ＭＳＤＵが最大１６個のフラグメントに分けられてもよい。結果として、ＭＡＣヘッダにおけるシーケンス制御フィールド内の４ビットのフラグメント数フィールドは、フラグメント化されたＭＳＤＵを搬送するＭＰＤＵの動向を追跡するために使用される。しかしながら、レベル３のフラグメンテーションにおける単一Ａ−ＭＰＤＵ当たりのＭＳＤＵのフラグメントの数は４に制限されるため、当然ながら、レベル３のフラグメンテーションモードで動作する際には、ＭＳＤＵが最大４個のフラグメントに分けられてもよい２ビットはＭＳＤＵの４つのフラグメントを追跡するのに十分であるため、フラグメント数フィールドの残りの２ビットを他の目的のために使用できる。

図６Ａは、第１の実施形態によるシーケンス制御フィールド６００の構造を示す。シーケンス番号フィールド６０６は不変のままであるが、フラグメント番号フィールド６０４のために２ビットのみが使用され、また、フラグメント数フィールド６０２のために残りの２ビットが使用され、フラグメント数フィールド６０２は、シーケンス番号６０６と一致するＭＳＤＵが分かれるフラグメントの数を示すために使用される。図６Ｃの符号化テーブル６４０は、フラグメント数フィールド６０２の符号化をリストアップする。図６Ａのフラグメント数フィールド６０２の２ビットは、最大４つのフラグメントを示すことができる。フラグメント数フィールド６０２の値は、シーケンス番号６０６と一致するＭＳＤＵの全てのフラグメントにおいて一定のままである。各ＭＰＤＵはそれぞれのＭＡＣヘッダでシーケンス制御フィールド６００を搬送するため、フラグメント数フィールド６０２を検査することによって、ＭＰＤＵの受信側は、フレーム制御フィールドのより多くのフラグメントビットを追跡する必要なく、シーケンス番号６０６と一致するＭＳＤＵが分けられるフラグメント数を素早く見出すことができる。

図６Ｂは、第１の実施形態によって提案されるブロックＡｃｋフレームのＢＡ情報フィールド６１０の構造を示す。ＢＡ開始シーケンス制御フィールド６２０の構造は、不変のままであり、４ビットフラグメント番号フィールド６２２と１２ビット開始シーケンス番号（ＳＳＮ）フィールド６２４とから構成される。レガシーブロックＡｃｋフレームでは、フラグメント番号フィールドが常に０に設定される。しかしながら、フラグメント番号フィールド６２２は、ＢＡビットマップフィールド６３０のタイプ又は使用を区別するために使用されてもよい。例えば、フラグメント番号フィールド６２２のビットの幾つかは、レガシーブロックＡｃｋと比べて異なるＢＡビットマップフィールド６３０のための符号化方式を示すために使用されてもよく、一方、幾つかの他のビットは、ＢＡビットマップフィールド６３０のサイズを示すために使用されてもよい。

図６Ｂは、一例として８オクテット長のＢＡビットマップを例示するが、本開示で開示される方法は、より小さい又はより長いＢＡビットマップにも同様に適用される。開始シーケンス番号（ＳＳＮ）フィールド６２４は、ＢＡビットマップフィールド６３０の最初のビット又はビットのブロックによって確認されるＭＳＤＵのシーケンス番号（ＳＮ）を示す。レガシー圧縮ブロックＡｃｋにおいて、ＢＡビットマップの各ビットは、１つのＭＳＤＵを確認するために使用される。「専用の」Ｃ−ＢＡフレームにおいて、ＢＡビットマップフィールド６３０は、それぞれが４ビットの１６個のブロックに静的に分けられる。ＢＡビットマップにおける各ビットは、単一のＭＳＤＵ又はＭＳＤＵのフラグメントの受信の成功を確認するために使用され、この場合、ＢＡビットマップフィールド６３０の最初の４ビットは、開始シーケンス番号（ＳＳＮ）サブフィールド６２４の値と一致するシーケンス番号（ＳＮ）を伴うＭＳＤＵに対応する。４ビットのブロックへのＢＡビットマップフィールド６３０の静的な分割の代わりに、第１の実施形態は、ビットブロックが必要に応じてのみ割り当てられるようにＢＡビットマップフィールド６３０の動的な符号化を提案する。受信されたＡ−ＭＰＤＵで搬送されるＭＳＤＵのフラグメントの数に等しいビットのブロックがＭＳＤＵに割り当てられる。受信側は、受信されたＭＰＤＵにおけるフラグメント数フィールド６０２の値を使用して、ＢＡビットマップフィールド６３０におけるビット割り当てを把握してもよい。例えば、３つのフラグメントを伴うＭＳＤＵに関して３ビットのブロック６３２が割り当てられ、２つのフラグメントを伴うＭＳＤＵに関して２ビットのブロック６３４が割り当てられ、フラグメント化されていないＭＳＤＵに関して単一ビット６３６が割り当てられ、一方、４つのフラグメントを伴うＭＳＤＵに関して４ビットのブロック６３８が割り当てられる。

ＢＡビットマップのそのような動的な符号化と関連付けられる１つの課題は、ビットブロックサイズに関する情報を管理することである。図７Ａは、単一ＭＳＤＵ当たりのフラグメント数に基づいて受信されたＭＳＤＵに割り当てられるビット数を記録するために受信側によって使用されるフラグメントサイズテーブル（ＦＳＴ：Ｆｒａｇｍｅｎｔ Ｓｉｚｅ Ｔａｂｌｅ）７００を示す。６４ビットＢＡビットマップを想定すると、６４個のエントリを伴う円形配列としてＦＳＴ７００を実装できる。一般に、ＢＡビットマップのサイズがＢｉｔｍａｐＬｅｎとして示される場合には、ＢｉｔｍａｐＬｅｎのエントリを伴う円形配列としてＦＳＴ７００を実装でき、変数ＦｓｔＳｔａｒｔＲ及び変数ＦｓｔＥｎｄＲを使用してＦＳＴの開始位置及び終了位置を追跡し、一方、ＦｓｔＩｎｄｅｘＲを使用して現在処理されているＭＳＤＵに対応するエントリを追跡する。

図７Ｂは、受信されたＭＳＤＵの受信状態を記録するために使用されるビットマップを示す。７１０は、シーケンス番号ごとに４ビットを伴う、シーケンス番号空間全体を表す。スコアボードビットマップ７１２は、発信側と受信側との間のＨＴ即時ブロックＡｃｋ合意のセットアップ段階２１０中に初期化されて現在の送信ウィンドウのシーケンス番号空間を表すブロック肯定応答記録の一部である。変数ＷｉｎＳｔａｒｔＲは、ビットマップにおける最低シーケンス番号位置に対応するビットのブロックを表し、変数ＷｉｎＳｉｚｅＲは、ＢｉｔｍａｐＬｅｎの値（ＢＡビットマップのサイズ）及びブロックＡｃｋ合意を確立した関連するＡＤＤＢＡ応答フレームのバッファサイズフィールドの値のうちの小さい方の値（この例では６４）に設定され、また、変数ＷｉｎＥｎｄＲは、現在の送信ウィンドウにおける最高シーケンス番号に対応するビットのブロックを表す。スコアボードビットマップのサイズはＷｉｎＳｉｚｅＲ×４に等しい。受信されたＭＰＤＵに対応する正確なビットを追跡するために変数ＳｂＩｎｄｅｘが使用される。レベル３のフラグメンテーションを含むそれぞれのＨＴ即時ブロックＡｃｋ合意ごとに、受信側が全状態動作又は部分状態動作のいずれかを選択してもよい。全状態動作下では、スコアボードビットマップ７１２が静的に割り当てられたメモリに保持され、一方、部分状態動作では、スコアボードビットマップ７１２がキャッシュメモリに保持される。ＦｓｔＳｔａｒｔＲ、ＦｓｔＥｎｄＲ、及び、ＦｓｔＩｎｄｅｘＲにおける全ての動作は循環モジュロＷｉｎＳｉｚｅＲで実行される。

＜スコアボードコンテキスト＞
定義：
ＳＮは、受信されたフレームのシーケンス番号フィールド６０６の値である。
ＦＮは、受信されたフレームのフラグメント番号フィールド６０４の値である。
ＮＦは、受信されたフレームのフラグメント数フィールド６０２の値である。
ＳＳＮは、受信されたブロックＡｃｋＲｅｑフレームの開始シーケンス番号フィールド６２４の値である。
ＢｉｔｍａｐＬｅｎは、ＢＡビットマップフィールド６３０のビット長である。

＜全状態動作中のスコアボードコンテキスト＞
レベル３のフラグメンテーションを伴うとともに全状態動作を使用するそれぞれのＨＴ即時ブロックＡｃｋ合意ごとに、受信側は、サイズがＷｉｎＳｉｚｅＲ×４の静的スコアボードビットマップとＷｉｎＳｉｚｅＲエントリを伴う静的フラグメントサイズテーブル（ＦＳＴ）とを含むブロック肯定応答記録を保持する。全状態動作を使用するＨＴ即時ブロックＡｃｋ合意を実施するＳＴＡは、以下の規則にしたがってその合意のためのブロック肯定応答記録を保持するものとする。

ａ）初期化（ＨＴ−即時ブロックＡｃｋ合意確立時）：
１）レベル３のフラグメンテーションを含むＨＴ即時ブロックＡｃｋ合意を開始したＡＤＤＢＡ要求フレームからＷｉｎＳｔａｒｔＲ＝ＳＳＮを設定する。
２）ＷｉｎＳｉｚｅＲ＝ＢｉｔｍａｐＬｅｎ及び関連するＡＤＤＢＡ応答フレームのバッファサイズフィールドの値のうちの小さい方を設定する。
３）ＷｉｎＥｎｄＲ＝ＷｉｎＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
４）ＦｓｔＳｔａｒｔＲ＝０を設定する。
５）ＦｓｔＥｎｄＲ＝ＦｓｔＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
６）ＦＳＴが全て「４」に初期化される。

ｂ）特定の全状態動作ブロックＡｃｋ合意に関連するそれぞれの受信されたデータフレームごとに：
１）ＷｉｎＳｔａｒｔＲ＜＝ＳＮ＜＝ＷｉｎＥｎｄＲである場合には、
ｉ）ＳｂＩｎｄｅｘ＝ＳＮ×４＋ＦＮを設定する。
ｉｉ）スコアボードビットマップ内の位置ＳｂＩｎｄｅｘにあるビットを１に設定する。
ｉｉｉ）ＦｓｔＩｎｄｅｘＲ＝ＦｓｔＳｔａｒｔＲ＋ＳＮ−ＷｉｎＳｔａｒｔＲを設定する。
ｉｖ）ＦＳＴ内の位置ＦｓｔＩｎｄｅｘＲにあるエントリをＮＦに設定する。
２）ＷｉｎＥｎｄＲ＜ＳＮ＜ＷｉｎＳｔａｒｔＲ＋２^１１である場合には、
ｉ）（ＳＮ−ＷｉｎＥｎｄＲ）＞ＷｉｎＳｉｚｅＲであれば、スコアボードビットマップ全体を０に設定し、そうでなければ、（ＷｉｎＥｎｄＲ＋１）×４から（ＳＮ×４＋３）までのＳｂＩｎｄｅｘに対応するスコアボードビットマップのビットを０に設定する。
ｉｉ）（ＳＮ−ＷｉｎＥｎｄＲ）＞＝ＷｉｎＳｉｚｅＲであれば、ＦＳＴの全てのエントリを４に設定し、そうでなければ、ＦｓｔＥｎｄＲから（ＦｓｔＥｎｄＲ＋ＳＮ−ＷｉｎＥｎｄＲ）までのＦｓｔＩｎｄｅｘＲに対応するＦＳＴのエントリを４に設定する。
ｉｉｉ）ＦｓｔＥｎｄＲ＝ＦｓｔＥｎｄＲ＋ＳＮ−ＷｉｎＥｎｄＲを設定する。
ｉｖ）ＦｓｔＳｔａｒｔＲ＝ＦｓｔＥｎｄＲ−ＷｉｎＳｉｚｅＲ＋１を設定する。
ｖ）ＷｉｎＳｔａｒｔＲ＝ＳＮ−ＷｉｎＳｉｚｅＲ＋１を設定する。
ｖｉ）ＷｉｎＥｎｄＲ＝ＳＮを設定する。
ｖｉｉ）ＳｂＩｎｄｅｘ＝ＳＮ×４＋ＦＮを設定する。
ｖｉｉｉ）スコアボードビットマップ内の位置ＳｂＩｎｄｅｘにあるビットを１に設定する。
ｉｘ）ＦｓｔＩｎｄｅｘＲ＝ＦｓｔＳｔａｒｔＲ＋ＳＮ−ＷｉｎＳｔａｒｔＲを設定する。
ｘ）ＦＳＴ内の位置ＦｓｔＩｎｄｅｘＲにあるエントリをＮＦに設定する。
３）ＷｉｎＳｔａｒｔＲ＋２１１＜＝ＳＮ＜ＷｉｎＳｔａｒｔＲである場合には、記録を変更しない。

ｃ）特定の全状態動作ブロックＡｃｋ合意に関連するそれぞれの受信されたブロックＡｃｋＲｅｑフレームごとに：
１）ＷｉｎＳｔａｒｔＲ＜ＳＳＮ＜＝ＷｉｎＥｎｄＲである場合には、
ｉ）ＦｓｔＳｔａｒｔＲ＝ＦｓｔＳｔａｒｔＲ＋ＳＳＮ−ＷｉｎＳｔａｒｔＲを設定する。
ｉｉ）ＷｉｎＳｔａｒｔＲ＝ＳＳＮを設定する。
ｉｉｉ）（ＷｉｎＥｎｄＲ＋１）×４から（（ＷｉｎＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１）×４＋３）までのＳｂＩｎｄｅｘに対応するスコアボードビットマップのビットを０に設定する。
ｉｖ）ＷｉｎＥｎｄＲ＝ＷｉｎＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
ｖ）ＦｓｔＥｎｄＲ＝ＦｓｔＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
２）ＷｉｎＥｎｄＲ＜ＳＳＮ＜ＷｉｎＳｔａｒｔＲ＋２１１である場合には、
ｉ）ＷｉｎＳｔａｒｔＲ＝ＳＳＮを設定する。
ｉｉ）ＷｉｎＥｎｄＲ＝ＷｉｎＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
ｉｉｉ）（ＷｉｎＳｔａｒｔＲ）×４から（ＷｉｎＥｎｄＲ×４＋３）までのＳｂＩｎｄｅｘに対応するスコアボードビットマップのビットを０に設定する。
ｉｖ）ＦｓｔＳｔａｒｔＲからＦｓｔＥｎｄＲまでのＦｓｔＩｎｄｅｘＲに対応するＦＳＴのエントリを４に設定する。
３）ＷｉｎＳｔａｒｔＲ＋２１１＜＝ＳＳＮ＜ＷｉｎＳｔａｒｔＲである場合には、記録を変更しない。

＜部分状態操作中のスコアボードコンテキスト＞
レベル３のフラグメンテーションを伴うとともに部分状態動作を使用するそれぞれのＨＴ即時ブロックＡｃｋ合意ごとに、受信側は、サイズがＷｉｎＳｉｚｅＲ×４の一時スコアボードビットマップとＷｉｎＳｉｚｅＲを伴う一時フラグメントサイズテーブル（ＦＳＴ）とを含むブロック肯定応答記録を保持する。部分状態動作を使用するＨＴ即時ブロックＡｃｋ合意を実施するＳＴＡは、次の規則にしたがってその合意のためのブロック肯定応答記録を管理するものとする。

ａ）初期化：
１）ＷｉｎＳｉｚｅＲ＝ＢｉｔｍａｐＬｅｎ及び関連するＡＤＤＢＡ応答フレームのバッファサイズフィールドの値のうちの小さい方を設定する。
２）ＦｓｔＳｔａｒｔＲ＝０を設定する。
３）ＦｓｔＥｎｄＲ＝ＦｓｔＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。

ｂ）特定の部分状態ブロックＡｃｋ合意に関連するそれぞれの受信されたデータフレームごとに、受信されたデータフレームと関連する合意のための一時記録が存在しない場合：
１）ＷｉｎＥｎｄＲ＝ＳＮを設定する。
２）ＷｉｎＳｔａｒｔＲ＝ＷｉｎＥｎｄＲ−ＷｉｎＳｉｚｅＲ＋１を設定する。
３）サイズがＷｉｎＳｉｚｅＲ×４のスコアボードビットマップを形成し、この場合、ビットマップ内の最初の４つのビットがシーケンス番号ＷｉｎＳｔａｒｔＲに対応し、ビットマップ内の最後の４つのビットがシーケンス番号ＷｉｎＥｎｄＲに対応し、また、ビットマップ内の全てのビットを０に設定する。
４）ＷｉｎＳｉｚｅＲのエントリを伴うＦＳＴを形成し、全てのエントリを「４」に設定する。

ｃ）特定の部分状態ブロックＡｃｋ合意に関連するそれぞれの受信されたデータフレームごとに、受信されたデータフレームと関連する合意のための一時記録が既に存在する場合には、その合意のための一時ブロック肯定応答記録は、前の節で説明した全状態合意のための肯定応答記録と同じ態様で変更される。

ｄ）特定の部分状態ブロックＡｃｋ合意に関連するそれぞれの受信されたブロックＡｃｋＲｅｑフレームごとに、受信されたデータフレームと関連する合意のための一時記録が存在しない場合には：
１）ＷｉｎＳｔａｒｔＲ＝ＳＳＮを設定する。
２）ＷｉｎＥｎｄＲ＝ＷｉｎＳｔａｒｔＲ＋ＷｉｎＳｉｚｅＲ−１を設定する。
３）サイズがＷｉｎＳｉｚｅＲ×４のスコアボードビットマップを形成し、この場合、ビットマップ内の最初の４つのビットがシーケンス番号ＷｉｎＳｔａｒｔＲに対応し、ビットマップ内の最後の４つのビットがシーケンス番号ＷｉｎＥｎｄＲに対応し、また、ビットマップ内の全てのビットを０に設定する。
４）ＷｉｎＳｉｚｅＲのエントリを伴うＦＳＴを形成し、全てのエントリを「４」に設定する。

ｅ）特定の部分状態ブロックＡｃｋ合意に関連するそれぞれの受信されたブロックＡｃｋＲｅｑフレームごとに、受信されたデータフレームと関連する合意のための一時記録が既に存在する場合には、その合意のための一時ブロック肯定応答記録は、前の節で説明した全状態合意のための肯定応答記録と同じ態様で変更される。

図７Ｃは、第１の実施形態によるＢＡビットマップ７２０の図である。ＢＡビットマップ７２０内のビットのサイズ又は数であるＢｉｔｍａｐＬｅｎは、ブロックＡｃｋフレームタイプに依存する。例えば、レガシー圧縮ブロックＡｃｋフレーム、Ｍｕｌｔｉ−ＴＩＤブロックＡｃｋフレーム、ＧＣＲブロックＡｃｋフレームの場合には、ＢｉｔｍａｐＬｅｎが６４に等しい。しかしながら、８０２．１１ａｘは、より短い又はより長い或いは更には可変長のＢＡビットマップを伴う新たなブロックＡｃｋフレームを規定してもよい。図７ｃは、ＷｉｎＳｉｚｅＲがＢｉｔｍａｐＬｅｎに等しい場合のＢＡビットマップの一例を示す。暗黙的なブロックＡｃｋ要求（ＡｃｋポリシーがノーマルＡｃｋに等しい受信されたＡ−ＭＰＤＵ）又はブロックＡｃｋＲｅｑフレームを受信する際、ＢＡビットマップは、スコアボードビットマップの関連するセクションの内容に基づいて生成される。受信されたＭＳＤＵに対応するスコアボードビットマップにおけるビット及びそれらのフラグメントだけが、もしあれば、ＢＡビットマップ上にコピーされる。フラグメント数はＭＳＤＵごとに異なる場合があるため、ＢＡビットマップにおける単一ＭＳＤＵ当たりのビット数は１（フラグメントなし）から４（４つのフラグメント）まで変化し得る。スコアボードビットマップ内のＷｉｎＳｔａｒｔＲ及びＢＡビットマップにおける最初のビットを発端として、フラグメントサイズテーブル（ＦＳＴ）内の対応するエントリを参照することにより、ＦＳＴエントリによって示されるビット数がＢＡビットマップ上にコピーされる。

例えば、ＷｉｎＳｔａｒｔＲに等しいシーケンス番号を有するＭＳＤＵが４つのフラグメントを有することをＷｉｎＳｔａｒｔＲに対応するＦＳＴエントリが示す場合には、ＷｉｎＳｔａｒｔＲに対応するスコアボードエントリからの最初の４ビットがＢＡビットマップにおける最初の４ビット上にコピーされる。ＷｉｎＳｔａｒｔＲ＋１に等しいシーケンス番号を有するＭＳＤＵがフラグメント化されないことをＷｉｎＳｔａｒｔＲ＋１に対応する次のＦＳＴエントリが示す場合には、ＷｉｎＳｔａｒｔＲ＋１に対応するスコアボードエントリからの最初の１ビットのみがＢＡビットマップにおける次のビット上にコピーされる。同様に、ＷｉｎＳｔａｒｔＲ＋２に等しいシーケンス番号を有するＭＳＤＵが３つのフラグメントを有する場合には、ＷｉｎＳｔａｒｔＲ＋２に対応するスコアボードエントリからの最初の３ビットのみがＢＡビットマップにおける次の３ビット上にコピーされる。このプロセスは、ＢＡビットマップの終わりに達するまで又はＷｉｎＥｎｄＲに対応するビットを含むスコアボードビットマップの全ての関連するビットがＢＡビットマップにコピーされるまで続く。

ＢＡビットマップの終わりに近づく際に、スコアボードビットマップ内の次のＭＳＤＵのビット上にその全体をコピーするためにＢＡビットマップに十分なビットが残っていないことが発見される場合、ＢＡビットマップ内の残りのビットが全て０に設定される。一例として、スコアボードビットマップにコピーされるべき次のＭＳＤＵが３つのフラグメントを有するが２つのビットだけがＢＡビットマップの最後に残される場合には、２つのビットがいずれも０に設定される（例えば７２２）。受信されない有効なシーケンス番号範囲（ＷｉｎＳｔａｒｔＲ〜ＷｉｎＥｎｄＲ）内の任意のＭＳＤＵは、初期設定で４に等しい対応するＦＳＴエントリと、全てが０に設定されるスコアボードビットマップ内の４つの対応するビットとを有する。

したがって、受信されない有効なシーケンス番号範囲（ＷｉｎＳｔａｒｔＲ〜ＷｉｎＥｎｄＲ）内の任意のＭＳＤＵは、ＢＡビットマップ内に４つの連続したゼロをもたらす。ＭＳＤＵに対応するＢＡビットマップ内の４つの連続したゼロの全てが０である場合、それは、発信側にとって特別な意味を持ち、そのＭＳＤＵのＭＰＤＵのいずれも受信されなかったことを発信側に警告する。受信されなかったＭＳＤＵの一部が単一ＭＳＤＵ当たり４未満のフラグメントを有する場合があるため、そのようなＭＳＤＵはＢＡビットマップに余分なビットをもたらす。結果として、スコアボードビットマップの最後に向かう有効ビットの幾つかは、現在のＢＡビットマップに適合できない場合がある。しかしながら、多くのＭＳＤＵがフラグメント化されない場合又は多くのＭＳＤＵがフラグメント化されるがそれぞれ４つ未満のフラグメントを含む場合であっても、同じサイズのＢＡビットマップに関して、現在の開示により提案されるブロックＡｃｋメカニズムが「専用」ブロックＡｃｋにより可能なものと比べてより多くのＭＳＤＵを確認できるのが容易に分かる。全てのＭＳＤＵがそれぞれ４つのフラグメントへとフラグメント化される最悪のシナリオでさえ、効率は「専用」ブロックＡｃｋの効率に等しい。

図８Ａは、単一のＡ−ＭＰＤＵで送信され得るＭＰＤＵの数を追跡するために発信側によって管理されてもよい送信ウィンドウ８００を示す。レベル３のフラグメンテーションがＭＳＤＵの複数のフラグメント（最大４つ）を単一のＡ−ＭＰＤＵで送信できるようにするため、単一ＭＳＤＵ当たりのフラグメント数がＭＳＤＵごとに異なる場合がある。また、有効なシーケンス番号空間、すなわち、１つの送信ウィンドウ内で送信され得る固有のシーケンス番号の数は固定されない。変数ＷｉｎＳｔａｒｔＯは、現在の送信ウィンドウ内の最初のＭＳＤＵのシーケンス番号を追跡し、一方、送信ウィンドウ内で送信され得るＭＰＤＵの最大数は、ブロックＡｃｋ合意を確立した関連するＡＤＤＢＡ応答フレームのバッファサイズフィールドの値よりも小さく関連するブロックＡｃｋフレームのＢＡビットマップ内のビット数よりも大きくない変数ＷｉｎＳｉｚｅＯによって示される。送信ウィンドウ８００を管理する目的は、受信側が全ての受信されたＭＤＰＵの受信状態の記録を保持できるようにすることである。

図８Ｂは、現在の送信ウィンドウで送信されているＭＳＤＵ内に存在するフラグメントの数を追跡するために発信側によって保持されてもよいフラグメントサイズテーブル（ＦＳＴ）８１０を示す。発信側は、アクセスを容易にするために、送信バッファ内のそのＭＳＤＵのそれぞれのフラグメント数を読み取ることができるが、発信側はＦＳＴを保持してもよい。１つのＦＳＴは、レベル３のフラグメンテーションを含む全ての新たなＨＴ即時ブロックＡｃｋ合意と関連付けられる。ＨＴ即時ブロックＡｃｋ合意に関連するブロックＡｃｋフレームが６４ビットＢＡビットマップを有すると仮定すると、ＦＳＴは、最大６４個のＭＳＤＵのフラグメント数を記録する最大６４エントリテーブルとして実装され得る。ＦＳＴは、ＦｓＴＳｔａｒｔＯ及びＦｓｔＥｎｄＯがＦＳＴの開始及び終了を追跡する最大６４エントリ循環バッファとして実装されてもよく、一方、ＦｓｔＩｎｄｅｘＯは、ＦＳＴの個々のエントリへのインデックスとして使用される。

一般に、ＢＡビットマップのサイズがＢｉｔｍａｐＬｅｎとして示される場合、ＦＳＴは、ＢｉｔｍａｐＬｅｎに等しいエントリを伴うテーブルとして実装され得る。位置ＦｓｔＳｔａｒｔＯにあるＦＳＴのエントリは、現在の送信ウィンドウにおける最初のＭＳＤＵのシーケンス番号、すなわち、シーケンス番号サブフィールド値がＷｉｎＳｔａｒｔＯに等しいＭＳＤＵに対応し、一方、位置ＦｓｔＥｎｄＯにあるＦＳＴのエントリは、現在の送信ウィンドウにおける最後のＭＳＤＵのシーケンス番号に対応する。ＦＳＴの各エントリは、それぞれごとのフラグメントの数を記録する。フラグメントの存在に起因して、１つの送信ウィンドウ内で送信され得る固有のシーケンス番号の数は固定されないが、ＷｉｎＳｉｚｅＯが１つの送信ウィンドウ内で送信され得る最大の固有のシーケンス番号を表すため、ＦｓｔＳｔａｒｔＯ、ＦｓｔＥｎｄＯ、及び、ＦｓｔＩｎｄｅｘＯに関する全ての動作が循環モジュロＷｉｎＳｉｚｅＯで実行される。

図８Ｃは、ＭＳＤＵ全体が受信されない場合のシナリオを示す第１の実施形態によるＢＡビットマップフィールドの一例の図である。シーケンス番号ごとの肯定応答ビットの数はＢＡビットマップ内で固定されないため、発信側は、肯定応答ビットを正しく復号するためにＦＳＴ８１０内の対応するＦＳＴエントリを参照する必要がある。受信側がＭＰＤＵヘッダにおけるフラグメント数フィールド６０２に基づいて各ＭＳＤＵの少なくとも１つのフラグメントを正しく受信する場合、受信側は、ＢＡビットマップ内のそれぞれのＭＳＤＵごとに割り当てるべき正しいビット数を知っている。そのような場合には、ＢＡビットマップが送信ウィンドウ内のＭＰＤＵと１対１の関係を有し、また、発信側は肯定応答状態を正しく復号することができる。

しかしながら、受信側がＭＳＤＵの単一のフラグメント又はフラグメント化されないＭＳＤＵをも受信しなかった場合には、欠けているシーケンス番号に対応するＢＡビットマップ内の４つの連続するビットが０に設定される。一例として、シーケンス番号ＳＮ＋１を有するＭＰＤＵが受信側によって受信されない場合には、ＭＳＤＵが正しく受信された場合に１つのビットだけが１にセットされるのではなく、ブラックボックス８２４によって強調されるようにＢＡビットマップにはＳＮ＋１に対応する０に設定される４つの連続するビットが存在する。ＦＳＴエントリ８１２により、発信側は、シーケンス番号ＳＮ＋１を有するＭＰＤＵに関して単一のビットを期待している。ビットがゼロに設定される場合、発信側は次の３ビットをチェックする必要がある。発信側は、それがシーケンス番号境界で４つの連続したゼロを受信する場合には、それを、シーケンス番号ＳＮ＋１を伴う任意のＭＰＤＵの受信に受信側が失敗したと解釈し、ＳＮ＋１に対応する全てのＭＰＤＵ、この場合には失敗した１つのＭＰＤＵの送信状態をマーキングして、ＢＡビットマップ内で４ビット前進する。

ＳＮ境界で生じる単一ＭＳＤＵ当たりのフラグメントの最大数に等しい連続したゼロだけがこの特別な意味を持つ。上記の例では、ＦＳＴに基づき、ビット２及びビット３（最初のビットがビット０）にある２つのゼロ８２２がＭＳＤＵ ＳＮに対応することに発信側が気づくため、ビット数２から始まる４つの連続するゼロが存在しても、発信側はこれを特別な意味を持つものとして混同しない。ＳＮ＋１境界で始まる４つの連続したゼロ、すなわち、８２４だけが、シーケンス番号ＳＮ＋１を有するＭＳＤＵを受信するのに失敗として解釈される。

図９Ａ、図９Ｂ、及び、図９Ｃは、第１の実施形態による効率的なブロックＡｃｋメカニズムを利用するフレーム交換シーケンス９００の一例を示す。フレーム交換に先立って、レベル３のフラグメンテーションを含むＨＴ即時ブロックＡｃｋ合意がフレーム交換に関与する２つの無線デバイス間で既にネゴシエートされてしまっていると仮定される。この例では、ＷｉｎＳｉｚｅＯ、ＷｉｎＳｉｚｅＲ、及び、ＢｉｔｍａｐＬｅｎの値が６４に等しい。発信側及び受信側は、フラグメントサイズテーブル９０２、９２０を保持して、現在の送信ウィンドウでそれぞれ送信又は受信されているＭＳＤＵ内に存在するフラグメントの数を追跡する。ＦＳＴの全てのエントリは、現在のＨＴ即時ブロックＡｃｋ合意下でＭＳＤＵごとに許されるフラグメントの最大数（この例では４）に初期化される。

発信側は、ＳＮ＝１を伴うＭＳＤＵの４つのそれぞれのフラグメントを搬送する４つのＭＰＤＵ、ＳＮ２〜６を伴うフラグメント化されないＭＳＤＵを搬送する５つのＭＰＤＵ、ＳＮ＝７を伴うＭＰＤＵの２つのそれぞれのフラグメントを搬送する２つのＭＰＤＵ、及び、ＳＮ８〜３０を伴うフラグメント化されないＭＳＤＵを搬送する２３個のＭＰＤＵを発端として３４個のＭＰＤＵを集約するＡ−ＭＰＤＵ９１０を送信することによってフレーム交換を開始する。また、各ＭＰＤＵはそれぞれのＭＡＣヘッダでフラグメント数フィールド６０２も搬送する。

受信側は、ＭＰＤＵを受信する際、フラグメント数６０２の値をＦＳＴ９２０の対応するエントリにコピーし、例えば、ＳＮ＝１を伴うＭＳＤＵに対応するエントリ＃１に４をコピーし、エントリ＃２、＃３、＃４、＃６などに１をコピーする。同じＭＳＤＵのフラグメントを搬送する全てのＭＰＤＵのフラグメント数フィールドの値が同じであるため、ＭＳＤＵごとに１回ＦＳＴエントリを更新するだけで済む。この送信において、受信側は、３つのＭＰＤＵ、すなわち、ＳＮ＝５を伴うＭＰＤＵ９１２、ＳＮ＝７を伴うＭＳＤＵの２つのフラグメントを搬送するＭＰＤＵ９１４、９１６を受信し損なう。結果として、ＦＳＴエントリ＃５ ９２２及び＃７ ９２４並びにＳＮが送信ウィンドウの外側にあるＭＳＤＵに対応する全てのエントリは、初期値４で不変のままである。同時に、受信側は、正しく受信されたＭＰＤＵに対応する各ビットを１に設定するスコアボードビットマップ９２６の対応するビットに各ＭＰＤＵの受信状態も記録する。

フラグメント化されないＭＳＤＵの場合、ＭＳＤＵに対応する４ビットブロック内の最初のビットのみが１に設定され、残りのビットは０に設定されたままである。この例では、ＳＮ＝１である。Ａ−ＭＰＤＵ９１０のＭＰＤＵは暗黙的なブロックＡｃｋ要求を示す（ＡｃｋポリシーがノーマルＡｃｋに等しい）。Ａ−ＭＰＤＵ９１０の終わりに到達する際に、スコアボードビットマップ９２６の最初のビット及びＢＡビットマップ９３０の最初のビットを発端として、フラグメントサイズテーブル（ＦＳＴ）９２０内の対応するエントリを参照することによって、ＦＳＴエントリによって示されるビット数が、一度に１つのＭＳＤＵずつ、ＢＡビットマップ９３０上にコピーされる。ＳＮ＝１を伴うＭＳＤＵに対応するスコアボードエントリからの４つのビットがＢＡビットマップ内の最初の４つのビット上にコピーされ、ＳＮ＝２〜４を伴うＭＳＤＵに対応するスコアボードエントリの最初の１つのビットが次の３つのビット上にコピーされる。同様に、ＦＳＴエントリ＃５ ９２２は４の値を示すため、ＳＮ＝５を伴うＭＳＤＵに対応するスコアボードエントリからの４つのビット（００００）は、ＢＡビットマップ内の次の４つのビット９３２上にコピーされる。同様に、ＳＮ＝６及び７を伴うＭＳＤＵに対応するスコアボードエントリからの１つのビット及び４つのビット（００００）は、ＢＡビットマップのビット＃１１及び次の４つのビット９３４上にそれぞれコピーされる。スコアボードビットマップ９２６の有効範囲内の残りのビットは、同様にしてＢＡビットマップ９３０のそれぞれのビット上にコピーされる。ＳＮ＝３０を伴うＡ−ＭＰＤＵ９１０における最後のＭＳＤＵに対応するビット９２８は、ＢＡビットマップ９３０におけるビット＃３８ ９３６上にコピーされる。

受信側は、ＢＡビットマップ９３０を搬送するブロックＡｃｋフレーム９３８を送信することによってＡ−ＭＰＤＵ９１０の受信を確認する。ブロックＡｃｋフレーム９３８の開始シーケンス番号フィールド６２４は、ＢＡビットマップ９３０によって確認される第１のＭＳＤＵのシーケンス番号に設定され、一方、フラグメント番号フィールド６２２の１つのビット（例えばＢ０）は、ＢＡビットマップ９３０が第１の実施形態のように符号化されることを示すために使用されてもよく、また、２つのビット（例えば、Ｂ１、Ｂ２）は、ＢＡビットマップ９３０の長さ（ビット数）を示すために使用されてもよい。

発信側がブロックＡｃｋフレーム９３８を受信した時点で、発信側は、フラグメント番号フィールド６２２のビットの値に基づいてＢＡビットマップ９３０を復号し始める。ＢＡビットマップ９３０において単一ＭＳＤＵ当たりのビット数が変化する場合であっても、発信側は、ＦＳＴ９０２を参照することによって各ＭＰＤＵの受信状態を正しく理解することができる。発信側がＳＮ＝５を伴うＭＳＤＵのためのＳＮ境界にある４つの連続したゼロ９３２を横切ると、発信側は、それを、ＳＮ＝５を伴うＭＳＤＵに対応する任意のＭＰＤＵの受信に受信側が失敗したと解釈し、ＦＳＴエントリ９０４に基づき、ＳＮ＝５に対応する単一のＭＰＤＵの送信状態を失敗としてマーキングする。同様に、発信側は、ＳＮ＝７を伴うＭＳＤＵのためのＳＮ境界にある４つの連続したゼロ９３４を、ＳＮ＝７を伴うＭＳＤＵに対応する任意のＭＰＤＵの受信に受信側が失敗したとして解釈し、ＦＳＴエントリ９０６に基づき、ＳＮ＝７に対応する２つのＭＰＤＵの送信状態を失敗としてマーキングする。

発信側は、ブロックＡｃｋ９３８の内容に基づき、ＳＮ＝５及び７を伴うＭＳＤＵに対応する３つの失敗したＭＰＤＵ、ＳＮ３１を伴うフラグメント化されないＭＳＤＵを搬送する単一のＭＰＤＵ、ＳＮ＝３２を伴うＭＳＤＵの３つのそれぞれのフラグメントを搬送する３つのＭＰＤＵ、及び、ＳＮ３３〜４０を伴うフラグメント化されないＭＳＤＵを搬送する９個のＭＰＤＵを集約する次のＡ−ＭＰＤＵ９４０を送信する。それに応じてＦＳＴ９０２のエントリが更新される。この送信において、受信側は、４つのＭＰＤＵ、すなわち、ＳＮ＝７を伴うＭＳＤＵの最初のフラグメントであるＭＰＤＵ９４２、及び、ＳＮ＝３２を伴うＭＳＤＵの３つのフラグメントを搬送するＭＰＤＵ９４４、９４６、９４８の受信に失敗する。結果として、ＦＳＴエントリ＃３２ ９４９及びＳＮが送信ウィンドウの外側にあるＭＳＤＵに対応する全てのエントリは、初期値４で不変のままである。

しかしながら、ＳＮ＝５を伴うＭＳＤＵを搬送するＭＰＤＵ及びＳＮ＝７を伴うＭＳＤＵの第２のフラグメントを搬送するＭＰＤＵもＭＰＤＵヘッダにおけるフラグメント数フィールド６０２の値に基づき正しく受信されるため、受信側は、ＦＳＴエントリ９２２及び９２４を１及び２の正しい値にそれぞれ更新する。Ａ−ＭＰＤＵ９４０の終わりに達すると、ＢＡビットマップ９５０は、先に説明したようにスコアボードビットマップの関連するビット上にコピーすることによって形成される。今回は、ＳＮ＝３２を伴うＭＰＤＵに対応するＭＰＤＵのいずれも受信されなかったため、ＢＡビットマップ９５０内の４つの対応するビット９５２上に４つのゼロがコピーされる。

最後に、受信側は、ＢＡビットマップ９５０を搬送するブロックＡｃｋフレーム９５４を送信することによってＡ−ＭＰＤＵ９４０の受信を確認する。発信側は、ブロックＡｃｋフレーム９５４を受信すると、先に説明したようにＢＡビットマップ９５０を復号し続ける。発信側がＳＮ＝７を伴うＭＳＤＵのためのＳＮ境界にある４つの連続したゼロ９５２を横切ると、発信側は、それを、ＳＮ＝３２を伴うＭＳＤＵに対応する任意のＭＰＤＵの受信に受信側が失敗したと解釈し、ＦＳＴエントリ９０８に基づき、ＳＮ＝３２に対応する３つのＭＰＤＵの送信状態を失敗としてマーキングする。この例から分かるように、フラグメント化されるＭＳＤＵの数が少ない場合、第１の実施形態で提示されたブロック肯定応答メカニズムを採用することによって、確認応答効率の大幅な向上を達成することができる。

＜第２の実施形態＞
多くのＭＳＤＵが完全に受信されない場合、ＢＡビットマップは、連続したゼロの多数のグループで満たされ、それにより、単一のブロックＡｃｋフレームで確認され得るＭＰＤＵのシーケンス番号空間を減少させる。先に説明したように、レベル３のフラグメンテーションに関する主な使用事例は、アップリンクマルチユーザＰＰＤＵの最後の未使用スペースを埋めることである。したがって、レベル３のフラグメンテーションがＭＳＤＵごとに最大で４つのフラグメントを許容する場合であっても、多くのシナリオでは、特にＭＳＤＵのサイズが小さいときに、ＭＳＤＵごとに必要なフラグメントの実際の数は、４未満となる場合があり、多くの場合にはちょうど２となる場合がある。

この所見に基づき、第２の実施形態は、第１の実施形態で提示されたメカニズムを改善し、ＭＳＤＵ全体が受信されない場合にＭＳＤＵに対応するＦＳＴエントリが受信されたＡ−ＭＰＤＵに存在する同じＭＳＤＵの最大フラグメント数として例えば２として更新されることを推奨する。これは、受信されないＭＳＤＵを完全に表現するために使用されるＢＡビットマップ内の連続した０の数、すなわち、２をもたらす発信側がＢＡビットマップを正しく復号するのを助けるために、受信側は、この値を、ブロックＡｃｋフレーム内のフラグメント番号フィールド６２２の２つのビットを使用して示す。２つのビットが一緒に使用される場合には、以下の４つのケース、すなわち、００（フラグメント化されない）；０１（２つのフラグメント）；１０（３つのフラグメント）；１１（４つのフラグメント）を信号で伝えることができる。フラグメント化されないケースのほかに、残りの３つの値はレベル３のフラグメンテーションの使用も示す。或いは、レベル３のフラグメンテーションの使用を示すために１つのビットが使用され（０：レベル３のフラグメンテーションが使用されない、１：レベル３のフラグメンテーションが使用される）、一方、受信されたＡ−ＭＰＤＵに存在するフラグメントの最大数を示すために２番目のビットが使用される。例えば、２つのフラグメントを示すための０、及び、４つのフラグメントを示すための１。

図１０Ａ、図１０Ｂ、及び、図１０Ｃを参照すると、第２の実施形態による効率的なブロックＡｃｋメカニズムを利用するフレーム交換シーケンス１０００の一例が示される。最初のＡ−ＭＰＤＵは４つのフラグメントを伴うＭＳＤＵを含むため、受信側でのＢＡ Ｂｉｔｍａｐの構築及び発信側でのＢＡビットマップの復号化は、フレーム交換９００におけるＢＡビットマップ９３０の構築及び復号化と全く同じである。唯一の相違点は、４に等しい受信されたＡ−ＭＰＤＵに存在するフラグメントの最大数がブロックＡｃｋフレーム９３８におけるフラグメント番号フィールド６２２の２つのビットを使用して示されるという点である。

その後、発信側は、フレーム交換９００におけるＡ−ＭＰＤＵ９４０と全く同じであるＡ−ＭＰＤＵ１０１０を送信する。この送信において、受信側は、４つのＭＰＤＵ、すなわち、ＳＮ＝７を伴うＭＳＤＵの最初のフラグメントであるＭＰＤＵ１０１２、及び、ＳＮ＝３２を伴うＭＳＤＵの３つのフラグメントを搬送するＭＰＤＵ１０１４、１０１６、１０１８の受信に失敗する。ＳＮ＝３２を伴うＭＳＤＵの３つの全てのフラグメントは受信されないため、受信されるフラグメントの最大数は２である。したがって、受信側は、ＳＮ＝３２を伴うＭＳＤＵに対応するＦＳＴエントリ１０２０を２として記録する。その結果、ＢＡビットマップ１０３０が構築されるときに、２つの連続するゼロ１０３２がＳＮ＝３２を伴うＭＳＤＵを表す。その後、受信側は、ＢＡビットマップ９５０を搬送するブロックＡｃｋフレーム１０４０を送信することによってＡ−ＭＰＤＵ１０１０の受信を続けて確認する。

発信側は、ブロックＡｃｋフレーム１０４０を受信する際、完全に受信されないＭＳＤＵを表す連続する０の数、この場合には２がブロックＡｃｋフレーム１０４０のフラグメント番号フィールド６２２に示されることを除き、第１の実施形態で先に説明した態様と同様の態様でＢＡビットマップ１０３０を続けて復号する。発信側がＳＮ＝３２を伴うＭＳＤＵに対応する２つの連続するビット１０３２を横切るとき、ＳＮ＝３２を伴うＭＳＤＵに対応する３つのＭＰＤＵの全てが受信側によって受信されなかったことを正しく復号することができる。

＜第３実施形態＞
第１及び第２の実施形態では、ＭＳＤＵごとに許可されるフラグメントの最大数が４に固定されると仮定された。しかしながら、ＭＳＤＵごとに許容されるフラグメントの最大数を所定値に固定する代わりに、発信側及び受信側は、２つのデバイス間のＨＴ即時ブロックＡｃｋメカニズムのセットアップ段階中にこの値をネゴシエートできるようにされてもよい。通信されるようになっているＭＳＤＵが比較的大きい場合には、より大きな値が使用されてもよく、一方、ＭＳＤＵがより小さい場合には、より小さい値がネゴシエートされてもよい。また、ＭＳＤＵごとに許可されるフラグメントの最大数は、いずれかのデバイスで利用可能なリソースに依存する場合もある。これは、より大きな値によってデバイスがより大きなバッファ等を有さなければならないからである。図１１Ａに示されるように、ＭＳＤＵごとに許可されるフラグメントの最大数は、ＡＤＤＢＡ拡張要素１１００で搬送されてもよい。

要素ＩＤ１１０２が８０２．１１仕様で指定されるように設定され、長さフィールド１１０４が１オクテットを示し、一方、ＡＤＤＢＡ能力フィールド１１０６が図１１Ｂに示されるようにカスタマイズされる。既存の非フラグメンテーションサブフィールド１１１２のほかに、残りの７つのビットが現在留保される。第３の実施形態により、留保されたビットの幾つか、例えば２つのビットは、残りの５ビットが留保される状態で単一ＭＳＤＵ１１２４当たりの最大フラグメントを示すために使用される。単一ＭＳＤＵ１１２４当たりの最大フラグメントの符号化が図１１Ｃのテーブル１１３０に示されるようになっていてもよく、この場合、値０、１、２及び３は、単一ＭＳＤＵ当たりの最大２、４、８及び１６フラグメントをそれぞれ表す。４つのビットを使用して単一ＭＳＤＵ当たりの最大フラグメントを符号化する場合、更に一層細かいレベルを示すことができる。

単一ＭＳＤＵ当たりのより高い数のフラグメントをサポートするために、スコアボード及びフラグメントサイズテーブルを更に変更する必要がある。単一ＭＳＤＵ当たりの最大フラグメントが４以下ある場合にはフラグメントの数を記録するのに単一ＦＳＴエントリ当たり２ビットで十分であるが、単一ＭＳＤＵ当たりの最大フラグメントが１６である場合には単一ＦＳＴエントリ当たり４ビットが必要とされる。加えて、ＭＳＤＵの受信状態を記録するために、スコアボードビットマップには単一ＭＳＤＵ当たり１６ビットが必要とされる。

第３の実施形態は、単一ＭＳＤＵ当たり１つの余分なビットを加えることによってスコアボードビットマップが受信状態及び単一ＭＳＤＵ当たりのフラグメント数の両方を一緒に記録できるようにするスコアボードビットマップのための新規な符号化方法を導入する。これは、単一ＭＳＤＵ当たりの最大フラグメントが４になるようにネゴシエートされる例に関して図１１Ｄに示される。単一ＭＳＤＵ当たりの最大フラグメント＋１に等しいビットの数、この場合には５は、ＭＳＤＵごとにスコアボードビットマップ１１４０で割り当てられる。それぞれのビットグループごとのビット番号付けが１１５０に示されており、この場合、Ｂ０、Ｂ１、Ｂ２、Ｂ３及びＢ４は、ビットグループ１１５０の第１、第２、第３、第４及び第５のビットを表す。

図１１Ｅは、スコアボードビットマップ１１４０の各ビットグループの符号化のテーブル１１６０を示す。単一ＭＳＤＵ当たりの最大フラグメントが４としてネゴシエートされる場合、４つの可能な符号化が存在する。Ｂ４＝０の場合には２つの可能性が存在する。すなわち、ＭＳＤＵ全体が受信されず、このケースでは、ビットＢ０、Ｂ１、Ｂ２及びＢ３の残りが全て０に設定され、或いは、単一ＭＳＤＵ当たりのフラグメント数が４に等しく、ビットＢ０、Ｂ１、Ｂ２及びＢ３がフラグメント０、１、２及び３の受信状態をそれぞれ示す。この符号化はビットグループ１１４２によって表される。Ｂ４＝１及びＢ３＝０の場合、単一ＭＳＤＵ当たりのフラグメント数は３に等しく、また、ビットＢ０、Ｂ１及びＢ２はフラグメント０、１及び２の受信状態をそれぞれ示す。

この符号化はビットグループ１１４４によって表される。同様に、Ｂ４＝１、Ｂ３＝１及びＢ２＝０の場合、単一ＭＳＤＵ当たりのフラグメント数は２に等しく、ビットＢ０及びＢ１はフラグメント０及び１の受信状態をそれぞれ示す。この符号化はビットグループ１１４４によって表される。最後に、Ｂ４＝１、Ｂ３＝１、Ｂ２＝１及びＢ１＝０の場合、単一ＭＳＤＵ当たりのフラグメント数は１に等しく、すなわち、ＭＳＤＵはフラグメント化されず、ビットＢ０はＭＳＤＵの受信状態を示す。この符号化はビットグループ１１４８によって表される。１１４０の網掛けボックスは、ＭＰＤＵの受信状態を記録するために使用されてＢＡビットマップ上にコピーされるビットを表す。一般に、ビットグループ内の０に設定される最後のビットの位置は、ビットグループの符号化を示す。「ｎ」がＨＴ即時ブロックＡｃｋセットアップ中にネゴシエートされるＭＳＤＵごとに許可される最大フラグメント数を表す場合、スコアボードビットマップ内のＭＳＤＵごとにｎ＋１ビットのビットグループが必要とされる。Ｂ０がビットグループの最初のビットを表すとともにＢｎが位置ｎ＋１にあるビットを表す場合、スコアボードビットマップ符号化は以下のように一般化され得る。

Ｂｎ＝０の場合、及び、ビットグループ内の残りのビットもゼロである場合には、ＭＳＤＵ全体が受信されず、さもなければ、フラグメント数＝ｎであり、Ｂ０〜Ｂｎ−１はフラグメント０〜ｎ−１の受信状態をそれぞれ示す。

Ｂｎ〜Ｂｍが全て１でＢｍ−１＝０の場合、フラグメント数＝ｍ−１及びＢ０〜Ｂｍ−２は、フラグメント０〜ｍ−２の受信状態をそれぞれ示す（ｍ＜＝ｎ；ｍ＞２）。

Ｂｎ〜Ｂｎ−２が全て１でありＢ１＝０の場合には、ＭＳＤＵがフラグメント化されず、Ｂ０はＭＳＤＵの受信状態を示す。

次に、スコアボードビットマップ動作について簡単に説明する。スコアボードビットマップの全てのビットは０に初期化される。フラグメント数フィールド６０２の値に基づいてフラグメント又はＭＳＤＵが受信されると、対応するビットがテーブル１１６０に記載されるような値に設定され、例えばフラグメント数フィールド６０２の値が３である場合には、Ｂ４が１に設定されるとともにＢ３が０に設定され、フラグメント数フィールド６０２の値が１であれば、Ｂ４、Ｂ３及びＢ２が１に設定されるとともにＢ１が０に設定される。更に、フラグメント番号フィールド６０４に対応するビットが１に設定される。フラグメント０の場合にはＢ０、フラグメント１の場合にはＢ１、フラグメント２の場合にはＢ２、フラグメント４の場合にはＢ３である。

或いは、フラグメント数がＭＰＤＵに明示的に示されない場合、受信側は、ＭＰＤＵのシーケンス制御フィールド内のフレーム制御フィールド及びフラグメント番号フィールドにおけるより多くのフラグメントビットを使用してフラグメント数を決定する。この場合、受信側は、（０に設定されるより多くのフラグメントビットによって示されるように）最後のフラグメントが受信されるときだけフラグメントの数を決定できる。したがって、スコアボードビットマップ符号化は、受信されたフラグメントに基づいて動的に更新される必要があり得る。例えば、最初のフラグメントが受信されるときには、より多くのフラグメントビットが１に設定されれば、受信側は、より多くのフラグメントが存在することを認識するが、フラグメントの正確な数を認識しないため、Ｂ４を０に設定するとともにＢ０を１に設定する。その後、同じＭＳＤＵの第２のフラグメントが受信されると、より多くのフラグメントビットが０に設定されれば、受信側は、この時点で、フラグメント数が２であることを知り、そのため、２つのフラグメントを示すべくＢ４、Ｂ３及びＢ２をそれぞれ１、１、０に設定するとともにフラグメント２が受信されたことを示すべくＢ１を１に設定する。

しかしながら、スコアボードビットマップ符号化を破損させないようにするために、フラグメント化されたＭＳＤＵの場合には、１つの付加的な規則が必要とされる。すなわち、ビットグループが全て０以外の値に既に符号化されてしまっている場合には、符号化だけが全てゼロに（ＭＳＤＵの最後のフラグメントが受信されないとき）又はより多くの数のフラグメントを示すように変えられてもよい。言い換えると、ビットグループ内の最後のゼロは、より高いビットにシフトされるだけで、より低いビットにはシフトされなくてもよい。この規則は、再送されたフラグメントを搬送するＭＰＤＵの受信がビットグループ符号化を破損させるのを防ぐために必要とされる。

受信状態をＢＡビットマップにコピーするために、受信側は、スコアボードビットマップの各ビットグループの最後のビットから開始する。ビットが１に設定される場合には、受信側が次のビットに移動し、また、ビットが０の場合、受信側は、ビットグループ内の残りのビットの内容をＢＡビットマップ内の対応するビットにコピーする。例えば、ビットグループ１１４２に関しては、Ｂ４＝０であるため、４つの網掛けビットがＢＡビットマップ上にコピーされ、ビットグループ１１４４に関しては、Ｂ４＝１であるため、Ｂ３がチェックされ、また、Ｂ３＝０であるため、残りの３つの網掛けビットがＢＡビットマップ上にコピーされ、ビットグループ１１４６に関しては、Ｂ４及びＢ３が１に設定されるとともにＢ２が０に設定されるため、Ｂ１及びＢ０がＢＡビットマップ上にコピーされ、ビットグループ１１４８に関しては、Ｂ４、Ｂ３及びＢ２が１に設定されるとともにＢ１が０に設定されるため、Ｂ０がＢＡビットマップ上にコピーされる。フラグメントの数及び受信状態のいずれもスコアボードビットマップ自体に記録されるため、ＦＳＴに必要なメモリが保存されるだけでなく、ＢＡビットマップを構築するプロセスがより高速になり得る。これは、スコアボードビットマップからコピーされるべきビット数を決定するために別個のＦＳＴテーブルを参照する必要がないからである。

図１２Ａは、レベル３のフラグメンテーションを伴う任意の実際のフレーム交換の前に２つの無線デバイス間のレベル３のフラグメンテーションを伴うＨＴ即時ブロックＡｃｋ合意をネゴシエートするために使用されるＡＤＤＢＡ要求／応答交換１２００を示す。発信側は、ＡＤＤＢＡ要求フレーム１２０２において、ＭＳＤＵフィールドごとに最大フラグメントを設定することによって、ＭＳＤＵごとに許可されるフラグメントの最大数が１６になることを要求する。リソース制約に起因して、受信側は、ＡＤＤＢＡ応答フレーム１２０４の単一ＭＳＤＵ当たりの最大フラグメントフィールドに示されるように、ＭＳＤＵごとに最大６つのフラグメントをサポートすることしかできない。

図１２Ｂ、図１２Ｃ、及び、図１２Ｄは、第３の実施形態による効率的なブロックＡｃｋメカニズムを利用するフレーム交換シーケンス１２１０の一例を示す。この例では、ＷｉｎＳｉｚｅＯ、ＷｉｎＳｉｚｅＲ、及び、ＢｉｔｍａｐＬｅｎの値が６４に等しい。発信側は、現在の送信ウィンドウで送信されているＭＳＤＵ内に存在するフラグメント数を追跡するためにフラグメントサイズテーブル（ＦＳＴ）１２１２を保持してもよいが、これは随意的である。それは、発信側が各ＭＳＤＵ内のフラグメントの数に関する情報をその送信バッファを参照することによって容易に得ることができるからである。発信側は、ＳＮ＝１を伴うＭＳＤＵの６つのそれぞれのフラグメントを搬送する６つのＭＰＤＵ、ＳＮ＝２を伴うフラグメント化されないＭＳＤＵを搬送する１つのＭＰＤＵ、ＳＮ＝３を伴うＭＳＤＵの３つのそれぞれのフラグメントを搬送する３つのＭＰＤＵ、及び、ＳＮ４〜２０を伴うフラグメント化されないＭＳＤＵを搬送する１７個のＭＳＤＵを発端として２７個のＭＰＤＵを集約するＡ−ＭＰＤＵ１２１３を送信することによってフレーム交換を開始する。それに応じてＦＳＴ１２１２の全ての関連するエントリも更新される。

この送信において、受信側は、６個のＭＰＤＵ、すなわち、ＳＮ＝１を伴うＭＳＤＵの最初の５つのフラグメントを搬送するＭＰＤＵ１２１４、１２１５、１２１６、１２１７、１２１８及びＳＮ＝３を伴うＭＳＤＵの最後のフラグメントを搬送するＭＰＤＵ１２１９の受信に失敗する。この例では、ＳＮ＝１である。第３の実施形態によれば、フラグメント数は発信側によってＭＰＤＵに明示的に示されず、そのため、受信側は、ＭＰＤＵのシーケンス制御フィールド内のフレーム制御フィールド及びフラグメント番号フィールドにおけるより多くのフラグメントビットを使用して、ＭＳＤＵに存在するフラグメント数を決定する必要がある。より多くのフラグメントビットが０に設定されるとともにＭＰＤＵにおいてフラグメント番号フィールドも０であれば、受信側は、ＭＰＤＵがフラグメント化されないＭＳＤＵを搬送することを示す。より多くのフラグメントビットが１に設定されれば、受信側は、ＭＰＤＵがフラグメント化されたＭＳＤＵを搬送するとともにＭＳＤＵのより多くのフラグメントが存在することを示す。より多くのフラグメントビットが０に設定されるとともにＭＰＤＵにおいてフラグメント番号フィールドがゼロでない場合、受信側は、ＭＰＤＵがＭＳＤＵの最後のフラグメントを搬送することを示す。しかしながら、これの１つの欠点は、受信側がＭＳＤＵの最後のフラグメントを受信してＭＳＤＵに存在するフラグメントの数を絶対的な確実性で決定する必要があるという点である。

レベル３のフラグメンテーションを含む新たなＨＴ即時ブロックＡｃｋがセットアップされるたびに、受信側は、各ＭＰＤＵの受信状態を記録するためにスコアボードビットマップ１２３０を形成する。ＭＳＤＵごとに許可される最大フラグメント数が６としてネゴシエートされるため、１つのＭＳＤＵのためにスコアボードビットマップで７ビットのビットグループがそれぞれ必要とされ、全てのビットが形成時に０に初期化される。Ａ−ＭＰＤＵ１２１３を受信する際、受信側は、それぞれの個々のＭＰＤＵの受信状態をＡ−ＭＰＤＵに記録し始める。ＳＮ＝１を伴うＭＳＤＵの最初の５つのフラグメントが失われても、最後のフラグメントが正しく受信されるため、受信側は、フラグメント数を６として正しく決定することができ、フラグメント数＝６を示すために第１のビットグループ１２３１を続けて符号化するとともに、６番目のフラグメントに対応する６番目のビットを１に設定する。

ＳＮ＝２を伴うフラグメント化されないＭＳＤＵを搬送するＭＰＤＵを受信する際、受信側は、フラグメント数＝１を示すために第２のビットグループ１２３３を同様に符号化するとともに最初のビットを１に設定する。ＳＮ＝３を伴うＭＳＤＵに関するシナリオは少し異なり、最初の２つのフラグメントが受信される場合でも、３番目及び最後のフラグメント１２１９が受信されないため、受信側は、ＭＳＤＵに存在するフラグメントの数を決定することができず、したがって、第３のビットグループ１２３５を全て０に設定する。ＳＮ４〜２０を伴うＭＳＤＵに対応するビットグループも同様にして符号化される。Ａ−ＭＰＤＵ１２１３の終わりに達した時点で、第１のビットグループ１２３１を発端として、受信側は前述のようにＢＡビットマップ１２４０を形成し始める。ビットグループ１２３１の最後のビット１２３２が０に設定されるため、ビットグループ１２３１の最初の６個のビットは、ＢＡビットマップ１２４０の最初の６個のビット上にコピーされる。

次に、ビットグループ１２３３内の０に設定される最後のビット１２３４の位置に基づき、最初のビットがＢＡビットマップ内の次のビット上にコピーされる。同様に、ビットグループ１２３５の最後のビット１２３６が０に設定されるため、たまたま全て０になるビットグループ１２３５の最初の６つのビットは、１２４２により示されるようにＢＡビットマップの次の６つのビット上にコピーされる。残りのＢＡビットマップも同様の方法で作成されてブロックＡｃｋフレーム１２４８内の発信側に送信される。発信側でのＢＡビットマップ１２４０の復号は、第１の実施形態で説明されたものと同じである。発信側は、ＳＮ＝３を伴うＭＳＤＵのシーケンス番号境界にある６つの連続するゼロ１２４２を受信すると、これを、受信側によって受信され損ねるＳＮ＝３を伴うＭＳＤＵの３つの全てのフラグメントとして復号し、それらを次のＡ−ＭＰＤＵ１２５０で再送する。これは、発信側がフラグメント１、２をそれらが受信側により受信された場合であっても再送する必要があるため、幾つかの非効率性をもたらすが、この規則は、発信者が残りのＢＡビットマップを正しく復号できるようにするために必要である。

発信側は、ブロックＡｃｋ１２４８の内容に基づき、ＳＮ＝１を伴うＭＳＤＵに対応する５つの失敗したＭＰＤＵ、ＳＮ＝３を伴うＭＳＤＵに対応する３つの失敗したＭＰＤＵ、及び、ＳＮ２１〜３０を伴うフラグメント化されないＭＳＤＵを搬送する１０個の新たなＭＰＤＵを集約する次のＡ−ＭＰＤＵ１２５０を送信する。この送信において、受信側は、ＳＮ＝３を伴うＭＳＤＵの最初の２つのフラグメントを搬送する２つのＭＰＤＵ１２５２、１２５４を受信し損なう。しかしながら、ＳＮ＝３を伴うＭＳＤＵの最後のフラグメントが受信されるため、受信側は、この時点で、ＳＮ＝３を伴うＭＳＤＵ内のフラグメントの数を正しく決定することができる。受信されたＭＰＤＵは、先に説明した符号化方式にしたがってスコアボードビットマップ１２６０に記録される。第１のビットグループ１２６２及び第３のビットグループ１２６４はいずれも、それぞれのフラグメントの受信を反映するように更新される。ＢＡビットマップ１２７０は、スコアボードビットマップの内容に基づいて形成され、ブロックＡｃｋフレーム１２８０における発信側に送信される。ＳＮ＝３を伴うＭＳＤＵのために割り当てられる３ビット１２７２は、この時点で、ＭＳＤＵ内のフラグメント数を正しく反映する。ＦＳＴを参照することによって、発信側は受信されたＢＡ Ｂｉｔｍａｐを正しく復号できる。

＜第４実施形態＞
図６Ａに示されるようにＭＡＣヘッダにおけるシーケンス制御フィールド内のフラグメント番号フィールドの２ビットを使用して単一ＭＳＤＵ当たりのフラグメント数を示すことができる場合でも、これは、単一ＭＳＤＵ当たりのフラグメント数を４に制限する。第４の実施形態によれば、フラグメント数は、ＨＥバリアントＨＴ制御フィールドの集約制御（Ａ−制御）サブフィールド内の制御サブフィールドのうちの１つを使用して示される。

図１３Ａは、ＩＥＥＥ８０２．１１ａｘで規定されるＨＥバリアントＨＴ制御フィールド１３００のＡ−制御サブフィールドのフォーマットを示す。Ａ−制御サブフィールドは、一連の１つ以上の制御サブフィールド１３１０、．．．、１３２０を含み、その後に、Ａ−制御サブフィールドの長さを３０ビットに等しくするために０のシーケンスに設定される随意的なパディングサブフィールド１３３０が続く。各制御サブフィールドは、固定長制御ＩＤサブフィールドと可変長制御情報サブフィールドとにより形成される。制御ＩＤサブフィールドは、制御情報サブフィールドで搬送される情報のタイプを示し、一方、制御情報サブフィールドの長さは、留保されない制御ＩＤサブフィールドのそれぞれの値ごとに固定される。

図１３Ｂは、第４の実施形態によるフラグメント数を示すために使用される制御サブフィールド１３５０のフォーマットを示す。この制御サブフィールドは、制御ＩＤサブフィールド１３５２のほかに、４ビット長フラグメント数サブフィールド１３５４を搬送する。第４の実施形態によれば、フラグメント化されたＭＳＤＵを搬送する各ＭＰＤＵは、同じＡ−ＭＰＤＵで送信されるＭＳＤＵのフラグメント数に設定されるフラグメント数フィールド１３５４を伴ってＭＡＣヘッダ内に制御サブフィールド１３５０を含む。同じＡ−ＭＰＤＵで送信されるＭＳＤＵの全てのフラグメントは、フラグメント数フィールド１３５４で同じ値を搬送する。これにより、受信側は、単一のフラグメントだけが受信される場合でも、正しい数のビットをＢＡビットマップ内のＭＳＤＵに正確に割り当てることができる。

＜第５の実施形態＞
第５の実施形態は、ＢＡビットマップのための更なる他の符号化を導入する。ＢＡビットマップのビットは２つのタイプにグループ化される。
１）タイプ１のブロックは、少なくとも１つのフラグメントが受信されて少なくとも１つのフラグメントが受信されないときにフラグメント化されたＭＳＤＵのフラグメントの受信状態を示すために使用される。タイプ１のブロックのサイズは、Ａ−ＭＤＰＵ（Ｘ）で送信されることが許可されるＭＳＤＵの最大フラグメント数に依存する。タイプ１のブロックは長さがＸ＋１ビットである。
２）タイプ２のブロックは、フラグメントがいずれも受信されない又はフラグメントの全てが受信されるときにフラグメント化されないＭＳＤＵ又はフラグメント化されたＭＳＤＵの受信状態を示すために使用される。タイプ２のブロックは長さが常に２ビットである。

第５の実施形態は、Ａ−ＭＤＰＵで送信されることが許可される最大フラグメント数が４に固定されることを想定する。図１４Ａは、ＢＡビットマップブロック１４００の一般的な構造を示す。ブロックタイプとして知られる最下位ビット（ＬＳＢ：Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）１４１０はブロックのタイプを示し、一方、可変サイズのＡｃｋビットフィールド１４２０はフレームの受信状態を示す。

図１４Ｂは、タイプ１のブロック１４３０の構造を示す。タイプ１のブロックでは、ブロックタイプ１４４０が１に設定され、一方、タイプ１のブロックのＡｃｋビットフィールド１４５０の残りの４つのビットは、個々のフラグメントの受信状態を示すために使用される。図１４Ｃは、タイプ２のブロック１４６０の構造を示す。タイプ２のブロックでは、ブロックタイプ１４７０が０に設定され、第２ビット１４８０がＭＳＤＵ全体の受信状態を示す。フラグメント化されないＭＳＤＵが受信されない場合或いは更にはフラグメント化されたＭＳＤＵの単一のフラグメントが受信されない場合には、第２のビット１４８０が０に設定される。フラグメント化されないＭＳＤＵが受信される或いはフラグメント化されたＭＳＤＵの全てのフラグメントが受信される場合には、第２のビット１４８０が１に設定される。

スコアボードビットマップ及びフラグメントサイズテーブルに関しては、先の実施形態で導入された方法のいずれかを使用して、フレームの受信状態を記録してもよく或いは単一ＭＳＤＵ当たりのフラグメント数を記録してもよい。Ａ−ＭＰＤＵの終わりに達して受信側がＢＡビットマップを形成すると、スコアボードビットマップをＴｙｐｅ１又はＴｙｐｅ２のブロックに符号化するために何らかの種類の変換が必要とされる。スコアボードビットマップで設定されるビットとフラグメント数の知識とに基づいて、受信側は、前述の規則にしたがってそれぞれのＭＳＤＵごとに使用されるべき適切なタイプのブロックを選択する。

しかしながら、第５の実施形態は、第５の実施形態で導入されたＢＡビットマップ符号化のために特別に形成されるスコアボードビットマップのための新たな符号化を導入する。これは、ＭＳＤＵ当たりの最大フラグメントが４に固定される例に関して図１５Ａに示される単一ＭＳＤＵ当たりの最大フラグメント＋１に等しいビット数、この場合は５が、単一ＭＳＤＵ当たりのスコアボードビットマップ１５００に割り当てられる。ＢＡビットマップに関して規定される同じ符号化がスコアボードビットマップにおいても使用される。最初にスコアボードのビットマップ内の全てのビットが０に設定され、このことは、ＭＳＤＵごとの各５ビットブロックの最初の２つのビットを受信されないＭＳＤＵを示すタイプ２のブロックであると解釈できることを意味する。

フラグメント化されないＭＳＤＵが受信される場合には、対応するブロックの第２のビット１４８０が１に設定される。ブロック内の残りの３ビットは未使用のままである。１５０６及び１５０８はそのようなタイプ２のブロックの例である。フラグメント化されたＭＳＤＵが受信されるとともに、対応するビットマップブロックがタイプ２のブロックを示す場合には、タイプ１のブロックを示すために対応するブロックのブロックタイプビットが１に設定され、また、フラグメントに対応するＡｃｋビットフィールド１４５０内のビットも１に設定される。その後、ＭＳＤＵの最後のフラグメントが受信されてＭＳＤＵの他の全てのフラグメントも受信されてしまうと、ブロックタイプビットを０に設定することによってブロックがタイプ２のブロックに変換される。この場合、第２のビットは（第１のフラグメントが受信されたことを示すために）既に１に設定されるため、ビットマップブロックは、ＭＳＤＵの全てのフラグメントが受信されたことを正しく反映する。タイプ１のブロックからタイプ２のブロックへの変換は、対応するＭＳＤＵの全てのフラグメントが受信されたと決定される場合にのみ可能である。全てのフラグメントが受信されたかどうかを受信側が決定できない場合には、タイプ１のブロックがそのまま残される。

Ａ−ＭＰＤＵの終わりに達する際に（暗黙的なブロックＡｃｋ要求）或いはブロックＡｃｋＲｅｑフレームを受信する際に（明示的なブロックＡｃｋ要求）受信側がＢＡビットマップ１５１０を形成すると、受信側は、単に、スコアボードビットマップからの関連するビットをＢＡビットマップ内の対応する位置にコピーする。タイプ１のブロックの場合、５ビット全てがＢＡビットマップ（例えば、１５１２、１５１４）上にコピーされ、これに対し、タイプ２のブロックの場合には、最初の２ビットのみがコピーされる（例えば、１５１６、１５１８）。ＢＡビットマップの終わりに近づく際に、スコアボードビットマップ内の次のブロック上にその全体をコピーするためにＢＡビットマップに十分なビットが残っていないことが発見される場合、ＢＡビットマップ内の残りのビットが全て０に設定される。一例として、ＳｃｏｒｅＢｏａｒｄビットマップにコピーされるべき次のブロックがタイプ１のブロックであってＢＡビットマップの最後に２ビットしか残らない場合には、２つのビットがいずれも０（例えば、１５１９）に設定される。

第１のビット１５１１を発端として第５の符号化にしたがって符号化されるＢＡビットマップ１５１０を含むブロックＡｃｋフレームを発信側が受信すると、発信側は、第１のブロック１５１２がタイプ１のブロックであるかタイプ２のブロックであるかを決定する。ブロックタイプビット１５１１が１に設定されるため、１５１２がタイプ１のブロックであると決定され、次の４つのビットがフラグメントの受信状態を示す。同様に、次のビット１５１３は、次のブロック１５１４もタイプ１のブロックであることを示す。５ビット前進すると、ビット１５１５は、ブロック１５１６がタイプ２のブロックであることを示し、したがって、次のビットは、ＭＳＤＵ全体の受信状態を示す。１５１６はタイプ２のブロックであるため、次のビット１５１７は、同様にタイプ２のブロックであると決定される次のブロック１５１８のブロックタイプを決定する。

図１６Ａ、図１６Ｂ、及び、図１６Ｃは、第５の実施形態による効率的なブロックＡｃｋメカニズムを利用するフレーム交換シーケンス１６００の一例を示す。この例では、ＷｉｎＳｉｚｅＯ、ＷｉｎＳｉｚｅＲ、及び、ＢｉｔｍａｐＬｅｎの値が６４に等しい。発信側は、ＳＮ＝１を伴うＭＳＤＵの４つのそれぞれのフラグメントを搬送する４つのＭＰＤＵ、ＳＮ２〜６を伴うフラグメント化されないＭＳＤＵを搬送する５つのＭＰＤＵ、ＳＮ＝７を伴うＭＳＤＵの２つのそれぞれのフラグメントを搬送する２つのＭＰＤＵ、及び、ＳＮ８〜３０を伴うフラグメント化されないＭＳＤＵを搬送する２３個のＭＰＤＵを発端として３４個のＭＰＤＵを集約するＡ−ＭＰＤＵ１６１０を送信することによってフレーム交換を開始する。

この送信において、受信側は、４つのＭＰＤＵ、すなわち、ＳＮ＝１を伴うＭＳＤＵの第２のフラグメントを搬送するＭＰＤＵ１６１１、ＳＮ＝５を伴うフラグメント化されないＭＳＤＵを搬送するＭＰＤＵ１６１２、及び、ＳＮ＝７を伴うＭＳＤＵの２つのフラグメントを搬送するＭＰＤＵ１６１４、１６１６の受信に失敗する。この例では、ＳＮ＝１である。

Ａ−ＭＰＤＵ１６１０を受信する際、受信側は、先に説明したようにＡ−ＭＰＤＵのそれぞれの個々のＭＰＤＵの受信状態をスコアボードビットマップに記録し始める。ＳＮ＝１を伴うＭＳＤＵの３つの受信されたフラグメントは、タイプ１のブロックとしてスコアボードビットマップに記録され、この場合、Ａｃｋビットフィールド１４５０内の第１、第３及び第４のビットが１に設定される。同様に、ＳＮ＝２〜４及びＳＮ＝６を伴うフラグメント化されないＭＳＤＵの受信状態がタイプ２のブロックとして記録され、この場合、それぞれのＡｃｋビット１４８０が１に設定される。ＳＮ＝５を伴うＭＳＤＵ及びＳＮ＝７を伴うＭＳＤＵの両方のＭＰＤＵに関しては、対応するスコアボードブロックがタイプ２のブロックとして記録され、この場合、それぞれのＡｃｋビット１４８０が０に設定される。残りのＭＳＤＵも同様の方法でスコアボードビットマップに記録される。Ａ−ＭＰＤＵ１６１０の終わりに達すると、スコアボード１６２０の関連する内容がＢＡビットマップ１６３０上に一度に１ブロックずつコピーされる。タイプ１のブロック、例えば１６３２は、ＢＡビットマップ内の５つのビットを占有し、一方、タイプ２のブロックは、例えば１６３４又は１６３６は、２ビットを占有する。ＢＡビットマップが形成された時点で、このＢＡビットマップがブロックＡｃｋフレーム１６３８で発信側に送信される。

発信側がブロックＡｃｋフレーム１６３８を受信した時点で、発信側は先に説明したようにＢＡビットマップ１６３０を復号する。ＢＡビットマップの最初のビットを発端として、発信側は、最初に、Ａｃｋビットを参照する前にブロックタイプを決定して、ＭＰＤＵの受信状態を決定する。発信側は、ＢＡビットマップ１６３０の内容に基づき、ＳＮ＝１及びＳＮ＝５を伴うＭＳＤＵに対応する２つの失敗したＭＰＤＵ、ＳＮ＝７を伴うＭＳＤＵに対応する２つの失敗したＭＰＤＵ、ＳＮ＝３１を伴うフラグメント化されないＭＳＤＵを搬送する１つのＭＰＤＵ、ＳＮ＝３２を伴うＭＳＤＵの３つのそれぞれのフラグメントを搬送する３つのＭＰＤＵ、及び、ＳＮ３３〜４０を伴うフラグメント化されないＭＳＤＵを搬送する８個のＭＰＤＵを集約する次のＡ−ＭＰＤＵ１６４０を送信する。この送信において、受信側は、ＳＮ＝３２を伴うＭＳＤＵの最初及び３番目のフラグメントを搬送する２つのＭＰＤＵ１６４４、１６４６を受信し損なう。

Ａ−ＭＰＤＵ１６４０を受信すると、受信側は、先に説明したようにスコアボードビットマップ１６５０を更新し、例えば、ＳＮ＝３２を伴うＭＳＤＵをタイプ１のブロックとして符号化する一方で、フラグメント化されない全てのＭＳＤＵをタイプ２のブロックとして符号化する。特に興味深いのは、ＳＮ＝１を伴うＭＳＤＵに対応するブロック１６５２である。このブロックは、以前はタイプ１のブロックとして符号化されたが、欠けている第２のフラグメントがＡ−ＭＰＤＵ１６４０で受信されるため、Ａｃｋビットフィールド１４５０の４つの全てのビットがこの時点で１であり、そのため、ブロックはタイプ２のブロックとして再符号化され、この場合、全てのフラグメントが受信されてしまったことを示すためにＡｃｋビット１６５４が１に設定される。Ａ−ＭＰＤＵ１６４０の終わりに達すると、スコアボード１６５０の関連する内容が、一度に１ブロックずつＢＡビットマップ１６６０上にコピーされて、ブロックＡｃｋフレーム１６６８における発信側に送信される。

ブロックＡｃｋフレーム１６６８を受信すると、発信側は続けてＢＡビットマップ１６６０を復号する。タイプ２のブロック１６６２、１６６４は、ＳＮ＝１及びＳＮ＝７を伴うＭＳＤＵの全てのフラグメントが受信されてしまったことを示すように復号される。同様に、タイプ１のブロック１６６６は、ＳＮ＝３２を伴うＭＳＤＵの第２のフラグメントのみが受信されてしまったことを示すように復号され、以下同様である。

＜無線通信システム＞
図１７は、本開示において説明される効率的なブロックａｃｋメカニズムを実現するために、レベル３のフラグメンテーションをサポートするブロックａｃｋ合意の発信側である無線デバイスによって実施されるべき方法１７００の一例を示す。ステップの幾つかは、随意的であり、対応する機能がデバイスによってサポートされる場合にのみ実施される。１７１０において、適用可能であれば、レベル３のフラグメンテーションをサポートするブロックＡｃｋ合意をセットアップする際に、他のパラメータブロックａｃｋ合意と共に、発信側は、同じＡ−ＭＰＤＵで送信されることが許可されるＭＳＤＵのフラグメントの最大数もネゴシエートする。１７２０において、フラグメント化されるＭＳＤＵを搬送するそれぞれのＭＰＤＵごとに発信側がフラグメントサイズテーブル（ＦＳＴ）を保持する場合、発信側は、ＦＳＴの対応するエントリにＭＳＤＵのフラグメントの総数も記録する。１７３０において、適用可能であれば、発信側は、ＭＰＤＵのＭＡＣヘッダ内の指定されたフィールド（例えば、シーケンス制御フィールド内のフラグメント数フィールド又はＨＥバリアントＨＴ制御フィールドのＡ−制御サブフィールドなど）にあるＭＳＤＵのフラグメントの総数も示す。その後、１７４０において、レベル３のフラグメンテーションを伴うＭＰＤＵを搬送するＡ−ＭＰＤＵに応じて送信されるブロックＡｃｋフレームを受信すると、発信側は、実施されるビットマップ符号化方式にしたがってブロックＡｃｋフレームを含むＢＡビットマップを復号する。

図１８は、本開示において説明される効率的なブロックａｃｋメカニズムを実現するために、レベル３のフラグメンテーションをサポートするブロックａｃｋ合意の受信側である無線デバイスによって実施されるべき方法１８００の一例を示す。ステップの幾つかは、随意的であり、対応する機能がデバイスによってサポートされる場合にのみ実施される。１８１０において、適用可能であれば、レベル３のフラグメンテーションをサポートするブロックＡｃｋ合意をセットアップする際に、他のパラメータブロックａｃｋ合意と共に、受信側は、同じＡ−ＭＰＤＵで送信されることが許可されるＭＳＤＵのフラグメントの最大数もネゴシエートする。また、受信側は、スコアボードビットマップ、存在する場合にはフラグメントサイズテーブル（ＦＳＴ）、及び、ブロックａｃｋ合意に関連する他の変数も初期化する。

１８２０において、レベル３のフラグメンテーションを伴うＭＰＤＵを搬送するＡ−ＭＰＤＵを受信すると、ＦＳＴの対応するエントリにおいて、フラグメント化されるＭＳＤＵを搬送するそれぞれのＭＰＤＵごとに、受信側がＭＳＤＵに対応するフラグメント数を記録する。この情報は、ＭＡＣヘッダ内の関連するフィールド（例えば、シーケンス制御フィールド内又はＨＥバリアントＨＴ制御フィールドのＡ−制御サブフィールド内のフラグメント数フィールドなど）に基づいてもよく、或いは、Ｍａｃヘッダのフレーム制御フィールド内のより多くのフラグメントビットの受信側の観測に基づいてもよい。１８３０において、受信側は、各ＭＰＤＵの受信状態を、実施符号化方式にしたがってスコアボードビットマップ内の対応するビットに記録する。１８４０において、受信側は、実施される符号化方式のようにスコアボードビットマップの関連部分にしたがって符号化されるＢＡビットマップフィールドを含むブロックＡｃｋフレームを構築する。最後に、１８５０において、受信側はブロックＡｃｋフレームを送信する。

＜発信側の構成＞
図１９Ａは、発信側としての機能を果たす無線デバイス１９００の一例のブロック図である。発信側は、図１のＳＴＡ又はＡＰのいずれか１つであってもよい。無線デバイス１９００は、送信部１９０１、フレーム生成部１９０３、復号部１９０７、及び、受信部１９０９を備える。フレーム生成部１９０３は、上層ＭＳＤＵ又はＭＭＰＤＵからＡ−ＭＰＤＵを生成する。また、Ａ−ＭＰＤＵは、フラグメント化されたＭＳＤＵ又はＭＭＰＤＵを含んでもよい。送信部１９０１は、生成されたＡ−ＭＰＤＵを１つ以上の受信側に送信する。受信部１９０９は、各受信側からブロックＡｃｋフレームを受信する。ブロックＡｃｋフレームはビットマップフィールドを含む。そして、復号部１９０７は、ブロックＡｃｋフレーム内のビットマップフィールドを復号して、復号された情報をフレーム生成部１９０３に送る。フレーム生成部１９０３は、復号部１９０７からの復号されたビットマップ情報に基づいて、うまく送信されたＭＰＤＵを送信キューから削除し、一方、その送信が成功しなかったＭＰＤＵは送信部１９０１から再送信される。

図１９Ｂは、図１のＳＴＡ又はＡＰのいずれか１つであってもよい発信側としての機能を果たす無線デバイス１９００の一例の詳細なブロック図である。無線デバイス１９００は、メモリ１９２０、二次記憶装置１９４０、及び、１つ以上の無線通信インタフェース１９５０に結合される中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１９３０を備える。二次記憶装置１９４０は、関連する命令コード、データなどを永久に記憶するために使用される不揮発性コンピュータ可読記憶媒体であってもよい。起動時に、ＣＰＵ１９３０は、実行のために命令コード及び関連データを揮発性メモリ１９２０にコピーしてもよい。命令コードは、無線デバイス１９００の動作に必要なオペレーティングシステム、ユーザアプリケーション、デバイスドライバ、実行コードなどであってもよい。また、無線デバイス１９００は、電源１９１０、例えばリチウムイオンバッテリ又はコインセルバッテリなどを備えてもよく、又は、主電源であってもよい。

無線通信インタフェース１９５０は、セルラー通信用のインタフェース、又は、Ｚｉｇｂｅｅなどの短距離通信プロトコル用のインタフェースを備えてもよく、或いは、ＷＬＡＮインタフェースであってもよい。無線インタフェース１９５０は、ＭＡＣモジュール１９５２及びＰＨＹモジュール１９６０を更に備えてもよい。他のサブモジュールの中でも、ＭＡＣモジュール１９５２は、フレームの送信に必要な様々なＭＡＣレベル機能に関与する送信モジュール１９５４を備えてもよい。ＭＡＣモジュール１９５２は、フレームがうまく送信されるまで又はフレームがそれらが削除されるそれらの寿命に達するまで、上層から受信されるデータフレーム及びＭＡＣ層内で生成されるフレームを記憶するために使用される送信バッファ１９５６を更に備えてもよい。ＰＨＹモジュールは、送信／受信信号との間でのＭＡＣモジュールデータの変換に関与する。また、無線インタフェースは、ＰＨＹモジュールを介して、無線媒体上の／無線媒体からの無線通信信号の実際の送信／受信に関与する１つ以上のアンテナ１９７０に結合されてもよい。

図２０は、図１９Ｂの送信モジュール１９５４をより詳細に示す。他のサブモジュールの中でも、送信モジュール１９５４は、上層から受信されるＭＳＤＵに対して及びＭＡＣ層内で生成されるＭＭＰＤＵに対して固有のシーケンス番号を割り当てるシーケンス番号生成部２０００を備えてもよい。また、送信モジュール１９５４はフラグメンテーションモジュール２０１０を備えてもよく、フラグメンテーションモジュール２０１０は、ＭＳＤＵ又はＭＭＰＤＵがフラグメント化される必要があるかどうかを決定することに関与し、そうであれば、フラグメントの数及びフラグメントのサイズも決定する。また、フラグメンテーションモジュール２０１０は、フラグメントにフラグメント番号を割り当てる。適用可能な場合、フラグメンテーションモジュール２０１０は、フラグメントを搬送する各ＭＰＤＵのフラグメント数フィールド６０２も更新する。

また、送信モジュール１９５４は、送信されたＭＳＤＵ内のフラグメント数を追跡するために１つ以上のフラグメントサイズテーブル２０３０を保持してもよい。送信モジュール１９５４は、ＭＳＤＵ及びフラグメントをＡ−ＭＰＤＵに集約するフレーム集約モジュール２０２０を更に備えてもよい。時間になると、ＭＡＣ層はＡ−ＭＰＤＵを送信のためにＰＨＹ層へ送る。また、送信モジュール１９５４は、実施された復号方式にしたがって受信されるブロックＡｃｋフレームのＢＡビットマップを復号することに関与するＢＡビットマップ復号モジュール２０４０を備えてもよい。ＭＳＤＵ又はＭＭＰＤＵの全てのフラグメントが受信側によって受信されたことをＢＡビットマップが示す場合には、ＭＳＤＵ又はＭＭＰＤＵが送信バッファ１９５６から削除される。さもなければ、受信されないフラグメントを再送する必要がある。

特定の実施形態では、オペレーティングシステムがリアルタイムオペレーティングシステム（ＲＴＯＳ：Ｒｅａｌ Ｔｉｍｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を備え、ユーザアプリケーションがウェブブラウザ又はスマートフォンアプリを備え、デバイスドライバがＷＬＡＮドライバを備え、また、実行コードは、ＣＰＵ１９３０により実行されるときに方法１７００を実行させるコードを備えてもよい。フラグメントサイズテーブル２０３０は、フラグメント数の記録を保持するために１７２０で使用される。ＢＡビットマップ復号部２０４０は、受信されたＢＡビットマップを復号するための復号部として１７４０で使用される。

発信側１９００は、分かりやすくするために図１９Ｂ及び図２０には図示されない多くの他の構成要素を備えてもよい。本開示に最も関連する構成要素のみが図示されている。

＜受信側の構成＞
図２１Ａは、受信側としての機能を果たす無線デバイス２１００の一例のブロック図である。受信側は、図１のＳＴＡ又はＡＰのいずれか１つであってもよい。無線デバイス２１００は、受信部２１０９、メモリ２１０７、肯定応答生成部２１０３、及び、送信部２１０１を備える。受信部２１０９は、発信側から複数のフレームを受信する。そして、各フレームのペイロードは、フラグメント化されたパケット又はフラグメント化されないパケットのいずれか或いはそれらの組み合わせから成ってもよい。メモリ２１０７は、複数のフレームのそれぞれの受信状態を記録する。肯定応答生成部２１０３は、フレームの受信状態を示すために使用される少なくとも１つのビットマップフィールドを含むブロック肯定応答（ブロックＡｃｋ）フレームを生成する。パケットのためのビットマップフィールドに割り当てられるビット数は可変であってもよい。送信部２１０１は、肯定応答生成部２１０３により指示されるときにブロックＡｃｋフレームを送信する。

図２１Ｂは、図１のＳＴＡ又はＡＰのいずれか１つであってもよい受信側としての機能を果たす無線デバイス２１００の一例の詳細なブロック図である。無線デバイス２１００は、メモリ２１２０、二次記憶装置２１４０、及び、１つ以上の無線通信インタフェース２１５０に結合される中央処理ユニット（ＣＰＵ）２１３０を備える。二次記憶装置２１４０は、関連する命令コード、データなどを永久に記憶するために使用される不揮発性コンピュータ可読記憶媒体であってもよい。起動時に、ＣＰＵ２１３０は、実行のために命令コード及び関連データを揮発性メモリ２１２０にコピーしてもよい。命令コードは、無線デバイス２１００の動作に必要なオペレーティングシステム、ユーザアプリケーション、デバイスドライバ、実行コードなどであってもよい。また、無線デバイス２１００は、電源２１１０、例えばリチウムイオンバッテリ又はコインセルバッテリなどを備えてもよく、又は、主電源であってもよい。

無線通信インタフェース２１５０は、セルラー通信用のインタフェース、又は、Ｚｉｇｂｅｅなどの短距離通信プロトコル用のインタフェースを備えてもよく、或いは、ＷＬＡＮインタフェースであってもよい。無線インタフェース２１５０は、ＭＡＣモジュール２１５２及びＰＨＹモジュール２１６０を更に備えてもよい。他のサブモジュールの中でも、ＭＡＣモジュール２１５２は、フレームの受信に必要な様々なＭＡＣレベル機能に関与する受信モジュール２１５４を備えてもよい。ＭＡＣモジュール２１５２は、他の無線デバイスから受信されるフレームをそれらがＭＡＣ層内で処理される又は関連する上層に送られる準備が整うまで記憶するために使用される受信バッファ２１５６を更に備えてもよい。

図２２は、図２１Ｂの受信モジュール２１５４を更に詳しく示す。他のサブモジュールの中でも、受信モジュール２１５４は、受信されたＡ−ＭＰＤＵから個々のＭＰＤＵを抽出することに関与するフレーム分解モジュールを備えてもよい。また、受信モジュール２１５４は、受信されたフラグメントをそれぞれのＭＳＤＵへと再結合するデフラグメンテーション処理を実行するデフラグメンテーションモジュール２２１０を備えてもよい。ＭＳＤＵの全てのフラグメントが受信された場合には、ＭＳＤＵがそれぞれの上層に送られてもよい。しかしながら、以前のＭＳＤＵのフラグメントの一部の受信失敗に起因して後の時点で受信されたＭＳＤＵが最初に再結合されることが時折発生する場合がある。上層プロトコルが受信されたＭＳＤＵを正しい順序で受信モジュールに転送することを要求する場合、受信モジュール２１５４は、受信されたＭＳＤＵの並べ替えを実行する必要がある。この目的のために、受信モジュール２１５４が受信並び替えモジュール２２００を備えてもよい。

また、受信モジュール２１５４は、スコアボードコンテキストを各ブロックＡｃｋ合意ごとに１つずつ記憶するための１つ以上のメモリユニット２２４０を備えてもよい。中でも、レベル３のフラグメンテーションを含むブロックａｃｋ合意が受信側としての無線デバイス２１００と共に確立されたときに入力ＭＳＤＵの受信状態を記録するために使用される１つ以上のＬ３スコアボードビットマップが存在してもよい。また、受信モジュール２１５４は、実施された符号化方式にしたがってＢＡビットマップ上へＭＳＤＵの受信状態を符号化することに関与するＢＡビットマップ符号化モジュール２２５０を備えてもよい。適用可能であれば、受信モジュール２１５４は、受信されたＭＳＤＵにフラグメント数を記憶するために１つ以上のフラグメントサイズテーブル２２３０を記憶してもよい。

特定の実施形態では、オペレーティングシステムがリアルタイムオペレーティングシステム（ＲＴＯＳ）を備え、ユーザアプリケーションがウェブブラウザ又はスマートフォンアプリを備え、デバイスドライバがＷＬＡＮドライバを備え、また、実行コードは、ＣＰＵ２１３０により実行されるときに方法１８００を実行させるコードを備えてもよい。フラグメントサイズテーブル２２３０は、フラグメント数の記録を保持するために１８２０で使用される。スコアボードコンテキスト２２４０内のＬ３スコアボードビットマップが１８３０において使用される。ＢＡビットマップ符号化部２２５０は、送信されるべきＢＡビットマップを符号化するための符号化部として１８４０で使用される。

受信側２１００は、分かりやすくするために図２１Ｂ及び図２２には図示されない多くの他の構成要素を備えてもよい。本開示に最も関連する構成要素のみが図示されている。

無線デバイスはある場合には発信側として他の場合には受信側として作用する幾つかの同時ブロックａｃｋ合意を有することができるため、無線デバイスは、発信側モジュール及び受信側モジュールの両方を同時に実装してもよい。

前述した実施形態では、本開示が一例としてハードウェアにより構成されるが、本開示がハードウェアと協働するソフトウェアによって与えられてもよい。

また、本実施形態の説明で使用される機能ブロックは、一般に、集積回路などのＬＳＩデバイスとして実装される。機能ブロックが個々のチップとして形成されてもよく、或いは、機能ブロックの一部又は全部が単一チップに組み込まれてもよい。ここでは「ＬＳＩ」という用語が使用されるが、集積度に応じて、「ＩＣ」、「システムＬＳＩ」、「スーパーＬＳＩ」、又は、「ウルトラＬＳＩ」という用語が使用されてもよい。ＬＳＩは、これに結合されるデータ入出力を含んでもよい。

また、回路集積は、ＬＳＩに限らず、ＬＳＩ以外の専用回路や汎用プロセッサによって達成されてもよい。ＬＳＩの製造後、プログラム可能なフィールドプログラマブルゲートアレイ（ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩの回路セルの接続及び設定の再構成を可能にする再構成可能プロセッサが使用されてもよい。

ＬＳＩに置き換わる回路集積技術が半導体技術やその技術に由来する他の技術の進歩の結果として現れる場合には、そのような技術を用いて機能ブロックを集積することができる。他の可能性は、バイオテクノロジーなどの適用である。

この開示は、効率的なブロックＡｃｋメカニズムのための無線装置に適用可能である。

１９００ 発信側
１９０１、２１０１ 送信部
１９０３ フレーム生成部
１９０７ 復号部
１９０９、２１０９ 受信部
１９１０、２１１０ 電源
１９２０、２１０７、２１２０ メモリ
１９３０、２１３０ ＣＰＵ
１９４０、２１４０ 二次記憶装置
１９５０、２１５０ 無線インタフェース
１９５２、２１５２ ＭＡＣモジュール
１９５４ 送信モジュール
１９５６ 送信バッファ
１９６０、２１６０ ＰＨＹモジュール
１９７０、２１７０ アンテナ
２０００ シーケンス番号生成部
２０１０ フラグメンテーション
２０２０ フレーム集約
２０３０、２２３０ フラグメントサイズテーブル
２０４０ ＢＡビットマップ復号部
２１００ 受信側
２１０３ 肯定応答生成部
２１５４ 受信モジュール
２１５６ 受信バッファ
２２００ 受信記録
２２１０ デフラグメンテーション
２２２０ フレーム分解
２２４０ スコアボード
２２５０ ＢＡビットマップ符号化部

Claims (12)

1. 送信デバイスから複数のフレームを受信するステップであって、フレームのペイロードがフラグメントされるパケット又はフラグメント化されないパケットのいずれかから成る、ステップと、
   前記フレームの受信状態を記録するステップと、
   前記フレームの受信状態を示すために使用される少なくとも１つのビットマップフィールドを含むブロック肯定応答（ブロックＡｃｋ）フレームを生成するステップであって、パケットのために前記ビットマップフィールドで割り当てられるビット数が可変である、ステップと、
   前記ブロックＡｃｋフレームを送信するステップと、
   を備える通信方法。
2. 前記ビットマップフィールドは、それぞれの受信されるフラグメント化されないパケットごとに１に設定される１ビットと、同じ送信ウィンドウ内で送信されるパケットのフラグメント数に等しいビット数とを含み、前記パケットのそれぞれの受信されるフラグメントごとに１つのビットが１に設定される請求項１に記載の通信方法。
3. 有効なシーケンス番号範囲内の受信されないそれぞれのパケットごとに、前記ビットマップフィールドは、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数に等しい数の連続ビットを更に含み、前記ビットが全て０に設定される請求項２に記載の通信方法。
4. 前記フレームの受信状態を記録する前記ステップは、
   １つの送信ウィンドウ内で送信されることが許可される全てのパケットの受信状態を記録するのに十分大きいビットマップを保持するステップであって、各パケットには、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数に等しい数のビットが割り当てられ、受信されるフレームに対応するビットを１に設定するステップと、
   同じ送信ウィンドウ内で送信されることが許容されるパケットフラグメント数を記録するのに十分大きなテーブルを保持するとともに、受信される各パケットのフラグメント数を前記テーブルの対応するエントリに記録するステップと、
   を更に備える請求項１に記載の通信方法。
5. 前記フレームの受信状態を記録する前記ステップは、
   １つの送信ウィンドウ内で送信されることが許可される全てのパケットの受信状態を記録するのに十分大きいビットマップを保持するステップであって、各パケットには、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数足す１に等しい数のビットが割り当てられ、前記ビットは、パケットが分けられたフラグメント数と各フラグメントの受信状態とを一緒に信号で伝える、ステップ
   を更に備える請求項１に記載の通信方法。
6. 前記ビットマップフィールドが２つのタイプのビットグループから構成され、第１のグループは、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数足す１に等しい数のビットを備えるとともに、少なくとも１つのフラグメントが受信されて少なくとも１つのフラグメントが受信されないときにフラグメント化されるパケットの受信状態を示すために使用され、第２のグループは２つのビットを備え、そのうちの１つのビットは、前記フラグメントの全てが受信される又はいずれも受信されないときにフラグメント化されないパケットの受信状態又はフラグメント化されるパケットの受信状態を示すために使用され、各ビットグループの１つのビットは、前記ビットグループのタイプを示すために使用される請求項１に記載の通信方法。
7. 動作時に、送信デバイスから複数のフレームを受信する受信部であって、フレームのペイロードがフラグメントされるパケット又はフラグメント化されないパケットのいずれかから成る、受信部と、
   前記複数のフレームのそれぞれの受信状態を記録するためのメモリと、
   前記フレームの受信状態を示すために使用される少なくとも１つのビットマップフィールドを含むブロック肯定応答（ブロックＡｃｋ）フレームを生成するための肯定応答生成部であって、パケットのために前記ビットマップフィールドで割り当てられるビット数が可変である、肯定応答生成部と、
   命令時に前記ブロックＡｃｋフレームを送信する送信部と、
   を備える通信装置。
8. 前記ビットマップフィールドは、それぞれの受信されるフラグメント化されないパケットごとに１に設定される１ビットと、同じ送信ウィンドウ内で送信されるパケットのフラグメント数に等しいビット数とを含み、前記パケットのそれぞれの受信されるフラグメントごとに１つのビットが１に設定される請求項７に記載の通信装置。
9. 有効なシーケンス番号範囲内の受信されないそれぞれのパケットごとに、前記ビットマップフィールドは、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数に等しい数の連続ビットを更に含み、前記ビットが全て０に設定される請求項８に記載の通信装置。
10. 前記フレームの受信状態を記録するための前記メモリユニットは、
    １つの送信ウィンドウ内で送信されることが許可される全てのパケットの受信状態を記録するのに十分大きいビットマップであって、各パケットには、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数に等しい数のビットが割り当てられ、受信されるフレームに対応するビットを１に設定する、ビットマップと、
    同じ送信ウィンドウ内で送信されることが許容されるパケットフラグメント数を記録するのに十分大きなテーブルであって、前記テーブルのエントリが受信される各パケットのフラグメント数を記録するために使用される、テーブルと、
    を更に備える請求項７に記載の通信装置。
11. 前記フレームの受信状態を記録する前記メモリユニットは、
    １つの送信ウィンドウ内で送信されることが許可される全てのパケットの受信状態を記録するのに十分大きいビットマップであって、各パケットには、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数足す１に等しい数のビットが割り当てられ、前記ビットは、パケットが分けられたフラグメント数と各フラグメントの受信状態とを一緒に信号で伝える、ビットマップ
    を更に備える、請求項７に記載の通信装置。
12. 前記ビットマップフィールドが２つのタイプのビットグループから構成され、第１のグループは、同じ送信ウィンドウ内で送信されることが許可されるパケットの最大フラグメント数足す１に等しい数のビットを備えるとともに、少なくとも１つのフラグメントが受信されて少なくとも１つのフラグメントが受信されないときにフラグメント化されるパケットの受信状態を示すために使用され、第２のグループは２つのビットを備え、そのうちの１つのビットは、前記フラグメントの全てが受信される又はいずれも受信されないときにフラグメント化されないパケットの受信状態又はフラグメント化されるパケットの受信状態を示すために使用され、各ビットグループの１つのビットは、前記ビットグループのタイプを示すために使用される請求項７に記載の通信装置。

Images