JP2015505226A - ユニキャストとブロードキャストとの間でブロードキャストｄａｓｈサービスの受信を遷移させるための方法およびシステム - Google Patents

Abstract

コンテンツの１つまたは複数の表現をワイヤレスに受信するための技法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介してコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を受信すること（２３１２）を含むことができる。方法は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定すること（２３１４）と、モバイルエンティティの基準に基づいてコンテンツのマルチプルな表現の中から所与の表現を選択すること（２３１６）とを含むことができる。方法は、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現のためのデータセグメントを受信すること（２３１８）を含むことができる。

Description

関連出願の相互参照
本特許出願は、本明細書の譲受人に譲渡され、その内容全体が参照により本明細書に明確に組み込まれている、以下の仮出願の優先権を主張する：「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、２０１２年１月１６日に出願された第６１／５８７，１０３号、「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、２０１２年４月１３日に出願された第６１／６２３，９６５号、「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、２０１２年５月１４日に出願された第６１／６４６，８７３号、および「METHOD AND SYSTEM FOR TRANSITIONS OF BROADCAST DASH SERVICE RECEPTIONS BETWEEN UNICAST AND BROADCAST」と題する、２０１２年１０月２９日に出願された第６１／７１９，９３６号。

本開示の態様は、一般に、ワイヤレス通信システムに関し、より詳細には、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）サービスの管理に関する。

ワイヤレス通信ネットワークは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャストなどの様々な通信サービスを提供するために広く展開されている。これらのワイヤレスネットワークは、利用可能なネットワークリソースを共有することによって、マルチプルなユーザをサポートすることが可能な多元接続ネットワークであり得る。そのような多元接続ネットワークの例には、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（ＯＦＤＭＡ）ネットワーク、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワークが含まれる。

ワイヤレス通信ネットワークは、モバイルエンティティとも呼ばれるいくつかのユーザ機器（ＵＥ）の通信をサポートすることができるいくつかの基地局を含み得る。ＵＥは、ダウンリンクおよびアップリンクを介して基地局と通信することができる。ダウンリンク（または順方向リンク）は基地局からＵＥへの通信リンクを指し、アップリンク（または逆方向リンク）はＵＥから基地局への通信リンクを指す。本明細書で使用される場合、「基地局」は、ワイヤレス通信システムのｅノードＢ（ｅＮＢ）、ノードＢ、ホームノードＢ、または同様のネットワークコンポーネントを意味する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）のロングタームエボリューション（ＬＴＥ）は、モバイル通信用グローバルシステム（ＧＳＭ（登録商標））およびユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）の発展形として、セルラー技術における大きな進歩を代表するものである。ＬＴＥの物理層（ＰＨＹ）は、発展型ノードＢ（ｅＮＢ）などの基地局と、ＵＥなどのモバイルエンティティとの間でデータと制御情報の両方を伝達する高効率な方法を提供する。従来の適用例では、マルチメディア用の高帯域幅通信を容易にするための方法は、単一周波数ネットワーク（ＳＦＮ）動作であった。ＳＦＮは、たとえば、ｅＮＢなどの無線送信機を利用して加入者ＵＥと通信する。ユニキャスト動作では、各ｅＮＢは、１つまたは複数の特定の加入者ＵＥに向けられた情報を搬送する信号を送信するために制御される。ユニキャストシグナリングの特異性により、たとえば、音声通話、テキストメッセージング、またはビデオ通話などの人対人サービスが可能になる。

動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）により、ユニキャスト・トランスポート・プロトコルであるハイパーテキスト転送プロトコル（ＨＴＴＰ）を介して、連続（ストリーミング）メディアコンテンツを配信するサービスが可能になる。ＤＡＳＨコンテンツのユニキャストとブロードキャストの同時配信、ならびに、ユニキャスト配信とブロードキャスト配信との間およびその逆の遷移の処理は、完全には定義されていない。ブロードキャスト配信に関連する待ち時間は、また、そのような遷移にさらなる課題を与える。ブロードキャストアベイラビリティ調整（たとえば、アベイラビリティの先延ばし（delay）または前倒し（advance））に関する情報は、ネットワークの展開に依存し、ユニキャスト配信とブロードキャスト配信との間のシームレスな遷移を実現するために、モバイルエンティティに対して利用可能にされるべきである。ブロードキャストを介したＤＡＳＨセグメントの配信に関係する情報は、ＤＡＳＨクライアントに配信される必要があり得、そのような情報には、コンテンツのユニキャストバージョンの受信に対する地理的制約、コンテンツのどの表現（representation）が所与のエリア内でブロードキャストを介して利用可能であるかに関する情報、同じコンテンツの異なる表現を搬送する適切なブロードキャスト・トランスポート・セッションの発見を可能にする情報、およびオフロードユニキャストＤＡＳＨトラフィックへのオンデマンドＤＡＳＨサービスをサポートする情報が含まれ得る。したがって、ＤＡＳＨのコアユニキャスト機能に影響を及ぼすことなくブロードキャスト配信をサポートするパラメータを伝達するための技法も必要とされる。

図面において示される本発明の例示的な実施形態が、以下で要約される。これらおよび他の実施形態は、詳細な説明のセクションにおいてより十分に記載される。しかしながら、本発明をこの発明の概要または詳細な説明において記載される形態に限定する意図はないことを理解されたい。

ブロードキャストとマルチキャストは本明細書では同義であることに留意されたい。いくつかのブロードキャストネットワークでは、ブロードキャストストリーム化されたコンテンツは、また、ユニキャストを介して利用可能にされ得るまたはアクセスされ得ることに、さらに留意されたい。そのようなコンテンツの代替的な配信は、ブロードキャストカバレージ内にない間にブロードキャストストリーミングサービス用のコンテンツにアクセスするために、ユニキャストフォールバック技法を提供する。１つの問題は、ブロードキャストＤＡＳＨサービスが様々な位置で様々なバージョンのコンテンツ（たとえば、様々な表現）を配信できることである。様々な表現は、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であることもあり得る。

本明細書に記載された実施形態の１つまたは複数の態様によれば、ワイヤレス通信システム内のモバイルエンティティによって動作可能な方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を受信することを含むことができる。方法は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法は、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法は、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現についてのデータセグメントを受信することを含むことができる。関係する態様では、電子デバイス（たとえば、モバイルエンティティまたはそのコンポーネント）は、上述された方法を実行するように構成することができる。

本明細書に記載された実施形態の１つまたは複数の態様によれば、モバイルエンティティによって動作可能な別の方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介して、（ａ）ＤＡＳＨ ＭＰＤと、（ｂ）コンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することを含むことができる。方法は、ブロードキャスト送信のためのパラメータおよびモバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法は、ブロードキャストファイル配信セッションにおいて所与の表現についてのデータセグメントを受信することを含むことができる。関係する態様では、電子デバイス（たとえば、モバイルエンティティまたはそのコンポーネント）は、上述された方法を実行するように構成され得る。

本明細書に記載された実施形態の１つまたは複数の態様によれば、ネットワークエンティティによって動作可能な方法が提供される。方法は、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むＭＰＤを送信することを含むことができる。方法は、コンテンツの所与の表現に関する要求を受信することを含むことができる。方法は、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、ファイル配信セッションにおいて所与の表現についてのデータセグメントを送信することを含むことができる。関係する態様では、電子デバイス（たとえば、ネットワークエンティティまたはそのコンポーネント）は、上述された方法を実行するように構成され得る。

上記および関係の目的を達成するために、１つまたは複数の実施形態は、以下で十分に記載され、特に特許請求の範囲で指摘される特徴を含む。以下の説明および添付の図面は、１つまたは複数の実施形態のいくつかの例示的な態様を詳細に説明する。しかしながら、これらの態様は、様々な実施形態の原理が使用され得る様々な方法のほんのいくつかを示すものであり、記載された実施形態は、すべてのそのような態様およびそれらの等価物を含むものとする。

テレコミュニケーションシステムの一例を概念的に示すブロック図。 テレコミュニケーションシステム内のダウンリンクフレーム構造の一例を概念的に示すブロック図。 本開示の一態様に従って構成された基地局／ｅＮＢおよびＵＥの設計を概念的に示すブロック図。 ユニキャスト信号およびマルチキャスト信号のためのシンボルの割当ての一例を示すシグナリングフレームの図。 ＭＢＭＳオーバー単一周波数ネットワーク（ＭＢＳＦＮ）サービスエリア内のＭＢＳＦＮエリアを示す図。 ＭＢＳＦＮサービスを提供またはサポートするためのワイヤレス通信システムのコンポーネントを示すブロック図。 ＤＡＳＨ ＭＰＤの一実施形態を示す図。 ＤＡＳＨ ＭＰＤ内のＢａｓｅＵＲＬの一実施形態を示す図。 ｅＭＢＭＳ ＵＳＤ内のバンドルディスクリプションの一実施形態を示す図。 ｅＭＢＭＳのためのＵＳＤの一実施形態を示す図。 ｅＭＢＭＳのためのＵＳＤの別の実施形態を示す図。 ｅＭＢＭＳ ＵＳＤ内のｄｅｌｉｖｅｒｙＭｅｔｈｏｄディスクリプションの一実施形態を示す図。 ＭＰＤレベルにある複数のＢａｓｅＵＲＬの一実施形態を示す図。 ＤＡＳＨセグメントアベイラビリティタイムラインの一実施形態を示す図。 保護期間に関する暗黙の考慮事項の一例を示す図。 ＵＣ−ＢＣ遷移についての例示的なタイムラインを示す図。 ユニキャスト取出しセグメントについての様々なプレイバック遅延の例を示す図。 ブロードキャスト取出しセグメントについての様々なプレイバック遅延の例を示す図。 ＢＣ−ＵＣ遷移に関する例示的なタイムラインを示す図。 ブロードキャスト取出しセグメント対ユニキャスト取出しセグメントに基づくセグメントプレイバックを示す図。 単一のサービスのためのマルチプルなブロードキャスト送信を示す図。 単一のサービスのためのマルチプルなブロードキャスト送信のためにＸＭＬ文字列を介してパラメータを伝達することを示す図。 モバイルエンティティによって実行可能な例示的な方法を示す図。 図２２Ａの方法のさらなる態様を示す図。 図２２Ａの方法のさらなる態様を示す図。 図２２Ａの方法のさらなる態様を示す図。 図２２Ａ〜図２２Ｄの方法による装置の一実施形態を示す図。 ワイヤレスシステム内のモバイルエンティティによって実行可能な別の例示的な方法を示す図。 図２４の方法による装置の一実施形態を示す図。 ワイヤレスシステム内のネットワークエンティティによって実行可能な例示的な方法を示す図。 図２６の方法による装置の一実施形態を示す図。

詳細な説明

添付の図面に関して以下に記載される詳細な説明は、様々な構成を説明するものであり、本明細書に記載される概念が実践され得る唯一の構成を表すものではない。詳細な説明は、様々な概念の完全な理解を与えるための具体的な詳細を含む。しかしながら、これらの概念はこれらの具体的な詳細なしに実践され得ることが当業者には明らかであろう。いくつかの例では、そのような概念を不明瞭にしないために、よく知られている構造および構成要素は、ブロック図の形式で示される。

本明細書に記載される技法は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡおよび他のネットワークなどの、様々なワイヤレス通信ネットワークに使用することができる。「ネットワーク」および「システム」という用語は、しばしば互換的に使用される。ＣＤＭＡネットワークは、ユニバーサル地上無線アクセス（ＵＴＲＡ）、ＣＤＭＡ２０００などの無線技術を実装することができる。ＵＴＲＡは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））およびＣＤＭＡの他の変形形態を含む。ＣＤＭＡ２０００は、ＩＳ−２０００規格、ＩＳ−９５規格およびＩＳ−８５６規格をカバーする。ＴＤＭＡネットワークは、モバイル通信用グローバルシステム（ＧＳＭ）などの無線技術を実装することができる。ＯＦＤＭＡネットワークは、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ（登録商標））、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ８０２．２０、フラッシュＯＦＤＭＡなどの無線技術を実装することができる。ＵＴＲＡおよびＥ−ＵＴＲＡは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）の一部である。３ＧＰＰのロングタームエボリューション（ＬＴＥ）およびＬＴＥアドバンスト（ＬＴＥ−Ａ）は、Ｅ−ＵＴＲＡを使用する、新たにリリースされたＵＭＴＳである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥ、ＬＴＥ−Ａ、およびＧＳＭは、「第３世代パートナーシッププロジェクト」（３ＧＰＰ）と称する団体からの文書に記載されている。ＣＤＭＡ２０００およびＵＭＢは、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）という名称の団体からの文書に記載されている。本明細書に記載される技法は、上記のワイヤレスネットワークおよび無線技術、ならびに他のワイヤレスネットワークおよび無線技術に使用することができる。明確にするために、本技法のいくつかの態様は、以下ではＬＴＥに関して記載され、以下の説明の大部分でＬＴＥ用語が使用される。

図１は、ＬＴＥネットワークであり得るワイヤレス通信ネットワーク１００を示す。ワイヤレスネットワーク１００は、いくつかのｅＮＢ１１０と他のネットワークエンティティとを含み得る。ｅＮＢは、ＵＥと通信する局であり得、また、基地局、ノードＢ、アクセスポイント、または他の用語として呼ばれる場合もある。各ｅＮＢ１１０ａ、１１０ｂ、１１０ｃは、特定の地理的エリアに対して通信カバレージを提供することができる。３ＧＰＰでは、「セル」という用語は、この用語が使用される状況に応じて、ｅＮＢのカバレージエリアおよび／またはこのカバレージエリアにサービスしているｅＮＢサブシステムを指すことができる。

ｅＮＢは、マクロセル、ピコセル、フェムトセル、および／または他のタイプのセルに通信カバレージを提供することができる。マクロセルは、比較的大きい地理的エリア（たとえば、半径数キロメートル）をカバーでき、サービスに加入しているＵＥによる制限されないアクセスを可能にすることができる。ピコセルは、比較的小さい地理的エリアをカバーでき、サービスに加入しているＵＥによる制限されないアクセスを可能にすることができる。フェムトセルは、比較的小さい地理的エリア（たとえば、家庭）をカバーでき、フェムトセルとの関連を有するＵＥ（たとえば、限定加入者グループ（ＣＳＧ）内のＵＥ、家庭内のユーザのためのＵＥなど）による制限されたアクセスを可能にすることができる。マクロセルのためのｅＮＢは、マクロｅＮＢと呼ばれる場合がある。ピコセルのためのｅＮＢは、ピコｅＮＢと呼ばれる場合がある。フェムトセルのためのｅＮＢは、フェムトｅＮＢまたはホームｅＮＢ（ＨＮＢ）と呼ばれる場合がある。図１に示された例では、ｅＮＢ１１０ａ、１１０ｂ、および１１０ｃは、それぞれマクロセル１０２ａ、１０２ｂ、および１０２ｃのためのマクロｅＮＢであり得る。ｅＮＢ１１０ｘは、ＵＥ１２０ｘにサービスするピコセル１０２ｘのためのピコｅＮＢであり得る。ｅＮＢ１１０ｙおよび１１０ｚは、それぞれフェムトセル１０２ｙおよび１０２ｚのためのフェムトｅＮＢであり得る。ｅＮＢは、１つまたはマルチプルな（たとえば、３つの）セルをサポートすることができる。

ワイヤレスネットワーク１００はまた、中継局１１０ｒを含み得る。中継局は、上流局（たとえば、ｅＮＢまたはＵＥ）からデータおよび／または他の情報の送信を受信し、そのデータおよび／または他の情報の伝送を下流局（たとえば、ＵＥまたはｅＮＢ）に送る局である。中継局はまた、他のＵＥのための伝送を中継するＵＥであり得る。図１に示された例では、中継局１１０ｒは、ｅＮＢ１１０ａとＵＥ１２０ｒとの間の通信を容易にするために、ｅＮＢ１１０ａおよびＵＥ１２０ｒと通信することができる。中継局は、リレーｅＮＢ、リレーなどと呼ばれる場合もある。

ワイヤレスネットワーク１００は、様々なタイプのｅＮＢ、たとえば、マクロｅＮＢ、ピコｅＮＢ、フェムトｅＮＢ、リレーなどを含む異種ネットワークであり得る。これらの異なるタイプのｅＮＢは、異なる送信電力レベル、異なるカバレージエリア、およびワイヤレスネットワーク１００内の干渉に対する異なる影響を有する場合がある。たとえば、マクロｅＮＢは、高い送信電力レベル（たとえば、２０ワット）を有する場合があるが、ピコｅＮＢ、フェムトｅＮＢ、およびリレーは、より低い送信電力レベル（たとえば、１ワット）を有する場合がある。

ワイヤレスネットワーク１００は、同期動作または非同期動作をサポートすることができる。同期動作の場合、ｅＮＢは同様のフレームタイミングを有することができ、異なるｅＮＢからの送信はほぼ時間的にアラインされ得る。非同期動作の場合、ｅＮＢは異なるフレームタイミングを有することができ、異なるｅＮＢからの送信は時間的にアラインされない場合がある。本明細書に記載された技法は、同期動作と非同期動作の両方に使用することができる。

ネットワークコントローラ１３０は、ｅＮＢのセットに結合し、これらのｅＮＢに協調および制御を提供することができる。ネットワークコントローラ１３０は、バックホールを介してｅＮＢ１１０と通信することができる。ｅＮＢ１１０はまた、たとえば、ワイヤレスバックホールまたは有線バックホールを介して、直接的にまたは間接的に互いに通信することができる。

ＵＥ１２０は、ワイヤレスネットワーク１００全体にわたって分散されることができ、各ＵＥは、固定式またはモバイルであり得る。ＵＥは、また、端末、移動局、加入者ユニット、ステーションなどと呼ばれる場合もある。ＵＥは、携帯電話、携帯情報端末（ＰＤＡ）、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレスフォン、ワイヤレスローカルループ（ＷＬＬ）局、または他のモバイルエンティティであり得る。ＵＥは、マクロｅＮＢ、ピコｅＮＢ、フェムトｅＮＢ、リレー、または他のネットワークエンティティと通信することが可能であり得る。図１では、両矢印付きの実線は、ダウンリンクおよび／またはアップリンク上での、ＵＥと、そのＵＥをサービスするように指定されたｅＮＢであるサービングｅＮＢとの間の所望の送信を示す。両矢印付きの破線は、ＵＥとｅＮＢとの間の干渉する送信を示す。

ＬＴＥは、ダウンリンク上では直交周波数分割多重化（ＯＦＤＭ）を利用し、アップリンク上ではシングルキャリア周波数分割多重化（ＳＣ−ＦＤＭ）を利用する。ＯＦＤＭおよびＳＣ−ＦＤＭは、システム帯域幅を、通常はトーン、ビンなどとも呼ばれるマルチプルな（Ｋ個の）直交サブキャリアに分割する。各サブキャリアはデータで変調されることができる。一般に、変調シンボルは、ＯＦＤＭでは周波数領域で、ＳＣ−ＦＤＭでは時間領域で送られる。隣接するサブキャリア間の間隔は固定であり得、サブキャリアの総数（Ｋ）はシステム帯域幅に依存し得る。たとえば、Ｋは、１．２５、２．５、５、１０または２０メガヘルツ（ＭＨｚ）のシステム帯域幅について、それぞれ１２８、２５６、５１２、１０２４または２０４８に等しくなり得る。システム帯域幅はまた、サブバンドに分割され得る。たとえば、サブバンドは１．０８ＭＨｚをカバーでき、１．２５、２．５、５、１０、または２０ＭＨｚのシステム帯域幅について、それぞれ１個、２個、４個、８個、または１６個のサブバンドがあり得る。

