関連出願の相互参照
本特許出願は、本明細書の譲受人に譲渡され、その内容全体が参照により本明細書に明確に組み込まれている、以下の仮出願の優先権を主張する:「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、2012年1月16日に出願された第61/587,103号、「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、2012年4月13日に出願された第61/623,965号、「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、2012年5月14日に出願された第61/646,873号、および「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、2012年10月29日に出願された第61/719,936号。
本開示の態様は、一般に、ワイヤレス通信システムに関し、より詳細には、動的適応ストリーミングオーバーHTTP(DASH:Dynamic Adaptive Streaming over HTTP)サービスの管理に関する。
ワイヤレス通信ネットワークは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャストなどの様々な通信サービスを提供するために広く展開されている。これらのワイヤレスネットワークは、利用可能なネットワークリソースを共有することによって、マルチプルなユーザをサポートすることが可能な多元接続ネットワークであり得る。そのような多元接続ネットワークの例には、符号分割多元接続(CDMA)ネットワーク、時分割多元接続(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、およびシングルキャリアFDMA(SC−FDMA)ネットワークが含まれる。
ワイヤレス通信ネットワークは、モバイルエンティティとも呼ばれるいくつかのユーザ機器(UE)の通信をサポートすることができるいくつかの基地局を含み得る。UEは、ダウンリンクおよびアップリンクを介して基地局と通信することができる。ダウンリンク(または順方向リンク)は基地局からUEへの通信リンクを指し、アップリンク(または逆方向リンク)はUEから基地局への通信リンクを指す。本明細書で使用される場合、「基地局」は、ワイヤレス通信システムのeノードB(eNB)、ノードB、ホームノードB、または同様のネットワークコンポーネントを意味する。
第3世代パートナーシッププロジェクト(3GPP)のロングタームエボリューション(LTE)は、モバイル通信用グローバルシステム(GSM(登録商標))およびユニバーサルモバイルテレコミュニケーションシステム(UMTS)の発展形として、セルラー技術における大きな進歩を代表するものである。LTEの物理層(PHY)は、発展型ノードB(eNB)などの基地局と、UEなどのモバイルエンティティとの間でデータと制御情報の両方を伝達する高効率な方法を提供する。従来の適用例では、マルチメディア用の高帯域幅通信を容易にするための方法は、単一周波数ネットワーク(SFN)動作であった。SFNは、たとえば、eNBなどの無線送信機を利用して加入者UEと通信する。ユニキャスト動作では、各eNBは、1つまたは複数の特定の加入者UEに向けられた情報を搬送する信号を送信するために制御される。ユニキャストシグナリングの特異性により、たとえば、音声通話、テキストメッセージング、またはビデオ通話などの人対人サービスが可能になる。
動的適応ストリーミングオーバーHTTP(DASH)により、ユニキャスト・トランスポート・プロトコルであるハイパーテキスト転送プロトコル(HTTP)を介して、連続(ストリーミング)メディアコンテンツを配信するサービスが可能になる。DASHコンテンツのユニキャストとブロードキャストの同時配信、ならびに、ユニキャスト配信とブロードキャスト配信との間およびその逆の遷移の処理は、完全には定義されていない。ブロードキャスト配信に関連する待ち時間は、また、そのような遷移にさらなる課題を与える。ブロードキャストアベイラビリティ調整(たとえば、アベイラビリティの先延ばし(delay)または前倒し(advance))に関する情報は、ネットワークの展開に依存し、ユニキャスト配信とブロードキャスト配信との間のシームレスな遷移を実現するために、モバイルエンティティに対して利用可能にされるべきである。ブロードキャストを介したDASHセグメントの配信に関係する情報は、DASHクライアントに配信される必要があり得、そのような情報には、コンテンツのユニキャストバージョンの受信に対する地理的制約、コンテンツのどの表現(representation)が所与のエリア内でブロードキャストを介して利用可能であるかに関する情報、同じコンテンツの異なる表現を搬送する適切なブロードキャスト・トランスポート・セッションの発見を可能にする情報、およびオフロードユニキャストDASHトラフィックへのオンデマンドDASHサービスをサポートする情報が含まれ得る。したがって、DASHのコアユニキャスト機能に影響を及ぼすことなくブロードキャスト配信をサポートするパラメータを伝達するための技法も必要とされる。
図面において示される本発明の例示的な実施形態が、以下で要約される。これらおよび他の実施形態は、詳細な説明のセクションにおいてより十分に記載される。しかしながら、本発明をこの発明の概要または詳細な説明において記載される形態に限定する意図はないことを理解されたい。
ブロードキャストとマルチキャストは本明細書では同義であることに留意されたい。いくつかのブロードキャストネットワークでは、ブロードキャストストリーム化されたコンテンツは、また、ユニキャストを介して利用可能にされ得るまたはアクセスされ得ることに、さらに留意されたい。そのようなコンテンツの代替的な配信は、ブロードキャストカバレージ内にない間にブロードキャストストリーミングサービス用のコンテンツにアクセスするために、ユニキャストフォールバック技法を提供する。1つの問題は、ブロードキャストDASHサービスが様々な位置で様々なバージョンのコンテンツ(たとえば、様々な表現)を配信できることである。様々な表現は、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であることもあり得る。
本明細書に記載された実施形態の1つまたは複数の態様によれば、ワイヤレス通信システム内のモバイルエンティティによって動作可能な方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション(MPD)を受信することを含むことができる。方法は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法は、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法は、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現についてのデータセグメントを受信することを含むことができる。関係する態様では、電子デバイス(たとえば、モバイルエンティティまたはそのコンポーネント)は、上述された方法を実行するように構成することができる。
本明細書に記載された実施形態の1つまたは複数の態様によれば、モバイルエンティティによって動作可能な別の方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介して、(a)DASH MPDと、(b)コンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することを含むことができる。方法は、ブロードキャスト送信のためのパラメータおよびモバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法は、ブロードキャストファイル配信セッションにおいて所与の表現についてのデータセグメントを受信することを含むことができる。関係する態様では、電子デバイス(たとえば、モバイルエンティティまたはそのコンポーネント)は、上述された方法を実行するように構成され得る。
本明細書に記載された実施形態の1つまたは複数の態様によれば、ネットワークエンティティによって動作可能な方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むMPDを送信することを含むことができる。方法は、コンテンツの所与の表現に関する要求を受信することを含むことができる。方法は、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、ファイル配信セッションにおいて所与の表現についてのデータセグメントを送信することを含むことができる。関係する態様では、電子デバイス(たとえば、ネットワークエンティティまたはそのコンポーネント)は、上述された方法を実行するように構成され得る。
上記および関係の目的を達成するために、1つまたは複数の実施形態は、以下で十分に記載され、特に特許請求の範囲で指摘される特徴を含む。以下の説明および添付の図面は、1つまたは複数の実施形態のいくつかの例示的な態様を詳細に説明する。しかしながら、これらの態様は、様々な実施形態の原理が使用され得る様々な方法のほんのいくつかを示すものであり、記載された実施形態は、すべてのそのような態様およびそれらの等価物を含むものとする。
テレコミュニケーションシステムの一例を概念的に示すブロック図。
テレコミュニケーションシステム内のダウンリンクフレーム構造の一例を概念的に示すブロック図。
本開示の一態様に従って構成された基地局/eNBおよびUEの設計を概念的に示すブロック図。
ユニキャスト信号およびマルチキャスト信号のためのシンボルの割当ての一例を示すシグナリングフレームの図。
MBMSオーバー単一周波数ネットワーク(MBSFN)サービスエリア内のMBSFNエリアを示す図。
MBSFNサービスを提供またはサポートするためのワイヤレス通信システムのコンポーネントを示すブロック図。
DASH MPDの一実施形態を示す図。
DASH MPD内のBaseURLの一実施形態を示す図。
eMBMS USD内のバンドルディスクリプションの一実施形態を示す図。
eMBMSのためのUSDの一実施形態を示す図。
eMBMSのためのUSDの別の実施形態を示す図。
eMBMS USD内のdeliveryMethodディスクリプションの一実施形態を示す図。
MPDレベルにある複数のBaseURLの一実施形態を示す図。
DASHセグメントアベイラビリティタイムラインの一実施形態を示す図。
保護期間に関する暗黙の考慮事項の一例を示す図。
UC−BC遷移についての例示的なタイムラインを示す図。
ユニキャスト取出しセグメントについての様々なプレイバック遅延の例を示す図。
ブロードキャスト取出しセグメントについての様々なプレイバック遅延の例を示す図。
BC−UC遷移に関する例示的なタイムラインを示す図。
ブロードキャスト取出しセグメント対ユニキャスト取出しセグメントに基づくセグメントプレイバックを示す図。
単一のサービスのためのマルチプルなブロードキャスト送信を示す図。
単一のサービスのためのマルチプルなブロードキャスト送信のためにXML文字列を介してパラメータを伝達することを示す図。
モバイルエンティティによって実行可能な例示的な方法を示す図。
図22Aの方法のさらなる態様を示す図。
図22Aの方法のさらなる態様を示す図。
図22Aの方法のさらなる態様を示す図。
図22A〜図22Dの方法による装置の一実施形態を示す図。
ワイヤレスシステム内のモバイルエンティティによって実行可能な別の例示的な方法を示す図。
図24の方法による装置の一実施形態を示す図。
ワイヤレスシステム内のネットワークエンティティによって実行可能な例示的な方法を示す図。
図26の方法による装置の一実施形態を示す図。
詳細な説明
添付の図面に関して以下に記載される詳細な説明は、様々な構成を説明するものであり、本明細書に記載される概念が実践され得る唯一の構成を表すものではない。詳細な説明は、様々な概念の完全な理解を与えるための具体的な詳細を含む。しかしながら、これらの概念はこれらの具体的な詳細なしに実践され得ることが当業者には明らかであろう。いくつかの例では、そのような概念を不明瞭にしないために、よく知られている構造および構成要素は、ブロック図の形式で示される。
本明細書に記載される技法は、CDMA、TDMA、FDMA、OFDMA、SC−FDMAおよび他のネットワークなどの、様々なワイヤレス通信ネットワークに使用することができる。「ネットワーク」および「システム」という用語は、しばしば互換的に使用される。CDMAネットワークは、ユニバーサル地上無線アクセス(UTRA)、CDMA2000などの無線技術を実装することができる。UTRAは、広帯域CDMA(WCDMA(登録商標))およびCDMAの他の変形形態を含む。CDMA2000は、IS−2000規格、IS−95規格およびIS−856規格をカバーする。TDMAネットワークは、モバイル通信用グローバルシステム(GSM)などの無線技術を実装することができる。OFDMAネットワークは、発展型UTRA(E−UTRA)、ウルトラモバイルブロードバンド(UMB)、IEEE802.11(Wi−Fi(登録商標))、IEEE802.16(WiMAX(登録商標))、IEEE802.20、フラッシュOFDMAなどの無線技術を実装することができる。UTRAおよびE−UTRAは、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)の一部である。3GPPのロングタームエボリューション(LTE)およびLTEアドバンスト(LTE−A)は、E−UTRAを使用する、新たにリリースされたUMTSである。UTRA、E−UTRA、UMTS、LTE、LTE−A、およびGSMは、「第3世代パートナーシッププロジェクト」(3GPP)と称する団体からの文書に記載されている。CDMA2000およびUMBは、「第3世代パートナーシッププロジェクト2」(3GPP2)という名称の団体からの文書に記載されている。本明細書に記載される技法は、上記のワイヤレスネットワークおよび無線技術、ならびに他のワイヤレスネットワークおよび無線技術に使用することができる。明確にするために、本技法のいくつかの態様は、以下ではLTEに関して記載され、以下の説明の大部分でLTE用語が使用される。
図1は、LTEネットワークであり得るワイヤレス通信ネットワーク100を示す。ワイヤレスネットワーク100は、いくつかのeNB110と他のネットワークエンティティとを含み得る。eNBは、UEと通信する局であり得、また、基地局、ノードB、アクセスポイント、または他の用語として呼ばれる場合もある。各eNB110a、110b、110cは、特定の地理的エリアに対して通信カバレージを提供することができる。3GPPでは、「セル」という用語は、この用語が使用される状況に応じて、eNBのカバレージエリアおよび/またはこのカバレージエリアにサービスしているeNBサブシステムを指すことができる。
eNBは、マクロセル、ピコセル、フェムトセル、および/または他のタイプのセルに通信カバレージを提供することができる。マクロセルは、比較的大きい地理的エリア(たとえば、半径数キロメートル)をカバーでき、サービスに加入しているUEによる制限されないアクセスを可能にすることができる。ピコセルは、比較的小さい地理的エリアをカバーでき、サービスに加入しているUEによる制限されないアクセスを可能にすることができる。フェムトセルは、比較的小さい地理的エリア(たとえば、家庭)をカバーでき、フェムトセルとの関連を有するUE(たとえば、限定加入者グループ(CSG)内のUE、家庭内のユーザのためのUEなど)による制限されたアクセスを可能にすることができる。マクロセルのためのeNBは、マクロeNBと呼ばれる場合がある。ピコセルのためのeNBは、ピコeNBと呼ばれる場合がある。フェムトセルのためのeNBは、フェムトeNBまたはホームeNB(HNB)と呼ばれる場合がある。図1に示された例では、eNB110a、110b、および110cは、それぞれマクロセル102a、102b、および102cのためのマクロeNBであり得る。eNB110xは、UE120xにサービスするピコセル102xのためのピコeNBであり得る。eNB110yおよび110zは、それぞれフェムトセル102yおよび102zのためのフェムトeNBであり得る。eNBは、1つまたはマルチプルな(たとえば、3つの)セルをサポートすることができる。
ワイヤレスネットワーク100はまた、中継局110rを含み得る。中継局は、上流局(たとえば、eNBまたはUE)からデータおよび/または他の情報の送信を受信し、そのデータおよび/または他の情報の伝送を下流局(たとえば、UEまたはeNB)に送る局である。中継局はまた、他のUEのための伝送を中継するUEであり得る。図1に示された例では、中継局110rは、eNB110aとUE120rとの間の通信を容易にするために、eNB110aおよびUE120rと通信することができる。中継局は、リレーeNB、リレーなどと呼ばれる場合もある。
ワイヤレスネットワーク100は、様々なタイプのeNB、たとえば、マクロeNB、ピコeNB、フェムトeNB、リレーなどを含む異種ネットワークであり得る。これらの異なるタイプのeNBは、異なる送信電力レベル、異なるカバレージエリア、およびワイヤレスネットワーク100内の干渉に対する異なる影響を有する場合がある。たとえば、マクロeNBは、高い送信電力レベル(たとえば、20ワット)を有する場合があるが、ピコeNB、フェムトeNB、およびリレーは、より低い送信電力レベル(たとえば、1ワット)を有する場合がある。
ワイヤレスネットワーク100は、同期動作または非同期動作をサポートすることができる。同期動作の場合、eNBは同様のフレームタイミングを有することができ、異なるeNBからの送信はほぼ時間的にアラインされ得る。非同期動作の場合、eNBは異なるフレームタイミングを有することができ、異なるeNBからの送信は時間的にアラインされない場合がある。本明細書に記載された技法は、同期動作と非同期動作の両方に使用することができる。
ネットワークコントローラ130は、eNBのセットに結合し、これらのeNBに協調および制御を提供することができる。ネットワークコントローラ130は、バックホールを介してeNB110と通信することができる。eNB110はまた、たとえば、ワイヤレスバックホールまたは有線バックホールを介して、直接的にまたは間接的に互いに通信することができる。
UE120は、ワイヤレスネットワーク100全体にわたって分散されることができ、各UEは、固定式またはモバイルであり得る。UEは、また、端末、移動局、加入者ユニット、ステーションなどと呼ばれる場合もある。UEは、携帯電話、携帯情報端末(PDA)、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレスフォン、ワイヤレスローカルループ(WLL)局、または他のモバイルエンティティであり得る。UEは、マクロeNB、ピコeNB、フェムトeNB、リレー、または他のネットワークエンティティと通信することが可能であり得る。図1では、両矢印付きの実線は、ダウンリンクおよび/またはアップリンク上での、UEと、そのUEをサービスするように指定されたeNBであるサービングeNBとの間の所望の送信を示す。両矢印付きの破線は、UEとeNBとの間の干渉する送信を示す。
LTEは、ダウンリンク上では直交周波数分割多重化(OFDM)を利用し、アップリンク上ではシングルキャリア周波数分割多重化(SC−FDM)を利用する。OFDMおよびSC−FDMは、システム帯域幅を、通常はトーン、ビンなどとも呼ばれるマルチプルな(K個の)直交サブキャリアに分割する。各サブキャリアはデータで変調されることができる。一般に、変調シンボルは、OFDMでは周波数領域で、SC−FDMでは時間領域で送られる。隣接するサブキャリア間の間隔は固定であり得、サブキャリアの総数(K)はシステム帯域幅に依存し得る。たとえば、Kは、1.25、2.5、5、10または20メガヘルツ(MHz)のシステム帯域幅について、それぞれ128、256、512、1024または2048に等しくなり得る。システム帯域幅はまた、サブバンドに分割され得る。たとえば、サブバンドは1.08MHzをカバーでき、1.25、2.5、5、10、または20MHzのシステム帯域幅について、それぞれ1個、2個、4個、8個、または16個のサブバンドがあり得る。
図2は、LTEにおいて使用されるダウンリンクのフレーム構造を示す。ダウンリンクの送信タイムラインは、無線フレームの単位に分割することができる。各無線フレームは、所定の継続時間(duration)(たとえば、10ミリ秒(ms))を有することができ、0〜9のインデックスをもつ10個のサブフレームに分割することができる。各サブフレームは2つのスロットを含むことができる。したがって、各無線フレームは、0〜19のインデックスをもつ20個のスロットを含むことができる。各スロットは、L個のシンボル期間、たとえば、図2に示されたようにノーマルサイクリックプレフィックス(CP)の場合は7個のシンボル期間、または拡張サイクリックプレフィックスの場合は6個のシンボル期間を含むことができる。ノーマルCPおよび拡張CPは、異なるCPのタイプと本明細書では呼ばれる場合がある。各サブフレーム内の2L個のシンボル期間は、0〜2L−1個のインデックスを割り当てることができる。利用可能な時間周波数リソースは、リソースブロックに分割することができる。各リソースブロックは、1つのスロット内でN個のサブキャリア(たとえば、12個のサブキャリア)をカバーすることができる。
LTEでは、eNBは、eNB内のセルごとに1次同期信号(PSS)と2次同期信号(SSS)とを送ることができる。1次同期信号および2次同期信号は、図2に示されたように、それぞれ、ノーマルサイクリックプレフィックスをもつ各無線フレームのサブフレーム0および5の各々の中のシンボル期間6および5の中で送ることができる。同期信号は、セルの検出および捕捉のためにUEによって使用されることができる。eNBは、サブフレーム0のスロット1内のシンボル期間0〜3の中で物理ブロードキャストチャネル(PBCH)を送ることができる。PBCHはあるシステム情報を搬送することができる。
eNBは、図2の第1のシンボル期間全体の中に示されているが、各サブフレームの第1のシンボル期間の一部のみの中で、物理制御フォーマットインジケータチャネル(PCFICH)を送ることができる。PCFICHは、制御チャネルに使用されるいくつか(M個)のシンボル期間を搬送することができ、ここで、Mは、1、2または3に等しくなり得るし、サブフレームごとに変化する場合がある。Mはまた、たとえば、リソースブロックが10個未満である、小さいシステム帯域幅では4に等しくなり得る。図2に示された例では、M=3である。eNBは、各サブフレームの最初のM個のシンボル期間の中で(図2ではM=3)、物理HARQインジケータチャネル(PHICH)と物理ダウンリンク制御チャネル(PDCCH)とを送ることができる。PHICHは、ハイブリッド自動再送(HARQ)をサポートする情報を搬送することができる。PDCCHは、UEのためのリソースの割当てに関する情報と、ダウンリンクチャネル用の制御情報とを搬送することができる。図2の第1のシンボル期間の中には示されていないが、PDCCHおよびPHICHは、第1のシンボル期間の中にも含まれることを理解されたい。同様に、PHICHおよびPDCCHはまた、第2のシンボル期間と第3のシンボル期間の両方の中にあるが、図2ではそのように示されていない。eNBは、各サブフレームの残りのシンボル期間中に、物理ダウンリンク共有チャネル(PDSCH)を送ることができる。PDSCHは、ダウンリンク上でのデータ送信のためにスケジュールされたUE用のデータを搬送することができる。LTEにおける様々な信号およびチャネルは、公開されている「Evolved Universal Terrestrial Radio Access(E−UTRA);Physical Channels and Modulation」と題する、3GPPのTS36.211に記載されている。
eNBは、eNBによって使用されるシステム帯域幅の中心1.08MHzにおいてPSSと、SSSと、PBCHとを送ることができる。eNBは、これらのチャネルが送られる各シンボル期間内のシステム帯域幅全体にわたってPCFICHとPHICHとを送ることができる。eNBは、システム帯域幅のいくつかの部分においてUEのグループにPDCCHを送ることができる。eNBは、システム帯域幅の特定の部分において特定のUEにPDSCHを送ることができる。eNBは、すべてのUEにブロードキャスト方式でPSSと、SSSと、PBCHと、PCFICHと、PHICHとを送ることができ、特定のUEにユニキャスト方式でPDCCHを送ることができ、また、特定のUEにユニキャスト方式でPDSCHを送ることができる。
各シンボル期間において、いくつかのリソース要素が利用可能であり得る。各リソース要素は、1つのシンボル期間内で1つのサブキャリアをカバーすることができ、実数値または複素数値であり得る1つの変調シンボルを送るために使用されることができる。各シンボル期間内で基準信号に使用されないリソース要素は、リソース要素グループ(REG)内に配置することができる。各REGは、1つのシンボル期間内に4つのリソース要素を含むことができる。PCFICHは、シンボル期間0において、周波数上でほぼ等しく離間され得る、4つのREGを占有することができる。PHICHは、1つまたは複数の構成可能なシンボル期間において、周波数上で拡散され得る、3つのREGを占有することができる。たとえば、PHICH用の3つのREGは、すべてシンボル期間0に属する場合があるか、またはシンボル期間0、1および2で拡散される場合がある。PDCCHは、最初のM個のシンボル期間において、利用可能なREGから選択され得る、9、18、32または64個のREGを占有することができる。REGのいくつかの組合せのみを、PDCCHに対して許可することができる。
UEは、PHICHおよびPCFICHに使用される特定のREGを知ることができる。UEは、PDCCH用のREGの様々な組合せを探索することができる。探索する組合せの数は、通常、PDCCHに対して許可された組合せの数よりも少ない。eNBは、UEが探索することになる組合せのいずれかにおいて、UEにPDCCHを送ることができる。
UEは、マルチプルなeNBのカバレージ内にあり得る。これらのeNBのうちの1つを、UEをサービスするために選択することができる。サービングeNBは、受信電力、経路損失、信号対雑音比(SNR)などの様々な基準に基づいて、選択することができる。
図3は、図1の基地局/eNBの1つおよびUEの1つであり得る、基地局/eNB110およびUE120の設計のブロック図を示す。制限付き関連付けシナリオの場合、基地局110は図1のマクロeNB110cであり得るし、UE120はUE120yであり得る。基地局110はまた、何らかの他のタイプの基地局であり得る。基地局110はアンテナ334a〜334tを備える場合があり、UE120はアンテナ352a〜352rを備える場合がある。
基地局110において、送信プロセッサ320は、データソース312からデータを受信し、コントローラ/プロセッサ340から制御情報を受信することができる。制御情報は、PBCH、PCFICH、PHICH、PDCCHなどのためであり得る。データは、PDSCHなどのためであり得る。プロセッサ320は、データと制御情報とを処理(たとえば、符号化およびシンボルマッピング)して、それぞれデータシンボルと制御シンボルとを取得することができる。プロセッサ320はまた、たとえば、PSS、SSS、およびセル固有基準信号のための基準シンボルを生成することができる。送信(TX)多入力多出力(MIMO)プロセッサ330は、適用可能な場合、データシンボル、制御シンボル、および/または基準シンボルに対して空間処理(たとえば、プリコーディング)を実行することができ、出力シンボルストリームを変調器(MOD)332a〜332tに提供することができる。各変調器332は、(たとえば、OFDMなどのために)それぞれの出力シンボルストリームを処理して、出力サンプルストリームを取得することができる。各変調器332はさらに、出力サンプルストリームを処理(たとえば、アナログへの変換、増幅、フィルタ処理、およびアップコンバート)して、ダウンリンク信号を取得することができる。変調器332a〜332tからのダウンリンク信号は、それぞれアンテナ334a〜334tを介して送信することができる。
UE120において、アンテナ352a〜352rは、基地局110からダウンリンク信号を受信することができ、受信された信号をそれぞれ復調器(DEMOD)354a〜354rに提供することができる。各復調器354は、それぞれの受信された信号を調整(たとえば、フィルタ処理、増幅、ダウンコンバート、およびデジタル化)して、入力サンプルを取得することができる。各復調器354は、(たとえば、OFDMなどのために)入力サンプルをさらに処理して、受信シンボルを取得することができる。MIMO検出器356は、すべての復調器354a〜354rから受信シンボルを取得し、適用可能な場合は受信シンボルに対してMIMO検出を実行し、検出シンボルを提供することができる。受信プロセッサ358は、検出シンボルを処理(たとえば、復調、デインターリーブ、および復号)し、UE120の復号されたデータをデータシンク360に提供し、復号された制御情報をコントローラ/プロセッサ380に提供することができる。
アップリンク上では、UE120において、送信プロセッサ364は、データソース362から(たとえば、PUSCHのための)データを受信し処理することができ、コントローラ/プロセッサ380から(たとえば、PUCCHのための)制御情報を受信し処理することができる。プロセッサ364はまた、基準信号用の基準シンボルを生成することができる。送信プロセッサ364からのシンボルは、適用可能な場合はTX MIMOプロセッサ366によってプリコードされ、さらに(たとえば、SC−FDMなどのために)変調器354a〜354rによって処理され、基地局110に送信することができる。基地局110において、UE120からのアップリンク信号は、アンテナ334によって受信され、復調器332によって処理され、適用可能な場合はMIMO検出器336によって検出され、さらに受信プロセッサ338によって処理されて、UE120によって送られる復号されたデータと制御情報とを取得することができる。プロセッサ338は、復号されたデータをデータシンク339に提供し、復号された制御情報をコントローラ/プロセッサ340に提供することができる。
コントローラ/プロセッサ340および380は、それぞれ基地局110およびUE120での動作を指示することができる。基地局110にあるプロセッサ340ならびに/または他のプロセッサおよびモジュールは、本明細書に記載された技法のための様々なプロセスを実行するか、またはその実行を指示することができる(図26参照)。UE120にあるプロセッサ380ならびに/または他のプロセッサおよびモジュールは、本明細書に記載された技法のための様々なプロセスを実行するか、またはその実行を指示することができる(図22A〜図22Dおよび図24参照)。メモリ342および382は、それぞれ、基地局110およびUE120のためのデータとプログラムコードとを記憶することができる。スケジューラ344は、ダウンリンク上および/またはアップリンク上でのデータ送信のためにUEをスケジューリングすることができる。
単一周波数ネットワークにおけるeMBMSおよびユニキャストシグナリング: マルチメディア用の高帯域幅通信を容易にする1つの技法は、単一周波数ネットワーク(SFN)動作であった。具体的には、(たとえば、LTEのコンテキストではマルチメディアブロードキャスト単一周波数ネットワーク(MBSFN)として最近知られるようになってきたものを含む)発展型MBMS(eMBMS)としても知られる、マルチメディアブロードキャストマルチキャストサービス(MBMS)およびLTE用のMBMSは、そのようなSFN動作を利用することができる。SFNは、たとえば、eNBなどの無線送信機を利用して、加入者UEと通信する。eNBのグループは、情報を同期方式で送信できるので、信号は互いに干渉するのではなく、互いに補強し合う。eMBMSのコンテキストでは、共有コンテンツは、LTEネットワークのマルチプルなeNBからマルチプルなUEに送信される。したがって、所与のeMBMSエリア内で、UEは、eMBMSサービスエリアおよびMBSFNエリアの一部としての無線範囲内の任意のeNBから、eMBMS信号を受信することができる。しかしながら、eMBMS信号を復号するために、各UEは、非eMBMSチャネルを介して、サービングeNBからマルチキャスト制御チャネル(MCCH)情報を受信する。MCCH情報は時間とともに変化し、変化の通知が別の非eMBMSチャネル、PDCCHを通じて提供される。したがって、特定のeMBMSエリア内のeMBMS信号を復号するために、各UEは、エリア内のeNBの1つによってMCCHおよびPDCCH信号を供給される。
本開示の主題の態様によれば、eMBMS用のシングルキャリア最適化に関連する機能を有するワイヤレスネットワーク(たとえば、3GPPネットワーク)が提供される。eMBMSは、たとえばUEなどのマルチプルなモバイルエンティティに、LTEネットワークから共有コンテンツを送信する効率的な方法を提供する。
LTE周波数分割複信(FDD)用のeMBMSの物理層(PHY)に関して、チャネル構造は、混合されたキャリア上でeMBMS送信とユニキャスト送信とを分割する、時分割多重化(TDM)リソースを備える場合があり、これにより、柔軟で動的なスペクトルの利用が可能になる。現在、マルチメディアブロードキャスト単一周波数ネットワーク(MBSFN)サブフレームとして知られる、サブフレームのサブセット(最大60%)を、eMBMS送信のために確保することができる。したがって、現在のeMBMS設計は、10個のサブフレームのうち最大で6個をeMBMS用に許容する。
eMBMS用のサブフレームの割当ての例が図4に示され、図4は、シングルキャリアの場合の、MBSFNサブフレームへのMBSFN基準信号の既存の割当てを示す。図4に描写されたコンポーネントは、図2に示されたコンポーネントに対応し、図4は、各々のスロットおよびリソースブロック(RB)内の個別のサブキャリアを示す。3GPPのLTEでは、RBは、0.5msのスロット期間にわたる12個のサブキャリアに及び、各サブキャリアは15kHzの帯域幅を有し、合わせてRB当たり180kHzに及ぶ。サブフレームは、たとえば、0、1、2、3、4、5、6、7、8、および9と標示されたサブフレームのシーケンス中で、ユニキャストまたはeMBMSのために割り当てられる場合があり、サブフレーム0、4、5、および9は、FDDではeMBMSから除外される場合がある。また、サブフレーム0、1、5、および6は、時分割複信(TDD)ではeMBMSから除外される場合がある。より具体的には、サブフレーム0、4、5、および9は、PSS/SSS/PBCH/ページング/システム情報ブロック(SIB)およびユニキャストサービスに使用することができる。列の中の残りのサブフレーム、たとえばサブフレーム1、2、3、6、7、および8は、eMBMSサブフレームとして構成することができる。
図4への参照を続けると、各eMBMSサブフレーム内で、最初の1個または2個のシンボルが、ユニキャスト基準シンボル(RS)および制御シグナリングに使用されうる。最初の1個または2個のシンボルのCPの長さは、サブフレーム0のCPの長さに従う場合がある。CPの長さが異なる場合、最初の1個または2個のシンボルとeMBMSシンボルとの間に、送信ギャップが発生する場合がある。関係する態様では、eMBMS帯域幅全体の利用率は、RSオーバーヘッド(たとえば、各eMBMSサブフレーム内に6個のeMBMSサブフレームと2個の制御シンボルと)を考慮すると、42.5%であり得る。MBSFN RSとユニキャストRSとを提供するための既知の技法は、通常、(図4に示されたように)MBSFNサブフレームにMBSFN RSを割り当て、非MBSFNサブフレームにユニキャストRSを別個に割り当てることを伴う。より具体的には、図4が示すように、MBSFNサブフレームの拡張CPは、MBSFN RSを含むが、ユニキャストRSを含まない。本技術は、限定ではなく例として提示された図2および図4によって示された特定のフレーム割当て方式に限定されない。本明細書で使用するマルチキャストセッションまたはマルチキャストブロードキャストは、任意の適切なフレーム割当て方式を使用することができる。
eMBMSサービスエリア: 図5は、それら自体がマルチプルなセルまたは基地局510を含む、マルチプルなMBSFNエリア504と、506と、508とを包含する、MBMSサービスエリア502を含むシステム500を示す。本明細書で使用する「MBMSサービスエリア」は、ある特定のMBMSサービスが利用可能であるワイヤレス送信セルのグループを指す。たとえば、ある特定のスポーツプログラムまたは他のプログラムが、ある特定の時間にMBMSサービスエリア内の基地局によってブロードキャストされる場合がある。特定のプログラムがブロードキャストされるエリアは、MBMSサービスエリアを定義する。MBMSサービスエリアは、504、506および508で示された1つまたは複数の「MBSFNエリア」で構成され得る。本明細書で使用するMBSFNエリアは、MBSFNプロトコルを使用して同期方式で特定のプログラムを現在ブロードキャストしているセル(たとえば、セル510)のグループを指す。「MBSFN同期エリア」は、現在そうしているかどうかにかかわらず、同期方式で動作して、MBSFNプロトコルを使用してある特定のプログラムをブロードキャストすることが可能なように相互接続され構成された、セルのグループを指す。各eNBは、所与の周波数層上の、1つのMBSFN同期エリアのみに属することができる。MBMSサービスエリア502が1つまたは複数のMBSFN同期エリア(図示せず)を含むことができることは、注意に値する。逆に、MBSFN同期エリアは、1つまたは複数のMBSFNエリアまたはMBMSサービスエリアを含むことができる。一般に、MBSFNエリアは、単一のMBSFN同期エリアのすべてまたは一部で構成され、単一のMBMSサービスエリア内に位置する。様々なMBSFNエリア間の重複がサポートされ、単一のeNBはいくつかの異なるMBSFNエリアに属することができる。たとえば、異なるMBSFNエリア内のメンバーシップをサポートするために、最大で8個の独立のMCCHがSIB−13において構成され得る。MBSFNエリア予約セルまたは基地局は、MBSFN送信に寄与しないMBSFNエリア内のセル/基地局、たとえば、MBSFN同期エリアの境界に近いセル、または、その位置ゆえにMBSFN送信に必要とされないセルである。
eMBMSシステムのコンポーネントおよび機能: 図6は、MBSFNサービスを提供またはサポートするワイヤレス通信システム600の機能エンティティを示す。サービス品質(QoS)に関して、システム600は、保証ビットレート(GBR)タイプのMBMSベアラを使用し、最大ビットレート(MBR)はGBRに等しい。これらのコンポーネントは、例として図示および記載され、本明細書に記載された本発明の概念を限定せず、この本発明の概念は、マルチキャスト送信を配信し制御するための他のアーキテクチャおよび機能的分布に採用され得る。
システム600は、MBMSゲートウェイ(MBMS GW)616を含む場合がある。MBMS GW616は、M1インターフェースを介した、eNodeB604へのMBMSユーザプレーンデータのインターネットプロトコル(IP)マルチキャスト分配を制御し、多くの可能なeNBのうちの1つのeNB604が示されている。さらに、MBMS GWは、M1インターフェースを介してUTRAN無線ネットワークコントローラ(RNC)620へのMBMSユーザプレーンデータのIPマルチキャスト分配を制御し、多くの可能なRNCのうちの1つのUTRAN RNC620が示されている。M1インターフェースは、MBMSデータ(ユーザプレーン)と関連付けられ、データパケットの配信用にIPを使用する。eNB604は、E−UTRAN Uuインターフェースを介して、ユーザ機器(UE)/モバイルエンティティ602にMBMSコンテンツを提供することができる。RNC620は、Uuインターフェースを介してUEモバイルエンティティ622にMBMSコンテンツを提供することができる。MBMS GW616はさらに、モビリティ管理エンティティ(MME)608およびSmインターフェースを介して、MBMSセッション制御シグナリング、たとえば、MBMSセッション開始とセッション停止とを実行することができる。MBMS GW616はさらに、SG−mb(ユーザプレーン)基準点を通じてMBMSベアラを使用してエンティティにインターフェースを提供し、SGi−mb(制御プレーン)基準点を通じてMBMSベアラを使用してエンティティにインターフェースを提供することができる。SG−mbインターフェースは、MBMSベアラサービス固有のシグナリングを搬送する。SGi−mbインターフェースは、MBMSデータ配信用のユーザプレーンインターフェースである。MBMSデータ配信は、デフォルトモードであり得るIPユニキャスト送信によって、またはIPマルチキャスティングによって、実行され得る。MBMS GW616は、サービング汎用パケット無線サービスサポートノード(SGSN)618およびSn/Iuインターフェースを介して、UTRANを通じてMBMSに制御プレーン機能を提供することができる。
システム600はさらに、マルチキャスト協調エンティティ(MCE)606を含み得る。MCE606は、MBMSコンテンツ用のアドミッション制御機能を実行し、MBSFN動作を使用してマルチセルMBMS送信のためにMBSFNエリア内のすべてのeNBによって使用される時間および周波数の無線リソースを割り当てることができる。MCE606は、たとえば、変調およびコーディング方式など、MBSFNエリアについての無線構成を決定することができる。MCE606は、MBMSコンテンツのユーザプレーン送信をスケジューリングおよび制御し、どのサービスがどのマルチキャストチャネル(MCH)内で多重化されるべきかを決定することによって、eMBMSサービスの多重化を管理することができる。MCE606は、M3インターフェースを通じてMME608とのMBMSセッション制御シグナリングに参加することができ、eNB604に制御プレーンインターフェースM2を提供することができる。
システム600はさらに、コンテンツプロバイダサーバ614と通信している、ブロードキャストマルチキャストサービスセンタ(BM−SC)612を含み得る。BM−SC616は、コンテンツプロバイダ614などの1つまたは複数のソースからのマルチキャストコンテンツの取込みをハンドリングし、以下で記載されるような他のより高レベルの管理機能を提供することができる。これらの機能は、たとえば、識別されたUEのためのMBMSサービスの認証および開始を含むメンバーシップ機能を含むことができる。BM−SC616はさらに、MBMSセッションおよび送信機能、ライブブロードキャストのスケジューリング、ならびにMBMSおよび関連する配信機能を含む配信を実行することができる。BM−SC612はさらに、マルチキャストに利用可能なコンテンツをアドバタイズすることなどの、サービスのアドバタイズメント(advertisement)と説明とを提供することができる。別個のパケットデータプロトコル(PDP)のコンテキストは、UEとBM−SCとの間で制御メッセージを搬送するために使用され得る。BM−SCはさらに、キー管理などのセキュリティ機能を提供し、データボリュームおよびQoSなどのパラメータに従ってコンテンツプロバイダの課金を管理し、UTRANにおいて、およびブロードキャストモードの場合E−UTRANにおいて、MBMSについてのコンテンツ同期を提供し、UTRANにおいてMBSFNデータについてのヘッダ圧縮を提供することができる。BM−SC612は、QoSおよびMBMSサービスエリアなどのセッション属性(session attributes)を含め、セッションの開始、更新、および停止をMBMS−GW616に示すことができる。
システム600はさらに、MCE606およびMBMS−GW616と通信しているマルチキャスト管理エンティティ(MME)608を含み得る。MME608は、E−UTRANを介してMBMSについての制御プレーン機能を提供することができる。加えて、MMEは、MBMS−GW616によって定義されるマルチキャスト関連情報を、eNB604、620に提供することができる。MME608とMBMS−GW616との間のSmインターフェースは、MBMS制御シグナリング、たとえば、セッション開始信号とセッション停止信号とを搬送するために使用され得る。
システム600はさらに、パケットデータネットワーク(PDN)ゲートウェイ(GW)610(時にP−GWと略される)を含み得る。P−GW610は、シグナリングおよび/またはユーザデータのために、UE602とBM−SC612との間に発展型パケットシステム(EPS)ベアラを提供することができる。したがって、P−GWは、UEに割り当てられたIPアドレスと関連するUEから発信された、ユニフォームリソースロケータ(URL)ベースの要求を受信することができる。BM−SC612はまた、P−GW610を介して1つまたは複数のコンテンツプロバイダにリンクされ得、P−GW610は、IPインターフェースを介してBM−SC612と通信し得る。
本明細書に記載された実施形態の1つまたは複数の態様によれば、動的適応ストリーミングオーバーHTTP(DASH)コンテンツについてのメディアプレゼンテーションディスクリプション(MPD)内のserviceLocation属性(attribute)を介して、そのコンテンツのオンデマンドブロードキャストバージョンへのユニキャスト動的適応ストリーミングオーバーHTTP(DASH)アクセスを指示することをサポートする、いくつかのURLの使用をシグナリングするための技法が提供される。DASHにより、ハイパーテキスト転送プロトコル(HTTP)を介して連続(ストリーミング)メディアコンテンツを配信するサービスが可能になる。DASHについての仕様は、主に2つのフォーマット、すなわち、MPDおよびセグメントのフォーマットを定義する。
図7は、MPD用の高レベルの拡張可能マークアップ言語(XML)スキーマ構造の実施形態700を示す。図8は、serviceLocationおよびbyteRange属性をベースURLに関連付けるBaseURLについての構造を示すためのスキーマ800を描く。BaseURL要素のリストは、MPDで、MPDのPeriodレベルで、Adaptation Setレベルで、およびRepresentaionレベルで記述され得る。
関係する態様では、BaseURLは、Baseユニフォームリソース識別子(URL)の機能を果たすことができる。MPDの各レベルでのURLは、ドキュメント(たとえば、MPD)のそのレベルで、または上のレベルで指定されたBaseURL要素に関するRFC3986に従って解決(resolved)され得る。URL解決(URL resolution)は、MPDドキュメント内で見出されるすべてのURL、特に、本明細書に記載された開示にとって関心事である初期化およびメディアセグメント用のURLに適用される。マルチプルなBaseURL要素は、同一のセグメントがアクセスされることのできる1つまたは複数の共通ロケーションを指定するために提供され得る。他の基準がない場合、DASHクライアントは、ベースURIとして第1のBaseURL要素を使用し得る。
図8を参照すると、BaseURL要素についてのserviceLocation属性は、同じserviceLocation値を有するBaseURL要素が、たとえば、共通コンテンツ配信ネットワークなどの共通ネットワークロケーションでのサービスに対するそれらのURL解決を有する可能性があるようなBaseURL間の関係を指定する。たとえば、DASHクライアントが表現についてのセグメント(たとえば、解像度、言語などの所与のコンテンツの様々なバージョン)を取り出すが、(アクセスワイヤレスネットワークが帯域幅上の現在の表現要件をサポートし続けることができないので)異なる表現からセグメントを取り出すことを決めた場合、前の表現と同じserviceLocation値を有する新しい表現についてのBaseURLを選択することができる。このserviceLocation属性の使用は、新しい表現についてのセグメントを取り出すことが、同じserviceLocation値を有するBaseURLを介して前の表現から取り出されたセグメントと同様の性能(たとえば、アベイラビリティ調整)を体験することを示す、デバイスに対するヒントの役割を果たす。
eMBMSを介したDASHブロードキャストに関する問題: DASHメディアセグメント(たとえば、メディアファイル)の連続配信は、メディアファイルまたはDASHメディアセグメントの連続送信を含み得るメディアストリーミングサービスを構成する。RTPを使用するメディアのストリーミング配信も可能であるが、RTPトランスポートは、通常、DASHセグメントには適していない。
一部のブロードキャストネットワークでは、ブロードキャストストリーム化されたコンテンツは、また、たとえば、eMBMS内のRTPストリーミングブロードキャストの場合のように、ユニキャストを介して利用可能にされ、アクセスされることができる。コンテンツのこの代替的な配信は、ブロードキャストカバレージの中にいない間、ブロードキャストストリーミングサービス用のコンテンツにアクセスするためのユニキャストフォールバック技法を提供する。ブロードキャストファイル配信サービスのファイルにアクセスするフォールバック技法は、通常、ブロードキャストネットワークでは定義されない。
DASHセグメントのブロードキャスト配信は、通常、ブロードキャストファイル配信サービス(たとえば、FLUTE)に採用されるトランスポート・プロトコルを使用するので、ブロードキャストDASHサービスのコンテンツにアクセスするための代替のユニキャストフォールバックが必要とされる。
eMBMSなどを介したDASHブロードキャストに関して考慮すべきいくつかの問題が存在する。1つの問題は、ブロードキャストDASHサービスが様々な位置で様々なバージョンのコンテンツ(たとえば、様々な表現)を配信できることである。様々な表現は、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であることもあり得る。したがって、サービスのどの表現が、現在の所望の/利用可能なブロードキャストまたはユニキャスト・トランスポートに利用可能であるかをシグナリングする技法が必要とされる。
別の問題は、DASHセグメントのトランスポートが、時間セグメントからのさらなるブロードキャストアベイラビリティ調整(たとえば、アベイラビリティの先延ばしまたは前倒し)がユニキャストを介した取出しに利用可能であり得ることを招く場合があることであり、ブロードキャストアベイラビリティ調整は、そのようなシナリオにおけるブロードキャスト待ち時間である。ブロードキャスト配信を介して受信されたセグメントのアベイラビリティは、セグメントがユニキャスト配信を介して受信され得る時間からのさらなるアベイラビリティ調整を招く場合があり、このことは、1つのモードの配信から別のモードの配信に(たとえば、ブロードキャストからユニキャストに)切り替えるときの問題をまねきうる。デバイスがブロードキャストカバレージに出入りするときに、シームレスなユニキャストからブロードキャスト(UC−BC)およびブロードキャストからユニキャスト(BC−UC)の遷移を可能にするために、ブロードキャストアベイラビリティ調整に関する情報は、DASHクライアントに通信されるべきである。
別の問題は、ユニキャストを介して利用可能な表現が、いくつかの地理的エリアでのみアクセス可能であり得ることである。そのような地理的制約は、DASHクライアントにシグナリングされるべきである。さらに別の問題は、ブロードキャストDASHサービスが様々なFLUTEセッションを介してマルチプルな表現を搬送し得ることであり、したがって、どのFLUTEセッションが所望の表現を可能にするかを識別する技法が必要とされる。たとえば、マルチプルな表現が、代替的な言語またはビデオ解像度のオプションを提供するために所与のエリアでブロードキャストを介して利用可能であり得る。関心のある表現だけを受信するように選択すると、モバイルエンティティのバッテリ寿命が改善される。
いくつかの状況では、ブロードキャストDASHのサービスオンデマンドを作成して、マルチプルなユーザがユニキャストを介してDASHコンテンツを取り出すことによって引き起こされるシステムリソース上の負荷を低減することが望ましい場合がある。異なるURLを使用して、ユニキャスト受信からブロードキャスト受信に切り替える必要があることをデバイスにシグナリングすることも必要であり得る。したがって、これらの問題に対処するための解決策が以下に記載される。
シグナリング情報の搬送: 上述の問題に対処するために、ブロードキャストされたDASHセグメントのサポートのためにいくつかのパラメータがDASHクライアントにシグナリングされることができる。そのようなパラメータは、MPDにおいて別個の新しいパラメータとしてシグナリングされることができる。しかしながら、MPD定義をさらに拡張して、ブロードキャストDASHのいくつかのシナリオのみで使用されるこれらの追加パラメータについてのサポートを追加することは、望ましくないか、または許容できない可能性がある。
したがって、本明細書に記載する提案される解決策は、登録された名前空間識別子(NID:Namespace Identifier)下のユニフォームリソース名(URN)として、これらのパラメータをシグナリングすることができる−たとえば、3GPPの場合、NIDは3gppであり、その結果、3GPP制御下のURNはurn:3gpp:{3gpp−urn}の形式である。加えて、URN名前空間固有文字列(NSS)は、BaseURLのserviceLocation属性などの中の文字列として搬送されたキー=値のペアのコロン区切りのリストとして、必要なパラメータをどのように符号化すべきかの実施形態を提供する。
可能な代替手法は、BaseURLのserviceLocation属性において文字列として搬送されたキー=値のペアのカンマ区切りのリストを使用することを含むことができる。別の代替手法は、XML構造内のこれらのパラメータをXMLスキーマごとに符号化し、BaseURLのserviceLocation属性においてそのXML符号化データを搬送することを含むことができる。さらに別の手法は、追加の属性または要素を、URNにおいて搬送されたパラメータのリスト、カンマ区切りのリストをキャプチャするために、MPDのXMLスキーマに追加すること、または、serviceLocation属性の中のXML符号化もしくはパラメータに追加することを含むことができる。
キー=値のペアのリストを伝達するためにURL符号化が使用される実施形態では、以下の規則または要件が適用される場合がある。URNのNSS内の最初の文字列は、(serviceLocationの場合)slであり得る。たとえば、3GPPのURNの場合、serviceLocation属性で使用されるすべてのURNは、「urn:3gpp:sl」で始まる。2番目の文字列(または最初のキー=値のペア)は、「:transport=」+値文字列(value-string)であり得る。たとえば、可能な値文字列は、「broadcast」、「unicast」、「both」であり得る。他のキー=値のペアは、「:transport=」+値文字列、またはその変形形態に従うことができる。
ブロードキャストDASHサービスのユニキャストアベイラビリティ: DASHは、各DASHクライアントがHTTPを介して、かつMPDで定義されたタイムラインに従うシーケンスでメディアサービスを取り出し得る、ユニキャストストリーミングフレームワークを提供する。DASHセグメントはまた、メディアセグメントがFLUTEなどを介してブロードキャストされる、ブロードキャスト・トランスポートを介して、DASHクライアントを含むデバイスに配信され得る。
ブロードキャストシステムは、通常、ブロードキャスト・トランスポートを介して利用可能なサービスを記述するシステム情報(SI)メタデータを含む。eMBMSブロードキャストシステムでは、そのSIは、ユーザサービスディスクリプション(USD)と呼ばれる場合があり、図9に示されたように、サービスのバンドルを記述するメタデータを含む場合がある。SIの他の例は、OMAブロードキャストサービスガイドおよびMediaFLOサービス定義メタデータであることに留意されたい。図10Aを参照すると、eMBMS用のUSDの実施形態が示され、各サービスはパラメータ付きで記述される場合がある。そのようなパラメータは、(図11に詳述される)deliveryMethodリストと、サービスに関連付けられたMPDユニフォームリソース識別子(mpdURI)に対する参照を含み得る。mpdURIは、MPDをサービスに結合することができる。図10Bは、以下でさらに詳細に記載される、eMBMS用のUSDの別の実施形態を示す。
図11は、eMBMSブロードキャストシステムの場合に、ブロードキャストサービスコンテンツのユニキャストバージョンがどこで見出され得るかに関係する情報をブロードキャストシステムについてのSIが提供できることを示す。RTPストリーミングを使用するeMBMSブロードキャストサービスの場合、SIは、サービス用のdeliveryMethod内のunicastAccessURIを介して、同じコンテンツについてのユニキャストRTPストリーミングバージョンを記述するセッション記述プロトコル(SDP)ファイルへのポインタを提供することができる。そのようなURLの存在はまた、サービスのユニキャストバージョンが利用可能であることをシグナリングする働きをすることができ、一方で、その不在は、サービスがブロードキャストを介してのみ利用可能であることを示す。パラメータは、ユニキャストのアベイラビリティなどを示すために使用できることに留意されたい。ブロードキャストDASHサービスの場合、属性は、ブロードキャストDASHサービスについて、ユニキャスト表現も利用可能であることをシグナリングするために使用され得る。
ブロードキャストDASHサービスの場合、SIにおける別個のURLを介したユニキャストアベイラビリティの明示的なシグナリングは、一般に望ましくない。ブロードキャストDASHサービスの場合、そのような明示的なシグナリングは、ユニキャストを介したDASHセグメントの配信を記述する追加MPDへの参照を提供しうる。プレイバック中のMPDの交換は破壊的になる傾向があるので、(たとえば、eMBMSのUSDについてmpdURIを介してシグナリングされた)ブロードキャスト用のMPDと、(たとえば、eMBMSのUSDについてunicastAccessURIを介してシグナリングされた)ユニキャスト用の別のMPDとを使用することは、ブロードキャスト配信からユニキャスト配信、およびその逆の、受信のシームレスな遷移を可能にしない。したがって、ユニキャストアベイラビリティのシグナリングを単一のDASH MPDに埋め込み、図8に示されたタイプのBaseURL要素を介して異なるロケーションからのセグメントのアベイラビリティのMPDシグナリングを活用することが望ましい。どのURLがユニキャスト受信対ブロードキャスト受信に使用されるべきかをDASHクライアントにシグナリングする方法が提供される。このように、ブロードキャストサービスのユニキャスト受信を行うときには、DASHクライアントは、通常のDASHクライアントとして働き、単一のMPDにおいてユニキャストHTTPのURLを使用してセグメントを取り出す。
この手法により、ブロードキャストおよびユニキャストを介してサービスがどのように受信され得るかを、単一のMPDが記述することが可能になる。ブロードキャスト受信およびユニキャスト受信用の単一のMPDにより、DASHクライアントがブロードキャストカバレージに出入りするときのシームレスなUC−BCおよびBC−UCの受信ハンドオフの効率的なサポートも可能になる。
ユニキャスト受信およびブロードキャスト受信用のセグメントURLを識別することに関して、図12は、MPDから他の属性および要素を取り除きながら、MPDレベルで利用可能なBaseURLのリストを示す図7の簡略化を与える。ユニキャスト・トランスポートでは、マルチプルなBaseURLは、通常、同一のセグメントがマルチプルなロケーションでアクセス可能であることをシグナリングするために使用される。serviceLocation属性は、同じserviceLocation値をもつBaseURL要素が、共通のネットワークロケーションでのサービスに対するそれらのURL解決を有する可能性があるように、BaseURL間の関係を指定するために定義されることができる。これにより、表現を変更するときにどのベースURLを使用すべきかを決定するときに、DASHクライアントがserviceLocationを使用することが可能になる。たとえば、DASHクライアントは、古い表現のために使用されたBaseURLと同じserviceLocation属性をもつBaseURLを有する新しい表現を選択することができる。
所与の表現についてのマルチプルなBaseURLは、サービスのためのセグメントがそこから取出しに利用可能である様々なロケーションを記述するので、ブロードキャストシステムを通じたDASHサービスの場合、フォーマットはserviceLocationの文字列に関して定義され得る。フォーマットは、所与のブロードキャストDASHサービスまたはそれらの表現の任意の組合せが、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であるかをシグナリングするために追加情報を提供することができる。より具体的には、URNフォーマットを使用するときには、serviceLocation属性は、上述されたように、「urn:3gpp:sl」で始まる文字列を含み得る。後続の文字列は、「:」で始まる最初の文字列に連結され、キー=値のペアを提供する文字列がその後に続くことができる。2番目の文字列(または最初のキー=値のペア)は、「:transport=」+値文字列であり得る。可能な値文字列は、「broadcast」、「unicast」、「both」であり得る。他の値が使用される場合がある。serviceLocation属性についての文字列の例は、urn:3gpp:sl:transport=broadcast、またはurn:3gpp:sl:transport=unicastであり得る。
特定の値文字列の設定に応じて、他の制限がURLの使用に課される場合がある。たとえば、値文字列が「broadcast」であるとき、関連付けられたBaseURL要素の使用から導出されたURLは、DASHクライアントがブロードキャストを介してそのサービスを受信するときに使用され得る。より具体的には、「broadcast」に設定された値文字列を有するただ1つのBaseURLが存在する場合、サービスまたは対応する表現は、ブロードキャストを介してのみ利用可能である。「broadcast」に設定された値文字列を有するBaseURLが存在しない場合、サービスまたは対応する表現は、ブロードキャストを介して利用可能ではない。「broadcast」に設定された値文字列を有するマルチプルなBaseURLが存在する場合、マルチプルなブロードキャスト・トランスポート(たとえば、FLUTE)セッションがサービスについて定義され得るか、またはMPDによって記述されたサービスが、様々な地理的エリアでブロードキャストされ得る様々な表現を含む。様々な表現を様々なロケーションでブロードキャストされ得ることも可能である。説明の目的のみで、以下の説明では、1つのブロードキャスト表現のみが存在すると仮定する。本明細書に記載された符号化方式をサポートしないDASHクライアントとの互換性のために、「broadcast」に設定された値文字列を有するBaseURLは、BaseURLのリストの最後に配置され得る。「broadcast」に設定された値文字列を有するBaseURLは、ローカルホストhttp://localhost/などを指すことによって、ローカル(すなわち、デバイス上の)HTTPサーバにDASHクライアントを向けることができる。
値文字列が「unicast」であるときには、関連付けられたBaseURL要素上のURLは、DASHクライアントがユニキャストを介してサービスにアクセスするときに使用されることができる。値文字列が「unicast」に設定されたマルチプルなBaseURLが存在する場合、DASHクライアントは、ユニキャストを介してサービスにアクセスするときにBaseURLのうちの1つを選択するために、様々な手法を使用することができる。たとえば、1つの手法は、リストの中の最初のBaseURLから順番にBaseURLを使用することである。
値文字列が「both」であるとき、関連付けられたBaseURL要素上のURLは、DASHクライアントがユニキャストを介して、またはブロードキャストカバレージの中にいる間のいずれかで、サービスにアクセスするときに使用されることができる。値文字列が「both」に設定されたBaseURLが存在する場合、(1つだけのブロードキャスト表現が存在すると仮定して、)値文字列が「broadcast」に設定された表現についてのさらなるBaseURLは存在しない。値文字列が「both」に設定されたBaseURLは、外部の(すなわち、ネットワークからアクセス可能なサーバ)HTTPサーバにDASHクライアントを向ける。したがって、DASHクライアントがブロードキャストカバレージの中にいて、このURLが使用されるときには、デバイスは、HTTPアクセスをローカルホストにリダイレクトする技法をサポートする。
サンプルDASHクライアントの挙動: MPDにおいてシグナリングされるDASHセグメントのブロードキャストまたはユニキャストのアベイラビリティに基づいて、DASHクライアントの実装形態は、次のようにBaseURLのserviceLocation情報を使用することができる。ブロードキャストカバレージの中の最初の受信に関して、DASHクライアントは、ブロードキャストカバレージの中にいる間ブロードキャスト(たとえば、eMBMS)DASHサービスの受信を開始することができる。DASHクライアントは、(1つのブロードキャスト表現を仮定して)ブロードキャストを介してどの表現が利用可能であるかを発見し、「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、かつ/または選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。ブロードキャストの中にいる間にどのブロードキャスト表現が現在利用可能であるかを判定することは、FLUTEトランスポートを介してシグナリングされたメディアセグメントのファイル名を照合することによって行うことができる。
ブロードキャストを介してコンテンツを消費しながらブロードキャストカバレージから遷移することに関して(BC−UC)、ブロードキャストを介してブロードキャスト(たとえば、eMBMS)DASHサービスを受信するDASHクライアントは、セグメントのブロードキャスト受信から遷移し、セグメントのユニキャスト受信を開始することができる。ブロードキャストカバレージからの遷移は、LTEトランスポート内のSIBの中で利用可能なSIB−13の不在によって、より直接には、そのブロードキャストDASHサービスを搬送する(サービスの一時的モバイルグループ識別情報(TMGI)などを割り当てられた)LTEベアラが利用できないことによって、検出することができる。関係する態様では、次いで、ユニキャスト帯域幅がその表現をサポートすることができ、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有する表現についてのBaseURLが存在する場合、DASHクライアントは現在の表現の受信を続けることができる。そうでない場合、DASHクライアントは、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLが存在する異なる表現に変化することができる。マルチプルのそのようなBaseURLが存在する場合、DASHクライアントは1つを選択することができる。さらなる関係する態様では、DASHクライアントは、選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。
(たとえば、SIB−13がLTEトランスポート内のシステム情報ブロック(SIB)の中にないときの)ブロードキャストカバレージからの最初の受信に関して、DASHクライアントは、ブロードキャストカバレージの中にいない間、ユニキャストを介して利用可能なブロードキャスト(たとえば、eMBMS)DASHサービスのユニキャスト受信を開始することができる。DASHクライアントは、セグメントを取り出し、再生(play)すべき表現を選択するために利用可能な帯域幅を決定し、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、かつ/または選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。
ユニキャストを介してコンテンツを消費しながらブロードキャスト受信に遷移することに関して(UC−BC)、ユニキャストを介してブロードキャスト(たとえば、eMBMS)DASHサービスを現在受信しているDASHクライアントは、ブロードキャストカバレージに遷移し、ブロードキャストを介したセグメントの受信を開始することができる。関係する態様では、DASHクライアントは、たとえば、FLUTEトランスポート内で記述されたメディアファイル名を介して、ブロードキャストカバレージの中でどの表現が利用可能であるかを発見することができる。さらなる関係する態様では、ブロードキャストされている表現がユニキャストを介してアクセスされている表現と同じである場合、DASHクライアントは、現在の表現の受信を続けることができる。この場合、DASHクライアントは、「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択することができる。さらなる関係する態様では、DASHクライアントは、ブロードキャスト表現に遷移し、「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択することができる。さらなる関係する態様では、DASHクライアントは、選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。
ブロードキャストDASHサービスのユニキャストアベイラビリティに対する地理的制約: ブロードキャストDASHサービスがユニキャストを介して利用可能な場合でも、いくつかの地理的エリアに対するサービスコンテンツのユニキャストアベイラビリティを制限する契約上の義務または他の要件が存在する場合がある。
ユニキャストアベイラビリティに対する地理的制約は、別の値の文字列を追加することによって、ブロードキャストDASHサービス用のMPD内のBaseURLで示すことができる。たとえば、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性に関連付けられた、ブロードキャストDASHサービス用のMPD内のBaseURLは、同じくserviceLocation属性内でトランスポートされる追加文字列フォーマットを介して、ユニキャスト受信についての地理的なアベイラビリティの制約を示すことができる。具体的には、serviceLocation属性は、urnフォーマットを使用するとき、「urn:3gpp:sl」で始まる文字列を含むことができ、サービスがユニキャストを介して利用可能であることを示すために、「:transport=unicast」または「:transport=both」のいずれかを含むことができる。
(キー=値のペアのフォーマットの)文字列「:uGeo3GppCellID=」+CellID文字列は、CellID文字列を介して、サービスがユニキャストを介して消費され得る3GPPのセルIDを示すことができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=unicast:uGeo3GppCellID=345690などであり得る。
(キー=値のペアのフォーマットの)文字列「:uGeo3Gpp2S+N+Z=」+SID_value+「+」+NID_value+「+」+PZID_valueは、SID、NID、PZID、および「+」の文字列の連結を介して、サービスがユニキャストを介して消費され得る3GPP2のセルIDを示すことができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=unicast:uGeo3Gpp2S+N+Z=23+34+45などであり得る。したがって、デバイスに対して利用可能であり得る他の地理的記述子を取り込むために、他の文字列を定義することができる。
サンプルのDASHクライアントの挙動に関して、MPDにおいてシグナリングされたDASHセグメントのユニキャストアベイラビリティおよび任意の地理的制約に基づいて、DASHクライアントの実装形態は、次のようにBaseURL上のserviceLocation情報を使用することができる。地理的制約がないユニキャスト受信の場合、DASHクライアントは、ユニキャストを介してブロードキャスト(たとえば、eMBMS)DASHサービスの受信を開始することができる(すなわち、デバイスはブロードキャストカバレージの中におらず、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLが存在する)。関係する態様では、DASHクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、serviceLocationが「:uGeo」で始まる文字列を含むBaseURLが存在しないことを検証し、かつ/または選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。
制約されたエリアの中にいる間地理的制約を有するユニキャスト受信の場合、DASHクライアントは、ユニキャストを介してブロードキャスト(たとえば、eMBMS)DASHサービスの受信を開始することができる。関係する態様では、DASHクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、serviceLocationが「:uGeo」で始まる文字列を含むBaseURLが存在することを検証し、提供された地理情報を理解することを決定し、記述されたエリアの中にいることを判定し、かつ/または、記述されたエリアの中にいる間、選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行することができる。
制約されたエリアの外にいる間地理的制約を有するユニキャスト受信が存在しない状況の場合、DASHクライアントは、ユニキャストを介してブロードキャスト(たとえば、eMBMS)DASHサービスの受信を開始することができず、サービスのプレイバックは停止するはずである。関係する態様では、DASHクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、serviceLocationが「:uGeo」で始まる文字列を含むBaseURLが存在することを検証し、UE(もしくはDASHクライアント)が提供された地理情報を理解することを決定し、UEが記述されたエリアの中にいないことを判定し、提供された地理情報が理解され得ないことを決定し、かつ/または、記述されたエリアの中にいない間、選択されたBaseURLを使用する通常のDASHクライアントの挙動に従ってセグメント取出しを実行しないようにすることができる。
トランスポートアベイラビリティ調整の考慮: 図13に示されたように、DASHセグメントのアベイラビリティについてのタイムラインをMPDの中で記述することができる。本明細書ではMPD@availabilityStartTimeと呼ばれるMPDのavailabilityStartTimeは、そのタイムラインが固定された時刻からの絶対時間を定義する。MPDの最初のPeriod内のstart属性は、最初のセグメントが取出し可能になったときのavailabilityStartTimeからの継続時間(duration)を記述する。同じ表現についての次のセグメントは、セグメントが同じ継続時間であるときのその表現についてのMPD内の適切なduration属性によって間隔をあけられる(すなわち、各セグメントはセグメント継続時間によって間隔をあけられる)。図13はまた、FLUTEを介したUEへのブロードキャスト・トランスポートおよびLTEベアラが、上述されたMPDタイムラインで記述されたときよりも、セグメントのアベイラビリティをFLUTE/LTEの配信のために後になるようにさせることを示す。メディアファイルがFLUTEを介して配信されたとき、DASHクライアントは、リモートサーバからのユニキャスト取出しとは対照的に、ローカルストレージからセグメントを取り出す。ユニキャストアベイラビリティタイムラインは、MPDのavailabilityStartTime属性およびduration属性によって記述されたタイムラインであり得る。
関係する態様では、ブロードキャスト配信内のセグメントアベイラビリティタイムラインは、ユニキャスト配信のタイムラインよりも後になる必要はなく、実際、ユニキャスト配信を介したセグメントアベイラビリティの前になり得る。この場合、「アドバタイズされた」ユニキャストセグメントアベイラビリティタイムラインは、MPD内のavailabilityStartTime属性およびduration属性によって与えられたように、DASHメディアプレゼンテーションのセグメントが、MPDドキュメントの範囲内のHTTPサーバ/コンテンツ配信のエンティティの中で(DASHクライアントによるHTTP検索に)利用可能であることを保証され得るとき、「最新の」時刻を表すことができる。a)コンテンツソースからのBM−SCでのDASHセグメントの受信、b)LTEコアネットワークおよびRANを越えてFLUTEにわたるUEへの送信、ならびに/またはc)UEでのFLUTE受信、FEC復号およびセグメント復元と取出し用のローカルHTTPキャッシュへの配置の組合せを含む、ブロードキャスト配信されたセグメントの利用可能時刻は、セグメントがリモートコンテンツ配信ネットワーク(CDN)またはHTTPサーバに到達する前に起こり得ることが可能である。したがって、ブロードキャスト配信されたセグメントの利用可能時刻は、ユニキャストの利用可能時刻よりも前、同じ、または後になり得る。MPDは多数のデバイスに利用可能/提供することができ、MPDを所有するデバイスがそこからDASHセグメントを取り出すことができるマルチプルなアクセスネットワークまたはCDNを参照できることに留意されたい。たとえば、MPDドキュメントを作成したエンティティおよびDASHコンテンツ配信のサービスプロバイダは、MPDによって記述されたように、メディアプレゼンテーションと個別のRepresentationとを配信することができる。
MPD@availabilityStartTimeによって表現されたユニキャストセグメント利用可能時刻の指示が、MPDドキュメントによって支配されたすべてのHTTPサーバにわたって最も遅い可能時刻であるとすれば、より早いセグメント利用可能時刻を保証できる個別のユニキャストアクセスネットワーク/CDNがその差異をシグナリングでき、ユーザがDASHコンテンツをより早く取得し見ることが可能になることは有用である。言い換えれば、MPD@availabilityStartTimeはユニキャスト開始時刻の最悪のケースである。コンテンツを様々なCDNに配信するための様々な待ち時間が存在する。これは、その表現について定義された待ち時間期間によって表現のセグメントについてのアベイラビリティタイムラインを調整することによって行うことができる。本明細書では(図13の保護期間として示された)availabilityTimeAdjustmentと呼ばれるパラメータは、所与のアクセスネットワーク/技術用のMPD@availabilityStartTimeからの調整を示すために、BaseURL要素の下に追加することができる。言い換えれば、availabilityTimeAdjustmentは、概して、最悪のケースのユニキャスト利用可能時刻と比較して、所与のユニキャストまたはブロードキャストのネットワークを介したセグメント利用可能時刻を示すために使用することができる。
関係する態様では、Period全体についてのアベイラビリティ調整は、期間内のリソースがMPD@availabilityStartTimeの前にアクセス可能であるように、十分大きい絶対値を有する負の値であり得るし、データセグメントのより早いダウンロードがユーザ体験を向上することが可能になる。
図13を参照すると、DASHクライアントがユニキャストを介してセグメントを取り出すために使用できる取出し可能タイムラインが示される。図13のFLUTEアベイラビリティタイムラインは、たとえば、eMBMSのFLUTEセッションを介してセグメントをブロードキャストすることに含まれるアベイラビリティ調整が存在することを示し、これは、セグメントのパケット化およびトランスポート用のFEC符号化、UEに向けてのパケットのブロードキャスト、ならびにデバイス上のFEC復号およびセグメント再配置に起因する場合がある。これらのブロードキャストセグメントにアクセスするDASHクライアントの場合、このアベイラビリティ調整は、セグメントを取り出すための時間アベイラビリティが、セグメントがユニキャストを介して取り出されるか、またはブロードキャスト配信を介して取り出されるかに応じて異なるべきであることを知らせることができる。DASHクライアントは、ブロードキャストを介してセグメントを要求するとき、保護期間を考慮に入れるべきである。
保護期間は、ブロードキャストを介して取り出すためのセグメントのアベイラビリティが、ユニキャストを介して取り出される同じセグメントに比べて遅延されることをDASHクライアントに示す。
DASHセグメントのブロードキャスト配信用の保護期間のシグナリング: 上述されたように、関連付けされたserviceLocation属性を有するブロードキャストDASHサービス用のMPD内のBaseURLは、表現がブロードキャストを介して利用可能であることを示す文字列「:transport=broadcast」または「:transport=both」を含むことができる。セグメントのブロードキャスト配信に関連するアベイラビリティ調整に対応するために、同じくserviceLocation属性内でトランスポートされる追加文字列を使用して、保護期間情報を伝達することができる。たとえば、serviceLocation属性は、URNフォーマットを使用するとき、「urn:3gpp:sl」で始まる文字列を含むことができ、サービスがブロードキャストを介して利用可能であることを示すために、文字列「:transport=broadcast」または「:transport=both」を含むことができる。
(キー=値のペアのフォーマットの)文字列「:pp=」+ppValueは、ppValueを介して、たとえば、ミリ秒または他の時間増分で保護期間をシグナリングして、DASHクライアントがブロードキャスト受信を介してセグメントを要求したときに対応されるようにすることができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=broadcast:pp=50などであり得る。
サンプルのDASHクライアントの挙動に関して、MPDにおいてシグナリングされたDASHセグメントのブロードキャストアベイラビリティおよび保護期間の情報に基づいて、DASHクライアントの実装形態は、次のようにBaseURL上のserviceLocation情報を使用することができる。
ブロードキャスト配信を介した受信に関しては、DASHクライアントは、ブロードキャストエリア内でどの表現が利用可能であるかを発見し、「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、「:pp」で始まるserviceLocation属性内の部分文字列内で示された保護期間を決定し、かつ/または選択されたBaseURLを使用するMPD内のセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができるが、「:pp」を含む文字列内で示された追加ppValueミリ秒によってセグメント取出しを調整する(すなわち、先延ばす、または前倒しにする)。これにより、所与の地理的エリアにあるモバイルが、アドバタイズされたよりも早くセグメントについての要求を行うことが可能になり、より低い待ち時間の体験をユーザに提供するか、または次いでアドバタイズされた後でモバイルにセグメントを取り出させ、したがってセグメントがMPDにおいてアドバタイズされたよりも後にのみ利用可能になるときのエラー状態を回避する。
ブロードキャストカバレージの外の受信に関しては、DASHクライアントは、セグメントを取り出し表現を選択するために利用可能な帯域幅を決定し、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、かつ/または選択されたBaseURLを使用するMPD内の正確なセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができ、さらなるセグメント取出しの遅延は実行されない。
DASHセグメントのブロードキャスト配信用の保護期間のシグナリングに対する代替形態: ブロードキャスト待ち時間に対応するための代替形態が図14に示される。ブロードキャストカバレージの中にいる間、保護期間を明示的にシグナリングし、それに対応するのではなく、ブロードキャストDASHサービス用のMPDは、既存のMPDパラメータを介してブロードキャスト・トランスポートのアベイラビリティ調整に対応することができる。これは、MPDのavailabilityStartTime属性に保護期間を追加すること、または最初のMPDのPeriodのstart属性に保護期間を追加することによって、図14に示される。上述されたパラメータのいずれかに保護期間を追加することの影響は、ユニキャスト取出しも遅延されることである。
シームレスなUC−BC遷移/BC−UC遷移: ブロードキャスト・トランスポートにおけるさらなるアベイラビリティ調整に対応する2つの代替形態を考慮する際に、ユニキャストおよびブロードキャストを介したセグメントの受信およびプレイバック前のバッファリングでのUC−BC遷移およびBC−UC遷移が考慮されるべきである。図15は、セグメントNがユニキャストを介して取り出されている時点で、ユニキャストを介したセグメントの受信からブロードキャストを介した受信への遷移が起こる時点を示す。
シームレスな遷移についての1つの目標は、DASHクライアントがユニキャスト受信とブロードキャスト受信との間を遷移するとき、メディアプレイバック中の干渉を最小化することである。これを達成するために、DASHクライアントは、プレイバックが始まる前に2つ以上のセグメントを蓄積することができる。プレイバックを開始する前に蓄積するセグメントの数は、MPD内のminBufferTime属性などを介してシグナリングされ得る。図16は、(時刻tAviで)ユニキャストを介して取り出されたセグメントのプレイバックが1セグメントだけ遅延され(左のタイムライン)、かつ2セグメントだけ遅延された(右のタイムライン)、(時刻tPbiで)遅延された2つのプレイバックシナリオを有する実施形態を示す。これは、1セグメントまたは2セグメントが、それぞれ、プレイバックが開始できる前に蓄積される必要があることを意味する。図16の例は、セグメントが同じサイズであり、帯域幅が1セグメントの継続時間内にセグメントをダウンロードするために利用可能である場合に、ユニキャストを介して1セグメントをダウンロードするために1セグメントの継続時間がかかるシナリオを示す。図16の実施形態は例示的であるにすぎず、セグメントのサイズが可変であり、バッファリングするセグメントの数がそのような可変性に対応する他のシナリオを記載するために、同様の数字を描くことができることに留意されたい。
図17は、(時刻tFAviで)ブロードキャストを介して受信されたセグメントについての同様の遅延されたセグメントプレイバックのシナリオを示す。これらのセグメントは、ブロードキャストを介して配信され、前に示されたようにローカルで利用可能なので、クライアントに直ちに利用可能であり得る。図17の実施形態は、セグメントが同じサイズであり、ブロードキャスト帯域幅が1セグメントの継続時間内にセグメントを配信するために十分である場合に、ブロードキャストを介して1セグメントを配信するために1セグメントの継続時間がかかることを示唆する。図17の実施形態は例示的であるにすぎず、セグメントのサイズが可変であり、バッファリングするセグメントの数がそのような可変性に対応する同様のシナリオを記載するために、同様の数字を描くことができることに留意されたい。
図17はまた、プレイバック前の1セグメントまたは2セグメントの同じminBufferTime要件の使用を示す。図17はまた、DASHクライアントが保護期間に対応するとき、すなわち、(時刻tAviでの)ユニキャストアベイラビリティよりも後の保護期間である、(時刻tFAviでの)ブロードキャストセグメントアベイラビリティによって取出しが駆動されるとき(図15参照)、セグメントは、ローカルで容易に利用可能であり得るし、最小の待ち時間で取り出すことができる。取り出されたセグメントは、minBufferTimeが1セグメントまたは2セグメントであるとき、それぞれ1番目のセグメントまたは2番目のセグメントの後に、直ちにプレイバック準備ができている。
図16〜図17のタイムラインが与えられると、DASHクライアントがユニキャストを介してセグメントNを取り出す間にブロードキャストアベイラビリティが検出されると仮定して、UC−BC遷移への影響は以下を含み得る。第1に、セグメントNは、ブロードキャストを介した受信に成功しない(FEC復号に十分ではないシンボル)場合があり、その結果、UC−BC遷移が後で起こる可能性がある。第2に、ブロードキャストを介したDASHセグメントの受信の成功は、最初のセグメント(N+1)がブロードキャストを介して受信されるまで保証されない可能性がある。したがって、DASHクライアントは、ユニキャストを介してセグメントNの取出しを完了し、ユニキャストを介してセグメントN+1を取り出すことができる。第3に、DASHクライアントは、セグメントN+2からのセグメントの取出しを遅延(ユニキャストを停止)することができ、セグメントのブロードキャスト配信に頼ることができる。第4に、図16〜図17を考慮すると、シームレスな遷移を達成することができ、セグメントN+2は、ユニキャストを介して取り出されたように同じ時間で利用可能になり得る。すなわち、プレイバックをシームレスに進めることができる。したがって、シームレスなUC−BC遷移は、プレイバックが1セグメントだけ遅延される場合(すなわち、1セグメントに設定されたminBufferTimeによって)、実現することができる。状況に応じて、シームレスな遷移は、より大きいセグメント遅延を必要とする場合があり、より小さいセグメント遅延を必要とする場合もある。
図18は、セグメントNの受信がブロードキャストを介して取り出されている間にBC−UC遷移が起こる時点を強調することによって、逆のBC−UC遷移を示す。セグメントNは、ブロードキャストを介した受信に成功しない(FEC復号に十分ではないシンボル)場合があり、そのことが直ちに判定されない場合がある。セグメントNが受信に成功しなかったことを判定すると、DASHクライアントは、ユニキャストを介してセグメントNの取出しを開始して、連続プレイバックを保証することができる。DASHクライアントは、より低いデータレート表現に切り替えて巻き返す必要があり得る。
したがって、シームレスなBC−UCハンドオフは、セグメントNがプレイバック用の時間内にユニキャストを介して取り出すことができる場合にのみ、達成可能であり得る。図19の左のタイムラインが示すように、これは、minBufferTimeなどが1セグメントのみを規定する場合、実現可能ではない。minBufferTimeが2セグメントを規定すると(図19の右のタイムライン参照)、DASHクライアントは、巻き返し、プレイバック途絶を回避するために1セグメントの時間を有する。したがって、ブロードキャストからユニキャストへのシームレスな遷移のために、DASHクライアントは、プレイバック前に3つ以上のセグメントを蓄積して、ユニキャストを介した巻き返しダウンロードに適応するように命令されるべきである。
関係する態様では、MPDの属性上の保護期間を含むとき、DASHクライアントは、プレイバック前に3つ以上のセグメントを蓄積するように命令される場合がある。したがって、MPD内の既存のパラメータに保護期間を含めることの欠点は、さらなるセグメントアベイラビリティ調整であり得る。
ストリーミングサービスの所与の表現のブロードキャスト配信および関連するブロードキャストアベイラビリティ調整をシグナリングするためのセッション記述プロトコルの使用: いくつかの状況では、Representaionのメディアセグメントのユニキャスト対ブロードキャストの配信モードを示すために、(たとえば、serviceLocation属性などを介して)MPDを直接使用することは望ましくない。たとえば、いくつかの実装形態では、DASHセグメントおよび関連するMPDのネットワークベースの生成は、メディアコンテンツのトランスポート方法(ユニキャストおよび/またはブロードキャスト)に対して不可知論的であり得る。そのような場合、ユニキャスト対ブロードキャストの配信モードが(システム情報またはSIとも呼ばれる)サービス告知情報などを使用してシグナリングされることは、望ましい場合がある。
特に、3GPPのMBMSの場合、SIまたはUSDのコンポーネントは、セッション記述メタデータフラグメントなどであり得る。そのようなパラメータおよびシンタックスは、次に、IETFのRFC4566によって規定されたSDPに基づくことができる。「属性」という用語または「a=」は、SDPを拡張する主な方法であり、セッションレベルで(すなわち、FLUTEセッションのメディアコンポーネントに適用可能な)、またはセッション内の個別のメディアレベルで定義することができることに留意されたい。関係する態様では、属性フィールドは、たとえば、2つのフォームであり得る。関係する態様では、フォーム「a=<フラグ>」の「プロパティ」属性があり、この場合、属性の存在は、属性がセッションのプロパティであることを示すにすぎない。さらなる関係する態様では、フォーム「a=<属性>:<値>」の「値」属性があり、この場合、名前が付けられた属性の値は、任意のオクテット列などから構成される。
本明細書に記載された実施形態の態様によれば、関連するセッションのトランスポートモードを表記するために、新しいセッションレベルの属性「a=<representation−transport−mode>」が提供される。この属性の定義された<値>サブフィールドは、対応するRepresentaionなどのセグメントについて、ユニキャストのみ、ブロードキャストのみ、またはユニキャストとブロードキャストの両方の配信モードを指定する、テキスト列「unicast」、「broadcast」、または「both」の間の選択であり得る。
さらに、セグメントのブロードキャスト配信は、ユニキャスト配信と比べて、「保護期間」とも呼ばれる、さらなる遅延に関連付けられる場合がある。そのようなパラメータは、新しいサブフィールド<protection−period>などを介して、上記の「representation−transport−mode」属性に追加することができる。たとえば、「representation−transport−mode」属性のフルシンタックスは、次のようであり得る:
関係する態様では、USDのMPDフラグメント内のRepresentaionの「id」属性の値と同等である<representation−id>は、次の配信モードタグが適用される、Representaionと関連するDASHセグメントとを識別することができる。トランスポートモードが「broadcast」または「both」である場合、サブフィールド<protection−period>が現れることができ、そのRepresentaion用のブロードキャストアベイラビリティ調整を表す。
さらなる関係する態様では、サービス告知クライアントが上記の属性情報を使用して、MPD内の対応するRepresentaion用の配信モード、ならびにブロードキャスト配信モード用の保護期間をDASHクライアントに知らせることが予想される。
FLUTEセッションのブロードキャストアベイラビリティ調整をシグナリングするためのセッション記述プロトコルの使用: ブロードキャストアベイラビリティ調整をシグナリングするための上述された技法の代替形態は、トランスポートモードがMPDのserviceLocation属性を使用して宣言されるのに対して、セッション記述フラグメントを使用してブロードキャスト遅延をシグナリングすることである。この手法は、DASHからアベイラビリティ調整または保護期間情報を分離することの利益を有する。言い換えれば、ストリーミングサービスとしてのDASHコンテンツのFLUTE配信に加えて、アプリケーションが配信されたコンテンツをより早く使用することを可能にするためにブロードキャストアベイラビリティ調整の知識が有用である、他のファイル配信サービスアプリケーションが存在する可能性がある。そのようなアプリケーションの例には、モバイル端末上のリアルタイムに近いバックグラウンド表示向けの動的なニュースまたは株のティッカ情報のブロードキャストが含まれる。そのようなアプリケーションの場合、FLUTE配信に関連付けられたファイルは、符号化されたシンボルブロックの作成において重要な時間インターリービングを改善できる、アプリケーション層のFEC(たとえば、RaptorQなど)によって保護することができる。一般的にセッション記述フラグメントを介したブロードキャストアベイラビリティ調整/保護期間の告知により、関連コンテンツのプレイバックをスケジューリングするときに、UEがこの遅延を考慮に入れることが可能になるはずである。
SDP内で保護期間をシグナリングするための技法は、たとえば以下に従って実装され得る:
サービス告知クライアント(すなわち、ブロードキャスト対応UEの機能)が、関連コンテンツ配信モードのプレイバックをスケジューリングするときにこの遅延を考慮に入れるために、ブロードキャストアベイラビリティ調整のUE内で他の機能を知らせることが予想される。DASHコンテンツのブロードキャスト配信の場合、そのようなクライアント機能は、DASHクライアントを含むことができる。
適切なFLUTEセッションの決定: いくつかのブロードキャストDASHサービスの場合、サービスの2つの代替表現を同時にブロードキャストすることが望ましい場合がある。たとえば、2つの表現はビデオ解像度が異なる場合がある。各解像度は、異なるデバイスタイプ、一方は小さい画面サイズ(たとえば、スマートフォン)、および他方は大きい画面サイズ(たとえば、タブレット)に適応することができる。これらの表現のうちの1つだけが、通常所与のデバイスによって消費/利用されるので、各表現は異なるトランスポートセッションを使用してブロードキャストすることができる。eMBMSブロードキャストの場合、表現は、図20の実施形態で示された、異なるeMBMSベアラチャネル内でトランスポートされた2つのFLUTEセッションであり得る。
表現にFLUTEセッションを関連付けることに関して、関連付けられたserviceLocation属性を有するブロードキャストDASHサービス用のMPD内のBaseURLは、表現がブロードキャストを介して利用可能であることを示す「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むことができる。表現のための適切なブロードキャスト・トランスポートセッション(たとえば、eMBMS内のFLUTEセッション)をシグナリングするために、次のように追加の文字列フォーマットをserviceLocation属性内でトランスポートすることができる。
第1の態様では、URNフォーマットを使用するとき、表現のためのBaseURLについてのserviceLocation属性は、「urn:3gpp:sl」で始まる文字列を含むことができ、表現がブロードキャストを介して利用可能であることを示す「:transport=broadcast」または「:transport=both」のいずれかを含むことができる。第2の態様では、(キー=値のペアのフォーマットの)文字列「:flute=」+sourceIPAddValue+「+」+tsiValueは、sourceIPAddValueおよびtsiValueを介して、一緒にFLUTEセッションを一意に識別するソースIPアドレスとTSIとをシグナリングすることができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=broadcast:flute=198.152.39.10+4567などであり得る。
第3の態様では、(キー=値のペアのフォーマットの)代替の文字列「:fluteSDP=」+sdpURLValueは、sdpURLValueを介して、ブロードキャストサービス用に定義されたFLUTEセッションのうちの1つを識別するURLをシグナリングすることができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=broadcast:fluteSDP=http://example.com/serviceX/service.sdpなどであり得る。第4の態様では、FLUTEセッションとは異なるトランスポートセッションを記述するために他の文字列を定義することができる。
サンプルのDASHクライアントの挙動に関して、MPDにおいてシグナリングされたDASHセグメントのブロードキャストアベイラビリティおよびFLUTEセッションの表現へのマッピングに関する情報に基づいて、DASHクライアントの実装形態は、次のようにブロードキャストカバレージ中の受信用のBaseURL上のserviceLocation情報を使用することができる。第1の態様では、DASHクライアントは、メディア記述情報(たとえば、画面解像度)に基づいて、望ましい表現を選択することができる。第2の態様では、DASHクライアントは、たとえば、これらの表現用のBaseURLのserviceLocation情報が「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むとき、マルチプルな表現がブロードキャストを介して利用可能であることを検出することができる。第3の態様では、DASHクライアントは、ブロードキャストカバレージの中にいることを検出すると、選択された表現に関連付けられた、「:transport=broadcast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択することができる。第4の態様では、DASHクライアントは、選択されたBaseURLのserviceLocation属性内の「flute=」または「fluteSDP=」を含む文字列によって識別された(eMBMSの場合の)FLUTEセッションを介して、ブロードキャストを介したセグメントの受信を起こさせることができる。第5の態様では、DASHクライアントは、選択されたBaseURLを使用するMPD内のセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができる。
オンデマンドサービスのためのUC−BCのURLのシグナリング: ブロードキャストシステムは、ユニキャスト受信を介していくつかのDASHコンテンツにアクセスするマルチプルなユーザによるシステムリソースの使用を低減する方法として、ブロードキャストDASHサービスオンデマンドの定義をサポートすることができる。いくつかの状況では、ユニキャストDASHコンテンツを消費するユーザデバイスを、同じコンテンツをトランスポートするブロードキャストDASHサービスにリダイレクトすることが必要であり得る。このリダイレクションプロセスは、HTTPリダイレクション機能を使用して、ユーザデバイスに、元の要求に使用されたURLとは異なるURLを使用する望ましいセグメントを再要求させることができる。これらのリダイレクトされたURLの使用は、ユニキャストを介して取り出されている同じコンテンツ用の新しいブロードキャストDASHサービスのアベイラビリティをユーザデバイスが判定するトリガとして働くことができる。
ユニキャストからブロードキャストの受信用のセグメントURLを識別することに関して、文字列「:transport=unicast」を含むserviceLocation属性に関連付けられたブロードキャストDASHサービス用のMPD内のBaseURLは、表現がユニキャストを介して利用可能であることを示す。いくつかのユニキャストURLがリダイレクション手法をサポートするようにのみ意図されたことをさらに示すために、追加の文字列フォーマットを、リダイレクションに使用されるURLを識別するために、serviceLocation属性内でトランスポートすることもできる。より具体的には、serviceLocation属性は、urnフォーマットを使用するとき、「urn:3gpp:sl」で始まる文字列を含むことができ、サービスがユニキャストを介して利用可能であることを示すために、文字列「:transport=unicast」を含むことができる。また、(キー=値のペアのフォーマットの)文字列「:transition=」+transValueは、transValueがUC−BCまたはBC−UCのいずれかであり得る場合、URLがリダイレクション技法をサポートするようにのみ意図されたことを示すことができる。serviceLocation属性用の例示的な文字列は、urn:3gpp:sl:transport=unicast:transition=UC−BCなどであり得る。
サンプルのDASHクライアントの挙動に関して、ユニキャストを介して利用可能なDASHコンテンツがブロードキャストを介しても利用可能にされてユニキャストトラフィックをオフロードするとき、コンテンツ用の関連するMPDは、コンテンツのブロードキャストアベイラビリティとユニキャストアベイラビリティとをシグナリングすることができる。遷移URLに関する情報はまた、遷移リダイレクションに使用されるべきURLを識別するために存在することができる。遷移リダイレクションの場合、DASHクライアントの実装形態は、以下で説明されるようにBaseURLのserviceLocation情報の使用することを含むことができる。
第1の態様では、DASHクライアントが、(a)セグメントを取り出すために利用可能な帯域幅を決定し、再生すべき表現を選択し、(b)文字列「:transport=unicast」と「:transition=」とを含むBaseURLを除き、「:transport=unicast」または「:transport=both」のいずれかの文字列を含むserviceLocation属性を有するBaseURLを選択し、かつ/または(c)選択されたBaseURLを使用して通常のDASHクライアントの挙動に従ってセグメント取出しを実行する場合、DASHクライアントは、DASHコンテンツのユニキャスト受信を開始することができる。
第2の態様では、ユニキャストを介してコンテンツを消費する間、ブロードキャストサービスアベイラビリティのシグナリング(すなわち、ユニキャストからブロードキャストへの遷移の指示)が存在する場合がある。ユニキャストを介してDASHコンテンツを受信するDASHクライアントは、別のURLへのHTTPリダイレクションを得ることができる。DASHクライアントは、次いで、(a)対応するserviceLocation属性が文字列「:transport=unicast」と「:transition=UC−BC」とを含む場合、リダイレクトされたURLが同じ表現についてのMPDのBaseURLと一致するかどうかを評価し、(b)そのような一致がある場合、遷移を実施し、かつ/または(c)コンテンツのブロードキャストバージョンのアベイラビリティが判定され得るまで、リダイレクトされたURLからセグメントを取り出し続ける。
カンマ区切りの文字列を介したパラメータの伝達: 本明細書に記載された様々なパラメータは、例示目的で、かつ限定ではなく、URNフォーマットを使用して符号化されている。代替として、カンマ区切りの文字列を使用することができる。一実施形態では、カンマ区切りの文字列を次のように実装することができる。BaseURLのserviceLocation属性内でトランスポートされるべき最初の文字列は、「3gpp−sl」などであり得る。その後の文字列は、「,」で始まる最初の文字列に連結され、キー=値のペアを提供する文字列などがその後に続くことができる。
2番目の文字列(または最初のキー=値のペア)は、「,transport=」+値の文字列などであり得る。可能な値の文字列は、「broadcast」、「unicast」、「both」であり得る。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=broadcastまたは3gpp−sl,transport=unicastであり得る。
関係する態様では、ユニキャストを介してブロードキャストDASHサービスの地理的アベイラビリティをシグナリングするために、(キー=値のペアのフォーマットの)文字列「,uGeo3GppCellID=」+CellID文字列は、CellID文字列を介して、サービスがユニキャストを介して消費され得る3GPPのセルIDを示すことができる。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=unicast,uGeo3GppCellID=345690などであり得る。
(キー=値のペアのフォーマットの)文字列「,uGeo3Gpp2S+N+Z=」+SID_value+「+」+NID_value+「+」+PZID_valueは、SID、NID、PZID、および「+」の文字列の連結を介して、サービスがユニキャストを介して消費され得る3GPP2のセルIDを示すことができる。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=unicast,uGeo3Gpp2S+N+Z=23+34+45などであり得る。
デバイスに対して利用可能であり得る他の地理的記述子を取り込むために、他の文字列を定義することができる。
さらなる関係する態様では、(キー=値のペアのフォーマットの)文字列「,pp=」+ppValueは、ppValueを介して、ミリ秒保護期間をシグナリングして、DASHクライアントがブロードキャストカバレージの中にいる間、セグメントを要求したときに対応される。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=broadcast,pp=50などであり得る。
さらなる関係する態様では、表現についての適切なブロードキャストトランスポートセッションをシグナリングするために、(キー=値のペアのフォーマットの)文字列「,flute=」+sourceIPAddValue+「+」+tsiValueは、sourceIPAddValueおよびtsiValueを介して、一緒にFLUTEセッションを一意に識別するソースIPアドレスとTSIとをシグナリングすることができる。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=broadcast,flute=198.152.39.10+4567などであり得る。
(キー=値のペアのフォーマットの)代替の文字列「,fluteSDP=」+sdpURLValueは、sdpURLValueを介して、ブロードキャストサービス用に定義されたFLUTEセッションのうちの1つを識別するURLをシグナリングすることができる。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=broadcast,fluteSDP=http://example.com/serviceX/service.sdpなどであり得る。
FLUTEセッションとは異なるトランスポートセッションを記述するために他の文字列を定義することができる。
さらなる関係する態様では、(キー=値のペアのフォーマットの)文字列「,transition=」+transValueは、transValueがUC−BCまたはBC−UCのいずれかであり得る場合、URLがリダイレクション技法をサポートするようにのみ意図されたことを示すことができる。serviceLocation属性用の例示的な文字列は、3gpp−sl,transport=unicast,transition=UC−BCなどであり得る。
XML文字列を介したパラメータの伝達: BaseURLのserviceLocation属性内のトランスポート用のここまで記載された様々なパラメータを符号化するさらに別の方法は、XMLファイルを介することである。これらのパラメータ用のXML構造は、単一サービス用のマルチプルなブロードキャスト送信を示す図21の例で示されたように、XMLスキーマ上で取り込むことができる。
一実施形態では、トランスポートのタイプをシグナリングするために、serviceLocation属性は次のようであり得る。ブロードキャストタイプの場合、serviceLocation属性は、以下であり得る:
ユニキャストタイプの場合、serviceLocation属性は、以下であり得る:
別の実施形態では、ユニキャストを介してブロードキャストDASHサービスの地理的アベイラビリティをシグナリングするために、以下が適用される。
3GPPのセルIDを使用する:
3GPP2のセルIDを使用する:
さらに別の実施形態では、保護期間をシグナリングするために、以下が適用される:
さらに別の実施形態では、表現についての適切なブロードキャスト・トランスポートセッションをシグナリングするために、以下が適用される:
さらに別の実施形態では、オンデマンドDASHサービスに使用されるURLをシグナリングするために、以下が適用される:
ブロードキャストトランスポートモードおよび/またはブロードキャストアベイラビリティ調整を宣言するためのオプション: 本開示の主題の態様によれば、MPDを使用して、DASHセグメントのトランスポートモード、ならびに、それらの同じセグメントのユニキャスト配信に対して、ブロードキャストを介して配信されるメディアセグメントのアベイラビリティにおけるアベイラビリティ調整を宣言するための他のオプションが提供される。上述された1つの手法は、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報に関する、そのようなメタデータをトランスポートするためのserviceLocation属性を使用することを含む。上述された別の手法は、SDPファイルなどを介して、MBMSサービス告知情報のセッション記述を使用して、トランスポートモードおよび配信アベイラビリティ調整の情報を提供することを含む。
代替または追加として、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報は、TransportDescriptionなどの名前の新しいMPD要素内でシグナリングすることができる。たとえば、TransportDescriptionは、(たとえば、MPEG DASH(ISO/IEC23009−1)規格または3GP−DASH(3GPP TS26.247)規格によって定義された)汎用記述子要素のタイプを表し、MPD内で記述されたRepresentaion用の送信およびアクセス関連の情報の容器として働くことができる。そのような送信およびアクセスの情報の例には、i)送信トポロジー(ユニキャスト、ブロードキャスト、または両方)、ii)特定タイプのブロードキャスト技法(たとえば、セルラーMBMSオーバーGERAN、UTRAN、もしくはLTE)、地上放送TVシステム(たとえば、ATSC、ISDB−T、T−DMB、CMMB、もしくはDVB−T)、または衛星TV放送技術(たとえば、DVB−SもしくはS−DMB)、iii)アクセス技術に固有の情報に関するサービス告知/発見に対する参照、およびiV)ユニキャスト配信のセグメントアベイラビリティに対するセグメントアベイラビリティのブロードキャスト配信固有のアベイラビリティ調整が含まれ得る。ブロードキャスト固有のアベイラビリティ調整は、ユニキャストセグメント利用可能時間に追加されるべき時間遅延値を提供することによって、MPD@availabilityStartTimeを増加させることができる。得られた値(ユニキャストセグメント利用可能時間+ブロードキャスト遅延値)は、ブロードキャストセグメント利用可能時間を表す。
代替または追加として、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報は、MPD内のBaseURL要素の下の新しい拡張パラメータによってシグナリングされることができる。新しい拡張パラメータは、MBMS配信を示し、さらにブロードキャストアベイラビリティ調整を告知する、子要素または子属性broadcastDeliveryを含むことができる。新しい拡張パラメータは、Representaion要素などのBaseURLの子要素の下に現れることができる。この手法は、メディアプレゼンテーションの個別のRepresentaionがブロードキャスト配信に利用可能かどうかの指示を提供するはずであり、任意の様々な待ち時間の指示も提供するはずである。
TransportDescriptionは、サービス告知情報へのエントリポイントを提供するためにのみ定義できることに留意されたい。アベイラビリティ調整パラメータは、MPDのBaseURL要素に移動させることができる。関係する態様では、TransportDescription要素がブロードキャスト・トランスポートのケースで示されたアクセス固有のパラメータを表現するために使用されるとき、送信およびアクセスの関連情報は、技術(たとえば、セルラー、地上TV、衛星TVなど)を明示的に識別することができる。ブロードキャスト技術は、アクセス固有のパラメータなどをトランスポートするためのBaseURL要素を拡張することによって、識別することができる。さらなる関係する態様では、Transport記述子は、たとえば、MPDの様々な階層レベル、たとえば、最上位MPD要素レベル、またはMPDの子要素(たとえば、Period、AdaptationSet、Representationなど)の下に置くことができる。TransportDescription要素はBaseURLのピア要素であり得るか、またはSegmentBaseのピア要素であり得ることに留意されたい。
関係する態様では、各セグメントは異なるネットワークを介して配信することができるので、Transport記述子(すなわち、TransportDescription要素)は、MPD内で宣言された個別のセグメントに対処することが可能であり得る。さらなる関係する態様では、Transport記述子はRepresentationレベルで定義することができる。たとえば、Transport記述子は、Periodレベル、AdaptationSetレベル、および/またはRepresentationレベルで追加され得るように、以下の要素に追加することができる:(a)次いで柔軟に使用することができるBaseURL要素、および/または(b)(たとえば、BaseURLが存在しないときの)SegmentBase要素。
関係する態様では、Transport記述子の属性schemeIdUriによって表されるTransport記述子アクセス方式は、DASHクライアント、デバイスミドルウェア、または他のUE機能がこの機能を解釈して、ネットワークスタックがこのトランスポート方式をサポートするかどうかを判定することができるように、構築することができる。Transport記述子内の関連付けられた値は、サービス告知へのトランスポートに対する一意のエントリポイントを提供することができる。たとえば、関連付けられた値は、サービス告知ドキュメントへのserviceIDまたはURLであり得る。
関係する態様では、MBMSの場合、Transport記述子の値は、(たとえば、URL内のフラグメントとしてコード化された)serviceIDも含むユーザサービスバンドルドキュメント/フラグメントへのURLであり得る。Transport記述子の値は、参加されるべきFLUTEセッションに関する固有情報を含むことができる。代替または追加として、サービスおよびアクセスの発見情報へのURLは、HTTPなどを介したウェブページ上で利用可能にすることもできる。この場合、ブロードキャスト/マルチキャストのリンク用のユーザサービスバンドル記述ドキュメントとしてURLによってリンクされたドキュメントを識別するコンテンツタイプを定義することができる。
表現のブロードキャストおよび/またはユニキャストアベイラビリティのシグナリング: 本明細書に記載された実施形態の1つまたは複数の態様によれば、ブロードキャストワイヤレスシステム内のメディアデータセグメントの表現のブロードキャストアベイラビリティおよび/またはユニキャストアベイラビリティをシグナリングするための技法が提供される。図10Bを参照すると、eMBMSサービス用のシステム情報を含む例示的なUSDが示される。USDは、ブロードキャスト、ユニキャスト、または両方を介した表現のアベイラビリティを記述するように拡張されている。
図10Bが示すように、更新されたmedia−Presentation−Description−2要素の存在は、mpdURI要素がリンクを提供してDASHサービスに関連付けられたMPDを識別する場合、USDが記述するサービスがDASH eMBMSサービスであることを示す。
更新されたmedia−Presentation−Description−2要素はまた、ブロードキャスト表現とユニキャスト表現とを識別するbroadcast−Representaion要素およびunicast−Representaion要素のリストを提供する。両方のリストで識別された表現は、ユニキャストおよびブロードキャストを介して利用可能である。
いずれかのリスト内の表現は、periodId属性を介した期間により、adaptationSetId属性を介した適合セットにより、かつ/または、representaionId属性を介した表現により、MPD内で識別されたそれぞれの値への参照として識別することができる。ブロードキャスト表現はまた、所与のブロードキャストエリア内でどの表現が利用可能であるかを、ブロードキャストコンポーネントが判定することを可能にする、serviceArea情報と関連付けることができる。
ブロードキャストサービスはまた、マルチプルなトランスポートストリームを含むことができるので、ブロードキャストDASHサービスは、別々のトランスポートストリームを介してトランスポートされている様々な表現を有することができる。これは、様々なデバイス能力を対象にする様々な解像度、または様々なユーザ選好を対象にする様々な言語を提供するように行われる可能性がある。
例示的なブロードキャストクライアントの挙動では、eMBMSのDASHサービス用のUSD内でシグナリングされるDASH表現のブロードキャストおよび/またはユニキャストのアベイラビリティに基づいて、ブロードキャストeMBMSクライアントは、デバイスがいつブロードキャストカバレージに出入りするかを知り、かつ/または、図10Bが示すようなシステム情報(たとえば、eMBMS内のUSD)に従って、MPD内のDASH表現のうちのどれがブロードキャストサービスを介して利用可能であり、どれがユニキャストを介して利用可能であるかを知ることが可能であり得る。関係する態様では、ブロードキャストカバレージ状態に応じて、ブロードキャストクライアントは、デバイスがブロードキャストカバレージに入ると利用可能なブロードキャスト表現のうちの1つを選択するようにクライアントにシグナリングし、かつ/またはデバイスがブロードキャストカバレージから出ると利用可能なユニキャスト表現のうちの1つを選択するようにDASHクライアントにシグナリングすることができる。さらなる関係する態様では、DASHクライアントのブロードキャスト表現の選択に応じて、ブロードキャストクライアントは、選択された表現をトランスポートするFLUTEセッションの受信をアクティブ化することができる。
属性availabilityTimeAdjustmentは、存在する場合、MPDフラグメント(すなわち、MPD@availabilityStartTime)内で宣言され、正または負のいずれかの値であり得るセグメント利用可能開始時刻に対する表現のブロードキャスト受信の調整を指定する。正(負)の値は、Representaionのセグメントの利用可能時刻が、該当する場合、ユニキャストを介して配信されるメディアプレゼンテーションの任意のRepresentaionの利用可能時刻よりも後(前)であることを意味する。serviceArea要素およびsessionDescription要素は、存在する場合、それぞれ、それを介したRepresentaionが利用可能であるサービスエリアと、そのRepresentaionをトランスポートするFLUTEセッションとを表記する。unicastRepresentaion要素は、存在する場合、フォールバック配信用にユニキャストを介して供給される各Representaionを識別する。ユニキャスト配信されたRepresentaionは、MBMSベアラも介して配信された同じ表現であり得るか、またはユニキャストベアラのみを介して配信されたRepresentaionであり得る。
本明細書で図示および記載された例示的なシステムに鑑みて、開示された主題に従って実装され得る方法は、様々なフローチャートを参照してより良く理解されよう。説明を簡単にするために、方法が一連の行為/ブロックとして図示および記載されるが、いくつかのブロックは、本明細書で描写および記載された順序とは異なる順序で、かつ/または他のブロックと実質的に同時に行われ得るので、請求された主題はブロックの数または順序によって限定されないことを理解し、諒解されたい。その上、本明細書に記載された方法を実施するために、図示されたすべてのブロックが必要とされるとは限らない。ブロックに関連する機能は、ソフトウェア、ハードウェア、それらの組合せ、または任意の他の適切な手段(たとえば、デバイス、システム、プロセス、もしくはコンポーネント)によって実装され得ることを理解されたい。加えて、本明細書の全体にわたって開示された方法は、そのような方法を様々なデバイスに移送および転送することを容易にする製品に記憶することが可能であることをさらに諒解されたい。方法は、代替的に、状態図などの一連の相互に関係する状態または事象として表現され得ることを、当業者は理解し、諒解するであろう。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図22Aを参照すると、モバイルエンティティ(たとえば、UEなど)によって動作可能な方法2200が示される。方法2200は、2210で、MPDを受信することを含むことができ、MPDは、(たとえば、ファイル配信セッションのアクティブ化に応答して、)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータを備える。ユニキャストの場合、データはHTTPサーバまたは「クラウド内」に存在することができるのに対して、ブロードキャストの場合、データはUEのHTTPキャッシュにローカルに存在することができることに留意されたい。方法2200は、2220で、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法2200は、2230で、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法2200は、2240で、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現についてのデータセグメントを受信することを含むことができる。
図22B〜図22Dを参照すると、オプションであり、モバイルエンティティなどによって実行され得る方法2200のさらなる動作または態様が示される。方法2200が図22Bまたは図22Cの少なくとも1つのブロックを含む場合、方法2200は、図示された後続のダウンストリームブロックを必ずしも含む必要なしに、少なくとも1つのブロックの後で終了することができる。ブロックの参照番号は、ブロックが方法2200に従って実行され得る特定の順序を意味しないことに、さらに留意されたい。たとえば、モバイルエンティティは、ブロードキャストモバイルシステム上で動作することができ、ブロードキャストDASHサービスは、MPDを含むシステム情報メタデータを介して定義することができ、方法は、ブロードキャストDASHサービスの代替的な配信がユニキャスト送信を介して利用可能であるかどうかを、MPD内のパラメータから判定することを含むことができる(ブロック2250)。
方法2200は、モバイルエンティティの現在の位置におけるブロードキャスト送信のアベイラビリティを判定すること(ブロック2252)と、ブロードキャスト送信のアベイラビリティがない場合、ブロードキャスト送信の代替としてユニキャスト送信のアベイラビリティを判定すること(ブロック2254)とを含むことができる。
基準は、表示解像能力(display resolution capabilities)、言語能力(language capabilities)、モバイルエンティティのワイヤレスネットワーク互換性、または表現の帯域幅要件をサポートするためのワイヤレスチャネルアベイラビリティのうちの少なくとも1つを含むことができる(ブロック2256)。所与の表現に関連付けられたブロードキャストファイル配信セッションについての情報は、メディアセグメントの受信用のブロードキャストファイル配信セッションをアクティブ化するために使用される(ブロック2258)。
方法2200は、現在のブロードキャストサービスエリア内で受信され得る、利用可能なブロードキャスト表現の中から選択することによって、ブロードキャスト受信用の表現を選択すること(ブロック2260)を含むことができる。
方法2200は、現在のユニキャストサービスエリア内で受信され得る、代替配信に利用可能なユニキャスト表現の中から選択することによって、ユニキャスト受信用の表現を選択すること(ブロック2262)を含むことができる。
図22Cを参照すると、受信すること(ブロック2240)は、所与の表現についての待ち時間調整期間により、表現のデータセグメントについてのアベイラビリティタイムラインを調整すること(ブロック2264)を含むことができる。
受信すること(ブロック2240)は、それらそれぞれの待ち時間調整期間によって定義された表現についてのアベイラビリティタイムラインの差を考慮すること(ブロック2266)と、データセグメントへのアクセスに影響するブロードキャスト送信およびユニキャスト送信の特性を考慮すること(ブロック2268)と、コンテンツのそれぞれの表現についてユニキャスト送信を介した受信とブロードキャスト送信を介した受信との間のシームレスな遷移を達成するためにデータセグメントのバッファリングを調整すること(ブロック2270)とを含むことができる。
待ち時間期間の調整は、ユニキャスト送信に対する、ブロードキャスト送信を介した所与の表現についてのデータセグメントのアベイラビリティにおける時間遅延(time delay)または時間前進(time advance)を示すことができる(ブロック2272)。たとえば、パラメータは、データセグメントのユニキャスト配信に対する、データセグメントのブロードキャスト配信用のアベイラビリティ調整を示すことができる。たとえば、パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントのアベイラビリティにおける予想される時間遅延を示すことができる。代替として、パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントのアベイラビリティにおける予想される時間前進を示すことができる。
パラメータは、データセグメントの(a)ユニキャストのみ、(b)ブロードキャストのみ、または(c)ユニキャストとブロードキャストの両方のアベイラビリティを示すことができる(ブロック2274)。パラメータのうちの少なくとも1つは、データセグメントの(b)ブロードキャストのみ、または(c)ユニキャストとブロードキャストの両方のアベイラビリティに関係し、ブロードキャスト分配技術を識別する(ブロック2276)。たとえば、少なくとも1つのブロードキャスト分配技術は、たとえば、a)セルラーブロードキャスト技術、b)地上放送TVシステム、またはc)衛星TV放送技術などの、IPベースのブロードキャストシステムに対応することができる。
図22Dを参照すると、パラメータは、いくつかの識別されたブロードキャストサービスエリア内のブロードキャスト表現のアベイラビリティに関する情報を含む(ブロック2278)。
データセグメントは、DASHメディアセグメントなどであり得るし(ブロック2280)、方法2200は、ブロードキャスト送信からユニキャスト送信に、またはその逆に変化するメディアセグメントの受信に応答して、メディアセグメントのシームレスなプレイバックを達成するためにメディアセグメントを蓄積すること(ブロック2282)をさらに含むことができる。パラメータは、MPD内の拡張要素TransportDescriptionなどの1つまたは複数のインスタンスにおいて符号化されることができる(ブロック2284)。パラメータは、ブロードキャストコンテンツの特定の表現のためのFLUTEセッション識別子などを含み得る(ブロック2286)。
関係する態様では、判定すること(ブロック2220)は、ユニキャスト取出しがデータセグメントの受信に適することを判定することを含むことができる。パラメータは、ユニキャスト取出し用のデータセグメントの地理的アベイラビリティを示すことができる。さらなる関係する態様では、パラメータは、コンテンツ用のMPD内のserviceLocation属性を介して、コンテンツのオンデマンドブロードキャストバージョンへのユニキャストDASHアクセスを指示するための情報を備えることができる。
さらなる関係する態様では、パラメータは、MPDのBaseURL内で符号化することができる。パラメータは、登録されたNIDの下のURNを備えることができる。パラメータは、BaseURL内のserviceLocation属性内の文字列としてトランスポートされた、キー=値のペアのコロン区切りのリストを含む、URNの名前空間固有文字列(NSS)を備えることができる。パラメータは、所与のデータストリーム用の代替形態を提供するDASH表現に関することができる。
さらなる関係する態様では、パラメータは、MPDの下の拡張要素TransportDescriptionの1つまたは複数のインスタンス内で符号化することができる。MPDの下の拡張要素TransportDescriptionは、MPDデータ構造の以下の様々な階層レベルのうちの1つまたは複数の中に存在することができる:MPD要素、Period要素、AdaptationSet要素、およびRepresentation要素。TransportDescriptionは、汎用記述子要素のタイプであり得るし、MPD内で記述されたRepresentation用の送信およびアクセスの関連情報を含むことができる。TransportDescriptionの各インスタンス内でトランスポートされる送信およびアクセスの関連情報は、少なくとも1つの送信トポロジー:a)ユニキャスト、b)ブロードキャスト、またはc)ユニキャストとブロードキャストの両方を示すことができる。
送信トポロジーがブロードキャスト、またはブロードキャストとユニキャストの両方として示された場合、送信およびアクセスの関連情報は、a)セルラーブロードキャスト技術、b)地上放送TVシステム、またはc)衛星TV放送技術の特定タイプのうちの1つを示すことができる。送信およびアクセスの関連情報は、ブロードキャスト技術についてのサービス告知/発見情報にアクセスするためのエントリポイント情報を示すことができる。ブロードキャスト技術についてのサービス告知/発見情報にアクセスするためのエントリポイント情報に加えて、送信およびアクセスの関連情報は、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントの予想されるアベイラビリティ調整を示すことができる。データセグメントのユニキャスト配信を介した利用可能時間は、MPD@availabilityStartTimeの値によって表すことができるか、またはそれから導出することができる。
関係する態様では、パラメータは、MPD内のBaseURL要素の少なくとも1つのインスタンスの下の1つまたは複数の拡張パラメータ内で符号化することができる。BaseURL要素の1つまたは複数のインスタンスの各々の中のパラメータは、ユニキャストまたはブロードキャストのトランスポートモードを示すことができる。トランスポートモードがブロードキャストとして示された場合、関連するパラメータは、a)セルラーブロードキャスト技術、b)地上放送TVシステム、またはc)衛星TV放送技術の特定タイプのうちの1つのブロードキャスト分配技術の明示的な識別を可能にすることができる。パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントの予想されるアベイラビリティ調整を示すことができる。パラメータは、メディアプレゼンテーションの個別の表現がブロードキャスト配信に利用可能であるかどうかを示すことができる。トランスポートモードがユニキャストとして示された場合、関連するパラメータは、コンテンツ配信ネットワーク(CDN)タイプの1つのユニキャストアクセスネットワークの明示的な識別を可能にすることができる。パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、このユニキャストアクセスネットワークまたはCDN上の取出し用のデータセグメントの予想されるアベイラビリティ調整を示すことができる。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図22A〜図22Dに関して上述された方法を実行するためのデバイスおよび装置が提供される。図23を参照すると、モバイルエンティティとして、またはその中で使用するためのプロセッサもしくは同様のデバイス/コンポーネントとして構成され得る、例示的な装置2300が提供される。装置2300は、プロセッサ、ソフトウェア、またはそれらの組合せ(たとえば、ファームウェア)によって実装された機能を表すことができる機能ブロックを含むことができる。たとえば、装置2300は、MPDを受信するための電気的なコンポーネントまたはモジュール2312を含むことができ、MPDは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備える。装置2300は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定するためのコンポーネント2314を含むことができる。装置2300は、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択するためのコンポーネント2316を含むことができる。装置2300は、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現のためのデータセグメントを受信するためのコンポーネント2318を含むことができる。
関係する態様では、プロセッサとしてではなく、モバイルエンティティとして構成された装置2300の場合、装置2300は、少なくとも1つのプロセッサを有するプロセッサ/コントローラコンポーネント2350をオプションで含むことができる。そのような場合、プロセッサ2350は、バス2352などを介してコンポーネント2312〜2318と動作可能に通信することができる。プロセッサ2350は、コンポーネント2312〜2318によって実行されるプロセスまたは機能の起動とスケジューリングとを実現することができる。
さらなる関係する態様では、装置2300は、無線周波数(RF)送受信機コンポーネント2354を含むことができる。送受信機2354の代わりに、または送受信機2354とともに、スタンドアロン受信機および/またはスタンドアロン送信機を使用することができる。装置2300は、たとえば、メモリデバイス/コンポーネント2356などの情報を記憶するためのコンポーネントをオプションで含むことができる。コンピュータ可読媒体またはメモリコンポーネント2356は、バス2352などを介して装置2300の他のコンポーネントに動作可能に結合することができる。メモリコンポーネント2356は、コンポーネント2312〜2318およびそれらのサブコンポーネントのプロセスおよび挙動、またはプロセッサ2350、または図22A〜図22Dを参照して上述された方法を実現するためのコンピュータ可読命令とデータとを記憶するように適合することができる。メモリコンポーネント2356は、コンポーネント2312〜2318に関連する機能を実行するための命令を保持することができる。メモリ2356の外部にあるものとして示されているが、コンポーネント2312〜2318はメモリ2356の内部に存在する場合があることを理解されたい。図23内のコンポーネントは、プロセッサ、電子デバイス、ハードウェアデバイス、電気サブコンポーネント、論理回路、メモリ、ソフトウェアコード、ファームウェアコードなど、またはそれらの任意の組合せを備える場合があることにさらに留意されたい。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図24は、モバイルエンティティなどによって動作可能な別の例示的な方法2400を示す。方法2400は、2410で、(a)DASH MPDと、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含む、システム情報を受信することを含むことができる。方法2400は、2415で、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法2400は、2420で、モバイルエンティティのパラメータおよび基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法2400は、2430で、所与の表現のためのデータセグメントを受信することを含むことができる。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図25は、図24を参照して上述された方法2400を実行するための装置2500(たとえば、モバイルエンティティまたはそのコンポーネント)の設計を示す。たとえば、装置2500は、(a)DASH MPDと、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含む、システム情報を受信するための電気的なコンポーネントまたはモジュール2512を含むことができる。装置2500は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定するためのコンポーネント2513を含むことができる。装置2500は、モバイルエンティティのパラメータおよび基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択するためのコンポーネント2514を含むことができる。装置2500は、所与の表現のためのデータセグメントを受信するためのコンポーネント2516を含むことができる。簡潔にするために、装置2500に関する詳細の残りはさらに詳述されないが、装置2500の特徴および態様の多くは、図23の装置2300に関して上述された特徴および態様と実質的に同様であることを理解されたい。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図26を参照すると、ネットワークエンティティ(たとえば、eNBなど)によって動作可能な方法2600が示される。方法2600は、2610で、MPDを送ることを含むことができ、MPDは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備える。方法2600は、2620で、コンテンツの所与の表現についての要求を受信することを含むことができる。方法2600は、2630で、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、所与の表現のためのデータセグメントを送ることを含むことができる。方法は、サービスのどの表現がブロードキャスト送信またはユニキャスト送信に利用可能であるかシグナリングすること(ブロック2640)をオプションで含むことができる。たとえば、データセグメントを送ること(ブロック2630)は、ユニキャスト送信を介して所与の表現のためのデータセグメントを送ることと、並行して、ブロードキャスト送信を介して少なくとも1つの異なる表現のためのデータセグメントを送ることと(ブロック2650)を含むことができる。
本明細書に記載された実施形態の1つまたは複数の態様によれば、図27は、図26を参照して上述された方法2600を実行するための装置2700(たとえば、ネットワークエンティティまたはそのコンポーネント)の設計を示す。たとえば、装置2700は、MPDを送るための電気的なコンポーネントまたはモジュール2712を含むことができ、MPDは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータを備える。装置2700は、コンテンツの所与の表現についての要求を受信するためのコンポーネント2714を含むことができる。装置2700は、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、所与の表現のためのデータセグメントを送るためのコンポーネント2716を含むことができる。簡潔にするために、装置2700に関する詳細の残りはさらに詳述されないが、装置2700の特徴および態様の多くは、図23の装置2300に関して上述された特徴および態様と同様であることを理解されたい。しかしながら、装置2700は、eNBなどのネットワークエンティティであり得ることに留意されたい。したがって、装置は、ネットワークインターフェースコンポーネント(たとえば、ネットワークインターフェースカードまたはネットワークインターフェースコントローラ)、ならびに、通常、ワイヤレス通信システムで使用される基地局内で見出される他のコンポーネントを含むことができる。
ネットワークサイドは、MPDと、ブロードキャスト表現および/またはユニキャスト表現の間で選択するモバイルデバイス/エンティティへのパラメータとを記述することに留意されたい。ネットワークは、ブロードキャスト表現を送り、モバイルデバイスがセグメントを取り出すことに利用可能なユニキャスト表現を作成する。関係する態様では、装置2700は、モバイルエンティティがメディアデータセグメントの受信用にユニキャストモードを選択したことに応答して、ユニキャストHTTPなどを介してメディアデータセグメントのモバイルエンティティ選択の表現を送ることをさらに含むことができる。
情報および信号は様々な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表すことができる。
本明細書の開示に関連して記載された様々な例示的な論理ブロック、モジュール、回路、およびプロセスステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者はさらに諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、概してそれらの機能に関して上述された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、記載された機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈されるべきではない。
本明細書の開示に関連して記載された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書に記載された機能を実行するように設計されたそれらの任意の組合せを用いて、実施または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。プロセッサは、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装することもできる。
本明細書の開示に関して記載された方法またはプロセスのステップは、直接ハードウェアで具現化するか、プロセッサによって実行されるソフトウェアモジュールで具現化するか、またはその2つの組合せで具現化することができる。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROM(登録商標)メモリ、レジスタ、ハードディスク、リムーバブルディスク、CD−ROM、または当技術分野で知られている任意の他の形態の記憶媒体に常駐することができる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサに一体化することができる。プロセッサおよび記憶媒体はASICに常駐することができる。ASICはユーザ端末に常駐することができる。代替として、プロセッサおよび記憶媒体は、ユーザ端末内の個別構成要素として常駐することができる。
1つまたは複数の例示的な設計では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、または任意のそれらの組合せに実装することができる。ソフトウェアに実装する場合、機能は、1つもしくは複数の命令もしくはコードとしてコンピュータ可読媒体上に記憶するか、またはコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、汎用または専用のコンピュータによってアクセスできる任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体には、RAM、ROM、EEPROM、CD−ROMまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは、命令またはデータ構造の形態の所望のプログラムコード手段をトランスポートまたは記憶するために使用され得るし、汎用もしくは専用のコンピュータ、または汎用もしくは専用のプロセッサによってアクセスされ得る、任意の他の媒体を含むことができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または非一時的ワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または非一時的ワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびブルーレイ(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
本開示の前述の説明は、いかなる当業者も本開示を作成または使用することができるように提供される。本開示に対する様々な修正は当業者には容易に明らかであり、本明細書で定義された一般原理は、本開示の趣旨または範囲から逸脱することなく他の変形形態に適用することができる。したがって、本開示は、本明細書に記載された例および設計に限定されるものではなく、本明細書で開示された原理および新規の特徴に合致する最も広い範囲を与えられるべきである。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ワイヤレス通信のためのモバイルエンティティによって動作可能な方法であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含む、メディアプレゼンテーションディスクリプション(MPD)を受信することと、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信することと
を備える、方法。
[C2]
前記モバイルエンティティがブロードキャストモバイルシステム上で動作し、ブロードキャストDASHサービスが、前記MPDを含むシステム情報メタデータを介して定義され、前記方法が、前記ブロードキャストDASHサービスの代替的な配信が前記ユニキャスト送信を介して利用可能であるかどうかを、前記MPD内の前記パラメータから判定することをさらに備える、上記C1に記載の方法。
[C3]
判定することが、
前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定することと、
前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定することと
をさらに含む、上記C1に記載の方法。
[C4]
前記基準が、表示解像能力、言語能力、前記モバイルエンティティのワイヤレスネットワーク互換性、または前記表現の帯域幅要件をサポートするためのワイヤレスチャネルアベイラビリティのうちの少なくとも1つを含む、上記C1に記載の方法。
[C5]
前記所与の表現に関連付けられたブロードキャストファイル配信セッションについての情報が、メディアセグメントの前記受信のための前記ブロードキャストファイル配信セッションをアクティブ化するために使用される、上記C4に記載の方法。
[C6]
現在のブロードキャストサービスエリア内で受信され得る利用可能なブロードキャスト表現の中から選択することによって、ブロードキャスト受信用の表現を選択することをさらに備える、上記C1に記載の方法。
[C7]
現在のユニキャストサービスエリア内で受信され得る代替配信に利用可能なユニキャスト表現の中から選択することによって、ユニキャスト受信用の表現を選択することさらに備える、上記C1に記載の方法。
[C8]
前記所与の表現のための前記データセグメントを受信することが、前記所与の表現のための待ち時間調整期間により、前記表現の前記データセグメントについてのアベイラビリティタイムラインを調整することをさらに含む、上記C1に記載の方法。
[C9]
前記所与の表現のための前記データセグメントを受信することが、
それらそれぞれの待ち時間調整期間によって定義された、前記表現のためのアベイラビリティタイムラインの差を考慮することと、
前記データセグメントへのアクセスに影響する前記ブロードキャスト送信および前記ユニキャスト送信の特性を考慮することと、
前記コンテンツのそれぞれの表現のための前記ユニキャスト送信を介した前記受信と前記ブロードキャスト送信を介した前記受信との間のシームレスな遷移を達成するためにデータセグメントのバッファリングを調整することと
をさらに含む、上記C1に記載の方法。
[C10]
前記待ち時間調整期間が、前記ユニキャスト送信に対する、前記ブロードキャスト送信を介した前記所与の表現のための前記データセグメントの前記アベイラビリティにおける時間遅延または時間前進を示す、上記C8に記載の方法。
[C11]
前記パラメータが、前記データセグメントの(a)ユニキャストのみ、(b)ブロードキャストのみ、または(c)ユニキャストとブロードキャストの両方のアベイラビリティを示し、
前記データセグメントの(b)ブロードキャストのみ、または(c)ユニキャストとブロードキャストの両方のアベイラビリティに関する前記パラメータのうちの少なくとも1つが、ブロードキャスト分配技術を識別する、
上記C1に記載の方法。
[C12]
前記パラメータが、いくつかの識別されたブロードキャストサービスエリア内のブロードキャスト表現のアベイラビリティに関する情報を含む、上記C1に記載の方法。
[C13]
前記データセグメントが、動的適応ストリーミングオーバーHTTP(DASH)メディアセグメントを備え、
前記方法が、前記ブロードキャスト送信から前記ユニキャスト送信にまたはその逆に変化する前記メディアセグメントの前記受信に応答して、前記メディアセグメントのシームレスなプレイバックを達成するために前記メディアセグメントを蓄積することをさらに備える、
上記C1に記載の方法。
[C14]
前記パラメータが、前記MPD内の拡張要素TransportDescriptionの1つまたは複数のインスタンスにおいて符号化され、
前記パラメータが、ブロードキャストコンテンツの特定の表現のためのファイル配信オーバー単方向トランスポート(FLUTE)セッション識別子を含む、
上記C1に記載の方法。
[C15]
装置であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション(MPD)を受信するための手段と、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定するための手段と、
モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するための手段と、
前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信するための手段と
を備える、装置。
[C16]
前記装置がブロードキャストモバイルシステム上で動作し、ブロードキャストDASHサービスが、前記MPDを含むシステム情報メタデータを介して定義され、前記装置が、前記ブロードキャストDASHサービスの代替的な配信が前記ユニキャスト送信を介して利用可能であるかどうかを、前記MPD内の前記パラメータから判定するための手段をさらに備える、上記C15に記載の装置。
[C17]
前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定するための手段と、
前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定するための手段と
をさらに備える、上記C15に記載の装置。
[C18]
装置であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション(MPD)を受信するように構成された無線周波数(RF)送受信機と、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定し、モバイルエンティティの基準に基づいて前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するように構成された、少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに結合された、データを記憶するためのメモリとを備え、
前記RF送受信機が、前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて前記所与の表現についての前記データセグメントを受信する、
装置。
[C19]
コンピュータプログラム製品であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション(MPD)を受信することと、
モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記所与の表現についての前記データセグメントの受信に適しているかを判定することと、
前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信することと
をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
を備える、コンピュータプログラム製品。
[C20]
ワイヤレスシステム内のモバイルエンティティによって動作可能な方法であって、
(a)動的適応ストリーミングオーバーHTTP(DASH)のメディアプレゼンテーションディスクリプション(MPD)と、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することと、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
前記所与の表現のためのデータセグメントを受信することと
を備える、方法。
[C21]
前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定することと、
前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定することと
をさらに備える、上記C20に記載の方法。
[C22]
装置であって、
(a)動的適応ストリーミングオーバーHTTP(DASH)のメディアプレゼンテーションディスクリプション(MPD)と、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信するための手段と、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定するための手段と、
前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するための手段と、
前記所与の表現のためのデータセグメントを受信するための手段と
を備える、装置。
[C23]
装置であって、
(a)動的適応ストリーミングオーバーHTTP(DASH)のメディアプレゼンテーションディスクリプション(MPD)と、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信するように構成された無線周波数(RF)送受信機と、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定し、前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するように構成された少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに結合された、データを記憶するためのメモリとを備え、
前記RF送受信機が、前記所与の表現のためのデータセグメントを受信する、
装置。
[C24]
コンピュータプログラム製品であって、
(a)動的適応ストリーミングオーバーHTTP(DASH)のメディアプレゼンテーションディスクリプション(MPD)と、(b)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することと、
前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
前記所与の表現のためのデータセグメントを受信することと
をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
を備える、コンピュータプログラム製品。
[C25]
ワイヤレス通信のためのネットワークエンティティによって動作可能な方法であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション(MPD)を送信することと、
前記コンテンツの所与の表現についての要求を受信することと、
前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと
を備える、方法。
[C26]
サービスのどの表現が前記ブロードキャスト送信または前記ユニキャスト送信に利用可能であるかをシグナリングすることをさらに備える、上記C25に記載の方法。
[C27]
前記データセグメントを送信することが、前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと、並行して、前記ブロードキャスト送信を介して少なくとも1つの異なる表現のための前記データセグメントを送信することとを含む、上記C25に記載の方法。
[C28]
装置であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション(MPD)を送信するための手段と、
前記コンテンツの所与の表現についての要求を受信するための手段と、
前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信するための手段と
を備える、装置。
[C29]
装置であって、
無線周波数(RF)送受信機と、
(a)ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション(MPD)を送信するように前記RF送受信機に命令し、(b)前記コンテンツの所与の表現についての要求を受信することに応答して、前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信するように前記RF送受信機に命令するように構成された、少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに結合された、データを記憶するためのメモリとを備える、装置。
[C30]
コンピュータプログラム製品であって、
ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション(MPD)を送信することと、
前記コンテンツの所与の表現についての要求を受信することと、
前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと
をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
を備える、コンピュータプログラム製品。