JP2014534489A - 帯域幅および対応する装置を制御する方法 - Google Patents

Abstract

本発明は、装置およびこの装置での方法に関する。この装置は、アダプティブ・ストリーミングのサーバを含む第１のネットワークに対する第１のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置を含む第２のネットワークに対する第２のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置によってリクエストされた少なくとも１つのストリーミング・コンテンツを検出するストリーム識別器であって、少なくとも１つのストリーミング・コンテンツは複数のデータ・レートで利用可能である、ストリーム識別器と、複数のデータ・レートからデータ・レートを選択する帯域幅マネージャと、第２のインタフェースで、少なくとも１つのストリーミング・コンテンツを、選択されたデータ・レートを超え、ストリーミング・コンテンツに利用可能なデータ・レートよりも低いデータ・レートで少なくとも１つのクライアント装置に送信するスケジューラと、を含む。【選択図】図４

Description

本発明は、概ね、ビデオ・ストリーミング・コンテンツの配信に関し、特に、ビデオ・ストリーミング・コンテンツによって使用される帯域幅の制御に関する。

この項は、読者に対し、様々な技術的な態様を紹介することを意図している。これらの技術的な態様は、以下に説明する、さらに／または、以下の請求項に記載する本発明の様々な態様に関連する。この説明が本発明の様々な態様をより良好に理解するための背景情報を読者に対して提供するのに役立つと確信する。従って、それぞれの記載は、この点に鑑みて読まれるべきものであり、先行技術を自認するものではないことを理解すべきである。

メディア配信ストリーミングのソリューションは、主に、ＩＥＴＦ ＲＦＣ ２３２６において規定されているような、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）、Ｍｉｃｒｏｓｏｆｔ社のマイクロソフト・メディア・サーバ（ＭＭＳ）独自プロトコル、または、Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社のリアル・タイム・メッセージング・プロトコル（ＲＴＭＰ）に基づいている。

ＨＴＴＰプロトコルに基づくストリーミング技術の登場により、インターネットを介したコンテンツの配信が可能となっている。これらの技術により、クライアント装置がチャンクと呼ばれる、少数の連続する小さなセグメントの形式で、数秒間のビデオを受信可能となる。各セグメントは、ＨＴＴＰプロトコルを介してリクエストされ、種々の大きさ（形）で存在する場合があることにより、クライアント装置が、常時、ネットワークおよび自己の制約と合致した適切なビットレートを選択できるようになっている。種々のビットレートは、配信されるコンテンツの種々の品質レベルに対応する。クライアント装置によって測定されるネットワーク帯域幅が減少するとすぐに、ネットワーク帯域幅の必要条件に関してより制限の小さいチャンクのリクエストが行われる。クライアント装置によって測定されるネットワーク帯域幅が増加するとすぐに、ネットワーク帯域幅の必要条件に関してより制限の大きいチャンクのリクエストが行われる。

利用可能なチャンクは、一般的には、ストリーミング・サーバによって生成され、提供されるプレイリストに列挙される。プレイリストは、フォーマットのタイプ毎に１つなど、他のプレイリストを示すことができる。プレイリストは、コーデックやコーデックをダウンロードするために必要な帯域幅、さらに、それらをリクエストするための方法など、チャンク・コンテンツを記述する。プレイリスト・フォーマットは、文書「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ ｄｒａｆｔ、 ｐａｎｔｏｓ、 ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ、 ０６」に記載されているものとすることができ、様々なＳＶＣレイヤーを記述するためにコーデック情報を用いて拡張される。

様々なＨＴＴＰストリーミング技術を利用可能である。Ａｐｐｌｅ社のＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）がＲＦＣのドラフトとして公開され、主に、アップル社の装置で使用されている。マイクロソフト社のＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇは、マイクロソフト社のＳｉｌｖｅｒｌｉｇｈｔプラットフォームの一部であり、仕様書は公に入手可能である。Ａｄｏｂｅ社のＯｐｅｎ Ｓｏｕｒｃｅ Ｍｅｄｉａ Ｆｒａｍｅｓｏｒｋ（ＯＳＭＦ）は、マイクロソフト社のソリューションに類似するものである。３ＧＰＰ社は、Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ（ＰＳＳ）システムの仕様書をリリースしている。ＭＰＥＧのワーキング・ループもまた、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）の定義に関連して作成されている。これらのストリーミングのソリューションにおいてＨＴＴＰプロトコルを使用する利点は、ＮＡＴおよびファイアウォールをシームレスに乗り越えるその機能にある。これらのＨＴＴＰストリーミング技術は、帯域幅の制約に適合するためにビデオ品質のアップグレードおよびダウングレードを継続的に、程よく行うことによって、利用可能な帯域幅に関する異常なネットワーク挙動を補償する方法を提供する。