図２は、ＬＴＥにおいて使用されるダウンリンクのフレーム構造を示す。ダウンリンクの送信タイムラインは、無線フレームの単位に分割することができる。各無線フレームは、所定の継続時間（duration）（たとえば、１０ミリ秒（ｍｓ））を有することができ、０〜９のインデックスをもつ１０個のサブフレームに分割することができる。各サブフレームは２つのスロットを含むことができる。したがって、各無線フレームは、０〜１９のインデックスをもつ２０個のスロットを含むことができる。各スロットは、Ｌ個のシンボル期間、たとえば、図２に示されたようにノーマルサイクリックプレフィックス（ＣＰ）の場合は７個のシンボル期間、または拡張サイクリックプレフィックスの場合は６個のシンボル期間を含むことができる。ノーマルＣＰおよび拡張ＣＰは、異なるＣＰのタイプと本明細書では呼ばれる場合がある。各サブフレーム内の２Ｌ個のシンボル期間は、０〜２Ｌ−１個のインデックスを割り当てることができる。利用可能な時間周波数リソースは、リソースブロックに分割することができる。各リソースブロックは、１つのスロット内でＮ個のサブキャリア（たとえば、１２個のサブキャリア）をカバーすることができる。

ＬＴＥでは、ｅＮＢは、ｅＮＢ内のセルごとに１次同期信号（ＰＳＳ）と２次同期信号（ＳＳＳ）とを送ることができる。１次同期信号および２次同期信号は、図２に示されたように、それぞれ、ノーマルサイクリックプレフィックスをもつ各無線フレームのサブフレーム０および５の各々の中のシンボル期間６および５の中で送ることができる。同期信号は、セルの検出および捕捉のためにＵＥによって使用されることができる。ｅＮＢは、サブフレーム０のスロット１内のシンボル期間０〜３の中で物理ブロードキャストチャネル（ＰＢＣＨ）を送ることができる。ＰＢＣＨはあるシステム情報を搬送することができる。

ｅＮＢは、図２の第１のシンボル期間全体の中に示されているが、各サブフレームの第１のシンボル期間の一部のみの中で、物理制御フォーマットインジケータチャネル（ＰＣＦＩＣＨ）を送ることができる。ＰＣＦＩＣＨは、制御チャネルに使用されるいくつか（Ｍ個）のシンボル期間を搬送することができ、ここで、Ｍは、１、２または３に等しくなり得るし、サブフレームごとに変化する場合がある。Ｍはまた、たとえば、リソースブロックが１０個未満である、小さいシステム帯域幅では４に等しくなり得る。図２に示された例では、Ｍ＝３である。ｅＮＢは、各サブフレームの最初のＭ個のシンボル期間の中で（図２ではＭ＝３）、物理ＨＡＲＱインジケータチャネル（ＰＨＩＣＨ）と物理ダウンリンク制御チャネル（ＰＤＣＣＨ）とを送ることができる。ＰＨＩＣＨは、ハイブリッド自動再送（ＨＡＲＱ）をサポートする情報を搬送することができる。ＰＤＣＣＨは、ＵＥのためのリソースの割当てに関する情報と、ダウンリンクチャネル用の制御情報とを搬送することができる。図２の第１のシンボル期間の中には示されていないが、ＰＤＣＣＨおよびＰＨＩＣＨは、第１のシンボル期間の中にも含まれることを理解されたい。同様に、ＰＨＩＣＨおよびＰＤＣＣＨはまた、第２のシンボル期間と第３のシンボル期間の両方の中にあるが、図２ではそのように示されていない。ｅＮＢは、各サブフレームの残りのシンボル期間中に、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を送ることができる。ＰＤＳＣＨは、ダウンリンク上でのデータ送信のためにスケジュールされたＵＥ用のデータを搬送することができる。ＬＴＥにおける様々な信号およびチャネルは、公開されている「Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ（Ｅ−ＵＴＲＡ）；Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌｓ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ」と題する、３ＧＰＰのＴＳ３６．２１１に記載されている。

ｅＮＢは、ｅＮＢによって使用されるシステム帯域幅の中心１．０８ＭＨｚにおいてＰＳＳと、ＳＳＳと、ＰＢＣＨとを送ることができる。ｅＮＢは、これらのチャネルが送られる各シンボル期間内のシステム帯域幅全体にわたってＰＣＦＩＣＨとＰＨＩＣＨとを送ることができる。ｅＮＢは、システム帯域幅のいくつかの部分においてＵＥのグループにＰＤＣＣＨを送ることができる。ｅＮＢは、システム帯域幅の特定の部分において特定のＵＥにＰＤＳＣＨを送ることができる。ｅＮＢは、すべてのＵＥにブロードキャスト方式でＰＳＳと、ＳＳＳと、ＰＢＣＨと、ＰＣＦＩＣＨと、ＰＨＩＣＨとを送ることができ、特定のＵＥにユニキャスト方式でＰＤＣＣＨを送ることができ、また、特定のＵＥにユニキャスト方式でＰＤＳＣＨを送ることができる。

各シンボル期間において、いくつかのリソース要素が利用可能であり得る。各リソース要素は、１つのシンボル期間内で１つのサブキャリアをカバーすることができ、実数値または複素数値であり得る１つの変調シンボルを送るために使用されることができる。各シンボル期間内で基準信号に使用されないリソース要素は、リソース要素グループ（ＲＥＧ）内に配置することができる。各ＲＥＧは、１つのシンボル期間内に４つのリソース要素を含むことができる。ＰＣＦＩＣＨは、シンボル期間０において、周波数上でほぼ等しく離間され得る、４つのＲＥＧを占有することができる。ＰＨＩＣＨは、１つまたは複数の構成可能なシンボル期間において、周波数上で拡散され得る、３つのＲＥＧを占有することができる。たとえば、ＰＨＩＣＨ用の３つのＲＥＧは、すべてシンボル期間０に属する場合があるか、またはシンボル期間０、１および２で拡散される場合がある。ＰＤＣＣＨは、最初のＭ個のシンボル期間において、利用可能なＲＥＧから選択され得る、９、１８、３２または６４個のＲＥＧを占有することができる。ＲＥＧのいくつかの組合せのみを、ＰＤＣＣＨに対して許可することができる。

ＵＥは、ＰＨＩＣＨおよびＰＣＦＩＣＨに使用される特定のＲＥＧを知ることができる。ＵＥは、ＰＤＣＣＨ用のＲＥＧの様々な組合せを探索することができる。探索する組合せの数は、通常、ＰＤＣＣＨに対して許可された組合せの数よりも少ない。ｅＮＢは、ＵＥが探索することになる組合せのいずれかにおいて、ＵＥにＰＤＣＣＨを送ることができる。

ＵＥは、マルチプルなｅＮＢのカバレージ内にあり得る。これらのｅＮＢのうちの１つを、ＵＥをサービスするために選択することができる。サービングｅＮＢは、受信電力、経路損失、信号対雑音比（ＳＮＲ）などの様々な基準に基づいて、選択することができる。

図３は、図１の基地局／ｅＮＢの１つおよびＵＥの１つであり得る、基地局／ｅＮＢ１１０およびＵＥ１２０の設計のブロック図を示す。制限付き関連付けシナリオの場合、基地局１１０は図１のマクロｅＮＢ１１０ｃであり得るし、ＵＥ１２０はＵＥ１２０ｙであり得る。基地局１１０はまた、何らかの他のタイプの基地局であり得る。基地局１１０はアンテナ３３４ａ〜３３４ｔを備える場合があり、ＵＥ１２０はアンテナ３５２ａ〜３５２ｒを備える場合がある。

基地局１１０において、送信プロセッサ３２０は、データソース３１２からデータを受信し、コントローラ／プロセッサ３４０から制御情報を受信することができる。制御情報は、ＰＢＣＨ、ＰＣＦＩＣＨ、ＰＨＩＣＨ、ＰＤＣＣＨなどのためであり得る。データは、ＰＤＳＣＨなどのためであり得る。プロセッサ３２０は、データと制御情報とを処理（たとえば、符号化およびシンボルマッピング）して、それぞれデータシンボルと制御シンボルとを取得することができる。プロセッサ３２０はまた、たとえば、ＰＳＳ、ＳＳＳ、およびセル固有基準信号のための基準シンボルを生成することができる。送信（ＴＸ）多入力多出力（ＭＩＭＯ）プロセッサ３３０は、適用可能な場合、データシンボル、制御シンボル、および／または基準シンボルに対して空間処理（たとえば、プリコーディング）を実行することができ、出力シンボルストリームを変調器（ＭＯＤ）３３２ａ〜３３２ｔに提供することができる。各変調器３３２は、（たとえば、ＯＦＤＭなどのために）それぞれの出力シンボルストリームを処理して、出力サンプルストリームを取得することができる。各変調器３３２はさらに、出力サンプルストリームを処理（たとえば、アナログへの変換、増幅、フィルタ処理、およびアップコンバート）して、ダウンリンク信号を取得することができる。変調器３３２ａ〜３３２ｔからのダウンリンク信号は、それぞれアンテナ３３４ａ〜３３４ｔを介して送信することができる。

ＵＥ１２０において、アンテナ３５２ａ〜３５２ｒは、基地局１１０からダウンリンク信号を受信することができ、受信された信号をそれぞれ復調器（ＤＥＭＯＤ）３５４ａ〜３５４ｒに提供することができる。各復調器３５４は、それぞれの受信された信号を調整（たとえば、フィルタ処理、増幅、ダウンコンバート、およびデジタル化）して、入力サンプルを取得することができる。各復調器３５４は、（たとえば、ＯＦＤＭなどのために）入力サンプルをさらに処理して、受信シンボルを取得することができる。ＭＩＭＯ検出器３５６は、すべての復調器３５４ａ〜３５４ｒから受信シンボルを取得し、適用可能な場合は受信シンボルに対してＭＩＭＯ検出を実行し、検出シンボルを提供することができる。受信プロセッサ３５８は、検出シンボルを処理（たとえば、復調、デインターリーブ、および復号）し、ＵＥ１２０の復号されたデータをデータシンク３６０に提供し、復号された制御情報をコントローラ／プロセッサ３８０に提供することができる。

アップリンク上では、ＵＥ１２０において、送信プロセッサ３６４は、データソース３６２から（たとえば、ＰＵＳＣＨのための）データを受信し処理することができ、コントローラ／プロセッサ３８０から（たとえば、ＰＵＣＣＨのための）制御情報を受信し処理することができる。プロセッサ３６４はまた、基準信号用の基準シンボルを生成することができる。送信プロセッサ３６４からのシンボルは、適用可能な場合はＴＸ ＭＩＭＯプロセッサ３６６によってプリコードされ、さらに（たとえば、ＳＣ−ＦＤＭなどのために）変調器３５４ａ〜３５４ｒによって処理され、基地局１１０に送信することができる。基地局１１０において、ＵＥ１２０からのアップリンク信号は、アンテナ３３４によって受信され、復調器３３２によって処理され、適用可能な場合はＭＩＭＯ検出器３３６によって検出され、さらに受信プロセッサ３３８によって処理されて、ＵＥ１２０によって送られる復号されたデータと制御情報とを取得することができる。プロセッサ３３８は、復号されたデータをデータシンク３３９に提供し、復号された制御情報をコントローラ／プロセッサ３４０に提供することができる。

コントローラ／プロセッサ３４０および３８０は、それぞれ基地局１１０およびＵＥ１２０での動作を指示することができる。基地局１１０にあるプロセッサ３４０ならびに／または他のプロセッサおよびモジュールは、本明細書に記載された技法のための様々なプロセスを実行するか、またはその実行を指示することができる（図２６参照）。ＵＥ１２０にあるプロセッサ３８０ならびに／または他のプロセッサおよびモジュールは、本明細書に記載された技法のための様々なプロセスを実行するか、またはその実行を指示することができる（図２２Ａ〜図２２Ｄおよび図２４参照）。メモリ３４２および３８２は、それぞれ、基地局１１０およびＵＥ１２０のためのデータとプログラムコードとを記憶することができる。スケジューラ３４４は、ダウンリンク上および／またはアップリンク上でのデータ送信のためにＵＥをスケジューリングすることができる。

単一周波数ネットワークにおけるｅＭＢＭＳおよびユニキャストシグナリング： マルチメディア用の高帯域幅通信を容易にする１つの技法は、単一周波数ネットワーク（ＳＦＮ）動作であった。具体的には、（たとえば、ＬＴＥのコンテキストではマルチメディアブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）として最近知られるようになってきたものを含む）発展型ＭＢＭＳ（ｅＭＢＭＳ）としても知られる、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）およびＬＴＥ用のＭＢＭＳは、そのようなＳＦＮ動作を利用することができる。ＳＦＮは、たとえば、ｅＮＢなどの無線送信機を利用して、加入者ＵＥと通信する。ｅＮＢのグループは、情報を同期方式で送信できるので、信号は互いに干渉するのではなく、互いに補強し合う。ｅＭＢＭＳのコンテキストでは、共有コンテンツは、ＬＴＥネットワークのマルチプルなｅＮＢからマルチプルなＵＥに送信される。したがって、所与のｅＭＢＭＳエリア内で、ＵＥは、ｅＭＢＭＳサービスエリアおよびＭＢＳＦＮエリアの一部としての無線範囲内の任意のｅＮＢから、ｅＭＢＭＳ信号を受信することができる。しかしながら、ｅＭＢＭＳ信号を復号するために、各ＵＥは、非ｅＭＢＭＳチャネルを介して、サービングｅＮＢからマルチキャスト制御チャネル（ＭＣＣＨ）情報を受信する。ＭＣＣＨ情報は時間とともに変化し、変化の通知が別の非ｅＭＢＭＳチャネル、ＰＤＣＣＨを通じて提供される。したがって、特定のｅＭＢＭＳエリア内のｅＭＢＭＳ信号を復号するために、各ＵＥは、エリア内のｅＮＢの１つによってＭＣＣＨおよびＰＤＣＣＨ信号を供給される。

本開示の主題の態様によれば、ｅＭＢＭＳ用のシングルキャリア最適化に関連する機能を有するワイヤレスネットワーク（たとえば、３ＧＰＰネットワーク）が提供される。ｅＭＢＭＳは、たとえばＵＥなどのマルチプルなモバイルエンティティに、ＬＴＥネットワークから共有コンテンツを送信する効率的な方法を提供する。

ＬＴＥ周波数分割複信（ＦＤＤ）用のｅＭＢＭＳの物理層（ＰＨＹ）に関して、チャネル構造は、混合されたキャリア上でｅＭＢＭＳ送信とユニキャスト送信とを分割する、時分割多重化（ＴＤＭ）リソースを備える場合があり、これにより、柔軟で動的なスペクトルの利用が可能になる。現在、マルチメディアブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）サブフレームとして知られる、サブフレームのサブセット（最大６０％）を、ｅＭＢＭＳ送信のために確保することができる。したがって、現在のｅＭＢＭＳ設計は、１０個のサブフレームのうち最大で６個をｅＭＢＭＳ用に許容する。

ｅＭＢＭＳ用のサブフレームの割当ての例が図４に示され、図４は、シングルキャリアの場合の、ＭＢＳＦＮサブフレームへのＭＢＳＦＮ基準信号の既存の割当てを示す。図４に描写されたコンポーネントは、図２に示されたコンポーネントに対応し、図４は、各々のスロットおよびリソースブロック（ＲＢ）内の個別のサブキャリアを示す。３ＧＰＰのＬＴＥでは、ＲＢは、０．５ｍｓのスロット期間にわたる１２個のサブキャリアに及び、各サブキャリアは１５ｋＨｚの帯域幅を有し、合わせてＲＢ当たり１８０ｋＨｚに及ぶ。サブフレームは、たとえば、０、１、２、３、４、５、６、７、８、および９と標示されたサブフレームのシーケンス中で、ユニキャストまたはｅＭＢＭＳのために割り当てられる場合があり、サブフレーム０、４、５、および９は、ＦＤＤではｅＭＢＭＳから除外される場合がある。また、サブフレーム０、１、５、および６は、時分割複信（ＴＤＤ）ではｅＭＢＭＳから除外される場合がある。より具体的には、サブフレーム０、４、５、および９は、ＰＳＳ／ＳＳＳ／ＰＢＣＨ／ページング／システム情報ブロック（ＳＩＢ）およびユニキャストサービスに使用することができる。列の中の残りのサブフレーム、たとえばサブフレーム１、２、３、６、７、および８は、ｅＭＢＭＳサブフレームとして構成することができる。

図４への参照を続けると、各ｅＭＢＭＳサブフレーム内で、最初の１個または２個のシンボルが、ユニキャスト基準シンボル（ＲＳ）および制御シグナリングに使用されうる。最初の１個または２個のシンボルのＣＰの長さは、サブフレーム０のＣＰの長さに従う場合がある。ＣＰの長さが異なる場合、最初の１個または２個のシンボルとｅＭＢＭＳシンボルとの間に、送信ギャップが発生する場合がある。関係する態様では、ｅＭＢＭＳ帯域幅全体の利用率は、ＲＳオーバーヘッド（たとえば、各ｅＭＢＭＳサブフレーム内に６個のｅＭＢＭＳサブフレームと２個の制御シンボルと）を考慮すると、４２．５％であり得る。ＭＢＳＦＮ ＲＳとユニキャストＲＳとを提供するための既知の技法は、通常、（図４に示されたように）ＭＢＳＦＮサブフレームにＭＢＳＦＮ ＲＳを割り当て、非ＭＢＳＦＮサブフレームにユニキャストＲＳを別個に割り当てることを伴う。より具体的には、図４が示すように、ＭＢＳＦＮサブフレームの拡張ＣＰは、ＭＢＳＦＮ ＲＳを含むが、ユニキャストＲＳを含まない。本技術は、限定ではなく例として提示された図２および図４によって示された特定のフレーム割当て方式に限定されない。本明細書で使用するマルチキャストセッションまたはマルチキャストブロードキャストは、任意の適切なフレーム割当て方式を使用することができる。

ｅＭＢＭＳサービスエリア： 図５は、それら自体がマルチプルなセルまたは基地局５１０を含む、マルチプルなＭＢＳＦＮエリア５０４と、５０６と、５０８とを包含する、ＭＢＭＳサービスエリア５０２を含むシステム５００を示す。本明細書で使用する「ＭＢＭＳサービスエリア」は、ある特定のＭＢＭＳサービスが利用可能であるワイヤレス送信セルのグループを指す。たとえば、ある特定のスポーツプログラムまたは他のプログラムが、ある特定の時間にＭＢＭＳサービスエリア内の基地局によってブロードキャストされる場合がある。特定のプログラムがブロードキャストされるエリアは、ＭＢＭＳサービスエリアを定義する。ＭＢＭＳサービスエリアは、５０４、５０６および５０８で示された１つまたは複数の「ＭＢＳＦＮエリア」で構成され得る。本明細書で使用するＭＢＳＦＮエリアは、ＭＢＳＦＮプロトコルを使用して同期方式で特定のプログラムを現在ブロードキャストしているセル（たとえば、セル５１０）のグループを指す。「ＭＢＳＦＮ同期エリア」は、現在そうしているかどうかにかかわらず、同期方式で動作して、ＭＢＳＦＮプロトコルを使用してある特定のプログラムをブロードキャストすることが可能なように相互接続され構成された、セルのグループを指す。各ｅＮＢは、所与の周波数層上の、１つのＭＢＳＦＮ同期エリアのみに属することができる。ＭＢＭＳサービスエリア５０２が１つまたは複数のＭＢＳＦＮ同期エリア（図示せず）を含むことができることは、注意に値する。逆に、ＭＢＳＦＮ同期エリアは、１つまたは複数のＭＢＳＦＮエリアまたはＭＢＭＳサービスエリアを含むことができる。一般に、ＭＢＳＦＮエリアは、単一のＭＢＳＦＮ同期エリアのすべてまたは一部で構成され、単一のＭＢＭＳサービスエリア内に位置する。様々なＭＢＳＦＮエリア間の重複がサポートされ、単一のｅＮＢはいくつかの異なるＭＢＳＦＮエリアに属することができる。たとえば、異なるＭＢＳＦＮエリア内のメンバーシップをサポートするために、最大で８個の独立のＭＣＣＨがＳＩＢ−１３において構成され得る。ＭＢＳＦＮエリア予約セルまたは基地局は、ＭＢＳＦＮ送信に寄与しないＭＢＳＦＮエリア内のセル／基地局、たとえば、ＭＢＳＦＮ同期エリアの境界に近いセル、または、その位置ゆえにＭＢＳＦＮ送信に必要とされないセルである。

