JP2007523540A - 体験の品質のメトリクスのタイミング - Google Patents

Abstract

本発明は、特に、ストリーミングサービスにおける品質フィードバックの方法であって、少なくとも１つのメディアストリーム（１０１）がクライアント（６０１）へストリーミングされ、前記方法が、少なくとも１つの品質メトリクスに従って品質フィードバック値を判定するステップ（３０４）と、前記品質フィードバック値に関連するタイムスタンプを少なくとも１つのタイムスタンプメトリクスに従って判定するステップ（３０５）であって、前記少なくとも１つの品質メトリクスの各々に対して、対応するタイムスタンプメトリクスが規定され、前記少なくとも１つのタイムスタンプメトリクスの各々が、前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づく前記の判定するステップ（３０５）と、前記品質フィードバック値、及び、前記関連するタイムスタンプをサーバ（６００）に報告するステップ（３０６）とを有する方法に関する。好ましくは、前記相対的なメディア再生時間を、リアルタイム転送プロトコル（１０２）タイムスタンプから、または、リアルタイムストリーミングプロトコル（１０９）により与えられた正規再生時間から、または、リアルタイムトランスポート制御プロトコルのタイムスタンプから、または、セッション開始プロトコルのタイムスタンプから得られる。

Description

本発明は、少なくとも１つのメディアストリームがクライアントへストリーミングされるストリーミングサービスにおける品質フィードバックの方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバ及びプロトコルに関する。

一方において、ストリーミングは、音声、オーディオ及び映像ストリームのような同期化されたメディアストリームがデータネットワーク上のクライアントに送信されている間、このようなストリームを連続的に再生するためにクライアントに配置されたアプリケーションの能力を意味する。他方では、ストリーミングは、対話型アプリケーションのようなリアルタイム低遅延アプリケーションをも意味する。

ストリーミングサービスの最上位に構築できるアプリケーションを、オンデマンドとライブの情報配信アプリケーションに分類することができる。第１カテゴリの例として、音楽及びニュースオンデマンドアプリケーションが挙げられる。第２カテゴリの例として、ラジオ及びテレビ番組のライブ配信が挙げられる。リアルタイム低遅延アプリケーションの例として、マルチメディア（映像）電話またはＩＰによる音声、及び、あらゆる種類の対話型マルチメディアアプリケーションが挙げられる。

固定インターネットプロトコル（ＩＰ）ネットワーク上のストリーミングは、今日、既に主要なアプリケーションである。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）及びワールドワイドウェブコンソーシアム（Ｗ３Ｃ）は、固定ＩＰストリーミングサービスに用いられる一連のプロトコルを開発したが、完全に標準化されたストリーミングフレームワークはまだ規定されていない。第３世代パートナーシッププロジェクト（３ＧＰＰ）により開発された標準規格に従う第３世代（３Ｇ）移動通信システムに対して、３Ｇパケット交換ストリーミングサービス（ＰＳＳ，３ＧＰＰ‐ＴＳ２６．２３３，ＴＳ２６．２３４）は、３Ｇマルチメディアメッセージングサービス（ＭＭＳ）例えばアプリケーション及びマルチメディアコンテンツのダウンロードと、対話型及びストリーミングサービスとの間のギャップを埋める。

ＰＳＳは、いかなるメディア入力装置及び符号器も必要とされず、且つ、より単純なプロトコルを用いることができるため、端末の複雑性が、対話サービスに必要とされる複雑性よりも少ないモバイルストリーミングアプリケーションを可能にする。ＰＳＳは、ストリーミング制御プロトコル、トランスポートプロトコル、メディアコーデック及びシーン記述プロトコルの基本セットを含む。

図１には、コンテンツまたはメディアサーバとクライアントとの間のストリーミング可能なコンテンツとストリーミング可能でないコンテンツの双方の転送を制御するＰＳＳプロトコルスタック１を概略的に示す。

映像、オーディオ及び音声のようなストリーミング可能なコンテンツ１０１は、まず、アダプテーション層１０３内のリアルタイムトランスポートプロトコル（ＲＴＰ）１０２のペイロードフォーマットに変換される。ＩＥＴＦにより規定されているような前記ＲＴＰは、その下にあるユーザデータグラムプロトコル（ＵＤＰ）１０４のサービスを用いることによりリアルタイムまたはストリーミングデータを送信する手段を備える。ユーザデータグラムプロトコル（ＵＤＰ）１０４は、その下にあるＩＰプロトコル１０５のサービスを用いる。

例えば、ストリーミング目的に生成されていないマルチメディアコンテンツ（例えば、端末装置に記録されているＭＭＳクリップ）、静止画像、ビットマップ及びベクトルグラフィックス、テキスト、タイムドテキスト（timed text）、並びに、合成オーディオのようなストリーミング可能でないコンテンツ１０６は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）１０７により転送される。ハイパーテキスト転送プロトコル（ＨＴＴＰ）１０７は、その下にあるトランスポート制御プロトコル（ＴＣＰ）１０８と、更にその下にあるＩＰ１０５とのサービスを用いる。

ストリーミング可能でないコンテンツ１０６に対して、ＨＴＴＰ１０７の組み込まれたセッション設定及び制御能力がコンテンツを転送するのに充分であるのに対して、ストリーミング可能なコンテンツ１０１の場合では、コンテンツサーバからクライアントへＲＴＰ／ＵＤＰ／ＩＰを介して転送されるストリーミング映像を、例えば、開始、停止及び一時停止するため、高度なセッション設定及び制御プロトコルを呼び出さなくてはならない。このタスクはリアルタイムストリーミングプロトコル（ＲＴＳＰ）１０９により実行され、リアルタイムストリーミングプロトコル（ＲＴＳＰ）１０９は、その下にあるＴＣＰ１０８またはＵＤＰ１０４を用いることができる。ＲＴＳＰは、少なくともストリーミングセッションを設定するのにプレゼンテーション記述１１０を必要とする。このようなプレゼンテーション記述１１０を、例えばセッション記述プロトコル（ＳＤＰ）ファイルの形態で利用することができる。前記ＳＤＰファイルは、セッションの記述例えばセッション名及びオーサー（author）と、与えられるメディアの種類と、インスタンスアドレス、ポート、フォーマットなどに関する前記メディアを受信するための情報と、メディアのビットレートとを含む。

