JP2011501613A - マルチキャストの信頼性を向上させる方法、システム及び装置 - Google Patents

Abstract

マルチキャストの信頼性を向上させる方法及び装置は、第１のマルチキャストグループから、複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信し、１つの追加的なレイヤの順方向誤り訂正パケットと前記コンテンツとを、複数の順方向誤り訂正符号化パケットの別の追加的なレイヤとともに受信するために、追加的なマルチキャストグループに加わる。

Description

本発明は、一般に無線通信ネットワークに関連し、特に順方向誤り訂正と自動再送要求を組み合わせることでマルチキャストアプリケーションの信頼性を向上させることに関連する。

本願で使用されるような「コンテンツ」という用語は、オーディオやビデオを包含するように使用され、さらに何らかのマルチメディアデータを含む他の任意のデータ形式を包含するようにも使用される。ビデオ及びコンテンツという用語は同義的に使用される。「／」という記号は、同一の又は同様な要素又は構造の代替名を示す。すなわち、「／」は本願において「又は」という意味として使用されてもよい。

無線ローカルエリアネットワーク（WLAN）は、それらが柔軟であることや低コストであることに起因して、家庭、ホテル、学内、及びその他のホットスポット（空港や列車の駅等）において広く使用されている。多くの場合、ユーザはWLANに接続してウェブサイトを閲覧したり、電子メールをチェックしたりするので、WLANがリアルタイムのマルチメディアストリーミングをサポートすることは非常に望まれている。しかしながら、無線チャネルはマルチパスフェージング及び干渉を受け、ランダムでバースト的なパケット損失を引き起こしたり、ストリーミングアプリケーションのコンテンツ再生品質に悪影響を及ぼしてしまうことがある。信頼性を向上させるため、順方向誤り訂正（FEC）のような誤り訂正方及び／又は自動再送要求（ARQ）を使用することが可能である。FECの場合、元の／ソースのメディアパケット／データとともにパリティパケットが送信される。しかしながら、移動装置各々は異なるチャネル状態を経験するので、どの程度多くの送信をFECで行うかを決定することは容易でない。不足したFECは、貧弱にしか保護できず、失われたパケット／データを復元できないかもしれない。過剰なFECは多くのオーバーヘッドを必要とし、ネットワーク帯域を浪費してしまう。本発明はある適応的な方法を提供し、その方法は、クライアント／移動装置に適切な保護を与えると同時に、帯域リソースを効率的に利用できるものである。

誤り訂正にARQを使用する場合、クライアント／移動装置のデータ／パケットを復元する際、長いラウンドトリップ時間による遅延が生じてしまうおそれがある。マルチキャストアプリケーションの場合、ARQは、フィードバックが長期化してしまう問題（feedback explosion problem）を招くおそれがある。しかしながら、ラウンドトリップ時間が短く、かつ適切なフィードバック抑制アルゴリズムが使用される場合、ARQは、リアルタイムのコンテンツストリーミングに対してさえも適切な誤り訂正法になる。

FECは、マルチキャストアプリケーションの信頼性を向上させる効率的な方法である。パケットレベルの誤り訂正を行うため、アプリケーションレイヤにおいて様々なFEC法が使用可能である。使用可能な候補は、ランダムインターリーブを伴う／伴わないPro−MPEGや、及びリードソロモン（RS）を含む。どのFECも長所及び短所を有する。Pro−MPEGによるFECは、XOR演算しか使用しないので非常に簡易な方法であるが、それに応じて誤り訂正能力も制限される。Pro−MPEGは、パケットの損失率が高くない場合でさえ、ある誤りパターンを訂正できないかもしれない。RSは、誤りのパターンに依存せずに機能するので、RSは、多くの場合、XORによるFEC法よりも優れた誤り訂正能力を有する。RSを使用すると演算リソースを増やす必要がある。にもかかわらず、RSはXORによるFEC法よりも低いパフォーマンスを示す場合がある。FEC符号化ブロックにおいて、ｎ個の符号化パケットの内、ｎ−ｋ個より多くのパケットを喪失した場合、RS（n，k）符号は全く機能しなくなってしまう。XORによるFECは、ｎ−ｋ個より多いパケット損失があった場合であっても、失われたパケット／データの一部を訂正することが可能である。

FECに関する問題は、第１段階において、どの程度多くのFECを送信するかを決定することである。マルチキャストアプリケーションの場合、様々な移動装置は様々なチャネル状態及び損失率を有する。単に１つの静的なFECは、全ての移動装置の条件には合わない。従来技術において、スケーラブルソースコーディングとともに、階層化FECが導入され、有線ネットワークにおける帯域幅の利用効率及びサービス品質を改善しようとしている。しかしながら、従来法はARQの再送を考慮していない。受信機のパケット損失が、FECコードの能力を超えていた場合、損失したパケットを復元することはできない。さらに、受信機は、必要とする追加的なFECパケットを取得できない。なぜなら、各レイヤにおいて、異なる数のFECパケットを取得するからである。さらに、従来の階層化法は、マルチメディアセッションの複数のトラック同士の間の同期を考慮していない。さらに、マルチメディアセッションの場合、しばしばオーディオトラックやビデオトラックがあり、ビデオトラックは、同じFECブロックサイズが使用される場合、オーディオトラックよりも高いビットレートを有するので、オーディオトラックは、FECバッファを満たすまでに、より多くの時間がかかってしまう。

従来法の場合、FECブロックにおけるFEC符号化に使用するパケットの最大数（maxK）が設定されている。バッファのトラックに対するビデオ（オーディオ）パケット数がmaxKに達すると、これらのビデオ（オーディオ）パケットに基づいてFEC符号化が実行される。これと同時に、他のトラックのオーディオ（ビデオ）メディアパケットに基づくFEC符号化も実行され、これは他のオーディオ（ビデオ）トラックバッファにおけるパケット数によらず実行される。N及びKはともに個々のFECブロックについて固定されていないので、N及びKは、FECヘッダ及び情報に包含される必要があり、これによりクライアントに通知される。

従来技術において、クライアントからサーバへの平均的なラウンドトリップ時間が短く、かつマルチキャストセッションにおけるクライアント数が少なかった場合、ARQがマルチキャストに使用される。フィードバックの長期化問題を避けるため、フィードバックの抑制がしばしば行われる。従来のハイブリッドARQ法では、クライアント／移動装置は、オリジナルのメディアパケットのシーケンス番号ではなく、FECブロックをデコードするのに必要なパリティパケットの数を求めるリクエストを送信する。再送されるパリティパケットは、マルチキャストセッションにおける全てのクライアントにマルチキャストされる。パリティパケットは、個々のクライアント／移動装置が個々の損失を回復するのに使用される。

様々な状況において異なる誤り訂正法が使用されるかもしれない。場合によってはFECが、より効果的かもしれないし、他の場合ではARQの方がより良い選択しかもしれない。全てのアプリケーションの状況にとって簡潔な解決手段を提供することが望まれている。

開示される発明の一形態による方法は、
マルチキャストの信頼性を向上させる方法であって、
順方向誤り訂正符号化パケットの複数のレイヤを生成するステップと、
複数の順方向誤り訂正符号化パケットの第１レイヤ及びコンテンツを送信するステップと、
複数の順方向誤り訂正符号化パケットの第２レイヤを要求に応じて送信するステップと、
複数の順方向誤り訂正符号化パケットの第３レイヤを、自動再送要求メッセージの受信に応じて送信するステップと、
複数の順方向誤り訂正符号化パケットの第４レイヤ及びコンテンツを、自動再送要求のコンテンツリクエストの受信に応じて送信するステップと
を有する方法である。

