JP2008510351A

JP2008510351A - 共通無線チャネルによって接続された複数の局を含むネットワークにおいてデータパケットに対して確認応答する方法

Info

Publication number: JP2008510351A
Application number: JP2007525496A
Authority: JP
Inventors: グ、ダクィン; タオ、ジフェング; ジャン、ジンユン
Original assignee: Mitsubishi Electric Research Laboratories Inc
Current assignee: Mitsubishi Electric Research Laboratories Inc
Priority date: 2004-08-12
Filing date: 2005-08-02
Publication date: 2008-04-03
Also published as: US20060034247A1; WO2006016541A1; KR100762071B1; KR20070015154A; CN1943157A; US7385976B2; CN100583723C

Abstract

【課題】方法は、共通無線チャネルによって接続された複数の局を含むネットワークにおいてデータパケットに対して確認応答する。
【解決手段】送信局は、受信局に対しブロック確認応答を要求する。送信局は、受信局に対してデータパケットのブロックを送信する。受信局は、正しく受信されたデータパケットの数及び誤って受信されたパケットの数を確定する。そして、受信局は、有効に受信されたデータパケットの数が誤って受信されたデータパケットの数を下回る場合、正しく受信されたデータパケットに対してのみ確認応答し、そうでない場合、誤って受信されたパケットに対してのみ確認応答する。

Description

本発明は、包括的には無線通信ネットワークに関し、特にかかるネットワークにおいて受信パケットに対して確認応答することに関する。

ＩＥＥＥ８０２．１１規格による無線ローカルエリアネットワーク（ＷＬＡＮ）では、セルのアクセスポイント（ＡＰ）が、そのセルに関連する局のすべてに対するパケット伝送を調整する。単一無線チャネル、すなわち周波数帯域を、データ及び制御信号に対し、局からＡＰへのアップリンクと、ＡＰから局へのダウンリンクとの両方が共有する。すべての局がＡＰと通信することができるが、任意の２つの局が互いの通信範囲内にある必要はない。

無線チャネルの伝送レートは、知覚される信号対雑音比（ＳＮＲ）によって変化する可能性がある。たとえば、ＩＥＥＥ８０２．１１ｂ規格の物理層は、１Ｍｂｐｓ、２Ｍｂｐｓ、５．５Ｍｂｐｓ及び１１Ｍｂｐｓでの４つのレートをサポートする。

ＩＥＥＥ８０２．１１確認応答（Acknowledgement）
無線ローカルエリアネットワーク（ＷＬＡＮ）に対する現ＩＥＥＥ８０２．１１規格、「Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications」、Standard, IEEE, August, 1999によれば、受信側は、送信側に対して確認応答（ＡＣＫ）メッセージを送信することにより、データパケットを正しく受信したことに対し明示的に確認応答しなければならない。ＡＣＫメッセージは、先に受信したデータパケットに直接関連するため、非常に単純なフォーマットを有する。

ＩＥＥＥ８０２．１１ｅブロック確認応答（Block Acknowledgement）（ＢｌｏｃｋＡＣＫ）
無線チャネルの使用の効率を向上させるために、ＩＥＥＥ８０２．１１ｅタスクグループ（ＴＧｅ）は、ブロック確認応答技法を開発しており、新たなメッセージのセットを定義する。これについては、ＩＥＥＥ８０２．１１ｅ、「Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Enhancements for Quality of Service (QoS)」、Draft v6, IEEE, November 2003を参照されたい。そこでは、すべてのデータパケットに対する１つの単純なＡＣＫメッセージの代わりに、複数の連続的なデータパケットに対して確認応答するために、単一であるがより複雑なＡＣＫメッセージを使用する。

したがって、ＩＥＥＥ８０２．１１ｅ規格は、ＭＡＣヘッダに追加のＱｏＳ制御フィールドを使用する。そのフィールドは、使用されるＡＣＫポリシのタイプを指定する２ビットＡＣＫポリシサブフィールドを含む。

