JP6096309B2 - モバイルｈｔｔｐ適応ストリーミングを用いるワイヤレスネットワークにおける輻輳管理のための方法および装置 - Google Patents

Description

本非仮特許出願は、米国特許法第１１９条（ｅ）の下で、米国特許商標局に２０１２年１０月２９日に出願された米国仮特許出願第６１／７１９，５１９号に対する優先権を主張し、その仮特許出願の内容全体が引用により本明細書に組み込まれている。

本発明は、モバイルＨＴＴＰ適応ストリーミングを用いるワイヤレスネットワークにおける輻輳管理のための方法および装置に関する。

ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応ストリーミング（ＨＡＳ）は、ビデオオンデマンドおよびリアルタイムコンテンツをストリーミングする一般的な手法として浮上しつつある。例えば、ビデオオンデマンドに関して、ＨＡＳは、ＨＡＳサーバとそれぞれのＨＡＳクライアントとの間で利用可能な帯域幅またはデータ転送速度に基づいて、ビデオ品質を調整できるという意味において適応的である。しかしながら、各ＨＡＳクライアントは、同じリソースを共有する他のＨＡＳクライアントから独立して、そのビデオ品質を個別に適応させる。

モバイルＨＡＳは、モバイルデバイス上でビデオオンデマンドおよびリアルタイムマルチメディアコンテンツを視聴するための好ましい技術に急速になりつつある。モバイルＨＡＳの使用が増加するにつれて、モバイルＨＡＳに関連するトラフィックに関する輻輳に対処することが、ワイヤレスサービスプロバイダにとって次第に重要になってきた。有線ＨＡＳと同様に、モバイルＨＡＳも、ＨＡＳサーバとそれぞれのモバイルＨＡＳクライアントとの間で利用可能な帯域幅またはデータ転送速度に基づいて、ビデオ品質を調整できるという意味において適応的である。

大抵の場合に、モバイルＨＡＳは現在、ワイヤレスベストエフォート（ＢＥ）データ接続を利用する。しかしながら、これは、ワイヤレスアクセスネットワークが輻輳状態になったときに問題になる。なぜなら、ＨＡＳ適応はアクセスネットワーク輻輳状態を適時に識別することができず、それゆえ、モバイルＨＡＳトラフィックによって引き起こされるワイヤレスネットワークへの非常に高いデータ負荷が持続し、結果として、遅延、パケット損失、輻輳状態の悪化を生じるからである。これは特に、個々のクライアントが２−４Ｍｂ／ｓｅｃのデータストリームを受信できるようにする第３世代パートナーシッププロジェクトロングタームエボリューション（３ＧＰＰ ＬＴＥ）ネットワークの場合に当てはまり、その場合、約８−１０のモバイルＨＡＳクライアントによって、サービングｅＮｏｄｅＢまたはセルが簡単に過負荷になる可能性がある。各モバイルＨＡＳクライアントが利用可能な最大のセルスループットを達成しようと試みる、貪欲で非協力的なクライアントの振舞いは、輻輳問題を引き起こす更なる一因となり、同時に、ビデオ品質の配分に関する不公平を増長する。

エンドユーザから見ると、輻輳問題は、ビデオフリーズを伴うビデオ品質の変動に現れる。ワイヤレスサービスプロバイダから見ると、オーバーザトップＨＡＳトラフィックが、ネットワーク輻輳自体の主な誘因のうちの１つと見なされる。

「Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）；ＬＴＥ；Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ−ｔｏ−ｅｎｄ Ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）；Ｐｒｏｇｒｅｓｓｉｖｅ Ｄｏｗｎｌｏａｄ ａｎｄ Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（３ＧＰ−ＤＡＳＨ）」（２０１３年７月）と題する第３世代パートナーシッププロジェクト（３ＧＰＰ）ＴＳ２６．２４７バージョン１１．３．０リリース１１

少なくとも１つの例示的な実施形態は、モバイルＨＴＴＰ適応ストリーミング（ＨＡＳ）を提供するワイヤレスネットワークのセル内の輻輳を制御するための方法を提供する。少なくともこの例示的な実施形態によれば、その方法は、セル内の輻輳の通知に応答して、セル内のモバイルＨＡＳクライアントにおいて、ＨＡＳメディアストリームの次のＨＡＳセグメント要求を遅延時間間隔の間、遅延させることと、モバイルＨＡＳクライアントにおいて、次のＨＡＳセグメントのための低減されたビットレートを計算することであって、低減されたビットレートは、ＨＡＳメディアストリームの先行するＨＡＳセグメントのためのビットレートに対して低減される、計算することと、遅延時間間隔の終了後に、モバイルＨＡＳクライアントによって、低減されたビットレートで次のＨＡＳセグメントを要求することとを含む。

少なくとも１つの他の例示的な実施形態は、ワイヤレス通信ネットワーク内のモバイルＨＴＴＰ適応ストリーミング（ＨＡＳ）のためのモバイルデバイスを提供する。少なくともこの例示的な実施形態によれば、そのモバイルデバイスはＨＡＳクライアントを含むプロセッサを含む。ＨＡＳクライアントは、ワイヤレス通信ネットワークのセル内の輻輳の通知に応答して、ＨＡＳメディアストリームの次のＨＡＳセグメント要求を遅延時間間隔の間、遅延させることと、次のＨＡＳセグメントのための低減されたビットレートを計算することであって、低減されたビットレートは、ＨＡＳメディアストリームの先行するＨＡＳセグメントためのビットレートに対して低減される、計算することと、遅延時間間隔の終了後に、低減されたビットレートで次のＨＡＳセグメントを要求することとを実施するように構成される。

少なくとも１つの他の例示的な実施形態は、アクティブＨＴＴＰ適応ストリーミング（ＨＡＳ）セッション中にワイヤレスネットワークのセル内の輻輳を制御するための方法を提供する。少なくともこの例示的な実施形態によれば、その方法は、セル内の輻輳を検出することと、検出された輻輳に応答して、アクセスネットワーク要素によって、モバイルＨＡＳクライアントとのアクティブＨＡＳセッションのための輻輳制御パラメータを生成することと、モバイルＨＡＳクライアントに輻輳通知メッセージを送信することによって、検出された輻輳をモバイルＨＡＳクライアントに通知することであって、輻輳通知メッセージは、生成された輻輳制御パラメータを含む、通知することとを含む。

少なくとも１つの他の例示的な実施形態は、１つ以上のコンピュータデバイスにおいて実行されるときに、１つ以上のコンピュータデバイスに、モバイルＨＴＴＰ適応ストリーミング（ＨＡＳ）を提供するワイヤレスネットワークのセル内の輻輳を制御するための方法を実行させるコンピュータ実行可能命令を記憶する非一時的コンピュータ可読記憶媒体を提供する。少なくともこの例示的な実施形態によれば、その方法は、セル内の輻輳の通知に応答して、セル内のモバイルＨＡＳクライアントにおいて、ＨＡＳメディアストリームの次のＨＡＳセグメント要求を遅延時間間隔の間、遅延させることと、モバイルＨＡＳクライアントにおいて、次のＨＡＳセグメントのための低減されたビットレートを計算することであって、低減されたビットレートは、ＨＡＳメディアストリームの先行するＨＡＳセグメントのためのビットレートに対して低減される、計算することと、遅延時間間隔の終了後に、モバイルＨＡＳクライアントによって、低減されたビットレートで次のＨＡＳセグメントを要求することとを含む。

少なくとも１つの他の例示的な実施形態は、１つ以上のコンピュータデバイスにおいて実行されるときに、１つ以上のコンピュータデバイスに、アクティブＨＴＴＰ適応ストリーミング（ＨＡＳ）セッション中にワイヤレスネットワークのセル内の輻輳を制御するための方法を実行させるコンピュータ実行可能命令を記憶する非一時的コンピュータ可読記憶媒体を提供する。少なくともこの例示的な実施形態によれば、その方法は、セル内の輻輳を検出することと、検出された輻輳に応答して、アクセスネットワーク要素によって、モバイルＨＡＳクライアントとのアクティブＨＡＳセッションのための輻輳制御パラメータを生成することと、モバイルＨＡＳクライアントに輻輳通知メッセージを送信することによって、検出された輻輳をモバイルＨＡＳクライアントに通知することであって、輻輳通知メッセージは、生成された輻輳制御パラメータを含む、通知することとを含む。

本発明は、本明細書において後に与えられる詳細な説明および添付の図面からさらに十分に理解されるようになり、図面において、同様の要素は同様の参照番号によって表され、図面は一例としてのみ与えられており、本発明を限定するものではない。

通信ネットワークの一部を示す図である。 モバイルハイパーテキスト転送プロトコル（ＨＴＴＰ）適応ストリーミングを用いるワイヤレスネットワーク内の輻輳管理のための方法の例示的な実施形態を示す流れ図である。 モバイルハイパーテキスト転送プロトコル（ＨＴＴＰ）適応ストリーミングを用いるワイヤレスネットワーク内の輻輳管理のための方法の例示的な実施形態を示す流れ図である。 モバイルＨＡＳ適応ストリーミングを提供するワイヤレスネットワーク内の輻輳管理のための方法の別の例示的な実施形態を示す流れ図である。 モバイルＨＡＳ適応ストリーミングを提供するワイヤレスネットワーク内の輻輳管理のための方法の別の例示的な実施形態を示す流れ図である。

これらの図は、特定の例示的な実施形態において用いられる方法、構造および／または材料の全体的特徴を例示し、かつ下記に与えられる書面による説明を補足することを意図していることに留意されたい。しかしながら、これらの図は原寸に比例しておらず、任意の所与の実施形態の正確な構造的または性能的特徴を正確に反映しない場合があり、例示的な実施形態によって包含される値の範囲または特性を定義または限定すると解釈されるべきではない。種々の図面において類似の、または同一の参照番号を使用することは、類似の、または同一の要素または特徴の存在を示すことを意図している。

ここで、幾つかの例示的な実施形態が図示される添付の図面を参照しながら、種々の例示的な実施形態がさらに十分に説明される。

詳細な例示的な実施形態が本明細書において開示される。しかしながら、本明細書において開示される特定の構造的および機能的詳細は、例示的な実施形態を説明するための典型にすぎない。しかしながら、本発明は数多くの代替形態において具現される場合があるので、本明細書において記載される実施形態のみに限定されると解釈されるべきではない。

したがって、例示的な実施形態は、種々の変更形態および代替形態の余地があるが、図面では、それらの実施形態が一例として図示されており、本明細書において詳細に説明されることになる。しかしながら、例示的な実施形態を開示される特定の形態に限定することを意図するものでないことは理解されたい。それどころか、例示的な実施形態は、本開示の範囲内に入る全ての変更形態、均等形態および代替形態を含むことになる。図の説明を通して、同じ番号は同じ要素を指している。

第１の、第２のなどの用語が、種々の要素を説明するために本明細書において用いられる場合があるが、これらの要素はこれらの用語によって限定されるべきではない。これらの用語は、要素を区別するためにのみ用いられる。本開示の範囲から逸脱することなく、例えば、第１の要素を第２の要素と呼ぶことができ、第２の要素を第１の要素と呼ぶことができる。本明細書において用いられるときに、「および／または」という用語は、関連付けられる列挙された物品の１つ以上の物品のありとあらゆる組合せを含む。

ある要素が別の要素に「接続される」または「結合される」と言われるとき、他の要素に直接接続または結合することができるか、または介在する要素が存在する場合がある。対照的に、ある要素が別の要素に「直接接続される」または「直接結合される」と言われるとき、介在する要素は存在しない。要素間の関係を記述するために用いられる他の用語も同様に解釈されるべきである（例えば、「との間」と「との間に直接」、「隣り合う」と「直に隣り合う」など）。

本明細書において用いられる用語は特定の実施形態を説明することのみを目的としており、限定することは意図していない。本明細書において用いられるとき、単数形「１つの（ａ、ａｎ）および「その（ｔｈｅ）は、別段文脈が明確に示さない限り、複数形も含むことを意図している。「備える、および／または含む（ｃｏｍｐｒｉｓｅｓ、ｃｏｍｐｒｉｓｉｎｇ、ｉｎｃｌｕｄｅｓ、ｉｎｃｌｕｄｉｎｇ）」という用語は、本明細書において用いられるときに、述べられた特徴、整数、ステップ、動作、要素および／または構成要素の存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、要素、構成要素および／またはそのグループが存在すること、または追加されることを除外しないことがさらに理解されよう。

幾つかの代替の実施態様では、言及される機能／行為は図面において言及される以外の順序で行われる場合があることにも留意されたい。例えば、順次に図示される２つの図は、実際には、実質的に同時に実行される場合があるか、または関連する機能性／行為によっては、逆の順序において実行される場合もある。

例示的な実施形態を十分に理解してもらうために、以下の説明では、具体的な細部が提供される。しかしながら、これらの具体的な細部を用いることなく、例示的な実施形態が実施される場合があることは当業者には理解されよう。例えば、無用に細かくして例示的な実施形態を分かりにくくしないように、システムがブロック図で図示される場合がある。他の事例では、例示的な実施形態を分かりにくくするのを避けるために、よく知られているプロセス、構造および技法は、不要な細部を用いることなく図示される場合がある。

以下の説明では、例示的な実施形態は、行為および動作の記号表現（例えば、流れ図、フロー図、データフロー図、構造図、ブロック図など）を参照しながら説明されることになり、それらの行為および動作はプログラムモジュールまたは機能プロセスとして実施される場合があり、プログラムモジュールまたは機能プロセスはルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含み、それらは特定のタスクを実行するか、または特定の抽象データ型を実現し、既存のネットワーク要素（例えば、無線ネットワークコントローラ基地局、基地局コントローラ、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ユーザ機器（ＵＥ）、サービングゲートウェイ（ＳＧＷ）、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）、モバイル管理エンティティ（ＭＭＥ）など）において既存のハードウェアを用いて実施される場合がある。そのような既存のハードウェアは、１つ以上の中央処理装置（ＣＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）コンピュータなどを含むことができる。

流れ図はシーケンシャルプロセスとして複数の動作を記述する場合があるが、それらの動作の多くは並列に、一斉にまたは同時に実行される場合がある。さらに、動作の順序は並べ替えることができる。その動作が完了するときに、プロセッサが終了される場合があるが、図には含まれない更なるステップを有する場合もある。１つのプロセスは、メソッド、ファンクション、プロシージャ、サブルーチン、サブプログラムなどに対応する場合がある。１つのプロセスが１つのファンクションに対応するとき、その終了は、そのファンクションが呼出しファンクションまたは主要ファンクションに戻ることに対応する場合がある。

本明細書において開示されるときに、「記憶媒体」、「コンピュータ可読媒体」または「非一時的コンピュータ可読媒体」という用語は、リードオンリーメモリ（ＲＯＭ），ランダムアクセスメモリ（ＲＡＭ）、磁気ＲＡＭ、コアメモリ、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイスおよび／または情報を記憶するための他の有形の機械可読媒体を含む、データを記憶するための１つ以上のデバイスを表す場合がある。「コンピュータ可読媒体」という用語は、限定はしないが、ポータブルもしくは固定記憶デバイス、光記憶デバイス、並びに１つ以上の命令および／またはデータを記憶するか、入れるか、または搬送することができる種々の他の媒体を含む場合がある。

さらに、例示的な実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語またはその任意の組合せによって実現される場合がある。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードにおいて実現されるとき、必要なタスクを実行するプログラムコードあるいはコードセグメントはコンピュータ可読記憶媒体のような機械またはコンピュータ可読媒体に記憶される場合がある。ソフトウェアにおいて実現されるとき、１つ以上のプロセッサが必要なタスクを実行することになる。

コードセグメントが、プロシージャ、ファンクション、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造もしくはプログラム文の任意の組合せを表す場合がある。コードセグメントは、情報、データ、引数、パラメータまたはメモリ内容を渡すことによって、および／または受け取ることによって、別のコードセグメントまたはハードウェア回路に結合される場合がある。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク伝送などを含む任意の適切な手段を介して渡されるか、転送されるか、または送信される場合がある。

本明細書において用いられるときに、「ｅＮｏｄｅＢ」または「ｅＮＢ」という用語は、ノードＢ、発展型ノードＢ、基地局、無線基地局装置（ＢＴＳ）などと同義語と見なすことができ、これ以降、そのような呼ばれる場合もあり、複数の技術世代に及ぶワイヤレス通信ネットワーク内のユーザ機器（ＵＥ）と通信し、ネットワークリソースを提供する送受信機を示す。本明細書において論じられるように、基地局は、本明細書において論じられる方法を実行する能力および機能性に加えて、従来のよく知られている基地局に関連付けられる全ての機能を有することができる。さらに、本明細書において論じられるように、セルという用語は、ｅＮｏｄｅＢによって提供されるセクタカバレッジを指す場合がある。

本明細書において論じられるときに、「ユーザ機器」という用語は、クライアント、モバイルユニット、移動局、モバイルユーザ、モバイル、加入者、ユーザ、遠隔局、アクセス端末、受信機などと同義語と見なすことができ、これ以降、そのような呼ばれる場合もあり、ワイヤレス通信ネットワーク内のワイヤレスリソースの遠隔ユーザを示す。

モバイルＨＡＳクライアントは、例えば、「Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）；ＬＴＥ；Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ−ｔｏ−ｅｎｄ Ｐａｃｋｅｔ−ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）；Ｐｒｏｇｒｅｓｓｉｖｅ Ｄｏｗｎｌｏａｄ ａｎｄ Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（３ＧＰ−ＤＡＳＨ）」（２０１３年７月）と題する第３世代パートナーシッププロジェクト（３ＧＰＰ）ＴＳ２６．２４７バージョン１１．３．０リリース１１において記述されるような、よく知られているクライアントである。これらのようなモバイルＨＡＳクライアントはよく知られているので、詳細な検討は省略される。

例示的な実施形態は、例示を目的として、３ＧＰＰロングタームエボリューション（３ＧＰＰ ＬＴＥ）、ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）に関して、本明細書において説明される。しかしながら、例示的な実施形態は、ユニバーサル移動電気通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ、ＵＭＴＳ）、移動通信のためのグローバルシステム（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＧＳＭ（登録商標））、アドバンスト移動電話サービス（ＡＭＰＳ）システム、狭帯域ＡＭＰＳシステム（ＮＡＭＰＳ）、トータルアクセス通信システム（ＴＡＣＳ）パーソナルデジタルセルラー（ＰＤＣ）システム、合衆国デジタルセルラー（ＵＳＤＣ）システム、ＥＩＡ／ＴＩＡ ＩＳ−９５において記述される符号分割多元接続（ＣＤＭＡ）システム、高速パケットデータ（ＨＲＰＤ）システム、マイクロ波アクセスのための世界規模相互運用（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ、ＷｉＭＡＸ）、ウルトラモバイルブロードバンド（ＵＭＢ）、第４世代（４Ｇ）ＬＴＥおよびＬＴＥアドバンストのような、無線アクセスネットワーク（ＲＡＮ）とともに用いることができる。

１つ以上の例示的な実施形態はビデオコンテンツに関して説明される場合があるが、例示的な実施形態は、オーディオのような他のタイプのマルチメディアコンテンツに適用可能であることは理解されたい。

図１は、通信ネットワークの一部を示す。そのネットワークはワイヤレス通信ネットワーク１００と、バックホールネットワーク１００１とを含む。

図１を参照すると、ワイヤレス通信ネットワーク１００は、サービングゲートウェイ（ＳＧＷ）１０１と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）１０３と、モバイル管理エンティティ（ＭＭＥ）１０８と、ｅＮｏｄｅＢ（ｅＮＢ）１０５とを含む。バックホールネットワーク１００１は、インターネットのようなインターネットプロトコルネットワークとすることができ、ハイパーテキスト転送プロトコル（ＨＴＴＰ）適応ストリーミング（ＨＡＳ）サーバ１１０を含む。

ｅＮＢ１０５は、ＵＥ１を含む複数のＵＥにワイヤレスリソースおよび無線カバレッジを提供する。ＵＥ１は、モバイルＨＡＳクライアント１０を含み、モバイルＨＡＳクライアントは再生バッファＢをさらに含む。モバイルＨＡＳクライアント１０および再生バッファＢの例示的な機能性は、図２Ｂおよび図３Ｂに関して後にさらに詳細に論じられる。明確にするために、図１には、１つのＵＥのみが示される。しかしながら、任意の数のＵＥがｅＮＢ１０５に接続される場合がある。図１に示される例では、ＵＥ１は、ｅＮＢ１０５にアタッチされ、それゆえ、ｅＮＢ１０５はサービングｅＮＢ（またはセル）１０５と呼ばれる場合がある。

図１をさらに参照すると、ｅＮＢ１０５は、輻輳制御機能ブロック２２を含む。輻輳制御機能ブロック２２は、図１において、ｅＮＢ１０５に位置するように示されるが、例示的な実施形態は、この例には限定されない。むしろ、輻輳制御機能ブロック２２は、ＳＧＷ１０１、ＰＧＷ１０３、専用サーバ（図示せず）、ＭＭＥ１０８などのより上位の層に位置する場合がある。輻輳制御機能ブロック２２の例示的な機能性は、図２Ａおよび図３Ａに関して後にさらに詳細に論じられる。

ｅＮＢ１０５はＳＧＷ１０１に動作可能に接続される。複数のｅＮＢがＳＧＷ１０１と通信することができるが、明確にするために１つのみが示される。

ＳＧＷ１０１は、ｅＮＢ１０５に接続されるＵＥからのユーザデータパケットをルーティングし、転送する。さらに、ＳＧＷ１０１は、ｅＮＢ１０５がＰＧＷ１０３にアクセスできるようにする。

ＰＧＷ１０３は、ＵＥ１と、ＨＡＳサーバ１１０、およびインターネットのような外部パケットデータネットワークとの間の接続性を提供する。知られているように、ＰＧＷ１０３は、ポリシー施行、ＵＥのためのパケットフィルタリング、課金支援、合法的傍受およびパケットスクリーニングを実行する。ＳＧＷおよびＰＧＷの一般的な機能性はよく知られているので、さらに詳細な検討は省略される。

図１をさらに参照すると、ＨＡＳサーバ１１０は、同じビデオコンテンツの異なるビットレート分解能（ビットレートとも呼ばれる）の複数の符号化をホストするウェブサーバである。ビデオコンテンツのビットレート分解能が高くなるにつれて、画質が改善され、モバイルＨＡＳクライアント１０にコンテンツを提供するのに、より広い帯域幅が必要とされる。

各ビットレート分解能におけるビデオコンテンツは、より小さなビデオセグメント（例えば、長さが約２秒−５秒）に分割され、ＨＡＳクライアント１０が、ＨＡＳサーバ１１０から次の、または後続のビデオセグメント（または複数のセグメント）を先行するビデオセグメント（または複数のセグメント）とは異なるビットレート分解能において要求することによって、ビットレート分解能を切り替える（例えば、シームレスに切り替える）ことができるようにする。モバイルＨＡＳシステムとの関連で、同じ再生持続時間でも、ビットレートが低くなるほど、結果としてビデオ品質が低下し、セグメントサイズが小さくなり、結果としてネットワークにかかる負荷が小さくなる。

図１に示される例では、ワイヤレス通信ネットワーク１００は、ＳＧＷおよびｅＮＢを含むものとして示される。しかしながら、例示的な実施形態では、ワイヤレス通信ネットワーク１００は、スケジューリングを通して、複数のユーザにわたる共有リソース割り振りをサポートすることができる任意のタイプの無線アクセス技術を含むことができる。その例は、限定はしないが、ＬＴＥおよびエンハンストボイスデータオンリー（ＥＶＤＯ：ｅｎｈａｎｃｅｄ ｖｏｉｃｅ−ｄａｔａ ｏｎｌｙ）無線アクセス技術、高速ダウンリンクパケットアクセス（ＨＳＰＤＡ）、ＨＳＰＤＡ＋、広帯域符号分割多元接続（ＷＣＤＭＡ（登録商標））、マイクロ波アクセスのための世界規模相互運用（ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ、ＷｉＭＡＸ）などを含む。

図１をさらに参照すると、ｅＮＢ１０５はＭＭＥ１０８にも動作可能に接続される。ＭＭＥ１０８は、ワイヤレスアクセスネットワークのための制御ノードであり、加入者およびセッション管理に関連する全ての制御プレーン機能の責任を負う。この観点から、ＭＭＥ１０８は、セキュリティ手順、端末−ネットワーク間セッション処理、アイドル端末位置管理をサポートする。ＭＭＥの一般的な機能性はよく知られているので、さらに詳細な検討は省略される。

