図面 (/)

技術 利用可能な帯域幅に応じてトランスポートプロトコルを選択することによってコンテンツを取得する装置

出願人 トムソンライセンシング
発明者 フィリップギルバートンステファングワッシュイヴォンルガレ
出願日 2012年11月29日 (6年7ヶ月経過) 出願番号 2014-543891
公開日 2015年3月12日 (4年4ヶ月経過) 公開番号 2015-507857
状態 特許登録済
技術分野 双方向TV,動画像配信等 計算機間の情報転送 広域データ交換 通信制御
主要キーワード ウィドウ ストリーミングモード 電子タブレット 単一サイズ 再送機構 無線ローカルネットワーク コンピュータ生成画像 コンテンツ取得装置
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2015年3月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (5)

課題・解決手段

装置(D)は、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルを用いて、コンテンツを取得するように意図される。そのようなコンテンツは少なくとも1つのコンテンツサーバ(CS)上にて異なるバージョンで利用可能であり、バージョンは、異なる伝送バイナリビットレートに対応し、通信ネットワーク(N)を介して伝送されるように適合されたチャンク細分化される。この装置(D)は、コンテンツのバージョンの少なくとも1つの要求された次のチャンクを伝送するためにサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択するように構成され、選択されたトランスポートプロトコルは、通信ネットワーク(N)の利用可能な帯域幅現在値が厳密に第1の閾値よりも大きいときの第1のトランスポートプロトコル、または、この帯域幅の現在値が第1の閾値以下であるときの第2のトランスポートプロトコルを含む。装置(D)は、選択されたトランスポートプロトコルを用いてコンテンツのバージョンの、少なくとも1つの要求される次のチャンクを伝送する要求を、コンテンツサーバ(CS)に送信するように、さらに構成される。

概要

背景

業者は、データ伝送ビットレートは、通信ネットワーク内で、時々は著しくおよび/または持続的に変動しうるパラメータであり、コンテンツ受信機のレベルにおいて、受信されたコンテンツの画像および/または音声復元された品質に変動を引き起こす、ということを知っている。実際に、もし所与の時間において通信ネットワークにより提供された帯域幅がデータ伝送ビットレートと瞬間的に合わなければ、このコンテンツのデータの一部分は、要求しているコンテンツ受信機により受信され得ないであろうし、よって、コンテンツ受信機は、良くても、瞬間的に品質の落ちた画像および/または音声を復元させることしかできず、最悪の場合、何も復元させることができない。

前述した変動の影響を抑えるために、異なる伝送ビットレートに対応する同一コンテンツのいくつかの異なるバージョンから生成することが提案されている。これゆえに、通信ネットワークに接続されたコンテンツ受信機が通信ネットワークを介してコンテンツを受信したいとき、コンテンツ受信機は、それぞれの選択された時間において、この選択された時間においてこの通信ネットワークによって与えられた条件に最適なこのコンテンツのバージョンを必要とし、これはフリーズ画像を回避する。残念ながら、かなりの変動がある環境においては、この解決手法は、低い伝送ビットレートに最もよく対応するバージョンにおいてチャンク伝送を増加させる傾向があり、これはユーザが体験する全般的な品質を低下させる。状況を改善するために、伝送ビットレートを選択することを担うアルゴリズムに、より厳しい制御を課すことは可能である。しかし、これは、コンテンツ受信機がまさにそのトランスポートプロトコルの原則によって1つまたは複数の同時のアプリケーション(例えば、ダウンロードまたはブラウジング)と通信ネットワークの帯域幅を共有するよう強いられるとき、状況を改善させることはない。

概要

装置(D)は、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルを用いて、コンテンツを取得するように意される。そのようなコンテンツは少なくとも1つのコンテンツサーバ(CS)上にて異なるバージョンで利用可能であり、バージョンは、異なる伝送バイナリビットレートに対応し、通信ネットワーク(N)を介して伝送されるように適合されたチャンクに細分化される。この装置(D)は、コンテンツのバージョンの少なくとも1つの要求された次のチャンクを伝送するためにサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択するように構成され、選択されたトランスポートプロトコルは、通信ネットワーク(N)の利用可能な帯域幅の現在値が厳密に第1の閾値よりも大きいときの第1のトランスポートプロトコル、または、この帯域幅の現在値が第1の閾値以下であるときの第2のトランスポートプロトコルを含む。装置(D)は、選択されたトランスポートプロトコルを用いてコンテンツのバージョンの、少なくとも1つの要求される次のチャンクを伝送する要求を、コンテンツサーバ(CS)に送信するように、さらに構成される。

目的

