JP2012147504A - 分類されたメディア経験の質 - Google Patents

Abstract

【課題】本発明は、ストリーミング品質の報告方法に関する。
【解決手段】少なくとも１つの連続メディアストリームが、クライアントに配信され、該配信は、該クライアントとサーバとの間で動作するプロトコルによって制御される。本発明の方法は、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスと、を選択するステップと、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づく上記ストリーミング品質を上記サーバへ報告するステップと、を具備する。上記プロトコルは、３ＧＰＰパケット交換型ストリーミングサービス（PSS）と関連して、セッション記述プロトコル（SDP）と組み合わされるリアルタイム・ストリーミングプロトコル（RTSP）が望ましい。本発明は、さらにシステム、サーバ及びプロトコル等にも関する。
【選択図】図７

Description

本発明は、ストリーミングシステム（streaming system）において、ストリーミング品質を報告するための方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバおよびプロトコルに関する。本発明のストリーミングシステムでは、少なくとも１つの連続メディアストリームが、クライアントに配信され、該配信は、該クライアントとサーバとの間で動作するプロトコルによって制御される。

オーディオストリームやビデオストリームのような同期するメディアストリームは、データネットワークを介してクライアントへ送信される間、連続して再生される。このため、ストリーミングは、クライアント内に設けられたアプリケーションの能力に言及してくる。

ストリーミングサービスにおいて最上位に位置づけできるアプリケーションに、オン・デマンドおよびライブによる情報配信アプリケーションを分類することができる。第１のカテゴリの例は、音楽およびニュース・オン・デマンド（news-on-demand）のアプリケーションである。ラジオ番組とテレビ番組のライブ配信は、第２のカテゴリの例である。

現在、固定インターネットプロトコル（ＩＰ）ネットワークを介するストリーミングは、すでに主要なアプリケーションとなっている。インターネット技術特別調査委員会（ＩＥＴＦ）およびワールドワイドウェブコンソーシアム（Ｗ３Ｃ）が、固定ＩＰストリーミングサービスで使用するプロトコルのセットを開発しているが、完全に標準化されたストリーミングの枠組みはまだ規定されていない。第３世代パートナプロジェクト（３ＧＰＰ）によって開発された標準規格に準拠する第３世代（３Ｇ）移動通信システムでは、３Ｇパケット交換用ストリーミングサービス（ＰＳＳ：Packet-switched Streaming Service、3GPP TS26.233）が、３Ｇマルチメディアメッセージサービス（ＭＭＳ）間のギャップを埋めており、例えば、ダウンロードアプリケーションおよび通話サービスの面を埋めている。

上記ＰＳＳは移動用ストリーミングアプリケーションを可能にするものではあるが、端末装置の複雑さは、対話型サービスで要求される複雑さに比べると低いものである。何故なら、端末装置では、メディア入力用デバイスとエンコーダとが必要とされないからであり、さらに複雑さが少ないプロトコルが使用できるからである。上記ＰＳＳは、ストリーミング制御プロトコル、トランスポートプロトコル、メディアコーデックおよびシーン記述プロトコルの基本セットを含む。

図１は、上記ＰＳＳのプロトコルスタック１を概略的に表現しており、上記ＰＳＳのプロトコルスタック１は、コンテンツサーバすなわちメディアサーバと、クライアントとの間で、ストリーミング可能なコンテンツとストリーミング不可能なコンテンツの双方の転送を制御する。

ビデオ、オーディオおよびスピーチのようなストリーミング可能なコンテンツ１０１は、最初に、アダプテーション層１０３においてリアルタイムトランスポートプロトコル（ＲＴＰ）１０２のペイロードフォーマットに変換される。ＩＥＴＦで規定しているようなＲＴＰが、下方に在るユーザデータグラムプロトコル（ＵＤＰ）１０４のサービスを使用して、リアルタイムデータまたはストリーミングデータを送信する手段を提供する。このとき、上記ＵＤＰ１０４は、下方に在るインターネットプロトコル（ＩＰ）１０５のサービスを、順々に使用する。

ストリーミング不可能なコンテンツ１０６、例えば、静止画、ビットマップならびにベクタグラフィックス（vector graphics）、テキスト、時間情報付テキスト（timed text）、および合成オーディオなどのコンテンツは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）１０７によって転送される。このＨＴＴＰ１０７は、下方に在るトランスポート制御プロトコル（ＴＣＰ）１０８のサービス、およびさらに下方に在るＩＰ１０５のサービスを使用する。

ストリーミング不可能なコンテンツ１０６のとき、ＨＴＴＰ１０７の組み込み型セッション設定および制御能力が、コンテンツを転送するのに十分であるのに対して、ストリーミング可能なコンテンツ１０１のとき、高度のセッション設定および制御プロトコルを呼び出す必要がある。この呼び出すのは、例えば、ＲＴＰ／ＵＤＰ／ＩＰを介してコンテンツサーバからクライアントへ転送するストリーミングビデオを起動、停止および中断を行うためである。これらの作業は、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ：Real Time Streaming Protocol）１０９によって実行されるが、このＲＴＳＰは、下方に在るＴＣＰ１０８または下方に在るＵＤＰ１０４のいずれかを使用することができる。ＲＴＳＰは、少なくともストリーミングセッションを確立するためにプレゼンテーション記述１１０を必要とする。このようなプレゼンテーション記述１１０は、例えばセッション記述プロトコル（ＳＤＰ）ファイルの形で使用することができる。このＳＤＰファイルには、セッションの記述が含まれる。含まれる記述内容は、例えばセッション名と著者名、提供するメディアタイプ、該メディアを受信するための情報で例えばアドレス、ポート、フォーマット等、およびメディアのビットレートについてである。

ストリーミングコンテンツをクライアント側で考えたとき、例えば、移動端末装置で考えたとき、この移動端末装置のユーザに、ユーザの端末装置に適した特定コンテンツのユニバーサルリソース識別子（ＵＲＩ）が第１に与えられる。このＵＲＩは、ＷＷＷサーバ、無線アプリケーション用プロトコル（ＷＡＰ）サーバから送信することもでき、あるいは、端末装置のキーボードにより手で入力させておくこともできる。このＵＲＩは、ストリーミングサーバすなわちＲＴＳＰサーバ、および当該サーバまたは別のコンテンツサーバ上のコンテンツのアドレスを特定するものである。第２に、対応するＳＤＰファイルは、多くの方法で取得することができる。ユーザがダウンロードできるＨＴＭＬページの内部にあるリンクで、例えば埋め込まれたタグを介してＳＤＰファイルを取得することもできるし、あるいは、ＵＲＩとしてこのタグをタイプして、ＳＤＰファイルを直接取得することもできる。こうして、ＳＤＰファイル、すなわちプレゼンテーション記述１１０が、図１のプロトコルスタックの中央列に示すＨＴＴＰ１０７を介して転送されてくる。上記とは別に、例えば、図１のプロトコルスタックの右列に示すＲＴＳＰ１０９のＤＥＳＣＲＩＢＥ法を使用することによって、ＲＴＳＰ１０９の信号伝達を介してＳＤＰファイルを取得することも可能である。プレゼンテーション記述が、上記ＲＴＰ１０２によって等しく良好に送信できることに留意されたい。しかし、本発明の説明を簡単にするため、上記可能な内容は図１に含めていない。

後続のセッション確立は、コンテンツサーバに対してセッションを設定するために、ブラウザまたは移動端末装置のユーザがストリーミングクライアントを呼び出す処理プロセスとなる。端末装置は、セッション確立の信号伝達の起動時にＩＰベースのパケット送信を可能にするアクティブな無線ベアラを有すると見込める。

ストリーミングサービスの後続の設定は、クライアントによって選択される個々のメディアストリーム用の「RTSP SET UP」メッセージを送信することによって実行される。この送信は、ＵＤＰ１０４及び/又はＴＣＰ１０８ポートを、それぞれのメディアストリームが使用する状態に戻す。クライアントは、「RTSP PLAY」メッセージをコンテンツサーバへ送信し、コンテンツサーバはＩＰネットワーク上に１つ以上のストリームの送信を開始する。