ｅＭＢＭＳシステムのコンポーネントおよび機能： 図６は、ＭＢＳＦＮサービスを提供またはサポートするワイヤレス通信システム６００の機能エンティティを示す。サービス品質（ＱｏＳ）に関して、システム６００は、保証ビットレート（ＧＢＲ）タイプのＭＢＭＳベアラを使用し、最大ビットレート（ＭＢＲ）はＧＢＲに等しい。これらのコンポーネントは、例として図示および記載され、本明細書に記載された本発明の概念を限定せず、この本発明の概念は、マルチキャスト送信を配信し制御するための他のアーキテクチャおよび機能的分布に採用され得る。

システム６００は、ＭＢＭＳゲートウェイ（ＭＢＭＳ ＧＷ）６１６を含む場合がある。ＭＢＭＳ ＧＷ６１６は、Ｍ１インターフェースを介した、ｅＮｏｄｅＢ６０４へのＭＢＭＳユーザプレーンデータのインターネットプロトコル（ＩＰ）マルチキャスト分配を制御し、多くの可能なｅＮＢのうちの１つのｅＮＢ６０４が示されている。さらに、ＭＢＭＳ ＧＷは、Ｍ１インターフェースを介してＵＴＲＡＮ無線ネットワークコントローラ（ＲＮＣ）６２０へのＭＢＭＳユーザプレーンデータのＩＰマルチキャスト分配を制御し、多くの可能なＲＮＣのうちの１つのＵＴＲＡＮ ＲＮＣ６２０が示されている。Ｍ１インターフェースは、ＭＢＭＳデータ（ユーザプレーン）と関連付けられ、データパケットの配信用にＩＰを使用する。ｅＮＢ６０４は、Ｅ−ＵＴＲＡＮ Ｕｕインターフェースを介して、ユーザ機器（ＵＥ）／モバイルエンティティ６０２にＭＢＭＳコンテンツを提供することができる。ＲＮＣ６２０は、Ｕｕインターフェースを介してＵＥモバイルエンティティ６２２にＭＢＭＳコンテンツを提供することができる。ＭＢＭＳ ＧＷ６１６はさらに、モビリティ管理エンティティ（ＭＭＥ）６０８およびＳｍインターフェースを介して、ＭＢＭＳセッション制御シグナリング、たとえば、ＭＢＭＳセッション開始とセッション停止とを実行することができる。ＭＢＭＳ ＧＷ６１６はさらに、ＳＧ−ｍｂ（ユーザプレーン）基準点を通じてＭＢＭＳベアラを使用してエンティティにインターフェースを提供し、ＳＧｉ−ｍｂ（制御プレーン）基準点を通じてＭＢＭＳベアラを使用してエンティティにインターフェースを提供することができる。ＳＧ−ｍｂインターフェースは、ＭＢＭＳベアラサービス固有のシグナリングを搬送する。ＳＧｉ−ｍｂインターフェースは、ＭＢＭＳデータ配信用のユーザプレーンインターフェースである。ＭＢＭＳデータ配信は、デフォルトモードであり得るＩＰユニキャスト送信によって、またはＩＰマルチキャスティングによって、実行され得る。ＭＢＭＳ ＧＷ６１６は、サービング汎用パケット無線サービスサポートノード（ＳＧＳＮ）６１８およびＳｎ／Ｉｕインターフェースを介して、ＵＴＲＡＮを通じてＭＢＭＳに制御プレーン機能を提供することができる。

システム６００はさらに、マルチキャスト協調エンティティ（ＭＣＥ）６０６を含み得る。ＭＣＥ６０６は、ＭＢＭＳコンテンツ用のアドミッション制御機能を実行し、ＭＢＳＦＮ動作を使用してマルチセルＭＢＭＳ送信のためにＭＢＳＦＮエリア内のすべてのｅＮＢによって使用される時間および周波数の無線リソースを割り当てることができる。ＭＣＥ６０６は、たとえば、変調およびコーディング方式など、ＭＢＳＦＮエリアについての無線構成を決定することができる。ＭＣＥ６０６は、ＭＢＭＳコンテンツのユーザプレーン送信をスケジューリングおよび制御し、どのサービスがどのマルチキャストチャネル（ＭＣＨ）内で多重化されるべきかを決定することによって、ｅＭＢＭＳサービスの多重化を管理することができる。ＭＣＥ６０６は、Ｍ３インターフェースを通じてＭＭＥ６０８とのＭＢＭＳセッション制御シグナリングに参加することができ、ｅＮＢ６０４に制御プレーンインターフェースＭ２を提供することができる。

システム６００はさらに、コンテンツプロバイダサーバ６１４と通信している、ブロードキャストマルチキャストサービスセンタ（ＢＭ−ＳＣ）６１２を含み得る。ＢＭ−ＳＣ６１６は、コンテンツプロバイダ６１４などの１つまたは複数のソースからのマルチキャストコンテンツの取込みをハンドリングし、以下で記載されるような他のより高レベルの管理機能を提供することができる。これらの機能は、たとえば、識別されたＵＥのためのＭＢＭＳサービスの認証および開始を含むメンバーシップ機能を含むことができる。ＢＭ−ＳＣ６１６はさらに、ＭＢＭＳセッションおよび送信機能、ライブブロードキャストのスケジューリング、ならびにＭＢＭＳおよび関連する配信機能を含む配信を実行することができる。ＢＭ−ＳＣ６１２はさらに、マルチキャストに利用可能なコンテンツをアドバタイズすることなどの、サービスのアドバタイズメント（advertisement）と説明とを提供することができる。別個のパケットデータプロトコル（ＰＤＰ）のコンテキストは、ＵＥとＢＭ−ＳＣとの間で制御メッセージを搬送するために使用され得る。ＢＭ−ＳＣはさらに、キー管理などのセキュリティ機能を提供し、データボリュームおよびＱｏＳなどのパラメータに従ってコンテンツプロバイダの課金を管理し、ＵＴＲＡＮにおいて、およびブロードキャストモードの場合Ｅ−ＵＴＲＡＮにおいて、ＭＢＭＳについてのコンテンツ同期を提供し、ＵＴＲＡＮにおいてＭＢＳＦＮデータについてのヘッダ圧縮を提供することができる。ＢＭ−ＳＣ６１２は、ＱｏＳおよびＭＢＭＳサービスエリアなどのセッション属性（session attributes）を含め、セッションの開始、更新、および停止をＭＢＭＳ−ＧＷ６１６に示すことができる。

システム６００はさらに、ＭＣＥ６０６およびＭＢＭＳ−ＧＷ６１６と通信しているマルチキャスト管理エンティティ（ＭＭＥ）６０８を含み得る。ＭＭＥ６０８は、Ｅ−ＵＴＲＡＮを介してＭＢＭＳについての制御プレーン機能を提供することができる。加えて、ＭＭＥは、ＭＢＭＳ−ＧＷ６１６によって定義されるマルチキャスト関連情報を、ｅＮＢ６０４、６２０に提供することができる。ＭＭＥ６０８とＭＢＭＳ−ＧＷ６１６との間のＳｍインターフェースは、ＭＢＭＳ制御シグナリング、たとえば、セッション開始信号とセッション停止信号とを搬送するために使用され得る。

システム６００はさらに、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＧＷ）６１０（時にＰ−ＧＷと略される）を含み得る。Ｐ−ＧＷ６１０は、シグナリングおよび／またはユーザデータのために、ＵＥ６０２とＢＭ−ＳＣ６１２との間に発展型パケットシステム（ＥＰＳ）ベアラを提供することができる。したがって、Ｐ−ＧＷは、ＵＥに割り当てられたＩＰアドレスと関連するＵＥから発信された、ユニフォームリソースロケータ（ＵＲＬ）ベースの要求を受信することができる。ＢＭ−ＳＣ６１２はまた、Ｐ−ＧＷ６１０を介して１つまたは複数のコンテンツプロバイダにリンクされ得、Ｐ−ＧＷ６１０は、ＩＰインターフェースを介してＢＭ−ＳＣ６１２と通信し得る。

本明細書に記載された実施形態の１つまたは複数の態様によれば、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）コンテンツについてのメディアプレゼンテーションディスクリプション（ＭＰＤ）内のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性（attribute）を介して、そのコンテンツのオンデマンドブロードキャストバージョンへのユニキャスト動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）アクセスを指示することをサポートする、いくつかのＵＲＬの使用をシグナリングするための技法が提供される。ＤＡＳＨにより、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介して連続（ストリーミング）メディアコンテンツを配信するサービスが可能になる。ＤＡＳＨについての仕様は、主に２つのフォーマット、すなわち、ＭＰＤおよびセグメントのフォーマットを定義する。

図７は、ＭＰＤ用の高レベルの拡張可能マークアップ言語（ＸＭＬ）スキーマ構造の実施形態７００を示す。図８は、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎおよびｂｙｔｅＲａｎｇｅ属性をベースＵＲＬに関連付けるＢａｓｅＵＲＬについての構造を示すためのスキーマ８００を描く。ＢａｓｅＵＲＬ要素のリストは、ＭＰＤで、ＭＰＤのＰｅｒｉｏｄレベルで、Ａｄａｐｔａｔｉｏｎ Ｓｅｔレベルで、およびＲｅｐｒｅｓｅｎｔａｉｏｎレベルで記述され得る。

関係する態様では、ＢａｓｅＵＲＬは、Ｂａｓｅユニフォームリソース識別子（ＵＲＬ）の機能を果たすことができる。ＭＰＤの各レベルでのＵＲＬは、ドキュメント（たとえば、ＭＰＤ）のそのレベルで、または上のレベルで指定されたＢａｓｅＵＲＬ要素に関するＲＦＣ３９８６に従って解決（resolved）され得る。ＵＲＬ解決（URL resolution）は、ＭＰＤドキュメント内で見出されるすべてのＵＲＬ、特に、本明細書に記載された開示にとって関心事である初期化およびメディアセグメント用のＵＲＬに適用される。マルチプルなＢａｓｅＵＲＬ要素は、同一のセグメントがアクセスされることのできる１つまたは複数の共通ロケーションを指定するために提供され得る。他の基準がない場合、ＤＡＳＨクライアントは、ベースＵＲＩとして第１のＢａｓｅＵＲＬ要素を使用し得る。

図８を参照すると、ＢａｓｅＵＲＬ要素についてのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、同じｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ値を有するＢａｓｅＵＲＬ要素が、たとえば、共通コンテンツ配信ネットワークなどの共通ネットワークロケーションでのサービスに対するそれらのＵＲＬ解決を有する可能性があるようなＢａｓｅＵＲＬ間の関係を指定する。たとえば、ＤＡＳＨクライアントが表現についてのセグメント（たとえば、解像度、言語などの所与のコンテンツの様々なバージョン）を取り出すが、（アクセスワイヤレスネットワークが帯域幅上の現在の表現要件をサポートし続けることができないので）異なる表現からセグメントを取り出すことを決めた場合、前の表現と同じｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ値を有する新しい表現についてのＢａｓｅＵＲＬを選択することができる。このｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性の使用は、新しい表現についてのセグメントを取り出すことが、同じｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ値を有するＢａｓｅＵＲＬを介して前の表現から取り出されたセグメントと同様の性能（たとえば、アベイラビリティ調整）を体験することを示す、デバイスに対するヒントの役割を果たす。

ｅＭＢＭＳを介したＤＡＳＨブロードキャストに関する問題： ＤＡＳＨメディアセグメント（たとえば、メディアファイル）の連続配信は、メディアファイルまたはＤＡＳＨメディアセグメントの連続送信を含み得るメディアストリーミングサービスを構成する。ＲＴＰを使用するメディアのストリーミング配信も可能であるが、ＲＴＰトランスポートは、通常、ＤＡＳＨセグメントには適していない。

一部のブロードキャストネットワークでは、ブロードキャストストリーム化されたコンテンツは、また、たとえば、ｅＭＢＭＳ内のＲＴＰストリーミングブロードキャストの場合のように、ユニキャストを介して利用可能にされ、アクセスされることができる。コンテンツのこの代替的な配信は、ブロードキャストカバレージの中にいない間、ブロードキャストストリーミングサービス用のコンテンツにアクセスするためのユニキャストフォールバック技法を提供する。ブロードキャストファイル配信サービスのファイルにアクセスするフォールバック技法は、通常、ブロードキャストネットワークでは定義されない。

ＤＡＳＨセグメントのブロードキャスト配信は、通常、ブロードキャストファイル配信サービス（たとえば、ＦＬＵＴＥ）に採用されるトランスポート・プロトコルを使用するので、ブロードキャストＤＡＳＨサービスのコンテンツにアクセスするための代替のユニキャストフォールバックが必要とされる。

ｅＭＢＭＳなどを介したＤＡＳＨブロードキャストに関して考慮すべきいくつかの問題が存在する。１つの問題は、ブロードキャストＤＡＳＨサービスが様々な位置で様々なバージョンのコンテンツ（たとえば、様々な表現）を配信できることである。様々な表現は、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であることもあり得る。したがって、サービスのどの表現が、現在の所望の／利用可能なブロードキャストまたはユニキャスト・トランスポートに利用可能であるかをシグナリングする技法が必要とされる。

別の問題は、ＤＡＳＨセグメントのトランスポートが、時間セグメントからのさらなるブロードキャストアベイラビリティ調整（たとえば、アベイラビリティの先延ばしまたは前倒し）がユニキャストを介した取出しに利用可能であり得ることを招く場合があることであり、ブロードキャストアベイラビリティ調整は、そのようなシナリオにおけるブロードキャスト待ち時間である。ブロードキャスト配信を介して受信されたセグメントのアベイラビリティは、セグメントがユニキャスト配信を介して受信され得る時間からのさらなるアベイラビリティ調整を招く場合があり、このことは、１つのモードの配信から別のモードの配信に（たとえば、ブロードキャストからユニキャストに）切り替えるときの問題をまねきうる。デバイスがブロードキャストカバレージに出入りするときに、シームレスなユニキャストからブロードキャスト（ＵＣ−ＢＣ）およびブロードキャストからユニキャスト（ＢＣ−ＵＣ）の遷移を可能にするために、ブロードキャストアベイラビリティ調整に関する情報は、ＤＡＳＨクライアントに通信されるべきである。

別の問題は、ユニキャストを介して利用可能な表現が、いくつかの地理的エリアでのみアクセス可能であり得ることである。そのような地理的制約は、ＤＡＳＨクライアントにシグナリングされるべきである。さらに別の問題は、ブロードキャストＤＡＳＨサービスが様々なＦＬＵＴＥセッションを介してマルチプルな表現を搬送し得ることであり、したがって、どのＦＬＵＴＥセッションが所望の表現を可能にするかを識別する技法が必要とされる。たとえば、マルチプルな表現が、代替的な言語またはビデオ解像度のオプションを提供するために所与のエリアでブロードキャストを介して利用可能であり得る。関心のある表現だけを受信するように選択すると、モバイルエンティティのバッテリ寿命が改善される。

いくつかの状況では、ブロードキャストＤＡＳＨのサービスオンデマンドを作成して、マルチプルなユーザがユニキャストを介してＤＡＳＨコンテンツを取り出すことによって引き起こされるシステムリソース上の負荷を低減することが望ましい場合がある。異なるＵＲＬを使用して、ユニキャスト受信からブロードキャスト受信に切り替える必要があることをデバイスにシグナリングすることも必要であり得る。したがって、これらの問題に対処するための解決策が以下に記載される。

シグナリング情報の搬送： 上述の問題に対処するために、ブロードキャストされたＤＡＳＨセグメントのサポートのためにいくつかのパラメータがＤＡＳＨクライアントにシグナリングされることができる。そのようなパラメータは、ＭＰＤにおいて別個の新しいパラメータとしてシグナリングされることができる。しかしながら、ＭＰＤ定義をさらに拡張して、ブロードキャストＤＡＳＨのいくつかのシナリオのみで使用されるこれらの追加パラメータについてのサポートを追加することは、望ましくないか、または許容できない可能性がある。

したがって、本明細書に記載する提案される解決策は、登録された名前空間識別子（ＮＩＤ：Namespace Identifier）下のユニフォームリソース名（ＵＲＮ）として、これらのパラメータをシグナリングすることができる−たとえば、３ＧＰＰの場合、ＮＩＤは３ｇｐｐであり、その結果、３ＧＰＰ制御下のＵＲＮはｕｒｎ：３ｇｐｐ：｛３ｇｐｐ−ｕｒｎ｝の形式である。加えて、ＵＲＮ名前空間固有文字列（ＮＳＳ）は、ＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性などの中の文字列として搬送されたキー＝値のペアのコロン区切りのリストとして、必要なパラメータをどのように符号化すべきかの実施形態を提供する。

可能な代替手法は、ＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性において文字列として搬送されたキー＝値のペアのカンマ区切りのリストを使用することを含むことができる。別の代替手法は、ＸＭＬ構造内のこれらのパラメータをＸＭＬスキーマごとに符号化し、ＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性においてそのＸＭＬ符号化データを搬送することを含むことができる。さらに別の手法は、追加の属性または要素を、ＵＲＮにおいて搬送されたパラメータのリスト、カンマ区切りのリストをキャプチャするために、ＭＰＤのＸＭＬスキーマに追加すること、または、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性の中のＸＭＬ符号化もしくはパラメータに追加することを含むことができる。

キー＝値のペアのリストを伝達するためにＵＲＬ符号化が使用される実施形態では、以下の規則または要件が適用される場合がある。ＵＲＮのＮＳＳ内の最初の文字列は、（ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎの場合）ｓｌであり得る。たとえば、３ＧＰＰのＵＲＮの場合、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性で使用されるすべてのＵＲＮは、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる。２番目の文字列（または最初のキー＝値のペア）は、「：ｔｒａｎｓｐｏｒｔ＝」＋値文字列（value-string）であり得る。たとえば、可能な値文字列は、「ｂｒｏａｄｃａｓｔ」、「ｕｎｉｃａｓｔ」、「ｂｏｔｈ」であり得る。他のキー＝値のペアは、「：ｔｒａｎｓｐｏｒｔ＝」＋値文字列、またはその変形形態に従うことができる。

ブロードキャストＤＡＳＨサービスのユニキャストアベイラビリティ： ＤＡＳＨは、各ＤＡＳＨクライアントがＨＴＴＰを介して、かつＭＰＤで定義されたタイムラインに従うシーケンスでメディアサービスを取り出し得る、ユニキャストストリーミングフレームワークを提供する。ＤＡＳＨセグメントはまた、メディアセグメントがＦＬＵＴＥなどを介してブロードキャストされる、ブロードキャスト・トランスポートを介して、ＤＡＳＨクライアントを含むデバイスに配信され得る。

ブロードキャストシステムは、通常、ブロードキャスト・トランスポートを介して利用可能なサービスを記述するシステム情報（ＳＩ）メタデータを含む。ｅＭＢＭＳブロードキャストシステムでは、そのＳＩは、ユーザサービスディスクリプション（ＵＳＤ）と呼ばれる場合があり、図９に示されたように、サービスのバンドルを記述するメタデータを含む場合がある。ＳＩの他の例は、ＯＭＡブロードキャストサービスガイドおよびＭｅｄｉａＦＬＯサービス定義メタデータであることに留意されたい。図１０Ａを参照すると、ｅＭＢＭＳ用のＵＳＤの実施形態が示され、各サービスはパラメータ付きで記述される場合がある。そのようなパラメータは、（図１１に詳述される）ｄｅｌｉｖｅｒｙＭｅｔｈｏｄリストと、サービスに関連付けられたＭＰＤユニフォームリソース識別子（ｍｐｄＵＲＩ）に対する参照を含み得る。ｍｐｄＵＲＩは、ＭＰＤをサービスに結合することができる。図１０Ｂは、以下でさらに詳細に記載される、ｅＭＢＭＳ用のＵＳＤの別の実施形態を示す。

図１１は、ｅＭＢＭＳブロードキャストシステムの場合に、ブロードキャストサービスコンテンツのユニキャストバージョンがどこで見出され得るかに関係する情報をブロードキャストシステムについてのＳＩが提供できることを示す。ＲＴＰストリーミングを使用するｅＭＢＭＳブロードキャストサービスの場合、ＳＩは、サービス用のｄｅｌｉｖｅｒｙＭｅｔｈｏｄ内のｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩを介して、同じコンテンツについてのユニキャストＲＴＰストリーミングバージョンを記述するセッション記述プロトコル（ＳＤＰ）ファイルへのポインタを提供することができる。そのようなＵＲＬの存在はまた、サービスのユニキャストバージョンが利用可能であることをシグナリングする働きをすることができ、一方で、その不在は、サービスがブロードキャストを介してのみ利用可能であることを示す。パラメータは、ユニキャストのアベイラビリティなどを示すために使用できることに留意されたい。ブロードキャストＤＡＳＨサービスの場合、属性は、ブロードキャストＤＡＳＨサービスについて、ユニキャスト表現も利用可能であることをシグナリングするために使用され得る。

ブロードキャストＤＡＳＨサービスの場合、ＳＩにおける別個のＵＲＬを介したユニキャストアベイラビリティの明示的なシグナリングは、一般に望ましくない。ブロードキャストＤＡＳＨサービスの場合、そのような明示的なシグナリングは、ユニキャストを介したＤＡＳＨセグメントの配信を記述する追加ＭＰＤへの参照を提供しうる。プレイバック中のＭＰＤの交換は破壊的になる傾向があるので、（たとえば、ｅＭＢＭＳのＵＳＤについてｍｐｄＵＲＩを介してシグナリングされた）ブロードキャスト用のＭＰＤと、（たとえば、ｅＭＢＭＳのＵＳＤについてｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩを介してシグナリングされた）ユニキャスト用の別のＭＰＤとを使用することは、ブロードキャスト配信からユニキャスト配信、およびその逆の、受信のシームレスな遷移を可能にしない。したがって、ユニキャストアベイラビリティのシグナリングを単一のＤＡＳＨ ＭＰＤに埋め込み、図８に示されたタイプのＢａｓｅＵＲＬ要素を介して異なるロケーションからのセグメントのアベイラビリティのＭＰＤシグナリングを活用することが望ましい。どのＵＲＬがユニキャスト受信対ブロードキャスト受信に使用されるべきかをＤＡＳＨクライアントにシグナリングする方法が提供される。このように、ブロードキャストサービスのユニキャスト受信を行うときには、ＤＡＳＨクライアントは、通常のＤＡＳＨクライアントとして働き、単一のＭＰＤにおいてユニキャストＨＴＴＰのＵＲＬを使用してセグメントを取り出す。

この手法により、ブロードキャストおよびユニキャストを介してサービスがどのように受信され得るかを、単一のＭＰＤが記述することが可能になる。ブロードキャスト受信およびユニキャスト受信用の単一のＭＰＤにより、ＤＡＳＨクライアントがブロードキャストカバレージに出入りするときのシームレスなＵＣ−ＢＣおよびＢＣ−ＵＣの受信ハンドオフの効率的なサポートも可能になる。

ユニキャスト受信およびブロードキャスト受信用のセグメントＵＲＬを識別することに関して、図１２は、ＭＰＤから他の属性および要素を取り除きながら、ＭＰＤレベルで利用可能なＢａｓｅＵＲＬのリストを示す図７の簡略化を与える。ユニキャスト・トランスポートでは、マルチプルなＢａｓｅＵＲＬは、通常、同一のセグメントがマルチプルなロケーションでアクセス可能であることをシグナリングするために使用される。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、同じｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ値をもつＢａｓｅＵＲＬ要素が、共通のネットワークロケーションでのサービスに対するそれらのＵＲＬ解決を有する可能性があるように、ＢａｓｅＵＲＬ間の関係を指定するために定義されることができる。これにより、表現を変更するときにどのベースＵＲＬを使用すべきかを決定するときに、ＤＡＳＨクライアントがｓｅｒｖｉｃｅＬｏｃａｔｉｏｎを使用することが可能になる。たとえば、ＤＡＳＨクライアントは、古い表現のために使用されたＢａｓｅＵＲＬと同じｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性をもつＢａｓｅＵＲＬを有する新しい表現を選択することができる。

所与の表現についてのマルチプルなＢａｓｅＵＲＬは、サービスのためのセグメントがそこから取出しに利用可能である様々なロケーションを記述するので、ブロードキャストシステムを通じたＤＡＳＨサービスの場合、フォーマットはｓｅｒｖｉｃｅＬｏｃａｔｉｏｎの文字列に関して定義され得る。フォーマットは、所与のブロードキャストＤＡＳＨサービスまたはそれらの表現の任意の組合せが、ブロードキャストを介してのみ利用可能であるか、ユニキャストを介してのみ利用可能であるか、またはユニキャストとブロードキャストの両方を介して利用可能であるかをシグナリングするために追加情報を提供することができる。より具体的には、ＵＲＮフォーマットを使用するときには、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、上述されたように、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる文字列を含み得る。後続の文字列は、「：」で始まる最初の文字列に連結され、キー＝値のペアを提供する文字列がその後に続くことができる。２番目の文字列（または最初のキー＝値のペア）は、「：ｔｒａｎｓｐｏｒｔ＝」＋値文字列であり得る。可能な値文字列は、「ｂｒｏａｄｃａｓｔ」、「ｕｎｉｃａｓｔ」、「ｂｏｔｈ」であり得る。他の値が使用される場合がある。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性についての文字列の例は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ、またはｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔであり得る。

特定の値文字列の設定に応じて、他の制限がＵＲＬの使用に課される場合がある。たとえば、値文字列が「ｂｒｏａｄｃａｓｔ」であるとき、関連付けられたＢａｓｅＵＲＬ要素の使用から導出されたＵＲＬは、ＤＡＳＨクライアントがブロードキャストを介してそのサービスを受信するときに使用され得る。より具体的には、「ｂｒｏａｄｃａｓｔ」に設定された値文字列を有するただ１つのＢａｓｅＵＲＬが存在する場合、サービスまたは対応する表現は、ブロードキャストを介してのみ利用可能である。「ｂｒｏａｄｃａｓｔ」に設定された値文字列を有するＢａｓｅＵＲＬが存在しない場合、サービスまたは対応する表現は、ブロードキャストを介して利用可能ではない。「ｂｒｏａｄｃａｓｔ」に設定された値文字列を有するマルチプルなＢａｓｅＵＲＬが存在する場合、マルチプルなブロードキャスト・トランスポート（たとえば、ＦＬＵＴＥ）セッションがサービスについて定義され得るか、またはＭＰＤによって記述されたサービスが、様々な地理的エリアでブロードキャストされ得る様々な表現を含む。様々な表現を様々なロケーションでブロードキャストされ得ることも可能である。説明の目的のみで、以下の説明では、１つのブロードキャスト表現のみが存在すると仮定する。本明細書に記載された符号化方式をサポートしないＤＡＳＨクライアントとの互換性のために、「ｂｒｏａｄｃａｓｔ」に設定された値文字列を有するＢａｓｅＵＲＬは、ＢａｓｅＵＲＬのリストの最後に配置され得る。「ｂｒｏａｄｃａｓｔ」に設定された値文字列を有するＢａｓｅＵＲＬは、ローカルホストｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／などを指すことによって、ローカル（すなわち、デバイス上の）ＨＴＴＰサーバにＤＡＳＨクライアントを向けることができる。

値文字列が「ｕｎｉｃａｓｔ」であるときには、関連付けられたＢａｓｅＵＲＬ要素上のＵＲＬは、ＤＡＳＨクライアントがユニキャストを介してサービスにアクセスするときに使用されることができる。値文字列が「ｕｎｉｃａｓｔ」に設定されたマルチプルなＢａｓｅＵＲＬが存在する場合、ＤＡＳＨクライアントは、ユニキャストを介してサービスにアクセスするときにＢａｓｅＵＲＬのうちの１つを選択するために、様々な手法を使用することができる。たとえば、１つの手法は、リストの中の最初のＢａｓｅＵＲＬから順番にＢａｓｅＵＲＬを使用することである。

値文字列が「ｂｏｔｈ」であるとき、関連付けられたＢａｓｅＵＲＬ要素上のＵＲＬは、ＤＡＳＨクライアントがユニキャストを介して、またはブロードキャストカバレージの中にいる間のいずれかで、サービスにアクセスするときに使用されることができる。値文字列が「ｂｏｔｈ」に設定されたＢａｓｅＵＲＬが存在する場合、（１つだけのブロードキャスト表現が存在すると仮定して、）値文字列が「ｂｒｏａｄｃａｓｔ」に設定された表現についてのさらなるＢａｓｅＵＲＬは存在しない。値文字列が「ｂｏｔｈ」に設定されたＢａｓｅＵＲＬは、外部の（すなわち、ネットワークからアクセス可能なサーバ）ＨＴＴＰサーバにＤＡＳＨクライアントを向ける。したがって、ＤＡＳＨクライアントがブロードキャストカバレージの中にいて、このＵＲＬが使用されるときには、デバイスは、ＨＴＴＰアクセスをローカルホストにリダイレクトする技法をサポートする。

サンプルＤＡＳＨクライアントの挙動： ＭＰＤにおいてシグナリングされるＤＡＳＨセグメントのブロードキャストまたはユニキャストのアベイラビリティに基づいて、ＤＡＳＨクライアントの実装形態は、次のようにＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報を使用することができる。ブロードキャストカバレージの中の最初の受信に関して、ＤＡＳＨクライアントは、ブロードキャストカバレージの中にいる間ブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスの受信を開始することができる。ＤＡＳＨクライアントは、（１つのブロードキャスト表現を仮定して）ブロードキャストを介してどの表現が利用可能であるかを発見し、「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、かつ／または選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。ブロードキャストの中にいる間にどのブロードキャスト表現が現在利用可能であるかを判定することは、ＦＬＵＴＥトランスポートを介してシグナリングされたメディアセグメントのファイル名を照合することによって行うことができる。

ブロードキャストを介してコンテンツを消費しながらブロードキャストカバレージから遷移することに関して（ＢＣ−ＵＣ）、ブロードキャストを介してブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスを受信するＤＡＳＨクライアントは、セグメントのブロードキャスト受信から遷移し、セグメントのユニキャスト受信を開始することができる。ブロードキャストカバレージからの遷移は、ＬＴＥトランスポート内のＳＩＢの中で利用可能なＳＩＢ−１３の不在によって、より直接には、そのブロードキャストＤＡＳＨサービスを搬送する（サービスの一時的モバイルグループ識別情報（ＴＭＧＩ）などを割り当てられた）ＬＴＥベアラが利用できないことによって、検出することができる。関係する態様では、次いで、ユニキャスト帯域幅がその表現をサポートすることができ、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有する表現についてのＢａｓｅＵＲＬが存在する場合、ＤＡＳＨクライアントは現在の表現の受信を続けることができる。そうでない場合、ＤＡＳＨクライアントは、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬが存在する異なる表現に変化することができる。マルチプルのそのようなＢａｓｅＵＲＬが存在する場合、ＤＡＳＨクライアントは１つを選択することができる。さらなる関係する態様では、ＤＡＳＨクライアントは、選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。

（たとえば、ＳＩＢ−１３がＬＴＥトランスポート内のシステム情報ブロック（ＳＩＢ）の中にないときの）ブロードキャストカバレージからの最初の受信に関して、ＤＡＳＨクライアントは、ブロードキャストカバレージの中にいない間、ユニキャストを介して利用可能なブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスのユニキャスト受信を開始することができる。ＤＡＳＨクライアントは、セグメントを取り出し、再生（play）すべき表現を選択するために利用可能な帯域幅を決定し、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、かつ／または選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。

ユニキャストを介してコンテンツを消費しながらブロードキャスト受信に遷移することに関して（ＵＣ−ＢＣ）、ユニキャストを介してブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスを現在受信しているＤＡＳＨクライアントは、ブロードキャストカバレージに遷移し、ブロードキャストを介したセグメントの受信を開始することができる。関係する態様では、ＤＡＳＨクライアントは、たとえば、ＦＬＵＴＥトランスポート内で記述されたメディアファイル名を介して、ブロードキャストカバレージの中でどの表現が利用可能であるかを発見することができる。さらなる関係する態様では、ブロードキャストされている表現がユニキャストを介してアクセスされている表現と同じである場合、ＤＡＳＨクライアントは、現在の表現の受信を続けることができる。この場合、ＤＡＳＨクライアントは、「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択することができる。さらなる関係する態様では、ＤＡＳＨクライアントは、ブロードキャスト表現に遷移し、「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択することができる。さらなる関係する態様では、ＤＡＳＨクライアントは、選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。

ブロードキャストＤＡＳＨサービスのユニキャストアベイラビリティに対する地理的制約： ブロードキャストＤＡＳＨサービスがユニキャストを介して利用可能な場合でも、いくつかの地理的エリアに対するサービスコンテンツのユニキャストアベイラビリティを制限する契約上の義務または他の要件が存在する場合がある。

ユニキャストアベイラビリティに対する地理的制約は、別の値の文字列を追加することによって、ブロードキャストＤＡＳＨサービス用のＭＰＤ内のＢａｓｅＵＲＬで示すことができる。たとえば、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性に関連付けられた、ブロードキャストＤＡＳＨサービス用のＭＰＤ内のＢａｓｅＵＲＬは、同じくｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内でトランスポートされる追加文字列フォーマットを介して、ユニキャスト受信についての地理的なアベイラビリティの制約を示すことができる。具体的には、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、ｕｒｎフォーマットを使用するとき、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる文字列を含むことができ、サービスがユニキャストを介して利用可能であることを示すために、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかを含むことができる。

（キー＝値のペアのフォーマットの）文字列「：ｕＧｅｏ３ＧｐｐＣｅｌｌＩＤ＝」＋ＣｅｌｌＩＤ文字列は、ＣｅｌｌＩＤ文字列を介して、サービスがユニキャストを介して消費され得る３ＧＰＰのセルＩＤを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ：ｕＧｅｏ３ＧｐｐＣｅｌｌＩＤ＝３４５６９０などであり得る。

（キー＝値のペアのフォーマットの）文字列「：ｕＧｅｏ３Ｇｐｐ２Ｓ＋Ｎ＋Ｚ＝」＋ＳＩＤ＿ｖａｌｕｅ＋「＋」＋ＮＩＤ＿ｖａｌｕｅ＋「＋」＋ＰＺＩＤ＿ｖａｌｕｅは、ＳＩＤ、ＮＩＤ、ＰＺＩＤ、および「＋」の文字列の連結を介して、サービスがユニキャストを介して消費され得る３ＧＰＰ２のセルＩＤを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ：ｕＧｅｏ３Ｇｐｐ２Ｓ＋Ｎ＋Ｚ＝２３＋３４＋４５などであり得る。したがって、デバイスに対して利用可能であり得る他の地理的記述子を取り込むために、他の文字列を定義することができる。

サンプルのＤＡＳＨクライアントの挙動に関して、ＭＰＤにおいてシグナリングされたＤＡＳＨセグメントのユニキャストアベイラビリティおよび任意の地理的制約に基づいて、ＤＡＳＨクライアントの実装形態は、次のようにＢａｓｅＵＲＬ上のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報を使用することができる。地理的制約がないユニキャスト受信の場合、ＤＡＳＨクライアントは、ユニキャストを介してブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスの受信を開始することができる（すなわち、デバイスはブロードキャストカバレージの中におらず、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬが存在する）。関係する態様では、ＤＡＳＨクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎが「：ｕＧｅｏ」で始まる文字列を含むＢａｓｅＵＲＬが存在しないことを検証し、かつ／または選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。

制約されたエリアの中にいる間地理的制約を有するユニキャスト受信の場合、ＤＡＳＨクライアントは、ユニキャストを介してブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスの受信を開始することができる。関係する態様では、ＤＡＳＨクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎが「：ｕＧｅｏ」で始まる文字列を含むＢａｓｅＵＲＬが存在することを検証し、提供された地理情報を理解することを決定し、記述されたエリアの中にいることを判定し、かつ／または、記述されたエリアの中にいる間、選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行することができる。

制約されたエリアの外にいる間地理的制約を有するユニキャスト受信が存在しない状況の場合、ＤＡＳＨクライアントは、ユニキャストを介してブロードキャスト（たとえば、ｅＭＢＭＳ）ＤＡＳＨサービスの受信を開始することができず、サービスのプレイバックは停止するはずである。関係する態様では、ＤＡＳＨクライアントは、セグメントを取り出し、再生すべき表現を選択するために利用可能な帯域幅を決定し、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎが「：ｕＧｅｏ」で始まる文字列を含むＢａｓｅＵＲＬが存在することを検証し、ＵＥ（もしくはＤＡＳＨクライアント）が提供された地理情報を理解することを決定し、ＵＥが記述されたエリアの中にいないことを判定し、提供された地理情報が理解され得ないことを決定し、かつ／または、記述されたエリアの中にいない間、選択されたＢａｓｅＵＲＬを使用する通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行しないようにすることができる。

トランスポートアベイラビリティ調整の考慮： 図１３に示されたように、ＤＡＳＨセグメントのアベイラビリティについてのタイムラインをＭＰＤの中で記述することができる。本明細書ではＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅと呼ばれるＭＰＤのａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅは、そのタイムラインが固定された時刻からの絶対時間を定義する。ＭＰＤの最初のＰｅｒｉｏｄ内のｓｔａｒｔ属性は、最初のセグメントが取出し可能になったときのａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅからの継続時間（duration）を記述する。同じ表現についての次のセグメントは、セグメントが同じ継続時間であるときのその表現についてのＭＰＤ内の適切なｄｕｒａｔｉｏｎ属性によって間隔をあけられる（すなわち、各セグメントはセグメント継続時間によって間隔をあけられる）。図１３はまた、ＦＬＵＴＥを介したＵＥへのブロードキャスト・トランスポートおよびＬＴＥベアラが、上述されたＭＰＤタイムラインで記述されたときよりも、セグメントのアベイラビリティをＦＬＵＴＥ／ＬＴＥの配信のために後になるようにさせることを示す。メディアファイルがＦＬＵＴＥを介して配信されたとき、ＤＡＳＨクライアントは、リモートサーバからのユニキャスト取出しとは対照的に、ローカルストレージからセグメントを取り出す。ユニキャストアベイラビリティタイムラインは、ＭＰＤのａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ属性およびｄｕｒａｔｉｏｎ属性によって記述されたタイムラインであり得る。