本発明の目的は、特に、通信ネットワークNに結合された少なくとも1つのコンテンツ受信機CRに関連付けられるよう意図されたコンテンツを取得する装置Dを提案することである

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ネットワーク利用可能な帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルを用いてコンテンツを取得する装置(D)であって、前記コンテンツは少なくとも1つのサーバ(CS)上において異なるバージョンで利用可能であり、前記コンテンツの異なるバージョンは、異なる伝送ビットレートに対応し、通信ネットワーク(N)を介して伝送されるように適合されたチャンク細分化され、前記装置は、コンテンツのバージョンの少なくとも1つの要求された次のチャンクを前記装置に伝送するために、前記少なくとも1つのサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択し、前記選択されたトランスポートプロトコルは、前記通信ネットワーク(N)の前記利用可能な帯域幅の現在値が厳密に第1の閾値よりも大きいときの第1のトランスポートプロトコル、または、前記利用可能な帯域幅の前記現在値が前記第1の閾値以下であるときの第2のトランスポートプロトコルを含み、前記少なくとも1つのサーバに、前記選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも1つの要求される次のチャンクを伝送する要求を送信する、ように構成された、前記装置。

請求項2

コンテンツの要求されたバージョンに応じて、前記第1の閾値を選択するように構成された、請求項1に記載の装置。

請求項3

パケットロス率の現在値を分析し、第1の伝送ビットレートに対応するバージョンのチャンクの前記伝送について前記第2のトランスポートプロトコルを選択しているときに、前記パケットロス率の前記現在値が厳密に第2の閾値よりも大きいときには、これと同一のチャンクではあるが、前記第1の伝送ビットレートよりも低い第2の伝送ビットレートに対応する別のバージョンのチャンクの前記伝送を要求するように構成された、請求項1または2に記載の装置。

請求項4

取得するコンテンツの前記伝送の間の複数の所与の時間において、前記トランスポートプロトコルを選択し、前記少なくとも1つのサーバに要求を送信するように構成された、請求項1から3のいずれか一項に記載の装置。

請求項5

タイムスロット上の前記第1および第2のトランスポートプロトコルの前記使用の所定の配分に応じて、さらに使用されるべき前記トランスポートプロトコルを、それぞれの所与の時間において選択するように構成された、請求項1から4のいずれか一項に記載の装置。

請求項6

前記タイムスロットはスライドする、請求項5に記載の装置。

請求項7

前記タイムスロット上の前記第1および第2のトランスポートプロトコルの75%/25%の所定の配分を使用するように構成された、請求項5または6に記載の装置。

請求項8

バージョンのチャンクの前記伝送について前記第2のトランスポートプロトコルを選択したとき、前記第1のトランスポートプロトコルを用いてこのバージョンのチャンクから受信されなかったデータパケット再送機構トリガするように構成された、請求項1から7のいずれか一項に記載の装置。

請求項9

前記再送のためのコンテンツサーバ(CS2)からデータパケットの各再送を要求するように構成された、請求項8に記載の装置。

請求項10

前記第1のトランスポートプロトコルはTCPであり、前記第2のトランスポートプロトコルはUDPである、請求項1から9のいずれか一項に記載の装置。

請求項11

所与の時間における前記第2のトランスポートプロトコルの前記選択の場合には、前記所与の時間において前記帯域幅の前記現在値に最も近い値を有する前記伝送ビットレートに対応する前記コンテンツのバージョンを選択するように構成された、請求項1から10のいずれか一項に記載の装置。

請求項12

取得しようとするコンテンツのバージョンに対応付けて記憶され、およびこのコンテンツを取得するためのトランスポートプロトコルの第1の選択を行うために、それらの各伝送ビットレートを表す、記述ファイル復元するように構成された、請求項1から11のいずれか一項に記載の装置。

請求項13

ストリーミングモードまたはダウンロードモードにおいて、コンテンツの前記伝送を達成するように構成された、請求項1から12のいずれか一項に記載の装置。

請求項14

前記第1のトランスポートプロトコルを使用してコンテンツのバージョンの少なくとも1つの次のチャンクを伝送する第1のコンテンツサーバ(CS1)に要求を送信し、前記第2のトランスポートプロトコルを使用してコンテンツの次のバージョンの少なくとも1つのチャンクを伝送する第2のコンテンツサーバ(CS2)に第2の要求を送信するように構成された、請求項1から13のいずれか一項に記載の装置。

請求項15

ネットワークの利用可能な帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルを用いてコンテンツを取得する方法であって、前記コンテンツは少なくとも1つのサーバ(CS)上において異なるバージョンで利用可能であり、前記コンテンツの異なるバージョンは、異なる伝送ビットレートに対応し、通信ネットワーク(N)を介して伝送されるように適合されたチャンクに細分化され、前記方法は、コンテンツ取得装置(D)によって実施される、コンテンツのバージョンの少なくとも1つの要求された次のチャンクを前記コンテンツ取得装置に伝送するために、前記少なくとも1つのサーバによって所与の時間において使用されるべきトランスポートプロトコルを選択するステップであって、前記選択されたトランスポートプロトコルは、前記通信ネットワーク(N)の前記利用可能な帯域幅の現在値が厳密に第1の閾値よりも大きいときの第1のトランスポートプロトコル、または、前記利用可能な帯域幅の前記現在値が前記第1の閾値以下であるときの第2のトランスポートプロトコルを含む、ステップと、前記少なくとも1つのサーバに、前記選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも1つの要求される次のチャンクを伝送する要求を送信するステップと、を含む、前記方法。

