JP5637988B2

JP5637988B2 - 無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答の要求および伝送を行う装置

Info

Publication number: JP5637988B2
Application number: JP2011516235A
Authority: JP
Inventors: リウ，ハン; マンドレカー，イシヤン; ウー，ミンチエン; ペルマナム，ラムクマー; マートウル，ソウラブ
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2008-06-26
Filing date: 2008-06-26
Publication date: 2014-12-10
Anticipated expiration: 2028-06-26
Also published as: JP2011526455A; ZA201008790B; AU2008358409A1; RU2478259C2; AU2008358409B2; KR101482087B1; BRPI0822834A2; CN102057608B; CA2727473A1; MX2010014072A; BRPI0822834A8; US8514763B2; US20110096710A1; CN102057608A; WO2009157901A1; KR20110025657A; RU2011102757A; EP2304890B1; CA2727473C; EP2304890A1

Description

本発明は、一般に、無線通信に関し、詳細には、無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答の要求および伝送を行う装置に関する。

本明細書で使用する記号「／」は、同じまたは類似の構成要素または構造を指す別名を示している。すなわち、記号「／」は、本明細書では「または」の意味と解釈することができる。ユニキャスト伝送は、単一の送信側／伝送側と、単一の受信側との間で行われる。ブロードキャスト伝送は、単一の送信側／伝送側と、当該送信側の受信範囲内の全ての受信側との間で行われる。マルチキャスト伝送は、単一の送信側／伝送側と、当該伝送側の受信範囲内の受信側のサブセットとの間で行われる。ただし、伝送側の受信範囲内の受信側のサブセットは、受信範囲内の受信側全体であってもよい。すなわち、「マルチキャスト」は、「ブロードキャスト」を含むことがあるので、本明細書では「ブロードキャスト」より広い意味を有する用語である。

無線ローカル・エリア・ネットワークでは、アクセス・ポイント（ＡＰ）／基地局／局（ＳＴＡ）／移動装置／移動端末／ノードは、ランダム・バックオフ・タイム（ｒａｎｄｏｍｂａｃｋｏｆｆｔｉｍｅ）を用いた物理的および仮想的搬送波感知プロセスを用いて無線媒体／チャネルが遊休／クリア状態であると判定した直後に、マルチキャスト・フレームおよびブロードキャスト・フレームを伝送する。従って、複数のＳＴＡが同時に伝送を試みると、衝突が起こる可能性がある。例えば、あるアクセス・ポイントおよびそれと関連付けられた複数のＳＴＡが同時に伝送を行う場合があるが、この場合、伝送された全てのフレームが衝突によって失われる。例えば、ＡＰがマルチキャスト・データ・フレームをそれと関連付けられたＳＴＡのうちのいくつかに送信したとき、別のＳＴＡがそのデータまたは制御フレームを当該ＡＰに送信する可能性がある。複数の局と関連付けられたＡＰを、基本サービス・セット（ＢＳＳ）と呼ぶ。１つのＢＳＳ内部で起こる衝突を、ＢＳＳ内衝突と呼ぶ。別の例では、ＡＰ１およびＡＰ２が同じチャネル／周波数で動作し、その２つのＢＳＳが重複する。ＡＰ１は、それと関連付けられたＳＴＡにデータ・フレームを伝送する。しかし、ＡＰ２は、ＡＰ１の伝送を認識することができず、媒体が遊休状態であると考える。ＡＰ１は、ＡＰ２にとっては「隠れたノード」である。ＡＰ２は、ＡＰ１が伝送を行っている最中に、それと関連付けられたＳＴＡにフレームを伝送することがある。しかし、ＡＰ１とＡＰ２の干渉範囲内にあるＳＴＡが存在するので、ＡＰ１およびＡＰ２から伝送されるフレームは、それらのＳＴＡにおいて衝突によって失われる。このタイプの衝突を、重複ＢＳＳ衝突、またはＢＳＳ間衝突と呼ぶ。

マルチキャストおよびブロードキャストは、複数の受信側にデータを分配する効率的な方法を提供する。しかし、マルチキャストおよびブロードキャストにおいて複数の受信側によるデータの受信が確実に行われることを保証することは難題である。媒体アクセス制御およびリンク・レイヤにおいて複数の受信側が受信したマルチキャスト・パケットの確認応答を行う効率的な機構を提供することは、特に重要である。

マルチキャストの信頼性を向上させるための高いレイヤ（アプリケーション・レイヤおよびトランスポート・レイヤ）方式は、既に提案されている。従来技術の１つの方式では、否定応答（ＮＡＣＫ）方法が述べられている。この方法では、受信側が、受信パケット中にシーケンス番号の途切れを検出したときに、ＮＡＣＫを送信側に送信する。この手法では、送信側および受信側の双方で、遅延およびバッファの要件が増えることになる。複数のマルチキャスト受信側が送信するＮＡＣＫの数を抑制することによってフィードバック・オーバヘッドを低減することもできるが、この方式では、高いマルチキャスト信頼性を保証する、またはパケットの損失がない状態を保証することがさらに複雑になる。

「無線伝送において効率的且つ信頼性の高いＭＡＣレイヤ・マルチキャストを行う方法およびシステム」と題する、Ａｃｈａｒｙａ他による米国特許出願公開第２００６／０１０９８５９号には、無線ネットワークにおいて信頼性の高いマルチキャストを行うための媒体アクセス制御（ＭＡＣ）レイヤ方法が記載されている。送信側ノードは、送信要求（ＲＴＳ）信号を受信側ノードに送信する。ＲＴＳ信号は、受信側ノードに対応する識別子のセットまたはビット・ベクトルを含む。ビット・ベクトル中の各ビットは、受信ノードを示している。識別子セットまたはビット・ベクトルの順序関数に従って、送信可（ＣＴＳ）信号が、受信側ノードから送信される。送信側は、少なくとも１つのＣＴＳ信号を受信した後で、受信側ノードにデータ・パケットを送信する。データ・パケットが適切に受信された場合には、ＲＴＳ信号中の識別子セットまたはビット・ベクトルの順序付け関数に従って、１つまたは複数のＡＣＫ信号が、受信側ノードの１つまたは複数から送信される。この手法では、４方向ハンドシェイクを用いて、１つのデータ・パケットの送信および確認応答を行う。複数の受信側からのＡＣＫ信号の順序は、ＲＴＳ信号中の識別子またはビット・ベクトルに基づいている。ＡＣＫ信号は、１つのパケットのみの確認応答である。この方式では、オーバヘッドが大きくなり、従って、ネットワークのスループットが低下することになる。

さらに、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）では、アクセス・ポイント（ＡＰ）が、関連付けられた局を多数有することがある。あるいは、送信側ノードが、近接ノードを多数有することがある。ＲＴＳ信号が受信側ノードに対応する識別子のセットまたはビット・ベクトルを含む場合には、ＲＴＳ信号が大きくなり、オーバヘッドがさらに大きくなる可能性がある。

別の手法では、複数のユニキャストを使用して、無線ネットワークにおいてマルチキャスト・データを送信する。アクセス・ポイントは、マルチキャスト・データ・パケットのユニキャストを繰り返し行う。ユニキャストは無線ネットワーク環境においてＭＡＣレイヤの確認応答および再伝送を行うものであるため、１回のユニキャストは、所期の１つの受信側のみを対象として行われる。ただし、この手法では、同じマルチキャスト・データを、共通のブロードキャスト・チャネルを介して複数回伝送する必要があるので、オーバヘッドが大きくなり、ネットワークのスループットが低くなることになる。

「無線ネットワークにおけるマルチキャスト手続き」と題する、Ｈｕｈ他による国際出願第２００８／０２０７３１号には、発信側／アクセス・ポイントが複数の受信側にマルチキャストでデータ・パケットを伝送し、その後、ユニキャストを用いて各受信側に個別にポーリングして、先に伝送したマルチキャスト・データ・パケットの受信状態を問い合わせる方法が記載されている。発信側は、各受信側にユニキャストでブロック確認応答要求（ＢＡＲ）メッセージを送信して、受信状態を個別に要求するので、ＢＡＲメッセージを、各受信側毎に１回ずつ、複数回送信する。すなわち、発信側は、各受信側と個別に、つまり各受信側毎に１回ずつ、ブロック確認応答要求（ＢＡＲ）メッセージおよび確認応答返答（Ｂ−ＡＣＫ）メッセージの交換をユニキャストで行う。従って、この手法でも、依然として不要なオーバヘッドが生じ、ネットワークの効率およびスループットが低下する。

無線ネットワーク環境において、ＭＡＣレイヤで複数の受信側からの複数のマルチキャスト・パケットの確認応答を行う方法および装置があると有利であろう。信頼性の高いマルチキャスト・データの伝送、確認応答および再伝送を行う効率的な方法があることが望ましい。