一般的に、複数存在するＨＴＴＰストリーミング技術は、同一のコンセプトに基づいている。これらは、プレイリストのファイル・フォーマット、コンテンツのオプション（ビットレート、画像寸法、フレームレートなど）を記述するために提供されるメタデータ、セグメントの形態で利用可能なコンテンツを表現する構成、サポートされるコーデック、さらに、コンテンツ保護技術において異なっている。

クライアント装置が何らかのオーディオ／ビジュアル（ＡＶ）のコンテンツを再生することを望む場合には、クライアント装置は、最初に、この特定のコンテンツをどのように取得できるかを記述するファイルを取得しなければならない。

これは、ＵＲＬから幾らかの「ファイル」を取得することによってＨＴＴＰを通じて行われる。このファイルは、基本的に、（ビットレートおよび他の特性の観点から）コンテンツの利用可能な表現を列挙し、各々に対し、各時間スライスに対してコンテンツ・セグメントのロードを可能とするＵＲＬを列挙する。例えば、ビデオ・オンデマンド・コンテンツでは、映画の全体の説明が提供される一方で、ライブ放送コンテンツでは、この説明は、短時間のみに渡った範囲となっており、時間の経過に際して新たな項目のみが発見されるように周期的にリロードされる必要がある。

クライアント装置は、自己の機能およびネットワーク環境から得られる情報に依存して、（通常は、自己のビットレートに基づいた）何らかの表現を選択し、コンテンツの最初のセグメントをロードする。クライアント装置は、ネットワークの障害に対処できるようにするために少数のセグメントをバッファする。そこで、各受信されたセグメントからのコンテンツは、１つずつ再生される。同時に、クライアント装置は、受信レートを測定し、ビットレートを増減させることを決定することができる。そのような場合、クライアント装置は、単に、別の表現から次のセグメントをリクエストするだけである。どのＨＴＴＰストリーミング・システムでも、クライアントが再生を継続できるようにする一方で、何らかのビットレートのセグメントから別のビットレートの「次」のセグメントに行くことができるようになっている。

このようにして、ネットワーク上のトラフィックによりコンテンツが受信されるレートに変化が生じると、クライアントは、クライアントのバッファの充足度を安全なレベルに維持可能なビットレートでセグメントを選択することによって反応することができる。実際、クライアントは、通常、より良好な視聴品質を提供する、最も高い可能なビットレートに達するようにし、レンダリングがマクロブロックまたはピクチャのフリーズを発生させるようなデータの受信遅延を発生させないレベルを維持するように試行する。

住宅用ネットワークにおいて、複数のクライアント装置がＨＴＴＰストリーミングを同時に実行することがある。ローカル・ネットワーク上、または、ブロードバンド・ネットワーク上で利用可能な帯域幅がトラフィック全体をサポートするのに十分でない場合には、クライアント装置は、利用可能な帯域幅の各々の配分を取得しようと競合する。ＨＴＴＰストリーミング・アルゴリズムは、各々の装置において、独立して実行され、帯域幅を最適に配分することができない。以下の状況が発生する可能性がある。１つのビデオ・ストリームが高い安定したビットレートを使用する一方で、別のビデオ・ストリームが低ビットレートのままでいるといったような、帯域幅の配分の不公平が発生する場合がある。あるいは、各装置が高ビットレートおよび低ビットレートを交互に使用するような変動が発生する場合がある。時折、複数の装置が、良好でないと判定したネットワークの状態に対して同時に過剰反応し、結果として、各装置のために極めて低いビットレートが選択され、帯域幅の大きな浪費が発生する場合がある。これは、十分な帯域幅を利用可能である場合にも発生することがある。ＨＴＴＰプロトコルを根底とするＴＣＰのメカニズムには、各ストリームに対してパケット受信の黙示的な競合が伴うことがあり、これにより、不公平な状態が安定して発生するか、恒久的な変動が発生するという、同じ結果が生じる。このような挙動は、表示されるビデオの品質が使用されるビットレートに連動しているため、エンドユーザが体験する品質に直接的な影響を与えるものである。