技術分野

0001

本発明は、ストリーミングモードにあるかフルファイルダウンロードモードにあるかにかかわらない、コンテンツ伝送に関する。

0002

ストリーミングは、通信ネットワーク有線または無線)を介して、コンテンツのチャンク(または部分 −微小なファイル)を、それらがストリーミング中でリアルタイムに使用されるために、少なくとも1つのコンテンツ受信機に連続的に伝送することを含むことに注意する。この第1の伝送の形式は、異なるストリーミングプロトコル、例えば、UDP上のRTPもしくはMPEG−TS、HTTPストリーミング、またはより最近のHTTPアダプティブストリーミング(HTTP adaptive streaming)を用いて行われうる。フルファイルダウンロードは、それを再生することを可能とするために、ファイルの全てまたは一部を受信することを必要とする。この第2の伝送形式は、通常、TCPプロトコル上のhttpを用いて行われる。

0003

ここで、“コンテンツ”は、テレビ番組映像および音声)、ゲームまたはドキュメントを定義し、要求に応じてファイル(マルチメディア、ゲーム、ドキュメント)の形式にておそらく配信されるデータのセットと理解される。

背景技術

0004

業者は、データ伝送ビットレートは、通信ネットワーク内で、時々は著しくおよび/または持続的に変動しうるパラメータであり、コンテンツ受信機のレベルにおいて、受信されたコンテンツの画像および/または音声の復元された品質に変動を引き起こす、ということを知っている。実際に、もし所与の時間において通信ネットワークにより提供された帯域幅がデータ伝送ビットレートと瞬間的に合わなければ、このコンテンツのデータの一部分は、要求しているコンテンツ受信機により受信され得ないであろうし、よって、コンテンツ受信機は、良くても、瞬間的に品質の落ちた画像および/または音声を復元させることしかできず、最悪の場合、何も復元させることができない。

0005

前述した変動の影響を抑えるために、異なる伝送ビットレートに対応する同一コンテンツのいくつかの異なるバージョンから生成することが提案されている。これゆえに、通信ネットワークに接続されたコンテンツ受信機が通信ネットワークを介してコンテンツを受信したいとき、コンテンツ受信機は、それぞれの選択された時間において、この選択された時間においてこの通信ネットワークによって与えられた条件に最適なこのコンテンツのバージョンを必要とし、これはフリーズ画像を回避する。残念ながら、かなりの変動がある環境においては、この解決手法は、低い伝送ビットレートに最もよく対応するバージョンにおいてチャンクの伝送を増加させる傾向があり、これはユーザが体験する全般的な品質を低下させる。状況を改善するために、伝送ビットレートを選択することを担うアルゴリズムに、より厳しい制御を課すことは可能である。しかし、これは、コンテンツ受信機がまさにそのトランスポートプロトコルの原則によって1つまたは複数の同時のアプリケーション(例えば、ダウンロードまたはブラウジング)と通信ネットワークの帯域幅を共有するよう強いられるとき、状況を改善させることはない。

0006

よって、本発明は状況を改善する目的を有し、より具体的には、通信ネットワーク内で伝送状況が変動するときのユーザの体験を改善する目的を有する。

0007

この目的のために、本発明は、少なくとも1つのサーバ(CS)上の異なるバージョンにおいて利用可能なコンテンツを取得するように意図された装置であって、異なるバージョンは、異なる伝送バイナリビットレートに対応して、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルを用いて通信ネットワークを介して伝送されるよう適合されたチャンクに細分化される、装置を提案する。

0008

この装置は、トランスポートプロトコルを選択するように構成されるということによって特徴付けられ、トランスポートプロトコルは、その取得装置に、コンテンツのバージョンの少なくとも1つの要求された次のチャンクを伝送するために、少なくとも1つのサーバによって所与の時間において使用されるべきである。トランスポートプロトコルの選択は、通信ネットワークの利用可能な帯域幅の現在値が厳密に第1の閾値よりも大きいときの第1のトランスポートプロトコル、または帯域幅のこの現在値が第1の閾値以下であるときの(利用可能なネットワーク帯域幅について第1のトランスポートプロトコルの要件よりも少ない要件を有する)第2のトランスポートプロトコルを含む。この装置はさらに、その選択されたトランスポートプロトコルを用いて、コンテンツのバージョンの少なくとも1つの要求される次のチャンクを伝送する要求を、少なくとも1つのサーバに送信するように構成されている。

0009

本発明に係る装置は、別々に、または組み合わせて獲得されうる他の特徴を備えることができる。特に:
−装置は、コンテンツの定義の要求されるレベルにあるコンテンツの要求されるバージョンに係る第1の閾値を選択するように構成されうる。
−装置は、パケットロス率の現在値を分析するように構成されうる。この場合、装置が第1の伝送ビットレートに対応するバージョンのチャンクの伝送のために第2のトランスポートプロトコルを選択したとき、装置は、これと同一のチャンクではあるが、別のバージョンのチャンクの伝送を要求することができ、この別のバージョンは、パケットロス率の現在値が厳密に第2の閾値よりも大きいときに、第1の伝送ビットレートよりも低い第2の伝送ビットレートに対応する。
−装置は、トランスポートプロトコルを選択し、取得するコンテンツの伝送の間の、複数の所与の時間、よって、コンテンツ全体の伝送の間に適用できる所与の時間において、少なくとも1つのサーバに要求を送信するように構成されうる。
−装置は、タイムスロット上の第1および第2のトランスポートプロトコルの使用の所定の配分に応じて、さらに使用されるべきトランスポートプロトコルを、各所与の時間において選択するように構成されうる。
・タイムスロットはスライドしうる。
・装置は、タイムスロット上において第1および第2のトランスポートプロトコルの75%/25%の所定の配分を使用するように構成されうる。
−装置が、バージョンのチャンクの伝送のために第2のトランスポートプロトコルを選択したとき、装置は、第1のトランスポートプロトコルを用いて、このバージョンのチャンクから受信されなかったデータパケット再送機構トリガするように構成されうる。
・装置は、再送のためのコンテンツサーバからデータパケットの各再送を要求するように構成されうる。
−第1トランスポートプロトコルはTCPであってもよく、第2のトランスポートプロトコルはUDPであってもよい。
−所与の時間において、第2のトランスポートプロトコルの選択に関し、装置は、この所与の時間において帯域幅の現在値に最も近い値を有する伝送ビットレートに対応するコンテンツのバージョンを選択するように構成されうる。
−装置は、記述ファイルを復元するように構成されてもよく、記述ファイルは、装置が取得を必要としておりそれらの各伝送ビットレートを表すコンテンツのバージョンに対応付けて記憶され、このコンテンツを取得するためにトランスポートプロトコルの第1の選択を行うようにする。
−装置は、ストリーミングモードまたはフルファイルダウンロードモードにてコンテンツの伝送を達成するように構成されうる。

0010

本発明はさらに、上述のいずれかのタイプのコンテンツを取得する装置を備えるコンテンツ受信機を提案する。

0012

本発明はさらに、コンテンツ取得装置によって実施されるステップ実装するコンテンツを取得する方法を提案する。コンテンツ取得装置について上述された特徴は、このコンテンツを取得する方法において、あらゆる組み合わせで使用されうる。

図面の簡単な説明

0013

本発明の他の特徴および利点は、これ以降の詳細な説明の検討、および添付の図面にみられるであろう。
本発明の実施形態に係る3つのコンテンツサーバおよびコンテンツを取得する装置が備えられたコンテンツ受信機が接続された通信ネットワークを、図表にて機能的に示す。
4つの異なる伝送ビットレートにそれぞれ対応する同一コンテンツの4つの異なるバージョンを図表にて示す。
通信ネットワークの帯域幅(BW)の時間的変化(t)の第1の例、および、時間的変化のこの第1の例において、第1の方法にて構成された本発明の実施態様に係るコンテンツを取得する装置に伝送されるコンテンツのチャンクの第1の例を、図表にて機能的に示す。
通信ネットワークの帯域幅(BW)の時間的変化(t)の第2の例、および、時間的変化のこの第2の例において、第2の方法にて構成された本発明の実施態様に係るコンテンツを取得する装置に伝送されるコンテンツのチャンクの第2の例を、図表にて機能的に示す。

0014

添付図面は、本発明を完成するのに役立つだけでなく、必要に応じて、その定義に寄与しうる。

実施例

0015

本発明の目的は、特に、通信ネットワークNに結合された少なくとも1つのコンテンツ受信機CRに関連付けられるよう意図されたコンテンツを取得する装置Dを提案することである。

0016

以下においては、非限定的な例として、コンテンツ受信機CRはセットップボックス(またSTB)であると考えられている。しかし、本発明は、このタイプのコンテンツ受信機に限定されない。実際、本発明は、コンテンツを受信するために少なくとも1つの通信ネットワークに接続されることができ、コンテンツを回復することが可能な、あらゆるタイプのコンテンツ受信機に関する。従って、本発明は、例えば、デコーダ、レジデンシャルゲートウェイ、ホームゲートウェイ、据置型コンピュータもしくはラップトップ、携帯電話(スマートフォンタイプも可)、パーソナルデジタルアシスタント(もしくはPDA)、電子タブレット、またはゲームコンソールにも関係する。

0017

さらに、以下において、非限定的な一例として、コンテンツはマルチメディアコンテンツである。しかし、本発明は、このタイプのコンテンツに限定されない。実際、本発明は、データファイルまたはファイルチャンク、ならびに、特にテレビ番組、ゲーム、映画番組音楽、およびコンピュータ生成画像(またはCGI)の形式で利用可能な、あらゆるタイプのコンテンツに関する。

0018

図1は、コンテンツを記憶するのに適する3つのコンテンツサーバCS1からCS3が接続された通信ネットワークN、および(本発明に係るコンテンツを取得する装置Dの要求により)サーバCS1からCS3のうちの1つによって伝送されるコンテンツをデコードするよう意図されたコンテンツ受信機CRを図示する。

0019

