JP5654108B2 - 無線ネットワークにおけるマルチキャストのためのセル依存性マルチグループハイブリッド自動再送要求方法 - Google Patents

Description

本発明は、無線通信に関し、特に、データのセル依存性再送信の方法に関する。

無線マルチメディアアプリケーションに関する興味と需要は急速に増大している。ワイヤレスネットワーク上のマルチキャストは、効率的なデータの分散を可能にする。そのデータは、多くの受信機に対するマルチメディアデータ及び娯楽番組（ビデオ、オーディオ、ファイル、及びテキスト）を同時含むがこれらに限定されない。しかしながら、マルチメディアデータ配信には、高信頼性と帯域効率が必要とされる。無線リンクは、時間変動及びバーストリンクエラーによって信頼性が低い。特にマルチキャストアプリケーションにおいて、同一のプログラムに関する異なる受信機のチャンネル条件は異なり得るし、受信機は、セッションの間、離れるか又は参加し得るので、受信機の接続状態が変更してしまう。例えば、現行のＩＥＥＥ８０２．１１ネットワークである多くの無線ネットワークにおけるマルチキャストに対しては、リンクレイヤ再転送はなく、リンクレイヤの適応がない。無線デバイスは、無線アクセスポイント（ＡＰ）／基地局（ＢＳ）から別の場所へ配され得る。本明細書に使用されるように、「／」は、同一又は類似の要素若しくは構造に対する代替の名称を意味する。すなわち、「／」は、本明細書に使用されるように「又は」の意味として捉えられ得る。ワイヤレス機器は、ラップトップ、デュアルモードスマートフォン、携帯情報端末（ＰＤＡ）、端末装置、クライアント、クライアントデバイス、モバイルデバイス、モバイル端末、マルチキャストクライアント、マルチキャストクライアントデバイス、受信機等を含む。データフレームの送信は中断され、多くのデータパケットが伝送の期間中に受信機に対して失われる。その上、複数の無線ＡＰ／ＢＳが高速有線ネットワークを介してマルチキャストサーバ／ソースに接続される。あるセルにおけるクライアントのチャンネル条件は、別のセルにおけるクライアントのチャンネル条件とは劇的に異なり得る。

ユニキャスト通信は、２つのエンティティ間の１対１の通信である。放送通信は、通信システムにおける１つのエンティティと他のすべてのエンティティとの間の通信である。マルチキャスト通信は、通信システムにおける１つのエンティティと複数の他のエンティティと間における１対多数の通信である。かかる通信において、複数の他のエンティティは、通信システムの他のすべてのエンティティを含み得る。多くの無線マルチキャストシステムにおいて、前方誤り訂正コード（ＦＥＣ）は、フィジカル層におけるパケット内で使用されて、多経路フェーディング及び干渉から保護し、かつ、パケットエラーを低減せしめる。無線ネットワークにおいて損失されたパケットを回復するために、ＦＥＣコードは、転送及びアプリケーションレイヤにおけるパケットにわたっても利用される。しかしながら、無線チャネル条件は時間変動しており、マルチキャストネットワークにおける複数のクライアントのチャンネル条件は異なる。最悪なチャンネル条件に応じて、ＦＥＣコードが通常使用されて、所望のサービスエリアにおける全ての受信機の受信品質が保証される。これは、大なるオーバヘッドを生じせしめ、かつ、再転送のために多くの無線通信リソースを必要とする。信頼性を改良する別の方法は、自動再送要求（ＡＲＱ）とも称される損失パケットの再転送を使用することである。マルチキャストシナリオにおいて、ＡＲＱはそれほど効率的でない。例えば、クライアントＡがパケット１を喪失し、クライアントＢがパケット２を喪失する場合、ソース／サーバはパケット１及びパケット２の両方を再送信する。

いくつかの報告されたマルチキャストシステムにおいて、ＡＲＱ及びＦＥＣを組み合わせ且つ単なるＡＲＱよりも効率的であるハイブリッドＡＲＱの概要を説明する。ハイブリッドＡＲＱにおける再送信されたパケットは、ＦＥＣコードによって作成されたパリティパケットであり、そのパリティパケットは、異なる受信機によって喪失された異なる情報パケットを補正するのに使用され得る。例えば、クライアントＡはパケット１を喪失し、クライアントＢはパケット２を喪失し、リード−ソロモンＦＥＣコードが、クロスパケット消去コード化を用いてパリティパケットを作成するのに使用される場合、ソース／サーバは、１つのＦＥＣパリティパケットを再送信／マルチキャストを行う必要があるだけである。クライアント１は、再送信理されたＦＥＣパリティパケットを使用して、パケット１を回復し得るし、クライアントＢは、同一のＦＥＣパリティパケットを使用して、パケット２を回復し得る。

しかしながら、先のマルチキャストＡＲＱ又はハイブリッドＡＲＱ方式においては、再送信されたパケットは、単一のマルチキャストグループ、ソースデータパケットと同一のマルチキャストグループ又は別々のマルチキャストグループ内において送信される。複数の受信機は時間変動を受け得るし、チャンネル条件は異なり得る。特定のセル内の１つの受信機が多くの再送信されたパケットを要求する場合、他のセルにおける受信機はそれ程多くの再送信されたパケットを必要としないものの、これら再送信されたパケットは、すべての無線のセルの中でマルチキャストを送るだろう。その結果、この方法は他のセルの無線バンド幅を無駄にしてしまう。

ＡＰ／ＢＳの数とクライアントの数に関する拡張性は、解決するべき重要な課題である。信頼でき且つスケーラブルな無線マルチキャストシステムを有すること及び無線のバンド幅を効率的に利用することは、有利であろう。

本出願は、２００８年６月４日に出願された「ストリーミングのデータポーズ機能」という名称の欧州特許出願第ＥＰ０８３０５２３０．８号に対する優先権の利益を主張し、かかる出願は本明細書に参考として援用されている。

下部構造／セルラー無線ネットワーク上における信頼性の高いマルチキャストに対するマルチ−グループハイブリッド自動再送要求（ＡＲＱ）（本明細書において回復とも称される）方法が本明細書において開示されている。本発明のハイブリッドＡＲＱ方法は、マルチキャストグループを無線デバイスに自動的に割り当てる。その無線デバイスは、アクセスポイント（ＡＰ）／基地局（ＢＳ）と関連付けられており、又は、セル依存性制御メッセージ交換のための無線セルに存在する。そのセル依存性制御メッセージ交換は、例えば、ＡＲＱ要求を送信し且つ再送信されたパケットを受信することを含む。１つのセルにおけるマルチキャストクライアントに対するコントロールメッセージ及び再送信されたデータは、他のセルにおける無線リンク上の他のＡＰ／ＢＳによって送信されないだろう。このように、単一セルにおける再送信に使用される無線バンド幅は、このセルにおけるマルチキャストクライアントのチャンネル条件に適合され、かつ、他のセルにおけるマルチキャストクライアントのチャンネル条件によっては影響されない。

ＡＲＱマルチキャストグループと称されるセル依存性制御メッセージ交換の及びＡＲＱ／再送信のためにマルチキャストアドレスをセルに自動的に割り当て、かつ、ＡＲＱ／リカバリサーバにＡＲＱマルチキャストグループの割り当てられたマルチキャストアドレスを知らせる方法も開示されている。その上、本願発明は、ＡＲＱマルチキャストグループが必要とされるときに、ＡＲＱサーバが、セルに対するセル依存性ＡＲＱマルチキャストグループに参加し、かつ、ＡＲＱマルチキャストグループが終了された後にＡＲＱマルチキャストグループから離れる方法について開示する

