(57)【特許請求の範囲】
【請求項１】
サーバーとクライアント間の無線ネットワークにおけるパケット交換ストリーミングの品質指標を報告する方法であって、
リアルタイム・ストリーミング・プロトコルを用いて、コンテンツ・データを前記サーバーから前記クライアントへ配信する工程と、
信頼性の無い伝送メカニズムを用いて、前記配信されたデータ・ストリームに関する少なくとも１つの品質指標を前記クライアントから前記サーバーへ報告する工程と、
信頼性のある伝送メカニズムを用いて、前記配信されたデータ・ストリームに関する少なくとも１つの品質指標を前記クライアントから前記サーバーへ報告する工程と、
を具備し、
前記信頼性のある伝送メカニズムを用いて報告される前記品質指標は、前記クライアントにより生成されたＩフレーム数もしくはＰフレーム数、セッションの継続中に測定されたビデオフレームレートの最小値、平均値および最大値のうちの少なくとも１つ、前記クライアントがデータを再バッファリングした回数、前記クライアントがバッファリングに要した時間長、または前記クライアントからのストリーム要求と前記クライアントにより表示された最初のデータ・パケットとの間の時間長であることを特徴とする方法。
【請求項２】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は定期的に繰り返されることを特徴とする、請求項１記載の方法。
【請求項３】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標はセッションの進行中に送信されることを特徴とする、請求項１または２に記載の方法。
【請求項４】
前記信頼性のない伝送メカニズムは、ＲＴＰの拡張報告ＸＲを利用することを特徴とする、請求項１から３のいずれかに記載の方法。
【請求項５】
前記信頼性のある伝送メカニズムを用いて報告される前記品質指標は、セッション中またはセッションの終わりに送信されることを特徴とする、請求項１から４のいずれかに記載の方法。
【請求項６】
前記信頼性のある伝送メカニズムは、ＴＣＰを含む信頼性のあるトランスポートプロトコルを用いることを特徴とする、請求項１から５のいずれかに記載の方法。
【請求項７】
前記信頼性のある伝送メカニズムを用いて報告される前記品質指標は、前記サーバーの要求に応じて送信されることを特徴とする、請求項１から６のいずれかに記載の方法。
【請求項８】
前記信頼性のある伝送メカニズムを用いて報告される前記品質指標は、セッション中には、前記サーバーから前記クライアントへの能動的な要求に応じて送信され、セッションの終わりには、前記サーバーから前記クライアントへの能動的な要求なしで送信されることを特徴とする、請求項５記載の方法。
【請求項９】
前記信頼性のある伝送メカニズムはＲＴＳＰプロトコルであることを特徴とする、請求項１から８のいずれかに記載の方法。
【請求項１０】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標はパケット並び替えの度合であることを特徴とする、請求項１から９のいずれかに記載の方法。
【請求項１１】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、最も最近受信したシーケンス番号であることを特徴とする、請求項１から１０のいずれかに記載の方法。
【請求項１２】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、正しく受信されたコンテンツ・パケット数であることを特徴とする、請求項１から１１のいずれかに記載の方法。
【請求項１３】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、予測されるコンテンツ・パケット数または損失コンテンツ・パケット数であることを特徴とする、請求項１から１２のいずれかに記載の方法。
【請求項１４】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、連続で損失したコンテンツデータ・パケットの最小値、平均値および最大値のうちの少なくとも１つであることを特徴とする、請求項１から１３のいずれかに記載の方法。
【請求項１５】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、パケット遅延の最小値、平均値および最大値のうちの少なくとも１つであることを特徴とする、請求項１から１４のいずれかに記載の方法。
【請求項１６】
前記信頼性のない伝送メカニズムを用いて報告される前記品質指標は、パケットジッタであることを特徴とする、請求項１から１５のいずれかに記載の方法。
【請求項１７】
前記信頼性のない伝送メカニズムを用いて報告されるべき前記品質指標が所定の期間受信されなかった場合、前記サーバーは、前記クライアントからの、前記信頼性のある伝送メカニズムを用いた品質指標の送信を要求することを特徴とする、請求項１から１６のいずれかに記載の方法。
【請求項１８】
前記サーバーは、信頼性のある伝送から信頼性のない伝送へ、または信頼性のない伝送から信頼性のある伝送へ、少なくとも１つのパラメータを移すことを特徴とする、請求項１から１７のいずれかに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケット交換ストリーミングの品質指標を報告する方法に関する。本発明は特に３ＧＰＰストリーミング・サービス（ＰＳＳ）に好適であるが、これに限定されるものではない。
【背景技術】
【０００２】
通常、サービス提供者（サーバー）がクライアントに配信されるビデオストリームの受信品質に関する情報を必要とする３ＧＰＰパケット交換ストリーミング・サービス（ＰＳＳ）においては、品質指標が報告に用いられる（例：3GPP TS26.234 V5.3.0、第５版参照）。サーバー側で当該情報を収集するには、クライアントは受信品質に関するフィードバック情報をサーバーに送信する必要がある。介在するネットワークおよびクライアント自身の状態がビデオストリームの受信品質に影響を及ぼすことがあるため、当該情報はクライアント側でのみ生成が可能である。コンテンツの品質（例：粗悪なビデオ符号化による粗悪品質）ではなく、配信品質に関する情報が評価の対象となるため、報告される指標は客観的なものとなる（例：ストリーミング・セッション中に損失したパケット数）。当該指標はすべて主観的ではなく客観的であるので、ユーザーとのやり取り無しに自動的にクライアント側で生成が可能である。
【０００３】
３ＧＰＰネットワークにおけるパケット交換ストリーミング・サービスは、有線インターネットでのストリーミング用に考案されたメカニズムに基づく。従って、ＲＴＳＰがストリーミング・セッションの制御に用いられる一方で、ＲＴＰ／ＲＴＣＰ等の既知の転送プロトコルは、データ伝送（実際のストリーミング）に用いられる。標準化されたメカニズムでは、受信者側で知覚された品質について品質指標を報告するには十分ではないことがこれまでに明らかになった。例えば、ＲＴＣＰの受信者報告（receiver report）により伝送される情報では、送信者はグループ・メンバー数、受信者までのＲＴＴ推定、損失したパケットの累積数等、配信ストリームの品質に関する基本的な指標のみ得ることができる。これらの指標は、各受信者へのストリーミング品質をサーバーに通知するには十分ではない。例えば、損失パケットの累積数からは、当該損失が発生したＲＴＴについて、あるいはどのパケットが実際に受信もしくは損失されたかについて、正確な情報を得ることはできない。この事実は、サーバーによる適切な適応（レートと品質）と請求方式の適用とを妨げることになり、ストリーミング・サービスが普及するに従って、より重大になる。従って、拡張されたメカニズムが必要となる。要約すると、ＲＴＣＰに基づく品質指標報告には、大きく２つの問題がある。
【０００４】
ＲＴＣＰメッセージ用に用いられる伝送プロトコル（通常はＵＤＰ）は信頼性がなく（unreliable）、したがって信頼性をもって（reliably）品質指標を判断することが不可能である。
【０００５】
ＲＴＣＰ受信者報告に含まれる情報は非常に限られたものであり、オペレータに個別の品質指標を特定させるほどの自由度を与えるものではない。
【０００６】
３ＧＰＰ  ＰＳＳの概要とこれに用いられるプロトコルについては、3GPP TS26.234 V5.3.0 第５版に示されている。ＲＴＣＰは、ＲＴＰ用の制御プロトコルであり、ＲＴＰに基づいたデータ伝送に関する制御情報の配信に用いられる。ＲＴＣＰにおける２つの主なメッセージ種別は、ＲＴＰを介して伝送されるデータに関する情報の交換に用いられる、送信者報告および受信者報告である（例：送信者より送られるパケットの総数）。ＲＴＰセッションがＵＤＰに基づく場合、すなわちストリーミングの場合、ＲＴＣＰデータもＵＤＰを介して送信される。ＵＤＰは信頼性のない（unreliable）プロトコルであり、損失の生じないＲＴＣＰデータ伝送は保証されない。ＲＴＣＰメッセージが帯域幅を過剰に消費するのを防ぐため、ＲＴＣＰ送信者報告および受信者報告は、ある間隔でのみ送信が可能である（例：５秒毎に１つの受信者報告）。従って、送信者報告と受信者報告とを介して送信できる情報は非常に制限され、有用な品質指標を迅速に生成するには十分でない場合が生じる。特に、ＲＴＣＰは典型的な基本指標として、送信者から各受信者までのＲＴＴ推定、遅延ジッタ、損失パケットの累積数、最大受信シーケンス番号、送信者から送られたパケット計数を与える。
【０００７】
先に述べたように、これらの指標は非常に制限されたものであり、かつ拡張性に乏しいため、ＭＰＥＧ４ビデオおよびＡＭＲオーディオ等の新規および既存のアプリケーションは、各受信者の受信品質を適切に報告するための指標セットを有さない。
【０００８】
ＲＴＳＰは、ＰＳＳにおいてストリーミング・セッションの制御および設定に用いられるシグナリングプロトコルである。これにより、クライアントは、ストリームを開始または停止したり、ストリームの任意の時間位置に飛ぶことができる。通常、ＲＴＳＰデータはＴＣＰプロトコルを介して確実に送信される。制御情報の次に、データ伝送特性に関する付加的な情報がＲＴＳＰを介してサーバーとクライアント間で交換される。さらに、特定の情報をストリーミング・セッション中に交換することができる。
【０００９】
品質指標は、クライアントからサーバーに報告される特定のパラメータ・セットを定義し、品質指標により、オペレータは、クライアントへのストリーム配送の品質を判断することができる。これらの品質指標から得られる情報の利用方法は多岐に亘り、例えば、課金モデルをこれらの情報に基づかせてもよいし、あるいは、オペレータが単に自身の統計用に当該データを収集してもよい。現在のところ、あらゆる種類のアプリケーションに対応するパラメータ・セットは知られていない。また、将来、特定の一のパラメータ・セットが、あらゆるオペレータの要求に適合するかについては議論の余地がある。ＲＴＣＰによって与えられる、損失パケット総数、クライアントまでのＲＴＴ概算推定および遅延ジッタ推定のような、あらゆる場合に必要となる限られた品質指標セットは確かに存在する。しかし、特定のフォーマットで符号化されたコンテンツがストリーミングされる場合に、この他のパラメータが重要となる上に、多くの特定用途向けパラメータが存在する。
【００１０】
オペレータが品質指標をどのように使用するかは完全には明らかではないので、あらゆる種類のアプリケーションに対して、オペレータがそれら自身の品質指標を定義することができるよう解決法を見出すことが望ましい。しかし、これは本発明の範囲を超える。各パラメータに対してどの種類の伝送が必要かおよび各パラメータに対して責任があるのはどのピアかといった伝送に関する品質指標の課題は、サーバーおよびクライアントには周知であるものとする。
【発明の開示】
【００１１】
要約すると、既存の方法は、ＰＳＳにおいてクライアントからサーバーへ品質指標を報告するための限定的な可能性のみを与えるものであり、クライアント側で受信されたビデオストリームの品質に関する詳細かつ正確な報告をオペレータが得るには十分ではない。
【００１２】
従って、本発明の目的は、ＰＳＳ用の品質指標を報告する方法を提供することであり、これによりオペレータに付加的な情報を与えることができる。この目的は請求項１に記載の方法により実現される。本発明の方法の好ましい実施態様については、各従属請求項に対応する。
【００１３】
本発明の基本的な思想は、クライアントからサーバーへの品質指標の報告について、信頼性のない（unreliable）伝送メカニズムと信頼性のある（reliable）伝送メカニズムとを組み合わせることである。例えば、信頼性はない（unreliable）が最低限の品質指標は、標準的なＲＴＣＰ受信者報告から得ることができる。この情報は常に入手可能であるので、クライアントから付加的な情報が提供されない場合には、これを最低限の情報として使用しなくてはならない。
【００１４】
また、品質指標により、サービス品質に関し統計的測定が可能になる。この情報は、クライアントに対してより良い品質で配信するための、例えば、ネットワーク管理上の判断、あるいは、レート適応やデータ・パケットの適正なスケジューリング等のストリーミング適応に用いることができる。こうしてオペレータはネットワーク状態に関する情報を取得し、配信された品質が多くの場合に一定レベルに達しない場合に、対応策をとることができる。
【００１５】
配信された品質に関する情報をユーザー課金に用いることもできる。ユーザーが非常に粗悪な品質のデータ・ストリームを受信したことを品質指標が示す場合、当該サービスの課金率を、完全な品質のストリームを受信したユーザーと比較して低減することができる。クライアントは実際に体験した品質に対する対価を払うので、この目的のためには、表示されたＩフレーム総数あるいはクライアントが再バッファリングを要した回数のような特定の配信パラメータ値が必要となる。
【００１６】
品質指標に用いられるパラメータは、２つのカテゴリーに分類することができる。１つのグループは、定期的にしかし信頼性なく（unreliably）送信されるパラメータにより定義され、もう一方のグループは、信頼性をもって（reliably）送信されるパラメータにより定義される。第１のグループの例は、送信パケットの総数に対する損失パケットの比であり、一方、クライアントによる再バッファリング量は第２グループの例である。特に、第２のグループに関しては一度のみ送信されるので、これらのデータは確実に（reliably）送信されることが重要である。このデータの損失は致命的であり、サーバー側で当該品質指標を入手できないことを意味する。これは、定期的に送信される受信パケット数のようなデータとは異なる。損失の意味するところは、当該情報を含む新しいデータがサーバーに到着するまで、サーバー側で入手可能な情報は誤った情報であるということである。
【００１７】
さらに、サーバーは、特定の品質指標を信頼性のある（reliable）方法でクライアントから送信させる要求を行う機会を有する。このことも、信頼性なく（unreliably）送信されたデータがより長い期間に亘ってサーバーに到達していない場合に有用である。これによっても、クライアント・アプリケーションが正しく終了しなかった場合（例：アプリケーションが破損した場合）でも、サーバーは情報を取得できる。この場合のデータは最新ではないかもしれないが、サーバーは少なくとも何らかの情報を取得する機会を得る。
【００１８】
クライアントが再バッファリングした回数あるいはバッファリングに費やした合計時間に対する値など他のパラメータは、一度のみだが信頼性のある（reliable）方法で送信される。本発明の説明にここで用いる１つの可能性は、ストリーミング・セッションの終わりにＲＴＳＰプロトコルを用いてこれらのパラメータを送信することである。
【００１９】
品質指標の最小セット以外に、オペレータは、必要に応じて追加の指標を容易に定義できなければならない。従って、信頼性のある（reliable）伝送メカニズムと、信頼性のない（unreliable）伝送メカニズムのどちらにも対応できるメッセージ形式が必要となる。ＲＴＣＰの場合には、拡張報告（extended report）ブロック（ＸＲ）をこの目的のために用いることができる。ＲＴＳＰに関しては、プロトコル自身が意図的に漠然と定義された方法を含み、新規のパラメータを容易に組み込むことができる。例としては、GET_PARAMETERやSET_PARAMETER等の方法が挙げられる。
【００２０】
ネットワーク・オペレータ以外にも、コンテンツ・プロバイダも品質指標に関心を持つ場合があるということに留意すべきである。それらは、ストリーミングが十分な品質を持つことと、必要に応じて、例えば適正な符号化率を求めるために必要な変更を行って良好な品質を提供することとに大きな関心を持つからである。コンテンツ・プロバイダは、この品質指標無しには適切なコンテンツをオペレータへ提供することができない。
【発明を実施するための最良の形態】
【００２１】
以下添付図面を参照して本発明をさらに詳細に説明する。
【００２２】
図１に示すように、サーバーとクライアントとを含む代表的なシステムは、オペレータにより操作される無線通信ネットワークを備えて構成される。サーバーからクライアントへ配信の対象となるコンテンツは、サーバーに接続されたコンテンツ・プロバイダにより、事前にあるいはリアルタイムに提供される。クライアントへのコンテンツ・データの伝送には、サーバーはＲＴＰ／ＲＴＣＰを用いる。ＲＴＰセッションは、ＵＤＰ（信頼性のない（unreliable）プロトコル）の上（top）で送信され、またストリーミング・セッションの制御に用いられるＲＴＣＰデータもＵＤＰを介して送信される。クライアントは、特定の報告間隔で（ＵＤＰに基づいて）ＲＴＣＰメッセージまたはＴＣＰのように信頼性のある（reliable）トランスポートプロトコル上のＲＴＳＰを用いて、受信者報告を送信する。
【００２３】
本発明の方法では、品質指標の信頼性のある（reliable）伝送と信頼性のない（unreliable）伝送とを合わせた合成品質指標報告メカニズムを採用する。２つの伝送方法を用いることが出来るため、クライアントおよびサーバーは、品質指標伝送を調整するメカニズムを実現する必要がある。通常、クライアントは品質指標をサーバーへ能動的に送信する。一方、サーバーは、クライアントからの品質指標を能動的に要求し、クライアントは要求された情報を含むメッセージで応答する。
【００２４】
信頼性のない（unreliable）伝送に対しては、既存のメカニズムおよび（ＲＴＣＰの受信者報告および送信者報告等の）メッセージ形式を用いなければならない。オペレータは、付加的な品質指標の伝送を可能にするため、ＲＴＰ拡張報告ＸＲ等の拡張メカニズムを用いることができる。この周期的なメッセージは、オペレータが、時間の経過と共に品質指標（例：ストリーミング・セッションの最初の３分間に５３個のパケットが失われ、続く２分間に３３個のパケットが失われた）を取得できるという利点を有する。
【００２５】
信頼性のある（reliable）伝送としては、ＴＣＰに基づいたプロトコルを用いることができる。１つの可能性としては、ストリーミング・セッションで既に使用されているＲＴＳＰを活用することである。
【００２６】
図２に、合成品質指標報告の一例を示す。周期的かつ信頼性のない（unreliable）報告がストリーミング・セッション中に連続して送信される。サーバーは、ストリーミング・セッション中の特定の時点で特定の品質指標を要求する。クライアントは、要求された情報を確実に（reliably）送信することにより、この要求に応答する。また、ストリーミング・セッションの最後に、クライアントは、いくつかの品質指標を確実に（reliably）サーバーへ送信する。この新しい方法により、オペレータは所望の品質指標を得ることができ、一方、該報告により発生する付加的なトラヒックを最低限に保つことができる。
【００２７】
サーバーが特定の品質指標を具体的に要求できるようにするメカニズムは、３ＧＰＰ等の無線ネットワークにおいて特に有用である。このようなネットワークでは、例えばハンドオーバー中に、有線ネットワークよりも高い損失率が見込まれる。したがって、サーバーが、定期的かつ信頼性のない（unreliable）報告を長時間受信できない場合が生じる。本新規メカニズムにより、サーバーは、実際に必要に応じて、クライアントからこの情報を要求する機会を得る。
【００２８】
以下に、信頼性をもって（reliably）送信されるべき品質指標の例を説明する。
【００２９】
重要と考えられるパラメータには、クライアントにより表示されたビデオのＩフレーム数またはＰフレーム／Ｂフレーム数がある。また、セッションの継続時間に亘って測定される最小フレームレート、平均フレームレート、最大フレームレートは、さらに重要な品質指標を構成する。さらに、クライアントが再バッファリングした回数、あるいはクライアントがバッファリングに費やした時間長（秒）も重要な品質指標である。最後に、受信者からのデータ・ストリーム要求（すなわちＲＴＳＰの「Ｐｌａｙ」）と最初にレンダリングされたデータ・コンテンツ・パケットとの間の秒単位の時間長は、全ストリーム設定時間を示すパラメータを構成する。上述のように、上記の品質パラメータは全て、好ましくはセッションの終わりに、ＲＴＳＰ等の信頼性のある（reliable）伝送メカニズムを介して信頼性をもって（reliably）伝送されなければならない。
【００３０】
更に、品質指標の信頼性のない（unreliable）伝送のためのパラメータの例を説明する。以下に述べるパラメータは、例えばＲＴＰの拡張報告ブロックＸＲメカニズムおよびそこで定義されるメッセージ形式を用いて送信が可能である。
【００３１】
第１の指標はパケットの並び替えの度合であり、ＲＴＣＰ用の報告ブロック拡張を用いる。
【００３２】
同様に、連続で（in succession）およびメディア・チャネル毎に失われたコンテンツデータ・パケットの最小値、平均値または最大値は、信頼性のない（unreliable）伝送における好ましい品質指標である。
【００３３】
さらに、最小、平均または最大パケット遅延（ミリ秒単位）を送信してもよい。
【００３４】
代表的な品質指標は、最後に受信したＲＴＣＰシーケンス番号、すなわちメディア・チャネル毎に受信された最も最近のＲＴＣＰシーケンス番号により構成される。これは、ユーザーがデータ・ストリームをどこまで再生したかを判断する際に有用である。さらに別の例は、メディア・チャネル毎の、正しく受信されたコンテンツ・パケットの累積数である。受信者が損失パケットを報告するため、受信されたパケット数は送信者側で確定できる。同様に、メディア・チャネル毎に予測されるコンテンツ・パケット数は、サーバーから送られるＲＴＣＰの送信者報告（sender report）から導出することができる。最後に、パケット・ジッタは、遅延変動の量を構成する。
【００３５】
次に、本発明の方法をいかに実現するかを示すため、簡単な例を用いる。説明の簡単のため、以下の例では５つの品質指標のみが報告されるものとする。この小規模な指標セットは、例えば「3gpp-video-qos-profile-1」のように、ＰＳＳフレームワークの属性により予め定義されているものとする。また、各パラメータを（信頼性をもって、あるいは信頼性なく）送信する方法と、報告を行うまたは報告を照会するピアも、当該属性により定義されるものとする。「3gpp-video-qos-profile-1」は、この場合、ビデオ用のサービス品質（QoS: Quality of Service）指標のプロフィールを定義する。このことはサーバーとクライアントには既知であるものとする。例えば、特定のアプリケーションにおいて、いくつかのパラメータがそれほど重大な値でない場合、サーバーは、これらのパラメータを信頼性のある（reliable）伝送から信頼性のない（unreliable）伝送へ移すことができ、また、逆も可能である。正確な品質指標パラメータ・セットをネゴシエートする方法としてはいくつかの方法がある。以下にネゴシエーションの一例を示す。
【００３６】
ＲＴＳＰを介したクライアントとサーバー間の品質指標のネゴシエーションは以下のように始まる（Ｃはクライアント、Ｓはサーバーを表わす）。
C->S:DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq:1
Require:3gpp-video-qos-profile-1
【００３７】
サーバーが、このようなパラメータ・セットをサポートしない場合、次のように応答する。
S->C:RTSP/1.0 200 OK
CSeq:1
Unsupported:3gpp-video-qos-profile-1
【００３８】
一方、サーバーが、要求されたパラメータ・セットをサポートする場合、以下のように応答する。
S->C:RTSP/1.0 200 OK
CSeq:1
v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
u=http://foo/twister
m=video 0 RTP/AVPF 98
c=IN IP4 192.0.0.1
a=rtpmap:98 H263-2000/90000
a=fmtp:98 profile=3;level=10
a=3gpp-video-qos-profile-1:98
【００３９】
上記記述は、サーバーが、要求のあった品質指標報告プロフィールをサポートし、該品質指標報告プロフィールが（ペイロード・タイプ値９８を備えた）ビデオセッションに適用されることを示す。
【００４０】
上述のように、サーバーは、いくつかのパラメータを、信頼性のある（reliable）伝送から信頼性のない（unreliable）伝送へ移すよう決定できる。このとき、サーバーが「表示されたビデオのＩフレームあるいはＰフレーム／Ｂフレームの数」の品質指標をそれほど重要でないと判断した場合、この品質指標を以下のような方法で信頼性のない（unreliable）伝送用に設定することができる。
S->C:RTSP/1.0 200 OK
CSeq:1
v=0
o=alice 3203093520 3203093520 lNIP4 host.example.com
u=http://foo/twister
m=video O RTP/AVPF 98
c=IN IP4 192.0.0.1
a=rtpmap:98 H263-2000/90000
a=fmtp:98 profile=3;level=10
a=3gpp-video-qos-profile-1:98 n_i_P_frames=unreliable
【００４１】
上記記述は、サーバーが、要求のあった品質指標報告プロフィールをサポートし、該品質指標報告プロフィールが（ペイロード・タイプ９８を備えた）ビデオセッションに適用されることを示す。この場合、信頼性のある（reliable）伝送用の規定値「表示されたビデオのＩフレームあるいはＰフレーム／Ｂフレームの数」が信頼性なく（unreliably）送信され、サーバーもそのほうがより妥当であると判断する。
【００４２】
このネゴシエーションが成功しなかった場合、クライアントは別の品質指標プロフィールまたは別のファイルを要求することを決定できる。あるいは、サーバーは、当初信頼性のない（unreliable）伝送へ移そうとしたものを信頼性をもって（reliably）送信することができる。このことは実装向けであり、本書の範囲外である。
【００４３】
例えば、「3gpp-video-qos-profile-1」において、平均パケット遅延、最大パケット遅延およびパケット・ジッタの３つの指標が、ＲＴＣＰ報告拡張あるいはその他の方法を介してクライアントからサーバーに定期的に報告されるものとする。信頼性のない（unreliable）報告用の、ＲＴＣＰ報告拡張を用いたメッセージ形式の一例を以下に示す。
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      BT=0     |  app-specific |        block length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          name (ASCII)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Min_delay                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Ave_delay                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Max_delay                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
【００４４】
ストリーミング・セッションの最後に、クライアントは以下に示すように、他の２つの品質指標（再バッファリング回数および再バッファリング時間）をRTSP SET_PARAMETERメッセージを介して確実に（reliably）送信する。
C->S: SET_PARAMETER rtsp://foo/twisterRTSP/1.0
CSeq:12
Content-length:19
Content-type:text/parameters
Times rebuffrd:3
S->C: RTSP/1.0 200 OK
CSeq:12
C->M: SET_PARAMETER rtsp://foo/twisterRTSP/1.0
CSeq:13
Content-length:24
Content-type:text/parameters
Tot_time_rebuffrd:30
S->C:RTSP/1.0 200 OK
CSeq:13
【００４５】
上述のように、クライアントから自動的に生成される報告に加え、サーバーは、必要に応じてクライアントに１または２以上の品質指標を確実に（reliably）送信させることもできる。これは、例えば、定期的で信頼性のない（unreliable）報告が、一定の時間サーバーに到着していない場合である。ここでは前記３つの遅延指標を要求する一例を示す。
S->C: GET_PARAMETER rtsp://foo/twisterRTSP/1.0
CSeq:8
Content-length:24
Content-type:text/parameters
Min_delay
Avg_delay
Max_deIay
C->S: RTSP/1.0 200 OK
CSeq:8 
Content-length:24
Content-type:text/parameters
Min_delay:5
Avg_delay:6.7
Max_delay:10
【図面の簡単な説明】
【００４６】
【図１】本発明による方法を実行するための代表的なサーバー／クライアント構成。
【図２】本発明の方法を例示するための図式的な通信ダイアグラム。
【図１】
0004519835.tif 000002
【図２】
0004519835.tif 000003