ＰＳＳシステムのサービスプロバイダに、エンドユーザのストリーミング経験を評価する手段を提供するために、ストリーミングサービス品質メトリクスが、ＰＳＳシステムに導入されている。この品質メトリクスは、３ＧＰＰの技術文献（Tdoc）S4-030860「草案Rel-6 PSS品質メトリクス永久ドキュメントV.0.10」に記載されており、この技術文献は３ＧＰＰのＴＳＧ−ＳＡ４会議＃２９（2003年11月24日〜28日、フィンランドのタンペールにて開催）に関連するものである。ストリーミングクライアントは、実際のストリーミングアプリケーションの品質に関する測定を行い、得られた情報をストリーミングサーバへフィードバックする。そこで、上記品質メトリクスという観点から測定結果の品質が規定される。上記ストリーミングサーバは、例えばＲＴＳＰサーバにより実現でき、上記品質メトリクスは、例えば上記ＲＴＳＰとＳＤＰとを使用することによってトランスポートすることができる。

ＲＡＮ（無線アクセスネットワーク）とＣＮ（コンピュータネットワーク）のタイプに対してサービスが透過的であるということで、ストリーミングクライアントとストリーミングサーバだけが、ＰＳＳの品質メトリクスによってインパクトを受けることになる。このインパクトに関する帰結の１つは、品質測定が、ＲＴＰ層（例えば、ＵＤＰ、ＩＰ、ＰＤＣＰ、ＲＬＣ）以下のプロトコル層からの情報に依存しないことである。

品質フィードバック情報を含むＰＳＳシステムにおける端末装置は、測定の規定に従って品質測定を実行する責任を負い、測定値をストリーミングクライアントの品質メトリクスに情報集約させ、ストリーミングサーバにこのメトリクスを報告する。上記要求処理は、ストリーミングクライアントが、ストリーミングサーバによって品質メトリクス用に処理される生の品質測定結果を、報告する可能性を排除するものではない。

ストリーミングサーバは、ストリーミングクライアントの品質メトリクス報告の起動信号の送信と、ストリーミングクライアントの品質メトリクスの収集とに責任を負うことになる。ストリーミングサーバは、集約された品質メトリクスを構築するために、受信したストリーミングクライアントの品質メトリクスを処理することもできる。例えば、生の損失パケット報告を受け取り、特定のストリーミングクライアントに対する最小値、最大値、平均値、標準パケットの損失比率を構築することもできる。

品質メトリクスを規定する目的は、コンテンツタイプ、端末装置、および無線アクセスネットワーク（ＲＡＮ）タイプの全般にわたって、一貫性のある測定値を取得することである。

制約条件は、ストリーミングサーバへ送信すべき品質メトリクスの報告サイズを最小化すること、および、端末装置での複雑さを最小化することが挙げられる。

品質メトリクスは、３つの異なるタイプに分けることができる。
第１セットの品質メトリクスは、端末装置ベースのメディア品質測定値（デコーダ内で測定されるか、またはデコーダ入力箇所で予測される値）から計算される。例えば、測定値は、データ破損持続時間（corruption duration）で規定し、データ破損して復号化されたメディア（オーディオ／スピーチ／ビデオ）の第１のフレームの開始から、後続する復号化された良好な第１のフレームの開始または報告期間の終了（のいずれか早い方）までの時間とする。ただし、フリーズ／ギャップのバッファ処理時間、フリーズ／ギャップの一時停止時間は含まないものとする。

第２セットの品質メトリクスは、一般的なＰＳＳプロトコルと、ストリーミングアプリケーションを提供するプレイヤの処理とに基づいて、端末装置よって計算される。例えば、セッションの異常終了が該当する。

第３セットの品質メトリクスは、端末装置で測定されるネットワーク特性に基づいて計算される。例えば、連続して損失するパケットの数が該当する。

既述したように、ＰＳＳシステムでは、ＲＴＳＰは、品質メトリクスによる品質報告のフィードバックのために使用される。図２ａは、ストリーミングクライアントとストリーミングサーバとの間で、品質メトリクスの協議（negotiation）を行うためのＲＴＳＰプロトコル・データユニットヘッダ２ａの「QoE-Metrics」の規定内容を記載する。図２ｂは、ＲＴＳＰプロトコル・データユニットヘッダ２ｂの「QoE-Feedback」の規定内容を記載しており、ストリーミングクライアントからストリーミングサーバへの品質メトリクスの実際のフィードバック用に使用するものであり、ＱｏＥは“経験の質（Quality of Experience）”を表す。

図２ａの協議用ヘッダ２ａは、２つの方法で使用することができる。
（１）「Off」パラメータが使用されるときだけ、これは、ストリーミングサーバまたはストリーミングクライアントのいずれかが、品質メトリクスのモニターおよび報告の取消しを要求していることを示す。
（２）ヘッダ２ａが別のパラメータを含むとき、品質メトリクスの送信開始（または、中間セッションでのモニター再開）が要求される。

協議用ヘッダ２ａを、ＲＴＳＰの「セッション制御ＵＲＬ」情報と共に使用するとき、「QoE-Metrics」がセッションレベルで使用される。ＵＲＬがＲＴＳＰの「メディア制御ＵＲＬ」であるとき、「QoE-Metrics」がメディアレベルで使用され、個々のメディアは各々の「QoE-Metrics」回線を取得する。

送信レートを設定することが要求される。「Sending-rate」値が０のとき、ストリーミングクライアントは、ストリーミングクライアントで発生するイベントに対応して、いつでもフィードバックメッセージの送信を行うことができる。「Value」の値が１以上のとき、正確なメッセージ送信間隔を示す。最短間隔は１秒に１回であり、最長間隔は規定されていない。異なるメディアに対してフィードバック送信間隔を異なるものとすることが可能であるが、アップリンク方向での余分なトラフィックを避けるために、１種類の同期状態を保持することを推奨する。「End」の値は、セッション終了時に送信する唯一のメッセージを示す。「Range」フィールドを用いて、フィードバック送信の時間制限を規定することができる。このようにして、協議段階で、モニター時間範囲を決定することができる。

実際の品質メトリクスフィードバックは、図２ｂのフィードバック用ヘッダ２ｂと一緒にＲＴＳＰの「SET PARAMETER」法を使用することによって、ＰＳＳサーバへ送信することができる。

図２ｂのフィードバック用ヘッダ２ｂでは、「Stream-url」は、フィードバックパラメータ用のＲＴＳＰセッション識別子、またはメディア制御ＵＲＬ識別子である。「Parameters」規定における「Metrics」フィールドは、メトリクス／測定値（例えば、データ破損持続時間等）の名称を含み、この「Metrics」フィールドは、協議用ＱｏＥヘッダ２ａ（「QoE-Metrics」）内のメトリクスフィールドと同一のフィールドとするべきである。メトリクスの順序は、構文解析を単純化するために、同一の順序を保持することが推奨される。「Value」フィールドは、結果を示すフィールドである。モニター期間中に、同じイベントが２回以上発生する可能性がある。２回以上発生したときは、メトリクス値が２回以上発生する可能性があり、この発生したメトリクス値が、イベント発生回数をサーバへ示すことになる。オプションの「Timestamp」は、イベント（または測定）が発生したとき、あるいはセッションの開始以来メトリクスが計算されたときの時刻を示すものである。また、（SP−スペースを使用して）イベント発生が無いことを報告することができる。オプションの「Range」は、報告周期を示す。

品質メトリクス報告は、通常ＲＴＳＰの「SET PARAMETER」法を使用して、ＰＳＳクライアントにより行われる。しかし、特別なとき、情報を運ぶのに、別の方法を使用する方が効率的である。例えば、別の方法を使用するのに、「TEARDOWN」メッセージまたは「PAUSE」メッセージがある。