開示された方法及び装置は、アクセスポイントに関連付けるステップと、アクセスポイントアドレスを取得するステップと、マルチキャストグループアドレスを取得するステップとアクセスポイントアドレス及びマルチキャストグループアドレスを使用してリカバリマルチキャストアドレスを判定するステップと、を含む。また、開示された方法及び装置は、要求を送信してマルチキャストグループに参加するステップと、要求を送信してリカバリマルチキャストグループに参加するステップと、リカバリサーバに登録メッセージを送信するステップと、マルチキャストデータを受信するステップと、いずれかのデータが失われたかどうかを判定するステップと、別のデバイスがリカバリ要求メッセージを送信したかどうかを判定するステップと、他のデバイスが前記リカバリ要求メッセージを送信していない場合にはリカバリ要求メッセージを作成するステップと、登録応答メッセージが前記リカバリサーバから受信されたかどうかを判定するステップと、いずれかの再送信されたデータが先に受信されたかどうかを判定するステップと、再送信されたデータが先に受信されていない場合には前記リカバリ要求メッセージを前記リカバリサーバにユニキャストするステップと、を含む。さらに、開示された方法及び装置は、リカバリマルチキャストグループメッセージをリカバリサーバから受信するステップと、デバイスがリカバリマルチキャストグループのメンバであるかどうかを判定するステップと、前記リカバリマルチキャストグループに対する応答を送信するステップとを含む。

開示された方法及び装置は、アクセスポイントアドレス及びマルチキャストグループアドレスを使用してアドレスを判定するステップと、リカバリ要求メッセージを前記リカバリサーバに送信して、前記アドレスを使用してリカバリデータを要求するステップと、前記リカバリデータを前記リカバリサーバから受信するステップと、を含む。また、開示された方法及び装置は、登録メッセージを受信するステップと、前記登録メッセージに対する応答を送信するステップと、リカバリ要求メッセージを受信するステップと、前記リカバリ要求メッセージに応答してリカバリデータを送信するステップと、メッセージをリカバリマルチキャストグループに送信して、前記リカバリマルチキャストグループのステータスを判定するステップとを含む。

本願発明は、添付図面とともに読み取ると、以下の詳細な説明から特に理解される。図面は以下に簡潔に説明した図面を含み、図面において類似の番号は類似の要素を表している。

本発明の方法に応じて本発明の方法を説明するために用いられる例示的マルチキャストシステムの概略図である。 ＦＥＣコード化の実施例である。 クライアントがプログラムＸに対するＡＲＱマルチキャストアドレスを取得する本発明の原理に係る例示的方法を示すフローチャートである クラインアントがＡＲＱサーバに登録し且つＡＲＱサーバに要求を送信してパケット（ＦＥＣ及び／又はソース）をＡＲＱサーバから受信する本発明の原理に係る例示的な方法を図示するフロー図である。 クライアントから受信された登録メッセージを処理するＡＲＱサーバの本発明の原理に係る例示的方法を表すフロー図である。 クライアントから受信されたＡＲＱ要求メッセージを処理するＡＲＱサーバの本発明の原理に係る例示的方法を図示するフロー図である。 ＡＲＱサーバがＡＲＱマルチキャストグループにクエリを行う本発明の原理に係る例示的方法を図示するフロー図である。 ＡＲＱサーバからのＡＲＱマルチキャストグループクエリを処理するクライントに対する本発明の原理に係る例示的方法を図示するフロー図である。 本発明の原理に係る例示的クライアント／受信デバイスのブロック図である 本発明の原理に係る例示的リカバリサーバ／ＡＲＱサーバのブロック図である。

図１は、本発明の方法に応じて本発明の方法を説明するために用いられる例示的マルチキャストシステムの概略図である。無線デバイス／クライアント／受信機１０５は、マルチキャストサーバ１２０（例えば、ビデオストリーミングサーバ）に接続されている。かかる接続は、無線アクセスポイント（ＡＰ）／基地局（ＢＳ）１１０及びイーサーネットスイッチ／ルータ１１５を有する高速有線アクセスネットワーク１３０（例えば、イーサネット（登録商標））を介する。アクセスポイントはセルの役目をする。セル内に多くのマルチキャスト受信機／クライアント１０５があり得る。マルチキャストサーバ／ビデオストリーミングサーバ１２０は、高速有線ネットワーク１３０を介して、複数のＡＰｓ／ＢＳ１１０に接続されており、サービスエリアを増強する複数のセルに役立つ。干渉を低減せしめるために、隣接する無線アクセスポイントは、異なる周波数キャリアを使用して動作し得る。サーバ１２０は、マルチキャストソースデータパケット（例えば、圧縮映像データパケット）を複数のＡＰ／ＢＳ１１０に送信し、ＡＰ／ＢＳ１１０の各々は、ソースデータパケットをマルチキャストにおけるセル内の多くのクライアント１０５に送信する。

また、ＡＲＱサーバ／ハイブリッドＡＲＱサーバ１２５は、イーサーネットスイッチ／ルータ１１５を介して、高速イーサネットＬＡＮ１３０に接続されている。ＡＲＱサーバは、イーサーネットスイッチ／ルータ１１５を介して、ソースパケットをマルチキャストサーバから取得する。ＡＲＱサーバ１２５は、他の要素の間において、ＦＥＣエンコーダ及びＡＲＱハンドラを含む。ＦＥＣエンコーダは、クロスパケットＦＥＣコード化をソースパケットに利用し、ＦＥＣパリティパケットを作成する。ＡＲＱハンドラは、受信機からの要求に基づいて、ＦＥＣパリティパケット及び／又はソースパケットを再送信することを担当する。使用されるＦＥＣは、例えば、リード−ソロモン（ＲＳ）コード等のシステマティックな前進修正コードであり得る。ＦＥＣコードは、全体的なソースパケットの損失（消去）から保護するために、パケットにわたって使用される。これは、誤ったパケットが多くの場合プロトコルの低レイヤによって破棄されるからである。例えば、図２に示されているように、（Ｎ、Ｋ）ＲＳ符号は、Ｋソース／情報パケットに利用されて、Ｈ＝（Ｎ−Ｋ）パリティパケットを形成する。どのソースパケットがＫ情報パケットから損失されようとも、各パリティパケットは受信機において１つの損失されたソースパケットを回復し得る。代替実施例では、図１のＡＲＱサーバ１２５は、図１のマルチキャストサーバ１２０と一緒に用いられる。

マルチキャストにおいて、同時に異なるチャンネル条件に起因して、同じビデオストリームの複数の受信機が異なるパケット損失レートに直面し得る。また、同一の受信機は、異なる時間において異なるパケット損失レートに直面し得る。新たな受信機はセッション中に参加し得るし又はいくつかの受信機は離れ得るので、受信機の接続状態が変更してしまう。マルチキャストプログラムに対して、あるセルにおけるクライアントのチャンネル条件は、別のセルにおけるクライアントのチャンネル条件とは劇的に異なり得る。本発明のハイブリッドＡＲＱ方法は、下部構造／セルラー無線ネットワーク上における信頼性の高いマルチキャストのための方法である。本発明のハイブリッドＡＲＱ方法は、マルチキャストグループ及びマルチキャストグループアドレスを無線デバイスに自動的に割り当てる。無線デバイスは、アクセスポイント（ＡＰ）／基地局（ＢＳ）と関連付けられ、又は、ＡＲＱ要求を送信して、再送信されたＦＥＣパリティパケット及び／又はソースデータパケットを受信する等のセル依存性制御メッセージ交換のための無線セルにおいて存在する。単一セルにおける受信機／クライアントに対して再送信されたデータは、他のセルにおける無線リンク上の他のＡＰ／ＢＳによって送信されないだろう。このように、単一セルにおける再送信に使用される無線バンド幅は、このセルにおけるマルチキャストクライアントのチャンネル条件に適合され、他のセルにおけるマルチキャストクライアントのチャンネル条件によっては影響されない。

