JP5053390B2

JP5053390B2 - 無線通信システムにおけるストリーミングメディアサービスのためのプロキシベースのシグナリングアーキテクチャ

Info

Publication number: JP5053390B2
Application number: JP2009549602A
Authority: JP
Inventors: バラチヤンドラン，クリシユナ; カラン，ドル; キム，ウニヨン; レゲ，キラン・エム
Original assignee: アルカテル−ルーセントユーエスエーインコーポレーテッド
Priority date: 2007-02-14
Filing date: 2008-02-11
Publication date: 2012-10-17
Anticipated expiration: 2028-02-11
Also published as: KR20090118933A; US20080192711A1; JP2010518782A; EP2122940A1; CN101611601A; EP2122940B1; WO2008100474A1; CN101611601B; US8081609B2; KR101107816B1

Description

本出願は、本明細書と同時に出願され、全文が引用により本明細書に組み込まれる米国特許出願第１１／６７４，８０２号および第１１／６７４，８４２号に関する。

本発明は、一般に通信システムに関し、より詳細には、無線通信システムに関する。

無線通信ネットワークを介したストリーミングメディアサービス（例えば音楽、ビデオ）は人気を増してきており、近い将来、無線サービスプロバイダにとって商業的に重要になる可能性がある。それらの成功の大きな障害は、これらのサービスに関連するしばしば不十分および／または信頼できないオーディオまたはビデオ品質である。無線通信ネットワークを介して送信されるパケットは、失われ、遅延し、またはジッタを受けることがある。例えば、環境の変化および無線アクセスメディアを複数のユーザ間で共有する必要性に起因する信号強度変動は、メディアストリームを搬送するパケットがモバイルユニットおよび／またはモバイルユニット上で動作するメディアプレーヤなどのアプリケーションに配信される速度の著しい変動をもたらす。パケットはまた、メディアサーバからクライアントへのエアインターフェースを通過するときに失われることがあり、それがメディアサービスの中断および／またはメディアサービスの品質の劣化を引き起こすことがある。従来のメディアセッションは、受信されたデータストリームをバッファリングすることによって、失われたパケット、遅延したパケットおよび／またはジッタの影響を低減しようと試みる。

図１は、無線ネットワークを介したストリーミングメディアのための従来のシステム１００の１つの例示的な実施形態を概念的に示す。基地局１０７と移動体クライアント１１０との間の無線リンク１０２はシステム１００の無線セグメントのみを構成する。システム１００は全体として有線セグメントならびに無線セグメントを備えるが、それは従来、無線ネットワーク１００と呼ばれる。コアネットワーク１０５がゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２０とメディアサーバ１１５との間にある。ＧＧＳＮ１２０と移動体クライアント１１０との間のネットワークセグメント（一般にＧＧＳＮ１２０および移動体クライアント１１０を含む）は、従来、無線アクセスネットワーク１２５と呼ばれる。図示の実施形態では、無線アクセスネットワーク１２５はユニバーサル移動電話システム（ＵＭＴＳ）（３ＧＰＰ）標準に基づいている。しかしながら、無線アクセスネットワーク１２５は、他の無線ネットワーキング技術および標準、例えば、ｃｄｍａ２０００ハイレートパケットデータ（ＨＲＰＤ）またはＩＥＥＥ８０２．１６ｅ／ＷｉＭＡＸにも従って動作することもできる。ｃｄｍａ２０００ＨＲＰＤの場合、例えば、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１０３とゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２０のノードペアが、パケットデータサービングノード（ＰＤＳＮ）として知られている単一のエンティティによって置き換えられることを除いて、システム１００は図１のそれと同等と思われる。さらに、階層アーキテクチャが示されているが、無線ネットワーク１００はフラットまたは分散型インターネットプロトコル（フラットＩＰ）ベースのアーキテクチャを実装することもでき、その場合、無線アクセスネットワーク１２５に関するレイヤ３ルーティング（すなわち、ＩＰルーティング）および制御機能が、基地局１０７、無線ネットワーク制御装置（ＲＮＣ）１３０、ＳＧＳＮ１０３およびＧＧＳＮ１２０を単一のエンティティに併合する基地局ルータによって実行される。

図示の実施形態では、移動体クライアント１１０は無線ネットワーク１００を介してメディアサーバ１１５とストリーミングビデオセッションを開始することができる。例えば、クライアント１１０は、ＲＴＳＰメッセージをサーバ１１５に送信することによってストリーミングビデオセッションを要求することができる。メディアセッションを開始するために、移動体クライアント１１０は、シグナリングメッセージをメディアサーバ１１５と交換してストリーミングメディアセッションを確立し、セッションパラメータ、例えば、メディアがストリーミングされるべきビットレートなどを取り決める。移動体クライアント１１０はまた、下位レイヤのシグナリングメッセージをＲＮＣ１３０、ＳＧＳＮ１０３、およびＧＧＳＮ１２０と交換して、無線アクセスベアラチャネルを確立する。無線アクセスベアラチャネルは、例えば、ベストエフォートのベアラサービスが不十分であると見なされる場合、一般に所望のサービス品質（ＱｏＳ）特性を維持するように構成される。無線アクセスベアラチャネルが確立され、ストリーミングメディアセッションがセットアップされた後、メディアサーバ１１５は、メディアを搬送するパケットを、ＧＧＳＮ１２０、ＳＧＳＮ１０３、ＲＮＣ１３０、および基地局１０７を介して移動体クライアント１１０に送信する。移動体クライアント１１０は基地局１０７からＲＮＣ１３０、ＳＧＳＮ１０３、ＧＧＳＮ１２０、およびメディアサーバ１１５への逆パスに沿って周期的なフィードバックメッセージを送信する。無線アクセスネットワークにおけるアップリンク帯域幅限界のために、アップリンクフィードバックメッセージは比較的低い頻度で、例えば３−４秒ごとに１回送信される。