ＢｌｏｃｋＡＣＫセッションは、確立、データ転送、ＢｌｏｃｋＡＣＫ及び終了の各フェーズから構成される。ブロックデータ転送に先立ち、ＡｄｄＢｌｏｃｋＡＣＫ（ＡＤＤＢＡ）要求及びＡｄｄＢｌｏｃｋＡＣＫ（ＡＤＤＢＡ）応答を交換し、セッションに関与する２つの局の間でパラメータを交渉する。ＢｌｏｃｋＡＣＫタイムアウト値を指定し、それが満了すると、ＢｌｏｃｋＡＣＫセッションは終了する。

表１及び表２は、それぞれＡＤＤＢＡ要求フレーム及びＡＤＤＢＡ応答フレームの内容を示す。各フィールドの詳細な説明については規格を参照されたい。

ＢｌｏｃｋＡＣＫセッションが確立すると、送信側は、短フレーム間隔（short inter-frame space）（ＳＩＦＳ）期間によって区切られたデータパケットのブロックを送信することができる。フローに対してセッション確立を実行し、それは、秒から分、時間又はさらには何日かの期間にわたって何千又は何百万ものパケットに対して続く場合もある。

目立ったデータパケットの確認応答を要求するために、送信側は、受信側にＢｌｏｃｋＡＣＫＲｅｑｕｅｓｔメッセージを送信する。ＢｌｏｃｋＡＣＫシーケンス制御フィールドを、直前の受信したＢｌｏｃｋＡＣＫＲｅｑｕｅｓｔメッセージと同じ値に設定する。ＢｌｏｃｋＡＣＫに含まれるＢｌｏｃｋＡＣＫビットマップフィールドは、１２８オクテットを有し、６４までのＭＡＣサービスデータユニット（MAC service data unit）（ＭＳＤＵ）またはパケットの受信状態を示す。

図１は、ＩＥＥＥ８０２．１１ｅ規格で定義されるようなＢｌｏｃｋＡＣＫＲｅｑメッセージの何バイトかのフォーマット１００を示し、図２は、ＩＥＥＥ８０２．１１ｅ規格で定義されるようなＢｌｏｃｋＡＣＫメッセージの何バイトかのフォーマット２００を示す。すべての図において、それぞれのフィールドの上の数字は、バイト割当てを示す（ここでは、フィールドの上の数字が単にバイトの数を示すように図を変更した）。

ＢｌｏｃｋＡＣＫＲｅｑメッセージ１００は、以下のフィールドを含む。すなわち、ビットフレーム制御１０１、継続時間１０２、受信側アドレス（ＲＡ）１０３、送信側アドレス（ＴＡ）１０４、ＢｌｏｃｋＡＣＫ要求（ＢＡＲ）制御１０５、開始シーケンス制御１０６及びフレームチェックシーケンス（ＦＣＳ）１０７である。

図２は、以下のフィールドを含む。すなわち、フレーム制御２０１、継続時間２０２、受信側アドレス（ＲＡ）２０３、送信側アドレス（ＴＡ）２０４、ＢｌｏｃｋＡＣＫ（ＢＡ）制御２０５、ＢｌｏｃｋＡＣＫ開始シーケンス制御２０６、ＢｌｏｃｋＡＣＫビットマップ２０７及びフレームチェックシーケンス（ＦＣＳ）２０８である。

図３は、フォーマット３００を有する、何ビットかのＢｌｏｃｋＡＣＫ要求（ＢＡＲ）制御フィールド及びＢｌｏｃｋＡＣＫ（ＢＡ）フィールドを示す。ＢＡＲ／ＢＡフィールドの最上位４ビットは、ＴＩＤサブフィールド３０２である。ＢＡＲ／ＢＡフィールドの最下位１２ビットは予約されている３０１。