本発明において、ＡＲＱマルチキャストグループと称されるセル依存性制御メッセージ交換の及びＡＲＱ／再送信のためにマルチキャストアドレスをセルに自動的に割り当て、かつ、ＡＲＱサーバにＡＲＱマルチキャストグループの割り当てられたマルチキャストアドレスを知らせる方法も、開示されている。その上、本発明は、ＡＲＱサーバは、ＡＲＱマルチキャストグループが必要とされるときにはセルに対するセル依存性ＡＲＱマルチキャストグループに参加し、ＡＲＱマルチキャストグループが終了された後にＡＲＱマルチキャストグループから離れる方法を開示する。

ＩＥＥＥ ８０２．１１ ＷＬＡＮネットワークは、本願発明の適応ＦＥＣ方法及び適応ＦＥＣシステムを説明する実施例として用いられているものの、本明細書に記載された方法及びシステムは、無線のローカルエリアネットワーク（ＷＬＡＮ）、３Ｇネットワーク、ＷｉＭａｘ上の又は他の無線ネットワーク上のマルチキャストアプリケーションにおいて使用され得る。その上、本発明は、送信されているデータのタイプから独立しており、いかなるタイプのデータのマルチキャストにも使用され得るし、ビデオマルチキャストが本発明の方法を説明する実施例として用いられているものの、オーディオ／ビデオプログラムに限定されない。本願発明は、ＦＥＣパリティパケット及び／又はソースパケットを再送信するのに使用され得る。

信頼性のあるマルチキャストのために、サーバは、プログラムのマルチキャストソースデータパケットを、マルチキャストグループ、例えば、マルチキャストグループＸのクライアントに送信する。ソースデータを受信したいと望むクライアントは、要求をクライアントが関連付けられたＢＳ／ＡＰに送信することによって、マルチキャストグループＸに参加し／加入する。セルにおけるクライアントのいずれかが、マルチキャストグループＸメンバである限り、ＢＳ／ＡＰは、マルチキャストグループＸに対するデータをそのセル内の無線リンク上で送信する。ＢＳ／ＡＰに関連付けられたクライアントが、特定のマルチキャストグループに対するデータを必要としない場合、すなわち、特定のマルチキャストグループのメンバであることを希望し、そのマルチキャストグループに行くことになっているデータを受信する場合には、ＢＳ／ＡＰは、その無線セルにおけるその特定のマルチキャストグループに対するデータを送信しないだろうが、データを破棄する。ＢＳ／ＡＰは、それに関連付けられたクライアントに対して、いずれかのクライアントがリカバリマルチキャストグループのメンバであるかどうかに関するクエリを周期的に行い得る。インターネットマルチキャスト管理プロトコル（ＩＧＭＰ）又は他のプロトコルは、クライアントがＢＳ／ＡＰに対する要求を介して特定のマルチキャストグループに参加し又はそのグループから離れ得る手段として使用され得る。代替の実施形態は、クライアントが要求をイーサーネットスイッチ／ルータに送信するというものである。その要求クライアントがマルチキャストグループに参加し又はマルチキャストグループから離れたいと望むことを示す。ＢＳ／ＡＰに関連付けられたクライアントが、特定のマルチキャストグループに対するデータを必要としない場合には、イーサーネットスイッチ／ルータは、そのマルチキャストグループに対するデータをＢＳ／ＡＰに送信しないだろう。

さらに、セル１におけるマルチキャストプログラムＸのクライアントは、マルチキャストグループ１Ｘに参加して、ＡＲＱ要求をＡＲＱ／ハイブリッドＡＲＱサーバに送信し、かつ、マルチキャストプログラムＸの失われたパケットを回復するためにＡＲＱサーバ／ハイブリッドＡＲＱサーバから再送信されたＦＥＣパリティパケット又はソースパケットを受信する。一般に、セルＮにおけるマルチキャストプログラムＸのクライアントは、マルチキャストグループＮＸに参加して、ＡＲＱ要求をＡＲＱサーバ／ハイブリッドＡＲＱサーバに送信し、かつ、ＡＲＱサーバ／ハイブリッドＡＲＱサーバから再送信されたＦＥＣパリティパケット又はソースパケットを受信して、マルチキャストプログラムＸの失われたパケットを回復する。マルチキャストグループ１Ｘ、２Ｘ．．．ＮＸ．．．は、異なるマルチキャストアドレスを有する異なるマルチキャストグループである。ＡＲＱサーバは、再送信されたＦＥＣパリティパケット又はソースパケットを、セル１におけるクライアントに対するマルチキャストグループ１Ｘ、セル２におけるクライアントに対するマルチキャストグループ２Ｘ、．．．セルＮにおけるクライアントに対するマルチキャストグループＮＸに、送信する。すべてのソースパケット及び再送信されたパケットが、高速有線ネットワーク上でイーサーネットスイッチ／ルータに再送信される。マルチキャストグループＸにおけるソースデータ、並びに、マルチキャストグループ１ＸにおけるＡＲＱ要求と再送信されたデータは、セル１において送信される。これは、セル１におけるクライアントは、マルチキャストグループＸ及び１Ｘのメンバであるからである。しかしながら、他のグループ（２Ｘ、．．．、ＮＸ１、．．．）に対するＡＲＱ要求及び再送信されたデータは、セル１において送信されない。これは、セル１におけるクライアントは、マルチキャストグループ２Ｘ．．．、ＮＸ、．．．のメンバではないからである。他のグループに対するデータは、上述したように、セル１，ＡＰ／ＢＳ又はイーサーネットスイッチ／ルータによって破棄される。このように、無線バンド幅はセル１におけるマルチキャストクライアントに適合される。同様に、マルチキャストグループＸにおけるソースデータ並びにマルチキャストグループＮＸにおけるＡＲＱ要求と再送信されたデータは、セルＮにおいて送信される。他のグループにおけるＡＲＱ要求と再送信されたデータ（１Ｘ、．．．、（Ｎ−１）Ｘ、．．．（Ｎ＋１）Ｘ，．．．）は、セルＮにおいて送信されない。したがって、セルにおける再送信に使用される無線バンド幅は、そのセルにおけるクライアントのチャンネル条件にのみ依存しており、他のセルにおけるクライアントのチャンネル条件には依存していない。

マルチキャストソースデータに対するマルチキャストアドレス並びにＡＲＱ要求及び再送信されたデータは、セルにおけるクライアント、マルチキャストサーバ、及びＡＲＱサーバによって知られていることが必要である。本願発明は、マルチキャストアドレスを割り当てる方法についてさらに記述する。３２ビットＩＰｖ４アドレスが、本願発明のアドレス割当て方法を説明する実施例として用いられている。本発明の方法は、１２８ビットＩＰｖ６アドレス又はレイヤ２ＭＡＣアドレスの指定に容易に拡張され得る。

マルチキャストプログラムＸ１に対して、３２ビットＩＰｖ４マルチキャストアドレスｂｘ（３１），ｂｘ（３０），．．．ｂｘ（ｍ＋１），ｂｘ（ｍ），ｂｘ（ｍ−１）．．．ｂｘ０，（ｂｘ（ｍ）はアドレスのｍ番目のビットであり、０＜ｍ＜３１である）は、ソースデータマルチキャストグループと称されるソースデータ送信のために割り当てられる。ソースデータマルチキャストグループにおいて、ｂｘ（３１）．．．ｂｘ（ｍ＋１）、ｂｘ（ｍ）は、１又は０であり、ｂｘ（ｍ−１），．．．ｂ０は、０に等しい。マルチキャストプログラムＸに対するソースデータアドレスは、マルチキャストサーバ、ＡＲＱサーバ、及びクライアントにおいて構成され得る。代替方法では、マルチキャストプログラムＸのソースデータマルチキャストグループアドレスは、セッション記述ファイル（ＳＤＦ）に含まれ得る。ＳＤＦファイルは、セッション開始時におけるハイパーテキストトランスファープロトコル（「ＨＴＴＰ」）又はリアルタイムストリーミングプロトコル（ＲＴＳＰ）を介して、クライアントによってダウンロードされ得るし、又は、セッション通知プロトコル（ＳＡＰ）プロトコルを介してマルチキャストサーバ若しくは別々のディレクトリサーバ（図１に図示せず）によって知らされ得る

