JP6403768B2

JP6403768B2 - 適応ストリーミングクライアントのためのバンド幅をリザーブする方法及びデバイス

Info

Publication number: JP6403768B2
Application number: JP2016526237A
Authority: JP
Inventors: タイービ，シャルリーヌ; ボルゼ，フランソワーズル; フーダイル，レミ
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2013-10-29
Filing date: 2014-10-02
Publication date: 2018-10-10
Anticipated expiration: 2034-10-02
Also published as: CN105684390B; US20160261661A1; EP3063918A1; TW201517602A; EP3063918B1; WO2015062808A1; US10419507B2; JP2016541161A; KR102355325B1; KR20160077077A; CN105684390A

Description

本発明は、概して、ビデオストリーミングコンテンツの分配に関係があり、特に、ビデオストリーミングコンテンツによって使用されるバンド幅を制御する方法に関係がある。

本項は、以下で記載及び／又は請求される本発明の様々な態様に関係があり得る技術の様々な態様に読者を引き合わせることを目的としている。この議論は、本発明の様々な態様のより良い理解を助けるよう背景情報を読者に提供するのに有用であると信じられる。然るに、それらの記述は、先行技術の承認としてではなく、この観点において読まれるべきであることが理解されるべきである。

ＨＴＴＰ適応テクノロジは、インターネットにおいて度を超えたオーディオビジュアル配信の提供を可能にするよう様々な利害関係者によって押し進められている。斯様なテクノロジは、クライアント端末が小さい連続したセグメント（２、３秒の長さ）（いわゆるチャンク）の形でビデオを受信することを可能にする。夫々のセグメントは、ＨＴＴＰプロトコルを通じて要求され、種々の変形（いわゆる表現）において存在してよく、クライアント端末がネットワーク及びデバイス制約に適合する適切なビットレートをいつでも選択することを可能にする。

既に使用されているＨＴＴＰ適応ストリーミング（ＨＡＳ；HTTP adaptive streaming）プロトコルの中で最も有名なものは、アップル社のＨＴＴＰ・ライブ・ストリーミング（ＨＬＳ；HTTP Live streaming）、マイクロソフト社のシルバーライト・スムース・ストリーミング（ＳＳＳ；Sliverlight Smooth Streaming）、アドビ社のアドビ・ダイナミック・ストリーミング（ＡＤＳ；Adobe Dynamic Streaming）、及びＳＡ４グループ内の３ＧＰＰによって開発されたＨＰＰＴ経由動的適応ストリーミング（ＤＡＳＨ；Dynamic Adaptive Streaming over HTTP）である。それらのＨＴＴＰ適応ストリーミングのための既存の技術は、コンテンツのオプション（ビットレート、画像ディメンション、フレームレート、など）を記述するためのメタデータを提供するマニフェストファイルフォーマットにおいて、セグメントにおける、サポートされているコーデックにおける、及びコンテンツ保護技術におけるコンテンツの利用可能な表現の編成を変える。

特に、クライアント端末がオーディオ／ビデオコンテンツを再生したいと望む場合に、それは最初に、如何にしてこの特定のコンテンツが取得され得るのかを記述するマニフェストを入手すべきである。これは、ＵＲＬから何らかの‘ファイル’を入手することによって、ＨＴＴＰを通じて行われる。このマニフェストファイルは、コンテンツの利用可能な表現を（ビットレート及び他の特性に関して）リストアップするとともに、夫々の表現について、夫々の時間スライスについてコンテンツチャンクをロードすることを可能にするＵＲＬをリストアップする。ビデオ・オン・デマンド（ＶｏＤ；Video on Demand）に関し、Ａ／Ｖコンテンツの全体の記述が提供され、一方、ライブコンテンツ（例えば、ＴＶコンテンツ）に関し、記述は、短時間しかカバーせず、時間が過ぎる場合に新しい項目を発見するために周期的にリロードされる必要がある。

その機能性及びネットワーキング環境から得られる知識に応じて、クライアント端末は、１つの表現を（例えば、そのビットレートに基づき）選択し、コンテンツの第１のチャンクをロードする。それは、２、３のチャンクを、ネットワーク障害に即応することができるようにバッファリングする。次いで、Ａ／Ｖコンテンツは、夫々の受信されたチャンクから次々に再生される。同時に、クライアント端末は、受信レートを測定し、より高い又はより低いビットレートを選択すると決定してよい。斯様な場合に、それは、単に、他の表現に次のチャンクを要求する。あらゆるＨＴＴＰストリーミング技術は、クライアント端末が、所与のビットレートを有するチャンクから他のビットレートを有する次のチャンクへ移動しながら連続再生を続けることが可能であるようなものである。このようにして、ネットワーク上の競合するトラフィックが、Ａ／Ｖコンテンツが受信されるレートに変化をもたらす場合に、クライアント端末は、バッファ充填を安全なレベルに維持することを可能にするビットレートを有するチャンクを選択することによって、対処し適応することができる。実際に、クライアント端末は、レンダリングがマクロブロック又はピクチャフリーズを引き起こすデータの受信遅れに悩まないレベルにとどまりながら、エンドユーザに良好なビューイング品質を提供するよう最大級のビットレートに達しようと試みる。