ホットスポットマルチメディアコンテンツをWLANキャスト（WLANを介するマルチキャスト）するアプリケーションに関する一般的な無線LANビデオ配信システムを示す図。 ソースストリームに関する３つのタイプのFECグループを示す図。 本発明の結合ハイブリッドARQ法によるクライアント／移動装置の概略ブロック図。 クライアントプロキシモジュールにおけるスレッド処理を示す図。 クライアントプロキシモジュールにおけるスレッド処理を示す図。 クライアントプロキシモジュールにおけるスレッド処理を示す図。 クライアントプロキシモジュールにおけるスレッド処理を示す図。 本発明によるクライアント側のプロキシに対するデータ構造を示す図。 本発明による結合ハイブリッドARQ法によるサーバ側の概略ブロック図。

本願は適応的な方法を開示し、その方法は、順方向誤り訂正と自動再送要求を組み合わせることでWLANにおけるマルチキャストアプリケーションの信頼性を向上させる。無線ブロードキャスト／マルチキャストシステムの場合、パケット／データは、マルチパスフェージング、干渉、ハンドオフ状態等に起因して、ランダムなバースト状の損失、欠落又はロスを被るおそれがある。信頼性を向上させるため、順方向誤り訂正（FEC）のような誤り訂正法及び自動再送要求（ARQ）法が使用可能である。FECとARQを組み合わせることは有利である。FECとARQを組み合わせることで、システム実現における柔軟性を増やし、個々の状況におけるシステムパフォーマンスを向上させることができる。本願は、結合ハイブリッドARQ法（mhARQ：merged hybrid ARQ）として言及する組み合わされた方法を開示する。本発明によるmhARQシステムでは、FECパケットは符号化され、１つ以上の適応FECマルチキャストグループ及びARQマルチキャストグループに分けられる。WLANブロードキャスト／マルチキャストシステムは、ARQ、適応FEC又は双方をマルチキャストアプリケーションにおいて使用するように構築可能である。

マルチキャストの信頼性を向上させる方法及び装置が開示され、その方法及び装置は、第１のマルチキャストグループから、複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信し、１つの追加的なレイヤの順方向誤り訂正パケットと前記コンテンツとを、複数の順方向誤り訂正符号化パケットの別の追加的なレイヤとともに受信するために、追加的なマルチキャストグループに加わる。また、マルチキャストの信頼性を向上させる開示される方法及び装置は、順方向誤り訂正符号化パケットの複数のレイヤを生成し、複数の順方向誤り訂正符号化パケットの第１レイヤ及びコンテンツを要求に応じて送信し、複数の順方向誤り訂正符号化パケットの第２レイヤを要求に応じて送信し、複数の順方向誤り訂正符号化パケットの第３レイヤを、自動再送要求メッセージの受信に応じて送信し、複数の順方向誤り訂正符号化パケットの第４レイヤ及びコンテンツを、自動再送要求のコンテンツリクエストの受信に応じて送信する。

各レイヤのFECパケットは複数のマルチキャストグループでもよいことに留意を要する。すなわち、上記の第２レイヤは、実際、複数のマルチキャストグループにより送信されるいくつかのサブレイヤでもよい。第２レイヤに関し、いくつかのマルチキャストグループが存在してもよい。マルチキャストグループ各々について、遅延時間が異なる（設定可能である）。クライアント／移動装置が、このレイヤの全てのマルチキャストグループに加わることは必須でないが、コンテンツを復元するのに十分なFEC／パリティパケットを受信するのに必要なマルチキャストグループに参加していることのみ必要である。

本発明は、添付図面とともに以下の詳細な説明を理解することで、さらに理解が深まる。図面は、図面の簡単な説明の欄に記載されているものを含む。

様々な状況において異なる誤り訂正法が使用されるかもしれない。場合によってはFECが、より効果的かもしれないし、他の場合ではARQの方がより良い選択しかもしれない。場合によっては、２つの方法をともに組み合わせてパフォーマンスを改善できるかもしれない。全てのアプリケーションの状況にとって簡潔な解決手段を提供することが望まれている。

本願は適応的な方法を開示し、その方法は、順方向誤り訂正と自動再送要求を組み合わせることでWLANにおけるマルチキャストアプリケーションの信頼性を向上させる。無線ブロードキャスト／マルチキャストシステムの場合、パケット／データは、マルチパスフェージング、干渉、ハンドオフ状態等に起因して、ランダムなバースト状の損失（ロス）を被るおそれがある。FECとARQを組み合わせることは有利である。FECとARQを組み合わせることで、システム実現における柔軟性を増やし、個々の状況におけるシステムパフォーマンスを向上させることができる。本発明によるmhARQシステムでは、FECパケットは符号化され、１つ以上の適応FECマルチキャストグループ及びARQマルチキャストグループに分けられる。WLANブロードキャスト／マルチキャストシステムは、ARQ、適応FEC又は双方をマルチキャストアプリケーションにおいて使用するように構築可能である。すなわち、本発明は、マルチキャストマルチメディアコンテンツアプリケーションに対する単一の統合されたデータ／パケット復元の手法をもたらす。本願において、「グループ」という用語は、特に断りがない限り、マルチキャストグループを示す。

図１は、ホットスポットマルチメディアコンテンツWLANキャスティングアプリケーション用の一般的な無線LAN配信システムを示し、ホットスポットがマルチメディアコンテンツをWLANを介してマルチキャストする。コンテンツサーバ（コンテンツオンデマンド105及びライブ（live）コンテンツ110）は、高速イーサーネットLAN125を介して無線アクセスポイント120a、120bに接続されている。コンテンツサーバ（コンテンツオンデマンド（COD）、ライブコンテンツ）105、110は、高速有線ネットワークを介して、１つ以上の番組（オーディオ及び／又はビデオ）を無線アクセスポイント120a、120bにマルチキャストする。アプリケーションレイヤFECが実行され、FECパケットは、遅延のない及び遅延のあるFECマルチキャストグループにおいてストリーミングサーバ115により送信され、誤り訂正能力をもたらす。アクセスポイント120a、120bは、無線リンク135を介したマルチキャストにより、コンテンツを無線装置130a、130b、130c、130dに配信する。無線装置130a、130b、130c、130dのユーザは、１つ以上の番組を視聴し、同時にインターネット140にアクセスすることもできる。インターネット140へのアクセスは、無線リンク135、適切なWLANアクセスポイント120a、120b、高速イーサーネットLAN125、イーサーネットスイッチ145、通信リンク150及びおそらくはファイヤウォール155を介して行われる。ARQサーバ160は、クライアント／移動装置からNACKを受信し、ARQ−FECパケットを送信する。場合によっては、AEQサーバ及びストリーミングサーバは、１つの装置／機器／デバイスの中で並存してもよい。遅延したFECパケットが、失われた／損傷を受けたパケット／データを復元するのに十分でなかった場合、クライアント／移動装置はIGMPを介してARQ−FECグループに加わる。

クライアント／ソース／ビデオ／オーディオのストリーム用のFECパケットは、異なるレイヤ（階層）に分けられる。各レイヤは、異なるマルチキャストグループにおいて送信される。図２に示されるように、ソースストリームについて３つのタイプのFECグループがある：
・非遅延FECグループ：これらのグループのFECパケットは、コンテンツ／ソースから遅延していない、すなわちFECパケットはそれらが生成されると直ぐに送信されている。ランダム損失リカバリに備えて、クライアント／移動装置は、「長期的な（long−term）
」チャネル状態に基づいて、１つ以上の非遅延FECグループに加わる。メンバーシップが静的である又は「準静的（semi−static）」（分単位）である場合、クライアント／移動装置は、遅延FECグループに加わる又はARQを送信することを要しない。非遅延FECは、クライアント／移動装置からのフィードバックトラフィックを減らす。