本発明において、各セルは、制御メッセージ交換（例えば、プログラムＸに対するＡＲＱ要求と再転送）のための別々のセル依存性マルチキャストアドレスを有する。その別々のセル依存性マルチキャストアドレスを本明細書においてＡＲＱマルチキャストアドレスと称する。セルＮにおけるプログラムＸに対するＡＲＱマルチキャストアドレスは、プログラムＸのソースデータマルチキャストグループアドレス及びセルＮに対するＡＰ／ＢＳのメディアアクセスコントロール（ＭＡＣ）アドレス又はＩＰアドレスから復号される。セルＮのＡＰ／ＢＳのＭＡＣアドレスがＭＡＣ＿Ｎである場合には、セルＮにおけるプログラムＸに対するＡＲＱマルチキャストアドレスの最下位ｍビットは、数式（１）に示されているように、セルＮのＡＰ／ＢＳのＭＡＣアドレスのハッシュ関数である。
｛ｄｘｎ（ｍ−１），ｄｘｎ（ｍ−２），．．．ｄｘｎ（０）｝＝Ｈａｓｈ（ＭＡＣ＿Ｎ） （１）

Ｈａｓｈ（ＭＡＣ＿Ｎ）＝０である場合、プログラムＸのソースデータマルチキャストグループアドレスと同一のアドレスを避けるために、ｄｘｎ（０）は１に設定される。

代替実施例では、セルＮにおけるプログラムＸに対するＡＲＱマルチキャストアドレスの最下位ｍビットは、数式（２）に示されているように、セルＮのＡＰ／ＢＳのＩＰアドレスＩＰ＿Ｎのハッシュ関数である。
｛ｄｘｎ（ｍ−１），ｄｘｎ（ｍ−２），．．．ｄｘｎ（０）｝＝Ｈａｓｈ（ＩＰ＿Ｎ） （２）

Ｈａｓｈ（ＩＰ＿Ｎ）＝０である場合、プログラムＸのソースデータマルチキャストグループアドレスと同一のアドレスを避けるために、ｄｘｎ（０）は１に設定される。

別の代替的実施形態では、セルＮにおけるプログラムＸに対するＡＲＱマルチキャストアドレスの最下位ｍビットは、そのＡＰ／ＢＳのＭＡＣアドレスＭＡＣ＿Ｎ又はＩＰアドレスＩＰ＿Ｎの最下位ｍビットに等しい。

プログラムＸに対するＡＲＱマルチキャストアドレスの最上位（３２−ｍ）ビットは、プログラムＸに対するソースデータマルチキャストアドレスの最上位（３２−ｍ）ビットに等しい。すなわち、ｄｘｎ（３１）＝ｂｘ（３１）、ｄｘｎ（３０）＝ｂｘ（３０）、．．．、ｄｘｎ（ｍ）＝ｂｘ（ｍ）である。

図３は、クライアントがプログラムＸに対するＡＲＱマルチキャストアドレスを取得する例示的方法を示すフローチャートである。ステップ３０５において、マルチキャストデータ／コンテンツ／プログラムを受信するために、クライアントはＡＰ／ＢＳに関連づけ、ステップ３１０において、ＭＡＣアドレス及び／又はＡＰ／ＢＳのＩＰアドレスを取得する。そして、ステップ３１５において、クライアントは、ディレクトリサーバからダウンロードされた設定又はセッション記述ファイルを介して又はディレクトリサーバからの通知を介して、プログラムＸのソースデータマルチキャストグループアドレスを取得する。ステップ３２０において、上述したように、クライアントはプログラムＸのＡＲＱマルチキャストアドレスをプログラムＸのソースデータマルチキャストグループアドレス及びＭＡＣアドレス又はＡＰ／ＢＳのＩＰアドレスから復号化する。

プログラムＸに対するＡＲＱマルチキャストアドレスは、ＡＲＱ要求をクライアントから受信するために、ＡＲＱサーバによって知られていることが必要であり、ＦＥＣパリティパケット及び／又はソースパケットを再送信することが必要である。

ＡＲＱサーバは、ＡＰ／ＢＳのＩＰ及び／又はＭＡＣアドレスを知り得ないし、ＡＲＱマルチキャストアドレスをＡＰ／ＢＳのＩＰ及び／又はＭＡＣアドレスから復号化することができない。その上、例えば、新たなＡＰ／ＢＳが追加される場合、既存のＡＰ／ＢＳが削除される場合、又は、既存のＡＰ／ＢＳが別のＡＰ／ＢＳによって異なるＭＡＣアドレスに置換される場合には、ＡＰ／ＢＳのＩＰ及び／又はＭＡＣアドレスは変更し得るので、ＡＲＱマルチキャストアドレスのＡＲＱマルチキャストグループがクライアントによってセルに使用される。その上、本発明は、ＡＲＱマルチキャストグループが必要とされるときにはＡＲＱサーバがＡＲＱマルチキャストグループに参加し且つＡＲＱマルチキャストグループが終了された後にＡＲＱマルチキャストグループから離れる方法について開示している（これはＡＰ／ＢＳ変更のＭＡＣアドレスの一例である。）。

図４は、クラインアントがＡＲＱサーバに登録し且つＡＲＱサーバに要求を送信してパケット（ＦＥＣ及び／又はソース）をＡＲＱサーバから受信する例示的な方法を図示するフロー図である。ステップ４０５において、クライアントは、要求を送信して、要求をＢＳ／ＡＰ又はイーサーネットスイッチ／ルータに送信することによって、ソースデータマルチキャストグループ及びＡＲＱマルチキャストグループに参加する。ソースデータマルチキャストグループに参加するクライアントの要求及びＡＲＱマルチキャストグループは、ＩＧＭＰを使用する。ステップ４１０において、クライアントは、登録メッセージをユニキャストでＡＲＱサーバに送信する。登録メッセージは、メッセージＩＤ、クライアントのアドレス、クライアントが関連付けられたＡＰ／ＢＳのアドレス、ソースデータマルチキャストグループのアドレス及びポート、ＡＲＱマルチキャストグループのアドレス及びポートを含む、クライアントは、プログラムＸのソースデータをソースデータマルチキャストグループからステップ４１５にて受信する。クライアントが、いくつかのソースデータパケットがステップ４２０で失われていることをステップ４２０にて検知する場合、及び、クライアントが、ステップ４２５にて失われたソースパケットを回復するのに使用され得るＦＥＣパリティパケット及び／又はソースパケットの再送信を要求したＡＲＱ要求を、他のクライアントから検知しない場合、クライアントはステップ４３０にてＡＲＱ要求を作成し得る。ステップ４３５において、クライアントは、クライアントが登録応答をＡＲＱサーバから受信したかどうかを判定するテストを実行する。登録応答メッセージは、ＡＲＱサーバのアドレス及びクライアントのアドレスを含み得る。クライアントが登録応答を受信していない場合には、ステップ４４０において、クライアントが再送信されたパケットをＡＲＱマルチキャストグループから先に受信しているかどうかを判定するテストをクライアントは実行する。クライアントが、再送信されたパケットをＡＲＱマルチキャストグループから先に受信していない場合には、ステップ４４５において、クライアントは、パケット（ＦＥＣ及び／又はソースパケット）の再送信に関するＡＲＱ要求をＡＲＱサーバにユニキャストする。クライアントが登録応答メッセージをＡＲＱサーバから受信していない場合及びクライアントが再送信されたパケットをＡＲＱマルチキャストグループにおけるＡＲＱサーバから受信していない場合には、ＡＲＱ要求は、ＡＲＱサーバにユニキャストで送信される。処理はステップ４１５に進む。クライアントが、再送信されたパケットをＡＲＱマルチキャストグループから先に受信している場合、クライアントは、ステップ４５０において、パケット（ＦＥＣ及び／又はソースパケット）の再送信に関するＡＲＱ要求をＡＲＱサーバにマルチキャストする。処理はステップ４１５に進む。クライアントが（ステップ４３５にて）登録応答を受信した場合には、処理はステップ４５０に進む。クライアントが失ったパケットを回復するために十分なパケットのために、クライアントがＡＲＱ要求を（ステップ４２５における）他のクライアントから検知した場合には、処理はステップ４１５に進む。（ステップ４２０において）クライアントが失ったパケットを検知しなかった場合には、処理はステップ４１５に進む。