上述の品質メトリクスの規定へ戻ると、データ破損持続時間を、端末装置ベースのメディア品質の測定値から計算される第１セットの品質メトリクスの代表値と規定した。上記品質メトリクス規定の依存から離れ、“データ破損”および“報告周期”についてのさらなる規定に基づけば、この品質メトリクス規定が、特に“良好なフレーム”の規定に依存するものであることは容易にわかる。

良好なフレームとは、データ破損せずに復号化されたメディア（オーディオ／スピーチ／ビデオ）のフレーム、すなわち、フリーズ／ギャップあるいは品質劣化のいずれをも含まないフレームである。ビデオフレームあるいはオーディオフレームを良好なものとして宣言するために、Tdoc S4-030860では、以下の規定を導入している。
「良好なフレームとは、最後の損失後のＮ個のフレームまたは完全なＩ−フレームのうちの時間的に早い方のどちらかのフレームである。但し、Ｎは、
（ａ）信号による送信値、または
（ｂ）デフォルト値∞（ビデオのとき）、もしくはデフォルト値１（オーディオのとき）のいずれかの値である。」

この規定の適用は必須のものではないため、この結果、良好なフレームの規定について広い範囲の解釈が生じることになる。したがって、異なるストリーミングクライアントが異なるストリーミング品質を報告することができる。何故なら、同一の品質メトリクスに対して（例えば、データ破損持続時間に対して）、“良好なフレーム”に対する異なる規定が適用されるからである。異なる端末装置が異なるエラートラッキングアルゴリズムを使用するとき、同様の曖昧さが生じ、これによって、“良好なフレーム”についての同一の規定を使用するときでさえ、同じ品質メトリクスという点から見て、報告されるストリーミング品質が端末装置間の全般として異なるものになる可能性がある。これらの曖昧さが、報告される品質メトリクスを不正確にし、実際上価値のないものとする。

ＰＳＳ：Packet-switched Streaming Service、3GPP TS26.233 Tdoc）S4-030860「草案Rel-6 PSS品質メトリクス永久ドキュメントV.0.10」３ＧＰＰのＴＳＧ−ＳＡ４会議＃２９（2003年11月24日〜28日）

上述の問題を考慮するとき、本発明の目的は、上述の問題に関して改善された方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバおよびプロトコルを提供することであり、特に、ストリーミング品質について一層有効な報告を可能にする方法等を提供することである。

本発明において、ストリーミング品質を報告する下記の方法を提案する。
ストリーミング品質を報告する方法であって、少なくとも１つの連続メディアストリームをクライアントに対して配信し、該配信を該クライアントとサーバとの間で動作するプロトコルによって制御する方法において、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスと、を選択するステップ、および、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づく上記ストリーミング品質を、上記サーバへ報告するステップを具備する。

上記少なくとも１つの連続メディアストリームは、例えば、ビデオ、オーディオあるいはスピーチ情報などを含むことができ、これらの情報は、コンテンツサーバなどのサーバから上記クライアントへ連続して送信され、端末装置に提供される。上記クライアントと上記端末装置とは、同期してセットアップされる。このストリーミングは、ストリーミングセッションで実行することができ、このとき、複数のメディアストリームを、同時に上記クライアントに配信することができる。上記ストリーミングは、プロトコルによって制御され、例えば、ＲＴＳＰのようなストリーミングプロトコルで制御される。このストリーミングプロトコルは、例えば、上記ストリーミングを起動、停止及び/又は一時停止させることができる。上記ＲＴＳＰは、上記クライアントおよび上記サーバ内のプロトコルエンティティによって動作し、ＳＤＰをベースにすることができる。上記サーバは、上記連続メディアを実際に発生させるコンテンツサーバと同じ場所に配置、または、同一のものにすることもできる。あるいは、別々のサーバにすることもできる。これらストリーミングの品質は、上記少なくとも１つの品質メトリクスに従って、例えばデータ破損継続時間またはリバッファリング（re-buffering）事象としてクライアントサイトで決定される。上記品質メトリクスクラスは、少なくとも部分的に、上記少なくとも１つの品質メトリクスをどのように決定しなければならないかを規定する。例えば、上記少なくとも１つの品質メトリクスが、上記連続メディアストリームのフレームが良好なフレームであるか否かの決定に依存するとき、上記品質メトリクスクラスは、どのようにこの決定を行わなければならないかを規定することができる。上記少なくとも２つの品質メトリクスクラスからなるセットは、予め規定されている。上記選択ステップにおいて、少なくとも上記クライアントまたは上記サーバは、例えば品質メトリクスの所定のセットの中から、少なくとも１つの品質メトリクスを選択し、また、少なくとも上記クライアントまたは上記サーバは、上記少なくとも２つの品質メトリクスクラスからなる所定のセットの中から、品質メトリクスクラスを選択する。上記所定のセットは、例えばＲＴＳＰ及び/又はＳＤＰ内で規定することもできる。上記選択ステップは、少なくとも１つの上記品質メトリクスと品質メトリクスクラスとについて、上記クライアントと上記サーバとの間での協議をさらに含むこともできる。上記協議は、上記クライアントと上記サーバとの間で、例えばＲＴＳＰおよびＳＤＰのようなプロトコルを介して行うことができる。上記少なくとも１つの選択された品質メトリクスと上記品質メトリクスクラスとに基づいて、上記クライアントは、こうして上記ストリーミングの上記品質を上記サーバへ報告する。

したがって、本発明の第１の態様によれば、追加した品質メトリクスクラスの取り込みは、品質メトリクス規定の解釈を限定し、品質報告を一層重要にしかつ一層簡潔なものにすることに貢献する。本発明の第２の態様によれば、上記追加した品質メトリクスクラスの取り込みは、品質メトリクスの規定において、追加する自由度を増す。例えば、上記連続メディアストリームのフレームが、良好なフレームかデータ破損フレームかの決定にとりわけ依存するデータ破損持続時間を、品質メトリクスとして選択したとき、この品質メトリクスは、品質メトリクスクラスの選択によってさらに特殊化することができる。この選択された品質メトリクスクラスは、例えば良好なフレームの規定に多様性を与えることができる。したがって、品質メトリクスクラスに従う良好なフレームの個々の規定が予め固定して定められるという理由で、品質メトリクス自体の簡潔さを失うことなく、品質メトリクスの適用範囲は拡張される。

本発明の方法によれば、上記品質メトリクスクラスを選択する上記ステップは、前記クライアントと上記サーバとの間で、上記品質メトリクスクラスの協議を行うステップを含むことが望ましい。また、上記協議は、上記ストリーミング配信を制御する上記プロトコルに基づき行うことができる。上記プロトコルとは、例えばＳＤＰと組み合わせたＲＴＳＰが該当する、また、上記協議は、さらに上記少なくとも１つの品質メトリクスの協議を含むこともできる。

本発明の方法によれば、上記プロトコルは、少なくとも１つのプロトコルデータユニットの内で、品質メトリクスクラス・フィールドを規定することが望ましい。このとき、上記品質メトリクスクラス・フィールドは、上記少なくとも２つの品質メトリクスクラスからなる所定のセットの個々の品質メトリクスクラスを、特定することができる。例えば、個々の品質メトリクスクラスに、固有番号を一意的に割り当てることができ、こうして上記品質メトリクスクラス・フィールドは、選択された品質メトリクスクラスの上記番号を含むことになる。同様に、上記プロトコルデータユニットは、上記少なくとも１つの選択された品質メトリクスを識別するフィールドと、上記少なくとも１つの品質メトリクスと上記品質メトリクスクラスとによって決定されたフィードバック値を伝達するフィールドと、をさらに含むことができる。上記プロトコルデータユニットは、協議用のプロトコルデータユニット、またはフィードバック用のプロトコルデータユニットのいずれかのプロトコルデータユニットにすることができる。フィードバック用プロトコルデータユニット内にフィールドを必要としないように、上記選択された品質メトリクスクラスに関する信号伝達は、協議中に十分に実施することができる。上記フィールドは、オプションのフィールドにすることもでき、あるいは上記プロトコルデータユニット内の必須フィールドにすることもできる。

