JP2011503966A - スケーラブルマルチメディアデータストリームをストリーミングする方法及び装置 - Google Patents

Abstract

あるレイヤに関連するコンテンツの符号化されたパケットを受信し、チャネル状態に関するフィードバック情報を受信し、フィードバック情報に基づいてパケットを伝達するためにハイブリッドＡＲＱを利用する方法及び装置が記載される。ハイブリッドＡＲＱをレイヤ毎に利用する方法及び装置は、あるリソースが使い尽くされたかを判定し、リソースが使い尽くされていない場合、あるレイヤのレイヤード符号化コンテンツパケットの伝達をスケジュールし、レイヤの全てのレイヤード符号化コンテンツパケットが送信されたかを判定し、レイヤの全てのレイヤード符号化パケットが送信されていない場合、最初の判定手段による処理に進み、確認メッセージがユーザ装置から受信されたかを判定し、確認メッセージが受信されていない場合、リソースが使い尽くされたかを判定し、リソースが使い尽くされていない場合、レイヤード符号化順方向誤り訂正パケットの伝達をスケジュールする。

Description

本発明は、スケーラブルマルチメディアデータストリームのストリーミングに関し、より詳細には、損失の多いネットワークを通したユニキャスト及びマルチキャスト環境の両者においてマルチメディアデータストリームをストリーミングすることに関する。

マルチメディアストリーミングの応用は、典型的に、有線又は無線ネットワークにより提供されるリアルタイムサービスに共通する。マルチメディアストリーミングのようなリアルタイムサービスは、遅延の制約により特徴付けされる。クライアントに遅れて到達するマルチメディアストリームデータ（サービスデータ）は、クライアントにより一般に廃棄される。マルチメディアストリーミングデータは、クライアント装置でユーザに表示されているので、データに関連するデッドラインを有する。ネットワークにおける混雑又はチャネル障害のような理由のため、クライアントへのマルチメディアストリーミングデータのタイムリー且つ正しい伝達を常に保証することはできない。したがって、クライアントでは、再生の間に欠けているマルチメディアデータが存在する。

大量のマルチメディアデータのため、マルチメディアストリーミングアプリケーションは、広いネットワーク帯域幅を必要とすることがある。それら帯域幅で制約されたネットワークについて、データ伝送レートの制約が係るアプリケーションに課されることがある。ここで帯域幅、データ伝送レート及びネットワーク伝送レートは、全て同じ意味で使用される。帯域幅は、ヘルツで典型的に測定されるが、デジタル通信において、帯域幅は、実際には伝送レートである毎秒当たりのビット数（ｂｐｓ）で規定されることがある。その一方で、たとえばファイルダウンロード及びウェブブラウジングといった上位レイヤのアプリケーションで利用可能なネットワーク帯域幅は、ネットワーク混雑、物理レイヤのチャネル停止等のようなファクタに依存して時間につれて変動する場合がある。利用可能なネットワーク帯域幅がマルチメディアストリーミングの応用により要求される量よりも低いとき、ストリーミングサーバは、データドロッピングポリシーに従ってデータレートを低減するため、マルチメディアデータを強制的に廃棄する場合がある。先の理由により、クライアントでデータロスが生じる場合があり、クライアントの再生品質に悪影響を及ぼす可能性がある。

したがって、遅延及び／又は帯域幅が制約されたマルチメディアストリーミングアプリケーションが損失が多いネットワークを通してマルチメディアデータを伝送するとき、マルチメディアの再生品質を改善する方法及び装置を有することは有利である。本明細書で使用されるように、“／”は同じ又は類似の動作又は構成要素の代替的な名称を示す。

マルチメディアストリーミングアプリケーションは、厳密な遅延及び帯域幅の制約を有することがある。本発明は、フィードバックチャネルを提供する損失の多いネットワークを通してクライアントにスケーラブルコーデックにより圧縮されたマルチメディアコンテンツをストリーミングするサーバの方法及び装置を記載する。本発明によれば、クライアントサイドでのマルチメディアの再生品質を改善することができる。

