JP2014527769A - 無線アップリンク・セッションを制御する方法および装置 - Google Patents

Abstract

ビデオ・セッション管理能力を開示する。ビデオ・セッション管理能力は、セルラ・セクタのモバイル・デバイスの潜在的なおよび／または確立されたビデオ・セッションの管理を可能にする（たとえば、セルラ・セクタ内の確立されたビデオ・セッションの送信ビット・レートに対する動的変更をサポートするために）。セルラ・セクタに関連する条件の表示に応答して、マネージャは、セルラ・セクタのそれぞれの複数のアップリンク・ビデオ・セッションの複数のビデオ送信側のそれぞれについて、アップリンク・ビデオ・セッションのビデオ送信側の修正済み送信ビット・レートを決定し、ビデオ送信側に向かって、そのアップリンク・ビデオ・セッションの修正済み送信ビット・レートを使用するようにビデオ送信側に指示するメッセージを伝搬させる。

Description

関連出願の相互参照
本願は、その全体が参照によって本明細書に組み込まれている、米国特許出願第１３／２０８４６５号（整理番号第８０９０１８−ＵＳ−ＮＰ号）、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＣＯＮＴＲＯＬＬＩＮＧ ＷＩＲＥＬＥＳＳ ＵＰＬＩＮＫ ＳＥＳＳＩＯＮＳ」に関する。

本発明は、一般に通信ネットワークに関し、排他的にではなくより詳細には、無線通信ネットワークでの無線アップリンク・セッションの管理に関する。

さまざまな無線エコシステム（たとえば、第３世代（３Ｇ）無線ネットワーク、第４世代（４Ｇ）無線ネットワークなど）では、多くのモバイル・ユーザ・デバイスがビデオ取込能力を備える。これは、ソーシャル・メディア・サイト（たとえば、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、ブログなど）の使用の継続する増加と相俟って、モバイル・ユーザ・デバイスからのビデオの取込およびストリーミングの大幅な増加を引き起こす可能性がある。しかし、この可能性は、モバイル・ユーザ・デバイスから無線ネットワークへの無線アップリンク上の帯域幅制限に起因して、厳しく抑制されている。

ＲＦＣ ３５５０ ＲＦＣ ４５８５ ＲＦＣ ５１０４ ＲＦＣ ５５０６

従来技術のさまざまな欠点は、無線ネットワーク内でビデオ・セッションを管理する実施形態によって対処される。

一実施形態では、装置は、プロセッサおよびメモリを含み、プロセッサは、無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御するように構成される。プロセッサは、セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信し、セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信し、セルラ・セクタに関連する条件に応答して、無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定するように構成される。

一実施形態では、無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する方法が提供される。この方法は、セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信するステップと、セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信するステップと、セルラ・セクタに関連する条件に応答して、無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定するステップとを含む。

一実施形態では、装置は、プロセッサおよびメモリを含み、プロセッサは、無線ネットワークのセルラ・セクタ内でそれぞれの複数のビデオ送信側の複数のアップリンク・ビデオ・セッションのビット・レートを制御するように構成される。プロセッサは、ビデオ送信側のアップリンク・ビデオ・セッションに関連する状況メッセージを受信し、状況メッセージを使用して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の現在の送信ビット・レートを判定し、セルラ・セクタに関連する条件に応答して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の修正済み送信ビット・レートを決定し、それぞれの複数の送信ビット・レート変更メッセージを使用して、それぞれのビデオ送信側に向かってそれぞれのアップリンク・ビデオ・セッションの修正済み送信ビット・レートの表示を伝搬させるように構成される。

一実施形態では、無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する方法が提供される。この方法は、ビデオ送信側のアップリンク・ビデオ・セッションに関連する状況メッセージを受信するステップと、状況メッセージを使用して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の現在の送信ビット・レートを判定するステップと、セルラ・セクタに関連する条件に応答して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の修正済み送信ビット・レートを決定し、それぞれの複数の送信ビット・レート変更メッセージを使用して、それぞれのビデオ送信側に向かってそれぞれのアップリンク・ビデオ・セッションの修正済み送信ビット・レートの表示を伝搬させるステップとを含む。

本明細書の教示は、添付図面に関連して次の詳細な説明を考慮することによって、容易に理解することができる。

無線アップリンク制御能力を提供するように構成された無線アップリンク・コントローラを含む例示的な無線通信システムを示す図である。 図１のセルラ・セクタ内でアップリンク・ビデオ・セッションをスケジューリングする方法の一実施形態を示す図である。 図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションのスケジューリングを決定する方法の一実施形態を示す図である。 図１のセルラ・セクタ内でアップリンク・ビデオ・セッションをスケジューリングするように構成されたスケジューラの一実施形態を示す図である。 図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションの送信ビット・レートを変更する方法の一実施形態を示す図である。 図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションの送信ビット・レートを変更する方法の一実施形態を示す図である。 図１のセルラ・セクタ内でそれぞれの複数のＭＤの複数のアップリンク・ビデオ・セッションのビット・レートを制御する方法の一実施形態を示す図である。 本明細書で説明される機能を実行する際の使用に適するコンピュータを示す高水準ブロック図である。

理解を容易にするために、可能な場合には、複数の図面に共通する同一の要素を指定するのに、同一の符号を使用した。

一般に、無線アップリンク制御能力を、図示し、本明細書で説明するが、さまざまな他の能力も、本明細書で提示される可能性がある。

少なくともいくつかの実施形態では、無線アップリンク制御能力は、ユーザの体感品質（ｑｕａｌｉｔｙ−ｏｆ−ｅｘｐｅｒｉｅｎｃｅ、ＱｏＥ）を高めながら、無線アップリンク・リソースのより効率的な利用を可能にするさまざまな能力を使用してセルラベースの通信ネットワーク内のセルラ・セクタの無線アップリンク上の一貫して信頼できるビデオ送信を可能にする。

少なくともいくつかの実施形態では、無線アップリンク制御能力は、ビデオ・セッション・スケジューリング能力を含む。ビデオ・セッション・スケジューリング能力は、セルラ・セクタのモバイル・デバイスによるビデオ送信のスケジューリングを可能にする。たとえば、モバイル・デバイスが、セルラ・セクタの無線アップリンクを介してビデオを送信することを要求する場合に、ビデオ・セッション・スケジューリング能力は、モバイル・デバイスのビデオ・セッションの確立に関連する１つまたは複数のパラメータ（たとえば、ビデオ・セッションを開始できる時刻、ビデオ・セッションの最大送信ビット・レート割振りなど）を判定する。ビデオ・セッション・スケジューリング能力が、さまざまな他の特徴および機能をサポートできることに留意されたい。

少なくともいくつかの実施形態では、無線アップリンク制御能力は、ビデオ・セッション管理能力を含む。ビデオ・セッション管理能力は、セルラ・セクタのモバイル・デバイスの潜在的なおよび／または確立されたビデオ・セッションの管理を可能にする。たとえば、ビデオ・セッション管理能力は、セルラ・セクタ内の確立されたビデオ・セッションの送信ビット・レートに対する動的変更をサポートすることができる（たとえば、別のモバイル・デバイスによって要求される新しいビデオ・セッションに対処するために１つまたは複数のモバイル・デバイスの（１つまたは複数の）送信ビット・レートを下げる、無線アップリンク上の追加容量を、レート増加をサポートするのに使用できる場合に１つまたは複数のモバイル・デバイスの（１つまたは複数の）送信ビット・レートを上げるなど、およびそのさまざまな組合せ）。ビデオ・セッション管理能力が、さまざまな他の特徴および機能をサポートできることに留意されたい。

本明細書では主に特定のタイプの無線通信ネットワーク内の無線アップリンク制御能力のさまざまな実施形態の使用に関して図示され、説明されるが、無線アップリンク制御能力のさまざまな実施形態を、任意の適切な（１つまたは複数の）タイプの（１つまたは複数の）無線通信ネットワーク内で使用できることを了解されたい。

図１に、無線アップリンク制御能力を提供するように構成された無線アップリンク・コントローラを含む例示的な無線通信システムを示す。

例示的な無線通信システム１００は、複数のモバイル・デバイス（ＭＤ）１１０_１〜１１０_Ｎ（集合的にＭＤ１１０）、無線アクセス・ネットワーク（ＲＡＮ）１２０、無線パケット・ネットワーク（ＷＰＮ）１３０、パケット・ネットワーク（ＰＮ）１４０、複数のサーバ１５０_１〜１５０_ｍ（集合的にサーバ１５０）、管理システム１６０、および無線アップリンク・コントローラ１７０を含む。

ＭＤ１１０は、ＲＡＮ１２０と無線で通信するように構成されたモバイル・デバイスである。ＭＤ１１０は、無線アップリンクを介してＲＡＮ１２０に制御情報およびコンテンツを提供することができ、無線ダウンリンクを介してＲＡＮ１２０から制御情報およびコンテンツを受信することができる。

ＭＤ１１０は、無線アップリンクを介してＲＡＮ１２０に伝搬されるコンテンツ・ストリーム（本明細書では無線アップリンク・コンテンツ・ストリームと表す）のソースとして動作するように構成される。一般に、無線アップリンク・コンテンツ・ストリームは、ビデオ・ストリーム（オーディオなし）、マルチメディア・ストリーム（たとえば、ビデオおよびオーディオ、テキストその他などの１つまたは複数の他のタイプのコンテンツ）などとすることができる。この意味で、無線アップリンク・コンテンツ・ストリームを、本明細書では、無線アップリンク・ビデオ・ストリームと称する場合もあり、ここで、コンテンツ・ストリームは、少なくともビデオ部分を含む（および、上で注記したように、１つまたは複数の他のタイプのコンテンツをも含むことができる）。

ＭＤ１１０は、それを介してＭＤ１１０が無線アップリンクを介してＲＡＮ１２０にビデオ・コンテンツを伝搬させることができるアップリンク・ビデオ・セッションのスケジューリングについてネゴシエートするように構成される。たとえば、ＭＤ１１０は、アップリンク・ビデオ・セッションのスケジューリングを要求するためにアップリンク・ビデオ・セッション・スケジューリング要求を送信するように構成される。同様に、ＭＤ１１０は、アップリンク・ビデオ・セッション・スケジューリング要求に応答してアップリンク・ビデオ・セッション・スケジューリング応答を受信するように構成され、アップリンク・ビデオ・セッション・スケジューリング応答は、無線アップリンクを介するビデオ・コンテンツの伝搬のためにアップリンク・ビデオ・セッションを確立する際のＭＤによる使用のために構成されたアップリンク・ビデオ・セッション・スケジューリング情報を含む（たとえば、ビデオ・セッションを開始できる時刻、ビデオ・セッションの最大送信ビット・レート割振り）。

ＭＤ１１０は、コンテンツを取込み、取込まれたコンテンツを無線アップリンクを介してＲＡＮ１２０にストリーミングするように構成される。

ＭＤ１１０は、ビデオ・コンテンツ取込機構およびストリーミング機構をサポートするように構成される。たとえば、ＭＤ１１０は、標準品位および／または高品位ビデオ録画をサポートすることができる。たとえば、ＭＤ１１０は、１つまたは複数のビデオ・カメラ（たとえば、ビデオ・チャットをサポートするためのより低い解像度の前面カメラ、他のビデオのためのより高解像度の背面カメラなど、およびそのさまざまな組合せ）を含むことができる。たとえば、ＭＤ１１０は、１つまたは複数の異なるビデオ・コーデック（たとえば、Ｈ．２６３、Ｈ．２６４ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）−４−Ｐａｒｔ １０）、Ｈ．２６４ ＡＶＣ−Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＳＶＣ）、Ｇｏｏｇｌｅ ＶＰ８など、およびそのさまざまな組合せ）を含むことができる。一実施形態では、ＭＤ１１０は、ＭＤ１１０の帯域幅および／またはプロセッサ容量に依存してリアルタイムまたはほぼリアルタイムで可変ビット・レート符号化／ストリーミングを提供する適応ビット・レート符号化／ストリームをサポートするように構成される（たとえば、ＭＤ１１０が、複数の符号化ビット・レートをサポートし、無線条件、エンドツーエンド条件などの情報に基づいて、サポートされる符号化ビット・レートのうちの要求された１つで符号化するように構成される場合）。たとえば、ＭＤ１１０は、ビデオのストリーミングに関連するさまざまなプロトコル（たとえば、ＲＦＣ ３５５０で定義されるリアルタイム・トランスポート・プロトコル（ＲＴＰ）／リアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）、ＲＦＣ ４５８５で定義される、ＲＴＰ Ａｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＲＴＰ／ＡＶＰＦ）と表されるＥｘｔｅｎｄｅｄ ＲＴＰ Ｐｒｏｆｉｌｅ ｆｏｒ ＲＴＣＰ−Ｂａｓｅｄ Ｆｅｅｄｂａｃｋ、ＲＦＣ ５１０４で定義されるＲＴＰ ＡＶＰＦ内のＣｏｄｅｃ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅｓ、ＲＦＣ ５５０６で定義されるＲｅｄｕｃｅｄ−Ｓｉｚｅ ＲＴＣＰなど）をサポートすることができる。ＭＤ１１０は、さまざまな他のビデオ取込能力および／またはビデオ・ストリーミング能力をサポートすることができる。ＭＤ１１０を、本明細書で、ビデオ取込能力およびストリーミング能力をサポートするビデオ送信側と称する場合もある。

ＭＤ１１０を、オーディオ・コンテンツ取込機構およびストリーミング機構をサポートするように構成することができる。たとえば、ＭＤ１１０は、１つまたは複数のマイクロホン（たとえば、ビデオ・チャットでの使用のため、ビデオのナレーションでの使用のためなど）を含むことができる。たとえば、ＭＤ１１０は、１つまたは複数のオーディオ・コーデック（たとえば、ＡＡＣ（ＭＰＥＧ−４ Ｐａｒｔ ３）、Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ（ＡＭＲ）、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ｌａｙｅｒ−３（ＭＰ３）など、およびそのさまざまな組合せ）を含むことができる。

ＭＤ１１０を、ビデオ・コンテンツの伝搬に関連するさまざまな他の機能（たとえば、ビデオ・セッションに関連するビデオ・セッション品質統計の送信、ビデオ・セッション管理情報の受信および処理など、ならびにそのさまざまな組合せ）をサポートするように構成することができる。

一実施形態では、ＭＤ１１０は、さまざまな関連するソフトウェア開発キット（ＳＤＫ）アプリケーション・プログラミング・インターフェース（ＡＰＩ）によってサポートできる、コンテンツ取込に関するさまざまな特徴セットを含むことができる。

少なくともいくつかの実施形態で、ＭＤ１１０の少なくとも一部を、他のデバイスから提供されるコンテンツ・ストリームの受信側として動作するように構成することができる。この意味で、ＭＤ１１０は、コンテンツ送信側であることができ、オプションで、コンテンツ受信側であることもできる。さらに、少なくともいくつかの実施形態で、ＭＤ１１０のうちの１つによって提供される無線アップリンク・コンテンツ・ストリームのコンテンツ受信側のうちの１つまたは複数を、ＰＮ１４０に接続できる任意のタイプの（１つまたは複数の）デバイス（たとえば、モバイル・デバイス、静止デバイスなど、およびそのさまざまな組合せ）とすることができることに留意されたい。

たとえば、ＭＤ１１０を、スマート・ホン、タブレット・コンピュータ、ラップトップ・コンピュータ、またはビデオを取込み、取込まれたビデオを無線ネットワークの無線アップリンクを介して伝搬させることができる任意の他のタイプのデバイスとすることができる。

ＲＡＮ１２０は、異なるタイプの無線技術について異なって実施され得る任意の適切なタイプの無線アクセス・ネットワークとすることができる。ＲＡＮ１２０は、ＭＤ１１０とＷＰＮ１３０との間のインターフェースを提供する。ＲＡＮ１２０は、関連するセルラ・セクタ１２３をサポートする基地局（ＢＳ）１２２を含み、セルラ・セクタ１２３内に配置されたＭＤ１１０は、ＲＡＮ１２０のＢＳ１２２を介してＲＡＮ１２０にアクセスすることができる。一般に、ＭＤ１１０は、上で注記したように、一般に、それを介してＭＤ１１０が情報をＢＳ１２２に送信するアップリンク部分とそれを介してＢＳ１２２が情報をＭＤ１１０に送信するダウンリンク部分とを含む無線通信リンクを介してＢＳ１２２と通信する。単一の基地局を含むものとして（明瞭さのために）図示され、本明細書で説明されるが、ＲＡＮ１２０が、任意の適切な個数の関連するセルラ・セクタをサポートする任意の適切な個数の基地局を含むことができることを了解されたい。

