JP4263604B2 - ストリーム当りの利用可能な帯域幅とビットストリームのトレードオフを計算する、複数データストリームを送るためのデータ通信方法とシステム - Google Patents

Description

この発明は、データ通信を提供する方法とシステムに係り、とくに複数のデータストリーム（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）による再生のために受信機オーディオバッファ内に記憶された十分なオーディオデータが普通は存在しているのに対し、オーディオデータと同時に再生するためには、受信機ビデオバッファ内に不十分なビデオデータしか存在しないことになる。

各それぞれのストリームに対して伝送レート制御アルゴリズムの別個な適用からは、とくに標準のＴＣＰ伝送レート制御アルゴリズムのもつ乗算式の減少という本質からは別の問題が生ずる。オーディオストリームがＴＣＰ接続上でビデオストリームに対するのとは別に送られている場合を考えるとする。このビデオストリームもＴＣＰを用いて送られているとする。通常は、先に説明したように、各接続の平均のスループットは実質的に同じとなるが、ストリームの一つについてパケット損失が発生する伝送レートでの乗算的な減少に起因して、いずれかの時間的な瞬間に事実上二つのストリームについてのそれぞれの伝送レートにおける大きな差異があり得ることになる。二つのストリーム間で伝送レートに存在するこういった潜在的な大きな短期間の変動がデータ伝送に不確定さをもたらし、かつ受信機内のデータバッファについての問題を生じさせることができて、一時的に大きな差異が生ずることは、例えばオーディオバッファが一杯となってオーバーフローして、それによりデータを失い、それでもなお対応するビデオバッファは空となっていて、それによりＡＶ再生が行なわれるのを妨げることになる。さらに、潜在的な一時的な大きなこれらストリーム間のデータ伝送レートでの差異は、適切な再生にとって二つの形式のデータについての必要とされる伝送レートをしばしば絶縁することができて、それによって先に述べたように後続のデコードと再生とに同じような問題をもたらすことになる。

ＴＣＰ伝送レート制御アルゴリズムを複数のデータストリームに適用することによって生ずるといった上記の問題は、各ストリームについて無接続のＵＤＰプロトコルを用い、かつ単純に各ストリームを適当な転送レートで送ってストリーム間でデータの正しい比を維持するようにすることによって以前に対応されてきた。しかしながら、前記のように、ＵＤＰは、網の輻輳と、この輻輳を介して生じ得る後続のデータ損失を勘案するために伝送レートを制御するために何も備えていない。したがって、網輻輳によって生ずる問題を勘案しながら、正しいデータ比と各ストリームの伝送レートの安定性との両方を維持することができるという伝送レート制御方法とシステムに対する必要性はなお存在している。

発明の要約
この発明は上述の問題に対処するのに、データ伝送の方法とシステムとを提供しており、そこでは網サーバが複数のデータストリームの伝送用に利用可能な全体の（total）伝送レートを伝送レート式を用いて計算する。この式は例えば可能とされる網の輻輳といった各種の因子（factors）を勘案して得られたものである。サーバは次に複数のデータストリームをそれぞれのデータ伝送ビットレートで送り、ストリームのそれぞれのデータ伝送レートを制御してビットレートの和が計算された利用可能な全体のレート以下となるようにする一方で、ストリーム間のビットレートを交換（trading）することによって複数のストリーム間の適当な伝送レートを維持するようにしている。このことが各データストリームについて滑らかな（smooth）定常状態の伝送レートを提供しながら、各ストリーム内で送られることになる異なる形式のデータについての適切な比を維持するという効果をもたらしている。

上記の見方にてらして、この発明の第一の特徴として、網をまたいだデータ伝送の方法が提供される。該方法は、
伝送レート式を用いてデータの伝送のための全体の(total)伝送レートを計算する段階と、受信機に向けて少くとも二つの別個のデータストリームの各々をそれぞれのデータ伝送ビットレートで送るために網上でデータを伝送する段階と、前記ストリーム間でビットレートを交換するためにデータストリームの少くともサブセットのそれぞれのデータ伝送レートを制御する段階とを備え、ここで各データストリームのそれぞれの伝送レートの和は実質的に計算された全体の伝送レート以下である。

第二の特徴からは、この発明はまた網をまたいだデータ伝送用システムを提供し、該システムは、伝送レート式を用いてデータの伝送用の全体の伝送レートを計算するための伝送レート計算手段と、受信機に向けて、少くとも二つの別個のデータストリームの各々をそれぞれのデータ伝送ビットレートで送るために網上にデータを送り出すためのデータストリーム伝送手段と、ストリーム間でビットレートを交換するために少くともデータストリームのサブセットのそれぞれのデータ伝送レートを制御するデータストリーム制御手段とを備え、ここで該データストリーム制御手段はさらに各データストリームについてのそれぞれの伝送レートの和が実質的に計算された全体の(total)伝送レート以下となるように制御されるように動作可能である。
利用可能な全体の(total)伝送レートの計算のために伝送レート式を使用することによって、この発明は網の輻輳と結果として生ずるパケット損失とを複数のデータストリームにとって利用可能とされる全体の帯域幅を計算して考慮することが可能であるという利点を与えている。さらに、各データストリームのそれぞれの伝送レートを利用可能な全体の計算された帯域幅内とするように制御することにより、計算された全体の利用可能な帯域幅の中でそれぞれのストリーム間でビットレートを交換して、各ストリーム内で送られたデータの比を制御することが可能となる。これは各ストリーム間でデータ比を維持するのに適切なレートで各データストリームのスムースな定常状態伝送レートを与えるという効果をもっている。

好ましいのは、各データストリーム内のデータが、例えば、同時に受信機での再生もしくは使用を意図していることと関係している。好ましい実施例では、ストリームの一方でのデータがオーディオデータであり、ストリームの他方でのデータはビデオデータである。

さらに、好ましいのは、データストリームのデータ伝送レートが制御されて、データストリーム内のデータを受領する受信機内のデータバッファが、過剰なレートで充満されるのを防ぐようにする。それぞれの伝送レートをこのやり方で制御することによって、受信機内のデータバッファがオーバーフローを生じないようにすることが可能であり、したがってデータが損失されない結果となる。

さらに、好ましいのは、この発明は帰還データを受信機から受領するようにさらに構成されていて、この帰還データは該受信機で受領した各ストリーム内で少くとも送られたデータのデコード用レートを示しており、そこで少くとも受信機のデコード用レートの関数として、受領したデータに応答してそれぞれのデータストリームの少くともサブセットのデータ伝送レートを制御するようにしている。受信機からのこのような情報を受領することによって、各ストリームについてのそれぞれの伝送レートをさらに動的に制御することが可能であって、定常状態伝送レートを維持しかつそれぞれのデータ比を維持するだけでなく、受信機端末におけるデータバッファの状態を遠隔制御して、バッファのオーバーフローに起因するパケット損失がないことを確かにするようにもする。

好ましい実施形態では、全体の伝送レートが計算されて網上でのデータの平均スループットがトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同じようなものを与えるようにする。このことはこの発明がＴＣＰフレンドリィとなるという利点をもっており、パケット損失比を低減し、帯域幅利用での改善をもたらすとともに網上での競合しているＴＣＰ接続に対しては公平であることを与える。