図４は、ＢｌｏｃｋＡＣＫメッセージにおけるＢｌｏｃｋＡＣＫビットマップフィールドのフォーマット４００を示す。ＢｌｏｃｋＡＣＫビットマップは、フラグメント番号４０１、４０３及び４０５と、それら各々の後に続くシーケンス番号４０２、４０４及び４０６を含む６４個の２バイト長シーケンス制御番号を含む。

図５により詳細に示すように、各２バイト長シーケンス制御番号５００は、受信された１つのデータパケットを一意に識別する。シーケンス番号フィールドは、１２ビット長シーケンス番号５０２と、４ビット長フラグメント番号５０１とから成る。フラグメント番号は、フラグメンテーション及びリアセンブリプロセスで使用される。

現ＢｌｏｃｋＡＣＫの限界
いかなるネットワークにおいても、帯域幅は重要な資源である。ＩＥＥＥ８０２．１１ｎ規格による高スループットＷＬＡＮの場合、ＭＡＣプロトコルは、ＭＡＣサービスアクセスポイント（ＳＡＰ）において１００Ｍｂｐｓの設計要求を満たすために７０〜８０％効率を達成しなければならない。したがって、現ＭＡＣプロトコルを改善しなければならない。

しかしながら、現ＩＥＥＥ８０２．１１規格によるフレーム単位のＡＣＫメカニズムでは、無線チャネルを大幅に浪費する潜在的な原因がある。これは、ＩＥＥＥ８０２．１１ｅ規格においてＢｌｏｃｋＡＣＫが提案されているまさにその理由である。不都合なことに、ＢｌｏｃｋＡＣＫメカニズム自体は、帯域幅効率に関して完全に最適化されていない。

ＢｌｏｃｋＡＣＫフレームにおけるＢｌｏｃｋＡＣＫビットマップフィールドは、１２８バイトの固定長である。したがって、ＢｌｏｃｋＡＣＫを使用してブロックとして送信されるいかなる数のデータパケットに対しても、ＢｌｏｃｋＡＣＫに１２８バイト長ＢｌｏｃｋＡＣＫビットマップを含めなければならない。これは、小さいブロックの場合の大幅な無駄及び柔軟性のなさの原因となる。

さらに、現ＢｌｏｃｋＡＣＫメッセージには、同じトラフィッククラス（ＴＣ）又はトラフィックストリーム（ＴＳ）に属するデータに対する確認応答でなければならないという制約がある。現在、競合（contention：コンテンション）によって取得される送信権（transmission opportunity）（ＴＸＯＰ）（ＥＣＣＡ−ＴＸＯＰ）又はポーリングによって割り当てられる送信権（ＨＣＣＡ−ＴＸＯＰ）は、常に特定のＴＣ又はＴＳに関連しており、ＴＸＯＰ中はそのＴＣ又はＴＳのデータパケットしか送信することができない。

したがって、より優れたブロック確認応答方法が望ましい。

ＩＥＥＥ８０２．１１ｎ規格では、サービスアクセスポイント（ＳＡＰ）の媒体アクセス制御（ＭＡＣ）層において１００Ｍｂｐｓのスループットを必要とする。現ＩＥＥＥ８０２．１１／ＩＥＥＥ８０２．１１ｅＭＡＣプロトコルにおけるさまざまなメカニズムは、莫大なオーバヘッドを伴い、最終的に深刻なスループット性能の劣化がもたらされる。ＩＥＥＥ８０２．１１ｎ規格に対して現ＭＡＣプロトコルを直接適用することは実際的ではない。

したがって、本発明は、改良されたブロック確認応答方法を提供する。本方法は、従来技術によるブロック確認応答方式より使用する帯域幅が小さい。本方法は、ＩＥＥＥ８０２．１１／ＩＥＥＥ８０２．１１ｅＭＡＣフレームにおける予約フィールドを使用して、広範囲の新たな機能を達成する。それら機能は、従来技術によるＩＥＥＥ８０２．１１／ＩＥＥＥ８０２．１１ｅＭＡＣプロトコルでは利用できないものである。分析により、本発明の方法によって、７０％以上効率が向上することが分かった。