特に、ＨＡＳプレイヤーは、サービスプロバイダアプリケーションから通常は利用可能にされ、ユーザによってダウンロードされ得る。適応ストリーミングプレイヤーは、次の３つの重要な機能を有する：
− チャンク要求スケジューリング。２つの要求ストラテジーが一般的に実施される。プレイヤーバッファを形成するために最初に立ち上げフェーズの間に使用される即時ダウンロード、及び一定の再生バッファを保つために定常フェーズにおいて使用される周期ダウンロードである。“Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE”，Junchen Jiang and al.，CoNext 2012において記載されているように、プレイヤーの初期条件に応じて、周期ダウンロードは、他のストリームによるバンド幅に関してＨＡＳストリームが完了する場合にバンド幅割り当ての不公平を生じさせる次善の時間割り当てにつながることがある；
− ビットレート選択。基本ストラテジーは、推定されるバンド幅よりも低い最も高い利用可能なビットレートを保守的に選択することである。選択アルゴリズムの保守主義は、推定されるバンド幅の値と許容されている最大要求ビットレートの値との間に持ち込まれたマージンに従って評価される。保守的な値は、パーセンテージにおいて表現されてよい；
− バンド幅推定。バンド幅推定は、瞬時スループット（すなわち、ダウンロード時間によって分割されるダウンロードサイズ）に基づく。ほとんどの市販プレイヤーは、フィルタリング技術を用いて推定を改善する。現在の推定は、次いで、そのダイナミックを平滑化するよう最後の幾つかの観測にわたって平均化される。

これらのＨＡＳ技術は、前から存在する技術と比べた場合にまあまあ上手く働くことが証明されてきたが、最近の研究は、幾つかの特定の挑戦的な環境（すなわち、他のＨＡＳクライアントとの又は隘路での他のＴＣＰフローとの競合）の下で、ＨＡＳ実施は厳しい安定性、公平性及び効率の問題に苦しむことがあると指摘している。

特に、バンド幅を奪い合う２つのＨＡＳクライアントは予測不能な結果をもたらし、最終的にユーザエクスペリエンスを台無しにすることが観察されている。加えて、ＨＡＳ端末は、バンド幅が評価されず、その場合に潜在的に低く見積もられるＯＦＦ期間を生じさせるそれらの周期ダウンロードプロファイルのために、どん欲なＴＣＰフロー（例えば、バルク転送）と競合する場合にバンド幅のそれらの公平な共有を取り戻すことができない。そして、それらのＯＦＦ期間の間に、特に、他のＴＣＰフローは、バンド幅を横取りする機会をとらえることができる。

最後に、定常状態の間に、ＨＡＳクライアント端末は、所与の目標レート（例えば、２０％の保守的な値）を維持するよう所与のバンド幅保守主義を適用する。それにより、ＨＴＴＰストリーミングは、供給されているバンド幅の１００％を満たすことができず、バンド幅の不十分な利用を引き起こす。

その上、効率を評価するために収束も重要な基準であり、それは初期条件に依存することが本出願人によって観察されている。収束する時間は、現在は決定的でなく、長いことがある。このことは、貧しいユーザエクスペリエンス及び潜在的に次善のバンド幅利用を生じさせる。

本発明は、定義された目標レートへのストリーミングコンテンツの収束を少なくとも改善するために、上記の懸案事項の少なくとも幾つかを改善しようと試みる。

"Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE"，Junchen Jiang and al.，CoNext 2012

本発明は、少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する点が注目に値する方法と関係がある。

本発明のおかげで、適応ストリーミングクライアントの初期条件は、目標データレートへのその収束を改善するために、要求されているストリーミングコンテンツへ起動時に割り当てられているバンド幅を一時的に広げることによって、変更及び／又は影響を及ぼされ得る。収束し且つ安定性を得るための時間を短縮するために、本発明は、クライアントのトランジェント状態の間にトランジェントバンド幅を割り当てることを少なくとも提案する。本出願人は、ＨＡＳストリーミングコンテンツのためにリザーブされるハンド幅が大きければ大きいほど（例えば、所与の制限まで。）、収束はますます早いことを観測した。加えて、適応ストリーミングクライアントの収束がより早い場合に、安定性及び公平性は、適応ストリーミングセッションの全存続期間にわたって得られる。

好適な実施形態に従って、前記トランジェントマージンは、次のパラメータ：
− 前記ネットワークのトータルの利用可能なバンド幅、
− 前記ストリーミングコンテンツに関連した前記所定の目標データレート、
− 前記ネットワークのバンド幅を共有している競合するストリーム、
− 前記ストリーミングコンテンツのプライオリティ、
− 前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する。

特に、前記適応ストリーミングクライアントが保守的な値を使用する場合に、前記トランジェントマージンは前記保守的な値よりも有利に大きい。

加えて、前記トランジェントバンド幅は、望ましくは、前記目標データレートに前記保守的な値を加えたものよりも大きくてよく、前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、望ましくは、前記クライアントが前記より高いデータレートに切り替わらないようにするために、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい。

本発明の他の態様では、前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下であってよい。

本発明の更なる態様では、前記トランジェントバンド幅は、前記クライアントのバッファの充填速度又は充填率（充填状態とも呼ばれる。）に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされ得る。

特に、前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファ満たされると、すなわち、例えば：
− 前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に；又は
− チャンク要求周波数がチャンクの存続期間に等しい場合に、
終了する。

更には、前記イベントは、次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始；
− ネットワーク条件の（望ましくは、顕著な）変化；
− 他のストリームの受信の停止
に属する。

