| 【発明の名称】 |
プロキシサーバ及びプロキシ制御プログラム |
| 【発明者】 |
【氏名】小林 正好
【住所又は居所】東京都港区芝五丁目７番１号 日本電気株式会社内
【氏名】蔵杉 俊康
【住所又は居所】東京都港区芝五丁目７番１号 日本電気株式会社内
|
| 【要約】 |
【課題】ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑え実現する。
【解決手段】本発明のストリームプロキシサーバは、ネットワーク情報収集手段と、フロー制御機能を持ち、異なる帯域共有特性を持った複数のトランスポート層プロトコルを用いたデータ送受信が出来るトランスポート層プロトコル制御手段と、トランスポート層プロトコル制御手段から決められたレートでデータを読み出す受信レート制御手段と、ネットワーク情報収集手段から得られる情報とバッファ余裕に基づいて、オリジンサーバからのコンテンツの取得レートと使用するトランスポート層プロトコルを決定して受信レート制御手段へ決定したレートを通知し、トランスポート層プロトコル制御手段へ使用するトランスポート層プロトコルを通知する、先読み制御手段とを持つ。 |
【特許請求の範囲】
【請求項１】 コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得レートを、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に応じて制御することを特徴とするプロキシサーバ。
【請求項２】 コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択することを特徴とするプロキシサーバ。
【請求項３】 前記オリジンサーバからのコンテンツの取得を、フロー制御の機能を備えるプロトコルを用いて行い、前記オリジンサーバからのコンテンツ取得レートの制御を、前記プロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項４】 前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、フロー制御の機能を備える帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツ取得レートの制御を、前記プロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項５】 前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することによって実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項６】 前記オリジンサーバからのコンテンツの取得を、帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することにより実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項７】 前記オリジンサーバからのコンテンツ取得レートを、前記コンテンツ又はクライアントに対して設定された優先度も考慮して決定することを特徴とする請求項１、３、４、５、６のいずれか一つに記載のプロキシサーバ。
【請求項８】 コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシサーバにおいて、前記バッファに蓄積されているコンテンツの残り時間を検出し、前記残り時間が閾値以下になったタイミングで、該コンテンツの現在のバッファ蓄積位置より後続の前記コンテンツ部分を前記オリジンサーバから取得することを特徴とするプロキシサーバ。
【請求項９】 前記後続のコンテンツ部分の取得の間に優先度を設け、前記優先度の低い取得を中止することでボトルネックリンクの帯域使用幅が基準値を上回らないように調整することを特徴とする請求項８に記載のプロキシサーバ。
【請求項１０】 前記優先度を、前記クライアントによるコンテンツの視聴位置と前記バッファの蓄積位置の差に基づいて設定することを特徴とする請求項９に記載のプロキシサーバ。
【請求項１１】 前記優先度を、前記コンテンツが蓄積されているオリジンサーバ、コンテンツを配信するクライアント、取得を行うコンテンツの少なくとも何れか毎に設定することを特徴とする請求項９に記載のプロキシサーバ。
【請求項１２】 コンテンツの一部をバッファに蓄積し、該バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシサーバにおいて、前記バッファに蓄積されているコンテンツの残り時間が指定された時刻に閾値以下になることを予測することにより、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得することを特徴とするプロキシサーバ。
【請求項１３】 通信速度の異なる複数のデータ送受信手段を使い分けることにより、指定された時刻にバッファに蓄積されているコンテンツの残り時間が指定された値を上回るように該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得することを特徴とする請求項８、９、１０、１１、１２の何れかひとつに記載のプロキシサーバ。
【請求項１４】 通信速度の異なる複数のデータ送受信手段として優先制御を備えるプロトコルを利用すること特徴とする請求項１３に記載のプロキシサーバ。
【請求項１５】 通信速度の異なる複数のデータの送受信手段として異なるトランスポート層プロトコルを使い分けることを特徴とする請求項１３に記載のプロキシサーバ【請求項１６】 該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分を前記オリジンサーバから取得するタイミングを決定する閾値を、前記オリジンサーバとの間のネットワークの輻輳状況の変化に合わせて動的に更新することを特徴とする請求項８から請求項１５の何れか一つに記載のプロキシサーバ。
【請求項１７】 コンテンツの一部または全部を記憶装置に格納し、該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を持つプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に応じて選択することを特徴とするプロキシサーバ。
【請求項１８】 前記オリジンサーバからのコンテンツの取得を、フロー制御と送信レート制御機能を備えるプロトコルを用いて行い、前記オリジンサーバからのコンテンツ取得レートの制御を、前記フロー制御と送信レート制御機能を備えるプロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項１９】 前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を備えるプロトコルを、フロー制御の機能を持つ帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツ取得レートの制御を、送信制御機能を備えるプロトコルの受信バッファからコンテンツを読み出すレートを制御することで実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項２０】 前記オリジンサーバからのコンテンツの取得を、帯域共有特性の異なる複数の種類の送信レート制御機能を備えるプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することで実現することを特徴とする請求項１に記載のプロキシサーバ。
【請求項２１】 前記受信バッファの状態は、目標として設定したバッファ余裕と現在のバッファ余裕との差を用いることを特徴とする請求項１に記載のプロキシサーバ。
【請求項２２】 前記目標として設定されるバッファ余裕は、ネットワークの状況に応じて変化させることを特徴とする請求項２１に記載のプロキシサーバ。
【請求項２３】 同一配信対象であるコンテンツのための先読みを複数同時に実行することを特徴とする請求項８から請求項１５の何れか一つに記載のプロキシサーバ。
【請求項２４】 同一配信対象であるコンテンツのための先読みにおいて、それぞれ異なる部分の複数の要求として先読みを同時に実行することを特徴とする請求項８から請求項１５の何れか一つに記載のプロキシサーバ。
【請求項２５】 ネットワークの輻輳を招かない範囲で同一配信対象であるコンテンツのための先読みを複数同時に実行することを特徴とする請求項８から請求項１５の何れか一つに記載のプロキシサーバ。
【請求項２６】 ネットワークの輻輳を招かない範囲で同一配信対象のための先読みにおいて、それぞれ異なる部分の複数の要求として同時に実行することを特徴とする請求項８から請求項１５の何れか一つに記載のプロキシサーバ。
【請求項２７】 コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得レートを、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に応じて制御する機能を有することを特徴とするプロキシ制御プログラム。
【請求項２８】 コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択する機能を有することを特徴とするプロキシ制御プログラム。
【請求項２９】 コンピュータ上で実行され、コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシ制御プログラムにおいて、前記バッファに蓄積されているコンテンツの残り時間を検出し、前記残り時間が閾値以下になったタイミングで、該コンテンツの現在のバッファ蓄積位置より後続の前記コンテンツ部分を前記オリジンサーバから取得する機能を有することを特徴とするプロキシ制御プログラム。
【請求項３０】 コンピュータ上で実行され、コンテンツの一部をバッファに蓄積し、該バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシ制御プログラムにおいて、前記バッファに蓄積されているコンテンツの残り時間が指定された時刻に閾値以下になることを予測することにより、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得する機能を有することを特徴とするプロキシ制御プログラム。
【請求項３１】 コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を持つプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に応じて選択する機能を有することを特徴とするプロキシ制御プログラム。
|
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、コンテンツの一部または全部を記憶装置に溜め、そこからクライアントにコンテンツをストリーム配信しながら、該コンテンツの保持していないコンテンツ断片をオリジンサーバから取得して記憶装置に追加するストリームプロキシサーバに関し、特にネットワークを流れる他のトラヒックへの影響を抑えてオリジンサーバからのコンテンツの取得を実現するストリームプロキシサーバおよびネットワーク技術に関する。
【従来の技術】図３４に従来のストリームプロキシサーバを用いたネットワークの構成図を示す。従来のストリームプロキシサーバ200は、クライアント100-1〜100-nのn台のクライアントに対して、m台のオリジンサーバ400-1〜400-mの保持するコンテンツについてn本のストリームプロキシサービスを行っているものとする。またプロキシサーバと、オリジンサーバ400-1〜400-mへはルータ300、リンク700、ネットワーク500を経由して接続されているとする。リンク700には、ネットワーク500と600の間のトラヒックも流れている。
【０００２】ストリーム配信とは、クライアント100-1〜100-nから要求のあったコンテンツについて、クライアントから要求されたコンテンツ内の位置から、要求された速度（配信レート）でコンテンツをクライアントに送信する事である。ストリーミングによって、クライアント100-1〜100-nは、受け取ったコンテンツの部分から順にコンテンツを再生（あるいは利用）する事によって、コンテンツ全体を受け取るまで待つ必要がなくなり、再生を開始するまでの時間が短縮出来る。
【０００３】ストリームプロキシサービスとは、ネットワーク内の要素C（例えば、クライアント100-1〜100-n）からの視聴リクエストを受け取り、視聴リクエストのあったコンテンツについて、ストリームプロキシサーバ200が保持している部分については、ストリームプロキシサーバ200自身から、保持していない部分については、コンテンツを保持しているネットワーク内の要素S（例えば、オリジンサーバ400-1〜400-m）から取得して、ネットワーク内の要素C（例えば、クライアント100-1〜100-n）に対して、コンテンツをストリーム配信するサービスである。ネットワーク内の要素S(例えば、オリジンサーバ）から取得したコンテンツについては、ストリームプロキシサーバ200は一部または全部を記憶装置に保存しておく。次回同じコンテンツへ、ネットワーク内の要素C（例えば、クライアント100-1〜100-n）からの視聴リクエストがあった場合に、保存した部分についてはネットワーク内の要素S(例えば、オリジンサーバ）から取得する事をせず、自身の記憶装置から読み出して要素C（例えば、クライアント）にストリーミングでコンテンツ配信する。ネットワーク内の要素Cとして、ストリーミング配信を行うオリジンサーバをとり、ネットワーク内の要素Sとして、ディスク装置をとる事も可能である。
【０００４】図３５に、従来のストリームプロキシサーバ200の内部構成図を示す。各構成要素を説明する。
【０００５】ストリーム配信制御部201は、クライアントからのコンテンツの視聴リクエストを受け取り、視聴要求のあったコンテンツを記憶部204から読み出してクライアントへとストリーム配信する機能を持つ。また、視聴リクエストを、先読み制御部202へと伝える機能も持つ。
【０００６】先読み制御部202は、ストリーム配信制御部201から、視聴リクエストを受け取り、クライアントから視聴リクエストがあったコンテンツに関して、記憶部204に保持していないコンテンツ断片（コンテンツの全部又は一部分）がある場合には、オリジンサーバとのコネクションをトランスポート層制御部205へ指示して開設する。また、コンテンツ取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）を、前記の開設したコネクション上に送信する（トランスポート層制御部が提供する、書き込みのインターフェースを使う）。サーバは、同コネクションに、該当コンテンツ断片を送り返してくるので、先読み制御部202はこれを同コネクションから読み出して（トランスポート層制御部が提供する、読み出しのインターフェースを使う）、記憶部204へと書き込む。コンテンツ断片は記憶装置の容量が許す限り書き込まれるが、容量がなくなった場合、コンテンツの中ですでに配信が終わっている部分を削除し、書き込む容量を確保する。
【０００７】記憶部204は、オリジンサーバのコンテンツの一部または全部のコピーを保存している。ストリームの任意の位置への書き込みと、任意の位置からの読み出しのインターフェース、および、各コンテンツについて保持している位置情報を、ストリーム配信制御部、先読み制御部へ提供する。
【０００８】トランスポート層制御部205は、トランスポート層プロトコル（例えばTCP)を使ったデータ通信を制御する部分である。先読み制御部202からの指示に従って、オリジンサーバとのコネクションの開設、切断、およびデータ送受信に必要なトランスポート層の終端処理（例えばトランスポート層がTCPならTCPの送受信のプロトコル処理）を行う。また、開設した各コネクションについて、先読み制御部からのデータの読み出し、書き込みのインターフェースを持つ。
【０００９】次に、従来のストリームプロキシサーバの動作の概要を説明する。クライアントが送信する視聴リクエストには、視聴初期化（コンテンツ識別子が指定される）、視聴開始(コンテンツ内での位置が指定される、例えば再生時間での先頭から何秒目などを指定する）、視聴停止、視聴終了、が含まれる。視聴の際、クライアントは、まず「視聴初期化」の視聴リクエストをストリームプロキシサーバに送信し、ストリームプロキシサーバと、クライアントとの間に、リクエスト内のコンテンツ識別子で指定されたコンテンツの配信サービスのためのコネクションを開設する。ストリームプロキシサーバは、その後、「視聴開始」（任意の開始位置と配信レートが指定出来る）や、「視聴停止」（一時停止）、の視聴リクエストを使ってコンテンツ視聴を行い、視聴を終えると、「視聴終了」の視聴リクエストでストリームプロキシサーバに視聴を終える旨を通知する。
【００１０】図３６に、前記の視聴リクエストを利用した典型的なコンテンツ視聴のタイミングチャートを示す。図３６の例では、クライアントはコンテンツの最初から視聴開始し、最後まで見終わってから視聴終了するとする。また、リクエストされたコンテンツの先頭部分(0秒〜Ta秒）、コンテンツの途中部分(Tb秒〜Tc秒）をストリームプロキシサーバが保持しているとする。
【００１１】図３７にこの例でのストリームプロキシサーバが保持しているコンテンツの位置を示す。現在クライアントに対して送信を行っている位置（配信位置）から、それ以降のコンテンツ部分で最初に記憶部に保持していないコンテンツの位置を送信するまでの時間的な差を、視聴の（あるいは、クライアントをターゲットとする）ストリームバッファ余裕（あるいはバッファ余裕）と呼ぶ。例えば、あるコンテンツについて、記憶部に保持されている部分が、図３７のような場合で、現在の配信位置がT1ならストリームバッファ余裕はTa−T1秒、現在の視聴位置がT2なら、ストリームバッファ余裕は0秒である。
【００１２】図３６には、ストリームプロキシサーバが、リクエストされたコンテンツの保持している以外の部分（Ta〜Tb秒、および、Tc〜Td秒）をオリジンサーバから取得しながら、クライアントへとストリーミングでコンテンツ配信している様子を示している。以下、この動作を説明する。図３６のXT-10において、クライアントが、「視聴初期化」のリクエストをプロキシサーバに送り、ストリーム配信のためのコネクションが、クライアントとストリームプロキシサーバとの間に開設される。次に、XT-20において、クライアントは「視聴開始」（位置は先頭(0秒)からとする。配信レート(Kbps等)も指定される）の視聴リクエストを送ってくるので、コンテンツスイッチは、記憶部に保持している該当コンテンツの指定された位置(0秒)から、ストリーム配信を開始する(XT-30)。また、オリジンサーバへ、コンテンツの保持している以外の部分を取得するために、コネクションを開設し(XT-40)、取得要求を出す(XT-50)。そしてサーバから後続のコンテンツ部分を取得し始める（XT-60)。取得は記憶部の容量が許す限り行われ、取得した部分は記憶部にためられてゆく。要求を出した取得が完了すると(XT-65)、現在の配信位置以降で保持していない部分があれば、さらに取得要求を出す(XT-70)。ストリームプロキシサーバは、オリジンサーバから、コンテンツを取得しながら(XT-63およびXT-73)、記憶装置に保持しているコンテンツ読み込んで、クライアントへとストリーム配信してゆく。このとき、コンテンツがまだ取得出来ていない場合（ストリームバッファ余裕が0秒になった場合）には、取得出来るまでの間（ストリームバッファ余裕が正の値になるまで）、配信は一時的に中断され、クライアントには視聴が不連続に飛ぶ（映像がとぎれる、あるいは、音がとぎれるなど）、視聴品質が低下する。クライアントは全コンテンツを取得し終えると、「視聴終了」の視聴リクエストを送り(XT-110)、ストリームプロキシサーバは、それを受けて、サーバとのコネクションを切断する(XT-120)。
【００１３】次に、図３６のタイミングチャートの中で、ストリーム配信制御部201、先読み制御部202、記憶部204、トランスポート層制御部205がどのように動作するのかを説明する。ストリーム配信制御部201は、クライアントからの視聴リクエストを受け取ると、それが「視聴終了」の場合、ストリーム配信を停止し、先読み制御部に該当コンテンツの識別子と視聴終了であることを通知する。「視聴初期化」の場合、記憶部204の該当コンテンツを検索し、記憶部内のアドレスを得る。みつからない場合、先読み制御部202へ指示して、記憶部204に記憶領域を確保させ、記憶部内のアドレスを通知してもらう。また、先読み制御部202に「視聴初期化」である事と、コンテンツの識別子を通知する。「視聴開始」の場合、指定された視聴開始位置が、記憶部内にある場合には、配信の先頭を指定された位置に調整する動作を行う。また、先読み制御部に、「視聴開始」である事を通知する。その後、記憶部からコンテンツを読み出してストリーム配信を行う。オリジンサーバからの取得が間に合わず、記憶部に読み出したいコンテンツの部分がない場合(バッファ余裕が0秒になった場合）には、その部分のコンテンツは配信されず、クライアントには、視聴が不連続に飛んだ（映像がとぎれる、あるいは、音がとぎれるなど）ようにみえる。また、ストリーム配信制御部201は、先読み制御部202からのリクエストに応じて、現在の視聴位置、現在のコンテンツ配信レートを返す事も行う。
【００１４】先読み制御部202では、ストリーム配信制御部から「視聴終了」の通知を受け取ると、該当のコンテンツに関してオリジンサーバとのコネクションを切断する。「視聴初期化」の場合には、該当コンテンツについて、トランスポート層制御部205へ指示して、オリジンサーバへとコネクションを張る処理を行う。また、「視聴初期化」の場合に、該当コンテンツが記憶部にない場合に記憶領域を確保してそのアドレスをストリーム配信制御部へと通知する。「視聴開始」の場合、視聴開始位置以降のコンテンツについて、記憶部内にない部分を、トランスポート層制御部を介してオリジンサーバから取得して、記憶部の容量が許す限り記憶部へ書き込む。記憶部の容量がなくなった場合、コンテンツの中ですでに配信が終わっている部分などを削除して容量を空ける動作を行う。
【００１５】
【本発明が解決しようとする課題】従来のストリームプロキシサーバでは、クライアントの視聴が始まると、保持していないコンテンツ部分をオリジンサーバから取得するが、現在の配信位置以降の部分の取得（以下、「先読み」と呼ぶ）については、実際にクライアントに配信を行うのは、配信位置がそこに達した時であり、取得の緊急度は低い。これに対して、一般にネットワークを流れるトラヒックには緊急度の高いものが含まれており、先読みは、これらのトラヒックより優先度を低くすべきである。例えば、図２７ではリンク700は、ネットワーク500と600の間の通信にも使われているが、従来のストリームプロキシサーバは、このリンク700の輻輳度を考慮していないため、ネットワーク500と600の間の通信によってこのリンクが輻輳している時に、先読みによって発生するトラヒックで、このリンク700をさらに輻輳させてしまう。
【００１６】また、従来のストリームプロキシサーバでは、オリジンサーバからのコンテンツ取得レートを制御しておらず、トランスポート層プロトコルが達成するデータ送信レートがコンテンツ取得レートとなっている。このため、同一ボトルネックを経由してオリジンサーバからの取得を行っている複数のコンテンツがある場合に、一時的にボトルネックが輻輳し、ボトルネックの空き帯域が、配信レートの合計を下回るような場合に、ストリームバッファ余裕の少ないものに対して、優先してオリジンサーバからのコンテンツ取得帯域を割り当てることが出来ず、ストリームバッファ余裕が0に達して視聴品質が悪化してしまう視聴が発生する確率が高い。
【００１７】例えば、同じ配信レートの2つのコンテンツ視聴に対して、ストリームプロキシサービスを行っている状況で、それぞれの視聴に対して、オリジンサーバから同一のボトルネックを経由して先読みを行っているとする。このとき、一時的にボトルネックが輻輳し、コンテンツ取得に使えるボトルネックの空き帯域が1つの配信レート分の空き帯域しかない状況になったとする。また、このとき2つの視聴の、バッファ余裕が1秒と100秒だったとする。従来のストリームプロキシサーバでは、空き帯域を2つの先読みによって均等に配分するため、各コンテンツ取得は、配信レートの半分のレートでオリジンサーバからの取得を行う事になる。このため、2秒後に片方の視聴のストリームバッファ余裕が0となり、その視聴の視聴品質が悪化してしまう。もし、100秒のストリームバッファ余裕がある視聴について、オリジンサーバからの取得を一時的に停止し、1秒のストリームバッファ余裕の視聴について、オリジンサーバからの取得帯域を割り当てれば、いずれかの視聴のストリームバッファ余裕が0になるまでの時間を延ばすことが出来、それまでの間に一時的な輻輳が解消すれば、クライアントの視聴品質の悪化をなくすことが可能であるが、従来のストリームプロキシサーバではこれは出来ない。
【００１８】また、バッファ余裕以外の要因（視聴しているクライアントやコンテンツなど）に依存して、取得レートを決定する事を行う事が出来ない。このため、特定のクライアントやコンテンツについての取得レートをより高く設定して、そのクライアントやコンテンツの視聴品質の悪化を防ぐという事が出来ない。
【００１９】本発明の第１の目的は、ネットワークを流れる他のトラヒックへの影響を極力抑えてオリジンサーバからのコンテンツの取得を実現することができるプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２０】本発明の第２の目的は、オリジンサーバからのコンテンツ取得レートを制御し、同一のボトルネックを共有するコンテンツの間で帯域の割り当て制御を行うことにより、視聴品質の悪化が起こる可能性を極力抑えることを可能としたプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２１】本発明の第３の目的は、オリジンサーバからのコンテンツ取得レートを制御することにより、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を最小限に抑えることを可能とするプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２２】
【課題を解決するための手段】本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得レートを、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に応じて制御することを特徴とする。
【００２３】請求項２の本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択することを特徴とする。
【００２４】請求項３の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得を、フロー制御の機能を備えるプロトコルを用いて行い、前記オリジンサーバからのコンテンツ取得レートの制御を、前記プロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする。
【００２５】請求項４の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、フロー制御の機能を備える帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツ取得レートの制御を、前記プロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする。
【００２６】請求項５の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することによって実現することを特徴とする。
【００２７】請求項６の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得を、帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することにより実現することを特徴とする。
【００２８】請求項７の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツ取得レートを、前記コンテンツ又はクライアントに対して設定された優先度も考慮して決定することを特徴とする。
【００２９】請求項８の本発明のプロキシサーバは、コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシサーバにおいて、前記バッファに蓄積されているコンテンツの残り時間を検出し、前記残り時間が閾値以下になったタイミングで、該コンテンツの現在のバッファ蓄積位置より後続の前記コンテンツ部分を前記オリジンサーバから取得することを特徴とする【００３０】請求項９の本発明のプロキシサーバは、前記後続のコンテンツ部分の取得の間に優先度を設け、前記優先度の低い取得を中止することでボトルネックリンクの帯域使用幅が基準値を上回らないように調整することを特徴とする。
【００３１】請求項１０の本発明のプロキシサーバは、前記優先度を、前記クライアントによるコンテンツの視聴位置と前記バッファの蓄積位置の差に基づいて設定することを特徴とする。
【００３２】請求項１１の本発明のプロキシサーバは、前記優先度を、前記コンテンツが蓄積されているオリジンサーバ、コンテンツを配信するクライアント、取得を行うコンテンツの少なくとも何れか毎に設定することを特徴とする。
【００３３】請求項１２の本発明のプロキシサーバは、コンテンツの一部をバッファに蓄積し、該バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシサーバにおいて、前記バッファに蓄積されているコンテンツの残り時間が指定された時刻に閾値以下になることを予測することにより、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得することを特徴とする。
【００３４】請求項１３の本発明のプロキシサーバは、通信速度の異なる複数のデータ送受信手段を使い分けることにより、指定された時刻にバッファに蓄積されているコンテンツの残り時間が指定された値を上回るように該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得することを特徴とする。
【００３５】請求項１４の本発明のプロキシサーバは、通信速度の異なる複数のデータ送受信手段として優先制御を備えるプロトコルを利用すること特徴とする。
【００３６】請求項１５の本発明のプロキシサーバは、通信速度の異なる複数のデータの送受信手段として異なるトランスポート層プロトコルを使い分けることを特徴とする。
【００３７】請求項１６の本発明のプロキシサーバは、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分を前記オリジンサーバから取得するタイミングを決定する閾値を、前記オリジンサーバとの間のネットワークの輻輳状況の変化に合わせて動的に更新することを特徴とする。
【００３８】請求項１７の本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシサーバにおいて、前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を持つプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に応じて選択することを特徴とする。
【００３９】請求項１８の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得を、フロー制御と送信レート制御機能を備えるプロトコルを用いて行い、前記オリジンサーバからのコンテンツ取得レートの制御を、前記フロー制御と送信レート制御機能を備えるプロトコルの受信バッファからコンテンツを読み出すレートを制御することにより実現することを特徴とする。
【００４０】請求項１９の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を備えるプロトコルを、フロー制御の機能を持つ帯域共有特性の異なる複数の種類のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツ取得レートの制御を、送信制御機能を備えるプロトコルの受信バッファからコンテンツを読み出すレートを制御することで実現することを特徴とする。
【００４１】請求項２０の本発明のプロキシサーバは、前記オリジンサーバからのコンテンツの取得を、帯域共有特性の異なる複数の種類の送信レート制御機能を備えるプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に基づいて選択し、前記オリジンサーバからのコンテンツの取得レートの制御を、前記オリジンサーバに送信レートを指示することで実現することを特徴とする。
【００４２】請求項２１の本発明のプロキシサーバは、前記受信バッファの状態は、目標として設定したバッファ余裕と現在のバッファ余裕との差を用いることを特徴とする。
【００４３】請求項２２の本発明のプロキシサーバは、前記目標として設定されるバッファ余裕は、ネットワークの状況に応じて変化させることを特徴とする。
【００４４】請求項２３の本発明のプロキシサーバは、同一配信対象であるコンテンツのための先読みを複数同時に実行することを特徴とする。
【００４５】請求項２４の本発明のプロキシサーバは、同一配信対象であるコンテンツのための先読みにおいて、それぞれ異なる部分の複数の要求として先読みを同時に実行することを特徴とする。
【００４６】請求項２５の本発明のプロキシサーバは、ネットワークの輻輳を招かない範囲で同一配信対象であるコンテンツのための先読みを複数同時に実行することを特徴とする。
【００４７】請求項２６の本発明のプロキシサーバは、ネットワークの輻輳を招かない範囲で同一配信対象のための先読みにおいて、それぞれ異なる部分の複数の要求として同時に実行することを特徴とする。
【００４８】請求項２７の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得レートを、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に応じて制御する機能を有することを特徴とする。
【００４９】請求項２８の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得に用いるプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況又は前記コンテンツの受信バッファの状態の少なくとも一方に基づいて選択する機能を有することを特徴とする。
【００５０】請求項２９の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシ制御プログラムにおいて、前記バッファに蓄積されているコンテンツの残り時間を検出し、前記残り時間が閾値以下になったタイミングで、該コンテンツの現在のバッファ蓄積位置より後続の前記コンテンツ部分を前記オリジンサーバから取得する機能を有することを特徴とする。
【００５１】請求項３０の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部をバッファに蓄積し、該バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得してバッファに追加するプロキシ制御プログラムにおいて、前記バッファに蓄積されているコンテンツの残り時間が指定された時刻に閾値以下になることを予測することにより、該コンテンツの現在のバッファ蓄積位置より後続のコンテンツ部分をオリジンサーバから取得する機能を有することを特徴とする。
【００５２】請求項３１の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシ制御プログラムにおいて、前記オリジンサーバからのコンテンツの取得に用いる送信レート制御機能を持つプロトコルを、異なる帯域共有特性を持つ複数のプロトコルの中から、ネットワーク状況と受信バッファの状態の少なくとも一方に応じて選択する機能を有することを特徴とする。
【００５３】
【作用】ネットワーク情報収集手段によって、ネットワークの残余帯域の情報を収集し、取得レート決定手段において、この残余帯域に基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５４】また、ネットワークがトランスポート層プロトコル決定手段によって、複数の異なる帯域共有特性を持つトランスポート層プロトコルから、ネットワークを流れる他のトラヒックへの影響の小さいトランスポート層プロトコルを決定し、複数の異なる帯域共有特性を持つトランスポート層プロトコルを用いたデータ送受信が出来るトランスポート層プロトコル制御手段を用いて、コンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５５】また、バッファ余裕測定手段によって、各コンテンツのバッファ余裕の大きさを求め、それに基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５６】また、指定優先度を考慮した取得レートを決定する手段によって、オリジンサーバからの取得レートを指定優先度も考慮して決定し、優先度の高い視聴に関してより高い取得レートを割り当て、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第３の目的である、ストリームプロキシサーバにおいて、指定優先度に従い、優先度の高い視聴に関して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５７】また、バッファ余裕に基づいてオリジンサーバからのコンテンツ取得要求を送出する先読み手段を用いることで、過剰な先読み要求の送出が抑制され、さらにコンテンツを部分的なコンテンツ断片として取得要求を行う先読み制御手段を用いてコンテンツを時間的に分割して取得することで、ネットワーク本発明の第１の目的である、オリジンサーバからのコンテンツ取得をネットワークに流れる他のトラヒックへの影響を抑えて実現することが可能となる。
【００５８】また、ネットワーク情報収集手段と、同時に実行される取得要求間の優先度を判別する手段と、優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制されることで、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００５９】また、優先度をバッファ余裕の大小で決定する手段とその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６０】また、優先度を要求が取得しようとするコンテンツを蓄積しているオリジンサーバにより決定する手段により、コンテンツが蓄積されているオリジンサーバを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６１】また、優先度を要求により獲得したコンテンツ断片のデータをストリーム配信するクライアントにより決定する手段により、配信対象となるクライアントを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６２】また、優先度を要求したコンテンツにより決定する手段により、コンテンツを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能である。
【００６３】また、バッファ余裕の変化を予測し、バッファ余裕が将来不足しそうな場合に、後続のコンテンツ断片の取得要求を送出する先読み制御手段により、より時間的な余裕を持った要求間での帯域の融通が可能となり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６４】また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段を使い分けて実行する手段により、ネットワークの輻輳を抑制した取得を選択できる可能性がより高くなり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６５】また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段として優先制御をもったネットワーク層プロトコルを利用する手段により、Diffserv等既存のプロトコルの採用することで比較的容易に本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６６】また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段として異なるトランスポート層プロトコルを使い分けて実行する手段により、TCP RenoとTCP Vegasを使い分けるなど既存のプロトコルを使い分けることで比較的容易に本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６７】また、後続のコンテンツ断片要求を送出する間隔をネットワーク状況に応じて調整する手段により、ネットワークの輻輳状況に応じて、先読みに伴うトラヒックの調整を行い、ネットワークの輻輳を抑制することで、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６８】また、同一配信対象のための先読みを複数同時に実行する手段と、ネットワークの輻輳を招かない適切な同時実行数を判断し同時実行数を制御する手段により、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、１人のクライアントをターゲットする取得要求を同時に複数実行することで空き帯域を活用した積極的な取得を実現し、より多くのクライアントが配信品質を維持するために十分なバッファ余裕を確保することが可能となる。
【００６９】
【本発明の実施の形態】（第１の実施の形態）図１に本発明の第１の実施の形態の構成を示す。ストリームプロキシサーバ20Aは、クライアント10-1〜10-nのn台のクライアントに対して、m台のオリジンサーバ40-1〜40-mの保持するコンテンツのについてn本のストリームプロキシサービスを行っているものとする。またストリームプロキシサーバ20Aと、オリジンサーバ40-1〜40-mは、ルータ30、リンク70とネットワーク50を経由して接続されているとする。リンク70には、ネットワーク50と60の間のトラヒックも流れている。クライアントが視聴リクエストを出す動作は、従来の技術で説明したものと同等とする。
【００７０】図２に本発明の第１の実施の形態のプロキシサーバ20Aの内部構成図を示す。
【００７１】ストリーム配信制御部201Aは、クライアントからのコンテンツの視聴リクエストを受け取り、視聴リクエストの合ったコンテンツを記憶装置から読み出してクライアントへとストリーム配信する機能を持つ。また、視聴リクエストを、先読み制御部202Aへと伝える機能も持つ。さらに、現在の配信位置、現在の配信レート情報を先読み制御部202Aへと伝える機能も持つ。
【００７２】先読み制御部202Aは、ストリーム配信制御部201Aから、視聴リクエストを受け取り、クライアントが視聴したいコンテンツに関して、現在の配信位置以降で、記憶部204Aに保持していないコンテンツ断片（コンテンツの全部又は一部分）がある場合には、オリジンサーバへのコネクションをトランスポート層制御部へ指示して開設し、コンテンツ取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）をトランスポート層制御部に出す。また、受信レート制御部206Aへ目標レートを指示する。この目標レートに従って、受信レート制御部206Aはトランスポート層制御部205Aからコンテンツを読み出す。また、先読み制御部202Aは、受信レート制御部206Aがトランスポート層制御部205Aから読み出したコンテンツを受け取る。受け取ったコンテンツは記憶部204Aへと書き込む。また、先読み制御部202Aは、コンテンツ取得要求で指定しなければならない、コンテンツ断片の位置（開始位置と終わり位置）、記憶部のコンテンツの中で削除する部分の決定も行う。さらに、オリジンサーバからのコンテンツ取得の目標レートは、記憶部204Aが保持しているコンテンツ断片の位置の情報、ストリーム配信制御部201Aから得られる現在の配信位置と配信レート、および、ネットワーク情報取得部207Aから得られる情報を基に決定する。この決定のアルゴリズムを「受信レート決定アルゴリズム」と呼ぶ。先読み制御部202Aの動作の詳細はフローチャートを使って後述する。また、「受信レート決定アルゴリズム」の詳細についても後述する。
【００７３】記憶部204Aは、オリジンサーバのコンテンツの一部または全部のコピーを保存している。ストリームの任意の位置への書き込みと読み出しのインターフェース、および、ストリームのどの位置を保持しているかの情報を、ストリーム配信制御部201A、先読み制御部202Aへ提供する。
【００７４】トランスポート層制御部205Aは、フロー制御機能を持つトランスポート層プロトコル（例えばTCP(Transport Control Protocol)）を使ったデータ通信を制御する部分である。フロー制御機能とは、受信者が、受信バッファの現在の空き状況を送信者へ伝え、送信者は伝えられた空き状況に基づいて送信レートを調節する事によって、受信側の受信バッファがあふれるのを防ぐ機能の事である。例えばTCPはこの機能を持っている。また、トランスポート層制御部205Aは、先読み制御部202Aからの指示に従って、オリジンサーバとのコネクションの開設、切断、およびデータ送受信に必要なトランスポート層の終端処理（例えばトランスポート層がTCPならTCPの送受信のプロトコル処理）を行う。また、開設した各コネクションについて、先読み制御部からのデータ書き込み、および、受信レート制御部からのデータの読み出し、の2つのインターフェースを持つ。
【００７５】受信レート制御部206Aは、先読み制御部202Aから指定される目標レートに従って、オリジンサーバから取得したコンテンツをトランスポート層制御部205Aから読み出し、先読み制御部202Aへと渡す。トランスポート層制御部205Aが用いるトランスポート層プロトコルはフロー制御機構を持つため、受信レート制御部206Aが、データの読み出しレートを目標レートに制限すると、オリジンサーバからのデータ転送レートの上限も、その読み出しレートに制限される。この原理を用い、データの読み出しレートを目標レートにすることによって、オリジンサーバからのデータ転送レートを目標レート以下に制御する事が出来る。
【００７６】ネットワーク情報取得部207Aは、先読み制御部からの指示に従い、先読み制御部へネットワーク情報（輻輳情報等の混み具合を表す情報）を通知する。ネットワーク情報とは、例えば、リンク70の現在の残余帯域情報（ネットワーク50からルータ30へ向かう方向の残余帯域情報）等のネットワークの混み具合を表す情報であり、一定時間毎に、リンク70に接続されているルータ30から、ルータ30のリンク70からの受信バイト数をSNMP(Simple Network Management Protocol)等を使って集め、転送バイト数を前記の一定時間で割る事で、使用帯域を求め、リンク70の物理帯域から使用帯域を減算する事によって求める事が出来る。このとき、SNMP等を使って集めた転送バイト数を何倍かして、70の物理帯域から使用帯域を減算することで、残余帯域情報を少な目に見積もる事を行ってもよい。この他にも、オリジンサーバへ試験パケットを送出してRTT(round trip time)を計測して、ボトルネック帯域を求める事も可能である。
【００７７】次に先読み制御部202Aの動作をフローチャート図３から図７を用いて説明する。
【００７８】先読み制御部202Aは、図示しないタイマー（設定された時間が経過すると信号を発生する装置）に設定された時間が経過した場合（あるいはカウンタによって設定された値を計数した場合）、あるいは、ストリーム配信制御部からの視聴リクエスト（視聴終了、視聴初期化、視聴開始、取得完了）によって、待ち状態から起動される。本実施の形態では、タイマーの時間であるタイマＴに所定の時間Ｔ０が設定されて起動され、タイマＴが０になると先読み制御部202Aが起動される。
【００７９】視聴リクエストが「視聴終了」であった場合、図３に示すように、該当視聴コンテンツを取得しているオリジンサーバとのコネクションを切断する指示をトランスポート層制御部205Aへ出す（ステップＡ１０）。
【００８０】視聴リクエストが「視聴初期化」の場合、図４に示すように、クライアントが視聴したいコンテンツに関して、記憶部204Aに保持していないコンテンツ断片がある場合には、オリジンサーバへコネクションをトランスポート層制御部へ指示して開設する（ステップＡ２０）。また、ストリーム配信制御部201Aから、記憶部に領域を確保する指示があれば、記憶領域を確保してアドレスをストリーム配信制御部201Aへと返す（ステップＡ３０）。
【００８１】視聴リクエストが「視聴開始」の場合、図５に示すように、コンテンツの中で現在視聴している位置以降で、保持していないコンテンツの部分から、取得する部分を決定し（ステップＡ４０）、取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）をトランスポート層制御部に指示する（ステップＡ５０）。また、タイマＴを「0」に設定し（ステップＡ６０）、タイマＴが「0」の場合の処理である、該当コンテンツへの目標レートの設定処理が実行されるようにする。
【００８２】視聴リクエストがコンテンツ断片の「取得完了」である場合、図６に示すように、タイマＴを「0」に設定し（ステップＡ７０）、タイマＴが「0」の場合の処理である、該当コンテンツへの目標レートの設定処理が実行されるようにする。そして、次に取得するコンテンツの位置を決定し（ステップＡ７０）、取得要求を送出する（ステップＡ８０）。
【００８３】タイマＴが「0」の場合、図７に示すように、現在オリジンサーバからコンテンツ取得を行っている全コンテンツについて、記憶部204Aが保持しているコンテンツ断片の位置の情報、ストリーム配信制御部から得られる現在の再生位置情報と視聴レート情報、および、ネットワーク情報取得部207Aから得られる情報を基に、そのコンテンツに関する目標取得レートを決定する（ステップＡ９０）。この決定アルゴリズムについては後述する。全コンテンツに対する目標レートが決まると、その値を受信レート制御部206Aに通知する（ステップＡ１００）。また、これ以降、受信レート制御部206Aが取得したコンテンツは先読み制御部202Aが受け取って、記憶部206Aへの書き込みを行う。この書き込み動作を実行しながら、タイマＴを規定値の時間「T0」にリセットし（ステップＡ１１０）、待ち状態となる。
【００８４】（受信レート決定アルゴリズム）次に、受信レート決定アルゴリズムを示す。
【００８５】まず以下を定義する。
（１）現時点での（新たに視聴開始するクライアントは加えず、視聴終了するクライアントは含める）視聴を行っているクライアントの集合を、ｐＭ＝｛ｐＭ１，ｐＭ２，．．．，ｐＭｍ｝とする。
（２）ｐＭに新たな視聴を開始するクライアントを加え、視聴を終了するクライアントを除いたクライアントの集合をＭ＝｛Ｍ１，Ｍ２，．．．，Ｍｎ｝とする。
（３）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）への、時刻tでの配信レートをｒｉ（ｔ） bps(bit per second)とする。
（４）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に対する、時刻tでのストリームバッファ余裕（バッファ余裕とも呼ぶ）を、ｂｉ（ｔ）秒とする。
（５）時刻tでの、クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴の為に行う、オリジンサーバからのコンテンツ取得（先読み）のレートの目標値（目標レート）をｇｉ（ｔ）とする。
（６）時刻tでの、クライアントｐＭｉ（ｉ＝１，２，．．．，ｍ）の視聴のために行う、オリジンサーバからのコンテンツ取得（先読み）の実際の取得レートをｇｉ＊（ｔ）とする。
（７）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に対する、現在の目標のバッファ余裕をＴｈｉＶ（ｔ）とする。ＴｈｉＶ（ｔ）はクライアントの再生の飛びが生じる確率が許容範囲内に納めるために必要なストリームプロキシサーバのバッファ余裕である。この値は、経験値として固定的に与えてもよいし、動的に決定してもよい。例えば、過去のコンテンツ取得レートｇｉ＊（ｔ）の履歴と配信レートｒｉ（ｔ）の履歴から、視聴開始時からのｒｉ（ｔ）−ｇｉ＊（ｔ）の積分値の履歴を求め、その最大値（すなわち、過去で最もバッファ余裕が少なくなった状況を救うバッファ余裕としている）等に決めてもよい。あるいは、以下のステップ４において、Ａ（ｔ）−Ｐ（ｔ）＞０の状態が続けば、ボトルネックの使用可能帯域が余っている事を意味するので、ＴｈｉＶ（ｔ）を増加させ、Ａ（ｔ）−Ｐ（ｔ）＜０の状態が続けば、ＴｈｉＶ（ｔ）をある規定値にまで減少させる、といった方法をとってもよい。
（８）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に関して、バッファ余裕が0の時に、現在の配信レートのｓｉ倍でコンテンツ取得を行う、としてｓｉを決定する。例えば、全ターゲットコンテンツ一律にｓｉ=3などと決めてもよいし、配信レートｓｉ倍がリンク70の帯域になるように（バッファ余裕が0の時は最大リンク70の帯域全部を使えるように）決めてもよい。
【００８６】ステップ１：まず、実取得レートの合計と現在のリンク70の空き帯域Ｘ（ｔ）が、ターゲットコンテンツの集合Ｍがオリジンサーバからのコンテンツ取得に使える帯域（使用可能帯域）であると考え、その帯域【数１】
を求める。
【００８７】ステップ２：クライアント集合Ｍの各クライアントの視聴について、 現在のバッファ余裕に依存して、希望レートｇｉ０（ｔ）を決定する。例えば、ｇｉ０（ｔ）＝ｍａｘ｛０，ｒｉ（ｔ）＋（ＴｈｉＶ（ｔ）−ｂｉ（ｔ））（ｓｉ／ＴｈｉＶ（ｔ））｝を計算して決定する。ここで、ｍａｘ｛ａ，ｂ｝とは、ａ，ｂのうちの大きい方を意味する（図８を参照）。
【００８８】ステップ３：【数２】
を求める。
【００８９】ステップ４：Ｐ（ｔ）≦Ａ（ｔ）ならば、目標レートｇｉ（ｔ）＝ｇｉ０（ｔ）として終了。
そうでないならば、ステップ５へステップ５：目標レートｇｉ（ｔ）を、Ａ（ｔ）をｇｉ０（ｔ）に比例して配分したものとする。終了。
【００９０】なお、ステップ５において、目標レートｇｉ（ｔ）を、バッファ余裕ｂｉ（ｔ）を出来るだけ平均化するように割り当ててもよい。あるいは、目標レートｇｉ（ｔ）を、ｇｉ０（ｔ）の大きいものから順に、ｇｉ（ｔ）の合計がＡ（ｔ）を越えない範囲で割り当て、越えるものについては、目標レートとして0を割り当てる方式でもよい。すなわち、ｇｉ０（ｔ）の大きいもの順に並べ変えてｇｉ１（ｔ）とし、Kを、【数３】
を満たす整数として、【数４】
とする方式でもよい。また、管理者の設定する、指定優先度（視聴コンテンツやクライアントに依存して決まる優先度）に従って、優先度の高いものから順にＡ（ｔ）から目標レートｇｉ（ｔ）をｇｉ０（ｔ）として割り当てる方式でもよい。
【００９１】次に、第１の実施の形態のストリームプロキシサーバ20Aの全体の動作を説明する。従来のストリームプロキシサーバとの大きな違いは、主に以下の点である。まず、先読み制御部202Aがオリジンサーバからのコンテンツを取得する際に、目標受信レートを、ストリーム配信制御部から得られる現在の再生位置情報と視聴レート情報、および、ネットワーク情報取得部207Aから得られる情報を基に決定すること。また、その目標レートに従って、受信レート制御部206Aが、トランスポート層制御部からデータを読み出すことにより、オリジンサーバからストリームプロキシサーバへのデータ送信レートが目標レートに抑制される事である。
【００９２】クライアントが送信する視聴リクエストには、視聴初期化（コンテンツ識別子が指定される）、視聴開始(コンテンツ内での位置が指定される、例えば再生時間での何秒目などを指定する）、視聴停止、視聴終了が含まれるのは、従来のストリームプロキシサーバの場合と同様である。また、視聴の際の動作も同様で、クライアントは、まず「視聴初期化」の視聴リクエストをプロキシサーバに送信し、プロキシサーバと、クライアントとの間に、リクエスト内のコンテンツ識別子で指定されたコンテンツについての配信サービスのためのコネクションを開設する。ストリームプロキシサーバは、その後、「視聴開始」（任意の開始位置が指定出来る）や、「視聴停止」（一時停止）、の視聴リクエストを使ってコンテンツ視聴を行い、視聴を終えると、「視聴終了」の視聴リクエストでプロキシサーバに視聴を終える旨を通知する。
【００９３】図９に典型的なコンテンツ視聴のタイミングチャートを示す。
【００９４】図９の例では、クライアントはコンテンツの最初から視聴開始し、最後まで見終わってから視聴終了するとする。また、ストリームプロキシサーバ20Aは、視聴開始時点で、リクエストされたコンテンツの先頭部分(0秒〜Ta秒）、コンテンツの途中部分(Tb秒〜Tc秒）を保持しているとする。図９では、保持している以外の部分（Ta〜Tb秒、および、Tc〜Td秒）をオリジンサーバから取得しながら、クライアントへとストリーム配信している様子を示している。図１０にこの例で、視聴開始時にストリームプロキシサーバが保持しているコンテンツの位置を示す。
【００９５】図９のAT-10において、クライアントが、「視聴初期化」のリクエストをプロキシサーバに送り、サーバが肯定応答(OK)）を返す事で、視聴リクエストの配信のためのコネクションが、クライアントとストリームプロキシサーバとの間に開設される。次に、AT-20において、クライアントは「視聴開始」（位置は先頭(0秒)から）の視聴リクエストを送ってくるので、ストリームプロキシサーバは、記憶部に保持している該当コンテンツの先頭部分からコンテンツのストリーム配信を開始する(AT-30)。また、オリジンサーバへに、コンテンツの保持している以外の部分を取得するために、コネクションを開設し(AT-40)、後続のコンテンツ部分の取得要求を出す(AT-50)。そしてサーバから後続のコンテンツ断片を取得し始める（AT-60)。取得した部分は記憶部にためられてゆく。ストリームプロキシサーバは、オリジンサーバから、後続のコンテンツを取得しながら(AT-65およびAT-70)、記憶装置に保持しているコンテンツ読み込んで、クライアントへとストリーム配信してゆく。このとき、コンテンツがまだ取得出来ていない場合（バッファ余裕が0秒になった場合）には、取得出来るまでの間（バッファ余裕が正の値になるまで）、配信は一時的に中断され、クライアントには視聴が不連続に飛んだ（画面が飛ぶ、あるいは、音がとぎれるなど）ようにみえる。クライアントは全コンテンツを取得し終えると、「視聴終了」の視聴リクエストを送り(AT-8)、それを受けて、サーバ側とのコネクションを切断する(AT-9)。
【００９６】次に、図９タイミングチャートの中で、ストリーム配信制御部201A、先読み制御部202A、記憶部204A、トランスポート層制御部205A、受信レート制御部206A、ネットワーク情報収集部207Aがどのように動作するのかを説明する。ストリーム配信制御部201Aは、クライアントからの視聴リクエストを受け取ると、それが「視聴終了」の場合、ストリーム配信を停止し、先読み制御部に該当コンテンツの識別子と視聴終了であることを通知する。「視聴初期化」の場合、記憶部204Aの該当コンテンツを検索し、記憶部内のアドレスを得る。みつからない場合、先読み制御部202Aへ指示して、記憶部204Aに記憶領域を確保させ、記憶部内のアドレスを通知してもらう。また、先読み制御部202Aに「視聴初期化」である事と、コンテンツの識別子を通知する。「視聴開始」の場合、指定された視聴開始位置が、記憶部内にある場合には、配信の先頭を指定された位置に調整する動作を行う。また、先読み制御部に、「視聴開始」である事を通知する。その後、記憶部からコンテンツを読み出してストリーム配信を行う。オリジンサーバからの取得が間に合わず、記憶部に読み出したいコンテンツの部分がない場合(バッファ余裕が0秒になった場合）には、その部分のコンテンツは配信されず、クライアントには、視聴が不連続に飛んだ（映像がとぎれる、あるいは、音がとぎれるなど）ようにみえ、視聴品質が悪化する。また、ストリーム配信制御部201Aは、先読み制御部202Aからのリクエストに応じて、現在の視聴位置、現在のコンテンツ視聴レートを返す事も行う。
【００９７】先読み制御部202Aでは、前述のフローチャート（図３から図７）に従った動作をする。すなわち、ストリーム配信制御部から「視聴終了」の通知を受け取ると、該当のコンテンツに関してオリジンサーバとのコネクションを切断する。「視聴初期化」の場合には、該当コンテンツについて、トランスポート層制御部205Aへ指示して、オリジンサーバへとコネクションを張る処理を行う。また、「視聴開始」の場合、視聴開始位置以降のコンテンツについて、記憶部内にない部分を、トランスポート層制御部を介してオリジンサーバから取得して、記憶部へ書き込む。このとき、前述記憶部の容量がなくなった場合、コンテンツの中ですでに配信が終わっている部分などを削除して容量を空ける動作を行う。また取得に関して、目標受信レートを、ネットワーク情報収集部207Aからのネットワーク情報、ストリーム配信制御部201Aからの現在の配送レート、現在の配信位置、記憶部204A内のコンテンツ断片の位置情報、過去の実際の受信レートの履歴から、受信レート決定アルゴリズムに従って決定し、受信レート制御部206Aに目標受信レートを指示して取得を行う。
【００９８】次に、本発明の第１の実施の形態の効果を説明する。
【００９９】受信レート制御アルゴリズムでは、ステップ１で現在のオリジンサーバからの取得レートの合計と、ネットワーク情報収集部から得られるボトルネックの空き帯域の和を、次にオリジンサーバからのコンテンツ取得に使用出来るレートとして計算し、ステップ４、ステップ５で、このレート以下に目標レートの合計を制限している。また、受信レート制御アルゴリズムで決めた目標レートを受信レート制御部に指示する事によって、オリジンサーバからのコンテンツ取得レートを目標レート以下に抑えている。以上の事から、実際のオリジンサーバからのコンテンツ取得レートの合計は、ネットワークの空いている帯域以下に抑えられるため、オリジンサーバからのコンテンツの取得をネットワークの他のトラヒック（ボトルネックを共有している他のトラヒック）への影響を抑えて実現する事が出来る。これによって本発明の第１の目的を達成する事が出来る。
【０１００】また、受信レート制御アルゴリズムのステップ２では、各クライアントの視聴のためのオリジンサーバからのコンテンツ取得（先読み）の希望レートを、バッファ余裕が少なくなるほど高く、バッファ余裕が大きければ低くなるように決めている。また、ステップ４で希望レートの合計が、使用可能帯域を越えなければ、希望レートが目標レートとなり、越えていれば、ステップ５で使用可能帯域を希望レートで比例配分したものにしているため、同一ボトルネックを共有するコンテンツの間で、バッファ余裕が少ないものに、より多くの帯域を割り当てる事が可能となり、視聴品質の悪化が起こる可能性を小さくする事が可能となり、本発明の第２の目的を達成することが可能となる。
【０１０１】さらに、ステップ５において、輻輳時に、指定優先度に従って、使用可能帯域の中から、より多くの帯域を割り当てる事が出来る。これによって、指定優先度に従って、優先度の高い視聴の、視聴品質の悪化が起こる可能性を小さくする事が可能となり、本発明の第３の目的を達成することが可能となる。
【０１０２】（第２の実施の形態）図１１に本発明の第２の実施の形態の構成を示す。ストリームプロキシサーバ20Bは、クライアント10-1〜10-nのn台のクライアントに対して、m台のオリジンサーバ40-1〜40-mの保持するコンテンツのについてn本のストリームプロキシサービスを行っているものとする。またストリームプロキシサーバと、オリジンサーバ40-1〜40-mは、ルータ30、リンク70とネットワーク50を経由して接続されているとする。リンク70には、ネットワーク50と60の間のトラヒックも流れている。クライアントが視聴リクエストを出す動作は、従来の技術で説明したものと同等とする。
【０１０３】図１２に本発明の第２の実施の形態のプロキシサーバ20Bの内部構成図を示す。ストリーム配信制御部201B、記憶部204B、ネットワーク情報収集部207Bについては、本発明の第１の実施の形態の、ストリーム配信制御部201A、記憶部204A、ネットワーク情報収集部207Aと、それぞれ同じ動作をする。本発明の第１の実施の形態と動作が異なる、先読み制御部202Bと、トランスポート層制御部205B、受信レート制御部のみについて説明する。
【０１０４】先読み制御部202Bは、ストリーム配信制御部201Bから、視聴リクエストを受け取り、クライアントが視聴したいコンテンツに関して、現在の配信位置以降で、記憶部204Bに保持していないコンテンツ断片がある場合には、オリジンサーバへ、複数のコネクション（それぞれ、帯域共有特性の異なるトランスポート層プロトコルを用いる）をトランスポート層制御部205Bへ指示して開設する。また、コンテンツ取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）と、そのコンテンツ取得を、前記の複数のトランスポート層プロトコルを用いたコネクションのうち、どれを使用して行うかを決定し（この決定方法を、「トランスポート層プロトコル決定アルゴリズム」と呼び、詳細は後述する）、トランスポート層制御部205Bに指示する。コンテンツ取得要求したコンテンツを受け取っている最中にトランスポート層を切り替える必要がある場合には、現在の取得を中断し、現在までに受け取ったデータ量から、残りのコンテンツ断片を取得するためのコンテンツ断片の開始位置と終わりの位置を計算し、次のリクエストを切り替えたいトランスポート層プロトコルのコネクションを使ってオリジンサーバへと転送する。また、受信レート制御部206Bへ、目標レートを指示し、受信レート制御部206Bがトランスポート層制御部205Bから取得したコンテンツを読み出す速度を指定して読み出させ、受信レート制御部206Bからコンテンツを受け取る。受け取ったコンテンツは記憶部206Bへと書き込む。また、コンテンツ取得要求で指定するコンテンツ断片の位置（開始位置と終わり位置）、記憶部のコンテンツの中で削除する部分の決定も行う。さらに、オリジンサーバからのコンテンツ取得の目標レートは、記憶部204Bが保持しているコンテンツ断片の位置の情報、ストリーム配信制御部から得られる現在の再生位置情報と視聴レート情報、および、ネットワーク情報取得部207Bから得られる情報を基に決定する。この決定のアルゴリズムを「受信レート決定アルゴリズム」と呼ぶ。先読み制御部202Bの動作の詳細はフローチャートを使って後述する。また、「受信レート決定アルゴリズム」の詳細についても後述する【０１０５】トランスポート層制御部205Bは、フロー制御機能を持つトランスポート層プロトコル（例えばTCP）を使ったデータ通信を制御する部分である。トランスポート層プロトコルとして、帯域共有の特性が異なる複数の種類のトランスポート層プロトコルのコネクションの終端を行う事が出来る。先読み制御部202Bからの指示に従って、オリジンサーバとのコネクションの開設、切断、およびデータ送受信に必要なトランスポート層の終端処理（例えばトランスポート層がTCPならTCPの送受信のプロトコル処理）を行う。また、開設した各コネクションについて、先読み制御部からのデータ書き込み、および、受信レート制御部からのデータの読み出しのインターフェースを持つ。帯域共有特性の異なるトランスポート層プロトコルとしては、例えば、TCP RenoとTCP Vegas等がある。TCP Vegas は、TCPRenoと帯域を共有した場合、TCP Renoに帯域を譲る特性が知られている。
【０１０６】受信レート制御部206Bは、先読み制御部202Bから指定される目標レートに従って、オリジンサーバから取得したコンテンツをトランスポート層制御部205Bから読み出し、先読み制御部202Bへと渡す。トランスポート層制御部205Bのトランスポート層はフロー制御機構を持つため、受信レート制御部でデータの読み出しレートを制限すると、オリジンサーバからのデータ転送レートもその読み出しレートに制約される。これを用いてオリジンサーバからのデータ転送レートを制御する事が出来る。
【０１０７】次に先読み制御部202Bの動作を図８、フローチャートである図１３から図１７を用いて説明する。
（受信レート決定アルゴリズム）まず以下を定義する。
（１）現時点での（新たに視聴開始するクライアントは加えず、視聴終了するクライアントは含める）視聴を行っているクライアントの集合を、ｐＭ＝｛ｐＭ１，ｐＭ２，．．．，ｐＭｍ｝とする。
（２）ｐＭに新たな視聴を開始するクライアントを加え、視聴を終了するクライアントを除いたクライアントの集合をＭ＝｛Ｍ１，Ｍ２，．．．，Ｍｎ｝とする。
（３）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）への、時刻tでの配信レートをｒｉ（ｔ） bps(bit per second)とする。
（４）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に対する、時刻tでのストリームバッファ余裕（バッファ余裕とも呼ぶ）を、ｂｉ（ｔ）秒とする。
（５）時刻tでの、クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴の為に行う、オリジンサーバからのコンテンツ取得（先読み）のレートの目標値（目標レート）をｇｉ（ｔ）とする。
（６）時刻tでの、クライアントｐＭｉ（ｉ＝１，２，．．．，ｍ）の視聴のために行う、オリジンサーバからのコンテンツ取得（先読み）の実際の取得レートをｇｉ＊（ｔ）とする。
（７）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に対する、現在の目標のバッファ余裕をＴｈｉＶ（ｔ）とする。ＴｈｉＶ（ｔ）はクライアントの再生の飛びが生じる確率が許容範囲内に納めるために必要なストリームプロキシサーバのバッファ余裕である。この値は、経験値として固定的に与えてもよいし、動的に決定してもよい。例えば、過去のコンテンツ取得レートｇｉ＊（ｔ）の履歴と配信レートｒｉ（ｔ）の履歴から、視聴開始時からのｒｉ（ｔ）−ｇｉ＊（ｔ）の積分値の履歴を求め、その最大値（すなわち、過去で最もバッファ余裕が少なくなった状況を救うバッファ余裕としている）等と決めてもよい。あるいは、以下のステップ４において、Ａ（ｔ）−Ｐ（ｔ）＞０の状態が続けば、ボトルネックの使用可能帯域が余っている事を意味するので、ＴｈｉＶ（ｔ）を増加させ、Ａ（ｔ）−Ｐ（ｔ）＜０の状態が続けば、ＴｈｉＶ（ｔ）をある規定値にまで減少させる、といった方法をとってもよい。
（８）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の視聴に関して、バッファ余裕が0の時に、現在の配信レートのｓｉ倍でコンテンツ取得を行う、としてｓｉを決定する。例えば、全ターゲットコンテンツ一律にｓｉ=3などと決めてもよいし、配信レートｓｉ倍がリンク70の帯域になるように（バッファ余裕が0の時は最大リンク70の帯域全部を使えるように）決めてもよい。
【０１０８】先読み制御部202Bは、第１の実施の形態と同様に、図示しないタイマー（設定された時間が経過すると信号を発生する装置）に設定された時間が経過した場合（あるいはカウンタによって設定された値を計数した場合）、あるいは、ストリーム配信制御部からの視聴リクエスト（視聴終了、視聴初期化、視聴開始、取得完了）によって、待ち状態から起動される。
【０１０９】視聴リクエストが「視聴終了」であった場合、図１３に示すように、該当視聴コンテンツを取得しているオリジンサーバとのコネクションを切断する指示をトランスポート層制御部205Bへ送る（ステップＢ１０）。
【０１１０】視聴リクエストが「視聴初期化」の場合、図１４に示すように、クライアントが視聴したいコンテンツに関して、記憶部204Bに保持していないコンテンツ断片がある場合には、オリジンサーバへのコネクションをトランスポート層制御部205Bへ指示して開設する（ステップＢ２０）。このとき、帯域共有特性の異なる複数のトランスポート層プロトコルのコネクションが開設される。また、ストリーム配信制御部201Bから、記憶部204Bに領域を確保する指示があれば、記憶領域を確保してアドレスをストリーム配信制御部201Bへと返す（ステップＢ３０）。
【０１１１】視聴リクエストが「視聴開始」の場合、図１５に示すように、コンテンツの中で現在視聴している位置以降で、保持していないコンテンツの部分から、取得するコンテンツの位置を決定し（ステップＢ４０）、トランスポート層プロトコル決定アルゴリズム(後述する）によって使用するトランスポート層プロトコルを決定し、取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）と使用するトランスポート層プロトコルをトランスポート層制御部205Bに指示する（ステップＢ５０）。また、タイマＴを「0」に設定し（ステップＡ６０）、タイマＴが「0」の場合の処理である、該当コンテンツへの目標レートの設定処理が実行されるようにする。
【０１１２】視聴リクエストがコンテンツ断片の「取得完了」である場合、図１６に示すように、次に取得するコンテンツの位置を決定し（ステップＢ７０）、トランスポート層プロトコル決定アルゴリズム(後述する）によって使用するトランスポート層プロトコルを決定し、取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）と使用するトランスポート層プロトコルをトランスポート層制御部205Bに指示する（ステップＢ８０）。
【０１１３】タイマＴが「0」の場合、図１７に示すように、現在オリジンサーバからコンテンツ取得を行っている全コンテンツについて、記憶部204Bが保持しているコンテンツ断片の位置の情報、および、ストリーム配信制御部201Bから得られる現在の配信位置の情報に基づいて、トランスポート層プロトコル決定アルゴリズム(後述する）によって使用すべきトランスポート層プロトコルを決定する（ステップＢ９０）。トランスポート層プロトコルに変更がある場合（ステップＢ１００）、現在の取得を終了し（ステップＢ１１０）、現在までに取得した断片のサイズから、現在の取得要求で取得するはずであった残りのコンテンツの位置を決定し、残りのコンテンツに対する取得要求（コンテンツの識別子、取得すべき各コンテンツ断片の開始位置と終わりの位置から成る）と使用するトランスポート層プロトコルをトランスポート層制御部205Bに指示する（ステップＢ１２０）。
【０１１４】次に、記憶部204Bが保持しているコンテンツ断片の位置の情報、および、ストリーム配信制御部201Bから得られる現在の配信位置の情報と、ストリーム配信レート制御部201Bから得られる現在の配信レート情報、および、ネットワーク情報取得部207Bから得られる情報を基に、そのコンテンツに関する目標取得レートを決定する（ステップＢ１３０）。目標取得レートの決定アルゴリズムについては後述する。全コンテンツに対する目標レートが決まると、その値を受信レート制御部206Bに通知する（ステップＢ１４０）。このとき、トランスポート層が切り替わる場合には、また、これ以降、受信レート制御部が取得したコンテンツは先読み制御部202Bが受け取って、記憶部204Bへの書き込みを行う。この書き込み動作を実行しながら、タイマを規定値のT0にリセットし（ステップＢ１５０）、待ち状態となる。
【０１１５】（トランスポート層プロトコル決定アルゴリズム）以下に前述のトランスポート層プロトコル決定アルゴリズムを示す。
【０１１６】ストリーム配信制御部201Bから得られる現在の配信位置と、記憶部204Bから得られるストリームのどの位置を保持しているかの情報から、現在のバッファ余裕ｂｉ（ｔ）を求め、これと、ネットワーク情報収集部207Bから得られる現在のネットワーク状況に基づいて、使用するトランスポート層プロトコルを決定する。例えば、2つの閾値ＴｈｉＵ（ｔ）とＴｈｉＭ（ｔ）（ＴｈｉＵ（ｔ）＜ＴｈｉＭ（ｔ）とする）を決め、ｂｉ（ｔ）＜ＴｈｉＵ（ｔ）なら、トランスポート層をTCP Reno、ｂｉ（ｔ）＞ＴｈｉＭ（ｔ）ならば、TCP Vegasとする。ＴｈｉＵ（ｔ）≦ｂｉ（ｔ）≦ＴｈｉＭ（ｔ）の場合、前回のトランスポート層の変更がTCP RenoからTCP Vegasへの変更であったならばTCP Vegasに、TCP VegasからTCPRenoへの変更であったならばTCP Renoとする。前回の変更がない場合（まだ一度も切り替えていない場合）、例えば、TCP Vegasとする。閾値ＴｈｉＵ（ｔ）とＴｈｉＭ（ｔ）は、ネットワーク情報収集部から得られる、ネットワークの輻輳の度合いの変動が大きい場合には大きく、小さい場合には小さく設定する。
【０１１７】次に受信レート決定アルゴリズムを示す(第１の実施の形態の受信レートアルゴリズムと同じである)。
【０１１８】（受信レート決定アルゴリズム）
ステップ１：まず、実取得レートの合計と現在のリンク70の空き帯域Ｘ（ｔ）が、ターゲットコンテンツの集合Ｍがオリジンサーバからのコンテンツ取得に使える帯域（使用可能帯域）であると考え、その帯域【数５】
を求める。
【０１１９】ステップ２：クライアント集合Ｍの各クライアントの視聴について、 現在のバッファ余裕に依存して、希望レートｇｉ０（ｔ）を決定する。例えば、ｇｉ０（ｔ）＝ｍａｘ｛０，ｒｉ（ｔ）＋（ＴｈｉＶ（ｔ）−ｂｉ（ｔ））（ｓｉ／ＴｈｉＶ（ｔ））｝を計算して決定する。ここで、ｍａｘ｛ａ，ｂ｝とは、ａ，ｂのうちの大きい方を意味する（図８を参照）。
ステップ３：【数６】
を求める。
【０１２０】ステップ４：Ｐ（ｔ）≦Ａ（ｔ）ならば、目標レートｇｉ（ｔ）＝ｇｉ０（ｔ）として終了。
そうでないならば、ステップ５へ【０１２１】ステップ５：目標レートｇｉ（ｔ）を、Ａ（ｔ）をｇｉ０（ｔ）に比例して配分したものとする。終了。
【０１２２】なお、ステップ５において、目標レートｇｉ（ｔ）を、バッファ余裕ｂｉ（ｔ）を出来るだけ平均化するように割り当ててもよい。あるいは、目標レートｇｉ（ｔ）を、ｇｉ０（ｔ）の大きいものから順に、ｇｉ（ｔ）の合計がＡ（ｔ）を越えない範囲で割り当て、越えるものについては、目標レートとして0を割り当てる方式でもよい。すなわち、ｇｉ０（ｔ）の大きいもの順に並べ変えてｇｉ１（ｔ）とし、Kを、【数７】
を満たす整数として、【数８】
とする方式でもよい。また、管理者の設定する、指定優先度（視聴コンテンツやクライアントに依存して決まる優先度）に従って、優先度の高いものから順にＡ（ｔ）から目標レートｇｉ（ｔ）をｇｉ０（ｔ）として割り当てる方式でもよい。
【０１２３】次に、第２の実施の形態のストリームプロキシサーバ20Bの全体の動作を説明する。第１の実施の携帯のストリームプロキシサーバ20Aとの大きな違いは、主に以下の点である。まず、トランスポート層制御部は、帯域共有特性の異なる複数のトランスポート層プロトコルを使って、複数のコネクションをサーバとの間に持っている。そして、先読み制御部202Bがオリジンサーバからのコンテンツを取得する際に、目標受信レートとともに、使用するトランスポート層プロトコルを、ストリーム配信制御部から得られる現在の再生位置情報と視聴レート情報、および、ネットワーク情報取得部207Bから得られる情報を基に変える点が異なる。
【０１２４】クライアントが送信する視聴リクエストには、視聴初期化（コンテンツ識別子が指定される）、視聴開始(コンテンツ内での位置が指定される、例えば再生時間での何秒目などを指定する）、視聴停止、視聴終了が含まれるのは、従来のストリームプロキシサーバの場合と同様である。また、視聴の際の動作も同様で、クライアントは、まず「視聴初期化」の視聴リクエストをプロキシサーバに送信し、プロキシサーバと、クライアントとの間に、リクエスト内のコンテンツ識別子で指定されたコンテンツについての配信サービスのためのコネクションを開設する。ストリームプロキシサーバは、その後、「視聴開始」（任意の開始位置が指定出来る）や、「視聴停止」（一時停止）、の視聴リクエストを使ってコンテンツ視聴を行い、視聴を終えると、「視聴終了」の視聴リクエストでプロキシサーバに視聴を終える旨を通知する。
【０１２５】図１８に、前記の視聴リクエストを利用した典型的なコンテンツ視聴のタイミングチャートを示す。図１８では、クライアントはコンテンツの最初から視聴開始し、最後まで見終わってから視聴終了するとする。また、図１９に示すように、視聴開始の時点で、ストリームプロキシサーバはコンテンツの最初の部分(0秒〜Ta秒）、コンテンツの途中部分(Tb秒〜Tc秒）をストリームプロキシサーバが保持しているとする。図１８では、保持している以外の部分（Ta〜Tb秒、および、Tc〜Td秒）をオリジンサーバから取得しながら、クライアントへとストリーム配信している様子を示している。
【０１２６】図１８のBT-10において、クライアントが、「視聴初期化」のリクエストをプロキシサーバに送り、サーバが肯定応答(OK)）を返す事で、視聴リクエストの配信のためのコネクションが、クライアントとストリームプロキシサーバとの間に開設される。次に、BT-20において、クライアントは「視聴開始」（位置は先頭(0秒)から）の視聴リクエストを送ってくるので、コンテンツスイッチは、記憶部に保持している該当コンテンツの先頭部分からコンテンツのストリーム配信を開始する(BT-30)。また、オリジンサーバへに、コンテンツの保持している以外の部分を取得するために、コネクションを開設し(BT-40)、後続のコンテンツ部分の取得要求を出す(BT-50)。そしてサーバから後続のコンテンツ部分を取得し始める（BT-60)。取得した部分は記憶部にためられてゆく。ストリームプロキシサーバは、オリジンサーバから、後続のコンテンツを取得して記憶部204Bに保存しながら、記憶部204Bに保持しているコンテンツをストリーム配信してゆく(BT-90)。このとき、配信したい位置のコンテンツがまだ取得出来ていない場合（バッファ余裕が0秒になった場合）には、取得出来るまでの間（バッファ余裕が正の値になるまで）、配信は一時的に中断され、クライアントには視聴が不連続に飛んだ（映像がとぎれる、あるいは、音がとぎれるなど）ようにみえ、視聴品質が悪化する。ストリームプロキシサーバは、コンテンツ断片の取得が終わると(BT-65)、現在の配信位置以降で、次に保持していないコンテンツ断片の取得要求を出す(BT-70)。コンテンツの取得に関しては、受信レート制御部によって、トランスポート層からの読みとりレートを制御することでコンテンツの取得レートの制御を行う。また、コンテンツ取得を行うトランスポート層についても、トランスポート層プロトコル決定アルゴリズムに従って決定し、それを用いてコンテンツ取得を行う。この例では、最初の後続のコンテンツ断片要求(BT-50)はTCP Renoのトランスポート層プロトコルを用いており、次の後続のコンテンツ断片(時間Tc〜Td)については、TCP Vegasを使った取得を行うが(BT-73、BT-83)、途中(BT-75)で、トランスポート層決定プロトコルによってTCP Renoへと切り替える判断がなされる。BT-75までに取得出来たコンテンツ断片が、時間Tc〜Txの部分であり、現在の配信位置がTxより前であるため、さらに後続のコンテンツ断片(Tx〜Td)については、TCP Renoを使ってコンテンツの取得要求を出し(BT-80)、TCP Renoを使ったコンテンツ取得を行う（BT-83)。 クライアントは全コンテンツを取得し終えると、「視聴終了」の視聴リクエストを送り(BT-130)、それを受けて、サーバ側とのコネクションを切断する(BT-140)。
【０１２７】次に、図１８のタイミングチャートの中で、ストリーム配信制御部201B、先読み制御部202B、記憶部204B、トランスポート層制御部205B、受信レート制御部206B、ネットワーク情報収集部207Bがどのように動作するのかを説明する。ストリーム配信制御部201Bは、クライアントからの視聴リクエストを受け取ると、それが「視聴終了」の場合、ストリーム配信を停止し、先読み制御部に該当コンテンツの識別子と視聴終了であることを通知する。「視聴初期化」の場合、記憶部204Bの該当コンテンツを検索し、記憶部内のアドレスを得る。みつからない場合、先読み制御部202Bへ指示して、記憶部204Bに記憶領域を確保させ、記憶部内のアドレスを通知してもらう。また、先読み制御部202Bに「視聴初期化」である事と、コンテンツの識別子を通知する。「視聴開始」の場合、指定された視聴開始位置が、記憶部内にある場合には、配信の先頭を指定された位置に調整する動作を行う。また、先読み制御部202Bに、「視聴開始」である事を通知する。その後、記憶部からコンテンツを読み出してストリーム配信を行う。オリジンサーバからの取得が間に合わず、記憶部に読み出したいコンテンツの部分がない場合(バッファ余裕が0秒になった場合）には、その部分のコンテンツは配信されず、クライアントには、視聴が不連続に飛んだ（映像がとぎれる、あるいは、音がとぎれるなど）ようにみえ、視聴品質が悪化する。また、ストリーム配信制御部201Bは、先読み制御部202Bからのリクエストに応じて、現在の視聴位置、現在のコンテンツ視聴レートを返す事も行う。
【０１２８】先読み制御部202Bでは、前述のフローチャート(図B-3)に従った動作をする。すなわち、ストリーム配信制御部から「視聴終了」の通知を受け取ると、該当のコンテンツに関してオリジンサーバとのコネクションを切断する。「視聴初期化」の場合には、該当コンテンツについて、トランスポート層制御部205Bへ指示して、オリジンサーバへとコネクションを張る処理を行う。また、「視聴開始」の場合、視聴開始位置以降のコンテンツについて、記憶部内にない部分を、トランスポート層制御部205Bを介してオリジンサーバから取得して、記憶部へ書き込む。このとき、前述記憶部の容量がなくなった場合、コンテンツの中ですでに配信が終わっている部分などを削除して容量を空ける動作を行う。また取得に関して、目標受信レートを、ネットワーク情報収集部207Bからのネットワーク情報、ストリーム配信制御部201Bからの現在の配送レート、現在の配信位置、記憶部204B内のコンテンツ断片の位置情報、過去の実際の受信レートの履歴から、受信レート決定アルゴリズムに従って決定し、受信レート制御部206Bに目標レートを指示して取得を行う。また、使用するトランスポート層プロトコルを、ストリーム配信制御部201Bからの現在の配信位置情報と、記憶部204Bからの現在のコンテンツを保持している位置情報を基に計算される現在のバッファ余裕をもとに判断して決定する(トランスポート層プロトコル決定アルゴリズムに従う)。
【０１２９】次に、本発明の第２の実施の形態の効果を説明する。
【０１３０】受信レート制御アルゴリズムでは、ステップ１で現在のオリジンサーバからの取得レートの合計と、ネットワーク情報収集部から得られるボトルネックの空き帯域の和を、次にオリジンサーバからのコンテンツ取得に使用出来るレートとして計算し、ステップ４、ステップ５で、このレート以下に目標レートの合計を制限している。また、受信レート制御アルゴリズムで決めた目標レートを受信レート制御部に指示する事によって、オリジンサーバからのコンテンツ取得レートを目標レート以下に抑えている。以上の事から、実際のオリジンサーバからのコンテンツ取得レートの合計は、ネットワークの空いている帯域以下に抑えられるため、オリジンサーバからのコンテンツの取得をネットワークの他のトラヒック（ボトルネックを共有している他のトラヒック）への影響を抑えて実現する事が出来る。これによって本発明の第１の目的を達成する事が出来る。
【０１３１】また、トランスポート層決定アルゴリズムによって、バッファ余裕が大きい場合には、TCP Vegasを用いてオリジンサーバからコンテンツ取得を行う。他のトラヒックがTCP Renoで送信されているような環境においては、TCP VegasがTCP Renoと帯域を共有すると、TCP Renoに帯域を譲るという効果があるため、他のトラヒックとコンテンツ取得を行っているトラヒック帯域共有をしているような場所（例えば、リンク70)において、他のトラヒックに対して帯域を譲る効果があり、他のトラヒックに対する影響を抑える事が出来、発明の第１の目的を達成することが可能となる。
【０１３２】また、受信レート制御アルゴリズムのステップ２では、各クライアントの視聴のために行うオリジンサーバからのコンテンツ取得（先読み）の希望レートをバッファ余裕が少なくなるほど高く、バッファ余裕が大きければ低くなるように決めている。また、ステップ４で希望レートの合計が、使用可能帯域を越えなければ、希望レートが目標レートとなり、越えていれば、ステップ５で使用可能帯域を希望レートで比例配分したものにしているため、同一ボトルネックを共有する先読みの間で、バッファ余裕が少ないものに、より多くの帯域を割り当てる事が可能となり、視聴品質の悪化が起こる可能性を小さくする事が可能となり、本発明の第２の目的を達成することが可能となる。
【０１３３】さらに、ステップ５において、輻輳時に、指定優先度の高い特定のクライアントやコンテンツについて、使用可能帯域の中から、より多くの帯域を割り当てる事が出来る。これによって、特定のクライアントやコンテンツについて、視聴品質の悪化が起こる可能性を小さくする事が可能となり、本発明の第３の目的を達成することが可能となる。
【０１３４】（第３の実施の形態）図２０に本発明の第３の実施の形態のストリームプロキシサーバC1000の内部構成図示す。本発明の第１の実施の形態のストリームプロキシサーバ20Aとほぼ同じ構成であるが、サーバからのコンテンツ送信レートを制御する方式が異なるため、受信レート制御部206Aが、受信レート制御部206Cへとおき変わっている。また、トランスポート層制御部205Cが用いるトランスポート層プロトコルは、フロー制御機能を持っている必要はない点が異なる。
【０１３５】受信レート制御部206Cについて、本発明の第１の実施の形態の受信レート制御部205Aとの違いを説明する。
【０１３６】受信レート制御部206Cは、本発明の第１の実施の形態の受信レート制御部205Aは、トランスポート層制御部205Aからのコンテンツの読み出しレートを制御していたが、受信レート制御部206Cはオリジンサーバに対して送信レートを明示的に指定する。例えば、オリジンサーバからのコンテンツ取得を、トランスポート層制御部205Cで、RTCPプロトコルを用いて行い、受信レート制御部206Cが、オリジンサーバに対して、RTCPプロトコルのSpeedというヘッダフィールドを用いることによって送信レートを明示的に設定する事が可能である。
【０１３７】その他の、ストリーム配信制御部201C、先読み制御部202C、記憶部204C、トランスポート層制御部205C、ネットワーク情報収集部207Cの機能、動作は本発明の第１の実施の形態のストリームプロキシサーバ20Aのストリーム配信制御部201A、先読み制御部202A、記憶部204A、トランスポート層制御部205A、ネットワーク情報収集部207Aと同様であり、全体の動作も受信レート制御部206Cが、先読み制御部202Cから指示される目標レートをオリジンサーバに伝えて、オリジンサーバが送信レートを目標レートにする点以外は同じである。
【０１３８】次に、本発明の第３の実施の形態の効果を説明する。
【０１３９】本発明の第３の実施の形態では、オリジンサーバからのコンテンツを取得するために使用するネットワーク帯域の制御を、明示的にオリジンサーバに指示している。第１の実施の形態では、同じ制御を、受信レート制御部がトランスポート層制御部からコンテンツを読み出すレートを抑制することで、トランスポート層のフロー制御を働かせ間接的に行っていた。第３の実施の形態では、第１の実施の形態より正確な制御が可能になり、第１の実施の形態でも実現出来ていた本発明の第１、２、３の目的をより精度高く達成することが出来る。
【０１４０】（第４の実施の形態）図２１に本発明の第４の実施の形態のストリームプロキシサーバ20Dの内部構成図を示す。本発明の第２の実施の形態のストリームプロキシサーバ20Bとほぼ同じ構成であるが、サーバからのコンテンツ送信レートを制御する方式が異なるため、受信レート制御部206Bが、受信レート制御部206Dへとおき変わっている。また、トランスポート層制御部が用いるトランスポート層プロトコルは、フロー制御機能を持っている必要はない点が異なる。
【０１４１】受信レート制御部206Dについて、本発明の第２の実施の形態の受信レート制御部206Bとの違いを説明する。
【０１４２】受信レート制御部206Dは、本発明の第２の実施の形態の受信レート制御部206Bは、トランスポート層制御部205Bからのコンテンツの読み出しレートを制御していたが、受信レート制御部206Dはオリジンサーバに対して送信レートを明示的に指定する。例えば、オリジンサーバからのコンテンツ取得を、トランスポート層制御部で、RTCPプロトコルを用いて行い、受信レート制御部206Dが、オリジンサーバに対して、RTCPプロトコルのSpeedというヘッダフィールドを用いることによって送信レートを明示的に設定する事が可能である。
【０１４３】その他の、ストリーム配信制御部201D、先読み制御部202D、記憶部204D、トランスポート層制御部205D、ネットワーク情報収集部207Dの機能、動作は本発明の第２の実施の形態のストリームプロキシサーバ20Bのストリーム配信制御部201B、先読み制御部202B、記憶部204B、トランスポート層制御部205B、ネットワーク情報収集部207Bと同様であり、全体の動作も受信レート制御部206Dが、先読み制御部202Dから指示される目標レートをオリジンサーバに伝えて、オリジンサーバが送信レートを目標レートにする点以外は同じである。
【０１４４】本発明の第４の実施の形態では、オリジンサーバからのコンテンツを取得するために使用するネットワーク帯域の制御を、明示的にオリジンサーバに指示している。第２の実施の形態では、同じ制御を、受信レート制御部がトランスポート層制御部からコンテンツを読み出すレートを抑制することで、トランスポート層のフロー制御を働かせ間接的に行っていた。本発明の第４の実施の形態の方がより正確な制御が可能になり、第２の実施の形態でも実現出来ていた本発明の第１、 ２、 ３の目的をより精度高く達成することが出来る。
【０１４５】（第５の実施の形態）図２２に本発明の第５の実施の形態における接続構成を示す。ストリームプロキシサーバ20Eは、クライアント10-1〜10-nのｎ台のクライアント、ｍ台のオリジンサーバ40-1〜40-mの保持するコンテンツについてｎ本のストリームのプロキシ配信を行っているものとする。ストリームプロキシサーバ20Eとオリジンサーバ40-1〜40-mは、リンク120、ルータ30、リンク110、ネットワーク50を経由して接続されているとする。また、ルータ30には、リンク130を通して他のネットワーク80からのトラヒックや、ストリームプロキシサーバ20Eを介さずにクライアント10-1〜10-nが送受信するトラヒックも流れているものとする。
【０１４６】次に、図２３に本発明の第５の実施の形態におけるストリームプロキシサーバの構成を示す。
【０１４７】本実施の形態の構成において従来の構成と異なる点はない。ストリームプロキシサーバとしての動作は従来例とほぼ同じである。先読み制御アルゴリズムのみが異なる。第５の実施の形態では、バッファ余裕が基準値を下回らないようにコンテンツの断片取得を行うことでクライアントへ配信するデータが常にストリームプロキシサーバに蓄積されていることと、後続のデータ全体を要求するのではなく、要求する範囲を分割して細切れに要求することで限られたネットワーク帯域をできるだけ公平にシェアすることを実現する。バッファ余裕は従来例と同様に、クライアントの現在の視聴位置とクライアントが視聴中のコンテンツ断片の末尾位置の差として定義される。
【０１４８】本実施の形態における先読み制御部202Eが行う先読み制御アルゴリズムを動作フローチャートの図２４と構成図の図２３を用いて説明する。
【０１４９】コンテンツの先読み要求は、クライアントからの視聴リクエストがストリーム配信制御部201Eを通じて先読み制御部202Eに到着したとき、またはクライアントに配信中のコンテンツのバッファ余裕が指定閾値（取得要求送出バッファ余裕値）以下になった場合に発生する（ステップＣ１０）。現在の視聴位置のコンテンツのデータが記憶部204Eに記憶されていない場合は０となる。バッファ余裕は、クライアントの視聴位置により決まる値であるので、当然コンテンツ毎にではなく、クライアント毎に定まる値である。例えば、図２５を用いて説明すると、クライアント１の現在の視聴位置がS1、クライアント２の視聴位置がS2、クライアント３の視聴位置がS3とすると、クライアント１のバッファ余裕は、Sa-S1、クライアント２のバッファ余裕は０、クライアント３のバッファ余裕は、Sc-Sbとなる。
【０１５０】本実施の形態では、取得要求送出バッファ余裕値はクライアント毎にパラメータとして与えられるとし、クライアントiに対しての取得要求送出バッファ余裕値は、THLiと表記されるとする。
【０１５１】現在時刻tでのクライアントiに対するバッファ余裕が、bi(t)であるとすると、bi(t)≦THLiとなると、次のコンテンツ断片の要求が生成され送出されることになる。
【０１５２】クライアントiのバッファ余裕がbi(t)≦THLiとなったことを契機に発生したコンテンツ断片の取得要求は、クライアントiへの配信を目的とした先読みである。以後、クライアントiへの配信を目的としたコンテンツ断片の取得要求を、クライアントiをターゲットとした取得要求と表現することにする。
【０１５３】クライアントiをターゲットとしたコンテンツ取得要求の送出が決定すると、先読み制御部202Eは、先読みを要求するコンテンツ断片の範囲（開始位置と終了位置）を決定する（ステップＣ２０）。本実施の形態では、コンテンツ断片の幅（開始位置と終了位置の差）はクライアント毎のパラメータとして与えられるとする。クライアントiに対しての幅はPFRiで与えられるとする。クライアントiが視聴中のコンテンツ断片の末尾位置を開始位置、開始位置にPFRiを加えた位置を終了位置とする。（PFRiを動的に変更する方式については他の実施の形態として説明している。）範囲内のコンテンツが既にコンテンツ断片として記憶部204Eに保持されている場合は、その範囲を除いた範囲を要求する。図２５を用いて説明すると、クライアントiの視聴位置がS1の場合、開始位置はSaとなる。終了位置は、Sa+PRFi≦Sbならば、Sa+PRFiとなり、Sa+PFRi＞SbならばSbからのコンテンツ断片との重複を除くのでSbとなる。視聴位置がS2の場合、開始位置はS2となり、S2+PRFi≦Sbならば終了位置はS2+PRFiとなり、S2+PFRi＞SbならばSbからのコンテンツ断片との重複を除くので終了位置はSbとなる。視聴位置がS3の場合、開始位置はScとなり、終了位置は、以降はコンテンツ断片が無いので、Sc+PFRiとコンテンツの末尾の小さい方となる。
【０１５４】そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＣ３０）。そしてステップＣ１０に戻る。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０１５５】以上の処理フローは、クライアントiからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０１５６】この第５の実施の形態は、以下のような効果を発揮する。
【０１５７】クライアントが視聴中のコンテンツに対する先読みのみが発生するので、帯域を浪費しない。
【０１５８】先読みを分割することにより、特定のコンテンツの取得が帯域を長期間独占することを回避できる。
【０１５９】バッファ余裕のあるクライアントをターゲットとしたコンテンツ断片の取得が抑制される。そのため、バッファ余裕のないクライアントをターゲットとしたコンテンツ断片の取得が帯域を利用できる確率が増える。そのためバッファが枯渇する（バッファ余裕が０となる）クライアントが減り、より多くのクライアントに安定した品質で配信できる。
【０１６０】（第６の実施の形態）しかし第５の実施の形態では、ネットワークの輻輳状況に適応した制御が実現されていない。例えば、図２２のリンク120が輻輳している場合は、バッファ余裕のないクライアントをターゲットとしたコンテンツ断片の取得が優先的に実行され、バッファ余裕のあるクライアントをターゲットとしたコンテンツ断片の取得は抑制されるべきである。また、リンクの帯域使用率が低い場合は、バッファ余裕があっても、ストリームプロキシサーバ上の記憶部204Eの領域を圧迫しない範囲ならば、積極的にコンテンツ断片の取得を実行して良いはずである。そこで第６の実施の形態では、ネットワークの輻輳状況に適応してコンテンツ断片の取得要求の送出頻度を調整する方法を導入する。
【０１６１】特定のネットワークリンク部がボトルネックとなることがわかっている場合、そのリンク部の輻輳状況をピンポイントに把握し、その情報を適切に反映した制御が望ましい。そのボトルネックとなるリンク部の帯域使用状況を測定し、その情報を利用した制御を行う。
【０１６２】このようにボトルネックリンクがわかっている場合に対応するために、ボトルネックリンクの帯域使用幅の監視と、各コネクションの取得レートの監視を行う。ボトルネックリンクの帯域使用幅を監視するために、図２６に示す構成図のように、図２３の構成にネットワーク情報収集部207Eを加える。さらに各コンテンツ断片の取得レートを受信状況監視部202E-1で監視する。受信状況監視部202E-1は、オリジンサーバとストリームプロキシサーバ間のコネクション毎に以下のパラメータを測定し記憶する。
（１）コンテンツ取得要求を発してから開始位置のデータを受信するまでのラウンドトリップタイム（RTT）
（２）コンテンツのオリジンサーバからの取得レート【０１６３】本実施の形態では、ボトルネックとなるリンクを使用してコンテンツ断片を取得できる要求を、バッファ余裕を基に決定する。ターゲットとするクライアントのバッファ余裕が小さい要求を優先して処理することで、バッファが枯渇するクライアントが無くなり、安定した配信が実現できる。新規取得要求を送出する際に、ボトルネックリンクの輻輳により必要な取得レートを確保できないと判断した場合は、実行中の要求のバッファ余裕を調べ、新規取得要求よりもバッファ余裕の大きい要求が実行中ならば、それを中止することで必要な取得レートを確保する。
【０１６４】第６の実施の形態の詳細を図２７のフローチャートと図２６の構成図を用いて説明する。
【０１６５】コンテンツ断片の取得要求は、第５の実施の形態と同様に、クライアントからの視聴リクエストがストリーム配信制御部201Eを通じて先読み制御部202Eに到着したとき、またはクライアントのバッファ余裕が取得要求送出バッファ余裕閾値以下になった場合に発生する。このどちらかのイベントの発生を待ち、新たなコンテンツ断片の取得要求のターゲットとなるクライアントj（以下新規ターゲットクライアント）を先読み制御部202Eは決定する（ステップＤ１０）。新たなコンテンツ断片の取得要求を以下では新規取得要求と呼ぶ。バッファ余裕の算出法は従来例と同様である。
【０１６６】まず、先読み制御部202Eはネットワーク情報収集部207Eから、ボトルネックリンクの現在時刻tの帯域使用幅RA(t)を取得する（ステップＤ２０）。その際、ネットワーク情報収集部207Eがどこの帯域使用幅を測定すれば良いのかを、図２２に示されるネットワーク構成を用いて説明する。ストリームプロキシサーバ20Eに接続されたリンク120がボトルネックであり、ストリームプロキシサーバ20Eがトランスペアレントキャッシュとして接続されている場合は、ボトルネックの帯域使用幅はトランスポート層制御部205Eが測定し、ネットワーク情報収集部207Eがトランスポート層制御部205Eに問い合わせを行うことになる。ストリームプロキシサーバ20Eを介して流れるトラヒック以外のトラヒックも流れるリンク、例えば図２２においては、リンク110がボトルネックの場合は、ルータ30で帯域使用幅を測定する。ネットワーク情報収集部207Eは、ルータ30にSNMP等を利用して問い合わせをすることで、ボトルネックの現在の帯域使用幅を知ることができる。
【０１６７】各コンテンツ断片の取得レートは受信状況監視部202E-1で測定されている。時刻tでのクライアントjをターゲットとしたコンテンツ断片の取得レートをrj(t)で表すことにする。
【０１６８】次に、新規取得要求を実行し、コンテンツ断片をオリジンサーバからストリームプロキシサーバが受信する際の取得レートを先読み制御部202Eが推定する（ステップＤ３０）。これを先読み取得予測レートと呼び、z＊j(t)で表すことにする。もし新規取得要求が要求するコンテンツの一部が既にコンテンツ断片として記憶部204Eに蓄積された経歴があれば、受信状況監視部202E-1がその際の取得レートを記憶している。そのときのレートでz＊j(t)を近似することができる。または、クライアントがコンテンツを視聴する際の平均視聴レート、ピーク視聴レートと言った情報をコンテンツのメタデータ等として、オリジンサーバから先読み制御部202Eが取得し、それらの値を先読み予測レートz＊j(t)として設定する、としても良い。
【０１６９】次に、新規取得要求を送出した場合に、ボトルネックリンクが輻輳しないかを先読み制御部202Eは判別する（ステップＤ４０）。具体的には、先読み予測取得レートをz＊j(t)、ボトルネックの帯域使用幅をRA(t)とした場合に、要求を新たに送出した場合の見込み帯域使用幅RA(t)+z＊j(t)が、閾値RBを超えるか超えないかで判断する。この閾値RB（ボトルネック限界レート）は、ボトルネックリンクの帯域幅を指定しても良いし、安全側に倒すために帯域幅の80％値などにしても良い。また、実効帯域幅を取得する手段があれば、その手段により取得した実効帯域に動的に設定する、としても良い。
【０１７０】見込み帯域使用幅RA(t)+z＊j(t)がボトルネック限界レートRB以下の場合は、先読み制御部202Eは取得要求を行うコンテンツ断片の範囲を算出する（ステップＤ５０）。コンテンツ断片の範囲の算出方法は第５の実施の形態と同様である。
【０１７１】そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＤ６０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０１７２】そして先読み制御部202Eは、コンテンツ断片の取得要求を送出後、以下のいずれかのイベントが発生するのを待つ（ステップＤ７０）。
【０１７３】すなわち、クライアントjをターゲットとした取得要求の完了（ステップＤ８０）とクライアントjをターゲットとした取得要求の中止（ステップＤ９０）である。
【０１７４】取得要求が完了のイベントがトランスポート層制御部205Eから到着すると（ステップＤ８０）、先読み制御部202Eは取得要求送出バッファ余裕値THLjを初期値に戻す（ステップＤ１００）。そしてステップＤ１０に戻る。
【０１７５】取得要求の中止を検出した場合（ステップＤ９０）、先読み制御部202Eは取得要求送出バッファ余裕値THLjを現在のクライアントjのバッファ余裕より小さい値に設定する（ステップＤ１１０）。例えば、現在のバッファ余裕bj(t)のadj倍(adj＜1)などとする。つまり、THLj=adj×bj(t)とする。そしてステップＤ１０に戻る。これは、中止した要求がターゲットとしていたクライアントjを対象とするコンテンツ断片取得の次回取得要求が発生するまでの時間間隔をあけるためである。現在のバッファ余裕より大きい値が取得要求送出バッファ余裕値として指定されると直ちに取得要求が生成されるので、現在のバッファ余裕よりも小さい値を設定する必要がある。
【０１７６】ステップＤ１１０で初期値に戻すのは、ステップＤ１１０で小さくなった取得要求送出バッファ余裕値をリセットするためである。
【０１７７】見込み帯域使用幅RA(t)+z＊j(t)がRBより大きい場合は、新たなコンテンツ取得要求を送出するとボトルネックリンクの輻輳を招く。それを回避するために、クライアントjをターゲットとする新規取得要求の送出を中止するか、送出する代わりに他の実行中のコンテンツ取得要求を中止する必要がある。そこで中止可能な取得要求があるか先読み制御部202Eは確認し、存在すれば中止候補として選択する（ステップＤ１２０）。最も単純なやり方としては、ターゲットクライアントのバッファ余裕の大きい取得要求から順に中止候補としていくことである。新規ターゲットクライアントjのバッファ余裕よりも大きなバッファ余裕を持つクライアントをターゲットとする取得要求が存在する場合、先読み制御部202Eはこれらを中止候補として選択する。ただし、相対的なバッファ余裕の大小のみで取得要求を中止して行くと、全ての要求のバッファ余裕が単調に減少し、結局全てのクライアントの視聴品質が劣化する恐れがある。そこで、ターゲットクライアントの見込みバッファ余裕値が、設定した最低バッファ余裕閾値以下の取得要求は中止候補としないとする。
【０１７８】そして先読み制御部202Eは、これら中止候補の取得要求を中止することでボトルネックの見込み帯域使用幅をボトルネック限界レート以下にできるか計算する（ステップＤ１３０）。例えば、実行中の取得要求の対象であるクライアントのバッファ余裕を調べたところ、バッファ余裕がクライアントjよりも大きいクライアントが、k1、k2、…、kvだけあったとする。つまり、bj(t)＜bki(t) (i=1、2、…、v)であったとする。これらの要求を全て中止しても見込み帯域使用幅がボトルネック限界レート以下にならないならば、先読み制御部202Eはクライアントjをターゲットとする新規取得要求の送出を中止する（ステップＤ１５０）。具体的に示すと、オリジンサーバからストリームプロキシサーバ20Eへの取得レートが受信状況監視部202E-1での測定結果から、zki(t) (i=1、…、v)と与えられているとして、【数９】
が成り立たないならば、新規取得要求は中止される。そして先読み制御部202Eはクライアントjの取得要求送出バッファ余裕値THLjを現在のバッファ余裕よりも小さく設定し（ステップＤ１６０）、ステップＤ１０に戻る。これは、ターゲットをクライアントjとするコンテンツ断片取得要求が発生するまでの時間間隔をあけるためである。
【０１７９】
【数１０】
が成り立つならば、先読み制御部202Eは見込み帯域使用幅がボトルネック限界レート以下にするのに必要なだけの要求を中止する（ステップＤ１４０）。具体的には、【数１１】
が成り立つなら、このw個の要求を先読み制御部202Eは中止する。先読み制御部202Eはトランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０１８０】以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０１８１】第６の実施の形態の効果は、ネットワークの輻輳状況に適応した制御が実現できることである。ボトルネック帯域の使用状況を監視することで、ネットワークを輻輳させないように送出する要求の数を調整することができる。その際にバッファ余裕の小さい要求を優先することで、より多くの取得要求のバッファ余裕の枯渇を防ぐことができる。それによりより多くのクライアントに安定して高品質のストリーム配信を実現できることである。
【０１８２】（第７の実施の形態）第６の実施の形態で、中止取得要求の候補を選択するときに、ターゲットクライアントのバッファ余裕が大きいものから候補として行った。これを別の指標により取得要求間に優先度を設定し、その優先度の低い順に中止候補として選択して行くという方式がある。例えば、以下のような例を挙げることができる。
（１）要求するコンテンツの位置するオリジンサーバ毎に優先度を設定する。
（２）要求を実行したクライアント毎に優先度を設定する。
（３）コンテンツ毎に優先度を設定する。
【０１８３】第７の実施の形態の効果は、要求間にバッファ余裕以外の差別化を導入できることである。ターゲットとするクライアントのバッファ余裕が小さくなれば、新たな要求を送出すべきであるので要求生成のタイミングを決定するのに不可欠であるが、実行する要求間の優先順位は必ずしもバッファ余裕で決定する必要は無い。中止取得要求間の候補を上記指標で決定することで、要求の優先順位付けが実現できる。
【０１８４】（第８の実施の形態）第５、第６、第７の実施の形態では、コンテンツの取得要求は、クライアントからの視聴リクエストがストリーム配信制御部201Eを通じて先読み制御部202Eに到着したとき、またはクライアントのバッファ余裕が取得要求送出バッファ余裕閾値以下になった場合に発生する、としていた。その時のバッファ余裕から取得要求を行うコンテンツ断片を決定していた。
【０１８５】しかしこの方法では、現在はバッファ余裕があっても、コンテンツを取得中のストリームプロキシサーバ20Eとオリジンサーバの間に張られたコネクションのパス上に位置する特定のリンクが急激に輻輳して来ている場合は、バッファ余裕が少なくなってからコンテンツ断片の取得要求を送出するのでは取得が間に合わず、バッファの枯渇、それに伴うクライアントの視聴品質の劣化が起こる可能性がある。
【０１８６】この問題を回避するには、バッファ余裕を取得レートや視聴レートも考慮した尺度として定義し直し、その新たに定義されたバッファ余裕を基にした制御を行えば良い。そこでバッファ余裕に代わる指標として、見込みバッファ余裕を定義する。見込みバッファ余裕とは、現在時刻よりも先の指定時刻において期待されるバッファ余裕と定義される。
【０１８７】見込みバッファ余裕を算出する指定時刻と現在時刻の差をDT（秒）とする。現在時刻tからＤＴ先の指定時刻までにオリジンサーバからプロキシストリームサーバ20Eが獲得できるコンテンツの範囲をCT（秒）とする。現在のバッファ余裕をbi(t)とすると、見込みバッファ余裕b＊i(t)は、b＊i(t)=bi(t)-DT+CTで算出できる。
【０１８８】この第８の実施の形態では、コンテンツ断片を取得する際のレートとクライアントの視聴レートの大小関係と、現在のバッファ余裕から、定義した見込みバッファ余裕を算出し、それに基づいた制御を行う。以下大まかな方針を示す。
【０１８９】バッファが枯渇寸前の場合（バッファ余裕が０に近い場合）は、コンテンツ断片取得を行うべきかどうかはコンテンツ断片を取得する際のレートとユーザの視聴レートの大小関係で決定される。取得レートが視聴レートよりも低ければ、バッファ余裕が回復する見込みは無い。見込みバッファ余裕は０と算出される。この場合、すぐにクライアントへの配信は中断されるのでコンテンツ断片を取得することは帯域の輻輳を助長するだけである。よってさらなるコンテンツ断片の要求は中止する。それに対して、取得レートがクライアントの視聴レートよりも大きければ、バッファが枯渇寸前であってもバッファ余裕を回復することが可能である。つまり見込みバッファ余裕がある程度の値になることを期待できる。そのため、ある程度広い範囲のコンテンツ断片を要求することにより、現在確保できる取得レートをできるだけ長期間維持し、バッファ余裕の回復を行うべきである。
【０１９０】次にバッファ余裕が（枯渇寸前というほどではないが）あまり無い場合を考える。取得レートが視聴レートより大きい場合は上記と同様に、見込みバッファ余裕がある程度の値になることを期待できる。ある程度広い範囲のコンテンツ断片を要求することで、現在確保できる取得レートをできるだけ長期間維持し、バッファ余裕の回復を行うべきである。取得レートが視聴レートよりも小さい場合は、バッファ余裕はさらに減少する。つまり見込みバッファ余裕は０に近くなる。このままではバッファが枯渇してしまうのでできるだけ早く適切な取得レートを確保したい。そのためには、ターゲットとするクライアントのバッファ余裕が大きい要求があれば、取得を中断させ、その要求が使っていた帯域を譲り受け、必要な取得レートを確保したい。しかし他の要求を中断させることが可能なのは、より大きなバッファ余裕を持つ要求が存在する場合である。そのような要求が存在しない場合は、必要とする取得レートを確保することは不可能である。しかし、必要な取得レートが確保できるまで全くコンテンツ断片を取得しないと、すぐにバッファが枯渇してしまう（見込みバッファ余裕が０となる）。よってとりあえず可能な取得レートでコンテンツ断片を取得してバッファが枯渇するまでの時間を引き延ばす必要がある。しかし、そのままの取得レートが長期間続いても、ターゲットとするクライアントのバッファ余裕が枯渇するのも明らかである。取得レートが視聴レートを上回る場合に比べて、短い期間でコンテンツ断片の取得を終了させ、必要な取得レートを確保できないか確認すべきである。そこで、この小さな取得レートで確保する期間、つまり要求するコンテンツ断片の範囲を小さくする。
【０１９１】次にバッファ余裕が十分にある場合を述べる。バッファ余裕が十分にあれば一般には今すぐコンテンツ断片を取得する必要は無い。よってコンテンツ断片要求の送出は先送りしてよい。しかし、取得レートが視聴レートに比べ、著しく低くなっている場合はその限りでない。この場合、ネットワークが著しく輻輳してきていることを意味する。この場合、現在は十分にあるバッファ余裕がすぐになくなることを意味する。つまりコンテンツ断片取得を行わなければ、見込みバッファ余裕は０に近くなる。この場合は、確保できる取得レートで良いのでコンテンツ断片を取得し、ネットワークの輻輳が解消するまでバッファが枯渇しないように凌ぐべきである。
【０１９２】以上がおおまかな方針である。
【０１９３】以下この見込みバッファ余裕を用いた制御による第８の実施の形態の詳細をフローチャートである図２８と構成図である図２６を用いて説明する。
【０１９４】コンテンツ取得要求の生成は、クライアントからの視聴リクエストの到着、または以下で説明するクライアント毎に設定されるコンテンツ断片取得要求送出時刻に発生する。先読み制御部202Eは、ストリーム配信制御部201Eからの視聴リクエストの到着、コンテンツ断片取得要求送出時刻のイベントを監視し、新規取得要求の生成を待つ。そして新規ターゲットクライアントjを決定する（ステップＥ１０）。
【０１９５】まず、現在時刻での実際のクライアントjのバッファ余裕を確認する（ステップＥ２０）。もしバッファ余裕bj(t)がクライアント毎に指定された希望バッファ余裕値THSjより大きく(bj(t)＞THSj)、かつクライアントjをターゲットとした要求の取得レートが、クライアントjの視聴レートを超えている場合は、まだ余裕があると判断し、新規取得要求の送出を中止する（ステップＥ１６０）。そして、コンテンツをクライアントが視聴中なら、次回要求生成時刻を設定する（ステップＥ１７０）。次回要求生成時刻の設定法は、後述するステップ（ステップＥ１４０）で説明する。バッファ余裕がTHSj以下、またはバッファ余裕はTHSjを超えるがクライアントjをターゲットとした要求の取得レートが、クライアントjの視聴レートを下回る場合は、ステップＥ３０に進む。
【０１９６】bj(t)≦THMjの場合は、先読み制御部202Eは、ネットワーク情報収集部207Eからボトルネックリンクの帯域使用幅RA(t)を得る（ステップＥ３０）。ネットワーク情報収集部207EのRA(t)を得る方法は、第５の実施の形態と同様である。
【０１９７】先読み制御部202Eは、クライアントjをターゲットとした新規取得を実行した際のストリームプロキシサーバ20Eがオリジンサーバからコンテンツを取得する際のレートを予測する（ステップＥ４０）。このレートを先読み取得予測レートと呼び、z＊j(t)で表すことにする。このz＊j(t)の推定方法は第６の実施の形態と同様とする。
【０１９８】ボトルネックリンクにその先読み取得予測レートのトラヒックが加わった際の見込み帯域使用幅RA(t)+z＊j(t)がボトルネック限界レートRBを超えないか確認する（ステップＥ５０）。超えない場合は、ステップＥ６０に進む。
【０１９９】見込み帯域使用幅RA(t)+z＊j(t)がRBより大きい場合は、新規取得要求を送出するとボトルネックリンクの輻輳を招く。それを回避するために、新規取得要求の送出をやめるか、送出する代わりに他の実行中のコンテンツ断片の取得要求を中止する必要がある。そこで先読み制御部202Eは中止可能な取得要求があるか確認し、存在すれば中止候補として選択する（ステップＥ１８０）。最も単純なやり方としては、見込みバッファ余裕の大きいものから順に中止候補としていくことである。
【０２００】指定時間幅PT先の見込みバッファ余裕を比較するとする。要求を送出してから実際に中止されるまでには、プロキシストリームサーバ20Eからオリジンサーバまでパケットが届く時間だけかかる。クライアントiをターゲットとしたコンテンツ断片の取得要求を中止するために要する時間をRCSiで表すことにする。ここで、RCSiは、受信状況監視部202E-1で測定されているクライアントiをターゲットとする取得要求のRTTであるRTTiの半分などと近似すればよい。
【０２０１】説明を簡単にするために、クライアントiをターゲットとしたコンテンツ断片の取得レートがほぼ変動なくziであり、視聴レートもCBRでriだったとする。すると、クライアントiへの要求を中止した場合の見込みバッファ余裕b＊i(t)は、現在のバッファ余裕をbi(t)とすると、b＊i(t)=bi(t)-PT+(zi-ri)×RCSiとされる。
【０２０２】新たなコンテンツ取得要求を行うクライアントjの見込みバッファ余裕b＊j(t)よりも大きな見込みバッファ余裕を持つクライアントをターゲットとする取得要求が実行中の場合、これらを中止候補として選択する。ただし、相対的な見込みバッファ余裕の大小のみで取得要求を中止して行くと、全ての要求のバッファ余裕が単調に減少し、結局全てのクライアントへの配信品質が劣化する恐れがある。そこで、ターゲットクライアントの見込みバッファ余裕値が、設定した最低見込みバッファ余裕閾値以下の取得要求は中止候補としないとする。
【０２０３】そしてこれら中止候補の取得要求を中止することでボトルネックの見込み帯域使用幅をボトルネック限界レート以下にできるか調べる（ステップＥ１９０）。例えば、実行中の取得要求の対象であるクライアントの見込みバッファ余裕を調べたところ、見込みバッファ余裕がクライアントjよりも大きいクライアントが、k1、k2、…、kvだけいたとする。つまり、b＊j(t)＜b＊ki(t) (i=1、2、…、v)であったとする。そして、クライアントk1、k2、…、kvの現在時刻ｔでの取得レートが、zk1(t)、zk2(t)、…、zkv(t)であるとする。これらの要求を全て中止しても見込み帯域使用幅がボトルネック限界レート以下にならない、つまり【数１２】
ならば、先読み制御部202Eはクライアントjからの新たな要求の送出を中止する（ステップＥ２１０）。そして、クライアントjをターゲットとするコンテンツ断片の取得要求送出時刻を、後述のステップＥ１４０で示す方法に従い設定する。
【０２０４】ステップＥ１９０において、中止候補の要求の幾つかを中止することで見込み帯域使用幅がボトルネック限界レート以下にできるならば、ステップＥ６０に進み、ステップＥ６０でバッファ余裕がTHLMINjより大きければ、見込み帯域使用幅がボトルネック限界レート以下にできるだけの要求を中止する（ステップＥ２００）。この時、【数１３】
が成り立つなら、このw個の要求を中止する。
【０２０５】新規取得要求を送出するために必要な帯域が確保できたとステップＥ５０で判断されると、先読み制御部202Eは、ステップＥ７０以下の要求するコンテンツ断片の範囲の算出に進もうとする。しかし、算出された先読み取得予測レートz＊j(t)が小さい場合、先読みを行ってもバッファの枯渇（バッファ余裕が０となること）が避けられない。このような場合は、新規取得要求を断念すべきである。その判断をステップＥ６０で行う。具体的には、バッファ余裕bj(t)が指定された最低バッファ余裕値THLMINj以下であるならば、新規取得要求の送出を中止するためにステップＥ２１０に進む。バッファ余裕がTHLMINjより大きければ、ステップＥ２００に進み上記のように候補要求の中止を行うと共に、ステップＥ７０以下に進み、新規取得要求の送出を行う。
【０２０６】ステップＥ７０では、新規取得要求のコンテンツ断片の範囲の算出を行う。まず開始位置は前回要求の終了位置と現在視聴位置のうち大きいほうの値に一致する。これは第５の実施の形態と同様である。終了位置は、取得要求の実行完了時の見込みバッファ余裕を希望バッファ余裕値THSjにできる位置とする。例えば、ストリームが固定視聴レートrjのCBRとしてエンコードされていて、プロキシストリームサーバ20Eがオリジンサーバからストリームデータを取得するレートがコンスタントにzjである場合の終了位置の算出法を説明する。プロキシストリームサーバ20Eは、要求した開始位置のデータの到着から、終了位置のデータの到着までの間、(zj-rj)のレート（bps）でバッファを増加する。これをバッファ余裕に換算すると、単位時間あたりに(zj-rj)/rj秒分のバッファ余裕が生じていることになる。プロキシストリームサーバ20Eが、コンテンツ取得要求を送信してから、終了位置のデータを受信するまでの時間をSTと置くと、ST後の見込みバッファ余裕b＊j(t+ST)は、要求送信から開始位置のデータ受信までのRTTであるRTTjも考慮すると、【数１４】
となる。b＊j(t+ST)=THSjとなるのは、【数１５】
である。ここで、（データ取得完了予定時刻がRTTよりも短く設定されるのはおかしいので）ST＞RTTjでなければならない。よって、THSj＞bj(t)の時は、zj＞rjで無ければならない。THSj＞bj(t)かつzj≦rjの時の対応は別途検討する。THSj≦bj(t)の時は、ステップＥ２０で、取得レートが視聴レートを超えるケースは除かれているので、必ずzj＜rjとなっているので、ST＞RTTjが成立している。ST＞RTTjを満たす場合、ST秒後に得られるコンテンツの範囲CSTは、【数１６】
となる。よって終了位置は、開始位置＋CSTと設定する。こうすることで、現在時刻からST秒後に、クライアントjのバッファ余裕が、THSjになっていることが期待できる。
【０２０７】しかし、THSj＞bj(t)かつzj≦rjの時は、バッファ余裕をTHSjにすることはできない。しかし、バッファ余裕を希望バッファ余裕値にできないから全く取得要求を出さないと、さらにバッファ余裕は切迫する。適当なコンテンツ断片の範囲を設定して取得を実行すべきであるが、あまり長い範囲を要求するのは、取得レートを確保するタイミングを遅らせることになってしまい、バッファ余裕が切迫する原因となる。早めに次回の取得要求が実行されるように範囲は小さく設定しすることが望ましい。そこで、最低バッファ余裕値THLMINjを指定し、見込みバッファ余裕がTHLMINjとなる範囲を先読み制御部202Eは設定する。b＊j(t)=THLMINjとなるのは、【数１７】
である。ST＞RTTjでなければならない。bj(t)≦THLMINjのケース（最低バッファ余裕値を確保できないケース）は既にステップＥ６０で除外されているので、必ずST＞RTTjとなっている。bj(t)＞THLMINjの際は、【数１８】
の範囲を要求する。終了位置をこのCSTを用いて、開始位置＋CSTと設定する。こうすることで、現在時刻からST秒後のクライアントjのバッファ余裕は、THLMINj以下にならないことが期待できる。
【０２０８】そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＥ８０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０２０９】そして、送出した要求の中止（ステップＥ１１０）、または送出した要求によるコンテンツ断片の取得完了（ステップ１００）のいずれかのイベントが発生するのを先読み制御部202Eは待つ（ステップＥ９０）。
【０２１０】コンテンツ断片の取得が完了した場合（ステップ１００）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＥ１２０）。次回要求送出時刻は、バッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、b＊j(t+XT)=bj(t)-XTである。これがTHLjとなるのは、XT=bj(t)-THLj秒後である。現在時刻＋XTを次回取得要求送出時刻として設定する。もしTHLj＞bj(t)ならば、バッファ余裕が十分に無いことを意味するので、現在時刻を次回要求取得送出時刻として設定し、直ちにステップＥ１０に戻る。
【０２１１】コンテンツ断片の取得要求の中止の場合（ステップＥ１１０）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＥ１４０）。中止の場合、次回の要求送出までの間隔をある程度空けなければならない。直ちに再要求を実行することは、ネットワークの輻輳に拍車をかけることになるからである。現在のバッファ余裕値が、bj(t)＞THLjの場合は、次回要求生成時刻は、完了時と同様にバッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻とすればよい。それに対し、現在のバッファ余裕値が、bj(t)≦THLjの場合は、次回要求送出時刻は、見込みバッファ余裕が最小バッファ余裕値THLMINjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLMINj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、b＊j(t+XT)=bj(t)-XTである。これがTHLMINjとなるのは、XT=bj(t)-THLMINj秒後である。現在時刻＋XTを次回取得要求送出時刻として設定する。もしTHLMINj ＞bj(t)ならば、バッファ余裕が視聴品質を保つのには不十分と判断しクライアントjをターゲットとしたコンテンツ断片の取得はあきらめるものとする（ステップＥ１５０）。
【０２１２】また、以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０２１３】第８の実施の形態の効果は、取得レートや視聴レートを考慮してバッファ余裕を予測することでネットワークの急激な状況変化に即応できることである。
【０２１４】（第９の実施の形態）これまでの実施の形態では、ネットワーク層において全てのパケットは公平に扱われることを前提としていた。しかし、ネットワーク層に幾つか通信速度が異なるクラスが存在する場合もある。その例として、TCP RenoとTCP Vegasが混在する場合が挙げられる。TCP VegasはTCP Renoに帯域を譲る傾向が知られている。そのため、TCP RenoとTCP Vegasのどちらのプロトコルを利用するかでコンテンツ断片の取得速度が異なる。
【０２１５】また別の例として、Diffservが挙げられる。Diffservでは、トラヒックをクラス分けし、クラス毎に異なる優先度で処理する設定が可能である。例えば、EFクラスには、設定されたPIRと呼ばれる値までのレートと指定されたラウンドトリップタイムを保証し、AF１〜AFｎのクラスには、設定されたCIR1〜CIRnの値の重み付けラウンドロビンでのベストエフォート処理をする、などの設定が可能である。この場合、どのクラスを選択するかにより、処理速度が異なる。
【０２１６】第９の実施の形態では、このような複数のクラスが存在しその処理速度が異なる場合に、クラスを適切に使いこなすことで、より多くのクライアントが配信品質を維持するために十分なバッファ余裕を確保できる制御方式を示す。第６、７、８の実施の形態では、ボトルネックを競合する要求間での調整を、要求の中止、実行いずれかのみで調整していた。これをクラスを使い分けることでさらに粒度の細かい制御が可能となる。
【０２１７】図２９のフローチャートと図２６の構成図を用いて、第９の実施の形態を説明する。以下、説明を一般化するため、トランスポート層には、クラス1からクラスｋまでのｋ種類のクラスが存在するとする。
【０２１８】要求の生成のタイミングは、第５、第６、第７の実施の形態のように、クライアントからの視聴リクエスト到着またはバッファ余裕が取得要求送出バッファ余裕値を下回ったとき、としても良いし、第８の実施の形態のようにクライアントからの視聴リクエストの到着時または設定された取得要求送出時刻、としても良い。ここでは、クライアントjからの視聴リクエスト到着またはクライアントjのバッファ余裕が取得要求送出バッファ余裕値を下回ったときとして説明する。これらのイベントを検出したとき、先読み制御部202Eは新規ターゲットクライアントjを決定する（ステップＦ１０）。
【０２１９】まず先読み制御部202Eはネットワーク情報収集部207Eから現在時刻ｔでのボトルネックリンクの帯域使用幅RA(t)を得る（ステップＦ２０）。ネットワーク情報収集部207Eのボトルネックリンクの帯域使用幅RA(t)の取得法は、第７の実施の形態と同様である。
【０２２０】次に、各クラスの先読み取得予測レートを算出する（ステップＦ３０）。先読み制御部202Eは、この新規取得要求を各クラスで実行した際の取得速度を推定する。クラスqでクライアントjをターゲットとした新規取得要求を実行した際の時刻ｔでの取得予測レートをz＊j(q、t)で表すことにする。クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことのあるクラスに対する取得予測レートは、その最新の取得レートで近似することができる。最新の取得レートは、受信状況監視部202E-1で記録されている。クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことはあるが、一部のクラスは取得に使われたことがない場合は、取得に使われたクラスにおける最新のレートから、取得されたことのないクラスでの取得予測レートを換算する。
【０２２１】この換算法の具体例を１つ示すことにする。Diffservによる優先制御が行われていて、EF、 AF1、 AF2の３つのクラスがあり、EFはPIRのピークレート保証、AF1とAF２はそれぞれ重みCIR1、 CIR2でのベストエフォートでの処理がされているとする。EFをクラス1、 AF1をクラス2、 AF2をクラス3とし、AF1での最新の取得レートzj(2、 s) (s＜t、 tは現在時刻)のみが受信状況監視部202E-1に記録されているとする。このとき、EFではピークレートが保証されているので、先読み制御部202EはEFでの取得予測レートはz＊(1、t)=PIRと算出できる。AF1で取得予測レートは、この最新値で近似することで、z＊(2、t)=z＊(2、s)とできる。EF2の取得予測レートは、重み付けを用いて、z＊(3、t)=z＊(2、t)×CIR2/CIR1と換算することができる。
【０２２２】クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことのない場合でも、同一のコンテンツが他のクライアントをターゲットとして取得さ� | |