JP6231583B2

JP6231583B2 - ネットワークを介するメディアストリーミングのためのトランスポートダイバーシティおよびタイムシフトバッファのサポート

Info

Publication number: JP6231583B2
Application number: JP2015552894A
Authority: JP
Inventors: ケヴィン・ローランド・フォール; ナガラジュ・ナイク; トーマス・シュトックハンマー; ファティ・ウルピナール; カルロス・マルセロ・ディアス・パソス; チャールズ・エヌ・ロー
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2013-01-15
Filing date: 2014-01-14
Publication date: 2017-11-15
Anticipated expiration: 2034-01-14
Also published as: CN105284093A; EP2946542A1; JP2016510460A; BR112015016989A2; EP2946542B1; ES2630279T3; KR20150107837A; US20140201323A1; CN105284093B; WO2014113383A1; BR112015016989B1; US20140199044A1; HUE031896T2; KR101847585B1; US10015437B2

Description

本出願は、2013年1月15日に出願した、米国仮出願第61/752,456号、および2013年4月8日に出願した、米国仮出願第61/809,871号の利益を主張するものである。

本開示は、通信システムに関し、より具体的には、ネットワークを介するコンテンツの配信に関する。

デジタルマルチメディア(オーディオおよびビデオならびに他のメディアを含む)機能は、デジタルテレビジョン、デジタル直接ブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラまたは衛星無線電話、ビデオ遠隔会議デバイスを含む、幅広いデバイスに組み込まれ得る。デジタルマルチメディアデバイスは、デジタルマルチメディア情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4 Part 10、アドバンスドビデオ符号化(AVC)によって定義された規格、およびそのような規格の拡張に記載されたもののような、ビデオ、オーディオ、および/または他のメディアの圧縮技術を実施する。

マルチメディア圧縮技術は、ビデオシーケンス中の固有の冗長性を低減または除去するために、空間予測および/時間予測を実行する。ブロックベースのビデオ符号化に関して、ビデオフレームまたはスライスは、ブロックに分割され得る。各ブロックは、さらに分割され得る。イントラ符号化(I)フレームまたはスライスのブロックは、隣接ブロックに対する空間予測を用いて符号化される。インター符号化(PまたはB)フレームまたはスライスのブロックは、同じフレームもしくはスライス内の隣接ブロックに対する空間予測、または、他の参照フレームに対する時間予測を使用することができる。

マルチメディアデータが符号化(例えば、圧縮)された後、データは、送信または保存のためにパケット化され得る。データは、AVCのような、国際標準化機構(ISO)ベースメディアファイルフォーマットのような様々な規格、およびその拡張のいずれかに準拠するファイルに組み込まれ得る。

ワイヤレス通信ネットワークは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャスト、などのような様々な通信サービスを提供するために、広く展開されている。これらのワイヤレスネットワークは、利用可能なネットワークリソースを共有することによって、複数のユーザをサポートすることができる多重アクセスネットワークであり得る。そのような多重接続ネットワークの例は、符号分割多重アクセス(CDMA)ネットワーク、時分割多重アクセス(TDMA)ネットワーク、周波数分割多重アクセス(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、およびシングルキャリアFDMA(SC-FDMA)ネットワークを含む。

第3世代パートナーシッププロジェクト(3GPP)ロングタームエボリューション(LTE)は、汎欧州デジタル移動電話方式(GSM(登録商標))およびユニバーサル移動体通信システム(UMTS)の発展としてセルラ技術の大きな進歩を表している。LTE物理層(PHY)は、進化型ノードB(eNB)のような基地局と、UEのようなモバイルデバイスとの間で、データと制御情報の両方を搬送するための高度に効率的な方法を提供する。先行出願では、マルチメディアのための高帯域通信を容易にするための方法は、単一周波数ネットワーク(SFN)運用であった。SFNは、加入者UEと通信するために、例えば、eNBのような無線送信機を利用する。ユニキャスト運用では、各eNBは、1つまたは複数の特定の加入者UEに向けられた情報を搬送する信号を送信するように制御される。ユニキャストシグナリングの特異性は、例えば、音声通話、テキストメッセージング、またはビデオ通話のような、個人対個人のサービスを可能にする。

Fielding他、「Hypertext Transfer Protocol - HTTP/1.1」、Network Working Group、RFC 2616、1999年6月 Qualcomm Inc.からのTdoc S4-130051、「Rationale for USD Indication of DASH Delivery Mode and Illustrative Implementation」

全体的に、本開示は、ネットワークを介してメディアデータをストリーミングするための技術を説明する。例えば、本開示は、様々なタイプのトランスポート、例えば、ユニキャスト、ブロードキャスト、および/またはマルチキャストのいずれかを介してマルチメディアデータを受信するための技術を説明する。例えば、リダイレクタ/プロキシユニットは、アプリケーションサービスクライアントに、ユニキャストを介して直接インターネットから、または、ブロードキャストまたはマルチキャストサービスが利用可能なとき、ブロードキャストまたはマルチキャストミドルウェアユニットから、メディアデータを取得させることができる。代替的には、リダイレクタ/プロキシユニットは、ブロードキャストまたはマルチキャストサービスが利用できないとき、アプリケーションサービスクライアントの代わりにメディアデータを取得することができる。メディアデータを伝達するために、複数のタイプのトランスポートが利用可能であるおよび/または使用されるとき、「トランスポートダイバーシティ」という用語が、以下で使用され得る。メディアを伝達するために使用されるプロバイダ(メディア供給源)および/またはトランスポートが(例えば、リダイレクタ/プロキシユニットによって)変更されたとき、「リダイレクション」または「リダイレクトされた」という用語が、以下で使用され得る。

本開示は、また、取得されたメディアデータをバッファリングすることに関連する技術を説明する。例えば、取得されたメディアデータは、タイムシフトバッファ(TSB:time-shifted buffer)に記憶され得る。本開示は、適切な量のメモリがTSBのために割り当てられ得るように、例えば、メディアコンテンツの再生時間の点で、TSBのサイズをシグナリングするための技術を説明する。このようにして、メディアデータは、より後の時点で再生され得、および/または、トリックモード、例えば、早送りもしくは巻き戻しを使用して再生され得る。

一例では、メディアデータを取得する方法は、プロキシユニットを使用することによって、メディアデータを取得するためのサービスに基づいて、メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得するステップであって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、ステップと、アプリケーションサービスクライアントからのメディアデータに対する要求を受信するステップと、サービスが利用可能であるかどうかを判断するステップと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させるステップとを含む。

別の例では、メディアデータを受信するためのデバイスは、メディアデータを取得するためのサービスに基づいて、メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、ことと、アプリケーションサービスクライアントからのメディアデータに対する要求を受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させることとを行うように構成されたプロキシユニットを含む。

別の例では、メディアデータを取得するためのデバイスは、メディアデータを取得するためのサービスに基づいて、メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得するための手段であって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、手段と、アプリケーションサービスクライアントからのメディアデータに対する要求を受信するための手段と、サービスが利用可能であるかどうかを判断するための手段と、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させるための手段とを含む。

別の例では、コンピュータ可読記憶媒体は、実行されたとき、プロセッサに、メディアデータを取得するためのサービスに基づいて、メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、ことと、アプリケーションサービスクライアントからのメディアデータに対する要求を受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させることとを行わせる命令を記憶している。

別の例では、メディアデータを処理する方法は、タイムシフトバッファ(TSB)の深度を定義する属性を含むセッション記述プロトコル(SDP:session description protocol)メッセージを受信するステップと、属性の値に基づいて、TSBのためのメモリの量を決定するステップと、TSBを形成するために、決定された量のメモリを割り当てるステップと、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶するステップとを含む。

別の例では、メディアデータを処理するためのデバイスは、タイムシフトバッファ(TSB)の深度を定義する属性を含むセッション記述プロトコル(SDP:session description protocol)メッセージを受信し、属性の値に基づいて、TSBのためのメモリの量を決定し、TSBを形成するために、決定された量のメモリを割り当て、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶するように構成された1つまたは複数のプロセッサを含む。

別の例では、メディアデータを処理するためのデバイスは、タイムシフトバッファ(TSB)の深度を定義する属性を含むセッション記述プロトコル(SDP)メッセージを受信するための手段と、属性の値に基づいて、TSBのためのメモリの量を決定するための手段と、TSBを形成するために、決定された量のメモリを割り当てるための手段と、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶するための手段とを含む。

別の例では、コンピュータ可読記憶媒体は、実行されたとき、プロセッサに、タイムシフトバッファ(TSB)の深度を定義する属性を含むセッション記述プロトコル(SDP:session description protocol)メッセージを受信させ、属性の値に基づいて、TSBのためのメモリの量を決定させ、TSBを形成するために、決定された量のメモリを割り当てさせ、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶させる命令を記憶している。

トランスポートダイバーシティをサポートするための例示的なシステムを示す図である。トランスポートダイバーシティをサポートするためのリダイレクタ/プロキシを含む装置の代替的な例を示す図である。トランスポートダイバーシティをサポートするためのリダイレクタ/プロキシを含む装置の代替的な例を示す図である。リダイレクション動作のために構成されたリダイレクタ/プロキシを使用する方法の例示的なプロセスの流れの態様を示す図である。プロキシ動作のために構成されたリダイレクタ/プロキシを使用する方法の態様を示す図である。トランスポートダイバーシティをサポートするための方法論の例を示す図である。図5の方法論を実施するための例示的な装置を示す図である。トランスポートダイバーシティをサポートするためのさらなる態様を示す図である。トランスポートダイバーシティをサポートするためのさらなる態様を示す図である。リアルタイムトランスポートプロトコル(RTP:Real-Time Transport Protocol)/リアルタイムストリーミングプロトコル(RTSP:Real-Time Streaming Protocol)ストリーミングをサポートするための例示的なマルチキャストサービスデバイスクライアント(MSDC:multicast services device client)アーキテクチャを示すブロック図である。リアルタイムトランスポートプロトコル(RTP)/リアルタイムストリーミングプロトコル(RTSP)ストリーミングをサポートするための例示的なマルチキャストサービスデバイスクライアント(MSDC)アーキテクチャを示すブロック図である。例示的な進化型MBMS(eMBMS)ユーザサービス記述(USD:user service description)スキーマの抜粋(snippet)を示す概念図である。 RTSP/RTPクライアントのためのトランスポートダイバーシティをサポートするための例示的な構成要素を示すブロック図である。 RTSP/RTPクライアントのためのトランスポートダイバーシティをサポートするための例示的な構成要素を示すブロック図である。 HTTP(DASH)トランスポート情報を介して動的適応型ストリーミングを行うためにUSDを拡張するための例示的な拡張可能マークアップ言語(XML)コンテンツモデルを示す概念図である。 HTTP(DASH)トランスポート情報を介して動的適応型ストリーミングを行うためにUSDを拡張するための例示的な拡張可能マークアップ言語(XML)コンテンツモデルを示す概念図である。 MBMSを介するDASHをサポートするための例示的なアーキテクチャを示す概念図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図15のネットワークアーキテクチャに関連するコールフローを示す流れ図である。 MBMSを介するDASHをサポートするための別の例示的なアーキテクチャを示す概念図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。本開示の技術によるタイムシフトバッファ(TSB)の深度に関連するデータをシグナリングするための例示的な方法を示すフローチャートである。

全体的に、本開示は、ネットワークを介して、オーディオおよび/またはビデオデータのようなマルチメディアデータをストリーミングするための様々なタイプのトランスポートメカニズムをサポートするための技術を説明する。例えば、アプリケーションサービスクライアント(ストリーミングクライアンと呼ぶこともできる)は、ユニキャストプロトコルまたはブロードキャスト(もしくはマルチキャスト)プロトコルのいずれかにしたがってメディアデータを取得するために、プロキシユニットと相互作用するように構成され得る。いくつかの例では、プロキシユニットは、例えば、クライアントデバイスがブロードキャストプロトコルを使用してメディアデータを配信するためのサービスプロバイダのカバレッジエリア内にあるかどうかに基づいて、メディアデータがブロードキャストプロトコルを使用して取得され得るかどうかを判断し、クライアントデバイスがカバレッジエリア内にあるかどうかに基づいて、ユニキャストプロトコルまたはブロードキャストプロトコルのいずれかを選択することができる。クライアントデバイスは、アプリケーションサービスクライアントを実行することができ、および/または、プロキシユニットを含むことができる。いくつかの例では、クライアントデバイスは、アプリケーションサービスクライアントを実行することができ、プロキシユニットは、クライアントデバイスとは別のデバイスに含まれ得る。

本開示の技術は、メディアデータをストリーミングするための様々なアプリケーション層プロトコルと併せて使用され得る。例えば、本開示の技術は、メディアデータをストリーミングするためにHTTPを利用する動的適応型ストリーミングオーバHTTP(DASH:Dynamic Adaptive Streaming over HTTP)と併せて使用され得る。別の例として、本開示の技術は、リアルタイムトランスポートプロトコル(RTP)またはリアルタイムストリーミングプロトコル(RTSP)と併せて使用され得る。これらおよび他の例では、アプリケーションサービスクライアント(例えば、RTPクライアント、RTSPクライアント、またはDASHクライアント)は、アプリケーションサービスクライアントがメディアデータを取得するために使用されるトランスポートメカニズムを意識する必要がないという意味で、トランスポート非依存であり得る。例えば、アプリケーションサービスクライアントは、基礎となるトランスポートメカニズムがユニキャストプロトコルまたはブロードキャストもしくはマルチキャストプロトコルのいずれに対応するのかを意識する必要はない。

以下でより詳細に論じるように、プロキシユニット(リダイレクタ/プロキシユニットと呼ぶこともできる)は、アプリケーションサービスクライアントからの要求を受信するように構成され得、要求は、特定のメディアデータを指定する。プロキシユニットは、メディアデータが、特定のトランスポートメカニズム、例えば、ブロードキャストプロトコルまたはユニキャストプロトコルを使用して取得され得るかどうかを判断することができる。プロキシユニットは、次いで、アプリケーションサービスクライアントに、(利用可能性、嗜好性、信頼性、および/または他の要因に基づいて)トランスポートメカニズムのうちの1つを使用してメディアデータを受信させることができる。例えば、ブロードキャストプロトコルがユニキャストプロトコルよりも好ましく、ブロードキャストプロトコルが利用可能である場合、プロキシユニットは、アプリケーションサービスクライアントに、ブロードキャストプロトコルを介してメディアデータを取得させることができるが、ブロードキャストプロトコルが利用できない場合、プロキシユニットは、アプリケーションサービスクライアントに、ユニキャストプロトコルを介してメディアデータを受信させることができる。

一例では、DASHに関して、メディアデータは、1つまたは複数のサーバ、例えば、ブロードキャストおよび/またはユニキャストサービスとして、ブロードキャストサーバおよびユニキャストサーバから利用可能であり得る。DASHクライアントは、メディアデータが(サーバではなく)プロキシユニットから利用可能であることを示す、メディアデータに関する修正されたメディアプレゼンテーション記述(MPD:media presentation description)を受信することができる。DASHクライアントがメディアデータに対する要求をプロキシユニットに送信すると、プロキシユニットは、要求されたメディアデータを取得するためにユニキャストプロトコルまたはブロードキャストプロトコルのいずれが利用可能であるのかを判断することができる。ブロードキャストプロトコルが利用可能である場合、ブロードキャスト受信ユニット(例えば、マルチメディアブロードキャストマルチキャストサービス(MBMS:multimedia broadcast multicast service)または進化型MBMS(eMBMS)ミドルウェアユニット)は、マルチメディアデータを受信することができ、プロキシユニットは、DASHクライアントに、メディアデータに対する要求をブロードキャスト受信ユニットに送らせることができる。他方では、ブロードキャストプロトコルが利用できない場合、プロキシユニットは、ユニキャストを使用してメディアデータを取得するために、DASHクライアントに、メディアデータに対する要求をユニキャストサーバに送らせることができる。代替的には、プロキシユニットは、ユニキャストサーバからメディアデータを取得することができ、次いで、取得したメディアデータをDASHクライアントに提供することができる。いくつかの例では、ユニキャストサーバおよびブロードキャストサーバは、同じサーバに対応することができる。

別の例として、RTPまたはRTSPに関して、RTPクライアント(代替的には、RTSPクライアントに対応することができる)は、DESCRIBE、SETUP、およびPLAYコマンドをプロキシユニットに提出することができる。DESCRIBEコマンド応答して、プロキシユニットは、修正されたセッション記述プロトコル(SDP)メッセージをRTPクライアントに提供することができる。修正されたSDPメッセージは、そこからメディアデータが利用可能であるアドレスとして、プロキシユニットのアドレスを指定することができる。この修正されたSDPメッセージは、RTPクライアントに、SETUPおよびPLAYコマンドをプロキシユニットに送らせることができる。プロキシユニットが、ブロードキャストプロトコルが利用可能であると判断したとき、プロキシユニットは、SETUPおよびPLAYコマンドをブロードキャスト受信ユニット(MBMSまたはeMBMSミドルウェアユニット)に送ることができ、ブロードキャスト受信ユニットは、メディアデータを受信し、メディアデータをRTPクライアントに転送することができる。他方では、プロキシユニットが、ブロードキャストプロトコルが利用できないと判断したとき、プロキシユニットは、メディアデータをユニキャストサーバから取得することができ、次いで、取得したメディアデータをRTPクライアントに提供することができる。

いくつかの例では、本開示の技術を実行するための構成要素は、アプリケーションサービスクライアントと、プロキシユニットと、ブロードキャスト受信ユニットとを含むことができる。様々な例では、クライアントデバイスは、これらの構成要素のいずれかまたはすべてを、単独でまたは任意の組み合わせで含むことができる。代替的には、クライアントデバイスは、アプリケーションサービスクライアントを含むことができ、プロキシユニットおよび/またはブロードキャスト受信ユニットは、クライアントデバイスとは別の1つまたは複数のデバイス内に含まれ得る。

さらに、本開示は、また、タイムシフトバッファ(TSB)のためのデータをシグナリングすることに関連する技術を説明する。クライアントデバイス(本明細書では「ユーザ機器」とも呼ばれる)は、早送り、巻き戻し、再生、などのような様々なトリックモードをサポートする際に媒体データを保持するために使用されるようにTSBを形成するために、メモリを割り当てることができる。一般に、トリックモードは、メディアデータが定義された出力順序以外の順序または速度で再生される再生モードを指すことができる。例えば、早送りでは、特定のメディアデータは、スキップされ得る。別の例として、巻き戻しでは、メディアデータの出力順序は、逆転され得、特定のメディアデータは、同様にスキップされ得る。例えば、ビデオデータに関して、メディアデータをスキップするために、イントラ符号化モードを使用して符号化された画像のみが表示され得、インター符号化されたピクチャをスキップする。

本開示の技術によれば、データは、例えば、TSBをインスタンス化するために、SDPメッセージ中でシグナリングされ得る。例えば、TSB属性は、TSBに記憶され得るメディアデータの量を秒単位で定義する値でシグナリングされ得る。クライアントデバイスは、TSB属性の値に基づいて、TSBのために必要なメモリの量を計算することができる。計算は、例としてビデオデータに関して、メディアデータ内のビデオデータのフレームレートを含むことができる。クライアントデバイスは、画像あたりの平均データ量、(フレームレートに基づく)ある期間中の画像数、および、TSB属性によって定義される時間の長さに基づいて、TSBのためのメモリサイズを計算することができる。同様に、クライアントデバイスは、さらに、期間中の、オーディオデータ、テキストデータ、または他のデータもしくはメディアのために必要なメモリの量を決定することができる。したがって、クライアントデバイスは、このデータを、トリックモードを実行するためにメディアデータを記憶するためのTSBに割り当てることができる。さらに、クライアントデバイスは、MBMSまたはeMBMSのようなブロードキャストプロトコルを介して受信したデータのためのトリックモードを実行することができる。

言い換えれば、いくつかの例では、本開示の技術は、進化型マルチメディアブロードキャストマルチキャストサービス(eMBMS)ネットワークを介するリアルタイムプロトコル/リアルタイムストリーミングプロトコル(RTP/RTSP)ストリーミングの機能をサポートするためのミドルウェアアーキテクチャを含む。これらの機能は、タイムシフトバッファおよびトランスポートダイバーシティ(例えば、コンテンツ配信のためのユニキャストからブロードキャストへのまたはその逆の切り替え)を含む。タイムシフトバッファ(TSB)機能に関して、アーキテクチャは、バッファ深度をシグナリングするデータを含むために、セッション記述プロトコル(SDP)の拡張をサポートすることができる。トランスポートダイバーシティ機能の一例として、本開示は、切り替えがミドルウェアレベルで管理され得るので、コンテンツを消費するアプリケーションがユニキャストからブロードキャストに、またはその逆に切り替わるトランスポートの詳細を意識する必要がないアーキテクチャを説明し、提案する。

HTTPストリーミングでは、頻繁に使用される動作は、GETおよび部分的GETを含む。GET動作は、所与のユニフォームリソース識別子(URI)(例えば、URLまたはURN)に関連付けられたファイル全体の取得を要求する。部分的GET動作は、リソースのバイト範囲(サブセット)の取得を要求する。GETまたは部分的GET動作は、1つまたは複数の個々の映像断片を取得することができるので、映像断片は、HTTPストリーミングのために提供され得る。映像断片には、異なるトラックのいくつかのトラック断片が存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにアクセス可能な構造化されたデータ集合であり得る。クライアントは、ストリーミングサービスをユーザに提示するために、メディアデータ情報を要求し、ダウンロードすることができる。

HTTPを使用するストリーミングDASHデータの例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータの複数の表現が存在し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造で定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能な構造化されたデータ集合に対応することができる。HTTPストリーミングクライアントデバイスは、ストリーミングサービスをクライアントデバイスのユーザに提示するために、メディアデータ情報を要求し、ダウンロードすることができる。メディアプレゼンテーションは、MPDデータ構造に記述され得、それは、MPDの動的な更新を含むことができる。

メディアプレゼンテーションは、一連の1つまたは複数の期間を含むことができる。期間は、MPD中のPeriod要素によって定義され得る。各期間は、MPD中の属性startを有することができる。MPDは、各周期に関するstart属性およびavailablityStartTime属性を含むことができる。ライブサービスに関して、周期のstart属性およびMPDの属性availablityStartTimeの合計は、UTCフォーマット中の期間の、特に、対応する期間中の各表現の第1のメディアセグメントの利用可能な時間を指定することができる。オンデマンドサービスに関して、第1の期間のstart属性は、0であり得る。任意の他の期間に関して、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定することができる。各期間は、次の期間の開始まで、または、最後の期間の場合にはメディアプレゼンテーションの最後まで延長することができる。期間開始時間は、正確であり得る。それらは、すべての過去の期間のメディアを再生することから生じる実際のタイミングを反映することができる。

各期間は、同じメディアコンテンツのための1つまたは複数の表現を含むことができる。表現は、オーディオ、ビデオ、または他のデータのいくつかの代替的な符号化バージョンのうちの1つであり得る。表現は、符号化タイプによって、例えば、ビデオデータに関するビットレート、解像度、および/またはコーデック、ならびに、オーディオデータに関するビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、符号化されたオーディオもしくはビデオデータ、または、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された他のメディアもしくはデータのセクションを指すために使用され得る。

特定の期間の表現は、MPDのgroup属性によって示されるグループに割り当てられ得る。同じグループ内の表現は、一般的に、互いに代替するものと考えられる。例えば、特定の期間中のビデオデータの各表現は、表現のいずれかが、対応する期間中のマルチメディアコンテンツのビデオデータを表示するために復号するために選択され得るように、同じグループに割り当てられ得る。1つの期間内のメディアコンテンツは、いくつかの例では、存在する場合、グループ0からのいずれか1つの表現によって、または、非ゼロのグループからの多くても1つの表現の組み合わせによって表現され得る。ある期間の各表現に関するタイミングデータは、期間の開始時間と比較して表され得る。

表現は、1つまたは複数のセグメントを含むことができる。各表現は、初期化セグメントを含むことができ、または、表現の各セグメントは、自己初期化している可能性がある。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。一般的に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソース識別子(URI)(例えば、ユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN))のような識別子を使用して一意に参照され得る。MPDは、各セグメントのための識別子を提供することができる。いくつかの例では、MPDは、また、range属性の形態でバイト範囲を提供することができ、それは、対応するURIを参照することによってアクセス可能なリソース(例えば、ファイル)内のセグメントの連続するバイト範囲に関するデータに対応することができる。