好ましいのは、この発明が、さらに受信機から帰還データを受領するように構成されていて、このデータはラウンドトリップ時間（ＲＴＴ）と、損失レート値と、及び／又は受信機での受信用レート値のいくつかを示していて、またさらに帰還データによって示されたいくつかの受領した値の関数として全体の(total)伝送レートを計算するようになっている。ラウンドトリップ時間はデータが送信機から受信機に向けてさらに送信機まで戻って来る移動にかかる時間の測度であり、また損失レート値は網内で失なわれる、受信機向けに送られたデータ量の測度である。受信用レート値はラウンドトリップ時間内に受信機により受領されたビットの数である。

受信機からサーバへの帰還(feedback)を与えることによって、更新された情報をサーバに提供することが可能であり、この情報は例えばパケット損失をもたらす網上の輻輳状態を示すものである。サーバはそこで網の現在の状態に依存して利用可能な全体の伝送レートを計算することが可能となり、それによってストリームが送られる伝送レートを最適化することができるようになる。

さらに、この発明の第三の特徴からは計算機プログラムを記憶している計算機読取り可能記憶媒体を提供する。このプログラムは計算機上で実行されるときにはこの発明の第一の特徴による方法を実行する計算機を制御するものである。

好ましいのはこの計算機読取り可能記憶媒体は、光ディスク、磁気ディスク、磁気光ディスク、固体計算機メモリ、もしくはいずれかの他の適当とされるデータ記憶媒体である。

第四の特徴からは、この発明はまた網からデータを受領する方法を提供し、このデータはこの発明の第一または第二の特徴により伝送されたものである。この方法は、少くとも二つの別個のデータストリームの各々をそれぞれのデータ伝送レートで受領する段階と、
各ストリーム内で該受領されたデータをバッファするためにそれぞれのデータバッファに向けて送る段階と、該受領されたデータについてのいくつかの特徴を示しているいくつかの定量的な値を計算する段階と、該計算された定量的な値を送信機に向けてそこから送られたデータについての全体の伝送レートを計算するのに使用するために送る段階とを含む。

受領されたデータの特徴を示している定量的な値の伝送のために与えることによって、送信機からの伝送用に利用可能な全体の伝送レートは現在の網状態をより正確に考慮して計算することができる。

好ましいのは、第四の特徴では、この発明はそれぞれのデコード用レートで各バッファ内のデータのデコードを与えるようにさらに構成されて、ここではそれぞれのデータデコード用レートが計算された定量的な値の少くとも一つとして送信機に向けて送られる。

送信機に向けて、各受信機のバッファ内でのデータデコード用レートが何程であるかを通信することによって、送信機は各ストリームのデータ伝送レートをさらに制御して、受信機内のデータバッファが満ちていないこと、したがってデータがこの理由で失なわれていないことを確かとすることができる。

第五の特徴からは、この発明は網からデータを受領するためのシステムをまた提供し、このデータがこの発明の第一または第二の特徴のいずれかによって送られて、またシステムは少くとも二つの別個のデータストリームをそれぞれのデータ伝送レートで受領するデータ受領手段を備えていて、さらに、少くとも２つのデータバッファはそれぞれの受領したデータストリームからそこにあるデータを受領するように構成されていて、該受領したデータのいくつかの特徴を示すいくつかの定量的な値を計算するための計算手段と、該計算された定量的な値を送信機に向けて送り、そこから伝送されるデータについての全体の伝送レートを計算するのに使用のためにあてるデータ伝送手段とを備えている。

第五の特徴からは、第四の特徴に関して前記したのと同じ特徴と利点とを与えている。

さらに、第六の特徴から、この発明はまた計算機プログラムを記憶する、計算機読取り可能記憶媒体を提供しており、この計算機プログラムは計算機上での実行時に、この発明の第四の特徴による方法を実行するように計算機を制御する。第三の特徴の場合のように、第六の特徴によるこの発明は、磁気ディスク、光ディスク、磁気・光ディスク、固体計算機メモリ等のいずれか一つまたは複数のもので実施されてよい。

この発明の別な特徴と利点とは、以下の好ましい実施例の記述で明らかにされるが、記述は例としての目的に限定して、添付の図面を参照して行なわれる。

この発明の好ましい実施形態を構成している各種の要素の構造と動作とを図３〜１１を参照してここで記述して行く。ここで記述する好ましい実施形態はこの発明の非限定的な適用の例をオーディオとビデオデータのようなマルチメディアデータの伝送に対してしたものであるが、本発明はほとんどどんな適用にも用途が見付けられるものであり、この適用ではいくつかのデータストリームが網上で伝送されることに注目すべきである。

この発明の好ましい実施例を形成している二つの基本要素が図３に示されている。ここでサーバ４０が提供されているのを見ることができ、ここには第一のビデオバッファ４２と第二のビデオバッファ４３とが備えられている。第一のビデオバッファ４２はエンコードされたビデオデータを記憶するように構成されていて、このビデオデータは第一のビデオエンコード用レートで符号化されており、また第二のビデオバッファ４３は第二のエンコード用レート（このレートは第一のバッファ４２内に記憶されたエンコードされたビデオデータのレートより低い）でエンコードされた、第一のものよりも多いエンコードされたデータを記憶するように構成されている。二つのバッファ４２，４３内に記憶されたエンコードされたビデオデータは同じオリジナルデータから得られたものであるが、異なるエンコードされたビデオデータを与えるために異なるエンコード用レートを用いて符号化されたにすぎないことを理解されたい。一般に、第一のバッファ４２内に記憶された符号化されたビデオデータを生成するために使用される高い方のエンコード用レートが原因となって、第一のバッファ４２内のエンコードされたビデオデータは、第二のビデオバッファ４３内に記憶された低い方のエンコード用レートでエンコードされた対応するエンコードされたビデオデータよりも大きなサイズをもっている。好ましいのは、ビデオデータはＨ．６２３エンコーデングを用いて符号化されているが、いずれもの適したビデオ符号化技術も使用できるのであって、その中にはＭＰＥＧなどがあることを理解されたい。

またサーバ４０の中に用意されているものに、オーディオデータバッファ４４があり、これがエンコードされたオーディオデータを記憶するために用意されている。気付いてほしいのは、好ましい実施例では、オーディオデータは単一のエンコード用レートで符号化されるだけであり、したがって、単一のオーディオバッファだけが求められる。好ましいオーディオデータはＡＭＲオーディオエンコーデングを用いて符号化されるが、ＭＰ３などのような他のいずれかの適当なオーディオ符号化技術も使用できる。

サーバ４０だけでなく、この好ましい実施例では、クライアント計算機５０も用意されていて、ビデオバッファ５２とオーディオバッファ５４とを備えている。ビデオバッファ５２はサーバ４０から受領したエンコードされたビデオデータを受領して記憶するように構成されている。ビデオバッファ５２は受領したエンコードされたビデオデータを記憶するが、これはクライアント計算機内に用意されたビデオデコーダがエンコードされたビデオデータをそこから読取って、そこでエンコードされたビデオ信号のデコードと再生にあてるまで記憶する。同じように、オーディオバッファ５４はサーバ４０から送られた、エンコードされたオーディオデータを受領して、このエンコードされたオーディオデータを、クライアント計算機内に用意されたオーディオデコーダがエンコードされたデータを読取ってエンコードされたオーディオ信号のデコードと再生にあてるまでバッファする。