ＡＲＱ要求メッセージは、メッセージＩＤ、メッセージのタイプ、ラウンドＩＤ、ソースマルチキャストアドレス及びポート、ＡＲＱマルチキャストアドレス及びポート、ソースコーディングブロックのソースコーディングブロックＩＤ又はベースシーケンスナンバ（第１のソースパケットのシーケンスナンバ）、要求された再送信パリティパケットの数、ソースコーディングブロックにおいて損失したソースデータパケットの平均数、パケットビットマップの長さ、ブロックのパケットビットマップ等、を含む。メッセージのタイプのフィールドは、ソースデータの再送信若しくはＦＥＣパリティの再送信ＡＲＱ要求、又は、ソースデータ及びＦＥＣパリティの両方の再送信のＡＲＱ要求を示す。ラウンドＩＤは、メッセージが送信されたＡＲＱラウンドの数を示す。すべての受信機に対して、各々のＦＥＣコード化ブロックのラウンドＩＤは０の値から開始する。ブロックのパケットビットマップは、ソースコーディングブロックにおいて受信されたソースパケットの状態を示す。ソースコーディングブロックにおいて、１の値を有するビットは、対応するソースパケットが正確に受信されたこと及びビット０はパケットが損失したことを示す。なお、上記のソースマルチキャストアドレス及びＡＲＱマルチキャストアドレスは、ＩＰ（レイヤ３）アドレス及び／又はＭＡＣ（レイヤ２）アドレスであり得る。

図５は、クライアントから受信された登録メッセージを処理するＡＲＱサーバの本発明の原理に係る例示的方法を表すフロー図である。ステップ５０５において、ＡＲＱサーバはクライアントから登録メッセージを受信する。ＡＲＱサーバがクライアントから登録メッセージを受信するとすぐに、ＡＲＱサーバが、ＡＲＱマルチキャストグループに既に参加していると判定するテストがステップ５１０にて実行される。ＡＲＱサーバが登録メッセージにおいて指定されたＡＲＱマルチキャストグループに参加してない場合には、ＡＲＱサーバは、ステップ５１５において、登録メッセージにおいて指定されたＡＲＱマルチキャストグループに参加する。そして、ステップ５２０においてＡＲＱサーバがＡＲＱマルチキャストグループに参加する後に、ＡＲＱサーバは、登録応答メッセージをユニキャストでクライアントに送信する。ＡＲＱサーバが、登録メッセージにおいて指定されたＡＲＱマルチキャストグループに既に参加している場合には、処理はステップ５２０に進む。

図６は、クライアントから受信されたＡＲＱ要求メッセージを処理するＡＲＱサーバの本発明の原理に係る例示的方法を表すフロー図である。ステップ６０５において、ＡＲＱサーバはクライアントからステップ６０５でＡＲＱ要求メッセージを受信する。ＡＲＱサーバがクライアントからＡＲＱ要求メッセージを受信するとすぐに、ＡＲＱサーバが、ＡＲＱマルチキャストグループに既に参加していると判定するテストがステップ６１０にて実行される。ＡＲＱサーバが、ＡＲＱ要求メッセージにおいて指定されたＡＲＱマルチキャストグループに参加してない場合には、ＡＲＱサーバは、ステップ６１５において、ＡＲＱ要求メッセージにおいて指定されたＡＲＱマルチキャストグループに参加する。ステップ６２０において、ＡＲＱサーバは、無線セルにおけるクライアントから受信されたＡＲＱ要求メッセージを分析する。セルにおけるクライアントからのＡＲＱ要求メッセージに基づいて、ＡＲＱサーバは、ステップ６２５において、ＡＲＱ要求において指定されたＡＲＱマルチキャストグループにおけるＦＥＣパリティパケット及び／又はソースパケットを再送信する。なお、異なるセルに対する再送信されたＦＥＣパリティパケット及び／又は当初のソースパケットは、異なるＡＲＱマルチキャストグループにおけるマルチキャストにおいて再送信される。

図７は、ＡＲＱサーバがＡＲＱマルチキャストグループにクエリを行う本発明の原理に係る例示的方法を図示するフロー図である。ＡＲＱサーバは、ＡＲＱ＿マルチキャスト＿タイムアウトが満了したことをステップ７０５において通知される。ＡＲＱ＿マルチキャスト＿タイムアウトの満了は、ＡＲＱサーバがＡＲＱマルチキャストグループに参加したものの、ＡＲＱマルチキャスト＿タイムアウトの期間中にこのＡＲＱマルチキャストグループからいかなるＡＲＱ要求をも受信していないことを示している。ステップ７１０において、ＡＲＱサーバは、マルチキャスト＿グループ＿クエリ（ＭＧＱＵ）メッセージをＡＲＱマルチキャストグループに送信する。ＭＧＱＵメッセージは、このＡＲＱマルチキャストグループ内にクライアントが現時点で存在するかどうかに関するクエリを行うのに使用される。ＭＧＱＵメッセージは、ＡＲＱサーバのアドレス、ＡＲＱマルチキャストアドレス、メッセージＩＤ、メッセージシーケンスナンバ等を含む。ステップ７１５において、ＡＲＱサーバはマルチキャスト＿グループ＿クエリ＿リトライ＿カウントを初期化し、ステップ７２０において、マルチキャスト＿グループ＿クエリ＿ウェイト＿タイマを設定する。マルチキャスト＿グループ＿クエリ＿ウェイト＿タイマは、満了時間がＭＧＱＵ＿リトライ＿間隔であるタイマである。ＭＧＱＵを送信した後に、ＡＲＱサーバは、マルチキャスト＿グループ＿クエリ＿リプライ（ＭＧＱＲ）メッセージを待つ。マルチキャスト＿グループ＿クエリ＿リプライが受信されているかどうかを判定するテストが、ステップ７２５にて実行される。マルチキャスト＿グループ＿クエリ＿リプライが受信されていない場合には、マルチキャスト＿グループ＿クエリ＿ウェイト＿タイマが満了したかどうかを判定するテストがステップ７３０にて実行される。マルチキャスト＿グループ＿クエリ＿ウェイト＿タイマが満了している場合には、マルチキャスト＿グループ＿クエリ＿リトライ＿カウント（ＭＧＱＵ＿リトライ＿カウント）が所定のマルチキャスト＿グループ＿クエリ＿リトライ＿リミット（ＭＧＱＵ＿リトライ＿リミット）よりも大であるかどうかを判定するテストがステップ７３５にて実行される。マルチキャスト＿グループ＿クエリ＿リトライ＿カウントがＭＧＱＵ＿リトライ＿リミット以下である場合には、そして、マルチキャスト＿グループ＿クエリ＿シーケンスナンバ及びマルチキャスト＿グループ＿クエリ＿リトライ＿カウントは、ステップ７４０において増加される。マルチキャスト＿グループ＿クエリは、ステップ７４５で再送信される。処理はステップ７２０に進む。マルチキャスト＿グループ＿クエリ＿リプライが受信されている場合には、マルチキャスト＿グループ＿クエリ＿ウェイト＿タイマは消去され、ステップ７５０において、ＡＲＱ＿マルチキャスト＿タイムアウトタイマはリセットされる。マルチキャスト＿グループ＿クエリ＿リトライ＿カウントがＭＧＱＵ＿リトライ＿リミットよりも大である場合には、ステップ７５５において、ＡＲＱはこのＡＲＱマルチキャストグループから離れる。

