JP4681044B2 - データパケットの送信を動的に制御する技術 - Google Patents

Description

本発明はデータの通信に関しており、より具体的には、連続するデータパケットの送信（streaming data packet transmissions）を制御する技術に関するものである。

パケットに基づくインターネット・プロトコル（ＩＰ）ネットワーク等の通信インフラを介して、ますます大量のデータがサーバからクライアントへと送信されている。特に人気が高まっているアプリケーションに、マルチメディア・ストリーミングがある。しかし、そのようなサービスが広く受容されるには、先ず信頼できるデータ・ストリームを提供することでの向上がなされねばならない。例えば、ＩＰネットワークとユーザのクライアント装置との間のデータ送信リンクのレートが変動しがちなことから、ユーザへのデータ配信に乱れがあると、端末ユーザへのプレイアウトの厳しい悪化、すなわち、ユーザが視聴するメディアの品質低下に結びつき兼ねない。特に、プレイアウト（playout: すなわち、マルチメディア・アプリケーションまたはプレーヤによるマルチメディアファイルの表示）の進行中は、マルチメディア・アプリケーションが取り寄せるパケットデータがクライアント装置に十分に供給されることが重要である。

多くの場合、パケット送信レートは変更できない（または、パケット送信レートを変更することは、少なくとも実際的ではない）。というのは、このレートは通信リンクの帯域幅に依存するからである。しかし、データがユーザの出力装置に供給されるレートは、しばしば変更されねばならない。通常、ストリーミング・アプリケーションでは、そのような調整は「ストリーム切り替え(stream switching)」を使って達成される。ストリーム切り替えでは、同じメディア内容、例えば特定の映像の連なり、が幾つかの異なるビットレートで予め符号化されて、サーバに格納される。したがって、同じストリームについて幾つかの異なるバージョンが利用可能である。送信中には、サーバが、ネットワークで現時点に使用可能な帯域幅とクライアントバッファの状態とに基づいて、最も適したデータ・ビットレートを有する特定バージョンを選択する。サーバが使用する切り替えの論理では、別バージョンのストリームへ切り替えるべきか、およびいつ切り替えるかを判定する。いわゆる「ダウンスイッチ(down-switch)」の場合、ストリームはより低い符号化ビットレートのバージョンへ切り替えられる。「アップスイッチ(up-switch)」の場合は、より高い符号化ビットレートのバージョンへ切り替えられる。多くの実施形態において、切り替えの基準としてはクライアントバッファの状態に関して定義された所定の閾値を使用する。１つの例としては、閾値はクライアントバッファ中のデータ量をバイト単位で示すバッファ・フィルレベルに基づいている。他の例としては、閾値はクライアントバッファ中に格納されたメディアのプレイアウト長（ＰＴ:playout length）に基づいている。このＰＴは、既にクライアントバッファ中に存在するデータをユーザにプレイアウトするのに要する時間を秒単位で示される。代わりにバッファ・フィルレベルまたはその他の適当なパラメータを使うこともできるが、ここでは、プレイアウト長に関する例を述べる。

クライアントバッファの状態を判定する従来技術には、実時間トランスポート制御プロトコル（Real Time Transport Control Protocol：ＲＴＣＰ）の受信者レポート（receiver reports：ＲＲｓ）中の情報を利用するものがある。このＲＲと一緒に、クライアントバッファ中の次のシーケンス番号（next sequence number：ＮＳＮ）または最も古くバッファされたシーケーンス番号（oldest buffered sequence number：ＯＢＳＮ）、およびクライアントバッファ中の最大受信のシーケンス番号（highest received sequence number：ＨＲＳＮ）に関する情報が含まれており、この情報が、ＨＲＳＮからＮＳＮ／ＯＢＳＮの範囲内の各パケットの大きさがわかっているので、消費バッファ空間を決定するのに使用される。もしクライアントバッファ中の未使用空間が望ましいクライアントバッファ・フィルレベルより小さい場合、別バージョンのストリームが選択される。例えば、バッファのプレイアウト長（ＰＴ）が所定の最小閾値（ＰＴ_DOWN）より低下すると、バッファの枯渇の危険、すなわち、クライアントバッファが空になりユーザに流すべきデータがないという危険が生じる。これはプレイアウトのフリーズにつながる。そうなると、通常は、十分な量のデータがクライアントバッファに追加されてユーザが使用する出力装置へのストリーミングが再開されるまで、ユーザに表示された最終イメージにフリーズすることになる。すなわち、クライアントバッファの「再バッファリング(rebuffering)」が必要となる。再バッファリングは、ユーザの立場からすると極めて不愉快なものとなり得る。

クライアントバッファの枯渇による再バッファリングの可能性を回避するために、サーバは、クライアントバッファ中のプレイアウト長（ＰＴ）が閾値ＰＴ_DOWNより低下したことを検出し、クライアントバッファが完全に枯渇しないようにするため、ビットレートを調整する（すなわち、別のビットレートのストリームのバージョンを選択する）。より具体的には、サーバは、ダウンスイッチを実行する。すなわち、より低いビットレートのストリームへ切り替える。アップスイッチではなくダウンスイッチが実行される理由は、クライアントバッファが枯渇しそうになる最もありそうな理由が、サーバとクライアントバッファとの間のリンクレートが予想より小さい、すなわち、実効帯域幅が現時点で使用されるビットレートに必要とされる帯域幅より小さいことにあるからである。その結果、クライアントバッファがユーザの出力装置に対してデータを供給するのと同じレートで、データがクライアントバッファに受信されない。したがって、データが十分に存在する状態にあるべきクライアントバッファが枯渇する。低いビットレートへ切り替えることにより、クライアントバッファはより低いレートで表示ユニットへデータを供給し、これにより、データをサーバから受信するのにより多く時間が掛かってもよいようにし、クライアントバッファが完全に枯渇しないようにする。ユーザの立場からは、ダウンスイッチのためにメディア・ストリームの品質が低下することになる。例えば、ビデオ・ストリームの表示イメージのサイズが小さくなったり、イメージの解像度が小さくなったり、またはイメージ中の歪みが大きくなったりする。それでも、これは、再バッファリング中に発生する、前述のプレイアウトのフリーズよりはましである。

一方、もしバッファのプレイアウト長（ＰＴ）が所定の最大閾値（ＰＴ_UP）を越えると、バッファ溢れ(overflow)の危険が生じる。すなわち、クライアントバッファが満杯になり、追加パケット用の空間がなくなる。クライアントバッファが受信していながらそこに格納されないパケットは、通常、サーバによって再送されることはなく、したがって、それらのパケットのデータはユーザの出力装置へは転送されないままとなる。クライアントバッファがパケットを再度格納可能になると、データ・ストリームは新しいパケットを受け入れるようになる。こうして、ユーザから見ると、ストリームが先へ飛ぶというような、内容の突然の欠落が生じる。フィルムまたは映画の場合、対話が途切れてユーザが物語に追随し難くなる。音楽の場合は、歌が先に飛んでしまう。お分かりのように、これもまたユーザから見て、極めて不愉快なものとなり得る。

