(57)【要約】  ＤＡＳＨ形式コンテンツのＨＴＴＰベースの配信とＭＢＭＳダウンロードとの間のＰ２Ｐ切り替えを提供するテクノロジーが開示される。一例において、ホストＵＥが、モバイル装置へのＤＡＳＨベースのコンテンツの配信のためのＳＩＰセッションを終了するようにサービス制御ファンクション（ＳＣＦ）モジュールからセッション開始プロトコル（ＳＩＰ）終了メッセージを受信し、モバイル装置に転送されるべきＳＩＰ肯定応答メッセージをＳＣＦに送信し、ＭＢＭＳダウンロードのためにモバイル装置とホストモバイル装置上で動作するＢＭＳＣ．ＵＰＦモジュールとの間でＦＬＵＴＥプロトコルベースのＭＢＭＳダウンロードセッションを確立するように構成されたコンピュータ回路を含むことができる。切り替えを使用したＢＭＳＣを介したＰ２Ｐ  ＭＢＭＳダウンロードとＨＴＴＰサーバを介したファイル修復とについてのテクノロジーも開示される。
2015530833.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからＤＡＳＨ（ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）形式コンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールが、
ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭ‐ＳＣ．ＵＰＦ）モジュールからコンテンツ配信セッションにおいてＤＡＳＨ形式コンテンツを含むＭＢＭＳダウンロードをモバイル装置が受信している間、サービス制御ファンクション（ＳＣＦ）モジュールにおいて前記モバイル装置からセッション開始プロトコル（ＳＩＰ）再招待を受信し、
前記モバイル装置へのＨＴＴＰベースの配信のために前記ホストモバイル装置又は別のホストモバイル装置上で動作するＨＴＴＰサーバを選択するように、前記ＳＣＦモジュールから前記ホストモバイル装置上で動作するＨＴＴＰ／ＳＩＰアダプタにＳＩＰ招待を送信し、
前記ＳＣＦモジュールにおいて、前記ＨＴＴＰ／ＳＩＰアダプタから、前記コンテンツ配信セッションのための前記ホストモバイル装置上の前記ＨＴＴＰサーバの選択を示すＳＩＰ肯定応答を受信し、
前記コンテンツ配信セッションのための前記ＨＴＴＰサーバへの切り替えを示す前記ＳＩＰ肯定応答を前記モバイル装置に転送する、
ように構成させたコンピュータ回路。
【請求項２】
前記ＳＩＰ再招待は、前記モバイル装置からインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）コアネットワーク（ＩＭ  ＣＮ）サブシステムにおいて受信され、前記ＩＰ  ＣＮサブシステムは前記ＳＩＰ再招待を前記ＳＣＦに転送するように構成される、請求項１記載のコンピュータ回路。
【請求項３】
前記コンピュータ回路は、サービス品質（ＱＯＳ）予約を可能にするように前記ＳＩＰ肯定応答を前記ＩＭ  ＣＮサブシステムに送信するようにさらに構成され、前記ＩＭ  ＣＮサブシステムは、前記コンテンツ配信セッションのための前記ＨＴＴＰサーバへの切り替えを示す前記ＳＩＰ肯定応答を前記モバイル装置に転送する、請求項２記載のコンピュータ回路。
【請求項４】
セッション記述プロトコル（ＳＤＰ）オファーとリクエストＵＲＩとが前記ＳＩＰ再招待メッセージに含まれる、請求項１記載のコンピュータ回路。
【請求項５】
前記コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えが前記モバイル装置においてサポートされるかを判定するようにさらに構成される、請求項１記載のコンピュータ回路。
【請求項６】
前記コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えが前記モバイル装置において利用可能であるとき、前記ホストモバイル装置において動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールと前記モバイル装置との間のＭＢＭＳコンテンツ配信セッションを破棄するようにさらに構成される、請求項１記載のコンピュータ回路。
【請求項７】
前記ＳＩＰ再招待はＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージを含み、前記ＳＩＰ招待はＳＩＰ  ＩＮＶＩＴＥメッセージを含み、前記ＳＩＰ肯定応答はＳＩＰ２００  ＯＫを含む、請求項１記載のコンピュータ回路。
【請求項８】
モバイル装置へのＤＡＳＨ（ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）形式コンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信からマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードに切り替えるように動作可能なホストモバイル装置が、
モバイル装置へのＤＡＳＨベースのコンテンツの配信のためのＳＩＰセッションを終了するように、前記ホストモバイル装置上で動作するＨＴＴＰ／ＳＩＰアダプタにおいてサービス制御ファンクション（ＳＣＦ）モジュールからセッション開始プロトコル（ＳＩＰ）終了メッセージを受信し、
前記モバイル装置に転送されるべきＳＩＰ肯定応答メッセージを前記ＳＣＦに送信し、
ＭＢＭＳダウンロードのために前記モバイル装置と前記ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールとの間でＦＬＵＴＥ（ｆｉｌｅ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｔｒａｎｓｐｏｒｔ）プロトコルベースのＭＢＭＳダウンロードセッションを確立する、
ように構成させたコンピュータ回路。
【請求項９】
前記ＳＩＰ終了はＳＩＰ  ＢＹＥメッセージを含み、前記ＳＩＰ肯定応答はＳＩＰ２００  ＯＫメッセージを含む、請求項８記載のコンピュータ回路。
【請求項１０】
前記ホストモバイル装置は、コンテンツのユニキャスト及びマルチキャスト配信をサポートするエアインタフェースを介して前記モバイル装置と通信する、請求項８記載のコンピュータ回路。
【請求項１１】
前記ホストモバイル装置は、第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）標準  リリース８、９、１０又は１１と米国電気電子学会（ＩＥＥＥ）８０２．１６ｍ‐２０１１標準とを含む群から選択されたプロトコルを使用する、請求項８記載のコンピュータ回路。
【請求項１２】
前記ホストモバイル装置は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）及びワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のうち少なくとも１に接続するように構成され、前記モバイル装置は、アンテナ、タッチセンサ式ディスプレイ画面、スピーカ、マイクロフォン、グラフィクスプロセッサ、アプリケーションプロセッサ、内部メモリ、不揮発性メモリポート又はこれらの組み合わせを含む、請求項８記載のコンピュータ回路。
【請求項１３】
ファイル修復のためにマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからコンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールが、
ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭ‐ＳＣ．ＵＰＦ）モジュールからコンテンツ配信セッションにおいてＤＡＳＨ形式コンテンツを含むＭＢＭＳダウンロードをモバイル装置が受信している間、サービス制御ファンクション（ＳＣＦ）モジュールにおいて前記モバイル装置からセッション開始プロトコル（ＳＩＰ）再招待を受信し、
前記ＳＩＰ再招待がファイル修復手順に関すると判定し、
前記ＳＣＦモジュールから前記ファイル修復手順に使用されるＨＴＴＰ／ＳＩＰアダプタにＳＩＰ招待を送信し、ただし前記ＨＴＴＰ／ＳＩＰアダプタは前記ホストモバイル装置又は別のホストモバイル装置上で動作するように構成され、
前記ＳＣＦモジュールにおいて、前記ＨＴＴＰ／ＳＩＰアダプタから、要求されたファイル修復コンテンツのコンテンツ配信のための前記ホストモバイル装置又は他のホストモバイル装置上のＨＴＴＰサーバの選択を示すＳＩＰ肯定応答を受信し、
前記要求されたファイル修復コンテンツのコンテンツ配信のための前記ＨＴＴＰサーバへの切り替えを示す前記ＳＩＰ肯定応答を前記モバイル装置に転送する、
ように構成させたコンピュータ回路。
【請求項１４】
前記ＳＩＰ再招待は、前記モバイル装置からインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）コアネットワーク（ＩＭ  ＣＮ）サブシステムにおいて受信され、前記ＩＰ  ＣＮサブシステムは前記ＳＩＰ再招待を前記ＳＣＦに転送するように構成される、請求項１３記載のコンピュータ回路。
【請求項１５】
前記ＳＩＰ再招待は、セッション記述プロトコル（ＳＤＰ）オファーとリクエスト・ユニフォームリソース識別子（ＵＲＩ）とを含み、
前記ＵＲＩは、コンテンツ識別子と修復サーバアドレスＵＲＩとを含む、
請求項１３記載のコンピュータ回路。
【請求項１６】
前記コンピュータ回路は、前記コンテンツ識別子に関連付けられたコンテンツのためのユーザ権利について確認するようにさらに構成される、請求項１５記載のコンピュータ回路。
【請求項１７】
前記ＳＩＰ招待は、前記ＳＩＰ再招待の中と同じコンテンツ識別子を含むＴｏヘッダを含む、請求項１５記載のコンピュータ回路。
【請求項１８】
前記ＨＴＴＰ／ＳＩＰアダプタは、
前記Ｔｏヘッダの中の前記コンテンツ識別子を調べ、
前記修復サーバアドレスＵＲＩに従って前記ＨＴＴＰサーバを選択し、
前記モバイル装置のインターネットプロトコル（ＩＰ）アドレスを含むＨＴＴＰポストメッセージを前記ＨＴＴＰサーバに送信し、
前記リクエストＵＲＩを別のＨＴＴＰ／ＳＩＰアダプタにリダイレクトするかを判定する
ように構成される、請求項１７記載のコンピュータ回路。
【請求項１９】
前記ＨＴＴＰサーバは、前記ＳＩＰ肯定応答を前記ＨＴＴＰ／ＳＩＰアダプタに送信するように構成される、請求項１８記載のコンピュータ回路。
【請求項２０】
前記ＳＩＰ肯定応答は、前記要求されたファイル修復コンテンツのダウンロードＵＲＬを含むＭＢＭＳファイル修復セッションを記述するＳＤＰアンサーを含む、請求項１３記載のコンピュータ回路。
【請求項２１】
前記コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えが前記モバイル装置においてサポートされるかを判定するようにさらに構成される、請求項１３記載のコンピュータ回路。
【請求項２２】
前記コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えが前記モバイル装置において利用可能であるとき、前記ホストモバイル装置において動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールと前記モバイル装置との間のＭＢＭＳコンテンツ配信セッションを破棄するようにさらに構成される、請求項１３記載のコンピュータ回路。
【請求項２３】
前記ＳＩＰ再招待はＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージを含み、前記ＳＩＰ招待はＳＩＰ  ＩＮＶＩＴＥメッセージを含み、前記ＳＩＰ肯定応答はＳＩＰ２００  ＯＫを含む、請求項１３記載のコンピュータ回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＭＳベースのネットワークにおいて、ユーザへのＤＡＳＨ形式コンテンツの伝送の間、ＭＢＭＳダウンロード方法とＨＴＴＰベースの配信方法との間で切り替えることに関する。
【背景技術】
【０００２】
ワイヤレスモバイル通信テクノロジーは、様々な標準及びプロトコルを使用して、伝送局とワイヤレスモバイル装置との間でデータを伝送する。いくつかのワイヤレス装置は、物理層を介して、所望されるデジタル変調スキームと組み合わせられた直交周波数分割多重方式（ＯＦＤＭ）を使用して通信する。ＯＦＤＭを使用する標準及びプロトコルには、第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）、一般に業界団体にＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）として知られている米国電気電子学会（ＩＥＥＥ）８０２．１６標準（例えば、８０２．１６ｅ、８０２．１６ｍ）、及び一般に業界団体にＷｉＦｉとして知られているＩＥＥＥ８０２．１１が含まれる。
【０００３】
３ＧＰＰ無線アクセスネットワーク（ＲＡＮ）ＬＴＥシステムにおいて、伝送局は、Ｅ‐ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）ノードＢ（一般に、進化型ノードＢ、拡張型ノードＢ、ｅＮｏｄｅＢ又はｅＮＢとも記される）と無線ネットワークコントローラ（ＲＮＣ）との組み合わせであってよく、これが、ユーザ機器（ＵＥ）として知られるワイヤレスモバイル装置と通信する。ダウンリンク（ＤＬ）伝送は、伝送局（又はｅＮｏｄｅＢ）からワイヤレスモバイル装置（又はＵＥ）への通信であってよく、アップリンク（ＵＬ）伝送は、ワイヤレスモバイル装置から伝送局への通信であってよい。
【０００４】
ダウンリンク伝送において、伝送局は、ユニキャストサービスを使用してユニキャストサブフレームを用いて単一のワイヤレスモバイル装置と通信することができる。ユニキャスト配信は、１対１関係を有することができ、１のモバイル装置への１のメッセージを指す。別法として、伝送局は、マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）を使用してマルチキャスト／ブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）サブフレームを用いて複数のワイヤレスモバイル装置と通信することができる。ＭＢＭＳにおけるトランスポートのマルチキャスト及びブロードキャストトラフィックは、１対多関係を有することができ、多数のモバイル装置にへの１のメッセージを指す。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＩＭＳベースのネットワークにおいて、ユーザへのＤＡＳＨ形式コンテンツの伝送の間、ＭＢＭＳダウンロード方法とＨＴＴＰベースの配信方法との間で切り替えることが所望されることがある。
【課題を解決するための手段】
【０００６】
マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからＤＡＳＨ（ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）形式コンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールが、
ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭ‐ＳＣ．ＵＰＦ）モジュールからコンテンツ配信セッションにおいてＤＡＳＨ形式コンテンツを含むＭＢＭＳダウンロードをモバイル装置が受信している間、サービス制御ファンクション（ＳＣＦ）モジュールにおいて上記モバイル装置からセッション開始プロトコル（ＳＩＰ）再招待を受信し、
上記モバイル装置へのＨＴＴＰベースの配信のために上記ホストモバイル装置又は別のホストモバイル装置上で動作するＨＴＴＰサーバを選択するように、上記ＳＣＦモジュールから上記ホストモバイル装置上で動作するＨＴＴＰ／ＳＩＰアダプタにＳＩＰ招待を送信し、
上記ＳＣＦモジュールにおいて、上記ＨＴＴＰ／ＳＩＰアダプタから、上記コンテンツ配信セッションのための上記ホストモバイル装置上の上記ＨＴＴＰサーバの選択を示すＳＩＰ肯定応答を受信し、
上記コンテンツ配信セッションのための上記ＨＴＴＰサーバへの切り替えを示す上記ＳＩＰ肯定応答を上記モバイル装置に転送する、
ように構成させたコンピュータ回路が開示される。
【図面の簡単な説明】
【０００７】
本願開示の特徴及び利点は、例として本願開示の特徴を共に例示する添付図面と関連して、後に続く詳細な説明から明らかになるであろう。
【図１】一例に従う、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ベースのピアツーピア（Ｐ２Ｐ）コンテンツ配布システムのブロック図を示す。
【図２】一例に従う、Ｐ２ＰのためのＩＭＳベースのパケット交換ストリーミングサービス（ＰＳＳ）及びＭＢＭＳの機能的アーキテクチャのブロック図を示す。
【図３】一例に従う、ブロードキャスト・マルチキャスト・サービス・センタ（ＢＭＳＣ）・ユーザ・プレーン・サブファンクション（ＵＰＦ）（ＢＭＳＣ．ＵＰＦ）のブロック図を示す。
【図４】一例に従う、Ｐ２Ｐを使用したマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからＤＡＳＨ（Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）のハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替える手順の図を示す。
【図５】一例に従う、Ｐ２Ｐを使用したＨＴＴＰベースの配信からＤＡＳＨコンテンツのＭＢＭＳダウンロード配信に切り替える手順の図を示す。
【図６】一例に従う、ＨＴＴＰサーバを使用した一例示的なＭＢＭＳファイル修復手順を示す。
【図７】一例に従う、Ｐ２Ｐを使用したＢＭＳＣを介したＭＢＭＳダウンロードとＨＴＴＰサーバを介したファイル修復とのための手順の図を示す。
【図８】一例に従う、Ｐ２Ｐを使用したＭＢＭＳダウンロードからＤＡＳＨ形式コンテンツのＨＴＴＰベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールのコンピュータ回路の機能性を表す。
【図９】一例に従う、Ｐ２Ｐを使用したモバイル装置へのＤＡＳＨ形式コンテンツのＨＴＴＰベースの配信からＭＢＭＳダウンロードに切り替えるように動作可能なホストモバイル装置のコンピュータ回路の機能性を表す。
【図１０】一例に従う、Ｐ２Ｐを使用したファイル修復のためにＭＢＭＳダウンロードからデータのＨＴＴＰベースの配信に切り替えるように動作可能なＳＣＦモジュールのコンピュータ回路の機能性を表す。
【図１１】一例に従う、ワイヤレス装置（例えば、ＵＥ）の図を示す。
【発明を実施するための形態】
【０００８】
次に、図示される例示的実施形態が参照され、特定の言語が本明細書において上記例示的実施形態を説明するために使用される。それにもかかわらず、これにより本発明の範囲の限定が意図されはしないことを理解されたい。
【０００９】
本発明が開示され及び説明される前に、本発明は、本明細書に開示される特定の構造、プロセス、ステップ又は素材に限定されず、当業者に認識されるであろうとおり、これらの均等物に及ぶことが理解されるべきである。本明細書に採用される専門用語は、単に特定の例を説明する目的で使用されており、限定的であることは意図されないことも理解されるべきである。種々の図面における同じ参照番号は、同じ要素を表す。フローチャート及びプロセスに提供される数字は、ステップ及びオペレーションを例示することにおいて明りょうさのために提供されており、必ずしも特定の順序又はシーケンスを示すものではない。
【００１０】
例示的実施形態
テクノロジー実施形態の最初の概説が以下に提供され、それから、特定のテクノロジー実施形態が後からさらに詳細に説明される。この最初の概要は、読み手がテクノロジーをより迅速に理解することを支援するものであり、本願テクノロジーの重要な特徴又は必須の特徴を識別するものではなく、請求される対象事項の範囲を限定するものでもない。
【００１１】
ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングは、インターネットビデオのマルチメディア配信の形態として使用することができる。ＨＴＴＰベースの配信は、トランスミッション制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）を含むＨＴＴＰとＨＴＴＰの下層のプロトコルとの双方の広範の採用に起因して、信頼性と配備簡素化とを提供することができる。ＨＴＴＰベースの配信は、ネットワークアドレス変換（ＮＡＴ）及びファイアウォールトラバーサル問題を回避することによって、容易な及び楽なストリーミングサービスを可能にすることができる。ＨＴＴＰベースの配信又はストリーミングは、特殊化したストリーミングサーバに代わって標準ＨＴＴＰサーバ及びキャッシュを使用する能力を提供することもできる。ＨＴＴＰベースの配信は、サーバ側における最小の又は低減された状態情報に起因して、スケーラビリティを提供することができる。
【００１２】
ＤＡＳＨ（Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）は、マルチメディアストリーミングテクノロジーであり、これにおいて、マルチメディアファイルは、１又は複数のセグメントに分割され、ＨＴＴＰを使用してクライアントに配信されることができる。ＤＡＳＨクライアントは、一連のＨＴＴＰリクエスト‐レスポンストランザクションを通してセグメントをダウンロードすることによって、マルチメディアコンテンツを受信することができる。ＤＡＳＨは、利用可能な帯域幅が変化するとき、メディアコンテンツのビットレート又はエンコーディングタイプを含む種々の表現にわたって動的に切り替える能力を提供することができる。したがって、ＤＡＳＨは、変化するネットワーク及びワイヤレスリンク状態、ユーザ選好及び表示解像度などの装置能力、採用される中央プロセシングユニット（ＣＰＵ）のタイプ、又は利用可能なメモリリソースに対して、迅速な適応を可能にすることができる。ＤＡＳＨの動的適応は、より短い起動遅延時間及びより少ない再バッファリング事象と共に、より良好な体感品質（ＱｏＥ）をユーザに提供することができる。
【００１３】
インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）又はＩＰマルチメディアコアネットワークサブシステム（ＩＭ  ＣＮ）は、ＩＰマルチメディアサービスを配信するための３ＧＰＰにおける構造的フレームワークである。ＩＰマルチメディアコアネットワークサブシステムは、標準化されたインタフェースによってリンクされた種々のコアネットワークファンクション及びアクセスネットワークファンクションの集合であり得、これらが一緒にグループ化されると、１のＩＭＳ管理ネットワークを形成することができる。
【００１４】
Ｐ２Ｐコンテンツ配布
ピアツーピア（Ｐ２Ｐ）通信の使用は、ストリーミングメディアをモバイル装置に配信することにおいて有意な改良を提供することができる。メディアコンテンツ消費の爆発的成長と共に、ストリーミングサービスを提供するメディアサーバの数は、ユーザの数に対してほぼ直線的に増加を必要とされている。さらに、集中型のストリーミングメディアサーバは、基幹ＩＰネットワークの帯域幅に関して相当な需要を有する。さらに多くのエッジサーバが、所望されるサービス品質（ＱｏＳ）及び／又は体感品質（ＱｏＥ）を提供するためにＵＥの近くに配備される。
【００１５】
ピアツーピアテクノロジーは、ＵＥの近くに配備されることを必要とされるエッジサーバの数を低減するようにエッジサーバとＵＥとの間で使用されてよい。モバイル装置の能力が許容する場合、ＵＥは、ストリーミングデータのためのスペアのアップリンク帯域幅及び記憶空間を提示することができる。ストリーミングデータは、他の要求された宛先にアップロードされてもよい。
【００１６】
一実施形態において、ＩＭＳは、マルチメディアサービスを提供する固定とモバイルとの融合コアネットワークであってよい。さらに、ＩＭＳは、ユーザ認証、登録、サービス発見及びマルチメディアセッション制御のためのインフラストラクチャを提供することができる。図１は、ＩＭＳベースのＰ２Ｐコンテンツ配布システム１００の概説を提供する。一実施形態において、ＩＭＳ構成された（IMS  configured）ＵＥ１１０が、固定の又はモバイルのアクセスネットワークを介してＩＭＳ  ＣＮサブシステム１０２にコンテンツ配布を開始することができる。ＩＭＳ  ＵＥは、コンテンツのインデクス化、ブラウジング及び検索の機能性を提示することができるポータル１０４にリダイレクトされてもよい。コンテンツは、ＵＥのネットワークサーバ１０６などのコンテンツサーバに記憶されてもよい。コンテンツキャッシュサーバ１０８が、コンテンツ配布を加速するようにユーザの近くに配備されてもよい。
【００１７】
ユーザプロファイルがＩＭＳ１００に記憶されてもよく、ＵＥ１１０などの端末の能力（すなわち、処理能力、画面サイズ、３ＧＰＰ能力）がユーザの選好と共にＰ２Ｐアプリケーションサービスに記憶されてもよい。ＵＥ能力は、ＵＥ又はＵＥ上で動作するクライアントが要求されたコンテンツを受信する能力があるか否かを決めるために使用されてもよい。コンテンツ制御は、コンテンツがネットワークの中でどのように配布されるかとＵＥが要求されたコンテンツをどこで入手できるかとを制御するために使用されてもよい。
【００１８】
インターネットとの統合を容易にするために、ＩＭＳは、セッション開始プロトコル（ＳＩＰ）を使用することができる。ＳＩＰサーバ又はプロキシのいくつかの役割が、呼セッション制御ファンクション（ＣＳＣＦ）と集合的に呼ばれることがあり、これらは、ＩＭＳにおいてＳＩＰシグナリングパケットを処理するために使用されてもよい。固定アクセス（例えば、デジタル加入者線（ＤＳＬ）、ケーブルモデム又はイーサネット（登録商標））、モバイルアクセス（例えば、Ｗ‐ＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ（登録商標）又はＧＰＲＳ）、及びワイヤレスアクセス（例えば、ＷＬＡＮ（ＩＥＥＥ８０２．１１‐２０１２）又はＷＷＡＮ（３ＧＰＰ  ＬＴＥ  リリース１０、１１又はＩＥＥＥ８０２．１６ｍ‐２０１１））が、ＩＭＳによってサポートされてもよい。平易な旧来の電話（ＰＯＴＳ  ‐  アナログ電話）システムや非ＩＭＳ互換のボイスオーバーＩＰ（ＶｏＩＰ）システムのような他の電話システムが、ゲートウェイを通してサポートされてもよい。ＤＡＳＨ形式（DASH-formatted）コンテンツが、マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロード配信などのマルチキャストフレームにおいて、又はＨＴＴＰベースの配信などのユニキャストフレームにおいてＩＭＳ又はＩＭ  ＣＮネットワークを通じて配信されてもよい。
【００１９】
一実施形態において、ＤＡＳＨコンテンツを含むコンテンツ配信セッションが、ＭＢＭＳダウンロード方法を使用して配信され、それからセッションの中間で（セッション途中で）ＨＴＴＰベースの配信方法に切り替えられてよい。別法として、コンテンツ配信セッションは、ＨＴＴＰベースの配信方法を使用して配信され、それからセッション途中でＭＢＭＳダウンロード方法に切り替えられてもよい。ＩＭＳベースのネットワークにおいて、ユーザへのＤＡＳＨ形式コンテンツの伝送の間、ＭＢＭＳダウンロード方法とＨＴＴＰベースの配信方法との間で切り替えることが所望されることがある。
【００２０】
次に、ＭＢＭＳ及びＨＴＴＰベースの配信の概要を示す。本概要は、完全なものではない。オンデマンド又はライブコンテンツのユニキャストストリーミングのためのリアルタイムストリーミングプロトコル（ＲＴＳＰ）に基づいたパケット交換ストリーミングサービス（ＰＳＳ）のより完全な解説が、３ＧＰＰ技術仕様書（ＴＳ）２６．２３４に提供される。プログレッシブダウンロードとＤＡＳＨとを含むＨＴＴＰベースのストリーミングサービスが、３ＧＰＰ  ＴＳ２６．２４７に記述される。３ＧＰＰベースのＭＢＭＳ仕様書ＴＳ２６．３４６は、マルチキャスト／ブロードキャストコンテンツ配布のためのストリーミング及びダウンロード手法を規定する。ＤＡＳＨ／ＰＳＳ／ＭＢＭＳユーザサービスと関連するストリーミング及びダウンロード手順とのＩＭＳベースの拡張が、３ＧＰＰ  ＴＳ２６．２３７に提供される。
【００２１】
ＭＢＭＳダウンロード配信は、ＨＴＴＰベースのユニキャストダウンロード配信のための代わりのサービスであってもよい。ＭＢＭＳダウンロード配信を使用する利点には、非リアルタイムサービスタイプのサポートを可能にすること、ＭＢＭＳストリーミングサービスを補完するコンテンツの供給を可能にすること、及びモバイル装置上で増加させた記憶容量を利用することを含むことができる。ＤＡＳＨセグメント形式は、ＨＴＴＰを用いたユニキャストトランスポートを主に対象とするが、配信環境がユニキャスト又はマルチキャストであることについて不確か（agnostic）でもよい。ＤＡＳＨ形式コンテンツは、ＦＬＵＴＥ（ｆｉｌｅ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｔｒａｎｓｐｏｒｔ）プロトコルを用いてＭＢＭＳダウンロード配信を使用して伝送されてもよい。
【００２２】
ＦＬＵＴＥは、インターネットを通じたファイルの単方向配信のためのプロトコルであり得、マルチキャストネットワークに特に適し得る。ＦＬＵＴＥは、非同期階層型符号化（asynchronous  layered  coding）（ＡＬＣ）、大規模にスケーラブルなマルチキャスト配布のために設計されたベースプロトコル上に構築することができる。ＦＬＵＴＥは、階層型符号化トランスポート（layered  coding  transport）（ＬＣＴ）構築ブロックのインスタンス化を提供することができる。ＡＬＣプロトコルは、ＬＣＴ構築ブロック、輻輳制御（ＣＣ）構築ブロック及び前方誤り訂正（ＦＥＣ）構築ブロックを組み合わせて輻輳制御された信頼性のある非同期配信を提供することができる。ＬＣＴは、信頼性のあるコンテンツ配信及びストリーム配信プロトコルのためのトランスポートレベルサポートを提供することができる。ストリーミングデータ又はダウンロードは、ＭＢＭＳベアラを通じて配信されるとき、リアルタイムトランスポートプロトコル（ＲＴＰ）にカプセル化され、ＦＬＵＴＥプロトコルを使用して運ばれ得る。ＲＴＰは、電話通信、ビデオテレビ会議アプリケーション、テレビジョンサービス及びウェブベースのプッシュ・ツー・トーク機構などのストリーミングメディアに関与する通信及びエンタテインメントシステムにおいて使用され得る。
【００２３】
３のファンクション層が、ＭＢＭＳベースのサービスの配信のために使用されてよく、これらには、ベアラ層、配信方法層、及びユーザサービス層又はアプリケーション層を含むことができる。ベアラ層は、ＩＰデータを運ぶことができるメカニズムを提供することができる。ベアラには、ユニキャストベアラ又はＭＢＭＳベアラを含むことができる。配信層は、セキュリティ及びキー配布などの機能性、前方誤り訂正（ＦＥＣ）手法による信頼性制御、並びにファイル修復、配信検証などの関連する配信手順を提供することができる。配信方法には、ダウンロードとストリーミングとを含むことができる。ＭＢＭＳユーザサービスは、アプリケーションを有効にすることができる。ユーザサービスには、マルチメディアメッセージングサービス又はパケット交換ストリーミングサービス（ＰＳＳ）を含むことができる。
【００２４】
ＨＴＴＰを通じたＤＡＳＨベースの適応的ストリーミングは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）ベースの適応的ストリーミングとは異なり得る。ＲＴＳＰは、ストリーミングメディアサーバを制御するためにエンターテインメント及び通信システムにおいて使用されるネットワーク制御プロトコルであり得る。ＲＴＳＰプロトコルは、プッシュベースの、サーバにより制御される様態でエンドポイント間でメディアセッションを確立し及び制御することに使用され得るが、ＤＡＳＨベースの適応的ストリーミングは、プルベースであり得、クライアントにより制御され得る。メディアサーバのクライアントは、サーバからのメディアファイルのプレイバックのリアルタイム制御を容易にするように、再生、一時停止などのビデオカセットレコーダ（ＶＣＲ）のようなコマンドを発行することができる。いくつかの点でＨＴＴＰと同様であるが、ＲＴＳＰは、マルチメディアプレイバックを制御することに有用な制御シーケンスを定義することができる。ＨＴＴＰはステートレスであり得るが、ＲＴＳＰは、同時的なセッションを追跡するために必要とされるときに使用される状態又は識別子を有することができる。
【００２５】
ＤＡＳＨベースの適応的ストリーミング手法の使用に先行して、プログレッシブダウンロード方法もまた標準ＨＴＴＰウェブサーバからのメディア配信に利用可能であった。ＨＴＴＰベースのプログレッシブダウンロードの欠点には、プログレッシブダウンロードが始まった後にユーザが視聴をやめる（例えば、別のコンテンツに切り替える）と決めた場合に帯域幅が無駄にされ得ること、ダウンロードがあまりビットレートに適応的でなくなること、又はダウンロードがライブメディアサービスをサポートしないことを含むことができる。ＤＡＳＨテクノロジーは、ＲＴＰ／ＲＳＴＰベースのストリーミングとＨＴＴＰベースのプログレッシブダウンロードとの弱点に対処することができる。
【００２６】
ＤＡＳＨにおいて、メディアプレゼンテーション記述（media  presentation  description）（ＭＰＤ）メタデータファイルが、種々のビットレート、フレームレート、解像度、コーデックタイプ及び同様の情報を含め、サーバに記憶されたメディアコンテンツ表現の構造と種々のバージョンとに関する情報を提供することができる。ＭＰＤ情報は、プレゼンテーションを切り替えること及び他の表現と同期させることについて、セグメントのメディアプレゼンテーションタイムラインへのマッピングを保証するために使用されてもよい。さらに、ＤＡＳＨは、初期化に関する情報とメディアエンジンのためのメディアセグメントとなどのセグメント形式を規定することもできる。メディアエンジンは、コンテナ形式とメディアタイミング情報とを決定するように、初期化セグメントを表示することができる。
【００２７】
ＤＡＳＨテクノロジーの例には、Ｍｉｃｒｏｓｏｆｔ  ＩＩＳ  Ｓｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ、Ａｐｐｌｅ  ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ及びＡｄｏｂｅ  ＨＴＴＰ  Ｄｙｎａｍｉｃ  Ｓｔｒｅａｍｉｎｇを含むことができる。ＤＡＳＨテクノロジーはさらに、第３世代パートナーシッププロジェクト（３ＧＰＰ）、ＭＰＥＧ（ｍｏｖｉｎｇ  ｐｉｃｔｕｒｅ  ｅｘｐｅｒｔｓ  ｇｒｏｕｐ）及びオープンＩＰＴＶフォーラム（ＯＩＰＦ）などの機関によって標準化されている。
【００２８】
ＭＢＭＳとＤＡＳＨとの間の切り替え
適応的ストリーミングセッション又はコンテンツ配信セッションの全体について一貫したユーザ体感を提供するために、モバイル装置が、特定の状況に依存して、ＨＴＴＰベースの配信とＭＢＭＳダウンロードとの間を切り替えることができる。例えば、切り替える状況には、パケット交換ストリーミングサービス（ＰＳＳ）及びＭＢＭＳのカバレッジにおける変化、又はトリックプレイなどの特定のユーザ行為によって引き起こされることを含むことができる。トリックプレイ又はトリックモードには、早送り、巻き戻し、スローモーション、スロー巻き戻し、一時停止及び再開を含むことができる。トリックプレイ又はトリックモードは、モバイル装置によって受信したセグメントの処理に基づくことができる。受信した（又はダウンロードした）セグメントは、セグメントの基準タイムライン（内部のタイプスタンプ）が指示し得るより遅い、又はより速いスピードでデコーダに提供されることができ、したがって、所望されるトリック効果を画面又はメディアプレゼンテーション上に作り出すことができる。
【００２９】
モバイル装置は、ＭＢＭＳダウンロード又はＨＴＴＰベースのＤＡＳＨ形式コンテンツ配信セッションを既に確立していることがある。モバイル装置は、ＭＢＭＳダウンロードを受信している場合にＨＴＴＰベースの配信などの他の配信方法に切り替え、又はＨＴＴＰベースの配信を受信している場合にＭＢＭＳダウンロードに切り替える能力を有することができる。ＭＢＭＳダウンロードからＨＴＴＰベースの配信方法に切り替えるためのいくつかの関連する切り替えイベントの例は、チャネルを変えることなく提供されることがあり、チャネルを変えることと共に提供されることがある。例えば、チャネル変化なしに、ユーザは、ＭＢＭＳユーザサービスを表示しており、ＭＢＭＳカバレッジから出ることがある。あるいは、ユーザは、ＨＴＴＰベースの配信への切り替えを促すトリックプレイモード行為を開始することがある。別の例において、コンテンツは、チャネルの変化を有するパケット交換ストリーミング（ＰＳＳ）／ＤＡＳＨ上に限り利用可能であり得る。ＨＴＴＰベースの配信からＭＢＭＳダウンロードに切り替えるためのいくつかの関連する切り替えイベントの例は、チャネルを変えることなく提供されることがあり、チャネルを変えることと共に提供されることがある。例えば、チャネル変化なしに、ユーザは、トリックプレイモードから通常のＭＢＭＳユーザサービスに戻ることができる。別の例において、コンテンツは、チャネルの変化を伴うＭＢＭＳ上に限り利用可能であり得る。
【００３０】
図２は、ＩＭＳベースのパケット交換ストリーミングサービス（ＰＳＳ）及びＭＢＭＳの機能的アーキテクチャの一例示的ブロック図を提供する。この例示的実施形態において、アーキテクチャの一部分は、ＵＥなどのモバイル装置にホストされて（hosted）、ピアツーピア（Ｐ２Ｐ）ストリーミング及びダウンロード配信サービスを可能にすることができる。Ｐ２Ｐストリーミング及びダウンロード配信サービスを提供するために、ＵＥは、ＰＳＳサーバ２８２、ＰＳＳアダプタ２９２、ＨＴＴＰサーバ２６０、ＨＴＴＰ／ＳＩＰアダプタ２５０、又はブロードキャスト・マルチキャスト・サービス・センタ（ＢＭＳＣ）ユーザ・プレーン・サブファンクション（ＵＰＦ）（ＢＭＳＣ．ＵＰＦ）２４０のうち１又は複数をホストすることができる。このことは、Ｐ２Ｐストリーミング及びダウンロード配信サービスがＭＢＭＳ及びＤＡＳＨ配信の間で切り替わることを可能にする。
【００３１】
ＵＥ２１０は、ＧＢＡ（ｇｅｎｅｒｉｃ  ｂｏｏｔｓｔｒａｐｐｉｎｇ  ａｒｃｈｉｔｅｃｔｕｒｅ）クライアント、ＩＭＳクライアント、ＰＳＳクライアント及びＭＢＭＳクライアントを含むことができ、これらクライアントは、サービス発見及び選択を実行し、サービス開始、変更及び終了を扱い、かつ／あるいはコンテンツを受信してユーザに提示することができる。
【００３２】
ＵＥは、ＨＴＴＰ／ＳＩＰアダプタをホストすることもできる。ＨＴＴＰ／ＳＩＰアダプタファンクションは、ＳＩＰセッションをＨＴＴＰ到着リクエストに相互に関連付ける。ＵＥは、ＨＴＴＰサーバをホストすることもできる。ＨＴＴＰサーバのファンクションは、３ＧＰＰ  ＴＳ２６．２３４（例えば、バージョン１１．０．０）に記述される。
【００３３】
ＳＣＦ２３０は、サービスロジック及びファンクションを提供して、こうしたサーバロジックの実行をサポートすることができる。ＳＣＦは、セッション開始及びセッション変更の間、サービス認証を提供することができ、このサービス認証には、サービスを許可し又は拒否するためにＰＳＳ及びＭＢＭＳのユーザのサービス加入を確認することを含むことができる。ＳＣＦは、関連するＰＳＳ及びＭＢＭＳメディアファンクションを選択することができる。ＨＴＴＰベースの配信について、ＳＣＦは、プロキシ又はＢ２ＢＵＡ（ｂａｃｋ‐ｔｏ‐ｂａｃｋ  ｕｓｅｒ  ａｇｅｎｔ）の役割を果たすことができる。ＭＢＭＳについて、ＳＣＦは、終端ユーザエージェント（ＵＡ）の役割を果たすことができる。
【００３４】
ＨＴＴＰ／ＳＩＰアダプタ２５０は、ＳＩＰセッションをＨＴＴＰ到着リクエストに相互に関連付けることができる。ＨＴＴＰサーバ２６０は、ＤＡＳＨ形式コンテンツをＨＴＴＰベースの配信のために提供することができる。ＰＣＲＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）２７０モジュールは、ＲＡＮ及びＰＳコアネットワーク２８０における課金とリソースの確立とを制御することができる。ＰＣＲＦは、３ＧＰＰ  ＴＳ２３．２０３（例えば、バージョン１１．０．０）に規定される。
【００３５】
ＳＳＦ２９０モジュールは、利用可能なＰＳＳ（ＨＴＴＰベースのＤＡＳＨ含む）のリストと、ＭＢＭＳユーザサービス及び関連するユーザサービス記述情報とを提供することができる。ＳＳＦモジュールは、クライアントのアイデンティティに対して個人向けにすることができる。ＰＳＳアダプタ２９２は、ＰＳＳサーバの制御を提示するようにＳＩＰとＲＴＳＰとの間で双方向のプロトコル変換を実行することができる。サービス選択ファンクション（ＳＳＦ）モジュールは、利用可能なＰＳＳ（ＨＴＴＰベースのＤＡＳＨを含む）のリストと、ＭＢＭＳユーザサービス及び関連するユーザサービス記述情報を提供することができる。これは、クライアントのアイデンティティに対して個人向けにすることができる。
【００３６】
ＢＭＳＣ．ＵＰＦ２４０は、ブロードキャスト・マルチキャスト・サービス・センタ（ＢＭＳＣ）・ユーザ・プレーン・サブファンクション（ＵＰＦ）を含むことができる。ＢＭＳＣ．ＵＰＦは、ＤＡＳＨ形式コンテンツをＭＢＭＳダウンロードのために提供することができる。ＢＭＳＣ．ＵＰＦ又はＢＭ‐ＳＣ．ＵＰＦは、コンテンツ・プロバイダ／マルチキャスト・ブロードキャスト・ソース２４６と通信し、かつ／あるいはこれを制御することができる。ＢＭ‐ＳＣは、ＭＢＭＳ配信ファンクション２４４を提供することができる。ＵＥは、ＢＭＳＣ．ＵＰＦをホストすることができる。ＢＭＳＣ．ＵＰＦは、すべてのＢＭＳＣユーザ・プレーン・サブファンクションＵＰＦを包含する。図３は、ＢＭＳＣのサブファンクションのアーキテクチャと、ＵＥとＢＭＳＣとの間の関連するインタフェースとを示す。サブファンクションのアーキテクチャは、３ＧＰＰ  ＴＳ２６．３４６（例えば、バージョン１１．０．０）に記述される。
【００３７】
一実施形態において、ＭＢＭＳダウンロード配信は、事前に開始されることがあり、ＵＥは、別のＵＥ（例えば、ホストＵＥ２９６）にホストされたＢＭＳＣ．ＵＰＦからＤＡＳＨ形式コンテンツを受信することができる。ＵＥは、ＭＰＤを取得した後、（ホストＵＥ２９６にホストされた）ＨＴＴＰサーバからメディアセグメントを取り出すことによって、ＨＴＴＰストリーミングを開始することができる。以下で、これをより十分に論じる。
【００３８】
ＭＢＭＳ→ＨＴＴＰ切り替え
図２の例示的なブロック図に示されるとおり、ＩＭＳネットワークにおけるＰ２Ｐ  ＭＢＭＳダウンロードからＤＡＳＨ形式コンテンツのＨＴＴＰベースの配信への切り替えにおいて、複数のステップが実行される。これらのステップの例示的な実施例が、以降の段落に提供され、図２及び図４に示される。上記ステップは、限定的なものではない。ステップの番号付けも、ステップが実行されるにおいて必要とされる順序を提供するものではない。
【００３９】
第１のステップにおいて、ＵＥ２１０などのモバイル装置は、ホストＵＥ２９６から現在のコンテンツ配信セッションにおいてＤＡＳＨコンテンツを含むＭＢＭＳダウンロードを上記モバイル装置が受信する間、セッション開始プロトコル（ＳＩＰ）再招待（re-invitation）をＩＭ  ＣＮサブシステム２２０に発行することができる。ＳＩＰ再招待には、ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージを含むことができる。ＳＩＰ再招待には、同じコンテンツ配信セッションにおいてＨＴＴＰベースの配信を介してＤＡＳＨコンテンツを提供するように、ホストＵＥ２９６上にホストされたＨＴＴＰサーバ２６０のためのリクエストユニフォームリソース識別子（ＵＲＩ）とセッション記述プロトコル（ＳＤＰ）オファーとを含むことができる。
【００４０】
リクエストＵＲＩは、ユーザがアクティブ化することを決定したＨＴＴＰベースの配信セッションに関連する。リクエストＵＲＩは、ユーザパートとドメインパートとから成り得る。ユーザパートは、コンテンツ識別子を含むことができる。コンテンツ識別子は、サービス選択ファンクション（ＳＳＦ）２９０モジュールからのユーザサービス記述情報から読み出される。別法として、コンテンツ識別子は、サービス選択情報から読み出されてもよい。ドメインパートはサービスプロバイダドメイン名であり、これはＳＳＦ２９０から取得することができる。“Ｔｏ”ヘッダは、リクエストＵＲＩの中のものと同じＵＲＩを含むことができる。“Ｆｒｏｍ”ヘッダは、ユーザのパブリックユーザアイデンティティを示すことができる。
【００４１】
ＳＤＦオファーは、ＨＴＴＰストリーミングセッションについて利用可能なメディア能力及びポリシーを含むことができる。ＳＤＦオファーは、ＭＰＤの解析に基づいて、及びＳＩＰオプションによってサービス選択手順の間又は消失パラメータを読み出す手順の間にＳＳＦモジュール２９０から読み出されたパラメータに基づいて、導出されてもよい。ＵＥがＭＢＭＳダウンロードの間にＭＰＤをすでに取り出していることがあるので、ＨＴＴＰサーバに対するＭＰＤのためのリクエストは必須でなくてよい。そうでない場合、ＵＥは、ＭＰＤをダウンロードするために、ＨＴＴＰ  ＧＥＴリクエストをＨＴＴＰサーバに送信してよい。一実施形態において、ＳＤＰオファーは、ポートをゼロに設定された、事前に交渉されたメディア記述を含むことができる。ＳＤＰオファーは、２以上の追加のメディア記述を含むこともでき、すなわち、メディア制御チャネル（すなわち、ＭＰＤ配信チャネル）のための１と、メディア配信チャネル（すなわち、ＨＴＴＰを通じたユニキャストストリームのための配信チャネル）のための１又は複数とを含むことができる。別の実施形態において、メディア配信のためのＳＤＰオファーは、コーデック及びトランスポートプロトコルの観点で、ブロードキャストのために送信された事前のＳＤＰオファーと同一であり得る。ＨＴＴＰベースの配信がトランスミッション制御プロトコル（ＴＣＰ）の上で動き、ＦＬＵＴＥベースのＭＢＭＳダウンロード配信がユーザデータグラムプロトコル（ＵＤＰ）の上で動くので、ＭＢＭＳからＤＡＳＨへの変化は、ＳＤＰにおいて示されることができる。
【００４２】
第２のステップにおいて、ＩＭ  ＣＮサブシステム２２０は、ＳＩＰ再招待をＳＣＦモジュール２３０に転送することができる。
【００４３】
第３のステップにおいて、ＳＩＰ変更リクエストを受信したとき、ＳＣＦ２３０は、現在ブロードキャストされているプログラムがＭＢＭＳ・ツー・ＨＴＴＰ（MBMS  to  HTTP）切り替えサポートを有するかを判定することになる。ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがＵＥ２１０に利用可能でない場合、セッション変更は拒絶され、元のＭＢＭＳセッションが（事前の予約されたリソースと共に）維持される。
【００４４】
ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがＵＥ２１０に利用可能である場合、ＳＣＦ２３０は、Ｂ２ＢＵＡ（ｂａｃｋ‐ｔｏ‐ｂａｃｋ  ｕｓｅｒ  ａｇｅｎｔ）の役割を果たして第３のステップにおいて下記の動きを実行することができる。
【００４５】
ＵＥ２１０からＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥを受信すると、ＳＣＦ２３０は、要求されたコンテンツのためのユーザ権利を確認し、リクエストがＨＴＴＰストリーミングに関すると識別し、ホストＵＥ２９６の中のＨＴＴＰ／ＳＩＰアダプタ２５０を選択し、これに応じて「リクエストＵＲＩ」を変えることによってＨＴＴＰストリーミングサービスを担当するＨＴＴＰ／ＳＩＰアダプタに上記ＳＩＰリクエストを転送することができる。ＨＴＴＰ／ＳＩＰアダプタから３０１又は３０２レスポンスを受信したとき、ＳＣＦは、このメッセージをＵＥ２１０に転送しない。
【００４６】
リクエストＵＲＩが、ユーザパートにコンテンツ識別子を、及びドメインパートにドメイン名を含む場合、ＳＣＦ２３０は、適切なＨＴＴＰ／ＳＩＰアダプタ２５０を選択し、選択されたＰＳＳアダプタ２９２に対するＳＩＰ  ＩＮＶＩＴＥリクエストを生成することができる。このＳＩＰ  ＩＮＶＩＴＥリクエストの“Ｔｏ”ヘッダには、ＵＥから受信したＳＩＰ変更リクエストのリクエストＵＲＩの中のものと同じコンテンツ識別子を含むことができる。
【００４７】
ＳＣＦ２３０は、ＳＩＰ  ＩＮＶＩＴＥリクエストを、ＨＴＴＰストリーミングセッションに利用可能なメディア能力及びポリシーを含むＳＤＰパラメータと共に、ＨＴＴＰ／ＳＩＰアダプタ２５０に送信することができる。ＳＩＰ  ＩＮＶＩＴＥリクエストは、ＭＰＤの解析に基づいて導出されてもよい。一実施形態において、ＳＤＰオファーには、ポートをゼロに設定された事前に交渉されたメディア記述と、２以上の追加のメディア記述とを含むことができ、この２以上の追加のメディア記述は、メディア制御チャネル（すなわち、ＭＰＤ配信チャネル）のための１と、メディア配信チャネル（すなわち、ＨＴＴＰを通じたユニキャストストリームのための配信チャネル）のための１又は複数とである。
【００４８】
それから、ＳＣＦは、ホストＵＥ２９６上で動作するＢＭＳＣ．ＵＰＦとＵＥ２１０との間のＦＬＵＴＥベースのＭＢＭＳダウンロードセッションを破棄する（tear  down）ことができる。
【００４９】
第４のステップにおいて、ＨＴＴＰストリーミングセッション開始リクエストを受信すると、ホストＵＥ２９６上で動作するＨＴＴＰ／ＳＩＰアダプタ２５０は、“Ｔｏ”ヘッダのユーザパートに存在するコンテンツ識別子とＳＤＰの中のメディアパラメータとを調べることができ、リクエストＵＲＩに従ってＨＴＴＰサーバ２６０を選択することができる。ＨＴＴＰサーバは、ＨＴＴＰ／ＳＩＰアダプタと同じホストＵＥ２９６上で動作していてもよく、あるいはそうでなくてもよい。ＨＴＴＰ／ＳＩＰアダプタは、別のホストＵＥ上で動作する別のＨＴＴＰ／ＳＩＰアダプタサーバに上記リクエストをリダイレクトすることに決めてもよい。この場合、ＨＴＴＰ／ＳＩＰアダプタは、コンテンツがこのＨＴＴＰ／ＳＩＰアダプタによって管理されていない場合に３０１レスポンスを返し、他の何らかの理由（例えば、負荷分散）について３０２レスポンスを返すべきである。リダイレクトするＨＴＴＰ／ＳＩＰアダプタは、コンタクトヘッダの中に１又は複数の宛先ＨＴＴＰ／ＳＩＰアダプタアドレスを示すことができる。
【００５０】
第５のステップにおいて、ＨＴＴＰ／ＳＩＰアダプタ２６０は、ＳＤＰアンサーを含むＳＩＰ２００  ＯＫメッセージを、ＳＣＦ２３０に返すことができる。ＳＤＰアンサーは、ＨＴＴＰストリーミングセッションを記述することができる。
【００５１】
第６のステップにおいて、ＳＣＦ２３０は、ＳＩＰ２００  ＯＫをＩＭ  ＣＮサブシステム２２０に転送することができる。ＩＭ  ＣＮサブシステムは、ＴＳ２３．２０３に規定されるとおりＰＣＣ（ｐｏｌｉｃｙ  ｃｈａｒｇｉｎｇ  ａｎｄ  ｃｏｎｔｒｏｌ）アークテクチャのＰＣＲＦ（ｐｏｌｉｃｙ  ｃｈａｒｇｉｎｇ  ａｎｄ  ｒｕｌｅｓ  ｆｕｎｃｔｉｏｎ）２７０と相互作用してＱｏＳ予約を確約し、それからＳＩＰ２００  ＯＫをＵＥ２１０に転送することができる。
【００５２】
プロキシ呼セッション制御ファンクション（Ｐ‐ＣＳＣＦ）は、ＰＣＣアーキテクチャにおけるアプリケーションファンクションとして使用される。ＰＣＲＦ２７０は、ＩＭＳにより開始され及び制御されるＰＳＳ及びＭＢＭＳユーザサービスについて、ＱｏＳのポリシー制御がどのように実行されるかを決めることができる。ＰＣＲＦは、セッション確立の間にＰ‐ＣＳＣＦから受信したＳＤＰを使用して妥当なＱｏＳ承認を算出することができる。適切な既存ベアラが使用されてもよく、あるいは新しい必要とされるベアラが割り当てられてもよい。ネットワークにより開始されるベアラ制御とＵＥ２１０により開始されるベアラ制御とが可能である。最後のＳＤＰを受信したとき、ＵＥは、ネットワークにより開始されたベアラ割り当て手順がすでに進行中でない限り、必要とされるベアラの確立を開始することができ、あるいは、ＵＥは、ネットワークにより開始されたリソース制御を使用するように構成されている。
【００５３】
ステップ７において、ＳＩＰ２００  ＯＫを受信した後、ＵＥ２１０は、マルチキャストチャネルから離れ、ＨＴＴＰを通じてＤＡＳＨ形式コンテンツをダウンロードし始めることができ、したがって、メディアセグメントは、予約されたＱｏＳを使用してＵＥに配信される。
【００５４】
前述の段落において開示された、ＭＢＭＳダウンロードからＤＡＳＨコンテンツのＨＴＴＰベースの配信に切り替える例示的ステップが、図４に表されて一例示的な通信フローを示す。
【００５５】
別の例が、図８においてフローチャートに示されるとおり、マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからＤＡＳＨ（ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）形式コンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールのコンピュータ回路の機能性８００を提供する。さらに、上記機能性は方法として実施されてもよく、あるいは上記機能性はマシン上で命令として実行されてもよく、この命令は、少なくとも１のコンピュータ可読媒体又は少なくとも１の非一時的マシン可読記憶媒体上に含まれる。
【００５６】
図８に示される例において、コンピュータ回路は、ブロック８１０のとおり、ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭ‐ＳＣ．ＵＰＦ）モジュールからコンテンツ配信セッションにおいてＤＡＳＨ形式コンテンツを含むＭＢＭＳダウンロードをモバイル装置が受信している間、このモバイル装置からサービス制御ファンクション（ＳＣＦ）モジュールにおいてセッション開始プロトコル（ＳＩＰ）再招待を受信するように構成されてよい。
【００５７】
コンピュータ回路は、ブロック８２０のとおり、モバイル装置へのＨＴＴＰベースの配信のために上記ホストモバイル装置又は別のホストモバイル装置上で動作するＨＴＴＰサーバを選択するように、ＳＣＦモジュールから上記ホストモバイル装置上で動作するＨＴＴＰ／ＳＩＰアダプタにＳＩＰ招待を送信するように構成されてよい。ブロック８３０のとおり、ＳＩＰ肯定応答（acknowledgement）が、ＳＣＦモジュールにおいてＨＴＴＰ／ＳＩＰアダプタから受信されてよく、コンテンツ配信セッションのためのホストモバイル装置上のＨＴＴＰサーバの選択を示すことができる。ブロック８４０のとおり、ＳＩＰ肯定応答は、モバイル装置に転送されてよく、コンテンツ配信セッションのためのＨＴＴＰサーバへの切り替えを示すことができる。
【００５８】
別の例において、ＳＩＰ再招待は、モバイル装置からインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）コアネットワーク（ＩＭ  ＣＮ）サブシステムにおいてモバイル装置から受信されてもよく、ＩＰ  ＣＮサブシステムは、このＳＩＰ再招待をＳＣＦに転送するように構成される。
【００５９】
別の例において、コンピュータ回路は、サービス品質（ＱＯＳ）予約を可能にするようにＳＩＰ肯定応答をＩＭ  ＣＮサブシステムに送信するようにさらに構成されてもよい。ＩＭ  ＣＮサブシステムは、コンテンツ配信セッションのためのＨＴＴＰサーバへの切り替えを示すＳＩＰ肯定応答をモバイル装置に転送することができる。
【００６０】
別の例において、セッション記述プロトコル（ＳＤＰ）オファーとリクエストＵＲＩとが、ＳＩＰ再招待メッセージに含まれてもよい。
【００６１】
別の例において、コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがモバイル装置においてサポートされるかを判定するようにさらに構成されてもよい。
【００６２】
別の例において、コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがモバイル装置において利用可能であるとき、ホストモバイル装置で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールとモバイル装置との間のＭＢＭＳコンテンツ配信セッションを破棄するように構成されてもよい。
【００６３】
別の例において、ＳＩＰ再招待にはＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージを含むことができ、ＳＩＰ招待にはＳＩＰ  ＩＮＶＩＴＥメッセージを含むことができ、ＳＩＰ肯定応答にはＳＩＰ２００  ＯＫを含むことができる。
【００６４】
ＨＴＴＰ→ＭＢＭＳ切り替え
図２及び図５は、ＨＴＴＰベースの配信からＤＡＳＨコンテンツのＭＢＭＳダウンロードに切り替える例示的な図示を提供する。この例示的な図示において、ＤＡＳＨコンテンツのＨＴＴＰベースの配信は、開始されていることが仮定され、ＵＥ２１０は、ホストＵＥ２９６上で動作するＨＴＴＰサーバ２６０からＨＴＴＰを通じてＤＡＳＨ形式コンテンツを受信している。以降の段落において、図５に示される例示的なステップは、図２において示されたＩＭＳを参照して論じられる。
【００６５】
第１のステップにおいて、ＨＴＴＰベースの配信からＤＡＳＨコンテンツのＭＢＭＳダウンロード受信に切り替えるために、セッション変更リクエストすなわちＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥが、ＵＥ２１０により発行され、ＳＤＰオファーと共にＩＭ  ＣＮサブシステム２２０に送信される。ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥは、選択されたＭＢＭＳダウンロードサービス及びＦＬＵＴＥセッション情報を示すことにも使用される。ＳＤＰオファーは、ＵＥサービス選択手順の間に受信されたパラメータに従って作成されてよい。ＳＤＰオファーは、ＵＥ２１０のメディア能力とＭＢＭＳダウンロードサービスに利用可能な所望される帯域幅とを考慮して作成されてもよい。
【００６６】
一実施形態において、メディア配信のためのＳＤＰオファーは、コーデック及びトランスポートプロトコルの観点で、ＨＴＴＰベースの配信のために提供された事前のＳＤＰオファーと同一であり得る。別の実施形態において、ＭＰＤには、ＨＴＴＰベースの配信からＭＢＭＳダウンロード配信に切り替えるための情報を含むことができ、ＵＥ２１０は、セッション変更リクエスト、例えばＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥを発行するときに、こうした情報を利用してＭＢＭＳダウンロードに切り替えることができる。ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージには、リクエストＵＲＩを含むこともでき、このリクエストＵＲＩは、ＭＢＭＳダウンロードサービスの周知のＰＳＩ（パブリックサービス識別子）であり得る。“Ｔｏ”ヘッダには、リクエストＵＲＩの中のものと同じＵＲＩを含むことができ、“Ｆｒｏｍ”ヘッダは、ユーザのパブリックユーザアイデンティティを示すことができる。
【００６７】
第２のステップにおいて、ＩＭ  ＣＮサブシステム２２０は、ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージをＳＣＦ２３０に転送することができる。
【００６８】
第３のステップにおいて、ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥリクエストを受信すると、ＳＣＦ２３０は、要求されたＭＢＭＳダウンロードサービスのサービス権利をユーザ加入情報に従って確認するように、サービス承認手順を実行することができる。
【００６９】
ＳＩＰ変更リクエストを受信したとき、ＳＣＦ２３０は、現在配信されているコンテンツがＨＴＴＰ・ツー・ＭＢＭＳ（HTTP  to  MBMS）切り替えサポートを有するかを判定することができる。ＨＴＴＰ・ツー・ＭＢＭＳ切り替えがＵＥに利用可能でない場合、セッション変更は拒絶されてよく、元のＨＴＴＰセッションが（事前の予約されたリソースと共に）維持されてよい。ＨＴＴＰ・ツー・ＭＢＭＳ切り替えがＵＥ２１０に利用可能である場合、ＳＣＦは、Ｂ２ＢＵＡの役割を果たし、ホストＵＥ２９６上で動作するＢＭＳＣ．ＵＰＦ２４０とＵＥ２１０との間でＦＬＵＴＥベースのＭＢＭＳダウンロードセッションを確立し、ＳＩＰ  ＢＹＥメッセージをＨＴＴＰ／ＳＩＰアダプタ２５０に送信して上記の間のＳＩＰセッションを終了することができる。
【００７０】
第４のステップにおいて、ＨＴＴＰ／ＳＩＰアダプタ２５０は、それから、ＨＴＴＰサーバ２６０を解放し、ＳＩＰ２００  ＯＫメッセージをＳＣＦ２３０に送信することができる。
【００７１】
第５のステップにおいて、ＳＩＰ２００  ＯＫメッセージがＨＴＴＰアダプタ２５０から受信されると、ＳＣＦ２３０は、ＳＩＰ２００  ＯＫメッセージをＳＤＰアンサーと共にＩＭ  ＣＮサブシステム２２０に送信することができる。
【００７２】
第６のステップにおいて、ＩＭ  ＣＮサブシステム２２０は、ＳＩＰ２００  ＯＫメッセージをＳＤＰアンサーと共にＵＥ２１０に転送することができる。Ｐ‐ＣＳＣＦは、ＰＣＣアーキテクチャにおけるアプリケーションファンクションとして使用されてよい。ＰＣＲＦ２７０は、ＭＢＭＳユーザサービスにより開始され及び制御されるＩＭＳについて、ＱｏＳのポリシー制御がどのように実行されるかを決めることができる。このＭＢＭＳ設定において、一実施形態において、ＰＣＲＦは、具体的なベアラの確立を開始しなくてもよい。
【００７３】
第７のステップにおいて、ＵＥ２１０がＳＩＰ２００  ＯＫレスポンスを受信すると、ＵＥは、対応するＭＢＭＳユーザサービスをＳＤＰに記述されたとおりアクティブ化することができ、具体的に、ＦＬＵＴＥに基づいたＭＢＭＳダウンロードサービスをアクティブ化することができる。ＭＢＭＳダウンロード受信開始は、ＭＢＭＳブロードキャストモードアクティブ化手順又はＭＢＭＳマルチキャストモードアクティブ化手順に対応してもよい。ＵＥは、受信したＳＤＰの中のＦＬＵＴＥセッションパラメータを調べ、これに応じてＭＢＭＳダウンロードデータを受信することができる。ファイル配信テーブル（ＦＤＴ）が利用不可能である場合、ＵＥは、ＦＤＴをＳＤＰアンサーの中のｆｄｔ＿ａｄｄｒｅｓｓ属性に従って入手してもよい。ＦＤＴには、ＦＬＵＴＥセッションにおいて配信されたファイルのコンテンツ記述情報を含むことができる。不完全なダウンロードの場合、ＵＥは、ＳＤＰアンサーの中でｒｅｐａｉｒ‐ｓｅｒｖｅｒ‐ａｄｄｒｅｓｓ属性によって示された修復サーバに向かってファイル修復手順を実行することができる。ファイル修復は、以降の段落でより十分に論じられる。
【００７４】
ＨＴＴＰベースの配信からＤＡＳＨコンテンツのＭＢＭＳダウンロード配信に切り替える例示的な手順は、図５にも表される。
【００７５】
別の例が、図９においてフローチャートに示されるとおり、モバイル装置へのＤＡＳＨ（ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）形式コンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信からマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードに切り替えるように動作可能なホストモバイル装置のコンピュータ回路の機能性９００を提供する。さらに、上記機能性は方法として実施されてもよく、あるいは上記機能性はマシン上で命令として実行されてもよく、この命令は、少なくとも１のコンピュータ可読媒体又は少なくとも１の非一時的マシン可読記憶媒体上に含まれる。
【００７６】
図９に示される例において、コンピュータ回路は、ブロック９１０のとおり、モバイル装置へのＤＡＳＨベースのコンテンツの配信のためのＳＩＰセッションを終了するように、ホストモバイル装置上で動作するＨＴＴＰ／ＳＩＰアダプタにおいてサービス制御ファンクション（ＳＣＦ）からセッション開始プロトコル（ＳＩＰ）終了メッセージを受信するように構成されてよい。ブロック９２０のとおり、ＳＩＰ肯定応答メッセージが、ＳＣＦに送信されてモバイル装置に転送されてよい。ブロック９３０のとおり、ＦＬＵＴＥ（ｆｉｌｅ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｔｒａｎｓｐｏｒｔ）プロトコルベースのＭＢＭＳダウンロードセッションが、ＭＢＭＳダウンロードのためにモバイル装置とホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールとの間で確立されてよい。
【００７７】
別の例において、ＳＩＰ終了にはＳＩＰ  ＢＹＥメッセージを含むことができ、ＳＩＰ肯定応答にはＳＩＰ２００  ＯＫメッセージを含むことができる。
【００７８】
別の例において、ホストモバイル装置は、コンテンツのユニキャスト及びマルチキャスト配信をサポートするエアインタフェースを介してモバイル装置と通信することができる。ホストモバイル装置は、第３世代パートナーシッププロジェクト（３ＧＰＰ）ロングタームエボリューション（ＬＴＥ）標準リリース８、９、１０又は１１と、米国電気電子学会（ＩＥＥＥ）８０２．１６ｍ‐２０１１標準とを含む群から選択されたプロトコルを使用することができる。
【００７９】
別の例において、ホストモバイル装置は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）及びワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のうち少なくとも１に接続するように構成されてよく、モバイル装置には、アンテナ、タッチセンサ式ディスプレイ画面、スピーカ、マイクロフォン、グラフィクスプロセッサ、アプリケーションプロセッサ、内部メモリ、不揮発性メモリポート又はこれらの組み合わせが含まれる。
【００８０】
ＭＢＭＳダウンロード及びファイル修復手順
３ＧＰＰのＭＢＭＳを通じたファイルダウンロード配信サービスは、十分なシンボルを受信していないＵＥがファイルを正しくデコードして追加のシンボルを要求することを可能にするファイル修復機構を提供する。これにより、ユニキャストを通じて特定のＵＥにシンボルを配信するのに必要とされる総計負荷が適度になる場合に、ネットワークが、ユニキャストベアラを通じて特定のＵＥに具体的なシンボルを配信し、ブロードキャストベアラをロードしないようにする。
【００８１】
ファイル修復機構は、ネットワークの中の、ＵＥの修復リクエストにサービス提供するファイル修復サーバに依存する。現在のアーキテクチャは、ＵＥリクエストにサービス提供するように特別に設計された専用サーバを必要とする。このアプローチは、費用がかかることがあり、大規模な配備に合わせてうまく調整されない。
【００８２】
図６に、ＢＭＳＣ６２０に依存するのではなく従来のＨＴＴＰウェブサーバ６３０を使用してファイル修復リクエストを扱うことを可能にする、現在のファイル修復機構に対する強化を示す。ＭＢＭＳダウンロードとＨＴＴＰベースの配信との間で切り替える能力は、強化されたファイル修復手順を可能にする。ＢＭＳＣ６２０により提供されるＭＢＭＳブロードキャストサービスは、セルラーネットワーク６４０を通じて、ファイル又は他のメディア６１０をＵＥ６５０に伝送することができる。ソースシンボルの回復のため、ＵＥは、標準的なＨＴＴＰリクエスト／レスポンスを使用してＨＴＴＰサーバ６３０にコンタクトすることができる。このアプローチは、既存の、スケーラブルな、標準的な及び広く配備されたウェブベースのインフラストラクチャを、修復サービスのために活用する。いくつかの例において、システムは、限られた数のＨＴＴＰリクエストによってソースシンボルの回復を可能にする間に、ＭＢＭＳを通じて修復シンボル伝送をインテリジェントに実行することによって（修復シンボルは、ファイルの消失した部分を実際に再伝送することなくＵＥがファイルを修復できるようにする、ＵＥに送信される冗長なシンボルであり、例えば、ＡＬ‐ＦＥＣスキームにより作り出されるシンボルである）、サーバ複雑度、スケーラビリティ、キャッシュ効率及びＨＴＴＰリクエストオーバヘッド全体像を考慮して、良好なパフォーマンスと複雑度とのトレードオフを実現することができる。オペレータは、特殊化されたファイル修復サーバを使用する必要がなく、コンテンツを配信するために使用されるものと同じウェブサーバを使用することができる。それゆえに、ＢＭＳＣは、もはやファイル修復手順に必要とされず、ファイル修復手順は今やＨＴＴＰサーバによって扱われる。ＨＴＴＰサーバは、コンテンツを記憶する必要があるだけであり、ＦＥＣ符号化のためにリソースを費やす必要がなく、このことは、システムが低い複雑度で良好なキャッシュ及びネットワーク効率を達成できるようにし、低い複雑度は、スケーラビリティ、信頼度、及びネットワーク又はインターネットの中の従来のウェブサーバを使用することによって提供される容易に利用可能なコンテンツをオペレータが活用できるようにする。
【００８３】
一実施形態において、ＩＭＳベースのＰＳＳ及びＭＢＭＳサービスを通じたＭＢＭＳファイル修復手順は、ＭＢＭＳ配信サービスとＨＴＴＰ配信サービスとの間を切り替える能力を活用する。ＭＢＭＳダウンロード配信方法は、ファイルをブロードキャストするＢＭＳＣからＭＢＭＳベアラを通じてＦＬＵＴＥセッションがＵＥによって受信され、その後、（現在の手順であるＭＢＭＳファイル修復サービスのためにＢＭＳＣに接続されたままであるのではなく、）ＵＥがＨＴＴＰウェブサーバへのセッション切り替えを確立してＨＴＴＰを通じてファイルの消失コンポーネントを読み出すように、変更されてよい。
【００８４】
ＩＭＳベースのＰＳＳ及びＭＢＭＳサービスに関する３ＧＰＰ技術仕様書ＴＳ２６．２３７ｖ．１１．０．０は、ＵＥがファイル修復の間にＢＭＳＣに接続されたままであることと、ＢＭＳＣがファイル修復サービスをホストすることとを仮定する。それゆえに、既存の手順は、従来のＨＴＴＰウェブサーバを使用してＵＥにファイル修復サービスを配信することに適用することができない。
【００８５】
以降の段落において、ＭＢＭＳファイル修復のための方法及びシグナリング手順が、ＩＭＳベースのＰＳＳ及びＭＢＭＳサービスの文脈において、従来のＨＴＴＰウェブサーバの使用に基づいて提供される。具体的に、ＭＢＭＳダウンロード配信手順に対する変更が、図２に示されるとおり規定され、したがって、ＦＬＵＴＥセッションが、ファイルをブロードキャストするホストＵＥ２９６上に配置されたＢＭＳＣ．ＵＰＦ２４０から、ＭＢＭＳベアラを通じてＵＥ２１０によって受信され、その後、ＵＥは、同じホストＵＥ又は別のホストＵＥ上に配置されたＨＴＴＰウェブサーバ２６０へのセッション切り替えを確立してＨＴＴＰを通じてファイルの消失コンポーネントを読み出す。
【００８６】
Ｐ２Ｐ通信の使用は、ファイル修復リクエストを扱うためにＢＭＳＣに依存するのではなく従来のＨＴＴＰウェブサーバ６３０を使用することにおいて有意な利点を提供する。具体的に、ＢＭＳＣ．ＵＰＦ２４０、ＨＴＴＰサーバ２６０及びＨＴＴＰ／ＳＩＰアダプタ２５０を１又は複数のホストＵＥ上に置くことで、ユーザ場所の近くに多数のエッジサーバを配置する必要なく回復情報を容易に利用可能にし及び容易にアクセス可能にすることができる。
【００８７】
図２の例示的なブロック図に示されるとおり、Ｐ２Ｐ  ＭＢＭＳダウンロードからファイル修復リクエスト情報のＨＴＴＰベースの配信への切り替えにおいて、複数のステップが実行される。これらのステップの例示的な実施例が、以降の段落に提供され、図２及び図７に示される。上記ステップは、限定的なものではない。ステップの番号付けも、ステップが実行されるにおいて必要とされる順序を提供するものではない。
【００８８】
第１のステップにおいて、ＵＥ２１０は、選択されたＭＢＭＳダウンロードサービスを示す、ＩＭ  ＣＮサブシステム２２０に送信される最初のＳＩＰ  ＩＮＶＩＴＥメッセージを生成する。ＳＤＰオファーが、ＳＩＰ  ＩＮＶＩＴＥメッセージに含まれる。ＩＭ  ＣＮサブシステムは、ＳＩＰ  ＩＮＶＩＴＥメッセージとＳＤＰオファーとをＳＣＦ２３０に転送する。
【００８９】
ＳＩＰ  ＩＮＶＩＴＥリクエストの中のリクエストＵＲＩは、ＭＢＭＳダウンロードサービスの周知のＰＳＩ（パブリックサービス識別子）であってよい。“Ｔｏ”ヘッダには、リクエストＵＲＩの中のものと同じＵＲＩを含むことができる。“Ｆｒｏｍ”ヘッダは、ユーザのパブリックユーザアイデンティティを示すことができる。
【００９０】
ＳＤＰオファーが、リクエストの中に含まれてよい。ＳＤＰオファーは、ＵＥサービス選択手順の間に受信されたパラメータに従って、及びＭＢＭＳダウンロードサービスに利用可能なメディア能力と必要とされる帯域幅とに従ってなされてよい。
【００９１】
第２のステップにおいて、ＳＩＰ  ＩＮＶＩＴＥリクエストを受信すると、ＳＣＦは、ＳＤＰオファーの中のＳＤＰパラメータを調べ、要求されたＭＢＭＳダウンロードサービスのサービス権利をユーザ加入情報に従って確認するようにサービス承認手順を実行することができる。調査成功の場合、ＳＣＦはＳＤＰアンサーを含むＳＩＰ２００  ＯＫで答えることができる。ＳＤＰアンサーには、ｆｄｔ＿ａｄｄｒｅｓｓ、すなわちファイル配信テーブル（ＦＤＴ）のアドレスを示すｕｒｉと、ｒｅｐａｉｒ‐ｓｅｒｖｅｒ‐ａｄｄｒｅｓｓ、すなわち修復サーバのアドレスを示すｕｒｉとを含むことができる。
【００９２】
第３のステップにおいて、ＵＥ２１０がＳＩＰレスポンス（ＳＩＰ２００  ＯＫ）を受信すると、ＵＥは、受信したＳＤＰの中のＦＬＵＴＥセッションパラメータを調べ、これに応じてＭＢＭＳダウンロードデータを受信することができる。ＦＤＴが利用不可能である場合、ＵＥは、ＳＤＰアンサーの中のｆｄｔアドレス属性に従ってＦＤＴを入手してもよい。ＦＤＴは、ＦＬＵＴＥセッションにおいて配信されるファイルのためのコンテンツ記述情報を含む。
【００９３】
第４のステップにおいて、不完全なダウンロードの場合、ＵＥ２１０は、ＳＣＦ２３０からのＳＤＰアンサーの中のｒｅｐａｉｒ‐ｓｅｒｖｅｒ‐ａｄｄｒｅｓｓ属性によって示される修復サーバに向かってファイル修復手順を実行することができる。ＭＢＭＳダウンロードから、ウェブサーバからの修復サービスのＨＴＴＰベースの配信に切り替えるために、セッション開始プロトコル（ＳＩＰ）Ｒｅ‐ＩＮＶＩＴＥが、ＵＥによって発行され、ＩＭ  ＣＮサブシステム２２０に送信されてよい。セッション記述プロトコル（ＳＤＰ）オファーと修復サーバを指すリクエストＵＲＩとが、ファイル修復をアクティブ化するようにＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージに含まれてよい。ＩＭ  ＣＮサブシステムは、ＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージをＳＣＦに転送することができる。
【００９４】
リクエストＵＲＩは、ユーザがアクティブ化したいウェブサーバからのＨＴＴＰベースのファイル修復セッションに関連する。この例において、ウェブサーバは、ホストＵＥ上に配置される。リクエストＵＲＩは、ユーザパートとドメインパートとから成ってよい。ユーザパートは、コンテンツ識別子を含むことができる。コンテンツ識別子は、サービス選択ファンクション（ＳＳＦ）モジュール２９０からのユーザサービス記述情報から読み出されてよい。コンテンツ識別子は、サービス選択情報から読み出されてもよい。ドメインパートは、ＳＳＦから取得されたサービスプロバイダドメイン名である。“Ｔｏ”ヘッダには、修復サーバアドレスＵＲＩを含むことができる。“Ｆｒｏｍ”ヘッダは、ユーザのパブリックユーザアイデンティティを示すことができる。コンテンツ識別子は、サービス選択情報から読み出されてもよい。
【００９５】
ＳＤＰオファーは、ファイル修復セッションに利用可能なメディア能力及びポリシーに従って、及びサービス選択手順の間又は消失パラメータを読み出す手順の間にＳＩＰ  ＯＰＩＴＯＮＳによってＳＳＦから読み出されたパラメータに従って、Ｒｅ‐ＩＮＶＩＴＥリクエストに含まれてよい。
【００９６】
第５のステップにおいて、ＳＩＰ変更リクエストを受信したとき、ＳＣＦ２３０は、現在ブロードキャストされているプログラムがファイル修復目的のためにＭＢＭＳ／ＦＬＵＴＥ・ツー・ＨＴＴＰへの切り替えサポートを有するかを判定することができる。ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがＵＥに利用可能でない場合、セッション変更は拒絶されてよく、元のＭＢＭＳセッションが（事前の予約されたリソースと共に）維持されてよい。
【００９７】
ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがＵＥ２１０に利用可能である場合、ＳＣＦ２３０は、Ｂ２ＢＵＡの役割を果たし、第５のステップにおいて下記の動きを実行することができる。
【００９８】
ＵＥ２１０からＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥを受信すると、ＳＣＦ２３０は、要求されたコンテンツのためのユーザ権利を確認し、リクエストがＭＢＭＳファイル修復手順に関すると識別し、ホストＵＥ２９６上で動作するＨＴＴＰ／ＳＩＰアダプタ２５０を選択し、これに応じて「リクエストＵＲＩ」を変えることによってファイル修復サービスを担当するＨＴＴＰ／ＳＩＰアダプタにＳＩＰ  ＩＮＶＩＴＥリクエストを転送することができる。ＨＴＴＰ／ＳＩＰアダプタから３０１又は３０２レスポンスを受信したとき、ＳＣＦは、このメッセージをＵＥに転送しなくてもよい。
【００９９】
リクエストＵＲＩが、ユーザパートの中にコンテンツ識別子を、及びドメインパートの中にドメイン名を含む場合、ＳＣＦ２３０は、適切なＨＴＴＰ／ＳＩＰアダプタ２５０を選択し、選択されたＨＴＴＰ／ＳＩＰアダプタに対してＳＩＰ  ＩＮＶＩＴＥリクエストを生成することができる。ＳＩＰ  ＩＮＶＩＴＥリクエストの“Ｔｏ”ヘッダには、ＵＥから受信したＳＩＰ変更リクエストのリクエストＵＲＩの中のものと同じコンテンツ識別子を含むことができる。
【０１００】
Ｂ２ＢＵＡの役割を果たすＳＣＦ２３０は、ＳＩＰ  ＩＮＶＩＴＥリクエストをＳＤＰパラメータと共にＨＴＴＰ／ＳＩＰアダプタに送信することができる。ＳＣＦは、ホストＵＥ２９６上で動作するＢＭＳＣ．ＵＰＦ２４０とＵＥ２１０との間のＦＬＵＴＥベースのＭＢＭＳダウンロードセッションを破棄することができる。
【０１０１】
第６のステップにおいて、ＭＢＭＳファイル修復アクティブ化リクエスト（すなわち、ＳＤＰオファー付きのＳＩＰ  Ｉｎｖｉｔｅ）を受信すると、ＨＴＴＰ／ＳＩＰアダプタ２５０は、“Ｔｏ”ヘッダのユーザ部分とＳＤＰの中のメディアパラメータとに存在するコンテンツ識別子を調べることができ、リクエストＵＲＩに従ってＨＴＴＰサーバ２６０を選択することができる。ＨＴＴＰサーバは、ＵＲＩに基づいて、ＢＭＳＣ．ＵＰＦ２４０と同じホストＵＥ又は別のホストＵＥに配置されてよい。ＨＴＴＰ／ＳＩＰアダプタ２５０は、ＵＥ２１０のＩＰアドレスを含むＨＴＴＰ  ＰＯＳＴメッセージをＨＴＴＰサーバに送信することができる。ＨＴＴＰ／ＳＩＰアダプタは、このリクエストを、別のホストＵＥ上で動作する別のＨＴＴＰ／ＳＩＰアダプタサーバにリダイレクトすることに決めてもよい。この場合、ＨＴＴＰ／ＳＩＰアダプタは、コンテンツがこのＨＴＴＰ／ＳＩＰアダプタによって管理されない場合には３０１レスポンスを、又は何らかの他の理由（例えば、負荷分散）について３０２レスポンスを返すことができる。リダイレクトするＨＴＴＰ／ＳＩＰアダプタは、コンタクトヘッダの中に１又は複数の宛先ＨＴＴＰ／ＳＩＰアダプタアドレスを示すことができる。
【０１０２】
第７のステップにおいて、ＨＴＴＰ／ＳＩＰアダプタ２５０から受信されたＨＴＴＰ  ＰＯＳＴメッセージを受信すると、ＨＴＴＰサーバ２６０は、ＨＴＴＰ２００  ＯＫレスポンスでＨＴＴＰ／ＳＩＰアダプタに答える。ＨＴＴＰ／ＳＩＰアダプタは、ＳＤＰアンサーを含むＳＩＰ２００  ＯＫメッセージをＳＣＦ２３０に返すことができる。ＳＤＰアンサーには、要求されたコンテンツファイルのダウンロードＵＲＬを含むＭＢＭＳファイル修復セッションを記述することができる。ストリーミングのために定義されたＳＤＰアンサーとの差は、制御プロトコル（ＲＴＳＰ）に対応するメディアラインが存在しないこと、“ｍ”ラインにおいてストリーミングに代わってＴＣＰトランスポート及びＨＴＴＰベースのダウンロード方法を指し示すこと、並びにＲＴＳＰ  ＵＲＩに代わってＨＴＴＰ  ＵＲＬを指し示すことである。ユーザが選択しているコンテンツが見つからなかった場合、ＨＴＴＰ／ＳＩＰアダプタは、ＳＩＰエラーコード４０４“Ｎｏｔ  Ｆｏｕｎｄ”レスポンスなどの適切なエラーコードで応答することができる。
【０１０３】
第８のステップにおいて、ＳＣＦ２３０は、ＳＩＰ２００  ＯＫメッセージをＩＭ  ＣＮサブシステム２２０に転送することができる。ＩＭ  ＣＮサブシステムは、ＳＩＰ２００  ＯＫをＵＥに転送することができる。
【０１０４】
第９のステップにおいて、ＳＩＰ２００  ＯＫメッセージを受信した後、ＵＥ２１０は、マルチキャストチャネルを離れ、ＳＩＰ２００  ＯＫメッセージから取得されたＵＲＬにＨＴＴＰ  ＧＥＴリクエストを送信することによってＭＢＭＳファイル修復を開始することができる。ＨＴＴＰサーバは、ＵＥに対してＨＴＴＰレスポンスにおいてコンテンツファイルを配信することができる。
【０１０５】
Ｐ２Ｐ通信を使用した、ＭＢＭＳダウンロードから、ホストＵＥ上に配置されたウェブサーバからのファイル修復サービスのＨＴＴＰベースの配信に切り替える例示的な手順が、図７に表される。
【０１０６】
別の例が、図９においてフローチャートに示されるとおり、ファイル修復のためにマルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）ダウンロードからコンテンツのハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースの配信に切り替えるように動作可能なサービス制御ファンクション（ＳＣＦ）モジュールのコンピュータ回路の機能性１０００を提供する。さらに、上記機能性は方法として実施されてもよく、あるいは上記機能性はマシン上で命令として実行されてもよく、この命令は、少なくとも１のコンピュータ可読媒体又は少なくとも１の非一時的マシン可読記憶媒体上に含まれる。
【０１０７】
図１０に示される例において、コンピュータ回路は、ブロック１０１０のとおり、ホストモバイル装置上で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭ‐ＳＣ．ＵＰＦ）モジュールからコンテンツ配信セッションにおいてＤＡＳＨ形式コンテンツを含むＭＢＭＳダウンロードをモバイル装置が受信している間、このモバイル装置からサービス制御ファンクション（ＳＣＦ）モジュールにおいてセッション開始プロトコル（ＳＩＰ）再招待を受信するように構成される。このコンピュータ回路は、ブロック１０２０のとおり、ＳＩＰ再招待がファイル修復手順に関すると判定するようにさらに構成される。ブロック１０３０のとおり、ＳＩＰ招待が、ＳＣＦモジュールからファイル修復手順に使用されるＨＴＴＰ／ＳＩＰアダプタに送信されてよく、ＨＴＴＰ／ＳＩＰアダプタは、上記ホストモバイル装置又は別のホストモバイル装置上で動作するように構成される。ブロック１０４０のとおり、ＳＩＰ肯定応答が、ＳＣＦモジュールにおいてＨＴＴＰ／ＳＩＰアダプタから受信されてよく、要求されたファイル修復コンテンツのコンテンツ配信のための上記ホストモバイル装置又は他のホストモバイル装置上のＨＴＴＰサーバの選択を示すことができる。ブロック１０５０のとおり、ＳＩＰ肯定応答は、モバイル装置に転送されてよく、要求されたファイル修復コンテンツのコンテンツ配信のためのＨＴＴＰサーバへの切り替えを示すことができる。
【０１０８】
別の例において、ＳＩＰ再招待は、モバイル装置からインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）コアネットワーク（ＩＭ  ＣＮ）サブシステムにおいてモバイル装置から受信されてもよく、ＩＰ  ＣＮサブシステムは、このＳＩＰ再招待をＳＣＦに転送するように構成されてもよい。
【０１０９】
別の例において、ＳＩＰ再招待には、セッション記述プロトコル（ＳＤＰ）オファーとリクエスト・ユニフォームリソース識別子（ＵＲＩ）とを含むことができ、ＵＲＩには、コンテンツ識別子と修復サーバアドレスＵＲＩとを含むことができる。
【０１１０】
別の例において、コンピュータ回路は、コンテンツ識別子に関連付けられたコンテンツのためのユーザ権利について確認するようにさらに構成される。
【０１１１】
別の例において、ＳＩＰ招待には、ＳＩＰ再招待の中のものと同じコンテンツ識別子を含む“Ｔｏ”ヘッダを含むことができる。
【０１１２】
別の例において、ＨＴＴＰ／ＳＩＰアダプタは、“Ｔｏ”ヘッダの中のコンテンツ識別子を調べ、修復サーバアドレスＵＲＩに従ってＨＴＴＰサーバを選択し、モバイル装置のインターネットプロトコル（ＩＰ）アドレスを含むＨＴＴＰポストメッセージをＨＴＴＰサーバに送信し、リクエストＵＲＩを別のＨＴＴＰ／ＳＩＰアダプタにリダイレクトするかどうかを判定するように構成されてよい。
【０１１３】
別の例において、ＨＴＴＰサーバは、ＳＩＰ肯定応答をＨＴＴＰ／ＳＩＰアダプタに送信するように構成されてよい。
【０１１４】
別の例において、ＳＩＰ肯定応答には、要求されたファイル修復コンテンツのダウンロードＵＲＬを含むＭＢＭＳファイル修復セッションを記述するＳＤＰアンサーを含むことができる。
【０１１５】
別の例において、コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがモバイル装置においてサポートされるかを判定するようにさらに構成される。
【０１１６】
別の例において、コンピュータ回路は、ＭＢＭＳ・ツー・ＨＴＴＰ切り替えがモバイル装置において利用可能であるとき、ホストモバイル装置で動作するブロードキャスト・マルチキャスト・サービス・センタ・ユーザ・プレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）モジュールとモバイル装置との間のＭＢＭＳコンテンツ配信セッションを破棄するようにさらに構成される。
【０１１７】
別の例において、ＳＩＰ再招待にはＳＩＰ  Ｒｅ‐ＩＮＶＩＴＥメッセージを含むことができ、ＳＩＰ招待にはＳＩＰ  ＩＮＶＩＴＥメッセージを含むことができ、ＳＩＰ肯定応答にはＳＩＰ２００  ＯＫを含むことができる。
【０１１８】
本願例示に使用される特定のエアインタフェース（例えば、ＲＡＮ）特性は、限定的なものではないことに留意されたい。エアインタフェースは、不確かでもよい。関連するネットワークが、説明されたＩＭＳベースのＭＢＭＳダウンロード配信ファンクションをホストすることが可能とされる限り、任意のエアインタフェース又は複数のエアインタフェースの組み合わせが適用可能であり得る。
【０１１９】
図１１は、ユーザ機器（ＵＥ）、移動局（ＭＳ）、モバイルワイヤレス装置、モバイル通信装置、タブレット、ハンドセット、又は他のタイプのワイヤレス装置などの、ワイヤレス装置の一例示的な図示を提供する。ワイヤレス装置には、基地局（ＢＳ）、進化型ノードＢ（ｅＮＢ）、ベースバンドユニット（ＢＢＵ）、リモート無線ヘッド（ＲＲＨ）、リモート無線機器（ＲＲＥ）、中継局（ＲＳ）、無線機器（ＲＥ）、リモート無線ユニット（ＲＲＵ）、中央処理モジュール（ＣＰＭ）又は他のタイプのワイヤレスワイドエリアネットワーク（ＷＷＡＮ）アクセスポイントなどのノード又は伝送局と通信するように構成された１又は複数のアンテナを含んでよい。ワイヤレス装置は、３ＧＰＰ  ＬＴＥ、ＷｉＭＡＸ、ハイスピードパケットアクセス（ＨＳＰＡ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）及びＷｉＦｉを含む少なくとも１のワイヤレス通信標準を使用して通信するように構成されてよい。ワイヤレス装置は、各ワイヤレス通信標準について別個のアンテナを使用して、又は複数のワイヤレス通信標準について共有のアンテナを使用して通信してよい。ワイヤレス装置は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）及び／又はＷＷＡＮにおいて通信してよい。
【０１２０】
図１１は、オーディオ入力とワイヤレス装置からの出力とに使用することができるマイクロフォンと１又は複数のスピーカとの図も提供する。ディスプレイ画面は、液晶ディスプレイ（ＬＣＤ）画面、又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの他のタイプのディスプレイ画面であってよい。ディスプレイ画面は、タッチスクリーンとして構成されてもよい。タッチスクリーンは、容量性、抵抗性又は別のタイプのタッチスクリーンテクノロジーを使用してよい。アプリケーションプロセッサとグラフィクスプロセッサとが、処理及び表示能力を提供するように内部メモリに結合されてよい。不揮発性メモリポートが、データ入力／出力オプションをユーザに提供するように使用されてもよい。不揮発性メモリポートは、ワイヤレス装置のメモリ能力を拡大するように使用されてもよい。キーボードが、追加のユーザ入力を提供するようにワイヤレス装置と一体にされてもよく、あるいはワイヤレス装置にワイヤレスに接続されてもよい。仮想キーボードが、タッチスクリーンを使用して提供されてもよい。
【０１２１】
種々の手法、又はこれらの特定の態様若しくは部分が、フロッピー（登録商標）ディスケット、コンパクトディスク読取専用メモリ（ＣＤ−ＲＯＭ）、ハードドライブ、非一時的コンピュータ可読記憶媒体又は任意の他のマシン可読記憶媒体などの有形媒体に具現化されたプログラムコード（すなわち、命令）の形式をとってよく、このプログラムコードがコンピュータなどのマシンにロードされ、マシンによって実行されると、このマシンは、上記種々の手法を実施する装置になる。回路には、ハードウェア、ファームウェア、プログラムコード、実行可能コード、コンピュータ命令及び／又はソフトウェアを含んでよい。非一時的コンピュータ可読記憶媒体は、信号を含まないコンピュータ可読記憶媒体であってよい。プログラマブルコンピュータ上でのプログラムコード実行の場合、コンピューティング装置は、プロセッサ、プロセッサにより可読な記憶媒体（揮発性及び不揮発性のメモリ及び／又は記憶素子を含む）、少なくとも１の入力装置及び少なくとも１の出力装置を含んでよい。揮発性及び不揮発性のメモリ及び／又は記憶素子は、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラマブル読取専用メモリ（ＥＰＲＯＭ）、フラッシュドライブ、光学ドライブ、磁気ハードドライブ、ソリッドステートドライブ、又は電子データを記憶する他の媒体であってよい。ノード及びワイヤレス装置には、トランシーバモジュール（すなわち、トランシーバ）、カウンタモジュール（すなわち、カウンタ）、処理モジュール（すなわち、プロセッサ）、及び／又はクロックモジュール（すなわち、クロック）若しくはタイマーモジュール（すなわち、タイマー）を含んでもよい。本明細書に説明された種々の手法を実施し又は利用することができる１又は複数のプログラムが、アプリケーションプログラミングインタフェース（ＡＰＩ）、リユーザブル制御などを使用してもよい。こうしたプログラムは、コンピュータシステムとやりとりするように高水準の手続き型又はオブジェクト指向のプログラミング言語で実施されてよい。しかしながら、所望される場合、（１又は複数の）プログラムが、アセンブリ言語又はマシン語で実施されてもよい。いずれの場合でも、言語は、コンパイラ型又はインタプリタ型の言語であってよく、ハードウェア実装と組み合わせられてもよい。
【０１２２】
本仕様書に説明された機能的ユニットの多くが、その実施独立性をより具体的に強調するためにモジュールと呼ばれていることを理解されたい。例えば、モジュールが、カスタム超大規模集積（ＶＬＳＩ）回路若しくはゲートアレイ、ロジックチップなどのオフザシェルフ半導体、トランジスタ又は他の個別のコンポーネントを含むハードウェア回路として実施されてよい。モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジック装置などのプログラマブルハードウェア装置において実施されてもよい。
【０１２３】
モジュールは、様々なタイプのプロセッサによる実行のためにソフトウェアにおいて実施されてもよい。実行可能コードの識別されたモジュールが、例えば、コンピュータ命令の１又は複数の物理的又は論理的ブロックを含んでよく、これらは、例えば、オブジェクト、プロシージャ又はファンクションとして体系化されてよい。それにもかかわらず、識別されたモジュールの実行ファイルは、物理的に一緒に配置される必要はなく、種々の場所に記憶された完全に異なる命令を含んでよく、こうした命令は、論理的に一緒に結合されると、モジュールを構成し、モジュールについて宣言された目的を達成する。
【０１２４】
実際、実行可能コードのモジュールは、単一の命令又は複数の命令であってよく、いくつかの種々のコードセグメントにわたって、種々のプログラムにわたって、及び複数のメモリ装置にわたって分散されてもよい。同様に、オペレーショナルデータが、本明細書においてモジュール内に識別され、例示されることがあり、任意の適切な形式で具現化され、任意の適切なタイプのデータ構造内に体系化されることがある。オペレーショナルデータは、単一のデータセットとして収集されてもよく、あるいは種々の記憶装置にわたることを含め種々の場所にわたって分散されてもよく、少なくとも部分的に、システム又はネットワーク上に単に電子信号として存在してもよい。モジュールは、所望されるファンクションを実行するように動作可能なエージェントを含め、パッシブ又はアクティブであってよい。
【０１２５】
本明細書において「一例」又は「例示的」という言葉は、その例に関連して説明される特定の特徴、構造又は特性が本発明の少なくとも１の実施形態に含まれることを意味する。したがって、本明細書の様々な箇所における「一例において」という語句又は「例示的」という語の出現は、必ずしもすべて同じ実施形態を参照するものではない。
【０１２６】
本明細書において、複数の項目、構造要素、組成要素及び／又は素材が、利便性のために共通のリストにおいて提示されることがある。しかしながら、これらのリストは、リストの各メンバが別個の及び一意のメンバとして個々に識別されるかのようにみなされるべきである。したがって、こうしたリストの個々のメンバは、単にその提示が反対を指し示すことなく共通グループの中にあることに基づいて、同じリストの任意の他のメンバの事実上の均等物とみなされるべきではない。さらに、本発明の様々な実施形態及び例が、本明細書において、その様々なコンポーネントのための代替手段と共に示されることがある。こうした実施形態、例及び代替手段は、互いの事実上の均等物とみなされるべきではなく、本発明の別個の及び自律的な表現とみなされるべきである。
【０１２７】
さらに、説明された特徴、構造又は特性は、１又は複数の実施形態において任意の適切な方法で組み合わせられてよい。下記の説明において、本発明の実施形態の完全な理解を提供するために、レイアウトの例、距離、ネットワーク例などの多数の具体的な詳細が提供される。しかしながら、当業者は、本発明が上記の具体的な詳細のうち１又は複数なしで、あるいは他の方法、コンポーネント、レイアウトなどを用いて実施され得ることを認識するであろう。他の例において、周知の構造、素材又はオペレーションは、本発明の態様を分かりにくくすることを回避するために、詳細には図示又は説明されていない。
【０１２８】
前述の例は、１又は複数の特定の応用における本発明の原理の例示であり、実施の形式、用法及び詳細における多数の変更が発明能力の行使なしに、及び本発明の原理及び概念から逸脱することなしになされ得ることが当業者に明らかであろう。したがって、以下に明記される請求項による場合を除き、本発明は、限定されるものではない。
【０１２９】
関連出願
本出願は、２０１２年９月２８日に申請された米国仮特許出願第６１／７０７７８４号と代理人明細書番号Ｐ４９０８２Ｚとの利益を主張し、本出願においてこれらを参照により援用する。
【図１】
2015530833.tif 000003
【図２】
2015530833.tif 000004
【図３】
2015530833.tif 000005
【図４】
2015530833.tif 000006
【図５】
2015530833.tif 000007
【図６】
2015530833.tif 000008
【図７】
2015530833.tif 000009
【図８】
2015530833.tif 000010
【図９】
2015530833.tif 000011
【図１０】
2015530833.tif 000012
【図１１】
2015530833.tif 000013
【国際調査報告】
2015530833.tif 000014
2015530833.tif 000015