JP5914748B2 - メディアコンテンツのユニキャストと、マルチキャスト／ブロードキャストストリーミングとを組み合わせたＱｏＥ（体感品質）報告 - Google Patents

Description

本発明の実施形態は、無線通信の分野に関し、特に、メディアコンテンツの動的ストリーミングのための体感品質の報告に関する。

ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol：ＨＴＴＰ）ストリーミングはインターネットビデオのマルチメディア配信の形態として広く普及している。既に広まっている、ＨＴＴＰとその基本となる伝送制御プロトコル（transmission control protocol：ＴＣＰ）／インターネットプロコトル（Internet protocol：ＩＰ）との両方を採用することにより、ＨＴＴＰベースの配信がインターネットへの信頼性と開発されたシンプルさを提供する。
また、ネットワークアドレス変換（network address translation：ＮＡＴ）およびファイアウォールトラバーサルの問題を回避することにより、ＨＴＴＰベースの配信は、簡単で楽なストリーミングサービスを可能にする。最後に、ＨＴＴＰベースのストリーミングはまた、特殊なストリーミングサーバの代わりに、標準のＨＴＴＰサーバーおよびキャッシュを利用可能にし、サーバー側で最小限の状態情報によりより良い拡張性を持てるようになる。

GPP TS26.247 V.10.2.0（2012年6月29日）で標準化された、動的適応型ＨＴＴＰストリーミング（Dynamic adaptive streaming over HTTP：ＤＡＳＨ）は、リアルタイムストリーミングプロトコル（real−time streaming protocol：ＲＴＳＰ）ベースの適応型ストリーミングに比べて新技術である。ＤＡＳＨの使用に先立ち、標準化されたプログレッシブダウンロード方法は、標準的なＨＴＴＰウェブサーバからメディア配信のために利用可能であった。ＨＴＴＰベースのプログレッシブダウンロードでは、Ｗｅｂサーバーに対してバイト範囲要求を行うことにより、クライアントはメディアファイルの位置を探し出す（Seek）ことができる。
ＨＴＴＰプログレッシブダウンロードの欠点の大半は、プログレッシブダウンロードが開始された後に、ユーザーがコンテンツを見て停止することを決定した場合（例えば、他のコンテンツへの切り替え）、帯域幅が、無駄になる可能性があることであり、これは、ビットレート（ビット速度）に実際に適応されておらず、ライブメディアサービスをサポートしていない。ＤＡＳＨ技術は、リアルタイムプロトコル（Realtime Transport Protocol：ＲＴＰ）／ＲＴＳＰベースのストリーミング及びＨＴＴＰベースのプログレッシブダウンロードの弱点に対処する。

ＤＡＳＨにおいて、ＭＰＤ（media presentation description）のメタデータファイルは、構造に関する情報と、サーバーに格納されているメディアコンテンツ表現の異なるバージョン（異なるビットレート、フレームレート、解像度、コーデックタイプなどを含む）を提供する。
切り替えのためのメディアプレゼンテーション（表示）・タイムラインへの他の表現との同期表示と、セグメントのマッピングとを確実にするために、ＤＡＳＨは、さらに、セグメント形式、すなわち、初期化の情報とメディアプレイヤーのためのメディアセグメントを含む、形式を特定する。（コンテナフォーマット・プレイヤー及びメディア・タイミング情報を理解するために、メディアプレイヤーは初期化セグメントを見る）。
セグメントの関係を記述したもの、及びどのようにメディアプレゼンテーションを形成するか、についてＭＰＤメタ情報に基づいて、クライアントは、ＨＴＴＰ ＧＥＴまたはＧＥＴ方式の一部を用いてセグメントを要求する。例えば、デバイスの状態の変化やユーザーの好みに対応するために、クライアントは、完全に、ストリーミングセッションを制御する、すなわち、オンタイム要求及びセグメントのシーケンスの円滑な再生を管理することで、潜在的に、ビットレート又は他の属性を調整する。

ＤＡＳＨは、利用可能な帯域幅の変化に応じて、メディアコンテンツの異なるビットレート表現の間を動的に切り替える機能を提供する。したがって、ＤＡＳＨは、変化するネットワークと無線リンク状態、ユーザーの好み（優先度）、およびデバイスの能力（例えば、表示解像度、ＣＰＵ、メモリリソース、等）への迅速な適応を可能にする。このような動的適応は、起動遅延を短くし、リバッファリングのイベントを少なくするなど、よりよい、ユーザー体感品質（Quality of Experience：ＱｏＥ）を提供している。

マルチメディア・ブロードキャスト・マルチキャスト・サービス（Multimedia Broadcast Multicast Services：ＭＢＭＳ）は、第3世代パートナーシップ・プロジェクト（Third Generation Partnership Project：３ＧＰＰ）によって普及したセルラー規格の１つに従って動作するセルラーネットワーク上で利用される、ピーツーエムピー（Point to Multipoint：Ｐ２ＭＰ）システムである。
これ（ＭＢＭＳ）は、ブロードキャスト及びマルチキャスト技術に基づいて、人気コンテンツを多くの受信機へ効率的な配信するように設計されており、オプション機能として最初の３ＧＰＰユニバーサルモバイル遠距離通信システム（ＵＭＴＳ）仕様のリリース６で最初に導入された。そして、これ（ＭＢＭＳ）は、マルチキャストブロードキャスト単一周波数ネットワーク（multicast broadcast single frequency network：ＭＢＳＦＮ）機能などのいくつかの拡張に基づいて、後の３ＧＰＰのリリースで最適化された。
ユーザデータグラムプロトコル（user datagram protocol：ＵＤＰ）に応じた伝送層プロコトル、ストリーミングのためのＲＴＰ、及びファイル配信のための単方向伝送（File Delivery over Unidirectional Transport：ＦＬＵＴＥ）に基づいて、サービス層において、ＭＢＭＳは、マルチメディアコンテンツの配信及びファイルの信頼できるダウンロードの両方のために、配信プロコトルをさらに規定する。ＭＢＭＳは、リリース８以降の３ＧＰＰに対応する、３ＧＰＰベースのロング・ターム・エボリューション（Long Term Evolution：ＬＴＥ）規格開発における、拡張ＭＢＭＳ（ｅＭＢＭＳ）モードとして採用されていた。

ＤＡＳＨフォーマットのコンテンツは、ＭＢＭＳダウンロード配信方法及び／又はＨＴＴＰベースの配信方法の両方を用いてユーザー機器（User Equipment：ＵＥ）に配信することができた。ＭＢＭＳベースＤＡＳＨ配信オプションは、サービスがユニキャストを介して代わりに提供されることがあり、いくつかのサービスエリアでは、利用できない場合がありうる。ＤＡＳＨフォーマットコンテンツがＭＢＭＳで配信される場合には、ＦＬＵＴＥ伝送プロトコルを使用してもよい。
クライアントがＨＴＴＰ／ＴＣＰで配信されるものが見られるように、ＲＦＣ３９２６で規定されたＦＬＵＴＥは、ＭＢＭＳ上のＤＡＳＨセグメントの配信を可能にする。
ＨＴＴＰ−ＵＲＬは、ＦＬＵＴＥの各配信オブジェクトに割り当てられ、ＨＴＴＰ−ＵＲＬは、ＭＰＤにおけるセグメントＵＲＬをマップする。ＭＰＤに含まれるＨＴＴＰ ＵＲＬとＦＬＵＴＥパケットに含まれるＵＲＬ情報との比較に基づいて、ＵＥは、受信されたＤＡＳＨ表現を識別する。

