サービス品質に関する埋込み情報の送信
本発明は、サービス品質関連情報の送信方法に関し、この情報は第１の装置（３０）と第２の装置（２０）との間で少なくとも１つの方向に送信される。第１の方法は、少なくとも上記装置（２０、３０）のうちの一方の装置において、上記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするステップと、上記サービス品質関連情報を上記プロトコルメッセージにアタッチするステップと、を具備するものである。第２の方法は、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に上記サービス品質関連情報を形成するステップを具備する。本発明は、対応するソフトウェアコード、装置（２０、３０）、ネットワークエレメント並びにシステムにも同様に関するものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス品質関連情報の送信方法に関し、この情報は第１の装置と第２の装置との間で少なくとも１つの方向に送信される。本発明は対応する装置、対応するネットワークエレメント並びに対応するシステムにも同様に関する。
【背景技術】
【０００２】
種々のサービスのうちの１つのサービスであって、そのサービスの品質に関する情報を送信する必要が生じる可能性があるサービスとして、ストリーミングクラスのサービスがある。
【０００３】
ストリーミングクラスのサービスを行うために、ストリーミングサーバはネットワークを介して媒体データをストリーミングクライアントへ送信し、それによってクライアント側で安定かつ連続したストリームとして媒体データの処理を行うことが可能となる。ストリーミング用アプリケーションの一例としてインターネット用ビデオ製品がある。ストリーミングサーバはネットワーク内に常駐することができる。
【０００４】
ネットワーク通信事業者やサービスプロバイダは、ストリーミングクライアントのユーザが知覚したサービス品質（ＱｏＳ）の評価に関心を持っている。現在、３ＧＰＰ ＴＳ２６.２３４の形で標準化されているプロトコルを用いて定義されているようなストリーミングセッションによって、知覚されたエンドユーザ品質に関する限られた情報量を知る可能性が提供されている。例えば、パケットロス、遅延ジッタ、受信した累積最大シーケンス番号に関する情報などのネットワークの振舞いに関する情報およびリアルタイムのトランスポートプロトコル（ＲＴＰ）パケットに関する他の情報をレポートするために、リアルタイムのトランスポート制御プロトコル（ＲＴＣＰ）受信レポートがクライアントによってサーバへ送信されている。ＲＴＣＰ送信レポートはサーバによってクライアントへ送信されるが、この送信レポートには送り手に関する情報が含まれている。
【０００５】
しかし、これらのレポートは、ストリーミングサーバや、ストリーミングサーバを経由する通信事業者が、例えば、ストリーミングクライアントから得られる破損ビデオフレームの数、再バッファの継続時間、オーディオギャップの継続時間などの知覚されたＱｏＳに関する付加情報を取得することを可能にするものではない。リアルタイムのトランスポート制御プロトコル（ＲＴＣＰ）レポート、ＲＴＣＰ拡張レポートあるいはＲＴＣＰ ＸＲパケットによって搬送される最新情報を拡張するだけで、ストリーミングクライアントからストリーミングサーバへこのような情報を伝えることが可能となる。このような拡張に含まれるものとして、セッションの確立および設定解除、スピーチギャップとオーディオギャップ、破損ビデオフレーム、再バッファリングと初期バッファリング、サクセション時に紛失したパケットに関する情報、並びに、セッションと媒体送信とに関する生じ得るその他の情報が含まれる１セットのＱｏＳメトリックがある。
【０００６】
ＩＥＴＦ ＲＦＣ２３２８（ＲＴＳＰ仕様、１９９８年４月）、ＩＥＴＦ ＲＦＣ３５５０（ＲＴＰ仕様、２００３年７月）並びにドラフトＲＴＰ制御プロトコル拡張レポート（ＲＴＣＰ ＸＲ、２００３年５月）によって、例えば、ストリーミングクライアントが、パケットロス部分、遅延ジッタ、受信最大シーケンス番号および一続きのパケットロスを含む、受信済みＲＴＰパケットに関する情報をレポートすることが可能となる。
【０００７】
２つの文書ドラフトＲＥＬ−６“ＰＳＳ品質メトリックパーマネント文書”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２７、２００３年７月７〜１１日、Ｔｄｏｃ Ｓ４−０３０５６２、および“ストリーム品質メトリック−クライアントメトリック”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２６、２００３年５月５〜９日、Ｔｄｐｃ Ｓ４−０３０３５３に、３ＧＰＰ（第３世代パートナープロジェクト）におけるＱｏＳメトリックについての追加の一般的問題点についての記載がある。第１の文書には、音声、オーディオ、ビデオ、プレイヤおよびネットワークメトリック用の２５個の異なるパラメータを用いてどのような情報を送るべきかについて記載があり、さらに、どのような種類のプロトコルを使用すべきかについての記載がある。さらに、第２の文書には高レベルの要件および技術上の考慮事項が定義されている。これらの文書は、要求時にクライアントが情報を計算し、この情報をサーバへ送信する方法を定義するものである。トランスポートを行うことを目的として、サーバからクライアントへ送信されるリアルタイムのストリーミングプロトコル（ＲＴＳＰ）ＧＥＴ−ＰＡＲＡＭＥＴＥＲメッセージと、クライアントからサーバへ送信されるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージとの利用が提案されている。
【０００８】
これらのメッセージは、文書“ストリーミング品質メトリック−トランスポート”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２８、２００３年９月１〜５日、Ｔｄｐｃ Ｓ４−０３０６２９にさらに詳細に定義されている。ＱｏＳメトリックをトリガするために、サーバからクライアントへのＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージの送信が提案されている。クライアントがＱｏＳメトリックの送信を受け入れれば、クライアントは応答としてＲＴＳＰ２００ＯＫメッセージを送信することができる。次いで、サーバは、メトリックセッション記述ＭＥＴＲＩＣＳ−ＳＥＴＵＰを含むさらに別のＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックセッション記述を送信することができる。メトリックセッション記述ＭＥＴＲＩＣＳ−ＳＥＴＵＰにはＲａｎｇｅ、ＰｅｒｉｏｄおよびＳｅｎｄｅｒパラメータが含まれる。また、このメッセージはＲＴＳＰ２００ＯＫメッセージを用いてクライアントにより受け入れられなければならない。上記とは別に、サーバは、ＱｏＳメトリックセッションの記述にＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを与えるようにクライアントに対して要求することができる。ＱｏＳメトリックセッションが記述され、同意が得られるとすぐに、クライアントは、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックを送信するか、サーバがＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックを検索するかのいずれかを行うことができる。
【０００９】
３つの複数対の必要なメッセージが遅延の原因となることがこのアプローチの欠点であり、この遅延によってセッションのセットアップがスローダウンする場合がある。この提案されたアプローチではセットアップの混同が生じることさえ考えられる。というのは、サーバからデータを取得するために、クライアントは第２のＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを受け取る前にすでに第１のメッセージを送信しているかもしれないからである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
例えば、エンドユーザが知覚したストリーミングクラスのサービス品質に関する情報をストリーミングサーバに提供するような、サービス品質関連情報の装置への提供を改善することが本発明の目的である。
【００１１】
２つの装置間でのセッションのセットアップを高速化し、セットアップの混同を防ぐことが本発明のさらに別の目的である。
【課題を解決するための手段】
【００１２】
本発明の第１の態様によれば、サービス品質関連情報の送信方法が提案され、上記情報は第１の装置と第２の装置間の少なくとも１つの方向に送信されるべきものである。上記提案された方法は、装置のうちの少なくとも一方の装置において上記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするステップと、上記サービス品質関連情報を上記プロトコルメッセージにアタッチするステップと、を具備する。上記提案された方法は上記第１の装置と上記第２の装置のそれぞれの相手方装置へ上記プロトコルメッセージを送信するステップをさらに具備する。
【００１３】
本発明の第１の態様によれば、さらに、サービス品質関連情報を送信するためのソフトウェアコードが提案される。上記情報は第１の装置と第２の装置との間の少なくとも１つの方向に送信されるべきものである。少なくとも上記装置のうちの一方の装置の処理用コンポーネントにおいて実行するとき、上記ソフトウェアコードは上記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルし、上記サービス品質関連情報を上記プロトコルメッセージにアタッチする。
【００１４】
本発明の第１の態様によれば、さらに、サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするため、且つ、他方の装置に送信されるべきサービス品質関連情報を上記メッセージにアタッチするためのアセンブリング用コンポーネントを具備する装置が提案される。上記装置は、上記アセンブリング用コンポーネントがアセンブルしたプロトコルメッセージを他方の装置へ送信する送信用コンポーネントをさらに具備する。同様に、ネットワークにアクセスする装置へサービス品質関連情報を送信するための対応する特徴を具備するこのネットワークのネットワークエレメントが提案される。
【００１５】
本発明の第１の態様によれば、少なくとも２つの装置を具備するシステムが提案される。第１の装置は上記提案された装置に対応するものである。第２の装置は、第１の装置が送信したプロトコルメッセージを受け取る受信ユニットと、サービス品質関連情報を受け取ったプロトコルメッセージからデタッチするデタッチ用コンポーネントとを具備する。
【００１６】
本発明の第１の態様は、ＱｏＳに関連する情報の少なくとも一部を、２つの装置間で何らかの方法で送信されるプロトコルメッセージにアタッチすることができるという考察に基づくものである。
【００１７】
この結果、メッセージの数が減少することになる。というのは、ＱｏＳ関連情報に関する専用メッセージの対が回避されることになるからである。
【００１８】
したがって、ＱｏＳ関連情報を送信するための、専用メッセージを利用する公知のアプローチと比べると、データ交換を高速化するさらに少ないシグナリング用オーバヘッドしか必要としなくなること、さらに高速なセッションのセットアップが可能となること、並びに、簡単な方法でより多量のＱｏＳ関連情報の交換が可能となることが本発明の利点である。例えば、考慮対象のＱｏＳデータのネゴシエーションを行うために、考慮したＱｏＳデータを２回以上送信するために、考慮対象のＱｏＳデータを現在進行中のセッション中に変更するために、あるいは、ＱｏＳデータの送信をセッション中に停止するために、上記のようなさらに多量のＱｏＳ関連情報を利用することも可能となる。ＱｏＳ関連情報がセットアップメッセージの中に含まれていれば、セットアップ中であっても混同を防ぐことが可能となる。プロトコルメッセージのアセンブリングと、このメッセージのＱｏＳ関連情報へのアタッチとを別個の後続するステップで実現することは可能ではあるが、これらを別々の後続するステップで実現する必要はないことを理解されたい。上記アタッチは、プロトコルメッセージのアセンブリの一部を形成するものであってもよい。例えば、プロトコルメッセージのヘッダフィールドの中などのような、プロトコルメッセージの任意の位置に、あるいは、プロトコルメッセージ本文に対する属性としてＱｏＳ関連情報をさらにアタッチすることも可能である。
【００１９】
本発明の第２の態様によれば、第１の装置と第２の装置間で少なくとも１つの方向に送信される、サービス品質関連情報のさらなる送信方法が提案される。提案されるこのさらなる方法は、上記装置のうちの少なくとも一方の側において、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に上記サービス品質関連情報を形成するステップと、上記第１の装置と上記第２の装置のそれぞれの相手方装置へ上記プロトコルメッセージを送信するステップと、を具備する。
【００２０】
本発明の第２の態様によれば、サービス品質関連情報を送信するためのソフトウェアコードがさらに提案される。この情報は、第１の装置と第２の装置との間で少なくとも一方の方向に送信されるべきである。少なくとも上記装置のうちの一方の装置の処理用コンポーネントで実行するとき、上記ソフトウェアコードは、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に上記サービス品質関連情報を形成する。
【００２１】
本発明の第２の態様によれば、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネントであって、上記サービス品質関連情報を一方の装置へ送信するようになっているアセンブリング用コンポーネントと、上記アセンブリング用コンポーネントによって提供されたプロトコルメッセージをこの他方の装置へ送信する送信用コンポーネントとを具備する装置がさらに提案される。同様に、このネットワークにアクセスする装置へサービス品質関連情報を送信するための対応する特徴を具備するネットワークのネットワークエレメントが提案される。
【００２２】
本発明の第２の態様によれば、少なくとも２つの装置を具備するシステムがさらに提案される。第１の装置は本発明の第２の態様に関連して提案された装置に対応するものである。第２の装置は、上記第１の装置が送信したプロトコルメッセージを受け取る受信ユニットと、受け取ったプロトコルメッセージからサービス品質関連情報を抽出するデタッチ用コンポーネントとを具備するものである。
【００２３】
本発明の第２の態様は、ＱｏＳ関連情報を送信するためのプロトコルメッセージのヘッダまたは属性が特段の利点を有するものであるという認識に基づくものである。というのは、このケースでは、単一の制御モジュールを利用して、プロトコルメッセージを分析し、ＱｏＳ関連情報を含む情報を抽出することが可能であり、次いで、抽出された情報をシステム内の必要なモジュールへ提供することが可能となるからである。
【００２４】
したがって、本発明の第２の態様は、例えば、ストリーミングクラスのセッションセットアップ中に、あるいは、ストリーミングクラスのデータ送信中に、ＱｏＳ関連情報の送信に用いらる新しく定義されたＲＴＳＰヘッダフィールドに基づくようにすることも可能である。
【００２５】
新たなＲＴＳＰヘッダまたは属性の利用に代る代替例として、ＱｏＳメトリックのシグナリングの新たなＲＴＳＰメッセージ定義の利用、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドの利用、および、ＲＴＳＰメッセージの最後におけるメッセージ本文の挿入、あるいは、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲとＧＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＴＳＰメッセージとして使用するためのＱｏＳメトリックと関連するパラメータセットの定義が挙げられる。ＱｏＳメトリックシグナリングをセッションレベルのシグナリングから完全に分離することを目的として、実施装置はＱｏＳメトリック用のＲＴＳＰヘッダフィールドの利用を選択しなくてもよい。
【００２６】
本発明の上記第１および第２の態様の双方を単一の実施構成で組み合わせることが可能であることを理解されたい。
【００２７】
排他的にというわけではないが、特に、本発明の上記双方の態様において、プロトコルメッセージは、ＲＴＳＰメッセージ、ＲＴＣＰメッセージ、セッション開始プロトコル（ＳＩＰ）メッセージあるいはセッション記述プロトコル（ＳＤＰ）記述とすることが可能である。このプロトコルがＲＴＣＰ送信よりも信頼性の高い柔軟性のある送信を提供することが上記提案された方法でＲＴＳＰメッセージを利用する特別の利点である。
【００２８】
排他的にというわけではないが、例えばストリーミングクラスのサービスなどのサービス品質が関わるサービスは本発明の双方の態様の中に存在することが可能である。特に、このようなストリーミングクラスのサービスのためにＲＴＳＰとＲＴＣＰとを利用することも可能である。したがって、上記提案された装置は、例えばストリーミングクラスのサービス、すなわち、ストリーミングクライアントまたはストリーミングサーバ用の受信ユニットあるいは送信ユニットとすることができる。本発明は、ストリーミングクライアントが実際にどのようにしてデータを受け取るかをストリーミングサーバが見つけ出し、さらに多くのユーザ経験の品質（経験のＱｏＥ−品質）に関する情報、並びに、ストリーミングセッションが遭遇するかもしれない諸問題に関する情報をストリーミングサーバが得ることができるようにするのに特に適した方法を提供するものである。
【００２９】
別のサービスとして、例えば、ＩＰ電話、ビデオ電話、あるいは片方向通話ビデオなども考えられる。特に、このような別のサービス用として会議用プロトコルＳＩＰの利用も可能である。
【００３０】
例えば、セッションを形成しながらおよび／またはそれぞれのサービスのための現在進行中のセッション中にプロトコルメッセージの送信を実行することが可能である。それぞれのプロトコルメッセージ内のＱｏＳ関連情報は、例えば、最新のサービスのために達成されたＱｏＳに関するレポートを含むものであってもよい。このレポートは、特に一方の装置が他方の装置へ提供するパラメータおよび／または未使用データを含むものであってもよい。この未使用データが例えばイベントや測定データに関する通知を含むものであってもよいのに対して、メトリックとも呼ばれているパラメータは処理済みの未使用データである。さらに、ＱｏＳ関連情報は、最新のサービスのための達成済みＱｏＳに関するこのような情報の提供を求める、第１の装置からの第２の装置への要求および／または提供される達成済みのＱｏＳに関する情報を定義するデータを含むものであってもよい。このようなデータはまた、それぞれのレポートで提供される達成済みＱｏＳに関する情報の範囲と頻度とに関する装置間でのネゴシエーションの一部を形成するものであってもよい。
【００３１】
ストリーミングクラスのサービスのためなどの好適な実施形態では、ＱｏＳ関連情報は、セッション記述プロトコル（ＳＤＰ）メッセージの中に、あるいは、ＲＴＳＰ ＤＥＳＣＲＩＰＴＩＯＮ返信メッセージ２００ＯＫ、ＲＴＳＰ ＳＥＴＵＰメッセージ、ＲＴＳＰ ＰＬＡＹメッセージ、ＲＴＳＰ ＰＡＵＳＥメッセージまたはＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージのヘッダフィールドの中に含まれる。好適には、“ＱｏＳメトリックパラメータセットアップ”メッセージは、ＲＴＳＰ ＤＥＳＣＲＩＰＴＩＯＮメッセージへの返信の内部に在るＳＤＰメッセージにアタッチすることが望ましい。さらに好適には、“ＱｏＳメトリックパラメータ変更”メッセージは、クライアント側装置あるいはクライアント側装置のユーザのいずれかによって開始されるＰＡＵＳＥのような任意のＲＴＳＰメッセージにアタッチすることが望ましい。セッション中にはＳＤＰを利用できないことに留意しなければならない。
【００３２】
例えば、ストリーミングクラスのサービス用としてＱｏＳレポートを定義するために、１セットの最低限の要件を定義することが望ましい。以下、ストリーミングサービスのためのＱｏＳレポートの利便性とパワーとを最大化するのに適したＱｏＳレポートのプロパティを定義する。対応するプロパティは、別のタイプのサービス用としても同様の利点を有するものであることを理解されたい。ストリーミングの開始時におよび現在進行中のセッション中に、ＱｏＳレポートのネゴシエーションを行うことができれば有利である。ストリーミングサーバが常にＱｏＳレポートを要求すればさらに有利である。単一のメッセージの中に１組のメトリックを一体にグループ化できる可能性があればさらに有利である。サーバは、単一のメッセージによって、単一項目の未使用データまたは単一のパラメータあるいは複数項目の未使用データおよび／またはパラメータをレポートするようにクライアントに要請することも可能である。例えば、無線インタフェースで送られる情報を最小限にし、どのようなレポートを選択的に選び、どの媒体から選択的に選ぶかなどについて、セッション時にまたは精度特性としての媒体レベルでレポートを行うことについてネゴシエーションできる可能性があればさらに有利である。レポートのオン／オフの切替えができる可能性があればさらに有利である。レポート頻度を定義できる可能性があればさらに有利である。
【００３３】
レポート頻度は、周期的頻度、イベント駆動による頻度あるいはセッション終了時の頻度とすることができる。周期的レポートの場合、その周期は、ストリーミングサーバが要求し、ストリーミングクライアントが同意したものである。ストリーミングクライアントはこの同意値で応答を行うが、この同意値はサーバが要求した値よりも最適性が少ないようなものであってもよい。イベント駆動によるレポートの場合、イベントはストリーミングクライアントによってレポートされる。これによって、ストリーミングクライアントからストリーミングサーバへ送信される情報量が最小化される。セッション終了時のレポートは、セッションが異常終了した場合、問題を引き起こす原因になることが考えられる。サービスがＰａｕｓｅ状態にある場合、ダミーのデータで無線リソースの浪費を避けるために、クライアントはＱｏＳ関連フィードバックデータを送信しないかもしれない。サーバによるこのような割込み処理が可能であることが望ましい。
【００３４】
好適には、サーバ側でＱｏＳメトリックを計算することが望ましい。すなわち、ストリーミングクライアントは、１セットのイベントおよび／または測定値をレポートし、サーバが計算を実行して、例えば、指定された時間ウィンドウにわたっていくつかの値の最低値、平均値および／または最大値を決定する。ストリーミングサーバは、セッション終了時まで、あるいは。低い作業負荷時まで実際の統計計算の送信を延期することができる。上記とは別に、クライアント側でメトリックを計算する場合もある。このケースでは、クライアント側での複雑さが最少になるようにすることが望ましい。
【００３５】
客観性を保証するために、異なるサーバが同じ方法でＱｏＳメトリックの計算を行うことが望ましい。
【００３６】
通常のＲＴＣＰレポートまたはＲＴＣＰ ＸＲレポートを通じて層３および層４（Ｌ３−Ｌ４）メトリックが利用できるため、本発明は層５（Ｌ５）メトリックおよび未使用データの送信に特に適している。クライアントは、複数のＱｏＳレポートをバッファし、タイムレンジ仕様を追加する単一のレポートでこれらのＱｏＳレポートを送信できるようにして、無線インタフェースで送信するメッセージ数の最少化を図ることが望ましい。送信情報の例として、セッションＩＤ、誤り発生間の継続時間、タイムスタンプなどがある。
【００３７】
本発明の他の目的と特徴は添付図面と共に考察する以下の詳細な説明から明らかになる。しかし、これらの図面は単に例示を目的として設計されたものであり、本発明の限定を定義するものとして設計されたものではないことを理解すべきである。本発明の限定については添付の請求項を参照すべきである。これらの図面は、スケーリングを行うために描かれたものではないこと、並びに、本明細書に記載の構造および処理手順を単に概念的に例示する意図のものであることをさらに理解すべきである。
【発明を実施するための最良の形態】
【００３８】
図１は本発明によって採用可能なシステム１０の概略図である。
【００３９】
システム１０は、例えばオン・デマンドのビデオストリーミングを提供するストリーミングサーバ２０を具備するものである。システム１０は、例えば移動電話の形で実現可能なストリーミングクライアント３０をさらに有する。ストリーミングクライアント３０は、ネットワーク４０を介してストリーミングサーバ２０と接続され、ビデオストリーミング用アプリケーションを要求し、ストリーミングサーバ２０からビデオストリーミング用アプリケーションを受け取るものであってもよい。ネットワーク４０は、例えば、ストリーミングクライアント３０を備えた移動電話がアクセス可能な、相互接続された公衆地上移動通信ネットワーク（ＰＬＭＮ）と、ストリーミングサーバ２０が接続できる接続先インターネットとを具備することができる。ストリーミングクライアント３０は、ネットワーク４０のネットワークエレメントの一部であってもよいことを理解されたい。
【００４０】
ストリーミングサーバ２０は、送信機ＴＸ２２と接続されたＲＴＳＰメッセージをアセンブルするアセンブリング用コンポーネント２１と、受信機ＲＸ２４と接続されたＱｏＳデータのデタッチを行うデタッチ用コンポーネント２３とを備える。ストリーミングクライアント３０は、送信機ＴＸ３２と接続されたＲＴＳＰメッセージのアセンブリングを行うアセンブリング用コンポーネント３１と、受信機ＲＸ３４と接続されたＱｏＳデータのデタッチを行うデタッチ用コンポーネント３３も同様に備える。特にソフトウェアによってコンポーネント２１、２３、３１、３３の実現が可能であるが、ハードウェアによっても同様にこれらのコンポーネントの実現が可能である。
【００４１】
ストリーミングクライアント３０はストリーミングサーバへの送信を行うための３つのタイプのＱｏＳ関連値（イベント、測定値、メトリック）を出力するように作動可能にされる。イベントとは、媒体の標準擬似エラーのない実現からの異常および差異が生じる、ストリーミングクライアント３０における事故またはエラーとして定義され、例えば、スピーチギャップ（speech gap）の継続時間を含むものであってもよい。測定は正常または異常な条件におけるストリーミングセッションをモニタするトラッキングシステムとして定義され、例えば、セッションセットアップタイムを含むものであってもよい。メトリックはイベントと測定値とをベースとするものであり、例えば、音声ギャップの平均値および／または最大継続時間を含むものであってもよい。
【００４２】
図１のシステム１０では、ストリーミングクライアント３０からストリーミングサーバ２０へのイベント、測定値およびメトリックの送信処理が可能な方法が実行される。さらに詳細には、ＱｏＳ関連定義およびネゴシエーションデータとして同様にイベント、測定値およびメトリックを含む、ストリーミングクライアント３０とストリーミングサーバ２０間のいずれかの方向でのすべてのＱｏＳ関連データは、アセンブリング用コンポーネント２１、３１による送信用として、何らかの別の目的のために何らかの方法でアセンブルされたＲＴＳＰメッセージにそれぞれアタッチされる。次いで、補足されたＲＴＳＰメッセージは、それぞれの送信ユニット２０、３０の送信機２２、３２によって、ネットワーク４０を介してそれぞれの受信ユニット３０、２０の受信機３４、２４へ送信される。それぞれの受信ユニット３０、２０では、ＱｏＳデータ３３、２３をデタッチするそれぞれのデタッチ用コンポーネントで受け取ったＲＴＳＰメッセージからＱｏＳデータがデタッチされ、さらなるＱｏＳデータの利用が図られる。
【００４３】
ストリーミングクライアント３０がイベントまたは測定値を送信する場合、ストリーミングクライアントだけがイベントおよび／または測定値を検出し、これらイベントおよび／または測定値をストリーミングサーバ２０へレポートする。次いで、ストリーミングサーバ２０はメトリックの計算を行う。ストリーミングクライアント３０によってメトリックが決定され、送信された場合、ストリーミングサーバ２０は予め計算されたメトリックを受け取ることになる。ストリーミングクライアント３０がメトリックを計算した場合、さらに多くの処理パワーが移動電話側で要求され、送信が必要なデータはさらに広範囲にわたることになる。というのは、１つのイベントまたは測定値の中からいくつかのメトリックを計算することができるからである。
【００４４】
ストリーミングクライアント３０が検出できるイベント並びに測定値の例を図２の表に示す。ストリーミングクライアント３０あるいはストリーミングサーバ２０が計算できるメトリックの例を図３の表に示す。システム１０で採用されているイベント、測定値およびメトリックのリストは提示されたリストとは異なるものであってもよいことを理解されたい。
【００４５】
さらに、イベント、測定値および／またはメトリックを含む、ストリーミングクライアント３０からストリーミングサーバ２０へのフィードバックメッセージの送信頻度を定義する４つの方法が提供される。
【００４６】
第１の周期的代替方法では、或る一定のスケジュールに従ってセッション中にフィードバックメッセージが送信される。この方法によって、必要な場合に、送信済み媒体ストリームのＱｏＳの調整を行うサーバアクションの可能性が提供される。定義された頻度に応じて、この方法は、レポートの周期があまりに短すぎる場合、アップリンク方向にいくつかの追加トラフィックを引き起こす可能性がある。第２のイベントベースの代替方法では、クライアント３０におけるイベントの発生に基づいてフィードバックメッセージが送信される。この方法も、必要な場合、サーバ２０がセッション中にアクションをとる可能性を提供するものである。イベントのレートがあまりに高すぎる場合、同じメッセージの中に多くのイベントが追加されなければ、多くの追加トラフィックがアップリンク方向に生じる可能性がある。第３の代替方法では、フィードバックメッセージはセッション終了時に一回だけ送信される。この方法は帯域上非常に効率のよい方法であるが、レポートされたイベントはセッション終了時にはもはや関連のないものになっているかもしれない。第４の代替方法では、前回のセッションのイベント、測定値あるいはメトリックを持つフィードバックメッセージは次のセッション開始時に送信される。この方法には、ユーザがサービスを利用している頻度に応じて、レポートされたイベントが数日古いものとなって、もはや関連のないものになっているかもしれないという欠点がある。
【００４７】
図１のシステムでは、ＱｏＳ関連データの送信は、主として、２つの段、ストリーミングセッションの接続設定中のネゴシエーション段と、現在進行中のストリーミングセッション中のフィードバック段において実現される。図４を参照しながら以下双方の段について説明する。図４はストリーミングサーバ２０とストリーミングクライアント３０間でのシグナリングを示す信号概略図である。さらに、再ネゴシエーション段は現在進行中のストリーミングセッション中に作動可能にされる。
【００４８】
ストリーミングセッション用のＲＴＳＰ接続設定では、ストリーミングクライアント３０とストリーミングサーバ２０とによって、どのようなメトリック、測定値およびイベントの送信を行うかについての、および、この送信を行う頻度についてのネゴシエーションが行われる。このネゴシエーションに関連して、上述のドキュメントで定義されたヘッダとは異なる以下の新たなＱｏＳ−ＭｅｔｒｉｃｓヘッダがＴＳＧ−ＳＡ４会議＃２８で定義されている：
QoS-header = "QoS-Metrics" ";" "Off" | 1# (stream-url
";" Metrics ";" Sending-rate [";" Range]) CRLF
stream-url = "url" "=" rtsp_URL
Metrics = "metrics" "=" "｛" 1# (1*TEXT)" "｝"
Sending-rate = "rate" "=" 1*DIGIT | "End"
Range = as defined in RFC 2327
DIGIT = as defined in RFC 2326
Rtsp_URL = as defined in RFC 2326
【００４９】
このヘッダはストリーミングサーバ２０またはストリーミングクライアント３０が送信する任意のＲＴＳＰメッセージの一部であってもよい。
【００５０】
定義されたＱｏＳ−Ｍｅｔｒｉｃｓを利用する２つの方法がある。Ｏｆｆパラメータだけを用いる場合、これは、サーバ２０またはクライアント３０のいずれかがイベント、測定値およびメトリックの送信を取り消したいという表示である。一方、ヘッダが、別のパラメータ、すなわちストリームＲＬ、Ｍｅｔｒｉｃｓ、Ｓｅｎｄｉｎｇ−ｒａｔｅおよびおそらくＲａｎｇｅを含む場合、メトリック送信は開始か再開をそれぞれ要求されることになる。
【００５１】
ストリームＲＬフィールドはＲＴＳＰセッションＵＲＬまたはＲＴＳＰ媒体制御ＵＲＬ識別子である。ＲＴＳＰセッション制御ＵＲＬ情報と共にヘッダを用いる場合、セッションレベルでＱｏＳ−メトリックが用いられる。ＵＲＬがＲＴＳＰ媒体制御ＵＲＬである場合、媒体レベルでＱｏＳ−Ｍｅｔｒｉｃｓが用いられ、個々の媒体はそれ自身のＱｏＳ−Ｍｅｔｒｉｃｓラインを取得することになる。２回以上同じＵＲＬを参照することが可能である。Ｓｅｎｄｉｎｇ−ＲａｔｅおよびＲａｎｇｅ情報が予め定義した情報と異なる場合、新たなメトリックパラメータが、当該特定ＵＲＬに対して有効な異なるパラメータセットと見なされるが、この新たなメトリックパラメータは異なるメトリックに対しても有効である。Ｓｅｎｄｉｎｇ−ＲａｔｅおよびＲａｎｇｅ情報が予め定義した情報と同じものである場合、同じＳｅｎｄｉｎｇ−Ｒａｔｅ値とＲａｎｇｅ値に対して同じＲＴＳＰ制御ＵＲＬを２回以上参照してはならない。
【００５２】
Ｍｅｔｒｉｃｓフィールドを利用して、レポートの対象メトリックの量、測定値およびイベントの制限が行われる。メトリックフィールドには、セッション時にレポートを要求するメトリック、測定値およびイベントを記述する名称リストが含まれる。Ｍｅｔｒｉｃｓフィールドに含まれない名称はセッションで使用されない。
【００５３】
Ｓｅｎｄｉｎｇ−ｒａｔｅフィールドを利用して送信レートがセットされる。Ｓｅｎｄｉｎｇ−ｒａｔｅ値が０であれば、クライアント３０はクライアント３０において行われるイベントに応じていつでもフィードバックメッセージを送信することができる。１よりも大きな値は正確なメッセージ−送信間隔を秒で示す。最短間隔は１秒に１回であり、最長間隔は定義されていない。フィードバック情報の送信間隔は異なる媒体に関連して異なるものとなる場合があるが、追加トラフィックを回避するためには１種の同期の保持が推奨される。値Ｅｎｄは唯一のフィードバックメッセージがセッション終了時に送信されることを示す。
【００５４】
Ｒａｎｇｅフィールドを用いてフィードバック情報の送信期限を定義することができる。これはパラメータＯｆｆの送信の場合と同様であるが、ネゴシエーションフェーズの最中にＯｎ状態を事前に定めることが可能となる。
【００５５】
定義済みのＱｏＳ−Ｍｅｔｒｉｃｓフィールドは、ストリーミングサーバ２０でメトリック計算が行われる状況と、ストリーミングクライアント３０がイベントおよび／または測定値のみをサーバへ送信する状況、および同様に、ストリーミングクライアント３０が予め計算したメトリックをストリーミングサーバ２０へ送信する状況を処理することができる。
【００５６】
さらに、新たなＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性が定義され、セッションレベルまたは媒体レベルのＳＤＰ属性のいずれかとしてこのＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性を利用することができる。この定義シンタックスはＲＦＣ２３２７に基づくものであり、このＲＦＣ２３２７は本願明細書で参照により援用される。
a=QoS-Metrics: Metrics Sending-rate Range])
CRLF
Metrics = "metrics" "=" "｛" l# (l*TEXT) "｝"
Sending-rate = "rate" "=" 1*DIGIT/ "End"
Range = as defined in RFC 2327
DIGIT = as defined in RFC 2327
【００５７】
ストリーミングセッションを開くために、ストリーミングクライアント３０は図４のメッセージ１としてＲＴＳＰ ＤＥＳＣＲＩＢＥ要求をストリーミングサーバ２０へ送信する。
C->S DESCRIBE rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 1
【００５８】
表現Ｃ−＞Ｓはクライアント３０からサーバ２０への送信を示す。
【００５９】
次いで、ＱｏＳ−Ｍｅｔｒｉｃｓフィールドの実際のネゴシエーションを第１のＤＥＳＣＲＩＢＥ応答と共に開始することが可能となる。
【００６０】
クライアント３０からＤＥＳＣＲＩＢＥ要求１を受け取った後、サーバ２０はＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性を用いるＳＤＰ記述の所望のＱｏＳメトリック情報をリストする。ＳＤＰのセッションレベルまたは媒体レベルのいずれかでこれらのメトリックを定義することが可能である。この定義によってＱｏＳプロセスに対する柔軟性が与えられ、その結果重要な媒体コンポーネントをさらに詳細にモニタすることが可能となる。ストリーミングサーバ２０はＳＤＰ記述をＤＥＳＣＲＩＢＥ応答２００ＯＫにアタッチし、図４のメッセージ２として上記応答をストリーミングクライアント３０へ送信する。サーバは、ＳＤＰ属性を用いる代わりにＱｏＳ−Ｍｅｔｒｉｃｓヘッダを用いるＤＥＳＣＲＩＢＥ応答メッセージの形でＱｏＳメトリックのリストを行うことも可能である。ストリーミングクライアント３０は応答時にこのようなヘッダの存在をチェックすることが望ましい。
【００６１】
ＴＳＧ−Ｓ４会議＃２８に関する上述のドキュメントにおいて、この時点までにすでに４つの専用ＱｏＳメッセージが要求されていることに留意しなければならない。
【００６２】
以下、対応するセッションレベルメッセージの１例を提示するが、この例では、要求されるセッションパラメータはＲＴＳＰＳｅｔｕｐＴｉｍｅとＩｎｉｔｉａｌＢｕｆｆｅｒｉｎｇＴｉｍｅであり、要求されるビデオパラメータはＦｒａｍｅｇａｐ＿ｍａｘとＦｒａｍｅｇａｐ＿ａｖｅであり、さらに、要求されるオーディオパラメータはＡｕｄｉｏＧａｐ＿ａｖｅとＡｕｄｉｏＧａｐ＿ｍａｘである。これらのパラメータの名称は例示にすぎないこと、また、それぞれの名称は、メトリック、測定値および／またはイベントを示すものであってもよいことに留意されたい。
S->C RTSP/1. 0 200 OK
Cseq: 1
Content-Type: application/sdp
Content-Base: rtsp://example.com/foo/bar/baz.3gp/
Content-Length: 800
Server: Nokia RTSP Server
v=O
o=-3268077682 433392265 IN IP4 63.108. 142.6
s=QoS Enables Session Description Example
e=support@nokia.com
c=IN IP4 0.0. 0.0
t=0 0
a=range: npt=0-83.660000
a=QoS-Metrics:｛RTSPSetupTime, InitialBufferingTime｝;rate=End
a=control:*
m=video 0 RTP/AVP 96
b=AS: 28
a=QoS-Metrics:｛Framegap_max,
Framegap_ave｝;rate=15;range: npt=0-40
a=control:tracklD=3
a=rtpmap: 96 MP4V-ES/1000
a=range: npt=0-83.666000
a=fmtp: 96profile-level-
id=8; config=000001 b008000001 b5090000010000000120008440fa28
302090a28f
m=audio 0 RTP/AVP 98
b=AS: 13
a=QoS-Metrics: ｛AudioGap_ave, AudioGap_max｝;rate=20
a=control:trackl D=5
a=rtpmap: 98 AMR/8000
a=range: npt=0-83.660000
a=fmtp: 98 octet-align=1
a=maxptime: 200
【００６３】
表現Ｓ−＞Ｃはサーバ２０からクライアント３０への送信を示す。
【００６４】
一方のパーティがＱｏＳメトリックシグナリングを作動可能したい場合、セッション中の任意のフェーズにおいてＱｏＳネゴシエーションを行うことが可能である。ここでリストした例では、ＱｏＳネゴシエーションはセッション確立フェーズの際にＳＤＰ属性を用いて行われる。本発明に基づいてＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性またはＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドを利用して、他の任意のＲＴＳＰメッセージにおけるＱｏＳメトリックの送信を行うことも可能である。
【００６５】
ストリーミングクライアント３０は、受け取った２００ＯＫメッセージのＳＤＰ属性の形でリストされた受け入れ可能なＱｏＳメトリックを選択するか、第１の設定要求時に新たな値を提案する。クライアント３０は、ＱｏＳメトリックをサポートしている場合、設定要求を送信するか、確立中のセッションレベルまたは媒体レベルのいずれかの選択／修正ＱｏＳメトリックを含む何らかの別のＲＴＳＰメッセージを送信しなければならない。このような確立要求メッセージがメッセージ３として図４に示されている。代替のＲＴＳＰメッセージとしては、例えばメッセージ５として図４に示されているＰＬＡＹ要求がある。対応する、例示のＳＥＴＵＰメッセージを以下に示す：
C->S SETUP rtsp://example.com/foo/bar/baz.3gp/tracklD=3 RTSP/1.0 Cseq: 2
QoS-Metrics: url="rtsp://example.com/foo/bar/baz.3gp/track ID=3";
metrics= ｛Framegap_max, Framegap_ave｝;rate=10;range: npt=0-40,
url="rtsp://example.com/foo/bar/baz.3gp";
metrics= ｛RTSPSetupTime, InitialBufferingTime｝;rate=End
【００６６】
上記設定要求例では、ストリーミングクライアント３０は、制御ＵＲＬ”ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”のＱｏＳメトリックの送信レートを１５から１０へ修正する。
【００６７】
セッションレベルと媒体レベルとの双方のＱｏＳメトリックがサポートされていることを示すために、ストリーミングクライアント３０は、媒体レベルに関連するすべてのサポートされているおよび／または修正済みのＱｏＳメトリックを送信しなければならない。ストリーミングクライアント３０は、設定要求のうちの少なくとも１つで選択されたセッションレベルのＱｏＳメトリックを送信しなければならない。
【００６８】
ストリーミングサーバ２０はこの設定要求を受け取り、２００ＯＫメッセージを返信し、変更の再確認応答を行うために受け入れ済みのＱｏＳメトリックはアタッチされ、クライアント３０により送信される。この２００ＯＫメッセージはメッセージ４として図４に示されているものである。ストリーミングサーバ２０は２００ＯＫメッセージの形でストリーミングクライアント３０によって行われる変更を拒絶してもよい。変更を拒絶するために、ストリーミングサーバ２０は新たな値を設定して、修正したメトリックをＯＫメッセージにアタッチして元のストリーミングクライアント３０へ再送信するか、単にそのメトリックを無視してそれらの再確認応答を行わないようにするかのいずれかを行うことができる。
【００６９】
ストリーミングサーバ２０が変更の確認応答を行ったと仮定すると、ストリーミングサーバ２０は以下の例示のＳＥＴＵＰ応答を返送することが可能となる：
S->C RTSP/1.0 200 OK
Cseq: 2
Session: 17903320
Transport: RTP/AVP;unicast;client_port=7000-
7001;server_port=6970-6971
QoS-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/tracklD=3";
metrics=｛Framegap_max, Framegap_ave｝;rate=10;range: npt=0-40,
url="rtsp://example.com/foo/bar/baz.3gp";
metrics=｛RTSPSetupTime, InitialBufferingTime｝;rate=End
【００７０】
ストリーミングクライアント３０は、その設定要求３に応答するこの２００ＯＫメッセージ４を受け取ると、ストリーミングサーバ２０がＱｏＳメトリックをサポートしていることを理解する。さらに、クライアント３０はサーバ２０がＱｏＳ−ＭｅｔｒｉｃｓＲＴＳＰヘッダにリストされたメトリックをサポートすることを受け入れた旨を理解する。
【００７１】
同じシグナリングがセッション時に別の媒体コンポーネントに対して実行される。このような場合、セッションレベルでのＱｏＳメトリックネゴシエーションは反復しなくてもよい。
【００７２】
ストリーミングサーバ２０がストリーミングクライアント３０によって行われる修正を承認しなかった場合、サーバ２０とクライアント３０とはクライアント３０によるＲＴＳＰ ＰＬＡＹ要求までメッセージ５として図４に示す再ネゴシエーションを続けてもよい。メッセージ６として図４に示す後続するＲＴＳＰ ＰＬＡＹサーバ２０の応答は、すべてのセッション値と媒体レベルのＱｏＳメトリック値とを含む最終ネゴシエーションを行ったＱｏＳ−Ｍｅｔｒｉｃｓを返送する。
【００７３】
ＲＴＳＰ要求時にＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドが送信される度に、ＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドは特定の要求に対応する応答の中に存在しなければならないことに留意しなければならない。そうしないと、応答の受信機２０、３０は、それぞれの相手側の端３０、２０がＱｏＳメトリックをサポートしていないものと仮定することになる。
【００７４】
例えば、ファイルの形でセッションを開始する前に、ストリーミングクライアント３０がＳＤＰ記述を予め所有するようにしてもよいことにさらに留意しなければならない。ＤＥＳＣＲＩＢＥ応答とは別の手段によってＳＤＰ記述が特定のサーバ２０から検索される場合、ストリーミングサーバにが受け取った第１のメッセージは図４のＳＥＴＵＰメッセージ３となる。したがって図４のＤＥＳＣＲＩＢＥ要求メッセージ１およびＤＥＳＣＲＩＢＥ応答メッセージ２と関連する矢印は点線だけを用いて示されている。ストリーミングクライアント３０は、このケースでは、ＳＥＴＵＰメッセージ３でのネゴシエーション用の初期ＱｏＳメトリック情報を送信するものであってもよい。ＳＥＴＵＰメッセージ３がＱｏＳメトリック情報を含む場合、ストリーミングサーバ２０は、ＳＥＴＵＰ応答４時にメトリックを受け入れたり、新たなメトリックを提案したりすることが可能となり、上述のように次のＲＴＳＰメッセージでのＱｏＳメトリックネゴシエーションの続行が可能となる。第１のＳＥＴＵＰメッセージ３がＱｏＳメトリック情報を含まず、かつ、ストリーミングサーバ２０がストリーミングクライアント３０とのＱｏＳメトリックのネゴシエーションの実行を望む場合、ストリーミングサーバ２０はＳＥＴＵＰ応答４を利用することによってストリーミングクライアント３０からのＱｏＳメトリック情報のレポートを要求することが可能となる。ストリーミングクライアント３０が、要求されたＱｏＳメトリックを受け入れるか、要求されたＱｏＳメトリックの変更を望む場合、ストリーミングクライアント３０は次のＲＴＳＰメッセージの中にメトリック情報を含む必要がある。次のＲＴＳＰメッセージの中にＱｏＳメトリック情報が存在していなければ、これはストリーミングクライアント３０がＱｏＳメトリックをサポートしていないことを示すことになる。
【００７５】
ネゴシエーションが終了した後、ストリーミングクライアント３０はフィードバックメッセージの送信を開始することができる。
【００７６】
また、フィードバックメッセージは信頼性の高いトランスポートメカニズムを用いて送信を行うことが望ましい。ストリーミングセッション中に任意のＲＴＳＰ要求−応答ペアを採用することが可能である。例えば、何らかの方法でＲＴＳＰ ＰＡＵＳＥメッセージをセッション中に送信する場合、このＰＡＵＳＥメッセージ内へフィードバックメッセージを含むことができる。このフィードバックメッセージがセッション終了時にだけ送信される場合、ＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージを利用して、不要なトラフィックを回避することが可能となる。周期的フィードバックレポートの場合、最後のフィードバックメッセージの送信のためにこのようなＴＥＡＲＤＯＷＮメッセージが用いられる。
【００７７】
フィードバック情報用として新しいヘッダが同様に定義される。以下のヘッダはイベント、測定値またはメトリックと関連する送信方法の処理が可能である。定義シンタックスは、同様に本願明細書で参照により援用されているＲＦＣ２３２６に基づくものである：
Feedbackheader = 'QoS-Feedback" ":" l# (stream-url
1 * (parameters) CRLF)
stream-url = "url" "=" rtsp URL
parameters = ";" Metrics "=" "｛" SP / 1# (Value [SP
Timestamp]) "｝"
Metrics = *TEXT
Value = 1*DIGIT ["."*DIGIT]
Timestamp = 1*DIGIT
DIGIT = as defined in RFC 2326
Rtsp_URL = as defined in RFC 2326
SP = as defined in RFC 2326
【００７８】
ストリームＲＬは、フィードバック情報パラメータ用のＲＴＳＰセッションＵＲＬまたは媒体制御ＵＲＬ識別子である。パラメータ定義におけるメトリックフィールドはメトリックの名称、測定値またはイベントを含み、このメトリックフィールドはネゴシエーションフィールドＱｏＳ−Ｍｅｔｒｉｃｓ内のメトリックフィールドと同じでなければならない。構文解析を単純化するためにメトリックの順序を同じに保つことが推奨される。Ｖａｌｕｅフィールドはメトリックの結果を示す。オプションのタイムスタンプフィールドはイベントまたは測定が行われた時刻あるいはメトリックが計算された時刻を示す。同様にスペース（ＳＰ）を設けることにより、ヘッダによってゼロイベントのレポートを行うことができるようにする。
【００７９】
メトリックの送信時にイベントと測定値とを用いる場合、送信時間中に２回以上同じイベントが生じる可能性がある。その場合メトリックタイプ、すなわちイベントまたは測定値の名称が２回以上生じる場合があり、これは、サーバに対するイベントの数を示すものである。
【００８０】
タイムスタンプはイベントが生じたり、メトリック（数）が計算されたりしたときの時刻であり、このタイムスタンプは専らオプションとして与えられる。ＲＴＣＰヘッダは、特定の媒体に関する情報を含むため、追加フィールドを持つこの情報を繰り返す必要はない。
【００８１】
フィードバックメッセージには、ＱｏＳ−フィードバックヘッダが更新されたＱｏＳ−Ｍｅｔｒｉｃｓメトリックのみが含まれる。メトリックパラメータがリストされていないが、確立フェーズ中にネゴシエーションが行われる場合、このメトリックパラメータは不変の／更新されていないパラメータと仮定される。ストリーミングクライアント３０は、ＰＬＡＹ要求後のいずれのＲＴＳＰメッセージにおいても以下のメッセージを用いることができる。このようなメッセージはメッセージ７として図４に示されている。パラメータの名称は単に例示にすぎないことに留意されたい。
OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/trackl D=3"; Framega
p_max=100 6000 ; Framegapave=50 6000
url="rtsp://example.com/foo/bar/baz.3gp/tracklD=5" ;
AudioGapave=340. 5 52; AudioGap_max=0 500
【００８２】
例えば、イベントベースの送信などに起因して高くなりすぎたメッセージ送信レートを避けるために、ＲＴＳＰフィードバックメッセージの連結を行うことも可能である。
【００８３】
ＲＴＳＰフィードバックメッセージとは別に、ストリーミングクライアント３０は、例えばＱｏＳデータのレポートのために以下のＲＴＣＰＲＲメッセージを利用することが可能である。
RTCP header
Report block
Profile specific extension
AudioGap_ave 105.5 6000
AudioGapmax 123 500
【００８４】
さらに上記とは別に、クライアントは、例えば以下のＲＴＣＰ ＡＰＰメッセージを利用することが可能である：
RTCP APP header
Name
QoS_Metrics
Application-dependent data
Audiogapave 105.5 6000
Audiogapmax 123 500
【００８５】
計算されたメトリックの代わりに測定値またはイベントがレポートされている場合、イベント記述が２以上の値を含むようにしてもよい。これは、ＲＴＰパケットを紛失した２つの別々のイベントがレポート時間中に生じた場合関心の対象になることが考えられる。
【００８６】
ＲＴＳＰメッセージで用いる以下の例は、オプションのタイムスタンプ情報をさらに含むものである：
OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/tracklD=3" ; Vcorruption dur
= ｛100 6000,215. 4 11000｝ ; Lost_RTP= ｛3 6000,5 11000｝
url="rtsp://example.com/foo/bar/baz.3gp/trackl D=5";
Acorruptiondur= ｛97 6000,221 11000｝
【００８７】
ＲＴＳＰ ＲＲメッセージで用いる次の例も同様にオプションのタイムスタンプ情報を含むものである：
RTCP header
Report block
Profile specific extension
Acorruptiondur 97 6000
Acorruptiondur 221 11000
【００８８】
ＲＴＳＰ ＡＰＰメッセージで用いる次の例も同様にオプションのタイムスタンプ情報を含むものである：
RTCP APP header
Name
QoS_Metrics
Application-dependent data
Acorruption_dur 97 6000
Acorruption_dur 221 11000
【００８９】
ストリーミングサーバ２０またはクライアント３０のいずれかが、セッション中にネゴシエーション済みパラメータの変更を望むことが起こり得る。サーバ２０が例えば頻繁に若干の情報を望む場合もあることが考えられ、これに対して、同意した数と同数のパラメータの準備ができないことにクライアント３０が気がつく場合もあることが考えられる。ＱｏＳメトリック全体の送信をオフに切り替えることも可能である。その後、ＱｏＳメトリック全体の送信を再開するために、ストリーミングクライアント３０またはストリーミングサーバ２０は新たな要求を送信することができる。現在進行中のストリーミングセッション中、ＱｏＳメトリックパラメータの再ネゴシエーションを行うために任意のＲＴＳＰメッセージを利用することが可能である。最初にネゴシエーションを行ったレポートのいずれの変更も図４のメッセージ７の下に同様に組み込まれる。
【００９０】
以下は、クライアント３０またはサーバ２０によるセッション中の変更要求、あるいは、ＱｏＳメトリックが始動後のセッション中のクライアント３０またはサーバ２０による再開要求を示す１例である：
RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapnum,
AudioGap_max;rate=20
【００９１】
要求の受け入れを示す変更要求への応答は、例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1. 0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapnum,
AudioGap_max;rate=20
【００９２】
要求の拒絶を示す変更要求への応答は、例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGap_ave, AudioGap_max;rate=20
【００９３】
新たな値が受け入れられなかった場合、前回ネゴシエーションが行われた状況が変らない状態のまま残っていることを示す前回用いたパラメータが繰り返し使用されることになる。メトリックのリストは常に絶対的なものである。現在のリストに加除を行う方法は存在しないが、メトリックの新たなリストは古いリストにとって替わる。
【００９４】
以下は、メトリックをオフにセットするための、セッション中のクライアント３０またはサーバ２０によるメッセージを示す１例である：
C->S, S->C OPTIONS rtsp:/example.com/foo/bar/baz.3gp RTSP/1. 0
Cseq: 302
Session: 17903320
QoS-Metrics: Off
【００９５】
セッションレベルまたは媒体レベルでのメトリックの始動が可能であることに留意する必要がある。どのようなレベルを用いるかはＵＲＬによって示される。上記例では、メトリックはすべての媒体に対してセッションレベルでスイッチが切られる。
【００９６】
メトリックの始動を求める要求が受け入れられた場合、応答は双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: Off
【００９７】
メトリックの始動を求める要求が拒絶された場合、応答は例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapmax;rate=20
【００９８】
すなわち、上記始動が受け入れられなかった場合、前回ネゴシエーションが行われた状況が変らない状態のまま残っていることを示す前回用いたパラメータが繰り返し使用されることになる。必要に応じて送信用パラメータの再ネゴシエーションを行うことが可能である。
【００９９】
イベント検出が要求されさえすれば、ストリーミングクライアント３０の実施構成はさらに簡単なものになる。
【０１００】
メッセージの周期的送信が可能であること、および、メッセージができるだけ短くなるように設計されていることが提示した方法の利点である。
【０１０１】
上記説明した方法によって、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２８での上述のドキュメントよりも多くの情報を伝えることが可能となる。さらに、提示したこの方法はセットアップをより高速にする方法である。というのは、より少ないメッセージしか必要としないからである。提案した上記方法には、利用されるメトリックのうちの個々のメトリックのネゴシエーションが可能であるという利点もある。さらに上記方法は、必要に応じてセッション中にメトリックの送信の再ネゴシエーションを行う可能性と、必要に応じてメトリック送信全体の始動を行う可能性とを提供するものである。
【０１０２】
上記提示された方法は、他の解決方法で用いられるレンジよりも正確にイベントの時刻を記述するメトリック用タイムスタンプをさらに提供するものである。周期的メッセージ送信時に記述すべきイベントが存在しないケースについては空メッセージが定義される。メッセージ送信を最適化するためにいくつかのメッセージの連結を行うことも可能である。
【０１０３】
以上、本発明の推奨実施形態に適用されたものとして、本発明の基本的な新規の特徴について図示と説明とを行ったが、詳述した装置並びに方法における形態および細部における種々の省略と代替並びに変更は本発明の精神から逸脱することなく当業者によって行うことが可能であることを理解されたい。例えば、実質的に同一の方法で実質的に同一の機能を実行して同じ結果を達成するための当該エレメントおよび／または方法ステップのすべての組み合わせは本発明の範囲に属するものであることが明白に意図されている。さらに、本発明の開示されたいずれの形態あるいは実施形態と関連して図示および／または説明が行われる構造および／またはエレメントおよび／または方法ステップを、設計上の選択肢の一般的事項として他の任意の開示または説明された形態または実施形態の中に組み込むことも可能であることを認識することが望ましい。したがって、本明細書に添付のクレームの範囲によって示されるように、本発明はこれらクレームによってのみ限定されることを意図するものである。
【図面の簡単な説明】
【０１０４】
【図１】本発明を実現できるシステムを概略的に示す。
【図２】図１のシステムのクライアントが検出できるイベントと測定値とを示す表である。
【図３】図１のシステムのクライアントが計算できるメトリックの１例を示す表である。
【図４】本発明による方法の実施形態を例示する概略信号図である。
【技術分野】
【０００１】
本発明は、サービス品質関連情報の送信方法に関し、この情報は第１の装置と第２の装置との間で少なくとも１つの方向に送信される。本発明は対応する装置、対応するネットワークエレメント並びに対応するシステムにも同様に関する。
【背景技術】
【０００２】
種々のサービスのうちの１つのサービスであって、そのサービスの品質に関する情報を送信する必要が生じる可能性があるサービスとして、ストリーミングクラスのサービスがある。
【０００３】
ストリーミングクラスのサービスを行うために、ストリーミングサーバはネットワークを介して媒体データをストリーミングクライアントへ送信し、それによってクライアント側で安定かつ連続したストリームとして媒体データの処理を行うことが可能となる。ストリーミング用アプリケーションの一例としてインターネット用ビデオ製品がある。ストリーミングサーバはネットワーク内に常駐することができる。
【０００４】
ネットワーク通信事業者やサービスプロバイダは、ストリーミングクライアントのユーザが知覚したサービス品質（ＱｏＳ）の評価に関心を持っている。現在、３ＧＰＰ ＴＳ２６.２３４の形で標準化されているプロトコルを用いて定義されているようなストリーミングセッションによって、知覚されたエンドユーザ品質に関する限られた情報量を知る可能性が提供されている。例えば、パケットロス、遅延ジッタ、受信した累積最大シーケンス番号に関する情報などのネットワークの振舞いに関する情報およびリアルタイムのトランスポートプロトコル（ＲＴＰ）パケットに関する他の情報をレポートするために、リアルタイムのトランスポート制御プロトコル（ＲＴＣＰ）受信レポートがクライアントによってサーバへ送信されている。ＲＴＣＰ送信レポートはサーバによってクライアントへ送信されるが、この送信レポートには送り手に関する情報が含まれている。
【０００５】
しかし、これらのレポートは、ストリーミングサーバや、ストリーミングサーバを経由する通信事業者が、例えば、ストリーミングクライアントから得られる破損ビデオフレームの数、再バッファの継続時間、オーディオギャップの継続時間などの知覚されたＱｏＳに関する付加情報を取得することを可能にするものではない。リアルタイムのトランスポート制御プロトコル（ＲＴＣＰ）レポート、ＲＴＣＰ拡張レポートあるいはＲＴＣＰ ＸＲパケットによって搬送される最新情報を拡張するだけで、ストリーミングクライアントからストリーミングサーバへこのような情報を伝えることが可能となる。このような拡張に含まれるものとして、セッションの確立および設定解除、スピーチギャップとオーディオギャップ、破損ビデオフレーム、再バッファリングと初期バッファリング、サクセション時に紛失したパケットに関する情報、並びに、セッションと媒体送信とに関する生じ得るその他の情報が含まれる１セットのＱｏＳメトリックがある。
【０００６】
ＩＥＴＦ ＲＦＣ２３２８（ＲＴＳＰ仕様、１９９８年４月）、ＩＥＴＦ ＲＦＣ３５５０（ＲＴＰ仕様、２００３年７月）並びにドラフトＲＴＰ制御プロトコル拡張レポート（ＲＴＣＰ ＸＲ、２００３年５月）によって、例えば、ストリーミングクライアントが、パケットロス部分、遅延ジッタ、受信最大シーケンス番号および一続きのパケットロスを含む、受信済みＲＴＰパケットに関する情報をレポートすることが可能となる。
【０００７】
２つの文書ドラフトＲＥＬ−６“ＰＳＳ品質メトリックパーマネント文書”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２７、２００３年７月７〜１１日、Ｔｄｏｃ Ｓ４−０３０５６２、および“ストリーム品質メトリック−クライアントメトリック”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２６、２００３年５月５〜９日、Ｔｄｐｃ Ｓ４−０３０３５３に、３ＧＰＰ（第３世代パートナープロジェクト）におけるＱｏＳメトリックについての追加の一般的問題点についての記載がある。第１の文書には、音声、オーディオ、ビデオ、プレイヤおよびネットワークメトリック用の２５個の異なるパラメータを用いてどのような情報を送るべきかについて記載があり、さらに、どのような種類のプロトコルを使用すべきかについての記載がある。さらに、第２の文書には高レベルの要件および技術上の考慮事項が定義されている。これらの文書は、要求時にクライアントが情報を計算し、この情報をサーバへ送信する方法を定義するものである。トランスポートを行うことを目的として、サーバからクライアントへ送信されるリアルタイムのストリーミングプロトコル（ＲＴＳＰ）ＧＥＴ−ＰＡＲＡＭＥＴＥＲメッセージと、クライアントからサーバへ送信されるＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージとの利用が提案されている。
【０００８】
これらのメッセージは、文書“ストリーミング品質メトリック−トランスポート”、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２８、２００３年９月１〜５日、Ｔｄｐｃ Ｓ４−０３０６２９にさらに詳細に定義されている。ＱｏＳメトリックをトリガするために、サーバからクライアントへのＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージの送信が提案されている。クライアントがＱｏＳメトリックの送信を受け入れれば、クライアントは応答としてＲＴＳＰ２００ＯＫメッセージを送信することができる。次いで、サーバは、メトリックセッション記述ＭＥＴＲＩＣＳ−ＳＥＴＵＰを含むさらに別のＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックセッション記述を送信することができる。メトリックセッション記述ＭＥＴＲＩＣＳ−ＳＥＴＵＰにはＲａｎｇｅ、ＰｅｒｉｏｄおよびＳｅｎｄｅｒパラメータが含まれる。また、このメッセージはＲＴＳＰ２００ＯＫメッセージを用いてクライアントにより受け入れられなければならない。上記とは別に、サーバは、ＱｏＳメトリックセッションの記述にＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを与えるようにクライアントに対して要求することができる。ＱｏＳメトリックセッションが記述され、同意が得られるとすぐに、クライアントは、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックを送信するか、サーバがＧＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージと共にＱｏＳメトリックを検索するかのいずれかを行うことができる。
【０００９】
３つの複数対の必要なメッセージが遅延の原因となることがこのアプローチの欠点であり、この遅延によってセッションのセットアップがスローダウンする場合がある。この提案されたアプローチではセットアップの混同が生じることさえ考えられる。というのは、サーバからデータを取得するために、クライアントは第２のＳＥＴ＿ＰＡＲＡＭＥＴＥＲメッセージを受け取る前にすでに第１のメッセージを送信しているかもしれないからである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
例えば、エンドユーザが知覚したストリーミングクラスのサービス品質に関する情報をストリーミングサーバに提供するような、サービス品質関連情報の装置への提供を改善することが本発明の目的である。
【００１１】
２つの装置間でのセッションのセットアップを高速化し、セットアップの混同を防ぐことが本発明のさらに別の目的である。
【課題を解決するための手段】
【００１２】
本発明の第１の態様によれば、サービス品質関連情報の送信方法が提案され、上記情報は第１の装置と第２の装置間の少なくとも１つの方向に送信されるべきものである。上記提案された方法は、装置のうちの少なくとも一方の装置において上記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするステップと、上記サービス品質関連情報を上記プロトコルメッセージにアタッチするステップと、を具備する。上記提案された方法は上記第１の装置と上記第２の装置のそれぞれの相手方装置へ上記プロトコルメッセージを送信するステップをさらに具備する。
【００１３】
本発明の第１の態様によれば、さらに、サービス品質関連情報を送信するためのソフトウェアコードが提案される。上記情報は第１の装置と第２の装置との間の少なくとも１つの方向に送信されるべきものである。少なくとも上記装置のうちの一方の装置の処理用コンポーネントにおいて実行するとき、上記ソフトウェアコードは上記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルし、上記サービス品質関連情報を上記プロトコルメッセージにアタッチする。
【００１４】
本発明の第１の態様によれば、さらに、サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするため、且つ、他方の装置に送信されるべきサービス品質関連情報を上記メッセージにアタッチするためのアセンブリング用コンポーネントを具備する装置が提案される。上記装置は、上記アセンブリング用コンポーネントがアセンブルしたプロトコルメッセージを他方の装置へ送信する送信用コンポーネントをさらに具備する。同様に、ネットワークにアクセスする装置へサービス品質関連情報を送信するための対応する特徴を具備するこのネットワークのネットワークエレメントが提案される。
【００１５】
本発明の第１の態様によれば、少なくとも２つの装置を具備するシステムが提案される。第１の装置は上記提案された装置に対応するものである。第２の装置は、第１の装置が送信したプロトコルメッセージを受け取る受信ユニットと、サービス品質関連情報を受け取ったプロトコルメッセージからデタッチするデタッチ用コンポーネントとを具備する。
【００１６】
本発明の第１の態様は、ＱｏＳに関連する情報の少なくとも一部を、２つの装置間で何らかの方法で送信されるプロトコルメッセージにアタッチすることができるという考察に基づくものである。
【００１７】
この結果、メッセージの数が減少することになる。というのは、ＱｏＳ関連情報に関する専用メッセージの対が回避されることになるからである。
【００１８】
したがって、ＱｏＳ関連情報を送信するための、専用メッセージを利用する公知のアプローチと比べると、データ交換を高速化するさらに少ないシグナリング用オーバヘッドしか必要としなくなること、さらに高速なセッションのセットアップが可能となること、並びに、簡単な方法でより多量のＱｏＳ関連情報の交換が可能となることが本発明の利点である。例えば、考慮対象のＱｏＳデータのネゴシエーションを行うために、考慮したＱｏＳデータを２回以上送信するために、考慮対象のＱｏＳデータを現在進行中のセッション中に変更するために、あるいは、ＱｏＳデータの送信をセッション中に停止するために、上記のようなさらに多量のＱｏＳ関連情報を利用することも可能となる。ＱｏＳ関連情報がセットアップメッセージの中に含まれていれば、セットアップ中であっても混同を防ぐことが可能となる。プロトコルメッセージのアセンブリングと、このメッセージのＱｏＳ関連情報へのアタッチとを別個の後続するステップで実現することは可能ではあるが、これらを別々の後続するステップで実現する必要はないことを理解されたい。上記アタッチは、プロトコルメッセージのアセンブリの一部を形成するものであってもよい。例えば、プロトコルメッセージのヘッダフィールドの中などのような、プロトコルメッセージの任意の位置に、あるいは、プロトコルメッセージ本文に対する属性としてＱｏＳ関連情報をさらにアタッチすることも可能である。
【００１９】
本発明の第２の態様によれば、第１の装置と第２の装置間で少なくとも１つの方向に送信される、サービス品質関連情報のさらなる送信方法が提案される。提案されるこのさらなる方法は、上記装置のうちの少なくとも一方の側において、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に上記サービス品質関連情報を形成するステップと、上記第１の装置と上記第２の装置のそれぞれの相手方装置へ上記プロトコルメッセージを送信するステップと、を具備する。
【００２０】
本発明の第２の態様によれば、サービス品質関連情報を送信するためのソフトウェアコードがさらに提案される。この情報は、第１の装置と第２の装置との間で少なくとも一方の方向に送信されるべきである。少なくとも上記装置のうちの一方の装置の処理用コンポーネントで実行するとき、上記ソフトウェアコードは、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に上記サービス品質関連情報を形成する。
【００２１】
本発明の第２の態様によれば、プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネントであって、上記サービス品質関連情報を一方の装置へ送信するようになっているアセンブリング用コンポーネントと、上記アセンブリング用コンポーネントによって提供されたプロトコルメッセージをこの他方の装置へ送信する送信用コンポーネントとを具備する装置がさらに提案される。同様に、このネットワークにアクセスする装置へサービス品質関連情報を送信するための対応する特徴を具備するネットワークのネットワークエレメントが提案される。
【００２２】
本発明の第２の態様によれば、少なくとも２つの装置を具備するシステムがさらに提案される。第１の装置は本発明の第２の態様に関連して提案された装置に対応するものである。第２の装置は、上記第１の装置が送信したプロトコルメッセージを受け取る受信ユニットと、受け取ったプロトコルメッセージからサービス品質関連情報を抽出するデタッチ用コンポーネントとを具備するものである。
【００２３】
本発明の第２の態様は、ＱｏＳ関連情報を送信するためのプロトコルメッセージのヘッダまたは属性が特段の利点を有するものであるという認識に基づくものである。というのは、このケースでは、単一の制御モジュールを利用して、プロトコルメッセージを分析し、ＱｏＳ関連情報を含む情報を抽出することが可能であり、次いで、抽出された情報をシステム内の必要なモジュールへ提供することが可能となるからである。
【００２４】
したがって、本発明の第２の態様は、例えば、ストリーミングクラスのセッションセットアップ中に、あるいは、ストリーミングクラスのデータ送信中に、ＱｏＳ関連情報の送信に用いらる新しく定義されたＲＴＳＰヘッダフィールドに基づくようにすることも可能である。
【００２５】
新たなＲＴＳＰヘッダまたは属性の利用に代る代替例として、ＱｏＳメトリックのシグナリングの新たなＲＴＳＰメッセージ定義の利用、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドの利用、および、ＲＴＳＰメッセージの最後におけるメッセージ本文の挿入、あるいは、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲとＧＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＴＳＰメッセージとして使用するためのＱｏＳメトリックと関連するパラメータセットの定義が挙げられる。ＱｏＳメトリックシグナリングをセッションレベルのシグナリングから完全に分離することを目的として、実施装置はＱｏＳメトリック用のＲＴＳＰヘッダフィールドの利用を選択しなくてもよい。
【００２６】
本発明の上記第１および第２の態様の双方を単一の実施構成で組み合わせることが可能であることを理解されたい。
【００２７】
排他的にというわけではないが、特に、本発明の上記双方の態様において、プロトコルメッセージは、ＲＴＳＰメッセージ、ＲＴＣＰメッセージ、セッション開始プロトコル（ＳＩＰ）メッセージあるいはセッション記述プロトコル（ＳＤＰ）記述とすることが可能である。このプロトコルがＲＴＣＰ送信よりも信頼性の高い柔軟性のある送信を提供することが上記提案された方法でＲＴＳＰメッセージを利用する特別の利点である。
【００２８】
排他的にというわけではないが、例えばストリーミングクラスのサービスなどのサービス品質が関わるサービスは本発明の双方の態様の中に存在することが可能である。特に、このようなストリーミングクラスのサービスのためにＲＴＳＰとＲＴＣＰとを利用することも可能である。したがって、上記提案された装置は、例えばストリーミングクラスのサービス、すなわち、ストリーミングクライアントまたはストリーミングサーバ用の受信ユニットあるいは送信ユニットとすることができる。本発明は、ストリーミングクライアントが実際にどのようにしてデータを受け取るかをストリーミングサーバが見つけ出し、さらに多くのユーザ経験の品質（経験のＱｏＥ−品質）に関する情報、並びに、ストリーミングセッションが遭遇するかもしれない諸問題に関する情報をストリーミングサーバが得ることができるようにするのに特に適した方法を提供するものである。
【００２９】
別のサービスとして、例えば、ＩＰ電話、ビデオ電話、あるいは片方向通話ビデオなども考えられる。特に、このような別のサービス用として会議用プロトコルＳＩＰの利用も可能である。
【００３０】
例えば、セッションを形成しながらおよび／またはそれぞれのサービスのための現在進行中のセッション中にプロトコルメッセージの送信を実行することが可能である。それぞれのプロトコルメッセージ内のＱｏＳ関連情報は、例えば、最新のサービスのために達成されたＱｏＳに関するレポートを含むものであってもよい。このレポートは、特に一方の装置が他方の装置へ提供するパラメータおよび／または未使用データを含むものであってもよい。この未使用データが例えばイベントや測定データに関する通知を含むものであってもよいのに対して、メトリックとも呼ばれているパラメータは処理済みの未使用データである。さらに、ＱｏＳ関連情報は、最新のサービスのための達成済みＱｏＳに関するこのような情報の提供を求める、第１の装置からの第２の装置への要求および／または提供される達成済みのＱｏＳに関する情報を定義するデータを含むものであってもよい。このようなデータはまた、それぞれのレポートで提供される達成済みＱｏＳに関する情報の範囲と頻度とに関する装置間でのネゴシエーションの一部を形成するものであってもよい。
【００３１】
ストリーミングクラスのサービスのためなどの好適な実施形態では、ＱｏＳ関連情報は、セッション記述プロトコル（ＳＤＰ）メッセージの中に、あるいは、ＲＴＳＰ ＤＥＳＣＲＩＰＴＩＯＮ返信メッセージ２００ＯＫ、ＲＴＳＰ ＳＥＴＵＰメッセージ、ＲＴＳＰ ＰＬＡＹメッセージ、ＲＴＳＰ ＰＡＵＳＥメッセージまたはＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージのヘッダフィールドの中に含まれる。好適には、“ＱｏＳメトリックパラメータセットアップ”メッセージは、ＲＴＳＰ ＤＥＳＣＲＩＰＴＩＯＮメッセージへの返信の内部に在るＳＤＰメッセージにアタッチすることが望ましい。さらに好適には、“ＱｏＳメトリックパラメータ変更”メッセージは、クライアント側装置あるいはクライアント側装置のユーザのいずれかによって開始されるＰＡＵＳＥのような任意のＲＴＳＰメッセージにアタッチすることが望ましい。セッション中にはＳＤＰを利用できないことに留意しなければならない。
【００３２】
例えば、ストリーミングクラスのサービス用としてＱｏＳレポートを定義するために、１セットの最低限の要件を定義することが望ましい。以下、ストリーミングサービスのためのＱｏＳレポートの利便性とパワーとを最大化するのに適したＱｏＳレポートのプロパティを定義する。対応するプロパティは、別のタイプのサービス用としても同様の利点を有するものであることを理解されたい。ストリーミングの開始時におよび現在進行中のセッション中に、ＱｏＳレポートのネゴシエーションを行うことができれば有利である。ストリーミングサーバが常にＱｏＳレポートを要求すればさらに有利である。単一のメッセージの中に１組のメトリックを一体にグループ化できる可能性があればさらに有利である。サーバは、単一のメッセージによって、単一項目の未使用データまたは単一のパラメータあるいは複数項目の未使用データおよび／またはパラメータをレポートするようにクライアントに要請することも可能である。例えば、無線インタフェースで送られる情報を最小限にし、どのようなレポートを選択的に選び、どの媒体から選択的に選ぶかなどについて、セッション時にまたは精度特性としての媒体レベルでレポートを行うことについてネゴシエーションできる可能性があればさらに有利である。レポートのオン／オフの切替えができる可能性があればさらに有利である。レポート頻度を定義できる可能性があればさらに有利である。
【００３３】
レポート頻度は、周期的頻度、イベント駆動による頻度あるいはセッション終了時の頻度とすることができる。周期的レポートの場合、その周期は、ストリーミングサーバが要求し、ストリーミングクライアントが同意したものである。ストリーミングクライアントはこの同意値で応答を行うが、この同意値はサーバが要求した値よりも最適性が少ないようなものであってもよい。イベント駆動によるレポートの場合、イベントはストリーミングクライアントによってレポートされる。これによって、ストリーミングクライアントからストリーミングサーバへ送信される情報量が最小化される。セッション終了時のレポートは、セッションが異常終了した場合、問題を引き起こす原因になることが考えられる。サービスがＰａｕｓｅ状態にある場合、ダミーのデータで無線リソースの浪費を避けるために、クライアントはＱｏＳ関連フィードバックデータを送信しないかもしれない。サーバによるこのような割込み処理が可能であることが望ましい。
【００３４】
好適には、サーバ側でＱｏＳメトリックを計算することが望ましい。すなわち、ストリーミングクライアントは、１セットのイベントおよび／または測定値をレポートし、サーバが計算を実行して、例えば、指定された時間ウィンドウにわたっていくつかの値の最低値、平均値および／または最大値を決定する。ストリーミングサーバは、セッション終了時まで、あるいは。低い作業負荷時まで実際の統計計算の送信を延期することができる。上記とは別に、クライアント側でメトリックを計算する場合もある。このケースでは、クライアント側での複雑さが最少になるようにすることが望ましい。
【００３５】
客観性を保証するために、異なるサーバが同じ方法でＱｏＳメトリックの計算を行うことが望ましい。
【００３６】
通常のＲＴＣＰレポートまたはＲＴＣＰ ＸＲレポートを通じて層３および層４（Ｌ３−Ｌ４）メトリックが利用できるため、本発明は層５（Ｌ５）メトリックおよび未使用データの送信に特に適している。クライアントは、複数のＱｏＳレポートをバッファし、タイムレンジ仕様を追加する単一のレポートでこれらのＱｏＳレポートを送信できるようにして、無線インタフェースで送信するメッセージ数の最少化を図ることが望ましい。送信情報の例として、セッションＩＤ、誤り発生間の継続時間、タイムスタンプなどがある。
【００３７】
本発明の他の目的と特徴は添付図面と共に考察する以下の詳細な説明から明らかになる。しかし、これらの図面は単に例示を目的として設計されたものであり、本発明の限定を定義するものとして設計されたものではないことを理解すべきである。本発明の限定については添付の請求項を参照すべきである。これらの図面は、スケーリングを行うために描かれたものではないこと、並びに、本明細書に記載の構造および処理手順を単に概念的に例示する意図のものであることをさらに理解すべきである。
【発明を実施するための最良の形態】
【００３８】
図１は本発明によって採用可能なシステム１０の概略図である。
【００３９】
システム１０は、例えばオン・デマンドのビデオストリーミングを提供するストリーミングサーバ２０を具備するものである。システム１０は、例えば移動電話の形で実現可能なストリーミングクライアント３０をさらに有する。ストリーミングクライアント３０は、ネットワーク４０を介してストリーミングサーバ２０と接続され、ビデオストリーミング用アプリケーションを要求し、ストリーミングサーバ２０からビデオストリーミング用アプリケーションを受け取るものであってもよい。ネットワーク４０は、例えば、ストリーミングクライアント３０を備えた移動電話がアクセス可能な、相互接続された公衆地上移動通信ネットワーク（ＰＬＭＮ）と、ストリーミングサーバ２０が接続できる接続先インターネットとを具備することができる。ストリーミングクライアント３０は、ネットワーク４０のネットワークエレメントの一部であってもよいことを理解されたい。
【００４０】
ストリーミングサーバ２０は、送信機ＴＸ２２と接続されたＲＴＳＰメッセージをアセンブルするアセンブリング用コンポーネント２１と、受信機ＲＸ２４と接続されたＱｏＳデータのデタッチを行うデタッチ用コンポーネント２３とを備える。ストリーミングクライアント３０は、送信機ＴＸ３２と接続されたＲＴＳＰメッセージのアセンブリングを行うアセンブリング用コンポーネント３１と、受信機ＲＸ３４と接続されたＱｏＳデータのデタッチを行うデタッチ用コンポーネント３３も同様に備える。特にソフトウェアによってコンポーネント２１、２３、３１、３３の実現が可能であるが、ハードウェアによっても同様にこれらのコンポーネントの実現が可能である。
【００４１】
ストリーミングクライアント３０はストリーミングサーバへの送信を行うための３つのタイプのＱｏＳ関連値（イベント、測定値、メトリック）を出力するように作動可能にされる。イベントとは、媒体の標準擬似エラーのない実現からの異常および差異が生じる、ストリーミングクライアント３０における事故またはエラーとして定義され、例えば、スピーチギャップ（speech gap）の継続時間を含むものであってもよい。測定は正常または異常な条件におけるストリーミングセッションをモニタするトラッキングシステムとして定義され、例えば、セッションセットアップタイムを含むものであってもよい。メトリックはイベントと測定値とをベースとするものであり、例えば、音声ギャップの平均値および／または最大継続時間を含むものであってもよい。
【００４２】
図１のシステム１０では、ストリーミングクライアント３０からストリーミングサーバ２０へのイベント、測定値およびメトリックの送信処理が可能な方法が実行される。さらに詳細には、ＱｏＳ関連定義およびネゴシエーションデータとして同様にイベント、測定値およびメトリックを含む、ストリーミングクライアント３０とストリーミングサーバ２０間のいずれかの方向でのすべてのＱｏＳ関連データは、アセンブリング用コンポーネント２１、３１による送信用として、何らかの別の目的のために何らかの方法でアセンブルされたＲＴＳＰメッセージにそれぞれアタッチされる。次いで、補足されたＲＴＳＰメッセージは、それぞれの送信ユニット２０、３０の送信機２２、３２によって、ネットワーク４０を介してそれぞれの受信ユニット３０、２０の受信機３４、２４へ送信される。それぞれの受信ユニット３０、２０では、ＱｏＳデータ３３、２３をデタッチするそれぞれのデタッチ用コンポーネントで受け取ったＲＴＳＰメッセージからＱｏＳデータがデタッチされ、さらなるＱｏＳデータの利用が図られる。
【００４３】
ストリーミングクライアント３０がイベントまたは測定値を送信する場合、ストリーミングクライアントだけがイベントおよび／または測定値を検出し、これらイベントおよび／または測定値をストリーミングサーバ２０へレポートする。次いで、ストリーミングサーバ２０はメトリックの計算を行う。ストリーミングクライアント３０によってメトリックが決定され、送信された場合、ストリーミングサーバ２０は予め計算されたメトリックを受け取ることになる。ストリーミングクライアント３０がメトリックを計算した場合、さらに多くの処理パワーが移動電話側で要求され、送信が必要なデータはさらに広範囲にわたることになる。というのは、１つのイベントまたは測定値の中からいくつかのメトリックを計算することができるからである。
【００４４】
ストリーミングクライアント３０が検出できるイベント並びに測定値の例を図２の表に示す。ストリーミングクライアント３０あるいはストリーミングサーバ２０が計算できるメトリックの例を図３の表に示す。システム１０で採用されているイベント、測定値およびメトリックのリストは提示されたリストとは異なるものであってもよいことを理解されたい。
【００４５】
さらに、イベント、測定値および／またはメトリックを含む、ストリーミングクライアント３０からストリーミングサーバ２０へのフィードバックメッセージの送信頻度を定義する４つの方法が提供される。
【００４６】
第１の周期的代替方法では、或る一定のスケジュールに従ってセッション中にフィードバックメッセージが送信される。この方法によって、必要な場合に、送信済み媒体ストリームのＱｏＳの調整を行うサーバアクションの可能性が提供される。定義された頻度に応じて、この方法は、レポートの周期があまりに短すぎる場合、アップリンク方向にいくつかの追加トラフィックを引き起こす可能性がある。第２のイベントベースの代替方法では、クライアント３０におけるイベントの発生に基づいてフィードバックメッセージが送信される。この方法も、必要な場合、サーバ２０がセッション中にアクションをとる可能性を提供するものである。イベントのレートがあまりに高すぎる場合、同じメッセージの中に多くのイベントが追加されなければ、多くの追加トラフィックがアップリンク方向に生じる可能性がある。第３の代替方法では、フィードバックメッセージはセッション終了時に一回だけ送信される。この方法は帯域上非常に効率のよい方法であるが、レポートされたイベントはセッション終了時にはもはや関連のないものになっているかもしれない。第４の代替方法では、前回のセッションのイベント、測定値あるいはメトリックを持つフィードバックメッセージは次のセッション開始時に送信される。この方法には、ユーザがサービスを利用している頻度に応じて、レポートされたイベントが数日古いものとなって、もはや関連のないものになっているかもしれないという欠点がある。
【００４７】
図１のシステムでは、ＱｏＳ関連データの送信は、主として、２つの段、ストリーミングセッションの接続設定中のネゴシエーション段と、現在進行中のストリーミングセッション中のフィードバック段において実現される。図４を参照しながら以下双方の段について説明する。図４はストリーミングサーバ２０とストリーミングクライアント３０間でのシグナリングを示す信号概略図である。さらに、再ネゴシエーション段は現在進行中のストリーミングセッション中に作動可能にされる。
【００４８】
ストリーミングセッション用のＲＴＳＰ接続設定では、ストリーミングクライアント３０とストリーミングサーバ２０とによって、どのようなメトリック、測定値およびイベントの送信を行うかについての、および、この送信を行う頻度についてのネゴシエーションが行われる。このネゴシエーションに関連して、上述のドキュメントで定義されたヘッダとは異なる以下の新たなＱｏＳ−ＭｅｔｒｉｃｓヘッダがＴＳＧ−ＳＡ４会議＃２８で定義されている：
QoS-header = "QoS-Metrics" ";" "Off" | 1# (stream-url
";" Metrics ";" Sending-rate [";" Range]) CRLF
stream-url = "url" "=" rtsp_URL
Metrics = "metrics" "=" "｛" 1# (1*TEXT)" "｝"
Sending-rate = "rate" "=" 1*DIGIT | "End"
Range = as defined in RFC 2327
DIGIT = as defined in RFC 2326
Rtsp_URL = as defined in RFC 2326
【００４９】
このヘッダはストリーミングサーバ２０またはストリーミングクライアント３０が送信する任意のＲＴＳＰメッセージの一部であってもよい。
【００５０】
定義されたＱｏＳ−Ｍｅｔｒｉｃｓを利用する２つの方法がある。Ｏｆｆパラメータだけを用いる場合、これは、サーバ２０またはクライアント３０のいずれかがイベント、測定値およびメトリックの送信を取り消したいという表示である。一方、ヘッダが、別のパラメータ、すなわちストリームＲＬ、Ｍｅｔｒｉｃｓ、Ｓｅｎｄｉｎｇ−ｒａｔｅおよびおそらくＲａｎｇｅを含む場合、メトリック送信は開始か再開をそれぞれ要求されることになる。
【００５１】
ストリームＲＬフィールドはＲＴＳＰセッションＵＲＬまたはＲＴＳＰ媒体制御ＵＲＬ識別子である。ＲＴＳＰセッション制御ＵＲＬ情報と共にヘッダを用いる場合、セッションレベルでＱｏＳ−メトリックが用いられる。ＵＲＬがＲＴＳＰ媒体制御ＵＲＬである場合、媒体レベルでＱｏＳ−Ｍｅｔｒｉｃｓが用いられ、個々の媒体はそれ自身のＱｏＳ−Ｍｅｔｒｉｃｓラインを取得することになる。２回以上同じＵＲＬを参照することが可能である。Ｓｅｎｄｉｎｇ−ＲａｔｅおよびＲａｎｇｅ情報が予め定義した情報と異なる場合、新たなメトリックパラメータが、当該特定ＵＲＬに対して有効な異なるパラメータセットと見なされるが、この新たなメトリックパラメータは異なるメトリックに対しても有効である。Ｓｅｎｄｉｎｇ−ＲａｔｅおよびＲａｎｇｅ情報が予め定義した情報と同じものである場合、同じＳｅｎｄｉｎｇ−Ｒａｔｅ値とＲａｎｇｅ値に対して同じＲＴＳＰ制御ＵＲＬを２回以上参照してはならない。
【００５２】
Ｍｅｔｒｉｃｓフィールドを利用して、レポートの対象メトリックの量、測定値およびイベントの制限が行われる。メトリックフィールドには、セッション時にレポートを要求するメトリック、測定値およびイベントを記述する名称リストが含まれる。Ｍｅｔｒｉｃｓフィールドに含まれない名称はセッションで使用されない。
【００５３】
Ｓｅｎｄｉｎｇ−ｒａｔｅフィールドを利用して送信レートがセットされる。Ｓｅｎｄｉｎｇ−ｒａｔｅ値が０であれば、クライアント３０はクライアント３０において行われるイベントに応じていつでもフィードバックメッセージを送信することができる。１よりも大きな値は正確なメッセージ−送信間隔を秒で示す。最短間隔は１秒に１回であり、最長間隔は定義されていない。フィードバック情報の送信間隔は異なる媒体に関連して異なるものとなる場合があるが、追加トラフィックを回避するためには１種の同期の保持が推奨される。値Ｅｎｄは唯一のフィードバックメッセージがセッション終了時に送信されることを示す。
【００５４】
Ｒａｎｇｅフィールドを用いてフィードバック情報の送信期限を定義することができる。これはパラメータＯｆｆの送信の場合と同様であるが、ネゴシエーションフェーズの最中にＯｎ状態を事前に定めることが可能となる。
【００５５】
定義済みのＱｏＳ−Ｍｅｔｒｉｃｓフィールドは、ストリーミングサーバ２０でメトリック計算が行われる状況と、ストリーミングクライアント３０がイベントおよび／または測定値のみをサーバへ送信する状況、および同様に、ストリーミングクライアント３０が予め計算したメトリックをストリーミングサーバ２０へ送信する状況を処理することができる。
【００５６】
さらに、新たなＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性が定義され、セッションレベルまたは媒体レベルのＳＤＰ属性のいずれかとしてこのＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性を利用することができる。この定義シンタックスはＲＦＣ２３２７に基づくものであり、このＲＦＣ２３２７は本願明細書で参照により援用される。
a=QoS-Metrics: Metrics Sending-rate Range])
CRLF
Metrics = "metrics" "=" "｛" l# (l*TEXT) "｝"
Sending-rate = "rate" "=" 1*DIGIT/ "End"
Range = as defined in RFC 2327
DIGIT = as defined in RFC 2327
【００５７】
ストリーミングセッションを開くために、ストリーミングクライアント３０は図４のメッセージ１としてＲＴＳＰ ＤＥＳＣＲＩＢＥ要求をストリーミングサーバ２０へ送信する。
C->S DESCRIBE rtsp://example.com/foo/bar/baz.3gp RTSP/1.0 Cseq: 1
【００５８】
表現Ｃ−＞Ｓはクライアント３０からサーバ２０への送信を示す。
【００５９】
次いで、ＱｏＳ−Ｍｅｔｒｉｃｓフィールドの実際のネゴシエーションを第１のＤＥＳＣＲＩＢＥ応答と共に開始することが可能となる。
【００６０】
クライアント３０からＤＥＳＣＲＩＢＥ要求１を受け取った後、サーバ２０はＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性を用いるＳＤＰ記述の所望のＱｏＳメトリック情報をリストする。ＳＤＰのセッションレベルまたは媒体レベルのいずれかでこれらのメトリックを定義することが可能である。この定義によってＱｏＳプロセスに対する柔軟性が与えられ、その結果重要な媒体コンポーネントをさらに詳細にモニタすることが可能となる。ストリーミングサーバ２０はＳＤＰ記述をＤＥＳＣＲＩＢＥ応答２００ＯＫにアタッチし、図４のメッセージ２として上記応答をストリーミングクライアント３０へ送信する。サーバは、ＳＤＰ属性を用いる代わりにＱｏＳ−Ｍｅｔｒｉｃｓヘッダを用いるＤＥＳＣＲＩＢＥ応答メッセージの形でＱｏＳメトリックのリストを行うことも可能である。ストリーミングクライアント３０は応答時にこのようなヘッダの存在をチェックすることが望ましい。
【００６１】
ＴＳＧ−Ｓ４会議＃２８に関する上述のドキュメントにおいて、この時点までにすでに４つの専用ＱｏＳメッセージが要求されていることに留意しなければならない。
【００６２】
以下、対応するセッションレベルメッセージの１例を提示するが、この例では、要求されるセッションパラメータはＲＴＳＰＳｅｔｕｐＴｉｍｅとＩｎｉｔｉａｌＢｕｆｆｅｒｉｎｇＴｉｍｅであり、要求されるビデオパラメータはＦｒａｍｅｇａｐ＿ｍａｘとＦｒａｍｅｇａｐ＿ａｖｅであり、さらに、要求されるオーディオパラメータはＡｕｄｉｏＧａｐ＿ａｖｅとＡｕｄｉｏＧａｐ＿ｍａｘである。これらのパラメータの名称は例示にすぎないこと、また、それぞれの名称は、メトリック、測定値および／またはイベントを示すものであってもよいことに留意されたい。
S->C RTSP/1. 0 200 OK
Cseq: 1
Content-Type: application/sdp
Content-Base: rtsp://example.com/foo/bar/baz.3gp/
Content-Length: 800
Server: Nokia RTSP Server
v=O
o=-3268077682 433392265 IN IP4 63.108. 142.6
s=QoS Enables Session Description Example
e=support@nokia.com
c=IN IP4 0.0. 0.0
t=0 0
a=range: npt=0-83.660000
a=QoS-Metrics:｛RTSPSetupTime, InitialBufferingTime｝;rate=End
a=control:*
m=video 0 RTP/AVP 96
b=AS: 28
a=QoS-Metrics:｛Framegap_max,
Framegap_ave｝;rate=15;range: npt=0-40
a=control:tracklD=3
a=rtpmap: 96 MP4V-ES/1000
a=range: npt=0-83.666000
a=fmtp: 96profile-level-
id=8; config=000001 b008000001 b5090000010000000120008440fa28
302090a28f
m=audio 0 RTP/AVP 98
b=AS: 13
a=QoS-Metrics: ｛AudioGap_ave, AudioGap_max｝;rate=20
a=control:trackl D=5
a=rtpmap: 98 AMR/8000
a=range: npt=0-83.660000
a=fmtp: 98 octet-align=1
a=maxptime: 200
【００６３】
表現Ｓ−＞Ｃはサーバ２０からクライアント３０への送信を示す。
【００６４】
一方のパーティがＱｏＳメトリックシグナリングを作動可能したい場合、セッション中の任意のフェーズにおいてＱｏＳネゴシエーションを行うことが可能である。ここでリストした例では、ＱｏＳネゴシエーションはセッション確立フェーズの際にＳＤＰ属性を用いて行われる。本発明に基づいてＱｏＳ−ＭｅｔｒｉｃｓＳＤＰ属性またはＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドを利用して、他の任意のＲＴＳＰメッセージにおけるＱｏＳメトリックの送信を行うことも可能である。
【００６５】
ストリーミングクライアント３０は、受け取った２００ＯＫメッセージのＳＤＰ属性の形でリストされた受け入れ可能なＱｏＳメトリックを選択するか、第１の設定要求時に新たな値を提案する。クライアント３０は、ＱｏＳメトリックをサポートしている場合、設定要求を送信するか、確立中のセッションレベルまたは媒体レベルのいずれかの選択／修正ＱｏＳメトリックを含む何らかの別のＲＴＳＰメッセージを送信しなければならない。このような確立要求メッセージがメッセージ３として図４に示されている。代替のＲＴＳＰメッセージとしては、例えばメッセージ５として図４に示されているＰＬＡＹ要求がある。対応する、例示のＳＥＴＵＰメッセージを以下に示す：
C->S SETUP rtsp://example.com/foo/bar/baz.3gp/tracklD=3 RTSP/1.0 Cseq: 2
QoS-Metrics: url="rtsp://example.com/foo/bar/baz.3gp/track ID=3";
metrics= ｛Framegap_max, Framegap_ave｝;rate=10;range: npt=0-40,
url="rtsp://example.com/foo/bar/baz.3gp";
metrics= ｛RTSPSetupTime, InitialBufferingTime｝;rate=End
【００６６】
上記設定要求例では、ストリーミングクライアント３０は、制御ＵＲＬ”ｒｔｓｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｆｏｏ／ｂａｒ／ｂａｚ．３ｇｐ／ｔｒａｃｋＩＤ＝３”のＱｏＳメトリックの送信レートを１５から１０へ修正する。
【００６７】
セッションレベルと媒体レベルとの双方のＱｏＳメトリックがサポートされていることを示すために、ストリーミングクライアント３０は、媒体レベルに関連するすべてのサポートされているおよび／または修正済みのＱｏＳメトリックを送信しなければならない。ストリーミングクライアント３０は、設定要求のうちの少なくとも１つで選択されたセッションレベルのＱｏＳメトリックを送信しなければならない。
【００６８】
ストリーミングサーバ２０はこの設定要求を受け取り、２００ＯＫメッセージを返信し、変更の再確認応答を行うために受け入れ済みのＱｏＳメトリックはアタッチされ、クライアント３０により送信される。この２００ＯＫメッセージはメッセージ４として図４に示されているものである。ストリーミングサーバ２０は２００ＯＫメッセージの形でストリーミングクライアント３０によって行われる変更を拒絶してもよい。変更を拒絶するために、ストリーミングサーバ２０は新たな値を設定して、修正したメトリックをＯＫメッセージにアタッチして元のストリーミングクライアント３０へ再送信するか、単にそのメトリックを無視してそれらの再確認応答を行わないようにするかのいずれかを行うことができる。
【００６９】
ストリーミングサーバ２０が変更の確認応答を行ったと仮定すると、ストリーミングサーバ２０は以下の例示のＳＥＴＵＰ応答を返送することが可能となる：
S->C RTSP/1.0 200 OK
Cseq: 2
Session: 17903320
Transport: RTP/AVP;unicast;client_port=7000-
7001;server_port=6970-6971
QoS-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/tracklD=3";
metrics=｛Framegap_max, Framegap_ave｝;rate=10;range: npt=0-40,
url="rtsp://example.com/foo/bar/baz.3gp";
metrics=｛RTSPSetupTime, InitialBufferingTime｝;rate=End
【００７０】
ストリーミングクライアント３０は、その設定要求３に応答するこの２００ＯＫメッセージ４を受け取ると、ストリーミングサーバ２０がＱｏＳメトリックをサポートしていることを理解する。さらに、クライアント３０はサーバ２０がＱｏＳ−ＭｅｔｒｉｃｓＲＴＳＰヘッダにリストされたメトリックをサポートすることを受け入れた旨を理解する。
【００７１】
同じシグナリングがセッション時に別の媒体コンポーネントに対して実行される。このような場合、セッションレベルでのＱｏＳメトリックネゴシエーションは反復しなくてもよい。
【００７２】
ストリーミングサーバ２０がストリーミングクライアント３０によって行われる修正を承認しなかった場合、サーバ２０とクライアント３０とはクライアント３０によるＲＴＳＰ ＰＬＡＹ要求までメッセージ５として図４に示す再ネゴシエーションを続けてもよい。メッセージ６として図４に示す後続するＲＴＳＰ ＰＬＡＹサーバ２０の応答は、すべてのセッション値と媒体レベルのＱｏＳメトリック値とを含む最終ネゴシエーションを行ったＱｏＳ−Ｍｅｔｒｉｃｓを返送する。
【００７３】
ＲＴＳＰ要求時にＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドが送信される度に、ＱｏＳ−Ｍｅｔｒｉｃｓヘッダフィールドは特定の要求に対応する応答の中に存在しなければならないことに留意しなければならない。そうしないと、応答の受信機２０、３０は、それぞれの相手側の端３０、２０がＱｏＳメトリックをサポートしていないものと仮定することになる。
【００７４】
例えば、ファイルの形でセッションを開始する前に、ストリーミングクライアント３０がＳＤＰ記述を予め所有するようにしてもよいことにさらに留意しなければならない。ＤＥＳＣＲＩＢＥ応答とは別の手段によってＳＤＰ記述が特定のサーバ２０から検索される場合、ストリーミングサーバにが受け取った第１のメッセージは図４のＳＥＴＵＰメッセージ３となる。したがって図４のＤＥＳＣＲＩＢＥ要求メッセージ１およびＤＥＳＣＲＩＢＥ応答メッセージ２と関連する矢印は点線だけを用いて示されている。ストリーミングクライアント３０は、このケースでは、ＳＥＴＵＰメッセージ３でのネゴシエーション用の初期ＱｏＳメトリック情報を送信するものであってもよい。ＳＥＴＵＰメッセージ３がＱｏＳメトリック情報を含む場合、ストリーミングサーバ２０は、ＳＥＴＵＰ応答４時にメトリックを受け入れたり、新たなメトリックを提案したりすることが可能となり、上述のように次のＲＴＳＰメッセージでのＱｏＳメトリックネゴシエーションの続行が可能となる。第１のＳＥＴＵＰメッセージ３がＱｏＳメトリック情報を含まず、かつ、ストリーミングサーバ２０がストリーミングクライアント３０とのＱｏＳメトリックのネゴシエーションの実行を望む場合、ストリーミングサーバ２０はＳＥＴＵＰ応答４を利用することによってストリーミングクライアント３０からのＱｏＳメトリック情報のレポートを要求することが可能となる。ストリーミングクライアント３０が、要求されたＱｏＳメトリックを受け入れるか、要求されたＱｏＳメトリックの変更を望む場合、ストリーミングクライアント３０は次のＲＴＳＰメッセージの中にメトリック情報を含む必要がある。次のＲＴＳＰメッセージの中にＱｏＳメトリック情報が存在していなければ、これはストリーミングクライアント３０がＱｏＳメトリックをサポートしていないことを示すことになる。
【００７５】
ネゴシエーションが終了した後、ストリーミングクライアント３０はフィードバックメッセージの送信を開始することができる。
【００７６】
また、フィードバックメッセージは信頼性の高いトランスポートメカニズムを用いて送信を行うことが望ましい。ストリーミングセッション中に任意のＲＴＳＰ要求−応答ペアを採用することが可能である。例えば、何らかの方法でＲＴＳＰ ＰＡＵＳＥメッセージをセッション中に送信する場合、このＰＡＵＳＥメッセージ内へフィードバックメッセージを含むことができる。このフィードバックメッセージがセッション終了時にだけ送信される場合、ＲＴＳＰ ＴＥＡＲＤＯＷＮメッセージを利用して、不要なトラフィックを回避することが可能となる。周期的フィードバックレポートの場合、最後のフィードバックメッセージの送信のためにこのようなＴＥＡＲＤＯＷＮメッセージが用いられる。
【００７７】
フィードバック情報用として新しいヘッダが同様に定義される。以下のヘッダはイベント、測定値またはメトリックと関連する送信方法の処理が可能である。定義シンタックスは、同様に本願明細書で参照により援用されているＲＦＣ２３２６に基づくものである：
Feedbackheader = 'QoS-Feedback" ":" l# (stream-url
1 * (parameters) CRLF)
stream-url = "url" "=" rtsp URL
parameters = ";" Metrics "=" "｛" SP / 1# (Value [SP
Timestamp]) "｝"
Metrics = *TEXT
Value = 1*DIGIT ["."*DIGIT]
Timestamp = 1*DIGIT
DIGIT = as defined in RFC 2326
Rtsp_URL = as defined in RFC 2326
SP = as defined in RFC 2326
【００７８】
ストリームＲＬは、フィードバック情報パラメータ用のＲＴＳＰセッションＵＲＬまたは媒体制御ＵＲＬ識別子である。パラメータ定義におけるメトリックフィールドはメトリックの名称、測定値またはイベントを含み、このメトリックフィールドはネゴシエーションフィールドＱｏＳ−Ｍｅｔｒｉｃｓ内のメトリックフィールドと同じでなければならない。構文解析を単純化するためにメトリックの順序を同じに保つことが推奨される。Ｖａｌｕｅフィールドはメトリックの結果を示す。オプションのタイムスタンプフィールドはイベントまたは測定が行われた時刻あるいはメトリックが計算された時刻を示す。同様にスペース（ＳＰ）を設けることにより、ヘッダによってゼロイベントのレポートを行うことができるようにする。
【００７９】
メトリックの送信時にイベントと測定値とを用いる場合、送信時間中に２回以上同じイベントが生じる可能性がある。その場合メトリックタイプ、すなわちイベントまたは測定値の名称が２回以上生じる場合があり、これは、サーバに対するイベントの数を示すものである。
【００８０】
タイムスタンプはイベントが生じたり、メトリック（数）が計算されたりしたときの時刻であり、このタイムスタンプは専らオプションとして与えられる。ＲＴＣＰヘッダは、特定の媒体に関する情報を含むため、追加フィールドを持つこの情報を繰り返す必要はない。
【００８１】
フィードバックメッセージには、ＱｏＳ−フィードバックヘッダが更新されたＱｏＳ−Ｍｅｔｒｉｃｓメトリックのみが含まれる。メトリックパラメータがリストされていないが、確立フェーズ中にネゴシエーションが行われる場合、このメトリックパラメータは不変の／更新されていないパラメータと仮定される。ストリーミングクライアント３０は、ＰＬＡＹ要求後のいずれのＲＴＳＰメッセージにおいても以下のメッセージを用いることができる。このようなメッセージはメッセージ７として図４に示されている。パラメータの名称は単に例示にすぎないことに留意されたい。
OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/trackl D=3"; Framega
p_max=100 6000 ; Framegapave=50 6000
url="rtsp://example.com/foo/bar/baz.3gp/tracklD=5" ;
AudioGapave=340. 5 52; AudioGap_max=0 500
【００８２】
例えば、イベントベースの送信などに起因して高くなりすぎたメッセージ送信レートを避けるために、ＲＴＳＰフィードバックメッセージの連結を行うことも可能である。
【００８３】
ＲＴＳＰフィードバックメッセージとは別に、ストリーミングクライアント３０は、例えばＱｏＳデータのレポートのために以下のＲＴＣＰＲＲメッセージを利用することが可能である。
RTCP header
Report block
Profile specific extension
AudioGap_ave 105.5 6000
AudioGapmax 123 500
【００８４】
さらに上記とは別に、クライアントは、例えば以下のＲＴＣＰ ＡＰＰメッセージを利用することが可能である：
RTCP APP header
Name
QoS_Metrics
Application-dependent data
Audiogapave 105.5 6000
Audiogapmax 123 500
【００８５】
計算されたメトリックの代わりに測定値またはイベントがレポートされている場合、イベント記述が２以上の値を含むようにしてもよい。これは、ＲＴＰパケットを紛失した２つの別々のイベントがレポート時間中に生じた場合関心の対象になることが考えられる。
【００８６】
ＲＴＳＰメッセージで用いる以下の例は、オプションのタイムスタンプ情報をさらに含むものである：
OPTIONS rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/tracklD=3" ; Vcorruption dur
= ｛100 6000,215. 4 11000｝ ; Lost_RTP= ｛3 6000,5 11000｝
url="rtsp://example.com/foo/bar/baz.3gp/trackl D=5";
Acorruptiondur= ｛97 6000,221 11000｝
【００８７】
ＲＴＳＰ ＲＲメッセージで用いる次の例も同様にオプションのタイムスタンプ情報を含むものである：
RTCP header
Report block
Profile specific extension
Acorruptiondur 97 6000
Acorruptiondur 221 11000
【００８８】
ＲＴＳＰ ＡＰＰメッセージで用いる次の例も同様にオプションのタイムスタンプ情報を含むものである：
RTCP APP header
Name
QoS_Metrics
Application-dependent data
Acorruption_dur 97 6000
Acorruption_dur 221 11000
【００８９】
ストリーミングサーバ２０またはクライアント３０のいずれかが、セッション中にネゴシエーション済みパラメータの変更を望むことが起こり得る。サーバ２０が例えば頻繁に若干の情報を望む場合もあることが考えられ、これに対して、同意した数と同数のパラメータの準備ができないことにクライアント３０が気がつく場合もあることが考えられる。ＱｏＳメトリック全体の送信をオフに切り替えることも可能である。その後、ＱｏＳメトリック全体の送信を再開するために、ストリーミングクライアント３０またはストリーミングサーバ２０は新たな要求を送信することができる。現在進行中のストリーミングセッション中、ＱｏＳメトリックパラメータの再ネゴシエーションを行うために任意のＲＴＳＰメッセージを利用することが可能である。最初にネゴシエーションを行ったレポートのいずれの変更も図４のメッセージ７の下に同様に組み込まれる。
【００９０】
以下は、クライアント３０またはサーバ２０によるセッション中の変更要求、あるいは、ＱｏＳメトリックが始動後のセッション中のクライアント３０またはサーバ２０による再開要求を示す１例である：
RTSP/1.0
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapnum,
AudioGap_max;rate=20
【００９１】
要求の受け入れを示す変更要求への応答は、例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1. 0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapnum,
AudioGap_max;rate=20
【００９２】
要求の拒絶を示す変更要求への応答は、例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGap_ave, AudioGap_max;rate=20
【００９３】
新たな値が受け入れられなかった場合、前回ネゴシエーションが行われた状況が変らない状態のまま残っていることを示す前回用いたパラメータが繰り返し使用されることになる。メトリックのリストは常に絶対的なものである。現在のリストに加除を行う方法は存在しないが、メトリックの新たなリストは古いリストにとって替わる。
【００９４】
以下は、メトリックをオフにセットするための、セッション中のクライアント３０またはサーバ２０によるメッセージを示す１例である：
C->S, S->C OPTIONS rtsp:/example.com/foo/bar/baz.3gp RTSP/1. 0
Cseq: 302
Session: 17903320
QoS-Metrics: Off
【００９５】
セッションレベルまたは媒体レベルでのメトリックの始動が可能であることに留意する必要がある。どのようなレベルを用いるかはＵＲＬによって示される。上記例では、メトリックはすべての媒体に対してセッションレベルでスイッチが切られる。
【００９６】
メトリックの始動を求める要求が受け入れられた場合、応答は双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: Off
【００９７】
メトリックの始動を求める要求が拒絶された場合、応答は例えば以下のように双方の方向に対して定義される：
S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
QoS-Metrics: metrics=AudioGapave, AudioGapmax;rate=20
【００９８】
すなわち、上記始動が受け入れられなかった場合、前回ネゴシエーションが行われた状況が変らない状態のまま残っていることを示す前回用いたパラメータが繰り返し使用されることになる。必要に応じて送信用パラメータの再ネゴシエーションを行うことが可能である。
【００９９】
イベント検出が要求されさえすれば、ストリーミングクライアント３０の実施構成はさらに簡単なものになる。
【０１００】
メッセージの周期的送信が可能であること、および、メッセージができるだけ短くなるように設計されていることが提示した方法の利点である。
【０１０１】
上記説明した方法によって、３ＧＰＰ ＴＳＧ−Ｓ４会議＃２８での上述のドキュメントよりも多くの情報を伝えることが可能となる。さらに、提示したこの方法はセットアップをより高速にする方法である。というのは、より少ないメッセージしか必要としないからである。提案した上記方法には、利用されるメトリックのうちの個々のメトリックのネゴシエーションが可能であるという利点もある。さらに上記方法は、必要に応じてセッション中にメトリックの送信の再ネゴシエーションを行う可能性と、必要に応じてメトリック送信全体の始動を行う可能性とを提供するものである。
【０１０２】
上記提示された方法は、他の解決方法で用いられるレンジよりも正確にイベントの時刻を記述するメトリック用タイムスタンプをさらに提供するものである。周期的メッセージ送信時に記述すべきイベントが存在しないケースについては空メッセージが定義される。メッセージ送信を最適化するためにいくつかのメッセージの連結を行うことも可能である。
【０１０３】
以上、本発明の推奨実施形態に適用されたものとして、本発明の基本的な新規の特徴について図示と説明とを行ったが、詳述した装置並びに方法における形態および細部における種々の省略と代替並びに変更は本発明の精神から逸脱することなく当業者によって行うことが可能であることを理解されたい。例えば、実質的に同一の方法で実質的に同一の機能を実行して同じ結果を達成するための当該エレメントおよび／または方法ステップのすべての組み合わせは本発明の範囲に属するものであることが明白に意図されている。さらに、本発明の開示されたいずれの形態あるいは実施形態と関連して図示および／または説明が行われる構造および／またはエレメントおよび／または方法ステップを、設計上の選択肢の一般的事項として他の任意の開示または説明された形態または実施形態の中に組み込むことも可能であることを認識することが望ましい。したがって、本明細書に添付のクレームの範囲によって示されるように、本発明はこれらクレームによってのみ限定されることを意図するものである。
【図面の簡単な説明】
【０１０４】
【図１】本発明を実現できるシステムを概略的に示す。
【図２】図１のシステムのクライアントが検出できるイベントと測定値とを示す表である。
【図３】図１のシステムのクライアントが計算できるメトリックの１例を示す表である。
【図４】本発明による方法の実施形態を例示する概略信号図である。
【特許請求の範囲】
【請求項１】
サービス品質関連情報の送信方法であって、前記情報は第１の装置（３０）と第２の装置（２０）との間の少なくとも１つの方向に送信されるべきものであり、前記装置（２０、３０）のうちの少なくとも一方の装置において、
前記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするステップと、
前記サービス品質関連情報を前記プロトコルメッセージにアタッチするステップと、
前記第１の装置（３０）と前記第２の装置（２０）のそれぞれの相手方装置へ前記プロトコルメッセージを送信するステップと、を具備する方法。
【請求項２】
前記プロトコルメッセージが、リアルタイムのストリーミングプロトコルメッセージ、リアルタイムのトランスポート制御プロトコルおよびセッション開始プロトコルメッセージのうちの１つである請求項１に記載の方法。
【請求項３】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッションを形成するとき、前記送信ステップを実行する請求項１に記載の方法。
【請求項４】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッション中に前記送信ステップを実行する請求項１に記載の方法。
【請求項５】
前記第１の装置（３０）により前記第２の装置（２０）にレポートされるべき前記サービス品質関連情報が、達成済みのサービス品質関連情報を含む請求項１に記載の方法。
【請求項６】
前記達成済みサービス品質関連情報が、達成済みのサービス品質と関連づけられたイベント、測定値およびメトリックのうちの少なくとも１つに関する情報を含む請求項５に記載の方法。
【請求項７】
前記達成済みサービス品質関連情報が前記サービスのポーズ状態中には送信されない請求項５に記載の方法。
【請求項８】
前記第１の装置（３０）が前記第２の装置（２０）に対して達成済みのサービス品質に関するレポートをどの程度まで行うかについての、前記第１の装置（３０）と前記第２の装置（２０）間でのネゴシエーションのための情報が、前記サービス品質関連情報の中に含まれる請求項１に記載の方法。
【請求項９】
達成済みのサービス品質を前記第２の装置（２０）へレポートするために前記第１の装置（３０）により利用されるべき頻度情報が前記サービス品質関連情報の中に含まれる請求項１に記載の方法。
【請求項１０】
前記サービス品質関連情報が前記プロトコルメッセージのヘッダと、前記プロトコルメッセージの属性とのうちの少なくとも一方にアタッチされる請求項１に記載の方法。
【請求項１１】
サービス品質関連情報を送信するためのソフトウェアコードであって、前記情報は第１の装置（３０）と第２の装置（２０）間で少なくとも１つの方向に送信されるべきものであり、該ソフトウェアコードが少なくとも前記装置（２０、３０）のうちの一方の装置の処理用コンポーネントで実行するとき、以下の、
前記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルする機能と、
前記サービス品質関連情報を前記プロトコルメッセージにアタッチする機能とを実現するソフトウェアコード。
【請求項１２】
装置（２０、３０）であって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするためのアセンブリング用コンポーネント（２１、３１）であり、他方の装置（３０、２０）に送信されるべき前記サービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネント（２１、３１）と、
前記アセンブリング用コンポーネント（２１、３１）がアセンブルしたプロトコルメッセージを他方の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）とを具備する装置（２０、３０）。
【請求項１３】
ネットワークのネットワークエレメントであって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするためのアセンブリング用コンポーネントであり、前記ネットワークにアクセスする装置に送信されるべきサービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネントと、
前記アセンブリング用コンポーネントがアセンブルしたプロトコルメッセージを前記装置へ送信する送信用コンポーネントと、を具備するネットワークエレメント。
【請求項１４】
少なくとも第１の装置（２０、３０）と第２の装置（３０、２０）とを具備するシステムであって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするため、且つサービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネント（２１、３１）を具備した前記第１の装置（２０、３０）であって、前記サービス品質関連情報は前記第２の装置（３０、２０）に送信されるべきものであるものと、
前記アセンブリング用コンポーネント（２１、３１）がアセンブルしたプロトコルメッセージを前記第２の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）を具備する前記第１の装置（２０、３０）と、
前記第１の装置（２０、３０）が送信したプロトコルメッセージを受け取る受信ユニット（３４、２４）を具備する前記第２の装置（３０、２０）と、
受け取ったプロトコルメッセージからサービス品質関連情報をデタッチするデタッチ用コンポーネント（３３、２３）を具備する前記第２の装置（３０、２０）と、を具備するシステム。
【請求項１５】
サービス品質関連情報の送信方法であって、第１の装置（３０）と第２の装置（２０）との間で少なくとも１つの方向に前記情報を送信する方法において、前記装置（２０、３０）のうちの少なくとも一方の装置において、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に前記サービス品質関連情報を形成するステップと、
前記第１の装置（３０）と前記第２の装置（２０）のそれぞれの相手方装置へ前記プロトコルメッセージを送信するステップと、を具備する方法。
【請求項１６】
前記プロトコルメッセージが、リアルタイムのストリーミングプロトコルメッセージと、リアルタイムのトランスポート制御プロトコルと、セッション開始プロトコルメッセージと、セッション記述プロトコル記述とのうちの１つである請求項１５に記載の方法。
【請求項１７】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッションを形成するとき前記送信ステップを実行する請求項１５に記載の方法。
【請求項１８】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためののセッション中に前記送信ステップを実行する請求項１５に記載の方法。
【請求項１９】
前記第１の装置（３０）が前記第２の装置（２０）へレポートする前記サービス品質関連情報が、達成済みのサービス品質関連情報を含む請求項１５に記載の方法。
【請求項２０】
前記サービス品質関連情報が、達成済みのサービス品質と関連づけられたイベント、測定値およびメトリックのうちの少なくとも１つに関する情報を含む請求項１９に記載の方法。
【請求項２１】
前記達成済みサービス品質関連情報が前記サービスのポーズ状態中には送信されない請求項１９に記載の方法。
【請求項２２】
前記第１の装置（３０）が前記第２の装置（２０）に対して達成済みのサービス品質に関するレポートをどの程度まで行うかについての、前記第１の装置（３０）と前記第２の装置（２０）間でのネゴシエーションのための情報が、前記サービス品質関連情報の中に含まれる請求項１５に記載の方法。
【請求項２３】
達成済みのサービス品質を前記第２の装置（２０）へレポートするために前記第１の装置（３０）が利用する頻度情報が前記サービス品質関連情報の中に含まれる請求項１５に記載の方法。
【請求項２４】
サービス品質関連情報を送信するためのソフトウェアコードであって、第１の装置（３０）と第２の装置（２０）間で少なくとも１つの方向に前記情報が送信され、該ソフトウェアコードが少なくとも前記装置（２０、３０）のうちの一方の装置の処理用コンポーネントで実行するとき、以下の、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に前記サービス品質関連情報を形成する機能を実現するソフトウェアコード。
【請求項２５】
装置（２０、３０）であって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネント（２１、３１）であって、前記サービス品質関連情報を一方の装置（３０、２０）へ送信するようになっているアセンブリング用コンポーネント（２１、３１）と、
前記アセンブリング用コンポーネント（２１、３１）によって提供されたプロトコルメッセージを他方の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）とを、具備する装置（２０、３０）。
【請求項２６】
ネットワークのネットワークエレメントであって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネントであって、前記サービス品質関連情報は前記ネットワークにアクセスする装置に送信されるべきものであるアセンブリング用コンポーネントと、
前記アセンブリング用コンポーネントによって提供されたプロトコルメッセージを前記装置へ送信する送信用コンポーネントと、を具備するネットワークエレメント。
【請求項２７】
少なくとも第１の装置（２０、３０）と第２の装置（３０、２０）とを具備するシステムであって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネント（２１、３１）であって、前記サービス品質関連情報は前記第２の装置（３０、２０）に送信されるべきものであるアセンブリング用コンポーネント（２１、３１）を具備する前記第１の装置（２０、３０）と、
前記アセンブリング用コンポーネント（２１、３１）によって提供されたプロトコルメッセージを前記第２の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）を具備する前記第１の装置（２０、３０）と、
前記第１の装置（２０、３０）が送信したプロトコルメッセージを受け取る受信ユニット（３４、２４）を具備する前記第２の装置（３０、２０）と、
受け取ったプロトコルメッセージからサービス品質関連情報を抽出するデタッチ用コンポーネント（３３、２３）を具備する前記第２の装置（３０、２０）と、を具備するシステム。
【請求項１】
サービス品質関連情報の送信方法であって、前記情報は第１の装置（３０）と第２の装置（２０）との間の少なくとも１つの方向に送信されるべきものであり、前記装置（２０、３０）のうちの少なくとも一方の装置において、
前記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするステップと、
前記サービス品質関連情報を前記プロトコルメッセージにアタッチするステップと、
前記第１の装置（３０）と前記第２の装置（２０）のそれぞれの相手方装置へ前記プロトコルメッセージを送信するステップと、を具備する方法。
【請求項２】
前記プロトコルメッセージが、リアルタイムのストリーミングプロトコルメッセージ、リアルタイムのトランスポート制御プロトコルおよびセッション開始プロトコルメッセージのうちの１つである請求項１に記載の方法。
【請求項３】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッションを形成するとき、前記送信ステップを実行する請求項１に記載の方法。
【請求項４】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッション中に前記送信ステップを実行する請求項１に記載の方法。
【請求項５】
前記第１の装置（３０）により前記第２の装置（２０）にレポートされるべき前記サービス品質関連情報が、達成済みのサービス品質関連情報を含む請求項１に記載の方法。
【請求項６】
前記達成済みサービス品質関連情報が、達成済みのサービス品質と関連づけられたイベント、測定値およびメトリックのうちの少なくとも１つに関する情報を含む請求項５に記載の方法。
【請求項７】
前記達成済みサービス品質関連情報が前記サービスのポーズ状態中には送信されない請求項５に記載の方法。
【請求項８】
前記第１の装置（３０）が前記第２の装置（２０）に対して達成済みのサービス品質に関するレポートをどの程度まで行うかについての、前記第１の装置（３０）と前記第２の装置（２０）間でのネゴシエーションのための情報が、前記サービス品質関連情報の中に含まれる請求項１に記載の方法。
【請求項９】
達成済みのサービス品質を前記第２の装置（２０）へレポートするために前記第１の装置（３０）により利用されるべき頻度情報が前記サービス品質関連情報の中に含まれる請求項１に記載の方法。
【請求項１０】
前記サービス品質関連情報が前記プロトコルメッセージのヘッダと、前記プロトコルメッセージの属性とのうちの少なくとも一方にアタッチされる請求項１に記載の方法。
【請求項１１】
サービス品質関連情報を送信するためのソフトウェアコードであって、前記情報は第１の装置（３０）と第２の装置（２０）間で少なくとも１つの方向に送信されるべきものであり、該ソフトウェアコードが少なくとも前記装置（２０、３０）のうちの一方の装置の処理用コンポーネントで実行するとき、以下の、
前記サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルする機能と、
前記サービス品質関連情報を前記プロトコルメッセージにアタッチする機能とを実現するソフトウェアコード。
【請求項１２】
装置（２０、３０）であって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするためのアセンブリング用コンポーネント（２１、３１）であり、他方の装置（３０、２０）に送信されるべき前記サービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネント（２１、３１）と、
前記アセンブリング用コンポーネント（２１、３１）がアセンブルしたプロトコルメッセージを他方の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）とを具備する装置（２０、３０）。
【請求項１３】
ネットワークのネットワークエレメントであって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするためのアセンブリング用コンポーネントであり、前記ネットワークにアクセスする装置に送信されるべきサービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネントと、
前記アセンブリング用コンポーネントがアセンブルしたプロトコルメッセージを前記装置へ送信する送信用コンポーネントと、を具備するネットワークエレメント。
【請求項１４】
少なくとも第１の装置（２０、３０）と第２の装置（３０、２０）とを具備するシステムであって、
サービス品質関連情報以外の情報を含むプロトコルメッセージをアセンブルするため、且つサービス品質関連情報を前記メッセージにアタッチするためのアセンブリング用コンポーネント（２１、３１）を具備した前記第１の装置（２０、３０）であって、前記サービス品質関連情報は前記第２の装置（３０、２０）に送信されるべきものであるものと、
前記アセンブリング用コンポーネント（２１、３１）がアセンブルしたプロトコルメッセージを前記第２の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）を具備する前記第１の装置（２０、３０）と、
前記第１の装置（２０、３０）が送信したプロトコルメッセージを受け取る受信ユニット（３４、２４）を具備する前記第２の装置（３０、２０）と、
受け取ったプロトコルメッセージからサービス品質関連情報をデタッチするデタッチ用コンポーネント（３３、２３）を具備する前記第２の装置（３０、２０）と、を具備するシステム。
【請求項１５】
サービス品質関連情報の送信方法であって、第１の装置（３０）と第２の装置（２０）との間で少なくとも１つの方向に前記情報を送信する方法において、前記装置（２０、３０）のうちの少なくとも一方の装置において、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に前記サービス品質関連情報を形成するステップと、
前記第１の装置（３０）と前記第２の装置（２０）のそれぞれの相手方装置へ前記プロトコルメッセージを送信するステップと、を具備する方法。
【請求項１６】
前記プロトコルメッセージが、リアルタイムのストリーミングプロトコルメッセージと、リアルタイムのトランスポート制御プロトコルと、セッション開始プロトコルメッセージと、セッション記述プロトコル記述とのうちの１つである請求項１５に記載の方法。
【請求項１７】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためのセッションを形成するとき前記送信ステップを実行する請求項１５に記載の方法。
【請求項１８】
前記第１の装置（３０）と前記第２の装置（２０）間で特定のサービスを行うためののセッション中に前記送信ステップを実行する請求項１５に記載の方法。
【請求項１９】
前記第１の装置（３０）が前記第２の装置（２０）へレポートする前記サービス品質関連情報が、達成済みのサービス品質関連情報を含む請求項１５に記載の方法。
【請求項２０】
前記サービス品質関連情報が、達成済みのサービス品質と関連づけられたイベント、測定値およびメトリックのうちの少なくとも１つに関する情報を含む請求項１９に記載の方法。
【請求項２１】
前記達成済みサービス品質関連情報が前記サービスのポーズ状態中には送信されない請求項１９に記載の方法。
【請求項２２】
前記第１の装置（３０）が前記第２の装置（２０）に対して達成済みのサービス品質に関するレポートをどの程度まで行うかについての、前記第１の装置（３０）と前記第２の装置（２０）間でのネゴシエーションのための情報が、前記サービス品質関連情報の中に含まれる請求項１５に記載の方法。
【請求項２３】
達成済みのサービス品質を前記第２の装置（２０）へレポートするために前記第１の装置（３０）が利用する頻度情報が前記サービス品質関連情報の中に含まれる請求項１５に記載の方法。
【請求項２４】
サービス品質関連情報を送信するためのソフトウェアコードであって、第１の装置（３０）と第２の装置（２０）間で少なくとも１つの方向に前記情報が送信され、該ソフトウェアコードが少なくとも前記装置（２０、３０）のうちの一方の装置の処理用コンポーネントで実行するとき、以下の、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部に前記サービス品質関連情報を形成する機能を実現するソフトウェアコード。
【請求項２５】
装置（２０、３０）であって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネント（２１、３１）であって、前記サービス品質関連情報を一方の装置（３０、２０）へ送信するようになっているアセンブリング用コンポーネント（２１、３１）と、
前記アセンブリング用コンポーネント（２１、３１）によって提供されたプロトコルメッセージを他方の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）とを、具備する装置（２０、３０）。
【請求項２６】
ネットワークのネットワークエレメントであって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネントであって、前記サービス品質関連情報は前記ネットワークにアクセスする装置に送信されるべきものであるアセンブリング用コンポーネントと、
前記アセンブリング用コンポーネントによって提供されたプロトコルメッセージを前記装置へ送信する送信用コンポーネントと、を具備するネットワークエレメント。
【請求項２７】
少なくとも第１の装置（２０、３０）と第２の装置（３０、２０）とを具備するシステムであって、
プロトコルメッセージのヘッダフィールドと属性とのうちの少なくとも一方の内部にサービス品質関連情報を形成するためのアセンブリング用コンポーネント（２１、３１）であって、前記サービス品質関連情報は前記第２の装置（３０、２０）に送信されるべきものであるアセンブリング用コンポーネント（２１、３１）を具備する前記第１の装置（２０、３０）と、
前記アセンブリング用コンポーネント（２１、３１）によって提供されたプロトコルメッセージを前記第２の装置（３０、２０）へ送信する送信用コンポーネント（２２、３２）を具備する前記第１の装置（２０、３０）と、
前記第１の装置（２０、３０）が送信したプロトコルメッセージを受け取る受信ユニット（３４、２４）を具備する前記第２の装置（３０、２０）と、
受け取ったプロトコルメッセージからサービス品質関連情報を抽出するデタッチ用コンポーネント（３３、２３）を具備する前記第２の装置（３０、２０）と、を具備するシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００７−５０４７３６（Ｐ２００７−５０４７３６Ａ）
【公表日】平成１９年３月１日（２００７．３．１）
【国際特許分類】
【出願番号】特願２００６−５２５２０４（Ｐ２００６−５２５２０４）
【出願日】平成１６年９月１日（２００４．９．１）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２８２６
【国際公開番号】ＷＯ２００５／０２２８６５
【国際公開日】平成１７年３月１０日（２００５．３．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公表日】平成１９年３月１日（２００７．３．１）
【国際特許分類】
【出願日】平成１６年９月１日（２００４．９．１）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２８２６
【国際公開番号】ＷＯ２００５／０２２８６５
【国際公開日】平成１７年３月１０日（２００５．３．１０）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]