クライアント側例えば移動端末でストリーミングコンテンツが見られる場合、まず、ユーザの端末に適する特定コンテンツに対するユニバーサルリソース識別子（ＵＲＩ）を前記端末のユーザに供給する。このＵＲＩをＷＷＷサーバや無線アプリケーションプロトコル（ＷＡＰ）サーバによりもたらすことができ、または、端末のキーボードを介して手動で入力することができる。このＵＲＩは、ストリーミングまたはＲＴＳＰサーバと、このコンテンツサーバまたは他のコンテンツサーバ上のコンテンツのアドレスとを特定する。対応するＳＤＰファイルを多くの方法で取得することができる。例えば埋め込みタグにより、ユーザがダウンロードするＨＴＭＬページの内部のリンクで、対応のＳＤＰファイルを供給することができ、または、対応のＳＤＰファイルをＵＲＩとして打ち込むことにより直接に得られることもできる。次に、図１のプロトコルスタックの中央の列に示されるようなＨＴＴＰ１０７を介してＳＤＰファイルすなわちプレゼンテーション記述１１０を転送する。あるいはまた、ＳＤＰファイルを、例えば、図１のプロトコルスタックの右側の列に示されるようなＲＴＳＰ１０９の記述方法を用いることによりＲＴＳＰ１０９のシグナリングを介しても得られることができる。留意すべきは、ＲＴＰ１０２によっても同様に良好にプレゼンテーション記述を送信できるということである。しかし、プレゼンテーションの簡単化のため、この実現性は図１に含まれていない。

その後のセッション確立は、ブラウザまたは移動端末のユーザがストリーミングクライアントを呼び出して、コンテンツサーバに対してセッションを設定することにより処理される。端末は、ＩＰに基づくパケット伝送をセッション確立シグナリングの開始時に可能にするアクティブ無線ベアラを有することを期待されている。

ストリーミングサービスの次の設定は、クライアントにより選択された各メディアストリームに対してＲＴＳＰ設定メッセージを送信することにより行われる。クライアントは、それぞれのメディアストリームに用いるため、ＵＤＰ１０４及び／またはＴＣＰ１０８ポートを戻す。クライアントはＲＴＳＰ再生メッセージをコンテンツサーバに送信し、コンテンツサーバは、１つ以上のストリームをＩＰネットワーク上に送信し始める。

ＰＳＳシステムにおいてサービスプロバイダにエンドユーザストリーミング体験を評価する手段を与えるため、「Draft Rel-6 PSS Quality Metrics Permanent Document v.0.10」と題された３ＧＰＰ技術文書（Ｔｄｏｃ）Ｓ４‐０３０８６０に提示されているようなストリーミングサービス品質メトリクスがＰＳＳシステムに導入されている。この３ＧＰＰ技術文書は、２００３年１１月２４日〜２８日、フィンランドのタンペレで行われた第２９回３ＧＰＰ‐ＴＳＧ‐ＳＡ４会議を参考にする。ストリーミングクライアントは、実際のストリーミングアプリケーションの品質に関する情報を測定し、ストリーミングサーバにフィードバックする。前記品質は、前記品質メトリクスという形で規定されている。前記ストリーミングサーバを、例えばＲＴＳＰサーバとすることができ、例えば、前記ＲＴＳＰ及びＳＤＰを用いることにより前記品質メトリクスを転送することができる。

サービスがＲＡＮ及びＣＮの種類に対してトランスペアレントであるので、ストリーミングクライアント及びストリーミングサーバのみが、ＰＳＳ品質メトリクスにより影響を与えられる。この結果の１つとして、測定値は、ＲＴＰ層から下にあるプロトコル層（例えば、ＵＤＰ、ＩＰ、ＰＤＣＰ、ＳＮＤＣＰ、ＬＬＣ、ＲＬＣ、ＭＡＣ、物理層）からの情報に依存しないおそれがある。

品質フィードバックを用いるＰＳＳシステム内の端末は、測定規定に従って品質測定を実行し、それら品質測定値をストリーミングクライアント品質メトリクスに集め、メトリクスをストリーミングサーバに報告する責任がある。その必要条件は、ストリーミングクライアントが、ストリーミングサーバにより品質メトリクスへ処理される生の品質測定値を報告する可能性を防げない。

ストリーミングサーバは、ストリーミングクライアントの品質メトリクス報告の起動をシグナリングし、ストリーミングクライアント品質メトリクスを集める責任がある。ストリーミングサーバは、受信したストリーミングクライアント品質メトリクスを処理して、集めた品質メトリクスを構築することができる。例えば、ストリーミングサーバは、生の損失したパケット報告を受信し、特定のストリーミングクライアントについて最小、最大、平均及び標準パケット損失率を構築することができる。

下記の７つの品質メトリクスは、Ｔｄｏｃ Ｓ４‐０３０８６０により規定されている。

破損期間
破損期間は、最初の破損したフレームから、その後の最初の良好なフレームまたは報告期間の終わり（どちらか早いほう）までの期間である。このメトリクスの単位は秒で表され、これを小数値とすることができる。

リバッファリング期間
このメトリクスは、オーディオ、映像及び音声のみに適用することができ、他のメディアタイプには適用することができない。このメトリクスの単位は秒で表され、これを小数値とすることができる。リバッファリングは、クライアント側における何らかの不本意な事象による再生時間中の任意の区間として規定されている。

初期バッファリング時間
初期バッファリングは、最初のＲＴＰパケットを受信してから、再生が始まるまでの時間である。このメトリクスの単位は秒で表され、これを小数値とすることができる。

連続して損失したコンテンツパケットの数
メディアチャネル当りの連続して損失したコンテンツパケットの数

メディア復号器へ与えられたバイトの数
このパラメータは、メディア復号器へ与えられたバイトの累積数である。

検出されたビットエラーの数
これは、アプリケーションレベルで検出されたビットエラーの数である。下位レベルのエラーはリンク層により処理される（減らされるかアプリケーション層へ伝達される）。

訂正されたビットエラーの数
これは、アプリケーションレベルで訂正されたビットエラーの数である。下位レベルのエラーはリンク層により処理される（減らされるかアプリケーション層へ伝達される）。

上記の品質メトリクス規定の目的は、コンテンツの種類、端末及び無線アクセスネットワーク（ＲＡＮ）の種類すべてにわたって一貫性のある測定値を得るためである。

その制約は、ストリーミングサーバへ送信される品質メトリクス報告のサイズと、端末の複雑性とを最小限に抑えることである。

ＲＴＳＰのＳＥＴ＿ＰＡＲＡＭＥＴＥＲ方法を図２に示すようなフィードバックヘッダ２と共に用いることにより実際の品質メトリクスフィードバックをＰＳＳサーバへ伝達することができる。しかし、特定の場合では、例えば、分解（ＴＥＡＲＤＯＷＮ）メッセージまたは一時停止メッセージのような情報を伝送する他の方法を用いるのが効率的である。

図２のフィードバックヘッダ２では、Ｓｔｒｅａｍ‐ｕｒｌは、フィードバックパラメータに対するＲＴＳＰセッションまたはメディア制御ＵＲＬ識別子である。Ｐａｒａｍｅｔｅｒｓ規定内のＭｅｔｒｉｃｓフィールドは、メトリクス／測定の名前（例えば、破損期間など）を含む。Ｖａｌｕｅフィールドは結果を示す。監視期間中、同じ事象が２回以上生じる可能性がある。この場合、メトリクス値は２回以上生じてもよいので、サーバへ事象の数を知らせる。オプションのＲａｎｇｅフィールドは報告期間を示す。