異なるＤＡＳＨ表現はユニキャスト／ＨＴＴＰとＭＢＭＳ／ＦＬＵＴＥ上で利用可能な場合があり、ＤＡＳＨコンテンツの異なるバージョンにアクセスするための切り替えを必要とする。ユニキャスト／ＨＴＴＰとＭＢＭＳ／ＦＬＵＴＥ間を切り替えるケースは、アプリケーション開始時のアクセスの変更だけでなく、アクセス変更を伴うユーザー開始コンテンツ切り替えを含むなど、いくつかのシナリオで発生することがある。
要するに、クライアントは、コンテンツのストリーミング中に、ユニキャストアクセス方式とマルチキャスト／ブロードキャスト方式との間を切り替えることが可能である。さらに、あるＤＡＳＨフォーマット・コンポーネント（表現、セグメントなど）は、マルチキャスト／ブロードキャストで受信されることができ、他のコンポーネントはクライアント側で同期して、ユニキャストで受信されることもできる。

米国公開公報ＵＳ ２００５−００８９０４３ 米国公開公報ＵＳ ２００９−０３１６６１５ 米国公開公報ＵＳ ２００７−０２３７０９８

3GPP TS 26.247 V10.0.0,「UMTS；LTE；Transparent End−to−End Packet−Switched Streaming Service (PSS)；Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP−DASH)(リリース10)」, 2011年6月版P.12−13, P14−16，P46−57. A Ricy K. P. Mok et al. 「QDASH：A QoE−Aware DASH System」’ In：Proceedings of 1−30 the 3rd Multimedia Systems Conference (MMSys’12). 2012年2月22〜24日発表 P12−14.

ＤＡＳＨフォーマットのコンテンツのためのユニキャスト／ＨＴＴＰ及びブロードキャスト／ＦＬＵＴＥアクセス方式のこのような利用可能性を考慮すると、コンテンツストリーミング全体のための継続性と一貫性のあるユーザー体感（Experience）を確保することが重要である。

そこで、本発明は上記事情に鑑み、メディアコンテンツの動的ストリーミングにおいて、コンテンツ全体で継続性と一貫性のあるユーザー体感（Experience）を確保できる装置の提供を目的とする。

上記課題を解決するため、本発明の装置は、メディアサーバーから、１又は複数の無線アクセスネットワーク（ＲＡＮ）コンポーネントを介して、ユニキャストアクセス方式又はマルチキャスト／ブロードキャストアクセス方式による、動的対応型ＨＴＴＰストリーミング（dynamic adaptive streaming over hypertext transfer protocol：ＤＡＳＨ）フォーマットのコンテンツを受信するメディアプレイヤーと、前記メディアプレイヤーへ接続され、複数の体感品質（quality of experience：ＱｏＥ）メトリックを記録し、ＱｏＥ報告サーバーへ前記複数のＱｏＥメトリックを送信するＱｏＥ監視モジュールと、を有しており、
前記複数のＱｏＥメトリックの第一ＱｏＥメトリックは、該第一ＱｏＥメトリックが対応付けられる、前記ユニキャストアクセス方式及び前記マルチキャスト／ブロードキャストアクセス方式を備えるアクセス方式の指示を含んでいる、或いは、前記ユニキャストアクセス方式と前記マルチキャスト／ブロードキャストアクセス方式との間のアクセス切り替えを備えるアクセス切り替えイベントの指示を含んでいる。

本発明の一態様によれば、メディアコンテンツの動的ストリーミングにおいて、コンテンツ全体で継続性と一貫性のあるユーザー体感（Experience）を確保できる。

様々な実施形態に係る通信ネットワークの例示を示す。 様々な実施形態に係る通信ネットワークの例示を示す。 様々な実施形態に係るＱｏＥメトリックのトラックと報告の方法を示す。 様々な実施形態に係るＱｏＥメトリックのトラックと報告の方法を示す。 様々な実施形態に係るＱｏＥ監視方法を示す。 様々な実施形態に係る動的サービスプロビジョニング調整のための方法を示す。 様々な実施形態に係るシステムの例を示す。

本開示の例示的な実施形態として、ビデオコンテンツの動的ストリーミング配信に対して、QoE（体感品質）の報告、及びサービスプロビジョニング調整をするための、方法、システム、コンピューター可読メディア、及び装置を含み、これらに限定されない。

例示的な実施形態のさまざまな態様は、一般的に他の当業者に彼らの作用の本質を伝えるために当業者によって使用される用語を用いて説明する。しかしながら、代替の実施形態が説明された態様の一部だけで実施できることは当業者には明らかであろう。説明は、特定の数、材料、および構成の目的のための例示的な実施形態の完全な理解を提供するために述べられる。しかし、代替の実施形態は特定の詳細なしに実施できることが当業者には明らかである。他の例において、例示的な実施形態を不明瞭にしないために、周知の特徴は省略されているか単純化されている。

また、各種操作は、例示的な実施形態を理解するのに最も役立つ形で、順番に、複数の別個の動作として説明する。しかし、説明の順序は、これらの動作が必ずしも順序に依存していることを意味すると解釈されるべきではない。特に、これらの操作は、提示の順序で実行される必要はない。

明細書において、「ある実施形態では」という語句が繰り返し使用される。このフレーズは、一般に、同じ実施形態を指すものではないが、同じであってもよい。文脈が特に指示しない限り、用語「有する」、「含む」を「持つ」および「備える」は同じ同義で利用する。語句「Ａ及び／又はＢ」とは、（Ａ）、（Ｂ）、または（ＡおよびＢ）を意味する。語句「Ａ／Ｂと、Ａ又はＢ」は、（Ａ）、（Ｂ）、または（Ａ及びＢ）を意味し、「Ａ及び／又はＢ」と同様の意味となる。
語句「少なくともＡ、Ｂ、及びＣのうち１つ」は、（Ａ）、（Ｂ）、（Ｃ）、または（Ａ及びＢ）、（Ａ及びＣ）、（Ｂ及びＣ）、又は（Ａ、Ｂ、及びＣ）を意味する。語句「（Ａ）Ｂ」は、（Ｂ）または（ＡおよびＢ）は、つまり、Ａはオプションであることを意味する。

本明細書で使用される、用語「モジュール」は、一又は複数のソフトウェア又はファームウェアプログラム、組み合わせ論理回路、及び／又は説明した機能を提供する他の適切なコンポーネント、を実行する、特定用途向け集積回路（ＡＳＩＣ）、電子回路、プロセッサ（共有、専用、またはグループ）及び／又はメモリ（共有、専用、またはグループ）の一部である。

図１は、様々な実施形態に応じたネットワーク環境１００を模式的に示す。ネットワーク環境１００は、無線アクセスネットワーク（ＲＡＮ）１０８とワイヤレスに接続するユーザー機器（ＵＥ）１０４を備える。ＲＡＮ１０８は、オーディーエー（Over−the−air（無線通信）：ＯＤＡ）を介してＵＥ１０４と通信する拡張ノードベースステーション（ｅＮＢ）１１２を備えている。ＲＡＮ１０８は、３ＧＰＰ ＬＴＥアドバンスト（ＬＴＥ−Ａ）の一部であってもよく、そして、拡張地上波無線アクセスネットワーク（evolved universal terrestrial radio access network：ＥＵＴＲＡＮ）として参照されてもよい。他の実施形態では、他の無線アクセスネットワーク技術が利用できる。

