JP2007503741A - 無線通信ネットワーク用の経験の質（ｑｏｅ）メトリクス - Google Patents

Abstract

経験の質（ＱｏＥ）フレームワークは、２．５Ｇまたは３Ｇのような移動体無線通信環境において、あるいは他の任意の無線通信環境または有線通信環境において、エンドユーザの経験を評価するための技術を提供する。フレームワークは、メディアストリーミングアプリケーションと関連して利用可能であり、抽出結果において、ネットワーク層、トランスポート層、コデック層、およびアプリケーション層の測定を可能にする。抽出された結果は、必要であれば、激しく変動し得るネットワーク状態におけるエンドユーザの経験をモニターし、改善するために使用され得る。

Description

（関連出願の相互参照）
本出願は、２００３年８月２１日出願の米国特許仮出願第６０／４９７，４４７号、および２００４年１月２６日出願の米国特許仮出願第６０／５３９，５３６号の利益を主張する。なお、これらの２つの仮出願は、本出願と同一の譲受人に譲渡され、本明細書中にその全体を援用する。

本開示は、広義には通信ネットワークに関し、より具体的には、無線および／または有線の移動体通信環境においてエンドユーザの経験の質（ＱｏＥ）を評価する技術に関する。ただし、これらに限定するわけではない。

メディアの圧縮および無線ネットワークインフラストラクチャの発展に伴い、メディアスストリーミングは、エンドユーザ、コンテンツプロバイダ、無線オペレータ、その他の実体に対して有望な技術領域となった。２．５Ｇまたは３Ｇといった無線技術用に利用可能な帯域幅はより多いものの、進歩した圧縮技術によって非常に低ビットレートのストリーミングが可能であるという事実に反して、無線環境ということになると、本来備わっている問題が存在する。

このような問題をはらんだ無線ストリーミングアプリケーションは、リアルタイムのメディアアプリケーション（音声ストリーミングおよびビデオストリーミングの両方を含む）と、リアルタイムの音声アプリケーション（ライブミュージックまたはスポーツ放送等）オフラインのメディアアプリケーションと、オフラインの音声アプリケーションとを含む。有線ネットワークとは異なり、無線ネットワークは、実質的なパケットロスや、断続的なパケット遅延を受ける。パケットロスおよびパケット遅延は、無線ネットワークの本来備わっている特性であるフェージング等の影響の他、ネットワークの混雑、ビットエラーレート、あるいはユーザの機器におけるデータオーバーフローのような要因によって生じ得る。

パケットロスに加え、エンドユーザによって受け取られるメディアに悪影響を及ぼす他の要因がある。これらの要因のうちのいずれかによる、ユーザ経験への影響は、通信チャネル状態、ユーザ機器の特性、環境状態、通信中に起こる意図的なイベントまたは無意識のイベント、あるいは他の影響に応じて大きく変動し得る。

上記の要因および他の要因は全て、メディア配信およびメディア消費という意味での移動体無線通信環境において、エンドユーザの経験の質（ＱｏＥ）に対し最終的に悪影響を及ぼす。ここであるトリーミングはメディア配信のほんの一例である。これらの同様の要因または他の要因は、有線の通信環境においてもエンドユーザのＱｏＥに影響を及ぼす可能性がある。

一局面は、無線通信環境において利用可能な方法を提供する。この方法は、無線通信環境における質に影響する特性を示す少なくとも１つの経験の質（ＱｏＥ）メトリクスを定義することを含む。その少なくとも１つのＱｏＥメトリクスのうちのいずれをクライアントとサーバとの間のセッション中に用いるかを決定するために、クライアントとサーバとの間でネゴシエーションが行われ、そのようなＱｏＥメトリクスが、受け入れられるＱｏＥとして指定される。１つ以上の受け入れられるＱｏＥメトリクスのデータはがセッション中に収集され、測定データはクライアントとサーバとの間で通信される。

以下の図を参照して、限定的でなく網羅的でない実施形態を説明する。図において、別段の定めがない限り、同一の参照数字は様々な図を通して同一の部分を指すものとする。

以下の記載において、実施形態の完全な理解を提供するために、多数の特定の詳細事項が挙げられる。しかしながら、本発明が特定の細部のうちの１つ以上の詳細事項を欠いて実施されたり、あるいは他の方法、構成要素、素材等と共に実施されたりし得るということは、関連技術の当業者であれば認識できよう。他の例において、既知の構造、素材、または動作については、本発明の局面を不明確にするのを避けるために、詳述していない。

本明細書全体において、「一実施形態」または「実施形態」について言及することは、実施形態に関して記載された特定の特徴、構造あるいは特性が少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書全体において様々な箇所に「一実施形態において」または「実施形態において」という語句が現れることが、必ずしも同一の実施形態を指すものではない。さらに、特定の特徴、構造または特性は、１つ以上の実施形態において任意の適切な方法で組み合わせられ得る。

コンテクストから別段に必要でない限り、続く明細書および請求項の全体にわたって、「備える（ｃｏｍｐｒｉｓｅ）」という単語、ならびに「備える（ｃｏｍｐｒｉｓｅｓ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」等のその変形は、「含むが、それに限定されない（ｉｎｃｌｕｄｉｎｇ， ｂｕｔ ｎｏｔ ｌｉｍｉｔｅｄ ｔｏ）」のようにオープンかつ包括的な意味で解釈されるものとする。

本明細書において提供される見出しは便宜上のものにすぎず、請求される発明の範囲や意味を解釈するものではない。

概観として、ＱｏＥフレームワークの一実施形態は、ネットワークコンポーネント間の通信中に発生し得るＱｏＥ問題をモニターしアドレスする技術を提供する。たとえば、メディアがサーバからクライアントへ伝達される際にサーバとクライアント（たとえばエンドユーザ機器）との間の通信中に発生し得るＱｏＥ問題があり得る。一実施形態のＱｏＥフレームワークのコンポーネントは、セッションの開始および終了をそれぞれ定義する開始プロセスおよび終了プロセスと、セッション中にいずれのメトリクスを使用するかをサーバとクライアントがネゴシエートするネゴシエーションプロセスと、定義され実施される（たとえばメトリクス値の収集／測定）１つ以上のメトリクスと、所定の周波数において、所定のセッション範囲の間、メトリクスに適した測定値であってネゴシエーション中に認められた全ての測定値を移動することと、ＱｏＥを評価して必要であればＱｏＥが改善され得る条件を調節するために、測定値を分析／適用することとを含む。

無線通信ネットワークにおけるＱｏＥフレームワークというコンテクストで、様々な実施形態を本明細書に記載する。本発明が無線環境に限定されていないという点が認識される。
ＱｏＥフレームワークの実施形態は、有線の通信ネットワーク（有線要素および無線要素の両方を備える通信ネットワークを含む）、あるいはＱｏＥ問題を経験し得る他の任意のネットワークに適用され得る。

単なる図示説明の目的で、規格特有および／あるいはプロトコル特有の、用語、プロセス、フォーマットまたはプロトコル特有のその他の実施を用いて、様々な実施形態を本明細書中に記載する。たとえば、ある実施形態は、セッション記述プロトコル（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＳＤＰ）、実時間ストリーミングプロトコル（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）（ＲＴＳＰ）、および他の規格／プロトコルに関連して記載されている。これらの具体的に記載された実施は本発明を限定することを意図するものではない。むしろ、そのような規格／プロトコルに特有の記載は単に、既知の規格／プロトコルと関連して実施される場合の、ある例示的な実施形態の動作および特徴を読者（または当業者）が理解するのを助けるように意図される。本明細書中のこれらの特定の記述から、当業者であれば、他の規格／プロトコル（現在既存のもの、あるいは今後開発されるもの）に関する、あるいはＱｏＥ問題が発生する他の応用に関する、本発明のその他の実施形態をなす方法および利用する方法に関連する知識を得ることができよう。

ＱｏＥの、特定ではあるものの非限定的なこのような一例示の実施形態は、規格に従った拡張を提供することによって、ＳＤＰ（たとえば、ＲＦＣ２３２７：ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ，Ｈａｎｄｌｅｙ Ｍ．およびＪａｃｏｂｓｏｎ Ｖ．，１９９８年４月を参照）［２］のような既存のストリーミング記述プロトコル、ならびにＲＴＳＰ（たとえば、ＲＦＣ２３２６：Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ），Ｓｃｈｕｌｚｒｉｎｎｅ Ｈ．，Ｒａｏ Ａ．およびＬａｎｐｈｉｅｒ Ｒ．，１９９８年４月を参照）［３］のような既存のストリーミング制御プロトコルに影響を与える。また、一実施形態は、ＲＴＣＰ（たとえば、ＲＦＣ ３５５０：ＲＴＰ：Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−ＴＩｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ，Ｓｃｈｕｌｚｒｉｎｎｅ Ｈ．ら，２００３年７月を参照）［４］およびＲＴＣＰ ＸＲ（たとえばＲＦＣ ３６１１：ＲＴＰ Ｃｏｎｔｒｏｌ Ｅｘｔｅｎｄｅｄ Ｒｅｐｏｒｔｓ（ＲＴＣＰ ＸＲ），Ｔ．Ｆｒｉｅｄｍａｎら，２００３年１１月を参照）［５］のような既存の規格に基づくレポートメカニズムが組込まれることを可能にする。以後本記載を通じて、これらの参考文献のそれぞれに割り当てられた括弧［］内の数字を、これらの参考文献を参照する略記の手段として用いる。

