(57)【特許請求の範囲】
【請求項１】
HTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、マルチメディア放送マルチキャストサービス（MBMS）ダウンロードから、ハイパーテキスト転送プロトコル（HTTP）ベース配信へと切り換えるためのシステムであって、
サービス制御機能（SCF）モジュールにおいて、セッション開始プロトコル（SIP）再招待を、移動デバイスから、DASHフォーマット化コンテンツを含むコンテンツ配信セッションにおけるMBMSダウンロードの前記移動デバイスによる受信中に、受信する手段と、
HTTPベース配信のためのHTTPサーバを選択するために、前記SCFモジュールからHTTP/SIPアダプタへ、SIP招待を送信する手段と、
前記HTTP/SIPアダプタから、前記コンテンツ配信セッションのための前記HTTPサーバの選択を示すSIP確認を、前記SCFモジュールにおいて受信する手段と、
前記コンテンツ配信セッションのための前記HTTPサーバへの切換えを示す前記SIP確認を、前記SCFモジュールから前記移動デバイスへ転送する手段と、を備えるシステム。
【請求項２】
請求項１に記載のシステムであって、前記SIP再招待を前記SCFモジュールで受信後、前記MBMSダウンロードを終了するために、前記SCFモジュールから放送マルチキャストサービスセンタ（BMSC）へ、終了要求を送信する手段をさらに備える、システム。
【請求項３】
請求項１および２のいずれか１項に記載のシステムであって、前記SCFモジュールは、前記コンテンツ配信セッションにおける前記MBMSダウンロードを介する前記DASHフォーマット化コンテンツを提供する放送マルチキャストサービスセンタ（BMSC）に関連付けられたドメイン名またはコンテンツ識別子を以前に参照し、前記移動デバイスは、前記MBMSダウンロードを受信しており、前記SIP再招待は、前記の同じコンテンツ配信セッションにおける前記HTTPベース配信を介したDASHフォーマット化コンテンツを提供する前記HTTPサーバのための要求統一リソース識別子（URI）を含み、前記HTTPベース配信のための前記HTTPサーバは、前記HTTPサーバを参照する前記要求URIに含まれるドメイン名またはコンテンツ識別子に基づいて選択され、前記HTTPサーバを参照する前記ドメイン名および前記コンテンツ識別子は、前記BMSCに関連付けられた前記ドメイン名および前記コンテンツ識別子とは異なる、システム。
【請求項４】
請求項１乃至３のいずれか１項に記載のシステムであって、前記SIP招待を前記SCFモジュールからHTTP/SIPアダプタへ送信する前に、前記SCFモジュールで、前記コンテンツ配信セッションがMBMSからHTTPへの切換えをサポートしているか否かを判断する手段をさらに備える、システム。
【請求項５】
請求項１乃至４のいずれか１項に記載のシステムであって、前記SIP再招待は、前記移動デバイスから、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）コアネットワーク（IM  CN）サブシステムを介して前記SCFモジュールで受信され、前記SIP確認は、前記SCFモジュールから、前記IM  CNサブシステムを介して前記移動デバイスへ転送される、システム。
【請求項６】
請求項１乃至５のいずれか１項に記載のシステムであって、前記SCFモジュールとの通信における無線アクセスネットワーク（RAN）の前記移動デバイスと送信局との間の無線インターフェイスは、コンテンツのユニキャスト及びマルチキャスト配信をサポートする、システム。
【請求項７】
請求項１乃至６のいずれか１項に記載のシステムであって、前記SIP確認は、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、配信記述、およびこれらの組合せからなるグループから選択される、前記HTTPベース配信のための情報を含む、セッション記述プロトコル（SDP）アンサー（answer）を含む、システム。
【請求項８】
請求項１乃至７のいずれか１項に記載のシステムであって、前記SIP再招待は、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、HTTP上のユニキャストストリームのための配信チャネル、前記HTTPサーバで利用可能なメディア能力、前記HTTPサーバで利用可能なポリシー、コーデックおよびトランスポートプロトコル、およびこれらの組合せからなるグループから選択される、前記HTTPベース配信のための情報を含む、セッション記述プロトコル（SDP）オファー（offer）を含む、システム。
【請求項９】
請求項８に記載のシステムであって、前記HTTPストリーミングセッションのための前記HTTPサーバで利用可能な前記メディア能力およびポリシーは、以前受信したMPDメタデータファイルからMBMSダウンロード中に取得される、システム。
【請求項１０】
請求項１乃至９のいずれか１項に記載のシステムであって、前記SIP招待を前記SCFモジュールから前記HTTP/SIPアダプタへ送信する前に、HTTPベース配信を介した前記DASHフォーマット化コンテンツのためのユーザの権利を確認する手段をさらに備える、システム。
【請求項１１】
HTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、ハイパーテキスト転送プロトコル（HTTP）ベースの配信から、マルチメディア放送マルチキャストサービス（MBMS）ダウンロードへと切り換えるためのシステムであって、
セッション開始プロトコル（SIP）再招待を、サービス制御機能（SCF）モジュールで、移動デバイスから、DASHフォーマット化コンテンツを含むコンテンツ配信セッションにおけるHTTPベース配信の前記移動デバイスによる受信中に、受信する手段と、
前記SCFモジュールから、放送マルチキャストサービスセンタ（BMSC）へ、前記BMSCを前記コンテンツ配信セッションのMBMSダウンロードのために初期化するために、招待メッセージを送信する手段と、
前記HTTPベース配信を終了させるために、前記SCFモジュールからHTTP/SIPアダプタへ、SIP終了要求を送信する手段と、
前記HTTPベース配信の終了を示すSIP確認を、前記SCFモジュールで前記HTTP/SIPアダプタから受信する手段と、
前記コンテンツ配信セッションのための前記BMSCへの切換えを示す前記SIP確認を、前記SCFモジュールから前記移動デバイスへ転送する手段と、を備えるシステム。
【請求項１２】
請求項１１に記載のシステムであって、前記招待メッセージを前記SCFモジュールから前記BMSCへ送信後に、前記コンテンツ配信セッションのための前記BMSCの選択を示すBMSC確認を、前記SCFモジュールで、前記BMSCから受信する手段をさらに備えるシステム。
【請求項１３】
請求項１１および１２のいずれか１項に記載のシステムであって、前記SCFモジュールは、前記コンテンツ配信セッションにおいて前記HTTPベース配信を介して前記DASHフォーマット化コンテンツを提供するHTTPサーバに関連付けられたドメイン名またはコンテンツ識別子を、以前に参照し、前記移動デバイスは、前記HTTPベース配信を受信しており、前記SIP再招待は、前記の同じコンテンツ配信セッションにおいて前記MBMSダウンロードを介したDASHフォーマット化コンテンツを提供するための前記BMSCのための要求統一リソース識別子（URI）を含み、前記コンテンツ配信セッションの前記MBMSダウンロードのための前記BMSCを選択するために、前記の異なる要求URIが使用され、前記BMSCを参照する前記要求URIに含まれるドメイン名またはコンテンツ識別子に基づいて前記MBMSダウンロードのための前記BMSCが選択され、前記HTTPサーバに関連付けられた前記ドメイン名および前記コンテンツ識別子は、前記BMSCを参照する前記ドメイン名および前記コンテンツ識別子と異なる、システム。
【請求項１４】
請求項１１乃至１３のいずれか１項に記載のシステムであって、前記SCFモジュールとの通信における無線アクセスネットワーク（RAN）の前記移動デバイスと送信局との間の無線インターフェイスは、コンテンツのユニキャスト及びマルチキャスト配信をサポートする、システム。
【請求項１５】
請求項１１乃至１４のいずれか１項に記載のシステムであって、前記SIP再招待は、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、MBMS上のマルチキャストストリームのための配信チャネル、前記MBMSで利用可能なメディア能力、前記MBMSで利用可能なポリシー、コーデックおよびトランスポートプロトコル、およびこれらの組合せからなるグループから選択される、前記MBMSダウンロードのための情報を含む、セッション記述プロトコル（SDP）オファー（offer）を含む、システム。
【請求項１６】
請求項１１乃至１５のいずれか１項に記載のシステムであって、前記SCFモジュールから転送される前記SIP確認は、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、配信記述、コーデックおよびトランスポートプロトコル、およびこれらの組合せからなるグループから選択される、前記MBMSダウンロードのための情報を含む、セッション記述プロトコル（SDP）アンサー（answer）を含む、システム。
【請求項１７】
請求項１１乃至１６のいずれか１項に記載のシステムであって、前記招待メッセージを前記SCFモジュールから前記BMSCへ送信する前に、前記MBMSダウンロードを介した前記DASHフォーマット化コンテンツのサービスの権利を確認するために、サービス承認手順を実行するための手段をさらに備える、システム。
【請求項１８】
HTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、マルチキャストダウンロードとユニキャスト配信との間を切り換えるように構成された移動デバイスであって、マルチキャストからユニキャストへのセッション変更要求を、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）コアネットワーク（IM  CN）サブシステムに、コンテンツ配信セッションにおけるマルチメディア放送マルチキャストサービス（MBMS）ダウンロードを介したDASHフォーマット化コンテンツの受信中に、送信するように構成された送受信手段であり、前記マルチキャストからユニキャストへのセッション変更要求は、前記同じコンテンツ配信セッションにおいてHTTPベース配信を介してDASHフォーマット化コンテンツを提供するためのHTTPサーバのためのユニキャスト要求URIを含む、送受信手段と；
ユニキャストからマルチキャストへのセッション変更要求を前記IM  CNサブシステムに、前記コンテンツ配信セッションにおける前記HTTPベース配信を介したDASHフォーマット化コンテンツの受信中に、送信するようにさらに構成された前記送受信手段であり、前記ユニキャストからマルチキャストへのセッション変更要求は、前記同じコンテンツ配信セッションにおいて前記MBMSダウンロードを介したDASHフォーマット化コンテンツを提供するための放送マルチキャストサービスセンタ（BMSC)のためのマルチキャスト要求URIを含む、前記送受信手段と；
前記コンテンツ配信セッションのための前記HTTPサーバへの切換えを示す前記SIP確認を前記IM  CNサブシステムから受信し、前記コンテンツ配信セッションのための前記BMSCへの切換えを示すSIP終了メッセージを前記IM  CNサブシステムから受信するようにさらに構成された前記送受信手段と；
前記DASHフォーマット化コンテンツのための、前記MBMSダウンロードとHTTPベース配信との間を切り換えるように構成された処理モジュール手段と、を備える移動デバイス。
【請求項１９】
請求項１８に記載の移動デバイスであって、前記移動デバイスは、前記IM  CNサブシステムと、ユニキャストおよびマルチキャストのコンテンツ配信をサポートする無線インターフェイスを介して通信し、前記移動デバイスは、第３世代パートナーシッププロジェクト（3GPP）長期的高度化システム（LTE）規格および電気電子学会（IEEE）802.16規格からなるグループから選択されるプロトコルを使用する、前記移動デバイス。
【請求項２０】
請求項１８および１９のうちいずれか１項に記載の移動デバイスであって、前記移動デバイスは、無線ローカルエリアネットワーク（WLAN）、無線パーソナルエリアネットワーク（WPAN）、および、無線広域ネットワーク（WWAN）の中の少なくとも１つと接続されるように構成され、そして、前記移動デバイスは、アンテナ、タッチセンシィティブディスプレイスクリーン、スピーカ、マイクロフォン、グラフィックプロセッサ、アプリケーションプロセッサ、内部メモリ、不揮発性メモリポート、またはこれらの組合せを含む、移動デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IMSネットワークにおけるコンテンツの配信システムに関する。
【背景技術】
【０００２】
無線移動通信技術は、送信局と無線移動装置との間でデータを送信するためにさまざまな規格やプロトコルを利用する。無線装置の中には、物理層を介した所望のデジタル変調スキームと組み合せた直交周波数分割多重化（OFDM）を利用して通信するものがある。OFDMを利用する規格やプロトコルには、第３世代パートナーシッププロジェクト（3GPP）長期的高度化システム（LTE）、一般的に業界団体にWiMAX（マイクロ波アクセスのための全世界相互運用）として知られている電気電子学会（IEEE）802.16規格（例：802.16e、802.16m）、そして、一般的に業界団体にWiFiとして知られているIEEE  802.11規格が含まれる。
【０００３】
3GPP無線アクセスネットワーク（RAN）LTEシステムにおいて、送信局は、発展型ユニバーサル地上無線アクセスネットワーク（E-UTRAN）ノードＢ（一般的に、発展型ノードB、拡張ノードB、eノードB、eNBとも表記される。）と無線ネットワークコントローラ（RNC）との組合せであり得、ユーザ装置（UE）として知られる無線移動デバイスと通信する。下りリンク（DL）送信は、送信局（またはeNodeB）から無線移動デバイス（またはUE）への通信であり得、上りリンク（UL）送信は、無線移動デバイスから送信局への通信であり得る。
【０００４】
下りリンク送信においては、送信局は、ユニキャストサービスを使ったユニキャストサブフレームを用いて単一の無線移動デバイスと通信することができる。ユニキャスト配信は、１メッセージ１移動デバイスに関係する１対１の関係を持つことができる。代わりに、送信局は、マルチメディア放送およびマルチキャストサービス（MBMS）を使ったマルチキャスト／ブロードキャスト単一周波数ネットワーク（MBSFN）を用いて複数の無線移動デバイスと通信することができる。MBMSにおけるトランスポートのマルチキャストおよびブロードキャストのトラフィックは、１メッセージ多移動デバイスに関係する１対多の関係を持つことができる。
【発明の概要】
【０００５】
開示される発明の機能および特徴は、添付図とあわせて、以下の詳細な説明により明らかになるであろう。
【図面の簡単な説明】
【０００６】
【図１】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）に基づいたパケット交換ストリーミング（PSS）および、マルチメディア放送およびマルチキャストサービス（MBMS）機能アーキテクチャのブロック図
【図２】一例に従った放送マルチキャストサービスセンタ（BMSC）サブ機能アーキテクチャのブロック図
【図３】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）ネットワークにおける、HTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、マルチメディア放送およびマルチキャストサービス（MBMS）ダウンロードから、ハイパーテキスト転送プロトコル（HTTP）に基づいた配信への切換え処理例
【図４】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）ネットワークにおけるHTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、マルチメディア放送およびマルチキャストサービス（MBMS）ダウンロードから、ハイパーテキスト転送プロトコル（HTTP）に基づいた配信への、メディアプレゼンテーション記述（MPD）の要求を含む、切換え処理例
【図５】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）における、DASHフォーマット化コンテンツの、ハイパーテキスト転送プロトコル（HTTP）に基づいた配信から、マルチメディア放送およびマルチキャストサービス（MBMS）ダウンロード配信への切換え処理例
【図６】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）ネットワークにおけるHTTP上の動的適応ストリーミング（DASH）フォーマット化コンテンツの、マルチメディア放送およびマルチキャストサービス（MBMS）ダウンロードから、ハイパーテキスト転送プロトコル（HTTP）に基づいた配信への切換え方法のフローチャート
【図７】一例に従った、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）におけるDASHフォーマット化コンテンツの、ハイパーテキスト転送プロトコル（HTTP）に基づいた配信から、マルチメディア放送およびマルチキャストサービス（MBMS）ダウンロード配信への切換え方法のフローチャート
【図８】一例に従ったユーザ装置（UE）の図  参照を通して例示的実施形態が説明され、特定の言語を用いて説明される。しかしながら、これによって本発明の範囲のいかなる制限をも意図するものではない。
【０００７】
本発明が開示され説明される前に、理解されるべきは、本発明は、開示される特定の構造、処理工程、材料、に限定されるものではなく、当業者が認識するであろうこれらの均等物にまで拡張されるということである。また、明細書の中で用いられる用語は、特定の例を説明する目的のためだけに用いられるのであって、限定するために用いられるのではない、ということも理解されるべきである。異なる図における同じ参照番号は同じ要素を表す。フローチャートや処理において提供される番号は、ステップや操作を明確に説明するために提供されるのであって、必ずしも特定の順番や順序を示すものではない。
【発明を実施するための形態】
【０００８】
以下に、初期の実施例の概要が提供され、次に、特定の実施例がさらに詳しく後述される。この初期の概要は、読者がより早く技術を理解することを助けることを意図したものであり、技術の主要な機能や本質的な機能を特定することを意図するものではなく、請求される主題の範囲を制限することを意図するものでもない。
【０００９】
ハイパーテキスト転送プロトコル（HTTP）ストリーミングは、インターネットビデオのマルチメディア配信の一形式として利用されることができる。HTTPに基づいた配信は、HTTP、およびHTTPの下層にあるトランスミッションコントロールプロトコル（TCP）／インターネットプロトコル（IP）を含むプロトコルの幅広い採用により、信頼性と配備の単純性とを提供できる。HTTPに基づく配信は、ネットワークアドレス変換（NAT）やファイヤーウォールの通過問題を回避することにより、簡単で楽なストリーミングサービスを可能にする。HTTPに基づく配信またはストリーミングはまた、専用のストリーミングサーバの代わりに標準のHTTPサーバやキャッシュを使用するという能力を提供できる。HTTPに基づく配信は、サーバ側上の最小のまたは縮小された状態情報により、スケーラビリティを提供できる。
【００１０】
HTTP上の動的適応ストリーミング（DASH）は、マルチメディアファイルが１以上のセグメントに分割され、HTTPを使ってクライアントに配信されることができるマルチメディアストリーミング技術である。DASHクライアントは、一連のHTTP要求応答トランザクションを通してセグメントをダウンロードすることにより、マルチメディアコンテンツを受信することができる。DASHは、メディアコンテンツの様々なビットレート表現を、利用可能な帯域幅の変化に応じて動的に切り換える能力を提供することができる。こうして、DASHは、変化するネットワークや無線リンクの状態、ユーザの好み、そして、ディスプレイの解像度や採用されている中央処理装置（CPU）の種類や利用可能なメモリ資源等のデバイス能力、に対する高速な適応を可能にすることができる。DASHの動的な適応は、より短いスタートアップ遅延やより少ない再バッファリング事象によって、より質の高い経験（QoE）をユーザに提供することができる。
【００１１】
インターネットプロトコル（IP）マルチメディアサブシステム、または、IPマルチメディアコアネットワークサブシステム（IMS）は、IPマルチメディアサービスを配信するための、3GPPにおけるアーキテクチャフレームワークである。IPマルチメディアコアネットワークサブシステムは、標準化されたインターフェイスで結びつけられた様々なコアネットワーク及びアクセスネットワーク機能の集まりであることが可能であり、一緒に纏められて1つのIMS管理ネットワークを形成することができる。インターネットとの統合を容易にするために、IMSはセッション開始プロトコル（SIP）を利用することができる。SIPサーバまたはプロキシのいろいろな役割は、総称して呼セッション制御機能（CSCF）と呼ばれることができ、IMSにおいてSIPシグナリングパケットを処理するために用いることができる。固定アクセス（例：デジタル加入者線（DSL）、ケーブルモデム、またはイーサネット（登録商標））、移動アクセス（例：W-CDMA、CDMA2000、GSM（登録商標）、またはGPRS）および無線アクセス（例：WLANまたはWiMax）は、IMSによってサポートされることができる。昔ながらの電話（POTS：アナログ電話）やIMS互換でないIP電話（VoIP）システム等の他の電話システムは、ゲートウェイを介してサポートされることができる。
【００１２】
DASHフォーマット化コンテンツは、IMSネットワーク上で、マルチメディア放送マルチキャストサービス（MBMS）ダウンロード配信のようにマルチキャストフレームに入れて、または、HTTPに基づく配信のようにユニキャストフレームに入れて、配信されることができる。DASHコンテンツを含むコンテンツ配信セッションは、MBMSダウンロード方式を使って配信し、そして、セッションの最中（ミッドセッション）に、HTTPに基づく配信方式に切り換えることができる。IMSに基づくネットワークにおいて、ユーザへのDASHフォーマット化コンテンツの送信中にMBMSダウンロード方式とHTTPに基づく配信方式とを切り換えることは望ましいことであり得る。
【００１３】
図１に例示されたブロック図に示されるように、IMSネットワークにおけるDASHフォーマット化コンテンツの、MBMSダウンロードからHTTPに基づく配信への切換えにおいて、ユーザ装置（UE）210等の移動デバイスは、セッションイニシエーションプロトコル（SIP）の再招待（re-invitation）を、DASHコンテンツを含む現在のコンテンツ配信セッションにおいてMBMSダウンロードを該移動デバイスが受信している最中に、サービス制御機能（SCF）230モジュールに送信することができる。SIP再招待は、SIPの再招待（Re-INVITE）メッセージを含むことができる。SIP再招待は、同じコンテンツ配信セッションの中でHTTPに基づく配信を介してDASHコンテンツを提供するHTTPサーバ260の要求統一リソース識別子（URI）を含むことができる。要求URIは、HTTPに基づく配信を提供するHTTPサーバを識別する（または参照する）ドメイン名またはコンテンツ識別子を含むことができる。SCFモジュールは、インターネットプロトコル（IP）マルチメディアサブシステム（IMS）内に含まれることができる。IPマルチメディアコアネットワーク（IMCN）サブシステム220を介してSIP再招待を受信後、SCFモジュールは、HTTPに基づく配信のためのHTTPサーバ260を選択するために、SIP招待（SIP  invitation）をHTTP/SIPアダプタ250に送信することができる。ここで、SIP招待は、要求URIを含んだSIPのINVITEメッセージを含むことができる。SCFモジュールは、その前には、放送マルチキャストサービスセンタ（BMSC）またはBMSCユーザプレーンサブ機能（UPF）（BMSC.UPF）240に関連付けられた（または、を参照する）ドメイン名またはコンテンツ識別子を、BMSCを介したDASHフォーマット化コンテンツのMBMSダウンロードを確立するために使用していた。
【００１４】
HTTPサーバを参照するドメイン名およびコンテンツ識別子は、BMSCに関連付けられたドメイン名およびコンテンツ識別子とは異なることができる。SCFモジュール230はまた、コンテンツ配信セッションのためのMBMSダウンロードを終了させるために、BMSCに終了要求を送信することができる。HTTP/SIPアダプタは、その前にはMBMSダウンロード用に使用されていた同じコンテンツ配信セッションのために、DASHフォーマット化コンテンツのHTTPに基づく配信用のHTTPサーバを準備することができる。HTTP/SIPアダプタは、SCFモジュールにSIPの確認を送信して、コンテンツ配信セッション用のHTTPサーバの選択を示すことができる。SIPの確認は、SIP  200  OKメッセージを含むことができる。SCFモジュールは、SIPの確認を、IM  CNサブシステムを介して、移動デバイスに転送して、コンテンツ配信セッション用HTTPサーバへの切換えを示すことができる。すると移動デバイスは、MBMSダウンロードの代わりに、HTTPに基づいた配信を介して、コンテンツ配信セッションのDASHフォーマット化コンテンツを受信することができる。
【００１５】
DASHフォーマット化コンテンツの、HTTPに基づく配信からMBMSダウンロードへの切換えにおいて、移動デバイスは、コンテンツ配信セッションにおいてDASHフォーマット化コンテンツのHTTPに基づく配信を該移動デバイスが受信している最中に、SIP再招待をSCF  230モジュールに送信することができる。SIP再招待は、同じコンテンツ配信セッション内でMBMSダウンロードを介してDASHフォーマット化コンテンツを提供するためのBMSCまたはBMSC.UPF240のための要求URIを含むことができる。要求URIは、MBMSダウンロードを提供するためのBMSCを特定する（または参照する）ドメイン名またはコンテンツ識別子を含むことができる。IM  CNサブシステム220を介してSIP再招待を受信後、SCFモジュールは、招待メッセージ（invitation  message）をBMSCまたはBMSC.UPFに送信し、コンテンツ配信セッションのMBMSダウンロード用BMSCを初期化（準備）することができる。招待メッセージは、要求URIを含むことができる。ここで、SCFモジュールは、その前には、HTTPサーバを介したDASHフォーマット化コンテンツのHTTPに基づいた配信を確立するためにHTTPサーバ260に関連付けられた（または、参照する）ドメイン名またはコンテンツ識別子を使用していた。HTTPサーバを参照するドメイン名およびコンテンツ識別子は、BMSCに関連付けられたドメイン名およびコンテンツ識別子とは異なることができる。SCFモジュールは、BMSCがMBMSダウンロード用に準備された後、コンテンツ配信セッション用BMSCの選択を示すBMSCの確認をBMSCから受信することができる。SCFモジュールは、HTTPサーバを解除するために、そして／または、コンテンツ配信セッションのためのHTTPに基づく配信を終了させるために、SIP終了要求をHTTP/SIPアダプタ250に送信することができる。SIP終了要求は、SIP  BYEメッセージを含むことができる。
【００１６】
HTTP/SIPアダプタは、SCFモジュール230にSIPの確認を送信して、コンテンツ配信セッションのためのHTTPに基づく配信の終了、および／または、コンテンツ配信セッション用BMSCの準備を示す。SIPの確認は、SIP  200  OKメッセージを含むことができる。SCFモジュールは、IM  CNサブシステムを介してSIPの確認を転送して、コンテンツ配信セッションのためのBMSCへの切換えを示すことができる。移動デバイスは、HTTPに基づく配信の代わりに、MBMSダウンロードを介して、コンテンツ配信セッションのDASHフォーマット化コンテンツを受信することができる。
【００１７】
以下では、例についての追加の詳細が提供される。MBMSダウンロード配信は、HTTPに基づくユニキャストダウンロード配信の負荷を減らす代替サービスであり得る。MBMSダウンロード配信を利用することのメリットには、非リアルタイムサービスタイプのサポートを可能にできること、MBMSストリーミングサービスを補完するコンテンツの提供を可能にできること、そして、移動デバイス上の増加する記憶容量を活用できること、が含まれる。DASHセグメント形式は、HTTPに伴うユニキャストトランスポートを主に意図しているが、配信環境がユニキャストか、またはマルチキャストか、非依存型（agnostic）であり得る。DASHフォーマット化コンテンツは、単方向トランスポート上のファイル配信（file  delivery  over  unidirectional  transport）（FLUTE）プロトコルを用いたMBMSダウンロード配信を使って送信することができる。
【００１８】
FLUTEは、インターネット上のファイルの単方向配信のためのプロトコルであり得、マルチキャストネットワークに特に適するようにできる。FLUTEは、非常にスケーラブルなマルチキャスト配信のために設計された基本プロトコルである非同期階層符号化（asynchronous  layered  coding）（ALC）上に構築できる。FLUTEは、階層符号化トランスポート（LCT）ビルディングブロックのインスタンス化を提供できる。ALCプロトコルは、LCTビルディングブロック、輻輳制御（CC）ビルディングブロック、および順方向誤り訂正（FEC）ビルディングブロックを組み合わせて、輻輳が制御された信頼性のある非同期配信を提供することができる。LCTは、信頼性のあるコンテンツ配信およびストリーム配信プロトコルのためのトランスポートレベルのサポートを提供することができる。ストリーミングデータまたはダウンロードは、MBMSベアラ上で配信する際に、リアルタイムトランスポートプロトコル（RTP）の中にカプセル化され、FLUTEプロトコルを利用して搬送されることができる。RTPは、テレフォニー、ビデオ会議アプリケーション、テレビジョンサービス、およびウェブに基づくプッシュツートーク機能、等のストリーミングメディアを伴う通信および娯楽システムにおいて利用することができる。
【００１９】
３つの機能階層が、MBMSに基づくサービスの配信のために利用することができる。３つの機能階層は、ベアラ階層、配信方式階層、そして、ユーザサービス階層またはアプリケーション階層を含むことができる。ベアラ階層は、IPデータを搬送するメカニズムを提供することができる。ベアラは、ユニキャストベアラまたはMBMSベアラを含むことができる。配信階層は、セキュリティや鍵配布等の機能、順方向誤り訂正（FEC）技術による信頼性制御、そして、ファイル修復、配信検証等の関連配信手順を提供することができる。配信方式は、ダウンロードやストリーミングを含むことができる。MBMSユーザサービスはアプリケーションを可能にできる。ユーザサービスは、マルチメディアメッセージングサービスやパケット交換ストリーミングサービス（PSS）を含むことができる。
【００２０】
HTTP上のDASHベースの適応ストリーミングは、リアルタイムストリーミングプロトコル（RTSP）ベースの適応ストリーミングとは異なり得る。RTSPは、娯楽および通信システムにおいてストリーミングメディアサーバを制御するために使われるネットワーク制御プロトコルであり得る。RTSPプロトコルは、エンドポイント間のメディアセッションを、プッシュベースおよびサーバ制御方式で確立及び制御するために使用され得る。一方、DASHベースの適応ストリーミングは、プルベースおよびクライアント制御であり得る。メディアサーバのクライアントは、サーバからのメディアファイルの再生のリアルタイム制御を容易にするために、再生や停止等のビデオカセット録音機（VCR）のようなコマンドを発行することができる。いくつかの点でHTTPと類似している一方、RTSPは、マルチメディア再生の制御において役立つ制御シーケンスを定義することができる。HTTPがステートレス（stateless）であり得る一方、RTSPは、並行セッションを追跡する必要があるときに利用される状態または識別子を持つことができる。
【００２１】
DASHベースの適応ストリーミング技術の使用に先立って、標準のHTTPウェブサーバから、メディア配信のために漸進的ダウンロード方式もまた利用可能であった。HTTPベースの漸進的ダウンロードのデメリットとしては、もし、漸進的ダウンロードが始まってからコンテンツの視聴を中止すること（例えば、別のコンテンツへの切り換え）をユーザが決定したならば帯域幅が無駄にされ得ること、ダウンロードは必ずしもビットレート適応ではないこと、または、ダウンロードはライブメディアサービスをサポートしないこと、を含み得る。DASH技術は、RTP/RTSPベースのストリーミングおよびHTTPベースの漸進的ダウンロードの弱点に対処し得る。
【００２２】
DASHにおいては、メディアプレゼンテーション記述（MPD）メタデータファイルは、構造と、サーバに格納されたメディアコンテンツ表現の様々なバージョンと、についての情報を提供し得る。ここで、様々なバージョンは、様々なビットレート、フレームレート、解像度、コーデックの種類、および類似の情報を含む。MPD情報は、プレゼンテーションと他の表現との切換え及び同期のための、セグメントからメディアプレゼンテーション時系列へのマッピングを確実にするために使用され得る。加えて、DASHはまた、メディアエンジンのための初期化およびメディアセグメントに関する情報等のセグメントフォーマットを特定できる。メディアエンジンは、初期化セグメントを観て、コンテナフォーマットおよびメディアタイミング情報を決定することができる。
【００２３】
DASH技術の例として、マイクロソフト社のIISスムーズストリーミング、アップル社のHTTPライブストリーミング、およびアドビー社のHTTPダイナミックストリーミングを含むことができる。DASH技術はまた、第３世代パートナーシッププロジェクト（3GPP）、動画エキスパートグループ（MPEG）、およびオープンIPTVフォーラム（OIPF）等の団体によって標準化されてきた。
【００２４】
適応ストリーミングセッションまたはコンテンツ配信セッションの全体に対して一貫したユーザ体験を提供するために。移動デバイスは、パケット交換ストリーミングサービス（PSS）とMBMSカバレージとの間の変化等の特定の状況に応じて、あるいは、トリック再生等の特定のユーザ操作をトリガーとして、HTTPベースの配信とMBMSダウンロードとの間で切り換えることができる。トリック再生またはトリックモードは、早送り、早巻き戻し、スローモーション、スロー巻き戻し、ポーズおよび再開を含むことができる。トリック再生またはトリックモードは、移動デバイスによって受信されたセグメントの処理に基づくことができる。受信した（またはダウンロードされた）セグメントは、セグメントの計画通りの時系列（内部タイムスタンプ）が命じるよりも遅いまたは早いスピードで、デコーダに提供され得る。その結果、スクリーンまたはメディアプレゼンテーション上に所望のトリック効果を生成する。
【００２５】
移動デバイスは、MBMSダウンロードの、またはHTTPベースのDASHフォーマット化コンテンツ配信のセッションをすでに確立していることが可能である。移動デバイスは、他の配信方式に切り換えることが可能であり得る。たとえば、もしMBMSダウンロードを受信しているのであればHTTPベースの配信に、または、もしHTTPベースの配信を受信しているのであればMBMSダウンロードに、切り換えることが可能であり得る。MBMSダウンロードからHTTPベースの配信方式への切換えのための適切な切換えイベントの例は、チャネルの変更無しで提供されることもできるし、チャネルの変更有りで提供されることも可能である。例えば、チャネルの変更無しで、ユーザは、MBMSユーザサービスを見ていて、MBMSカバレージから外に出てもよい。あるいは、ユーザは、トリック再生モード操作を開始してHTTPベースの配信への切換えを促進してもよい。別の例においては、コンテンツは、チャネルの変更を伴うパケット交換ストリーミング（PSS）／DASH上でのみ利用可能であり得る。HTTPベースの配信方式からMBMSダウンロードへの切換えのための適切な切換えイベントの例は、チャネルの変更無して提供されることもできるし、チャネルの変更有りで提供されることも可能である。例えば、チャネルの変更無しで、ユーザは、トリック再生モードから通常のMBMSユーザサービスに戻り得る。別の例においては、コンテンツは、チャネルの変更を伴うMBMS上でのみ利用可能であり得る。
【００２６】
図１は、IMSベースのPSSおよびMBMSユーザサービスの機能アーキテクチャを示している。MBMSダウンロードとHTTPベースのDASH配信との間の切換えを促進する機能ブロックは、IM  CNサブシステム220、UE  210、SCF  230、HTTP/SIPアダプタ250、HTTPサーバ260、BMSC.UPF240、ポリシーおよび課金規則機能（PCRF）270モジュール、サービス選択機能（SSF）290モジュール、および、PSSアダプタ292を含み得る。IMSベースのPSSおよびMBMSユーザサービスの機能アーキテクチャの他の機能ブロックは、進化したパケットコア（evolved  packet  core）（EPC）/パケット交換ストリーミング（PS）/RAN  280である。EPCあるいはシステムアーキテクチャエボリューション（system  architecture  evolution）（SAE）は、モビリティ管理エンティティ（mobility  management  entity）（MME）、サービングゲートウェイ（SGW）、およびパケットデータネットワーク（PDN）ゲートウェイ（PGW）を含み得る。
【００２７】
IM  CNサブシステム220は、ユーザ登録および認証、モビリティおよびローミング、マルチメディアセッションの制御、サービス品質（QoS）制御、ポリシー制御、課金、および／または、回線交換ネットワークとの相互作用（interworking）をサポートすることができる。UE  210は、汎用のブートストラッピングアーキテクチャ（generic  bootstrapping  architecture）（GBA）/IMS/PSS/MBMSクライアントを含むことができる。ここで、GBA/IMS/PSS/MBMSクライアントは、サービスディスカバリおよび選択、サービス開始の扱い、変更および終了、および／または、コンテンツの受信とユーザへの提供を実行することができる。
【００２８】
SCF  230は、サービスロジックおよび該サービスロジックの実行をサポートする機能を提供することができる。SCFは、セッション開始およびセッション変更中にサービスの承認を提供することができ、該承認は、サービスへのアクセスを許可または拒否するためにPSSおよびMBMSユーザのサービス加入のチェックを含むことができる。SCFは、関連するPSSおよびMBMSメディア機能を選択することができる。HTTPベースの配信にとって、SCFは、プロキシとして、または、バックツーバックユーザーエージェント（back-to-back  user  agent）（B2BUA）としてふるまえる。MBMSにとって、SCFは、終端するユーザーエージェント（UA）としてふるまえる。HTTP/SIPアダプタ250は、SIPセッションとHTTP着信要求とを相互に関連付ける。HTTPサーバ260は、HTTPベースの配信用のDASHフォーマット化コンテンツを提供することができる。RCRF  270モジュールは、課金および、RANおよびPSコアネットワーク280におけるリソースの確立を制御することができる。SSF  290モジュールは、利用可能なPSS（HTTPベースのDASHを含む。）およびMBMSユーザサービスのリストと関連するユーザサービス加入情報を提供することができる。SSFモジュールは、クライアントの独自性（identity）に合わせた個人的なものにすることができる。PSSアダプタ292は、SIPとRTSPとの間の双方向プロトコル変換を実行して、PSSサーバの制御を提供することができる。BMSC.UPF240は、放送マルチキャストサービスセンタ（BMSC）ユーザープレーンサブ機能（user  plane  sub-functions）（UPF）を含むことができる。BMSC.UPFは、MBMSダウンロード用のDASHフォーマット化コンテンツを提供することができる。
【００２９】
図２は、BMSCサブ機能アーキテクチャと、UEとBMSCとの間の関連するインターフェイスとを示す。BMSCまたはBM-SC  242は、コンテンツプロバイダ／マルチキャスト放送リソース246と通信する、または制御することができる。BM-SCは、MBMS配信機能244を提供することができる。
【００３０】
図３は、IMSベースのコンテンツ配信セッションにおける、DASHフォーマット化コンテンツの、MBMSダウンロードからHTTPベースの配信への切換えの例を示している。FLUTEベースのMBMSダウンロード300a乃至300c配信がその前に開始されていることができ得る。そして、UE  210は、BMSC.UPF  240からDASHフォーマット化コンテンツを受信し得る。MBMSダウンロードは、コンテンツを配信するためにMBMSユーザサービスによって使用される仕組みであり得る。MBMSダウンロードは、コンテンツの配信においてMBMSベアラを使用するMBMS配信方式を参照することができ、関連する手順を活用し得る。ここで使用されるMBMSダウンロード方式は、連続するメディア（例：リアルタイムビデオ）の配信にも、個別オブジェクト（例：ファイル）の配信にも、どちらにも適用することが可能である。
【００３１】
UE  210は、MPD取得後にHTTPサーバからメディアセグメントを取ってくることによってHTTPストリーミングを開始し得る。MBMSダウンロードからDASHフォーマット化コンテンツのHTTPベースの配信へと切り換えるために、セッション開始プロトコル（SIP）のRe-INVITE  302がUEによって発行され、IM  CNサブシステム220に送信され得る。セッション記述プロトコル（SDP）オファー（offer）と要求統一リソース識別子（URI）がSIP  Re-INVITEメッセージに含まれ得る。
【００３２】
要求URIは、ユーザがアクティブにしたいと望んでいるHTTPベースの配信セッションまたはSIPセッションに関係することができる。要求URIは、ユーザ部分とドメイン部分とで構成されることができる。ユーザ部分は、SSFモジュールからのユーザサービス記述情報から検索されたコンテンツ識別子を含むことができる。コンテンツ識別子は、サービス選択情報から検索され得る。ドメイン部分は、SSFモジュールから得られたサービスプロバイダドメイン名を含むことができる。SIP  Re-INVITE  302および304、またはINVITE  306メッセージの「To」ヘッダは、要求URIにおけるURIと同じURIを含むことができる。SIP  Re-INVITEまたはINVITEメッセージの「From」ヘッダは、ユーザの公開ユーザ識別を示すことができる。コンテンツ識別子は、サービス選択情報から検索することができる。
【００３３】
SDPオファーは、HTTPストリーミング用に利用可能なメディア能力およびポリシーを含むことができる。例えば、SDPオファーは、推奨サービスのタイプ（例：PSS、MBMS、またはHTTPストリーミングサービス）、コンテンツ識別子、および、対象UEの識別子を示すパラメータを運ぶことができる。SDPオファーは、サービス選択手順中にSSFモジュールから受信したパラメータに基づいて導出され得るとともに、MPDの解析に基づいて導出され得る。SDPオファーは、SIP  OPTIONSメッセージによる不足パラメータの検索のための手順中に受信したパラメータに基づいて導出され得る。
【００３４】
UEは、MBMSダウンロード中にMPDをすでに取ってき得るので、HTTPサーバへのMPDの要求は必要ではないかもしれない。一例においては、もし、MPDがその前にすでに取得されていないならば、UEは、MPDをダウンロードするために、HTTP  GET要求をHTTPサーバに送信し得る。他の例においては、SDPオファーは、その前にネゴーシエイトした、ポートがゼロに設定されたメディア記述と、２以上の追加のメディア記述とを含み得る。例えば、メディア記述は、メディア制御チャネル（すなわち、MPD配信チャネル）およびメディア配信チャネル（すなわち、HTTP上のユニキャストストリーム用の配信チャネル）を含むことができる。SDPオファーは、メディア記述、メディア制御チャネル、メディア配信チャネル、MPD制御チャネル、HTTP上のユニキャストストリーム用の配信チャネル、HTTPサーバで利用可能なメディア能力、HTTPサーバで利用可能なポリシー等のHTTP-ベースの配信のための情報と、この情報の組合せとを含むことができる。
【００３５】
別の例においては、メディア配信用のSDPオファーは、その前に行われた放送用のSDPオファーと、コーデックおよびトランスポートプロトコルの点で同様であり得る。HTTPベースの配信はTCP上で実行できる。一方、FLUTEベースのMBMSダウンロード配信は、ユーザデータグラムプロトコル（UDP）上で実行できる。TCPおよびUDPは、トランスポートレイヤにおけるプロトコルであり得る。下にあるプロトコルの変化、たとえばUDPからTCPへの変化は、SDPにおいて示すことができる。UDPは、インターネットプロトコル群のメンバーの一員である。UDPでは、コンピュータアプリケーションは、特別な伝送チャネルやデータ経路を準備するための事前の通信を要することなく、IPネットワーク上で、データグラムと称されるメッセージを他のホストに送信することができる。
【００３６】
IM  CNサブシステム220は、SIP  Re-INVITE  304メッセージをSCF  230に転送し得る。SIP  Re-INVITEにおいてSIP変更要求を受信したとき、SCFは、現在放送されているプログラムに、MBMSからHTTPへの切換えのサポート（「MBMSからHTTPへ」の切換えサポート）があるか否かを判断することができる。もし、MBMSからHTTPへの切換えがUE  210にとって利用可能でないならば、セッション変更は拒否されることができ、もともとのMBMSダウンロードまたはセッションが（その前に確保されているリソースとともに）維持され得る。
【００３７】
もし、MBMSからHTTPへの切換えがUE  210にとって利用可能ならば、SCF  230はB2BUAとしてふるまうことができる。UEからSIP  Re-INVITE  304を受信すると、SCFは、要求されたDASHフォーマット化コンテンツに対するユーザの権限を確認または検証し、要求がHTTPストリーミングのためであることを特定し、HTTP/SIPアダプタ250を選択し、そして、SIP要求（SIP  INVITE  306）をHTTP/SIPアダプタに転送することができる。該HTTP/SIPアダプタは、それに応じて要求URIを変えることによりHTTPストリーミングサービスを担当し得る。HTTP/SIPアダプタから301または302応答を受信したとき、SCFは、301または302応答メッセージをUEに転送しないかもしれない。もし、コンテンツ要求がHTTP/SIPアダプタによって管理されていないならば、HTTP/SIPアダプタは301応答を返すことができる。HTTP/SIPアダプタは、コンテンツ要求を管理していない（301応答）という理由以外のいかなる他の理由に対しても、302応答を返すことができる。例えば、302応答メッセージは、負荷バランシング（load  balancing）という理由のために送信され得る。
【００３８】
もし、要求URIが、ユーザ部分にコンテンツ識別子を含み、ドメイン部分にドメイン名を含むならば、SCF  230は、適切なHTTP/SIPアダプタ250を選択し、選択されたHTTP/SIPアダプタへのSIP  INVITE  306要求を生成することができる。SIP  INVITE要求の「To」ヘッダは、UE  210からSCFが受信したSIP変更要求の要求URI内のコンテンツ識別子と同じコンテンツ識別子を含むことができる。
【００３９】
SCF  230は、HTTPストリーミングセッション用に利用可能なメディア能力およびポリシーを含むSDPパラメータと一緒に、SIP  INVITE  306要求をHTTP/SIPアダプタ250に送信することができる。SIP  INVITE要求は、MPDの解析に基づいて導出され得る。一例において、SDPオファーは、その前にネゴーシエイトされた、ポートがゼロに設定されたメディア記述と、２以上の追加的なメディア記述を含み得る。例えば、メディア記述は、メディア制御チャネル（例：MPD配信チャネル）およびメディア配信チャネル（例：HTTP上のユニキャストストリームのための配信チャネル）を含むことができる。
【００４０】
SCF  230は、BMSC.UPF  240とUE  210との間のFLUTEベースのMBMSダウンロードセッションを終了させることができる。SCFは、MBMS終了310要求またはメッセージをBMSC.UPFに送信することができる。SCFとBMSC.UPFとの間の通信プロトコルは、2011年3月に公表された3GPP技術仕様書（TS）26.346  V10.0.0によって定義されることができる。BMSC.UPFは、いかなるコンテンツプロバイダ／マルチキャスト放送リソース（図２の246）を解放してもよく、MBMSダウンロードを終了し得る。BMSC.UPFは、成功した終了を示す確認（ACK）312メッセージをSCFに送信することができ、また、失敗した終了またはリソースの解放を示す否定的な確認（NACK）メッセージをSCFに送信することができる。
【００４１】
HTTPストリーミングセッション開始要求（例：SIP  INVITE306）を受信すると、HTTP/SIPアダプタ250は、「To」ヘッダのユーザ部分内にあるコンテンツ識別子と、SDP内のメディアパラメータを調べ、要求URIに従ってHTTPサーバ260を選択できる。HTTP/SIPアダプタは、UEのIPアドレスを含むHTTP  POSTメッセージをHTTPサーバに送信できる。HTTP/SIPアダプタは、別のHTTP/SIPアダプタサーバに、要求をリダイレクトすることを決めてもよい。別のHTTP/SIPアダプタサーバに要求をリダイレクトする場合は、HTTP/SIPアダプタは、もしコンテンツがこのHTTP/SIPアダプタによって管理されていないのであれば301応答を、または、負荷バランシング等のいかなる他の理由に対しては302応答を、返すことができる。リダイレクトするHTTP/SIPアダプタは、コンタクトヘッダ内で、１以上の宛先HTTP/SIPアダプタアドレスを示すことができる。
【００４２】
HTTP/SIPアダプタ250は、SIP  OK  308メッセージ（例：SIP  200  OKメッセージ）等のSIP確認メッセージをSCF  230に返すことができる。SIP確認は、SDP  アンサー  （answer）を含むことができる。SDPアンサーは、HTTPストリーミングセッション（またはSIPセッション）を記述することができる。SDPアンサーは、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、配信記述等のHTTPベースの配信のための情報と、この情報の組合せとを含むことができる。
【００４３】
SCF  230は、SIP  OK  314をIM  CNサブシステム220に転送することができる。IM  CNサブシステムは、QoSベアラエンフォースメント（QoS  bearer  enforcement）316aのためのQoS予約を約束するために、ポリシー課金および制御（PCC）アーキテクチャのポリシー課金およびルール機能（PCRF）270モジュールとやりとりすることができる。PCRFモジュールは、UEとIMSとの間のQoSベアラエンフォースメント316b-dを提供することができる。IM  CNサブシステムは次に、SIP  OK  318（例：SIP  200  OKメッセージ）をUE  210に転送することができる。
【００４４】
プロキシコールセッション制御機能（P-CSCF）は、PCCアーキテクチャにおけるアプリケーション機能として使用され得る。PCRF  270は、IMSが開始し制御するPSSおよびMBMSユーザサービスに対してQoSのポリシー制御がどのように実行されるかを決定することができる。PCRFは、適切なQoS承認を計算するために、セッション確立中にP-CSCFから受信したSDPを利用することができる。適切な既存のベアラが使用されることができる、または、新しい必要なベアラがPCRFによって割り当てられることができる。ネットワークによって開始されるベアラ制御およびUEによって開始されるベアラ制御が可能であり得る。最後のSDPを受信すると、UE  210は、ネットワークが開始したベアラ割当て手順がすでに進行しているのでなければ、必要なベアラの確立を開始し得る。もう一つの方法として、UEはネットワークが開始するリソース制御を利用するように構成される。
【００４５】
SIP  OK  318の受信後、UE  210は、マルチキャストチャネルを離れ、予約済みのQoSを利用してメディアセグメントがUEに配信されるように、HTTP上のDASHフォーマット化コンテンツのダウンロード（適応HTTPベースDASHコンテンツ配信320a-c）を開始することができる。
【００４６】
別の例において、DASHフォーマット化コンテンツの、MBMSダウンロードとHTTPベースの配信との間の切換えを許容できるように、UE等の移動デバイスとeNB等の送信局との間の無線インターフェイスは、コンテンツのユニキャストおよびマルチキャスト配信をサポートし得る。RANのeNBは、IMSおよび、SCFモジュール等のIMS内のモジュールと通信することができる。無線インターフェイスは、3GPP  LTEまたは802.16規格を含むことができる。移動デバイス、および／または、送信局は、3GPP  LTEまたは802.16プロトコルを利用することができる。3GPP  LTE規格は、LTE  Rel-8（2008）、LTE  Rel-9（2009）およびLTE  Rel-10（2011）を含むことができる。IEEE  802.16規格は、IEEE  802.16e-2005、IEEE  802.16k-2007、IEEE  802.16-2009、IEEE  802.16j-2009、IEEE  802.16h-2010、およびIEEE  802.16m-2011を含むことができる。
【００４７】
図４は、コンテンツ配信セッションにおける、DASHフォーマット化コンテンツの、MBMSダウンロードからHTTPベースの配信への切換えの一例が示されている。ここでは、MPDメタデータファイルが、SIP  Re-INVITEに先立って取得されている。UE  210は、HTTPサーバ260からのMPD  322を要求することができる。HTTPサーバは、MPD  324をUEに送信することができる。UEは、MPD内の情報を使って、IM  CNサブシステム220に送信されるSIP  Re-INVITE  302を生成することができる。図４における動作の残りの部分は、図３の動作と同様であり得る。図３の動作については以前に議論されている。
【００４８】
図５は、コンテンツ配信セッションにおける、DASHフォーマット化コンテンツの、HTTPベースの配信からMBMSダウンロードへの切換えの一例を示している。HTTPベースの配信（例：適応HTTPベースDASHコンテンツ配信330a-c）が、その前に開始されており、UE  210は、HTTPサーバ260から、HTTP上でDASHフォーマット化コンテンツを受信していてよい。DASHフォーマット化コンテンツは、既存のSIPセッションにおいて配信されていてよい。
【００４９】
DASHフォーマット化コンテンツの、HTTPベースの配信からMBMSダウンロード受信へ切り換えるために、SIP  Re-INVITE  332等のセッション変更要求がUE  210によって発行され、IM  CNサブシステム220に送信され得る。SIP  Re-INVITEメッセージには、選択されたMBMSダウンロードサービスとFLUTEセッション情報とを示しているセッション記述プロトコル（SDP）オファーと、要求統一リソース識別子（URI）とが含まれ得る。SDPオファーは、UEサービス選択手順中に受信されたパラメータに従って、また、MBMSダウンロードサービスのために利用可能なメディア能力と必要帯域幅とに従って、実行することができる。一例において、メディア配信用のSDPオファーは、その前に行われたHTTPベースの配信用のSDPオファーと、コーデックおよびトランスポートプロトコルの点で同様であり得る。SDPオファーは、メディア記述、メディア制御チャネル、メディア配信チャネル、MPD制御チャネル、MBMS上のマルチキャストストリームのための配信チャネル、BMSCで利用可能なメディア能力、BMSCで利用可能なポリシー等のMBMSダウンロードのための情報と、この情報の組合せとを含み得る。
【００５０】
別の例において、MPDは、HTTPベースの配信からMBMSダウンロード配信へ切り換えるための情報を含み得る。そして、UEは、MBMSダウンロードへ切り換えるために、SIP  Re-INVITE等のセッション変更要求を発行するときに、そのような情報を利用し得る。SIP  Re-INVITEメッセージはまた、MBMSダウンロードサービスの公開サービス識別子（public  service  identifier）（PSI）を含むことのできる要求URIを含むことができる。SIP  Re-INVITEの「To」ヘッダは、要求URI内のURIと同じURIを含むことができ、SIP  Re-INVITEの「From」ヘッダは、ユーザの公開ユーザ識別を示すことができる。
【００５１】
IM  CNサブシステム220は、SIP  Re-INVITE  334メッセージをSCF  230に転送することができる。SIP  Re-INVITE要求を受信すると、SCFは、要求されたMBMSダウンロードサービスのサービス権限をユーザの加入情報に従って確認するために、サービス承認手順を実行することができる。
【００５２】
SIP変更要求（例：SIP  Re-INVITE）を受信したとき、SCF  230は、現在配信されているコンテンツに、HTTPからMBMSへの切換えサポート（例：「HTTPからMBMSへ」の切換えサポート）があるか否かを判断することができる。もし、HTTPからMBMSへの切換えが、UE  210にとって利用可能でないならば、セッション変更は拒否され得、もともとのHTTPセッションが（その前に確保されているリソースとともに）維持され得る。もし、HTTPからMBMSへの切換えが、UE  210にとって利用可能ならば、BMSC.UPFとUEとの間にFLUTEベースのMBMSダウンロードセッションを確立するために、SCFはB2BUAとしてふるまい得る。SCFとBMSC.UPFとの間の通信プロトコルは、2011年3月に公表された3GPP技術仕様書（TS）26.346  V10.0.0によって定義することができる。SCFはMBMS招待（MBMS  invitation）340をBMSC.UPFに送信することができる。BMSC.UPFがMBMSダウンロードのために準備できたとき、BMSC.UPFは、MBMS確認342メッセージをSCFに送信することができる。もし、HTTPからMBMSへの切換えがUEにとって利用可能であれば、SCFとHTTP/SIPアダプタとの間のSIPセッションを終了させるために、SCFは、SIP  BYE  336メッセージ（HTTP終了要求）をHTTP/SIPアダプタ250に送信することができる。
【００５３】
次に、HTTP/SIPアダプタ250は、HTTPサーバ260を解放することができる。そして、SIP  OK  338メッセージのようなSIP確認メッセージをSCF  230に送信することができる。ひとたびSIP  OKメッセージをHTTP/SIPアダプタから受信すると、SCFは、SIP  OK  344メッセージをIM  CNサブシステム220に送信することができる。SIP確認は、SDPアンサーを含むことができる。SDPアンサーは、メディア記述、メディア制御チャネル、メディア配信チャネル、メディアプレゼンテーション記述（MPD）制御チャネル、配信記述等のMBMSダウンロードのための情報と、この情報の組合せとを含むことができる。
【００５４】
IM  CN  サブシステム220は、SIP  OK  348メッセージをUE  210に転送することができる。SIP  OKメッセージはSDPアンサーを含むことができる。P-CSCFは、PCCアーキテクチャにおいてアプリケーションとして使われることができる。PCRFは、IMSによって開始制御されるMBMSユーザサービスおよびQoSベアラエンフォースメント用の通信（図３に示されたIM  CNサブシステム、PCRFモジュール、およびUEとの間のQoSベアラエンフォースメント  316a-d用の処理と同様）に対して、QoSのポリシー制御がどのように実行されるかを決定することができる。MBMSダウンロードへの切換えのために、PCRFは、特定のベアラの確立を開始しなくてよい。
【００５５】
ひとたびUE  210がSIP  OK応答を受信すると、UEは、SDPにおいて記述された対応するMBMSユーザサービス、例えば、FLUTE  350a-cに基づいたMBMSダウンロードサービス、をアクティブにすることができる。MBMSダウンロード受信の開始は、MBMSブロードキャストモード活性化手順、または、MBMSマルチキャストモード活性化手順に準じてもよい。UEは、受信したSDP内のFLUTEセッションパラメータを調べることができ、それに応じてMBMSダウンロードデータを受信することができる。ファイル配信テーブル（FDT）が利用可能でないような場合は、UEは、SDPアンサー内のfdt_address属性に従ってFDTを得ることができる。FDTは、FLUTEセッションにおいて配信されるファイルのためのコンテンツ記述情報を含むことができる。不完全なダウンロードの場合は、UEは、SDPアンサー内のrepair-server-address属性によって示される修復サーバに対してファイル修復手順を実行することができる。
【００５６】
MBMSダウンロードとHTTPベース配信との間の切換えは、特定の無線インターフェイス（例、RAN）特性に依存しない（agnostic）ことができる。関連するネットワークがIMSベースのHTTP配信およびMBMSダウンロード配信機能を主催することができる限り、いかなる無線インターフェイスまたは複数の無線インターフェイスの組合せであっても適用可能である。MBMSダウンロードとHTTPベース配信との切換えは、3GPPベースまたは802.16ベースの無線広域ネットワーク（WWANs）、およびIMSベースのアプリケーションにおいて、これらのネットワーク上で、最適化されたDASHフォーマットマルチメディアコンテンツ配信が望まれる場合に、利用することができる。DASHフォーマット化コンテンツをストリーミングするための、HTTPベースの配信とMBMSダウンロード配信との間の切換えを可能にするシグナリング手順は、ユーザにとっての経験の質を改善できる。
【００５７】
別の例が、図６のフローチャートに示されるように、HTTP上ダイナミック適応ストリーミング（DASH）フォーマット化コンテンツの、マルチメディア放送マルチキャストサービス（MBMS）ダウンロードから、ハイパーテキスト転送プロトコル（HTTP）ベースの配信への切換えのための方法500を提供する。この方法は、ブロック510に示されるように、DASHフォーマットを含むコンテンツ配信セッションにおけるMBMSダウンロードを移動デバイスが受信している時に、移動デバイスからのセッション開始プロトコル（SIP）re-invitation（再招待）を、サービス制御機能（SCF）モジュールで受信する動作を含む。ブロック520に示されるように、SIP  invitation（招待）をSCFモジュールからHTTP/SIPアダプタに送信し、HTTPベースの配信用のHTTPサーバを選択する動作が続く。この方法の次の動作は、ブロック530に示されるように、SCFモジュールで、HTTP/SIPアダプタからの、コンテンツ配信セッション用HTTPサーバの選択を示すSIP確認を受信することであることができる。この方法はさらに、ブロック540に示されるように、SCFモジュールからのSIP確認を移動デバイスに転送し、コンテンツ配信セッション用HTTPサーバへの切換えを示すことを含むことができる。
【００５８】
別の例が、図７のフローチャートに示されるように、HTTP上ダイナミック適応ストリーミング（DASH）フォーマット化コンテンツの、ハイパーテキスト転送プロトコル（HTTP）ベースの配信から、マルチメディア放送マルチキャストサービス（MBMS）ダウンロードへの切換えのための方法600を提供する。この方法は、ブロック610に示されるように、移動デバイスが、DASHフォーマットを含むコンテンツ配信セッションにおけるHTTP配信を受信している時に、移動デバイスからのセッション開始プロトコル（SIP）re-invitation（再招待）をサービス制御機能（SCF）モジュールで受信する、動作を含む。ブロック620で示されるように、invitation（招待）メッセージをSCFモジュールからBMSCへ送信し、放送マルチキャストサービスセンタ（BMSC）をMBMSダウンロード用に初期化する動作が続く。この方法の次の動作は、ブロック630に示されるように、SIP終了要求をSCFモジュールからHTTP/SIPアダプタへ送信し、HTTPベースの配信を終了させることであることができる。ブロック640に示されるように、HTTPベースの配信の終了を示すSIP確認を、SCFモジュールがHTTP/SIPアダプタから受信する動作が続く。この方法はさらに、ブロック650に示されるように、コンテンツ配信セッション用BMSCへの切換えを示すSIP確認を、SCFモジュールから移動デバイスに転送することを含むことができる。
【００５９】
別の例では、SCFは、マルチキャストからユニキャストへのセッション変更要求を受信するように構成された送受信モジュールを含むことができる。ここで、送受信機は、図３に示されたSCFに関連する動作を実行することができる。SCFの送受信機モジュールは、ユニキャストからマルチキャストへのセッション変更要求を受信するように構成されることができる。ここで、送受信機は、図５に示されたSCFに関連する動作を実行することができる。
【００６０】
別の例において、移動デバイスは、マルチキャストからユニキャストへのセッション変更要求をIM  CNサブシステムに送信するように構成された送受信機を含むことができる。ここで、送受信機は、図３に示された移動デバイスに関連する動作を実行することができる。移動デバイスの送受信機モジュールは、ユニキャストからマルチキャストへのセッション変更要求を送信するように構成されることができる。ここで、送受信機は、図５に示された移動デバイスに関連する動作を実行することができる。送受信機は、SIP確認またはSIP終了メッセージをIM  CNサブシステムから受信するように構成されることができる。移動デバイスは、MBMSダウンロードと、DASHフォーマット化コンテンツ用HTTPベースの配信との間を切り換えるように構成された処理モジュールを含むことができる。
【００６１】
別の例において、送信局は、移動デバイスと無線通信していることができる。図８は、ユーザ装置（UE）、移動局（MS）、移動無線デバイス、移動通信デバイス、タブレット、ハンドセット、あるいは、移動無線デバイスの他のタイプ、等の移動デバイスの例示を提供する。移動デバイスは、基地局（BS）、発展型ノードB（eNB）、ベースバンドユニット（BBU）、遠隔無線ヘッド（RRH）、遠隔無線装置（RRE）、中継局（RS）、無線装置（RE）、または、無線広域ネットワーク（WWAN）アクセスポイントの他のタイプ、等のノード、マクロノード、低パワーノード（LPN）、または、送信局と通信するように構成された１以上のアンテナを含むことができる。移動デバイスは、3GPP  LTE、WiMAX、ハイスピードパケットアクセス（HSPA）、ブルートゥース、およびWiFiを含む少なくとも１つの無線通信標準を使って通信するように構成されることができる。移動デバイスは、各無線通信標準のための別々のアンテナ、または、複数の無線通信標準のための共通のアンテナを使って通信することができる。移動デバイスは、無線ローカルエリアネットワーク（WLAN）、無線パーソナルエリアネットワーク（WPAN）、および／または、WWANにおいて、通信することができる。
【００６２】
図８はまた、移動デバイスからの音の入出力のために使用されることができるマイクロフォンと１以上のスピーカの図を提供する。表示スクリーンは、液晶ディスプレイ（LCD）スクリーン、または、有機発光ダイオード（OLED）ディスプレイ等の表示スクリーンの他のタイプであり得る。表示スクリーンは、タッチスクリーンとして構成されることができる。タッチスクリーンは、容量性、抵抗性、またはタッチスクリーン技術の他のタイプを使用し得る。アプリケーションプロセッサおよびグラフィックプロセッサが内部メモリに結合され、処理能力および表示能力を提供する。また、不揮発性メモリーポートが移動デバイスのメモリ能力を拡張するために使用され得る。キーボードが移動デバイスと統合され得、または、ワイヤレスで移動デバイスに接続され得、追加のユーザ入力を提供する。また、仮想キーボードが、タッチスクリーンを使って提供され得る。
【００６３】
様々な技術、または、その様々な技術のある観点または部分、は、フロッピー（登録商標）ディスク、CD-ROM、ハードドライブ、非一時的コンピュータ可読記憶媒体、あるいはいかなる他の機械可読記憶媒体等の有形媒体の中に埋め込まれたプログラムコード（すなわち、命令）の形をとり得る。ここで、そのプログラムコードがコンピュータ等の機械によってロードされ、実行されるとき、その機械は、様々な技術を実行するための装置になる。プログラム可能なコンピュータ上でのプログラムコードの実行の場合、コンピュータデバイスは、プロセッサと、プロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性メモリ、そして／または、記憶要素を含む）と、少なくとも１つの入力デバイスと、そして少なくとも１つの出力デバイスとを含み得る。揮発性および不揮発性メモリ  および／または、記憶要素は、RAM、EPROM、フラッシュドライブ、光ドライブ、磁気ディスクドライブ、または、電気的データを格納するための他の媒体であり得る。基地局および移動局はまた、送受信機モジュール、カウンタモジュール、処理モジュール、そして／または、時計モジュール、またはタイマモジュールを含み得る。ここで説明された様々な技術を実装または利用し得る１以上のプログラムは、アプリケーションプログラミングインターフェイス（API）、再利用可能コントロール、等を利用し得る。そのようなプログラムは、ハイレベルな手続きプログラミング言語、または、オブジェクト指向プログラミング言語で実装され得、コンピュータシステムと通信する。しかし、プログラムは、必要であれば、アセンブリー、または、機械語で実装される。いずれにせよ、言語は、コンパイル言語、またはインタープリタ言語であり得、ハードウェア実装と組合せられている。
【００６４】
理解されるべきは、本明細書で説明された機能ユニットの多くは、その実装の独立性を特に強調するために、モジュールと名付けられてきたということである。例えば、モジュールは、カスタムVLSI回路やゲートアレイ、ロジックチップ、トランジスタ、または他のディスクリート部品を含むハードウェア回路として実装され得る。モジュールはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス、等のプログラマブルハードウェアデバイスにおいて実装され得る。
【００６５】
モジュールはまた、プロセッサの様々なタイプによって実行されるためのソフトウェアにおいて実装され得る。実行可能コードの識別されたモジュールは、例えば、コンピュータ命令の、１以上の物理的または論理的ブロックを含み得る。そしてそれは、例えば、オブジェクト、手続き、または機能として組織される。しかしながら、識別されたモジュールの実行可能形式は、物理的に一緒に置かれている必要はなく、異なる場所に格納された離れ離れの命令を含み得る。離れ離れの命令は、論理的に一緒になったとき、そのモジュールを含み、そのモジュールのための明記された目的を達成する。
【００６６】
確かに、実行可能コードのモジュールは、１つの命令、または多くの命令であり得、いくつかの異なるコードセグメントにわたって、異なるプログラムの中に、そして、いくつかのメモリデバイスにまたがって、分散され得る。同様に、処理データは、本明細書において、モジュール内で識別され説明され得、そして、いかなる適切な形式で具体化され得、いかなる適切なタイプのデータ構造で組織され得る。処理データは、１つのデータの組として集められ得、または、異なる場所にわたって−異なる記憶デバイスにわたることを含む−分散し得、そして、少なくとも部分的に、システムまたはネットワーク上の単なる電子信号として存在し得る。モジュールは、受動的または能動的であり得、所望の機能を実行するように働くことのできるエージェントを含む。
【００６７】
本明細書を通して、「例」という参照は、その例に関連して説明された、特定の特徴、構造、または特性が、本発明の少なくとも１つの実施例に含まれることを意味する。従って、本明細書を通して様々な場所に登場する語句「例において」は、すべて同じ実施例を必ずしも参照するものではない。
【００６８】
本明細書で使用されているように、複数の、項目、構造的要素、組成要素、そして/または、材料は、便宜上一般的なリストで提示され得る。しかし、これらのリストは、あたかも、リストの各メンバは別々のユニークなメンバとして個々に識別される。こうして、そのようなリストのいかなる個々のメンバも、共通のグループではないという表示のない、共通のグループにおける提示ということだけに基づいて、同じリストのいかなる他のメンバと事実上均等物として解釈されるべきではない。加えて、本明細書において、本発明の様々な実施例や例が様々な構成要素に対する代替案とともに参照され得る。理解されるべきは、そのような実施例、例、および代替案は、お互いの事実上の均等物として解釈されるべきではなく、本発明の個別の自主的な表現と考えられるべきである。
【００６９】
さらに、説明された特徴、構造、または特性は、１以上の実施例において、いかなる適切な方法で組み合わされ得る。説明の中で、本発明の実施例の完全な理解を提供するために、数的に特定の詳細が、レイアウト、距離、ネットワーク例、等の例として提供される。しかし、当業者は、特定の詳細の１以上が無くても、または、他の、方法、構成要素、レイアウト、等を用いても、本発明が実施され得ることを認識するであろう。他の例では、発明の観点を曖昧にすることを避けるために、周知の構造、材料、または、処理は、詳細に示されていない、または説明されていない。
【００７０】
上述の例は、本発明の原理の、１以上の特定のアプリケーションにおける実例であるが、発明的能力の発揮を要することなく、そして本発明の原理及びコンセプトから離れることなく、実装の形式、利用および詳細における様々な変更が可能であることは、当業者にとって明らかである。したがって、以下に示されるクレームによってを除いて、本発明が限定されることを意図するものではない。
【００７１】
本出願は、２０１１年８月１１日に出願された米国仮特許出願６１／５２２６２３、事件整理番号Ｐ３９１０６Ｚに基づく優先権を主張するとともに、その全体が参照により本明細書に組み込まれる。
【図１】
0005706046.tif 000002
【図２】
0005706046.tif 000003
【図３】
0005706046.tif 000004
【図４】
0005706046.tif 000005
【図５】
0005706046.tif 000006
【図６】
0005706046.tif 000007
【図７】
0005706046.tif 000008
【図８】
0005706046.tif 000009