ＵＥ１０４はＲＡＮ１０８を介してリモートメディアサーバー１１６と接続可能である。
ｅＮＢ１１２はメディアサーバーに直接通信している間、様々な実施形態では、通信が、多くの中間ネットワーク部品（例えば、スイッチ、ルーター、ゲートウェイ等）を通って流れる。例えば、複数の実施形態では、ＲＡＮ１０８は、メディアサーバー１１６の一部であると考えられており、大きなネットワーク、例えば広域ネットワークとともにＲＡＮ１０８へ通信可能に接続する、コアサービスネットワーク（core services network：ＣＳＮ）へ接続できる。

ＵＥ１０４及びメディアサーバー１１６は、アクセス、記憶、通信及びマルチメディアコンテンツの表示を促進するように構成されている、多くの要素（コンポーネント）を備えてもよい。関連する部分として、例えば、ＵＥ１０４は、ＱｏＥ監視モジュール１２０、メディアプレイヤー１２４、及び１又は複数の出力デバイス１２８を備えてもよい。
メディアサーバー１１６は、ＱｏＥ報告モジュール１３２、コンテンツ配信モジュール１３６、及びコンテンツ記憶部１４０を備える。様々な実施形態において、ＱｏＥ報告モジュール１３２は、メディアサーバー１１６の外の異なる場所に存在する。コンテンツ配信モジュール１３６は、例えばＨＴＴＰベース配信のための、ユニキャスト（Unicast：ＵＣ）伝送モジュール１４４と、例えばＭＢＭＳベース配信のための、マルチキャスト／ブロードキャスト（multicast／broadcast：ＭＣ／ＢＣ）伝送モジュール１４８を備える。

また、他の実施形態において、メディアサーバー１１６の１又は複数の部品が互いに離れて配置されてもよい。例えば、図２は、ＵＥ２０４が第一メディアサーバー２１６ａと、第二メディアサーバーと通信可能な実施形態を示す。第一メディアサーバー２１６ａは、ＵＣ伝送モジュール２４４を含むコンテンツ配信モジュール２３６ａを含んでおり、第二メディアサーバー２１６ｂは、ＭＣ／ＢＣ伝送モジュール２４８を含むコンテンツ配信モジュール２３６ｂを含んでいる。
ＵＥ２０４は、ＵＥ１０４が存在する適用範囲に起因して、異なるときに、これらのメディアサーバーへ夫々接続可能できる。また、他の実施形態において、ＵＥ２０４は、同じときに、これらのメディアサーバーへ接続してもよく、そして、例えば、異なるサーバーからのマルチメディアコンテンツの異なる部分を受信してもよい。

簡潔にいうと、図１を再び参照して、コンテンツ配信モジュール１３６はコンテンツ記憶部１４０におけるメディアコンテンツ（例えば、音楽、又はビデオコンテンツ）にアクセスでき、動的適用型ストリーミングプロコトル、例えば動的適応型ＨＴＴＰストリーミング（Dynamic adaptive streaming over HTTP：ＤＡＳＨ）に応じてメディアコンテンツをフォーマット化する。ＤＡＳＨフォーマットのコンテンツは、ＲＡＮ１０８を通ってＵＥ１０４へ配信するために、ＵＣ伝送モジュール１４４又はＭＣ／ＢＣ伝送モジュール１４８のどちらかの伝送モジュールへ提供される。
ＵＥ１０４のメディアプレイヤー１２４は、ユニキャストアクセス方式又はマルチキャスト／ブロードキャストアクセス方式によって配信される、ストリーミングされたコンテンツを受信し、コンテンツをデコードし、ディスプレイやスピーカー等を含みうる出力デバイス１２８へコンテンツを提供する。

ある実施形態において、ユニキャストアクセス方式は、「3GPP TS 26.247」に特化した、ＨＴＴＰベースアクセス方式とすることができる。一方、マルチキャスト／ブロードキャストアクセス方式は、ＭＢＭＳ及び／又は、（2012／6／29）に特定された「3GPP TS26.364V.11.1,0」ベースの、一方向ファイル転送プロコトル（File Delivery over Unidirectional Transport：ＦＬＵＴＥ）とすることができる。

ある実施形態において、メディアサーバー１１６は、いくつかの又は全てのＤＡＳＨフォーマットの配信のために、異なるアクセス方式の間を動的に切り替えることができる。これは、複数のアクセス方式の使用可能度及び／又は優先における違いを基にする。例えば、伝送モジュールが他から離れて配置されている実施形態では、夫々の伝送モジュールに対応付けられる非重複サービスエリアとなる。ストリーミングコンテンツを現在提供する伝送モジュールによってサポートされていない領域へＵＥ１０４が移動した場合、ＵＥ１０４は他の伝送モジュールへ切り替える。
ある実施形態において、両方のアクセス方式が使用可能である場合、１つが他よりも優先される。従って、両方の伝送モジュールが、ＤＡＳＨフォーマットコンテンツをＵＥ１０４へ提供可能である場合、ＭＣ／ＢＣ伝送モジュール１４８は優先されたモジュールとして構成してもよい。

ある実施形態では、異なるＤＡＳＨフォーマット・コンポーネント（例えば、表示、セグメント等）は、異なるアクセス方式を利用可能であり、又は異なるアクセス方式によって優先的に提供される。従って、ある実施形態において、使用可能で優先されたアクセス方式に基づいて、異なるコンポーネントへアクセスさせるように、アクセス方式間の切り替え（「アクセス切り替え」とよぶ）が行われる。
ある実施形態では、ＤＡＳＨフォーマット・コンポーネントの第一セットがＵＣ伝送モジュール１４４によって提供され、ＤＡＳＨフォーマット・コンポーネント部品の第二セットがＭＣ／ＢＣ伝送モジュール１４８によって提供される。この第一セット及び第二セットを受信する、メディアプレイヤー１２４は、出力デバイス１２８でのメディアプレゼンテーション（Presentation，表示）のレンダリング（Rendering）の前にコンテンツを同期できる。

ユニキャストアクセス方式及びマルチキャスト／ブロードキャストアクセス方式の両方、及びこれらの間を切り替える観点から、本発明の複数の実施形態は、コンテンツ・ストリーム・セッション全体のための連続的で一貫性のあるユーザー体験（user experience）を確保する手順を提供する。

従来のＱｏＥ報告は、単一アクセス方式を前提とするものであり、それゆえ、ＵＣ配信とＭＣ／ＢＣ配信との組み合わせでのストリーミングのＱｏＥ劣化を引き起こす特定のイベントを正確に識別することが不十分であった。例えば、アクセス方式が独立して用いられるときに、ＤＡＳＨフォーマットコンテンツが無中断方法で配信される場合であっても、アクセス切り替えは、再生中断の形でのＱｏＥ劣化を引き起こす。
これは、ＭＢＭＳ及びユニキャストＨＴＴＰ｛ブロードキャスト／マルチキャストサービスセンター（ＢＭ−ＣＳ）処理、ＭＢＭＳ前方エラー補正（ＦＥＣ）バッファ、及びＨＴＴＰ要求―対応遅延｝における複数のＤＡＳＨセグメント受信時間の間のオフセットの制限によるものであり、多数のシナリオにおいて、これは無視できない。即ち、ユニキャスト及びブロードキャスト／マルチキャストアクセス方式の数が、無中断方法でＤＡＳＨフォーマットのコンテンツを配するために十分であっても、アクセスを切り替える間に導入される待機時間が動画の中断を引き起こし、ＱｏＥの劣化につながる。
もちろん、これは例示的な一例に過ぎず、アクセス切り替えは、追加の／代替的な例において、エンドユーザーのＱｏＥのネットに衝撃を与えるおそれがある。

