(57)【要約】  リッチメディアサービスにおいてデータ送信のための品質フィードバックメトリクスを提供するための改善されたシステム及び方法を提供する。クライアントへのリッチメディアコンテンツの送信に関する品質測定に対して拡張機能を設ける。このような測定は、ＰＳＳ基本語彙、ＰＳＳ体感品質、及びＲＴＰ／ＡＶＰＦにおける新しい拡張機能として定義される。リッチメディアクライアントが上記のような測定を利用することで、サーバは、送信品質を評価すると共にパケット再送信などのエラー回復メカニズムを考慮に入れて、失われた情報をクライアントに提供することができる。【選択図】図１
2010510689.tif 000002
【特許請求の範囲】
【請求項１】
リッチメディアサービスにおいてデータ送信のための品質フィードバックメトリクスを提供する方法であって、
リッチメディアコンテンツを遠隔装置から受信するステップと、
前記リッチメディアコンテンツの前記受信に応答して、サービス品質情報を前記遠隔装置へ送信するステップと、
を含み、
前記サービス品質情報は、前記受信されたリッチメディアコンテンツの品質特性について記述する少なくとも１つのサービス品質メトリクスの拡張機能を含む、
ことを特徴とする方法。
【請求項２】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、パケット交換ストリーミングサービスの語彙における少なくとも１つの拡張機能を含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記パケット交換ストリーミングサービスの語彙における前記少なくとも１つの拡張機能は、提供されたフィードバックの機能及びモードについて記述する「ＦｅｅｄｂａｃｋＭｅｔｈｏｄ」コンポーネントを含む、
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、パケット交換ストリーミングサービスの体感品質メトリクスに関する少なくとも１つの拡張機能を含む、
ことを特徴とする請求項１に記載の方法。
【請求項５】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数を報告するためのシンタックスを含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
パケット交換ストリーミングサービスの体感品質メトリクスについての前記少なくとも１つの拡張機能は、直近のアクティブな要素リストの中で正しく受信及び復号化されなかった要素のリストを報告するためのシンタックスを含む、
ことを特徴とする請求項４に記載の方法。
【請求項７】
パケット交換ストリーミングサービスの体感品質メトリクスについての前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの現在のグループ内で、どの要素が正しく受信、復号化され、かつアクティブであるかを報告するためのシンタックスを含む、
ことを特徴とする請求項４に記載の方法。
【請求項８】
パケット交換ストリーミングサービスの体感品質メトリクスについての前記少なくとも１つの拡張機能は、破損シーンの更新を数えることにより測定されるＣｏｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎを報告するためのシンタックスを含む、
ことを特徴とする請求項４に記載の方法。
【請求項９】
パケット交換ストリーミングサービスの体感品質メトリクスについての前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツのシーンにおけるグループ間の境界を推定するためのシンタックスを含む、
ことを特徴とする請求項４に記載の方法。
【請求項１０】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、ＲＴＣＰベースのフィードバックのための拡張された実時間転送プロトコルプロファイルにおける少なくとも１つの拡張機能を含む、
ことを特徴とする請求項１に記載の方法。
【請求項１１】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中のパケット損失の指示を含む、
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、前記直近のアクティブな要素リストの中で正しく受信及び復号化されなかった要素の個数の指示を含む、
ことを特徴とする請求項１０に記載の方法。
【請求項１３】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたデータの現在のグループ内で正しく受信、復号化され、かつアクティブである要素の指示を含む、
ことを特徴とする請求項１０に記載の方法。
【請求項１４】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたデータの１つのグループにわたる破損継続時間の指示を含む、
ことを特徴とする請求項１０に記載の方法。
【請求項１５】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたシーンデータの前記パケット損失に起因して破損したグループの指示を含む、
ことを特徴とする請求項１０に記載の方法。
【請求項１６】
前記リッチメディアコンテンツは、動的かつインタラクティブなメディアシーン（ＤＩＭＳ）専用のコンテンツを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１７】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中に損失した実時間転送プロトコル（ＲＴＰ）パケットの個数について記述する、
ことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーンについて記述する、
ことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーンの更新について記述する、
ことを特徴とする請求項１６に記載の方法。
【請求項２０】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーン及び破損したＤＩＭＳシーンの更新の両方について記述する、
ことを特徴とする請求項１６に記載の方法。
【請求項２１】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーン及びシーンの更新の継続時間について記述する、
ことを特徴とする請求項１６に記載の方法。
【請求項２２】
コンピュータ可読媒体に内蔵され、リッチメディアサービスにおいてデータ送信のための品質フィードバックメトリクスを提供するためのコンピュータプログラム製品であって、
リッチメディアコンテンツを遠隔装置から受信するためのコンピュータコードと、
前記リッチメディアコンテンツの前記受信に応答して、サービス品質情報を前記遠隔装置へ送信するためのコンピュータコードと、
を含み、
前記サービス品質情報は、前記受信されたリッチメディアコンテンツの品質特性について記述する少なくとも１つのサービス品質メトリクスの拡張機能を含む、
ことを特徴とするコンピュータプログラム製品。
【請求項２３】
プロセッサと、
前記プロセッサに通信可能に接続されたメモリと、
を含み、前記メモリは、
リッチメディアコンテンツを遠隔装置から受信するためのコンピュータコードと、
前記リッチメディアコンテンツの前記受信に応じて、サービス品質情報を前記遠隔装置へ送信するためのコンピュータコードと、
を含み、
前記サービス品質情報は、前記受信されたリッチメディアコンテンツの品質特性について記述する少なくとも１つのサービス品質メトリクスの拡張機能を含む、
ことを特徴とする電子装置。
【請求項２４】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、パケット交換ストリーミングサービス語彙における少なくとも１つの拡張機能を含む、
ことを特徴とする請求項２３に記載の電子装置。
【請求項２５】
前記パケット交換ストリーミングサービス語彙における前記少なくとも１つの拡張機能は、提供されたフィードバックの機能及びモードについて記述する「ＦｅｅｄｂａｃｋＭｅｔｈｏｄ」コンポーネントを含む、
ことを特徴とする請求項２４に記載の電子装置。
【請求項２６】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、パケット交換ストリーミングサービスの体感品質メトリクスに関する少なくとも１つの拡張機能を含む、
ことを特徴とする請求項２３に記載の電子装置。
【請求項２７】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数を報告するためのシンタックスを含む、
ことを特徴とする請求項２６に記載の電子装置。
【請求項２８】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、直近のアクティブな要素リストの中で正しく受信及び復号化されなかった要素のリストを報告するためのシンタックスを含む、
ことを特徴とする請求項２６に記載の電子装置。
【請求項２９】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの現在のグループ内で、どの要素が正しく受信、復号化され、かつアクティブであるかを報告するためのシンタックスを含む、
ことを特徴とする請求項２６に記載の電子装置。
【請求項３０】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、破損シーンの更新を数えることにより測定されるＣｏｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎを報告するためのシンタックスを含む、
ことを特徴とする請求項２６に記載の電子装置。
【請求項３１】
パケット交換ストリーミングサービスの体感品質メトリクスに関する前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツのシーンにおけるグループ間の境界を推定するためのシンタックスを含む、
ことを特徴とする請求項２６に記載の電子装置。
【請求項３２】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、ＲＴＣＰベースのフィードバックのための拡張された実時間転送プロトコルプロファイルにおける少なくとも１つの拡張機能を含む、
ことを特徴とする請求項２３に記載の電子装置。
【請求項３３】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中のパケット損失の指示を含む、
ことを特徴とする請求項３２に記載の電子装置。
【請求項３４】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、前記直近のアクティブな要素リストの中で正しく受信及び復号化されなかった要素の個数の指示を含む、
ことを特徴とする請求項３２に記載の電子装置。
【請求項３５】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたデータの現在のグループ内で正しく受信、復号化され、かつアクティブである要素の指示を含む、
ことを特徴とする請求項３２に記載の電子装置。
【請求項３６】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたデータの１つのグループにわたる破損継続時間の指示を含む、
ことを特徴とする請求項３２に記載の電子装置。
【請求項３７】
ＲＴＣＰベースのフィードバックのための前記拡張された実時間転送プロトコルプロファイルにおける前記少なくとも１つの拡張機能は、受信されたシーンデータの前記パケット損失に起因して破損したグループの指示を含む、
ことを特徴とする請求項３２に記載の電子装置。
【請求項３８】
前記リッチメディアコンテンツは、動的かつインタラクティブなメディアシーン（ＤＩＭＳ）専用のコンテンツを含む、
ことを特徴とする請求項２３に記載の電子装置。
【請求項３９】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記受信されたリッチメディアコンテンツの個々の優先度に対する一定期間中に損失した実時間転送プロトコル（ＲＴＰ）パケットの個数について記述する、
ことを特徴とする請求項３８に記載の電子装置。
【請求項４０】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーンについて記述する、
ことを特徴とする請求項３８に記載の電子装置。
【請求項４１】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーンの更新について記述する、
ことを特徴とする請求項３８に記載の電子装置。
【請求項４２】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーン及び破損したＤＩＭＳシーンの更新の両方について記述する、
ことを特徴とする請求項３８に記載の電子装置。
【請求項４３】
前記少なくとも１つのサービス品質メトリクスの拡張機能は、前記遠隔装置から受信した、破損したＤＩＭＳシーン及びシーンの更新の継続時間について記述する、
ことを特徴とする請求項３８に記載の電子装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にリッチメディアコンテンツの送信に関する。より具体的には、本発明は、リッチメディア・アプリケーションにおいてデータ送信中に品質メトリクスを提供することに関する。
【背景技術】
【０００２】
本節は、特許請求の範囲に記載の本発明に至るまでの背景又は前後関係を提供することを意図するものである。本明細書における説明は、追求可能ではあるものの、必ずしも構想又は追求されたことのない概念を含むことができる。従って、本節で説明する内容は、本明細書において示さない限り、本出願における説明及び特許請求の範囲にとって従来技術ではなく、本節内に包含されることにより従来技術であると認められるものではない。
【０００３】
リッチメディアコンテンツとは、単一のインターフェースを通じて配信されるグラフィックス、テキスト、ビデオ、及びオーディオを含む、画像が豊富でありかつ複合的な又は複数の媒体を含む、動的でインタラクティブなコンテンツのことである。スケーラブルビデオグラフィックス（ＳＶＧ）は、リッチメディアを表示するための主コンテナである。最近まで、移動通信装置向けのアプリケーションは、インタラクティビティが限定されたテキストベースのものであった。しかしながら、より多くの無線装置がカラーディスプレイ及びより高度なグラフィックスレンダリングライブラリを備えるようになってきたため、消費者は、自身の無線アプリケーションからより豊富な体験を得たいと求めている。特にマルチメディアブロードキャストおよびマルチキャストサービス（ＭＢＭＳ）、パケット交換ストリーミングサービス（ＰＳＳ）、及びマルチメディアメッセージングシステム（ＭＭＳ）サービスの分野において、リアルタイムなリッチメディアコンテンツのストリーミングサービスは移動端末にとって不可欠である。
【０００４】
ＳＶＧは、解像度に依存しない２次元ベクトルグラフィックスを記述するように設計されており、多くの場合、ラスターグラフィックス、オーディオ、及びビデオなどのその他の媒体を組み込んでいる。ＳＶＧは、同期マルチメディア統合言語（ＳＭＩＬ）を模倣したイベントモデル及びアニメーション概念を用いてインタラクティビティを可能にしている。ＳＶＧはまた、無限のズーム性能をも可能にし、移動通信装置におけるユーザインターフェースの能力を高めている。結果として、ＳＶＧは重要性を高めており、特に移動ＴＶ、交通情報のライブ更新、天気、ニュースのようなリッチメディアサービス向けのマルチメディア表示の中核要素の１つとなってきている。ＳＶＧはＸＭＬベースであるため、その他の既存のウェブ技術とのより透過的な統合を可能にする。移動スケーラブルベクトルグラフィックス（移動ＳＶＧ）は、移動通信装置にグラフィックス及び画像の改善をもたらす上で極めて重要な役割を果たす目的で、第３世代共同プロジェクト（３ＧＰＰ）により新たな画像基準として採用されてきたものである。最近、３ＧＰＰ及びオープンモバイルアライアンス（ＯＭＡ）が、リッチメディアベースの活動に取り組み始めたところである。
【０００５】
リッチメディア・アプリケーションでは、シーン及びシーンの更新という概念が用いられている。「シーン」とは、シーン要素の空間的構成、シーン要素の時間的構成、同期情報、及びＳＶＧ要素間の相互作用について記述するものである。シーンは、通常最初にクライアントへ送信されて、表示レイアウトが初期化される。シーンは、＜ｓｖｇ＞＜／ｓｖｇ＞タグ内に在る自己完結型のＳＶＧ文書であり、このタグ内では、＜ｇ＞要素を用いてアニメーションと要素とをグループ化することができる。またシーンは、＜ｄｅｆｓ＞＜／ｄｅｆｓ＞ブロックで囲まれたｄｅｆｉｎｉｔｉｏｎ要素を含むこともでき、現在のシーンにおいて、或いは後続のシーンの更新における要素によってこのブロックを用いることができる。シーンの更新は、クライアント装置へ１度に１個づつ送信される、ＳＶＧ文書オブジェクトモデル（ＤＯＭ）に対する増分更新である。これらの更新には、ＳＶＧ要素の追加、要素の削除、要素の置換、及び要素属性の更新処理が含まれる。
【０００６】
パケット損失、送信品質、及び媒体修復情報に関する、オーディオ及びビデオなどの媒体のための品質メトリクスは幾つか存在するが、リッチメディア・アプリケーションにおけるＳＶＧベースのシーン及びシーンの更新のための品質メトリクスは現在のところ存在しない。多くの場合、リッチメディア・アプリケーションの実行中に、クライアントは、送信及び表示の品質をサーバに報告することができる。このような情報は、サーバが転送システムの調整に関して最適な決定を行うために非常に有用なものである。現在、この問題に取り組むために、マルチメディアアプリケーションではＰＳＳ及びＭＢＭＳなどの上位層フレームワークが広く用いられてきている。この目的のために必要なフィードバックデータを表すシンタックスを定義し、次にこれらのシンタックスを実時間転送プロトコル（ＲＴＣＰ）などの下位層プロトコルにマッピングすることが解決策に含まれる。しかしながら、これらの解決策は、主に音声、ビデオ、及び時間調節テキスト等の連続データに焦点を合わせたものであり、特にＳＶＧ、個別媒体及び連続媒体を含むリッチメディア・アプリケーションに迎合するものではない。リッチメディア・アプリケーションのインストールに対する需要は常に増加しているので、現在のフレームワークに対する拡張機能を定義し、クライアントが品質関連のフィードバックデータをサーバへ返送できるようにすることが重要である。
【０００７】
上述のように、現在のところ、ローカルな（すなわち、完全にクライアント側の）インタラクティビティ、及びＳＶＧのようなリッチメディア表示の形のＨＴＴＰ  ＧＥＴ／ＰＯＳＴなどの初歩的なリモートインタラクションのための、単に予備的で部分的な解決策が多数存在している。リアルタイム転送プロトコル（ＲＴＰ）を用いたリアルタイムメディアストリームは、パケット損失に対してある程度まで回復を行う。ＲＴＰ制御プロトコル（ＲＴＣＰ）を用いてサービス品質をモニタし、進行中のＲＴＰセッションにおける参加者に関する情報を伝達することができる。このＲＴＰ制御プロトコルは、データパケットと同じ配信メカニズムを用いた、セッション内の全ての参加者への制御パケットの定期的な送信に基づくものである。ＲＴＰ制御プロトコルは４つの機能を実行する。第１に、主機能として、データ配信の品質に関するフィードバックを提供することである。第２の機能は、ＲＴＰソースに対して、カノニカルネーム又はＣＮＡＭＥと呼ばれる継続的な転送レベルの識別子を搬送することである。第３の機能は、大勢の参加者に合わせてＲＴＰの規模を拡大するように、送信パケットのレートを制御することである。最後に、任意的である第４の機能は、最低限のセッション制御情報を伝達することである。
【０００８】
ＲＴＰ／ＡＶＰＦは、受信者が送信者に対して統計的により迅速なフィードバックの提供を可能にするための、ＲＴＣＰに基づく拡張機能であり、これにより短期間での適応、及び効率的なフィードバックベースの修復メカニズムの実装が可能となる。この早期フィードバックプロファイル（ＡＶＰＦ）は、ＲＴＣＰに対するＡＶＰ帯域幅の制約を維持し、且つ大きなグループへの拡張性を保持する。セッションを記述するために、上記プロファイル内で多くの新しいＳＤＰパラメータが定義される。これに応答して、ＲＴＣＰフィードバックメッセージのフォーマットもまた定義され、このフォーマットを（１）トランスポート層フィードバックメッセージ、（２）ペイロード専用のフィードバックメッセージ、及び（３）アプリケーション層フィードバックメッセージという３つのカテゴリに分けることができる。残念ながら、ＲＴＰ／ＡＶＰＦに対して提案されるメッセージフォーマットの大半は、オーディオ−ビデオアプリケーション専用であり、リッチメディア・アプリケーションに適したものではない。
【０００９】
ＰＳＳの基本語彙は、「ＰｓｓＣｏｍｍｏｎ」、「Ｓｔｒｅａｍｉｎｇ」、「ＴｈｒｅｅＧＰＦｉｌｅＦｏｒｍａｔ」、及び「ＰｓｓＳｍｉｌ」と呼ばれる４つのコンポーネントを含む。これらのコンポーネントへの語彙の分類は、（１）ｓｔｒｅａｍｉｎｇコンポーネントによって記述される、純粋なＲＴＳＰ／ＲＴＰベースのストリーミング、（２）ＴｈｒｅｅＧＰＦｉｌｅＦｏｒｍａｔコンポーネントによって記述される、３ＧＰファイルのダウンロード又はプログレッシブダウンロード、及び（３）ＰｓｓＳｍｉｌコンポーネントによって記述される、ＳＭＩＬプレゼンテーションという３つの異なる基本アプリケーションをＰＳＳが含むという事実により動機付けられる。ＳＭＩＬプレゼンテーションは、ダウンロード可能な画像、テキスト等、並びにＲＴＳＰ／ＲＴＰストリーミング及びダウンロード可能な３ＧＰファイルを含むことができる。全てのＰＳＳアプリケーションに共通する機能は、ＰｓｓＣｏｍｍｏｎコンポーネントにより記述される。これらの３つの基本アプリケーションは、同期ソースにより互いに区別される。純粋なストリーミングの場合、ソースはＲＴＰである。３ＧＰファイルの場合、ソースは３ＧＰファイルフォーマットの形で引き継がれる。ＳＭＩＬプレゼンテーションの場合、ＳＭＩＬファイルによってタイミングが与えられる。ＰＳＳ専用のコンポーネントは、機能を表す多くの属性を含む。しかしながら、クライアントがフィードバックを提供する機能について記述する属性が１つ欠けている。
【００１０】
ユーザ、オペレータ、及びインターネットサービスプロバイダにとって、エンドツーエンドのサービス品質は非常に重要である。体感品質（ＱｏＥ）は、オーディオ及び音声のためのより広い帯域幅、インターネットプロトコルテレビジョン（ＩＰＴＶ）などの新しいマルチメディアサービス、及びコンテンツの損失した又は破損したパケットを示す統計データを含む幅広いサービスを網羅するものである。現存の及び新規のサービスプロバイダは両者共に、市場シェアを獲得し、サービスを拡大する一方で経費を削減し、顧客の忠誠心を生み出すことにより、営業成績を増大させる必要に迫られている。顧客離れを最小限に抑える１つのそのような取り組みはＱｏＥの配布である。ＱｏＥメトリクスは、上記継続性、及び、例えば動的かつインタラクティブなメディアシーン（ＤＩＭＳ）のコンテンツを含むような連続媒体の同期化を高めるのに役立てることができる。
【００１１】
３ＧＰＰのＱｏＥメトリクスは、ＰＳＳのストリーミングサーバとクライアントとの両方に対する任意の機能としてＰＳＳシステムにおいて特定されており、ＰＳＳのサービスを妨げるものではない。上記機能をサポートするＰＳＳのクライアントは、測定定義に基づいて品質測定を行い、これらの測定値を集計してクライアントのＱｏＥメトリクスを作成し、コンテンツ受信報告手順を用いてこれらのメトリクスをＰＳＳサーバに報告する。しかしながら、ＰＳＳにおいて定義されるメトリクスの全ては、オーディオ、ビデオ、音声、及び時間調節テキスト媒体型のうちの少なくとも１つにのみ適用可能であり、合成オーディオ、静止画像、ビットマップグラフィックス、ベクトルグラフィックス、及びテキストなどの他の媒体型には適用不可能である。任意の未知のメトリクスは、クライアントにより無視され、いかなるＱｏＥ報告にも含まれることはない。
【００１２】
ＭＢＭＳ  ＱｏＥメトリクスは、ＭＢＭＳストリーミングサーバ及びＭＢＭＳの両方に対して任意のものであり、ＭＢＭＳサービスを妨害するものではない。一般的にＭＢＭＳ  ＱｏＥメトリクスをサポートするＭＢＭＳクライアントは、測定定義に基づいて品質測定を行い、これらの測定値を集計してクライアントのＱｏＥメトリクスを作成し、コンテンツ受信報告手順を用いてこれらのメトリクスをＭＢＭＳサーバに報告する。
【００１３】
米国特許出願公報第２００５／０２４９１１７号に、２又はそれ以上のチャネルの形で構造化されたネットワークリンクを介して、異なるサービス品質（ＱｏＳ）属性を有するデータフローを送信する方法についての記述がある。この方法は、着信パケットを分類してこれらのパケットの要求される／割り当てられるＱｏＳ属性を判定し、分類したパケットを複数の論理チャネルキューのうちの１つの中に入れ、この選択された論理チャネルキューが、定義されたＱｏＳ属性の適当な対応する組を有するようにするものである。無線リンクコントローラは、利用可能なチャネルを調べ、そのチャネルで送信されることになるコンテンツを有する論理チャネルキューを各チャネルに対して選択する。論理チャネルキューの選択は、ＱｏＳ属性の組に基づいて行われる。従って、各フローは、優先度、信頼性（ＡＲＱ、非ＡＲＱ等）を含む異なるＱｏＳ特性を有することができる。しかしながら、このシステムは、主に異なる論理キューへのＱｏＳ属性割り当てに主眼を置くものであり、ＱｏＳパラメータ自体、特にリッチメディア・アプリケーションを扱うものではない。
【００１４】
米国特許出願公報第２００５／０１６９１７１号に、エンドツーエンドのサービス品質（ＱｏＳ）制御をサポートするためのシステムについて記載がある。ＱｏＳパラメータへのマッピングを行うＱｏＳプロファイル識別子が生成される。この識別子は、無線通信システムを介して終端局へ送信され、この終端局は、受信した識別子に基づいてＱｏＳパラメータを判定する。しかしながら、このシステムは、ＱｏＳメトリクスとして送信された実データよりも、むしろＱｏＳパラメータの制御の方に関するものである。更にこのシステムでは、エンドツーエンドのリッチメディア・アプリケーションにおいてＱｏＳメトリクスに関する特定の情報を定義する必要がある。
【００１５】
【特許文献１】米国特許出願第２００５／０２４９１１７号公報
【特許文献２】米国特許出願第２００５／０１６９１７１号公報
【非特許文献１】ＲＴＣＰベースのフィードバックのための拡張ＲＴＰプロファイル（ＲＴＰ／ＡＶＰＦ）のインターネット草案、インターネット＜ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｃｐ−ｆｅｅｄｂａｃｋ−１１．ｔｘｔ＞
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は、リッチメディア・アプリケーションにおいてデータ送信中に品質メトリクスを提供するためのシステム及び方法について説明するものである。このような品質メトリクスが重要な役割を果たし得る、インタラクティブなリッチメディアサービスの複数の使用事例が存在する。例えば、インタラクティブな移動ＴＶサービスは、ＴＶ及びラジオのチャンネルと共に、オーディオ−ビデオコンテンツ、テキスト、グラフィックス、画像を含むリッチメディアコンテンツの確定的なレンダリング及び動作を、まとめてエンドユーザインターフェースに提供することを含む。このサービスでは、単一のアプリケーション又はサービスの形でコンテンツを通じて便利なナビゲーションを提供する必要があり、投票及び個人化などの地方の又は遠距離の活動におけるインタラクションを同期できるようにする必要がある（例えば、エンドユーザのプロフィール又はサービス加入の機能における、関連するメニュー又はサブメニュー、広告、及びコンテンツなど）。このサービスでは、損失したパケット及び破損したパケットの観点からデータ送信の性質について記述する品質メトリクスは、このサービスのためにフィードバックとして有益である。
【００１７】
ウェブカム又はビデオチャンネル内に、或いはリッチメディアブログサービスにライブチャットサービスを組み入れることができる。エンドユーザは、自分たちの名前を登録、保存して、メッセージを交換することができる。ライブチャットサービスでは、メッセージは、エンドユーザが提供するリッチメディアデータと共に動的に出現する。チャットサービスは、同時に１又はそれ以上の複数のチャンネルにおいて、私的な又は公的なサービスのいずれとすることもできる。エンドユーザは、他のユーザからの新しいメッセージを動的に知らされる。サービス内での動的なメッセージ更新は、ページ全体をリロードすることなく行われる。これらの更新のうちの不正に受信された更新について記述する品質メトリクスをエラーの回復及び隠蔽に役立てて、サービスの全体的なユーザ体感を改善することができる。
【００１８】
それに加えて、ビデオ／楽曲選択サービスは、ユーザが、サーバからリアルタイムで自分の好みの楽曲又は映画を選択／リクエストできるようにする。コンテンツの更新は、どのクライアントがより早くリクエストを送信したかに依存するか、或いは各クライアントに割り当てた優先度に基づくようにすることができる。この状況でもまた、リクエストした楽曲のコンテンツがクライアントに正しく着信したかどうかを評価するのにＱｏＳメトリクスを用いることができる。
【００１９】
遠隔ユーザインターフェース（ＵＩ）は、アプリケーション論理プログラムを動作させる装置以外の装置上にユーザインターフェースをレンダリングできるようにするメカニズムである。製造業者は、ある環境に対して高度に最適化された装置を作り出している。これらの装置は様々な目的に向けられているため、そのＵＩ性能は大幅に異なる可能性があり、画面サイズ及び画面比率、色の深み、様々なコンポーネントの組を有するウィンドウシステム、及び入力方法が、これらの環境を大幅に異なるものにしている。同時に、アプリケーション開発者及びＵＩ設計者は、レンダリングプラットフォーム用として高度に最適化されたユーザインターフェースを作成することにより、それぞれのアプリケーションの習得及び使用を簡単にすることでユーザ体感の改善を図ろうとしている。このような遠隔ＵＩが、アプリケーション論理プログラムを動作させる装置以外の装置上でレンダリングされる場合には、ユーザがこのＵＩを、直感的に装置を使用できるようにするローカルアプリケーションであると分かるように提供される必要がある。この場合、ＱｏＳメトリクスは、全てのＵＩコンテンツが別のクライアントに遠隔的に正しくストリーミングされたか否かを評価する上で有用である。
【課題を解決するための手段】
【００２０】
上記全ての場合において、アプリケーションは、ブロードキャスト指向又はピアツーピア指向のいずれとすることもできる。本発明によれば、ＰＳＳの基本語彙に対する拡張機能、ＲＴＰパケット損失、不正に受信されたアクティブなＳＶＧ要素のリスト、正しく受信及び復号化されたアクティブなＳＶＧ要素のリスト、破損継続時間、破損したＳＶＧグループなどのＰＳＳの体感品質（ＱｏＥ）に対する拡張機能、ＲＴＰ／ＡＶＰＦに対する拡張機能、並びにトランスポート層フィードバックメッセージに対する拡張機能などの情報を伝達するために、様々な品質メトリクスを定義することができる。リッチメディアクライアントがこのような測定を利用することで、サーバは、送信品質を評価すると共に、パケット再送などのエラー回復メカニズムを考慮に入れて、失われた情報をクライアントに提供することができるようになる。
【００２１】
また本発明の様々な実施形態は、ＤＩＭＳ専用のコンテンツ及びサービスのエラー回復及びエラー隠蔽のためだけでなく、統計データの分析にも利用可能なＱｏＥメトリクスを提供する。このようなメトリクスを用いて、例えば、個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数、破損シーン、破損シーンの更新、及びＤＩＭＳ破損継続時間値（破損シーン及び破損シーンの更新の時間によって測定される）を報告することができる。
【００２２】
本発明の上記の及びその他の利点及び特徴は、その構成及び動作方法と共に、以下で説明する複数の図面を通して同様の要素が同様の番号を有する添付図面と併せて以下の詳細な説明から明らかとなるであろう。
【発明を実施するための最良の形態】
【００２３】
図１は、本発明を利用することができるシステム１０を示しており、このシステム１０は、ネットワークを介して通信することができる複数の通信装置を含んでいる。システム１０は、以下に限定されるわけではないが、移動電話ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）、ブルートゥースパーソナルエリアネットワーク、イーサネット（登録商標）ＬＡＮ、トークンリングＬＡＮ、広域ネットワーク、インターネット、通信装置間の１又はそれ以上のアドホックネットワーク等を含む有線又は無線ネットワークの任意の組み合わせを有することができる。システム１０は、有線と無線の両方の通信装置を含むことができる。
【００２４】
例示として、図１に示すシステム１０は、移動電話ネットワーク１１及びインターネット２８を含む。インターネット２８への接続は、以下に限定されるわけではないが、長距離無線接続、短距離無線接続、及び以下に限定されるわけではないが、電話線、ケーブル線、送電線等を含む様々な有線接続を含むことができる。
【００２５】
システム１０の例示の通信装置は、以下に限定されるわけではないが、移動電話１２、ＰＤＡと移動電話との組み合わせ１４、ＰＤＡ１６、統合メッセージング装置（ＩＭＤ）１８、デスクトップコンピュータ２０、及びノートブックコンピュータ２２を含むことができる。この通信装置は、据置式のもの、又は移動している個人が搬送する場合には移動式のものとすることができる。この通信装置はまた、以下に限定されるわけではないが、自動車、トラック、タクシー、バス、船、飛行機、自転車、単車等を含む輸送手段の中に配置することもできる。この通信装置の幾つか又は全ては、呼及びメッセージを送受信することができ、無線接続２５を介して基地局２４と通信することができる。基地局２４は、移動電話ネットワーク１１とインターネット２８との間の通信を可能にするネットワークサーバ２６に接続することができる。システム１０は、追加の通信装置及び異なる種類の通信装置を含むことができる。これらの通信装置は、相互に直接通信することができる。
【００２６】
通信装置は、以下に限定されるわけではないが、符号分割多重接続（ＣＤＭＡ）、移動通信用グローバルシステム（ＧＳＭ）、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）、時分割多元アクセス（ＴＤＭＡ）、周波数分割多元アクセス（ＦＤＭＡ）、送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ショートメッセージングサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、電子メール、インスタントメッセージングサービス（ＩＭＳ）、ブルートゥース、ＩＥＥＥ  ８０２．１１等を含む様々な送信技術を用いて通信することができる。通信装置は、以下に限定されるわけではないが、無線、赤外線、レーザー、ケーブル接続等を含む様々な媒体を用いて通信を行うことができる。
【００２７】
図２及び図３は１つの代表的な移動電話１２を示しており、該移動電話内で本発明を実施することができる。しかしながら、１つの特定の種類の移動電話１２又は他の電子装置に本発明を限定することを意図するものではないと理解されたい。図２及び図３の移動電話１２は、ハウジング３０、液晶ディスプレイの形のディスプレイ３２、キーパッド３４、マイクロフォン３６、受話口３８、電池４０、赤外線ポート４２、アンテナ４４、本発明の１つの実施形態によるＵＩＣＣ形態のスマートカード４６、カードリーダ４８、無線インターフェース回路５２、コーデック回路５４、コントローラ５６、及びメモリ５８を含む。個々の回路及び要素は、全て当業で周知の種類のもの、例えばＮｏｋｉａ社の移動電話の範囲内のものである。
【００２８】
本発明は、リッチメディア・アプリケーションにおいてデータ送信中に品質メトリクスを提供するためのシステム及び方法について説明するものである。以下の説明は、品質測定に関する詳細を提供する。本明細書で説明する新しい拡張機能は、ＰＳＳの基本語彙、ＰＳＳの体感品質、及びＲＴＰ／ＡＶＰＦの形で定義される。リッチメディア・アプリケーション専用のＱｏＥ情報を提供するために、ＰＳＳにおいて幾つかの拡張機能を定義する必要がある。それに応答して、下位層プロトコルＲＴＰ／ＡＶＰＦにおいてもまた幾つかの拡張機能が定義され、これらの拡張機能が、拡張ＱｏＥデータについての実際のフィードバックサービスを提供する。ＰＳＳ及びＲＴＰ／ＡＶＰＦは、相互に密接に関連している。ＲＴＰ／ＡＶＰＦの形で転送される拡張データは、ＰＳＳにおける拡張コンテンツから導出される。
【００２９】
ＰＳＳの基本語彙に対する拡張機能
ＰＳＳの基本語彙は、「ＰｓｓＣｏｍｍｏｎ」、「Ｓｔｒｅａｍｉｎｇ」、「ＴｈｒｅｅＧＰＦｉｌｅＦｏｒｍａｔ」、及び「ＰｓｓＳｍｉｌ」と呼ばれる４つのコンポーネントを含む。前に説明したように、これらのコンポーネントへの語彙の分割は、（１）ｓｔｒｅａｍｉｎｇコンポーネントによって記述される純粋なＲＴＳＰ／ＲＴＰベースのストリーミング、（２）ＴｈｒｅｅＧＰＦｉｌｅＦｏｒｍａｔコンポーネントによって記述される３ＧＰファイルのダウンロード又はプログレッシブダウンロード、及び（３）ＰｓｓＳｍｉｌコンポーネントによって記述されるＳＭＩＬプレゼンテーションという、３つの異なる基本アプリケーションをＰＳＳが含むという事実により動機付けられる。本発明の１つの実施形態によれば、クライアントによって提供されるフィードバックの機能及びモードを記述するために、新しい属性「ＦｅｅｄｂａｃｋＭｅｔｈｏｄ」がＰｓｓＣｏｍｍｏｎコンポーネントに追加される。この属性の性質は以下の通りである。
属性名：ＦｅｅｄｂａｃｋＭｅｔｈｏｄ
属性定義：この属性は、クライアントによって提供されるフィードバックの機能及びモードについて記述する。
コンポーネント：ＰｓｓＣｏｍｍｏｎ
種類：リテラル
有効な値：「Ｎｏｎｅ」、「ＳＭＳ」、「ＭＭＳ」、「ＨＴＴＰ」、「ＲＴＳＰ」
導出規則：付加
例：＜ＦｅｅｄｂａｃｋＭｅｔｈｏｄ＞ＭＭＳ＜／ＦｅｅｄｂａｃｋＭｅｔｈｏｄ＞
【００３０】
ＰＳＳの体感品質に対する拡張機能
ＰＳＳの体感品質メトリクス機能は、ＰＳＳサーバ及びクライアントの両方に対して任意のものであり、ＰＳＳサービスを妨げるものではない。ＱｏＥメトリクス機能をサポートするＰＳＳサーバは、所望の場合、クライアントＱｏＥメトリクスの活性化及び集まりをシグナリングする。この機能をサポートする３ＧＰＰ  ＰＳＳクライアントは、測定定義に基づいて品質測定を行い、これらを集計してクライアントのＱｏＥメトリクスを作成し、所望の場合、ＱｏＥ転送プロトコルを用いてこれらのメトリクスをＰＳＳサーバに報告する。ＰＳＳクライアントはトランスポート層においてメトリクスを測定するが、精度を向上させるためにアプリケーション層においてメトリクスを測定することもできる。クライアントにおけるサンプル及び要素の現在の状況（正しく受信した、不正に受信した、又は損失した）を記述するために、幾つかの新しいメトリクスが定義される。
【００３１】
本発明の１つの実施形態によれば、個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数を報告する場合、そのシンタックスは、Ｌｏｓｔ＿Ｐｒｉｏｒｉｔｙ＝｛ｌＦ，３Ｅ，０，２１｝；Ｒａｎｇｅ：Ｓｅｑ＿Ｎｕｍ＝６００００−６０５００となる。シーケンス番号が６００００から６０５００までの範囲のＲＴＰパケットの場合、パケット損失は以下の通りである（損失したパケットの個数は１６進フォーマットで表している）。
優先度１Ｆ＝パケット損失０
優先度３Ｅ＝パケット損失１
優先度ゼロ＝パケット損失２
優先度２１＝パケット損失３
【００３２】
本発明の別の実施形態では、「Ｌｏｓｔ＿Ｐｒｉｏｒｉｔｙ＝．．．」及び「Ｒａｎｇｅ：Ｓｅｑ＿Ｎｕｍ＝．．．」の位置及び対応値を変更することができることに留意されたい。加えて、Ｌｏｓｔ＿Ｐｒｉｏｒｉｔｙフィールド内の４つの要素の順番を変更することもできる。
【００３３】
直近の「アクティブな要素リスト」の中で正しく受信及び復号化されなかった要素のリストを報告する場合、「アクティブな要素リスト」をグループ毎に１回送信する。この「アクティブな要素リスト」に応答して、以下に定義するＬｏｓｔ＿Ｅｌｅｍｅｎｔを、このグループの送信処理中又は処理後の任意の時点で複数回送信することができる。本発明の１つの実施形態によれば、この報告のためのシンタックスは、Ｌｏｓｔ＿Ｅｌｅｍｅｎｔ＝｛要素１０，要素２２，要素４５｝；Ｒａｎｇｅ：ＧＲＰ＝１２となる。ＧＲＰ＝１２を有するグループでは、３つのアクティブな要素が失われている。これらの要素は、要素１０、要素２２、及び要素４５である。本発明の別の実施形態では、「Ｌｏｓｔ＿Ｅｌｅｍｅｎｔ＝．．．」及び「Ｒａｎｇｅ：ＧＲＰ＝．．．」フィールドの位置及び対応値を変更することができることにも留意されたい。
【００３４】
現在のグループ内でどの要素が正しく受信、復号化され、かつアクティブであるかを報告するために、クライアントは、「アクティブな要素リスト」を受信したか否かに関わらず、クライアントにおけるアクティブな要素の現在の状況について記述する、以下に定義するリストを送信することができる。本発明の１つの実施形態によれば、この報告のシンタックスは、Ａｃｔｉｖｅ＿Ｅｌｅｍｅｎｔ＝｛要素１，要素２，要素４，要素５，要素８，要素１１｝；Ｒａｎｇｅ：ＧＲＰ＝１３となる。この特定の例では、現在のグループはＧＲＰ＝１３を有する。このグループ内では、６つのアクティブな要素が正しく受信されている。これらの要素は、要素１０、要素２２、及び要素４５である。本発明の様々な実施形態では、「Ａｃｔｉｖｅ＿Ｅｌｅｍｅｎｔ＝．．．」及び「Ｒａｎｇｅ：ＧＲＰ＝．．．」フィールドの位置及び対応値を変更することができることに留意されたい。
【００３５】
破損シーンの更新の総数によって測定されるＣｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎを報告するためには、１つの実施形態におけるシンタックスは、Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＿Ｓｃｅｎｅｕｐｄａｔｅ＝｛３０  １２３４５；７５  １２５５５｝；Ｒａｎｇｅ：ＧＲＰ＝１６となる。ＧＲＰ＝１６を有するグループのＲＴＰパケットの中に、シーンの更新に関するパケット損失を原因とする合計２つの破損が存在する。特定のシーンの更新に関するパケットのうちの１つが損失し、実質的に修復されなかった場合には、このシーンの更新は損失したとみなされる。最初に損失したシーンの更新の先頭パケットのシーケンス番号は１２３４５である。このシーンの更新は３０パケットの間続いたことになる。２番目に損失したシーンの更新の先頭パケットのシーケンス番号は１２５５５である。このシーンの更新は７５パケットの間続いたことになる。サーバは、上記情報に基づいて残りのシーンの更新を送信するか否かを決定する。Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＿Ｓｃｅｎｅｕｐｄａｔｅ＝｛３０  １２３４５；？  １２５５５｝；Ｒａｎｇｅ：ＧＲＰ＝１６である別の例では、最初に損失したシーンの更新の先頭パケットのシーケンス番号は１２３４５である。このシーンの更新は３０パケットの間続いたことになる。２番目に損失したシーンの更新の先頭パケットのシーケンス番号は１２５５５である。正確な継続期間が不明な場合には、「？」が挿入される。
【００３６】
破損したグループを報告する場合、１つの実施形態におけるシンタックスは、Ｃｏｒｒｕｐｔｅｄ＿Ｇｒｏｕｐ＝｛１４｝となる。この例では、このグループのシーンデータのパケット損失に起因して、ＧＲＰ＝１４であるグループが破損している。サーバは、これらのグループに関連する以降のいかなるパケットも送信しないことを選択することができる。本発明の別の実施形態では、「Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＿Ｓｃｅｎｅｕｐｄａｔｅ＝．．．」及び「Ｒａｎｇｅ：ＧＲＰ＝．．．」フィールドの位置及び対応値を変更することができることにも留意されたい。
【００３７】
シーン内の連続するグループ間の境界を推定することは、失われたパケットが実際にどのグループに属するかを知るために重要である。この目的のために、ＳＶＧデータのＲＴＰペイロードヘッダ内で定義されるＳ及びＭフラグを用いることができる。Ｓフラグ（１ビット）は、現在のパケットが現在のサンプルの起点を含むか否かを示す一方、Ｍフラグは、現在のサンプルの終点を示すものである。Ｍ及びＳフラグの組み合わせにより、以下の情報が提供される。
Ｍ＝１、Ｓ＝１の時、現在のパケットは完全なサンプルを含む。
Ｍ＝０、Ｓ＝１の時、現在のパケットはサンプルの最初のフラグメントを含む。
Ｍ＝１、Ｓ＝０の時、現在のパケットはサンプルの最後のフラグメントを含む。
Ｍ＝０、Ｓ＝０の時、現在のパケットはサンプルの中間のフラグメントを含む。
【００３８】
この例では、「サンプル」とは、ＳＶＧシーン、シーンの更新、ＳＶＧの類似性情報、又はＳＶＧ要素のアクティブなリストを意味するものとする。
【００３９】
ＲＴＰ／ＡＶＰＦに対する拡張機能
ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｃｐ−ｆｅｅｄｂａｃｋ−１１．ｔｘｔにおいて見出すことができるＲＴＣＰベースのフィードバックのための拡張ＲＴＰプロファイル（ＲＴＰ／ＡＶＰＦ）のインターネット草案では、新しいペイロードフォーマット専用のＳＤＰ属性が、文献「ａ＝ｒｔｃｐ−ｆｂ」内で指定されているようなＲＴＣＰフィードバックを用いる機能を示すＳＤＰメディア属性として定義されている。これに応答して、フィードバックメッセージ（トランスポート層／ペイロード層／アプリケーション層）を送信するために、ＲＴＣＰパケット上の２つの拡張機能も定義される。ＰＳＳ  ＱｏＥ内で定義される上記のシンタックスは、このＳＤＰ＋ＲＴＣＰプロファイルの中にマッピングされる。このシンタックスをＲＴＰ／ＡＶＰＦの拡張機能として用いて、リッチメディアインタラクションについてのフィードバックメッセージを提供することができる。
【００４０】
「ｒｔｃｐ−ｆｂ」属性のシンタックスは以下の通りである（フィードバックタイプ及び任意のパラメータは全て大文字と小文字の区別がなされる）。下線付きパラメータは本発明に従って新しく定義したものである。
ｒｔｃｐ−ｆｂ−ｓｙｎｔａｘ        ＝“ａ＝ｒｔｃｐ−ｆｂ：”ｒｔｃｐ−ｆｂ−ｐｔ  ＳＰ  ｒｔｃｐ−ｆｂ−ｖａｌ  ＣＲＬＦ
ｒｔｃｐ−ｆｂ−ｐｔ                ＝“＊”；ワイルドカード：全てのフォーマットに適応
／ｆｍｔ；ＳＤＰ仕様に定義
ｒｔｃｐ−ｆｂ−ｖａｌ              ＝“ａｃｋ”ｒｔｃｐ−ｆｂ−ａｃｋ−ｐａｒａｍ
／“ｎａｃｋ”ｒｔｃｐ−ｆｂ−ｎａｃｋ−ｐａｒａｍ
／“ｔｒｒ−ｉｎｔ”ＳＰ１＊ＤＩＧＩＴ
／ｒｔｃｐ−ｆｂ−ｉｄ  ｒｔｃｐ−ｆｂ−ｐａｒａｍ
ｒｔｃｐ−ｆｂ−ｉｄ                ＝１＊（ａｌｐｈａ−ｎｕｍｅｒｉｃ／“−”／“＿”）
ｒｔｃｐ−ｆｂ−ｐａｒａｍ          ＝ＳＰ“ａｐｐ”［ＳＰ  バイト文字列］
／ＳＰ  ｔｏｋｅｎ［ＳＰ  バイト文字列］
／；空
ｒｔｃｐ−ｆｂ−ａｃｋ−ｐａｒａｍ  ＝ＳＰ“ｒｐｓｉ”
／ＳＰ“ａｐｐ”［ＳＰ  バイト文字列］
／ＳＰ“ａｅｉ”
／ＳＰ  ｔｏｋｅｎ［ＳＰ  バイト文字列］
／；空
ｒｔｃｐ−ｆｂ−ｎａｃｋ−ｐａｒａｍ＝ＳＰ“ｐｌｉ”
／ＳＰ“ｓｌｉ”
／ＳＰ“ｒｐｓｉ”
／ＳＰ“ｌｐｐｉ”
／ＳＰ“ｌｅｉ”
／ＳＰ“ｃｄｓｕ”
／ＳＰ“ｃｇ”
／ＳＰ“ａｐｐ”［ＳＰ  バイト文字列］
／ＳＰ  ｔｏｋｅｎ［ＳＰ  バイト文字列］
／；空
【００４１】
上記の「ｒｔｃｐ−ｆｂ」属性シンタックスでは、ＡＣＫ（肯定応答）に１つの拡張機能を追加し、ＮＡＣＫ（否定応答）に４つの拡張機能を追加している。「ａｃｋ」及び「ｎａｃｋ」を用いた利用のために以下のパラメータを定義する。「ａｅｉ」はアクティブな要素の表示を意味する。「ｌｐｐｉ」は損失した優先パケットの表示を意味する。「ｌｅｉ」は損失した要素の表示を意味する。「ｃｄｓｕ」はシーンの更新によって計数される破損継続時間を意味する。「ｃｇ」は破損したグループを意味する。これらのＳＤＰパラメータに応答して、ＲＴＰ／ＡＶＰＦに基づいて新しいフィードバックメッセージを以下のように定義する。
【００４２】
トランスポート層フィードバックメッセージに対する拡張機能：トランスポート層フィードバックメッセージは、ＲＴＣＰヘッダ内のペイロードタイプ（ＰＴ）フィールドの値ＰＴ＝ＲＴＰＦＢにより識別され、この場合ＰＴフィールドは、パケットが、トランスポート層、ペイロード層、又はアプリケーション層のいずれに属するかを示す。これまでＲＴＰ／ＡＶＰＦ内において定義されている単一の汎用トランスポート層フィードバックメッセージは汎用ＮＡＣＫである。上記汎用ＮＡＣＫはＦＭＴパラメータにより以下のように識別される。
０：未割り当て
１：汎用ＮＡＣＫ
２〜３０：未割り当て
３１：識別子番号空間の将来の拡張用として予約済み
【００４３】
個々の優先度に対する損失したパケットの表示を行うために、「ｌｐｐｉ」ＮＡＣＫメッセージをトランスポート層で以下のように定義する。このようなＮＡＣＫメッセージはＰＴ＝ＲＴＰＦＢ及びＦＭＴ＝３０により識別される。
【００４４】
損失した優先パケットを表示する（ｒｔｃｐ−ｆｂ−ｐａｒａｍ＝ｌｐｐｉ）場合、ＳＶＧ  ＲＴＰパケットは４つの優先度に分類される。ＲＴＰヘッダ内のＧＲＰフィールドにより優先度レベルが示される。ＲＴＣＰメッセージは、個々の優先度に対する一定期間中のパケット損失を報告する。損失した優先パケットを示すためのフォーマットを図４に示す。１６ビットのＳＳＮは現在の測定の起点のシーケンス番号を表す。同じく１６ビットのＥＳＮは現在の測定の終点のシーケンス番号を表す。ＣＰ０、ＣＰ１、ＣＰ２、及びＣＰ３は各々４ビットの長さである。ＣＰ０は、優先度０の状態で損失したパケット数を表す。ＣＰ１は、優先度１の状態で損失したパケット数を表す。ＣＰ２は、優先度２の状態で損失したパケット数を表す。ＣＰ３は、優先度３の状態で損失したパケット数を表す。
【００４５】
ペイロード層フィードバックメッセージに対する拡張機能：ペイロード層フィードバックメッセージは、ＲＴＣＰヘッダ内のペイロードタイプ（ＰＴ）フィールドにおける値ＰＴ＝ＰＳＦＢにより識別される。アプリケーション層フィードバックメッセージに加えて、３つのペイロード専用のフィードバックメッセージが、ＲＴＰ／ＡＶＰＦにおいて現在定義されている。これらのメッセージは、以下のようにＦＭＴパラメータにより識別される。
０：未割り当て
１：画像損失の表示（ＰＬＩ）
２：スライス損失の表示（ＳＬＩ）
３：参照画像選択の表示（ＲＰＳＩ）
４〜１４：未割り当て
１５：アプリケーション層フィードバックメッセージ
１６〜３０：未割り当て
３１：シーケンス番号空間の将来の拡張用として予約済み
【００４６】
以下、ペイロード専用のフィードバックメッセージのための４つの新しいＦＣＩフォーマットの定義について説明する。これらのフォーマットの各々にはＳＶＧグループ（ＧＲＰ）フィールドが存在し、それにより、同じグループに属する複数のＲＴＣＰ／ＡＶＰＦパケットが、これらパケットの下層のフォーマットで同じＧＲＰ  ｉｄを含むことができるようになる。このようなパケットは、共にその特定のグループ（ＧＲＰ）についての全情報を表す。
【００４７】
損失した要素の表示（ｒｔｃｐ−ｆｂ−ｐａｒａｍ＝ｌｅｉ）、ＦＭＴ＝２７：ＳＶＧ表示には、現在のグループ内でのみ有効な多くの要素が含まれる。「アクティブな要素リスト」はグループ毎に１回クライアントへ送信される。図５に示すＲＴＣＰメッセージは、直近の「アクティブな要素リスト」内で正しく受信及び復号化されなかった要素の個数を報告する。ＧＲＰフィールドは４ビットであると共に、現在のパケットが報告しているグループ番号を示すものである。ＰＡＤフィールドは４ビットであると共に、ＢＹＴＥを基準にして数えられる、このパケットの終端における埋め草ビットの長さを示すものである。ＬＬＥフィールドは可変長であると共に、「要素１，要素３，要素５，要素６」又は「要素１；要素３；要素５；要素６」のようにコンマ又はセミコロンによって区切られた、損失した要素のテキストベースのリストを表すものである。ＰＢフィールドもまた可変長であると共に、ＢＹＴＥを基準にして数えられる埋め草ビットを示すものである。この長さはＰＡＤにより示される。ＰＢはパケット全体を３２ビットに配列する。
【００４８】
アクティブな要素の表示（ｒｔｃｐ−ｆｂ−ｐａｒａｍ＝ａｅｉ）、ＦＭＴ＝２８：図６に定義するＲＴＣＰメッセージは、現在のグループ内でどの要素が正しく受信、復号化され、かつアクティブであるかを報告する。ＧＲＰフィールドは４ビットであると共に、現在のパケットが報告しているグループ番号を示すものである。ＰＡＤフィールドは４ビットであると共に、ＢＹＴＥを基準にして数えられる、このパケットの終端における埋め草ビットの長さを示すものである。ＬＡＥフィールドは可変長であると共に、「要素１，要素３，要素５，要素６」のようにコンマによって区切られた、損失した要素のテキストベースのリストを表すものである。ＰＢフィールドも同じく可変長であると共に、ＢＹＴＥを基準にして数えられる埋め草ビットを示すものである。この長さはＰＡＤにより示される。ＰＢフィールドはパケット全体を３２ビットに配列する。
【００４９】
シーンの更新により数えられる破損継続時間（ｒｔｃｐ−ｆｂ−ｐａｒａｍ＝ｃｄｓｕ）、ＦＭＴ＝２９：
【００５０】
図７に定義するＲＴＣＰメッセージは、１つのグループにわたる破損継続時間を示している。個々の破損は、１つの特定のＲＴＰパケットから始まり、数パケットの間継続する。ＧＲＰフィールドは４ビットであると共に、現在のパケットが報告しているグループ番号を示すものである。ＰＡＤフィールドは４ビットであると共に、このパケットの終端における埋め草ビットの長さを示すものである。ＣＤｎフィールドも同じく４ビットであると共に、現在のグループ内の１つの特定のリストのパケットの破損継続時間を表すものである。ＳＳＮｎフィールドは１６ビットであると共に、少なくとも１つの損失したパケットを含む、対応するシーンの更新のシーケンス番号を示すものである。このような損失したパケットは修復が不可能である。（ＣＤ、ＳＳＮ）の対は、シーケンス番号によりインデックスを付けられ、昇順にリストされる。ＰＢフィールドは可変長であると共に、４ビットを基準にして数えられる埋め草ビットを示すものである。この長さはＰＡＤにより示される。ＰＢはパケット全体を３２ビットに配列する。
【００５１】
破損したグループ（ｒｔｃｐ−ｆｂ−ｐａｒａｍ＝ｃｇ）、ＦＭＴ＝３０：図８に示すＲＴＣＰメッセージは、グループのシーンデータのパケット損失に起因して破損したグループを示している。ＮＣＧフィールドは４ビットであると共に、現在のパケットが報告しているグループの個数を表すものである。ＧＲＰｎも同じく４ビットであると共に、破損したグループのＧＲＰを表すものである。これらのフィールドは１つずつ置かれる。これらの合計個数はＮＣＧフィールドにより示される。ＰＢフィールドは可変長であると共に、埋め草ビットを表すものである。この長さはＮＣＧから推定することができる。ＰＢフィールドはパケット全体を３２ビットに配列する。
【００５２】
本発明の様々な実施形態は、ＤＩＭＳ専用のコンテンツ及びサービスの統計的なデータ分析のために用いることができるＱｏＥメトリクスを導入するための基礎として、ＰＳＳ及びＭＢＭＳベースのＱｏＳメトリクスを用いるステップも含むものである。このようなメトリクスは、例えば、個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数、及びＤＩＭＳ破損継続時間値（破損シーン及びシーンの更新の継続時間により測定される）の報告に用いることができる。上記の各々について以下に説明する。ＤＩＭＳ  ＱｏＥメトリクスは、ＤＩＭＳストリーミングサーバ及びクライアントの両方に対して任意の機能であり、ＤＩＭＳサービス自体を妨害することはない。この機能をサポートするＤＩＭＳクライアントは、測定定義に基づいて品質測定を行い、これらを集計してクライアントのＱｏＥメトリクスを作成し、更にコンテンツ受信報告手順を用いて、これらのメトリクスをＤＩＭＳサーバに報告することができる。ＤＩＭＳベースのＱｏＥメトリクスは、クライアントからサーバへのＱｏＥ情報の送信に用いられる現在の３ＧＰＰフレームワークに依拠するものである。このような３ＧＰＰフレームワークは、ＰＳＳにおけるユニキャストサービスのためのＲＴＳＰの使用、ＭＢＭＳにおけるマルチキャストサービスのためのＸＭＬオブジェクトを含むＨＴＴＰの使用を含んでいる。
【００５３】
個々の優先度に対する一定期間中に損失したＲＴＰパケットの個数を、下記に従って報告することができる。ＲＴＰシーケンス番号の中断が、失われたパケットを示すと同時に、ブール優先度は、この失われたパケットの重要性が低いか（Ｐ＝０）、又は高いか（Ｐ＝１）を示す。この報告のためのシンタックスは以下の通りである。
Ｌｏｓｔ＿Ｐｒｉｏｒｉｔｙ＝｛Ｘ，Ｙ｝；Ｒａｎｇｅ：＝Ｓｙ−Ｓｚ
【００５４】
上記シンタックスの場合、シーケンス番号がＳｙからＳｚまでの範囲にわたるＲＴＰパケットのセマンティクスに関しては、合計でＸ個の低優先度のパケットが損失し、Ｙ個の高優先度のパケットが損失したことになる。別の実施形態では優先値の変形を用いることができる。
【００５５】
破損シーンを報告するために、クライアントが、シーンのコンテンツから有効なＤＯＭ構造を構築することができなければ、ＤＩＭＳシーンは破損していると識別される。破損シーンを報告するためのシンタックスは以下の通りである。
Ｃｏｒｒｕｐｔｅｄ＿Ｓｃｅｎｅｓ＝｛Ｓ２  Ｎａ，Ｓ７  Ｎｂ｝
【００５６】
上記シンタックスに対応するセマンティクスに関しては、シーケンス番号Ｓ２を有しＮａ個のパケットの間継続するシーンと、シーケンス番号Ｓ７を有しＮｂ個のパケットの間継続するシーンとが破損していることになる。
【００５７】
破損シーンの更新を報告するには、クライアントにおける現在のＤＯＭ構造に更新がなされた後に、クライアントが有効なＤＯＭ構造を構築することができなければ、ＤＩＭＳシーンの更新は破損していると識別される。破損シーンの更新を報告するためのシンタックスは以下の通りである。
Ｃｏｒｒｕｐｔｅｄ＿ＳｃｅｎｅＵｐｄａｔｅｓ＝｛Ｓ５  Ｎｃ，Ｓ２２  Ｎｄ｝
【００５８】
上記のシンタックスに対応するセマンティクスに関しては、シーケンス番号Ｓ５を有しＮｃ個のパケットの間継続するシーンの更新と、シーケンス番号Ｓ２２を有しＮｄ個のパケットの間継続するシーンの更新とが破損していることになる。
【００５９】
本発明の別の実施形態では、破損シーン及び破損シーンの更新の両方に関するメトリクスを組み合わせて、ＤＩＭＳメディアタイプに関する単一の共通メトリクスとすることができる。
【００６０】
上記に加えて、ＤＩＭＳ破損継続時間値を報告することもできる。この値は、破損シーン及びシーンの更新の継続時間により測定される。この値を報告するためのシンタックスは以下の通りである。
ＤＩＭＳ＿Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＝｛Ｓ３  Ｔａ；Ｓ２２  Ｔｂ｝
【００６１】
この例では２つの破損の組が存在する。最初の破損の組における先頭パケットのシーケンス番号はＳ３となり、継続時間はＴａとなる。２番目の破損の組における先頭パケットのシーケンス番号はＳ２２となり、継続時間はＴｂとなる。個々の破損の組は、破損シーンとシーンの更新との組み合わせを含むことができることに留意されたい。
【００６２】
別の例では、ＤＩＭＳ＿Ｃｏｒｒｕｐｔｉｏｎ＿Ｄｕｒａｔｉｏｎ＝｛Ｓ３  Ｔａ；Ｓ２２  ？｝；Ｒａｎｇｅ：＝Ｓｙ−Ｓｚとなる。この例では、最初の破損の組における先頭パケットのシーケンス番号はＳ３となり、継続時間はＴａとなる。２番目の破損の組における先頭パケットのシーケンス番号はＳ２２となる。正確な継続時間が不明な場合には、「？」が挿入される。「？」の指定は、同様に他のメトリクスと共に用いることもできる。加えて、本発明の１つの特定の実施形態では、破損継続時間を示すのに継続時間を用いるのではなく、シーケンス番号を用いることができることに留意されたい。
【００６３】
本発明は、一般的なコンテキストの方法ステップで説明されており、該方法ステップは、ネットワーク環境におけるコンピュータによって実行される、プログラムコードなどのコンピュータ実行可能命令を含むプログラム製品により、１つの実施形態において実行することができる。
【００６４】
一般的にプログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれ、これらは特定のタスクを実行するか、或いは特定の抽象的なデータ型を実装するものである。コンピュータ実行可能命令、それに関するデータ構造、及びプログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表すものである。このような実行可能命令又はそれに関するデータ構造の特定のシーケンスは、上記ステップにおいて説明した機能を実施するための対応動作の例を表すものである。
【００６５】
本発明のソフトウェア及びウェブの実装は、様々なデータベース検索ステップ、相関ステップ、比較ステップ、及び決定ステップを実行するための、規則に基づく論理及びその他の論理を含む標準的なプログラミング技術によって達成することができる。本明細書及び特許請求の範囲において用いられる「コンポーネント」及び「モジュール」という用語は、１又はそれ以上の行のソフトウェアコード、及び／又はハードウェアの実装、及び／又は手動入力を受け入れるための機器を用いた実装を含むことを意図していることにも留意されたい。
【００６６】
例示及び説明の目的で本発明の実施形態についての前述の説明を提示した。上記説明は、本発明を網羅したり、或いは開示された厳密な形態に限定したりすることを意図するものではなく、上記の教示に照らして修正及び変更を行うか、或いは本発明を実施することによりこれらの修正及び変更を習得することができる。上記実施形態は、本発明の原理及びその実際の適用について説明する目的で選択及び説明され、想定される特定の用途に適合する様々な実施形態において、及び様々な修正を伴って、当業者が本発明を利用できるようにするものである。
【図面の簡単な説明】
【００６７】
【図１】本発明を実施することができるシステムの表現図である。
【図２】本発明の実施において用いることができる移動電話の斜視図である。
【図３】図２の移動電話の電話回路を示す概略図である。
【図４】情報の個々の優先度レベルに対する一定期間中に損失したパケットの報告に用いられるＲＴＣＰメッセージを示す図である。
【図５】直近の「アクティブな要素リスト」内にある要素のうちで、正しく受信及び復号化されなかった要素の個数の報告に用いられるＲＴＣＰメッセージを示す図である。
【図６】現在のグループ内でどの要素が正しく受信、復号化され、かつアクティブであるかの報告に用いるＲＴＣＰメッセージを示す図である。
【図７】パケットの１つのグループにわたる破損継続時間を示すために用いるＲＴＣＰメッセージを示す図である。
【図８】それぞれのグループに関するシーンデータのパケット損失に起因して破損したグループを示すために用いるＲＴＣＰメッセージを示す図である。
【符号の説明】
【００６８】
１１  移動電話ネットワーク
１２  移動電話
１６  ＰＤＡ
１８  統合メッセージングデバイス（ＩＭＤ）
２０  デスクトップコンピュータ
２２  ノートブックコンピュータ
２４  基地局
２５  無線接続
２６  ネットワークサーバ
２８  インターネット
【図１】
2010510689.tif 000003
【図２】
2010510689.tif 000004
【図３】
2010510689.tif 000005
【図４】
2010510689.tif 000006
【図５】
2010510689.tif 000007
【図６】
2010510689.tif 000008
【図７】
2010510689.tif 000009
【図８】
2010510689.tif 000010
【国際調査報告】
2010510689.tif 000011
2010510689.tif 000012
2010510689.tif 000013
2010510689.tif 000014