・遅延FECグループ：これらのグループのFECパケットの送信は、メディアパケットに対して、設定可能な時間だけ遅延させられる。非遅延FECパケットがデータ／コンテンツの欠落を回復するのに十分でなかった場合、インターネットグループ管理プロトコル（IGMP）を用いて、クライアント／移動装置は、遅延FECグループに動的に（FECブロック毎に）参加／脱退する。コンテンツ及び遅延パケット間の時間差よりも参加時間が長かった場合、対応するパリティパケットが受信され、失われたコンテンツ／データパケットをクライアント／移動装置が復元する。無線帯域を節約するため、AP／ルータに関連するクライアント／移動装置のどれもが、この特定のグループに参加していなかった場合、マルチキャストグループの遅延FECデータは、無線ネットワークのAP／ルータ120a、120bから送信されない。

・ARQ−FECグループ：クライアント／移動装置からのNACKに応じて、ARQ−FECグループのFECパケットが送信される。遅延FECパケットが、失われたパケット／データを回復するのに十分でなかった場合、クライアント／移動装置はNACKをARQサーバに送信し、IGMPを介して関連するARQ−FECグループに加わる。

・ARQソース／コンテンツグループ：欠落パケット数がしきい値を超えた場合、ARQサーバは、メディアパケットのオリジナルブロックをマルチキャストグループにおいて再送してもよい。なぜなら、全ての欠落／損傷パケット／データを復元するためにFECが使用される、又はFECを用いても、どの欠落／損傷パケット／データも復元できないからである。多くの欠落／損傷したメディアパケット／データが存在する場合、受信機は、再送されたメディアパケットのいくつかを少なくとも受信できる。

柔軟性の観点から、非遅延及び遅延FECグループの数、コンテンツストリーム及び遅延FECストリーム間の時間差に加えて、非遅延、遅延FECグループ及びARQ−FECグループにおけるFECの品質が、設定可能である。

利用可能な市販の及びフリーウェアのコンテンツ／ビデオプレーヤ（例えば、クイックタイム、トムソンマルチメディアアプリケーションフレームワーク（MMAF）及びビデオラン（VideoLAN）クライアント（VLC）プレーヤ）は、FECをサポートしていない。市販のプレーヤの場合、ソースコードは一般に利用可能でない。フリーウェアのソースコードが利用可能であった場合でさえ、FECを全てのフリーウェアプレーヤに統合することに加えて、ソースコードを維持して更新することは容易でない。本発明は、図３に示すように、クライアントプロキシアーキテクチャを含む。クライアントプロキシは、プレーヤのコードを変更する如何なる制約も課さずに、商用の及びフリーウェアの如何なるビデオプレーヤとも機能することができる。クライアントプロキシは、様々なマルチキャストグループからFECパケット及びメディアを受信し、FECマルチキャストグループに対して参加及び脱退を行い、ARQサーバにARQ−NACKを送信し、再送されたFEC及びメディアパケットを受信し、欠落したメディアパケットを復元し、復元されたメディアパケットを通信ソケットを介してプレーヤに送信する。

図３をさらに参照するに、クライアント／移動装置は、WLANインターフェース305を介して（WLANアクセスポイント120a、120bを介して）コンテンツサーバ105、110からコンテンツを受信する。クライアント／移動装置は同時に複数のマルチキャストグループ（コンテンツ、FEC、遅延FEC、ARQ−FEC、ARQソース／クライアント）のメンバになることもでき、その各々は、共通ユーザデータグラムプロトコル／インターネットプロトコル（UDP／IP）プロトコルスタック315を介する個々のフロー（310a、310b）により示される。共通UDP／IPプロトコルスタック315において、コンテンツ320及びFECパケット325は分かれており、本発明によるFECクライアントプロキシモジュール330に入力されている。復元されたコンテンツはストレージシステム335に保存され、ストレージシステムは、後の再生に備えて、ディスク、テープ、CD、メモリ、DVD等のような如何なる形式のストレージを含んでもよく、あるいは復元されたコンテンツは、通信ソケットを介してプレーヤ（又は適切な利用可能な何らかのディスプレイ装置）355に送信されてもよく、通信ソケットは、ディスプレイ装置355におけるUDP／IPプロトコルスタック350及びUDP／IPプロトコルスタック340、345を含む。

コンテンツサーバの側において、FEC符号化処理が実行される前に、所定数のメディアパケット（K）がバッファされる。マルチメディアコンテンツは、複数のトラック（例えば、ビデオトラック及びオーディオトラック）を含んでもよい。FEC符号化処理は、各トラック各々について実行される。異なるメディアトラックは異なるビットレートを有し、通常、ビデオやオーディオよりも速いビットレートを有する。ビデオ及びオーディオ双方に同じFECブロックサイズを使用すると、受信機において、オーディオ／ビデオの同期の問題を引き起こしてしまう。例えば、ビデオバッファのビデオパケット数がKに達した場合、それらのパケットについてFEC符号化が実行され、ビデオFECパケットが送信され、次のブロックに備えてバッファは空になるが、それと同時に、オーディオバッファのオーディオパケット数は、Kに達するまで不定の時間の間待機しなければならない。１つの解決法は、ビデオとオーディオについて異なるブロックサイズを使用することである。しかしながら、ビデオの所定のブロックサイズに対して、オーディオのブロックサイズをどのようにして選択するか、という問題が設計上残ってしまう。異なるコンテンツは、オーディオ及びビデオパケットの間で、異なるブロックサイズの組み合わせ（paring）を要するかもしれない。同じコンテンツの場合でさえ、可変ビットレートコンテンツは、オーディオ及びビデオに対して、異なる時点で異なるKを必要とするかもしれない。

可変ビットレートの場合、バッファの中で一定数のメディアパケットを満たすまでの時間は、一定でない。FECバッファリングに起因して被る再生ジッタに対処するため、本発明では、FECブロックについて最大バッファ時間（maxT）が設定される。ビデオ又はオーディオFECバッファに最初のパケットをバッファリングする時間がmaxTに等しい又はそれを超えていた場合、あるいはバッファ内のトラックに対するビデオ（オーディオ）のパケット数がmaxK（最大バッファサイズ）を超えていた場合、マルチメディアコンテンツのビデオ及びオーディオトラック双方のパケットについて、FEC符号化が実行される。

様々なN及びKを使用することでオーディオ及びビデオの同期問題を解決することはできるが、符号化及び復号化の余分なオーバーヘッドを必要とし、異なるN及びKの生成マトリクスは異なるので、生成マトリクスを形成するための演算負担は非常に高くなってしまう。符号化及び復号化の効率を改善するため、本発明では、maxK及びmaxNの双方が固定される。生成マトリクスはmaxK及びmaxNに基づいて生成され、サーバ及びクライアントの側双方で一度だけ初期化される。全ての（N，K）コードに関し、K≦maxK、N≦maxNである。これは、パンクチャリングされた／短縮化されたコードに基づいて、初期の生成マトリクスを用いて生成可能であり、符号化及び復号化の時間を顕著に短縮できる。