ＷＰＮ１３０は、ＲＡＮ１２０に似て、異なるタイプの無線技術について異なって実施され得る任意の適切なタイプの無線パケット・ネットワークとすることができる。ＷＰＮ１３０は、ＲＡＮ１２０とＰＮ１４０との間のインターフェースを提供する。たとえば、第３世代ＵＭＴＳネットワークでは、ＷＰＮ１３０は、サービング汎用パケット無線サービス（ＧＰＲＳ）サポート・ノード（ＳＧＳＮ）、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）などの要素を含むことができる。たとえば、ロング・ターム・エボリューション（ＬＴＥ）ネットワークでは、ＷＰＮ１３０は、サービング・ゲートウェイ（ＳＧＷ）、パケット・データ・ネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）、移動管理エンティティ（ＭＭＥ）、ポリシ／課金ルール機能（ＰＣＲＦ）などの要素を含むことができる。

ＰＮ１４０は、公衆パケット・ネットワーク（たとえば、インターネット）、私有パケット・ネットワークなど、任意の適切なタイプのパケット・ネットワークとすることができる。ＰＮ１４０は、無線アップリンク制御能力のさまざまな機能を提供するように構成された複数のネットワーク要素を含み、かつ／またはこれとの通信を提供することができる。一実施形態では、たとえば、ＰＮ１４０は、サーバ１５０、管理システム１６０、および無線アップリンク・コントローラ１７０に関する通信をサポートする。

サーバ１５０は、ウェブ・サーバ（ＷＳ）、アプリケーション・サーバ（ＡＳ）など、任意の適切なタイプのサーバとすることができる。サーバ１５０は、ＭＤ１１０によって提供されるビデオに関連せずにアクセスされ得るサーバ、ＭＤ１１０によって提供されるビデオのコンテキスト内でアクセスされ得るサーバ（たとえば、ＭＤ１１０がそこにストリーミング・ビデオを提供できるソーシャル・ネットワーキング・サイトおよび／または他のタイプのサイトをホスティングするサーバ）など、ならびにそのさまざまな組合せを含む、ＭＤ１１０によってアクセスできる任意のサーバを含むことができる。

管理システム１６０は、ＲＡＮ１２０、ＷＰＮ１３０、およびＰＮ１４０のうちの１つまたは複数のさまざまな管理機能を提供する、任意の適切なタイプの管理システムとすることができる。一実施形態では、たとえば、管理システム１６０は、ネットワークおよび／またはサービス・プロビジョニング機能、ネットワーク監視機能など、ならびにそのさまざまな組合せのうちの１つまたは複数を提供することができる。一実施形態では、管理システム１６０は、無線アップリンク制御能力の１つまたは複数の機能をサポートし、かつ／または提供するように構成される。

無線アップリンク・コントローラ１７０は、無線アップリンク制御能力のさまざまな機能を提供するように構成される。一実施形態では、無線アップリンク・コントローラは、ビデオ・セッション・スケジューリング能力のさまざまな機能を提供するように構成されたスケジューラ１７１を含む。一実施形態では、無線アップリンク・コントローラは、ビデオ・セッション管理能力のさまざまな機能を提供するように構成されたマネージャ１７２を含む。少なくともいくつかの実施形態で、スケジューラ１７１およびマネージャ１７２が、無線アップリンク制御能力のさまざまな機能を提供するために協力することができることに留意されたい。無線アップリンク・コントローラ１７０の動作は、図１の例示的な無線通信ネットワーク１００などの無線エコシステムのさまざまな態様と、図１の例示的な無線通信ネットワーク１００などの無線エコシステムでのビデオの作成および送達のプロセスに用いられるさまざまな要素をまず考慮することによって、よりよく理解することができる。

一般に、複数の要素および／または能力を、図１の例示的な無線通信ネットワーク１００などの無線エコシステム内でのビデオの作成および送達のプロセスに用いることができる。たとえば、そのような要素および／または能力は、（１）無線アクセス・ネットワーク能力（たとえば、帯域幅、サービス品質（ＱｏＳ）、コール・アドミッション・コントロール（ｃａｌｌ ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ、ＣＡＣ）など）、（２）アプリケーション（たとえば、ビデオ・チャット、放送用の生ビデオ、ウェブ・ポータルへの生またはバックグラウンドでのアップロードなど）およびプロトコル（たとえば、リアルタイム・トランスポート・プロトコル（ＲＴＰ）／リアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）、適応ハイパーテキスト転送プロトコル（Ａｄａｐｔｉｖｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）など）、（３）コーデックおよび関連するカプセル化／カプセル化解除能力（たとえば、Ｈ．２６３、Ｈ．２６４／ＡＶＣ、ＳＶＣ、ＶＰ８^＊、Ｍｉｃｒｏｓｏｆｔ ＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、ハイパーテキスト・マークアップ言語５（ＨＴＭＬ５）など）、ならびに（４）モバイル・デバイス能力（たとえば、カメラの個数およびタイプ、カメラ解像度、符号化能力、処理能力など）のうちの１つまたは複数を含むことができるが、これに限定はされない。そのような能力の追加の説明を、本明細書で提供する。

一般に、図１の例示的な無線通信ネットワーク１００は、無線アクセス・ネットワークの包括的なアーキテクチャを提供する。少なくともいくつかの実施形態では、次の仮定を、図１の例示的な無線通信ネットワーク１００について設けることができる。（１）インターネット・プロトコル・バージョン４（ＩＰｖ４）および／またはバージョン６（ＩＰｖ６）のエンドツーエンド・サポートが使用可能であり、（２）異なるＱｏＳレベルでのフローの扱いが、サポートされまたは少なくとも使用可能であり、（３）ボトルネックは、無線リンクで発生する可能性があり（無線リンク帯域幅は、技術にまたがって変化し、一般に、各世代に伴って改善される傾向があるが、ビデオの帯域幅要件は、非常に大きく、高品位（ＨＤ）ビデオについて８Ｍｂｐｓを超え、したがって、かなり長い間問題を提示し続ける可能性がある）、（４）アーキテクチャは、多くの点で、ＭＤ１１０からＷＰＮ１３０のエッジのゲートウェイ（たとえば、ＧＧＳＮ、ＰＧＷ、またはＷＰＮ１３０とＰＮ１４０との間の他の類似するゲートウェイ）への多少閉じられた標準規格への適合によって縛られる可能性があり、（５）コール・アドミッション・コントロール（ＣＡＣ）がサポートされ、適当なリソースが、サービスによって作られるエンドツーエンド・フローに対処するのに使用可能である、とシステムが判断する場合に、サービスが許され（これが、通常、ベスト・エフォート（ＢＥ）サービスではなくｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ（ＧＢＲ）サービスに適用されることに留意されたい）、（６）ＲＡＮ１２０、ＷＰＮ１３０、および／またはＰＮ１４０からの情報を、アプリケーション・レベルでインテリジェントな判断を行うために活用することができる。これらの仮定のうちの１つまたは複数を、必要に応じておよび／または望み通りに変更しまたは除去できることに留意されたい。さらに、無線アップリンク制御能力のさまざまな実施形態を提供する際に、さまざまな他の仮定に頼ることができることに留意されたい。

図１の例示的な無線通信ネットワーク１００では、ビデオを無線アップリンク上でＭＤ１１０からＲＡＮ１２０に送信できる多数のシナリオがある。

そのようなシナリオの第１の例は、１対１関係、１対多関係、またはビデオ会議に関する多対多関係さえ有する両方向ビデオ・セッションを含むことができるビデオ・チャットである。たとえば、いくつかのビデオ・チャット・アプリケーションは、ｉＰｈｏｎｅ ＦａｃｅＴｉｍｅ、Ｑｉｋ Ｃｈａｔなどを含む。

そのようなシナリオの第２の例は、単一方向ビデオ・セッションが音声呼に付随する（たとえば、この場合に、ビデオ送信側は、おそらくはシーンを説明しつつあり、ビデオは、音声に同期化される必要がない）、ビデオ共有である（ビデオ・チャットの変形形態と考えることができる）。

そのようなシナリオの第３の例は、ビデオの単一方向１対多分配を提供するビデオ・ブロードキャストである。一実施形態では、ビデオは、ＭＤ１１０から中央サーバにストリーミングされ、この中央サーバは、ＭＤ１１０からビデオを受信し、そのビデオを１つまたは複数の他の伝送媒体を介して送信する。一例として、ニュース・レポータは、ＭＤ１１０を介してビデオを録画することができかつ、ＭＤ１１０からブロードキャスタの制御室の中央サーバにビデオをストリーミングし（たとえば、セルラ通信能力および／または他の適切な能力を備えるビデオ・カメラを使用して）、中央サーバが、必要に応じてビデオを変更でき（たとえば、バナー、ロゴなどを用いて）、その後、そのビデオを通常の形で視聴者にブロードキャストできるようになっている。この例では、ＭＤ１１０が、レポータがそのようなレポートを提供するために、そうでなければ要求されるはずの高価で面倒な衛星幹線を置換できることに留意されたい。これが、単に、ビデオ・ブロードキャスト・シナリオの使用の一例であり、ビデオ・ブロードキャストを、さまざまな他の形でさまざまな他の目的に使用できることに留意されたい。

そのようなシナリオの第４の例は、マルチキャスト・ストリームおよび／または複数のユニキャスト・ストリームとして視聴者に直接に送信されるビデオの単一方向１対多分配を提供するビデオ・マルチキャストである。一般に、このタイプのサービスを利用できるいくつかのタイプのアプリケーションは、救急サービス（たとえば、事故のシーンからのビデオ・フィードを救急管理担当者、近くの病院の医師などに提供する）、生消費のためのリゾート・エリア・ブロードキャスト、リモート・ロケーションからのリアリティ・テレビジョンなどを含むことができる。

そのようなシナリオの第５の例はビデオがＭＤ１１０からネットワーク宛先（たとえば、ウェブサイトまたはクラウド内の他のロケーション）にストリーミングされ、その結果、ビデオが到着する時にリアルタイムでおよび／またはビデオがアーカイブされる場合にその後に、ビデオを、ネットワーク宛先から見ることができるようになる、ビデオトゥークラウド（ｖｉｄｅｏ−ｔｏ−ｃｌｏｕｄ）である。一実施形態では、ビデオの潜在的な視聴者に、ビデオの可用性について通知することができる（たとえば、「生」ビデオが進行中であり、かつ／または将来に使用可能になることの表示）。一実施形態では、ビデオの潜在的な視聴者に任意の適切な形で（たとえば、ショート・メッセージ・サービス（ＳＭＳ）メッセージ、電子メールなどを介する）ビデオの可用性について通知することができる。一実施形態では、ビデオの可用性に関する潜在的な視聴者への通知は、潜在的な視聴者がビデオにアクセスできる形（たとえば、ユニフォーム・リソース・ロケータ（ＵＲＬ）または任意の他の適切な機構を使用して）に関する表示を含む。たとえば、いくつかのビデオトゥークラウド・アプリケーションは、Ｑｉｋ、Ｋｎｏｃｋｉｎｇ Ｌｉｖｅ、およびＹｏｕＴｕｂｅを含む。

前述のシナリオが、例示的であり、さまざまな他のシナリオが、ＭＤ１１０とＲＡＮ１２０との間の無線アップリンクを介するビデオのストリーミングを利用できることに留意されたい。

一般に、例示的なビデオ送信シナリオのそれぞれは、その十分なまたは最適の有用性のために、推奨または要件の関連するセットを有する可能性がある。たとえば、そのような推奨または要件は、ビデオ品質、ビデオ送達モード、ビデオ・アプリケーション優先順位、ビデオ・アプリケーション・プロトコルなど、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。一般に、ビデオ品質は、見られるビデオの品質を構成する空間パラメータ、時間パラメータ、および／または量子化パラメータの組合せ（最終的に、ビデオの送信ビット・レートおよび／またはビデオをサポートするのに必要な帯域幅になる）に対応する。一般に、ビデオ送達モードは、ビデオの始まりのタイミングに対応する。一実施形態では、３つのビデオ・送達モードが、次のようにサポートされる：（１）リアルタイム（ＲＴ）、ビデオの送達がリアルタイムになることを示す、生ストリーミング・サービス（たとえば、ビデオの送達の始めは、即座にまたはほぼ即座に始まる）、（２）近リアルタイム（ＮＲＴ）、ビデオの送達の始めを遅延させることができることを示す、やはり生ストリーミング・サービス、および（３）バックグラウンド（ＢＧ）、ビデオのバックグラウンド送達を示す（たとえば、ファイル転送または、送達を任意の適切な長さの時間だけ遅延させることができる他のタイプのビデオなど）。一般に、ビデオ・アプリケーションのビデオ・アプリケーション優先順位は、相対的に高い体感品質（ＱｏＥ）を提供するための、他のビデオ・アプリケーションに対する相対的なビデオ・アプリケーションの優先順位に対応する。一般に、ビデオ・アプリケーションのビデオ・アプリケーション・プロトコルは、ビデオ・アプリケーションを使用可能にするのに使用されるプロトコルのクラスに対応する（たとえば、ストリーミング・ビデオがＲＴＰまたはＨＴＴＰを使用できる場合）、バックグラウンド・ビデオとしてファイル転送プロトコル（ＦＴＰ）サービスを利用できる場合。他の推奨および／または要件をこのコンテキスト内でサポートできることに留意されたい。

多くのビデオ・アプリケーションでは、（１）ビデオ送信側が、ビデオが使用可能であることをビデオ受信側に通知することを可能にし、ビデオ受信側が、ビデオ送信側からの招待を受け入れることができることを可能にするための機構を含むことができる、接続を作成する機構と、（２）コール・アドミッション・コントロール（ＣＡＣ）機能と、（３）ビデオ送信側からビデオ受信側へビデオをトランスポートするビデオ・パケットのＱｏＳ処理を提供することとを含む、ビデオのストリーミングをサポートするための接続を確立し維持するのに通常用いられる３つの機能がある。これらの機能を、下でさらに詳細に説明する。ビデオ・アプリケーションが、ネットワーク・サービス・プロバイダ（ＮＳＰ）からのＣＡＣおよび差別化されたＱｏＳを利用し始めた後に、オーバーザトップ（ＯＴＴ）アプリケーションは、ベスト・エフォート（ＢＥ）サービスだけを受信するので、特に輻輳の時に、不利になることに留意されたい。

一般に、少なくともいくつかのビデオ・アプリケーションについて、ビデオ・セッションは、ビデオ・アプリケーションのコンテキスト内でビデオの送信をサポートするために作成される。たとえば、ビデオ・チャット・アプリケーションについて、ビデオ・セッション作成機構は、多数の変形形態が可能であるボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）呼の確立に類似するものとすることができる。たとえば、いくつかのビデオ・アプリケーション（たとえば、Ｓｋｙｐｅおよび他）は、プロプライエタリ実施態様を有し、他のビデオ・アプリケーション（たとえば、Ａｐｐｌｅ社のＦａｃｅＴｉｍｅおよび他）は、標準規格（たとえば、Ｈ．２６４、Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ（ＡＡＣ）、セッション開始プロトコル（ＳＩＰ）、ＲＴＰ、セキュア・リアルタイム・トランスポート・プロトコル（ＳＲＴＰ）などの標準規格）に基づく実施態様を有する。たとえば、Ａｐｐｌｅ ＦａｃｅＴｉｍｅによって使用されるものなどの標準規格ベースの手法の使用を仮定すると、ビデオ・セッションを確立する基本的なメッセージ・フローは、次のステップを含むことができる：（１）開始するクライアントが、既知のサーバと（たとえば、この例では、ネットワーク内のＡｐｐｌｅサーバ）、ビデオ接続を確立する要求を開始し、ここで、要求は、ＳＩＰ ｉｎｖｉｔｅの形とすることができ、（２）ＳＩＰ ｉｎｖｉｔｅは、開始するクライアントから見るクライアントに提供され（ここで、すべての当事者が既に登録済みであると仮定する）、（３）見るクライアントからのＳＩＰ ＯＫメッセージの受信に続いて、メッセージングが、ビデオ接続のオーディオ／ビデオ・パラメータをネゴシエートするために交換され、（４）ビデオ・セッションの確立に続いて、ビデオ／オーディオが、ＲＴＰを介して２つの参加者の間で交換される（ここで、サーバが、必ずしもビデオ／オーディオ経路内にないことに留意されたい）。この全般的なメッセージ・フローが、単に例示であることに留意されたい。この全般的なプロセスの使用ならびにこの全般的なプロセスの変形形態は、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）標準規格によるこのプロセスの扱いの説明を参照することによってよりよく理解することができる。さらに、任意の他の適切なプロセスを、ビデオ・アプリケーションのビデオ・セッションを確立するのに使用することができることに留意されたい（たとえば、このプロセスの異なる変形形態を、他のビデオ・チャット・アプリケーションならびに他のタイプのビデオ・アプリケーションに使用することができ、他のタイプのプロセスなど、ならびにそのさまざまな組合せを使用することがでる）。