各表現は、また、1つまたは複数のメディア構成要素を含むことができ、各メディア構成要素は、オーディオ、ビデオ、または(例えば、クローズドキャプションのための)タイムドテキスト(timed text)のような、1つの個別のメディアタイプの符号化バージョンに対応することができる。メディア構成要素は、1つの表現内の連続するメディアセグメントの境界を越えて時間連続的であり得る。

本明細書で説明する技術は、上述のワイヤレスネットワークおよび無線技術、ならびに、他のワイヤレスネットワークおよび無線技術のために使用され得る。明確にするために、技術の特定の態様が、LTEに関して以下で説明されており、LTE用語が、以下の説明の多くで使用されている。

RTP/RTSPストリーミングは、リアルタイムストリーミングサービスをサポートするための一般的なプロトコルである。eMBMSサービスのための3GPP仕様は、ロングタームエボリューション(LTE)ネットワークを介するRTPプロトコルのためのアーキテクチャを説明している。しかしながら、本開示は、RTP/RTSPに関する2つの問題を認識し、これらの問題を克服するために使用され得る技術を論じる。

タイムシフトバッファ(TSB)は、ユーザ機器(UE)内にメディアコンテンツの一部を記憶するために使用され得る機能である。バッファは、ユーザがメディアコンテンツの再生位置を前方または後方に移動させることを可能にする。このプロセスでは、UEは、バッファ深度を知らされている必要があり、それは、トリックモード再生、例えば、再生の早送りまたは巻き戻しを可能にするために、UEがどれくらい多くの時間相当のコンテンツをデバイスに蓄積する必要があるのかの指標を提供する。VLCメディアプレーヤの一実施態様では、TSB機能は、起動時にバッファ深度を引数としてVLCプレーヤに提供することによって有効にされる。プロセスは、自動ではなく、代わりに、バッファ深度引数を提供し、その結果、TSBを有効にするために、ユーザの介入を必要とする。本開示は、マルチキャストサービスデバイスクライアント(MSDC)のような、eMBMS対応ミドルウェア層でTSBをサポートするための技術を説明する。

セッション記述プロトコル(SDP)は、まとめて「セッションプロファイル」として知られる、ストリーミングサービスのエンドポイント情報と、そのメディアストリーム(セッション)関連のパラメータとを記述する。したがって、ストリーミングサービスが異なるトランスポート方法で利用可能である場合、サービスのための異なるトランスポート/エンドポイントパラメータを記述する複数のプロファイルが必要とされる。例えば、ブロードキャストリアルタイムRTPベースのサービスは、そのメディアストリームに関するマルチキャストIPアドレスおよびポートを参照することができ、サービスのユニキャストバージョンは、ユニキャストIPアドレスおよびポートを参照することができる。ブロードキャストおよびユニキャスト配信方法のためのメディアストリームの異なる表現が存在し得る。LTEネットワークでは、MSDCは、eMBMS対応アプリケーションへのストリーミングサービスの配信を提供する。ユニキャストと他の(例えば、ブロードキャストまたはマルチキャスト)トランスポート方法への切り替えをサポートするために、複数のセッションプロファイルを利用する必要があり、その選択は、主に、UEがブロードキャストのカバレッジ外またはカバレッジ内のいずれにあるかに基づくことになる。UEがブロードキャストカバレッジエリアに移動するたびに、MSDCは、接続を設定し、コンテンツを消費するために、SDPプロファイルのブロードキャスト対応バージョンを使用することができる。しかしながら、逆のシナリオでは、UEがブロードキャストカバレッジの外に移動したとき、MSDCは、ユニキャストコンテンツを消費するために、ユニキャストSDPを使用し、リモートRTSPサーバとのユニキャスト接続を設定する必要があり得る。ユーザまたはアプリケーションから隠されたユニキャストとブロードキャストとの間の移行を維持するために、本開示は、シームレスな移行のためのメカニズムを説明する。

本開示は、数ある技術の中で、単独で、一緒に、および/または、本開示で説明する他の技術との任意の組み合わせで使用され得る、TSBをサポートする技術およびトランスポート切り替えをサポートする技術を説明する。eMBMSを介するRTPベースのストリーミングでTSB機能を有効にするために、本開示は、タイムシフトバッファ深度値をシグナリングするためにSDPメカニズムの拡張を使用するための技術を説明する。トランスポート切り替えの問題のために、本開示は、ユニキャスト記述とブロードキャスト記述の両方を含むSDP記述のための統一化手法を説明する。また、ブロードキャストとユニキャストとの間の移行をアプリケーション/ユーザに対してシームレスに行うために、本開示は、ミドルウェアが統一化SDPを使用してコンテンツのリダイレクションを処理し、プロセスをユーザから隠す、ミドルウェアベースの解決策を説明する。

本開示の主題の態様によれば、例えば、メタデータおよびデジタルコンテンツをクライアントのアプリケーションに配信するために、複数の異なるタイプのトランスポートメカニズム/プロトコル(例えば、eMBMS、デジタルビデオブロードキャスト(DVB:digital video broadcast)、など)が用いられ得る抽象化層を提供するために、クライアントデバイスまたはデバイスの集団内の展開のための方法、装置、およびアーキテクチャが提供される。アプリケーションは、個々のトランスポートの詳細を認識する必要はない。本開示は、アプリケーションに配信されるデータおよびメタデータの可用性の選択、場所、またはタイミングを決定するために使用され得るポリシーの設定可能なセットのオプションを含むことができる。

インターネット上のコンテンツにアクセスするアプリケーションは、HTTPまたはHTTPセキュア(HTTPS)スキームを利用するユニバーサルリソースロケイタ(URL)であり得るユニバーサルリソース識別子(URI)を使用してコンテンツ(またはその構成部分)を識別することができる。例えば、MPEG-DASHの文脈では、HTTPまたはHTTPSスキームを含むURL参照は、HTTPまたはHTTPSプロトコルを使用して解決され得る。加えて、HTTPは、URLによって参照されるデータをフェッチするために使用され得る。DASH規格は、非HTTPのURLを利用することができ、本開示は、クライアントからの任意の要求(HTTPベースの要求を含む)が、要求を異なるときに異なる場所に向けさせる、および/または、要求しているクライアントに代替のコンテンツにアクセスすることを命じるオプションを提供する柔軟な方法で処理されるケースに関連することができる。

本開示の技術は、コンテンツに対するクライアント要求を処理するリダイレクト機能の具体化を含み得る。リダイレクタ(本明細書ではリダイレクタ/プロキシとも呼ばれる)は、クライアント要求で識別される材料に処理を適用し、この処理の結果をマッチング基準のテーブルに対して比較する方法またはアルゴリズムを呼び出し、クライアントが後続の要求を実行する場所を知ることができるように、クライアントに、代替の場所、アクセス方法、タイミング情報、またはコンテンツ(例えば、ファイル内の)を示すことができる。別の態様では、リダイレクタは、クライアントの代わりにコンテンツに対する要求を実行し、要求されたコンテンツをフェッチすることができる。この場合には、リダイレクタは、プロキシまたは再帰的機能で作用することができる。

図1は、トランスポートダイバーシティをサポートするための例示的なシステム100を示すブロック図である。例示的なシステム100は、例えばモバイルデバイスの、アプリケーション101を含むことができる。アプリケーション101は、コンテンツに対する要求を実行することができる。例えば、DASHマルチメディア再生アプリケーションは、マニフェストまたはMPDを処理し、メタデータおよびデータを含むURLを決定し、HTTP要求を送る。コンテンツに対する要求は、典型的には、ウェブブラウザの「プロキシ」機能を設定する際に使用されることになるプロトコルのような、所定の、予め設定された、または(例えば、TCPもしくはUDPにより)動的に決定されるプロトコルポートを使用することができる。プロトコルポートの決定は、例えば、プロキシ自動設定(PAC:proxy auto-config)ファイル内などのユーザもしくはネットワーク/システム管理者によって確立された設定ファイルを使用すること、または、ウェブプロキシ自動検出プロトコル(WPAD:web proxy auto-discovery protocol)によるなどのプロトコルを介して設定ファイルを使用することを含むことができる。