図４Ａ、４Ｂ、４Ｃ及び４Ｄには、クライアントプロキシ330の機能の詳細が示されている。クライアントプロキシの機能／動作／手順は、ソフトウェア、ハードウェア、ファームウェア、特定用途集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）により実現されてもよいし、これらと適切な他の任意の手段との何らかの組み合わせにより実現されてもよい。クライアントプロキシは、FEC及びメディアパケットを受信し、受信したFEC及びメディアパケットをバッファリング（蓄積）し、パケットロスに基づいてチャネル状態を推定する。クライアントプロキシがFECブロックから元のメッセージを復元できなかった場合、クライアントプロキシは、さらに遅延したFECグループに加わり、及び／又はARQリクエストを送信し、さらなるFEC又はオリジナルのメディアパケットの再送を求める。クライアントプロキシにおいて、ARQフィードバック抑制アルゴリズムも使用される。何らかのパケットが欠落／損傷しているが、FECブロックは復号可能である場合、クライアントプロキシは欠落／損傷したパケットをパリティ（FEC）パケットから復元し、復元されたメディアパケットをプレーヤに送る。パケットが欠落／損傷しており、クライアントプロキシがFECブロックを復号できず、バッファタイマが経過した場合、たとえ或るパケットが欠落して復元できなかったとしても、クライアントプロキシは受信したメディアパケットをプレーヤに送る。

クライアントプロキシのタスクは、３つの別個のスレッドにより実行される。メイン（主要な）スレッドは、メディア／パリティパケットを受信及びバッファリングする。また、メインスレッドは、マルチキャストグループ中の他のクライアント／移動装置からARQリクエストを受信し、処理する。メインスレッドは、チャネル推定、適応FEC処理及びFECデコード処理も実行する。ARQ処理及びパケット転送は、第２及び第３のスレッドによりそれぞれ実行される。

図４Ａ、４Ｂ、４Ｃ及び４Ｄを参照するに、図３のクライアントプロキシで実行される方法も示されている。図４Ａはメインルーチンであり、405においてソースバッファが初期化される。410において、パケット転送プロセスの（第２）スレッドが起動される。415において、ARQイベントキューが初期化される。420において、ARQイベントプロセスの（第３）スレッドが起動される。最後に425において、メディアパケットの受信、メディアパケットのバッファリング及び誤り訂正等を処理するメイン（第１）スレッドが起動される。

図４Ｂは、図３のクライアントプロキシにより実行される方法のメイン／第１スレッドを示すフローチャートである。430においてパケットが受信される。435においてチャネル状態が推定される。440において、受信したパケットはFECパケットであるか否かの検査が実行される。受信したパケットがFECパケットであった場合、465においてパケットが処理される。クライアント／移動装置がパリティ（FEC）パケットを受信すると、クライアント／移動装置は、FECブロックヘッダから、そのパリティパケットが所属している（そのパリティ／FECパケットが含まれている）FECブロックに関する全ての情報を取得する。クライアント／移動装置は、先ず、ブロックデータ構造がFECブロックに割り当てられている（決まっている）か否かを確認する。ブロックデータ構造が未だ割り当てられていなかった場合、ブロックデータ構造が割り当てられる。FECブロックは、ベースシーケンスナンバー（base sequence number）にしたがってそのデータ構造（例えばリンクしたリスト）に挿入される。FECブロックのベースシーケンスナンバーは、そのFECブロックに所属するメディアパケットの中で最小のシーケンスナンバーである。FECブロックが割り当てられた後、クライアント／移動装置は、ソースバッファを調べ、そのFECブロックに所属するメディアパケットを確認し（マークし）、そのブロックに対応する情報（例えば、どの程度多くのパケットが欠落しているか、どのパケットが欠落しているか等の情報）を更新する。485において、FECブロックはデコード可能であるか否かの検査が実行される。FECブロックが割り当てられた後、クライアント／移動装置は、ソースバッファを調べ、そのブロックに対応する情報（例えば、どの程度多くのパケットが欠落しているか、どのパケットが欠落しているか等の情報）を抽出し、抽出した情報をFECデコード処理に使用することができる。FECブロックがデコード可能でなかった場合、495において適応FECアルゴリズムが起動される。すなわち、クライアントプロキシは、遅延FECマルチキャストグループに加わり、遅延FECパケットを要求する。497においてARQが必要か否かを決める検査が実行される。欠落／損傷したパケット／データを復元するには遅延FECパケットが不十分であった場合、ARQが必要になる。ここで、ARQは、ARQ−FECパケット及びARQソース／コンテンツパケットリクエストを含む。これは、ARQ−FEC及びARQソース／コンテンツマルチキャストグループに参加することを含む。ARQが必要な場合、499において、ARQリクエストがARQイベントキューに挿入される。そして、処理は430に戻る。ARQが必要でなかった場合も処理は430に戻る。

FECブロックがデコード可能であった場合、復元されたパケットは490においてソースバッファに挿入される。FECがデコードされた後に受信したメディア又はFECパケットは、破棄（drop）される。FECブロックの全てのメディアパケットがディスプレイに送信された場合、FECブロック構造はクリアされ、メモリは解放される。491において、適応FECが活性化され（起動され）、クライアントは不要なパリティパケットを受信しているか否か及びクライアントは既に加入しているFECグループを脱退する／不参加にする必要があるか否かを決める。そして、処理は430に戻る。

受信したパケットがFECパケットでなかった場合、445において、受信したパケットはメディアパケットであるか否かを決める検査が実行される。受信したパケットがメディアパケットであった場合、470においてメディアパケットが処理される。クライアント／移動装置がメディアパケットを受信した場合、その受信したメディアパケットは、シーケンスナンバーにしたがってデータ構造（リンクしたリスト）に挿入される。パケットが所属しているFECブロックが割り当てられた後に、メディアパケットが受信された場合、クライアント／移動装置は、メディアパケットのシーケンスナンバー、ベースシーケンスナンバー、FECブロックのN及びKに基づいて、リンクしたリストからそのFECブロック構造を特定することができる。クライアント／移動装置は、そのメディアパケットをマークし、FECブロック情報を更新する。そして、処理は485に進む。

例えばハンドオフのような場合、あるFECブロックのパリティパケットが全面的に欠落してしまうおそれがある。クライアント／移動装置は、そのFECブロックに所属するメディアパケットについて如何なるFEC情報も取得できないおそれがある。マークされていない最後のメディアパケットと、マークされていない最初のメディアパケットとの間の差分が、所定のしきい値（例えば、Kの推定値の3／2）を超えていた場合、クライアント／移動装置は、それらのメディアパケットに対する全てのFECブロックが欠落／損傷している（FECブロックはデコード可能でない）ものと結論する。クライアント／移動装置は、これらのメディアパケットに関する如何なるFEC情報にもよらず、本発明の適応FECアルゴリズム又はARQリクエスト処理を起動する。

受信したパケットがメディアパケットでなかった場合、450において、受信したパケットはARQパケットであるか否かを決める検査が実行される。受信したパケットがARQパケットであった場合、475において、ARQ抑制が実行され、ARQフィードバックの長期化の問題を回避する。そして、処理は430に戻る。

受信したパケットがARQパケットでなかった場合、455において、受信したパケットはRTCPパケットであるか否を決める検査が実行される。受信したパケットがRTCPパケットであった場合、480において、RTCPパケットが処理される。RTCPパケットのシーケンスナンバーはRTPパケットにしたがって割り当てられないので、受信したRTCPパケットは、それらが受信された時間にしたがってソースバッファに挿入される。そして、処理は430に戻る。受信したパケットがRTCPパケットでなかった場合、460において、受信したパケットは破棄される。そして、処理は430に戻る。