本発明の方法によれば、上記品質メトリクスクラス・フィールドを、上記少なくとも１つのプロトコルデータユニットのヘッダセクションに配置することが望ましい。上記とは別に、上記品質メトリクスクラス・フィールドを、上記少なくとも１つのプロトコルデータユニットのペイロードセクションの中に含むこともできる。

本発明の方法によれば、上記少なくとも１つの選択された品質メトリクスは、上記少なくとも１つの連続メディアストリームの少なくとも１つのフレームが良好なフレームであるか否かの決定に少なくとも部分的に根拠となる経験の質（ＱｏＥ）メトリクスであることが望ましい。例えば、上記品質メトリクスは、データ破損持続時間にすることができ、このとき、上記データ破損持続時間は、データ破損フレームと次の良好なフレームとの間の時間として規定することができる。

本発明の方法によれば、上記少なくとも２つの品質メトリクスクラスからなる所定のセット内の品質メトリクスクラスの個々が、上記連続メディアストリームのフレームが良好なフレームであるか否かを決定する方法に関して、異なるセットの規則を規定することが望ましい。上記品質メトリクスクラスは、例えばエラートラッキングアルゴリズムに基づくこともでき、あるいは、復号化品質評価アルゴリズムに基づくこともできる。

本発明の方法によれば、上記品質メトリクスクラスのうちの少なくとも１つの品質メトリクスクラスによって規定される上記セットの規則が、最後のエラーレームまたは最後の損失した良好フレームの後で、上記少なくとも１つの連続メディアストリームの完全受信されたＩ−フレーム、または上記少なくとも１つの連続メディアストリームのＮ番目（整数Ｎは、信号による送信値、またはビデオフレーム用のデフォルト値∞もしくはオーディオフレーム用のデフォルト値１かのいずれか）の完全に受信したフレームのうちで、時間的に早い方のフレームを決定するステップ、および、良好なフレームの後に続く上記少なくとも１つの連続メディアストリームのフレームを完全に受信したとき、上記フレームを良好なフレームと決定し、そうでないとき、次の良好なフレームまで、上記フレームおよびすべての後続するフレームをデータ破損フレームと決定するステップを含むことが望ましい。上記Ｉ−フレームは、例えば符号化されたビデオストリーム内のフレームとして実現でき、このとき上記フレームには完全なピクセル情報が含まれる。Ｈ．２６４またはＭＰＥＧ−４のＡＶＣ（Advanced Video Coding）コーデックのとき、上記Ｉ−フレームは、ＩＤＲ−フレームを表わす。上記クライアントが、ＡＶＣビデオ用のＡＶＣ回復ポイント補助拡張機能情報（ＳＥＩ：Supplement Enhancement Information）メッセージから得られる情報などの追加情報から実際に必要なＮの値を導き出すことができるとき、この値は、信号で送信されたＮの値またはデフォルトのＮの値を無効にすることができる。上記フレームを符号化するすべてのビットが正常に受信され、ビットエラーが生じなかったとき、上記フレームは完全に受信されたと理解することができる。

本発明の方法によれば、上記品質メトリクスクラスのうちの少なくとも１つによって規定される上記セットの規則は、エラートラッキングアルゴリズムに基づいて、上記少なくとも１つの連続メディアストリームの符号化されたフレームを良好なフレームとして決定するステップを含むことが望ましい。

本発明の方法によれば、上記品質メトリクスクラスのうちの少なくとも１つによって規定される上記セットの規則が、
上記少なくとも１つの連続メディアストリームのイントラ符号化されたフレームを上記クライアント側で完全に受信したとき、上記フレームを良好なフレームと決定し、そうでないとき、上記フレームをデータ破損フレームと決定するステップ、または
上記少なくとも１つの連続メディアストリームの予測符号化フレームを上記クライアント側で完全に受信し、かつ、上記予測符号化フレームの予測参照サンプルのすべてが良好なフレームに属するとき、上記フレームを良好なフレームと決定し、そうでないとき、上記フレームをデータ破損フレームと決定するステップを含むことが望ましい。
ビデオ用の上記イントラ符号化されたフレームは、時間的動き補償予測を使用せずに、おそらくフレーム内の空間的冗長性を除去できるフレームとして理解することができ、そして、ビデオ用の上記予測符号化フレームは、ビデオフレーム間での強い相関関係をうまく利用することにより、時間的冗長性を低減する時間的動き補償予測を有するフレームとして理解できる。例えばビデオの場合、上記予測参照サンプルは、予測参照ピクセルとすることができる。

本発明の方法によれば、上記品質メトリクスクラスのうちの少なくとも１つによって規定される上記セットの規則が、復号化品質評価アルゴリズムに従って、上記少なくとも１つの連続メディアストリームの符号化されたフレームを良好なフレームと決定するステップを含むことが望ましい。

本発明の方法によれば、上記品質メトリクスクラスのうちの少なくとも１つによって規定される上記セットの規則は、
上記少なくとも１つの連続メディアストリームのイントラ符号化されたフレームを上記クライアント側で完全に受信したとき、上記フレームを良好なフレームと決定し、そうでないとき、上記フレームをデータ破損フレームと決定するステップ、または
上記少なくとも１つの連続メディアストリームの予測符号化フレームを前記クライアント側で完全に受信し、かつ、上記予測符号化フレームの予測参照サンプルのすべてが良好なフレームに属するとき、あるいは、上記フレームの少なくとも一部を完全に受信し、例えば、ビデオ用の参照ピクセルなどの、上記フレームの上記完全に受信した部分のすべての予測参照サンプルが良好なフレームに属し、かつ、上記フレームのすべての隠蔽された部分が良好と見なされるとき、上記フレームを良好なフレームと決定するステップを含み、
上記フレームの復号化された損失部分またはエラー部分に、エラー隠蔽アルゴリズムを適用することによって、上記フレームの隠蔽された部分を取得し、かつ、上記フレームの上記隠蔽された部分と上記フレームの完全に受信し復号化された周辺部分との間の平均境界誤差が閾値未満であるとき、上記隠蔽された部分を良好とみなすことが望ましい。例えば、上記隠蔽アルゴリズムは、上記ピクセルの空間的及び/又は時間的隣接部分に基づいて、損失ピクセルまたはエラーピクセルを再構成する推定処理を含むことができる。上記平均境界誤差は、隠蔽された部分のエッジにおけるピクセル間の輝度の差の合計を定量化することができる。上記閾値は、例えば３に等しい値にすることができる。

本発明の方法によれば、上記プロトコルが、第３世代移動通信システムのパケット交換型ストリーミングサービスＰＳＳと関連して、セッション記述プロトコルＳＤＰと組み合わされるリアルタイム・ストリーミングプロトコルＲＴＳＰであることが望ましい。上記ＳＤＰは、例えば上記ストリーミング配信を制御するために、ＲＴＳＰで必要とされるプレゼンテーション記述を提供することができる。

本発明の方法によれば、上記ＳＤＰは、少なくとも１つの品質メトリクスクラス・フィールドを規定する少なくとも１つのＳＤＰ属性を含み、上記品質メトリクスクラス・フィールドは、上記所定のセットの少なくとも２つの品質メトリクスクラスの個々の品質メトリクスクラスを特定する能力を有することが望ましい。例えば、個々の品質メトリクスクラスに固有番号を一意的に割り当てることもでき、このとき上記品質メトリクスクラス・フィールドは、選択された品質メトリクスクラスの該固有番号を含むことになる。同様に、上記ＳＤＰ属性は、上記少なくとも１つの選択した品質メトリクスを識別するためのフィールドをさらに含むことができる。

本発明の方法によれば、少なくとも部分的に上記ＳＤＰ属性に基づいて上記クライアントと上記サーバとの間で品質メトリクスクラスの協議を行うために、上記ＲＴＳＰを使用することが望ましい。例えば、品質メトリクスおよび品質メトリクスクラスとの協議を開始するために、ＳＤＰを使用することができる。このために、協議を開始するために使用されるＳＤＰ属性に上記フィールドを追加することは好都合である。

