(57)【要約】本発明は、コンテンツ・ストリームのビット・レートを、少なくとも１つの受信器(1)の処理能力の関数として調節する装置(10)及び処理に関する。このコンテンツは、ネットワークにおけるこのコンテンツの通信の状態に関する少なくとも１つのパラメータを含む、受信器によって送信器にコンテンツの受信データ（REP）の戻り送信ができるようにする通信プロトコルによって、送信器によって受信器に送信される。装置は、これらの能力に関する情報の関数としてビット・レートの所要レベルを推定するモジュール(12)と、所要レベルに対するビット・レートの修正をもたらすことができる送信者ストリーム調節キューを、戻りとして送信するようこのパラメータを修正する書き込みモジュール(13)とを備える。ストリーミングへの適用。
2006512843.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも1つの受信器(1)の処理能力の関数としてコンテンツ（CONT）のストリームのビット・レートを調節する装置(10)であって、該コンテンツ（CONT）は、送信器(2)によって該受信器(1)にネットワーク(5)を介して、該受信器(1)によって該送信器(2)に該コンテンツ（CONT）の受信データ（REP）の戻り送信ができるようにする通信プロトコルによって送信され、
該能力に関する情報を入力するモジュール(11)、
該ビット・レートの所要レベルを少なくとも該情報の関数として推定するモジュール(12)、
及び、該送信器(2)に該受信データ（REP）とともに戻り送信する調節キューを書き込むことが意図されている、ストリーム調節キューを書き込むモジュール(13)を備え、該調節キューは該所要レベルに対する該ビット・レートの修正をもたらすことができ、
該通信プロトコルは該送信器(2)と該受信器(1)との間での該ネットワーク(5)における該コンテンツ（CONT）の通信の状態に関する少なくとも１つのパラメータを該送信器(2)に戻り送信することができるようにし、該書き込みモジュール(13)は、該パラメータを用いて該調節キューを送信するように該パラメータを修正することが意図されていることを特徴とする装置。
【請求項２】
請求項1記載の、調節する装置(10)であって、該通信プロトコルがRTCPプロトコルであることを特徴とする、調節する装置。
【請求項３】
請求項1と請求項2との一方に記載の、調節する装置(10)であって、プロトコル（DLSR）のパラメータが、該送信器(2)と該受信器(1)との間の往復伝送遅延（RTT）を計算する役目を担うことを特徴とする、調節する装置。
【請求項４】
請求項3記載の、調節する装置(10)であって、該プロトコルの該パラメータが、該コンテンツ（CONT）の受信の瞬間と、該受信器(1)によって該受信データ（REP）の送信の瞬間との間の該受信器(1)でもたらされる遅延（DLSR）を備えることを特徴とする、調節する装置。
【請求項５】
請求項1乃至4のうちの何れか１つに記載の、調節する装置(10)であって、該プロトコルの該パラメータがコンテンツ・ロス率(p)を備えることを特徴とする、調節する装置。
【請求項６】
請求項1乃至5のうちの何れか１つに記載の、調節する装置(10)であって、該書き込みモジュール(13)が、該パラメータのいくつかの連続した変形によって該パラメータを修正することができることを特徴とする、調節する装置。
【請求項７】
請求項1乃至6のうちの何れか１つに記載の、調節する装置(10)であって、該推定モジュール(12)が、該受信器(1)の該能力の共有のレートの関数としてもコンテンツ（CONT）の該ストリームの該ビット・レートの達成対象値を判定することができることを特徴とする、調節する装置。
【請求項８】
請求項1乃至7のうちの何れか１つに記載の、調節する装置(10)であって、該入力モジュール(11)と該推定モジュール(12)は、該受信器(1)の該処理能力が、データ処理速度と、メモリ容量と、エネルギ消費と、該コンテンツ（CONT）の処理に特化される構成部分の存在とのうちから選択される、該受信器の性能の少なくとも１つの基準を備えるように企図されていることを特徴とする、調節する装置。
【請求項９】
受信端末(1)であって、請求項1乃至8のうちの何れか１つに記載の、ビット・レートを調節する装置(10)を備えることを特徴とする受信端末。
【請求項１０】
少なくとも1つの受信器(1)の処理能力の関数としてコンテンツ（CONT）のストリームのビット・レートを調節する方法であって、該コンテンツ（CONT）は、送信器(2)によって該受信器(1)にネットワーク(5)を介して、該受信器(1)によって該送信器(2)に該コンテンツ（CONT）の受信データ（REP）の戻り送信ができるようにする通信プロトコルによって送信され：
該ビット・レートの所要レベルを少なくとも該能力に関する情報の関数として推定する工程、
及び、該送信器(2)に該受信データ（REP）とともに戻り送信するストリーム調節キューを書き込む工程を備え、該調節キューは該所要レベルに対する該ビット・レートの修正をもたらすことができ、
該通信プロトコルは該送信器(2)と該受信器(1)との間での該ネットワーク(5)における該コンテンツ（CONT）の通信の状態に関する少なくとも１つのパラメータを該送信器(2)に戻り送信することができるようにし、該キューは、該パラメータを用いて該調節キューを送信するように該パラメータを修正している間に書き込まれ、
好ましくは、請求項１乃至8の何れか１つに記載の、調節装置によって実施されることが意図されていることを特徴とする、ビット・レートを調節する方法。
【請求項１１】
請求項10記載の、ビット・レートを調節する方法であって、該ネットワーク(5)がポイント・ツー・ポイント通信ネットワークであり、該コンテンツ（CONT）の該ストリームが連続して送信されることを特徴とする、ビット・レートを調節する方法。
【請求項１２】
コンピュータ・プログラム・プロダクトであって、請求項10と請求項11との一方に記載の方法の工程を、プログラムがコンピュータ上で実行される場合に実行するプログラム・コード命令を備えることを特徴とするコンピュータ・プログラム・プロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ・ストリームのビット・レートを1つ又は複数の受信器の処理能力の関数として調節する装置及び処理に関し、更に、関連したプロダクトに関する。
【背景技術】
【０００２】
特にパーソナル・コンピュータ（PC）や携帯情報端末（PDA）などの一段と多くのユーザ端末は、ソフトウェアが実施される汎用のプラットフォームに基づいている。この動向は特に、オーディオ/ビデオの読み取り器に関する。
【０００３】
しかし、端末の能力は多くの場合、CPU（「中央処理装置」の略）の性能の点でも利用可能なメモリの点でも非常に異なっている。したがって、コンテンツを端末に合わせるか、端末をコンテンツに合わせる手法を規定することが必要である。
【０００４】
端末をコンテンツに合わせることに関する公知の解決策は、端末がリアルタイムでデータを全て正常に復号化しない場合、選択的な復号化を行うことから成る。例えば、通常、（それ自体で復号化される）タイプIの画像と、（先行する画像の助けを借りて復号化される）タイプPの画像と、（先行する画像と後続する画像との助けを借りて復号化される）タイプBの画像から成るMPEG2（「動画像専門家グループ」の略）ビデオ・ストリームの受信中に、埋め尽くされた端末はB画像を復号化するものでない（このB画像は、後続する画像の予測に用いられるものでない。）。
【０００５】
ブロードキャスト又はマルチキャストにより、戻り経路を何ら備えていない伝送アプリケーションでは、この解決策は効果的な適合を可能にするが、受信品質を損い得る情報ロスにつながる。
【０００６】
対照的に、ポイント・ツー・ポイントのアプリケーションでは、送信ビット・レートを端末に合わせることによってこの課題をなくすようにすることが可能である。このことを行うよう、公知の手法によれば、交渉の先行工程が標的端末とクライアントとの間で実施されるので、この端末の特性は送信器に通信される。送信器は更に、端末によってリアルタイムで復号化し得るコンテンツを選択する。この手法は、この種類の情報を交換することを可能にする、プロトコルの定義と、端末の特性の尺度の定義に依拠する。
【０００７】
受信器の能力に送信器が合わせることに関して開示されている方法がある（例えば、特許文献１参照。）。該文献は、受信器端末によってこれらの能力を先行して送信器に通知することによる、復号器を備えている端末の処理能力の関数として送信ビット・レートを合わせることを開示している。
【０００８】
この文献の開示から、送信器と受信器との間で特定の伝送プロトコルに合意して同じことを達成しなければならないということが判明しており、このことは、関係する送信器にも受信器にも首尾一貫したシステムの実施を必要とするという欠点を有する。更に、そのような手順は、認識された標準化の主題を形成する限りにおいてのみ比較的広い適用分野の恩恵を受けることが可能である。
【０００９】
更に、標準化された手法が、ポイント・ツー・ポイント・ネットワーク内のデータ伝達状態に送信ストリームを合わせるのに通常、利用される。よって、RTCP（「リアルタイム制御プロトコル」の略）プロトコルでは、送信器と受信器との間のIP（「インターネット・プロトコル」の略）パケットの往復時間（RTT）は送信器に通知され、送信器は送信されるストリームを修正するうえで適切な措置をとり得る。この措置は、ネットワークにおける輻輳に対応するうえで特に有用である。「TCPフレンドリな」種類のアルゴリズムの場合、受信器でみられるエラー・レート（「p」と表す「ロス・イベント率」）も送信器に通信され、送信器はよって、測定されるエラー・レートの関数として、その送信ストリームを合わせ、エラーに対する保護を生成することが可能である。
【００１０】
往復時間RTTを用いることは、受信器レベルでのバッファ・メモリの容量を考慮する目的での特定の改良の主題を形成してきた。特に、そのようなバッファ・メモリは、送信ストリームのビット・レートを調節する場合に考慮しなければならない時間を延長する。更に、受信器からの受信の応答からRTTを計算することができる情報処理部を有する送信器を開示するものがある（特許文献２参照。）。上記処理部は、このRTTと、端末に関連したバッファ・メモリの記憶の量に関する、受信の応答に添付されるキューとに相当する送信ビット・レートを抽出する。ビット・レート制御部は更に、実際の送信ビット・レートをこの抽出ビット・レートに基づいて修正する。この手法によって、送信ビット・レートを操作して、良好なリアルタイム再生を得て、ネットワークの輻輳がないようにすることが可能となる。
【特許文献１】特開2000‐270330号公報
【特許文献２】特開2001‐257715号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
バッファ・メッモリの容量をビット・レート変動について考慮することを可能にするこれらの方法は、送信器のレベルと受信器のレベルでの特定の実施、更には特定の通信プロトコルを必要とする。更に、それらは、受信器の処理能力に合わせるという課題をそのままにしておくものである。
【００１２】
送信ビット・レートの適切性を更に向上させる魅力的な解決策として、受信器の能力を送信器に知らせる通知を事前に送信する工程からなるものを記載するものがあり（上記特許文献１参照。）、RTTのみならず受信器のバッファ・メモリに関するキューも含む受信の応答を、送信中に送信器に送信する工程からなるものを記載するものもある（上記特許文献２参照。）。送信器は適切に組み合わせられたアルゴリズムによって、その送信ストリームを、両方の種類の情報を検討することによって合わせることになる。
【００１３】
そのような組み合わせは、リアルタイム復号化の良好な流動性をもたらすうえで効果的であることが明らかとなる場合があるが、送信器及び受信器における実施の必要性と、特定のプロトコルの導入の必要性とを残す。更に、それは、実施が互換性のある送信端末及び受信端末の制限されたプールに限定されない限り、インターネットなどの（WANネットワークと呼ぶ）ワイド・エリア・ネットワーク内でこの特定のプロトコルが受け入れられることに関するかなりの不確実性を残す。
【課題を解決するための手段】
【００１４】
本発明は、少なくとも１つの受信器の処理能力の関数としてコンテンツ・ストリームのビット・レートを調節する装置に関し、これは、単純でかつ効果的な実施を可能にし、特段の問題なしで、場合によっては別個の型式の、非常に多くの数の送信器及び受信器に、新たな特定の通信プロトコルを適合させることを必要とすることなく適用することが可能である。
【００１５】
本発明は、調節処理、受信端末、及び本発明の当該装置に相当するコンピュータ・プログラムにも関する。
【００１６】
それは特に、特にインターネット経由でのRTCP通信、更には他のWANネットワーク経由や（LANネットワークと呼ばれる）ローカル・エリア・ネットワーク経由でのRTCP通信の分野に適用される。更に、本発明は、例えばビデオ・オン・デマンド（VOD）などのビデオ・ストリームの（「ストリーミング」と呼ぶ）連続送信やイベントの生でのインターネット経由での再送信に関して特に有益である。
【００１７】
この目的で、本発明の主題は、少なくとも１つの受信器の処理能力の関数としてコンテンツのストリームのビット・レートを調節する装置である。このコンテンツは、受信器による送信器までのコンテンツの受信データを戻り送信できるようにする通信プロトコルによって、ネットワークを介してこの受信器に送信器によって送信される。この装置は：
これらの能力に関する情報を入力するモジュール、
少なくともこの情報の関数としてビット・レートの所要レベルを推定するモジュール、
及び、受信データとともに送信器に戻り送信する調節キューを書き込むことが意図されている、ストリーム調節キューを書き込むモジュールを備え、この調節キューは、所要レベルに対する上記ビット・レートの修正をもたらすことができる。
【００１８】
本発明によれば、通信プロトコルは、送信器と受信器との間でのネットワークにおけるコンテンツの通信の状態に関する少なくとも１つのパラメータを送信器に戻り送信できるようにし、書き込みモジュールは、調節キューを送信するのにそれを用いるようにそのパラメータを修正することが意図されている。
【００１９】
受信器の「処理能力」の表現は、例えばMPEG-2ストリームを復号化するよう、受信データを処理するのに適した受信器の資源を意味することとする。この能力は、よって、データ処理速度（通常、中央処理装置の略であるCPUの性能）、（RAM（ランダム・アクセス・メモリの略）メモリのものなどの）メモリの容量、エネルギ消費及び/又はコンテンツの処理に特化した構成部分（例えば、ハードウェアの復号器）が存在していることを特に含み得る。一方、この定義は、ピュア・ストリーム調節機能を有するエンティティ、この場合にはバッファ・メモリを排除している。
【００２０】
意外にかつ変則的に、受信器の処理能力は、ネットワークじゅうの伝達の特性に通常充てられる、プロトコルのパラメータに影響を及ぼすのに用いる。更に、このパラメータは、送信器に対する戻り送信の手前で修正され、このことも、調節アルゴリズムが送信器のレベルで実施される公知の手法とは際立った対照をなす。
【００２１】
この手順は、よって、受信器（又は受信器群）のレベルで作用することによって、この送信器が受信器の処理能力に対して実施を何ら有していないにもかかわらず、受信器に合わせる何れかの特定の動作から送信器を解放する可能性を有するので、それだけいっそう意外である。この結果は、ネットワークにおける通信状態を通常、標的としているが、別の、すなわち、受信器の能力に関する情報を暗黙的に組み入れる機能、が割り当てられる、プロトコルのパラメータを操作することによって得られる。
【００２２】
受信器の処理能力をそのようなパラメータにリンクさせることは、バッファ・メモリの容量の戻り送信とRTT時間とに関する上記特許文献2の開示に関しても意外である。特に、バッファ・メモリは交換の流動性に直接関係する役割を果たし、送信器と受信器との間のデータの移動の時間の概念を自然に拡張したものである、すなわち、バッファ・メモリにおける待ち行列が増えると、送信は遅くなり、RTT時間が増える。ネットワークにおける通信状態への明らかな直接の関係がない、受信器の処理能力の場合は当てはまるものでない。
【００２３】
本発明の調節装置は、特にそれが送信器に完全に透明なかたちで受信器の処理能力にビット・レートを調節する手順を可能にするという点で非常に効果的である。当該装置は実際に、プロトコルの規定によって、ネットワークの輻輳を抑制する目的で動作する。
【００２４】
この状況の重要な結果は、送信機器を修正することも、そのような機器に専用装置を加えることも必要でないということである。逆に、通信プロトコルに一致している何れかの送信器が適切であり得る。特定の手段を、それら自体又は適切に加えられたシステムにおいてこれらの手段を組み入れることによって備える必要があるのは受信器のみである。この状況の結果としては、プロトコルが修正されなくてよいということと、更に、追加のプロトコルを規定する必要がないということがある。よって、受信器が合わせられるという規定によって、本発明の調節装置は、ネットワークにおける通信状態に関するパラメータを含む受信データの戻り送信ができるようにするプロトコルが機能している限り適用可能である。
【００２５】
本発明の装置の手法と、バッファ・メモリを考慮することとを組み合わせることは更に効果的である。この場合、好ましくは、このバッファ・メモリの容量は、受信器の処理能力に利用されるパラメータに同一であり得る、プロトコルのパラメータの修正によって直接、考慮される。よって、前述のように、送信器を修正する必要はなく、標準的な通信プロトコルを利用することが可能である。
【００２６】
本発明の調節装置は、受信器の処理能力に正確に適合するのみならず、この能力が経時的に変動する場合にもそうすることを可能にする。好ましくは、受信器の処理能力を確かめる場合を含め、規定は完全に自動化された方法で作用させられる。行われる動作はよって、ユーザに完全に透明である。
【００２７】
本発明の調節装置は、例えば、所望の送信ビット・レートを判定し、更に、適宜、用いられるパラメータを操作する内部品質管理装置の形態で、ユーザ受信端末において直接実施することが可能である。それは、受信器とネットワークとの間に配置されるスタンドアロン型のシステムにおいて実施される場合もある。このようなスタンドアロン型システムは、いくつかの受信器と関連付けされる場合もあり、その幅広い処理能力を考慮する場合もある。当該実現は、例えば構内又は企業における、地理的に規定される端末群に関して特に有益である。
【００２８】
受信データは好ましくは、コンテンツ・ストリームを送り出すのに用いる通信ネットワークを介して、戻りとして送信される。
【００２９】
通信プロトコルの好適な形態によれば、当該プロトコルはRTCPプロトコルである。本発明は、ポイント・ツー・ポイントのネットワーク及びプロトコルに適用される場合もあり、（端末群について）マルチキャストに適用される場合もある。
【００３０】
プロトコルのパラメータの実現の第１の好適な態様においては、当該態様は、送信器と受信器との間の往復伝送遅延を計算する役目を担うよう企図されている。プロトコルのパラメータはその場合、効果的には、コンテンツの受信の瞬間と、受信器による受信データの送信の瞬間との間の、受信器でもたらされる遅延を備える。RTCPプロトコルでは、特に、伝送遅延は、コンテンツの受信を受信データの送信から隔てる（「送信者からの通知を最後に受信した時間からの遅延」の略である）DLSRと呼ぶ遅延を操作することによって受信器のレベルで修正されるRTT時間である。
【００３１】
プロトコルのパラメータの実現の第２の好適な態様では、当該態様は、コンテンツ・ロス率を備える。RTCPプロトコルでは、特に、送信者がTCP（「伝送制御プロトコル」の略）フレンドリなアルゴリズムを用いる限りこのロス・レートpを利用し得る。
【００３２】
プロトコルのパラメータに関するこれら２つの実現の態様は効果的に組み合わせられ、調節装置は、２つの種類のパラメータの何れかを修正することができるか、１度に両方のパラメータを修正することもできる。
【００３３】
RTCPプロトコルを修正するパラメータとしてDLSRを選ぶ効果は、TCPフレンドリなもの以外のアルゴリズムに適用するという点である。実際に、輻輳制御アルゴリズムを有する送信器がどちらであっても、調節装置が受信器のレベルで実施される場合には、この送信器は、受信器の処理能力に適合する。更に、このパラメータは、ロス率を用いることに特有な、何れかの不必要なエラー抑制がもたらされないようにする。
【００３４】
一方で、RTCPプロトコルの修正パラメータとしてpを（それを用いることが可能な場合に）選ぶ効果は、それが当該パラメータを直接操作することを、DLSRパラメータの修正がRTT時間に関して得られる効果における不確実性を引き起こす一方で、可能にし、後者は、受信器と送信器との間で受信データが伝達される速度によっても変わってくる。
【００３５】
効果的には、書き込みモジュールは、プロトコルのパラメータをこのパラメータのいくつかの連続した変形によって修正することができる。この実現は、決定的なパラメータを送信レベルで直接修正することが可能でないが、付随的なパラメータによって操作される場合に特に適切である。
【００３６】
このことは特に、RTT時間を間接的に修正することを可能にするDLSRパラメータにあてはまる。本実現態様によれば、DLSRを連続して増やして、コンテンツ・ストリームのビット・レートを正確に調節することが受信器レベルで行われる。改良バージョンに関しては、ロス率を用いることによって、一方でそれがそのような繰り返しがないようにする効果が残り、他方で上記の欠点が残る。
【００３７】
本発明の調節装置の実現の改良された態様では、当該実現は、コンテンツの送信ビット・レートを合わせる受信器の処理能力のみを考慮する訳ではない。前述のように、バッファ・メモリの容量は、特に、RTCPプロトコルのRTTをDLSRによって調節する工程を包含し得るが、その他の実現は特に有益である。
【００３８】
特に、効果的には、推定モジュールは、受信器の処理能力の関数としてのみならず、受信器の能力を共有するレートの関数として、コンテンツ・ストリームのビット・レートの達成対象値を判定することができる。このようにして、場合によっては優先度を課しながら、受信器において並列に処理されるいくつかのストリームのビット・レートを管理することが可能である。説明の目的では、そのようなストリームは（例えば、CPU共有の点で）処理能力の30%より大きな処理能力を費やさず、残りの70%はその他のストリーム間で公平に配分されることとするということを判定し得る。
【００３９】
入力モジュール及び推定モジュールは、好ましくは、上記受信器の処理能力がデータ処理速度と、メモリ容量と、エネルギ消費と、コンテンツの処理に特化した構成部分が存在していることとのうちから選択される、受信器の性能の少なくとも1つの基準を備えるように企図される。
【００４０】
本発明は、本発明の形態の何れか１つによる、ビット・レートを調節する装置を備える受信端末にも関する。
【００４１】
本発明は、本発明の装置に相当し、好ましくは、本発明の実現の態様のうちの何れか１つによって実施されることが意図されている少なくとも１つの受信器の処理能力の関数として、コンテンツ・ストリームのビット・レートを調節する処理にも適用される。効果的には、このネットワークは、ポイント・ツー・ポイント通信ネットワークであり、コンテンツ・ストリームは連続して送信される（ストリーミングされる）。
【００４２】
本発明は、このプログラムがコンピュータ上で実行される場合に本発明による調節処理の工程を実行するプログラム・コード命令を備えるコンピュータ・プログラム・プロダクトにも関する。「コンピュータ・プログラム・プロダクト」の表現は、ディスケットやカセットなどの、プログラムを含む記憶空間からなるだけでなく、電気信号や光信号などの信号からもなる場合があるコンピュータ・プログラム媒体を意味することとする。
【発明を実施するための最良の形態】
【００４３】
本発明は、添付図面を参照しながら、一切限定するものでない、以下の例示的な実現及び実施によってより良く理解され、説明される。
【００４４】
これらの図では、説明され、図示される機能エンティティは、物理的に別個のエンティティに必ずしも相当するものでないが、例えば、同じ構成部分の同じソフトウェア又は回路の機能からなり得る。
【実施例】
【００４５】
通信ネットワーク5を介して送信され、受信されるアセンブリ(図１)は、コンテンツCONTの送信器2と、このコンテンツCONTの受信器1とを備える。ネットワーク5を介した通信用のプロトコルによれば、受信器1は、このコンテンツCONTの受信データREP（「通知」の略）を送信器2にネットワーク5を介して、戻りとして送信するよう企図されている。特に、このコンテンツREPは、ネットワーク5におけるコンテンツCONTの通信の状態に関する1つ又は複数のパラメータを備え、これらのパラメータは、ネットワーク5における輻輳の問題を直すような方法で、コンテンツ・ストリームCONTのビット・レートを修正するのに送信器2によって用いられる。
【００４６】
受信器1は、前述のパラメータを修正することができるビット・レート調節装置10が備えられている。この調節装置10は、コンテンツCONTのストリームのビット・レートの所要レベルを受信器1の処理能力の関数として推定し、送信器2のレベルでビット・レートの調節をもたらすようにこれらのパラメータを適宜、操作するよう企図されている。
【００４７】
より正確には、受信器1は、調節装置10に加えて、受信器1の処理能力を測定するモジュール14、クロック20にリンクされる、受信データREPを作成するモジュール15、及びこのデータREPを送信するモジュール16を備える。調節装置10自体は：
測定モジュール14によって通信される、受信器1の処理能力に関する情報を入力するモジュール11、
コンテンツCONTのストリームのビット・レートの所要レベルを推定するモジュール12、
及び、作成モジュール15と通信し、ビット・レートを制御するのに用いるパラメータを修正する命令をモジュール15に備えることが意図されている、データREPにストリーム調節キューを書き込むモジュール13を備える。
【００４８】
上記例示的なアプリケーションによれば、プロトコルはRTCPであり、ネットワークはインターネットである。
【００４９】
第１の例示的な実施では、RTT(往復時間)の計算を用いて、受信器1が復号化することが可能なビット・レートを送信器2に知らせる。
【００５０】
RTTは、特に、受信データREPとともに受信器1から受信される遅延DLSRに基づいて送信器2によって計算される。RTT時間の計算の態様は、本質的にはRTCPプロトコルによって以下のように表される。
【００５１】
最後のタイム・スタンプSR（「送信者からの通知」の略）（LSRは「最後に受信したSR」の略）：32ビット、すなわち、ソースSSRC_nから最も近い時点に受信したSRパケットの一部として受信したタイム・スタンプNPT(..)における64のうちの32の中位ビット。SRがいまだ何ら受信されていない場合、このフィールドはゼロに設定される。
【００５２】
最後に受信したSRからの遅延（DLSR）：32ビット、ソースSSRC_nから最後に受信したSRパケットの受信と、受信通知ブロックの発送との間の、1/65536秒の単位で表す遅延。SRパケットがいまだSSRC_nから何ら受信されていない場合、DLSRフィールドはゼロに設定される。
【００５３】
ソースSSRC_nは、SSRC_rまでの（受信器が受信通知を送信する）往復の伝搬遅延を、受信通知ブロックの受信の瞬間Aを記録し、合計往復時間（A−LSR）を計算し、更に、それから遅延DLSRを減算すること（A−LSR−DLSR）によって計算することが可能である。
【００５４】
次に、輻輳制御アルゴリズムは、TCPプロトコル（「伝送制御プロトコル」の略）が行ったことになるように、輻輳の場合に送信ビット・レートを低減させることを可能にする、いわゆるTCPフレンドリなビット・レートを推定する。プロトコルにおいて表されるアルゴリズムでは、ビット・レート方程式は：
X=s/（R*√（2*b*p/3）+（t＿RTO*（3*√（3*b*p/8）*p*（1+32*p2））））
であり、
Xは毎秒のバイト単位での送信レートであり、
Sはバイト単位でのパケットのサイズであり、
Rは秒単位での往復移動時間（RTT）であり；
pは、送信パケット数の割合としてのロス・イベント数によって表す、0から1までの間のロス・イベント率であり：
t＿RTOは、秒単位での再送信アイドル時間値であり：
bは、受信の単一TCP応答によって証明されるパケットの数である。
【００５５】
受信器でもたらされる遅延（DLSR）を連続して増やすことによって、RTT（R）は意図的に修正されるので、利用可能なビット・レートは受信器1によって復号化可能なものであり、利用可能なネットワーク・ビット・レート5でないということを送信器2が「信じさせられる」。
【００５６】
第２の例示的な実施では、ロス率pの計算が用いられて、受信器が復号化することができるビット・レートを送信器に知らせる。このことを行うよう、pが直接修正される。
【図面の簡単な説明】
【００５７】
【図１】受信器が本発明による調節装置を備える、送信アセンブリ及び受信アセンブリの原理を示す図である。
【図２】図１の受信器の詳細を示す図である。
【図１】
2006512843.tif 000003
【図２】
2006512843.tif 000004
【国際調査報告】
2006512843.tif 000005
2006512843.tif 000006