ＱｏＥフレームワークの一実施形態は、コラプション継続期間、リバッファリング継続期間、初期バッファリング継続期間、連続的なロス、フレームレートの偏り、および／またはジッタ継続期間等のＱｏＥパラメータ（メトリクス）のセットをも定義する。これらのメトリクスまたはその他の適切に定義されたメトリクスが、単独で、あるいは任意の実用的な組合せで使用され得る。

図１は、一実施形態によるＱｏＥフレームワークに含まれるコンポーネントの図を示す。サーバ１００とクライアント１０２とは、ＱｏＥプロトコルおよびサービスの質（ＱｏＳ）プロトコルを経由して相互通信するように図示されている。クライアント１０２の適切ではあるが非限定的な一例は、任意の３ＧＰＰ Ｒｅｌｅａｓｅ ６の規格に従う、ＱｏＥプロトコルをサポートしているハンドセット／プレイヤーであり、定義されたメトリクスの最小のセット（たとえば、Ｓ４−０４０３０８ Ｗｏｒｋｉｎｇ Ｄｒａｆｔ ２６２３４−０５０，３ＧＰＰ ＴＳＧ−ＳＡ４ Ｍｅｅｔｉｎｇ＃３１，Ｍｏｎｔｒｅａｌ（カナダ）、２００４年５月１７〜２１日、に定義されている）［１］は、サーバ１００またはネットワークコンポーネントと通信できる。クライアント１０２の一実施形態は、ＱｏＥクライアントモジュール１１８を含む。これについては後にさらに詳述する。

サーバ１００の一実施形態は、Ｄｙｎａｍｉｃ Ｂａｎｄｗｉｄｔｈ Ａｄａｐｔａｔｉｏｎ（ＤＢＡ）モジュール１０４と、サービスの質（ＱｏＳ）モジュール１０６と、ＱｏＥサーバモジュール１０８とを組込んでいる。ＱｏＳモジュール１０６は、クライアント１０２とネットワークとの間の、ネゴシエートされた最大ビットレートと、保証されたビットレートと、転送遅延パラメータに影響する。ＱｏＳモジュール１０６はまた、ロス、遅延、その他のような任意の追加のネットワーク層データにも影響する。ＤＢＡモジュール１０４の実施形態の例は、２００３年５月３０日出願の、「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＤＹＮＡＭＩＣ ＢＡＮＤＷＩＤＴＨ ＡＤＡＰＴＡＴＩＯＮ」と題され、本出願と同一の譲受人に譲渡された米国出願第１０／４５２，０３５号においてさらに詳細に記載されている。当該出願の全体を本明細書中に援用する。

これらのモジュールはすべて、厳しく変動し得るネットワーク状態においてさえ、ユーザ経験がセッションの間じゅう予想通りでありかつモニターされていることを協働して保証する。サービスプロバイダ／オペレータ１１０は、システムモニタリングモジュール１１２、ビリングモジュール１１４（ハンドセットは認証されているものと仮定する）、またはその他の任意のモジュールに対し、ＱｏＥサーバモジュール１０８の出力を与えることができる。一実施形態のＱｏＥサーバモジュール１０８は、自身がプラグインするコンポーネントの必要性に応じてカスタマイズ可能であり得、ＱｏＥメトリクスの統計的分析およびＱｏＳパラメータを提供することができる。

図示した実施形態のＱｏＥサーバモジュール１０８はサーバ１００に常駐するように示されているが、ＱｏＥモジュール（あるいは他のモジュールのうちの任意のモジュール）を適切に無線または有線のネットワーク内の別の場所に適切に位置し得るという点が認識される。たとえば、ＱｏＥサーバモジュール１０８は、プロキシデバイス、ルータ、スイッチ、あるいは他のネットワークコンポーネントに位置することができる。一部の実施形態においては、クライアント１０２に位置することが含まれる。

ＱｏＥフレームワークの特徴の１つは、サービスプロバイダ１１０に対してエンドユーザ経験を評価する手段を提供することである。一実施形態のＱｏＥフレームワークは、ビリング、またはハンドセット／プレイヤーのベンチマークテストの目的に使用され得る。信頼されたメトリクスのフィードバックが実質的に保証され得るとすると、このような使用は向上され得る。

以下の記載は次のように編成されている。セクションＩは、ＱＯＥプロトコルの局面について記載する。セクションＩＩは、ＱＯＥメトリクスの局面について記載する。セクションＩＩＩは、ＱＯＥサーバモジュールの局面について記載する。セクションＩＶは、ＱＯＥクライアントモジュールの局面について記載する。

Ｉ．ＱｏＥプロトコル
特定であるが非限定的な実施形態において、ＲＴＳＰおよびＳＤＰをベースとするプロトコルの拡張は、たとえばパケットスイッチストリーミングサービス（ＰＳＳ）クライアント１０２とＰＳＳサーバ１００との間でＱｏＥメトリクスを伝送したりネゴシエートしたりするために用いられる。当然ながら、ＱｏＥメトリクスの伝送およびネゴシエーションは、代替的に、あるいはＲＴＳＰとＳＤＰに加えて、その他のメカニズムを利用することができる。ＱｏＥプロトコル１１６の伝送およびネゴシエーションのプロセスの、例示の実施形態を、図１に示す。

メトリクス情報がＳＤＰデータに埋め込まれている場合、クライアント１０２から送信されたＤＥＳＣＲＩＢＥリクエストに対するレスポンスによって、ＱｏＥメトリクスのネゴシエーションが開始する。ＱｏＥ−Ｍｅｔｒｉｃｓの属性を含む、ローカルに格納されたＳＤＰの場合については、クライアントの１０２のＳＥＴＵＰリクエストによってネゴシエーションが開始する。ＰＳＳクライアント１０２がＱｏＥメトリクスをサポートする場合、クライアント１０２はセッションレベルまたはメディアレベルのいずれかの選択された（すなわち、クライアント１０２によって認められた）／修正された（再ネゴシエーションのために）ＱｏＥメトリクスを含むＳＥＴＵＰリクエストを送信する。これがセットアップされるということである。

このＳＥＴＵＰリクエストを受け取ると、サーバ１００は、「認められた」ＱｏＥメトリクス（すなわち、クライアント１０２のリクエストにおけるものと同一であり、サーバ１００によって認められた、メトリクスおよびメトリクス値）と、「再ネゴシエーション」ＱｏＥメトリクス（すなわち、クライアント１０２のリクエストにおけるものと同一でなく、サーバ１００によって再ネゴシエーションのために修正された、メトリクスおよびメトリクス値）を有するＲＴＳＰレスポンスを返信する。「認められた」ＱｏＥメトリクスの反復（ｅｃｈｏｉｎｇ）は、クライアント１０２を再度承認するためのものである。サーバ１００はまた、クライアント１０２によってなされた変更を拒絶し（すなわち、「再ネゴシエーション」ＱｏＥメトリクスを拒絶する）得る。サーバ１００が変更を拒絶する場合、サーバ１００は、新たな値を設定しクライアント１０２に修正済のメトリクスを再送するか、あるいは、サーバ１００は「再ネゴシエーション」メトリクスを無視しそれらを再度承認しないかのいずれかである。サーバ１００によって「認められた」として承認されたＱｏＥメトリクスは、いずれも再ネゴシエートされない（すなわち、それは次のＲＴＳＰリクエスト内の「３ＧＰＰ−ＱｏＥメトリクス」ヘッダ中に再送される必要はなく、次のＲＴＳＰレスポンスにおいて再度承認される必要はない）。

サーバ１００がクライアント１０２によってなされた修正を認めない場合、サーバ１００およびクライアント１０２は、ＲＴＳＰ ＰＬＡＹリクエストまで再ネゴシエーションを続行し、サーバ１００は、ＲＴＳＰ ＰＬＡＹレスポンスにおいて、「認められた」ＱｏＥメトリクスを反復する。クライアント１０２は、ＲＴＳＰ ＰＬＡＹリクエストを出すことによってネゴシエーションプロセスを終了することができる。「ＱｏＥメトリクス」のヘッダ部がＲＴＳＰリクエストにおいて送信されるたびに、そのＱｏＥメトリクスはその個々のリクエストに対応するレスポンス内にも存在するという点が留意される。そうでなければ、レスポンスの受信者は、もう一方の端がＱｏＥメトリクスをサポートしていないとみなす。