その上、本発明は、少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスと関係がある。本発明に従って、当該デバイスは：
− 前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と；
− バンド幅マネージャであって：
・前記クライアントによって要求されている前記ストリーミングコンテンツに関連した目標データレートを決定し；
・少なくとも１つのイベントが起こる場合に、前記決定された目標データレート及びトランジェントマージンに応じて、トランジェントバンド幅を前記クライアントのためにリザーブする
よう構成される前記バンド幅マネージャと
を有する。

加えて、当該デバイスは、次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
− ネットワーク条件の変化、
− 他のストリームの受信の停止
に属する前記イベントを検出するよう構成される。

更には、前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは、望ましくは、前記保守的な値よりも大きい。

前記目標データレートよりも高い少なくとも１つの他の利用可能データレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、望ましくは、前記クライアントが前記より高いデータレートへ切り替わらないようにするために、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい。

当該デバイスは、例えば、ゲートウェイ又はルータであることができる。

本発明は、コンピュータによって読み出し可能な及び／又はプロセッサによって実行可能な媒体において記録される及び／又は通信ネットワークからダウンロード可能なコンピュータプログラム製品であって、上記の方法を実施するプログラムコード命令を有するコンピュータプログラム製品と更に関係がある。

加えて、本発明は、プロセッサによって実行されることが可能なコンピュータプログラム製品を記録している非一時的なコンピュータ可読媒体であって、上記の方法を実施するプログラムコード命令を含む非一時的なコンピュータ可読媒体とも関係がある。

開示される実施形態と適用範囲において相応である特定の態様は、以下で示される。それらの態様は、本発明がとり得る特定の形態の概要を読者に提供するために提示されているにすぎず、それらの態様は、本発明の適用範囲を制限するよう意図されないことが理解されるべきである。実際に、本発明は、以下で示されていない様々な態様を包含し得る。

本発明は、添付の図面を参照して、制限なしに、以下の実施形態及び実施例を用いて説明されてより良く理解されるであろう。
本発明が実施され得るクライアント−サーバ・ネットワークアーキテクチャの概略図である。図１のネットワークアーキテクチャのクライアント端末の例のブロック図である。本発明の好適な実施形態に従うゲートウェイの例のブロック図である。好適な実施形態に従って、図３のゲートウェイによって実施するバンド幅リザベーション方法のステップを表すフローチャートである。図２及び３において、提示されているブロックは、単に機能的なエンティティであって、必ずしも物理的に別個のエンティティに対応しない。すなわち、それらは、１つ以上のプロセッサを有する１つ以上の集積回路において実施されるか、又はソフトウェアやハードウェアの形で現れてよい。

可能な限り、同じ参照符号は、同じ又は同様の部分を参照するために図面を通して使用される。

本発明の図及び記載は、典型的なデジタルマルチメディアコンテンツ配信方法及びシステムにおいて見つけられる多くの他の要素を明りょうさのために無視しながら、本発明の明りょうな理解にとって適切な要素を表すために簡略化されていることが理解されるべきである。なお、そのような要素は当該技術においてよく知られているので、そのような要素の詳細な議論はここで与えられない。

好適な実施形態に従って、本発明は、ＨＴＴＰ適応ストリーミング（いわゆるＨＡＳ）プロトコルに関して表される。当然ながら、本発明はそのような特定の環境に制限されず、他の適応ストリーミングプロトコルが当然に考えられて実施され得る。

図１に表されているように、本発明が実施され得るクライアント−サーバ・ネットワークアーキテクチャは、例えば、２つのクライアント端末Ｃ１及びＣ２と、ゲートウェイＧＷと、１つ以上のＨＴＴＰサーバＳ（図１では、１つしか表されていない。）とを有する。明らかに、追加のクライアント端末が当該アーキテクチャにおいて存在してよい。

クライアント端末Ｃ１は、ローカルネットワークＮ１（ホームネットワーク又は企業ネットワークとして。）を通じてゲートウェイＧＷへ接続されているＨＴＴＰ適応ストリーミング（ＨＡＳ）クライアント端末であって、ブロードバンドネットワークＮ２（インターネットネットワークとして。）を通じてＨＴＴＰサーバＳへ接続したいと望む。ＨＡＳクライアント端末Ｃ１は、所与の保守的な値を提示する。ローカルネットワークＮ１は、ゲートウェイＧＷのおかげでブロードバンドネットワークＮ２へ接続される。

保守的な値は、推定されるバンド幅の値と選択されている要求されるビットレートとの間でクライアント端末によってとられた最小マージンであることができる。保守的な値は、推定されるバンド幅のパーセンテージにおいて表現されてよい。

ＨＴＴＰサーバＳは、１つ以上のＴＣＰ／ＩＰ接続にわたってＨＡＳプロトコルを用いて、クライアント要求時にチャンクをクライアント端末Ｃ１へストリーミングする。

図２において記載される好適な実施形態に従って、ＨＡＳクライアント端末Ｃ１は、少なくとも：
− ローカルネットワークＮ１への接続１のＬＡＮ（Local Area Network）インターフェイス（例えば、Ｗｉ−Ｆｉ（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、などとして、有線及び／又は無線）；
− ＨＴＴＰサーバＳと通信するためのプロトコルスタックを含む通信モジュール２。特に通信モジュール２は、当該技術においてよく知られているＴＣＰ／ＩＰスタックを有する。当然、それは、クライアント端末Ｃ１がＨＴＴＰサーバＳと通信することを可能にする如何なる他のタイプのネットワーク及び／又は通信手段であってもよい；
− ＨＴＴＰサーバＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する適応ストリーミングモジュール３。それは、ネットワーク制約及びそれ自身の制約とより良く適合するビットレートでチャンクを絶えず選択する；
− マルチメディアコンテンツを復号しレンダリングするよう構成されるビデオプレイヤー４；
− クライアント端末Ｃ１の不揮発性メモリにおいて記憶されているアプリケーション及びプログラムを実行する１つ以上のプロセッサ５；
− ＨＴＴＰサーバＳから受信されたチャンクを、ビデオプレイヤー４へのそれらの送信の前にバッファリングするよう構成されるバッファ６；
− 一般的なクライアント端末機能を実行するために当業者によく知られている様々なモジュール及び全ての手段を接続する内部バスＢ１
を有する。

