JP6113317B2 - Ｈｔｔｐサーバを用いるｍｂｍｓファイル修復のためのｉｐマルチメディアサブシステムおよび方法 - Google Patents

Description

［優先権の主張］
本特許出願は、２０１２年１月２３日に提出された米国仮特許出願第６１／５８９，７７４の便益を主張する、２０１２年９月１３日に提出された米国特許出願第１３／６１３，９０２の便益を主張する。これら米国特許出願の両方は、それらの全体が参照により本明細書に組み込まれる。

著作権情報
本特許文献の開示の一部は、著作権保護を受ける内容を含んでいる。著作権の所有者は、Ｐａｔｅｎｔ ａｎｄ Ｔｒａｄｅｍａｒｋ Ｏｆｆｉｃｅ特許ファイルまたは記録に示されるように、誰によるものであっても特許文献または特許開示の複製に対して不服はない。しかし、その他の点に関してはどんなものであれ、全ての著作権を留保する。以下の通知は、以下に説明されるようにソフトウェアおよびデータ、並びに本文書の一部を形成する図面に適用される：著作権Ｉｎｔｅｌ， Ｉｎｃ．。著作権所有。

マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）により公表されているセルラー規格のうち１つに従って動作しているセルラーネットワークで利用されるポイントツーマルチポイントシステムである。ＭＢＭＳは、ブロードキャストおよびマルチキャスト技術に基づいて、ポピュラーなコンテンツを多くの受信者に効率的に配信するよう設計されており、オプションの機能として、３ＧＰＰユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）仕様のリリース６において初めて導入され、マルチキャストブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）機能などのいくつかの改善に基づいて後の３ＧＰＰリリースにおいてさらに最適化された。またサービス層において、ＭＢＭＳは、マルチメディアコンテンツのストリーミングとファイルの信頼性の高いダウンロードとの両方のための配信プロトコルを規定している。ＭＢＭＳは、３ＧＰＰリリース８以降に対応する、３ＧＰＰベースのロングタームエボリューション（ＬＴＥ）規格開発において進化型のＭＢＭＳ（ｅＭＢＭＳ）モードとして導入されている。

必ずしも縮尺通りに描写されていない図面において、異なる図面において同様の符号は、同様の構成要素を示し得る。異なる添え字を有する同様の符号は、同様の構成要素の異なる例を表し得る。図面は限定ではなく例示として、本文書に説明される様々な実施形態を一般的に図示する。

本開示のいくつかの実施例に係るＨＴＴＰサーバを用いる例示的なファイル修復機能の概略図を示す。

本開示のいくつかの実施例に係る、ＩＭＳベースのＭＢＭＳを実施するのに用いられるコンポーネントのブロック図を示す。

本開示のいくつかの実施例に係る、ブロードキャストマルチキャストサービスセンター（ＢＭＳＣ）のブロック図を示す。

本開示のいくつかの実施例に係る、ＭＢＭＳベアラー上で配信されるファイルを修復するようＨＴＴＰサーバを用いるＩＭＳベースの方法の例示的なメッセージ順序チャートを示す。

本開示のいくつかの実施例に係る、ＭＢＭＳベアラー上で配信されるファイルを修復するようＨＴＴＰサーバを用いる、ＵＥの観点から見たＩＭＳベースの方法を示すフローチャートを示す。

本開示のいくつかの実施例に係る、ＭＢＭＳベアラー上で配信されるファイルを修復するようＨＴＴＰサーバを用いる、ＭＢＭＳネットワークの観点から見たＩＭＳベースの方法のフローチャートを示す。

本開示のいくつかの実施例に係るＵＥの特定のコンポーネントのブロック図を示す。

本開示のいくつかの実施例に係るマシンのブロック図を示す。

ユニキャスト配信と異なり、ＭＢＭＳベースの送信は、ユーザ機器（ＵＥ）からの肯定応答（ＡＣＫ）および否定応答（ＮＡＣＫ）シグナリングに基づく自動再送リクエスト（ＡＲＱ）およびハイブリッド自動再送リクエスト（ＨＡＲＱ）に基づくものなど、誤って受信したデータブロックの再送に基づくデータ回復メカニズムの恩恵を受けず、結果的に、ユーザ機器（ＵＥ）へのデータ送信の間、データが失われてしまうか、または破損してしまい得る。ＭＢＭＳ送信の信頼性を高めるべく、（少なくとも部分的に）パケット消去を回復するために従来のチャネル符号化に加えて、アプリケーション層の順方向誤り訂正（ＡＬ−ＦＥＣ）符号が用いられている。ＡＬ−ＦＥＣの例にはリードソロモン符号、ファウンテン符号、およびラプター符号が含まれる。

ＩＰマルチメディアサブシステムまたはＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）は、インターネットプロトコル（ＩＰ）マルチメディアサービスを配信するためのアーキテクチャフレームワークである。ＩＭＳは、集中化されたＩＰプラットフォーム内での音声、動画、データ、およびマルチメディアアプリケーションなど豊富な融合されたサービスを可能とすることを約束する。そのようなサービスは、ユーザの通信およびエンターテイメント体験を単純なものとし、サービス提供者にとっての価値に基づいた市場を形成するであろう。ＩＭＳは、革新的な個別化されたアプリケーションの作成と、これらのアプリケーションのより高速な展開を可能とすることを意図している。ＩＰマルチメディアコアネットワークサブシステムは、グループされて１つのＩＭＳ管理ネットワークを形成する、規格化されたインタフェースによりリンクされた複数の異なるコアネットワークおよびアクセスネットワーク機能の集合である。インターネットの統合を容易にすべく、ＩＭＳは広く採用されているセッション開始プロトコル（ＳＩＰ）を用いる。総称的にコールセッション制御機能（ＣＳＣＦ）と呼ばれるセッション開始プロトコル（ＳＩＰ）サーバまたはプロキシのいくつかの役割が、ＩＭＳにおけるＳＩＰシグナリングパケットを処理するべく用いられる。３ＧＰＰにおいて、ＩＭＳはまず、ＵＭＴＳへ、そのコアネットワーク内にリリース５の間に導入され、ＩＭＳのサポートはさらに、ＬＴＥの規格開発の間に促された。ＩＭＳは、ＭＢＭＳベースのストリーミングおよびダウンロードサービスに関するセッションを確立、制御、および終了についてのプロトコルおよび手順のためのものを含むマルチメディアセッションを制御するために必須の要件およびシグナリングの仕様から成る。固定アクセス（例えば、デジタル加入者回線（ＤＳＬ）、ケーブルモデム、Ｅｔｈｅｒｎｅｔ（登録商標））、モバイルアクセス、例えば、ＷＣＤＭＡ（登録商標）、ＣＤＭＡ２０００、ＧＳＭ（登録商標）、ＧＰＲＳ、および無線アクセス、例えば、ＷＬＡＮ、ＷｉＭＡＸは全て、ＩＭＳフレームワークにおいてサポートされている。プレインオールド電話サービス（ＰＯＴＳ−オールドアナログ電話）、Ｈ．３２３、および非ＩＭＳ対応ＶｏＩＰシステムなどの他の電話システムが、ゲートウェイを通じてサポートされる。

ＭＢＭＳ上でのファイルダウンロード配信サービスは、適切にファイルをデコードするのに十分なシンボルを受信していないＵＥが追加のシンボルを要求することを可能とするファイル修復機能を提供する。これによりネットワークは、シンボルをユニキャスト上で特定のＵＥへ配信するのに必要とされる合計の負荷がそれ程大きくない場合、負荷ブロードキャストベアラーではなくユニキャストベアラー上で特定のＵＥへ特定のシンボルを配信することが可能となる。

ファイル修復機能は、ＵＥの修復リクエストに対してサービスする、ネットワークのファイル修復サーバに頼っている。現在のアーキテクチャは、ＵＥのリクエストに対してサービスするよう特別に設計された専用のサーバを要する。このアプローチはコストが高くなり得、大きなスケールの配置には良好に拡張され得ない。