アクティブモバイルＨＡＳセッション中にビデオコンテンツをストリーミングするために、モバイルＨＡＳクライアント１０は、ＨＡＳサーバ１１０から特殊マニフェストファイル（例えば、３ＧＰＰ ＴＳ２６．２４７バージョン１１．３．０リリース１１において記述される）を取り出すことによって開始する。マニフェストファイルは、ビデオコンテンツのための利用可能なビットレート、符号化、セグメント（例えば、識別情報、持続時間など）についての情報と、コンテンツを要求する方法に関する仕様とを含む。これらのようなマニフェストファイルは一般的によく知られているので、より詳細な検討は省略される。

先に言及されたように、モバイルＨＡＳクライアント１０は、再生バッファＢを含む。この例では、再生バッファＢは固定再生バッファである。モバイルＨＡＳクライアント１０は、エンドユーザ体験がよどみなく進行することを目指して、固定再生バッファＢを維持する（例えば、約３０秒から約５分に及ぶ）。モバイルＨＡＳクライアント１０は、レート決定アルゴリズム（ＲＤＡ）を用いて、ＨＡＳサーバ１１０から要求されるビデオセグメント（またはセグメントグループ）ごとのビットレートを選択する。知られているように、モバイルＨＡＳクライアント１０は、バッファフルネスに関する履歴データと、受信されたセグメントに関する推定利用可能スループット帯域幅とともに、幾つかのあらかじめ設定されたロジック、ヒューリスティックスおよび／またはしきい値を用いて、ＲＤＡを実行することができる。アプリケーション層において、モバイルＨＡＳクライアントベンダーは、モバイルデバイスタイプごとにＲＤＡをカスタマイズする（例えば、異なるビデオキャッシュサイズ、異なるしきい値、異なるレート選択選択肢など）。結果として、異なる製品（例えば、スマートフォン、タブレット、ラップトップコンピュータなど）上のモバイルＨＡＳクライアントが、同じネットワーク状態下で異なる挙動を示す場合がある。これらのＲＤＡ変形／カスタム化は、帯域幅スループットおよび再生バッファフルネスの推定値履歴に対して勾配をかけ、平均値に基づくしきい値を動かすことによって、モバイルＨＡＳクライアントにおいて潜在的なネットワーク輻輳を識別するために種々の種類のヒューリスティックスを利用する。

ＨＡＳサーバ１１０は、モバイルＨＡＳクライアント１０からのそれぞれの要求に応答して、要求されたビットレートで、モバイルＨＡＳクライアント１０に要求されたビデオコンテンツを提供する。その後、モバイルＨＡＳクライアント１０は、受信されたビデオコンテンツをエンドユーザに表示する。

先に言及されたように、従来のネットワークにおけるモバイルＨＡＳは、要求されたビデオビットレートをモバイルＨＡＳクライアント１０が利用可能な推定帯域幅と一致させるために、モバイルＨＡＳクライアント１０とＨＡＳサーバ１１０との間のアプリケーション層シグナリングとワイヤレスベストエフォート（ＢＥ）データ接続とを主に利用する。

より安定したビデオ品質を提供し、ビットレート選択が次々に変化するのを回避するために、次のセグメントのための選択されたビットレートの降下が、特定のしきい値に達したときのみに生じ、間欠的なパケット損失または遅延に起因して生じないように、各モバイルＨＡＳクライアントはＲＤＡしきい値（例えば、バッファフルネスのレベルに関連付けられる）を維持する。

この必要なしきい値機構は、モバイルＨＡＳクライアントにおけるビットレート選択において相当量の慣性を導入し、それにより、輻輳が始まった後に、ある時間（例えば、約数十秒−数分のオーダー）にわたって持続するＨＡＳトラフィックに起因してワイヤレスネットワークの過負荷を引き起こしうる。そのような過負荷の結果として、サービングセルは、パケットをドロップし始める場合があり、それがＴＣＰ再送を引き起こし、過負荷状態をさらに悪化させる一因になる。

知られているように、輻輳／過負荷状態が長びくと、ネットワークの実効スループットがその能力より著しく低く降下する可能性があり、幾つかのモバイルＨＡＳクライアントがバッファ空状態に達し、結果として、ビデオフリーズが生じる。他のモバイルＨＡＳクライアントでは、レート降下はそれらの必要なスループットのオーバーシュートを引き起こす場合があり、それにより、数十秒から数分のオーダーの時間を要する場合があるプロセス収束までＲＤＡを調整することに起因して、後続のビデオ品質が変動する。その一方で、ネットワーク状態を変更することは、収束期間を延長する場合があり、これらの問題を深刻にする恐れがある。

先に言及されたように、モバイルＨＡＳクライアントにおけるＲＤＡ変形／カスタム化は、モバイルＨＡＳクライアントにおいて潜在的なネットワーク輻輳を識別するために、種々の種類のヒューリスティックスを利用する。しかしながら、そのようなヒューリスティックスは、ネットワークの全体的な視点を欠いており、個々のモバイルＨＡＳクライアントごとに別々に適用されるので、輻輳を正確に識別することはできない。さらに、モバイルＨＡＳクライアントは、アクセスネットワークから輻輳に関していかなる指示も受信しないので、ＨＡＳクライアントは自力で輻輳を識別するように委ねられる。

例示的な実施形態は、ＨＡＳトラフィックに対する輻輳をセルレベルにおいてより迅速に解決し、および／またはＨＡＳクライアントごとにレート選択をより安定したレベルにより迅速に（例えば、幾つかのシミュレーション結果では数秒のオーダーで）収束させるための方法、デバイス、コンピュータ可読記憶媒体を提供する。

少なくとも１つの例示的な実施形態によれば、ネットワーク要素（例えば、ｅＮＢ、ＰＧＷ、ＳＧＷ、ＭＭＥなど）における輻輳制御機能モジュールが、サービングセル内で検出された輻輳をモバイルＨＡＳクライアントに通知する。検出された輻輳の通知に応答して、ＨＡＳクライアントは、特殊輻輳モードに入る。特殊輻輳モード動作において、モバイルＨＡＳクライアントは、コンテンツの次のセグメント要求の送信を遅延時間間隔の間、遅延させ、遅延時間間隔後に次のセグメントが要求される低減されたビットレートを計算し、遅延時間間隔の終了後に、低減されたビットレートで次のセグメントを要求する。この方法論は、全てのモバイルＨＡＳクライアントの場合に、より安定したレートへのより迅速な収束を促進する。

遅延時間間隔の持続時間は、セル輻輳を解決するだけの十分な時間があるが、それでも、エンドユーザにおいてビデオ中断を引き起こされないほどビデオ再生バッファを十分にフルにしておくように設定される。一例では、遅延時間間隔の持続時間は、ビデオコンテンツの数セグメントの再生持続時間に等しく、または実質的に等しくすることができる。また、遅延時間間隔の長さは、モバイルＨＡＳクライアントのために現在要求されているセグメントの残りの処理／転送も考慮に入れることができる。すなわち、例えば、遅延時間間隔の持続時間は、モバイルＨＡＳクライアントごとの現在要求されているセグメントの処理／転送の完了後にセル輻輳が解決されるだけの十分な時間になるように設定することができる。

図２Ａおよび図２Ｂは、例示的な実施形態による、輻輳解決のための方法を示す流れ図である。図２Ａおよび図２Ｂに示される方法は、ＨＡＳセグメントを搬送するパケットのインターネットプロトコル（ＩＰ）ヘッダ内の明示的輻輳通知（ＥＣＮ：Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ）による、標準規格に基づくシグナリングを利用する。

知られているように、ＥＣＮはＩＰおよびＴＣＰに対する拡張であり、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のリクエストフォーコメント（ＲＦＣ）３１６８（２００１）において規定される。ＥＣＮによれば、パケットをドロップすることなく、ネットワーク輻輳をエンド・ツー・エンドで通知できるようになる。

少なくともこの例示的な実施形態によれば、ＨＡＳセグメントを伴うＩＰパケットをモバイルＨＡＳクライアント１０に送信する前に、ｅＮＢ１０５にある輻輳制御機能ブロック２２によって、ＨＡＳセグメントを搬送するパケットのＩＰヘッダにＥＣＮを追加することができる。図２Ａの流れ図は、輻輳制御機能ブロック２２の例示的な動作／機能性を示しており、一方、図２Ｂの流れ図は、モバイルＨＡＳクライアント１０の例示的な動作／機能性を示す。