図４Ｃは、図３のクライアントプロキシ330により実行される方法の第２スレッドを示すフローチャートである。第２スレッドは、ソースパケット転送を処理する。433において、ソースバッファが空であるか否かを決める検査が実行される。ソースバッファが空であったならば処理は戻り、バッファがもはや空でないようになるまで待機する。433における検査は、何らかの時間に基づいて実行されてもよいし、あるいはソースバッファの状態について確認が可能であるような何らかの他の適切な判断基準に基づいて実行されてもよい。ソースバッファが空でなかった場合、443において、ヘッドパケット又は先頭パケット（head packet）に対するパケットバッファ時間が経過したか否かを決める検査が実行される。ヘッドパケットは、処理するバッファにおける次のパケットである。本発明による方法はリンクリストデータ構造を使用するので、バッファにおける次のパケットは、その構造における次のパケットであるとは限らず、処理される次のパケットは、リンクリストポインタが指す次のパケットである。バッファ時間が経過した場合、453において、ヘッドパケットはメディアプレーヤ又はメディアディスプレイ装置に転送される。すなわち、受信したメディアパケット又はRTCPパケットが時間Tを超えてバッファ内に残っていた場合、クライアント／移動装置はそのパケットをメディアプレーヤに転送する。463において、ヘッドパケットを指すポインタは、ソースバッファ内の次のパケットに設定される。そして、処理は433に戻る。ヘッドパケットバッファ時間が経過していなかった場合、処理は433に戻る。

図４Ｄは、図３のクライアントプロキシ330により実行される方法の第３スレッドを示すフローチャートである。第３レッドは、ARQ処理を取り扱う。437において、イベントキューバッファが空であるか否かを決める検査が実行される。イベントキューバッファが空であったならば処理は戻り、イベントキューバッファがもはや空でないようになるまで待機する。437おける検査は、何らかの時間に基づいて実行されてもよいし、あるいはイベントキューバッファの状態について確認が可能であるような何らかの他の適切な判断基準に基づいて実行されてもよい。イベントキューバッファが空でなかった場合、447において、ヘッドイベントタイマが経過したか否かを決める検査が実行される。ヘッドイベントタイマは、イベントキューにおける次のイベントを処理するためのタイマである。ヘッドイベントタイマが経過した場合、457において、ARQリクエストが送信される。467において、ヘッドイベントタイマは、イベントキューにおける次のイベントを指すように設定される。そして、処理は437に戻る。ヘッドイベントタイマが経過していなかった場合、処理は437に戻る。

図５には、クライアント側におけるメインデータ構造が示されている。クライアント／移動装置は、セッションにおけるメディアストリームのトラック各々について、ソースバッファ（メディアバッファ）を維持する。ソースバッファはT秒間のメディアパケットを蓄積する。ソースバッファは、リンクリストデータ構造を用いて実現される。以下に説明される本発明によるデータ構造は、図４Ａ、４Ｂ、４Ｃ及び４Ｄの処理に使用される。データ構造は、図４Ａ、４Ｂ、４Ｃ及び４Ｄの処理における複数の目的のために及び複数の時点において使用される。

FECブロックは１つ以上のメディアパケット（高々K個のメディアパケット）を含む。したがって、メディアパケットは、FECブロックに所属するように言及される。FECブロックは１つ以上のFEC（パリティ）パケット（高々n−k個のパリティ／FECパケット）も含んでいる。したがって、FEC／パリティパケットは、FECブロックに所属するように言及される。ここで、ｎはFECブロックサイズであり、ｋはFECブロック内のメディアパケット数である。メディアパケットが所属するFECブロックが割り当てられているならば、メディアパケットはマークされる。したがって、FECブロックが割り当てられていた場合、クライアント／移動装置は、メディアパケットのシーケンスナンバー、ベースシーケンスナンバー、FECブロックのN及びKに基づいて、リンクリストからそのFECブロック構造を特定することができる。

本発明の実施例において、サーバ側のFEC符号化の際、メディアパケットは修正されない。FEC符号化パラメータに関する全ての情報は、FECパケットに含まれている。本実施例は後方互換性を有する。なぜなら、クライアント／移動装置がFECをサポートしていなかった場合でさえ、クライアント／移動装置は、メディアマルチキャストグループに参加し、メディアパケットを受信し、受信したコンテンツを再生できるからである。

クライアント／移動装置がメディアパケットを受信すると、受信されたメディアパケットは、505a、505b、．．．505α＋1として示されているシーケンスナンバーにしたがって、ソースバッファデータ構造（例えば、リンクリスト）に組み込まれる。受信したメディアパケットが所属するFECブロックデータ構造が未だ割り当てられていなかった場合、クライアント／移動装置は、メディアパケットが所属するFECブロックに関する情報を何ら持っていない。メディアパケットは、FECブロックに関する如何なる情報も含んでいない。また、本発明は一定したN及びKをFEC符号化に使用せず（ただし、MaxN及びMaxKは固定されている）、FECブロックインデックス情報は、シーケンスナンバーから導出することはできない。メディアパケットが所属するFECブロックについて如何なる情報も無かった場合、そのメディアパケットはマークされない。

メディアトラックのリアルタイムトランスポート制御プロトコル（RTCP）パケットは、対応するソースバッファデータ構造（例えば、リンクリスト）にも組み込まれることに、留意を要する。RTCPパケットのシーケンスナンバーは、RTPパケットにしたがって割り当てられない。そうではなく、RTCPパケットは、RTCPパケットが受信された時間にしたがって、ソースバッファに挿入される。

メディアパケット又はRTCPパケットがバッファ内に所定の又は設定可能な時間Tを超えて残っていた場合、クライアント／移動装置はそのパケットをメディアプレーヤに送信する。

クライアント／移動装置は、FECブロックバッファデータ構造も維持する。このデータ構造は或るリンクリストとして実現されてもよく、そのリンクリスト中の要素各々は、ベースシーケンスナンバー、N及びK等のようなFECブロックに関する全ての情報を含むFECブロックデータ構造である。

クライアント／移動装置がパリティ（FEC）パケットを受信すると、クライアント／移動装置は、そのパリティパケットが所属するFECブロックに関する全ての情報を、FECブロックヘッダから取得する。クライアント／移動装置は、先ず、ブロックデータ構造がFECブロックに割り当てられているか否かを確認する。ブロックデータ構造が未だ割り当てられていなかった場合、ブロックデータ構造が割り当てられる。FECブロックデータ構造は、510a、510b、．．．510β＋1として示されているベースシーケンスナンバーにしたがって、データ構造（例えば、リンクリスト）に組み入れられる。FECブロックのベースシーケンスナンバーとは、そのFECブロックに属するメディアパケットの中で最小のシーケンスナンバーである。FECブロックが割り当てられた後、クライアント／移動装置はソースバッファを調べ、そのFECブロックに属するメディアパケットをマークし、そのブロックに対応する情報（例えば、どの程度多くのパケットが欠落しているか、どのパケットが欠落しているか等の情報）を更新する。この情報は本発明による適応FECにおいて使用される。この情報はFEC復号処理にも使用される（図４Ｂの485、490）。そして、そのFECブロックに関し、メディアパケット又はFECパケットが受信された場合、そのブロックの情報はそれに応じて更新される。

パケットが所属するFECブロックが割り当てられた後に、メディアパケットが受信された場合、クライアント／移動装置は、メディアパケットのシーケンスナンバー、ベースシーケンスナンバー、FECブロックのN及びKに基づいて、リンクリストからそのFECブロック構造を特定することができる。クライアント／移動装置はそのメディアパケットをマークし、FECブロック情報を更新する。

FECブロックデータ構造は、そのブロックに所属する全てのメディアパケットを指すポインタの配列（アレイ）を含む。FECブロックデータ構造は、そのブロックについてFECパケットを保存するのに使用されるデコードバッファも含む。FECデコードを実行するのに必要なメモリバッファも、デコードバッファにおいて割り当てられる。