ブロードキャストマルチキャストサービスセンター（ＢＭＳＣ）に頼るのではなく、従来のハイパーテキスト転送プロトコル（ＨＴＴＰ）ウェブサーバ１０３０の利用によるファイル修復リクエストの処理を可能とする現在のファイル修復機能の改善は、図１に示されている。ＢＭＳＣ１０２０により提供されるＭＢＭＳブロードキャストサービスは、セルラーネットワーク１０４０上でユーザ機器（ＵＥ）へファイルまたは他のメディア１０１０を送信する。ソースシンボルの回復のために、ＵＥ１０５０は、規格化されたＨＴＴＰリクエスト／応答を用いてＨＴＴＰサーバ１０３０にコンタクトをとり得る。このアプローチは、既存の拡張可能な、規格化された、広く採用されているウェブベースのインフラストラクチャを修理サービスのために活用する。いくつかの実施例において、システムは、限られた数のＨＴＴＰリクエストによるソースシンボルの回復を可能としつつ、ＭＢＭＳ上での修復シンボル送信をインテリジェントに実行することにより、サーバの複雑性、拡張可能性、キャッシュ効率性、およびＨＴＴＰリクエストオーバーヘッドの観点に関して良好な性能−複雑性のトレードオフを実現し得る（修復シンボルは、実際にファイルの足りない部分を再送することなくＵＥがファイルを修復することを可能とするＵＥへ送信される冗長なシンボル−例えば、ＡＬ−ＦＥＣスキームにより生成されるシンボル）である。オペレータは、特化されたファイル修復サーバを用いなくてもよく、コンテンツを配信するのに用いられるのと同じウェブサーバを用い得る。よって、ＢＭＳＣはもはや、ここではＨＴＴＰサーバにより処理されるファイル修復手順のために必要ではない。ＨＴＴＰサーバはコンテンツを格納しさえすればよく、ＦＥＣ符号化のとめにリソースを費やさなくともよい。このことによりシステムは、低い複雑性で良好なキャッシュおよびネットワーク効率性を実現する。このことによりオペレータは、ネットワークまたはインターネットにおける従来のウェブサーバを用いることにより提供される拡張可能性、信頼性、および容易に利用可能なコンテンツを活用することが出来る。

いくつかの実施例において開示されるのは、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ベースのＭＢＭＳ上でのＭＢＭＳファイル修復手順を実現するシステム、方法、およびマシン可読媒体である。このことは、ファイルの最初のブロードキャストに続く、例えば、当該ファイルをブロードキャストしたＢＭＳＣからＭＢＭＳベアラー上でＦｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）セッションがＵＥにより受信された後の、ＩＭＳベースのＭＢＭＳダウンロード配信方法、特に、関連する回復手順への変更を伴う。訂正が必要とされる（つまり、正確に受信されたソースおよび修復シンボル群に基づいてＵＥがファイルをデコード出来ない）場合、（現在の手順である、ＭＢＭＳファイル修復サービスのためにＢＭＳＣに接続したままでいるのではなく）ＵＥはＢＭＳＣから切断し、ＨＴＴＰを用いてファイルの足りない構成要素を取得するためにＨＴＴＰウェブサーバへのセッションスイッチを確立する。

図２は、３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＴＳ）２６．２３７に規定されるＩＭＳベースのＭＢＭＳアーキテクチャの複数の機能ブロックを示す（この図は、ＴＳ ２６．２３７の同様の図に基づいており、パケット切り替えストリーミング（ＰＳＳ）に関する機能ブロックなどＩＭＳベースのＭＢＭＳに関連しないかもしれない追加のＩＭＳベースのサービス機能も示し得る）。ＩＭＳコアネットワークサブシステム２０１０（ＩＭ ＣＮサブシステム）は、３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＴＳ）２３．２２８に少なくとも部分的に規定され、ユーザ登録および認証、移動性およびローミング、マルチメディアセッションの制御、ＱｏＳ制御、ポリシー制御、チャージング、および回路切り替えネットワークとの共同作業をサポートするサブシステムであり得る。ＵＥ２０２０は、サービス発見および選択を実行し、サービス開始、変更、および停止を処理し、コンテンツを受信しユーザに提示するＩＭＳベースのＭＢＭＳクライアント機能を含む。サービス制御機能（ＳＣＦ）２０３０は、サービスロジックを提供し、そのようなロジックを実行するのに要する機能を提供する。サービス制御機能（ＳＣＦ）２０３０は、セッション開始およびセッション変更の間にサービス認証を行う。このことには、サービスへのアクセスを許可または拒否するためにＭＢＭＳユーザのサービス加入をチェックすることが含まれ、サービス制御機能（ＳＣＦ）２０３０は、関連するＭＢＭＳメディア機能を選択する。ＨＴＴＰベースの配信のために、ＳＣＦは、プロキシまたはバックツーバックユーザエージェント（Ｂ２ＢＵＡ）として動作する。ＭＢＭＳのために、ＳＣＦは停止ユーザエージェント（ＵＡ）として動作する。ＨＴＴＰ／ＳＩＰアダプタ２０４０は、ＳＩＰセッションとＨＴＴＰ受信リクエストとを関連付ける。ＨＴＴＰサーバ２０５０は３ＧＰＰ ＴＳ ２６．２３４に説明されており、標準的なＨＴＴＰプロトコルを用いたファイル修復のリクエストに応じてソースシンボルを提供し得る。ＢＭＳＣ．ＵＰＦ２０６０は、全てのブロードキャストマルチキャストサービスセンター（ＢＭＳＣ）ユーザプレーンサブ機能（ＵＰＦ）を処理する。図３は、３ＧＰＰ ＴＳ ２６．３４６に係る、ＢＭＳＣサブ機能アーキテクチャ、およびＵＥとＢＭＳＣとの間の関連するインタフェースを図示する。３ＧＰＰ ＴＳ ２３．２０３に特定されるポリシー／チャージングルール機能（ＰＣＲＦ）２０７０は、無線アクセスネットワーク（ＲＡＮ）およびパケット切り替え（ＰＳ）コアネットワークにおけるリソースのチャージングおよび確立を制御する。サービス選択機能（ＳＳＦ）２０８０は、ＨＴＴＰベースのＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）、ＭＢＭＳユーザサービス、および関連するユーザサービス記述情報を含む利用可能なユーザサービスのリストを提供する。リストは、クライアントのアイデンティティに個別化もされ得る。

図２は、（ＵＥ、進化型パケットコア（ＥＰＣ）、および無線アクセスネットワークまたはＲＡＮも示しつつ）特定の、例示的なＩＭＳベースのＭＢＭＳシステムの機能概略図の例であることを意図されている。本出願人の開示の恩恵を受ける当業者は、本明細書において開示される様々な実施例を実施すべく機能グループの様々な組み合わせおよび置き換えが用いられ得ることを理解されよう。例えば、複数のコンポーネントは同じ場所で、および／または同じ物理的ハードウェアで実行され得る。

図３を参照すると、ＢＭＳＣのブロック図である３０００が示されている。ＵＥにより送信されるＨＴＴＰリクエストへの応答を通じて（インタラクティブなアナウンス機能３０２０により促されて）、ＭＢＭＳベアラーを用いるサービスアナウンスを通じて（セッション／送信機能３０３０のＭＢＭＳ配信機能３０４０を通じて促されて）、またはＭＢＭＳプッシュ機能を用いたプッシュアナウンスを通じて、ユーザサービス発見／アナウンス３０１０は、ＵＥへアナウンスを提供する。これらのアナウンスは、アナウンスされたサービスをＵＥが受信するのに必要な情報を含む。アナウンスは、サービス識別子、ＩＰマルチキャストアドレス、およびメディア記述を含み得る。

セッション／送信機能３０３０は、全てのコンテンツ送信に関連した機能を含む。ＭＢＭＳ配信機能３０４０はファイルを（ＭＢＭＳダウンロードサービスを介して）、またはストリームを（ＭＢＭＳストリーミングサービスを介して）配信する。セッション／送信機能３０３０は、ＵＤＰおよびリアルタイム送信プロトコル（ＲＴＰ）、並びにＦｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）上でＵＥと通信する。関連する配信機能３０５０には、ファイル修復手順など補助的な手順が含まれる。

鍵管理機能３０６０は、鍵リクエスト機能３０７０、および、認証、およびＵＥへの鍵配布を処理する鍵配布機能３０８０を含む。コンテンツプロバイダ／マルチキャストブロードキャストソース３０９０は、ＭＢＭＳネットワーク上でブロードキャストまたはマルチキャストされるコンテンツを提供するコンテンツプロバイダのネットワークである。

ここで図４を参照すると、ＨＴＴＰを用いるＭＢＭＳファイル修復を図示する例示的なメッセージ順序チャートが示されている。処理４０１０において、ＵＥは、最初のＳＩＰ ＩＮＶＩＴＥメッセージを生成し、ＩＭ ＣＮサブシステムへ送信し、選択されたＭＢＭＳダウンロードサービスを示す。ＳＤＰオファーは、ＳＩＰ ＩＮＶＩＴＥメッセージに含まれ得る。ＩＭ ＣＮサブシステムはＳＩＰ ＩＮＶＩＴＥメッセージおよびＳＤＰオファーをＳＣＦへ転送する。ＳＩＰ ＩＮＶＩＴＥリクエストのＲｅｑｕｅｓｔ−ＵＲＩは、ＭＢＭＳダウンロードサービスの周知のＰＳＩ（パブリックサービス識別子）であり得、「ｔｏ」ヘッダは、Ｒｅｑｕｅｓｔ−ＵＲＩにおけるものと同じＵＲＩを含み得、「ｆｒｏｍ」ヘッダは、ユーザのパブリックユーザアイデンティティを示し得る。ＳＤＰオファーは、リクエストに含まれ得、ＵＥサービス選択手順の間に受信されるパラメータ、並びにＭＢＭＳダウンロードサービスに関して利用可能なメディア性能および要する帯域幅に従って行われ得る。

処理４０２０において、ＳＩＰ ＩＮＶＩＴＥリクエストの受信に応じて、ＳＣＦはＳＤＰオファーにおけるＳＤＰパラメータを検討し、ユーザ加入情報に従って、要求されるＭＢＭＳダウンロードサービスのサービス権限をチェックするべくサービス認証手順を実行する。ユーザが認証された場合、ＳＣＦはＳＤＰ回答を含むＳＩＰ２００ＯＫを用いて応答し得る。ＳＤＰ回答は、ファイル配信テーブル（ＦＤＴ）のアドレスを示すｆｄｔ＿ａｄｄｒｅｓｓ：ｕｒｉ、および修復サーバのアドレスを示すｒｅｐａｉｒ−ｓｅｒｖｅｒ−ａｄｄｒｅｓｓ：ｕｒｉを含み得る。

処理４０３０において、ＳＩＰ応答の受信に応じて、ＵＥは、受信したＳＤＰにおけるＦＬＵＴＥセッションパラメータを検討し、それに従ってＭＢＭＳダウンロードデータを受信し得る。ＦＤＴが利用可能でない場合、ＵＥは、ＳＤＰ回答における ｆｄｔ＿ａｄｄｒｅｓｓ ａｔｔｒｉｂｕｔｅに従ってＦＤＴを取得し得る。ＦＤＴは、ＦＬＵＴＥセッションで配信されるファイルに関するコンテンツ記述情報を含む。

不完全なダウンロードの場合、ＵＥは、ＳＣＦからのＳＤＰ回答における修復サーバアドレス属性に示される修復サーバに対してファイル修復手順を実行し得る。処理４０４０において、ＭＢＭＳダウンロードから、ウェブサーバからの修理サービスのＨＴＴＰベースの配信へ切り替えるために、セッション開始プロトコル（ＳＩＰ）Ｒｅ−ＩＮＶＩＴＥがＵＥにより発行され、ＩＭ ＣＮサブシステムへ送信される。修復サーバに向けられたセッション記述プロトコル（ＳＤＰ）オファーおよびＲｅｑｕｅｓｔ−ＵＲＩは、ファイル修復をアクティブにするＳＩＰ Ｒｅ−ＩＮＶＩＴＥメッセージに含まれ得る。ＩＭ ＣＮサブシステムは、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥメッセージをＳＣＦへ転送し得る。Ｒｅｑｕｅｓｔ−ＵＲＩは、ユーザがアクティブにすることを希望するウェブサーバからのＨＴＴＰベースのファイル修復セッションに関連する。Ｒｅｑｕｅｓｔ−ＵＲＩは以下に規定されるようにユーザ部分およびドメイン部分から構成され得る。ユーザ部分は、ＳＳＦからのユーザサービス記述情報から取得されるコンテンツ識別子を含む。コンテンツ識別子は、サービス選択情報から取得され得る。ドメイン部分は、ＳＳＦから取得されるサービスプロバイダドメイン名である。「ｔｏ」ヘッダは、修復サーバアドレスＵＲＩを含み得る。「ｆｒｏｍ」ヘッダは、ユーザのパブリックユーザアイデンティティを示し得る。コンテンツ識別子は、サービス選択情報から取得され得る。ＳＤＰオファーは、ファイル修復セッションに関して利用可能なメディア性能およびポリシー、および、サービス選択手順の間、または、ＳＩＰ ＯＰＴＩＯＮＳによる足りないパラメータを取得するための手順の間にＳＳＦから受信するパラメータに従ってＲｅ−ＩＮＶＩＴＥリクエストに含まれ得る。

処理４０５０において、ＳＩＰ変更リクエストを受信したことに応答して、ＳＣＦは、現在ブロードキャストされたプログラムがファイル修復目的のためのＭＢＭＳ／ＦＬＵＴＥ−ＨＴＴＰ切り替えサポートを有しているか否かを判断し得る。ＭＢＭＳ−ＨＴＴＰ切り替えがＵＥに関して利用可能でない場合、セッション変更は拒否され、（以前に確保されたリソースと共に）古いＭＢＭＳセッションが維持される。ＭＢＭＳ−ＨＴＴＰ切り替えがＵＥに関して利用可能である場合、Ｂ２ＢＵＡとして動作するＳＣＦは、ＵＥからのＳＩＰ Ｒｅ−ＩＮＶＩＴＥメッセージの受信に応じて要求されているコンテンツに対するユーザの権限をチェックし、リクエストがＭＢＭＳファイル修復手順のためのものであることを識別し、ＨＴＴＰ／ＳＩＰアダプタを選択し、それに従って「Ｒｅｑｕｅｓｔ−ＵＲＩ」を変更することにより、ファイル修理サービスを担当するＨＴＴＰ／ＳＩＰアダプタへＳＩＰ ＩＮＶＩＴＥリクエストを転送する。３０１または３０２応答をＨＴＴＰ／ＳＩＰアダプタから受信した場合、ＳＣＦはこのメッセージをＵＥへ転送しないかもしれない。

Ｒｅｑｕｅｓｔ−ＵＲＩがユーザ部分にコンテンツ識別子を含み、ドメイン部分にドメイン名を含む場合、ＳＣＦは、適したＨＴＴＰ／ＳＩＰアダプタを選択し、選択されたＨＴＴＰ／ＳＩＰアダプタに対するＳＩＰ ＩＮＶＩＴＥリクエストを生成し得る。ＳＩＰ ＩＮＶＩＴＥリクエストの「ｔｏ」ヘッダは、ＵＥから受信したＳＩＰ変更リクエストのＲｅｑｕｅｓｔ−ＵＲＩのものと同じコンテンツ識別子を含み得る。処理４０６０において、ＳＣＦはＨＴＴＰ／ＳＩＰアダプタへＳＤＰパラメータと共にＳＩＰ ＩＮＶＩＴＥリクエストを送信し得、ＢＭＳＣ．ＵＰＦとＵＥとの間のＦＬＵＴＥベースのＭＢＭＳダウンロードセッションを終了し得る。

ＭＢＭＳファイル修復アクティブ化リクエストを受信すると、ＨＴＴＰ／ＳＩＰアダプタは、「ｔｏ」ヘッダのユーザ部分に存在するコンテンツ識別子、およびＳＤＰのメディアパラメータを検討し、Ｒｅｑｕｅｓｔ ＵＲＩに従ってＨＴＴＰサーバを選択し得る。処理４０７０において、ＨＴＴＰ／ＳＩＰアダプタは、ＵＥのＩＰアドレスを含むＨＴＴＰ ＰＯＳＴメッセージをＨＴＴＰサーバへ送信する。ＨＴＴＰ／ＳＩＰアダプタは、リクエストを他のＨＴＴＰ／ＳＩＰアダプタサーバへ転送することを決定し得る。この場合、ＨＴＴＰ／ＳＩＰアダプタは、コンテンツがこのＨＴＴＰ／ＳＩＰアダプタにより管理されていなければ３０１応答を返信し得、何らかの他の理由（例えば、負荷バランシング）で３０２応答を返信し得る。転送を行うＨＴＴＰ／ＳＩＰアダプタは、コンタクトヘッダ内の１または複数の宛て先ＨＴＴＰ／ＳＩＰアダプタアドレスを示し得る。

ＨＴＴＰ／ＳＩＰアダプタから受信するＨＴＴＰ ＰＯＳＴメッセージを受信すると、処理４０８０において、ＨＴＴＰサーバは、ＨＴＴＰ２００ＯＫ応答によりＨＴＴＰ／ＳＩＰアダプタに応答し得る。処理４０９０において、ＨＴＴＰ／ＳＩＰアダプタは、ＳＤＰ回答を含むＳＩＰ２００ＯＫメッセージをＳＣＦへ返し得る。ＳＤＰ回答は要求されているコンテンツファイルのダウンロードＵＲＬを含む、ＭＢＭＳファイル修復セッションを記述し得る。ストリーミングに関して規定されるＳＤＰ回答との差異は、制御プロトコル（リアルタイムストリーミングプロトコル（ＲＴＳＰ））に対応するメディアラインの不在、ストリーミングの代わりのＴＣＰトランスポートおよびＨＴＴＰベースのダウンロード方法の情報、ＲＴＳＰ ＵＲＩの代わりのＨＴＴＰ ＵＲＬの情報である。ユーザが選択したコンテンツが見つからない場合、ＨＴＴＰ／ＳＩＰアダプタは、適切なＳＩＰエラーコード（例えば、４０４ Ｎｏｔ Ｆｏｕｎｄ）応答で返信し得る。

処理４１００において、ＳＣＦはＳＩＰ２００ＯＫをＩＭ ＣＮサブシステムへ転送し得る。処理４１１０において、ＩＭ ＣＮサブシステムは、ＳＩＰ２００ＯＫをＵＥへ転送し得る。

処理４１２０において、ＳＩＰ２００ＯＫを受信した後、ＵＥは、マルチキャストチャネルを離れ、ＳＩＰ２００ＯＫメッセージから取得されるＵＲＬへＨＴＴＰ ＧＥＴ（またはバイト範囲のリクエストのためのＨＴＴＰ部分的ＧＥＴ）リクエストを送信することによりＭＢＭＳファイル修復を開始し得る。処理４１３０において、ＨＴＴＰサーバはＨＴＴＰ応答内のコンテンツファイルをＵＥへ配信し得る。

図５は、いくつかの実施例に係るＨＴＴＰサーバを利用するＩＭＳベースのＭＢＭＳファイル修復方法のフローチャートを示す。処理５０１０において、ＵＥは、ＩＭＳネットワークとセッションを確立してＭＢＭＳを受信する。いくつかの実施例において、ＵＥは、ＳＤＰオファーメッセージを含むＳＩＰ勧誘をＩＭ ＣＮサブシステムへ送信し得る。ＩＭ ＣＮサブシステムはその後、ＳＤＰオファーを含むＳＩＰ勧誘をＳＣＦへ転送し得る。ＳＣＦはその後、ＳＩＰ ＯＫメッセージをＩＭ ＣＮサブシステムへ送信し得、ＩＭ ＣＮサブシステムはその後ＳＩＰ ＯＫをＵＥへ転送し得、これにより、ＩＭＳネットワークとセッションを確立してＭＢＭＳを受信する。

処理５０２０において、ＵＥは、ＭＢＭＳベアラー上でメディアを受信する。いくつかの実施例において、ＵＥは、第３世代パートナーシッププロジェクト（３ＧＰＰ）規格ファミリーに準拠するロングタームエボリューション無線ネットワークを通じてネットワークと通信を行う（およびメディアを受信する）。他の実施例において、ＵＥは、３ＧＰＰ規格ファミリーに準拠するユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）無線ネットワークを通じてネットワークと通信を行う（およびメディアを受信する）。さらに他の実施例において、他のタイプの無線ネットワークが用いられ得る。

処理５０３０において、ＵＥは、エンコードされたシンボルのうちのうち１または複数が適切にデコードされ得ず、したがって、ファイル修復手順が必要であると判断する。処理５０４０において、シンボルが再送されるようにする（メディアを修復する）ため、ＵＥは、ユニキャスト上でのＨＴＴＰベースのファイル修復を要求しているＩＭＳネットワークとセッションを再確立し得る。いくつかの実施例において、ＵＥはこのことを、ＳＤＰオファーを含むＳＩＰ Ｒｅ−ＩｎｖｉｔｅリクエストをＩＭ ＣＮサブシステムへ送信することにより行う。ＩＭ ＣＮサブシステムはこれをＳＣＦコンポーネントへ転送し得る。ＳＣＦコンポーネントはその後、指定されたＨＴＴＰ修復サーバにコンタクトをとり得るＳＩＰ−ＨＴＴＰアダプタをセットアップし得る。ＨＴＴＰ修復サーバの返信が肯定的である場合、ＩＭＳネットワークは、モバイルに対し、セッションが適切にセットアップされたと返信する。

処理５０５０において、ＵＥはＨＴＴＰサーバにコンタクトをとり、ＩＭＳネットワークから送信された返信メッセージ内の情報を用いて適切なシンボルを再ダウンロードする。

図６を参照すると、いくつかの実施例に係る、ＩＭＳネットワークから見た、ＨＴＴＰサーバを利用したファイル修復方法のフローチャートが示されている。６０１０において、ＳＣＦは、ＵＥから修復リクエストを受信する。修復リクエストは、ＳＤＰオファーを含むＳＩＰ再勧誘などのセッション再確立メッセージの形態をとり得る。処理６０２０において、ＳＣＦは、修復処理がＨＴＴＰを用いて行われ得るか否かを判断する。修復処理がＨＴＴＰを用いて行われ得る場合、処理６０３０において、リクエストは、ＨＴＴＰ−ＳＩＰアダプタへ転送される。処理６０３５において、ＨＴＴＰ−ＳＩＰアダプタは、ＨＴＴＰサーバにコンタクトをとって、ＨＴＴＰポストメッセージを送信することによりファイル修復をセットアップし得る。ＨＴＴＰサーバからの返信メッセージは、ＨＴＴＰ−ＳＩＰアダプタによりＳＩＰ返信メッセージへ変換され、ＳＣＦへ戻すよう転送され得る。処理６０４０において、ＵＥのＦＬＵＴＥセッションは終了され、６０５０において、ＳＣＦは、ＨＴＴＰ／ＳＩＰアダプタからＵＥへ返信メッセージを転送する。ＨＴＴＰセッションへの移行が成功したことを返信メッセージが示す場合、ＵＥは、いくつかの実施例において、返信に含まれる情報（例えば、ユニフォームリソースロケータ（ＵＲＬ））を用いてＨＴＴＰ上でファイルをダウンロードし得る。

いくつかの実施例において、「ＩＭＳネットワーク」という用語は便宜上用いられており、一般的にＩＭＳベースのＭＢＭＳを配信するのに用いられる何らかのコンポーネントを指し、コアネットワーク（例えば、進化型パケットコアネットワーク−ＥＰＣ）の特定の要素を含み得る。

図７は、本開示のいくつかの実施例に係るユーザ機器デバイス（ＵＥ）７０００のブロック図の例を示す。ＵＥ７０００は、例えば、タッチセンサ式ディスプレイインタフェース、キーボード、トラックボール、マウス、またはその他などユーザから入力を受け付ける入出力モジュール７０３０を（他のモジュールおよび／または機能に加えて）含み得る。また入出力モジュール７０３０は、１または複数のグラフィックディスプレイ、オーディオ再生デバイス（例えば、スピーカ）、またはその他を制御することによりユーザへ出力を表示する。入出力モジュール７０３０は、ＩＭＳネットワークから受信したメディア、ファイル、または他のデータを表示し得、ＩＭＳネットワークにおいて利用可能なコンテンツを受信可能なＵＥ７０００のユーザから入力を受信し得る。

ＵＥ７０００は、変調、符号化、送信、受信、復調、およびアンエンコードを含む無線物理層機能を実装し得るＴＸ／ＲＸモジュール７０２０を有し得る。またＵＥは、無線プロトコルスタックの他の層（例えば、層２、層３）を実装し得る制御モジュール７０１０を含み得る。例えば、制御モジュール７０１０は、ＩＭＳネットワークからのデータを登録、登録解除、および受信し得る。また制御モジュール７０１０は、メディアまたはファイルを修復すべくＨＴＴＰサーバにコンタクトをとることを含むファイル修復手順を制御し得る。また制御モジュール７０１０は、入出力モジュール７０３０からのユーザ入力に応答し、出力が、入出力モジュール７０３０を通じてディスプレイまたは他の出力デバイスに送信されるようにし得る。

図８は、本明細書に説明される技術（例えば、方法）のうち１または複数が実施され得る例示的なマシン８０００のブロック図を図示する。代替の実施例において、マシン８０００は、スタンドアロン型のデバイスとして動作し得、または、他のマシンに接続（例えば、ネットワーク接続）され得る。ネットワーク接続される構成において、マシン８０００は、サーバマシンまたはクライアントマシンとして、若しくは、サーバ−クライアントネットワーク環境で動作し得る。実施例において、マシン８０００は、ピアツーピア（Ｐ２Ｐ）（または他の分散された）ネットワーク環境のピアマシンとして動作し得る。マシン８０００は、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、ウェブアプライアンス、ネットワークルータ、スイッチまたはブリッジ、若しくはマシンにより行われる動作を特定する（順次的な、または他の）命令を実行可能な何らかのマシンであり得る。例えば、ｅＮｏｄｅＢ、ＵＥ、またはＬＴＥシステムの他のコンポーネントは、マシン８０００のコンポーネントであり得るか、またはそのようなコンポーネントを含み得る。さらに、１つのマシンだけが図示されているが、「マシン」という用語は、クラウドコンピューティング、サービス型ソフトウェア（ＳａａＳ）、他のコンピュータクラスタ構成など、本明細書に説明される方法のうち１または複数を実施させる１の（または複数の）命令群を個別または共同で実行するマシンの集合を含むものしても捉えられ得る。例えば、マシン８０００の機能は、ネットワーク内の複数の他のマシンに亘り分散されうる。