例えば、非限定的に示されるように、セットトップボックスCRは、それがデコードする、通信ネットワークNを介したサーバCS1、CS2、またはCS3からのコンテンツを回復する役割を果たす少なくとも1つのテレビセットに結合される。

0020

以下においては、非限定的な一例として、通信ネットワークNは、xDSLアクセスネットワークによる使用のために接続されるインターネットネットワークによって構成されるネットワークであるとみなす。しかし、本発明は、この種の通信ネットワークに限定されない。実際、通信ネットワークNは、有線または無線でありうる。よって、通信ネットワークNは、ケーブルもしくはファイバー形式の有線ネットワーク、移動もしくはセルラー、もしくはWLAN(Wireless Local Area Network−あるいは802.11(もしくはWiFi)もしくはWiMAX形式も可)、またはBluetooth(登録商標)形式の非常に短い範囲の無線ローカルネットワークでさえも、ありうる。

0021

通信Rは、利用可能なネットワーク帯域幅について異なる要件を有する少なくとも2つのトランスポートプロトコルをサポートすることが可能であるべきことに注意することは重要である。非限定的な一例として、通信ネットワークNは、TCP(Transmission Control Protocol)形式の第1のトランスポートプロトコルおよびUDP(User Datagram Protocol)形式の第2のトランスポートプロトコルをサポートする。しかし、トランスポートプロトコルの他の組み合わせも想定されうる。

0022

第1の(コンテンツ)サーバCS1は、例えば、第1の記憶手段SM1に異なるコンテンツバージョンVjを記憶する役割を果たす。これらの第1の記憶手段SM1は、ソフトウェアを含む、当業者に既知の任意の形態で表現される。従って、第1の記憶手段SM1は、メモリであってもよい。

0023

“コンテンツの異なるバージョン”は、異なる伝送ビットレートに対応するバージョンと理解される。図2は、4つの異なる伝送ビットレートにそれぞれ対応する同一コンテンツの4つの異なるバージョンV1からV4(j=1〜4)を図示する。例として、第1のバージョンV1は1Mbpsメガビット/秒)、第2のバージョンV2は2Mbps、第3のバージョンV3は4Mbps、第4のバージョンV4は6Mbpsに対応する。

0024

コンテンツの各バージョンVjは、決定された期間の様々なチャンク(または部分 −微小なファイル)によって構成される。図2の例において、バージョンVjの各チャンクは矩形によって表されており、矩形の高さは対応する伝送ビットレートを表す。

0025

同一コンテンツのバージョンの数は、“2”に少なくとも等しい任意の値と等しくなりうる。

0026

例えば、同一コンテンツのバージョンVjは、例えばMVC(Multiview Video Coding)、AVC(Advanced Video Coding)、SVC(Scalable Video Coding)、MPEG2、H264、および、転送(ストリーミング)または記憶(ダウンローディング)のためのフォーマットにてカプセル化を可能とするより一般的なあらゆる映像圧縮形式(音声データ向けを含む)のような、映像圧縮技術を用いて符号化することで生成されうることに注意されたい。

0027

異なる伝送ビットレートに対応する各コンテンツの異なるバージョンVjは、通信ネットワークN内で変動する伝送状況に正しく一致されることが理解されるであろう。

0028

図2に示されるように、同一コンテンツのバージョンVjは、優先的には、時間的位置が、あるバージョンから他のバージョンまで同一である参照フレームRFを備えることに注意されたい。参照フレームRFはストリーミング中で伝送されるコンテンツのチャンクにランダムアクセスすることができるものであることが想起される。示される例において、各参照フレームRFは、コンテンツのバージョンVjのチャンクの開始に位置される。これにより、コンテンツ受信機CRに設けられたデコーダは、要求に応じて、(参照フレームRFの伝送時間である)特定の時間において目に見えるいかなるアーチファクトも生じさせずに(典型的には、各映像チャンクは開始してから、おそらくは、あるチャンクからユーザの目に見えない他のチャンクへ移行するための、キー画像とともに終了する)、あるバージョンVjから別のバージョンVj’に移動することができる。

0029

各コンテンツのバージョンVjは、優先的には、それらの各ビットレートを記述する記述ファイルに対応して記憶されることにさらに注意されたい。各記述ファイルは、例えば、SDP(Session Description Protocol)形式である。この記述ファイルについては、さらに後述する。第2のコンテンツサーバCS2および第3のコンテンツサーバ(CS3)は、ここでは、コンテンツ受信機CRによって受信されていないコンテンツのデータパケットの可能な再送を意図されたものである。これらの利点は、さらに先で理解されるであろう。

0030

第1のサーバCS1に記憶されるバージョンVjは、要求により、少なくとも1つのコンテンツ受信機CRに伝送されることが意図される。そのため、各コンテンツ受信機CRは、本発明に係るコンテンツを取得する装置Dに関連付けられうる。

0031

ここで、“関連付けられる”は、非限定的に示されるように、コンテンツ受信機CRに直接に結合されること、ならびにコンテンツ受信機CRの必須部分であることの両方であると理解される。従って、コンテンツを取得する装置Dは、ソフトウェア(もしくはコンピュータ)モジュールの形で、または電子回路およびソフトウェアモジュールの組み合わせの形式で実現されうる。