FECブロックがデコード可能であった場合、FECデコード処理が実行され、復元されたメディアパケットはソースバッファに挿入される。FECブロックがデコードされた後に受信されたメディア又はFECパケットは破棄される。FECブロックに関する全てのメディアパケットがディスプレイに送信されると、FECブロック構造はクリアされ、メモリは解放される。

例えばハンドオフのような場合、あるFECブロックのパリティパケットが全面的に欠落してしまうおそれがある。クライアント／移動装置は、これらのメディアパケットについて如何なるFEC情報も取得できないおそれがある。クライアント／移動装置は、ソースバッファの中で第１未マークメディアパケットを指すポインタを維持し、図５におけるpkt−（α＋1）が第１未マークメディアパケットである。

最後の未マークメディアパケットと第１未マークメディアパケットとの間の差分が、所定のしきい値（例えば、Kの推定値の3／2）を超えていた場合、クライアント／移動装置は、それらのメディアパケットに対する全てのFECブロックが欠落／損傷している（FECブロックはデコード可能でない）ものと結論する。クライアント／移動装置は、これらのメディアパケットに関する如何なるFEC情報にもよらず、本発明の適応FECアルゴリズム又はARQリクエスト処理を起動する。本発目の場合、Kは固定されていないので、クライアント／移動装置はKの平均推定値を保持する。

クライアント／移動装置の各々は、イベントキューデータ構造を維持する。イベントはARQ処理イベントでもよく、クライアント／移動装置がARQリクエストを送信する又はARQ抑制を行うための全ての情報を含む。各イベントは、515a、515b、．．．515γ＋1のように示されている各自の経過時間にしたがって、イベントキューに挿入される。イベントはチェックイベントでもよい。例えば、クライアント／移動装置がARQリクエストを送信した後、クライアント／移動装置はイベントキューにチェックイベントを挿入（設定）し、クライアント／移動装置が再送パリティパケットを受信したか否か及びFECブロックをデコードできたか否かを後の時点で確認するようにしてもよい。クライアント／移動装置が再送パケットを受信しておらず、デコードできていなかった場合、クライアント／移動装置は別のARQリクエストを送信する。

マルチキャストセッションは、media＿groupにより表現される１つのメディアグループを有する。マルチキャストセッションにおけるメディアトラック各々は、多数のFECグループを有する。上述したように、FECグループ数は、例えばオーディオ及びビデオトラックに関して異なっていてもよい。適応FEC及びARQアルゴリズムは、メディアトラック各々について別々に装備される。以下の説明では、適応FEC及びARQアルゴリズムを説明するため、マルチキャストセッションは唯１つのメディアトラックを有するものとする。複数のトラックを伴うマルチメディアセッションの場合、本方法がトラック各々について使用可能である。

ストリームは、全部でm＋1個のFECグループ（グループ（0）、グループ（1）、．．．グループ（m））を有し、グループ（0）ないしグループ（m−1）は適応FECグループであり、グループ（m）はARQに使用されるものとする。第１のFECグループは、メディアグループ直後に送信される（非遅延FECグループ）。クライアントはメディアグループ及び第１のFECグループに常に加わっている。以下、グループに関するパラメータを指すために、グループ番号を使用する。例えば、グループ（i）のオーバーヘッドはオーバーヘッド（i）であり、グループ（i）の遅延は遅延（i）である。FECコードがブロックサイズｎを有するとすると、各ブロックにおけるメッセージシンボル数は、次のように書ける：

各ブロックにおけるパリティシンボル数は、次のように書ける。

num＿parity（i）＝overhead（i）*k
クライアント／移動装置は、受信したFECブロックについて平均損失率及びその変分（variance）をavg＿loss＿rate及びavg＿varianceとしてそれぞれ推定する。

クライアント／移動装置がFECブロックについて第１のFECパケットを受信している場合、それは、クライアント／移動装置が現在のFECブロックの最後のメディアパケット／シンボルを受信していることを意味する。

クライアント／移動装置は、FECヘッダから、FECブロックに関する全ての情報を抽出し、そのFECブロックについて、何らかのメディアパケットが欠落しているか否か及びどの程度多くパケットが欠落しているかの情報を得る。この情報は平均損失率及び変分の推定値を更新するのに使用される。この時点において、クライアント／移動装置が、現在のFECブロックをデコードするのに十分なパケット／シンボルを既に受信していた場合、クライアント／移動装置は、新たなどのFECグループに参加する必要はなく、ARQリクエストを送信する必要もない。しかしながら、クライアント／移動装置が、さらなるFECグループに加わっていた場合、クライアント／移動装置は冗長的なパリティパケット／シンボルを受信する。したがって、クライアント／移動装置は、そのクライアント／移動装置が必要とするよりも多いパリティパケット／シンボルを受信する。クライアントは、それらのFECグループを去る（脱退する）必要がある。

クライアントが現在のFECブロックをデコードするのに十分なシンボルを受信していないと仮定する。欠落したメディア／メッセージシンボル数は、lost＿msg＝k−recv＿msgである。クライアント／移動装置は、参加する必要があるFECグループ数を決定しなければならない。第１実施例では、一度に全てのグループに加わる。第２実施例では、先ず１つの追加的なFECグループに加わる。いくらか時間が経過した後で、クライアント／移動装置は、FECブロックをデコードするのに十分なパケット／シンボルを受信しているか否かを確認する。受信していなかった場合、クライアント／移動装置は次のFECグループに加わる。

第１実施例の場合、必要とされるシンボル数は、次のように推定できる。

req＿sym＝lost＿msg*（1＋avg_loss_rate）＋α*avg＿variance。

無線ネットワークの場合、パケット損失の変化は非常に大きくなり得る。したがって、多くの場合、クライアント／移動装置は、必要なパリティシンボルを過剰に見積もってしまう。しかしながら、必要なシンボルを過小評価し、FECブロックをデコードを困難にしてしまうおそれもある。クライアント／移動装置が必要とするグループ数は、次式のように表現できる。

クライアント／移動装置がマルチキャストFECグループに加わる場合、クライアント／移動装置は、そのクライアント／移動装置がそのグループに滞在する期間を指定する必要がある。これは、grp＿expireパラメータにより指定される。

grp＿expire（i）＝current＿time＋delay（i）＋Te i≦m−1 （２）
ここで、Teは調整可能なパラメータであり、例えばTe＝500msである。クライアント／移動装置は全ての適応FECグループに参加しているが、依然としてFECブロックをデコードできない場合、クライアント／移動装置はARQリクエストを送信しなければならない。フィードバックの長期化の問題に対処するため、ARQリクエストは速やかには送信されない。ARQリクエストタイマがイベントキューに設定され、タイマの経過時間は、（K−lost＿msg）*Tsと、（K−lost＿msg＋1）*Tsとの間に設定される。このように、ほとんどのパケットを失っているクライアント／移動装置は、ARQリクエストを先ず送信する。ARQリクエストは、ARQリクエストマルチキャストグループにマルチキャストされる。このARQリクエストを受信した他のクライアント／移動装置は、受信したARQリクエストにおける要求パリティパケットの番号と、自身が要求したものとを比較する。他のクライアント／移動装置が要求したパリティパケット番号が、自身の要求したものより大きかった場合、クライアント／移動装置は自身によるARQリクエストを抑制し、自身が必要とするものより多くのパリティパケットを含むマルチキャストを待機する。