ＤＡＳＨクライアント体験へのこの直接的な衝撃により、よりよいクライアント体験の中断のために、本発明の複数の実施形態は、存在するＱｏＥメトリックと一緒にアクセス切り替えイベントの監視をするように提供されており、ユニキャストアクセス方式及びマルチキャスト／ブロードキャストアクセス方式のＤＡＳＨフォーマットコンテンツの配信のためのＱｏＥ劣化の原因を識別する。

なお、ＤＡＳＨフォーマットのコンテンツに対応する実施形態を説明しているが、実施形態の概念は、他のタイプのストリーミングコンテンツにも等しく適用可能である。

ＤＡＳＨフォーマットコンテンツの配信のためのＱｏＥメトリック規定の多数は、ユニキャスト配信とマルチキャスト／ブロードキャスト配信との組み合わせられる間等のアクセス切り替えイベントの間のクライアント体験を、よりよく取り込むように、提供されている。
ここで利用されるものとして、ユニキャストとマルチキャスト／ブロードキャストとを組み合わせた配信手段は、メディアコンテンツの第一部分はユニキャスト方式によって配信され、メディアコンテンツの第二部分はマルチキャスト／ブロードキャストによって配信されることを意味する。
例えば、異なるコンテンツ配信ネットワーク（content delivery network：ＣＤＮ）等の切り替えを備えるいずれかのアクセス切り替えの間のクライアント体験を取り込むのにも、同じＱｏＥメトリックが用いられる。ＣＤＮにおいて、メディアコンテンツが格納され、ストリーミングが初期化されている。ＣＤＮはメディアサーバー１１６を含みうる。ある実施形態では、このようなアクセス切り替えイベントのためのＱｏＥメトリックは、表現切り替えイベント、再生、及び／又はＭＰＤ情報メトリックを含んでもよく、又はこれらに限られない。

ある実施形態において、ＱｏＥ監視モジュール１２０は、製造インターバルの期間において取り替える表現切り替えイベントのリストを記録（Record）する。表現切り替えイベントは第一メディアコンテンツ表現から第二メディアコンテンツ表現への切り替えに対応する。
各表現切り替えイベントは、切り替え先の表現（switch−to representation）、切り替えイベントのリアルタイム（ウォールクロックタイム）、切り替えられた表現の外（全てのメディアコンポーネントの外）からプレイされる最も早いメディアサンプルのメディアタイム、レベル識別サブ表現（切り替えられた表現のレベル等）、及び切り替えられた表現又はサブ表現を受信することによるアクセス方式、等を示す属性を備えている。
ある実施形態では、アクセス方式はユニキャスト（ＨＴＴＰ等）又はマルチキャスト／ブロードキャスト（ＭＢＭＳ等）でありうる。

表１は、ある実施形態における表現切り替えイベントを示す。

表１に含まれる、「切り替え先の表現」に対応する「アクセス方式」の属性は、関連するＤＡＳＨフォーマットコンテンツを伝送するのに用いられるアクセスメカニズムの識別を可能にする。
異なるＤＡＳＨ表現（又はサブ表現）の間をＵＥ（ユーザー機器）がどのように切り替えるか、によってだけではなく、例えばＭＢＭＳ変換がなくなり及び同じサービスの代替受信がユニキャストＨＴＴＰにより可能になるというイベントに対応して、どのようにアクセス方式（例えばＨＴＴＰ及びＭＢＭＳ／ＦＬＵＴＥ）をＵＥが切り替えるか、によっても、ＵＥ適応行動を解明する。
このような設定において、「アクセス方式」属性は、選択したＤＡＳＨ表現とともに、このようなアクセス切り替えイベントのログすることを容易にすることができる。オブジェクトの喪失又はイベントのリバッファ等の他のＱｏＥメトリックと組み合わせをするときは、サービスプロバイダーは、アクセス切り替えイベントの間のＱｏＥ行動及びＤＡＳＨ配信のためのクライアント体験を詳細に識別することができる。

図３は、ある実施形態に係る追跡（Tracking）と報告（Reporting）の方法３００を示す。方法３００はＵＥのＱｏＥ監視モジュール、例えば、ＵＥ１０４のＱｏＥ監視モジュール１２０等において実施されうる。ある実施形態では、ＵＥは、実施時、ＵＥ又はＱｏＥ監視モジュールに方法３００を実行させる命令を含む、コンピューター可読の１又は複数のメディアを備えることができる、或いはこのコンピューター可読メディアにアクセスすることができる。

方法はステップＳ３０４において、個々のＤＡＳＨ表現へのアクセス方式を追跡する。

方法はステップＳ３０８において、表現切り替えイベントを検知する。表現切り替えイベントは、第一ＤＡＳＨ表現から受信するメディアプレイヤーから第二ＤＡＳＨ表現からの受信するメディアプレイヤーへ切り替える。

Ｓ３０８にて表現切り替えイベントを検知した後、方法はＳ３１２において、表現切り替えイベントメトリックを演算する。ある実施形態において、表現切り替えイベントメトリックを演算することは、切り替えられた表現のアクセス方式を記録することを含む。ある実施形態において、切り替えイベントの他の要素は表現切り替えイベントメトリックにおいて記録される。

方法はステップＳ３１６において、演算された表現切り替えイベントメトリックを報告する。演算された表現切り替えイベントメトリックを報告することは、メトリックをＱｏＥ報告モジュール、例えばメディアサーバー１１６のＱｏＥ報告モジュール１３２へ送信することで、実行される。

ある実施形態において、ＱｏＥ監視モジュール１２０は測定インターバルのプレイリストを記録する。ＤＡＳＨフォーマットコンテンツのデコードされたサンプルは、一般的に、各特定のプレゼンテーション時間系列、又はその特定のプレゼンテーション時間系列においてレンダリングされる。
そして、特定の表示時間における夫々サンプルがある特定の精度レベル（例えば±10 ms）で存在するように、単一の表現のサンプルが連続的にレンダリングされた時間帯のリストから、情報フローのコンパクトな表現は構築することができる。
特定のメディアタイムにおいて再生を開始させるユーザーアクション（「プレイ（Play）」、「シーク（Seek）」または「再開（Resume）」アクション等）によって、このような連続配信の期間系列は開始され、ユーザーアクション、コンテンツの終了、または修復不能な障害が発生して再生が停止されるまで、続けられる。

ＱｏＥ監視モジュール１２０によって記録されるプレイリストメトリックは、測定インターバルにおける再生期間のリストのためのプレイリスト要素をログするのに利用され、各再生期間はユーザーアクションと、その直後のユーザーアクション、再生の停止、又は再生の停止の不具合、のいずれかアクション等との間の時間期間である。
各再生期間において、ＱｏＥ監視モジュール１２０は、様々なプレイリスト要素、例えばレンダリングされた表現、（メディア時間における）そのレンダリング時間及び持続期間、ノーマル再生速度に対する再生速度（早送りや巻き戻しなどのトリックモードを追跡する等）、及び、この表現の連続再生が中断された理由等、を測定し、報告する。

表２はある実施形態に係るプレイリストメトリックを示す。