移動体クライアント１１０によって送信されたメディアおよびフィードバックメッセージを搬送するパケットはネットワーク要素によって透過的に搬送される。したがって、メディアサーバ１１５が（伝送速度またはコンテンツ速度を変化させるなどの）制御決定を行うのを助ける（移動体クライアント１１０からのフィードバックメッセージの形式の）シグナリングは本質的にエンドツーエンドで、ネットワーク要素による介入がない。メディアサーバ１１５はまたいくつかの制御／信号メッセージを移動体クライアント１１０に周期的に送信することができる。「サーバリポート」など、これらのメッセージもネットワーク要素によって透過的に搬送される。したがって、メディアサーバの制御決定は、チャネル条件の直接的な知識を有していない移動体クライアント１１０から受信されたかなり低い頻度のフィードバックに基づいている。したがって、メディアサーバ１１５は、パケット損失を回避するか、またはストリーミングメディアサービスの品質にとって有害なイベントを再バッファリングしないようにするためのタイムリな決定を行うことができない。

ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＩＥＴＦＲＦＣ）１８８９ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＩＥＴＦＲＦＣ）２３２６ＩＥＴＦＲＦＣ３４４８

本発明は、上記のうちの１つまたは複数の問題の影響に対処することを対象とする。本発明のいくつかの態様の基本的な理解を与えるために、本発明の簡略化された概要を以下に示す。この概要は本発明の網羅的な概観ではない。本発明の重要なまたは不可欠な要素を特定すること、または本発明の範囲を詳述するものではない。その唯一の目的は、後述するより詳細な説明の前置きとして、いくつかの概念を簡略化された形で提示することである。

本発明の一実施形態では、メディアサーバ、無線アクセスネットワーク、少なくとも１つのメディアクライアント、およびプロキシサーバを関連させる方法が提供される。本方法は、プロキシサーバにおいて、メディアサーバと前記少なくとも１つのメディアクライアントとの間のメディアセッションの確立がなされようとしていることを示す情報を含む少なくとも１つのメッセージにアクセスすることを含む。本方法は、プロキシサーバから、メディアセッションの確立がなされようとしていることを示す情報、およびメディアセッションに関連付けられたフィードバックを受信する要求を提供することをも含む。本方法は、メディアセッションに関連付けられたフィードバックを受信する要求を提供することに応答して、プロキシサーバにおいて、メディアセッションに関連付けられたフィードバックを受信することをさらに含む。

本発明の別の実施形態では、メディアサーバ、無線アクセスネットワーク、少なくとも１つのメディアクライアント、およびプロキシサーバを関連させる方法が提供される。本方法は、プロキシサーバから、メディアセッションの確立がなされようとしていることを示す情報、およびメディアセッションに関連付けられたフィードバックを受信する要求を受信することを含む。この情報および要求は、メディアサーバと前記少なくとも１つのメディアクライアントとの間のメディアセッションの確立がなされようとしていることを示す情報を含む少なくとも１つのメッセージをプロキシサーバが受信することに応答して提供される。本方法は、メディアセッションに関連付けられたフィードバックを受信する要求を受信することに応答して、プロキシサーバに、メディアセッションに関連付けられたフィードバックを提供することも含む。

本発明は、同様の参照番号が同様の要素を特定する添付の図面とともに行う以下の説明を参照することによって理解できる。

無線ネットワークを介したストリーミングメディアのための従来のシステムの１つの例示的な実施形態を概念的に示す図である。本発明による、無線ネットワークを介したストリーミングメディアのためのシステムの１つの例示的な実施形態を概念的に示す図である。本発明による、無線ネットワークを介したメディアストリーミング中にフィードバックを提供するための方法の１つの例示的な実施形態を概念的に示す図である。

本発明は様々な変更形態および代替の形態が可能であるが、本発明の具体的な実施形態は図面中に例として示されており、本明細書で詳細に説明される。しかしながら、本明細書における具体的な実施形態の説明は、本発明を開示された特定の形態に限定するものではなく、むしろ、その意図は、添付の特許請求の範囲によって定義されるように、本発明の範囲内に入るすべての変更形態、均等物、および代替形態を包含することであることを理解されたい。

本発明の例示的な実施形態について以下で説明する。明確にするために、本明細書では、実際の実装形態のすべての特徴を説明するわけではない。そのようないかなる実際の実施形態の開発においても、実装形態ごとに変わることになる、システム関連および業務関連の制約への準拠など、開発者の固有の目的を達成するために、多くの実装形態固有の決定が行われるべきであることは当然理解されよう。さらに、そのような開発努力は複雑で時間がかかることがあるが、それでもやはり、この開示の利益を受ける当業者にとって日常的な仕事となることは理解されよう。

本発明および対応する詳細な説明の部分は、ソフトウェア、またはコンピュータメモリ内のデータビット上の演算のアルゴリズムおよび記号表現で表される。これらの説明および表現は、当業者が自身の仕事の本質を他の当業者に効果的に伝えるためのものである。アルゴリズムは、本明細書で使用されるとき、また一般に使用されるとき、所望の結果に至る首尾一貫した一連のステップであると考えられる。ステップは、物理量の物理操作を必要とするステップである。必ずしもそうとは限らないが、通常、これらの量は、格納、転送、組合せ、比較、あるいは操作が可能な、光信号、電気信号、または磁気信号の形態をとる。主として一般的な用法という理由から、これらの信号をビット、値、要素、記号、文字、項、数字などと呼ぶことは、時として便利であることがわかっている。

なお、これらおよび同様の用語はすべて、適切な物理量に関連すべきものであり、これら物理量に付けられる単なる便利なラベルであることに留意されたい。特に別段の規定がない限り、または、考察から明らかなように、「処理」または「計算」または「算出」または「決定」または「表示」などの用語は、コンピュータシステムのレジスタおよびメモリ内の物理的、電気的量として表現されるデータを操作し、コンピュータシステムのメモリまたはレジスタ、あるいは他のそのような情報記憶装置、伝送装置、または表示装置内の物理量として同様に表現される他のデータへ変換する、コンピュータシステムまたは同様の電子計算装置の動作およびプロセスを指す。

また、本発明のソフトウェア実装態様は、一般に、なんらかの形式のプログラム記憶メディアに符号化されるか、またはある種類の伝送メディア上で実装されることにも注意されたい。プログラム記憶メディアは、磁気メディア（例えば、フロッピディスクまたはハードドライブ）でも、光学式メディア（例えば、コンパクトディスク読取り専用メモリ、すなわち「ＣＤ−ＲＯＭ」）でもよく、読取り専用でもランダムアクセスでもよい。同様に、伝送メディアは、当技術分野で知られているツイストワイヤペア、同軸ケーブル、光ファイバ、または何かその他の適切な伝送メディアでもよい。本発明は、所与の実装のこれらの態様によって限定されない。