例示のために、かつ例示的な実施形態を論じるのを簡単にするために、モバイルＨＡＳクライアントがあまりにも高いビットレート分解能（「ビットレート」とも呼ばれる）を選択することによって輻輳が引き起こされると仮定される。この仮定により、サービングｅＮＢにおいて輻輳状態を解決するのに、後続のＨＡＳセグメントのために要求されるビットレートをより適切な低い値に調整するだけで十分となる。しかしながら、例示的な実施形態は、輻輳がＨＡＳトラフィックと非ＨＡＳトラフィック（例えば、ウェブブラウジング、ＦＴＰ、電子メールチェックなど）との組合せによって引き起こされる状況においても適用可能である。さらに、図２Ａおよび図２Ｂに示される例示的な実施形態は、簡単にするために、単一のＨＡＳクライアントに関して説明される。しかしながら、同じ、または実質的に同じ方法論が、複数のモバイルＨＡＳクライアントに同時に、または一斉に適用可能であることは理解されたい。

図２Ａを参照すると、サービングｅＮＢ１０５によって提供されるワイヤレスリソースを用いる、モバイルＨＡＳクライアント１０とＨＡＳサーバ１１０との間のアクティブモバイルＨＡＳセッション中に、ステップＳ４０２において、輻輳制御機能ブロック２２が、サービングｅＮＢ１０５において輻輳（例えば、持続する輻輳）を検出する。輻輳制御機能ブロック２２および／またはｅＮＢ１０５は、任意のよく知られている方法でサービングｅＮＢ１０５において輻輳を検出することができる。セル輻輳を検出するための方法はよく知られているので、詳細な検討は省略される。一例では、サービングｅＮＢ１０５は、セル容量を超えるレートが選択されたというＵＥ報告などに基づいて、ｅＮＢ１０５に向かうトラフィックとセルの容量とを比較することによって、セルバッファのコンテンツがしきい値を超えた時点で輻輳を検出することができる。しかしながら、例示的な実施形態はこれらの例に限定されるべきではない。

ステップＳ４０４において、輻輳制御機能ブロック２２は、検出された輻輳をモバイルＨＡＳクライアント１０に通知する。一例では、輻輳制御機能ブロック２２は、ＩＥＴＦ ＲＦＣ３１６８のようにＨＡＳサーバ１１０からＨＡＳセグメントを搬送するパケットのＩＰヘッダ内にＣＥ（輻輳経験）コードポイントフラグを設定することによって、検出された輻輳を明示的輻輳通知（ＥＣＮ）によってモバイルＨＡＳクライアント１０にシグナリングする。図２Ｂに関して後にさらに詳細に論じられるように、輻輳制御機能ブロック２２からの輻輳通知によって、モバイルＨＡＳクライアント１０は、特殊輻輳モードに入り、そのモードは、サービングｅＮＢ１０５において検出された輻輳を解決するのを促進する。

検出された輻輳をモバイルＨＡＳクライアント１０に通知した後のある待ち時間後に、輻輳制御機能ブロック２２は、ステップＳ４１４において、検出された輻輳が解決されたか否かを判定する。一例では、待ち時間は約２秒−約４秒とすることができる。代替的には、待ち時間は省略することができ、輻輳制御機能ブロック２２は、ステップＳ４１４において、検出された輻輳が解決されたか否かを直ちに、または継続的に判定することができる。輻輳制御機能ブロック２２および／またはｅＮＢ１０５は、任意のよく知られている方法で、セル輻輳が解決されたか否かを判定することができる。輻輳が解決されたことを検出するための方法はよく知られているので、詳細な検討は省略される。一例では、ｅＮＢ１０５は、セル容量を超えるレートが選択されたというＵＥ報告などに基づいて、ｅＮＢ１０５に向かうトラフィックとセルの容量とを比較することによって、セルバッファのコンテンツがしきい値を下回った時点で輻輳が解決されたことを検出することができる。しかしながら、例示的な実施形態はこれらの例に限定されるべきではない。

輻輳制御機能ブロック２２が、サービングｅＮＢ１０５において検出された輻輳が解決されたことを検出する場合には、ステップＳ４１６において、輻輳制御機能ブロック２２は、輻輳が解決されたことをモバイルＨＡＳクライアント１０に通知する。少なくとも１つの例示的な実施形態では、輻輳制御機能ブロック２２は、輻輳が解決されたことを検出した後にモバイルＨＡＳクライアント１０に送信されることになる次のＨＡＳセグメントを搬送するパケットのＩＰヘッダ内で（から）、ＣＥコードポイントフラグをリセットする（またはクリアする）ことによって、検出された輻輳が解決されたことをＥＣＮによってモバイルＨＡＳクライアント１０に通知する。

ステップＳ４１４に戻ると、輻輳制御機能ブロック２２が、待ち時間後に依然として輻輳を検出する場合には、そのプロセスはステップＳ４０４に戻り、輻輳制御機能ブロック２２は、モバイルＨＡＳクライアント１０に送信されるＨＡＳセグメントを搬送するパケットのＩＰヘッダ内に設定されたＣＥコードポイントフラグを入れ続ける。その後、そのプロセスは、サービングｅＮＢ１０５における輻輳が解決されるまで、先に論じられたように継続する。図２Ａに示される例では、輻輳制御機能ブロック２２は、サービングｅＮＢ１０５において輻輳が解決されるまで、ＨＡＳセグメントを搬送するＩＰパケット内に設定されたＥＣＮフラグを入れ続ける。

ここで図２Ｂを参照すると、ステップＳ４０３において、モバイルＨＡＳクライアント１０は、図２ＡのステップＳ４０２において輻輳制御機能ブロック２２によって送信された、検出された輻輳の通知を受信する。この例示的な実施形態では、モバイルＨＡＳクライアント１０は、受信されたＩＰパケット（ＨＡＳセグメントを搬送する）に、設定されたＣＥコードポイントフラグビット（輻輳インジケータまたは輻輳インジケータビットとも呼ばれる）があるかを定期的に調べる。一例では、モバイルＨＡＳクライアント１０は、約２秒−６秒の間隔で、受信されたＩＰパケットを定期的に調べることができる。代替的には、モバイルＨＡＳクライアント１０は、ＩＰパケットが受信されるたびに、設定されたＣＥコードポイントフラグビットがあるかを調べることができる。

ステップＳ４０５において、モバイルＨＡＳクライアント１０は、輻輳制御機能ブロック２２から輻輳通知（例えば、設定されたＣＥコードポイントフラグ）を受信するのに応答して、先に言及された特殊輻輳モードに入る。

特殊輻輳モードでは、ステップＳ４０６において、モバイルＨＡＳクライアント１０は、モバイルＨＡＳクライアント１０における再生バッファＢが少ないか、枯渇しているか、概ね空であるかを判定する。一例では、モバイルＨＡＳクライアント１０は、再生バッファＢの現在のコンテンツレベルをしきい値と比較することによって、再生バッファＢが枯渇しているか否かを判定する。しきい値は、約４秒の再生持続時間とすることができる。

ステップＳ４０６において、モバイルＨＡＳクライアント１０が、再生バッファＢが枯渇していないと判定する場合には、モバイルＨＡＳクライアント１０は、ステップＳ４０８において、ＨＡＳサーバ１１０からの後続のビデオセグメント要求を遅延させるか、または停止する遅延時間間隔の持続時間を決定する。

少なくともこの例示的な実施形態では、遅延時間間隔の長さは、モバイルＨＡＳクライアント１０におけるビデオセグメントの平均再生持続時間に基づいて決定することができる。例えば、遅延時間間隔の長さは、少なくとも２つのビデオセグメントの平均再生持続時間に等しく、または実質的に等しくすることができる。別の例では、遅延時間間隔の長さは、輻輳通知がモバイルＨＡＳクライアント１０において受信されたときのモバイルＨＡＳクライアント１０における再生バッファＢのコンテンツレベルに基づくことができる。例えば、モバイルＨＡＳクライアント１０は、遅延時間間隔の持続時間を、ＲＤＡがビットレートを必然的に低減する特定のバッファコンテンツ（またはフルネス）しきい値に再生バッファＢが達するのに必要とされる長さに設定することができる。さらに具体的な例では、遅延時間間隔の持続時間は約４秒とすることができる。さらに別の例では、遅延時間間隔の長さは、少なくとも２つのビデオセグメントの持続時間と約４秒との短い方とすることができる。