本発明は、各アダプティブ・ストリーミングのコンテンツによって使用される帯域幅の制御を提供することによって、先行技術におけるアダプティブ・ストリーミングの不安定性に関わる懸念の少なくともいくつかを払拭しようとするものである。

本発明は、アダプティブ・ストリーミングのサーバを含む第１のネットワークに対する第１のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置を含む第２のネットワークに対する第２のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置によってリクエストされた少なくとも１つのストリーミング・コンテンツを検出するストリーム識別器であって、少なくとも１つのストリーミング・コンテンツは複数のデータ・レートで利用可能である、ストリーム識別器と、複数のデータ・レートからデータ・レートを選択する帯域幅マネージャと、第２のインタフェースで、少なくとも１つのストリーミング・コンテンツを、選択されたデータ・レートを超え、ストリーミング・コンテンツに利用可能な任意のより高いデータ・レートよりも低いデータ・レートで少なくとも１つのクライアント装置に送信するスケジューラと、を含む装置に関する。

一態様によれば、第１のインタフェースは最大帯域幅受信率を有し、データ・レートの選択は、少なくとも１つのストリーミング・コンテンツのために必要な帯域幅が最大帯域幅受信率よりも低くなるように行われる。

一態様によれば、帯域幅マネージャは、少なくとも１つのストリーミング・コンテンツの少なくとも１つのクライアント装置への送信に優先度を付けるように構成されている。

一態様によれば、この装置は住宅用ゲートウェイである。

本発明の他の目的は、アダプティブ・ストリーミングのサーバを含む第１のネットワークに対する第１のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置を含む第２のネットワークに対する第２のインタフェースと、を含む装置における方法である。この方法は、少なくとも１つのアダプティブ・ストリーミングのクライアント装置によってリクエストされた少なくとも１つのストリーミング・コンテンツを検出するステップであって、少なくとも１つのストリーミング・コンテンツは複数のデータ・レートで利用可能である検出ステップと、複数のデータ・レートからデータ・レートを選択するステップと、第２のインタフェースで、少なくとも１つのストリーミング・コンテンツを、選択されたデータ・レートを超え、ストリーミング・コンテンツに利用可能な任意のより高いデータ・レートよりも低いデータ・レートで少なくとも１つのクライアント装置に送信するステップと、を含む。

本発明の他の目的は、コンピュータ・プログラム製品であって、このプログラムがコンピュータ上で実行される際に、本発明に係る方法の各ステップを実行するプログラム・コード・インストラクションを含む、コンピュータ・プログラム製品である。「コンピュータ・プログラム製品」とは、コンピュータ・メモリなど、プログラムを含む記憶空間からなるものだけでなく、電気信号や光学信号のような信号からなる、コンピュータ・プログラムのサポートを意味する。

本発明は、アダプティブ・ストリーミングのサーバとアダプティブ・ストリーミングのクライアント装置との間に位置する装置のレベルでトラフィック・シェーピングを実行する。帯域幅管理により、想定される同時に行われるサービスの数と、各装置の知覚されるサービスのＱｏＥ（体感品質）との間の最適なトレードオフが実現される。本発明のトラフィック・シェーピングの効果は、各ＨＴＴＰアダプティブ・ストリーミングのクライアントの挙動にとって有益である。これにより、幾つかのストリーム間の競合が抑制、または、制限される。トラフィック・シェーピングが無い場合には、帯域幅の配分がＴＣＰプロトコルの特性、さらに、クライアントのアルゴリズムがどのように「測定する」帯域幅に反応するかによって決定され、これにより、実際、不安定な状況、さらに／または不公平な状況が発生する。トラフィック・シェーピングが有る場合には、各ストリームは、その可変範囲に限定される。ストリームを高いビットレートにすることができる場合、例えば、この理由が別のストリームのトラフィックが一時的に低くなったためである場合には、帯域幅の低下が生じる。なぜならば、高ビットレートのリクエストされたセグメントの到達に多くの時間が費やされるからである。従って、これを補償するために、アダプティブなクライアントは、ビットレートを極めて低くしなくてはならなくなる。従って、ビットレートの変化に大きな幅があり、結果として、ＱｏＥ（体感品質）が低くなる。平均の目標に近い値に知覚される帯域幅を制限することにより、クライアントの帯域幅が高くなりすぎることがなくなり、目標値近傍でより安定するようになる。

さらに、本発明は、種々のビットレートを使用した種々のビデオ・フォーマットの例のように、制御された割合で帯域幅を割り当てることを可能にする。本発明のゲートウェイによって提供されるセントラル・アービトレーションが無い場合には、クライアントは、同様なビットレートの配分を受ける傾向にある。

トラフィックの分類には、ＡＶ（オーディオ／ビジュアル）ストリームおよび他の種類のデータ・フローとの間の優先度に係るルールを含めることができる。これにより、例えば、ＯＴＴビデオの視聴がデータ・ファイルのダウンロードによって妨げられることを防ぐことができる。

家庭用ゲートウェイは、帯域幅管理を行うための良好な場所である。その理由は、家庭用ゲートウェイは、ネットワークおよび装置の制約についての適切な情報を取得する機能を備えており、全てのトラフィックを監視し、従って、ＡＶサービスに属するストリームを識別し、それらのストリームに対する措置を取ることができるからである。

各々の特定の態様は、以下に開示する実施形態の範囲と一致したものである。これらの態様の提示は、読者に対し、発明が採用することのある特定の形態を概略的に提供するためのものに過ぎず、これらの態様は、本発明の範囲を制限するように意図されたものではないことを理解すべきである。実際、本発明は、以下に記載しない様々な態様を含むことがある。

本発明は、添付図面を参照して、以下の実施形態および実施例により良好に理解され、例示されるであろう。これらの実施形態および実施例は、決して限定的なものではない。

実施形態に係るシステムのブロック図である。 実施形態に係るクライアント装置のブロック図である。 実施形態に係るゲートウェイ装置のブロック図である。 実施形態に係るゲートウェイ装置の他のブロック図である。

図１において示されたブロックは、純粋に、機能的なものであり、これらは、必ずしも物理的に別個のものに対応するものではない。すなわち、これらのブロックは、ハードウエアまたはソフトウエアの形態で開発されてもよく、１つまたは幾つかの集積回路として実施されてもよい。

本発明の図面および説明は、本発明の明確な理解のために関連のある要素を例示するように簡略化されており、分かりやすくする目的で、通常のディジタル・マルチメディア・コンテンツ配信の方法およびシステムにおいて存在する多くの他の要素を削除していることを理解すべきである。しかしながら、これらの要素は、本技術分野においてよく知られており、このような要素についての詳細な説明は、本明細書において提供されていない。本発明の開示内容は、当業者にとって公知なこのような変形および改変の全てに関する。

本実施形態に係るシステムは、図１に示されている。システムは、２つのクライアント装置４，５と、インターネット２を介して接続されたストリーミング・サーバ３とを含む。クライアント装置は、ゲートウェイ１を介してインターネットに接続されたローカル・ネットワーク６に設置されている。好ましくは、ローカル・ネットワークは、住宅用ネットワークである。サーバは、ＴＣＰ／ＩＰ接続を介したＨＴＴＰプロトコルを使用して、クライアントのリクエストによりチャンクをクライアントにストリーム送信する。

本実施形態に係るクライアント装置４は、図２に例示されている。クライアント装置は、以降、アダプティブ・ストリーミングのクライアント装置とも呼ばれる。クライアント装置は、ローカル・ネットワーク６に対する第１のインタフェース４４を含む。クライアントは、通信モジュール４３を含み、通信モジュール４３は、サーバ３との通信を行うプロトコル・スタックを含む。特に、通信手段は、本技術分野で良く知られているＴＣＰ／ＩＰスタックを含む。もちろん、通信手段は、クライアントをサーバと通信可能にする他のどのようなタイプのネットワーク、さらに／または、通信手段であってもよい。クライアント装置は、アダプティブ・ストリーミング・モジュール４５を含む。クライアント装置は、サーバからのＨＴＴＰストリーミング・コンテンツを受信するＨＴＴＰストリーミングのクライアントである。クライアント装置は、ネットワークの制約および自己の制約と良好に合致するビットレートでチャンクを継続的に選択する。

クライアントは、コンテンツを復号し、レンダリングするように構成されたビデオ・プレイヤ４６を含む。クライアントは、さらに、クライアントに記憶されたアプリケーションおよびプログラムを実行するプロセッサ４１を含む。クライアントは、サーバから受信したチャンクがビデオ・プレイヤ４６に送信される前にバッファリングするメモリなどの記憶手段４２を含む。特に、メモリは、揮発性メモリである。もちろん、クライアント装置は、クライアント上で実行されるアプリケーションおよびプログラムを記憶するための、図示しない、不揮発性メモリを含む。クライアント装置は、ポータブル・メディア・デバイスでもよく、ラップトップでもよい。

代替的には、クライアント装置は、ビデオ・プレイヤを含まず、ビデオ・プレイヤと接続するインタフェースを含む。そして、クライアント装置は、セットトップ・ボックスなどのビデオ復号器である。

本実施形態に係るゲートウェイは、図３に例示されている。ゲートウェイは、ディジタル加入者線（ＤＳＬ）技術を利用して住宅用ネットワークに対するインターネットのブロードバンド・アクセスを提供するディジタル加入者線ゲートウェイである。もちろん、ゲートウェイは、ケーブル、ファイバ、または、無線など、どのようなタイプのブロードバンド・ゲートウェイであってもよい。ゲートウェイは、ＬＡＮインタフェース１４と、ブロードバンド・インタフェース１３と、通信モジュール１７とを含み、通信モジュール１７は、インタフェースを介して通信するためのプロトコル・スタックを含む。通信モジュールは、ＩＰスタックと表記されるインターネット・プロトコル・スタックを含む。

ゲートウェイは、第１のメモリ１６．１および第２のメモリ１６．２を含む。第１のメモリ１６．１は、プレイリスト・ファイルから抽出された情報を記憶するように構成されている。第２のメモリ１６．２は、インタフェースから受信されるパケット、インタフェースに送信されるパケットをバッファリングするように構成されている。

さらに、ゲートウェイは、帯域幅マネージャ１１と、ストリーム識別器モジュール１５と、スケジューラ１２と、分類器１８とを含むトラフィック・シェーピング・モジュール１９を含んでいる。トラフィック・シェーピング・モジュール１９のこれらの構成については以下においてより詳細に説明する。

ゲートウェイは、様々なモジュールと接続する内部バス１０を含む。さらに、ゲートウェイは、図示しないが、処理手段と、ルーティングおよびブリッジング手段と、一般的な住宅用ゲートウェイ機能を実行するための、当業者にとって公知な全ての手段と、を含む。

ゲートウェイは、さらに図４に例示されている。ストリーム識別器モジュール１５は、ゲートウェイで受信されたストリームを分析するように構成されている。クライアント装置がサービス・リクエストを発する毎に、ストリーム識別器モジュール１５は、このリクエストを識別し、サーバからクライアントに返送されるプレイリストを傍受する（ｉｎｔｅｒｃｅｐｔ）ことによって、サービス情報を収集する。ストリーム識別器モジュール１５は、各ローカル装置宛のプレイリスト・ファイルを傍受し、分析する。プレイリスト・ファイルを分析することによって、サーバからアナウンスされたビットレートなどの情報、さらに、関連するセグメント、ＵＲＬを抽出することが可能となる。プレイリストを傍受するために、ストリーム識別器は、利用可能なストリーミング技術および関連するプロトコルを認識している。各プロトコルについて、ストリーム識別器は、プレイリストを伝送するパケットのタイプを把握している。特に、ストリーム識別器は、Ａｐｐｌｅ社のＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ、Ｍｉｃｒｏｓｏｆｔ社のＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、およびＡｄｏｂｅ社のＯｐｅｎ Ｓｏｕｒｃｅ Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ技術を認識している。もちろん、ストリーム識別器は、他のストリーム技術を認識するように構成されていてもよい。

さらに、ストリーム識別器は、ストリームがゲートウェイでもはや受信されなくなるときを識別する。例えば、或る期間ストリームが受信されない場合、ストリーム識別器は、セッションが終了していると判断し、クライアント装置に対する配信をキャンセルする。

ストリーム識別器１５によって取得された情報は、帯域幅マネージャ１１に送信される。

帯域幅マネージャは、サービスが承認されるかどうかを決定し、サービスに対し、目標ビットレートを割り当て、これと同時に、既に動作している他のサービスがあれば、その目標ビットレートを変更する。帯域幅マネージャは、ブロードバンド・インタフェース上で利用可能な最大帯域幅の値を把握するように構成されている。この値に依存して、帯域幅マネージャは、ストリーム間の帯域幅の分配を決定する。帯域幅マネージャは、第２のメモリを設定（ｃｏｎｆｉｇｕｒｅ）し、検出された各ストリームに対し、第２のメモリ内で特定のキューが作成され、目標送信ビットレートが各キューに設定されるようにする。換言すれば、プレイリストは、各ストリームに対し、ＨＴＴＰストリーミングによって利用可能なビットレートを提供する。プレイリストにより、帯域幅マネージャが各ストリームに対して正確な目標ビットレートを判定できるようにする。各ストリームに対する目標ビットレートを決定した後、帯域幅マネージャは、スケジューラ１２を設定する。

スケジューラ１２は、ローカル・ネットワーク内のパケットの送信を管理するように構成されている。換言すれば、各ストリームには、独立したキューが割り当てられ、このキューには、丁度１つの正確な帯域幅が割り当てられる。パケットは、この目標ビットレートよりも速くは送信されない。同時に、帯域幅は、「保証」されている。すなわち、キューが送信するパケットを有し、目標ビットレートに達しない限り、そのパケットは、他のトラフィックに対して優先される。

ストリームのセッション間の帯域幅の割り当てに関する帯域幅マネージャの決定は、多くのパラメータおよびユーザまたはサービス・プロバイダの嗜好に依存する。これらは、帯域幅マネージャによって実施され、コンテンツ、ネットワーク、クライアント装置などの特性によって与えられる１組のアービトレーション・スキームにつながる（例えば、全てのセッションが自己のフォーマットに比例した帯域幅を取得する公平な配分）。帯域幅マネージャは、まず、利用可能な、複数の想定されるビットレートのステップを把握する機能と共に、ｈｔｔｐアダプティブ・ストリームの本質的な融通性に依存する。

帯域幅の分配は、以下のように行われる。帯域幅の分配は、クライアント装置のタイプに基づく。例えば、テレビジョン・セットのためのストリームは、ポータブル・メディア・プレイヤのためのストリームよりも高い優先度を有する。代替的には、帯域幅の分配は、住宅用ネットワークにおけるクライアント装置の位置に基づくようにすることができる。居間に位置するクライアント装置は、寝室に位置するクライアント装置よりも高い優先度を有するであろう。この分配は、好ましくは、テレビジョン・セット、セットトップ・ボックスなどの据え置き型の装置にとって好ましいものである。帯域幅の分配は、装置のタイプおよび住宅用ネットワーク内の位置の組み合わせに基づくようにすることもできる。代替的には、分配は、複数の装置間で公平になるように設定される。

好ましくは、ゲートウェイは、ストリーム間での優先度を調節可能なユーザ・インタフェースを含む。ユーザ・インタフェース内に入力される項目は、例えば、装置のタイプ、装置の位置、および装置の優先度である。

クライアントに割り当てる帯域幅を計算する例示的な実施形態として、想定されるアルゴリズムを以下に挙げる。
ＢＷを合計の利用可能な帯域幅であると仮定する。
各クライアントｃに対し：
・配分［ｃ］がクライアントｃに与えたいと望む帯域幅のパーセンテージであると仮定する。配分［ｃ］は、上述したように、管理ポリシー、ユーザの嗜好などによって決定される。
・目標［ｃ］を、クライアントｃが選択することを希望するコンテンツ・ビットレートを示すものと仮定する。
・目標［ｃ］は、クライアントｃのためのストリーミング・コンテンツの最も高い値で初期化され、以下のように計算される。
・パーセント［ｃ］をクライアントによる帯域幅の使用量の一時的な算出値を示していると仮定する。

最終的な目標［］テーブルの計算は、以下のアルゴリズムに従って行われる。

ＳＵＭ（目標［］）＞ＢＷであり、
・最大の比（パーセント［ｃ］／配分［ｃ］）のクライアントｃを選択し、既に最も低いレートにあるクライアントを無視する。
・目標［ｃ］： ＝ｃのための次に低いビットレート
・パーセント［ｃ］：＝目標［ｃ］／ＢＷ

次に、「未使用」の帯域幅をクライアントに割り当てる。
未使用：＝ＢＷ − ＳＵＭ（目標［］）

各クライアントｃに対し：
・目標［ｃ］：目標［ｃ］ ＋ （未使用^＊配分［ｃ］）

従って、各クライアントの有する自己のトラフィック・シェーピングによって形成されたトラフィックは、使用したいと望むコンテンツ・ビットレートよりも大きな値になる。これは、クライアントが所望のコンテンツ・ビットレートのリクエストを成功裏に継続するための条件である。その理由は、一般的に、ＨＴＴＰアダプティブ・クライアントが自己の有する帯域幅の１００％の使用に成功することはないためである。

分類器１８は、ゲートウェイで受信されたストリームを識別し、ストリームを第２のメモリにおける適切なキューにルーティングするように構成されている。複数の装置のうちの１つのために受信されたいずれのパケットも、分類器モジュールによって、オーディオ・ビデオ・ストリームのうちの１つ、または、何らかの他のトラフィックに属するものとしてチェックされ、識別される。この分類に基づいて、ＬＡＮへの送信のために、異なるキューにパケットが置かれる。各キューにおけるパケットは、選択されたシェーピング・プロフィールに従って、スケジューラによって配信される。これらのパケットは、目標ビットレートに合致するように転送される。

各クライアントに対して目標ビットレートが選択されるとすぐに、ゲートウェイは、トラフィック・シェーピングを適用し、クライアント装置によってネットワーク帯域幅が知覚されることにより、クライアント装置が所望のビットレートを採用するようにする。これにより、受信の際、より高いビットレートのリクエストを試行可能であると判断させるような帯域幅全体の使用による速度バーストが装置に発生することを防ぐことができる。同時に、各クライアントには、自己の帯域幅の配分の使用のための優先度が保証されている。これにより、クライアントにおいて、ビットレートのダウンピークが生じること、さらに、そのための補償が生じることが回避される。

次に、幾つかの例により、本実施形態の装置を用いてどのようにトラフィック・シェーピングが行われるかについて示す。

第１の例では、クライアント装置のためのストリームは、１ｍｂｐｓ、２ｍｂｐｓ、および３ｍｂｐｓが利用可能である。利用可能な帯域幅は、平均で、２．５ｍｂｐｓである。そこで、ゲートウェイは、２ｍｂｐｓを選択する。その後、クライアント装置は、最大２ｍｂｐｓでストリーミング・コンテンツを受信し、３ｍｂｐｓでコンテンツのリクエストを行わない。これにより、クライアント装置が２ｍｂｐｓを超える帯域幅を使用することが無くなる。

第２の例では、第１のクライアント装置のための第１のストリームは、１ｍｂｐｓ、２ｍｂｐｓ、および３ｍｂｐｓが利用可能であり、第２のクライアント装置のための第２のストリームは、２ｍｂｐｓ、３ｍｂｐｓ、および５ｍｂｐｓが利用可能である。利用可能な帯域幅は、５．５ｍｂｐｓである。優先度は、第１のクライアント装置に置かれる。第１のクライアント装置は、最大３ｍｂｐｓでストリーミング・コンテンツを受信し、第２のクライアント装置は、最大２ｍｂｐｓでストリーミング・コンテンツを受信する。これにより、第２のクライアント装置が２ｍｂｐｓを超える帯域幅を使用することが無くなる。その後、第１のクライアント装置が第１のストリームを受信することがなくなる。より大きな帯域幅の利用が可能であるため、第２のクライアント装置は、最大５ｍｂｐｓでストリーミング・コンテンツを受信する。

別の例は、ＳＤストリームおよびＨＤストリームがリクエストされる場合である。ＳＤストリームおよびＨＤストリームには、各々の最大ビットレートに比例した帯域幅、例えば、ＳＤストリームには、２０％が割り当てられ、ＨＤストリームには、８０％が割り当てられる。

好ましくは、キューの目標ビットレートは、ストリームの目標ビットレートよりも数パーセント大きく設定され、クライアントが安定して自己の選択をストリームの目標変数値に設定できるようにする。

本実施形態においては、帯域幅マネージャは、ブロードバンド・インタフェース上で利用可能な最大帯域幅の値に基づいて、ストリーム間での帯域幅の分配を決定する。代替的には、ブロードバンド・インタフェース上で利用可能な最大帯域幅の代わりに、帯域幅マネージャは、ローカル・ネットワーク上で利用可能な最大帯域幅を考慮することができる。その場合、帯域幅マネージャは、ローカル・ネットワーク上で利用可能な最大帯域幅の値に基づいて、ストリーム間での帯域幅の分配を決定する。これは、ブロードバンド・ネットワークではなく、ローカル・ネットワークにボトルネックが存在する場合に発生する。