本明細書に説明される実施例は、ロジック、若しくは複数のコンポーネント、モジュール、またはメカニズムを含み得、若しくはそれらで動作し得る。モジュールは、特定された処理を実行することが出来る有体物であり、特定のやり方で構成または配置され得る。実施例において、回路が、モジュールとして、特定されたやり方で（例えば、内部で、または他の回路など外部物体に関連して）配置され得る。実施例において、１または複数のコンピュータシステム（例えば、スタンドアロン型、クライアント、またはサーバコンピュータシステム）、若しくは、１または複数のハードウェアプロセッサの全体または一部は、特定された処理を実行するよう動作するモジュールとして、ファームウェアまたはソフトウェア（例えば、命令、アプリケーション部分、またはアプリケーション）により構成され得る。実施例において、ソフトウェアは、（１）非一時的マシン可読媒体、または（２）送信信号に存在し得る。実施例において、ソフトウェアはモジュールの下位のハードウェアにより実行された場合、特定された処理をハードウェアに実行させる。

したがって、「モジュール」という用語は、特定されたやり方で動作する、または本明細書に説明される処理の一部または全てを実行するよう物理的に構築された、特に構成された（例えば、ハードワイヤドされた）、または一時的に（例えば、一過性のもとして）構成（例えば、プログラム）された物体など、有体物を網羅するものとして理解される。モジュールが一時的に構成された実施例を考えると、モジュールのうちそれぞれは、いつでもインスタンスを作成される必要はない。例えば、モジュールが、ソフトウェアを用いて構成された汎用ハードウェアプロセッサを含む場合、汎用ハードウェアプロセッサは、経時的に変化する１または複数のモジュールとして構成され得る。したがって、ソフトウェアは、例えば、ある時点において特定のモジュールを構成し、異なる時点において異なるモジュールを構成するハードウェアプロセッサを構成し得る。

マシン（例えば、コンピュータシステム）８０００は、ハードウェアプロセッサ８００２（例えば、中央処理装置（ＣＰＵ）、グラフィックプロセッシングユニット（ＧＰＵ）、ハードウェアプロセッサコア、またはこれらの何らかの組み合わせ）、メインメモリ８００４、およびスタティックメモリ８００６を含み得、これらのうちいくつかまたは全てはバス８００８を介して互いに通信を行い得る。マシン８０００はさらに、ディスプレイユニット８０１０、文字数字入力デバイス８０１２（例えば、キーボード）、ユーザインタフェース（ＵＩ）制御デバイス８０１４、および／または他の入力デバイスを含み得る。実施例において、ディスプレイユニット８０１０およびＵＩ制御デバイス８０１４は、タッチスクリーンディスプレイを含み得る。マシン８０００は追加的に、記憶デバイス（例えば、ドライブユニット）８０１６、信号生成デバイス８０１８（例えば、スピーカ）、およびネットワークインタフェースデバイス８０２０を含み得る。

記憶デバイス８０１６は、本明細書に説明される技術または機能のうち１または複数を具体化する、またはそれらを利用する１または複数のデータ構造群または命令群８０２４（例えば、ソフトウェア）が格納されるマシン可読媒体８０２２を含み得る。また命令８０２４はマシン８０００による実行の間、完全に、または少なくとも部分的に、メインメモリ８００４、スタティックメモリ８００６、またはハードウェアプロセッサ８００２内に存在し得る。実施例において、ハードウェアプロセッサ８００２、メインメモリ８００４、スタティックメモリ８００６、または記憶デバイス８０１６のうち１つ、または何らかの組み合わせがマシン可読媒体を構成し得る。

マシン可読媒体８０２２は１つの媒体として図示されているが、「マシン可読媒体」という用語は、１または複数の命令８０２４を格納するよう構成または配置された１つの媒体、または複数の媒体（例えば、集中化または分散されたデータベース、並びに／若しくは、関連付けられたキャッシュおよびサーバ）を含み得る。

「マシン可読媒体」という用語は、マシン８０００による実行のための命令を格納、エンコード、または伝達することが出来、マシン８０００に、本開示の技術のうち１または複数を実行させる、若しくは、そのような命令により用いられる、またはそのような命令に関連付けられるデータ構造を格納、エンコード、または伝達することが出来る何らかの有形の媒体を含み得る。マシン可読媒体の非限定的な例には、固体メモリ、並びに光および磁気媒体が含まれ得る。マシン可読媒体の特定の例には、半導体メモリデバイス（例えば、電子的プログラマブル読取専用メモリ（ＥＰＲＯＭ）、電子的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ））およびフラッシュメモリデバイスなどの不揮発性メモリ、および、内部ハードディスクおよび取り外し可能ディスクなどの磁気ディスク、光磁気ディスク、並びにＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクが含まれ得る。

命令８０２４はさらに、ネットワークインタフェースデバイス８０２０を介して伝送媒体を用いて通信ネットワーク８０２６上で送受信され得る。ネットワークインタフェースデバイス８０２０は、複数の転送プロトコル（例えば、フレームリレー、インターネットプロトコル（ＩＰ）、トランスミッション制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、その他）のうちいずれか１つを利用することにより、他のマシンからなるネットワーク内でそれら他のマシンと通信を行うために、当該ネットワークへマシン８０００を接続し得る。例示的な通信ネットワークには、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、パケットデータネットワーク（例えば、インターネット）、携帯電話ネットワーク（例えば、セルラーネットワーク）、プレインオールド電話（ＰＯＴＳ）ネットワーク、および無線データネットワーク（例えば、Ｗｉ−Ｆｉ（登録商標）として知られるＩｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）８０２．１１規格ファミリー、ＷｉＭａｘ（登録商標）として知られるＩＥＥＥ ８０２．１６規格ファミリー）、ピアツーピア（Ｐ２Ｐ）ネットワーク等々が含まれ得る。実施例において、ネットワークインタフェースデバイス８０２０は、通信ネットワーク８０２６に接続するための１または複数の物理ジャック（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、同軸ケーブル、または電話ジャック）、若しくは１または複数のアンテナを含み得る。実施例において、ネットワークインタフェースデバイス８０２０は、単入力多出力（ＳＩＭＯ）、多入力多出力（ＭＩＭＯ）または多入力単出力（ＭＩＳＯ）技術のうち少なくとも１つを用いて無線通信を行うための複数のアンテナを含み得る。「伝送媒体」という用語は、マシン８０００により実行される命令を格納、エンコード、および伝達することが出来る何らかの無形媒体を含むものとして捉えられ得、そのようなソフトウェアの通信を促すデジタルまたはアナログ通信信号、若しくは他の無形媒体を含む。

他の注記および実施例
実施例１：インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ベースのネットワークにおけるメディア修復の方法であり、
上記方法は、
セッション開始プロトコル（ＳＩＰ）を用いてＩＭＳネットワークのコンポーネントと通信して、マルチメディアブロードキャストマルチキャストサービスベアラー（ＭＢＭＳベアラー）上でブロードキャストマルチキャストサービスセンター（ＢＭＳＣ）とダウンロードセッションをセットアップする段階と、
確立された上記ＭＢＭＳベアラーを用いてダウンロードされたメディアの１または複数のエンコードシンボルがデコードされ得ないとの判断に応答して、
上記ＭＢＭＳベアラーのセットアップの段階の間に上記ＩＭＳネットワークのコンポーネントにより示されるハイパーテキスト転送プロトコル修復サーバ（ＨＴＴＰ修復サーバ）のアドレスを含むＳＩＰ再勧誘リクエストを用いて、上記ＩＭＳネットワークの上記コンポーネントからファイル修復手順を要求する段階と、
上記リクエストが成功であったことを示すＳＩＰ肯定応答を受信したことに応答して、デコードされ得なかった上記メディアの上記１または複数のエンコードシンボルを再ダウンロードすべく、上記ＨＴＴＰサーバとのＨＴＴＰ接続を要求する段階と、
上記ＨＴＴＰサーバから上記１または複数のエンコードシンボルを受信する段階と
を含む方法。

実施例２：上記メディアは、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルを利用することにより上記ＭＢＭＳベアラーを用いてダウンロードされる、実施例１に記載の方法。

実施例３：上記ＩＭＳネットワークの上記コンポーネントはサービス調整機能（ＳＣＦ）である、実施例１または２に記載の方法。

実施例４：上記ＨＴＴＰ接続は、ＨＴＴＰ ＧＥＴリクエストを用いて要求される、実施例１から３のいずれか一例に記載の方法。

実施例５：上記ＩＭＳネットワークの上記コンポーネントと通信する段階は、ロングタームエボリューション（ＬＴＥ）ネットワーク上で通信する段階を含む、実施例１から４のいずれか一例に記載の方法。

実施例６：ユーザ機器（ＵＥ）であり、
インターネットプロトコルマルチメディアサブシステムネットワーク（ＩＭＳネットワーク）のコンポーネントからのマルチメディアブロードキャストマルチキャストサービスベアラー（ＭＢＭＳベアラー）を用いてダウンロードされたメディアファイルの１または複数のエンコードシンボルがデコードされ得ず、ファイル修復手順が必要であると判断するよう構成された制御モジュールと、
送受信モジュールと
を含み、
上記送受信モジュールは、
上記ファイル修復手順が必要であると上記制御モジュールが判断したことに応答して、セッション開始プロトコル再勧誘リクエスト（ＳＩＰ再勧誘リクエスト）を用いて上記ＩＭＳネットワークの上記コンポーネントから上記ファイル修復手順を要求し、
上記再勧誘リクエストが成功であったことを示すＳＩＰ肯定応答を受信したことに応答して、デコードされ得なかった上記メディアの上記１または複数のエンコードシンボルを再ダウンロードすべく、上記ハイパーテキスト転送プロトコルサーバ（ＨＴＴＰサーバ）とのＨＴＴＰ接続を要求し、
上記ＨＴＴＰサーバから上記１または複数のエンコードシンボルを受信するよう構成される、ＵＥ。

実施例７：ＳＩＰを用いた上記ＭＢＭＳベアラーのセットアップを備える、実施例６に記載のＵＥ。

実施例８：上記ＳＩＰ再勧誘リクエストは、上記ＭＢＭＳベアラーのセットアップの間にファイル修復サーバとして上記ＩＭＳネットワークの上記コンポーネントにより示されるＨＴＴＰサーバのアドレスを含む、実施例５または６に記載のＵＥ。

実施例９：上記送受信モジュールは、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルを利用することにより上記ＭＢＭＳベアラーを用いて上記メディアをダウンロードするよう構成される、実施例６から８のいずれか一例に記載のＵＥ。

実施例１０：上記ＩＭＳネットワークの上記コンポーネントはサービス調整機能（ＳＣＦ）である、実施例６から９のいずれか一例に記載のＵＥ。

実施例１１：上記送受信モジュールは、ロングタームエボリューション（ＬＴＥ）ネットワーク上で、上記ＩＭＳネットワークのコンポーネントと通信する、実施例６から１０のいずれか一例に記載のＵＥ。

実施例１２：マシンにより実行されると上記マシンに処理を実行させる命令を格納したマシン可読媒体であり、
上記処理は、
セッション開始プロトコル（ＳＩＰ）を用いてインターネットプロトコルマルチメディアサブシステムネットワーク（ＩＭＳネットワーク）のコンポーネントと通信して、マルチメディアブロードキャストマルチキャストサービスベアラー（ＭＢＭＳベアラー）上でブロードキャストマルチキャストサービスセンター（ＢＭＳＣ）とダウンロードセッションをセットアップする処理と、
確立された上記ＭＢＭＳベアラーを用いてダウンロードされたメディアの１または複数のエンコードシンボルがデコードされ得ないとの判断に応答して、
上記ＭＢＭＳベアラーのセットアップの間に上記ＩＭＳネットワークの上記コンポーネントにより示されるハイパーテキスト転送プロトコル修復サーバ（ＨＴＴＰ修復サーバ）のアドレスを含むＳＩＰ再勧誘リクエストを用いて、上記ＩＭＳネットワークの上記コンポーネントからファイル修復手順を要求する処理と、
上記リクエストが成功であったことを示すＳＩＰ肯定応答を受信したことに応答して、デコードされ得なかった上記メディアの上記１または複数のエンコードシンボルを再ダウンロードすべく、上記ＨＴＴＰサーバとのＨＴＴＰ接続を要求する処理と、
上記ＨＴＴＰサーバから上記１または複数のエンコードシンボルを受信する処理と
を備える、マシン可読媒体。

実施例１３：上記メディアは、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルを利用することにより上記ＭＢＭＳベアラーを用いてダウンロードされる、実施例１２に記載のマシン可読媒体。

実施例１４：上記ＩＭＳネットワークの上記コンポーネントはサービス調整機能（ＳＣＦ）である、実施例１２または１３に記載のマシン可読媒体。

実施例１５：上記ＨＴＴＰ接続は、ＨＴＴＰ ＧＥＴリクエストを用いて要求される、実施例１２から１４のいずれか一例に記載のマシン可読媒体。

実施例１６：上記ＩＭＳネットワークのコンポーネントと通信する処理は、ロングタームエボリューション（ＬＴＥ）ネットワーク上で通信する処理を含む、実施例１２から１５のいずれか一例に記載のマシン可読媒体。

実施例１７：インターネットプロトコルマルチメディアサブシステムネットワーク（ＩＭＳネットワーク）におけるファイル修復の方法であり
上記方法は、セッション開始プロトコル再勧誘リクエスト（ＳＩＰ再勧誘リクエスト）をユーザ機器（ＵＥ）から受信する段階を備え、
上記再勧誘は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ユニキャストベアラーを用いたファイル修復手順の開始を要求し、
上記ＳＩＰ再勧誘リクエストは、修復サーバのアドレスを含み、
上記方法はさらに、
ＨＴＴＰ−ＳＩＰアダプタを選択し、選択された上記ＨＴＴＰ−ＳＩＰアダプタに対するＳＩＰ勧誘リクエストを生成する段階と、
上記ＨＴＴＰ−ＳＩＰアダプタが上記修復サーバとのファイル修復手順をセットアップしたことを示すＳＩＰ肯定応答メッセージを、上記選択されたＨＴＴＰ−ＳＩＰアダプタから受信したことに応答して、上記ＵＥとブロードキャスト−マルチキャストサービスセンターユーザプレーンファンクション（ＢＭＳＣ．ＵＰＦ）との間のＭＢＭＳダウンロードセッションを終了し、ＨＴＴＰベースの配信を開始すべく上記肯定応答を上記ＵＥへ転送する段階と
を備える、方法。

実施例１８：上記ＵＥへのＭＢＭＳベアラーをセットアップする段階をさらに備え、
上記セットアップする段階は、上記ＨＴＴＰ修復サーバの上記アドレスを送信する段階を有する、実施例１７に記載の方法。

実施例１９：サービス調整機能で実行される、実施例１７または１８に記載の方法。

実施例２０：上記リクエスト内で特定される上記メディアアイテムがＭＢＭＳからＨＴＴＰへのプロトコル切り替えを許可すると判断したことに応答して、上記選択されたＨＴＴＰ−ＳＩＰアダプタに対する上記ＳＩＰ勧誘リクエストが生成される、実施例１７から１９のいずれか一例に記載の方法。

実施例２１：上記選択されたＨＴＴＰ−ＳＩＰアダプタに対するＳＩＰ勧誘リクエストは、セッション記述プロトコル（ＳＤＰ）オファーと、上記修復サーバに向けられたリクエストユニフォームリソース識別子（リクエストＵＲＩ）とを含む、実施例１７から２０のいずれか一例に記載の方法。

実施例２２：上記リクエストＵＲＩは、コンテンツ識別子を含むユーザ部分と、サービスプロバイダドメイン名を含むドメイン部分とを含む、実施例２１に記載の方法。

実施例２３：インターネットプロトコルマルチメディアサブシステムネットワーク（ＩＭＳネットワーク）コンポーネントであり、
コンピュータプロセッサ上で動作するサービス調整機能（ＳＣＦ）を備え、
上記ＳＣＦは、
マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）を提供すべくセッション開始プロトコル（ＳＩＰ）を用いてユーザ機器（ＵＥ）とのＭＢＭＳベアラーを確立し、
ハイパーテキスト転送プロトコル（ＨＴＴＰ）ユニキャストベアラーを用いて、ファイル修復手順の開始を要求している上記ＵＥからＳＩＰ再勧誘リクエストを受信し、
ＨＴＴＰ−ＳＩＰアダプタを選択し、選択された上記ＨＴＴＰ−ＳＩＰアダプタに対してＳＩＰ勧誘リクエストを生成し、
上記ＵＥとブロードキャスト−マルチキャストサービスセンターユーザプレーンファンクション（ＢＭＳＣ．ＵＰＦ）との間の上記ＭＢＭＳダウンロードセッションを終了し、上記ＨＴＴＰ−ＳＩＰアダプタからＳＩＰ肯定応答メッセージを受信したことに応答して、ＨＴＴＰベースの配信を開始すべく上記肯定応答を上記ＵＥへ転送する
よう構成される、ＩＭＳネットワークコンポーネント。