リダイレクタ/プロキシ104は、アプリケーションサービスクライアント102を介してアプリケーション101の要求を受信し、要求されたコンテンツを決定するために、要求を処理または解析することができる。リダイレクタ/プロキシ104は、一致が生じたかどうかを判断するために、結果を、マッチング基準を含むテーブル(または、他の適切なタイプのデータ構造)に対して比較することができる。一致が生じた場合、リダイレクタ/プロキシ104は、リダイレクション目標を決定することができる。目標は、アプリケーション101に送達され得る。別の態様では、リダイレクタ/プロキシ104は、再帰的に作用することができ、アプリケーション101は、リダイレクション目標を処理する必要はない可能性がある。例えば、リダイレクタ/プロキシ104は、アプリケーション101の代わりに、リダイレクション目標に基づいてコンテンツをフェッチすることができる。

リダイレクタ/プロキシ104は、アプリケーション101と同じデバイス上に配置され得、または、リダイレクタ/プロキシ104は、別個のデバイス上に配置され得る。同じデバイス上に配置されたリダイレクタ/プロキシ104の場合には、アプリケーション101は、HTTP、アプリケーションプログラミングインターフェース(API)、プロセス間通信(IPC:inter-process communication)、などを介して、リダイレクタ/プロキシ104と通信することができる。別個のデバイス上に配置されたリダイレクタ/プロキシ104の場合には、アプリケーション101は、(アプリケーションサービスクライアント102を介して)HTTPなどを介してリダイレクタと通信することができる。

「一致」(または不一致)の判断に続いて、リダイレクション目標は、アプリケーション101に提供され得る。目標は、アプリケーション101によって要求されたコンテンツオブジェクトの代わりにアクセスする代替のコンテンツオブジェクトを示すことができる。リダイレクション目標がアプリケーション101に示され得る様々な方法が存在する可能性がある。

システム100の構成要素間のシグナリングは、APIまたはIPCを使用して実行され得る。この態様では、APIまたはIPCメカニズムは、リダイレクタ/プロキシ104とアプリケーション101との間の通信を提供するために利用され得る。APIを使用する場合には、リダイレクタ/プロキシ104は、リダイレクト目標を示すために、アプリケーション101またはアプリケーションライブラリ内に実装された方法または手順を呼び出すことができる。

システム100の構成要素間のシグナリングは、メタデータの書き換えを介して実行され得る。この態様では、メタデータ(例えば、DASH MPD)は、オブジェクトのための代替の参照を示すように書き換えられ得る。例えば、元のメタデータ内のURIの存在は、同等のまたは代わりのコンテンツにアクセスするための代替URIを形成するために書き換えられ得る。

システム100の構成要素間のシグナリングは、通信プロトコル内の指標を使用して実行され得る。この態様では、アプリケーション層の通信プロトコル(例えば、HTTP)は、シグナリング情報をアプリケーション101に通信するような方法で利用され得る。一変形形態では、「リダイレクト」のHTTP応答コードカテゴリは、使用され得る(例えば、これは、フォーム3xxのコードに対応することができ、ここで、xは、ゼロから9までの数であり得る)。この変形形態の1つのサブケースでは、例えば、コード300(利用可能な複数の選択肢を示す)は、使用され得、そこで、リダイレクタ/プロキシ104は、アプリケーション101が使用するために1つまたは複数を選択することができる参照(例えば、URI)のベクトルを提供する。

マッチング機能は、アプリケーション101に由来するオブジェクト参照(例えば、要求URI)をデータ構造(例えば、ファイル、データベース、マッチングテーブル、など)内に存在するオブジェクト参照と比較した結果を与えることができる。

非限定的な例として、一態様では、マッチング基準は、URIプレフィックスとして表現され得、生じる単一の好ましい一致は、(一般に、ビットまたはバイトの数によって決定されるような)最長のプレフィックスとの一致によって示される。別の態様では、各々の潜在的な一致は、対応する優先度番号を割り当てられ得、最大(または最小)の優先度番号を有するエントリは、選択され得る。

別の態様では、マッチング基準は、正規表現によって表現され得、好ましい一致は、一致する文字の最大数を使用して決定され得る。別の変形形態では、正規表現は、マッチング基準を表すために使用され得、最大(または最小)の優先度番号を有する潜在的な一致が選択され得る。

上記で論じたマッチングアルゴリズムおよびデータ構造の内容は、予め決定または予め設定され得るポリシーに基づくことができる。別の態様では、ポリシーは、論理ポリシーデータベースから動的に追加または削除され得る。ポリシーデータベースは、様々なデータ構造を使用して実現され得、データ構造またはデータベース実施態様の任意の特定のタイプに限定されない。

ポリシーは、例えば、あるソースからのマッチング基準を他の基準よりも優先させるもしくは優先させないこと(例えば、あるトランスポートタイプは、他のトランスポートタイプよりも優先され得る/優先され得ない)、ソース、時間、リダイレクション目標、および/もしくはマッチング基準値の関数としてマッチング基準を削除すること、ソース、時間、リダイレクション目標、および/もしくはマッチング基準値の関数としてマッチング基準を追加すること、ならびに/または、ソース、時間、リダイレクション目標、および/もしくはマッチング基準値の関数としてマッチング基準を修正することを含むいくつかの方法で、マッチングアルゴリズムの動作を決定するために使用され得る。

例示的なシステム100は、リダイレクトされた場所に基づいてコンテンツを要求するためのトランスポートミドルウェア110を含むことができる。トランスポートミドルウェア110は、トランスポートA110AないしトランスポートR110Rのようないくつかのトランスポートメカニズム/プロトコルを含むことができる。各トランスポートメカニズム(トランスポートA110AないしトランスポートR110R)は、ファイル情報のリストおよび詳細を取得し、例えば、集約URIまたは共通URIプレフィックスを生成することができる、対応するモジュールを有することができる。これらのモジュールは、通信メカニズム(例えば、IPC、API、またはプロトコル)を介してこの情報をコントローラ106に伝達することができ、コントローラ106は、ポリシーおよび解像度を適用することができ、今度はポリシーを前提としてリダイレクタ/プロキシ104をプログラムすることができる。トランスポートメカニズム(トランスポートA110AないしトランスポートR110R)は、例えば、eMBMS、DVB-T2、DVB-S、他のDVBファミリの放送技術、などを含むことができる。各トランスポートミドルウェアは、コンテンツまたは他のデータを記憶するキャッシュを含むことができる。例えば、トランスポートミドルウェアは、アプリケーション101へのコンテンツ配信がユーザに対して瞬時に表示され得るように、コンテンツの開始セグメントをキャッシュすることができる。トランスポートミドルウェア110は、コンテンツサーバ120のようなソースからのコンテンツを要求することができる。加えて、または代替的に、クライアントは、インターネット122を含むネットワークを介してコンテンツを要求することができる。プロキシまたは「再帰的」動作のために設定されたリダイレクタ/プロキシ104に関して、リダイレクタ/プロキシ104は、トランスポートミドルウェア110を介して、またはネットワークもしくはインターネット122を介して、コンテンツを要求することができる。リダイレクタ/プロキシ104は、リダイレクションまたはプロキシの役割のうちの1つで動作するように事前に設定され得る。リダイレクタ/プロキシ104の役割は、例えば、ルールのセットに基づいて、実行時に決定され得る。

図2A〜図2Bは、トランスポートダイバーシティをサポートするためのリダイレクタ/プロキシ104を含む装置の代替例を示す。リダイレクタ/プロキシ104、ポリシーデータベース108を有するコントローラ106、またはトランスポートミドルウェア110のいずれかまたはすべては、アプリケーション101およびクライアントと同じデバイス上に配置され得、または、別個のデバイス上に配置され得る。図2Aの例では、システム200Aは、クライアントおよびアプリケーション101と同じUE101A上に配置されて示されているリダイレクタ/プロキシ104Aを含む。例えば、アプリケーションサービスクライアント102Aは、DASHクライアント、HTTPライブストリーミング(HLS:HTTP Live Streaming)、Apple(登録商標)ライブストリーミング(ALS:Apple Live Streaming)クライアント、適応型HTTPストリーミング(AHS)クライアント、または任意の他の適切なクライアントであり得る。アプリケーションサービスクライアント102Aは、HTTP、API、IPC、または任意の他の適切なプロトコルもしくは方法を介して、リダイレクタ/プロキシ104Aと通信することができる。図2Bの例では、システム200Bは、UE101B内に配置されたアプリケーションサービスクライアント102Bおよびアプリケーション101とは別のエンティティ110上に配置されて示されているリダイレクタ/プロキシ104Bを含む。例えば、アプリケーションサービスクライアント102Bは、DASHクライアント、HLS(ALS)クライアント、AHSクライアント、または任意の他の適切なクライアントであり得る。アプリケーションサービスクライアント102Bは、HTTP、または任意の他の適切なプロトコルもしくは方法を介して、リダイレクタ/プロキシ104Bと通信することができる。リダイレクタ/プロキシ104Bは、プロキシサーバ、ゲートウェイ、ルータ、などの、任意の適切なネットワークエンティティ上に配置され得る。

図3は、リダイレクション動作のために構成されたリダイレクタ/プロキシを使用する例示的なプロセスフロー320の態様を示す流れ図である。プロセスフロー320の開始の前に、ポリシーデータベース108(コントローラ106に結合された)は、コントローラ106の動作を決定するためのポリシー情報を備えることができる、または設定され得る。ポリシーデータベース108は、プロビジョニング時間における情報を備えることができる。

図1中のアプリケーション101に関連してもしなくてもよいアプリケーション101は、プロビジョニングアプリケーションであり得る。アプリケーション101は、トランスポートミドルウェア110を活性化する(321)と共に、トランスポートミドルウェア110に関するステータスを決定するように構成され得る。アプリケーション101は、トランスポートミドルウェア110の1つまたは複数のトランスポートメカニズムを活性化するように構成され得る。アプリケーション101は、起動時に、最初に、プロキシエンドポイント(例えば、ホスト名もしくはアドレス、プロトコル、またはプロトコルポート番号)を識別する情報を用いて、アプリケーションサービスクライアント102を構成することができる(322)。

この例では、2つ以上のトランスポートが利用可能であり得、様々なコンテンツが、異なる時間に様々なトランスポートを介して利用可能であり得る。具体的には、様々なサービスが利用可能であり得、ここで、様々なサービスは、各々、メディアデータをトランスポートするための、ブロードキャスト、マルチキャスト、ユニキャスト、などの、トランスポートの異なるそれぞれのタイプを定義することができる。例えば、eMBMS、および/または、トランスポートの1つもしくは複数のDVBファミリは、利用可能であり得る。さらに、利用可能なメディアコンテンツ(例えば、ファイル)は、例えば、アプリケーションサービス記述を使用して表現され得る。アプリケーションサービス記述の一例は、様々な利用可能なメディア構成要素を記述する際にMBMSユーザサービスとして配信されるDASHコンテンツの場合には、MPDフラグメントのようなMBMSユーザサービス記述(USD)メタデータフラグメントである。アプリケーションサービス記述の別の例は、MBMSユーザサービスとして配信されるHLSコンテンツの場合には、Apple HLS(HTTPライブストリーミング)マニフェストファイルである。各トランスポートメカニズムは、リストおよびファイル情報の詳細を取得し、集約URIまたは共通URIプレフィックスを生成することができる、対応するモジュールを有することができる。これらのモジュールは、通信メカニズム(例えば、IPC、API、または他のプロトコル)を介してこの情報をコントローラ106に伝達することができ、コントローラ106は、ポリシーおよび解像度を適用することができ、今度はポリシーを前提としてリダイレクタ/プロキシ104をプログラムする。

コンテンツサーバ310は、サービスリスト(例えば、USD、ESG)を(例えば、LTE RAN、DVB-Tなどを使用して)ブロードキャストすることができ、それは、トランスポートミドルウェア110によって受信され得る。アプリケーションモジュール(例えば、トランスポートA110AないしトランスポートR110Rのうちの1つ)は、サービスリストを解析し、情報をトランスポート固有ではない形式に処理する。トランスポートミドルウェア110は、結果(例えば、ファイル利用可能性リストとも呼ばれる、利用可能なファイルのリストを定義するサービスおよびデータの識別子)をコントローラ106に伝達することができる(324)。コントローラ106は、マッピングのセットを生成するために、アクセスポリシーと併せてファイル利用可能性リストを処理することができる(325)。マッピングは、どのURI(またはURIプレフィックス)がどのサーバにリダイレクトされるべきかを含むことができる(例えば、MBMSを介して利用可能なファイルは、MBMSミドルウェア内でインスタンス化された、またはMBMSミドルウェアに関連付けられたサーバから利用可能であり得る)。

アプリケーションサービスクライアント102が呼び出されると、アプリケーションサービスクライアント102は、例えば、MPDコンテンツを取得するために、設定されたプロキシアドレスを介して要求(例えば、HTTP要求)を発行することができる(326)。要求は、リダイレクタ/プロキシ104に通信され得る。リダイレクタ/プロキシ104は、マッチング基準、または、一致が生じない場合、別のインジケータ(例えば、デフォルトのリダイレクション目標、エラー表示、または、元の要求のコピー)を決定するために、マッチングアルゴリズムを実行することができる。リダイレクタ/プロキシ104は、次いで、リダイレクション目標またはエラーを、例えば、HTTPを使用して、アプリケーションサービスクライアント102に提供することができる(327A)。リダイレクションを示すコード(例えば、HTTPコード)(例えば、3xxタイプのコード)を観察したアプリケーションサービスクライアント102は、コードタイプに応じて応答する。例えば、300以外のコードタイプは、リソースの代替的な場所を示すことができるHTTP「Location:」ヘッダを含む。そのような指示を受信すると、アプリケーションサービスクライアント102は、示された代替的な場所を使用して、その要求を再試行することができる。この例では、リダイレクタ/プロキシ104は、特定のURIがMBMSミドルウェア内に統合されたサーバにリダイレクトされるべきであることを示す。したがって、アプリケーションサービスクライアント102は、例えば、そのようなリダイレクションコードに応答してMPDを取得するために、トランスポートミドルウェア110に要求を提出することができる(327B)。

アプリケーションサービスクライアント102がMPD情報を取得すると、アプリケーションサービスクライアント102は、アクセスするメディアセグメント(例えば、MPEG-DASHの場合には「表現」)を決定し、HTTPベースの要求をリダイレクタ/プロキシ104に発行することができる(328)。上記で説明したメカニズム(例えば、サービスIDによって識別されるサービスに関連付けられたトランスポートのタイプ)を使用して、リダイレクタ/プロキシ104は、リダイレクト目標をアプリケーションサービスクライアント102に提供することができる(329)。目標は、デフォルト値、(アプリケーションサービスクライアント102が要求を処理すべきであることを示す)要求のコピー、または異なるサーバへの参照であり得る。目標は、次いで、メディアセグメントを取得するためにアプリケーションサービスクライアント102によって使用される場所として役立つ。すなわち、コンテンツがサービスを使用して利用可能であると仮定すると、アプリケーションサービスクライアント102は、コンテンツ要求をトランスポートミドルウェア110に提出することができ(330A)、それに応答して、トランスポートミドルウェア110は、コンテンツをアプリケーションサービスクライアント102に配信することができる(331A)。(サービスが利用できないとき)他のソースを介して利用可能なコンテンツに関して、アプリケーションサービスクライアント102は、他の方法を介して(例えば、他のサーバ、記憶装置/キャッシュ、またはインターネットから)コンテンツを取得することができる。例えば、アプリケーションサービスクライアント102は、コンテンツ要求をコンテンツサーバ310に送ることができ(330B)、それに応答して、コンテンツサーバ310は、要求されたコンテンツをアプリケーションサービスクライアント102に配信することができる(331B)。