あるレイヤに関連されるコンテンツの符号化パケットを受信し、チャネルの制約に関するフィードバック情報を受信し、ハイブリッドＡＲＱ（automatic repeat request）を適用して、前記フィードバック情報に基づいてパケットを伝達することを含む方法及び装置が記載される。レイヤ毎にハイブリッドＡＲＱを適用する方法及び装置は、あるリソースが使い尽くされたかを判定し、そのリソースが使い尽くされていない場合、あるレイヤについてレイヤード符号化コンテンツパケットの伝達をスケジュールし、そのレイヤについて全てのレイヤード符号化コンテンツパケットが送信されたかを判定し、あるレイヤについて全てのレイヤード符号化コンテンツパケットが送信されていない場合、最初の判定ステップに進み、確認メッセージがユーザ装置から受信されたかを判定し、確認が受信されていない場合、そのリソースが使い尽くされたかを判定し、そのリソースが使い尽くされていない場合、レイヤード符号化前方誤り訂正パケットの伝達をスケジュールすることを更に含む。

本発明は、添付図面と共に読まれたとき、以下の詳細な説明から良好に理解されるであろう。図面は、以下に簡単に説明される図を含む。
本発明がユニキャストで動作する環境の概要を示す図である。 本発明の動作の一部のフローチャートである。 本発明の動作の一部のフローチャートである。 本発明の原理に係るパケットスケジューラのブロック図である。 例示的な時間スケーラビリティの符号化構造を示す図である。 本発明がマルチキャストで動作する環境の概要を示す図である。 本発明の原理に係るパケットスケジューラのブロック図である。

リアルタイムのマルチメディアサービスは、高いデータの信頼性と低い境界された時間遅延を必要とする。しかし、係るサービスが提供される多くのネットワークは、誤りが生じる傾向があり、帯域が制限されている。したがって、許容可能なサービス品質を得るために適切な誤り制御技術が必要である。

本明細書で使用されるように、「クライアント」は、任意のユーザ装置、エンド装置、モバイル端末、プロセッサ、ラップトップ、パーソナルデジタルアシスタント、デュアルモードモバイルフォン、セットトップボックス、又は、オーディオ、ビデオ及びマルチメディアコンテンツを含むコンテンツを表示又は再生するために使用される他の装置を含む。本明細書で使用されるように、ソース又はサービスデータは、オーディオ、ビデオ及びマルチメディアデータを含む任意の形式の圧縮されていないコンテンツ／圧縮されたコンテンツを含む。

順方向誤り訂正（ＦＥＣ）符号化は、損失の多いネットワークのスループットを改善するために一般に使用される誤り制御技術である。ＦＥＣは、制御された冗長度をサービスデータに追加し、冗長データ（本明細書ではＦＥＣデータとも呼ばれる）は、ネットワークを通してクライアントに送出される。データ損失があるときは何時でも、クライアントは、損失を検出して回復するために、ＦＥＣデータにより提供される冗長度を利用する。しかし、データ損失を効率的に回復するため、ＦＥＣの量は、ネットワークの損失の条件に従って調節される必要がある。しかし、たとえばワイヤレスネットワークといった多くのネットワークのチャネルの時間変動する特性のため、係る正確な情報はめったに得られない。したがって、係るネットワークについて、アンダープロビジョン（under provision）で、ＦＥＣは、ＦＥＣ障害を引き起こす可能性があり、オーバプロビジョン（over provision）で、ＦＥＣは、ネットワークのスループットを不要に減少する可能性があり、両者は、マルチメディアの再生品質の低下を引き起こす可能性がある。

再送信は、ネットワークがフィードバックチャネルを提供し、クライアントがフィードバック情報を発生可能であるとき、損失が多いネットワークにおいて一般に使用される別の技術である。典型的な再送信のために設計されるプロトコルは、以下のように機能する。送信機側で、サービスデータがネットワークを通して送出されるとき、サーバは、ネットワークフィードバックチャネルを通してクライアントからの確認（ＡＣＫ）を待つ。受信機側で、クライアントが全てのデータを正しく受信したとき、ＡＣＫのみがクライアントにより送出される。所定の時間後（タイムアウト期間と呼ばれる）、サーバがＡＣＫを受信していない場合、データが失わたことを想定し、同じデータをクライアントに再び送信する。このプロセスは、そのデータについてクライアントからサーバが受信するまで繰り返され、次いで、同じプロセスは、もしあれば後続のデータについて開始する。再送信の方法は、送信の間に失われているデータを再び送信するだけであるので、帯域幅の効率が高い。しかし、サーバは、実行するためにＡＣＫを待つ必要があり、これは通常、リアルタイムマルチメディアサービスに適さない長い遅延を導入する。また、この方法は、良好にスケーリングされない。クライアント数が多いとき、ＡＣＫの数は無限に成長し、したがって、スループットに深刻に影響を及ぼす可能性がある。制限されないＡＣＫの問題は、ＡＣＫが激増する問題と呼ばれる。