0032

このコンテンツを取得する装置Dは、コンテンツのバージョンVjの少なくとも1つの要求される次のチャンクを伝送するために所与の時間において使用されるべきトランスポートプロトコルとして、通信ネットワークNの利用可能な帯域幅BWの現在値が厳密に第1の閾値S1よりも大きいときの第1のトランスポートプロトコル、または、帯域幅BWのこの現在値が第1の閾値S1以下であるときの第2のトランスポートプロトコルを選択するように構成される。

0033

通信ネットワークNにおいて利用可能な帯域幅BWは、この通信ネットワークNが技術的問題またはアクセスネットワークの輻輳を経験するときに、第1の閾値S1以下となりうることに注意されたい。

0034

第1のトランスポートプロトコルは、第2のトランスポートプロトコルよりも多くの利用可能なネットワーク帯域幅BWを必要とするということに注意することも重要である。これは、特に、UDPプロトコルよりもより多くの利用可能なネットワーク帯域幅を著しく必要とするTCPプロトコルについての場合である。これは、主に、TCPが双方向性のものであるという事実に起因し、受信確認(acknowledgements)の伝送を必要とし、ウィンドウサイズ調整(またはウィンドウィング)に制約を課し、受信されなかったデータパケットの再送機構を提供する。これに対し、UDPは、一方向性のものであり(よって、いかなる受信確認も無く)、ウィンドウィングに制限はなく、受信されなかったデータパケットの再送機構を有さない。

0035

ウィドウィングはTCPセッションの間に動的に取り決められるウィンドウのサイズを明示すること、およびウィンドウィングはストリーム制御機構の形式を構成することが想起される。さらに具体的には、データが伝送されるとき、伝送元受信者から受信確認を受信しなければならず、受信者は伝送元に、受信者が希望するウィンドウのサイズおよび受信者が受信する準備のあるパケットの数の代表値シグナリングしなければならない。

0036

単なる例示として、1Mbpsでのコンテンツの伝達について、30msに等しいラウンドトリップタイムと0.02(または2%)に等しいパケットロス率が存在すると、TCPは、同じ量のデータを転送するためにはUDPよりも30%多くの帯域幅を必要とする。本例は、UDP上のRTPトラフィックと比較したTCP上のhttpトラフィック(受信されなかったデータパケットの再送機構を含む)に関するものであることに注意されたい。

0037

本発明によれば、第1のプロトコル(ここではTCP)の代わりにコンテンツのチャンクを復元させるために第2のプロトコル(ここではUDP)が一時的に使用される度に、このコンテンツを要求したユーザは、(利用可能な帯域幅BWの現在値に最も近い値を有する)高伝送ビットレートに対応するバージョンVjを取得する、より大きな可能性を有する。従って、UDPが選択される度に、例えば、通信ネットワークNにおける以下の輻輳、ユーザのコンテンツ受信機CRによって回復された品質は、TCPを使用する場合よりも良い可能性がより高い。例えば、そして輻輳の場合は常に、本発明は、http/TCPプロトコルが行うのと同様により低いビットレートのチャンクではあるが、RTP/UDPにおけるビットレートよりは高いビットレートのチャンクを要求することができるであろう。

0038

コンテンツを取得する装置Dは、所与の時間において第2のトランスポートプロトコルを選択したとき、この所与の時間において利用可能な帯域幅BWの現在値に最も近い値を有する伝送ビットレートに対応するコンテンツのバージョンVjを選択するようにも恐らくは構成されうることに、さらに注意されたい。

0039

要求されるコンテンツの異なるバージョンVjを知るために、コンテンツを取得する装置Dは、好ましくは、そのコンテンツ受信機CRに、関係する第1のサーバCS1からの、これらのバージョンVjに対応付けてコンテンツ受信機CRが記憶する(そして、それらの各伝送ビットレートを記述する)記述ファイルを復元するように命令するよう構成されることに注意されたい。この場合、コンテンツ受信機CRが、関連する第1のサーバCS1から、要求された記述ファイルを復元すると、コンテンツを取得する装置Dは、通信ネットワークNの利用可能な帯域幅BWに応じて、選択された(または選ばれた)要求されるコンテンツのバージョンVjを絶え間なく連続的方法で制御することにより、コンテンツを取得するためのセッションを開始しうる(ストリーミングモードにおいても、フルファイルダウンロードモードにおいても)。そして、コンテンツを取得する装置Dは、関係する第1のサーバCS1から各バージョンVjを請求するために、そのコンテンツ受信機CRに、コンテンツを取得する装置Dが選択する(および記述ファイルで言及された)各バージョンVjの指定を提供する。

0040

以下においては、非限定的な一例として、コンテンツはストリーミングモードで伝送されることとする。

0041