本発明の方法によれば、上記ＲＴＳＰは上記協議のためのＤＥＳＣＲＩＢＥ法を使用することが望ましい。上記協議は、例えば上記ＳＤＰ属性に連結させて上記ＲＴＳＰのＤＥＳＣＲＩＢＥ法を使用することによって、開始することができる。

上述の方法ステップをプロセッサが実行できるような動作可能な命令を有するコンピュータプログラムをさらに提案する。上記コンピュータプログラムは、例えば、上記クライアントまたは上記サーバのいずれかに組み込まれたプロセッサで実行することができる。

上述の方法ステップをプロセッサが実行できるような動作可能な命令を有するコンピュータプログラムを含むコンピュータプログラム製品をさらに提案する。

さらに、少なくとも１つのクライアントと、少なくとも１つのサーバとを具備するストリーミングシステムを提案する。上記ストリーミングシステムにおいて、少なくとも１つの連続メディアストリームを、上記少なくとも１つのクライアントに配信し、該配信は、上記少なくとも１つのクライアントと上記少なくとも１つのサーバとの間で動作するプロトコルによって制御され、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスとを選択し、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づく上記ストリーミング品質を、上記少なくとも１つのサーバへ報告する。

さらに、ストリーミングシステムにおけるクライアントを提案する。上記クライアントは、上記クライアントに対する少なくとも１つの連続メディアストリームの配信を制御するプロトコルを動作させる手段と、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスとを選択する手段と、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づく上記ストリーミング品質を、サーバへ報告する手段と、を具備する。

さらに、ストリーミングシステムにおけるサーバを提案する。クライアントに少なくとも１つの連続メディアストリームの配信を制御するプロトコルを動作させる手段と、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスとを選択する手段と、上記クライアントからの上記ストリーミングに関する品質報告を受信する手段と、を具備するサーバであって、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づき、上記品質が報告される。

さらに、ストリーミングシステム用プロトコルを提案する。上記プロトコルは、クライアントに少なくとも１つの連続メディアストリームの配信を制御するための規則と、少なくとも１つの品質メトリクスおよび少なくとも２つの品質メトリクスクラスからなるセットの規定と、少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる上記セットから品質メトリクスクラスとを選択するための規則と、上記少なくとも１つの選択された品質メトリクスと上記選択された品質メトリクスクラスとに基づく上記ストリーミング品質をサーバへ報告を行うための規則と、を含む。上記プロトコルは例えば、３ＧのＰＳＳシステムとの関連においてＳＤＰと組み合わされるＲＴＳＰにすることができる。

本発明の上記態様ならびにその他の態様が、本明細書で後述する実施形態から明らかになり、上記実施形態と関連して解明される。

従来技術によるパケット交換型ストリーミングサービス（ＰＳＳ）プロトコルスタックの概略を表す図である。 従来技術によるリアルタイム・ストリーミングプロトコル（ＲＴＳＰ）の協議ヘッダを規定する図である。 従来技術によるＲＴＳＰフィードバック用ヘッダを規定する図である。 本発明による修正されたＲＴＳＰの協議用ヘッダを規定する図である。 本発明によるエラー隠蔽アルゴリズムの例示的マクロブロック（ＭＢ）の状態マップである。 本発明による平均境界誤差の計算方法の一例を示す図である。 本発明の方法によるフローチャートである。 本発明によるシステムの概略を表す図である。

本発明に関して、図１のプロトコルスタックおよび図２ｂに規定するようなフィードバック用ＲＴＳＰヘッダが、未だ使用される。しかし、修正された協議用ＲＴＳＰヘッダ３が規定され、この規定例を図３に記載する。

図３の修正された協議用ＲＴＳＰヘッダ３は、追加のＲＴＳＰフィールド「Metrics-class」を提供し、このＲＴＳＰフィールドは、値“０”、“１”または“２”のいずれかの値を持つことができる。

したがって、ストリーミングクライアントとストリーミングサーバとの間での協議において、図３の修正された協議用ＲＴＳＰヘッダ３の「Metrics」ＲＴＳＰフィールドを使用することによって、ストリーミングクライアントの後続する品質フィードバックで使用される品質メトリクスが、同意されるだけでなく、「Metrics-class」ＲＴＳＰフィールドを使用することによって、上記品質メトリクスクラスについても協議される。

ＱｏＥメトリクス協議を開始するためにＳＤＰを使用するとき、ＱｏＥ協議の開始に使用するＳＤＰ属性に、「Metrics-class」フィールドを追加することもできる。

本発明は、ストリーミングクライアントに流れる連続したメディアストリームのフレームが、良好なフレームであるか（否のとき、これらのフレームはデータ破損フレームと見なす）を判断するための３つの異なる方法を提案する。提案する方法の各々は、「Metrics-class」ＲＴＳＰフィールドに割り当てができる“０”、“１”および“２”のうちの１つの値によって、一意に特定される。品質メトリクスは、フレームが良好なフレームであるかデータ破損フレームであるかの決定に、少なくとも部分的に根拠になるものと仮定すると、例えば、品質メトリクスがデータ破損持続時間であるとき、品質メトリクスの全体な情報内容は、選択された品質メトリクスクラスに準拠する判定方法に従うので、一層簡潔でかつ有効なものとなる。さらに、品質メトリクスの特殊化が達成される。何故なら、良好なフレーム決定に少なくとも部分的にベースとなった品質メトリクスが、ここで３つの品質メトリクスに分けられ、個々の品質メトリクスは、異なる良好なフレームの判定方法を有することになるからである。

この後の説明で、本発明により提案される３つの判定方法について解説する。

第１の判定方法
第１の方法は、Tdoc S4-030860で開示された方法に類似する方法であり、いくつかの改善を図る修正が含まれる。この方法を、以下に記述する。
良好なフレームは、下記のうちの時間的に早い方のフレームである。
１）完全に受信されたＩ−フレーム（Ｈ．２６４またはＭＰＥＧ−４のＡＶＣビデオ、ＩＤＲ−フレーム）、または、
２）最後のエラーまたは損失の後で、Ｎ番目に完全受信されたフレーム、但しＮは、信号による送信値、またはデフォルト値の∞（ビデオ用）か１（オーディオ用）のいずれかの値である。
クライアントが、追加情報から必要とするＮの値を導き出すことができれば、追加情報の値によって上記特定値は無効にされる。追加情報とは、例えばＡＶＣビデオ用のＡＶＣ回復ポイント補助拡張機能情報（ＳＥＩ：Supplement Enhancement Information）メッセージから得られる情報である。”完全に受信された”ということは、すべてのビットが受信され、ビットエラーが発生しなかったことを意味する。

良好なフレームに後続するフレームが完全に受信されたとき、このフレームは良好なフレームである。そうでないとき、問題のフレーム（このフレームは含む）から次の良好なフレーム（このフレームは除く）まで後続する全フレームが、データ破損したフレームである。

第２の判定方法
第２の方法は、エラートラッキングアルゴリズムの適用を特徴とする方法である。第２の方法の１つの可能な実施形態を以下に記述する。
イントラ符号化されたフレームのとき、このフレームが完全に受信されたとき、受信フレームは良好なフレームである。そうでないとき、受信フレームはデータ破損フレームである。

予測符号化フレームのとき、このフレームが完全に受信され、かつ、このフレームの予測参照サンプルのすべてが良好なフレームに属すれば、受信フレームは良好なフレームはである。そうでないとき、受信フレームはデータ破損フレームである。

第３の判定方法
第３の方法は、特定の復号化品質評価アルゴリズムの適用を特徴とする方法である。第３の判定方法の可能な実施形態を以下に記述する。

第３の方法の事例は、少なくとも部分的に予測符号化フレームの損失部分またはエラー部分の隠蔽に基づく。したがって、予測符号化フレームのエラー隠蔽戦略に適用する挿入語句（parenthesis）は、第３の方法のインスタンスのプレゼンテーションに先行させる必要がある。