クライアントバッファの溢れに起因するストリームの混乱を回避し、また同時にメディア品質を増進するために、サーバは、クライアントバッファ中のプレイアウト長（ＰＴ）が閾値ＰＴ_UPを超過するとそれを検出し、アップスイッチ、すなわち、より高いビットレート・ストリームへの切り替えを実施する。ダウンスイッチでなくアップスイッチが実施される理由は、クライアントバッファが溢れそうになる最もありそうな理由が、サーバとクライアントバッファとの間のリンクレートが予想より大きい、すなわち、実効帯域幅が現時点で使用されるビットレートに必要とされる帯域幅より大きいことにあるからである。その結果、クライアントバッファがユーザの出力装置にデータを供給するのより高いレートで、クライアントバッファはデータを受信する。したがって、クライアントバッファが溢れる。より高いビットレートへ切り替えることにより、クライアントバッファはより高いレートでデータを出力装置へ供給し、これにより、クライアントバッファが溢れないようにする。ユーザから見ると、メディア・ストリームの品質がアップスイッチにより改善する。例えば、ビデオ・ストリームの表示イメージのサイズが大きくなったり、イメージの解像度が大きくなる。したがって、アップスイッチはストリームの混乱が生じないようにし、またメディア品質を向上する。これらはいずれもユーザには利益となる。

アップスイッチおよびダウンスイッチを実行する簡単な論理を、以下のように表現してもよかろう：
If ＰＴ＞ＰＴ_UP then
Perfirm up-switch
else if ＰＴ＜ＰＴ_DOWN
Perform down-switch
end if.
これらの閾値を適切に選択することはユーザの総合的なメディア印象に非常に重要である。ダウンスイッチの実行時期が遅れた場合、再バッファリングの事態が起こる。アップスイッチの実行時期が遅れた場合、ユーザは、そうでない場合に必要とされる品質より低い品質のメディアを受信し、先述のように、バッファ溢れの結果としてデータ・ストリームの途切れが生じることにもなる。同様に、ダウンスイッチが不必要に早く実行された場合、ユーザは、そうでない場合に必要とされる品質より低い品質のメディアを受信する。アップスイッチが不必要に早く実行されると、直ぐにダウンスイッチが必要になってメディア品質が不愉快に変動する結果となる。これらの問題を回避するために、複数のダウンスイッチ閾値および複数のアップスイッチ閾値を使用できる可能性が潜在する。プレイアウト長が減少してバッファの枯渇に向かうに伴い、次々とダウンスイッチ閾値を通過し、それらの各々がダウンスイッチを起動する。その逆に、プレイアウト長が増加してバッファ溢れに向かうに伴い、次々とアップスイッチ閾値を通過し、それらの各々がアップスイッチを起動する。

しかし、切り替えが生じて新しいビットレートのストリームが送信された後も、その切り替えがクライアントバッファのプレイアウト長に何らかの効果をもたらすにはいくらかの時間が掛かる。第一に、新しいビットレートで符号化されたデータを含む最初のパケットがクライアントバッファに到達する迄の伝送遅延がある。この期間中、クライアントバッファ中の格納メディアのプレイアウト長は新しいレートの影響を受けない。したがって、プレイアウト長が増加中でバッファ溢れも見込まれていたとするなら、プレイアウト長は増加し続けそうである。逆に、プレイアウト長が減少中でバッファの枯渇も見込まれていたとするなら、プレイアウト長は減少し続けそうである。また、新しいビットレートの最初のパケットが到達した後でも、プレイアウト長は当初は緩慢にしか変化しない場合もある。例えば、以前のビットレートのデータで送信されたパケットがまだ幾らか存在し、クライアントバッファにまだ到達していないこともあり得る。それゆえ、切り替え状態がまだ有効になっていないこともしばしばであり、それにも拘わらず最初の切り替えに続いていくつもの切り替えが起こるが、それらが不必要であることも多い。最初がダウンスイッチの場合、複数のダウンスイッチがさらに実行され、ストリームのビットレートが必要なものより遥かに減少することがある。最低速のビットレートのストリームが選択されるまでダウンスイッチが止まらないことも多い。この動作によりユーザへのメディア・ストリーム品質が不必要に低下してしまう。アップスイッチの場合、複数のアップスイッチがさらに起こり、高過ぎるビットレートのストリームになってしまい、取り得る最高レートに至ることも多い。この結果、ストリームのビットレートが現時点で利用可能なネットワーク帯域幅と比べて遥かに高くなり、一連のダウンスイッチを起動することになる。

結果として、ユーザは頻繁で不愉快なストリーム品質の変動を視聴することになる。さらに、高過ぎるビットレートが選択された場合、その後のダウンスイッチを十分迅速には実行できず、その結果、不愉快なバッファ溢れとそれに伴うデータ欠落が発生する。アップスイッチ閾値が１つでダウンスイッチ閾値も１つだけであってもこの種の問題は起こり得る、特に、閾値が相互に近接して設定された場合に起こる。

したがって、より安定し信頼できるコンテンツをユーザに提供できるための、ストリーム切り替えを制御する改善された技術が必要であり、本発明が主たるねらいとするのはこの目的に対してである。

本発明は、サーバからクライアントバッファを有するクライアントへのパケット送信を制御する方法であって、パケットで送信されるデータのビットレートが、サーバによりクライアントバッファの状態に基づいて選択される方法によって具体化される。本方法に従えば、パケットは、最初、送信時点のビットレートに従って符号化されたデータを含んで送信される。クライアントバッファは、送信後の時点においてクライアントバッファ中のデータ量を示す基準値（ＰＴ_CH）を検出するために監視される。現時点のクライアントバッファ中のデータ量を示す値（ＰＴ）もまた追跡される。その時、送信中のデータのビットレートの調整は、動的モード（dynamic mode）に応じて、現時点のクライアントバッファ中のデータ量を示す値（ＰＴ）と、基準値（ＰＴ_CH）とに基づいて制御される。前記値（ＰＴ）に加えて基準値（ＰＴ_CH）をも考慮に入れることにより、ビットレートの調整を制御する時に、ビットレートの不必要な調整を実質的に回避することができる。

１つの実施形態では、送信後の時点におけるクライアントバッファ中のデータ量を示す基準値（ＰＴ_CH）を検出するステップは、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点を検出するために、クライアントバッファ（１１５）を監視するステップ(２０２)と、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点で、クライアントバッファ中のデータ量を示す基準値（ＰＴ_CH）を検出するステップ（２０４）とを含む。別案として、基準値（ＰＴ_CH）を、現時点の（新しい）ビットレートでパケットの送信を開始した直後の時点および／または直後の時点と到達した時点の２つの時点間の任意の時点において、検出することも可能である。