第三の方法は、ハイブリッドＡＲＱであり、この方法は、再送信及びＦＥＣの両者の利益を結合する。ハイブリッドＡＲＱにより、送信機側で、サーバは、クライアントにはじめにユーザデータを送出し、次いでＦＥＣデータを送出する。このプロセスの間、クライアントが損失を回復するために全てのユーザデータ又は十分なＦＥＣデータを受信したとき、クライアントは、ネットワークにより提供されるフィードバックチャネルを通してサーバにＡＣＫを送り返す。ひとたびサーバがＡＣＫを受信すると、これ以上をデータを送出するのを停止する。クライアントに送出されるＦＥＣデータの量はＡＣＫを通して現在のネットワークの状態に従って適切に調節することができるので、ハイブリッドＡＲＱは、高い帯域幅の効率を維持することができる。しかし、ネットワークが過度の損失を受けたとき、サーバは、ＡＣＫを受信するために大量のＦＥＣデータを送出する必要がある。ＦＥＣデータの量がデータ伝送レートの制限を超えるか、又はＦＥＣ伝送の期間が遅延の制約を超えるとき、コンテンツデータの損失は、ハイブリッドＡＲＱ方法により更に生じる可能性があり、マルチメディアの再生の品質を低下させる可能性がある。

スケーラブルソースコーダは、ソースコンテンツを圧縮し、スケーラブル符号化ビットストリームを生成し、これにより、ビットストリームの一部は、結果として得られるサブビットストリームが所与のデコーダのための別の有効なビットストリームを形成するやり方で除かれる。この別の有効なビットストリームは、オリジナルのビットストリームに比較して低減された再構成の品質をもつソースコンテンツを表す。たとえばビデオ符号化用にＨ．２６４／ＡＶＣ（時間スケーラビリティ）、ＳＶＣ（時間、ＳＮＲ及び空間スケーラビリティ）、及び画像符号化用にＪＰＥＧ２０００、ＳＰＩＨＴといった多くのスケーラブルソースコーダが存在する。

上述されたソースコーダにより生成されるスケーラブルソースビットストリームは、多数のレイヤに分割される。第一のレイヤは、ソースの表現を含み、独立してデコード可能である。それぞれの後続のレイヤは、ソースに関する更なる情報を含み、正しい復号化のために全ての前のレイヤに依存する必要がある。したがって、一般に、スケーラブルビットストリームの全てのレイヤのうち、第一のレイヤは、オリジナルソースを再構築する観点で最も高い重要度を有し、他のレイヤの重要度は、そのレイヤのインデックスが増加するにつれて減少する。

以下では、あるクライアントにフィードバックチャネルをもつ損失が多いネットワークを通してスケーラブルビットストリームをユニキャストするマルチメディアストリーミングアプリケーションが考慮される。アプリケーションは、以下で記載されるデータレート、伝送レート及び遅延の制約を有する。

レイヤｍの重要度がｍが増加するにつれて減少するように、マルチメディアコンテンツのユニットがスケーラブルソースコーダによりＭ個のレイヤにエンコードされるとする（１≦ｍ≦Ｍ，ｍ∈Ｎ）。さらに、ソースレイヤｍからのビットストリームがネットワークデリバリのためにＫmのソースパケットにパケット化されるとする。さらに、ＬmのＦＥＣパケットは、リードソロモン（ＲＳ）コードのような所定のＦＥＣコードを使用して、レイヤｍについて符号化される。特に、データ伝送レート又は遅延の制約なしに、Ｌmがレイヤｍについて可能なデータの損失を回復するために十分に大きいとする。以下では、「データパケット」は、一般にソース及びＦＥＣパケットの両者を含む。