ＲＴＳＰシグナリング（たとえば図２を参照）の初めに送信するＤＥＳＣＲＩＢＥ−ＲＴＳＰレスポンスのペアがない場合、ＳＤＰ記述がその他の手段によって受け取られることを意味する。そのようなＳＤＰが「３ＧＰＰ−ＱｏＥ Ｍｅｔｒｉｃｓ」属性を含んでいる場合、ネゴシエーションは、上記と同様の方法で起こる（すなわち、「３ＧＰＰ−ＱｏＥ Ｍｅｔｒｉｃｓ」ヘッダを含むＳＥＴＵＰリクエストによって開始される）。ＳＤＰが「３ＧＰＰ−ＱｏＥ Ｍｅｔｒｉｃｓ」属性を含んでおらず、クライアント１０２はＱｏＥプロトコルをサポートしているか否かについてサーバ１００がさらにチェックを所望する場合、サーバ１００は、初期のＱｏＥメトリクスを含んだ「３ＧＰＰ−ＱｏＥ Ｍｅｔｒｉｃｓ」ヘッダをＳＥＴＵＰレスポンス中に含む。ＰＳＳクライアント１０２が次のリクエスト（それがＱｏＥプロトコルをサポートしていることを示す）中のＱｏＥメトリクス情報を送信する場合、相互の合意が得られるまで、あるいは、ＲＴＳＰ ＰＬＡＹリクエストおよびレスポンスのメッセージペアが出されるまで、ネゴシエーションは続行される。クライアント１０２がＳＥＴＵＰレスポンスに次のリクエスト中のＱｏＥメトリクス情報を送信しない場合、サーバ１００は、クライアント１０２がＱｏＥメトリクスをサポートしていないとみなす。

性能および複雑さの理由のため、実施形態においてストリーミング中のＱｏＥメトリクス再ネゴシエーションを行う必要はない。しかしながら、ストリーミングセッション中にメトリクスをオフにすることは可能である。メトリクスは、たとえばセッションレベルまたはメディアレベルにおいて「オフ」に設定され得る。リクエストユニフォームリソースロケータ（ＵＲＬ）は、どのレベルが使用されているかを示す。ＵＲＬが使用されていない場合、「オフ」がセッションレベルに該当する。サーバ１００は、ＱｏＥフィードバックをオフにするために、ＯＰＴＩＯＮＳ（セッションＩＤを有する）またはＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＴＳＰ方法を使用することができる。

クライアント１０２は、ＲＴＳＰ準備完了状態中にはＱｏＥフィードバックを送信しない。レディ状態が終了された後（すなわちＲＴＳＰ状態＝再生中）、期間的なフィードバックおよび通常操作が続行される。これは、アップリンクおよびダウンリンクの方向におけるネットワーク負荷、ならびにＰＳＳクライアント１０２用の処理オーバーヘッドを低減する。ＲＴＳＰ ＰＬＡＹリクエストがＰＡＵＳＥの後にＰＳＳクライアント１０２によって送信される場合、レポート期間（定義された「送信レート」に基づく）を測定するためのクロックがリセットされる。

多数の集合されていないセッション（すなわち、メディアの配信はそれぞれ異なるＰＬＡＹリクエストによって開始される）がある場合、ＱｏＥメトリクスは、各セッションのために個々にネゴシエートされレポートされる。

繰り返すが、ＱｏＥプロトコルの部分の上記の（および、続いて以下のセクションｌ．Ａ−Ｉ．Ｆにも記載されている）特定であり実施を中心とした実施形態は、単に例示の目的のためのものであって、本発明の限定を意図されるものではないということが強調される。プロトコルのより一般的な説明は、以下のように要約され得る：サーバ１００とクライアント１０２との間でセッションが開始される；一部のメトリクスは、サーバ１００およびクライアント１０２のうちのいずれかあるいは両方によってサポートされてもよいし、サポートされなくてもよい；また、クライアント１０２は、クライアント１０２のサポートするメトリクスの部分集合を含むことを選択し得る；したがって、クライアント１０２およびサーバ１００はネゴシエーションプロセスに取り組み、ネゴシエーションプロセスは、メトリクスがクライアント１０２によってサポートされておりクライアント１０２によって送信されるべきであるか、サポートされた／認められたメトリクスがどのくらい頻繁に送信されるべきか、メトリクスを有効化および／または無効化する方法、認められたメトリクスが含むべき内容または値、測定関連の他の要因、を決定するためのいくつかの前後の交換を含むことができる；クライアント１０２による測定値の測定および収集；クライアント１０２からサーバ１００への測定値の伝送；およびセッションの終了である。伝送されたメトリック値は、ＱｏＥがストリーミングセッション中に、および／またはその後のセッションのために、改善され得る、あるいは改善されるべきであるかを決定するために評価され得る。ＱｏＥプロトコルの開始／終了、ネゴシエーション、および伝送（フィードバック）の特徴の、より詳細であり非限定的な実施形態の説明を、定義された規格というコンテクストにおいて、以下に記載する。

Ａ．開始／終了：ＲＴＳＰ
例示的かつ非限定的な実施形態において、新しいＲＴＳＰヘッダは、どの経験の質（ＱｏＥ）メトリクスをＰＳＳクライアント１０２が送信するべきであるか、メトリクスがどのくらい頻繁に送信されるべきであるか、およびメトリクスの送信をオフにする方法を、ＰＳＳクライアント１０２およびサーバ１００がネゴシエートすることを可能にするように定義される。このヘッダは、ＲＴＳＰの実施において、たとえばＲＴＳＰ方法のＳＥＴＵＰ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＯＰＴＩＯＮＳ（セッションＩＤを有する）およびＰＬＡＹのリクエストおよびレスポンスの中に存在し得る。そこにあるヘッダまたはデータは、非ＲＴＳＰの実施において、他の手段を使用して送信され得る。例示のヘッダは、ＡＢＮＦ［３］において以下のように定義される：
ＱｏＥ−Ｈｅａｄｅｒ＝“３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ”“：”（“Ｏｆｆ”／Ｍｅａｓｕｒｅ−Ｓｐｅｃ＊（“，”Ｍｅａｓｕｒｅ−Ｓｐｅｃ））ＣＲＬＦ
Ｍｅａｓｕｒｅ−Ｓｐｅｃ＝Ｓｔｒｅａｍ−ＵＲＬ“；”（（Ｍｅｔｒｉｃｓ“；”Ｓｅｎｄｉｎｇ−ｒａｔｅ［“；”Ｍｅａｓｕｒｅ−Ｒａｎｇｅ］“（“；”Ｐａｒａｍｅｔｅｒ−Ｅｘｔ］））／“Ｏｆｆ”）”
Ｓｔｒｅａｍ−ＵＲＬ＝“ｕｒｌ”“＝”＜”＞Ｒｔｓｐ＿ＵＲＬ＜”＞
Ｍｅｔｒｉｃｓ＝“ｍｅｔｒｉｃｓ”“＝”“｛“Ｍｅｔｒｉｃｓ−Ｎａｍｅ＊（“，“Ｍｅｔｒｉｃｓ−Ｎａｍｅ）”｝”
Ｍｅｔｒｉｃｓ−Ｎａｍｅ＝１＊（（０×２１．．０×２ｂ）／（０×２ｄ．．０×３ａ）／（０×３ｃ．．０×７ａ）／０×７ｃ／０×７ｅ）；ＶＣＨＡＲ ｅｘｃｅｐｔ“；”，“，”，“｛“ｏｒ”｝
Ｓｅｎｄｉｎｇ−Ｒａｔｅ＝“ｒａｔｅ”“＝”１＊ＤＩＧＩＴ／“Ｅｎｄ”
Ｍｅａｓｕｒｅ−Ｒａｎｇｅ＝“ｒａｎｇｅ”“＝”Ｒａｎｇｅｓ−Ｓｐｅｃｉｆｉｅｒ
Ｐａｒａｍｅｔｅｒ＿Ｅｘｔ＝“Ｏｎ”／“Ｏｆｆ”／（１＊ＤＩＧＩＴ［“．”１＊ＤＩＧＩＴ］）／（１＊（（０×２１．．０×２ｂ）／（０×２ｄ．．０×３ａ）／（０×３ｃ．．０×７ａ）／０×７ｃ／０×７ｅ））
Ｒａｎｇｅｓ−Ｓｐｅｃｉｆｉｅｒ＝ＲＦＣ２３２６において定義される
Ｒｔｓｐ＿ＵＲＬ＝ＲＦＣ２３２６において定義される
この特定であり非限定的な実施形態にこのヘッダを使用する２つの方法がある。すなわち、ヘッダは、他の実施形態では他の方法で使用され得る。
―「オフ」パラメータのみの使用は、サーバ１００またはクライアント１０２のいずれかがメトリクスレポートを取り消したいという指示である。
―他のパラメータの使用は、メトリクス送信を開始するリクエストを示す。