動的モードがアップスイッチの例では、ビットレートの調整を制御するステップは、現時点のクライアントバッファ中のデータ量（ＰＴ）が、基準値（ＰＴ_CH）に一部が基づいて設定された調整可能なアップスイッチ閾値（ＰＴ_UP-ADJ）を超過した場合に、より高いビットレートへ切り替えることにより実行される。調整可能なアップスイッチ閾値（ＰＴ_UP-ADJ）は、所定の安全マージン（Ｓ）と基準値（ＰＴ_CH）との積に等しく設定されてよい。所定の安全マージンは、通常、１．０より大きいかまたは等しく設定されるが、１．２に設定された特定の例もある。またその例では、動的モードにおいてより高いビットレートへ切り替えるステップが、現時点のクライアントバッファ中のデータ量（ＰＴ）が所定の最小閾値、これは固定的なダウンスイッチ閾値（ＰＴ_DOWN）であってよい、を超えた場合にのみ実行される。

動的モードがダウンスイッチの例では、パケットのビットレートの調整を制御するステップは、現時点のクライアントバッファ中のデータ量（ＰＴ）が、基準値（ＰＴ_CH）に一部が基づいて設定された調整可能なダウンスイッチ閾値（ＰＴ_DOWN-ADJ）より低下した場合に、より低いビットレートへ切り替えることにより実行される。調整可能なダウンスイッチ閾値（ＰＴ_DOWN-ADJ）は、所定の最小閾値（ＰＴ_DOWN）と基準値（ＰＴ_CH）とのほぼ中間に設定されてよい。またその例では、別案として、動的モードにおいてより低いビットレートへ切り替えるステップが、現時点のクライアントバッファ中のデータ量（ＰＴ）が所定の最小閾値、これは固定的なダウンスイッチ閾値（ＰＴ_DOWN）であってよい、より低下した場合にも実行される。

好ましくは、動的モードに応じてパケットのビットレートの調整を制御するステップは、送信時点のビットレートに従って符号化されたデータを含むパケットがクライアントバッファに到達した後にのみ実行される。ビットレートの調整の以後と調整されたビットレートに従って符号化されたデータを含むパケットがクライアントバッファに到達する以前との間の時間帯では、調整は、代わりに待機モード（waiting mode）に応じて制御される。待機モードでは、現時点のクライアントバッファ中のデータ量（ＰＴ）がダウンスイッチ閾値（ＰＴ_DOWN）より低下した場合に、ビットレートの低減が実行される。しかし、待機モードでは、ビットレートの増加は無能化される。

様々な実施形態において、クライアントバッファ中のデータ量を示す値は、データのプレイアウト長（ＰＴ）またはバッファ・フィルレベルを示す。

実施形態に依っては、クライアントは、携帯電話機等の移動通信端末であってもよく、さらにはまたは別案として、サーバが移動通信端末に統合されて、サーバとネットワークとの間のリンクが無線であってもよい。さらに、本方法が、サーバとクライアントとの間に設けられた１つまたはそれ以上の中間ネットワーク・ノード（プロキシ等）によって実行されてよい。本方法はまた、クライアントバッファ（または、クライアントの構成に依っては多重のクライアントバッファ）によってバッファされる複数のデータ・ストリームを有するアーキテクチャにおいて利用されてもよい。

本発明はまた、コンピュータ読み取り可能な記録媒体上に格納され、それがコンピュータシステム上で走る時に上述の方法の諸ステップのいずれをも実行するためのプログラム・コード部を含むコンピュータプログラム製品で実現されてもよい。

本発明はさらに、コンピュータ処理装置およびその処理装置に結ばれた記憶装置を含む装置を含んでもよい。ここで、記憶装置は、上述の方法の諸ステップのいずれをも実行する１つまたはそれ以上のプログラムに符号化されている。

さらに別の実施形態では、本発明は、サーバからクライアントバッファを有するクライアントへのパケット送信を制御するための装置であって、現時点のクライアントバッファの状態に基づいて、サーバからクライアントへのパケットのビットレートがサーバによって調整可能である装置に関連する。本装置は、送信時点のビットレートでパケットによるデータの送信を開始するビットレート制御部と、送信後の時点のクライアントバッファ中のデータ量を示す基準値を検出するために、クライアントバッファを監視するクライアントバッファ監視部と、現時点のクライアントバッファ中のデータ量を示す値を追跡する追跡部と、現時点のクライアントバッファ中のデータ量を示す値と、基準値とに基づいて、パケットのビットレートの調整を制御する動的モード制御部とを含む。

１つの実施形態では、本装置は、パケットのビットレートの調整を待機モードに応じて制御する待機モード制御部をさらに含む。

本装置は、ネットワーク・サーバおよび／または無線端末等の固定または移動体ネットワークの構成要素として構成されてもよい。さらに、本装置は、プロキシ等の中間ネットワーク・ノードによって構成されてもよい。

以下では、本発明を、図面に示された例示的な実施形態を参照しながら説明する。

以下の記述においては、説明を目的としており限定を目的とするものではないので、本発明を完全に理解できるようにするために、特定のステップ順序や種々の構成等の具体例を詳細に説明する。本発明がこれらの具体的な詳細例とは別の実施形態においても実施可能なことは、当業者には明白であろう。さらに、当業者は、ここで以下に説明される諸機能がプログラム可能なマイクロプロセッサまたは汎用コンピュータで働くソフトウェアを使用して、および／または特定用途向け集積回路（ＡＳＩＣ）を使用して、実施される場合があることを理解できよう。また、本発明は第一義には方法として説明されるが、コンピュータプログラム製品や、コンピュータ処理装置と処理装置に結合された記憶装置、ここで記憶装置はここに開示される方法を実行する１つまたはそれ以上のプログラムに符号化されている、を含むシステムまたは装置の形で実施されてもよいことも理解されよう。

図１は、本発明に関連して使用されるアーキテクチャ例１００を示している。

アーキテクチャ例１００には、ＩＰネットワーク１１０等の通信経路を介してクライアント１１５に接続されるサーバ１０５が含まれる。サーバは、ある種のメディア・コンテンツ（例えば、マルチメディア・データ・ファイル）にＲＴＰ／ＵＤＰモジュール１２５（Real time Transport Protocol：実時間トランスポート・プロトコル／User Datagram Protocol：ユーザ・データグラム・プロトコル）を介してアクセスしたり送信したりするメディア・コンテンツ・モジュール１２０を含む。ＲＴＰ／ＵＤＰモジュール１２５は、ＵＤＰ上のＲＴＰ、または（ＵＤＰ等のトランスポート・レイヤ・プロトコルを使って）マルチメディア・データの実時間転送を管理するその他のデータ・トランスポート・プロトコルのようなストリーミング標準を使用する。

パケットは、公衆ネットワーク１３０（例えば、インターネット、ただし、サーバが事業者ネットワーク(operator network)１３５に直接接続される場合は、外部の公衆ネットワークは不要）へ送信される。公衆ネットワーク１３０は、公衆ネットワークに接続された移動通信事業者の「有線(wired)」ネットワーク等の事業者ネットワーク１３５にパケットを配信する。

