(57)【要約】  ストリーミングメディアサーバのためのプロキシ駆動型コンテンツレート選択の方法が提供される。一方法では、クライアントからの受信者レポートメッセージに応答して、ネットワークコントローラからの１つまたは複数の最大伝送レートパラメータが、プロキシサーバに格納される。格納された最大伝送レートパラメータに基づいてメディアセッションの目標レートが生成され、その目標レートが、プロキシからサーバへのフィードバックメッセージにおいてメディアサーバに伝送される。メディアサーバは、プロキシサーバからの、プロキシからサーバへのフィードバックメッセージに応答して、複数のサポートされたコンテンツレートの中からコンテンツレートを選択して、ストリーミングマルチメディアフレームを、選択されたコンテンツレートでクライアントにストリーミングする。
2010537556.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内のクライアントのためのメディアセッションのコンテンツレートを動的に設定する方法であって、
クライアントからの受信者レポートメッセージに応答して、ネットワークコントローラから受信した１つまたは複数の最大伝送レートパラメータを、プロキシサーバに格納するステップと、
格納された最大伝送レートパラメータに基づいてメディアセッションの目標レートを生成するステップと、
メディアセッションのコンテンツレートを動的に設定するために、目標レートをメディアサーバに伝送するステップとを含む、方法。
【請求項２】
プロキシサーバで、クライアントから第１受信者レポートメッセージを受信するステップと、
受信した第１受信者レポートメッセージに応答して、フィードバックカウンタ値を初期化するステップとをさらに含む、請求項１に記載の方法。
【請求項３】
ネットワークコントローラから最大伝送レートパラメータを受信するステップと、
最大伝送レートパラメータを、１つまたは複数の最大伝送レートパラメータのうちの１つとして格納するステップと、
フィードバックカウンタ値を増分するステップと、
増分されたフィードバックカウンタ値をカウンタしきい値と比較するステップとをさらに含む、請求項２に記載の方法。
【請求項４】
カウンタ値がカウンタしきい値以上である場合、生成するステップが、格納された１つまたは複数の最大伝送レートパラメータに基づいてメディアセッションの目標レートを生成する、請求項３に記載の方法。
【請求項５】
受信者レポートメッセージをメディアサーバに転送するステップをさらに含む、請求項１に記載の方法。
【請求項６】
ネットワーク内のクライアントのためのメディアセッションのコンテンツレートを動的に設定する方法であって、
メディアサーバにおいて、プロキシサーバからの、第１のプロキシからサーバへのフィードバックメッセージに応答して、複数のサポートされたコンテンツレートの中から１つのコンテンツレートを選択するステップであって、選択されたコンテンツレートが、プロキシサーバからの、第１のプロキシからサーバへのフィードバックメッセージ内に含まれる第１目標レートから得た第１目標レートパラメータ以下であるステップと、
メディアサーバからクライアントに、選択されたコンテンツレートでマルチメディアフレームをストリーミングするステップとを含む、方法。
【請求項７】
第１目標レートおよび攻撃ファクタに基づいて、第１目標レートパラメータを計算するステップをさらに含む、請求項６に記載の方法。
【請求項８】
第１目標レートパラメータが、以下の式：
（１＋β）＊ＲＴ
に従って計算され、
ＲＴが第１目標レートであり、βが攻撃ファクタである、請求項７に記載の方法。
【請求項９】
プロキシサーバから、第２のプロキシからサーバへのフィードバックメッセージを受信するステップと、
第２のプロキシからサーバへのフィードバックメッセージ内に含まれる第２目標レート、およびカウンタ値に基づいて、メディアセッションのコンテンツレートをアップデートするかどうかを決定するステップと、
決定するステップに基づいて、メディアセッションのコンテンツレートを選択的にアップデートするステップとをさらに含む、請求項６に記載の方法。
【請求項１０】
決定するステップが、
第２目標レートに基づいて第２目標レートパラメータを生成するステップと、
第２目標レートパラメータに基づいてアップデートされたコンテンツレートを識別するステップとをさらに含み、
アップデートされたコンテンツレートが選択されたコンテンツレートと異なり、カウンタ値が第１しきい値を上回る場合、選択的にアップデートするステップがメディアセッションのコンテンツレートをアップデートする、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この通常特許出願は、米国特許法第１１９条（ｅ）に基づき、２００７年８月２４日に出願された、Ｋｒｉｓｈｎａ  Ｂａｌａｃｈａｎｄｒａｎ、Ｄｏｒｕ  Ｃａｌｉｎ、Ｅｕｎｙｏｕｎｇ  Ｋｉｍ、およびＫｉｒａｎ  Ｒｅｇｅの仮特許出願第６０／９６６，０２０号（整理番号Ｂａｌａｃｈａｎｄｒａｎ  ５２−１４−６−４５）、ならびに、２００７年８月２４日に出願された、Ｋｒｉｓｈｎａ  Ｂａｌａｃｈａｎｄｒａｎ、Ｄｏｒｕ  Ｃａｌｉｎ、Ｅｕｎｙｏｕｎｇ  Ｋｉｍ、およびＫｉｒａｎ  Ｒｅｇｅの仮特許出願第６０／９６６，０１７号（整理番号Ｂａｌａｃｈａｎｄｒａｎ  ５３−１５−７−４６）の優先権を主張するものである。これらのそれぞれの出願のすべての内容を、参照により本明細書に組み込む。
【０００２】
この通常特許出願は、２００７年２月１４日に出願された、Ｋｒｉｓｈｎａ  Ｂａｌａｃｈａｎｄｒａｎ、Ｄｏｒｕ  Ｃａｌｉｎ、Ｅｕｎｙｏｕｎｇ  Ｋｉｍ、およびＫｉｒａｎ  Ｒｅｇｅの米国特許出願第１１／６７４，８０２号（整理番号Ｂａｌａｃｈａｎｄｒａｎ  ４５−１１−３−３６）、ならびに、２００７年２月１４日に出願された、Ｋｒｉｓｈｎａ  Ｂａｌａｃｈａｎｄｒａｎ、Ｄｏｒｕ  Ｃａｌｉｎ、Ｅｕｎｙｏｕｎｇ  Ｋｉｍ、およびＫｉｒａｎ  Ｒｅｇｅの米国特許出願第１１／６７４，８５８号（整理番号Ｂａｌａｃｈａｎｄｒａｎ  ４８−１３−５−４３）に関し、これらのそれぞれの出願のすべての内容も参照により本明細書に組み込む。
【背景技術】
【０００３】
無線通信ネットワークを介するストリーミングメディアサービス（たとえば、音楽、ビデオなど）は、過去数年にわたり普及してきており、近い将来、無線サービスプロバイダにとって商業上重要になる可能性が高い。ストリーミングメディアサービスの成功の主な障害は、そのサービスに伴う品質がしばしば低い、および／または信頼できないことである。一例を挙げると、この信頼性の欠如は、メディアストリームを搬送するパケットが移動ユニットに配信されるレートの著しい変動に起因する。これらの変動は、信号強度の変動、および、複数の移動ユニット間で無線アクセスメディアを共有する必要性が原因である。
【０００４】
他の例を挙げると、パケットが移動ユニットに配信されるレートの変動は、メディアサーバと移動ユニットとの間のパス上の無線リンクをパケットが通過するときの、パケットの遅延および／または損失に起因する。従来、損失パケット、遅延パケット、および／またはジッタは、受信したデータストリームを移動ユニットでバッファリングすることによって減少される。しかし、許容できるメディア品質を保証するためには、バッファリングだけでは不十分である。
【０００５】
図１は、無線ネットワークを介してメディアを移動ユニットすなわちクライアントにストリーミングするための、従来のシステムを概念的に示している。
【０００６】
図１を参照すると、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２０とメディアサーバ１１５との間の無線ネットワーク１００の一部は、コアネットワーク１０５と呼ばれている。ＧＧＳＮ１２０と移動クライアント１１０との間のネットワーク部分（ＧＧＳＮ１２０、および移動クライアント１１０を含む）は無線アクセスネットワーク１２５と呼ばれる。
【０００７】
従来、移動ユニット、すなわちクライアント１１０（以下、クライアントと呼ぶ）が、無線ネットワーク１００を介してメディアサーバ１１５とのストリーミングマルチメディア（またはメディア）セッションを開始する。一例を挙げると、クライアント１１０は、リアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージをメディアサーバ１１５に送信することによって、ストリーミングビデオセッションを要求する。移動クライアント１１０は、ストリーミングビデオセッションを確立してセッションパラメータ（たとえば、メディアがストリーミングされるべきビットレート）のネゴシエーションを行うために、メディアサーバ１１５とシグナリングメッセージを交換する。
【０００８】
メディアセッションの確立において、移動クライアント１１０は、無線アクセスベアラ（ＲＡＢ）チャネルを確立するために、無線ネットワークコントローラ（ＲＮＣ）１３０、ＳＧＳＮ１０３、およびＧＧＳＮ１２０と、下層シグナリングメッセージも交換する。たとえばベストエフォート型のベアラサービスが不十分だと考えられる場合、ＲＡＢチャネルは、一般的に所望のサービス品質（ＱｏＳ）機能を維持するように構成される。
【０００９】
一旦、ＲＡＢチャネルおよびストリーミングメディアセッションが確立されると、メディアサーバ１１５は、メディアを搬送するパケットを、ＧＧＳＮ１２０、ＳＧＳＮ１０３、ＲＮＣ１３０、および基地局１０７を介して、移動クライアント１１０に伝送する。移動クライアント１１０は、基地局１０７を通過する逆方向パスをたどって、ＲＮＣ１３０、ＳＧＳＮ１０３、ＧＧＳＮ１２０、および最後にメディアサーバ１１５に、周期的なフィードバックメッセージを送信する。移動クライアント１１０からのアップリンクフィードバックメッセージは、たとえば３−４秒に１度など、比較的まれに伝送される。
【００１０】
メディアサーバ１１５は、移動クライアント１１０に周期的に制御／シグナリングメッセージも伝送する。これらの「サーバレポート」は、ネットワーク要素によってトランスペアレントに搬送される。従来、メディアを搬送するダウンリンクパケットおよび制御／シグナリングメッセージ、ならびに移動クライアント１１０によって伝送されるアップリンクフィードバックメッセージはすべて、ネットワーク要素によってトランスペラレントに搬送される。したがって、メディアサーバ１１５が制御を決定すること（伝送またはコンテンツレートの変更など）を支援する、移動クライアント１１０からのフィードバックメッセージは、基本的にはエンドツーエンドである。つまり、フィードバックメッセージは、介在するネットワーク要素だけが利用可能などのような情報も搬送しない。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
図１に示される従来のシステムでは、メディアサーバ１１５による制御決定は、移動クライアント１１０から受信されるかなりまれなフィードバックに基づくものであり、チャネル状態の直接認識はない。その結果、メディアサーバ１１５は、ストリーミングメディアサービスの品質に悪影響をもたらすパケット損失、および／または再バッファリングイベントを避けるための、タイムリーな決定ができない。
【課題を解決するための手段】
【００１２】
ストリーミングメディアサーバのための、プロキシ駆動型コンテンツレート選択の方法が提供される。一方法では、クライアントからの受信者レポートメッセージに応答して、ネットワークコントローラからの１つまたは複数の最大伝送レートパラメータが、プロキシサーバに格納される。格納された最大伝送レートパラメータに基づいてメディアセッションの目標レートが生成され、その目標レートが、プロキシからサーバへのフィードバックメッセージにおいてメディアサーバに伝送される。
【００１３】
メディアサーバにおいて、プロキシサーバからの、プロキシからサーバへのフィードバックメッセージに応答して、複数のサポートされたコンテンツレートの中から、コンテンツレートが選択される。選択されたコンテンツレートは、プロキシサーバからの、プロキシからサーバへのフィードバックメッセージ内に含まれる目標レートから得られる目標レートパラメータ以下である。次いで、メディアサーバは、マルチメディアフレームを、選択されたコンテンツレートでクライアントにストリーミングする。
【００１４】
本発明は、本明細書で以下に述べられる詳細な説明、および添付の図面から、より十分に理解されるだろう。添付の図面において、同様の要素は同様の参照番号によって示される。添付の図面は例示の目的でのみ与えられるものであり、したがって本発明を限定するものではない。
【図面の簡単な説明】
【００１５】
【図１】無線ネットワークを介してメディアをストリーミングするための、従来のシステム１００を示す図である。
【図２】例示的実施形態に従って、無線ネットワークを介してメディアをストリーミングするための、システム１００を示す図である。
【図３】無線ネットワークを介してメディアセッションの間にフィードバックを提供する方法の、例示的実施形態を示す図である。
【図４】無線ネットワークを介してメディアセッションのコンテンツレートを設定する方法の、例示的実施形態を示す図である。
【図５】無線ネットワークを介してメディアセッションのコンテンツレートを設定するかどうかを決定する方法を示す図である。
【図６】例示的実施形態に従って、フレーム伝送スケジューリングを動的に調整する方法を示す図である。
【発明を実施するための形態】
【００１６】
本発明の例示的実施形態について以下に述べる。わかりやすくするために、本明細書では実際の実装形態のすべての特徴を説明するとは限らない。もちろん、このような実際のいずれの実施形態の開発においても、開発者の具体的な目標を達成するために、実装形態によって異なるシステム関連およびビジネス関連の制約条件の遵守などの、実装形態特有の多数の決定がなされるべきであることが理解されよう。さらに、このような開発努力は、複雑で時間がかかる場合があるが、本開示の恩恵に浴する当業者にとっては日常的な仕事であることが理解されよう。
【００１７】
本発明の一部、および対応する詳細な説明は、ソフトウェア、またはコンピュータメモリ内のデータビットに対する操作のアルゴリズムおよび記号表現に関して提示される。これらの説明および表現は、当業者がその仕事内容を当分野の他の当業者に効果的に伝えるためのものである。アルゴリズムは、その用語が本明細書で使用され、また一般的に使用されるように、所望の結果につながる首尾一貫した一連のステップであると考えられる。この諸ステップは、物理量の物理的な操作を必要とするステップである。必ずしもそうであるとは限らないが、通常、これらの量は、格納され、転送され、結合され、比較され、および他のやり方で操作することができる、光、電気、または磁気信号の形をとる。主に一般的に使用されているという理由で、これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことが、時に便利であることがわかっている。
【００１８】
しかし、これらのおよび類似の用語はすべて、適切な物理量に関連付けられるべきであり、これらの量に適用された便利なラベルにすぎない点を念頭に置かれたい。とくに指定のない限り、あるいは説明から明らかなように、「処理する（ｐｒｏｃｅｓｓｉｎｇ）」、「演算処理する（ｃｏｍｐｕｔｉｎｇ）」、「計算する（ｃａｌｃｕｌａｔｉｎｇ）」、「決定する（ｄｅｔｅｒｍｉｎｉｎｇ）」、または「表示する（ｄｉｓｐｌａｙｉｎｇ）」などの用語は、コンピュータシステムのレジスタおよびメモリ内の物理量、電子量として表されるデータを操作し、コンピュータシステムメモリまたはレジスタ、あるいは他のこのような情報格納、伝送、または表示装置内で物理量として同様に表される他のデータに変換するコンピュータシステムまたは類似の電子演算処理装置の動作および処理を指す。
【００１９】
本発明の、ソフトウェアで実装される態様は、一般的に何らかの形のプログラム記憶媒体上で符号化され、あるいは何らかのタイプの伝送媒体を介して実装される点にも留意されたい。プログラム記憶媒体は、磁気的なもの（たとえば、フロッピー（登録商標）ディスク、またはハードドライブ）でも、光学的なもの（たとえば、コンパクトディスク読出し専用メモリ、すなわち「ＣＤ  ＲＯＭ」）でもよく、また読出し専用でもランダムアクセスでもよい。同様に、伝送媒体は、ツイストペア線、同軸ケーブル、光ファイバでもよく、当分野で知られている他の何らかの適切な伝送媒体でもよい。本発明は、所与のいずれかの実装形態のこれらの態様によって限定されるものではない。
【００２０】
次に、本発明について添付の図面を参照して述べる。説明のためだけに、また当業者にはよく知られている詳細で本発明を不明瞭にしないために、様々な構造、システム、および装置が、図面に概略的に示されている。しかし、添付の図面は、例示的な実施例について述べ説明するために含まれている。本明細書で使用される単語および語句は、該当する場合には、当業者によるそれらの単語および語句の理解に一致する意味を有するものと理解され解釈されるべきである。
【００２１】
本明細書では、「移動クライアント」という用語は、クライアント、モバイル、移動ユニット、移動局、移動ユーザ、ユーザ装置（ＵＥ）、加入者、ユーザ、遠隔局、アクセス端末、受信機などと同義語であると考えられてよく、以下で時々そのように呼ばれることがあり、また無線通信ネットワーク内の無線リソースの遠隔ユーザを表してもよい。「基地局」という用語は、基地トランシーバ局（ＢＴＳ）、ノードＢ、拡張ノードＢ、フェムトセル、アクセスポイントなどと同義語であると考えられてよく、および／またはそのように呼ばれることがあり、ネットワークと１人または複数のユーザとの間のデータおよび／または音声接続のための無線ベースバンド機能を提供する装置を表してもよい。
【００２２】
図２は、無線ネットワークを介してメディアをストリーミングするためのシステムの例示的実施形態を概念的に示している。メディアサーバ２１５と移動クライアント２１０との間のネットワーク全体は、たとえ無線に加えて有線部分を含んでいても、無線ネットワークと呼ばれる。ＧＧＳＮ２２０と移動クライアント２１０との間のネットワーク部分は、無線アクセスネットワーク２２３と呼ばれる。
【００２３】
図２を参照すると、無線アクセスネットワーク２２３は、電波インタフェースを介して１つまたは複数の移動クライアント、すなわちユニット２１０（「クライアント」と呼ばれる）にメディアをストリーミングするために、１つまたは複数の基地局２０７を含む。メディア（たとえば、音声、ビデオなど）は、メディアサーバ２１５によって、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３、および無線ネットワークコントローラ（ＲＮＣ）２３０Ａを介して提供される。無線アクセスネットワーク２２３、基地局２０７、クライアント２１０、メディアサーバ２１５、ＳＧＳＮ２０３、ＧＧＳＮ２２０、およびＲＮＣ２３０Ａ、２３０Ｂは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）（３ＧＰＰ）標準および／またはプロトコルに従って動作してよい。
【００２４】
ストリーミングメディアセッションでは、メディアコンテンツ（たとえば、音声、ビデオ、オーディオなど）を搬送するために、リアルタイムトランスポートプロトコル（ＲＴＰ）が使用されてよく、また、関連する制御パケットを搬送するために、関連するリアルタイム制御プロトコル（ＲＴＣＰ）が使用されてよい。ＲＴＣＰメッセージについては、以下で多少より詳細に説明する。リアルタイムストリーミングプロトコル（ＲＴＳＰ）は、セッションのセットアップ（機能ネゴシエーション／交換を含む）、分解、および何らかのユーザ動作（たとえば、一時停止、早送りなど）のための、メッセージの伝送のために使用されてよい。
【００２５】
ＲＴＰ／ＲＴＣＰ、およびＲＴＳＰに関する詳細は、インターネットエンジニアリングタスクフォースリクエストフォーコメント（ＩＥＴＦ  ＲＦＣ）１８８９および２３２６でそれぞれ論じられているので、よく知られている。
【００２６】
特定の標準および／またはプロトコルに関して例示的実施形態が論じられているが、例示的実施形態は、たとえばｃｄｍａ２０００高速パケットデータ（ＨＲＰＤ）またはＩＥＥＥ８０２．１６ｅ／ＷｉＭＡＸなどの、他のどのような無線ネットワーキング技術および標準にも適用されてよい。ｃｄｍａ２０００  ＨＲＰＤの場合、たとえば、システム２００は、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３およびゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０が、パケットデータサービングノード（ＰＤＳＮ）として知られる単一のエンティティに置き換えられるだろうということを除いて、図２のシステム２００と同一のものである可能性が高い。
【００２７】
さらに、階層アーキテクチャが図示されているが、本明細書で論じられる技法は、無線アクセスネットワーク２２３に関するレイヤ３（ＩＰ）ルーティングおよび制御機能が基地局２０７によって実行される、フラットインターネットプロトコル（ｆｌａｔ−ＩＰ）ベースのアーキテクチャにも適用されてよい。
【００２８】
例示的実施形態によれば、クライアント２１０は、３ＧＰＰ拡張子の有無にかかわらず、トランスペアレントなエンドツーエンドパケット交換ストリーミングサービスのための、標準的なＲＴＳＰ／ＲＴＣＰシグナリングをサポートする。
【００２９】
メディアセッションの間、クライアント２１０は、わずかなパケット損失（前回の同様のレポート以来の）、パケット損失の累積数、受信した最高（ＲＴＰ）シーケンス番号、前回の送信者レポート（サーバから受信した）に関連付けられるＲＴＰタイムスタンプ、前回の送信者レポート受信からの時間、復号されるべき次のアプリケーションデータユニットに関連付けられるＲＴＰシーケンス番号、次のアプリケーションデータユニットの復号までの遅延、使用していないバッファ領域（クライアントにおける）などのパフォーマンスメトリクスをメディアサーバ２１５に知らせるために、周期的にＲＴＣＰ（フィードバック）パケット（「受信者レポートメッセージ」または「受信者レポート」）を、メディアサーバ２１５に送信する。上記のパフォーマンスメトリクスのリストのうちの最後の３つは、パケット交換ストリーミングサービスのための３ＧＰＰ拡張子によるものであり、その他は、受信者レポートメッセージ内に含まれるより標準的なフィードバック項目である。受信者レポートに含まれるこれらの項目以外は、それぞれのＲＴＣＰパケットが、レポートを時間内の特定の点と関連付けるためにサーバによって使用されうるタイムスタンプを搬送してもよい。クライアント２１０は、ＲＴＣＰフィードバックパケットを、自分の機能および無線ネットワークの容量と調和するレートで送信してよい。一般的に、このようなフィードバックパケットは、比較的まれに、たとえば３から４秒に１度送信される。以下では、クライアント２１０がＲＴＣＰフィードバックパケットを送信する間隔をＴＲと表す。
【００３０】
引き続き図２を参照すると、無線通信システム２００はシグナリングプロキシ２２５をさらに含んでいる。シグナリングプロキシ２２５はプロキシサーバとして実装されてよく、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０などの無線アクセスネットワークエンティティに接続される。しかし、シグナリングプロキシ２２５は、他の実施形態では、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３、または無線ネットワークコントローラ（ＲＮＣ）２３０Ａ、２３０Ｂなどの、他のアクセスネットワークエンティティに接続されてよい。
【００３１】
他の例では、シグナリングプロキシ２２５は、アクセスネットワークがフラットアーキテクチャによって特徴付けられる基地局ルータを含む場合、基地局自体に接続されてよい。
【００３２】
Ｂａｌａｃｈａｎｄｒａｎ他の同時係属および関連特許出願第１１／６７４，８５８号において論じられるように、メディアセッションを確立するとき、分解するとき、およびメディアセッションの間、クライアント２１０はメディアサーバ２１５宛てのＲＴＳＰおよび／またはＲＴＣＰメッセージを、無線ネットワーク２００を介して送信する。例示的実施形態によれば、ＧＧＳＮ２２０は、クライアント２１０からのＲＴＳＰおよびＲＴＣＰメッセージを傍受して、これらのメッセージをメディアサーバ２１５の代わりにシグナリングプロキシ２２５に送信する。
【００３３】
図３は、無線ネットワークにおけるメディアセッションの目標レートを確立する方法の、例示的実施形態を示している。図３における方法は、ＧＧＳＮ２２０を介して、クライアント２１０から最初のＲＴＳＰメッセージを受信することに応答して実行される。図３の方法は、図２に示されたネットワークに関して、また具体的には、シグナリングプロキシ２２５で実行されているものとして論じられる。
【００３４】
図２および図３を参照すると、ステップＳ３０５で、クライアント２１０からの最初のＲＴＳＰメッセージに応答して、シグナリングプロキシ２２５が新しいメディアセッションのためのエントリを自分のデータベース（図示せず）内に作成する。最初のＲＴＳＰメッセージは新しいメディアセッションが近々確立することを示す。
【００３５】
ステップＳ３０７で、シグナリングプロキシ２２５は、メディアセッションの機能ネゴシエーション段階の間、ＲＴＳＰメッセージからセッションパラメータを取得するために（たとえば、クライアントのバッファサイズ、受信者レポートが送信される時間間隔など）、クライアント２１０とメディアサーバ２１５との間で交換された後続のＲＴＳＰメッセージを監視する。
【００３６】
シグナリングプロキシ２２５が、メディアセッションが確立されようとしていることがわかると（たとえば、クライアントからの「ＳＥＴＵＰ」ＲＴＳＰメッセージを介して）、シグナリングプロキシ２２５はセッション確立表示メッセージをＲＮＣ２３０Ａに送信し（ステップＳ３０９で）、ＲＮＣ２３０Ａを通じて対応するメディアストリームが配信されることになる。
【００３７】
ステップＳ３０９ではまた、シグナリングプロキシ２２５が、シグナリングプロキシ２２５がＲＮＣ２３０ＡからのＲＡＢ確立メッセージを待つ時間間隔を指定するタイマを設定する。タイマが切れると、シグナリングプロキシ２２５がＲＮＣ２３０ＡからＲＡＢ確立メッセージを受信していない場合（ステップＳ３１１で）、シグナリングプロキシ２２５は自分のローカルデータベースからセッションエントリを削除し（ステップＳ３１３で）、このプロセスは終了する。
【００３８】
ステップＳ３１１に戻ると、タイマが切れる前に、シグナリングプロキシ２２５が近々起りそうなメディアセッションについてのＲＡＢ確立メッセージを受信すると、シグナリングプロキシ２２５はタイマの電源を切り、ステップＳ３１５でセッションフラグを０に設定する。次いで、シグナリングプロキシ２２５は、ステップＳ３１７で待ち状態に入る。待ち状態の間、シグナリングプロキシ２２５は、ＲＮＣ２３０Ａからのチャネル／ネットワーク状態フィードバックメッセージ、およびクライアント２１０からの受信者レポート（またはＲＴＣＰ）メッセージを待つ。本明細書で論じられるように、チャネル／ネットワーク状態フィードバックメッセージは、ネットワーク状態フィードバックメッセージとも呼ばれる。チャネル／ネットワーク状態フィードバックメッセージは、最大伝送レートパラメータＷＳ、および、任意選択で、ＲＮＣ２３０Ａで、バッファ内で待っているメディアセッションに属しているＩＰパケット数、および対応するバイト数などの、他の関連するパフォーマンスメトリクスを含む。
【００３９】
最大伝送レートパラメータＷＳは、前述のチャネル状態フィードバック間隔（Ｔｐ秒の長さの）の間にクライアント２１０に配信されるＩＰパケット数、メディアセッションが利用可能な伝送機会の数、および、前述の間隔の間にデータを搬送するために実際に使用される伝送機会の数に基づいて演算処理されてよい。専用チャネルがあれば、その専用チャネルに属している伝送ブロックが伝送機会を表す。
【００４０】
より詳細な例では、Ｔｐ秒の間のｎ番目の間隔のための最大伝送レートパラメータＷＳは、利用可能な帯域幅パラメータＷＡ（ｎ）と等しく設定されてよく、以下によって示される（１秒あたりのバイトのユニットで）：
ＷＡ（ｎ）＝ＭＤ（ｎ）＊ＫＡ（ｎ）／（Ｋｕ（ｎ）＊Ｔｐ）
【００４１】
上式で、ＫＡ（ｎ）およびＫｕ（ｎ）はそれぞれ、メディアセッションが利用可能な伝送機会の数、および、ｎ番目のチャネル状態フィードバック間隔（Ｔｐ秒の長さの）の間にデータを搬送するために実際に使用される伝送機会の数を示す。可変のＭＤ（ｎ）は、この間隔の間クライアント２１０に実際に配信されるパケットに関連付けられるバイト数を示す。ｎ番目のチャネル／ネットワーク状態フィードバック間隔ＷＳ（ｎ）のための最大伝送レートパラメータは、利用可能な帯域幅パラメータＷＡ（ｎ）と等しく設定されてもよく、以下のヒューリスティックに従って設定されてもよい：
ＷＳ（ｎ）＝αＬ＊ＷＡ（ｎ）  Ｑ（ｎ）＜βＬの場合
＝αＨ＊ＷＡ（ｎ）  Ｑ（ｎ）＞βＨの場合
＝ＷＡ（ｎ）  そうでない場合。
【００４２】
上記のヒューリスティックで、Ｑ（ｎ）は、ｎ番目のチャネル／ネットワーク状態フィードバック間隔の終わりにＲＮＣ２３０Ａバッファ内の待ち行列に入れられたメディアセッションに属するデータ量である。βＨは何らかの「高水位線」であり、βＬは何らかの「低水位線」であり、βＨ＞βＬである。定数αＬおよびαＨは、常時αＨ＜１、およびαＬ＞１である。
【００４３】
一例を挙げると、２０キロバイトのセッションごとの専用ＲＮＣ２３０Ａバッファがあれば、βＨおよびβＬはそれぞれ１０キロバイトおよび２キロバイトと等しく設定されてよいのに対し、αＨおよびαＬはそれぞれ０．５および１．５と等しく設定されてよい。
【００４４】
シグナリングプロキシ２２５は、Ｔｐ秒ごとにＲＮＣ２３０Ａからチャネル／ネットワーク状態フィードバックメッセージを、および、ＴＲ秒ごとにクライアント装置２１０から受信者レポートメッセージを受信すると予想される。
【００４５】
ステップＳ３１７で待ち状態の間、クライアント２１０から最初の受信レポートメッセージを受信すると、ステップＳ３１９で、シグナリングプロキシ２２５は前述のセッションフラグを１に設定して、チャネル／ネットワーク状態フィードバックカウンタ値Ｎ（以下で、「フィードバックカウンタ値」と呼ばれる）を０に初期設定する。シグナリングプロキシ２２５で、セッションフラグが０と等しい限り、チャネル／ネットワーク状態フィードバックメッセージは無視される。最初の受信者レポートメッセージが受信されて、セッションフラグが１に設定された後、ステップＳ３２０で、シグナリングプロキシ２２５は待ち状態に入る。ステップＳ３２０で待ち状態の間、ステップＳ３３３で、シグナリングプロキシ２２５は、受信したどのような受信者レポートメッセージからの関連情報も記録し、ステップＳ３３５で、その受信者レポートメッセージをメディアサーバ２１５に転送する。
【００４６】
ステップＳ３２０に戻ると、ステップ３２０で、待ち状態の間にシグナリングプロキシ２２５がチャネル／ネットワーク状態フィードバックメッセージを受信すると、シグナリングプロキシ２２５は、ステップＳ３２９で、メッセージにおいてレポートされた最大伝送レートパラメータを格納して、ステップ３２１でフィードバックカウンタ値Ｎを１だけ増分する（Ｎ←Ｎ＋１）。次いで、ステップＳ３２３で、シグナリングプロキシ２２５は、増分されたフィードバックカウンタ値Ｎをフィードバックカウンタしきい値ＴＨＲＥＳＨＯＬＤと比較する。シグナリングプロキシ２２５がレートフィードバックを適当な間隔でメディアサーバ２１５に提供できるように、フィードバックカウンタしきい値ＴＨＲＥＳＨＯＬＤは５などの値に設定されてよい。
【００４７】
たとえば、上述のように、シグナリングプロキシ２２５は、ＲＮＣ２３０Ａから比較的頻繁に（たとえば、１００ミリ秒に１回）チャネル／ネットワーク状態フィードバックメッセージを受信する。プロキシからサーバへのメッセージ（以下でより詳細に説明する）をメディアサーバ２１５に適当な間隔（たとえば５００ミリ秒、または約１秒）で送信するために、シグナリングプロキシ２２５は、５番目または１０番目の受信したチャネル／ネットワーク状態フィードバックメッセージごとに、メディアサーバ２１５のためのレートフィードバックを生成する。しきい値ＴＨＲＥＳＨＯＬＤを５または１０に設定することにより、チャネル／ネットワーク状態フィードバック間隔が１００ミリ秒の場合、シグナリングプロキシがメディアサーバのためのレートフィードバックを５００ミリ秒ごと、または１秒ごとに生成するという結果になる。
【００４８】
引き続き図３を参照すると、フィードバックカウンタ値Ｎがフィードバックカウンタしきい値ＴＨＲＥＳＨＯＬＤ未満の場合、ステップＳ３２０で、シグナリングプロキシ２２５は待ち状態に戻る。
【００４９】
ステップＳ３２３に戻ると、フィードバックカウンタ値Ｎがフィードバックカウンタしきい値ＴＨＲＥＳＨＯＬＤ以上である場合、シグナリングプロキシ２２５は、前回フィードバックカウンタ値Ｎはリセットされたので、シグナリングプロキシ２２５に格納されたメディアセッションに関連付けられる最大伝送レートパラメータＷＳの値に基づいて、目標レートＲＴを演算処理する。シグナリングプロキシ２２５は、格納された最大伝送レートパラメータＷＳの加重和を計算することによって、目標レートＲＴを演算処理する。加重和は単純平均でもよく、より最近受信された最大伝送レートパラメータ値ＷＳをより重要視するように重みが設定されてもよい。より積極的なストリーミングができるように、目標レートＲＴを最大伝送レートパラメータ値ＷＳの平均を上回る値に設定することも可能である。
【００５０】
引き続き図３のステップＳ３２５を参照すると、シグナリングプロキシ２２５は演算処理された目標レートＲＴ（最大ストリーミングレートとも呼ばれる）を、プロキシからサーバへのフィードバックメッセージにおいて、メディアサーバ２１５に送信する。
【００５１】
以下でより詳細に説明するように、目標レートＲＴは、メディアサーバ２１５でメディアセッションのコンテンツレートを設定するために使用される。メディアセッションの間、メディア（たとえば、音声、ビデオ、オーディオなど）は、コンテンツレートと呼ばれる異なるレートで送出されてよい。コンテンツレートは、対応するメディアストリームを搬送するために必要な平均伝送レートに対応する。メディアストリームの所与のコンテンツレートは、適切な符号化と細線化（ｔｈｉｎｎｉｎｇ）との組合せによって実現されうる。一般的には、コンテンツレートが高いほど、エンドユーザにとってメディア品質がよい。
【００５２】
再び図３を参照すると、ステップＳ３２７で、シグナリングプロキシ２２５はフィードバックカウンタ値Ｎ＝０にリセットし、格納されたすべての最大伝送レートパラメータ値ＷＳを消去し、ステップＳ３２０で待ち状態に戻る。次いで、この方法は、クライアント２１０、またはメディアサーバ２１５からの適切なＲＴＳＰメッセージによってメディアセションが終了するまで、上述のように継続する。
【００５３】
例示的実施形態によると、クライアント２１０、またはメディアサーバ２１５からの適切なＲＴＳＰメッセージでメディアセッションが終了すると、シグナリングプロキシ２２５はそのメディアセッションのエントリを自分のローカルデータベースから削除する。シグナリングプロキシ２２５は、メディアサーバ２１５への、プロキシからサーバへのフィードバックメッセージの送信も停止し、またチャネル／ネットワーク状態フィードバックメッセージの送信を停止するようＲＮＣ２３０Ａに指示する。
【００５４】
上述のように、シグナリングプロキシ２２５はプロキシからサーバへのフィードバックメッセージをメディアサーバ２１５に周期的に（一定の間隔で）送信する。周期的な間隔は、約数百ミリ秒（たとえば、約１００ミリ秒から約１０００ミリ秒、すなわち１秒）でよい。これらのメッセージのうちの少なくともいくつかに応答して、メディアサーバ２１５はメディアセッションのコンテンツレートを設定してよい。メディアサーバ２１５は、シグナリングプロキシ２２５を介してクライアント２１０から周期的な受信者レポートメッセージも受信する。
【００５５】
一般的に、メディアサーバ２１５の観点からすると、例示的実施形態によるコンテンツレート選択の方法は、クライアント２１０からの最初のＲＴＳＰメッセージ（シグナリングプロキシ２２５から転送された）の受信で始まる。ＲＴＳＰメッセージは、メディアセッションをセットアップしたいというクライアント２１０の要求を、メディアサーバ２１５に伝える。次いで、メディアサーバ２１５は、機能ネゴシエーション（交換）およびセッション確立のための次のメッセージングに関与する。機能ネゴシエーションおよびセッション確立が実行される方法は当分野でよく知られており、したがって詳細な説明は省略する。
【００５６】
上述のように、メディアが記憶装置からストリーミングされている場合、そのメディアは異なるコンテンツレートで符号化されて、将来の使用のために格納されうる。ライブストリーミングメディアセッションのために、符号化は「オンザフライ」で行われる。メディアがストリーミングされているとき、メディアサーバ２１５はメディアフレームを含む適切なファイルを選択し、これらのファイルをパケット化し、選択されたコンテンツレートに基づいてそれらのファイルをクライアント２１０に伝送する。この説明のために、メディアはＣ１＜Ｃ２＜．．．．＜ＣＭであるような、Ｃ１，Ｃ２．．．．，ＣＭの、Ｍ個のコンテンツレートのうちのいずれか１つで送出されうると仮定する。
【００５７】
機能ネゴシエーションおよびセッション確立完了後、またはそれと同時に、メディアサーバ２１５はそのメディアセッションのコンテンツレートを決定して、クライアント２１０へのメディアフレームのストリーミングを開始する。メディアサーバ２１５は、クライアント２１０から、シグナリングプロキシ２２５を介して上述の受信者レポートメッセージを、および、シグナリングプロキシ２２５から、プロキシからサーバへのメッセージを受信することも開始する。従来のメディアサーバの場合、メディアサーバ２１５は、クライアント２１０でのフレーム送出時間の推定を維持する。これらの推定は、メディアサーバ２１５が、クライアント２１０から受信者レポートメッセージを受信するたびにアップデートされる。メディアサーバ２１５は、コンテンツレートを動的に設定して、メディアセッションのフレーム伝送スケジューリングを実行する。
【００５８】
図４は、メディアサーバ２１５でメディアセッションのコンテンツレートを設定する方法の、例示的実施形態を示している。図４に示された方法は、メディアセッションの最初のコンテンツレートを設定するために、または、メディアセッションの間にコンテンツレートを動的に調整（リセット）するために使用されてよい。
【００５９】
図４を参照すると、ステップＳ４０２で、シグナリングプロキシ２２５から受信した、プロキシからサーバへのフィードバックメッセージに応答して、メディアサーバ２１５がメディアセッションのコンテンツレートを設定する。上述のように、プロキシからサーバへのフィードバックメッセージは、目標レートＲＴを含む。目標レートＲＴは、ネットワーク内の現在のチャネル状態を示す。より詳細には、上述のように、目標レートＲＴは、ネットワーク内の現在のチャネル状態を示す、ＲＮＣ２３０Ａからの複数の最大伝送レートパラメータＷＳから得られる。
【００６０】
一例を挙げると、（１＋β）＊ＲＴ以下である最高コンテンツレートを（Ｍ個のサポートされたコンテンツレート：Ｃ１，Ｃ２．．．．，ＣＭの中から）選択することによって、メディアサーバ２１５がコンテンツレートを設定する。本明細書で論じられるように、（１＋β）＊ＲＴは目標レートパラメータと呼ばれる。この例では、パラメータβはあらかじめ定められた、または所与のコンテンツレート「攻撃」ファクタであり、０以上であるように選択される。一例を挙げると、メディア品質と起こりうるバッファオーバーフローとのバランスをとるために、パラメータβは、０．０５から０．１０の間で設定されてよい。最高コンテンツレートの選択において、メディアサーバ２１５は、プロトコルおよびパケット化オーバーヘッドを考慮してもよい。
【００６１】
引き続きステップＳ４０２を参照すると、メディアサーバ２１５が利用可能な最低コンテンツレート（たとえば、Ｃ１）が（１＋β）＊ＲＴをなお上回るとメディアサーバ２１５が決定すると、図４のステップＳ４０２で、メディアサーバ２１５は、コンテンツレートを最低コンテンツレートＣ１と等しく設定する。
【００６２】
他の実施形態では、Ｃ１＜Ｃ２＜．．．．＜ＣＭであるような、Ｃ１，Ｃ２．．．．，ＣＭの、Ｍ個の異なるコンテンツレートがあり、また現在のコンテンツレートがＣｉ（上式で、ｉ＝１，２，．．．，Ｍ）の場合、メディアサーバ２１５は、コンテンツレートをコンテンツレートＣｊと等しく設定し、上式で、ｊは、セット（ｉ−ｋ，ｉ−ｋ＋１，．．，ｉ，．．．，ｉ＋ｋ−１，ｉ＋ｋ）におけるすべての指数の中で、Ｃｊ＜（１＋β）＊ＲＴである、最高指数である。
【００６３】
セット（ｉ−ｋ，ｉ−ｋ＋１，．．，ｉ，．．．，ｉ＋ｋ−１，ｉ＋ｋ）における指数に関連付けられるコンテンツレートのうちのいずれも、（１＋β）＊ＲＴ以下でない場合、コンテンツレートは最大（ｉ−ｋ，１）と設定され、上式で、ｋは、どのようなレート変更の瞬間にもコンテンツレート内で取り上げられるまたは削除されるステップ数を抑制する正の整数であり、最大（ｉ−ｋ，１）は、２つの量「ｉ−ｋ」および「１」のうちの大きい方を指す。ｋ＝１である特別の場合では、コンテンツレートは、どのようなレート変更の瞬間にも、１ステップ増加または減少してよい。
【００６４】
引き続き図４を参照すると、ステップＳ４０４で、メディアサーバ２１５は、設定されたコンテンツレートで、クライアント２１０へのメディアフレームのストリーミングを開始する。
【００６５】
頻繁なコンテンツレート変更は、クライアント２１０でエンドユーザにとって望ましくない知覚品質を有する場合があるので、コンテンツレート変更の頻度は一定の限度内に維持されてよい。
【００６６】
一例を挙げると、プロキシからサーバへのフィードバックメッセージが、シグナリングプロキシ２２５からメディアサーバ２１５に送信される時間間隔が適切に大きい（たとえば、２−３秒）場合、メディアサーバ２１５は、シグナリングプロキシ２２５からの、それぞれのプロキシからサーバへのフィードバックメッセージに応答して、適応的に／動的にコンテンツレートを調整してよい。
【００６７】
他の例では、メディアサーバ２１５がプロキシからサーバへのメッセージを受信する間隔が比較的短い（たとえば、４００−５００ミリ秒）場合、メディアサーバ２１５は、メディアセッションのコンテンツレートを調整するかどうかを決定するために、プロキシからサーバへのフィードバックメッセージが受信されるたびに、図５に示された方法を使用してよい。
【００６８】
図５を参照すると、コンテンツレートを設定（リセット／アップデート／変更）後、ステップＳ５０４で、メディアサーバ２１５はタイマ値Ｔ＝０に設定する。次いで、ステップＳ５０６で、メディアサーバ２１５は、シグナリングプロキシ２２５からの、プロキシからサーバへのフィードバックメッセージを待つ。プロキシからサーバへのフィードバックメッセージを受信すると、ステップＳ５０８で、メディアサーバ２１５が新しいコンテンツレートＲ＿ＣＡＬＣを生成する。メディアサーバ２１５は、上述のように、シグナリングプロキシ２２５からの、もっとも最近のプロキシからサーバへのフィードバックメッセージにおいて受信した目標レートＲＴに基づいて、新しいコンテンツレートＲ＿ＣＡＬＣを選択する。
【００６９】
ステップＳ５１０で、新しいコンテンツレートＲ＿ＣＡＬＣが、メディアセッションの現在のコンテンツレートＲ＿ＣＵＲＲと比較される。新しいコンテンツレートＲ＿ＣＡＬＣが現在のコンテンツレートＲ＿ＣＵＲＲを上回る場合、ステップＳ５１２で、メディアサーバ２１５がタイマ値Ｔをステップアップしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＵＰと比較する。タイマ値Ｔがしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＵＰを超える場合、ステップＳ５１４で、メディアサーバ２１５が現在のコンテンツレートＲ＿ＣＵＲＲを新しいコンテンツレートＲ＿ＣＡＬＣと等しく設定する。次いで、メディアサーバ２１５は、ステップＳ５１６で、タイマ値Ｔ＝０にリセットし、ステップＳ５０６で待ち状態に戻る。
【００７０】
ステップＳ５１２に戻ると、タイマ値Ｔがしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＵＰ以下である場合、ステップＳ５０６で、現在のコンテンツレートＲ＿ＣＵＲＲを変更せずに（維持しながら）、メディアサーバ２１５は待ち状態に戻る。
【００７１】
ステップＳ５１０に戻ると、新しいコンテンツレートＲ＿ＣＡＬＣが現在のコンテンツレートＲ＿ＣＵＲＲを上回らない場合、ステップＳ５１８で、メディアサーバ２１５が、新しいコンテンツレートＲ＿ＣＡＬＣが現在のコンテンツレートＲ＿ＣＵＲＲ未満かどうかを決定する。新しいコンテンツレートＲ＿ＣＡＬＣが現在のコンテンツレートＲ＿ＣＵＲＲ未満ではない（現在のコンテンツレートＲ＿ＣＵＲＲと新しいコンテンツレートＲ＿ＣＡＬＣとが等しい）場合、ステップＳ５０６で、メディアサーバ２１５は、現在のコンテンツレートＲ＿ＣＵＲＲを変更せず、タイマ値Ｔもリセットせずに、単純に待ち状態に戻る。
【００７２】
ステップＳ５１８に戻ると、新しいコンテンツレートＲ＿ＣＡＬＣが現在のコンテンツレートＲ＿ＣＵＲＲ未満の場合、ステップＳ５２０で、メディアサーバ２１５はタイマ値Ｔをステップダウンしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＤＯＷＮと比較する。タイマ値Ｔがステップダウンしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＤＯＷＮを上回る場合、ステップＳ５１４で、メディアサーバ２１５は、現在のコンテンツレートＲ＿ＣＵＲＲを新しいコンテンツレートＲ＿ＣＡＬＣと等しく設定して、上述のように進む。
【００７３】
ステップＳ５２０に戻ると、タイマ値Ｔがステップダウンしきい値ＴＨＲＥＳＨ＿ＳＴＥＰ＿ＤＯＷＮ以下である場合、ステップＳ５０６で、メディアサーバ２１５は現在のコンテンツレートＲ＿ＣＵＲＲを変更せずに、単純に待ち状態に戻る。
【００７４】
コンテンツレートの増減が２つのしきい値を介して制御されるこの構成は、頻繁なレート変更を避ける必要性と、より高いコンテンツレートが維持できないようなチャネル状態のときにペイロードを迅速に減少させる必要性との間に適切な折り合いをつける際に、一層の柔軟性を提供する。
【００７５】
計算された目標レートＲＴのもっとも最近の値が以前の（もっとも最近の）値よりも低い場合、プロキシからサーバへのフィードバックメッセージを固定間隔で送信する代わりに、シグナリングプロキシ２２５がメッセージをより短い間隔で送信できる、類似の構成をシグナリングプロキシ２２５内に実装することも可能である。
【００７６】
メディアサーバ２１５で、フレーム伝送スケジューリングは、それぞれの送出時間以前に復号および送出の準備ができている適切なフレームを、クライアント装置２１０が確実に有するようにする。クライアント２１０のバッファ領域によって、メディアサーバ２１５は、フレームがクライアント２１０でバッファされて必要なときに準備ができているように、送出時間よりもかなり早くフレームを伝送できるようになる。上述のように、バッファ領域は、メディアセッションに利用可能なチャネル帯域幅内の変動を、クライアント２１０が克服するのを助ける。
【００７７】
通常の動作コースでは、メディアサーバ２１５は、フレーム周期ごとに１度、フレームを出力する。フレームに関連付けられるコンテンツレートは、メディアサーバ２１５によって設定された現在のコンテンツレートＲ＿ＣＵＲＲである。ある実装形態では、メディアサーバ２１５は、メディアサーバの入力−出力オーバーヘッドを減らすために、Ｋフレーム周期ごとに１度、Ｋフレームのブロックを出力してよい。メディアサーバ２１５が、フレーム周期ごとに１フレームを、またはＫフレーム周期ごとにＫフレームを出力するかにかかわらず、メディアサーバ２１５の出力は１フレーム周期ごとに１フレームと平均化される。場合によっては、フレーム伝送の周波数が調整されてよい。たとえば、クライアント２１０が、自分のバッファ領域がいっぱいになりつつあることを示す場合（受信者レポートメッセージを介して）、メディアサーバ２１５は、クライアントが十分なバッファ領域が利用可能であることを示すまで（他の受信者レポートメッセージを介して）、新しいフレームの伝送レートを減らしてよい。たとえば、フレーム周期ごとに１フレームという通常のレートで伝送する代わりに、クライアント２１０が新しいフレームのために十分なバッファスペースを有していることを示すまで、メディアサーバ２１５は２フレーム周期ごとに１フレームを伝送してよい。
【００７８】
一方、メディアサーバ２１５は、フレームの送出（ｐｌａｙ−ｏｕｔ）開始前にクライアント２１０のバッファがプリロールレベルまで満たされる必要があるときの最初の待ち時間を減らすために、メディアセッションの開始時にフレーム伝送レートを増やしてよい。例示的実施形態に従ってフレーム伝送を調整する方法は、図６に関して以下でより詳細に説明する。
【００７９】
図６は、メディアサーバ２１５でフレーム伝送を動的に調整する方法を示している。
【００８０】
図６を参照すると、クライアント２１０から受信者レポートメッセージを受信すると、ステップＳ６０２で、メディアサーバ２１５は、現在利用可能なクライアントバッファ領域を最小しきい値ＭＩＮ＿ＴＨＲＥＳＨと比較する。メディアサーバ２１５が、クライアント２１０で現在利用可能なバッファ領域が最小しきい値ＭＩＮ＿ＴＨＲＥＳＨ以下であると決定する場合、ステップＳ６０８で、メディアサーバ２１５は、フレームが実際にクライアント２１０に伝送されるレートを減らす。
【００８１】
ステップＳ６０２に戻ると、メディアサーバ２１５が、クライアント２１０で現在利用可能なバッファ領域が最小しきい値ＭＩＮ＿ＴＨＲＥＳＨを上回ると決定する場合、ステップＳ６０４で、メディアサーバ２１５は、現在利用可能なバッファ領域を最大しきい値ＭＡＸ＿ＴＨＲＥＳＨと比較する。クライアント２１０で現在利用可能なバッファ領域が最大しきい値ＭＡＸ＿ＴＨＲＥＳＨ以上である場合、ステップＳ６０６で、メディアサーバ２１５は、フレームが実際にクライアント２１０に伝送されるレートを増やす。
【００８２】
ステップＳ６０８に戻ると、クライアント２１０で現在利用可能なバッファ領域が最大しきい値ＭＡＸ＿ＴＨＲＥＳＨ未満の場合、メディアサーバ２１５は、フレームをクライアント２１０に、たとえば、１フレーム周期ごとに１フレームの平均レートで伝送する。
【００８３】
本明細書に記載の技法の実施形態は、従来技術より優れた多くの諸利点を提供できる。たとえば、従来のメディアサービス（たとえば、ビデオサービス）セットアップでは、クライアントによって提供されたデータを使用して、メディアサーバがメディアセッションのコンテンツレートを推定する。この推定は間接的であり、しばしば明らかなエラーを含む、または、とくに典型的な無線ネットワークなどの動的な動作状況では、単純に時代遅れである場合がある。
【００８４】
それに反して、例示的実施形態は、シグナリングプロキシによって決定された目標レートに基づくコンテンツレートを利用しており、直接測定に基づくため、少なくとも部分的により正確である。これにより、コンテンツレート決定の精度が改善し、無線アクセスネットワーク内でのパケット損失の可能性、または利用可能なリソースを十分活用しない可能性を減らしながら、サーバがデータを最適に伝送できるようになる。
【００８５】
本発明をこのように説明したが、本発明を多くの方法で変更できることは明らかである。このような変形形態は本発明から逸脱するものと見なされるべきではなく、このようなすべての修正形態は本発明の範囲内に含まれるものとする。
【図１】
2010537556.tif 000003
【図２】
2010537556.tif 000004
【図３】
2010537556.tif 000005
【図４】
2010537556.tif 000006
【図５】
2010537556.tif 000007
【図６】
2010537556.tif 000008
【国際調査報告】
2010537556.tif 000009
2010537556.tif 000010