コンピュータネットワークにおいて、及び本明細書で使用されるように、帯域幅は、データ伝送レートを示すために使用されることがあり、したがって毎秒当たりのビット数として通常示される。大部分のネットワークでは、通信パスは、パスに沿った個々のノード間の一連のリンクを含む。パスの帯域幅は、２つのリンク間の最も低い帯域幅により制限される。

Ｂをアプリケーションに割り当てられるネットワーク伝送ビットレート（ｂｐｓ）とし、Ｔをアプリケーションがデータを伝送するために許可されるタイムスロットの期間（秒）とする。それぞれのタイムスロットについて、ＢＴは、アプリケーションについて割り当てられたトータルビットバジェット（所与のタイムスロットにおいてリンクを通して送信されるか又は送信することができる全体のビット数）に等しく、［ｄ1，ｄ2］をビデオデータについて再生のデッドラインをインクリメンタルに示す。

本発明は、ハイブリッドＡＲＱ方法をマルチメディアデータストリーミングのためのスケーラブルソース符号化の特性とを結合する。サーバがデータを送信することが許可されるそれぞれのタイムスロットの開始で、サーバは、再生のデッドラインを［ｄ1，ｄ2］に含ませるスケーラブルビットストリームのそれぞれのレイヤについて、パケット数に関する情報を取得する。係る情報は、コンテンツデータを符号化／記憶するコンテンツサーバで通常取得される。ネットワークサーバは、コンテンツサーバから係る情報を要求及び受信する。ネットワークサーバは、次いで、専用の情報パケットにより、又はたとえばパケットヘッダにおける前のタイムスロットからのパケットを通して伝達される副情報により、この情報に関してクライアントに通知する。

送信機側で、ひとたびそのレイヤにおけるソースパケットの数に関する情報のクライアントの受信をネットワークサーバが保証すると、タイムスロットに属するデータパケットを送出し始める。特に、ネットワークサーバは、最も低いレイヤのインデックス（最も高い優先度）をもつレイヤから到達するデータパケットをはじめに送出し、次いで、インクリメンタルに高いレイヤのインデックスをもつ次のレイヤに進む。それぞれのレイヤ内で、ソースパケットがはじめに送出され、次にＦＥＣパケットが後続する。

受信機側で、クライアントは、あるレイヤについてデータパケットを受信し、そのレイヤについて全てのソースパケットを受信したかを常時チェックするか、又は、受信されたＦＥＣパケットを使用して、欠けているソースパケットを回復することができる。これは、そのタイムスロットについて期待されるそれぞれのレイヤの正確なソースパケットの数を知っているために可能である。ひとたび全てのソースパケットがクライアントレイヤについて利用可能であると、ＡＣＫをフィードバックチャネルを通してサーバに送出する。クライアントは、現在のレイヤについて受信されるそれぞれのデータパケットについて先のプロセスを繰り返す。

送信の間、以下の３つのイベントのうちの１つは、サーバに発生する。
１．クライアントからＡＣＫが到達する。
２．タイムスロットのビットバジェットＢＴが使い尽くされる。
３．持続期間Ｔがタイムスロットについて経過する。

イベント１は、クライアントがレイヤｍから全てのビデオパケットを受信したか、又はレイヤｍから全てのビデオパケットを回復することができることを示す。このイベントに応答して、サーバは、レイヤｍについてデータパケットの送出を停止し、レイヤｍ＋１からのデータパケットに送出に進む（ｍ＋ｌ≦Ｍ）。現在のレイヤが最も高い利用可能なレイヤである場合、サーバは、単にアイドリング状態に留まり、次のタイムスロットを待つ。イベント２又は３が生じたとき、アプリケーションがそのデータ伝送レートの限界に到達したことを示す。次いで、サーバは、次のタイムスロットを待つ必要があり、先の動作を繰り返す。

