JP4126928B2 - プロキシサーバ及びプロキシ制御プログラム - Google Patents
プロキシサーバ及びプロキシ制御プログラム Download PDFInfo
- Publication number
- JP4126928B2 JP4126928B2 JP2002054196A JP2002054196A JP4126928B2 JP 4126928 B2 JP4126928 B2 JP 4126928B2 JP 2002054196 A JP2002054196 A JP 2002054196A JP 2002054196 A JP2002054196 A JP 2002054196A JP 4126928 B2 JP4126928 B2 JP 4126928B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- acquisition
- rate
- client
- control unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 239000000872 buffer Substances 0.000 claims description 402
- 239000012634 fragment Substances 0.000 claims description 175
- 238000009825 accumulation Methods 0.000 claims 1
- 230000005540 biological transmission Effects 0.000 description 90
- 238000000034 method Methods 0.000 description 87
- 230000008685 targeting Effects 0.000 description 71
- 230000008569 process Effects 0.000 description 36
- 238000010586 diagram Methods 0.000 description 30
- 238000012544 monitoring process Methods 0.000 description 20
- 238000012545 processing Methods 0.000 description 19
- 230000000694 effects Effects 0.000 description 18
- 230000006870 function Effects 0.000 description 18
- 230000007423 decrease Effects 0.000 description 14
- 238000004891 communication Methods 0.000 description 9
- 230000006866 deterioration Effects 0.000 description 9
- 230000008859 change Effects 0.000 description 8
- 230000003247 decreasing effect Effects 0.000 description 8
- 230000004044 response Effects 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000009467 reduction Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 102100023778 Corepressor interacting with RBPJ 1 Human genes 0.000 description 5
- 101000906759 Homo sapiens Corepressor interacting with RBPJ 1 Proteins 0.000 description 5
- 239000012464 large buffer Substances 0.000 description 5
- 101000636811 Homo sapiens Neudesin Proteins 0.000 description 4
- 102100031903 Neudesin Human genes 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000015556 catabolic process Effects 0.000 description 3
- 239000001752 chlorophylls and chlorophyllins Substances 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 238000004904 shortening Methods 0.000 description 3
- 239000005711 Benzoic acid Substances 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 238000002372 labelling Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 239000004334 sorbic acid Substances 0.000 description 2
- 239000004173 sunset yellow FCF Substances 0.000 description 2
- OAWXYINGQXLWOE-UHFFFAOYSA-N (2-acetyloxybenzoyl) 2-acetyloxybenzoate Chemical compound CC(=O)OC1=CC=CC=C1C(=O)OC(=O)C1=CC=CC=C1OC(C)=O OAWXYINGQXLWOE-UHFFFAOYSA-N 0.000 description 1
- 241001522296 Erithacus rubecula Species 0.000 description 1
- KDXKERNSBIXSRK-UHFFFAOYSA-N Lysine Natural products NCCCCC(N)C(O)=O KDXKERNSBIXSRK-UHFFFAOYSA-N 0.000 description 1
- 239000004472 Lysine Substances 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- VTYYLEPIZMXCLO-UHFFFAOYSA-L calcium carbonate Substances [Ca+2].[O-]C([O-])=O VTYYLEPIZMXCLO-UHFFFAOYSA-L 0.000 description 1
- 239000004106 carminic acid Substances 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000004335 litholrubine BK Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000010187 selection method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
- H04L67/5681—Pre-fetching or pre-delivering data based on network characteristics
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Library & Information Science (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、コンテンツの一部または全部を記憶装置に溜め、そこからクライアントにコンテンツをストリーム配信しながら、該コンテンツの保持していないコンテンツ断片をオリジンサーバから取得して記憶装置に追加するストリームプロキシサーバに関し、特にネットワークを流れる他のトラヒックへの影響を抑えてオリジンサーバからのコンテンツの取得を実現するストリームプロキシサーバおよびネットワーク技術に関する。
【従来の技術】
図３４に従来のストリームプロキシサーバを用いたネットワークの構成図を示す。従来のストリームプロキシサーバ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になるまでの時間を延ばすことが出来、それまでの間に一時的な輻輳が解消すれば、クライアントの視聴品質の悪化をなくすことが可能であるが、従来のストリームプロキシサーバではこれは出来ない。
【００１８】
また、バッファ余裕以外の要因（視聴しているクライアントやコンテンツなど）に依存して、取得レートを決定する事を行う事が出来ない。このため、特定のクライアントやコンテンツについての取得レートをより高く設定して、そのクライアントやコンテンツの視聴品質の悪化を防ぐという事が出来ない。
【００１９】
本発明の第１の目的は、ネットワークを流れる他のトラヒックへの影響を極力抑えてオリジンサーバからのコンテンツの取得を実現することができるプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２０】
本発明の第２の目的は、オリジンサーバからのコンテンツ取得レートを制御し、同一のボトルネックを共有するコンテンツの間で帯域の割り当て制御を行うことにより、視聴品質の悪化が起こる可能性を極力抑えることを可能としたプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２１】
本発明の第３の目的は、オリジンサーバからのコンテンツ取得レートを制御することにより、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を最小限に抑えることを可能とするプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２２】
【課題を解決するための手段】
本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、記憶装置からクライアントにコンテンツを配信しながら、コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシサーバにおいて、各コンテンツのクライアントへの配信レートと、コンテンツのオリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量がコンテンツの受信バッファ閾値を上回るもののコンテンツ取得には、低優先のトランスポート層プロトコルを使用し、受信バッファ量が受信バッファの閾値を下回る量が大きいものほどコンテンツ配信レートより高い取得レートとし、かつ、各コンテンツの取得レートを合計したレートがネットワークの空き帯域を越えないように、各コンテンツの取得レートを制御し、各コンテンツの受信バッファ閾値と、各コンテンツの現在の受信バッファ量から、各コンテンツの希望取得レートを決定し、現在配信を行っている全コンテンツの希望取得レートの合計が、オリジンサーバとプロキシサーバの間のネットワークの空き帯域を越えない場合には、各コンテンツの取得レートを、前記希望取得レートとし、そうでない場合には、あらかじめ決められたコンテンツの優先度の高い順に、前記希望取得レートを、希望取得レートの合計が、前記ネットワークの空き帯域を越えないコンテンツまで割り当てることを特徴とする。
【００２５】
請求項２の本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、各コンテンツの前記クライアントへの配信レートと、該コンテンツの前記オリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量が該コンテンツの前記受信バッファ閾値を上回るもののコンテンツ取得には、低優先のトランスポート層プロトコルを使用し、前記受信バッファ量が前記受信バッファの閾値を下回る量が大きいものほどコンテンツ配信レートより高い取得レートとし、かつ、各コンテンツの取得レートを合計したレートがネットワークの空き帯域を越えないように、各コンテンツの取得レートを制御することを特徴とする。
【００２６】
請求項３の本発明のプロキシサーバは、各コンテンツの前記受信バッファ閾値と、各コンテンツの現在の受信バッファ量から、各コンテンツの希望取得レートを決定し、現在配信を行っている全コンテンツの希望取得レートの合計が、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、各コンテンツの取得レートを、前記希望取得レートとし、そうでない場合には、あらかじめ決められたコンテンツの優先度の高い順に、前記希望取得レートを、希望取得レートの合計が、前記ネットワークの空き帯域を越えないコンテンツまで割り当てることを特徴とする。
【００３４】
請求項４の本発明のプロキシサーバは、コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分を、コンテンツを分割した断片としてオリジンサーバから取得し、バッファに追加するプロキシサーバにおいて、現在より先の時刻での各クライアントの見込みバッファ量を、現在の取得レート、および、視聴レートから求め、前記見込みバッファ量がゼロ以下のコンテンツは取得を中止し、前記見込みバッファ量があらかじめ決められたバッファ閾値を下回ったコンテンツについて、前記ストリームの過去のオリジンサーバからのコンテンツ取得レートの履歴から決められる予測取得レートが、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、該コンテンツ取得を行い、そうでない場合には、バッファ量が前記閾値を越えているストリームのコンテンツ取得を、低優先のトランスポート層プロトコルを用いて行うことを特徴とする。
【００３５】
請求項５の本発明のプロキシサーバは、前記低優先のトランスポート層プロトコルとして、TCPVegasを用いて行うことを特徴とする。
【００３８】
請求項６の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、各コンテンツの前記クライアントへの配信レートと、該コンテンツの前記オリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量が該コンテンツの受信バッファ閾値を上回るコンテンツの取得には、低優先のトランスポート層プロトコルを使用することを特徴とする。
【００５３】
【作用】
ネットワーク情報収集手段によって、ネットワークの残余帯域の情報を収集し、取得レート決定手段において、この残余帯域に基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５４】
また、ネットワークがトランスポート層プロトコル決定手段によって、複数の異なる帯域共有特性を持つトランスポート層プロトコルから、ネットワークを流れる他のトラヒックへの影響の小さいトランスポート層プロトコルを決定し、複数の異なる帯域共有特性を持つトランスポート層プロトコルを用いたデータ送受信が出来るトランスポート層プロトコル制御手段を用いて、コンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５５】
また、バッファ余裕測定手段によって、各コンテンツのバッファ余裕の大きさを求め、それに基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５６】
また、指定優先度を考慮した取得レートを決定する手段によって、オリジンサーバからの取得レートを指定優先度も考慮して決定し、優先度の高い視聴に関してより高い取得レートを割り当て、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第３の目的である、ストリームプロキシサーバにおいて、指定優先度に従い、優先度の高い視聴に関して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５７】
また、バッファ余裕に基づいてオリジンサーバからのコンテンツ取得要求を送出する先読み手段を用いることで、過剰な先読み要求の送出が抑制され、さらにコンテンツを部分的なコンテンツ断片として取得要求を行う先読み制御手段を用いてコンテンツを時間的に分割して取得することで、ネットワーク本発明の第１の目的である、オリジンサーバからのコンテンツ取得をネットワークに流れる他のトラヒックへの影響を抑えて実現することが可能となる。
【００５８】
また、ネットワーク情報収集手段と、同時に実行される取得要求間の優先度を判別する手段と、優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制されることで、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００５９】
また、優先度をバッファ余裕の大小で決定する手段とその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６０】
また、優先度を要求が取得しようとするコンテンツを蓄積しているオリジンサーバにより決定する手段により、コンテンツが蓄積されているオリジンサーバを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６１】
また、優先度を要求により獲得したコンテンツ断片のデータをストリーム配信するクライアントにより決定する手段により、配信対象となるクライアントを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６２】
また、優先度を要求したコンテンツにより決定する手段により、コンテンツを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能である。
【００６３】
また、バッファ余裕の変化を予測し、バッファ余裕が将来不足しそうな場合に、後続のコンテンツ断片の取得要求を送出する先読み制御手段により、より時間的な余裕を持った要求間での帯域の融通が可能となり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６４】
また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段を使い分けて実行する手段により、ネットワークの輻輳を抑制した取得を選択できる可能性がより高くなり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６５】
また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段として優先制御をもったネットワーク層プロトコルを利用する手段により、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 は、TCP Renoと帯域を共有した場合、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からTCP Renoへの変更であったならば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をターゲットとしたコンテンツ断片の取得が既に実行されたことのない場合でも、同一のコンテンツが他のクライアントをターゲットとして取得されたことがあれば、受信状況監視部202E-1に記録されているその最新取得レートで各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２３】
同一のコンテンツが他のクライアントをターゲットとして取得されたことも無ければ、先読み制御部202Eは同一のオリジンサーバからの取得レートが受信状況監視部202E-1に記録されていないか調べる。そしてこの最新値で各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２４】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことも、同一のコンテンツが他のクライアントをターゲットとして取得されたことも、同一のオリジンサーバからの取得実績もない場合、各クラスに対するデフォルト値を用いることで、取得予測レートを設定することができる。
【０２２５】
次に先読み制御部202Eは、指定時間WT後の見込みバッファ余裕を指定した希望バッファ余裕値BTHjにできるクラスが存在するか確認する（ステップＦ４０）。例えば、ユーザの視聴レートが一定でrjであったとすると、
BTHj≦bj(t)+(z＊j(q、t)-rj)×(WT-RTTj、q)
の条件を満たすクラスが存在するかを確認することになる。この条件を満たすクラスが存在する場合は、条件を満たす最も小さいクラスをhとする。このhを最低必要クラスと呼ぶ。ここで、RTTj、qは、クラスqでクライアントjをターゲットとする取得要求を送出してから、開始位置のデータがプロキシサーバに到着するまでの時間である。
【０２２６】
この各クラスでのラウンドトリップタイムRTTj、qは、受信状況監視部202E-1にクライアントjをターゲットとした取得がクラスqで行われた実績があれば記録されている。記録されている場合は、この値を用いれば良い。記憶されていない場合は、適当な記録されているラウンドトリップタイムから換算するか、適当なデフォルト値を用いることになる。
【０２２７】
ラウンドトリップタイムの換算法の具体例を１つ示すことにする。Diffservによる優先制御が行われていて、EF、 AF1、 AF2の３つのクラスがあり、EFはラウンドトリップタイムがRTT1以下に保証されていて、AF1とAF２はそれぞれ重みCIR1、 CIR2でのベストエフォートでの処理がされているとする。EFをクラス1、 AF1をクラス2、 AF2をクラス3とし、EF1での最新のRTT、RTTj、2のみが受信状況監視部202E-1に記録されているとする。このとき、EFではRTTj、1=RTT1と算出できる。AF1でのRTTは、この最新値を用いれば良い。EF2のRTTは、重み付けを用いて、RTTj、3=RTTj、2×CIR1/CIR2と換算することができる。
【０２２８】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことのない場合でも、同一のコンテンツが他のクライアントをターゲットとして取得されたことがあれば、受信状況監視部202E-1に記録されているその最新RTTで各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２９】
同一のコンテンツが他のクライアントをターゲットとして取得されたことも無ければ、先読み制御部202Eは同一のオリジンサーバからのRTTが受信状況監視部202E-1に記録されていないか調べる。そしてこの最新値で各クラスでのRTTを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２３０】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことも、同一のコンテンツが他のクライアントをターゲットとして取得されたことも、同一のオリジンサーバからの取得実績もない場合、各クラスに対するデフォルト値を用いることで、RTTを設定することができる。
q= h、..、kの中で、(RA(t)+z＊j(q、t))≦RBを満たすものがあるか確認する（ステップＦ５０）。満たすものがあった場合は、ステップＦ６０以降のステップに進むが、なかった場合はステップＦ１４０以下のステップに進む。
(RA(t)+z＊j(q、t)) ≦RB、 q≧hを満たすクラスqが複数存在する場合、そのいずれかのクラスを選択する（ステップＦ６０）。選択方法としては、(RA(t)+z＊j(q、t)) ≦RB、 q≧hを満たすクラスqの中から、
１．最も先読み取得予測レートが大きいクラスを選択、
２．最も先読み取得予測レートが小さいクラスを選択、
３．クライアント毎に与えられている優先度に従い決定する。優先度の高いクライアントほど大きい先読み予測取得レートのクラスを選択する、
などのいずれの方法でも良い。
【０２３１】
クラスが選択できた場合は、取得要求範囲を算出する（ステップＦ７０）。開始位置は、現在の視聴位置もしくはクライアントが視聴中のコンテンツ断片の末尾位置とする。終了位置は、開始位置に(WT+BTHj-bj(t))を加えた位置となる。このような範囲を要求することで、指定時間WT後に、バッファ余裕がBTHjになっていることが期待できる。
【０２３２】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＦ８０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０２３３】
コンテンツ断片の取得要求を送出後は、先読み制御部202Eは以下のいずれかのイベントが発生するのを待つ（ステップＦ９０）。すなわち、クライアントjをターゲットとした取得要求の中止（ステップＦ１２０）と、クライアントjをターゲットとした取得要求の完了（ステップＦ１００）である。
【０２３４】
取得要求が完了のイベントが発生した場合は（ステップＦ１００）、取得要求送出バッファ余裕値THLjを初期値に戻す（ステップＦ１１０）。そして、ステップＦ１０に戻る。
【０２３５】
取得要求が中止された場合は（ステップＦ１２０）、取得要求送出バッファ余裕値THLjを、現在のクライアントjのバッファ余裕より小さい値に設定する（ステップＦ１３０）。例えば、現在の余裕バッファbj(t)のadj倍(adj＜1)などとする。つまり、THLj=adj×bj(t)とする。そしてステップＦ１０に戻る。これは、中止した要求がターゲットとしていたクライアントjを対象とするコンテンツ断片取得の次回取得要求が発生するまでの時間間隔をあけるためである。現在のバッファ余裕より大きい値が取得要求送出バッファ余裕値として指定されると直ちに取得要求が生成されるので、現在のバッファ余裕よりも小さい値を設定する必要がある。
【０２３６】
ステップＦ１１０で初期値に戻すのは、ステップＦ１３０で小さくなった取得要求送出バッファ余裕値をリセットするためである。
【０２３７】
クラスが選択できなかった場合は、いずれかの要求送出を中止する、または実行中の取得の取得レートを引き下げる必要がある。実行中の取得の取得レートを引き下げる際には、処理速度の低いクラスへの切り替えを行う。この作業をクラス下げと呼ぶ。先読み制御部202Eはクラス下げ、または中止となる要求の候補を選択する（ステップＦ１４０）。ステップＦ１４０の詳細を示したフローチャートが図３０である。
【０２３８】
まず、実行中の取得要求のクラス下げ、中止により期待できる削減見込みレートを記憶するパラメータdrを０に初期化する（ステップＧ１０）。
【０２３９】
そして、クラス下げ候補のレート抑制および中止候補の取得中止を実行し、さらに新規取得要求を最低必要クラスで実行した場合の見込み使用帯域幅がボトルネック限界レートRB以下になるかを確認する（ステップＧ２０）。具体的には、最低クラスでの新規取得要求の予測取得レートをz＊j(h、t)とし、現在の使用帯域幅をRA(t)とすると、RA(t)+z＊j(h、t)-dr≦RBが満たされるかを確認する。満たされる場合は、ステップＦ１５０へ進む。満たされない場合は、以下のステップに進む。
【０２４０】
クラス下げ候補／中止候補に含まれない実行中の取得要求の中にターゲットクライアントのバッファ余裕が新規ターゲットクライアントjよりも大きいものがあるか確認する（ステップＧ２０）。ない場合は、クラス下げ候補／中止候補なしとして処理を終了する（ステップＧ４０）。
【０２４１】
クラス下げ候補／中止候補に含まれない実行中の取得要求の中にターゲットクライアントのバッファ余裕が新規ターゲットクライアントjよりも大きいものがが存在する場合、最も大きいクライアントiをターゲットとする取得要求を選択する（ステップＧ５０）。
【０２４２】
この要求の現在の取得クラスをpi、現在の取得レートをzi(qi、t)として、(RA(t)+z＊j(h、t)-(zi(pi、t)- z＊i(hi、t)) ≦RB、 hi＜qとなるクラスhiがあるかを確認する。つまり、見込み使用帯域幅をボトルネックリンク限界レート以下にできるクラスが存在するか確認する（ステップＧ６０）。
【０２４３】
存在した場合は、この要求とクラスhiの組をクラス下げ候補とし、削減見込みレートdrにzi(pi,t)-zi(hi,t)を加える（ステップＧ７０）。そして図２９のステップＦ１５０に進む。
【０２４４】
もし、(RA(t)+z＊j(h、t)-(zi(pi、t)- z＊i(hi、t)) ≦RB、 hi＜qとなるクラスhiを満たすクラスが存在しなければ、このクライアントiをターゲットとする取得要求を中止候補として登録し（ステップＧ８０）、削減見込みレートdrにこの要求の現在の取得レートz＊i(pi、t)を加え、ステップＧ２０に戻る（ステップＧ９０）。
【０２４５】
ステップＦ１４０でクラス下げ候補／中止候補の選択が終了すると、ステップＦ１５０に進む。ステップＦ１５０では、クラス下げ候補／中止候補が登録されているか確認する。登録されていない場合は、新規取得要求の送出を中止し（ステップＦ１７０）、クライアントjの取得要求送出バッファ余裕値を現在のバッファ余裕よりも小さく設定する（ステップＦ１８０）。例えば、現在の余裕バッファのadj倍(adj＜1)などとする。つまり、THLj=adj×bj(t)となどとすればよい。現在のバッファ余裕よりも小さく設定するのは、クライアントjをターゲットとした取得要求が出るまでの間隔を空けるためである。
【０２４６】
もし、クラス下げ候補／中止候補が登録されているならば、候補のクラス下げ、中止を実行する。そして、ステップＦ７０へ進む。
【０２４７】
以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０２４８】
第９の実施の形態の形態の効果は、ボトルネックを競合する要求間での調整を、クラスを使い分けることで第６、７、８の実施の形態に比べより粒度の細かい制御が可能であることである。より有効に空き帯域を利用でき、より効果的に輻輳回避を実現できる。
【０２４９】
（第１０の実施の形態）
第５〜９の実施の形態では、バッファ余裕または見込みバッファ余裕の量に依存して新規のコンテンツ断片取得要求が生成されていた。そして、生成された要求間で帯域を融通しあうことにより、ネットワークの輻輳を回避していた。これらの方式はネットワークの輻輳状況によらず新規取得要求を（後に中止することがあるが）生成してしまう。つまり、ネットワークの輻輳状況に応じて、要求の送出を抑制する仕組みが第５〜第９の実施の形態では実現されていなかった。要求の中止時に取得要求送出バッファ余裕値を下げる制御により、輻輳時の要求送出間隔を大きくする制御は第６〜第９の実施の形態でも実現はされている。しかしネットワークの輻輳を検知した時点で、要求送出間隔を大きくすることができれば、より早期にネットワークの輻輳を回避できるはずである。逆に、ネットワークが空いている場合は、要求送出間隔を小さくすれば、ネットワーク帯域に隙間を作ることなく、より有効にバッファ余裕を確保することができるはずである。そこで、第１０の実施の形態では、バッファ余裕または見込みバッファ余裕をネットワークの輻輳に応じて調整する方式を示す。ここでは、バッファ余裕を調整する方式を示すが、これは見込みバッファ余裕と置き換えても良い。
【０２５０】
エンド−エンドのネットワークの輻輳状況を反映している値が、コンテンツ断片の要求を送出してからデータが到着するまでのラウンドトリップタイム（Round Trip Time、 以下RTT）である。そこで受信状況監視部202E-1は、この各コンテンツ断片取得時にRTTを測定する。このRTTの情報を効果的に活用することで、空き帯域の活用、輻輳時の帯域競合回避を実現する。
【０２５１】
本実施の形態の特徴は、ネットワークの輻輳状況をRTTにより捉え、RTTの増加、つまりネットワークが輻輳したと判断されたときには、取得要求送出バッファ余裕値を小さくし、要求の送出間隔を大きくすることである。この制御により、ネットワークの輻輳の要求送出を抑制できるため、より早いネットワークの輻輳解消が期待できる。また、RTTの減少、つまりネットワークが空いていると判断されたときには、取得要求送出バッファ余裕値を大きくし、要求の送出間隔を小さくする。この制御により空き帯域を積極的に利用したコンテンツ断片取得が実現される。
【０２５２】
この第１０の実施の形態の処理フローを、図３１のフローチャートと図２３の構成図を用いて説明する。クライアントからの視聴リクエストがストリーム配信制御部201Eを通じて先読み制御部202Eに到着すると（ステップＨ１０）、先読み制御部202Eは、その新規ターゲットクライアントjの取得要求送出バッファ余裕値THLjを指定されている初期値に初期化する（ステップＨ２０）。
【０２５３】
クライアントjをターゲットとしたコンテンツ断片の取得要求が送出されてから開始位置のコンテンツデータが到着するまでのRTT(以下RTTjと表記)は、視聴開始時には測定履歴がない。そこでRTTjの初期値を以下のいずれかの方法で設定する（ステップＨ３０）。
（１）同一のコンテンツに対する他のクライアントiをターゲットとしたコンテンツ断片取得が実行されている場合は、そのクライアントiのRTTを用いる。つまり、RTTj=RTTiとする。
（２）過去に同一コンテンツに対する要求があった場合は、その最新のRTTを利用する。
（３）適当なデフォルト値として初期設定する。
【０２５４】
そして先読み制御部202Eはコンテンツ断片の取得範囲を算出する（ステップＨ４０）。この範囲の算出法は、第５の実施の形態と同様である。
【０２５５】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＨ５０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０２５６】
要求の送出から要求したコンテンツ断片の開始位置の到着までの時間（RTT）を受信状況監視部202E-1で測定し、記録する（ステップＨ６０）。この際、古いRTTjはRTTj_oldに保存しておく。
【０２５７】
そして、第５の実施の形態では固定値として与えていたクライアントjの取得要求送出バッファ余裕値THLjを、クライアントjをターゲットとしたコンテンツ断片の取得要求が送出されてから開始位置のコンテンツデータが到着するまでのRTTに依存して動的に変化させる（ステップＨ７０）。受信状況監視部202E-1は、クライアントjをターゲットとしたコンテンツ断片取得のRTTが増加してくると、THLjを小さくする。RTTが小さくなるとTHLjを大きくする。例えば、前回のコンテンツ断片要求時のRTTをRTTj_old、今回のコンテンツ断片要求時のRTTをRTTjとすると、
THLj_old = THLj;
THLj = THLj_old×RTTj_old /RTTj;
としてTHLjを更新する。RTTの増加（減少）に対してTHLjを減少（増加）させるなら、ここで示した方法にこだわる必要はない。このようにRTTが増加した場合にTHLjを減少することで、ネットワーク輻輳時に要求送出を行ってしまう可能性を減らすことができる。
【０２５８】
しかし、THLjを小さくしすぎると、ネットワークの輻輳が長引くとバッファが枯渇し、クライアントの視聴品質が劣化する危険性がある。そこで、THLjは設定された最小値THLmin-j以下にはならないようにする。また、あまりに大きなバッファ余裕を持つことは記憶部204Eのスペースを圧迫するという意味で無駄であるため、THLj は指定された最大値THLmax-j以上にならないようにする。
【０２５９】
そして、先読み制御部202Eはバッファ余裕値bj(t)を監視し、取得要求送出バッファ余裕値THLj以下になるまで待つ（ステップＨ８０）。なったらステップＨ４０に戻り、再び要求の送出を行う。
【０２６０】
以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０２６１】
上記の第１０の実施の形態では、RTTを基にした制御を示した。しかし、ネットワークの輻輳はRTTのみで検知されるものではない。RTTを他のネットワークの輻輳を検知する指標に置き換えることも可能である。例えば、ボトルネックリンクの使用率で置き換えた制御も可能である。より具体的には、ステップＨ７０での取得要求送出バッファ余裕値THLjを、ボトルネックの使用率に依存して動的に変化させる。このときの構成は、図２６に示される第６の実施の形態の構成と同様であるとする。先読み制御部202Eは、ネットワーク情報収集部207Eからボトルネックリンクの使用率を所得する。ボトルネックリンクの使用率が増加してくると、THLjを小さくする。RTTが小さくなるとTHLjを大きくする。例えば、ある時間幅のタイムスロット毎に、先読み制御部202Eはネットワーク情報収集部207Eからボトルネックリンクの使用率を所得するとする。前回のタイムスロットでのリンク使用率をUold、今回のタイムスロットでのリンク使用率をUとすると、
THLj_old = THLj;
THLj = THLj_old×Uold /U;
としてTHLjを更新する。ボトルネックリンクの使用率の増加（減少）に対してTHLjを減少（増加）させるなら、ここで示した方法にこだわる必要はない。このようにボトルネックリンクの使用率が増加した場合にTHLjを減少することで、ネットワーク輻輳時に要求送出を行ってしまう可能性を減らすことができる。
【０２６２】
さらに、これまで示した第１０の実施の形態は、第５の実施の形態をベースとしていたが、ベースとなる制御は第６〜第９の実施の形態に置き換えることも容易に可能である。
【０２６３】
第１０の実施の形態の効果は、第５から第９の実施の形態に比較して、より早期にネットワークの輻輳を回避できることである。ネットワークの輻輳状況に応じて、要求の送出を抑制する仕組みを入れることでネットワークの輻輳を検知した時点で、要求送出間隔を大きく、逆に、ネットワークが空いている場合は、要求送出間隔を小さくすることで、この効果が実現できる。
【０２６４】
（第１１の実施の形態）
第１０の実施の形態は、ネットワークの輻輳時の要求送出の回避を１つの特徴としている。しかし、第１０の実施の形態でも触れたように、この制御はネットワークの輻輳が持続した場合、バッファ余裕の枯渇、配信品質の劣化に繋がる可能性がある。
【０２６５】
ボトルネックリンクは輻輳していないにも関わらず、特定のコネクション（特定のオリジンサーバ）からの取得が輻輳により遅くなっているケースもある。このような場合、第１０の実施の形態とは逆に、RTTの増加に対しては、積極的に要求送出を行うべきである。できるだけ早く取得要求を送出しなければ、取得が間に合わない危険性が高いからである。
【０２６６】
第１１の実施の形態の特徴は、ネットワークの輻輳状況をRTTにより捉え、RTTの増加、つまりネットワークが輻輳したと判断されたときには、バッファ余裕をできるだけ大きく維持できるように、RTTが小さいときに比べ、より頻繁にコンテンツ断片の取得を行う。この制御により、ネットワークの輻輳に伴うデータの到着遅延に伴うバッファの枯渇（バッファ余裕が０となること）を回避することができる。
【０２６７】
第１０の実施の形態との相違点は、図３１のステップＨ７０での取得要求送出バッファ余裕値THLjの設定のみである。
【０２６８】
前回のコンテンツ断片要求時のRTTをRTTj_old、今回のコンテンツ断片要求時のRTTをRTTjとすると、
THLj_old = THLj;
THLj = THLj_old×RTTj/RTTj_old;
としてTHLjを更新する。RTTの増加（減少）に対してTHLjを増加（減少）させるなら、ここで示した方法にこだわる必要はない。このようにRTTが増加した場合にTHLjを増加することで、コンテンツ断片取得に時間を要するコンテンツの取得要求ほど頻繁に送出される。データ取得に時間を要することに伴うバッファの枯渇を抑制できるようになり、より多くのクライアントへの配信品質を保証できるようになる。
【０２６９】
しかし、あまりに大きなバッファ余裕を持つことは記憶部204Eのスペースを圧迫するという意味で無駄であるため、THLjは指定された最大値THLmax-j以上にならないようにする。また、THLjを小さくしすぎると、バッファがちょっとしたネットワークの輻輳で枯渇し、クライアントの視聴品質が劣化する危険性がある。そこで、THLjは設定された最小値THLmin-j以下にはならないようにする。
【０２７０】
第１１の実施の形態は、第１０の実施の形態同様、基本的な構成は第５〜第９のいずれの実施の形態でも構わない。特に第７〜第９の実施の形態をベースとすれば、ボトルネックリンクの輻輳はある程度回避できるので、第７〜第９の実施の形態をベースとすることが望ましい。
【０２７１】
第１１の実施の形態の効果は、従来防ぐことができなかった、特定のコネクション（取得パス）の輻輳時のバッファ枯渇を防止できることである。ボトルネックリンクの監視と併用すればより優れた効果が期待できる。
【０２７２】
（第１２の実施の形態）
これまでの実施の形態では、1人のクライアントをターゲットする取得要求は同時に１つしか実行しないとしてきた。しかし、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合には、この1人のクライアントをターゲットする取得要求は同時に１つしか実行しないという制約があると、帯域に空きがあってもその空き帯域を活用した積極的な取得を実現することができない。例えば、オリジンサーバがクライアントの視聴レートと同じレートでしかデータを送出しないように設計されているような場合が挙げられる。1人のクライアントをターゲットする取得要求は同時に１つしか実行しないと、視聴レートでしかデータを取得できないため、バッファ余裕を現在値よりも増やすことが不可能である。この場合、ネットワークの輻輳等でデータの到着が遅れると、直ちにバッファ余裕が不足し、クライアントに送信されるストリームの品質が劣化する恐れがある。
【０２７３】
１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行すれば、空き帯域を活用した積極的な取得を実現することができる。
【０２７４】
第１２の実施の形態では、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行することで空き帯域を活用した積極的な取得を実現し、より多くのクライアントが配信品質を維持するために十分なバッファ余裕を確保できる制御方式を示す。
【０２７５】
図３２のフローチャートと図２６の構成図を用いて、第１１の実施の形態を説明する。以下の実施の形態は、第８の実施の形態の見込みバッファ余裕を用いた制御をベースとしているが、見込みバッファ余裕を用いることは本実施の形態の本質ではない。本実施の形態の本質は、同一のクライアントをターゲットする取得要求によるデータの取得レートの引き上げを複数の取得要求の同時実行により実現すること、その際の同時実行数をネットワークの輻輳を引き起こさない範囲に抑えることである。
【０２７６】
ここで、本実施の形態における見込みバッファ余裕を、図３３を参照して定義する。図３３の301の横軸は視聴時間を表す。クライアントの時刻PT後の視聴位置は302の三角形で示した位置であるとする。そして、現在３つの同一クライアントをターゲットとした要求が実行されているとする。1番目の要求(311)は、ストリームプロキシサーバ上に時刻PT後に303で示される位置から304で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は305で示される位置だとする。302と304の間の時間幅をET1とする。2番目の要求(312)は、ストリームプロキシサーバ上に時刻PT後には305で示される位置から306で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は307で示される位置だとする。305と306の間の時間幅をET2とする。3番目の要求(313)は、ストリームプロキシサーバ上に時刻PT後には307で示される位置から308で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は309で示される位置だとする。307と308の間の時間幅をET3とする。まず、１つの定義としては、見込みバッファ余裕は、現在より時刻PT後の同一クライアントをターゲットとした要求により取得されたデータのうち、クライアントが未視聴のデータの時間という定義ができる。このとき、見込みバッファ余裕は、ET1+ET2+ET3となる。また別の定義としては、視聴位置から時刻PT後に取得されているデータ上で、現在の視聴位置から見てデータが途切れるまでの時間という定義もできる。この場合、図３３の例ではET1が見込みバッファ余裕となる。
【０２７７】
このように幾つか見込みバッファ余裕は定義できるが、以下は現在より時刻PT後の同一クライアントをターゲットとした要求により取得されたデータのうち、クライアントが未視聴のデータの時間という定義を用いて説明する。このことは本質ではなく、視聴位置から時刻PT後に取得されているデータ上で、現在の視聴位置から見てデータが途切れるまでの時間という定義に置き換えてもほぼ同様の実施の形態を実現できる。
【０２７８】
次に本実施の形態の大まかな方針を示す。
【０２７９】
バッファが枯渇寸前の場合（バッファ余裕が０に近い場合）は、コンテンツ断片取得を行うべきかどうかは取得レートとユーザの視聴レートの大小関係で決定される。取得レートが視聴レートよりも低ければ、バッファ余裕が回復する見込みは無い。見込みバッファ余裕は０と算出される。この場合、すぐにクライアントへの配信は中断されるのでコンテンツ断片を取得することは帯域の輻輳を助長するだけである。よってさらなるコンテンツ断片の要求を中止する。これまでの実施の形態では、１つのターゲットクライアントに対する取得要求の同時実行数が１と限定されていたため、この判断を１つの取得要求（１コネクション）で実現できる取得レートを基に判断してきた。しかし、本実施の形態では、帯域に余裕がある範囲で、同一のクライアントをターゲットとする取得要求を複数実行することを許す。空き帯域で並行に複数の取得を実行してもなお、それらの取得要求によるデータの合計取得レートがクライアントの視聴レートよりも小さく、バッファ余裕を回復する望みがなければ取得要求の送出を中止する。それらの取得要求によるデータの合計取得レートがクライアントの視聴レートよりも大きければ、バッファが枯渇寸前であってもバッファ余裕を回復することが可能である。つまり見込みバッファ余裕がある程度の値になることを期待できる。そのため、バッファ余裕を回復するのに必要な合計取得レートを、帯域が許す範囲で並行に取得要求を実行することで確保し、バッファ余裕の回復を図る。
【０２８０】
次にバッファ余裕が（枯渇寸前というほどではないが）あまり無い場合を考える。同一クライアントをターゲットする取得要求によるデータの取得レートの合計が視聴レートより大きい場合は上記と同様に、見込みバッファ余裕がある程度の値になることを期待できる。帯域が許す範囲で平行に取得要求を実行することで確保し、バッファ余裕の増加を図る。同一クライアントをターゲットする取得要求によるデータの取得レートの合計が視聴レートよりも小さい場合は、バッファ余裕はさらに減少する。つまり見込みバッファ余裕は０に近くなる。このままではバッファが枯渇してしまうのでできるだけ早く適切な取得レートを確保したい。そのためには、ターゲットとするクライアントのバッファ余裕が大きい要求があれば、それらの取得を中断させ、それらの要求が使っていた帯域を譲り受け、必要な取得レートを確保する。その際、後続のコンテンツ断片の取得要求を必要な帯域を確保できるまで優先的に中止する。他の要求を中断させることが可能なのは、より大きなバッファ余裕を持つ要求が存在する場合である。そのような要求が存在しない場合は、必要とする取得レートを確保することは不可能である。しかし、必要な取得レートが確保できるまで全くコンテンツ断片を取得しないと、すぐにバッファが枯渇してしまう（見込みバッファ余裕が０となる）。よってとりあえず可能な取得レートでコンテンツ断片を取得してバッファが枯渇するまでの時間を引き延ばす必要がある。しかし、そのままの取得レートが長期間続いても、ターゲットとするクライアントのバッファ余裕が枯渇するのも明らかである。取得レートが視聴レートを上回る場合に比べて、短い期間でコンテンツ断片の取得を終了させ、必要な取得レートを確保できないか確認すべきである。そこで、この小さな取得レートで確保する期間、つまり要求する範囲を小さくする。
【０２８１】
次にバッファ余裕が十分にある場合を述べる。バッファ余裕が十分にあれば一般には今すぐコンテンツ断片を取得する必要は無い。よってコンテンツ断片要求の送出は先送りしてよい。しかし、取得レートが視聴レートに比べ、著しく低くなっている場合はその限りでない。この場合、ネットワークが著しく輻輳してきていることを意味する。この場合、現在は十分にあるバッファ余裕がすぐになくなることを意味する。つまりコンテンツ断片取得を行わなければ、見込みバッファ余裕は０に近くなる。この場合は、確保できる取得レートで良いのでコンテンツ断片を取得し、ネットワークの輻輳が解消するまでバッファが枯渇しないように凌ぐべきである。
【０２８２】
以下詳細な制御をフローチャート図３２と構成図２６を用いて説明する。
【０２８３】
コンテンツ取得要求の生成は、クライアントからの視聴リクエストの到着、または以下で説明するクライアント毎に設定されるコンテンツ断片取得要求送出時刻、さらにネットワーク情報収集部207Eがボトルネックリンクの帯域に空きが生じたことを検知した時に発生する。先読み制御部202Eは、ストリーム配信制御部201Eからの視聴リクエストの到着、コンテンツ断片取得要求送出時刻のイベントを監視し、新規取得要求の生成を待つ。そして新規ターゲットクライアントjを決定する。また、ネットワーク情報収集部207Eはボトルネックリンクの帯域に空きが生じたことを検知すると、先読み制御部202Eに新規取得要求の生成を指示する。先読み制御部202Eは、最も見込みバッファ余裕の少ないターゲットクライアントjを新規ターゲットクライアントとして決定する（ステップＫ１０）。
【０２８４】
まず、現在時刻での実際のクライアントjのバッファ余裕を確認する（ステップＫ２０）。もしバッファ余裕bj(t)がクライアント毎に指定された希望バッファ余裕値THSjより大きく(bj(t)＞THSj)、かつクライアントjをターゲットとした実行中の要求全ての合計取得レートが、クライアントjの視聴レートを超えている場合は、まだ余裕があると判断し、新規取得要求の送出を中止する（ステップＫ１６０）。そしてコンテンツをクライアントが視聴中なら、次回要求生成時刻を設定する（ステップＫ１７０）。次回要求生成時刻の設定法は、後述するステップＫ１４０で説明する。バッファ余裕がTHSj以下、またはバッファ余裕はTHSjを超えるがクライアントjをターゲットとした要求の取得レートが、クライアントjの視聴レートを下回る場合は、ステップＫ３０以下のステップに進む。
【０２８５】
bj(t)≦THSjの場合は、先読み制御部202Eは、ネットワーク情報収集部207Eからボトルネックリンクの帯域使用幅RA(t)を得る（ステップＫ３０）。ネットワーク情報収集部207EのRA(t)を得る方法は、第５の実施の形態と同様である。
【０２８６】
次に、新規取得要求を幾つの要求として並行に実行するかと、それぞれの要求で期待される先読み取得予測レートを算出する（ステップＫ４０）。クライアントjをターゲットとした取得要求が既にmj個実行中であるとする。取得要求の範囲が手前の順に１からmjまでのラベル付けがされているとする。そしてこれらの要求がデータを取得しているレートをzj,h(t) (h=1,..,mj)とする。ここに、新たにクライアントjをターゲットとした取得要求を増やして行った際に、期待できる先読み予測取得レートを先読み制御部202Eは予測する。このレートを先読み取得予測レートと呼び、z＊j,mj+k(t) (h=1,…)で表すことにする。このz＊j,mj+k(t)の推定方法は第６の実施の形態と同様、またはオリジンサーバへ問い合わせることでわかるものとする。そして、この先読み予測取得レートを基に、新規取得要求を幾つ実行したいかを算出する。バッファ余裕を希望する値にするために必要なレートを何本のコネクションでこのレートを実現できるか、つまり幾つの新規取得要求を並行に実行する必要があるかを算出する。例えば、現在より時刻PT後に、バッファ余裕を希望バッファ余裕値THSjにするための取得レートを新規に確保する、という方式が考えられる。クライアントjが要求を送出してオリジンサーバからデータが届くまでの時間をRGSjとする。また、クライアントjをターゲットとした、（先に付けたラベル付けで）h番目の要求の取得完了見込み時刻をTFj,hとする。希望する取得レートは、現在実行中の取得要求の実行を継続した場合に、これから新規取得要求を送ることで、時刻PT後に希望バッファ余裕値THSｊを確保するために必要な取得レートである。これは、
【数１９】
を満たすvj(t)を算出することで求まる。ここでｍｉｎ（ｘ，ｙ）は、ｘとｙの小さい方の値を返す関数である。
【数２０】
と算出される。これを実現するために、幾つの新規取得要求を送出すべきか（同時実行数を）算出する。つまり、
【数２１】
を満たす、最小のkを求める。もし、そのようなkが存在しない（同時実行数を増やしても、希望取得レートを確保できない）場合は、もっともvj(t)に近づく値を同時実行数kとして選択する。
ボトルネックリンクにそれらの先読み取得予測レートのトラヒックが加わった際の見込み帯域使用幅がボトルネック限界レートRBを超えないか確認する（ステップＫ５０）。つまり、
【数２２】
とならないかチェックする。ならない場合は、ステップＫ６０以下のステップに進む。
【数２３】
の場合は、新規取得要求を全て送出するとボトルネックリンクの輻輳を招く。それを回避するために、新規取得要求の送出を幾つか（もしくは全て）やめるか、送出する代わりに他の実行中のコンテンツ断片の取得要求を中止する必要がある。そこで先読み制御部202Eは、新規取得要求も含めて、中止可能な取得要求があるか確認し、存在すれば中止候補として選択する（ステップＫ１８０）。最も単純なやり方としては、実行中の取得要求に関しては、実行を中止した場合の見込みバッファ余裕（中止バッファ余裕）を、新規取得要求の場合は、その要求を実行しなかった場合の見込みバッファ余裕（未送出時バッファ余裕）を算出し、中止バッファ余裕および未送出時バッファ余裕の大きい要求から、中止候補としていくことである。
【０２８７】
ここで、中止バッファ余裕の算出法の一例を挙げることにする。該要求を中止した場合の、現在時刻から指定時間幅PT先の見込みバッファ余裕を中止バッファ余裕と定義する。要求を送出してから実際に中止されるまでには、プロキシストリームサーバ20Eからオリジンサーバまでパケットが届く時間だけかかる。クライアントiをターゲットとしたコンテンツ断片の取得要求を中止するために要する時間をRCSiで表すことにする。ここで、RCSiは、受信状況監視部202E-1で測定されているクライアントiをターゲットとする取得要求のRTTであるRTTiの半分などと近似すればよい。該要求が、クライアントiをターゲットとした要求の（先のラベル付けで）mi番目であるとする。mi番目が中止候補となる場合、mi+1番目以降の要求が存在したとしても、後続要求から中止候補となるため、すでにそれらは中止候補となっている。そのため、該要求を中止した場合、mi-1番目以下の要求が実行されている状況での見込みバッファ余裕が、中止バッファ余裕となる。具体的に示すと、クライアントiをターゲットとするmi番目の取得要求の中止バッファ余裕は、
【数２４】
と算出される。ここでTFi,hは、クライアントiをターゲットとするh番目の取得要求がデータ取得を完了すると見込まれる時間である。
【０２８８】
次に未送出時バッファ余裕の算出法の一例を挙げることにする。新規取得要求が先のラベル付けで、クライアントiをターゲットとするmi+h番目の要求であったとすると、未送出バッファ余裕は、mi+(h-1)番目までの新規要求を送出した際のバッファ余裕に相当する。つまり、
【数２５】
と未送出時バッファ余裕は算出される。
【０２８９】
各要求に対して、中止バッファ余裕、未送出バッファ余裕を算出する。そしてその値の大きい順に中止候補として行く。中止候補は、中止候補にならなかった実行中の要求を継続し、さらに中止候補とならなかった新規取得要求を実行しても、実行中の要求の取得レートと新規要求による予測取得レートの合計が、ボトルネック限界レート以下となるまで選択される。
【０２９０】
ただし、相対的な見込みバッファ余裕の大小のみで取得要求を中止して行くと、全ての要求のバッファ余裕が単調に減少し、結局全てのクライアントへの配信品質が劣化する恐れがある。そこで、ターゲットクライアントの見込みバッファ余裕値が、設定した最低見込みバッファ余裕閾値以下となった時点で中止候補の選択は打ち切る。
そして選択された中止候補の取得要求を中止することでボトルネックの見込み帯域使用幅をボトルネック限界レート以下にできるか調べる（ステップＫ１９０）。クライアントiをターゲットとした、要求hの現在時刻ｔでの取得レートをzi,h(t)で表す。ターゲットとなっているクライアントの数がMであり、クライアントiをターゲットとした中止候補となっていない要求がmi個(i=1,…,M)あり、中止候補となっていない新規取得要求がそれぞれni個（i=1,…M）だけあるとする。これらの要求を全て中止しても見込み帯域使用幅がボトルネック限界レート以下にならない、つまり
【数２６】
ならば、先読み制御部202Eはクライアントjからの新たな要求の送出を中止する（ステップＫ２１０）。そして、クライアントjをターゲットとするコンテンツ断片の取得要求送出時刻を、後述のステップＫ１４０で示す方法に従い設定する。ここで1(ni1)は、ni＞1の時に１、それ以外には０となる変数である。また、中止候補として選択されている要求の実行は中止してもしなくても良いが、本実施の形態のフローチャートでは中止しないとしてある。
【０２９１】
ステップＫ１９０において、中止候補を中止することで見込み帯域使用幅がボトルネック限界レート以下にできるならば、ステップＫ６０に進み、ステップＫ６０でバッファ余裕がTHLMINjより大きければ、実行中の中止候補の要求は実行を中止し、中止候補に含まれる新規取得要求は破棄する（ステップＫ２００）。
【０２９２】
新規取得要求を送出するために必要な帯域が確保できたとステップＫ５０で判断されると、先読み制御部202Eは、ステップＫ７０以下の要求するコンテンツ断片の範囲の算出に進もうとする。
【０２９３】
しかし、実行中の取得要求と算出された新規取得要求の先読み取得予測レートの合計（以下合計取得予測レート）
【数２７】
が小さい場合、先読みを行ってもバッファの枯渇（バッファ余裕が０となること）が避けられない。このような場合は、新規取得要求を断念すべきである。その判断をステップＫ６０で行う。具体的には、見込みバッファ余裕b＊j(t)が指定された最低バッファ余裕値THLMINj以下であるならば、新規取得要求の送出を中止するためにステップＫ２１０に進む。バッファ余裕がTHLMINjより大きければ、ステップＫ２００に進み上記のように候補要求の中止を行うと共に、ステップＫ７０以下に進み、新規取得要求の送出を行う。
【０２９４】
ステップＫ７０では、新規取得要求のコンテンツ断片の範囲の算出を行う。まず先頭の新規取得要求の開始位置は前回要求の終了位置と現在視聴位置のうち大きいほうの値に一致する。これは第５、第６の実施の形態と同様である。最後尾（クライアントjをターゲットとする要求の中で最後の要求）の取得要求の終了位置は、取得要求の実行完了時の見込みバッファ余裕を希望バッファ余裕値THSjにできる位置とする。例えば、ストリームが固定視聴レートrjのCBRとしてエンコードされていて、プロキシストリームサーバ20Eがオリジンサーバからストリームデータを取得する合計取得予測レートがコンスタントにzjである場合の終了位置の算出法を説明する。プロキシストリームサーバ20Eは、要求した開始位置のデータの到着から、終了位置のデータの到着までの間、(zj-rj)のレート（bps）でバッファを増加する。これをバッファ余裕に換算すると、単位時間あたりに(zj-rj)/rj秒分のバッファ余裕が生じていることになる。プロキシストリームサーバ20Eが、コンテンツ取得要求を送信してから、終了位置のデータを受信するまでの時間をSTと置くと、ST後の見込みバッファ余裕b＊j(t+ST)は、要求送信から開始位置のデータ受信までのRTTであるRTTjも考慮すると、
【数２８】
となる。b＊j(t)=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になっていることが期待できる。各要求の要求範囲は、開始位置＋CSTの幅を均等に分担するのが最も単純である。他にも、後続の要求から中止されることも考えると、後続の要求ほど短くする、という方式もあり得る。また、完全に異なる部分を分担するのではなく、ある程度重複があるように分担する、という方式でも良い。
【０２９５】
しかし、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以下にならないことが期待できる。各要求の要求範囲は、開始位置＋CSTの幅を均等に分担するのが最も単純である。他にも、後続の要求から中止されることも考えると、後続の要求ほど短くする、という方式もあり得る。
【０２９６】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定した中止候補とならなかったni個の新規コンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＫ８０）。
【０２９７】
そして、送出した要求の中止（ステップＫ１１０）、または送出した要求によるコンテンツ断片の取得完了（ステップＫ１００）のいずれかのイベントが発生するのを先読み制御部202Eは待つ（ステップＫ９０）。
【０２９８】
コンテンツ断片の取得が完了した場合（ステップＫ１００）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＫ１２０）。次回要求送出時刻は、バッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、クライアントjをターゲットとした実行中の要求がmi個あるとすると、XT後のバッファ余裕は、
【数３３】
として算出される。この式を満たすXTを求め、現在時刻＋XTを次回取得要求送出時刻として設定する。もしTHLj ＞bj(t)ならば、バッファ余裕が十分に無いことを意味するので、現在時刻を次回要求取得送出時刻として設定し、直ちにステップＥ１０に戻る。
【０２９９】
コンテンツ断片の取得要求の中止の場合（ステップＫ１１０）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＫ１４０）。中止の場合、次回の要求送出までの間隔をある程度空けなければならない。直ちに再要求を実行することは、ネットワークの輻輳に拍車をかけることになるからである。現在のバッファ余裕値が、bj(t)＞THLjの場合は、次回要求生成時刻は、完了時と同様にバッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻とすればよい。それに対し、現在のバッファ余裕値が、bj(t)≦THLjの場合は、次回要求送出時刻は、見込みバッファ余裕が最小バッファ余裕値THLMINjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLMINj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、中止後のクライアントjをターゲットとする実行中の要求数をkiとすると、
【数３４】
である。この式を満たすXTを求め、現在時刻＋XTを次回取得要求送出時刻として設定する。もしTHLMINj ＞bj(t)ならば、バッファ余裕が視聴品質を保つのには不十分と判断しクライアントjをターゲットとしたコンテンツ断片の取得はあきらめるものとする（ステップＫ１５０）。
【０３００】
また、以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０３０１】
第１２の実施の形態の効果は、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行することで、空き帯域を活用した積極的な取得を実現することができることである。
【０３０２】
なお、上記各実施の形態のストリームプロキシサーバは、ストリーム配信制御部、先読み制御部、受信レート制御部、トランスポート層制御部、ネットワーク情報収集部、その他の機能をハードウェア的に実現することは勿論として、各機能を備えるプロキシ制御プログラムを、コンピュータ処理装置のメモリにロードすることでソフトウェア的に実現することができる。このプロキシ制御プログラム１０００は、磁気ディスク、半導体メモリその他の記録媒体に格納される。そして、その記録媒体からコンピュータ処理装置にロードされ、コンピュータ処理装置の動作を制御することにより、上述した各機能を実現する。
【０３０３】
以上好ましい実施の形態及び実施例をあげて本発明を説明したが、本発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形して実施することができる。
【０３０４】
【発明の効果】
以上説明したように本発明によれば、以下に述べるような効果が実現される。
【０３０５】
第１に、プロキシサーバにおいて、ネットワークを流れる他のトラヒックへの影響を極力抑えてオリジンサーバからのコンテンツの取得を実現することができる。
【０３０６】
第２に、プロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御し、同一のボトルネックを共有するコンテンツの間で帯域の割り当て制御を行うことにより、視聴品質の悪化が起こる可能性を極力抑えることを可能する。
【０３０７】
第３に、プロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御することにより、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を最小限に抑えることを可能とする。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態のストリームプロキシサーバを使ったネットワーク構成を示す図である。
【図２】 本発明の第１の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図３】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図４】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図５】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図６】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図７】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図８】 本発明による希望レートの決定方法を説明する図である。
【図９】 本発明の第１の実施の形態のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図１０】 本発明の第１の実施の形態のストリームプロキシサーバ保持しているストリーム断片を説明する図である。
【図１１】 本発明の第２の実施の形態のストリームプロキシサーバを使ったネットワーク構成を示す図である。
【図１２】 本発明の第２の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図１３】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１４】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１５】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１６】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１７】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１８】 本発明の第２の実施の形態のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図１９】 本発明の第２ストリームプロキシサーバが保持しているストリーム断片を説明する図である。
【図２０】 本発明の第３の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図２１】 本発明の第４の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図２２】 本発明の第５、第６の実施の形態のネットワーク接続状況を示すための構成を示す図である。
【図２３】 本発明の第５の実施の形態のストリーミングプロキシサーバの内部構成を示すブロック図である。
【図２４】 本発明の第５の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２５】 本発明の第５の実施の形態における要求するコンテンツ断片の範囲の算出法を説明するための図である。
【図２６】 本発明の第６の実施の形態のストリーミングプロキシサーバの内部構成を示すブロック図である。
【図２７】 本発明の第６の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２８】 本発明の第８の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２９】 本発明の第９の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３０】 本発明の第９の実施の形態のストリームプロキシサーバの先読み制御部のクラス下げ／中止候補選択の動作フローチャートである。
【図３１】 本発明の第１０の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３２】 本発明の第１２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３３】 本発明の第１２の実施の形態における見込みバッファの定義を説明する図である。
【図３４】 従来のストリームプロキシサーバを用いたネットワーク構成を示す図である。
【図３５】 従来のストリームプロキシサーバの内部構成を示すブロック図である。
【図３６】 従来のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図３７】 従来のストリームプロキシサーバが保持しているストリーム断片を示す図である。
【符号の説明】
10-1−10-n クライアント
20A、20B、20C、20D、20E ストリームプロキシサーバ
30 ルータ
50、60、80 ネットワーク
70、110、120、130 ネットワーク
40-1−40m オリジンサーバ
201A、201B、201C、201D、201E ストリーム配信制御部
202A、202B、202C、202D、202E 先読み制御部
202E-1 受信状況監視部
204A、204B、204C、204D、204E 記憶部
205A、205B、205C、205D、205E トランスポート層制御部
206A、206B、206C、206D、206E 受信レート制御部
207A、207B、207C、207D、207E ネットワーク情報収集部
【発明の属する技術分野】
本発明は、コンテンツの一部または全部を記憶装置に溜め、そこからクライアントにコンテンツをストリーム配信しながら、該コンテンツの保持していないコンテンツ断片をオリジンサーバから取得して記憶装置に追加するストリームプロキシサーバに関し、特にネットワークを流れる他のトラヒックへの影響を抑えてオリジンサーバからのコンテンツの取得を実現するストリームプロキシサーバおよびネットワーク技術に関する。
【従来の技術】
図３４に従来のストリームプロキシサーバを用いたネットワークの構成図を示す。従来のストリームプロキシサーバ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になるまでの時間を延ばすことが出来、それまでの間に一時的な輻輳が解消すれば、クライアントの視聴品質の悪化をなくすことが可能であるが、従来のストリームプロキシサーバではこれは出来ない。
【００１８】
また、バッファ余裕以外の要因（視聴しているクライアントやコンテンツなど）に依存して、取得レートを決定する事を行う事が出来ない。このため、特定のクライアントやコンテンツについての取得レートをより高く設定して、そのクライアントやコンテンツの視聴品質の悪化を防ぐという事が出来ない。
【００１９】
本発明の第１の目的は、ネットワークを流れる他のトラヒックへの影響を極力抑えてオリジンサーバからのコンテンツの取得を実現することができるプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２０】
本発明の第２の目的は、オリジンサーバからのコンテンツ取得レートを制御し、同一のボトルネックを共有するコンテンツの間で帯域の割り当て制御を行うことにより、視聴品質の悪化が起こる可能性を極力抑えることを可能としたプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２１】
本発明の第３の目的は、オリジンサーバからのコンテンツ取得レートを制御することにより、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を最小限に抑えることを可能とするプロキシサーバ、プロキシ制御プログラムを提供することにある。
【００２２】
【課題を解決するための手段】
本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、記憶装置からクライアントにコンテンツを配信しながら、コンテンツの保持していない部分をオリジンサーバから取得して記憶装置に追加するプロキシサーバにおいて、各コンテンツのクライアントへの配信レートと、コンテンツのオリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量がコンテンツの受信バッファ閾値を上回るもののコンテンツ取得には、低優先のトランスポート層プロトコルを使用し、受信バッファ量が受信バッファの閾値を下回る量が大きいものほどコンテンツ配信レートより高い取得レートとし、かつ、各コンテンツの取得レートを合計したレートがネットワークの空き帯域を越えないように、各コンテンツの取得レートを制御し、各コンテンツの受信バッファ閾値と、各コンテンツの現在の受信バッファ量から、各コンテンツの希望取得レートを決定し、現在配信を行っている全コンテンツの希望取得レートの合計が、オリジンサーバとプロキシサーバの間のネットワークの空き帯域を越えない場合には、各コンテンツの取得レートを、前記希望取得レートとし、そうでない場合には、あらかじめ決められたコンテンツの優先度の高い順に、前記希望取得レートを、希望取得レートの合計が、前記ネットワークの空き帯域を越えないコンテンツまで割り当てることを特徴とする。
【００２５】
請求項２の本発明のプロキシサーバは、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、各コンテンツの前記クライアントへの配信レートと、該コンテンツの前記オリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量が該コンテンツの前記受信バッファ閾値を上回るもののコンテンツ取得には、低優先のトランスポート層プロトコルを使用し、前記受信バッファ量が前記受信バッファの閾値を下回る量が大きいものほどコンテンツ配信レートより高い取得レートとし、かつ、各コンテンツの取得レートを合計したレートがネットワークの空き帯域を越えないように、各コンテンツの取得レートを制御することを特徴とする。
【００２６】
請求項３の本発明のプロキシサーバは、各コンテンツの前記受信バッファ閾値と、各コンテンツの現在の受信バッファ量から、各コンテンツの希望取得レートを決定し、現在配信を行っている全コンテンツの希望取得レートの合計が、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、各コンテンツの取得レートを、前記希望取得レートとし、そうでない場合には、あらかじめ決められたコンテンツの優先度の高い順に、前記希望取得レートを、希望取得レートの合計が、前記ネットワークの空き帯域を越えないコンテンツまで割り当てることを特徴とする。
【００３４】
請求項４の本発明のプロキシサーバは、コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分を、コンテンツを分割した断片としてオリジンサーバから取得し、バッファに追加するプロキシサーバにおいて、現在より先の時刻での各クライアントの見込みバッファ量を、現在の取得レート、および、視聴レートから求め、前記見込みバッファ量がゼロ以下のコンテンツは取得を中止し、前記見込みバッファ量があらかじめ決められたバッファ閾値を下回ったコンテンツについて、前記ストリームの過去のオリジンサーバからのコンテンツ取得レートの履歴から決められる予測取得レートが、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、該コンテンツ取得を行い、そうでない場合には、バッファ量が前記閾値を越えているストリームのコンテンツ取得を、低優先のトランスポート層プロトコルを用いて行うことを特徴とする。
【００３５】
請求項５の本発明のプロキシサーバは、前記低優先のトランスポート層プロトコルとして、TCPVegasを用いて行うことを特徴とする。
【００３８】
請求項６の本発明のプロキシ制御プログラムは、コンピュータ上で実行され、コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシ制御プログラムにおいて、各コンテンツの前記クライアントへの配信レートと、該コンテンツの前記オリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、コンテンツの受信バッファ量が該コンテンツの受信バッファ閾値を上回るコンテンツの取得には、低優先のトランスポート層プロトコルを使用することを特徴とする。
【００５３】
【作用】
ネットワーク情報収集手段によって、ネットワークの残余帯域の情報を収集し、取得レート決定手段において、この残余帯域に基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５４】
また、ネットワークがトランスポート層プロトコル決定手段によって、複数の異なる帯域共有特性を持つトランスポート層プロトコルから、ネットワークを流れる他のトラヒックへの影響の小さいトランスポート層プロトコルを決定し、複数の異なる帯域共有特性を持つトランスポート層プロトコルを用いたデータ送受信が出来るトランスポート層プロトコル制御手段を用いて、コンテンツ取得を行う事によって、本発明の第１の目的である、オリジンサーバからのコンテンツの取得をネットワークを流れる他のトラヒックへの影響を抑えて実現する事が可能となる。
【００５５】
また、バッファ余裕測定手段によって、各コンテンツのバッファ余裕の大きさを求め、それに基づいて、オリジンサーバからの取得レートを決定し、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５６】
また、指定優先度を考慮した取得レートを決定する手段によって、オリジンサーバからの取得レートを指定優先度も考慮して決定し、優先度の高い視聴に関してより高い取得レートを割り当て、受信レート制御手段や、オリジンサーバへコンテンツの送信レートを指示する手段を用いて、決定した取得レートでのコンテンツ取得を行う事によって、本発明の第３の目的である、ストリームプロキシサーバにおいて、指定優先度に従い、優先度の高い視聴に関して、視聴品質の悪化が起こる可能性を小さくする事が可能となる。
【００５７】
また、バッファ余裕に基づいてオリジンサーバからのコンテンツ取得要求を送出する先読み手段を用いることで、過剰な先読み要求の送出が抑制され、さらにコンテンツを部分的なコンテンツ断片として取得要求を行う先読み制御手段を用いてコンテンツを時間的に分割して取得することで、ネットワーク本発明の第１の目的である、オリジンサーバからのコンテンツ取得をネットワークに流れる他のトラヒックへの影響を抑えて実現することが可能となる。
【００５８】
また、ネットワーク情報収集手段と、同時に実行される取得要求間の優先度を判別する手段と、優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制されることで、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００５９】
また、優先度をバッファ余裕の大小で決定する手段とその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６０】
また、優先度を要求が取得しようとするコンテンツを蓄積しているオリジンサーバにより決定する手段により、コンテンツが蓄積されているオリジンサーバを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６１】
また、優先度を要求により獲得したコンテンツ断片のデータをストリーム配信するクライアントにより決定する手段により、配信対象となるクライアントを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６２】
また、優先度を要求したコンテンツにより決定する手段により、コンテンツを基準とした優先付けが可能となり、さらにその判別された優先度に基づき実行中の要求を中止する手段により、バッファ余裕のある取得要求の実行が抑制され、本発明の第３の目的である、ストリームプロキシサーバにおいて指定優先度に従い、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を小さくすることが可能である。
【００６３】
また、バッファ余裕の変化を予測し、バッファ余裕が将来不足しそうな場合に、後続のコンテンツ断片の取得要求を送出する先読み制御手段により、より時間的な余裕を持った要求間での帯域の融通が可能となり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６４】
また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段を使い分けて実行する手段により、ネットワークの輻輳を抑制した取得を選択できる可能性がより高くなり、本発明の第２の目的である、ストリームプロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを抑制し、同一ボトルネックを共有するコンテンツの間で帯域を融通して、視聴品質の悪化が起こる可能性を小さくすることが可能となる。
【００６５】
また、後続のコンテンツ断片の取得を通信速度の異なる複数のデータ送受信手段として優先制御をもったネットワーク層プロトコルを利用する手段により、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 は、TCP Renoと帯域を共有した場合、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からTCP Renoへの変更であったならば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)と与えられているとして、
【数９】
【０１７９】
【数１０】
【数１１】
【０１８０】
以上の処理フローは、クライアント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)であるとする。これらの要求を全て中止しても見込み帯域使用幅がボトルネック限界レート以下にならない、つまり
【数１２】
【０２０４】
ステップＥ１９０において、中止候補の要求の幾つかを中止することで見込み帯域使用幅がボトルネック限界レート以下にできるならば、ステップＥ６０に進み、ステップＥ６０でバッファ余裕がTHLMINjより大きければ、見込み帯域使用幅がボトルネック限界レート以下にできるだけの要求を中止する（ステップＥ２００）。この時、
【数１３】
【０２０５】
新規取得要求を送出するために必要な帯域が確保できたとステップＥ５０で判断されると、先読み制御部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も考慮すると、
【数１４】
【数１５】
【数１６】
【０２０７】
しかし、THSj＞bj(t)かつzj≦rjの時は、バッファ余裕をTHSjにすることはできない。しかし、バッファ余裕を希望バッファ余裕値にできないから全く取得要求を出さないと、さらにバッファ余裕は切迫する。適当なコンテンツ断片の範囲を設定して取得を実行すべきであるが、あまり長い範囲を要求するのは、取得レートを確保するタイミングを遅らせることになってしまい、バッファ余裕が切迫する原因となる。早めに次回の取得要求が実行されるように範囲は小さく設定しすることが望ましい。そこで、最低バッファ余裕値THLMINjを指定し、見込みバッファ余裕がTHLMINjとなる範囲を先読み制御部202Eは設定する。b＊j(t)=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をターゲットとしたコンテンツ断片の取得が既に実行されたことのない場合でも、同一のコンテンツが他のクライアントをターゲットとして取得されたことがあれば、受信状況監視部202E-1に記録されているその最新取得レートで各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２３】
同一のコンテンツが他のクライアントをターゲットとして取得されたことも無ければ、先読み制御部202Eは同一のオリジンサーバからの取得レートが受信状況監視部202E-1に記録されていないか調べる。そしてこの最新値で各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２４】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことも、同一のコンテンツが他のクライアントをターゲットとして取得されたことも、同一のオリジンサーバからの取得実績もない場合、各クラスに対するデフォルト値を用いることで、取得予測レートを設定することができる。
【０２２５】
次に先読み制御部202Eは、指定時間WT後の見込みバッファ余裕を指定した希望バッファ余裕値BTHjにできるクラスが存在するか確認する（ステップＦ４０）。例えば、ユーザの視聴レートが一定でrjであったとすると、
BTHj≦bj(t)+(z＊j(q、t)-rj)×(WT-RTTj、q)
の条件を満たすクラスが存在するかを確認することになる。この条件を満たすクラスが存在する場合は、条件を満たす最も小さいクラスをhとする。このhを最低必要クラスと呼ぶ。ここで、RTTj、qは、クラスqでクライアントjをターゲットとする取得要求を送出してから、開始位置のデータがプロキシサーバに到着するまでの時間である。
【０２２６】
この各クラスでのラウンドトリップタイムRTTj、qは、受信状況監視部202E-1にクライアントjをターゲットとした取得がクラスqで行われた実績があれば記録されている。記録されている場合は、この値を用いれば良い。記憶されていない場合は、適当な記録されているラウンドトリップタイムから換算するか、適当なデフォルト値を用いることになる。
【０２２７】
ラウンドトリップタイムの換算法の具体例を１つ示すことにする。Diffservによる優先制御が行われていて、EF、 AF1、 AF2の３つのクラスがあり、EFはラウンドトリップタイムがRTT1以下に保証されていて、AF1とAF２はそれぞれ重みCIR1、 CIR2でのベストエフォートでの処理がされているとする。EFをクラス1、 AF1をクラス2、 AF2をクラス3とし、EF1での最新のRTT、RTTj、2のみが受信状況監視部202E-1に記録されているとする。このとき、EFではRTTj、1=RTT1と算出できる。AF1でのRTTは、この最新値を用いれば良い。EF2のRTTは、重み付けを用いて、RTTj、3=RTTj、2×CIR1/CIR2と換算することができる。
【０２２８】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことのない場合でも、同一のコンテンツが他のクライアントをターゲットとして取得されたことがあれば、受信状況監視部202E-1に記録されているその最新RTTで各クラスでの取得予測レートを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２２９】
同一のコンテンツが他のクライアントをターゲットとして取得されたことも無ければ、先読み制御部202Eは同一のオリジンサーバからのRTTが受信状況監視部202E-1に記録されていないか調べる。そしてこの最新値で各クラスでのRTTを近似することができる。全てのクラスでの取得実績が無くても、上記の換算法で算出することができる。
【０２３０】
クライアントjをターゲットとしたコンテンツ断片の取得が既に実行されたことも、同一のコンテンツが他のクライアントをターゲットとして取得されたことも、同一のオリジンサーバからの取得実績もない場合、各クラスに対するデフォルト値を用いることで、RTTを設定することができる。
q= h、..、kの中で、(RA(t)+z＊j(q、t))≦RBを満たすものがあるか確認する（ステップＦ５０）。満たすものがあった場合は、ステップＦ６０以降のステップに進むが、なかった場合はステップＦ１４０以下のステップに進む。
(RA(t)+z＊j(q、t)) ≦RB、 q≧hを満たすクラスqが複数存在する場合、そのいずれかのクラスを選択する（ステップＦ６０）。選択方法としては、(RA(t)+z＊j(q、t)) ≦RB、 q≧hを満たすクラスqの中から、
１．最も先読み取得予測レートが大きいクラスを選択、
２．最も先読み取得予測レートが小さいクラスを選択、
３．クライアント毎に与えられている優先度に従い決定する。優先度の高いクライアントほど大きい先読み予測取得レートのクラスを選択する、
などのいずれの方法でも良い。
【０２３１】
クラスが選択できた場合は、取得要求範囲を算出する（ステップＦ７０）。開始位置は、現在の視聴位置もしくはクライアントが視聴中のコンテンツ断片の末尾位置とする。終了位置は、開始位置に(WT+BTHj-bj(t))を加えた位置となる。このような範囲を要求することで、指定時間WT後に、バッファ余裕がBTHjになっていることが期待できる。
【０２３２】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＦ８０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０２３３】
コンテンツ断片の取得要求を送出後は、先読み制御部202Eは以下のいずれかのイベントが発生するのを待つ（ステップＦ９０）。すなわち、クライアントjをターゲットとした取得要求の中止（ステップＦ１２０）と、クライアントjをターゲットとした取得要求の完了（ステップＦ１００）である。
【０２３４】
取得要求が完了のイベントが発生した場合は（ステップＦ１００）、取得要求送出バッファ余裕値THLjを初期値に戻す（ステップＦ１１０）。そして、ステップＦ１０に戻る。
【０２３５】
取得要求が中止された場合は（ステップＦ１２０）、取得要求送出バッファ余裕値THLjを、現在のクライアントjのバッファ余裕より小さい値に設定する（ステップＦ１３０）。例えば、現在の余裕バッファbj(t)のadj倍(adj＜1)などとする。つまり、THLj=adj×bj(t)とする。そしてステップＦ１０に戻る。これは、中止した要求がターゲットとしていたクライアントjを対象とするコンテンツ断片取得の次回取得要求が発生するまでの時間間隔をあけるためである。現在のバッファ余裕より大きい値が取得要求送出バッファ余裕値として指定されると直ちに取得要求が生成されるので、現在のバッファ余裕よりも小さい値を設定する必要がある。
【０２３６】
ステップＦ１１０で初期値に戻すのは、ステップＦ１３０で小さくなった取得要求送出バッファ余裕値をリセットするためである。
【０２３７】
クラスが選択できなかった場合は、いずれかの要求送出を中止する、または実行中の取得の取得レートを引き下げる必要がある。実行中の取得の取得レートを引き下げる際には、処理速度の低いクラスへの切り替えを行う。この作業をクラス下げと呼ぶ。先読み制御部202Eはクラス下げ、または中止となる要求の候補を選択する（ステップＦ１４０）。ステップＦ１４０の詳細を示したフローチャートが図３０である。
【０２３８】
まず、実行中の取得要求のクラス下げ、中止により期待できる削減見込みレートを記憶するパラメータdrを０に初期化する（ステップＧ１０）。
【０２３９】
そして、クラス下げ候補のレート抑制および中止候補の取得中止を実行し、さらに新規取得要求を最低必要クラスで実行した場合の見込み使用帯域幅がボトルネック限界レートRB以下になるかを確認する（ステップＧ２０）。具体的には、最低クラスでの新規取得要求の予測取得レートをz＊j(h、t)とし、現在の使用帯域幅をRA(t)とすると、RA(t)+z＊j(h、t)-dr≦RBが満たされるかを確認する。満たされる場合は、ステップＦ１５０へ進む。満たされない場合は、以下のステップに進む。
【０２４０】
クラス下げ候補／中止候補に含まれない実行中の取得要求の中にターゲットクライアントのバッファ余裕が新規ターゲットクライアントjよりも大きいものがあるか確認する（ステップＧ２０）。ない場合は、クラス下げ候補／中止候補なしとして処理を終了する（ステップＧ４０）。
【０２４１】
クラス下げ候補／中止候補に含まれない実行中の取得要求の中にターゲットクライアントのバッファ余裕が新規ターゲットクライアントjよりも大きいものがが存在する場合、最も大きいクライアントiをターゲットとする取得要求を選択する（ステップＧ５０）。
【０２４２】
この要求の現在の取得クラスをpi、現在の取得レートをzi(qi、t)として、(RA(t)+z＊j(h、t)-(zi(pi、t)- z＊i(hi、t)) ≦RB、 hi＜qとなるクラスhiがあるかを確認する。つまり、見込み使用帯域幅をボトルネックリンク限界レート以下にできるクラスが存在するか確認する（ステップＧ６０）。
【０２４３】
存在した場合は、この要求とクラスhiの組をクラス下げ候補とし、削減見込みレートdrにzi(pi,t)-zi(hi,t)を加える（ステップＧ７０）。そして図２９のステップＦ１５０に進む。
【０２４４】
もし、(RA(t)+z＊j(h、t)-(zi(pi、t)- z＊i(hi、t)) ≦RB、 hi＜qとなるクラスhiを満たすクラスが存在しなければ、このクライアントiをターゲットとする取得要求を中止候補として登録し（ステップＧ８０）、削減見込みレートdrにこの要求の現在の取得レートz＊i(pi、t)を加え、ステップＧ２０に戻る（ステップＧ９０）。
【０２４５】
ステップＦ１４０でクラス下げ候補／中止候補の選択が終了すると、ステップＦ１５０に進む。ステップＦ１５０では、クラス下げ候補／中止候補が登録されているか確認する。登録されていない場合は、新規取得要求の送出を中止し（ステップＦ１７０）、クライアントjの取得要求送出バッファ余裕値を現在のバッファ余裕よりも小さく設定する（ステップＦ１８０）。例えば、現在の余裕バッファのadj倍(adj＜1)などとする。つまり、THLj=adj×bj(t)となどとすればよい。現在のバッファ余裕よりも小さく設定するのは、クライアントjをターゲットとした取得要求が出るまでの間隔を空けるためである。
【０２４６】
もし、クラス下げ候補／中止候補が登録されているならば、候補のクラス下げ、中止を実行する。そして、ステップＦ７０へ進む。
【０２４７】
以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０２４８】
第９の実施の形態の形態の効果は、ボトルネックを競合する要求間での調整を、クラスを使い分けることで第６、７、８の実施の形態に比べより粒度の細かい制御が可能であることである。より有効に空き帯域を利用でき、より効果的に輻輳回避を実現できる。
【０２４９】
（第１０の実施の形態）
第５〜９の実施の形態では、バッファ余裕または見込みバッファ余裕の量に依存して新規のコンテンツ断片取得要求が生成されていた。そして、生成された要求間で帯域を融通しあうことにより、ネットワークの輻輳を回避していた。これらの方式はネットワークの輻輳状況によらず新規取得要求を（後に中止することがあるが）生成してしまう。つまり、ネットワークの輻輳状況に応じて、要求の送出を抑制する仕組みが第５〜第９の実施の形態では実現されていなかった。要求の中止時に取得要求送出バッファ余裕値を下げる制御により、輻輳時の要求送出間隔を大きくする制御は第６〜第９の実施の形態でも実現はされている。しかしネットワークの輻輳を検知した時点で、要求送出間隔を大きくすることができれば、より早期にネットワークの輻輳を回避できるはずである。逆に、ネットワークが空いている場合は、要求送出間隔を小さくすれば、ネットワーク帯域に隙間を作ることなく、より有効にバッファ余裕を確保することができるはずである。そこで、第１０の実施の形態では、バッファ余裕または見込みバッファ余裕をネットワークの輻輳に応じて調整する方式を示す。ここでは、バッファ余裕を調整する方式を示すが、これは見込みバッファ余裕と置き換えても良い。
【０２５０】
エンド−エンドのネットワークの輻輳状況を反映している値が、コンテンツ断片の要求を送出してからデータが到着するまでのラウンドトリップタイム（Round Trip Time、 以下RTT）である。そこで受信状況監視部202E-1は、この各コンテンツ断片取得時にRTTを測定する。このRTTの情報を効果的に活用することで、空き帯域の活用、輻輳時の帯域競合回避を実現する。
【０２５１】
本実施の形態の特徴は、ネットワークの輻輳状況をRTTにより捉え、RTTの増加、つまりネットワークが輻輳したと判断されたときには、取得要求送出バッファ余裕値を小さくし、要求の送出間隔を大きくすることである。この制御により、ネットワークの輻輳の要求送出を抑制できるため、より早いネットワークの輻輳解消が期待できる。また、RTTの減少、つまりネットワークが空いていると判断されたときには、取得要求送出バッファ余裕値を大きくし、要求の送出間隔を小さくする。この制御により空き帯域を積極的に利用したコンテンツ断片取得が実現される。
【０２５２】
この第１０の実施の形態の処理フローを、図３１のフローチャートと図２３の構成図を用いて説明する。クライアントからの視聴リクエストがストリーム配信制御部201Eを通じて先読み制御部202Eに到着すると（ステップＨ１０）、先読み制御部202Eは、その新規ターゲットクライアントjの取得要求送出バッファ余裕値THLjを指定されている初期値に初期化する（ステップＨ２０）。
【０２５３】
クライアントjをターゲットとしたコンテンツ断片の取得要求が送出されてから開始位置のコンテンツデータが到着するまでのRTT(以下RTTjと表記)は、視聴開始時には測定履歴がない。そこでRTTjの初期値を以下のいずれかの方法で設定する（ステップＨ３０）。
（１）同一のコンテンツに対する他のクライアントiをターゲットとしたコンテンツ断片取得が実行されている場合は、そのクライアントiのRTTを用いる。つまり、RTTj=RTTiとする。
（２）過去に同一コンテンツに対する要求があった場合は、その最新のRTTを利用する。
（３）適当なデフォルト値として初期設定する。
【０２５４】
そして先読み制御部202Eはコンテンツ断片の取得範囲を算出する（ステップＨ４０）。この範囲の算出法は、第５の実施の形態と同様である。
【０２５５】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定したコンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＨ５０）。コンテンツ断片の取得を指示されたトランスポート層制御部205Eは、オリジンサーバとの間にコネクションが存在しなければ開設、既に存在すればそれを再利用し、コンテンツ断片の取得を実行する。
【０２５６】
要求の送出から要求したコンテンツ断片の開始位置の到着までの時間（RTT）を受信状況監視部202E-1で測定し、記録する（ステップＨ６０）。この際、古いRTTjはRTTj_oldに保存しておく。
【０２５７】
そして、第５の実施の形態では固定値として与えていたクライアントjの取得要求送出バッファ余裕値THLjを、クライアントjをターゲットとしたコンテンツ断片の取得要求が送出されてから開始位置のコンテンツデータが到着するまでのRTTに依存して動的に変化させる（ステップＨ７０）。受信状況監視部202E-1は、クライアントjをターゲットとしたコンテンツ断片取得のRTTが増加してくると、THLjを小さくする。RTTが小さくなるとTHLjを大きくする。例えば、前回のコンテンツ断片要求時のRTTをRTTj_old、今回のコンテンツ断片要求時のRTTをRTTjとすると、
THLj_old = THLj;
THLj = THLj_old×RTTj_old /RTTj;
としてTHLjを更新する。RTTの増加（減少）に対してTHLjを減少（増加）させるなら、ここで示した方法にこだわる必要はない。このようにRTTが増加した場合にTHLjを減少することで、ネットワーク輻輳時に要求送出を行ってしまう可能性を減らすことができる。
【０２５８】
しかし、THLjを小さくしすぎると、ネットワークの輻輳が長引くとバッファが枯渇し、クライアントの視聴品質が劣化する危険性がある。そこで、THLjは設定された最小値THLmin-j以下にはならないようにする。また、あまりに大きなバッファ余裕を持つことは記憶部204Eのスペースを圧迫するという意味で無駄であるため、THLj は指定された最大値THLmax-j以上にならないようにする。
【０２５９】
そして、先読み制御部202Eはバッファ余裕値bj(t)を監視し、取得要求送出バッファ余裕値THLj以下になるまで待つ（ステップＨ８０）。なったらステップＨ４０に戻り、再び要求の送出を行う。
【０２６０】
以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０２６１】
上記の第１０の実施の形態では、RTTを基にした制御を示した。しかし、ネットワークの輻輳はRTTのみで検知されるものではない。RTTを他のネットワークの輻輳を検知する指標に置き換えることも可能である。例えば、ボトルネックリンクの使用率で置き換えた制御も可能である。より具体的には、ステップＨ７０での取得要求送出バッファ余裕値THLjを、ボトルネックの使用率に依存して動的に変化させる。このときの構成は、図２６に示される第６の実施の形態の構成と同様であるとする。先読み制御部202Eは、ネットワーク情報収集部207Eからボトルネックリンクの使用率を所得する。ボトルネックリンクの使用率が増加してくると、THLjを小さくする。RTTが小さくなるとTHLjを大きくする。例えば、ある時間幅のタイムスロット毎に、先読み制御部202Eはネットワーク情報収集部207Eからボトルネックリンクの使用率を所得するとする。前回のタイムスロットでのリンク使用率をUold、今回のタイムスロットでのリンク使用率をUとすると、
THLj_old = THLj;
THLj = THLj_old×Uold /U;
としてTHLjを更新する。ボトルネックリンクの使用率の増加（減少）に対してTHLjを減少（増加）させるなら、ここで示した方法にこだわる必要はない。このようにボトルネックリンクの使用率が増加した場合にTHLjを減少することで、ネットワーク輻輳時に要求送出を行ってしまう可能性を減らすことができる。
【０２６２】
さらに、これまで示した第１０の実施の形態は、第５の実施の形態をベースとしていたが、ベースとなる制御は第６〜第９の実施の形態に置き換えることも容易に可能である。
【０２６３】
第１０の実施の形態の効果は、第５から第９の実施の形態に比較して、より早期にネットワークの輻輳を回避できることである。ネットワークの輻輳状況に応じて、要求の送出を抑制する仕組みを入れることでネットワークの輻輳を検知した時点で、要求送出間隔を大きく、逆に、ネットワークが空いている場合は、要求送出間隔を小さくすることで、この効果が実現できる。
【０２６４】
（第１１の実施の形態）
第１０の実施の形態は、ネットワークの輻輳時の要求送出の回避を１つの特徴としている。しかし、第１０の実施の形態でも触れたように、この制御はネットワークの輻輳が持続した場合、バッファ余裕の枯渇、配信品質の劣化に繋がる可能性がある。
【０２６５】
ボトルネックリンクは輻輳していないにも関わらず、特定のコネクション（特定のオリジンサーバ）からの取得が輻輳により遅くなっているケースもある。このような場合、第１０の実施の形態とは逆に、RTTの増加に対しては、積極的に要求送出を行うべきである。できるだけ早く取得要求を送出しなければ、取得が間に合わない危険性が高いからである。
【０２６６】
第１１の実施の形態の特徴は、ネットワークの輻輳状況をRTTにより捉え、RTTの増加、つまりネットワークが輻輳したと判断されたときには、バッファ余裕をできるだけ大きく維持できるように、RTTが小さいときに比べ、より頻繁にコンテンツ断片の取得を行う。この制御により、ネットワークの輻輳に伴うデータの到着遅延に伴うバッファの枯渇（バッファ余裕が０となること）を回避することができる。
【０２６７】
第１０の実施の形態との相違点は、図３１のステップＨ７０での取得要求送出バッファ余裕値THLjの設定のみである。
【０２６８】
前回のコンテンツ断片要求時のRTTをRTTj_old、今回のコンテンツ断片要求時のRTTをRTTjとすると、
THLj_old = THLj;
THLj = THLj_old×RTTj/RTTj_old;
としてTHLjを更新する。RTTの増加（減少）に対してTHLjを増加（減少）させるなら、ここで示した方法にこだわる必要はない。このようにRTTが増加した場合にTHLjを増加することで、コンテンツ断片取得に時間を要するコンテンツの取得要求ほど頻繁に送出される。データ取得に時間を要することに伴うバッファの枯渇を抑制できるようになり、より多くのクライアントへの配信品質を保証できるようになる。
【０２６９】
しかし、あまりに大きなバッファ余裕を持つことは記憶部204Eのスペースを圧迫するという意味で無駄であるため、THLjは指定された最大値THLmax-j以上にならないようにする。また、THLjを小さくしすぎると、バッファがちょっとしたネットワークの輻輳で枯渇し、クライアントの視聴品質が劣化する危険性がある。そこで、THLjは設定された最小値THLmin-j以下にはならないようにする。
【０２７０】
第１１の実施の形態は、第１０の実施の形態同様、基本的な構成は第５〜第９のいずれの実施の形態でも構わない。特に第７〜第９の実施の形態をベースとすれば、ボトルネックリンクの輻輳はある程度回避できるので、第７〜第９の実施の形態をベースとすることが望ましい。
【０２７１】
第１１の実施の形態の効果は、従来防ぐことができなかった、特定のコネクション（取得パス）の輻輳時のバッファ枯渇を防止できることである。ボトルネックリンクの監視と併用すればより優れた効果が期待できる。
【０２７２】
（第１２の実施の形態）
これまでの実施の形態では、1人のクライアントをターゲットする取得要求は同時に１つしか実行しないとしてきた。しかし、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合には、この1人のクライアントをターゲットする取得要求は同時に１つしか実行しないという制約があると、帯域に空きがあってもその空き帯域を活用した積極的な取得を実現することができない。例えば、オリジンサーバがクライアントの視聴レートと同じレートでしかデータを送出しないように設計されているような場合が挙げられる。1人のクライアントをターゲットする取得要求は同時に１つしか実行しないと、視聴レートでしかデータを取得できないため、バッファ余裕を現在値よりも増やすことが不可能である。この場合、ネットワークの輻輳等でデータの到着が遅れると、直ちにバッファ余裕が不足し、クライアントに送信されるストリームの品質が劣化する恐れがある。
【０２７３】
１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行すれば、空き帯域を活用した積極的な取得を実現することができる。
【０２７４】
第１２の実施の形態では、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行することで空き帯域を活用した積極的な取得を実現し、より多くのクライアントが配信品質を維持するために十分なバッファ余裕を確保できる制御方式を示す。
【０２７５】
図３２のフローチャートと図２６の構成図を用いて、第１１の実施の形態を説明する。以下の実施の形態は、第８の実施の形態の見込みバッファ余裕を用いた制御をベースとしているが、見込みバッファ余裕を用いることは本実施の形態の本質ではない。本実施の形態の本質は、同一のクライアントをターゲットする取得要求によるデータの取得レートの引き上げを複数の取得要求の同時実行により実現すること、その際の同時実行数をネットワークの輻輳を引き起こさない範囲に抑えることである。
【０２７６】
ここで、本実施の形態における見込みバッファ余裕を、図３３を参照して定義する。図３３の301の横軸は視聴時間を表す。クライアントの時刻PT後の視聴位置は302の三角形で示した位置であるとする。そして、現在３つの同一クライアントをターゲットとした要求が実行されているとする。1番目の要求(311)は、ストリームプロキシサーバ上に時刻PT後に303で示される位置から304で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は305で示される位置だとする。302と304の間の時間幅をET1とする。2番目の要求(312)は、ストリームプロキシサーバ上に時刻PT後には305で示される位置から306で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は307で示される位置だとする。305と306の間の時間幅をET2とする。3番目の要求(313)は、ストリームプロキシサーバ上に時刻PT後には307で示される位置から308で示される位置までのデータを取得していると見込まれ、取得要求を完了する位置は309で示される位置だとする。307と308の間の時間幅をET3とする。まず、１つの定義としては、見込みバッファ余裕は、現在より時刻PT後の同一クライアントをターゲットとした要求により取得されたデータのうち、クライアントが未視聴のデータの時間という定義ができる。このとき、見込みバッファ余裕は、ET1+ET2+ET3となる。また別の定義としては、視聴位置から時刻PT後に取得されているデータ上で、現在の視聴位置から見てデータが途切れるまでの時間という定義もできる。この場合、図３３の例ではET1が見込みバッファ余裕となる。
【０２７７】
このように幾つか見込みバッファ余裕は定義できるが、以下は現在より時刻PT後の同一クライアントをターゲットとした要求により取得されたデータのうち、クライアントが未視聴のデータの時間という定義を用いて説明する。このことは本質ではなく、視聴位置から時刻PT後に取得されているデータ上で、現在の視聴位置から見てデータが途切れるまでの時間という定義に置き換えてもほぼ同様の実施の形態を実現できる。
【０２７８】
次に本実施の形態の大まかな方針を示す。
【０２７９】
バッファが枯渇寸前の場合（バッファ余裕が０に近い場合）は、コンテンツ断片取得を行うべきかどうかは取得レートとユーザの視聴レートの大小関係で決定される。取得レートが視聴レートよりも低ければ、バッファ余裕が回復する見込みは無い。見込みバッファ余裕は０と算出される。この場合、すぐにクライアントへの配信は中断されるのでコンテンツ断片を取得することは帯域の輻輳を助長するだけである。よってさらなるコンテンツ断片の要求を中止する。これまでの実施の形態では、１つのターゲットクライアントに対する取得要求の同時実行数が１と限定されていたため、この判断を１つの取得要求（１コネクション）で実現できる取得レートを基に判断してきた。しかし、本実施の形態では、帯域に余裕がある範囲で、同一のクライアントをターゲットとする取得要求を複数実行することを許す。空き帯域で並行に複数の取得を実行してもなお、それらの取得要求によるデータの合計取得レートがクライアントの視聴レートよりも小さく、バッファ余裕を回復する望みがなければ取得要求の送出を中止する。それらの取得要求によるデータの合計取得レートがクライアントの視聴レートよりも大きければ、バッファが枯渇寸前であってもバッファ余裕を回復することが可能である。つまり見込みバッファ余裕がある程度の値になることを期待できる。そのため、バッファ余裕を回復するのに必要な合計取得レートを、帯域が許す範囲で並行に取得要求を実行することで確保し、バッファ余裕の回復を図る。
【０２８０】
次にバッファ余裕が（枯渇寸前というほどではないが）あまり無い場合を考える。同一クライアントをターゲットする取得要求によるデータの取得レートの合計が視聴レートより大きい場合は上記と同様に、見込みバッファ余裕がある程度の値になることを期待できる。帯域が許す範囲で平行に取得要求を実行することで確保し、バッファ余裕の増加を図る。同一クライアントをターゲットする取得要求によるデータの取得レートの合計が視聴レートよりも小さい場合は、バッファ余裕はさらに減少する。つまり見込みバッファ余裕は０に近くなる。このままではバッファが枯渇してしまうのでできるだけ早く適切な取得レートを確保したい。そのためには、ターゲットとするクライアントのバッファ余裕が大きい要求があれば、それらの取得を中断させ、それらの要求が使っていた帯域を譲り受け、必要な取得レートを確保する。その際、後続のコンテンツ断片の取得要求を必要な帯域を確保できるまで優先的に中止する。他の要求を中断させることが可能なのは、より大きなバッファ余裕を持つ要求が存在する場合である。そのような要求が存在しない場合は、必要とする取得レートを確保することは不可能である。しかし、必要な取得レートが確保できるまで全くコンテンツ断片を取得しないと、すぐにバッファが枯渇してしまう（見込みバッファ余裕が０となる）。よってとりあえず可能な取得レートでコンテンツ断片を取得してバッファが枯渇するまでの時間を引き延ばす必要がある。しかし、そのままの取得レートが長期間続いても、ターゲットとするクライアントのバッファ余裕が枯渇するのも明らかである。取得レートが視聴レートを上回る場合に比べて、短い期間でコンテンツ断片の取得を終了させ、必要な取得レートを確保できないか確認すべきである。そこで、この小さな取得レートで確保する期間、つまり要求する範囲を小さくする。
【０２８１】
次にバッファ余裕が十分にある場合を述べる。バッファ余裕が十分にあれば一般には今すぐコンテンツ断片を取得する必要は無い。よってコンテンツ断片要求の送出は先送りしてよい。しかし、取得レートが視聴レートに比べ、著しく低くなっている場合はその限りでない。この場合、ネットワークが著しく輻輳してきていることを意味する。この場合、現在は十分にあるバッファ余裕がすぐになくなることを意味する。つまりコンテンツ断片取得を行わなければ、見込みバッファ余裕は０に近くなる。この場合は、確保できる取得レートで良いのでコンテンツ断片を取得し、ネットワークの輻輳が解消するまでバッファが枯渇しないように凌ぐべきである。
【０２８２】
以下詳細な制御をフローチャート図３２と構成図２６を用いて説明する。
【０２８３】
コンテンツ取得要求の生成は、クライアントからの視聴リクエストの到着、または以下で説明するクライアント毎に設定されるコンテンツ断片取得要求送出時刻、さらにネットワーク情報収集部207Eがボトルネックリンクの帯域に空きが生じたことを検知した時に発生する。先読み制御部202Eは、ストリーム配信制御部201Eからの視聴リクエストの到着、コンテンツ断片取得要求送出時刻のイベントを監視し、新規取得要求の生成を待つ。そして新規ターゲットクライアントjを決定する。また、ネットワーク情報収集部207Eはボトルネックリンクの帯域に空きが生じたことを検知すると、先読み制御部202Eに新規取得要求の生成を指示する。先読み制御部202Eは、最も見込みバッファ余裕の少ないターゲットクライアントjを新規ターゲットクライアントとして決定する（ステップＫ１０）。
【０２８４】
まず、現在時刻での実際のクライアントjのバッファ余裕を確認する（ステップＫ２０）。もしバッファ余裕bj(t)がクライアント毎に指定された希望バッファ余裕値THSjより大きく(bj(t)＞THSj)、かつクライアントjをターゲットとした実行中の要求全ての合計取得レートが、クライアントjの視聴レートを超えている場合は、まだ余裕があると判断し、新規取得要求の送出を中止する（ステップＫ１６０）。そしてコンテンツをクライアントが視聴中なら、次回要求生成時刻を設定する（ステップＫ１７０）。次回要求生成時刻の設定法は、後述するステップＫ１４０で説明する。バッファ余裕がTHSj以下、またはバッファ余裕はTHSjを超えるがクライアントjをターゲットとした要求の取得レートが、クライアントjの視聴レートを下回る場合は、ステップＫ３０以下のステップに進む。
【０２８５】
bj(t)≦THSjの場合は、先読み制御部202Eは、ネットワーク情報収集部207Eからボトルネックリンクの帯域使用幅RA(t)を得る（ステップＫ３０）。ネットワーク情報収集部207EのRA(t)を得る方法は、第５の実施の形態と同様である。
【０２８６】
次に、新規取得要求を幾つの要求として並行に実行するかと、それぞれの要求で期待される先読み取得予測レートを算出する（ステップＫ４０）。クライアントjをターゲットとした取得要求が既にmj個実行中であるとする。取得要求の範囲が手前の順に１からmjまでのラベル付けがされているとする。そしてこれらの要求がデータを取得しているレートをzj,h(t) (h=1,..,mj)とする。ここに、新たにクライアントjをターゲットとした取得要求を増やして行った際に、期待できる先読み予測取得レートを先読み制御部202Eは予測する。このレートを先読み取得予測レートと呼び、z＊j,mj+k(t) (h=1,…)で表すことにする。このz＊j,mj+k(t)の推定方法は第６の実施の形態と同様、またはオリジンサーバへ問い合わせることでわかるものとする。そして、この先読み予測取得レートを基に、新規取得要求を幾つ実行したいかを算出する。バッファ余裕を希望する値にするために必要なレートを何本のコネクションでこのレートを実現できるか、つまり幾つの新規取得要求を並行に実行する必要があるかを算出する。例えば、現在より時刻PT後に、バッファ余裕を希望バッファ余裕値THSjにするための取得レートを新規に確保する、という方式が考えられる。クライアントjが要求を送出してオリジンサーバからデータが届くまでの時間をRGSjとする。また、クライアントjをターゲットとした、（先に付けたラベル付けで）h番目の要求の取得完了見込み時刻をTFj,hとする。希望する取得レートは、現在実行中の取得要求の実行を継続した場合に、これから新規取得要求を送ることで、時刻PT後に希望バッファ余裕値THSｊを確保するために必要な取得レートである。これは、
【数１９】
【数２０】
【数２１】
ボトルネックリンクにそれらの先読み取得予測レートのトラヒックが加わった際の見込み帯域使用幅がボトルネック限界レートRBを超えないか確認する（ステップＫ５０）。つまり、
【数２２】
【数２３】
【０２８７】
ここで、中止バッファ余裕の算出法の一例を挙げることにする。該要求を中止した場合の、現在時刻から指定時間幅PT先の見込みバッファ余裕を中止バッファ余裕と定義する。要求を送出してから実際に中止されるまでには、プロキシストリームサーバ20Eからオリジンサーバまでパケットが届く時間だけかかる。クライアントiをターゲットとしたコンテンツ断片の取得要求を中止するために要する時間をRCSiで表すことにする。ここで、RCSiは、受信状況監視部202E-1で測定されているクライアントiをターゲットとする取得要求のRTTであるRTTiの半分などと近似すればよい。該要求が、クライアントiをターゲットとした要求の（先のラベル付けで）mi番目であるとする。mi番目が中止候補となる場合、mi+1番目以降の要求が存在したとしても、後続要求から中止候補となるため、すでにそれらは中止候補となっている。そのため、該要求を中止した場合、mi-1番目以下の要求が実行されている状況での見込みバッファ余裕が、中止バッファ余裕となる。具体的に示すと、クライアントiをターゲットとするmi番目の取得要求の中止バッファ余裕は、
【数２４】
【０２８８】
次に未送出時バッファ余裕の算出法の一例を挙げることにする。新規取得要求が先のラベル付けで、クライアントiをターゲットとするmi+h番目の要求であったとすると、未送出バッファ余裕は、mi+(h-1)番目までの新規要求を送出した際のバッファ余裕に相当する。つまり、
【数２５】
【０２８９】
各要求に対して、中止バッファ余裕、未送出バッファ余裕を算出する。そしてその値の大きい順に中止候補として行く。中止候補は、中止候補にならなかった実行中の要求を継続し、さらに中止候補とならなかった新規取得要求を実行しても、実行中の要求の取得レートと新規要求による予測取得レートの合計が、ボトルネック限界レート以下となるまで選択される。
【０２９０】
ただし、相対的な見込みバッファ余裕の大小のみで取得要求を中止して行くと、全ての要求のバッファ余裕が単調に減少し、結局全てのクライアントへの配信品質が劣化する恐れがある。そこで、ターゲットクライアントの見込みバッファ余裕値が、設定した最低見込みバッファ余裕閾値以下となった時点で中止候補の選択は打ち切る。
そして選択された中止候補の取得要求を中止することでボトルネックの見込み帯域使用幅をボトルネック限界レート以下にできるか調べる（ステップＫ１９０）。クライアントiをターゲットとした、要求hの現在時刻ｔでの取得レートをzi,h(t)で表す。ターゲットとなっているクライアントの数がMであり、クライアントiをターゲットとした中止候補となっていない要求がmi個(i=1,…,M)あり、中止候補となっていない新規取得要求がそれぞれni個（i=1,…M）だけあるとする。これらの要求を全て中止しても見込み帯域使用幅がボトルネック限界レート以下にならない、つまり
【数２６】
【０２９１】
ステップＫ１９０において、中止候補を中止することで見込み帯域使用幅がボトルネック限界レート以下にできるならば、ステップＫ６０に進み、ステップＫ６０でバッファ余裕がTHLMINjより大きければ、実行中の中止候補の要求は実行を中止し、中止候補に含まれる新規取得要求は破棄する（ステップＫ２００）。
【０２９２】
新規取得要求を送出するために必要な帯域が確保できたとステップＫ５０で判断されると、先読み制御部202Eは、ステップＫ７０以下の要求するコンテンツ断片の範囲の算出に進もうとする。
【０２９３】
しかし、実行中の取得要求と算出された新規取得要求の先読み取得予測レートの合計（以下合計取得予測レート）
【数２７】
【０２９４】
ステップＫ７０では、新規取得要求のコンテンツ断片の範囲の算出を行う。まず先頭の新規取得要求の開始位置は前回要求の終了位置と現在視聴位置のうち大きいほうの値に一致する。これは第５、第６の実施の形態と同様である。最後尾（クライアントjをターゲットとする要求の中で最後の要求）の取得要求の終了位置は、取得要求の実行完了時の見込みバッファ余裕を希望バッファ余裕値THSjにできる位置とする。例えば、ストリームが固定視聴レートrjのCBRとしてエンコードされていて、プロキシストリームサーバ20Eがオリジンサーバからストリームデータを取得する合計取得予測レートがコンスタントにzjである場合の終了位置の算出法を説明する。プロキシストリームサーバ20Eは、要求した開始位置のデータの到着から、終了位置のデータの到着までの間、(zj-rj)のレート（bps）でバッファを増加する。これをバッファ余裕に換算すると、単位時間あたりに(zj-rj)/rj秒分のバッファ余裕が生じていることになる。プロキシストリームサーバ20Eが、コンテンツ取得要求を送信してから、終了位置のデータを受信するまでの時間をSTと置くと、ST後の見込みバッファ余裕b＊j(t+ST)は、要求送信から開始位置のデータ受信までのRTTであるRTTjも考慮すると、
【数２８】
【数２９】
【数３０】
【０２９５】
しかし、THSj＞bj(t)かつzj≦rjの時は、バッファ余裕をTHSjにすることはできない。しかし、バッファ余裕を希望バッファ余裕値にできないから全く取得要求を出さないと、さらにバッファ余裕は切迫する。適当なコンテンツ断片の範囲を設定して取得を実行すべきであるが、あまり長い範囲を要求するのは、取得レートを確保するタイミングを遅らせることになってしまい、バッファ余裕が切迫する原因となる。早めに次回の取得要求が実行されるように範囲は小さく設定することが望ましい。そこで、最低バッファ余裕値THLMINjを指定し、見込みバッファ余裕がTHLMINjとなる範囲を先読み制御部202Eは設定する。b＊j(t)=THLMINjとなるのは、
【数３１】
【数３２】
【０２９６】
そして先読み制御部202Eは、トランスポート層制御部205Eに、先のステップで決定した範囲を指定した中止候補とならなかったni個の新規コンテンツ取得要求をオリジンサーバに送出してコンテンツ断片を受信するように指示する（ステップＫ８０）。
【０２９７】
そして、送出した要求の中止（ステップＫ１１０）、または送出した要求によるコンテンツ断片の取得完了（ステップＫ１００）のいずれかのイベントが発生するのを先読み制御部202Eは待つ（ステップＫ９０）。
【０２９８】
コンテンツ断片の取得が完了した場合（ステップＫ１００）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＫ１２０）。次回要求送出時刻は、バッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、クライアントjをターゲットとした実行中の要求がmi個あるとすると、XT後のバッファ余裕は、
【数３３】
【０２９９】
コンテンツ断片の取得要求の中止の場合（ステップＫ１１０）、先読み制御部202Eはクライアントjをターゲットとする取得要求の次回送出時刻を設定する（ステップＫ１４０）。中止の場合、次回の要求送出までの間隔をある程度空けなければならない。直ちに再要求を実行することは、ネットワークの輻輳に拍車をかけることになるからである。現在のバッファ余裕値が、bj(t)＞THLjの場合は、次回要求生成時刻は、完了時と同様にバッファ余裕が取得要求送出バッファ余裕閾値THLjに達すると予測される時刻とすればよい。それに対し、現在のバッファ余裕値が、bj(t)≦THLjの場合は、次回要求送出時刻は、見込みバッファ余裕が最小バッファ余裕値THLMINjに達すると予測される時刻を次回の要求生成時刻として設定する。現在のバッファ余裕がbj(t)(≧THLMINj)とすると、XT秒先の見込みバッファ余裕b＊j(t+XT)は、中止後のクライアントjをターゲットとする実行中の要求数をkiとすると、
【数３４】
【０３００】
また、以上の処理フローは、クライアントjからの視聴終了リクエストがストリーム配信制御部201Eを通じて、先読み制御部202Eに届くと中止される。先読み制御部202Eは、視聴終了リクエストを受けると、トランスポート層制御部205Eに対して、オリジンサーバへ取得中止の要求を送出するように指示する。また、必要があればオリジンサーバとストリームプロキシサーバ間のコネクションの切断も指示する。
【０３０１】
第１２の実施の形態の効果は、１つの取得要求がデータを取得するために使える実効帯域が限定されている場合でも、1人のクライアントをターゲットする取得要求を同時に複数実行することで、空き帯域を活用した積極的な取得を実現することができることである。
【０３０２】
なお、上記各実施の形態のストリームプロキシサーバは、ストリーム配信制御部、先読み制御部、受信レート制御部、トランスポート層制御部、ネットワーク情報収集部、その他の機能をハードウェア的に実現することは勿論として、各機能を備えるプロキシ制御プログラムを、コンピュータ処理装置のメモリにロードすることでソフトウェア的に実現することができる。このプロキシ制御プログラム１０００は、磁気ディスク、半導体メモリその他の記録媒体に格納される。そして、その記録媒体からコンピュータ処理装置にロードされ、コンピュータ処理装置の動作を制御することにより、上述した各機能を実現する。
【０３０３】
以上好ましい実施の形態及び実施例をあげて本発明を説明したが、本発明は必ずしも上記実施の形態及び実施例に限定されるものではなく、その技術的思想の範囲内において様々に変形して実施することができる。
【０３０４】
【発明の効果】
以上説明したように本発明によれば、以下に述べるような効果が実現される。
【０３０５】
第１に、プロキシサーバにおいて、ネットワークを流れる他のトラヒックへの影響を極力抑えてオリジンサーバからのコンテンツの取得を実現することができる。
【０３０６】
第２に、プロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御し、同一のボトルネックを共有するコンテンツの間で帯域の割り当て制御を行うことにより、視聴品質の悪化が起こる可能性を極力抑えることを可能する。
【０３０７】
第３に、プロキシサーバにおいて、オリジンサーバからのコンテンツ取得レートを制御することにより、優先度の高い視聴に関して視聴品質の悪化が起こる可能性を最小限に抑えることを可能とする。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態のストリームプロキシサーバを使ったネットワーク構成を示す図である。
【図２】 本発明の第１の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図３】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図４】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図５】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図６】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図７】 本発明の第１の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図８】 本発明による希望レートの決定方法を説明する図である。
【図９】 本発明の第１の実施の形態のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図１０】 本発明の第１の実施の形態のストリームプロキシサーバ保持しているストリーム断片を説明する図である。
【図１１】 本発明の第２の実施の形態のストリームプロキシサーバを使ったネットワーク構成を示す図である。
【図１２】 本発明の第２の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図１３】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１４】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１５】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１６】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１７】 本発明の第２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図１８】 本発明の第２の実施の形態のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図１９】 本発明の第２ストリームプロキシサーバが保持しているストリーム断片を説明する図である。
【図２０】 本発明の第３の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図２１】 本発明の第４の実施の形態のストリームプロキシサーバの内部構成を示すブロック図である。
【図２２】 本発明の第５、第６の実施の形態のネットワーク接続状況を示すための構成を示す図である。
【図２３】 本発明の第５の実施の形態のストリーミングプロキシサーバの内部構成を示すブロック図である。
【図２４】 本発明の第５の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２５】 本発明の第５の実施の形態における要求するコンテンツ断片の範囲の算出法を説明するための図である。
【図２６】 本発明の第６の実施の形態のストリーミングプロキシサーバの内部構成を示すブロック図である。
【図２７】 本発明の第６の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２８】 本発明の第８の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図２９】 本発明の第９の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３０】 本発明の第９の実施の形態のストリームプロキシサーバの先読み制御部のクラス下げ／中止候補選択の動作フローチャートである。
【図３１】 本発明の第１０の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３２】 本発明の第１２の実施の形態のストリームプロキシサーバの先読み制御部の動作フローチャートである。
【図３３】 本発明の第１２の実施の形態における見込みバッファの定義を説明する図である。
【図３４】 従来のストリームプロキシサーバを用いたネットワーク構成を示す図である。
【図３５】 従来のストリームプロキシサーバの内部構成を示すブロック図である。
【図３６】 従来のストリームプロキシサーバの動作を説明するタイミングチャートである。
【図３７】 従来のストリームプロキシサーバが保持しているストリーム断片を示す図である。
【符号の説明】
10-1−10-n クライアント
20A、20B、20C、20D、20E ストリームプロキシサーバ
30 ルータ
50、60、80 ネットワーク
70、110、120、130 ネットワーク
40-1−40m オリジンサーバ
201A、201B、201C、201D、201E ストリーム配信制御部
202A、202B、202C、202D、202E 先読み制御部
202E-1 受信状況監視部
204A、204B、204C、204D、204E 記憶部
205A、205B、205C、205D、205E トランスポート層制御部
206A、206B、206C、206D、206E 受信レート制御部
207A、207B、207C、207D、207E ネットワーク情報収集部
Claims (3)
- コンテンツの一部または全部を記憶装置に格納し、当該記憶装置からクライアントにコンテンツを配信しながら、該コンテンツの保持していない部分をオリジンサーバから取得して前記記憶装置に追加するプロキシサーバにおいて、
各コンテンツの前記クライアントへの配信レートと、該コンテンツの前記オリジンサーバからの取得レートの履歴に基づいて、各コンテンツの受信バッファ閾値を決定し、
コンテンツの受信バッファ量が該コンテンツの前記受信バッファ閾値を上回るもののコンテンツ取得には、低優先のトランスポート層プロトコルを使用し、
前記受信バッファ量が前記受信バッファの閾値を下回る量が大きいものほどコンテンツ配信レートより高い取得レートとし、かつ、各コンテンツの取得レートを合計したレートがネットワークの空き帯域を越えないように、各コンテンツの取得レートを制御し、
各コンテンツの前記受信バッファ閾値と、各コンテンツの現在の受信バッファ量から、各コンテンツの希望取得レートを決定し、
現在配信を行っている全コンテンツの希望取得レートの合計が、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、各コンテンツの取得レートを、前記希望取得レートとし、
そうでない場合には、あらかじめ決められたコンテンツの優先度の高い順に、前記希望取得レートを、希望取得レートの合計が、前記ネットワークの空き帯域を越えないコンテンツまで割り当てることを特徴とするプロキシサーバ。 - コンテンツの一部をバッファに蓄積し、前記バッファからクライアントにコンテンツを配信しながら、該コンテンツの現在のバッファへの蓄積位置より後続のコンテンツ部分を、コンテンツを分割した断片としてオリジンサーバから取得し、バッファに追加するプロキシサーバにおいて、
現在より先の時刻での各クライアントの見込みバッファ量を、現在の取得レート、および、視聴レートから求め、
前記見込みバッファ量がゼロ以下のコンテンツは取得を中止し、
前記見込みバッファ量があらかじめ決められたバッファ閾値を下回ったコンテンツについて、
前記ストリームの過去のオリジンサーバからのコンテンツ取得レートの履歴から決められる予測取得レートが、前記オリジンサーバと当該プロキシサーバの間のネットワークの空き帯域を越えない場合には、該コンテンツ取得を行い、
そうでない場合には、バッファ量が前記閾値を越えているストリームのコンテンツ取得を、低優先のトランスポート層プロトコルを用いて行うことを特徴とするプロキシサーバ。 - 前記低優先のトランスポート層プロトコルとして、TCP Vegasを用いて行うことを特徴とする請求項２に記載のプロキシサーバ。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002054196A JP4126928B2 (ja) | 2002-02-28 | 2002-02-28 | プロキシサーバ及びプロキシ制御プログラム |
| CA 2399914 CA2399914A1 (en) | 2002-02-28 | 2002-08-28 | Proxy server and proxy control program |
| US10/228,925 US20030182437A1 (en) | 2002-02-28 | 2002-08-28 | Proxy server and proxy control program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002054196A JP4126928B2 (ja) | 2002-02-28 | 2002-02-28 | プロキシサーバ及びプロキシ制御プログラム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007059316A Division JP4345828B2 (ja) | 2007-03-09 | 2007-03-09 | プロキシサーバ及びプロキシ制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003256321A JP2003256321A (ja) | 2003-09-12 |
| JP4126928B2 true JP4126928B2 (ja) | 2008-07-30 |
Family
ID=27800028
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002054196A Expired - Lifetime JP4126928B2 (ja) | 2002-02-28 | 2002-02-28 | プロキシサーバ及びプロキシ制御プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20030182437A1 (ja) |
| JP (1) | JP4126928B2 (ja) |
| CA (1) | CA2399914A1 (ja) |
Families Citing this family (94)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7068729B2 (en) | 2001-12-21 | 2006-06-27 | Digital Fountain, Inc. | Multi-stage code generator and decoder for communication systems |
| US6307487B1 (en) | 1998-09-23 | 2001-10-23 | Digital Fountain, Inc. | Information additive code generator and decoder for communication systems |
| US7415723B2 (en) * | 2002-06-11 | 2008-08-19 | Pandya Ashish A | Distributed network security system and a hardware processor therefor |
| WO2003104943A2 (en) * | 2002-06-11 | 2003-12-18 | Ashish A Pandya | High performance ip processor for tcp/ip, rdma and ip storage applications |
| US9240810B2 (en) | 2002-06-11 | 2016-01-19 | Digital Fountain, Inc. | Systems and processes for decoding chain reaction codes through inactivation |
| US8046471B2 (en) * | 2002-09-19 | 2011-10-25 | Hewlett-Packard Development Company, L.P. | Regressive transport message delivery system and method |
| AU2003277198A1 (en) | 2002-10-05 | 2004-05-04 | Digital Fountain, Inc. | Systematic encoding and decoding of chain reaction codes |
| US7298753B1 (en) * | 2003-02-10 | 2007-11-20 | Cisco Technology, Inc. | Technique for managing heavy signaling traffic that is directed to a particular signaling control unit |
| US8938553B2 (en) * | 2003-08-12 | 2015-01-20 | Riverbed Technology, Inc. | Cooperative proxy auto-discovery and connection interception through network address translation |
| EP2722995B1 (en) | 2003-10-06 | 2023-04-19 | QUALCOMM Incorporated | Soft-Decision Decoding of Multi-Stage Chain Reaction Codes |
| US7978716B2 (en) | 2003-11-24 | 2011-07-12 | Citrix Systems, Inc. | Systems and methods for providing a VPN solution |
| US7720983B2 (en) * | 2004-05-03 | 2010-05-18 | Microsoft Corporation | Fast startup for streaming media |
| KR101205758B1 (ko) | 2004-05-07 | 2012-12-03 | 디지털 파운튼, 인크. | 파일 다운로드 및 스트리밍 시스템 |
| US8739274B2 (en) | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
| US8495305B2 (en) | 2004-06-30 | 2013-07-23 | Citrix Systems, Inc. | Method and device for performing caching of dynamically generated objects in a data communication network |
| US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private network |
| US9219579B2 (en) | 2004-07-23 | 2015-12-22 | Citrix Systems, Inc. | Systems and methods for client-side application-aware prioritization of network communications |
| EP2264956B1 (en) | 2004-07-23 | 2017-06-14 | Citrix Systems, Inc. | Method for securing remote access to private networks |
| JP2006140841A (ja) * | 2004-11-12 | 2006-06-01 | Canon Inc | 情報処理装置、サーバ装置、ネットワークシステム、データ通信方法、及びコンピュータプログラム |
| KR100631514B1 (ko) * | 2004-12-16 | 2006-10-09 | 엘지전자 주식회사 | 실시간 스트리밍 서비스의 전송률 제어 방법 |
| US7810089B2 (en) | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
| US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
| US8700695B2 (en) | 2004-12-30 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP pooling |
| US8706877B2 (en) | 2004-12-30 | 2014-04-22 | Citrix Systems, Inc. | Systems and methods for providing client-side dynamic redirection to bypass an intermediary |
| US8549149B2 (en) | 2004-12-30 | 2013-10-01 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing |
| US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
| JP4670598B2 (ja) | 2005-11-04 | 2011-04-13 | 日本電気株式会社 | ネットワークシステム、プロキシサーバ、セッション管理方法、及びプログラム |
| JP2007172389A (ja) * | 2005-12-22 | 2007-07-05 | Fuji Xerox Co Ltd | コンテント配信装置 |
| US8301839B2 (en) | 2005-12-30 | 2012-10-30 | Citrix Systems, Inc. | System and method for performing granular invalidation of cached dynamically generated objects in a data communication network |
| US7921184B2 (en) * | 2005-12-30 | 2011-04-05 | Citrix Systems, Inc. | System and method for performing flash crowd caching of dynamically generated objects in a data communication network |
| US9136983B2 (en) | 2006-02-13 | 2015-09-15 | Digital Fountain, Inc. | Streaming and buffering using variable FEC overhead and protection periods |
| US9270414B2 (en) | 2006-02-21 | 2016-02-23 | Digital Fountain, Inc. | Multiple-field based code generator and decoder for communications systems |
| JP4925693B2 (ja) * | 2006-03-08 | 2012-05-09 | ソニー株式会社 | 情報処理システム、情報処理方法、提供装置および方法、情報処理装置、並びにプログラム |
| US7782759B2 (en) * | 2006-04-21 | 2010-08-24 | Microsoft Corporation | Enabling network devices to run multiple congestion control algorithms |
| WO2007134196A2 (en) | 2006-05-10 | 2007-11-22 | Digital Fountain, Inc. | Code generator and decoder using hybrid codes |
| US9419749B2 (en) | 2009-08-19 | 2016-08-16 | Qualcomm Incorporated | Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes |
| US9432433B2 (en) | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
| US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
| US9178535B2 (en) | 2006-06-09 | 2015-11-03 | Digital Fountain, Inc. | Dynamic stream interleaving and sub-stream based delivery |
| US9386064B2 (en) | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
| US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
| US8576875B2 (en) * | 2006-09-13 | 2013-11-05 | Emc Corporation | Systems and methods of improving performance of transport protocols in a multi-path environment |
| US9141557B2 (en) | 2006-12-08 | 2015-09-22 | Ashish A. Pandya | Dynamic random access memory (DRAM) that comprises a programmable intelligent search memory (PRISM) and a cryptography processing engine |
| US7996348B2 (en) | 2006-12-08 | 2011-08-09 | Pandya Ashish A | 100GBPS security and search architecture using programmable intelligent search memory (PRISM) that comprises one or more bit interval counters |
| JP5162907B2 (ja) * | 2007-01-16 | 2013-03-13 | 沖電気工業株式会社 | ストリーム配信システム |
| KR101434568B1 (ko) * | 2007-02-02 | 2014-08-27 | 삼성전자 주식회사 | 컨텐츠 공유 방법 및 장치 |
| TWI339522B (en) * | 2007-02-27 | 2011-03-21 | Nat Univ Tsing Hua | Generation method of remote objects with network streaming ability and system thereof |
| US8171135B2 (en) * | 2007-07-12 | 2012-05-01 | Viasat, Inc. | Accumulator for prefetch abort |
| US8549099B2 (en) * | 2007-07-12 | 2013-10-01 | Viasat, Inc. | Methods and systems for javascript parsing |
| US20100146415A1 (en) * | 2007-07-12 | 2010-06-10 | Viasat, Inc. | Dns prefetch |
| US8966053B2 (en) * | 2007-07-12 | 2015-02-24 | Viasat, Inc. | Methods and systems for performing a prefetch abort operation for network acceleration |
| US20090016222A1 (en) * | 2007-07-12 | 2009-01-15 | Viasat, Inc. | Methods and systems for implementing time-slice flow control |
| EP2203836A4 (en) | 2007-09-12 | 2014-11-05 | Digital Fountain Inc | GENERATE AND TRANSFER SOURCE IDENTIFICATION INFORMATION TO ENABLE RELIABLE COMMUNICATION |
| US20090077256A1 (en) * | 2007-09-17 | 2009-03-19 | Mbit Wireless, Inc. | Dynamic change of quality of service for enhanced multi-media streaming |
| WO2009045963A1 (en) | 2007-10-01 | 2009-04-09 | Viasat, Inc. | Methods and systems for secure data transmission between a client and a server via a proxy |
| US9460229B2 (en) | 2007-10-15 | 2016-10-04 | Viasat, Inc. | Methods and systems for implementing a cache model in a prefetching system |
| US9654328B2 (en) | 2007-10-15 | 2017-05-16 | Viasat, Inc. | Methods and systems for implementing a cache model in a prefetching system |
| US20100180005A1 (en) * | 2009-01-12 | 2010-07-15 | Viasat, Inc. | Cache cycling |
| JP4650573B2 (ja) * | 2009-01-22 | 2011-03-16 | ソニー株式会社 | 通信装置、通信システム、プログラム、および通信方法 |
| US9281847B2 (en) | 2009-02-27 | 2016-03-08 | Qualcomm Incorporated | Mobile reception of digital video broadcasting—terrestrial services |
| JP5293958B2 (ja) * | 2009-04-01 | 2013-09-18 | 日本電気株式会社 | データ処理装置、データ処理方法、及びプログラム |
| JP5673538B2 (ja) * | 2009-08-10 | 2015-02-18 | 日本電気株式会社 | 配信システム |
| US9288010B2 (en) | 2009-08-19 | 2016-03-15 | Qualcomm Incorporated | Universal file delivery methods for providing unequal error protection and bundled file delivery services |
| US9450804B2 (en) * | 2009-09-03 | 2016-09-20 | At&T Intellectual Property I, L.P. | Anycast aware transport for content distribution networks |
| US9917874B2 (en) | 2009-09-22 | 2018-03-13 | Qualcomm Incorporated | Enhanced block-request streaming using block partitioning or request controls for improved client-side handling |
| EP2312804B1 (en) * | 2009-10-13 | 2015-02-25 | BlackBerry Limited | Methods and apparatus for intelligent selection of a transport protocol for content streaming |
| US8412827B2 (en) * | 2009-12-10 | 2013-04-02 | At&T Intellectual Property I, L.P. | Apparatus and method for providing computing resources |
| WO2011139305A1 (en) | 2010-05-04 | 2011-11-10 | Azuki Systems, Inc. | Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction |
| US9049497B2 (en) | 2010-06-29 | 2015-06-02 | Qualcomm Incorporated | Signaling random access points for streaming video data |
| US8918533B2 (en) | 2010-07-13 | 2014-12-23 | Qualcomm Incorporated | Video switching for streaming video data |
| US9185439B2 (en) | 2010-07-15 | 2015-11-10 | Qualcomm Incorporated | Signaling data for multiplexing video components |
| US9596447B2 (en) | 2010-07-21 | 2017-03-14 | Qualcomm Incorporated | Providing frame packing type information for video coding |
| US9319448B2 (en) | 2010-08-10 | 2016-04-19 | Qualcomm Incorporated | Trick modes for network streaming of coded multimedia data |
| US20120096144A1 (en) * | 2010-10-18 | 2012-04-19 | Nokia Corporation | Method and apparatus for fetching data based on network conditions |
| US8958375B2 (en) | 2011-02-11 | 2015-02-17 | Qualcomm Incorporated | Framing for an improved radio link protocol including FEC |
| US9270299B2 (en) | 2011-02-11 | 2016-02-23 | Qualcomm Incorporated | Encoding and decoding using elastic codes with flexible source block mapping |
| WO2012166927A1 (en) * | 2011-06-02 | 2012-12-06 | Numerex Corp. | Wireless snmp agent gateway |
| US9253233B2 (en) | 2011-08-31 | 2016-02-02 | Qualcomm Incorporated | Switch signaling methods providing improved switching between representations for adaptive HTTP streaming |
| US9843844B2 (en) | 2011-10-05 | 2017-12-12 | Qualcomm Incorporated | Network streaming of media data |
| US9294226B2 (en) | 2012-03-26 | 2016-03-22 | Qualcomm Incorporated | Universal object delivery and template-based file delivery |
| US9413801B2 (en) * | 2012-06-28 | 2016-08-09 | Adobe Systems Incorporated | Media stream index merging |
| US8930632B2 (en) * | 2012-11-14 | 2015-01-06 | Ebay Inc. | Methods and systems for application controlled pre-fetch |
| US9654527B1 (en) | 2012-12-21 | 2017-05-16 | Juniper Networks, Inc. | Failure detection manager |
| US9154535B1 (en) * | 2013-03-08 | 2015-10-06 | Scott C. Harris | Content delivery system with customizable content |
| US10491694B2 (en) | 2013-03-15 | 2019-11-26 | Oath Inc. | Method and system for measuring user engagement using click/skip in content stream using a probability model |
| US8898784B1 (en) * | 2013-05-29 | 2014-11-25 | The United States of America, as represented by the Director, National Security Agency | Device for and method of computer intrusion anticipation, detection, and remediation |
| JP2015001784A (ja) * | 2013-06-13 | 2015-01-05 | 富士通株式会社 | 情報処理システム、情報処理装置、及び情報処理プログラム |
| CN105763474B (zh) * | 2014-12-19 | 2019-10-25 | 华为技术有限公司 | 数据传输方法和装置 |
| CN105072174B (zh) * | 2015-08-03 | 2018-08-28 | 杭州智诚惠通科技有限公司 | 一种基于云服务的多级联合治超方法 |
| CN106559404A (zh) * | 2015-09-30 | 2017-04-05 | 北京奇虎科技有限公司 | 一种访问数据的客户端、代理服务器及系统 |
| US10218811B1 (en) | 2016-06-29 | 2019-02-26 | Oath (Ameericas) Inc. | Systems and methods for utilizing unused network capacity for prefetch requests |
| CN113271259B (zh) * | 2017-10-30 | 2023-08-29 | 创新先进技术有限公司 | 流量控制系统、方法、装置及设备 |
| WO2021063594A1 (en) * | 2019-09-30 | 2021-04-08 | British Telecommunications Public Limited Company | Content delivery – setting the unicast rate |
| JP7460569B2 (ja) * | 2021-03-05 | 2024-04-02 | Kddi株式会社 | コンテンツ配信ネットワークの転送装置及びプログラム |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5163046A (en) * | 1989-11-30 | 1992-11-10 | At&T Bell Laboratories | Dynamic window sizing in a data network |
| US5881245A (en) * | 1996-09-10 | 1999-03-09 | Digital Video Systems, Inc. | Method and apparatus for transmitting MPEG data at an adaptive data rate |
| US5999979A (en) * | 1997-01-30 | 1999-12-07 | Microsoft Corporation | Method and apparatus for determining a most advantageous protocol for use in a computer network |
| US6237031B1 (en) * | 1997-03-25 | 2001-05-22 | Intel Corporation | System for dynamically controlling a network proxy |
| US6272492B1 (en) * | 1997-11-21 | 2001-08-07 | Ibm Corporation | Front-end proxy for transparently increasing web server functionality |
| US6308214B1 (en) * | 1998-09-23 | 2001-10-23 | Inktomi Corporation | Self-tuning dataflow I/O core |
| US6484212B1 (en) * | 1999-04-20 | 2002-11-19 | At&T Corp. | Proxy apparatus and method for streaming media information |
| US6463508B1 (en) * | 1999-07-19 | 2002-10-08 | International Business Machines Corporation | Method and apparatus for caching a media stream |
| US7028096B1 (en) * | 1999-09-14 | 2006-04-11 | Streaming21, Inc. | Method and apparatus for caching for streaming data |
-
2002
- 2002-02-28 JP JP2002054196A patent/JP4126928B2/ja not_active Expired - Lifetime
- 2002-08-28 CA CA 2399914 patent/CA2399914A1/en not_active Abandoned
- 2002-08-28 US US10/228,925 patent/US20030182437A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CA2399914A1 (en) | 2003-08-28 |
| US20030182437A1 (en) | 2003-09-25 |
| JP2003256321A (ja) | 2003-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4126928B2 (ja) | プロキシサーバ及びプロキシ制御プログラム | |
| US8812673B2 (en) | Content rate control for streaming media servers | |
| US9419907B2 (en) | I/O driven rate adaptation | |
| US7284047B2 (en) | System and method for controlling network demand via congestion pricing | |
| Agarwal et al. | Adaptive multisource streaming in heterogeneous peer-to-peer networks | |
| KR101099800B1 (ko) | 미디어 서버로의 피드백 제공 방법 | |
| US8190750B2 (en) | Content rate selection for media servers with proxy-feedback-controlled frame transmission | |
| EP2665239B1 (en) | An adaptive streaming aware networks node, client and method with priority marking | |
| JP4681044B2 (ja) | データパケットの送信を動的に制御する技術 | |
| JP4345828B2 (ja) | プロキシサーバ及びプロキシ制御プログラム | |
| CN102138301A (zh) | 合理使用管理方法和系统 | |
| US7684336B2 (en) | Real-time video packet monitoring and processing for enhanced quality of service | |
| EP2388978B1 (en) | Methods and devices for determining network link load | |
| JP2009163440A (ja) | 負荷分散方法、負荷分散システム、負荷分散サーバ及び負荷分散プログラム | |
| JP7222748B2 (ja) | 受信装置及び配信サーバ | |
| Feng | On the efficacy of quality, frame rate, and buffer management for video streaming across best‐effort networks | |
| Sun et al. | Predictive flow control for TCP-friendly end-to-end real-time video on the Internet | |
| Zhang et al. | Congestion Control Optimization for Short Video Services: User-End and Edge Server Collaboration in Practice | |
| Ehtiba et al. | Media Playout Techniques for Video Intra-Stream Synchronization: Review and Analysis | |
| JP2022122064A (ja) | 配信サーバ、配信システム及び配信プログラム | |
| Qian et al. | Measurement and performance study of pert for on-demand video streaming | |
| Abd et al. | Supporting real-time video in SCTP networks | |
| HK1166155A (en) | Method and system for i/o driven rate adaptation | |
| HK1166155B (en) | Method and system for i/o driven rate adaptation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060223 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060424 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070208 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070309 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20070309 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20070309 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070423 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080129 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080331 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080422 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080505 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4126928 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110523 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120523 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130523 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140523 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |