JPWO2014132821A1 - 情報処理装置および方法、プログラム、並びにコンテンツ供給システム - Google Patents

情報処理装置および方法、プログラム、並びにコンテンツ供給システム Download PDF

Info

Publication number
JPWO2014132821A1
JPWO2014132821A1 JP2015502864A JP2015502864A JPWO2014132821A1 JP WO2014132821 A1 JPWO2014132821 A1 JP WO2014132821A1 JP 2015502864 A JP2015502864 A JP 2015502864A JP 2015502864 A JP2015502864 A JP 2015502864A JP WO2014132821 A1 JPWO2014132821 A1 JP WO2014132821A1
Authority
JP
Japan
Prior art keywords
distribution
content
mpd
unit
dash
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
JP2015502864A
Other languages
English (en)
Inventor
山岸　靖明
靖明 山岸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Saturn Licensing LLC
Original Assignee
Saturn Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Saturn Licensing LLC filed Critical Saturn Licensing LLC
Publication of JPWO2014132821A1 publication Critical patent/JPWO2014132821A1/ja
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/20—Arrangements for broadcast or distribution of identical information via plural systems
    • H04H20/24—Arrangements for distribution of identical information via broadcast system and non-broadcast system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42—Arrangements for resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6408—Unicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本開示は、コンテンツの配信をより効率よく行うことができるようにする情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関する。コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する。本開示は、例えば、情報処理装置に適用することができる。

Description