一般に、少なくともいくつかのビデオ・アプリケーションについて、単一方向ビデオ・セッションを、ビデオ・アプリケーションのコンテキスト内でビデオの送信をサポートするために確立することができ、単一方向ビデオ・セッションは、サポートされる（１つまたは複数の）アプリケーションの（１つまたは複数の）タイプに応じて異なるものとすることができる。これを、下で、単一方向ビデオ・セッションを使用するいくつかの例示的なビデオ・アプリケーションに関して説明する。

たとえば、ビデオ共有アプリケーションに関して、単一方向ビデオ・セッションの確立を、ビデオ・チャット・アプリケーションのそれに類似する形で実行することができるが、ビデオ共有アプリケーションでは、ビデオは、音声から遅れる場合があり、したがって、ビデオ共有アプリケーションでのビデオ・トランスポートのＱｏＳ要件は、一般に、ビデオ・チャット・アプリケーションより非厳格である。

たとえば、放送テレビジョン・アプリケーションのビデオ・ブロードキャストに関して、単一方向ビデオ・セッションを確立し、維持する実施態様を、特定のアプリケーションに適するためにプロプライエタリとすることができる。多くの場合に、ビデオの短待ち時間送達がクリティカルである（たとえば、ニュース・アンカとレポータとの間のオーディオ交換は、見られているものと一致しなければならない）。したがって、多くの場合に、失われたビデオ・フレームを取り出すことを試みる点がないので、ビデオを、伝送制御プロトコル（ＴＣＰ）接続ではなくユーザ・データグラム・プロトコル（ＵＤＰ）を使用してストリーミングすることができる。

たとえば、必ずしもビデオの送達を容易にすることができるアーキテクチャ内のアプリケーションがない、企業アプリケーションのビデオ・マルチキャスト／ブロードキャストに関して、ＮＳＰネットワーク内のインフラストラクチャを使用して、潜在的な視聴者へのＩＰマルチキャスト／ブロードキャストを使用可能にすることができる。このシナリオは、異なるタイプのそのようなアプリケーションについて異なる待ち時間要件を有する可能性がある（たとえば、短待ち時間ストリーミングが、緊急サービス・アプリケーションに要求されるが、「リゾート」タイプ・アプリケーションは、ビデオ・ストリーミングの実際の始めに遅延を許容できる場合がある）。

たとえば、消費者サイト・アプリケーションのビデオトゥークラウドに関して、ビデオは、特定のアプリケーションに応じて、生で見られる必要がある場合とない場合がある。この場合に、ビデオが時間に敏感ではない場合には、数十秒の遅延、数分の遅延、またはより長い遅延が、許容可能である場合がある。多くの場合に、サイトは、生であるものとしてビデオ・フィードを広告することができ、したがって、関連するビデオ・アプリケーションは、一般に、使用可能な帯域幅を考慮して最良の可能なサービスを提供するように設計される。その結果、多くのそのようなアプリケーションは、より少ない帯域幅を要求するより低い品質レベルでではあるが、放送テレビジョン・モデルの技法に似た技法を使用する。

一般に、さまざまな他のタイプのビデオ・セッションを、上記および／または他のタイプのビデオ・アプリケーションのために確立することができる。本明細書で説明するように、そのようなビデオ・セッションを、無線ネットワークの無線アップリンクを介してサポートすることができ、本明細書ではアップリンク・ビデオ・セッションとも称する。本明細書でさらに説明するように、そのようなアップリンク・ビデオ・セッションを、無線アップリンク制御能力のさまざまな実施形態を使用して制御することができる。

上で説明したように、無線アップリンク・コントローラ１７０は、無線アップリンク制御能力のさまざまな機能を提供するように構成される。一実施形態では、ビデオ・セッション・スケジューリング能力が、セルラ・セクタのモバイル・デバイスによるビデオ送信のスケジューリングのために提供される（たとえば、モバイル・デバイスが無線アップリンクを介するビデオ送信を開始できる時刻、無線アップリンクを介するビデオ送信に関する送信ビット・レート割振りなど、セルラ・セクタの無線アップリンクを介するモバイル・デバイスによるビデオ送信に関連する１つまたは複数のパラメータのスケジューリング）。ビデオ・セッション・スケジューリング能力は、セルラ・セクタのモバイル・デバイスのビデオ・アプリケーションが無線アップリンク上の適当な帯域幅を予約／保護することを可能にすることによって、セルラ・セクタの無線アップリンクを介してビデオを送信するビデオ・アプリケーションの信頼性を改善する。一実施形態では、ビデオ・セッション・スケジューリング能力のさまざまな機能は、図１に関して図示され、説明されるスケジューラ１７１によって提供される。

スケジューラ１７１は、図示され本明細書で説明されるように、例示的な通信システム１００のコンポーネントのうちの１つまたは複数のさまざまな機能を利用することができる。たとえば、スケジューラ１７１は、管理システム（たとえば、管理システム１６０および／またはそのような情報の任意の他の適切なソース）からアップリンク・リソース情報を受信することができる。たとえば、スケジューラ１７１は、ＭＤ１１０からアップリンク・ビデオ・セッション要求を受信することができる。たとえば、スケジューラ１７１は、ＲＡＮ１２０および／またはＷＰＮ１３０からモバイル・デバイス・ロケーション情報を受信することができ、スケジューラ１７１は、ＭＤ１１０ごとに、ＭＤ１１０が接続されるセルラ・セクタ（実例として、ＭＤ１１０_１〜１１０_Ｎのセルラ・セクタ１２３）を判定することができる。たとえば、スケジューラ１７１は、リソースの要求を満足できるかどうかを判定するように構成されたコール・アドミッション・コントロール（ＣＡＣ）機能と通信することができる。たとえば、スケジューラ１７１は、ＲＡＮ１２０および／またはＷＰＮ１３０から、リソース輻輳の存在および同様にリソース輻輳の緩和を示すトリガを受信することができる。一実施形態では、そのようなトリガを、ＲＡＮ１２０および／またはＷＰＮ１３０から明示的構成通知（Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ、ＥＣＮ）の形で提供することができる。スケジューラ１７１は、例示的な通信システム１００のコンポーネントのうちの１つまたは複数のさまざまな他の機能を利用することができる。

スケジューラ１７１は、セルラ・セクタ１２３のアップリンク・ビデオ・セッションのスケジューリングを管理するように構成される。

スケジューラ１７１は、セルラ・セクタ１２３のＭＤ１１０のアップリンク・ビデオ・セッションに関する要求を受信し、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションのスケジューリングに使用される情報を受信し、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションのスケジューリングに使用される受信された情報に基づいてセルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定し、セルラ・セクタ１２３のＭＤ１１０のアップリンク・ビデオ・セッション要求に応答してアップリンク・ビデオ・セッション応答を提供するように構成される。

スケジューラ１７１は、セルラ・セクタ１２３のＭＤ１１０のアップリンク・ビデオ・セッションに関する要求を受信する。一般に、アップリンク・ビデオ・セッションに関するＭＤ１１０による要求は、アップリンク・ビデオ・セッション要求に関連する情報を含む（たとえば、アップリンク・ビデオ・セッションの要求される送信ビット・レート、アップリンク・ビデオ・セッションに関連する送達モードの表示、アップリンク・ビデオ・セッションが関連するアプリケーションのタイプなど、およびそのさまざまな組合せ）。スケジューラ１７１は、ＭＤ１１０からアップリンク・ビデオ・セッションに関する要求を受信することができ、かつ／またはネットワークの１つまたは複数のＣＡＣ機能（たとえば、ＭＤ１１０のアップリンク・ビデオ・セッション要求を受信し、これらをスケジューラ１７１にルーティングし、かつ／またはＭＤ１１０のアップリンク・ビデオ・セッション要求を受信し、適当な対応するアップリンク・ビデオ・セッション要求をＭＤ１１０の代わりにスケジューラ１７１に送信するように動作することができる）からアップリンク・ビデオ・セッションに関する要求を受信することができる。どの場合でも、スケジューラ１７１は、セルラ・セクタ１２３のＭＤ１１０によって要求されるアップリンク・ビデオ・セッションの表示を受信する。

スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションのスケジューリングに使用される情報を受信し、この情報は、セルラ・セクタ１２３内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報、アップリンク・ビデオ・セッションに関するＭＤ１１０による要求に関連するビデオ・セッション要求情報、ＭＤ１１０のＭＤ状況情報、セルラ・セクタ１２３のセルラ・セクタ状況情報、ネットワーク状況情報（たとえば、ＲＡＮ１２０、ＷＰＮ１３０、ＰＮ１４０などのうちの１つまたは複数の）、サービス・プロバイダ・ポリシなど、およびそのさまざまな組合せを含むことができる。

スケジューラ１７１は、セルラ・セクタ１２３内でアップリンク・ビデオ・セッションをサポートするためにセルラ・セクタ１２３内で割り振られた無線アップリンク・リソースの量（本明細書では無線アップリンク・リソースのバジェットとも表される）を示す情報を受信する。この情報は、セルラ・セクタ１２３の現在のリソース割振り、セルラ・セクタ１２３の最大のリソース割振り、セルラ・セクタ１２３の使用可能なリソース・パラメータなど、およびそのさまざまな組合せのうちの１つまたは複数を使用して表すことができる。

セルラ・セクタ１２３のリソースは、セルラ・ネットワーク内のセルラ・セクタの任意の適切なリソースとすることができる。一実施形態では、たとえば、セルラ・セクタ１２３のリソースは、セルラ・セクタ１２３のＢＳ１２２によってサポートされるエア・インターフェース上の物理リソース・ブロック（ＰＲＢ）である（この場合に、リソースのバジェットは、ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮと表される）。一般に、ある個数のＰＲＢのが、ＭＤ１１０からの無線アップリンク送信をその間に行うことができるセルラ・セクタ１２３内の各タイム・スライス内で使用可能である。アップリンク・ビデオ・セッションのスケジューリングの基礎としての、ＰＲＢまたは任意の類似するタイプのリソースの使用は、ＭＤ１１０ごとに、ＭＤ１１０に割り振られるＰＲＢの個数がＭＤ１１０の総送信ビット・レートに変換されるので、有利である。これは、主に、異なるＭＤ１１０が、ＢＳ１２２との異なる信号対雑音比（ＳＮＲ）を有する可能性があり、これが、それぞれのＭＤ１１０が使用する変調符号化方式（ＭＣＳ）に変換され、このＭＣＳが、何ビットの情報を単一のＰＲＢ内でそれぞれのＭＤ１１０によって送信できるのかを決定するという事実に起因する（たとえば、一般に、ＢＳ１２２のより近くに配置されたＭＤ１１０は、ＢＳ１２２からより遠くに配置されたＭＤ１１０より多くのビットを所与のＰＲＢ内で送信することができる）。

セルラ・セクタ１２３の無線アップリンク・リソースのバジェットを、そのような情報の任意の適切なソースから受信することができる。一実施形態では、たとえば、セルラ・セクタ１２３の無線アップリンク・リソースのバジェットを、管理システム１６０から（たとえば、ＯＡＭシステムまたは任意の他の適切なタイプのシステムから）受信することができる。

スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介するＭＤ１１０からのビデオ・コンテンツの送信のためにアップリンク・ビデオ・セッションを確立するために、ＭＤ１１０による要求に関連するビデオ・セッション要求情報を受信する。ビデオ・セッション要求情報を、アップリンク・ビデオ・セッション要求の一部として受信し、かつ／またはアップリンク・ビデオ・セッション要求の受信に応答して入手することができる。ビデオ・セッション要求情報は、送信ビット・レート要求情報（たとえば、ＭＤ１１０によって要求された、要求された送信ビット・レート、ＭＤ１１０が受け入れ可能な最小送信ビット・レートなど）、アップリンク・ビデオ・セッションを介して提供されるビデオ・ストリームのタイプ、アップリンク・ビデオ・セッションの送達モード（たとえば、ＲＴ、ＮＲＴ、またはＢＧ）、アップリンク・ビデオ・セッションの開始を遅延できる最大時間を示すタイムアウト遅延値、ＭＤ１１０のユーザのサービス・レベル契約（ＳＬＡ）に関連する情報、ＭＤ１１０に関連するデバイス能力情報、アップリンク・ビデオ・セッションの１つまたは複数の所期のビデオ受信側のリスト、アップリンク・ビデオ・セッションに関する１つまたは複数の所期のビデオ受信側に関連するデバイス能力情報、アップリンク・ビデオ・セッションを確立するためのＭＤＤ １１０による要求に関連する情報のタイプのうちの１つまたは複数のネゴシエーション可能性（ｎｅｇｏｔｉａｂｉｌｉｔｙ）の範囲を示す１つまたは複数のネゴシエーション可能性パラメータなど、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。

スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定するのに使用できる追加のタイプの情報を受信することができる。

一実施形態では、たとえば、スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用されるＭＤ１１０のＭＤ状況情報（たとえば、ＭＤ１１０の信号強度の条件および／またはＭＣＳを示す情報、ＭＤ１１０のバッテリ電力状況を示す情報など）を受信することができる。一実施形態では、たとえば、スケジューラ１７１は、ＭＤ１１０の帯域幅要件（ビデオの所望の品質によって駆動される）をＭＤ１１０のＭＣＳ（それぞれのＭＤ１１０が無線アップリンクを介してデータを送信できる効率を規定する）に結合することによって、ＭＤ１１０に重みを付けるように構成される。いくつかの場合に、スケジューラ１７１は、よい信号強度を有する、高いビデオ品質要件を有するＭＤ１１０に優先権を与える。いくつかの場合に、スケジューラ１７１は、最適未満の信号強度を有する、低いビデオ品質要件を有するＭＤ１１０に優先権を与える。

一実施形態では、たとえば、スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用される、セルラ・セクタ１２３のセルラ・セクタ状況情報（たとえば、セルラ・セクタ１２３のセル負荷、セルラ・セクタ１２３に関連するデータ経路から受信されたＥＣＮなど）を受信することができる。

一実施形態では、たとえば、スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用される、ＲＡＮ１２０、ＷＰＮ１３０、および／またはＰＮ１４０の１つまたは複数の部分のネットワーク状況情報（たとえば、ネットワーク部分の負荷、ネットワーク部分に関連するデータ経路から受信されたＥＣＮなど）を受信することができる。

一実施形態では、たとえば、スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用される、サービス・プロバイダのサービス・プロバイダ・ポリシを受信することができる。

スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用できる任意の他の適切なタイプの情報を受信することができる。

スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介してサポートされるアップリンク・ビデオ・セッションをスケジューリングする際に使用される受信された情報に基づいて、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定する。

一実施形態では、スケジューラ１７１は、アップリンク・ビデオ・セッションが開始できる時刻を決定し、アップリンク・ビデオ・セッションのビット・レート割振りを決定することによって、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定する。

一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３内で使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報とアップリンク・ビデオ・セッション要求に関連するビデオ・セッション要求情報とに基づいて（および、オプションで、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定する時に検討することができる１つまたは複数の他のタイプの情報にも基づいて）、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定する。

一実施形態では、スケジューラ１７１は、スケジューリングされるアップリンク・ビデオ・セッションの送達モードの少なくとも部分的に基づいて、アップリンク・ビデオ・セッションのスケジューリングを決定するように構成される（たとえば、アップリンク・ビデオ・セッションの送達モードを、ビデオ・セッションを開始できる時刻を決定するのに使用できる場合）。一実施形態では、本明細書で上で注記したように、ビデオ・セッションの３つの可能な送達モードは、（１）厳格な待ち時間要件および遅延要件を有する生ビデオを示すが、帯域幅使用を可変とすることができるＲＴ、（２）ＲＴ送達のためにローカルにバッファリングされるビデオを示し（たとえば、ビデオのタイプ、ＭＤ１１０のバッファリング能力などに基づいて変更できる比較的短い時間期間内に）、より非厳格な待ち時間要件および遅延要件を有し、したがって送達に関するより高い柔軟性を有するＮＲＴ、および（３）ビデオを任意の時に提供できることを示すＢＧを含む。

送達モードのコンテキスト内で、スケジューラ１７１を、アプリケーションのタイプおよびオプションでＭＤ１１０によって要求される送達モード（ＭＤ１１０が、望まれるが、要求されるビデオ・セッションのアプリケーションのタイプについて必要ではないビデオ・セッションの送達モードを要求できる場合）に基づいて決定される送達モードを考慮に入れるように構成することができることに留意されたい。

