(57)【特許請求の範囲】
【請求項１】
通信ネットワークの利用可能な帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルを用いてコンテンツを取得する装置であって、前記コンテンツは少なくとも１つのサーバ上において異なるバージョンで利用可能であり、前記コンテンツの前記異なるバージョンは、異なる伝送ビットレートに対応し、前記通信ネットワークを介して伝送されるように適合されたチャンクに細分化され、前記装置は、前記少なくとも２つのトランスポートプロトコルのうちの１つに従って、前記少なくとも１つのサーバに、前記バージョンのうち１つの少なくとも１つのチャンクの伝送を要求するように構成され、前記トランスポートプロトコルおよび前記バージョンは、前記通信ネットワークにおいて現在利用可能な前記帯域幅の値に応じて選択され、
現在利用可能な前記帯域幅の値が第１の値よりも大きい場合に、前記選択されたトランスポートプロトコルは、第１のトランスポートプロトコルであり、現在利用可能な前記帯域幅の値が前記第１の値よりも小さい場合に、前記選択されたトランスポートプロトコルは、第２のトランスポートプロトコルであり、
前記第１のトランスポートプロトコルは、前記第２のトランスポートプロトコルよりも多くの利用可能なネットワーク帯域幅を必要とする、前記装置。
【請求項２】
前記第１の値は、要求される前記コンテンツの解像度のレベルに応じたものである、請求項１に記載の装置。
【請求項３】
現在のパケットロス率を分析するように構成され、並びに、前記第２のトランスポートプロトコルが、第１の伝送ビットレートに対応するバージョンのチャンクの前記伝送のために選択されたトランスポートプロトコルである場合、および前記現在のパケットロス率が第２の値よりも大きい場合には、これと同一のチャンクではあるが、前記第１の伝送ビットレートよりも低い第２の伝送ビットレートに対応する別のバージョンのチャンクの前記伝送を要求するように構成された、請求項１または２に記載の装置。
【請求項４】
複数の連続したチャンクについて、前記少なくとも２つのトランスポートプロトコルに従って、前記バージョンのうち１つの少なくとも１つのチャンクの前記伝送を連続して要求して、前記コンテンツを取得するように構成された、請求項１から３のいずれか一項に記載の装置。
【請求項５】
タイムスロット上の前記第１および第２のトランスポートプロトコルの使用の所定の配分に従って、さらに使用されなければならない前記トランスポートプロトコルを、それぞれのチャンクについて選択するように構成された、請求項１から４のいずれか一項に記載の装置。
【請求項６】
前記タイムスロットはスライドする、請求項５に記載の装置。
【請求項７】
前記タイムスロット上の前記第１および第２のトランスポートプロトコルの７５％／２５％の所定の配分を使用するように構成された、請求項５または６に記載の装置。
【請求項８】
あるバージョンのチャンクの前記伝送について前記第２のトランスポートプロトコルが選択されるとき、前記選択された第１のトランスポートプロトコルを用いてこのバージョンのチャンクから受信されなかったデータパケットの再送の機構をトリガするように構成された、請求項１から７のいずれか一項に記載の装置。
【請求項９】
前記再送のためのコンテンツサーバからのデータパケットの各再送を要求するように構成された、請求項８に記載の装置。
【請求項１０】
前記第１のトランスポートプロトコルはＴＣＰであり、前記第２のトランスポートプロトコルはＵＤＰである、請求項１から９のいずれか一項に記載の装置。
【請求項１１】
前記第２のトランスポートプロトコルが要求される場合には、前記チャンクについて現在利用可能な前記帯域幅の前記値に最も近い値を有する前記伝送ビットレートに対応する前記コンテンツのバージョンを選択するように構成された、請求項１から１０のいずれか一項に記載の装置。
【請求項１２】
取得しようとするコンテンツのバージョンに対応付けて記憶された記述ファイルであって、このコンテンツを取得するための前記トランスポートプロトコルを選択するために、それらの各伝送ビットレートを記述する前記記述ファイルを復元するように構成された、請求項１から１１のいずれか一項に記載の装置。
【請求項１３】
ストリーミングモードまたはダウンロードモードによって、前記コンテンツの前記伝送を得るように構成された、請求項１から１２のいずれか一項に記載の装置。
【請求項１４】
第１のコンテンツサーバに前記第１のトランスポートプロトコルを使用して前記コンテンツの前記バージョンのうち１つの少なくとも１つの次のチャンクを伝送することを要求し、第２のコンテンツサーバに前記第２のトランスポートプロトコルを使用して前記コンテンツの前記バージョンのうち次の１つの少なくとも１つのチャンクを伝送することを要求するように構成された、請求項１から１３のいずれか一項に記載の装置。
【請求項１５】
通信ネットワークの利用可能な帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルを用いてコンテンツを取得する方法であって、前記コンテンツは少なくとも１つのサーバ上において異なるバージョンで利用可能であり、前記コンテンツの前記異なるバージョンは、異なる伝送ビットレートに対応し、前記通信ネットワークを介して伝送されるように適合されたチャンクに細分化され、前記方法は、コンテンツ取得装置によって実施される、前記少なくとも２つのトランスポートプロトコルのうちの１つに従って、前記少なくとも１つのサーバに、前記バージョンのうち１つの少なくとも１つのチャンクの伝送を要求するステップであって、前記トランスポートプロトコルおよび前記バージョンは、前記通信ネットワークにおいて現在利用可能な前記帯域幅の値に応じて選択された、ステップを含み、
現在利用可能な前記帯域幅の値が第１の値よりも大きい場合に、前記選択されたトランスポートプロトコルは、第１のトランスポートプロトコルであり、現在利用可能な前記帯域幅の値が前記第１の値よりも小さい場合に、前記選択されたトランスポートプロトコルは、第２のトランスポートプロトコルであり、
前記第１のトランスポートプロトコルは、前記第２のトランスポートプロトコルよりも多くの利用可能なネットワーク帯域幅を必要とする、前記方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングモードにあるかフルファイルダウンロードモードにあるかにかかわらない、コンテンツの伝送に関する。
【０００２】
ストリーミングは、通信ネットワーク（有線または無線）を介して、コンテンツのチャンク（または部分  −  微小なファイル）を、それらがストリーミング中でリアルタイムに使用されるために、少なくとも１つのコンテンツ受信機に連続的に伝送することを含むことに注意する。この第１の伝送の形式は、異なるストリーミングプロトコル、例えば、ＵＤＰ上のＲＴＰもしくはＭＰＥＧ−ＴＳ、ＨＴＴＰストリーミング、またはより最近のＨＴＴＰアダプティブストリーミング（ＨＴＴＰ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ）を用いて行われうる。フルファイルダウンロードは、それを再生することを可能とするために、ファイルの全てまたは一部を受信することを必要とする。この第２の伝送形式は、通常、ＴＣＰプロトコル上のｈｔｔｐを用いて行われる。
【０００３】
ここで、“コンテンツ”は、テレビ番組（映像および音声）、ゲームまたはドキュメントを定義し、要求に応じてファイル（マルチメディア、ゲーム、ドキュメント）の形式にておそらく配信されるデータのセットと理解される。
【背景技術】
【０００４】
当業者は、データ伝送のビットレートは、通信ネットワーク内で、時々は著しくおよび／または持続的に変動しうるパラメータであり、コンテンツ受信機のレベルにおいて、受信されたコンテンツの画像および／または音声の復元された品質に変動を引き起こす、ということを知っている。実際に、もし所与の時間において通信ネットワークにより提供された帯域幅がデータ伝送ビットレートと瞬間的に合わなければ、このコンテンツのデータの一部分は、要求しているコンテンツ受信機により受信され得ないであろうし、よって、コンテンツ受信機は、良くても、瞬間的に品質の落ちた画像および／または音声を復元させることしかできず、最悪の場合、何も復元させることができない。
【０００５】
前述した変動の影響を抑えるために、異なる伝送ビットレートに対応する同一コンテンツのいくつかの異なるバージョンから生成することが提案されている。これゆえに、通信ネットワークに接続されたコンテンツ受信機が通信ネットワークを介してコンテンツを受信したいとき、コンテンツ受信機は、それぞれの選択された時間において、この選択された時間においてこの通信ネットワークによって与えられた条件に最適なこのコンテンツのバージョンを必要とし、これはフリーズ画像を回避する。残念ながら、かなりの変動がある環境においては、この解決手法は、低い伝送ビットレートに最もよく対応するバージョンにおいてチャンクの伝送を増加させる傾向があり、これはユーザが体験する全般的な品質を低下させる。状況を改善するために、伝送ビットレートを選択することを担うアルゴリズムに、より厳しい制御を課すことは可能である。しかし、これは、コンテンツ受信機がまさにそのトランスポートプロトコルの原則によって１つまたは複数の同時のアプリケーション（例えば、ダウンロードまたはブラウジング）と通信ネットワークの帯域幅を共有するよう強いられるとき、状況を改善させることはない。
【発明の概要】
【０００６】
よって、本発明は状況を改善する目的を有し、より具体的には、通信ネットワーク内で伝送状況が変動するときのユーザの体験を改善する目的を有する。
【０００７】
この目的のために、本発明は、少なくとも１つのサーバ（ＣＳ）上の異なるバージョンにおいて利用可能なコンテンツを取得するように意図された装置であって、異なるバージョンは、異なる伝送バイナリビットレートに対応して、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルを用いて通信ネットワークを介して伝送されるよう適合されたチャンクに細分化される、装置を提案する。
【０００８】
この装置は、トランスポートプロトコルを選択するように構成されるということによって特徴付けられ、トランスポートプロトコルは、その取得装置に、コンテンツのバージョンの少なくとも１つの要求された次のチャンクを伝送するために、少なくとも１つのサーバによって所与の時間において使用されるべきである。トランスポートプロトコルの選択は、通信ネットワークの利用可能な帯域幅の現在値が厳密に第１の閾値よりも大きいときの第１のトランスポートプロトコル、または帯域幅のこの現在値が第１の閾値以下であるときの（利用可能なネットワーク帯域幅について第１のトランスポートプロトコルの要件よりも少ない要件を有する）第２のトランスポートプロトコルを含む。この装置はさらに、その選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも１つの要求される次のチャンクを伝送する要求を、少なくとも１つのサーバに送信するように構成されている。
【０００９】
本発明に係る装置は、別々に、または組み合わせて獲得されうる他の特徴を備えることができる。特に：
−装置は、コンテンツの定義の要求されるレベルにあるコンテンツの要求されるバージョンに係る第１の閾値を選択するように構成されうる。
−装置は、パケットロス率の現在値を分析するように構成されうる。この場合、装置が第１の伝送ビットレートに対応するバージョンのチャンクの伝送のために第２のトランスポートプロトコルを選択したとき、装置は、これと同一のチャンクではあるが、別のバージョンのチャンクの伝送を要求することができ、この別のバージョンは、パケットロス率の現在値が厳密に第２の閾値よりも大きいときに、第１の伝送ビットレートよりも低い第２の伝送ビットレートに対応する。
−装置は、トランスポートプロトコルを選択し、取得するコンテンツの伝送の間の、複数の所与の時間、よって、コンテンツ全体の伝送の間に適用できる所与の時間において、少なくとも１つのサーバに要求を送信するように構成されうる。
−装置は、タイムスロット上の第１および第２のトランスポートプロトコルの使用の所定の配分に応じて、さらに使用されるべきトランスポートプロトコルを、各所与の時間において選択するように構成されうる。
・タイムスロットはスライドしうる。
・装置は、タイムスロット上において第１および第２のトランスポートプロトコルの７５％／２５％の所定の配分を使用するように構成されうる。
−装置が、バージョンのチャンクの伝送のために第２のトランスポートプロトコルを選択したとき、装置は、第１のトランスポートプロトコルを用いて、このバージョンのチャンクから受信されなかったデータパケットの再送機構をトリガするように構成されうる。
・装置は、再送のためのコンテンツサーバからデータパケットの各再送を要求するように構成されうる。
−第１トランスポートプロトコルはＴＣＰであってもよく、第２のトランスポートプロトコルはＵＤＰであってもよい。
−所与の時間において、第２のトランスポートプロトコルの選択に関し、装置は、この所与の時間において帯域幅の現在値に最も近い値を有する伝送ビットレートに対応するコンテンツのバージョンを選択するように構成されうる。
−装置は、記述ファイルを復元するように構成されてもよく、記述ファイルは、装置が取得を必要としておりそれらの各伝送ビットレートを表すコンテンツのバージョンに対応付けて記憶され、このコンテンツを取得するためにトランスポートプロトコルの第１の選択を行うようにする。
−装置は、ストリーミングモードまたはフルファイルダウンロードモードにてコンテンツの伝送を達成するように構成されうる。
【００１０】
本発明はさらに、上述のいずれかのタイプのコンテンツを取得する装置を備えるコンテンツ受信機を提案する。
【００１１】
このようなコンテンツ受信機は、例えば、セットトップボックスタイプのボックス、デコーダ、レジデンシャルゲートウェイもしくはホームゲートウェイ、据置型コンピュータもしくはラップトップ、携帯電話、パーソナルデジタルアシスタント、または電子タブレットの形態で表現されうる。
【００１２】
本発明はさらに、コンテンツ取得装置によって実施されるステップを実装するコンテンツを取得する方法を提案する。コンテンツ取得装置について上述された特徴は、このコンテンツを取得する方法において、あらゆる組み合わせで使用されうる。
【図面の簡単な説明】
【００１３】
本発明の他の特徴および利点は、これ以降の詳細な説明の検討、および添付の図面にみられるであろう。
【図１】本発明の実施形態に係る３つのコンテンツサーバおよびコンテンツを取得する装置が備えられたコンテンツ受信機が接続された通信ネットワークを、図表にて機能的に示す。
【図２】４つの異なる伝送ビットレートにそれぞれ対応する同一コンテンツの４つの異なるバージョンを図表にて示す。
【図３】通信ネットワークの帯域幅（ＢＷ）の時間的変化（ｔ）の第１の例、および、時間的変化のこの第１の例において、第１の方法にて構成された本発明の実施態様に係るコンテンツを取得する装置に伝送されるコンテンツのチャンクの第１の例を、図表にて機能的に示す。
【図４】通信ネットワークの帯域幅（ＢＷ）の時間的変化（ｔ）の第２の例、および、時間的変化のこの第２の例において、第２の方法にて構成された本発明の実施態様に係るコンテンツを取得する装置に伝送されるコンテンツのチャンクの第２の例を、図表にて機能的に示す。
【００１４】
添付図面は、本発明を完成するのに役立つだけでなく、必要に応じて、その定義に寄与しうる。
【発明を実施するための形態】
【００１５】
本発明の目的は、特に、通信ネットワークＮに結合された少なくとも１つのコンテンツ受信機ＣＲに関連付けられるよう意図されたコンテンツを取得する装置Ｄを提案することである。
【００１６】
以下においては、非限定的な例として、コンテンツ受信機ＣＲはセットップボックス（またＳＴＢ）であると考えられている。しかし、本発明は、このタイプのコンテンツ受信機に限定されない。実際、本発明は、コンテンツを受信するために少なくとも１つの通信ネットワークに接続されることができ、コンテンツを回復することが可能な、あらゆるタイプのコンテンツ受信機に関する。従って、本発明は、例えば、デコーダ、レジデンシャルゲートウェイ、ホームゲートウェイ、据置型コンピュータもしくはラップトップ、携帯電話（スマートフォンタイプも可）、パーソナルデジタルアシスタント（もしくはＰＤＡ）、電子タブレット、またはゲームコンソールにも関係する。
【００１７】
さらに、以下において、非限定的な一例として、コンテンツはマルチメディアコンテンツである。しかし、本発明は、このタイプのコンテンツに限定されない。実際、本発明は、データファイルまたはファイルチャンク、ならびに、特にテレビ番組、ゲーム、映画番組、音楽、およびコンピュータ生成画像（またはＣＧＩ）の形式で利用可能な、あらゆるタイプのコンテンツに関する。
【００１８】
図１は、コンテンツを記憶するのに適する３つのコンテンツサーバＣＳ１からＣＳ３が接続された通信ネットワークＮ、および（本発明に係るコンテンツを取得する装置Ｄの要求により）サーバＣＳ１からＣＳ３のうちの１つによって伝送されるコンテンツをデコードするよう意図されたコンテンツ受信機ＣＲを図示する。
【００１９】
例えば、非限定的に示されるように、セットトップボックスＣＲは、それがデコードする、通信ネットワークＮを介したサーバＣＳ１、ＣＳ２、またはＣＳ３からのコンテンツを回復する役割を果たす少なくとも１つのテレビセットに結合される。
【００２０】
以下においては、非限定的な一例として、通信ネットワークＮは、ｘＤＳＬアクセスネットワークによる使用のために接続されるインターネットネットワークによって構成されるネットワークであるとみなす。しかし、本発明は、この種の通信ネットワークに限定されない。実際、通信ネットワークＮは、有線または無線でありうる。よって、通信ネットワークＮは、ケーブルもしくはファイバー形式の有線ネットワーク、移動もしくはセルラー、もしくはＷＬＡＮ（Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ−あるいは８０２．１１（もしくはＷｉＦｉ）もしくはＷｉＭＡＸ形式も可）、またはＢｌｕｅｔｏｏｔｈ（登録商標）形式の非常に短い範囲の無線ローカルネットワークでさえも、ありうる。
【００２１】
通信Ｒは、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルをサポートすることが可能であるべきことに注意することは重要である。非限定的な一例として、通信ネットワークＮは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）形式の第１のトランスポートプロトコルおよびＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）形式の第２のトランスポートプロトコルをサポートする。しかし、トランスポートプロトコルの他の組み合わせも想定されうる。
【００２２】
第１の（コンテンツ）サーバＣＳ１は、例えば、第１の記憶手段ＳＭ１に異なるコンテンツバージョンＶｊを記憶する役割を果たす。これらの第１の記憶手段ＳＭ１は、ソフトウェアを含む、当業者に既知の任意の形態で表現される。従って、第１の記憶手段ＳＭ１は、メモリであってもよい。
【００２３】
“コンテンツの異なるバージョン”は、異なる伝送ビットレートに対応するバージョンと理解される。図２は、４つの異なる伝送ビットレートにそれぞれ対応する同一コンテンツの４つの異なるバージョンＶ１からＶ４（ｊ＝１〜４）を図示する。例として、第１のバージョンＶ１は１Ｍｂｐｓ（メガビット／秒）、第２のバージョンＶ２は２Ｍｂｐｓ、第３のバージョンＶ３は４Ｍｂｐｓ、第４のバージョンＶ４は６Ｍｂｐｓに対応する。
【００２４】
コンテンツの各バージョンＶｊは、決定された期間の様々なチャンク（または部分  −  微小なファイル）によって構成される。図２の例において、バージョンＶｊの各チャンクは矩形によって表されており、矩形の高さは対応する伝送ビットレートを表す。
【００２５】
同一コンテンツのバージョンの数は、“２”に少なくとも等しい任意の値と等しくなりうる。
【００２６】
例えば、同一コンテンツのバージョンＶｊは、例えばＭＶＣ（Ｍｕｌｔｉｖｉｅｗ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）、ＡＶＣ（Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）、ＳＶＣ（Ｓｃａｌａｂｌｅ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）、ＭＰＥＧ２、Ｈ２６４、および、転送（ストリーミング）または記憶（ダウンローディング）のためのフォーマットにてカプセル化を可能とするより一般的なあらゆる映像圧縮形式（音声データ向けを含む）のような、映像圧縮技術を用いて符号化することで生成されうることに注意されたい。
【００２７】
異なる伝送ビットレートに対応する各コンテンツの異なるバージョンＶｊは、通信ネットワークＮ内で変動する伝送状況に正しく一致されることが理解されるであろう。
【００２８】
図２に示されるように、同一コンテンツのバージョンＶｊは、優先的には、時間的位置が、あるバージョンから他のバージョンまで同一である参照フレームＲＦを備えることに注意されたい。参照フレームＲＦはストリーミング中で伝送されるコンテンツのチャンクにランダムにアクセスすることができるものであることが想起される。示される例において、各参照フレームＲＦは、コンテンツのバージョンＶｊのチャンクの開始に位置される。これにより、コンテンツ受信機ＣＲに設けられたデコーダは、要求に応じて、（参照フレームＲＦの伝送時間である）特定の時間において目に見えるいかなるアーチファクトも生じさせずに（典型的には、各映像チャンクは開始してから、おそらくは、あるチャンクからユーザの目に見えない他のチャンクへ移行するための、キー画像とともに終了する）、あるバージョンＶｊから別のバージョンＶｊ’に移動することができる。
【００２９】
各コンテンツのバージョンＶｊは、優先的には、それらの各ビットレートを記述する記述ファイルに対応して記憶されることにさらに注意されたい。各記述ファイルは、例えば、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）形式である。この記述ファイルについては、さらに後述する。第２のコンテンツサーバＣＳ２および第３のコンテンツサーバ（ＣＳ３）は、ここでは、コンテンツ受信機ＣＲによって受信されていないコンテンツのデータパケットの可能な再送を意図されたものである。これらの利点は、さらに先で理解されるであろう。
【００３０】
第１のサーバＣＳ１に記憶されるバージョンＶｊは、要求により、少なくとも１つのコンテンツ受信機ＣＲに伝送されることが意図される。そのため、各コンテンツ受信機ＣＲは、本発明に係るコンテンツを取得する装置Ｄに関連付けられうる。
【００３１】
ここで、“関連付けられる”は、非限定的に示されるように、コンテンツ受信機ＣＲに直接に結合されること、ならびにコンテンツ受信機ＣＲの必須部分であることの両方であると理解される。従って、コンテンツを取得する装置Ｄは、ソフトウェア（もしくはコンピュータ）モジュールの形で、または電子回路およびソフトウェアモジュールの組み合わせの形式で実現されうる。
【００３２】
このコンテンツを取得する装置Ｄは、コンテンツのバージョンＶｊの少なくとも１つの要求される次のチャンクを伝送するために所与の時間において使用されるべきトランスポートプロトコルとして、通信ネットワークＮの利用可能な帯域幅ＢＷの現在値が厳密に第１の閾値Ｓ１よりも大きいときの第１のトランスポートプロトコル、または、帯域幅ＢＷのこの現在値が第１の閾値Ｓ１以下であるときの第２のトランスポートプロトコルを選択するように構成される。
【００３３】
通信ネットワークＮにおいて利用可能な帯域幅ＢＷは、この通信ネットワークＮが技術的問題またはアクセスネットワークの輻輳を経験するときに、第１の閾値Ｓ１以下となりうることに注意されたい。
【００３４】
第１のトランスポートプロトコルは、第２のトランスポートプロトコルよりも多くの利用可能なネットワーク帯域幅ＢＷを必要とするということに注意することも重要である。これは、特に、ＵＤＰプロトコルよりもより多くの利用可能なネットワーク帯域幅を著しく必要とするＴＣＰプロトコルについての場合である。これは、主に、ＴＣＰが双方向性のものであるという事実に起因し、受信確認（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔｓ）の伝送を必要とし、ウィンドウサイズ調整（またはウィンドウィング）に制約を課し、受信されなかったデータパケットの再送機構を提供する。これに対し、ＵＤＰは、一方向性のものであり（よって、いかなる受信確認も無く）、ウィンドウィングに制限はなく、受信されなかったデータパケットの再送機構を有さない。
【００３５】
ウィドウィングはＴＣＰセッションの間に動的に取り決められるウィンドウのサイズを明示すること、およびウィンドウィングはストリーム制御機構の形式を構成することが想起される。さらに具体的には、データが伝送されるとき、伝送元は受信者から受信確認を受信しなければならず、受信者は伝送元に、受信者が希望するウィンドウのサイズおよび受信者が受信する準備のあるパケットの数の代表値をシグナリングしなければならない。
【００３６】
単なる例示として、１Ｍｂｐｓでのコンテンツの伝達について、３０ｍｓに等しいラウンドトリップタイムと０．０２（または２％）に等しいパケットロス率が存在すると、ＴＣＰは、同じ量のデータを転送するためにはＵＤＰよりも３０％多くの帯域幅を必要とする。本例は、ＵＤＰ上のＲＴＰトラフィックと比較したＴＣＰ上のｈｔｔｐトラフィック（受信されなかったデータパケットの再送機構を含む）に関するものであることに注意されたい。
【００３７】
本発明によれば、第１のプロトコル（ここではＴＣＰ）の代わりにコンテンツのチャンクを復元させるために第２のプロトコル（ここではＵＤＰ）が一時的に使用される度に、このコンテンツを要求したユーザは、（利用可能な帯域幅ＢＷの現在値に最も近い値を有する）高伝送ビットレートに対応するバージョンＶｊを取得する、より大きな可能性を有する。従って、ＵＤＰが選択される度に、例えば、通信ネットワークＮにおける以下の輻輳、ユーザのコンテンツ受信機ＣＲによって回復された品質は、ＴＣＰを使用する場合よりも良い可能性がより高い。例えば、そして輻輳の場合は常に、本発明は、ｈｔｔｐ／ＴＣＰプロトコルが行うのと同様により低いビットレートのチャンクではあるが、ＲＴＰ／ＵＤＰにおけるビットレートよりは高いビットレートのチャンクを要求することができるであろう。
【００３８】
コンテンツを取得する装置Ｄは、所与の時間において第２のトランスポートプロトコルを選択したとき、この所与の時間において利用可能な帯域幅ＢＷの現在値に最も近い値を有する伝送ビットレートに対応するコンテンツのバージョンＶｊを選択するようにも恐らくは構成されうることに、さらに注意されたい。
【００３９】
要求されるコンテンツの異なるバージョンＶｊを知るために、コンテンツを取得する装置Ｄは、好ましくは、そのコンテンツ受信機ＣＲに、関係する第１のサーバＣＳ１からの、これらのバージョンＶｊに対応付けてコンテンツ受信機ＣＲが記憶する（そして、それらの各伝送ビットレートを記述する）記述ファイルを復元するように命令するよう構成されることに注意されたい。この場合、コンテンツ受信機ＣＲが、関連する第１のサーバＣＳ１から、要求された記述ファイルを復元すると、コンテンツを取得する装置Ｄは、通信ネットワークＮの利用可能な帯域幅ＢＷに応じて、選択された（または選ばれた）要求されるコンテンツのバージョンＶｊを絶え間なく連続的方法で制御することにより、コンテンツを取得するためのセッションを開始しうる（ストリーミングモードにおいても、フルファイルダウンロードモードにおいても）。そして、コンテンツを取得する装置Ｄは、関係する第１のサーバＣＳ１から各バージョンＶｊを請求するために、そのコンテンツ受信機ＣＲに、コンテンツを取得する装置Ｄが選択する（および記述ファイルで言及された）各バージョンＶｊの指定を提供する。
【００４０】
以下においては、非限定的な一例として、コンテンツはストリーミングモードで伝送されることとする。
【００４１】
この場合、コンテンツを取得する装置Ｄは、第２のプロトコル（ここではＵＤＰ）を選択したとき、そのコンテンツ受信機ＣＲに第１のサーバＣＳ１とのＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）セッションを開始するように命令しうる。ＲＴＳＰは、ＲＴＰプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）の補足である、ＲＦＣ２３２６規則によって規定されているプロトコルであり、特に、ストリーミングモードでのマルチメディアコンテンツ転送セッションを設定して制御することを目的としたプロトコルであることが想起される。この場合において、コンテンツ受信機ＣＲは、要求されたコンテンツの記述ファイルを取得するために、“ＲＴＳＰ  ｄｅｓｃｒｉｂｅ  ＵＲＩ”メッセージを第１のサーバＣＳ１に送信することができる。次いで、第１のサーバＣＳ１は、“ＲＴＳＰ  ｄｅｓｃｒｉｂｅ  ｒｅｓｐｏｎｓｅ”メッセージで応答して要求された記述ファイルを伝送する。次いで、コンテンツ受信機ＣＲは、ＲＴＰ／ＵＤＰストリーミングセッションを準備するために、“ＲＴＳＰ  ｓｅｔｕｐ”メッセージを第１のサーバＣＳ１に送信することができる。次いで、第１のサーバＣＳ１は、“ＲＴＳＰ  ｓｅｔｕｐ  ｒｅｓｐｏｎｓｅ”メッセージで応答して、このセッションが準備されたことをシグナリングする。次いで、コンテンツ受信機ＣＲは、“ＲＴＳＰ  ｐｌａｙ”メッセージを第１のサーバＣＳ１に送って、第１のサーバＣＳ１に、先に準備されたセッションを開始するように依頼することができる。次いで、第１のサーバＣＳ１は、“ＲＴＳＰ  ｐｌａｙ  ｒｅｓｐｏｎｓｅ”メッセージで応答して、第１のサーバＣＳ１がＲＴＰ／ＵＤＰストリーミングセッションを開始することをシグナリングする。そして、要求されたコンテンツのコンテナを、例えば、ＭＰ４フォーマットまたはＭＰＥＧ−ＴＳフォーマットで、ＵＤＰ上のストリーミングモードで送信されるパケットにカプセル化する。
【００４２】
コンテンツがフルファイルダウンロードモードで伝送されるとき、（ＲＦＣ３９２６規則によって規定されている）ＦＬＵＴＥプロトコルがＲＴＰプロトコルに代えて使用されうることに注意されたい。
【００４３】
コンテンツを取得する装置Ｄがコンテンツのチャンクを復元すると決定する度に、コンテンツを取得する装置Ｄは、選択したバージョンＶｊのこのチャンクを表す識別子、およびこのチャンクの時間と等しく、このチャンクの開始時間を指定するタイムスロットを特定しなければならない。これは、ＲＴＳＰ形式のメッセージを交換することによって行われうる。
【００４４】
コンテンツを取得する装置Ｄは、要求したいコンテンツの解像度のレベルに応じて、第１の閾値Ｓ１を選択するために、構成されうることにも注意されたい。コンテンツの解像度が低いほど、第１の閾値Ｓ１は低くなりうることを理解されたい。これゆえに、第１の閾値Ｓ１は、高い解像度を含む、標準の解像度から非常に高い解像度まで増加して選択されうる。
【００４５】
コンテンツを取得する装置Ｄは、少なくとも異なる２つの方法で動作しうる。
【００４６】
第１の方法は上述されている。制限するものではないが、例えば家庭などの、帯域幅の共有公平性が優先ではないローカルのアプリケーションにも同様に適合される。例えば、（ＣＲ  ＳＴＢまたはホームゲートウェイに接続された）テレビセットＴＳの画面上で、例えばＷｉＦｉ／ＰＬＣストリーミングモードでこのＣＲ  ＳＴＢまたはこのホームゲートウェイと通信可能な据置型通信機器（デスクトップコンピュータなど）または移動型通信機器（例えば、移動電話またはビデオプレイまたはラップトップコンピュータなど）のアイテム上のメモリに記憶されている映像を閲覧したいユーザに適する。
【００４７】
図３は、図表内において、時間ｔに応じた通信ネットワークＮの利用可能な帯域幅ＢＷにおける変化を示す曲線の第１の例を図示する。同図は、この第１の時間的変化曲線において、コンテンツを取得する装置Ｄに伝送されるコンテンツのチャンクをも表す。異なるサイズの白い矩形は、それぞれ３つの異なる伝送ビットレートに対応して、第１トランスポートプロトコル（ここではＴＣＰ（例えばｈｔｔｐとの組み合わせ（すなわちｈｔｔｐ／ＴＣＰ）））を用いて第１のサーバＣＳ１によって伝送される、３つのバージョンＶｊに属するコンテンツチャンクを具体化する。単一サイズのグレーの矩形は、ある伝送ビットレートに対応し、第２のトランスポートプロトコル（ここではＵＤＰ（例えばＲＴＰとの組み合わせ（すなわちＲＴＰ／ＵＤＰ）））を用いて第１のサーバＣＳ１によって伝送される、単一のバージョンＶｊに属するコンテンツチャンクを具体化する。
【００４８】
この第１の例に見られるように、利用可能な帯域幅の値が第１の閾値Ｓ１以下になる度に、コンテンツを取得する装置Ｄは、第１のサーバＣＳ１に、第２のトランスポートプロトコル（ここではＵＤＰ）を使用するように命令する。
【００４９】
この第１の方法は、ＵＤＰ上でＲＴＰを使用する場合に、パケットロス率（またはｐｌｒ）の現在値を考慮に入れるように意図されたオプションを含みうる。この場合、コンテンツを取得する装置Ｄは、パケットロス率（ここではｐｌｒ）の現在値を分析するように構成されうる。これゆえに、もしコンテンツを取得する装置Ｄが、第１の伝送ビットレートに対応するバージョンＶｊのチャンクの伝送のために第２のトランスポートプロトコル（ここではＵＤＰ）を選択した場合、コンテンツを取得する装置Ｄは、パケットロス率の現在値が厳密に第２の閾値Ｓ２よりも大きいことを検知したとき、これと同一ではあるが、別のバージョンＶｊ’（ｊ’≠ｊ）であるチャンクの伝送を要求することができる。この別のバージョンＶｊ’は、第１の伝送ビットレートよりも低い第２の伝送ビットレートに対応する。
【００５０】
ｐｌｒパラメータは、例えばスライディングウィンドウ中で受信されたＲＴＰパケットの数（例えば、受信されたリフレッシュ済みの各１００ＲＴＰパケット）と、最初に伝送されたＲＴＰパケットの数であって、（規則ＲＦＣ３５５０に準じ、その中ではシーケンス番号と呼ばれる）各ＲＴＰパケットヘッダで言及されるＲＴＰパケットの数とを比較することで計算されることが想起される。それゆえに、シーケンス番号ホップを検知することは、それらからパケットロスおよび失われたパケットの数を推論するのに十分である。
【００５１】
ｐｌｒパラメータの場合、第２の閾値Ｓ２は、例えば、４％または５％と等しくなるよう選択されうる。
【００５２】
第２の方法は、限定するものではないが、帯域幅の共有の公平性が優先されるアプリケーションに同様に適用される。例えば、これは、例えばテレビセットＴＳのような電子（通信）機器のアイテムの画面上で、例えばＳＴまたはホームゲートウェイのようなこの電子機器に結合されたコンテンツ受信機ＣＲによって復元された映像を閲覧したいユーザに適する。
このタイプの状況においては、映像は、大勢のユーザによって共有される通信ネットワークＮによって転送され、それゆえに、公平性の理由から、通信ネットワークＮの利用可能な帯域幅ＢＷが第１の閾値Ｓ１よりも小さくなる度に、第２のトランスポートプロトコル（ここではＵＤＰ）の使用のため、帯域幅は、同一ユーザによって計画的に使用されてはならないことが理解されるであろう。
【００５３】
この目的のために、コンテンツを取得する装置Ｄは、利用可能な帯域幅ＢＷの現在値だけでなく、好ましくはスライドするタイムスロット上の第１および第２のトランスポートプロトコルの使用の所定の配分にも応じて、所与の各時間において使用されるべきトランスポートプロトコルを選択するように構成されうる。
【００５４】
非限定的な一例として、コンテンツを取得する装置Ｄは、タイムスロット上の第１および第２のトランスポートプロトコルの７５％／２５％形式の所定の定義（第１のトランスポートプロトコルが７５％、第２のトランスポートプロトコルが２５％）を使用しうる。
【００５５】
図４は、図表内において、時間ｔに応じた通信ネットワークＮの利用可能な帯域幅ＢＷにおける変化を示す曲線の第２の例を図示する。この同図は、この第２の時間的変化の曲線において、コンテンツを取得する装置Ｄに伝送されるコンテンツのチャンクをも表す。異なるサイズの白い矩形は、それぞれ４つの異なる伝送ビットレートに対応して、第１トランスポートプロトコル（ここではＴＣＰ（例えばｈｔｔｐとの組み合わせ（すなわちｈｔｔｐ／ＴＣＰ）））を用いて第１のサーバＣＳ１によって伝送される、４つのバージョンＶｊに属するコンテンツチャンクを具体化する。単一サイズのグレーの矩形は、ある伝送ビットレートに対応し、第２のトランスポートプロトコル（ここではＵＤＰ（例えばＲＴＰとの組み合わせ（すなわちＲＴＰ／ＵＤＰ）））を用いて第１のサーバＣＳ１によって伝送される、単一のバージョンＶｊに属するコンテンツチャンクを具体化する。
【００５６】
この第２の例において見られるように、第２のトランスポートプロトコル（ここではＵＤＰ）は、利用可能な帯域幅ＢＷの値が第１の閾値Ｓ１以下になる度に、計画的に使用されない。実際、利用可能な帯域幅ＢＷの値が第１の閾値Ｓ１以下になるとき、現在のタイムスロットにおけるその使用が選択された配分によってそれに割り当てられたパーセンテージを超過しないという条件で、第２のトランスポートプロトコルは、コンテンツを取得する装置Ｄの要求によって使用される。ある場合において、利用可能な帯域幅ＢＷが第１の閾値Ｓ１以下である一方で、第２のトランスポートプロトコルが使用されないことは、確かに注目されうる。
【００５７】
ＵＤＰのように、第２のトランスポートプロトコルが、受信されなかったデータパケットについてのいかなる再送機構も備えないとき、コンテンツを取得する装置Ｄが、バージョンＶｊのチャンクの伝送のためにこの第２のトランスポートプロトコルを選択したときに、第１トランスポートプロトコルを用いてバージョンＶｊのこのチャンクから受信されなかったデータパケットについての再送機構をトリガするように構成されることは有益である。これを行うために、コンテンツを取得する装置Ｄは、例えば、そのコンテンツ受信機に、ＲＴＳＰ形式の再送要求であって、サーバがｈｔｔｐ／ＴＣＰセッションを開始することで応答する再送要求を、サーバへ伝送するよう命令することができる。
【００５８】
データパケットの各再送は、再送のためのコンテンツサーバＣＳ２またはＣＳ３から要求されうることに注意されたい。実際、これにより、第１のサーバＣＳ１がさらなるタスクを実行することが回避されるのみならず、とりわけ、それにより、第１のサーバＣＳ１によって使用され、データパケットが失われた（１または複数の）パスとは異なるパスの通信ネットワークＮ内における使用が可能になる。そのうえ、１つまたは複数のコンテンツサーバを、受信されなかったデータパケットの再送のみに割り当てることによって、再送の時間を減らすことができる。
【００５９】
本発明は、上述の単なる非限定的一例としてのみ提供された、コンテンツを取得および受信する装置の実施態様に限定されないが、以下の請求項の構成において当業者によって把握されうる全ての変形を含む。
（付記１）
ネットワークの利用可能な帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルを用いてコンテンツを取得する装置（Ｄ）であって、前記コンテンツは少なくとも１つのサーバ（ＣＳ）上において異なるバージョンで利用可能であり、前記コンテンツの異なるバージョンは、異なる伝送ビットレートに対応し、通信ネットワーク（Ｎ）を介して伝送されるように適合されたチャンクに細分化され、前記装置は、
コンテンツのバージョンの少なくとも１つの要求された次のチャンクを前記装置に伝送するために、前記少なくとも１つのサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択し、前記選択されたトランスポートプロトコルは、前記通信ネットワーク（Ｎ）の前記利用可能な帯域幅の現在値が厳密に第１の閾値よりも大きいときの第１のトランスポートプロトコル、または、前記利用可能な帯域幅の前記現在値が前記第１の閾値以下であるときの第２のトランスポートプロトコルを含み、
前記少なくとも１つのサーバに、前記選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも１つの要求される次のチャンクを伝送する要求を送信する、
ように構成された、前記装置。
（付記２）
コンテンツの要求されたバージョンに応じて、前記第１の閾値を選択するように構成された、付記１に記載の装置。
（付記３）
パケットロス率の現在値を分析し、第１の伝送ビットレートに対応するバージョンのチャンクの前記伝送について前記第２のトランスポートプロトコルを選択しているときに、前記パケットロス率の前記現在値が厳密に第２の閾値よりも大きいときには、これと同一のチャンクではあるが、前記第１の伝送ビットレートよりも低い第２の伝送ビットレートに対応する別のバージョンのチャンクの前記伝送を要求するように構成された、付記１または２に記載の装置。
（付記４）
取得するコンテンツの前記伝送の間の複数の所与の時間において、前記トランスポートプロトコルを選択し、前記少なくとも１つのサーバに要求を送信するように構成された、付記１から３のいずれか一項に記載の装置。
（付記５）
タイムスロット上の前記第１および第２のトランスポートプロトコルの前記使用の所定の配分に応じて、さらに使用されるべき前記トランスポートプロトコルを、それぞれの所与の時間において選択するように構成された、付記１から４のいずれか一項に記載の装置。
（付記６）
前記タイムスロットはスライドする、付記５に記載の装置。
（付記７）
前記タイムスロット上の前記第１および第２のトランスポートプロトコルの７５％／２５％の所定の配分を使用するように構成された、付記５または６に記載の装置。
（付記８）
バージョンのチャンクの前記伝送について前記第２のトランスポートプロトコルを選択したとき、前記第１のトランスポートプロトコルを用いてこのバージョンのチャンクから受信されなかったデータパケットの再送の機構をトリガするように構成された、付記１から７のいずれか一項に記載の装置。
（付記９）
前記再送のためのコンテンツサーバ（ＣＳ２）からデータパケットの各再送を要求するように構成された、付記８に記載の装置。
（付記１０）
前記第１のトランスポートプロトコルはＴＣＰであり、前記第２のトランスポートプロトコルはＵＤＰである、付記１から９のいずれか一項に記載の装置。
（付記１１）
所与の時間における前記第２のトランスポートプロトコルの前記選択の場合には、前記所与の時間において前記帯域幅の前記現在値に最も近い値を有する前記伝送ビットレートに対応する前記コンテンツのバージョンを選択するように構成された、付記１から１０のいずれか一項に記載の装置。
（付記１２）
取得しようとするコンテンツのバージョンに対応付けて記憶され、およびこのコンテンツを取得するためのトランスポートプロトコルの第１の選択を行うために、それらの各伝送ビットレートを表す、記述ファイルを復元するように構成された、付記１から１１のいずれか一項に記載の装置。
（付記１３）
ストリーミングモードまたはダウンロードモードにおいて、コンテンツの前記伝送を達成するように構成された、付記１から１２のいずれか一項に記載の装置。
（付記１４）
前記第１のトランスポートプロトコルを使用してコンテンツのバージョンの少なくとも１つの次のチャンクを伝送する第１のコンテンツサーバ（ＣＳ１）に要求を送信し、前記第２のトランスポートプロトコルを使用してコンテンツの次のバージョンの少なくとも１つのチャンクを伝送する第２のコンテンツサーバ（ＣＳ２）に第２の要求を送信するように構成された、付記１から１３のいずれか一項に記載の装置。
（付記１５）
ネットワークの利用可能な帯域幅について異なる要件を有する少なくとも２つのトランスポートプロトコルを用いてコンテンツを取得する方法であって、前記コンテンツは少なくとも１つのサーバ（ＣＳ）上において異なるバージョンで利用可能であり、前記コンテンツの異なるバージョンは、異なる伝送ビットレートに対応し、通信ネットワーク（Ｎ）を介して伝送されるように適合されたチャンクに細分化され、前記方法は、コンテンツ取得装置（Ｄ）によって実施される、
コンテンツのバージョンの少なくとも１つの要求された次のチャンクを前記コンテンツ取得装置に伝送するために、前記少なくとも１つのサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択するステップであって、前記選択されたトランスポートプロトコルは、前記通信ネットワーク（Ｎ）の前記利用可能な帯域幅の現在値が厳密に第１の閾値よりも大きいときの第１のトランスポートプロトコル、または、前記利用可能な帯域幅の前記現在値が前記第１の閾値以下であるときの第２のトランスポートプロトコルを含む、ステップと、
前記少なくとも１つのサーバに、前記選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも１つの要求される次のチャンクを伝送する要求を送信するステップと、
を含む、前記方法。
【図１】
0006513402.tif 000002
【図２】
0006513402.tif 000003
【図３】
0006513402.tif 000004
【図４】
0006513402.tif 000005