(57)【要約】マルチメディアストリーミングネットワークのクライアント内のレシーババッファのレベルを適応制御する方法及びシステムである。このマルチメディアストリーミングネットワークは、クライアントにストリーミングデータを提供するサーバーを具備している。そして、このサーバーは、伝送レートを受信レートに対して適合させ（即ち、輻輳制御）、且つ、サンプリングレートを伝送レートに対して適合させる責任を担っている。従って、サーバーは、シフトを管理し、これをレート適合動作レンジ内に維持する。一方、クライアントは、パケット転送遅延変動（これは、ネットワークジッタとも呼ばれる）を補償する責任を担っている。又、クライアントは、サーバーレート適合動作レンジのパラメータを設定する責任をも担っている。クライアントは、シフトパラメータを選択してサーバーに送信するが、これらのパラメータに応答したそのエンコーディングレート又は伝送レートの適合は、サーバーに任されている。
2006524452.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディアストリーミングネットワークのクライアント内のレシーババッファのレベルを適応制御する方法であって、前記ストリーミングネットワークは、ストリーミングデータを前記クライアントに提供するサーバーを有しており、前記レシーババッファは、前記クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記サーバーによるデータ伝送量と前記クライアントによるデータ使用量間の差を補償するために使用される、方法において、
前記サーバーと前記クライアント間のレート適合を実行するために、前記クライアント内において、レート適合動作レンジを決定するための少なくとも１つのパラメータを定め、
前記サーバー内において、前記少なくとも１つのパラメータに基づいて、前記データ量を受信レートに対して適合させ、
前記クライアント内において、前記適合に基づいて、パケット転送遅延変動を調節すること、
を有することを特徴とする方法。
【請求項２】
前記少なくとも１つのパラメータは、前記サーバーが、最小シフト量に基づいて前記適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す前記最小シフト量を有することを特徴とする請求項１記載の方法。
【請求項３】
前記少なくとも１つのパラメータは、前記サーバーが、目標シフト量に基づいて前記適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す前記目標シフト量を有することを特徴とする請求項１又は２記載の方法。
【請求項４】
前記少なくとも１つのパラメータは、前記サーバーが、送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数に基づいて前記適合を実行できるようにするべく、前記の数を有することを特徴とする請求項１〜３の中のいずれか一項記載の方法。
【請求項５】
前記少なくとも１つのパラメータに基づいて前記サーバー内においてサンプリングレートを前記伝送レートに対して適合させることを更に有することを特徴とする請求項１〜４の中のいずれか一項記載の方法。
【請求項６】
前記少なくとも１つのパラメータは、前記クライアント内における再生の中断を防止するためのクロックシフト量を有することを特徴とする請求項１〜５の中のいずれか一項記載の方法。
【請求項７】
前記適合は、伝送レートの調節を有することを特徴とする請求項１〜６の中のいずれか一項記載の方法。
【請求項８】
前記適合は、サンプリングレートの調節を有することを特徴とする請求項１〜７の中のいずれか一項記載の方法。
【請求項９】
前記適合は、伝送レートとサンプリングレートの両方の調節を有することを特徴とする請求項１〜６の中のいずれか一項記載の方法。
【請求項１０】
前記少なくとも１つのパラメータは、
前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と、
前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と、
送信されたバイト数とサンプリングされたバイトの数の間の最大の差を規定する数と、
クロックシフト量と、
を有しており、
前記最小シフト量、前記ターゲットシフト量、前記規定数、及び前記クロックの中の複数のものが一緒に前記サーバーに対して送信されることを特徴とする請求項１記載の方法。
【請求項１１】
少なくとも１つのクライアントと、
前記クライアントに対してストリーミングデータを提供するサーバーによって特徴付けられ、
前記クライアントは、前記クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記サーバーによるデータ伝送量と前記クライアントによるデータ使用量の間の差を補償するレシーババッファを有しており、
前記クライアントは、
前記サーバーが、少なくとも１つのパラメータに基づいて、前記データ量を受信レートに対して適合させることができるようにするべく、レート適合動作レンジを決定するための前記少なくとも１つのパラメータを定めるメカニズムと、
前記適合に基づいて、パケット転送遅延変動を調節するメカニズムと、
を有することを特徴とするマルチメディアストリーミングシステム。
【請求項１２】
前記少なくとも１つのパラメータは、前記サーバーが前記適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量を有することを特徴とする請求項１１記載のマルチメディアストリーミングシステム。
【請求項１３】
前記少なくとも１つのパラメータは、前記サーバーが前記適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量を有することを特徴とする請求項１１又は１２記載のマルチメディアストリーミングシステム。
【請求項１４】
前記少なくとも１つのパラメータは、前記サーバーが前記適合を実行できるようにするべく、送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数を有することを特徴とする請求項１１〜１３の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項１５】
前記サーバーは、前記少なくとも１つのパラメータに基づいて、サンプリングレートを前記伝送レートに対して適合させる適合メカニズムを有することを特徴とする請求項１１〜１４の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項１６】
前記少なくとも１つのパラメータは、前記クライアント内における再生の中断を防止するためのクロックシフト量を有することを特徴とする請求項１１〜１５の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項１７】
前記サーバーは、伝送レートを調節する適合メカニズムを有することを特徴とする請求項１１〜１６の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項１８】
前記サーバーは、サンプリングレートを調節する適合メカニズムを有することを特徴とする請求項１１〜１７の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項１９】
前記サーバーは、伝送レートとサンプリングレートの両方を調節する適合メカニズムを有することを特徴とする請求項１１〜１６の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項２０】
前記サーバーは、前記適合を実行する少なくとも１つのコードを具備するソフトウェアプログラムを有することを特徴とする請求項１１〜１９の中のいずれか一項記載のマルチメディアストリーミングシステム。
【請求項２１】
クライアント内のレシーババッファのレベルを適応制御するマルチメディアストリーミングネットワークの前記クライアント内において使用するソフトウェアプロダクトであって、前記マルチメディストリーミングネットワークは、前記クライアントにストリーミングデータを提供する能力を有するサーバーを有しており、前記クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記レシーババッファを使用することにより、前記サーバーによるデータ伝送量と前記クライアントによるデータ使用量の間の差を補償する、ソフトウェアプロダクトにおいて、
前記サーバーと前記クライアント間のレート適合を実行するべく、前記サーバー内におけるレート適合動作レンジを決定する少なくとも１つのパラメータを定めるコードと、
前記適合に基づいて、パケット転送遅延変動を調節するコードと、
を有することを特徴とするソフトウェアプロダクト。
【請求項２２】
前記少なくとも１つのパラメータは、前記サーバーが前記レート適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量を有することを特徴とする請求項２１記載のソフトウェアプロダクト。
【請求項２３】
前記少なくとも１つのパラメータは、前記サーバーが前記レート適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表すターゲットシフト量を有することを特徴とする請求項２１又は２２記載のソフトウェアプロダクト。
【請求項２４】
前記少なくとも１つのパラメータは、前記サーバーが前記レート適合を実行できるようにするべく、送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数を有することを特徴とする請求項２１〜２３の中のいずれか一項記載のソフトウェアプロダクト。
【請求項２５】
前記少なくとも１つのパラメータは、前記クライアント内における再生の中断を防止するためのクロックシフト量を有することを特徴とする請求項２１〜２４の中のいずれか一項記載のソフトウェアプロダクト。
【請求項２６】
ストリーミングデータを端末に提供する少なくとも１つのサーバーを具備するマルチメディアストリーミングネットワークの前記端末であって、前記端末は、前記端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記サーバーによるデータ伝送量と前記端末によるデータ使用量の間の差を補償するためのレシーババッファを具備している、端末において、
前記サーバーが、前記少なくとも１つのパラメータに基づいて、前記データ伝送量を受信レートに対して適合させることができるようにするべく、前記サーバー内のレート適合動作レンジを決定する少なくとも１つのパラメータを定めるメカニズムと、
前記適合に基づいて、パケット転送遅延変動を調節するメカニズムと、
を有することを特徴とする端末。
【請求項２７】
前記定めるメカニズムは、前記少なくとも１つのパラメータを定める少なくとも１つのコードを具備するソフトウェアプログラムを有することを特徴とする請求項２６記載の端末。
【請求項２８】
前記調節メカニズムは、前記パケット転送遅延変動を調節する少なくとも１つのコードを具備するソフトウェアプログラムを有することを特徴とする請求項２６又は２７記載の端末。
【請求項２９】
前記少なくとも１つのパラメータは、前記サーバーが、最小シフト量に基づいて、前記適合段階を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す前記最小シフト量を有することを特徴とする請求項２６〜２８の中のいずれか一項記載の端末。
【請求項３０】
前記少なくとも１つのパラメータは、前記サーバーが、ターゲットシフト量に基づいて前記適合を実行できるようにするべく、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す前記ターゲットシフト量を有することを特徴とする請求項２６〜２９の中のいずれか一項記載の端末。
【請求項３１】
前記少なくとも１つのパラメータは、前記サーバーが、数に基づいて前記適合を実行できるようにするべく、送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する前記数を有することを特徴とする請求項２６〜３０の中のいずれか一項記載の端末。
【請求項３２】
ネットワーク要素からストリーミングデータを受信する少なくとも１つの端末を具備するマルチメディアストーミングネットワークの前記ネットワーク要素であって、前記端末は、前記端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記ネットワーク要素によるデータ伝送量と前記端末によるデータ使用量の間の差を補償するためのレシーババッファを具備している、ネットワーク要素において、
前記端末から要求を受信する手段であって、前記要求は、前記ネットワーク要素内におけるレート適合動作レンジを決定する少なくとも１つのパラメータを表している、手段と、
前記端末が、前記少なくとも１つのパラメータに基づいて、前記データ伝送レートを前記端末による受信レートに対して適合させて、前記適合に基づいて、パケット転送遅延変動を調節できるようにするメカニズムと、
を有することを特徴とするネットワーク要素。
【請求項３３】
前記調節メカニズムは、前記データ伝送量を適合させる少なくとも１つのコードを具備するソフトウェアプログラムを有することを特徴とする請求項３２記載のネットワーク要素。
【請求項３４】
前記ソフトウェアプログラムは、前記伝送レートを適合させるコードを有することを特徴とする請求項３３記載のネットワーク要素。
【請求項３５】
前記ソフトウェアプログラムは、サンプリングレートを調節するコードを有することを特徴とする請求項３３又は３４記載のネットワーク要素。
【請求項３６】
前記ソフトウェアプログラムは、伝送レートとサンプリングレートの両方を調節するコードを有することを特徴とする請求項３３〜３５の中のいずれか一項記載のネットワーク要素。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、マルチメディアストリーミングに関し、更に詳しくは、マルチメディアストリーミングサービスにおけるサーバーとクライアント間のレート適合に関するものである。
【背景技術】
【０００２】
マルチメディアストリーミングサービスには、ストリーミングサーバー、ストリーミングクライアント、及び伝送チャネル（又は、その基礎をなすネットワーク）という３つの要素が関係している。通常、このサービスのボトルネックは、スループットと信頼性の両方の観点において（即ち、スループットビットレートが保証されていない場合は）、伝送チャネルであるが、スループットの制限は、クライアント及び／又はサーバーにおいても発生する場合がある。
【０００３】
従って、リアルタイムストリーミングシステムにおいては、チャネル、クライアント、及びサーバーのスループット特性の動的な変化に起因し、ユーザーのリアルタイム再生状態を維持するべく、ストリーミング供給を適合可能にしておく必要があり、サーバーは、システムのスループットの変化に対して伝送レートを適合させる必要がある。Ｈａｓｋｅｌｌ他による「Ｅｎｃｏｄｅｒ／Ｄｅｃｏｄｅｒ  Ｂｕｆｆｅｒ  Ｃｏｎｔｒｏｌ  ｆｏｒ  Ｖａｒｉａｂｌｅ  Ｃｈａｎｎｅｌ」という名称の米国特許第５，５６５，９２４号明細書には、このようなレート適合システムの一例が開示されている。
【０００４】
ストリーミングクライアントにおいては、再生のためにメディアデコーダに伝達する前に、到来データを保存するべく、レシーババッファリングを提供している。即ち、レシーババッファを使用することにより、ソースエンコーディングレート（これは、サンプリングレートとも呼ぶ）と伝送レート（プリデコーダバッファリング）間の差を補償しており、又、これは、チャネル上のパケット転送遅延変動を補償するためにも使用されている（ジッタバッファリング）。尚、一般には、これら２つの機能は、単一のレシーババッファ内に統合されるものと考えられているが、受信側の２つの別個のバッファにより、これらを実装することも可能である（但し、このような実装は、遅延の観点から最適なものではない）。又、レシーババッファリングによれば、整合の不正確性を補正することも可能である（即ち、システムスループットがサーバーのアウトプットと正確に整合していない場合）。
【０００５】
レシーババッファが空になると（即ち、これは、バッファアンダーフローであり、デコーダがデコードするべきデータがなくなったことを意味している）、クライアントは、再生を休止し、到来データを再バッファリングした後に、再生を再開する必要がある。一方、到来データレートが再生レートよりも高速である場合には、レシーババッファのスペースが使い果たされることになり（即ち、バッファオーバーフロー）、この結果、新しい到来データ用の空きを生成するべく、バッファからパケットが削除されることになる。パケットが削除されると、ビデオ品質が劣化する。従って、滑らかで完全な再生を確保するには、クライアントのレシーババッファを一定の充填レンジ内に維持する必要ある。そして、レシーババッファがアンダーフロー又はオーバーフローしないようにするには、サーバーにおける伝送及びサンプリングのビットレートと、クライアントにおける受信及び再生のビットレートを十分に制御しなければならないのである。
【０００６】
以下の説明においては、ビットレートの変化プロット（水平軸が時間（単位：秒）であって、垂直軸が累積データ量（単位：バイト又はビット）である）を参照し、このビットレートの制御について説明するが、このプロットには、次の曲線が定義されている。
【０００７】
・再生曲線Ｐ（ｔ）：これは、所与の時刻においてデコーダが処理したレシーババッファからの累積データ量を示している。
【０００８】
・サンプリング曲線Ｓ（ｔ）：これは、メディアエンコーダがリアルタイムで稼働した場合のデータ生成の経過を示している（これは、再生曲線に対応しており、実際には、再生曲線の時間シフトされたバージョンである）。
【０００９】
・伝送曲線Ｔ（ｔ）：これは、所与の時刻においてサーバーから送出された累積データ量を示している。
【００１０】
・受信曲線Ｒ（ｔ）：これは、所与の時刻において受信され、クライアントバッファ内に配置された累積データ量を示している。
【００１１】
任意の２つの曲線間の差は、それら２つの曲線間における遅延と「バッファサイズ」を定めている。そして、ビットレートの制御は、２つの曲線間の差に関する制限（例：最大バッファサイズや最大遅延）によって制約を受けることになる。図１には、代表的なビットレートの変化プロットが示されている。
【００１２】
ビットレートの制御においてサーバー及びクライアントが協働するための最良の構成を決定する際には、次のような点を考慮する必要がある。
【００１３】
Ａ．サンプリング曲線：この制御（即ち、伝送用のビットストリームの選択）は、完全にサーバーに任せる必要がある。この理由は、（１）それぞれのビットストリームの正確な特性（例：スイッチング位置、フレームの優先順位、及び将来のフレームサイズ）に関する知識を有しているのが、サーバーのみであること、及び（２）ネットワークのビットレートと整合するビットストリームレートが存在せず、なんらかの「トリック」（例：間引きやスイッチングアップ及びダウン）をサーバーが実行することになる可能性があるためである。
【００１４】
Ｂ．伝送曲線：この制御（即ち、伝送するレート）もサーバーに任せる必要がある（即ち、ＲＴＣＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）レポートやクライアントからのその他の帯域幅情報の使用による）。この理由は、（１）一般に、伝送路上のデータ量を計測できるのが、サーバーのみであること、及び（２）サンプリング曲線の柔軟性が限定されている場合には、伝送レートをサンプリング曲線に対して適合させる必要があるためである。
【００１５】
サーバーは、そのサンプリング曲線Ｓ（ｔ）を、その伝送曲線Ｔ（ｔ）に対して適合させることによって、リアルタイム制約を維持しなければならない。十分なバッファリングが提供されておれば、伝送曲線に対してサンプリング曲線を適合させることにより、受信側における正しく同期したメディアの再生が保証されることになる。すべての時点ｔにおいて、伝送曲線Ｔ（ｔ）からのサンプリング曲線Ｓ（ｔ）の逸脱が、一定のバイト数を超過してはならない。
【００１６】
サーバーが、リアルタイム制約によって定められている制限内において稼働している場合に、クライアントは、その制限内においてサーバーに追随するのに必要なバッファリングを提供する責任を負っている。この場合に、クライアントは、（１）｜Ｓ（ｔ）−Ｔ（ｔ）｜のプリデコーダバッファリングと、（２）転送遅延変動｛Ｔ（ｔ）−Ｒ（ｔ）｝のジッタバッファリングについて補償しなければならない。
【００１７】
又、クライアントは、再生曲線とサンプリング曲線間における不整合（例：クライアントプラットフォームのオペレーティングシステムの問題に起因するクロックドリフトや再生のスローダウン）を許容しなければならない。
【発明の開示】
【００１８】
マルチメディアストリーミングシステムにおいては、送信側（即ち、サーバー）は、それぞれの時点において、送信対象の後続のパケットをどのように（どのレートで）エンコードするかを決定し、且つ、それをいつ送信するかを決定する必要がある。通常の動作においては、送信側は、ＲＴＣＰレポートのみを使用することにより、受信側によるリアルタイム再生を維持することができる。３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）のＰＳＳ（Ｐａｃｋｅｔ  Ｓｗｉｔｃｈｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｓｅｒｖｉｃｅ）には、規範的なビデオバッファリング要件が定義されており、これは、ＶＢＲ（Ｖａｒｉａｂｌｅ  Ｂｉｔ  Ｒａｔｅ）ビデオ圧縮及び伝送に固有のエンコーディング及びサーバー固有の遅延変動の保証を目的としている（３ＧＰＰ  ＴＳ  ２６．２３４  Ｖ５．１．０、「Ｔｒａｎｓｐａｒｅｎｔ  Ｅｎｄ−ｔｏ−Ｅｎｄ  Ｐａｃｋｅｔ  Ｓｗｉｔｈｃｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｓｅｒｖｉｃｅ（ＰＳＳ）；  Ｐｒｏｔｏｃｏｌｓ  ａｎｄ  Ｃｏｄｅｃｓ（Ｒｅｌｅａｓｅ  ５）」（２００２年６月）を参照されたい。尚、以下においては、これをＴＳ  ２６．２３４と呼ぶこととする）。ストリーミングサーバーとクライアントの両方がこれらのバッファリング要件を満足しており、且つ、サーバーからのストリームが、遅延が一定であって信頼性の高い伝送チャネル上において伝送されておれば、サーバーから伝送されたストリームのクライアントによる再生が、クライアントバッファ違反なしに（即ち、クライアントにおいて、バッファのアンダーフローやオーバーフローが発生することなしに）、保証されることになる。しかしながら、ハンドオーバー、再伝送、又はクロックドリフトなどの状況においては、これは不可能である。この結果、送信側と受信側が互いに矛盾する行動を取り、ユーザーが経験する機能の深刻な劣化が発生することになるのである。
【００１９】
従来技術においては、受信側は、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）ヘッダフィールドの速度（オーディオ及び／又はビデオのサブサンプリング）及びスケール（ビットレートの乗法的増大又は減少）を使用することにより、そのバッファレベルを変更しており、これらのヘッダについては、ＩＥＴＦ  ＲＦＣ２３２６に定義されている。又、受信側は、３ＧＰＰ  ＳＡ４の文書Ｓ４−０３００２４「Ｅｎｄ−ｔｏ−Ｅｎｄ  ｂｉｔ  ｒａｔｅ  ａｄａｐｔａｔｉｏｎ  ｆｏｒ  ＰＳＳ」に記述されているクライアントによるビットレート切り換え命令を使用することも可能である。
発明の概要
【００２０】
本発明においては、送信側と受信側間におけるレート適合の責任を次のように分割している。
【００２１】
即ち、サーバーは、「受信レートに対する伝送レートの適合（即ち、輻輳制御）」と「伝送レートに対するサンプリングレートの適合（即ち、シフトの管理と、レート適合動作レンジ内におけるその維持）」の責任を担っている。
【００２２】
一方、受信側は、「パケット転送遅延変動（即ち、ネットワークジッタ）の補償」と「サーバーレート適合動作レンジ（即ち、シフトレンジ）のパラメータの設定」の責任を担っている。
【００２３】
サーバーレート適合用の動作レンジは、サーバーが送信するパケットの許容可能な最小及び最大シフトを指定することにより、「サーバーの動的なスケジューリング」の制限を定めている。そして、このサーバーレート適合動作レンジのパラメータが、ハンドオーバー、再伝送、及びクロックドリフトなどの場合におけるアンダーフロー、オーバーフロー、及び品質劣化の発生を極小化するべく、サーバーと受信側間においてネゴシエートされる。
【００２４】
従って、本発明の第１の態様は、マルチメディアストリーミングネットワークのクライアント内のレシーババッファのレベルを適応制御する方法を提供し、このストリーミングネットワークは、クライアントにストリーミングデータを提供するサーバーを有しており、レシーババッファは、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償するために使用されており、この方法は、サーバーとクライアント間におけるレート適合を実行するために、クライアントにおいて、レート適合動作レンジを決定するための少なくとも１つのパラメータを定め；この少なくとも１つのパラメータに基づいて、サーバーにおいて、受信レートに対してデータ量を適合させ；この適合に基づいて、クライアントにおいて、パケット転送遅延変動を調節すること；を有している。
【００２５】
本発明によれば、少なくとも１つのパラメータは、サーバーが最小シフト量に基づいて適合を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の差を表す最小シフト量を有している。
【００２６】
本発明によれば、少なくとも１つのパラメータは、サーバーが目標シフト量に基づいて適合を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の差を上回るシフト量を表す目標シフト量を有している。
【００２７】
本発明によれば、少なくとも１つのパラメータは、サーバーが適合段階を実行できようにするべく、送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数を有している。
【００２８】
本発明によれば、このサーバー内における適合は、伝送レート又はサンプリングレート、或いは、これらの両方を調節することによって実行される。
【００２９】
本発明によれば、少なくとも１つのパラメータは、クライアントにおける再生の中断を防止するためのクロックシフト量を有している。
【００３０】
本発明によれば、この方法は、少なくとも１つのパラメータに基づいて、サーバー内において、伝送レートに対してサンプリングレートを適合させることを更に有している。
【００３１】
本発明によれば、最小シフト量、目標シフト量、規定数、及びクロックの中の複数のものをサーバーに一緒に送信している。
【００３２】
本発明の第２の態様は、マルチメディアストリーミングシステムを提供する。このシステムは、少なくとも１つのクライアントと；このクライアントに対してストリーミングデータを提供するサーバーと；を有しており、クライアントは、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償するためのレシーババッファを具備しており、クライアントは、サーバーが、少なくとも１つのパラメータに基づいて、受信レートに対してデータ量を適合させることができるようにするべく、レート適合動作レンジを決定するための少なくとも１つのパラメータを定めるメカニズムと；この適合に基づいてパケット転送遅延変動を調節するメカニズムと；を有している。
【００３３】
本発明によれば、少なくとも１つのパラメータは、サーバーが最小シフト量に基づいて適合段階を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と；サーバーがターゲットシフト量に基づいて適合段階を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と；送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数と；クライアントにおける再生の中断を防止するためのクロックシフト量と；を含むことができる。
【００３４】
本発明によれば、サーバーは、少なくとも１つのパラメータに基づいて、伝送レートに対してサンプリングレートを適合させる適合メカニズムを有している。
【００３５】
本発明の第３の態様は、クライアント内のレシーババッファのレベルを適応制御するためのマルチメディアストリーミングネットワーク内のクライアントにおいて使用するソフトウェアプロダクトを提供し、このマルチメディアストリーミングネットワークは、ストリーミングデータをクライアントに提供する能力を有するサーバーを有しており、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、レシーババッファを使用することにより、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償しており、このソフトウェアプロダクトは、サーバーとクライアント間におけるレート適合を実行するべく、サーバー内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを定めるコードと；この適合に基づいてパケット転送遅延変動を調節するコードと；を有している。
【００３６】
本発明によれば、少なくとも１つのパラメータは、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と；サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と；送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数と；クライアントにおける再生の中断を防止するためのクロックシフト量と；を含むことができる。
【００３７】
本発明の第４の態様は、端末にストリーミングデータを提供する少なくとも１つのサーバーを具備するマルチメディアストリーミングネットワーク内の端末を提供し、この端末は、この端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量と端末によるデータ使用量間の差を補償するレシーババッファを具備している。この端末は、サーバーが、少なくとも１つのパラメータに基づいて、受信レートに対してデータ伝送量を適合させることができるようにするべく、サーバー内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを定義するメカニズムと；この適合段階に基づいてパケット転送遅延変動を調節するメカニズムと；を有している。
【００３８】
本発明によれば、定めるメカニズムは、少なくとも１つのパラメータを定める少なくとも１つのコードを具備するソフトウェアプログラムを有しており、調節メカニズムは、パケット転送遅延変動を調節する少なくとも１つのコードを具備するソフトウェアプログラムを有している。
【００３９】
本発明の第５の態様は、ネットワーク要素からストリーミングデータを受信する少なくとも１つの端末を具備するマルチメディアストリーミングネットワーク内のネットワーク要素を提供し、この端末は、この端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、ネットワーク要素によるデータ伝送量と端末によるデータ使用量間の差を補償するレシーババッファを具備している。そして、ネットワーク要素は、このネットワーク要素内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを表している要求を端末から受信する手段と；端末が、少なくとも１つのパラメータに基づいて、端末による受信レートに対してデータ伝送量を適合させて適合段階に基づいてパケット転送遅延変動を調節できるようにするメカニズムと；を有している。
【００４０】
本発明によれば、適合メカニズムは、データ伝送量を適合させる少なくとも１つのコードを具備するソフトウェアプログラムを有している。
【００４１】
本発明によれば、ソフトウェアプログラムは、伝送レート又はサンプルレート、或いは、これらの両方を調節するコードを有している。
【００４２】
本発明については、添付の図１〜図３との関連で、以下の説明を参照することにより、明らかとなろう。
発明の詳細な説明
【００４３】
サーバーが送信するパケットに許容される最小及び最大シフトを規定するべく、本発明においては、次のようなレート適合モデルを使用して「シフト」を定義している。
【００４４】
Ａ．協調レート適合モデル
ＲＰＴ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケット内のメディアのサンプリング時刻（即ち、タイムスタンプ）と、このパケットの伝送時刻（即ち、これがサーバーから送信される時点）の間の時間差αを「シフト」として定義している。即ち、サンプリング曲線（Ｓ）と伝送曲線（Ｔ）を参照すれば、αのシフトは、Ｔ（ｔ）＝Ｓ（ｔ＋α）として表すことが可能である。
【００４５】
従って、パケットサンプリング時刻がパケット伝送時刻よりも遅行している場合には、シフトは、正の値になる。一方、パケットサンプリング時刻がパケット伝送時刻よりも先行している場合には、シフトは、負の値になる。
【００４６】
このように「シフト」を定義することに伴い、最小及び最大シフトパラメータは、次のように定義される。
【００４７】
Ｂ．サーバーレート適合動作レンジのパラメータ
レート適合動作レンジのパラメータは、次のように定義される。
【００４８】
（１）最小シフト：このパラメータは、送信側が使用可能な最小シフトを定義するものである。これによれば、伝送時刻ｔにおいて送信可能な最も古い許容サンプリング時刻が与えられる。即ち、このパラメータをα＿ｍｉｎとすれば、送信側が時刻ｔにおいて送信しているパケットのサンプリング時刻は、「ｔ＋α＿ｍｉｎ」を超過して先行してはならない。
【００４９】
そのサンプリング時刻に対して、どれだけ遅行してパケットを送信可能であるかに関するこの最大限度を具備することにより、受信側においてリアルタイムの再生を維持することができる。受信側は、再生の遅延を回避するために（即ち、レシーババッファのアンダーフローが発生しないようにするために）パケットの待機状態で許容しなければならない最大時間量を推定可能である。
【００５０】
初期レシーババッファリング遅延（即ち、プリロール）の大きさは、この最小シフトを許容すると共にパケット転送遅延変動を補償するように、設定しなければならない。一例として、この最小シフトが、−２０００ｍｓであると仮定しよう。これは、送信側がパケットを送信する場合に、パケットサンプリング時刻が、その伝送時刻と比べて、最大２秒だけ先行可能であり、これを上回ってはならないことを意味している。レシーババッファアンダーフローを回避するために、受信側は、当初、最大予想パケット転送遅延変動＋２秒にわたって、バッファリングすることになろう。そして、この（負の）値が小さくなるほど、受信側における初期バッファリングの必要性が増大することになる。
【００５１】
受信側がクロックドリフト（即ち、送信側において維持されているサンプリング曲線からの受信側の再生曲線のずれ）を検出した場合には、この最小シフトパラメータを変更することにより、サーバーのパケット伝送時刻を再生曲線に追随させることができる。例えば、受信側が相対的に高速であればは、受信側は、データのサンプリング速度よりも高速のレートでデータを再生することになろう。そして、これは、最終的にバッファのアンダーフローを招くことになる。従って、その最小シフトを増大させるべく送信側に対して要求することにより、アンダーフローを回避することができる。
【００５２】
即ち、受信側が送信側よりも低速である場合には、最小シフトを減少させる必要があり、受信側が、送信側よりも高速である場合には、最小シフトを増大させる必要があるのである。
【００５３】
この最小シフトの初期値は、通常、負であるが、受信側がこれを変更し、正になるように修正することも可能である。例えば、受信側が相対的に高速になる（即ち、相対的に再生クロックが高速になる）場合に、最小シフトは、その増大に伴って、正になることもあり得る。例えば、初期値が−２秒であるとすれば、送信側は、このシフトを、−１．９秒、次いで、−１．７秒などとするように後から要求することが可能である。
【００５４】
（２）目標シフト：このパラメータは、送信側が実現することをクライアントが所望しているシフトを定義するものである。このパラメータをα＿ｔａｒｇｅｔとすると、送信側が時刻ｔにおいて送信しているパケットのサンプリング時刻は、ｔ＋α＿ｔａｒｇｅｔである必要がある。
【００５５】
この目標シフトは、先程定義した最小シフトよりも常に大きくなければならない。送信側がこの目標シフトに従ってパケットを送信している場合には、当然のことながら、その定義により、送信側は、その最小シフトをも満足している。
【００５６】
この目標シフトは、リアルタイムデッドライン（即ち、最小シフト）を満足させた状態で伝送レートを突然減少させなければならない場合に（例：ハンドオーバーの際）、サンプリングレートを減少させる必要性を低減することを意図するものである。換言すれば、この目標シフトは、伝送レートが十分に良好である場合に、リアルタイムを満足させるのに厳密に必要とされるものよりも先行してパケットを送信側に送信させることを意図するものである。
【００５７】
この第２パラメータについて更に詳しく説明するべく、送信側が最小シフトの近傍において動作していると仮定しよう。そして、伝送レートが大幅に減少すると仮定しよう（この原因は、ハンドオーバーやＲＴＰ再伝送などであり、この場合には、オリジナルのストリームに提供されているビットレートが減少することになる）。この場合には、最小シフト（並びに、従って、リアルタイム）を保証するべく、送信側も、そのサンプリングレートを急激に減少させなければならないであろう。そして、この結果、送信側が、例えば、サンプリングレートの減少を実現するべくフレームのスキップを余儀なくされることに伴い、品質が低下することになる。
【００５８】
一方、サーバーが目標シフトの近傍において動作している場合には、伝送レートが減少した場合のサンプリングレートの減少は、伝送レートの減少ほどに急激なものにする必要はない。即ち、サンプリングレートの低下を伴うことなしに伝送レートを低下させる送信側の実際のシフトは、目標シフト未満に減少することになるが、この場合にも、伝送レートにおいて観察される減少ほどには劇的にサンプリングレートを減少させることなしに、最小シフトを維持することが可能である。
【００５９】
そのシフトの減少を余儀なくされた後に、伝送レートが再度増大すると、サーバーは、その目標シフトを再構築する必要がある。受信側から通知された目標シフトを実現するべく、送信側は、現在の伝送レートの制約に応じて、伝送レートの増大とサンプリングレートの減少（又は、伝送レートの減少とサンプリングレートの増大）の組み合わせを使用可能である。
【００６０】
このように定義された目標シフトを具備することにより、大きな伝送レートの減少に対応する際に、受信側が、サーバーに対して、まず、シフトを減少させ、次いで、再度、これを増大させて元に戻すように「命令」する必要がなくなる。即ち、以前に受信側から通知されている目標シフトから、シフトを減少させ、次いで、再度、そのシフトを増大させて目標シフトに戻すことを送信側自身が決定することになるのである。
【００６１】
このため、この方式をプロアクティブであると表現可能であり、伝送レートの減少の際に（シフトの）シグナリングを実行する必要はない。
【００６２】
（３）先行送信バイトの最大数：このパラメータは、時刻ｔにおいて送信済みのバイト数とサンプリング時刻ｔまでにサンプリング済みのバイト数間の最大の差を定義するものである（即ち、伝送曲線とサンプリング曲線の差：Ｔ（ｔ）−Ｓ（ｔ）である）。このパラメータは、正のシフトの結果として受信された（従って、受信側がその再生時間まで待たなければならない）パケットの保持に必要な受信側のバッファサイズを制限している。このパラメータの目的は、バッファのオーバーフローを防止することにある。
【００６３】
図１には、これらのパラメータが、伝送曲線Ｔ（ｔ）とサンプリング曲線Ｓ（ｔ）の例と共に示されている。
【００６４】
Ｃ．レート適合動作レンジのパラメータに対するサーバーの準拠要件
サーバーは、「最小シフト」及び「先行送信バイトの最大数」パラメータを厳格に遵守しなければならない。従って、サーバーは、正常な伝送条件下においては、その能力と提供されているメディアエンコーディングが許容する範囲内において、「目標シフト」に近接した状態で動作するべく試みることになる。
【００６５】
しかしながら、時間に伴って発生し得るメディアエンコーディングレートの変動のために、サーバーは、すべての送信パケットについて、「目標シフト」に正確に追随することはできない。従って、「目標シフト」に対して厳格に追随すると、不必要な品質の劣化が発生することになるとサーバーが判断する伝送条件下においては、この「目標シフト」からのずれは、サーバーの裁量によって許容されることになる（後述する使用例を参照されたい）。又、このずれの後に、「目標シフト」がどれだけ迅速に回復されるかについても、サーバーの決定／能力に任されている。
【００６６】
尚、「目標シフト」パラメータと「先行送信バイトの最大数」パラメータが矛盾している場合には（即ち、目標シフトを維持した結果、先行送信バイトの最大数を超過することになる場合には）、常に後者が優先する。
【００６７】
Ｄ．サーバーとクライアント間における責任分割の説明
中断のない再生にとって重要なのは、レシーババッファレベルの効果的な管理である。これは、クライアントにおいて、再生曲線と受信曲線の両方に対する少なくとも間接的な又は推定による制御を具備することによって実現することができる。クライアントは、その定義により、デコーディング／再生タイムラインに関する知識を有しており、これらを制御している。送信側がシフト制御を導入できるようにすることにより、クライアントに対して、受信曲線と、サンプリング曲線に対するその関係の少なくとも推定による制御機能が付与され、従って、レシーババッファレベルの制御機能が付与されることになる。
【００６８】
従って、クライアントは、その絶対的なバッファリング制限を考慮してシフトパラメータを選択し、これを要求する。そして、この協調レート適合モデルにおいて受信側が要求するのは、このシフトパラメータのみであり、この要求に対する応答において、そのエンコーディングレート及び／又は伝送レートをどのように適合させるかは、送信側に任されている。伝送曲線又はサンプリング曲線のいずれか、或いは、これらの両方を適合可能である。
【００６９】
従って、サンプリングレートの制御（即ち、伝送用のビットストリームの選択）は、サーバーの制御下に残されており、この理由は、それぞれのビットストリームの正確な特性（例：スイッチング位置、フレームの優先順位、将来のフレームサイズ）に関する知識を有しているのは、サーバーのみであることと、ネットワークのビットレートに整合するビットストリームレートが存在せず、従って、ネットワークのビットレートにビットストリームのレートをフィットさせるべく、なんらかの「トリック」（例：間引きやスイッチングアップ及びダウン）をサーバーが実行することになる可能性があるためである。
【００７０】
そして、伝送レートの制御（即ち、伝送するレート）も、サーバーの制御下に残されており（即ち、これには、ＲＴＣＰ  ＲＲ  レポートを使用する）、この理由は、一般に、伝送路上のデータ量を計測できるのは、サーバーのみであることと、サンプリングレート制御の柔軟性が限定されている場合には、サンプリングレートに伝送レートを結び付けることが必要になるためである。
【００７１】
送信側が適合を実行するべく試みる場合には、次の項目によって制限されることになる。
【００７２】
・伝送曲線の変更：伝送曲線は、受信曲線によって制約されており、従って、送信側は、伝送曲線を増大させることができない場合がある。送信側が伝送曲線を増大させることができるのは、送信側が、以前に、その提供されている帯域幅のすべてを使用していなかった場合のみである。例えば、サーバーは、ＴＦＲＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  Ｆｒｉｅｎｄｌｙ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ）メカニズムを使用して（又は、受信側からのシグナリングを介して直接的に帯域幅情報を受信して）その利用可能な伝送レートを算出可能であり、ＴＦＲＣ（又は、実際の通知された帯域幅）が許容するレートを超過して、そのレートを増大させることはない。
【００７３】
サンプリング曲線の変更：これは、送信側のレート適合能力によって左右される。例えば、送信側がビットストリームスイッチングを実装しており、且つ、送信側が、その最低の（又は、最高の）ビットストリームにおいて伝送している場合には、送信側は、サンプリングレートを更に減少（又は、減少）させることはできないであろう。
【００７４】
Ｅ．ユースケース
本発明によれば、ハンドオーバー、再伝送、及びクロックドリフトなどの場合におけるアンダーフロー、オーバーフロー、及び品質劣化の発生を極小化するべく、サーバーと受信側の間において、サーバーレート適合動作レンジのパラメータをネゴシエートしている。
【００７５】
ＲＴＰパケット伝送の場合においては、受信側は、実行を所望するパケット再伝送の数と、再伝送において許容する遅延を選択することができる。
【００７６】
ハンドオーバーの場合には、受信側は、無線ネットワークタイプから、例えば、予想されるハンドオーバーの長さと、従って、必要な目標シフトを導出可能である。受信側は、無線リンクに関して相対的に良好な知識を有していると共に、システム間ハンドオーバーと、これに相応してクロックシフトパラメータを適合させる必要性を検出可能である。
【００７７】
従って、受信側は、クロックシフトパラメータを更新することにより、送信側によるクロックドリフトを補償することができる。
【００７８】
ＲＴＰ再伝送
再伝送の要求を行う前に、受信側は、通常、再伝送対象のパケットが、その再生時間に間に合うかどうかを推定する必要がある。即ち、そのパケットが間に合わない場合には、その再伝送により、利用可能な帯域幅が浪費されることになるからである。
【００７９】
送信側は、受信側におけるリアルタイム制約を満足するために少なくともシフトα＿ｍｉｎによるスケジューリングを要するパケットのサンプリング時刻に関する知識を有している。
【００８０】
この観点において、再伝送パケットは、最初に送信されたパケットと異なるところはない。但し、受信側におけるアンダーフローの閾値を最小シフトが示しているため、送信側は、タイプスタンプがｔ＋α＿ｍｉｎ（ここで、ｔは、現在の時間である）を下回っている場合には、そのパケットを再伝送するべきではない。
【００８１】
従って、シフトパラメータのシグナリングによれば、受信側におけるデコーディング時間に間に合わず、利用可能な帯域幅がその再伝送によって浪費されることになるパケットを送信側が再伝送しないようにすることにより、パケット再伝送の効率を向上させることができる。又、受信側は、消失パケットを再生の前に受信可能かどうかに関する推定において、過度に慎重になる必要はない。これは、サーバーがそのパケットを再伝送しないため、誤った推定が（その無駄な要求自身を除いて）影響を及ぼさないからである。
【００８２】
又、受信側は、目標シフトを介して、実行を所望する再伝送の数をトレードオフすることも可能である。即ち、目標シフトの値が大きいほど、ネットワーク状態を良好に保ちつつ、相対的に多くのパケットが先行送信されることになる（且つ、レシーババッファレベルも高くなる）。そして、この結果、ネットワーク状態が悪化した場合に、相対的に多くの時間が再伝送に対して付与されることになるからである。
【００８３】
この場合にも、クロックシフトは、プロアクティブであり、受信側は、シフト要求をＲＴＣＰ要求と同期させる必要はない。
【００８４】
ハンドオーバー
クロックシフトのシグナリングは、ハンドオーバーに起因する受信側における再生の中断を防止するツールとして使用可能である。
【００８５】
受信側が、ネットワークに接続されており、且つ、そのネットワークの予想ハンドオーバー長がＴHであるという知識を有していると仮定しよう。又、この受信側が、最小シフトよりも少なくともＴHだけ大きくなるように（即ち、α＿ｔａｒｇｅｔ＞α＿ｍｉｎ＋ＴH）、その目標シフトを設定していると仮定しよう。
【００８６】
ハンドオーバーの前に、送信側は、パケットを先行送信することにより、目標シフトを満足させる。そして、ハンドオーバーを検出した場合には、送信側は、伝送を停止する必要がある（そして、これにより、ネットワークバッファのオーバーフローに起因するパケットの消失を回避する必要がある）。そして、このハンドオーバーの最中には、新しいデータが送信されない状態で、クロックが動作する。この結果、（ハンドオーバーが正確にＴHだけ継続したと仮定すれば）、このハンドオーバーにより、シフトは、時間量ＴHだけ減少することになる。そして、送信側は、ハンドオーバーの以前には、目標シフトで稼働していたため、ハンドオーバー後のシフトは、α＿ｔａｒｇｅｔ−ＴHとなる。
【００８７】
この値は、依然として、最小シフトα＿ｍｉｎを上回っている。そして、これは、リアルタイム性が依然として満足されており、受信側において、アンダーフローが発生しなかったことを意味している。従って、受信側は、目標シフトに従って送信側から送信されたパケットを、ハンドオーバーの最中においても、大幅な品質の劣化を伴うことなしに再生可能である。
【００８８】
そして、ハンドオーバーの後に、送信側は、その伝送レートの再度の増大に伴い、目標シフトを再構築することになる。従って、新しいシグナリングは不要である。
【００８９】
受信側が新しいシフトパラメータを通知するのは、許容可能なハンドオーバーの長さを更に増大させるべく、その目標シフトの拡大を所望する場合のみとなろう。具体的には、これには、異なる予想ハンドオーバー長を有する異なるタイプのネットワークに対するハンドオーバーが存在している場合が該当しよう。
【００９０】
当然のことながら、送信側は、ハンドオーバーを検出できる必要がある。送信側は、通常、いくつかのＲＴＣＰインターバルにわたってＲＴＣＰパケットを受信しない場合に、ハンドオーバーを検出することになる。送信側が可能な限り早期にハンドオーバーを検出できるように、受信側は、ＡＶＰＦが提供されている場合には、早期のフィードバックパケットを送信する必要がある。尚、ＡＶＰＦとは、ＲＴＣＰに基づいたフィードバックのための拡張プロファイルである。
【００９１】
受信側がＲＴＳＰによってパラメータを送信している場合には、受信側は、ハンドオーバーの後に、（同一のパラメータ又は更新済みの値と共に）新しい要求を送信することができよう。これは、高速のＲＴＣＰフィードバックが利用不能な場合に、ハンドオーバーが終了したことを送信側が迅速に検出するのに有用である。
【００９２】
図２には、ハンドオーバーと、バッファレベルに対するその影響が示されている。この例においては、ハンドオーバーの最中にバッファレベルが減少しているが、アンダーフローは発生していない。ハンドオーバーの後に、送信側は、初期の目標α＿ｔａｒｇｅｔを独自に再構築することになるが、ハンドオーバーの最中にバッファがほとんど空になっているため、ハンドオーバーの終了後に、受信側が相対的に大きな目標値を通知するべく選択する場合もあろう。この理由は、最初のハンドオーバーが、受信側が当初予想していたものを上回っており、将来、相対的に大きなハンドオーバーをサポートできるようになることを所望するためである。図には、この新しい目標のシグナリングと、曲線に対するその影響が示されている。
【００９３】
（クロックドリフト）
送信側と受信側の間におけるクロックドリフトやその他の理由（例：低速のクライアントプラットフォームオペレーティングシステム）のために、受信側にとって、送信側が過剰に低速に、又は過剰に高速に見える場合がある。新しいシフトパラメータを送信することにより、このようなドリフトを補正可能である。
【００９４】
例えば、受信側が低速である場合には、受信側は、最小シフト値の減少を定期的に要求可能であろう。
【００９５】
Ｆ．メッセージのフォーマットとトランスポート
新しいＲＴＳＰヘッダは、「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」と定義することができる。このヘッダは、クライアントが要求するシフトパラメータを通知するためのクライアント要求内において使用可能である。
【００９６】
その要求がセッションレベルのＲＴＳＰ  ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）に適用される場合には、そのシフトも、セッション内のすべてのメディアに適用される必要がある。一方、その要求がメディアレベルのＲＴＳＰ  ＵＲＬに適用される場合には、そのシフトも、そのメディアにのみに適用される必要がある。又、送信側は、この「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」を、その応答においても使用する。そして、これらのパラメータは、クライアントが要求したパラメータであってよいが、送信側が返すことができるのは、（送信側の能力の制限に起因し）要求されたパラメータに可能な限り近接したパラメータのみである。
【００９７】
この新しいヘッダは、あらゆるＲＴＳＰのメソッドによって送信可能である。
【００９８】
このＲＴＰヘッダのＡＢＮＦは、次のとおりである。
【００９９】
３ｇｐｐｓｈｉｆｔｐａｒａｍｅｔｅｒｓ  ＝  “３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ”  “：”
ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ  ＊（“；”  ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ）  ＣＲＬＦ
ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ  ＝  ａｌｐｈａ−ｍｉｎ  ／  ａｌｐｈａ−ｔａｒｇｅｔ  ／  ｍａｘ−ｓｉｚｅ
ａｌｐｈａ−ｍｉｎ  ＝  “ａｌｐｈａ＿ｍｉｎ”  “＝”  “＋”  ／  “−”  １＊ＤＩＧＩＴ  ；  ｍｓ
ａｌｐｈａ−ｔａｒｇｅｔ  ＝  “ａｌｐｈａ＿ｔａｒｇｅｔ”  “＝”  “＋”  ／  “−”  １＊ＤＩＧＩＴ  ；  ｍｓ
ｍａｘ−ｓｉｚｅ  ＝  “ｍａｘ＿ｓｉｚｅ”  “＝”  １＊ＤＩＧＩＴ；  ｂｙｔｅｓ
【０１００】
最初に、クライアントは、すべてのパラメータを送信する。そして、後続の要求において、クライアントは、変更を要求する１つ又は複数のパラメータのみを送信可能である。
【０１０１】
その変更が許容可能であり、且つ、受信側が要求したようにすべてのパラメータが設定済みである場合には、サーバーは、ヘッダを送信する必要はない。
【０１０２】
又、以前の要求が完了する前に、サーバーが新しい要求を受信した場合には、サーバーは、最新の要求に応えなければならない。
【０１０３】
又、送信側は、送信側が使用を所望するパラメータをセッションの開始時点において受信側に通知することも可能である。受信側は、これらのパラメータを考慮し、要求するパラメータの値を選択することになる。
【０１０４】
尚、パラメータを通知する好適な方法は、ＲＴＳＰによるものであるが、ＲＴＣＰなどの信頼性の低いトランスポートプロトコルを使用することも可能であろう。
【０１０５】
図３は、本発明によるストリーミングネットワークにおけるマルチメディアシステム１を示すブロックダイアグラムであり、このシステムには、ネットワーク要素又はストリーミングサーバー１０用のレート適合動作レンジを決定するパラメータを通知する手段が提供されており、このパラメータは、端末又はストリーミングクライアント６０とストリーミングサーバー１０の間においてネゴシエートされる。
【０１０６】
ストリーミングサーバー１０は、アプリケーションレベルシグナリングエンジン２０、レートコントローラ３０、及びサーバーバッファ４０を有している。一方、ストリーミングクライアント６０も、ストリーミングサーバー１０内のアプリケーションレベルシグナリングエンジン２０に対応し、且つ、これと通信するべく適合されたアプリケーションレベルシグナリングエンジン７０を有している。そして、これは、クライアントバッファ８０を更に有しており、このクライアントバッファは、この図３に示されている本発明の実施例においては、単一のユニットとして統合されたジッタバッファ８２とプリデコーディングバッファ８４を有している。尚、本発明のその他の実施例においては、ストリーミングクライアント６０は、別個に実装されたジッタバッファ及びプリデコーディングバッファを含むことができる。又、このストリーミングクライアントは、メディアデコーダ９０、ポストデコーダバッファ１００、バッファコントローラ１１０、及びディスプレイ／再生装置１２０を更に有している。
【０１０７】
又、この図３に示されているシステムは、更に、ストリーミングサーバーとストリーミングクライアント６０間に位置した「チャネルバッファ」を有するように示されており、このチャネルバッファは、ストリーミングサーバーからクライアントへのデータパケットの伝送において発生する転送遅延の変動を表している。
【０１０８】
ストリーミングクライアント６０においては、伝送チャネルからメディアデータを受信し、これをクライアントバッファ８０内においてバッファリングする。バッファコントローラ１１０が、プリデコーダバッファ８４とジッタバッファ８２のパラメータを設定している。これらのパラメータは、サーバー推奨プリデコーダバッファリングパラメータと、クライアントが推定した必要な追加バッファリングの集合体として選択される。クライアントにおいては、提供されている伝送チャネルにおいて予想されるパケット転送遅延の変動（即ち、ジッタ）を許容するために必要なものを推定している。この集合体は、クライアントの最大バッファリング能力の制約を受けることになる。そして、メディアデコーダ９０が、クライアントバッファからメディアデータを抽出し、対象のメディアタイプに適した方式でメディアデータをデコードする。尚、このメディアデータは、一般に、いくつかの異なるタイプのメディアタイプを有することになることを理解されたい。例えば、サーバーから伝送されたメディアデータがビデオシーケンスを表している場合には、そのメディアデータは、ビデオデータ以外に、少なくとも１つのオーディオ成分を有する可能性が高い。従って、図３に示されているメディアデコーダ９０は、実際には、例えば、特定のビデオコーディング規格に従って実装されたビデオデコーダと、その関連するオーディオデコーダなどの複数のデコーダを有する可能性があることを理解されたい。メディアデータは、メディアデコーダ９０によるデコードが完了すると、ポストデコーダバッファ１００に出力され、ここで、そのスケジューリングされている再生時刻まで一時保存された後に、再生時刻になると、バッファコントローラ１１０の制御下において、ポストデコーダバッファからディスプレイ／再生装置１２０に伝達されることになる。
【０１０９】
本発明によれば、バッファコントローラ１１０は、アプリケーションレベルシグナリングエンジン７０に対して、最小シフト、ターゲットシフト、及び先行送信バイトの最大数に関する通知を提供する。これらのパラメータは、例えば、クライアントのバッファリング制限やデコーディング／再生タイムラインなどに基づいて、ソフトウェアプログラム１１６によって決定される。そして、アプリケーションレベルシグナリングエンジンが、これらの動作レンジレート適合パラメータを表す信号３００をストリーミングサーバー１０に伝送するべく適合されている。これらのパラメータは、例えば、ＲＳＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）を使用することにより、クライアントからサーバーに伝送される。このＲＳＰＴヘッダは、例えば、「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」として定義可能である。
【０１１０】
サーバーサイトにおいては、サーバーのレートコントローラ３０が、シフトを管理し、これをレート適合レンジ内に維持しつつ、伝送レートを受信レートに対して適合させ、且つ、サンプリングレートを伝送レートに対して適合させるべく動作可能である。又、サーバーは、クライアントに伝送されるパケットにタイムスタンプを付与するための伝送クロック３２をも具備している。サーバーは、ソフトウェアプログラム３６を使用して、クライアントが推奨したパラメータに従って伝送データレートを調節し、クライアントの推奨シフトパラメータを考慮して伝送チャネル上におけるビットレートを変更することによって動作し、これにより、プリデコーダバッファのアンダーフローに起因するクライアントにおける再生の休止や、バッファオーバーフローに起因するクライアントにおけるパケットの消失を回避するべく試みる。
【０１１１】
サーバーバッファ４０は、伝送チャネルを介してストリーミングサーバーからストリーミングクライアント６０に伝送する前に、データパケットを一時的に保存する。データパケットをリアルタイムでサンプリングする「ライブ」ストリーミングの環境においては、サーバーバッファは、実際には、サンプリング時間においてデータパケットが配置され、伝送時間において抽出される物理バッファである。一方、データパケットを、リアルタイムサンプリングすることなしに、プリエンコーディングされたファイル内に保存しておき、伝送時間にファイルから読み取る「プリエンコーディング」ストリーミングの環境においては、サーバーバッファは、データパケットのサンプリング時刻（これは、プリエンコーディングされたファイルの最初のデータパケットが伝送される際にストリーミングサーバーにおいて起動するサンプリングクロックに関係するものである）と伝送時刻の間の差を表す仮想バッファである。
【０１１２】
又、サーバーは、アプリケーションレベルシグナリングエンジン２０を使用し、セッションの開始時点において、受信側に対して、サーバーが使用を所望するパラメータを表す信号３００を送信することも可能である。この場合には、受信側は、この信号３００が示しているパラメータを考慮し、サーバーレート適合動作レンジのパラメータを選択することになる。そして、サーバーは、その能力に基づいて、この信号３００を使用してクライアントの要求に応答し、サーバーがレート適合に使用可能なパラメータを返すことができる。
【０１１３】
（本発明の利点）
従来技術による方法（ＲＴＳＰヘッダ及びビットレートスイッチング）は、多数の制限を具備している。これらの制限の中の１つが、ＲＴＳＰ  ＰＬＡＹ要求内においてしか、ＳＰＥＥＤヘッダを送信できないという点である。
【０１１４】
・ＰＬＡＹは、バッファ制御のための操作ではなく、むしろ、クライアントからのユーザー要求をサーバーに対して説明することを意図したものであった。
【０１１５】
・Ｒａｎｇｅを有する新しいＰＬＡＹ要求に対する応答とサーバーが要求を取得する時点における実際の再生位置が同期することを期待することはできない（即ち、データのスキップ又は再送が発生する可能性がある）。
【０１１６】
・提供されているビットレートに対して伝送レートを適合される必要があるため、しばしば、ＲＴＳＰ  ＳＰＥＥＤを通じたクライアントの要求どおりに伝送レートを変更することが、まったく不可能である。
【０１１７】
これは、ビットレートドメインにおいて稼働しており、受信側は、このビットレートドメインを時間ドメイン（即ち、受信側が所与の量のデータを再生するのに所要する時間量）に直接的にマッピングすることはできない。この理由は、サンプリング曲線が、通常、直線でないことによるものである。
【０１１８】
・ＮＷビットレートに整合したビットストリームレートが存在しない可能性がある。
【０１１９】
・レシーババッファレベルの減少／増大の中のどの程度の割合が、所与のビットストリーム内のビットレートの変動又はビットストリーム平均レートと伝送レート間の差の蓄積に起因しているのかに関する知識をクライアントが有していない。
【０１２０】
・サーバー及びクライアントのタスクが分離されていないため、送信側と受信側におけるサンプリング曲線の成形判定の間に、矛盾が発生する。これは、送信側及び受信側の責任が明瞭に分離されており、受信側は、曲線に対する制約を変更するのみであり、送信側が、それらの制約を満足させるべく曲線の実際の成形を実行するクロックシフトシグナリングとは対照的である。
【０１２１】
一方、本発明は、次のような利点を具備している。
【０１２２】
・この方式は、プロアクティブに動作するようになっている。この概念は、クライアントが、厳密な動作ポイントではなく、動作レンジを要求する一方で、サーバーが、相対的に制限の少ない柔軟な方式でレート制御を実行できるようにしようというものである。
【０１２３】
・この結果、要求サーバーレート適合動作レンジが、明瞭にはっきりと定義され、準拠サーバーの実装が簡単になっている。
【０１２４】
・この方式のシグナリングオーバーヘッドは、クライアントからサーバーへのシグナリングに必要な周波数及び速度（即ち、ＲＴＰに同期したもの）を低減することにより、減少している。
【０１２５】
・ＲＴＳＰシグナリングを使用することにより、クライアントからサーバーへのレート適合動作レンジ要求メッセージの搬送の信頼性と正しいパイプライン化を実現することができる。これは、シグナリングの速度と周波数に関する要件の緩和と整合している（即ち、もはや矛盾していない）。
【０１２６】
要すれば、本発明は、マルチメディアストリーミングネットワークの端末又はクライアント内のレシーババッファのレベルを適応制御する方法及びシステムを提供している。このマルチメディアストリーミングネットワークは、ストリーミングデータをクライアントに提供するネットワーク要素又はサーバーを具備している。このサーバーは、伝送レートの受信レートに対する適合（即ち、輻輳管理）と、サンプリングレートの伝送レートに対する適合の責任を担っている。従って、サーバーは、シフトを管理し、これをレート適合動作レンジ内に維持する。一方、クライアントは、パケット転送遅延変動（これは、ネットワークジッタとも呼ばれる）を補償する責任を担っている。又、クライアントは、サーバーレート適合動作レンジのパラメータを設定する責任をも担っている。クライアントは、シフトパラメータを選択してサーバーに送信するが、これらのパラメータに応答したそのエンコーディングレート又は伝送レートの適合は、サーバーに任されている。
【０１２７】
以上、１つ又は複数の実施例との関連で、本発明について説明したが、当業者であれば、本発明の範囲を逸脱することなしに、その形態及び詳細において、以上の及び様々なその他の変更、省略、及び逸脱を実行可能であることを理解するであろう。
【図面の簡単な説明】
【０１２８】
【図１】サンプリング曲線及び伝送曲線に関するパラメータを定義したプロットである。
【図２】ハンドオーバーと、特定のシフトパラメータにおけるレシーババッファレベルに対するその影響を示すプロットである。
【図３】本発明によるレート適合方法を実行可能なサーバー装置とクライアント装置を具備したマルチメディアストリーミングシステムを示すブロック図である。
【図１】
2006524452.tif 000003
【図２】
2006524452.tif 000004
【図３】
2006524452.tif 000005
【国際調査報告】
2006524452.tif 000006
2006524452.tif 000007