本明細書で上で説明したように、ビデオ・セッションは、ＲＴ処理を要求してもしなくてもよい。たとえば、「ビデオ・チャット」アプリケーション（たとえば、１対１呼または電話会議）は、ＲＴの送達モードを有する。たとえば、ビデオ共有アプリケーションでは、音声をＲＴとすることができるが、ビデオは、必ずしも音声会話と同期化される必要がなく、したがって、ＮＲＴの関連する送達モードを有することができる。たとえば、ビデオ・セッションが、対話を伴わない１対多シナリオである場合には、ビデオの緊急性に応じて、ビデオを、任意の適切な遅延の後にＮＲＴ送達モードを使用して送信することができる。たとえば、さまざまな他のビデオ・アプリケーションは、バックグラウンドでビデオを送信することを許容可能と考えることができる（たとえば、ウェブサイトにビデオを提供するため、ビデオのオフピーク分配を提供するためなど）。少なくとも１つの実施形態では、スケジューラ１７１は、ビデオ・セッション要求のスケジューリングを決定するのに、ビデオ・セッションの送達モードの要件を使用するように構成される。

さらに、上で注記したように、ＭＤ１１０は、要求されたビデオ・セッションのアプリケーションのタイプに必要ではない送達モードを要求することができる（たとえば、ＭＤ１１０が、音声会話との同期化なしでストリーミングできるビデオ共有アプリケーションからのビデオのＲＴ処理を要求する場合、ＭＤ１１０が、ＢＧ送達モードを使用して処理できるビデオ・セッションのＮＲＴ処理を要求する場合など）。少なくとも１つの実施形態では、スケジューラ１７１は、ビデオ・セッション要求のスケジューリングを決定するのに、ビデオ・セッションに関してＭＤ１１０によって要求された送達モードを使用するように構成される。

したがって、そのような送達モードの異なる特性のそのような理解を用いて、ビデオ・セッションを、ユーザの知覚するＱｏＥに影響せずに、より知的にスケジューリングすることができる。

スケジューラ１７１は、セルラ・セクタ１２３のアップリンク・ビデオ・セッション要求を管理するキューのセットを維持する。１つのそのような実施形態では、セルラ・セクタのキューのセットは、セルラ・セクタ１２３のＭＤ１１０のＮＲＴアップリンク・ビデオ・セッション要求をキューイングするのに使用されるＮＲＴキューと、セルラ・セクタ１２３のＭＤ１１０のＢＧアップリンク・ビデオ・セッション要求をキューイングするのに使用されるＢＧキューとを含む。他のタイプの送達モードがサポートされる場合に、スケジューラ１７１を、送達モードに関する適当なタイプのキューをサポートするように構成できることに留意されたい。

一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定するのに、さまざまなプロセスを使用するように構成される。このプロセスは、ＶｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセス、ＶｉｄｅｏＳｅｓｓｉｏｎＥｎｄｅｄプロセス、ＶｉｄｅｏＳｅｓｓｉｏｎＣｈａｎｇｅｄプロセス、ＳｙｓｔｅｍＲｅｓｏｕｒｃｅＣｈａｎｇｅプロセス、ｎｒｔＴｉｍｅｏｕｔプロセス、ｎｒｔＥｘｉｔＦｒｏｍＳｅｃｔｏｒプロセス、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセス、ｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセス、およびｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを含む。そのようなプロセスを説明する際の明瞭さのために、プロセスは、主に、スケジューラ１７１が、セルラ・セクタ１２３内のアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報を受信し、セルラ・セクタ１２３内の無線アップリンクを介するＭＤ１１０からのビデオ・コンテンツの送信のためにアップリンク・ビデオ・セッションを確立するためにＭＤ１１０による要求に関連するビデオ・セッション要求情報（たとえば、要求された送信ビット・レートおよび関連する送達モードを含む）を受信し、セルラ・セクタ１２３内で使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報とアップリンク・ビデオ・セッション要求に関連するビデオ・セッション要求情報とを使用してセルラ・セクタ１２３内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを決定する実施形態のコンテキスト内で説明される。明瞭さのためにプロセスの説明からは主として省略されるが、スケジューラ１７１が、これらのプロセスのコンテキスト内でセルラ・セクタ１２３内の無線アップリンクを介するビデオ・セッションのスケジューリングを決定するのに使用できる１つまたは複数の追加のタイプの情報をも受信することに留意されたい。

一実施形態では、スケジューラ１７１は、次のイベントが到着する時に、これらのイベントに作用するように構成される。

（１）Ｖｉｄｅｏ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ（ビデオ・セッション要求）
一実施形態では、スケジューラ１７１は、ＭＤ１１０がビデオ・セッションのリソースを予約するためにスケジューラ１７１にビデオ・セッション要求を送信する時に、ＶｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスを実行するように構成される。ビデオ・セッション要求は、ＭＤ１１０が関連するセルラ・セクタ内でのビデオ・セッションのスケジューリングを決定する際のスケジューラ１７１による使用のために構成されたビデオ・セッション要求情報を含む。たとえば、ビデオ・セッション要求情報は、ＭＤ１１０の送信ビット・レート要求（ＴｘＭＡＸと表される）、ＭＤ１１０が許容可能な最小送信ビット・レート（ＴｘＭＩＮと表される）、ビデオ・セッションの所期の（１つまたは複数の）ビデオ受信側、ビデオ・セッションの送達モード（たとえば、ＲＴ、ＮＲＴ、ＢＧ）、ビデオ・セッションの始めを遅延できる最大時間を示すタイムアウト遅延（ＤＥＬＡＹと表される）など、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。たとえば、ビデオ・セッション要求情報は、任意の適切な個数およびタイプのネゴシエーション可能性パラメータ値（たとえば、ＨＡＲＤ（関連する（１つまたは複数の）パラメータの非ネゴシエーション可能性を示す））およびＳＯＦＴ（（１つまたは複数の）パラメータがネゴシエーション可能であることと、オプションで（１つまたは複数の）パラメータのネゴシエーション可能性の範囲とを示す）をサポートできる場合に、他のパラメータのうちの１つまたは複数のネゴシエーション可能性の範囲を示す（１つまたは複数の）ネゴシエーション可能性パラメータをも含むことができる。

ビデオ・セッション要求の送達モードがＲＴである場合に、スケジューラ１７１は、次の２つの条件（１）ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＋ＴｘＣＢＲ_ＰＲＢ＜ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮおよび（２）ＴｘＭＡＸ≦ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}≧ＴｘＭＩＮが満足されるように、現在のビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}と表される）をネゴシエートする。そうである場合に、スケジューラ１７１が、セルラ・セクタが要求されたビデオ・セッションに十分なリソースを有すると判定する場合に、スケジューラ１７１は、（１）ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＝ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＋ＴｘＣＢＲ_ＰＲＢのようにＴｘＣＢＲ_ＰＲＢを現在のＰＲＢ割振りに加算し、（２）ＭＤ１１０がビデオ・セッションを即座に開始できるように、ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}の値をＭＤ１１０に応答する。この場合に、スケジューラ１７１が、セルラ・セクタが要求されたビデオ・セッションに十分なリソースを有していないと判定し、ＲＴモードが、ＳＯＦＴ制約であるものとして示されていない場合には、スケジューラ１７１は、他のアクティブ・セッションを減らすことによって、要求されたビデオ・セッションの余地を作ることを試みるためにｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する（かつ、成功の場合に、（ａ）ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＝ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＋ＴｘＣＢＲ_ＰＲＢのようにＴｘＣＢＲ_ＰＲＢを現在のＰＲＢ割振りに加算し、（ｂ）ＭＤ１１０がビデオ・セッションを即座に開始できるようにＴｘＣＢＲ_{ｂｉｔｒａｔｅ}の値をＭＤ１１０に応答する）。この場合に、スケジューラ１７１が、セルラ・セクタが要求されたビデオ・セッションに十分なリソースを有していないと判定し、ＲＴモードが、ＳＯＦＴ制約であるものとして示されている合には、スケジューラ１７１は、セルラ・セクタのＮＲＴキューにビデオ・セッション要求を挿入するためにｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスを実行し、そうでない場合には、ビデオ・セッション要求を満足することはできない。

ビデオ・セッション要求の送達モードが、ＮＲＴまたはＢＧである場合には、スケジューラ１７１は、ビデオ・セッション要求の要件を即座に満足することが可能であるかどうかを判定する（たとえば、条件ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＋ＴｘＭＩＮ_ＰＲＢ＜ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮが満足されるかどうかを判定することによって）。この場合に、ビデオ・セッション要求の要件を即座に満足することが可能である場合には、スケジューラ１７１は、ビデオ・セッション要求を、ＲＴの送達モードを有するものとして扱いながら、ビデオ・セッション要求についてＶｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスを再実行する。この場合に、ビデオ・セッション要求の要件を即座に満足することが可能ではない場合には、スケジューラ１７１は、ビデオ・セッション要求をセルラ・セクタ１２３のＮＲＴキューまたはＢＧキューに適当に挿入するためにｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスを実行する。

（２）Ｖｉｄｅｏ Ｓｅｓｓｉｏｎ Ｅｎｄｅｄ（ビデオ・セッション終了）
一実施形態では、スケジューラ１７１は、ビデオ・セッションが終了するか、セルラ・セクタ１２３から新しいセルラ・セクタに移動され、これによって他のビデオ・セッションをサポートするためにセルラ・セクタ１２３のリソースが解放される時に、ＶｉｄｅｏＳｅｓｓｉｏｎＥｎｄｅｄプロセスを実行するように構成される。スケジューラ１７１は、ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＝ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ−ＴｘＣＢＲ_ＰＲＢのように、セルラ・セクタ１２３内のＰＲＢの現在の割振りから、終了されたビデオ・セッションに割り振られた送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）に対応するＰＲＢの量（ＴｘＣＢＲ_ＰＲＢ）を減算することによって、セルラ・セクタ１２３内のＰＲＢの現在の割振りを更新する。スケジューラ１７１は、セルラ・セクタ１２３の使用可能なリソースを他のビデオ・セッションに再割り振りするために、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する。

（３）Ｖｉｄｅｏ Ｓｅｓｓｉｏｎ Ｃｈａｎｇｅｄ（ビデオ・セッション変更）
一実施形態では、スケジューラ１７１は、ビデオ・セッションがセルラ・セクタ１２３内のＰＲＢのその割振り（たとえば、そのＴｘＣＢＲ_ＰＲＢまたはＴｘＭＡＸ_ＰＲＢの値）を減らされ、これによって他のビデオ・セッションをサポートするためにセルラ・セクタ１２３のリソースが解放される時に、ＶｉｄｅｏＳｅｓｓｉｏｎＣｈａｎｇｅｄプロセスを実行するように構成される。スケジューラ１７１は、ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＝ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ−（ＴｘＣＢＲ_{ＰＲＢ−ＯＬＤ}−ＴｘＣＢＲ_{ＰＲＢ−ＮＥＷ}）のように、セルラ・セクタ１２３内のＰＲＢの現在の割振りから、修正済みビデオ・セッションから解放されるビット・レートの量を減算することによって、セルラ・セクタ１２３内のＰＲＢの現在の割振りを更新する。その後、スケジューラ１７１は、セルラ・セクタの使用可能なリソースを他のビデオ・セッションに再割り振りするために、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する。

（４）Ｓｙｓｔｅｍ Ｒｅｓｏｕｒｃｅ Ｃｈａｎｇｅｄ（システム・リソース変更）
一実施形態では、スケジューラ１７１は、指定された時刻にまたは関連するタイマが満了する時に、ＳｙｓｔｅｍＲｅｓｏｕｒｃｅＣｈａｎｇｅプロセスを実行するように構成される。これは、たとえば、ある時刻にリソース変更を開始することが必要であるか望ましい場合に使用することができる。たとえば、スケジューラ１７１を、特定の時刻（たとえば、無線アップリンクを介するビデオの送信を介してレポートを提供するネットワーク・ニュース・アンカなどのプレミアム・ユーザに適当な無線アップリンク・リソースを保証するために午後５：００に）システム・リソースの増加を開始するように構成することができる。たとえば、スケジューラ１７１を、タイマの満了の後にシステム・リソースの減少を開始するように構成することができる。スケジューラ１７１は、さまざまな他の形で使用可能な無線アップリンクを変更するのにＳｙｓｔｅｍＲｅｓｏｕｒｃｅＣｈａｎｇｅプロセスを使用することができる。

一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３の使用可能なリソースの変化の表示に応答してＳｙｓｔｅｍＲｅｓｏｕｒｃｅＣｈａｎｇｅプロセスを実行するように構成される。

一実施形態では、セルラ・セクタ１２３の最大の使用可能なリソースの減少（すなわち、ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ値の減少）の表示に応答して、スケジューラ１７１は、ｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する。一実施形態では、スケジューラ１７１は、指定された時刻にまたは関連するタイマが満了する時に、ｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する。この変更を、セルラ・セクタ１２３への負荷の変化またはセルラ・セクタ１２３のリソース・バジェットの変化に起因するなど、任意の個数のイベントまたは条件に起因するものとすることができることに留意されたい。さらに、特定の時刻を、任意の適切な時刻とすることができ、同様に、タイマに、０以上の任意の適切な値をセットすることができる（０は、ｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスが即座に実行されることを示すはずである）ことに留意されたい。その後、スケジューラ１７１は、セルラ・セクタ１２３内のリソースの現在の割振りがセルラ・セクタ１２３の新しい最大の使用可能なリソース未満になるまで（すなわち、ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ≦ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＿ｎｅｗになるまで）セルラ・セクタ１２３内のすべての新しいビデオ・セッションを拒否するために、ｃｅｌｌＳｅｃｔｏｒ＿ＳｔａｔｅパラメータにＲＥＦＵＳＥをセットする。

一実施形態では、明示的構成通知（ＥＣＮ）メッセージの受信に応答して、スケジューラ１７１は、セルラ・セクタ１２３内のリソースの現在の割振りがセルラ・セクタ１２３の新しい最大の使用可能なリソース未満になるまで（すなわち、ＣＵＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ≦ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ＿ｎｅｗになるまで）セルラ・セクタ１２３内のすべての新しいビデオ・セッションを拒否するために、ｃｅｌｌＳｅｃｔｏｒ＿ＳｔａｔｅパラメータにＲＥＦＵＳＥをセットする。

一実施形態では、セルラ・セクタの最大の使用可能なリソースの増加の表示（たとえば、ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ値が減らされた）に応答して、スケジューラ１７１は、セルラ・セクタ１２３の使用可能なリソースを他のビデオ・セッションに再割り振りするために、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行する。

（５）ＮＲＴ Ｓｅｓｓｉｏｎ Ｔｉｍｅｏｕｔ（ＮＲＴセッションタイムアウト）
一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３のＮＲＴキュー内のビデオ・セッション要求がタイムアウトした時に、ｎｒｔＴｉｍｅｏｕｔプロセスを実行するように構成される。タイムアウトは、ビデオ・セッションが開始に時間がかかりすぎる場合またはビデオ録画が停止された場合など、複数の理由のうちのいずれについても発生し得る。スケジューラ１７１は、関連するＭＤ１１０に通知し、このＭＤ１１０は、タイムアウト・タイマをリセットする要求を応答してもしなくてもよい。ＭＤ１１０が、ビデオ・セッションのタイムアウト・タイマをリセットする要求を応答する場合に、スケジューラ１７１は、セルラ・セクタ１２３のＮＲＴキュー内にビデオ・セッション要求を残す。ＭＤ１１０が、ビデオ・セッションの送達モードをＮＲＴからＢＧに変更する要求を応答する場合に、スケジューラ１７１は、ビデオ・セッション要求をセルラ・セクタ１２３のＢＧキューに挿入する。

（６）ＮＲＴ Ｅｘｉｔ Ｆｒｏｍ Ｃｅｌｌｕｌａｒ Ｓｅｃｔｏｒ（セルラ・セクタからのＮＲＴ終了）
一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３のＮＲＴキュー内に現在保留中のビデオ・セッション要求を有するＭＤ１１０が新しいセルラ・セクタに移動する時に、ｎｒｔＥｘｉｔＦｒｏｍＳｅｃｔｏｒプロセスを実行するように構成される。この実施形態では、スケジューラ１７１は、ビデオ・セッション要求をＭＤ１１０にサービスする新しいセルラ・セクタのＮＲＴキューに挿入するために、ｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（ｎｅｗＳｅｃｔｏｒＩＤ）プロセスを実行する。

一実施形態では、スケジューラ１７１は、上で説明したイベントを処理する時に、複数の関連するプロセスを利用する。一実施形態では、スケジューラ１７１は、イベントが到着する時に、これらのイベントに作用するために次のプロセスのうちの１つまたは複数を実行するように構成される（そのようなイベントの使用は、本明細書上で、これらのイベントの説明の文脈内で参照される）。これらのプロセスは、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセス、ｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセス、およびｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを含み、その説明をこれに続ける。