いくつかの場合では、ステップ326またはステップ328でアプリケーションサービスクライアント102から要求されたURIは、リダイレクタ/プロキシ104には未知である可能性がある。そのような場合には、異なるセグメントを要求すること、または、リダイレクタ/プロキシ104の使用を停止する(例えば、代わりにダイレクトインターネットアクセス要求を使用する)ことを試みることができることをアプリケーションサービスクライアント102に示すために、エラー(例えば、HTTPコード404)が生成され得る。代替的には、リダイレクタ104は、非プロキシ動作を示唆するために、着信要求に相当する場所ヘッダを使用することができる。別の態様は、プロキシまたはウェブプロキシとして作用するリダイレクタ/プロキシ104を含むことができ、その場合には、例えば、図4の例示的なプロセスフロー400で以下に示すように、アプリケーションサービスクライアント102の代わりに、インターネットもしくは別のネットワークまたはキャッシュにアクセスすることができる。

300タイプのHTTPエラーコードに関して、アプリケーションサービスクライアント102は、「Location:」ヘッダ内に存在しない可能性がある選択肢のベクトルで提示され得る。この場合には、アプリケーションサービスクライアント102は、提供された複数の選択肢の中から選択することができ、メディア符号化フィーマットの細目に応じて、その復号状態を再初期化することができる。例えば、再生シナリオの途中で、アプリケーションサービスクライアント102がこれまでに処理してきた以外の方法で符号化された表現へのリダイレクションが生じた場合、シナリオは、生じ得る。

アプリケーションサービスクライアント102がその次のメディア要求/アクセスを選択するためにどのプロセスを使用しても、アプリケーションサービスクライアント102は、リダイレクトされた情報に基づいて要求/アクセスを初期化することができる。後続の要求/アクセスは、最初にリダイレクタを通過することができ、リダイレクタが介入し、セグメント(例えば、ファイルとして記憶されたメタデータおよび/またはメディアセグメント)が取得される場所(および他の特性)を有効に修正する機会を提供する。

図4は、プロキシ動作のために構成されたリダイレクタ/プロキシを使用する例示的なプロセスフロー400の態様を示す流れ図である。プロセスフロー400の開始の前に、ポリシーデータベース108(コントローラ106に結合された)は、コントローラ106の動作を決定するためのポリシー情報を備えることができる、または設定され得る。ポリシーデータベース108は、プロビジョニング時間における情報を備えることができる。

アプリケーション101は、プロビジョニングアプリケーションであり得る。図1のアプリケーション101に関連して説明したが、アプリケーションは、図1に関連して説明したものと同じである必要はないことを理解すべきである。アプリケーション101は、トランスポートミドルウェア110を活性化する(401)ように構成され得る。アプリケーション101は、トランスポートミドルウェア110の1つまたは複数のトランスポートメカニズムを活性化するように構成され得る。アプリケーションサービスクライアント102は、アプリケーション101によって、起動時に、最初に、プロキシエンドポイント(例えば、ホスト名もしくはアドレス、プロトコル、またはプロトコルポート番号)を識別する情報を用いて構成され得る(402)。

この例では、2つ以上のトランスポートメカニズムが利用可能であり得、様々なメディアが、異なる時間に様々なトランスポートを介して利用可能であり得る。トランスポートの様々なタイプは、それぞれのサービスによって定義され得る。例えば、eMBMS、および/または、トランスポートの1つもしくは複数のDVBファミリは、利用可能であり得る。さらに、利用可能なメディアファイルは、例えば、eMBMS USDのMPDフラグメントを使用して、DVBトランスポートのためのDVB電子サービスガイド(ESG:electronic service guide)を介して表現され得る。トランスポートミドルウェア110によって表される各トランスポートメカニズムは、利用可能なサービスのリストおよびファイル情報の詳細を取得し、集約URIまたは共通URIプレフィックスを生成することができる、対応するモジュールを有することができる。これらのモジュールは、通信メカニズム(例えば、IPC、API、または他のプロトコル)を介してこの情報をコントローラ106に伝達することができ、コントローラ106は、ポリシーおよび解像度を適用することができ、今度はポリシーを前提としてリダイレクタ/プロキシ104をプログラムする。

コンテンツサーバ310は、サービスリスト(例えば、USD、ESG)をブロードキャストすることができ、それは、トランスポートミドルウェア110によって受信される(403)。適切なモジュール(例えば、トランスポートA110AないしトランスポートR110Rのうちの1つ)は、サービスリストを解析し、情報をトランスポート固有ではない形式に処理する。トランスポートミドルウェア110は、結果をコントローラ106に伝達することができる(404)。コントローラ106は、マッピングのセットを生成するために、アクセスポリシーと併せてファイル利用可能性リストを処理することができる(405)。マッピングは、どのURI(またはURIプレフィックス)がどのインスタンス化されたサーバにリダイレクトされるべきかを含むことができる(例えば、MBMSを介して利用可能なファイルまたはメディアは、MBMSミドルウェア内でインスタンス化された、またはMBMSミドルウェアに関連付けられたサーバから利用可能であり得る)。

アプリケーションサービスクライアント102が呼び出されると、アプリケーションサービスクライアント102は、例えば、MPDコンテンツを取得するために、設定されたプロキシアドレスを介して要求(例えば、HTTP要求)を発行することができる(406)。要求は、リダイレクタ/プロキシ104に通信され得る。リダイレクタ/プロキシ104は、マッチング基準、または、一致が生じない場合、別のインジケータ(例えば、デフォルトのリダイレクション目標、エラー表示、または、元の要求のコピー)を決定するために、マッチングアルゴリズムを実行することができる。エラーの場合には、エラーは、アプリケーションサービスクライアント102に提供され得る。一致が生じた場合、リダイレクタ/プロキシ104は、プロキシとして動作し、アプリケーションサービスクライアント102の代わりにコンテンツを取得することができる。目標は、次いで、メディアセグメントを取得するために、プロキシとして動作するリダイレクタ/プロキシ104によって使用される場所として役立つ。すなわち、リダイレクタ/プロキシ104は、コンテンツ要求をトランスポートミドルウェア110に提出することができ(407A)、トランスポートミドルウェアは、コンテンツをリダイレクタ/プロキシ104に配信することができる(408A)。他のソースを介して利用可能なコンテンツに関して、リダイレクタ/プロキシ104は、他のサーバを介して、記憶装置/ファイル、またはインターネットからコンテンツを取得することができる。すなわち、リダイレクタ/プロキシ104は、コンテンツ要求をコンテンツサーバ310に送ることができ(407B)、コンテンツサーバ310は、要求されたコンテンツをリダイレクタ/プロキシに配信することができる(408B)。

図5は、ワイヤレス通信ネットワーク(WCN:wireless communications network)のマルチメディアクライアントのためのマルチメディアコンテンツに関連付けられたトランスポートダイバーシティをサポートするための例示的な方法を示すフローチャートである。マルチメディアクライアントは、モバイルエンティティであり得る、またはモバイルを含むことができる。方法500は、502でコンテンツに対する要求を受信することを含むことができる。方法500は、504でルールのセットに基づいて要求に関して一致が存在するかどうかを判断することを含むことができる。方法500は、506で、一致が存在するという判断に応じて、リダイレクションをマルチメディアクライアントに送ることができる。

図6は、ワイヤレス通信ネットワーク(WCN)のマルチメディアクライアントのためのマルチメディアコンテンツに関連付けられたトランスポートダイバーシティをサポートするための、UE、ネットワークエンティティ、もしくは他の適切なエンティティとして、または、UE、ネットワークエンティティ、もしくは他の適切なエンティティ内で使用するためのプロセッサ、構成要素、もしくは同様のデバイスとして構成され得る例示的な装置600を示すブロック図である。装置600は、プロセッサ、ソフトウェア、またはそれらの組み合わせ(例えば、ファームウェア)によって実現される機能を表すことができる機能ブロックを含むことができる。

図示のように、一例では、装置600は、コンテンツに対する要求を受信するための電気構成要素またはモジュール602を含むことができる。装置600は、要求に関して一致が存在するかどうかをルールのセットに基づいて判断するための電気構成要素またはモジュール604を含むことができる。装置600は、一致が存在するという判断に応じて、リダイレクションをマルチメディアクライアントに送るための電気構成要素またはモジュール606を含むことができる。

関連する態様では、ネットワークエンティティとして構成された装置600の場合には、装置600は、少なくとも1つのプロセッサを有するプロセッサ構成要素610をオプションで含むことができる。プロセッサ610は、そのような場合には、バス612または同様の通信カップリングを介して、構成要素602〜606または同様の構成要素と動作可能に通信することができる。プロセッサ610は、電気構成要素またはモジュール602〜606によって実行されるプロセスまたは機能の開始およびスケジューリングをもたらすことができる。

さらなる関連する態様では、装置600は、他のネットワークエンティティと通信するためのネットワークインターフェース構成要素614を含むことができる。装置600は、例えば、メモリデバイス/構成要素616のような、情報を記憶するための構成要素をオプションで含むことができる。コンピュータ可読媒体またはメモリ構成要素616は、バス612などを介して、装置600の他の構成要素と動作可能に結合され得る。メモリ構成要素616は、構成要素602〜606、およびそのサブ構成要素、またはプロセッサ610の活動を実行するためのコンピュータ可読命令およびデータを記憶するように適合され得る。メモリ構成要素616は、構成要素602〜606に関連付けられた機能を実行するための命令を保持することができる。メモリ616の外部にあるものとして示されているが、構成要素602〜606は、メモリ616内に存在し得ることが理解されるべきである。

図7および図8は、トランスポートダイバーシティをサポートするためのさらなる態様を示すブロック図である。図7および/または図8の構成要素は、上記で説明した図1の構成要素に実質的に対応することができる。図7は、例えば、ネットワーク700、アプリケーションサービスクライアント702、メディアアプリケーション704、HTTPリダイレクタ/プロキシ706、コントローラ708、ミドルウェア712、およびポリシーマネージャ716を示す。メディアアプリケーション704は、一般的に、メディアコンテンツを(例えば、ユーザの選択に応じて)選択することに関与し、アプリケーションサービスクライアント702は、選択されたメディアコンテンツを取得し、取得したメディアコンテンツを再生のためにメディアアプリケーション704に提供するように構成される。アプリケーションサービスクライアント702は、例えば、メディアデータをストリーミングするためにHTTPを利用するように構成されたDASHクライアントを備えることができる。

図1に関して上記で論じたように、アプリケーションサービスクライアント702は、ネットワーク700から直接、またはミドルウェア712からメディアデータを取得することができる。例えば、ブロードキャストまたはマルチキャストをサポートするサービスが(例えば、コントローラ708によって決定され、ポリシーマネージャ716によって記憶されたポリシーによって定義されるように)利用可能であるとき、ミドルウェア712は、メディアデータを受信し、受信したメディアデータをキャッシュ714内に記憶することができる。アプリケーションサービスクライアント702は、メディアデータに対する要求をHTTPリダイレクタ/プロキシ706に発することができる。要求されたメディアデータがミドルウェア712によって受信されているとき、HTTPリダイレクタ/プロキシ706は、メディアデータに対する要求をミドルウェア712にリダイレクトすることができる。したがって、アプリケーションサービスクライアント702は、HTTP要求をミドルウェア712に発することができ、ミドルウェア712は、メディアデータをアプリケーションサービスクライアント702に提供することができる。他方では、ミドルウェア712がメディアデータを受信していないとき、HTTPリダイレクタ/プロキシ706は、アプリケーションサービスクライアント702を、メディアデータが利用可能なサーバのネットワーク上の場所にリダイレクトすることができ、サーバは、ネットワーク700を介して利用可能である。

図8は、別の例として、DASHクライアント802、再生アプリケーション804、HTTPリダイレクタ/プロキシ818、コントローラ814、MSDC808、MBMS送信ユニット820、およびポリシーデータベース816を示す。これらの構成要素は、図1および/または図7中の同様の名前の構成要素に実質的に対応することができる。一般的に、図8の技術は、(HTTPを利用する)DASHを利用するように論じられているが、他のストリーミングプロトコルが同様に使用され得ることを理解すべきである。代替例は、例えば、RTP/RTSPに関して以下で論じられる。

最初に、ポリシー情報は、DASHクライアント802と、再生アプリケーション804と、HTTPリダイレクタ/プロキシ818と、コントローラ814と、MSDC808とを含むシステムに提供され得る。そのようなポリシー情報は、ポリシーデータベース816内に記憶され得る(830)。このポリシー情報は、コントローラ814の動作に影響を与えることができる。コントローラ814は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実現され得る。ソフトウェアおよび/またはファームウェアで実現されるとき、コントローラ814に対応するソフトウェアの命令を実行するための1つまたは複数のハードウェアベースの処理ユニットのような必要なハードウェアも設けられ得ると考えられる。

最初に、再生アプリケーション804は、プロキシエンドポイントを識別する情報(例えば、ホスト名またはアドレス、プロトコル、およびプロトコルポート番号)のような識別情報を与えることができる(832)。この情報は、オプションのプロビジョニングアプリケーションによって提供され得る。DASHクライアント802は、識別情報で設定され得る(834)。

図8の例では、2つ以上のトランスポートが利用可能であり得、(例えば、ファイル中の)様々なメディアが、異なる時間に様々なトランスポートを介して利用可能であり得る。例えば、eMBMSおよびDVBトランスポートが利用可能であると考える。さらに、利用可能なメディアファイルが、アプリケーションサービス記述を使用して表現されると考える。各トランスポートは、図1のトランスポートモジュール110A〜110Rによって示されるように、媒体情報のリストおよび詳細を取得し、集約URIまたは共通URIプレフィックスを生成することができる、対応するモジュールを有することができる。MSDC808のみが図8の例に示されているが、MSDC808は、複数のそれぞれのトランスポートモジュールを含むことができることを理解すべきである。これらのモジュールは、通信メカニズム(例えば、IPC、API、またはプロトコル)を介してこの情報をコントローラ814に伝達することができ、コントローラ814は、ポリシーおよび解像度を適用することができ、今度はポリシーを前提としてリダイレクタをプログラムすることができる。図8は、(混乱を制限するために)MBMSに関する部分のみを示す。MBMS rX820は、USDを受信し(836)、USDを解析し、MSDC808に送達することができる(838)。

MSDC808は、USD固有の情報を、トランスポート固有ではない形式に処理し、結果をコントローラ814に伝達する(840)。コントローラ814は、次いで、マッピングのセットを生成するために、ファイル利用可能性リストをアクセスポリシーと併せて処理する(842)。マッピングは、どのURI(またはURIプレフィックス)がどのインスタンス化されたサーバにリダイレクトされるべきかを示すことができる(例えば、MBMSを介して利用可能なファイルは、MSDC808内でインスタンス化された、またはMSDC808に関連付けられたサーバ812から利用可能であり得る)。すなわち、HTTPリダイレクタ/プロキシ818は、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することができ、サービスは、メディアデータをトランスポートするための複数のタイプのトランスポート(例えば、ブロードキャスト、ユニキャスト、またはマルチキャスト)のうちの少なくとも1つを定義する。例えば、サービスは、メディアデータをトランスポートするためのブロードキャストまたはマルチキャストトランスポートタイプを定義することができ、その場合には、MSDC808は、データを受信することができる。MSDC808は、以下で論じるように、例えば、DASHクライアント802によるその後の取得のために、受信したデータをキャッシュ810に記憶することができる。

呼び出されると、DASHクライアント802は、MPDコンテンツを取得するために、設定された(HTTPリダイレクタ/プロキシ818への)プロキシアドレスを介して、HTTP要求を発することができる(844)。同様に、HTTPリダイレクタ/プロキシ818は、DASHクライアント802からHTTP要求を受信することができる。HTTP要求は、メディアデータに対する要求であり得る。HTTPリダイレクタ/プロキシ818は、マッチング基準、または、一致が生じない場合、別のインジケータ(例えば、デフォルトのリダイレクション目標、エラー表示、または、元の要求のコピー)を決定するために、マッチングアルゴリズムを実行することができる。したがって、マッピング情報にマッチング基準を使用して、HTTPリダイレクタ/プロキシ818は、特定のサービス、例えば、要求されたメディアデータをトランスポートするためのブロードキャストまたはマルチキャストを定義するサービスが利用可能であるかどうかを判断することができる。HTTPリダイレクタ/プロキシ818は、次いで、マッチングアルゴリズムに基づいて、HTTPを使用して、リダイレクション目標またはエラーをDASHクライアント820に提供することができる(846)。

リダイレクションを示すHTTPコード(例えば、3xxタイプのHTTPコード)を観察したDASHクライアント802は、コードタイプに応じて応答することができる。300以外のタイプについて、HTTP「Location:」ヘッダは、リソースの代替的な場所を示すことができる。そのような指示を受信すると、DASHクライアント802は、示された代替的な場所を使用して、その要求を再試行することができる。この例では、HTTPリダイレクタ/プロキシ818は、特定のURIが、DASHクライアント802がMPDを取得することができるMSDC808内に統合されたサーバにリダイレクトされるべきであることを示すことができる(848)。

DASHクライアント802がMPD情報を取得した後、DASHクライアント802は、アクセスするメディアファイルがなにか(例えば、MPEG-DASHの場合、どの「表現」か)を判断することができ、判断したメディアファイルを取得するために、1つまたは複数のHTTPベースの要求を発することができる(852)。上記で説明したメカニズムを使用して、HTTPリダイレクタ/プロキシ818は、リダイレクト目標をDASHクライアント802に提供する(854)。目標は、デフォルト値、(クライアントが要求を処理すべきであることを示す)要求のコピー、または異なるサーバへの参照であり得る。目標は、次いで、メディアセグメントを、例えば、MSDC808から取得するためにDASHクライアント802によって使用される場所として役立つ(856)。このように、例えば、メディアをトランスポートするためのブロードキャストまたはマルチキャストを定義するサービスが利用可能であるとき、HTTPリダイレクタ/プロキシ818は、DASHクライアント802に、マッピング情報で示されたリソースの場所からサービスを使用してメディアデータを受信するユニット(例えば、MSDC808)から、要求されたメディアデータを受信させることができる。代替的には、リダイレクション目標は、インターネット806を含むなんらかのネットワークを介して利用可能なネットワーク上の場所に対応することができる。

いくつかの場合では、クライアントから要求されたURI(ステップ844/852)は、HTTPリダイレクタ/プロキシ818には未知である可能性がある。そのような場合には、DASHクライアント802が、異なるセグメントを要求すること、または、HTTPリダイレクタ/プロキシ818を使用しないように変更する(例えば、代わりにダイレクトネットワークまたはインターネットアクセス要求を使用する)ことを試みるべきであることをDASHクライアント802に示すために、エラー(例えば、HTTPコード404)が生成され得る。代替的には、HTTPリダイレクタ/プロキシ818は、非プロキシ動作を示唆するために、着信要求に相当する場所:ヘッダを使用することができる。1つのさらなる変形形態は、HTTPリダイレクタ/プロキシ818が従来のウェブプロキシとして動作することを伴うことになり、その場合には、HTTPリダイレクタ/プロキシ818は、DASHクライアント802の代わりにインターネット806にアクセスすることができる。

このように、図8の技術は、プロキシユニット(例えば、HTTPリダイレクタ/プロキシ818)によって、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスがメディアデータをトランスポートするための複数のタイプのトランスポート(例えば、ブロードキャスト、マルチキャスト、またはユニキャスト)のうちの少なくとも1つを定義する、ことと、メディアデータに対する要求をアプリケーションサービスクライアント(例えば、DASHクライアント802)から受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、リソースの場所からサービスを使用してメディアデータを受信するユニットからメディアデータを受信させることとを含む方法の一例を表す。メディアデータを受信するユニットは、この例では、MSDC808に対応する。

さらに、リソースの場所がネットワーク上の場所(例えば、インターネット806上、またはインターネット806を介してアクセス可能な場所)に対応する場合、HTTPリダイレクタ/プロキシ818は、要求で指定されたメディアデータがマッピング情報内のメディアデータと一致するかどうかを判断し、要求で指定されたメディアデータがマッピング情報内のメディアデータと一致したとき、アプリケーションサービスクライアントにネットワーク上の場所からメディアデータを取得させるために、メディアデータの識別子がマッピング情報中でマッピングされたネットワーク上の場所を指定するリダイレクトメッセージをアプリケーションサービスクライアントに送るように構成され得る。

同様に、HTTPリダイレクタ/プロキシ818は、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスがメディアデータをトランスポートするための複数のタイプのトランスポート(例えば、ブロードキャスト、マルチキャスト、またはユニキャスト)のうちの少なくとも1つを定義する、ことと、メディアデータに対する要求をアプリケーションサービスクライアントから受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、リソースの場所からサービスを使用してメディアデータを受信するユニットからメディアデータを受信させることとを行うように構成されたプロキシユニットの一例を表す。

図9および図10は、RTP/RTSPストリーミングをサポートするための例示的なMSDCアーキテクチャを示すブロック図である。図9は、TSB機能なしのアーキテクチャを示し、図10は、TSBをサポートするアーキテクチャを示す。これらの例では、TSBは、ミドルウェアに維持されることになる。番号付きの矢印は、ネットワーク層からミドルウェアへ、および最終的にはRTSP/RTPクライアントへのデータフローを示す。具体的には、LTEモデムによって受信されたデータは、マルチキャスト(またはブロードキャスト)をサポートするIPスタックに提供される。IPスタックは、受信したデータを、MSDCミドルウェアのリアルタイムトランスポートプロトコル(RTP)機能に提供し(901)、RTP機能は、データに順方向誤り訂正(FEC:forward error correction)処理を実行する。データは、次いで、IPスタックに提供され戻される(902)。IPスタックは、次いで、データをRTPクライアントに提供する(903)。

図10の例では、MSDC1010は、TSB1012をサポートすることができる。したがって、図10の例では、LTEモデムによって受信されたデータは、マルチキャスト(またはブロードキャスト)をサポートするIPスタックに提供される。IPスタックは、受信したデータを、MSDC1010のリアルタイムトランスポートプロトコル(RTP)機能に提供し(1001)、RTP機能は、データに順方向誤り訂正(FEC)処理を実行する。データは、次いで、タイムシフトバッファ(TSB)1012にバッファリングされる(1002)。IPスタックは、次いで、適切な時間にTSB1012からデータを受信し(1003)、データをRTPクライアントに提供する(1004)。

加えて、以下でより詳細に説明するように、MSDC1010は、図10のTSB1012のためのタイムシフトバッファ(TSB)深度を定義する属性を含むSDPメッセージを受信することができる。MSDC1010は、SDPメッセージでシグナリングされるような属性の値に基づいて、TSB1012のためのメモリの量を決定することができる。例えば、属性の値は、例えば、TSB1012に記憶されるべきメディアデータの再生の秒に関して、TSBの長さを定義することができる。したがって、MSDC1010は、例えば、受信されるべきメディアデータのビデオデータのフレームレート、および、TSB1012に潜在的にバッファリングされる再生の秒数に基づいてTSB1012を形成するために割り当てられるべきメモリの量を決定することができる。MSDC1010は、次いで、TSB1012のためのメモリの決定した量を割り当て、SDPメッセージに関連付けられた受信したメディアデータの少なくとも一部をTSB1012に記憶することができる。

TSB深度をシグナリングするために、本開示の技術は、SDPの拡張メカニズムを活用するために使用され得る。SDPの「a=」(属性)ラインは、一般的なセッション記述に機能拡張を提供するために使用され得る。以下のセマンティクスは、TSBに関連するデータをシグナリングするために使用され得、一例として、
・TSB-attribute="a=tsb-length:"Value
・Value=token
○Valueは、単位としてsecondsを有することになる。

一例として、Table 1(表1)に記載した以下のSDP抜粋は、TSBのためのデータを記載する。この例でのバッファ深度は、60秒または1分である。これは、MSDC(例えば、図10に示すMSDCのTSB)がそのタイムシフトバッファに1分相当のメディアコンテンツを維持することになることを意味する。下線付きのテキストは、TSBに関連する本開示の技術による「a=」ラインの形式の例示的な属性を表す。

TSBに関するデータがSDPで提供されたとき、MSDCは、SDPに記載されたサイズのバッファの同等の量を割り当てることができ、RTSP/RTPクライアントが、バッファ期間に対して早送りまたは巻き戻し再生することを可能にすることができる。

トランスポートダイバーシティを達成するための1つの例示的な技術は、代理人番号131286P1の、2013年1月15日に出願した、Fallらの米国仮出願第61/752,456号「ARCHITECTURE SUPPORTING TRANSPORT DIVERSITY」(以下、「Fall仮出願」)によって提案された解決策に基づく。Fall仮出願は、多様なトランスポートプロトコルをサポートするための共通クライアントアーキテクチャを提案する。RTPでトランスポートダイバーシティをサポートするための本開示の技術は、コンテンツのDASHベースの配信に関するFall仮出願に記載の技術を拡張するために使用され得る。

メディアプレゼンテーション記述(MPD)でのメディア表現がトランスポートダイバーシティ方法に基づいて変化し得るDASHプロトコルとは異なり、RTPプロトコルは、従来、単一のSDPプロファイルを介してトランスポートダイバーシティを直接区別する方法を持たない。本開示は、トランスポートダイバーシティを達成するために例示的な技術を説明する。

一例として、サービスのeMBMSブロードキャストの定義は、メカニズムが、ユニキャストトランスポートメカニズムとブロードキャストトランスポートメカニズムとの間で選択することを可能にする。例えば、eMBMSサービス定義スキーマのdeliveryMethod要素は、ブロードキャスト配信セッションを記述するSDPプロファイルを含むことができ、AlternativeAccessDelivery要素は、ユニキャストアクセスのためのRTSP URL、またはユニキャストSDPセッション情報を示すPSS SDPファイルへの参照を含むことができる。UEがブロードキャストネットワークカバレッジの下にあるとき、eMBMSミドルウェアは、ブロードキャストSDPセッション情報を使用して、ブロードキャストコンテンツを消費することができる。そうでなければ、ミドルウェアは、AlternateAccessDelivery中のunicastAccessURIに接続することによって、コンテンツを渡すことができる。eMBMSユーザサービス記述(USD)スキーマ抜粋の一例は、図11に示される。

ブロードキャストSDPおよびユニキャストアクセスURIを担持するdeliveryMethodの代替例は、異なるメディアストリーム内のユニキャストセッション記述とブロードキャストセッション記述の両方を含む統合された単一のSDPを有することである。SDP内の任意のセッション記述が、複数のメディアストリームの定義(例えば、オーディオトラックのための1つおよびビデオトラックのための別のもの)を含むことができるので、メカニズムは、統合されたSDPプロファイルを提供するために、ブロードキャストメディアストリームおよびユニキャストメディアストリームを異なるセットにグループ化するために使用され得る。これは、SDP内のグループ化方法によって達成され得る。グループ化メカニズムの一例は、以下のように記述される。
・メディアストリーム識別
○グループ内のメディアストリームを識別する
○Media-attribute="a=mid:"Identification-tag
○Identification-tag=token
・グループ属性
○ユニキャスト/ブロードキャストメディアストリームを識別する
○Group-attribute="a=group:"Semantics (identification-tag)*
○Semantics="BROADCAST"|"UNICAST"

以下のTable 2(表2)中の抜粋は、値がグループおよびメディアストリーム識別子属性に提供されている一例を提供する。以下の例では、「a=group:」ラインは、どのメディアストリームがブロードキャストのために使用され、どのメディアストリームがユニキャストのために使用されるのかを示す。この例では、それぞれ、ブロードキャストメディアストリームは、「a=mid:」値1および2によって示され、ユニキャストは、「a=mid:」値3および4によって示される。したがって、ミドルウェアは、ブロードキャストコンテンツのためのIPアドレス224.1.1.2ならびにポート30000および30002と、ユニキャストストリームのためのIPアドレス131.10.1.2ならびにポート26890および26892とに接続することができる。

このように、図10は、タイムシフトバッファ(TSB)深度を定義する属性を含むセッション記述プロトコル(SDP)を受信し、属性の値に基づいて、TSBのためのメモリの量を決定し、決定したメモリの量をTSBに割り当て、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶するように構成された1つまたは複数のプロセッサを含むデバイスの一例を示す。

図12および図13は、RTSP/RTPクライアントのためのトランスポートダイバーシティをサポートするための例示的な構成要素を示すブロック図である。eMBMS USD内のdeliveryMethodが、ブロードキャストとユニキャストトランスポートとの間を区別するために使用されるのか、または、統合された単一のSDPメカニズムが使用されるのかにかかわらず、本開示の技術は、RTSP/RTPクライアントによるシームレスなコンテンツ取得を提供することができる。これを達成するために、Fall仮出願で提案されているように、ポリシーマネージャ、コントローラ、およびRTSPリダイレクタ/プロキシは、あるいはeMBMSミドルウェア(マルチキャストサービスデバイスクライアント(MSDC)とも呼ばれる)の外で、UE内に維持され得る。RTSPクライアントがSDPを要求したとき、RTSPリダイレクタ/プロキシは、接続エンドポイントアドレスとしてローカルホスト(例えば、IPバージョン4アドレス127.0.0.1)を担持するSDPプロファイルを常に提供する。アイデアは、RTSPリダイレクタ/プロキシが、コンテンツを、(ブロードキャストのための)eMBMSミドルウェアを介して受信するのか、または(ユニキャストのための)ユニキャストRTSPサーバを介して受信するのかにかかわらず、常にコンテンツをローカルホストからRTSP/RTPクライアントにサーブすることである。したがって、クライアントは、トランスポートメカニズムの多様性を意識しない。以下に、アーキテクチャの主要な構成要素の簡単な説明を提供し、コンテンツがクライアントに配信される方法の一例を与える。

図12および図13の例では、再生アプリケーションは、ストリーミングコンテンツを消費しようとしているアプリケーションであり、RTSP/RTPクライアントは、クライアントの動作のためのRTPプロトコルを実施するクライアントであり、eMBMSミドルウェアは、(ストリーミングまたはファイルダウンロードのための)eMBMS(またはMBMS)ブロードキャストサービス発見を実施し、ブロードキャストLTEネットワークを介してストリーミングまたはファイル配信コンテンツを消費するミドルウェアアーキテクチャであり、ポリシーマネージャは、上記で論じたポリシーのデータベースを維持し、コントローラは、ポリシーマネージャからポリシー情報を、eMBMSミドルウェアからeMBMSブロードキャストカバレッジ指標を取得し、マッピングをRTSPリダイレクタ/プロキシに提供し、どのSDPプロファイルから選択するのか(ユニキャストまたはブロードキャスト)を明言する構成要素であり、RTSPリダイレクタ/プロキシは、コントローラからマッピング情報を受信し、マッピングに応じて、eMBMSミドルウェアからRTPコンテンツを収集し(UEがブロードキャストカバレッジ内の場合)、または、ユニキャストRTSP URIに接続し、ユニキャストトランスポートを介してコンテンツを受信するプロキシユニットであり、その後RTSP/RTPクライアントに渡すことができる。

図12は、RTPコンテンツのブロードキャスト配信のための例示的な手順を示す。図12は、RTSP/RTPクライアント1202と、再生アプリケーション1204と、RTSPリダイレクタ/プロキシ1218と、コントローラ1214と、eMBMSミドルウェア(MSDCとも呼ばれる)1208と、ポリシーマネージャ1216と、ブロードキャスト送信ユニット(eMBMS rXとも呼ばれる)1220とを含む。図12は、ロングタームエボリューション(LTE)無線アクセスネットワーク(RAN:radio access network)1206も示す。LTE RAN1206は、メディアデータのための複数のタイプのトランスポート(例えば、ブロードキャスト、マルチキャスト、またはユニキャスト)のうちの少なくとも1つを定義するMBMSサービスを提供する。したがって、MSDC1208がLTE RAN1206によって提供されるカバレッジのサービスエリア内にあるとき、MSDC1208は、ブロードキャストまたはマルチキャストトランスポートを使用して、LTE RAN1206を介してメディアデータを受信することができる。さらに、MSDC1208は、キャッシュ1210を含むサーバ1212を実装する。このように、MSDC1208は、メディアデータを受信するクライアントと、データを、例えば、RTSP/RTPクライアント1202に提供するサーバの両方として動作することができる。さらに、RTSP/RTPクライアント1202は、メディアデータを、例えば、MSDC1208またはRTSPリダイレクタ/プロキシ1218から取得することができ、次いで、メディアデータを再生アプリケーション1204に提供することができる。

再生アプリケーション1204は、アプリケーション101(図1)に実質的に対応することができ、RTSP/RTPクライアント1202は、アプリケーションサービスクライアント102(図1)に実質的に対応することができる。同様に、MSDC1208は、トランスポートミドルウェア110A〜110R(図10)のうちの1つに実質的に対応することができる。コントローラ1214は、コントローラ106(図1)に実質的に対応することができる。RTSPリダイレクタ/プロキシ1218は、リダイレクタ/プロキシ104(図1)に実質的に対応することができる。

この例では、ポリシーマネージャは、ポリシーがプロビジョニングされる(1230)。eMBMSミドルウェア(またはMSDC)1208は、eMBMSサービスのリストのためのUSD記述を受信する(1232、1234)。MSDC1208は、次いで、RTPストリーミングサービスのためのSDPプロファイル情報、およびブロードキャストカバレッジ通知をコントローラ1214に渡し(1236)、コントローラ1214は、SDP情報をポリシーのリストと一致させ、マッピング情報をRTSPリダイレクタ/プロキシ1218に提供する(1238)。マッピング情報は、各シナリオ(ブロードキャストまたはユニキャストカバレッジ)のために、どのSDPプロファイル接続エンドポイントを使用するのかを示すデータを含む。このように、RTSPリダイレクタは、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することができる。リソースの場所は、ネットワークアドレス、例えば、LTE RAN1206を介して利用可能なアドレスに対応することができる。サービスは、メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つ、例えば、ブロードキャストまたはマルチキャストを定義することができる。

MSDC1208は、その間、サービスのリストを再生アプリケーション1204に渡す(1240)。再生アプリケーション1204は、アプリケーション101(図1)に対応することができる。再生アプリケーション1204は、次いで、(MSDCからサービスのリストと共に提供された) RTSP URI、およびプロキシアドレスを、RTSP/RTPクライアント1202に渡す(1242)。RTSP/RTPクライアント1202がDESCRIBEコマンド(RTSP定義コマンド)を呼び出すと(1244)、RTSPリダイレクタ/プロキシ1218は、ローカルサーバにリダイレクトされた修正されたSDPメッセージを提供する(1246)。RTSP/RTPクライアント1202は、SDP情報を解析し(1248)、ローカルサーバとのRTPセッションをセットアップするためにSETUPコマンド(RTSPコマンド)を呼び出す。RTSP/RTPクライアント1202は、また、サーバとのセットアップが成功すると、PLAYコマンドを渡す(1250)RTSPリダイレクタ/プロキシ1218は、SETUPおよびPLAY要求に対する成功メッセージをRTSP/RTPクライアント1202に提供する(1252)。RTSP/RTPクライアント1202からRTSPリダイレクタ/プロキシ1218によって受信されたSETUPおよびPLAYコマンドは、メディアデータに対する要求の一例を表す。加えて、RTSPリダイレクタ/プロキシ1218は、SETUPおよびPLAYコマンドをMSDC1208(1251)に送る。

RTSPリダイレクタ/プロキシ1218は、メディアデータを受信するためのサービスが利用可能であるかどうか、例えば、トランスポートとしてブロードキャストまたはマルチキャストを定義するサービスが利用可能であるかどうかを判断することができる。RTSPリダイレクタ/プロキシ1218は、RTSPリダイレクタ/プロキシ1218またはMSDC1208がサービスカバレッジエリア内にあるかどうかに少なくとも部分的に基づいて、サービスが利用可能であるかどうかを判断することができる。図12の技術は、サービスが利用可能であることを前提とする。図13は、以下でより詳細に論じるように、サービスが利用できないときに用いられ得る追加の技術を説明する。

一方、ストリーミングサービスのアクティブなブロードキャストセッション中、ネットワークオペレータは、LTE RAN1206を介してRTPコンテンツを送る(1254)。MSDCは、(図12中のeMBMS rX1220とラベル付けられた)ブロードキャスト接続エンドポイントからサービスに関するRTPコンテンツを収集し(1256)、(必要ならば)コンテンツを処理し、RTSPリダイレクタ/プロキシとのSERUPコマンド中に、クライアントによって指定されたエンドポイントでコンテンツをRTSP/RTPクライアント1202に渡す(1258)。このように、サービス(例えば、ブロードキャストまたはマルチキャストトランスポートを定義するサービス)が利用可能であるとき、RTSPリダイレクタ/プロキシ1218は、RTSP/RTPクライアント1202に、MSDC1208(すなわち、例えば、LTE RAN1206を介して、サービスを使用してリソースの場所からメディアデータを受信するユニット)からメディアデータを受信させる。具体的には、この例では、MSDC1208は、サービスをネットワーク上の場所にマッピングするマッピング情報(例えば、上記で説明したUSDデータ)に基づいて、LTE RAN1206を介して、この場所からメディアデータを受信する。

このように、図12の技術は、プロキシユニット(例えば、RTSPリダイレクタ/プロキシ1218)によって、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポート(例えば、ブロードキャスト、マルチキャスト、またはユニキャスト)のうちの少なくとも1つを定義する、ことと、メディアデータに対する要求をアプリケーションサービスクライアント(例えば、RTSP/RTPクライアント1202)から受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させることとを含む方法の一例を示す。メディアデータを受信するユニットは、この例では、MSDC1208に対応する。

図13は、RTPコンテンツのユニキャスト配信のための例示的な手順を示す。この例では、ステップ1232〜1248は、図12を参照して説明したコンテンツのブロードキャスト配信と実質的に同じである。しかしながら、この場合には、RTSP/RTPクライアントがSETUPおよびPLAYコマンドを呼び出すと(1310)、RTSPリダイレクタ/プロキシ1218は、マッピング情報からRAN/インターネット1302を介してユニキャストRTSPサーバと接触し(1312)、コンテンツをユニキャストRTSPサーバから取得し(1314)、ステップ1246でのSETUP、またはSDPで述べられたものの間に、RTSP/RTPクライアント1202によって述べられたエンドポイントにコンテツを渡す(1316)。したがって、この場合には、(RTSP/RTPクライアント1202も含むユーザ機器内に存在し得る)RTSPリダイレクタ/プロキシ1218は、リモートRTSPサーバに対するクライアントとして動作し、RTSP/RTPクライアントの代わりにコンテンツを取得する。

このように、本開示の技術は、RTPコンテンツのeMBMS配信のためのTSP指標を提供するために、SDP拡張メカニズム(属性)を使用することができる。本開示は、また、ブロードキャストとユニキャストトランスポートとの間のシームレスな移行を提供し、UE内のRTPメディアコンテンツ配信メカニズムを提供する例示的なアーキテクチャを定義する。さらに、本開示は、SDPメッセージ内のコンテンツのユニットおよびブロードキャスト配信のための複数のRTPベースのメディアストリームのグループ化のための技術を説明する。

RTSPリダイレクタ/プロキシ1218は、メディアデータを取得するためのサービスに基づいてメディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得することであって、サービスが、メディアデータをトランスポートするための複数のタイプのトランスポート(例えば、ブロードキャスト、マルチキャスト、またはユニキャスト)のうちの少なくとも1つを定義する、ことと、メディアデータに対する要求をアプリケーションサービスクライアントから受信することと、サービスが利用可能であるかどうかを判断することと、サービスが利用可能であるとき、アプリケーションサービスクライアントに、マッピング情報に基づいて、サービスを使用してリソースの場所からメディアデータを受信するユニットからメディアデータを受信させることとを行うように構成され得るプロキシユニットの一例を示す。

図14Aおよび図14Bは、DASHトランスポート情報を担持するためにUSDを拡張するための例示的なXMLコンテンツモデルを示す概念図である。丸で囲んだAは、図14Aと図14Bとの間の接続が結合される点を表す。XMLコンテンツモデルは、単独で、または、上記で説明した技術のいずれかと組み合わせて使用され得る。例えば、図1、図2A、図2B、図6、図7、および/または図8の構成要素は、図14Aおよび図14Bに関して説明するXMLコンテンツモデルを利用するように構成され得る。上記で論じたように、本開示の技術は、ユニキャストトランスポートモードとブロードキャストトランスポートモードとの間で選択するための技術を含む。図14Bは、ブロードキャスト表現(USD内のブロードキャスト要素)とユニキャスト表現(USD内のユニキャスト要素)の両方を定義するデータを示す。

本開示のいくつかの技術によれば、DASHクライアント(例えば、図1、図2A、図2B、図6、図7、および/または図8のDASHクライアント)のようなアプリケーションサービスクライアントは、セグメントを取得する表現の最初の選択を行うことができる。具体的には、DASHクライアントは、要求されたセグメントが属する表現のトランスポートモード(ブロードキャストおよび/またはユニキャスト)に依存しないままで、そのような最初の選択を行うことができる。例示の目的のために、HTTPが、選択された表現のセグメントを要求する際にDASHクライアントによって使用され、図14Bに示す拡張されたUSDが、DASHトランスポート情報を担持するために使用されると仮定する。1つまたは複数のブロードキャスト表現の各々は、broadcast要素の固有のbaseURL属性によって、USD中で識別される。

broadcastの各インスタンスは、MBMSベアラを介して配信される固有の表現に対応する。そのbaseURLは、その表現が要求されているかどうかを判断するために、セグメントを要求するためにDASHクライアントによって使用されるセグメントURLの一部と比較されることになり、具体的には、URIスキームから始まってセグメントが属する表現の識別子まで広がり、その識別子を含んでいるセグメントURLの最初の部分と比較されることになる。

例えば、DASHクライアントによって発行されたセグメントURLが、期間3(Period@id='3')における表現512(Representation@id='512')のセグメント99に対する要求に対応する「http://example.com/per-3/rep-512/seg-99.3gp」であると仮定する。USD内のbasesURLとの一致の目的に関係するこのURLの部分は、「http://example.com/per-3/rep-512」である。表現がブロードキャストを介しても利用可能である場合には、mediaPresentationDescription2.broadcastのインスタンスは、要求URLに関係する部分と同一の「http://example.com/per-3/rep-512」によって与えられるbaseURLを有するUSD内に存在することになる。例えば、USDのbroadcast要素のbaseURL属性との要求URLに関係する部分での一致は、要求されたセグメントが属する表現のブロードキャストトランスポートを示す。

同様に、ゼロ以上のユニキャスト表現の各々は、この例では、mediaPresentationDescription2.unicast要素の固有のbaseURL属性によって、USD内で識別される。上記で論じたように、ユニキャストのbaseURLに対する要求URLの同じ部分での一致パターンは、この表現がユニキャスト配信を介して利用可能であることを意味する。同じ表現は、トランスポートモードの両方、もしくは一方のみを介して利用可能であり得、またはいずれでも利用不可能であり得る。

DASHクライアントがセグメント要求を提出するエンティティは、プロキシユニット(または、MBMSもしくはeMBMSクライアント)であり得る。例示の目的のため、プロキシユニットは、これらの技術を実行するように以下で説明されているが、例えば、図1、図2A、図2B、図6、図7、および/または図8のMBMSまたはeMBMSは、以下で説明するように、プロキシユニットに属する技術を実行するように構成され得ることを理解すべきである。要求URLに関係する部分と、USD内のbroadcastおよびunicast要素中のbaseURLの値との間のパターンマッチングを使用することによって、プロキシユニットは、選択されたトランスポートモードが利用可能であるかどうか、および/または、別のトランスポートモードよりも好ましいかどうかを判断することができる。

プロキシユニットは、トランスポートのタイプの中での優先度を示すポリシーを取得することができる。例えば、ポリシーは、要求がユニキャストを介して配信される表現に対するものである場合、デバイスがブロードキャストカバレッジエリア内にあるかぎり、ブロードキャスト配信される表現のみがDASHクライアントにアクセス可能であるべきであることを示すことができる。そのようなブロードキャスト表現は、baseURLがUSDのidenticalContent要素内に現れる場合、要求されたオリジナルと同じ表現であり得、異なるトランスポートモードを介して配信されるにもかかわらず、要求された表現の代用になり得る。

代替的には、代替の表現に関するbaseURLがUSD要素switchableContentのエントリのリスト内に現れるので、ブロードキャスト表現は、ブロードキャストを介して配信されることが知られている代替の表現であり得、切り替え可能な表現であると見なされる。この場合には、プロキシユニットは、DASHクライアントに、ブロードキャストを介して配信される代替の表現に属する同じセグメントを要求させるために、DASHクライアントにメッセージを送り返すことができる。例えば、プロキシユニットは、リダイレクトメッセージに対応する300タイプのHTTP応答メッセージをDASHクライアントに送ることができ、リダイレクトメッセージは、switchableContentに含まれるリストから代替応答に対応するリソースURLを指定することができる。

別の例として、DASHクライアントが、ブロードキャストを介して配信されるプロキシユニットに知られているセグメントを要求するが、(例えば、クライアントデバイスがブロードキャストトランスポートのカバレッジエリアの外にあるために)ブロードキャスト受信ができない場合、プロキシユニットは、同じ表現、または、同じ表現がユニキャストトランスポートを介して利用できない場合、switchableContent内のエントリとして現れる異なる表現のユニキャストトランスポートに対応するセグメントのURLを含む300タイプのHTTP応答メッセージを送ることができる。

別の例として、DASHクライアントが、ブロードキャストを介して配信されるプロキシユニットに知られているセグメントを要求し、ブロードキャスト受信が利用可能である場合、プロキシユニットは、要求をローカルコンテンツキャッシュにプロキシし、取得されたセグメントをDASHクライアントに配信し戻すことになる。

代替的には、プロキシユニットは、400タイプのエラーメッセージで応答することができ、それは、DASHクライアントに、異なるセグメントURLを使用して要求を再提出させることができる。プロキシユニットは、同様に他の方法で、例えば、アプリケーションプログラミングインターフェース(API)、プロセス間通信(IPC)、選択されたベースURLを省略する修正されたMPDを送ること、などを介して、異なるトランスポートプロトコルを通信することができる。

プロキシユニットからのリダイレクトまたはエラーメッセージは、DASHクライアントに異なるトランスポートモードを選択させることができる。いくつかの例では、2つ以上の表現が、リダイレクトされたトランスポートモードで利用可能であり得、その場合には、DASHクライアントは、これらの利用可能な表現の中から1つを選択することができる。一例として、(図14Aおよび図14Bのbroadcast要素のインスタンスによって与えられるように)DASHクライアントがブロードキャスト表現を選択することを試みているが、プロキシユニットが、ブロードキャスト受信が利用できないと判断した場合、プロキシユニットは、DASHクライアントに図14Aおよび図14Bのユニキャスト表現を代わりに選択させるために、メッセージ(例えば、300タイプのリダイレクトメッセージ、400タイプのエラーメッセージ、API呼び出し、IPC通信を介する、など)をDASHクライアントに送ることができる。

いくつかの例では、DASHクライアントのようなアプリケーションサービスクライアントは、ユニキャスト-ブロードキャストの移行を管理する仕事が割り当てられ得る。本開示は、一例として図14Aおよび図14Bに関連して、MBMSダウンロード配信を介するDASHの場合では、DASHクライアントからのセグメント要求が現状のままで機能されるか、または、1つまたは複数の代替表現からのみであるのかを、MBMSクライアントが判断することを可能にすることができる追加のパラメータでUSDを拡張するためのフレームワークを説明する。USDは、メディアプレゼンテーション記述(MPD)で指定される各表現のトランスポートモード(ブロードキャストのみ、ユニキャストのみ、または、ブロードキャストとユニキャストの両方)を示すことができる。表現の利用可能性を決定するためのルールおよびメカニズムに関する例示的なシナリオは、以下で説明される。

一例では、ユーザ機器(UE)は、MBMSのカバレッジエリア内に配置され得、DASHクライアントは、USDがブロードキャスト配信を介して利用できないことを示す特定の表現を要求することができる。サービスプロバイダのポリシーは、UEがMBMSのカバレッジ内であるときはいつでも、同じプログラムのブロードキャスト配信される表現のみがアクセスされ得ることを指示することができる。この状況では、DASHクライアントは、ブロードキャスト配信介して利用可能な代替配信の中から選択する(または、選択するようにリダイレクトされる、または指示される)ことに限定され得る。

別の例では、UEは、MBMSのカバレッジ内に配置され得、DASHクライアントは、ブロードキャスト配信を介して利用可能であることが知られている表現を要求することができる。この状況では、所望の表現は、UEによって直接アクセスされ得る。