図２のフィードバックヘッダ２におけるオプションのＴｉｍｅｓｔａｍｐフィールドは、事象（または測定）が生じた時点、または、セッションの開始以降にメトリクスが計算された時点を示す。

Ｔｄｏｃ Ｓ４‐０３０８６０では、前記Ｔｉｍｅｓｔａｍｐフィールドによれば、用いられる時間基準のいかなる規定も存在せず、「セッションの開始」について何の規定もない。

従って、タイムスタンプの決定に用いられる時間基準が何であるか不明確である。異なる可能性があるかもしれず、例えば、セッションの開始を用いることができるので絶対セッション時間であるかもしれない。絶対セッション時間は、セッションが発生した時間、例えば、２００４年の５月１０日の１２時２０分２２秒から１３時２０分２２秒である。しかし、例えば、破損の報告に対してタイムスタンプとして絶対セッション時間が用いられると、このタイムスタンプが、報告される事象にのみに関連するのではなく、前記セッション中、前に生じたすべての事象に関連するということが容易に分かる。例えば、かなりの初期バッファリング時間に直面し、次に、幾つかのリバッファリングがセッション中に生じた場合、前記初期バッファリング及び前記リバッファリングにより遅延されたタイムスタンプが、破損期間に関するその後の報告に割り当てられ、従って、その後の報告は簡潔性を失う。同じことが、ストリーミングをクライアントにより一時停止し、その後、再開する場合にも当てはまる。この破損の再構築または分析を品質報告及び関連のタイムスタンプに基づいてストリーミングサーバで実行する必要があれば、現在のタイムスタンプを分析する時に、初期バッファリング、リバッファリング、休止などのような先行する事象と関連するすべてのタイムスタンプを考慮しなければならない。

先行する事象のタイムスタンプのすべてを前記ストリーミングサーバで利用できる時でさえ、セッションの始まりが明確に規定されていない場合、このような再構築または分析を可能とすることが全くできない。セッションの始まりを、例えば、最初のＲＴＰパケットがストリーミングクライアントにより受信された時点、または、最初のメディアフレームが再生された時点、またはその他の時点と解釈する可能性がある。

時間基準及びセッションの開始時間が明確に規定されている場合でさえ、規定されたメトリクスの一部のタイムスタンプ値は、異なるクライアント、または、同一クライアントの異なるセッションの間で依然として変化するおそれがある。このことは、特に、クライアントサイトで測定できる品質メトリクスが、ストリーミングクライアントを設定する端末の処理電力及びタスクの負荷に依存するという事実による。例えば、４番目のメトリクス、すなわち、連続して損失したＲＴＰパケットの数のタイムスタンプが、復号化の開始前に、正確な時間であるように規定されている場合でさえ、前記指標に到達するのに端末により必要とされる時間は、前記処理電力及び前記タスクの負荷に依存する。

その結果として、ストリーミングサーバ及びストリーミングクライアントは、報告された品質メトリクスについて異なる解釈を有するおそれがあり、クライアントは、同一のストリーミング品質について異なる品質メトリクスを報告するおそれがある。従って、報告されたタイムスタンプの不明確さのため、ストリーミングサーバはストリーミング品質を正確に分析することができない。

上述の問題を考慮して、本発明の目的は、特に、ストリーミングサービスにおいて品質フィードバック値のタイミングを正確かつ明白に報告できるようにする方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバ及びプロトコルを提案することにある。

本発明は、ストリーミングサービスにおける品質フィードバックの方法であって、少なくとも１つのメディアストリームがクライアントへストリーミングされ、前記方法が、少なくとも１つの品質メトリクスに従って品質フィードバック値を判定するステップと、前記品質フィードバック値に関連するタイムスタンプを少なくとも１つのタイムスタンプメトリクスに従って判定するステップにおいて、前記少なくとも１つの品質メトリクスの各々に対して、対応するタイムスタンプメトリクスが規定され、前記少なくとも１つのタイムスタンプメトリクスの各々が、前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づくステップと、前記品質フィードバック値、及び、前記関連するタイムスタンプをサーバに報告するステップとを有する方法を提案する。

前記少なくとも１つのメディアストリームを、例えば連続的なメディアストリームとすることができ、この連続的なメディアストリームは、サーバ例えばコンテンツサーバから前記クライアントに連続して伝送され、前記クライアントが同期して設定されている端末上でレンダリングされる映像、オーディオまたは音声情報を含むことができる。あるいはまた、前記少なくとも１つのメディアストリームを、例えば、マルチメディア（映像）電話ストリームまたはＩＰによる音声メディアストリームまたは対話型マルチメディアアプリケーションのあらゆる種類のメディアストリームのようなリアルタイム低遅延アプリケーションのメディアストリームとすることができる。このストリーミングをストリーミングセッションで生じることができ、幾つかのメディアストリームを前記クライアントへ同時にストリーミングすることができる。前記ストリーミングは、プロトコル例えばリアルタイムトランスポートプロトコルＲＴＰに基づくことができ、これを更なるプロトコル例えば、リアルタイムストリーミングプロトコルＲＴＳＰまたはセッション開始プロトコルＳＩＰのようなストリーミングプロトコルにより制御することができ、これにより、例えば、ストリーミングを開始、停止及び／または一時停止することができる。前記クライアント及び前記サーバのプロトコルエンティティにより前記ＲＴＳＰまたはＳＩＰを動作させることができ、前記ＲＴＳＰまたはＳＩＰはセッション記述プロトコルＳＤＰに基づくことができる。前記サーバを、前記メディアが実際に生じるコンテンツサーバと同じ場所に配置することができ、または、このコンテンツサーバと同一にすることができ、または、異なる場合にすることができる。前記ストリーミングの品質は、例えば破損期間またはリバッファリング事象のような前記少なくとも１つの品質メトリクスに従ってクライアントサイトで判定され、例えば、ストリーミングが基づく前記プロトコル、または、ストリーミングを制御する前記プロトコルを介して品質フィードバック値として報告される。前記品質メトリクスは、前記品質フィードバック値をどのように計算するかを基本的に規定する。ストリーミングを制御する前記プロトコルにより前記少なくとも１つの品質メトリクスを規定することができ、例えば、前記プロトコルにより規定された一連の幾つかの品質メトリクスから生じた前記少なくとも１つの品質メトリクスを、セッションの設定中、またはその後、前記クライアントと前記サーバとの間で取り決めることができる。前記少なくとも１つの品質メトリクスの各々に対して、それぞれのタイムスタンプメトリクスが、例えば、前記ストリーミングを制御する前記プロトコルにより規定されている。前記タイムスタンプメトリクスは、品質メトリクスにより規定されている品質メトリクス値と関連するタイムスタンプをどのように判定するかを基本的に規定する。前記少なくとも１つのタイムスタンプメトリクスは、前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づく。前記相対的なメディア再生時間は、いかなる絶対時間基準からも切り離された、すなわち、ストリーミング中に生じるようなまとまった中断間隔または再生の遅延間隔を持たない前記少なくとも１つのメディアストリームの再生の時間進行を表す。従って、相対的なメディア再生時間を、デジタルフォーマットに記録する間、連続的なメディアのサンプリング時間に関連付けることができる。例えば、ＲＴＰにより表わされたＲＴＰタイムスタンプにより、または、ＲＴＳＰにより与えられた正規再生時間（ＮＰＴ）により、または、ＳＩＰあるいはＲＴＣＰにより与えられたタイムスタンプあるいはタイミング情報により前記相対的なメディア再生時間を表すことができる。前記品質フィードバック値と、関連するタイムスタンプとを、次に、例えば、ストリーミングが基づく前記プロトコルを介して、または、ストリーミングを制御する前記プロトコルを介して前記サーバに報告する。前記ストリーミングを制御する前記プロトコルがＲＴＣＰまたはＳＩＰであれば、品質測定を行うため、前記報告した品質フィードバック値と、関連するタイムスタンプとを、エンティティ例えば、呼状態制御機能（ＣＳＣＦ）のようなネットワークエンティティにより捕捉するかまたは傍受するのが好ましいであろう。前記タイムスタンプを、例えば、ＲＴＰ／ＲＴＳＰ／ＲＴＣＰ／ＳＩＰヘッダにおける強制的な、または選択的なパラメータとすることができる。