本発明は、クライアントのグループへのマルチメディアデータのマルチキャストに更に拡張される。それぞれのレイヤｍについて、そのグループにおける各クライアントが受信するか、又はソースレイヤを回復することができるとき、唯一のＡＣＫがサーバに送出される。１実施の形態では、有線／無線ネットワークにおけるクライアント／受信機／ユーザ装置のクラスが存在する。クライアントのグループは、それらのチャネル損失の状態に基づいてカテゴリ化／クラスタリングされる。したがって、クライアントが属するマルチキャストグループは、個々のクライアントのチャネル状態が変化するにつれて、時間と共に変化する場合がある。すなわち、個々のクライアントは、そのチャネル状態に基づいて時間を通して１以上のグループに加わり、１以上のグループから離れる場合がある。係るシナリオでは、あるグループにおけるクライアントは、それら自身の間で通信し、あるコンテンツレイヤに対応する１つのＡＣＫは、コンテンツレイヤを受信／回復することができない個々のクライアントがそのようにしたとき、そのグループについて送信される。再送信の要求の場合、再送信されることが必要とされる大部分のパケットをもつ個々のクライアントは要求を行う。すなわち、上述された全ての場合、大部分の必要／最悪の条件をもつ個々のクライアントは、それぞれのコンテンツレイヤに応答するクライアントのグループにおけるクライアントである。これは、フィードバック抑制を使用することで、ＡＣＫが激増する問題に対処する。

帯域幅又は遅延の制約が与えられると、本発明は、最上位の重要度をもつデータから開始して最下位の重要度をもつデータへの、現在のソースレイヤの正しい伝達を保証するために残りのリソースを割り当てる。マルチメディアデータのそれぞれ上手く伝達されたレイヤについて、ハイブリッドＡＲＱの使用のため、本発明は、損失の多いネットワークについて広い帯域幅の効率を維持することができる。あるタイムスロットに属する全てのマルチメディアデータがクライアントに伝達される前に所与のリソースが使い尽くされた場合、本発明は、ソースビットストリームのスケーラビリティの特性を利用することで、最小のパフォーマンスのロスを保証する。したがって、本発明は、ネットワークの損失の多い状態に従って柔軟なビットレートの適応を提供することができ、クライアントで改善されたマルチメディアの再生の品質を提供することができる。

図１は、本発明がユニキャストで動作する環境の概要を示す図である。サーバ１０５は、損失が多いネットワーク１１０を通してクライアント／ユーザ装置への送信のためにコンテンツをスケジュールする。図３に示されるサーバ１０５は、コンテンツサーバとネットワークサーバである２つのサーバを含む。ネットワークは、送信されたコンテンツのユーザ装置／クライアント１１５ａ，１１５ｂにより受信、又は符号化されたコンテンツの現在のレイヤを回復するために十分なパケット（コンテンツ及びＦＥＣ）のユーザ装置による受信をサーバ１０５に通知するため、フィードバックチャネルを提供する。

図２Ａ及び図２Ｂは、本発明のパケットスケジューラの動作に関するフローチャートである。本発明の実施の形態では、パケットは、複数のクライアント／ユーザ装置／受信機にユニキャストで送信／発送される。ステップ２０５で、（図３に示される）パケットスケジューラは、（図３に示される）コンテンツサーバからのレイヤード符号化パケット（コンテンツ及びＦＥＣ）を受信する。パケットスケジューラは、ステップ２１０で、（図３に示される）ネットワークサーバからフィードバックチャネルを通してクライアント／ユーザ装置からのフィードバックを受信する。次いで、パケットスケジューラは、ステップ２１５で、タイムスロットのインデックスを初期化する。ステップ２２０で、パケットスケジューラは、符号化されたデータレイヤのインデックスを初期化する。ステップ２２５でテストが実行され、このタイムスロットについてリソースが使い尽くされているかが判定される。すなわち、このタイムスロットのビットバジェット又はパケットデリバリのデッドラインが期限切れしているかに関する判定が行われる。リソースが使い尽くされている場合、ステップ２６０で、タイムスロットのインデックスがインクリメントされる。ステップ２３０でリソースが使い尽くされていない場合、パケットスケジューラは、現在の符号化データレイヤに属する次のコンテンツパケットを送信／発送することをネットワークサーバに指示／スケジュールする。ステップ２３５で、テストが実行され、現在のレイヤに属している全てのコンテンツパケットが送信／発送されたかが判定される。現在のレイヤに属する全てのコンテンツパケットが発送されていない場合、プロセスはステップ２２５に進む。現在のレイヤに属する全てのコンテンツパケットが発送／送出されている場合、ステップ２４０でテストが実行され、ＡＣＫがクライアントから受信されたかが判定される。ＡＣＫがクライアントから受信された場合、ステップ２６５でテストが実行され、現在のレイヤのインデックスが最上位レイヤのインデックスであるかが判定される。現在のレイヤが最上位レイヤでない場合、プロセスはステップ２５５に進み、パケットスケジューラは、符号化データレイヤのインデックスをインクリメントする。次いで、プロセスは、ステップ２２５に進む。現在のレイヤのインデックスが最も高いレイヤのインデックスである場合、ステップ２６０でタイムスロットがインクリメントされる。ＡＣＫがクライアントから受信されていない場合、次いで、ステップ２４５でテストが実行され、このタイムスロットについてリソースが使い尽くされているかが判定される。すなわち、タイムスロットのビットバジェット又はパケットデリバリのデッドラインが期限切れしているかに関する判定が行われる。リソースが使い尽くされている場合、ステップ２６０で、タイムスロットのインデックスがインクリメントされる。リソースが使い尽くされていない場合、次いでステップ２５０で、パケットスケジューラは、ＦＥＣパケットを送信／発送することをネットワークサーバに指示／スケジュールする。