別の例では、UEは、MBMS受信エリアの外にあり得、DASHクライアントは、ブロードキャスト配信を介してのみ利用可能であることが知られている表現を要求することができる。この状況では、DASHクライアントは、切り替え可能なコンテンツの形態でユニキャスト配信を介して利用可能な代替表現の中から選択する(または、選択するようにリダイレクトされる、または指示される)ことに限定され得る。

別の例では、UEは、MBMS受信エリアの外にあり得、DASHクライアントは、ブロードキャストを介して利用可能であることも知られている表現を要求することができる。この状況では、DASHクライアントは、同一のコンテンツの形態でユニキャストを介して同じ表現を受信することができる。

USD内に担持され得る追加の情報は、各表現が配信されるサービスエリア、および/または、その表現を担持するFLUTEセッションを記述するSDPの標識を含む。

本開示は、mediaPresentationDescription2子要素が追加のトランスポートパラメータを担持するためにuserServiceDescriptionの下に追加され得る技術を説明する。以前、ユニキャスト配信を介して利用可能なこれらの表現を識別することができる、期間ID、適合セットID、表現IDのようなMPD固有のパラメータがmediaPresentationDescription2に含まれることが提案された。これらの同じパラメータは、セッション記述フラグメントへのURI参照と共に、ブロードキャストを介して配信され得る各表現、ならびに、その表現のセグメントを担持するFLUTEセッションへのマッピングを識別することができる。

本開示の技術が克服することができる1つの問題は、プロトコル処理でのきれいな階層化分離を維持しながら、セグメント要求/応答のためのDASHクライアントとMBMSクライアントとの間のプロトコルインターフェースとしてのHTTP/1.1の使用を可能にすることに関する。例えば、従来の技術では、MBMSクライアントは、特定の表現のセグメントに対するDASHクライアント要求を、実際に使用可能で、トランスポートモード(ブロードキャストまたはユニキャスト)によって(サービスプロバイダポリシーに従って)許可された表現セグメントに関連付けることができるように、MPD固有の情報を処理しなければならない。1つまたは複数の代替表現をDASHクライアントに知らせるために(http://www.ietf.org/rfc/rfc2616.txtで利用可能な、Fielding他、「Hypertext Transfer Protocol - HTTP/1.1」、Network Working Group、RFC 2616、1999年6月、で定義されているような3xx応答コードを介して)HTTPリダイレクションを使用するMBMSクライアントのために、要求された表現が提供され得ない場合には、MBMSクライアントは、各代替リソースのための完全なセグメントURIを構成しなければならないことになる。MBMSクライアントの側のそのような階層化違反は、本開示の技術の使用によって除去され得る。

本開示の技術は、MBMSクライアント(またはプロキシユニット)が、(DASH固有の)MPD情報を意識する、または処理しなければならない必要性を排除する。MBMSクライアントは、要求されたセグメントが、ブロードキャスト、ユニキャスト、どちらでもない、もしくは両方のトランスポートモードを介して、または、なにか他の方法(例えば、キャッシュ)によって利用可能であるかどうかを判断する際に、USD内の新たなメタデータの存在に基づいてDASHクライアントによって生成されたセグメント要求URIとの、データ/パターンマッチングを単に実行する。これは、要求されたセグメントが属する表現を一意に識別する要求URIの部分もUSDに担持されるので、可能である。加えて、MBMSクライアントは、(トランスポートモードに依存しない)DASHクライアントによって要求される表現が、ブロードキャスト、ユニキャスト、どちらでもない、または両方のトランスポートモードを介して、またはなにか他の方法(例えば、キャッシュ)によって利用可能であるかどうかを、USD内の一致するデータパターンの場所によって判断することができる。カバレッジ条件(UEがユニキャストおよび/またはブロードキャストサービスエリア内であるかどうか)、サービスプロバイダのポリシー、などのような、任意の他の関連するルールおよび条件と併せて、代替リソースURIを返すための代替の方法がUSD属性replacementAllowed='true'に基づいて許可されると仮定する。MBMSクライアントは、セグメント要求を、適切なリソース、例えば、UE内のローカルコンテンツキャッシュ、または外部のHTTPサーバに、プロトコル階層化違反なしに仲介するために、HTTP/1.1メカニズムを使用することができる。

図14Aおよび図14Bの例に見られるように、1つまたは複数のブロードキャスト表現の各々は、broadcast要素の固有のbaseURL属性によってUSD内で識別される。baseURL値は、その表現のセグメントを要求するためにDASHクライアントによって使用されるセグメントIDの一部と同一であり得、具体的には、方法から始まって表現IDまで広がり、この表現IDを含んでいるセグメントIDの最初の部分と同一であり得る。例えば、セグメントIDが、周期3中の表現512(RepresentationID=512)のセグメント99に対する要求に対応するURL「http://example.com/per-3/rep-512/seg-99.3gp」である場合、baseURLは、「http://example.com/per-3/rep-512」として定義され得る。

この例では、1つまたは複数のブロードキャスト表現の各々は、broadcast要素の固有のbaseURL属性によってUSD内で識別される。broadcastの各インスタンスは、MBMSベアラを介して配信される固有の表現に対応する。そのbaseURLは、セグメントを要求するためにDASHクライアントによって使用されるセグメントURLの一部と比較されることになり、具体的には、URIスキームから始まって表現ID(Representation@id in the MPDの値)まで広がり、この表現IDを含んでいるセグメントURLの最初の部分と比較されることになる。例えば、DASHクライアントによって発行されたセグメントURIが、期間3(Period@id='3')における表現512 (Representation@id='512')のセグメント99に対する要求に対応する「http://example.com/per-3/rep-512/seg-99.3gp」であると仮定する。USDとの一致の目的に関係するこのURLの部分は、「http://example.com/per-3/rep-512」である。この表現がブロードキャストを介しても利用可能である場合には、mediaPresentationDescription2.broadcastのインスタンスは、要求URLに関係する部分と同一の「http://example.com/per-3/rep-512」によって与えられるbaseURLを有するUSD内に存在することになる。

MBMSクライアントが、DASHクライアントによって要求されたものの代替表現のみがアクセスされ得ると判断したとき、mediaPresentationDescription2のreplacementAllowed属性は、そのような通知を、例えば、RFC2616に定義されているようなHTTPリダイレクト(3xxステータスコード)を介してDASHクライアントに提供するべきか、およびどのように提供するのかを、MBMSクライアントに示すことができる。

例えば、replacementAllowed = 'true'の場合、MBMSクライアントが、代替表現のトランスポートモードにかかわらず、「303 See Other」リダイレクションを介して代替リソースURIをDASHクライアントに提供することを可能にするような方法で、DASHコンテンツおよびMPDが作成されるものとすることができる。具体的には、各代替URLは、元の要求のセグメント番号を保持しながら、セグメントURI中の関係する部分を、上記で説明したように、代替表現に対応するUSD中のbaseURLに置き換えることによって形成され得る。

他方では、replacementAllowed='false'の場合、代替リソースURLを生成し、それをDASHクライアントに提供するためのそのような置き換え方法は、許可されない可能性がある。代替表現を要求させ、配信させるための得られた技術は、実施態様依存であり得る(例えば、MBMSクライアントは、baseURL値によってシグナリングされた代替表現を伴う4xxエラーコードを返し、代替要求を定式化することをDASHクライアントに依存することができる)。HTTP「303」リダイレクションに基づくMBMSクライアントとDASHクライアントの間の相互作用を示す例示的なコールフローは、図15および図16に関連して以下に説明される。

同様に、ゼロ以上のユニキャスト表現の各々は、mediaPresentationDescription2.unicast要素の固有のbaseURL属性によって、USD内で識別され得る。上記で論じたように、ユニキャストのbaseURLに対する要求URIの同じ部分での一致パターンは、この表現がユニキャスト配信を介して利用可能であることを意味する。同じ表現は、トランスポートモードの両方、もしくは一方のみを介して利用可能であり得、またはいずれでも利用不可能であり得ることに留意されたい。

それ以外の場合、sessionDescription要素を介して、各ブロードキャスト表現は、その表現を担持するFLUTEセッションに属するセッション記述フラグメントまたはSDPドキュメントにリンクされ得る。加えて、serviceArea要素は、存在する場合、ブロードキャスト表現が利用可能なMBMSサービスエリアを示すことができる。

図15は、MBMSを介するDASHをサポートするためのアーキテクチャを示す概念図である。図15の例は、ユニキャストフォールバックによるMBMSベアラを介するDASHコンテンツ配信のためのエンドツーエンドネットワークアーキテクチャを表す。FLUTEベースのダウンロード配信は、BM-SCとMBMSクライアントとの間のTS26.346で定義されたインターフェースを表す。DASHクライアントとMBMSクライアント(ここでは、MBMS受信機、デバイスベースのHTTPサーバ、ポリシー、リダイレクション、およびプロキシ機能を含む複合エンティティであると仮定する)との間の想定されるインターフェースは、HTTP/1.1である。

図16は、ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図15のネットワークアーキテクチャに関連するコールフローを示す流れ図である。図16に関して説明する技術は、DASHトランスポート情報を担持するための図14Aおよび図14Bに示すUSD拡張に基づく。図15のネットワークアーキテクチャに従うものとして説明したが、図16の技術は、他のデバイス、例えば、図1、図2A、図2B、図6、図7、図8、および/または図17中のアーキテクチャにおけるデバイスによって実行され得る。図16の例では、USDが、mediaPresentationDescription2.broadcastおよびmediaPresentationDescription2.unicastの下のbaseURL属性の値を含むTable 3(表3)に示す情報を含むことを仮定し、USD内のreplacementAllowed属性の値は、「真」であると仮定する。

さらに、この例では、MPDが以下の内容を含むことを仮定する。
・MPD@type='dynamic'
・Period@id='3'
・Period.SegmentTemplate@media='http://example.com/per-3/rep-$RepresentationID$/seg-$Number$.3gp'
○Representation@id='512'...
○Representation@id='256'...
○Representation@id='128'...

これらの例示的なMPDパラメータ値が与えられると、期間3における表現512に関するセグメント番号99を要求しようとするDASHクライアントは、以下の要求URI, http://example.com/per-3/rep-512/seg-99.3gpを発することができる。図16のコールフローは、2つの異なる状況、1)UEは、MBMSカバレッジ内であり、ブロードキャスト配信を介して利用可能な期間3の表現512のセグメントを要求し、その後、2)UEは、MBMSカバレッジの外に移動し、ユニキャスト配信を介して利用できない同じ表現(すなわち、表現512)を要求し続けるが、表現256および128は、ユニキャストを介して利用可能である、に関するDASHコンテンツ配信を説明する。

言い換えれば、本開示は、トランスポートダイバーシティのサポートにおけるDASHトランスポートのUSDベースのシグナリングの使用のためのいくつかの技術を説明する。それは、Qualcomm Inc.からのTdoc S4-130051、「Rationale for USD Indication of DASH Delivery Mode and Illustrative Implementation」に記載の以前の提案を上回る1つまたは複数の改善を提供することができる。例えば、MBMSクライアントは、MPD情報を理解または処理する必要がないので、階層化違反は、この方法で完全に回避され得る。代わりに、MBMSクライアントは、要求されたセグメントがブロードキャストおよび/またはユニキャストを介して配信されることを要求されているかどうか、ならびに、その要求が、別のトランスポートモードを使用して利用可能な同じまたは代替の表現にリダイレクトされる、またはリダイレクトされることを要求されているかどうかを判断するために、DASHクライアントによって要求されるセグメントのURIに対する既知のトランスポートセマンティクスのデータパターンマッチングを実行することができる。

そのような判断は、UEがMBMSカバレッジの内または外のいずれにあるか、もしあれば、サービスプロバイダのポリシー、トランスポートモードによる表現のアクセス可能性の管理、および、おそらく他の条件またはルールに依存する、のような要因に基づくことができる。ユニキャストフォールバックによるMBMSを介するDASHコンテンツ配信のための例示的なネットワークアーキテクチャおよびコールフロー図は、DASHクライアントとMBMSクライアントとの間のHTTPプロトコルインターフェースの使用を特徴とするエンドツーエンドコンテンツ配信を説明するために提供された。プロトコル階層化の遵守は、MBMS内DASH(DASH-in-MBMS)サービスのサポートにおけるUE実施態様の拡張性および単純性の構造上の利益を提供すべきである。

DASHクライアントアクセスを代替リソース(表現)に制限するための、MBMSクライアントによる3xxステータスコードを介するHTTPリダイレクトの使用は、値「真」を有するmediaPresentationDescription2's replacementAllowed属性を前提とする。そのような場合には、代替表現のトランスポートモードにかかわらず、MBMSクライアントが「303 See Other」リダイレクションを介してDASHクライアントに代替リソースURIを提供することを可能にするような方法で、DASHコンテンツおよびMPDが作成されるものとする。具体的には、各代替URLは、元の要求のセグメント番号を保持しながら、セグメントURL中の関係する部分を、上記で説明したように、代替表現に対応するUSD中のbaseURLに置き換えることによって形成される。replacementAllowed='false'の値の場合、代替リソースURIを生成し、それをDASHクライアントに提供するためのそのような置き換え方法は、許可されない。

代替表現を要求させ、配信させるための得られた技術は、実施態様依存であり得る。例えば、MBMSクライアントは、HTTP応答のエンティティボディ内のbaseURLによってシグナリングされた代替表現を伴うまたは伴わない4xxエラーコードを返し、代替要求を形成することをDASHクライアントに依存することができる。ここで、代替表現が応答において利用可能であることを識別するbaseURLの存在は、その代替表現をフォローアップとして直接要求するインテリジェンスによるDASHクライアントへのヒントとして使用され得る。代替的には、baseURL「ヒント」は、4xx応答内で提供されない可能性があり、または、DASHクライアントは、MBMSクライアントの視点から許可された表現に対応してもしなくてもよい別の表現に対する新たな要求を生成する際にそのようなヒントを利用するインテリジェンスに欠ける可能性がある。

図17は、MBMSを介するDASHをサポートするための別の例示的なアーキテクチャを示す概念図である。適切な標準で、BM-CSとeMBMSクライアントとの間のインターフェース、およびeMBMSクライアントとDASHクライアントとの間のインターフェースを指定することが重要である可能性がある。例えば、標準は、BM-CSとeMBMSクライアントとの間のインターフェースがTS 26.346に従うべきであることを指定することができる。標準は、また、DASHクライアントおよびeMBMSクライアントが異なるベンダーからのものである場合、eMBMSクライアントとDASHクライアントとの間のインターフェースがTS 26.247に従うべきであることを指定することができる。図16の例と対比すると、図17は、DASHクライアントとeMBMSクライアントとの間のインターフェースがTS 26.247(例えば、HTTP/1.1であり得る)に従うことができる一例を示す。図17は、MBMSを介するDASHがユニキャストを介するDASHにフォールバックされることを可能にする高レベルのアーキテクチャを示す。

図18〜図23は、ブロードキャストおよびユニキャストトランスポートを介するDASHコンテンツ配信のための図17のネットワークアーキテクチャに関連する様々な例示的なコールフローを示す流れ図である。図17のネットワークアーキテクチャに対応するものとして説明したが、図18〜図23の技術は、他のデバイス、例えば、図1、図2A、図2B、図6、図7、図8、および/または図15のアーキテクチャ中のデバイスによって実行され得ることを理解すべきである。

図18の例に関して、USDシグナリングは、eMBMSクライアントに関して以下のTable 4(表4)に示すデータを含むことができる。

この例のMPDは、以下のデータを指定することができ、ここで、BaseURLは、セグメントにアクセスするためのURLのベース部分に対応し、

BaseURL1=http://www.cnn.com/512/、RepresentationId="512";Template=seg$Number$.3gp、

BaseURL2=http://www.cnn.com/256/、RepresentationId="256";Template=seg$Number$.3gp、

BaseURL3=http://www.cnn.com/128/、RepresentationId="128";Template=seg$Number$.3gpである。

図18の例では、eMBMSクライアントは、HTTPプロキシ機能を有するが、HTTPリダイレクタ機能のみを有するものとする。

図19の例に関して、USDシグナリングは、eMBMSクライアントに関する以下のTable 5(表5)に示すデータを含むことができる。

BaseURL1=http://www.cnn.com/512/、RepresentationId="512";Template=seg$Number$.3gp,

BaseURL2=http://www.cnn.com/256/、RepresentationId="256";Template=seg$Number$.3gp,

図19の例では、eMBMSクライアントは、HTTPプロキシとHTTPリダイレクタ機能の両方を有するものとする。

図20の例に関して、USDシグナリングは、eMBMSクライアントに関する以下のTable 6(表6)に示すデータを含むことができる。

BaseURL1.1=http://www.cnn.com/512/、BaseURL1.2=http://localhost/512/、RepresentationId="512";Template=seg$Number$.3gp、

図20の例では、eMBMSクライアントは、HTTPプロキシ機能を持たず、HTTPリダイレクタ機能のみを有するものとする。

図21の例に関して、USDシグナリングは、eMBMSクライアントに関する以下のTable 7(表7)に示すデータを含むことができる。

この例のMPDは、以下のデータを指定することができ、ここで、BaseURLは、セグメントにアクセスするためのURLのベース部分に対応し、
BaseURL1=http://www.cnn.com/;
RepresentationId="512";Template=$RepresentationId$/seg$Number$.3gp、
RepresentationId="256";Template=$Representagtion$/seg$Number$.3gp、
RepresentationId="128";Template=$Representagtion$/seg$Number$.3gpである。

図21の例では、eMBMSクライアントは、HTTPプロキシ機能を持たず、HTTPリダイレクタ機能のみを有するものとする。

図22の例に関して、USDシグナリングは、eMBMSクライアントに関する以下のTable 8(表8)に示すデータを含むことができる。

BaseURL1=http://localhost/512/、RepresentationId="512";Template=seg$Number$.3gp、

図22の例では、eMBMSクライアントは、HTTPプロキシ機能を持たず、HTTPリダイレクタ機能のみを有するものとする。

図23の例に関して、USDシグナリングは、eMBMSクライアントに関する以下のTable 9(表9)に示すデータを含むことができる。

BaseURL1=http://www.cnn.com/1024/、RepresentationId="1024";Template=seg$Number$.3gp、

BaseURL2=http://www.cnn.com/512/、RepresentationId="512";Template=seg$Number$.3gp、

BaseURL3=http://www.cnn.com/256/、RepresentationId="256";Template=seg$Number$.3gp、

BaseURL4=http://www.cnn.com/128/、RepresentationId="128";Template=seg$Number$.3gpである。

図23の例では、eMBMSクライアントは、HTTPプロキシ機能を持たず、HTTPリダイレクタ機能のみを有するものとする。

図24は、本開示の技術に関連するタイムシフトバッファ(TSB)に関するデータをシグナリングするための例示的な方法を示すフローチャートである。例示の目的のため、図25の方法は、図10の構成要素、例えば、MSDC1010およびTSB1212に関して説明される。しかしながら、タイムシフトバッファを利用するための技術は、本明細書に記載の様々なシステム、例えば、図1、図7、図8、図9、図12、図13、および/または図17のいずれかのシステムに組み込まれ得ることを理解すべきである。

最初に、MSDC1010は、セッション記述プロトコル(SDP)メッセージを受信することができる(2400)。SDPメッセージは、タイムシフトバッファ(TSB)深度を定義する属性を含むことができる。したがって、MSDC1010は、SDPメッセージ内の属性(TSB深度属性とも呼ばれる)の値を決定することができる(2402)。TSB深度属性の値は、例えば、TSBに記憶されるメディアデータの再生の秒でTSBの深度を定義することができる。例えば、属性の値は、TSBに記憶され得る最大再生時間を秒で定義することができる。

MSDC1010は、したがって、シグナリングされた深度からTSBを形成するために割り当てられるメモリの量を決定することができる(2404)。例えば、TSBの深度がメディアデータの再生の秒でシグナリングされるとし、フレームレートがビデオデータに関してシグナリングされるとして、MSDCは、(毎秒フレーム数で表される)フレームレートと、記憶されるメディアデータの秒数の積として、TSBに記憶されるビデオフレームの数を決定することができる。MSDC1010は、次いで、フレームあたりの平均ビットレートとフレーム数の積に基づいて、TSBのためのメモリの量を決定することができる。MSDC1010は、オーディオデータ、タイムドテキストデータ、などのためのメモリサイズを決定するために、同様の概念を使用することができる。

MSDC1010は、次いで、TSBを形成するために、決定された量のメモリを割り当てることができる(2406)。したがって、MSDC1010がメディアデータを受信するとき、MSDC1010は、受信したメディアデータをTSBに記憶することができる(2408)。再生アプリケーションは、後で観るため、または、早送りもしくは巻き戻しのようなトリックモードを実行するためのような、タイムシフト用途のために、このバッファリングされたメディアデータを使用することができる。もちろん、バッファリングされたデータは、また、実質的にリアルタイムの再生のために使用され得る。

このように、図24の方法は、タイムシフトバッファ(TSB)深度を定義する属性を含むセッション記述プロトコル(SDP)メッセージを受信することと、属性の値に基づいてTSBのためのメモリの量を決定することと、決定された量のメモリをTSBに割り当することと、SDPメッセージに関連付けられたメディアデータの少なくとも一部をTSBに記憶することとを含む方法の一例を表す。

当業者は、情報および信号が、任意の様々な異なるテクノロジーおよび技術を使用して表され得ることを理解するであろう。例えば、上記の説明を通して参照され得るデータ、命令、コマンド、情報、信号、ビット、記号、およびチップは、電圧、電流、電磁波、磁場もしくは粒子、光場もしくは粒子、またはそれらの任意の組み合わせによって表され得る。

当業者は、さらに、本明細書の開示と組み合わせて説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせとして実施され得ることを理解するであろう。ハードウェアおよびソフトウェアのこの互換性を明確に説明するために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、それらの機能性の観点から、一般的に上記で説明されてきた。そのような機能性が、ハードウェアまたはソフトウェアのいずれとして実施されるのかは、システム全体に課される特定の用途および設計に依存する。当業者は、説明した機能性を、各々の特定の用途のための様々な方法で実施することができるが、そのような実施の決定は、本開示の範囲からの逸脱を引き起こすと解釈されるべきではない。

1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実現され得る。ソフトウェアで実現される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして記憶または送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体のような有形の媒体に対応するコンピュータ可読記憶媒体、または、例えば、通信プロトコルに従う、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含むことができる。このように、コンピュータ可読媒体は、一般的に、(1)非一時的である有形のコンピュータ可読記憶媒体、または(2)信号もしくは搬送波のような通信媒体に対応することができる。データ記憶媒体は、本開示で説明した技術の実施態様のための命令、コード、および/またはデータを取得するために、1つもしくは複数のコンピュータ、または1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。

例として、限定ではなく、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、もしくは他の光ディスク記憶装置、磁気ディスク記憶装置、もしくは他の磁気記憶デバイス、フラッシュメモリ、または、所望のプログラムコードを命令もしくはデータ構造の形態で記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含むことができる。また、任意の接続は、適切にコンピュータ可読媒体と呼ばれる。例えば、命令が、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバケーブル、より対線、デジタル加入者線(DSL)、または、赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバケーブル、より対線、DSL、または、赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まず、代わりに、非一時的な有形の記憶媒体を対象とすることを理解すべきである。ディスク(disk)およびディスク(disc)は、本明細書で使用されるとき、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスク(登録商標)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。

命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPLA)、または他の同等の集積されたもしくは個別的な論理回路網のような、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明した技術の実施に適した任意の他の構造のいずれかを指すことができる。加えて、いくつかの態様では、本明細書で説明した機能性は、符号化および復号化のために構成された専用のハードウェアおよび/もしくはソフトウェアモジュール内に設けられ得、または、組み合わされたコーデックに組み込まれ得る。また、技術は、1つもしくは複数の回路、または論理要素において完全に実施され得る。