本発明の第１の態様によれば、各品質フィードバック値にタイムスタンプを割り当てることができ、前記タイムスタンプのタイムスタンプメトリクスは、前記品質フィードバック値の品質メトリクスに対して明確に規定される。従って、異なる品質メトリクスの一分類に一般的なタイムスタンプメトリクスを用いることから生じる曖昧さが取り除かれる。

更に、本発明の第２の態様によれば、タイムスタンプメトリクスは時間基準として相対的なメディア再生時間に基づき、従って、絶対セッション時間と、報告される実際の事象より前に発生した事象により生じた遅延と、クライアントが設定されている端末の処理電力及びタスクの負荷とは無関係となる。相対的なメディア再生時間の使用により、セッションの始まりを規定する必要性を無くすこともできる。

本発明の方法によれば、前記少なくとも１つのメディアストリームの前記ストリーミングがリアルタイムトランスポートプロトコルＲＴＰに基づくのが好ましいであろう。前記ＲＴＰを前記クライアントとコンテンツサーバとの間で動作させることができ、前記ＲＴＰはユーザデータグラムプロトコルＵＤＰのサービスを用いることができ、ユーザデータグラムプロトコルＵＤＰはインターネットプロトコルＩＰのサービスを用いることができる。

本発明の方法によれば、前記相対的なメディア再生時間を、前記ＲＴＰの少なくとも１つのプロトコルデータ単位のヘッダに形成されているＲＴＰタイムスタンプから生じさせるのが好ましいであろう。前記ＲＴＰタイムスタンプはＲＴＰプロトコルデータ単位（またはパケット）の最初のオクテットのサンプリング時を反映することができる。または、リアルタイムでサンプリングされているデータというよりはむしろ、記憶されたデータが前記少なくとも１つのメディアストリームで送信される場合、次のフレームまたは他の単位を与えるべき時刻を判定するため、前記ＲＴＰタイムスタンプを、掛け時計時間から生じる仮想プレゼンテーションスケジュールから生じさせることができる。

本発明の方法によれば、前記ストリーミングをリアルタイムストリーミングプロトコルＲＴＳＰにより少なくとも部分的に制御するのが好ましいであろう。前記ＲＴＳＰは、セッション記述プロトコルＳＤＰにより与えられたプレゼンテーション記述に基づくことができる。前記クライアントと前記サーバとにより前記ＲＴＳＰを動作させることができ、前記ＲＴＳＰにより、例えば、ストリーミングを開始、一時停止及び停止することができる。

本発明の方法によれば、前記相対的なメディア再生時間を、前記ＲＴＳＰにより与えられた通常の再生時間ＮＰＴから生じさせるのが好ましいであろう。前記ＮＰＴは、プレゼンテーションの開始に対するストリーム絶対位置を示すことができる。前記ＮＰＴをＲＴＰタイムスタンプから生じさせることができる。

本発明の方法によれば、前記少なくとも１つの品質メトリクスが、事象の継続期間であるように前記品質メトリクス値を規定し、前記対応のタイムスタンプメトリクスは、前記事象が生じる前の、前記少なくとも１つのメディアストリームの特定フレームの相対的なメディア再生時間であるように前記タイムスタンプを規定するのが好ましいであろう。

本発明の方法によれば、前記事象が破損期間であり、前記特定フレームが、再生順で、前記破損の発生前にある最後の良好なフレームであるのが好ましいであろう。

本発明の方法によれば、前記事象がリバッファリング期間であり、前記特定フレームが、前記リバッファリングの発生前、最後に再生されたフレームであるのが好ましいであろう。

本発明の方法によれば、前記事象が、連続して損失したコンテンツパケットの数であり、前記特定のフレームが、再生順で、前記連続して損失したパケットの発生前に、最後に受信したフレームであるのが好ましいであろう。

本発明の方法によれば、前記少なくとも１つの品質メトリクスが、事象の数であるように前記品質メトリクス値を規定し、前記対応のタイムスタンプメトリクスは、前記事象の数が測定される前の、前記少なくとも１つのメディアストリームの特定フレームの相対的なメディア再生時間であるように前記タイムスタンプを規定するのが好ましいであろう。

本発明の方法によれば、前記事象の数が、メディア復号器へ与えられたバイトの数、または、検出されたビットエラーの数、または、訂正されたビットエラーの数であり、前記特定フレームが、前記事象の数が測定される前、最後に復号化されたフレームであるのが好ましいであろう。

本発明の方法によれば、前記ＲＴＳＰを介して、前記品質フィードバック値、及び、前記関連するタイムスタンプを前記サーバに報告するのが好ましいであろう。前記品質フィードバック値及び前記タイムスタンプを、例えばＲＴＳＰプロトコルデータユニットのヘッダに含めることができる。

本発明の方法によれば、前記ストリーミングをセッション開始プロトコルＳＩＰにより少なくとも部分的に制御するのが好ましいであろう。この場合、品質測定を行うため、前記ＳＩＰを介して報告された前記品質フィードバック値と、関連するタイムスタンプとを、エンティティ例えば、呼状態制御機能（ＣＳＣＦ）のようなネットワークエンティティにより捕捉するかまたは傍受するのが好ましいであろう。

本発明の方法によれば、前記相対的なメディア再生時間を、前記ＳＩＰにより与えられた時間基準から生じさせ、特に、前記ＳＩＰの少なくとも１つのプロトコルデータユニットのヘッダに形成されているＳＩＰタイムスタンプから生じさせるのが好ましいであろう。