次に、添付の図を参照して本発明を説明する。様々な構造、システムおよび装置は、単に説明のために、また当業者によく知られている詳細により本発明を不明瞭にしないように、図面中では概略的に示されている。それにもかかわらず、添付の図面は、本発明の例示的な例を記述し、説明するために含まれる。本明細書で使用される語句は、当業者によるそれらの語句の理解と矛盾しない意味を有するように理解され、解釈されるべきである。語または句の特別な定義、すなわち、当業者によって理解される通常の、および慣習的な意味とは異なる定義が、本明細書の語または句の矛盾しない用法によって暗示されるものとされることはない。語または句が特別な意味、すなわち、当業者によって理解される意味以外の意味を有するとされる限りにおいて、このような特別な定義は、語または句に特別な定義を直接かつ明解に提供する定義法で、明細書にはっきり記載されることになる。

図２は、無線ネットワーク２００を介したストリーミングメディアのためのシステム２００の１つの例示的な実施形態を概念的に示す。図示の実施形態では、メディアサーバ２１５と移動体クライアント２１０との間のシステム２００の部分は、それが無線セグメントならびに有線セグメントを含むことができるにもかかわらず、従来、無線ネットワーク２００と呼ばれる。ＧＧＳＮ２２０と移動体クライアント２１０との間のネットワークセグメントは無線アクセスネットワーク２２３と呼ばれる。図示の実施形態では、無線ネットワーク２００は、エアインターフェース２０２上でモバイルユニットなど１つまたは複数のクライアント２１０に対してメディアをストリーミングするために使用できる１つまたは複数の基地局２０７を含む。メディアは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３、および無線ネットワーク制御装置（ＲＮＣ）２３０を介してメディアサーバ２１５によって提供できる。無線アクセスネットワーク２２３は、基地局２０７、ＳＧＳＮ２０３、ＧＧＳＮ２２０およびＲＮＣ２３０を備え、リアルタイムのメディア移送のためのユニバーサル移動電話システム（ＵＭＴＳ）（３ＧＰＰ）標準および／または標準プロトコルに従って動作することができる。例えば、ストリーミングメディアセッションでは、リアルタイムトランスポートプロトコル（ＲＴＰ）はメディアコンテンツを搬送するために使用でき、関連するリアルタイム制御プロトコル（ＲＴＣＰ）は関連する制御パケットを搬送するために使用できる。第３のプロトコルであるリアルタイムストリーミングプロトコル（ＲＴＳＰ）は、セッションのセットアップ（能力交換を含む）、ティアダウン、およびいくつかのユーザの動作（例えば休止、早送りなど）のためのメッセージの送信に使用できる。ＲＴＰ／ＲＴＣＰおよびＲＴＳＰに関する詳細は、それぞれ、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔｓ（ＩＥＴＦＲＦＣ）１８８９および２３２６に出ている。

ただし、第１の例示的な実施形態は例示的なものであり、本発明をこれらの標準および／またはプロトコルに限定するものではないことを、本開示の恩恵を受ける当業者は理解されたい。例えば、本明細書に記載の技法は、他の無線ネットワークキング技術および標準、例えば、ｃｄｍａ２０００ハイレートパケットデータ（ＨＲＰＤ）またはＩＥＥＥ８０２．１６ｅ／ＷｉＭＡＸにも適用できる。ｃｄｍａ２０００ＨＲＰＤの場合、例えば、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３とゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０のノードペアが、パケットデータサービングノード（ＰＤＳＮ）として知られている単一のエンティティによって置き換えられるであろうことを除いて、システム２００は図２のそれと同等と思われる。さらに、階層アーキテクチャが図示されているが、本明細書に記載の技法はフラットインターネットプロトコル（フラットＩＰ）ベースのアーキテクチャにも適用でき、その場合、無線アクセスネットワークに関するレイヤ３ルーティング（すなわち、ＩＰ）および制御機能が基地局によって実行される。

クライアント２１０は、透過的なエンドツーエンドのパケット交換ストリーミングサービスのための３ＧＰＰ拡張の有無にかかわらず、標準のＲＴＳＰ／ＲＴＣＰシグナリングをサポートすることができる。したがって、クライアント２１０は、メディアサーバ２１５に向かってＲＴＣＰ（フィードバック）パケットを周期的に送信し、以下の性能測定基準をメディアサーバ２１５に通知することができる。それらの測定基準は、（最後の同様のリポート以後に）失われたパケットの割合、失われたパケットの累積数、受信された最高の（ＲＴＰ）シーケンス番号、（サーバから受信された）最後の送信側のリポートに関連付けられたＲＴＰタイムスタンプ、最後の送信側リポートを受信してからの時間、復号すべき次のアプリケーションデータユニットに関連付けられたＲＴＰシーケンス番号、次のアプリケーションデータユニットを復号するまでの遅延、（クライアントにおける）空きバッファ空間などである。このリストの最後の３つの項目はパケット交換ストリーミングサービスのための３ＧＰＰ拡張に従っているが、残りは、ＲＴＣＰ受信側リポート中に含まれる標準フィードバック項目であることに留意されたい。受信側リポート中に含まれるこれらの項目以外に、各ＲＴＣＰパケットは、リポートを特定の時点に関係させるためにサーバによって使用できるタイムスタンプも搬送することができる。クライアント２１０は、それ自体の能力および無線アップリンクの容量に一致する速度でＲＴＣＰフィードバックパケットを送信することができる。一般に、そのようなフィードバックパケットはかなり低い頻度で、例えば３から４秒ごとに１回送信される。クライアントデバイスがそのＲＴＣＰフィードバックを送信する間隔はＴ_Ｒによって示されることになる。

無線通信システム２００はシグナリングプロキシ２２５を含む。一実施形態では、シグナリングプロキシ２２５は、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２２０などの、無線ネットワーク２００中の無線アクセスネットワークエンティティに接続できる。しかしながら、本発明の他の実施形態では、シグナリングプロキシ２２５を、サービングＧＰＲＳサポートノード（ＳＧＳＮ）２０３、無線ネットワーク制御装置（ＲＮＣ）２３０など他のアクセスネットワークエンティティに、または、フラットなアーキテクチャによって特徴付けられる（例えば、ＲＮＣ、ＳＧＳＮおよびＧＧＳＮによって処理される複数の機能が唯一のエンティティである基地局ルータにまとめられている）基地局ルータを備えるアクセスネットワークの場合、基地局自体に接続することが可能である。シグナリングプロキシ２２５は、ソフトウェア、ファームウェア、ハードウェアまたはその任意の組合せで実装できる。