（１）Ｉｎｃｒｅａｓｅ Ｓｅｃｔｏｒ Ｖｉｄｅｏｓ（セクタ・ビデオ増加）プロセス
一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３に割り振られたリソースのバジェットを超えずに（すなわち、ＰＲＢ＿ＡＬＬＯＣＡＴＥＤ値を超えずに）追加のビデオ・セッションにセルラ・セクタ１２３内で対処できなくなるまで、ｖｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスに１つまたは複数のビデオ・セッション要求をサブミットするために、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行するように構成される。スケジューラ１７１は、任意の適切な順序でｖｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスに（１つまたは複数の）ビデオ・セッション要求をサブミットすることができる（たとえば、セルラ・セクタ１２３内のＲＴセッションとして対処できる最高優先順位のビデオ・セッション要求を必ず選択する、セルラ・セクタ１２３内のＲＴセッションとして対処できるビデオ・セッション要求の中からランダムに選択するなど）。

一実施形態では、スケジューラ１７１は、（１）アクティブ・ビデオ・セッションごとにＴｘＣＢＲ_{ｂｉｔｒａｔｅ}≦ＴｘＭＡＸになり、（２）ＣＵＲＲＲＥＮＴ＿ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮ≦ＰＲＢ＿ＡＬＬＯＣＡＴＩＯＮになるように、セルラ・セクタ１２３のＮＲＴキューが空の時に、セルラ・セクタ１２３の既存のビデオ・セッションの送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）を増やすために、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行するように構成される。送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）を、任意の適切な形で増やすことができる（たとえば、等しい増分ですべてのアクティブ・ビデオ・セッションのすべての送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）を増やす、セルラ・セクタ１２３内のアクティブ・セッションの相対優先順位レベルに従って送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）のうちの１つまたは複数を増やすなど、およびそのさまざまな組合せ）。

（２）Ｉｎｓｅｒｔ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ（セッション要求挿入）プロセス
一実施形態では、スケジューラ１７１は、ビデオ・セッション要求の送達モードに基づいてｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセスを実行するように構成される。

ビデオ・セッション要求の送達モードがＮＲＴである場合に、スケジューラ１７１は、ビデオ・セッション要求をセルラ・セクタ１２３のＮＲＴキューに挿入する。ＮＲＴキュー内のビデオ・セッション要求の配置は、セルラ・セクタ１２３に関する要求の時刻に基づくものとすることができる（ビデオ・セッション要求のうちのいくつかについて、オリジナル要求が、異なるセルラ・セクタに関連した可能性がある場合）。

ビデオ・セッション要求の送達モードがＢＧである場合に、スケジューラ１７１は、ビデオ・セッション要求をセルラ・セクタ１２３のＢＧキューに挿入する。

（３）Ｒｅｄｕｃｅ Ｓｅｃｔｏｒ Ｖｉｄｅｏｓ（セクタ・ビデオ減少）
一実施形態では、スケジューラ１７１は、セルラ・セクタ１２３に割り振られたリソースのバジェットの変化に応答してｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行するように構成される。この場合に、スケジューラ１７１は、セルラ・セクタ１２３に割り振られたリソースのバジェットの減少の量に従って、アクティブ・ビデオ・セッションへのリソースの割振りをグレースフルに減らす。

一実施形態では、スケジューラ１７１は、ビデオ・セッション要求に応答してｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスを実行するように構成される。この場合に、スケジューラ１７１は、セルラ・セクタ１２３のすべてのアクティブ・ビデオ・セッションについてＴｘＣＢＲ_{ｂｉｔｒａｔｅ}≧ＴｘＭＩＮを保証しながら、新しいビデオ・セッションのためにリソースを解放するために１つまたは複数のアクティブ・ビデオ・セッションのうちの送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）を減らす。

一実施形態では、スケジューラ１７１は、リソース可用性が許す限り、ＢＧキュー内のビデオ・セッション要求を受け入れるように構成される。これは、オフピーク送達、サイド・ローディング（たとえば、無線ローカル・エリア・ネットワーク接続（たとえば、ＷｉＦｉまたは他の適切なタイプの無線アクセス技術を介するが使用可能である時））など、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。

主に、例示的プロセスの使用に関して図示され、本明細書で説明されるが、例示的プロセスによって提供されるものとして本明細書で説明される機能を、任意の適切な形で提供できる（たとえば、プロセスのうちの１つまたは複数を組み合わせることができ、例示的プロセスのうちの１つまたは複数を複数のプロセスに分割することができなど）ことに留意されたい。

主に、あるタイプの情報（たとえば、各ビデオ・セッション要求に関連する送達モードおよび要求されるデータ・レート）が、ビデオ・セッション要求のスケジューリングのためにスケジューラ１７１によって使用される実施形態に関して図示され、本明細書で説明されるが、本明細書で説明されるように、１つまたは複数の他のタイプの情報を、ビデオ・セッション要求のスケジューリングを決定するためにスケジューラ１７１によって使用することもできる（たとえば、セルラ・セクタ１２３の無線状況、無線アップリンクを介して送信されるビデオ・ストリームのタイプ、ユーザのＳＬＡ、ネットワーク・サービス・プロバイダの１つまたは複数のポリシなど、およびそのさまざまな組合せ）ことに留意されたい。

スケジューラ１７１は、セルラ・セクタ１２３のＭＤ１１０のアップリンク・ビデオ・セッション要求に対する応答を提供する。一般に、アップリンク・ビデオ・セッションに関するＭＤ１１０への応答は、確立されるアップリンク・ビデオ・セッションに関連する情報を含む。たとえば、この情報は、ビデオをアップリンク・ビデオ・セッションを介して送信できるようにアップリンク・ビデオ・セッションが確立される時に関する表示、ＭＤ１１０がアップリンク・ビデオ・セッションについて使用しなければならない送信ビット・レートの表示（これを、アップリンク・ビデオ・セッションについてＭＤ１１０に割り振られた無線アップリンクのＰＲＢに変換することができる）などを含むことができる。スケジューラ１７１は、アップリンク・ビデオ・セッション要求に対する応答をＭＤ１１０に提供することができ、かつ／またはアップリンク・ビデオ・セッション要求に対する応答をネットワークの１つまたは複数のＣＡＣ機能（たとえば、このＣＡＣ機能は、アップリンク・ビデオ・セッション要求に対する応答を受信し、これらをＭＤ１１０にルーティングし、かつ／またはアップリンク・ビデオ・セッション要求に対する応答を受信し、適当な対応するアップリンク・ビデオ・セッション応答をスケジューラ１７１の代わりにＭＤ１１０に送信するように動作することができる）に提供することができる。どの場合でも、アップリンク・ビデオ・セッション要求を送信するＭＤ１１０は、ＭＤ１１０がスケジューラ１７１によって決定されたアップリンク・ビデオ送信スケジュールに従ってセルラ・セクタ１２３の無線アップリンクを介してビデオ・コンテンツを提供できるように、それぞれ、これらのアップリンク・ビデオ・セッション要求に対するそれぞれのアップリンク・ビデオ・セッション応答を受信する。

図２に、図１のセルラ・セクタ内でアップリンク・ビデオ・セッションをスケジューリングする方法の一実施形態を示す。ステップ２１０で、方法２００が始まる。ステップ２２０で、セルラ・セクタのＭＤのアップリンク・ビデオ・セッション要求を受信する。ステップ２３０で、セルラ・セクタ内のアップリンク・ビデオ・セッションをスケジューリングする際に使用される情報を受信する。ステップ２４０で、セルラ・セクタ内のアップリンク・ビデオ・セッションのスケジューリングを、セルラ・セクタ内のアップリンク・ビデオ・セッションをスケジューリングする際に使用される受信された情報に基づいて決定する。ステップ２５０で、セルラ・セクタのＭＤのアップリンク・ビデオ・セッション応答を、ＭＤへの送達のために送信する。ステップ２６０で、方法２００は終了する。方法２００のステップを、図１の説明を参照することによってよりよく理解できることに留意されたい。

図３に、図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションのスケジューリングを決定する方法の一実施形態を示す。ステップ３１０で、方法３００が始まる。ステップ３２０で、セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするのに使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報を受信する。ステップ３３０で、セルラ・セクタ内での無線アップリンクを介するモバイル・デバイスからのビデオ・コンテンツの送信のためにアップリンク・ビデオ・セッションを確立するモバイル・デバイスによる要求に関連するビデオ・セッション要求情報を受信する。ステップ３４０で、セルラ・セクタ内の無線アップリンクを介するアップリンク・ビデオ・セッションのスケジューリングを、セルラ・セクタ内のアップリンク・ビデオ・セッションをサポートするのに使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報を使用して判定し、無線アップリンクを介するモバイル・デバイスからのビデオ・コンテンツの送信のためにアップリンク・ビデオ・セッションを確立するモバイル・デバイスによる要求に関連するビデオ・セッション要求情報を受信する。ステップ３５０で、方法３００は終了する。方法３００のステップを、図１の説明を参照することによってよりよく理解できることに留意されたい。

ここで図１に戻って、主にスケジューラ１７１が無線アップリンク・コントローラ１７０の一部として実施される実施形態に関して図示され、本明細書で説明されるが、スケジューラ１７１を、任意の他の適切な形で実施できることに留意されたい。一実施形態では、たとえば、スケジューラ１７１を、例示的な無線通信システム１００内の任意の適切な（１つまたは複数の）位置に配置できる複数の要素（たとえば、例示的な無線通信システム１００の１つもしくは複数の既存の要素および／または例示的な無線通信システム１００内に展開される１つもしくは複数の新しい要素）を使用して、分散された形で実施することができる。一実施形態では、たとえば、スケジューラ１７１を、例示的な無線通信システム１００内の任意の適切な位置の独立の要素として実施することができる（その例示的実施形態を、図４に関して図示し、説明する）。さらに、そのような実施形態のさまざまな組合せを使用できることに留意されたい。

図４に、図１のセルラ・セクタ内でアップリンク・ビデオ・セッションをスケジューリングするように構成されたスケジューラの一実施形態を示す。

図４に示されているように、スケジューラ４００は、プロセッサ４１０、メモリ４２０、入出力インターフェース４３０、およびサポート回路４４０を含む。

プロセッサ４１０は、メモリ４２０、入出力インターフェース４３０、サポート回路４４０のそれぞれに結合され、これらのそれぞれは、さまざまな他の形でお互いに結合され、かつ／またはお互いと通信することができる。プロセッサ４２１は、ビデオ・セッション・スケジューリング能力のさまざまな機能を制御するように構成される。

メモリ４２０は、プロセス４２１を格納し、ビデオ・セッション要求キュー４２５を維持するように構成される。

プロセス４２１は、ビデオ・セッション・スケジューリング能力の機能を提供するためにプロセッサ４１０によって実行され得る任意のプロセスを含むことができる。一実施形態では、たとえば、プロセス４２１は、１つまたは複数のビデオ・セッション・スケジューリング・プロセスを含むことができる（たとえば、ＶｉｄｅｏＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセス、ＶｉｄｅｏＳｅｓｓｉｏｎＥｎｄｅｄプロセス、ＶｉｄｅｏＳｅｓｓｉｏｎＣｈａｎｇｅｄプロセス、ＳｙｓｔｅｍＲｅｓｏｕｒｃｅＣｈａｎｇｅプロセス、ｎｒｔＴｉｍｅｏｕｔプロセス、ｎｒｔＥｘｉｔＦｒｏｍＳｅｃｔｏｒプロセス、ｉｎｃｒｅａｓｅＳｅｃｔｏｒＶｉｄｅｏｓプロセス、ｉｎｓｅｒｔＳｅｓｓｉｏｎＲｅｑｕｅｓｔプロセス、ｒｅｄｕｃｅＳｅｃｔｏｒＶｉｄｅｏｓプロセスなど）。

ビデオ・セッション要求キュー４２５は、セルラ・セクタのＭＤ（たとえば、セルラ・セクタ１２３のＭＤ１１０）のビデオ・セッション要求を格納するように構成される。一実施形態では、ビデオ・セッション要求キュー４２５は、それぞれスケジューラ４００が関連する無線ネットワークの複数のセルラ・セクタに関連するビデオ・セッション要求キュー４２６_１〜４２６_Ｎの複数のセットを含む。たとえば、第１セルラ・セクタに関連するビデオ・セッション要求キュー４２６_１のセットは、ＮＲＴ送達モード要求として処理される第１セルラ・セクタのビデオ・セッション要求をキューイングするＮＲＴキューと、ＢＧ送達モード要求として処理される第１セルラ・セクタのビデオ・セッション要求をキューイングするＢＧキューとを含み、第２セルラ・セクタに関連するビデオ・セッション要求キュー４２６_２のセットは、ＮＲＴ送達モード要求として処理される第２セルラ・セクタのビデオ・セッション要求をキューイングするＮＲＴキューと、ＢＧ送達モード要求として処理される第２セルラ・セクタのビデオ・セッション要求をキューイングするＢＧキューとを含み、以下同様である。主に別々のキューがセルラ・セクタのＮＲＴビデオ・セッション要求およびＢＧビデオ・セッション要求を維持するのに使用される実施形態に関して図示され、説明されるが、セルラ・セクタのＮＲＴビデオ・セッション要求およびＢＧビデオ・セッション要求を、単一のキューを使用して維持することができることを了解されたい。主に別々のキューがそれぞれセルラ・セクタのビデオ・セッション要求を維持するのに使用される実施形態に関して図示され、説明されるが、セルラ・セクタのビデオ・セッション要求を、任意の適切な個数のキューを使用して維持することができることを了解されたい。

プロセス４２１を格納し、ビデオ・セッション要求キュー４２５を維持するための単一のメモリ４２０の使用に関して図示され、説明されるが、任意の適切な個数のストレージ・モジュールを、プロセス４２１の格納およびビデオ・セッション要求キュー４２５の維持に使用することができることに留意されたい。

入出力インターフェース４３０は、スケジューラ４００がそれを介して外部デバイスと通信できるインターフェースを提供する。

サポート回路４４０は、プロセッサ４１０およびメモリ４２０によって提供される機能を容易にすることができるさまざまな回路（たとえば、電源など）を含む。

もう一度図１に戻って、主に図４では独立の要素として図示され、説明されるが、スケジューラ４００を、１つまたは複数のネットワーク要素（たとえば、無線アップリンク・コントローラ１７０）の一部として実施することができることに留意されたい。一実施形態では、スケジューラ４００は、図１の無線アップリンク・コントローラ１７０のスケジューラ１７１として使用される。スケジューラ４００が、１つまたは複数のネットワーク要素の一部として実施される場合に、スケジューラ４００の要素の少なくとも一部を、さまざまな他のモジュールおよび／または能力を提供し、かつ／またはサポートするのに利用することができることに留意されたい（たとえば、プロセッサ４１０は、スケジューラ１７１およびマネージャ１７２の機能を実行することができ、メモリ４２０は、スケジューラ１７１およびマネージャ１７２のプロセスおよび／またはデータを格納することができなど）。さらに、主にマネージャ１７２に関連して実施されるものとして図示され、本明細書で説明されるが、スケジューラ１７１は、マネージャ１７２の一部を形成することができ、マネージャ１７２からリモート実施され得（かつ、いくつかの場合に、任意の適切な形でマネージャ１７２と通信することができる）などに留意されたい。

スケジューラ１７１を、無線アップリンク制御能力のさまざまな他の機能を提供するように構成することができる。

上で説明したように、無線アップリンク・コントローラ１７０は、無線アップリンク制御能力のさまざまな機能を提供するように構成される。一実施形態では、ビデオ・セッション管理能力は、セルラ・セクタの無線アップリンクを介して確立されたまたはこれから確立されるビデオ・セッションを管理するために提供される。ビデオ・セッション管理能力は、ビデオ・アプリケーションが無線アップリンク上の帯域幅を動的に管理することを可能にすることによって、セルラ・セクタの無線アップリンクを介してビデオを送信するビデオ・アプリケーションの信頼性を改善する。一実施形態では、ビデオ・セッション管理能力のさまざまな機能は、図１に関して図示され、説明されるマネージャ１７２によって提供される。

マネージャ１７２は、セルラ・セクタ１２３のＭＤ１１０の潜在的なおよび／または確立されたアップリンク・ビデオ・セッションを監視し、管理するように構成される。

マネージャ１７２は、セルラ・セクタ１２３のＭＤ１１０の潜在的なおよび／または確立されたアップリンク・ビデオ・セッションを監視し、管理する際に使用される情報を受信するように構成される。たとえば、スケジューラ１７１は、管理システム（たとえば、管理システム１６０および／またはそのような情報の任意の他の適切なソース）からアップリンク・リソース情報を受信することができる。たとえば、スケジューラ１７１は、ＭＤ１１０からアップリンク・ビデオ・セッション要求を受信することができる。たとえば、マネージャ１７２は、マネージャ１７２がＭＤ１１０ごとにＭＤ１１０が接続されるセルラ・セクタ（実例として、セルラ・セクタ１２３）を決定できるように、ＲＡＮ１２０および／またはＷＰＮ１３０からモバイル・デバイス・ロケーション情報を受信する。たとえば、マネージャ１７２は、ＲＡＮ１２０および／またはＷＰＮ１３０から、リソース輻輳の存在および同様にリソース輻輳の緩和を示すトリガを受信する。一実施形態では、そのようなトリガを、ＲＡＮ１２０および／またはＷＰＮ１３０から明示的構成通知（ＥＣＮ）の形で提供することができる。たとえば、マネージャ１７２は、確立されたビデオ・セッションのＲＴＰストリームに関連するＲＴＣＰメッセージを受信し、処理することによって、確立されたビデオ・セッションを監視する。マネージャ１７２は、セルラ・セクタ１２３のＭＤ１１０の潜在的なおよび／または確立されたアップリンク・ビデオ・セッションを監視し、管理する際に使用されるさまざまな他のタイプの情報を受信することができる。マネージャ１７２は、セルラ・セクタ１２３のＭＤ１１０の潜在的なおよび／または確立されたアップリンク・ビデオ・セッションを監視し、管理するのに、そのような情報を使用するように構成される。

