JP2003256321A - プロキシサーバ及びプロキシ制御プログラム - Google Patents

プロキシサーバ及びプロキシ制御プログラム

Info

Publication number
JP2003256321A
JP2003256321A JP2002054196A JP2002054196A JP2003256321A JP 2003256321 A JP2003256321 A JP 2003256321A JP 2002054196 A JP2002054196 A JP 2002054196A JP 2002054196 A JP2002054196 A JP 2002054196A JP 2003256321 A JP2003256321 A JP 2003256321A
Authority
JP
Japan
Prior art keywords
content
acquisition
buffer
rate
client
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.)
Granted
Application number
JP2002054196A
Other languages
English (en)
Other versions
JP4126928B2 (ja
Inventor
Masayoshi Kobayashi
正好 小林
Toshiyasu Kurasugi
俊康 蔵杉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2002054196A priority Critical patent/JP4126928B2/ja
Priority to US10/228,925 priority patent/US20030182437A1/en
Priority to CA 2399914 priority patent/CA2399914A1/en
Publication of JP2003256321A publication Critical patent/JP2003256321A/ja
Application granted granted Critical
Publication of JP4126928B2 publication Critical patent/JP4126928B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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/1066—Session management
    • H04L65/1101—Session protocols
    • 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

Abstract

(57)【要約】 （修正有） 【課題】 ストリームプロキシサーバにおいて、オリジ
ンサーバからのコンテンツの取得をネットワークを流れ
る他のトラヒックへの影響を抑え実現する。 【解決手段】 本発明のストリームプロキシサーバは、
ネットワーク情報収集手段と、フロー制御機能を持ち、
異なる帯域共有特性を持った複数のトランスポート層プ
ロトコルを用いたデータ送受信が出来るトランスポート
層プロトコル制御手段と、トランスポート層プロトコル
制御手段から決められたレートでデータを読み出す受信
レート制御手段と、ネットワーク情報収集手段から得ら
れる情報とバッファ余裕に基づいて、オリジンサーバか
らのコンテンツの取得レートと使用するトランスポート
層プロトコルを決定して受信レート制御手段へ決定した
レートを通知し、トランスポート層プロトコル制御手段
へ使用するトランスポート層プロトコルを通知する、先
読み制御手段とを持つ。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、コンテンツの一部
または全部を記憶装置に溜め、そこからクライアントに
コンテンツをストリーム配信しながら、該コンテンツの
保持していないコンテンツ断片をオリジンサーバから取
得して記憶装置に追加するストリームプロキシサーバに
関し、特にネットワークを流れる他のトラヒックへの影
響を抑えてオリジンサーバからのコンテンツの取得を実
現するストリームプロキシサーバおよびネットワーク技
術に関する。
【従来の技術】図３４に従来のストリームプロキシサー
バを用いたネットワークの構成図を示す。従来のストリ
ームプロキシサーバ200は、クライアント100-1〜100-n
のn台のクライアントに対して、m台のオリジンサーバ40
0-1〜400-mの保持するコンテンツについてn本のストリ
ームプロキシサービスを行っているものとする。またプ
ロキシサーバと、オリジンサーバ400-1〜400-mへはルー
タ300、リンク700、ネットワーク500を経由して接続さ
れているとする。リンク700には、ネットワーク500と60
0の間のトラヒックも流れている。
【０００２】ストリーム配信とは、クライアント100-1
〜100-nから要求のあったコンテンツについて、クライ
アントから要求されたコンテンツ内の位置から、要求さ
れた速度（配信レート）でコンテンツをクライアントに
送信する事である。ストリーミングによって、クライア
ント100-1〜100-nは、受け取ったコンテンツの部分から
順にコンテンツを再生（あるいは利用）する事によっ
て、コンテンツ全体を受け取るまで待つ必要がなくな
り、再生を開始するまでの時間が短縮出来る。
【０００３】ストリームプロキシサービスとは、ネット
ワーク内の要素C（例えば、クライアント100-1〜100-
n）からの視聴リクエストを受け取り、視聴リクエスト
のあったコンテンツについて、ストリームプロキシサー
バ200が保持している部分については、ストリームプロ
キシサーバ200自身から、保持していない部分について
は、コンテンツを保持しているネットワーク内の要素S
（例えば、オリジンサーバ400-1〜400-m）から取得し
て、ネットワーク内の要素C（例えば、クライアント100
-1〜100-n）に対して、コンテンツをストリーム配信す
るサービスである。ネットワーク内の要素S(例えば、オ
リジンサーバ）から取得したコンテンツについては、ス
トリームプロキシサーバ200は一部または全部を記憶装
置に保存しておく。次回同じコンテンツへ、ネットワー
ク内の要素C（例えば、クライアント100-1〜100-n）か
らの視聴リクエストがあった場合に、保存した部分につ
いてはネットワーク内の要素S(例えば、オリジンサー
バ）から取得する事をせず、自身の記憶装置から読み出
して要素C（例えば、クライアント）にストリーミング
でコンテンツ配信する。ネットワーク内の要素Cとし
て、ストリーミング配信を行うオリジンサーバをとり、
ネットワーク内の要素Sとして、ディスク装置をとる事
も可能である。
【０００４】図３５に、従来のストリームプロキシサー
バ200の内部構成図を示す。各構成要素を説明する。
【０００５】ストリーム配信制御部201は、クライアン
トからのコンテンツの視聴リクエストを受け取り、視聴
要求のあったコンテンツを記憶部204から読み出してク
ライアントへとストリーム配信する機能を持つ。また、
視聴リクエストを、先読み制御部202へと伝える機能も
持つ。
【０００６】先読み制御部202は、ストリーム配信制御
部201から、視聴リクエストを受け取り、クライアント
から視聴リクエストがあったコンテンツに関して、記憶
部204に保持していないコンテンツ断片（コンテンツの
全部又は一部分）がある場合には、オリジンサーバとの
コネクションをトランスポート層制御部205へ指示して
開設する。また、コンテンツ取得要求（コンテンツの識
別子、取得すべき各コンテンツ断片の開始位置と終わり
の位置から成る）を、前記の開設したコネクション上に
送信する（トランスポート層制御部が提供する、書き込
みのインターフェースを使う）。サーバは、同コネクシ
ョンに、該当コンテンツ断片を送り返してくるので、先
読み制御部202はこれを同コネクションから読み出して
（トランスポート層制御部が提供する、読み出しのイン
ターフェースを使う）、記憶部204へと書き込む。コン
テンツ断片は記憶装置の容量が許す限り書き込まれる
が、容量がなくなった場合、コンテンツの中ですでに配
信が終わっている部分を削除し、書き込む容量を確保す
る。
【０００７】記憶部204は、オリジンサーバのコンテン
ツの一部または全部のコピーを保存している。ストリー
ムの任意の位置への書き込みと、任意の位置からの読み
出しのインターフェース、および、各コンテンツについ
て保持している位置情報を、ストリーム配信制御部、先
読み制御部へ提供する。
【０００８】トランスポート層制御部205は、トランス
ポート層プロトコル（例えばTCP)を使ったデータ通信を
制御する部分である。先読み制御部202からの指示に従
って、オリジンサーバとのコネクションの開設、切断、
およびデータ送受信に必要なトランスポート層の終端処
理（例えばトランスポート層がTCPならTCPの送受信のプ
ロトコル処理）を行う。また、開設した各コネクション
について、先読み制御部からのデータの読み出し、書き
込みのインターフェースを持つ。
【０００９】次に、従来のストリームプロキシサーバの
動作の概要を説明する。クライアントが送信する視聴リ
クエストには、視聴初期化（コンテンツ識別子が指定さ
れる）、視聴開始(コンテンツ内での位置が指定され
る、例えば再生時間での先頭から何秒目などを指定す
る）、視聴停止、視聴終了、が含まれる。視聴の際、ク
ライアントは、まず「視聴初期化」の視聴リクエストを
ストリームプロキシサーバに送信し、ストリームプロキ
シサーバと、クライアントとの間に、リクエスト内のコ
ンテンツ識別子で指定されたコンテンツの配信サービス
のためのコネクションを開設する。ストリームプロキシ
サーバは、その後、「視聴開始」（任意の開始位置と配
信レートが指定出来る）や、「視聴停止」（一時停
止）、の視聴リクエストを使ってコンテンツ視聴を行
い、視聴を終えると、「視聴終了」の視聴リクエストで
ストリームプロキシサーバに視聴を終える旨を通知す
る。
【００１０】図３６に、前記の視聴リクエストを利用し
た典型的なコンテンツ視聴のタイミングチャートを示
す。図３６の例では、クライアントはコンテンツの最初
から視聴開始し、最後まで見終わってから視聴終了する
とする。また、リクエストされたコンテンツの先頭部分
(0秒〜Ta秒）、コンテンツの途中部分(Tb秒〜Tc秒）を
ストリームプロキシサーバが保持しているとする。
【００１１】図３７にこの例でのストリームプロキシサ
ーバが保持しているコンテンツの位置を示す。現在クラ
イアントに対して送信を行っている位置（配信位置）か
ら、それ以降のコンテンツ部分で最初に記憶部に保持し
ていないコンテンツの位置を送信するまでの時間的な差
を、視聴の（あるいは、クライアントをターゲットとす
る）ストリームバッファ余裕（あるいはバッファ余裕）
と呼ぶ。例えば、あるコンテンツについて、記憶部に保
持されている部分が、図３７のような場合で、現在の配
信位置がT1ならストリームバッファ余裕はTa−T1秒、現
在の視聴位置がT2なら、ストリームバッファ余裕は0秒
である。
【００１２】図３６には、ストリームプロキシサーバ
が、リクエストされたコンテンツの保持している以外の
部分（Ta〜Tb秒、および、Tc〜Td秒）をオリジンサーバ
から取得しながら、クライアントへとストリーミングで
コンテンツ配信している様子を示している。以下、この
動作を説明する。図３６のXT-10において、クライアン
トが、「視聴初期化」のリクエストをプロキシサーバに
送り、ストリーム配信のためのコネクションが、クライ
アントとストリームプロキシサーバとの間に開設され
る。次に、XT-20において、クライアントは「視聴開
始」（位置は先頭(0秒)からとする。配信レート(Kbps
等)も指定される）の視聴リクエストを送ってくるの
で、コンテンツスイッチは、記憶部に保持している該当
コンテンツの指定された位置(0秒)から、ストリーム配
信を開始する(XT-30)。また、オリジンサーバへ、コン
テンツの保持している以外の部分を取得するために、コ
ネクションを開設し(XT-40)、取得要求を出す(XT-50)。
そしてサーバから後続のコンテンツ部分を取得し始める
（XT-60)。取得は記憶部の容量が許す限り行われ、取得
した部分は記憶部にためられてゆく。要求を出した取得
が完了すると(XT-65)、現在の配信位置以降で保持して
いない部分があれば、さらに取得要求を出す(XT-70)。
ストリームプロキシサーバは、オリジンサーバから、コ
ンテンツを取得しながら(XT-63およびXT-73)、記憶装置
に保持しているコンテンツ読み込んで、クライアントへ
とストリーム配信してゆく。このとき、コンテンツがま
だ取得出来ていない場合（ストリームバッファ余裕が0
秒になった場合）には、取得出来るまでの間（ストリー
ムバッファ余裕が正の値になるまで）、配信は一時的に
中断され、クライアントには視聴が不連続に飛ぶ（映像
がとぎれる、あるいは、音がとぎれるなど）、視聴品質
が低下する。クライアントは全コンテンツを取得し終え
ると、「視聴終了」の視聴リクエストを送り(XT-110)、
ストリームプロキシサーバは、それを受けて、サーバと
のコネクションを切断する(XT-120)。
【００１３】次に、図３６のタイミングチャートの中
で、ストリーム配信制御部201、先読み制御部202、記憶
部204、トランスポート層制御部205がどのように動作す
るのかを説明する。ストリーム配信制御部201は、クラ
イアントからの視聴リクエストを受け取ると、それが
「視聴終了」の場合、ストリーム配信を停止し、先読み
制御部に該当コンテンツの識別子と視聴終了であること
を通知する。「視聴初期化」の場合、記憶部204の該当
コンテンツを検索し、記憶部内のアドレスを得る。みつ
からない場合、先読み制御部202へ指示して、記憶部204
に記憶領域を確保させ、記憶部内のアドレスを通知して
もらう。また、先読み制御部202に「視聴初期化」であ
る事と、コンテンツの識別子を通知する。「視聴開始」
の場合、指定された視聴開始位置が、記憶部内にある場
合には、配信の先頭を指定された位置に調整する動作を
行う。また、先読み制御部に、「視聴開始」である事を
通知する。その後、記憶部からコンテンツを読み出して
ストリーム配信を行う。オリジンサーバからの取得が間
に合わず、記憶部に読み出したいコンテンツの部分がな
い場合(バッファ余裕が0秒になった場合）には、その部
分のコンテンツは配信されず、クライアントには、視聴
が不連続に飛んだ（映像がとぎれる、あるいは、音がと
ぎれるなど）ようにみえる。また、ストリーム配信制御
部201は、先読み制御部202からのリクエストに応じて、
現在の視聴位置、現在のコンテンツ配信レートを返す事
も行う。
【００１４】先読み制御部202では、ストリーム配信制
御部から「視聴終了」の通知を受け取ると、該当のコン
テンツに関してオリジンサーバとのコネクションを切断
する。「視聴初期化」の場合には、該当コンテンツにつ
いて、トランスポート層制御部205へ指示して、オリジ
ンサーバへとコネクションを張る処理を行う。また、
「視聴初期化」の場合に、該当コンテンツが記憶部にな
い場合に記憶領域を確保してそのアドレスをストリーム
配信制御部へと通知する。「視聴開始」の場合、視聴開
始位置以降のコンテンツについて、記憶部内にない部分
を、トランスポート層制御部を介してオリジンサーバか
ら取得して、記憶部の容量が許す限り記憶部へ書き込
む。記憶部の容量がなくなった場合、コンテンツの中で
すでに配信が終わっている部分などを削除して容量を空
ける動作を行う。
【００１５】
【本発明が解決しようとする課題】従来のストリームプ
ロキシサーバでは、クライアントの視聴が始まると、保
持していないコンテンツ部分をオリジンサーバから取得
するが、現在の配信位置以降の部分の取得（以下、「先
読み」と呼ぶ）については、実際にクライアントに配信
を行うのは、配信位置がそこに達した時であり、取得の
緊急度は低い。これに対して、一般にネットワークを流
れるトラヒックには緊急度の高いものが含まれており、
先読みは、これらのトラヒックより優先度を低くすべき
である。例えば、図２７ではリンク700は、ネットワー
ク500と600の間の通信にも使われているが、従来のスト
リームプロキシサーバは、このリンク700の輻輳度を考
慮していないため、ネットワーク500と600の間の通信に
よってこのリンクが輻輳している時に、先読みによって
発生するトラヒックで、このリンク700をさらに輻輳さ
せてしまう。
【００１６】また、従来のストリームプロキシサーバで
は、オリジンサーバからのコンテンツ取得レートを制御
しておらず、トランスポート層プロトコルが達成するデ
ータ送信レートがコンテンツ取得レートとなっている。
このため、同一ボトルネックを経由してオリジンサーバ
からの取得を行っている複数のコンテンツがある場合
に、一時的にボトルネックが輻輳し、ボトルネックの空
き帯域が、配信レートの合計を下回るような場合に、ス
トリームバッファ余裕の少ないものに対して、優先して
オリジンサーバからのコンテンツ取得帯域を割り当てる
ことが出来ず、ストリームバッファ余裕が0に達して視
聴品質が悪化してしまう視聴が発生する確率が高い。
【００１７】例えば、同じ配信レートの2つのコンテン
ツ視聴に対して、ストリームプロキシサービスを行って
いる状況で、それぞれの視聴に対して、オリジンサーバ
から同一のボトルネックを経由して先読みを行っている
とする。このとき、一時的にボトルネックが輻輳し、コ
ンテンツ取得に使えるボトルネックの空き帯域が1つの
配信レート分の空き帯域しかない状況になったとする。
また、このとき2つの視聴の、バッファ余裕が1秒と100
秒だったとする。従来のストリームプロキシサーバで
は、空き帯域を2つの先読みによって均等に配分するた
め、各コンテンツ取得は、配信レートの半分のレートで
オリジンサーバからの取得を行う事になる。このため、
2秒後に片方の視聴のストリームバッファ余裕が0とな
り、その視聴の視聴品質が悪化してしまう。もし、100
秒のストリームバッファ余裕がある視聴について、オリ
ジンサーバからの取得を一時的に停止し、1秒のストリ
ームバッファ余裕の視聴について、オリジンサーバから
の取得帯域を割り当てれば、いずれかの視聴のストリー
ムバッファ余裕が0になるまでの時間を延ばすことが出
来、それまでの間に一時的な輻輳が解消すれば、クライ
アントの視聴品質の悪化をなくすことが可能であるが、
従来のストリームプロキシサーバではこれは出来ない。
【００１８】また、バッファ余裕以外の要因（視聴して
いるクライアントやコンテンツなど）に依存して、取得
レートを決定する事を行う事が出来ない。このため、特
定のクライアントやコンテンツについての取得レートを
より高く設定して、そのクライアントやコンテンツの視
聴品質の悪化を防ぐという事が出来ない。
【００１９】本発明の第１の目的は、ネットワークを流
れる他のトラヒックへの影響を極力抑えてオリジンサー
バからのコンテンツの取得を実現することができるプロ
キシサーバ、プロキシ制御プログラムを提供することに
ある。
【００２０】本発明の第２の目的は、オリジンサーバか
らのコンテンツ取得レートを制御し、同一のボトルネッ
クを共有するコンテンツの間で帯域の割り当て制御を行
うことにより、視聴品質の悪化が起こる可能性を極力抑
えることを可能としたプロキシサーバ、プロキシ制御プ
ログラムを提供することにある。
【００２１】本発明の第３の目的は、オリジンサーバか
らのコンテンツ取得レートを制御することにより、優先
度の高い視聴に関して視聴品質の悪化が起こる可能性を
最小限に抑えることを可能とするプロキシサーバ、プロ
キシ制御プログラムを提供することにある。
【００２２】
【課題を解決するための手段】本発明のプロキシサーバ
は、コンテンツの一部または全部を記憶装置に格納し、
当該記憶装置からクライアントにコンテンツを配信しな
がら、該コンテンツの保持していない部分をオリジンサ
ーバから取得して前記記憶装置に追加するプロキシサー
バにおいて、前記オリジンサーバからのコンテンツの取
得レートを、ネットワーク状況又は前記コンテンツの受
信バッファの状態の少なくとも一方に応じて制御するこ
とを特徴とする。
【００２３】請求項２の本発明のプロキシサーバは、コ
ンテンツの一部または全部を記憶装置に格納し、当該記
憶装置からクライアントにコンテンツを配信しながら、
該コンテンツの保持していない部分をオリジンサーバか
ら取得して前記記憶装置に追加するプロキシサーバにお
いて、前記オリジンサーバからのコンテンツの取得に用
いるプロトコルを、異なる帯域共有特性を持つ複数のプ
ロトコルの中から、ネットワーク状況又は前記コンテン
ツの受信バッファの状態の少なくとも一方に基づいて選
択することを特徴とする。
【００２４】請求項３の本発明のプロキシサーバは、前
記オリジンサーバからのコンテンツの取得を、フロー制
御の機能を備えるプロトコルを用いて行い、前記オリジ
ンサーバからのコンテンツ取得レートの制御を、前記プ
ロトコルの受信バッファからコンテンツを読み出すレー
トを制御することにより実現することを特徴とする。
【００２５】請求項４の本発明のプロキシサーバは、前
記オリジンサーバからのコンテンツの取得に用いるプロ
トコルを、フロー制御の機能を備える帯域共有特性の異
なる複数の種類のプロトコルの中から、ネットワーク状
況又は前記コンテンツの受信バッファの状態の少なくと
も一方に基づいて選択し、前記オリジンサーバからのコ
ンテンツ取得レートの制御を、前記プロトコルの受信バ
ッファからコンテンツを読み出すレートを制御すること
により実現することを特徴とする。
【００２６】請求項５の本発明のプロキシサーバは、前
記オリジンサーバからのコンテンツの取得レートの制御
を、前記オリジンサーバに送信レートを指示することに
よって実現することを特徴とする。
【００２７】請求項６の本発明のプロキシサーバは、前
記オリジンサーバからのコンテンツの取得を、帯域共有
特性の異なる複数の種類のプロトコルの中から、ネット
ワーク状況又は前記コンテンツの受信バッファの状態の
少なくとも一方に基づいて選択し、前記オリジンサーバ
からのコンテンツの取得レートの制御を、前記オリジン
サーバに送信レートを指示することにより実現すること
を特徴とする。
【００２８】請求項７の本発明のプロキシサーバは、前
記オリジンサーバからのコンテンツ取得レートを、前記
コンテンツ又はクライアントに対して設定された優先度
も考慮して決定することを特徴とする。
【００２９】請求項８の本発明のプロキシサーバは、コ
ンテンツの一部をバッファに蓄積し、前記バッファから
クライアントにコンテンツを配信しながら、該コンテン
ツの現在のバッファへの蓄積位置より後続のコンテンツ
部分をオリジンサーバから取得してバッファに追加する
プロキシサーバにおいて、前記バッファに蓄積されてい
るコンテンツの残り時間を検出し、前記残り時間が閾値
以下になったタイミングで、該コンテンツの現在のバッ
ファ蓄積位置より後続の前記コンテンツ部分を前記オリ
ジンサーバから取得することを特徴とする
【００３０】請求項９の本発明のプロキシサーバは、前
記後続のコンテンツ部分の取得の間に優先度を設け、前
記優先度の低い取得を中止することでボトルネックリン
クの帯域使用幅が基準値を上回らないように調整するこ
とを特徴とする。
【００３１】請求項１０の本発明のプロキシサーバは、
前記優先度を、前記クライアントによるコンテンツの視
聴位置と前記バッファの蓄積位置の差に基づいて設定す
ることを特徴とする。
【００３２】請求項１１の本発明のプロキシサーバは、
前記優先度を、前記コンテンツが蓄積されているオリジ
ンサーバ、コンテンツを配信するクライアント、取得を
行うコンテンツの少なくとも何れか毎に設定することを
特徴とする。
【００３３】請求項１２の本発明のプロキシサーバは、
コンテンツの一部をバッファに蓄積し、該バッファから
クライアントにコンテンツを配信しながら、該コンテン
ツの現在のバッファ蓄積位置より後続のコンテンツ部分
をオリジンサーバから取得してバッファに追加するプロ
キシサーバにおいて、前記バッファに蓄積されているコ
ンテンツの残り時間が指定された時刻に閾値以下になる
ことを予測することにより、該コンテンツの現在のバッ
ファ蓄積位置より後続のコンテンツ部分をオリジンサー
バから取得することを特徴とする。
【００３４】請求項１３の本発明のプロキシサーバは、
通信速度の異なる複数のデータ送受信手段を使い分ける
ことにより、指定された時刻にバッファに蓄積されてい
るコンテンツの残り時間が指定された値を上回るように
該コンテンツの現在のバッファ蓄積位置より後続のコン
テンツ部分をオリジンサーバから取得することを特徴と
する。
【００３５】請求項１４の本発明のプロキシサーバは、
通信速度の異なる複数のデータ送受信手段として優先制
御を備えるプロトコルを利用すること特徴とする。
【００３６】請求項１５の本発明のプロキシサーバは、
通信速度の異なる複数のデータの送受信手段として異な
るトランスポート層プロトコルを使い分けることを特徴
とする。
【００３７】請求項１６の本発明のプロキシサーバは、
該コンテンツの現在のバッファ蓄積位置より後続のコン
テンツ部分を前記オリジンサーバから取得するタイミン
グを決定する閾値を、前記オリジンサーバとの間のネッ
トワークの輻輳状況の変化に合わせて動的に更新するこ
とを特徴とする。
【００３８】請求項１７の本発明のプロキシサーバは、
コンテンツの一部または全部を記憶装置に格納し、該記
憶装置からクライアントにコンテンツを配信しながら、
該コンテンツの保持していない部分をオリジンサーバか
ら取得して記憶装置に追加するプロキシサーバにおい
て、前記オリジンサーバからのコンテンツの取得に用い
る送信レート制御機能を持つプロトコルを、異なる帯域
共有特性を持つ複数のプロトコルの中から、ネットワー
ク状況と受信バッファの状態の少なくとも一方に応じて
選択することを特徴とする。
【００３９】請求項１８の本発明のプロキシサーバは、
前記オリジンサーバからのコンテンツの取得を、フロー
制御と送信レート制御機能を備えるプロトコルを用いて
行い、前記オリジンサーバからのコンテンツ取得レート
の制御を、前記フロー制御と送信レート制御機能を備え
るプロトコルの受信バッファからコンテンツを読み出す
レートを制御することにより実現することを特徴とす
る。
【００４０】請求項１９の本発明のプロキシサーバは、
前記オリジンサーバからのコンテンツの取得に用いる送
信レート制御機能を備えるプロトコルを、フロー制御の
機能を持つ帯域共有特性の異なる複数の種類のプロトコ
ルの中から、ネットワーク状況と受信バッファの状態の
少なくとも一方に基づいて選択し、前記オリジンサーバ
からのコンテンツ取得レートの制御を、送信制御機能を
備えるプロトコルの受信バッファからコンテンツを読み
出すレートを制御することで実現することを特徴とす
る。
【００４１】請求項２０の本発明のプロキシサーバは、
前記オリジンサーバからのコンテンツの取得を、帯域共
有特性の異なる複数の種類の送信レート制御機能を備え
るプロトコルの中から、ネットワーク状況と受信バッフ
ァの状態の少なくとも一方に基づいて選択し、前記オリ
ジンサーバからのコンテンツの取得レートの制御を、前
記オリジンサーバに送信レートを指示することで実現す
ることを特徴とする。
【００４２】請求項２１の本発明のプロキシサーバは、
前記受信バッファの状態は、目標として設定したバッフ
ァ余裕と現在のバッファ余裕との差を用いることを特徴
とする。
【００４３】請求項２２の本発明のプロキシサーバは、
前記目標として設定されるバッファ余裕は、ネットワー
クの状況に応じて変化させることを特徴とする。
【００４４】請求項２３の本発明のプロキシサーバは、
同一配信対象であるコンテンツのための先読みを複数同
時に実行することを特徴とする。
【００４５】請求項２４の本発明のプロキシサーバは、
同一配信対象であるコンテンツのための先読みにおい
て、それぞれ異なる部分の複数の要求として先読みを同
時に実行することを特徴とする。
【００４６】請求項２５の本発明のプロキシサーバは、
ネットワークの輻輳を招かない範囲で同一配信対象であ
るコンテンツのための先読みを複数同時に実行すること
を特徴とする。
【００４７】請求項２６の本発明のプロキシサーバは、
ネットワークの輻輳を招かない範囲で同一配信対象のた
めの先読みにおいて、それぞれ異なる部分の複数の要求
として同時に実行することを特徴とする。
【００４８】請求項２７の本発明のプロキシ制御プログ
ラムは、コンピュータ上で実行され、コンテンツの一部
または全部を記憶装置に格納し、当該記憶装置からクラ
イアントにコンテンツを配信しながら、該コンテンツの
保持していない部分をオリジンサーバから取得して前記
記憶装置に追加するプロキシ制御プログラムにおいて、
前記オリジンサーバからのコンテンツの取得レートを、
ネットワーク状況又は前記コンテンツの受信バッファの
状態の少なくとも一方に応じて制御する機能を有するこ
とを特徴とする。
【００４９】請求項２８の本発明のプロキシ制御プログ
ラムは、コンピュータ上で実行され、コンテンツの一部
または全部を記憶装置に格納し、当該記憶装置からクラ
イアントにコンテンツを配信しながら、該コンテンツの
保持していない部分をオリジンサーバから取得して前記
記憶装置に追加するプロキシ制御プログラムにおいて、
前記オリジンサーバからのコンテンツの取得に用いるプ
ロトコルを、異なる帯域共有特性を持つ複数のプロトコ
ルの中から、ネットワーク状況又は前記コンテンツの受
信バッファの状態の少なくとも一方に基づいて選択する
機能を有することを特徴とする。
【００５０】請求項２９の本発明のプロキシ制御プログ
ラムは、コンピュータ上で実行され、コンテンツの一部
をバッファに蓄積し、前記バッファからクライアントに
コンテンツを配信しながら、該コンテンツの現在のバッ
ファへの蓄積位置より後続のコンテンツ部分をオリジン
サーバから取得してバッファに追加するプロキシ制御プ
ログラムにおいて、前記バッファに蓄積されているコン
テンツの残り時間を検出し、前記残り時間が閾値以下に
なったタイミングで、該コンテンツの現在のバッファ蓄
積位置より後続の前記コンテンツ部分を前記オリジンサ
ーバから取得する機能を有することを特徴とする。
【００５１】請求項３０の本発明のプロキシ制御プログ
ラムは、コンピュータ上で実行され、コンテンツの一部
をバッファに蓄積し、該バッファからクライアントにコ
ンテンツを配信しながら、該コンテンツの現在のバッフ
ァ蓄積位置より後続のコンテンツ部分をオリジンサーバ
から取得してバッファに追加するプロキシ制御プログラ
ムにおいて、前記バッファに蓄積されているコンテンツ
の残り時間が指定された時刻に閾値以下になることを予
測することにより、該コンテンツの現在のバッファ蓄積
位置より後続のコンテンツ部分をオリジンサーバから取
得する機能を有することを特徴とする。
【００５２】請求項３１の本発明のプロキシ制御プログ
ラムは、コンピュータ上で実行され、コンテンツの一部
または全部を記憶装置に格納し、該記憶装置からクライ
アントにコンテンツを配信しながら、該コンテンツの保
持していない部分をオリジンサーバから取得して記憶装
置に追加するプロキシ制御プログラムにおいて、前記オ
リジンサーバからのコンテンツの取得に用いる送信レー
ト制御機能を持つプロトコルを、異なる帯域共有特性を
持つ複数のプロトコルの中から、ネットワーク状況と受
信バッファの状態の少なくとも一方に応じて選択する機
能を有することを特徴とする。
【００５３】
【作用】ネットワーク情報収集手段によって、ネットワ
ークの残余帯域の情報を収集し、取得レート決定手段に
おいて、この残余帯域に基づいて、オリジンサーバから
の取得レートを決定し、受信レート制御手段や、オリジ
ンサーバへコンテンツの送信レートを指示する手段を用
いて、決定した取得レートでのコンテンツ取得を行う事
によって、本発明の第１の目的である、オリジンサーバ
からのコンテンツの取得をネットワークを流れる他のト
ラヒックへの影響を抑えて実現する事が可能となる。
【００５４】また、ネットワークがトランスポート層プ
ロトコル決定手段によって、複数の異なる帯域共有特性
を持つトランスポート層プロトコルから、ネットワーク
を流れる他のトラヒックへの影響の小さいトランスポー
ト層プロトコルを決定し、複数の異なる帯域共有特性を
持つトランスポート層プロトコルを用いたデータ送受信
が出来るトランスポート層プロトコル制御手段を用い
て、コンテンツ取得を行う事によって、本発明の第１の
目的である、オリジンサーバからのコンテンツの取得を
ネットワークを流れる他のトラヒックへの影響を抑えて
実現する事が可能となる。
【００５５】また、バッファ余裕測定手段によって、各
コンテンツのバッファ余裕の大きさを求め、それに基づ
いて、オリジンサーバからの取得レートを決定し、受信
レート制御手段や、オリジンサーバへコンテンツの送信
レートを指示する手段を用いて、決定した取得レートで
のコンテンツ取得を行う事によって、本発明の第２の目
的である、ストリームプロキシサーバにおいて、オリジ
ンサーバからのコンテンツ取得レートを制御し、同一ボ
トルネックを共有するコンテンツの間で帯域を融通し
て、視聴品質の悪化が起こる可能性を小さくする事が可
能となる。
【００５６】また、指定優先度を考慮した取得レートを
決定する手段によって、オリジンサーバからの取得レー
トを指定優先度も考慮して決定し、優先度の高い視聴に
関してより高い取得レートを割り当て、受信レート制御
手段や、オリジンサーバへコンテンツの送信レートを指
示する手段を用いて、決定した取得レートでのコンテン
ツ取得を行う事によって、本発明の第３の目的である、
ストリームプロキシサーバにおいて、指定優先度に従
い、優先度の高い視聴に関して、視聴品質の悪化が起こ
る可能性を小さくする事が可能となる。
【００５７】また、バッファ余裕に基づいてオリジンサ
ーバからのコンテンツ取得要求を送出する先読み手段を
用いることで、過剰な先読み要求の送出が抑制され、さ
らにコンテンツを部分的なコンテンツ断片として取得要
求を行う先読み制御手段を用いてコンテンツを時間的に
分割して取得することで、ネットワーク本発明の第１の
目的である、オリジンサーバからのコンテンツ取得をネ
ットワークに流れる他のトラヒックへの影響を抑えて実
現することが可能となる。
【００５８】また、ネットワーク情報収集手段と、同時
に実行される取得要求間の優先度を判別する手段と、優
先度に基づき実行中の要求を中止する手段により、バッ
ファ余裕のある取得要求の実行が抑制されることで、本
発明の第２の目的である、ストリームプロキシサーバに
おいて、オリジンサーバからのコンテンツ取得レートを
抑制し、同一ボトルネックを共有するコンテンツの間で
帯域を融通して、視聴品質の悪化が起こる可能性を小さ
くすることが可能となる。
【００５９】また、優先度をバッファ余裕の大小で決定
する手段とその判別された優先度に基づき実行中の要求
を中止する手段により、バッファ余裕のある取得要求の
実行が抑制され、本発明の第２の目的である、ストリー
ムプロキシサーバにおいて、オリジンサーバからのコン
テンツ取得レートを抑制し、同一ボトルネックを共有す
るコンテンツの間で帯域を融通して、視聴品質の悪化が
起こる可能性を小さくすることが可能となる。
【００６０】また、優先度を要求が取得しようとするコ
ンテンツを蓄積しているオリジンサーバにより決定する
手段により、コンテンツが蓄積されているオリジンサー
バを基準とした優先付けが可能となり、さらにその判別
された優先度に基づき実行中の要求を中止する手段によ
り、バッファ余裕のある取得要求の実行が抑制され、本
発明の第３の目的である、ストリームプロキシサーバに
おいて指定優先度に従い、優先度の高い視聴に関して視
聴品質の悪化が起こる可能性を小さくすることが可能と
なる。
【００６１】また、優先度を要求により獲得したコンテ
ンツ断片のデータをストリーム配信するクライアントに
より決定する手段により、配信対象となるクライアント
を基準とした優先付けが可能となり、さらにその判別さ
れた優先度に基づき実行中の要求を中止する手段によ
り、バッファ余裕のある取得要求の実行が抑制され、本
発明の第３の目的である、ストリームプロキシサーバに
おいて指定優先度に従い、優先度の高い視聴に関して視
聴品質の悪化が起こる可能性を小さくすることが可能と
なる。
【００６２】また、優先度を要求したコンテンツにより
決定する手段により、コンテンツを基準とした優先付け
が可能となり、さらにその判別された優先度に基づき実
行中の要求を中止する手段により、バッファ余裕のある
取得要求の実行が抑制され、本発明の第３の目的であ
る、ストリームプロキシサーバにおいて指定優先度に従
い、優先度の高い視聴に関して視聴品質の悪化が起こる
可能性を小さくすることが可能である。
【００６３】また、バッファ余裕の変化を予測し、バッ
ファ余裕が将来不足しそうな場合に、後続のコンテンツ
断片の取得要求を送出する先読み制御手段により、より
時間的な余裕を持った要求間での帯域の融通が可能とな
り、本発明の第２の目的である、ストリームプロキシサ
ーバにおいて、オリジンサーバからのコンテンツ取得レ
ートを抑制し、同一ボトルネックを共有するコンテンツ
の間で帯域を融通して、視聴品質の悪化が起こる可能性
を小さくすることが可能となる。
【００６４】また、後続のコンテンツ断片の取得を通信
速度の異なる複数のデータ送受信手段を使い分けて実行
する手段により、ネットワークの輻輳を抑制した取得を
選択できる可能性がより高くなり、本発明の第２の目的
である、ストリームプロキシサーバにおいて、オリジン
サーバからのコンテンツ取得レートを抑制し、同一ボト
ルネックを共有するコンテンツの間で帯域を融通して、
視聴品質の悪化が起こる可能性を小さくすることが可能
となる。
【００６５】また、後続のコンテンツ断片の取得を通信
速度の異なる複数のデータ送受信手段として優先制御を
もったネットワーク層プロトコルを利用する手段によ
り、Diffserv等既存のプロトコルの採用することで比較
的容易に本発明の第２の目的である、ストリームプロキ
シサーバにおいて、オリジンサーバからのコンテンツ取
得レートを抑制し、同一ボトルネックを共有するコンテ
ンツの間で帯域を融通して、視聴品質の悪化が起こる可
能性を小さくすることが可能となる。
【００６６】また、後続のコンテンツ断片の取得を通信
速度の異なる複数のデータ送受信手段として異なるトラ
ンスポート層プロトコルを使い分けて実行する手段によ
り、TCP RenoとTCP Vegasを使い分けるなど既存のプロ
トコルを使い分けることで比較的容易に本発明の第２の
目的である、ストリームプロキシサーバにおいて、オリ
ジンサーバからのコンテンツ取得レートを抑制し、同一
ボトルネックを共有するコンテンツの間で帯域を融通し
て、視聴品質の悪化が起こる可能性を小さくすることが
可能となる。
【００６７】また、後続のコンテンツ断片要求を送出す
る間隔をネットワーク状況に応じて調整する手段によ
り、ネットワークの輻輳状況に応じて、先読みに伴うト
ラヒックの調整を行い、ネットワークの輻輳を抑制する
ことで、本発明の第２の目的である、ストリームプロキ
シサーバにおいて、オリジンサーバからのコンテンツ取
得レートを抑制し、同一ボトルネックを共有するコンテ
ンツの間で帯域を融通して、視聴品質の悪化が起こる可
能性を小さくすることが可能となる。
【００６８】また、同一配信対象のための先読みを複数
同時に実行する手段と、ネットワークの輻輳を招かない
適切な同時実行数を判断し同時実行数を制御する手段に
より、１つの取得要求がデータを取得するために使える
実効帯域が限定されている場合でも、１人のクライアン
トをターゲットする取得要求を同時に複数実行すること
で空き帯域を活用した積極的な取得を実現し、より多く
のクライアントが配信品質を維持するために十分なバッ
ファ余裕を確保することが可能となる。
【００６９】
【本発明の実施の形態】（第１の実施の形態）図１に本
発明の第１の実施の形態の構成を示す。ストリームプロ
キシサーバ20Aは、クライアント10-1〜10-nのn台のクラ
イアントに対して、m台のオリジンサーバ40-1〜40-mの
保持するコンテンツのについてn本のストリームプロキ
シサービスを行っているものとする。またストリームプ
ロキシサーバ20Aと、オリジンサーバ40-1〜40-mは、ル
ータ30、リンク70とネットワーク50を経由して接続され
ているとする。リンク70には、ネットワーク50と60の間
のトラヒックも流れている。クライアントが視聴リクエ
ストを出す動作は、従来の技術で説明したものと同等と
する。
【００７０】図２に本発明の第１の実施の形態のプロキ
シサーバ20Aの内部構成図を示す。
【００７１】ストリーム配信制御部201Aは、クライアン
トからのコンテンツの視聴リクエストを受け取り、視聴
リクエストの合ったコンテンツを記憶装置から読み出し
てクライアントへとストリーム配信する機能を持つ。ま
た、視聴リクエストを、先読み制御部202Aへと伝える機
能も持つ。さらに、現在の配信位置、現在の配信レート
情報を先読み制御部202Aへと伝える機能も持つ。
【００７２】先読み制御部202Aは、ストリーム配信制御
部201Aから、視聴リクエストを受け取り、クライアント
が視聴したいコンテンツに関して、現在の配信位置以降
で、記憶部204Aに保持していないコンテンツ断片（コン
テンツの全部又は一部分）がある場合には、オリジンサ
ーバへのコネクションをトランスポート層制御部へ指示
して開設し、コンテンツ取得要求（コンテンツの識別
子、取得すべき各コンテンツ断片の開始位置と終わりの
位置から成る）をトランスポート層制御部に出す。ま
た、受信レート制御部206Aへ目標レートを指示する。こ
の目標レートに従って、受信レート制御部206Aはトラン
スポート層制御部205Aからコンテンツを読み出す。ま
た、先読み制御部202Aは、受信レート制御部206Aがトラ
ンスポート層制御部205Aから読み出したコンテンツを受
け取る。受け取ったコンテンツは記憶部204Aへと書き込
む。また、先読み制御部202Aは、コンテンツ取得要求で
指定しなければならない、コンテンツ断片の位置（開始
位置と終わり位置）、記憶部のコンテンツの中で削除す
る部分の決定も行う。さらに、オリジンサーバからのコ
ンテンツ取得の目標レートは、記憶部204Aが保持してい
るコンテンツ断片の位置の情報、ストリーム配信制御部
201Aから得られる現在の配信位置と配信レート、およ
び、ネットワーク情報取得部207Aから得られる情報を基
に決定する。この決定のアルゴリズムを「受信レート決
定アルゴリズム」と呼ぶ。先読み制御部202Aの動作の詳
細はフローチャートを使って後述する。また、「受信レ
ート決定アルゴリズム」の詳細についても後述する。
【００７３】記憶部204Aは、オリジンサーバのコンテン
ツの一部または全部のコピーを保存している。ストリー
ムの任意の位置への書き込みと読み出しのインターフェ
ース、および、ストリームのどの位置を保持しているか
の情報を、ストリーム配信制御部201A、先読み制御部20
2Aへ提供する。
【００７４】トランスポート層制御部205Aは、フロー制
御機能を持つトランスポート層プロトコル（例えばTCP
(Transport Control Protocol)）を使ったデータ通信を
制御する部分である。フロー制御機能とは、受信者が、
受信バッファの現在の空き状況を送信者へ伝え、送信者
は伝えられた空き状況に基づいて送信レートを調節する
事によって、受信側の受信バッファがあふれるのを防ぐ
機能の事である。例えばTCPはこの機能を持っている。
また、トランスポート層制御部205Aは、先読み制御部20
2Aからの指示に従って、オリジンサーバとのコネクショ
ンの開設、切断、およびデータ送受信に必要なトランス
ポート層の終端処理（例えばトランスポート層がTCPな
らTCPの送受信のプロトコル処理）を行う。また、開設
した各コネクションについて、先読み制御部からのデー
タ書き込み、および、受信レート制御部からのデータの
読み出し、の2つのインターフェースを持つ。
【００７５】受信レート制御部206Aは、先読み制御部20
2Aから指定される目標レートに従って、オリジンサーバ
から取得したコンテンツをトランスポート層制御部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 s
econd)とする。 （４）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に対する、時刻tでのストリームバッファ余裕（バ
ッファ余裕とも呼ぶ）を、ｂｉ（ｔ）秒とする。 （５）時刻tでの、クライアントＭｉ（ｉ＝１，
２，．．．，ｎ）の視聴の為に行う、オリジンサーバか
らのコンテンツ取得（先読み）のレートの目標値（目標
レート）をｇｉ（ｔ）とする。 （６）時刻tでの、クライアントｐＭｉ（ｉ＝１，
２，．．．，ｍ）の視聴のために行う、オリジンサーバ
からのコンテンツ取得（先読み）の実際の取得レートを
ｇｉ ＊（ｔ）とする。 （７）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に対する、現在の目標のバッファ余裕をＴｈ
ｉ Ｖ（ｔ）とする。Ｔｈｉ Ｖ（ｔ）はクライアントの再
生の飛びが生じる確率が許容範囲内に納めるために必要
なストリームプロキシサーバのバッファ余裕である。こ
の値は、経験値として固定的に与えてもよいし、動的に
決定してもよい。例えば、過去のコンテンツ取得レート
ｇｉ ＊（ｔ）の履歴と配信レートｒｉ（ｔ）の履歴か
ら、視聴開始時からのｒｉ（ｔ）−ｇｉ ＊（ｔ）の積分
値の履歴を求め、その最大値（すなわち、過去で最もバ
ッファ余裕が少なくなった状況を救うバッファ余裕とし
ている）等に決めてもよい。あるいは、以下のステップ
４において、Ａ（ｔ）−Ｐ（ｔ）＞０の状態が続けば、
ボトルネックの使用可能帯域が余っている事を意味する
ので、Ｔｈｉ Ｖ（ｔ）を増加させ、Ａ（ｔ）−Ｐ（ｔ）
＜０の状態が続けば、Ｔｈｉ Ｖ（ｔ）をある規定値にま
で減少させる、といった方法をとってもよい。 （８）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に関して、バッファ余裕が0の時に、現在の配信レ
ートのｓｉ倍でコンテンツ取得を行う、としてｓ ｉを決
定する。例えば、全ターゲットコンテンツ一律にｓｉ=3
などと決めてもよいし、配信レートｓｉ 倍がリンク70の
帯域になるように（バッファ余裕が0の時は最大リンク7
0の帯域全部を使えるように）決めてもよい。
【００８６】ステップ１：まず、実取得レートの合計と
現在のリンク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、記憶部20
4A、トランスポート層制御部205A、受信レート制御部20
6A、ネットワーク情報収集部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、ネットワーク情報収集部20
7Aと、それぞれ同じ動作をする。本発明の第１の実施の
形態と動作が異なる、先読み制御部202Bと、トランスポ
ート層制御部205B、受信レート制御部のみについて説明
する。
【０１０４】先読み制御部202Bは、ストリーム配信制御
部201Bから、視聴リクエストを受け取り、クライアント
が視聴したいコンテンツに関して、現在の配信位置以降
で、記憶部204Bに保持していないコンテンツ断片がある
場合には、オリジンサーバへ、複数のコネクション（そ
れぞれ、帯域共有特性の異なるトランスポート層プロト
コルを用いる）をトランスポート層制御部205Bへ指示し
て開設する。また、コンテンツ取得要求（コンテンツの
識別子、取得すべき各コンテンツ断片の開始位置と終わ
りの位置から成る）と、そのコンテンツ取得を、前記の
複数のトランスポート層プロトコルを用いたコネクショ
ンのうち、どれを使用して行うかを決定し（この決定方
法を、「トランスポート層プロトコル決定アルゴリズ
ム」と呼び、詳細は後述する）、トランスポート層制御
部205Bに指示する。コンテンツ取得要求したコンテンツ
を受け取っている最中にトランスポート層を切り替える
必要がある場合には、現在の取得を中断し、現在までに
受け取ったデータ量から、残りのコンテンツ断片を取得
するためのコンテンツ断片の開始位置と終わりの位置を
計算し、次のリクエストを切り替えたいトランスポート
層プロトコルのコネクションを使ってオリジンサーバへ
と転送する。また、受信レート制御部206Bへ、目標レー
トを指示し、受信レート制御部206Bがトランスポート層
制御部205Bから取得したコンテンツを読み出す速度を指
定して読み出させ、受信レート制御部206Bからコンテン
ツを受け取る。受け取ったコンテンツは記憶部206Bへと
書き込む。また、コンテンツ取得要求で指定するコンテ
ンツ断片の位置（開始位置と終わり位置）、記憶部のコ
ンテンツの中で削除する部分の決定も行う。さらに、オ
リジンサーバからのコンテンツ取得の目標レートは、記
憶部204Bが保持しているコンテンツ断片の位置の情報、
ストリーム配信制御部から得られる現在の再生位置情報
と視聴レート情報、および、ネットワーク情報取得部20
7Bから得られる情報を基に決定する。この決定のアルゴ
リズムを「受信レート決定アルゴリズム」と呼ぶ。先読
み制御部202Bの動作の詳細はフローチャートを使って後
述する。また、「受信レート決定アルゴリズム」の詳細
についても後述する
【０１０５】トランスポート層制御部205Bは、フロー制
御機能を持つトランスポート層プロトコル（例えばTC
P）を使ったデータ通信を制御する部分である。トラン
スポート層プロトコルとして、帯域共有の特性が異なる
複数の種類のトランスポート層プロトコルのコネクショ
ンの終端を行う事が出来る。先読み制御部202Bからの指
示に従って、オリジンサーバとのコネクションの開設、
切断、およびデータ送受信に必要なトランスポート層の
終端処理（例えばトランスポート層がTCPならTCPの送受
信のプロトコル処理）を行う。また、開設した各コネク
ションについて、先読み制御部からのデータ書き込み、
および、受信レート制御部からのデータの読み出しのイ
ンターフェースを持つ。帯域共有特性の異なるトランス
ポート層プロトコルとしては、例えば、TCP RenoとTCP
Vegas等がある。TCP Vegas は、TCPRenoと帯域を共有し
た場合、TCP Renoに帯域を譲る特性が知られている。
【０１０６】受信レート制御部206Bは、先読み制御部20
2Bから指定される目標レートに従って、オリジンサーバ
から取得したコンテンツをトランスポート層制御部205B
から読み出し、先読み制御部202Bへと渡す。トランスポ
ート層制御部205Bのトランスポート層はフロー制御機構
を持つため、受信レート制御部でデータの読み出しレー
トを制限すると、オリジンサーバからのデータ転送レー
トもその読み出しレートに制約される。これを用いてオ
リジンサーバからのデータ転送レートを制御する事が出
来る。
【０１０７】次に先読み制御部202Bの動作を図８、フロ
ーチャートである図１３から図１７を用いて説明する。 （受信レート決定アルゴリズム）まず以下を定義する。 （１）現時点での（新たに視聴開始するクライアントは
加えず、視聴終了するクライアントは含める）視聴を行
っているクライアントの集合を、ｐＭ＝｛ｐＭ１，ｐＭ
２，．．．，ｐＭｍ｝とする。 （２）ｐＭに新たな視聴を開始するクライアントを加
え、視聴を終了するクライアントを除いたクライアント
の集合をＭ＝｛Ｍ１，Ｍ２，．．．，Ｍｎ｝とする。 （３）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）へ
の、時刻tでの配信レートをｒｉ（ｔ） bps(bit per s
econd)とする。 （４）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に対する、時刻tでのストリームバッファ余裕（バ
ッファ余裕とも呼ぶ）を、ｂｉ（ｔ）秒とする。 （５）時刻tでの、クライアントＭｉ（ｉ＝１，
２，．．．，ｎ）の視聴の為に行う、オリジンサーバか
らのコンテンツ取得（先読み）のレートの目標値（目標
レート）をｇｉ（ｔ）とする。 （６）時刻tでの、クライアントｐＭｉ（ｉ＝１，
２，．．．，ｍ）の視聴のために行う、オリジンサーバ
からのコンテンツ取得（先読み）の実際の取得レートを
ｇｉ ＊（ｔ）とする。 （７）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に対する、現在の目標のバッファ余裕をＴｈ
ｉ Ｖ（ｔ）とする。Ｔｈｉ Ｖ（ｔ）はクライアントの再
生の飛びが生じる確率が許容範囲内に納めるために必要
なストリームプロキシサーバのバッファ余裕である。こ
の値は、経験値として固定的に与えてもよいし、動的に
決定してもよい。例えば、過去のコンテンツ取得レート
ｇｉ ＊（ｔ）の履歴と配信レートｒｉ（ｔ）の履歴か
ら、視聴開始時からのｒｉ（ｔ）−ｇｉ ＊（ｔ）の積分
値の履歴を求め、その最大値（すなわち、過去で最もバ
ッファ余裕が少なくなった状況を救うバッファ余裕とし
ている）等と決めてもよい。あるいは、以下のステップ
４において、Ａ（ｔ）−Ｐ（ｔ）＞０の状態が続けば、
ボトルネックの使用可能帯域が余っている事を意味する
ので、Ｔｈｉ Ｖ（ｔ）を増加させ、Ａ（ｔ）−Ｐ（ｔ）
＜０の状態が続けば、Ｔｈｉ Ｖ（ｔ）をある規定値にま
で減少させる、といった方法をとってもよい。 （８）クライアントＭｉ（ｉ＝１，２，．．．，ｎ）の
視聴に関して、バッファ余裕が0の時に、現在の配信レ
ートのｓｉ倍でコンテンツ取得を行う、としてｓ ｉを決
定する。例えば、全ターゲットコンテンツ一律にｓｉ=3
などと決めてもよいし、配信レートｓｉ 倍がリンク70の
帯域になるように（バッファ余裕が0の時は最大リンク7
0の帯域全部を使えるように）決めてもよい。
【０１０８】先読み制御部202Bは、第１の実施の形態と
同様に、図示しないタイマー（設定された時間が経過す
ると信号を発生する装置）に設定された時間が経過した
場合（あるいはカウンタによって設定された値を計数し
た場合）、あるいは、ストリーム配信制御部からの視聴
リクエスト（視聴終了、視聴初期化、視聴開始、取得完
了）によって、待ち状態から起動される。
【０１０９】視聴リクエストが「視聴終了」であった場
合、図１３に示すように、該当視聴コンテンツを取得し
ているオリジンサーバとのコネクションを切断する指示
をトランスポート層制御部205Bへ送る（ステップＢ１
０）。
【０１１０】視聴リクエストが「視聴初期化」の場合、
図１４に示すように、クライアントが視聴したいコンテ
ンツに関して、記憶部204Bに保持していないコンテンツ
断片がある場合には、オリジンサーバへのコネクション
をトランスポート層制御部205Bへ指示して開設する（ス
テップＢ２０）。このとき、帯域共有特性の異なる複数
のトランスポート層プロトコルのコネクションが開設さ
れる。また、ストリーム配信制御部201Bから、記憶部20
4Bに領域を確保する指示があれば、記憶領域を確保して
アドレスをストリーム配信制御部201Bへと返す（ステッ
プＢ３０）。
【０１１１】視聴リクエストが「視聴開始」の場合、図
１５に示すように、コンテンツの中で現在視聴している
位置以降で、保持していないコンテンツの部分から、取
得するコンテンツの位置を決定し（ステップＢ４０）、
トランスポート層プロトコル決定アルゴリズム(後述す
る）によって使用するトランスポート層プロトコルを決
定し、取得要求（コンテンツの識別子、取得すべき各コ
ンテンツ断片の開始位置と終わりの位置から成る）と使
用するトランスポート層プロトコルをトランスポート層
制御部205Bに指示する（ステップＢ５０）。また、タイ
マＴを「0」に設定し（ステップＡ６０）、タイマＴが
「0」の場合の処理である、該当コンテンツへの目標レ
ートの設定処理が実行されるようにする。
【０１１２】視聴リクエストがコンテンツ断片の「取得
完了」である場合、図１６に示すように、次に取得する
コンテンツの位置を決定し（ステップＢ７０）、トラン
スポート層プロトコル決定アルゴリズム(後述する）に
よって使用するトランスポート層プロトコルを決定し、
取得要求（コンテンツの識別子、取得すべき各コンテン
ツ断片の開始位置と終わりの位置から成る）と使用する
トランスポート層プロトコルをトランスポート層制御部
205Bに指示する（ステップＢ８０）。
【０１１３】タイマＴが「0」の場合、図１７に示すよ
うに、現在オリジンサーバからコンテンツ取得を行って
いる全コンテンツについて、記憶部204Bが保持している
コンテンツ断片の位置の情報、および、ストリーム配信
制御部201Bから得られる現在の配信位置の情報に基づい
て、トランスポート層プロトコル決定アルゴリズム(後
述する）によって使用すべきトランスポート層プロトコ
ルを決定する（ステップＢ９０）。トランスポート層プ
ロトコルに変更がある場合（ステップＢ１００）、現在
の取得を終了し（ステップＢ１１０）、現在までに取得
した断片のサイズから、現在の取得要求で取得するはず
であった残りのコンテンツの位置を決定し、残りのコン
テンツに対する取得要求（コンテンツの識別子、取得す
べき各コンテンツ断片の開始位置と終わりの位置から成
る）と使用するトランスポート層プロトコルをトランス
ポート層制御部205Bに指示する（ステップＢ１２０）。
【０１１４】次に、記憶部204Bが保持しているコンテン
ツ断片の位置の情報、および、ストリーム配信制御部20
1Bから得られる現在の配信位置の情報と、ストリーム配
信レート制御部201Bから得られる現在の配信レート情
報、および、ネットワーク情報取得部207Bから得られる
情報を基に、そのコンテンツに関する目標取得レートを
決定する（ステップＢ１３０）。目標取得レートの決定
アルゴリズムについては後述する。全コンテンツに対す
る目標レートが決まると、その値を受信レート制御部20
6Bに通知する（ステップＢ１４０）。このとき、トラン
スポート層が切り替わる場合には、また、これ以降、受
信レート制御部が取得したコンテンツは先読み制御部20
2Bが受け取って、記憶部204Bへの書き込みを行う。この
書き込み動作を実行しながら、タイマを規定値のT0にリ
セットし（ステップＢ１５０）、待ち状態となる。
【０１１５】（トランスポート層プロトコル決定アルゴ
リズム）以下に前述のトランスポート層プロトコル決定
アルゴリズムを示す。
【０１１６】ストリーム配信制御部201Bから得られる現
在の配信位置と、記憶部204Bから得られるストリームの
どの位置を保持しているかの情報から、現在のバッファ
余裕ｂｉ（ｔ）を求め、これと、ネットワーク情報収集
部207Bから得られる現在のネットワーク状況に基づい
て、使用するトランスポート層プロトコルを決定する。
例えば、2つの閾値Ｔｈｉ Ｕ（ｔ）とＴｈｉ Ｍ（ｔ）
（Ｔｈｉ Ｕ（ｔ）＜Ｔｈｉ Ｍ（ｔ）とする）を決め、ｂ
ｉ（ｔ）＜Ｔｈｉ Ｕ（ｔ）なら、トランスポート層をTC
P Reno、ｂｉ（ｔ）＞Ｔｈｉ Ｍ（ｔ）ならば、TCP Vega
sとする。Ｔｈｉ Ｕ（ｔ）≦ｂｉ（ｔ）≦Ｔｈ
ｉ Ｍ（ｔ）の場合、前回のトランスポート層の変更がTC
P RenoからTCP Vegasへの変更であったならばTCP Vegas
に、TCP VegasからTCPRenoへの変更であったならばTCP
Renoとする。前回の変更がない場合（まだ一度も切り替
えていない場合）、例えば、TCP Vegasとする。閾値Ｔ
ｈｉ Ｕ（ｔ）とＴｈｉ Ｍ（ｔ）は、ネットワーク情報収
集部から得られる、ネットワークの輻輳の度合いの変動
が大きい場合には大きく、小さい場合には小さく設定す
る。
【０１１７】次に受信レート決定アルゴリズムを示す
(第１の実施の形態の受信レートアルゴリズムと同じで
ある)。
【０１１８】（受信レート決定アルゴリズム） ステップ１：まず、実取得レートの合計と現在のリンク
70の空き帯域Ｘ（ｔ）が、ターゲットコンテンツの集合
Ｍがオリジンサーバからのコンテンツ取得に使える帯域
（使用可能帯域）であると考え、その帯域
【数５】 を求める。
【０１１９】ステップ２：クライアント集合Ｍの各クラ
イアントの視聴について、 現在のバッファ余裕に依存
して、希望レートｇｉ ０（ｔ）を決定する。例えば、ｇ
ｉ ０（ｔ）＝ｍａｘ｛０，ｒｉ（ｔ）＋（Ｔｈ
ｉ Ｖ（ｔ）−ｂｉ（ｔ））（ｓ ｉ／Ｔｈｉ Ｖ（ｔ））｝
を計算して決定する。ここで、ｍａｘ｛ａ，ｂ｝とは、
ａ，ｂのうちの大きい方を意味する（図８を参照）。 ステップ３：
【数６】 を求める。
【０１２０】ステップ４：Ｐ（ｔ）≦Ａ（ｔ）ならば、
目標レートｇｉ（ｔ）＝ｇｉ ０（ｔ）として終了。 そうでないならば、ステップ５へ
【０１２１】ステップ５：目標レートｇｉ（ｔ）を、Ａ
（ｔ）をｇｉ ０（ｔ）に比例して配分したものとする。
終了。
【０１２２】なお、ステップ５において、目標レートｇ
ｉ（ｔ）を、バッファ余裕ｂｉ（ｔ）を出来るだけ平均
化するように割り当ててもよい。あるいは、目標レート
ｇｉ（ｔ）を、ｇｉ ０（ｔ）の大きいものから順に、ｇ
ｉ（ｔ）の合計がＡ（ｔ）を越えない範囲で割り当て、
越えるものについては、目標レートとして0を割り当て
る方式でもよい。すなわち、ｇｉ ０（ｔ）の大きいもの
順に並べ変えてｇｉ １（ｔ）とし、Kを、
【数７】 を満たす整数として、
【数８】 とする方式でもよい。また、管理者の設定する、指定優
先度（視聴コンテンツやクライアントに依存して決まる
優先度）に従って、優先度の高いものから順にＡ（ｔ）
から目標レートｇｉ（ｔ）をｇｉ ０（ｔ）として割り当
てる方式でもよい。
【０１２３】次に、第２の実施の形態のストリームプロ
キシサーバ20Bの全体の動作を説明する。第１の実施の
携帯のストリームプロキシサーバ20Aとの大きな違い
は、主に以下の点である。まず、トランスポート層制御
部は、帯域共有特性の異なる複数のトランスポート層プ
ロトコルを使って、複数のコネクションをサーバとの間
に持っている。そして、先読み制御部202Bがオリジンサ
ーバからのコンテンツを取得する際に、目標受信レート
とともに、使用するトランスポート層プロトコルを、ス
トリーム配信制御部から得られる現在の再生位置情報と
視聴レート情報、および、ネットワーク情報取得部207B
から得られる情報を基に変える点が異なる。
【０１２４】クライアントが送信する視聴リクエストに
は、視聴初期化（コンテンツ識別子が指定される）、視
聴開始(コンテンツ内での位置が指定される、例えば再
生時間での何秒目などを指定する）、視聴停止、視聴終
了が含まれるのは、従来のストリームプロキシサーバの
場合と同様である。また、視聴の際の動作も同様で、ク
ライアントは、まず「視聴初期化」の視聴リクエストを
プロキシサーバに送信し、プロキシサーバと、クライア
ントとの間に、リクエスト内のコンテンツ識別子で指定
されたコンテンツについての配信サービスのためのコネ
クションを開設する。ストリームプロキシサーバは、そ
の後、「視聴開始」（任意の開始位置が指定出来る）
や、「視聴停止」（一時停止）、の視聴リクエストを使
ってコンテンツ視聴を行い、視聴を終えると、「視聴終
了」の視聴リクエストでプロキシサーバに視聴を終える
旨を通知する。
【０１２５】図１８に、前記の視聴リクエストを利用し
た典型的なコンテンツ視聴のタイミングチャートを示
す。図１８では、クライアントはコンテンツの最初から
視聴開始し、最後まで見終わってから視聴終了するとす
る。また、図１９に示すように、視聴開始の時点で、ス
トリームプロキシサーバはコンテンツの最初の部分(0秒
〜Ta秒）、コンテンツの途中部分(Tb秒〜Tc秒）をスト
リームプロキシサーバが保持しているとする。図１８で
は、保持している以外の部分（Ta〜Tb秒、および、Tc〜
Td秒）をオリジンサーバから取得しながら、クライアン
トへとストリーム配信している様子を示している。
【０１２６】図１８のBT-10において、クライアント
が、「視聴初期化」のリクエストをプロキシサーバに送
り、サーバが肯定応答(OK)）を返す事で、視聴リクエス
トの配信のためのコネクションが、クライアントとスト
リームプロキシサーバとの間に開設される。次に、BT-2
0において、クライアントは「視聴開始」（位置は先頭
(0秒)から）の視聴リクエストを送ってくるので、コン
テンツスイッチは、記憶部に保持している該当コンテン
ツの先頭部分からコンテンツのストリーム配信を開始す
る(BT-30)。また、オリジンサーバへに、コンテンツの
保持している以外の部分を取得するために、コネクショ
ンを開設し(BT-40)、後続のコンテンツ部分の取得要求
を出す(BT-50)。そしてサーバから後続のコンテンツ部
分を取得し始める（BT-60)。取得した部分は記憶部にた
められてゆく。ストリームプロキシサーバは、オリジン
サーバから、後続のコンテンツを取得して記憶部204Bに
保存しながら、記憶部204Bに保持しているコンテンツを
ストリーム配信してゆく(BT-90)。このとき、配信した
い位置のコンテンツがまだ取得出来ていない場合（バッ
ファ余裕が0秒になった場合）には、取得出来るまでの
間（バッファ余裕が正の値になるまで）、配信は一時的
に中断され、クライアントには視聴が不連続に飛んだ
（映像がとぎれる、あるいは、音がとぎれるなど）よう
にみえ、視聴品質が悪化する。ストリームプロキシサー
バは、コンテンツ断片の取得が終わると(BT-65)、現在
の配信位置以降で、次に保持していないコンテンツ断片
の取得要求を出す(BT-70)。コンテンツの取得に関して
は、受信レート制御部によって、トランスポート層から
の読みとりレートを制御することでコンテンツの取得レ
ートの制御を行う。また、コンテンツ取得を行うトラン
スポート層についても、トランスポート層プロトコル決
定アルゴリズムに従って決定し、それを用いてコンテン
ツ取得を行う。この例では、最初の後続のコンテンツ断
片要求(BT-50)はTCP Renoのトランスポート層プロトコ
ルを用いており、次の後続のコンテンツ断片(時間Tc〜T
d)については、TCP Vegasを使った取得を行うが(BT-7
3、BT-83)、途中(BT-75)で、トランスポート層決定プロ
トコルによってTCP Renoへと切り替える判断がなされ
る。BT-75までに取得出来たコンテンツ断片が、時間Tc
〜Txの部分であり、現在の配信位置がTxより前であるた
め、さらに後続のコンテンツ断片(Tx〜Td)については、
TCP Renoを使ってコンテンツの取得要求を出し(BT-8
0)、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と帯域を共有すると、T
CP Renoに帯域を譲るという効果があるため、他のトラ
ヒックとコンテンツ取得を行っているトラヒック帯域共
有をしているような場所（例えば、リンク70)におい
て、他のトラヒックに対して帯域を譲る効果があり、他
のトラヒックに対する影響を抑える事が出来、発明の第
１の目的を達成することが可能となる。
【０１３２】また、受信レート制御アルゴリズムのステ
ップ２では、各クライアントの視聴のために行うオリジ
ンサーバからのコンテンツ取得（先読み）の希望レート
をバッファ余裕が少なくなるほど高く、バッファ余裕が
大きければ低くなるように決めている。また、ステップ
４で希望レートの合計が、使用可能帯域を越えなけれ
ば、希望レートが目標レートとなり、越えていれば、ス
テップ５で使用可能帯域を希望レートで比例配分したも
のにしているため、同一ボトルネックを共有する先読み
の間で、バッファ余裕が少ないものに、より多くの帯域
を割り当てる事が可能となり、視聴品質の悪化が起こる
可能性を小さくする事が可能となり、本発明の第２の目
的を達成することが可能となる。
【０１３３】さらに、ステップ５において、輻輳時に、
指定優先度の高い特定のクライアントやコンテンツにつ
いて、使用可能帯域の中から、より多くの帯域を割り当
てる事が出来る。これによって、特定のクライアントや
コンテンツについて、視聴品質の悪化が起こる可能性を
小さくする事が可能となり、本発明の第３の目的を達成
することが可能となる。
【０１３４】（第３の実施の形態）図２０に本発明の第
３の実施の形態のストリームプロキシサーバC1000の内
部構成図示す。本発明の第１の実施の形態のストリーム
プロキシサーバ20Aとほぼ同じ構成であるが、サーバか
らのコンテンツ送信レートを制御する方式が異なるた
め、受信レート制御部206Aが、受信レート制御部206Cへ
とおき変わっている。また、トランスポート層制御部20
5Cが用いるトランスポート層プロトコルは、フロー制御
機能を持っている必要はない点が異なる。
【０１３５】受信レート制御部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)≦TH
Liとなったことを契機に発生したコンテンツ断片の取得
要求は、クライアント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（以下新規ターゲットクライアント）を先読み制御部2
02Eは決定する（ステップＤ１０）。新たなコンテンツ
断片の取得要求を以下では新規取得要求と呼ぶ。バッフ
ァ余裕の算出法は従来例と同様である。
【０１６６】まず、先読み制御部202Eはネットワーク情
報収集部207Eから、ボトルネックリンクの現在時刻tの
帯域使用幅RA(t)を取得する（ステップＤ２０）。その
際、ネットワーク情報収集部207Eがどこの帯域使用幅を
測定すれば良いのかを、図２２に示されるネットワーク
構成を用いて説明する。ストリームプロキシサーバ20E
に接続されたリンク120がボトルネックであり、ストリ
ームプロキシサーバ20Eがトランスペアレントキャッシ
ュとして接続されている場合は、ボトルネックの帯域使
用幅はトランスポート層制御部205Eが測定し、ネットワ
ーク情報収集部207Eがトランスポート層制御部205Eに問
い合わせを行うことになる。ストリームプロキシサーバ
20Eを介して流れるトラヒック以外のトラヒックも流れ
るリンク、例えば図２２においては、リンク110がボト
ルネックの場合は、ルータ30で帯域使用幅を測定する。
ネットワーク情報収集部207Eは、ルータ30にSNMP等を利
用して問い合わせをすることで、ボトルネックの現在の
帯域使用幅を知ることができる。
【０１６７】各コンテンツ断片の取得レートは受信状況
監視部202E-1で測定されている。時刻tでのクライアン
トjをターゲットとしたコンテンツ断片の取得レートをr
j(t)で表すことにする。
【０１６８】次に、新規取得要求を実行し、コンテンツ
断片をオリジンサーバからストリームプロキシサーバが
受信する際の取得レートを先読み制御部202Eが推定する
（ステップＤ３０）。これを先読み取得予測レートと呼
び、z＊j(t)で表すことにする。もし新規取得要求が要
求するコンテンツの一部が既にコンテンツ断片として記
憶部204Eに蓄積された経歴があれば、受信状況監視部20
2E-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)であったとする。これ
らの要求を全て中止しても見込み帯域使用幅がボトルネ
ック限界レート以下にならないならば、先読み制御部20
2Eはクライアント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であるRT
Tiの半分などと近似すればよい。
【０２０１】説明を簡単にするために、クライアントi
をターゲットとしたコンテンツ断片の取得レートがほぼ
変動なくziであり、視聴レートもCBRでriだったとす
る。すると、クライアントiへの要求を中止した場合の
見込みバッファ余裕b＊i(t)は、現在のバッファ余裕をb
i(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は、要求した開始位置のデ
ータの到着から、終了位置のデータの到着までの間、(z
j-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と設定する。こうすることで、現在時刻からS
T秒後のクライアントjのバッファ余裕は、THLMINj以下
にならないことが期待できる。
【０２０８】そして先読み制御部202Eは、トランスポー
ト層制御部205Eに、先のステップで決定した範囲を指定
したコンテンツ取得要求をオリジンサーバに送出してコ
ンテンツ断片を受信するように指示する（ステップＥ８
０）。コンテンツ断片の取得を指示されたトランスポー
ト層制御部205Eは、オリジンサーバとの間にコネクショ
ンが存在しなければ開設、既に存在すればそれを再利用
し、コンテンツ断片の取得を実行する。
【０２０９】そして、送出した要求の中止（ステップＥ
１１０）、または送出した要求によるコンテンツ断片の
取得完了（ステップ１００）のいずれかのイベントが発
生するのを先読み制御部202Eは待つ（ステップＥ９
０）。
【０２１０】コンテンツ断片の取得が完了した場合（ス
テップ１００）、先読み制御部202Eはクライアントjを
ターゲットとする取得要求の次回送出時刻を設定する
（ステップＥ１２０）。次回要求送出時刻は、バッファ
余裕が取得要求送出バッファ余裕閾値THLjに達すると予
測される時刻を次回の要求生成時刻として設定する。現
在のバッファ余裕がbj(t)(≧THLj)とすると、XT秒先の
見込みバッファ余裕b＊j(t+XT)は、b＊j(t+XT)=bj(t)-X
Tである。これが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である。これがT
HLMINjとなるのは、XT=bj(t)-THLMINj秒後である。現在
時刻＋XTを次回取得要求送出時刻として設定する。もし
THLMINj ＞bj(t)ならば、バッファ余裕が視聴品質を保
つのには不十分と判断しクライアントjをターゲットと
したコンテンツ断片の取得はあきらめるものとする（ス
テップＥ１５０）。
【０２１２】また、以上の処理フローは、クライアント
jからの視聴終了リクエストがストリーム配信制御部201
Eを通じて、先読み制御部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、 AF
1、 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、RT
Tj、2のみが受信状況監視部202E-1に記録されていると
する。このとき、EFではRTTj、1=RTT1と算出できる。AF
1でのRTTは、この最新値を用いれば良い。EF2のRTTは、
重み付けを用いて、RTTj、3=RTTj、2×CIR1/CIR2と換算
することができる。
【０２２８】クライアントjをターゲットとしたコンテ
ンツ断片の取得が既に実行されたことのない場合でも、
同一のコンテンツが他のクライアントをターゲットとし
て取得されたことがあれば、受信状況監視部202E-1に記
録されているその最新RTTで各クラスでの取得予測レー
トを近似することができる。全てのクラスでの取得実績
が無くても、上記の換算法で算出することができる。
【０２２９】同一のコンテンツが他のクライアントをタ
ーゲットとして取得されたことも無ければ、先読み制御
部202Eは同一のオリジンサーバからのRTTが受信状況監
視部202E-1に記録されていないか調べる。そしてこの最
新値で各クラスでのRTTを近似することができる。全て
のクラスでの取得実績が無くても、上記の換算法で算出
することができる。
【０２３０】クライアントjをターゲットとしたコンテ
ンツ断片の取得が既に実行されたことも、同一のコンテ
ンツが他のクライアントをターゲットとして取得された
ことも、同一のオリジンサーバからの取得実績もない場
合、各クラスに対するデフォルト値を用いることで、RT
Tを設定することができる。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-b
j(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の取得要求送出バッファ余裕値T
HLjを指定されている初期値に初期化する（ステップＨ
２０）。
【０２５３】クライアントjをターゲットとしたコンテ
ンツ断片の取得要求が送出されてから開始位置のコンテ
ンツデータが到着するまでのRTT(以下RTTjと表記)は、
視聴開始時には測定履歴がない。そこでRTTjの初期値を
以下のいずれかの方法で設定する（ステップＨ３０）。 （１）同一のコンテンツに対する他のクライアントiを
ターゲットとしたコンテンツ断片取得が実行されている
場合は、そのクライアントiのRTTを用いる。つまり、RT
Tj=RTTiとする。 （２）過去に同一コンテンツに対する要求があった場合
は、その最新のRTTを利用する。 （３）適当なデフォルト値として初期設定する。
【０２５４】そして先読み制御部202Eはコンテンツ断片
の取得範囲を算出する（ステップＨ４０）。この範囲の
算出法は、第５の実施の形態と同様である。
【０２５５】そして先読み制御部202Eは、トランスポー
ト層制御部205Eに、先のステップで決定した範囲を指定
したコンテンツ取得要求をオリジンサーバに送出してコ
ンテンツ断片を受信するように指示する（ステップＨ５
０）。コンテンツ断片の取得を指示されたトランスポー
ト層制御部205Eは、オリジンサーバとの間にコネクショ
ンが存在しなければ開設、既に存在すればそれを再利用
し、コンテンツ断片の取得を実行する。
【０２５６】要求の送出から要求したコンテンツ断片の
開始位置の到着までの時間（RTT）を受信状況監視部202
E-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の増加（減少）に対してTHL
jを減少（増加）させるなら、ここで示した方法にこだ
わる必要はない。このようにRTTが増加した場合にTHLj
を減少することで、ネットワーク輻輳時に要求送出を行
ってしまう可能性を減らすことができる。
【０２５８】しかし、THLjを小さくしすぎると、ネット
ワークの輻輳が長引くとバッファが枯渇し、クライアン
トの視聴品質が劣化する危険性がある。そこで、THLjは
設定された最小値THLmin-j以下にはならないようにす
る。また、あまりに大きなバッファ余裕を持つことは記
憶部204Eのスペースを圧迫するという意味で無駄である
ため、THLj は指定された最大値THLmax-j以上にならな
いようにする。
【０２５９】そして、先読み制御部202Eはバッファ余裕
値bj(t)を監視し、取得要求送出バッファ余裕値THLj以
下になるまで待つ（ステップＨ８０）。なったらステッ
プＨ４０に戻り、再び要求の送出を行う。
【０２６０】以上の処理フローは、クライアントjから
の視聴終了リクエストがストリーム配信制御部201Eを通
じて、先読み制御部202Eに届くと中止される。先読み制
御部202Eは、視聴終了リクエストを受けると、トランス
ポート層制御部205Eに対して、オリジンサーバへ取得中
止の要求を送出するように指示する。また、必要があれ
ばオリジンサーバとストリームプロキシサーバ間のコネ
クションの切断も指示する。
【０２６１】上記の第１０の実施の形態では、RTTを基
にした制御を示した。しかし、ネットワークの輻輳はRT
Tのみで検知されるものではない。RTTを他のネットワー
クの輻輳を検知する指標に置き換えることも可能であ
る。例えば、ボトルネックリンクの使用率で置き換えた
制御も可能である。より具体的には、ステップＨ７０で
の取得要求送出バッファ余裕値THLjを、ボトルネックの
使用率に依存して動的に変化させる。このときの構成
は、図２６に示される第６の実施の形態の構成と同様で
あるとする。先読み制御部202Eは、ネットワーク情報収
集部207Eからボトルネックリンクの使用率を所得する。
ボトルネックリンクの使用率が増加してくると、THLjを
小さくする。RTTが小さくなるとTHLjを大きくする。例
えば、ある時間幅のタイムスロット毎に、先読み制御部
202Eはネットワーク情報収集部207Eからボトルネックリ
ンクの使用率を所得するとする。前回のタイムスロット
でのリンク使用率をUold、今回のタイムスロットでのリ
ンク使用率をUとすると、 THLj_old = THLj; THLj = THLj_old×Uold /U; としてTHLjを更新する。ボトルネックリンクの使用率の
増加（減少）に対してTHLjを減少（増加）させるなら、
ここで示した方法にこだわる必要はない。このようにボ
トルネックリンクの使用率が増加した場合にTHLjを減少
することで、ネットワーク輻輳時に要求送出を行ってし
まう可能性を減らすことができる。
【０２６２】さらに、これまで示した第１０の実施の形
態は、第５の実施の形態をベースとしていたが、ベース
となる制御は第６〜第９の実施の形態に置き換えること
も容易に可能である。
【０２６３】第１０の実施の形態の効果は、第５から第
９の実施の形態に比較して、より早期にネットワークの
輻輳を回避できることである。ネットワークの輻輳状況
に応じて、要求の送出を抑制する仕組みを入れることで
ネットワークの輻輳を検知した時点で、要求送出間隔を
大きく、逆に、ネットワークが空いている場合は、要求
送出間隔を小さくすることで、この効果が実現できる。
【０２６４】（第１１の実施の形態）第１０の実施の形
態は、ネットワークの輻輳時の要求送出の回避を１つの
特徴としている。しかし、第１０の実施の形態でも触れ
たように、この制御はネットワークの輻輳が持続した場
合、バッファ余裕の枯渇、配信品質の劣化に繋がる可能
性がある。
【０２６５】ボトルネックリンクは輻輳していないにも
関わらず、特定のコネクション（特定のオリジンサー
バ）からの取得が輻輳により遅くなっているケースもあ
る。このような場合、第１０の実施の形態とは逆に、RT
Tの増加に対しては、積極的に要求送出を行うべきであ
る。できるだけ早く取得要求を送出しなければ、取得が
間に合わない危険性が高いからである。
【０２６６】第１１の実施の形態の特徴は、ネットワー
クの輻輳状況をRTTにより捉え、RTTの増加、つまりネッ
トワークが輻輳したと判断されたときには、バッファ余
裕をできるだけ大きく維持できるように、RTTが小さい
ときに比べ、より頻繁にコンテンツ断片の取得を行う。
この制御により、ネットワークの輻輳に伴うデータの到
着遅延に伴うバッファの枯渇（バッファ余裕が０となる
こと）を回避することができる。
【０２６７】第１０の実施の形態との相違点は、図３１
のステップＨ７０での取得要求送出バッファ余裕値THLj
の設定のみである。
【０２６８】前回のコンテンツ断片要求時のRTTをRTTj_
old、今回のコンテンツ断片要求時のRTTをRTTjとする
と、 THLj_old = THLj; THLj = THLj_old×RTTj/RTTj_old; としてTHLjを更新する。RTTの増加（減少）に対してTHL
jを増加（減少）させるなら、ここで示した方法にこだ
わる必要はない。このように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)は、ストリームプロキシサーバ上に時刻P
T後には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は、ストリーム配信制御部20
1Eからの視聴リクエストの到着、コンテンツ断片取得要
求送出時刻のイベントを監視し、新規取得要求の生成を
待つ。そして新規ターゲットクライアント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,..,m
j)とする。ここに、新たにクライアント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と設定する。こうすることで、現在時刻からS
T秒後のクライアント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からの視聴終了リクエストがストリーム配信制御部201
Eを通じて、先読み制御部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 ネットワーク情報収集
部
───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B089 GB01 JA11 KD01 KE09 5K030 GA13 HA08 HB02 HB13 KA01 KA03 LA03 LA08 LD13 MA13 MB02 MB15

Claims (31)

    【特許請求の範囲】
  1. 【請求項１】 コンテンツの一部または全部を記憶装置
    に格納し、当該記憶装置からクライアントにコンテンツ
    を配信しながら、該コンテンツの保持していない部分を
    オリジンサーバから取得して前記記憶装置に追加するプ
    ロキシサーバにおいて、 前記オリジンサーバからのコンテンツの取得レートを、
    ネットワーク状況又は前記コンテンツの受信バッファの
    状態の少なくとも一方に応じて制御することを特徴とす
    るプロキシサーバ。
  2. 【請求項２】 コンテンツの一部または全部を記憶装置
    に格納し、当該記憶装置からクライアントにコンテンツ
    を配信しながら、該コンテンツの保持していない部分を
    オリジンサーバから取得して前記記憶装置に追加するプ
    ロキシサーバにおいて、 前記オリジンサーバからのコンテンツの取得に用いるプ
    ロトコルを、異なる帯域共有特性を持つ複数のプロトコ
    ルの中から、ネットワーク状況又は前記コンテンツの受
    信バッファの状態の少なくとも一方に基づいて選択する
    ことを特徴とするプロキシサーバ。
  3. 【請求項３】 前記オリジンサーバからのコンテンツの
    取得を、フロー制御の機能を備えるプロトコルを用いて
    行い、前記オリジンサーバからのコンテンツ取得レート
    の制御を、前記プロトコルの受信バッファからコンテン
    ツを読み出すレートを制御することにより実現すること
    を特徴とする請求項１に記載のプロキシサーバ。
  4. 【請求項４】 前記オリジンサーバからのコンテンツの
    取得に用いるプロトコルを、フロー制御の機能を備える
    帯域共有特性の異なる複数の種類のプロトコルの中か
    ら、ネットワーク状況又は前記コンテンツの受信バッフ
    ァの状態の少なくとも一方に基づいて選択し、前記オリ
    ジンサーバからのコンテンツ取得レートの制御を、前記
    プロトコルの受信バッファからコンテンツを読み出すレ
    ートを制御することにより実現することを特徴とする請
    求項１に記載のプロキシサーバ。
  5. 【請求項５】 前記オリジンサーバからのコンテンツの
    取得レートの制御を、前記オリジンサーバに送信レート
    を指示することによって実現することを特徴とする請求
    項１に記載のプロキシサーバ。
  6. 【請求項６】 前記オリジンサーバからのコンテンツの
    取得を、帯域共有特性の異なる複数の種類のプロトコル
    の中から、ネットワーク状況又は前記コンテンツの受信
    バッファの状態の少なくとも一方に基づいて選択し、前
    記オリジンサーバからのコンテンツの取得レートの制御
    を、前記オリジンサーバに送信レートを指示することに
    より実現することを特徴とする請求項１に記載のプロキ
    シサーバ。
  7. 【請求項７】 前記オリジンサーバからのコンテンツ取
    得レートを、前記コンテンツ又はクライアントに対して
    設定された優先度も考慮して決定することを特徴とする
    請求項１、３、４、５、６のいずれか一つに記載のプロ
    キシサーバ。
  8. 【請求項８】 コンテンツの一部をバッファに蓄積し、
    前記バッファからクライアントにコンテンツを配信しな
    がら、該コンテンツの現在のバッファへの蓄積位置より
    後続のコンテンツ部分をオリジンサーバから取得してバ
    ッファに追加するプロキシサーバにおいて、 前記バッファに蓄積されているコンテンツの残り時間を
    検出し、前記残り時間が閾値以下になったタイミング
    で、該コンテンツの現在のバッファ蓄積位置より後続の
    前記コンテンツ部分を前記オリジンサーバから取得する
    ことを特徴とするプロキシサーバ。
  9. 【請求項９】 前記後続のコンテンツ部分の取得の間に
    優先度を設け、前記優先度の低い取得を中止することで
    ボトルネックリンクの帯域使用幅が基準値を上回らない
    ように調整することを特徴とする請求項８に記載のプロ
    キシサーバ。
  10. 【請求項１０】 前記優先度を、前記クライアントによ
    るコンテンツの視聴位置と前記バッファの蓄積位置の差
    に基づいて設定することを特徴とする請求項９に記載の
    プロキシサーバ。
  11. 【請求項１１】 前記優先度を、前記コンテンツが蓄積
    されているオリジンサーバ、コンテンツを配信するクラ
    イアント、取得を行うコンテンツの少なくとも何れか毎
    に設定することを特徴とする請求項９に記載のプロキシ
    サーバ。
  12. 【請求項１２】 コンテンツの一部をバッファに蓄積
    し、該バッファからクライアントにコンテンツを配信し
    ながら、該コンテンツの現在のバッファ蓄積位置より後
    続のコンテンツ部分をオリジンサーバから取得してバッ
    ファに追加するプロキシサーバにおいて、 前記バッファに蓄積されているコンテンツの残り時間が
    指定された時刻に閾値以下になることを予測することに
    より、該コンテンツの現在のバッファ蓄積位置より後続
    のコンテンツ部分をオリジンサーバから取得することを
    特徴とするプロキシサーバ。
  13. 【請求項１３】 通信速度の異なる複数のデータ送受信
    手段を使い分けることにより、指定された時刻にバッフ
    ァに蓄積されているコンテンツの残り時間が指定された
    値を上回るように該コンテンツの現在のバッファ蓄積位
    置より後続のコンテンツ部分をオリジンサーバから取得
    することを特徴とする請求項８、９、１０、１１、１２
    の何れかひとつに記載のプロキシサーバ。
  14. 【請求項１４】 通信速度の異なる複数のデータ送受信
    手段として優先制御を備えるプロトコルを利用すること
    特徴とする請求項１３に記載のプロキシサーバ。
  15. 【請求項１５】 通信速度の異なる複数のデータの送受
    信手段として異なるトランスポート層プロトコルを使い
    分けることを特徴とする請求項１３に記載のプロキシサ
    ーバ
  16. 【請求項１６】 該コンテンツの現在のバッファ蓄積位
    置より後続のコンテンツ部分を前記オリジンサーバから
    取得するタイミングを決定する閾値を、前記オリジンサ
    ーバとの間のネットワークの輻輳状況の変化に合わせて
    動的に更新することを特徴とする請求項８から請求項１
    ５の何れか一つに記載のプロキシサーバ。
  17. 【請求項１７】 コンテンツの一部または全部を記憶装
    置に格納し、該記憶装置からクライアントにコンテンツ
    を配信しながら、該コンテンツの保持していない部分を
    オリジンサーバから取得して記憶装置に追加するプロキ
    シサーバにおいて、 前記オリジンサーバからのコンテンツの取得に用いる送
    信レート制御機能を持つプロトコルを、異なる帯域共有
    特性を持つ複数のプロトコルの中から、ネットワーク状
    況と受信バッファの状態の少なくとも一方に応じて選択
    することを特徴とするプロキシサーバ。
  18. 【請求項１８】 前記オリジンサーバからのコンテンツ
    の取得を、フロー制御と送信レート制御機能を備えるプ
    ロトコルを用いて行い、前記オリジンサーバからのコン
    テンツ取得レートの制御を、前記フロー制御と送信レー
    ト制御機能を備えるプロトコルの受信バッファからコン
    テンツを読み出すレートを制御することにより実現する
    ことを特徴とする請求項１に記載のプロキシサーバ。
  19. 【請求項１９】 前記オリジンサーバからのコンテンツ
    の取得に用いる送信レート制御機能を備えるプロトコル
    を、フロー制御の機能を持つ帯域共有特性の異なる複数
    の種類のプロトコルの中から、ネットワーク状況と受信
    バッファの状態の少なくとも一方に基づいて選択し、前
    記オリジンサーバからのコンテンツ取得レートの制御
    を、送信制御機能を備えるプロトコルの受信バッファか
    らコンテンツを読み出すレートを制御することで実現す
    ることを特徴とする請求項１に記載のプロキシサーバ。
  20. 【請求項２０】 前記オリジンサーバからのコンテンツ
    の取得を、帯域共有特性の異なる複数の種類の送信レー
    ト制御機能を備えるプロトコルの中から、ネットワーク
    状況と受信バッファの状態の少なくとも一方に基づいて
    選択し、前記オリジンサーバからのコンテンツの取得レ
    ートの制御を、前記オリジンサーバに送信レートを指示
    することで実現することを特徴とする請求項１に記載の
    プロキシサーバ。
  21. 【請求項２１】 前記受信バッファの状態は、目標とし
    て設定したバッファ余裕と現在のバッファ余裕との差を
    用いることを特徴とする請求項１に記載のプロキシサー
    バ。
  22. 【請求項２２】 前記目標として設定されるバッファ余
    裕は、ネットワークの状況に応じて変化させることを特
    徴とする請求項２１に記載のプロキシサーバ。
  23. 【請求項２３】 同一配信対象であるコンテンツのため
    の先読みを複数同時に実行することを特徴とする請求項
    ８から請求項１５の何れか一つに記載のプロキシサー
    バ。
  24. 【請求項２４】 同一配信対象であるコンテンツのため
    の先読みにおいて、それぞれ異なる部分の複数の要求と
    して先読みを同時に実行することを特徴とする請求項８
    から請求項１５の何れか一つに記載のプロキシサーバ。
  25. 【請求項２５】 ネットワークの輻輳を招かない範囲で
    同一配信対象であるコンテンツのための先読みを複数同
    時に実行することを特徴とする請求項８から請求項１５
    の何れか一つに記載のプロキシサーバ。
  26. 【請求項２６】 ネットワークの輻輳を招かない範囲で
    同一配信対象のための先読みにおいて、それぞれ異なる
    部分の複数の要求として同時に実行することを特徴とす
    る請求項８から請求項１５の何れか一つに記載のプロキ
    シサーバ。
  27. 【請求項２７】 コンピュータ上で実行され、コンテン
    ツの一部または全部を記憶装置に格納し、当該記憶装置
    からクライアントにコンテンツを配信しながら、該コン
    テンツの保持していない部分をオリジンサーバから取得
    して前記記憶装置に追加するプロキシ制御プログラムに
    おいて、 前記オリジンサーバからのコンテンツの取得レートを、
    ネットワーク状況又は前記コンテンツの受信バッファの
    状態の少なくとも一方に応じて制御する機能を有するこ
    とを特徴とするプロキシ制御プログラム。
  28. 【請求項２８】 コンピュータ上で実行され、コンテン
    ツの一部または全部を記憶装置に格納し、当該記憶装置
    からクライアントにコンテンツを配信しながら、該コン
    テンツの保持していない部分をオリジンサーバから取得
    して前記記憶装置に追加するプロキシ制御プログラムに
    おいて、 前記オリジンサーバからのコンテンツの取得に用いるプ
    ロトコルを、異なる帯域共有特性を持つ複数のプロトコ
    ルの中から、ネットワーク状況又は前記コンテンツの受
    信バッファの状態の少なくとも一方に基づいて選択する
    機能を有することを特徴とするプロキシ制御プログラ
    ム。
  29. 【請求項２９】 コンピュータ上で実行され、コンテン
    ツの一部をバッファに蓄積し、前記バッファからクライ
    アントにコンテンツを配信しながら、該コンテンツの現
    在のバッファへの蓄積位置より後続のコンテンツ部分を
    オリジンサーバから取得してバッファに追加するプロキ
    シ制御プログラムにおいて、 前記バッファに蓄積されているコンテンツの残り時間を
    検出し、前記残り時間が閾値以下になったタイミング
    で、該コンテンツの現在のバッファ蓄積位置より後続の
    前記コンテンツ部分を前記オリジンサーバから取得する
    機能を有することを特徴とするプロキシ制御プログラ
    ム。
  30. 【請求項３０】 コンピュータ上で実行され、コンテン
    ツの一部をバッファに蓄積し、該バッファからクライア
    ントにコンテンツを配信しながら、該コンテンツの現在
    のバッファ蓄積位置より後続のコンテンツ部分をオリジ
    ンサーバから取得してバッファに追加するプロキシ制御
    プログラムにおいて、 前記バッファに蓄積されているコンテンツの残り時間が
    指定された時刻に閾値以下になることを予測することに
    より、該コンテンツの現在のバッファ蓄積位置より後続
    のコンテンツ部分をオリジンサーバから取得する機能を
    有することを特徴とするプロキシ制御プログラム。
  31. 【請求項３１】 コンピュータ上で実行され、コンテン
    ツの一部または全部を記憶装置に格納し、該記憶装置か
    らクライアントにコンテンツを配信しながら、該コンテ
    ンツの保持していない部分をオリジンサーバから取得し
    て記憶装置に追加するプロキシ制御プログラムにおい
    て、 前記オリジンサーバからのコンテンツの取得に用いる送
    信レート制御機能を持つプロトコルを、異なる帯域共有
    特性を持つ複数のプロトコルの中から、ネットワーク状
    況と受信バッファの状態の少なくとも一方に応じて選択
    する機能を有することを特徴とするプロキシ制御プログ
    ラム。
JP2002054196A 2002-02-28 2002-02-28 プロキシサーバ及びプロキシ制御プログラム Expired - Lifetime JP4126928B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2002054196A JP4126928B2 (ja) 2002-02-28 2002-02-28 プロキシサーバ及びプロキシ制御プログラム
US10/228,925 US20030182437A1 (en) 2002-02-28 2002-08-28 Proxy server and proxy control program
CA 2399914 CA2399914A1 (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 true JP2003256321A (ja) 2003-09-12
JP4126928B2 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)

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007241621A (ja) * 2006-03-08 2007-09-20 Sony Corp 情報処理システム、情報処理方法、提供装置および方法、情報処理装置、並びにプログラム
JP2008177657A (ja) * 2007-01-16 2008-07-31 Oki Electric Ind Co Ltd ストリーム配信システム
US7496949B2 (en) 2005-11-04 2009-02-24 Nec Corporation Network system, proxy server, session management method, and program
JP2009534937A (ja) * 2006-04-21 2009-09-24 マイクロソフト コーポレーション ネットワーク・デバイスによる多数の輻輳制御アルゴリズムの実行を可能にすること
JP2010245612A (ja) * 2009-04-01 2010-10-28 Nec Corp データ処理装置、データ処理方法、及びプログラム
JP2013505682A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド 改良されたクライアント側処理のためにブロックパーティショニング又は要求制御を用いた拡張ブロック−要求ストリーミング
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US8887020B2 (en) 2003-10-06 2014-11-11 Digital Fountain, Inc. Error-correcting multi-stage code generator and decoder for communication systems having single transmitters or multiple transmitters
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9136983B2 (en) 2006-02-13 2015-09-15 Digital Fountain, Inc. Streaming and buffering using variable FEC overhead and protection periods
US9136878B2 (en) 2004-05-07 2015-09-15 Digital Fountain, Inc. File download and streaming system
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9191151B2 (en) 2006-06-09 2015-11-17 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9236885B2 (en) 2002-10-05 2016-01-12 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
US9237101B2 (en) 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
US9236976B2 (en) 2001-12-21 2016-01-12 Digital Fountain, Inc. Multi stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US9246633B2 (en) 1998-09-23 2016-01-26 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9264069B2 (en) 2006-05-10 2016-02-16 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient uses of the communications systems
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
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
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
JP2018500827A (ja) * 2014-12-19 2018-01-11 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データ伝送方法及び装置
JP7460569B2 (ja) 2021-03-05 2024-04-02 Kddi株式会社 コンテンツ配信ネットワークの転送装置及びプログラム

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1573454A2 (en) * 2002-06-11 2005-09-14 Ashish Pandya High performance ip processor for tcp/ip, rdma and ip storage applications
US7415723B2 (en) * 2002-06-11 2008-08-19 Pandya Ashish A Distributed network security system and a hardware processor therefor
US8046471B2 (en) * 2002-09-19 2011-10-25 Hewlett-Packard Development Company, L.P. Regressive transport message delivery system and method
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
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
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
US8739274B2 (en) 2004-06-30 2014-05-27 Citrix Systems, Inc. Method and device for performing integrated caching 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
US7606902B2 (en) 2004-07-23 2009-10-20 Citrix Systems, Inc. Method and systems for routing packets from an endpoint to a gateway
US9219579B2 (en) 2004-07-23 2015-12-22 Citrix Systems, Inc. Systems and methods for client-side application-aware prioritization of network communications
JP2006140841A (ja) * 2004-11-12 2006-06-01 Canon Inc 情報処理装置、サーバ装置、ネットワークシステム、データ通信方法、及びコンピュータプログラム
KR100631514B1 (ko) * 2004-12-16 2006-10-09 엘지전자 주식회사 실시간 스트리밍 서비스의 전송률 제어 방법
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
US8706877B2 (en) 2004-12-30 2014-04-22 Citrix Systems, Inc. Systems and methods for providing client-side dynamic redirection to bypass an intermediary
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
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
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
JP2007172389A (ja) * 2005-12-22 2007-07-05 Fuji Xerox Co Ltd コンテント配信装置
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
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
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
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
US20090016222A1 (en) * 2007-07-12 2009-01-15 Viasat, Inc. Methods and systems for implementing time-slice flow control
US20100146415A1 (en) * 2007-07-12 2010-06-10 Viasat, Inc. Dns prefetch
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
US8966053B2 (en) * 2007-07-12 2015-02-24 Viasat, Inc. Methods and systems for performing a prefetch abort operation for network acceleration
US20090077256A1 (en) * 2007-09-17 2009-03-19 Mbit Wireless, Inc. Dynamic change of quality of service for enhanced multi-media streaming
US8245287B2 (en) 2007-10-01 2012-08-14 Viasat, Inc. Server message block (SMB) security signatures seamless session switch
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 ソニー株式会社 通信装置、通信システム、プログラム、および通信方法
WO2011018868A1 (ja) * 2009-08-10 2011-02-17 日本電気株式会社 配信システム
US9450804B2 (en) * 2009-09-03 2016-09-20 At&T Intellectual Property I, L.P. Anycast aware transport for content distribution networks
US8892757B2 (en) * 2009-10-13 2014-11-18 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
US20120096144A1 (en) * 2010-10-18 2012-04-19 Nokia Corporation Method and apparatus for fetching data based on network conditions
US9325814B2 (en) * 2011-06-02 2016-04-26 Numerex Corp. Wireless SNMP agent gateway
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 富士通株式会社 情報処理システム、情報処理装置、及び情報処理プログラム
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 创新先进技术有限公司 流量控制系统、方法、装置及设备
EP4038852A1 (en) * 2019-09-30 2022-08-10 British Telecommunications public limited company Content delivery - setting the unicast rate

Family Cites Families (9)

* Cited by examiner, † Cited by third party
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

Cited By (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9246633B2 (en) 1998-09-23 2016-01-26 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US9236976B2 (en) 2001-12-21 2016-01-12 Digital Fountain, Inc. Multi stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US9236885B2 (en) 2002-10-05 2016-01-12 Digital Fountain, Inc. Systematic encoding and decoding of chain reaction codes
US8887020B2 (en) 2003-10-06 2014-11-11 Digital Fountain, Inc. Error-correcting multi-stage code generator and decoder for communication systems having single transmitters or multiple transmitters
US9236887B2 (en) 2004-05-07 2016-01-12 Digital Fountain, Inc. File download and streaming system
US9136878B2 (en) 2004-05-07 2015-09-15 Digital Fountain, Inc. File download and streaming system
US7496949B2 (en) 2005-11-04 2009-02-24 Nec Corporation Network system, proxy server, session management method, and program
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
JP2007241621A (ja) * 2006-03-08 2007-09-20 Sony Corp 情報処理システム、情報処理方法、提供装置および方法、情報処理装置、並びにプログラム
JP2009534937A (ja) * 2006-04-21 2009-09-24 マイクロソフト コーポレーション ネットワーク・デバイスによる多数の輻輳制御アルゴリズムの実行を可能にすること
US9264069B2 (en) 2006-05-10 2016-02-16 Digital Fountain, Inc. Code generator and decoder for communications systems operating using hybrid codes to allow for multiple efficient uses of the communications systems
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US11477253B2 (en) 2006-06-09 2022-10-18 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9628536B2 (en) 2006-06-09 2017-04-18 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9191151B2 (en) 2006-06-09 2015-11-17 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
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
JP2008177657A (ja) * 2007-01-16 2008-07-31 Oki Electric Ind Co Ltd ストリーム配信システム
US9237101B2 (en) 2007-09-12 2016-01-12 Digital Fountain, Inc. Generating and communicating source identification information to enable reliable communications
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
JP2010245612A (ja) * 2009-04-01 2010-10-28 Nec Corp データ処理装置、データ処理方法、及びプログラム
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
US9876607B2 (en) 2009-08-19 2018-01-23 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9660763B2 (en) 2009-08-19 2017-05-23 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US10855736B2 (en) 2009-09-22 2020-12-01 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
JP2013505682A (ja) * 2009-09-22 2013-02-14 クゥアルコム・インコーポレイテッド 改良されたクライアント側処理のためにブロックパーティショニング又は要求制御を用いた拡張ブロック−要求ストリーミング
US11743317B2 (en) 2009-09-22 2023-08-29 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
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
US11770432B2 (en) 2009-09-22 2023-09-26 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9992555B2 (en) 2010-06-29 2018-06-05 Qualcomm Incorporated Signaling random access points for streaming video data
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
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
US9602802B2 (en) 2010-07-21 2017-03-21 Qualcomm Incorporated Providing frame packing type information for video coding
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
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
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
JP2018500827A (ja) * 2014-12-19 2018-01-11 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データ伝送方法及び装置
US10560382B2 (en) 2014-12-19 2020-02-11 Huawei Technologies Co., Ltd. Data transmission method and apparatus
JP7460569B2 (ja) 2021-03-05 2024-04-02 Kddi株式会社 コンテンツ配信ネットワークの転送装置及びプログラム

Also Published As

Publication number Publication date
CA2399914A1 (en) 2003-08-28
JP4126928B2 (ja) 2008-07-30
US20030182437A1 (en) 2003-09-25

Similar Documents

Publication Publication Date Title
JP4126928B2 (ja) プロキシサーバ及びプロキシ制御プログラム
US9419907B2 (en) I/O driven rate adaptation
KR101582371B1 (ko) 잉여 네트워크 용량을 사용한 점진적 다운로드 시스템 및 방법
KR101071898B1 (ko) 네트워크 지연 제어
US8812673B2 (en) Content rate control for streaming media servers
US8190750B2 (en) Content rate selection for media servers with proxy-feedback-controlled frame transmission
US9043467B2 (en) Adaptive chunked and content-aware pacing of multi-media delivery over HTTP transport and network controlled bit rate selection
KR101099800B1 (ko) 미디어 서버로의 피드백 제공 방법
US7284047B2 (en) System and method for controlling network demand via congestion pricing
US8949452B2 (en) System and method for progressive download with minimal play latency
EP2665239B1 (en) An adaptive streaming aware networks node, client and method with priority marking
Agarwal et al. Adaptive multisource streaming in heterogeneous peer-to-peer networks
US20140344471A1 (en) Progressive Download Prioritisation
US8391292B2 (en) Systems and methods for dynamically adjusting QoS parameters
KR20080098020A (ko) 멀티플렉싱 및 대역폭 제어 기능을 갖는 신뢰가능한 이벤트브로드캐스터
JP4345828B2 (ja) プロキシサーバ及びプロキシ制御プログラム
US7830794B2 (en) Method and apparatus for improved isochronous data delivery over non-isochronous communication fabric
KR20150050085A (ko) 무선 환경에서 usb 통신을 위한 버퍼 관리 방법 및 장치
EP2388978B1 (en) Methods and devices for determining network link load
Sun et al. Predictive flow control for TCP-friendly end-to-end real-time video on the Internet
Ehtiba et al. Media Playout Techniques for Video Intra-Stream Synchronization: Review and Analysis
JP2013034101A (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
Smith Responsive vs. Unresponsive Traffic: Active Queue Management for a Better-Than-Best-Effort Service

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