本発明は、通信ネットワークにおいて信頼性の高いマルチキャストを行うために、複数の受信側からの複数のデータ・ユニット／フレーム・パケットの受信状態を取得する方法および装置を提供する。本発明は、１つの送信側ノードから複数の受信側ノードに複数のデータ・ユニット／フレーム／パケットをマルチキャストし、その後、送信側ノードから受信側ノードにマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）をマルチキャストすることを含む。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号は、確認応答ポリシーおよび確認応答する必要がある複数のパケットに関する制御情報と、識別子のセットまたは部分仮想ビットマップを有するビットマップ制御とを含む。ビットマップ制御および部分仮想ビットマップを使用することにより、オーバヘッドが低減する。各識別子またはビットマップ中の１ビットは、１つの受信側ノードに対応する。マルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）信号は、前記の識別子のセットまたはビットマップによって示されるＭ−ＢｌｏｃｋＡｃｋＲｅｑに応答して、受信側ノードから送信される。受信側からのＭ−ＢｌｏｃｋＡｃｋは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑで確認応答を要求された複数のデータ・ユニット／パケット／フレームの受信状態情報を含む。

持続時間フィールドと、マルチキャスト受信側アドレス・フィールドと、伝送側アドレス・フィールドと、ブロック確認応答要求制御フィールドと、ブロック確認応答要求情報フィールドと、情報フィールドとを含む信号、ならびにその信号を受信する装置について述べる。また、持続時間フィールドと、マルチキャスト受信側アドレス・フィールドと、伝送側アドレス・フィールドと、ブロック確認応答制御フィールドと、ブロック確認応答情報フィールドとを含む信号、ならびにその信号を伝送する装置について述べる。

本発明は、添付の図面と関連付けて以下の詳細な説明を読むと最も良く理解できる。添付の図面には、以下の図面が含まれる。

例示的なＷＬＡＮネットワークを示す図である。複数の局／ノードを含む無線メッシュ・ネットワークを示す図である。本発明の例示的な実施例における、マルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）およびマルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）を用いる高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。例示的なＭ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレームを示す図である。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレーム内の受信側情報フィールドの例示的なフォーマットを示す図である。例示的なＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを示す図である。Ｍ−ＢｌｏｃｋＡｃｋフレーム／信号／メッセージ内のＢＡ制御フィールドの例示的なフォーマットを示す図である。Ｍ−ＢｌｏｃｋＡｃｋフレーム内のＢＡ情報フィールドの例示的なフォーマットを示す図である。本発明の例示的な実施例によるマルチキャスト伝送手続きを示す流れ図である。本発明の例示的な実施例によるマルチキャスト受信手続きを示す流れ図である。本発明の例示的な実施例による、ＢＡＲ受信側ビットマップ制御およびＢＡＲ受信側部分仮想ビットマップを用いるＭ−ＢｌｏｃｋＡｃｋＲｅｑフレーム／信号／メッセージ内の受信側情報フィールドの例示的なフォーマットを示す図である。本発明の代替の実施例における、遅延ポリシーおよび確認応答を用いたマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）とマルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）の交換を用いる高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。本発明の代替の実施例における、遅延ポリシーを用いるが確認応答は用いないマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）とマルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）の交換を用いる高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。本発明の代替の実施例における、マルチ・ポーリングを用いたマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）とマルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）の交換を用いる高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。本発明の例示的な実施態様を示すブロック図である。

ＩＥＥＥ８０２．１１無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を用いた本発明の例示的な実施例について説明する。ただし、本発明は、その他の無線および有線のネットワークでも使用することができる。本発明は、媒体アクセス制御（ＭＡＣ）／リンク・レイヤまたはそれより高いレイヤ（アプリケーション・レイヤおよびトランスポート・レイヤ）で使用することができる。

ＩＥＥＥ８０２．１１に基づく既存の無線ローカル・エリア・ネットワークでは、マルチキャストおよびブロードキャストは信頼性が低い。ＭＡＣレイヤでマルチキャスト・データ／パケット／フレームの確認応答および再伝送が行われないからである。ＩＥＥＥ８０２．１１に基づく無線ローカル・エリア・ネットワークにおけるマルチキャストは、失われたマルチキャスト・パケットを回復するのにさらに高いレイヤのプロトコルに依存しており、その結果、待ち時間が長くなり、ネットワークのスループットが低下する。

図１は、例示的なＷＬＡＮネットワークを示す図である。このＷＬＡＮネットワークは、１つのアクセス・ポイント（ＡＰ）および複数の局を含む。ＡＰは、マルチキャストおよびブロードキャストのデータ／パケット／フレームを、複数の局に送信する。なお、ＡＰは、有線ネットワークに接続する特殊な局であることに留意されたい。以下では、特に断らない限り、ＳＴＡはＡＰを含む。図２は、複数の局／ノードを含む無線メッシュ・ネットワークを示す図である。送信側／伝送側局は、マルチキャストおよびブロードキャストのデータ／パケット／フレームを、複数の受信側／宛先局に送信する。

共用媒体を用いるネットワークでは、複数の局が同時に媒体／チャネルにアクセスしてデータを送信／伝送することを試みた場合に、衝突が起こることがある。媒体アクセス制御技術は、チャネル・アクセス制御機構を提供し、複数のノードが１つのネットワーク内で通信することを可能にするために使用される。ＭＡＣ技術の１つは、搬送波感知多重アクセス（ＣＳＭＡ）である。ＣＳＭＡでは、伝送を望むＳＴＡは、最初に、一定時間（フレーム間インターバル／スペースにビジー媒体状態後のバックオフ・タイムを加えた時間）、無線媒体／チャネルをリッスンして、当該媒体において何らかのアクティビティが起きているかどうか検査する。媒体が「遊休状態／クリア状態」であると感知された場合には、ＳＴＡは、伝送を許可される。媒体が「ビジー」であると感知された場合には、ＳＴＡは、伝送を延期しなければならない。これは、ＣＳＭＡ／衝突回避（ＣＳＭＡ／ＣＡ）およびＣＳＭＡ／衝突検出（ＣＳＭＡ／ＣＤ）の両方の基本である。衝突検出は、衝突が検出されると直ちに伝送を終了させ、リトライ時に第２の衝突が起こる確率を低下させることによって、ＣＳＭＡ性能を向上させるために使用される。

ＣＳＭＡ／ＣＡは、媒体を一定期間（送信機会）確保するための信号を送信することによって、純粋なＣＳＭＡを改変することも含む。ＣＳＭＡ／ＣＡでは、１つの局が、搬送波感知多重アクセスを行う。搬送波感知は、物理的搬送波感知および仮想搬送波感知の両方を含む。仮想搬送波感知は、その他のＳＴＡが媒体を予約しているかどうかを示す。物理的搬送波感知および仮想搬送波感知の両方によってチャネルが遊休状態／クリア状態であることが感知され、ＳＴＡが伝送を許可されると、発信側ＳＴＡは、要求送信（ＲＴＳ）フレーム／メッセージ／信号を送信することができる。所期の受信側は、それ自体でも媒体が遊休状態であることを感知した場合には、送信可（ＣＴＳ）フレーム／信号／メッセージによって返答する。このＲＴＳフレーム／信号／メッセージとＣＴＳフレーム／信号／メッセージの交換は、実際のデータ・フレーム伝送の前に行われ、ＲＴＳおよびＣＴＳフレーム／メッセージ／信号の持続時間フィールドに指定された確保持続時間の間は、この共通／共用媒体を介した伝送を行わないように、その他の全てのＳＴＡに通達／助言することによって、その後のデータ伝送のために媒体を確保する。送信側または受信側あるいはその両方の受信範囲内の全てのＳＴＡは、ＲＴＳまたはＣＴＳ信号／フレーム／メッセージを通じてこの媒体確保を知り、確保している局の伝送が続いている間、サイレント状態を保つ。

共用媒体（例えば無線チャネル）ネットワーク用の、一般に良く用いられる別の媒体アクセス制御方法は、時分割多重アクセス（ＴＤＭＡ）である。ＴＤＭＡは、媒体／チャネルを異なる時間スロットに分割することによって、複数の局が同一チャネルを共用することができるようにする。各ノードに１つの時間スロットが割り当てられ、各ノードは、その時間スロットを使用してデータを伝送する。時間スロットの利用スケジュールは、アクセス・ポイント／基地局にある中央制御装置が制御して配布する（中央スケジューリング）、あるいは個々のノード自体が分散して確立する。

ポーリングは、共用チャネル用の別の媒体アクセス制御方法である。アクセス・ポイントまたは中央制御装置が、媒体アクセスを制御する。ＡＰは、チャネルをダウンリンク伝送（ＡＰから関連する全てのＳＴＡへの伝送）に使用してもよいし、関連する１つのＳＴＡに対してポーリングして、アップリンク伝送（関連するＳＴＡからＡＰへの伝送）の有無を問い合わせてもよい。

マルチ・ポーリング（ＭＰ）は、共用チャネル用の別の代替の媒体アクセス制御方法である。ＡＰまたは制御装置が、ＡＰおよびその１つまたは複数のＳＴＡが１回または複数回のダウンリンク伝送および１回または複数回のアップリンク伝送を行うために無線媒体にアクセスするために使用するタイム・スケジュールを送信することができる。

図３は、本発明の例示的な実施例におけるマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）と即時マルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）の交換を用いる、高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。送信側／ＡＰ／発信側は、マルチキャスト・データ・ユニット／パケット／フレームのブロックを、複数の受信側／ＳＴＡに伝送する。例えば、図３では、受信側１および２には伝送するが、受信側３には伝送しない。各データ・ユニット／パケット／フレームは、シーケンス番号またはフレーム識別子を含む。シーケンス番号は、例えば１ずつ増分する。データ・ユニット／パケット／フレームは、ＣＳＭＡまたはＴＤＭＡ、あるいはポーリングまたはマルチ・ポーリングを用いて伝送される。マルチキャスト・データのブロックを送信した後で、送信側は、マルチキャストＢｌｏｃｋＡｃｋＲｅｑ（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）信号を、マルチキャスト受信側に伝送する。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号は、ブロック確認応答要求（ＢＡＲ）制御フィールド、ブロック確認応答要求（ＢＡＲ）情報フィールド、および高信頼マルチキャスト受信側（ＲＭＲ）情報フィールドを含む。ＢＡＲ制御フィールドおよびＢＡＲ情報フィールドは、それについてマルチキャストＢｌｏｃｋＡｃｋ（Ｍ−ＢｌｏｃｋＡｃｋ）フレームが要求される１つまたは複数のトラフィック識別子（ＴＩＤ）と、ブロック確認応答開始シーケンス番号とを含む。開始シーケンス番号は、このＭ−ＢｌｏｃｋＡｃｋＲｅｑがＭ−ＢｌｏｃｋＡｃｋを要求している最初のフレームのシーケンス番号である。高信頼マルチキャスト受信側情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示す、ブロック確認応答要求対象受信側識別子のリストを含む。図３の例では、それらの識別子は、受信側１および２の識別子である。識別子は、局のＭＡＣアドレスでも、アソシエーションＩＤでも、ＩＰアドレス（本発明がＩＰレイヤで実行される／動作する場合）でもよい。あるいは、高信頼マルチキャスト受信側情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示すために、ビットマップ制御フィールドおよびビットマップ・フィールドを含む。ビットマップ中の各ビットは、ブロック確認応答を要求される受信局を識別する。ブロック確認応答要求対象受信側識別子リストまたはビットマップ中の各受信側／受信局（図３の例では受信側１および２）は、リストまたはビットマップに指定されている受信側の順序／シーケンスで、Ｍ−ＢｌｏｃｋＡｃｋによって応答する。受信側は、Ｍ−ＢｌｏｃｋＡｃｋを送信して、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレームに指定されている開始シーケンス番号を有するデータ・ユニット／パケット／フレームのブロックの受信状態を知らせる。受信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑマルチキャスト受信側情報フィールド（すなわちブロック確認応答要求対象識別子リストまたはビットマップ）に指定されているのと同じ順序／シーケンスで、それぞれのＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを送信する。あるいは、受信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ識別子リストまたはＭ−ＢｌｏｃｋＡｃｋＲｅｑビットマップの受信側識別子のシーケンスによって決まる順序で、それぞれのＭ−ＢｌｏｃｋＡｃｋ信号を送信する。ＢｌｏｃｋＡｃｋＲｅｑのブロック確認応答要求対象受信側リストまたはビットマップに含まれない受信側／ＳＴＡは、このＢｌｏｃｋＡｃｋＲｅｑに応答しない。図３の例では、受信側３は、ブロック確認応答要求対象受信側識別子リストまたはビットマップに含まれないので、Ｍ−ＢｌｏｃｋＡｃｋを送信してこのＭ−ＢｌｏｃｋＡｃｋＲｅｑに応答することはない。

図４Ａは、例示的なＭ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレームを示す図であり、このＭ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレームは、フレーム制御フィールド、持続時間／ＩＤフィールド、受信側アドレス（ＲＡ）フィールド、伝送側アドレス（ＴＡ）フィールド、ＢＡＲ制御フィールド、ＢＡＲ情報フィールド、受信側情報（ＲＩ）フィールド、フレーム検査シーケンス（ＦＣＳ）フィールドなどを含む。フレーム制御フィールドは、フレーム・タイプ、フレーム・サブタイプおよびフラグを識別する。持続時間／ＩＤフィールドは、媒体が伝送に使用される残り時間を示す。ＲＡフィールドは、所期の受信側／宛先／受信局の媒体アクセス制御（ＭＡＣ）アドレスを示す。ＭＡＣアドレスは、マルチキャスト・アドレスである。ＴＡフィールドは、伝送側のＭＡＣアドレスを示す。ＢＡＲ制御フィールドおよびＢＡＲ情報フィールドは、トラフィック識別子（ＴＩＤ）、およびこのＭ−ＢｌｏｃｋＡｃｋＲｅｑがＭ−ＢｌｏｃｋＡｃｋを要求している開始フレーム・シーケンス番号を示す。さらに、伝送側アドレスおよび受信側アドレスが同じであるがトラフィック識別子（ＴＩＤ）が異なる、複数のトラフィック・カテゴリまたはトラフィック・ストリームがあってもよい。例えば、ビデオ・トラフィックに対して１つのＴＩＤがあり、ウェブ・データ・トラフィックに対して別のＴＩＤがあってもよい。ＢＡＲ制御フィールドは、ブロックＡＣＫポリシーおよびＭ−ＢｌｏｃｋＡｃｋＲｅｑフォーマット指標を含むこともできる。例えば、ＢＡＲ制御フィールドは、このＭ−ＢｌｏｃｋＡｃｋＲｅｑに対する即時確認応答が必要であるかどうか、トラフィック識別子（ＴＩＤ）の異なる複数のトラフィック・カテゴリ／トラフィック・ストリームについて一緒に確認応答を行うことができるかどうかを指定することができる。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに複数のＴＩＤがある場合には、ＢＡＲ情報フィールドは、複数のＴＩＤおよび各ＴＩＤ毎に１つずつのブロック確認応答開始シーケンス番号のセットを複数含む。マルチＴＩＤＭ−ＢｌｏｃｋＡｃｋＲｅｑのＢＡＲ制御フィールドのＴＩＤ＿ＩＮＦＯサブフィールドは、ＴＩＤとＢｌｏｃｋＡｃｋ開始シーケンス番号のセット／インスタンスの数を含む。ＦＣＳフィールドは、受信側が、受信フレーム中にエラーがあるかどうかを判定するために使用する。図４Ｂは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレーム内の受信側情報フィールドの例示的なフォーマットを示す図であり、この受信側情報フィールドは、タイプ／フラグ・サブフィールド、および宛先／受信側／受信局識別子のリストを含む。タイプ／フラグ・サブフィールドは、受信側情報フィールドのフォーマットを示す。宛先／受信側／受信局識別子は、このＭ−ＢｌｏｃｋＡｃｋＲｅｑで返答が要求されているＳＴＡ／受信側を示す。識別子は、局のＭＡＣアドレスでも、アソシエーションＩＤでも、ＩＰアドレス（本発明がＩＰレイヤで実行される／動作する場合）でもよい。

図５Ａは、例示的なＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを示す図であり、このＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージは、フレーム制御フィールド、持続時間／ＩＤフィールド、受信側アドレス（ＲＡ）フィールド、伝送側アドレス（ＴＡ）フィールド、ＢＡ制御フィールド、ＢＡ情報フィールド、フレーム検査シーケンス（ＦＣＳ）フィールドなどを含む。フレーム制御フィールドは、フレーム・タイプ、フレーム・サブタイプおよびフラグを識別する。持続時間／ＩＤフィールドは、媒体が伝送に使用される残り時間を示す。ＲＡフィールドは、所期の受信側／宛先／受信局の媒体アクセス制御（ＭＡＣ）アドレスを示す。このアドレスは、このＭ−ＢｌｏｃｋＡｃｋを要求したＭ−ＢｌｏｃｋＡｃｋＲｅｑ発信側のアドレスである。ＴＡフィールドは、このフレームを伝送する局のアドレスである。ＢＡ制御フィールドおよびＢＡ情報フィールドは、トラフィック識別子（ＴＩＤ）、ブロックＡＣＫ開始フレーム・シーケンス番号、およびこのＭ−ＢｌｏｃｋＡｃｋフレームで確認応答するデータ／パケット／フレームのブロック／ユニットのブロックＡＣＫビットマップを示す。さらに、ＢＡ制御フィールドは、ブロックＡＣＫポリシーおよびＭ−ＢｌｏｃｋＡｃｋフォーマット指標を含むこともできる。ＦＣＳフィールドは、受信側が、受信フレーム中にエラーがあるかどうかを判定するために使用する。