事業者ネットワーク１３５は、サーバ１０５とクライアント１１５との間の通信リンクを提供するコアネットワーク１４０を含む。オプションとしてバッファを有してよいコアネットワーク１４０は、無線送信機１５０によりそれらを送信する前にＲＡＮ（radio access network: 無線アクセス・ネットワーク）１４５中のバッファ（ＳＧＳＮ中またはＲＮＣ中のバッファ等）にバッファリングするために、ＲＴＰ／ＵＤＰモジュール１２５から受信したパケットを提供する。コアネットワーク１４０（バッファリングが使用される場合の）およびＲＡＮ１４５のバッファは直列接続されて、ネットワーク・バッファを形成する。

クライアント１１５は、無線送信機１５０が送信したパケットをクライアントバッファ１５５中に受信する。パケットは、メディア・アプリケーション・モジュール１６５（すなわちマルチメディア・プレーヤ）へ配信して使用するため、クライアントバッファ１５５からＲＴＰ／ＵＤＰモジュール１６０へ転送される。

本出願の目的では、「パケット送信レート」という用語は、サーバ１０５からＩＰネットワーク１１０へのパケットの送信レートを指し、「リンクレート」という用語は、ＩＰネットワーク１１０からクライアント１１５へのパケットの送信レートを指し、「ビットレート」という用語は、メディア・アプリケーション・モジュール１６５によるプレイアウトのために、データがクライアントバッファ１５５からメディア・アプリケーション・モジュール１６５へ転送されるレートを指す。これはまた「コンテンツレート」と呼ばれることもある。

図２を参照して、例えば、図１のシステムによって実行される、本発明の方法の実施形態２００が図示されている。

図２の方法は、本発明を処理する動的モードを表わしており、動的モード単独で、または図３に示される待機モードと組み合わせて実施される。本方法は、好ましくは、図１のサーバ１０５等のサーバにより実施されるが、その他のどのような適当なネットワーク構成要素によって実施されてもよい。以下の記述では、サーバが本方法のステップを実施するものとする。

まず、ステップ２０２で、サーバは、送信時点のビットレートに従って符号化されたメディア・ストリームのパケットの送信を開始し、クライアントバッファ１５５（図１）を監視する。送信時点のビットレートは、例えば、特定のビットレートを持つストリームの予め符号化されたバージョンを選択することにより設定されてよい。ステップ２０４で、サーバは、送信後の時点、例えば、上記送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点における、クライアントバッファ中のデータ量を示す基準値を格納する。上記送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点を検出するために、サーバは、クライアントバッファから受信した信号を処理する。

１つの例では、クライアントバッファがＲＴＣＰプロトコルに準拠して実施される場合、サーバは、クライアントバッファからフィードバック情報を受信し、そのフィードバック情報はＮＳＮまたはＨＲＳＮデータ・フィールドを含んでいる。サーバは、これらのデータ・フィールド中の情報を使って、上記送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点を、少なくとも近似的に検出することができる。先述のように、クライアントバッファ中のデータ量は、例えば、プレイアウト長（ＰＴ）、クライアントバッファ・フィルレベル、またはその他の適当な値を使って示される場合がある。以下の記述では、プレイアウト長を使用する例について述べる。プレイアウト長を使用する場合、ステップ２０４で検出される基準値をＰＴ_CHとして参照する。

ステップ２０６で、サーバは、現時点のクライアントバッファ中のデータ量を示す値、すなわちＰＴを追跡する。これは、ほかの従来技術により、例えば、ＮＳＮおよびＨＲＳＮデータ・フィールド中の情報を使用して実行してもよい。

ステップ２０８で、サーバは、現時点のクライアントバッファ中のデータ量を示す値（ステップ２０６で検出）と、基準値（ステップ２０４で検出）とに基づいて、ビットレートの調整を制御する。言い換えれば、サーバは、ＰＴとＰＴ_CHの両者に基づいてビットレートの調整を制御する。ＰＴに加えてＰＴ_CHをも考慮することにより、サーバは、固定的なレート切り替え閾値のみを使用する従来システムで発生する不必要なレート切り替えの多くを回避することができる。例えば、ＰＴ_CHは調整可能なアップスイッチ閾値およびダウンスイッチ閾値を設定するのに使用されてよく、これにより不必要なレート切り替えが最小化する。

好ましくは、調整可能な閾値は、前回のアップスイッチの後、クライアントバッファのプレイアウト長がなおも増加している場合にのみ、追加のアップスイッチが実行されるよう設定される。こうして、クライアントバッファのプレイアウト長が既に減少に転じたにも拘わらず追加のアップスイッチが実行されるようなことが回避される。一方、前回のダウンスイッチの後、クライアントバッファのプレイアウト長がなおも減少している場合にのみ、追加のダウンスイッチが実行される。こうして、クライアントバッファのプレイアウト長が既に増加に転じたにも拘わらず追加のダウンスイッチが実行されるようなことは回避される。これは、以下で図５の好ましい実施形態を参照しながらもっと詳細に述べる。

図２について、最後にステップ２１０で、ステップ２０８で実行されたビットレートのいずれの調整によっても、サーバは待機モード３００へ切り替わる。

図３を参照して、待機モード３００について要約する。

以下で議論されるように、待機モード単独でも、すなわち、図２を参照して示された動的モードとは独立に実施することができる。

図３のステップ３０２で、サーバは、また現時点のクライアントバッファ中のデータ量、すなわちプレイアウト長（ＰＴ）を示す値を追跡する。ステップ３０４で、サーバは、調整されたビットレートに従って符号化されたデータを有するパケットがクライアントバッファに到達したかを検出するために、クライアントバッファを監視する。ステップ３０４で参照される調整されたレートは、図２のステップ２０８で実行されたビットレートの調整（これが、動的モードから待機モードへの切り替えを起動した）の結果である新しいビットレートである。特定のビットレートで符号化されたパケットがクライアントバッファにすでに到達したかの判定は、ＮＳＮおよびＨＲＳＮデータ・フィールド中のデータを調べることにより実行される。

ステップ３０６で、調整されたビットレートで符号化されたデータのパケットがまだクライアントバッファに到達していない間、サーバは、現時点のクライアントバッファ中のデータ量を示す値（ＰＴ）に基づくビットレート低減の実行によるビットレートのいずれの追加的調整をも制御する一方、ビットレートのいずれの増加をも無能化する。ステップ３０８で、最も新しく調整されたビットレートで符号化されたデータを有するパケットがクライアントバッファに一旦到達すると、サーバは、図２の動的モードへ戻るよう切り替える。

言い換えるならば、ステップ３０６は、前回実行されたレート調整（すなわち、アップスイッチまたはダウンスイッチ）の時点と、調整されたビットレートで符号化されたデータを含むパケットがクライアントバッファに初めて到達する時点との間の期間でだけ実行される。この期間では、レートの増加は無能化される。したがって、クライアントバッファの状態に関わらず、アップスイッチが実行されることはない。しかし、ダウンスイッチは依然として実行される。ダウンスイッチが、ほかの従来技術に従って実行される場合もある。その場合は、ＰＴは固定的なＰＴ_DOWN閾値と比較され、ＰＴがＰＴ_DOWNより低下した場合にダウンスイッチが実行される。調整されたビットレートで符号化されたデータを有するパケットがクライアントバッファに一旦到達すると、動的モードの処理が再度実行され、アップスイッチおよびダウンスイッチの両者が許される。