プレイリストメトリックは、「停止理由」パラメータによって、与えられた表現の連続表示の中断を引き起こすイベントを取り込むので、「ユニキャストからブロードキャスト（及び／又はマルチキャスト）への切り替え」及び「ブロードキャスト（及び／又はマルチキャスト）からユニキャストへの切り替え」に基づくアクセス切り替えイベントを含む列挙は、関連するＤＡＳＨフォーマットコンテンツの伝送に用いられるアクセス方式の識別を可能にする。
そして、いずれかに対応付けられたリバッファリングイベント（又はＱｏＥの他の形状）の背後にある可能性のある理由を理解する手助けとなり、これにより、プレイリストメトリックによってさらに取り込める。
再び、このような修正によって、どのようにクライアント体験がアクセス切り替えイベントによって衝撃をうけているか、及びどのようにメディアプレイヤー１２４が異なるＤＡＳＨ表現及びアクセス方式で動作するか、より正確に理解することが可能になる。
最後に、「異なるＣＤＮへの切り替え」の列挙は、幅広いコンテンツにおけるアクセス方式の変化のクライアント体験を取り込むことを含んでいてもよい。

図４は、ある実施形態における追跡及び報告の方法４００を示す。方法４００はＵＥのＱｏＥモジュール、例えば、ＵＥ１０４のＱｏＥ監視モジュール１２０等において実施されうる。ある実施形態では、ＵＥは、実施時、ＵＥ又はＱｏＥ監視モジュールに方法４００を実行させる命令を含む、コンピューター可読の１又は複数のメディアを備えることができる、或いはこのコンピューター可読メディアにアクセスすることができる。

方法はステップＳ４０４において、プレイリスト要素を追跡する。追跡される要素は、例えば、表２で表した要素である。

方法はＳ４０８において、アクセス切り替えイベントを検知する。上述のように、アクセス切り替えイベントは、例えば、ユニキャストからブロードバンド（及び／又はマルチキャスト）アクセス方式への切り替えと、ブロードバンド（及び／又はマルチキャスト）からユニキャストアクセス方式への切り替え、及び異なるＣＤＮ（コンテンツ配信ネットワーク）間の切り替え、を実行する。

Ｓ４０８でのアクセス切り替えイベントの検知により、Ｓ４１２にて、方法４００はプレイリストメトリックを演算する。ある実施形態では、プレイリストメトリックは、切り替え先のアクセス方式の追跡プレイリスト要素を記録することを含みうる。

方法はＳ４１６において、演算されたプレイリストメトリックを報告する。演算されたプレイリストメトリックを報告することは、ＱｏＥ報告モジュール、例えばメディアサーバー１１６のＱｏＥ報告モジュール１３２へメトリックを送信することで実施される。

ある実施形態において、ＱｏＥ監視モジュール１２０はＭＰＤからの表現情報を記録する。これによって、ＱｏＥ監視モジュールの報告の際、ＭＰＤへ直接アクセスしないサーバーが、利用されたメディア特性を理解することが可能である。
ＵＥ１０４が、ＭＰＤ情報が未だに報告されていない表現への参照を含む他の品質メトリック報告を送信するときはいつでも、ＱｏＥ監視モジュール１２０はＭＰＤ情報メトリックを報告する。
このコンテンツにおいて、表現が利用可能であることによって、アクセス方式の情報を含むことは有益である。これは、＠伝送ＩＤ属性の専属であり（@transportID）、利用可能なアクセス方式の情報を運んで、メディアコンテンツ表現を受信する。

表３は、ある実施形態に係るＱｏＥ報告のためのＭＰＤ情報メトリックを示す。

図５は、ある実施形態に係るＱｏＥ監視の方法５００を示す。方法５００はＵＥのＱｏＥ監視モジュール、例えば、ＵＥ１０４のＱｏＥ監視モジュール１２０等において実施されうる。ある実施形態において、ＵＥは、実施時、ＵＥ又はＱｏＥ監視モジュールに方法５００を実行させる命令を含む、コンピューター可読の１又は複数のメディアを備えることができる、或いはこのコンピューター可読メディアにアクセスすることができる。

Ｓ５０４において、ＱｏＥ監視モジュールは、メディアコンテンツ、例えばＤＡＳＨフォーマットのコンテンツのダウンロード及び再生を監視する。ダウンロード及び再生は、メディアプレイヤー、例えばメディアプレイヤー１２４によって実施される。ダウンロード及び再生を監視しているとき、ＱｏＥ報告モジュールはたくさんのＱｏＥメトリックを記録する。これらのメトリックは、ユニキャストアクセス方式によって配信されるメディアコンポーネントのための、ＨＴＴＰ要求／応答トランザクション（transactions）、表現切り替えイベント、ユニキャストアクセス方式に対応付けられる平均処理量、マルチキャスト／ブロードキャストアクセス方式に対応付けられる平均処理量、初期再生遅延（initial playout delay）、バッファ占有レベル、プレイリスト、及びＭＰＤ情報等を含んでもよく、またこれらに限られない。

Ｓ５０８において、ＱｏＥ報告モジュールは、１又は複数のＱｏＥメトリックとともに、アクセス方式又はアクセス切り替えイベントを対応付ける。例えば、アクセス方式は、上述の表現切り替えイベント、プレイリスト、及びＭＰＤ情報に対して記録される。

Ｓ５１２において、ＱｏＥ監視モジュールは、対応付けられたアクセス方式及び／又はアクセスイベント切り替えの指示を含むＱｏＥメトリックを、ＱｏＥ監視モジュール、例えばメディアサーバー１１６のＱｏＥ報告モジュール１３２、へ送信する。
ある実施形態において、ＱｏＥメトリックは拡張マークアップ言語（extensible markup language：ＸＭＬ）文書として、ＱｏＥ報告フォーマットで送信される。ＱｏＥ監視モジュールは、その中にＸＭＬフォーマットのメタデータ本体を運ぶＨＴＴＰ−ＰＯＳＴ 要求シグナリング（ＲＦＣ２６１６）を用いてＱｏＥ報告をメディアサーバーへ送る。

様々な実施形態において、ＱｏＥメトリックの送信は周期的に、又はイベント駆動型報告で、実施されうる。イベント駆動型報告は、所定の閾値よりも下がった又は他のトリガー（Trigger：きっかけ）で、１又は複数のＱｏＥメトリックにより引き起こされる。

