(57)【特許請求の範囲】
【請求項１】
ビデオセッションのビデオセグメントをサーバから受信し、クライアント（１０３）にストリーミングすることができる適応ストリーミングアウェアネットワークノード（１０１）であって、前記ビデオセグメントは前記サーバから１つ又は複数の品質レベルで利用可能であり、各ビデオセグメントは前記クライアント（１０３）から受信された要求において指定された品質レベルで前記サーバから受信され、前記クライアント（１０３）に配信される適応ストリーミングアウェアネットワークノード（１０１）において、
前記ビデオセッションによって占有される前記クライアント（１０３）におけるバッファ量を示すバッファフィル情報を収集するためのセッション監視手段（１１１）と、
前記バッファフィル情報に応じて前記セッションのビデオセグメントのための優先順位レベルを判断するための優先順位計算手段（１１２）と、
前記セッションのビデオセグメントを前記優先順位レベルでマーキングするためのビデオセグメントマーキング手段（１１３）とを備えることを特徴とする、適応ストリーミングアウェアネットワークノード（１０１）。
【請求項２】
前記セッション監視手段（１１１）が、前記クライアント（１０３）から、前記ビデオセッションによって占有されるバッファ量が所定のしきい値未満に降下することを指示する専用メッセージ（１２１）を受信し、解釈するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項３】
前記セッション監視手段（１１１）が、前記クライアント（１０３）から、前記ビデオセッションによって占有される実際のバッファ量に関する情報を与える定期報告（１２１）を受信し、解釈するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項４】
前記セッション監視手段（１１１）が、前記適応ストリーミングアウェアネットワークノード（１０１）を通過するビデオセグメントに関するデータ（１２２、１２３）を取り込むように構成され、前記取り込まれたデータから、前記クライアント（１０３）におけるバッファフィルレベルを推定するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項５】
前記セッション監視手段（１１１）が、以下の情報、
ユーザ加入タイプを示す情報
ダウンロード品質を示す情報
ネットワーク負荷を示す情報
コンテンツ識別子を示す情報
コンテンツソースを示す情報、及び／又は
要求された品質に関する情報
のうちの１つ又は複数を収集するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項６】
前記優先順位計算手段（１１２）が、前記バッファ量が所定のしきい値未満に降下するときに、ＤＳＣＰ値を求めるように構成され、
前記ビデオセグメントマーキング手段（１１３）が、前記ＤＳＣＰ値を前記セッションに属するパケットのパケットヘッダに挿入するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項７】
前記優先順位計算手段（１１２）が、１つ又は複数のしきい値を前記バッファ量が超えるのに応じて、Ｌ−ＬＳＰを求めるか、又はＥＸＰビット値を求めるように構成され、
前記ビデオセグメントマーキング手段（１１３）が、前記Ｌ−ＬＳＰを構成するか、又は前記ＥＸＰビット値を前記セッションに属するパケットのＥ−ＬＳＰ  ＭＰＬＳヘッダに挿入するように構成される、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項８】
前記クライアント（１０３）からの将来の要求における品質レベルに影響を及ぼすように、前記クライアント（１０３）へのビデオセグメントの配信をスケジューリングするように構成されるスケジューリング手段（１１４）を更に備える、請求項１に記載の適応ストリーミングアウェアネットワークノード（１０１）。
【請求項９】
適応ストリーミングアウェアネットワークノード（１０１）においてクライアント（１０３）にサーバから受信したビデオセッションのビデオセグメントをストリーミングする方法であって、前記ビデオセグメントは前記サーバから１つ又は複数の品質レベルで利用可能であり、各ビデオセグメントは、前記クライアント（１０３）から受信された要求において指定された品質レベルで前記サーバから受信され、前記クライアント（１０３）に配信される方法において、
前記適応ストリーミングアウェアネットワークノード（１０１）において、前記ビデオセッションによって占有される前記クライアント（１０３）におけるバッファ量を示すバッファフィル情報を収集することと、
前記適応ストリーミングアウェアネットワークノード（１０１）において、前記バッファフィル情報に応じて前記セッションのビデオセグメントのための優先順位レベルを判断することと、
前記適応ストリーミングアウェアネットワークノード（１０１）において、前記セッションのビデオセグメントを前記優先順位レベルでマーキングすることとを含むことを特徴とする、方法。
【請求項１０】
ビデオセッションのビデオセグメントをサーバから適応ストリーミングアウェアネットワークノードを介して受信することができ、前記ビデオセグメントは前記サーバから１つ又は複数の品質レベルで利用可能であり、前記ビデオセグメントの配信のための品質レベルを前記サーバに要求において指定することができる適応ストリーミングアウェアクライアント（１０３）であって、
ビデオセグメントが優先順位レベルで前記適応ストリーミングアウェアネットワークノードによってマーキングされることを検出するように構成される優先順位検出手段を備えることを特徴とする、適応ストリーミングアウェアクライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般には、通常、数秒の長さを有し、異なる品質レベルで配信可能であるビデオセグメント、すなわち、ビデオストリームの固定サイズ又は可変サイズのフラグメントの適応ストリーミングに関する。これらのビデオフラグメントは、チャンク又はセグメントとも呼ばれる。本発明は、詳細には、適応ストリーミングを用いてビデオを配信する場合のバッファアンダーランのリスクを低減することを目的とする。
【背景技術】
【０００２】
例えば、ＨＴＴＰに基づく適応ストリーミング（ＨＡＳ）のような適応ストリーミング（ＡＳ）技法を用いるビデオ配信が次第に増えている。適応ストリーミングを用いるとき、ビデオアイテム、例えば、ファイル又はストリームが符号化され、異なる品質レベルで利用される。ビデオクライアントは、自らの測定に基づいて最も高い持続可能な品質レベルを推定し、この最も高い持続可能な品質レベルでビデオアイテムを要求する。例えば、ＨＴＴＰ適応ストリーミングの場合、各セグメントは、利用可能な品質レベルと、プレイアウトのために必要とされるセグメントとの観点からビデオアイテムを記述するマニフェストファイルとともに、ＨＴＴＰサーバを通して利用可能となる。ビデオクライアントは、ＨＴＴＰサーバからマニフェストファイルを要求することによって、プレイアウトを開始する。その後、ビデオクライアントは、セグメントごとにＨＴＴＰ−ＧＥＴ要求を送ることによって、ビデオセグメントをダウンロードし始める。所望の品質は、ＨＴＴＰ−ＧＥＴ要求においてセグメントごとに指定される。それに加えて、ビデオクライアントは、要求された各ビデオセグメントの品質レベルを自律的に決定するクライアントヒューリスティックを組み込む。クライアントヒューリスティックによる品質選択は、例えば、表示サイズ、サポートされるデコーダ、クライアントデバイスの処理能力、クライアントにおけるバッファのフィリングレベルなどの進行中セッションに関連する情報のような、クライアント端末仕様と、以前に受信されたビデオセグメントの転送レートを測定することによって推定された、典型的にはリンク帯域幅のような、ネットワーク条件のクライアント自らの推定値とに基づく。
【０００３】
ビデオクライアントは、要求された品質レベルを自律的に決定するので、各クライアントは自らの体験を最適化しようと試みることになる。ビデオサーバ及び中間要素はクライアントによって選択された品質レベルに関して何も制御しない。例えば、ネットワーク輻輳、又は品質レベル判断アルゴリズムによる準最適な決定の結果として、クライアント側においてバッファ枯渇又はバッファアンダーランが起こる場合があり、その結果、ビデオプレイアウトが中断されるか、又はユーザのビデオストリーム鑑賞が不快になる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、上記で確認された、バッファアンダーラン又はバッファ枯渇の問題を克服するか、又は緩和する適応ストリーミングアウェアシステム及び方法を開示することである。
【課題を解決するための手段】
【０００５】
本発明によれば、先に確定した目的は、ビデオセッションのビデオセグメントをクライアントにストリーミングすることができる、請求項１に記載の適応ストリーミングアウェアネットワークノードによって実現され、ビデオセグメントは１つ又は複数の品質レベルで利用可能であり、各ビデオセグメントはクライアントから受信された要求において指定された品質レベルでクライアントに配信され、適応ストリーミングアウェアネットワークノードは、
−  ビデオセッションによって占有されるクライアントのバッファ量を示すバッファフィル情報を収集するためのセッション監視手段と、
−  バッファフィル情報に応じてセッションのビデオセグメントのための優先順位レベルを判断する優先順位計算手段と、
−  セッションのビデオセグメント優先順位レベルでマーキングするためのビデオセグメントマーキング手段とを備える。
【０００６】
したがって、通常のビデオセグメントの処理とバッファ枯渇のリスクがあるクライアントによって要求されるセグメントの処理とを区別する可能性を提供しない既存のシステムとは異なり、本発明は、ネットワーク内に実装されるサービス品質（ＱｏＳ）機構を利用して、バッファ枯渇／アンダーランのリスクがあるクライアントによって要求されたビデオセグメントに対してネットワークにおいて更に良好な処理を提供するように、ビデオの適応ストリーミングをセッション監視及び優先順位設定と組み合わせる。より具体的には、本発明に従って動作する適応ストリーミングアウェアネットワークノードは、ビデオセッションによって占有されるクライアントにおけるバッファ空間量を監視し、その監視に基づいて、そのビデオセッションに属するビデオパケット又はセグメントのための優先順位を構成する。
【０００７】
請求項２に記載のオプションの態様によれば、本発明による適応ストリーミングアウェアネットワークノード内の前記セッション監視手段は、クライアントから、ビデオセッションによって占有されるバッファ量が所定のしきい値未満であることを指示する専用メッセージを受信し、解釈するように構成され得る。
【０００８】
したがって、バッファフィル情報を収集する１つの方法として、特定のビデオセッションのセグメントによって占有されるバッファ量がしきい値未満に降下するたびに、クライアントが専用メッセージを送信することに依拠することができる。そのような実装では、結果として、ネットワーク内のビデオパケットに対して、優先順位に基づくしきい値が設定されることになる。明らかに、複数の優先順位が利用可能である場合には、対応するセッションのバッファフィルレベルが異なる（減少する）しきい値未満に降下するときに、ネットワークがビデオセグメントの優先順位レベルを徐々に高めるように、複数のしきい値があらかじめ規定され得る。
【０００９】
代替的には、又は補足的には、請求３に記載されるように、本発明による適応ストリーミングアウェアネットワークノード内のセッション監視手段は、クライアントから、ビデオセッションによって占有される実際のバッファ量に関する情報の定期報告を受信し、解釈するように構成され得る。
【００１０】
したがって、特定のビデオセッションの場合にクライアントがバッファ枯渇に近いことを適時に検出するために、クライアントは、進行中の適応ストリーミングセッション中にバッファフィルレベルに関して定期的に報告することができる。そのような定期報告は、ネットワーク内のシグナリングを増やすことになるが、優先順位を構成する適応ストリーミングアウェアネットワークノードが、バッファ枯渇／アンダーランについて適時に推定し、予想できるようにする。定期報告は、バッファフィルレベルがしきい値未満に降下する場合の専用メッセージ伝送と組み合わせられる場合も、組み合わせられない場合もある。
【００１１】
代替的には、又は補足的には、請求項４に記載されるように、本発明による適応ストリーミングアウェアネットワークノード内のセッション監視手段は、適応ストリーミングアウェアノードを通過するビデオセグメント上のデータを取り込むように構成され、取り込まれたデータから、クライアントにおけるバッファフィルレベルを推定するように構成され得る。
【００１２】
それゆえ、バッファフィルレベルと、バッファ枯渇／アンダーランのリスクとに関する知識を得る更に別の方法は、ノードを通過するトラフィックを監視することに依拠することができる。特定のセッションの場合にノードを通過するビデオセグメントの数を数えるか、又はレートを計算することによって、そのノードはクライアントにおけるバッファフィルレベルを推定し、そこから、そのセッションに属するビデオセグメントを更に処理するための優先順位を導出することができる。そのようなトラフィック監視は、特にネットワーク輻輳の状況において遅れて到着する場合があるクライアントからのメッセージ伝送に依拠しないという利点を有する。ローカルトラフィック監視に基づく推定が不正確である場合に、バッファ枯渇／アンダーランのリスクを更に低減するために、そのような監視がクライアントからの定期的又は専用メッセージ伝送と組み合わせられる場合があることも当業者は理解されよう。
【００１３】
オプションで、請求項５に記載されるように、本発明による適応ストリーミングアウェアノード内のセッション監視手段は、以下の情報：
−  ユーザ加入タイプを示す情報；
−  ダウンロード品質を示す情報；
−  ネットワーク負荷を示す情報；
−  コンテンツ識別子を示す情報；
−  コンテンツソースを示す情報；及び／又は
−  要求された品質に関する情報；
のうちの１つ又は複数を収集するように更に構成され得る。
【００１４】
実際には、特定のビデオセッションのビデオセグメントの優先順位レベルを構成するために、クライアント側におけるバッファフィルレベルに加えて、他の情報も考慮に入れられ得る。例えば、加入タイプに関する情報は、特定のユーザに配信されるビデオセッションのセグメントが優先されなければならないか否か、及び特定のユーザに配信されるビデオセッションのセグメントがいつ優先されるかを判断するのに役に立つ場合がある。要求された品質レベル、又はダウンロードされた品質レベルに関する情報は、バッファフィルレベルが特定のしきい値未満に降下すると直ちに、バッファ枯渇／アンダーランを回避するのに要求される優先順位レベルを判断するのを支援することができる。同様に、実際のネットワーク負荷、及びクライアントに関する利用可能な容量の知識は、バッファ枯渇／アンダーランのリスクがあるクライアントに送信されるビデオセグメントの優先順位レベルを判断するときに考慮に入れられ得る。更に、ビデオセッション内のコンテンツの識別及び／又はコンテンツソースの識別は、クライアントにおけるバッファ枯渇／アンダーランを回避するために、本発明によるノードが優先順位レベルを判断し、その結果として、そのセッションのビデオセグメントを更に良好に処理するためにネットワークに課せられる労力を判断するのを助けることができる。バッファ枯渇／アンダーランのリスクがあるクライアントに対する適応ストリーミングセッションにおいてビデオパケット／セグメントの優先順位レベルを設定するために考慮に入れられ得る上記の情報リストは包括的でないことは当業者には理解されよう。
【００１５】
請求項６に記載される、本発明の第１の可能な実施態様では、
−  優先順位計算手段は、バッファ量が所定のしきい値未満に降下するとき、ＤＳＣＰ（差別化サービスコードポイント）値を求めるように構成され、
−  ビデオセグメントマーキング手段は、ＤＳＣＰ値をそのセッションに属するパケットのパケットヘッダに挿入するように構成される。
【００１６】
このようにして、本発明は、ビデオパケットを優先順位でマーキングするための既存のＤｉｆｆＳｅｒｖ技術を用いて実現され得る。
【００１７】
代替的には、又は補足的には、図７に記載されるように、
−  優先順位計算手段は、１つ又は複数のしきい値をバッファ量が超えるのに応じて、Ｌ−ＬＳＰ（Ｌａｂｅｌ−ｏｎｌｙ−ｉｎｆｅｒｒｅｄ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ）を求めるか、又はＥＸＰ（Ｅｘｐｅｒｉｍｅｎｔａｌ）ビット値を求めるように構成され得る。そして、
−  ビデオセグメントマーキング手段は、Ｌ−ＬＳＰを構成するか、又はＥＸＰビット値をそのセッションに属するパケットのＥ−ＬＳＰ（Ｅｘｐｅｒｉｍｅｎｔａｌ−ｂｉｔ−ｉｎｆｅｒｒｅｄ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ）ＭＰＬＳ（Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）ヘッダ内に挿入する。
【００１８】
このようにして、本発明は、ビデオパケットを優先順位でマーキングするための出て行くＭＰＬＳ技術と組み合わせて実施することもできる。
【００１９】
請求項８に記載されるオプションの態様によれば、本発明による適応ストリーミングアウェアネットワークノードは：
−  クライアントからの将来の要求における品質レベルに影響を及ぼすように、クライアントへのビデオセグメントの配信をスケジューリングするように構成されるスケジューリング手段を更に備える。
【００２０】
このようにして、本発明を実施するノードは、ビデオセグメントの配信レート又は配信持続時間を制御するスケジューリング機能性を更に備えることができる。これにより、ノードは、例えば、特定の品質レベルが一般に要求されることになる品質レベルとは異なるように、クライアントの品質レベル選択アルゴリズムに影響を及ぼすことができるようになる。
【００２１】
請求項１に記載の適応ストリーミングアウェアノードに加えて、本発明は、適応ストリーミングアウェアネットワークノードにおいて、ビデオセッションのビデオセグメントをクライアントにストリーミングする対応する方法にも関連し、ビデオセグメントは、１つ又は複数の品質レベルで利用可能であり、各ビデオセグメントは、クライアントから受信された要求において指定された品質レベルでクライアントに配信され、請求項９に記載の方法は、
−  適応ストリーミングアウェアネットワークノードにおいて、ビデオセッションによって占有されるクライアントのバッファ量を示すバッファフィル情報を収集することと、
−  適応ストリーミングアウェアネットワークノードにおいて、バッファフィル情報に応じてセッションのビデオセグメントのための優先順位レベルを決定することと、
−  適応ストリーミングアウェアネットワークノードにおいて、セッションのビデオセグメントを優先順位レベルでマーキングすることとを含む。
【００２２】
本発明は更に、ビデオセッションの、１つ又は複数の品質レベルで利用可能であるビデオセグメントを受信することができ、ビデオセグメントを配信するための品質レベルを要求において指定することができる、請求項１０に記載される対応する適応ストリーミングアウェアクライアントにも関連し、適応ストリーミングアウェアクライアントは、
−  ビデオセグメントが優先順位レベルでマーキングされることを検出するように構成される優先順位検出手段を備える。
【００２３】
実際には、有利には、クライアントは優先順位が使用されていることを検出するように構成される。その際、ビデオセグメントに対して要求された品質レベルを判断するクライアントアルゴリズムは、特定のセッションのビデオパケット／セグメントが、より高い優先順位で送信されたことを考慮に入れることができる。
【図面の簡単な説明】
【００２４】
【図１】本発明による適応ストリーミングアウェアノードの一実施形態の機能ブロック図である。
【発明を実施するための形態】
【００２５】
図１は、本発明を実施するシステムの機能ブロックを示す。図１は、ＨＴＴＰ適応ストリーミング（ＨＡＳ）クライアント１０３と、ＨＡＳサーバ１０２と、その間にあり、本発明を実施するＨＡＳアウェアノード１０１とを更に詳細に示す。
【００２６】
ＨＡＳアウェアノード１０１は、監視機能１１１と、優先順位構成ロジック１１２と、パケットマーカ１１３と、スケジューラ１１４とを備える。更に、ＨＡＳアウェアノード１０１は、そのノードが表す中間ノードのタイプによるが、ルーティング又はスイッチング機能性、キャッシング機能性、パケット処理機能性などを備える場合がある。図１は、ＨＡＳサーバ１０２からビデオセグメントを受信するための入力ポート１１５と、ＨＡＳサーバ１０２に要求を送るための出力ポート１１６と、ＨＡＳクライアント１０３にビデオセグメントを送るための出力ポート１１７と、ＨＡＳクライアント１０３から要求を受信するための入力ポート１１８とを更に示す。
【００２７】
ＨＴＴＰ適応ストリーミング（ＨＡＳ）では、ビデオが幾つかのビットレートにおいて符号化され、通常、ある秒数の断片にセグメント化される。ＨＡＳサーバ１０２からＨＡＳクライアント１０３への、又は中間キャッシングノードからＨＡＳクライアント１０３へのビデオセグメントの配信は、標準的なＨＴＴＰを介して行われる。ＨＡＳクライアント１０３にインストールされたクライアントアプリケーションがネットワーク帯域幅を監視し、この監視された帯域幅と、結果として生じる他の情報、例えば、クライアント側におけるバッファフィリングとに基づいて、セグメントのためにどの品質バージョン／ビットレートを要求するかを判断する。このバッファは、ビデオセグメントの一時格納及びビデオストリームのプレイアウトのために用いられ、プレイアウト中の中断を回避するために、いつでも幾つかのビデオセグメントを含まなければならない。どのセグメントの場合にどのバージョン／ビットレートが利用可能であるかに関する情報は、通常、いわゆる、マニフェストファイル内に配置される。ＨＡＳクライアント１０３は、ＨＡＳサーバ１０２からマニフェストファイルを要求することによって、プレイアウトを開始する。ＨＡＳクライアント１０３は、その後、セグメントごとにＨＴＴＰ−ＧＥＴ要求を送ることによってビデオセグメントをダウンロードし始める。ＨＴＴＰ−ＧＥＴ要求においてセグメントごとに所望の品質が指定される。ビデオセグメントの配信は、単一の中央サーバから、又はコンテンツ配信ネットワーク（ＣＤＮ）、すなわち、複数の分散サーバからなるシステムから行われる。このサービスタイプの配信は、ベストエフォートインターネットを介して行われる。
【００２８】
中間ＨＡＳアウェアノード１０１内の監視機能１１１は、特定のＨＡＳセッションのセグメントによってＨＡＳクライアント１０３において占有されるバッファ量に関する情報を収集する。最終的に、監視機能１１１は、加入タイプ、要求される品質レベル、実際のネットワーク負荷及び／又はコンテンツ若しくはコンテンツソースに関する情報のような他のパラメータも収集する。この情報は、ＨＡＳクライアント１０３におけるバッファ枯渇／アンダーランを回避するために、優先順位判断ロジック１１２が、ＨＡＳセッションの更なるセグメントに割り当てられることになる優先順位レベルに関する決定を行うことができるようにするために、優先順位判断ロジック１１２と共有される。
【００２９】
図１において矢印１２１によって指示されるように、監視機能１１１は、ＨＡＳクライアント１０３から情報を受信する。それに加えて、ＨＡＳクライアント１０３は、ＨＡＳセッションのためのバッファフィルレベルが、所定のしきい値、例えば、３秒のビデオ再生時間未満に降下するたびに、進行中のＨＡＳセッションのためのバッファフィルレベル及び／又は信号を監視機能１１１に定期的に報告するように構成される。更に、監視機能１１１は、図１において矢印１２２及び１２３によって指示されるように、ノード１０１を通過するビデオセグメントからデータを取り込む。例えば、特定の時間間隔内で、出力ポート１１６を介してＨＡＳサーバ１０２に向かって送られたビデオセグメント要求の量を数えることによって、及び／又は出力ポート１１７を介してＨＡＳクライアント１０３に配信されたビデオセグメント数を数えることによって、監視機能１１１は、監視されるＨＡＳセッションに属するセグメントで占められた、クライアント１０３のバッファ空間量を推定することができる。この情報は、ＨＡＳクライアント１０３におけるバッファ枯渇／アンダーランのリスクを更に正確に予測するために、ＨＡＳクライアント１０３から受信された情報と組み合わせられ得る。
【００３０】
優先順位判断ロジック１１２は、監視機能１１１から受信された情報を考慮し、特定のＨＡＳセッションのビデオパケット／セグメントが高い優先順位のチャネルを介して送られるべきであるか否かを決定する。優先順位判断ロジックは、例えば、監視機能１１１によって監視されるようなバッファフィルレベル情報を、１つ又は複数のしきい値と比較することができる。推定されたバッファフィルレベルがしきい値未満に降下すると直ちに、そのＨＡＳセッションに対する優先順位レベルが上げられる。
【００３１】
ＤｉｆｆＳｅｒｖ対応ネットワーク内の優先順位判断ロジック１１２の例示的な実施態様は、監視されたバッファフィルレベルを所定のしきい値、例えば、３秒ビデオ再生時間と比較する。監視されたバッファフィルレベルが特定のＨＡＳセッションの場合に３秒のビデオ再生時間未満に降下するとき、そのＨＡＳセッションに属するビデオパケットのパケットヘッダ内のＤＳＣＰ（差別化サービスコードポイント）値が最も高い優先順位に設定される。
【００３２】
ＭＰＬＳシステム内の優先順位判断ロジック１１２の例示的な実施態様も、監視されたバッファフィルレベルを所定のしきい値、例えば、３秒のビデオ再生時間と比較する。特定のＨＡＳセッションの監視されたバッファフィルレベルが３秒のしきい値未満に降下すると直ちに、適切なＬ−ＬＳＰ（Ｌａｂｅｌ−ｏｎｌｙ−ｉｎｆｅｒｒｅｄ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ）が選択されるか、又はＥ−ＬＳＰ（Ｅｘｐｅｒｉｍｅｎｔａｌ−ｂｉｔ−ｉｎｆｅｒｒｅｄ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ）のＥＸＰ（Ｅｘｐｅｒｉｍｅｎｔａｌ）ビットが設定される。この場合、そのＨＡＳセッションに属するパケット／セグメントの処理のための優先順位は、選択されたＬＳＰによって決定される。Ｌ−ＬＳＰ内のすべてのパケットが同じ優先順位で扱われることになる。Ｅ−ＬＳＰにおいて、優先順位は、ＭＰＬＳヘッダ内のＥＸＰビットによって推測される。Ｅ−ＬＳＰにおいて、異なる優先順位を有するパケットをトランスポートすることができる。
【００３３】
パケットマーカ１１３は、バッファ枯渇／アンダーランのリスクがある監視されたＨＡＳセッションの更なるビデオセグメント／パケットを選択された優先順位で送信するのに必要とされる準備を行う。パケットマーカは、例えば、適切なＤＳＣＰ値をパケットヘッダに挿入することによってパケットをマーキングするか、又はＬＳＰを構成することができる。
【００３４】
ビデオパケット／セグメントの優先順位マーキングが使用可能であるとき、スケジューラ１１４は、ＨＳＡクライアント１０３によって選択された品質レベルに影響を及ぼす。それに加えて、スケジューラは、ＨＡＳクライアント１０３が特定の品質レベルを要求し始めるように、優先順位をマーキングされたビデオセグメントの配信レートを制御する。
【００３５】
本発明は具体的な実施形態を参照しながら説明されてきたが、本発明が上記の例示的な実施形態の細部に限定されないこと、及び本発明がその範囲から逸脱することなく種々の変形及び変更を加えて具現され得ることは当業者には明らかであろう。それゆえ、本実施形態は、すべての点で例示と見なされるべきであり、限定と見なされるべきではなく、本発明の範囲は上記の説明によってではなく、添付の特許請求の範囲によって指示され、それゆえ、特許請求の範囲の意味及び均等物の範囲内にあるすべての変更が、本明細書に包含されることが意図される。言い換えると、基本的な根底にある原理の範囲内に入り、かつその不可欠な属性が本特許出願において特許請求されるありとあらゆる変更形態、変形形態又は同等形態を包含することが意図される。更に、「備える、含む（ｃｏｍｐｒｉｓｉｎｇ、ｃｏｍｐｒｉｓｅ）という用語が他の要素又はステップを除外しないこと、「１つの（ａ、ａｎ）」という用語が複数を除外しないこと、コンピュータシステム、プロセッサ、又は別の集積ユニットのような単一の要素が特許請求の範囲において列挙される幾つかの手段の機能を遂行できることは、本特許出願の読者には理解されよう。特許請求の範囲における任意の参照符号は、関係するそれぞれの請求項を限定すると解釈されるべきではない。「第１の」、「第２の」、「第３の」、「ａ」、「ｂ」、「ｃ」などの用語は、説明及び特許請求の範囲において用いられるときに、類似の要素又はステップ間を区別するために導入されており、必ずしも順次に、又は経時的に示しているわけではない。同様に、「上側」、「下側」、「上方」、「下方」などの用語は、説明のために導入されており、必ずしも相対的な位置を表すために導入されていない。そのように用いられる用語は適切な状況下で交換可能であり、本発明の実施形態は、他の順序において、又は先に説明若しくは例示された１つ又は複数の向きとは異なる向きにおいて、本発明に従って動作することができることは理解されたい。
【図１】
0005990640.tif 000002