関係する態様では、ブロードキャスト配信内のセグメントアベイラビリティタイムラインは、ユニキャスト配信のタイムラインよりも後になる必要はなく、実際、ユニキャスト配信を介したセグメントアベイラビリティの前になり得る。この場合、「アドバタイズされた」ユニキャストセグメントアベイラビリティタイムラインは、ＭＰＤ内のａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ属性およびｄｕｒａｔｉｏｎ属性によって与えられたように、ＤＡＳＨメディアプレゼンテーションのセグメントが、ＭＰＤドキュメントの範囲内のＨＴＴＰサーバ／コンテンツ配信のエンティティの中で（ＤＡＳＨクライアントによるＨＴＴＰ検索に）利用可能であることを保証され得るとき、「最新の」時刻を表すことができる。ａ）コンテンツソースからのＢＭ−ＳＣでのＤＡＳＨセグメントの受信、ｂ）ＬＴＥコアネットワークおよびＲＡＮを越えてＦＬＵＴＥにわたるＵＥへの送信、ならびに／またはｃ）ＵＥでのＦＬＵＴＥ受信、ＦＥＣ復号およびセグメント復元と取出し用のローカルＨＴＴＰキャッシュへの配置の組合せを含む、ブロードキャスト配信されたセグメントの利用可能時刻は、セグメントがリモートコンテンツ配信ネットワーク（ＣＤＮ）またはＨＴＴＰサーバに到達する前に起こり得ることが可能である。したがって、ブロードキャスト配信されたセグメントの利用可能時刻は、ユニキャストの利用可能時刻よりも前、同じ、または後になり得る。ＭＰＤは多数のデバイスに利用可能／提供することができ、ＭＰＤを所有するデバイスがそこからＤＡＳＨセグメントを取り出すことができるマルチプルなアクセスネットワークまたはＣＤＮを参照できることに留意されたい。たとえば、ＭＰＤドキュメントを作成したエンティティおよびＤＡＳＨコンテンツ配信のサービスプロバイダは、ＭＰＤによって記述されたように、メディアプレゼンテーションと個別のＲｅｐｒｅｓｅｎｔａｔｉｏｎとを配信することができる。

ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅによって表現されたユニキャストセグメント利用可能時刻の指示が、ＭＰＤドキュメントによって支配されたすべてのＨＴＴＰサーバにわたって最も遅い可能時刻であるとすれば、より早いセグメント利用可能時刻を保証できる個別のユニキャストアクセスネットワーク／ＣＤＮがその差異をシグナリングでき、ユーザがＤＡＳＨコンテンツをより早く取得し見ることが可能になることは有用である。言い換えれば、ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅはユニキャスト開始時刻の最悪のケースである。コンテンツを様々なＣＤＮに配信するための様々な待ち時間が存在する。これは、その表現について定義された待ち時間期間によって表現のセグメントについてのアベイラビリティタイムラインを調整することによって行うことができる。本明細書では（図１３の保護期間として示された）ａｖａｉｌａｂｉｌｉｔｙＴｉｍｅＡｄｊｕｓｔｍｅｎｔと呼ばれるパラメータは、所与のアクセスネットワーク／技術用のＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅからの調整を示すために、ＢａｓｅＵＲＬ要素の下に追加することができる。言い換えれば、ａｖａｉｌａｂｉｌｉｔｙＴｉｍｅＡｄｊｕｓｔｍｅｎｔは、概して、最悪のケースのユニキャスト利用可能時刻と比較して、所与のユニキャストまたはブロードキャストのネットワークを介したセグメント利用可能時刻を示すために使用することができる。

関係する態様では、Ｐｅｒｉｏｄ全体についてのアベイラビリティ調整は、期間内のリソースがＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅの前にアクセス可能であるように、十分大きい絶対値を有する負の値であり得るし、データセグメントのより早いダウンロードがユーザ体験を向上することが可能になる。

図１３を参照すると、ＤＡＳＨクライアントがユニキャストを介してセグメントを取り出すために使用できる取出し可能タイムラインが示される。図１３のＦＬＵＴＥアベイラビリティタイムラインは、たとえば、ｅＭＢＭＳのＦＬＵＴＥセッションを介してセグメントをブロードキャストすることに含まれるアベイラビリティ調整が存在することを示し、これは、セグメントのパケット化およびトランスポート用のＦＥＣ符号化、ＵＥに向けてのパケットのブロードキャスト、ならびにデバイス上のＦＥＣ復号およびセグメント再配置に起因する場合がある。これらのブロードキャストセグメントにアクセスするＤＡＳＨクライアントの場合、このアベイラビリティ調整は、セグメントを取り出すための時間アベイラビリティが、セグメントがユニキャストを介して取り出されるか、またはブロードキャスト配信を介して取り出されるかに応じて異なるべきであることを知らせることができる。ＤＡＳＨクライアントは、ブロードキャストを介してセグメントを要求するとき、保護期間を考慮に入れるべきである。

保護期間は、ブロードキャストを介して取り出すためのセグメントのアベイラビリティが、ユニキャストを介して取り出される同じセグメントに比べて遅延されることをＤＡＳＨクライアントに示す。

ＤＡＳＨセグメントのブロードキャスト配信用の保護期間のシグナリング： 上述されたように、関連付けされたｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するブロードキャストＤＡＳＨサービス用のＭＰＤ内のＢａｓｅＵＲＬは、表現がブロードキャストを介して利用可能であることを示す文字列「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」を含むことができる。セグメントのブロードキャスト配信に関連するアベイラビリティ調整に対応するために、同じくｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内でトランスポートされる追加文字列を使用して、保護期間情報を伝達することができる。たとえば、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、ＵＲＮフォーマットを使用するとき、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる文字列を含むことができ、サービスがブロードキャストを介して利用可能であることを示すために、文字列「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」を含むことができる。

（キー＝値のペアのフォーマットの）文字列「：ｐｐ＝」＋ｐｐＶａｌｕｅは、ｐｐＶａｌｕｅを介して、たとえば、ミリ秒または他の時間増分で保護期間をシグナリングして、ＤＡＳＨクライアントがブロードキャスト受信を介してセグメントを要求したときに対応されるようにすることができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ：ｐｐ＝５０などであり得る。

サンプルのＤＡＳＨクライアントの挙動に関して、ＭＰＤにおいてシグナリングされたＤＡＳＨセグメントのブロードキャストアベイラビリティおよび保護期間の情報に基づいて、ＤＡＳＨクライアントの実装形態は、次のようにＢａｓｅＵＲＬ上のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報を使用することができる。

ブロードキャスト配信を介した受信に関しては、ＤＡＳＨクライアントは、ブロードキャストエリア内でどの表現が利用可能であるかを発見し、「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、「：ｐｐ」で始まるｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内の部分文字列内で示された保護期間を決定し、かつ／または選択されたＢａｓｅＵＲＬを使用するＭＰＤ内のセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができるが、「：ｐｐ」を含む文字列内で示された追加ｐｐＶａｌｕｅミリ秒によってセグメント取出しを調整する（すなわち、先延ばす、または前倒しにする）。これにより、所与の地理的エリアにあるモバイルが、アドバタイズされたよりも早くセグメントについての要求を行うことが可能になり、より低い待ち時間の体験をユーザに提供するか、または次いでアドバタイズされた後でモバイルにセグメントを取り出させ、したがってセグメントがＭＰＤにおいてアドバタイズされたよりも後にのみ利用可能になるときのエラー状態を回避する。

ブロードキャストカバレージの外の受信に関しては、ＤＡＳＨクライアントは、セグメントを取り出し表現を選択するために利用可能な帯域幅を決定し、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、かつ／または選択されたＢａｓｅＵＲＬを使用するＭＰＤ内の正確なセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができ、さらなるセグメント取出しの遅延は実行されない。

ＤＡＳＨセグメントのブロードキャスト配信用の保護期間のシグナリングに対する代替形態： ブロードキャスト待ち時間に対応するための代替形態が図１４に示される。ブロードキャストカバレージの中にいる間、保護期間を明示的にシグナリングし、それに対応するのではなく、ブロードキャストＤＡＳＨサービス用のＭＰＤは、既存のＭＰＤパラメータを介してブロードキャスト・トランスポートのアベイラビリティ調整に対応することができる。これは、ＭＰＤのａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ属性に保護期間を追加すること、または最初のＭＰＤのＰｅｒｉｏｄのｓｔａｒｔ属性に保護期間を追加することによって、図１４に示される。上述されたパラメータのいずれかに保護期間を追加することの影響は、ユニキャスト取出しも遅延されることである。

シームレスなＵＣ−ＢＣ遷移／ＢＣ−ＵＣ遷移： ブロードキャスト・トランスポートにおけるさらなるアベイラビリティ調整に対応する２つの代替形態を考慮する際に、ユニキャストおよびブロードキャストを介したセグメントの受信およびプレイバック前のバッファリングでのＵＣ−ＢＣ遷移およびＢＣ−ＵＣ遷移が考慮されるべきである。図１５は、セグメントＮがユニキャストを介して取り出されている時点で、ユニキャストを介したセグメントの受信からブロードキャストを介した受信への遷移が起こる時点を示す。

シームレスな遷移についての１つの目標は、ＤＡＳＨクライアントがユニキャスト受信とブロードキャスト受信との間を遷移するとき、メディアプレイバック中の干渉を最小化することである。これを達成するために、ＤＡＳＨクライアントは、プレイバックが始まる前に２つ以上のセグメントを蓄積することができる。プレイバックを開始する前に蓄積するセグメントの数は、ＭＰＤ内のｍｉｎＢｕｆｆｅｒＴｉｍｅ属性などを介してシグナリングされ得る。図１６は、（時刻ｔ_Aviで）ユニキャストを介して取り出されたセグメントのプレイバックが１セグメントだけ遅延され（左のタイムライン）、かつ２セグメントだけ遅延された（右のタイムライン）、（時刻ｔ_Pbiで）遅延された２つのプレイバックシナリオを有する実施形態を示す。これは、１セグメントまたは２セグメントが、それぞれ、プレイバックが開始できる前に蓄積される必要があることを意味する。図１６の例は、セグメントが同じサイズであり、帯域幅が１セグメントの継続時間内にセグメントをダウンロードするために利用可能である場合に、ユニキャストを介して１セグメントをダウンロードするために１セグメントの継続時間がかかるシナリオを示す。図１６の実施形態は例示的であるにすぎず、セグメントのサイズが可変であり、バッファリングするセグメントの数がそのような可変性に対応する他のシナリオを記載するために、同様の数字を描くことができることに留意されたい。

図１７は、（時刻ｔ_FAviで）ブロードキャストを介して受信されたセグメントについての同様の遅延されたセグメントプレイバックのシナリオを示す。これらのセグメントは、ブロードキャストを介して配信され、前に示されたようにローカルで利用可能なので、クライアントに直ちに利用可能であり得る。図１７の実施形態は、セグメントが同じサイズであり、ブロードキャスト帯域幅が１セグメントの継続時間内にセグメントを配信するために十分である場合に、ブロードキャストを介して１セグメントを配信するために１セグメントの継続時間がかかることを示唆する。図１７の実施形態は例示的であるにすぎず、セグメントのサイズが可変であり、バッファリングするセグメントの数がそのような可変性に対応する同様のシナリオを記載するために、同様の数字を描くことができることに留意されたい。

図１７はまた、プレイバック前の１セグメントまたは２セグメントの同じｍｉｎＢｕｆｆｅｒＴｉｍｅ要件の使用を示す。図１７はまた、ＤＡＳＨクライアントが保護期間に対応するとき、すなわち、（時刻ｔ_Aviでの）ユニキャストアベイラビリティよりも後の保護期間である、（時刻ｔ_FAviでの）ブロードキャストセグメントアベイラビリティによって取出しが駆動されるとき（図１５参照）、セグメントは、ローカルで容易に利用可能であり得るし、最小の待ち時間で取り出すことができる。取り出されたセグメントは、ｍｉｎＢｕｆｆｅｒＴｉｍｅが１セグメントまたは２セグメントであるとき、それぞれ１番目のセグメントまたは２番目のセグメントの後に、直ちにプレイバック準備ができている。

図１６〜図１７のタイムラインが与えられると、ＤＡＳＨクライアントがユニキャストを介してセグメントＮを取り出す間にブロードキャストアベイラビリティが検出されると仮定して、ＵＣ−ＢＣ遷移への影響は以下を含み得る。第１に、セグメントＮは、ブロードキャストを介した受信に成功しない（ＦＥＣ復号に十分ではないシンボル）場合があり、その結果、ＵＣ−ＢＣ遷移が後で起こる可能性がある。第２に、ブロードキャストを介したＤＡＳＨセグメントの受信の成功は、最初のセグメント（Ｎ＋１）がブロードキャストを介して受信されるまで保証されない可能性がある。したがって、ＤＡＳＨクライアントは、ユニキャストを介してセグメントＮの取出しを完了し、ユニキャストを介してセグメントＮ＋１を取り出すことができる。第３に、ＤＡＳＨクライアントは、セグメントＮ＋２からのセグメントの取出しを遅延（ユニキャストを停止）することができ、セグメントのブロードキャスト配信に頼ることができる。第４に、図１６〜図１７を考慮すると、シームレスな遷移を達成することができ、セグメントＮ＋２は、ユニキャストを介して取り出されたように同じ時間で利用可能になり得る。すなわち、プレイバックをシームレスに進めることができる。したがって、シームレスなＵＣ−ＢＣ遷移は、プレイバックが１セグメントだけ遅延される場合（すなわち、１セグメントに設定されたｍｉｎＢｕｆｆｅｒＴｉｍｅによって）、実現することができる。状況に応じて、シームレスな遷移は、より大きいセグメント遅延を必要とする場合があり、より小さいセグメント遅延を必要とする場合もある。

図１８は、セグメントＮの受信がブロードキャストを介して取り出されている間にＢＣ−ＵＣ遷移が起こる時点を強調することによって、逆のＢＣ−ＵＣ遷移を示す。セグメントＮは、ブロードキャストを介した受信に成功しない（ＦＥＣ復号に十分ではないシンボル）場合があり、そのことが直ちに判定されない場合がある。セグメントＮが受信に成功しなかったことを判定すると、ＤＡＳＨクライアントは、ユニキャストを介してセグメントＮの取出しを開始して、連続プレイバックを保証することができる。ＤＡＳＨクライアントは、より低いデータレート表現に切り替えて巻き返す必要があり得る。

したがって、シームレスなＢＣ−ＵＣハンドオフは、セグメントＮがプレイバック用の時間内にユニキャストを介して取り出すことができる場合にのみ、達成可能であり得る。図１９の左のタイムラインが示すように、これは、ｍｉｎＢｕｆｆｅｒＴｉｍｅなどが１セグメントのみを規定する場合、実現可能ではない。ｍｉｎＢｕｆｆｅｒＴｉｍｅが２セグメントを規定すると（図１９の右のタイムライン参照）、ＤＡＳＨクライアントは、巻き返し、プレイバック途絶を回避するために１セグメントの時間を有する。したがって、ブロードキャストからユニキャストへのシームレスな遷移のために、ＤＡＳＨクライアントは、プレイバック前に３つ以上のセグメントを蓄積して、ユニキャストを介した巻き返しダウンロードに適応するように命令されるべきである。

関係する態様では、ＭＰＤの属性上の保護期間を含むとき、ＤＡＳＨクライアントは、プレイバック前に３つ以上のセグメントを蓄積するように命令される場合がある。したがって、ＭＰＤ内の既存のパラメータに保護期間を含めることの欠点は、さらなるセグメントアベイラビリティ調整であり得る。

ストリーミングサービスの所与の表現のブロードキャスト配信および関連するブロードキャストアベイラビリティ調整をシグナリングするためのセッション記述プロトコルの使用： いくつかの状況では、Ｒｅｐｒｅｓｅｎｔａｉｏｎのメディアセグメントのユニキャスト対ブロードキャストの配信モードを示すために、（たとえば、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性などを介して）ＭＰＤを直接使用することは望ましくない。たとえば、いくつかの実装形態では、ＤＡＳＨセグメントおよび関連するＭＰＤのネットワークベースの生成は、メディアコンテンツのトランスポート方法（ユニキャストおよび／またはブロードキャスト）に対して不可知論的であり得る。そのような場合、ユニキャスト対ブロードキャストの配信モードが（システム情報またはＳＩとも呼ばれる）サービス告知情報などを使用してシグナリングされることは、望ましい場合がある。

特に、３ＧＰＰのＭＢＭＳの場合、ＳＩまたはＵＳＤのコンポーネントは、セッション記述メタデータフラグメントなどであり得る。そのようなパラメータおよびシンタックスは、次に、ＩＥＴＦのＲＦＣ４５６６によって規定されたＳＤＰに基づくことができる。「属性」という用語または「ａ＝」は、ＳＤＰを拡張する主な方法であり、セッションレベルで（すなわち、ＦＬＵＴＥセッションのメディアコンポーネントに適用可能な）、またはセッション内の個別のメディアレベルで定義することができることに留意されたい。関係する態様では、属性フィールドは、たとえば、２つのフォームであり得る。関係する態様では、フォーム「ａ＝＜フラグ＞」の「プロパティ」属性があり、この場合、属性の存在は、属性がセッションのプロパティであることを示すにすぎない。さらなる関係する態様では、フォーム「ａ＝＜属性＞：＜値＞」の「値」属性があり、この場合、名前が付けられた属性の値は、任意のオクテット列などから構成される。

本明細書に記載された実施形態の態様によれば、関連するセッションのトランスポートモードを表記するために、新しいセッションレベルの属性「ａ＝＜ｒｅｐｒｅｓｅｎｔａｔｉｏｎ−ｔｒａｎｓｐｏｒｔ−ｍｏｄｅ＞」が提供される。この属性の定義された＜値＞サブフィールドは、対応するＲｅｐｒｅｓｅｎｔａｉｏｎなどのセグメントについて、ユニキャストのみ、ブロードキャストのみ、またはユニキャストとブロードキャストの両方の配信モードを指定する、テキスト列「ｕｎｉｃａｓｔ」、「ｂｒｏａｄｃａｓｔ」、または「ｂｏｔｈ」の間の選択であり得る。

さらに、セグメントのブロードキャスト配信は、ユニキャスト配信と比べて、「保護期間」とも呼ばれる、さらなる遅延に関連付けられる場合がある。そのようなパラメータは、新しいサブフィールド＜ｐｒｏｔｅｃｔｉｏｎ−ｐｅｒｉｏｄ＞などを介して、上記の「ｒｅｐｒｅｓｅｎｔａｔｉｏｎ−ｔｒａｎｓｐｏｒｔ−ｍｏｄｅ」属性に追加することができる。たとえば、「ｒｅｐｒｅｓｅｎｔａｔｉｏｎ−ｔｒａｎｓｐｏｒｔ−ｍｏｄｅ」属性のフルシンタックスは、次のようであり得る：

関係する態様では、ＵＳＤのＭＰＤフラグメント内のＲｅｐｒｅｓｅｎｔａｉｏｎの「ｉｄ」属性の値と同等である＜ｒｅｐｒｅｓｅｎｔａｔｉｏｎ−ｉｄ＞は、次の配信モードタグが適用される、Ｒｅｐｒｅｓｅｎｔａｉｏｎと関連するＤＡＳＨセグメントとを識別することができる。トランスポートモードが「ｂｒｏａｄｃａｓｔ」または「ｂｏｔｈ」である場合、サブフィールド＜ｐｒｏｔｅｃｔｉｏｎ−ｐｅｒｉｏｄ＞が現れることができ、そのＲｅｐｒｅｓｅｎｔａｉｏｎ用のブロードキャストアベイラビリティ調整を表す。

さらなる関係する態様では、サービス告知クライアントが上記の属性情報を使用して、ＭＰＤ内の対応するＲｅｐｒｅｓｅｎｔａｉｏｎ用の配信モード、ならびにブロードキャスト配信モード用の保護期間をＤＡＳＨクライアントに知らせることが予想される。