フレームのエラー部分または不完全部分は、復号化されずに復号化前に破棄されると仮定する。したがって整合性のチェックやビットエラー検出は実行されない。第一に、画像の正常に受信されたすべての部分が復号化され、第二に、損失部分は隠蔽される。実際、記録はフレームの状態マップをベースとしたマクロブロック（ＭＢ：macroblock）に保持される。ＭＢが存在する部分が、復号化に使用可能なときはいつでも、この状態マップ内のＭＢの状態は“正常受信”状態であり、そうでないとき“損失”状態である。フレームが復号化された後、状態マップが“損失”ＭＢを含むとき、隠蔽処理が開始される。

フレームの正常受信部分と損失部分との構造、ならびに、フレームのＭＢベースの状態マップが与えられれば、適用される隠蔽アルゴリズムはＭＢベースのアルゴリズムになる。状態マップ内で“損失”とマークされたＭＢによってカバーされる損失フレーム領域（ピクセル領域）は、隠蔽されたＭＢ×ＭＢ（１６×１６Ｙピクセル、８×８Ｕ、Ｖピクセル）とする。このとき、Ｙは輝度を意味し、ＵとＶとはクロミナンスピクセルを意味する。ＭＢは、隠蔽された後は、“隠蔽済み”として状態マップの中にマークされる。“損失”ＭＢのすぐ隣接した部分に“正常受信”隣接部分が存在しないときはいつでも、“正常受信”ＭＢだけでなく“隠蔽済み”ＭＢも、隠蔽処理時に信頼性の高い隣接ＭＢとして処理される。このようなとき、隠蔽に失敗したＭＢの結果が、いくつかの隣接する隠蔽されたＭＢへ、この隠蔽ミスの伝播が発生するときがある。したがって、“損失”ＭＢが隠蔽される順序が重要となる。この隠蔽処理はフレーム境界におけるＭＢの列から開始され、次いで、列毎に内側へ移行する。この処理順序は、フレームの“困難な”中心部（不連続な動き領域、大きな符号化された予測誤差）で通常発生する典型的な隠蔽ミスが、フレームの“簡単な”部分（連続する動き領域、いくつかのフレームにわたる類似する動き）へ伝播するのを防ぐのに役立つ。

図４は、隠蔽フェーズにある状態マップのスナップショットを示す。この状態マップでは、既に隠蔽されたＭＢ４０２は、“隠蔽済み”の状態を有し、正常に受信されたＭＢ４０３は“正常受信”の状態を有し、損失したＭＢ４００は、“損失”状態を有し、現在処理中（隠蔽される）のＭＢ４０１は“現在のＭＢ”としてマークされる。図４は、さらに隠蔽されたＭＢ４０２または損失ＭＢ４００だけから、構成することができる損失部分４０４を示す。

少なくとも２つのこのようなＭＢが使用可能なとき、“正常受信”の隣接ＭＢ４０３のみが、隠蔽用として使用される。さもなければ、隣接する“隠蔽済み”のＭＢ４０２は平均化処理で、また使用される。

ピクセル領域で直接処理を行う代わりに、さらに効率のよいアプローチとして、何らかの予測方式によって、隣接部分の空間的または時間的に使用可能な動き情報から、損失ピクセル領域（ＭＢ）４００内の動きを“推測する”試みがある。このとき、この“推測された”動きベクトル（ＭＶ：Motion Vector）は、参照フレームを使用する動き補償用に使用される。

コピーされたピクセル値が、隠蔽用の最終の再構成ピクセル値を与え、追加のピクセル領域の処理が、使用されることはない。

最新画像の正常受信部分（正常受信されたＭＢ４０３のグループ）の動きの活発性が、最初に調査される。平均的ＭＶが所定の閾値（一般に、個々のＭＶ要素に対して１／４ピクセル分）よりも小さいとき、参照フレーム内の空間的に対応する位置からコピーすることによって、すべての損失部分４０４は隠蔽される。そうでないとき、動き補償用エラー隠蔽処理が使用され、損失ＭＢ４００のＭＶは、以下の段落で記載するように予測される。

“損失”ＭＢ４００の動きは、統計的観測に依拠する空間的隣接ＭＢの動きから予測され、空間的に隣接するフレーム領域の動きに対しては非常に強い相関関係がある。例えば、動く前景シーンのオブジェクトによってカバーされるフレーム領域で、ＭＶフィールドは連続しており、連続していることは、予測が簡単に行えることを意味する。

“損失”ＭＢ４００のＭＶは、隣接するＭＢのうちの１つのＭＢ（すなわち８×８ブロック）から予測される。このアプローチは、隣接するＭＢ（すなわちブロック）のうちの１つのＭＢが、現在のＭＢ内の動きを良好にモデルにしていると仮定する。従来の試みで、隣接するすべてのＭＶの中央値または平均値では、良い結果が得られなかったことが判明している。説明を簡潔にするために、現在の実施構成では、個々に予測用として考慮する最小の隣接するブロックのサイズを、８×８Ｙピクセルのセットとする。任意の８×８ブロックの動きを、４×４のブロックまたは別の形状（例えば、４×８）のブロックに対応する空間での動きの平均値として計算する。

隣接するＭＶの中で、どのＭＶを現在のＭＢ５００の予測用として使用するかの決定は、隠蔽された（再構成された）部分の滑らかさに基づいて行われる。この決定については、図５を参照しながら説明する。この試行処理手順の中で、ＭＢ５００の隠蔽ピクセル値は、個々の候補（動き補償ピクセル値）のＭＶ５０１ａ〜ＭＶ５０１ｄを用いて計算される。ブロック５００がフレーム内の場所の中へ挿入されるとき、ブロック境界５０２ａ〜５０２ｄの全般にわたって最小輝度変化が生ずるＭＶ５０１ａ〜ＭＶ５０１ｄが、選択される。ＭＶがゼロの場合については常に考慮され、このコピーされた隠蔽値（参照フレーム内の空間的に対応するＭＢから得られるコピーピクセル値）は、他のＭＶ候補値と類似と評価される。

成功した予測ＭＶとは、サイドマッチ歪みｄ_smを最小化するＭＶで、サイドマッチ歪みｄ_smは_、ＩＮ−ブロック５０３と現在のブロック５００の５０２ａ〜５０２ｄ境界で隣接するＯＵＴ−ブロック５０４ピクセルとの絶対Ｙピクセル値の差の合計である。該当する予測式を（数式１）として示す。

ただし、（項Ａ）は、ＭＶを予測するために、ｍｖ_dirを使用したＩＮ−ブロック５０３におけるｊ番目の隠蔽されたＹ値であり、（項Ｂ）は、ＯＵＴ−ブロック５０４内のｊ番目の再構成されたＹ値であり、Ｎは計算に使用した境界ピクセルの総数である。

“正常受信”の隣接ＭＢ４０３が存在するとき、サイドマッチ歪みは、“正常受信”の隣接ＭＢ４０３だけで計算される。そうでないとき、“隠蔽済み”隣接ＭＢ４０２が計算の中に含まれる。

次に、第３の方法の可能な実施形態については、以下のように記述できる。
イントラ符号化されたフレームのとき、このフレームが完全に受信されたとき、受信フレームは良好なフレームである。そうでないとき、受信フレームはデータ破損フレームである。

予測符号化フレームのとき：
ａ）予測符号化フレームが、完全に／正常に受信され、かつ、すべての予測符号化フレームの予測参照サンプルが良好なフレームに属するとき、この予測符号化フレームは良好なフレームである。
ｂ）フレームの少なくとも一部が完全に／正常に受信され、かつ、この完全に／正常受信された部分の予測参照サンプルが良好なフレームに属するとき、このフレームは、下記のステップｃを使用して判断される。そうでないとき、このフレームはデータ破損している。
ｃ）フレームが復号化され、損失部分またはエラー部分が上述のエラー隠蔽アルゴリズムを用いて隠蔽される。隠蔽された部分と、完全／正常に受信されかつ復号化された囲まれた部分との間の平均境界誤差、すなわち数式（１）のサイドマッチ歪みが、閾値よりも小さければ、上記隠蔽された部分は良好と見なされる。すべての隠蔽された部分が良好であるとき、フレームは良好なフレームである。そうでないとき、フレームはデータ破損している。