「ストリーム−ＵＲＬ」がＲＴＳＰセッション制御ＵＲＬである場合、「メトリクス」はＲＴＳＰセッションに該当する。「ストリーム−ＵＲＬ」がＲＴＳＰメディア制御ＵＲＬである場合、「メトリクス」は、セッションのうちの指示されたメディアコンポーネントにのみ該当する。

「ストリーム−ＵＲＬ」、「送信レート」、および「測定範囲」が同じであるＱｏＥメトリクスは、単一の「測定スペック」の通知内で集合される。そうでなければ、多数の「ストリーム−ＵＲＬ」が使用される。「メトリクス」フィールドは、ＰＳＳセッションにおいてレポートされるメトリクス／測定について示す名前のリストを含む。「メトリクス」フィールドに含まれていない名前はセッション中レポートされない。

「送信レート」が設定され、それは、２つの連続のＱｏＥレポート間の最大時間を秒で表す。「送信レート」値が０である場合、クライアント１０２は、クライアント１０２において生じたイベントに応じてレポートの送信時間を決定する。値＞１は、正確なレポート間隔を示す。最短間隔は１秒であり、最長間隔は定義されていない。レポート間隔は異なるメディアについては異なり得るが、アップリンク方向に余分なトラフィックを回避するために、同期の程度は維持され得る。値「終了」は、１つのレポートのみがセッションの終わりに送信されることを示す。

オプションの「測定範囲」フィールドは、使用される場合、ＱｏＥメトリクスがレポートされるストリームにおける時間範囲を定義する。例示の実施形態において、測定仕様につき１つの範囲のみが存在する。範囲フォーマットはメディアによって認められたフォーマットのいずれかであり得る。「測定範囲」フィールドが存在しない場合、ＳＤＰの中の対応する（メディアあるいはセッションレベル）範囲の属性が使用される。ＳＤＰ情報が存在しない場合、メトリクス範囲は全体のセッションの継続期間である。一実施形態において、１つのＲＴＳＰリクエストまたはレスポンス中に１つの「３ＧＰＰ ＱｏＥ−Ｍｅｔｒｉｃｓ」ヘッダのみが存在する。

Ｂ．伝送／フィードバック：ＲＴＳＰ
一実施形態において、ＱｏＥメトリクスフィードバックは、「３ＧＰＰ−ＱｏＥ−Ｆｅｅｄｂａｃｋ」ヘッダによって、ＳＥＴ−ＰＡＲＡＭＥＴＥＲ、ＰＡＵＳＥまたはＴＥＡＲＤＯＷＮ方法を用いてＰＳＳサーバ１００へのリクエストにおいて伝えられ得る。ヘッダ（クライアント１０２からサーバ１００へ送信された）の可能な一例は、ＡＢＮＦ［３］において以下のように定義される：
Ｆｅｅｄｂａｃｋｈｅａｄｅｒ＝“３ＧＰＰ−ＱｏＥ−Ｆｅｅｄｂａｃｋ”“：”Ｆｅｅｄｂａｃｋ−Ｓｐｅｃ＊（“，”Ｆｅｅｄｂａｃｋ−Ｓｐｅｃ）ＣＲＬＦ
Ｆｅｅｄｂａｃｋ−Ｓｐｅｃ＝Ｓｔｒｅａｍ−ＵＲＬ１＊（“；”Ｐａｒａｍｅｔｅｒｓ）［“；”Ｍｅａｓｕｒｅ−Ｒａｎｇｅ］
Ｓｔｒｅａｍ−ＵＲＬ＝［１］において特定される
Ｐａｒａｍｅｔｅｒｓ＝Ｍｅｔｒｉｃｓ−Ｎａｍｅ“＝”“｛“ＳＰ／（Ｍｅａｓｕｒｅ＊（“；”Ｍｅａｓｕｒｅ））”｝”
Ｍｅｔｒｉｃｓ−Ｎａｍｅ＝［１］において定義される
Ｍｅａｓｕｒｅ＝Ｖａｌｕｅ［ＳＰ Ｔｉｍｅｓｔａｍｐ］
Ｍｅａｓｕｒｅ−Ｒａｎｇｅ＝［１］において定義される
Ｖａｌｕｅ＝（１＊ＤＩＧＩＴ“．”＊ＤＩＧＩＴ］）／１＊（（０×２１．．０×２ｂ）／（０×２ｄ．．０×３ａ）／（０×３ｃ．．０×７ａ）／０×７ｃ／０×７ｅ）；ＶＣＨＡＲ ｅｘｃｅｐｔ“；”，“，”，｛“ｏｒ”｝”
Ｔｉｍｅｓｔａｍｐ ＝ ＮＰＴ−Ｔｉｍｅ
ＮＰＴ−Ｔｉｍｅ＝ＲＦＣ２３２６において定義される
“ストリーム−ＵＲＬ”は、フィードバックパラメータの該当するメディアを識別する、ＲＴＳＰセッションまたはメディア制御ＵＲＬである。

「パラメータ」定義における「メトリクス名」フィールドは、メトリクス／測定の名称を含み、「３ＧＰＰＱｏＥメトリクス」ヘッダと同じ識別子を使用する。

「値」フィールドは結果を示す。モニタリング期間中に同じイベントが二度以上生じる可能性がある。その場合、サーバ１００へイベントの数を指示するメトリクス値が二度以上生じ得る。

オプションの「タイムスタンプ」（ＮＰＴ時間において定義される）は、イベントが生じたか、あるいはメトリックが計算された時間を示す。イベントが生じていない場合、それは、空集合（スペースのみを含む）にてレポートされる。

オプションの「測定範囲」は、このレポートが有効である実際のレポート期間を示す。

ＱｏＥメトリクスレポートは、たとえばＳＥＴ−ＰＡＲＡＭＥＴＥＲ方法を使用することによって、ＰＳＳクライアント１０２によって行われる。しかしながら、次のような特定の場合において、さらなる効率のためにＲＴＳＰＰＡＵＳＥおよびＴＥＡＲＤＯＷＮ方法もまた使用され得る：
場合１：まさに最後のＱｏＥレポートを送信する場合、クライアント１０２はＴＥＡＲＤＯＷＮメッセージへＱｏＥ情報を埋め込む。
場合２：クライアント１０２がストリーミングの流れの休止を所望する場合、ＱｏＥ情報はＰＡＵＳＥ方法へ埋め込まれるべきである。システムが休止されている場合、メディアフローがないため、ＰＳＳクライアント１０２はＰＳＳサーバ１００へＱｏＥレポートを送信するべきではない。

Ｃ．開始／終了：ＳＤＰ
一実施形態において、ＳＤＰはＱｏＥネゴシエーションを開始するために使用され得る。ＳＤＰが使用される理由は、ＳＤＰがＲＴＳＰ ＤＥＳＣＲＩＢＥ（たとえばＷＡＰ、ＨＴＴＰまたは電子メール）以外の方法を介して配信される場合の使用をサポートするためである。セッションあるいはメディアレベルのいずれかにおいて使用され得る、新しい例示のＳＤＰ属性は、ＲＦＣ２３２７に基づくＡＢＮＦにおいて以下に定義される：
ＱｏＥ−Ｍｅｔｒｉｃｓ−ｌｉｎｅ＝“ａ”“＝”“３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：”ａｔｔ＿ｍｅａｓｕｒｅ＿ｓｐｅｃ＊（“，”ａｔｔ−ｍｅａｓｕｒｅ−ｓｐｅｃ））ＣＲＬＦ
ａｔｔ−ｍｅａｓｕｒｅ−ｓｐｅｃ＝Ｍｅｔｒｉｃｓ“；”Ｓｅｎｄｉｎｇ―ｒａｔｅ［“；”Ｍｅａｓｕｒｅ−Ｒａｎｇｅ］＊（“；”Ｐａｒａｍｅｔｅｒ＿Ｅｘｔ］）
Ｍｅｔｒｉｃｓ＝［１］において定義される
Ｓｅｎｄｉｎｇ−Ｒａｔｅ＝［１］において定義される
Ｍｅａｓｕｒｅ−Ｒａｎｇｅ ＝［１］において定義される
Ｐａｒａｍｅｔｅｒ＿Ｅｘｔ ＝［１］において定義される
サーバ１００は、この属性を、ＱｏＥメトリクスがサポートされていることを示し、またクライアント１０２によってもサポートされている場合には用いられることを示すために用いる。セッションレベルに存在する場合、それは、完全なセッションに該当するメトリクスのみを含む。メディアレベルに存在する場合、それは、個々のメディアに適用可能なメトリクスのみを含む。ＲＴＳＰヘッダ「３ＧＰＰ ＱｏＥ−Ｍｅｔｒｉｓ」の仕様において使用されるＵＲＩ ＲＴＳＰ制御ＵＲＩ（ａ＝制御）によって暗に示されている。