サーバ計算機とクライアント計算機との間でデータ通信を提供するために、第一のユーザデータグラムプロトコル（ＵＤＰ）接続１０がサーバ４０とクライアント５０との間に提供されて、この接続を介してエンコードされたビデオデータがサーバ４０から送られる。同じように、第二のＵＤＰ接続２０もまたサーバ４０から各クライアント５０に向けて提供されて、この接続を介してエンコードされたオーディオデータが送られる。それぞれのＵＤＰ接続１０，２０の伝送レートは後述される方法でサーバによって制御される。

サーバとクライアントとの間のＵＤＰ接続に加えて、好ましい実施例ではトランスポート制御プロトコル（ＴＣＰ）接続３０がクライアントとサーバとの間に設定されて、制御メッセージの伝送を与えるようにしている。この制御メッセージは主としてクライアントからサーバーに向けて戻されるもので、二つのＵＤＰ接続１０と２０の伝送レートの実効的な制御ができるようにする。帰還データで各クライアントから、ＴＣＰ接続上でサーバに向けて送られるものの詳細については後述する。

ここで図４を見ると、図４はサーバ計算機４０内部でこの発明の好ましい実施例で必要とされる要素をブロック図形式で示している。図４はこの発明の動作に必要とされているサーバの部品だけを示していること、また動作に必要とされるサーバシステムの他の要素は示していないことに留意されたい。ここでは、意図された読者は当業者であって、サーバシステムについてのそれが全操作を実行するのに必要としている追加の要素が何であるかを認識する者であるとしている。

好ましい実施例では、サーバ計算機４０は、マルチメディア応用（application）制御器４１を備え、これがエンコードされたオーディオデータとエンコードされたビデオデータとを受領し、そこで受けたデータをバッファ４２，４３，４４内にバッファように、図３に関して前記したように構成されている。留意してほしいのは、こういったバッファは明りょう化のために図４では示されていないことである。マルチメディア応用制御器４１は制御メッセージをＴＣＰ接続３０を介してクライアント計算機５０との間で送受する。さらに、マルチメディア応用制御器はエンコードされたビデオデータとエンコードされたオーディオデータとを適当なバッファから網接続モジュール４７に向けて提供し、モジュール４７は網をまたいでクライアント計算機に向けた伝送のためにデータをパケット化する。したがって、網接続モジュール４７はエンコードされたオーディオとビデオデータとをマルチメディア応用制御器から受領するように動作し、このデータを伝送に適した形態にパケット化して、このデータパケットを二つのそれぞれのＵＤＰデータストリーム内で、適切とされるそれぞれの送りレートで網に向けて送る。データストリームのそれぞれの送り用レートは送り用レート計算器４６により後述の適当な伝送レート式により計算される。送り用レート計算器４６はオーディオとビデオのデータストリームについての計算された送りレートを網接続モジュール４７に向けて送り、網接続モジュール４７に計算された伝送レートについて通知するようにしている。好ましい実施例では、送り用レート計算器４６で計算された伝送レート式に向けた入力データはクライアント計算機からマルチメディア応用制御器に向けたＴＣＰ接続上で得られていて、この制御器から網接続を経由して送り用レート計算器に向けてデータが送られる。

網制御器モジュール４８はさらに、網接続４７を制御するために用意されていてオーディオとビデオとのデータが網上で送られるようにするために適切なデータのパケット化プロセスを実行する。

さらに、再伝送バッファ４９はメモリなどであり、これが与えられていて、網接続４７から適切な制御信号と一緒にデータパケットを受領し、受領したデータパケットをバッファして、このバッファしたパケットを網接続４７が再送しなければならない事象に備えるように構成されている。送られたデータパケットのバッファ動作と再送動作とはこの発明にとって特有のものではないのでこれ以上の詳細についてはここではふれない。

図４に示されてはいないが、さらに次のことについては留意されたい。サーバ計算機４０はさらに少くとも一つの計算機読取り可能記憶媒体を含んでいて、これが計算機プログラムを記憶し、このプログラムがこの発明を実施するためにサーバ計算機の動作を制御する。計算機読取り可能記憶媒体は既知のいずれの形式のものでもよく、とくに、光ディスク、磁気ディスク、磁気・光ディスク、固体計算機メモリ、あるいは他の適当なデータ記憶媒体のうちの一つまたは何らかの組合せから形式されるものでよい。

図５はこの発明の好ましい実施形態で必要とされるクライアント計算機５０の機能素子のブロック図を示す。サーバ計算機４０と同じように、図５は動作上クライアント計算機５０にとって必要とされる部品のすべてを示しておらず、この発明の好ましい実施例の動作にとって必要とされる機能ブロック素子だけが示されていると理解されたい。読者として意図されているのは当業者であって、全動作に必要とされる他のクライアント計算機部品はどれかは理解できる者としている。

クライアント計算機５０内部では、マルチメディア応用制御器５１が用意されていて、この制御器はサーバ内で用意されたマルチメディア応用制御器４１と対応している。マルチメディア応用制御器５１は、クライアント計算機５０内で実行しているマルチメディアアプリケーション（application）の高いレベル制御を提供し、またサーバ内の対応しているマルチメディア応用制御器４１と、ＴＣＰ接続３０上で送られる制御メッセージを介して通信する。同じように、マルチメディア応用制御器５１は制御信号をクライアント計算機５０の他の機能素子に提供し、このクライアント計算機は好ましい実施例を構成するものとなっている。

さらにクライアント計算機５０内に用意されているのが網接続モジュール５７であって、これは網からのデータパケットをいくつかのデータストリームの中で受領するように構成されている。いくつかのデータストリームの中で受領したデータに関する制御情報は測度計算器５６に送られて、受領したデータストリームのある種の特性を示す定量的な値の計算にあたり、計算された定量的な値は帰還(feedback)送信機５８に送られて、ＴＣＰ接続３０上で制御メッセージとして網を通って送り戻すのにあてられる。定量的な値の計算についてのさらなる情報は後に与えられる。

網接続５７はオーディオとビデオとのデータストリームを受領して、各ストリーム内のパケットからエンコードされたオーディオとビデオとのデータを読取る。エンコードされたオーディオとビデオとのデータは次にバッファ制御器５９に送られて、制御器は受領したエンコードされたオーディオデータをオーディオバッファ５４に供給し、また受領したエンコードされたビデオデータをビデオバッファ５２に供給する。バッファ制御器５９はさらにオーディオバッファ５４とビデオバッファ５２の状態を監視して、各バッファがどのくらい一杯であるかを判断し、また、各バッファが空となるレート（これはそこに記憶されたデータのデコード用レートを示している）を判断するように構成されている。オーディオデコーダ５３はさらに用意がされていて、オーディオバッファ５４からエンコードされたオーディオデータを読取り、かつエンコードされたオーディオデータをデコードして、デコードされたオーディオデータを出力として提供する。同じように、ビデオデコーダ５５が用意されて、これがビデオバッファ５２からエンコードされたビデオデータを取得し、エンコードされたビデオデータをデコードしてビデオ出力信号を提供する。