ＦＬＵＴＥセッションのブロードキャストアベイラビリティ調整をシグナリングするためのセッション記述プロトコルの使用： ブロードキャストアベイラビリティ調整をシグナリングするための上述された技法の代替形態は、トランスポートモードがＭＰＤのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を使用して宣言されるのに対して、セッション記述フラグメントを使用してブロードキャスト遅延をシグナリングすることである。この手法は、ＤＡＳＨからアベイラビリティ調整または保護期間情報を分離することの利益を有する。言い換えれば、ストリーミングサービスとしてのＤＡＳＨコンテンツのＦＬＵＴＥ配信に加えて、アプリケーションが配信されたコンテンツをより早く使用することを可能にするためにブロードキャストアベイラビリティ調整の知識が有用である、他のファイル配信サービスアプリケーションが存在する可能性がある。そのようなアプリケーションの例には、モバイル端末上のリアルタイムに近いバックグラウンド表示向けの動的なニュースまたは株のティッカ情報のブロードキャストが含まれる。そのようなアプリケーションの場合、ＦＬＵＴＥ配信に関連付けられたファイルは、符号化されたシンボルブロックの作成において重要な時間インターリービングを改善できる、アプリケーション層のＦＥＣ（たとえば、ＲａｐｔｏｒＱなど）によって保護することができる。一般的にセッション記述フラグメントを介したブロードキャストアベイラビリティ調整／保護期間の告知により、関連コンテンツのプレイバックをスケジューリングするときに、ＵＥがこの遅延を考慮に入れることが可能になるはずである。

ＳＤＰ内で保護期間をシグナリングするための技法は、たとえば以下に従って実装され得る：

サービス告知クライアント（すなわち、ブロードキャスト対応ＵＥの機能）が、関連コンテンツ配信モードのプレイバックをスケジューリングするときにこの遅延を考慮に入れるために、ブロードキャストアベイラビリティ調整のＵＥ内で他の機能を知らせることが予想される。ＤＡＳＨコンテンツのブロードキャスト配信の場合、そのようなクライアント機能は、ＤＡＳＨクライアントを含むことができる。

適切なＦＬＵＴＥセッションの決定： いくつかのブロードキャストＤＡＳＨサービスの場合、サービスの２つの代替表現を同時にブロードキャストすることが望ましい場合がある。たとえば、２つの表現はビデオ解像度が異なる場合がある。各解像度は、異なるデバイスタイプ、一方は小さい画面サイズ（たとえば、スマートフォン）、および他方は大きい画面サイズ（たとえば、タブレット）に適応することができる。これらの表現のうちの１つだけが、通常所与のデバイスによって消費／利用されるので、各表現は異なるトランスポートセッションを使用してブロードキャストすることができる。ｅＭＢＭＳブロードキャストの場合、表現は、図２０の実施形態で示された、異なるｅＭＢＭＳベアラチャネル内でトランスポートされた２つのＦＬＵＴＥセッションであり得る。

表現にＦＬＵＴＥセッションを関連付けることに関して、関連付けられたｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するブロードキャストＤＡＳＨサービス用のＭＰＤ内のＢａｓｅＵＲＬは、表現がブロードキャストを介して利用可能であることを示す「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むことができる。表現のための適切なブロードキャスト・トランスポートセッション（たとえば、ｅＭＢＭＳ内のＦＬＵＴＥセッション）をシグナリングするために、次のように追加の文字列フォーマットをｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内でトランスポートすることができる。

第１の態様では、ＵＲＮフォーマットを使用するとき、表現のためのＢａｓｅＵＲＬについてのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる文字列を含むことができ、表現がブロードキャストを介して利用可能であることを示す「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかを含むことができる。第２の態様では、（キー＝値のペアのフォーマットの）文字列「：ｆｌｕｔｅ＝」＋ｓｏｕｒｃｅＩＰＡｄｄＶａｌｕｅ＋「＋」＋ｔｓｉＶａｌｕｅは、ｓｏｕｒｃｅＩＰＡｄｄＶａｌｕｅおよびｔｓｉＶａｌｕｅを介して、一緒にＦＬＵＴＥセッションを一意に識別するソースＩＰアドレスとＴＳＩとをシグナリングすることができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ：ｆｌｕｔｅ＝１９８．１５２．３９．１０＋４５６７などであり得る。

第３の態様では、（キー＝値のペアのフォーマットの）代替の文字列「：ｆｌｕｔｅＳＤＰ＝」＋ｓｄｐＵＲＬＶａｌｕｅは、ｓｄｐＵＲＬＶａｌｕｅを介して、ブロードキャストサービス用に定義されたＦＬＵＴＥセッションのうちの１つを識別するＵＲＬをシグナリングすることができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ：ｆｌｕｔｅＳＤＰ＝ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅＸ／ｓｅｒｖｉｃｅ．ｓｄｐなどであり得る。第４の態様では、ＦＬＵＴＥセッションとは異なるトランスポートセッションを記述するために他の文字列を定義することができる。

サンプルのＤＡＳＨクライアントの挙動に関して、ＭＰＤにおいてシグナリングされたＤＡＳＨセグメントのブロードキャストアベイラビリティおよびＦＬＵＴＥセッションの表現へのマッピングに関する情報に基づいて、ＤＡＳＨクライアントの実装形態は、次のようにブロードキャストカバレージ中の受信用のＢａｓｅＵＲＬ上のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報を使用することができる。第１の態様では、ＤＡＳＨクライアントは、メディア記述情報（たとえば、画面解像度）に基づいて、望ましい表現を選択することができる。第２の態様では、ＤＡＳＨクライアントは、たとえば、これらの表現用のＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報が「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むとき、マルチプルな表現がブロードキャストを介して利用可能であることを検出することができる。第３の態様では、ＤＡＳＨクライアントは、ブロードキャストカバレージの中にいることを検出すると、選択された表現に関連付けられた、「：ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択することができる。第４の態様では、ＤＡＳＨクライアントは、選択されたＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内の「ｆｌｕｔｅ＝」または「ｆｌｕｔｅＳＤＰ＝」を含む文字列によって識別された（ｅＭＢＭＳの場合の）ＦＬＵＴＥセッションを介して、ブロードキャストを介したセグメントの受信を起こさせることができる。第５の態様では、ＤＡＳＨクライアントは、選択されたＢａｓｅＵＲＬを使用するＭＰＤ内のセグメントアベイラビリティタイムラインに従ってセグメント取出しを実行することができる。

オンデマンドサービスのためのＵＣ−ＢＣのＵＲＬのシグナリング： ブロードキャストシステムは、ユニキャスト受信を介していくつかのＤＡＳＨコンテンツにアクセスするマルチプルなユーザによるシステムリソースの使用を低減する方法として、ブロードキャストＤＡＳＨサービスオンデマンドの定義をサポートすることができる。いくつかの状況では、ユニキャストＤＡＳＨコンテンツを消費するユーザデバイスを、同じコンテンツをトランスポートするブロードキャストＤＡＳＨサービスにリダイレクトすることが必要であり得る。このリダイレクションプロセスは、ＨＴＴＰリダイレクション機能を使用して、ユーザデバイスに、元の要求に使用されたＵＲＬとは異なるＵＲＬを使用する望ましいセグメントを再要求させることができる。これらのリダイレクトされたＵＲＬの使用は、ユニキャストを介して取り出されている同じコンテンツ用の新しいブロードキャストＤＡＳＨサービスのアベイラビリティをユーザデバイスが判定するトリガとして働くことができる。

ユニキャストからブロードキャストの受信用のセグメントＵＲＬを識別することに関して、文字列「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性に関連付けられたブロードキャストＤＡＳＨサービス用のＭＰＤ内のＢａｓｅＵＲＬは、表現がユニキャストを介して利用可能であることを示す。いくつかのユニキャストＵＲＬがリダイレクション手法をサポートするようにのみ意図されたことをさらに示すために、追加の文字列フォーマットを、リダイレクションに使用されるＵＲＬを識別するために、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内でトランスポートすることもできる。より具体的には、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、ｕｒｎフォーマットを使用するとき、「ｕｒｎ：３ｇｐｐ：ｓｌ」で始まる文字列を含むことができ、サービスがユニキャストを介して利用可能であることを示すために、文字列「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」を含むことができる。また、（キー＝値のペアのフォーマットの）文字列「：ｔｒａｎｓｉｔｉｏｎ＝」＋ｔｒａｎｓＶａｌｕｅは、ｔｒａｎｓＶａｌｕｅがＵＣ−ＢＣまたはＢＣ−ＵＣのいずれかであり得る場合、ＵＲＬがリダイレクション技法をサポートするようにのみ意図されたことを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、ｕｒｎ：３ｇｐｐ：ｓｌ：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ：ｔｒａｎｓｉｔｉｏｎ＝ＵＣ−ＢＣなどであり得る。

サンプルのＤＡＳＨクライアントの挙動に関して、ユニキャストを介して利用可能なＤＡＳＨコンテンツがブロードキャストを介しても利用可能にされてユニキャストトラフィックをオフロードするとき、コンテンツ用の関連するＭＰＤは、コンテンツのブロードキャストアベイラビリティとユニキャストアベイラビリティとをシグナリングすることができる。遷移ＵＲＬに関する情報はまた、遷移リダイレクションに使用されるべきＵＲＬを識別するために存在することができる。遷移リダイレクションの場合、ＤＡＳＨクライアントの実装形態は、以下で説明されるようにＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ情報の使用することを含むことができる。

第１の態様では、ＤＡＳＨクライアントが、（ａ）セグメントを取り出すために利用可能な帯域幅を決定し、再生すべき表現を選択し、（ｂ）文字列「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」と「：ｔｒａｎｓｉｔｉｏｎ＝」とを含むＢａｓｅＵＲＬを除き、「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」または「：ｔｒａｎｓｐｏｒｔ＝ｂｏｔｈ」のいずれかの文字列を含むｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を有するＢａｓｅＵＲＬを選択し、かつ／または（ｃ）選択されたＢａｓｅＵＲＬを使用して通常のＤＡＳＨクライアントの挙動に従ってセグメント取出しを実行する場合、ＤＡＳＨクライアントは、ＤＡＳＨコンテンツのユニキャスト受信を開始することができる。

第２の態様では、ユニキャストを介してコンテンツを消費する間、ブロードキャストサービスアベイラビリティのシグナリング（すなわち、ユニキャストからブロードキャストへの遷移の指示）が存在する場合がある。ユニキャストを介してＤＡＳＨコンテンツを受信するＤＡＳＨクライアントは、別のＵＲＬへのＨＴＴＰリダイレクションを得ることができる。ＤＡＳＨクライアントは、次いで、（ａ）対応するｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性が文字列「：ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ」と「：ｔｒａｎｓｉｔｉｏｎ＝ＵＣ−ＢＣ」とを含む場合、リダイレクトされたＵＲＬが同じ表現についてのＭＰＤのＢａｓｅＵＲＬと一致するかどうかを評価し、（ｂ）そのような一致がある場合、遷移を実施し、かつ／または（ｃ）コンテンツのブロードキャストバージョンのアベイラビリティが判定され得るまで、リダイレクトされたＵＲＬからセグメントを取り出し続ける。

カンマ区切りの文字列を介したパラメータの伝達： 本明細書に記載された様々なパラメータは、例示目的で、かつ限定ではなく、ＵＲＮフォーマットを使用して符号化されている。代替として、カンマ区切りの文字列を使用することができる。一実施形態では、カンマ区切りの文字列を次のように実装することができる。ＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内でトランスポートされるべき最初の文字列は、「３ｇｐｐ−ｓｌ」などであり得る。その後の文字列は、「，」で始まる最初の文字列に連結され、キー＝値のペアを提供する文字列などがその後に続くことができる。

２番目の文字列（または最初のキー＝値のペア）は、「，ｔｒａｎｓｐｏｒｔ＝」＋値の文字列などであり得る。可能な値の文字列は、「ｂｒｏａｄｃａｓｔ」、「ｕｎｉｃａｓｔ」、「ｂｏｔｈ」であり得る。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔまたは３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔであり得る。

関係する態様では、ユニキャストを介してブロードキャストＤＡＳＨサービスの地理的アベイラビリティをシグナリングするために、（キー＝値のペアのフォーマットの）文字列「，ｕＧｅｏ３ＧｐｐＣｅｌｌＩＤ＝」＋ＣｅｌｌＩＤ文字列は、ＣｅｌｌＩＤ文字列を介して、サービスがユニキャストを介して消費され得る３ＧＰＰのセルＩＤを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ，ｕＧｅｏ３ＧｐｐＣｅｌｌＩＤ＝３４５６９０などであり得る。

（キー＝値のペアのフォーマットの）文字列「，ｕＧｅｏ３Ｇｐｐ２Ｓ＋Ｎ＋Ｚ＝」＋ＳＩＤ＿ｖａｌｕｅ＋「＋」＋ＮＩＤ＿ｖａｌｕｅ＋「＋」＋ＰＺＩＤ＿ｖａｌｕｅは、ＳＩＤ、ＮＩＤ、ＰＺＩＤ、および「＋」の文字列の連結を介して、サービスがユニキャストを介して消費され得る３ＧＰＰ２のセルＩＤを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ，ｕＧｅｏ３Ｇｐｐ２Ｓ＋Ｎ＋Ｚ＝２３＋３４＋４５などであり得る。

デバイスに対して利用可能であり得る他の地理的記述子を取り込むために、他の文字列を定義することができる。

さらなる関係する態様では、（キー＝値のペアのフォーマットの）文字列「，ｐｐ＝」＋ｐｐＶａｌｕｅは、ｐｐＶａｌｕｅを介して、ミリ秒保護期間をシグナリングして、ＤＡＳＨクライアントがブロードキャストカバレージの中にいる間、セグメントを要求したときに対応される。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ，ｐｐ＝５０などであり得る。

さらなる関係する態様では、表現についての適切なブロードキャストトランスポートセッションをシグナリングするために、（キー＝値のペアのフォーマットの）文字列「，ｆｌｕｔｅ＝」＋ｓｏｕｒｃｅＩＰＡｄｄＶａｌｕｅ＋「＋」＋ｔｓｉＶａｌｕｅは、ｓｏｕｒｃｅＩＰＡｄｄＶａｌｕｅおよびｔｓｉＶａｌｕｅを介して、一緒にＦＬＵＴＥセッションを一意に識別するソースＩＰアドレスとＴＳＩとをシグナリングすることができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ，ｆｌｕｔｅ＝１９８．１５２．３９．１０＋４５６７などであり得る。

（キー＝値のペアのフォーマットの）代替の文字列「，ｆｌｕｔｅＳＤＰ＝」＋ｓｄｐＵＲＬＶａｌｕｅは、ｓｄｐＵＲＬＶａｌｕｅを介して、ブロードキャストサービス用に定義されたＦＬＵＴＥセッションのうちの１つを識別するＵＲＬをシグナリングすることができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｂｒｏａｄｃａｓｔ，ｆｌｕｔｅＳＤＰ＝ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｓｅｒｖｉｃｅＸ／ｓｅｒｖｉｃｅ．ｓｄｐなどであり得る。

ＦＬＵＴＥセッションとは異なるトランスポートセッションを記述するために他の文字列を定義することができる。

さらなる関係する態様では、（キー＝値のペアのフォーマットの）文字列「，ｔｒａｎｓｉｔｉｏｎ＝」＋ｔｒａｎｓＶａｌｕｅは、ｔｒａｎｓＶａｌｕｅがＵＣ−ＢＣまたはＢＣ−ＵＣのいずれかであり得る場合、ＵＲＬがリダイレクション技法をサポートするようにのみ意図されたことを示すことができる。ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性用の例示的な文字列は、３ｇｐｐ−ｓｌ，ｔｒａｎｓｐｏｒｔ＝ｕｎｉｃａｓｔ，ｔｒａｎｓｉｔｉｏｎ＝ＵＣ−ＢＣなどであり得る。

ＸＭＬ文字列を介したパラメータの伝達： ＢａｓｅＵＲＬのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内のトランスポート用のここまで記載された様々なパラメータを符号化するさらに別の方法は、ＸＭＬファイルを介することである。これらのパラメータ用のＸＭＬ構造は、単一サービス用のマルチプルなブロードキャスト送信を示す図２１の例で示されたように、ＸＭＬスキーマ上で取り込むことができる。

一実施形態では、トランスポートのタイプをシグナリングするために、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は次のようであり得る。ブロードキャストタイプの場合、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、以下であり得る：

ユニキャストタイプの場合、ｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性は、以下であり得る：

別の実施形態では、ユニキャストを介してブロードキャストＤＡＳＨサービスの地理的アベイラビリティをシグナリングするために、以下が適用される。

３ＧＰＰのセルＩＤを使用する：

３ＧＰＰ２のセルＩＤを使用する：

さらに別の実施形態では、保護期間をシグナリングするために、以下が適用される：

さらに別の実施形態では、表現についての適切なブロードキャスト・トランスポートセッションをシグナリングするために、以下が適用される：

さらに別の実施形態では、オンデマンドＤＡＳＨサービスに使用されるＵＲＬをシグナリングするために、以下が適用される：

ブロードキャストトランスポートモードおよび／またはブロードキャストアベイラビリティ調整を宣言するためのオプション： 本開示の主題の態様によれば、ＭＰＤを使用して、ＤＡＳＨセグメントのトランスポートモード、ならびに、それらの同じセグメントのユニキャスト配信に対して、ブロードキャストを介して配信されるメディアセグメントのアベイラビリティにおけるアベイラビリティ調整を宣言するための他のオプションが提供される。上述された１つの手法は、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報に関する、そのようなメタデータをトランスポートするためのｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を使用することを含む。上述された別の手法は、ＳＤＰファイルなどを介して、ＭＢＭＳサービス告知情報のセッション記述を使用して、トランスポートモードおよび配信アベイラビリティ調整の情報を提供することを含む。

代替または追加として、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報は、ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎなどの名前の新しいＭＰＤ要素内でシグナリングすることができる。たとえば、ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎは、（たとえば、ＭＰＥＧ ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）規格または３ＧＰ−ＤＡＳＨ（３ＧＰＰ ＴＳ２６．２４７）規格によって定義された）汎用記述子要素のタイプを表し、ＭＰＤ内で記述されたＲｅｐｒｅｓｅｎｔａｉｏｎ用の送信およびアクセス関連の情報の容器として働くことができる。そのような送信およびアクセスの情報の例には、ｉ）送信トポロジー（ユニキャスト、ブロードキャスト、または両方）、ｉｉ）特定タイプのブロードキャスト技法（たとえば、セルラーＭＢＭＳオーバーＧＥＲＡＮ、ＵＴＲＡＮ、もしくはＬＴＥ）、地上放送ＴＶシステム（たとえば、ＡＴＳＣ、ＩＳＤＢ−Ｔ、Ｔ−ＤＭＢ、ＣＭＭＢ、もしくはＤＶＢ−Ｔ）、または衛星ＴＶ放送技術（たとえば、ＤＶＢ−ＳもしくはＳ−ＤＭＢ）、ｉｉｉ）アクセス技術に固有の情報に関するサービス告知／発見に対する参照、およびｉＶ）ユニキャスト配信のセグメントアベイラビリティに対するセグメントアベイラビリティのブロードキャスト配信固有のアベイラビリティ調整が含まれ得る。ブロードキャスト固有のアベイラビリティ調整は、ユニキャストセグメント利用可能時間に追加されるべき時間遅延値を提供することによって、ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅを増加させることができる。得られた値（ユニキャストセグメント利用可能時間＋ブロードキャスト遅延値）は、ブロードキャストセグメント利用可能時間を表す。