図３は、本発明の原理に係るサーバのブロック図である。図１に示されるサーバ１０５は、コンテンツサーバ３０５ａ及びネットワークサーバ３０５ｂとして実現される。コンテンツサーバ３０５ａは、パケットスケジューラモジュール３１０にソース情報を供給するのと同様に、ネットワークサーバ３０５ｂにレイヤード符号化ビデオビットストリームを供給する役割を果たす。パケットスケジューラモジュールは、コンテンツサーバからレイヤード符号化パケットを受信し、ネットワークサーバ３０５ｂを介してユーザ装置／クライアントからのフィードバックを受信する。パケットスケジューラモジュール３１０は、図２Ａ及び図２Ｂを参照して上述されるように、パケットスケジューリング情報をネットワークサーバ３０５ｂに送出する。パケットスケジューラモジュール３１０は、ハードウェア又はソフトウェア或いはその組み合わせにおいて実現することができる。ネットワークサーバ３０５ｂは、ダウンリンクチャネル３２０を通して損失の多いネットワーク３１５にパケット（コンテンツ及びＦＥＣ）を送出する。損失の多いネットワークは、クライアント／ユーザ装置３４０にダウンリンクチャネル３３０を通してパケット（コンテンツ及びＦＥＣ）を送信する。本明細書で使用されるように、及びマルチキャスト環境で特に使用されるように、クライアント／ユーザ装置３４０は、多数のクラスのクライアント／受信機／ユーザ装置である。損失の多いネットワーク３１５は、フィードバックチャネル３３５を通してクライアント／受信機／ユーザ装置からフィードバックを受信し、このフィードバックを、損失の多いネットワーク３１５は、フィードバックチャネル３２５を通してネットワークサーバ３０５ｂに送出する。図３は、１つのクライアント／ユーザ装置／受信機を示す。現実の実務では、多数のクライアントが存在することが想定される。しかし、図３のポイントは、本発明の実施の形態は複数のクライアントへのユニキャストであることである。なお、パケットスケジューラの機能は、図示されるようにそのままモジュール（ソフトウェア又はハードウェア）にあるか、この機能は、コンテンツサーバ３０５ａとネットワークサーバ３０５ｂとの間で分割することができるか、或いは、全ての３つのユニット（コンテンツサーバ３０５ａ、ネットワークサーバ３０５及びパケットスケジューラ３１０）が１つの装置に結合される場合がある。