図５Ｂは、Ｍ−ＢｌｏｃｋＡｃｋフレーム／信号／メッセージ内のＢＡ制御フィールドの例示的なフォーマットを示す図であり、ＢＡ制御フィールドは、フラグおよびＴＩＤ＿Ｉｎｆｏサブフィールドを含む。フラグは、ブロックＡＣＫポリシーおよびＭ−ＢｌｏｃｋＡｃｋフォーマットを示し、例えば、即時確認応答が必要であるかどうか、トラフィック識別子（ＴＩＤ）の異なる複数のトラフィック・カテゴリまたはトラフィック・ストリームについて一緒に確認応答を行うことができるかどうかを示す。ＴＩＤ＿Ｉｎｆｏサブフィールドは、このＭ−ＢｌｏｃｋＡｃｋフレームが確認応答となるＴＩＤを含む。図５Ｃは、Ｍ−ＢｌｏｃｋＡｃｋフレーム内のＢＡ情報フィールドの例示的なフォーマットを示す図であり、このフィールドは、ブロック確認応答開始シーケンス番号およびブロック確認応答ビットマップを含む。開始シーケンス番号は、このＭ−ＢｌｏｃｋＡｃｋが確認応答となる最初のデータ・ユニット／パケット／フレームのシーケンス番号であり、直前に受信したＭ−ＢｌｏｃｋＡｃｋＲｅｑ信号／フレーム／メッセージ中の開始シーケンス番号と同じ値である。ＢｌｏｃｋＡｃｋビットマップのビット位置ｎは、（ＢｌｏｃｋＡｃｋ開始シーケンス番号＋ｎ）に等しいシーケンス番号値を有するパケットに対応する。これは、複数のパケット／フレームの受信状態を示すために使用される。ＢｌｏｃｋＡｃｋビットマップにおいて１に設定されたビットは、パケットの受信に成功したことを示す。ＢｌｏｃｋＡｃｋビットマップのビット位置ｎが１に設定された場合には、（ＢｌｏｃｋＡｃｋ開始シーケンス制御＋ｎ）に等しいシーケンス番号値を有するパケットの受信に成功したことを示している。ＢｌｏｃｋＡｃｋビットマップのビット位置ｎが０に設定された場合には、（ＢｌｏｃｋＡｃｋ開始シーケンス制御＋ｎ）に等しいパケット・シーケンス番号値を有するパケット／データ／フレームが受信されていないことを示している。さらに、Ｍ−ＢｌｏｃｋＡｃｋ信号は、ＴＩＤの異なる複数のトラフィック・ストリームまたはトラフィック・カテゴリの確認応答となることができる。Ｍ−ＢｌｏｃｋＡｃｋ内に複数のＴＩＤがある場合には、ＢＡ情報フィールドは、複数のＴＩＤならびに各ＴＩＤ毎に１つずつのブロック確認応答開始シーケンス番号およびＭ−ＢｌｏｃｋＡｃｋビットマップのセット／インスタンスを複数含む。マルチＴＩＤＭ−ＢｌｏｃｋＡｃｋのＢＡＲ制御フィールドのＴＩＤ＿ＩＮＦＯサブフィールドは、ＴＩＤ情報、ＢｌｏｃｋＡｃｋ開始シーケンス番号およびＢｌｏｃｋＡｃｋビットマップのセット／インスタンスの数を含む。

Ｍ−ＢｌｏｃｋＡｃｋＲｅｑまたはＭ−ＢｌｏｃｋＡｃｋ信号は、失われる、または所期の受信側／宛先／受信局によって正しく受信されない可能性がある。マルチキャスト送信側が、受信側情報フィールドに受信側識別子リストを有するＭ−ＢｌｏｃｋＡｃｋＲｅｑを伝送して、全ての所期の受信側からＭ−ＢｌｏｃｋＡｃｋ信号をうまく受信できなかった場合には、マルチキャスト送信側は、Ｍ−ＢｌｏｃｋＡｃｋ信号をうまく受信できなかった受信側情報フィールド中の残りの受信側の識別子のリストを有するＭ−ＢｌｏｃｋＡｃｋＲｅｑを再伝送する。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの残りの受信側のリスト中の所期の受信側／宛先／受信局は、それぞれＭ−ＢｌｏｃｋＡｃｋによって応答する。このプロセスを、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ送信側が全ての所期の受信側／宛先／受信局からＭ−ＢｌｏｃｋＡｃｋを受信するまで、または再伝送試行回数が限度に達するまで、繰り返す。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑおよびＭ−ＢｌｏｃｋＡｃｋを再伝送するその他のポリシーを適用することもできる。例えば、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑで確認応答を要求されているデータ・パケットがその寿命／有効限度に達した場合に、マルチキャスト送信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの再伝送の試行を停止する、または新たなブロック確認応答開始シーケンス番号を有する更新Ｍ−ＢｌｏｃｋＡｃｋＲｅｑを発行する。あるいは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑがその寿命限度に達した場合に、マルチキャスト送信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの再伝送の試行を停止する。別の代替のポリシーでは、特定の（所定の）割合の所期の受信側／宛先／受信局からこのＭ−ＢｌｏｃｋＡｃｋＲｅｑに対応するＭ−ＢｌｏｃｋＡｃｋを受信した後で、または一定の試行回数に達した後で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ送信側が再伝送試行を停止することもできる。上記の割合は、所定のしきい値以上である。これらのポリシーは、単独で使用することもできるし、組み合わせて使用することもできる。

Ｍ−ＢｌｏｃｋＡｃｋＲｅｑとＭ−ＢｌｏｃｋＡｃｋの交換が完了した後で、マルチキャスト送信側は、Ｍ−ＢｌｏｃｋＡｃｋビットマップ中に与えられた情報から、パケットを再伝送する必要があるかどうかを判定する。受信側ブロック確認応答のビットマップから、１つまたは複数のパケットが失われている（１つまたは複数の所期のマルチキャスト受信側／宛先／受信局によって正しく受信されていない）と判定された場合には、マルチキャスト送信側は、この、またはこれらの失われたパケットの再伝送を手配する。再伝送パケットは、所期の受信側／宛先／受信局に、マルチキャストで送信される。失われたデータ・パケットの再伝送および／または新たなパケットの伝送を行った後で、マルチキャスト送信側は、新たなＭ−ＢｌｏｃｋＡｃｋＲｅｑを送信することができ、上記のＭ−ＢｌｏｃｋＡｃｋＲｅｑとＭ−ＢｌｏｃｋＡｃｋの交換方法を使用して、伝送（再伝送）パケットの受信状態を取得する。受信側ブロック確認応答のビットマップから、１つまたは複数のパケットが、１つまたは複数の所期のマルチキャスト受信側によって正しく受信されていないと判定された場合には、マルチキャスト送信側は、この、またはこれらの失われたパケットの再伝送を再度手配する。この失われたパケットの再伝送プロセスは、Ｍ−ＢｌｏｃｋＡｃｋを送信した全ての所期の受信側がパケットを正しく受信するまで、または当該パケットの伝送寿命（有効期間）が切れるまで、繰り返すことができる。なお、その他のデータ・パケット・マルチキャスティング・ポリシーを適用することもできることに留意されたい。例えば、マルチキャスト送信側は、データ・パケットの再伝送の試行を、当該パケットを正しく受信した受信側の割合がしきい値以上である場合に停止する。別の例示的なポリシーでは、マルチキャスト送信側は、データ・パケットの再伝送の試行を、当該パケットの再伝送回数が再試行限度／しきい値に達した場合に停止する。これらの例示的なポリシーは、単独で使用することもできるし、組み合わせて使用することもできる。