ある実施形態において、ＱｏＥ報告は、ＵＥ１０４またはメディアサーバー１１６の開始により、作動される／引き起こすことができる。ＱｏＥ報告は、メディアサーバー１１６又は他のサーバーがＱｏＥ監視モジュールへ送信することが、報告トリガーとなる。
報告トリガーは、例えば、ＭＰＤファイルにおいて、例えばメトリック要素、オープンメディア・アライアンスー装置マネジメント(Open Mobile Alliance−Device Management：ＯＭＡ−ＤＭ）ＱｏＥ監視マネジメントオブジェクト、セッション説明プロコトル（session description protocol：ＳＤＰ）メッセージとなる。

図６は、ある実施形態に係る動的サービスプロビジョニング調整の方法６００を示す。
方法６００は、メディアサーバーのＱｏＥ報告モジュール、例えば、メディアサーバー１１６のＱｏＥ報告モジュール１３２等において実施されうる。ある実施形態において、メディアサーバーは、実施時、メディアサーバー又はＱｏＥ監視モジュールに方法６００を実行させる命令を含む、コンピューター可読の１又は複数のメディアを備えることができる、或いはこのコンピューター可読メディアにアクセスすることができる。

Ｓ６０４において、ＱｏＥ報告モジュールは複数のＱｏＥメトリックを受信する。ＱｏＥメトリックはユニキャスト及び／又はマルチキャスト／ブロードキャストアクセス方式によって配信されたメディアコンテンツのダウンロード及び再生に対応付けられる。
上述のように、受信したＱｏＥメトリックは、ユニキャストによって配信されるメディアコンポーネントのためのＨＴＴＰ要求／応答トランザクション、表現切り替えイベント、ユニキャストアクセスに対応付けられる平均処理能力、マルチキャスト／ブロードキャストに対応付けられる平均処理能力、初期再生遅延、バッファ占有レベル、プレイリスト、ＭＰＤ情報等、を含み、これらに限られない。少なくとも１つの受信されたＱｏＥメトリックは１つのアクセス方式に対応付けられる。

Ｓ６０８において、ＱｏＥ報告モジュールはサービスプロビジョニング調整を初期化する。ある実施形態において、サービスプロビジョニング調整の初期化は、受信した１又は複数のメトリックに基づく。例えば、クライアントは、第一アクセス方式によって表現が配信されたときに、ＤＡＳＨメディアコンテンツの特定の表現から定期的に切り替えることを判断される場合がある。従って、ＱｏＥ報告モジュールは第二アクセス方式による配信の方へ表現が偏ることがある。

サービスプロビジョニング調整は、ＤＡＳＨフォーマットコンテンツを第一のフォーマットから第二のフォーマットへトランスコーディングすること、アクセス方式を第一アクセス方式から第二アクセス方式へ変更すること、ＤＡＳＨフォーマットの配信に利用される故障検出及び補正方式を変更すること、及びユニキャスト又はマルチキャスト／ブロードキャストアクセス方式によるＤＡＳＨフォーマットの配信の監視のための無線リソースを再割り当てすることを、含み、これらに限られない。

ここで説明するＱｏＥ監視及びフィードバックは、故障の検出及びデバッグに有利なので、ストリームパフォーマンスの監視を行い、インテリジェントクライアント適応（装置製造者に有利）が可能になり、さらにＱｏＥアウェア（ＱｏＥ−ａｗａｒｅ）ネットワークへの適応及びサービスプロビジョニング調整（ネットワークオペレーター及びサービスプロバイダーに有利）を可能にする。

ここで説明するＵＥ１０４及びメディアサーバー１１６は、所望な構成のいずれか適切なハードウェア及び／又はソフトウェアを用いるシステムで実施される。
図７は、例えば一例として、システム７００は、１又は複数のプロセッサ７０４、該１又は複数のプロセッサ７０４に接続されるシステム制御ロジック７０８、該システムロジック７０８に接続されるシステムメモリ７１２、前記システム制御ロジック７０８に接続される不揮発性メモリ（ＮＶＭ）／ストレージ７１６、前記システム制御ロジック７０８に接続されるネットワークインターフェース７２０、前記システム制御ロジック７０８に接続される入出力（Ｉ／Ｏ）デバイス７３２を備える。

１又は複数のプロセッサ７０４は１又は複数のシングルコア又は、マルチコアプロセッサを備えることができる。プロセッサ７０４は一般的な目的のプロセッサと専用プロセッサ（グラフィックプロセッサ、アプリケーションプロセッサ、ベースバンドプロセッサ等）との組み合わせでもよい。

ある実施形態に係るシステム制御ロジック７０８は、システム制御ロジック７０８と通信する、少なくとも１つのプロセッサ７０４及び／又はいずれか適切な装置又は適切なコンポーネントに対して、適切なインターフェースのために適切なインターフェースコントローラを含みうる。

ある実施形態のシステム制御ロジック７０８は、インターフェースをシステムメモリ７１２へ提供する１又は複数のメモリコントローラを含みうる。システムメモリ７１２は、例えばＱｏＥロジック７２４等のデータ及び命令の読み込み（Load）及び格納へ利用されうる。ある実施形態のシステムメモリ７１２は、適切な揮発性メモリ、例えば適切なダイナミックランダムアクセスメモリ（ＤＲＡＭ）等を備える。

ＮＶＭ／ストレージ７１６は、ＱｏＥロジック７２４等のデータ及び／又は命令の記録に用いる、有形の、一時的ではない、コンピューター可読の１又は複数のメディアを含んでもよい。ＮＶＭ／ストレージ７１６は、例えばフラッシュメモリ等の不揮発性メモリ、及び／又は、例えば、１又は複数のハードディスク（ＨＤＤ）、１又は複数のコンパクトデスク（ＣＤ）ドライブ、及び／又はデジタル多用途ディスク（ＤＶＤ）等のいずれか適切な不揮発性記憶装置を含んでもよい。

ＮＶＭ／ストレージ７１６は、システム７００がインストールされている、或いはシステム７００がアクセス可能であるデバイスの物理的に一部又は全部である記憶リソースを含むことができる。例えば、ＮＶＭ／ストレージ７１６は、ネットワークインターフェース７２０を介するネットワークによって、及び／又は入出力（Ｉ／Ｏ）デバイス７３２によって、アクセスすることができる。

ＱｏＥロジック７２４は、システム７００に、上述のようなＱｏＥ監視、ＱｏＥ報告、及び／又はサービスプロビジョニング調整をさせるように、１又は複数のプロセッサ７０４によって実行させる、命令を含むことができる。様々な実施形態において、ＱｏＥロジック７２４は、システム７００の追加の／代替の要素として配置されるハードウェア、ソフトウェア、及び／又はフィルムウェア・コンポーネントをさらに備えてもよい。

ネットワークインターフェース７２０は、システム７００が１又は複数のネットワークで、他の適切な装置と通信するために、無線インターフェースを提供するトランシーバー７２２を含む。
様々な実施形態において、トランシーバー７２２はシステム７００の他の構成要素（コンポーネント）と集積してもよい。例えば、トランシーバー７２２はプロセッサ（複数のプロセッサ）７０４のおける１つのプロセッサ、システムメモリ７１２の１つのメモリ、及びＮＶＭ／ストレージ７１６の１つのＮＶＭストレージを含んでもよい。
ネットワークインターフェース７２０は、いずれか適切なハードウェア及び／又はフィルムウェアを含んでもよい。ネットワークインターフェース７２０は、複数の入力、複数の出力インターフェースを提供する複数のアンテナを含んでもよい。ある実施形態のネットワークインターフェース７２０は、例えば配線ネットワークアダプター、ワイヤレスネットワークアダプター、電話モデム、及び／又はワイヤレスモデムを含んでもよい。

ある実施形態では、少なくとも1つのプロセッサ７０４は、システム制御ロジック７０８の一又は複数のコントローラのロジックとともにパッケージ化することができる。さらに、ある実施形態では、少なくとも１つのプロセッサ７０４は、システム制御ロジック７０８の一つ以上のコントローラのためのロジックと一緒にパッケージすることで、システムインパケージ（ＳＩＰ）を形成する。
また、ある実施形態では、少なくとも１つのプロセッサ７０４は、システム制御ロジック７０８の一つ以上のコントローラのためのロジックと一緒に同じダイ上に集積することができる。さらに、ある実施形態では、少なくとも１つのプロセッサ７０４は、システム制御ロジック７０８の一つ以上のコントローラのためのロジックと一緒に同じダイ上に集積することで、システムオンチップ（ＳｏＰ）を形成してもよい。

様々な実施形態において、入出力デバイス７３２は、システムにおけるユーザーインタラクション（interaction：相互作用）を可能にするために設計されたユーザーインターフェース、システムにおける周辺要素（コンポーネント）インタラクションを可能にするために設計された周辺要素（コンポーネント）インターフェース、および／または、システム７００に関連する環境条件及び又は位置情報を決定するために設計されたセンサを備えてもよい。

様々な実施形態において、ユーザーインターフェースは、ディスプレイ（液晶ディスプレイ、タッチスクリーンディスプレイ等）、スピーカー、マイク、１又は複数のカメラ（スチールカメラ及び／又はビデオカメラ）、フラッシュライト（発光ダイオードフラッシュ）及びキーボード、を含んでいてもよく、また、これらに限られない。

様々な実施形態において、周辺コンポーネントインターフェースは不揮発性メモリ・ポート、ユニバーサルシリアルバス（ＵＳＢ）ポート、オーディオジャック、及び電源インターフェースを含んでいてもよく、またこれに限られない。

様々な実施形態において、センサは、ジャイロセンサ、加速度計、近接センサ、環境光センサ、測位ユニットを含んでもよく、また、これらに限られない。
測位ユニットは、例えば、全地球測位システム（global positioning system：ＧＰＳ）サテライト等の測位ネットワークのコンポーネントと通信可能である、ネットワークインターフェース７２０の一部である、又はネットワークインターフェース７２０と相互に影響しあう。

様々な実施形態において、システム７００は、ラップトップコンピューター、タブレットコンピュータ―装置、ネットブック、スマートフォン等の携帯コンピューター装置であってもよく、またこれらに限られない。
様々な実施形態において、システム７００は、多少の構成要素（コンポ―ネット）及び又はアーキテクチャ―を備えてもよい。

複数の目的のための特定の実施形態が図示および説明されているが、本開示の範囲から逸脱することなく、代わりの計算および／または等価な実施形態または実装の多種多様な目的のために達成するためものものを、示された実施形態の代わりと説明することができる。本出願は、本明細書で説明した実施形態の任意の適応または変形をカバーすることを意図している。したがって、明らかに、本明細書に記載の実施形態は単に特許請求の範囲及びその均等物によってのみ限定されるものである。

１００ ネットワーク環境
１０４，２０４ ユーザー機器（ＵＥ）
１０８ 無線アクセスネットワーク（ＲＡＮ）
１１２ 拡張ノードベースステーション（ｅＮＢ）
１１６，２１６ａ，２１６ｂ メディアサーバー
１２０ ＱｏＥ監視モジュール
１２４ メディアプレイヤー
１２８ 出力デバイス
１３２ ＱｏＥ報告モジュール
１３６，２３６ａ，２３６ｂ コンテンツ配信モジュール
１４０ コンテンツ記憶部
１４４，２４４ ユニキャスト伝送モジュール（ＵＣ伝送モジュール）
１４８，２４８ マルチキャスト／ブロードキャスト伝送モジュール（ＭＣ／ＢＣ伝送モジュール）
７００ システム
７０４ プロセッサ
７０８ システム制御ロジック
７１２ システムメモリ
７１６ ＮＶＭ／ストレージ
７２０ ネットワークインターフェース
７２２ トランシーバー
７２４ ＱｏＥロジック
７３２ 入出力（Ｉ／Ｏ）デバイス

Claims (31)

1. メディアサーバーから、１又は複数の無線アクセスネットワーク（ＲＡＮ）コンポーネントを介して、ユニキャストアクセス方式又はマルチキャスト／ブロードキャストアクセス方式による、動的対応型ＨＴＴＰストリーミング（dynamic adaptive streaming over hypertext transfer protocol：ＤＡＳＨ）フォーマットのコンテンツを受信するメディアプレイヤーと、
   前記メディアプレイヤーへ接続され、複数のＱｏＥ（quality of experience）メトリックを記録し、ＱｏＥ報告サーバーへ前記複数のＱｏＥメトリックを送信するＱｏＥ監視モジュールと、を有しており、
   前記複数のＱｏＥメトリックの第一ＱｏＥメトリックは、該第一ＱｏＥメトリックが対応付けられる、前記ユニキャストアクセス方式及び前記マルチキャスト／ブロードキャストアクセス方式を備えるアクセス方式の指示を含んでいる、或いは、前記ユニキャストアクセス方式と前記マルチキャスト／ブロードキャストアクセス方式との間のアクセス切り替えを備えるアクセス切り替えイベントの指示を含んでいる、
   装置。
2. 前記第一ＱｏＥメトリックは、第一メディアコンテンツ表現を受信することから、第二メディアコンテンツ表現を受信することへの切り替えに対応する表現切り替えを基にした、表現切り替えイベントメトリックを含む、
   請求項１記載の装置。
3. 前記表現切り替えイベントメトリックは、前記アクセス方式を示すアクセス方式属性を含む、
   請求項２記載の装置。
4. 前記第一ＱｏＥメトリックは、ユニキャストアクセス方式からマルチキャスト／ブロードキャストアクセス方式へ、またはマルチキャスト／ブロードキャストアクセス方式からユニキャストアクセス方式への、アクセス切り替えを備える、前記アクセス切り替えイベントの指示を含む、
   請求項１に記載の装置。
5. 前記第一ＱｏＥメトリックは、測定インターバルにおいて、１又は複数の再生期間のためのプレイリスト要素のリストをログするのに利用されるプレイリストメトリックを含む、
   請求項１又は４記載の装置。
6. 前記ＱｏＥ監視モジュールは、
   複数のプレイリスト要素をトラックし、
   ユニキャストアクセス方式からマルチキャスト／ブロードキャストアクセス方式へ、或いは、マルチキャスト／ブロードキャストアクセス方式からユニキャストアクセス方式への、アクセス切り替えを示す、アクセス切り替えイベントを検出し、
   前記複数のプレイリスト要素の第一プレイリスト要素において、前記アクセス切り替えを示す、前記アクセス切り替えイベントの指示を提供し、
   前記複数のプレイリスト要素の前記第一プレイリスト要素を前記ＱｏＥ報告サーバーへ報告する、
   請求項５記載の装置。
7. 前記プレイリスト要素のリストは、対応付けられたメディアコンテンツ表現の連続表示が中断される理由として、前記ユニキャストアクセス方式と前記マルチキャスト／ブロードキャストアクセス方式との切り替えを示す、前記アクセス切り替えイベントの指示を含む、停止理由パラメータを有する、
   請求項５記載の装置。
8. 前記第一ＱｏＥメトリックは、受信した前記ＤＡＳＨフォーマットのメディアコンテンツ表現におけるＭＰＤ（media presentation description）情報を含み、
   前記ＭＰＤ情報は、前記ユニキャストアクセス方式又は前記マルチキャスト／ブロードキャストアクセス方式が前記メディアコンテンツ表現のために利用可能であるということを示す前記アクセス方式の指示を含む、
   請求項１記載の装置。
9. 前記メディアプレイヤーは、前記ユニキャストアクセス方式を介して前記ＤＡＳＨフォーマットコンテンツの第一の部分を受信し、
   前記マルチキャスト／ブロードキャストアクセス方式を介して前記ＤＡＳＨフォーマットコンテンツの第二の部分を受信する、
   請求項１記載の装置。
10. 当該装置はさらに、タッチスクリーンディスプレイを有しており、
    前記メディアプレイヤーは該タッチスクリーンディスプレイに前記ＤＡＳＨフォーマットコンテンツを表示するように構成されている、
    請求項１記載の装置。
11. ユニキャストアクセス方式又はマルチキャスト／ブロードキャストアクセス方式によって、動的適応型ＨＴＴＰストリーミング（dynamic adaptive streaming over hypertext transfer protocol：ＤＡＳＨ）フォーマットのコンテンツのダウンロードと再生を監視するステップ、
    前記ユニキャストアクセス方式又は前記マルチキャスト／ブロードキャストアクセス方式のアクセス方式、或いは、ＱｏＥ（quality of experience）メトリックを備えるアクセス切り替えイベントを対応付けられるステップ、及び
    前記ＱｏＥメトリックをＱｏＥ報告サーバーへ送信するステップ、
    をコンピュータに実行させるためのプログラム。
12. 前記ＱｏＥメトリックは、第一メディアコンテンツ表現を受信することから第二メディアコンテンツ表現を受信することへ切り替えに対応する表現切り替えを基にする、表現切り替えイベントメトリックを備えており、
    前記アクセス方式を示すアクセス方式属性を備えている前記表現切り替えイベントメトリックは、前記第二メディアコンテンツ表現へアクセスするのに用いられる、
    請求項１１記載のプログラム。
13. 前記ＱｏＥメトリックは、対応付けられたメディアコンテンツ表現の連続表示が中断される理由として、前記アクセス切り替えイベントを示す、停止理由パラメータを備えるプレイリストメトリックを有する、
    請求項１１記載のプログラム。
14. 前記ＱｏＥメトリックは、アクセス方式がメディアコンテンツ表現に利用可能であることの指示を含むＭＰＤ（media presentation description）情報を有する、
    請求項１１記載のプログラム。
15. 前記マルチキャスト／ブロードキャストアクセス方式は、マルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）、又は一方向伝送を介するファイル配信（File Delivery over Unidirectional Transport：ＦＬＵＴＥ）プロコトルに応じており、
    前記ユニキャストアクセス方式は、ハイパーテキスト転送プロコトル（ＨＴＴＰ）に応じている、
    請求項１１から１４のいずれか一項記載のプログラム。
16. 無線アクセスネットワークを介してユーザー機器に配信される、動的ストリーミングメディアコンテンツのダウンロード及び再生を、監視する工程、
    前記動的ストリーミングメディアコンテンツのダウンロード及び再生に対応する、１又は複数のＱｏＥ（quality of experience）メトリックを記録する工程、及び
    前記１又は複数のＱｏＥメトリックを報告モジュールへ送信する工程、を有しており、
    前記１又は複数のＱｏＥメトリックの第一ＱｏＥメトリックは、前記動的ストリーミングメディアコンテンツがユーザー機器に配信されるアクセス方式の指示、又はアクセス切り替えイベントの指示を有する、
    方法。
17. 前記第一ＱｏＥメトリックは、第一アクセス方式から第二アクセス方式へのアクセス切り替えを示すアクセス切り替えイベントの指示を含んでいる、
    請求項１６記載の方法。
18. 前記第一アクセス方式はユニキャスト方式であって、前記第二アクセス方式はマルチキャスト／ブロードキャストアクセス方式である、
    請求項１７記載の方法。
19. 前記第一アクセス方式はマルチキャスト／ブロードキャストアクセス方式であって、前記第二アクセス方式はユニキャスト方式である、
    請求項１７記載の方法。
20. 前記第一アクセス方式は第一コンテンツ配信ネットワークからの受信に基づくものであり、前記第二アクセス方式は第二コンテンツ配信ネットワークからの受信に基づくものである、
    請求項１７記載の方法。
21. ユーザー機器から、該ユーザー機器上の動的対応型ＨＴＴＰストリーミング（dynamic adaptive streaming over hypertext transfer protocol：ＤＡＳＨ）フォーマットのコンテンツの再生に関連する複数のＱｏＥ（quality of experience）メトリックを受信するステップ、及び
    前記複数のＱｏＥメトリックに基づいて、前記ＤＡＳＨフォーマットコンテンツをユーザー機器へ配信するサービスプロビジョニング調整、を開始するステップ、
    をＱｏＥ報告サーバーに実行させるためのプログラムであって、
    前記複数のＱｏＥメトリックの第一ＱｏＥメトリックは、前記ユーザー機器へ前記ＤＡＳＨフォーマットコンテンツを配信するのに利用される、ユニキャストアクセス方式又はマルチキャスト／ブロードキャストアクセス方式であるアクセス方式、又はアクセス切り替えイベントを示すプログラム。
22. 前記サービスプロビジョニング調整は、前記ＤＡＳＨフォーマットコンテンツをトランスコーディングすることを含む、
    請求項２１記載のプログラム。
23. 前記サービスプロビジョニング調整は、前記ＤＡＳＨフォーマットコンテンツの配信で採用される故障検出及び補正方式を変更することを含む、
    請求項２１記載のプログラム。
24. 前記サービスプロビジョニング調整は、ユニキャストアクセス方式からマルチキャスト／ブロードキャストアクセス方式へ、又は、マルチキャスト／ブロードキャストアクセス方式からユニキャストアクセス方式へ、前記アクセス方式を変更することを含む、
    請求項２１記載のプログラム。
25. 前記サービスプロビジョニング調整は、前記ユニキャストアクセス方式又は前記マルチキャスト／ブロードキャストアクセス方式によって、前記ＤＡＳＨフォーマットコンテンツの配信をマネジングするために無線リソースを割り当てし直す、
    請求項２１から２４のいずれか一項記載のプログラム。
26. サーバーから、ユニキャストアクセス方式またはマルチキャスト／ブロードキャストアクセス方式によってＤＡＳＨクライアントに提供される、メディアストリームの動的対応型ＨＴＴＰストリーミング（dynamic adaptive streaming over hypertext transfer protocol：ＤＡＳＨ）セグメントを受信するステップ、
    前記メディアストリームのレンダリング（Rendering）に関連する、前記ユニキャストアクセス方式又は前記マルチキャスト／ブロードキャストアクセス方式を切り替える指示を含んでいる、ＱｏＥ（quality of experience）メトリックを記録するステップ、及び
    前記ＱｏＥメトリックをＱｏＥ報告サーバーへ送信するステップ、
    をＤＡＳＨクライアントに実行させるためのプログラム。
27. 前記ＱｏＥメトリックは、測定インターバルにおいて、１又は複数の再生期間のための、プレイリスト要素のリストをログするプレイリストメトリックを含む、
    請求項２６記載のプログラム。
28. 前記プレイリスト要素のリストは、前記メディアストリームの表現の連続表示が中断される理由として、前記切り替えの指示を含む、停止理由パラメータを含む、
    請求項２７記載のプログラム。
29. 前記ブロードキャストアクセス方式は、マルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）又は一方向伝送プロコトルを介するファイル配信（ＦＬＵＴＥ）であり、
    前記ユニキャストアクセス方式は、ハイパーテキスト転送プロコトル（ＨＴＴＰ）である、
    請求項２６から２８のいずれか一項記載のプログラム。
30. ＭＰＤ（media presentation description）、オープンメディア・アライアンスー装置マネジメント（ＯＭＡ−ＤＭ）ＱｏＥ管理オブジェクト、又はセッション説明プロコトル（ＳＤＰ）メッセージにおいて、報告トリガーを取得するステップ、及び
    該報告トリガーに基づいてＱｏＥメトリックを送信するステップ、
    を前記ＤＡＳＨクライアントに更に実行させる、
    請求項２６記載のプログラム。
31. 請求項１１乃至１５及び請求項２１乃至３０のいずれか一項記載のプログラムを記憶するためのコンピュータ可読記憶媒体。

Images