Ｄ．開始／終了：ＳＤＰ（例）
以下のこの非限定的な例は、ＱｏＥメトリクスのためのＳＤＰ属性のシンタックスを示す。セッションレベルＱｏＥメトリクス記述（初期のバッファリングの継続期間および再バッファリング）は、セッションの終了において一度モニターされレポートされる。また、メトリクス（コラプションおよびデコードされたバイト）のビデオの特定の記述は、ストリームの開始からたとえば時間４０ｓまで１５秒ごとにモニターされレポートされるが、このタイミングは、一実施形態から別の実施形態まで、所望するとおりに変えることができる。メトリクス（コラプション）の音声特定の記述は、ストリームの開始から終了まで、たとえば２０秒ごとにモニターされレポートされる。
（例１：）
Ｓｅｒｖｅｒ−＞Ｃｌｉｅｎｔ ＲＴＳＰ／１．０２００ ＯＫ
Ｃｓｅｑ：１
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
Ｃｏｎｔｅｎｔ−Ｂａｓｅ：ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：８００
Ｓｅｒｖｅｒ：ＰＳＳＲ６ Ｓｅｒｖｅｒ
ｖ＝０
０＝−３２６８０７７６８２ ４３３３９２２６５ ＩＮ ＩＰ４ ６３．１０８．１４２．６
ｓ＝ＱｏＥ Ｅｎａｂｌｅｓ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｅｘａｍｐｌｅ
ｅ＝ｓｕｐｐｏｒｔ＠ｆｏｏ．ｃｏｍ
ｃ＝ＩＮ ＩＰ４ ０．０．０．０
ｔ＝０ ０
ａ＝ｒａｎｇｅ：ｎｐｔ＝０−８３．６６００００
ａ＝３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：｛Ｉｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ，Ｒｅｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ｝；ｒａｔｅ＝Ｅｎｄ ａ＝ｃｏｎｔｒｏｌ：＊
ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ９６
ｂ＝ＡＳ：２８
ａ＝３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：｛Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ，Ｄｅｃｏｄｅｄ＿Ｂｙｔｅｓ｝；ｒａｔｅ＝１５；ｒａｎｇｅ：ｎｐｔ＝０−４０
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝３
ａ＝ｒｔｐｍａｐ：９６ ＭＰ４Ｖ−ＥＳ／１０００
ａ＝ｒａｎｇｅ：ｎｐｔ＝０ー８３．６６６０００
ａ＝ｆｍｔｐ：９６ｐｒｏｆｉｌｅ−ｌｅｖｅｌ−ｉｄ＝８；ｃｏｎｆｉｇ＝０００００１ｂ００８０００００１ｂ５０９０００１２０００
ｍ＝ａｕｄｉｏ ０ ＲＴＰ／ＡＶＰ ９８
ｂ＝ＡＳ：１３
ａ＝３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：｛Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ｝；ｒａｔｅ＝２０
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝５
ａ＝ｒｔｐｍａｐ：９８ ＡＭＲ／８０００
ａ＝ｒａｎｇｅ：ｎｐｔ＝０ー８３．６６００００
ａ＝ｆｍｔｐ：９８ ｏｃｔｅｔ−ａｌｉｇｎ＝１
ａ＝ｍａｘｐｔｉｍｅ：２００
Ｅ．開始／終了：ＲＴＳＰ（例）
図２の例において、ＲＴＳＰセッションのセットアップ中にＱｏＥメトリクスのネゴシエーションを行う方法が示されている。ネゴシエーションの後、クライアント１０２は、サーバ１００に認められたメトリクスの、測定された／収集された値をフィードバックとして供給することができる。
Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ
ＳＥＴＵＰ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３ ＲＴＳＰ／１．０
Ｃｓｅｑ：２
３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ３”；
ｍｅｔｒｉｃｓ＝｛Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ, Ｄｅｃｏｄｅｄ＿Ｂｙｔｅｓ｝；ｒａｔｅ＝１０；Ｒａｎｇｅ：ｎｐｔ＝０−４０，
ｕｒｌ“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ”；
ｍｅｔｒｉｃｓ＝｛Ｉｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ，Ｒｅｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ｝；ｒａｔｅ＝Ｅｎｄ
上記の例示のＳＥＴＵＰリクエストにおいて、クライアント１０２は、ＱｏＥメトリクスの制御ＵＲＬ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”に対する送信レートを１５から１０へ修正する（初期のＳＤＰ記述と比較して）。サーバ１００が変更を認めたとみなすと、サーバ１００は以下のようにＳＥＴＵＰレスポンスを返信する：
Ｓｅｒｖｅｒ−＞Ｃｌｉｅｎｔ
ＲＴＳＰ／１．０ ２００ ＯＫ
Ｃｓｅｑ：２
Ｓｅｓｓｉｏｎ：１７９０３３２０
Ｔｒａｎｓｐｏｒｔ：ＲＴＰ／ＡＶＰ；ｕｎｉｃａｓｔ；ｃｌｉｅｎｔ＿ｐｏｒｔ＝７０００−７００１；ｓｅｒｖｅｒ＿ｐｏｒｔ＝６９７０−６９７１
３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”；
ｍｅｔｒｉｃｓ＝｛Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ，Ｄｅｃｏｄｅｄ＿Ｂｙｔｅｓ｝；ｒａｔｅ＝１０；Ｒａｎｇｅ：ｎｐｔ−０−４０，
ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ”；
ｍｅｔｒｉｃｓ＝（Ｉｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ，Ｒｅｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ｝；ｒａｔｅ＝Ｅｎｄ
図３は、ＤＥＳＣＲＩＢＥ−２００／ＯＫがない場合の例示のＱｏＥメトリクスネゴシエーションを示す。

以下の例では、セッションレベル（全メディア用）においてメトリクスはオフに切り替えられる。
Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ，Ｓｅｒｖｅｒ−＞Ｃｌｉｅｎｔ
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ ＲＴＳＰ／１．０
Ｃｓｅｑ：３０２
Ｓｅｓｓｉｏｎ：１７９０３３２０
３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：Ｏｆｆ
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：０
メトリクスのオフを設定するための例示のレスポンスは、以下のようなものであろう。
Ｓｅｒｖｅｒ−＞Ｃｌｉｅｎｔ，Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ
ＲＴＳＰ／１．０ ２００ ＯＫ
Ｃｓｅｑ：３０２
Ｓｅｓｓｉｏｎ：１７９０３３２０
３ＧＰＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ：Ｏｆｆ
Ｆ． 伝送／フィードバック：ＲＴＳＰ（例）
メトリクスフィードバック（メトリック値／データを含む）は、任意の適切な通信技術を用いて、クライアント１０２からサーバ１００へ伝送されるか、そうでなければ伝えられ得る。可能であり非限定的な１つの技術は、サーバ１００へフィードバックを伝えるためにＳＥＴ＿ＰＡＲＡＭＥＴＥＲ方法を使用することである。以下の例は、モニタリング時間中に２つのコラプション期間が生じたことを示す。各値は、各コラプション期間の継続期間（ミリセカンドで）を示す。
例５（フィードバック）：
Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ ＲＴＳＰ／１．０
Ｃｓｅｑ：３０２
Ｓｅｓｓｉｏｎ：１７９０３３２０
３ＧＰＰ−ＱｏＥ−Ｆｅｅｄｂａｃｋ：
ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”；Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＝｛２００ １３００）
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：０
以下の例は、モニタリング時間中に、２つのコラプション期間が生じたことを示す。各値の組は、各コラプション期間の継続期間（ミリセカンドで）およびコラプションのタイムスタンプ（たとえば最初のコラプションは１２秒で生じ、２００ミリセカンド続いた）を示す。
例６（タイムスタンプおよび範囲を有するフィードバック）：
Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐＲＴＳＰ／１．０
Ｃｓｅｑ：３０２
Ｓｅｓｓｉｏｎ：１７９０３３２０
３ＧＰＰ−ＱｏＥ−Ｆｅｅｄｂａｃｋ：ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”；
Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＝｛２００ １２，１３００ １６｝；Ｒａｎｇｅ：ｎｐｔ＝１０−２０
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：０
以下の例では、レポートするイベントはない。
例７（イベントのないフィードバック）：
Ｃｌｉｅｎｔ−＞Ｓｅｒｖｅｒ
ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ ＲＴＳＰ／１．０
Ｃｓｅｑ：３０２
Ｓｅｓｓｉｏｎ：１７９０３３２０
３ＧＰＰ−ＱｏＥ−Ｆｅｅｄｂａｃｋ：
ｕｒｌ＝“ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｎ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”；Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ｛｝
Ｃｏｎｔｅｎｔ−ｌｅｎｇｔｈ：０

ＩＩ．ＱｏＥメトリクス
一実施形態において、ＰＳＳクライアント１０２は、トランスポート層でメトリクスを測定するが、よりよい精度のためには、アプリケーション層でさらに測定し得る。メトリクスのレポート期間は、１セットのメトリクスが計算される期間である。レポート期間の極大値はＱｏＥプロトコルによってネゴシエートされる。レポート期間は、休止または巻き戻し、あるいはそれらによって引き起こされた任意のバッファリングまたはフリーズ／ギャップのように、実際の再生に影響するイベントを含んでいない。他の実施形態において、１つ以上のメトリクスが、クライアント１０２に加えて、あるいは代替的に、要素によって測定され得、次いでサーバ１００および／またはクライアント１０２に伝えられ得る。