好適な実施形態において、クライアント端末Ｃ１は、ポータブルメディアデバイス、携帯電話機、タブレット又はラップトップである。当然ながら、クライアント端末Ｃ１は、完全なビデオプレイヤーを有さずに、メディアコンテンツを逆多重化及び復号するもののような幾つかのサブエレメントしか有さなくてよく、そして、復号されたコンテンツをエンドユーザに表示する外部手段に依存してよい。この場合に、クライアント端末Ｃ１は、セットトップボックスのような、ＨＴＴＰ適応ストリーミング対応のビデオデコーダである。

その上、好適な実施形態のゲートウェイＧＷは、デジタル加入者回線（ＤＳＬ；Digital Subscriber Line）ゲートウェイであって、ＤＳＬテクノロジを通じたローカルネットワークＮ１へのインターネットブロードバンドアクセスを提供する。当然、ゲートウェイは、ケーブル、ファイバ又は無線のような如何なるタイプのブロードバンドゲートウェイであってもよい。

図３において示されるように、ゲートウェイＧＷは：
− ローカルネットワークＮ１への接続７のＬＡＮインターフェイス（例えば、Ｗｉ−Ｆｉ、Ｅｔｈｅｒｎｅｔなどとして、有線及び／又は無線）；
− ブロードバンドネットワークＮ２への接続８のブロードバンドインターフェイス（有線及び／又は無線）；及び
− 接続７及び８のインターフェイスを通じて通信するためのプロトコルスタックを有する通信モジュール９。特に、通信モジュールは、ＩＰスタックと記されるインターネットプロトコルスタックを有する；
− マニフェストから取り出された情報（例えば、プレイリスト又はＸＭＬファイル）を記憶するよう特に構成されるメモリ１０；
− ゲートウェイＧＷの不揮発性メモリにおいて記憶されているアプリケーション及びプログラムを実行する１つ以上のプロセッサ１５；
− 一般的な家庭用ゲートウェイ機能を実行するために当業者によく知られている様々なモジュール及びプロセッシング手段、ルーティング及びブリッジング手段並びに全ての手段を接続する内部バスＢ２
を有する。

上述されたように、適応ストリーミングにおけるマルチメディアコンテンツ（例えば、映画）を再生するために、クライアント端末Ｃ１は、最初に、要求されているマルチメディアコンテンツの利用可能な表現を（ビットレート及び解像度に関して）リストアップするマニフェストをサーバＳから入手する必要がある。このマニフェストは、前もって生成されて、ＨＴＴＰサーバＳで記憶されている。

更には、ゲートウェイＧＷは、ネットワーク条件の変化を識別するネットワーク監視ユニット１１と、ゲートウェイで受信されたストリームを解析するよう構成されるストリーム識別部１２とを更に有する。クライアント端末Ｃ１がサービス要求を発行するたびに、ストリーム識別部１２は、当該要求を識別し、サーバＳからクライアントＣ１へ返されたマニフェストをインターセプトすることによってサービス情報を収集し、それによって、サーバＳによって知らされた利用可能なビットレート及び関連するチャンクＵＲＬのような情報を解析し抽出する。マニフェストをインターセプトするよう、ストリーム識別部１２は、利用可能なストリーミング技術及び関連するプロトコルを承知している。夫々のプロトコルにおいて、それは、マニフェストを運ぶパケットのタイプを知っている。例えば、ストリーム識別部１２は、アップルのＨＴＴＰライブ・ストリーミング、マイクロソフトのスムース・ストリーミング、及びアドビのオープン・ソース・メディア・フレームワーク技術を承知している。当然、それは、他のストリーミング技術を認識するよう構成され得る。

ストリーム識別部１２は、ストリームがもはやゲートウェイＧＷで受信されない場合も識別する。制限されない実例となる例として、ストリームが所定の期間の間受信されない場合に、ストリーム識別部１２は、セッションが終わったと見なすことができ、そして、ゲートウェイＧＷのバンド幅マネージャ１３に通告することができる。バンド幅マネージャ１３は、以降で記載されるように然るべくトラフィック制御規則及びバンド幅リザベーションを変更することができる。

バンド幅マネージャ１３は、次いで、ストリーム識別部１２によって入手された情報を受けるよう構成される。特に、バンド幅マネージャ１３は、サービスが認められているかどうかを判定し、そのサービスに関して目標ビットレートを決定し、場合により、既に実行されている他のサービスのための目標を同時に変更する。バンド幅マネージャ１３は、ゲートウェイＧＷのブロードバンドインターフェイス８で利用可能な最大バンド幅の値を測定する。