バッファ制御器５９は、オーディオとビデオとのバッファの状態に関する情報を受領すると、この情報を帰還送信機に向けて送り、ＴＣＰ接続３０上でサーバ計算機に送り戻された制御メッセージの中に組入れるようにする。

図５には示されていないが、クライアント計算機はさらに少くとも一つの計算機読取り可能記憶媒体を含んでいて、そこには計算機プログラムを記憶し、このプログラムはクライアント計算機がこの発明を実行する動作を制御することに注目すべきである。計算機読取り可能記憶媒体は既知の形式のいずれであってもよく、とくに光ディスク、磁気ディスク、磁気・光ディスク、固体計算機メモリ、あるいはいずれか他の適切なデータ記憶媒体のいずれか一つもしくは組合せの形式とすることができる。

この発明のサーバ装置とクライアント計算機装置を形成している基本的な機能ブロックを記述したので、今度は本発明の好ましい実施例の動作の記述をこれから記載して行く。

図６はこの発明の好ましい実施例によりサーバ計算機４０により実行される段階の流れ図である。第一に、段階２では、送り用レート計算器４６はサーバ計算機４０から送られることになる個々のデータストリームのすべてにとって利用可能な全帯域幅を計算する。この値total_rateは伝送レート上の上限を表わしていて、この上限を各別個のデータストリームの個々の伝送レートはお互い合計されたときに越えてはならない。この値total_rateは次の原理により計算される。

一般に、以前のマルチメディアコンファレンス適用であって、現在インターネットで使用されているものは、ＵＤＰトランスポートプロトコルに基づいていて、このプロトコルは、以前に論じたように、サービスの品質制御機構を何も提供しておらず、それ故に、例えば網輻輳を補償するのに必要であるような制御動作を実行する能力はない。したがって、網輻輳が発生するときに、競合しているＴＣＰ接続は、ＵＤＰトラヒックに代っていずれかのレート低減なしに前述したように伝送レートを減じる。

この問題を回復させるために、この発明では、ＵＤＰオーディオとビデオとのデータストリームは輻輳制御方式で強化され、total_rateパラメータの計算は該方式の一部を形成している。とくに、パラメータtotal_rateは合計（total）の伝送レートを提供するために計算され、このレートは“ＴＣＰフレンドリィ”であって、伝送レートとなっていて、この伝送レートは時間にわたりＴＣＰ接続を介して達成されたスループットと類推できるものとなっている。

好ましい実施例では、全体の(total)伝送レートパラメータtotal_rateが伝送レート式を用いて計算され、この式はＴＣＰ接続の時間にわたる平均スループットをモデル化するように求められて、したがって、全体のレートはＴＣＰフレンドリィな伝送レートを与えるように計算される。好ましい実施例では下記の式１で示した伝送レート式を使用している。

bit_rate_stream＝ｃ((packet_medium_size)／(RTT)√(loss_rate)) （式１）
上記のユビキタス（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値を与え、この値は単一のＴＣＰ接続が現在の網状態で達成できる平均帯域幅の推定値である。しかしながら、好ましい実施例では、この推定値を直接にあるストリームについての全体の伝送レートとして使用せず、むしろこの値bit_rate_streamは次の式２に入れられる。
total_rate_stream＝min(bit_rate_stream, 2^* receiving_rate_stream) （式２）
パラメータreceiving_rate_streamはクライアント計算機からＴＣＰ接続上で受領され、クライアントによって特定のストリームについて受領されたビット数に対応していて、このストリームについては計算はＲＴＴ秒内に行なわれる。

上記の式２はＴＣＰフレンドリィ性能を与えるために単一のＵＤＰストリームについて利用可能な全体の帯域幅を与える。しかしながら、本実施例では、我々は複数のストリームの伝送に関心があり、このため上記計算は伝送されるべき各ストリームについて別個に実施されなければならない。即ち、式１と式２の両方が各ストリーム（即ち、本実施例ではオーディオとビデオのストリーム）に対して順番に適用されて、total_rate_stream値が各ストリームに関して見出される。こうして各ストリームに関して見出されたそれぞれの値が互いに合計されて、値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_video＝video_rate−decoding_video_rate （式４）
受信機でのバッファの制御はバッファが比ｘ：ｙで充填するように要求されていると仮定すると、そのときは
ｘ（filling_rate_audio）＝ｙ（filling_rate_video） （式５）
であり、また
total_rate＝audio_rate＋video_rate （式６）
である。

適当な代入を実行し、audio_rateとvideo_rateをそれぞれを解くことにより式７と式８とが与えられる：
audio_rate＝［y(total_rate-decoding_video_rate)
＋x(decoding_audio_rate)］／（ｘ＋ｙ） （式７）
video_rate＝［x(total_rate-decoding_audio_rate)
＋y(decoding_video_rate)］／（ｘ＋ｙ） （式８）
したがって、上記から明らかなように、それぞれのオーディオ送り用レートとビデオ送り用レートを制御して、受信機内でのそれぞれのオーディオとビデオのデコードレートに依存して一方のストリームから他方のストリームにビットレートを交換するようにすることが可能となる。さらに、上のことから注意すべきことは、パラメータtotal_rateは式１と２とを適用することから前に計算された値であってデータストリームのすべての伝送のために利用可能な全体の利用可能帯域幅、すなわち、total_rate＝total_rate_stream_1＋total_rate_stream_2＋…＋total_rate_stream_n（ここでｎは同時に送られるデータストリームの数である）を与えるものであることである。

図６に戻ると、各ストリームについてオーディオとビデオの送りレートを計算した後で、段階Ｓ６では、サーバにおける網接続４７はオーディオとビデオのストリームを分離されたＵＤＰデータストリームとして、計算されたオーディオとビデオの送りレートで送る。このオーディオとビデオのストリームは連続して送られるので、図６の段階は、継続的に示しているものの、実際には並列に実行されて、オーディオとビデオのストリームの伝送レートは現実にはオーディオとビデオの伝送レートについて新しい値が計算されると更新される。しかしながら、この新しい計算が実行されている間には、これらのストリームは以前に計算したレートで送られ続けることになっている。

図１１は図２にプロットされたＴＣＰ接続により送られたのと同じデータを送っているときにこの発明の好ましい実施例により制御される一つのデータストリームについての測定された伝送レートのプロットを示し、図１１からは、このセッションの開始時に経験した初期の過渡的な変化の後に、ストリームの伝送レートは安定となって、時間に対して比較的僅かな変動で連続することがわかる。さらに、図２に示したＴＣＰ接続により経験された伝送レートと比較するときは、殆んど同一の平均スループットがＴＣＰのように達成されるが、ＴＣＰの乗算式の減少制御アルゴリズムからの結果である伝送レートに大きな変化を伴うことがないことが分かる。この時間に関して滑らかな伝送レートを与えるという性質は、この発明を連続するストリーミングを求めるデータを送るときでの使用にとくに適切なものとなっている。

図６の段階Ｓ８では、サーバ計算機４０は帰還データをクライアント計算機５０から受領する。好ましい実施例ではこのデータは段階Ｓ２と段階Ｓ４の全体の伝送レートとデータストリーム伝送レートの計算を実行するために必要とするものである。とくに各ストリームについて、サーバはクライアントにおいて現在経験しているラウンドトリップ時間と、クライアントでのパケットの損失レートと、クライアントにおけるオーディオとビデオのバッファのそれぞれのデコード用レートと、クライアントにおける各データのデータストリームのデータ受信レートとについて知らせるデータをサーバが受領する。こういった定量的な値はサーバに向けてＴＣＰ接続を経由して各クライアントから送り戻される。