本開示の技術は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(例えばチップセット)を含む、多種多様なデバイスまたは装置において実施され得る。様々な構成要素、モジュール、またはユニットが、開示した技術を実行するように構成されたデバイスの機能的態様を強調するように本開示で説明されているが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニットで組み合わされ得、または、適切なソフトウェアおよび/もしくはファームウェアと併せて、上記で説明したように1つまたは複数のプロセッサを含む相互運用ハードウェアユニットの集合によって提供され得る。

添付図面に関連して上述した詳細な説明は、様々な構成の説明として意図され、本明細書に記載の概念が実施され得る唯一の構成を表すことを意図されていない。詳細な説明は、様々な概念の完全な理解を提供する目的のための特定の詳細を含む。しかしながら、これらの概念がこれらの特定の詳細なしに実施され得ることは、当業者には明らかであろう。いくつかの例では、周知の構造および構成要素は、そのような概念を不明瞭にすることを避けるために、ブロック図形式で示される。

様々な例を説明してきた。これらおよび他の例は、以下の特許請求の範囲内にある。

100 システム
101 アプリケーション
101A UE
101B UE
102 アプリケーションサービスクライアント
102A アプリケーションサービスクライアント
102B アプリケーションサービスクライアント
104 リダイレクタ/プロキシ
104A リダイレクタ/プロキシ
104B リダイレクタ/プロキシ
106 コントローラ
108 ポリシーデータベース
110 トランスポートミドルウェア
110A トランスポートA
110R トランスポートR
120 コンテンツサーバ
122 インターネット
200A システム
200B システム
310 コンテンツサーバ
320 プロセスフロー
400 プロセスフロー
600 装置
602 電気構成要素、モジュール
604 電気構成要素、モジュール
606 電気構成要素、モジュール
610 プロセッサ構成要素、プロセッサ
612 バス
614 ネットワークインターフェース構成要素
616 メモリ構成要素
700 ネットワーク
702 アプリケーションサービスクライアント
704 メディアアプリケーション
706 HTTPリダイレクタ/プロキシ
708 コントローラ
710 サーバ
712 ミドルウェア
714 キャッシュ
716 ポリシーマネージャ
802 DASHクライアント
804 再生アプリケーション
806 インターネット
808 MSDC
810 キャッシュ
812 サーバ
814 コントローラ
816 ポリシーデータベース
818 HTTPリダイレクタ/プロキシ
820 MBMS送信ユニット
910 MSDC
1010 MSDC
1202 RTSP/RTPクライアント
1204 再生アプリケーション
1206 LTE RAN
1208 eMBMSミドルウェア、MSDC
1210 キャッシュ
1212 サーバ
1214 コントローラ
1216 ポリシーマネージャ
1218 RTSPリダイレクタ/プロキシ
1220 ブロードキャスト送信ユニット、eMBMS rX

Claims

メディアデータを取得する方法であって、前記方法が、
プロキシユニットによって、
メディアデータを取得するためのサービスに基づいて、前記メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得するステップであって、前記サービスが、前記メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、ステップと、
アプリケーションサービスクライアントからの前記メディアデータに対する要求を受信するステップと、
前記サービスが利用可能であるかどうかを判断するステップと、
前記サービスが利用可能であるとき、前記アプリケーションサービスクライアントに、
前記マッピング情報に基づいて、前記サービスを使用して前記リソースの場所から前記メディアデータを受信するユニットから前記メディアデータを受信させるステップと
前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップと、
を含む、方法。
前記リソースの場所がネットワーク上の場所を含み、前記方法が、
前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するとき、前記アプリケーションサービスクライアントに前記ネットワーク上の場所から前記メディアデータを取得させるために、前記メディアデータの前記識別子が前記マッピング情報中でマッピングされた前記ネットワーク上の場所を指定するリダイレクトメッセージを前記アプリケーションサービスクライアントに送るステップと
をさらに含む、請求項1に記載の方法。
前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致しないとき、前記アプリケーションサービスクライアントにデフォルトのリダイレクションのネットワーク上の場所から前記メディアデータを取得させるために、前記デフォルトのリダイレクションのネットワーク上の場所を指定するリダイレクトメッセージを前記アプリケーションサービスクライアントに送るステップをさらに含む、請求項2に記載の方法。
前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致しないとき、前記アプリケーションサービスクライアントに前記要求のコピーを送り返すステップをさらに含む、請求項2に記載の方法。
前記マッピング情報をマッピングテーブル内に記憶するステップをさらに含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、メディアデバイスの識別子が前記マッピングテーブル内のエントリに対応するかどうかを判断するステップを含む、請求項2に記載の方法。
前記マッピング情報が、ユニフォームリース識別子(URI)プレフィックスとして表されるマッピング基準を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、前記要求に示された前記メディアデータのURIの少なくとも一部と一致する前記マッピング情報のURIプレフィックスを決定するステップを含む、請求項2に記載の方法。
前記要求に示された前記メディアデータのURIの少なくとも一部と一致する前記マッピング情報のURIプレフィックスを決定するステップが、前記要求に示された前記メディアデータのURIの少なくとも一部と一致する前記マッピング情報の最長のURIプレフィックスを決定するステップを含む、請求項6に記載の方法。
前記マッピング基準によって表される前記URIプレフィックスが、メディアデータをトランスポートするためのトランスポートのタイプを定義するそれぞれのサービスに対応し、前記URIプレフィックスのうちの第1のURIプレフィックスが、ブロードキャストサービスを定義し、前記URIプレフィックスのうちの第2のURIプレフィックスが、ユニキャストサービスを定義する、請求項6に記載の方法。
前記マッピング情報が、各々の潜在的な一致に関する優先順位値を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、最も高い優先順位値を有する一致を選択するステップを含む、請求項2に記載の方法。
前記マッピング情報が、各々の潜在的な一致に関する優先順位値を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、最も低い優先順位値を有する一致を選択するステップを含む、請求項2に記載の方法。
前記マッピング情報が、正規表現として表されるマッピング基準を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、前記要求で示された前記メディアデータの識別子と直接一致する最大数の文字と一致する正規表現を選択するステップを含む、請求項2に記載の方法。
前記マッピング情報が、正規表現として表されるマッピング基準を含み、前記マッピング情報が、各々の潜在的な一致に関する優先順位値を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、最も高い優先順位値を有する一致を選択するステップを含む、請求項2に記載の方法。
前記マッピング情報が、正規表現として表されるマッピング基準を含み、前記マッピング情報が、各々の潜在的な一致に関する優先順位値を含み、前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するステップが、最も低い優先順位値を有する一致を選択するステップを含む、請求項2に記載の方法。
前記サービスが利用可能であるかどうかを判断するステップが、前記プロキシユニットがサービスカバレッジエリア内にあるかどうかを判断するステップを含む、請求項1に記載の方法。
前記要求が、動的適応型ストリーミングオーバHTTP(DASH)要求に適合し、前記方法が、
前記プロキシユニットによって、
前記DASH要求を受信するステップであって、前記DASH要求が、前記プロキシユニットのネットワークアドレスを指定する、ステップと、
前記DASH要求に応答して、前記要求に指定された前記メディアデータを受信し、前記メディアデータを前記アプリケーションサービスクライアントに提供するステップとをさらに含む、請求項1に記載の方法。
メディアデータを取得するためのデバイスであって、前記デバイスが、
メディアデータを取得するためのサービスに基づいて、前記メディアデータの識別子をリソースの場所にマッピングするマッピング情報を取得するための手段であって、前記サービスが、前記メディアデータをトランスポートするための複数のタイプのトランスポートのうちの少なくとも1つを定義する、手段と、
アプリケーションサービスクライアントからの前記メディアデータに対する要求を受信するための手段と、
前記サービスが利用可能であるかどうかを判断するための手段と、
前記サービスが利用可能であるとき、前記アプリケーションサービスクライアントに、前記マッピング情報に基づいて、前記サービスを使用して前記リソースの場所から前記メディアデータを受信するユニットから前記メディアデータを受信させるための手段と、
前記要求で指定された前記メディアデータが前記マッピング情報中の前記メディアデータと一致するかどうかを判断するための手段と、
を備えるプロキシユニット
を備える、デバイス。
前記メディアデータを受信するミドルウェアユニットをさらに備え、前記ミドルウェアユニットが、マルチメディアブロードキャストマルチキャストサービス(MBMS)ミドルウェアユニットと、進化型MBMS(eMBMS)ミドルウェアユニットとのうちの一方を備える、請求項16に記載のデバイス。
前記デバイスが、プロキシデバイスを備え、クライアントデバイスが、前記アプリケーションサービスクライアントを備え、前記プロキシデバイスが、前記クライアントデバイスと別である、請求項16に記載のデバイス。