(57)【要約】 【課題】ネットワークにおける輻輳の状況をより正確に把握して要求するビットレートを決定できる、またはネットワークリソースの利用についての公平さを考慮して要求するビットレートを決定する。【解決手段】クライアント装置は、複数のセグメントに分割され、セグメントごとに異なるビットレートを指定可能なコンテンツのセグメントデータを、ネットワークにおける輻輳の度合いを示す輻輳情報と共にネットワークを介して取得する取得部と、取得部によって取得された輻輳情報に基づいて、次に要求するセグメントのビットレートを決定する決定部と、を備える。【選択図】図１
2017220796.tif 000002
【特許請求の範囲】
【請求項１】
複数のセグメントに分割され、セグメントごとに異なるビットレートを指定可能なコンテンツのセグメントデータを、ネットワークにおける輻輳の度合いを示す輻輳情報と共にネットワークを介して取得する取得部と、
前記取得部によって取得された輻輳情報に基づいて、次に要求するセグメントのビットレートを決定する決定部と、を備えるクライアント装置。
【請求項２】
前記取得部によって取得された輻輳情報に基づいてビットレートの基準値を算出する算出部をさらに備え、
前記決定部は、前記算出部によって算出された基準値と次に要求するセグメントに対して指定可能な異なる複数のビットレートとの比較によりビットレートを決定する請求項１に記載のクライアント装置。
【請求項３】
前記算出部は、前記クライアント装置におけるサービス品質とビットレートとの関係を示すユーティリティ関数に、前記取得部によって取得された輻輳情報をサービス品質の指標として適用することで、基準値を算出する請求項２に記載のクライアント装置。
【請求項４】
前記ユーティリティ関数は階段関数を近似し、該階段関数の各ステップは次に要求するセグメントに対して指定可能な異なる複数のビットレートのひとつに対応する請求項３に記載のクライアント装置。
【請求項５】
前記決定部によって決定されたビットレートを指定して次のセグメントをネットワークを介して要求する要求部をさらに備えることを特徴とする請求項１から４のいずれか１項に記載のクライアント装置。
【請求項６】
セグメントデータはコンテンツのソースまたはキャッシュから前記クライアント装置へ複数のリンクを通じて伝送され、
前記取得部によって取得された輻輳情報は、前記複数のリンクのそれぞれにおける輻輳の度合いの累計を反映する請求項１から５のいずれか１項に記載のクライアント装置。
【請求項７】
複数のセグメントに分割され、セグメントごとに異なるビットレートを指定可能なコンテンツのセグメントデータを、ネットワークにおける輻輳の度合いを示す輻輳情報と共にネットワークを介して取得することと、
前記取得された輻輳情報に基づいて、次に要求するセグメントのビットレートを決定することと、を含む方法。
【請求項８】
複数のセグメントに分割され、セグメントごとに異なるビットレートを指定可能なコンテンツのセグメントデータを、ネットワークにおける輻輳の度合いを示す輻輳情報と共にネットワークを介して取得する機能と、
前記取得された輻輳情報に基づいて、次に要求するセグメントのビットレートを決定する機能と、をコンピュータに実現させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置および方法に関する。
【背景技術】
【０００２】
近年、オンライン動画配信サービスにおいてＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）型配信に代表される配信ビットレートを動的に変更する配信形態が広く採用されている（例えば、非特許文献１、２参照）。本方式によれば、予めあるコンテンツについて、異なるビットレートのデータを用意し、かつ、セグメント単位に分割しておくことで、ネットワーク状況に応じて最適かつ最高の品質のコンテンツを要求できるようになる。具体的には、コンテンツビットレートと直近で計測したスループットの指標とが比較され、スループットを超えない範囲のビットレートのセグメントファイルが要求される。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】I. Sodagar, “The MPEG-DASH Standard for Multimedia Streaming Over the Internet,” IEEE MultiMedia, vol.18, pp.62-67, 2011.
【非特許文献２】Z. Li et al., “Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale,” IEEE Journal on Selected Areas in Communications, vol.32, 719-733, 2014
【非特許文献３】W.-H. Wang et al., “Application-Oriented Flow Control: Fundamentals, Algorithms and Fairness,” IEEE/ACM Transactions on Networking, 2006, 14, 1282-1291
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ＤＡＳＨでビットレート決定のために使用されるスループットはクライアント装置で計測されるものであるため、クライアント装置の状況にも左右され、ネットワーク状況の指標として正確でない場合がある。また、現状のＤＡＳＨではネットワークリソースの利用についての公平さは考慮されていない。
【０００５】
本発明はこうした課題に鑑みてなされたものであり、その目的は、ネットワークにおける輻輳の状況をより正確に把握して要求するビットレートを決定できる、またはネットワークリソースの利用についての公平さを考慮して要求するビットレートを決定できる配信技術の提供にある。
【課題を解決するための手段】
【０００６】
本発明のある態様はクライアント装置に関する。このクライアント装置は、複数のセグメントに分割され、セグメントごとに異なるビットレートを指定可能なコンテンツのセグメントデータを、ネットワークにおける輻輳の度合いを示す輻輳情報と共にネットワークを介して取得する取得部と、取得部によって取得された輻輳情報に基づいて、次に要求するセグメントのビットレートを決定する決定部と、を備える。
【０００７】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、ネットワークにおける輻輳の状況をより正確に把握して要求するビットレートを決定できる、またはネットワークリソースの利用についての公平さを考慮して要求するビットレートを決定できる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態に係る配信システムのネットワークトポロジの一例を示す模式図である。
【図２】配信サーバに保持されるコンテンツの説明図である。
【図３】実施の形態に係るクライアント装置の機能および構成を示すブロック図である。
【図４】ユーティリティ関数の一例を示すグラフである。
【図５】図３のクライアント装置における一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。
【００１１】
図１は、実施の形態に係る配信システム１００のネットワークトポロジの一例を示す模式図である。配信システム１００は７つのノードを含む。ノード１〜４はそれぞれ、デスクトップＰＣ（Personal Computer）やラップトップＰＣや携帯端末などのクライアント装置であり、ノード７はコンテンツのソースとなる配信サーバである。ノード５はルータ等のネットワーク機器であり、ノード６はコンテンツのキャッシュとなるキャッシュサーバである。一例では、ノード７とノード１〜４とはインターネットなどのネットワークを介して接続され、ノード５、６はこのネットワークに含まれるノードである。
【００１２】
以下では、ノード間の接続をリンクと称する。各リンクには、そのリンクにおける輻輳の度合いを示す輻輳プライス（Congestion price）が対応付けられている。
【００１３】
配信サーバ（ノード７）は、映画やアニメーションや他の動画像などのコンテンツを保持し、クライアント装置（ノード１〜４）からの要求に応じてストリーミング形式で配信する。
【００１４】
図２は、配信サーバに保持されるコンテンツの説明図である。配信サーバはひとつのコンテンツを複数のビットレート（符号化速度）で保持する。複数のビットレートは３００ｋｂｐｓ、１．２Ｍｂｐｓ、５Ｍｂｐｓを含むがこれらに限定されない。配信サーバでは、ひとつのコンテンツはＮ個（Ｎは２以上の自然数）のセグメントに分割される。各セグメントは所定の再生長またはデータ量に対応する。本実施の形態ではセグメントは３秒、５秒、１０秒のいずれかの再生長に対応するものとする。各セグメントには複数のビットレートのそれぞれに対応するセグメントファイルが存在する。
【００１５】
図２には、３秒の再生長でＮ個のセグメントに分割されたコンテンツが示される。すなわちこのコンテンツの総再生長は３・Ｎ秒となる。各セグメントについて、ビットレートが高いほどセグメントファイルのデータ量は多くなる。図２に示されるように、配信サーバにはセグメントごとに異なるビットレートのデータが用意されており、セグメントごとに異なるビットレートを指定可能となっている。例えば、セグメント１については３００ｋｂｐｓのセグメントファイル２０２、セグメント２については１．２Ｍｂｐｓのセグメントファイル２０４、セグメント３については５Ｍｂｐｓのセグメントファイル２０６、がそれぞれ指定され、クライアント装置に配信されてもよい。ビットレートの指定はクライアント装置からのセグメントの要求に含まれる。
【００１６】
本実施の形態では、クライアント装置が次に要求するセグメントのビットレートを決定する際、ネットワークにおける輻輳の度合いとユーザ間のネットワークリソース利用の公平さとを考慮する。これにより、ビットレートの決定にネットワークの輻輳の状態をより正確に反映することができ、かつユーザ間の公平さも担保することができる。
【００１７】
図３は、実施の形態に係るクライアント装置１０６の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（Central Processing Unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００１８】
クライアント装置１０６はコンテンツをネットワーク１０４を介して取得する。クライアント装置１０６は受信したデータをバッファしつつ既にバッファされているデータを順次再生する。クライアント装置１０６は、アクセスクライアント１０８と、メディアエンジン１１０と、制御エンジン１１２と、ディスプレイ１１４と、ユーザ操作受付部１１８と、を備える。
【００１９】
アクセスクライアント１０８はネットワーク１０４とのインタフェースとして機能する。アクセスクライアント１０８はネットワーク１０４を介してクライアント装置１０６宛に送られてきたデータを受信して他の部材に提供すると共に、他の部材から送信対象のデータを取得してネットワーク１０４に送信する。
【００２０】
メディアエンジン１１０はクライアント装置１０６が受信したコンテンツを再生するための復号等の処理を行い、ディスプレイ１１４にコンテンツを表示させる。メディアエンジン１１０は受信したコンテンツのセグメントファイルを保持するためのバッファ１３６を含む。配信サーバから送信されたセグメントファイルはネットワーク１０４を介してアクセスクライアント１０８で受信され、アクセスクライアント１０８からメディアエンジン１１０に送信され、メディアエンジン１１０においてバッファ１３６に格納される。また、メディアエンジン１１０は再生対象のセグメントファイルをバッファ１３６から読み出して処理し、ディスプレイ１１４に表示させる。
【００２１】
ユーザ操作受付部１１８は不図示のタッチパネル等の入力装置と接続され、ユーザから再生対象のコンテンツの指定を受け付ける。ユーザ操作受付部１１８は、コンテンツの再生に関するユーザ操作、例えばコンテンツの再生開始や再生停止の指示、を受け付ける。
【００２２】
制御エンジン１１２は、配信サーバに対するコンテンツの要求および配信サーバからのコンテンツの受信を制御する。制御エンジン１１２は、セグメント要求部１２６と、輻輳情報処理部１２８と、基準レート算出部１３０と、フィルタ部１３２と、ビットレート決定部１３４と、要求スケジュール部１３８と、を含む。
【００２３】
セグメント要求部１２６は、ビットレート決定部１３４によって決定されたビットレートを指定して次のセグメントを、ネットワーク１０４を介して配信サーバに要求する。セグメント要求部１２６は、要求する次のセグメントのＩＤと該セグメントについて指定するビットレートとを含むセグメント要求信号を生成し、アクセスクライアント１０８およびネットワーク１０４を介して配信サーバに送信する。配信サーバは、受信したセグメント要求信号で指定されるビットレートのセグメントファイルをクライアント装置１０６に送信する。メディアエンジン１１０は、ネットワーク１０４における輻輳の度合いを示す輻輳値を伴うセグメントファイルをネットワーク１０４を介して取得する。バッファ１３６は取得されたセグメントファイルを保持する。
【００２４】
図１に示されるように、本実施の形態ではセグメントファイルはコンテンツのソースである配信サーバ（ノード７）からクライアント装置（ノード１〜４）へ複数のリンクを通じて伝送される。輻輳値は、該輻輳値を伴うセグメントファイルが通過する複数のリンクのそれぞれにおける輻輳プライスの累計である。例えば、ノード１がノード７から取得するセグメントファイルに対応する輻輳値は、ノード７とノード５との間のリンクの輻輳プライスλ７，５と、ノード５とノード１との間のリンクの輻輳プライスλ５，１と、の和である（λ７，５＋λ５，１）。ソースである配信サーバは輻輳値を初期化する、すなわち輻輳値としてゼロを設定する。そして、配信サーバは対応するセグメントファイルをノード１に向けて送信する際に輻輳値をλ７，５に更新する。該セグメントファイルを受信したノード５は、ノード１へ該セグメントファイルを転送する際に、輻輳値にλ５，１を加算する。すなわち、セグメントファイルの伝送経路上にある各ノードにおいて、セグメントファイルを転送する際に輻輳値に送り先のリンクの輻輳プライスが加算される。輻輳プライスは例えばキュー遅延（queuing delay）や呼損率（loss probability）であってもよく、またはそのいずれかに関連するパラメータであってもよい。
【００２５】
輻輳情報処理部１２８は、取得された輻輳値を伴うセグメントファイルから輻輳値を抽出する。輻輳情報処理部１２８は、異常値を除去するために、抽出された輻輳値にローパスＥＷＭＡ（Exponentially Weighted Moving Average）を行う。より具体的には、輻輳情報処理部１２８は、ｔ番目（ｔは１より大きくＮより小さい自然数）のセグメントのセグメントファイルと共に取得された輻輳値ｑ（ｔ）から、以下の式（１）にしたがいフィルタされた輻輳値Ｑ（ｔ）を算出する。
Ｑ（ｔ）＝β・Ｑ（ｔ−１）＋（１−β）・ｑ（ｔ）      …（１）
ここで、βは０以上で１より小さい定数である。
【００２６】
基準レート算出部１３０は、輻輳情報処理部１２８からフィルタされた輻輳値Ｑ（ｔ）を取得し、取得された輻輳値Ｑ（ｔ）に基づいてビットレートの基準値ｘ（ｔ＋１）を算出する。基準レート算出部１３０は、基準値ｘ（ｔ＋１）の算出に際して、クライアント装置１０６におけるサービス品質（Quality of Service）とビットレートとの関係を示すユーティリティ関数（Utility Function）Ｕ（ｘ）に、輻輳値Ｑ（ｔ）をサービス品質の指標として適用する。より具体的には、基準レート算出部１３０は、以下の式２にしたがい基準値ｘ（ｔ＋１）を算出する。
【数１】
2017220796.tif 000003
…（２）
ここで、［・］ｂａは関数ｍａｘ（ｍｉｎ（・、ｂ）、ａ）を表す。また、Ｍはクライアント装置１０６が要求しうるビットレートの最大値、ｍはクライアント装置１０６が要求しうるビットレートの最小値であり、それぞれクライアント装置１０６の性能、特性により決まる。例えば、配信サーバにおいて０．１Ｍｂｐｓ、０．３５Ｍｂｐｓ、０．７Ｍｂｐｓ、１．３Ｍｂｐｓ、２．８Ｍｂｐｓ、４．５Ｍｂｐｓの６種類のビットレートのセグメントファイルが利用可能であっても、クライアント装置１０６のデコーダが３．０Ｍｂｐｓまでしか対応できない場合、Ｍは２．８Ｍｂｐｓとなる。
【００２７】
上記の式２は、ネットワークリソースをユーザ間で公平に利用することを目指して設定される。特に、式２はユーティリティ公平フレームワーク（Utility Faireness Framework）を使用して決定される。ユーティリティ公平フレームワークについては非特許文献３に詳述されているので、本明細書では説明を省略する。
【００２８】
図４は、ユーティリティ関数Ｕ（ｘ）の一例を示すグラフである。グラフの横軸はビットレートｘを示し、縦軸はサービス品質の指標を示す。破線はユーティリティ関数Ｕ（ｘ）を示す。ユーティリティ関数Ｕ（ｘ）は階段関数Ｖ（ｘ）を、マルチレベルシグモイド関数で近似する。階段関数Ｖ（ｘ）の各ステップは、次に要求するセグメントに対して指定可能な異なる複数のビットレート（３００ｋｂｐｓ、１．２Ｍｂｐｓ、５Ｍｂｐｓ）のひとつに対応する。
【００２９】
より一般的には、Ｋを次に要求するセグメントに対して指定可能な異なる複数のビットレートの数、ｒ１＜ｒ２＜…＜ｒＫを次に要求するセグメントに対して指定可能な異なる複数のビットレートのそれぞれ、とするとき、マルチレベルロジスティック関数を使用した近似により得られるユーザｎについてのユーティリティ関数Ｕｎ（ｘ）は、
【数２】
2017220796.tif 000004
…（３）
のように表される。
ｙをユーティリティ値とするとき、上記のユーティリティ関数の逆関数Ｕ−１ｎ（ｙ）は、
【数３】
2017220796.tif 000005
…（４）
のように表される。
なお、他のタイプのアプリケーションは異なる形状のユーティリティ関数を有する。例えば、ＦＴＰやＷｅｂアプリケーションは一般に対数関数的なユーティリティ関数を有する。
【００３０】
図３に戻り、フィルタ部１３２は、ビットレート決定のために使用するビットレートの基準値から揺動成分を除去するために、基準レート算出部１３０によって算出された基準値ｘ（ｔ＋１）にローパスＥＷＭＡを行う。より具体的には、フィルタ部１３２は、基準レート算出部１３０によって算出された基準値ｘ（ｔ＋１）から、以下の式（５）にしたがいフィルタされた基準値Ｘ（ｔ＋１）を算出する。
Ｘ（ｔ＋１）＝（１−α）・Ｘ（ｔ）＋α・ｘ（ｔ＋１）      …（５）
ここで、αは０より大きく１以下の定数である。
【００３１】
αを１に設定することで、フィルタ部１３２を無効化することができる。基準レート算出部１３０により算出される基準値が速く収束する場合、αを１に設定してもよいし、フィルタ部１３２を設けなくてもよい。
【００３２】
ビットレート決定部１３４は、フィルタ部１３２によって算出されたフィルタされた基準値Ｘ（ｔ＋１）にしたがい、次に要求するセグメントについて指定するビットレートを決定する。ビットレート決定部１３４は、ビットレートの決定の際、フィルタされた基準値Ｘ（ｔ＋１）と次に要求するセグメントに対して指定可能な異なる複数のビットレートとを比較する。より具体的には、ビットレート決定部１３４は、次に要求するセグメントに対して指定可能な異なる複数のビットレートのなかから、フィルタされた基準値Ｘ（ｔ＋１）以下であり、かつそれに最も近いビットレートを選択する。すなわち、低い方から数えてｐ番目のビットレートｒｐが選択された場合、
ｒｐ≦Ｘ（ｔ＋１）＜ｒｐ＋１    …（６）
が成立する。
【００３３】
要求スケジュール部１３８は、バッファ１３６の残量が最小値Ｂｍｉｎと最大値Ｂｍａｘとの間になるように、次にセグメントを要求するタイミングを制御する。要求スケジュール部１３８は、現在のバッファ１３６の残量ＢがＢｍａｘを下回っている場合、ビットレート決定部１３４によってビットレートが決定されるとすぐにセグメント要求部１２６に次のセグメントを要求させる。現在のバッファ１３６の残量ＢがＢｍａｘ以上である場合、要求スケジュール部１３８はΔｔ（＝Ｂ−Ｂｍａｘ＋τ）の間、次のセグメントの要求を延期する。ここで、Ｂ、Ｂｍａｘ、Ｂｍｉｎの単位はいずれも再生長であり、τは１セグメントの再生長である。
【００３４】
以上の構成によるクライアント装置１０６の動作を説明する。
図５は、クライアント装置１０６における一連の処理を示すフローチャートである。クライアント装置１０６はネットワーク１０４を介して配信サーバから、セグメントファイルおよびそれに伴う輻輳値を取得する（Ｓ５０２）。クライアント装置１０６は取得した情報から輻輳値を抽出する（Ｓ５０４）。クライアント装置１０６は抽出された輻輳値を平滑化する（Ｓ５０６）。クライアント装置１０６は、ネットワークリソースの利用についてユーザ間の公平を実現するよう設定された計算式を用いて、輻輳値からビットレートの基準値を算出する（Ｓ５０８）。クライアント装置１０６は、得られた基準値をＥＷＭＡにより平滑化する（Ｓ５１０）。クライアント装置１０６は、基準値から次に要求するセグメントのビットレートを決定する（Ｓ５１２）。クライアント装置１０６は、現在のバッファ残量Ｂと最大値Ｂｍａｘとを比較する（Ｓ５１４）。Ｂ≧Ｂｍａｘの場合（Ｓ５１４のＹＥＳ）クライアント装置１０６はΔｔだけ待機する（Ｓ５１６）。ステップＳ５１６の待機の後、またはＢ＜Ｂｍａｘの場合（Ｓ５１４のＮＯ）、クライアント装置１０６はネットワーク１０４を介して、決定されたビットレートを指定して次のセグメントを配信サーバに要求する（Ｓ５１８）。
【００３５】
上述の実施の形態について、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。
【００３６】
本実施の形態に係るクライアント装置１０６によると、輻輳についてのフィードバックである輻輳値を利用して、ユーティリティ公平フレームワークにしたがい公平なビットレート基準値が決定される。したがって、多くのクライアント装置が輻輳フィードバックのガイドの下で協調して動作するので、公平さを担保することができ、またシステム全体のユーティリティを最大化することができる。
【００３７】
また、本実施の形態に係るクライアント装置１０６によると、多くのユーザの間でサービス品質と公平さを最適化することができる。特に、複数のユーザがネットワークのボトルネックを共有する場合、それらのユーザにおける輻輳値はボトルネックにおける輻輳プライスが支配的となり、同等となる。したがってそれらのユーザの間での公平さを担保することができる。
【００３８】
また、本実施の形態に係るクライアント装置１０６では、マルチレベルシグモイド関数がユーティリティ関数として使用される。マルチレベルシグモイド関数は階段関数よりもビットレートの増大に対してより保守的なので、バッファ１３６のアンダーラン（underrun）が発生する確率をより低減できる。
【００３９】
また、本実施の形態に係るクライアント装置１０６によると、同じまたは同様な経路でセグメントファイルを受信する複数のクライアント装置が指定する次のセグメントのビットレートは同じになる場合が多くなる。したがって、その経路上に設けられたキャッシュに要求される容量を低減することができる。例えば、図１に示されるトポロジにおいて、ノード２、３、４が同時にノード７から同じコンテンツを要求する場合を考える。ノード２、３、４における輻輳値はそれぞれ（λ７，６＋λ６，２）、（λ７，６＋λ６，３）、（λ７，６＋λ６，４）である。キャッシュであるノード６からノード２、３、４へのリンクの輻輳プライスλ６，２、λ６，３、λ６，４が同等である場合、各ノード２、３、４における輻輳値も同等となり、したがって指定されるビットレートも同じになる。この場合、キャッシュ（ノード６）は指定される同じビットレートのセグメントファイルのみをキャッシュすればよいので、指定されるビットレートがばらばらの場合と比較して必要な容量を低減できる。
【００４０】
また、本実施の形態に係るクライアント装置１０６ではユーティリティ公平フレームワークが使用される。該フレームワークは非弾性的アプリケーション（例えば、ストリーミング）および弾性的アプリケーション（例えば、ＦＴＰ、Ｗｅｂ、ダウンロード）が混ざったネットワークをサポートしている。したがって、配信システム１００もまたそのようなネットワークをサポートできる。
【００４１】
以上、実施の形態に係るクライアント装置１０６の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。
【００４２】
実施の形態では、輻輳値に基づいてビットレートの基準値が算出される場合について説明したが、これに限られず、ネットワークにおける輻輳の度合いを示す輻輳情報に基づいて次に要求するセグメントのビットレートを決定してもよい。この場合、輻輳情報は複数のリンクのそれぞれにおける輻輳プライスの累計を反映してもよい。あるいはまた、輻輳情報は、ＴＣＰ／ＩＰの拡張機能であるＥＣＮ（Explicit Congestion Notification）などのネットワークにおける輻輳の状況を示す情報を含んでもよい。
【００４３】
実施の形態では、輻輳プライスの累計の始点を配信サーバ（ソース）とする場合について説明したが、これに限られず、例えばキャッシュを累計の始点としてもよい。
【００４４】
実施の形態に係る配信システム１００はＨＴＴＰ（Hypertext Transfer Protocol）環境で実装されてもよい。あるいはまた、配信システム１００はＵＤＰ（User Datagram Protocol）環境やＣＣＮ（Content-Centric Networks）環境で実現されてもよい。
【符号の説明】
【００４５】
１００  配信システム、  １０４  ネットワーク、  １０６  クライアント装置、  １０８  アクセスクライアント、  １１０  メディアエンジン、  １１２  制御エンジン。
【図１】
2017220796.tif 000006
【図２】
2017220796.tif 000007
【図３】
2017220796.tif 000008
【図４】
2017220796.tif 000009
【図５】
2017220796.tif 000010