第２実施例の場合、クライアント／移動装置は、先ず、１つの追加的な遅延FECグループに加わる。タイマがセットされる。タイマは、次の遅延FECグループの遅延時間よりもいくらか前に満了すべきである。そうすれば、クライアント／移動装置がFECブロックを依然としてデコードできないと判断した場合、クライアント／移動装置が次のFECグループに加わる時間がある。例えば、IGMP参加時間が数msないし50msの間にある場合、タイマ満了時間は、次のFECグループ遅延時間よりもTx＝100ms前として指定される：
timer＿expire（i）＝current＿time＋delay（i＋1）−Tx （３）
ここで、Txは調整可能なパラメータである。また、FECグループに既に加わっていた場合、クライアント／移動装置は、グループの満了時間を更新する必要があるだけであり、タイマが設定される必要がある。クライアント／移動装置が最後の適応FECグループに加わっているが、FECブロックを依然としてデコードできない場合、クライアント／移動装置はARQリクエストを送信する必要がある。

FECブロックの中で欠落したメディアパケット数が閾値（例えば、Kの50％）を超えているような場合、パリティパケットを求めるためだけにARQを送信することは効率的でない。この場合、クライアント／移動装置は、ARQを送信することで、オリジナルのメディアパケットを送信することを求めることができる。

クライアント／移動装置がFECブロックをデコードするのに十分なパケット／シンボルを受信した場合、あるいはクライアント／移動装置が、参加しているFECグループが提供するものより少ないパリティシンボルしか必要としない場合、クライアント／移動装置は、１つ以上のFECマルチキャストグループを去る（脱退する）べきであるか否かを確認する。数式（１）はクライアント／移動装置が参加すべきFECグループ数を与え、現在参加しているグループ数l（エル）がｇより大きかった場合、クライアント／移動装置は、グループ（g＋1）ないしグループ（g＋l（エル））を脱退するべきである。参加及び脱退する回数を減らすため、別のパラメータが導入される。

及びt＝max（g，h）とする。l（エル）＞tならば、クライアント／移動装置は、グループ（t＋1）ないしグループ（l（エル））を脱退する。

図６は、本発明による結合ハイブリッドARQ法を使用するサーバ側の概略ブロック図である。具体的には、図６は本発明によるストリーミングサーバ115及びARQサーバ160を示す。上述したように、ストリーミングサーバ及びARQサーバは、異なる機器に設けられてもよいし、１つの機器に並存させてもよい。ストリーミングサーバ115は、コンテンツサーバ105及び／又はライブコンテンツサーバ111から、コンテンツRTP（メディア）パケットの形式でコンテンツを受信する。FCモジュール605は、これらのメディアパケットをFECブロックに割り当て、FEC／パリティパケットが生成され、FECブロックの中でｋ個のメディアパケットとn−k個のFEC／パリティパケットとが存在するように、FEC／パリティビットがFECブロックに付加される。FEC／パリティパケットは、増加するパリティ／FECを表すレイヤ（複数）に分けられ、コンテンツを復元するにはFECブロック（メディアパケット及び非遅延FECパケットを含む）が不十分であった場合にクライアント／移動装置が要求及び使用する。クライアント／移動装置は、追加的なFECを提供するマルチキャストグループに加わることで、追加的なFECを要求する。追加的なFECは、それが必要とされた場合に遅延バッファ610に保存される。全てのデータ（メディア、非遅延FEC及び遅延FEC）は、UDP／IP／イーサーネットプロトコルスタック615を介してクライアント／移動装置に転送される。

コンテンツ（メディアパケット）は、ストリーミングサーバ115によりARQサーバ160に転送される。また、ストリーミングサーバ115は、ARQ−FECグループのFECパケットをARQサーバ160に転送する。コンテンツ及びARQ−FECパケットの双方は、UDP／IP／イーサーネットプロトコルスタック620を介してハイブリッドARQプロセスモジュール625に転送される。クライアント／移動装置が、FECパケット又はコンテンツパケットの再送を求めるNACKを送信する場合、クライアント／移動装置は、ARQ再送マルチキャストグループに加わり、FECパケット又はコンテンツパケットの再送を受信する。何種類かのNACK／ARQリクエストが存在する。第１のタイプのNACK／ARQリクエストの場合、クライアント／移動装置は、必要とする数のFECパケットを要求し、第２のタイプのNACK／ARQリクエストの場合、クライアント／移動装置は、ARQサーバが特定のコンテンツパケットを再送することを要求する。この場合、NACK／ARQリクエストは、クライアント／移動装置が必要とするコンテンツパケットのシーケンスナンバーを含む。第３のタイプのNACK／ARQリクエストは、上記２つのNACK／ARQリクエストの組み合わせである。第３のタイプの場合、クライアント／移動装置は、ある数のFECパケット及びあるコンテンツパケットを要求する。NACKがクライアント／移動装置から受信されると、ARQグループにおけるオリジナルコンテンツ又はFECパケットの再送が、ハイブリッドARQプロセスモジュール625により処理され、UDP／IP／イーサーネットプロトコルスタック620により送信される。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特定用途プロセッサ又はそれらの組み合わせ等の様々な形式により実現されてもよいことが、理解されるであろう。好ましくは、本発明はハードウェアとソフトウェアの組み合わせにより実現される。さらに、ソフトウェアは、プログラムストレージ装置に実際に組み込まれるアプリケーションプログラムとして実現されることが好ましい。アプリケーションプログラムは、適切な何らかのアーキテクチャを有するマシンにアップロードされ、それにより実行される。好ましくは、マシンは、ハードウェアを有するコンピュータプラットフォームにより実現され、ハードウェアは、１つ以上の中央処理装置（CPU）、ランダムアクセスメモリ（RAM）及び入力／出力（I／O）インターフェース等である。コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含む。上記の様々な処理及び機能は、マイクロ命令コードの一部分でもよいし、オペレーティングシステムを介して実行さえるアプリケーションプログラムの一部分でもよい（又はそれらの組み合わせでもよい。）。さらに、（追加的なデータストレージ装置や、印刷装置のような）他の様々な周辺装置がコンピュータプラットフォームに接続されてもよい。

さらに、添付図面に示されるシステム構成要素及び方法ステップの一部は、好ましくはソフトウェアにより実現されるので、システム構成要素間の実際の接続は、本発明をプログラムする仕方に依存して異なることが、理解されるべきである。本願により教示したものにより、当業者は、本発明の上記の及び同様な実施形態や構成例を把握することができるであろう。

Claims (45)

1. マルチキャストの信頼性を向上させる方法であって、
   順方向誤り訂正符号化パケットの複数のレイヤを生成するステップと、
   複数の順方向誤り訂正符号化パケットの第１レイヤ及びコンテンツを送信するステップと、
   複数の順方向誤り訂正符号化パケットの第２レイヤを要求に応じて送信するステップと、
   複数の順方向誤り訂正符号化パケットの第３レイヤを、自動再送要求メッセージの受信に応じて送信するステップと、
   複数の順方向誤り訂正符号化パケットの第４レイヤ及びコンテンツを、自動再送要求のコンテンツリクエストの受信に応じて送信するステップと
   を有する方法。