実施例２４：上記ＳＣＦは、上記ＭＢＭＳベアラーを確立したことに応じて、上記ＨＴＴＰ修復サーバの上記アドレスを送信するよう構成される、実施例２３に記載のＩＭＳネットワークコンポーネント。

実施例２５：上記ＳＣＦは、リクエスト内で特定される上記メディアアイテムがＭＢＭＳからＨＴＴＰへのプロトコル切り替えを許可すると判断したことに応答して、選択されたＨＴＴＰ−ＳＩＰアダプタに対する上記ＳＩＰ勧誘リクエストを生成するよう構成される、実施例２３または２４に記載のＩＭＳネットワークコンポーネント。

実施例２６：上記選択されたＨＴＴＰ−ＳＩＰアダプタに対する上記ＳＩＰ勧誘リクエストは、セッション記述プロトコル（ＳＤＰ）オファーと、上記修復サーバに向けられたリクエストユニフォームリソース識別子（リクエストＵＲＩ）とを含む、実施例２３から２５のいずれか一例に記載のＩＭＳネットワークコンポーネント。

実施例２７：上記リクエストＵＲＩは、コンテンツ識別子を含むユーザ部分と、サービスプロバイダドメイン名を含むドメイン部分とを含む、実施例２６に記載のＩＭＳネットワークコンポーネント。

実施例２８：マシンに実行された場合に上記マシンに処理を実行させる命令を格納したマシン可読媒体であり、
上記処理は、セッション開始プロトコル再勧誘リクエスト（ＳＩＰ再勧誘リクエスト）をユーザ機器（ＵＥ）から受信する処理を備え、
上記再勧誘リクエストは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ユニキャストベアラーを用いたファイル修復手順の開始を要求し、
上記リクエストは、修復サーバのアドレスを含み、
上記処理はさらに、
ＨＴＴＰ−ＳＩＰアダプタを選択し、選択された上記ＨＴＴＰ−ＳＩＰアダプタに対するＳＩＰ勧誘リクエストを生成する処理と、
上記ＨＴＴＰ−ＳＩＰアダプタが上記修復サーバとのファイル修復手順をセットアップしたことを示すＳＩＰ肯定応答メッセージを、上記ＨＴＴＰ−ＳＩＰアダプタから受信したことに応答して、上記ＵＥとブロードキャスト−マルチキャストサービスセンターユーザプレーンファンクション（ＢＭＳＣ．ＵＰＦ）との間のマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）ダウンロードセッションを終了し、ＨＴＴＰベースの配信を開始すべく上記肯定応答を上記ＵＥへ転送する処理と
を備える、マシン可読媒体。

実施例２９：上記命令はさらに、上記マシンにより実行された場合に上記マシンに、上記ＵＥへのＭＢＭＳベアラーをセットアップする処理を実行させる命令を備え、
上記セットアップする処理は、上記ＨＴＴＰ修復サーバの上記アドレスを送信する処理を有する、実施例２８に記載のマシン可読媒体。

実施例３０：上記命令はさらに、上記マシンにより実行された場合に上記マシンに、リクエスト内で特定される上記メディアアイテムがＭＢＭＳからＨＴＴＰへのプロトコル切り替えを許可すると判断したことに応答して、上記選択されたＨＴＴＰ−ＳＩＰアダプタに対する上記ＳＩＰ勧誘リクエストを生成させる処理を実行させる命令を備える、実施例２８または２９に記載のマシン可読媒体。

実施例３１：上記選択されたＨＴＴＰ−ＳＩＰアダプタに対する上記ＳＩＰ勧誘リクエストは、セッション記述プロトコル（ＳＤＰ）オファーと、上記修復サーバに向けられたリクエストユニフォームリソース識別子（リクエストＵＲＩ）とを含む、実施例２８から３０のいずれか一例に記載のマシン可読媒体。

実施例３２：上記リクエストＵＲＩは、コンテンツ識別子を含むユーザ部分と、サービスプロバイダドメイン名を含むドメイン部分とを含む、実施例３１に記載のマシン可読媒体。

上記の詳細な説明は、詳細な説明の一部を形成する添付の図面の参照を含む。図面は図示により、実施され得る特定の実施形態を示す。これらの実施形態は本明細書において、「実施例」とも呼ばれる。そのような実施例は、示された、または説明されたものに加えて要素を含み得る。しかし、本発明者らは、それら示された、または説明された要素のみが提供される実施例も想定している。さらに、本発明者らは、本明細書に示された、または説明された特定の実施例（またはその１または複数の態様）に関連して、または、他の実施例（またはその１または複数の態様）に関連して、示された、または説明されたそれらの要素（またはその１または複数の態様）の何らかの組み合わせ、または置き換えを用いる実施例も想定している。

本文書において言及される全ての出版物、特許、および特許文献はその全体が、まるで個別に参照により組み込まれているかのように、本明細書に参照により組み込まれる。本明細書とそれら参照により組み込まれる文書との間で矛盾する使用があった場合には、組み込まれる参照文献の使用は、本明細書のものの補足であるものとして見なされるべきであり、相容れない矛盾に関しては、本明細書における使用が有効となる。

本文書において、「１つ」という用語は、特許文献では一般的であるように、「少なくとも１つ」または「１または複数」の何らかの他の例または使用と独立して、１の、または１より大きい数を含むものとして用いられる。本文書において、「または」という用語は、異なるように示されない限り非排他的に、または、「ＡまたはＢ」が「ＡであるがＢではない」、「ＢであるがＡではない」、および「ＡおよびＢ」を含むように用いられる。添付の請求項において「含み」および「ここで」といった用語は、「備える」および「ここで」という各々の用語の平易な英語の同等物として用いられる。また以下の請求項において、「含む」および「備える」という用語は無制限であり、つまり、請求項においてそのような用語の前に列挙されるものに加えて要素を含むシステム、デバイス、物品、または処理がそれでも請求項の範囲内に含まれるものとして見なされる。さらに、以下の請求項において、「第１」、「第２」、「第３」、その他の用語は、単なる符号としてのみ用いられており、それらのオブジェクトに対して数字に関わる条件を課すことを意図してない。

上記の説明は限定的ではなく例示的であるよう意図されている。例えば、上述した実施例（またはその１または複数の態様）は、互いに組み合わせて用いられ得る。上記の説明を検討することにより当業者によってなど、他の実施形態が用いられ得る。要約は３７ Ｃ．Ｆ．Ｒ．§１．７２（ｂ）に準拠して、読者が、技術的開示の本質を即座に確認することが可能であるよう提供されている。要約は、請求項の範囲または意味を解釈または限定するために用いられることがないという理解のもと提出されている。また、上記の詳細な説明において、開示を効率化すべく様々な特徴が一緒にグループ化されているかもしれない。このことは、特許請求されていない開示されている特徴がいずれかの請求項にとって必須であることを意図するものとして解釈されるべきではない。むしろ、発明の主題は、特定の開示されている実施形態の全ての特徴を含まなくてもよい。よって、以下の請求項はここにおいて詳細な説明に組み込まれ、各請求項は、別個の実施形態として独立している。特許請求される主題の範囲は、添付の請求項を参照し、そのような請求項が権利を認められる完全な範囲の同等物と併せて判断されるべきである。

Claims (23)

1. ユーザ機器（ＵＥ）であり、
   プロセッサを備え、
   前記プロセッサは少なくとも、
   マルチメディアブロードキャストマルチキャストサービスベアラー（ＭＢＭＳベアラー）を通じてダウンロードされたファイルが不完全であるとの判断に応答して、インターネットプロトコルマルチメディアコアネットワーク（ＩＭ ＣＮ）サブシステムに送信されたセッション開始プロトコル再勧誘メッセージ（ＳＩＰ再勧誘メッセージ）であって、セッション記述プロトコル（ＳＤＰ）オファーと前記ＩＭ ＣＮサブシステムによりファイル修復サーバとして示されたＨＴＴＰサーバのユニフォームリソース識別子（ＵＲＩ）とを含むＳＩＰ再勧誘メッセージを用いて、ファイル修復セッションを開始し、
   前記ＳＩＰ再勧誘メッセージが成功であったことを示す情報を受信し、
   前記ファイルの不完全な１つ又は複数の部分を要求すべく、ハイパーテキスト転送プロトコルリクエスト（ＨＴＴＰリクエスト）を前記ＵＲＩに送信し、
   前記ＨＴＴＰサーバの前記ＵＲＩは、前記ＭＢＭＳベアラーのセットアップの間に受信されているＵＥ。