特に、方法は、共通無線チャネルによって接続された複数の局を含むネットワークにおいてデータパケットに対して選択的に確認応答する。

送信局は、受信局に対してブロック確認応答を要求する。送信局は、受信局に対してデータパケットのブロックを送信する。

受信局は、正しく受信されたデータパケットの数と、誤って受信されたパケットの数とを確定する。

そして、受信局は、有効に受信されたデータパケットの数が誤って受信されたデータパケットの数を下回る場合には、正しく受信されたデータパケットに対してのみ選択的に確認応答し、そうでない場合は、誤って受信されたパケットに対してのみ確認応答する。

本発明は、ＩＥＥＥ８０２．１１規格によって設計された無線ローカルエリアネットワーク（ＷＬＡＮ）においてデータパケットのブロックに対して確認応答する方法を提供する。本方法は、ＢｌｏｃｋＡＣＫビットマップにおける可変サイズのフィールドを使用する。ＢｌｏｃｋＡＣＫフィールドは、正しく受信されたデータパケットか又は誤って受信されたデータパケットのいずれかビットの数が少ない方を伝えることができる。

一般に、物理チャネルの状態は、変動するより安定している傾向がある。したがって、レート適応により、適度に低いパケット誤り率（ＰＥＲ）を達成するように伝送レートが最適化される。このため、パケット誤りが持続的に発生する確率は低い。これは、大部分のデータパケットが正しく受信されることを意味し、ＢｌｏｃｋＡＣＫフィールドは、誤って受信されたデータパケットを示すのみでよい。

本方法は、複数のトラフィッククラス（ＴＣ）及びトラフィックストリーム（ＴＳ）に対して柔軟な確認応答をサポートする。本方法を、ＥＤＣＡ（enhanced distritubed channel access）期間中の競合によって取得された送信権（ＴＸＯＰ）、及びＨＣＣＡ（hybrid coordinated channel access）期間中にアクセスポイント（ＡＰ）によって割り当てられたＴＸＯＰに対して使用することができる。

本方法は、セッション確立、データ交換、ブロック確認応答及び終了の各フェーズを含み、２つのモードで動作することができる。

モード１
セッションが確立すると、送信側と受信側との間で、ＡＤＤＢＡ要求メッセージ及びＡＤＤＢＡ応答メッセージを交換する。ＡＤＤＢＡ要求メッセージとＡＤＤＢＡ応答メッセージとの両方に含まれるＢｌｏｃｋＡＣＫパラメータセット固定フィールドを使用して、確立されるべきＢｌｏｃｋＡＣＫセッションに対するパラメータを交渉する。

表３は、ＩＥＥＥ８０２．１１ｅ規格によるＡＤＤＢＡ要求によって開始することができるあり得るすべてのＡＣＫモードを示す。

表４は、セッションに対してＴＣ又はＴＳを指定するＢｌｏｃｋＡＣＫパラメータセット固定フィールド内のトラフィックＩＤ（ＴＩＤ）サブフィールドを示す。

図６は、ＢｌｏｃｋＡＣＫパラメータセット固定フィールドのフォーマット６００を示す。ここでは、従来技術によるＢｌｏｃｋＡＣＫパラメータセット固定フィールドの予約ビット（Ｂ０）６０１を使用して、ブロック送信セッションにおいて複数のＴＩＤ６０３がサポートされているか否かを示す。Ｂ０が０である場合、本発明による混合トラフィックが使用可能であり、一方、０である場合、混合トラフィックは使用不能である。

ＡＤＤＢＡ要求メッセージ及びＡＤＤＢＡ応答メッセージにＢｌｏｃｋＡＣＫパラメータセット固定フィールドが含まれるため、セッションに関与する２つの局は、この混合モードをサポートするか否かを交渉することができる。フィールド６０２は、２ビット長ＢｌｏｃｋＡＣＫポリシを格納し（表３を参照）、フィールド６０４はバッファサイズを格納する。