上記方法での閾値は、例えば３に等しい値に選択することができる。

図６は本発明によるストリーミング品質を報告する方法を示すフローチャートである。ここでの方法でのステップは、ストリーミングサーバ６００とストリーミングクライアント６０１との間で交換される要求と確認応答とを表し、この要求と確認応答は、ＲＴＳＰによって行われる。さらに、この方法でのステップが、協議用ステップ６０２とフィードバック用ステップ６０３とに分類できることは容易に理解できる。

品質メトリクスの協議は、ストリーミングクライアント６０１の「DESCRIBE」要求６０４に対するストリーミングサーバ６００の応答６０５から開始される。この応答６０５の中において、今後の品質報告のためにストリーミングサーバ６００が要求するような少なくとも１つの品質メトリクスと品質メトリクスクラスとが、セッション記述プロトコル（ＳＤＰ）データにより組み込まれる。ストリーミングクライアント６０１が品質メトリクスをサポートするとき、ストリーミングクライアント６０１は、「SET UP」要求６０６を送信することになる。この「SET UP」要求６０６は、セッションレベルまたはメディアレベルの選択／修正された品質メトリクスおよび品質メトリクスクラスを含んでおり、各々のレベルが送信によりセットアップされる。

ストリーミングクライアント６０１が、セッションレベルとメディアレベルとの両レベルの品質メトリクスをサポートしていることを示すために、クライアントは、メディアレベルに関するすべてのサポート／修正された品質メトリクスを送信することができる。また、クライアントは、少なくとも１つの「SET UP」要求時に、選択されたセッションレベルの品質メトリクスを送信することができる。上記「SET UP」要求６０６のときに、クライアントは、サーバ６００の応答６０５の中に含まれる初期のＳＤＰ記述と比較して、制御ＵＲＬの品質メトリクスの送信レートのみを修正する。

この「SET UP」要求６０６を受信すると、ストリーミングサーバ６００は、ストリーミングクライアント６０１から返送された品質メトリクスおよび品質メトリクスクラスの受諾を含む「200 OK」応答６０７を、（変更を再確認するために）返送する。また、ストリーミングサーバ６００は、ストリーミングクライアント６０１が行う変更を拒絶することができる。ストリーミングサーバ６００が変更を拒絶するとき、ストリーミングサーバ６００は、新規の値をセットするか、または修正した品質メトリクスと修正したメトリクスクラスとをストリーミングクライアント６０１へ再返送するかのいずれかを行うことができる。あるいは、ストリーミングサーバ６００は、単に品質メトリクスおよび品質メトリクスクラスを無視し、これらの再確認を行わないこともできる。

ストリーミングサーバ６００が、ストリーミングクライアント６０１が行った修正を承認しないとき、ストリーミングサーバ６００とストリーミングクライアント６０１とは、再協議を続行することができる。ＲＴＳＰの「PLAY要求」６０８とストリーミングサーバ６００のＲＴＳＰのプレイ応答６０９とが、セッションレベルとメディアレベルのすべてのメトリクス値を含む最終合意の品質メトリクスおよび品質メトリクスクラスを返送するまで、続行することができる。

こうして、協議された品質メトリクスと品質メトリクスクラスとに従って、実際のフィードバックは、少なくとも１つのステップ６１０で実行され、例えば、図２ｂで規定するようなＲＴＳＰフィードバックのヘッダ２ｂに基づき実行される。

「QoE-Metrics」ヘッダフィールドが、ＲＴＳＰ要求で送信される度に、この特別な要求に対応する応答のときにも、「QoE-Metrics」ヘッダフィールドを存在させるべきことに留意されたい。こうしないと、この応答の受信側は、相手側の端部が品質メトリクスをサポートしていないと推測する。同様な方法が、「QoE-Metrics-Class」ヘッダフィールドについても適用することができる。

図７は、本発明によるシステムの機能コンポーネントを概略的に示す。ＰＳＳシステムは、ストリーミングクライアント６０１とストリーミングサーバ６００とを具備する。これらクライアント６０１とサーバ６００の双方は、少なくとも１つのＲＴＳＰエンティティ７０１、７００を有し、各エンティティはＲＴＳＰを動作させることができる。ＲＴＳＰエンティティ７００、７０１は、さらに別のプロトコルエンティティによって実行される下部に在るプロトコル層のサービスを使用する。これら別のプロトコルエンティティのうち、ＴＣＰ／ＵＤＰエンティティ７０２、７０３およびＩＰエンティティ７０４、７０５のみを、図７に表示する。ストリーミングクライアント６０１は、ストリーミング品質モニターインスタンス７０７とさらに接続される。このストリーミング品質モニターインスタンス７０７は、協議された品質メトリクスと品質メトリクスクラスとの観点から、実際のストリーミングアプリケーションの品質をモニターし、モニターした品質値を上記ＲＴＳＰエンティティ７０１に入力する。例えば、上記ストリーミングクライアントのセットアップが、端末装置によって実施できれば、上記ストリーミング品質モニターは、端末装置によって実現することができる。ＲＴＳＰを介して、モニターした上記品質値は、ストリーミングサーバ６００内のＲＴＳＰピアエンティティへ転送され、ここで、モニターした上記品質値は、評価および分析用として品質データ処理インスタンス７０６に入力される。上記評価および分析は、例えば、リバッファリング事象が頻繁に発生することが判明したとき、ストリーミングアプリケーションのデータレートを高めることによって、ストリーミングアプリケーションの品質改善を意図することもできる。

以上の推奨実施形態によって、本発明について説明した。当業者にとっては明らかな代替方法および変更例が存在すること、ならびに、添付の請求項の範囲および精神から逸脱することなく、これらの代替方法および変更例の実施が可能であることに留意されたい。特に、品質メトリクスクラスは、少なくとも部分的に一層厳密に、良好なフレームの決定に根拠となる任意の品質メトリクスの規定を与えるのに使用することができ、また同時に、上記品質メトリクスの特殊化を可能にすることができる。例えば、品質メトリクスクラスは、データ破損現象のもとで理解すべきことについての種々の規定を与えることができ、あるいは、異なるレベルのフレームデータ破損の規定を与えることもできる。このとき、これらの規定は、データ破損の規定に少なくとも部分的に依存する品質メトリクスと組み合わせて、さらに簡潔となるストリーミング品質報告を可能にする。本発明の範囲は決して、第３世代移動通信システムでの適用に限定されるものではない。別の様々な無線ストリーミングシステムならびに有線ストリーミングシステムへの適用も、予測することが可能である。

Claims (21)

1. ストリーミング品質を報告する方法であって、少なくとも１つの連続メディアストリームをクライアント（６０１）に対して配信し、該配信を該クライアント（６０１）とサーバ（６００）との間で動作するプロトコル（１０９）によって制御する方法において、
   少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスと、を選択するステップ（６０２）と、
   前記少なくとも１つの選択された品質メトリクスと前記選択された品質メトリクスクラスとに基づく前記ストリーミング品質を、前記サーバ（６００）へ報告するステップ（６０３）と、を具備する方法。
