(57)【要約】  少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングするストリーミングサービスにおける品質フィードバックのための方法を提示する。該方法は、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定するステップと、前記品質フィードバック値をサーバへ報告するステップとを有し、前記所定の品質メトリックの組には、前記少なくとも１つのメディアストリームの前記再生のうちの少なくとも１つの再生に関係する品質メトリックと、前記少なくとも１つのメディアストリームの中に含まれている少なくとも２つのタイプのフレーム内の１つの破損とが含まれる。システム、クライアント、サーバ、コンピュータプログラム、コンピュータプログラム製品及び品質フィードバック用プロトコルも提示する。
2007536859.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングサービスにおいて品質フィードバックを行う方法であって、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングし、前記方法が、
所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定し、前記所定の品質メトリックの組が、
前記少なくとも１つのメディアストリームの前記再生と、
前記少なくとも１つのメディアストリームに含まれる少なくとも２つのタイプのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含むステップと、
前記品質フィードバック値をサーバへ報告するステップと、を有する方法。
【請求項２】
前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックが、前記少なくとも１つのメディアストリームの前記再生の再生フレームレートの所定値からの偏差に関係するフレームレート偏差メトリックである請求項１に記載の方法。
【請求項３】
前記フレームレート偏差メトリックが前記偏差の継続時間にさらに関係する請求項２に記載の方法。
【請求項４】
前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックが、前記少なくとも１つのメディアストリームの前記再生の再生時間とスケジュールされた再生時間との間の差が所定値よりも大きくなった場合に発生するジッタイベントの継続時間に関係するジッタ継続時間メトリックである請求項１に記載の方法。
【請求項５】
前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックが、値Ａと値Ｂとの間の絶対差が所定値よりも大きくなった場合に発生する同期はずれイベントの継続時間に関係する同期はずれ継続時間メトリックであり、前記値Ａが、前記少なくとも１つのメディアストリームの第１のメディアストリームの最後に再生されたフレームの再生時間と、前記少なくとも１つのメディアストリームの第２のメディアストリームの最後に再生されたフレームの再生時間との間の差であり、前記値Ｂが、前記少なくとも１つのメディアストリームの前記第１のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間と、前記少なくとも１つのメディアストリームの前記第２のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間との間の差である請求項１に記載の方法。
【請求項６】
前記少なくとも１つのメディアストリームの中に含まれている前記少なくとも２つのタイプのフレーム内の１つがシーンカットフレームであり、前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損に関係する前記品質メトリックが、前記少なくとも１つのメディアストリーム内の破損シーンカットフレーム数に関係する破損シーンカットフレーム数メトリックである請求項１に記載の方法。
【請求項７】
前記品質メトリックをタイムスタンプと共に報告する請求項１に記載の方法。
【請求項８】
前記フレームレート偏差メトリックをタイムスタンプと共に報告し、前記タイムスタンプが、品質報告期間の開始時間に対する前記偏差中最初に再生されたフレームの再生時間に等しい請求項２に記載の方法。
【請求項９】
前記ジッタ継続時間メトリックをタイムスタンプと共に報告し、前記タイムスタンプが、品質報告期間の開始時間に対する前記ジッタイベント中最初に再生されたフレームの再生時間に等しい請求項４に記載の方法。
【請求項１０】
前記同期はずれ継続時間メトリックをタイムスタンプと共に報告し、前記タイムスタンプが、品質報告期間の開始時間に対する前記同期はずれイベント中最初に再生されたフレームの再生時間に等しい請求項５に記載の方法。
【請求項１１】
前記再生時間がNormal Play Time ＮＰＴである請求項８に記載の方法。
【請求項１２】
前記所定の品質メトリックの組が、破損継続時間に関係する破損継続時間メトリックを含み、前記継続時間の方が所定値よりも大きい場合にだけ、前記破損継続時間メトリックに従って決定された前記品質フィードバック値を報告する請求項１に記載の方法。
【請求項１３】
リアルタイムトランスポートプロトコルＲＴＰに基づいて前記少なくとも１つのメディアストリームの前記ストリーミングを行う請求項１に記載の方法。
【請求項１４】
リアルタイムストリーミングプロトコルＲＴＳＰによって少なくとも部分的に前記ストリーミングを制御する請求項１に記載の方法。
【請求項１５】
前記ＲＴＳＰを介して前記品質フィードバック値を前記サーバへ報告する請求項１４に記載の方法。
【請求項１６】
前記ストリーミングサービスが、３Ｇ移動体通信システムにおけるパケット交換型ストリーミングサービスＰＳＳである請求項１に記載の方法。
【請求項１７】
請求項１の方法ステップをプロセッサに実行させるように動作可能な命令を備えたコンピュータプログラム。
【請求項１８】
請求項１の方法ステップをプロセッサに実行させるように動作可能な命令を備えたコンピュータプログラムを含むコンピュータプログラム製品。
【請求項１９】
ストリーミングサービスにおける品質フィードバックのためのシステムであって、
少なくとも１つのサーバと、
少なくとも１つのクライアントとを備え、少なくとも１つのメディアストリームを再生用として前記少なくとも１つのクライアントへストリーミングし、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定し、前記所定の品質メトリックの組が、
前記少なくとも１つのメディアストリームの前記再生と、
前記少なくとも１つのメディアストリームに含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含み、前記品質フィードバック値を前記少なくとも１つのサーバへ報告するシステム。
【請求項２０】
ストリーミングサービスにおけるクライアントであって、
再生用として前記クライアントへストリーミングされる少なくとも１つのメディアストリームを受信する手段と、
所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定する手段であって、前記所定の品質メトリックの組が、
前記少なくとも１つのメディアストリームの前記再生と、
前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含む手段と、
前記品質フィードバック値をサーバへ報告する手段とを備えるクライアント。
【請求項２１】
ストリーミングサービスにおけるサーバであって、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングし、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定し、前記所定の品質メトリックの組が、
前記少なくとも１つのメディアストリームの前記再生と、
前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含み、前記サーバが、
前記クライアントが前記サーバへ報告する前記品質フィードバック値を受信する手段を備えるサーバ。
【請求項２２】
ストリーミングサービスにおいて使用するプロトコルであって、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングし、前記プロトコルが、
前記少なくとも１つのメディアストリームの前記再生と、
前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを定義するプロトコル。
【請求項２３】
前記プロトコルがセッション記述プロトコルＳＤＰと組み合わされたＲＴＳＰである請求項２１に記載のプロトコル。
【請求項２４】
前記再生時間がNormal Play Time ＮＰＴである請求項９に記載の方法。
【請求項２５】
前記再生時間がNormal Play Time ＮＰＴである請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングサービスにおける品質フィードバックのための、方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバ及びプロトコルに関し、少なくとも１つのメディアストリームが再生用としてクライアントへストリーミングされる。
【背景技術】
【０００２】
一方で、ストリーミングは、音声、オーディオ及びビデオストリームのような同期メディアストリームの再生を、データネットワークを介してこれらのストリームをクライアントへ送信しながら連続して行うために、クライアント側に設けられているアプリケーションの能力を指す。他方で、ストリーミングはまた、会話型アプリケーションのようなリアルタイム低遅延アプリケーションも指す。
【０００３】
ストリーミングサービスの上に構成することが可能なアプリケーションは、オン・デマンド情報配信アプリケーションとライブ情報配信アプリケーションとに分類することができる。第１のカテゴリの例として音楽及びニュースアプリケーションがある。ラジオ番組及びテレビ番組のライブ配信は、第２のカテゴリの例である。リアルタイム低遅延アプリケーションとしては、例えば、マルチメディア（テレビ）電話又はＩＰ電話及び任意のタイプの会話型マルチメディアアプリケーションなどがある。
【０００４】
固定インターネットプロトコル（ＩＰ）ネットワークを介するストリーミングはすでに主要なアプリケーションとなっている。インターネット技術特別調査委員会（ＩＥＴＦ）と、ワールドワイドウェブコンソーシアム（Ｗ３Ｃ）とが、固定ＩＰストリーミングサービスで使用される１組のプロトコルを開発しているが、完全な標準化ストリーミングフレームワークはまだ規定されていない。第３世代パートナプロジェクト（３ＧＰＰ）によって開発された規格に準拠する第３世代（３Ｇ）移動体通信システムの場合、３Ｇパケット交換型ストリーミングサービス（ＰＳＳ、３ＧＰＰ  ＴＳ２６.２３３、ＴＳ２６.２３４）は、例えば、ダウンロード型アプリケーション及びマルチメディアコンテンツなどの３Ｇマルチメディア・メッセージサービス（ＭＭＳ）と通話サービス及びストリーミングサービスと間のギャップを満たすものである。
【０００５】
ＰＳＳによって、移動体ストリーミングアプリケーションが可能となり、端末装置の複雑さは会話型サービスに必要な複雑さに比べて少なくなる。というのは、メディア入力装置及びエンコーダが必要でなくなり、さらに、複雑さの少ないプロトコルを利用できるからである。ＰＳＳには、ストリーミング制御プロトコルと、トランスポートプロトコルと、メディアコーデックと、シーン記述プロトコルとの基本的組合せが含まれる。
【０００６】
図１は、コンテンツサーバすなわちメディアサーバと、クライアントとの間での、ストリーミング可能コンテンツとストリーミング不能コンテンツ双方の転送を制御するＰＳＳプロトコルスタックを概略的に描く図である。
【０００７】
ビデオ、オーディオ及び音声のようなストリーミング可能コンテンツ１０１は、アダプテーション層１０３のリアルタイムトランスポートプロトコル（ＲＴＰ）１０２のペイロードフォーマットへまず変換される。ＩＥＴＦによって規定されているような前記ＲＴＰは、下位のユーザデータグラムプロトコル（ＵＤＰ）１０４のサービスを利用することによって、リアルタイムデータ又はストリーミングデータの送信手段を提供するものであり、ＵＤＰは、次いで、下位のＩＰプロトコル１０５のサービスを利用する。
【０００８】
ストリーミング不能コンテンツ１０６は、例えば、ストリーミングを目的として制作されていないマルチメディアコンテンツ（端末装置に記録されるＭＭＳクリップなど）、静止画像、ビットマップ図形及びベクトル図形、テキスト、時間指定テキスト（timed text）並びに合成オーディオとして、ハイパーテキスト転送プロトコル（ＨＴＴＰ）１０７によって転送される。上記ハイパーテキスト転送プロトコルは、下位のトランスポート制御プロトコル（ＴＣＰ）１０８及びさらに下位のＩＰ１０５のサービスを利用する。
【０００９】
ストリーミング不能コンテンツ１０６の場合、ＨＴＴＰ１０７の組込型セッションの設定機能と、制御機能とがコンテンツを転送するのに十分なものであるのに対して、ストリーミング可能コンテンツ１０１の場合、例えば、ＲＴＰ／ＵＤＰ／ＩＰを介してコンテントサーバからクライアントへ転送されるストリーミングビデオの開始、停止及び一時停止を行うために、高度のセッションの設定と制御プロトコルとを呼び出す必要がある。このタスクは、リアルタイムストリーミングプロトコル（ＲＴＳＰ）１０９により実行され、このリアルタイムストリーミングプロトコルは下位のＴＣＰ１０８か、下位のＵＤＰ１０４かのいずれかを利用することが可能である。ＲＴＳＰは、少なくともストリーミングセッションを設定するためにプレゼンテーション記述１１０を必要とする。このようなプレゼンテーション記述１１０は、例えば、セッション記述プロトコル（ＳＤＰ）ファイルの形で利用可能なものにすることも可能である。前記ＳＤＰファイルには、例えば、セッション名及び著者、提示すべきメディアタイプ、例えば、アドレス、ポート、フォーマット等々の前記メディアを受信するための情報、並びにメディアのビットレートなどのセッション記述が含まれる。
【００１０】
例えば、移動端末装置などのクライアント側でストリーミングコンテンツを視聴する場合、前記端末装置のユーザには、自分の端末装置に適合する特定のコンテンツに対応するユニバーサルリソース識別子（ＵＲＩ）がまず与えられる。このＵＲＩは、ＷＷＷサーバ又は無線アプリケーションプロトコル（ＷＡＰ）サーバから得たものであってもよく、若しくは、端末装置のキーボードを介して手で入力したものであってもよい。このＵＲＩはストリーミングサーバすなわちＲＴＳＰサーバと、当該サーバ又は別のコンテントサーバのコンテンツのアドレスとを指定するものである。次いでいくつかの方法で対応するＳＤＰファイルを得ることも可能である。ユーザがダウンロードするＨＴＭＬページ中のリンクで、例えば埋め込みタグを介して、このＳＤＰファイルを得ることも可能であるし、又はＵＲＩとしてリンクをタイプすることによりこのＳＤＰファイルを直接得ることも可能である。次いで、図１のプロトコルスタックの中央列に示すように、ＳＤＰファイルすなわちプレゼンテーション記述１１０はＨＴＴＰ１０７を介して転送される。代替として、ＳＤＰファイルは、例えば、図１のプロトコルスタックの右列に示すように、ＲＴＳＰ１０９のＤＥＳＣＲＩＢＥメソッドによってＲＴＳＰ１０９シグナリングを介して取得してもよい。プレゼンテーション記述は前記ＲＴＰ１０２によって同様に良好に送信することも可能であることに留意されたい。しかし、表示を簡略にするために、上記可能性は図１には含まれていない。
【００１１】
後続するセッション確立は、移動端末装置のブラウザ又はユーザが、コンテントサーバに対してセッションを設定するためにストリーミングクライアントを呼び出す処理プロセスである。端末装置はセッション確立シグナリングの開始時に、ＩＰベースのパケット送信を可能にする活性な無線ベアラを有するものと予想されている。
【００１２】
クライアントが選択した個々のメディアストリームのためのＲＴＳＰ  ＳＥＴＵＰメッセージを送信することによってストリーミングサービスの次の設定が行われる。この設定は、それぞれのメディアストリーム用として利用すべきＵＤＰ１０４及び／又はＴＣＰ１０８ポートを返す。クライアントはコンテントサーバへＲＴＳＰ  ＰＬＡＹメッセージを送信し、コンテントサーバは次いでＩＰネットワークを介して１以上のストリームの送信を開始する。
【００１３】
３ＧＰＰ技術文献（Ｔｄｏｃ）Ｓ４−０４００７３：“ドラフトＲｅ１−６ＰＳＳ品質メトリックパーマネントドキュメントｖ．０．１１”に記載されているように、エンドユーザのストリーミング体験を評価する手段をＰＳＳシステムのプロバイダに提供するために、ＰＳＳシステムではストリーミングサービス品質メトリックが導入されている。上記３ＧＰＰ技術文献（Ｔｄｏｃ）Ｓ４−０４００７３は３ＧＰＰ  ＴＳＧ−ＳＡ４会議＃３０（２００４年２月２３〜２７日、スペインのマラガで開催）に関係するものである。ストリーミングクライアントは、実際のストリーミングアプリケーションの品質（体験の品質、ＱｏＥ）に関する情報を測定し、ストリーミングサーバへこの情報をフィードバックし、ここで前記品質は前記品質メトリックによって規定される。前記ストリーミングサーバは、例えばＲＴＳＰサーバであってもよく、前記品質メトリックは、例えば前記ＲＴＳＰとＳＤＰとを利用して転送してもよい。
【００１４】
サービスはＲＡＮ及びＣＮのタイプに対して透過的なものであるため、ストリーミングクライアント及びストリーミングサーバだけがＰＳＳ品質メトリックによってインパクトを受けることになる。上記の１つの結果として、測定は、ＲＴＰ層より下にあるプロトコル層（ＵＤＰ、ＩＰ、ＰＤＣＰ、ＳＮＤＣＰ、ＬＬＣ、ＲＬＣ、ＭＡＣ、物理層など）から得られる情報に頼ることができない。
【００１５】
品質フィードバックを有するＰＳＳシステムの端末装置は、測定規定に基づいて品質測定を実行し、品質測定値をストリーミングクライアント品質メトリックに集約し、ストリーミングサーバへメトリックを報告する役割を果たすものである。この要件は、ストリーミングサーバにより処理されて品質メトリックの中へとり込まれる生の品質測定値についてストリーミングクライアントが報告を行う可能性を除外するものではない。
【００１６】
ストリーミングサーバは、ストリーミングクライアントの品質メトリック報告の活性化を通知し、ストリーミングクライアントの品質メトリックを収集する役割を果たすものである。ストリーミングサーバは受信したストリーミングクライアント品質メトリックを処理して、集約された品質メトリックを作成することも可能である。例えば、ストリーミングサーバは、生の損失パケットについての報告を受信して、特定ストリーミングクライアントのパケット損失率の最小値、最大値、平均値及び標準偏差値を作成する場合も考えられる。
【００１７】
以下の４つの品質メトリックがＴｄｏｃ  Ｓ４−０４００７３によって規定されている。
【００１８】
破損継続時間
破損継続時間とは、最初の破損フレームから、最初の後続する良好なフレーム又は報告期間の終了（いずれか時間的に早い方）までの時間である。上記メトリックの単位は秒で表現され、分数値となる場合がある。
【００１９】
再バッファリング継続時間
このメトリックは、オーディオ、ビデオ及び音声だけに適用可能であり、別のメディアタイプに対しては適用できない。上記メトリックの単位は秒で表現され、分数値となる場合がある。再バッファリングは、クライアント側で何らかの非任意イベントに起因して生じる再生時の任意の機能停止として規定される。
【００２０】
初期バッファリング時間
初期バッファリングとは、最初のＲＴＰパケットの受信から再生が開始するまでの時間である。上記メトリックの単位は秒で表現され、分数値となる場合がある。
【００２１】
連続して損失したコンテンツパケット数
メディアチャネル当たりの連続して損失したコンテンツパケットの数。
【００２２】
上記品質メトリック規定の目的は、コンテンツタイプと、端末装置と、無線アクセスネットワーク（ＲＡＮ）のタイプとにわたって一貫性のある測定値を取得することである。
【００２３】
制約として、ストリーミングサーバへ送信する品質メトリック報告のサイズ及び端末装置の複雑さの最小化がある。
【００２４】
図２に描かれているように（ＩＥＴＦコメント要求（ＲＦＣ）ドキュメント２３２７を参照しながら）フィードバックヘッダ２を伴うＲＴＳＰのＳＥＴ_ＰＡＲＡＭＥＴＥＲメソッドを利用することによって、実際の品質メトリックフィードバック情報をＰＳＳサーバへ送信することが可能であるが、特定のケースでは、例えば、ＴＥＡＲＤＯＷＮメッセージ又はＰＡＵＳＥメッセージとして情報を搬送する別の方法を利用する方がさらに効率的である。
【００２５】
図２のフィードバックヘッダでは、ｓｔｒｅａｍ−ｕｒｌは、フィードバックパラメータ用のＲＴＳＰセッション又はメディア制御ＵＲＬ識別子である。Ｐａｒａｍｅｔｅｒｓ定義内のＭｅｔｒｉｃｓフィールドは、（例えば破損継続時間などの）メトリック／測定名を含む。Ｖａｕｌｅフィールドはこれらの結果を示す。同じイベントが監視期間中に２回以上発生する可能性がある。その場合メトリック値が２回以上生じる可能性があり、該メトリック値はサーバに対してこのイベント数を示す。オプションのＲａｎｇｅフィールドは報告期間を示すフィールドである。
【００２６】
図２のフィードバックヘッダ内のオプションのＴｉｍｅｓｔａｍｐフィールドは、イベント（すなわち測定）が発生した時間、すなわちセッションの開始以降メトリックが計算された時間を示す。
【００２７】
Ｔｄｏｃ  Ｓ４−０４００７３によって規定されている４つの品質メトリックは、ユーザが体験するようなマルチメディアストリームの再生品質のおおまかな特性分析を可能にするものにすぎない。例えば、２つのストリーミングセッションが、Ｔｄｏｃ  Ｓ４−０４００７３によって規定されている４つの品質メトリックについて同じ値を有している場合であって、前記セッションの第１のセッションではオーディオデータとビデオデータとの間に完全な同期が存在しているのに対して、前記セッションの第２のセッションではオーディオとビデオ間の同期が失われた場合、Ｔｄｏｃ  Ｓ４−０４００７３によって規定されている４つの品質メトリックに基づいて報告される品質は同じものでありながら、実際に体験される再生品質はきわめて異なったものとなる。さらに、Ｔｄｏｃ  Ｓ４−０４００７３によって規定されている４つの品質メトリックは、前記マルチメディアストリームの中に含まれている異なるフレームタイプを区別するものではなく、そのため、例えば、品質の報告の際に、再生品質にとって不可欠な重要性を持つフレームタイプの損失と、重要性の小さいフレームタイプの損失とを区別することができない。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
上述の問題に鑑み、ストリーミングサービスにおける改善された品質フィードバックを可能にする方法、コンピュータプログラム、コンピュータプログラム製品、システム、クライアント、サーバ及びプロトコルを提供することが、特に、本発明の目的である。
【課題を解決するための手段】
【００２９】
ストリーミングサービスにおける品質フィードバックのための方法を提案し、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングする。前記方法は、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定するステップを有し、前記所定の品質メトリックの組は、前記少なくとも１つのメディアストリームの前記再生と、前記少なくとも１つのメディアストリームの中に含まれている少なくとも２つのタイプのフレーム内の１つの破損とのうち少なくとも１つに関係する品質メトリックを含み、さらに、前記方法は前記品質フィードバック値をサーバへ報告するステップを有する。
【００３０】
前記少なくとも１つのメディアストリームは、例えば、コンテントサーバなどのサーバから連続して前記クライアントへ送信され、前記クライアントが設定されている端末装置で同期して再生されるビデオ、オーディオ又は音声情報を含むことが可能な連続するメディアストリームなどであってもよい。代替として、前記少なくとも１つのメディアストリームは、例えば、マルチメディア（テレビ）電話ストリーム又はＩＰ電話メディアストリームのようなリアルタイムの低遅延アプリケーションのメディアストリーム、若しくは会話型マルチメディアアプリケーションにおける任意のタイプのメディアストリームであってもよい。このストリーミングは、前記クライアントへいくつかのメディアストリームを同時にストリームすることも可能なストリーミングセッションにおいて行われる場合もある。前記ストリーミングは、例えばリアルタイムトランスポートプロトコルＲＴＰなどのプロトコルに基づくものであってもよく、さらに、例えばリアルタイムストリーミングプロトコルＲＴＳＰ又はセッション開始プロトコルＳＩＰのようなストリーミングプロトコルなどの別のプロトコルによって制御可能であり、例えばストリーミングの開始、停止及び／又は一時停止を行うことも可能である。前記ＲＴＳＰ又はＳＩＰは、前記クライアントにおいて、及び前記サーバにおいてプロトコルエンティティにより動作させることが可能であり、セッション記述プロトコルＳＤＰに基づくものであってもよい。前記サーバは、実際に前記メディアの発生元であるコンテントサーバと同じ場所に配置されるものであってもよいし、又は、同一のサーバですらよく、若しくは別のインスタンスであってもよい。
【００３１】
前記ストリーミングの品質は、前記所定の品質メトリックの組のうち前記少なくとも１つの品質メトリックに従ってクライアント側サイトで決定され、例えば、ストリーミングのベースとなる前記プロトコル、すなわち、ストリーミングを制御する前記プロトコルを介して品質フィードバック値として報告される。前記品質メトリックは、前記品質フィードバック値の計算方法を基本的に規定する。前記所定の品質メトリックの組は、ストリーミングを制御する前記プロトコルによって規定することも可能であり、さらに前記少なくとも１つの品質メトリックは、セッション設定の前、途中、又は後でも前記クライアントと前記サーバ間でネゴシエーションが行われる。
【００３２】
前記品質フィードバック値は、例えば、ストリーミングのベースとなる前記プロトコルを介して、すなわち、ストリーミングを制御する前記プロトコルを介して前記サーバへ報告される。前記ストリーミングを制御する前記プロトコルがＲＴＣＰ又はＳＩＰである場合、品質測定のために前記報告された品質フィードバック値を、例えば、呼状態制御機能ＣＳＣＦのようなネットワークエンティティなどのエンティティによって捕捉したり、傍受したりすることが望ましい場合がある。
【００３３】
本発明によれば、品質フィードバックを改善するために、前記所定の品質メトリックの組には、前記少なくとも１つのメディアストリームの前記再生に関係する品質メトリック、及び／又は前記少なくとも１つのメディアストリームの中に含まれている少なくとも２つのタイプのフレーム内の１つの破損に関係する品質メトリックが含まれる。前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックは、例えば、前記再生の実際の再生フレームレートの所定値からの偏差、若しくは実際の再生時間とスケジュールされた再生時間との間の差、若しくはオーディオフレーム又は音声フレームと対応するビデオフレームとの間の再生同期はずれに関するものであってもよい。前記少なくとも１つのメディアストリームの中に含まれている少なくとも２つのタイプのフレーム内の１つの破損に関係する前記品質メトリックは、例えば、再生について体験した品質にとって非常に本質的である場合もある、ビデオストリームのシーンカットフレームの破損に関する場合もある。
【００３４】
このようにして、本発明による再生及び／又は特定タイプのフレームの破損と関係する品質メトリックの組み込みは品質フィードバックの改善を可能にする。
【００３５】
本発明の推奨実施例によれば、前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックは、前記少なくとも１つのメディアストリームの前記再生の再生フレームレートの所定値からの偏差に関係するフレームレート偏差メトリックである。一連のフレームから構成することが可能な前記少なくとも１つのメディアストリームの再生を行うとき、前記フレームを再生するフレームレートは、前記再生用として所望の又は最適なフレームレートとは等しくない場合もある。したがって、偏差のような報告を行うことが有益となる。前記所定値はサーバとクライアントとの双方又は上記双方のうちの一方だけに既知のデフォルト値であってもよい。前記所定値は、例えば最適な再生フレームレートとなる場合もある。前記フレームレート偏差メトリックはさらに、前記偏差イベントの継続時間に関係するものであってもよい。
【００３６】
本発明の推奨実施例によれば、前記少なくとも１つのメディアストリームの前記再生に関連する前記品質メトリックは、前記少なくとも１つのメディアストリームの前記再生の再生時間と、スケジュールされた再生時間との間の差が所定値よりも大きいときに発生するジッタイベントの継続時間に関係するジッタ継続時間メトリックである。前記所定値はサーバとクライアントとの双方又は上記双方のうちの一方だけに既知のデフォルト値であってもよい。前記再生時間は、例えば、Normal Play Time（ＮＰＴ）又は壁時計の時間などのクライアント側の任意のほかの時間系で測定が可能な実際の再生時間を示すものである。各種時間系は、（値０を有する）異なる起源と単位とを持ってもよい。個々のメディアフレームはスケジュールされた再生時間と関連づけられ、該再生時間は、例えば、リアルタイム送信プロトコル（ＲＴＰ）のタイムスタンプを用いて通知してもよい。しかし、ネットワーク遅延のような理由に起因して、メディアフレームがスケジュールされた再生時間に正確に再生されず、再生時間とスケジュールされた再生時間とが異なる場合がある。
【００３７】
本発明の推奨実施例によれば、前記少なくとも１つのメディアストリームの前記再生に関係する前記品質メトリックが、値Ａと値Ｂとの間の絶対差が所定値よりも大きい場合に発生する同期はずれイベントの継続時間に関係する同期はずれ継続時間メトリックであり、前記値Ａは、前記少なくとも１つのメディアストリームの第１のメディアストリームの最後に再生されたフレームの再生時間と、前記少なくとも１つのメディアストリームの第２のメディアストリームの最後に再生されたフレームの再生時間との間の差であり、前記値Ｂは、前記少なくとも１つのメディアストリームの前記第１のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間と、前記少なくとも１つのメディアストリームの前記第２のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間との間の差である。前記第１のメディアストリームは、例えばオーディオストリーム又は音声ストリームであってもよく、前記第２のメディアストリームは、例えばビデオストリームであってもよい。再生がビデオストリームと音声／オーディオストリームとの同期再生を指す場合、画像と、対応する音声／オーディオとの同期欠如は、ユーザをいらだたせる場合もあるため、前記サーバへ報告することが重要である。前記所定値は、サーバとクライアントとの双方又は上記双方のうちの一方だけに既知のデフォルト値であってもよい。
【００３８】
本発明の推奨実施例によれば、前記少なくとも１つのメディアストリームの中に含まれている前記少なくとも２つのタイプのフレーム内の１つがシーンカットフレームであり、前記少なくとも１つのメディアストリームの中に含まれている少なくとも２つのタイプのフレームの中の１つの破損に関係する前記品質メトリックが、前記少なくとも１つのメディアストリーム内の破損シーンカットフレーム数に関係する破損シーンカットフレーム数メトリックである。したがって、前記他のタイプのフレームは、例えば、コンテンツ内の前のフレームと類似の正常なコンテンツフレームであってもよい。したがって、再生品質に特別の重要性を有する可能性のあるシーンカットフレームの破損に関しては、個別に報告を行うようにすることも可能である。前記シーンカットフレームは、例えばビデオストリーム内のシーンの切替を示してもよく、前記シーンカットフレームに関係する情報はサーバ側で利用可能となる場合もあり、若しくはサーバ側又はクライアント側で該シーンカットフレームを導き出すようにしてもよく、さらに、帯域内又は帯域外で、クライアントへ前記情報を通知するようにしてもよい。
【００３９】
本発明の推奨実施例によれば、前記品質メトリックはタイムスタンプと共に報告される。前記タイムスタンプは例えば、前記品質メトリックに従って記述される発生イベントの絶対時間インスタンスや相対時間インスタンスを示すものであってもよい。
【００４０】
本発明の推奨実施例によれば、前記フレームレート偏差メトリックをタイムスタンプと共に報告し、前記タイムスタンプは、品質報告期間の開始時間に対する、前記偏差の継続時間中最初に再生されたフレームの再生時間に等しい。前記再生時間は、例えばＮＰＴとして表してもよい。
【００４１】
本発明の推奨実施例によれば、前記ジッタ継続時間メトリックをタイムスタンプと共に報告し、前記タイムスタンプは、品質報告期間の開始時間に対する、前記ジッタイベント中最初に再生されたフレームの再生時間に等しい。前記再生時間は、例えばＮＰＴとして表してもよい。
【００４２】
本発明の推奨実施例によれば、前記同期はずれ継続時間メトリックをタイムスタンプと共に報告し、前記タイムスタンプは、品質報告期間の開始時間に対する、前記同期はずれイベント中最初に再生されたフレームの再生時間に等しい。前記再生時間は、例えばＮＰＴとして表してもよい。
【００４３】
本発明の推奨実施例によれば、前記再生時間はNormal Play Time ＮＰＴである。前記ＮＰＴは、例えばリアルタイムストリーミングプロトコルＲＴＳＰによって与えられてもよい。ＮＰＴによって前記再生時間を規定することにより、クライアント及びサーバによるタイムスタンプの解釈の際に曖昧さが取り除かれ、それによって、ストリーミング品質体験の正しい分析が可能になる。
【００４４】
本発明の推奨実施例によれば、前記所定の品質メトリックの組には、破損継続時間に関係する破損継続時間メトリックが含まれ、前記継続時間の方が所定値よりも大きい場合だけ、前記破損継続時間メトリックに従って決定された前記品質フィードバック値が報告される。再生中、たとえ短期間に単一フレーム又は２、３のフレームが再生されなくても、エンドユーザは一般にその違いを知覚することはできない。受信端末装置は、例えば、以下の理由のうちの１つ理由に基づいてフレームを再生しないように決定してもよい。何らかの理由によって非参照フレームがサーバから送信されなかった；非参照フレームが部分的に又は全体的に損失している；非参照フレームは完全に受信されているが、この非参照フレームを正確に復号できない；非参照フレームは完全に受信されているが、遅延又は計算能力不足に起因してこの非参照フレームが復号されない；参照フレーム又は非参照フレームは完全に受信され、正確に復号されるが、そのスケジュールされた表示時間が過ぎている。短期間内のこのようなフレームの非再生はユーザ体験に影響を与えるものではなく、したがって、短期間のこのようなフレームの報告は送信帯域幅を浪費するものとなる。したがって、本発明の推奨実施例によれば、破損持続時間が前記所定値を上回ったときにだけ、この破損持続時間の報告を行うことが提案される。該所定値は、例えば、サーバ及び／又はクライアントによって設定されたデフォルト値であってもよいし、又は、プロトコルによって規定された値であってもよい。
【００４５】
本発明の推奨実施例によれば、前記少なくとも１つのメディアストリームはリアルタイムトランスポートプロトコルＲＴＰに基づく。前記ＲＴＰは前記クライアントとコンテントサーバとの間で動作することができ、ユーザデータグラムプロトコルＵＤＰのサービスを利用することができる。次いで、該ユーザデータグラムプロトコルＵＤＰは、インターネットプロトコルＩＰのサービスを利用することができる。
【００４６】
本発明の推奨実施例によれば、前記ストリーミングは、リアルタイムストリーミングプロトコルＲＴＳＰによって少なくとも部分的に制御される。前記ＲＴＳＰは、セッション記述プロトコルＳＤＰによって与えられるプレゼンテーション記述に基づくものであってもよい。前記ＲＴＳＰは前記クライアントと前記サーバとによって運用されてもよく、例えばストリーミングの開始、一時停止及び停止を行うことが可能である。
【００４７】
本発明の推奨実施例によれば、前記品質フィードバック値は前記ＲＴＳＰを介して前記サーバへ報告される。前記品質フィードバック値は、例えばＲＴＳＰプロトコルデータユニットのヘッダに含めてもよい。
【００４８】
本発明の推奨実施例によれば、前記ストリーミングサービスは、３Ｇ移動体通信システムにおけるパケット交換型ストリーミングサービスＰＳＳである。
【００４９】
上述の方法ステップをプロセッサに実行させるように動作可能な命令を備えたコンピュータプログラムがさらに提案される。前記コンピュータプログラムは、例えば前記クライアントのプロセッサ上で動作してもよい。
【００５０】
上述の方法ステップをプロセッサに実行させるように動作可能な命令を備えたコンピュータプログラムを含むコンピュータプログラム製品がさらに提案される。前記コンピュータプログラム製品は、例えば、ＲＯＭ又はＲＡＭのようなメモリに格納したり、若しくはメモリカード、メモリスティック（登録商標）、ディスク、ＣＤ又は類似の媒体のような着脱可能媒体に格納したりすることも可能であり、さらに、前記クライアント側に配置されているプロセッサの内部メモリの中へロードすることも可能である。
【００５１】
ストリーミングサービスにおける品質フィードバックのためのシステムであって、少なくとも１つのサーバと、少なくとも１つのクライアントとを備え、少なくとも１つのメディアストリームを再生用として前記少なくとも１つのクライアントへストリーミングし、所定の品質メトリックの組から得られる品質フィードバック値を少なくとも１つの品質メトリックに従って決定し、前記所定の品質メトリックの組が、前記少なくとも１つのメディアストリームの前記再生と、前記少なくとも１つのメディアストリームに含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含み、前記品質フィードバック値を前記少なくとも１つのサーバへ報告するシステムがさらに提案される。
【００５２】
ストリーミングサービスにおけるクライアントであって、再生用として前記クライアントへストリーミングされる少なくとも１つのメディアストリームを受信する手段と、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定する手段であって、前記所定の品質メトリックの組が、前記少なくとも１つのメディアストリームの前記再生と、前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含む手段と、前記品質フィードバック値をサーバへ報告する手段とを備えるクライアントがさらに提案される。
【００５３】
ストリーミングサービスにおけるサーバであって、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングし、所定の品質メトリックの組のうち少なくとも１つの品質メトリックに従って品質フィードバック値を決定し、前記所定の品質メトリックの組が、前記少なくとも１つのメディアストリームの前記再生と、前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを含み、前記サーバが、前記クライアントが前記サーバへ報告する前記品質フィードバック値を受信する手段を備えるサーバがさらに提案される。
【００５４】
ストリーミングサービスにおいて使用するプロトコルであって、少なくとも１つのメディアストリームを再生用としてクライアントへストリーミングし、前記プロトコルが、前記少なくとも１つのメディアストリームの前記再生と、前記少なくとも１つのメディアストリームの中に含まれる少なくとも２つのタイプのフレームのうち１つの破損とのうちの少なくとも一方に関係する品質メトリックを定義するプロトコルがさらに提案される。前記プロトコルセッションは記述プロトコルＳＤＰと組み合わされたＲＴＳＰであってもよい。
【００５５】
本発明の上記局面並びにその他の局面は、本明細書で後述する実施例から明らかにされ、該実施例を参照しながら解明される。
【発明を実施するための最良の形態】
【００５６】
本発明は、品質フィードバックを改善するためにストリーミングサービス用の品質フィードバックに利用する特別の品質メトリックを提案する。以下、この提案された品質メトリックと、この品質メトリックに関連づけられたタイムスタンプとについてさらに詳細に説明する。
【００５７】
フレームレート偏差
この品質メトリックは、オーディオ、ビデオ及び音声用にだけ適用可能であり、他のメディアタイプに対しては適用できない。この品質メトリックは再生フレームレートに関する情報を与える。再生フレームレートが所定値から逸脱したとき、フレームレート偏差が生じる。この品質メトリックは、イベントの継続時間と、フレームレートの偏差値すなわち、所定のフレームレートと実際の再生フレームレートとの間の差との双方を含むものであってもよい。継続時間は秒で表現され、分数値となる場合がある。上記偏差値は毎秒当たりフレーム数の単位で表現することも可能であり、やはり分数値になる場合がある。
【００５８】
前記所定値は、サーバ及びクライアント双方に既知のデフォルト値でもよいし、又は、ＱｏＥネゴシエーション中にサーバによって提供されるものでもよい。サーバが上記所定値を提供する場合、サーバはメディアビットストリームをチェックすることにより、又は、ほかの任意の手段によってこの値を決定してもよい。
【００５９】
上記値が、メディアストリームをローカルに再生する場合の計算された平均フレームレートを示すと都合が良い場合がある。
【００６０】
実装という点から見て、フレームレートを計算するために以下の方法を指定することも可能である。フレームレートは整数秒でのみ変動すると仮定されている。ｎ−１秒からｎ秒までの期間のフレームレート値は、その期間中に再生されるフレーム数に等しい。時間軸はＮＰＴ時間を表すものであってもよく、ＱｏＥ報告期間の開始時間を起点としてもよい。
【００６１】
フレームレート偏差メトリックと関連づけられるタイムスタンプは、フレームレート偏差が発生した時間を示す。上記タイムスタンプの値は、ＱｏＥ報告期間の開始時間に対する、フレームレート偏差イベント中最初に再生されたフレームのＮＰＴに等しくてもよい。イベント中再生されたフレームが存在しない場合、上記タイムスタンプの値は、イベント前に最後に再生されたフレームのＮＰＴ又はＱｏＥ報告期間の開始時間（ＱｏＥ報告期間の開始時間に対していずれか遅い方）に等しくしてもよい。
【００６２】
ジッタ継続時間
この品質メトリックは、オーディオ、ビデオ及び音声だけに適用可能なものであり、他のメディアタイプに対しては適用できない。再生ジッタは実際の再生時間とスケジュールされた再生時間との間の絶対差が所定値よりも大きいときに生じる。このメトリックは秒で表現され、分数値となる場合がある。前記所定値は、サーバ及びクライアント双方に既知の、例えば１００ミリ秒などのデフォルト値であってもよい。
【００６３】
ジッタ継続時間メトリックと関連づけられるタイムスタンプは、再生ジッタが発生した時間を示す。タイムスタンプの値は、ＱｏＥ報告期間の開始時間に対する再生ジッタ期間内の最初に再生されたフレームのＮＰＴに等しくしてもよい。
【００６４】
同期はずれ継続時間
この品質メトリックは任意の一対のメディアタイプに適用可能である。前記少なくとも１つのメディアストリームの第１のメディアストリームの最後に再生されたフレームの再生時間と、前記少なくとも１つのメディアストリームの第２のメディアストリームの最後に再生されたフレームの再生時間との間の差として値Ａを定め、前記少なくとも１つのメディアストリームの前記第１のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間と、前記少なくとも１つのメディアストリームの前記第２のメディアストリームの前記最後に再生されたフレームのスケジュールされた再生時間との間の差として値Ｂを定める。
【００６５】
同期はずれは、前記値Ａと前記値Ｂの間の絶対差が所定値よりも大きくなると生じる。この品質メトリックは秒で表現され、分数値となる場合がある。前記所定値は、サーバ及びクライアント双方に既知の、例えば１００ミリ秒などのデフォルト値であってもよい。
【００６６】
同期はずれ継続時間メトリックと関連づけられたタイムスタンプは、再生同期はずれが発生した時間を示す。タイムスタンプの値は、ＱｏＥ報告期間の開始時間に対する、同期はずれ期間中最初に再生されたフレームのＮＰＴに等しくしてもよい。
【００６７】
破損シーンカットフレーム数
この品質メトリックは、ビデオだけに適用可能であり、他のメディアタイプに対しては適用できない。このメトリックは、ＱｏＥ報告期間中の破損シーンカットフレームの数と関連するものである。このメトリックは０以上の整数の単位で表現することができる。このメトリックがサポートされていて、かつ、ＱｏＥ報告期間にこのようなメトリックが報告されなければ、これは、ＱｏＥ報告期間中はシーンカットフレームが破損しなかったことを示しているかもしれない。
【００６８】
この品質メトリックは、どのフレームがシーンカットフレームであるかを示す情報をサーバが有するとき、又は、例えば、シーンカット検出アルゴリズムによってサーバがその情報を導き出す方法を実装しているとき、利用することができる。この場合、帯域内シグナリングか、帯域外シグナリングかのいずれかを介して、サーバが情報をクライアントに利用可能とすることが有利かもしれない。この品質メトリックはまた、クライアントが、例えばシーンカット検出アルゴリズムを利用することによってこの情報を導き出す方法を実装しているときも利用可能である。例えば、ＩＴＵ−Ｔ  Ｈ.２６４（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｐａｒｔ１０としても知られる）では、シーン情報補足強化情報（ＳＥＩ）メッセージを利用して、シーンカット情報を帯域内でクライアントへ送信することが可能である。
【００６９】
破損シーンカットフレーム数メトリックと関連づけられたタイムスタンプは定義されない場合がある。というのは、破損したシーンカットフレームの数の測定時間がＱｏＥ報告期間の終了時間に等しいことは明瞭かもしれないからである。
【００７０】
本発明によって提案される新規の品質メトリックの各々のための例示のプロトコルシンタックスは、例えば、以下のとおりになる。
Framerate_Deviation = "Framerate_Deviation"  "="  "｛"  SP / (Value1 SP Value2 [SP Timestamp])#(","  Value1 SP Value2 [SP Timestamp]) "｝";
Jitter_Duration = "Jitter_Duration"  "="  "｛"  SP / (Value [SP Timestamp])#(","  Value [SP Timestamp])  "｝";
Syncloss_Duration = "Syncloss_Duration"  "="  "｛"  SP / (Value [SP Timestamp])#(","  Value [SP Timestamp])  "｝";
Corrupted_Scene_Cuts = "Corrupted_Scene_Cuts"  "="  "｛"  SP / Value "｝";
【００７１】
上記例では、Ｖａｌｕｅ１フィールドはフレームレート偏差イベントの継続時間を示し、Ｖａｌｕｅ２フィールドはフレームレート偏差値を示す。上記Ｖａｌｕｅフィールドは再生ジッタの継続時間、同期はずれの継続時間又は破損シーンカットフレーム数を示す。Ｔｉｍｅｓｔａｍｐフィールドの意味は上記に指定されるとおりである。
【００７２】
品質フィードバックにおいて、監視期間中に同じイベントが２回以上発生する可能性がある。その場合、品質フィードバック値が２回以上発生し、それはサーバに対してイベントの数を示す。
【００７３】
クライアントがフレームレート偏差メトリックの計算を可能にするためには、所定のフレームレート値をクライアントへ送る必要があるかもしれない。この場合、Ｔｄｏｃ  Ｓ４−０４００７３に規定されているように、ＲＳＴＰヘッダのＱｏＥ−Ｈｅａｄｅｒ又はＳＤＰ属性“ＱｏＥ−Ｍｅｔｒｉｃｓ”の１つの追加パラメータとして値を追加することができる。所定のフレームレート値用の構文設計は、例えば、以下のように定義することができる。
Pre-defined Frame Rate = "FR"  "="  1*DIGIT "."  1*DIGIT
【００７４】
この場合、ＲＴＳＰ  ＱｏＥ−Ｈｅａｄｅｒの構文及びＳＤＰ  ＱｏＥ−Ｍｅｔｒｉｃｓの構文は以下のようになるかもしれない。
QoE-Header = "QoE-Metrics"  ":"  "Off" / 1# (stream-url ";"  Metrics ";"
Sending-rate [";"  Range] [";"  FR])  CRLF
そして
a=QoE-Metrics: Metrics ";"  Sending-rate [";"  Range] [";"  FR] CRLF
【００７５】
ストリーミングサービスにおいて品質フィードバックを行う際に、より効率的に送信帯域を利用するために、本発明は、前記継続時間の方が所定値よりも大きい場合だけ、破損継続時間メトリックに従って決定された品質フィードバック値を報告することを提案する。再生中、たとえ短期間に単一フレーム又は２、３のフレームが再生されなくても、エンドユーザは一般にその違いを知覚することはできない。受信端末装置は、例えば、以下の理由のうちの１つ理由に基づいてフレームを再生しないように決定してもよい。何らかの理由によって非参照フレームがサーバから送信されなかった；非参照フレームが部分的に又は全体的に損失している；非参照フレームは完全に受信されているが、この非参照フレームを正確に復号できない；非参照フレームは完全に受信されているが、遅延又は計算能力不足に起因してこの非参照フレームが復号されない；参照フレーム又は非参照フレームは完全に受信され、正確に復号されるが、そのスケジュールされた表示時間が過ぎている。短期間内のこのようなフレームの非再生はユーザ体験に影響を与えるものではなく、したがって、短期間のこのようなフレームの報告は送信帯域幅を浪費するものとなる。したがって、本発明によれば、破損持続時間が前記所定値を上回ったときにだけ、上記破損持続時間の報告を行うことが提案される。該所定値は、例えば、サーバ及び／又はクライアントによって設定されたデフォルト値であってもよいし、又はプロトコルによって規定された値であってもよい。
【００７６】
図３は、本発明に準拠する方法を示すフローチャートを描く図である。第１のステップ３００で、ストリーミングクライアントとストリーミングサーバとの間でストリーミングセッションを設定する。ステップ３０１で、本発明が提案するとおりの品質メトリックを含む、所定の品質メトリックの組のうち１以上の品質メトリックのネゴシエーションを、ストリーミングクライアントが行う品質フィードバックの処理手続で利用するためにストリーミングクライアントとストリーミングサーバとの間で行う。前記セッションの設定とネゴシエーションとの双方は、ＳＤＰと組み合わされたＲＴＳＰに基づくものであってもよいし、ＲＴＣＰ又はＳＩＰに基づくものであってもよい。ステップ３０１はまた、ステップ３００と共に実行してもよい。対応するタイムスタンプメトリックは、ストリーミングセッション用としてネゴシエーションが行われた品質メトリックのうちの少なくともいくつかと関連づけられたものであってもよい。ステップ３０２で、例えば、メディアストリームがストリーミングクライアントへ送信され、前記ストリーミングクライアントが設定された端末装置で再生されるとき、実際のストリーミングを開始する。前記ストリーミング中、ステップ３０３で、品質フィードバックが必要か否かのチェックを行う。例えば、ネゴシエーションが行われた品質メトリックに従ってストリーミングサーバへ報告する必要があるイベントが発生したか否かのチェックを連続的に行うことにより、上記チェックを行うことができる。このイベントは、例えば同期はずれイベントかもしれない。代替として、例えば、ある時間間隔で、破損シーンカットフレーム数の周期的フィードバックなどの周期的品質報告のネゴシエーションが行われている場合もある。前記ステップ３０３で、イベント駆動型品質フィードバックと、周期的品質フィードバックとの双方をトリガする。品質フィードバックが必要であることが決定された場合、ステップ３０４で、ネゴシエーションが行われた各品質メトリックに従って品質フィードバック値を決定する。１又はいくつかの前記ネゴシエーションされた品質メトリックがタイムスタンプメトリックと関連づけられている場合、ステップ３０５で対応するタイムスタンプを決定する。前記ステップ３０５はステップ３０４の前であっても同様に良好に実行可能である。次いでステップ３０６で、例えば、ＲＴＳＰ、ＲＴＣＰ又はＳＩＰを介して、品質フィードバック値及び対応するタイムスタンプをストリーミングサーバへ報告する。品質フィードバックを行った後、又は品質フィードバックが必要でないことが決定された場合、ステップ３０７で、ストリーミングを停止すべきかどうかのチェックを行う。ストリーミングを停止すべきでない場合、ステップ３０３で新たな品質フィードバックが必要か否かのチェックを再度行う。
【００７７】
図４は本発明に準拠するシステムの機能コンポーネントを概略的に描く図である。この実施例は、ストリーミングを制御するためにＲＴＳＰを利用するＰＳＳシステムを例示的に参照するものである。わずかに修正された下位のプロトコルスタックを用い、かつ、クライアント６０１（第１のパーティ）からサーバ６００（第２のパーティ）へ送信される品質フィードバック情報と、タイムスタンプとを傍受したり、捕捉したりする追加のネットワークインスタンスを用いることによって、ＳＩＰも同様に良好に利用が可能であることを理解されたい。図４のＰＳＳシステムは、ストリーミングクライアント６０１と、ストリーミングサーバ６００とを備え、そこでクライアント６０１とサーバ６００との双方は、ＲＴＳＰを動作させることができる少なくとも１つのＲＴＳＰエンティティ４０１、４００を有する。ＲＴＳＰエンティティは、別のプロトコルエンティティによって運用される下位のプロトコル層のサービスを利用する。上記プロトコルエンティティのうち、ＴＣＰエンティティ４０２、４０３及びＩＰエンティティ４０４、４０５だけが図示されている。ストリーミングクライアント６０１は、ネゴシエーションされた品質メトリック、及びおそらく対応するタイムスタンプメトリックという観点から、実際のストリーミング用アプリケーションの品質を監視し、監視された品質フィードバック値を前記ＲＴＳＰエンティティ４０１へ入力するストリーミング品質モニタインスタンス４０７とさらに接続されている。例えば前記ストリーミングクライアントが設定された端末装置によって、前記ストリーミング品質モニタを行ってもよい。利用する品質メトリックとしてタイムスタンプメトリックが規定されている場合、ストリーミング品質モニタ４０７は、前記タイムスタンプメトリックに従ってタイムスタンプを決定し、クライアントＲＴＳＰ４０１を介して、前記監視した品質フィードバック値と、前記対応するタイムスタンプとをストリーミングサーバ６００内のＲＴＳＰピアエンティティへ転送し、該ＲＴＳＰピアエンティティにおいて、該品質フィードバック値は評価と分析のために品質データ処理インスタンス４０６へ入力される。該評価と分析とは、例えば、破損継続時間イベントの頻度が高すぎることが判明した場合、ストリームのエラー耐性を強化することによってストリーミングアプリケーションの品質の改善をねらいとしてもよいし、若しくは、単に統計的品質データの収集、課金又は他の目的をねらいとしてもよい。
【００７８】
以上推奨実施例により本発明を説明した。当業者にとっては明白な代替の方法及び変更例が存在し、本願請求項の範囲と精神から逸脱することなく実現可能であることに留意されたい。特に、本発明は、決して３Ｇ無線通信システムにおけるアプリケーションに限定されるものではない。本発明は、パラメータフィードバックを含むすべての種類の有線及び無線データ送信システムにおいても同様に良好に利用可能である。
【図面の簡単な説明】
【００７９】
【図１】従来技術に従うパケット交換型ストリーミングサービス（ＰＳＳプロトコルスタックの概略表示。
【図２】従来技術に従うリアルタイムストリーミングプロトコル（ＲＴＳＰ）ネゴシエーションヘッダの定義。
【図３】本発明の方法を示すフローチャート。
【図４】本発明に準拠するシステムの概略表示。
【図１】
2007536859.tif 000003
【図２】
2007536859.tif 000004
【図３】
2007536859.tif 000005
【図４】
2007536859.tif 000006
【国際調査報告】
2007536859.tif 000007
2007536859.tif 000008
2007536859.tif 000009