具体的には、ＡＤＤＢＡ要求は、ビットＢ０を適当に設定することによって交渉を開始する。そして、受信側は、その能力が設定されたＢ０ビット及び対応するＡＤＤＢＡ要求メッセージとともにＡＤＤＢＡ応答メッセージを返す。この交換の後、両局は、セッション中に混合トラフィックを使用することができるか否かを判断することができる。

セッションが確立された後、データパケットを送信することができる。送信側は、送信されたデータパケットが受信側によって正しく受信されたか否かを確認する必要がある場合、ＢｌｏｃｋＡＣＫＲｅｑメッセージを送信することによって受信側にＢｌｏｃｋＡＣＫを要求する。

本発明によるＢｌｏｃｋＡＣＫＲｅｑメッセージ７００及びＢｌｏｃｋＡＣＫメッセージ８００のフォーマットを、それぞれ図７及び図８に示す。フォーマット７００は、フレーム制御７０１、継続時間７０２、受信側アドレス７０３、送信側アドレス７０４、ＢＡＲ制御７０５、シーケンス制御７０６及び７０７並びにＦＣＳ７０８の各フィールドを含む。フォーマット８００は、フレーム制御８０１、継続時間８０２、受信側アドレス８０３、送信側アドレス８０４、ＢＡ制御８０５、シーケンス制御８０６及び８０７、ｎバイトを含むＢｌｏｃｋＡＣＫビットマップ８０８並びにＦＣＳ８０９の各フィールドを含む。

ＢｌｏｃｋＡＣＫの柔軟性及び効率を向上させるために、本発明は、ＢｌｏｃｋＡＣＫＲｅｑメッセージ及びＢｌｏｃｋＡＣＫメッセージのＢＡＲ／ＢＡ制御フィールドにおける予約された１２ビット長フィールドを使用する。

図９は、モード１の場合のＢＡＲ制御フィールドのフォーマット９００を示す。ＢＡ制御フィールドの設計も同様であるが、簡単のために、図９にはＢＡＲ制御フィールドのみを示し、以下で説明する。従来技術において予約されていた１２ビット長フィールド９１０をサブフィールドに分割する。モード１の場合、モード選択のために最下位３ビット（Ｂ０〜Ｂ２）９０１を使用する。表５に、８つのすべてのあり得るモードを列挙する。さまざまなフィールド、たとえばＮＡＣＫ、相対シーケンス番号等については後述する。

モード１では、ＢＡＲ制御フィールドのビットＢ３〜Ｂ４９０２を使用して、現ＢｌｏｃｋＡＣＫＲｅｑメッセージに含まれるＴＩＤの番号を示す。ビットＢ５〜Ｂ８９０３は、ＢｌｏｃｋＡＣＫＲｅｑメッセージに含まれるＴＩＤを示す。たとえば、Ｂ５が１に設定されている場合、ＢｌｏｃｋＡＣＫＲｅｑメッセージには、ＴＩＤ_１に対するＢｌｏｃｋＡＣＫ開始シーケンス制御フィールドが存在する。ビットＢ９〜Ｂ１１９０４は予約されている。ＴＩＤフィールド９０５、Ｂ１２〜Ｂ１５は、ＢｌｏｃｋＡＣＫセッションが確立された元のＴＩＤを表す。

有効なデータパケットは１つのＴＣ又は１つのＴＳしか有することができず、両方を同時に有することはできない。さらに、データパケットのブロック送信は、競合期間又は非競合期間にのみ発生することができるが、両方で発生することはできない。したがって、常に、ＢｌｏｃｋＡＣＫＲｅｑメッセージは、ＴＣ又はＴＳのいずれかにしか関連することができず、両方に関連することはできない、と想定することが適当である。これは、いずれのＢｌｏｃｋＡＣＫＲｅｑメッセージにおいてもあり得る有効なＴＩＤは４つしかないことを意味する。したがって、「ＴＩＤの数」フィールド９０２及び「ＴＩＤビットマップ」フィールド９０３には、それぞれ２ビット及び４ビットのみを割り付ける。これは、単一のＢｌｏｃｋＡＣＫＲｅｑフレームに、最大４つのＢｌｏｃｋＡＣＫ開始シーケンス制御フィールドを含めることができることを意味する。