一実施形態において、少なくともメトリクスのうちの一部は、通信環境中の質に影響する特性を示すものであるか、あるいは、通信チャネルのその他の一部の指示または結果である。クライアント１０２のアプリケーション、クライアント１０２のバッファー、クライアント１０２のコーデック、あるいはＱｏＥと関連し得る他のクライアント特性、あるいは以上のものの任意の組み合わせが、クライアント１０２のプロトコルスタックにて測定され得る。メトリクスは、サーバ１００および／またはクライアント１０２において、これらの層のうちの任意の層において、動作を調節するために使用され得る。

以下の例示のメトリクスは、ＱｏＥを実施するＰＳＳクライアント１０２によって引き出され得る。これらのメトリクスがＱｏＥ目的に使用され得る唯一のメトリクスではないということが認識される。これらのメトリクスは他のメトリクスで補われ得、他のメトリクスと置き換えられ得、修正され得、組み合わせら得る。下記のメトリクスは、動作についてのよりよい理解、および発明の実施形態の特徴を提供するために本明細書に記載されている。

以下に定義されるメトリクスは全て、オーディオ、ビデオ、スピーチおよび時間が計られたテキストメディアタイプのうちの少なくとも１つに適用可能であり、合成オーディオ、スチル画像、ビットマップグラフィックス、ベクトルグラフィックスおよびテキストのような他のメディアタイプに必ずしも適用可能ではない。しかしながら、他のメトリクスがこれらの他のメディアタイプに提供され得るということが認識される。任意の未知のメトリクスは、クライアント１０２によって無視され得、実施形態中のどのＱｏＥレポートにも含まれない。

Ａ．メトリックのコラプション継続期間
コラプション継続期間Ｍは、コラプションの前の最後の良いフレームのＮＰＴ時間から、その後の最初の良いフレームのＮＰＴ時間、あるいはレポート期間（どちらもより早い）の終了までの期間である。破壊されたフレームは、完全に失われたフレーム、あるいは質の低下を有するメディアフレームであり得、デコードされたフレームは、エラーなしのデコーディング中のものと同じではない。良いフレームは「完全に受信された」フレームＸである。すなわち、
−それがリフレッシュフレーム（先にデコードされたフレームを参照せず、後に受信されたフレームのいずれも、先立ってデコードされたフレームを全く参照しない）
−あるいは、先にデコードされたフレームを参照しない；
−あるいは、先にデコードされた「良いフレーム」を参照する。

「完全に受信された」とは、ビットがすべて受け取られ、ビットエラーが生じていないことを意味する。

以下の一実施形態においてのように、コラプション継続期間（Ｍ）はミリセカンドで計算することができる：
ａ）Ｍはクライアント１０２によってコーデック層を用いて引き出され得る。この場合、コーデック層は、クライアント１０２へ良いフレームのデコーディングの信号を出す。エラートラッキング方法によってよいフレームを引き出すことが可能であり得るが、デコーディングの品質評価方法は、一実施形態においては使用されず、別の実施形態において使用され得る。
ｂ）コーデック層からの情報がない場合、Ｍは、コラプションおよびＮの前の最後のフレームのＮＰＴ時間に由来する。ここで、Ｎはサーバ１００からクライアント１０２へ選択的に信号を出され、ミリセカンドで後の２つのリフレッシュフレーム間の最大継続期間を表す。
ｃ）コーデック層からの情報がなく、Ｎが信号を出されない場合、Ｍは∞（ビデオ用）または１つのフレーム継続期間（オーディオ用）、あるいはレポート期間（いずれもより早い）の終了へ戻る。

ポイントｂに定義される任意のパラメータＮが、「３ＧＲＰ−ＱｏＥ−Ｍｅｔｒｉｃｓ」ヘッダ中で「Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ」パラメータと共に使用される。クライアント１０２がトラッキングエラーを使用するか否かを示すために、別の任意のパラメータＴが定義される。Ｔの値はクライアントによって設定される。例示的かつ非限定的な、「測定スペック」（［１］の５．３．２．３．１の節）に含まれ得るＮおよびＴのシンタックスは、以下のとおりである：
Ｎ＝“Ｎ”“＝”１＊ＤＩＧＩＴ
Ｔ＝“Ｔ”“＝”“Ｏｎ”／“Ｏｆｆ”
ＱｏＥ−フィードバックヘッダの「Ｍｅｔｒｉｃｓ−Ｎａｍｅ Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ」に対する例示的かつ非限定的なシンタックスは、［１］の５．３．２．３．２節に定義されたとおりである。

イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。
「Ｍｅｔｒｉｃｓ−Ｎａｍｅ Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ」について、節５．３．２．３．２中の「値」フィールドはコラプション継続期間を示す。このメトリクスのユニットはミリセカンドで表される。コラプションがレポート期間に二度以上生じる可能性がある。その場合、コラプションのイベントの数を示す値が二度以上生じ得る。

「タイムスタンプ」の値は、レポート期間の開始時間に比べて、プレイバック順のレポート期間においてコラプションの発生前の最後の良いフレームのＮＰＴ時間と等しい。
レポート期間内およびコラプションの前に良いフレームがない場合、タイムスタンプは、レポート期間の開始時間に設定される。

Ｂ．再バッファリング継続期間メトリック
再バッファリングは、クライアント側の任意の無意識のイベントによる、再生時間における任意のストールとして定義される。ＱｏＥ−フィードバックヘッダの「ＭｅｔｒｉｃｓーＮａｍｅ Ｒｅｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ」に対する例示的かつ非限定的なシンタックスは、［１］の節５．３．２．３．２に定義されたとおりである。

イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。

「ＭｅｔｒｉｃｓーＮａｍｅ Ｒｅｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ」について、節５．３．２．３．２中の「値」フィールドは再度バッファリングの継続期間を示す。このメトリクスの単位は秒で表され、小数値であり得る。再バッファリングがレポート期間に二度以上生じる可能性がある。その場合、再バッファリングのイベントの数を示すメトリクス値が二度以上生じ得る。

オプションの「タイムスタンプ」は、再バッファリングがレポート期間の開始以来生じている時間を示す。「タイムスタンプ」の値は、レポート期間の開始時間に比べて、レポート期間内に再バッファリングの発生前に最後になされたフレームのＮＰＴ時間と等しい。再生されるフレームがレポート期間内にない場合、タイムスタンプは、レポート期間の開始時間に設定される。

Ｃ．初期バッファリング継続期間メトリック
初期バッファリングの継続期間は、第１のＲＴＰパケットを受け取ってから再生が開始するまでの時間である。

ＱｏＥ−フィードバックヘッダの「Ｍｅｔｒｉｃｓ−ＮａｍｅＩｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ」に対する例示的かつ非限定的なシンタックスは、節５．３．２．３．２に定義されたとおりである。この定義には、「測定」の「タイムスタンプ」がこのメトリックに対して定義されていないという例外がある。レポート期間が「Ｉｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ」より短い場合、それがそれを観察する限り、クライアントは各レポート期間としてこのパラメータを送信すべきである。「値」フィールドは初期のバッファリングの継続期間を示す。ここで、このメトリクスの単位は秒で表され、小数値であり得る。１つの「測定」のみが存在でき、それは１つの「値」のみをとることができる。イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。「Ｉｎｉｔｉａｌ＿Ｂｕｆｆｅｒｉｎｇ＿Ｄｕｒａｔｉｏｎ」はセッションレベルパラメータである。
（Ｄ．ＲＴＰパケットの連続的ロス）
このパラメータは、メディアチャネルにつき連続で失われたＲＴＰパケットの数を示す。

ＱｏＥ−フィードバックヘッダの「Ｍｅｔｒｉｃｓ−Ｎａｍｅ Ｓｕｃｃｅｓｓｉｖｅ＿Ｌｏｓｓ」に対する例示的かつ非限定的なシンタックスは、［１］の節５．３．２．３．２に定義されたとおりである。

イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。「Ｍｅｔｒｉｃｓ−Ｎａｍｅ Ｓｕｃｃｅｓｓｉｖｅ＿Ｌｏｓｓ」について、「値」フィールドは、ＲＴＰパケットの数が連続して失われることを示す。このメトリックの単位は整数として表され、１以上であり得る。連続のロスがレポート期間に二度以上生じる可能性がある。その場合、連続ロスの数を示すメトリクス値が二度以上生じる場合がある。

オプションの「タイムスタンプ」は、パケットロスの連続が生じた時間を示す。「タイムスタンプ」の値は、レポート期間の開始時間に比べて、プレイバック順でレポート期間内に、パケットロスの連続発生の前に最後に受信したＲＴＰパケットのＮＰＴ時間と等しい。レポート期間内およびロスの連続の前に受信ＲＴＰパケットがない場合、タイムスタンプは、レポート期間の開始時間に設定される。