図８は、クライントがＡＲＱサーバからのＡＲＱマルチキャストグループクエリを処理する本発明の原理に係る例示的方法を図示するフロー図である。ステップ８０５において、クライアントはＡＲＱマルチキャストグループクエリをＡＲＱサーバから受信する。クライアントがまだＲＱマルチキャストグループクエリにおいて指定されたＡＲＱマルチキャストグループのメンバであるかどうかを判定するテストが、ステップ８１０にて実行される。クライアントがまだＡＲＱマルチキャストグループクエリにおいて指定されたリカバリマルチキャストグループのメンバである場合には、クライアントは、ステップ８１５において、マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマ（ＭＧＱＲ＿遅延＿タイマ）を設定する。クライアントがセル内の他のクライアントからも他のマルチキャスト＿グループ＿クエリ＿リプライを受信したかどうかを判定するテストがステップ８２０にて実行される。クライアントがセル内の他のクライアントからも他のマルチキャスト＿グループ＿クエリ＿リプライを全く受信していない場合には、マルチキャスト＿グループ＿クエリ＿遅延＿タイマが満了したかどうかを判定するテストがステップ８２５にて実行される。マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマが満了している場合には、ステップ８３０において、マルチキャスト＿グループ＿クエリ＿リプライがＡＲＱマルチキャストグループに送信される。（ステップ８２５において）マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマが満了している場合には、処理はステップ８２０に進む。クライアントがセル内の他のクライアントからも他のマルチキャスト＿グループ＿クエリ＿リプライを受信している場合には、クライアントは、ステップ８３５において、マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマを消去する。クライアントが、ＡＲＱマルチキャストグループクエリにおいて指定されたＡＲＱマルチキャストグループのメンバでない場合には（既にメンバでない場合には）、クライアントは、ＡＲＱマルチキャストグループクエリを無視する。

マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマは、マルチキャスト＿グループ＿クエリ＿リプライ＿遅延＿タイマ（０＜ＭＧＱＲ＿遅延＿タイマ＜ＭＧＱＲ＿遅延＿リミット）であるランダムな遅延タイマである。事実上、この遅延は時間をランダム化して、マルチキャスト＿グループ＿クエリ＿リプライ（ＭＧＱＲ）を送信する。ＭＧＱＲは、クライアントから全ての参加者（ＡＲＱサーバ及びＡＲＱマルチキャストグループにおける他のクライアント）までＡＲＱマルチキャストアドレスに送信される。遅延期間中に、クライアントは、同一のＡＲＱマルチキャストグループにおける別のクライアントからＭＧＱＲを受信し得る。かかるＭＧＱＲが遅延期間中に受信される場合には、このクライアントは、ディレイタイマを消去して、ＭＧＱＲを送信しないだろう。ＭＧＱＲは、クライアントアドレス、ＡＲＱマルチキャストグループアドレス、このＭＲＧＲが応答する当初のＭＧＱＵメッセージのシーケンスナンバ等を含む。

ＡＲＱ＿マルチキャスト＿タイムアウト、ＭＧＱＵ＿リトライ＿間隔、ＭＧＱＵ＿リトライ＿リミット、及び、ＭＧＱＲ＿遅延＿リミットは、設定され得るパラメータである。

代替実施例では、クライアントが登録応答メッセージをＡＲＱサーバから受信していない場合及び／又はクライアントが再送信されたパケットをセル依存性ＡＲＱマルチキャストグループにおけるＡＲＱサーバから受信していない場合には、マルチキャストプログラムＸのクライアントは、マルチキャストプログラムＸのセル独立性コントロールマルチキャストグループにおけるＡＲＱ要求を送信する。セル独立性制御マルチキャストグループは共通の制御チャンネルを使用する。マルチキャストプログラムＸに対するセル独立性制御マルチキャストグループのアドレスｃｘ（３１），ｃｘ（３０），．．．ｃｘ（ｍ＋１），ｃｘ（ｍ），ｃｘ（ｍ−１），．．．ｃｘ０は、割り当てられ、且つマルチキャストサーバ、ＡＲＱサーバ、及びクライアントにおいて構成され得る。代替方法では、マルチキャストプログラムＸに対するセル独立性制御チャネルアドレスは、セッション記述ファイル（ＳＤＦ）に含まれ得る。セッション記述ファイルは、セッション開始時においてＨＴＴＰ又はＲＴＳＰプロトコルを介して、クライアントによってダウンロードされ得るし、又は、マルチキャストサーバ若しくは別々のディレクトリサーバによって知らされ得る。別の代替的方法では、プログラムＸのセル独立性制御チャネルアドレスは、プログラムＸのソースマルチキャストアドレス、例えば、ｃｘ（３１）＝ｂｘ（３１）、ｃｘ（３０）＝ｂｘ（３０）、．．．ｃｘ（ｍ＋１）＝ｂｘ（ｍ＋１）、ｃｘ（ｍ）＝＾ｂｘ（ｍ），ｃｘ（ｍ−１）＝０、．．．ｃｘ０＝０から推定される。

図９は、本発明の原理に係る例示的クライアント／受信デバイスのブロック図である。制御モジュール９０５は、プログラムに対するソースマルチキャストアドレス及びＡＲＱマルチキャストアドレスを取得する役割がある。また、それはそれ自身をＡＲＱサーバに登録する責任を有し、登録メッセージを送信し且つ登録の応答を処理すること、マルチキャストグループクエリ（ＭＧＱＵ）メッセージを受信すること、ＭＧＱＵメッセージを処理すること、及び、マルチキャストグループクエリ応答（ＭＧＱＲ）を通信インターフェイス９１０を介して送信することを含む。それは、ＡＲＱ要求モジュール９１５にアドレスを知らせてＡＲＱ要求を送信し、データ受信モジュール９２０にアドレスを知らせてソースデータ及び再送信されたデータを受信する。データ受信モジュール９２０は、通信インターフェイス９１０を介してソースデータ及び再送信されたデータを受信する。データ受信モジュール９２０は、ＡＲＱ要求モジュール９１５にあらゆるデータ損失をも知らせる。データ受信モジュール９２０は、受信されたデータをマルチキャストアプリケーション／マルチメディアプレイヤーモジュール９２５に転送する。ＡＲＱ要求モジュール９１５は、ＡＲＱ要求が必要であるかどうか及び何を要求するべきかを判定し、通信インターフェイス９１０を介してＡＲＱ要求をＡＲＱサーバに送信する。また、ＡＲＱ要求モジュール９１５は、通信インターフェイス９１０を介して、ＡＲＱ要求を他のクライアントから聞く。