特に、ＨＡＳクライアント端末Ｃ１がストリーミングコンテンツをサーバＳに要求する場合に、バンド幅マネージャ１３は、ストリーム識別部１２から受信された情報及び追加のパラメータ（例えば、利用可能なネットワークバンド幅、ストリームのプライオリティ、クライアント端末の保守的な値、など）に基づき目標ビットレートＲ_Ｔを決定した後に、要求されているストリーミングコンテンツに関連したトランジェントバンド幅ＢＷ_ｔをリザーブし、次いで、ゲートウェイＧＷのスケジューラ１４を設定する。

スケジューラ１４は、ローカルネットワークＮ１におけるパケットの送信を管理するよう構成される。特に、夫々のＨＡＳストリームは、トランジェント期間Ｄ_ｃの間のまさに１つのトランジェントバンド幅ＢＷ_ｔと、ストリーム受信の終了までの１つの定常バンド幅ＢＷ_ｓとを配分されている独立したキューを割り当てられる。

トランジェントバンド幅ＢＷ_ｔは、トランジェント期間Ｄ_ｃの間リザーブされ、決定された目標データレートＲ_Ｔ及びトランジェントマージンｍ_ｔに依存する。特に、トランジェントバンド幅ＢＷ_ｔは、以下のように、目標ビットレートＲ_Ｔにトランジェントマージンｍ_ｔを加えたものに等しくてよい：

ＢＷ_ｔ＝Ｒ_Ｔ＋ｍ_ｔなお、ｔ∈［Ｔ_ｏ；Ｔ_ｏ＋Ｄ_ｃ］

上記の式において、ｔは時間であり、Ｔ_ｏはストリーミングコンテンツの受信の開始を示す。

有利なことには、トランジェントマージンｍ_ｔは、保守的な値Ｖ_ｃよりも大きく（ｍ_ｔ＞Ｖ_ｃ）、それにより：

ＢＷ_ｔ＞Ｒ_Ｔ＋Ｖ_ｃなお、ｔ∈［Ｔ_ｏ；Ｔ_ｏ＋Ｄ_ｃ］

が成立する。

目標ビットレートＲ_Ｔよりも高い少なくとも１つの他のビットレート（Ｒ_Ｔ＋１と記される。）が受信されたマニフェストにおいて挙げられており、サーバＳで利用可能である場合に、トランジェントバンド幅ＢＷ_ｔは、より高いデータレートＲ_Ｔ＋１にＨＡＳクライアント端末Ｃ１の保守的な値Ｖ_ｃを加えたものよりも小さい。それにより：

ＢＷ_ｔ＜Ｒ_Ｔ＋１＋Ｖ_ｃ

が成立する。

他の実例となる例として、トランジェントバンド幅ＢＷ_ｔは、次の関係によって求められてよい：

ＢＷ_ｔ＝Ｒ_Ｔ×１００／（１００−ｍ_ｔ）なお、ｔ∈［Ｔ_ｏ；Ｔ_ｏ＋Ｄ_ｃ］

当然ながら、他の式がトランジェントバンド幅を決定するために使用されてよい。

トランジェントマージンｍ_ｔは、次のパラメータのうちの１つ以上に基づくことができる：
− ブロードバンドネットワークＮ２のトータルの利用可能なバンド幅ＢＷ_{ＴＯＴＡＬ}；
− ＨＡＳクライアント端末Ｃ１によって要求されるストリーミングコンテンツに関連した決定された目標データレートＲ_Ｔ；
− ネットワークバンド幅を共有している競合するストリーム（例えば、第２のクライアント端末Ｃ２によって受信されるストリーム）；
− ストリーミングコンテンツのプライオリティ；
− 適応ストリーミングクライアント端末Ｃ１の保守的な値。

特に、目標ビットレートＲ_Ｔがサーバによって提供される（マニフェストにおいてリストアップされる）最大ビットレートである場合に、トランジェントマージンｍ_ｔは、トータルの利用可能なバンド幅ＢＷ_{ＴＯＴＡＬ}と目標ビットレートＲ_Ｔとの間の差に多くても等しい。それにより：

ｍ_ｔ≦ＢＷ_{ＴＯＴＡＬ}−Ｒ_Ｔ

が成立する。

好適な実施形態において、バンド幅マネージャ１３は、ブロードバンドインターフェイス８で利用可能な最大バンド幅の値に基づき、バンド幅リザベーションを決定する。代替的に、ブロードバンドネットワークＮ２のブロードバンドインターフェイス８で利用可能な最大バンド幅の代わりに、バンド幅マネージャ１３は、ローカルネットワークＮ１のＬＡＮインターフェイスで利用可能な最大バンド幅を考慮してよい。それは、次いで、ローカルネットワークＮ１で利用可能な最大バンド幅の値に基づき、バンド幅リザベーションを決定する。これは、隘路がブロードバンドネットワークＮ２ではなくローカルネットワークＮ１にある場合に起こる。

ＨＡＳクライアント端末Ｃ１がその要求されているストリーミングコンテンツをサーバＳから受信し始める場合におけるバンド幅マネージャ１３によるトランジェント期間Ｄ_ｃの間のトランジェントバンド幅ＢＷ_ｔのリザベーションが記載されてきたが、斯様なトランジェントバンド幅のリザベーションは、バンド幅共有がネットワーク条件の大きな変化（特に、ＨＡＳクライアントＣ１のためのバンド幅部分の増大）又はＨＡＳクライアント端末Ｃ１に割り当てられているバンド幅部分の増大を生じさせる他のストリームの受信の中止により変更されるべき場合にも実行され得る。そのようなイベントは、対応するメッセージ（例えば、ゲートウェイＧＷによって送信される。）によって識別され、ＨＡＳクライアント端末Ｃ１のバンド幅の割増部分の一時的な許可をトリガして、それにより、定常状態へのその収束を加速させる。換言すると、そのようなイベントは、クライアント端末Ｃ１による関連するメッセージの受信時に検出される。