本発明の方法によれば、前記ストリーミングをリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）により少なくとも部分的に制御するのが好ましいであろう。この場合、品質測定を行うため、前記ＲＴＣＰを介して報告された前記品質フィードバック値と、関連するタイムスタンプとを、エンティティ例えば、呼状態制御機能（ＣＳＣＦ）のようなネットワークエンティティにより捕捉するかまたは傍受するのが好ましいであろう。

本発明の方法によれば、前記相対的なメディア再生時間を、前記ＲＴＣＰにより与えられた時間基準から得て、特に、前記ＲＴＣＰの少なくとも１つのプロトコルデータ単位のヘッダに形成されているＲＴＣＰタイムスタンプから得るのが好ましいであろう。

本発明の方法によれば、前記報告された品質フィードバック値、及び、前記関連するタイムスタンプをインスタンスにより捕捉し、前記ストリーミングの品質を分析するのに用いるのが好ましいであろう。

本発明の方法によれば、前記ストリーミングサービスが３Ｇ移動通信システムのパケット交換ストリーミングサービスＰＳＳであるのが好ましいであろう。

本発明は、上述した方法のステップをプロセッサに実行させるように動作可能な命令を有するコンピュータプログラムを更に提案する。

本発明は、上述した方法のステップをプロセッサに実行させるように動作可能な命令を有するコンピュータプログラムを含むコンピュータプログラム製品を更に提案する。

本発明は、ストリーミングサービスにおける品質フィードバックのシステムであって、前記システムが、少なくとも１つのサーバと、少なくとも１つのクライアントとを備え、少なくとも１つのメディアストリームが前記少なくとも１つのクライアントへストリーミングされ、品質フィードバック値が少なくとも１つの品質メトリクスに従って判定され、前記品質フィードバック値に関連するタイムスタンプが、前記少なくとも１つの品質メトリクスの各々に対して対応するように規定されると共に前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づく少なくとも１つのタイムスタンプメトリクスに従って判定され、前記品質フィードバック値、及び、前記関連するタイムスタンプが前記少なくとも１つのサーバに報告されるシステムを更に提案する。

本発明は、ストリーミングサービスにおけるクライアントであって、前記クライアントへストリーミングされる少なくとも１つのメディアストリームを受信する手段と、品質フィードバック値を少なくとも１つの品質メトリクスに従って判定する手段と、前記品質フィードバック値に関連するタイムスタンプを少なくとも１つのタイムスタンプメトリクスに従って判定する手段において、前記少なくとも１つの品質メトリクスの各々に対して、対応のタイムスタンプメトリクスが規定され、前記少なくとも１つのタイムスタンプメトリクスの各々が、前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づく手段と、前記品質フィードバック値、及び、前記関連するタイムスタンプをサーバに報告する手段とを備えるクライアントを更に提案する。前記クライアントを、例えばＳＩＰにより制御できる例えばマルチメディア（映像）電話またはＩＰによる電話のようなリアルタイム低遅延アプリケーションセッションにかかわっている少なくとも二人の当事者の一方として理解することもできる。

本発明は、ストリーミングサービスにおけるサーバにおいて、少なくとも１つのメディアストリームがクライアントへストリーミングされ、品質フィードバック値が少なくとも１つの品質メトリクスに従って判定され、前記品質フィードバック値に関連するタイムスタンプが、前記少なくとも１つの品質メトリクスの各々に対して対応するように規定されると共に前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づく少なくとも１つのタイムスタンプメトリクスに従って判定されるサーバであって、前記サーバが、前記クライアントにより前記サーバに報告された前記品質フィードバック値、及び、前記関連するタイムスタンプを受信する手段を備えるサーバを更に提案する。前記サーバを、例えばＳＩＰにより制御できる例えばマルチメディア（映像）電話またはＩＰによる電話のようなリアルタイム低遅延アプリケーションセッションにかかわっている少なくとも二人の当事者の一方として理解することもできる。

本発明は、ストリーミングサービスに用いられるプロトコルにおいて、少なくとも１つのメディアストリームがクライアントへストリーミングされ、前記プロトコルが、少なくとも１つの品質メトリクスと、前記少なくとも１つの品質メトリクスの各々に対する少なくとも１つのタイムスタンプメトリクスとを規定し、前記少なくとも１つのタイムスタンプメトリクスの各々が前記少なくとも１つのメディアストリームの相対的なメディア再生時間に基づくプロトコルを更に提案する。

本発明のプロトコルによれば、前記プロトコルが、セッション記述プロトコルＳＤＰと組み合わされたＲＴＳＰであるのが好ましいであろう。

本発明のプロトコルによれば、前記プロトコルが、セッション記述プロトコルＳＤＰと組み合わされたＳＩＰであるのが好ましいであろう。

本発明のプロトコルによれば、前記プロトコルがＲＴＣＰであるのが好ましいであろう。

本発明の上述した態様及びその他の態様は、以下に説明する実施形態を参照することにより明らかになるであろう。

本発明は、各々規定された品質メトリクスに対して明確に且つ均一に指定されたタイムスタンプメトリクス（タイムスタンプセマンティクス）を提案することにより、同期化された映像及びオーディオの転送及びレンダリングのような連続的なマルチメディアアプリケーションと対話型アプリケーションのようなリアルタイム低遅延アプリケーションとの双方に対するストリーミングサービスにおいて品質フィードバック値のタイミングを報告する際の不明確さを取り除く。タイムスタンプメトリクスは、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）が用いられる場合に利用できる正規再生時間（normal playing time（ＮＰＴ））とすることができ、または、ＲＴＰにより供給され各ＲＴＰヘッダに含まれるリアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプから得ることができ、または、リアルタイムトランスポート制御プロトコルＲＴＣＰあるいはセッション開始プロトコルＳＩＰの時間基準あるいはタイムスタンプから得ることができる相対的なメディア再生時間に基づく。

ＲＴＣＰは、データパケットと同じ配信機構を用いるセッション中のすべての当事者への制御パケットの周期的な伝送に基づく。下層のプロトコルは、例えば、ＵＤＰで別々のポート番号を用いてデータの多重化及びパケットの制御を行わなければならない。ＲＴＣＰは、特に、データ配信の品質に関するフィードバックを行うことができる。このことは、転送プロトコルとしてのＲＴＰの役割の不可欠な部分であり、他の転送プロトコルのフロー及び輻輳制御機能に関連する。適応符号化の制御にフィードバックを直接に役立てることができる。しかし、ＩＰマルチキャスティングに関する実験は、配信中の障害を診断するため、受信機からフィードバックを得ることも重要であることを示している。受信フィードバック報告をすべての当事者へ送信することにより、問題を観察する人は、これら問題が局所的であるか大域的であるかを評価することができる。ＩＰマルチキャストのような配信機構の場合、他の点ではセッションに関与しないネットワークサービスプロバイダのようなエンティティがフィードバック情報を受信し、ネットワーク問題を診断するための第３者モニタとしての役割を果すことも可能である。このフィードバック機能は、ＲＴＣＰ発信者及び受信者の報告により実行される。特に、ＲＴＣＰは、タイムスタンプを支援するか供給することができる。