代替または追加として、トランスポートモードおよびブロードキャストアベイラビリティ調整の情報は、ＭＰＤ内のＢａｓｅＵＲＬ要素の下の新しい拡張パラメータによってシグナリングされることができる。新しい拡張パラメータは、ＭＢＭＳ配信を示し、さらにブロードキャストアベイラビリティ調整を告知する、子要素または子属性ｂｒｏａｄｃａｓｔＤｅｌｉｖｅｒｙを含むことができる。新しい拡張パラメータは、Ｒｅｐｒｅｓｅｎｔａｉｏｎ要素などのＢａｓｅＵＲＬの子要素の下に現れることができる。この手法は、メディアプレゼンテーションの個別のＲｅｐｒｅｓｅｎｔａｉｏｎがブロードキャスト配信に利用可能かどうかの指示を提供するはずであり、任意の様々な待ち時間の指示も提供するはずである。

ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎは、サービス告知情報へのエントリポイントを提供するためにのみ定義できることに留意されたい。アベイラビリティ調整パラメータは、ＭＰＤのＢａｓｅＵＲＬ要素に移動させることができる。関係する態様では、ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎ要素がブロードキャスト・トランスポートのケースで示されたアクセス固有のパラメータを表現するために使用されるとき、送信およびアクセスの関連情報は、技術（たとえば、セルラー、地上ＴＶ、衛星ＴＶなど）を明示的に識別することができる。ブロードキャスト技術は、アクセス固有のパラメータなどをトランスポートするためのＢａｓｅＵＲＬ要素を拡張することによって、識別することができる。さらなる関係する態様では、Ｔｒａｎｓｐｏｒｔ記述子は、たとえば、ＭＰＤの様々な階層レベル、たとえば、最上位ＭＰＤ要素レベル、またはＭＰＤの子要素（たとえば、Ｐｅｒｉｏｄ、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎなど）の下に置くことができる。ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎ要素はＢａｓｅＵＲＬのピア要素であり得るか、またはＳｅｇｍｅｎｔＢａｓｅのピア要素であり得ることに留意されたい。

関係する態様では、各セグメントは異なるネットワークを介して配信することができるので、Ｔｒａｎｓｐｏｒｔ記述子（すなわち、ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎ要素）は、ＭＰＤ内で宣言された個別のセグメントに対処することが可能であり得る。さらなる関係する態様では、Ｔｒａｎｓｐｏｒｔ記述子はＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルで定義することができる。たとえば、Ｔｒａｎｓｐｏｒｔ記述子は、Ｐｅｒｉｏｄレベル、ＡｄａｐｔａｔｉｏｎＳｅｔレベル、および／またはＲｅｐｒｅｓｅｎｔａｔｉｏｎレベルで追加され得るように、以下の要素に追加することができる：（ａ）次いで柔軟に使用することができるＢａｓｅＵＲＬ要素、および／または（ｂ）（たとえば、ＢａｓｅＵＲＬが存在しないときの）ＳｅｇｍｅｎｔＢａｓｅ要素。

関係する態様では、Ｔｒａｎｓｐｏｒｔ記述子の属性ｓｃｈｅｍｅＩｄＵｒｉによって表されるＴｒａｎｓｐｏｒｔ記述子アクセス方式は、ＤＡＳＨクライアント、デバイスミドルウェア、または他のＵＥ機能がこの機能を解釈して、ネットワークスタックがこのトランスポート方式をサポートするかどうかを判定することができるように、構築することができる。Ｔｒａｎｓｐｏｒｔ記述子内の関連付けられた値は、サービス告知へのトランスポートに対する一意のエントリポイントを提供することができる。たとえば、関連付けられた値は、サービス告知ドキュメントへのｓｅｒｖｉｃｅＩＤまたはＵＲＬであり得る。

関係する態様では、ＭＢＭＳの場合、Ｔｒａｎｓｐｏｒｔ記述子の値は、（たとえば、ＵＲＬ内のフラグメントとしてコード化された）ｓｅｒｖｉｃｅＩＤも含むユーザサービスバンドルドキュメント／フラグメントへのＵＲＬであり得る。Ｔｒａｎｓｐｏｒｔ記述子の値は、参加されるべきＦＬＵＴＥセッションに関する固有情報を含むことができる。代替または追加として、サービスおよびアクセスの発見情報へのＵＲＬは、ＨＴＴＰなどを介したウェブページ上で利用可能にすることもできる。この場合、ブロードキャスト／マルチキャストのリンク用のユーザサービスバンドル記述ドキュメントとしてＵＲＬによってリンクされたドキュメントを識別するコンテンツタイプを定義することができる。

表現のブロードキャストおよび／またはユニキャストアベイラビリティのシグナリング： 本明細書に記載された実施形態の１つまたは複数の態様によれば、ブロードキャストワイヤレスシステム内のメディアデータセグメントの表現のブロードキャストアベイラビリティおよび／またはユニキャストアベイラビリティをシグナリングするための技法が提供される。図１０Ｂを参照すると、ｅＭＢＭＳサービス用のシステム情報を含む例示的なＵＳＤが示される。ＵＳＤは、ブロードキャスト、ユニキャスト、または両方を介した表現のアベイラビリティを記述するように拡張されている。

図１０Ｂが示すように、更新されたｍｅｄｉａ−Ｐｒｅｓｅｎｔａｔｉｏｎ−Ｄｅｓｃｒｉｐｔｉｏｎ−２要素の存在は、ｍｐｄＵＲＩ要素がリンクを提供してＤＡＳＨサービスに関連付けられたＭＰＤを識別する場合、ＵＳＤが記述するサービスがＤＡＳＨ ｅＭＢＭＳサービスであることを示す。

更新されたｍｅｄｉａ−Ｐｒｅｓｅｎｔａｔｉｏｎ−Ｄｅｓｃｒｉｐｔｉｏｎ−２要素はまた、ブロードキャスト表現とユニキャスト表現とを識別するｂｒｏａｄｃａｓｔ−Ｒｅｐｒｅｓｅｎｔａｉｏｎ要素およびｕｎｉｃａｓｔ−Ｒｅｐｒｅｓｅｎｔａｉｏｎ要素のリストを提供する。両方のリストで識別された表現は、ユニキャストおよびブロードキャストを介して利用可能である。

いずれかのリスト内の表現は、ｐｅｒｉｏｄＩｄ属性を介した期間により、ａｄａｐｔａｔｉｏｎＳｅｔＩｄ属性を介した適合セットにより、かつ／または、ｒｅｐｒｅｓｅｎｔａｉｏｎＩｄ属性を介した表現により、ＭＰＤ内で識別されたそれぞれの値への参照として識別することができる。ブロードキャスト表現はまた、所与のブロードキャストエリア内でどの表現が利用可能であるかを、ブロードキャストコンポーネントが判定することを可能にする、ｓｅｒｖｉｃｅＡｒｅａ情報と関連付けることができる。

ブロードキャストサービスはまた、マルチプルなトランスポートストリームを含むことができるので、ブロードキャストＤＡＳＨサービスは、別々のトランスポートストリームを介してトランスポートされている様々な表現を有することができる。これは、様々なデバイス能力を対象にする様々な解像度、または様々なユーザ選好を対象にする様々な言語を提供するように行われる可能性がある。

例示的なブロードキャストクライアントの挙動では、ｅＭＢＭＳのＤＡＳＨサービス用のＵＳＤ内でシグナリングされるＤＡＳＨ表現のブロードキャストおよび／またはユニキャストのアベイラビリティに基づいて、ブロードキャストｅＭＢＭＳクライアントは、デバイスがいつブロードキャストカバレージに出入りするかを知り、かつ／または、図１０Ｂが示すようなシステム情報（たとえば、ｅＭＢＭＳ内のＵＳＤ）に従って、ＭＰＤ内のＤＡＳＨ表現のうちのどれがブロードキャストサービスを介して利用可能であり、どれがユニキャストを介して利用可能であるかを知ることが可能であり得る。関係する態様では、ブロードキャストカバレージ状態に応じて、ブロードキャストクライアントは、デバイスがブロードキャストカバレージに入ると利用可能なブロードキャスト表現のうちの１つを選択するようにクライアントにシグナリングし、かつ／またはデバイスがブロードキャストカバレージから出ると利用可能なユニキャスト表現のうちの１つを選択するようにＤＡＳＨクライアントにシグナリングすることができる。さらなる関係する態様では、ＤＡＳＨクライアントのブロードキャスト表現の選択に応じて、ブロードキャストクライアントは、選択された表現をトランスポートするＦＬＵＴＥセッションの受信をアクティブ化することができる。

属性ａｖａｉｌａｂｉｌｉｔｙＴｉｍｅＡｄｊｕｓｔｍｅｎｔは、存在する場合、ＭＰＤフラグメント（すなわち、ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）内で宣言され、正または負のいずれかの値であり得るセグメント利用可能開始時刻に対する表現のブロードキャスト受信の調整を指定する。正（負）の値は、Ｒｅｐｒｅｓｅｎｔａｉｏｎのセグメントの利用可能時刻が、該当する場合、ユニキャストを介して配信されるメディアプレゼンテーションの任意のＲｅｐｒｅｓｅｎｔａｉｏｎの利用可能時刻よりも後（前）であることを意味する。ｓｅｒｖｉｃｅＡｒｅａ要素およびｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎ要素は、存在する場合、それぞれ、それを介したＲｅｐｒｅｓｅｎｔａｉｏｎが利用可能であるサービスエリアと、そのＲｅｐｒｅｓｅｎｔａｉｏｎをトランスポートするＦＬＵＴＥセッションとを表記する。ｕｎｉｃａｓｔＲｅｐｒｅｓｅｎｔａｉｏｎ要素は、存在する場合、フォールバック配信用にユニキャストを介して供給される各Ｒｅｐｒｅｓｅｎｔａｉｏｎを識別する。ユニキャスト配信されたＲｅｐｒｅｓｅｎｔａｉｏｎは、ＭＢＭＳベアラも介して配信された同じ表現であり得るか、またはユニキャストベアラのみを介して配信されたＲｅｐｒｅｓｅｎｔａｉｏｎであり得る。

本明細書で図示および記載された例示的なシステムに鑑みて、開示された主題に従って実装され得る方法は、様々なフローチャートを参照してより良く理解されよう。説明を簡単にするために、方法が一連の行為／ブロックとして図示および記載されるが、いくつかのブロックは、本明細書で描写および記載された順序とは異なる順序で、かつ／または他のブロックと実質的に同時に行われ得るので、請求された主題はブロックの数または順序によって限定されないことを理解し、諒解されたい。その上、本明細書に記載された方法を実施するために、図示されたすべてのブロックが必要とされるとは限らない。ブロックに関連する機能は、ソフトウェア、ハードウェア、それらの組合せ、または任意の他の適切な手段（たとえば、デバイス、システム、プロセス、もしくはコンポーネント）によって実装され得ることを理解されたい。加えて、本明細書の全体にわたって開示された方法は、そのような方法を様々なデバイスに移送および転送することを容易にする製品に記憶することが可能であることをさらに諒解されたい。方法は、代替的に、状態図などの一連の相互に関係する状態または事象として表現され得ることを、当業者は理解し、諒解するであろう。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２２Ａを参照すると、モバイルエンティティ（たとえば、ＵＥなど）によって動作可能な方法２２００が示される。方法２２００は、２２１０で、ＭＰＤを受信することを含むことができ、ＭＰＤは、（たとえば、ファイル配信セッションのアクティブ化に応答して、）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータを備える。ユニキャストの場合、データはＨＴＴＰサーバまたは「クラウド内」に存在することができるのに対して、ブロードキャストの場合、データはＵＥのＨＴＴＰキャッシュにローカルに存在することができることに留意されたい。方法２２００は、２２２０で、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法２２００は、２２３０で、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法２２００は、２２４０で、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現についてのデータセグメントを受信することを含むことができる。

図２２Ｂ〜図２２Ｄを参照すると、オプションであり、モバイルエンティティなどによって実行され得る方法２２００のさらなる動作または態様が示される。方法２２００が図２２Ｂまたは図２２Ｃの少なくとも１つのブロックを含む場合、方法２２００は、図示された後続のダウンストリームブロックを必ずしも含む必要なしに、少なくとも１つのブロックの後で終了することができる。ブロックの参照番号は、ブロックが方法２２００に従って実行され得る特定の順序を意味しないことに、さらに留意されたい。たとえば、モバイルエンティティは、ブロードキャストモバイルシステム上で動作することができ、ブロードキャストＤＡＳＨサービスは、ＭＰＤを含むシステム情報メタデータを介して定義することができ、方法は、ブロードキャストＤＡＳＨサービスの代替的な配信がユニキャスト送信を介して利用可能であるかどうかを、ＭＰＤ内のパラメータから判定することを含むことができる（ブロック２２５０）。

方法２２００は、モバイルエンティティの現在の位置におけるブロードキャスト送信のアベイラビリティを判定すること（ブロック２２５２）と、ブロードキャスト送信のアベイラビリティがない場合、ブロードキャスト送信の代替としてユニキャスト送信のアベイラビリティを判定すること（ブロック２２５４）とを含むことができる。

基準は、表示解像能力（display resolution capabilities）、言語能力（language capabilities）、モバイルエンティティのワイヤレスネットワーク互換性、または表現の帯域幅要件をサポートするためのワイヤレスチャネルアベイラビリティのうちの少なくとも１つを含むことができる（ブロック２２５６）。所与の表現に関連付けられたブロードキャストファイル配信セッションについての情報は、メディアセグメントの受信用のブロードキャストファイル配信セッションをアクティブ化するために使用される（ブロック２２５８）。

方法２２００は、現在のブロードキャストサービスエリア内で受信され得る、利用可能なブロードキャスト表現の中から選択することによって、ブロードキャスト受信用の表現を選択すること（ブロック２２６０）を含むことができる。

方法２２００は、現在のユニキャストサービスエリア内で受信され得る、代替配信に利用可能なユニキャスト表現の中から選択することによって、ユニキャスト受信用の表現を選択すること（ブロック２２６２）を含むことができる。

図２２Ｃを参照すると、受信すること（ブロック２２４０）は、所与の表現についての待ち時間調整期間により、表現のデータセグメントについてのアベイラビリティタイムラインを調整すること（ブロック２２６４）を含むことができる。

受信すること（ブロック２２４０）は、それらそれぞれの待ち時間調整期間によって定義された表現についてのアベイラビリティタイムラインの差を考慮すること（ブロック２２６６）と、データセグメントへのアクセスに影響するブロードキャスト送信およびユニキャスト送信の特性を考慮すること（ブロック２２６８）と、コンテンツのそれぞれの表現についてユニキャスト送信を介した受信とブロードキャスト送信を介した受信との間のシームレスな遷移を達成するためにデータセグメントのバッファリングを調整すること（ブロック２２７０）とを含むことができる。

待ち時間期間の調整は、ユニキャスト送信に対する、ブロードキャスト送信を介した所与の表現についてのデータセグメントのアベイラビリティにおける時間遅延（time delay）または時間前進（time advance）を示すことができる（ブロック２２７２）。たとえば、パラメータは、データセグメントのユニキャスト配信に対する、データセグメントのブロードキャスト配信用のアベイラビリティ調整を示すことができる。たとえば、パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントのアベイラビリティにおける予想される時間遅延を示すことができる。代替として、パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントのアベイラビリティにおける予想される時間前進を示すことができる。

パラメータは、データセグメントの（ａ）ユニキャストのみ、（ｂ）ブロードキャストのみ、または（ｃ）ユニキャストとブロードキャストの両方のアベイラビリティを示すことができる（ブロック２２７４）。パラメータのうちの少なくとも１つは、データセグメントの（ｂ）ブロードキャストのみ、または（ｃ）ユニキャストとブロードキャストの両方のアベイラビリティに関係し、ブロードキャスト分配技術を識別する（ブロック２２７６）。たとえば、少なくとも１つのブロードキャスト分配技術は、たとえば、ａ）セルラーブロードキャスト技術、ｂ）地上放送ＴＶシステム、またはｃ）衛星ＴＶ放送技術などの、ＩＰベースのブロードキャストシステムに対応することができる。

図２２Ｄを参照すると、パラメータは、いくつかの識別されたブロードキャストサービスエリア内のブロードキャスト表現のアベイラビリティに関する情報を含む（ブロック２２７８）。

データセグメントは、ＤＡＳＨメディアセグメントなどであり得るし（ブロック２２８０）、方法２２００は、ブロードキャスト送信からユニキャスト送信に、またはその逆に変化するメディアセグメントの受信に応答して、メディアセグメントのシームレスなプレイバックを達成するためにメディアセグメントを蓄積すること（ブロック２２８２）をさらに含むことができる。パラメータは、ＭＰＤ内の拡張要素ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎなどの１つまたは複数のインスタンスにおいて符号化されることができる（ブロック２２８４）。パラメータは、ブロードキャストコンテンツの特定の表現のためのＦＬＵＴＥセッション識別子などを含み得る（ブロック２２８６）。

関係する態様では、判定すること（ブロック２２２０）は、ユニキャスト取出しがデータセグメントの受信に適することを判定することを含むことができる。パラメータは、ユニキャスト取出し用のデータセグメントの地理的アベイラビリティを示すことができる。さらなる関係する態様では、パラメータは、コンテンツ用のＭＰＤ内のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性を介して、コンテンツのオンデマンドブロードキャストバージョンへのユニキャストＤＡＳＨアクセスを指示するための情報を備えることができる。

さらなる関係する態様では、パラメータは、ＭＰＤのＢａｓｅＵＲＬ内で符号化することができる。パラメータは、登録されたＮＩＤの下のＵＲＮを備えることができる。パラメータは、ＢａｓｅＵＲＬ内のｓｅｒｖｉｃｅＬｏｃａｔｉｏｎ属性内の文字列としてトランスポートされた、キー＝値のペアのコロン区切りのリストを含む、ＵＲＮの名前空間固有文字列（ＮＳＳ）を備えることができる。パラメータは、所与のデータストリーム用の代替形態を提供するＤＡＳＨ表現に関することができる。

さらなる関係する態様では、パラメータは、ＭＰＤの下の拡張要素ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎの１つまたは複数のインスタンス内で符号化することができる。ＭＰＤの下の拡張要素ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎは、ＭＰＤデータ構造の以下の様々な階層レベルのうちの１つまたは複数の中に存在することができる：ＭＰＤ要素、Ｐｅｒｉｏｄ要素、ＡｄａｐｔａｔｉｏｎＳｅｔ要素、およびＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素。ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎは、汎用記述子要素のタイプであり得るし、ＭＰＤ内で記述されたＲｅｐｒｅｓｅｎｔａｔｉｏｎ用の送信およびアクセスの関連情報を含むことができる。ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎの各インスタンス内でトランスポートされる送信およびアクセスの関連情報は、少なくとも１つの送信トポロジー：ａ）ユニキャスト、ｂ）ブロードキャスト、またはｃ）ユニキャストとブロードキャストの両方を示すことができる。

送信トポロジーがブロードキャスト、またはブロードキャストとユニキャストの両方として示された場合、送信およびアクセスの関連情報は、ａ）セルラーブロードキャスト技術、ｂ）地上放送ＴＶシステム、またはｃ）衛星ＴＶ放送技術の特定タイプのうちの１つを示すことができる。送信およびアクセスの関連情報は、ブロードキャスト技術についてのサービス告知／発見情報にアクセスするためのエントリポイント情報を示すことができる。ブロードキャスト技術についてのサービス告知／発見情報にアクセスするためのエントリポイント情報に加えて、送信およびアクセスの関連情報は、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントの予想されるアベイラビリティ調整を示すことができる。データセグメントのユニキャスト配信を介した利用可能時間は、ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅの値によって表すことができるか、またはそれから導出することができる。