本開示は情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関し、特に、コンテンツの配信をより効率よく行うことができるようにした情報処理装置および方法、プログラム、並びにコンテンツ供給システムに関する。
近年、インターネット上のストリーミングサービスの主流がOTT-V（Over The Top Video）となっている。この基盤技術として普及し始めているのがDASH（Dynamic Adaptive Streaming over HTTP）である（例えば、非特許文献１参照）。
DASHはポイントトゥーポイントのHTTP（HyperText Transfer Protocol）ストリーミングにより実現されるため、スポーツ中継等の大多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミングに適用する場合、例えばAkamai（登録商標）等のCDN（Contents Delivery Network）のサポートが必要となることがある。
ただし、一般的に、CDNは、コスト的な制約から、既存の放送配信に匹敵する程のスケーラビリティを求めることはできないので、マルチキャストやブロードキャストベアラを併用することにより、ネットワークリソースの負荷を低減する方法が考えられた。
「既存のWebサーバで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
しかしながら、この方法を適用するだけでは、併用するマルチキャスト・ブロードキャストネットワークリソースの容量等によって、常に十分なコストメリットが得られるとは限らなかった。
本開示は、このような状況に鑑みてなされたものであり、コンテンツの配信をより効率よく行うことができるようにするものである。
本技術の一側面は、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部とを備える情報処理装置である。
前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定することができる。
前記制御情報を受け取る受け取り部をさらに備え、前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新することができる。
前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価することができる。
前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取ることができる。
前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取ることができる。
マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価することができる。
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新することができる。
前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、前記制御情報は、MPD（Media Presentation Description）であるようにすることができる。
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納することができる。
前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納することができる。
前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備えることができる。
前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備えることができる。
前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルであることができる。
前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入することができる。
前記更新部により更新された前記制御情報を供給する供給部をさらに備えることができる。
クライアントの代わりに前記コンテンツを取得し、前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備えることができる。
本技術の一側面は、また、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する情報処理方法である。
本技術の一側面は、さらに、コンピュータを、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部として機能させるプログラムである。
本技術の一側面は、また、サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新するコンテンツ供給システムである。
本技術においては、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かが判定され、マルチキャスト配信若しくは放送配信を利用すると判定された場合、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するように、コンテンツのユニキャスト配信に関する制御情報が更新される。
本開示によれば、コンテンツの配信に関する情報を処理することができる。特に、コンテンツの配信をより効率よく行うようにすることができる。
従来のコンテンツ配信システムの例を説明する図である。 DASHの概要を説明する図である。 MPDの構成例を示す図である。 コンテンツの時間的区切りを説明する図である。 MPDにおけるPeriod以下の階層構造の例を示す図である。 MPDファイルの構成例を時間軸上で説明する図である。 MPDのRepresentation以下の構造の例を説明する図である。 MPDのXML記述例を示す図である。 セグメント取得要求の例を説明する図である。 拡張したMPDのXML記述例を示す図である。 serviceLocationAttributeUrl属性により指定されるServiceLocation要素のXML Schemaの一例を示す図である。 serviceLocationAttributeUrl属性により指定されるServiceLocation要素のデータ構造を示す図である。 User Service Description構造の例を示す図である。 FLUTEプロトコルの階層構造を示す図である。 FDTのデータ構造を示す図である。 拡張したFDTのデータ構造を示す図である。 コンテンツ配信システムの主な構成例を示すブロック図である。 MPDコンフィギュレータの物理的構成の例を示すブロック図である。 DASHセグメントストリーマが有する機能の例を示す機能ブロック図である。 FLUTEサーバが有する機能の例を示す機能ブロック図である。 放送配信サーバが有する機能の例を示す機能ブロック図である。 DASH-MPDサーバが有する機能の例を示す機能ブロック図である。 DASHクライアントが有する機能の例を示す機能ブロック図である。 MPDコンフィギュレータが有する機能の例を示す機能ブロック図である。 BC/MCリソースマネージャが有する機能の例を示す機能ブロック図である。 DASHクライアントプロキシが有する機能の例を示す機能ブロック図である。 配信制御処理の流れの例を説明するフローチャートである。 DASHクライアントプロキシ処理の流れの例を説明するフローチャートである。 コンテンツ配信処理の流れの例を説明するフローチャートである。 コンテンツ配信処理の流れの例を説明する、図２９に続くフローチャートである。 コンテンツ配信処理の流れの例を説明する、図２９に続くフローチャートである。 コンテンツ配信システムの他の構成例を示すブロック図である。 プロキシサーバが有する機能の例を示す機能ブロック図である。 コンテンツ配信処理の流れの他の例を説明するフローチャートである。 コンテンツ配信処理の流れの他の例を説明する、図３４に続くフローチャートである。 コンテンツ配信処理の流れの他の例を説明する、図３４に続くフローチャートである。 MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。 ユニキャスト配信の場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。 マルチキャスト配信若しくは放送配信の場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。 マルチキャスト配信若しくは放送配信の場合の、MPDおよびセグメントの配信処理の流れの、他の例を説明するフローチャートである。 MPDおよびセグメントをFLUTEにより配信する場合の配信処理の流れの例を説明するフローチャートである。 プロキシサーバを介して行う場合の、MPDおよびセグメントの配信処理の流れの例を説明するフローチャートである。
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
０．概要
１．第１の実施の形態（コンテンツ配信システム）
２．第２の実施の形態（コンテンツ配信システム）
３．第３の実施の形態（MPDおよびストリームの伝送）
＜０．概要＞
＜コンテンツ配信システム＞
近年、インターネット上のストリーミングサービスの主流がOTT-V（Over The Top Video）となっている。この基盤技術として普及し始めているのがDASH（Dynamic Adaptive Streaming over HTTP）である。
DASHは、ポイントトゥーポイントのHTTP（HyperText Transfer Protocol）ストリーミングにより実現されるため、スポーツ中継等の大多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミングに適用する場合、例えばAkamai（登録商標）等のCDN（Contents Delivery Network）のサポートが必要となることがある。
図１は、DASHによるコンテンツを配信するシステムの例を説明する図である。図１に示されるコンテンツ配信システム１０は、DASHを利用して、画像や音声等よりなるコンテンツデータをサーバからクライアントに配信するシステムである。
図１に示される例のように、このコンテンツ配信システム１０においては、DASH-MPDファイルも、DASHセグメントもすべてCDNを介して配信される。つまり、まず、DASH MPDサーバ１１が、DASH-MPDファイル４１を、CDN２０を介して、最初にHTTPリクエストを発したDASHクライアント３１に供給する。このDASH-MPDファイル４１は、CDN２０のキャッシュサーバ（DASHキャッシュ２１）にも保持される。
DASHクライアント３１が、取得したDASH-MPDファイル４１に基づいて、コンテンツを要求すると、DASHセグメントストリーマ１２は、そのコンテンツであるDASHセグメント６１を、矢印５１のように、CDN２０を介して、DASHクライアント３１に供給する。図１において小さな楕円は、それぞれ、セグメント化されたコンテンツであるDASHセグメントを示している。このDASHセグメント６１も、CDN２０のキャッシュサーバ（DASHキャッシュ２２乃至DASHキャッシュ２４等）にも保持される。
その後、他のクライアントであるDASHクライアント３２が、同じコンテンツについてHTTPリクエストを発すると、CDN２０のDASHキャッシュ２１が、保持しているDASH-MPDファイル４１をDASH-MPDファイル４２としてDASHクライアント３２に供給する。これによりDASH MPDサーバ１１の負荷が低減される。もちろん、CDN２０のキャッシュサーバにDASH-MPDファイルがキャッシュされていない場合は、DASHクライアント３１の場合と同様に、DASH MPDサーバ１１からDASH-MPDファイル４２がDASHクライアント３２に供給される。
そして、DASHクライアント３２が、取得したDASH-MPDファイル４２に基づいて、コンテンツを要求すると、DASHセグメントストリーマ１２は、そのコンテンツであるDASHセグメント６１を、矢印５２のように、CDN２０を介して、DASHクライアント３２に供給する。このとき、CDN２０のキャッシュサーバ（DASHキャッシュ２２乃至DASHキャッシュ２４等）にそのコンテンツのDASHセグメント６１がキャッシュされている場合、そのDASHセグメント６１がDASHクライアント３２に供給される。これによりDASHセグメントストリーマ１２の負荷が低減される。
このようにCDNを利用することにより、より効率的にコンテンツを配信することができる。
＜DASH＞
DASHによるコンテンツの伝送の手順を、図２を参照して説明する。まず、コンテンツを取得する側のクライアントは、ブラウザ等のアプリケーション（HTTP Streaming Client）によって、所望のコンテンツのMPDを選択し、サーバ（Media Presentation on HTTP Server）から取得する。
MPDを取得すると、クライアントは、MPDを解析して、所望のコンテンツのDASHセグメントをサーバから取得し、それを再生する。
MPDは、図３に示されるような構成を有する。MPDの解析（パース）においては、クライアントは、MPD（図３のMedia Presentation）のPeriodに含まれるRepresentationの属性から最適なものを選択する。
クライアントは、選択したRepresentationの先頭のSegmentを呼んでInitialization Segmentを取得し、処理する。続いて、クライアントは、後続のSegmentを取得し、再生する。
なお、MPDにおける、Period、Representation、およびSegmentの関係は、図４のようになる。つまり、１つのメディアコンテンツは、時間方向のデータ単位であるPeriod毎に管理することができ、各Periodは、時間方向のデータ単位であるSegment毎に管理することができる。また、各Periodについて、ビットレート等の属性の異なる複数のRepresentationを構成することができる。
したがって、このMPDのファイル（MPDファイルとも称する）は、Period以下において、図５に示されるような階層構造を有する。また、このMPDの構造を時間軸上に並べると図６の例のようになる。図６から明らかなように、同一のSegmentに対して複数のRepresentationが存在している。クライアントは、これらのうちのいずれかを適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータを取得し、再生することができる。
ただし、一般的に、CDNは、コスト的な制約から、既存の放送配信に匹敵する程のスケーラビリティを求めることはできない。
Representationで記述する対象は、インターネット（NIC（Network Interface Controller））経由で配信されるストリームのurlであるが、もしクライアントがMBMS（Multimedia Broadcast and Multicast Service）等のブロードキャスト・マルチキャスト用（放送系）物理層が実装されている場合、それらを経由して受信できるチャンネル上に同一のライブ放送等が配信されているときには、それら経由で受信再生した方が放送系のQoS（Quality of Service）（保証帯域/遅延等）の保証された伝送路上ではるかに品質の高いコンテンツ再生が期待できる場合がある。
また、コスト的にも放送を使った方がリーズナブルな配信ができる可能性がある。また、再生途中で、インターネット配信環境（トラフィック）の急激な変化により、例えば、準備されているビットレートの範囲（の下限）を超えたストリームでしか受信できないような状況になった場合には、ストリーム再生が停止してしまう。このような場合に、たとえそれがインターネット配信よりもビットレートの低いストリームであっても視聴そのものを継続したいというユーザには、放送系伝送路上のストリームにスイッチして視聴を継続させるというような代替配信が必要となる。しかしながら、現在のDASHのスコープではいずれのケースもサポートすることができなかった。
＜MPDの拡張＞
そこで、ネットワークリソースの負荷を低減し、より効率よくコンテンツの配信を行うことができるように、マルチキャストやブロードキャストベアラを利用することができるようにする。より具体的には、Representationの１つとして、上述の放送チャネルで配信されるストリームを指定できるようにする。そのために、放送チャネルチューニング用のパラメタを記述する要素を配置できるようにし、放送チャネルで配信されるストリーム上のファイル転送プロトコルFLUTE（File Delivery over Unidirectional Transport）に対しても拡張属性を配置できるようにする。
図７は、MPDのRepresentation以下の構造の例を示す図である。Representationには、セグメント化されたストリームデータが格納されたファイルのアドレスが記述される。具体的には、セグメント化された複数のストリームデータがそれぞれ個別にファイル化されている場合、各ファイルのアドレス（url情報）のシーケンスが記述される。また、セグメント化された複数のストリームデータがまとめてファイル化されている場合、該ファイルのアドレス（Base URL）と、該ファイルにおける各セグメントの範囲（mediaRange）のシーケンスが記述される。なお、図７には、後者の場合が示されている。
MPDに、Representationの１つとして、放送チャンネル上に配信される同一コンテンツストリームを表現する属性を記述できるようにするための拡張利用方式を以下に説明する。ストリームを構成するチャンク化されたコンテンツデータのシーケンスは、チャンク化されたコンテンツデータが格納されるファイルのurlのシーケンスか、もしくは、チャンク化されたコンテンツのデータがファイルの中に納まっている場合には、それらが格納される"ファイルのURL+バイト範囲 "のシーケンスにより表現されるようにDASHで規定されている。
図８は、図７に示されたRepresentation以下の構造をXML形式で記述した一例を示している。
図８においては、対象のMP4のメディアが格納されるファイルのURLが
MPD/Period/AdaptationSet/Representation/BaseURL
に記述されている
”http://example.com/counter-10mn_avc_dash.mp4”
で表されている。
また、図８の
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange=”795-83596”
は、そのファイルにおけるバイト範囲795バイト目から83596バイト目までが１つ目のSegment（セグメント化されたストリームデータ）であることを示している。
また、図８の
MPD/Period/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRange="83597-166046"
は、そのファイルにおけるバイト範囲83597バイト目から166046バイト目までが２つ目のSegmentであることを示している。
クライアントは、これらのSegmentを取得する際、ファイルのurlである
"http://example.com/counter-10mn_avc_dash.mp4"
を指定するとともに、HTTPリクエストのRangeヘッダに当該バイトレンジを指定するHTTPリクエストを発行する。すなわち、図９のＡに示されるように、クライアントは、最初のセグメントを取得するためのHTTPリクエストにおいて、ファイルurlとして
http://example.com/counter-10mn_avc_dash.mp4
を指定し、さらに、バイトレンジとして" 795-83596"を指定する。
また、図９のＢに示されるように、クライアントは、２つ目のセグメントを取得するためのHTTPリクエストにおいて、ファイルurlとして
http://example.com/server/counter-10mn_aacdash.mp4
を指定し、さらに、バイトレンジとして"83597-166046"を指定する。
これらセグメントのデータを放送チャネル上のIPマルチキャストストリーム上のFLUTEで転送されるファイルに格納させる場合、上述の表現形式を放送チャネル上のIPマルチキャストストリームをアドレッシングするように拡張しなければならない。
そのために、セグメントファイル群が転送されるIPマルチキャストストリームを取得するための新たな要素としてチューニングパラメタ（DeliverySystemAttributes）やIPマルチキャストアドレス（IPMulticastAddress）を格納するServiceLocation要素が導入される。つまり、この場合、図１０に示される例のように、このServiceLocation要素をルート要素として格納するserviceLocationファイルのurlを格納するserviceLocationAttribute Url属性がMPDのBaseURLに配置（記述）される。
なお、serviceLocationAttributeUrl属性により指定されるServiceLocationファイルのXML Schemaは、図１１に示される例のように記述される。
図１２は、このように拡張したMPDにおけるServiceLocation要素の構成例を示す図である。
図１２に示されるように、DeliverySystemAttributesTypeのDeliverySystemIdentifierには、MBMSのマルチキャスト配信若しくは放送配信用のストリーム（ブロードキャスト・マルチキャストストリーム）を識別するデータ構造のフォーマットを識別する識別子が格納される。例えば、動画や音楽などのマルチメディアコンテンツを既存ネットワーク、特にW-CDMAをベースとする3G携帯電話網、GSM（登録商標）/EDGEをベースとする2.5G携帯電話網で効率よく配信するための技術である”MBMS”を用いた配信の場合、DeliverySystemIdentifierには、MBMSを示す識別子”ID_MBMS”が格納（記述）される。
また、DeliverySystemAttributesTypeのDeliverySystemDescriptorには、上述したDeliverySystemIdentifierで識別される配信システム毎に規定されたブロードキャスト・マルチキャストストリームを取得するためのパラメタのデータ構造若しくはパラメタそのものが格納（記述）される。
DeliverySystemIdentifierに”ID_MBMS”が格納（記述）される場合、例えば、図１３に示されるような、MBMSにおいて規定される”User Service Description”構造が格納（記述）される。
［FDTの拡張］
次に、FDTの拡張について説明する。上述したServiceLocation/DeliverySystem要素に格納される情報によりMBMSマルチキャストストリーム上に転送されるIPパケットストリームのうち、ServiceLocation/IPMulticastAddress要素で指定されるマルチキャストアドレスを持つIPパケットストリーム上には、FLUTEプロトコルによりファイル群が運ばれるものとする。
図１４はFLUTEプロトコルの階層を示している。FLUTEは、IPパケットストリーム上にファイルを転送するプロトコルであり、図１４に示される例のようなプロトコル階層を有する。なお図１４においては、上述したDeliverySystemAttributesで指定されるMBMSベアラ上にFLUTEのパケットが運ばれる場合を示している。
FLUTEプロトコルでは、FLUTEパケットにより運ばれるファイルのそれぞれに対してファイル属性が記述できるようになっている。ファイル属性はFDT（File Delivery Table）（FDT-Instance要素）に記述される。
図１５は、FDTのデータ構造の例を示している。FDTに必須のファイル属性は以下の３種である。
FDT-Instance/Expires（FDTの有効期限）
FDT-Instance/File/Content-Location（転送するファイルのURL）
FDT-Instance/File/TOI（Transport Object Identifier、FLUTE転送する上で必須の構成チャンク群の識別子）
FLUTEプロトコルでは、同一のTOIを有する全てのファイルが受信された段階で初めて、Content-LocationのURLにより指定されるファイルとしてそれらに対してアクセスが可能となる。したがって、映画などのVoDコンテンツのように再生時間が長く１つのファイルのサイズが非常に大きい場合には、そのファイル全体が受信側で再構成されてアクセスできるようになるまでに、ある程度の時間が必要となる。
これに対して、DASHを利用したストリーミングにおいては、対象のVoDコンテンツのファイルのサイズが大きくても、個々のHTTPリクエストのmediaRange指定によりファイルの一部をセグメント単位で取得し、再生することができる。したがって、放送チャネル上のFLUTE転送されるファイルの単位もこのセグメントの単位で取得し、再生できるようにすることが望ましい。
ただし、現在規定されているFDTのContent-Location要素のみでは、MPDのBaseURL＋SegmentURL mediaRangeのシーケンスのように、ファイルの一部を表現することができない。DASHのMPDのSegmentが、FLUTEで転送されるファイルの一部（ファイルurl+バイトレンジで指定されるバイト列）である場合には、そのバイト列をファイルとして独立させ、そのファイルにURLを割り当て、そのurlと対応するSegmentを対応させる方法も考えられるが、これは、放送配信のために、ネット配信のMPDファイルの構成を変更することとなり、ネット配信目的で生成されたMPDを、放送配信を併用することになった時点で、セグメントファイルの構成変更や、対応するMPDの書き換えが生じるため現実的でない（運用上余計なオーバヘッドが生じる）。そこで、FDTについてもファイルの一部を表現できるように拡張する。
図１６は、拡張したFDTのデータ構造を示している。すなわち、FDTに対して、Content-Locationと、さらにそのContent-Locationのurlで指定されるファイルの中のバイトレンジが指定できるように新たにrange属性を導入する。range属性のシンタクスには、range-specifier(RFC2616.section.14.35.1)の定義を適用する。range属性には、以下のようにHTTPリクエストのrangeヘッダに格納されるrange-specifierにより表現されるものをそのまま格納できるようにする。つまりrange属性には、MPDのPeriod/AdaptationSet/Representation/SegmentList/SegmentURL/@mediaRangeをそのまま流用することができる。
＜適応的な制御＞
ただし、仮に、上述したようにMPDを拡張することにより、マルチキャストやブロードキャストベアラを利用するとしても、マルチキャスト配信やブロードキャスト配信が常に最善という訳ではない。例えば、コンテンツを要求するクライアントが少ない場合や、使用可能なマルチキャスト配信やブロードキャスト配信のリソースが少ない場合等においては、十分なコストメリットを得ることができず、ネットワークリソースの負荷を十分に低減することができないことも考えられた。
そこで、コンテンツの配信をより効率よく行うために、ユニキャスト配信とマルチキャスト配信やブロードキャスト配信とを併用し、各配信の利用をより適応的に制御するようにする。
例えば、DASHアダプティブストリーミングフォーマットのマニフェストファイル（MPD）を収集するMPDコンフィギュレータを用意し、DASHクライアントからの要求量（要求数）に応じて放送チャンネルを割り当て（解放して）、MPDを書き換える（更新する）ようにする。
このようにすることにより、放送配信リソース割り当てを最適に保ちながら、アダプティブストリーミングにおけるストリームスイッチ可能な代替配信パスとしてMBMS等のモバイル放送チャンネルを利用することができる。
＜１．第１の実施の形態＞
＜コンテンツ配信システム＞
図１７は、本技術を適用したコンテンツ供給システムの一実施の形態であるコンテンツ配信システムの主な構成例を示すブロック図である。
図１７に示されるコンテンツ配信システム１００は、サーバからクライアントにコンテンツを供給するシステムである。図１７に示されるように、コンテンツ配信システム１００は、コンテンツ提供システム１１１、配信制御システム１１２、ネットワーク１１３、並びに、DASHクライアント１１４−１およびDASHクライアント１１４−２を有する。コンテンツ配信システム１００は、コンテンツ提供システム１１１からDASHクライアント１１４−１やDASHクライアント１１４−２へコンテンツを伝送するシステムである。
コンテンツ提供システム１１１は、主にコンテンツの提供に関する処理を行うシステムである。コンテンツ提供システム１１１は、DASHクライアント１１４−１やDASHクライアント１１４−２からの要求に応じて、自身が管理するコンテンツを、ネットワーク１１３を介して、要求元であるDASHクライアント１１４−１若しくはDASHクライアント１１４−２に供給する。
配信制御システム１１２は、そのコンテンツの配信方法に関する制御処理を行うシステムである。
ネットワーク１１３は、例えばインターネットやLAN等の、有線若しくは無線、または両方の任意のネットワークよりなる。図１７においては、ネットワーク１１３が１つのネットワークとして示されているが、ネットワーク１１３の構成は任意であり、複数のネットワークにより構成されるようにしてもよい。また、ネットワーク１１３には、どのような機器やシステムが接続されるようにしてもよい。図１７の例の場合、ネットワーク１１３には、コンテンツ提供システム１１１、配信制御システム１１２、並びに、DASHクライアント１１４−１およびDASHクライアント１１４−２が接続される。
DASHクライアント１１４−１やDASHクライアント１１４−２は、それぞれ、ネットワーク１１３に接続され、コンテンツの取得に関する処理を行う。なお、DASHクライアント１１４−１とDASHクライアント１１４−２とを互いに区別して説明する必要がない場合、単にDASHクライアント１１４と称する。図１７においては、２つのDASHクライアント１１４が示されているが、DASHクライアント１１４の数は任意である。
DASHクライアント１１４は、ネットワーク１１３を介して通信を行う通信機能を備え、コンテンツ提供システム１１１から供給される動画像や音声などよりなるコンテンツのストリーミングデータを再生可能な装置であれば、どのようなデバイスであってもよい。例えば、携帯電話機、ノート型のパーソナルコンピュータ、スマートフォン、タブレット型情報処理装置等といった携帯型の端末装置（モバイル機器）であってもよい。DASHクライアント１１４−１とDASHクライアント１１４−２とが互いに異なる種類のデバイスであってももちろんよい。
また、DASHクライアント１１４は、ネットワーク１１３に、有線通信により接続されてもよいし、無線通信により接続されてもよい。
図１７に示されるように、コンテンツ提供システム１１１は、例えば、コンテンツマネジメントサーバ１２１、DASHセグメントストリーマ１２２、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４を有する。
コンテンツマネジメントサーバ１２１は、コンテンツ（例えば、ライブ放送ストリームを含む）の生成・管理を行うサーバである。
DASHセグメントストリーマ１２２は、コンテンツマネジメントサーバ１２１にて管理されるコンテンツからDASHセグメントを生成するサーバである。個々のセグメントは、ファイルとして独立して生成される場合もあれば、ファイルとしては分割されずにファイルURL+rangeで指定される領域として管理される場合もある。ネット配信の場合、DASHセグメントストリーマ１２２は、セグメントを配信するHTTPサーバとなる。
DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２にて管理されるDASHセグメントのurl(+range)とコンテンツマネジメントサーバ１２１にて管理されるコンテンツのメタデータをもとにMPDを生成するサーバである。ネット配信の場合、DASH-MPDサーバ１２３は、MPDを配信するHTTPサーバとなる。放送配信もしくはマルチキャスト配信の場合、DASH-MPDサーバ１２３は、MPDを後述するFLUTEサーバ１３１に送付する。
BC/MCサービスプロバイダ１２４は、後述するDASHクライアントプロキシ１４３から放送配信依頼されたMPDやセグメントを放送配信リソース１５２（例えばMBMSベアラ等）により放送配信するサーバである。図１７に示されるように、BC/MCサービスプロバイダ１２４は、例えば、FLUTEサーバ１３１および放送配信サーバ１３２を有する。
FLUTEサーバ１３１は、DASHセグメントストリーマ１２２にて管理されるDASHセグメントをFLUTEプロトコルにてDASHクライアント１１４にマルチキャストするサーバである。FLUTEサーバ１３１は、拡張されたFDTの生成や、セグメントからFLUTEパケット（ALCパケット等）の生成等を行う。ネット配信の場合、FLUTEサーバ１３１は、生成したFDTやFLUTEパケットをDASHクライアント１１４にマルチキャスト配信するマルチキャストサーバとなる。放送配信の場合、FLUTEサーバ１３１は、生成したFDTやFLUTEパケットを放送配信サーバ１３２に送付する。
放送配信サーバ１３２は、FLUTEサーバ１３１にて生成されるFDTやALCパケット等を放送配信するサーバである。
図１７に示されるように、配信制御システム１１２は、例えば、MPDコンフィギュレータ１４１、BC/MCリソースマネージャ１４２、およびDASHクライアントプロキシ１４３を有する。
MPDコンフィギュレータ１４１は、コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、マルチキャスト配信若しくは放送配信を利用すると判定された場合、コンテンツの供給にそのマルチキャスト配信若しくは放送配信を利用するように、そのコンテンツのユニキャスト配信に関する制御情報を更新する。
より具体的には、MPDコンフィギュレータ１４１は、DASHクライアント１１４から送付された、その制御情報の一例であるMPDをもとに、BC/MCリソースマネージャ１４２に対してマルチキャストリソースを予約・解放し、コンテンツの一例である当該セグメントストリームをマルチキャストチャネルから取得できるように、＜０．概要＞において上述したようにMPDを書き換えてクライアントに送付する。リソースの予約・解放判断は、BC/MCリソース併用のコスト効果計算をもとに行う。
BC/MCリソースマネージャ１４２は、MPDコンフィギュレータ１４１からの依頼を基に、マルチキャストリソースを予約・解放するサーバである。MPDコンフィギュレータ１４１に対してブロードキャスト/マルチキャストリソースの空き状況を報告し、リソース予約・解放要求に応じる。
DASHクライアントプロキシ１４３は、DASHセグメントストリーマ１２２に対して、DASHクライアント１１４としてふるまうプロキシサーバである。MPDコンフィギュレータ１４１により書き換えられたMPDをモニタして、DASHクライアント１１４の代わりにセグメントを取得し、マルチキャスト配信若しくは放送配信（BC/MC）のためのプロトコル変換（HTTP取得からFLUTEマルチキャスト配信への変換）を行い、BC/MCサービスプロバイダ１２４に対してマルチキャスト配信若しくは放送配信を依頼するサーバである。
図１７に示されるように、ネットワーク１１３は、例えば、CDN１５１および放送配信リソース１５２を有する。放送配信リソース１５２は、例えば、MBMSベアラ等よりなる。図１７においては、ネットワーク１１３にCDN１５１と放送配信リソース１５２を１つずつ示しているが、ネットワーク１１３に含まれるCDN１５１や放送配信リソース１５２の数は任意であり、複数であってもよい。
コンテンツ提供システム１１１が上述した以外のサーバ等を有していてももちろんよい。また、図１７においては、コンテンツ提供システム１１１がネットワーク１１３に接続されているように示されているが、実際には、上述した、コンテンツ提供システム１１１を構成する各サーバ（コンテンツマネジメントサーバ１２１乃至BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）等）が、直接的または間接的にネットワーク１１３に接続される。
もちろん、コンテンツ提供システム１１１の構成は任意であり、ネットワーク１１３を介してDASHクライアント１１４に対してコンテンツを配信することができるのであれば、上述した各サーバやその他の機器がどのように互いに接続され、どのようにネットワーク１１３に接続されるようにしてもよい。また、図１７においては、１つずつ示されているが、コンテンツマネジメントサーバ１２１乃至BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）の数は任意であり、複数であってもよい。
配信制御システム１１２が上述した以外のサーバ等を有していてももちろんよい。また、図１７においては、配信制御システム１１２がネットワーク１１３に接続されているように示されているが、実際には、上述した、配信制御システム１１２を構成する各サーバ（MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３等）が、直接的または間接的にネットワーク１１３に接続される。
もちろん、配信制御システム１１２の構成は任意であり、ネットワーク１１３を介したコンテンツ配信を制御することができるのであれば、上述した各サーバやその他の機器がどのように互いに接続され、どのようにネットワーク１１３に接続されるようにしてもよい。また、図１７においては、１つずつ示されているが、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３の数は任意であり、複数であってもよい。
さらに、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、コンテンツ配信側に形成される（すなわち、コンテンツ提供システム１１１を構成する）ようにしてもよい。
また、例えば、ネットワーク１１３が複数のネットワークよりなり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、それらのネットワーク間の中継装置として形成されるようにしてもよい。
さらに、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、ネットワーク１１３を介して行われるコンテンツ配信の所定の一部のみを制御するようにしてもよい。例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、時間的または位置的（領域的）にネットワーク１１３の一部において行われるコンテンツ配信を担当するようにしてもよい。
例えば、DASHクライアント１１４が携帯電話機やスマートフォンのような、公衆無線通信回線の基地局を介してインターネット等に接続するデバイスであり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、その基地局に形成されるようにし、その基地局を介して行われるコンテンツ配信のみを制御するようにしてもよい。
この場合、MPDコンフィギュレータ１４１は、その基地局に接続されるDASHクライアント１１４からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
また、例えば、DASHクライアント１１４が、家庭内や店舗等に設置された無線LANのアクセスポイント（またはフェムトセルの基地局等）を介してインターネット等に接続するデバイスであり、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、そのアクセスポイントに形成されるようにし、そのアクセスポイントを介して行われるコンテンツ配信のみを制御するようにしてもよい。
この場合、MPDコンフィギュレータ１４１は、そのアクセスポイントに接続されるDASHクライアント１１４（つまり、その無線LANに接続されるDASHクライアント１１４）からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
さらに、例えば、MPDコンフィギュレータ１４１は、予め登録された所定のDASHクライアント１１４に対するコンテンツ配信のみを制御するようにしてもよい。つまり、この場合、MPDコンフィギュレータ１４１は、予め登録された所定のDASHクライアント１１４からのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新する。
また、例えば、MPDコンフィギュレータ１４１乃至DASHクライアントプロキシ１４３（若しくはそれらの一部）が、DASHクライアント１１４内に形成されるようにし、そのDASHクライアント１１４において実行される各アプリケーションのコンテンツ配信要求の量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御して、MPDを更新するようにしてもよい。
このようにすることにより、MPDコンフィギュレータ１４１は、ネットワーク１１３全体でなく、その時間的、位置的（領域的）、若しくはクライアント的に一部におけるコンテンツ配信要求量に応じて、マルチキャスト配信若しくは放送配信のリソースの割り当てを適応的に制御することができる。すなわち、局所的に要求量の変動にもより適切に対応することができる。つまり、コンテンツ配信をより効率よく行うようにすることができる。
＜物理的構成＞
次に、コンテンツ配信システム１００を構成する各デバイスの構成例について説明する。図１８は、MPDコンフィギュレータ１４１の物理的な構成例を示すブロック図である。
図１８に示されるように、MPDコンフィギュレータ１４１は、CPU（Central Processing Unit）２０１、ROM（Read Only Memory）２０２、およびRAM（Random Access Memory）２０３を有する。これらのCPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。
バス２０４にはまた、入出力インタフェース２１０も接続されている。入出力インタフェース２１０には、入力部２１１、出力部２１２、記憶部２１３、通信部２１４、およびドライブ２１５が接続されている。
入力部２１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部２１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部２１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部２１４は、例えば、ネットワークインタフェースよりなる。ドライブ２１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア２２１を駆動する。
もちろん、MPDコンフィギュレータ１４１の構成は任意であり、図１８の例に限らない。例えば、MPDコンフィギュレータ１４１が、図１８に示される構成以外の構成を有するようにしてもよい。
なお、コンテンツマネジメントサーバ１２１、DASHセグメントストリーマ１２２、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１および放送配信サーバ１３２）、BC/MCリソースマネージャ１４２、DASHクライアントプロキシ１４３、並びに、DASHクライアント１１４も、それぞれ、MPDコンフィギュレータ１４１と同様の構成を有するものとする。すなわち、以下において、これらのデバイスの物理的な構成について説明する場合、図１８を参照して説明する。もちろん、これらのデバイスの構成も、MPDコンフィギュレータ１４１の場合と同様に任意であり、図１８の例に限らない。MPDコンフィギュレータ１４１を含むこれらのデバイス（または一部のデバイス）が他のデバイスと異なる構成を有するようにしてもよい。
＜機能的構成＞
次に、コンテンツ配信システム１００を構成する各デバイスの機能の例について、図１９乃至図２６を参照して説明する。図１９乃至図２６は、各デバイスが有する機能を説明するための機能ブロック図である。図１９乃至図２６に示される各機能ブロックは、各デバイスのCPU２０１がROM２０２や記憶部２１３から読み出したプログラム等を、適宜RAM２０３等を用いて実行することにより実現される機能を表すものである。
図１９は、DASHセグメントストリーマ１２２が有する主な機能ブロックの構成例を示す図である。図１９に示されるように、DASHセグメントストリーマ１２２は、例えば、DASHセグメント生成部３０１、DASHセグメント管理部３０２、およびDASHセグメント供給部３０３を有する。
DASHセグメント生成部３０１は、DASHセグメントストリーマ１２２の通信部２１４を介して、コンテンツマネジメントサーバ１２１にて管理されるコンテンツデータを取得し、その取得したコンテンツデータからDASHセグメントを生成する。
DASHセグメント管理部３０２は、DASHセグメント生成部３０１により生成されたDASHセグメントを、DASHセグメントストリーマ１２２の記憶部２１３に記憶し、管理する。
DASHセグメント供給部３０３は、DASHセグメントストリーマ１２２の通信部２１４を介して外部（例えば、DASHクライアント１１４、DASHクライアントプロキシ１４３等）から要求された、DASHセグメントストリーマ１２２の記憶部２１３に記憶され、DASHセグメント管理部３０２により管理されているDASHセグメントを読み出し、その読み出したDASHセグメントを、DASHセグメントストリーマ１２２の通信部２１４を介して要求元に供給する。
もちろん、DASHセグメントストリーマ１２２は、任意の機能ブロックを有することができる。例えば、図１９に示される例以外の機能ブロックを有することもできる。
図２０は、FLUTEサーバ１３１が有する主な機能ブロックの構成例を示す図である。図２０に示されるように、FLUTEサーバ１３１は、例えば、プロトコル変換部３１１、MPDマルチキャスト配信部３１２、セグメントマルチキャスト配信部３１３、および放送配信依頼部３１４を有する。
プロトコル変換部３１１は、FLUTEサーバ１３１の通信部２１４を介して外部（例えば、DASHクライアントプロキシ１４３等）から供給されたデータのプロトコルをマルチキャスト配信若しくは放送配信用のプロトコルに変換する。より具体的には、プロトコル変換部３１１は、供給されるDASHプロトコルのデータをFLUTEプロトコルのデータに変換する。例えば、プロトコル変換部３１１は、MPDやDASHセグメントからFDTやFLUTEパケットを生成する。
図２０に示されるように、プロトコル変換部３１１は、例えばFDT生成部３２１およびFLUTEストリーム生成部３２２を有する。
FDT生成部３２１は、＜０．概要＞において上述したように、拡張されたFDTを生成する。
FLUTEストリーム生成部３２２は、＜０．概要＞において上述したようにFLUTEパケットを生成する。
MPDマルチキャスト配信部３１２は、FLUTEサーバ１３１の通信部２１４を介して、MPDをマルチキャスト配信する。つまり、MPDマルチキャスト配信部３１２は、MPDのマルチキャスト配信を行う。その際MPDマルチキャスト配信部３１２は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（マルチキャスト配信用のリソース）を用いて、外部（例えば、DASHクライアント１１４等）に対してMPDのマルチキャスト配信を行う。
セグメントマルチキャスト配信部３１３は、FLUTEサーバ１３１の通信部２１４を介して、DASHセグメントをマルチキャスト配信する。つまり、セグメントマルチキャスト配信部３１３は、プロトコル変換部３１１により生成されたFDTやFLUTEパケットをマルチキャスト配信する。その際セグメントマルチキャスト配信部３１３は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（マルチキャスト配信用のリソース）を用いて外部（例えば、DASHクライアント１１４等）にマルチキャスト配信を行う。
放送配信依頼部３１４は、FDTやFLUTEパケットを放送配信する場合、FLUTEサーバ１３１の通信部２１４を介して、放送配信サーバ１３２に対して放送配信依頼を行う。その際、放送配信依頼部３１４は、放送配信するFDTやFLUTEパケットを放送配信サーバ１３２に供給する。
もちろん、FLUTEサーバ１３１は、任意の機能ブロックを有することができる。例えば、図２０に示される例以外の機能ブロックを有することもできる。
図２１は、放送配信サーバ１３２が有する主な機能ブロックの構成例を示す図である。図２１に示されるように、放送配信サーバ１３２は、例えば、放送配信部３３１を有する。
放送配信部３３１は、外部（例えば、FLUTEサーバ１３１等）より供給された放送配信依頼を放送配信サーバ１３２の通信部２１４を介して取得し、その放送配信依頼にしたがって、同様に供給されたFDTやFLUTEパケットを、放送配信サーバ１３２の通信部２１４を介して外部（例えば、DASHクライアント１１４等）に放送配信する。その際放送配信部３３１は、BC/MCリソースマネージャ１４２により確保された放送配信リソース１５２（放送配信用のリソース）を用いて放送配信を行う。
もちろん、放送配信サーバ１３２は、任意の機能ブロックを有することができる。例えば、図２１に示される例以外の機能ブロックを有することもできる。
図２２は、DASH-MPDサーバ１２３が有する主な機能ブロックの構成例を示す図である。図２２に示されるように、DASH-MPDサーバ１２３は、例えば、MPD生成部３４１、MPD管理部３４２、およびMPD供給部３４３を有する。
MPD生成部３４１は、DASH-MPDサーバ１２３の通信部２１４を介して、DASHセグメントストリーマ１２２において管理されるDASHセグメントのurl（+range）とコンテンツマネジメントサーバ１２１において管理されるコンテンツのメタデータを取得し、それらの情報をもとにMPDを生成する。
MPD管理部３４２は、MPD生成部３４１により生成されたMPDを、DASH-MPDサーバ１２３の記憶部２１３に記憶し、管理する。
MPD供給部３４３は、DASH-MPDサーバ１２３の通信部２１４を介して外部（例えば、DASHクライアント１１４、DASHクライアントプロキシ１４３等）から要求された、DASH-MPDサーバ１２３の記憶部２１３に記憶され、MPD管理部３４２により管理されているMPDを読み出し、その読み出したMPDを、DASH-MPDサーバ１２３の通信部２１４を介して要求元に供給する。
もちろん、DASH-MPDサーバ１２３は、任意の機能ブロックを有することができる。例えば、図２２に示される例以外の機能ブロックを有することもできる。
図２３は、DASHクライアント１１４が有する主な機能ブロックの構成例を示す図である。図２３に示されるように、DASHクライアント１１４は、例えば、MPD要求部３５１、MPD取得部３５２、判定部３５３、MPD供給部３５４、セグメント要求部３５５、セグメント取得部３５６、およびセグメント再生部３５７を有する。
MPD要求部３５１は、DASHクライアント１１４の通信部２１４を介して、外部（例えばDASH-MPDサーバ１２３等）に対してMPDの取得を要求する。
MPD取得部３５２は、DASHクライアント１１４の通信部２１４を介して、MPD要求部３５１がした要求に対して外部（例えば、DASH-MPDサーバ１２３、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されるMPDを取得する。
判定部３５３は、MPD取得部３５２により取得された、DASHクライアント１１４の通信部２１４を介して外部（例えば、DASH-MPDサーバ１２３等）から供給されたMPDに基づいて、受信方法（ユニキャスト配信されるデータを受信する（ユニキャスト受信する）方がよいか、マルチキャスト配信若しくは放送配信されるデータを受信する（マルチキャスト受信する）方がよいか）を判定する。つまり、判定部３５３は、各配信用のリソースの利用可能帯域等を確認することにより、MPDを、DASHクライアント１１４の通信部２１４を介して外部（例えば、MPDコンフィギュレータ１４１等）に供給するか否かを判定する。コンテンツをユニキャスト受信する方がよい場合、MPDを更新する必要がないので、判定部３５３は、MPDを供給しないと判定する。逆に、コンテンツをマルチキャスト受信する方が望ましい場合、MPDを更新する必要があるので、判定部３５３は、MPDを供給すると判定する。
MPD供給部３５４は、判定部３５３によりMPDを供給すると判定された場合、MPD取得部３５２により取得されたMPDを、DASHクライアント１１４の通信部２１４を介して外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
セグメント要求部３５５は、MPD取得部３５２により取得された、DASHクライアント１１４の通信部２１４を介して外部（例えば、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されたMPDに基づいて、ユニキャスト受信する場合、DASHクライアント１１４の通信部２１４を介して、外部（例えば、DASHセグメントストリーマ１２２等）に対してDASHセグメントの取得を要求する。
セグメント取得部３５６は、DASHクライアント１１４の通信部２１４を介して、セグメント要求部３５５がした要求に対して外部（例えば、DASHセグメントストリーマ１２２等）から供給されるDASHセグメントを取得する。また、セグメント取得部３５６は、DASHクライアント１１４の通信部２１４を介して、外部（例えば、BC/MCサービスプロバイダ１２４、DASHクライアントプロキシ１４３等）から供給されるFLUTEパケット等を取得する。
セグメント再生部３５７は、セグメント取得部３５６により取得されたコンテンツデータ（例えば、DASHセグメント、FLUTEパケット等）を再生し、例えば、画像や音声をDASHクライアント１１４の出力部２１２から出力する。
もちろん、DASHクライアント１１４は、任意の機能ブロックを有することができる。例えば、図２３に示される例以外の機能ブロックを有することもできる。
図２４は、MPDコンフィギュレータ１４１が有する主な機能ブロックの構成例を示す図である。図２４に示されるように、MPDコンフィギュレータ１４１は、例えば、MPD取得部３６１、リソース情報要求部３６２、リソース情報取得部３６３、コスト評価部３６４、リソース確保要求部３６５、リソース確保結果通知取得部３６６、MPD更新部３６７、およびMPD供給部３６８を有する。
MPD取得部３６１は、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、DASHクライアント１１４等）から供給されるMPDを取得する。
リソース情報要求部３６２は、リソースの利用状況を確認するために、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、BC/MCリソースマネージャ１４２等）に対して、放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の利用状況を示す情報であるリソース情報を要求する。
リソース情報取得部３６３は、MPDコンフィギュレータ１４１の通信部２１４を介して、リソース情報要求部３６２がした要求に対して外部（例えば、BC/MCリソースマネージャ１４２等）から供給されるリソース情報を取得する。
コスト評価部３６４は、MPD取得部３６１が取得したMPDやリソース情報取得部３６３が取得したリソース情報に基づいて、コンテンツの配信に、マルチキャスト配信や放送配信を利用する場合のコスト（BC/MC併用コストとも称する）を評価する。この場合のコストとは、任意の条件についての評価値を示し、コンテンツ配信の効率の度合いを示す任意のパラメタである。
リソース確保要求部３６５は、コスト評価部３６４によりマルチキャスト配信や放送配信を利用すると判定された場合に、リソース情報に基づいて、利用可能な放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保を、MPDコンフィギュレータ１４１の通信部２１４を介して外部（例えば、BC/MCリソースマネージャ１４２等）に要求する。
リソース確保結果通知取得部３６６は、MPDコンフィギュレータ１４１の通信部２１４を介して、リソース確保要求部３６５がした要求に対して外部（例えば、BC/MCリソースマネージャ１４２等）から供給される、放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保結果の通知を取得する。
MPD更新部３６７は、コスト評価部３６４によりマルチキャスト配信や放送配信を利用すると判定された場合に、MPDを、コンテンツの供給にその放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）を利用するように、＜０．概要＞において上述したように更新する。
MPD供給部３６８は、MPD更新部３６７により更新されたMPD、若しくは、MPD更新部３６７により更新されなかったMPDを、MPDコンフィギュレータ１４１の通信部２１４を介して、外部（例えば、DASHクライアントプロキシ１４３、BC/MCサービスプロバイダ１２４、DASHクライアント１１４等）に供給する。
もちろん、MPDコンフィギュレータ１４１は、任意の機能ブロックを有することができる。例えば、図２４に示される例以外の機能ブロックを有することもできる。
図２５は、BC/MCリソースマネージャ１４２が有する主な機能ブロックの構成例を示す図である。図２５に示されるように、BC/MCリソースマネージャ１４２は、例えば、リソース情報要求取得部３７１、リソース情報生成部３７２、リソース情報供給部３７３、リソース確保要求取得部３７４、リソース確保部３７５、およびリソース確保結果通知部３７６を有する。
リソース情報要求取得部３７１は、BC/MCリソースマネージャ１４２の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給されるリソース情報の要求を取得する。
リソース情報生成部３７２は、リソース情報要求取得部３７１により取得されたリソース情報の要求に応じて、BC/MCリソースマネージャ１４２の通信部２１４を介して放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の利用状況を調査し、リソース情報を生成する。
リソース情報供給部３７３は、リソース情報生成部３７２により生成されたリソース情報を、BC/MCリソースマネージャ１４２の通信部２１４を介して、要求元である外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
リソース確保要求取得部３７４は、BC/MCリソースマネージャ１４２の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給される放送配信リソースの確保の要求を取得する。
リソース確保部３７５は、リソース確保要求取得部３７４により取得された放送配信リソースの確保の要求に応じて、要求された放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）を確保する。
リソース確保結果通知部３７６は、リソース確保部３７５による放送配信リソース１５２（マルチキャスト配信や放送配信用のリソース）の確保結果を、BC/MCリソースマネージャ１４２の通信部２１４を介して、要求元である外部（例えば、MPDコンフィギュレータ１４１等）に供給する。
もちろん、BC/MCリソースマネージャ１４２は、任意の機能ブロックを有することができる。例えば、図２５に示される例以外の機能ブロックを有することもできる。
図２６は、DASHクライアントプロキシ１４３が有する主な機能ブロックの構成例を示す図である。図２６に示されるように、DASHクライアントプロキシ１４３は、例えば、MPD取得部３８１、MPD供給部３８２、セグメント要求部３８３、セグメント取得部３８４、およびFLUTE配信依頼部３８５を有する。
MPD取得部３８１は、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、MPDコンフィギュレータ１４１等）から供給されるMPDを取得する。
MPD供給部３８２は、MPD取得部３８１が取得したMPDを、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、DASHクライアント１１４、BC/MCサービスプロバイダ１２４等）に供給する。
セグメント要求部３８３は、MPD取得部３８１が取得したMPDに基づいて、コンテンツの配信にマルチキャスト配信若しくは放送配信を利用する場合、DASHクライアントプロキシ１４３の通信部２１４を介して、DASHクライアント１１４の代わりに、外部（例えば、DASHセグメントストリーマ１２２等）に、DASHセグメントを要求する。
セグメント取得部３８４は、DASHクライアントプロキシ１４３の通信部２１４を介して、セグメント要求部３８３の要求に応じて外部（例えば、DASHセグメントストリーマ１２２等）から供給されたDASHセグメントを取得する。
FLUTE配信依頼部３８５は、セグメント取得部３８４により取得されたDASHセグメントを、DASHクライアントプロキシ１４３の通信部２１４を介して、外部（例えば、BC/MCサービスプロバイダ１２４等）に供給し、そのDASHセグメントをFLUTE配信（マルチキャスト配信若しくは放送配信）するように依頼する。
もちろん、DASHクライアントプロキシ１４３は、任意の機能ブロックを有することができる。例えば、図２６に示される例以外の機能ブロックを有することもできる。
＜配信制御処理の流れ＞
以上のような機能を有するMPDコンフィギュレータ１４１（図２４）は、配信制御処理を実行して、＜０．概要＞において上述したようにMPDを適宜更新することにより、より効率よく行われるように、コンテンツの配信を制御する。
図２７のフローチャートを参照して、このMPDコンフィギュレータ１４１による配信制御処理の流れの例を説明する。
配信制御処理が開始されると、MPDコンフィギュレータ１４１のMPD取得部３６１は、ステップＳ１０１において、MPDコンフィギュレータ１４１の管理対象となる（配下の）クライアントから供給されるMPDを取得（収集）する。
ステップＳ１０２において、リソース情報要求部３６２がリソース情報を要求し、リソース情報取得部３６３がリソース情報を取得することにより、放送配信リソース１５２（マルチキャスト配信および放送配信用のリソース）が確認される。
ステップＳ１０３において、コスト評価部３６４は、ステップＳ１０１におけるMPDの収集結果（MPDの取得量、すなわち、コンテンツの要求量）や、ステップＳ１０２における確認結果（リソース情報取得部３６３が取得したリソース情報）に応じて、マルチキャスト配信および放送配信利用のコストを評価する。
ステップＳ１０４において、コスト評価部３６４は、ステップＳ１０３の評価結果に基づいて、マルチキャスト配信または放送配信を利用するか否かを判定する。利用すると判定された場合、処理はステップＳ１０５に進む。
ステップＳ１０５において、リソース確保要求部３６５がリソースの確保を要求し、リソース確保結果通知取得部３６６がリソース確保結果の通知を取得することにより、利用可能な放送配信リソース１５２が確保される。
ステップＳ１０６において、MPD更新部３６７は、ステップＳ１０５の処理により確保された放送配信リソース１５２を利用するように、＜０．概要＞において上述したようにMPDを更新する。ステップＳ１０６の処理が終了すると、処理は、ステップＳ１０７に進む。
また、ステップＳ１０４において、マルチキャスト配信または放送配信を利用しないと判定された場合、処理は、ステップＳ１０７に進む。
ステップＳ１０７において、MPD供給部３６８は、MPDをDASHクライアントプロキシ１４３に供給する。
ステップＳ１０７の処理が終了すると、配信制御処理が終了する。MPDコンフィギュレータ１４１は、このような配信制御処理を実行することにより、コンテンツの配信をより効率よく行うようにすることができる。また、MPDコンフィギュレータ１４１は、このような配信制御処理を繰り返し実行する。これにより、MPDコンフィギュレータ１４１は、常に、コンテンツの配信をより効率よく行うようにすることができる。例えば、MPDコンフィギュレータ１４１は、配信中のコンテンツについてもこのような配信制御処理を実行する。これにより、MPDコンフィギュレータ１４１は、コンテンツ配信中であっても、適応的に配信方法を制御することができ、より効率よくコンテンツ配信を行うことができる。
＜DASHクライアントプロキシ処理の流れ＞
以上のような機能を有するDASHクライアントプロキシ１４３（図２６）は、DASHクライアント１１４の代わりに、MPDコンフィギュレータ１４１による配信制御処理に対応して、DASHクライアントプロキシ処理を実行する。これにより、DASHクライアントプロキシ１４３は、MPDコンフィギュレータ１４１の配信制御に応じた、より効率のよいコンテンツの配信を実現する。
図２８のフローチャートを参照して、このDASHクライアントプロキシ１４３によるDASHクライアントプロキシ処理の流れの例を説明する。
DASHクライアントプロキシ処理が開始されると、MPD供給部３８２は、ステップＳ１２１において、MPD取得部３８１が取得したMPD（MPDコンフィギュレータ１４１により供給されたMPD）に基づいて、マルチキャスト配信若しくは放送配信を利用するか否かを判定する。利用すると判定された場合、処理はステップＳ１２２に進む。
ステップＳ１２２において、MPD供給部３８２は、MPD取得部３８１が取得したMPDをBC/MCサービスプロバイダ１２４に供給し、そのMPDをDASHクライアント１１４に対して周期的に配信させる。
ステップＳ１２３において、セグメント要求部３８３は、DASHセグメントストリーマ１２２に対してDASHセグメントの取得を要求する。
ステップＳ１２４において、セグメント取得部３８４は、ステップＳ１２３における要求に応じて供給されるDASHセグメントを取得する。
ステップＳ１２５において、FLUTE配信依頼部３８５は、ステップＳ１２４において取得したDASHセグメントをBC/MCサービスプロバイダ１２４に供給し、FLUTE配信依頼をする。つまり、この場合、コンテンツは、BC/MCサービスプロバイダ１２４からDASHクライアント１１４に対してマルチキャスト配信若しくは放送配信される。
ステップＳ１２５の処理が終了すると、DASHクライアントプロキシ処理が終了する。
また、ステップＳ１２１において、マルチキャスト配信若しくは放送配信を利用しないと判定された場合、処理はステップＳ１２６に進む。
ステップＳ１２６において、MPD供給部３８２は、MPD取得部３８１が取得したMPDをDASHクライアント１１４に供給する。この場合、DASHクライアント１１４が、DASHセグメントストリーマ１２２にDASHセグメントを要求し、取得する。つまり、この場合、コンテンツは、ユニキャスト配信される。
ステップＳ１２６の処理が終了すると、DASHクライアントプロキシ処理が終了する。
以上のようにすることにより、DASHクライアントプロキシ１４３は、MPDコンフィギュレータ１４１の配信制御に応じた、より効率のよいコンテンツの配信を実現することができる。
なお、配信制御処理が上述したように繰り返し実行される場合、このDASHクライアントプロキシ処理も、それに対応して繰り返し実行される。また、配信制御処理が上述したようにコンテンツ配信中に実行される場合、このDASHクライアントプロキシ処理も、それに対応してコンテンツ配信中に実行される。
＜コンテンツ配信処理の流れ＞
以上のようなコンテンツ配信システム１００により行われるコンテンツの配信の例を、図２９乃至図３１のフローチャートを参照して説明する。
コンテンツ配信システム１００によりコンテンツ配信処理が開始されると、DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２が管理するコンテンツについて、MPD生成部３４１がMPDを生成し（ステップＳ２１１）、MPD管理部３４２がそのMPDを管理する。
コンテンツの配信を要求するユーザに操作されたDASHクライアント１１４のMPD要求部３５１は、所望のコンテンツのMPDの取得を、DASH-MPDサーバ１２３に対して要求する（ステップＳ２６１）。
DASH-MPDサーバ１２３のMPD供給部３４３は、その要求を受け取ると（ステップＳ２１２）、要求されたMPDを要求元であるDASHクライアント１１４に供給する（ステップＳ２１３）。
DASHクライアント１１４のMPD取得部３５２がそのMPDを受け取ると（ステップＳ２６２）、判定部３５３は、帯域をモニタリングし、ユニキャスト受信が不安定になりそうか否か、並びに、マルチキャストが受信可能なデバイスであるか否か等により、コンテンツの受信方法、すなわち、MPDを送信するか否かを判定する（ステップＳ２６３）。
ユニキャスト受信が不安定になりそうであり、かつ、マルチキャストが受信可能である場合、判定部３５３は、MPDを送信すると判定し、MPD供給部３５４は、MPDをMPDコンフィギュレータ１４１に供給する（ステップＳ２６４）。
MPDコンフィギュレータ１４１のMPD取得部３６１がそのMPDを取得すると（ステップＳ２２１）、リソース情報要求部３６２は、BC/MCリソースマネージャ１４２に対してリソース情報を要求する（ステップＳ２２２）。
BC/MCリソースマネージャ１４２のリソース情報要求取得部３７１がその要求を取得すると（ステップＳ２３１）、リソース情報生成部３７２がリソース情報を生成し（ステップＳ２３２）、リソース情報供給部３７３がそのリソース情報を、要求元であるMPDコンフィギュレータ１４１に供給する（ステップＳ２３３）。
MPDコンフィギュレータ１４１のリソース情報取得部３６３がそのリソース情報を取得すると（ステップＳ２２３）、コスト評価部３６４は、BC/MC併用コストを評価し、マルチキャスト配信若しくは放送配信を利用するか否かを判定する（ステップＳ２２４）。
ここで、マルチキャスト配信若しくは放送配信を利用すると判定されたとする。その場合、リソース確保要求部３６５は、リソース情報に基づいて利用可能なBC/MCリソース（放送配信リソース１５２）の確保を、BC/MCリソースマネージャ１４２に対して要求する（ステップＳ２２５）。
BC/MCリソースマネージャ１４２のリソース確保要求取得部３７４がその要求を取得すると（ステップＳ２３４）、リソース確保部３７５が、要求された放送配信リソース１５２を確保し（ステップＳ２３５）、リソース確保結果通知部３７６が、リソース確保結果を、要求元であるMPDコンフィギュレータ１４１に通知する（ステップＳ２３６）。
MPDコンフィギュレータ１４１のリソース確保結果通知取得部３６６がそのリソース確保結果を取得すると（ステップＳ２２６）、MPD更新部３６７が、＜０．概要＞において上述したようにMPDを書き換えて（ステップＳ２２７）、MPD供給部３６８が、更新されたMPDをDASHクライアントプロキシ１４３に供給する（ステップＳ２２８）。
DASHクライアントプロキシ１４３のMPD取得部３８１がそのMPDを取得すると（ステップＳ２４１）、MPD供給部３８２は、そのMPDを、マルチキャスト配信若しくは放送配信を利用しない場合、DASHクライアント１１４に供給し、マルチキャスト配信若しくは放送配信を利用する場合、BC/MCサービスプロバイダ１２４に供給する（ステップＳ２４２）。
BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１）のMPDマルチキャスト配信部３１２は、そのMPDを取得すると（ステップＳ２５１）、取得したMPDを、DASHクライアント１１４に対して、周期的に（つまり複数回繰り返し）マルチキャスト配信する（ステップＳ２５２）。
DASHクライアント１１４のMPD取得部３５２は、DASHクライアントプロキシ１４３から供給されるMPD、若しくは、BC/MCサービスプロバイダ１２４から周期的にマルチキャスト配信されるMPDを取得する（ステップＳ２６６）。
ここで、MPD取得部３５２により取得されたMPDにおいて、マルチキャスト配信若しくは放送配信を利用しないようになされている場合、つまり、ユニキャスト配信によりDASHセグメントを取得する場合、処理は、図３０に進む。
この場合、DASHクライアント１１４のセグメント要求部３５５は、MPDの情報に基づいて、DASHセグメントストリーマ１２２に対して、所望のDASHセグメントの取得を要求する（ステップＳ２６７）。
DASHセグメントストリーマ１２２のDASHセグメント供給部３０３は、その要求を取得すると（ステップＳ２０１）、要求されたDASHセグメントを、要求元であるDASHクライアント１１４に供給（ユニキャスト配信）する（ステップＳ２０２）。
DASHクライアント１１４のセグメント取得部３５６が、そのユニキャスト配信されたDASHセグメントを取得すると（ステップＳ２６８）、セグメント再生部３５７は、そのDASHセグメントを再生する（ステップＳ２６９）。
また、図２９のステップＳ２６６においてMPD取得部３５２により取得されたMPDにおいて、マルチキャスト配信若しくは放送配信を利用するようになされている場合、つまり、マルチキャスト配信若しくは放送配信によりDASHセグメントを取得する場合、処理は、図３１に進む。
この場合、DASHクライアント１１４の代わりに、DASHクライアントプロキシ１４３のセグメント要求部３８３は、MPDの情報に基づいて、DASHセグメントストリーマ１２２に対して、所望のDASHセグメントの取得を要求する（ステップＳ２４３）。
DASHセグメントストリーマ１２２のDASHセグメント供給部３０３は、その要求を取得すると（ステップＳ２０３）、要求されたDASHセグメントを、要求元であるDASHクライアントプロキシ１４３に供給する（ステップＳ２０４）。
DASHクライアントプロキシ１４３のセグメント取得部３８４が、そのDASHセグメントを取得すると（ステップＳ２４４）、FLUTE配信依頼部３８５は、BC/MCサービスプロバイダ１２４に対してそのDASHセグメントを供給し、配信依頼を行う（ステップＳ２４５）。
BC/MCサービスプロバイダ１２４（FLUTEサーバ１３１）のプロトコル変換部３１１は、そのDASHセグメントを取得すると（ステップＳ２５３）、取得したDASHセグメントをマルチキャストプロトコル（例えば、FLUTEプロトコル等）に変換する（ステップＳ２５４）。
マルチキャスト配信を行う場合、セグメントマルチキャスト配信部３１３は、そのプロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、DASHクライアント１１４に対してマルチキャスト配信する（ステップＳ２５５）。
なお、ここで、放送配信を行う場合、放送配信依頼部３１４は、プロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、放送配信サーバ１３２に供給し、放送配信依頼する。これを受けて、放送配信サーバ１３２の放送配信部３３１は、プロトコル変換されたDASHセグメント（FDTやFLUTEパケット）を、DASHクライアント１１４に対して放送配信する。
DASHクライアント１１４のセグメント取得部３５６が、このようにマルチキャスト配信（若しくは放送配信）されたセグメント（FDTやFLUTEパケット）を取得し（ステップＳ２７０）、セグメント再生部３５７が、そのセグメント（FDTやFLUTEパケット）を再生する（ステップＳ２７１）。
以上のようなコンテンツ配信処理を行うことにより、コンテンツ配信システム１００は、より効率よくコンテンツ配信を行うことができる。
＜２．第２の実施の形態＞
＜コンテンツ配信システム＞
なお、第１の実施の形態においては、MPDコンフィギュレータ１４１が、DASHクライアント１１４から供給されるMPDを収集するように説明したが、MPDの送付元はどこであってもよく、これに限らない。例えば、DASH-MPDサーバ１２３等のコンテンツ提供システム１１１側のデバイスから供給されるようにしてもよい。また、例えば、DASH-MPDサーバ１２３の代わりに処理を行うプロキシサーバを設けるようにし、そのプロキシサーバからMPDが供給されるようにしてもよい。
図３２は、本技術を適用したコンテンツ供給システムの一実施の形態であるコンテンツ配信システムの主な構成例を示すブロック図である。
図３２に示されるコンテンツ配信システム４００は、コンテンツ配信システム１００（図１７）と同様のシステムである。コンテンツ配信システム４００は、コンテンツ配信システム１００の構成に加え、配信制御システム１１２の構成として、プロキシサーバ４４１を有する。
プロキシサーバ４４１は、ネット上のマルチキャスト、もしくは、放送により配信されるFLUTE上のファイルを展開（キャッシュ）して、DASHクライアント１１４に対してDASH-MPDサーバ１２３若しくはDASHセグメントストリーマ１２２としてふるまうサーバである。
＜物理的構成＞
このプロキシサーバ４４１も、MPDコンフィギュレータ１４１と同様の構成を有するものとする。すなわち、以下において、プロキシサーバ４４１のデバイスの物理的な構成について説明する場合、図１８を参照して説明する。
＜機能的構成＞
図３３は、プロキシサーバ４４１が有する主な機能ブロックの構成例を示す図である。図３３に示されるように、プロキシサーバ４４１は、例えば、MPD要求部４５１、MPD取得部４５２、MPD供給部４５３、セグメント取得部４５４、およびセグメント供給部４５５を有する。
MPD要求部４５１は、プロキシサーバ４４１の通信部２１４を介して、外部（例えば、DASHクライアント１１４等）からMPD取得要求を取得し、その要求に基づいて、外部（例えば、DASH-MPDサーバ１２３等）に対してMPDの取得を要求する。
MPD取得部４５２は、プロキシサーバ４４１の通信部２１４を介して、MPD要求部４５１がした要求に対して外部（例えば、DASH-MPDサーバ１２３、FLUTEサーバ１３１、放送配信（MBMS）サーバ１３２、MPDコンフィギュレータ１４１等）から供給されるMPDを取得する。
MPD供給部４５３は、プロキシサーバ４４１の通信部２１４を介して、MPD取得部４５２により取得されたMPDを、外部（例えば、MPDコンフィギュレータ１４１、DASHクライアント１１４等）に供給する。
セグメント取得部４５４は、プロキシサーバ４４１の通信部２１４を介して、外部（例えば、FLUTEサーバ１３１、放送配信（MBMS）サーバ１３２等）から供給されるセグメント（FDTやFLUTEパケット）を取得する。
セグメント供給部４５５は、プロキシサーバ４４１の通信部２１４を介して、セグメント取得部４５４により取得されたセグメント（FDTやFLUTEパケット）を、外部（例えば、DASHクライアント１１４等）に供給する。
もちろん、プロキシサーバ４４１は、任意の機能ブロックを有することができる。例えば、図３３に示される例以外の機能ブロックを有することもできる。
＜コンテンツ配信処理の流れ＞
以上のようなコンテンツ配信システム４００（図３２）により行われるコンテンツの配信の例を、図３４乃至図３６のフローチャートを参照して説明する。
コンテンツ配信システム４００によりコンテンツ配信処理の場合も、DASH-MPDサーバ１２３は、DASHセグメントストリーマ１２２が管理するコンテンツについて、MPD生成部３４１がMPDを生成し（ステップＳ４１１）、MPD管理部３４２がそのMPDを管理する。
ただし、DASHクライアント１１４からのMPD要求（ステップＳ４７１）は、プロキシサーバ４４１を介してDASH-MPDサーバ１２３に供給される。つまり、プロキシサーバ４４１のMPD要求部４５１が、DASHクライアント１１４からのMPD要求を取得し（ステップＳ４２１）、それをDASH-MPDサーバ１２３に供給する（ステップＳ４２２）。
したがって、この場合、DASH-MPDサーバ１２３のMPD供給部３４３は、プロキシサーバ４４１を介して供給された要求を受け取ると（ステップＳ４１２）、要求されたMPDをプロキシサーバ４４１に供給する（ステップＳ４１３）。
プロキシサーバ４４１のMPD取得部４５２は、そのMPDを取得すると（ステップＳ４２３）、それをMPDコンフィギュレータ１４１に供給する（ステップＳ４２４）。
つまり、この場合、MPDコンフィギュレータ１４１には、MPDが、プロキシサーバ４４１から供給される。すなわち、この場合、DASHクライアント１１４がMPDをMPDコンフィギュレータ１４１に供給しなくても、MPDコンフィギュレータ１４１によるコンテンツの配信方法の制御が行われる。
MPDコンフィギュレータ１４１は、ステップＳ４３１乃至ステップＳ４３７の各処理を、ステップＳ２２１乃至ステップＳ２２７の各処理（図２９）と同様に行い、BC/MCリソースマネージャ１４２は、ステップＳ４４１乃至ステップＳ４４６の各処理を、ステップＳ２３１乃至ステップＳ２３６の各処理と同様に行い、配信方法を決定し、必要に応じてMPDを更新する。
この場合、MPDコンフィギュレータ１４１のMPD供給部３６８は、MPDをプロキシサーバ４４１に供給する（ステップＳ４３８）。
プロキシサーバ４４１のMPD取得部４５２がそのMPDを取得すると（ステップＳ４２５）、MPD供給部４５３が、そのMPDをDASHクライアントプロキシ１４３に供給する（ステップＳ４２６）。
これ以降の処理は、第１の実施の形態の場合と同様である。
すなわち、DASHクライアントプロキシ１４３は、ステップＳ４５１およびステップＳ４５２の各処理を、ステップＳ２４１およびステップＳ２４２の各処理（図２９）と同様に行い、BC/MCサービスプロバイダ１２４は、ステップＳ４６１およびステップＳ４６２の各処理を、ステップＳ２５１およびステップＳ２５２の各処理（図２９）と同様に行い、DASHクライアント１１４は、ステップＳ４７２乃至ステップＳ４７３の各処理を、ステップＳ２６３、ステップＳ２６５、およびステップＳ２６６の各処理（図２９）と同様に行う。ただし、この場合DASHクライアント１１４は、ステップＳ４７２若しくはステップＳ４７３においてMPDを取得するので、ステップＳ４７４において受信方法の判定を行う。
図３４においてユニキャスト受信が選択された場合、処理は、図３５に進む。すなわち、DASHセグメントストリーマ１２２は、ステップＳ４０１およびステップＳ４０２の各処理を、ステップＳ２０１およびステップＳ２０２の各処理（図３０）と同様に行う。また、DASHクライアント１１４は、ステップＳ４７５乃至ステップＳ４７７の各処理を、ステップＳ２６７乃至ステップＳ２６９の各処理（図３０）と同様に行う。
図３４においてマルチキャスト受信（若しくは放送受信）が選択された場合、処理は、図３６に進む。すなわち、DASHセグメントストリーマ１２２は、ステップＳ４０３およびステップＳ４０４の各処理を、ステップＳ２０３およびステップＳ２０４の各処理（図３１）と同様に行う。
また、DASHクライアントプロキシ１４３は、ステップＳ４５３乃至ステップＳ４５５の各処理を、ステップＳ２４３乃至ステップＳ２４５の各処理（図３１）と同様に行う。
さらに、BC/MCサービスプロバイダ１２４は、ステップＳ４６３乃至ステップＳ４６５の各処理を、ステップＳ２５３乃至ステップＳ２５５の各処理（図３１）と同様に行う。
また、DASHクライアント１１４は、ステップＳ４７８およびステップＳ４７９の各処理を、ステップＳ２７０およびステップＳ２７１の各処理（図３１）と同様に行う。
以上のようなコンテンツ配信処理を行うことにより、コンテンツ配信システム４００も、より効率よくコンテンツ配信を行うことができる。
＜３．第３の実施の形態＞
＜MPDおよびストリームの伝送＞
本実施の形態においては、第１の実施の形態や第２の実施の形態において説明したMPDやストリームの伝送の流れの例についてさらに説明する。
コンテンツマネジメントサーバ１２１にて管理されるコンテンツからDASHセグメントストリーマ１２２におけるDASHストリームセグメント生成、DASH-MPDサーバ１２３によるDASH-MPD生成までの処理の流れと、DASHセグメントストリーマ１２２において生成されたストリームセグメントならびにストリームセグメントurlからFLUTEサーバ１３１におけるFLUTEのFDTとFLUTEストリームの生成に至る処理の流れの例を、図３７のフローチャートを参照して説明する。
DASH-MPDサーバ１２３は、ステップＳ５１１乃至ステップＳ５１３の各処理を、ステップＳ２１１乃至ステップＳ２１３の各処理（図２９）と同様に行う。また、この例の場合、DASHクライアントプロキシ１４３のMPD取得部３８１が、DASHクライアント１１４の代わりに、ステップＳ５４１およびステップＳ５４２の各処理を、ステップＳ２６１およびステップＳ２６２の各処理（図２９）と同様に行う。
MPDを取得すると、DASHセグメントストリーマ１２２は、ステップＳ５０１およびステップＳ５０２の各処理を、ステップＳ２０３およびステップＳ２０４の各処理（図３１）と同様に行う。これに対して、DASHクライアントプロキシ１４３のセグメント要求部３８３は、ステップＳ５４３およびステップＳ５４４の各処理を、ステップＳ２４３およびステップＳ２４４（図３１）と同様に行う。
ユニキャスト配信が利用される場合、DASHセグメントストリーマ１２２は、ステップＳ５０３において、DASHセグメントをHTTP配信する。
また、マルチキャスト配信若しくは放送配信を利用する場合、DASHクライアントプロキシ１４３のFLUTE配信依頼部３８５は、ステップＳ５４５の処理を、ステップＳ２４５の処理（図３１）と同様に行う。つまり、DASHクライアントプロキシ１４３は、BC/MCサービスプロバイダ１２４のFLUTEサーバ１３１に対してFLUTE配信依頼要求を行う。
FLUTEサーバ１３１のプロトコル変換部３１１がそのFLUTE配信依頼要求を取得すると（ステップＳ５２１）、FDT生成部３２１がFDTを生成し（ステップＳ５２２）、FLUTEストリーム生成部３２２がFLUTEストリーム（FLUTEパケット等）を生成する（ステップＳ５２３）。
放送配信を行う場合は、放送配信依頼部３１４が、放送配信（MBMS）サーバ１３２に対して、そのFDTやFLUTEパケット等を供給し、放送配信依頼を行う（ステップＳ５２４）。放送配信（MBMS）サーバ１３２の放送配信部３３１は、その依頼を受け取ると（ステップＳ５３２）、その依頼に基づいて、FDTやFLUTEパケットを放送配信する（ステップＳ５３２）。
マルチキャスト配信する場合は、FLUTEサーバ１３１のセグメントマルチキャスト配信部３１３が、FDTやFLUTEパケット等をマルチキャスト配信する（ステップＳ５２５）。
次に、ユニキャスト配信の場合の、MPD配信、クライアント主導のストリームセグメント取得・再生の処理の流れを、図３８のフローチャートを参照して説明する。
この場合、DASHクライアント１１４は、ステップＳ５７１乃至ステップＳ５７５の各処理を、ステップＳ２６１およびステップＳ２６２（図２９）、並びに、ステップＳ２６７乃至ステップＳ２６９（図３０）の各処理と同様に行う。
また、DASH-MPDサーバ１２３は、ステップＳ５６１およびステップＳ５６２の各処理を、ステップＳ２１２およびステップＳ２１３の各処理（図２９）と同様に行う。
そして、DASHセグメントストリーマ１２２は、ステップＳ５５１およびステップＳ５５２の各処理を、ステップＳ２０１およびステップＳ２０２の各処理（図３０）と同様に行う。
次に、マルチキャスト配信若しくは放送配信の場合の、MPD配信、クライアント受動のストリームセグメント受信・再生の処理の流れを、図３９のフローチャートを参照して説明する。
この場合、DASHクライアント１１４は、ステップＳ６１１およびステップＳ６１２の各処理を、ステップＳ５７１およびステップＳ５７２の各処理（図３８）と同様に行う。これに対応して、DASH-MPDサーバ１２３は、ステップＳ５８１およびステップＳ５８２の各処理を、ステップＳ５６１およびステップＳ５６２の各処理（図３８）と同様に行う。
マルチキャスト配信の場合、FLUTEサーバ１３１が、セグメントをマルチキャスト配信する（ステップＳ５９１）。放送配信の場合、放送配信（MBMS）サーバ１３２に対する放送配信依頼となる。その場合、放送配信（MBMS）サーバ１３２は、その依頼（セグメント）を取得し（ステップＳ６０１）、放送配信する（ステップＳ６０２）。
DASHクライアント１１４は、マルチキャスト配信の場合、FLUTEサーバ１３１から供給されるセグメントを取得し（ステップＳ６１３）、放送配信の場合、放送配信（MBMS）サーバ１３２から供給されるセグメントを取得する（ステップＳ６１４）。
DASHクライアント１１４は、このように取得したセグメントを再生する（ステップＳ６１５）。
なお、上述したストリームセグメントのマルチキャストは、ストリームセグメントが生成されると同時に行われるようにしてもよい。その場合の処理の流れの例を、図４０のフローチャートを参照して説明する。
この場合、図３９と処理順が異なるのみで同様の処理が行われる。
つまり、FLUTEサーバ１３１が、ステップＳ６３１の処理をステップＳ５９１の処理と同様に行い、放送配信（MBMS）サーバ１３２が、ステップＳ６４１およびステップＳ６４２の各処理を、ステップＳ６０１およびステップＳ６０２の各処理と同様に行い、DASHクライアント１１４が、ステップＳ６５１の処理をステップＳ６１３と同様に行うか、若しくは、ステップＳ６５２の処理をステップＳ６１４と同様に行う。
そして、DASHクライアント１１４が、ステップＳ６５３およびステップＳ６５４の各処理を、ステップＳ６１１およびステップＳ６１２と同様に行い、DASH-MPDサーバ１２３が、ステップＳ６２１およびステップＳ６２２の各処理を、ステップＳ５８１およびステップＳ５８２の各処理と同様に行う。
そして、DASHクライアント１１４が、ステップＳ６５５の処理を、ステップＳ６１５の処理と同様に行う。
このような手順によりコンテンツの配信を行うこともできる。
なお、MPD配信もFLUTEにより放送(マルチキャスト)配信で行うこともできる。その場合の処理の流れの例を、図４１のフローチャートを参照して説明する。
この場合、DASH-MPDサーバ１２３は、MPDをFLUTEサーバ１３１に供給する（ステップＳ６６１）。
FLUTEサーバ１３１は、そのMPDを取得すると（ステップＳ６７１）、そのMPDをマルチキャスト配信する（ステップＳ６７２）。なお、MPDを放送配信する場合は、この処理が、放送配信（MBMS）サーバ１３２に対する放送配信依頼となる。その場合、放送配信（MBMS）サーバ１３２は、その依頼（セグメント）を取得し（ステップＳ６８１）、放送配信する（ステップＳ６８２）。
DASHクライアント１１４は、マルチキャスト配信の場合、FLUTEサーバ１３１から供給されるMPDを取得し（ステップＳ６９１）、放送配信の場合、放送配信（MBMS）サーバ１３２から供給されるMPDを取得する（ステップＳ６９２）。
セグメントの配信については、図３９の場合と同様に行われる。
すなわち、FLUTEサーバ１３１が、ステップＳ６７３の処理をステップＳ５９１の処理と同様に行い、放送配信（MBMS）サーバ１３２が、ステップＳ６８３およびステップＳ６８４の各処理を、ステップＳ６０１およびステップＳ６０２の各処理と同様に行い、DASHクライアント１１４が、ステップＳ６９３乃至ステップＳ６９５の各処理をステップＳ６１３乃至ステップＳ６１５の各処理と同様に行う。
このような手順によりMPDの配信を行うこともできる。
図４１のフローチャートの場合の処理を、第２の実施の形態にも適用することができる。その場合の処理の流れの例を、図４２のフローチャートを参照して説明する。
この場合、DASH-MPDサーバ１２３、FLUTEサーバ１３１、および放送配信（MBMS）サーバ１３２は、図４１の場合と同様に各処理を実行する。つまり、DASH-MPDサーバ１２３は、ステップＳ７０１の処理を、ステップＳ６６１の処理と同様に行い、FLUTEサーバ１３１は、ステップＳ７１１乃至ステップＳ７１３の各処理を、ステップＳ６７１乃至ステップＳ６７３の各処理と同様に行い、放送配信（MBMS）サーバ１３２は、ステップＳ７２１乃至ステップＳ７２４の各処理を、ステップＳ６８１乃至ステップＳ６８４の各処理と同様に行う。
ただし、図４２の場合、MPDやセグメントの配信先は、DASHクライアント１１４ではなく、プロキシサーバ４４１である。プロキシサーバ４４１は、ステップＳ７３１若しくはステップＳ７３２において、MPDを取得し、ステップＳ７３３若しくはステップＳ７３４において、セグメントを取得する。
DASHクライアント１１４は、このようにプロキシサーバ４４１によりキャッシュされたMPDやセグメントを取得する。
つまり、DASHクライアント１１４は、プロキシサーバ４４１に対して、MPDの取得を要求し（ステップＳ７４１）、その要求に応じて供給されたMPDを取得する（ステップＳ７４２）。プロキシサーバ４４１は、DASHクライアント１１４からのMPD取得要求を受け取ると（ステップＳ７３５）、要求されたMPDを要求元であるDASHクライアント１１４に供給する（ステップＳ７３６）。
また、DASHクライアント１１４は、プロキシサーバ４４１に対して、セグメントの取得を要求し（ステップＳ７４３）、その要求に応じて供給されたセグメントを取得する（ステップＳ７４４）。プロキシサーバ４４１は、DASHクライアント１１４からのセグメントの要求を受け取ると（ステップＳ７３７）、要求されたセグメントを要求元であるDASHクライアント１１４に供給する（ステップＳ７３８）。
セグメントを取得したDASHクライアント１１４は、そのセグメントを再生する（ステップＳ７４５）。
以上のように、プロキシサーバ４４１を介してMPDやセグメントを配信することもできる。
以上においては、DASHのストリームを配信する場合について説明したが、本技術は、DASH以外の任意のコンテンツ配信技術に適用することができる。
また、上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、例えば、図１８に示されるような構成のコンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
図１８のように構成されるコンピュータでは、CPU２０１が、例えば、記憶部２１３に記憶されているプログラムを、入出力インタフェース２１０およびバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
コンピュータ（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２２１に記録して適用することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
コンピュータでは、プログラムは、リムーバブルメディア２２１をドライブ２１５に装着することにより、入出力インタフェース２１０を介して、記憶部２１３にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２１４で受信し、記憶部２１３にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２１３に、あらかじめインストールしておくことができる。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
なお、本技術は以下のような構成も取ることができる。
（１） コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
を備える情報処理装置。
（２） 前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する
（１）、（３）乃至（１７）のいずれかに記載の情報処理装置。
（３） 前記制御情報を受け取る受け取り部をさらに備え、
前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する
（１）、（２）、（４）乃至（１７）のいずれかに記載の情報処理装置。
（４） 前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価する
（１）乃至（３）、（５）乃至（１７）のいずれかに記載の情報処理装置。
（５） 前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取る
（１）乃至（４）、（６）乃至（１７）のいずれかに記載の情報処理装置。
（６） 前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取る
（１）乃至（５）、（７）乃至（１７）のいずれかに記載の情報処理装置。
（７） マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、
前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価する
（１）乃至（６）、（８）乃至（１７）のいずれかに記載の情報処理装置。
（８） 前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、
前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新する
（１）乃至（７）、（９）乃至（１７）のいずれかに記載の情報処理装置。
（９） 前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記制御情報は、MPD（Media Presentation Description）である
（１）乃至（８）、（１０）乃至（１７）のいずれかに記載の情報処理装置。
（１０） 前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納する
（１）乃至（９）、（１１）乃至（１７）のいずれかに記載の情報処理装置。
（１１） 前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納する
（１）乃至（１０）、（１２）乃至（１７）のいずれかに記載の情報処理装置。
（１２） 前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備える
（１）乃至（１１）、（１３）乃至（１７）のいずれかに記載の情報処理装置。
（１３） 前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、
前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備える
（１）乃至（１２）、（１４）乃至（１７）のいずれかに記載の情報処理装置。
（１４） 前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルである
（１）乃至（１３）、（１５）乃至（１７）のいずれかに記載の情報処理装置。
（１５） 前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入する
（１）乃至（１４）、（１６）、（１７）のいずれかに記載の情報処理装置。
（１６） 前記更新部により更新された前記制御情報を供給する供給部をさらに備える
（１）乃至（１５）、（１７）のいずれかに記載の情報処理装置。
（１７） クライアントの代わりに前記コンテンツを取得し、前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備える
（１）乃至（１６）のいずれかに記載の情報処理装置。
（１８） コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
情報処理方法。
（１９） コンピュータを、
コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
して機能させるプログラム。
（２０） サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、
前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
コンテンツ供給システム。
１００ コンテンツ配信システム， １１１ コンテンツ提供システム， １１２ 配信制御システム， １１３ ネットワーク， １１４ DASHクライアント， １２１ コンテンツマネジメントサーバ， １２２ DASHセグメントストリーマ， １２３ DASH-MPDサーバ， １２４ BC/MCサービスプロバイダ， １３１ FLUTEサーバ， １３２ 放送配信サーバ， １４１ MPDコンフィギュレータ， １４２ BC/MCリソースマネージャ， １４３ DASHクライアントプロキシ， ３６１ MPD取得部， ３６２ リソース情報要求部， ３６３ リソース情報取得部， ３６４ コスト評価部， ３６５ リソース確保要求部， ３６６ リソース確保結果通知取得部， ３６７ MPD更新部， ３６８ MPD供給部， ３７１ リソース情報要求取得部， ３７２ リソース情報生成部， ３７３ リソース情報供給部， ３７４ リソース確保要求取得部， ３７５ リソース確保部， ３７６ リソース確保結果通知部， ３８１ MPD取得部， ３８２ MPD供給部， ３８３ セグメント要求部， ３８４ セグメント取得部， ３８５ FLUTE配信依頼部， ４００ コンテンツ配信システム， ４４１ プロキシサーバ

