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