図６は、本発明の例示的な実施例によるマルチキャスト伝送手続きを示す流れ図である。６０５で、複数のデータ・ユニット／パケット／フレームを、所期の受信側に対してマルチキャストする。６１０で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑカウンタを初期化し、６１５でＭ−ＢｌｏｃｋＡｃｋＲｅｑをマルチキャストする。６２０で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑカウンタを増分し、６２５で、タイマをセット／初期化する。６３０で、データを伝送／マルチキャストしている局が、Ｍ−ＢｌｏｃｋＡｃｋを受信し始める。６３５で、タイムアウトになったかどうか（６２５でセット／初期化されたタイマが満了になったかどうか）を判定する試験を実行する。タイムアウトになっていない場合には、処理は６３０に戻る。タイムアウトになっている場合には、６４０で、全ての所期の受信側／宛先／受信局からＭ−ＢｌｏｃｋＡｃｋが受信されたかどうかを判定する試験を実行する。全ての所期の受信側／宛先／受信局からＭ−ＢｌｏｃｋＡｃｋが受信されている場合には、処理は６５０に進む。全ての所期の受信側／宛先／受信局からＭ−ＢｌｏｃｋＡｃｋが受信されていない場合には、６４５で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑカウンタがＭ−ＢｌｏｃｋＡｃｋＲｅｑ再試行限度／しきい値を超えたかどうかを判定する試験を実行する。これは、予想Ｍ−ＢｌｏｃｋＡｃｋに対する受信Ｍ−ＢｌｏｃｋＡｃｋの比がしきい値を超えている場合などには、上述の別のポリシーに基づく試験として実施されることもある。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑカウンタがＭ−ＢｌｏｃｋＡｃｋＲｅｑ再試行限度／しきい値を超えている場合には、６５０で、Ｍ−ＢｌｏｃｋＡｃｋを検査して、マルチキャスト／伝送されたデータの状態を判定する。６５５で、各マルチキャスト・パケット（マルチキャスト・データ）を、Ｍ−ＢｌｏｃｋＡｃｋによって応答した所期の受信側が受信したかどうか、またはパケット／データの伝送寿命（有効期間）を超えた（満了になった）かどうかを判定する試験を実行する。Ｍ−ＢｌｏｃｋＡｃｋによって応答した全ての所期の受信側がマルチキャスト・パケット（マルチキャスト・データ）を受信していない場合、またはパケット／データの伝送寿命（有効期間）を超えていない（満了になっていない）場合には、６６０で、送信側／伝送側は、未受信／未確認応答のパケットを所期の受信側／宛先／受信局に再伝送／再マルチキャストするように手配する。６６５で、状態が要求された全てのデータ／パケットの状態が検査および更新されているかどうかを判定する試験を実行する。状態が要求された全てのデータ／パケットの状態が検査および更新されていない場合には、処理は６５０に戻る。状態が要求された全てのデータ／パケットの状態が検査および更新されている場合には、処理は６０５に戻る。マルチキャスト・パケット（マルチキャスト・データ）を、Ｍ−ＢｌｏｃｋＡｃｋによって応答した全ての所期の受信側が受信した場合、またはパケット／データの伝送寿命（有効期間）を超えている（満了になっている）場合には、処理は６６５に進む。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑカウンタがＭ−ＢｌｏｃｋＡｃｋＲｅｑ再試行限度／しきい値を超えていない場合には、６７０で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑを更新し、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対して応答した受信側／宛先／受信局を、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑのブロック確認応答要求対象リストから除去する。その後、処理は６１５に進む。

図７は、本発明の例示的な実施例によるマルチキャスト受信手続きを示す流れ図である。７０５で、受信側／宛先／受信局は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑを受信する。７１０で、この受信側／宛先／受信局が所期の受信側（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対するブロック確認応答の返答／応答を要求される受信側）であるかどうかを判定する試験を実行する。この受信側／宛先／受信局が所期の受信側（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対するブロック確認応答の返答／応答を要求される受信側）ではない場合には、処理は終了する。この受信側／宛先／受信局が所期の受信側（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対するブロック確認応答の返答／応答を要求される受信側）である場合には、７１５で、この受信側が受信し、且つ（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑにおいて）その確認応答が要求されているマルチキャスト・データ／パケットの状態を判定し、Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを準備／生成する。７２０で、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑにおいて供給／提供される情報によって決まる順序／シーケンスで、準備したＭ−ＢｌｏｃｋＡｃｋを（ユニキャストで）伝送する。

代替の実施例では、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号内の受信側情報フィールドは、タイプ／フラグ・サブフィールド、ＢＡＲ受信側ビットマップ制御サブフィールド、ＢＡＲ受信側部分仮想ビットマップなどを含む。図８は、本発明の例示的な実施例による、ＢＡＲ受信側ビットマップ制御およびＢＡＲ受信側部分仮想ビットマップを用いた、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑフレーム／信号／メッセージ内の受信側情報フィールドの例示的なフォーマットを示す図である。ＢＡＲ受信側ビットマップ制御フィールドは、１オクテットである。このフィールドのうちの７つのビット（ビット１〜７）が、ビットマップ・オフセットを形成する。１ビット（０ビット）は、予約されている。部分仮想ビットマップの長さは変化するが、オクテットの倍数であり、これは、フレーム全体のサイズによって決定することができる。ビットマップ・オフセット・サブフィールドの値は、局のアソシエーションＩＤ（ＡＩＤ）を１６で割ったものである。その値がＮである場合には、１６×Ｎ未満のＡＩＤを有する局は、このＭ−ＢｌｏｃｋＡｃｋＲｅｑに対してＭ−ＢｌｏｃｋＡｃｋで返答する局のリストには含まれない。部分仮想ビットマップ・フィールドの各ビットは、特定の局に対応する。ビットマップ・フィールド中のビット番号ｉ（０≦ｉ≦２００７）、すなわち各オクテットの低位ビットをビット番号０、高位ビットをビット番号７としてビットマップ・フィールドのオクテット数

のビット番号（８を法とするｉ）は、ＡＩＤが１６×Ｎ＋ｉである局に対応する。ビットマップ・フィールドのビットｉが１に設定された場合には、ＡＩＤが１６×Ｎ＋ｉとなる局は、このＭ−ＢｌｏｃｋＡｃｋＲｅｑに対して返答することを要求される返答要求対象局のリスト中にある。ここで、Ｎは、ビットマップ・オフセット・フィールドの値である。部分仮想ビットマップ・フィールドの長さがＬオクテットである場合には、１６×Ｎ＋８×Ｌ以上のＡＩＤを有する局は、返答要求対象局のリスト中にない。所期の受信側／宛先／受信局は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑのＢＡＲ受信側ビットマップ中で受信側が指定されているのと同じ順序／シーケンスで、それぞれのＭ−ＢｌｏｃｋＡｃｋ信号を送信する。あるいは、受信側／受信局／宛先は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑのＢＡＲ受信側ビットマップ中に指定された受信側のシーケンスによって決まる順序で、それぞれのＭ−ＢｌｏｃｋＡｃｋ信号を送信する。

例えば、ビットマップ制御フィールドの値は５０である。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの部分仮想ビットマップのサイズは、２オクテットである。ビットマップは、１０１１１１１１０１１１１１１１である。ＡＩＤが１６×５０＝８００未満である全ての局は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑにおいてアドレス指定されていないので、Ｍ−ＢｌｏｃｋＡｃｋを送信しない。ＡＩＤが８００＋２×８＝８１６以上である局も、Ｍ−ＢｌｏｃｋＡｃｋを送信しない。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの部分ビットマップのｉ番目の位置は、ＡＩＤが８００＋ｉである局を示す。ビット・パターン１０１１１１１１０１１１１１１１に基づき、ＡＩＤが８００、８０２、８０３、８０４、８０５、８０６、８０７、８０９、８１０、８１１、８１２、８１３、８１４、８１５に等しい局は、それぞれの対応するビットが１に設定されるので、順次Ｍ−ＢｌｏｃｋＡｃｋを送信する。ＡＩＤが８０１および８０８に等しい局は、それぞれの対応するビットが０に設定されるので、Ｍ−ＢｌｏｃｋＡｃｋを送信しない。なお、ビットマップ制御フィールドおよび部分ビットマップを使用することにより、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対してＭ−ＢｌｏｃｋＡｃｋによって応答する必要がある受信局を表現するために３オクテット必要であることに留意されたい。返答を要求される受信局を示すために１６ビット識別子のセットをＭ−ＢｌｏｃｋＡｃｋＲｅｑが含む場合には、Ｍ−ＢｌｏｃｋＡｃｋは、１４オクテット必要となる。返答を要求される受信局を示すためにＭ−ＢｌｏｃｋＡｃｋＲｅｑでビット・ベクトルを使用した場合には、Ｍ−ＢｌｏｃｋＡｃｋは、少なくとも１２オクテット必要となる。従って、本発明のビットマップ制御フィールドおよび部分ビットマップは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号のオーバヘッドを減少させる。これにより、ＡＰと関連付けられた関連する局の数が大きく、且つ／またはマルチキャストの対象となる所期の受信側の数が大きいときに、効率的なアドレス指定方法が提供される。