Claims (20)

  1. コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
    前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
    を備える情報処理装置。
  2. 前記判定部は、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する
    請求項１に記載の情報処理装置。
  3. 前記制御情報を受け取る受け取り部をさらに備え、
    前記判定部は、前記受け取り部により受け取られた前記制御情報に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用する場合のコストを評価し、その評価結果に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
    前記更新部は、前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記受け取り部により受け取られた前記制御情報を更新する
    請求項２に記載の情報処理装置。
  4. 前記判定部は、前記受け取り部により受け取られた前記制御情報の量に応じて、前記コストを評価する
    請求項３に記載の情報処理装置。
  5. 前記受け取り部は、所定のネットワークに接続されるクライアントから供給される前記制御情報を受け取る
    請求項３に記載の情報処理装置。
  6. 前記受け取り部は、前記コンテンツを供給するサーバのプロキシサーバから供給される、前記プロキシサーバがクライアントから収集した前記制御情報を受け取る
    請求項３に記載の情報処理装置。
  7. マルチキャスト配信若しくは放送配信のリソースの利用状況を確認する確認部をさらに備え、
    前記判定部は、前記確認部により確認された利用可能な前記リソースを利用する場合についての前記コストを評価する
    請求項２に記載の情報処理装置。
  8. 前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツを供給するためのマルチキャスト配信若しくは放送配信のリソースを確保する確保部をさらに備え、
    前記更新部は、前記コンテンツの供給に、前記確保部により確保された前記リソースを利用するように、前記制御情報を更新する
    請求項１に記載の情報処理装置。
  9. 前記コンテンツは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
    前記制御情報は、MPD（Media Presentation Description）である
    請求項１に記載の情報処理装置。
  10. 前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemIdentifierに、前記コンテンツの供給に利用するマルチキャスト配信若しくは放送配信を識別する識別子を格納する
    請求項９に記載の情報処理装置。
  11. 前記更新部は、前記MPDのBaseURLに配置されるserviceLocationAttribute URL属性により指定されるService Locationファイルの、DeliverySystemDescriptorに、前記DeliverySystemIdentifierに格納された識別子に対応するシステムにおいてストリームデータを取得するためのパラメタを格納する
    請求項１０に記載の情報処理装置。
  12. 前記コンテンツのユニキャスト用のストリームをユニキャスト配信するユニキャスト配信部をさらに備える
    請求項１に記載の情報処理装置。
  13. 前記コンテンツのユニキャスト用のストリームをマルチキャスト配信若しくは放送配信用のストリームに変換する変換部と、
    前記変換部により生成された前記ストリームをマルチキャスト配信若しくは放送配信するBC/MC配信部をさらに備える
    請求項１２に記載の情報処理装置。
  14. 前記ユニキャスト用のストリームは、DASH（Dynamic Adaptive Streaming over HTTP）フォーマットのストリームであり、
    前記変換部により生成されたマルチキャスト配信若しくは放送配信用のストリームは、FLUTE（File Delivery over Unidirectional Transport）プロトコルのファイルである
    請求項１３に記載の情報処理装置。
  15. 前記変換部は、前記FLUTEプロトコルのファイルのFDT（File Delivery Table）-Instanceにおいて、File要素の属性としてrange属性を導入する
    請求項１４に記載の情報処理装置。
  16. 前記更新部により更新された前記制御情報を供給する供給部をさらに備える
    請求項１に記載の情報処理装置。
  17. クライアントの代わりに前記コンテンツを取得し、
    前記供給部より供給される前記制御情報に応じて、取得した前記コンテンツをユニキャスト配信により前記クライアントに供給するか、若しくは、取得した前記コンテンツを、マルチキャスト配信若しくは放送配信のリソースを利用して前記クライアントに供給する供給制御部をさらに備える
    請求項１６に記載の情報処理装置。
  18. コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
    前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
    情報処理方法。
  19. コンピュータを、
    コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定する判定部と、
    前記判定部により前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する更新部と
    して機能させるプログラム。
  20. サーバからクライアントにコンテンツを供給するコンテンツ供給システムであって、
    前記クライアントからの前記コンテンツの取得要求量に応じて、前記コンテンツの供給にマルチキャスト配信若しくは放送配信を利用するか否かを判定し、
    前記マルチキャスト配信若しくは前記放送配信を利用すると判定された場合、前記サーバから前記クライアントへの前記コンテンツの供給に前記マルチキャスト配信若しくは前記放送配信を利用するように、前記コンテンツのユニキャスト配信に関する制御情報を更新する
    コンテンツ供給システム。
JP2015502864A 2013-02-27 2014-02-17 情報処理装置および方法、プログラム、並びにコンテンツ供給システム Abandoned JPWO2014132821A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2013036902 2013-02-27
JP2013036902 2013-02-27
PCT/JP2014/053596 WO2014132821A1 (ja) 2013-02-27 2014-02-17 情報処理装置および方法、プログラム、並びにコンテンツ供給システム

Publications (1)

Publication Number Publication Date
JPWO2014132821A1 true JPWO2014132821A1 (ja) 2017-02-02

Family

ID=51428093

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015502864A Abandoned JPWO2014132821A1 (ja) 2013-02-27 2014-02-17 情報処理装置および方法、プログラム、並びにコンテンツ供給システム

Country Status (6)

Country Link
US (1) US10085123B2 (ja)
EP (1) EP2963939A4 (ja)
JP (1) JPWO2014132821A1 (ja)
CN (1) CN105009601A (ja)
BR (1) BR112015020102A2 (ja)
WO (1) WO2014132821A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140372569A1 (en) * 2013-06-14 2014-12-18 Samsung Electronics Co., Ltd. Controlling dash client rate adaptation
WO2015023655A1 (en) * 2013-08-12 2015-02-19 Imvision Software Technologies Ltd. Method and system for managing the delivery of over-the-top streams
CN105745899B (zh) * 2014-02-24 2023-12-26 Lg 电子株式会社 发送广播信号的设备、接收广播信号的设备、发送广播信号的方法和接收广播信号的方法
US20160094986A1 (en) * 2014-09-29 2016-03-31 Sprint Communications Company L.P. Content delivery metadata exchange in wireless communication systems
US10305949B2 (en) 2014-10-10 2019-05-28 Sony Corporation Reception device, reception method, transmission device, and transmission method
WO2016067987A1 (ja) * 2014-10-28 2016-05-06 ソニー株式会社 受信装置、送信装置、およびデータ処理方法
WO2016127374A1 (zh) * 2015-02-12 2016-08-18 华为技术有限公司 多媒体流业务呈现方法和相关装置及相关系统
FR3052318B1 (fr) * 2016-06-03 2019-08-09 Expway Procede d’acces a un service transmis en mode telediffusion sur un reseau mobile
JP6487953B2 (ja) * 2017-02-13 2019-03-20 Kddi株式会社 通信端末装置、及び管理装置
US20200053394A1 (en) * 2017-03-24 2020-02-13 Sony Corporation Content processing apparatus, content processing method, and program
KR20190128630A (ko) * 2017-03-24 2019-11-18 소니 주식회사 콘텐츠 제공 시스템 및 콘텐츠 제공 방법, 그리고 프로그램
JP2020005038A (ja) * 2018-06-25 2020-01-09 キヤノン株式会社 送信装置、送信方法、受信装置、受信方法、及び、プログラム
US11509949B2 (en) * 2019-09-13 2022-11-22 Disney Enterprises, Inc. Packager for segmenter fluidity

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL158158A (en) 2003-09-29 2012-05-31 Bamboo Mediacasting Ltd Distribution of multicast data to users
US7423973B2 (en) * 2004-05-18 2008-09-09 Qualcomm Incorporated Methods and apparatus for hybrid multicast and unicast transmissions in a data network
US20060007930A1 (en) * 2004-07-09 2006-01-12 Dorenbosch Jheroen P Downlink multicast method in wireless internet protocol system
CA2577421A1 (en) * 2004-08-16 2006-03-02 Qualcomm Flarion Technologies, Inc. Group communication signal methods and apparatus
US7983493B2 (en) * 2004-10-05 2011-07-19 Vectormax Corporation Adaptive overlapped block matching for accurate motion compensation
JP5325978B2 (ja) * 2008-05-20 2013-10-23 トムソン ライセンシング 複数の受信器において利用できるコンテンツマップの配信システム及び方法
JP2010081397A (ja) * 2008-09-26 2010-04-08 Ntt Docomo Inc データ受信端末、データ配信サーバ、データ配信システム、およびデータ配信方法
US9369516B2 (en) * 2009-01-13 2016-06-14 Viasat, Inc. Deltacasting
JP4878642B2 (ja) * 2009-12-15 2012-02-15 シャープ株式会社 コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法
US8310957B1 (en) 2010-03-09 2012-11-13 Juniper Networks, Inc. Minimum-cost spanning trees of unicast tunnels for multicast distribution
ES2774203T3 (es) * 2011-06-14 2020-07-17 Viasat Inc Protocolo de transporte para contenido anticipado
US9635689B2 (en) * 2011-08-30 2017-04-25 Verizon Patent And Licensing Inc. Delivery channel selection and application layer handover of programs for a mobile service
KR20130048094A (ko) * 2011-11-01 2013-05-09 한국전자통신연구원 콘텐츠 스트리밍 중계를 위한 노드 장치 및 그 방법
EP2885903B1 (en) * 2012-08-14 2016-06-15 Telefonaktiebolaget LM Ericsson (publ) Processing of multimedia data