マネージャ１７２は、ＲＴＰ／ＲＴＣＰプロトコルおよびそれに関連する拡張を適用してＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ａｕｄｉｏ／Ｖｉｄｅｏ Ｔｒａｎｓｐｏｒｔ（ＡＶＴ）ＲＦＣ（たとえば、ＲＦＣ ３５５０と、ＲＦＣ ４５８５、ＲＦＣ ５１０４、ＲＦＣ ５５０６などの関連するＲＦＣのうちの１つまたは複数となど、およびそのさまざまな組合せ）を使用することによって、監視能力および管理能力を提供するように構成される。一実施形態では、たとえば、マネージャ１７２は、ＲＦＣ ３５５０によって定義されるＭｕｌｔｉｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ（ＭＣＵ）として（またはその一部として）、これを使用して、かつ／またはこれに従って実施される。

一般に、ＲＦＣ ３５５０は、ＲＴＰおよびＲＴＣＰを定義する。ＲＴＰは、例示的な通信システム１００内でビデオ・データをトランスポートするのに使用されるプロトコルである。ＲＴＰは、ＲＴＰストリーム内のジッタおよび順序はずれパケットの到着を処理する機構を含む。ＲＴＣＰは、例示的な通信システム１００内でＲＴＰストリームを介するビデオ・データのトランスポートを制御するのに使用されるプロトコルである。ＲＴＣＰは、ＲＴＰストリームを介するビデオ・データの送達を監視し、ＲＴＰストリームに関連する品詞統計を収集／報告する機構を含む（たとえば、失われたＲＴＰパケットの総数、ジッタ、送信されたＲＴＰペイロードの総数などのパラメータを指定できるＲＴＣＰセンダ・レポート（ＳＲ）およびＲＴＣＰレシーバ・レポート（ＲＲ）を介して）。

一般に、ＲＦＣ ４５８５（Ｅｘｔｅｎｄｅｄ ＲＴＰ Ｐｒｏｆｉｌｅ ｆｏｒ Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＲＴＣＰ）−Ｂａｓｅｄ Ｆｅｅｄｂａｃｋ（ＲＴＰ／ＡＶＰＦ））は、受信側が送信側に統計的により直接のフィードバックを提供することを可能にし、短期適合および効率的なフィードバックベースの修復機構を実施することを可能にする、Ａｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ（ＡＶＰ）に対する拡張を定義する。ＲＦＣ ４５８５は、ｐｉｃｔｕｒｅ ｌｏｓｓ ｉｎｄｉｃａｔｉｏｎ（ＰＬＩ）、ｓｌｉｃｅ ｌｏｓｓ ｉｎｄｉｃａｔｉｏｎ（ＳＬＩ）、ｒｅｆｅｒｅｎｃｅ ｐｉｃｔｕｒｅ ｓｅｌｅｃｔｉｏｎ ｉｎｄｉｃａｔｉｏｎ（ＲＰＳＩ）（ＡＣＫ／ＮＡＣＫ）などの追加パラメータの使用を介してＡＶＰを拡張する。

一般に、ＲＦＣ ５１０４（Ｃｏｄｅｃ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅｓ ｉｎ ｔｈｅ ＲＴＰ／ＡＶＰＦ）は、ＲＴＰ／ＡＶＰＦで定義されるメッセージに対する拡張を指定する。ＲＦＣ ５１０４は、ＲＴＣＰ ＲＲメッセージを補足する。ＲＦＣ ５１０４は、Ｔｅｍｐｏｒａｒｙ Ｍａｘｉｍｕｍ Ｍｅｄｉａ Ｓｔｒｅａｍ Ｂｉｔ Ｒａｔｅ Ｒｅｑｕｅｓｔ（ＴＭＭＢＲ）メッセージおよびＴｅｍｐｏｒａｒｙ Ｍａｘｉｍｕｍ Ｍｅｄｉａ Ｓｔｒｅａｍ Ｂｉｔ Ｒａｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ（ＴＭＭＢＮ）メッセージを含む複数のメッセージを定義する。一般に、ビデオ受信側は、それが受信しつつあるビデオ・ストリームの送信ビット・レートの減少または増加を要求するためにＲＴＣＰ／ＡＶＰＦメッセージ内にＴＭＭＢＲ値を含めるように構成され、ビデオ送信側は、それがビデオ・ストリームの将来の送信に使用するつもりの送信ビット・レートの通知としてＲＴＣＰ／ＡＶＰＦメッセージ内にＴＭＭＢＮ値を含めるように構成される。ＲＦＣ ５１０４は、時間対空間のトレードオフに関する提案を可能にするように構成されたｔｅｍｐｏｒａｌ ｓｐａｔｉａｌ ｔｒａｄｅ−ｏｆｆ ｒｅｑｕｅｓｔ（ＴＳＴＲ）パラメータ、復号器リフレッシュの要求を可能にするように構成されたｆｕｌｌ ｉｎｔｒａ ｒｅｑｕｅｓｔ（ＦＩＲ）パラメータなど、追加のパラメータをサポートする。

一般に、ＲＦＣ ５５０６（Ｒｅｄｕｃｅｄ−Ｓｉｚｅ ＲＴＣＰ）は、ＡＶＰＦ情報がＲＴＣＰメッセージ内に含まれ、ＳＲ／ＲＲがＲＴＣＰメッセージから省略される、減らされたサイズのＲＴＣＰメッセージを指定する。

マネージャ１７２は、セルラ・セクタ１２３のＭＤ１１０のビデオ・セッションのそれぞれを知っている。一般に、ビデオ・セッションごとに、いくつかの基本的なセットアップが、ビデオ・セッションを確立するために実行される。ビデオ送信側は、ビデオ・セッションを開始する時に通常発生するように、リソースをグラントされる（スケジューラ１７１によって提供されてもされなくてもよい）。たとえば、ビデオ送信側には、ビデオ送信側の要件に基づいて、ビデオ・セッションのＧｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ（ＧＢＲ）およびＭａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ（ＭＢＲ）をグラントすることができ、ここで、ＭＢＲ＞ＧＢＲである。マネージャ１７２は、ビデオ・セッションに関連する情報、たとえば、ビデオ送信側および（１つまたは複数の）ビデオ受信側の識別、ビデオ送信側のサービング基地局に関するビデオ送信側のロケーション（ビデオ送信側のセルラ・セクタをも識別する）、ビデオ・セッションのために割り振られたパラメータ（たとえば、ＧＢＲ、ＭＢＲなど）など、およびそのさまざまな組合せを受信する。マネージャ１７２は、任意の適切な形でビデオ・セッションに関連する情報を受信することができる。一実施形態では、たとえば、マネージャ１７２は、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）ベースのＡＩＰウェブ・サービスを使用して、ビデオ送信側および（１つまたは複数の）ビデオ受信側の識別を含めて、ビデオ・セッションを知ることができる。

マネージャ１７２は、セルラ・セクタ１２３のアップリンク・ビデオ・セッションごとに（および、オプションで、明瞭さのために省略されている、マネージャ１７２がそれに関する管理機能を提供する他のセルラ・セクタについて）、アップリンク・ビデオ・セッション中に生成されるＲＴＣＰメッセージを受信する。アップリンク・ビデオ・セッションのＲＴＣＰメッセージは、（１）アップリンク・ビデオ・セッションのＲｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ（ＲＲ）および／またはＳｅｎｄｅｒ Ｒｅｐｏｒｔ（ＳＲ）を含むＲＴＣＰメッセージ、（２）アップリンク・ビデオ・セッションのＲＲ／ＳＲおよび関連するＡＶＰＦ情報を含むＲＴＣＰメッセージ、ならびに／あるいは（３）アップリンク・ビデオ・セッションのＡＶＰＦ情報を含む（かつ、ＲＲ／ＳＲを除外した）ＲＴＣＰメッセージのうちの１つまたは複数を含むことができる。アップリンク・ビデオ・セッションのＲＴＣＰメッセージは、任意の他の適切なタイプのＲＴＣＰメッセージを含むことができる。そのようなＲＴＣＰメッセージは、通常、ビデオ・セッションのビデオ送信側とビデオ受信側との間で交換されるが、マネージャ１７２は、それぞれセルラ・セクタ（実例として、セルラ・セクタ１２３）の潜在的なおよび確立されたアップリンク・ビデオ・セッションを監視し、管理するために、セルラ・セクタを基礎としてそのようなメッセージを受信し、そのようなメッセージを使用するように構成される。

マネージャ１７２は、セルラ・セクタごとにマネージャ１７２がセルラ・セクタ内でアクティブなすべてのビデオ送信側ならびにアクティブ・ビデオ送信側のアップリンク・ビデオ・セッションの詳細をそれぞれ知るように、セルラ・セクタごとの基礎で情報を照合する。マネージャ１７２は、セルラ・セクタごとにマネージャ１７２がセルラ・セクタ内のすべてのアップリンク・ビデオ・セッションの割り振られたＧＢＲの総量および割り振られたＭＢＲの総量を判定するように、セルラ・セクタごとの基礎でそのような情報を処理することができる。

マネージャ１７２を、ＲＴＣＰ ＳＲメッセージおよびＲＲメッセージの受信および処理、ビデオ受信側から発するＴＭＭＢＲメッセージの受信および関連するビデオ・セッションのビデオ送信側への受信されたＴＭＭＢＲメッセージの提供などを含めて、通常の輻輳していない動作中にＲＦＣ ５７６０に従って機能するように構成することができる。その結果、マネージャ１７２は、各ビデオ・セッションの送信ビット・レート（ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}と表される）をも判定することができ（ここで、ＴｘＣＢＲ_{ｂｉｔｒａｔｅ}はＭＢＲ以下であり、悪い信号をもたらす条件の下など、ある種の状況ではＧＢＲ以下である可能性がある）、したがって、セルラ・セクタ内のすべてのビデオ送信側の総送信ビット・レート（セルラ・セクタ内のすべてのビデオ送信側にわたるΣＴｘＣＢＲ_{ｂｉｔｒａｔｅ}）をも判定することができる。

マネージャ１７２は、セルラ・セクタ１２３（ならびに、明瞭さのために省略されている、マネージャ１７２がそれに関して管理機能を提供する他のセルラ・セクタ）の確立されたアップリンク・ビデオ・セッションを監視し、管理するように構成される。マネージャ１７２は、セルラ・セクタ１２３内のアップリンク・ビデオ・セッションのビデオ送信側の一部またはすべての送信ビット・レートを変更するように構成される。マネージャ１７２は、アップリンク・ビデオ・セッションのためにセルラ・セクタ１２３内で使用可能なアップリンク・リソースのバジェット、セルラ・セクタ１２３内のビデオ送信側の現在のビット・レート、およびセルラ・セクタ１２３のビデオ送信側（１つまたは複数）の新しい（１つまたは複数の）ビット・レートをトリガする（１つまたは複数の）条件に基づいて、セルラ・セクタ１２３内の（１つまたは複数の）ビデオ送信側の新しい（１つまたは複数の）ビット・レートを決定するように構成される。マネージャ１７２は、（１つまたは複数の）ビデオ送信側に（１つまたは複数の）送信ビット・レート変更メッセージを送信するように構成され、ここで、ビデオ送信側に関する送信ビット・レート変更メッセージは、マネージャ１７２によって決定された新しいビット・レートを使用してビデオを送信するようにビデオ送信側に指示するように構成される。マネージャ１７２は、さまざまなイベントおよび／または条件に応答して、セルラ・セクタ１２３内のアップリンク・ビデオ・セッションのビデオ送信側の一部またはすべての送信ビット・レートを変更することができる。マネージャ１７２は、ビデオ送信側のビット・レートを減らし、かつ／または増やすことによって、ビデオ送信側の一部またはすべての送信ビット・レートを変更することができる。送信ビット・レート変更メッセージは、任意の適切な（１つまたは複数の）タイプのメッセージとすることができる。一実施形態では、送信ビット・レート変更メッセージは、ＴＭＭＢＲメッセージとして送信される。

マネージャ１７２は、ビデオ送信側に、そのそれぞれのビット・レートを減らすように指示し、これによってセルラ・セクタ１２３内のリソースを解放するために、セルラ・セクタ１２３内のビデオ送信側の一部またはすべてにそれぞれの送信ビット・レート変更メッセージを送信することができる。これを、任意の適切なイベントまたは条件に応答して実行することができる。一実施形態では、たとえば、これを、保留中のおよび／または新しいビデオ・セッション要求（たとえば、ＲＴビデオ・セッション要求、保留中のＮＲＴビデオ・セッション要求など）に対処するために行うことができる。一実施形態では、たとえば、これを、セルラ・セクタ１２３内に輻輳があることの表示に応答して行うことができる。これを、任意の他の適切なイベントまたは条件に応答して実行することができる。

マネージャ１７２は、ビデオ送信側のそれぞれにそのそれぞれのビット・レートを増やすように指示するために、セルラ・セクタ１２３内のビデオ送信側の一部またはすべてにそれぞれの送信ビット・レート変更メッセージを送信することができる。一実施形態では、たとえば、追加の無線アップリンク・リソースがアクティブ・ビデオ送信側による使用のために使用可能である場合に、これを行うことができる。

マネージャ１７２は、セルラ・セクタ１２３内のビデオ送信側の一部またはすべてにそれぞれの送信ビット・レート変更メッセージを送信することができる。これに関して、それぞれの送信ビット・レート変更メッセージを、さまざまな条件の下で（たとえば、新しいアップリンク・ビデオ・セッションに対処するためにすべてのビデオ送信側のビット・レートをスロットリングするため、セルラ・セクタ内の輻輳中にすべてのビデオ送信側のビット・レートをスロットリングするためなど）セルラ・セクタ１２３のビデオ送信側のすべてに送信することができることに留意されたい。同様に、これに関して、それぞれの送信ビット・レート変更メッセージを、さまざまな条件の下で（たとえば、１つまたは複数のビデオ送信側が他のアクティブなまたは保留中のビデオ・ソースに損害を与えて無線アップリンク・リソースを消費しつつある場合、１つまたは複数のビデオ送信側が追加の無線アップリンク・リソースの使用の資格を与えられ、そのような追加のリソースが現在セルラ・セクタ１２３内で使用可能である場合など）セルラ・セクタ１２３のビデオ送信側のサブセットだけに送信することができることに留意されたい。

マネージャ１７２は、たとえば、セルラ・セクタ１２３の１つまたは複数のビデオ送信側の（１つまたは複数の）送信ビット・レートを減らし、セルラ・セクタ１２３の１つまたは複数のビデオ送信側の（１つまたは複数の）送信ビット・レートを増やすために、送信ビット・レート変更メッセージの組合せを使用することができる。

少なくともいくつかのそのような実施形態で、送信ビット・レート変更メッセージは、均しい量または等しくない量のビデオ送信側のビット・レートの変更を指定することができる（たとえば、ビデオ送信側の無線送信効率、ビデオ送信側によって使用されるＭＣＳ、ビデオ送信側のＳＬＡ、ビデオ送信側のアプリケーション・タイプおよび／またはアプリケーションなど、ならびにそのさまざまな組合せに基づいて）。

少なくともいくつかのそのような実施形態で、任意の適切な個数の送信ビット・レート変更メッセージを、任意の適切な個数のビデオ送信側に送信することができ、ここで、そのような送信ビット・レート変更メッセージは、ビデオ送信側のビット・レートのそれぞれの減少および／または増加を要求することができる。この形で、マネージャ１７２は、要員および条件のさまざまな組合せに基づいて（たとえば、セルラ・セクタ１２３内での新しいビデオ・セッションの要求、セルラ・セクタ１２３内での既存のビデオ・セッションの終了、輻輳の表示、ビデオ送信側の無線送信効率、ビデオ送信側によって使用されるＭＣＳ、ビデオ送信側のＳＬＡ、ビデオ送信側のアプリケーション・タイプおよび／またはアプリケーションなど、ならびにそのさまざまな組合せのうちの１つまたは複数に基づいて）セルラ・セクタ１２３の使用可能な無線アップリンク・リソースを管理するように構成される。