図９Ａは、本発明の代替実施例における、遅延確認応答ポリシーを用いたマルチキャスト・ブロック確認応答要求（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）とマルチキャスト・ブロック確認応答（Ｍ−ＢｌｏｃｋＡｃｋ）の交換を用いる、高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。送信側／ＡＰ／発信側は、マルチキャスト・データ・ユニット／パケット／フレームのブロックを、複数の受信側／ＳＴＡに伝送する。例えば、受信側１および２には伝送するが、受信側３には伝送しない。各データ・ユニット／パケット／フレームは、シーケンス番号またはフレーム識別子を含む。シーケンス番号は、例えば１ずつ増分する。データ・ユニット／パケット／フレームは、ＣＳＭＡまたはＴＤＭＡ、あるいはポーリングまたはマルチ・ポーリングを用いて伝送される。マルチキャスト・データのブロックを送信した後で、送信側は、マルチキャストＢｌｏｃｋＡｃｋＲｅｑ（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）信号／フレーム／メッセージを、所期のマルチキャスト受信側に伝送する。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号／メッセージ／フレームは、ブロック確認応答要求（ＢＡＲ）制御フィールド、ブロック確認応答要求（ＢＡＲ）情報フィールド、および高信頼マルチキャスト受信側（ＲＭＲ）情報フィールドを含む。ＢＡＲ制御フィールドおよびＢＡＲ情報フィールドは、それについてマルチキャストＢｌｏｃｋＡｃｋ（Ｍ−ＢｌｏｃｋＡｃｋ）フレームが要求される１つまたは複数のトラフィック識別子（ＴＩＤ）と、ブロック確認応答開始シーケンス番号とを含む。開始シーケンス番号は、このＭ−ＢｌｏｃｋＡｃｋＲｅｑがＭ−ＢｌｏｃｋＡｃｋを要求している最初のフレームのシーケンス番号である。高信頼マルチキャスト受信側情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示す、ブロック確認応答要求対象受信側識別子のリストを含む。図９Ａの例では、受信側１および２の識別子が含まれる。識別子は、局のＭＡＣアドレスでも、アソシエーションＩＤでも、ＩＰアドレス（本発明がＩＰレイヤで実行される／動作する場合）でもよい。あるいは、ＲＭＲ情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示すために、ビットマップ制御フィールドおよびビットマップ・フィールドを含む。ビットマップ中の各ビットは、ブロック確認応答を要求される受信局を識別する。ブロック確認応答要求対象受信側識別子リストまたはビットマップ中の各マルチキャスト受信側／受信局（図９Ａの例では受信側１および２）は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑリストまたはビットマップに指定されているマルチキャスト受信側の順序／シーケンスで、ブロック確認応答（Ａｃｋ）信号／フレームまたはその他のフレーム／信号によってＭ−ＢｌｏｃｋＡｃｋＲｅｑ発信側に対して応答し、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑをうまく受信したことを知らせる。あるいは、受信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ識別子リストまたはＭ−ＢｌｏｃｋＡｃｋＲｅｑビットマップ中の受信側識別子のシーケンスによって決まる順序で、それぞれのブロックＡｃｋ信号／フレーム／メッセージを送信する。その後、マルチキャスト受信側は、Ｍ−ＢｌｏｃｋＡｃｋを準備し、送信機会を得た後で、その遅延Ｍ−ＢｌｏｃｋＡｃｋ応答を送信する。Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージの内容を準備したら、マルチキャスト受信側は、可能な限り最も早い送信機会（ＴＸＯＰ）に、遅延Ｍ−ＢｌｏｃｋＡｃｋを送信する。Ｍ−ＢｌｏｃｋＡｃｋは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ信号／フレーム／メッセージに指定されている開始シーケンス番号を有するデータ・ユニット／パケット／フレームのブロックの受信状態を知らせる。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの発信側は、Ａｃｋ信号／フレーム／メッセージまたはその他の信号／フレーム／メッセージによって応答して、Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを受信したことを知らせる。Ｍ−ＢｌｏｃｋＡｃｋ発信側は、Ａｃｋ信号／メッセージ／フレームを、ユニキャストで伝送する。ＢｌｏｃｋＡｃｋＲｅｑリストまたはビットマップに指定されていないＳＴＡは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの発信側に応答しない。図９Ａの例では、受信側３は、ブロック確認応答要求対象受信側識別子リストまたはＭ−ＢｌｏｃｋＡｃｋＲｅｑのビットマップに含まれないので、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対して応答しない。

図９Ｂは、本発明の代替の実施例における、遅延確認応答ポリシーを用いるがＭ−ＢｌｏｃｋＡｃｋＲｅｑおよびＭ−ＢｌｏｃｋＡｃｋの確認応答は用いないマルチキャストＢｌｏｃｋＡｃｋＲｅｑおよびマルチキャストＢｌｏｃｋＡｃｋの交換を用いる、高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。送信側／ＡＰ／発信側は、マルチキャスト・データ・ユニット／パケット／フレームのブロックを、複数の受信側／ＳＴＡに伝送する。例えば、受信側１および２には伝送するが、受信側３には伝送しない。マルチキャスト・データのブロックを送信した後で、発信側は、マルチキャストＢｌｏｃｋＡｃｋＲｅｑ（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）信号／フレーム／メッセージを、所期のマルチキャスト受信側に伝送する。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの高信頼マルチキャスト受信側（ＲＭＲ）情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示す、ブロック確認応答要求対象受信側識別子のリストを含む。図９Ｂの例では、受信側１および２の識別子が含まれる。あるいは、ＲＭＲ情報フィールドは、Ｍ−ＢｌｏｃｋＡｃｋを要求される受信側を示すために、ビットマップ制御フィールドおよびビットマップ・フィールドを含む。ビットマップ中の各ビットは、ブロック確認応答を要求される受信局を識別する。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの確認応答機構／ポリシーを使用しない場合、ブロック確認応答要求対象受信側識別子リストまたはビットマップ中の各マルチキャスト受信側／受信局（図９Ｂの例では受信側１および２）が、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑを受信しても、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの発信側に対して、確認応答（Ａｃｋ）信号／フレーム／メッセージによって応答することはない。遅延ブロック確認応答ポリシーにより、ブロック確認応答要求対象リストまたはビットマップ中のマルチキャスト受信側は、Ｍ−ＢｌｏｃｋＡｃｋを準備し、送信機会を得た後で、遅延Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージによってＭ−ＢｌｏｃｋＡｃｋＲｅｑの発信側に応答する。マルチキャスト受信側は、Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージの内容を準備したら、可能な限り最も早い送信機会に、Ｍ−ＢｌｏｃｋＡｃｋを送信する。Ｍ−ＢｌｏｃｋＡｃｋの確認応答機構／ポリシーを使用しない場合には、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの発信側は、Ｍ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージを受信したことを知らせるためにＡｃｋ信号／フレーム／メッセージによって応答することはしない。ＢｌｏｃｋＡｃｋＲｅｑリストまたはビットマップに指定されていないＳＴＡは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑの発信側に応答しない。図９Ｂの例では、受信側３は、ブロック確認応答要求対象受信側識別子リストまたはＭ−ＢｌｏｃｋＡｃｋＲｅｑのビットマップに含まれないので、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑに対して応答しない。一般に、遅延ブロック確認応答ポリシーを用いると、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑまたはＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージは、確認応答ポリシー・フィールドを含む。Ｍ−ＢｌｏｃｋＡｃｋＲｅｑまたはＭ−ＢｌｏｃｋＡｃｋ信号／フレーム／メッセージに確認応答ポリシー・フィールドが設定された場合、その確認応答ポリシー・フィールドは、そのフレーム／信号／メッセージの受信時に、それに対する確認応答が期待されていないことを示す。そうでない場合には、確認応答が期待される。確認応答ポリシー・フィールドの設定は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑフレーム／信号／メッセージおよびＭ−ＢｌｏｃｋＡｃｋフレーム／信号／メッセージに対して、独立して行うこともできる。これらのフィールドの値の４通りの組合せは、全て使用することができる。