いったん更新された帰還データがクライアントから受領されたならば、これがサーバ内の送り用レート計算器４６に送られて、ここで段階Ｓ２とＳ４での計算をもう一度行ない、その結果が網接続４７に向けて送られる。この網接続はオーディオとビデオのストリームを新しい計算された送り用レートで送る。このプロセスはクライアントのセッションの間に連続している。

定量的な値であってクライアント計算機からサーバに向けて送り戻されたものについての計算を、図７において展開されたようにクライアント計算機の動作に関して論述することとする。図７を参照すると段階Ｓ１ではクライアント計算機５０内での網接続５７は別々のオーディオとビデオのデータストリームを、網上での個々のＵＤＰ伝送として受領する。前述のように、網接続５７はそれぞれのＵＤＰストリームからのエンコードされたオーディオとビデオのデータのパケット化を解いて（depacketises）、このエンコードされたオーディオとビデオのデータをバッファ制御器５９に向けて送り、バッファ化と後のデコード化とにあてる。

バッファ制御器５９によって受領されたエンコードされたオーディオとビデオのデータはそれぞれオーディオバッファ５４とビデオバッファ５２に記憶される。段階Ｓ３では、バッファ制御器５９はオーディオバッファ５４とビデオバッファ５２とにそれぞれ問合せをして各バッファの状態を判断するようにする。とくに、バッファ制御器は各バッファはどのくらい充填されているかと、どのくらい速くにエンコードされたオーディオとビデオの情報であって各バッファ内にあるものがそれぞれのオーディオとビデオのデコーダ５３，５５によってデコードされているかについての情報を判断する。これがどのくらい速くオーディオとビデオのバッファがそれぞれのデコーダによって空にされているかを示すものとなっている。バッファ制御器がオーディオとビデオのバッファの状態を判断すると、判断された情報が帰還送信機５８に送られて、制御メッセージの中に閉じ込められ（encapsulation）、サーバ計算機４０への戻り伝送にあてられる。

エンコードしたオーディオとビデオデータをバッファ制御器に向けて送ることに加えて、網接続５７はまた受領したデータに関する情報を測度計算器５６に向け送り、測度計算器５６が帰還送信機５８によりサーバに向けて送り戻された定量的な測度値を計算できるようにする。したがって、段階Ｓ５，Ｓ７，及びＳ９では、測度計算器がそれぞれ各ストリームについてラウンドトリップ時間（ＲＴＴ）と、損失事象のレートと、ストリーム当りの受領したデータレートとを計算し、これらの計算値はすべてサーバにおいて式１と２との入力として必要とされているものであり、データストリームについて利用可能な伝送レートの計算にあてられる。三つの測度が各受領したデータストリームについて個々に計算され、一組の測度が各受領したデータストリームについて与えられるようになっていることに留意されたい。こういった定量的の値の各々についての計算は次に論じられる。

ＲＴＴに関しては、前述の通り、ＲＴＴがパケットがある計算器から網をまたいで他の計算機に行って戻って来る移動にかかる時間の測定値である。ＲＴＴはそれ故にクライアント計算機において測度計算器５６内部で測定された何かであるが、発振（oscillations）防止のために次式で計算されるのが好ましい。

ＲＴＴ＝０．２^* ＲＴＴ_sample＋０．８^* ＲＴＴ_mean （式９）
値ＲＴＴ_sampleは測度計算器によって測定されたＲＴＴの最新の測定値であり、また値ＲＴＴ_meanは以前のＲＴＴの全測定値の平均値である。

段階Ｓ７では、測度計算器５６はクライアント計算機で経験したストリーム当りの損失事象レートを計算する。損失事象レートの計算は最も複雑な計算であり、この計算は速度計算器５６が実行しなければならないものであり、また到着するパケットの一連番号からＵＤＰストリーム内の失なわれたパケットの検出に依存している。この失なわれたパケットの検出は到着するパケット内のパケット一連番号の検出に基づいて網接続により実行され、ここでは予期されたパケットが失なわれたと定義されるが、その条件は少くとも三つのパケットであって予期されたパケットよりも大きな一連番号をもつものが、予期されたパケットが到着していない状態で、受信機に到達するものである。したがって、もし一連番号５をもつパケットが予期されているとすると、そのときは到達する次のパケットがパケット６，パケット７，そしてパケット５である場合には、このときはパケット５は損失されたと定義されない。しかし次の３つのパケットで順に到着するものがパケット７，８，そして６であると、そのときは到着したパケットの三つ各々が予期されたパケット番号５よりも大きなシーケンス番号であるから、パケット５は損失と定義される。

上記のようにパケットが損失としてどのように定義されるかを特定した上で、測度計算器は損失事象（loss event）として知られる別の出現（occurrence）を定義する。好ましい実施例では、損失事象はいずれかのＲＴＴ測定においていくつかのパケットの損失の検出として定義されている。したがって、もしいずれかの特定のＲＴＴ測定で、パケットでその番号が４，６，７，９，１０、１１のものが到着したとすると、そのときは、パケット５と８とは失なわれているけれども、特定の測定されたＲＴＴでは実際には一つだけの損失事象であったとされる。この方法は網内で同時に失なわれている複数のパケットについても説明されるところであり、全体の損失事象のレート計算に過度に影響を与えるものではない。

上述のように損失事象がいったん検出されると、ステップＳ７４において測度計算器５６は最近の損失間隔（loss interval）を計算する。これは現在検出された損失事象と以前に検出された損失事象との間で受領されたパケットの数である。測度計算器は新しく計算された損失間隔を、ｎ個の最近計算した損失間隔と一緒に記憶して、平均損失間隔値を与えるために加重したフィルタでの応用にあてる。平均損失間隔値は次のように計算される。

図９と１０とを参照すると、図１０は測度計算器を作り上げている若干の機能素子を示しており、これらの素子が損失レートの計算のために使用されている。とくに、損失事象検出器５６２は前述したように損失事象を検出して、最新計算された損失間隔を多数の直列接続された(serially-connected)損失間隔バッファ５６４の第一のものに向けて出力する。新しい損失間隔が第一のシリーズバッファ５６４に入力されるときは、前の損失間隔値として第一のバッファ内に保存されているものが次のバッファへとシフトされ、ここで言う次のバッファの値はシリーズ内の次のバッファというように順にシフトされることが図１０に示されている。この方法では、ｎ個の最新の損失間隔値は平均損失間隔値を計算するのに使用するために記憶される。シフトバッファ５６４内に記憶された各損失間隔値は、時間加重された損失間隔係数Ａ０〜Ａｎによりそれぞれ乗算される。この係数はそれぞれの係数メモリ６５６に記憶されている。係数の個々の値Ａ０〜Ａｎは図９に示したように、時間加重された係数関数に従って求められ、この関数は最近の損失間隔が平均損失間隔の計算に向けて前の計算から記憶された歴史的な損失間隔よりも大きな拡がり（extent）までカウントすることを確かにする。この時間加重したフィルタを応用する目的は、計算された損失事象レートが滑かに変化することを確かにすることである。