図４は、符号化を実行するＨ．２６４メインプロファイルを使用した例示的な時間スケーラビリティ符号化構造である。Ｈ．２６４は、幾つかの可能な符号化スキームのうちの１つである。図４におけるピクチャのセットは、「グループオブピクチャ」又はＧＯＰと呼ばれ、ベースレイヤ（ＢＬ）とエンハンスメントレイヤ（ＥＬ）に分割される。図４は、時間方向において３つのＥＬを示す。ＢＬは、ＩＤＲ（instantaneous decoder refresh）及びＰ／Ｂタイプのスライスを含む。ＥＬは、Ｂｓ及びＢとそれぞれ示される参照及び非参照のＢタイプのスライスを含む。図４における矢印は、符号化の間の参照の依存度を示す。参照の依存度は、階層的な動き予測構造を形成する。図４から、ＢＬが独立してデコード可能であり、ＥＬ−ｎが正しい復号化のためにＢＬ又はＥＬ−ｍ（この場合ｍ＜ｎ）に依存する必要があることが分かる。さらに、予測の依存度のため、ＥＬ−ｍから欠けているピクチャは、ＥＬ−ｎのような上位のレイヤからのピクチャにのみ影響を及ぼす。しかし、ＢＬからの失われたピクチャは、次のＩＤＲが受信されるまで後続のピクチャの全てに影響を及ぼす可能性がある。結果的に、係る符号化構造では、ＢＬは、ＢＬは一般に最も重要であり（したがって、最も低いインデックスを有するレイヤ）、減少する重要度のためにＥＬ−１、ＥＬ−２及びＥＬ−３が続く。係る符号化構造は、レイヤードコンテンツ構造を満足する。レイヤードハイブリッドＡＲＱは、他のコンテンツ符号化スケーラビリティの特徴と機能することを特に述べておく。

図５は、本発明がマルチキャストで動作する環境の概要を示す図である。サーバ１０５及び損失の多いネットワーク１１０は、図１を参照して上述されたようなものである。マルチキャストグループ１ ５０５は、それらチャネル状態に基づいてマルチキャストのグループ１に参加しているクライアント／ユーザ装置／受信機のクラスであり、この場合、チャネル状態は、ソースからの距離の関数である。マルチキャストグループ２ ５１０は、それらのチャネル状態に基づいてマルチキャストのグループ２に参加しているクライアント／ユーザ装置／受信機の別のクラスである。この環境において更なるマルチキャストのグループが存在する場合がある。

図６は、本発明の原理に従うパケットスケジューラのブロック図である。本発明のこの実施の形態では、パケットスケジューラは、ユニキャストからマルチキャストへの本発明の原理の拡張の記載に従って、個々のクライアントとは対照的に、クライアントのグループのスケジュールを実行する。３０５ａ、３０５ｂ、３１０〜３３５は、図３を参照して上述されたとおりである。マルチキャストクライアントグループ６０５ａ、６０５ｂ及び６０５ｃは、それぞれ１つのクライアント又は複数のクライアントを有することができる。

なお、本発明は、ハードウェア、ソフトウェア、ファームウェア、特定用途向けプロセッサ又はその組み合わせで実現される。好ましくは、本発明は、ハードウェアとソフトウェアの組み合わせとして実現される。さらに、ソフトウェアは、プログラムストレージ装置に実現されるアプリケーションプログラムとして実現されることが好ましい。アプリケーションプログラムは、適切なアーキテクチャを有するコンピュータにアップロードされ、コンピュータにより実行される場合がある。好ましくは、コンピュータは、１以上の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、及び入力／出力（Ｉ／Ｏ）インタフェースのようなハードウェアを有するコンピュータプラットフォームで実現される。また、コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含む。本明細書で記載される様々な処理及び機能は、オペレーティングシステムを介して実行される、マイクロ命令コードの一部又はアプリケーションプログラムの一部（或いはその組み合わせ）である場合がある。さらに、様々な他の周辺装置は、更なるデータストレージ装置及びプリンティング装置のようなコンピュータプラットフォームに接続される。

添付図面に示されるシステム構成要素又は方法のステップの幾つかはソフトウェアで実現されるのが好ましいため、システムコンポーネント（又はプロセスステップ）間の実際の接続は、本発明がプログラムされるやり方に依存して異なる場合がある。本明細書の教示が与えられた場合、当業者であれば、本発明のこれらの実現又はコンフィギュレーション、或いは類似の実現又はコンフィギュレーションを考えることができるであろう。

Claims (18)

1. あるレイヤに関連するコンテンツの符号化されたパケットを受信するステップと、
   チャネル状態に関するフィードバック情報を受信するステップと、
   前記フィードバック情報に基づいて前記パケットを伝達するためにハイブリッドＡＲＱ（automatic repeat request）を適用するステップと、
   を含む方法。