シグナリングプロキシ２２５はクライアント２１０からフィードバックを受信する。一実施形態では、クライアント２１０からのフィードバックはクライアント２１０の現在のセッション状態を示している。例えば、シグナリングプロキシ２２５はＲＴＣＰおよびＲＴＳＰメッセージのフローの中に介入することができる。セッションのセットアップおよびティアダウン中、ならびにセッションのライフタイム中に、クライアント２１０によって生成される制御メッセージ（例えば、メディアセッションに関連付けられたＲＴＣＰおよびＲＴＳＰメッセージ）は、通常、メディアサーバ２１５に直接移動することになるが、代わりに、シグナリングプロキシ２２５に提供される。これらのメッセージは、シグナリングプロキシ２２５がユーザの動作ならびにクライアント２１０の状態（例えば、バッファの内容、オーバーフロー／アンダーフローに対する予想時間など）を追跡するのを助けることができる。一実施形態では、メディアコンテンツを搬送するＲＴＰパケットはメディアサーバ２１５からクライアント２１０に直接流れることができる。

シグナリングプロキシ２２５は無線アクセスネットワーク２２３からのフィードバックも受信する。一実施形態では、無線アクセスネットワーク２２３からのフィードバックは、無線アクセスネットワーク２２３とクライアント２１０との間のエアインターフェースに関連付けられたリソースを示している。例えば、シグナリングプロキシ２２５は、ＲＡＮ−プロキシ制御パケットの形態で、送信する無線リンク制御プロトコルハンドラから頻繁なフィードバックを受信することができ、それは、無線ネットワーク制御装置２３０において一般性を失なうことなく実装できる。基地局ルータを有する無線アクセスネットワーク２２３の場合、シグナリングプロキシ２２５はこれらのルータに接続でき、バッファレベル、利用可能帯域幅、競合するユーザ数などに関する情報がローカルで利用可能となる。フィードバックは、ＲＮＣ２３０におけるバッファレベル、ダウンリンク帯域幅をメディアセッションと共有しているユーザ数、各ユーザに利用可能な帯域幅など、無線アクセスネットワーク２２３中のエンティティから入手可能な詳細なシステム情報およびシステムビューをシグナリングプロキシ２２５に通知する。メディアストリームごとに、（対応するＲＮＣ２３０によって送信された）チャネル／ネットワーク条件フィードバックは、メディアストリームが現在の条件の下で送信できる最大送信速度も含むことができる。最後のリポート間隔中にクライアント２１０に配信されたストリーミングメディアを搬送するパケットの数などの他の測定値を（随意に）リポートすることも可能である。

ダウンリンクシグナリング／制御メッセージ中で送信された情報（例えば、メディアサーバ２１５によって送信されたシグナリング／制御メッセージ）は、サーバ動作、およびクライアント２１０とサーバ２１５との間で取り決められた能力を追跡するために、シグナリングプロキシ２２５において記録できる。一実施形態では、シグナリングプロキシ２２５は、これらのメッセージをクライアント２１０にとって本質的に不変であると認めることができる。メディアサーバ２１５に直接提供される代わりに、クライアント２１０によって送信されたアップリンクシグナリング／制御メッセージは、シグナリングプロキシ２２５によって傍受でき、シグナリングプロキシ２２５は、クライアントの状態を追跡するためにこれらのメッセージ中に含まれる情報を記録することができる。シグナリングプロキシ２２５は、クライアントの状態のこの知識を、適切なネットワーク要素から受信された周期的なチャネル／ネットワーク条件フィードバックと組み合わせて使用して、フィードバックメッセージを生成することができ、フィードバックメッセージはメディアサーバ２１５に送信できる。シグナリングプロキシ２２５によって形成されたフィードバックメッセージは、クライアント２１０によって送信され（プロキシ２２５によって傍受され）た元のフィードバックメッセージ中に含まれていた情報、ならびに対応するネットワーク要素（ＲＮＣ２３０など）に見える実際のネットワーク条件に基づいて決定できる他の有用なパラメータ（ストリーミングメディアセッションのための最大送信速度など）を含むことができる。シグナリングプロキシ２２５とメディアサーバ２１５との間の帯域幅限界は、一般にシグナリングプロキシ２２５とメディアサーバ２１５との間で送信されるフィードバックメッセージの周波数を限定しないので、シグナリングプロキシ２２５は、かなり短い間隔（例えば、１００ｍｓ）でそのフィードバックメッセージを送信することができる。シグナリングプロキシ２２５を含まない従来のシステムに対して、低減されたフィードバック間隔はメディアサーバ２１５がより正確でタイムリな制御決定を行うのを助け、したがってストリーミングメディアサービスの全体的な品質を強化することができる。

動作時に、移動体クライアント２１０は、無線ネットワーク２００を介してストリーミングビデオセッションをメディアサーバ２１５と開始することができる。例えば、クライアント２１０は、ＲＴＳＰメッセージをサーバ２１５に送信することによってストリーミングビデオセッションを要求することができる。ＧＧＳＮ２２０は、メディアサーバ２１５の代わりに、ＲＴＳＰメッセージをシグナリングプロキシ２２５に転送する。プロキシ２２５は、このメッセージを検査し、それが新しいストリーミングビデオセッションの開始とすることができるものであると理解すると、そのローカルキャッシュ内にエントリを行う。次いで、それはメッセージをサーバ２１５に転送する。プロキシ２２５は、ＲＴＳＰメッセージがＧＧＳＮ２２０に向かう途中で通過したＲＮＣ２３０にセッション確立指示メッセージも送信する。セッション確立指示メッセージは、セッションの確立がなされようとしていることをＲＮＣ２３０に知らせる。無線アクセスベアラ（ＲＡＢ）がセッションのためにすでにセットアップされている場合、ＲＮＣ２３０は（プロキシ２２５に対して）ＲＡＢ確立メッセージで応答し、他の場合には、ＲＮＣ２３０は単に肯定応答を送信するだけである。