この場合、コンテンツを取得する装置Dは、第2のプロトコル(ここではUDP)を選択したとき、そのコンテンツ受信機CRに第1のサーバCS1とのRTSP(Real−Time Streaming Protocol)セッションを開始するように命令しうる。RTSPは、RTPプロトコル(Real−Time Protocol)の補足である、RFC2326規則によって規定されているプロトコルであり、特に、ストリーミングモードでのマルチメディアコンテンツ転送セッションを設定して制御することを目的としたプロトコルであることが想起される。この場合において、コンテンツ受信機CRは、要求されたコンテンツの記述ファイルを取得するために、“RTSP describe URI”メッセージを第1のサーバCS1に送信することができる。次いで、第1のサーバCS1は、“RTSP describe response”メッセージで応答して要求された記述ファイルを伝送する。次いで、コンテンツ受信機CRは、RTP/UDPストリーミングセッションを準備するために、“RTSP setup”メッセージを第1のサーバCS1に送信することができる。次いで、第1のサーバCS1は、“RTSP setup response”メッセージで応答して、このセッションが準備されたことをシグナリングする。次いで、コンテンツ受信機CRは、“RTSP play”メッセージを第1のサーバCS1に送って、第1のサーバCS1に、先に準備されたセッションを開始するように依頼することができる。次いで、第1のサーバCS1は、“RTSP play response”メッセージで応答して、第1のサーバCS1がRTP/UDPストリーミングセッションを開始することをシグナリングする。そして、要求されたコンテンツのコンテナを、例えば、MP4フォーマットまたはMPEG−TSフォーマットで、UDP上のストリーミングモードで送信されるパケットにカプセル化する。

0042

コンテンツがフルファイルダウンロードモードで伝送されるとき、(RFC3926規則によって規定されている)FLUTEプロトコルがRTPプロトコルに代えて使用されうることに注意されたい。

0043

コンテンツを取得する装置Dがコンテンツのチャンクを復元すると決定する度に、コンテンツを取得する装置Dは、選択したバージョンVjのこのチャンクを表す識別子、およびこのチャンクの時間と等しく、このチャンクの開始時間を指定するタイムスロットを特定しなければならない。これは、RTSP形式のメッセージを交換することによって行われうる。

0044

コンテンツを取得する装置Dは、要求したいコンテンツの解像度のレベルに応じて、第1の閾値S1を選択するために、構成されうることにも注意されたい。コンテンツの解像度が低いほど、第1の閾値S1は低くなりうることを理解されたい。これゆえに、第1の閾値S1は、高い解像度を含む、標準の解像度から非常に高い解像度まで増加して選択されうる。

0045

コンテンツを取得する装置Dは、少なくとも異なる2つの方法で動作しうる。

0046

第1の方法は上述されている。制限するものではないが、例えば家庭などの、帯域幅の共有公平性が優先ではないローカルのアプリケーションにも同様に適合される。例えば、(CR STBまたはホームゲートウェイに接続された)テレビセットTSの画面上で、例えばWiFi/PLCストリーミングモードでこのCR STBまたはこのホームゲートウェイと通信可能な据置型通信機器デスクトップコンピュータなど)または移動型通信機器(例えば、移動電話またはビデオプレイまたはラップトップコンピュータなど)のアイテム上のメモリに記憶されている映像を閲覧したいユーザに適する。

0047

図3は、図表内において、時間tに応じた通信ネットワークNの利用可能な帯域幅BWにおける変化を示す曲線の第1の例を図示する。同図は、この第1の時間的変化曲線において、コンテンツを取得する装置Dに伝送されるコンテンツのチャンクをも表す。異なるサイズの白い矩形は、それぞれ3つの異なる伝送ビットレートに対応して、第1トランスポートプロトコル(ここではTCP(例えばhttpとの組み合わせ(すなわちhttp/TCP)))を用いて第1のサーバCS1によって伝送される、3つのバージョンVjに属するコンテンツチャンクを具体化する。単一サイズグレーの矩形は、ある伝送ビットレートに対応し、第2のトランスポートプロトコル(ここではUDP(例えばRTPとの組み合わせ(すなわちRTP/UDP)))を用いて第1のサーバCS1によって伝送される、単一のバージョンVjに属するコンテンツチャンクを具体化する。

0048

この第1の例に見られるように、利用可能な帯域幅の値が第1の閾値S1以下になる度に、コンテンツを取得する装置Dは、第1のサーバCS1に、第2のトランスポートプロトコル(ここではUDP)を使用するように命令する。

0049

この第1の方法は、UDP上でRTPを使用する場合に、パケットロス率(またはplr)の現在値を考慮に入れるように意図されたオプションを含みうる。この場合、コンテンツを取得する装置Dは、パケットロス率(ここではplr)の現在値を分析するように構成されうる。これゆえに、もしコンテンツを取得する装置Dが、第1の伝送ビットレートに対応するバージョンVjのチャンクの伝送のために第2のトランスポートプロトコル(ここではUDP)を選択した場合、コンテンツを取得する装置Dは、パケットロス率の現在値が厳密に第2の閾値S2よりも大きいことを検知したとき、これと同一ではあるが、別のバージョンVj’(j’≠j)であるチャンクの伝送を要求することができる。この別のバージョンVj’は、第1の伝送ビットレートよりも低い第2の伝送ビットレートに対応する。