ＢｌｏｃｋＡＣＫＲｅｑメッセージ及びＢｌｏｃｋＡＣＫメッセージの両方に含まれるＢｌｏｃｋＡＣＫ開始シーケンスサブフィールドは、確認応答されるべきパケットのブロック内の開始データパケットのシーケンス番号を指定する。図５に示すように、シーケンス制御フィールドを２つの部分、すなわち、それぞれ４ビット及び１２ビットであるフラグメント番号サブフィールド５０１及びシーケンス番号サブフィールド５０２に分割する。

図１０に、モード１の場合のＢｌｏｃｋＡＣＫビットマップフィールドのフォーマット１０００を示す。従来技術の場合のように固定長ＢｌｏｃｋＡＣＫビットマップを含むのではなく、ここでは、正しく受信されたパケットか又は誤って受信されたパケットのいずれかビットの数が少ない方に対して選択的に確認応答することができる。

パケットのブロックにおいて正しく受信されたパケットの数及び誤って受信されたパケットの数が、それぞれＮ（ｓｕｃｅｅｄ）及びＮ（ｆａｉｌ）であり、ブロックの全サイズがＮ（ｔｏｔａｌ）であるとすると、
Ｎ（ｓｕｃｃｅｅｄ）＋Ｎ（ｆａｉｌ）＝Ｎ（ｔｏｔａｌ）
である。

従来技術によるＢｌｏｃｋＡＣＫビットマップに必要なバイトの数Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）は、
Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）＝１２８バイト
である。

本発明によるＢｌｏｃｋＡＣＫビットマップに必要なバイトの数Ｓｉｚｅ（ｂｉｔｍａｐ−ｉｎｖｅｎｔｉｏｎ）は、
Ｓｉｚｅ（ｂｉｔｍａｐ−ｉｎｖｅｎｔｉｏｎ）＝２×ｍｉｎ｛Ｎ（ｓｕｃｃｅｅｄ），Ｎ（ｆａｉｌ）｝
＝２×ｍｉｎ｛Ｎ（ｓｕｃｃｅｄ），Ｎ（ｔｏｔａｌ）−Ｎ（ｓｕｃｃｅｅｄ）｝
≦２×［Ｎ（ｔｏｔａｌ）／２］
≦Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）／２バイト
である。

すなわち、Ｓｉｚｅ（ｂｉｔｍａｐ−ｉｎｖｅｎｔｉｏｎ）≦Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）／２である。

言い換えれば、本発明による確認応答方法が使用するバイトの数は、最悪の場合でも、従来技術による方式の半分である。したがって、選択的な確認応答及び否定ＡＣＫ（ＮＡＣＫ）を適応的に使用することにより、ＢｌｏｃｋＡＣＫにおけるシーケンス制御フィールドの数を大幅に低減することができる。ＢｌｏｃｋＡＣＫＲｅｑメッセージ及びＢｌｏｃｋＡＣＫメッセージの新たなＢＡＲ／ＢＡ制御フィールドのモード選択フィールドは、肯定ＡＣＫを使用するか又は否定ＡＣＫを使用するかを示す。

ＢｌｏｃｋＡＣＫビットマップの長さｎは可変である。たとえば、６４データパケットが送信され２０パケットのみが受信される場合、本発明によれば、ＢｌｏｃｋＡＣＫビットマップには２０のシーケンス番号しかない。これは、従来技術によるＢｌｏｃｋＡＣＫと比較した場合、８０％節約されることを表す。

ＢｌｏｃｋＡＣＫ開始シーケンスフィールドに、各ＴＩＤに対する開始シーケンス番号が含まれるため、ブロックのデータパケットが連続したシーケンス番号を有する限り、完全なシーケンス制御フィールドを確認応答で返信する必要はない。