図９Ｃは、本発明の例示的な実施例における、マルチキャストＢｌｏｃｋＡｃｋＲｅｑとマルチキャストＢｌｏｃｋＡｃｋの交換をマルチ・ポーリング（ＭＰ）と共に用いた高信頼マルチキャスト伝送のタイミング・シーケンスを示す図である。マルチ・ポーリングの発信側／送信側／ＡＰは、マルチ・ポーリング（ＭＰ）フレームを伝送する。ＭＰフレームは、ダウンリンク（ＭＰ発信側／ＡＰから受信側／ＳＴＡに向かう方向）伝送時間（ＤＴＴ）および／またはアップリンク（ＳＴＡからＭＰ発信側／ＡＰに向かう方向）伝送時間（ＵＴＴ）のスケジュール／時間割当てを含む。ＭＰ発信側／ＡＰは、複数のＤＴＴおよびＵＴＴをスケジューリングすることができる。ＤＴＴまたはＵＴＴは、開始時間および持続時間を有する。ＤＴＴ期間は、ＭＰ発信側／ＡＰが、マルチキャストまたはユニキャスト・アドレスに関連するマルチキャストまたはユニキャスト・データ・ユニット／フレーム／パケットのブロックを伝送するために使用する。ＵＴＴ期間は、ＳＴＡが、ＭＰ発信側／ＡＰにデータ・ブロックを伝送するために使用する。ＭＰ発信側／ＡＰは、複数の受信側／ＳＴＡに対してマルチキャスト・データ・ユニット／パケット／フレームのブロックを伝送した後で、マルチキャストＢｌｏｃｋＡｃｋＲｅｑ（Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ）信号／フレーム／メッセージを伝送する。マルチキャスト受信側／受信局／宛先は、それ自体のＵＴＴにおいて、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ発信側に対してＭ−ＢｌｏｃｋＡｃｋ信号／フレームによって応答し、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑによって要求されたデータ・ユニット／パケット／フレームのブロックの受信状態を知らせる。図９Ｃの例に示すように、ＡＰ／ＭＰ発信側は、あるマルチキャスト・アドレスを有するマルチキャスト・データの第１のブロックと、別のマルチキャスト・アドレスを有するマルチキャスト・データの第２のブロックと、マルチキャスト・データおよび／またはユニキャストデータのその他のブロックとを伝送する。マルチキャスト・データの第１のブロックを伝送した後で、ＡＰ／ＭＰ発信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ１を送信する。マルチキャスト・データの第１のブロックの所期の受信側／ＳＴＡ、例えば受信側１および２は、それぞれのＵＴＴ期間中に、それぞれのＭ−ＢｌｏｃｋＡｃｋによって、それぞれＭ−ＢｌｏｃｋＡｃｋＲｅｑ１に応答する。Ｍ−ＢｌｏｃｋＡｃｋの他に、受信側／ＳＴＡは、そのＵＴＴ期間中にその他のアップリンク・データを送信することもできる。同様に、マルチキャスト・データの第２のブロックを伝送した後で、ＡＰ／ＭＰ発信側は、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑ２を送信する。マルチキャスト・データの第２のブロックの所期の受信側／ＳＴＡ、例えば受信側３および４は、それぞれのＵＴＴ期間中に、それぞれのＭ−ＢｌｏｃｋＡｃｋによって、それぞれＭ−ＢｌｏｃｋＡｃｋＲｅｑ２に応答する。あるいは、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑは、異なるＭＰＤＴＴ（マルチキャスト・データ・ユニット／パケット／フレームの対応するブロックが送信されたのと同じでないＤＴＴ）において送信する、または異なるＭＰシーケンス／バーストで送信することもできる。さらに、マルチキャスト・データ・ユニット／パケット／フレームのブロックを複数のＭＰＤＴＴにおいて送信することもでき、この場合には、Ｍ−ＢｌｏｃｋＡｃｋＲｅｑは、データのブロックが伝送される最後のＭＰＤＴＴまたは後続／後のＭＰＤＴＴにおいてマルチキャスト送信側が送信して、このマルチキャスト・データ・ユニット／パケット／フレームのブロックの確認応答となるＭ−ＢｌｏｃｋＡｃｋを要求する。

本発明は、無線メッシュ・ネットワーク、アドホック・ネットワークまたは独立基本サービス・セット（ＩＢＳＳ）におけるマルチキャスト伝送およびブロードキャスト伝送のために、局（ＳＴＡは局、ＡＰおよびメッシュＡＰを含む）がブロック確認応答要求とブロック確認応答を交換するために使用することもできる。本発明は、局間のピア・ツー・ピア・マルチキャストに使用することができる。局は、本発明の方法を使用して、例えばテレビ会議などのピア・ツー・ピア・サービスにおいて、伝送したマルチキャスト・データに関するマルチキャスト・ブロック確認応答要求を、複数の受信局に送信することができる。受信局は、マルチキャスト・ブロック確認応答によって、マルチキャスト・ブロック確認応答要求発信側に応答する。

次に図１０を参照すると、本発明の例示的な実施態様を示すブロック図が示してある。ＳＴＡおよび／またはＡＰ（ＡＰは特殊なＳＴＡである）は、伝送機、受信機、または送受信機とすることができるので、無線伝送機／受信機を有する無線通信モジュールを示す信号ブロック図を使用する。すなわち、ここに示す無線伝送機／受信機は、伝送機であっても、受信機であっても、送受信機であってもよい。本発明は、ホスト計算システムおよび通信モジュール（無線）を含む。ホスト処理システムは、汎用コンピュータまたは特殊目的計算システムとすることができる。ホスト計算システムは、中央処理装置（ＣＰＵ）、メモリ、および入出力（Ｉ／Ｏ）インタフェースを含むことができる。無線通信モジュールは、ＭＡＣおよびベースバンド・プロセッサ、無線伝送機／受信機、および１本または複数本のアンテナを含むことができる。アンテナは、無線信号を伝送し、受信する。無線伝送機／受信機は、無線信号処理を実行する。ＭＡＣおよびベースバンド・プロセッサは、伝送／受信のための、ＭＡＣ制御およびデータ・フレーミング、変調／復調、符号化／復号を実行する。本発明の少なくとも１つの実施例を、ホスト計算システムまたは無線通信モジュールにおいてルーチンとして実施して、データおよび制御信号の伝送および受信を処理することができる。すなわち、図１０のブロック図は、ハードウェア、ソフトウェア、ファームウェア、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、縮小命令セット・コンピュータ（ＲＩＳＣ）、またはこれらの任意の組合せとして実施することができる。さらに、上記の様々な流れ図および記述に示した例示的なプロセスは、実用においては、ホスト処理システムまたは無線通信モジュール、あるいはホスト処理システムと通信モジュールを組み合わせたものにおいて実施される。従って、このブロック図は、様々な方法／プロセスを、ハードウェア、ソフトウェア、ファームウェア、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、縮小命令セット・コンピュータ（ＲＩＳＣ）、またはこれらの任意の組合せで実施することを十分に可能にするものである。

本発明は、様々な形態のハードウェア、ソフトウェア、ファームウェア、特殊目的プロセッサ、またはそれらの組合せで実施することができることを理解されたい。本発明は、ハードウェアとソフトウェアの組合せとして実施されることが好ましい。さらに、ソフトウェアは、プログラム記憶装置に実装されるアプリケーション・プログラムとして実施されることが好ましい。アプリケーション・プログラムは、任意の適当なアーキテクチャを備えた任意のマシンにアップロードし、このマシンによって実行することができる。このマシンは、１つまたは複数の中央処理装置（ＣＰＵ）などのハードウェアと、ランダム・アクセス・メモリ（ＲＡＭ）と、１つまたは複数の入出力（Ｉ／Ｏ）インタフェースとを有するコンピュータ・プラットフォームに実装されることが好ましい。コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも含む。本明細書に記載する様々なプロセスおよび機能は、オペレーティング・システムを介して実行される、マイクロ命令コードの一部またはアプリケーション・プログラムの一部（あるいはそれらの組合せ）とすることができる。さらに、追加のデータ記憶装置や印刷装置など、その他の様々な周辺機器を、コンピュータ・プラットフォームに接続することもできる。

さらに、添付の図面に示すシステム構成要素および方法ステップの一部はソフトウェアで実施することが好ましいので、それらのシステム構成要素間（またはプロセス・ステップ間）の実際の接続は、本発明をプログラミングする方法によって異なっていてもよいことも理解されたい。本明細書の教示があれば、当業者なら、上記の、またそれに類似した、本発明の実施態様または構成を企図することができるであろう。

Claims