加重された損失間隔計算の結果は合算機器（summer）５６６で合算され、その結果はインバータ５６８に向けて送られて、損失レートの計算にあてられ、合算機器５６６により計算された平均損失間隔の逆数となる。こうして計算された損失レートはそこで帰還送信機５８に送られて、前記のようにサーバ計算機に向けた伝送にあてられる。

受領したデータレートの計算はまた測度計算器５６によっても実行され、ＲＴＴ秒内のデータストリーム内でクライアントにより受領されたビットの数の直截的な（straightforward）測定値となる。各ストリーム内のいずれかの一時刻で受領されるデータ量に関する情報は網接続５７から測度計算器５６に向けて送られて、ストリーム毎の受信レートの計算にあてられる。計算されたストリーム毎の受信レートはそこで帰還送信機５８に向けて送られて、前述のようにサーバ計算器に向けて送り戻されるようにする。

いったん帰還送信機５８がバッファ制御器５９と測度計算器５６からの必要とされる情報を受領したときには、送信機はこの情報をＴＣＰ接続３０内の網上での伝送に適した形式にパケット化する。

図７の流れ図に示された段階Ｓ１〜Ｓ１３は例示だけの目的のものであり、またクライアント計算機５０は事実所望されるどんな順序でもこれらの段階のいずれかあるいは全部を実行できる。さらに、これらの段階のいくつかを並列に実行することも可能であり、例えば、バッファ制御器５９により実行されたオーディオとビデオとのバッファのチェックと測定とは測度計算器５６によって実行される計算と並列に実行されることができる。しかしながら、好ましい実施例では、受信機にとっては、サーバ計算機に向けて送り戻される定量的な値を計算するのに必要な情報を持つために、オーディオとビデオとのデータストリーム内に実際に受領したデータを持つことが必要であることに留意されたい。

サーバ内部では、各ストリームの実際の伝送レートは網制御器４８と網接続４７との組合わせで制御されていて、計算されたレートに従って網上にパケットを実際にレリーズすることによって行なわれる。しかしながら、好ましい実施例で記述したオーディオとビデオデータの伝送をする特別な場合には、ビデオデータに関して、特に計算されたレートは使用された特定のエンコードレートについての伝送レート要求を満足しないことになることもあり得る。この場合に、ビデオストリームについての計算された伝送レートが低下して、現在のビデオエンコードレートで、ビデオストリーム内で十分なデータを送り、受信機にあるビデオバッファを空にすることを妨げることができないように思われれば、網制御器４８は網接続４７を制御して低レートエンコード用ビデオバッファ４３からエンコードされたビデオデータを採り出すようにし、これが低品質でエンコードされていて、より低い計算された伝送レートで網をまたいだ伝送により適切なものとなっている。受信機では、低レートのエンコードされたビデオデータはビデオバッファ内に置かれていて、ビデオデコーダ５５は低い方のレートのエンコードを検出して、自己のデコードレートをより低いレートに変えて、これがビデオデータをビデオバッファから読取るレートに低減する。このような測定値がビデオバッファを完全に空にすることを防いで、それによりクライアント計算機における連続したビデオ再生を可能ににしている。

この発明の好ましい実施例はオーディオとビデオとのデータを複数のデータストリームとして送ることを指向しているので、好ましい実施例内部では、各ストリームのそれぞれのビットレートを設定するための規準はオーディオとビデオのデータの特別な要件を反映するように選定されていて、もとのオーディオとビデオとの信号を再生するために受信機でそのようにデコードされなければならないことに留意されたい。しかしながら、この発明は複数のデータストリームとしてのオーディオとビデオデータの伝送に限定されておらず、事実いくつかのストリームの中での送りが求められているいずれもの形式のデータがこの発明を用いて伝送される。さらに、これらのストリーム間でビットレートを交換するために選ばれた特定の規準がデータが置かれることになる応用に依存することになる。例えば、この発明の他の実施形態を想定することも可能であり、この場合にデータは複数のストリーム内で送られて、多数のセンサがマウントされている例えば遠方のビークル（vehicle）の遠隔制御に影響を与えるようにする。このようなビークルは、例えば海中の潜水可能な探査ビークルなどであってよく、そこには無線網接続が備えられている。このような場合には、データの複数のストリームが潜水艇の操縦素子へ操縦制御情報を与えることが必要とされ、また個々のセンサに向けてセンサ制御情報を与えることが必要とされてよい。このようなデータストリーム間でビットレートが交換されるようにする規準は、オーディオとビデオとのデータを伝送することに関係するこの発明の好ましい実施例で必要とされるものとは異なることになり、したがって、一方のデータストリームから他へのビットレートの交換を制御するために選ばれる規準は応用に依存することになるのは明らかである。

さらに、この発明で使用される利用可能な全部の伝送帯域幅の計算に関しては、好ましい実施例では伝送レート式が使用されたが、この式は標準のＴＣＰ接続によって得られる平均のスループットをシミュレートすることが意図されている。しかしながら、この特定の式もまたこの式を使用する理由もこの発明での限定となることを意図したものでないことを理解されたい。また事実、いずれか適当な伝送レート式が利用可能な全体の伝送レートを計算するために使用できて、このレートは次に個々のストリーム伝送レートを計算するために使用されることを理解されたい。

とくに、また例として、伝送がインターネットプロトコル網上で行なわれることになるところでは、ＴＣＰフレンドリィな伝送レートを与える他の伝送レート式がこの特殊な実施例で使用される式のかわりに使用できるのであって、各種の他のＴＣＰフレンドリィな式が現在では当業者の知るところである。さらに、異なるパラメータ入力として必要とする異なる式が用いられるところではクライアント計算機はサーバによって必要とされているパラメータはどんなものでも計算して供給するように構成しなければならない。ＩＰ網が使用されない場合には、選ばれた伝送レート式は関心のある特定の網上で使用されているどんなトランスポートプロトコルに対しても有意なものとなっているべきであることが好ましいし、また網輻輳と結果として生ずるパケット損失などのような因子を計算に入れるために有意の伝送レート制御を提供することが好ましい。この発明の他の実施例では、どんな伝送レート式が適切であるかが、本発明の応用の特定分野に依存していて、それが当業者にとって明らかになる。

ＴＣＰスループットをシミュレートするために使用することができる別の伝送レート式の例であって、上述したような別の式の例を次に記述する。

スループット方程式で下記のものはRenoＴＣＰ用のスループット方程式の僅かに簡単化したものである。この発明では式１に代って使用されることができてストリーム当りの伝送レートの計算することができる。このスループット式は、
Ｘ＝ｓ／[R^*sqrt（2^*b^*p/3）＋（t_RTO^*(3^*sqrt(3^*b^*p/8)^*p^*(1＋32^*p^2))）]
（式１０）
ここでＸは伝送レート（バイト／秒単位），
ｓはバケットのサイズ（バイト単位），
Ｒはラウンドトリップ時間（秒単位），
ｐは損失事象レートであり、０と１．０の間。送られたパケット数の一分としてパケット損失事象の数についての割合となっている，
t_RTOはＴＣＰ再伝送時間切れ値（秒単位），
ｂは単一のＴＣＰアクノレッジにより受領告知されたパケットの数である。

