(57)【要約】【課題】DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給する。【解決手段】  本開示の第１の側面であるコンテンツ供給装置は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備える。本開示は、コンテンツをストリーミング配信するシステムに適用できる。【選択図】図２
2014239278.tif 000002
【特許請求の範囲】
【請求項１】
適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、
前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
を備えるコンテンツ供給装置。
【請求項２】
前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成する
請求項１に記載のコンテンツ供給装置。
【請求項３】
前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含む
請求項２に記載のコンテンツ供給装置。
【請求項４】
前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給される
請求項２に記載のコンテンツ供給装置。
【請求項５】
適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、
前記コンテンツ供給装置による、
前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給ステップと、
供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成ステップと
を含むコンテンツ供給方法。
【請求項６】
適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンピュータを、
前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
して機能させるプログラム。
【請求項７】
適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信する端末装置とから成るコンテンツ供給システムにおいて、
前記コンテンツ供給装置は、
前記複数のストリーミングデータを、異なる複数のネットワークを介して前記端末装置に供給する供給部と、
供給される前記複数のストリーミングデータを前記端末装置が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備え、
前記端末装置は、
取得した前記メタファイルに基づいて前記マニフェストファイルを取得し、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータを選択する
コンテンツ供給システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関し、特に、同一内容のコンテンツを複数の配信パスを介して供給する場合に用いて好適なコンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システムに関する。
【背景技術】
【０００２】
インタネットを介する動画配信に利用可能な国際標準化された動画配信プロトコルとして、Webサイトなどの閲覧と同様のHTTPを用いるMPEG-DASH（Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP、以下、DASHと称する）が知られている（例えば、非特許文献１を参照）。
【０００３】
DASHでは適応型ストリーミング技術が実現されている。すなわち、コンテンツの供給側は、同一内容のコンテンツであって、パスとなるインタネットの通信環境や受信側の能力や状態に応じて画質や画角サイズなどが変更されている複数のストリームを用意するようになされている。一方、受信側は、供給側が用意している複数のストリームのうち、インタネットの通信環境や受信側の能力や状態などに応じて最適なストリームを選択して取得、再生することができる。
【０００４】
このように、DASHにおいては、受信側がストリームを適応的に選択して取得できるように、MPD(Media Presentation Description)と称されるメタファイルが供給側から受信側に供給される。
【０００５】
MPDには、チャンク化されたストリーミングデータ(Audio/Video/Subtitle等のメディアデータ)のアドレス(url情報)が記述されており、受信側は該url情報に基づいて、コンテンツの供給元となる所定のサーバにアクセスし、HTTP配信されるストリーミングデータを取得、再生することができる。
【０００６】
図１は、DASHに基づいてコンテンツをストリーミング配信するコンテンツ供給システムの構成の一例を示している。
【０００７】
該コンテンツ供給システム１０は、コンテンツマネジメントサーバ１１、DASHセグメントストリーマ１２、DASH MPDサーバ１３、キャッシュサーバ１５、およびDASHクライアント１７から構成される。
【０００８】
コンテンツマネジメントサーバ１１は、DASHクライアント１７に供給するコンテンツを管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ１２に出力する。DASHセグメントストリーマ１２は、コンテンツのストリーミングデータを時間的にセグメントに分割して、それぞれをファイル化して保持し、該ファイルの供給元のアドレスをDASH MPDサーバ１３に通知する。さらに、DASHセグメントストリーマ１２は、受信側のDASHクライアント１７からの要求に応じ、HTTPサーバとして、セグメント化されたストリーミングデータのファイルをHTTP配信する。
【０００９】
DASH MPDサーバ１３は、セグメント化された複数のストリーミングデータのファイルの供給元を表すアドレスなどを記述したMPDを生成し、受信側のDASHクライアント１７からの要求に応じ、該MPDをHTTP配信する。
【００１０】
インタネット上に存在するキャッシュサーバ１５は、HTTP配信されたMPDやセグメント化されたストリーミングデータのファイルなどをキャッシングする。そして、キャッシングしているMPDやセグメント化されたストリーミングデータのファイルがDASHクライアント１７-２からDASH MPDサーバ１３またはDASHセグメントストリーマ１２に要求された場合、それらに代わってキャッシングしているMPDやセグメント化されたストリーミングデータをDASHクライアント１７-２にHTTP配信する。
【００１１】
DASHクライアント１７は、DASH MPDサーバ１３からMPDを取得し、取得したMPDに基づいて、DASHセグメントストリーマ１２が用意している複数のストリームのうち、現況に適したものを選択してDASHセグメントストリーマ１２に要求し、該要求に応じてHTTP配信されるファイルを受信、再生する。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【００１３】
上述したように、DASHでは、インタネットを介するHTTP配信を用いた適応的ストリーミング技術が実現されている。
【００１４】
ところで、受信側が各種放送網（地上放送、衛星放送、モバイル通信網、Wi-Fi等の無線LANなど）で放送配信されるストリームや、インタネットによるマルチキャスト配信されたストリームも取得、再生できるのであれば、それらの配信パスも用いてストリームを供給するようにし、受信側で適応的にストリームを選択できるようにすることが望ましい。
【００１５】
しかしながら、DASHにおいてはコンテンツのストリーミングデータをHTTP配信することのみを想定しており、放送配信やマルチキャスト配信は想定されていない。
【００１６】
したがって、DASHにて規定されたMPDにも、放送配信やマルチキャスト配信されるストリームについて記述する術がないので、上記を実現するためにはMPDを拡張する必要がある。
【００１７】
さらに、MPDを拡張する場合、コンテンツを配信する様々なパスのそれぞれのQoS(Quality Of Service)に関するパラメータが記述できれば、受信側がストリームを選択する際の助けとなる。
【００１８】
本開示はこのような状況に鑑みてなされたものであり、DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給できるようにするものである。
【課題を解決するための手段】
【００１９】
本開示の第１の側面であるコンテンツ供給装置は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備える。
【００２０】
前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成することができる。
【００２１】
前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含むことができる。
【００２２】
前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給されるようにすることができる。
【００２３】
本開示の第１の側面であるコンテンツ供給装置のコンテンツ供給方法は、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置のコンテンツ供給方法において、前記コンテンツ供給装置による、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給ステップと、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成ステップとを含む。
【００２４】
本開示の第１の側面であるプログラムは、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンピュータを、前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部として機能させる。
【００２５】
本開示の第１の側面においては、複数のストリーミングデータが異なる複数のネットワークを介して受信側に供給され、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルが生成されて受信側に供給される。
【００２６】
本開示の第２の側面であるコンテンツ供給システムは、適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置と、前記ストリームデータを受信する端末装置とから成るコンテンツ供給システムにおいて、前記コンテンツ供給装置が、前記複数のストリーミングデータを、異なる複数のネットワークを介して前記端末装置に供給する供給部と、供給される前記複数のストリーミングデータを前記端末装置が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部とを備え、前記端末装置が、取得した前記メタファイルに基づいて前記マニフェストファイルを取得し、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータを選択する。
【００２７】
本開示の第２の側面においては、コンテンツ供給装置により、複数のストリーミングデータが異なる複数のネットワークを介して受信側に供給され、供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルが生成されて受信側に供給される。また、端末装置により、取得した前記メタファイルに基づいて前記マニフェストファイルが取得され、前記マニフェストファイルに記述されている前記QoSパラメータとその条件値に基づいて、受信するストリーミングデータが選択される。
【発明の効果】
【００２８】
本開示の第１の側面によれば、異なる複数の配信パスによりコンテンツを供給することができる。
【００２９】
本開示の第２の側面によれば、DASHを用いた適応的ストリーミング技術を拡張し、異なる複数の配信パスによりコンテンツを供給することができる。
【図面の簡単な説明】
【００３０】
【図１】従来のコンテンツ供給システムの構成の一例を示すブロック図である。
【図２】本開示を適用したコンテンツ供給システムの構成例を示すブロック図である。
【図３】コンテンツの時間的区切りを説明する図である。
【図４】MPDの構成を示す図である。
【図５】MPDにおけるPeriod以下の階層構造を示す図である。
【図６】時間軸上にMPDの構成を並べた図である。
【図７】MPDのRepresentation以下の詳細な構造を示す図である。
【図８】Representation以下の構造をXML形式で記述した一例を示す図である。
【図９】拡張したMPDの構造を示す図である。
【図１０】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のXML Schemaの一例を示す図である。
【図１１】serviceLocationAttributeUrl属性により指定されるServiceLocation要素のデータ構造を示す図である。
【図１２】チューニングパラメータの一例を示す図である。
【図１３】DVB衛星放送／ケーブルテレビのQoSパラメータの例を示す図である。
【図１４】DVBケーブルテレビのQoSパラメータの例を示す図である。
【図１５】DVB衛星放送のQoSパラメータの例を示す図である。
【図１６】地上放送(DVB-T)のQoSパラメータの例を示す図である。
【図１７】地上放送(DVB-T2)のQoSパラメータの例を示す図である。
【図１８】ケーブルテレビ(DVB-C2)のQoSパラメータの例を示す図である。
【図１９】その他の地上放送のQoSパラメータの例を示す図である。
【図２０】３Ｇ携帯電話機(UTRA FDD)端末用のQoSパラメータの例を示す図である。
【図２１】３Ｇ携帯電話機(UTRA TDD)端末用のQoSパラメータの例を示す図である。
【図２２】LTE (E-UTRA)端末用のQoSパラメータの例を示す図である。
【図２３】ストリーミングプロトコルのスタックを示す図である。
【図２４】コンテンツ供給装置の動作を説明するフローチャートである。
【図２５】コンテンツ供給システムの動作を説明するフローチャートである。
【図２６】コンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３１】
以下、本開示を実施するための最良の形態（以下、実施の形態と称する）について、図面を参照しながら詳細に説明する。
【００３２】
［コンテンツ供給システムの構成例］
本開示の実施の形態であるコンテンツ供給システムは、コンテンツを異なる複数の配信パスを介して供給する適応的ストリーミングを実現するものである。
【００３３】
具体的には、DASHにおけるMPDを拡張して、コンテンツストリームの配信パスとして、インタネットのみならず各種の放送網を記述できるようにするとともに、各配信パスを選択して受信する場合に必要となるQoS（サービス品質）パラメータの基準値を記述できるようにする。これにより、受信側では、自己の受信環境、デコード能力などに応じて、最適なコンテンツストリームを受信、再生することができる。
【００３４】
図２は、本開示の実施の形態であるコンテンツ供給システムの構成例を示している。
【００３５】
このコンテンツ供給システム２０は、コンテンツ供給装置３０および端末装置４０から構成される。
【００３６】
コンテンツ供給装置３０は、コンテンツマネジメントサーバ３１、DASHセグメントストリーマ３２、DASH MPDサーバ３３、RTP/RTP/FLUTEサーバ３４、および放送配信サーバ３５を有する。
【００３７】
コンテンツマネジメントサーバ３１は、受信側の端末装置４０に供給するコンテンツ（ライブ放送コンテンツを含む）を管理しており、同一内容のコンテンツからビットレートが異なる複数のストリーミングデータを生成してDASHセグメントストリーマ３２に出力する。
【００３８】
DASHセグメントストリーマ３２は、図３に示されるように、コンテンツのストリーミングデータを時間的にピリオド(period)に区切り、さらにセグメント(segment)に分割して、それぞれをファイル化して保持する。さらに、DASHセグメントストリーマ３２は、保持するファイルの供給元となるアドレスをDASH MPDサーバ３３およびRTP/FLUTEサーバ３４に通知する。また、DASHセグメントストリーマ３２は、セグメント化されたストリーミングデータのファイルをRTP/FLUTEサーバ３４に供給する。さらに、DASHセグメントストリーマ３２は、端末装置４０からの要求に応じ、セグメント化されたストリーミングデータのファイルを、HTTPによりインタネット１を介してユニキャスト配信する。
【００３９】
DASH MPDサーバ３３は、異なる複数の配信パスを介して供給されるコンテンツのストリーミングデータを受信するために必要なMPDを生成し、端末装置４０からの要求に応じ、該MPDを、HTTPによりインタネット１を介してユニキャスト配信する。また、DASH MPDサーバ３３は、生成したMPDをRTP/FLUTEサーバ３４に供給する。なお、生成されたMPDは、DASH MPDサーバ３３からHTTP配信する他、RTP/FLUTEサーバ３４からマルチキャスト配信したり、放送配信サーバ３５から放送配信したりするようにしてもよい。
【００４０】
RTP/FLUTEサーバ３４は、セグメント化されたストリーミングデータのファイルを格納したFLUTEパケット（ALC(Asynchronous Layered Coding)パケットなど）を生成するとともに、MPDに基づいてFDTを生成し、FLUTEパケットおよびFDTをFLUTEプロトコルに従い、インタネット１を介してマルチキャスト配信する。また、RTP/FLUTEサーバ３４は、FLUTEパケットおよびFDTを放送配信サーバ３５に供給する。
【００４１】
放送配信サーバ３５は、RTP/FLUTEサーバ３４から供給されるFLUTEパケットおよびFDTを、放送網２を介して放送配信する。なお、放送網２には、地上放送、衛星放送、CATV網、携帯通信網などが含まれるものとする。以下、本明細書においては、マルチキャスト配信の用語は、放送網２を介する放送配信を含むものとする。
【００４２】
インタネット１上に設けられたキャッシュサーバ３６は、インタネット１を介してHTTP配信またマルチキャスト配信されたMPD、セグメント化されたストリーミングデータのファイル、FDT、およびFLUTEパケットなどをキャッシングする。そして、キャッシングしているMPD等が、端末装置４０からDASH MPDサーバ３３などに対して要求された場合、それらに代わってキャッシングしているMPDなどを要求元の端末装置４０にHTTP配信する。
【００４３】
［MPDの概要］
次に、MPDの概要について、図４および図５を参照して説明する。
【００４４】
図４はMPDのデータ構成を示している。図５はMPDにおけるPeriod以下の階層構造を示している。
【００４５】
MPDは、コンテンツ（Media)に関する情報がPeriod毎に区分されている。各Periodには、同一内容であって画質や画角サイズが変更されているビットレートなどのストリーム属性の異なるストリーミングデータに関する情報からなる複数のRepresentationが用意されている。Representationには、Periodをさらに時間的に分割したSegmentに関する情報が格納されている。
【００４６】
図６は、時間軸上にMPDの構造を並べた状態を示している。同図から明らかなように、同一のSegmentに対して複数のRepresentationが存在しているので、端末装置４０ではこれらのうちのいずれかを、通信環境や自己のデコード能力などに応じてSegment単位で適応的に選択することにより、適切なストリームデータを取得、再生することができる。
【００４７】
図７は、MPDのRepresentation以下の構造を詳細に示している。Representationには、セグメント化されたストリームデータが格納されたファイルの供給元のアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合には、各ファイルそれぞれの供給元のアドレス（url情報）のシーケンスが記述される。また、セグメント化された複数のストリームデータがまとめて一つのファイルにファイル化されている場合には、該ファイルの供給元のアドレス（Base URL）と、該ファイルにおける各セグメントの範囲(mediaRange)のシーケンスが記述される。なお、図７には、後者の場合が示されている。
【００４８】
図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
【００４９】
同図においては、MPD/Period/AdaptationSet/Representation/BaseURLに記述されている"http://example.com/counter-10mn_avc_dash.mp4"が、複数のセグメントがまとめてファイル化されているファイルの供給元のアドレスを示している。
【００５０】
また、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeが該ファイルにおける、セグメント化されたストリームデータのバイト範囲を示している。
【００５１】
例えば、MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange="795-83596"は、該ファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のセグメント化されたストリームデータであることを示している。
【００５２】
したがって、端末装置４０が１つ目のセグメント化されたストリームデータを取得する際には、ファイルのurl"http://example.com/counter-10mn_avc_dash.mp4"とともに、そのRangeヘッダにmediaRange"795-83596"を指定してHTTPリクエストを発行すればよい。この際のHTTPリクエストは以下のとおりとなる。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=795-83596
【００５３】
また例えば２つ目のセグメント化されたストリームデータを取得するためには、ファイルのurl"http://example.com/Servicer/counter-10mn_avc_dash.mp4"とともに、mediaRange"83597-166046"を指定してHTTPリクエストを発行すればよい。この際のHTTPリクエストは以下のとおりとなる。
GET /counter-10mn_avc_dash.mp4 HTTP/1.1
Host: example.com
Range: bytes=83597-166046
【００５４】
［MPDの拡張］
本実施の形態においては、コンテンツストリームの配信パスとして、インタネットのみならず各種の放送網を記述できるようにし、さらに各配信パスを選択して受信する場合に必要となるQoSパラメータの基準値を記述できるようMPDを拡張する。
【００５５】
具体的には、セグメントファイル群が転送されるIPマルチキャストストリームを受信するための新たな要素としてチューニングパラメータ(DeliverySystemAttributes)およびIPマルチキャストアドレス(IPMulticastAddress)が記述されたServiceLocation要素を導入する。そして、該ServiceLocation要素をルート要素として格納するserviceLocationAttributeファイルのurlを記述するためのserviceLocationAttribute Url属性をMPDに導入する。
【００５６】
図１０は、serviceLocationAttributeUrl属性により指定されるServiceLocationファイルに格納されるServiceLocation要素のXML schemaの一例を示している。
【００５７】
図１１は、図１０に示されたDeliverySystemAttributes以下のXML schemaの階層構造を図示したものである。
【００５８】
L3L4L5Addressは、マルチキャストストリームの解決にSDPを利用しない場合の、FLUTEセッションストリーム、RTPマルチキャストストリームが転送されるIPアドレス"ipAddress"、ポート番号"port"、およびFLUTEのセッションID"transportSessionId"が格納される要素である。
【００５９】
DeliverySystemIdentifierは、放送配信またはマルチキャスト配信にて採用されているチューニングパラメータのデータ構造のフォーマット識別子が格納される要素である。例えば、欧州にて採用されている地上放送による放送配信の場合には、"ID_DVB_T"が格納され、衛星放送に放送配信の場合には、"ID_DVB_S"が格納される。
【００６０】
DeliverySystemDescriptorは、DeliverySystemIdentifierで識別される放送配信またはマルチキャスト配信にて規定されたチューニングパラメータのデータ構造(パラメタ自体)が格納される要素である。図１２は、欧州にて採用されている地上放送による放送配信に対応するチューニングパラメータのデータ構造の例である。なお、実際には、上記フォーマットに則ったバイト列をbase64等により文字列に変換してDeliverySystemDescriptorに記述する。
【００６１】
RequiredQoSParameterは、チューニングに必要なQoSパラメータの識別名"parameterURI"、およびその条件値"requestdValue"としての"upperLimit(上限値)"、"lowerLimit(下限値)"、または"just(指定値)"を格納する要素である。
【００６２】
RequiredQoSParameterの記述例について具体的に説明する。
【００６３】
例えば、ストリーミングサービス一般に適用されるQoEパラメータとして、遅延、遅延揺らぎ、損失(エラー)、スループット等が存在する。このうち、スループットについて記述する場合には、
RequiredQoSParameter/@parameterURI=urn:DownLinkThroughput(下りスループットを示すユニークな識別子)と記述し、条件値としてその下限値を指定するときは、
RequiredQoSParameter/requiredValue/@lowerLimit="3Mbps"（下りスループットの下限値3Mbpsとの意味）と記述する。
【００６４】
また例えば、放送を受信する場合や、Wi-Fi等無線LANを介してストリームを受信する場合の放送や携帯電話の端末の物理層信号品質を表すパラメータには、代表的なものとして、電波の強さに関するものと、ビット誤り率(BER)に関するものが存在する。より具体的には、前者の例としては、搬送波対雑音比(CN比)、受信信号強度(RSSI)等がある。後者の例としては、リード・ソロモン(RS)等の誤り訂正処理(放送/通信方式によって異なる)前/後のビット誤り率(BER before/after RS)や、トランスポート・ブロックの誤り率(BLER)等がある。
【００６５】
このうち、CN比について記述する場合には、
RequiredQoSParameter/@parameterURI=urn:CarrierToNoiseRatio(CN比を示すユニークな識別子)と記述し、条件値としてその下限値を指定するときには、
RequiredQoSParameter/requiredValue/@lowerLimit="10dB"（CN比の下限値10dBとの意味）
と記述する。
【００６６】
また、条件値としてCN比をいくつかのクラス（例えば３クラス）に分類して評価するときには、
レベル１("urn:CNclass1"で指定):１０-3以上（不良）
レベル２("urn:CNclass2"で指定): １０-5以上、１０-3未満（良）
レベル３("urn:CNclass3"で指定): １０-５未満（最良）
と定義した上で、
RequiredQoSParameter/@parameterURI=urn:CarrierToNoiseRatio(C/Nを示すユニークな識別子)と記述し、条件値として、
RequiredQoSParameter/requiredClass/＠class="urn:CNclass2"
RequiredQoSParameter/requiredClass/＠class="urn:CNclass3"
（CN比とクラス１またはクラス２が必要との意味）
と記述する。
【００６７】
なお、QoSパラメータとしては、上述した例の他にも、図１３乃至図２１に挙げるパラメータを記述することができる。
【００６８】
図１３は、DVB衛星放送／ケーブルテレビのQoSパラメータの例である。図１４は、DVBケーブルテレビのQoSパラメータの例である。図１５は、DVB衛星放送のQoSパラメータの例である。図１６は、地上放送(DVB-T)のQoSパラメータの例である。図１３乃至図１６に示されたQoSパラメータの例は、いずれもETSI TR 101 290 V1.2.1 (2001-05), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems"にて定義されているものである。
【００６９】
図１７は、地上放送(DVB-T2)のQoSパラメータの例である。これらは、DVB BlueBook A14-2 (07/12), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-T2 Systemにて定義されているものである。
【００７０】
図１８は、ケーブルテレビ(DVB-C2)のQoSパラメータの例である。これらは、DVB BlueBook A14-3 (03/13), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems; Amendment for DVB-C2 System"にて定義されているものである。
【００７１】
図１９は、その他の地上放送のQoSパラメータの例である。これらは、NorDig Unified ver2.4にて定義されているものである。
【００７２】
図２０は、３Ｇ携帯電話機(UTRA FDD)端末用のQoSパラメータの例である。これらは、ETSI TS 125 215 V11.0.0 (2012-11); "Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (FDD) (3GPP TS 25.215 version 11.0.0 Release 11)"にて定義されているものである。
【００７３】
図２１は、３Ｇ携帯電話機(UTRA TDD)端末用のQoSパラメータの例である。これらは、ETSI TS 125 225 V11.0.0 (2012-09); "Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (TDD) (3GPP TS 25.225 version 11.0.0 Release 11)"にて定義されているものである。
【００７４】
図２２は、LTE (E-UTRA)端末用のQoSパラメータの例を示す図である。これらは、ETSI TS 136 214 V11.1.0 (2013-02); "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements (3GPP TS 36.214 version 11.1.0 Release 11)"にて定義されているものである。
【００７５】
［ストリーミングプロトコルスタックについて］
上述したServiceLocation/DeliverySystem要素に格納される情報によりチューンされたMPEG2-TSストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリーム上では、RTPまたはFLUTEプロトコルによりファイル群が運ばれる。
【００７６】
図２３は、IPパケットストリーム上で運ばれるファイル群のストリーミングプロトコルスタックを示している。
【００７７】
RTPは、IPパケット上にリアルタイム(同期型)ストリームを転送するプロトコルである。FLUTEプロトコルは、IPパケット上にファイルを転送するプロトコルであり、それぞれ同図Ａまたは同図Ｂに示されるように階層的構成される。ここで、MACはリンク層プロトコルの総称であり、放送系ではGSE、TLV等が相当する。
【００７８】
［FDTの拡張］
FLUTEプロトコルでは、同一のTOIを有する全てのファイルが受信された段階で初めて、Content-LocationのURLにより指定されるファイルとしてそれらに対してアクセスが可能となる。したがって、映画などのVoDコンテンツのように再生時間が長く１つのファイルのサイズが非常に大きい場合には、そのファイル全体が受信側で再構成されてアクセスできるようになるまでに、ある程度の時間が必要となる。
【００７９】
これに対して、DASHを利用したストリーミングにおいては、対象のVoDコンテンツのファイルのサイズが大きくても、個々のHTTPリクエストのmediaRange指定によりファイルの一部をセグメント単位で取得、再生することができる。したがって、放送配信またはマルチキャスト配信のIPマルチキャストストリームによりFLUTE転送されるファイルについても同様にセグメントの単位で取得、再生できるようにすることが望ましい。
【００８０】
ただし、現在規定されているFDTのContent-Location要素では、MPDのBaseURL＋SegmentURL mediaRangeのシーケンスのように、ファイルの一部を表現することができない。そこで、FDTについてもファイルの一部を表現できるように拡張する。
【００８１】
すなわち、FDTに対して、Content-Locationと、さらにそのContent-Locationのurlで指定されるファイルの中のバイトレンジが指定できるように新たにrange属性を導入する。range属性のシンタクスには、range-specifier(RFC2616.section.14.35.1)の定義を適用する。range属性には、MPDのPeriod/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeをそのまま流用することができる。
【００８２】
このようにFDTを拡張すれば、端末装置４０が取得、再生するストリーミングデータを、HTTP配信、放送配信、またはマルチキャスト配信の間で適応的、かつ、アドホックに切り替えることが可能となる。また、コンテンツのストリーミングサービスを運用する上での柔軟性を確保することが可能となる。
【００８３】
［コンテンツ供給システム２０の動作］
次に、コンテンツ供給システム２０の動作について説明する。
【００８４】
図２４は、コンテンツ供給システム２０のコンテンツ供給装置３０の動作を説明するフローチャートである。
【００８５】
ステップＳ１において、コンテンツマネジメントサーバ３１は、受信側の端末装置４０に供給するための、同一内容のコンテンツであってビットレートなどが異なる複数のストリーミングデータをDASHセグメントストリーマ３２に供給する。また、コンテンツマネジメントサーバ３１は、ステップＳ２において、コンテンツのメタデータをDASH MPDサーバ３３に通知する。
【００８６】
ストリーミングデータの供給を受けたDASHセグメントストリーマ３２は、ステップＳ１１において、コンテンツのストリーミングデータを時間的にピリオドに区切り、さらにセグメントに分割して、DASHストリームセグメントを生成し、それぞれをファイル化する。また、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルを、マルチキャスト配信のためにRTP/FLUTEサーバ３４に供給する。
【００８７】
ステップＳ１２において、DASHセグメントストリーマ３２は、DASHストリームセグメントのファイルの供給元のアドレス（url情報）を、DASH MPDサーバ３３およびRTP/FLUTEサーバ３４に通知する。これ以降、DASHセグメントストリーマ３２は、ステップＳ１３において、端末装置４０からの要求に応じた、DASHストリームセグメントのファイルのインタネット１を介するHTTP配信を開始する。
【００８８】
DASHストリームセグメントのファイルの供給元のアドレスの通知を受けたDASH MPDサーバ３３は、ステップＳ２１においてMPDを生成し、ステップＳ２２において、該MPDをRTP/FLUTEサーバ３４に供給し、そのFLUTEによる配信を依頼する。これ以降、ステップＳ２３において、DASH MPDサーバ３３は、端末装置４０からの要求に応じた、生成したMPDのインタネット１を介するHTTP配信を開始する。
【００８９】
DASH MPDサーバ３３からMPDの供給を受けたRTP/FLUTEサーバ３４は、ステップＳ３１において、MPDに基づいて、拡張されたFDTを生成するとともに、DASHセグメントストリーマ３２から供給されているDASHストリームセグメントのファイルを格納したFLUTEパケット（またはRTPパケット）を生成する。
【００９０】
ステップＳ３２において、RTP/FLUTEサーバ３４は、生成したFDTとFLUTEパケット（またはRTPパケット）を放送配信サーバ３５に供給し、それらの放送配信を依頼する。これ以降、所定のタイミングにおいて、ステップＳ３３として、RTP/FLUTEサーバ３４は、FDTとFLUTEパケット（またはRTPパケット）のインタネット１を介するマルチキャスト配信を開始する。
【００９１】
FDTとFLUTEパケット（またはRTPパケット）の供給を受けた放送配信サーバ３５は、所定のタイミングにおいて、ステップＳ４１として、FLUTEパケット（またはRTPパケット）およびFDTを、放送網２を介して放送配信する。以上で、コンテンツ供給システム２０のコンテンツ供給装置３０の動作説明を終了する。
【００９２】
次に、図２５は、端末装置４０がコンテンツを受信、再生するまで動作を説明するフローチャートである。
【００９３】
コンテンツを受信、再生しようとする端末装置４０は、ステップＳ５１において、インタネット１を介してDASH MPDサーバ３３にアクセスし、MPDを要求する。この要求に応じ、ステップＳ６１において、DASH MPDサーバ３３は、インタネット１を介して端末装置４０にMPDをHTTP配信する。
【００９４】
なお、インタネット１上のキャッシュサーバ３６が該MPDを保持している場合には、DASH MPDサーバ３３に代わってキャッシュサーバ３６が端末装置４０に該MPDをHTTP配信することもある。
【００９５】
また、MPDがFLUTE配信されたり、放送網２を介して放送配信されたりする場合もあり、それを受信、取得するときにはステップＳ５１の処理は不要となる。
【００９６】
MPDを取得した端末装置４０は、ステップＳ５２において、MPDのserviceLocationAttributeUrl属性に基づいてServiceLocationAttributeファイルを取得し、ServiceLocationAttributeファイルに記述されているRequiredQoSParameter要素を参照するとともに、自己の現在の通信状況をモニタリングして、取得する最適なストリームを選択する。
【００９７】
ステップＳ５３において、端末装置４０は、MPDの、選択したストリームに対応するBaseURLとmediaRangeにもとづいてHTTPリクエストを発行して、DASHセグメントストリーマ３２にDASHストリームセグメントのファイルを要求する。この要求に応じ、ステップＳ７１において、DASHセグメントストリーマ３２は、対応するファイルをインタネット１を介して端末装置４０にHTTP配信する。なお、インタネット１上のキャッシュサーバ３６が該ファイルを保持している場合には、DASHセグメントストリーマ３２に代わってキャッシュサーバ３６が端末装置４０に該ファイルをHTTP配信することもある。
【００９８】
ステップＳ５４において、端末装置４０は、HTTP配信された該ファイルを受信、再生する。この後、例えばインタネット１の通信環境が悪化したりした場合、端末装置４０は、受信するストリームを適応的に切り替えることができる。具体的には、ステップＳ５５として、例えば、放送配信サーバ３５がステップＳ８１として放送配信しているDASHストリームセグメントのファイルを受信、再生することができる。また、この後、HTTP配信されるファイルの受信、再生に戻ることもできる。
【００９９】
なお、DASHセグメントストリーマ３２からHTTP配信される、よりビットのレートが低いストリームを受信、再生するように切替えたり、RTP/FLUTEサーバ３４がインタネット１を介してマルチキャスト配信するストリームに切替えたりすることも可能である。以上で、端末装置４０の動作説明を終了する。
【０１００】
以上説明したように、本実施の形態においては、MPDのserviceLocationAttributeUrl属性に基づいて参照可能なServiceLocationAttributeファイルに、RequiredQoSParameter要素を設けたので、端末装置４０にて現況において最適なストリームにスイッチングすることが可能となった。
【０１０１】
ところで、上述した一連の処理を実行するコンテンツ供給装置３０、および端末装置４０は、それぞれをハードウェアにより構成する他、コンピュータがソフトウェアを実行することにより実現することもできる。このコンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０１０２】
図２６は、上述したコンピュータのハードウェアの構成例を示すブロック図である。
【０１０３】
このコンピュータ１００において、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
【０１０４】
バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９、およびドライブ１１０が接続されている。
【０１０５】
入力部１０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１０７は、ディスプレイ、スピーカなどよりなる。記憶部１０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１０９は、ネットワークインタフェースなどよりなる。ドライブ１１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア１１１を駆動する。
【０１０６】
以上のように構成されるコンピュータ１００では、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５およびバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
【０１０７】
コンピュータ１００（CPU１０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インタネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０１０８】
コンピュータ１００では、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
【０１０９】
なお、コンピュータ１００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであってもよいし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであってもよい。
【０１１０】
本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【０１１１】
本開示は以下のような構成もとることができる。
（１）
適応的ストリーミング技術に従い、同一内容のコンテンツであって属性が異なる複数のストリーミングデータを供給するコンテンツ供給装置において、
前記複数のストリーミングデータを、異なる複数のネットワークを介して受信側に供給する供給部と、
供給される前記複数のストリーミングデータを受信側が選択するためのQoSパラメータとその条件値を記述したマニフェストファイルの取得先を含むメタファイルを生成して受信側に供給するメタファイル生成部と
を備えるコンテンツ供給装置。
（２）
前記メタファイル生成部は、前記メタファイルとして拡張されたMPDを生成する
前記（１）に記載のコンテンツ供給装置。
（３）
前記異なる複数のネットワークは、インタネット、地上放送網、衛星放送網、ケーブルテレビ放送網、モバイル放送網、または無線LANのうちの少なくとも一つを含む
前記（１）または（２）に記載のコンテンツ供給装置。
（４）
前記メタファイルは、前記ネットワークを介したHTTP配信、FLUTE配信、または放送配信により、前記受信側に供給される
前記（１）から（３）のいずれかに記載のコンテンツ供給装置。
【符号の説明】
【０１１２】
２０  コンテンツ供給システム，  ３０  コンテンツ供給装置，  ３１  コンテンツマネジメントサーバ，  ３２  DASHセグメントストリーマ，  ３３  DASH MPDサーバ，  ３４  FLUTEサーバ，  ３５  放送配信サーバ，  端末装置４０，  １００  コンピュータ，  １０１  CPU
【図１】
2014239278.tif 000003
【図２】
2014239278.tif 000004
【図３】
2014239278.tif 000005
【図４】
2014239278.tif 000006
【図５】
2014239278.tif 000007
【図６】
2014239278.tif 000008
【図７】
2014239278.tif 000009
【図８】
2014239278.tif 000010
【図９】
2014239278.tif 000011
【図１０】
2014239278.tif 000012
【図１１】
2014239278.tif 000013
【図１２】
2014239278.tif 000014
【図１３】
2014239278.tif 000015
【図１４】
2014239278.tif 000016
【図１５】
2014239278.tif 000017
【図１６】
2014239278.tif 000018
【図１７】
2014239278.tif 000019
【図１８】
2014239278.tif 000020
【図１９】
2014239278.tif 000021
【図２０】
2014239278.tif 000022
【図２１】
2014239278.tif 000023
【図２２】
2014239278.tif 000024
【図２３】
2014239278.tif 000025
【図２４】
2014239278.tif 000026
【図２５】
2014239278.tif 000027
【図２６】
2014239278.tif 000028