2. 前記ハイブリッドＡＲＱをレイヤ毎に適用するステップは、
   あるリソースが使い尽くされたかを判定するステップと、
   前記リソースが使い尽くされていない場合、あるレイヤのレイヤード符号化コンテンツパケットの伝達をスケジュールするステップと、
   前記レイヤの全てのレイヤード符号化コンテンツパケットが送信されたかを判定するステップと、
   前記レイヤの全てのレイヤード符号化パケットが送信されていない場合、前記最初の判定ステップに進むステップと、
   確認メッセージがユーザ装置から受信されたかを判定するステップと、
   確認メッセージが受信されていない場合、前記リソースが使い尽くされたかを判定するステップと、
   前記リソースが使い尽くされていない場合、レイヤード符号化順方向誤り訂正パケットの伝達をスケジュールするステップと、
   を更に含む請求項１記載の方法。
3. タイムスロットのインデックスを初期化するステップと、
   レイヤのインデックスを初期化するステップと、
   を更に含む請求項２記載の方法。
4. 前記レイヤのインデックスが最上位のレイヤのインデックスである場合、前記タイムスロットのインデックスをインクリメントするステップと、
   前記レイヤのインデックスを再初期化するステップと、
   を更に含む請求項３記載の方法。
5. 前記レイヤインデックスが最上位のレイヤのインデックスでない場合、前記レイヤのインデックスをインクリメントするステップを更に含む、
   請求項３記載の方法。
6. 前記リソースは帯域制限されている、
   請求項２記載の方法。
7. 前記リソースは、送信時間である、
   請求項２記載の方法。
8. 前記レイヤード符号化パケットは、スケーラブルコーダにより生成される、
   請求項２記載の方法。
9. 前記レイヤード符号化パケットは、前記レイヤのインデックスにより示されるパケットの重要度の順序で伝達のためにスケジュールされ、
   前記レイヤのインデックスは、重要度の減少する順序で増加する、
   請求項２記載の方法。
10. あるレイヤに関連するコンテンツの符号化されたパケットを受信する手段と、
    チャネル状態に関するフィードバック情報を受信する手段と、
    前記フィードバック情報に基づいて前記パケットを伝達するためにハイブリッドＡＲＱ（automatic repeat request）を適用する手段と、
    を含む装置。
11. 前記ハイブリッドＡＲＱをレイヤ毎に適用する手段は、
    あるリソースが使い尽くされたかを判定する手段と、
    前記リソースが使い尽くされていない場合、あるレイヤのレイヤード符号化コンテンツパケットの伝達をスケジュールする手段と、
    前記レイヤの全てのレイヤード符号化コンテンツパケットが送信されたかを判定する手段と、
    前記レイヤの全てのレイヤード符号化パケットが送信されていない場合、前記最初の判定手段による処理に進む手段と、
    確認メッセージがユーザ装置から受信されたかを判定する手段と、
    確認メッセージが受信されていない場合、前記リソースが使い尽くされたかを判定する手段と、
    前記リソースが使い尽くされていない場合、レイヤード符号化順方向誤り訂正パケットの伝達をスケジュールする手段と、
    を更に含む請求項１０記載の装置。
12. タイムスロットのインデックスを初期化する手段と、
    レイヤのインデックスを初期化する手段と、
    を更に含む請求項１１記載の装置。
13. 前記レイヤのインデックスが最上位のレイヤのインデックスである場合、前記タイムスロットのインデックスをインクリメントする手段と、
    前記レイヤのインデックスを再初期化する手段と、
    を更に含む請求項１２記載の装置。
14. 前記レイヤインデックスが最上位のレイヤのインデックスでない場合、前記レイヤのインデックスをインクリメントする手段を更に含む、
    請求項１２記載の装置。
15. 前記リソースは帯域制限されている、
    請求項１１記載の装置。
16. 前記リソースは、送信時間である、
    請求項１１記載の装置。
17. 前記レイヤード符号化パケットは、スケーラブルコーダにより生成される、
    請求項１１記載の装置。
18. 前記レイヤード符号化パケットは、前記レイヤのインデックスにより示されるパケットの重要度の順序で伝達のためにスケジュールされ、
    前記レイヤのインデックスは、重要度の減少する順序で増加する、
    請求項１１記載の装置。

Images