図１０は、本発明の原理に係る例示的リカバリサーバ／ＡＲＱサーバのブロック図である。制御モジュール１００５は、クライアントの登録に対して責任を有し、クライアント登録要求を受信し且つ処理すること、前記マルチキャストグループに参加すること、及び、通信インターフェイス１０１０を介して登録応答を送信することを含む。また、制御モジュール１００５は、ＡＲＱマルチキャストグループを使用するクライアントが存在するかどうかに関するクエリを行う義務を有し、ＭＧＱＵを送信すること、通信インターフェイス１０１０を介してＭＧＱＲをクライアントから受信すること、ＭＧＱＲメッセージを処理すること、ＡＲＱサーバが、ＡＲＱマルチキャストグループから離れるべきかどうかを判定する義務を含む。制御モジュール１００５は、データ受信／送信モジュール１０１５に命令して、プログラムに対するデータを（通信インターフェイス１０１０を介して）受信し、データをバッファに記憶する。そして、データ受信／送信モジュール１０１５は、プログラムに対するデータを（通信インターフェイス１０１０を介して）受信し、データをバッファに記憶する。制御モジュール１００５は、ＡＲＱ処理過程モジュール１０２０にＡＲＱマルチキャストアドレスを知らせる。ＡＲＱ処理過程モジュール１０２０は、ＡＲＱ要求を通信インターフェイス１０１０を介して受信し、ＡＲＱ要求を処理する。ＡＲＱ処理モジュール１０２０はデータ受信／送信モジュール１０１５に要求して、失われたパケットをクライアント／受信デバイスに再送信する。本発明は、例えば、サーバ内、（無線アクセスポイント又は無線ルータ等の）中間的デバイス内、又はモバイルデバイス内のハードウェア（例えば、ＡＳＩＣチップ）、ソフトウェア、ファームウェア、専用プロセッサ、又は、それらの組合せ等の種々の形態において実装され得ると理解されるべきである。望ましくは、本発明はハードウェアとソフトウェアとの組合せとして実装され得る。その上、ソフトウェアは、プログラム記憶デバイス上でタンジブルに実施されたアプリケーションプログラムとして望ましくは実装される。アプリケーションプログラムは、あらゆる適切なアーキテクチャを含むマシンへとアップロードされ得るし、あらゆる適切なアーキテクチャを含むマシンによって実行され得る。望ましくは、マシンは、１つ以上の中央演算処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、入出力（入出力）インターフェイス等のハードウェアを有するコンピュータプラットフォーム上で実装される。また、コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含み得る。本明細書に記載された種々のプロセス及び機能は、オペレーティングシステムを介して実行されるマイクロ命令コードの一部又はアプリケーションプログラム（若しくはそれらの組合せ）の一部であり得る。さらに、他の種々の周辺デバイスが、追加的データ記憶機構デバイスや印刷デバイス等のコンピュータプラットフォームに接続され得る。

添付図面に現されたシステムの要素及び方法ステップのいくつかは、ソフトウェアにおいて望ましくは実装されるので、本発明がプログラムされている手法に依存して、システムの要素（又は処理ステップ）間の実際の接続は異なり得ることがさらに理解されるべきである。本明細書における教示を前提として、関連技術の当業者であれば、本発明のこれらインプリメンテーション又は構成及び類似のインプリメンテーション又は構成を想定し得るであろう。
本発明は以下の態様を含む。
（付記１）
ハイブリッド自動再送要求エラーリカバリの方法であって、
前記方法は、
マルチキャストグループアドレス及びアクセスポイントアドレスの機能を使用して、リカバリマルチキャストグループアドレスを判定するステップと、
要求を送信してマルチキャストグループに参加するステップと、
要求を送信してリカバリマルチキャストグループに参加するステップと、
リカバリサーバに登録メッセージを送信するステップと、
登録応答メッセージが前記リカバリサーバから受信されたかどうかを判定するステップと、
リカバリ要求メッセージを前記リカバリサーバに送信して、前記判定されたアドレスを使用してリカバリデータを要求するステップと、
前記リカバリデータを前記リカバリサーバから受信するステップと、を含み、
前記リカバリデータは、クロスパケットコード化によって作成されたエラーリカバリデータ及び再送信されたデータのうちの一方であることを特徴とする方法。
（付記２）
前記第１の判定するステップは、
アクセスポイントに関連付けるステップと、
前記アクセスポイントアドレスを取得するステップと、
前記マルチキャストグループアドレスを取得するステップと
をさらに含むことを特徴とする付記１に記載の方法。
（付記３）
前記アクセスポイントアドレスは、インターネットプロトコルアドレス及び媒体アクセス制御アドレスの内の１つであり、
前記マルチキャストグループアドレスは、セッション記述ファイル及びディレクトリサーバの内の１つから取得され、
前記第１の判定するステップは、ハッシュ関数を前記媒体アクセス制御アドレスに適用するステップ及びハッシュ関数を前記インターネットプロトコルアドレスに適用するステップの内の１つによって実行されることを特徴とする付記１に記載の方法。
（付記４）
マルチキャストデータを受信するステップと、
いずれかのデータが失われたかどうかを判定するステップと、
別のデバイスが前記リカバリ要求メッセージを送信したかどうかを判定するステップと、
他のデバイスが前記リカバリ要求メッセージを送信していない場合には、前記リカバリ要求メッセージを作成するステップと、
いずれかのリカバリデータが先に受信されたかどうかを判定するステップと、
リカバリデータが先に受信されていない場合には、前記リカバリ要求メッセージを前記リカバリサーバにユニキャストするステップと
をさらに含む付記１に記載の方法。
（付記５）
前記マルチキャストグループに参加する前記要求は、アクセスポイント及びイーサーネットスイッチのうちの一方に送信され、
前記マルチキャストグループに参加する前記要求は、インターネットグループ管理プロトコルを使用して実行され、
前記登録メッセージはユニキャストであり、
前記登録応答メッセージは前記リカバリサーバのアドレスを含むこと
を特徴とする付記４に記載の方法。
（付記６）
デバイスがリカバリマルチキャストグループのメンバであるかどうかを判定するステップと、
前記リカバリデータに対する応答を送信するステップと
をさらに含み、
前記送信するステップは、他のデバイスが前記リカバリマルチキャストグループメッセージに応答していない場合、及び遅延時間が満了した場合に、実行されること
を特徴とする付記１に記載の方法。
（付記７）
自動再送要求エラーリカバリのための装置であって、
マルチキャストグループアドレス及びアクセスポイントアドレスの機能を使用して、リカバリマルチキャストグループアドレスを判定する手段と、
要求を送信してマルチキャストグループに参加する手段と、
要求を送信してリカバリマルチキャストグループに参加する手段と、
登録メッセージをリカバリサーバに送信する手段と、
登録応答メッセージが前記リカバリサーバから受信されたかどうかを判定する手段と、
リカバリ要求メッセージを前記リカバリサーバに送信して、前記判定されたアドレスを使用してリカバリデータを要求する手段と、
前記リカバリデータを前記リカバリサーバから受信する手段と
を含み、
前記リカバリデータは、クロスパケットコード化によって作成されたエラーリカバリデータ及び再送信されたデータのうちの一方であることを特徴とする装置。
（付記８）
登録メッセージを受信するステップと、
前記登録メッセージに対する応答を送信するステップと、
リカバリ要求メッセージを受信するステップと、
前記リカバリ要求メッセージに応答してリカバリデータを送信するステップと、
メッセージをリカバリマルチキャストグループに送信して、前記リカバリマルチキャストグループのステータスを判定するステップと
を含む方法。
（付記９）
前記登録メッセージにおいて指定されたリカバリマルチキャストグループが既に参加されているかどうかを判定するステップと、
前記リカバリマルチキャストグループが既に参加せしめられていない場合に、前記リカバリマルチキャストグループに参加するステップと
をさらに含む付記８に記載の方法。
（付記１０）
前記リカバリ要求メッセージにおいて指定されたリカバリマルチキャストグループが既に参加せしめられているかどうかを判定するステップと、
前記リカバリマルチキャストグループが既に参加せしめられていない場合には、前記リカバリマルチキャストグループに参加するステップと
をさらに含む付記８に記載の方法。
（付記１１）
前記リカバリデータは、前方誤り訂正パケット及びソースデータのうちの一方であることを特徴とする付記１０に記載の方法。
（付記１２）
前記リカバリデータは、前方誤り訂正パケットとソースデータの両方であることを特徴とする付記１０に記載の方法。
（付記１３）
リカバリタイムアウトが生じたという通知を受信するステップをさらに含む付記８に記載の方法。
（付記１４）
登録メッセージを受信する手段と、
前記登録メッセージに対する応答を送信する手段と、
リカバリ要求メッセージを受信する手段と、
前記リカバリ要求メッセージに応答してリカバリデータを送信する手段と、
メッセージをリカバリマルチキャストグループに送信して、前記リカバリマルチキャストグループのステータスを判定する手段と
を含む装置。
（付記１５）
判定する前記第１の手段は、
アクセスポイントに関連付ける手段と、
前記アクセスポイントアドレスを取得する手段と、
前記マルチキャストグループアドレスを取得する手段と
をさらに含むことを特徴とする付記７に記載の方法。
（付記１６）
前記アクセスポイントアドレスは、インターネットプロトコルアドレス及び媒体アクセス制御アドレスの内の１つであり、
前記マルチキャストグループアドレスは、セッション記述ファイル及びディレクトリサーバの内の１つから取得され、
判定する前記第１の手段は、ハッシュ関数を前記媒体アクセス制御アドレスに適用するステップ及びハッシュ関数を前記インターネットプロトコルアドレスに適用するステップの内の１つによって実行されることを特徴とする付記１５に記載の装置。
（付記１７）
マルチキャストデータを受信する手段と、
いずれかのデータが失われたか否かを判定する手段と、
別のデバイスが前記リカバリ要求メッセージを送信したか否かを判定する手段と、
他のデバイスが前記リカバリ要求メッセージを送信していない場合には、前記リカバリ要求メッセージを作成する手段と、
いずれかのリカバリデータが先に受信されたかどうかを判定する手段、
リカバリデータが先に受信されていない場合には、前記リカバリ要求メッセージを前記リカバリサーバにユニキャストする手段と
をさらに含む付記７に記載の装置。
（付記１８）
前記マルチキャストグループに参加する前記要求は、アクセスポイント及びイーサーネットスイッチの内の１つに送信され、
前記マルチキャストグループに参加する前記要求は、インターネットグループ管理プロトコルを使用して実行され、
前記登録メッセージはユニキャストであり、
前記登録応答メッセージは前記リカバリサーバのアドレスを含む
ことを特徴とする付記１７に記載の装置。
（付記１９）
デバイスがリカバリマルチキャストグループのメンバであるかどうか判定する手段と、
前記リカバリデータに対する応答を送信する手段と
をさらに含み、
前記送信するステップは、他のデバイスが前記リカバリマルチキャストグループメッセージに応答していない場合及び遅延時間が満了した場合に、実行されること
を特徴とする付記１４に記載の装置。
（付記２０）
前記登録メッセージにおいて指定されたリカバリマルチキャストグループが既に参加せしめられているどうかを判定する手段と、
前記リカバリマルチキャストグループが既に参加せしめられていない場合には、前記リカバリマルチキャストグループに参加せしめる手段と
をさらに含む付記１４に記載の装置。
（付記２１）
前記リカバリ要求メッセージにおいて指定されたリカバリマルチキャストグループが既に参加せしめられているかどうかを判定する手段と、
前記リカバリマルチキャストグループが既に参加せしめられていない場合には、前記リカバリマルチキャストグループに参加せしめる手段と
を含む付記１４に記載の装置
（付記２２）
前記リカバリデータは、前方誤り訂正パケット及びソースデータのうちの一方であることを特徴とする付記１４に記載の装置。
（付記２３）
前記リカバリデータは、前方誤り訂正パケットとソースデータの両方であることを特徴とする付記１４に記載の装置。
（付記２４）
リカバリタイムアウトが生じたという通知を受信する手段をさらに含む付記１４に記載の装置。