したがって、一旦ビットレートの調整（アップスイッチかダウンスイッチのいずれか）が実行されると、調整されたビットレートに従って符号化されたデータを含むパケットがクライアントバッファに受信されるまで、アップスイッチは無能化される。これにより、前回のレート調整が効果を発揮する前に、クライアントバッファのプレイアウト長の途中での変化に基づいて、追加的なアップスイッチを実行することがないようにする。

上述の「発明の開示」の項で説明したように、前回のレート調整が効果を発揮する前に、クライアントバッファのプレイアウト長が変化する状況が起こり得る。そのような変化は、往々にして追加的なアップスイッチを起動することがあり、それらが不必要で逆効果を有することもしばしばである。実際に、一連のダウンスイッチが必要となるまでビットレートが増加することもよくあり、それらのダウンスイッチが十分迅速に実行できないため、バッファ溢れを防止できないことも多い。

一方、待機モードであっても、ダウンスイッチは実行されてよい。通常、再バッファリングの発生が端末ユーザに惹き起こす不愉快さのレベルは高いことから、再バッファリングの発生はいかなる状況においても回避されるべきであり、その発生の可能性を防ぐために追加的なダウンスイッチが許される。

調整されたビットレート（すなわち、図２のステップ２０８で設定されたレート）に従って符号化されたデータを含むパケットが最終的にクライアントバッファに受信され、動的モードへ戻る切り替えが起動される以前には、一連のダウンスイッチがステップ３０６で実行されることがあってもよいことに注意されたい。１つの例では、サーバが切り替えにより動的モードへ戻る時、動的モードの論理が使用する新しい「現時点の(current)」レートは、最新の、すなわち最も最近のダウンスイッチに従うレートである。

本例では、待機モードの間に一連のダウンスイッチが実行された場合、最新のダウンスイッチに従って送信されたパケットが最終的にクライアントバッファに受信されるまで、サーバはＰＴ_CHを更新しない。

別の例では、サーバが切り替えにより動的モードへ戻る時、動的モードの論理が使用する新しい「現時点の」レートは、先の例とは違って、待機モードで実行された最初のダウンスイッチに従うレートである。この第２の例では、待機モード中に一連のダウンスイッチが実行された場合、最初のダウンスイッチに従って送信されたパケットがクライアントバッファに受信されると、サーバは直ぐにＰＴ_CHを更新する。

以上のように、図２および図３に本発明の動的モードおよび待機モードが要約される。好ましい実施形態では、サーバは両方のモードを実施でき、ビットレートが調整された時点と、送信時点のビットレートで符号化されたデータのパケットがクライアントバッファに到達した時点とに基づいて、両モード間の行き来を切り替える。

図４は、２つの動作モードを要約する状態図を示す。

サーバは、レートの調整３１０（アップスイッチかダウンスイッチのいずれか）が実行されるまで動的モード２００に留まり、レートの調整により待機モードへの遷移が起動される。その後、サーバは、送信時点のビットレートに従って符号化されたデータを含むパケットがクライアントバッファに到達する３１２まで待機モードに留まり、上記到達により動的モードへ戻る遷移が起動される。

以上のようにして、サーバは、バッファ溢れを防ぐ働きをしながら、不必要なレート切り替えを最小化するために常に動作モードを選択して動作し、そして最も重要なことは、再バッファリングの発生を防ぐ働きをすることである。

しかし、別の実施形態では、サーバが動的モードのみを実施するかまたは待機モードのみを実施するよう構成される場合もある。

動的モードのみが実施される場合、好ましくは、サーバが常に動的モードに留まるよう構成される。言い換えるならば、ビットレートの調整（これは、例えば、図２のステップ２０８で起動される）が他のモードへの遷移を起動することはない。処理は動的モード中でのみ続けられ、調整されたビットレートに従って符号化されたデータを含むパケットがクライアントバッファに到達する時点を検出するために、サーバはクライアントバッファを監視し、それに従ってＰＴ_CHを更新する。

しかし、待機モードのみが実施される場合、好ましくは、サーバが待機モードに常に留まる（これでは、アップスイッチが永久に実行されない）ことはない。むしろ、好ましくは、サーバの動作は待機モードと通常モード(normal mode)との間を行ったり来たりするよう切り替わる。ここで、通常モードは、ほかの従来型の動作モード（固定的なアップスイッチの閾値およびダウンスイッチの閾値が、プレイアウト長またはクライアントバッファ・フィルレベルとともに使用される）であってよい。通常モードは、図５の閾値メカニズムに加えてまたはその代わりに、この技術分野でよく知られるレート評価メカニズムを使用することがあってよい。言い換えれば、動的モードを通常モードに置き換えることを除いて、システムは、図４の状態図に類似した状態図に従って実施される。

図５に移り、図２のステップ２０８で使用される動的モードの論理の実施形態例について述べる。

この実施形態例では、基準値ＰＴ_CHは、送信時点のレートで送信されたパケットが初めてクライアントバッファに到達した時点の、クライアントバッファ中のデータ量を示す。別の例では、基準値ＰＴ_CHを検出するのに別の基準時点(reference points)が代わりに使用される。例えば、レート切り替えの時点と新しいレートで送信されたパケットが初めてクライアントバッファに到達した時点との間に定義された基準時点、および新しいレートで送信されたパケットが初めてクライアントバッファに到達した後に定義された基準時点、等である。

まず、ステップ４００で、サーバは、ＰＴ_UP、ＰＴ_DOWN、ＰＴ_CH、および安全値Ｓへ値を入力する。ＰＴ_UPおよびＰＴ_DOWNは、それぞれ所定の固定的なアップスイッチ閾値およびダウンスイッチ閾値であり、これらはほかの従来技術に従って設定される場合もある。ＰＴ_CHは、図２のステップ２０４で判定された値であり、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点の、クライアントバッファ中のデータ量を示す。Ｓは安全値であり、１．０より大きく設定され、１．２に設定した例もある。ステップ４０２で、サーバは、調整可能なアップスイッチ閾値（ＰＴ_UP-ADJ）をＰＴ_CHに安全値Ｓを乗じたものに等しいと設定する。ステップ４０４で、サーバは、調整可能なダウンスイッチ閾値（ＰＴ_DOWN-ADJ）を、ＰＴ_CHにＰＴ_DOWNを加え全体を２で除算したものに等しいと設定する。すなわち、ＰＴ_DOWN-ADJは、ＰＴ_CHとＰＴ_DOWNとの中ほどに設定される。一般的には、ＰＴ_DOWN-ADJは、ＰＴ_CHとＰＴ_DOWNの間のどの点に設定されてもよい。

それらの閾値が図６に示される。図６は、図１のクライアントバッファ１５５をブロック図で表わしたものである。