また、ステップＳ４０８において、モバイルＨＡＳクライアント１０は、遅延時間間隔の終了後の後続のビデオセグメントのための低減されたビットレートを計算する。例示的な実施形態によれば、後続のビデオセグメントのためのビットレートは、１レベル、または複数レベル（例えば、２レベル）だけ、および／または指数関数的に（例えば、約５０％だけ）低減することができる。

ステップＳ４１０において、モバイルＨＡＳクライアント１０は、ＨＡＳサーバ１１０からの後続のビデオセグメント要求を、ステップＳ４０８において決定された遅延時間間隔の持続時間だけ遅延させる。

ステップＳ４１２において、遅延時間間隔の終了後に、モバイルＨＡＳクライアント１０は、ステップＳ４０８において計算された低減されたビットレートで、次のビデオセグメントを要求する。少なくとも１つの他の例示的な実施形態によれば、モバイルＨＡＳクライアント１０は、従来のＲＤＡしきい値に達するのを待つことなく、低減されたビットレートで後続のビデオセグメントを要求する。

ステップＳ４１７において、モバイルＨＡＳクライアント１０は、セル輻輳が解決されたか否かを判定する。少なくともこの例示的な実施形態によれば、モバイルＨＡＳクライアント１０は、輻輳制御機能ブロック２２からの輻輳インジケータに基づいて、セル輻輳が解決されたか否かを判定する。少なくとも一例では、モバイルＨＡＳクライアント１０が、輻輳制御機能ブロック２２からの一番最近に受信されたパケットのＩＰヘッダが、設定されたＣＥコードポイントフラグビットを含まないと判定する場合には、モバイルＨＡＳクライアント１０は、セル輻輳が解決されたと判定する。一方、輻輳制御機能ブロック２２からの一番最近に受信されたパケットのＩＰヘッダが、設定されたＣＥコードポイントフラグビットを依然として含む場合には、モバイルＨＡＳクライアント１０は、セル輻輳が解決されていないと判定する。

モバイルＨＡＳクライアント１０が、ステップＳ４１７において輻輳が解決されたと判定する場合には、モバイルＨＡＳクライアント１０は、特殊輻輳モードを出て、ステップＳ４１８において、収束した安定したビットレートで、アクティブモバイルＨＡＳセッションを継続する。一例では、モバイルＨＡＳクライアント１０は、後続のビデオセグメントに対して、ＲＤＡによって行われる通常のレート計算を再開する。

ステップＳ４１７に戻ると、モバイルＨＡＳクライアント１０が、セル輻輳が解決されていないと判定する場合には、そのプロセスはステップＳ４０６に戻り、先に論じられたように継続する。ステップＳ４０６に戻ることによって、モバイルＨＡＳクライアント１０は、セル輻輳の解決を促進するために、後続のセグメント要求の更なるビットレート低減および／または遅延が必要であるか否かを再評価することができる。

ステップＳ４０６に戻ると、モバイルＨＡＳクライアント１０が、再生バッファＢが少ないか、または枯渇していると判定する場合には、ステップＳ４２０において、モバイルＨＡＳクライアント１０は、次のビデオセグメントのための低減されたレートを計算し、遅延させることなく、またはわずかだけ遅延させて、計算後の低減されたレートで次のセグメントを要求する。この場合、遅延時間間隔の持続時間はわずか（例えば、約１００ｍｓ以下）とすることができる。一例では、モバイルＨＡＳクライアント１０は、アクティブモバイルＨＡＳセッションのために利用可能な最小ビットレートで、次のビデオセグメントを要求する。モバイルＨＡＳクライアント１０は、ステップＳ４０８に関して先に論じられたのと同じようにして、ステップＳ４２０において低減されたレートを計算することができる。その後、そのプロセスは、ステップＳ４１２に進み、先に論じられたように継続する。

図２Ａおよび図２Ｂに関して先に論じられた例示的な実施形態は、ＨＡＳクライアントが後続のビデオセグメントを要求していないときは、ＨＡＳサーバ１１０からのトラフィックが休止されるので、ＨＡＳトラフィックによって引き起こされる輻輳の解決を比較的迅速に（例えば、シミュレーションモデルでは数秒のうちに）促進する。輻輳解決時間は、既に要求されているセグメントを配信するのにかかる時間によって決定することができる。設定されたＣＥコードポイントフラグを受信することによって、ＴＣＰ窓を縮小することもでき（ＩＥＴＦ ＲＦＣ３１６８において論じられるように）、それも輻輳解決を促進することができることに留意されたい。

輻輳解決をさらに支援するために、輻輳モードにおいて、モバイルＨＡＳクライアント１０は、モバイルＨＡＳビデオセグメントをダウンロードするために用いられるＴＣＰソケットを閉じることができ、それにより、ＴＣＰスタックが、現在要求されているセグメントグループのダウンロードを中断する。

少なくとも幾つかの例示的な実施形態によれば、モバイルＨＡＳクライアント１０が収束した安定したレートに達するために、幾つかのレート調整が必要とされる場合がある。したがって、図２Ａおよび／または図２Ｂに示される動作は、何回か繰返し実行される場合がある。

図３Ａおよび図３Ｂは、別の例示的な実施形態による、輻輳解決のための方法を示す流れ図である。図３Ａおよび図３Ｂに示される方法は、サービングセル内で、図２Ａおよび図２Ｂに示される、ＩＰヘッダ内のＥＣＮフィールドを利用する方法とは異なるタイプの輻輳シグナリングを用いる。図２Ａおよび図２Ｂの場合と同様に、図３Ａの流れ図は、輻輳制御機能ブロック２２の例示的な動作／機能性を示し、一方、図３Ｂの流れ図は、モバイルＨＡＳクライアント１０の例示的な動作／機能性を示す。

輻輳制御機能ブロック２２は、輻輳通知メッセージの形をとる、メッセージに基づくシグナリングを用いて、モバイルＨＡＳクライアント１０と通信する。このメッセージに基づくシグナリングによって、輻輳制御機能ブロック２２は、モバイルＨＡＳクライアント１０に輻輳制御パラメータを通信し、検出されたセル輻輳の解決を促進する。一例では、輻輳通知メッセージは、輻輳制御パラメータを含む。輻輳制御パラメータは、遅延間隔パラメータおよび／またはビットレート低減パラメータを含むことができる。遅延間隔パラメータは、遅延時間間隔のための推奨長さまたは持続時間とすることができる。ビットレート低減パラメータは、遅延時間間隔の終了後の後続のビデオセグメント要求のためのビットレート低減の尺度とすることができる。ビットレート低減パラメータの例は、限定はしないが、後続のＨＡＳセグメントを要求するための最大許容ビットレート、最大許容消費帯域幅（スループット）、現在のレベルから降下する利用可能なビットレートレベル数を含むことができる。

遅延時間間隔のための推奨長さ、およびビットレート低減の尺度は、明示的に（モバイルＨＡＳクライアントごとに、またはまとめて）計算することができる。一例では、輻輳制御機能ブロック２２は、遅延時間間隔の推奨持続時間を計算することができ、検出された輻輳が、その方法を一度実施するだけで解決される。輻輳制御機能ブロック２２は、要求されたビットレートを安定した値に、より迅速に収束できるように、推奨最大ビットレートを計算することができる。一例では、遅延およびレート低減は、輻輳状態の深刻さに基づいて、例えば、無線で送り出されるトラフィックがどの程度セル容量を超えるかに基づいて計算することができる。

図３Ａを参照すると、サービングｅＮＢ１０５によって提供されるワイヤレスリソースを用いる、モバイルＨＡＳクライアント１０とＨＡＳサーバ１１０との間のアクティブモバイルＨＡＳセッション中に、ステップＳ４０２において、輻輳制御機能ブロック２２は、図２Ａに関して先に論じられたのと同じようにして、サービングｅＮＢ１０５における輻輳（例えば、持続する輻輳）を検出する。