マルチキャスト・ブロック確認応答要求信号を受信することを含む方法であって、
前記マルチキャスト・ブロック確認応答要求信号が、
マルチキャスト・ブロック確認応答が要求されるマルチキャスト・トラフィック・ストリームの識別を示すフィールドと、
前記マルチキャスト・ブロック確認応答が要求される第１のフレームのシーケンス番号を示すフィールドと、
前記マルチキャスト・ブロック確認応答によって応答することを要求される受信側装置のリストを示すマルチキャスト受信側装置アドレス・フィールドと、
を含み、前記マルチキャスト受信側装置アドレス・フィールドが、ビットマップ制御フィールド及び部分仮想ビットマップであり、前記ビットマップ制御フィールドが、アソシエーション識別子を１６で割ったものに相当するビットマップ・オフセットを含み、前記ビットマップ・オフセットに１６を掛けて前記部分仮想ビットマップと組み合されたものが、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置を識別し、前記ビットマップ制御フィールド及び前記部分仮想ビットマップの使用が、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置のアドレスのために必要なバイト数を低減させる、前記方法。
前記マルチキャスト・ブロック確認応答要求信号が、フレーム制御フィールドをさらに含み、前記フレーム制御フィールドが、フレーム・タイプ、フレーム・サブタイプ、及び、フラグを識別する、請求項１に記載の方法。
前記マルチキャスト・ブロック確認応答要求信号が、持続時間フィールドをさらに含み、前記持続時間フィールドが、前記マルチキャスト・ブロック確認応答要求信号、及びデータの通信に使用されている媒体が前記マルチキャスト・ブロック確認応答要求信号の送信側によって確保されている残り時間を指定する、請求項１に記載の方法。
前記マルチキャスト受信側装置アドレス・フィールドが、前記受信側装置のリストの前記アドレスを含む場合に、媒体アクセス制御アドレスを有する、請求項１に記載の方法。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答要求制御フィールド及びブロック確認応答要求情報フィールドをさらに含み、前記ブロック確認応答要求制御フィールドが、トラフィック識別子を指定し、さらに、前記ブロック確認応答要求情報フィールドが、開始フレーム・シーケンス番号を指定し、さらに、前記トラフィック識別子が、トラフィックのカテゴリを識別し、前記開始フレーム・シーケンス番号が、前記マルチキャスト・ブロック確認応答が要求されるデータの第１のフレームのシーケンス番号である、請求項１に記載の方法。
前記ブロック確認応答要求制御フィールドが、確認応答ポリシー及びフォーマット指標を指定する、請求項５に記載の方法。
前記マルチキャスト・ブロック確認応答要求信号が、受信側装置情報フィールドをさらに含み、前記受信側装置情報フィールドが、前記受信側装置情報フィールドのフォーマットを指定するサブフィールド、及び、前記マルチキャスト・ブロック確認応答要求信号の受信側装置を指定する識別子を含む、請求項１に記載の方法。
ブロック確認応答要求信号をマルチキャストすることを含む方法であって、
前記マルチキャスト・ブロック確認応答要求信号が、
マルチキャスト・ブロック確認応答が要求されるマルチキャスト・トラフィック・ストリームの識別を示すフィールドと、
前記マルチキャスト・ブロック確認応答が要求される第１のフレームのシーケンス番号を示すフィールドと、
前記マルチキャスト・ブロック確認応答によって応答することを要求される受信側装置のリストを示すマルチキャスト受信側装置アドレス・フィールドと、
を含み、前記マルチキャスト受信側装置アドレス・フィールドが、ビットマップ制御フィールド及び部分仮想ビットマップであり、前記ビットマップ制御フィールドが、アソシエーション識別子を１６で割ったものに相当するビットマップ・オフセットを含み、前記ビットマップ・オフセットに１６を掛けて前記部分仮想ビットマップと組み合されたものが、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置を識別し、前記ビットマップ制御フィールド及び前記部分仮想ビットマップの使用が、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置のアドレスのために必要なバイト数を低減させる、前記方法。
前記マルチキャスト・ブロック確認応答要求信号が、フレーム制御フィールドをさらに含み、前記フレーム制御フィールドが、フレーム・タイプ、フレーム・サブタイプ、及び、フラグを識別する、請求項８に記載の方法。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答制御フィールドをさらに含み、前記ブロック確認応答制御フィールドが、フラグを指定するサブフィールド、及び、トラフィック識別情報のためのサブフィールドを含む、請求項８に記載の方法。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答情報フィールドをさらに含み、前記ブロック確認応答情報フィールドが、確認応答されるデータの第１のユニットのシーケンス番号を指定するサブフィールド、及び、この受信側装置が含まれるマルチキャスト・グループに送信されるデータ・ユニットの受信状態を示すビットマップを含む、請求項８に記載の方法。
マルチキャスト・ブロック確認応答要求信号を受信する手段を備える装置であって、
前記マルチキャスト・ブロック確認応答要求信号が、
マルチキャスト・ブロック確認応答が要求されるマルチキャスト・トラフィック・ストリームの識別を示すフィールドと、
前記マルチキャスト・ブロック確認応答が要求される第１のフレームのシーケンス番号を示すフィールドと、
前記マルチキャスト・ブロック確認応答によって応答することを要求される受信側装置のリストを示すマルチキャスト受信側装置アドレス・フィールドと、
を含み、前記マルチキャスト受信側装置アドレス・フィールドが、ビットマップ制御フィールド及び部分仮想ビットマップであり、前記ビットマップ制御フィールドが、アソシエーション識別子を１６で割ったものに相当するビットマップ・オフセットを含み、前記ビットマップ・オフセットに１６を掛けて前記部分仮想ビットマップと組み合されたものが、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置を識別し、前記ビットマップ制御フィールド及び前記部分仮想ビットマップの使用が、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置のアドレスのために必要なバイト数を低減させる、前記装置。
前記マルチキャスト・ブロック確認応答要求信号が、フレーム制御フィールドをさらに含み、前記フレーム制御フィールドが、フレーム・タイプ、フレーム・サブタイプ、及び、フラグを識別する、請求項１２に記載の装置。
前記マルチキャスト・ブロック確認応答要求信号が、持続時間フィールドをさらに含み、前記持続時間フィールドが、前記マルチキャスト・ブロック確認応答要求信号及びデータの通信に使用されている媒体が前記マルチキャスト・ブロック確認応答要求信号の送信側によって確保されている残り時間を指定する、請求項１２に記載の装置。
前記マルチキャスト受信側装置アドレス・フィールドが、前記受信側装置のリストの前記アドレスを含む場合に、媒体アクセス制御アドレスを有する、請求項１２に記載の装置。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答要求制御フィールド及びブロック確認応答要求情報フィールドをさらに含み、前記ブロック確認応答要求制御フィールドが、トラフィック識別子を指定し、さらに、前記ブロック確認応答要求情報フィールドが、開始フレーム・シーケンス番号を指定し、さらに、前記トラフィック識別子が、トラフィックのカテゴリを識別し、前記開始フレーム・シーケンス番号が、前記マルチキャスト・ブロック確認応答が要求されるデータの第１のフレームのシーケンス番号である、請求項１２に記載の装置。
前記ブロック確認応答要求制御フィールドが、確認応答ポリシー及びフォーマット指標を指定する、請求項１６に記載の装置。
前記マルチキャスト・ブロック確認応答要求信号が、受信側装置情報フィールドをさらに含み、前記受信側装置情報フィールドが、前記受信側装置情報フィールドのフォーマットを指定するサブフィールド、及び、前記マルチキャスト・ブロック確認応答要求信号の受信側装置を指定する識別子を含む、請求項１２に記載の装置。
ブロック確認応答要求信号をマルチキャストする手段を備える装置であって、
前記マルチキャスト・ブロック確認応答要求信号が、
マルチキャスト・ブロック確認応答が要求されるマルチキャスト・トラフィック・ストリームの識別を示すフィールドと、
前記マルチキャスト・ブロック確認応答が要求される第１のフレームのシーケンス番号を示すフィールドと、
前記マルチキャスト・ブロック確認応答によって応答することを要求される受信側装置のリストを示すマルチキャスト受信側装置アドレス・フィールドと、
を含み、前記マルチキャスト受信側装置アドレス・フィールドが、ビットマップ制御フィールド及び部分仮想ビットマップであり、前記ビットマップ制御フィールドが、アソシエーション識別子を１６で割ったものに相当するビットマップ・オフセットを含み、前記ビットマップ・オフセットに１６を掛けて前記部分仮想ビットマップと組み合されたものが、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置を識別し、前記ビットマップ制御フィールド及び前記部分仮想ビットマップの使用が、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置のアドレスのために必要なバイト数を低減させる、前記装置。
前記マルチキャスト・ブロック確認応答要求信号が、フレーム制御フィールドをさらに含み、前記フレーム制御フィールドが、フレーム・タイプ、フレーム・サブタイプ、及び、フラグを識別する、請求項１９に記載の装置。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答制御フィールドをさらに含み、前記ブロック確認応答制御フィールドが、フラグを指定するサブフィールド、及び、トラフィック識別情報のためのサブフィールドを含む、請求項１９に記載の装置。
前記マルチキャスト・ブロック確認応答要求信号が、ブロック確認応答情報フィールドをさらに含み、前記ブロック確認応答情報フィールドが、確認応答されるデータの第１のユニットのシーケンス番号を指定するサブフィールド、及び、この受信側装置が含まれるマルチキャスト・グループに送信されるデータ・ユニットの受信状態を示すビットマップを含む、請求項１９に記載の装置。
マルチキャスト・ブロック確認応答要求信号を記憶する一時的でないコンピュータ可読記憶媒体であって、
前記マルチキャスト・ブロック確認応答要求信号が、
持続時間フィールドと、
マルチキャスト受信側装置アドレス・フィールドであって、前記マルチキャスト受信側装置アドレス・フィールドが、ビットマップ制御フィールド及び部分仮想ビットマップであり、前記ビットマップ制御フィールドが、アソシエーション識別子を１６で割ったものに相当するビットマップ・オフセットを含み、前記ビットマップ・オフセットに１６を掛けて前記部分仮想ビットマップと組み合されたものが、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置を識別し、前記ビットマップ制御フィールド及び前記部分仮想ビットマップの使用が、前記マルチキャスト・ブロック確認応答が要求される前記受信側装置のアドレスのために必要なバイト数を低減させる、前記マルチキャスト受信側装置アドレス・フィールドと、
送信側アドレス・フィールドと、
を含む、前記コンピュータ可読記憶媒体。