0050

plrパラメータは、例えばスライディングウィンドウ中で受信されたRTPパケットの数(例えば、受信されたリフレッシュ済みの各100RTPパケット)と、最初に伝送されたRTPパケットの数であって、(規則RFC3550に準じ、その中ではシーケンス番号と呼ばれる)各RTPパケットヘッダで言及されるRTPパケットの数とを比較することで計算されることが想起される。それゆえに、シーケンス番号ホップを検知することは、それらからパケットロスおよび失われたパケットの数を推論するのに十分である。

0051

plrパラメータの場合、第2の閾値S2は、例えば、4%または5%と等しくなるよう選択されうる。

0052

第2の方法は、限定するものではないが、帯域幅の共有の公平性が優先されるアプリケーションに同様に適用される。例えば、これは、例えばテレビセットTSのような電子(通信)機器のアイテムの画面上で、例えばSTまたはホームゲートウェイのようなこの電子機器に結合されたコンテンツ受信機CRによって復元された映像を閲覧したいユーザに適する。
このタイプの状況においては、映像は、大勢のユーザによって共有される通信ネットワークNによって転送され、それゆえに、公平性の理由から、通信ネットワークNの利用可能な帯域幅BWが第1の閾値S1よりも小さくなる度に、第2のトランスポートプロトコル(ここではUDP)の使用のため、帯域幅は、同一ユーザによって計画的に使用されてはならないことが理解されるであろう。

0053

この目的のために、コンテンツを取得する装置Dは、利用可能な帯域幅BWの現在値だけでなく、好ましくはスライドするタイムスロット上の第1および第2のトランスポートプロトコルの使用の所定の配分にも応じて、所与の各時間において使用されるべきトランスポートプロトコルを選択するように構成されうる。

0054

非限定的な一例として、コンテンツを取得する装置Dは、タイムスロット上の第1および第2のトランスポートプロトコルの75%/25%形式の所定の定義(第1のトランスポートプロトコルが75%、第2のトランスポートプロトコルが25%)を使用しうる。

0055

図4は、図表内において、時間tに応じた通信ネットワークNの利用可能な帯域幅BWにおける変化を示す曲線の第2の例を図示する。この同図は、この第2の時間的変化の曲線において、コンテンツを取得する装置Dに伝送されるコンテンツのチャンクをも表す。異なるサイズの白い矩形は、それぞれ4つの異なる伝送ビットレートに対応して、第1トランスポートプロトコル(ここではTCP(例えばhttpとの組み合わせ(すなわちhttp/TCP)))を用いて第1のサーバCS1によって伝送される、4つのバージョンVjに属するコンテンツチャンクを具体化する。単一サイズのグレーの矩形は、ある伝送ビットレートに対応し、第2のトランスポートプロトコル(ここではUDP(例えばRTPとの組み合わせ(すなわちRTP/UDP)))を用いて第1のサーバCS1によって伝送される、単一のバージョンVjに属するコンテンツチャンクを具体化する。

0056

この第2の例において見られるように、第2のトランスポートプロトコル(ここではUDP)は、利用可能な帯域幅BWの値が第1の閾値S1以下になる度に、計画的に使用されない。実際、利用可能な帯域幅BWの値が第1の閾値S1以下になるとき、現在のタイムスロットにおけるその使用が選択された配分によってそれに割り当てられたパーセンテージ超過しないという条件で、第2のトランスポートプロトコルは、コンテンツを取得する装置Dの要求によって使用される。ある場合において、利用可能な帯域幅BWが第1の閾値S1以下である一方で、第2のトランスポートプロトコルが使用されないことは、確かに注目されうる。

0057

UDPのように、第2のトランスポートプロトコルが、受信されなかったデータパケットについてのいかなる再送機構も備えないとき、コンテンツを取得する装置Dが、バージョンVjのチャンクの伝送のためにこの第2のトランスポートプロトコルを選択したときに、第1トランスポートプロトコルを用いてバージョンVjのこのチャンクから受信されなかったデータパケットについての再送機構をトリガするように構成されることは有益である。これを行うために、コンテンツを取得する装置Dは、例えば、そのコンテンツ受信機に、RTSP形式の再送要求であって、サーバがhttp/TCPセッションを開始することで応答する再送要求を、サーバへ伝送するよう命令することができる。

0058

データパケットの各再送は、再送のためのコンテンツサーバCS2またはCS3から要求されうることに注意されたい。実際、これにより、第1のサーバCS1がさらなるタスクを実行することが回避されるのみならず、とりわけ、それにより、第1のサーバCS1によって使用され、データパケットが失われた(1または複数の)パスとは異なるパスの通信ネットワークN内における使用が可能になる。そのうえ、1つまたは複数のコンテンツサーバを、受信されなかったデータパケットの再送のみに割り当てることによって、再送の時間を減らすことができる。

0059

本発明は、上述の単なる非限定的一例としてのみ提供された、コンテンツを取得および受信する装置の実施態様に限定されないが、以下の請求項の構成において当業者によって把握されうる全ての変形を含む。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