したがって、本発明は、ＩＥＥＥ８０２．１１規格によって定義される２バイト長（１６ビット）シーケンス番号を使用する代りに、６ビット長相対シーケンス番号（１００１及び１００３）を使用することにより、さらなる節約を達成することができる。相対シーケンス番号の６ビットは、最大６４の異なるデータパケットを表すことができる。従来技術によるＢｌｏｃｋＡＣＫビットマップは、６４までの完全なシーケンス番号をサポートするのみである。

図１０に示すように、残っている２ビット（１００２及び１００４）は、確認応答されているデータの符号化ＴＩＤを表すことができる。この新たな拡張により、同じブロックの異なるトラフィッククラスのデータパケットを送信することが可能になる。

この場合、Ｓｉｚｅ（ｂｉｔｍａｐ−ｉｎｖｅｎｔｉｏｎ）≦Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）／４である。

すなわち、本発明には、より柔軟な伝送方式を用いても、従来技術によるＢｌｏｃｋＡＣＫの１／４のバイトがあればよい。

モード２
本発明による確認応答の方法の第２のモードを、データパケットが連続したシーケンス番号を有する場合に使用することができる。モード２では、確立フェーズ及びデータ交換フェーズは、モード１のものと同一である。

しかしながら、簡単にするために、ＢｌｏｃｋＡＣＫＲｅｑメッセージ及びＢｌｏｃｋＡＣＫメッセージを異なるように設計する。実際には、これらの２つのメッセージは、従来技術によるＢｌｏｃｋＡＣＫメッセージと略同様であるが、より効率を向上させるように、ＢＡＲ／ＢＡフィールド及びＢｌｏｃｋＡＣＫビットマップフィールドを最適化する。

図１１は、モード２の場合のＢＡＲ／ＢＡフィールド１１００を示す。従来技術において予約されていた１２ビット長フィールド１１１０をサブフィールドに分割する。最初の３ビット（Ｂ０〜Ｂ２）は、モード選択フィールド１１０１を構成し、これは、モード１の場合のＢＡＲ／ＢＡフィールドと同じ定義を有する。特に、モード選択フィールドが０×０の値を有する場合、モード１が使用される。

ブロックサイズフィールド１１０２（Ｂ３〜Ｂ８）は、ＢｌｏｃｋＡＣＫメッセージにおいていくつのパケットが確認応答されるべきかを示す。モード２でサポートされる最大ブロックサイズは、従来技術によるＢｌｏｃｋＡＣＫと同じサイズである６４パケットであるため、ブロックサイズフィールドは６ビット長である。フィールド１１０３は予約されており、フィールド１１０４はＴＩＤを格納する。

図１２は、モード２の場合のＢｌｏｃｋＡＣＫビットマップフィールド１２００を示す。このビットマップは、３２バイト長フラグメント番号連結フィールド１２０１及び８バイト長シーケンス番号ビットマップフィールド１２０２を有する。フラグメント番号連結フィールドは、確認応答されるべきデータパケットすべてに対する４ビットフラグメント番号１２０３の連結である。ブロックのパケットの最大数が６４であるため、このフィールドに対し１６バイトを使用することで十分である。シーケンス番号ビットマップフィールドの各ビットは、特定のパケットが正しく受信されたか又は誤って受信されたかを示す。ビットの相対位置は、シーケンス番号を表す。たとえば、このビットマップフィールドの最下位ビットが０に設定されている場合、シーケンス番号が（ＢｌｏｃｋＡＣＫ開始シーケンス番号＋０）であるパケットは正しく受信されている。

