(57)【要約】本発明は、メディア・サーバと、無線ネットワークと、無線ネットワークとの少なくとも１つのエア・インターフェースに関連する少なくとも１つのメディア・クライアントとが関与する方法を提供する。この方法は、少なくとも１つのメディア・クライアントの少なくとも１つの状態を示す第１の情報にアクセスするステップを含む。第１の情報は、少なくとも１つのメディア・クライアントによって提供される。この方法は、少なくとも１つのエア・インターフェースに関連するリソースを示す第２の情報にアクセスするステップをも含む。第２の情報は、無線ネットワークによって提供される。この方法はさらに、メディア・サーバに少なくとも１つのフィードバック・パラメータを提供するステップを含む。少なくとも１つのフィードバック・パラメータは、第１および第２の情報に基づいて形成される。
2010518783.tif 000002
【特許請求の範囲】
【請求項１】
メディア・サーバと、無線ネットワークと、前記無線ネットワークとの少なくとも１つのエア・インターフェースに関連する少なくとも１つのメディア・クライアントとが関与する方法であって、
前記少なくとも１つのメディア・クライアントの少なくとも１つの状態を示す第１の情報にアクセスするステップを含み、前記第１の情報が前記少なくとも１つのメディア・クライアントによって提供され、さらに、
前記少なくとも１つのエア・インターフェースに関連するリソースを示す第２の情報にアクセスするステップを含み、前記第２の情報が前記無線ネットワークによって提供され、さらに、
前記第１および第２の情報に基づいて形成される少なくとも１つのフィードバック・パラメータを前記メディア・サーバに提供するステップとを含む方法。
【請求項２】
前記第１の情報にアクセスするステップは、前記少なくとも１つのメディア・クライアントへのパケット配信率、前記少なくとも１つのメディア・クライアントに関連するパケットロス率、前記少なくとも１つのメディア・クライアント内の使用可能なバッファ空間、及び、前記少なくとも１つのメディア・クライアント内のバッファ・オーバーフローまたはアンダフローの期待時間、のうちの少なくとも１つを示す第１の情報にアクセスするステップを含む、請求項１に記載の方法。
【請求項３】
前記第２の情報にアクセスするステップは、無線ネットワーク・エンティティのバッファ・レベル、少なくとも１つの無線ネットワーク・エンティティによって提示された負荷、前記少なくとも１つのメディア・クライアントに関連する前記少なくとも１つのエア・インターフェースのダウンリンク帯域幅を共有するユーザの数、及び、前記少なくとも１つのメディア・クライアントのそれぞれが使用可能な前記少なくとも１つのエア・インターフェースの帯域幅の一部分、のうちの少なくとも１つを示す第２の情報にアクセスするステップを含む、請求項１に記載の方法。
【請求項４】
前記第１および第２の情報に基づいて前記少なくとも１つのフィードバック・パラメータを形成するステップを含み、前記少なくとも１つのフィードバック・パラメータを形成するステップは、前記少なくとも１つのメディア・クライアントが使用可能な最大レート、前記無線ネットワーク内の少なくとも１つのエンティティ内にバッファリングされる前記少なくとも１つのメディア・クライアントに属するデータ量、少なくとも１つの前のフィードバック間隔にわたって配信された前記少なくとも１つのメディア・クライアントのそれぞれに関連するパケットの数、及び、前記少なくとも１つのメディア・クライアントによって提供された少なくとも１つの制御パケットの内容、のうちの少なくとも１つを示す情報を形成するステップを含む、請求項１に記載の方法。
【請求項５】
前記少なくとも１つのフィードバック・パラメータを提供するステップは、前記メディア・サーバに少なくとも１つの制御パケットを提供するステップを含む、請求項１に記載の方法。
【請求項６】
メディア・サーバと、無線ネットワークと、前記無線ネットワークとの少なくとも１つのエア・インターフェースに関連する少なくとも１つのメディア・クライアントとが関与する方法であって、
前記メディア・サーバで少なくとも１つのフィードバック・パラメータを受信するステップを含み、前記少なくとも１つのフィードバック・パラメータは、前記少なくとも１つのメディア・クライアントによって提供される、前記少なくとも１つのメディア・クライアントの少なくとも１つの状態を示す第１の情報と、前記無線ネットワークによって提供される、前記少なくとも１つのエア・インターフェースに関連するリソースを示す第２の情報とに基づいて形成され、さらに、
前記少なくとも１つのフィードバック・パラメータに基づいて決定されたレートで少なくとも１つのパケットを提供するステップとを含む、方法。
【請求項７】
前記第１の情報に基づいて形成された前記少なくとも１つのフィードバック・パラメータを受信するステップは、前記少なくとも１つのメディア・クライアントへのパケット配信率、前記少なくとも１つのメディア・クライアントに関連するパケットロス率、前記少なくとも１つのメディア・クライアント内の使用可能なバッファ空間、及び、前記少なくとも１つのメディア・クライアント内のバッファ・オーバーフローまたはアンダフローの期待時間、のうちの少なくとも１つを示す第１の情報に基づいて形成された前記少なくとも１つのフィードバック・パラメータを受信するステップを含む、請求項６に記載の方法。
【請求項８】
前記第２の情報に基づいて形成された前記少なくとも１つのフィードバック・パラメータを受信するステップは、無線ネットワーク・エンティティのバッファ・レベル、少なくとも１つの無線ネットワーク・エンティティによって提示された負荷、前記少なくとも１つのメディア・クライアントに関連する前記少なくとも１つのエア・インターフェースのダウンリンク帯域幅を共有するユーザの数、及び、前記少なくとも１つのメディア・クライアントのそれぞれが使用可能な前記少なくとも１つのエア・インターフェースの帯域幅の一部分、のうちの少なくとも１つを示す第２の情報に基づいて形成された前記少なくとも１つのフィードバック・パラメータを受信するステップを含む、請求項６に記載の方法。
【請求項９】
前記少なくとも１つのフィードバック・パラメータを受信するステップは、前記無線ネットワークに関連する最大レート、前記無線ネットワーク内の少なくとも１つのエンティティ内にバッファリングされる前記少なくとも１つのメディア・クライアントに属するデータ量、少なくとも１つの前のフィードバック間隔にわたって配信された前記少なくとも１つのメディア・クライアントのそれぞれに関連するパケットの数、前記少なくとも１つのメディア・クライアントに配信された最後のパケットに関連するタイムスタンプまたはシーケンス番号、及び、前記少なくとも１つのメディア・クライアントによって提供された少なくとも１つの制御パケットの内容、のうちの少なくとも１つを示す情報を受信するステップを含む、請求項６に記載の方法。
【請求項１０】
前記少なくとも１つのパケットを提供するステップは、前記決定されたレートに従って少なくとも１つの可変ビットレート・データ・ストリームにレート・シェーピングを適用するステップを含む、請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、通信システムに関し、より詳細には、無線通信システムに関する。
【背景技術】
【０００２】
無線通信ネットワーク上のメディア・サービス（たとえば音楽、ビデオ）のストリーミングは、普及しており、近い将来、無線サービス・プロバイダにとって商業上重要となる可能性が高い。その成功の妨げになる主な障害は、これらのサービスに関連するオーディオまたはビデオ品質がしばしば低く、かつ／または信頼できないことである。無線通信ネットワークを介して送信されたパケットは、失われ、遅延され、またはジッタを伴うことがある。たとえば、環境の変化、および複数ユーザの間で無線アクセス・メディアを共有する必要性により信号強度が変動すると、メディア・ストリームを運ぶパケットをモバイル装置および／またはメディア・プレーヤーなどのモバイル装置上で実行されるアプリケーションに配信するレートが大きく変動することになる。パケットは、メディア・サーバからクライアントへとエア・インターフェースを横断する間に失われることもあり、それによってメディア・サービスの中断、および／またはメディア・サービスの品質の劣化がもたらされ得る。従来のメディア・セッションは、失われたパケット、遅延されたパケット、および／または受信されたデータ・ストリームのバッファリングによるジッタの影響を低減しようと試みる。
【０００３】
図１は、無線ネットワーク１０５上でメディアをストリーミングするための従来型システム１００の例示的な一実施形態を概念的に示している。図示された実施形態では、システム１００は、モバイル装置や、モバイル装置上で実行されたアプリケーションなど、少なくとも１つのクライアント１１５に無線ネットワーク１０５上でメディアをストリーミングするメディア・サーバ１１０を含む。メディア・サーバ１１０は、クライアント１１５にストリーミングされるメディアを表す信号を符号化するメディア・エンコーダ１２０を含む。メディア・エンコーダ１２０は、以下符号化レートと呼ばれる１つまたは複数の平均ビットレートでストリーミング・メディアを符号化することができる。一般に、所与のメディアでは、より高い符号化レートは、エンドユーザから見てより良いメディア品質に関連する。さらに、所与の符号化レート（エンコーダの出力の平均ビットレートを指す）の場合でも、エンコーダの出力の実際のビットレートは、対応するメディア・コンテンツに依存して時間と共に大きく変化することがある。たとえば、比較的に高いビットレートは、かなりの動きを含んでおり、または高度の詳細を有している画像シーケンス時に観察され得るが、比較的に低いビットレートは、静止画像時に観察され得る。
【０００４】
プロット１２５（１〜ｎ）は、それぞれ異なる符号化レートについて、メディア・エンコーダ１２０の出力の累積符号化バイト（垂直軸、任意単位）を時間（水平軸、任意単位）の関数として示している。符号化レートは、対応するプロットの平均傾斜に対応する。プロット１２５（１〜ｎ）は、メディア・エンコーダ１２０が出力することができる様々な符号化レートの差を明らかに指し示している。さらに、プロット１２５（１〜ｎ）で示されるように、各符号化レートについて、時間の関数として、対応する曲線の傾斜によって表されたメディア・エンコーダ１２０の出力の瞬間ビットレートは、時間と共に大きく変化することが見て分かる。上記に説明されたように、ビデオ・ストリームの画像が、動いており、または高度の詳細を有している領域の比較的大きい割合を含む場合、メディア・エンコーダ１２０の出力のバイト数は増加し、高い（瞬間）ビットレートがもたらされ得る。しかし、ビデオ・ストリームの画像が、動いており、または高度の詳細を有している領域の割合が減少するように変化する場合、メディア・エンコーダ１２０の出力のバイト数は減少し、低い（瞬間）ビットレートがもたらされ得る。したがって、メディア・サーバ１１０は、プロット１３５によって示されるようにほぼ一定の単位時間当たり送信バイト数を無線ネットワーク１０５に提供するためのレート・シェーピング要素１３０を含んでもよい。
【０００５】
無線ネットワーク１０５は一般に、エア・インターフェースを介してクライアント１１５に送信されるパケットのスケジューリング、ならびに適応変調、バケットの符号化、および自動再送要求機能を実施する。しかし、上記に論じられたように、無線ネットワーク１０５によって送信されたパケットは、失われ、遅延され、かつ／またはジッタを伴い得る。したがって、クライアント１１５に提供される単位時間当たりバイト数は、プロット１４０によって示されるように、時間と共に変化し得る。図示された実施形態では、クライアント１１５は、失われたパケット、遅延されたパケット、および／またはジッタを伴うパケットの到着時間の保証を試みるために、デジッタ・バッファ１４５とプレデコーダ・バッファ１５０とを含む。たとえば、クライアント１１５によって受信されたパケットは、デジッタ・バッファ１４５内に格納され、次いで、プロット１５５で示されるように、ほぼ一定の単位時間当たりバイト数でデジッタ・バッファ１４５から押し出されてもよい。プレデコーダ・バッファ１５０は、デジッタ・バッファ１４５によって提供されたデータ・ストリームを受信し、プロット１６５で示されるように、受信されたパケットを所望の単位時間当たりバイト数でメディア・デコーダ１６０に提供してもよい。
【０００６】
メディア・サーバ１１０およびクライアント１１５は、矢印１７０によって示されるように、クライアント１１５がメディア・サーバ１１０に間欠的なフィードバックを送信することを可能にする組込み型の特徴を含む。フィードバック１７０は一般に、パケットが送信されているレート、パケットの損失、使用可能なバッファ空間など、エンドツーエンドの性能メトリックをメディア・サーバ１１０に通知する。エンドツーエンド性能メトリックは、ソース符号化レートおよび／または伝送速度を制御するために、メディア・サーバ１１０にローカルの情報と共に使用される。しかし、エンドツーエンド性能メトリックは、クライアント１１５によって受信されたデータ・ストリームから推定され得る情報を提供するにすぎない。さらに、少なくとも一部には、ストリーミング・メディア・セッションに使用可能な制限されたアップリンク帯域幅で送信しなければならないオーバーヘッドを減少させるという目的のために、クライアント１１５は一般に、比較的長い時間尺度で、たとえば３秒〜５秒ごとにフィードバック１７０を提供する。
【０００７】
ネットワーク状態および／または競合ユーザの影響についての直接的な知識が欠如していること、ならびに長い時間尺度によって、フィードバック１７０の有用性が制限される。たとえば、無線ネットワーク１０５は一般に、チャネル品質の速い（たとえばミリ秒の尺度の）変化によってもたらされるマルチユーザ・ダイバーシチを活用するために、無線リンクを介した速いチャネル品質フィードバックに基づいてスケジューリングおよびレート適応技術を実施する。これらの技術によって、所与のメディア・セッションについて、無線リンクにわたって達成されるレートが著しく変化することになり、またフィードバック１７０は、サポートされた伝送速度の速い変化にメディア・サーバ１１０が有効に応答するのに役立つほど頻繁にはメディア・サーバ１１０に提供されない。その結果、従来のメディア・サーバ１１０は、エア・インターフェースを介した伝送速度が迅速に変化する状況では、可能な最良のメディア品質を提供することができない。さらに、フィードバック１７０は、ネットワーク状態、および共有された帯域幅を求めて争うユーザについての直接的な知識を提供する情報を含まず、それによって、サーバ１１０がこれらのイベントを回避するための積極的な措置を講じるのに役立ち得るバッファ・オーバーフローおよびアンダフロー予測のより精緻な方法をメディア・サーバ１１０が使用する可能性がなくなる。
【０００８】
メディア・サーバ１１０が比較的遅いエンドツーエンド・フィードバック１７０に基づいてしか伝送速度をシェーピングすることができないので、無線ネットワーク１０５上のメディアのストリーミングに使用可能なリソースは、最適または効率的なやり方では使用され得ない。たとえば、メディア・サーバ１１０は一般に、フィードバック１７０に基づいて伝送速度を選択する。選択された伝送速度は、比較的長い期間をかけて無線ネットワーク１０５の状態を平均する効果を反映し得る。しかし、所与の任意の瞬間に無線ネットワーク１０５によってサポートされる実際の伝送速度は、この平均速度から大きく異なり、リソースの非能率的な使用をもたらし得る。この平均値を使用して、このレートでのパケット送信の期間の間に持続し得ない高いメディア・ソース符号化レートを選択する場合には、パケット損失が生じ、許容不可能なメディア品質がもたらされることがあり、また、他のユーザまたはセッションのダウンリンク・リソース使用可能性が不所望にも減少することがある。もう一方で、より低いソース・レートを選択すると、無線ネットワークがより高い伝送速度をサポートし得る期間の間、使用可能なリソースを十分に活用し得ないことがある。使用可能なリソースを十分に活用し得ないということは、現行の条件下（ｐｒｅｖａｉｌｉｎｇ  ｃｏｎｄｉｔｉｏｎ）で可能な最良の品質レベルより下のレベルでメディアを配信することを意味し得る。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】ＩＥＴＦ  ＲＦＣ  １８８９
【非特許文献２】ＩＥＴＦ  ＲＦＣ  ２３２６
【非特許文献３】ＩＥＴＦ  ＲＦＣ  ３４４８
【発明の概要】
【課題を解決するための手段】
【００１０】
本発明は、上記で述べた諸問題のうちの１つまたは複数の影響に対処することを対象とする。下記は、本発明のいくつかの態様についての基本的な理解を促すために、本発明の簡略化された要約を提示している。この要約は、本発明を網羅的に概観するものではない。それは、本発明の重要なまたは重大な要素を識別するものでも、本発明の範囲を定めるものでもない。その唯一の目的は、以下で論じられるより詳細な説明の序文として、いくつかの概念を簡略化された形で提示することである。
【００１１】
本発明の一実施形態では、メディア・サーバと、無線ネットワークと、無線ネットワークとの少なくとも１つのエア・インターフェースに関連する少なくとも１つのメディア・クライアントとが関与する方法が提供される。この方法は、少なくとも１つのメディア・クライアントの少なくとも１つの状態を示す第１の情報にアクセスするステップを含む。第１の情報は、少なくとも１つのメディア・クライアントによって提供される。この方法は、少なくとも１つのエア・インターフェースに関連するリソースを示す第２の情報にアクセスするステップをも含む。第２の情報は、無線ネットワークによって提供される。この方法はさらに、メディア・サーバに少なくとも１つのフィードバック・パラメータを提供するステップを含む。少なくとも１つのフィードバック・パラメータは、第１および第２の情報に基づいて形成される。
【００１２】
本発明の別の実施形態では、メディア・サーバと、無線ネットワークと、無線ネットワークとの少なくとも１つのエア・インターフェースに関連する少なくとも１つのメディア・クライアントとが関与する方法が提供される。この方法は、メディア・サーバで少なくとも１つのフィードバック・パラメータを受信することを含む。少なくとも１つのフィードバック・パラメータは、少なくとも１つのメディア・クライアントの少なくとも１つの状態を示す第１の情報、および少なくとも１つのエア・インターフェースに関連するリソースを示す第２の情報に基づいて形成される。第１の情報は、少なくとも１つのメディア・クライアントによって提供され、第２の情報は、無線ネットワークによって提供される。この方法は、少なくとも１つのフィードバック・パラメータに基づいて決定されたレートで少なくとも１つのパケットを提供することをも含む。
【００１３】
本発明は、以下の説明を添付の図面と併せて参照することによって理解することができる。図面では、同じ参照符号は、同様の要素を識別する。
【図面の簡単な説明】
【００１４】
【図１】無線ネットワーク上でメディアをストリーミングするための従来のシステムの例示的な一実施形態を概念的に示す図である。
【図２】本発明による、無線ネットワーク上でメディアをストリーミングするためのシステムの第１の例示的な実施形態を概念的に示す図である。
【図３】本発明による、無線ネットワーク上でメディアをストリーミングするためのシステムの第２の例示的な実施形態を概念的に示す図である。
【発明を実施するための形態】
【００１５】
本発明は、様々な修正および代替形態が可能であるが、その特定の実施形態について、例示するために図面に示されており、本明細書で詳細に述べられる。しかし、特定の実施形態について本明細書で述べることは、本発明を開示された特定の形に限定するものではなく、その逆に、添付の特許請求の範囲に定められた本発明の範囲内に含まれるすべての修正物、等価物および代替物を網羅するものであることを理解されたい。
【００１６】
本発明の例示的な実施形態について以下に述べられる。分かり易くするために、本明細書では、実際の実装形態のすべての特徴について述べられているとは限らない。もちろん、いずれかのこうした実際の実施形態の開発においては、開発者の特定の目標を達成するために、実装形態によって異なるシステム関連およびビジネス関連の制約の遵守など、実装特有の複数の決定が行われるべきであることが理解されよう。さらに、こうした開発努力は複雑で、多大な時間を要するものであり得るが、しかし、本開示の利益を得る当業者にとっては日常的な仕事であることが理解されよう。
【００１７】
本発明および対応する詳細な説明の一部は、コンピュータ・メモリ内のデータ・ビットに対する操作のソフトウェア、またはアルゴリズムおよび記号表現に関して提示されている。これらの説明および表現は、当業者がその仕事の内容を他の当業者に有効に伝えるためのものである。アルゴリズムは、その用語が本明細書で用いられる場合、また一般的に用いられる場合、所望の結果をもたらす自己一貫性のある一連のステップと考えられる。諸ステップは、物理量の物理的な操作を必要とするステップである。必ずしも必要ではないが、通常、これらの量は、格納され、転送され、組み合わされ、比較され、他のやり方で操作することができる光学的、電気的または磁気的信号の形を取る。主として一般的に使用するために、これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶことが時として都合であることが分かっている。
【００１８】
しかし、これらのおよび類似の用語はすべて、適切な物理量と関連付けられるものであり、これらの量に適用された便宜的なラベルにすぎないことに留意されたい。他に特に述べられていない限り、あるいは議論から明らかであるように、「処理する（ｐｒｏｃｅｓｓｉｎｇ）」、「コンピュータ処理する（ｃｏｍｐｕｔｉｎｇ）」、「計算する（ｃａｌｃｕｌａｔｉｎｇ）」、「判断する（ｄｅｔｅｒｍｉｎｉｎｇ）」または「表示する（ｄｉｓｐｌａｙｉｎｇ）」などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理、電子量として表されたデータを操作し、コンピュータ・システム・メモリまたはレジスタ、あるいは他のこうした情報記憶、伝送または表示装置内の物理量として同様に表された他のデータに変換するコンピュータ・システムまたは類似の電子コンピューティング装置の動作およびプロセスを指す。
【００１９】
ソフトウェアで実施される本発明の諸態様は一般に、何らかの形のプログラム記憶媒体内で符号化され、または何らかのタイプの伝送媒体を介して実施されることにも留意されたい。プログラム記憶媒体は、磁気的（たとえばフロッピー・ディスクやハード・ドライブ）であっても、光学的（たとえばコンパクト・ディスク読出し専用メモリ、すなわち「ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ  ｄｉｓｋ  ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ」）であってもよく、また読出し専用であっても、ランダム・アクセス型であってもよい。同様に、伝送媒体は、ツイストペア線、同軸ケーブル、光ファイバ、または当技術分野で知られている他の何らかの適切な伝送媒体とすることができる。本発明は、所与のいずれかの実装のこれらの態様によって限定されるものではない。
【００２０】
次に、本発明について、添付の図面を参照して述べられる。様々な構造、システムおよび装置が、説明するためだけに、また本発明の当業者によく知られている詳細で本発明を不明瞭にしないように、図面に概略的に示されている。しかし、添付の図面は、本発明の例示的な実施例について述べ説明するために含まれている。本明細書で使用される単語および語句は、当業者によるそれらの単語および語句の理解に一致する意味を有するものと理解し解釈すべきである。用語または語句の特別な定義、すなわち、当業者によって理解される通常の慣例的な意味とは異なる定義を、本明細書中で用語または語句を一貫して使用することによって暗示することは意図されていない。用語または語句が特別な意味、すなわち当業者によって理解されている以外の意味を有することが意図される限りでは、こうした特別な定義は、その用語または語句についての特別な定義を直接かつ明確に提供する定義のやり方で本明細書に明示的に述べるものである。
【００２１】
図２は、無線ネットワーク２０５上でメディアをストリーミングするためのシステム２００の第１の例示的な実施形態を概念的に示している。図示された実施形態では、システム２００は、モバイル装置や、モバイル装置で実行されるアプリケーションなど、少なくとも１つのクライアント２１５に無線ネットワーク２０５上でメディアをストリーミングするメディア・サーバ２１０を含む。無線ネットワーク２０５、メディア・サーバ２１０およびクライアント２１５は、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）規格および／またはプロトコルに従って動作してもよい。たとえば、メディア・セッションをストリーミングする際、メディア・コンテンツを運ぶのにリアルタイム・トランスポート・プロトコル（ＲＴＰ：Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）が使用されてもよく、関連する制御パケットを運ぶのに関連するリアルタイム制御プロトコル（ＲＴＣＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）が使用されてもよい。第３のプロトコル、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）は、セッション設定（能力の交換を含む）、分解および何らかのユーザ動作（たとえば休止、早送りなど）のためのメッセージの伝送に使用されてもよい。ＲＴＰ／ＲＴＣＰおよびＲＴＳＰに関する詳細は、インターネット技術特別調査委員会のコメント要求（ＩＥＴＦ  ＲＦＣ：Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）１８８９および２３２６にそれぞれ見ることができる。しかし、本開示の利益を有する当業者には、第１の例示的な実施形態は例を示すためのものであり、本発明はこれらの規格および／またはプロトコルに限定されないことを理解されたい。
【００２２】
メディア・サーバ２１０は、クライアント２１５にストリーミングされるメディアを表す信号を符号化するメディア・エンコーダ２２０を含む。メディア・エンコーダ２２０は、１つまたは複数の符号化レートでメディアを配信することができる。また上記に述べられたように、各符号化レートについて、メディア・エンコーダ２２０の出力の実際の瞬間ビットレートは、メディア・コンテンツに依存して時間と共に変化する。符号化されたデータ・ストリームは、オーディオ、ビデオ、その組合せ、または他の所望のメディアを表すために使用され得る情報を含む。代替の一実施形態では、メディア・サーバ２１０は、メディア・エンコーダ２２０を含まない。そうではなく、メディア・エンコーダ２２０は、おそらく異なる（符号化）レートでメディアを符号化する別個の装置である。メディア・サーバ２１０は、メディア・エンコーダ２２０によって生成された符号化メディア出力をそれぞれ異なるファイルに格納し、対応するメディア・セッションの間、格納された符号化メディア・ファイルから読み出すことによってメディアをクライアント装置にストリーミングする。
【００２３】
プロット２２５（１〜ｎ）は、それぞれ異なる符号化レートについて、メディア・エンコーダ２２０の出力の累積符号化バイト（垂直軸、任意単位）を時間（水平軸、任意単位）の関数として示している。プロット２２５（１〜ｎ）に示されるように、各プロットでは、対応するプロットの傾斜に対応する実際の（瞬間）ビットレートは、時間と共に変化する。たとえば、対応するビデオ・ストリームの画像が、動いており、または高度の詳細を有している領域の比較的大きい割合を含む場合、メディア・エンコーダ２２０の出力の瞬間ビットレートは高くなり得る。しかし、ビデオ・ストリームの画像が、動いており、または高度の詳細を有している領域の割合が減少するように変化する場合、メディア・エンコーダ２２０の出力の瞬間ビットレートは低くなり得る。したがって、メディア・サーバ２１０は、プロット２３５によって示されるように、ほぼ一定の出力ストリームを無線ネットワーク２０５に提供するためのレート・シェーピング要素２３０を含んでもよい。レート・シェーピング要素２３０によって使用される目標伝送速度は、下記に論じられるように、無線ネットワーク２０５および／またはクライアント２１５からのフィードバックに基づいて選択されてもよい。
【００２４】
第１の例示的な実施形態では、クライアント２１５は、失われたパケット、遅延されたパケット、および／またはジッタを伴うパケットの到着時間の保証を試みるために、デジッタ・バッファ２３５とプレデコーダ・バッファ２４０とを含む。たとえば、クライアント２１５によって受信されたパケットは、デジッタ・バッファ２３５内に格納され、次いで、プロット２４５で示されるように、ほぼ一定の単位時間当たりバイト数でデジッタ・バッファ２４０から押し出される。プレデコーダ・バッファ２４０は、デジッタ・バッファ２３５によって提供されるデータ・ストリームを受信し、プロット２５５で示されるように、受信されたパケットを所望の単位時間当たりバイト数でメディア・デコーダ２５０に提供してもよい。しかし、クライアントの第１の例示的な実施形態は、例を示すためのものであり、クライアント２１５の代替実施形態は、厳密に同じ数および／または構造のバッファ２３５、２４０を含まなくてもよいことを、本開示の利益を得る当業者には理解されたい。
【００２５】
無線通信システム２００は、シグナリング・プロキシ２６０を含む。一実施形態では、シグナリング・プロキシ２６０は、３ＧＰＰユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）規格に指定されたゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ：Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）、および／または３ＧＰＰ２  ｃｄｍａ２０００規格に指定されたパケット・データ・サービス・ノード（ＰＤＳＮ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｓｅｒｖｉｎｇ  Ｎｏｄｅ）など、無線ネットワーク２０５内の無線アクセス・ネットワーク・エンティティに接続されてもよい。しかし、本発明の他の実施形態では、サービスＧＰＲＳサポート・ノード（ＳＧＳＮ：Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）、無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）など、他のアクセス・ネットワーク・エンティティに、あるいはフラット・アーキテクチャ（たとえばＲＮＣ、ＳＧＳＮおよびＧＧＳＮによって対処される複数の機能性が、唯一のエンティティ、基地局ルータ内にまとめられる）によって特徴付けられる基地局ルータを含むアクセス・ネットワークの場合には基地局自体に、シグナリング・プロキシを接続することが可能である、シグナリング・プロキシ２６０は、ソフトウェア、ファームウェア、ハードウェアまたはその任意の組合せで実装されてもよい。
【００２６】
シグナリング・プロキシ２６０は、クライアント２１５からフィードバック２６５を受信する。一実施形態では、クライアント２１５からのフィードバック２６５は、クライアント２１５の現在のセッション状態を示す。たとえば、シグナリング・プロキシ２６０は、ＲＴＣＰおよびＲＴＳＰのメッセージの流れに介入してもよい。セッション設定および分解の間、ならびにセッションの寿命の間、通常はメディア・サーバ２１０に直接向かうクライアント２１５によって生成された制御メッセージ（たとえばメディア・セッションに関連するＲＴＣＰおよびＲＴＳＰメッセージ）は、そうではなく、シグナリング・プロキシ２６０に提供される。これらのメッセージは、シグナリング・プロキシ２６０がユーザ動作ならびにクライアント２１５の状態（たとえばバッファ内容、オーバーフロー／アンダフローの期待時間など）を追跡するのに役立ち得る。一実施形態では、メディア・コンテンツを運ぶＲＴＰパケットは、メディア・サーバ２１０からクライアント２１５に直接流れてもよい。
【００２７】
シグナリング・プロキシ２６０は、無線ネットワーク２０５からもフィードバック２７０を受信する。一実施形態では、無線ネットワーク２０５からのフィードバック２７０は、無線ネットワーク２０５とクライアント２１５の間のエア・インターフェースに関連するリソースを示す。たとえば、シグナリング・プロキシ２６０は、無線ネットワーク制御装置上で一般性を失わずに実装され得る送信側無線リンク制御プロトコル・ハンドラから、ＲＡＮプロキシ制御パケットの形で速いフィードバック２７０を受信してもよい。基地局ルータを備えた無線アクセス・ネットワークの場合には、シグナリング・プロキシ２６０は、これらのルータに接続されてもよく、バッファ・レベル、使用可能な帯域幅、競合ユーザの数などに関する情報は、ローカルに使用可能である。フィードバック２７０は、シグナリング・プロキシ２６０に、ＲＮＣのバッファ・レベル、メディア・セッションとダウンリンク帯域幅を共有するユーザの数、各ユーザが使用可能な帯域幅など、無線ネットワーク２０５内のエンティティから使用可能な詳細なシステム情報およびシステム・ビューについて知らせる。
【００２８】
様々な代替実施形態では、フィードバック２６５、２７０は、周期的に提供されてもよく、かつ／または特定のイベントによってトリガされてもよい。たとえば、無線ネットワーク２０５は、信号対干渉雑音比が特定の閾値未満に下がり、または特定の閾値より高くなるなど、リンク品質メトリックの変化を検出することに応答してフィードバック２７０を提供してもよい。別の例では、無線ネットワーク２０５は、バッファ・レベルの増加または減少の検出に応答してフィードバック２７０を提供してもよい。
【００２９】
シグナリング・プロキシ２６０は、矢印２７５によって示されるようにメディア・サーバ２１０に提供され得る制御情報を形成するために、フィードバック２６５、２７０を使用する。一実施形態では、シグナリング・プロキシ２６０は、メディア・サーバ２１５に知らされる１組のフィードバック・パラメータを生成するために、それぞれクライアント２１５から、および無線ネットワーク２０５内の１つまたは複数の送信側無線リンク制御プロトコル・エンティティからのフィードバック２６５、２７０の情報を使用する。一実施形態では、フィードバック・パラメータは、プロキシ・サーバ制御パケット内に含まれ、このプロキシ・サーバ制御パケットは、既存のメディア・サーバおよびサポート基盤への変更を最小限に抑えるための適切な拡張を伴って、既存のプロトコル（たとえばＲＴＣＰ）を使用して運ばれ得る。フィードバック・パラメータは、クライアント２１５上、および無線ネットワーク２０５上の状態についてのメディア・サーバ２１０の知識を向上させ得る。一実施形態では、シグナリング・プロキシ２６０によって送信される制御パケットは、それがこの時点では１つまたは複数の追加のパラメータ、たとえば無線ネットワーク２０５内で現在維持され得る（対応するメディア・セッションの）最大レート、ＲＮＣでバッファリングされるクライアント２１５に属するデータ量、以前のフィードバック間隔の間にクライアント２１５に配信された、クライアント２１５に属するＲＴＰパケットの数などを含む点を除いては、まさにクライアント２１５によって生成された制御パケットのように見える。プロキシ・サーバ制御パケットの内容の残りは、ＲＴＰ−ＲＴＣＰプロトコルまたは独自開発プロトコルに基づく既存の最先端の設定に対応するように保存されてもよい。
【００３０】
図示された実施形態では、シグナリング・プロキシ２６０は、無線ネットワーク２０５に、かつ／または有線接続によってメディア・サーバ２１０に結合され得る。シグナリング・プロキシ２６０とメディア・サーバ２１０の間の帯域幅制約は、シグナリング・プロキシ２６０がネットワーク２０５の高帯域の有線側でホストされる場合、（クライアント・サーバ・チャネルと比べて）遥かに弱い。したがって、シグナリング・プロキシ２６０は、クライアント２１５とメディア・サーバ２１０がエア・インターフェースを介して制御パケットを直接交換するならば可能であろうレートよりも著しく高いレートでメディア・サーバ２１０にその制御（フィードバック）パケットを送信することができる。これは、最先端技術にまさる明らかな利点であり、下記に説明されるように、メディア接続の品質に直接的かつ肯定的な影響を及ぼし得る。
【００３１】
一実施形態では、ダウンリンク方向で、メディア・サーバ２１０によって送信されたＲＴＣＰおよびＲＴＳＰメッセージなど制御情報がシグナリング・プロキシ２６０に渡されてもよく、次いで、このシグナリング・プロキシ２６０は、必要であれば適切な変更を行ってクライアント装置２１５にそれを転送してもよい。この構成は、シグナリング・プロキシ２６０が、クライアント２１５とサーバ２１０の間で交渉されたセッション・パラメータを決定し、そのそれぞれの観点から見て期待されるサービス特性が何であるか認識するのに役立つ。
【００３２】
メディア・クライアントから直接にフィードバック情報を得る能力は、エアリンク状態およびＲＮＣから提示された負荷についての現在の包括的な知識と相まって、プロキシ２６０を、ユーザによって知覚されるエンドツーエンド・メディア転送の品質に知的に影響を及ぼす独特な立場に置く。確かに、クライアント２１５から受信される情報、ならびに無線ネットワーク２０５から受信される情報を使用することによって、シグナリング・プロキシ２６０は、メディア・サーバ２１０が異なるレートでストリームを送信する場合のバッファ・オーバーフローおよびアンダフローの可能性についてメディア・サーバ２１０が正確な予測を行うのを助ける適切な立場にいることになる。
【００３３】
図３は、無線ネットワーク上でメディアをストリーミングするためのシステム３００の第２の例示的な実施形態を概念的に示している。図示された実施形態では、上記説明に一致して、メディア・サーバ３１５とメディア・クライアント３１０の間のネットワーク全体は、無線ネットワークと呼ばれる。メディア・サーバ３１５とネットワーク要素ＧＧＳＮ  ３２０の間に位置するネットワーク・セグメントは、コア・ネットワーク３０５と呼ばれ、ＧＧＳＮ  ３２０で開始して、メディア・クライアント３１０で終了するネットワーク・セグメントは、無線アクセス・ネットワーク３２７と呼ばれる。図示された実施形態では、１つまたは複数の基地局３０７を含む無線アクセス・ネットワーク３２７は、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）（３ＧＰＰ）規格に基づく。しかし、本明細書に述べられた諸技術は、他の任意の無線ネットワーキング技術および規格、たとえばｃｄｍａ２０００高レート・パケット・データ（ＨＲＰＤ：Ｈｉｇｈ  Ｒａｔｅ  Ｐａｃｋｅｔ  Ｄａｔａ）やＩＥＥＥ  ８０２．１６ｅ／ＷｉＭＡＸに適用することもできる。たとえば、ｃｄｍａ２０００  ＨＲＰＤの場合、システム３００は、サービスＧＰＲＳサポート・ノード（ＳＧＳＮ：Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）３０３とゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）３２０のノード対が、パケット・データ・サービス・ノード（ＰＤＳＮ）として知られている単一のエンティティで置き換えられるという点を除いて、図３のそれと同一に見える。さらに、階層アーキテクチャが示されているが、本明細書に述べられた諸技術は、レイヤ３ルーティング（すなわちＩＰ）および、無線アクセス・ネットワークに関する制御機能が基地局によって実施されるフラット−インターネット・プロトコル（フラットＩＰ）ベースのアーキテクチャに適用することもできる。
【００３４】
図示された実施形態では、モバイル・クライアント３１０は、無線ネットワーク３００上のメディア・サーバ３１５とのストリーミング・ビデオ・セッションを開始する。たとえば、クライアント３１０は、サーバ３１５にＲＴＳＰメッセージを送信することによりストリーミング・ビデオ・セッションを要求してもよい。このメッセージがＧＧＳＮ  ３２０に達するとき、ＧＧＳＮ  ３２０は、サーバ３１５にではなく、シグナリング・プロキシ３２５にそれを転送する。プロキシ３２５は、このメッセージを検査し、それが新しいストリーミング・ビデオ・セッションの開始であり得ることを認識し、そのローカル・キャッシュへのエントリを行う。次いで、それは、サーバ３１５にメッセージを転送する。サーバ３１５は、メッセージに応答し、「能力交換」を実行するためにクライアント３１０とサーバ３１５によって交換された後続のＲＴＳＰメッセージもまた、シグナリング・プロキシ３２５を介してルーティングされる。これによって、プロキシ３２５は、クライアント３１０およびサーバ３１５によって同意された関連セッション・パラメータ（たとえば帯域幅、バッファ・サイズなど）を発見することができる。能力交換が、クライアント３１０がサーバ３１５にその受信者レポート（ｒｅｃｅｉｖｅｒ  ｒｅｐｏｒｔ）を送信するレートまたは時間間隔を含む場合、プロキシ３２５は、プロキシによって決定された適切な時間間隔またはレートでサーバ３１５がフィードバックを受信する準備が整うように、対応するメッセージをサーバ３１５に転送するときにこのパラメータを修正する。規則的なレポート間隔に加えて、特定の条件（たとえば持続可能なレート、またはＲＮＣのバッファ状況の変化）下で、プロキシ３２５は、サーバ３１５にフィードバック・レポートを自律的に送信することを選択することもできることに留意されたい。この修正によって、プロキシ３２５は、クライアント３１０がより低いレートでそのレポート（プロキシ３２５によってインターセプトされる）を送信することを可能にしながら、（プロキシ３２５とサーバ３１５の間で使用可能な豊富な帯域幅に一致する）遥かに高いレートでサーバ３１５にレポートを送信することができる。
【００３５】
サーバ３１５との能力交換の後、クライアント３１０は、ダウンリンク上で所望のサービス品質を有するストリーミング・ビデオ・セッションを運ぶために、パケット・データ・プロトコル（ＰＤＰ：Ｐａｃｋｅｔ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）コンテキストおよび無線アクセス・ベアラ（ＲＡＢ：Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｂｅａｒｅｒ）の確立を開始する。ＲＡＢおよび対応する無線ベアラ（ＲＢ：Ｒａｄｉｏ  Ｂｅａｒｅｒ）が設定されたとき、無線ネットワーク制御装置（ＲＮＣ）３３０は、イベントについてシグナリング・プロキシ３２５に通知する。プロキシ３２５は、対応するストリーミング・ビデオ・セッション用のキャッシュ内に既にエントリを有している場合、セッションの持続可能なレート、バッファ占有率などについての周期的なフィードバックを（プロキシ３２５に）送信するようにＲＮＣ  ３３０に指示する肯定的な表示で応答する。少なくとも、このフィードバックは、セッションの持続可能なレート（すなわち現在の条件下でセッションがストリーミングされ得る最大伝送速度）を含むべきであり、他のパラメータはオプションである。
【００３６】
この時点から、ＲＮＣ  ３３０は、ストリーミング・セッションの持続可能レート（およびおそらく、ＲＮＣ  ３３０によってそのセッションに割り当てられたバッファ内に格納されたデータ量および／または他の関連パラメータ）をシグナリング・プロキシ３２５に周期的に報告し始める。サーバ３１５がストリーミングし始めるとき、ストリーミング・セッションに関連するオーディオ／ビデオ・ペイロードを運ぶＲＴＰパケットは、ＧＧＳＮ  ３２０を介してサーバからクライアント３１０に流れ始める。一実施形態では、これらのパケットは、シグナリング・プロキシ３２５を介してルーティングされない。クライアント３１０は、文字通り「プレロール」として知られている時間量の間、これらのパケットをバッファに入れ（ｂｕｆｆｅｒ  ｕｐ）、次いで、それを復号し、それを再生し（ｐｌａｙ  ｏｕｔ）始める。このプロセスがクライアント３１０で開始するとき、クライアント３１０は、サーバ３１５に受信者レポートを送信し、受信されたデータ量、失われたデータ量、次に再生すべきパケット／フレームの識別子など、１つまたは複数のパラメータに関してサーバ３１５に通知し始める。一実施形態では、これらのレポートは、３〜５秒ごとに１回など、数秒の間隔で、やや低頻度に送信されてもよい。
【００３７】
クライアント３１０によって送信される受信者レポートは、ＲＴＣＰパケットに入れて運ばれてもよい。ＧＧＳＮ  ３２０は、アップストリーム方向で受信されたすべてのＲＴＣＰパケットをシグナリング・プロキシ３２５に転送する。プロキシ３２５は、（それがローカル・キャッシュにエントリを行った）所与のセッションの第１のこうしたパケットを受信するとき、持続可能なレートなどの追加の情報、およびおそらく、それがＲＮＣ  ３３０から受信したセッションについての他のフィードバック・パラメータなどをパケットに追加してもよく、サーバ３１５にパケットを転送する。この時点から、プロキシ３２５は。一定間隔でサーバ３１５にＲＴＣＰフィードバック・レポートを送信する。この間隔は一般に、クライアント３１０がそのＲＴＣＰレポートを送信する間隔よりも遥かに（たとえば、十分な平均化と速いフィードバックの両方を可能にする何百ミリ秒程度−約１００ｍｓ）短いことを想起されたい。プロキシ３２５が、サーバ３１０にＲＴＣＰレポートを最後に送信して以来、（ＧＧＳＮ  ３２０によってそれに転送された）クライアント・レポートを受信している場合、プロキシ３２５は、クライアント３１０によって報告されたデータ、ならびにサーバへの次のＲＴＣＰレポート内でＲＮＣ  ３３０によって提供されたフィードバックを含めてもよい。そうでない場合は、クライアント３１０は、サーバ３１５へのそのレポートに、ＲＮＣフィードバック・データだけを含む。
【００３８】
サーバ３１５は、プロキシ３２５からＲＴＣＰレポートを受信するとき、その送信（ストリーミング）速度を、レポート内に示された持続可能なレートに等しく設定する。一般にサーバ３１５は、クライアントのバッファ・レベルの推定値を維持し、この推定値に基づいて、符号化レートの増加、符号化レートの減少、または同じ符号化レートにとどまることを決定する。すなわち、サーバ３１５は、後続のフレーム用により高いビデオ符号化レートを使用すべきか、より低いビデオ符号化レートを使用すべきか、それとも同じビデオ符号化レートを使用すべきか決定する。プロキシ・レポートが、ＲＮＣ  ３３０に現在バッファリングされているデータ量を含む場合、サーバ３２５は、そのクライアント・バッファ・モデルのコンテンツ・レベル推定値を精緻化するためにこの情報を使用することができる。精緻化されたこれらの推定値は、サーバ３２５が時宜を得た（符号化）レート変更決定を行うのに役立ち、クライアント受信側で高いビデオ品質を維持しながら、潜在的なリバッファリング・イベントを回避する。クライアント・バッファ・モデルのコンテンツ・レベルを精緻化するためにレポート内の追加の情報を使用することは、（符号化）レート変更決定を行う際に使用される論理の本質を変えるものではないことに留意されたい。
【００３９】
サーバ３１５は、クライアント３１０に周期的なサーバ・レポートを、たとえばＲＴＣＰパケットに入れて送信することもできる。これらのパケットがＧＧＳＮ  ３２０に到達するとき、それらもシグナリング・プロキシ３２５に転送される。プロキシ３２５は、クライアント３１０にそれらを転送する前に、これらのパケットに関連情報を記録する。サーバ３２５によってこれらのレポートが送信されるレートが、クライアント３１０がそれらを受信すると予期するレートより高い場合、プロキシ３２５は、クライアント３１０が予期するレートに一致するレートでそれらを受信することを保証するために、これらのレポートのうちの一部を廃棄してもよい。この場合、プロキシは、クライアント３１０の期待に一致するレートでサーバ統計値を報告するために、それがクライアント３１０に転送するサーバ・レポートの内容を修正しなければならないことがある、この制御パケット・フローは、クライアント３１０および／またはサーバ３１５が適切なＲＴＳＰメッセージで分解段階を開始するまで継続してもよい。分解段階が終了するとき、プロキシ３２５は、対応するセッションについての周期的なフィードバックの送信を停止するようにＲＮＣ  ３３０に指示する。ＲＮＣ  ３３０は、指示に従い、最終的には、対応するＰＤＰコンテキスト、ＲＡＢおよび無線ベアラは分解される。
【００４０】
本明細書に述べられた諸技術の実施形態は、従来のやり方にまさる複数の利点を提供することができる。たとえば、既存のビデオ・サービス設定では、ビデオ・サーバは、クライアントによって提供されたデータを使用して、持続可能なレートを推定する。この推定は、間接的であるが、重大な誤差をしばしば含み、特に無線ネットワークに典型的な状態など、動的な動作状態においては、単純に陳腐化し得る。もう一方で、シグナリング・プロキシによって決定された持続可能なレートは、それが直接的な測定に基づくので、少なくとも部分的にはより正確であり得る。持続可能なレートの推定の精度を向上させると、サーバがデータを最適に送信することが可能になり、アクセス・ネットワーク内のパケット損失、または使用能リソースの不十分な活用の可能性が減少する。
【００４１】
さらに、既存の設定では、無線アクセス・ネットワーク上で使用可能なアップリンク帯域幅が制限されるので、クライアントがビデオ・サーバにフィードバックを送信する頻度はやや低い。たとえば、ＲＴＰ／ＲＴＣＰベースのビデオ・ストリーミング・セッションでは、クライアントがサーバに（フィードバック）レポートを５秒ごとに１回ほど送信することが一般的である。プロキシとビデオ・サーバの間にこうした帯域幅制限がないので、プロキシは、現在持続可能なレート（およびおそらく他の有用なビット数の情報）を運ぶ制御パケットを遥かに頻繁に、たとえば１００ｍｓごとに１回ほど送信することができる。これは、サーバが伝送速度を最適に変調するのに役立ち、したがって、パケットを失うリスクを冒さずにネットワーク・リソースが完全に利用される。クライアントは、無線アクセス・メディアの能力に一致するレートでレポートを生成することができる。プロキシは、これらのレポートを使用して、クライアント状態についての知識を更新する。プロキシによって（遥かに短い間隔で）生成され、サーバに送信されたレポートは、クライアント・レポートから導出された情報、ならびに現在持続可能なレートのプロキシの推定値を含む。こうした構成によって、クライアント動作がシグナリング・プロキシの存在の影響を受けず、したがって、メディア・クライアント上で実装変更が求められないことが保証され得る。
【００４２】
別の利点は、本明細書に述べられた諸技術によって、メディア・サーバが、シグナリング・プロキシによって決定されてサーバに伝えられた、推定された持続可能レートを使用することが可能となり得ることである。既存の設定では、メディア・サーバは、現在持続可能なレートの推定値を得るために、（たとえばＩＥＴＦ  ＲＦＣ  ３４４８に指定されたＴＣＰフレンドリ・レート計算アルゴリズムによって）クライアント・レポートから受信された情報を使用する。したがって、メディア・ストリーミング・サーバは、既存の最先端技術に従ってストリーミング・サーバによって計算されるストリーミング・レート値の代わりに、プロキシから周期的に受信される持続可能レートのフィードバックを単に使用することができる。サーバ機能の残り、特に、異なる符号化レートへの切換えの論理は、変更されないままであってもよい。メディア・サーバに要求される唯一の能力は、プロキシによって提供された持続可能レートの予測に基づくストリーミングまたは伝送速度で動作できることである。この能力は、サーバ実装への重大な影響はないと見込まれる。クライアント・フィードバック（たとえばＲＴＣＰ受信者レポート）用の既存の機構は、持続可能レートのフィードバック、およびプロキシからの他の関連パラメータ（それが報告されるべき場合）を運ぶようにする単純な拡張を伴って向上され得る。
【００４３】
本明細書に述べられた諸技術のさらに別の利点は、それが輻輳レベルおよび相対的な優先度などのパラメータに基づいて、それぞれ異なるセッション（ストリーミングならびに他のタイプ）対して他とは異なる扱いを行うことを可能にし、アプリケーションが柔軟かつ適切なやり方で現行の条件に適応することを可能にするということである。たとえば、ダウンリンクが輻輳している場合、シグナリング・プロキシは低優先度アプリケーションについては報告される持続可能レートを下げ、したがって、対応するサーバに低レートでストリーミングするように強制することができる。
【００４４】
上記に開示された特定の諸実施形態は、本明細書の教示の利益を得る当業者には明らかな、等価であるが異なるやり方で本発明が修正され実施され得るので、例示的なものにすぎない。さらに、添付の特許請求の範囲に示されるもの以外には、本明細書に示された構成または設計の詳細への限定は意図されていない。したがって、上記に開示された特定の諸実施形態は変更され、または修正されてもよく、またこうしたすべての変形形態は、本発明の範囲内であると見なされることが明らかである。したがって、本発明に求められた保護については、添付の特許請求の範囲において述べられる。
【図１】
2010518783.tif 000003
【図２】
2010518783.tif 000004
【図３】
2010518783.tif 000005
【国際調査報告】
2010518783.tif 000006
2010518783.tif 000007
2010518783.tif 000008