サービングｅＮＢ１０５において輻輳を検出した後に、ステップＳ５０３において、輻輳制御機能ブロック２２は、モバイルＨＡＳクライアント１０のための輻輳制御パラメータを生成する。先に言及されたように、輻輳制御パラメータは、遅延間隔パラメータおよび／またはビットレート低減パラメータを含むことができる。

ステップＳ５０５において、輻輳制御機能ブロック２２は、モバイルＨＡＳクライアント１０に輻輳通知メッセージを送信することによって、検出された輻輳および生成された輻輳制御パラメータをモバイルＨＡＳクライアント１０に通知する。一例では、輻輳通知メッセージは、専用メッセージとすることができるか、または既存のＩＰ、媒体アクセス制御（ＭＡＣ）またはＨＡＳアプリケーション層メッセージへの対応するフィールド追加とすることができる。図３Ｂに関して後にさらに詳細に論じられるように、輻輳制御機能ブロック２２からの輻輳通知によって、モバイルＨＡＳクライアント１０は、特殊輻輳モードに入り、そのモードはサービングｅＮＢ１０５において検出された輻輳の解決を促進する。

輻輳が検出されたことをモバイルＨＡＳクライアント１０に通知した後のある待ち時間後に、輻輳制御機能ブロック２２は、図２Ａに関して先に論じられたのと同じようにして、ステップＳ４１４において、検出された輻輳が解決されたか否かを判定する。

輻輳制御機能ブロック２２が、サービングセル内の輻輳が解決されたと判定する場合には、ステップＳ４１６において、輻輳制御機能ブロック２２は、輻輳が解決されたことをモバイルＨＡＳクライアント１０に通知する。少なくとも１つの例示的な実施形態では、先に言及されたように、輻輳制御機能ブロック２２は、専用メッセージ、または既存のＩＰ、媒体アクセス制御（ＭＡＣ）またはＨＡＳアプリケーション層メッセージへの対応するフィールド追加を用いて、モバイルＨＡＳクライアント１０に通知する。

ステップＳ４１４に戻ると、輻輳制御機能ブロック２２が、待ち時間後に依然として輻輳を検出する場合には、そのプロセスはＳ５０３に戻り、輻輳が解決されるまで、先に論じられたように継続する。

ここで図３Ｂを参照すると、ステップＳ５０４において、モバイルＨＡＳクライアント１０は、図３ＡのステップＳ５０５における輻輳制御機能ブロック２２からの初期輻輳通知メッセージにおいて、検出された輻輳の通知および輻輳制御パラメータを受信する。

ステップＳ５０６において、モバイルＨＡＳクライアント１０は、輻輳制御機能ブロック２２からの輻輳通知メッセージを受信するのに応答して、特殊輻輳モードに入る。

特殊輻輳モードでは、ステップＳ４０６において、モバイルＨＡＳクライアント１０は、図２Ｂに関して先に論じられたのと同じようにして、再生バッファＢが少ないか、枯渇しているか、または概ね空であるかを判定する。

ステップＳ４０６において、モバイルＨＡＳクライアント１０が、再生バッファＢが少なくないと判定する場合には、その後、ステップＳ５０８において、モバイルＨＡＳクライアント１０は、輻輳通知メッセージに含まれる遅延間隔パラメータに基づいて、ＨＡＳサーバ１１０からの後続のＨＡＳセグメント要求を遅延させる遅延時間間隔の持続時間を決定する。一例では、遅延間隔パラメータは、遅延時間間隔の推奨持続時間を示すことができる。この例では、モバイルＨＡＳクライアント１０は、遅延時間間隔の持続時間を、輻輳制御機能ブロック２２から受信された遅延時間間隔の推奨持続時間に設定する。

また、ステップＳ５０８において、モバイルＨＡＳクライアント１０は、輻輳制御機能ブロック２２からのビットレート低減パラメータに基づいて、後続のＨＡＳセグメントのための低減されたビットレートを計算する。一例では、ビットレート低減パラメータは、後続のＨＡＳセグメントを要求するための最大許容ビットレートを示すことができる。この例では、モバイルＨＡＳクライアント１０は、低減されたビットレートを、最大許容ビットレート以下になるように設定することができる。

ステップＳ４１０において、図２Ｂに関して先に論じられたように、モバイルＨＡＳクライアント１０は、後続のビデオセグメント要求をＨＡＳサーバ１１０に送信するのを、遅延時間間隔の持続時間だけ遅延させる。

ステップＳ４１２において、図２Ｂに関して先に論じられたのと同じようにして、遅延時間間隔の終了後に、モバイルＨＡＳクライアント１０は、ステップＳ５０８において計算された低減されたビットレートで次のＨＡＳセグメントを要求する。図２Ａおよび図２Ｂに示される例示的な実施形態の場合と同様に、モバイルＨＡＳクライアント１０は、従来のＲＤＡしきい値に達するのを待つことなく、低減されたビットレートで後続のＨＡＳセグメントを要求する。

少なくともこの例示的な実施形態では、モバイルＨＡＳクライアント１０は、特殊輻輳モードのままであり、輻輳制御機能ブロック２２から、検出された輻輳が解決されたことを示す輻輳通知メッセージを受信するまで、低減されたレートで後続のＨＡＳセグメントを要求し続ける。

図３Ｂに戻ると、特殊輻輳モードにある間に、通知がないことは、輻輳（そして解決パラメータ）が存続していることを示す。輻輳状態またはパラメータが変化しない限り、モバイルＨＡＳクライアント１０が特殊輻輳状態にとどまるべきであることを示すのに、輻輳が解消されたことを通知しないだけで十分である。したがって、モバイルＨＡＳクライアント１０は、輻輳状態が変化するか、またはネットワークによって計算された輻輳解決パラメータが変化するときに、輻輳通知メッセージを受信する。しかしながら、代替の例示的な実施形態では、輻輳通知メッセージは定期的に生じることができる。

モバイルＨＡＳクライアント１０が、輻輳が解消されたという通知を受信する場合には、モバイルＨＡＳクライアント１０は、ステップＳ５１７において、検出された輻輳が解決されたと判定する。その後、ステップＳ４１８において、モバイルＨＡＳクライアント１０は、特殊輻輳モードを出て、図２Ｂに関して先に論じられたのと同じようにして、収束した安定したレートで、アクティブモバイルＨＡＳセッションを継続する。

ステップＳ５１７に戻ると、モバイルＨＡＳクライアント１０が、検出された輻輳が解決されないと判定する場合には、そのプロセスはステップＳ４０６に戻り、先に論じられたように継続する。この場合、先に言及されたように、通知がないことは、輻輳（そして解決パラメータ）が存続していることを示し、セル輻輳の解決をさらに促進することを目指して、図３Ｂに示される方法の後続の反復（例えば、ステップＳ４０６、Ｓ４１２、Ｓ５１７、そして必要に応じて、Ｓ５２０、Ｓ５０８およびＳ４１０）をトリガする。

ステップＳ４０６に戻ると、モバイルＨＡＳクライアント１０が、再生バッファＢが少ないか、または枯渇していると判定する場合には、ステップＳ５２０において、モバイルＨＡＳクライアント１０は、次のビデオセグメントのための低減されたレートを計算し、遅延させることなく、またはわずかだけ遅延させて、計算後の低減されたレートで次のセグメントを要求する。この場合、遅延時間間隔の持続時間はわずか（例えば、約１００ｍｓ以下）とすることができる。一例では、モバイルＨＡＳクライアント１０は、アクティブモバイルＨＡＳセッションのために利用可能な最小ビットレートで、次のビデオセグメントを要求する。モバイルＨＡＳクライアント１０は、ステップＳ５０８に関して先に論じられたのと同じようにして、ステップＳ５２０において、低減されたレートを計算することができる。その後、そのプロセスはステップＳ４１２に進み、先に論じられたように継続する。

少なくとも幾つかの例示的な実施形態では、輻輳制御機能ブロック２２は、モバイルＨＡＳクライアント１０がＴＣＰソケットを閉じ、現在のビデオセグメントのダウンロードを直ちに中断することを要求することができる（例えば、要求されたダウンロードがまだ完了していないとき）。

本明細書において論じられる１つ以上の例示的な実施形態による方法は、コンピュータ可読媒体に記憶されるコンピュータ実行可能命令として具現することができる。１つ以上のコンピュータデバイス上で実行されるときに、１つ以上のコンピュータデバイスは、本明細書において論じられる１つ以上の方法を実行することができる。