ＳＩＰは、インターネット電話呼のようなマルチメディアセッション（会議）を確立し、変更し、終了することができるアプリケーション層制御プロトコルである。ＳＩＰは、マルチキャスト会議のような既存のセッションへ当事者を勧誘することもできる。既存のセッションにメディアを加える（また、既存のセッションから取り除く）ことができる。ＳＩＰは、ユーザのネットワーク位置にかかわらず外部から見える単一識別子をユーザが維持できる個人の移動性を支援するネームマッピング及びリダイレクションサービスをトランスペアレントに支援する。

ＳＩＰは、縦に統合された通信システムではない。むしろ、ＳＩＰは、完全なマルチメディアアーキテクチャを構築するのに他のＩＥＴＦプロトコルと用いることができるコンポーネントである。典型的には、これらアーキテクチャは、リアルタイムデータを転送しＱｏＳフィードバックを行うＲＴＰや、ストリーミングメディアの配信を制御するリアルタイムストリーミングプロトコルＲＴＳＰや、公衆交換電話網（ＰＳＴＮ）に対するゲートウェイを制御するメディアゲートウェイ制御プロトコルＭＥＧＡＣＯや、マルチメディアセッションを記述するセッション記述プロトコルＳＤＰのようなプロトコルを含む。従って、完全なサービスをユーザに提供するため、他のプロトコルと併せてＳＩＰを用いる必要がある。しかし、ＳＩＰの基本機能及び動作は、これらプロトコルのいずれにも依存しない。

ＳＩＰは、特に、ヘッダにタイムスタンプフィールドを備える。タイムスタンプヘッダフィールドは、例えば、ある当事者がリクエストを他の当事者に送信した時点を記述することができる。

ＳＩＰまたはＲＴＣＰが用いられる場合、ストリーミングはセッションの（例えば、２つの端末に設定された）二人の当事者の間で生じ、ある当事者が品質フィードバック値及び関連のタイムスタンプを他の当事者に報告することが役立たない場合がある。従って、ＳＩＰまたはＲＴＣＰは、例えば呼状態制御機能ＣＳＣＦとしてネットワークエンティティを構成して、これら報告された品質フィードバック値及び関連のタイムスタンプを傍受するのに有利であり、これらを用いて、二人の当事者間のストリーミングの品質を分析する。

提案するタイムスタンプメトリクスを用いれば、異なるストリーミングサーバ及びストリーミングクライアントは、報告された品質メトリクス例えば、３Ｇ移動通信システムのパケット交換ストリーミングサービス（ＰＳＳ）でのような体験の品質ＱｏＥメトリクスについて、または対話型アプリケーションの品質フィードバックについて同一の解釈を有し、ストリーミング品質体験の正確な分析を可能にする。ストリーミングサーバまたはＱｏＥメトリクス分析器が、ＮＰＴを実時間にマッピングする方法を用いれば、セッション品質について時間に関する分析を行うことができる。

３ＧＰＰ技術文書Ｓ４‐０３０８６０に規定された品質メトリクスの各々に対して本発明で規定されるようなタイムスタンプメトリクスを後に提示するであろう。表記ＮＰＴ／ＲＴＰのタイムスタンプは、ＮＲＴが利用できればＮＰＴが相対的なメディア再生時間として用いられ、ＲＴＰタイムスタンプのみが利用できればこれらは相対的なメディア再生時間として用いられるものと理解されるべきである。

破損期間
タイムスタンプは、破損が生じた時点を示す。タイムスタンプの値は、再生順で、破損発生の前にある最後の良好なフレームのＮＰＴ／ＲＴＰタイムスタンプに等しい。破損前に良好なフレームがなければ、タイムスタンプは０に設定される。

メトリクス破損期間は、オーディオ、映像または音声メディアに適用できるだけでなく、メディアとしてタイムドテキストストリームに適用することもできる。

リバッファリング期間
タイムスタンプは、リバッファリングが生じた時点を示す。タイムスタンプの値は、リバッファリングの発生前、最後に再生されたフレームのＮＰＴ／ＲＴＰタイムスタンプに等しい。

初期バッファリング時間
タイムスタンプセマンティクスは指定されておらず、タイムスタンプの値は規定されていない。

連続して損失したコンテンツパケットの数
タイムスタンプは、一連の損失したパケットが生じた時点を示す。タイムスタンプの値は、再生順で、一連の損失したパケットの発生前、最後に受信したＲＴＰのＮＰＴ／ＲＴＰタイムスタンプに等しい。一連の損失したパケット前に、受信したＲＴＰパケットがなければ、タイムスタンプは０に設定される。

メディア復号器へ与えられたバイトの数
タイムスタンプは、メディア復号器へ与えられたバイトの数が測定された時点を示す。タイムスタンプの値は、メディア復号器へ与えられたバイトの数が測定される前、最後に復号化されたフレームのＮＰＴ／ＲＴＰタイムスタンプに等しい。測定前に、復号化されたフレームがなければ、タイムスタンプは０に設定される。

検出されたビットエラーの数
タイムスタンプは、検出されたビットエラーの数が測定された時点を示す。タイムスタンプの値は、検出されたビットエラーの数が測定される前、最後に復号化されたフレームのＮＰＴ／ＲＴＰタイムスタンプに等しい。測定前に、復号化されたフレームがなければ、タイムスタンプは０に設定される。

訂正されたビットエラーの数
タイムスタンプは、訂正されたビットエラーの数が測定された時点を示す。タイムスタンプの値は、訂正されたビットエラーの数が測定される前、最後に復号化されたフレームのＮＰＴ／ＲＴＰタイムスタンプに等しい。測定前に、復号化されたフレームがなければ、タイムスタンプは０に設定される。

上記のタイムスタンプメトリクスから分かるように、事象発生（破損、リバッファリング、初期バッファリング、または、一連のＲＴＰパケットの損失）の時刻、または、統計値（メディア復号器へ与えられたバイトの数、検出されたビットエラーの数、及び、訂正されたビットエラーの数）が測定された時刻は、実際には、相対的なメディア再生時間（ＮＰＴ／ＲＴＰタイムスタンプ）において測定されたメディアストリームの位置である。

初期バッファリングが、再生の始まる前、セッションの始めにのみ生じるので、初期バッファリング時間のタイムスタンプは指定されない。

提案されたタイムスタンプ情報を有する報告された品質メトリクスに従って、ストリーミングサーバは、クライアントにおいて生じたストリーミング再生またはレンダリングを再現する（mimic）ことができる。従って、ストリーミング品質を完全に分析することができる。