本実施形態では、トラフィック・シェーピングは、ゲートウェイで実行される。代替的には、トラフィック・シェーピングは、ローカル・ネットワークに位置し、ゲートウェイに接続されたルータにおいて実行される。

明細書、請求項の範囲、および図面において開示された参照内容は、独立して提供されることも、適切な組み合わせにより提供されることもある。機能は、適宜、ハードウエア、ソフトウエア、または、ハードウエアおよびソフトウエアを組み合わせた形態で実施することができる。

本明細書において、「一実施形態」または「実施形態」と参照している場合、実施形態に係る特定の機能、構造、または特性が本発明の少なくとも一実施態様に含まれることを意味する。明細書の様々な箇所に存在する「一実施形態においては」という記載は、必ずしも、全てが同一の実施形態について言及するものではなく、別個の実施形態または代替的な実施形態が他の実施形態に対して相互に排他的であるものではない。

請求項に存在する参照符号は例示的な目的のみのものであり、請求の範囲に限定的な影響を与えるものではない。

Claims (6)

1. アダプティブ・ストリーミングのサーバを含む第１のネットワークに対する第１のインタフェースと、
   少なくとも１つのアダプティブ・ストリーミングのクライアント装置を含む第２のネットワークに対する第２のインタフェースと、
   前記少なくとも１つのアダプティブ・ストリーミングのクライアント装置によってリクエストされた少なくとも１つのストリーミング・コンテンツを検出するストリーム識別器であって、前記少なくとも１つのストリーミング・コンテンツは前記アダプティブ・ストリーミングのサーバで複数のデータ・レートで利用可能である、前記ストリーム識別器と、
   前記複数のデータ・レートからローカル・データ・レートを選択する帯域幅マネージャと、
   前記アダプティブ・ストリーミングのサーバから前記少なくとも１つのストリーミング・コンテンツを前記ローカル・データ・レートを超える第１のデータ・レートで受信すると、前記第２のインタフェースで、前記少なくとも１つのストリーミング・コンテンツを、前記ローカル・データ・レートを超え、前記第１のデータ・レートよりも低い第２のデータ・レートで前記少なくとも１つのクライアント装置に送信するスケジューラと、
   を含む装置。
2. 前記第１のインタフェースは最大帯域幅受信率を有し、前記帯域幅マネージャは、前記少なくとも１つのストリーミング・コンテンツのために必要な前記帯域幅が前記最大帯域幅受信率よりも低くなるように、前記ローカル・データ・レートの選択を行うように構成されている、請求項１に記載の装置。
3. 前記帯域幅マネージャは、前記少なくとも１つのストリーミング・コンテンツの前記少なくとも１つのクライアント装置への送信に優先度を付けるように構成されている、請求項１または２に記載の装置。
4. 前記装置は住宅用ゲートウェイである、請求項１〜３のいずれか１項に記載の装置。
5. アダプティブ・ストリーミングのサーバを含む第１のネットワークに対する第１のインタフェースと、少なくとも１つのアダプティブ・ストリーミングのクライアント装置を含む第２のネットワークに対する第２のインタフェースと、を含む装置によって実行される方法であって、
   前記少なくとも１つのアダプティブ・ストリーミングのクライアント装置によって前記アダプティブ・ストリーミングのサーバに対してリクエストされた少なくとも１つのストリーミング・コンテンツを検出するステップであって、前記少なくとも１つのストリーミング・コンテンツは前記アダプティブ・ストリーミングのサーバで複数のデータ・レートで利用可能である、前記検出するステップと、
   前記複数のデータ・レートからローカル・データ・レートを選択するステップと、
   前記アダプティブ・ストリーミングのサーバから前記少なくとも１つのストリーミング・コンテンツを前記ローカル・データ・レートを超える第１のデータ・レートで受信すると、前記第２のインタフェースで、前記少なくとも１つのストリーミング・コンテンツを、前記ローカル・データ・レートを超え、前記第１のデータ・レートよりも低い第２のデータ・レートで前記少なくとも１つのクライアント装置に送信するステップと、
   を含む前記方法。
6. コンピュータ・プログラム製品であって、前記プログラムがコンピュータ上で実行される際に、請求項５に記載の方法の各ステップを実行するプログラム・コード・インストラクションを含むことを特徴とする、前記コンピュータ・プログラム製品。
   

Images