2. 複数の順方向誤り訂正符号化パケットの前記第１レイヤ及び前記コンテンツを受信するために、移動装置が第１のマルチキャストグループに加わる、請求項１記載の方法。
3. 複数の順方向誤り訂正符号化パケットの前記第２レイヤを受信するために、移動装置が第２のマルチキャストグループに加わる場合に、前記要求がなされる、請求項１記載の方法。
4. 複数の順方向誤り訂正符号化パケットの前記第３レイヤを受信するために、移動装置が第３のマルチキャストグループに加わる場合に、前記自動再送要求がなされる、請求項１記載の方法。
5. 複数の順方向誤り訂正符号化パケットの前記第４レイヤ及び前記コンテンツを受信するために、移動装置が第４のマルチキャストグループに加わる場合に、自動再送要求の前記コンテンツリクエストがなされる、請求項１記載の方法。
6. 複数の順方向誤り訂正符号化パケットの前記第３レイヤが、自動再送要求サーバにより送信される、請求項１記載の方法。
7. 複数の順方向誤り訂正符号化パケットの前記第４レイヤ及び前記コンテンツが、自動再送要求サーバにより再送される、請求項１記載の方法。
8. 複数の順方向誤り訂正符号化パケットの前記第２レイヤが、ストリーミングサーバにより送信される、請求項１記載の方法。
9. 複数の順方向誤り訂正符号化パケットの前記第２レイヤの各々が、調整可能な期間の分だけ時間的に遅延させられる、請求項１記載の方法。
10. 複数のレイヤ各々に適用される順方向誤り訂正符号化の量が、設定可能である、請求項１記載の方法。
11. 前記コンテンツが、複数のメディアトラックを含む、請求項１記載の方法。
12. マルチキャストの信頼性を向上させるシステムであって、
    順方向誤り訂正符号化パケットの複数のレイヤを生成する手段と、
    複数の順方向誤り訂正符号化パケットの第１レイヤ及びコンテンツを送信する手段と、
    複数の順方向誤り訂正符号化パケットの第２レイヤを要求に応じて送信する手段と、
    複数の順方向誤り訂正符号化パケットの第３レイヤを、自動再送要求メッセージの受信に応じて送信する手段と、
    複数の順方向誤り訂正符号化パケットの第４レイヤ及びコンテンツを、自動再送要求のコンテンツリクエストの受信に応じて送信する手段と
    を有するシステム。
13. 複数の順方向誤り訂正符号化パケットの前記第１レイヤ及び前記コンテンツを受信するために、移動装置が第１のマルチキャストグループに加わる、請求項１２記載のシステム。
14. 複数の順方向誤り訂正符号化パケットの前記第２レイヤを受信するために、移動装置が第２のマルチキャストグループに加わる場合に、前記要求がなされる、請求項１２記載のシステム。
15. 複数の順方向誤り訂正符号化パケットの前記第３レイヤを受信するために、移動装置が第３のマルチキャストグループに加わる場合に、前記自動再送要求がなされる、請求項１２記載のシステム。
16. 複数の順方向誤り訂正符号化パケットの前記第４レイヤ及び前記コンテンツを受信するために、移動装置が第４のマルチキャストグループに加わる場合に、自動再送要求の前記コンテンツリクエストがなされる、請求項１２記載のシステム。
17. 複数の順方向誤り訂正符号化パケットの前記第３レイヤが、自動再送要求サーバにより送信される、請求項１２記載のシステム。
18. 複数の順方向誤り訂正符号化パケットの前記第４レイヤ及び前記コンテンツが、自動再送要求サーバにより再送される、請求項１２記載のシステム。
19. 複数の順方向誤り訂正符号化パケットの前記第２レイヤが、ストリーミングサーバにより送信される、請求項１２記載のシステム。
20. 複数の順方向誤り訂正符号化パケットの前記第２レイヤの各々が、調整可能な期間の分だけ時間的に遅延させられる、請求項１２記載のシステム。
21. 複数のレイヤ各々に適用される順方向誤り訂正符号化の量が、設定可能である、請求項１２記載のシステム。
22. 前記コンテンツが、複数のメディアトラックを含む、請求項１２記載のシステム。
23. マルチキャストの信頼性を向上させる方法であって、
    第１のマルチキャストグループから、複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信するステップと、
    １つの追加的なレイヤの順方向誤り訂正パケットと前記コンテンツとを、複数の順方向誤り訂正符号化パケットの別の追加的なレイヤとともに受信するために、追加的なマルチキャストグループに加わるステップと
    を有する方法。
24. 第１のマルチキャストグループからの、複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとによっては、コンテンツが復元可能でなかった場合に、前記加わるステップが行われる、請求項２３記載の方法。
25. 複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信するために、前記第１のマルチキャストグループに加わるステップをさらに有する、請求項２３記載の方法。
26. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の受信した第１レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第２レイヤを受信するために、第２のマルチキャストグループに加わるステップが実行される、請求項２４記載の方法。
27. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の第１レイヤと、複数の順方向誤り訂正符号化パケットの内の第２レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第３レイヤを受信するために、第３のマルチキャストグループに加わるステップが実行される、請求項２４記載の方法。
28. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の第１レイヤと、複数の順方向誤り訂正符号化パケットの内の第２レイヤと、複数の順方向誤り訂正符号化パケットの内の第３レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第４レイヤ及びコンテンツを受信するために、第４のマルチキャストグループに加わるステップが実行される、請求項２４記載の方法。
29. 複数の順方向誤り訂正符号化パケットの前記第１及び第２レイヤが、調整可能な期間の分だけ時間的に遅延させられ、該調整可能な期間は、追加的なマルチキャストグループに加わるのに必要な時間より長い、請求項２４記載の方法。
30. 欠落したパケット数が閾値を超えた場合に、前記第４のマルチキャストグループに加わることが決定される、請求項２８記載の方法。
31. 復元されたコンテンツを再生装置に転送するステップをさらに有する、請求項２３記載の方法。
32. 当該方法がクライアントプロキシモジュールにより実行される、請求項２３記載の方法。
33. 複数の追加的なマルチキャストグループに同時に加わる、請求項２３記載の方法。
34. 前記コンテンツは、複数のメディアトラックを含む、請求項２３記載の方法。
35. マルチキャストの信頼性を向上させる装置であって、
    第１のマルチキャストグループから、複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信する手段と、
    １つの追加的なレイヤの順方向誤り訂正パケットと前記コンテンツとを、複数の順方向誤り訂正符号化パケットの別の追加的なレイヤとともに受信するために、追加的なマルチキャストグループに加わる手段と
    を有する装置。
36. 複数の順方向誤り訂正符号化パケットの内の第１レイヤとコンテンツとを受信するために、前記第１のマルチキャストグループに加わる手段をさらに有する、請求項３５記載の装置。
37. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の第１レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第２レイヤを受信するために、第２のマルチキャストグループに加わる手段が起動される、請求項３５記載の装置。
38. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の第１レイヤと、複数の順方向誤り訂正符号化パケットの内の第２レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第３レイヤを受信するために、第３のマルチキャストグループに加わる手段が起動される、請求項３５記載の装置。
39. 受信したコンテンツと、複数の順方向誤り訂正符号化パケットの内の第１レイヤと、複数の順方向誤り訂正符号化パケットの内の第２レイヤと、複数の順方向誤り訂正符号化パケットの内の第３レイヤとによっては、コンテンツが復元可能でなかった場合に、複数の順方向誤り訂正符号化パケットの内の第４レイヤ及びコンテンツを受信するために、第４のマルチキャストグループに加わる手段が起動される、請求項３５記載の装置。
40. 複数の順方向誤り訂正符号化パケットの前記第１及び第２レイヤが、調整可能な期間の分だけ時間的に遅延させられ、該調整可能な期間は、追加的なマルチキャストグループに加わるのに必要な時間より長い、請求項３５記載の装置。
41. 欠落したパケット数が閾値を超えた場合に、前記第４のマルチキャストグループに加わることが決定される、請求項４０記載の装置。
42. 復元されたコンテンツを再生装置に転送する手段をさらに有する、請求項３５記載の装置。
43. 当該装置がクライアントプロキシモジュールを有する、請求項３５記載の装置。
44. 複数の追加的なマルチキャストグループに同時に加わる、請求項３５記載の装置。
45. 前記コンテンツは、複数のメディアトラックを含む、請求項３５記載の装置。

Images