(57)【要約】  本発明は，１又は複数のメトリックによって送信セッションの品質を報告する方法と，計算機プログラム製品と，クライアントと，サーバと，システムと，プロトコルと，に関し，中でも品質報告を送信セッション内のコンテンツ切替に適応させ，高速なセッション起動を可能にすることに関する。
2010522450.tif 000002
【特許請求の範囲】
【請求項１】
クライアント側の方法であって，サーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項２】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアフレームが再生された時点までの時間と，クライアントからサーバへ切替要求が送信された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間と，のうち一つとして規定される請求項１に記載の方法。
【請求項３】
前記コンテンツ切替時間メトリックは，即時報告するように折衝できる請求項１に記載の方法。
【請求項４】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１に記載の方法。
【請求項５】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項１に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項６】
クライアント側のデバイスであって，サーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含むデバイス。
【請求項７】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項６に記載のデバイス。
【請求項８】
サーバ側の方法であって，クライアントが送信セッションの品質を報告する１又は複数のメトリックを処理するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項９】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項８に記載の方法。
【請求項１０】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項８に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項１１】
サーバ側のデバイスであって，クライアントが送信セッションの品質を報告する１又は複数のメトリックを処理するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含むデバイス。
【請求項１２】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１１に記載のデバイス。
【請求項１３】
請求項６に記載のクライアント側デバイスと，請求項１１に記載のサーバ側デバイスとを備えるシステム。
【請求項１４】
送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，前記新コンテンツの送信品質を報告するために，前記共通のメディア種別を有する前記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてをクライアントにおいて受け入れるステップを有する方法。
【請求項１５】
前記クライアントは，前記新コンテンツの再生要求によって前記メトリックを受け入れる請求項１４に記載の方法。
【請求項１６】
前記メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１４に記載の方法。
【請求項１７】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項１４に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項１８】
送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，前記新コンテンツの送信品質を報告するために，前記共通のメディア種別を有する前記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてを受け入れるように構成した処理ユニットを備えるデバイス。
【請求項１９】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１８に記載のデバイス。
【請求項２０】
サーバ及びクライアントを備えるシステムであって，該クライアントは請求項１９に記載のデバイスを含むシステム。
【請求項２１】
送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，前記新コンテンツの送信品質を報告するために，前記共通のメディア種別を有する前記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてを前記クライアントが受け入れることを許可するか，又は規定する規則を有するプロトコル。
【請求項２２】
送信セッションの品質を報告する少なくとも一つのメトリックを折衝するステップを有し，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されない方法。
【請求項２３】
前記の折衝ステップの少なくとも一部は，前記コンテンツ再生要求の後で行う請求項２２に記載の方法。
【請求項２４】
前記メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項２２に記載の方法。
【請求項２５】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項２２に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項２６】
クライアント側のデバイスであって，送信セッションの品質を報告する少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されないデバイス。
【請求項２７】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項２６に記載のデバイス。
【請求項２８】
サーバ及びクライアントを備えるシステムであって，該クライアントは請求項２６に記載のデバイスを含むシステム。
【請求項２９】
クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されないことを規定する規則を有するプロトコル。
【請求項３０】
送信セッションの品質を報告する少なくとも一つのメトリックを折衝するステップを有し，前記の折衝ステップの少なくとも一部は，クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われる方法。
【請求項３１】
旧コンテンツから，該旧コンテンツ内のメディアストリームと異なるメディアストリーム，又は追加メディアストリームを少なくとも一つ含む新コンテンツへの切替が生じたとき，前記クライアントは，少なくとも一つのメトリックに関する情報を，前記送信セッションにおける少なくとも一つのメディアストリームの設定要求と，前記送信セッションにおける前記新コンテンツ再生要求と，のうち一つに挿入することによって，前記少なくとも一つのメディアストリームの前記少なくとも一つのメトリックの折衝を開始し，前記の双方の要求はパイプライン化されて前記クライアントから前記サーバへ送信される請求項３０に記載の方法。
【請求項３２】
前記メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項３０に記載の方法。
【請求項３３】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項３０に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項３４】
クライアント側のデバイスであって，送信セッションの品質を報告する少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，前記折衝の少なくとも一部は，クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われるデバイス。
【請求項３５】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項３４に記載のデバイス。
【請求項３６】
サーバ側のデバイスであって，送信セッションの品質を報告するためにクライアントが用いる少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，前記折衝の少なくとも一部は，前記クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われるデバイス。
【請求項３７】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項３６に記載のデバイス。
【請求項３８】
請求項３４に記載のクライアント側デバイスと，請求項３６に記載のサーバ側デバイスとを備えるシステム。
【請求項３９】
送信セッションの品質を報告する少なくとも一つのメトリックの少なくとも一部は，クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われることを許可する規則を有するプロトコル。
【請求項４０】
送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，前記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承するステップを有する方法。
【請求項４１】
前記旧コンテンツの報告頻度は，前記新コンテンツの報告頻度と同一とする請求項４０に記載の方法。
【請求項４２】
前記のコンテンツ切替の前又は途中で，前記クライアントに関して前記少なくとも一つのメトリックが継承されることを，ＳＤＰファイル及び要求のうち一つに規定する請求項４０に記載の方法。
【請求項４３】
前記メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項４０に記載の方法。
【請求項４４】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項４０に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項４５】
送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，前記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承するように構成した処理ユニットを備えるデバイス。
【請求項４６】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項４５に記載のデバイス。
【請求項４７】
サーバ及びクライアントを備えるシステムであって，該クライアントは請求項４５に記載のデバイスを含むシステム。
【請求項４８】
送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，前記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承することを許可するか，又は規定する規則を有するプロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，１又は複数のメトリックによって送信セッションの品質を報告する方法と，計算機プログラム製品と，クライアントと，サーバと，システムと，プロトコルと，に関する。
【背景技術】
【０００２】
第３世代パートナシッププロジェクト（３ＧＰＰ）のパケット交換ストリームサービス（ＰＳＳ）は，３Ｇ通信網におけるインターネットプロトコル（ＩＰ）によるストリーム応用の体系（framework）を提供する。３ＧＰＰ文書，TS 26.234 V.6.a.0，"Transparent end-to-end Packet-switched Streaming Service (PSS) Protocols and codecs (Release 6)"は，３ＧＰＰ ＰＳＳのプロトコル及びコーデックを規定したものであり，ここに参照する。制御信号方式と，能力交換と，メディア転送と，速度適応と，ストリーム保護と，が規定されている。
【０００３】
更に，ＰＳＳは任意選択の体感品質（ＱｏＥ）のメトリック体系も規定している。ＱｏＥメトリック体系は，メディアストリーム応用の最終利用者体感（end user experience）を評価する技法である。該体系は，結果（ＱｏＥメトリック）を抽出する際に，層を横断する測定値の組合せを可能にする。抽出された結果は，種々の通信網条件における最終利用者体感を監視し，改善するために用いられる。
【０００４】
ＱｏＥメトリックに対応する３ＧＰＰ ＰＳＳクライアントは，測定規定に従って品質測定を行い，結果をクライアントＱｏＥメトリックに集約し，要求されたとき，ＱｏＥ転送プロトコルを用いて該メトリックをＰＳＳサーバへ転送する。
【０００５】
ＱｏＥメトリック体系は，中でも次の項目を含む。
【０００６】
ＱｏＥメトリック定義：  セッションレベル及びメディアレベルでの体感品質を評価するためのＱｏＥメトリック集合が規定される。3GPP TS 26.234 V.6.a.0は，これらのメトリックを計算する方法，及びそれらの送信頻度について規定し，勧告を行っている。
【０００７】
ＱｏＥメトリック折衝：  ＰＳＳのクライアント及びサーバが，ＰＳＳクライアントが送信するＱｏＥメトリックと，そのメトリックの送信頻度と，メトリック送信を停止させる方法と，を折衝できるように，実時間ストリームプロトコル（ＲＴＳＰ）ヘッダ"3GPP-QoE-metrics"が規定される。このヘッダは，ＲＴＳＰの設定（SETUP）メソッドと，パラメータ設定（SET_PARAMETER）メソッドと，（セッションＩＤを含む）オプション（OPTIONS）メソッドと，再生（PLAY）メソッドと，の要求及び応答によって送信される。3GPP TS 26.234 V.6.a.0によれば，この折衝はＰＳＳサーバが提供するセッション記述プロトコル（ＳＤＰ）ファイル又はＰＳＳクライアントからのRTSP SETUP要求によって開始され，遅くともRTSP PLAY応答メッセージがＰＳＳサーバによって発行されたときには終了する。クライアントは，RTSP PLAY要求を単に発行することによって折衝過程を終了することができる。メディア転送が始まると，ＱｏＥメトリック帰還（feedback）を停止すること以外，更なるＱｏＥメトリック折衝は許可されない。
【０００８】
ＱｏＥメトリック転送：  折衝済みＱｏＥメトリックを，ＰＳＳクライアントからＰＳＳサーバへ転送するために，ＲＴＳＰヘッダ"3GPP-QoE-feedback"が規定され，一定のＲＴＳＰメソッド（SET_PARAMETER，一時停止（PAUSE）又は停止（TEARDOWN））に関係する。
【０００９】
３ＧＰＰ ＰＳＳ仕様書第７版（ＰＳＳｅとも呼ばれる）が，３ＧＰＰ ＳＡ４において現在開発されている。この作業項目は，既存のパケット交換ストリーム（ＰＳＳ）仕様を，新規機能及び最新のメディアコーデック構成で強化するものである。この作業の主な目的の一つは，ＰＳＳチャネル／コンテンツ切替時間を改善し，またＰＳＳｅセッションの開始を高速化することである。
【００１０】
３ＧＰＰ仕様書第７版に関する変更要求S4-070151，"Fast Content Switching and Start-Up"に記載されているとおり，高速コンテンツ起動のためにＲＴＳＰメッセージのパイプライン化が導入された。特に，ＰＳＳセッション開始を高速化するために，種々のメディアストリームのRTSP SETUP要求と，集約制御PLAY要求とをパイプラインにすることが合意された。図１のダイヤグラム１００に，クライアントとサーバとの間でＲＴＳＰ要求及びＲＴＳＰ応答が交換され，映像用RTSP SETUP要求１０１及び音響用RTSP SETUP要求１０２と，RTSP PLAY要求１０３と，がパイプライン化されていることが示されている。
【００１１】
類似して，ＰＳＳチャネル／コンテンツ切替を高速化するために，旧ＲＴＳＰセッションを停止することなく新ＰＳＳセッションを設定し，新ＲＴＳＰセッションを開始できる新規ＲＴＳＰヘッダが規定された。特に高速コンテンツ切替のために，"Switch-Stream"ヘッダを有する過積載PLAY要求を用いて，受信器にストリームする新規コンテンツが示される。図２のダイヤグラム２００に，サーバとクライアントとの間のＲＴＳＰ要求及びＲＴＳＰ応答の交換が示されている。クライアントは"Switch-Stream"ヘッダを有するRTSP PLAY要求を用いて，二つの旧ストリームから二つの新ストリームへの切替が行われることをサーバに示し，サーバはRTSP "200 OK"応答によって切替を確認する。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
標準化グループによって合意された現在の解決策（高速チャネル／コンテンツ切替及び高速セッション開始）は，ＲＴＳＰセッション設定に先立つセッションプロトコルに大きな変更をもたらす。この解決策の指針原理は，メディアレベル及びセッションレベルの転送パラメータが，二つのコンテンツ間で類似しているという合理的推測によって，往復遅延をできる限り取り除くことである。
【００１３】
ＰＳＳ仕様書第６版では，ＱｏＥ折衝によって総合セッション設定遅延を増加させることができない。メディア毎に別個のSETUP要求／応答対のために，複数の往復が生じる。この場合，ＱｏＥメトリック折衝ヘッダはRTSP SETUP要求／応答対に相乗りしているので，ＱｏＥメトリック折衝は総合セッション設定遅延に大きく影響することはない。
【００１４】
これに対してＰＳＳ第７版（ＰＳＳｅ）では，セッション設定は１又は２往復しか必要としない。この場合，１往復時間内で完全な折衝を行うことはできないので，ＱｏＥ折衝はセッション設定時間に大きな影響がある。
【００１５】
このようにＰＳＳｅで既存のＱｏＥ折衝プロトコルを用いると，セッション開始時間及びコンテンツ切替時間が増加する。したがって，新しいセッション開始及び切替の最適化を反映するためには，ＱｏＥメトリック折衝過程を修正する必要がある。
【００１６】
更に，ＰＳＳ第７版（ＰＳＳｅ）は開始時間及び切替時間を大きく改善する解決策を標準化しているが，実際のサービスにおける最終利用者体感は，種々のチャネル条件及びコンテンツ構成（例えば，コンテンツ内のメディアストリーム数及びそのビット速度）によって異なることがある。しかし，ＰＳＳｅの強化項目，特にチャネル／コンテンツ切替時の利用者体感の効果を評価するＱｏＥメトリックは，今のところ存在しない。
【課題を解決するための手段】
【００１７】
（第１態様）
本発明の第１態様によってクライアント側の方法が開示され，該方法はサーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するステップを有し，上記１又は複数のメトリックは，上記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。
【００１８】
本発明の第１態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは上記のクライアント側の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００１９】
本発明の第１態様によってクライアント側のデバイスがまた更に開示され，該デバイスは，サーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するように構成した処理ユニットを備え，上記１又は複数のメトリックは，上記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。このデバイスは例えばクライアント，又はその一部であってよい。
【００２０】
本発明の第１態様によってクライアント側のデバイスがまた更に開示され，該デバイスは，サーバに報告する送信セッションの品質を１又は複数のメトリックによって測定する手段を備え，上記１又は複数のメトリックは，上記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。このデバイスは例えばクライアント，又はその一部であってよい。
【００２１】
本発明の第１態様によってサーバ側の方法がまた更に開示され，該方法はクライアントが送信セッションの品質を報告する１又は複数のメトリックを処理するステップを有し，上記１又は複数のメトリックは，上記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。
【００２２】
本発明の第１態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは上記のサーバ側の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００２３】
本発明の第１態様によってサーバ側のデバイスがまた更に開示され，該デバイスは，クライアントが送信セッションの品質を報告する１又は複数のメトリックを処理するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。このデバイスは例えばサーバ，又はその一部であってよい。
【００２４】
本発明の第１態様によってサーバ側のデバイスがまた更に開示され，該デバイスは，クライアントが送信セッションの品質を報告する１又は複数のメトリックを処理する手段を備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む。このデバイスは例えばサーバ，又はその一部であってよい。
【００２５】
本発明の第１態様によってシステムがまた更に開示され，該システムは本発明の第１態様によるクライアント側デバイス及びサーバ側デバイスを備える。
【００２６】
本発明の第１態様によれば，送信セッションにおいてコンテンツがクライアントに送信される。上記送信セッションは例えばストリームセッションであってもよく，該セッションでコンテンツは，例えば有線通信網若しくは無線通信網，又はそれらの組合せにおける１又は複数のメディアストリームを介してクライアントへストリームされる。上記のメディアストリームは，例えば実時間転送プロトコル（ＲＴＰ）のメディアストリームであってよい。上記コンテンツはコンテンツ源から発せられる。この送信セッションは，例えばストリームセッションの場合，実時間ストリームプロトコル（ＲＴＳＰ）によって設定し，制御してもよい。
【００２７】
この送信セッションにおいては，例えば利用者の要求に応じて複数のコンテンツを切り替えることができる。ストリームセッションの場合，メディア送信信号は例えばメディアストリームであってもよい。そしてコンテンツは，例えばメディアストリームの同一の転送パラメータ及び／又はコーデックパラメータを維持しつつ，メディアストリームの（同一又は別のメディア種別の）コンテンツを置き換え，及び／又はメディアストリームを置き換え，及び／又はメディアストリームを追加及び／又は削除することによって，切り替えてもよい。セッションがＲＴＳＰによって制御されているときは，この切替は例えばRTSP PLAY要求の"Switch-Stream"ヘッダを用いて行ってもよい。
【００２８】
クライアントにおいて，送信セッションの品質が１又は複数のメトリックによって測定され，サーバへ報告されて，例えば送信セッションの品質評価などの処理が行われる。ここで上記メトリックが報告されるサーバは，コンテンツ源である必要はない。
【００２９】
上記１又は複数のメトリックは，送信セッションにおいてコンテンツを切り替えるのに掛かる時間に関係するコンテンツ切替時間メトリックを含み，これによって運用事業者又はサービス提供事業者はコンテンツ切替時の利用者体感を評価することができる。
【００３０】
本発明の第１態様の例示実施例によれば，上記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，上記新コンテンツの最初のメディアフレームが再生された時点までの時間と，クライアントからサーバへ切替要求が送信された時点から，上記新コンテンツの最初のメディアパケットが上記クライアントで受信された時点までの時間と，のうち一つとして規定される。均等に，上記コンテンツ切替時間メトリックは，上記二つの規定の組合せ又はその要素によって規定してもよい。
【００３１】
本発明の第１態様の更なる例示実施例によれば，上記コンテンツ切替時間メトリックは即時報告するように折衝できる。このため，新報告頻度値"Start"をコンテンツ切替時間メトリックとして規定してもよい。
【００３２】
本発明の第１態様の更なる例示実施例によれば，上記コンテンツ切替時間メトリックは第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックである。
【００３３】
（第２態様）
本発明の第２態様によって，方法が開示され，該方法は送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，前記新コンテンツの送信品質を報告するために，前記共通のメディア種別を有する前記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてをクライアントにおいて受け入れる。
【００３４】
本発明の第２態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは本発明の第２態様の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００３５】
本発明の第２態様によってデバイスがまた更に開示され，該デバイスは，送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，上記新コンテンツの送信品質を報告するために，上記共通のメディア種別を有する上記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてを受け入れるように構成した処理ユニットを備える。このデバイスは例えばクライアント，又はその一部であってよい。
【００３６】
本発明の第２態様によってデバイスがまた更に開示され，該デバイスは，送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，上記新コンテンツの送信品質を報告するために，上記共通のメディア種別を有する上記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてを受け入れる手段を備える。このデバイスは例えばクライアント，又はその一部であってよい。
【００３７】
本発明の第２態様によってシステムがまた更に開示され，該システムはサーバ及びクライアントを備え，該クライアントは本発明の第２態様によるデバイスを備える。
【００３８】
本発明の第２態様によってプロトコルがまた更に開示され，該プロトコルは，送信セッションにおいて，双方が共通のメディア種別を有する旧コンテンツから新コンテンツへの切替が生じたとき，前記新コンテンツの送信品質を報告するために，前記共通のメディア種別を有する前記旧コンテンツの送信品質を報告するためにクライアントとサーバとの間で既に折衝された１又は複数のメトリックのすべてを前記クライアントが受け入れることを許可するか，又は規定する規則を有する。このプロトコルは，例えば３ＧＰＰ ＰＳＳによるＱｏＥ折衝プロトコルであってよい。
【００３９】
本発明の第２態様によれば，送信セッションにおいてコンテンツがクライアントに送信される。上記送信セッションは例えばストリームセッションであってもよく，該セッションでコンテンツは，例えば有線通信網若しくは無線通信網，又はそれらの組合せにおける１又は複数のメディアストリームを介してクライアントへストリームされる。上記のメディアストリームは，例えば実時間転送プロトコル（ＲＴＰ）のメディアストリームであってよい。この送信セッションは，例えばストリームセッションの場合，実時間ストリームプロトコル（ＲＴＳＰ）によって設定し，制御してもよい。
【００４０】
この送信セッションにおいては，例えば利用者の要求に応じて複数のコンテンツを切り替えることができる。ストリームセッションの場合，メディア送信信号は例えばメディアストリームであってもよい。そしてコンテンツは，例えばメディアストリームの同一の転送パラメータ及び／又はコーデックパラメータを維持しつつ，メディアストリームの（同一又は別のメディア種別の）コンテンツを置き換え，及び／又はメディアストリームを置き換え，及び／又はメディアストリームを追加及び／又は削除することによって，切り替えてもよい。セッションがＲＴＳＰによって制御されているときは，この切替は例えばRTSP PLAY要求の"Switch-Stream"ヘッダを用いて行ってもよい。
【００４１】
クライアントにおいて，送信セッションの品質が１又は複数のメトリックによって測定され，サーバへ報告されて，例えば送信セッションの品質評価などの処理が行われる。ここで上記メトリックが報告されるサーバは，コンテンツ源である必要はない。
【００４２】
旧コンテンツの送信品質を報告するためのメトリックは，クライアントとサーバとの間で折衝される。ここで上記メトリックの上記折衝は，メトリック自体についての合意，及び／又は例えばメトリックの報告の頻度を示す報告頻度若しくは範囲であるメトリックに関係するメトリック値についての合意，を見いだすステップを含むものと理解してよい。
【００４３】
往復時間を減少させるため，（例えば映像，音響，音声，字幕などの）共通メディア種別の場合，新コンテンツのいくつかのメディア種別又はすべてのメディア種別に対応する旧コンテンツのメディア種別について既に折衝されたすべてのメトリックがクライアントに受け入れられて新コンテンツの送信品質が報告され，これらのメトリックについては更なる折衝は必要ない。換言すれば，旧メディア送信信号（例えばメディアストリーム）と新メディア送信信号（例えばメディアストリーム）とが同一メディア種別のときは，クライアントは新メディアストリーム用に同一のＱｏＥメトリックを受け入れる。この受け入れは，メトリックと，該メトリックに関係するメトリック値との双方に関係してもよい。クライアント又はサーバは，必要ならばセッション中にメトリックを破棄してもよい。
【００４４】
本発明の第２態様の例示実施例によれば，クライアントは新コンテンツの再生要求によってメトリックを受け入れる。
【００４５】
本発明の第２態様の更なる例示実施例によれば，上記メトリックは第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックである。そして上記メトリックは，例えばRTSP PLAY要求によって受け入れられる。
【００４６】
（第３態様）
本発明の第３態様によって，方法が開示され，該方法は送信セッションの品質を報告する少なくとも一つのメトリックを折衝するステップを有し，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されない。
【００４７】
本発明の第３態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは本発明の第３態様の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００４８】
本発明の第３態様によってクライアント側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告する少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されない。
【００４９】
本発明の第３態様によってクライアント側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告する少なくとも一つのメトリックを折衝する手段を備え，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されない。
【００５０】
本発明の第３態様によってシステムがまた更に開示され，該システムはサーバ及びクライアントを備え，該クライアントは本発明の第３態様によるデバイスを備える。
【００５１】
本発明の第３態様によってプロトコルがまた更に開示され，該プロトコルは，クライアント側の折衝は，前記送信セッションにおけるメディア送信設定の少なくとも一つの要求と，前記送信セッションにおけるコンテンツ再生要求とを含むいくつかのパイプライン化された要求が行われるまで開始されないことを規定する規則を有する。このプロトコルは，例えば３ＧＰＰ ＰＳＳのＱｏＥ折衝プロトコルであってよい。
【００５２】
本発明の第３態様によれば，送信セッションにおいてコンテンツがクライアントに送信される。上記送信セッションは例えばストリームセッションであってもよく，該セッションでコンテンツは，例えば有線通信網若しくは無線通信網，又はそれらの組合せにおける１又は複数のメディアストリームを介してクライアントへストリームされる。上記のメディアストリームは，例えば実時間転送プロトコル（ＲＴＰ）のメディアストリームであってよい。この送信セッションは，例えばストリームセッションの場合，実時間ストリームプロトコル（ＲＴＳＰ）によって設定し，制御してもよい。
【００５３】
クライアントにおいて，送信セッションの品質が１又は複数のメトリックによって測定され，サーバへ報告されて，例えば送信セッションの品質評価などの処理が行われる。ここで上記メトリックが報告されるサーバは，コンテンツ源である必要はない。
【００５４】
高速セッション開始を確実にするため，少なくとも一つのメトリックのクライアント側折衝は，送信セッションにおけるメディア送信の少なくとも一つの設定要求及び送信セッションにおけるコンテンツ再生要求を含む複数のパイプライン化された要求が行われるまで開始されない。ここで，上記再生要求は，例えばＲＴＳＰセッションであってよい送信セッションにおけるコンテンツ再生の最初の要求であってよい。上記複数のパイプライン化された要求とは，連続して発行された複数の要求と理解してもよく，発行された要求に対する応答を待たずに次の要求が発行される。このようにして，メトリック折衝によってコンテンツ再生が開始されるまでの追加往復時間は生じない。クライアント側折衝は，例えば複数のパイプライン化された要求のうち一つ，すなわち設定要求又は再生要求によって開始される。クライアントには，送信セッションの品質を報告するためにサーバが受け入れるメトリックを記述するファイル（例えばセッション記述プロトコル（ＳＤＰ）ファイル）が与えられる。このＳＤＰファイルは，例えばクライアントのRTSP DESCRIBE要求に応答してサーバからクライアントへ送信してもよい。均等に，ＳＤＰファイルはクライアントに予め記憶しておいてもよいし，別の手段によってクライアントへ送信してもよい。そしてクライアントは，クライアントが対応するメトリックの選択（例えば報告頻度又は範囲などのメトリックに関係するメトリック値を含む）を，パイプライン化した設定／再生要求のうち一つで搬送することによってクライアント側折衝を開始してもよい。
【００５５】
本発明の第３態様の例示実施例によれば，折衝の少なくとも一部はコンテンツ再生要求の後に行われる。クライアントがコンテンツ再生要求を行った後に行われる折衝の一部は，品質報告の停止だけに限らない。クライアントがコンテンツ再生要求を行った後に行われる折衝，又は折衝の一部は，少なくとも変更したメトリック及び／又はメトリック値の提案を含み，この変更とは折衝相手の提案を指す。
【００５６】
本発明の第３態様の例示実施例によれば，上記メトリックは第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックである。そして上記少なくとも一つのメトリックのクライアント側折衝は，例えば"3GPP-QoE-Metrics"ヘッダを含むパイプライン化されたRTST SETUP/PLAY要求によって開始してもよい。
【００５７】
（第４態様）
本発明の第４態様によって方法が開示され，該方法は送信セッションの品質を報告する少なくとも一つのメトリックを折衝するステップを有し，前記の折衝ステップの少なくとも一部は，クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われる。
【００５８】
本発明の第４態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは本発明の第４態様の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００５９】
本発明の第４態様によってクライアント側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告する少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，上記折衝の少なくとも一部は，クライアントが上記送信セッション内でコンテンツ再生要求を行った後に行われる。このデバイスは例えばクライアント，又はその一部であってよい。
【００６０】
本発明の第４態様によってクライアント側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告する少なくとも一つのメトリックを折衝する手段を備え，上記折衝の少なくとも一部は，クライアントが上記送信セッション内でコンテンツ再生要求を行った後に行われる。このデバイスは例えばクライアント，又はその一部であってよい。
【００６１】
本発明の第４態様によってサーバ側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告するためにクライアントが用いる少なくとも一つのメトリックを折衝するように構成した処理ユニットを備え，前記折衝の少なくとも一部は，前記クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われる。このデバイスは例えばクライアント，又はその一部であってよい。
【００６２】
本発明の第４態様によってサーバ側デバイスがまた更に開示され，該デバイスは，送信セッションの品質を報告するためにクライアントが用いる少なくとも一つのメトリックを折衝する手段を備え，前記折衝の少なくとも一部は，前記クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われる。このデバイスは例えばクライアント，又はその一部であってよい。
【００６３】
本発明の第４態様によってシステムがまた更に開示され，該システムは本発明の第４態様によるクライアント側デバイスを備えるクライアントと，本発明の第４態様によるサーバ側デバイスを備えるサーバと，を備える。
【００６４】
本発明の第４態様によってプロトコルがまた更に開示され，該プロトコルは，送信セッションの品質を報告する少なくとも一つのメトリックの少なくとも一部は，クライアントが前記送信セッション内でコンテンツ再生要求を行った後に行われることを許可する規則を有する。
【００６５】
本発明の第４態様によれば，送信セッションにおいてコンテンツがクライアントに送信される。上記送信セッションは例えばストリームセッションであってもよく，該セッションでコンテンツは，例えば有線通信網若しくは無線通信網，又はそれらの組合せにおける１又は複数のメディアストリームを介してクライアントへストリームされる。上記のメディアストリームは，例えば実時間転送プロトコル（ＲＴＰ）のメディアストリームであってよい。この送信セッションは，例えばストリームセッションの場合，実時間ストリームプロトコル（ＲＴＳＰ）によって設定し，制御してもよい。
【００６６】
クライアントにおいて，送信セッションの品質が１又は複数のメトリックによって測定され，サーバへ報告されて，例えば送信セッションの品質評価などの処理が行われる。ここで上記メトリックが報告されるサーバは，コンテンツ源である必要はない。
【００６７】
上記の再生要求は，例えば送信セッションにおける最初の再生要求であってよい。この場合，上記の折衝はクライアントがコンテンツ再生要求を行った後ですべて行ってもよい。均等に，上記の再生要求は送信セッションにおける後の再生要求であってもよい。
【００６８】
上記の再生要求されたコンテンツは，例えば上記少なくとも一つのメトリックが折衝されたコンテンツと少なくとも一部異なっていてもよい。例えば，上記送信セッションの第１コンテンツに再生要求がなされ，第１コンテンツから第２コンテンツにコンテンツ切替が行われたとき，又はその後で第２コンテンツ用の少なくとも一つのメトリックの折衝が開始される。上記の折衝は，クライアントがコンテンツ再生を要求した後ですべて行ってもよい。
【００６９】
上記少なくとも一つのメトリックは，クライアントとサーバとの間で折衝される。クライアントがコンテンツ再生を要求した後で行われる折衝は，品質報告の停止だけに限定されない。クライアントがコンテンツ再生要求を行った後に行われる折衝，又は折衝の一部は，少なくとも変更したメトリック及び／又はメトリック値の提案を含み，この変更とは折衝相手の提案を指す。
【００７０】
本発明の第４態様の例示実施例によれば，旧コンテンツから，旧コンテンツ内のメディアストリームに対して追加のメディアストリーム又は異なるメディアストリームを含む新コンテンツへの切替が行われるとき，上記クライアントは，少なくとも一つのメトリックに関する情報を，上記送信セッションにおける少なくとも一つのメディアストリームの設定要求と，上記送信セッションにおける上記新コンテンツ再生要求と，のうち一つに挿入することによって，上記少なくとも一つのメディアストリームの上記少なくとも一つのメトリックの折衝を開始し，上記の双方の要求はパイプライン化されて上記クライアントから上記サーバへ送信される。
【００７１】
上記のメディアストリームは，例えばＲＴＰメディアストリームであってよい。コンテンツは，例えばメディアストリームの同一の転送パラメータ及び／又はコーデックパラメータを維持しつつ，メディアストリームの（同一又は別のメディア種別の）コンテンツを置き換え，及び／又はメディアストリームを置き換え，及び／又はメディアストリームを追加及び／又は削除することによって，切り替えてもよい。
【００７２】
ここで上記少なくとも一つのメトリックに関係する情報は，例えばクライアントが上記メトリック及び／又は該メトリックに関係するメトリック値の提案を利用することを望むかどうかを示す情報であってよい。
【００７３】
ここで，パイプライン化した形態での送信とは，要求を連続して送信することと理解してもよく，第２要求は，第１要求に対する応答を待たずに送信される。３ＧＰＰ ＰＳＳシステムでは，上記少なくとも一つのメトリックに関係する情報は，例えば新規メディアに対するパイプラインRTSP SETUP要求，又はコンテンツに対するパイプライン集約RTSP PLAY要求に挿入してもよい。
【００７４】
本発明の第４態様の更なる例示実施例によれば，メトリックは第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質である。
【００７５】
（第５態様）
本発明の第５態様によって，方法が開示され，該方法は送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，上記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承するステップを有する。
【００７６】
本発明の第５態様によって計算機プログラムを記憶した計算機可読媒体が更に開示され，該計算機プログラムは本発明の第５態様の方法をプロセッサに実行させる命令を含む。この計算機プログラムはまたそれ自体，すなわち計算機可読媒体に記憶されない形態，としても開示されたものと理解される。
【００７７】
本発明の第５態様によってデバイスがまた更に開示され，該デバイスは，送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，上記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承するように構成した処理ユニットを備える。
【００７８】
本発明の第５態様によってデバイスがまた更に開示され，該デバイスは，送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，上記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承する手段を備える。
【００７９】
本発明の第５態様によってシステムがまた更に開示され，該システムはサーバ及びクライアントを備え，該クライアントは本発明の第５態様によるデバイスを備える。
【００８０】
本発明の第５態様によってプロトコルがまた更に開示され，該プロトコルは，送信セッション内で旧コンテンツから新コンテンツへの切替が生じたとき，前記旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックを継承することを許可するか，又は規定する規則を有する。
【００８１】
本発明の第５態様によれば，送信セッションにおいてコンテンツがクライアントに送信される。上記送信セッションは例えばストリームセッションであってもよく，該セッションでコンテンツは，例えば有線通信網若しくは無線通信網，又はそれらの組合せにおける１又は複数のメディアストリームを介してクライアントへストリームされる。上記のメディアストリームは，例えば実時間転送プロトコル（ＲＴＰ）のメディアストリームであってよい。この送信セッションは，例えばストリームセッションの場合，実時間ストリームプロトコル（ＲＴＳＰ）によって設定し，制御してもよい。
【００８２】
クライアントにおいて，送信セッションの品質が１又は複数のメトリックによって測定され，サーバへ報告されて，例えば送信セッションの品質評価などの処理が行われる。ここで上記メトリックが報告されるサーバは，コンテンツ源である必要はない。
【００８３】
この送信セッションにおいては，例えば利用者の要求に応じて複数のコンテンツを切り替えることができる。ストリームセッションの場合，コンテンツは，例えばメディアストリームの同一の転送パラメータ及び／又はコーデックパラメータを維持しつつ，メディアストリームの（同一又は別のメディア種別の）コンテンツを置き換え，及び／又はメディアストリームを置き換え，及び／又はメディアストリームを追加及び／又は削除することによって，切り替えてもよい。セッションがＲＴＳＰによって制御されているときは，この切替は例えばRTSP PLAY要求の"Switch-Stream"ヘッダを用いて行ってもよい。
【００８４】
このようなコンテンツ切替が生じたとき，旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝された少なくとも一つのメトリックが継承される。均等に，旧コンテンツの送信品質を報告するために，クライアントとサーバとの間で折衝されたすべてのメトリックを新コンテンツが継承してもよい。継承とは，旧コンテンツ用に既に折衝されたメトリックを，切替が発生した後で新コンテンツに適応させるために再折衝する必要がなく，それらが切替直後に後者のコンテンツに適用されることを意味する。例えば，クライアントに対してはメトリックが継承されることを（例えばＳＤＰファイル又はコンテンツ切替の前及び／又は途中の任意のＲＴＳＰ要求によって）規定し，サーバに対してはメトリックが継承されたことを想定するように規定してもよい。
【００８５】
明示的に修正され又は停止されない限り，新コンテンツの品質報告は旧コンテンツと同一の頻度で継続してよい。したがって，新コンテンツのメトリックのための折衝は必要ない。しかし，コンテンツ切替が実行された後に報告事象が起きたときは，旧コンテンツに関する統一資源位置指定子（ＵＲＬ）の代わりに新コンテンツの統一資源位置指定子を用いてもよい。
【００８６】
既に折衝されたメトリックを継承することに加えて，（例えば，旧コンテンツのメディアストリームと異なる新ストリームのメディアストリーム用に）更なるメトリックを折衝してもよい。この折衝は，クライアントが再生要求を発行した後で少なくとも一部を行ってもよい。
【００８７】
本発明の第５態様の例示実施例によれば，旧コンテンツの報告頻度は，新コンテンツの報告頻度と同一である。明示的に修正され又は停止されない限り，品質報告は旧メディアストリーム，すなわち旧コンテンツと同一の頻度で継続してよい。
【００８８】
本発明の第５態様の例示実施例によれば，上記のコンテンツ切替の前又は途中で，上記記クライアントに関して上記少なくとも一つのメトリックが継承されることが，ＳＤＰファイル及び要求のうち一つに規定される。上記要求は，例えばＲＴＳＰ要求であってよい。
【００８９】
本発明の第５態様の更なる例示実施例によれば，上記メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックである。
【００９０】
本発明の上記及びほかの態様は，以降に提示する詳細な説明から明白であり，また明確になる。
【００９１】
上述した本発明の種々の態様の特徴，及びそれらの例示実施例の特徴は，各々のすべての可能な組合せにおいても開示されたものとする。
【図面の簡単な説明】
【００９２】
【図１】パケット交換ストリームサービスによる高速セッション開始を例示する図である。
【図２】パケット交換ストリームサービスによる高速コンテンツ切替を例示する図である。
【図３】本発明によるシステムの例示実施例の簡単なブロック図である。
【図４】本発明の第１態様による方法の例示実施例のフローチャートである。
【図５】本発明の第１態様によるContent_Switch_Timeメトリックの計算法を簡単に示す図である。
【図６】本発明の第２態様による方法の例示実施例のフローチャートである。
【図７】本発明の第３態様による方法の例示実施例のフローチャートである。
【図８】本発明の第４態様による方法の例示実施例のフローチャートである。
【図９】本発明の第５態様による方法の例示実施例のフローチャートである。
【発明を実施するための形態】
【００９３】
本願明細書では，以降第３世代パートナシッププロジェクト（３ＧＰＰ）パケット交換ストリームサービス（ＰＳＳ）システムにおける本発明の例示実施例を説明する。
【００９４】
図３は，本発明によるシステム１の例示実施例の簡単なブロック図である。システム１はＰＳＳサーバ２及びＰＳＳクライアント３を備える。
【００９５】
サーバ２は，サーバ２の動作全体を制御するプロセッサ２０を備える。プロセッサ２０はプロセッサメモリ２１に記憶されたプログラムコードを実行する。プロセッサメモリは例えばランダムアクセスメモリ（ＲＡＭ）若しくは読み出し専用メモリ（ＲＯＭ）のような固定的に組み込まれたメモリであってもよいし，又はメモリカード若しくは光記憶媒体のような着脱可能メモリであってもよい。プロセッサ２０は，クライアント３へストリームされるコンテンツを記憶するコンテンツ記憶装置を利用することができる。ここでコンテンツは，例えば映像音響ストリーム又は音声のような１又は複数のメディアストリームからなっているものとする。例えばパケット交換インタフェースであるインタフェース２２を介して，プロセッサ２０はクライアント３と通信することができる。
【００９６】
代替として，コンテンツは１又は複数の個別コンテンツサーバに記憶してもよいことに注意されたい。この場合，図１のサーバ２はＲＴＳＰサーバとしてだけ機能し，クライアント３と上記のようなコンテンツサーバとの間のストリームセッションを設定し，制御する。しかし，単純にするため図１においては，ＲＴＳＰサーバとコンテンツサーバとは併設されているものとする。
【００９７】
プロセッサ２０は，ストリームセッションにおいてサーバ２からクライアント３へコンテンツをストリームし，そのストリームセッションの品質を監視するすべての機能を実現する。このためプロセッサ２０は，コンテンツをストリームするためのプロトコルスタックを実現し，該プロトコルスタックはコンテンツのペイロードを実時間転送プロトコル（ＲＴＰ）と，利用者データグラムプロトコル（ＵＤＰ）と，インターネットプロトコル（ＩＰ）との形式に変換する適応層を有する。更に，プロセッサ２０はこのストリームを設定し，制御するプロトコルスタックを実現する。該プロトコルスタックは実時間ストリームプロトコル（ＲＴＳＰ）を含み，ＲＴＳＰは，いずれもＩＰを利用する転送制御プロトコル（ＴＣＰ）又はＵＤＰのいずれかを利用する。ＲＴＳＰは，ストリームセッションを設定するために，例えばセッション記述プロトコル（ＳＤＰ）による提示記述を少なくとも必要とする。ＲＴＳＰは更に，サーバ２とクライアント３との間で体感品質（ＱｏＥ）メトリックを折衝し，これらのＱｏＥメトリックをクライアント３からサーバ２へ転送する役割をする。
【００９８】
クライアント３は，その動作全体を制御するプロセッサ３０を備える。プロセッサ３０はプロセッサメモリ３１に記憶されたプログラムコードを実行する。プロセッサメモリは例えばランダムアクセスメモリ（ＲＡＭ）若しくは読み出し専用メモリ（ＲＯＭ）のような固定的に組み込まれたメモリであってもよいし，又はメモリカード若しくは光記憶媒体のような着脱可能メモリであってもよい。プロセッサ３０は，利用者入力を受け付けるインタフェース３２と，ストリームセッション内でサーバ２からクライアント３へストリームされるコンテンツを再生するディスプレイ３３及びスピーカ３４と，を制御する。クライアント３は更に，サーバ２と通信するためのインタフェース３５を備える。上記インタフェースは，例えばパケットインタフェースであってよい。
【００９９】
ストリームセッションに参加し，このストリームセッションに関係するＱｏＥメトリックをサーバ２へ報告する機能を提供するために，クライアント３のプロセッサ３０は，サーバ２０のプロセッサ２０が実現するプロトコルスタック，すなわち適応層と，ＲＴＰと，ＵＤＰと，ＩＰと，ＲＴＳＰと，任意選択のＴＣＰと，を含むプロトコルスタック，に対応するプロトコルスタックを実現する。
【０１００】
ＰＳＳシステムにおいてサービス提供事業者に最終利用者ストリーム体感を評価する手段を提供するために，ＰＳＳシステムにストリームサービスＱｏＥメトリックが導入された。クライアント３は，実際のストリーム応用の品質に関する情報を測定してサーバ２へ帰還させる。上記の品質は，ＱｏＥメトリックによって規定される。品質メトリックは，例えばＲＴＳＰ及びＳＤＰを用いて転送される。均等に，例えばセッション開始プロトコル（ＳＩＰ），拡張可能マーク付け言語（ＸＭＬ），ハイパテキスト転送プロトコル（ＨＴＴＰ），ショートメッセージサービス（ＳＭＳ），その他いくつか，のほかのプロトコルを用いてＱｏＥメトリックを搬送してもよい。
【０１０１】
品質帰還を有するＰＳＳシステムにおけるクライアント３は，測定規定に従って品質測定を行い，その結果をストリームクライアント品質メトリックに集約し，そのメトリックをサーバ２へ報告する。
【０１０２】
サーバ２は，クライアントがＱｏＥメトリック報告を開始したことを通知し，クライアントのＱｏＥメトリックを集約する。サーバ２は受信したクライアントのＱｏＥメトリックを処理して集約品質メトリックを作成する。例えば，サーバは未処理の損失パケット報告を受信して，特定クライアントのパケット損失率の最小値と，最大値と，平均値と，標準偏差値とを計算してもよい。
【０１０３】
次に，図４，６，７，８及び９のフローチャートを参照して本発明の別の態様に関するシステム１の特定の動作を詳細に説明する。
【０１０４】
本発明の第１態様によれば，クライアントがサーバにコンテンツ切替時間を報告することができる新規ＱｏＥメトリック"Content_Switch_Time"が提案されている。Content_Switch_Time ＱｏＥメトリックは，運用事業者又はサービス提供事業者がチャネル／コンテンツ切替時の利用者体感を評価し，それによってＰＳＳｅ強化項目の有効性を評価できるようにするので特に有用である。
【０１０５】
Content_Switch_Time ＱｏＥメトリック報告の形式は，強化バッカスナウア形式（ＡＢＮＦ）で次のように規定される。
【数１】
2010522450.tif 000003
【０１０６】
この規定は，３ＧＰＰ ＰＳＳのＱｏＥ帰還報告構文によく適合する。
【０１０７】
このメトリックのTimestampパラメータは，切替動作が開始された時刻（例えば通常再生時刻（ＮＰＴ）で表される）を示すために用いられる。この時刻は，旧コンテンツの時間軸による。
【０１０８】
Content_Switch_Time ＱｏＥメトリックは，例えばクライアント上で利用者が新コンテンツを選択したときから，最初のメディアフレームが再生されたときまでの時間（例えばミリ秒で表される）として規定してもよい。あるいは，クライアントからサーバへ切替要求が送信されたときから，新メディアストリームの最初のメディアパケットがクライアントで受信されたときまでの時間（例えばミリ秒で表される）として規定してもよい。また，上記規定の任意の組合せであってもよい。
【０１０９】
Content_Switch_Time ＱｏＥメトリック値の即時報告を要求できると有利なことがある。このため，新規報告頻度値"Start"をContent_Switch_Time ＱｏＥメトリック用に規定してもよい。
【０１１０】
本発明の第１態様は，３ＧＰＰ ＰＳＳにおけるＱｏＥ体系に後方互換であるように実現すると有利である。例えば，新ＱｏＥメトリックの通知は，ＳＤＰファイルによって行ってもよいし，ＲＴＳＰ要求／応答メッセージのいずれかによって行ってもよい。折衝した頻度が"Start"に設定されているとき，コンテンツ切替が終了した直後にContent_Switch_Time ＱｏＥメトリックを報告してもよい。あるいは，頻度が"End"に設定されているときは，現在のコンテンツセッションの最後に報告してもよい。
【０１１１】
コンテンツ切替時刻は，常に旧コンテンツのＮＰＴを用いて計算してもよい。開始直後にコンテンツ切替時刻が報告されるときは，旧コンテンツのＮＰＴタイムスタンプを含んでもよい。そうでなければタイムスタンプは報告に有用ではない。
【０１１２】
コンテンツ切替時刻はミリ秒で計算され，ＮＰＴ時間縮尺によらない。
【０１１３】
図５は，コンテンツ切替時刻の計算を表している。図５は，旧コンテンツ５０１のＮＰＴと，壁時計時刻５０２と，新コンテンツ５０３のＮＰＴと，を示している。そしてコンテンツ切替時間５０６は，コンテンツ間の切替が完了した時刻５０５（例えば最初のメディアフレームが再生されたとき，又は新メディアストリームの最初のメディアパケットがクライアントで受信されたとき）と，利用者が切替を起動した時刻５０４（例えば利用者が新規コンテンツを選択したとき，又は切替要求がクライアントからサーバへ送信されたとき）との差として取得される。この差は壁時計時間尺度５０２によって測定される。
【０１１４】
範囲値がContent_Switch_Time ＱｏＥメトリックに指定されているときは，コンテンツ切替が生じたとき報告される期間を示してもよい。この範囲は旧コンテンツに適用される。
【０１１５】
図４は，本発明の第１態様による方法の例示実施例のフローチャート４００である。フローチャート４００の各ステップは，例えばクライアント３のプロセッサ３０（図３参照）で実行されて，Content_Switch_Time ＱｏＥメトリックをサーバ２へ報告する。ここで，本フローチャート及びまた本明細書に記載されたすべてのほかのフローチャートの各ステップの順序は，それらステップが用いられる順序に固定されているとも，異なるとも理解しないものとする。
【０１１６】
最初のステップ４０１において，例えばRTSP DESCRIBE要求に応答してＳＤＰファイルが取得される。均等にＳＤＰファイルはＨＴＴＰを介して受信してもよいし，クライアント３が利用できる場所に記憶されていて，クライアント３が利用可能であってもよい。ＳＤＰファイルは，例えばクライアントに予め記憶されていてもよい。ＳＤＰファイルは，サーバ２が対応しているＱｏＥメトリック及び（例えば報告頻度のような）関連のＱｏＥメトリック値を含む。説明を単純にするため，サーバは頻度"Start"を有するContent_Switch_Time ＱｏＥメトリックだけに対応するものとする。
【０１１７】
ステップ４０２において，クライアント３は特定コンテンツを含むメディアストリームの設定を（RTSP SETUP要求によって）要求する。これらのRTSP SETUP要求には"3GPP-QoE-Metrics"ヘッダが含まれており，ＳＤＰファイルのすべてのＱｏＥメトリック及び関連するＱｏＥメトリック値（すなわち，頻度が"Start"であるContent_Switch_Time ＱｏＥメトリック）がクライアント３に受け入れられたことをサーバ２に通知するように構成されている。実際，ここでＱｏＥメトリック折衝は終了したものと見なしてよい。それでも，サーバ２はクライアント３に再肯定応答するために，RTSP SETUP要求に応答して受け入れたパラメータをそのまま返信（ｅｃｈｏ）してもよい。
【０１１８】
ステップ４０３でクライアント３は，RTSP PLAY要求によってコンテンツの再生を要求する。セッション設定時間を短縮するため，この要求もまたRTSP SETUP要求と共にパイプライン形式で，すなわちRTSP PLAY要求を送信する前にRTSP SETUP要求に対する応答を待たないで，送信してもよい。この場合，図７を参照して後で述べるように，本発明の第３態様が実際に実現される。
【０１１９】
図４に戻り，ステップ４０４でクライアント３はサーバ２からコンテンツを受信する。
【０１２０】
ステップ４０５でクライアント３はコンテンツを切り替えることを決定し，例えばRTSP "Switch-Stream" ヘッダを含む過積載RTSP PLAY要求をサーバ２へ発行してもよい。これによってコンテンツの切替が行われる。
【０１２１】
Content_Switch_Time ＱｏＥメトリックに関係する報告頻度が値"Start"（コンテンツ切替が発生した後，当該コンテンツ切替を即時報告することを意味する）に折衝されたので，ステップ４０６でクライアント３はコンテンツ切替に関係するコンテンツ切替時間を測定し，測定結果をContent_Switch_Time ＱｏＥメトリックに集約し，このＱｏＥメトリックを例えばRTSP SET_PARAMETER要求に含まれる"3GPP-QoE-feedback"ヘッダによってサーバ２へ送信する。
最後にステップ４０７で，クライアント３は新コンテンツを受信する。
【０１２２】
次に，本発明の第１態様によるContent_Switch_Time ＱｏＥメトリックの折衝に関する代替のより詳細な例を説明する。ここで，記法"S->C"は情報がサーバ（Ｓ）からクライアント（Ｃ）へ送信されることを示し，記法"C->S"は情報がクライアントからサーバへ送信されることを示す。Content_Switch_Time ＱｏＥメトリックに属する情報は太字体で示す。更に，折衝される関連メトリック値は下線を付している。
【０１２３】
初めに，クライアント３のRTSP DESCRIBE要求に応答して，サーバ２が応答メッセージによって次のＳＤＰファイルを提供する（この応答メッセージは，例えば図４のフローチャート４００のステップ４０１で受信される）。
【数２】
2010522450.tif 000004
【０１２４】
次の要求は，クライアント３が発行したRTSP SETUP要求及びRTSP PLAY要求と，それに対してサーバ２が発行した応答におけるContent_Switch_Time ＱｏＥメトリックの折衝を示す。この例は，クライアント３が"Start"から"End"に変更し，次にサーバ２が"End"から"Start"に変更した報告頻度の折衝を示す（このように，この折衝は図４のフローチャート４００のステップ４０２における折衝と異なっており，ＳＤＰファイル中のＱｏＥメトリック及び関係する頻度がクライアント３によって直接受け入れられる）。クライアント３は，最終的にRTSP PLAY要求によって頻度"Start"を受け入れる。
【数３】
2010522450.tif 000005
【数４】
2010522450.tif 000006
【数５】
2010522450.tif 000007
【数６】
2010522450.tif 000008
【数７】
2010522450.tif 000009
【０１２５】
次の要求は，Content_Switch_Time ＱｏＥメトリックの帰還の例である。ここでコンテンツ切替時間は２００ｍｓであり，このコンテンツ切替は旧コンテンツのＮＰＴタイムスタンプ２１０５．２で開始されたものである（この帰還は，例えば図４のフローチャート４００のステップ４０６で行われる）。
【数８】
2010522450.tif 000010
【０１２６】
本発明の第２態様は，ＱｏＥメトリック折衝プロトコルをコンテンツ切替に適応させることに関し，旧メディアストリームのコンテンツと，新メディアストリームのコンテンツとが同一メディア種別であるときは，クライアントは新コンテンツのPLAY要求の"Switch-Stream"ヘッダによって同一のＱｏＥメトリックを受け入れることを提案する。これらパラメータについて更なる折衝は必要ない。クライアント又はサーバは，必要なときはセッション中にメトリックを破棄してもよい。
【０１２７】
更に，本発明の第４態様もまたＱｏＥメトリック折衝プロトコルをコンテンツ切替に適応させることに関し，PLAY要求（例えばセッションの最初のPLAY要求）の後でＱｏＥメトリック折衝を可能にすることを提案する。例えば，旧コンテンツよりも多くのメディアストリームを有する新コンテンツについて，新メディアストリームのＱｏＥメトリックはセッション中に折衝してもよい（現在，第６版では許されていない）。クライアントは，対応するＱｏＥメトリックの選択を，新メディアのパイプラインSETUP要求，又は新コンテンツのパイプライン集約PLAY要求に含める（旧コンテンツよりも少ないメディアストリームを有する新コンテンツについては，更なるＱｏＥメトリック折衝は必要ない）。
【０１２８】
図６は，本発明の第２態様及び第４態様による方法の例示実施例のフローチャート６００である。このフローチャートの各ステップは，例えば図３のシステム１のクライアント３のプロセッサ３０によって実行される。このフローチャートでは，例としてコンテンツ切替時にメディアストリームの数は同一のままであるものとする。切替後にメディアストリームが追加される場合については，図８のフローチャート８００で扱う。
【０１２９】
最初のステップ６０１で，例えばRTSP DESCRIBE要求に応答してクライアント３がＳＤＰファイルを取得する。ＳＤＰファイルはまた，クライアント内に予め記憶しておいてもよい。
【０１３０】
ステップ６０２で，クライアント３はメディアストリームの設定を（RTSP SETUP要求によって）要求し，ＳＤＰファイル内のサーバ２が提案したすべてのＱｏＥメトリック及び関係するメトリック値を受け入れる。
【０１３１】
ステップ６０３で，クライアント３はRTSP PLAY要求によってコンテンツの再生を要求し，ステップ６０４でコンテンツが受信される。
【０１３２】
ステップ６０５で，コンテンツ切替が望まれているかどうか判定される。望まれていないときは，フローチャートはステップ６０４に戻る。そうでないときは，旧コンテンツ及び新コンテンツに共通のメディア種別（例えば映像，音響，音声，等のメディア種別）があるかどうかが検査される。
【０１３３】
この場合，本発明の第２態様をステップ６０７で適用してもよい。すなわち，新コンテンツのメディア種別と共通な旧コンテンツのメディア種別（例えば，映像，音響，音声，字幕，等）用に折衝されたすべてのＱｏＥメトリック（及び関係するメトリック値，すなわち報告頻度）が，例えばRTSP PLAY要求によって受け入れられる。
【０１３４】
新コンテンツが，旧コンテンツのメディア種別と異なる追加のメディア種別を含むときは，本発明の第４態様もまたステップ６０７で適用してもよい。すなわち，これらのメディア種別用ＱｏＥメトリック折衝が許可されるが，この折衝の少なくとも一部は，RTSP PLAY要求が発行された後で行われる。例えばクライアント３は，ＱｏＥメトリック（関係するＱｏＥメトリック値を含む）の選択を，新メディアに対するパイプラインRTSP SETUP要求，又は新コンテンツに対するパイプライン集約RTSP PLAY要求で搬送して折衝を開始してもよい。サーバ２がクライアントのＱｏＥメトリック選択に同意しないときでも，例えばRTSP SETUP要求又はRTSP PLAY要求への応答で異なるパラメータを提案して折衝を続けることが許可される。ここで，新コンテンツのＱｏＥメトリックの記述を含むＳＤＰファイルはDESCRIBE要求に応答してクライアント３へ送信してもよいし，クライアントに予め記憶しておいてもよいし，切替時に要求し（図６には示していない），RTSP又はほかの手段でクライアントへ送信してもよい。
【０１３５】
類似して，ステップ６０６で旧コンテンツと新コンテンツとに共通のメディア種別がないことが判定されたときも，本発明の第４態様をステップ６０８で適用してもよい。すなわち，新メディア種別用ＱｏＥメトリックの折衝が開始されるが，この折衝の少なくとも一部はRTSP PLAY要求が発行された後で行われる。クライアント３は，ＱｏＥメトリック（関係するＱｏＥメトリック値を含む）の選択を，新メディアに対するパイプラインRTSP SETUP要求，又は新コンテンツに対するパイプライン集約RTSP PLAY要求で搬送して折衝を開始してもよい。既に述べたように，この場合においても新コンテンツ用ＱｏＥメトリックの記述を含むＳＤＰファイルは，DESCRIBE要求に応答してクライアント３へ送信してもよいし，クライアントに予め記憶しておいてもよいし，切替時に要求し（図６には示していない），RTSP又はほかの手段でクライアントへ送信してもよい。
【０１３６】
ステップ６０９で新コンテンツが受信され，折衝されたＱｏＥメトリックが測定され，報告される。
【０１３７】
本発明の第３態様は，ＱｏＥメトリック折衝を高速セッション設定に適応させることに注力されており，高速セッション開始のため，PLAY要求の前にＱｏＥメトリック折衝を追加しないことを提案している。パイプラインSETUP/PLAY要求のうち一つで，クライアントはＳＤＰファイルによって受信した対応するＱｏＥメトリックの選択を搬送する。
【０１３８】
図７は，本発明の第３態様による方法の例示実施例のフローチャート７００である。このフローチャートの各ステップは，例えば図３のシステム１のクライアント３のプロセッサ３０によって実行される。
【０１３９】
最初のステップ７０１で，例えばRTSP DESCRIBE要求に応答してクライアント３がＳＤＰファイルを取得する。ＳＤＰファイルはまた，例えばクライアント内に予め記憶されていてもよいし，ほかの手段でクライアントに送信してもよい。
【０１４０】
ステップ７０２でクライアント３は二つのパイプライン要求を発行する。すなわち二つの要求を連続して発行する。第２要求は既に送信された第１要求の応答を待たずに送信され，第３要求は送信された第２要求の応答を待たずに送信される。以降同様に続く。
【０１４１】
これらのパイプライン要求は，ストリームセッションでストリームされるコンテンツのメディアストリーム設定用のRTSP SETUP要求と，コンテンツに集約されたすべてのメディアストリームの再生を起動する集約RTSP PLAY要求と，を含む。対応するＱｏＥメトリックについてのクライアントの選択は，RTSP SETUP要求又はRTSP PLAY要求のいずれかの"3GPP-QoE-metrics"ヘッダに含まれる。
【０１４２】
サーバは，応答メッセージでクライアントの選択を受け入れて折衝を終了してもよいし，クライアントの選択と異なる提案を行ってもよい。後者の場合（図７のフローチャートには描かれていない），本発明の第４態様による提案，すなわち折衝の少なくとも一部が再生が要求された後で行われるという提案を適用するのが有利である。これは，そうしないと折衝が完了しないことがあるからである。
【０１４３】
本発明の第３態様によれば，折衝はRTSP PLAY要求の前には開始されないので，ＱｏＥメトリック折衝によって追加の往復時間が生じることが避けられ，高速セッション設定が確実になる。
【０１４４】
フローチャート７００の最後のステップ７０３でコンテンツが受信され，折衝されたとおりＱｏＥメトリックが測定され，報告される。
【０１４５】
既に述べたとおり，本発明の第４態様もまたＱｏＥメトリック折衝プロトコルをコンテンツ切替に適応させることに関し，PLAY要求（例えばセッションの最初のPLAY要求）の後でＱｏＥメトリック折衝を可能にすることを提案する。例えば，旧コンテンツよりも多くのメディアストリームを有する新コンテンツについて，新メディアストリームのＱｏＥメトリックをセッション中に折衝してもよい（現在，第６版では許されていない）。クライアントは，対応するＱｏＥメトリックの選択を，新メディアのパイプラインSETUP要求，又はコンテンツのパイプライン集約PLAY要求に含める（旧コンテンツよりも少ないメディアストリームを有する新コンテンツについては，更なるＱｏＥメトリック折衝は必要ない）。
【０１４６】
図８は，本発明の第４態様による方法の例示実施例のフローチャート８００である。このフローチャートの各ステップは，例えば図３のシステム１のクライアント３のプロセッサ３０によって実行される。
【０１４７】
最初のステップ８０１で，例えばRTSP DESCRIBE要求に応答してクライアント３がＳＤＰファイルを取得する。ＳＤＰファイルはまた，例えばクライアント内に予め記憶されていてもよいし，ほかの手段でクライアントに送信してもよい。
【０１４８】
ステップ８０２で，クライアント３はメディアストリームの設定を（RTSP SETUP要求によって）要求し，ＳＤＰファイル内のサーバ２が提案したすべてのＱｏＥメトリック及び関係するメトリック値を受け入れる。
【０１４９】
ステップ８０３で，クライアント３はRTSP PLAY要求によってコンテンツの再生を要求し，ステップ８０４でコンテンツが受信される。ステップ８０２のRTSP PLAY要求が，このストリームセッションにおける最初のRTSP PLAY要求である。
【０１５０】
ステップ８０５でクライアント３はコンテンツ切替を要求する。ここで，例として新コンテンツは旧コンテンツより多いメディアストリームを含むものとする。すなわち，コンテンツ切替時に１又は複数のメディアストリームが追加される。維持されるメディアストリーム用の既に折衝されたＱｏＥメトリックは本発明の第２態様によって受け入れられるが，これらのメディアストリームのメディア種別が変わらないときは，追加メディアストリーム用ＱｏＥメトリックの折衝が必要である。したがって，折衝を初期RTSP要求８０３の後で行えるようにすると有利である。
【０１５１】
例えば，クライアント３は折衝を開始するために，対応するＱｏＥメトリックの選択を，新メディアのパイプラインSETUP要求，又は新コンテンツのパイプライン集約PLAY要求に含めてもよい。そしてサーバ２は，要求に応答して提案されたＱｏＥメトリック及びＱｏＥメトリック値を受け入れてもよいし，異なる提案を行ってもよい。次にクライアント３は提案を受け入れてもよいし，更に異なる提案を行ってもよい。
【０１５２】
新コンテンツのＱｏＥメトリックの記述を含むＳＤＰファイルはDESCRIBE要求に応答してクライアント３へ送信してもよいし，クライアントに予め記憶しておいてもよいし，切替時に要求し（図８には示していない），RTSP又はほかの手段でクライアントへ送信してもよい。
【０１５３】
ステップ８０６で新コンテンツが受信され，ステップ８０７でＱｏＥメトリックが測定され，報告される。
【０１５４】
本発明の第５態様は，ＱｏＥメトリック折衝プロトコルをコンテンツ切替に適応させることに関し，既に折衝されたＱｏＥメトリックを新コンテンツが継承することを提案している。明示的に修正され又は停止されない限り，品質報告は旧メディアストリームすなわちコンテンツと同一の頻度で継続される。しかし，コンテンツ切替が実行された後に報告事象が起きたときは，旧ＵＲＬの代わりに新ＵＲＬを用いる。
【０１５５】
図９は，本発明の第５態様による方法の例示実施例のフローチャート９００である。このフローチャートの各ステップは，例えば図３のシステム１のクライアント３のプロセッサ３０によって実行される。
【０１５６】
最初のステップ９０１で，例えばRTSP DESCRIBE要求に応答してクライアント３がＳＤＰファイルを取得する。ＳＤＰファイルはまた，例えばクライアント内に予め記憶されていてもよいし，ほかの手段でクライアントに送信してもよい。
【０１５７】
ステップ９０２で，クライアント３はメディアストリームの設定を（RTSP SETUP要求によって）要求し，ＳＤＰファイル内のサーバ２が提案したすべてのＱｏＥメトリック及び関係するメトリック値を受け入れる。
【０１５８】
ステップ９０３で，クライアント３はRTSP PLAY要求によってコンテンツの再生を要求し，ステップ９０４でコンテンツが受信される。
【０１５９】
ステップ９０５でクライアント３はコンテンツ切替を要求し，旧コンテンツから既に折衝されたＱｏＥメトリックを継承する。継承とは，旧コンテンツ用に既に折衝されたメトリックを，切替が発生した後で新コンテンツに適応させるために再折衝する必要がなく，それらが切替直後に後者のコンテンツに適用されることを意味する。
【０１６０】
既に折衝されたメトリックを継承することに加えて，（例えば旧コンテンツのメディアストリームと異なる新コンテンツのメディアストリーム用に）更なるメトリックを折衝してもよい。この折衝は，クライアントが発行したPLAY要求の後で行うことができ（すなわち，本発明の第４態様による），例えばＱｏＥメトリック（及び関係するＱｏＥメトリック値）の提案を，パイプラインRTSP SETUP要求，又はパイプライン集約RTSP PLAY要求によって開始してもよい。
【０１６１】
新コンテンツのＱｏＥメトリックの記述を含むＳＤＰファイルはDESCRIBE要求に応答してクライアント３へ送信してもよいし，クライアントに予め記憶しておいてもよいし，切替時に要求し（図９には示していない），RTSP又はほかの手段でクライアントへ送信してもよい。
【０１６２】
ステップ９０６で新コンテンツが受信され，ステップ９０７で継承されたＱｏＥメトリックが測定され，報告される。ここで，報告は旧メディアストリームすなわちコンテンツと同一の頻度で継続される。しかし，コンテンツ切替が実行された後に報告事象が起きたときは，旧ＵＲＬの代わりに新ＵＲＬを用いる。
【０１６３】
以降，本発明によるＱｏＥメトリック折衝の更なる例を，特に本発明の第１，第３及び第４態様に関して説明する。ＱｏＥメトリックの制御追跡ＩＤ（trackID）及び関係する「頻度」の追跡を容易にするため，これらのパラメータには下線を付している。更にすべての"3GPP-QoE-Metrics"ヘッダは太字体で示している。
【０１６４】
以降の例では，ＳＤＰファイル内の，サーバが対応するＱｏＥパラメータのすべて，中でも本発明の第１態様によるContent_Switch_Timeメトリックを報告することにクライアントは同意する。
【０１６５】
しかしクライアントは，ＳＤＰファイル内でサーバが要求した「頻度」で上記パラメータを報告することができない。したがってクライアントは，ＱｏＥパラメータのうちいくつかに関係する「頻度」特性にいくつかの変更を提案する（trackID=3で頻度を１０から１５に変更し，trackID=5で２０から４０に変更する）。本発明の第３態様によれば，クライアントはこれらの変更をパイプラインRTSP PLAY要求で標示する。更に本発明の第４態様によれば，サーバはクライアントの提案を受け入れるときであっても，クライアントに肯定応答するためにRTSP PLAY要求に応答してクライアントの提案をそのまま返信する必要があるので，ＱｏＥメトリック折衝の少なくとも一部は，RTSP PLAY要求が発行された後で行うことになる。
【数９】
2010522450.tif 000011
【数１０】
2010522450.tif 000012
【数１１】
2010522450.tif 000013
【数１２】
2010522450.tif 000014
【０１６６】
サーバは，これらの報告頻度変更を受け入れる。したがって，サーバは受け入れたことを，RTSP PLAY要求に応答して"3GPP-QoE-Metrics"ヘッダの内容をそのまま返信することによって確認する。既に述べたとおり，ＱｏＥメトリック折衝の少なくとも一部（すなわちサーバ側がパラメータを受け入れることに関して）はRTSP PLAY要求の後で行われるので，このようにして本発明の第４態様がここに適用される。
【数１３】
2010522450.tif 000015
【数１４】
2010522450.tif 000016
【数１５】
2010522450.tif 000017
【０１６７】
あるいは，サーバがクライアントの提案した変更に同意しないときは，RTSP PLAY応答以降も折衝を続ける（これもまた本発明の第４態様による）。
【０１６８】
RTSP PLAY応答中のＱｏＥパラメータがRTSP PLAY要求によってクライアントが提案したものと同一のときは，クライアントは折衝を停止する。
【０１６９】
同一でないときは，RTSP OPTIONS要求又はRTSP SET_PARAMETER要求を用いてクライアントとサーバとが合意に至るまで折衝を続ける。
【０１７０】
次の例は上記の例（これもまた本発明の第４態様による）の続きであり，サーバはクライアントの提案のうち，ＱｏＥメトリック"Decoded_Bytes"の「頻度」を除くすべてのメトリック及び関係する値に合意する。サーバは，Decoded_Bytesを頻度５で送信することを提案する。しかし，クライアントはそれらをそれほど頻繁に送信することができないので，次の折衝で対応する最大頻度（頻度１０）を送信する。既に合意されたＱｏＥメトリックは折衝から除外される。クライアントは残りのＱｏＥメトリックについて新規の値をRTSP OPTIONS要求を用いて再提案する。サーバは最終的にこの値に合意する。
【数１６】
2010522450.tif 000018
【数１７】
2010522450.tif 000019
【数１８】
2010522450.tif 000020
【０１７１】
本発明の上述の詳細な説明においては，本発明の例示実施例を第３世代パートナシッププロジェクト（３ＧＰＰ）のパケット交換ストリームサービス（ＰＳＳ）システムに関して説明した。
【０１７２】
本発明は，３ＧＰＰ ＰＳＳシステムに限らず，品質報告が適用できるすべてのほかの種類の伝送システムにも展開できることを理解されたい。上記の伝送システム，例えば会話型システム（例えばテレビ電話）では，２以上のクライアント間で通信網を介して情報が交換され，メトリックは例えばセッション開始プロトコル（ＳＩＰ）のプロキシのような通信網要素によって取得される。
【０１７３】
本発明の更なる例示展開シナリオはマルチメディア同報／多対地通信サービス（ＭＢＭＳ）であり，ここでも切替時間メトリックを用い，拡張可能マーク付け言語，ハイパテキスト転送プロトコル（ＨＴＴＰ），又はほかの手段を用いてサーバに搬送することができる。コンテンツ切替時間メトリックはまた，ＭＢＭＳと単一通信（ｕｎｉｃａｓｔ）ＰＳＳとの切替，又はその逆も意味する。コンテンツが同一のときは，コンテンツ切替時間は，ある通信網から別の通信網への切替時間であってよい。コンテンツが異なるときは，コンテンツ切替時間はある通信網から別の通信網への切替時間に，本発明の第１態様によって既に規定したコンテンツ切替時間を加えたものであってよい。
【０１７４】
また，ＱｏＥメトリックを必ずしもＲＴＳＰ及びＳＤＰによって搬送しなくてもよいことは容易に理解できる。均等に，例えばＳＩＰ，ＸＭＬ，ＨＴＴＰ，ショートメッセージサービス（ＳＭＳ），又はその他いくつか，のほかのプロトコルを用いてＱｏＥメトリックを搬送してもよい。
【０１７５】
本発明を例示実施例によって説明した。当業者には明白な代替方法及び修正物があり，本願請求項の範囲及び精神から逸脱することなく実現できることに注意されたい。
【０１７６】
更に，上記の説明において提示した簡単なブロック図に示した各論理ブロック及びフローチャート及びアルゴリズムの各ステップは，少なくとも部分的に電子ハードウェア及び／又は計算機ソフトウェアによって実現でき，それらは上記の論理ブロックと，フローチャートのステップと，アルゴリズムのステップとの機能，及び上記の論理ブロックと，フローチャートのステップと，アルゴリズムのステップとがハードウェア又はソフトウェアで実現された程度に，それぞれのデバイスに課された設計上の制約に依存する。提示した論理ブロックと，フローチャートのステップと，アルゴリズムのステップとは，例えば１又は複数のデジタル信号プロセッサ，特定応用集積回路，フィールドプログラム可能ゲートアレイ，又はほかのプログラム可能デバイスによって実現してもよい。計算機ソフトウェアは，電気，磁気，電磁気，又は光の種々の記憶媒体に記憶してもよく，例えばマイクロプロセッサのようなプロセッサによって読み出され，処理してもよい。このため，プロセッサと記憶媒体とを情報を交換するために接続してもよいし，プロセッサ内に記憶媒体を含めてもよい。
【０１７７】
最後に，本発明の各実施例は，それらのすべての可能な組合せによっても開示されたものとする。
【図１】
2010522450.tif 000021
【図２】
2010522450.tif 000022
【図３】
2010522450.tif 000023
【図４】
2010522450.tif 000024
【図５】
2010522450.tif 000025
【図６】
2010522450.tif 000026
【図７】
2010522450.tif 000027
【図８】
2010522450.tif 000028
【図９】
2010522450.tif 000029
【手続補正書】
【提出日】平成21年6月17日(2009.6.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアント側の方法であって，クライアントの処理ユニットによってサーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項２】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアフレームが再生された時点までの時間と，クライアントからサーバへ切替要求が送信された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間と，のうち一つとして規定される請求項１に記載の方法。
【請求項３】
前記コンテンツ切替時間メトリックは，即時報告するように折衝できる請求項１に記載の方法。
【請求項４】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１に記載の方法。
【請求項５】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間として規定される請求項１に記載の方法。
【請求項６】
前記コンテンツ切替時間メトリックは，前記切替が開始された時刻を示すタイムスタンプと共に報告される請求項１に記載の方法。
【請求項７】
前記タイムスタンプは，旧コンテンツの時間軸による通常再生時刻ＮＰＴで表される請求項６に記載の方法。
【請求項８】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項１に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項９】
クライアント側の装置であって，サーバに報告する送信セッションの品質を１又は複数のメトリックによって測定するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む装置。
【請求項１０】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項９に記載の装置。
【請求項１１】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアフレームが再生された時点までの時間と，クライアントからサーバへ切替要求が送信された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間と，のうち一つとして規定される請求項９に記載の装置。
【請求項１２】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間として規定される請求項９に記載の装置。
【請求項１３】
前記コンテンツ切替時間メトリックは，即時報告するように折衝できる請求項９に記載の装置。
【請求項１４】
前記コンテンツ切替時間メトリックは，前記切替が開始された時刻を示すタイムスタンプと共に報告される請求項９に記載の装置。
【請求項１５】
前記タイムスタンプは，旧コンテンツの時間軸による通常再生時刻ＮＰＴで表される請求項１４に記載の装置。
【請求項１６】
サーバ側の方法であって，クライアントの処理ユニットが送信セッションの品質を測定する１又は複数のメトリックであって，前記クライアントから受信した１又は複数のメトリックをサーバにおいて処理するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項１７】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１６に記載の方法。
【請求項１８】
計算機プログラムを記憶させた計算機可読媒体であって，該計算機プログラムは請求項１６に記載の方法をプロセッサに実行させる命令を含む計算機可読媒体。
【請求項１９】
サーバ側の装置であって，クライアントの処理ユニットが送信セッションの品質を測定する１又は複数のメトリックであって，前記クライアントから受信した１又は複数のメトリックをサーバにおいて処理するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む装置。
【請求項２０】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１９に記載の装置。
【請求項２１】
請求項９に記載のクライアント側装置と，請求項１９に記載のサーバ側装置とを備えるシステム。
【手続補正書】
【提出日】平成21年10月15日(2009.10.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアントの処理ユニットによって送信セッションの品質を１又は複数のメトリックによって測定するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項２】
前記コンテンツ切替時間メトリックは，前記クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアフレームが再生された時点までの時間と，前記クライアントからサーバへ切替要求が送信された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間と，のうち一つとする請求項１に記載の方法。
【請求項３】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１に記載の方法。
【請求項４】
前記コンテンツ切替時間メトリックは，前記クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間として規定される請求項１に記載の方法。
【請求項５】
前記コンテンツ切替時間メトリックは，前記切替が開始された時刻を示すタイムスタンプと共に報告される請求項１に記載の方法。
【請求項６】
計算機プログラムを記憶させた計算機可読記憶媒体であって，該計算機プログラムは請求項１〜５のいずれか一項に記載の方法をプロセッサに実行させる命令を含む計算機可読記憶媒体。
【請求項７】
送信セッションの品質を１又は複数のメトリックによって測定するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む装置。
【請求項８】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項７に記載の装置。
【請求項９】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアフレームが再生された時点までの時間と，クライアントからサーバへ切替要求が送信された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間と，のうち一つとして規定される請求項７に記載の装置。
【請求項１０】
前記コンテンツ切替時間メトリックは，クライアント上で新コンテンツが選択された時点から，前記新コンテンツの最初のメディアパケットが前記クライアントで受信された時点までの時間として規定される請求項７に記載の装置。
【請求項１１】
前記コンテンツ切替時間メトリックは，前記切替が開始された時刻を示すタイムスタンプと共に報告される請求項７に記載の装置。
【請求項１２】
クライアントの処理ユニットが送信セッションの品質を測定する１又は複数のメトリックであって，前記クライアントから受信した１又は複数のメトリックをサーバにおいて処理するステップを有し，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む方法。
【請求項１３】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１２に記載の方法。
【請求項１４】
計算機プログラムを記憶させた計算機可読記憶媒体であって，該計算機プログラムは請求項１２又は１３に記載の方法をプロセッサに実行させる命令を含む計算機可読記憶媒体。
【請求項１５】
クライアントの処理ユニットが送信セッションの品質を測定する１又は複数のメトリックであって，前記クライアントから受信した１又は複数のメトリックをサーバにおいて処理するように構成した処理ユニットを備え，前記１又は複数のメトリックは，前記送信セッションにおけるコンテンツ間の切替に要する時間に関係するコンテンツ切替時間メトリックを含む装置。
【請求項１６】
前記コンテンツ切替時間メトリックは，第３世代パートナシッププロジェクトのパケット交換ストリームサービスの体感品質メトリックとする請求項１５に記載の装置。
【国際調査報告】
2010522450.tif 000030
2010522450.tif 000031
2010522450.tif 000032
2010522450.tif 000033
2010522450.tif 000034