図６の例では、ＰＴ_CHは、サーバによってＰＴ_UPより大きい値として見いだされた。したがって、ＰＴ_CHとＰＴ_DOWNとの中ほどに設定されるＰＴ_DOWN-ADJは、ＰＴ_DOWNより大きい。一方、ＰＴ_CHがＰＴ_DOWNより小さい場合は、同様にＰＴ_DOWN-ADJもＰＴ_DOWNより小さくなる。また、図６の例では、ＰＴ_UP-ADJ（これはＰＴ_CH＊Ｓに等しい）は、ＰＴ_UPより大きい。

一方、別の例で、ＰＴ_CHがＰＴ_UPよりかなり小さい場合は、ＰＴ_UP-ADJはＰＴ_UPより小さいかもしれない。これは、安全係数Ｓに使用される値のみならずＰＴ_CHの正確な値にも依存する。したがって、ＰＴ_CHおよびその他の係数の値に依って、ＰＴ_UPおよびＰＴ_DOWNの調整可能バージョンは、それらの固定的な相手より大きい場合もあり小さい場合もある。ＰＴ_CH＊Ｓがクライアントバッファの最大値（ＭＡＸ）より大きいような状況が生じ得ることにも注意されたい。それが事実の場合、ＰＴ_UP-ADJは、単に、ＭＡＸに等しいかまたは他のもっと小さいデフォルト値に設定される。

図５に戻って、ステップ４０６で、サーバは、図２のステップ２０６で追跡されたＰＴ（すなわち、クライアントバッファ中に既に含まれるデータの現時点のプレイアウト長）の値の入力を開始する。判定ステップ４０８では、ＰＴがＰＴ_DOWNより大きく、且つＰＴがＰＴ_UP-ADJよりも大きい場合、ステップ４１０でアップスイッチが起動される。そうでない場合は、判定ステップ４１２が実行され、ＰＴがＰＴ_DOWNより小さいか、またはＰＴがＰＴ_UP-ADJより小さい場合、ステップ４１４でダウンスイッチが起動される。

判定ステップ４０８および４１２の論理は、以下のように表現されてもよい。

