(57)【要約】  要求に応じてネットワークを介してコンテンツの一部分を配信するように構成された少なくとも１つのサーバノードと、少なくとも１つのクライアントノードとの間において使用するためのコンテンツ配信システムに使用するように適合されたネットワークノードであって、前記ネットワークノードは、前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている、複数のバージョンのうちの１つのコンテンツの一部分を求める要求を受信し、その受信を受けて、要求されているバージョンの前記コンテンツの部分を送信することが可能であるか否かを決定し、可能である場合、前記コンテンツの部分を要求して前記サーバノードから受信し、前記クライアントノードに前記コンテンツの部分を送信し、可能でない場合、要求されているバージョンの前記コンテンツの部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている、ネットワークノード。
2016526355.tif 000002
【特許請求の範囲】
【請求項１】
要求に応じてネットワークを介してコンテンツの一部分を配信するように構成された少なくとも１つのサーバノード（３０）と、少なくとも１つのクライアントノード（１０）との間において使用するためのコンテンツ配信システムに使用するように適合されたネットワークノード（２０）であって、前記ネットワークノードは、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行される、複数のバージョンのうちの１つのコンテンツの一部分を求める要求（４０）を受信し、（ｉｖ）その受信を受けて、要求されているバージョンの前記コンテンツの部分を送信することが可能であるか否かを決定し、（ｖ）可能である場合、前記コンテンツの部分を要求して前記サーバノードから受信し、前記クライアントノードに前記コンテンツの部分（５０）を送信し、（ｖｉ）可能でない場合、要求されているバージョンの前記コンテンツの部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている、ネットワークノード。
【請求項２】
前記ネットワークノードが、複数の符号化レイヤにおいてコンテンツの１つまたは複数の部分を提供するように構成されているサーバノードと、特定の符号化レイヤにおいてコンテンツの１つまたは複数の部分を求める要求を発行するように構成されているクライアントノードとの間において使用するようにさらに適合されており、前記ネットワークノードが、前記決定するステップが特定の要求されている符号化レイヤを考慮に入れるように構成されている、請求項１に記載のネットワークノード。
【請求項３】
前記ネットワークノードが、コンテンツの一部分を送信することが可能であるか否かを決定するときに、前記ネットワークノードによって複数の前記少なくとも１つのクライアントノードから受信された、所定の時間期間内の要求の量を考慮に入れるようにさらに構成されている、請求項１または２に記載のネットワークノード。
【請求項４】
前記ステップ（ｉｉｉ）、（ｉｖ）、（ｖ）および（ｖｉ）が、所定の符号化レイヤセット内で利用可能にされているコンテンツ部分に対してのみ適用され、一方で、他の符号化レイヤ内で利用可能な同じコンテンツ部分について、要求が前記サーバノードに転送され、前記ネットワークノードが前記サーバノードから前記コンテンツ部分を受信し、前記コンテンツ部分を前記クライアントノードに送信する、請求項１、２または３のいずれか一項に記載のネットワークノード。
【請求項５】
コンテンツ配信システムであって、（１）要求されているバージョンにおいて要求に応じてネットワークを介して、１つまたは複数のバージョンのコンテンツの一部分を配信するように構成された少なくとも１つのサーバノード（３０）と、
（２）（ｉ）ネットワークを介して利用可能なコンテンツビデオデータの一部分を受信し、（ｉｉ）複数のバージョンのうちの１つのコンテンツの一部分を求める要求（４０）を発行するように構成された少なくとも１つのクライアントノード（１０）と、
（３）前記少なくとも１つのサーバノードと、前記少なくとも１つのクライアントノードとの間にあるネットワークノード（２０）であって、ネットワークノードは、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている、要求されているバージョンのコンテンツの一部分を求める要求（４０）を受信し、（ｉｖ）要求されているバージョンの前記コンテンツの部分を送信することが可能であるか否かを決定し、（ｖ）可能である場合、要求されているバージョンにおいて前記コンテンツの部分を要求して前記サーバノードから受信し、要求されているバージョンにおいて前記クライアントノードに前記コンテンツの部分（５０）を送信し、（ｖｉ）可能でない場合、要求されているバージョンの前記コンテンツの部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている、ネットワークノード（２０）と
を備える、コンテンツ配信システム。
【請求項６】
前記サーバノードが、複数の符号化レイヤ内に前記コンテンツ部分の各々を提供するように構成されており、前記クライアントノードが、前記要求に特定の符号化レイヤを関連付けるように構成されており、前記ネットワークノードは、前記決定するステップにおいて、特定の関連付けられた符号化レイヤを考慮に入れるように構成されている、請求項５に記載のネットワーク。
【請求項７】
前記ネットワークノードが、コンテンツの一部分を送信することが可能であるか否かを決定するときに、複数の前記少なくとも１つのクライアントノードから受信された、所定の時間期間内の要求の量を考慮に入れるようにさらに構成されている、請求項５または６に記載のネットワーク。
【請求項８】
（ａ）前記ネットワークノードから受信された前記情報に基づいて前記クライアントノードが、次のコンテンツ部分の要求を進め、または、（ｂ）前記ネットワークノードから受信された前記情報に基づいて前記クライアントノードが、同じコンテンツ部分を求めるものであるが、任意選択的に、関連付けられた符号化レイヤが以前の要求よりも要求が少ない新たな要求の発行を進め、または、（ｃ）前記ネットワークノードから受信された前記情報に基づいて前記クライアントノードが、（ｉ）次のコンテンツ部分の要求を進め、もしくは、（ｉｉ）同じコンテンツ部分を求めるものであるが、任意選択的に、関連付けられた符号化レイヤが以前の要求よりも要求が少ない新たな要求の発行を進めるかを決めることができる、請求項５から７のいずれか一項に記載のネットワーク。
【請求項９】
（ｉ）要求に応じて１つまたは複数のバージョンのコンテンツの一部分を配信するように構成されたネットワークを介して利用可能なコンテンツの一部分（５０）を受信し、（ｉｉ）要求されているバージョンのコンテンツの一部分を求める要求（４０）を発行するためのコンテンツ配信システムに使用するように適合されたクライアントノード（１０）であって、少なくとも１つのクライアントノードと少なくとも前記サーバノードとの間に使用するように適合された少なくとも１つのネットワークノード（２０）の情報を受信するのにさらに構成されており、前記情報は、前記ネットワークノードが、前記要求されているバージョンの前記要求されているビデオデータ部分を送信することが可能でないと決定したことを示す、クライアントノード（１０）。
【請求項１０】
前記コンテンツ部分の各々が、複数の符号化レイヤにおいて利用可能であり、前記ノードが、該ノードが要求するコンテンツ部分の特定の符号化レイヤを、前記要求と関連付けるようにさらに構成されている、請求項９に記載のノード。
【請求項１１】
前記ノードが、前記ネットワークノードから受信された前記情報に基づいて次のコンテンツ部分の要求を進めるように構成されている、請求項９または１０に記載のノード。
【請求項１２】
前記ノードが、前記ネットワークノードから受信された前記情報に基づいて、同じコンテンツ部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない、新たな要求の発行を進めるように構成されている、請求項９または１０に記載のノード。
【請求項１３】
コンテンツ配信システムに使用するための、要求に応じてネットワークを介しては１つまたは複数のバージョンのコンテンツの一部分を配信するように構成された少なくとも１つのサーバノード（３０）と、（ｉ）ネットワークを介して利用可能なコンテンツの一部分（５０）を受信し、（ｉｉ）要求されているバージョンのコンテンツの一部分を求める要求（４０）を発行するように構成された少なくとも１つのクライアントノード（１０）との間に使用するように適合された、ネットワークノード（２０）を動作させるための方法であって、方法は、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている、要求されているバージョンのコンテンツの部分を求める要求（４０）を受信するステップ（６０）と、（ｉｖ）その受信を受けて、前記要求されているバージョンの前記コンテンツ部分を送信することが可能であるか否かを決定するステップ（７０）と、（ｖ）可能である場合、前記要求されているバージョンの前記コンテンツ部分を要求して前記サーバノードから受信し、前記クライアントノードに前記要求されているバージョンの前記コンテンツ部分（５０）を送信するステップ（８０）と、（ｖｉ）可能でない場合、前記要求されているバージョンの前記コンテンツ部分を送信することが可能でないことを前記クライアントノードに通知するステップ（９０）とを含む、方法。
【請求項１４】
請求項１から４のステップ（ｉ）から（ｖｉ）および／もしくは請求項９から１２のステップ（ｉ）から（ｉｉ）のいずれかを実行し、ならびに／または請求項１３の方法を実行するために、処理エンジン上で動作可能な、コンピュータプログラム製品。
【請求項１５】
請求項１４のコンピュータプログラム製品を記憶している、一時的でない機械可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＡＳコンテンツ配信システムの分野に関し、特に、そのクライアントに対する公平性を改善することに関する。
【背景技術】
【０００２】
ＩＰ（インターネットプロトコル）ベースのネットワークを介してビデオを配信するための方法が、ＨＡＳ（ＨＴＴＰ（ハイパーテキスト転送プロトコル）適応型ストリーミング）である。この方法には容易に配備可能であるという利点があり、これは、（ｉ）ＵＤＰ／ＲＴＰ（ユーザデータグラムプロトコル／リアルタイム転送プロトコル）ベースのビデオ配信よりも容易にファイアウォールおよびＮＡＴ（ネットワークアドレス変換器）を越え、（ｉｉ）ＴＣＰ（伝送制御プロトコル）に依拠し、利用可能なＨＴＴＰインフラストラクチャ、特にＨＴＴＰキャッシュおよびＣＤＮ（コンテンツ配信ネットワーク）ノードを利用することができるため、本質的に輻輳を制御することができるためである。
【０００３】
説明したシステムは、ＲＴＴおよびビデオの複雑度に関係なく各クライアントに等しい品質を提供しないという点において不公平である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】欧州特許出願公開番号第２４０８２０５号明細書
【特許文献２】米国特許出願公開第２０１２／１５５２５８号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の実施形態の目的は、上述したようなコンテンツ配信システムにおける不公平性を解決することである。
【課題を解決するための手段】
【０００６】
本発明の第１の態様によれば、要求に応じてネットワーク内でコンテンツの一部分を配信するように構成された少なくとも１つのサーバノードと、（ｉ）サーバノードまたは任意の他の中間ノードのような、ネットワーク内の任意のノードにおいてネットワーク内で利用可能なコンテンツの一部分を受信し、（ｉｉ）コンテンツの一部分（好ましくは複数のバージョンのうちの１つ）を求める要求を発行するように構成された少なくとも１つのクライアントノードとの間において使用するための（ストリーミング）（マルチメディア）コンテンツ（ビデオおよび／またはオーディオなど）配信システム（ネットワークを介する）に使用するように適合された、（電子）ネットワークノード、デバイスまたはシステムが提供される。前記ネットワークノードは、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている（前記複数のバージョンのうちの１つの）コンテンツの一部分を求める要求を受信し、（ｉｖ）その受信を受けて（要求されているバージョンの）前記コンテンツの部分を送信することが可能であるか否かを決定し、（ｖ）可能である場合、前記コンテンツの部分を要求して前記サーバノードから受信し、前記クライアントノードに前記コンテンツの部分を送信し、（ｖｉ）可能でない場合、（要求されているバージョンの）前記コンテンツの部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている。
【０００７】
本発明の一実施形態において、クライアントノード、サーバノードおよび中間ネットワークノードは様々なネットワークアーキテクチャにおいて接続されてもよいが、ネットワークノードは、ボトルネックノードとしての役割を果たし、またその役割を果たすことが可能であり、それゆえ、ネットワークノードは前記少なくとも１つのクライアントにとってネットワークを介してコンテンツの受信に対するボトルネックであり、前記ネットワークノードは前記クライアントに対する輻輳を軽減する。
【０００８】
本発明の一実施形態において、ネットワークノードは、（ネットワーク上で動作可能な伝送プロコトルに関係している）所定の時間枠内での要求への応答を予測して通信プロトコル上で（クライアントおよび／またはサーバノードと）通信するために使用するように構成されている。
【０００９】
本発明の一実施形態において、ネットワークノードは、部分ごとに（コンテンツの可能な品質の表示を選択することに関係した）適切なバージョンの選択をサポートし（ビデオのセグメントごとに示され、それによって、そのようなセグメントの各バージョンがチャンクになる）、それによって、いわゆる適応型ストリーミングをサポートするように構成されているネットワーク内で動作可能である。
【００１０】
本発明の一実施形態において、ネットワークノードは、前記コンテンツをパケット化フォーマット（ＩＰ）で受信および送信するように構成されている。
【００１１】
記載されている実施形態の１つまたは複数は、組み合わされることができ、好ましくは、ネットワークノードは、コンテンツ（ビデオおよび／またはオーディオなど）を配信するために、ハイパーテキスト転送プロトコル適応型ストリーミングを使用してインターネットプロトコルベースのネットワーク内で動作するように構成されている。
【００１２】
好ましい実施形態において、ネットワークノードは、複数の符号化レイヤにおいてコンテンツ（ビデオ）の１つまたは複数の部分を提供するように構成されているサーバノードと、特定の符号化レイヤにおいてコンテンツ（ビデオ）の１つまたは複数の部分を求める要求を発行するように構成されているクライアントノードとの間において使用するようにさらに適合されており、前記ネットワークノードは、前記決定するステップが特定の要求されている符号化レイヤを考慮に入れるように構成されている。
【００１３】
別の好ましい実施形態において、前記ネットワークノードは、前記ネットワークノードによって（複数の）前記少なくとも１つのクライアントノードから受信された、所定の期間中の要求の量を考慮に入れるようにさらに構成されており、好ましくは、この所定の期間は、以前の時間期間に関係し（それゆえ、その期間のそのような瞬時量は、その来たる時間期間のための予測値を有すると仮定される）、任意選択的にまた、実際の期間（測定されるものとしての）中に前記ネットワークノードによって前記少なくとも１つのクライアントノードから受信された要求の瞬時量は、コンテンツ（ビデオ）の一部分を送信することが可能であるか否かを決定するときに、さらに考慮に入れられる。現在および／または過去（ここでも１つまたは複数）の任意の組合せが、たとえば、重み付け手順において使用され得る。
【００１４】
別の好ましい実施形態において、前記ネットワークノードは、前記ステップ（ｉｉｉ）、（ｉｖ）、（ｖ）および（ｖｉ）が、前記の複数のクライアントの間の（全体的な）公平性を改善するように選択されるように構成されている。
【００１５】
別の好ましい実施形態において、前記ネットワークノードは、前記ステップ（ｉｉｉ）、（ｉｖ）、（ｖ）および（ｖｉ）が、所定の符号化レイヤセット内で利用可能にされているコンテンツ（ビデオ）部分に対してのみ適用され、一方で、他の符号化レイヤ内で利用可能な同じコンテンツ（ビデオ）部分に対する要求は前記サーバノードに転送され、前記ネットワークノードが前記サーバノードから前記コンテンツ（ビデオ）部分を受信し、前記コンテンツ（ビデオ）部分を前記クライアントノードに送信するように構成されている。
【００１６】
本発明の第２の態様は、（ストリーミング）（マルチメディア）コンテンツ（ビデオおよび／またはオーディオなど）配信システム（ネットワークを介する）を提供することであり、当該システムは：（１）要求に応じて（要求されているバージョンにおいて）ネットワークを介して（好ましくは１つまたは複数のバージョンの）コンテンツの一部分を配信するように構成された少なくとも１つのサーバノードと、（２）（ｉ）サーバノードまたは任意の他の中間ノードにおいて、ネットワークを介して利用可能なコンテンツの一部分を受信し、（ｉｉ）コンテンツの一部分（複数のバージョンのうちの１つ）を求める要求を発行するように構成された少なくとも１つのクライアントノードと、（３）前記少なくとも１つのサーバノードと前記少なくとも１つのクライアントノードとの間にあるネットワークノード（ボトルネックノード）であって、ネットワークノードは、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている要求されているバージョンのコンテンツの一部分を求める要求を受信し、（ｉｖ）（要求されているバージョンの）前記コンテンツ部分を送信することが可能であるか否かを決定し、（ｖ）可能である場合、（要求されているバージョンの）前記コンテンツ部分を要求して前記サーバノードから受信し、前記ネットワークノードに（要求されているバージョンの）前記コンテンツの部分を送信し、（ｖｉ）可能でない場合、（要求されているバージョンの）前記コンテンツ部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている、ネットワークノードとを備える。
【００１７】
本発明の一実施形態において、クライアントノード、サーバノードおよび中間ネットワークノードは様々なネットワークアーキテクチャにおいて接続されてもよいが、ネットワークノードは、ボトルネックノードとしての役割を果たし、またその役割を果たすことが可能であり、それゆえ、ネットワークノードは前記少なくとも１つのクライアントにとってネットワークを介してコンテンツの受信に対するボトルネックであり、前記ネットワークノードは前記クライアントに対する輻輳を軽減する。
【００１８】
本発明の一実施形態において、前記ノードは、（ネットワーク上で動作可能な伝送プロコトルに関係している）所定の時間枠内での要求への応答を予測して通信プロトコル上で互いに通信し合うために使用するように構成されている。
【００１９】
本発明の一実施形態において、前記ノードは、部分ごとに（コンテンツの可能な品質の表示を選択することに関係した）適切なバージョンの選択をサポートし（ビデオのセグメント（それによって、チャンクがそのバージョンになる）ごとに示される）、それによって、いわゆる適応型ストリーミングをサポートするように構成されている。
【００２０】
本発明の一実施形態において、前記ノードは、前記コンテンツをパケット化フォーマット（ＩＰ）で受信および送信するように構成されている。
【００２１】
記載されている実施形態の１つまたは複数は、組み合わされることができ、好ましくは、前記ノードは、コンテンツ（ビデオおよび／またはオーディオなど）を配信するために、ハイパーテキスト転送プロトコル適応型ストリーミングを使用してインターネットプロトコルベースのネットワーク内で動作するように構成されている。
【００２２】
より好ましい実施形態において、前記サーバノードは、複数の符号化レイヤ内に前記コンテンツ部分の各々を提供するように構成されており、前記クライアントノードは、前記要求に特定の符号化レイヤを関連付けるように構成されており、前記ネットワークノードは、前記決定するステップにおいて、特定の関連付けられた符号化レイヤを考慮に入れるように構成されている。
【００２３】
別のより好ましい実施形態において、前記ネットワークノードは、コンテンツの一部分を送信することが可能であるか否かを決定するときに、前記少なくとも１つのクライアントノードから受信された要求の瞬時量、もしくはやはり、前記少なくとも１つのクライアントノードから受信された要求の以前の瞬時量、または、重み付けされたそれらの組合せを考慮に入れるようにさらに構成されている。
【００２４】
例示的な実施形態において、前記サーバノード（複数可）には、前記複数の符号化レイヤ内の前記部分の各々を配信することが可能である、ビデオエンコーダ、好ましくは、スケーラブルビデオエンコーダが設けられている。
【００２５】
別の好ましい実施形態において、前記ネットワークノードは、前記ステップ（ｉｉｉ）、（ｉｖ）、（ｖ）および（ｖｉ）が、前記の複数のクライアントの間の（全体的な）公平性を改善するように選択されるように構成されている。
【００２６】
別の好ましい実施形態において、前記ネットワークノードは、前記ステップ（ｉｉｉ）、（ｉｖ）、（ｖ）および（ｖｉ）が、所定の符号化レイヤセット内で利用可能にされているコンテンツ（ビデオ）部分に対してのみ適用され、一方で、他の符号化レイヤ内で利用可能な同じコンテンツ（ビデオ）部分について、要求は前記サーバノードに転送され、前記ネットワークノードが前記サーバノードから前記コンテンツ（ビデオ）部分を受信し、前記コンテンツ（ビデオ）部分を前記クライアントノードに送信するように構成されている。
【００２７】
そのさらなる好ましい実施形態において、前記所定の符号化レイヤセットは、（他の符号化レイヤの部分である）ベースレイヤを除き、すべてのレイヤが前記スケーラブルビデオエンコーダによって提供される。
【００２８】
別の好ましい実施形態において、前記クライアントノードは、前記ネットワークノードから受信された前記情報に基づいて、次のコンテンツ（ビデオ）部分の要求を進める。
【００２９】
また別の好ましい実施形態（たとえば、ＡＶＣクライアント）において、前記クライアントノードは、前記ネットワークノードから受信された前記情報に基づいて、同じコンテンツ（ビデオ）部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない新たな要求の発行を進める。
【００３０】
代替的な好ましい実施形態（たとえば、Ｈ２６４  ＡＶＣまたはＭＰＥＧ４パート１０  ＡＶＣクライアントのようなアドバンスドビデオコーデック（ＡＶＣ））において、前記クライアントノードは、前記ネットワークノードから受信された前記情報に基づいて、（ｉ）次のコンテンツ（ビデオ）部分の要求を進めるか、または、（ｉｉ）同じコンテンツ（ビデオ）部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない新たな要求の発行を進めるかを決定してもよく、任意選択的に（ｉ）または（ｉｉ）の決定は、（ネットワークノードについて受信されたメッセージがそのような情報を与える限り）それ自体のプレイアウトバッファを測定し、および／または、他のクライアント要求を考慮に入れるよう試行することによって行われる。
【００３１】
代替的な好ましい実施形態（たとえば、Ｈ２６４  ＳＶＣまたはＭＰＥＧ４パート１０  ＳＶＣクライアントのようなスケーラブルビデオコーデック（ＳＶＣ））において、前記クライアントノードは、前記ネットワークノードから受信された前記情報に基づいて、（ｉ）次のコンテンツ（ビデオ）部分の要求を進めるか、または、（ｉｉ）同じコンテンツ（ビデオ）部分を求める新しい要求の発行を進めるかを決定してもよく、任意選択的に（ｉ）または（ｉｉ）の決定は、（ネットワークノードについて受信されたメッセージがそのような情報を与える限り）それ自体のプレイアウトバッファを測定し、および／または、他のクライアント要求を考慮に入れるよう試行することによって行われる。
【００３２】
本発明の第３の態様によれば、（電子）クライアントノードを提供するために、（ｉ）要求に応じて（好ましくは１つまたは複数のバージョンの）コンテンツの一部分を配信するように構成されたサーバノードまたは中間ノードにおいてネットワークを介して利用可能なコンテンツの一部分を受信し、（ｉｉ）（要求されているバージョンの）コンテンツの一部分を求める要求を発行するための（ストリーミング）（マルチメディア）コンテンツ（ビデオなど、および／または）配信システム（ネットワークを介する）で使用するように適合されたデバイスまたはシステムが、少なくとも１つのクライアントノードと少なくとも前記サーバノードとの間に使用するように適合された少なくとも１つのネットワークノードの情報を受信するようにさらに構成されており、前記情報は、前記ネットワークノードが、（前記要求されているバージョンの）前記要求されているビデオデータ部分を送信することが可能でないと決定したことを示す。
【００３３】
本発明の一実施形態によれば、クライアントノードは、前記コンテンツ（ビデオ）を表示することが可能である（それゆえ、ユーザにサービスする実際のクライアントである）。
【００３４】
本発明の代替的な実施形態において、クライアントノードは、前記コンテンツ（ビデオ）を表示することが可能である（それゆえ、ユーザにサービスする実際のクライアントであるが、第１のノードよりも低い計算および記憶容量を有し得る）さらなるノードに（固有に）関連付けられることができ、それによって、第１のノードは、前記さらなるノードを（たとえば、その挙動をエミュレートすることによって）表すことが可能である。
【００３５】
好ましい実施形態において、前記コンテンツ（ビデオ）部分の１つまたは複数は、複数の符号化レイヤにおいて、サーバノードまたは均等物もしくは中間ノードにおいて利用可能であり、前記クライアントノードは、当該クライアントノードが要求するコンテンツ（ビデオ）部分の特定の符号化レイヤを、前記要求と関連付けるように構成されている。
【００３６】
また別の好ましい実施形態において、前記ノードは、前記ネットワークノードから受信された前記情報に基づいて次のコンテンツ（ビデオ）部分の要求を進めるように構成されている。
【００３７】
代替的な好ましい実施形態において、前記ノードは、前記ネットワークノードから受信された前記情報に基づいて、同じコンテンツ（ビデオ）部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない、新たな要求の発行を進めるように構成されている。
【００３８】
また別の代替的な好ましい実施形態において、前記ノードは、前記ネットワークノードから受信された前記情報に基づいて、（ｉ）次のコンテンツ（ビデオ）部分の要求を進めるか、または、（ｉｉ）同じコンテンツ（ビデオ）部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない、新たな要求の発行を進めるかのいずれかを決定するように構成されている。
【００３９】
記載されている実施形態または好ましい実施形態のいずれか１つを、（それら自体組み合わされることができる）以下の実施形態と組み合わされることができる。
【００４０】
一実施形態において、クライアントノードは、（ネットワーク上で動作可能な伝送プロコトルに関係している）所定の時間枠内での要求への応答を予測して通信プロトコル上で他のノードと通信するために使用するように構成されている。
【００４１】
一実施形態において、クライアントノードは、部分ごとに（コンテンツの可能な品質の表示を選択することに関係した）適切なバージョンの選択をサポートし（ビデオのチャンクごとに示される）、それによって、いわゆる適応型ストリーミングをサポートするように構成されている。
【００４２】
本発明の一実施形態において、前記クライアントノードは、前記コンテンツをパケット化フォーマット（ＩＰ）で受信および送信するように構成されている。
【００４３】
記載されている実施形態の１つまたは複数は、組み合わされることができ、好ましくは、前記ノードは、コンテンツ（ビデオおよび／またはオーディオなど）を配信するために、ハイパーテキスト転送プロトコル適応型ストリーミングを使用してインターネットプロトコルベースのネットワーク内で動作するように構成されている。
【００４４】
本発明の第４の態様は、（ストリーミング）（マルチメディア）コンテンツ（ビデオおよび／またはオーディオなど）配信システム（ネットワークを介する）に使用するための、要求に応じてネットワークを介して（好ましくは１つまたは複数のバージョンの）コンテンツの一部分を配信するように構成された少なくとも１つのサーバノードと、（ｉ）サーバノードまたは任意の他の中間ノードのような、ネットワーク内の任意のノードにおいて、ネットワークを介して利用可能なコンテンツの一部分を受信し、（ｉｉ）（要求されているバージョンの）コンテンツの一部分を求める要求を発行するように構成された少なくとも１つのクライアントノードとの間に使用するように適合された、（電子）ネットワークノード、デバイスまたはシステム（ボトルネックノード）を動作させるための方法を提供することであり、当該方法は、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている（要求されているバージョンの）コンテンツの部分を求める要求を受信するステップと、（ｉｖ）その受信を受けて、（前記要求されているバージョンの）前記コンテンツ部分を送信することが可能であるか否かを決定するステップと、（ｖ）可能である場合、（前記要求されているバージョンの）前記コンテンツ部分を要求して前記サーバノードから受信し、前記クライアントノードに（前記要求されているバージョンの）前記コンテンツ部分を送信するステップと、（ｖｉ）可能でない場合、（前記要求されているバージョンの）前記コンテンツ部分を送信することが可能でないことを前記クライアントノードに通知するステップとを含む。
【００４５】
本発明の第５の態様は、前述したステップのいずれかを実行し）および／または以前の態様の方法を実行するために、（電子）処理エンジン（前述した前記ノードのいずれかの部分）上で動作可能なコンピュータプログラム製品を提供することである。
【００４６】
本発明の第６の態様において、第５の態様のコンピュータプログラム製品を記憶している一時的でない機械可読記憶媒体が提供される。
【００４７】
ノード、ネットワーク、方法、コンピュータプログラム製品および記憶媒体を別個の態様として上述したが、これは明瞭にする目的でのみ行われており、１つの態様とのみ関連して記載されている特徴は、同じ技術的効果および利点を得るために、本発明による他の態様に適用されてもよく、逆もあってもよいことが留意されるべきである。
【００４８】
本発明の実施形態によるシステム、ノードもしくはデバイスおよび／または方法のいくつかの実施形態を、ここで例としてのみ、添付の図面を参照して説明する。
【図面の簡単な説明】
【００４９】
【図１】（従来技術）本発明のネットワーク実施形態が配備され得る、スケーラブルビデオ符号化の使用を可能にする標準を使用した、クライアントノード、ネットワークまたはボトルネックノードおよびサーバノードを有するネットワークを示す図である。
【図２】（従来技術）やはりスケーラブルビデオ符号化の使用を可能にする標準を使用しているが、本発明の実施形態が意図されているものとは異なるネットワーク（非ＨＡＳ）上にある、クライアントノード、ネットワークまたはボトルネックノードおよびサーバノードを有するネットワークを示す図である。
【図３】本発明のネットワーク実施形態が配備され得る、スケーラブルビデオ符号化の使用を可能にする標準を使用した、クライアントノード、ネットワークまたはボトルネックノードおよびサーバノードを有するネットワークを示す図である。
【図４】本発明の実施形態を使用する効果、特に、ビデオ公平性の改善を示す図である。
【図５】ネットワークノードまたはプロキシの動作を示す図である。
【図６】ネットワークノードにおける方法のステップおよびネットワークノードならびにクライアントおよびサーバノード間の相互作用を示す図である。
【発明を実施するための形態】
【００５０】
ＨＡＳの設計原理は以下のとおりである（図１参照）。ビデオは異なるビットレートで符号化され、クライアントは、指定される瞬間においてこれらのビットレートバージョンの間で切り替わることができる。ビデオがいかに符号化されるかは、ビデオデータがダウンロードされる前にビデオクライアントに転送される（また、後に更新される場合がある）マニフェストファイルに記述されている。２つの連続する、可能性のある切り替え時間の間のビデオの間隔は、ビデオセグメントとして示され、その間隔を有する関連付けられたビットストリング（利用可能な品質バージョンあたり１つのビットストリング）がチャンクとして示される。それゆえ、品質バージョンと同じだけの数の、各ビデオセグメントと関連付けられているチャンクが多く存在する。既存の実施態様（たとえば、Ａｐｐｌｅ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ、Ｓｉｌｖｅｒｌｉｇｈｔ  Ｓｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ、Ａｄｏｂｅ  Ｄｙｎａｍｉｃ  Ｓｔｒｅａｍｉｎｇ）において、チャンクは１つまたは複数のＴＣＰ（伝送制御プロトコル）接続を介して進行する連続したＨＴＴＰ  ＧＥＴ（取得）要求を介してダウンロードされる。どのチャンクを次のビデオセグメントのためにダウンロードすべきかを選択するために、クライアントは、（１）以前に見たチャンクのダウンロードを調べて利用可能なネットワークスループット、特に、ＴＣＰによって提供されるスループットをモニタリングし、（２）（次のチャンクの）ビデオビットレートを、この利用可能なネットワークスループットと一致させることを試みる。要求されるビデオビットレートは、利用可能なネットワークビットレートと正確に一致することができないため、クライアントはプレイアウトバッファを維持することを必要とする。
【００５１】
説明されているシステムは、以下の意味で不公平である。ＴＣＰが提供するスループットは、クライアントが経験するＲＴＴ（往復時間）に依存する。大きいＲＴＴを有するクライアントは、より低いスループット、それゆえ、より低い品質のビデオを経験する。その上、いくつかのビデオ（一般的に多くの詳細および一貫していない動きを有する）は、同じ品質に達成するために他のビデオよりも高いビットレートを必要とする。理想的なビデオ配信システムは、ＲＴＴおよびビデオの複雑度とは無関係に、各クライアントに等しい品質を提供し、すべてのビデオに提供され得る品質は、ネットワークの輻輳状態に依存する。
【００５２】
本発明の実施形態の１つが、当該技術分野において知られているようなＳＶＣを使用するＨＡＳクライアントについて実証され、たとえば、ＳＶＣベースのクライアントに対するフックが、ＤＡＳＨ（ＨＴＴＰを介した動的適応型ストリーミング）規格において予期されている。「ＥＰ２４０８２０５（Ａ１）−Ａ  ｖｉｄｅｏ  ｓｅｒｖｅｒ，  ｖｉｄｅｏ  ｃｌｉｅｎｔ  ａｎｄ  ｍｅｔｈｏｄ  ｏｆ  ｓｃａｌａｂｌｅ  ｅｎｃｏｄｉｎｇ  ｖｉｄｅｏ  ｆｉｌｅｓ」が、そのようなクライアントを記載している。そのようなＳＶＣベースのクライアントは、従来のクライアントよりも多用途である。従来のクライアントは、どの（品質バージョンの）チャンクを次のビデオセグメントのためにダウンロードすべきかについて行う決定において慎重であるべきである。決定が積極的すぎる場合、、ビデオバッファを過度な枯渇の危険にさらしてしまう（そして最終的に、ビデオフリーズがもたらされるおそれがある）。決定が保守的すぎる場合（より高い品質のチャンクをダウンロードできたかもしれないという意味で）、この決定を取り消すことは困難である、すなわち、より低い品質のチャンクの転送が無駄にされるため、より高い品質バージョンのチャンクを求めることは非効率的である。対照的に、ＳＶＣベースのクライアントは、ＨＴＴＰ  ＧＥＴ要求が満たされるときはいつでも、以下の２つの決定のうちの１つを行うことができる：次のビデオセグメントのためのベースレイヤチャンクのダウンロードに進むか、または、現在のビデオセグメントのための次のエンハンスメントレイヤチャンクのダウンロードを決定するかのいずれかであり得る。クライアントはこのように徐々に品質を増大させることができるため、クライアントが行う決定は、決して無駄になる情報を転送する結果にはならない。しかしながら、ＳＶＣベースのクライアントは依然として積極的すぎる場合があり、それ自体のプレイアウトバッファを枯渇させる危険性があるか、または、他のクライアントによって達成される品質を過度に妨害する。ここに、本発明の実施形態が解決策をもたらす。
【００５３】
同様の問題が関連する分野において解決されているが、これらの解決策はＨＡＳに直接適用され得ない：
１）ビデオレート整形（「統計的多重化」とも称する）。限られた数のビデオシーケンスが一定のビットレートのチャネル上で多重化される必要があるとき（たとえば、ケーブルまたは衛星チャネルを介した「ライブ」ビデオプログラムのデジタル転送において）、これらのビデオの符号化プロセスは２つのステップから構成される。第１のステップにおいて（第２のステップの数秒前に作動する）、各ビデオシーケンスの複雑度が決定される。各ビデオのこの複雑度は、ビットレートに応じて到達し得る質として表現される、すなわち各ビデオの時間的レート−歪み曲線が評価される。これらのレート−歪み曲線は、第２のステップ（すなわち、実際の符号化ステップ）において使用され、各ビデオシーケンスが（より多くのまたはより少ない）同じ品質を達成するように、利用可能なビットが多重化されるべきすべてのビデオシーケンスにわたって分散される。様々な符号化の供給元が、このような解決策を提供している。この種類のシステムは、同じリンクを共有するすべてのクライアントに対するフィードバックを必要とするため、この解決策は、ＨＡＳまで拡張され得ない。ＨＡＳにおいて、これらのエンティティのいずれも（符号化器も、いずれのネットワークノードも）、すべてのクライアントのこの知識を有していない。
２）チョーキングベースの輻輳制御。ＵＤＰ／ＲＴＰを介して転送されるビデオについて、解決策は、「米国特許出願公開第２０１２１５５２５８号（Ａ１）−Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ」に記載されている。本件特許に記載されているシステム（図２に示す）は、２つの基礎的要素から構成されている。第１に、各ビデオはＳＶＣ（スケーラブルビデオ符号化）を使用してレイヤ内で符号化される。すなわち、符号化されたビデオフローは、ベースレイヤおよび多くのエンハンスメントレイヤから構成され、これらすべてがクライアントに向けてネットワークへと送信される。ベースレイヤは、最低のビデオ品質に対応する。クライアントが追加のエンハンスメントレイヤにアクセスするとき、品質は１の増分だけ増大され得る。第２に、アクティブなネットワークノードが、（その輻輳状態に応じて）どのレイヤをサポートすることができるのかを決定し、一時的にサポートすることができないレイヤのパケットを捨てる。そのように、クライアントは、輻輳状態に応じて等しい品質を得る。パケットが捨てられる結果として、ＴＣＰがそれらのパケットを再送信することになり、ＴＣＰスループット劣化することになるという有害な副作用があり、これによってシステム全体の性能が低減するため、この解決策は、ＨＡＳには使用され得ない。
【００５４】
ＨＡＳの関連において、いくつかの技法が提案されているが、それらは問題を完全に解決していない：
３）マニフェストファイル書き換え。そのようなシステムにおいて、プロキシがマニフェストファイルをインターセプトし、クライアントに中継する前にいくつかのエントリを削除する。そのように、クライアントは、特定の品質バージョンに気付かず、それゆえ、これらを要求しない。マニフェストファイルはビデオ配信中更新できるが、この技法は、輻輳に十分に速く反応するのに必要とされる粒度を有しない。
４）ネットワークにおける優先順位付けを用いるＳＶＣベースのクライアント。「ＥＰ２４０８２０５（Ａ１）−Ａ  ｖｉｄｅｏ  ｓｅｒｖｅｒ，  ｖｉｄｅｏ  ｃｌｉｅｎｔ  ａｎｄ  ｍｅｔｈｏｄ  ｏｆ  ｓｃａｌａｂｌｅ  ｅｎｃｏｄｉｎｇ  ｖｉｄｅｏ  ｆｉｌｅｓ」において、ＳＶＣに基づくＨＡＳクライアントのための方法が記載されている。ベースレイヤは、ネットワーク内で優先処理を受けるビットパイプを介して転送され、一方で、エンハンスメントレイヤは、より低い優先順位を受けるビットパイプを介して転送される。結果として、ベースレイヤチャンクは常に時間内に宛先に達し、一方で、エンハンスメントレイヤチャンクは遅延される可能性があり、それゆえ、輻輳があるとき、クライアントは、あまり後者をダウンロードしない傾向にされる。この発明は、より劣悪な条件にあるクライアント（たとえば、高いＲＴＴを有する）が、良好な条件にあるクライアントよりも動作が低下するため、本明細書において対処される公平性問題を解決しない。
【００５５】
本発明の実施形態は、特殊化されたノード、そのようなノード上で実行される方法、そのようなノード、および、そうでなければクライアント間に不公平性をもたらす場合がある、コンテンツ配信システムに使用するための関係付けられたソフトウェア（およびその記憶媒体）を有するネットワークを提案する。特に、クライアントとサーバとの間のネットワークは、無線リンク（たとえば、ＩＥＥＥ  ８０２．１１  ＷＬＡＮリンク、ＵＭＴＳ、３Ｇ、ＬＴＥなどのようなモバイルリンク）および／または有線リンク（たとえば、ＩＥＥＥ  ８０２．３「Ｅｔｈｅｒｎｅｔ（登録商標）」リンク、ＰＬＣリンク、ｘＤＳＬリンク、同軸リンクなど）を含んでもよい。
【００５６】
ここで、本発明の実施形態が、ＨＡＳおよびビデオコンテンツ配信の関連において実証されるが、それには限定されない。
【００５７】
基礎となるネットワークは、ＩＰ（インターネットプロトコル）ベースのネットワークのような、パケット化データベースのネットワークである。ＨＡＳ（ＨＴＴＰ（ハイパーテキスト転送プロトコル）適応型ストリーミング）。この方法は、ＴＣＰ（伝送制御プロトコル）およびＨＴＴＰインフラストラクチャに依拠する。ビデオは異なるビットレートで符号化され、クライアントは、指定される瞬間においてこれらのビットレートバージョンの間で切り替わることができる。一般的に、チャンク（特定のビットレートに従って符号化されているビデオセグメント）は、１つまたは複数のＴＣＰ（伝送制御プロトコル）接続を介して進行する連続したＨＴＴＰ  ＧＥＴ要求を介してダウンロードされる。
【００５８】
提案されているノードの構成または特殊化および関連する方法は、ＴＣＰによって提供される輻輳制御を適合させる（オーバーライドする）ことによって実装され、その２つの他の利点のためにＨＴＴＰのみを使用することができる：１）容易にファイアウォールおよびＮＡＴを越えることを可能にすること、２）配備されているＨＴＴＰインフラストラクチャを使用することができるようにすること。明らかに、本発明はこれに限定されるものではない。まったく他のタイプの輻輳制御および／または要求処理メカニズムを有するネットワークも使用されてもよい。
【００５９】
本発明の一態様（図３に示されているような）は、プロキシ（ボトルネックノード）に、それがサービスするクライアントによって発行されている（すべての）ＨＴＴＰ  ＧＥＴ要求を検査させることである。クライアントが求めているチャンクがその輻輳状態に対応していないとこのプロキシがみなす場合、プロキシは、要求されているチャンクが一時的に利用不可能であることを示すＨＴＴＰ応答メッセージ（たとえば、「４ｘｘ  ｍｅｓｓａｇｅ（メッセージ）」、たとえば、「４０３  Ｆｏｒｂｉｄｄｅｎ（禁止）」または「４０５  Ｍｅｔｈｏｄ  Ｎｏｔ  Ａｌｌｏｗｅｄ（無効なメソッド）」）をクライアントに送信する。そうでなければ、ＨＴＴＰ  ＧＥＴ要求をサーバ（またはキャッシュ）に中継する。図４は、これによってビデオ配信システムの挙動がいかに変わるかを示す。
【００６０】
したがって、基本的に、（１）要求されているバージョンにおいて要求に応じてネットワークを介して、１つまたは複数のバージョン（ビットレート）（それによってチャンクを定義する）のコンテンツ（ビデオ）の一部分（セグメント）を配信するように構成された少なくとも１つのサーバノードと、（２）（ｉ）ネットワークを介して利用可能なコンテンツビデオデータの一部分を受信し、（ｉｉ）複数のバージョンのうちの１つにおける、コンテンツの一部分を求めるＨＴＴＰ  ＧＥＴ要求を発行するように構成された少なくとも１つのクライアントノードと、それゆえ、指定される瞬間においてこれらのビットレートバージョンの間で切り替わる機能を有し、（３）前記少なくとも１つのサーバノードと前記少なくとも１つのクライアントノードとの間にあるネットワークノードまたはプロキシであって、ネットワークノードは、（ｉｉｉ）前記少なくとも１つのクライアントノードのうちのクライアントノードによって発行されている要求されているバージョンのコンテンツの一部分を求める要求を受信し、（ｉｖ）要求されているバージョンの前記コンテンツ部分を送信することが可能であるか否かを決定し、（ｖ）可能である場合、前記サーバノードから要求されているバージョンの前記コンテンツ部分を要求および受信し、前記ネットワークノードに要求されているバージョンの前記コンテンツの部分を送信し、（ｖｉ）可能でない場合、ＨＴＴＰ応答メッセージを送信することによって、要求されているバージョンの前記コンテンツ部分を送信することが可能でないことを前記クライアントノードに通知するように構成されている、コンテンツ配信システムが提供される。
【００６１】
ＳＶＣのようなレイヤードコーデック（好ましくはベースレイヤチャンクを求める要求が常に許可される）に基づく好ましい実施形態において、クライアントは、次のビデオセグメントのベースレイヤチャンクのダウンロードを進めるために、この「４ｘｘ  ｍｅｓｓａｇｅ」を合図として利用する。
【００６２】
図１は、スケーラブルビデオ符号化の使用を可能にする標準を使用した、クライアントノード（１０）、ネットワークまたはボトルネックノード（２０）およびサーバノード（３０）を有するネットワークを示す。本発明の実施形態は、そのようなネットワーク上に配備され得る。この図は、クライアントおよびサーバのビットレートならびにネットワークノードのスループットを示す。ＤＡＳＨクライアントは、利用可能なスループットを推定し、プレイアウトバッファが増大し（バッファリングモードにおいて）、安定した状態において過度には変化しないような数の（符号化）レイヤ（他のレイヤのうちの１つ）をダウンロードする。ネットワークノードは、このプロセスにおいて積極的な役目を有しない。サーバは、階層レイヤ内でビデオセグメントを利用可能にし、クライアントからの要求を待つ。ビデオ品質（使用されているレイヤを表すグラフ内の異なる陰影によって反映されている）は、（ＲＴＴ、損失などに応じて決まる）ＴＣＰスループットに応じて決まることは明らかである。基本的に、この結果として、いくつかのクライアント間で不公平性がもたらされる。図２は、やはりスケーラブルビデオ符号化の使用を可能にする標準を使用しているが、特に、この図ではボトルネックノードがパケットを捨てる場合があるため、本発明の実施形態が配備され得るものとは異なるネットワーク（非ＨＡＳ）上にある、クライアントノード（１０）、ネットワークまたはボトルネックノード（２０）およびサーバノード（３０）を有するネットワークを示す。この図では、クライアントは、このプロセスにおいて積極的な役割を有しない。ボトルネックノードは、経験する輻輳に応じてレイヤ（のパケット）を廃棄する。すべてのビデオが同じように影響を受ける。サーバは、ネットワーク内の階層レイヤにおいてビデオストリームを送信する。本発明の実施形態は、別のタイプのネットワークについてこれを達成することを望むため、ビデオ品質はすべてのユーザにとって同じであり、それゆえ、同様の公平性を確立する。図３は、スケーラブルビデオ符号化の使用を可能にする標準を使用した、クライアントノード（１０）、ネットワークまたはボトルネックノード（２０）およびサーバノード（３０）を有するネットワークを示す。本発明の実施形態は、そのようなネットワーク上に配備され得る。ＤＡＳＨクライアントは、図１におけるように機能するが、いくつかのＨＴＴＰ  ＧＥＴ要求が許可されないことを知る。ボトルネックノードまたはネットワークプロキシは、ＨＴＴＰ  ＧＥＴ要求メッセージを検査する。輻輳がひどい場合、ボトルネックノードは、最高レイヤに対するＨＴＴＰ  ＧＥＴ要求をブロックし、４ｘｘ  ＨＴＴＰ応答メッセージをクライアントに送信する。サーバは、階層レイヤ内でビデオセグメントを利用可能にし、クライアントからの要求（サーバがネットワークノードを介して取得するか、またはそうでなければ要求はブロックされている）を待つ。ネットワークノードは、このプロセスにおいて積極的な役目を有する。
【００６３】
非スケーラブルコーデックに基づく別の実施形態において、クライアントは、現在のビデオセグメントのためのより低い品質のチャンクを求める要求を発行するために、この「４ｘｘメッセージ」を合図として利用する必要がある。
【００６４】
レイヤードコーデック（たとえば、ＳＶＣ）に基づく好ましい実施形態が、ここでより詳細に説明される。
【００６５】
さらにより好ましい実施形態において、本発明は、ＳＶＣを使用するＨＡＳクライアントによって使用される。ＳＶＣベースのクライアントは、ＨＴＴＰ  ＧＥＴ要求が満たされるときはいつでも、以下の２つの決定のうちの１つを行うことができる：次のビデオセグメントのためのベースレイヤチャンクのダウンロードに進むか、または、現在のビデオセグメントのための次のエンハンスメントレイヤチャンクのダウンロードを決定するかのいずれかであり得る。クライアントはこのように徐々に品質を増大させることができるため、クライアントが行う決定は、決して無駄になる情報を転送する結果にはならない。しかしながら、ＳＶＣベースのクライアントは依然として積極的すぎる場合があり、それ自体のプレイアウトバッファを枯渇させる危険性があるか、または、他のクライアントによって達成される品質を過度に妨害する。本明細書において説明されている本発明の実施形態によれば、ＳＶＣベースのクライアントは、過度に積極的になることに関して迷う必要はない：プロキシは、すべてのクライアントの要求およびネットワークの輻輳レベルをより良好に展望し、ネットワークがサポートすることができないエンハンスメントレイヤに対する要求を拒絶することができる。ＳＶＣベースのクライアントに必要とされる変更は、「４ｘｘメッセージ」を正確に解釈することが必要になることだけである。「４ｘｘメッセージ」を正確に解釈することが、既存のＳＶＣベースのクライアントに必要とされる最小限の変更である。極端な場合において、ＳＶＣベースのクライアントは、プロキシに完全に依拠し得る：クライアントは、「４ｘｘメッセージ」を得るまで、現在のビデオセグメントのより多くのエンハンスメントレイヤチャンクを漸進的にダウンロードするよう試行することができ、この場合には次のビデオセグメントのベースレイヤチャンクの要求に進む。ＳＶＣクライアントがこれよりもなお積極的である場合（たとえば、ビデオセグメントのためにすべてのエンハンスメントレイヤチャンクの要求を主張する場合）、より多くの「４ｘｘメッセージ」がプロキシによって送信される結果になるだけなので、結果は基本的に異ならない。ＳＶＣクライアントがあまり積極的でない場合、他のクライアントのためにより多くの転送容量が残るだけである。図４は、本発明の実施形態を使用する効果、特に、２つのクライアントの事例におけるビデオ公平性の改善を示す。左手側は、ＨＡＳネットワーク上での従来の実施態様を示し、一方で、右手側は、そのようなネットワーク上での本発明の実施形態の使用を示す。上側の図は、良好な条件における（たとえば、小さいＲＴＴを有する）クライアントのスループットを表し、一方で、下側の図は、不良な条件における（たとえば、大きいＲＴＴを有する）クライアントを表す。積極的にＨＴＴＰ  ＧＥＴ要求を廃棄し（一定の閾値Ｋを上回る符号化レイヤに対する要求について可能性がある）、クライアントに対する４ｘｘメッセージによって応答することによって、良好な条件にあるクライアントが、不良な条件にあるクライアントによって占められ得る資源を解放し、したがって、ビデオ公平性が改善することは明らかである。
【００６６】
基本的に、ＳＶＣクライアントノードは、前記ネットワークノードまたはプロキシから受信された前記ＨＴＴＰメッセージ情報に基づいて、（ｉ）次のコンテンツ部分の要求を進めるか、または、（ｉｉ）同じコンテンツ部分を求める新たな要求の発行を進めるかを決定することができる。
【００６７】
この実施形態の残りの部分について、プロキシがどのように機能するかを説明する例示的な実施形態が提供される。例示のために、各ビデオがＬ個のレイヤにおいて符号化されていると仮定される（が、本発明の実施形態は、異なるクライアントにわたって可変量のレイヤに対して動作可能である）。レイヤ１はベースレイヤであり、基本的な品質（コンテンツプロバイダが提供することを望む最小限の品質）に対応する。このベースレイヤ品質はすべてのビデオに対して同じであるように設計されているため、各ビデオのベースレイヤのビットレート（またはバイト単位のチャンクサイズ）は公称値から逸脱することができることに留意されたい。レイヤ２，３，．．．は、（階層的）エンハンスメントレイヤである。１つのエンハンスメントレイヤは、すべてのビデオに対して同じであるように設計されている品質増分をもたらし、それゆえ、エンハンスメントレイヤのビットレートも同様に、公称値付近で変動することができる。ｂｌを、プロキシの出力インターフェースのビットレートに対するレイヤｌの公称ビットレートとする。プロキシは以下の動作を実施する（図５参照）：
１）以下のように間隔［（ｉ−１）・Ｄ，ｉ・Ｄ［においてレイヤｌに対する要求Ｒｌ，ｉの平滑化された数を測定し、Ｄはビデオセグメントの一般的な持続時間である：
・間隔［（ｉ−１）・Ｄ，ｉ・Ｄ［におけるレイヤｌに対する要求の数Νｌ，ｉがカウントされる。
・これらの数は以下のように平滑化される：Ｒｌ，ｉ＝（１−ａ）・Ｒｌ，ｉ−１＋ａ・Νｌ，ｉ、式中、ａは間隔［０，１］において調整可能な値。
２）以下のように、間隔［ｉ・Ｄ，（ｉ＋１）・Ｄ［における（仮想的な）トラフィック負荷ｒｋ，ｉを予測する：ｒｋ，ｉ＝Σｌ＝１．．．ｋ（ｂｌ・Ｒｌ，ｉ）。
３）ｒＫ，ｉ≦１＜ｒＫ＋１，ｉである場合に、間隔［ｉ・Ｄ，（ｉ＋１）・Ｄ［において最大でレイヤＫまでのレイヤに対する要求を可能にする。
【００６８】
ステップ１−３を実施するための代替的な方法が想定され得るが、原理は同じままである：プロキシが、（間隔［（ｉ−１）・Ｄ，ｉ・Ｄ［における観測に基づいて）最大でレイヤｋまでのチャンクを求める要求を許可するとき、次の間隔［ｉ・Ｄ，（ｉ＋１）・Ｄ［において予期する負荷ｒｋ，ｉを決定し、次いでちょうど輻輳がなくなるように（すなわち、トラフィック負荷がただ１よりも小さくなるように）次の間隔［ｉ・Ｄ，（ｉ＋１）・Ｄ［にわたって実際にサポートすることになるレイヤの数を選択する。任意選択的に、値ｂｋをより正確に決定するために、プロキシは、（プロキシが予測した）ｒｋを、（やはりプロキシが容易に測定することができる）実際に観測されるトラフィック負荷と相関付けることができる。
【００６９】
図５は、スケーラブルビデオ符号化の使用を可能にする標準を使用した、クライアントノード（１０）、ネットワークまたはボトルネックノード（２０）およびサーバノード（３０）を有するネットワークを示す。本発明の実施形態は、そのようなネットワーク上に配備され得る。図５は、ネットワークノードまたはプロキシの動作を示す。プロキシは、レイヤを要求しているＨＴＴＰ  ＧＥＴメッセージ（４０）を確認する。上側のグラフにおいて、要求されている（符号化）レイヤを示す番号を有する矢印によって表されている要求を示す（１がベースレイヤであり、一方で他の数字はエンハンスメントレイヤである）。プロキシは前記ＨＴＴＰ  ＧＥＴメッセージに対して動作し、この結果として、プロキシが任意選択的にその出力インターフェースにおいて（その動作方法において使用するために）測定してもよい一定のトラフィック負荷（５０）が生じる。
【００７０】
一般的に言って、ネットワークノードは、コンテンツの一部分を送信することが可能であるか否かを決定するときに、前記ネットワークノードによって複数の前記少なくとも１つのクライアントノードから受信された要求の瞬時量、もしくは予測モードにおいて、前記ネットワークノードによって複数の前記少なくとも１つのクライアントノードから受信された要求の以前の瞬時量のいずれか、または、それらの両方を考慮に入れるように構成されている。
【００７１】
上述された好ましい実施形態は、ＳＶＣベースのクライアントを有するものであるが、システムはまた、非レイヤードコーデックに基づく従来のクライアントの変更されたバージョンによって機能してもよい。この事例において、従来のクライアントは、「４ｘｘメッセージ」を正確に解釈することが可能であるように変更されることのみを必要とする、すなわち、そのような「４ｘｘメッセージ」を受信した後、そのような（変更された）クライアントは、要求した情報を受信するまで、同じビデオセグメントに対するより低い品質のチャンク要求を再発行するべきである。そのようなクライアントに対するプロキシの動作は、ＡＶＣベースのクライントについて説明されたものと非常に類似している。そのような実施形態において、前記ネットワークノードから受信された前記ＨＴＴＰ応答メッセージ情報に基づく前記クライアントノードは、同じコンテンツ部分を求めるものであるが、関連付けられた符号化レイヤが以前の要求よりも要求が少ない新たなＨＴＴＰ要求の発行を進める。
【００７２】
結論として、本発明の実施形態はビデオレート整形（「統計的多重化とも称される）とは対照的に、集中的決定が行われず、レート−歪み曲線のような複雑な情報も交換されないという点で、非集中的に動作するネットワークに対して動作可能であることを述べることができる。本発明の実施形態において、サーバノードは変更されない。変更されるのはボトルネックノードのみであり、ボトルネックノードは、受信するまたは受信した（予測モード）（ＨＴＴＰ）要求の分析に基づいて、クライアントノードに（ＨＴＴＰ）メッセージを発行することが可能である。さらに、クライアントノードは、そのような（ＨＴＴＰ）メッセージを使用するように構成されている。さらに、ＴＣＰに違反して、一時的にサポートすることができないレイヤのパケットを捨てるために積極的なネットワークノードを使用するチョーキングベースの輻輳とは対照的に、本発明の解決策は、パケットが捨てられないため、ＨＡＳに使用するのに適合している。
【００７３】
本発明の実施形態は、マニフェストファイルに対して動作せず、ＳＶＣベースのクライアントのための事前の優先順位付けも提供しないＨＡＳに適合する解決策を提案し、対照的に、本発明の実施形態の技術的効果は、たとえクライアントが異なる条件において動作していたとしても、クライアントにわたる公平性を精密に改善することである。
【００７４】
図６は、ネットワークノード（２０）における方法のステップおよびネットワークノードならびにクライアント（１０）およびサーバノード（３０）間の相互作用を示し、より詳細には、クライアントからＨＴＴＰメッセージ（４０）を受信するステップ（６０）と、行われるべき動作を決定するステップ（７０）と、したがって、サーバから要求しクライアントに転送するステップ（８０）であってそれによってクライアントに対するトラフィックを生成するステップ（５０）、または、クライアントにＨＴＴＰ応答メッセージ（１００）を送信するステップ（９０）のいずれかとを示す。
【００７５】
それらのノードのいずれか１つの部分である処理エンジンの機能は、専用ハードウェア、および、適切なソフトウェアと関連してソフトウェアを実行することが可能なハードウェアを使用することによってもたらすことができる。プロセッサによってもたらされるとき、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、または、複数の個々のプロセッサによってもたらされてもよく、それらのうちのいくつかは共有されてもよい。その上、プロセッサという用語が明示的に使用されている場合、これは、ソフトウェアを実行することが可能なハードウェアを排他的に指すように解釈されるべきではなく、暗黙的に、限定ではなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を含んでもよい。従来のおよび／またはカスタムの他のハードウェアも含まれてもよい。様々な上述された方法のステップは、プログラムされたコンピュータによって実施され得ることを、当業者は容易に認識するであろう。本明細書において、いくつかの実施形態は、プログラム記憶デバイス、たとえば、機械またはコンピュータ読み出し可能であり、命令の機械実行可能またはコンピュータ実行可能プログラムを符号化するデジタルデータ記憶媒体を包含するようにも意図されており、前記命令は、前記上述された方法のいくつかまたはすべてを実施する。プログラム記憶デバイスは、たとえば、デジタルメモリ、磁気ディスクおよび磁気テープのような磁気記憶媒体、ハードドライブ、または、光学的に、読み出し可能デジタルデータ記憶媒体であってもよい。実施形態はまた、上述された方法の前記ステップを実施するようにプログラムされているコンピュータを包含するようにも意図されている。
【図１】
2016526355.tif 000003
【図２】
2016526355.tif 000004
【図３】
2016526355.tif 000005
【図４】
2016526355.tif 000006
【図５】
2016526355.tif 000007
【図６】
2016526355.tif 000008
【国際調査報告】
2016526355.tif 000009
2016526355.tif 000010
2016526355.tif 000011