シーケンス番号情報を備えたＲＴＰロスの十分な動作の長さの（ｆｕｌｌ ｒｕｎ ｌｅｎｇｔｈ）エンコーディングが所望される場合、連続ロスのメトリックの代わりにＲＴＣＰ ＸＲ［５］ロスＲＬＥレポートブロックが使用されるべきである。

Ｅ．フレームレート偏差
フレームレート偏差はプレイバックフレームレート情報を示す。フレームレート偏差は、レポート期間中に実際のプレイバックフレームレートが所定の値から逸脱する場合に起こる。

実際のプレイバックフレームレートは、レポート期間のうち、レポート期間に再生されたフレーム数を秒の時間継続で割ったものに等しい。

所定のフレームレート値を示すパラメータＦＲは、「Ｆｒａｍｅｒａｔｅ＿Ｄｅｖｉａｔｉｏｎ」パラメータと共に「３ＧＰＰ−ＱｏＥＭｅｔｒｉｃｓ」ヘッダにおいて用いられる。サーバ１００は、ＦＲの値を設定することができる。「測定スペック」（［１］の節５．３．２．３．１）に含まれるべきＦＲに対する例示的かつ非限定的なシンタックスは、以下のとおりである：
ＦＲ＝“ＦＲ”“＝”１＊ＤＩＧＩＴ「．」１＊ＤＩＧＩＴ
ＱｏＥ−フィードバックヘッダのメトリクス名「Ｆｒａｍｅｒａｔｅ＿Ｄｅｖｉａｔｉｏｎ」に対する例示的かつ非限定的なシンタックスは、節５．３．２．３．２に定義されたとおりである。この定義には、「測定」の「タイムスタンプ」がこのメトリックに対して定義されていないという例外がある。イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。

メトリクス名「Ｆｒａｍｅｒａｔｅ＿Ｄｅｖｉａｔｉｏｎ」について、「値」フィールドはフレームレート偏差値を示す。それは実際のプレイバックフレームレートを引いて所定のフレームレートと等しい。このメトリックはフレーム／秒と表され得、フラクタルの値であり得、負であり得る。メトリック値は、例示的かつ非限定的な一実施形態において、このメトリックに対して一度のみ生じることができる。

Ｆ．ジッタ継続期間
ジッタは、実際の再生時間と予定再生時間との間の絶対差が所定の値、１００ミリセカンドより大きい、場合に起こる。フレームの期待時間は、例示の一実施形態において、最後に再生されたフレームの実際の再生時間 プラス フレームのＮＰＴ時間と、最後に再生されたフレームのＮＰＴ時間との間の差に等しい。

ＱｏＥ−フィードバックヘッダのメトリクス名「Ｊｉｔｔｅｒ＿Ｄｕｒａｔｉｏｎ」に対する、例示的かつ非限定的なシンタックスは、［１］の節５．３．２．３．２に定義されたとおりである。

イベントが存在しないことは、スペース（ＳＰ）を用いてレポートすることができる。

メトリクス名「Ｊｉｔｔｅｒ＿Ｄｕｒａｔｉｏｎ」について、５．３．２．３．２の「値」フィールドは、プレイバックジッタの時間期間を示す。このメトリクスの単位は秒で表され、小数値であり得る。ジッタがレポート期間に二度以上生じる可能性がある。その場合、ジッタのイベントの数を示すメトリック値が二度以上生じる場合がある。

オプションの「タイムスタンプ」フィールドは、レポート期間の開始以来ジッタが生じた時間を示す。「タイムスタンプ」の値は、レポート期間の開始時間に比べて、プレイバックジッタにおいて最初に再生されたフレームのＮＰＴ時間と等しい。

ＩＩＩ．ＱｏＥサーバモジュール
図４は、サーバ１００内のＱｏＥサーバモジュール１０８を一実施形態によって示す。ＱＯＥサーバモジュール１０８は、通信しているメディア上に、ネットワーク状態、クライアントの特性等を含む、いくつかの影響を計る要因である。ＱＯＥサーバモジュール１０８は、クライアント１０２からフィードバックを収集することによってそれを行う。

ＱｏＥサーバモジュール１０８の様々な実施形態の特性および特徴を、以下のように記述することができる。

１．ＱｏＥサーバモジュール１０８は、ストリーミングサーバ（例えばサーバ１００）上で存在することができる。

２．ＱｏＥサーバモジュール１０８は、ｒｔｓｐプロキシ、またはその他の適切なネットワーク機器上で存在することができる。

３．ＱｏＥサーバモジュール１０８は、以下のように、様々なプロトコル４１２からの入力を読み込むことができる
○ ＱｏＥプロトコル（先に説明したもの、および［１］に説明したもの）を介したＱｏＥメトリクス
○ ＲＴＣＰメトリクス［４］
○ ３ＧＰＰリンク特性［Ｉ］
○ ＲＴＣＰ ＸＲ［５］
４．ＱｏＥサーバモジュール１０８構成は、ＳＤＰファイルに格納されるか、あるいはサーバ／プロキシによって生成され得る。例示の構成パラメータを図４中の４１０に示す。

５．ＱｏＥサーバモジュール１０８はＤＢＡモジュール１０４と対話する：
○ 統計的なＱｏＥ結果に基づいて、ビットレートを増加させるように決定に影響するために
○ 主観的なＱｏＥ結果に基づいて、ビットレートを増加させるように決定に影響するために
○ 統計的なＱｏＥ結果に基づいて、ビットレートを減少させるように決定に影響するために
○ 主観的なＱｏＥ結果に基づいて、ビットレートを減少させるように決定に影響するために
○ 以下の特性もまた、主観的および／または統計的なＱｏＥ結果に基づいて、増加／減少または影響／変更され得る。：フレームレート、リフレッシュ間隔および動作、エラーに対する柔軟性、バッファ動作、最大フレームサイズ、ピークビットレート、フラグメンテーション、再送信、および／または他の特性。
○ ＤＢＡモジュール１０４がオンにされる場合：
・ＱｏＥは速度の適合（設定可能である）に影響し得る。
・一実施形態において、レポートは、ＤＢＡモジュール１０４によって制御される。
○ ＤＢＡモジュール１０４がオフにされる場合：
・ＱｏＥサーバ１０８は、一実施形態においては速度の適合に影響しないが、別の実施形態においては速度の適合に影響し得る。
・一実施形態において、レポートは、ＱｏＥサーバ１０８によって制御され、別の実施形態においては、他のモジュールまたはコンポーネントによって制御される。
○ ＤＢＡ、ＱｏＥモジュール１０４および１０８の両方がオフにされる場合、一実施形態において、レポートはＱｏＳモジュール１０６によって制御される。

６．ＱｏＥサーバモジュール１０８は、以下のモードのうち、一方または両方において動作することができる。：
○ 統計モード
○ 主観モード
○ 詳細：
クライアント１０２からサーバ１００へ返ってくるメトリクスは多くの方法でＱＯＥサーバＭｏｄｕｌｅｌ０８内で編成されて使用され得る。１つの方法は「統計モード」である。ここで、ＱＯＥサーバモジュール１０８は、最小、最大などの形でメトリクスの統計を編成する。別の方法は「主観モード」である。ここで、ＱＯＥサーバモジュール１０８は、受信したメトリクスを、サービス品質のクラスにそれらをマッピングすることによって編成する。したがって、たとえば、メトリクスを見た後、ＱＯＥサーバモジュール１０８は特定のメトリックがＭＥＤＩＵＭ品質クラスに属することを決定し得る。したがって、この情報を確認目的に使用することが可能であり得る。たとえば、クライアント１０２がＨＩＧＨクオリティのクラスに加入している場合でも、この特定のセッションについては、サーバ１００が受信したメトリクスに基づき、このセッションは単にＭＥＤＩＵＭクオリティのクラスに属するということが決定されよう。そのため、このような情報は多目的において有用である。ＱＯＥサーバモジュール１０８が受信するメトリクスの多くの他の分析が潜在的に存在し得る。

７．ＱｏＥ統計モード：
○ メディアレベルまたはセッションレベルにおいて算出される。
○ 単一の期間あるいは全体のセッション間に測定される
○ 少なくとも以下の、最小、最大、平均およびｓｔｄ偏差を計算する：
・コラプション継続期間（先に説明し、［１］においても説明した）
・再バッファリング継続期間（先に説明し、［１］においても説明した）
・初期バッファリングの継続期間（先に説明し、［１］においても説明した）
・連続ロス（先に説明に、［１］においても説明した）
８．ＱｏＥ主観モード：
○ メディアレベルまたはセッションレベルにおいて算出される
○ 全体のセッション（単一の期間のレポートはない）の間測定される
○ 所定のＱｏＳクラスにマッピングを提供する。
・最大成果のクラスまたはストリーミングのクラス
・低い、中度の、あるいは高いＱｏＥクラス
○ 可能な問題位置の隔離を提供する
・リンク層
・ネットワークプロトコルスタック
・コーデックスタック問題
・クライアントアプリケーション問題
・クリップ問題
・その他
９．ＱｏＥレポートは以下のものに統合され得る。
○ モニタリングシステム
○ ビリングシステム（ハンドセットが確証された場合）
一実施形態において、ＤＢＡモジュール１０４、ＱｏＳモジュール１０６およびＱｏＥサーバモジュール１０８は、ともにレポートするモジュール４００の一部を含むことができる。サーバ１００には、レート交換モジュール４０２等の追加モジュールが存在し得る。簡潔さのために、そのような追加モジュールの詳細な説明はここではしない。