６４パケットが送信される前にＢｌｏｃｋＡＣＫを要求することが可能である。しかしながら、ビットマップフィールドは、パケットがまったく送信されなかった場合を、そのパケットが正しく受信されたか又は誤って受信された場合から識別するのに適当なロジックを提供しない。したがって、モード２では、ＢＡＲ／ＢＡＲフィールドにブロックサイズサブフィールドを含める。モード２の場合、Ｓｉｚｅ（ｂｉｔｍａｐ−ｉｎｖｅｎｔｉｏｎ）＝４０であり、Ｓｉｚｅ（ｂｉｔｍａｐ−ｐｒｉｏｒ−ａｒｔ）＝４０／１２８であるため、６８．７５％の節約である。ここでさらにフラグメント番号連結フィールドを取り除くと、（１−８／１２８）＝０．９３７５％の節約を達成することができる。

アプリケーションに応じて動作モードを選択することができる、ということに留意すべきである。

実施態様及び互換性の点
ＢｌｏｃｋＡｃｋＲｅｑメッセージ及びＢｌｏｃｋＡｃｋメッセージのＢＡＲ／ＢＡ制御フィールドのモード選択サブフィールドをゼロに設定することにより、本発明による方法を従来技術で使用することができる。

本発明を、好ましい実施形態の例を用いて説明したが、本発明の精神及び範囲内で他のさまざまな適応及び変更を行ってもよい、ということを理解すべきである。したがって、添付の特許請求の範囲の目的は、本発明の真の精神及び範囲内にあるかかる変形及び変更をすべて包含することである。

従来技術によるＢｌｏｃｋＡＣＫＲｅｑフレームフォーマットのブロック図である。従来技術によるＢｌｏｃｋＡＣＫフレームフォーマットのブロック図である。従来技術によるＢＡＲ／ＢＡ制御フィールドのブロック図である。従来技術によるＢｌｏｃｋＡＣＫビットマップフォーマットのブロック図である。従来技術によるシーケンス制御フィールドのブロック図である。本発明によるＢｌｏｃｋＡＣＫパラメータセット固定フィールドのブロック図である。本発明によるＢｌｏｃｋＡＣＫＲｅｑメッセージのブロック図である。本発明によるＢｌｏｃｋＡＣＫメッセージのブロック図である。本発明による第１の確認応答モードの場合のＢＡＲ／ＢＡフィールドのブロック図である。本発明による第１のモードの場合のＢｌｏｃｋＡＣＫビットマップフィールドのブロック図である。本発明による第２の確認応答モードの場合のＢＡＲ／ＢＡフィールドのブロック図である。本発明による第２のモードの場合のＢｌｏｃｋＡＣＫビットマップフィールドのブロック図である。

Claims

共通無線チャネルによって接続された複数の局を含むネットワークにおいてデータパケットに対して確認応答する方法であって、
送信局によって、受信局に対しブロック確認応答を要求すること、
前記送信局によって、前記受信局に対してデータパケットのブロックを送信すること、
前記受信局において、正しく受信されたデータパケットの数及び誤って受信されたパケットの数を確定すること、
及び
有効に受信されたデータパケットの数が前記誤って受信されたデータパケットの数を下回る場合、前記正しく受信されたデータパケットに対してのみ確認応答し、そうでない場合、前記誤って受信されたパケットに対してのみ確認応答すること
を含む方法。
前記ブロック確認応答要求は、単一のトラフィッククラスのデータパケットに対する
請求項１記載の方法。
前記ブロック確認応答要求は、複数のトラフィッククラスのデータパケットに対する
請求項１記載の方法。
前記ブロック確認応答要求は、単一のトラフィックストリームのデータパケットに対する
請求項１記載の方法。
前記ブロック確認応答要求は、複数のトラフィックストリームのデータパケットに対する
請求項１記載の方法。
前記ブロック確認応答のビットマップは、各確認応答されたデータパケットの完全なシーケンス番号を含む
請求項１記載の方法。
前記ブロック確認応答のビットマップは、各確認応答データパケットの相対シーケンス番号を含む
請求項１記載の方法。
前記ブロック確認応答のビットマップは、フラグメント番号連結及びシーケンス番号ビットマップを含む
請求項１記載の方法。
前記ブロック確認応答のビットマップは、シーケンス番号ビットマップのみを含む
請求項１記載の方法。