Also Published As

Publication number Publication date
CN105009601A (zh) 2015-10-28
WO2014132821A1 (ja) 2014-09-04
US10085123B2 (en) 2018-09-25
US20150327025A1 (en) 2015-11-12
BR112015020102A2 (pt) 2017-07-18
EP2963939A4 (en) 2016-10-05
EP2963939A1 (en) 2016-01-06

Similar Documents

Publication Publication Date Title
WO2014132821A1 (ja) 情報処理装置および方法、プログラム、並びにコンテンツ供給システム
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
US20110246608A1 (en) System, method and device for delivering streaming media
WO2009021374A1 (fr) Système de réseau de pair à pair de service vidéo intégré
WO2014188886A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
WO2014196392A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
WO2014148277A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JPWO2018043134A1 (ja) 配信装置、配信方法、受信装置、受信方法、プログラム、およびコンテンツ配信システム
CN105284118B (zh) 内容供应装置、内容供应方法、程序存储介质、终端装置和内容供应系统
WO2015029800A1 (ja) サーバ装置、情報処理方法、プログラム、端末装置、およびコンテンツ供給システム
WO2020195705A1 (ja) 情報処理装置および情報処理方法、並びにプログラム
US20170155968A1 (en) Content supply apparatus, content supply method, program terminal apparatus, and content supply system
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6471922B2 (ja) 情報処理装置、情報処理方法、及び、プログラム
Riad et al. A framework for cloud P2P VoD system based on user's behavior analysis
WO2015029768A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP6340882B2 (ja) 情報処理装置、情報処理方法、及び、プログラム
WO2015008653A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
Iqbal et al. DAg-stream: Distributed video adaptation for overlay streaming to heterogeneous devices
WO2015163172A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
Fortino et al. An open streaming content distribution network

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170214

A762 Written abandonment of application

Free format text: JAPANESE INTERMEDIATE CODE: A762

Effective date: 20170321