サーバ２１５はメッセージに応答し、後続のＲＴＳＰメッセージがクライアント２１０およびサーバ２１５によって交換されて、能力交換を実施する。後続のＲＴＳＰメッセージもシグナリングプロキシ２２５を介してルーティングされる。これにより、プロキシ２２５は、クライアント２１０およびサーバ２１５によって合意された１つまたは複数のセッションパラメータ（例えば帯域幅、バッファサイズなど）によって示される適切な能力を発見することが可能になる。能力交換が、クライアント２１０がその受信側リポートをサーバ２１５に送信すべき速度または時間間隔を含む場合、プロキシ２２５は、対応するメッセージをサーバ２１５に転送するときに、サーバ２１５がプロキシによって決定された適切な時間間隔または速度でフィードバックを受信する準備ができるように、このパラメータを修正する。正規のリポート間隔に加えて、いくつかの条件（例えば、ＲＮＣ２３０におけるセッションの最大送信速度またはバッファ状況の変化）の下で、プロキシ２２５は、自主的にフィードバックリポートをサーバ２１５に送信することも選択することができることに留意されたい。この修正により、プロキシ２２５は（プロキシ２２５とサーバ２１５との間の利用可能な大量の帯域幅に一致する）はるかにより速い速度でリポートをサーバ２１５に送信することが可能になり、クライアント２１０は（プロキシ２２５によって傍受される）そのリポートをより遅い速度で送信することが可能になる。

サーバ２１５との能力交換の後に、クライアント２１０は、パケットデータプロトコル（ＰＤＰ）コンテキストおよび無線アクセスベアラ（ＲＡＢ）の確立を開始して、ダウンリンク上で所望のサービス品質でストリーミングメディアセッションを搬送する。ＲＡＢおよび対応する無線ベアラ（ＲＢ）がセットアップされたとき、無線ネットワーク制御装置（ＲＮＣ）２３０はそのイベントについてシグナリングプロキシ２２５に知らせる。プロキシ２２５は、対応するストリーミングビデオセッションのためにそのキャッシュ中にすでにエントリを有する場合、肯定の指示で応答し、セッションの最大送信速度、バッファ占有率などについて周期的なフィードバックを（プロキシ２２５に）送信するようにＲＮＣ２３０に対して指示する。最低でも、このフィードバックはセッションのための最大送信速度を含むべきであるが、他のパラメータは随意である。プロキシ２２５は、ストリーミングメディアセッションのためにそのキャッシュ中にエントリを有していない場合、否定の指示で応答する。クライアント２１０がセッション確立のためにメディアサーバ２１５とのシグナリングを開始する前に、ＲＡＢがストリーミングメディアセッションを搬送するために確立されたとき、そのようなシナリオが起こることがある。このシナリオで、最終的にセッション確立のためのシグナリングが第１のＲＴＳＰメッセージの送信で行われるとき、プロキシ２２５がセッション確立指示メッセージをＲＮＣ２３０に送信することができることに留意されたい。そのセッションのためのＲＡＢがすでにセットアップされてから、次いで、ＲＮＣ２３０は別のＲＡＢ確立メッセージで応答することができる。次いで、残りの動作は本明細書に記載の順序に従うことができる。

ここから、ＲＮＣ２３０は様々なパラメータを追跡し、および／または他のパラメータを算出することができる。一実施形態では、ＲＮＣ２３０は、クライアント２１０に配信されたストリーミングメディアセッションに属するＩＰパケットの数を追跡する。ＲＮＣ２３０は、対応するバイト数、エアインターフェース上で繰り返されたブロックエラーのためにＲＮＣで廃棄されたパケットの数、およびセッションに利用可能であったチャネル帯域幅も（セッションに属するパケットを搬送するために使用されたかどうかにかかわりなく）追跡する。ＲＮＣ２３０は、選択された間隔で、例えば、Ｔ_Ｐ＝０．１００秒ごとにこの情報を処理し、チャネル／ネットワーク条件フィードバックメッセージでシグナリングプロキシ２２５に送信できる情報を形成する。このフィードバックは、最大送信速度（Ｗ_Ｓ）、および、随意に、ＲＮＣバッファで待機しているセッションに属するＩＰパケットの数、対応するバイト数など他の適切な性能測定基準を含むことができる。例えば、ＲＮＣ２３０は、セッションがストリーミングすることができる最大送信速度、および、場合によっては、ＲＮＣ２３０および／または他の適切なパラメータによってそのセッションのために割り当てられたバッファ中に記憶されるデータ量を、シグナリングプロキシ２２５に周期的にリポートすることができる。

一実施形態では、最大送信速度Ｗ_Ｓは、次の通り計算できる。Ｎ_Ｄ（ｎ）で、（Ｔ_Ｐ秒の長さの）ｎ番目のチャネル条件フィードバック間隔中にクライアント２１０に配信されるＩＰパケットの数を示し、Ｋ_Ａ（ｎ）およびＫ_Ｕ（ｎ）で、それぞれ、ｎ番目の間隔中にメディアセッションにとって利用可能であった送信機会の数、およびｎ番目の間隔中にデータを搬送するために実際に使用された送信機会の数を示す。専用チャネルとともに、専用チャネルに属している送信ブロックは、送信機会として見なされることがある。Ｍ_Ｄ（ｎ）で、この間隔中にクライアント２１０に実際に配信されたＮ_Ｄ（ｎ）個のパケットに関連付けられたバイト数を示す。次いで、利用可能帯域幅Ｗ_Ａ（ｎ）は、以下で与えられる：
Ｗ_Ａ（ｎ）＝Ｍ_Ｄ（ｎ）＊Ｋ_Ａ（ｎ）／（Ｋ_Ｕ（ｎ）＊Ｔ_Ｐ）（バイト／秒を単位とする）
ｎ番目のチャネル／ネットワーク条件フィードバック間隔、Ｗ_Ｓ（ｎ）の間の最大送信速度は、Ｗ_Ａ（ｎ）、利用可能帯域幅に等しく設定できるか、または、以下のヒューリスティックを使用することができる。
Ｗ_Ｓ（ｎ）＝_Ｌ＊Ｗ_Ａ（ｎ）Ｑ（ｎ）＜_Ｌの場合
＝_Ｈ＊Ｗ_Ａ（ｎ）Ｑ（ｎ）＞_Ｈの場合
＝Ｗ_Ａ（ｎ）他の場合
式中、Ｑ（ｎ）はｎ番目のチャネル／ネットワーク条件フィードバック間隔の終了時にＲＮＣバッファ中で列が作られるメディアセッションに属するデータ量であり、_Ｈはある「高水準値」で、_Ｌはある「低水準値」であり（ただし、_Ｈ＞_Ｌ）、_Ｌおよび_Ｈは定数である（ただし、_Ｈが１より小さく、_Ｌが１より大きい）。例えば、セッション当たりの専用ＲＮＣバッファが２０キロバイトの場合、_Ｈおよび_Ｌは、それぞれ、１０キロバイトおよび２キロバイトに等しく設定されてもよいが、_Ｈおよび_Ｌは、それぞれ、０．５および１．５に等しく設定されてもよい。