ラウンドトリップ時間と損失事象レートであって上記で使用されるものは前述のように計算される。さらにこの評価をさらに簡単化することができ、そのためにはt_RTO＝４^* R と設定する。もっと正確なt_RTOの計算が可能であるが、現在の設定での実験は既存のＴＣＰ実施で妥当な公平さをもたらしている。別の可能性はt_RTO＝max（４Ｒ，１秒）に設定されて、ＲＴＯに１秒という推奨される最小値を整合させるものである。

この発明の実施例で上記の方程式を前述のように使用するものでは、上記式１０は単に先に記述した実施例での式１に代入される。他の処理段階は実質的に同じもののままである。

先行技術のマルチメディアストリーミングシステムの要素を示す例示ブロック図。 先行技術のＴＣＰプロトコルを用いる網のデータスループットを示すグラフ。 この発明で使用されるサーバ及びクライアント装置の構成を示すブロック図。 この発明の実施例で使用するためのサーバ装置の主要素のブロック図。 この発明の実施例で使用するためのクライアント装置で使用される機能素子のブロック図。 この発明の実施例においてサーバ装置により実行される方法段階の流れ図。 この発明の実施例において使用されるクライアント装置により実行される方法段階の流れ図。 この発明の実施例において使用される損失事象レートの計算に含まれる段階を示す流れ図。 この発明の実施例において使用されるフィルタ係数のグラフ。 この発明の実施例において受信機装置で使用されるフィルタ素子のブロック図。 この発明の実施例を用いて達成されるデータストリームの一つについて網をまたいだデータスループットのグラフ。

Claims (29)

1. 送信側から受信側へ網をまたいだデータ伝送の方法であって、該方法は、
   伝送レート式を用いてデータの伝送用の全体の伝送レートを計算する段階と、
   受信機に向けて少くとも二つの別個のデータストリームを各々がそれぞれのデータ伝送ビットレートで伝送するために網上でデータを送り、該受信機からフィードバックデータを受領する段階と、
   該受領したフィードバックデータに応答して、該それぞれのデータストリームの二つの少くともサブセットのそれぞれのデータ伝送レートを制御して、前記ストリーム間で所定のデータ伝送レートを維持するために、該ストリーム間でビットレートを交換する段階とを備え、
   各データストリームのそれぞれの伝送レートの和は、実質的に該計算された全体の伝送レート以下であり、
   前記データの伝送用の全体の伝送レートを計算する段階は、前記データの伝送前に送信側で実行される、方法。
2. 請求項１記載の方法において、該データストリームの該データ伝送レートは、該データストリーム内の該データを受領する受信機内のデータバッファのオーバーフローを妨げるように制御される方法。
3. 請求項２記載の方法において、該受領した帰還データは該受信機で受領した各ストリーム内の伝送されたデータの少くともデコード用レートを示しており、また該制御されたデータストリームの伝送レートはさらに少くとも該受信機のデコード用レートの関数として制御される方法。
4. 請求項３記載の方法において、二つのデータストリームの場合であって、それぞれのデータ伝送レートが下記の式により制御される方法：
   sr_str_1＝[y(tr-dr_str2)＋x(dr_str1)]／(x+y)
   sr_str_2＝[x(tr-dr_str1)＋y(dr_str2)]／(x+y)
   ここで変数は次の関係があるものとする；
   sr_str_1：第一のデータストリームの送りレート
   sr_str_2：第二のデータストリームの送りレート
   tr：計算された全体の伝送レート
   dr_str1：第一のデータストリーム内のデータの受信機におけるデコード用レート
   dr_str2：第二のデータストリーム内のデータの受信機におけるデコード用レート
   ｘ：第一のデータストリームからデータを受領する受信機の第一のバッファの充填用レートの係数
   ｙ：第二のデータストリームからデータを受領する受信機の第二のバッファの充填用レートの係数。
5. 請求項１ないし請求項４のいずれか１項記載の方法において、全体の伝送レートは計算されて網上でのデータの平均スループットをトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同じとなるように与える方法。
6. 請求項１ないし請求項５のいずれか１項記載の方法において、該計算する段階はさらに、
   ラウンドトリップ時間値（ＲＴＴ）と、損失レート値と、並びに／または該受信機における受信レート値のいくつかを示している該受信機からの帰還データを受領する段階と、
   該全体の伝送レートを該帰還データによって示されたいくつかの受領した値の関数として計算する段階とを備え、
   該ラウンドトリップ時間は送信機から該受信機に向いかつ該送信機に戻る移動をするためにデータが要する時間の測度であり、該損失レート値は該受信機に向けて送られた失なわれたデータの量の測度であり、また該受信レート値はラウンドトリップ時間内に受領されたビットの数である、方法。
7. 請求項６記載の方法において、全体の伝送レートは下記の式により計算される方法、
   bit_rate_per_stream_x＝c((data_medium_size)／(t_RTT√(loss_rate)))
   ここで：
   total_rate_stream_x＝min(bit_rate_per_stream_x, 2×Receiving_Rate_x)であり、
   また、total_rate＝total_rate_stream_1＋total_rate_stream_2＋…+total_rate_stream_nであり、
   ここでｘ∈｛１，２，…，ｎ｝であり、data_medium_sizeは網をまたいで送られるストリーム当りのデータの平均サイズの測度であり、またｃは定数であって０．８７＜ｃ＜１．３１の範囲のものとし、ｎは送られることになるデータストリームの数である。
8. 請求項１ないし請求項７のいずれか１項記載の方法において、複数のデータストリームの少くともサブセットで送られたデータは関係がある方法。
9. 請求項８記載の方法において、前記データストリームの少くとも一つは第一の形式の実時間データを含み、かつ前記データストリームのいくつかの他のものは該第一の形式の該データと関係した第二の形式の実時間データを含んでいる方法。
10. 複数のデータストリームを生成し、次に請求項１ないし請求項９のいずれか１項記載のデータ伝送方法を使用して網上で前記データストリームを送信する方法。
11. 送信側から受信側へ網をまたいだデータ伝送用システムであって、
    伝送レート式を用いてデータの伝送用の全体の伝送レートを計算するための伝送レート計算手段と、
    データを網上で受信機に向けた伝送のために、少くとも二つの別個のデータストリーム内でそれぞれのデータ伝送ビットレートで送り、該受信機からフィードバックデータを受領するためのデータストリーム伝送手段と、
    該受領したフィードバックデータに応答して、該それぞれのデータストリームの二つの少くともサブセットのそれぞれのデータ伝送レートを制御して、前記データストリーム間で所定のデータ伝送レートを維持するために、前記ストリーム間でビットレートを交換するためのデータストリーム制御手段とを備え、
    該データストリーム制御手段はさらに、各データストリームのそれぞれの伝送レートの和が、計算された全体の伝送レート以下に実質的になるように制御されるよう動作可能であり、
    前記伝送レート計算手段は、前記データの伝送前に送信側で前記全体の伝送レートを計算するように構成された、システム。