2. 前記品質メトリクスクラスを選択する前記ステップ（６０２）が、前記クライアント（６０１）と前記サーバ（６００）との間で、前記品質メトリクスクラスを協議するステップ（６０５〜６０９）を含む請求項１に記載の方法。
3. 前記プロトコル（１０９）が、前記プロトコルの少なくとも１つのプロトコルデータユニット内で品質メトリクスクラス・フィールドを規定し、該品質メトリクスクラス・フィールドは、前記少なくとも２つの品質メトリクスクラスからなる所定のセット内の個々の品質メトリクスクラスを特定することができる請求項１〜２のいずれか一項に記載の方法。
4. 前記品質メトリクスクラス・フィールドが、前記少なくとも１つのプロトコルデータユニットのヘッダセクション（３）に配置される請求項３に記載の方法。
5. 前記少なくとも１つの選択された品質メトリクスが、前記少なくとも１つの連続メディアストリームの少なくとも１つのフレームが良好なフレームか否かの決定に、少なくとも部分的に根拠となる経験の質（ＱｏＥ）メトリクスである請求項１〜４のいずれか一項に記載の方法。
6. 前記少なくとも２つの品質メトリクスクラスからなる所定のセット内の個々の品質メトリクスクラスが、前記少なくとも１つの連続メディアストリームのフレームが良好なフレームか否かを決定する方法に関する異なるセットの規則を規定する請求項５に記載の方法。
7. 前記品質メトリクスクラスのうちの少なくとも１つによって規定される前記セットの規則が、
   前記少なくとも１つの連続メディアストリームを完全に受信したＩ−フレーム、または
   エラーまたは損失の最後のフレームの後、前記少なくとも１つの連続メディアストリームのＮ番目（整数Ｎは、信号による送信値、または、ビデオフレームのときは∞の値もしくはオーディオフレームのときは１の値のデフォルト値のいずれかの値）に完全受信したフレーム、のうちの時間的に早い方のフレームを、良好なフレームと決定するステップと、
   良好なフレームの後に続く前記少なくとも１つの連続メディアストリームのフレームが完全に受信されたとき、該フレームを良好なフレームと決定し、そうでないとき、次の良好なフレームまで、該フレームおよび後続するすべてのフレームを破損フレームと決定するステップと、を含む請求項６に記載の方法。
8. 前記品質メトリクスクラスのうちの少なくとも１つによって規定される前記セットの規則が、エラートラッキングアルゴリズムに従って、前記少なくとも１つの連続メディアストリームの符号化されたフレームを良好なフレームと決定するステップを含む請求項６に記載の方法。
9. 前記品質メトリクスクラスのうちの少なくとも１つによって規定される前記セットの規則が、
   前記少なくとも１つの連続メディアストリームのイントラ符号化されたフレームを前記クライアント側で完全に受信したとき、該フレームを良好なフレームと決定し、そうでないとき、該フレームを破損フレームと決定するステップ、または
   前記少なくとも１つの連続メディアストリームの予測符号化フレームを前記クライアント側で完全に受信し、かつ、上記予測符号化フレームの予測参照サンプルのすべてが良好なフレームに属するとき、該フレームを良好なフレームと決定し、そうでないとき、該フレームを破損フレームと決定するステップを含む請求項８に記載の方法。
10. 前記品質メトリクスクラスのうちの少なくとも１つによって規定される前記セットの規則が、
    復号化品質評価アルゴリズムに従って、前記少なくとも１つの連続メディアストリームの符号化されたフレームを良好なフレームと決定するステップを含む請求項６に記載の方法。
11. 前記品質メトリクスクラスのうちの少なくとも１つによって規定される前記セットの規則が、
    前記少なくとも１つの連続メディアストリームのイントラ符号化されたフレームを前記クライアント側で完全に受信したとき、前記フレームを良好なフレームと決定し、そうでないとき、破損フレームと決定するステップ、または
    前記少なくとも１つの連続メディアストリームの予測符号化フレームを前記クライアント側で完全に受信し、かつ、上記予測符号化フレームの予測参照サンプルのすべてが良好なフレームに属するとき、あるいは、
    前記フレームの少なくとも一部（４０３）が完全に受信され、前記フレームの該完全に受信された部分のすべての予測参照サンプルが良好なフレームに属し、かつ、前記フレームのすべての隠蔽された部分（４０２）が良好とみなされるとき、前記フレームを良好なフレームと決定するテップを含む方法であって、
    前記フレームの復号化バージョンの損失部分やエラー部分（４００、４０４）にエラー隠蔽アルゴリズムを適用することによって、前記フレームの隠蔽された部分（４０２）を取得し、前記フレームの前記隠蔽された部分（４０２、５０３）と前記フレームの完全受信された周辺部分（４０３、５０４）で復号化された部分との間（５０２ａ−ｄ）の平均境界誤差が、閾値未満であるとき、前記隠蔽された部分（４０３）を良好とみなす請求項１０に記載の方法。
12. 前記プロトコル（１０９）が、第３世代移動通信システムのパケット交換型ストリーミングサービスＰＳＳと関連して、セッション記述プロトコルＳＤＰ（１１０）と組み合わされるリアルタイム・ストリーミングプロトコルＲＴＳＰ（１０９）である請求項１〜１１のいずれかに一項に記載の方法。
13. 前記セッション記述プロトコルＳＤＰ（１１０）は、少なくとも１つの品質メトリクスクラス・フィールドを規定する少なくとも１つのＳＤＰ属性を含み、該品質メトリクスクラス・フィールドは、前記少なくとも２つの品質メトリクスクラスからなる所定のセットの個々の品質メトリクスクラスを特定できる請求項１２に記載の方法。
14. 少なくとも部分的に前記ＳＤＰ属性に基づいて、前記クライアント（６０１）と前記サーバ（６００）との間で品質メトリクスクラスを協議するために、前記ＲＴＳＰ（１０９）が使用される請求項１３に記載の方法。
15. 前記ＲＴＳＰ（１０９）が、前記協議用としてＤＥＳＣＲＩＢＥ法を使用する請求項１４に記載の方法。
16. 請求項１〜１５の方法ステップをプロセッサに実行させるように動作できる命令を有するコンピュータプログラム。
17. 請求項１〜１５の方法ステップをプロセッサに実行させるように動作できる命令を有するコンピュータプログラムを含むコンピュータプログラム製品。
18. 少なくとも１つのクライアント（６０１）と、少なくとも１つのサーバ（６００）と、を具備するストリーミングシステムであって、
    少なくとも１つの連続メディアストリームを、前記少なくとも１つのクライアント（６０１）に対して配信し、該配信を、前記少なくとも１つのクライアント（６０１）と前記少なくとも１つのサーバ（６００）との間で動作するプロトコル（１０９）によって制御し、
    少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスと、を選択し、
    前記少なくとも１つの選択された品質メトリクスと前記選択された品質メトリクスクラスとに基づく前記ストリーミング品質を、前記少なくとも１つのサーバ（６００）へ報告するシステム。
19. ストリーミングシステムにおけるクライアント（６０１）であって、
    前記クライアント（６０１）に対する少なくとも１つの連続メディアストリームの配信を制御するプロトコル（１０９）を動作させる手段（７０１）と、
    少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定のセットから品質メトリクスクラスと、を選択する手段（７０１）と、
    前記少なくとも１つの選択された品質メトリクスと前記選択された品質メトリクスクラスとに基づく前記ストリーミング品質を、サーバ（６００）へ報告する手段（７０１）と、を具備するクライアント。
20. ストリーミングシステムにおけるサーバ（６００）であって、
    クライアント（６０１）に対する少なくとも１つの連続メディアストリームの配信を制御するプロトコル（１０９）を動作させる手段（７００）と、
    少なくとも１つの品質メトリクスと、少なくとも２つの品質メトリクスクラスからなる所定セットから品質メトリクスクラスと、を選択する手段（７００）と、
    前記クライアント（６０１）からの前記ストリーミングに関する品質報告を受信する手段（７００、７０６）と、を具備するサーバにおいて、
    前記品質が、前記少なくとも１つの選択された品質メトリクスと前記選択された品質メトリクスクラスとに基づき報告されるサーバ。
21. ストリーミングシステム用プロトコル（１０９）であって、
    クライアント（６０１）に対する少なくとも１つの連続メディアストリームの配信を制御するための規則と、
    少なくとも１つの品質メトリクスおよび少なくとも２つの品質メトリクスクラスからなるセットの規定と、
    少なくとも１つの品質メトリクスと、前記少なくとも２つの品質メトリクスクラスからなるセットから品質メトリクスクラスと、を選択するための規則と、
    前記少なくとも１つの選択された品質メトリクスと前記選択された品質メトリクスクラスとに基づく前記ストリーミング品質をサーバ（６００）へ報告するための規則と、を含むプロトコル。

Images