上記の、ＱｏＥ関連の動作および他の動作のうち、少なくとも一部は、ソフトウェア、あるいは１つ以上の機械可読媒体４０６上に格納された他の機械可読の命令４０４において具体化され得る。そのような機械可読媒体４０６はサーバ１００、クライアント１０２、または他の適切なネットワーク位置に位置し得る。１つ以上のプロセッサ４０８は、プロセッサ４０８が、その上に格納されたソフトウェア４０４を実行することを可能にするために、記憶媒体４０６に接続される。

ＩＶ．ＱｏＥクライアントモジュール
一実施形態のＱｏＥクライアントモジュール１１８は、クライアント１０２に基づく。

ＱｏＥクライアントモジュール１１８は、検討される任意の数に基づいたセッションに対してＱｏＥメトリクスのオン／オフの切り替えを決定することができる。そのような検討の１つは、たとえば、規則的な動作を妨害し得る低いバッテリパワーである。

ＱｏＥクライアントモジュール１１８は、セッションの初めにメトリクスをオンにすることを決定した後、セッションの途中でメトリクスをオフにすることができる。この決定は、収集しているメトリクスの非有効性、または他の理由を含む、多数の理由によって影響を受け得る。

ＱｏＥクライアントモジュール１１８は、サポートするメトリクスのセットから特定のセッションの間どれをサポートするか、取り上げて選択することができる。この決定は、メトリクス計算の複雑さ、過去の経験、あるいは他の検討によって影響を受け得る。そのようなメトリックの選択は、サーバ１００とのネゴシエーションに使用され得る。

ＱｏＥクライアントモジュール１１８は、セッションの初めにおいて、あるメトリクスを測定することを認めた後、セッションの途中でそのメトリクスを選択的にオフにすることを決定できる。ＱｏＥクライアントモジュール１１８は、そのようなメトリクスをレポートする周波数を選択することもできる。周波数の選択は、サーバ１００とのネゴシエーションに使用され得る。ＱｏＥクライアントモジュール１１８は、メトリクスが測定されるセッションの範囲を選択することができる。範囲選択は、サーバ１００とのネゴシエーションに使用され得る。一実施形態のＱｏＥサーバモジュール１０８および／またはＱｏＥクライアントモジュール１１８は、メトリクスのリスト、メトリクスのレベル（メディア／セッション）、メトリクスの周波数、およびセッション中のメトリクスの範囲を変更することができる。

ＱｏＥクライアントモジュール１１８は、メトリック値を、ダイナミックに測定することができるか、そうでなければ、サーバ１００によって受信されたメディアをデコーディングまたは処理しながら、「オンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）」でメトリック値を求める。デコーディングおよび／または処理サイクルからの結果は、メトリック収集プロセスの間使用され得る。

ＱｏＥクライアントモジュール１１８は、様々なレベル（たとえばアプリケーション、ネットワーク、コーデック、その他）においてデータを収集することができる。次いで、ＱｏＥクライアントモジュール１１８は、メトリクスのうちの一部を決定するためにそのようなデータを集合的に使用することができる。

ＱｏＥクライアントモジュール１１８は、クライアント１０２の、経験の質に関連する任意または無意識の動作を識別することができる。ＱｏＥクライアントモジュール１１８は、測定したメトリクスの統合を維持することができる。ＱｏＥクライアントモジュール１１８は、そのような選択が利用可能な場合、これらのメトリクスの伝送手段を選択することができる。

一実施形態において、ＱｏＥクライアントモジュール１１８は、まだ収集している間に、メトリクス（たとえば周波数およびメトリクスの範囲）の構成を変更することができる。さらに、メトリクスは、セッションレベルのメディアおよびストリームレベルのメディア（たとえばオーディオ、ビデオ、個別または組み合わせて）に適用可能であり得る。

上記のＱｏＥ関連の動作および他の動作のうちの少なくとも一部は、ソフトウェア、あるいは１つ以上の機械可読媒体４０６上に格納された他の機械可読の命令４０４において具体化され得る。そのような機械可読媒体４０６は、サーバ１００、クライアント１０２、および／または他の一部の適切なネットワーク位置に位置することができる。１つ以上のプロセッサ４０８は、プロセッサ４０８が、その上に格納されたソフトウェア４０４を実行することを可能にするために、記憶媒体４０６に連結される。サーバ１００および／またはクライアント１０２のモジュールのような様々なコンポーネント、が、ソフトウェア（または他の機械可読の命令）、ハードウェア、ならびに／またはその両方の組合せにおいて具体化され得る。

本明細書中で言及され、および／または出願データシートに列挙された、上記の米国特許、米国特許出願刊行物、米国特許出願、外国特許、外国特許出願および非特許文献の全てについて、その全体の内容を援用する。

図示した実施形態の上記記載は、要約書に記載されたものも含めて、網羅的、あるいは開示された厳密な形態に本発明を限定するものとして意図されたものではない。特定の実施形態および例を、例示の目的のために本明細書に記載したが、様々な均等な修正が本発明の範囲内で可能であり、本発明の精神および範囲から逸脱することなくなされ得る。

たとえば、様々な実施形態を本明細書に記載したが、ある特定の通信プロトコル、規格、フォーマット、シンタックスおよびその他同種のもの、というコンテクストにおいて、他のタイプの通信プロトコル、規格、フォーマット、シンタックスおよびその他同種のものに対し、他の実施形態が提供され得る。本発明は、本明細書に記載した特定の通信プロトコル、規格、フォーマット、シンタックスおよびその他同種のものに限定されない。実施形態は、音声メディアおよびビデオメディアのストリーミングのみならず、メディア配信およびメディア消費の他の形式にも適用可能である。

上記の詳細な説明に鑑みて、これらの修正および他の修正が本発明に対してなされ得る。以下の請求項において使用する用語は、本発明を本明細書および請求項に開示された特定の実施形態に限定するものと解釈されるべきではない。さらに、本発明の範囲は、以下の請求項において完全に決定されるべきものであり、請求項の解釈の確立された原則に従って解釈されるべきである。

図１は、一実施形態によるＱｏＥフレームワークの構成要素とその動作とを示す、機能ブロック図である。 図２は、ＱｏＥネゴシエーションの第１の実施形態を示す。 図３は、ＱｏＥネゴシエーションの別の実施形態を示す。 図４Ａは、より詳細に示した、図１のＱｏＥフレームワークに対するＱｏＥモジュールの一実施形態のブロック図である。 図４Ｂは、より詳細に示した、図１のＱｏＥフレームワークに対するＱｏＥモジュールの一実施形態のブロック図である。

Claims (28)

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. 前記ＱｏＥモジュールが前記サーバに位置し、前記装置が、該ＱｏＥモジュールと協働して少なくとも１つの目的のために該メトリックデータを適用するための、少なくとも１つの別のモジュールをさらに備える、請求項２５に記載の装置。
28. 前記ＱｏＥモジュールが、ネゴシエーション手段を含み、該ネゴシエーション手段は、
    前記ネゴシエーションを開始することと、
    どのメトリックが前記サーバまたは前記クライアントのいずれか、あるいは両方によってサポートされるかを決定することと、
    該ネゴシエーション中に提案されたＱｏＥメトリックの受け取りを認めることと、
    ＱｏＥメトリックを修正し、このようなＱｏＥメトリックが認められ得るかを決定するために再ネゴシエーションすることと、
    任意の初期のＱｏＥメトリックまたは修正されたＱｏＥメトリックを、認めるかまたは拒否することと、
    ＱｏＥメトリックが該セッション中に通信される方法を決定することと、
    該セッション中のＱｏＥメトリックの通信周波数を決定することと、
    ＱｏＥメトリックの範囲を決定することと、
    ＱｏＥメトリックのレベルを決定することと、
    ＱｏＥメトリックの構成を決定することと、
    ＱｏＥメトリックを該セッション中に無効化する方法を決定することと、
    メトリック値のパラメータを決定することと、
    最後の１つ以上の認められたＱｏＥメトリックへの相互同意を含め、所定の条件が満たされた場合にネゴシエーションを終了することと
    のうちのいずれか１つ以上のためのものである、請求項２５に記載の装置。

Images