Claims (13)

1. 自動再送要求エラーリカバリのための方法であって、
   リカバリサーバにより、登録メッセージを受信するステップであって、前記登録メッセージはリカバリマルチキャストグループのアドレスを含む、該受信するステップと、
   前記リカバリサーバにより、前記登録メッセージに対する応答を送信するステップと、
   前記リカバリサーバにより、リカバリ要求メッセージを受信するステップと、
   前記リカバリサーバにより、前記リカバリ要求メッセージに応答してリカバリデータをリカバリマルチキャストグループへ送信するステップと、
   前記リカバリサーバにより、メッセージを前記リカバリマルチキャストグループに送信して、前記リカバリマルチキャストグループのステータスを判定するステップと、
   を含み、前記リカバリマルチキャストグループは前記マルチキャストグループアドレス及びアクセスポイントアドレスのハッシュ値であるアドレスを有する、前記方法。
2. 前記リカバリサーバにより、前記登録メッセージにおいて指定されたリカバリマルチキャストグループに既に参加しているかどうかを判定するステップと、
   前記リカバリマルチキャストグループにまだ参加していない場合に、前記リカバリマルチキャストグループに参加するステップと、
   をさらに含む、請求項１に記載の方法。
3. 前記リカバリサーバにより、前記リカバリ要求メッセージにおいて指定されたリカバリマルチキャストグループに既に参加しているかどうかを判定するステップと、
   前記リカバリマルチキャストグループにまだ参加していない場合、前記リカバリマルチキャストグループに参加するステップと、
   をさらに含む、請求項１に記載の方法。
4. 前記リカバリデータは、前方誤り訂正パケット及びソースデータのうちの一方である、請求項３に記載の方法。
5. 前記リカバリデータは、前方誤り訂正パケット及びソースデータの両方である、請求項３に記載の方法。
6. リカバリタイムアウトが生じたという通知を受信するステップをさらに含む、請求項１に記載の方法。
7. 登録メッセージを受信する手段であって、前記登録メッセージはリカバリマルチキャストグループのアドレスを含む、該受信する手段と、
   前記登録メッセージに対する応答を送信する手段と、
   リカバリ要求メッセージを受信する手段と、
   前記リカバリ要求メッセージに応答してリカバリデータをリカバリマルチキャストグループへ送信する手段と、
   メッセージを前記リカバリマルチキャストグループに送信して、前記リカバリマルチキャストグループのステータスを判定する手段と、
   を含み、前記リカバリマルチキャストグループは前記マルチキャストグループアドレス及びアクセスポイントアドレスのハッシュ値であるアドレスを有する、装置。
8. デバイスがリカバリマルチキャストグループのメンバであるかどうか判定する手段と、
   前記リカバリデータに対する応答を送信する手段と、
   をさらに含み、
   前記送信する動作は、他のデバイスが前記リカバリマルチキャストグループメッセージに応答していない場合及び遅延時間が満了した場合に実行される、請求項７に記載の装置。
9. 前記登録メッセージにおいて指定されたリカバリマルチキャストグループに既に参加しているどうかを判定する手段と、
   前記リカバリマルチキャストグループにまだ参加していない場合には、前記リカバリマルチキャストグループに参加する手段と、
   をさらに含む、請求項７に記載の装置。
10. 前記リカバリ要求メッセージにおいて指定されたリカバリマルチキャストグループに既に参加しているかどうかを判定する手段と、
    前記リカバリマルチキャストグループにまだ参加していない場合、前記リカバリマルチキャストグループに参加する手段と、
    をさらに含む、請求項７に記載の装置
11. 前記リカバリデータは、前方誤り訂正パケット及びソースデータのうちの一方である、請求項１０に記載の装置。
12. 前記リカバリデータは、前方誤り訂正パケット及びソースデータの両方である、請求項１０に記載の装置。
13. リカバリタイムアウトが生じたという通知を受信する手段をさらに含む、請求項７に記載の装置。

Images