更には、トランジェント期間Ｄ_ｃは、前もってバンド幅マネージャ１３によって設定され、例えば、固定値（例えば、数秒）に等しくてよい。それに反して、トランジェント期間Ｄ_ｃは、前もって設定されなくてもよく、ＨＡＳクライアント端末Ｃ１のバッファ６の充填速度に依存してよい。特に、トランジェント期間Ｄ_ｃは、クライアント端末Ｃ１のバッファ６におけるロードされたチャンクの数に依存することができ、例えば、ＨＡＳクライアント端末Ｃ１によって受信されるチャンクの数が、バッファ長に、経過時間の間に適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了することができる。

バッファ充填期間Ｔ_ｂは、次の関係によって近似され得ることが知られる：

Ｔ_ｂ＝Ｌ_Ｂ×Ｒ_Ｔ／（ＢＷ_ｔ−Ｒ_Ｔ）

この式において：
− Ｌ_Ｂはバッファ長（単位秒）であり；
− Ｒ_Ｔは目標ビットレート（単位ｋｂｐｓ）であり；
− ＢＷ_ｔはリザーブされるトランジェントバンド幅（単位ｋｂｐｓ）である。

変形例において、トランジェント期間Ｄ_ｃは、チャンク要求周波数が、少なくともおおよそ、チャンクの存続期間に等しくなるまで、保たれ得る（その場合に、バッファ６は満たされたと見なされる。）。

他の変形例において、又は補足として、トランジェント期間は、クライアント端末Ｃ１のバッファ６の充填率（又は状態）にも依存してよい（例えば、バッファの８０％）。

その上、本発明の更なる態様において、バンド幅マネージャ１３は、定常状態の間、トランジェント期間Ｄ_ｃの終了後に、端末Ｃ１によって要求されているストリーミングコンテンツに関連する１つの定常バンド幅ＢＷ_ｓを更にリザーブすることができる。

定常バンド幅ＢＷ_ｓは、決定された目標データレートＲ_Ｔ及び定常マージンｍ_ｓに等しい。定常マージンｍ_ｓは、トランジェントマージンｍ_ｔよりも小さい（ｍ_ｓ＜ｍ_ｔ）。例えば：

ＢＷ_ｓ＝Ｒ_Ｔ＋ｍ_ｓなお、ｔ＞Ｔ_ｏ＋Ｄ_ｃ且つＢＷ_ｓ＜ＢＷ_ｔ。

特に、定常バンド幅ＢＷ_ｓは、目標ビットレートＲ_Ｔに保守的な値Ｖ_ｃを加えたものに少なくとも等しくてよい（定常マージンｍ_ｓは、その場合に保守的な値Ｖ_ｃに等しい。）。それにより：

ＢＷ_ｓ≧Ｒ_Ｔ＋Ｖ_ｃなお、Ｔ_ｏ＋Ｄ_ｃ

が成立する。

他の例として、定常バンド幅ＢＷ_ｓは、次の関係によって求められてよい：

ＢＷ_ｓ＝Ｒ_Ｔ×１００／（１００−ｍ_ｓ）なお、Ｔ_ｏ＋Ｄ_ｃ。

ＨＡＳストリーミングコンテンツのためのバンド幅リザベーション（トランジェントバンド幅ＢＷ_ｔ、定常バンド幅ＢＷ_ｓ）に関するバンド幅マネージャ１３の決定は、多数のパラメータ及びユーザ又はサービスプロバイダの好みに依存する。それらは、要求されるコンテンツ、ネットワーク、ネットワークのクライアント端末、等の特性によって与えられる、バンド幅マネージャによって強いられるアービトレーションスキームの組となる。

競合するストリーム（例えば、クライアント端末Ｃ１及びＣ２によって要求される。）の場合に、バンド幅マネージャ１３によるバンド幅リザベーションは、クライアント端末のタイプに依存することができる。例えば、テレビジョンセットのためのストリームは、ポータブルメディアプレイヤーのためのストリームよりも高いプライオリティを有することができる。代替的に、バンド幅リザベーションは、ローカルネットワークＮ１におけるクライアント端末Ｃ１、Ｃ２の位置や、ユーザの身元などにも基づくことができる。居間に位置するクライアント端末Ｃ１、Ｃ２は、寝室に位置するクライアント端末Ｃ１、Ｃ２よりも高いプライオリティを有してよい。望ましくは、ゲートウェイＧＷは、ストリーム間でプライオリティを調整することを可能にするユーザインターフェイス（図示せず。）を有する。ユーザインターフェイスでの入力は、例えば、デバイスのタイプ、その位置及びそのプライオリティであってよい。