一部の別の実施形態では、共用チャネルは、無線セグメント上でメディアストリームを配信するために使用できる。メディアストリームのための最大送信速度の概念をこれらの実施形態で利用して、パケット損失のリスクを冒すことなくストリーミング速度を最大にすることができる。しかしながら、この場合、メディアストリームのための最大送信速度の算出は異なる。共用チャネルについては、多数の様々なストリーム／セッションが同じ物理チャネル、または、ＭＡＣレイヤチャネル上で統計学的に多重化される。したがって、メディアストリームのための最大送信速度は、チャネルを共有する様々なストリームと、それらのそれぞれの優先順位レベルと、帯域幅保証と、チャネル特性と、ＲＮＣで使用されているバッファリング戦略と、ＲＮＣにおけるバッファレベルとに応じている。最大送信速度の算出のための特定のアルゴリズムは、基地局で使用されている送信予定戦略の詳細に依存することがあるが、設計選択の問題である。次いで、ＲＮＣ２３０は、メディアがストリーミングできる最大送信速度をメディアサーバ２１５に（プロキシ２２５を介して）知らせることができ、それによって、サービスオペレータがそれらの要件およびサービス保証に従って帯域幅リソースを異なるユーザ間で柔軟に共有することが可能になる。この能力は輻輳の期間中に特に有用なことがある。

クライアント２１０によって送信された受信側リポートはＲＴＣＰパケットで搬送できる。ＧＧＳＮ２２０は、上流方向で受信されたすべてのＲＴＣＰパケットをシグナリングプロキシ２２５に転送する。プロキシ２２５は、（プロキシ２２５がそのローカルキャッシュ中にエントリを行った）所与のセッションのためにそのような第１のパケットを受信した場合、最大送信速度、および、場合によっては、ＲＮＣ２３０から受信した、セッションのための他のフィードバックパラメータなどの追加情報をパケットに追加することができ、そのパケットをサーバ２１５に向かって転送する。ここから、プロキシ２２５は、一定の間隔をおいてＲＴＣＰフィードバックリポートをサーバ２１５に送信する。この間隔は、一般に、クライアント２１０がそのＲＴＣＰリポートを送信する間隔よりもはるかに短い（例えば、十分な平均化と高速フィードバックの両方を可能にする百ミリ秒台、すなわち約１００ｍｓである）ことを思い出されたい。プロキシ２２５が、サーバ２１５に対するＲＴＣＰリポートのその最後の送信以後に、（ＧＧＳＮ２２０によってプロキシ２２５に転送された）クライアントリポートを受信した場合、プロキシ２２５は、クライアント２１０によってリポートされたデータ、ならびにＲＮＣ２３０によって提供されたフィードバックを、サーバ２１５へのその次のＲＴＣＰリポート中に含むことができる。他の場合には、クライアント２１０は、ＲＮＣフィードバックデータのみをサーバ２１５へのそのリポート中に含む。

図３は、無線ネットワークを介したメディアストリーミング中にフィードバックを提供するための方法３００の１つの例示的な実施形態を概念的に示す。上記のように、ＧＧＳＮは、メディアサーバおよびクライアントから受信するすべてのＲＴＳＰおよびＲＴＣＰメッセージをシグナリングプロキシに転送する。シグナリングプロキシは（３０５において）これらのメッセージを受信し、メッセージが新しいメディアセッションの確立がなされようとしていることを示している場合、ローカルデータベース中の新しいメディアセッションのためのエントリを作成する。次いで、シグナリングプロキシは（３１０において）、セッションの能力交換フェーズに関係するＲＴＳＰメッセージをモニタし、セッションパラメータ（例えば、クライアントバッファサイズ、クライアントリポートが送信される時間間隔など）について学習することができる。シグナリングプロキシは、メディアセッションが確立されようとしていることを学習すると、（３１５において）対応するメディアストリームがそれを介して配信されることになるＲＮＣにセッション確立指示メッセージを送信する。シグナリングプロキシは、このメッセージをＲＮＣに送信した後、（３１５において）タイマを設定し、（３２０において）そのメディアセッションのための（ＲＮＣからの）ＲＡＢ確立メッセージを待つ。タイマが時間切れになる前にセッションのためのＲＡＢ確立メッセージが受信されない場合、シグナリングプロキシは（３２５において）セッションのためのエントリをそのロ−カルデータベースから削除する。

タイマが時間切れになる前にセッションのためのＲＡＢ確立メッセージが受信された場合、シグナリングプロキシは、タイマをオフにし、（３３０において）ＲＡＢ確立メッセージの受信を肯定応答するＲＮＣにメッセージを送信し、対応するセッションのためのチャネル／ネットワーク条件フィードバックの送信を開始するようにＲＮＣに指示する。このメッセージは、とりわけ、チャネル／ネットワーク条件中に含むべきパラメータ、およびフィードバックを提供すべき間隔（Ｔ_Ｐ）を含むことができる。このメッセージを送信した後、プロキシは、チャネル／ネットワーク条件フィードバックメッセージをＲＮＣからＴ_Ｐ秒ごとに、（受信側リポートを有する）ＲＴＣＰメッセージをクライアントデバイスからＴ_Ｒ秒ごとに受信することを予想する。したがって、プロキシは（３３５において）、受信側リポートを有する第１のＲＴＣＰメッセージをクライアントから受信するまで待機する。そのような第１のリポートが受信されるまで、プロキシは、対応するＲＮＣから受信することができる（メディアセッションのための）チャネル／ネットワーク条件フィードバックメッセージを無視する。受信側リポートを有するＲＴＣＰメッセージがクライアントから受信されるときはいつでも、プロキシは、（３４０において）フラグを１に設定し、次いで（３４５において）クライアントデバイスからの受信側リポートおよびＲＮＣからのチャネル／ネットワーク条件フィードバックメッセージを待つ。