12. 請求項１１記載のシステムにおいて、該データストリーム制御手段はさらに該データストリームの該データ伝送レートを制御して、該データストリーム内のデータを受領する受信機内のデータバッファが、オーバーフローを生じないよう防止するように構成されているシステム。
13. 請求項１２記載のシステムにおいて、該受領した帰還データは該受信機において受領した各ストリーム内の伝送されたデータの少くとも該デコード用レートを示すものであり、かつ該データストリーム制御手段はさらに該制御されたデータストリームの該伝送レートを少くとも該受信機のデコード用レートの関数として制御するように構成されているシステム。
14. 請求項１３記載のシステムにおいて、二つのデータストリームの場合には、それぞれの伝送レートが下記に式により制御されるシステム、
    sr_str_1＝[y(tr-dr_str2)＋x(dr_str1)]／(x+y)
    sr_str_2＝[x(tr-dr_str1)＋y(dr_str2)]／(x+y)
    ここで変数は次の関係があるものとする；
    sr_str_1：第一のデータストリームの送りレート
    sr_str_2：第二のデータストリームの送りレート
    tr：計算された全体の伝送レート
    dr_str1：第一のデータストリーム内のデータの受信機におけるデコード用レート
    dr_str2：第二のデータストリーム内のデータの受信機におけるデコード用レート
    ｘ：第一のデータストリームからデータを受領する受信機の第一のバッファの充填用レートの係数
    ｙ：第二のデータストリームからデータを受領する受信機の第二のバッファの充填用レートの係数。
15. 請求項１１ないし請求項１４のいずれか１項記載のシステムにおいて、該全体の伝送レートは計算されて、該網上でのデータの平均スループットがトランスポート制御プロトコル（ＴＣＰ）を用いて得られたものと同様のものを与えるようにするシステム。
16. 請求項１１ないし請求項１５のいずれか１項記載のシステムにおいて、該システムはさらにラウンドトリップ時間（ＲＴＴ）値、損失レート値、及び／または該受信機における受信レート値のいくつかを示す該受信機からの帰還データを受領するデータ受領手段を備え、また該伝送レート計算手段はさらに該帰還データにより示されたいくつかの該受領された値の関数として該全体の伝送レートを計算するように構成されて、
    該ラウンドトリップ時間は、データが送信機から受信機へ向けてさらに送信機に向けて戻る移動にかかる時間の測度であり、該損失レート値は該受信機に向けて送られたデータの失なわれた量の測定であり、また該受信レート値は該ラウンドトリップ時間内に受領されたビット数である、システム。
17. 請求項１６記載のシステムにおいて、該全体の伝送レートは下記式により計算されるシステム、
    bit_rate_per_stream_x＝c((data_medium_size)／(t_RTT√(loss_rate)))
    ここで：
    total_rate_stream_x＝min(bit_rate_per_stream_x, 2×Receiving_Rate_x)であり、また、total_rate＝total_rate_stream_1＋total_rate_stream_2＋…＋total_rate_stream_nであり、
    ここでｘ∈｛１，２，…，ｎ｝であり、data_medium_sizeは網をまたいで送られるデータ当りの平均サイズの測度であり、またｃは定数であって０．８７＜ｃ＜１．３１の範囲のものとし、ｎは送られることになるデータストリームの数である。
18. 請求項１１ないし請求項１７のいずれか１項記載のシステムにおいて、少くとも二つ以上のデータストリーム内で送られたデータが関係づけられたものであるシステム。
19. 請求項１８記載のシステムにおいて、前記データストリームの少くとも一つが第一の形式の実時間データを含み、また前記データストリームの他のいくつかが該第一の形式のデータと関係した第二の形式の実時間データを含んでいるシステム。
20. 計算機上で実行されるときには、請求項１ないし請求項１０のいずれか１項記載の方法を実行するために該計算機を制御する計算機プログラムを記憶する計算機読取り可能記憶媒体。
21. 請求項１ないし請求項１０のいずれか１項記載の伝送の方法によるか請求項１１ないし請求項１９のいずれか１項記載のシステムにより送られたデータを網から受領する方法であって、該方法は、
    少くとも二つの別個のデータストリームの各々をそれぞれのデータ伝送レートで受領する段階と、
    各ストリーム内の該受領したデータをそれぞれのデータバッファに向けてそこでバッファするために送る段階と、
    該受領したデータのいくつかの特性を示すいくつかの定量的な値を計算する段階と、
    該計算された定量的な値を送信機に向けて送り、そこから送られるデータ用の全体の伝送レートの計算での使用のための段階とを備える方法。
22. 請求項２１記載の方法は、さらに、各バッファ内のデータをそれぞれのデコード用レートでデコードする段階を備え、
    該それぞれのデータデコード用レートは送信機に向けて該計算された定量的な値の少くとも一つとして送られる方法。
23. 請求項２１または請求項２２記載の方法において、該計算する段階はさらにラウンドトリップ時間（ＲＴＴ）値と、損失レート値と、及び／または受信レート値のいくつかをいくつかの定量的な値として計算する段階を備え、該ラウンドトリップ時間はデータが送信機から受信機に向いかつ該送信機に戻る移動のためにかかる時間の測度であり、該損失レート値は受信機に向けて送られ失なわれたデータの量の測度であり、また該受信レート値は該ラウンドトリップ時間内で該受信機により受領されたビットの数である方法。
24. 請求項２３記載の方法において、該損失事象のレートはｎ個の最新の損失間隔についての加重したフィルタを用いて計算され、二つの損失事象間で受領したデータの出力となっている方法。
25. 網からデータを受領するシステムであって、該データは請求項１ないし請求項１０のいずれか１項記載の伝送方法によるか、請求項１１ないし請求項１９のいずれか１項記載の伝送システムによって送られたものであり、該システムは、
    少くとも二つの別個のデータストリームの各々をそれぞれのデータ伝送レートで受領するためのデータ受領手段と、
    それぞれの受領したデータストリームからその中にデータを受領するように構成された少くとも二つのデータバッファと、
    該受領したデータのいくつかの特徴を示すいくつかの定量的な値を計算するための計算手段と、
    該計算された定量的な値を送信機に向けて送り、そこから送られるデータについての全体の伝送レートを計算する使用にあてるデータ伝送手段とを備えるシステム。
26. 請求項２５記載のシステムは、さらに各バッファ内のデータをそれぞれのデコード用レートでデコードするためのデータデコード手段を備え、該それぞれのデータデコード用レートは該送信機に向けて該計算された定量的な値の少くとも一つとして送られるシステム。
27. 請求項２５または請求項２６記憶のシステムにおいて、該計算手段はさらにラウンドトリップ時間（ＲＴＴ）値と、損失レート値と、及び／または受信レート値のいくつかをいくつかの定量的な値として計算するように動作可能であって、該ラウンドトリップ時間はデータが送信機から受信機に向いさらに該送信機に戻る移動にかかる時間の測度であり、該損失レートは受信機に向けて送られて失なわれたデータの量の測度であり、該受信レート値は該ラウンドトリップ時間で該受信機により受領されたビットの数である、システム。
28. 請求項２７記載のシステムにおいて、該計算手段はさらに加重したフィルタ手段を備え、ｎ個の最新の損失間隔の加重したフィルタを用いて、二つの損失事象間に受領したデータの量である、損失事象レートを計算するシステム。
29. 計算機上で実施されるときには請求項２１ないし請求項２４のいずれか１項記載の方法を実行するために該計算機を制御する計算機プログラムを記憶する計算機読取り可能記憶媒体。

Images