本発明に従って、バンド幅マネージャ１３は、次いで、クライアント端末Ｃ１によって要求されるＨＡＳストリーミングコンテンツのために２つの別個の規則を定義する。第１の規則は、収束期間に対応する極めて短い期間（トランジェント期間Ｄ_ｃとしても知られる。）に適用される。次いで、第２の規則は、ストリームの受信の終了まで適用される。収束期間は、ＨＡＳクライアント端末Ｃ１がトランジェント状態にあり、目標レートＲ_Ｔに達してそのバッファを満たそうと試みる期間に対応する。この収束期間の後、ＨＡＳクライアント端末Ｃ１は、ストリームの終了まで又はネットワーク条件が変化するまで同じレートを保ちながら定常状態にあるべきである。第１の規則は、ＨＡＳクライアント端末Ｃ１に対してバンド幅の余分の部分を一時的に許可し、それによって、定常状態へのその収束を加速させるとともに安定性を得る。本出願人は、リザーブされるバンド幅が大きければ大きいほど、目標ビットレートへの収束がますます早いことを観測した。

提案される発明は、所与のＨＡＳストリームと競合するストリームが膨大なＴＣＰダウンロード、進行性のダウンロードストリーム又は他のＨＡＳストリームである場合に適用され得る。

トランジェントマージン及び定常マージンは、上記のパラメータ（プライオリティ、ユーザ好み、競合するストリーム、など）に基づき実験により決定されることが理解されるべきである。

制限されない実例として、３０秒のバッファを用いたスムース・ストリーミングＨＡＳサービスに関して、次の典型的な値が選択され得る：
− トランジェントマージン＝決定されるべき割り当てトランジェントバンド幅の４０％（例えば、ｔ∈［Ｔ_ｏ；Ｔ_ｏ＋Ｄ_ｃ］について、式ＢＷ_ｔ＝Ｒ_Ｔ×１００／（１００−ｍ_ｔ）においてｍ_ｔ＝４０）；
− 定常マージン＝決定されるべき割り当て定常バンド幅の２０％（例えば、ｔ＞Ｔ_ｏ＋Ｄ_ｃについて、式ＢＷ_ｓ＝Ｒ_Ｔ×１００／（１００−ｍ_ｓ）においてｍ_ｓ＝２０）。

好適な実施形態に従って、図４に示されるように、ゲートウェイＧＷは、ＨＡＳクライアント端末Ｃ１のためのバンド幅をリザーブする方法を実施するよう構成される。方法は、次のステップを有する：
− ゲートウェイＧＷでリザーブされるストリームを解析する（ステップＳ０）；
− 所与のイベント（例えば、クライアント端末Ｃ１によるＨＡＳストリーミングコンテンツの受信の開始、ネットワーク条件の大きな変化）を検出する（ステップＳ１）；
− ＨＡＳクライアント端末Ｃ１によって要求されるストリーミングコンテンツに関連した目標データレートを決定する（ステップＳ２）；
− 少なくとも１つのイベントが検出される場合に、トランジェント期間Ｄｃの間はトランジェントバンド幅ＢＷ_ｔを、ＨＡＳストリーミングコンテンツの終了までは定常バンド幅ＢＷ_ｓをＨＡＳクライアント端末Ｃ１のためにリザーブする（ステップＳ３）。

好適な実施形態において、バンド幅リザベーションは、ゲートウェイＧＷで実行される。代替的に、それはまた、ローカルネットワークＮ１に位置してゲートウェイＧＷへ接続されているルータにおいて、又は外部ルータにおいて、又はブロードバンドネットワークＮ２に位置するキャッシュにおいて、実行されてよい。

図面におけるフローチャート及び／又はブロック図は、本発明の様々な実施形態に従うシステム、方法及びコンピュータプログラム製品の起こり得る実施の構成、動作及び機能性を説明する。これに関して、フローチャート又はブロック図における夫々のブロックは、モジュール、セグメント、又はコードの部分を表してよい。コードは、特定されている論理関数を実施するための１つ以上の実行可能命令を含む。幾つかの代替の実施において、ブロックにおいて表されている機能は、図に表されている順序を外れて起こってよいことも留意されるべきである。例えば、続けて示されている２つのブロックは、実際には略同時に実行されてよく、あるいは、ブロックは、逆の順序において時には実行されてよく、あるいは、ブロックは、関連する機能性に応じて別の順序において実行されてよい。ブロック図及び／又はフローチャート図の夫々のブロック、並びにブロック図及び／又はフローチャート図におけるブロックの組み合わせは、特定される機能又は動作を実行する専用のハードウェアに基づいたシステム、あるいは、専用のハードウェアとコンピュータ命令との組み合わせによって実施され得ることも知られる。明示的に記載されていないが、本実施形態は、如何なる組み合わせ又は部分的組み合わせにおいても用いられてよい。

当業者に明らかなように、本原理の態様は、システム、方法又はコンピュータ可読媒体として具現され得る。然るに、本原理の態様は、全体としてハードウェアの実施形態、全体としてソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード、などを含む。）、又はここで“回路”、“モジュール”若しくは“システム”と一般的に呼ばれ得る、ソフトウェア及びハードウェア態様を組み合わせる実施形態の形をとることができる。更には、本原理の態様は、コンピュータ可読記憶媒体の形をとることができる。１つ以上のコンピュータ可読記憶媒体の如何なる組み合わせも利用されてよい。

