(57)【要約】いくつかのデータストリームがそれぞれの伝送レートで伝送されるデータ伝送方法とシステムとを開示する。このレートは受信機内でデータバッファがオーバーフローを生じないよう制御される。いくつかの実施例では、受け側クライアント内の各バッファの状態に関する帰還データが、送り側サーバで受領されて、送り用レートを効果を達成するために適用するために使用される。各バッファのデータデコードレートもしくは充填度を示す情報が帰還データとしてサーバに向けて通信される。他の実施例では、サーバはバッファ内で残っている空間の開ループ推定を作って、それにより伝送レートを制御する。データ受領方法とシステムでデータストリームを受領するのに適応したものも開示される。【選択図】図３
2005503722.tif 000002
【特許請求の範囲】
【請求項１】
網をまたいでデータを伝送する方法であって：
データストリームの形態でデータ伝送レートで受信機に向けて伝送するために網上でデータを送る段階と；
該受信したデータが記憶される受信機のデータバッファの少くとも一つまたは複数の特性を判断する段階と；
該判断された一つまたは複数の特性に応答して該受信機内の該データバッファがオーバーフローとならないように該データストリームの該データ伝送レートを制御する段階とを備えた方法。
【請求項２】
請求項１記載の方法であって、該判断する段階はさらに：
データストリーム内で該受信機に向けて既に送られたデータの量を監視する段階と；
該受信機バッファに関して一つまたは複数のパラメータを記憶する段階と；
該監視されたデータと該記憶されたパラメータとに基づいて該一つまたは複数の特性を推定する段階とを備え、該推定する段階は該受信機データバッファの一つまたは複数の特性を示す該受信機からの繰返される帰還なしに開ループ方式で実行される方法。
【請求項３】
請求項１記載の方法であって、該判断する段階はさらに：
該受信機データバッファの該一つまたは複数の特性を示す該受信機からの帰還データを受領する段階を備え；
該制御する段階は該受領した帰還データに応答して、データ伝送レートを制御する方法。
【請求項４】
請求項１ないし請求項３のいずれか１項記載の方法であって：
該一つまたは複数の特性は少くとも該受信機で受領した該ストリーム内の該伝送されたデータの該デコード用レートを含み；該データストリームの該伝送レートは少くとも該受信機デコード用レートの関数としてさらに制御される方法。
【請求項５】
請求項１ないし請求項４のいずれか１項記載の方法であって、該一つまたは複数の特性は該バッファの該残っている容量を示す情報を含んでいる方法。
【請求項６】
請求項１ないし請求項５のいずれか１項記載の方法であって、さらに該データストリームが伝送されるべき最大伝送レートを計算する段階を備え、該制御する段階はさらに該伝送ビットレートが該計算された最大ビットレート内にあるように制御するように構成されている方法。
【請求項７】
請求項６記載の方法であって、該最大伝送レートは、該網上でのデータの平均スループットがトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同じとなるように計算される方法。
【請求項８】
請求項６または請求項７記載の方法であって、該計算する段階はさらに：
該受信機からラウンドトリップ時間値（ＲＴＴ）と、損失レート値と、該受信機における受信レート値のうちの少くとも一つを示す帰還データを受領する段階と；
該最大伝送レートを該帰還データによって示されたいくつかの該受領した値の関数として計算する段階とを含んでいて、該ラウンドトリップ時間はデータが送信機から受信機へ向けてさらに送信機に向けて戻る移動にかかる時間の測度であり；該損失レート値は該受信機まで送られたデータの失なわれた量の測度であり；また、該受信レート値は該ラウンドトリップ時間内に受領されたビット数である方法。
【請求項９】
請求項８記載の方法であって、最大伝送レートは下記により計算される方法：
【数１】
2005503722.tif 000009
ここでmaximum_rate_stream＝min(bit_rate_per_stream, 2×Receiving_Rate)であり、
data_medium_sizeは該ストリーム内で該網をまたいで送られる該データの平均サイズの測度であり、またｃは定数であって０．８７＜ｃ＜１．３１の範囲のものである。
【請求項１０】
請求項１ないし請求項９のいずれか１項記載の方法であって、さらにいくつかの受信機に向けての伝送のために該網上で複数のデータストリームを、各々をそれぞれのデータ伝送レートで、送る段階と；各ストリーム内の受信されたデータが記憶されているそれぞれのデータバッファの該少くとも一つまたは複数の特性を各ストリームについて判断する段階と；該データバッファがオーバーフローしないように該受信した帰還データに応答して各ストリームの該それぞれのデータ伝送レートを制御する段階とを備えた方法。
【請求項１１】
請求項６ないし請求項９のいずれか１項記載の方法に従属する請求項１０記載の方法であって、同じ該受信機に向けて送られた二つのストリームについて、各ストリームについてのそれぞれのデータ伝送レートが下記により制御される方法：
【数２】
2005503722.tif 000010
ここで変数は次の関係があるものとする；
sr_str_1：第一のデータストリームの送りレート
sr_str_2：第二のデータストリームの送りレート
tr：各ストリームについて計算した最大伝送レートの和
dr_str1：第一のデータストリーム内のデータの受信機におけるデコード用レート
dr_str2：第二のデータストリーム内のデータの受信機におけるデコード用レート
ｘ：第一のデータストリームからデータを受領する受信機の第一のバッファの充填用レートの係数
ｙ：第二のデータストリームからデータを受領する受信機の第二のバッファの充填用レートの係数。
【請求項１２】
請求項１ないし請求項１１のいずれか１項記載のデータ伝送方法を備えている網上でいくつかのデータストリームを生成する方法。
【請求項１３】
網をまたいでのデータ伝送用システムであって：
受信機に向けてデータストリームにおけるデータ伝送ビットレートで伝送するために該網上でデータを伝送するためのデータストリーム伝送手段と；
受信したデータが記憶される該受信機内のデータバッファの少くとも一つまたは複数の特性を判断するための特性判断手段と；
該受信機内の該データバッファのオーバーフローを回避するために該判断された特性に応答して該データストリームの該データ伝送レートを制御するデータストリーム制御手段とを備えたシステム。
【請求項１４】
請求項１３記載のシステムであって、該特性判断手段はさらに：
該データストリーム内で該受信機に向けてすでに送られた該データ量を監視するための監視手段と；該受信機バッファに関するいくつかのパラメータを記憶するための記憶手段と；該監視されたデータと該記憶されたパラメータとに基づいていくつかの特性を推定するための推定手段とを備えており；該推定手段は該受信機データバッファの該いくつかの特性を示す、該受信機からの繰返された帰還なしに開ループ方式で該推定を実行するように動作可能であるシステム。
【請求項１５】
請求項１３記載のシステムであって、該特性判断手段はさらに：
該受信機データバッファの該いくつかの特性を示す、該受信機からの帰還データを受領するためのデータ受領手段を備え；
該データストリーム制御手段は該受領した帰還データに応答して該データ伝送レートを制御するようにさらに動作可能であるシステム。
【請求項１６】
請求項１３ないし請求項１５のいずれか１項記載のシステムであって、該いくつかの特性は該受信機で受領した該ストリーム内で該伝送されたデータの該デコードレートを少くとも含み；また該データストリーム制御手段は少くとも該受信機デコードレートの関数として該データストリームの該伝送レートを制御するようにさらに動作可能であるシステム。
【請求項１７】
請求項１３ないし請求項１６のいずれか１項記載のシステムであって、該いくつかの特性は該バッファの残っている容量を示す情報を含むシステム。
【請求項１８】
請求項１３ないし請求項１７のいずれか１項記載のシステムであって、さらに、データストリームが伝送されるべき最大伝送レートを計算するための計算手段を備え、該データストリーム制御手段はさらに該伝送ビットレートを該計算された最大ビットレート内にあるように制御するよう動作可能であるシステム。
【請求項１９】
請求項１８記載のシステムであって、該計算手段はさらに該網上でのデータの平均スループットがトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同じとなるように最大伝送レートを計算するように動作可能であるシステム。
【請求項２０】
請求項１８または請求項１９記載のシステムであって、該データ受領手段はさらにラウンドトリップ時間値（ＲＴＴ）、損失レート値、及び該受信機における受信レートの少くとも一つを示す該受信機からの帰還データを受領するように構成されていて；また計算手段はさらに該帰還データにより示されたいくつかの受領された値の関数として該最大伝送レートを計算するように構成されていて；
該ラウンドトリップ時間は、データが送信機から受信機へ向けてさらに送信機に向けて戻る移動にかかる時間の測度であり；該損失レート値は該受信機に向けて送られたデータの失なわれた量の測定であり；また該受信レート値は該ラウンドトリップ時間内に受領されたビット数であるシステム。
【請求項２１】
請求項２０記載のシステムであって、該最大伝送レートは下記式により計算されるシステム：
【数３】
2005503722.tif 000011
ここで：maximum_rate_stream＝min(bit_rate_per_stream, 2×Receiving_Rate)であり、また、data_medium_sizeは該ストリーム内で該網をまたいで送られたデータの平均サイズの測度であり、またｃは定数であって０．８７＜ｃ＜１．３１の範囲のものである。
【請求項２２】
請求項１３ないし請求項２１のいずれか１項記載のシステムであって、いくつかの受信機に向けた伝送のために該網上で複数のデータストリームを、各々がそれぞれのデータ伝送レートで、送るための手段と；各ストリーム内での該受領したデータが記憶されているそれぞれのデータバッファの少くとも一つまたは複数の特性を各ストリームについて判断するための手段と；該データバッファのオーバーフローを防ぐために該受領した帰還データに応答して各ストリームのそれぞれのデータ伝送レートを制御するための手段とを備えたシステム。
【請求項２３】
請求項１８ないし請求項２１のいずれか１項記載のシステムに従属する請求項２２記載のシステムであって、同じ該受信機に向けて送られた二つのストリームについて、各ストリームについてのそれぞれのデータ伝送レートが下記式により制御されるシステム：
【数４】
2005503722.tif 000012
ここで変数は次の関係があるものとする；
sr_str_1：第一のデータストリームの送りレート
sr_str_2：第二のデータストリームの送りレート
tr：各ストリームについて計算した最大伝送レートの和
dr_str1：第一のデータストリーム内のデータの受信機におけるデコード用レート
dr_str2：第二のデータストリーム内のデータの受信機におけるデコード用レート
ｘ：第一のデータストリームからデータを受領する受信機の第一のバッファの充填用レートの係数
ｙ：第二のデータストリームからデータを受領する受信機の第二のバッファの充填用レートの係数。
【請求項２４】
計算機上での実行時に該計算機が請求項１ないし請求項１２のいずれか１項記載の方法を実行する計算機プログラムを記憶している計算機読取り可能記憶媒体。
【請求項２５】
網からデータを受領する方法であって、該データは請求項３、または請求項３に従属する請求項４乃至請求項１１記載の伝送方法により送られたものであるか、請求項１５、または請求項１５に従属する請求項１６乃至請求項２３記載のシステムにより送られたものであり、該方法は：
データ伝送レートでデータストリームを受領する段階と；
該データバッファの少くとも一つまたは複数の特性を測定する段階と；
該測定された特性を送信機に向けて送り、該送られたデータストリームについての伝送レートを計算での使用にあてる段階とを備えた方法。
【請求項２６】
請求項２５記載の方法であって、さらに：
デコード用レートで該バッファ内の該データをデコードする段階を備え；
該デコード用レートは該測定された特性の少くとも一つとして該送信機に向けて送られる方法。
【請求項２７】
請求項２５または請求項２６記載の方法であって、該一つまたは複数の特性は該バッファの残りの容量を示す情報を含んでいる方法。
【請求項２８】
請求項２５ないし請求項２７のいずれか１項記載の方法であって、さらにラウンドトリップ時間値（ＲＴＴ）、損失レート値、及び受信レート値の少くとも一つを計算する段階と、該計算した値を該送信機に向けて戻す段階とを備え；該ラウンドトリップ時間は送信機から受信機に向けさらに該送信機に向けて戻る移動をするデータの所要時間の測度であり；損失レート値は受信機に向けて送られたデータの失なわれた量の測定であり；また受信レート値は該受信機により該ラウンドトリップ時間内で受領されたビット数である方法。
【請求項２９】
請求項２８記載の方法であって、該損失レートはｎ個の最新の損失間隔についての重み付けしたフィルタを用いて計算され、二つの損失事象間で受領されたデータの出力となっている方法。
【請求項３０】
網からデータを受領するシステムであって、該データは請求項３もしくは請求項３に従属する請求項４ないし請求項１１のいずれか１項記載の伝送方法によるか、または請求項１５もしくは請求項１５に従属する請求項１６ないし請求項２３のいずれか１項記載のシステムにより送られたものであり、該方法は：
データストリームをデータ伝送レートで受領するためのデータ受領手段と；
バッファ動作用のデータバッファに向けて該受領したデータを送るデータバス手段と；
該データバッファの少くとも一つまたは複数の特性を測定するためのバッファ監視手段と；
該測定された特性を送信機に向けて送り、送られたデータストリームについて該伝送レートを計算するのに使用するのにあてるデータ伝送手段とを備えたシステム。
【請求項３１】
請求項３０記載のシステムであって、さらにデコード用レートで該バッファ内の該データをデコードするためのデコード手段を備え、該データデコード用レートは少くとも一つの該測定された特性として該送信機に向けて送られるシステム。
【請求項３２】
請求項３０または請求項３１記載のシステムであって、該いくつかの特性は該バッファの残っている容量を示す情報を含むシステム。
【請求項３３】
請求項３０ないし請求項３２のいずれか１項記載のシステムであって、さらにラウンドトリップ時間値（ＲＴＴ）、損失レート値、及び受信レート値の少くとも一つを計算するための計算手段を備え；該データ伝送手段はさらに該計算された値を該送信機に向けて送り戻すように動作が可能であり；該ラウンドトリップ時間はデータが送信機から受信機に向けてさらに該送信機に戻る移動の所要時間の測度であり；該損失レート値は受信機に向けて送られたデータの失なわれた量の測度であり；また該受信レート値は該ラウンドトリップ時間で該受信機により受領されたビットの数であるシステム。
【請求項３４】
請求項３３記載のシステムであって、該損失レートはｎ個の最新の損失間隔の重み付けフィルタを用いて計算され、二つの損失事象間で受領されたデータ出力であるシステム。
【請求項３５】
計算機読取り可能記憶媒体であって計算機プログラムを記憶し、このプログラムは、計算機上で実行するときには、請求項２５ないし請求項２９のいずれか１項記載の方法を実行するために計算機を制御する媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ通信を提供する方法とシステムに係り、とくに一または複数のデータストリーム（streams）を網をまたいで送るための方法とシステムとに関するものであり、また併せてこのような送られたデータを受信するための方法とシステムとにも関係している。さらに、この発明はまた計算機読取り可能記憶媒体にも関係していて、この媒体は計算機プログラムを記憶し、このプログラムは計算機上での実行時には計算機を制御して、上述のデータの送りと受けとの方法を実行する。
【背景技術】
【０００２】
近年、データ通信用遠隔通信網の数、拡がりまた使用者数におびただしい増加が見られる。以前には、このような遠隔通信網上で搬送されるデータトラヒックの大部分の特性は実質的に“メッセージベース（message-based）”のものであった。ここで“メッセージベース”と言う意味は網上で伝送されるデータは、例えば電子メールメッセージ、転送されているプロセス内のファイル、あるいはクライアント・サーバシステム間で送られている他の応用(application)データの一部として形成されていることを言う。このような“メッセージベース”のデータの主要特性はそれが特に時間にクリティカルなものでないものであって、データは受信機端末にある伝送時間内にどんな使用であれ到達しなければならないというのではないことである。むしろ、合理的な時間量のうちに受信機にデータが到達するのであれば、終局的にはユーザに使用できるというものである。以前に知られていたこのような“メッセージベース”のデータの例は、例えば標準の電子メールとファイルであって、ファイル転送プロトコル（ＦＴＰ）を用いて転送されるものである。
【０００３】
もっと最近になると、関心は伝統的なメッセージベースデータを送るデータ通信網の能力から離れて、送信機から受信機に向けて連続するデータストリームの中でデータを送ることができる網と関係装置とに向っている。しばしば、このようなデータの価値が時間にクリティカルであって、網はこのデータを送信機から受信機端末までできるだけ滑らかにしかも早く輸送しなければならず、好ましいのはデータの再送の必要がないようにすることである。このようなデータストリーミングシステムの例で先行技術で知られているものが図１に関して次に記述されている。
【０００４】
普通は、ストリームとされるデータはマルチメディアデータであり、例えば、オーディオとビデオデータである。このオーディオとビデオデータとは、ニュースとかスポーツイベントといったライブのオーディオ・ビジュアル放送からのものであってもよいし、あるいは例えばビデオ・オン・デマンドサービスであって、加入者がその者の選択によりまた選んだ時にテレビジョンプログラムとフィルムとを見ることができるものをソースとするものでもよい。しかしながら、データのソースが何であっても、網上での伝送に適したサイズに該オーディオ及びビデオデータ信号を圧縮するために、それぞれのオーディオとビデオ供給(feed)データは先ずデジタル符号化に適したものでなければならず、普通はオーディオ及びビデオ符号化は各種のＭＰＥＧ規格の一つに従って実行される。
【０００５】
オーディオ及びビデオデータの符号化に続き、符号化された(encoded)データは網サーバを通過して、そこで網上でクライアントに向けた伝送の前に分離されたオーディオ及びビデオバッファに記憶される。
【０００６】
バッファ動作に続いて、データは、後に後述するように網上で送られて、受信機で受領され、デコード(decoding)前にそこでバッファされる。デコード動作は受信機で適切なデコーダにより実行されて、このデコードされたデータは受信機で実行中のアプリケーションに再生のために送られる。
【０００７】
現在使用されている網の最も普通の形式の一つはもちろんインターネットを形成するものであり、これはインターネットプロトコル（ＩＰ）を用いて該網の網(network)レイヤ（layer）内のＩＰデータグラムの形式でデータを転送する。この網レイヤ上でのデータトランスポートはトランスポートレイヤプロトコルである伝送制御プロトコル(transmission control protocol)（ＴＣＰ）とユーザデータグラムプロトコル(user datagram protocol)（ＵＤＰ）とによって提供される。ＴＣＰとＵＤＰとの両方は当業者に既知のものであり、例えばTannenbaum, A.S.,“Computer Network”第三版. Prentice Hall, pp521〜542に記述されている。
【発明の開示】
【０００８】
しばしば、ＵＤＰは網上でのデータサービスのストリーミングに使用されて来ており、とくにオーディオ及びビデオデータのストリーミングに使用されてきた。しかしながら、ＵＤＰは無接続のトランスポートプロトコルであり、したがってサービス品質制御機構とかユーザに対して保証されるべきサービスについての特定品質を許容する能力とかを提供することは何もない。
【０００９】
さらに、データのストリーミングにＵＤＰを使用することは別な問題の原因となっており、その理由は、ＵＤＰの使用がいつも同じ伝送レートでデータを送り出すので、網の輻輳状態についてもあるいは受信端末での受信したデータのバッファの状態にも何ら考慮していないことにある。これが容易にパケット損失をもたらし、したがってデータの損失の結果を生じている。即ち、データストリーミング用にＵＤＰを用いて、そこで網輻輳が生ずる事象にあってはＵＤＰは同じ伝送レートでデータパケットを送り続けることになり、それによって網の輻輳に寄与することになる。最悪の場合で網輻輳を排除するための機構が何もないときには、その結果はデータ流のパケットの多くがあるいは全部が喪失してしまうことになり得る。同じように、ストリームのデータ伝送レートが受信機バッファが空にされるレートよりも高いという事象では、該バッファはオーバーフローすることになり、それによってパケット損失に対する別の機構を与えることになる。このような場合における有害な効果は二重に恐ろしいものであり、受信機がオーバーフローしたデータを失なってしまうだけでなく、実時間マルチメディアの場合には貧弱な品質の再生をもたらすばかりか、網は宛先で失なわれるオーバーフローするパケットを送るという帯域幅を損失することになる。
【００１０】
データストリーミングについてのＵＤＰの使用と関係する上述の問題は、網トランスポートプロトコルとしてＴＣＰを用いることによって僅かながら軽減されることができる。ＴＣＰは接続指向のプロトコルであり、送り側端末に向けてパケットの受領告知（acknowledgements）を提供し、送り側端末はデータの伝送レートを越えた制御の増加量を許容する。より特別なこととして、ＴＣＰは網の輻輳について勘案するために伝送レート制御アルゴリズムを組入れている。これはibid ｐｐ５３６〜５３９において、ＴＣＰ伝送制御アルゴリズムは“加算的な増加と乗算的な減少（additive-increase-multiplicative-decrease）”として知られているところであり、ここでは、基本となるしきい値伝送レートに到達すると、伝送レートがその後は加算的なやり方でパケット毎に増加されて、パケット損失が生ずるまで行なわれ、そこで伝送レートは乗算的なやり方で、例えば伝送レートを半分に除算することによって減少される。ＴＣＰ伝送レートアルゴリズムは、それ故に網輻輳を勘案して、パケット損失が発生するときにはデータストリームの伝送レートを減らすこととするが、この減少の乗算的な本質は網上でのデータスループットの変化は極めて大きくなることができることを意味している。
【００１１】
図２はＴＣＰを用いたデータスループットの例を示しており、データ伝送レートは時間に関してかなり変化できることをここから見ることができる。比較的大きな変動がＴＣＰを用いる伝送レートにあることは、データストリーミング応用（application）に特に適したものでないことを意味し、データストリーミング応用（application）では時間に関して滑らかに変る定常的な伝送レートが好ましいとされる。さらに、ＴＣＰ伝送レート制御アルゴリズムは受信機のバッファ状態に何らの注意も払わないので、それによりここでもまたＴＣＰストリーム伝送レートが受信機におけるデコードレートよりも大きくならなければならないとするとパケット損失の可能性を誘起する。ＵＤＰの場合と同様に、宛先でのパケットの損失は二つの危険をもった有害な効果を表わしていて、単に受信機がオーバーフローデータを失い、実時間マルチメディアの場合には貧弱な品質の再生をもたらすだけでなく、宛先で失われたオーバーフローパケットの伝送に網が帯域幅を浪費したことになる。
【００１２】
データをストリーミングするためにＴＣＰを用いてのデータ伝送レートでの頻繁な変化と関係した問題は、複数のデータストリームが例えばオーディオとビデオとのデータといった関係しているデータを同時に送らねばならないときにさらに複合化される。この場合に、ＴＣＰを用いしかも例として別個のデータストリームの中でオーディオとビデオとのデータを伝送するときには、オーディオストリームはビデオストリームとは別個のＴＣＰ接続上で伝送されるから、このときは各それぞれの接続は自己の伝送レート制御アルゴリズムを適用し、他のストリームの伝送レートには注目することがない。これは、時間にわたって見ると、網上でのオーディオストリームのデータスループットが実質的にビデオストリームのものと同じになるという結果的な効果を有するのではあるが、そうであっても、大部分のオーディオビジュアルソースについては、現実として、単位時間についてオーディオデータよりもかなり多くの送られるべきビデオデータがあるのが普通である。こうしてＴＣＰにより達成されたオーディオとビデオのストリーム間の伝送レートのこの等価性は、データについての適切な再生に影響を与えるという受信機での効果をもつことが可能となり、この効果では、二つの形式のデータがオーディオとビデオデータの生成の比と整合のとれたそれぞれのレートで送られないことが原因となって、オーディオビジュアル応用（application）による再生のために受信機オーディオバッファ内に記憶された十分なオーディオデータが普通は存在しているのに対し、オーディオデータと同時に再生するためには、受信機ビデオバッファ内に不十分なビデオデータしか存在しないことになる。
【００１３】
各それぞれのストリームに対して伝送レート制御アルゴリズムの別個な適用からは、とくに標準のＴＣＰ伝送レート制御アルゴリズムのもつ乗算式の減少という本質からは別の問題が生ずる。オーディオストリームがＴＣＰ接続上でビデオストリームに対するのとは別に送られている場合を考えるとする。このビデオストリームもＴＣＰを用いて送られているとする。通常は、先に説明したように、各接続の平均のスループットは実質的に同じとなるが、ストリームの一つについてパケット損失が発生する伝送レートでの乗算的な減少に起因して、いずれかの時間的な瞬間に事実上二つのストリームについてのそれぞれの伝送レートにおける大きな差異があり得ることになる。二つのストリーム間で伝送レートに存在するこういった潜在的な大きな短期間の変動がデータ伝送に不確定さをもたらし、かつ受信機内のデータバッファについての問題を生じさせることができて、一時的に大きな差異が生ずることは、例えばオーディオバッファが一杯となってオーバーフローして、それによりデータを失い、それでもなお対応するビデオバッファは空となっていて、それによりＡＶ再生が行なわれるのを妨げることになる。
【００１４】
ＴＣＰ伝送レート制御アルゴリズムを複数のデータストリームに適用することによって生ずるといった上記の問題は、各ストリームについて無接続のＵＤＰプロトコルを用い、かつ単純に各ストリームを適当な転送レートで送ってストリーム間でデータの正しい比を維持するようにすることによって以前に対応されているところである。しかしながら、前記のように、ＵＤＰは伝送レートを制御して受信機バッファの状態を勘案するような備えを何もしていない。したがって、受信機における不必要なパケット損失を防ぐために受信機内でのバッファの状態をなお勘案している間に依然として各ストリームの伝送レートの両方の安定性を維持できる伝送レート制御方法とシステムの必要性はなお存在しているところである。
【００１５】
発明の概要
この発明は網サーバが受信機バッファの状態を判断するようにデータ伝送の方法とシステムとを提供することにより前記問題に対処するものである。サーバはそこでデータ伝送ビットレートでデータストリームを送り、ストリームのデータ伝送レートを制御して、受信機バッファがオーバーフローから妨げられるようにする。伝送レートの制御はまたデータストリームについてのスムースな定常状態伝送レートに与える効果を有している。受信機バッファ状態の判断は開または閉ループ方法で実行される。
【００１６】
このような観点にたって、この発明による第一の特徴から、網をまたいだデータ伝送方法が提供され、該方法は：
データストリームの形態でデータ伝送レートで受信機に向けて伝送するために網上でデータを送る段階と；
該受信したデータが記憶される受信機内のデータバッファの少くとも一つまたは複数の特性を判断する段階と；
該判断された特性に応答して該受信機内の該データバッファがオーバーフローとならないように該データストリームの該データ伝送レートを制御する段階とを備えている。
【００１７】
第二の特徴からは、この発明では網をまたいでのデータ伝送用システムが提供され、該システムは：
受信機に向けてデータストリーム内でデータ伝送ビットレートで伝送するために該網上でデータを伝送するためのデータストリーム伝送手段と；
受信したデータが記憶される該受信機内のデータバッファの少くとも一つまたは複数の特性を判断するための特性判断手段と；
該受信機内の該データバッファのオーバーフローを回避するために該判断された特性に応答して該データストリームの該データ伝送レートを制御するデータストリーム制御手段とを備えている。
【００１８】
受領したストリーム内のデータが記憶されている受信機内のデータバッファのいくつかの特性を判断することによって、この発明はデータ伝送レートが制御できるようにし、その制御のやり方はバッファのオーバーフローに起因して受信機でのパケットが損失しないようにしている。このことは網帯域幅利用が改良されるという利点をもたらしており、その理由は、先ずはバッファのオーバフローによるデータの損失があろうはずはなく、何らかの失なわれたデータのパケットが存在するときに再送信をする必要がないからである。さらに、例えば実時間データの場合に、データ再送は通常必要とされておらず、実時間データの再生はより滑らかなやり方で処理され、しかも意図した再生品質で行うことができる。
【００１９】
特性判断は開ループもしくは閉ループであってもよい。とくに、この判断が開ループであるときは、サーバはどのくらいの数のパケットを受信機に向けて送ったかと、これらのパケットのデコードレートはどんなものかについての追跡を単に維持するだけでよい。先に受信機バッファのサイズを知ることにより、サーバは受信機バッファ内にどのくらいの空間が残っているかの推定を維持できて、それにより伝送レートを調節することができる。
【００２０】
特性判断が閉ループのときは、受信機はいくつかの特性を示す情報をサーバに向けて送り、サーバは受領した情報を伝送レート制御の基礎として使用する。
【００２１】
好ましくは、いくつかの（one or more）特性が、受信機のところでの、ストリームの中に送られたデータについてのデコード用レートを少くとも含み、データストリームの伝送レートが少くとも該受信機のデコード用レートの関数としてさらに制御される。データストリームの伝送レートをデコード用レートとリンクすることによって、安定な定常状態の伝送を送信機から受信機に向けて達成することが可能となり、これが実時間データのストリーミングにとって特に適切なものとなる。
【００２２】
別の実施例では、データバッファのいくつかの特性はバッファの残っている容量を示す情報を含んでいる。この残っている容量を判断することによって、連続的かステップ状の変化を適当に伝送レート内で実効あるものとすることが可能であり、例えば伝送されたデータをより低品質でエンコードされたデータに変えることにより実効あるものとすることが可能であるから、それにより同じ情報を再生するのにより少いバッファ容量を必要とすることになる。
【００２３】
他の好ましい実施例では、この方法はさらにデータストリームが送られなければならない最大伝送レートを計算する段階を備えていて、伝送ビットレートが計算された最大レート以内となるように制御される。
【００２４】
網の輻輳を勘案して求められた伝送レート式を用いて、ストリームについての最大伝送レートを計算することによって、網の一部での輻輳を説明するためにストリームの最大伝送レートを制御することが可能でありこの網の一部に向けてストリームがルート設定されていてそれによって、また他のパケット損失機構のインパクトを最少とすることとなる。
【００２５】
好ましくは最大伝送レートが網上での平均データスループットがトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同じものになるように計算され、データストリームは“ＴＣＰフレンドリィ”と呼ばれることができるものである。伝送レート制御方式を用いることにより（この方式はＴＣＰフレンドリィである）、伝送レートが網輻輳を勘案するために制御できるという利点が得られるとともに、網内部での他の競合するＴＣＰ接続を受入れるという利点が得られる。
【００２６】
好ましくは、この方法がさらに複数のデータストリームを受信機に向けた伝送のため網上でそれぞれのデータ伝送レートで伝送する段階を含んでいて；また受領したデータストリームが記憶されるそれぞれのデータバッファの少くとも１又はいくつかの特性を判断する段階と；データバッファがオーバーフローするのを防ぐために、受領した帰還データに応答して、各ストリームのそれぞれの伝送レートを制御する段階とを備えていることである。
【００２７】
上記したところにより、この発明はまた、ある送信機からいくつかの同一でもまた異っていてもよい受信機に向けて複数のデータストリームを伝送することに応用を有している。
【００２８】
好ましくは、伝送されたデータストリームはオーディオまたはビデオデータを含んでいる。二つのデータストリームは同時に送られる場合には、好ましくはストリームの一方はオーディオデータを含み、ストリームの他方はビデオデータを含んでいる。好ましくはオーディオとビデオとのデータとは受信機のところで同時に再生されることが意図されている点で関係していて、例えば、ビデオデータがＴＶプログラムまたはフィルムであり、かつオーディオデータがそのサウンドトラックである場合である。この発明は、ストリームの中でオーディオとビデオとのデータの伝送をとくに意図されていて、各ストリームの送り用レートはこの発明により制御されて、実質的にスムースなものとされ、また受信機バッファをオーバーフローから防ぐようにしている。好ましくは、送り用レートは受信機バッファからの読取りレートと整合するように制御されていることである。
【００２９】
好ましくは、この発明はさらに帰還データを特定または各受信機から受領するように構成されており、ラウンドトリップ時間（ＲＴＴ）、損失レート値、及び／又は受信用レート値で受信機におけるもののいくつかを示しているデータであり、またさらに、帰還データによって示された受領された値のいくつかの関数として全伝送レートを計算するようにも構成されている。ラウンドトリップ時間は送信機から受信機に至りさらに該送信機に戻るのにデータがかかる時間の測度であり、また損失レート値は網内で失われた受信機に向けて送られたデータの量の測度である。受信レート値はラウンドトリップ時間内に受信機により受領されたビットの数である。
【００３０】
受信機からのサーバに向けた帰還を提供することによって、例えばパケット損失をもたらす網の輻輳状態を示しているデータの情報をサーバに提供することが可能である。サーバはそこで網での現在の状態に依存してストリームについて利用可能な最大伝送レートを計算できるようになり、それによってストリームが伝送される伝送レートを最適化する。
【００３１】
さらに、第三の特徴からは、本発明は計算機読取り可能記憶媒体であって計算機プログラムを記憶するものを提供し、このプログラムは計算機上で実行されるときには、この発明の第一の特徴に従った方法を実行するように計算機を制御する。
【００３２】
好ましくは、この計算機読取り可能記憶媒体は、光ディスク、磁気ディスク、磁気・光ディスク、固体(solid)状態計算機メモリ、あるいは他の適切なデータ記憶媒体のいずれかである。
【００３３】
第四の特徴から、この発明は網からのデータを受領する方法も提供し、このデータはすでにこの発明の第一または第二の特徴に関して記述した方法とシステムにより送られたものであり、該方法は：
データ伝送レートでデータストリームを受領する段階と；
該受領したデータをバッファする目的でデータバッファに送る段階と；
該データバッファの少くとも一つまたは複数の特性を測定する段階と；
該測定された特性を送信機に向けて送り、該送られたデータストリームについての伝送レートを計算での使用にあてる段階とを備えた方法である。
【００３４】
データバッファの特性を送信機に向けて送り戻すことによって、この送信機はそのデータ伝送レートを制御して受信機内のデータバッファがオーバフローすること及びデータが損失することを防ぐようにすることが可能となる。
【００３５】
好ましくは、第四の特徴で、この方法がさらにデータバッファ内のデータをデコード用レートでデコードする段階と、少くとも一つの測定された特性として受信機に向けてデータデコード用レートを送る段階とを備えていることである。データデコード用レートを送信機に向けて通信することにより、送信機にとってはその伝送レートを制御して安定した定常状態伝送レートを達成することが可能となり、しかもその際にこのデコード用レートは実質的に伝送レートと整合がとれていて、好ましくは網でのパケット損失も勘案されているものとする。
【００３６】
さらに、好ましくは、いくつかの特性がさらにバッファの残っている容量を示している情報を含むことである。この情報を送信機に向けて通信することにより、送信機はさらにデータストリームの伝送レートをレートのステップ状変化を用いて制御することができ、バッファのオーバーフローを防ぐために緊急測度としてレートのステップ状変化が使用される。
【００３７】
第五の特徴から、本発明はまた網からデータを受領するためのシステムを提供し、このデータはこの発明の第一または第二の特徴の方法かシステムによって送られたものである。第五の特徴ではこのシステムは：
データストリームをデータ伝送レートで受領するためのデータ受領手段と；
バッファ動作用のデータバッファに向けて該受領したデータを送るデータバス手段と；
該データバッファの少くとも一つまたは複数の特性を測定するためのバッファ監視手段と；
該測定された特性を送信機に向けて送り、送られたデータストリームについて該伝送レートを計算するのに使用するのにあてるデータ伝送手段とを備える。
【００３８】
この発明の第五の特徴は第四の特徴に関して前記したのと同じ特徴と利点と、また別の特徴と利点とを表わしている。
【００３９】
さらに、第六の特徴から、この発明は計算機プログラムを記憶する、計算機読取り可能記憶媒体を提供し、この計算機プログラムは計算機上での実行時に、この発明の第四の特徴による方法を実行するように計算機を制御する。第三の特徴の場合のように、第六の特徴によるこの発明は、磁気ディスク、光ディスク、磁気・光ディスク、固体状計算機メモリ等のいずれか一つまたは複数のもので実施されてよい。
【００４０】
この発明の別な特徴と利点とは、以下の実施例の記述で明らかにされるが、記述は例としての目的に限定して、添付の図面を参照して行なわれる。
【発明を実施するための最良の形態】
【００４１】
この発明の三つの好ましい実施形態を構成している各種の要素の構造と動作とを図３〜１３を参照してここで記述して行く。ここで記述する好ましい実施形態はこの発明の非限定的な適用の例をオーディオとビデオデータのようなマルチメディアデータの伝送に対してしたものであるが、本発明はほとんどどんな適用にも用途が見付けられるものであり、この適用ではいくつかのデータストリームが網上で伝送されることに注目すべきである。
【００４２】
この記述では、“送信機”と“サーバ”という用語は交換性のあるものとして使用されており、“受信機”と“クライアント”という用語についても同様である。
【００４３】
この発明の各実施形態でここでこれから記述するものは同じシステム要素を利用してよいが、その程度は異なり、また動作方法に差異があることになる。その結果として、各実施例で使用されてよい装置の普通の記述が続くことになり、その後に各実施例の動作についての別個の記述が続くことになる。
【００４４】
この発明の好ましい実施例のシステムを形成している二つの基本要素が図３に示されている。ここでサーバ４０が提供されているのを見ることができ、ここには第一のビデオバッファ４２と第二のビデオバッファ４３とが備えられている。第一のビデオバッファ４２はエンコードされたビデオデータを記憶するように構成されていて、このビデオデータは第一のビデオエンコード用レートで符号化されており、また第二のビデオバッファ４３は第二のエンコード用レート（このレートは第一のバッファ４２内に記憶されたエンコードされたビデオデータのレートより低い）でエンコードされた、第一のものよりも多いエンコードされたデータを記憶するように構成されている。二つのバッファ４２，４３内に記憶されたエンコードされたビデオデータは同じオリジナルデータから得られたものであるが、異なるエンコードされたビデオデータを与えるために異なるエンコード用レートを用いて符号化されたにすぎないことを理解されたい。一般に、第一のバッファ４２内に記憶された符号化されたビデオデータを生成するために使用される高い方のエンコード用レートが原因となって、第一のバッファ４２内のエンコードされたビデオデータは、第二のビデオバッファ４３内に記憶された低い方のエンコード用レートでエンコードされた対応するエンコードされたビデオデータよりも大きなサイズをもっている。好ましいのは、ビデオデータはＨ．６２３エンコーデングを用いて符号化されているが、いずれもの適したビデオ符号化技術も使用できるのであって、その中にはＭＰＥＧなどがあることを理解されたい。
【００４５】
またサーバ４０の中に用意されているものに、オーディオデータバッファ４４があり、これがエンコードされたオーディオデータを記憶するために用意されている。気付いてほしいのは、好ましい実施例では、オーディオデータは単一のエンコード用レートで符号化されるだけであり、したがって、単一のオーディオバッファだけが求められる。好ましいオーディオデータはＡＭＲオーディオエンコーデングを用いて符号化されるが、ＭＰ３などのような他のいずれかの適当なオーディオ符号化技術も使用できる。
【００４６】
サーバ４０とともに、この好ましい実施例では、いくつかのクライアント計算機５０も用意されている。図３は明瞭にするために単一のクライアントを示しているが、サーバにとっては複数のクライアントにサービスすることは可能であり、また複数のデータストリームが各クライアントに向けて送られるようにすることが可能である。実施例では、各クライアントはビデオバッファ５２とオーディオバッファ５４とを備えている。ビデオバッファ５２はサーバ４０から受領したエンコードされたビデオデータを受領して記憶するように構成されている。ビデオバッファ５２は受領したエンコードされたビデオデータを記憶するが、これはクライアント計算機内に用意されたビデオデコーダがエンコードされたビデオデータをそこから読取って、そこでエンコードされたビデオ信号のデコードと再生にあてるまで記憶する。同じように、オーディオバッファ５４はサーバ４０から送られた、エンコードされたオーディオデータを受領して、このエンコードされたオーディオデータを、クライアント計算機内に用意されたオーディオデコーダがエンコードされたデータを読取ってエンコードされたオーディオ信号のデコードと再生にあてるまでバッファする。
【００４７】
サーバ計算機と特定の又は各クライアント計算機との間でデータ通信を提供するために、第一のユーザデータグラムプロトコル（ＵＤＰ）接続１０がサーバ４０と特定の又は各クライアント５０との間に提供されて、この接続を介してエンコードされたビデオデータがサーバ４０から送られる。同じように、第二のＵＤＰ接続２０もまたサーバ４０から特定の又は各クライアント５０に向けて提供されて、この接続を介してエンコードされたオーディオデータが送られる。それぞれのＵＤＰ接続１０，２０の伝送レートはこの発明の各実施例について後述される方法でサーバによって制御される。
【００４８】
サーバと特定の又は各クライアントとの間のＵＤＰ接続に加えて、第1と第２の実施例ではトランスポート制御プロトコル（ＴＣＰ）接続３０が特定の又は各クライアントとサーバとの間に設定されて、制御メッセージの伝送を与えるようにしている。この制御メッセージは主として特定の又はクライアントからサーバーに向けて戻されるもので、二つのＵＤＰ接続１０と２０の伝送レートの実効的な制御ができるようにする。帰還データで各クライアントから、各実施例について、ＴＣＰ接続上でサーバに向けて送られるものの詳細については後述する。
【００４９】
ここで図４を見ると、図４はサーバ計算機４０内部でこの発明の好ましい実施例で必要とされる要素をブロック図形式で示している。図４はこの発明の実施例少なくとも一つについての動作に必要とされているサーバの部品だけを示していること、また動作に必要とされるサーバシステムの他の要素は示していないことに留意されたい。ここでは、意図された読者は当業者であって、サーバシステムについてのそれが全操作を実行するのに必要としている追加の要素が何であるかを認識する者であるとしている。
【００５０】
好ましい実施例では、サーバ計算機４０は、マルチメディア応用（application）制御器４１を備え、これがエンコードされたオーディオデータとエンコードされたビデオデータとを受領し、そこで受けたデータをバッファ４２，４３，４４内にバッファように、図３に関して前記したように構成されている。留意してほしいのは、こういったバッファは明りょう化のために図４では示されていないことである。マルチメディア応用制御器４１は制御メッセージをＴＣＰ接続３０を介してクライアント計算機５０との間で送受する。さらに、マルチメディア応用制御器はエンコードされたビデオデータとエンコードされたオーディオデータとを適当なバッファから網接続モジュール４７に向けて提供し、モジュール４７は網をまたいでクライアント計算機に向けた伝送のためにデータをパケット化する。したがって、網接続モジュール４７はエンコードされたオーディオとビデオデータとをマルチメディア応用制御器から受領するように動作し、このデータを伝送に適した形態にパケット化して、このデータパケットを二つのそれぞれのＵＤＰデータストリーム内で、適切とされるそれぞれの送りレートで網に向けて送る。データストリームのそれぞれの送り用レートは送り用レート計算器４６により適当な伝送レート式（各実施例について後述する）により計算される。送り用レート計算器４６はオーディオとビデオのデータストリームについての計算された送りレートを網接続モジュール４７に向けて送り、網接続モジュール４７に計算された伝送レートについて通知するようにしている。第1と第２の実施例では、送り用レート計算器４６で計算された伝送レート式に向けた入力データはクライアント計算機からマルチメディア応用制御器に向けたＴＣＰ接続上で得られていて、この制御器から適当な接続を経由して送り用レート計算器に向けてデータが送られる。
【００５１】
網制御器モジュール４８はさらに、網接続４７を制御するために用意されていてオーディオとビデオとのデータが網上で送られるようにするために適切なデータのパケット化プロセスを実行する。
【００５２】
さらに、再伝送バッファ４９はメモリなどであり、これが与えられていて、網接続４７から適切な制御信号と一緒にデータパケットを受領し、受領したデータパケットをバッファして、このバッファしたパケットを網接続４７が再送しなければならない事象に備えるように構成されている。送られたデータパケットのバッファ動作と再送動作とはこの発明にとって特有のものではないのでこれ以上の詳細についてはここではふれない。
【００５３】
図４に示されてはいないが、さらに次のことについては留意されたい。サーバ計算機４０はさらに少くとも一つの計算機読取り可能記憶媒体を含んでいて、これが計算機プログラムを記憶し、このプログラムがこの発明を実施するためにサーバ計算機の動作を制御する。計算機読取り可能記憶媒体は既知のいずれの形式のものでもよく、とくに、光ディスク、磁気ディスク、磁気・光ディスク、固体計算機メモリ、あるいは他の適当なデータ記憶媒体のうちの一つまたは何らかの組合せから形式されるものでよい。
【００５４】
図５はこの発明の実施例で必要とされるクライアント計算機５０の機能素子のブロック図を示す。サーバ計算機４０と同じように、図５は動作上クライアント計算機５０にとって必要とされる部品のすべてを示しておらず、この発明の好ましい実施例の少なくとも一つの動作にとって必要とされる機能ブロック素子だけが示されていると理解されたい。読者として意図されているのは当業者であって、全動作に必要とされる他のクライアント計算機部品はどれかは理解できる者としている。
【００５５】
クライアント計算機５０内部では、マルチメディア応用制御器５１が用意されていて、この制御器はサーバ内で用意されたマルチメディア応用制御器４１と対応している。マルチメディア応用制御器５１は、クライアント計算機５０内で実行しているマルチメディアアプリケーション（application）の高いレベル制御を提供し、またサーバ内の対応しているマルチメディア応用制御器４１と、ＴＣＰ接続３０上で送られる制御メッセージを介して通信する。同じように、マルチメディア応用制御器５１は制御信号をクライアント計算機５０の他の機能素子に提供し、このクライアント計算機は好ましい実施例を構成するものとなっている。
【００５６】
さらにクライアント計算機５０内に用意されているのが網接続モジュール５７であって、これは網からのデータパケットをいくつかの(one or more)データストリームの中で受領するように構成されている。いくつかの(one or more)データストリームの中で受領したデータに関する制御情報は測度計算器５６に送られて、受領したデータストリームのある種の特性を示す定量的な値の計算にあたり、計算された定量的な値は帰還(feedback)送信機５８に送られて、ＴＣＰ接続３０上で制御メッセージとして網を通って送り戻すのにあてられる。定量的な値の計算についてのさらなる情報は後に与えられる。
【００５７】
網接続５７はオーディオとビデオとのデータストリームを受領して、各ストリーム内のパケットからエンコードされたオーディオとビデオとのデータを読取る。エンコードされたオーディオとビデオとのデータは次にバッファ制御器５９に送られて、制御器は受領したエンコードされたオーディオデータをオーディオバッファ５４に供給し、また受領したエンコードされたビデオデータをビデオバッファ５２に供給する。バッファ制御器５９はさらにオーディオバッファ５４とビデオバッファ５２の状態を監視して、各バッファがどのくらい一杯であるかを判断し、また、各バッファが空となるレート（これはそこに記憶されたデータのデコード用レートを示している）を判断するように構成されている。オーディオデコーダ５３はさらに用意がされていて、オーディオバッファ５４からエンコードされたオーディオデータを読取り、かつエンコードされたオーディオデータをデコードして、デコードされたオーディオデータを出力として提供する。同じように、ビデオデコーダ５５が用意されて、これがビデオバッファ５２からエンコードされたビデオデータを取得し、エンコードされたビデオデータをデコードしてビデオ出力信号を提供する。
【００５８】
バッファ制御器５９は、オーディオとビデオとのバッファの状態に関する情報を受領すると、この情報を帰還送信機に向けて送り、ＴＣＰ接続３０上でサーバ計算機に送り戻された制御メッセージの中に組入れるようにする。
【００５９】
図５には示されていないが、クライアント計算機はさらに少くとも一つの計算機読取り可能記憶媒体を含んでいて、そこには計算機プログラムを記憶し、このプログラムはクライアント計算機がこの発明を実行する動作を制御することに注目すべきである。計算機読取り可能記憶媒体は既知の形式のいずれであってもよく、とくに光ディスク、磁気ディスク、磁気・光ディスク、固体計算機メモリ、あるいはいずれか他の適切なデータ記憶媒体のいずれか一つもしくは組合せの形式とすることができる。
【００６０】
この発明のサーバ装置とクライアント計算機装置を形成している基本的な機能ブロックを記述したので、今度は本発明の好ましい実施例の動作の記述をこれから順番に記載して行く。
【００６１】
第一の実施例
この発明の第一の実施例を図６〜１０を参照して記述して行く。第一の実施例はいくつかの独立したストリームを同じまたは異なるクライアントに向けて送ることと、閉ループ方法でストリームの伝送レートを制御することとにとくに関係している。
【００６２】
図６はこの発明の第1の実施例によりサーバ計算機４０により実行される段階の流れ図である。第一に、段階１０２では、送り用レート計算器４６はサーバ計算機４０から送られることになる個々のデータストリームのすべてにとって利用可能な全帯域幅を計算する。この値max_rateは伝送レート上の上限を表わしていて、この上限を各別個のデータストリームの個々の伝送レートは越えてはならない。この値max_rateは次の原理により計算される。
【００６３】
一般に、以前のマルチメディアコンファレンス適用であって、現在インターネットで使用されているものは、ＵＤＰトランスポートプロトコルに基づいていて、このプロトコルは、以前に論じたように、サービスの品質制御機構を何も提供しておらず、それ故に、例えば網輻輳を補償するのに必要であるような制御動作を実行する能力はない。したがって、網輻輳が発生するときに、競合しているＴＣＰ接続は、ＵＤＰトラヒックに代っていずれかのレート低減なしに前述したように伝送レートを減じる。
【００６４】
この問題を回復させるために、この発明の第1の実施例では、ＵＤＰオーディオとビデオとのデータストリームは輻輳制御方式で強化され、max_rateパラメータの計算は該方式の一部を形成している。とくに、パラメータmax_rateはストリームについて最大伝送レートを提供するために計算され、このレートは“ＴＣＰフレンドリィ”であって、伝送レートとなっていて、この伝送レートは時間にわたりＴＣＰ接続を介して達成されたスループットと類推できるものとなっている。
【００６５】
第1の実施例では、全体の(total)伝送レートパラメータmax_rateが伝送レート式を用いて計算され、この式はＴＣＰ接続の時間にわたる平均スループットをモデル化するように求められて、したがって、全体のレートはＴＣＰフレンドリィな伝送レートを与えるように計算される。第1の実施例では下記の式１で示した伝送レート式を使用している。
【数５】
2005503722.tif 000003
【００６６】
（式１）
上記のユビキタス（ubiquitous）ＴＣＰ接続に適用される式の導入についてはFloyd,S.の“Connections with Multiple Congested Gateway in Packet Switched Networks Part1：One Way Traffic”,Computer Communications Review,vol.21,no.5,1991年10月, page30〜47に見出すことができることに留意されたい。
【００６７】
上式ではｃは定数であってその範囲は０．８７ないし１．３１であり、ＲＴＴはラウンドトリップ時間（単位秒）であって、これはあるパケットがある計算機からある網をまたいで他の計算機に行きまた戻る転送にかかる時間であり、loss_rateは網内で受信機に至る際に失なわれたパケットの測定値であり、packet_medium_sizeは、計算が実行されている対象のストリーム内で伝送されるパケットの平均サイズである。式１のこれら要素についてのさらなる論議と、伝送レート式での使用のためにこれらがどのように計算されるかについては後に行なわれることに留意されたい。
【００６８】
式１はbit_rate_stream値を与え、この値は単一のＴＣＰ接続が現在の網状態で達成できる平均帯域幅の推定値である。しかしながら、第1の実施例では、この推定値を直接にあるストリームについての全体の伝送レートとして使用せず、むしろこの値bit_rate_streamは次の式２に入れられる。
【数６】
2005503722.tif 000004
【００６９】
（式２）
パラメータreceiving_rate_streamは特定の又は各クライアント計算機からＴＣＰ接続上で受領され、クライアントによって特定のストリームについて受領されたビット数に対応していて、このストリームについては計算はＲＴＴ秒内に行なわれる。
【００７０】
上記の式２はＴＣＰフレンドリィ性能を与えるために単一のＵＤＰストリームについて利用可能な全体の帯域幅max_rateを与える。この値は最大値であり、この値ではデータストリームはＴＣＰフレンドリィに留まるために送られなければならない。式１と２との計算はサーバが送っている各ストリームについて別個に行なわれなければならないことに留意されたい。
【００７１】
利用可能な最大伝送レートの計算に続いて、段階Ｓ１０４では、サーバにおける送りレート計算器４６が実際の伝送レート（data_rate）を各データストリームについて計算する。このストリームはオーディオＵＤＰストリームかビデオＵＤＰストリームかのいずれかとすることができる。data_rateの値は以下のように計算される。
【００７２】
前記のように、この発明の主な趣旨はいくつかのデータストリームの伝送レートを、受信機内のデータバッファ内のデータのレベルが特定又は各クライアントにおけるいくつかのそれぞれのバッファでのオーバーフローを防ぐように制御できるように制御することである。サーバから送られた各データストリームの伝送レートは、第一の実施例では、そのサーバから同じまたは異なるクライアントへ向けて送られた他のストリームのものとは独立して制御され、この制御はデータバッファの状態に関する特定の又は各クライアントからの帰還データに応答して影響されていて、このデータバッファでは受領したデータがデコード動作の前に記憶される。第一の実施例内部では、特定又は各クライアント計算機は少くともいくつかのデータデコードレート（バッファが空となるレートと等価）を報告として戻すことができ、あるいは各バッファがどのくらい一杯か（あるいは代ってどのくらい空があるか）を示す情報を報告として戻すことができる。この情報を用いて、送りレート計算器４６は各ストリームについてのdata_rate値をいくつかの後続の変形に従って計算することができる。
【００７３】
第一の変形では、サーバはクライアントからの帰還データを受領し、これが受領したデータのクライアントにおけるデコードレートすなわちバッファが空にされるレートに対応している。一番簡単な場合には、伝送レートは受領したデコードレートに等しいと単純に設定され、前に論じた計算された最大伝送レートとは何の関与もない。このような場合に、max_rateの計算に関する段階１０２は実行されない。伝送レートをデコードレートに等しく設定することによって、バッファはオーバーフローすることがなくなることを確かなものとし、理論的にはデータはバッファに到達するのにそのレートはバッファから移動されるレートと同じでなければならない。定常的な伝送レートはそこで確保されなければならず、伝送レートの変化はエンコード用レートの変化に依存することになる。
【００７４】
上記の第一の変形は、しかしながら、網をまたいだ伝送が完全であることを仮定していて、途中でのパケット損失はないとしている。第二の変形では、それ故に、クライアントからデコードレートを受領するとともに、サーバはまた前述したloss_rate測度を受領し（loss_rate値の計算は後に詳述する）、これを以下のように伝送レートの計算の因子とする：
data_rate＝（１＋loss_rate）* decode_rate                  （式３）
この方法では、サーバは網において経験されている現在の損失レートについてある種の先行補償を作ることができる。
【００７５】
別な変形では、サーバはどのくらいの充填度にバッファがあるかに関する情報を受領し、バッファをオーバーフローから防ぐために伝送レートでの段階もしくは連続変化を実行する。多くの可能とされるアルゴリズムが存在し、これがこの場合にも適用できて、例えばデータレートはバッファを充填する百分率と逆関係にある（すなわち、百分率が大きくなると、データレートが小さくなる関係）とか、しきい値技術を用いる段階変更を達成すること（例えば、単純な場合には：もしバッファが満杯状態のｘ％より小さいとすると、第一の高い方のレートで送り、そうでなくバッファが満杯状態のｘ％より大きいならば、第二の低い方のレートで送るというものである。複数のしきい値をもつアルゴリズムも同じように考えることができる）。伝送レートにおける段階変更ソースデータの符号化を制御してより高い（よい品質の）、あるいはより低い（貧弱な品質の）エンコードレートを与えるようにすることで達成できる。
【００７６】
第四の変形では、段階１０２で計算されたmax_rate値が使用される。ここでサーバはデコードレート情報をクライアントから受領し、送り用レート計算器４６は先ず、受領したデコードレートが計算されたmax_rateよりも小さいかどうかを調べる。そうであれば、伝送レートはクライアントにおけるデコードレートと同じになるように設定され、それ以外では伝送レートは計算された最大伝送レートとなるように設定される。上述のように計算された最大伝送レートを計算に入れることによって、網輻輳をデータストリームをＴＣＰフレンドリィとするのと併せて説明することが可能になる。
【００７７】
ここで対象として考えられている読者にとっては、他のもっと複雑なレート制御アルゴリズムがクライアントから受領した利用可能な情報と一緒に使用できること、また上述の例は非限定的な例についてのことだけであることが疑いなく理解できるものと思料する。この発明の第一の実施例の本質的な特徴は、しかしながら、ある種の帰還データであって受信機バッファと関係しているものがサーバに向けて送られて、このサーバで使用され、クライアントのバッファのオーバーフローを防ぐために伝送レートを制御するのにあてるということである。対象と考えられている読者にとっては上記概説以外の他の方式もこの目的を達成するために使用できることは疑いなく明らかであろう。
【００７８】
図６に戻ると、各ストリームについて送りレートを計算した後で、段階Ｓ１０６では、サーバにおける網接続４７はいくつかのストリームを分離されたＵＤＰデータストリームとして、計算された送りレートで送る。このいくつかのストリームは連続して送られるので、図１１の段階は、継続的に示しているものの、実際には並列に実行されて、このようなストリームの伝送レートは現実には伝送レートについて新しい値がいったん計算されると更新されることに留意すべきである。しかしながら、この新しい計算が実行されている間には、ストリームは以前に計算したレートで送られ続けることになっている。
【００７９】
図６の段階Ｓ１０８では、サーバ計算機４０は帰還データを特定又は各クライアント計算機５０から受領する。第1の実施例ではこのデータは最大伝送レートとデータストリーム伝送レートの計算を段階Ｓ１０２とＳ１０４とで実行するために必要とするものである。とくに各ストリームについて、サーバはクライアントにおいて現在経験しているラウンドトリップ時間と、クライアントでのパケットの損失レートと、クライアントにおけるバッファのそれぞれのデコード用レートと、クライアントにおける各データのデータストリームのデータ受信レートとについて知らせるデータをサーバが受領する。こういった定量的な値はサーバに向けてＴＣＰ接続を経由して特定又は各クライアントから送られる。これらの値は特定の又は各クライアントから各伝送されたデータストリームについて送り戻されることに留意されたい。
【００８０】
いったん更新された帰還データがクライアントから受領されたならば、これがサーバ内の送り用レート計算器４６に送られて、ここで段階Ｓ１０２とＳ１０４での計算をもう一度行ない、その結果が網接続４７に向けて送られる。この網接続はオーディオとビデオのストリームを新しい計算された送り用レートで送る。このプロセスは特定又は各クライアントのセッションの間に連続している。
【００８１】
定量的な値であって特定又は各クライアント計算機からサーバに向けて送り戻されたものについての計算を、図７において展開されたように第1の実施例でのクライアント計算機の一つの動作に関して論述することとする。図７を参照すると段階Ｓ１０１ではクライアント計算機５０内での網接続５７はいくつかのデータストリームを、網上での個々のＵＤＰ伝送として受領する。前述のように、網接続５７はそれぞれのＵＤＰストリームからのエンコードされたデータのパケット化を解いて（depacketises）、このエンコードされたデータをバッファ制御器５９に向けて送り、バッファ化と後のデコード化とにあてる。
【００８２】
オーディオもしくはビデオデータを含んでいる単一のストリームの場合に、バッファ制御器５９によって受領されたエンコードされたデータはそれぞれオーディオバッファ５４かビデオバッファ５２かの一つに記憶される。段階Ｓ１０３では、バッファ制御器５９はオーディオバッファ５４とビデオバッファ５２とにそれぞれ問合せをして各バッファの状態を判断するようにする。とくに、バッファ制御器は各バッファはどのくらい充填されているかと、どのくらい速くにエンコードされたオーディオとビデオの情報であって各バッファ内にあるものがそれぞれのオーディオとビデオのデコーダ５３，５５によってデコードされているかについての情報を判断する。これがどのくらい速くオーディオとビデオのバッファがそれぞれのデコーダによって空にされているかを示すものとなっている。バッファ制御器が各バッファの状態を判断すると、判断された情報が帰還送信機５８に送られて、制御メッセージの中に閉じ込められ（encapsulation）、サーバ計算機４０への戻り伝送にあてられる。
【００８３】
エンコードしたオーディオとビデオデータをバッファ制御器に向けて送ることに加えて、網接続５７はまた受領したデータに関する情報を測度計算器５６に向け送り、測度計算器５６が帰還送信機５８によりサーバに向けて送り戻された定量的な測度値を計算できるようにする。したがって、段階Ｓ１０５，Ｓ１０７，及びＳ１０９では、測度計算器がそれぞれ各ストリームについてラウンドトリップ時間（ＲＴＴ）と、損失事象のレートと、ストリーム当りの受領したデータレートとを計算し、これらの計算値はすべてサーバにおいて式１と２との入力として必要とされているものであり、データストリームについて利用可能な最大伝送レートの計算にあてられる。三つの測度が各受領したデータストリームについて個々に計算され、一組の測度が各受領したデータストリームについて与えられるようになっていることに留意されたい。こういった定量的の値の各々についての計算は次に論じられる。
【００８４】
ＲＴＴに関しては、前述の通り、ＲＴＴがパケットがある計算器から網をまたいで他の計算機に行って戻って来る移動にかかる時間の測定値である。ＲＴＴはそれ故にクライアント計算機において測度計算器５６内部で測定された何かであるが、発振（oscillations）防止のために次式で計算されるのが好ましい。
【数７】
2005503722.tif 000005
【００８５】
（式４）
値ＲＴＴsampleは測度計算器によって測定されたＲＴＴの最新の測定値であり、また値ＲＴＴmeanは以前のＲＴＴの全測定値の平均値である。
【００８６】
段階Ｓ１０７では、測度計算器５６はクライアント計算機で経験したストリーム当りの損失事象レートを計算する。損失事象レートの計算は最も複雑な計算であり、この計算は速度計算器５６が実行しなければならないものであり、また到着するパケットの一連番号からＵＤＰストリーム内の失なわれたパケットの検出に依存している。この失なわれたパケットの検出は到着するパケット内のパケット一連番号の検出に基づいて網接続により実行され、ここでは予期されたパケットが失なわれたと定義されるが、その条件は少くとも三つのパケットであって予期されたパケットよりも大きな一連番号をもつものが、予期されたパケットが到着していない状態で、受信機に到達するものである。したがって、もし一連番号５をもつパケットが予期されているとすると、そのときは到達する次のパケットがパケット６，パケット７，そしてパケット５である場合には、このときはパケット５は損失されたと定義されない。しかし次の３つのパケットで順に到着するものがパケット７，８，そして６であると、そのときは到着したパケットの三つ各々が予期されたパケット番号５よりも大きなシーケンス番号であるから、パケット５は損失と定義される。
【００８７】
上記のようにパケットが損失としてどのように定義されるかを特定した上で、測度計算器は損失事象（loss event）として知られる別の出現（occurrence）を定義する。好ましい実施例では、損失事象はいずれかのＲＴＴ測定においていくつかのパケットの損失の検出として定義されている。したがって、もしいずれかの特定のＲＴＴ測定で、パケットでその番号が４，６，７，９，１０、１１のものが到着したとすると、そのときは、パケット５と８とは失なわれているけれども、特定の測定されたＲＴＴでは実際には一つだけの損失事象であったとされる。この方法は網内で同時に失なわれている複数のパケットについても説明されるところであり、全体の損失事象のレート計算に過度に影響を与えるものではない。
【００８８】
上述のように損失事象がいったん検出されると、段階Ｓ７４において測度計算器５６は最近の損失間隔（loss interval）を計算する。これは現在検出された損失事象と以前に検出された損失事象との間で受領したパケットの数である。測度計算器は新しく計算された損失間隔を、ｎ個の最近計算した損失間隔と一緒に記憶して、平均損失間隔値を与えるために重み付けしたフィルタでの応用にあてる。平均損失間隔値は次のように計算される。
【００８９】
図９と１０とを参照すると、図１０は測度計算器を作り上げている若干の機能素子を示しており、これらの素子が損失レートの計算のために使用されている。とくに、損失事象検出器５６２は上述したように損失事象を検出して、最新計算の損失間隔を多数の直列接続された損失間隔バッファ５６４の第一のものに向けて出力する。新しい損失間隔が第一のシリーズバッファ５６４に入力されるときは、前の損失間隔値として第一のバッファ内に保存されているものが次のバッファへとシフトされ、ここで言う次のバッファの値はシリーズ内の次のバッファというように順にシフトされることが図１０に示されている。この方法では、ｎ個の最新の損失間隔値は平均損失間隔値を計算するのに使用するために記憶される。シフトバッファ５６４内に記憶された各損失間隔値は、時間で重み付けされた損失間隔係数Ａ０〜Ａｎによりそれぞれ乗算される。この係数はそれぞれの係数メモリ６５６に記憶されている。係数の個々の値Ａ０〜Ａｎは図９に示したように、時間で重み付けした係数関数に従って求められ、この関数は直近の損失間隔が平均損失間隔の計算に向けて前の計算から記憶された歴史上の損失間隔よりも大きな拡がり（extent）までカウントすることを確かにする。この時間重み付けしたフィルタを適用する目的は、計算された損失事象レートが滑かに変化することを確かにすることである。
【００９０】
加重された損失間隔計算の結果は合算機器（summer）５６６で合算され、その結果はインバータ５６８に向けて送られて、損失レートの計算にあてられ、合算機器５６６により計算された平均損失間隔の逆数となる。こうして計算された損失レートはそこで帰還送信機５８に送られて、前記のようにサーバ計算機に向けた伝送にあてられる。
【００９１】
受領したデータレートの計算はまた測度計算器５６によっても実行され、ＲＴＴ秒内のデータストリーム内でクライアントにより受領されたビットの数の直截的な（straightforward）測定値となる。各ストリーム内のいずれかの一時刻で受領されるデータ量に関する情報は網接続５７から測度計算器５６に向けて送られて、ストリーム毎の受信レートの計算にあてられる。計算されたストリーム毎の受信レートはそこで帰還送信機５８に向けて送られて、前述のようにサーバ計算器に向けて送り戻されるようにする。
【００９２】
いったん帰還送信機５８がバッファ制御器５９と測度計算器５６からの必要とされる情報を受領したときには、送信機はこの情報をＴＣＰ接続３０内の網上での伝送に適した形式にパケット化する。
【００９３】
図７の流れ図に示された段階Ｓ１０１〜Ｓ１０１３は例示だけの目的のものであり、また特定又は各クライアント計算機５０は事実所望されるどんな順序でもこれらの段階のいずれかあるいは全部を実行できることに留意すべきである。さらに、これらの段階のいくつかを並列に実行することも可能であり、例えば、バッファ制御器５９により実行されたオーディオとビデオとのバッファのチェックと測定とは測度計算器５６によって実行される計算と並列に実行されることができる。しかしながら、第1の実施例では、受信機にとっては、サーバ計算機に向けて送り戻される定量的な値を計算するのに必要な情報を持つために、オーディオとビデオとのデータストリーム内に実際に受領したデータを持つことが必要であることに留意されたい。
【００９４】
サーバ内部では、特定又は各ストリームの実際の伝送レートは網制御器４８と網接続４７との組合わせで制御されていて、計算されたレートに従って網上にパケットを実際にレリーズすることによって行なわれる。しかしながら、データストリーム内でビデオデータの伝送をする特別な場合には、計算されたレートは使用された特定のエンコードレートについての伝送レート要求を満足しないことになることもあり得る。この場合に、ビデオストリームについての計算された伝送レートが低下して、現在のビデオエンコードレートで、ビデオストリーム内で十分なデータを送り、受信機にあるビデオバッファを空にすることを妨げることができないように思われれば、網制御器４８は網接続４７を制御して低レートエンコード用ビデオバッファ４３からエンコードされたビデオデータを採り出すようにし、これが低品質でエンコードされていて、より低い計算された伝送レートで網をまたいだ伝送により適切なものとなっている。受信機では、低レートのエンコードされたビデオデータはビデオバッファ内に置かれていて、ビデオデコーダ５５は低い方のレートのエンコードを検出して、自己のデコードレートをより低いレートに変えて、これがビデオデータをビデオバッファから読取るレートに低減する。このような測定値がビデオバッファを完全に空にすることを防いで、それによりクライアント計算機における連続したビデオ再生を可能にしている。
【００９５】
第二の実施例
この発明の第二の実施例の動作を図８〜１３を参照して記述して行く。この発明の第二の実施例はとくに複数のデータストリームを同じクライアントに向けて送ることに係り、またとくに同時実時間オーディオ及びビデオデータを別個のオーディオ及びビデオデータストリーム内で送ることに関係している。さらに、第一の実施例と同じように、第二の実施例は閉ループ方式でストリームの伝送レートを制御することに関係している。
【００９６】
図１１は、この発明の第二の実施例により、サーバ計算機４０によって実行される段階の流れ図である。第一に、段階２では、送りレート計算器４６は、サーバ計算機４０から送られることになる個々のデータストリームの全部について利用可能な全帯域幅を計算する。この値total_rateは伝送レートの上限を表わしていて、このレートは一緒に加算されたときに各別個のデータストリームの個別伝送レートがより大きくなってはならないものである。値total_rateは以下の原理により計算される。
【００９７】
各ストリームの伝送レートの計算について同じ考え方が、第一の実施例のように第二の実施例で適用される。それ故に式１と２とを第一の実施例について記述したように、各ストリームに対して別個に適用して、各ストリームについて値max_rateを得るようにし、これがオーディオ及びビデオデータストリームの各々について最大個別伝送レートを表わしている。しかしながら、現在の実施例では、複数ストリームの伝送に関心があって、したがって上記の計算は伝送されることになる各ストリームについて別個に実行されなけばならない。すなわち、式１と式２との両方が各ストリームに（すなわち第二の実施例でのオーディオとビデオのストリームの各々に）及び各ストリームについて見付かった値max_rateに順に適用される。それぞれの値は、したがって各ストリームについて見付かったものはそこで一緒に加算されて値total_rateを与えるようにされ、この値はＴＣＰフレンドリィな性能を与えるためにすべてのストリームについて利用可能な全帯域幅となっていて、したがって、可能とされる網の輻輳を計算に含めている。
【００９８】
利用可能な全体の伝送レートの計算に続いて、段階Ｓ４では、送り用レート計算器４６でサーバの中にあるものが各データストリームについて個々の伝送レートを計算する。このレートは第二の実施例ではオーディオＵＤＰストリームの伝送レート（audio_rate）と、ビデオＵＤＰストリームの伝送レート（video_rate）である。audio_rateとvideo_rateの値は次のように計算される。
【００９９】
図３に関して前述したように、オーディオデータはＵＤＰストリーム内でビデオデータからは別個に送られて、ビデオデータは別のＵＤＰストリーム内で送られるので、各ストリームについて一つの二つの別個のＵＰＤ接続が存在する。各ストリームは同じ網帯域幅に対して競合していると考えることができたのであるが、実際には、これは真実ではなく、その理由はビデオとオーディオとのデータパケットを同じ瞬間に送ることは可能でないことにある。したがって、二つのデータストリームがオーディオとビデオとのストリームである場合には、以前に計算した全体の送り用ビットレートはオーディオの送り用ビットレートにビデオ送り用ビットレートを加えたものに等しくすることができる。さらに、後に論述するように、第二の実施例では、サーバはクライアントからビデオとオーディオとのバッファの状態と、ビデオとオーディオとのパケットについてのデコード用レートとについての情報を受領している。したがって、オーディオとビデオとのデータストリームの送りレートを制御して、クライアント内のバッファの充填レートを制御することは可能となる。これは次のように達成される。
【０１００】
先ず、パラメータfilling_rate_audioとfilling_rate_videoを定義して、それぞれ受信機内でオーディオとビデオバッファがデータで満たされるそれぞれのレートであるとする。この実施例では：
filling_rate_audio＝audio_rate−decoding_audio_rate            （式５）
と
filling_rate_audio＝video_rate−decoding_video_rate            （式６）
受信機内のバッファの制御がバッファが比ｘ：ｙで充填するように要求されていると仮定すると、そのときは：
ｘ（filling_rate_audio）＝ｙ（filling_rate_video）            （式７）
と
total_rate＝audio_rate＋video_rate                            （式８）
適切な代入を実行し、audio_rateとvideo_rateについてそれぞれ解くと：
【数８】
2005503722.tif 000006
【０１０１】
（式９）
【数９】
2005503722.tif 000007
【０１０２】
（式１０）
ここで上記のことから明らかなように、それぞれのオーディオ送り用レートとビデオ送り用レートとを制御して、受信機におけるそれぞれのオーディオ及びビデオのデコードレートに依存して一方のストリームから他方のストリームにビットレートを交換することが可能となる。さらに、上述のことから、パラメータtotal_rateは式１と式２の適用から、以前に計算された値であって、すべてのデータストリームの伝送について利用できる全部の利用可能な帯域幅を与えることに留意されたい。すなわちtotal_rate＝total_rate_stream_1＋total_rate_stream_2＋…＋total_rate_stream_n（ここでｎは同時に伝送されているデータストリームの数）である。
【０１０３】
図１１に戻って、各ストリームについてオーディオとビデオとの送りレートの計算後に、段階Ｓ６では網接続４７でサーバ内のものがオーディオとビデオとのストリームを別個のＵＤＰデータストリームとして、計算したオーディオとビデオとの送りレートで送る。オーディオとビデオとのストリームは連続して送られ、図１１の段階は、シーケンシャルに示されてはいるが、実際には並列で実行されていて、それによってオーディオとビデオとのストリームの伝送レートは、実際には新しい値がオーディオとビデオとの伝送レートが計算されたときに更新されるようになることに留意されたい。しかしながら、新しい計算が実行される間は、これらのストリームは、以前に計算されたレートで伝送され続けることになる。
【０１０４】
図１３はこの発明の実施例により制御された一つのデータストリームの測定された伝送レートのプロットを示し、その条件は図２でプロットされたＴＣＰ接続により送られたものと同じデータを送るときである。図１３から、セッションの開始で経験される初期の過渡的な変化の後で、ストリームの伝送レートは次第に安定化し、時間に対して比較的小さな変化で継続する。さらに、図２に示したＴＣＰ接続によって経験された伝送レートと比較されるときには、ほぼ同一の平均スループットがＴＣＰのように達成されるが、ＴＣＰの乗算的な減少制御アルゴリズムからもたらされる伝送レートに大きな変化を生ずることはない。時間に関して滑らかな伝送レートを提供するというこの特性はこの発明を連続ストリーミングを必要とするデータの伝送に使用するのにとくに適したものにしている。
【０１０５】
図１１の段階Ｓ８では、サーバ計算機４０は帰還データをクライアント計算機５０から受領し、好ましい実施例では、データは全伝送レータとデータストリーム伝送レートの計算（段階Ｓ２とＳ４のもの）を実行するのに必要とされるデータである。とくに、各ストリームについて、サーバはデータを受領し、このデータはクライアントのところで現在経験されているラウンドトリップ時間と、クライアントのところでのパケットの損失レートと、クライアントにおけるオーディオとビデオとのバッファのそれぞれのデコード用レートと、クライアントのところでの各データストリームのデータ受信レートとを知らせるものである。こういった定量値はクライアントからＴＣＰ接続を介してサーバに送り戻される。
【０１０６】
いったん更新された帰還データがクライアントから受領されると、それがサーバにおける送り用レート計算器４６に向けて送られて、ここで段階Ｓ２とＳ４との計算がもう一度実行されて、網接続４７に向けて結果を送り、この接続は新しい計算された送り用レートでオーディオ及びビデオストリームを送る。このプロセスはクライアントセッションの間に継続する。
【０１０７】
クライアント計算機からサーバに向けて送り戻された定量値の計算は、図１２で設定されたような第二の実施例におけるクライアント計算機の動作に関してここで論じられる。図１２に関して、段階Ｓ１では、クライアント計算機５０における網接続５７は網上での個別のＵＤＰ伝送として分離されたオーディオ及びビデオデータストリームを受領する。前述したように、網接続５７はそれぞれのＵＤＰストリームからエンコードされたオーディオ及びビデオデータのパケット化を解除し、バッファと後続のデコードのためにエンコードされたビデオ及びオーディオデータをバッファ制御器５９に向けて送る。
【０１０８】
エンコードされたオーディオ及びビデオでバッファ制御器５９により受領されたものはそれぞれオーディオバッファ５４とビデオバッファ５２内に記憶される。段階S３では、バッファ制御器５９はオーディオバッファ５４とビデオバッファ５２にそれぞれ問合せて、各バッファの状態を判断するように動作する。とくに、バッファ制御器は、各バッファがどの程度充填されているかと、エンコードされたオーディオ及びビデオ情報で各バッファ内にあるものがどのくらい速くそれぞれのオーディオ及びビデオデコーダ５３，５５でデコードされているかについて情報を判断する。これがどのくらい速く、オーディオ及びビデオバッファがそれぞれのデコーダにより空にされているかを示す。ひとたびバッファ制御器がオーディオ及びビデオバッファ状態を判断すると、判断された情報が帰還送信機５８に向けて送られて、サーバ計算機４０に向けて送り戻すために制御メッセージの中への閉じ込め(encapsulation)にあてられる。
【０１０９】
バッファ制御器に向けてエンコードされたオーディオ及びビデオデータを送ることに加えて、網接続５７はまた受領したデータに関する情報を測度計算器５６に向けて送り、それによって測度計算器５６に定量的測度値を計算することができるようにし、この値は帰還送信器５８によってサーバに送り戻される。したがって、段階Ｓ５，Ｓ７，Ｓ９では、測度計算器はそれぞれ各ストリームについてラウンドトリップ時間（ＲＴＴ）と、損失事象レートと、ストリーム当りの受領したデータレートとを計算し、これらのすべては、データストリーム毎に利用可能な伝送レートの計算のために式１と式２への入力としてサーバで必要とされる。この三つの測度は各受領されたデータストリームについて個々に計算されて、その結果一組の測度が各受領されたデータストリームに提供されることに留意されたい。各ストリームについてのこれらの測度の各々の計算は第一の実施例で前述したものと正確に一致していて、したがってここでは繰返さない。
【０１１０】
いったん帰還送信機５８が、バッファ制御器５９と測度計算器５６とから必要とされる情報を受領すると、この情報をＴＣＰ接続３０内で網上での伝送に適した形式に情報をパケット化する。
【０１１１】
図１２の流れ図に示した段階Ｓ１ないしＳ１３は例示の目的だけのためであり、クライアント計算機５０は事実上、望ましいいずれかの順序でこれらの段階のどれかあるいは全部を実行できることに留意されたい。さらに、これらの段階のいくつかを並列に実行することも可能であり、例えばバッファ制御器５９により実行されるオーディオ及びビデオバッファをチェックすることと測定とは測度計算器５６によって実行される計算と並列に実行することができる。しかしながら、第二の実施例では、受信機にとって実際にオーディオ及びビデオデータストリーム内で受領したデータを有することがサーバ計算機に向けて送り戻される定量的な値を計算するのに必要な情報を持つために必要であることに留意されたい。
【０１１２】
サーバ内部では、各ストリームの実際の伝送レートは網制御器４８と網接続４７とを組合せによって、計算されたレートに従って網に向けてパケットを実際にリリースすることにより制御される。しかしながら、第二の実施例で記述したオーディオ及びビデオデータの伝送の特別な場合には、第一の実施例のように、ビデオデータについてはとくに計算されたレートは使用される特定のエンコード用レートについての伝送レート要件を満足しないことになり得る。この場合には、もしビデオストリームにとって計算された伝送レートが低下されなければならないように見えるとすると（この低下は現在のビデオエンコードレートでは受信機におけるビデオバッファが空になることを防ぐにはビデオストリーム内で十分なデータを送ることが不可能となる程度のものである）、そのときは網制御器４８が網接続４７を制御してエンコードされたビデオデータを低いレートのエンコード用ビデオバッファ４３から採用するようにする。該ビデオデータは低い方の品質でエンコードされたものであり、低い方の計算された伝送レートで網をまたいだ伝送により適したものである。受信機では、低レートのエンコードされたビデオデータはビデオバッファの中に置かれて、ビデオデコーダ５５はエンコードについての低い方のレートを検出し、自己のデコード用レートを低い方のレートに変更し、この低減しているレートでビデオバッファからビデオデータが読み取られている。このような測定値はビデオバッファが完全に空になることを防ぎ、それによってクライアント計算機における連続するビデオ再生を可能としている。
【０１１３】
この発明の第二の実施例はオーディオとビデオのデータを複数のデータストリームとして送ることを指向しているので、第二の実施例内部では、各ストリームのそれぞれのビットレートを設定するための規準はオーディオとビデオのデータの特別な要件を反映するように選定されていて、もとのオーディオとビデオの信号を再生するために受信機でそのようにデコードされなければならないことに留意されたい。しかしながら、この発明は複数のデータストリームとしてのオーディオとビデオデータの伝送に限定されておらず、事実いくつかのストリームの中での送りが求められているほとんどいずれの形式のデータがこの発明を用いて伝送することができる。
【０１１４】
さらに、この発明で使用される利用可能な全部の最大伝送帯域幅の計算に関しては、好ましい実施例では伝送レート式が使用されたが、この式は標準のＴＣＰ接続によって得られる平均のスループットをシミュレートする(simulate)ことが意図されている。しかしながら、この特定の式もまたこの式を使用する理由もこの発明での限定となることを意図したものでないことを理解されたい。また事実、いずれか適当な伝送レート式が利用可能な最大伝送レートを計算するために使用できて、このレートは次に個々のストリーム伝送レートを計算するために使用されることを理解されたい。
【０１１５】
とくに、また例として、伝送がインターネットプロトコル網上で行なわれることになるところでは、ＴＣＰフレンドリィな伝送レートを提供する他の伝送レート式がこの特定の実施例で使用される式の代わりに使用できるのであって、各種の他のＴＣＰフレンドリィな式が現在では当業者の知るところである。さらに、入力として異なるパラメータを必要としている異なる式が用いられる場合には、特定の又は各クライアント計算機はサーバによって必要とされているパラメータはどんなものでも計算して供給するように構成しなければならない。ＩＰ網が使用されない場合には、選ばれた伝送レート式は関心のある特定の網上で使用されているどんなトランスポートプロトコルに対しても意味のあるものとなっているべきであることが好ましいし、また網輻輳と結果として生ずるパケット損失などのような因子を計算に入れるために有意の伝送レートを提供することが好ましい。この発明の他の実施例では、どんな伝送レート式が適切であるかが、本発明の応用の特定分野に依存していて、それが当業者にとって明らかになるものと思料する。
【０１１６】
第三の実施例
この発明の第三の実施例をここに記述して行く。第三の実施例は、とくに、いくつかの独立したストリームを同一または異なるクライアントに送ることと関係していて、また開ループ方式で特定又は各ストリームの伝送レートを制御することに関係している。
【０１１７】
閉ループ制御システムと関係した上記の実施例では、クライアントから受領した情報はサーバのところで伝送レートを制御するために使用された。第三の実施例では、しかしながら、開ループ制御が、特定又は各データストリームの中でクライアントに向けて送られたパケットの追跡を保っているサーバによって実行され、またどのくらいの量の空間がクライアントのバッファに残っているかの推定が、クライアントのバッファサイズ（Ｓ）（バイト単位）の予め用意した知識と、受領したデータをバッファから読取ることを始める前にクライアントが実行することになる静的バッファ動作の量と、バッファからデータが読取られることになるレートとの推定が行なわれる。サーバはそこでバッファ内にクライアントが残した空間がどの位の量かについての常に更新された推定を保持して、それにより伝送レートを制御する。
【０１１８】
とくに、第三の実施例では、送り用レート計算器４６はそこに次のような特定又は各クライアントの特質に関する情報を記憶している：
ａ）どのくらいの量の静的バッファ動作をデコード動作が始まる前（Ｔ秒）にクライアントがすることになるか；
ｂ）どのくらいの大きさ（バイト単位で）がクライアントのバッファにあるか（Ｓバイト）。
【０１１９】
加えて、サーバ内の網接続４７は送り用レート計算器に向けて次の情報を監視して送る：
ｃ）特定時間ｔに送られているデータの生のデコードレート（ｄ（ｔ）バイト／秒）；
ｄ）時間ｔでデータの伝送レートt（ｔｘ（ｔ）バイト／秒）。
【０１２０】
網接続はクライアントのところでのデコードレートを、クライアントに向けて送られる各パケットをログすることにより計算する。各パケットはタイムスタンプをそこに有して、サーバ内の網接続はまたどのくらい長さが各パケットにあるかについても知っているので、そこで区分的な秒当りのバイトを計算することが可能となる。このバイト／秒はクライアントが受領したパケットでバッファからのものを消費すべきものである。伝送レートはもちろん網接続によって知られることになり、記録を保存するために時間に対して単順にログされることができる。網接続はデコードレートと過去の伝送レートとに関する情報を送り用レート計算器に向けて送る。
【０１２１】
上記の変数を判断しかつ受領すると、送り用レート計算機はそこである時間ｔにおいてバッファ内に残されたバイト単位の空間（space）の量を次の式１１（すなわち数１）を適用して判断することができる：
【数１０】
2005503722.tif 000008
【０１２２】
（式１１）
上記式を用いると、バッファの充填度もしくは受領したデータのデコードレート（受信機のバッファからの読取りレート）についてクライアントからの帰還を何ら必要としないが、サーバはＴ（静的なバッファ動作時間−クライアントが最初にストリームを受けるときに、バッファからのデータ読取りを開始するのに先立ってクライアントがどれほどの時間をデータをバッファするのに費すかというもの）と、Ｓ（バイト単位としたクライアントのバッファのサイズ）との値を前もって知ることを必要としている。しかしながら、上述の計算を連続して実行することによって、サーバにとっては、クライアントのバッファ内に残された空間量についてのストリーム伝送の間はいつでも推定を維持することが可能であり、それは、クライアントはサーバが考えていることをするかぎりクライアントはする（即ち、開始からＴ秒までデコードを始めることがなく、あるバッファサイズＳを有している）からである。もち論、クライアントは、何かほかのことが発生して（すなわち、ユーザが休止を強勢して）、それによりサーバが再計算できるように、信号を送らねばならない。このような信号送り（signalling）はＴＣＰチャンネル上で第一と第二の実施例について上記したように行なわれる。加えて、何らかのパケット損失が発生し、クライアントがその戻しの信号を送ると、バッファの充填度はそのパケットのサイズによって調節されるようにできる。
【０１２３】
もち論、ＴとＳとが知られていないときには、あるいは動的であると、そのときは現在のバッファの充填度についての帰還が必要とされることになる。このことは第一の実施例について前記したところである。
【０１２４】
サーバが複数のストリームを送っているときに、上記の処理段階が各ストリームについて実行されて、各ストリームについて各それぞれのバッファ内に残っている空間を判断するようにする。
【０１２５】
上記の方法は、伝送の間に、いずれかの特定時間にバッファ内にクライアントが残したとサーバが信じている空間がどのくらいの量であるかについて推定空間（space）をバイト単位で判断する。そこでこの情報を用いて特定又は各ストリームの伝送レートを実際に制御してバッファのオーバーフローを防ぐことが必要となる。第三の実施例では、第一の実施例のように、これが多数の方法で達成できる。
【０１２６】
第一の変形では、サーバはこの空間情報を使用してバッファをオーバーフローから防ぐために伝送レートに段階状もしくは連続する変化を実行してもよい。数多くの可能なアルゴリズムが存在し、これがこの場合に適用されてよく、例えば、データレートがバッファの充填についての百分率と逆の関係にあるようなもの（すなわち百分率が大きいほどデータレートは低い）とか、しきい値技術を用いて段階変化を達成することによる（例えば簡単な場合には：もしバッファが一杯のｘ％より少ないときは、第一の高い方のレートで送り、そうでなくバッファが一杯のｘ％より大きければ第二の低い方のレートで送るとするようなものである。複数のしきい値をもつアルゴリズムも同じように考えることができる）。伝送レートにおける段階変化はソースデータの符号化を制御してより高い（より好品質）かより低い（より貧弱な品質）の符号化（encoding）レートを与えるようにすることにより達成できる。
【０１２７】
別な変形では、サーバはできるだけ速いレートで所与の現在の網状態を送ることができてそれによりクライアントのバッファを（サーバによる推定通りに）充填することができ、また次に送りをバッファがあるレベルまで空になるまで（これをまたサーバによる推定通りに）停止する。この変形では、データはバースト形式の方式で一連のストリームとして送られることになり、また定常状態の伝送を達成しない。定常状態の伝送はマルチメディアのストリーミングにとっては通常は好都合となっているのであるが、しかし、このような‘バースティ（bursty）’形式の伝送は若干の可能性のある網環境でメリットをもつことができる。
【０１２８】
意図された対象の読者は、もっと他の複雑なレート制御アルゴリズムがサーバによって判断された空間情報と一緒に使用できること、また上記の例が非限定的な例示だけの目的であると意図されていることを疑いなく理解できると思料される。この発明の第三の実施例の本質的な特徴は、しかしながら、受信機バッファ内に残っている空間がサーバで推定されて、サーバ内で使用されてその伝送レートを制御して、クライアントでのバッファがオーバーフローしないようにすることにある。意図された読者には上記で概説したもの以外の他の方式もまたこの目的を達成するために使用できることは疑いもなく明らかであろう。
【０１２９】
また留意してほしいのは第三の実施例では、最大伝送レートを計算して計算した最大レートを上限として伝送レート制御に適用することがまた可能であるということである。最大伝送レートの計算は第一と第二の実施例に関して前述したのと同じものとなろう。レート制御アルゴリズムへのその適用もまた同様であり、そこでは計算された最大レートがどんなレート制御アルゴリズムにも単純に適用されるのであって、ここでのアルゴリズムはそれ以上の伝送レートが送られてはならないとされている最大上限として選ばれたものであるとしている。代って、別の変形では、複数のストリームが同じクライアントに向けて送られ、この伝送レート制御は第二の実施例で記述したのと同じであってよいが、違いとして、レート制御式では受信機から送り戻されたものよりはむしろ、サーバで監視されたデコードレートの値が使用されることである。
【図面の簡単な説明】
【０１３０】
【図１】先行技術のマルチメディアストリーミングシステムの要素を示す例示ブロック図。
【図２】先行技術のＴＣＰプロトコルを用いる網のデータスループットを示すグラフ。
【図３】この発明の実施例で使用されるサーバ及びクライアント装置の構成を示すブロック図。
【図４】この発明の実施例で使用するためのサーバ装置の主要素のブロック図。
【図５】この発明の実施例で使用するためのクライアント装置で使用される機能素子のブロック図。
【図６】この発明の第一の実施例においてサーバ装置により実行される方法段階の流れ図。
【図７】この発明の第一の実施例において使用されるクライアント装置により実行される方法段階の流れ図。
【図８】この発明の実施例において使用される損失事象レートの計算に含まれる段階を示す流れ図。
【図９】この発明の実施例において使用されるフィルタ係数のグラフ。
【図１０】この発明の実施例において受信機装置で使用されるフィルタ素子のブロック図。
【図１１】この発明の第二の実施例におけるサーバ装置によって実行される方法段階の流れ図。
【図１２】この発明の第二の実施例で使用されるクライアント装置により実行される方法段階の流れ図。
【図１３】この発明の実施例を用いて達成されるデータストリームの一つについて網をまたいだデータスループットのグラフ。
【図１】
2005503722.tif 000013
【図２】
2005503722.tif 000014
【図３】
2005503722.tif 000015
【図４】
2005503722.tif 000016
【図５】
2005503722.tif 000017
【図６】
2005503722.tif 000018
【図７】
2005503722.tif 000019
【図８】
2005503722.tif 000020
【図９】
2005503722.tif 000021
【図１０】
2005503722.tif 000022
【図１１】
2005503722.tif 000023
【図１２】
2005503722.tif 000024
【図１３】
2005503722.tif 000025
【国際公開パンフレット】
2005503722.tif 000026
2005503722.tif 000027
2005503722.tif 000028
2005503722.tif 000029
2005503722.tif 000030
2005503722.tif 000031
2005503722.tif 000032
2005503722.tif 000033
2005503722.tif 000034
2005503722.tif 000035
2005503722.tif 000036
2005503722.tif 000037
2005503722.tif 000038
2005503722.tif 000039
2005503722.tif 000040
2005503722.tif 000041
2005503722.tif 000042
2005503722.tif 000043
2005503722.tif 000044
2005503722.tif 000045
2005503722.tif 000046
2005503722.tif 000047
2005503722.tif 000048
2005503722.tif 000049
2005503722.tif 000050
2005503722.tif 000051
2005503722.tif 000052
2005503722.tif 000053
2005503722.tif 000054
2005503722.tif 000055
2005503722.tif 000056
2005503722.tif 000057
2005503722.tif 000058
2005503722.tif 000059
2005503722.tif 000060
2005503722.tif 000061
2005503722.tif 000062
2005503722.tif 000063
2005503722.tif 000064
2005503722.tif 000065
2005503722.tif 000066
2005503722.tif 000067
2005503722.tif 000068
2005503722.tif 000069
2005503722.tif 000070
2005503722.tif 000071
2005503722.tif 000072
2005503722.tif 000073
2005503722.tif 000074
2005503722.tif 000075
2005503722.tif 000076
2005503722.tif 000077
2005503722.tif 000078
2005503722.tif 000079
【国際調査報告】
2005503722.tif 000080
2005503722.tif 000081
2005503722.tif 000082