一例として、（１）あるセルラ・セクタ内に５つのビデオ送信側があり、各ビデオ送信側が、２５６ＫｂｐｓのＧＢＲを有し、そのセルラ・セクタについて合計１．２５Ｍｂｐｓが現在割り振られており、（２）このセルラ・セクタのアップリンク・ビデオ・セッションについて割り振ることのできる最大帯域幅が、１．２５Ｍｂｐｓであると仮定する。単純化のために、すべてのビデオ送信側が、同一のＭＣＳ値を有すると仮定する（ただし、無線アップリンク・リソースの割振りが、ＭＣＳ値の関数とすることができるＰＲＢに関することに留意されたい）。この例では、１２８Ｋｂｐｓの第６のビデオ・セッションの要求が受信される時に、マネージャ１７２は、新しいビデオ・セッションに対処するように促される。新しいセッションに対処するために、マネージャ１７２は、５つの既存のビデオ送信側のそれぞれに５つのＴＭＭＢＲメッセージを発行し、各ＴＭＭＢＲメッセージは、２２４Ｋｂｐｓのビット・レート値を示す（すなわち、それぞれ３２Ｋｂｐｓの減少）。この形で、１６０Ｋｂｐｓの無線アップリンク容量が、セルラ・セクタの無線アップリンクを介して１２８Ｋｂｓｐ（またはこれを超える）でビデオを送信するための新しいビデオ・セッションによる使用のために使用可能にされる。この例では、アクティブ・ビデオ送信側のそれぞれの送信ビット・レートが、均一に劣化することに留意されたい。

もう１つの例として、（１）あるセルラ・セクタ内に５つのビデオ送信側があり、各ビデオ送信側が、２５６ＫｂｐｓのＧＢＲを有し、そのセルラ・セクタについて合計１．２５Ｍｂｐｓが現在割り振られており、５つのビデオ送信側のうちの２つが、それらに２５６ＫｂｐｓのＧＢＲを保証する関連するＳＬＡを有し、（３）このセルラ・セクタのアップリンク・ビデオ・セッションについて割り振ることのできる最大帯域幅が、１．２５Ｍｂｐｓであると仮定する。単純化のために、すべてのビデオ送信側が、同一のＭＣＳ値を有すると仮定する（ただし、無線アップリンク・リソースの割振りが、ＭＣＳ値の関数とすることができるＰＲＢに関することに留意されたい）。この例では、１２８Ｋｂｐｓの第６のビデオ・セッションの要求が受信される時に、マネージャ１７２は、新しいビデオ・セッションに対処するように促される。新しいセッションに対処するために、マネージャ１７２は、２５６ＫｂｐｓのＧＢＲを保証するＳＬＡを有しない３つの既存のビデオ送信側のそれぞれに３つのＴＭＭＢＲメッセージを発行し、各ＴＭＭＢＲメッセージは、１９２Ｋｂｐｓのビット・レート値を示す（すなわち、それぞれ６４Ｋｂｐｓの減少）。この形で、１９２Ｋｂｐｓの無線アップリンク容量が、セルラ・セクタの無線アップリンクを介して１２８Ｋｂｓｐ（またはこれを超える）でビデオを送信するための新しいビデオ・セッションによる使用のために使用可能にされる。この例では、ビデオ送信側のサブセットの送信ビット・レート減少が、ビデオ送信側のうちの２つのＳＬＡによって影響される（すなわち、より高いレベルの加入者は、より低いレベルの加入者に損害を与えて、影響を受けない）ことに留意されたい。

もう１つの例として、（１）あるセルラ・セクタ内に５つのビデオ送信側があり、各ビデオ送信側が、２５６ＫｂｐｓのＧＢＲを有し、そのセルラ・セクタについて合計１．２５Ｍｂｐｓが現在割り振られており、（２）このセルラ・セクタのアップリンク・ビデオ・セッションについて割り振ることのできる最大帯域幅が、１．２５Ｍｂｐｓであると仮定する。単純化のために、すべてのビデオ送信側が、同一のＭＣＳ値を有すると仮定する（ただし、無線アップリンク・リソースの割振りが、ＭＣＳ値の関数とすることができるＰＲＢに関することに留意されたい）。この例では、ビデオ送信側のうちの１つが、悪い無線条件を有し、ビデオ送信側が２６５Ｋｂｐｓビット・レートを利用できなくなっていると判定される時に、マネージャ１７２は、悪い無線条件を有するビデオ送信側の送信ビット・レートを下げ、過剰な無線アップリンク・リソースを他のビデオ送信側のうちの１つまたは複数（たとえば、より高いビット・レートをサポートできることを示す無線条件を有する、他のビデオ送信側のうちの１つまたは複数）に再割り振りする。マネージャ１７２は、悪い無線条件を有するビデオ送信側から解放されたリソースを、よりよい無線条件を有する残りのビデオ送信側に割り振る。そのような無線アップリンク・リソースの再割振りを実行するために、マネージャ１７２は、（１）悪い無線条件を有するビデオ送信側にＴＭＭＢＲメッセージを発行し、このＴＭＭＢＲメッセージは、２５６Ｋｂｐｓ未満のビット・レートを示し、（２）１つまたは複数の他のビデオ送信側に１つまたは複数のＴＭＭＢＲメッセージを発行し、この各ＴＭＭＢＲメッセージは、２５６Ｋｂｐｓを超えるビット・レート値を示す。

もう１つの例として、（１）あるセルラ・セクタ内に５つのビデオ送信側があり、各ビデオ送信側が、２５６ＫｂｐｓのＧＢＲを有し、そのセルラ・セクタについて合計１．２５Ｍｂｐｓが現在割り振られており、（２）このセルラ・セクタのアップリンク・ビデオ・セッションについて割り振ることのできる最大帯域幅が、１．２５Ｍｂｐｓであると仮定する。単純化のために、すべてのビデオ送信側が、同一のＭＣＳ値を有すると仮定する（ただし、無線アップリンク・リソースの割振りが、ＭＣＳ値の関数とすることができるＰＲＢに関することに留意されたい）。この例では、５つのビデオ送信側のうちの１つからビデオを受信しつつあるビデオ受信側が、１２８Ｋｂｐｓのより低い送信ビット・レートを要求するＴＭＭＢＲメッセージを送信する。マネージャ１７２は、ビデオ送信側からＴＭＭＢＲメッセージを受信し、そのＴＭＭＢＲメッセージを関連するビデオ送信側に転送し、この関連するビデオ送信側は、その送信レートを２５６Ｋｂｐｓから１２８Ｋｂｐｓに下げ、これによって、マネージャ１７２によって再割り振りできる使用可能な帯域幅をもたらす。マネージャ１７２は、ビデオ送信側から解放されたリソースを他のビデオ送信側のうちの１つまたは複数に割り振る。無線アップリンク・リソースのそのような再割振りを実行するために、マネージャ１７２は、１つまたは複数のＴＭＭＢＲメッセージを１つまたは複数の他のビデオ送信側に発行し、各ＴＭＭＢＲメッセージは、２５６Ｋｂｐｓより大きいビット・レート値を示す。前述の例が、無線アップリンク制御能力のさまざまな実施形態に従ってビデオ送信側の送信ビット・レートを管理できる（たとえば、増やし、かつ／または減らす）多数の形のうちの少数にすぎないことに留意されたい。

図５に、図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションの送信ビット・レートを変更する方法の一実施形態を示す。

ステップ５１０で、方法５００が始まる。

ステップ５２０で、セルラ・セクタに関連する少なくとも１つの条件の少なくとも１つの表示を受信する。条件は、セルラ・セクタ内の輻輳条件、少なくともセルラ・セクタにサービスするネットワーク要素に関連する輻輳条件、新しいビデオ・セッションがセルラ・セクタ内で確立されることの要求、セルラ・セクタ内の既存のビデオ・セッションの終了など、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。

ステップ５３０で、セルラ・セクタのビデオ送信側のアップリンク・ビデオ・セッションの修正済み送信ビット・レートを決定する。一実施形態では、修正済み送信ビット・レートは、少なくとも１つの条件に関連する情報、セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す情報、およびビデオ送信側によってサポートされる現在のビット・レートを示す情報（たとえば、ＲＴＣＰ ＳＲ／ＲＲおよび／またはそのような情報の任意の他の適切な（１つまたは複数の）ソースから判定される）を使用して決定される。

ステップ５４０で、アップリンク・ビデオ・セッションの修正済み送信ビット・レートを使用するようにビデオ送信側に指示するメッセージを、ビデオ送信側に向かって伝搬させる。一実施形態では、メッセージは、修正済み送信ビット・レートの値または使用すべき修正済み送信ビット・レートを判定するためにビデオ送信側によって使用され得る値（たとえば、修正済み送信ビット・レートに達するために現在のビット・レートを変更する必要がある量を示す値）を含むＴＭＭＢＲメッセージである。

ステップ５５０で、方法５００は終了する。

図６に、図１のセルラ・セクタ内でＭＤのアップリンク・ビデオ・セッションの送信ビット・レートを変更する方法の一実施形態を示す。

ステップ６１０で、方法６００が始まる。

ステップ６２０で、セルラ・セクタ内のアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示すアップリンク・リソース情報を受信する。

ステップ６３０で、セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信する。アップリンク・ビデオ・セッション情報を、ＲＴＣＰ ＳＲ、ＲＴＣＰ ＲＲ、ＡＶＰＦメッセージなどのうちの１つまたは複数の形で受信することができる。

ステップ６４０で、セルラ・セクタに関連する条件に応答して、無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定する。条件は、セルラ・セクタ内の輻輳の増加、セルラ・セクタ内の輻輳の減少、新しいビデオ・セッションがセルラ・セクタ内で確立されることの要求、セルラ・セクタ内の既存のビデオ・セッションの終了など、およびそのさまざまな組合せのうちの１つまたは複数を含むことができる。

ステップ６５０で、方法６００は終了する。

図７に、図１のセルラ・セクタ内でそれぞれの複数のＭＤの複数のアップリンク・ビデオ・セッションのビット・レートを制御する方法の一実施形態を示す。

ステップ７１０で、方法７００が始まる。

ステップ７２０で、ビデオ送信側のアップリンク・ビデオ・セッションに関連する状況メッセージを受信する。状況メッセージは、ＲＴＣＰ ＳＲ、ＲＴＣＰ ＲＲ、ＡＶＰＦメッセージなどのうちの１つまたは複数を含むことができる。

ステップ７３０で、状況メッセージを使用して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の現在の送信ビット・レートを判定する。

ステップ７４０で、セルラ・セクタに関連する条件に応答して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の修正済み送信ビット・レートを決定し、それぞれのアップリンク・ビデオ・セッションの修正済み送信ビット・レートの表示を、それぞれの複数の送信ビット・レート変更メッセージを使用して、それぞれのビデオ送信側に向かって伝搬させる。送信ビット・レート変更メッセージは、ＴＭＭＢＲメッセージを含むことができる。

ステップ７５０で、方法７００は終了する。

ここで図１を参照して、マネージャ１７２を、セルラ・セクタのビデオ送信側のビット・レートの変更に関連してさまざまな他のタイプの機能を提供するように構成することができることに留意されたい。

一実施形態では、マネージャ１７２は、セルラ・セクタから発しつつあるビデオ・セッションに参加するすべてのデバイスのビット・レート要件を監視するように構成される。たとえば、マネージャ１７２は、セルラ・セクタ内のすべてのビデオ送信側の送信ビット・レート要件を監視し、セルラ・セクタから発するビデオ・セッションに参加するすべてのビデオ受信側の送信ビット・レート要件を監視することができる。一実施形態では、マネージャ１７２は、送信ビット・レート変更メッセージを介してビット・レートの変更を要求するのにそのような情報を使用する。一実施形態では、マネージャ１７２は、さまざまなスケジューリング機能（マネージャ１７２が、セルラ・セクタ内のビデオ送信側の送信ビット・レートを変更する送信ビット・レート変更メッセージを発行することのスケジューラ１７１による要求をもたらすこともできる）を実行する際のスケジューラ１７１による使用のためにスケジューラ１７１にそのような情報を提供する。

マネージャ１７２が、セルラ・セクタ１２３のビデオ送信側のビット・レートの監視および管理を実行しつつある一実施形態では、マネージャ１７２を、コール・アドミッション・コントロール機能を実行する際のＢＳ１２２のコール・アドミッション・コントロール（ＣＡＣ）機構による使用のためにセルラ・セクタ１２３の関連するＢＳ１２２に情報を提供するように構成することができる。一実施形態では、たとえば、マネージャ１７２によって判定されたセルラ・セクタ１２３の総送信ビット・レートを、ＢＳ１２２のＣＡＣ機構によって使用して、セルラ・セクタ１２３の総送信ビット・レートがセルラ・セクタ１２３の総リソース未満である時に追加のリソースをアドミットすることができる。セルラ・セクタ１２３の総送信ビット・レートが、ビデオ送信側の個々のＴｘＣＢＲ_{ｂｉｔｒａｔｅ}値が変化する時に経時的に変化を受けるが（すなわち、ＢＳ１２２のＣＡＣ機構が総送信ビット・レート値に常に安全に頼ることができない可能性がある）、マネージャ１７２との協力によって、ＢＳ１２２のＣＡＣ機構は、ＭＢＳとしてビデオ送信側のＴｘＣＢＲ_{ｂｉｔｒａｔｅ}を実施するようにマネージャ１７２に知らせる（すなわち、どのビデオ送信側についてもＴｘＣＢＲ_{ｂｉｔｒａｔｅ}が増加することを許容しない）機構を使用することによって、コール・アドミッションを実行するためにセルラ・セクタ１２３の総リソース（ＰＲＢなど）に変換される総送信ビット・レートに頼ることができる。この機構を、さまざまなイベントおよび条件に応答して使用することができる（たとえば、システムが突然の輻輳を処理する間の一時的状態としてまたは任意の他の適切な目的のために）。さらに、ビデオ送信側が、その新しいビット・レートがもはや一時的ではないと判定する場合に、ビデオ受信側と新しいビット・レートを再ネゴシエートする（たとえば、ＳＩＰメッセージングまたは任意の他の適切なタイプのメッセージングを介して）ことが期待され、これによって、コール・アドミッション計算にＢＳ１２２のＣＡＣ機構によって使用できるビデオ・セッションの新しいＧＢＲ値およびＭＢＲ値がもたらされる。

主に、セルラ・セクタ１２３のビデオ送信側がＳｏｕｒｃｅ−Ｓｐｅｃｉｆｉｃ Ｍｕｌｔｉｃａｓｔ（ＳＳＭ）を使用する（すなわち、アップリンク・ビデオ・セッションごとに単一のビデオ送信側および複数のビデオ受信側がある）実施形態に関して図示され、本明細書で説明されるが、図示され本明細書で説明されるマネージャ１７２のさまざまな機能を、他のタイプのコンテンツ分配方式を使用して提供される他のタイプのアップリンク・ビデオ・セッション内での使用のために適合させることができることに留意されたい。

マネージャ１７２のサービスを利用しないアップリンク・ビデオ・セッションが、おそらくは、ベスト・エフォート処理だけを与えられ、したがって、輻輳の場合に信頼できないものになるはずであることに留意されたい。

主に、セルラ・セクタを基礎とするビデオ送信側の送信ビット・レートの制御に関して図示され、本明細書で説明されるが、マネージャ１７２を、グループとして複数のセルラ・セクタのビデオ送信側の送信ビット・レートを制御するように構成することもできることに留意されたい。一実施形態では、たとえば、ネットワークのより上のレベルでの輻輳の場合に、マネージャ１７２は、輻輳を経験するネットワークのより上のレベルによってサービスされるセルラ・セクタのすべてに関連するビデオ送信側のビット・レートを制御することができる。たとえば、３ＧＰＰネットワーク内のサービング・ゲートウェイ（ＳＧＷ）での輻輳の場合に、マネージャ１７２は、そのＳＧＷによってサポートされる関連するデータ経路を有するセルラ・セクタの一部またはすべての一部またはすべてのビデオ送信側にＴＭＭＢＲを発行することができる。同様に、たとえば、３ＧＰＰネットワーク内のＰＤＮゲートウェイ（ＰＧＷ）での輻輳の場合に、マネージャ１７２は、そのＰＧＷによってサポートされる関連するデータ経路を有するセルラ・セクタの一部またはすべての一部またはすべてのビデオ送信側にＴＭＭＭＢＲを発行することができる。マネージャ１７２を、ビデオ送信側のビット・レートの監視および制御のさまざまな他の粒度をサポートするように構成できることに留意されたい。