コンピュータ可読記憶媒体は、１つ以上のコンピュータ可読媒体において具現され、コンピュータによって実行可能なコンピュータ可読プログラムコードを担持しているコンピュータ可読プログラム製品の形をとることができる。ここで使用されるコンピュータ可読記憶媒体は、情報を記憶する固有の機能及び情報の検索を提供する固有の機能を前提として、非一時的な記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学式、電磁気、赤外線、又は半導体のシステム、装置、又はデバイス、あるいはそれらのあらゆる適切な組み合わせであることができるが、それらに限られない。当然に、以下は、本原理が適用され得るコンピュータ可読記憶媒体のより具体的な例を与えるが、当業者によって容易に理解されるように、網羅的ではなく、単なる実例としての列挙である：可搬性のコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ；random access memory）、読出専用メモリ（ＲＯＭ；read-only memory）、消去可能なプログラム可能読出専用メモリ（ＥＰＲＯＭ（erasable programmable read-only memory）又はフラッシュメモリ）、可搬性のコンパクトディスク型読出専用メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、又はこれらのあらゆる適切な組み合わせ。
上記の実施形態に加えて、以下の付記を開示する。
（付記１）
少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する方法。
（付記２）
前記トランジェントマージンは、次のパラメータ：
− 前記ネットワークのトータルの利用可能なバンド幅、
− 前記ストリーミングコンテンツに関連した前記所定の目標データレート、
− 前記ネットワークのバンド幅を共有している競合するストリーム、
− 前記ストリーミングコンテンツのプライオリティ、
− 前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する、
付記１に記載の方法。
（付記３）
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
付記１又は２に記載の方法。
（付記４）
前記トランジェントバンド幅は、前記目標データレートに前記保守的な値を加えたものよりも大きく、
前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい、
付記３に記載の方法。
（付記５）
前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下である、
付記１乃至４のうちいずれか１つに記載の方法。
（付記６）
前記トランジェントバンド幅は、前記クライアントのバッファの充填速度に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
付記１乃至５のうちいずれか１つに記載の方法。
（付記７）
前記トランジェントバンド幅は、前記クライアントのバッファの充填率に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
付記１乃至６のうちいずれか１つに記載の方法。
（付記８）
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、経過時間の間に前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了する、
付記６又は７に記載の方法。
（付記９）
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、チャンク要求周波数がチャンクの存続期間に等しい場合に終了する、
付記６又は７に記載の方法。
（付記１０）
前記イベントは、次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
− ネットワーク条件の変化、
− 他のストリームの受信の停止
に属する、
付記１乃至９のうちいずれか１つに記載の方法。
（付記１１）
少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスであって、
− 前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と、
− 少なくとも１つのイベントが起こる場合に、前記要求されているストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするよう構成されるバンド幅マネージャと
を有するデバイス。
（付記１２）
次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
− ネットワーク条件の変化、
− 他のストリームの受信の停止
に属する前記イベントを検出するよう構成される
付記１１に記載のデバイス。
（付記１３）
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
付記１１又は１２に記載のデバイス。
（付記１４）
コンピュータによって読み出し可能な及び／又はプロセッサによって実行可能な媒体において記録される及び／又は通信ネットワークからダウンロード可能なコンピュータプログラム製品であって、
付記１乃至９の少なくとも１つに記載の方法を実施するプログラムコード命令を有するコンピュータプログラム製品。
（付記１５）
プロセッサによって実行されることが可能なコンピュータプログラム製品を記録している非一時的なコンピュータ可読媒体であって、
付記１乃至９の少なくとも１つに記載の方法を実施するプログラムコード命令を含む非一時的なコンピュータ可読媒体。

Claims

少なくとも１つのネットワークに属するよう構成され、少なくとも１つのサーバから、該サーバにおいて複数のデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する方法。
前記トランジェントマージンは、次のパラメータ：
− 前記ネットワークのトータルの利用可能なバンド幅、
− 前記ストリーミングコンテンツに関連した前記所定の目標データレート、
− 前記ネットワークのバンド幅を共有している競合するストリーム、
− 前記ストリーミングコンテンツのプライオリティ、
− 前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する、
請求項１に記載の方法。
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
請求項１又は２に記載の方法。
前記トランジェントバンド幅は、前記目標データレートに前記保守的な値を加えたものよりも大きく、
前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい、
請求項３に記載の方法。
前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下である、
請求項１乃至４のうちいずれか一項に記載の方法。
前記トランジェントバンド幅は、前記クライアントのバッファの充填速度に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
請求項１乃至５のうちいずれか一項に記載の方法。
前記トランジェントバンド幅は、前記クライアントのバッファの充填率に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
請求項１乃至６のうちいずれか一項に記載の方法。
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、経過時間の間に前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了する、
請求項６又は７に記載の方法。
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、チャンク要求周波数がチャンクの存続期間に等しい場合に終了する、
請求項６又は７に記載の方法。
前記イベントは、次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
− ネットワーク条件の変化、
− 他のストリームの受信の停止
に属する、
請求項１乃至９のうちいずれか一項に記載の方法。
少なくとも１つのネットワークに属するよう構成され、少なくとも１つのサーバから、該サーバにおいて複数のデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスであって、
− 前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と、
− 少なくとも１つのイベントが起こる場合に、前記要求されているストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするよう構成されるバンド幅マネージャと
を有するデバイス。
次のイベント群：
− 前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
− ネットワーク条件の変化、
− 他のストリームの受信の停止
に属する前記イベントを検出するよう構成される
請求項１１に記載のデバイス。
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
請求項１１又は１２に記載のデバイス。
コンピュータによって実行される場合に、該コンピュータに、
請求項１乃至９のうちいずれか一項に記載の方法を実施させるコンピュータプログラム。
コンピュータによって実行される場合に、該コンピュータに、
請求項１乃至９のうちいずれか一項に記載の方法を実施させるコンピュータプログラムを記憶している非一時的なコンピュータ可読媒体。