2. 前記プロセッサは少なくとも、ＳＩＰを用いた前記ＭＢＭＳベアラーのセットアップを行う、請求項１に記載のＵＥ。
3. 前記プロセッサは少なくとも、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルを利用することにより前記ＭＢＭＳベアラーを用いて前記ファイルのダウンロードを試行する、請求項１または２に記載のＵＥ。
4. 前記プロセッサは少なくとも、ロングタームエボリューション（ＬＴＥ）又はロングタームエボリューションアドバンスト（ＬＴＥ−Ａ）ファミリ規格に従って前記ＩＭ ＣＮサブシステムと無線で通信する、請求項１から３のいずれか１項に記載のＵＥ。
5. 前記ＨＴＴＰリクエストはＧＥＴリクエストである、請求項１から４のいずれか１項に記載のＵＥ。
6. 前記ＵＥは、タッチセンサ式ディスプレイインタフェースを備える、請求項１から５のいずれか１項に記載のＵＥ。
7. 少なくとも、
   マルチメディアブロードキャストマルチキャストサービスベアラー（ＭＢＭＳベアラー）を通じてダウンロードされたファイルが不完全であるとの判断に応答して、インターネットプロトコルマルチメディアコアネットワーク（ＩＭ ＣＮ）サブシステムへのセッション開始プロトコル再勧誘メッセージ（ＳＩＰ再勧誘メッセージ）であって、セッション記述プロトコル（ＳＤＰ）オファーと前記ＩＭ ＣＮサブシステムによりファイル修復サーバとして示されたＨＴＴＰサーバのユニフォームリソース識別子（ＵＲＩ）とを含むＳＩＰ再勧誘メッセージを用いて、ファイル修復セッションを開始し、
   前記ＳＩＰ再勧誘メッセージが成功であったことを示す情報を受信し、
   前記ファイルの不完全な１つ又は複数の部分を要求すべく、ハイパーテキスト転送プロトコルリクエスト（ＨＴＴＰリクエスト）を前記ＵＲＩに送信する
   ための手順であって、前記ＨＴＴＰサーバの前記ＵＲＩが前記ＭＢＭＳベアラーのセットアップの間に受信されている手順をマシンに実行させるプログラム。
8. 前記プログラムは、
   少なくとも、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）プロトコルを利用することにより前記ＭＢＭＳベアラーを用いて前記ファイルをダウンロードするための手順を前記マシンに実行させる、請求項７に記載のプログラム。
9. 前記プログラムは、
   少なくとも、ロングタームエボリューション（ＬＴＥ）又はロングタームエボリューションアドバンスト（ＬＴＥ−Ａ）アドバンストファミリ規格に従って前記ＩＭ ＣＮサブシステムと無線で通信するための手順を前記マシンに実行させる、請求項７または８に記載のプログラム。
10. 前記ＨＴＴＰリクエストは、ＧＥＴリクエストである、請求項７から９のいずれか１項に記載のプログラム。
11. 前記プログラムは、
    前記ファイルの１又は複数のエンコードシンボルがデコードされ得ないとの判断によって、ダウンロードされた前記ファイルが不完全であると判断するための手順を、前記マシンに実行させる、請求項７から１０のいずれか１項に記載のプログラム。
12. 請求項７から１１のいずれか１項に記載のプログラムを格納したコンピュータ可読記録媒体。
13. インターネットプロトコルマルチメディアサブシステムネットワーク（ＩＭＳネットワーク）コンポーネントであり、
    サービス調整機能（ＳＣＦ）であって、少なくとも、
    ハイパーテキスト転送プロトコル（ＨＴＴＰ）ユニキャストベアラーを用いて、インターネットプロトコルマルチメディアコアネットワーク（ＩＭ ＣＮ）サブシステムから、ユーザ機器（ＵＥ）のためにファイル修復手続を開始するためのＳＩＰ再勧誘リクエストを受信し、
    ＨＴＴＰ−ＳＩＰアダプタを選択し、
    前記選択されたＨＴＴＰ−ＳＩＰアダプタに対してＳＩＰリクエストを送信し、
    前記ＵＥとブロードキャスト−マルチキャストサービスセンターユーザプレーンファンクション（ＢＭＳＣ．ＵＰＦ）との間の、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）ベースのマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）ダウンロードセッション（ＭＢＭＳダウンロードセッション）を終了し、
    前記選択されたＨＴＴＰ−ＳＩＰアダプタからＳＩＰ肯定応答メッセージを受信したことに応答して、ＨＴＴＰベースの配信の開始を前記ＵＥに通知すべく前記ＳＩＰ肯定応答メッセージを前記ＩＭ ＣＮサブシステムへ転送するためのＳＣＦ
    を備えるＩＭＳネットワークコンポーネント。
14. 前記ＳＣＦは少なくとも、ＦＬＵＴＥベースの前記ＭＢＭＳダウンロードセッションの確立の間に、ＨＴＴＰ修復サーバのアドレスを送信する、請求項１３に記載のＩＭＳネットワークコンポーネント。
15. 前記ＳＩＰ再勧誘リクエスト内で特定されるメディアアイテムがＭＢＭＳからＨＴＴＰへのプロトコル切り替えを許可すると判断したことに応答して、前記ＳＣＦは、前記選択されたＨＴＴＰ−ＳＩＰアダプタに対するＳＩＰリクエストを生成する、請求項１３または１４に記載のＩＭＳネットワークコンポーネント。
16. 前記選択されたＨＴＴＰ−ＳＩＰアダプタに対する前記ＳＩＰリクエストは、セッション記述プロトコル（ＳＤＰ）オファーと、ＨＴＴＰ修復サーバに向けられたリクエストユニフォームリソース識別子（リクエストＵＲＩ）とを含む、請求項１３から１５のいずれか１項に記載のＩＭＳネットワークコンポーネント。
17. 前記リクエストＵＲＩは、コンテンツ識別子を含むユーザ部分と、サービスプロバイダドメイン名を含むドメイン部分とを含む、請求項１６に記載のＩＭＳネットワークコンポーネント。
18. 少なくとも、
    ハイパーテキスト転送プロトコル（ＨＴＴＰ）ユニキャストベアラーを用いて、インターネットプロトコルマルチメディアコアネットワーク（ＩＭ ＣＮ）サブシステムから、ユーザ機器（ＵＥ）のためにファイル修復手続を開始するためのＳＩＰ再勧誘リクエストを受信し、
    ＨＴＴＰ−ＳＩＰアダプタを選択し、
    前記選択されたＨＴＴＰ−ＳＩＰアダプタに対してＳＩＰリクエストを送信し、
    前記ＵＥとブロードキャスト−マルチキャストサービスセンターユーザプレーンファンクション（ＢＭＳＣ．ＵＰＦ）との間の、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（ＦＬＵＴＥ）ベースのマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）ダウンロードセッション（ＭＢＭＳダウンロードセッション）を終了し、
    前記選択されたＨＴＴＰ−ＳＩＰアダプタからＳＩＰ肯定応答メッセージを受信したことに応答して、ＨＴＴＰベースの配信の開始を前記ＵＥに通知すべく前記ＳＩＰ肯定応答メッセージを前記ＩＭ ＣＮサブシステムへ転送する
    ための手順をマシンに実行させる、プログラム。
19. 前記プログラムは少なくとも、ＦＬＵＴＥベースの前記ＭＢＭＳダウンロードセッションの確立の間に、ＨＴＴＰ修復サーバのアドレスを送信するための手順を前記マシンに実行させる、請求項１８に記載のプログラム。
20. 前記プログラムは少なくとも、前記ＳＩＰ再勧誘リクエスト内で特定されるメディアアイテムがＭＢＭＳからＨＴＴＰへのプロトコル切り替えを行うことを許可すると判断したことに応答して、前記選択されたＨＴＴＰ−ＳＩＰアダプタに対するＳＩＰリクエストを生成する手順を前記マシンに実行させる、請求項１８又は１９に記載のプログラム。
21. 前記選択されたＨＴＴＰ−ＳＩＰアダプタに対する前記ＳＩＰリクエストは、セッション記述プロトコル（ＳＤＰ）オファーと、ＨＴＴＰ修復サーバに向けられたリクエストユニフォームリソース識別子（リクエストＵＲＩ）とを含む、請求項１８から２０のいずれか１項に記載のプログラム。
22. 前記リクエストＵＲＩは、コンテンツ識別子を含むユーザ部分と、サービスプロバイダドメイン名を含むドメイン部分とを含む、請求項２１に記載のプログラム。
23. 請求項１８から２２のいずれか１項に記載のプログラムを格納したコンピュータ可読記録媒体。

Images