例示的な実施形態のこれまでの説明は、例示し、説明するために提供されてきた。その説明は、余すところなく述べることや、本開示を限定することは意図していない。特定の例示的な実施形態の個々の要素または特徴は一般的には、その特定の実施形態に限定されるのではなく、具体的に図示または説明されない場合であっても、適用可能な場合には入れ替えることができ、選択された実施形態において用いることができる。また、特定の実施形態は数多くの点で変更することもできる。そのような変形形態は、本開示からの逸脱と見なされるべきではなく、全てのそのような変更形態が、本開示の範囲に入ることを意図している。

Claims (20)

1. モバイルＨＴＴＰ適応ストリーミング（ＨＡＳ）を提供するワイヤレスネットワークのセル内の輻輳を制御するための方法であって、
   アクセスネットワーク要素からセル内のモバイルＨＡＳクライアントによりセル内の輻輳の通知について受信すると、前記モバイルＨＡＳクライアントによって、ＨＡＳメディアストリームの後続のビデオセグメント要求を遅延させるか、または停止する遅延時間間隔について決定することと、
   セル内のモバイルＨＡＳクライアントにおいて、ＨＡＳメディアストリームの次のＨＡＳセグメント要求を遅延時間間隔の間、遅延させることと、
   モバイルＨＡＳクライアントにおいて、次のＨＡＳセグメントのための低減されたビットレートを計算することであって、低減されたビットレートは、ＨＡＳメディアストリームの先行するＨＡＳセグメントのためのビットレートに対して低減される、計算することと、
   モバイルＨＡＳクライアントによって、遅延時間間隔の終了後に、低減されたビットレートで次のＨＡＳセグメントを要求することとを含む方法。
2. モバイルＨＡＳクライアントにおいて、ＨＡＳバッファのコンテンツレベルに基づいて、遅延時間間隔の持続時間を設定することをさらに含む、請求項１に記載の方法。
3. ＨＡＳバッファのコンテンツレベルが、バッファコンテンツしきい値より大きいときに、設定するステップが、（ｉ）２つのＨＡＳセグメントの再生持続時間、（ｉｉ）４秒のうちの一方に等しい遅延時間間隔の持続時間を設定する、請求項２に記載の方法。
4. 先行するＨＡＳセグメントの少なくとも一部を搬送するパケットにおいてセル内の輻輳の通知を受信することをさらに含む、請求項１に記載の方法。
5. セル内の輻輳の通知が、明示的な輻輳通知インジケータである、請求項４に記載の方法。
6. セル内の輻輳の通知を含む輻輳通知メッセージを受信することであって、輻輳通知メッセージは、モバイルＨＡＳクライアントのための輻輳制御パラメータをさらに含む、受信することをさらに含み、
   計算するステップが、受信された輻輳制御パラメータに基づいて、次のＨＡＳセグメントのための低減されたビットレートを計算する、請求項１に記載の方法。
7. 輻輳制御パラメータが、次のＨＡＳセグメントのための低減されたビットレートを示すビットレート低減パラメータを含み、
   計算するステップが、ビットレート低減パラメータに基づいて、次のＨＡＳセグメントのための低減されたビットレートを計算する、請求項６に記載の方法。
8. セル内の輻輳の通知を含む輻輳通知メッセージを受信することであって、輻輳通知メッセージはモバイルＨＡＳクライアントのための輻輳制御パラメータをさらに含む、受信することと、
   輻輳制御パラメータに基づいて、遅延時間間隔の持続時間を設定することとをさらに含む、請求項１に記載の方法。
9. 輻輳制御パラメータが遅延時間間隔のための推奨持続時間を示す遅延間隔パラメータを含み、
   設定するステップが、遅延間隔パラメータに基づいて、遅延時間間隔の持続時間を設定する、請求項８に記載の方法。
10. ワイヤレス通信ネットワーク内のモバイルＨＴＴＰ適応ストリーミング（ＨＡＳ）のためのモバイルデバイスであって、
    アクセスネットワーク要素からワイヤレス通信ネットワークのセル内の輻輳の通知について受信すると、前記ＨＡＳメディアストリームの後続のビデオセグメント要求を遅延させるか、または停止する遅延時間間隔について決定することと、
    ＨＡＳメディアストリームの次のＨＡＳセグメント要求を遅延時間間隔の間、遅延させることと、
    次のＨＡＳセグメントのための低減されたビットレートを計算することであって、低減されたビットレートは、ＨＡＳメディアストリームの先行するＨＡＳセグメントのためのビットレートに対して低減される、計算することと、
    遅延時間間隔の終了後に、低減されたビットレートで次のＨＡＳセグメントを要求することとを実施する
    ように構成されたＨＡＳクライアントを含むプロセッサを備えるモバイルデバイス。
11. 再生バッファをさらに備え、
    ＨＡＳクライアントが、再生バッファのコンテンツレベルに基づいて、遅延時間間隔の持続時間を設定するようにさらに構成される、請求項１０に記載のモバイルデバイス。
12. 再生バッファのコンテンツレベルが、バッファコンテンツしきい値より大きいときに、ＨＡＳクライアントが、遅延時間間隔の持続時間を（ｉ）２つのＨＡＳセグメントの再生持続時間、（ｉｉ）４秒のうちの一方に設定するように構成される、請求項１１に記載のモバイルデバイス。
13. ＨＡＳクライアントが、先行するＨＡＳセグメントの少なくとも一部を搬送するパケット内でセル内の輻輳の通知を受信するようにさらに構成される、請求項１０に記載のモバイルデバイス。
14. セル内の輻輳の通知は、明示的な輻輳通知インジケータである、請求項１３に記載のモバイルデバイス。
15. ＨＡＳクライアントが、
    セル内の輻輳の通知を含む輻輳通知メッセージを受信することであって、輻輳通知メッセージはＨＡＳクライアントのための輻輳制御パラメータをさらに含む、受信することと、
    輻輳制御パラメータに基づいて、次のＨＡＳセグメントのための低減されたビットレートを計算することとを実施するようにさらに構成される、請求項１０に記載のモバイルデバイス。
16. 輻輳制御パラメータが、次のＨＡＳセグメントのための低減されたビットレートを示すビットレート低減パラメータを含み、ＨＡＳクライアントが、ビットレート低減パラメータに基づいて、次のＨＡＳセグメントのための低減されたビットレートを計算するようにさらに構成される、請求項１５に記載のモバイルデバイス。
17. ＨＡＳクライアントが、
    セル内の輻輳の通知を含む輻輳通知メッセージを受信することであって、輻輳通知メッセージはＨＡＳクライアントのための輻輳制御パラメータをさらに含む、受信することと、
    輻輳制御パラメータに基づいて、遅延時間間隔の持続時間を設定することとを実施するようにさらに構成される、請求項１０に記載のモバイルデバイス。
18. 輻輳制御パラメータが、遅延時間間隔のための推奨持続時間を示す遅延間隔パラメータを含み、ＨＡＳクライアントが、遅延間隔パラメータに基づいて、遅延時間間隔の持続時間を設定するようにさらに構成される、請求項１７に記載のモバイルデバイス。
19. アクティブＨＴＴＰ適応ストリーミング（ＨＡＳ）セッション中にワイヤレスネットワークのセル内の輻輳を制御するための方法であって、
    アクセスネットワーク要素において、セル内の輻輳を検出することと、
    検出された輻輳に応答して、アクセスネットワーク要素によって、モバイルＨＡＳクライアントとのアクティブＨＡＳセッションのための輻輳制御パラメータを生成することと、
    モバイルＨＡＳクライアントに輻輳通知メッセージを送信することによって、検出された輻輳をモバイルＨＡＳクライアントに通知することであって、輻輳通知メッセージは、アクティブＨＡＳセッション中にモバイルＨＡＳクライアントによる後続のＨＡＳセグメント要求を遅延させるための推奨持続時間を示す遅延間隔パラメータを含む、生成された輻輳制御パラメータを含む、通知することとを含む方法。
20. 輻輳制御パラメータが、ビットレート低減パラメータを含み、
    ビットレート低減パラメータが、アクティブＨＡＳセッション中にモバイルＨＡＳクライアントに与えられる後続のＨＡＳセグメントのための低減されたビットレートを示す、請求項１９に記載の方法。

Images