受信側リポートを有する第１のＲＴＣＰメッセージを受信した後、シグナリングプロキシは、メディアセッションのためのチャネル／ネットワーク条件フィードバックメッセージを対応するＲＮＣから受信するときはいつでも、以下の動作を実施することができる。シグナリングプロキシが（３５０において）フラグが１に設定されていると判断した場合、プロキシは（３５５において）フラグをリセット（すなわち、フラグを０に等しく設定）し、拡張されたフィードバックリポートをメディアサーバにＲＴＣＰパケットで送信する。拡張されたフィードバックリポートは、クライアントから受信されたＲＴＣＰ受信側リポートで報告される情報、ならびに、対応するメディアストリームが送信できる最大送信速度（Ｗ_Ｓ）、および（あるとすれば）ちょうど受信されたチャネル／ネットワーク条件フィードバックでリポートされた他の任意パラメータを含むことができる。一方、チャネル／ネットワーク条件フィードバックメッセージが到着したとき、（３５０において）シグナリングプロキシがフラグが０に等しいと判断した場合、プロキシは（３６０において）、Ｗ_Ｓ、および（あるとすれば）受信されたばかりのチャネル／ネットワーク条件フィードバック中に含まれる他の任意パラメータの現在の値を含むことができる短いフィードバックリポートを（またＲＴＣＰパケットで）送信する。プロキシは、拡張されたフィードバックリポートを送信するとき、クライアントから受信された最新のＲＴＣＰメッセージのＲＴＰタイムスタンプを、拡張されたフィードバックリポートのＲＴＰタイムスタンプとして使用することができる。短いリポートの場合、プロキシは、そのローカルなクロックタイムを使用してＲＴＰタイムスタンプを生成することができる。一実施形態では、プロキシは、クライアントから受信されたＲＴＣＰメッセージに関連付けられたＲＴＰタイムスタンプを使用して、そのクロックタイムをクライアントのクロックタイムに合わせることができる。既存のＲＴＣＰプロトコルに好適な拡張は、プロキシからの短く、拡張されたフィードバックリポートの移送を可能にするように展開できることに留意されたい。

メディアセッションがクライアントまたはサーバからの適切なＲＴＳＰメッセージで終了したとき、シグナリングプロキシは、そのローカルデータベース中のそのセッションのためのエントリを削除し、フィードバックメッセージをメディアサーバに送信するのを停止し、チャネル／ネットワーク条件フィードバックメッセージを送信するのを停止するようにＲＮＣに指示する。

本明細書に記載の技法の実施形態は、従来の実施に勝るいくつかの利点を提供することができる。例えば、既存のビデオサービスのセットアップでは、ビデオサーバは、クライアントによって提供されるデータを使用して最大送信速度を推定する。この推定は、間接的であるので、特に無線ネットワークの典型的な動作条件など、動的な動作条件では、しばしば有意性誤りを含むか、または単に使われなくなることがある。一方、シグナリングプロキシによって決定される最大送信速度は、それが直接的な測定値に基づいているので、少なくとも部分的により正確であるとすることができる。最大送信速度推定値の確度を改善することによってサーバがデータを最適に送信することが可能になり、無線アクセスネットワークでのパケット損失、または利用可能なリソースの過小利用の可能性を低減する。

さらに、既存のセットアップでは、無線アクセスネットワーク上の利用可能なアップリンク帯域幅が限定されているため、クライアントがビデオサーバにフィードバックを送信する頻度はかなり低い。例えば、ＲＴＰ／ＲＴＣＰベースのビデオストリーミングセッションでは、クライアントが（フィードバック）リポートをサーバに５秒ごとに１回程度送信するのが一般的である。そのような帯域幅限界がプロキシとビデオサーバとの間にないので、プロキシは、現在持続可能な（すなわち、最大送信）速度（および、場合によっては、他の有用な情報）を搬送する制御パケットを、もっとより頻繁に、例えば１００ｍｓごとに１回程度送信することができる。これは、サーバが送信速度を最適に調整することを助け、したがってパケットを失うリスクを冒すことなくネットワークリソースを十分に利用することになる。クライアントは、それらのリポートを無線アクセスメディアの能力に一致する速度で生成することができる。プロキシは、これらのリポートを使用して、クライアントの状態についてその知識を更新することになる。プロキシによって（もっとより短い間隔で）生成され、サーバに送信されるリポートは、クライアントリポートから得られる情報、ならびに最大送信速度の現在の値についてのプロキシの推定値を含むことになる。そのような構成は、クライアント動作がシグナリングプロキシの存在によって影響を受けないことを保証することができるので、メディアクライアント上で実装形態の変更は必要ではない。

別の利点は、本明細書に記載の技法が、メディアサーバがシグナリングプロキシによって、決定され、サーバに伝達される、推定された最大送信速度を使用することを可能にすることができることである。既存のセットアップでは、メディアサーバは、クライアントリポートから受信された情報を使用して、最大送信速度の現在の値の推定値を得る（例えば、ＩＥＴＦＲＦＣ３４４８に明記されているＴＣＰＦｒｉｅｎｄｌｙＲａｔｅＣｏｍｐｕｔａｔｉｏｎａｌｇｏｒｉｔｈｍによる）。したがって、メディアストリーミングサーバは、既存の現況技術に従ってストリーミングサーバによって計算されたストリーミング速度値の代わりに、プロキシから周期的に受信された最大送信速度フィードバックを使用するだけでよい。残りのサーバ機能、特に異なる符号化速度に切り替えるための論理回路は変わらなくてよい。メディアサーバで必要とされる唯一の能力は、プロキシによって提供される最大送信速度予測に基づいたストリーミング速度または送信速度で動作することを可能にすることである。この能力がサーバの実装形態について大きな意味を持たなくなることが予想される。クライアントフィードバック（例えば、ＲＴＣＰ受信側リポート）のための既存の機構は、最大送信速度フィードバック、および（それらを報告すべき場合には）プロキシからの他の適切なパラメータを搬送するように、単純な拡張で拡大できる。