図３には、本発明による方法のフローチャートを示す。最初のステップ３００では、ストリーミングセッションをストリーミングクライアントとストリーミングサーバとの間に設定する。ステップ３０１では、ストリーミングクライアントにより実行される品質フィードバック手順に用いるため、１つ以上の品質メトリクスをストリーミングクライアントとストリーミングサーバとの間で取り決める。前記セッションの設定及び取り決めの双方は、ＳＤＰと組み合わされたＲＴＳＰ、または、ＲＴＣＰあるいはＳＩＰに基づくことができる。ステップ３０１をステップ３００と一緒に実行することもできる。対応のタイムスタンプメトリクスを、ストリーミングセッショに対して取り決めた品質メトリクスの各々と関連付けることができる。ステップ３０２では、例えば、メディアストリームをストリーミングクライアントに送信し、前記ストリーミングクライアントが設定されている端末でメディアストリームをレンダリングする時、実際のストリーミングを開始する。前記ストリーミングの期間に、ステップ３０３では、品質フィードバックが必要とされるかどうかを監視する。この監視を、例えば、取り決めた品質メトリクスに従ってストリーミングサーバに報告しなければならない事象が生じたかどうかを連続して確認することにより達成することができる。この事象を、例えば、リバッファリング事象とすることができる。あるいはまた、周期的な品質報告を、例えば、ある時間間隔で、メディア復号器へ与えられたバイトの数の周期的なフィードバックについて取り決めることができる。前記ステップ３０３では、事象駆動の品質フィードバック及び周期的な品質フィードバックの双方が起動される。品質フィードバックが必要とされると決定すれば、ステップ３０４において、取り決めた品質メトリクスの各々に従って品質フィードバック値を判定する。次に、ステップ３０５では、取り決めた品質メトリクスの各々に対応するタイムスタンプメトリクスに従って、対応のタイムスタンプを判定する。前記ステップ３０５をステップ３０４の前でも同様に良好に実行することができる。いずれの場合でも、ステップ３０６において、例えばＲＴＳＰ、ＲＴＣＰまたはＳＩＰを介して、品質フィードバック値及び対応のタイムスタンプをストリーミングサーバに報告する。品質フィードバックの後、または、いかなる品質フィードバックも必要とされないと判定された場合、ステップ３０７では、ストリーミングを停止すべきかを確認する。停止すべきでない場合、ステップ３０３において、新たな品質フィードバックが必要とされるかどうかを再び確認する。

図４には、本発明によるシステムの機能コンポーネントを概略的に示す。この実施例は、ストリーミングを制御するのにＲＴＳＰを用いるＰＳＳシステムについて典型的に言及する。当然のことながら、本明細書では、わずかに修正された下側のプロトコルスタックと、クライアント６０１（第１の当事者）からサーバ６００（第２の当事者）へ送信された品質フィードバック及びタイムスタンプを傍受または捕捉する追加のネットワークインスタンスと一緒にＳＩＰも同様に良く用いることができる。図４のＰＳＳシステムはストリーミングクライアント６０１及びストリーミングサーバ６００を含み、クライアント６０１及びサーバ６００の双方は、ＲＴＳＰを動作することができる少なくとも１つのＲＴＳＰエンティティ４０１，４００を有する。ＲＴＳＰエンティティ４０１，４００は、その下側にあるプロトコル層のサービスを用いる。下側にあるプロトコル層は、更なるプロトコルエンティティにより動作させられ、下側にあるプロトコル層のうち、ＴＣＰ／ＵＤＰエンティティ４０２，４０３及びＩＰエンティティ４０４，４０５のみが示されている。ストリーミングクライアント６０１は、取り決めた品質メトリクス及び対応のタイムスタンプメトリクスに関して実際のストリーミングアプリケーションの品質を監視し、監視した品質フィードバック値を前記ＲＴＳＰエンティティ４０１へ入力するストリーミング品質モニタインスタンス４０７と更に接続されている。前記ストリーミング品質モニタを、例えば、前記ストリーミングクライアントが設定されている端末により与えることができる。ストリーミング品質モニタ４０７は、次に、用いられている品質メトリクスに対応するタイムスタンプメトリクスに従ってタイムスタンプを判定し、クライアントＲＴＳＰ４０１を介して、前記監視された品質フィードバック値及び前記対応するタイムスタンプをストリーミングサーバ６００のＲＴＳＰピアエンティティへ転送する。ＲＴＳＰピアエンティティでは、例えば、リバッファリング事象が度々起こり過ぎると検出された場合にストリーミングアプリケーションのデータレートを増大することによりストリーミングアプリケーションの品質を改善することを目的とするか、または、統計に基づく品質データの収集あるいは課金だけを目的とするか、または、その他の目的とすることができる評価及び分析のため、これら品質フィードバック値及び対応のタイムスタンプを品質データ処理インスタンス４０６に入力する。

好適な実施例を用いて上記に本発明を説明した。当業者に明らかであって、請求項の範囲及び精神を逸脱することなく、実施することができる代わりの方法及び変形形態があることに留意すべきである。特に、本発明は、３Ｇ無線通信システムの分野だけに制限されるものではない。パラメータフィードバックを用いるあらゆる種類の有線及び無線データ伝送システムにも同様に良好に利用することができる。

従来技術によるパケット交換ストリーミングサービス（ＰＳＳ）プロトコルスタックの略図を示す図である。 従来技術によるリアルタイムストリーミングプロトコル（ＲＴＳＰ）の取り決めヘッダの規定を示す図である。 本発明の方法のフローチャートを示す図である。 本発明のシステムの略図を示す図である。

Claims (27)

1. ストリーミングサービスにおける品質フィードバックの方法であって、少なくとも１つのメディアストリーム（１０１）がクライアント（６０１）へストリーミングされる前記の方法が、
   少なくとも１つの品質メトリクスに従って品質フィードバック値を判定するステップ（３０４）と、
   前記品質フィードバック値に関連するタイムスタンプを少なくとも１つのタイムスタンプメトリクスに従って判定するステップ（３０５）であって、前記少なくとも１つの品質メトリクスの各々に対して、対応するタイムスタンプメトリクスが規定され、前記少なくとも１つのタイムスタンプメトリクスの各々が、前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づく、前記の判定するステップ（３０５）と、
   前記品質フィードバック値、及び、前記関連するタイムスタンプをサーバ（６００）に報告するステップ（３０６）と
   を有する方法。