If ＰＴ＞ＰＴ_DOWN AND ＰＴ＞ＰＴ_UP-ADJ then
Perform up-switch
else if ＰＴ＜ＰＴ_DOWN OR ＰＴ＜ＰＴ_DOWN-ADJ
Perform down-switch
end if
ここで、先述のように、
ＰＴ_UP-ADJ=ＰＴ_CH＊Ｓ であり、且つ
ＰＴ_DOWN-ADJ=(ＰＴ_CH+ＰＴ_DOWN）／２
である。

このように、アップスイッチは、現時点のクライアントバッファのプレイアウト長（ＰＴ）が調整されたアップスイッチ閾値（ＰＴ_UP-ADJ）を超過した場合に、ＰＴがＰＴ_DOWNをも超過していると、起動される。この後者の条件は、ダウンスイッチの方がより適切かもしれない状況での不適切なアップスイッチを防止する。固定的なアップスイッチ閾値ではなく、調整されたアップスイッチ閾値に基づいてアップスイッチを起動することにより、サーバは、現時点のクライアントバッファの状態（ＰＴで示される）を考慮に入れる一方、クライアントバッファの状態の動的な変化をも（アップスイッチ閾値の調整を通して）考慮に入れる。これにより、その他の不適切なアップスイッチの防止に役立つ。

調整可能なアップスイッチ閾値が固定的なアップスイッチ閾値にぴったり等しく初期設定される例を考えよう。ここで、クライアントバッファのプレイアウト長がその閾値レベルを超過した場合、アップスイッチが実行される。その後、そのより高いビットレートで送信された最初のパケットがクライアントバッファに到達する以前にプレイアウト長が増加しても、その時には調整可能なアップスイッチ閾値は固定的な閾値より大きくなっていよう。その場合、プレイアウト長がその新しいより高い閾値を超過した場合にのみ、追加的なアップスイッチが実行される。言い換えるならば、より高い閾値を超過せねばならないため、アップスイッチはより起動され難くなる。こうして、追加的なアップスイッチが遅れることになる。これは、アップスイッチの遅れが正当化される状況だからである。

一方、固定的なアップスイッチ閾値がここでも使用されたとすると、クライアントバッファのプレイアウト長の増加は、その固定的な閾値を再度超過する新しい値をＰＴがとる結果となる。こうして、アップスイッチをもう１回起動することになろう。本例では、パケットが最初に受信された時点のプレイアウト長に基づいて閾値を再設定するので、プレイアウト長がさらに増加した場合にのみアップスイッチをもう１回起動できる。先述の安全係数は、アップスイッチをもう１回起動する前には、プレイアウト長がＰＴ_CHとの対比で有意に増加しなければならないことを確実にするための備えである。このようにして、最初のアップスイッチの後では、これに続くアップスイッチは、バッファのプレイアウト長がなおも増加している場合に実行される。これにより、不必要なアップスイッチが回避される。

さて、調整可能なアップスイッチ閾値は今度も固定的なアップスイッチ閾値に等しく初期設定されるが、より高いビットレートで送信された最初のパケットがクライアントバッファに到達する以前にプレイアウト長が有意に減少する例を考えよう。この場合には、調整可能なアップスイッチ閾値は固定的な閾値より低くなる。その場合は、プレイアウト長が新しいより低い閾値を超過するので（固定的な閾値ＰＴ_DOWNも超過するとして）、追加的なアップスイッチが実行される。言い換えるならば、アップスイッチはより起動し易くなり、アップスイッチが遅滞なく実行される。これは、アップスイッチが正当化される状況だからである。

さてダウンスイッチであるが、ダウンスイッチは、現時点のクライアントバッファのプレイアウト長（ＰＴ）が、固定的な閾値ＰＴ_DOWNか、または調整されたダウンスイッチ閾値（ＰＴ_DOWN-ADJ）より低下した場合に、起動される。言い換えるならば、ダウンスイッチは、ＰＴが２つのダウンスイッチ閾値の大きいものより低下すると起動される。ダウンスイッチが遅延するのを防止して再バッファリングの発生を防止し易くするため、固定的な閾値がダウンスイッチの起動のためになお使用される。

しかし、ダウンスイッチの促進が可能であり、このダウンスイッチの促進は、ＰＴが調整されたダウンスイッチ閾値より低下した場合に起こる。先述のように、調整されたダウンスイッチ閾値は固定的なダウンスイッチ閾値より結果的に大きい場合も小さい場合もある。調整されたダウンスイッチ閾値が固定的なダウンスイッチ閾値より小さい場合、とにかく固定的なダウンスイッチ閾値を使用して直ちにダウンスイッチが起動されるので、それは余分である。しかし、調整可能なダウンスイッチ閾値が固定的なダウンスイッチ閾値を超過している場合は、調整可能なダウンスイッチ閾値は促進されたダウンスイッチ、すなわち、従来の切り替え論理を使用していてはダウンスイッチが起こらない状況において生起するダウンスイッチ、を起動することができる。促進されたダウンスイッチは、先述のように、プレイアウト長が調整可能なダウンスイッチ閾値より低下した場合に生起する。

判定ステップ４０８および４１２のいずれの条件も満たさない場合、処理はステップ４０６へ戻り、そこでＰＴの最新値が入力されて種々の閾値に適用される。しかし、アップスイッチとダウンスイッチのいずれかが起動されたとすると、ステップ４１６が実行され、そこでサーバは待機モードに切り替わる。待機モードの論理は、以下で図７を参照しつつ述べる。

簡単にまとめると、図５の動的モードの判定論理は、現時点のクライアントバッファ中のデータ量が調整されたアップスイッチ閾値を超過した場合に、パケットのビットレートをより高いビットレートへ切り替えるよう調整を制御する手段を与える。ここで、この調整されたアップスイッチ閾値は、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点で、クライアントバッファ中のデータ量を示す値に基づいて設定されたものである。しかし、より高いビットレートへの切り替えは、現時点のクライアントバッファ中のデータ量が最低閾値をも超過した場合にのみ実行される。

動的モードの判定論理は、また、現時点のクライアントバッファ中のデータ量が調整されたダウンスイッチ閾値より低下した場合に、ビットレートをより低いビットレートに切り替えるよう調整を制御する手段を与える。ここで、この調整されたダウンスイッチ閾値は、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点で、クライアントバッファ中のデータ量を示す値に基づいて設定されたものである。

次は図７であり、図３のステップ３０６で使用した待機モードの論理の好ましい実施形態について説明する。

まず、ステップ５００で、サーバは、ＰＴ_UPおよびＰＴ_DOWNへ値を入力する。それらは図６で使用されたのと同じ固定的な閾値である。ステップ５０２では、サーバは、図２のステップ２０６で追跡されたＰＴ、すなわち、現時点のクライアントバッファに既に含まれるデータのプレイアウト長の値の入力を開始する。

判定ステップ５０４では、プレイアウト長（ＰＴ）がＰＴ_DOWNより低下した場合、ステップ５０６でダウンスイッチが起動される。そうでない場合、判定ステップ５０８で、サーバが、最新の調整されたビットレートで送信されたパケットがクライアントバッファに到達したかを判定する。もし到達したならば、ステップ５１０で、処理はすぐに動的モードへ戻る。到達してなければ、処理はステップ５０２へ戻り、プレイアウト長の更新された値が、ステップ５０４での固定的なダウンスイッチ閾値との比較のために入力される。

図７の論理で特に注意すべきことは、アップスイッチ閾値については比較は行われず、アップスイッチは実行されないことである。既に説明したように、待機モードの間は不適切なアップスイッチを防止するために、アップスイッチは無能化される。ダウンスイッチは、再バッファリングの生起の可能性を回避するためにダウンスイッチが確実に実行されるよう、固定的なダウンスイッチ閾値により起動される。待機モードでは、調整可能な閾値は使用されない。

以上により、パケット中の符号化されたデータのビットレートを増加または減少させることにより、パケットベース・システムのデータ送信レートを総合的に調整する技術について、方法の例示的な実施形態を説明した。パケットの送信レートは、通信リンクの帯域幅に依存するので、通常は変化しない。しかし、パケットの送信レートが、例えば、適応技術を使用して調整される実施形態があってよい。

主に方法の実施形態に関して本発明を説明してきたが、装置の実施形態もまた本発明に含まれる。図８は、例示的な装置の実施形態を大まかなレベルで示す。

簡単に言えば、図１のサーバ１０５に含まれてよいネットワーク構成要素６００は、送信時点のビットレートでパケット中のデータの送信を開始するためのビットレート制御部６０２と、送信時点のビットレートに従って符号化されたデータを含むパケットが初めてクライアントバッファに到達した時点等の、送信後の時点のクライアントバッファ中のデータ量を示す基準値を検出するために、クライアントバッファを監視するためのクライアントバッファ監視部６０４とを含む。追跡部６０６は、現時点のクライアントバッファ中のデータ量を示す値を追跡する。

動的モード制御部６０８は、現時点のクライアントバッファ中のデータ量を示す値と、基準値とに基づいて、パケットのビットレートの調整を制御するために装備される。本装置は、また、待機モードにおいてパケットのビットレートの調整を制御するための待機モード制御部６１０を含む場合もある。動的モード制御部６０８が図５の動的モードの論理を実施し、一方、待機モード制御部６１０が図７の待機モードの論理を実施する。動的モード制御部６０８を含まなかったり、または待機モード制御部６１０を含まなかったりする、別の実施形態例があってもよい。

通常の当業者には理解できるように、本発明およびこれに関わる技術は、クライアントバッファの溢れや枯渇を回避することにより、マルチメディア・ストリーミング等のアプリケーションに対する、末端ユーザが知覚できるより増進させた経験を提供するものである。

さらに、当業者は、また、クライアントバッファ・フィルレベルの判定に使用される、ＲＲｓおよび送信者レポート(Sender Reports)中のデータに基づく評価を含む多くの異なる技術が存在すること、および、本発明が、１つまたはそれ以上のクライアントに送信するため、１つまたはそれ以上のネットワーク・バッファに同時にバッファされる複数のデータパケット・ストリームで並列に実施されること、を理解するであろう。また、バッファ溢れを回避するために、以上で説明したアップスイッチに加えて、送信レート制御メカニズムが使用される場合もある。通常の当業者は、さらに、本発明が、ネットワーク端末、ネットワーク・ノード等の種々のタイプのネットワーク構成要素において、またそれらのネットワーク構成要素によって、実施されることを理解しよう。特に、本発明は、移動端末、プロキシ（これにより送信経路を分割することもできる）、および固定端末によって実施される場合もある。

本発明を特定の実施形態について説明してきたが、当業者には、本発明がここで説明されまた例示された特定の実施形態に限定されるものでないことは理解されよう。従って、本発明についてその好ましい実施形態を説明してきたが、この開示がその例を示すにすぎないことを理解されたい。したがって、本発明は、ここに添付の請求項によってのみ限定されるよう意図するものである。

本発明を理解し実施するのに有用な通信システムの概略図である。 本発明の動的モードでの方法の実施形態の概要を示す処理の流れの図である。 本発明の待機モードでの方法の実施形態の概要を示す処理の流れの図である。 動的モードと待機モードとの間の相互関係の概要を示す状態図である。 本発明の動的モードの論理の例示的な実施形態を示す処理の流れの図である。 特に本発明によって使用される種々の閾値を示している、例示的なクライアントバッファのブロック図である。 本発明の待機モードの論理の例示的な実施形態を示す処理の流れの図である。 本発明のサーバ構成要素の例示的な装置の実施形態を示すブロック図である。

Claims (20)

1. サーバ（１０５）からクライアントバッファ（１５５）を有するクライアント（１１５）へのパケット送信を制御する方法であって、パケットで送信されるデータの符号化ビットレートが前記クライアントバッファの状態に基づいて前記サーバにより選択され、前記サーバと、前記サーバと前記クライアントの間に設けられたネットワーク・ノードとの少なくとも何れかによって実行される方法において、
   送信時点の符号化ビットレートに従って符号化されたデータを含むパケットの送信を開始するステップ（２０２）と、
   前記送信時点の符号化ビットレートに従って符号化された前記データを含むパケットが初めて前記クライアントバッファに到達する時点を検出するために、前記クライアントから受信されるフィードバック情報を用いて前記クライアントバッファ（１５５）を監視するステップ（２０２）と、
   前記送信時点の符号化ビットレートに従って符号化された前記データを含むパケットが初めて前記クライアントバッファに到達した時点における、前記クライアントバッファ（１５５）中のデータ量を示す基準値（ＰＴ_CH）を、前記フィードバック情報を用いて検出するステップ（２０４）と、
   現時点の前記クライアントバッファ中のデータ量を示す値（ＰＴ）を、前記フィードバック情報を用いて追跡するステップ（２０６）と、
   動的モード（２００）に応じて、現時点の前記クライアントバッファ（１５５）中のデータ量を示す前記値（ＰＴ）と、前記基準値（ＰＴ_CH）とに基づき、送信中のデータの前記符号化ビットレートの調整を制御するステップ（２０８）と
   を含むことを特徴とする方法。
2. 前記動的モードにおける調整を制御する前記ステップ（２０８）は、
   現時点の前記クライアントバッファ中の前記データ量（ＰＴ）が、前記基準値（ＰＴ_CH）に基づいて設定された調整可能なアップスイッチ閾値（ＰＴ_UP-ADJ）を超過した場合、より高い符号化ビットレートへ切り替えるステップ（４１０）を含むことを特徴とする請求項１に記載の方法。
3. 前記調整可能なアップスイッチ閾値（ＰＴ_UP-ADJ）が、所定の安全マージン（Ｓ）と前記基準値（ＰＴ_CH）との積にほぼ等しく設定されることを特徴とする請求項２に記載の方法。
4. 前記動的モードにおいてより高い符号化ビットレートへ切り替える前記ステップは、現時点の前記クライアントバッファ中の前記データ量（ＰＴ）が最小閾値を超過した場合（４０８）にのみ実行されることを特徴とする請求項２または３に記載の方法。
5. 前記動的モード（２００）において調整を制御する前記ステップ（２０８）は、
   現時点の前記クライアントバッファ中の前記データ量（ＰＴ）が、前記基準値（ＰＴ_CH）に基づいて設定された調整可能なダウンスイッチ閾値（ＰＴ_DOWN-ADJ）より低下した場合、より低い符号化ビットレートへ切り替えるステップ（４１４）を含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記調整可能なダウンスイッチ閾値（ＰＴ_DOWN-ADJ）が、所定の最小閾値（ＰＴ_DOWN）と前記基準値（ＰＴ_CH）とのほぼ中央に設定される（４０４）ことを特徴とする請求項５に記載の方法。
7. 前記動的モード（２００）においてより低い符号化ビットレートへ切り替える前記ステップ（４１４）は、現時点の前記クライアントバッファ中の前記データ量（ＰＴ）が前記所定の最小閾値（ＰＴ_DOWN）より低下した場合にも実行されることを特徴とする請求項５または６に記載の方法。
8. 前記最小閾値（ＰＴ_DOWN）が固定的ダウンスイッチ閾値である（４００）ことを特徴とする請求項６または７に記載の方法。
9. 前記動的モード（２００）においてパケットの前記符号化ビットレートの調整を制御する前記ステップ（２０８）は、前記送信時点の符号化ビットレートに従って符号化されたデータを含んで送信されたパケットが前記クライアントバッファに到達した（３１２）後にのみ実行されることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 待機モード（３００）において、データの前記符号化ビットレートの追加的な調整を制御するステップ（３０６）をさらに含むことを特徴とする請求項９に記載の方法。
11. 前記待機モード（３００）における、データの前記符号化ビットレートの追加的な調整を制御する前記ステップ（３０６）は、レート調整の以後および新しく調整された符号化ビットレートに従って符号化されたデータを含んで送信されたパケットが前記クライアントバッファに到達する以前にのみ実行される(３１０)ことを特徴とする請求項１０に記載の方法。
12. 前記待機モード（３００）における、パケットの前記符号化ビットレートの追加的な調整を制御する前記ステップ（３０６）は、現時点の前記クライアントバッファ中の前記データ量（ＰＴ）が固定的なダウンスイッチ閾値（ＰＴ_DOWN）より低下した場合、より低い符号化ビットレートへ切り替えるステップを含むことを特徴とする請求項１１に記載の方法。
13. 前記待機モード（３００）における、パケットの前記符号化ビットレートの追加的な調整を制御する前記ステップ（３０６）は、前記符号化ビットレートの増加を無能化するステップ（３０６）を含むことを特徴とする請求項１１または１２に記載の方法。
14. 前記クライアントバッファ中の前記データ量を示す前記値が、前記データのプレイアウト長（ＰＴ）またはバッファ・フィルレベルを示すことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. 前記サーバは無線端末であることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
16. 請求項１乃至１５のいずれか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータプログラム。
17. 請求項１６に記載のコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
18. コンピュータ処理装置と該コンピュータ処理装置と接続した記憶装置とを含む装置（６００）であって、
    前記記憶装置が、請求項１乃至１５のいずれか１項に記載の方法の各ステップを前記コンピュータ処理装置に実行させるためのコンピュータプログラムを記憶していることを特徴とする装置。
19. サーバ（１０５）からクライアントバッファ（１５５）を有するクライアント（１１５）へのパケット送信を制御する装置（６００）であって、前記サーバにより、前記サーバから前記クライアントへパケットで送信されるデータの符号化ビットレートが現時点の前記クライアントバッファの状態に基づいて調整され、前記サーバと、前記サーバと前記クライアントの間のネットワークとの少なくとも何れかに含まれる装置（６００）において、
    送信時点の符号化ビットレートでパケットでのデータの送信を開始するビットレート制御部（６０２）と、
    前記送信時点の符号化ビットレートに従って符号化された前記データを含むパケットが初めて前記クライアントバッファに到達する時点を検出するために、前記クライアントから受信されるフィードバック情報を用いて前記クライアントバッファ（１５５）を監視し（２０２）、前記送信時点の符号化ビットレートに従って符号化された前記データを含むパケットが初めて前記クライアントバッファに到達した時点における、前記クライアントバッファ（１５５）中のデータ量を示す基準値（ＰＴ_CH）を、前記フィードバック情報を用いて検出する（２０４）クライアントバッファ監視部（６０４）と、
    現時点の前記クライアントバッファ（１５５）中のデータ量を示す値を、前記フィードバック情報を用いて追跡する追跡部（６０６）と、
    前記現時点の前記クライアントバッファ中のデータ量を示す前記値と、前記基準値とに基づいて、パケットで送信中のデータの前記符号化ビットレートの調整を制御する動的モード制御部（６０８）と
    を含むことを特徴とする装置。
20. 前記サーバは無線端末であることを特徴とする請求項１９に記載の装置。

Images