主に特定の制御プロトコル（たとえば、ＲＴＰ／ＲＴＣＰおよび関連するプロトコル）を使用するビデオ送信側の送信ビット・レートの制御に関して図示され、本明細書で説明されるが、マネージャ１７２を、さまざまな他の適切なプロトコルを使用してビデオ送信側の送信ビット・レートを制御するように構成することもできることに留意されたい。したがって、本明細書でのＲＴＣＰ状況メッセージ（たとえば、ＲＴＣＰ ＳＲ、ＲＴＣＰ ＲＲ、ＡＶＰＦメッセージなど）への言及は、状況メッセージまたは状況トラフィックとしてより一般的に解釈することができ、本明細書でのＲＴＣＰベースの送信ビット・レート変更メッセージ（たとえば、ＴＭＭＢＲメッセージ）ヘの言及を、より包括的に、送信ビット・レート変更メッセージと解釈することができる。

主に、セルラ・ネットワーク内の無線アップリング制御能力の実施形態の提供に関して本明細書で図示し、説明したが、無線アップリンク制御能力の実施形態を、他のタイプの無線広域ネットワーク（たとえば、セルラベースのネットワーク以外のネットワーク）、無線ローカル・エリア・ネットワーク（たとえば、Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ（ＷｉＦｉネットワークなど））など、他のタイプの無線ネットワーク内で提供することもできることに留意されたい。したがって、特定のタイプの無線ネットワークのコンテキスト内で本明細書で使用されるさまざまな用語が、より一般的に言及できることに留意されたい。たとえば、主に、ＰＢＲの文脈で図示され、説明されるが、他のタイプの用語が、他のタイプのネットワーク内で使用され（たとえば、ＷｉＭＡＸネットワーク内で使用される用語「スロット」）、ＰＲＢへの本明細書での言及が、より全般的に無線リソース割振り単位を参照するものとして解釈され得ることに留意されたい。

図８は、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。

図８に示されているように、コンピュータ８００は、プロセッサ要素８０２（たとえば、中央処理装置（ＣＰＵ）および／または他の適切な（１つまたは複数の）プロセッサ）と、メモリ要素８０４（たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）など）を含む。コンピュータ８００は、協力するモジュール／プロセス８０５および／またはさまざまな入出力デバイス８０６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、マウスなど）、ユーザ出力デバイス（ディスプレイ、スピーカなど）、入力ポート、出力ポート、受信器、送信器、およびストレージ・デバイス（たとえば、テープ・ドライブ、フロッピ・ドライブ、ハード・ディスク・ドライブ、コンパクト・ディスク・ドライブなど）をも含むことができる。

図示され、本明細書で説明される機能を、ソフトウェア（たとえば、１つまたは複数のプロセッサ上でのソフトウェアの実施を介して）および／またはハードウェア（たとえば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または任意の他のハードウェア同等物を使用して）で実施できることを了解されたい。

図示され、本明細書で説明される機能を、特殊目的コンピュータを実施するために汎用コンピュータ上で実行される（たとえば、１つまたは複数のプロセッサによる実行を介して）ソフトウェアで実施することができ、かつ／またはハードウェア（たとえば、１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）および／または１つもしくは複数の他のハードウェア同等物を使用して）で実施することができることを了解されたい。

一実施形態では、協力するプロセス８０５を、メモリ８０４にロードし、プロセッサ８０２によって実行して、本明細書で議論される機能を実施することができる。したがって、協力するプロセス８０５（関連するデータ構造を含む）を、コンピュータ可読記憶媒体、たとえば、ＲＡＭメモリ、磁気ドライブ、磁気ディスケット、光ドライブ、光ディスケットなどに格納することができる。

図８に示されたコンピュータ８００が、本明細書で説明される機能要素および／または本明細書で説明される機能要素の諸部分を実施するのに適する全般的なアーキテクチャおよび機能性を提供することに留意されたい。たとえば、コンピュータ８００は、ＭＤ１１０のうちの１つ、ＢＳ１２２、サーバ１５０のうちの１つ、管理システム１６０、無線アップリンク・コントローラ１７０、スケジューラ１７１、およびマネージャ１７２のうちの１つまたは複数を実施するのに適する全般的なアーキテクチャおよび機能性を提供する。

本明細書でソフトウェア方法として議論されるステップのいくつかを、ハードウェア内で、たとえばさまざまな方法ステップを実行するためにプロセッサと協力する回路網として実施することができることが企図されている。本明細書で説明される機能／要素の諸部分を、コンピュータ・プログラム製品として実施することができ、ここで、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および／または技法が呼び出されまたは他の形で提供されるようにコンピュータの動作を適合させる。発明的方法を呼び出す命令を、固定媒体または取外し可能媒体内に格納し、放送媒体または他の信号担持媒体内のデータ・ストリームを介して送信し、かつ／あるいは命令に従って動作するコンピューティング・デバイス内のメモリ内に格納することができる。

さまざまな実施形態の諸態様は、特許請求の範囲で指定される。さまざまな実施形態の上記および他の態様は、次の番号付きの節で指定される。

１．無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する装置であって、
プロセッサとメモリとを備え、プロセッサは、
セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信し、
セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信し、
セルラ・セクタに関連する条件に応答して、無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定する
ように構成される、装置。

２．無線アップリンク・リソース情報は、
セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするのに使用可能な無線アップリンク・リソースのバジェットを示す最大リソース割振り値と、
セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために現在割り振られている無線アップリンク・リソースの量を示す現在のリソース割振り値と
を含む、節１に記載の装置。

３．アップリンク・ビデオ・セッション情報は、ビデオ送信側のアップリンク・ビデオ・セッションに関連する制御メッセージを介して受信される、節１に記載の装置。

４．制御メッセージは、リアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）メッセージを含む、節３に記載の装置。

５．ＲＴＣＰメッセージは、ビデオ送信側から受信されたＲＴＣＰセンダ・レポート（ＳＲ）と、アップリンク・ビデオ・セッションに関連するビデオ受信側から受信されたＲＴＣＰレシーバ・レポート（ＲＲ）とのうちの少なくとも１つを含む、節４に記載の装置。

６．少なくとも１つの条件は、セルラ・セクタ内の輻輳条件、セルラ・セクタにサービスするネットワーク要素に関連する輻輳条件、新しいビデオ・セッションがセルラ・セクタ内で確立されることの要求、セルラ・セクタ内の既存のビデオ・セッションの終了、セルラ・セクタのビデオ送信側のうちの１つに関連する無線条件、およびアップリンク・ビデオ・セッションのうちの１つに関連するビデオ受信側から受信されたリソース変更要求のうちの少なくとも１つを含む、節１に記載の装置。

７．プロセッサは、
修正済み送信ビット・レートが決定されたビデオ送信側のうちの１つに向かって、修正済み送信ビット・レートを示すメッセージを伝搬させる
ように構成される、節１に記載の装置。

８．ビデオ送信側に向かって伝搬されるメッセージは、Ｔｅｍｐｏｒａｒｙ Ｍａｘｉｍｕｍ Ｍｅｄｉａ Ｓｔｒｅａｍ Ｂｉｔ Ｒａｔｅ Ｒｅｑｕｅｓｔ（ＴＭＭＢＲ）メッセージである、節７に記載の装置。

９．プロセッサは、
セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションのそれぞれについて、
無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれの複数のアップリンク・ビデオ・セッションのそれぞれの複数の修正済み送信ビット・レートを決定し、
修正済み送信ビット・レートが決定された複数のビデオ送信側に向かって、それぞれの修正済み送信ビット・レートを示すそれぞれの複数のメッセージを伝搬させる
ように構成される、節１に記載の装置。

１０．複数のビデオ送信側は、セルラ・セクタ内でアクティブなすべてのアップリンク・ビデオ・セッションのすべてのビデオ送信側を含む、節９に記載の装置。

１１．メッセージのうちの少なくとも１つは、そのアップリンク・ビデオ・セッションのその送信ビット・レートを減らすように関連するビデオ送信側に指示するように構成されたビット・レート減少メッセージであり、メッセージのうちの少なくとも１つは、そのアップリンク・ビデオ・セッションのその送信ビット・レートを増やすように関連するビデオ送信側に指示するように構成されたビット・レート増加メッセージである、節９に記載の装置。

１２．プロセッサは、
セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを使用して、セルラ・セクタ内でアクティブなビデオ送信側の総ｇｕａｒａｎｔｅｅｄ ｂｉｔ ｒａｔｅ（ＧＢＲ）を判定し、
セルラ・セクタのビデオ送信側の総ＧＢＲおよびセルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするのに使用可能な無線アップリンク・リソースの量を使用して、セルラ・セクタの総変更帯域幅を決定し、
これによってそれぞれのビデオ送信側の修正済み送信ビット・レートを決定するために、ビデオ送信側へのセルラ・セクタの総変更帯域幅の適用を決定する
ように構成される、節９に記載の装置。

１３．プロセッサは、
セルラ・セクタ内でアクティブなアップリンク・ビデオ・セッションの総送信ビット・レートを判定し、
セルラ・セクタの基地局（ＢＳ）に向かってセルラ・セクタ内のアップリンク・ビデオ・セッションの総送信ビット・レートの表示を伝搬させる
ように構成される、節１に記載の装置。

１４．プロセッサは、
セルラ・セクタ内の関連するアップリンク・ビデオ・セッションの確立に関するビデオ・セッション要求をスケジューリングする際に使用されるスケジューラに情報を提供する
ように構成される、節１に記載の装置。

１５．無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する方法であって、
セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信するステップと、
セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信するステップと、
セルラ・セクタに関連する条件に応答して、無線アップリンク・リソース情報およびアップリンク・ビデオ・セッション情報を使用して、セルラ・セクタ内でアクティブなそれぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定するステップと
を含む方法。

１６．無線ネットワークのセルラ・セクタ内でそれぞれの複数のビデオ送信側の複数のアップリンク・ビデオ・セッションのビット・レートを制御する装置であって、
プロセッサとメモリとを備え、プロセッサは、
ビデオ送信側のアップリンク・ビデオ・セッションに関連する状況メッセージを受信し、
状況メッセージを使用して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の現在の送信ビット・レートを判定し、
セルラ・セクタに関連する条件に応答して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の修正済み送信ビット・レートを決定し、それぞれの複数の送信ビット・レート変更メッセージを使用して、それぞれのビデオ送信側に向かってそれぞれのアップリンク・ビデオ・セッションの修正済み送信レートの表示を伝搬させる
ように構成される、装置。

１７．状況メッセージは、リアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）メッセージを含む、節１６に記載の装置。

１８．ＲＴＣＰメッセージは、
ビデオ送信側のうちの１つからのＲＴＣＰセンダ・レポート（ＳＲ）であって、ＲＴＣＰ ＳＲは、Ａｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＡＶＰＦ）部分を含む、ＲＴＣＰ ＳＲと、
ビデオ送信側のうちの１つから受信されたＡｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＡＶＰＦ）メッセージと、
アップリンク・ビデオ・セッションのうちの１つに関連するビデオ受信側からのＲＴＣＰレシーバ・レポート（ＲＲ）であって、ＲＴＣＰ ＲＲは、Ａｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＡＶＰＦ）部分を含む、ＲＴＣＰ ＲＲと、
アップリンク・ビデオ・セッションのうちの１つに関連するビデオ受信側から受信されたＡｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｆｉｌｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＡＶＰＦ）メッセージと
のうちの少なくとも１つを含む、節１７に記載の装置。

１９．送信ビット・レート変更メッセージは、Ｔｅｍｐｏｒａｒｙ Ｍａｘｉｍｕｍ Ｍｅｄｉａ Ｓｔｒｅａｍ Ｂｉｔ Ｒａｔｅ Ｒｅｑｕｅｓｔ（ＴＭＭＢＲ）メッセージを含む、節１６に記載の装置。

２０．無線ネットワークのセルラ・セクタ内のそれぞれの複数のビデオ送信側の複数のアップリンク・ビデオ・セッションのビット・レートを制御する方法であって、
ビデオ送信側のアップリンク・ビデオ・セッションに関連する状況メッセージを受信するステップと、
状況メッセージを使用して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の現在の送信ビット・レートを判定するステップと、
セルラ・セクタに関連する条件に応答して、ビデオ送信側のそれぞれのアップリンク・ビデオ・セッションの複数の修正済み送信ビット・レートを決定し、それぞれの複数の送信ビット・レート変更メッセージを使用して、それぞれのビデオ送信側に向かってそれぞれのアップリンク・ビデオ・セッションの修正済み送信ビット・レートの表示を伝搬させるステップと
を含む方法。

本発明の教示を組み込むさまざまな実施形態を図示し、本明細書で詳細に説明したが、当業者は、それでもこれらの教示を組み込む多数の他の変更された実施形態を容易に考案することができる。

Claims (10)

1. 無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する装置であって、
   プロセッサとメモリとを備え、前記プロセッサは、
   前記セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信し、
   前記セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、前記セルラ・セクタ内でアクティブな前記それぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信し、
   前記セルラ・セクタに関連する条件に応答して、前記無線アップリンク・リソース情報および前記アップリンク・ビデオ・セッション情報を使用して、前記セルラ・セクタ内でアクティブな前記それぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定する
   ように構成される、装置。
2. 前記無線アップリンク・リソース情報は、
   前記セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするのに使用可能な無線アップリンク・リソースのバジェットを示す最大リソース割振り値と、
   前記セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために現在割り振られている無線アップリンク・リソースの量を示す現在のリソース割振り値と
   を含む、請求項１に記載の装置。
3. 前記アップリンク・ビデオ・セッション情報は、ビデオ送信側の前記アップリンク・ビデオ・セッションに関連する制御メッセージを介して受信される、請求項１に記載の装置。
4. 前記制御メッセージは、リアルタイム・トランスポート制御プロトコル（ＲＴＣＰ）メッセージを含む、請求項３に記載の装置。
5. 前記ＲＴＣＰメッセージは、前記ビデオ送信側から受信されたＲＴＣＰセンダ・レポート（ＳＲ）と、前記アップリンク・ビデオ・セッションに関連するビデオ受信側から受信されたＲＴＣＰレシーバ・レポート（ＲＲ）とのうちの少なくとも１つを含む、請求項４に記載の装置。
6. 少なくとも１つの条件は、前記セルラ・セクタ内の少なくとも１つの輻輳条件、前記セルラ・セクタにサービスするネットワーク要素に関連する輻輳条件、新しいビデオ・セッションが前記セルラ・セクタ内で確立されることの要求、前記セルラ・セクタ内の既存のビデオ・セッションの終了、前記セルラ・セクタの前記ビデオ送信側のうちの１つに関連する無線条件、および前記アップリンク・ビデオ・セッションのうちの１つに関連するビデオ受信側から受信されたリソース変更要求のうちの少なくとも１つを含む、請求項１に記載の装置。
7. 前記プロセッサは、
   前記修正済み送信ビット・レートが決定された前記ビデオ送信側のうちの１つに向かって、前記修正済み送信ビット・レートを示すメッセージを伝搬させる
   ように構成される、請求項１に記載の装置。
8. 前記プロセッサは、
   前記セルラ・セクタ内でアクティブな複数の前記アップリンク・ビデオ・セッションのそれぞれについて、
   前記無線アップリンク・リソース情報および前記アップリンク・ビデオ・セッション情報を使用して、前記セルラ・セクタ内でアクティブな前記それぞれの複数のアップリンク・ビデオ・セッションのそれぞれの複数の修正済み送信ビット・レートを決定し、
   前記修正済み送信ビット・レートが決定された複数のビデオ送信側に向かって、前記それぞれの修正済み送信ビット・レートを示すそれぞれの複数のメッセージを伝搬させる
   ように構成される、請求項１に記載の装置。
9. 前記プロセッサは、
   前記セルラ・セクタ内でアクティブな前記アップリンク・ビデオ・セッションの総送信ビット・レートを判定し、
   前記セルラ・セクタの基地局（ＢＳ）に向かって前記セルラ・セクタ内のアップリンク・ビデオ・セッションの前記総送信ビット・レートの表示を伝搬させる
   ように構成される、請求項１に記載の装置。
10. 無線ネットワークのセルラ・セクタのアップリンク・ビデオ・セッションの送信ビット・レートを制御する方法であって、
    前記セルラ・セクタ内でアップリンク・ビデオ・セッションをサポートするために使用可能な無線アップリンク・リソースの量を示す無線アップリンク・リソース情報を受信することと、
    前記セルラ・セクタ内でアクティブな複数のアップリンク・ビデオ・セッションを識別し、前記セルラ・セクタ内でアクティブな前記それぞれのアップリンク・ビデオ・セッションの複数の送信ビット・レートを含む、アップリンク・ビデオ・セッション情報を受信することと、
    前記セルラ・セクタに関連する条件に応答して、前記無線アップリンク・リソース情報および前記アップリンク・ビデオ・セッション情報を使用して、前記セルラ・セクタ内でアクティブな前記それぞれのアップリンク・ビデオ・セッションのうちの１つの修正済み送信ビット・レートを決定することと
    を含む方法。

Images