2. 前記少なくとも１つのメディアストリーム（１０１）の前記ストリーミングがリアルタイムトランスポートプロトコルＲＴＰ（１０２）に基づく、請求項１に記載の方法。
3. 前記相対的なメディア再生時間が、前記ＲＴＰ（１０２）の少なくとも１つのプロトコルデータユニットのヘッダに与えられているＲＴＰタイムスタンプから得られる、請求項２に記載の方法。
4. 前記ストリーミングがリアルタイムストリーミングプロトコルＲＴＳＰ（１０９）により少なくとも部分的に制御される、請求項１〜３のいずれか一項に記載の方法。
5. 前記相対的なメディア再生時間が、前記ＲＴＳＰ（１０９）により与えられた正規再生時間ＮＰＴから得られる、請求項４に記載の方法。
6. 前記少なくとも１つの品質メトリクスが、事象の継続期間であるように前記品質メトリクス値を規定し、前記対応するタイムスタンプメトリクスは、前記事象が生じる前の、前記少なくとも１つのメディアストリーム（１０１）の特定のフレームの相対的なメディア再生時間であるように前記タイムスタンプを規定する、請求項１〜５のいずれか一項に記載の方法。
7. 前記事象が破損期間であり、前記特定のフレームが、再生順で、前記破損の発生前の最後の良好なフレームである、請求項６に記載の方法。
8. 前記事象がリバッファリング期間であり、前記特定のフレームが、前記リバッファリングの発生前の最後に再生されたフレームである、請求項６に記載の方法。
9. 前記事象が、連続して損失したコンテンツパケットの数であり、前記特定のフレームが、再生順で、前記連続して損失したパケットの発生前の最後に受信したフレームである、請求項６に記載の方法。
10. 前記少なくとも１つの品質メトリクスが、事象の数であるように前記品質メトリクス値を規定し、前記対応するタイムスタンプメトリクスは、前記事象の数が測定される前の、前記少なくとも１つのメディアストリーム（１０１）の特定のフレームの相対的なメディア再生時間であるように前記タイムスタンプを規定する、請求項１〜５のいずれか一項に記載の方法。
11. 前記事象の数が、メディア復号器へ与えられたバイトの数、または、検出されたビットエラーの数、または、訂正されたビットエラーの数であり、前記特定のフレームが、前記事象の数が測定される前の最後に復号化されたフレームである、請求項１０に記載の方法。
12. 前記品質フィードバック値、及び、前記関連するタイムスタンプが前記ＲＴＳＰ（１０９）を介して前記サーバ（６００）に報告される、請求項４〜１１のいずれか一項に記載の方法。
13. 前記ストリーミングがセッション開始プロトコルＳＩＰにより少なくとも部分的に制御される、請求項１に記載の方法。
14. 前記相対的なメディア再生時間が、前記ＳＩＰにより与えられた時間基準から得られ、特に、前記ＳＩＰの少なくとも１つのプロトコルデータユニットのヘッダに与えられているＳＩＰタイムスタンプから得られる、請求項１３に記載の方法。
15. 前記ストリーミングがリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）により少なくとも部分的に制御される、請求項１に記載の方法。
16. 前記相対的なメディア再生時間が、前記ＲＴＣＰにより与えられた時間基準から得られ、特に、前記ＲＴＣＰの少なくとも１つのプロトコルデータユニットのヘッダに与えられているＲＴＣＰタイムスタンプから得られる、請求項１５に記載の方法。
17. 前記報告された品質フィードバック値、及び、前記関連するタイムスタンプがインスタンスにより捕捉され、前記ストリーミングの品質を分析するのに用いられる、請求項１３〜１６のいずれか一項に記載の方法。
18. 前記ストリーミングサービスが３Ｇ移動通信システムのパケット交換ストリーミングサービスＰＳＳである、請求項１〜１７のいずれか一項に記載の方法。
19. 請求項１〜１８のいずれか一項に記載の方法のステップをプロセッサに実行させるように動作可能な命令を有するコンピュータプログラム。
20. 請求項１〜１８のいずれか一項に記載の方法のステップをプロセッサに実行させるように動作可能な命令を有するコンピュータプログラムを備えるコンピュータプログラム製品。
21. ストリーミングサービスにおける品質フィードバックのシステムであって、
    少なくとも１つのサーバ（６００）と、
    少なくとも１つのクライアント（６０１）とを備え、
    少なくとも１つのメディアストリーム（１０１）が前記少なくとも１つのクライアント（６０１）へストリーミングされ、品質フィードバック値が少なくとも１つの品質メトリクスに従って判定され、前記品質フィードバック値に関連するタイムスタンプが、前記少なくとも１つの品質メトリクスの各々に対して対応するように規定されると共に前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づく少なくとも１つのタイムスタンプメトリクスに従って判定され、前記品質フィードバック値、及び、前記関連するタイムスタンプが前記少なくとも１つのサーバ（６００）に報告されるシステム。
22. ストリーミングサービスにおけるクライアント（６０１）であって、
    前記クライアント（６０１）へストリーミングされる少なくとも１つのメディアストリーム（１０１）を受信する手段（４０１，４０３，４０５）と、
    品質フィードバック値を少なくとも１つの品質メトリクスに従って判定する手段（４０１，４０７）と、
    前記品質フィードバック値に関連するタイムスタンプを少なくとも１つのタイムスタンプメトリクスに従って判定する手段（４０１）であって、前記少なくとも１つの品質メトリクスの各々に対して、対応するタイムスタンプメトリクスが規定され、前記少なくとも１つのタイムスタンプメトリクスの各々が、前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づく、前記の判定する手段（４０１）と、
    前記品質フィードバック値、及び、前記関連するタイムスタンプをサーバ（６００）に報告する手段（４０１）と
    を備えるクライアント。
23. ストリーミングサービスにおけるサーバ（６００）であって、少なくとも１つのメディアストリーム（１０１）がクライアント（６０１）へストリーミングされ、品質フィードバック値が少なくとも１つの品質メトリクスに従って判定され、前記品質フィードバック値に関連するタイムスタンプが、前記少なくとも１つの品質メトリクスの各々に対して対応するように規定されると共に前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づく少なくとも１つのタイムスタンプメトリクスに従って判定される、前記のサーバ（６００）が、
    前記クライアント（６０１）により前記サーバ（６００）に報告された前記品質フィードバック値、及び、前記関連するタイムスタンプを受信する手段（４００）を備えるサーバ。
24. ストリーミングサービスに用いられるプロトコルであって、少なくとも１つのメディアストリーム（１０１）がクライアント（６０１）へストリーミングされ、
    少なくとも１つの品質メトリクスと、
    前記少なくとも１つの品質メトリクスの各々に対する少なくとも１つのタイムスタンプメトリクスとを規定し、
    前記少なくとも１つのタイムスタンプメトリクスの各々が前記少なくとも１つのメディアストリーム（１０１）の相対的なメディア再生時間に基づくプロトコル。
25. 前記プロトコルが、セッション記述プロトコルＳＤＰ（１１０）と組み合わされたＲＴＳＰ（１０９）である、請求項２４に記載のプロトコル。
26. 前記プロトコルがＳＩＰである、請求項２４に記載のプロトコル。
27. 前記プロトコルがＲＴＣＰである、請求項２４に記載のプロトコル。

Images