本明細書に記載の技法のまた別の利点は、それらにより輻輳のレベルおよび相対的な優先順位などのそのようなパラメータに基づいた（ストリーミングならびに他のタイプの）異なるセッションに対する特異な処理が可能になり、アプリケーションが、柔軟で適切な方法で主要な条件に適合することが可能になることである。例えば、ダウンリンクが輻輳した場合、シグナリングプロキシは、リポートされた最大送信速度を低い優先順位のアプリケーションのために低下させ、したがって対応するサーバに遅い速度でストリーミングすることを強制することができる。

上記に開示された具体的な実施形態は例示的なものにすぎず、本発明は、本明細書の教示の利益を受ける当業者にとって明らかな、異なるが均等の様態で変更および実施できる。さらに、下記の特許請求の範囲に記載されている場合を除いて、本明細書に示された構成または設計の詳細に限定されるものではない。したがって、上記に開示された具体的な実施形態は改変または変更でき、すべてのそのような変形例は本発明の範囲内であると考えられることは明白である。したがって、本明細書で求められる保護は以下の特許請求の範囲に説明するとおりである。

Claims

メディアサーバと、無線アクセスネットワークと、少なくとも１つのメディアクライアントと、プロキシサーバとを関連させる方法であって、
シグナリングプロキシから無線アクセスネットワーク内の少なくとも１つの無線ネットワークコントローラおよび前記少なくとも１つのメディアクライアントへ、メディアセッションの確立がなされようとしていることを示す情報とメディアセッションに関連付けられたフィードバックを受信する要求を提供するステップと、
シグナリングプロキシにおいて、前記少なくとも１つの無線ネットワークコントローラから、無線アクセスネットワークと前記少なくとも１つのメディアクライアントの間のエアインターフェースと関連付けられたリソースを示す、第１のフィードバックを受信するステップと、
シグナリングプロキシにおいて、前記少なくとも１つのメディアクライアントから、メディアセッションに関連付けられた、エアインターフェースを介して伝送されフィードバック速度で受信される、第２のフィードバックを受信するステップと、
シグナリングプロキシから、メディアサーバへ、第１のフィードバックと第２のフィードバックに基づいて形成された少なくとも１つのリポートを提供するステップとを含み、前記少なくとも１つのリポートが該フィードバック速度より高い速度で提供される、方法。
メディアセッションの確立がなされようとしていることを示す、前記少なくとも１つのメディアクライアントによって提供された少なくとも１つのリアルタイムストリーミングプロトコルメッセージにアクセスするステップを含む、請求項１に記載の方法。
メディアサーバと前記少なくとも１つのメディアクライアントとの間のメディアセッションを示している情報をシグナリングプロキシに関連付けられたキャッシュ中に格納し、メディアセッションに関連付けられた無線アクセスベアラの確立を示すメッセージが選択された時間内に受信されない場合、メディアセッションを示している前記情報を削除するステップと、
シグナリングプロキシにおいて、メディアセッションに関連付けられた無線アクセスベアラの確立を示す情報を受信するステップと、
キャッシュがメディアセッションを示している情報を含む場合、無線アクセスベアラの確立を示す情報に応答して、肯定の応答を提供するステップと
を含む、請求項１に記載の方法。
前記少なくとも１つのメッセージに基づいてメディアセッションに関連付けられた少なくとも１つのセッションパラメータを決定するステップを含み、前記少なくとも１つのセッションパラメータを決定するステップが、帯域幅と、バッファサイズと、フィードバックを送信または受信するための速度または時間間隔とのうちの少なくとも１つを決定するステップを含む、請求項１に記載の方法。
前記少なくとも１つのセッションパラメータを修正するステップと、前記少なくとも１つの修正されたセッションパラメータを無線アクセスネットワークとメディアサーバとのうちの少なくとも１つに提供するステップとを含む、請求項４に記載の方法。
第２のフィードバックを受信するステップが、フィードバック速度でエアインターフェースを介して伝送された少なくとも１つのリアルタイムコントロールプロトコル（ＲＴＣＰ）パケットを受信するステップを含み、前記少なくとも１つのＲＴＣＰパケットを受信するステップが、メディアセッションに関連付けられた少なくとも１つの性能測定基準を含む少なくとも１つのＲＴＣＰパケットを受信するステップを含む、請求項１に記載の方法。
シグナリングプロキシにおいて、少なくとも１つのメディアクライアントとメディアサーバの間のメディアセッションについてのメディアクライアントフィードバックと、無線アクセスネットワークと少なくとも１つのメディアクライアントの間のエアインターフェース関連付けられたリソースを示すネットワークフィードバックとを使用してフィードバックリポートを生成するステップを含み、メディアクライアントフィードバックは、メディアクライアントから、第１のフィードバック速度でエアインターフェースを介して伝送され、ネットワークフィードバックは、第２のフィードバック速度で提供され、
シグナリングプロキシから、第１のフィードバック速度より高い第３のフィードバック速度で、メディアサーバへ、フィードバックリポートを提供するステップと
を含む、方法。
フィードバックリポートを生成するステップが、無線アクセスネットワーク内の少なくとも１つの無線ネットワークコントローラ又は前記少なくとも１つのメディアクライアントに関連付けられた基地局ルータ又は無線ネットワークコントローラにより提供される、ネットワークフィードバックを使用して、フィードバックリポートを生成するステップを含む、請求項７に記載の方法。
フィードバックリポートを生成するステップが、無線アクセスネットワーク内の少なくとも１つのバッファレベルを示す情報、前記少なくとも１つのメディアクライアントとダウンリンク帯域幅を共有しているユーザ数、又は、各ユーザに利用可能な帯域幅を含む、ネットワークフィードバックを使用して、フィードバックリポートを生成するステップを含む、請求項７に記載の方法。
メディアセッション確立要求内に示されたフィードバック速度を修正するステップと、シグナリングプロキシからメディアサーバへ修正されたフィードバック速度を含む修正されたメディアセッション確立要求を提供するステップと
を含む、請求項７に記載の方法。