関係する態様では、パラメータは、ＭＰＤ内のＢａｓｅＵＲＬ要素の少なくとも１つのインスタンスの下の１つまたは複数の拡張パラメータ内で符号化することができる。ＢａｓｅＵＲＬ要素の１つまたは複数のインスタンスの各々の中のパラメータは、ユニキャストまたはブロードキャストのトランスポートモードを示すことができる。トランスポートモードがブロードキャストとして示された場合、関連するパラメータは、ａ）セルラーブロードキャスト技術、ｂ）地上放送ＴＶシステム、またはｃ）衛星ＴＶ放送技術の特定タイプのうちの１つのブロードキャスト分配技術の明示的な識別を可能にすることができる。パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、ブロードキャスト配信されたデータセグメントの予想されるアベイラビリティ調整を示すことができる。パラメータは、メディアプレゼンテーションの個別の表現がブロードキャスト配信に利用可能であるかどうかを示すことができる。トランスポートモードがユニキャストとして示された場合、関連するパラメータは、コンテンツ配信ネットワーク（ＣＤＮ）タイプの１つのユニキャストアクセスネットワークの明示的な識別を可能にすることができる。パラメータは、ユニキャスト配信を介したそれらのアベイラビリティに対する、このユニキャストアクセスネットワークまたはＣＤＮ上の取出し用のデータセグメントの予想されるアベイラビリティ調整を示すことができる。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２２Ａ〜図２２Ｄに関して上述された方法を実行するためのデバイスおよび装置が提供される。図２３を参照すると、モバイルエンティティとして、またはその中で使用するためのプロセッサもしくは同様のデバイス／コンポーネントとして構成され得る、例示的な装置２３００が提供される。装置２３００は、プロセッサ、ソフトウェア、またはそれらの組合せ（たとえば、ファームウェア）によって実装された機能を表すことができる機能ブロックを含むことができる。たとえば、装置２３００は、ＭＰＤを受信するための電気的なコンポーネントまたはモジュール２３１２を含むことができ、ＭＰＤは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備える。装置２３００は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定するためのコンポーネント２３１４を含むことができる。装置２３００は、モバイルエンティティの基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択するためのコンポーネント２３１６を含むことができる。装置２３００は、ブロードキャスト送信およびユニキャスト送信のうちの判定された方のためのパラメータに少なくとも部分的に基づいて、所与の表現のためのデータセグメントを受信するためのコンポーネント２３１８を含むことができる。

関係する態様では、プロセッサとしてではなく、モバイルエンティティとして構成された装置２３００の場合、装置２３００は、少なくとも１つのプロセッサを有するプロセッサ／コントローラコンポーネント２３５０をオプションで含むことができる。そのような場合、プロセッサ２３５０は、バス２３５２などを介してコンポーネント２３１２〜２３１８と動作可能に通信することができる。プロセッサ２３５０は、コンポーネント２３１２〜２３１８によって実行されるプロセスまたは機能の起動とスケジューリングとを実現することができる。

さらなる関係する態様では、装置２３００は、無線周波数（ＲＦ）送受信機コンポーネント２３５４を含むことができる。送受信機２３５４の代わりに、または送受信機２３５４とともに、スタンドアロン受信機および／またはスタンドアロン送信機を使用することができる。装置２３００は、たとえば、メモリデバイス／コンポーネント２３５６などの情報を記憶するためのコンポーネントをオプションで含むことができる。コンピュータ可読媒体またはメモリコンポーネント２３５６は、バス２３５２などを介して装置２３００の他のコンポーネントに動作可能に結合することができる。メモリコンポーネント２３５６は、コンポーネント２３１２〜２３１８およびそれらのサブコンポーネントのプロセスおよび挙動、またはプロセッサ２３５０、または図２２Ａ〜図２２Ｄを参照して上述された方法を実現するためのコンピュータ可読命令とデータとを記憶するように適合することができる。メモリコンポーネント２３５６は、コンポーネント２３１２〜２３１８に関連する機能を実行するための命令を保持することができる。メモリ２３５６の外部にあるものとして示されているが、コンポーネント２３１２〜２３１８はメモリ２３５６の内部に存在する場合があることを理解されたい。図２３内のコンポーネントは、プロセッサ、電子デバイス、ハードウェアデバイス、電気サブコンポーネント、論理回路、メモリ、ソフトウェアコード、ファームウェアコードなど、またはそれらの任意の組合せを備える場合があることにさらに留意されたい。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２４は、モバイルエンティティなどによって動作可能な別の例示的な方法２４００を示す。方法２４００は、２４１０で、（ａ）ＤＡＳＨ ＭＰＤと、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含む、システム情報を受信することを含むことができる。方法２４００は、２４１５で、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定することを含むことができる。方法２４００は、２４２０で、モバイルエンティティのパラメータおよび基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択することを含むことができる。方法２４００は、２４３０で、所与の表現のためのデータセグメントを受信することを含むことができる。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２５は、図２４を参照して上述された方法２４００を実行するための装置２５００（たとえば、モバイルエンティティまたはそのコンポーネント）の設計を示す。たとえば、装置２５００は、（ａ）ＤＡＳＨ ＭＰＤと、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含む、システム情報を受信するための電気的なコンポーネントまたはモジュール２５１２を含むことができる。装置２５００は、ブロードキャスト送信またはユニキャスト送信のどちらがデータセグメントの受信に適しているかを判定するためのコンポーネント２５１３を含むことができる。装置２５００は、モバイルエンティティのパラメータおよび基準に基づいて、コンテンツのマルチプルな表現の中から所与の表現を選択するためのコンポーネント２５１４を含むことができる。装置２５００は、所与の表現のためのデータセグメントを受信するためのコンポーネント２５１６を含むことができる。簡潔にするために、装置２５００に関する詳細の残りはさらに詳述されないが、装置２５００の特徴および態様の多くは、図２３の装置２３００に関して上述された特徴および態様と実質的に同様であることを理解されたい。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２６を参照すると、ネットワークエンティティ（たとえば、ｅＮＢなど）によって動作可能な方法２６００が示される。方法２６００は、２６１０で、ＭＰＤを送ることを含むことができ、ＭＰＤは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備える。方法２６００は、２６２０で、コンテンツの所与の表現についての要求を受信することを含むことができる。方法２６００は、２６３０で、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、所与の表現のためのデータセグメントを送ることを含むことができる。方法は、サービスのどの表現がブロードキャスト送信またはユニキャスト送信に利用可能であるかシグナリングすること（ブロック２６４０）をオプションで含むことができる。たとえば、データセグメントを送ること（ブロック２６３０）は、ユニキャスト送信を介して所与の表現のためのデータセグメントを送ることと、並行して、ブロードキャスト送信を介して少なくとも１つの異なる表現のためのデータセグメントを送ることと（ブロック２６５０）を含むことができる。

本明細書に記載された実施形態の１つまたは複数の態様によれば、図２７は、図２６を参照して上述された方法２６００を実行するための装置２７００（たとえば、ネットワークエンティティまたはそのコンポーネント）の設計を示す。たとえば、装置２７００は、ＭＰＤを送るための電気的なコンポーネントまたはモジュール２７１２を含むことができ、ＭＰＤは、ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータを備える。装置２７００は、コンテンツの所与の表現についての要求を受信するためのコンポーネント２７１４を含むことができる。装置２７００は、パラメータに少なくとも部分的に基づいて、ブロードキャスト送信またはユニキャスト送信を介して、所与の表現のためのデータセグメントを送るためのコンポーネント２７１６を含むことができる。簡潔にするために、装置２７００に関する詳細の残りはさらに詳述されないが、装置２７００の特徴および態様の多くは、図２３の装置２３００に関して上述された特徴および態様と同様であることを理解されたい。しかしながら、装置２７００は、ｅＮＢなどのネットワークエンティティであり得ることに留意されたい。したがって、装置は、ネットワークインターフェースコンポーネント（たとえば、ネットワークインターフェースカードまたはネットワークインターフェースコントローラ）、ならびに、通常、ワイヤレス通信システムで使用される基地局内で見出される他のコンポーネントを含むことができる。

ネットワークサイドは、ＭＰＤと、ブロードキャスト表現および／またはユニキャスト表現の間で選択するモバイルデバイス／エンティティへのパラメータとを記述することに留意されたい。ネットワークは、ブロードキャスト表現を送り、モバイルデバイスがセグメントを取り出すことに利用可能なユニキャスト表現を作成する。関係する態様では、装置２７００は、モバイルエンティティがメディアデータセグメントの受信用にユニキャストモードを選択したことに応答して、ユニキャストＨＴＴＰなどを介してメディアデータセグメントのモバイルエンティティ選択の表現を送ることをさらに含むことができる。

情報および信号は様々な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表すことができる。

本明細書の開示に関連して記載された様々な例示的な論理ブロック、モジュール、回路、およびプロセスステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者はさらに諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、概してそれらの機能に関して上述された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、記載された機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本開示の範囲からの逸脱を生じるものと解釈されるべきではない。

本明細書の開示に関連して記載された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書に記載された機能を実行するように設計されたそれらの任意の組合せを用いて、実施または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。プロセッサは、コンピューティングデバイスの組合せ、たとえば、ＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装することもできる。

本明細書の開示に関して記載された方法またはプロセスのステップは、直接ハードウェアで具現化するか、プロセッサによって実行されるソフトウェアモジュールで具現化するか、またはその２つの組合せで具現化することができる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭ（登録商標）メモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当技術分野で知られている任意の他の形態の記憶媒体に常駐することができる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサに一体化することができる。プロセッサおよび記憶媒体はＡＳＩＣに常駐することができる。ＡＳＩＣはユーザ端末に常駐することができる。代替として、プロセッサおよび記憶媒体は、ユーザ端末内の個別構成要素として常駐することができる。

１つまたは複数の例示的な設計では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、または任意のそれらの組合せに実装することができる。ソフトウェアに実装する場合、機能は、１つもしくは複数の命令もしくはコードとしてコンピュータ可読媒体上に記憶するか、またはコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、汎用または専用のコンピュータによってアクセスできる任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは、命令またはデータ構造の形態の所望のプログラムコード手段をトランスポートまたは記憶するために使用され得るし、汎用もしくは専用のコンピュータ、または汎用もしくは専用のプロセッサによってアクセスされ得る、任意の他の媒体を含むことができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または非一時的ワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または非一時的ワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。

本開示の前述の説明は、いかなる当業者も本開示を作成または使用することができるように提供される。本開示に対する様々な修正は当業者には容易に明らかであり、本明細書で定義された一般原理は、本開示の趣旨または範囲から逸脱することなく他の変形形態に適用することができる。したがって、本開示は、本明細書に記載された例および設計に限定されるものではなく、本明細書で開示された原理および新規の特徴に合致する最も広い範囲を与えられるべきである。

Claims (30)

1. ワイヤレス通信のためのモバイルエンティティによって動作可能な方法であって、
   ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含む、メディアプレゼンテーションディスクリプション（ＭＰＤ）を受信することと、
   前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
   前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
   前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信することと
   を備える、方法。
2. 前記モバイルエンティティがブロードキャストモバイルシステム上で動作し、ブロードキャストＤＡＳＨサービスが、前記ＭＰＤを含むシステム情報メタデータを介して定義され、前記方法が、前記ブロードキャストＤＡＳＨサービスの代替的な配信が前記ユニキャスト送信を介して利用可能であるかどうかを、前記ＭＰＤ内の前記パラメータから判定することをさらに備える、請求項１に記載の方法。
3. 判定することが、
   前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定することと、
   前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定することと
   をさらに含む、請求項１に記載の方法。
4. 前記基準が、表示解像能力、言語能力、前記モバイルエンティティのワイヤレスネットワーク互換性、または前記表現の帯域幅要件をサポートするためのワイヤレスチャネルアベイラビリティのうちの少なくとも１つを含む、請求項１に記載の方法。
5. 前記所与の表現に関連付けられたブロードキャストファイル配信セッションについての情報が、メディアセグメントの前記受信のための前記ブロードキャストファイル配信セッションをアクティブ化するために使用される、請求項４に記載の方法。
6. 現在のブロードキャストサービスエリア内で受信され得る利用可能なブロードキャスト表現の中から選択することによって、ブロードキャスト受信用の表現を選択することをさらに備える、請求項１に記載の方法。
7. 現在のユニキャストサービスエリア内で受信され得る代替配信に利用可能なユニキャスト表現の中から選択することによって、ユニキャスト受信用の表現を選択することさらに備える、請求項１に記載の方法。
8. 前記所与の表現のための前記データセグメントを受信することが、前記所与の表現のための待ち時間調整期間により、前記表現の前記データセグメントについてのアベイラビリティタイムラインを調整することをさらに含む、請求項１に記載の方法。
9. 前記所与の表現のための前記データセグメントを受信することが、
   それらそれぞれの待ち時間調整期間によって定義された、前記表現のためのアベイラビリティタイムラインの差を考慮することと、
   前記データセグメントへのアクセスに影響する前記ブロードキャスト送信および前記ユニキャスト送信の特性を考慮することと、
   前記コンテンツのそれぞれの表現のための前記ユニキャスト送信を介した前記受信と前記ブロードキャスト送信を介した前記受信との間のシームレスな遷移を達成するためにデータセグメントのバッファリングを調整することと
   をさらに含む、請求項１に記載の方法。
10. 前記待ち時間調整期間が、前記ユニキャスト送信に対する、前記ブロードキャスト送信を介した前記所与の表現のための前記データセグメントの前記アベイラビリティにおける時間遅延または時間前進を示す、請求項８に記載の方法。
11. 前記パラメータが、前記データセグメントの（ａ）ユニキャストのみ、（ｂ）ブロードキャストのみ、または（ｃ）ユニキャストとブロードキャストの両方のアベイラビリティを示し、
    前記データセグメントの（ｂ）ブロードキャストのみ、または（ｃ）ユニキャストとブロードキャストの両方のアベイラビリティに関する前記パラメータのうちの少なくとも１つが、ブロードキャスト分配技術を識別する、
    請求項１に記載の方法。
12. 前記パラメータが、いくつかの識別されたブロードキャストサービスエリア内のブロードキャスト表現のアベイラビリティに関する情報を含む、請求項１に記載の方法。
13. 前記データセグメントが、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）メディアセグメントを備え、
    前記方法が、前記ブロードキャスト送信から前記ユニキャスト送信にまたはその逆に変化する前記メディアセグメントの前記受信に応答して、前記メディアセグメントのシームレスなプレイバックを達成するために前記メディアセグメントを蓄積することをさらに備える、
    請求項１に記載の方法。
14. 前記パラメータが、前記ＭＰＤ内の拡張要素ＴｒａｎｓｐｏｒｔＤｅｓｃｒｉｐｔｉｏｎの１つまたは複数のインスタンスにおいて符号化され、
    前記パラメータが、ブロードキャストコンテンツの特定の表現のためのファイル配信オーバー単方向トランスポート（ＦＬＵＴＥ）セッション識別子を含む、
    請求項１に記載の方法。
15. 装置であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を受信するための手段と、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定するための手段と、
    モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するための手段と、
    前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信するための手段と
    を備える、装置。
16. 前記装置がブロードキャストモバイルシステム上で動作し、ブロードキャストＤＡＳＨサービスが、前記ＭＰＤを含むシステム情報メタデータを介して定義され、前記装置が、前記ブロードキャストＤＡＳＨサービスの代替的な配信が前記ユニキャスト送信を介して利用可能であるかどうかを、前記ＭＰＤ内の前記パラメータから判定するための手段をさらに備える、請求項１５に記載の装置。
17. 前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定するための手段と、
    前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定するための手段と
    をさらに備える、請求項１５に記載の装置。
18. 装置であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を受信するように構成された無線周波数（ＲＦ）送受信機と、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定し、モバイルエンティティの基準に基づいて前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するように構成された、少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに結合された、データを記憶するためのメモリとを備え、
    前記ＲＦ送受信機が、前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて前記所与の表現についての前記データセグメントを受信する、
    装置。
19. コンピュータプログラム製品であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を受信することと、
    モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記所与の表現についての前記データセグメントの受信に適しているかを判定することと、
    前記ブロードキャスト送信および前記ユニキャスト送信のうちの前記判定された方のための前記パラメータに少なくとも部分的に基づいて、前記所与の表現のための前記データセグメントを受信することと
    をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
    を備える、コンピュータプログラム製品。
20. ワイヤレスシステム内のモバイルエンティティによって動作可能な方法であって、
    （ａ）動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）のメディアプレゼンテーションディスクリプション（ＭＰＤ）と、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することと、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
    前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
    前記所与の表現のためのデータセグメントを受信することと
    を備える、方法。
21. 前記モバイルエンティティの現在の位置における前記ブロードキャスト送信のアベイラビリティを判定することと、
    前記ブロードキャスト送信の前記アベイラビリティが存在しない場合、前記ブロードキャスト送信の代替として前記ユニキャスト送信のアベイラビリティを判定することと
    をさらに備える、請求項２０に記載の方法。
22. 装置であって、
    （ａ）動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）のメディアプレゼンテーションディスクリプション（ＭＰＤ）と、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信するための手段と、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定するための手段と、
    前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するための手段と、
    前記所与の表現のためのデータセグメントを受信するための手段と
    を備える、装置。
23. 装置であって、
    （ａ）動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）のメディアプレゼンテーションディスクリプション（ＭＰＤ）と、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータとを含むシステム情報を受信するように構成された無線周波数（ＲＦ）送受信機と、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定し、前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択するように構成された少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに結合された、データを記憶するためのメモリとを備え、
    前記ＲＦ送受信機が、前記所与の表現のためのデータセグメントを受信する、
    装置。
24. コンピュータプログラム製品であって、
    （ａ）動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）のメディアプレゼンテーションディスクリプション（ＭＰＤ）と、（ｂ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現についてのデータセグメントの受信のためのパラメータとを含むシステム情報を受信することと、
    前記ブロードキャスト送信または前記ユニキャスト送信のどちらが前記データセグメントの受信に適しているかを判定することと、
    前記パラメータおよび前記モバイルエンティティの基準に基づいて、前記コンテンツの前記マルチプルな表現の中から所与の表現を選択することと、
    前記所与の表現のためのデータセグメントを受信することと
    をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
    を備える、コンピュータプログラム製品。
25. ワイヤレス通信のためのネットワークエンティティによって動作可能な方法であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを含むメディアプレゼンテーションディスクリプション（ＭＰＤ）を送信することと、
    前記コンテンツの所与の表現についての要求を受信することと、
    前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと
    を備える、方法。
26. サービスのどの表現が前記ブロードキャスト送信または前記ユニキャスト送信に利用可能であるかをシグナリングすることをさらに備える、請求項２５に記載の方法。
27. 前記データセグメントを送信することが、前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと、並行して、前記ブロードキャスト送信を介して少なくとも１つの異なる表現のための前記データセグメントを送信することとを含む、請求項２５に記載の方法。
28. 装置であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション（ＭＰＤ）を送信するための手段と、
    前記コンテンツの所与の表現についての要求を受信するための手段と、
    前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信するための手段と
    を備える、装置。
29. 装置であって、
    無線周波数（ＲＦ）送受信機と、
    （ａ）ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション（ＭＰＤ）を送信するように前記ＲＦ送受信機に命令し、（ｂ）前記コンテンツの所与の表現についての要求を受信することに応答して、前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信するように前記ＲＦ送受信機に命令するように構成された、少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに結合された、データを記憶するためのメモリとを備える、装置。
30. コンピュータプログラム製品であって、
    ブロードキャスト送信およびユニキャスト送信を介したコンテンツのマルチプルな表現のためのデータセグメントの受信のためのパラメータを備えるメディアプレゼンテーションディスクリプション（ＭＰＤ）を送信することと、
    前記コンテンツの所与の表現についての要求を受信することと、
    前記パラメータに少なくとも部分的に基づいて、前記ブロードキャスト送信または前記ユニキャスト送信を介して前記所与の表現のための前記データセグメントを送信することと
    をコンピュータに行わせるためのコードを備える、非一時的コンピュータ可読媒体
    を備える、コンピュータプログラム製品。