JP2010530155A - リアルタイム通信システムにおけるジッタベースのメディアレイヤアダプテーション - Google Patents

Abstract

基本的な概念は、複数のパケットにわたって測定されるジッタプロファイル特性を判定し（Ｓ１）、判定した特性および送信機と受信機との間の通信で使用されている特定のアクセスを表す情報に基づき、ジッタプロファイルを分類する（Ｓ２）ことである。次いで、分類したジッタプロファイルをメディアレイヤアダプテーションのための適切な動作に適合させることにより（Ｓ３）、メディアレイヤアダプテーションのための適切な動作を開始することができる（Ｓ４）。
【選択図】 なし

Description

本発明は、一般に、リアルタイム通信に関するものであり、より詳しくは、メディアレイヤアダプテーション（media layer adaptation）に関するものである。

どんなリアルタイム通信システムにおいても、トランスポート（transport：伝送）特性の変化を取り入れる必要がある。例えば、インターネットプロトコル（ＩＰ）に基づくデータトランスポートに関しては、このことは、リアルタイムトランスポートプロトコル（ＲＴＰ）［１］を設計する場合に既に明らかになっており、メディアフローが通った経路の特性のポイント・ツー・ポイントでのレポーティング（reporting：報告）を可能にするために、リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）と呼ばれる、付随のレポーティングプロトコルが設計された。ＲＴＣＰレポートでは、いくつかの異なる特性をレポートすることができ、ＲＴＣＰレポートには、非常に大量のデータを収容できる、いわゆる拡張ＲＴＣＰレポート（ＲＴＣＰ−ＸＲ）を使用する対策もある。これらのレポートの受領により、送信側のアプリケーション／ユニットに、その動作を変更させ、利用可能なチャネルリソースをより好適に使用することが可能になる。

リンクスループットまたはエンドツーエンド総合トランスポート特性を保証できない環境で、リアルタイム通信サービスを使用する場合、アプリケーションは、この変化する環境に対処する必要がある。これが行われない場合、セッションは、最適に満たない品質に落ちるか、または最悪の場合打ち切られる可能性がある。このことは、すべての通信ネットワークに関して当てはまり、無線環境は伝送特性についての保証を提供することが事実上不可能であるので、移動通信ネットワークについてはいっそう当てはまる。

このことは、回線交換伝送でもやはり当てはまる。３ＧＰＰの回線交換（ＣＳ）音声サービスで使用される適応マルチレート（ＡＭＲ）音声コーデックには、新しく測定された状況に適応するように、コーデックに対して、信号によるエンドツーエンドのリクエストを行うための手段が存在する。例えば、無線リンクの中の１つリンクのキャリア対干渉比（Ｃ／Ｉ）が一定の閾値以下になる場合、ソース符号化ビットレートを下げ、よりロバストなチャネル符号化を適用するためのリクエストが、通常は、ＡＭＲビットストリームのコーデックモードリクエスト（ＣＭＲ：Codec Mode Request）を使用して、一方のエンドに送信される。

ＩＰ伝送に関しては、ＲＴＣＰがほぼ同じ目的を達成することができるが、いくつかの欠点がある。その中でも主要な欠点は、レポート間の長い遅延であり、これがアプリケーションを主体的というよりむしろ受動的にする。従って、ＲＴＣＰ受信機レポートの使用は、アダプテーションプロセスをかなり遅くすることになる。レポートの情報は使用可能ではあるけれども、それに対するどんな応答も、実際には主体的というよりむしろ受動的なものになる。品質の劣化が既に起こっているであろう。

ＲＴＣＰレポートの応答が遅いことの問題は、引用文献［２］で認識されており、この文献では、受信機における音声パケット損失予測に基づく手順が提案されている。受信機側で音声パケット損失を予測することで、送信機に警告することができる。特に、パケット到着間隔ジッタ（inter-arrival jitter）が各パケットに対して計算され、パケット損失を予測するために、所定の閾値と比較される。到着間隔時間の突然の変化の後に、音声パケット損失のオーバシュートが続くことが予想されている。こうして、パケット毎の単位で到着間隔ジッタをモニタして、到着間隔ジッタが一定の閾値を超えたらすぐに送信機に警告することによって、パケット損失を減少することが可能である。

引用文献［２］に記載の解決手段は、遅いＲＴＣＰレポートメカニズムと比べてかなりの改善を示しているが、この解決手段は、実際のアプリケーションでは、十分に満足する結果を提供するようには思えない。特に、引用文献［２］で提案されているアプローチは、多くのアプリケーションにおいて、はるかに控え目すぎるように見える。

従って、リアルタイムアプリケーションにおけるメディアレイヤアダプテーションのメカニズムを改善する一般的必要性がある。

本発明は、従来技術の解決策の上記および他の欠点を解決する。

本発明の一般的な目的は、リアルタイム通信に関するメディアレイヤアダプテーションのための効率的な方策を提供することである。効率的なメディアレイヤアダプテーションは、当然に、利用可能な伝送リソース／チャネルリソースの効率的使用をもたらすものである。

本発明の一目的は、受動的なアダプテーションでなくむしろ主体的なアダプテーションを行うために、より直接的に対応するメディアレイヤアダプテーションメカニズムを提供することである。メディアレイヤの成り行きが深刻な品質問題をもたらす前に、チャネル劣化を判定する方法を提供することは、明らかに有益であろう。

特に、受信機側でパケット損失を予測する利点をより効果的に利用し、パケット損失を回避する、改善したジッタベースのメカニズムを提供することは望ましい。

本発明の一目的は、リアルタイム通信システムにおいてメディアレイヤアダプテーションを可能にするデバイスを提供することでもある。

上記および他の目的は、添付の特許請求項に規定される本発明によって達成される。

発明者が認識していることは、特定のアクセス技術および／またはアクセスパラメータ設定に関しては、あるジッタプロファイルは正常である場合があり、適応動作を全くトリガすべきでないのに対して、別のアクセス技術および／またはアクセスパラメータ設定に関しては、同一のジッタプロファイルが迅速な適応動作を必要とすることである。従って、パケット毎の単位でジッタを評価する代わりに、好ましくは、複数のパケットにわたる全体のジッタプロファイルが評価されるべきである。さらに、測定されたジッタプロファイルが評価される場合、それが適正な状況に置かれることが重要である。ジッタ測定値（およびパケット損失率）を単独でアダプテーション制御アルゴリズムの基礎にすることは、改善の見込みを幾分かは与えるだろうが、大幅に改善の余地がある控え目な制御アルゴリズムを強いることにもなるだろう。

それゆえ、本発明の基本的な概念は、複数のパケットにわたって測定されるジッタプロファイルの特性を判定し、その判定された特性および送信機と受信機との間の通信で使用される特定のアクセスを表す情報に基づき、ジッタプロファイルを分類することである。次いで、分類したジッタプロファイルを、メディアレイヤアダプテーションの適切な動作に適合させることで、適切な動作を開始することができる。

ジッタプロファイルの分類を判定されたジッタ特性に基づくだけでなく、通信に対して使用されるアクセスについての情報にも基づかせることによって、より多くの情報に基づくメディアレイヤアダプテーションの決定を行うことができ、通信システムで利用可能なリソースの利用の大幅な改善につながる。

好ましくは、アクセス情報は、考慮されているメディアパケットフローに対するアクセスコンフィグレーションについての情報を含み、また、通常は、アクセスタイプについての情報および／またはアクセスパラメータ設定についての情報を含んでいる。無線アプリケーションでは、これは、例えば、使用される無線アクセスタイプについての情報および／または無線ベアラ設定についての情報であってもよい。

本発明の他の態様および利点については、本発明の実施形態についての以下の記載を読むことによって正しく理解されるであろう。

本発明は、そのさらなる目的および利点も含めて、以下の説明を添付図面とともに参照することにより最もよく理解できるであろう。

リアルタイム通信システムにおけるメディアレイヤアダプテーションの方法の概略のフロー図である。 音声に関するエンドツーエンドの遅延変動の一例を示す概略図である。 音声に関するエンドツーエンドの遅延変動の別の例を示す概略図である。 本発明の一実施形態例に従うデータベースコンフィグレーションの原理を示す概念図である。 本発明の一実施形態例に従うデータベースコンフィグレーションの一例を示す概略図である。 本発明の好ましい実施形態例に従う受信機の概略のブロック図である。 ３ＧＰＰ／ＨＳＰＡアクセスタイプによりきめ細かく焦点を合わせた分類プロセスの一例を示す概略のフロー図である。 本発明の一実施形態例に従う、ジッタとパケット損失との関係を推定し、データベースを更新する概略のフロー図である。 本発明の一実施形態例に従う、ジッタ分類、アダプテーションのトリガ、およびデータベース処理の概略のフロー図である。

図面の全部にわたって、同一の参照文字は、対応する要素または類似の要素に使用される。

上述のように、どんなリアルタイム通信システムにおいても、伝送条件の変化を取り入れる基本的必要性がある。

例えば、ＩＰ伝送に関して、ＲＴＣＰ受信機レポートの使用は、メディアレイヤアダプテーションプロセスをかなり遅くする。レポート内の情報は使用可能であるにしても、それに対するどの応答も、実際のところ主体的というより受動的なものになる。品質の劣化が既に起こっているであろう。

広帯域符号分割多元接続（ＷＣＤＭＡ）のＣＳ音声サービスでは、ＡＭＲのインバンドシグナリング（in-band signaling：帯域内シグナリング）が高速エンドツーエンド・シグナリングに使用することができ、アダプテーションのトリガは無線レイヤのＣ／Ｉ測定値から判断される。しかしながら、ＩＰマルチメディアサブシステム（ＩＭＳ）テレフォニーに関しては、これを達成することは難しいかもしれない。第１に、ＩＭＳマルチメディアテレフォニーアプリケーションが下位レイヤとインタフェースすることを可能にする規格の中には、仕様を定められているインタフェースがなく、第２に、インバンドシグナリングは、現在音声コーデックだけを制御している。さらに、ペイロードフォーマットのＣＭＲビットは、音声コーデックモードだけの制御しか許容されていないが、クライアントに対して伝送特性の変化に適応する他の実行可能手段が存在する（例えば、冗長度のオン／オフ、フレームアグリゲーション等）。

全体的に見て、必要なことは、チャネル劣化が深刻な品質問題をもたらす前に、チャネル劣化を測定するメディアにとらわれないやり方である。この測定は、下位レイヤの情報にアクセスする必要なしに実行することが可能となるべきである。しかしながら、このような下位レイヤの情報へのアクセスが存在する場合、測定範囲がさらに広がり、品質に役に立つ可能性はより大きいであろう。本発明は、ＩＰレイヤのようなトランスポートレイヤで利用可能な測定値を超える知識を有する実施形態とそれを有しない実施形態の異なる実施形態を提示する。

トランスポートチャネルは、伝送の基本的特性としてジッタを呈示することを基本的に想定している。ネットワーク、特に、ＩＰネットワークの運用においては、ジッタは、パケットのエンドツーエンドにおける遅延の変動（統計的ばらつき）を通常示すものである。ネットワーク輻輳、局所的な伝送状態、または待ち行列（キューイング：queuing）の問題などの種々の要因のために、パケット間の遅延は、一定ではなく変動することがある。換言すれば、ジッタは、通信のエンドポイントへのパケット配信タイミングの変動と見なしてもよい。変動が大きくなりある閾値を超えると、その結果、パケット損失および／またはメディア（通話）品質の低下が起こることがある。このように、ジッタは、対策を取らないとパケット損失率の増加および／またはメディア品質の低下をもたらすことになる、起こり得る間近に迫ったチャネル品質低下の検出および対策に使用し得る（アプリケーションがトランスポートレイヤ（例えば、ＩＰレイヤ）から利用可能な）基本パラメータである。

本発明について、これより高速パケットアクセス（ＨＳＰＡ：High Speed Packet Access）、ＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、または無線ローカルエリアネットワーク（ＷＬＡＮ：Wireless Local Area Network）のシステム等の無線通信システムを参照して主に説明するが、本発明はそれに限定されない。本発明は、有線システムを含む、ジッタが関係している任意のリアルタイム通信システムに適用されてもよい。

例えば、ＨＳＰＡは、ダウンリンクの高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High Speed Downlink Packet Access）とアップリンクのエンハンスドアップリンク（ＥＵＬ：Enhanced Uplink）との２つのアクセスタイプを含んでいる。ＨＳＤＰＡは、ＷＣＤＭＡに対して機能強化したものでであり、より高いデータレートへの円滑で漸進的な経路を提供する。ＨＳＤＰＡは、３ＧＰＰのリリース５で仕様が定められており、高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ：High-Speed Downlink Shared Channel）等の追加のトランスポートチャネルおよび制御チャネルを含んでいる。ＥＵＬは、３ＧＰＰのリリース６で仕様が定められており、エンハンスド専用チャネル（Ｅ−ＤＣＨ：Enhanced Dedicated Channel）などの追加の伝送チャネルおよび制御チャネルを含んでいる。

これらのリンクは、固有のジッタ属性、すなわち、ＩＰエンドポイントへのパケット配信タイミングの変動属性を有する。このジッタの理由には、基本的には、２つの要素からなる。

第１は、優先順位をもたらす支配的計量値に従って、ＭＡＣ−ｈｓ（高速媒体アクセス制御：Medium Access Control-high speed）送信ブロックをスケジュールするスケジューラがダウンリンクに存在する。ＮｏｄｅＢの送信バッファ長は、ＭＡＣ−ｈｓ送信ブロックの優先順位およびセルの負荷に依存することになる。

第２は、ＨＳＤＰＡもＥＵＬも高速の下位レイヤ再送信能力を有する。再送信が高速であるので、特に、ＨＳＤＰＡに関しては、通常動作モードでは、その中にほぼ１０％もの再送信を含んでいる。アプリケーションレイヤ上のＩＰパケットの受信時間を測定することによって、配信タイミングが変動することを見てもよい。これは、通常動作モードであり、異常ではないことに注目すべきである。ある意味では、これは、通常動作の固有の特徴である。

これら２つの事情の両方とも、セル輻輳が存在する場合、すなわち、ダウンリンクのスケジューラが高負荷で動作している（ＮｏｄｅＢの長い待ち行列（キュー）になる）場合、または受信側のユーザ端末（ＵＥ）の局所的な電波状態によってＮｏｄｅＢが数回の再送信を強いられる場合、より大きなジッタをもたらすことになるであろう。これは、トラフィック状況が悪化する場合に、ユーザ装置（ＵＥ）がより多量のジッタに直面するであろうことを意味する。ＮｏｄｅＢのバッファが一杯になると、または、再送信の量がある閾値を上回ると、パケットは欠落することになり、パケット損失率が増加するであろう。

ジッタ特性の変化（例えば、ジッタの振幅の増加または減少する場合）がＵＥで検出される場合、この変化は、基礎をなすチャネル特性の変化と見なしてもよく、パケット損失の確率が増加しているまたは減少していることを暗示している。次いで、ＵＥはこの入力情報に基づいて動作し、そして、セッションで使用されているメディア特性に適応するように送信者にリクエストを送信することができる。ジッタが減少する場合、その結果として、パケット損失確率が低下して、チャネルが改善されていると見なしてもよい。従って、ジッタの減少は、ＵＥがより高いビットレートまでに適応し、ビットストリームの復元措置を取り去ることができることを示すことになる。

大規模な実験／シミュレーションおよび注意深い分析の後に、本発明者たちが認識したことは、特定のアクセス技術および／またはアクセスパラメータ設定に関しては、あるジッタプロファイルは正常なことがあり、適応動作（adaptive action：アダプティブアクション）をトリガすべきでないのに対して、別のアクセス技術および／またはアクセスパラメータ設定に関しては、同一のジッタプロファイルが迅速な適応動作を必要とすることである。従って、パケット毎の単位でジッタを評価するのではなく、好ましくは、複数のパケットにわたって測定されるジッタプロファイルが評価されるべきである。さらに、測定されるジッタプロファイルが評価される場合に、それを適正な状況に置くことが重要である。アダプテーション制御アルゴリズムをジッタ測定値（およびパケット損失率）だけに根拠を置くと、はるかに控え目すぎる制御アルゴリズムを提供することになるであろう。

図１の例示のフロー図に示されているように、複数のパケットにわたって測定されるジッタプロファイルの特性を判定し（Ｓ１）、判定される特性、および送信機と受信機との間の通信に対して使用される特定のアクセスを表す情報に基づいて、ジッタプロファイルを分類する（Ｓ２）ことを提案している。次いで、分類されるジッタプロファイルをメディアレイヤアダプテーションのための適切な動作に適合して（Ｓ３）、適切な動作を開始することができる（Ｓ４）。

ジッタプロファイルの分類を、判定されるジッタ特性に基づくだけでなく、通信に対して使用されるアクセスについての情報にも基づいて行うことによって、はるかに多くの情報に基づいたメディアレイヤアダプテーションの決定を行うことができ、これは、通信システムにおいて利用可能なリソースの大幅な利用改善をもたらすことになる。

加えて、本発明は、間近に迫ったパケット損失率の増加を適切な時期に検出する可能性を維持することで、セッション品質を最適化するために受信機が主体的に振る舞うことを可能にする。これは、セッションを本来の意図される品質に回復することを試行する場合に、すなわち、上方アダプテーションを実行する場合も有効である。

符号化ビットレート、パケットレートまたは復元措置の引き下げリクエストがパケット損失統計に基づいている場合、メディアフローにダメージが既に与えられていて、措置が取られた後に状況は改善するであろうが、ユーザは品質低下としてこのダメージを感じることになる。本発明では、ユーザがパケット損失による品質低下を感じる前に、ジッタ量の増加によってこの対応をトリガすることになるが、上方のジッタバッファアダプテーションによって強要されるより長いエンドツーエンド遅延のためにいくらかの通話品質低下が起こるかもしれない。しかしながら、いずれにせよこの低下は存在するが、パケット損失率の増加に比べてはるかに目立たない品質問題をもたらすであろう。

本発明をよりよく理解する上で、実践感覚を得るためにジッタプロファイルを考慮することは役に立つことがある。例えば、典型的なＨＳＰＡチャネルのエンドツーエンドの遅延変動（すなわち、ジッタ）が図２に示されている。特に、図２は、アップリンクに、２ｍｓの送信時間間隔（ＴＴＩ）を有するＥ−ＤＣＨ、パケット交換コアネットワーク伝送、およびダウンリンクに優先順位スケジューラを有するＨＳＤＰＡを使用した、音声の遅延変動の一例を示している。図から分かるように、正常な動作状態でも常に存在する典型的な基準ジッタが存在する。しかしながら、再送信が増加する場合、または、ＮｏｄｅＢのバッファが最大限に使用される場合、ジッタが増加し、エンドツーエンド遅延の固定的な部分も増加する。これは、図３に示されており、図３は、より高いパケット損失率を有するより厳しいジッタプロファイルを示している。ゼロへの落下は、パケット損失を示している。

種々のアクセスコンフィグレーション（configuration：構成）に対するジッタおよびパケット損失（場合によっては、他の品質パラメータ）をモニタし、数的指標（metric：メトリック）間の相関関係を推定することによって、様々なチャネル状態、およびより重要なことに様々なメディアアダプテーション動作にマッピングし得る、様々なアクセス依存ジッタ動作を反映するデータベースを構築することができる。図４は、本発明の一実施形態例に従うデータベース構成の原理を示している。図４に示されている例示のデータベース１００は、いくつかのいわゆるアクセスカテゴリ、いくつかの異なるタイプのジッタ特性、および対応するメディアレイヤアダプテーション動作／措置を含んでいる。アクセスカテゴリは、例えば、アクセスタイプおよび／またはアクセスパラメータ設定によって定義されてもよい。

いくつかの異なるジッタタイプが存在し、その特性は、通信に対して使用されるアクセスコンフィグレーション（構成）に少なくとも一部は依存することになる。好ましくは、測定されたジッタプロファイルの分類は、考慮しなければならない、異なるジッタタイプの数を削減するために、アクセス情報に基づき第１レベルの分類を行うことから始まる。次に、例えば、使用されているアクセスに対して固有の様々な所定のタイプのジッタプロファイルのセットとの比較によって、ジッタプロファイルの第２レベルの詳細分類が行われる。

データベースには、いくつかの異なるアクセスカテゴリのそれぞれに対して、様々な所定のタイプのジッタプロファイルのセットが、対応するメディアレイヤアダプテーション動作についての情報とともに記憶されている。アクセスカテゴリの情報に応じて、このようにして、様々な所定のタイプのジッタプロファイルのセットがデータベースで検出することができ、次いで、判定されたジッタプロファイル特性は、適切な分類を行うために、アクセス固有のタイプのジッタプロファイルの対応する特性と比較することができる。

好ましくは、ジッタプロファイル特性は、測定されたプロファイルの少なくともパケットのサブセットにわたる時間的進展（time evolution）を表している。実際には、ジッタプロファイルは、代表的なキーインジケータによって、またはパラメータ群を定義することによって特徴付けられてもよく、このパラメータ群には、ジッタ振幅進展（jitter amplitude evolution）（「ジッタ派生物（jitter derivative）」）、ジッタ進展率（rate of jitter evolution）、平均ジッタスパイク率、平均ジッタスパイク振幅、パケット損失との関係等を含み得る。広範囲の異なるキーインジケータが想定されてもよい。

通信のために使用されている特定のアクセスに関して、ジッタがチャネルの当然の部分であるかどうかを予測するために、複数のパケットにわたってどのようにジッタが進展するかについて、選択された情報を使用することが望ましい。

種々のジッタのタイプには、例えば、スパイクだらけ（spiky：スパイク状）のジッタ特性、バースト的なジッタ特性、および／または段階的に変化するジッタ特性を含んでもよい。

適応動作は、例えば、拡張チャネル符号化と組み合わせられるソース符号化率の変更、オフセットと組み合わせられるロバスト性の改善のためのエラー復元措置、および／またはフレームアグリゲーション（frame aggregation）または他の任意の適切な復元措置を含んでもよい。

送信機と受信機との間の通信のために使用されているアクセスを示す情報は、通常は、アクセスカテゴリ、または単にアクセスコンフィグレーション（構成）と呼ばれ、例えば、アクセスタイプもしくはアクセス技術および／またはアクセスパラメータ設定についての情報を含んでもよい。無線アプリケーションでは、これは、例えば、使用されている無線アクセスタイプについての情報および／または無線ベアラ設定についての情報でもよい。例えば、異なる無線アクセスタイプ、およびあるアクセスタイプ内の異なる種類の無線リンクの実現は、異なるジッタ特性を示すことになる。この情報は、ジッタプロファイルを評価し、メディアレイヤアダプテーションのための適切な動作を判定する場合に考慮されるべきである。異なる種類の無線リンク実現は、異なる無線ベアラ（ＲＡＢ）が考慮される場合のＱｏＳ（サービス品質）設定と呼ばれることが多い。

図５は、本発明の一実施形態例に従うデータベースコンフィグレーションの一例を示す概略図である。この例では、異なる３つの無線アクセスタイプであるＷＬＡＮ、ＧＳＭおよびＨＳＰＡが考慮されている。適用できる場合には、異なるアクセスカテゴリを区別するために、無線ベアラ設定も使用される。

例えば、ＷＬＡＮアクセスタイプに関しては、１つ以上のキーインジケータのセットに定量化されている、異なる特徴を有する、いくつかの異なるジッタプロファイルが予め定められていてもよい。この例では、３つの異なるタイプのジッタプロファイルが、異なる間隔のキーインジケータセットを用いて定義されている。各タイプのジッタプロファイルは、データベースの中で対応する動作に適合される。従って、ＷＬＡＮアクセスタイプが使用され、かつ測定されるジッタプロファイルのキーインジケータの所与のセットがそれぞれの間隔（例のために）０〜５０ｍｓ、０〜１００ｍｓおよび０〜５ｍｓにある場合、ジッタは動作を行う必要のない特定のタイプのジッタに分類されることになる。しかしながら、他方、キーインジケータがそれぞれの例示の間隔５０〜７５ｍｓ、０〜１００ｍｓおよび５〜（すなわち、５以上）ｍｓの中にある場合、パケットサイズの減少等のメディアレイヤアダプテーションを必要とする別のタイプのジッタを扱っている。最後に、キーインジケータがそれぞれの例示の間隔７５〜ｍｓ、１００〜ｍｓ、および５〜ｍｓにある場合、冗長度の増加等のメディアレイヤアダプテーション動作を必要とする、また別のタイプのジッタを有している。

ＧＳＭアクセスタイプに関しては、無線ベアラ（ＲＡＢ）とも呼ばれる、異なるＱｏＳ設定が存在してもよい。この例では、各無線ベアラに対して、メディアレイヤアダプテーションに対する対応の動作を有するいくつかの異なるタイプのジッタプロファイルがあってもよい。ＷＬＡＮの場合と同様に、所定のタイプのジッタプロファイルそれぞれは、特定のメディアレイヤアダプテーション動作に関連付けられている。

ＨＳＰＡアクセスタイプに関しては、無線リンク制御−未確認応答モード（ＲＬＣ−ＵＭ：Radio Link Control-Unacknowledged Mode）および無線リンク制御−確認応答モード（ＲＬＣ−ＡＭ：Radio Link Control-Acknowledged Mode）のような、異なるＱｏＳ設定またはＲＡＢが存在してもよい。例えば、ＲＬＣ−ＵＭのＨＳＰＡに対して、このデータベース１００の特定の例では、２つの異なるタイプのジッタプロファイルが存在する。各プロファイルは、例示のキーインジケータ値のセットによって定義され、アダプテーションに対する対応する動作に関連付けられている。「正常」で示されている動作は、アダプテーションが必要とされないことを意味する。

特定の無線ベアラで測定されたあるジッタプロファイルは、正常であることがあるので、適応的動作をトリガすべきでないのに対して、別のアクセス技術または無線ベアラ設定においては、同一のジッタプロファイルが、迅速な適応動作を必要とするであろう。従って、測定されるジッタプロファイルが評価される場合、それを適正な状況に置くことが重要である。これは、アクセス技術／アクセスタイプおよび／またはアクセスパラメータ設定等のアクセスコンフィグレーションについての情報を考慮することによって実行される。

図６は、本発明の好ましい実施形態例に従う、受信機の概略のブロック図である。従来のトランシーバ機能とは別に、受信機２００は、ジッタを測定するためのモジュール２１０、ジッタプロファイル特性を判定するためのモジュール２２０、分析モジュール２３０、およびアダプテーション動作を開始するためのモジュール２４０をさらに備える。ジッタは、任意の適切な従来の手段を用いてモジュール２１０で測定される。複数の受信パケットにわたって測定されるジッタプロファイルの適切な特性が、モジュール２２０で判定される。次いで、ジッタプロファイルの特性は、分類のために分析モジュール２３０に転送される。分析モジュール２３０は、適切に構成されているデータベース２３２を中心に、ジッタを分類し、分類したジッタを適切なアダプテーション動作に適合させるための関連のモジュール２３４、２３６を加えて構築されている。分析モジュール２３０は、考慮している通信で使用されているアクセスコンフィグレーションについての情報も受信する。無線システムでは、移動受信機が、ネットワークから、通信用のリソースを通常リクエストする。このリソースには、ＲＡＢなどの無線アクセスパラメータ設定を含んでもよい。次いで、ネットワークは、実際のリソース割当を実行し、かつ移動受信機からリクエストされている設定を受け付けてもよいし、また、それを変更してもよい。ネットワークは、通信に使用するワイヤレスアクセス／無線アクセスについての情報を含む、割り当てられたリソースについての情報を移動受信機に送信する。従って、無線アクセスについての情報は、移動端末で利用可能であり、ジッタプロファイルの分類で使用され得る。受信機は、必要な動作について送信機に通知するリクエストを送信機に送信することによって、または少なくとも送信機にそのような動作を開始するために必要な情報を提供することによって、適応動作を開始することが好ましい。

本発明の好ましい実施形態例では、ジッタ振幅の進展が、データベース２３２の様々なチャネル特性と比較される。分類機能は、無線ベアラタイプなどのＱｏＳ属性および／または無線アクセスタイプを考慮して、現在のチャネル特性が適応動作を必要とするかどうかを判定する。そのような動作が必要と見なされる場合、例えば、ソースビットレートもしくはソースパケットレートを減少するように、またはパケット損失に対してビットストリームをよりロバストにする復元措置を強要し、好ましくは観察される遅延ジッタの増加原因を取り除き、チャネルがさらに劣化する危険を減少させるために、リクエストが送信機に送信されることが好ましい。このリクエストは、例えば、ＲＴＰパケットなどのペイロード固有フィールドを使用してインバンド（in-band：帯域内）で、または、例えば、ＲＴＣＰのアプリケーション固有のレポートフォーマットなどを使用してアウトオブバンド（out-of-band：帯域外）で送信することができる。選択的には、ジッタ特性についての情報は、分析および分類のために送信機に送信される。

図７は、３ＧＰＰ／ＨＳＰＡアクセスタイプにより詳細に焦点を合わせた分類プロセスの一例を示す概略のフロー図である。この例では、この分類は、無線アクセス技術／無線アクセスタイプから開始する。この場合、データベースは、ＷＬＡＮ、３ＧＰＰ／ＨＳＰＡ、３ＧＰＰ／ＥＤＧＥおよびＷｉＭＡＸを含む様々なアクセスタイプに関する情報を用意している。使用されているアクセスタイプがＨＳＰＡであると判断される場合、分類は、続いて、どの無線ベアラ設定が使用されているかを判定するためにＱｏＳパラメータを読み取ることによって、継続する。この例では、２つの基本的なＲＡＢであるＲＬＣ ＵＭとＲＬＣ ＡＭがあり、それぞれが３つの異なる所定のタイプのジッタプロファイルを有している。

リアルタイム通信サービス用の効率的な無線ベアラは、ＲＬＣ未確認応答モード（ＲＬＣ−ＵＭ）であり、これは、ＭＡＣレイヤだけで再送信を行い、ＲＬＣレイヤでは再送信を行わない。一方、ＲＬＣ確認応答モード（ＲＬＣ−ＡＭ）は、ＲＬＣレイヤでも再送信を行い、それが起こると、非常に短期間であるが大幅なジッタ増加をもたらすことになる。この場合、ジッタスパイクは、正常であり、同様に、正常運転状態で考慮されるべきであり、従って、この動作は、パケット損失確率の増加が差し迫っていることを示すはずがない。一方、ＲＬＣ−ＵＭの同様のジッタスパイクは、パケット損失が間近に迫っていることを示す傾向がより強くなる。

図７を参照すると、ＨＳＰＡのＲＬＣ ＡＭに関して、高いが、例えば、２００ｍｓ〜４００ｍｓ程度のジッタスパイクが比較的たまにしか起こらない、通常の基線が存在する場合、これは、第１の所定のジッタタイプ（正常）に対応する可能性があり、このジッタタイプは、パケット損失のリスクが低いことを示している。従って、適応動作は必要とされない。

ＨＳＰＡのＲＬＣ ＵＭに関しては、ジッタの大幅な増加（例えば、４０ｍｓ〜１００ｍｓ）はあるがジッタスパイクのないジッタプロファイルが存在する場合、これは、第３の所定のジッタタイプに対応する可能性があり、このジッタタイプは、パケット損失のリスクが高いことを示している。これは、パケット損失を回避するために、適応動作が必要とされることを意味する。ＲＬＣ ＡＭに対するジッタ振幅は、適応動作を必要とすることなく、時には、ＲＬＣ ＵＭに対するジッタ振幅をはるかに超えることに注目すべきである。

比較のために、パケット損失に対するリスクが比較的低いことを示す、ＲＬＣ ＵＭに対する第１の所定のジッタプロファイル（正常）を考慮されたい。

以下では、ジッタとパケット損失の関係についていくつかの例を説明する。これが、例えば、ビットレート、パケットレートおよび他の復元措置などのアダプテーションにどのように影響を及ぼすことがあるかについても説明する。

遅延スケジューラおよび未確認応答モード
遅延スケジューラは、送信キューの中で長時間遅れているパケットを廃棄する。長いキューイング遅延が、いくつかの理由で発生することがある。

１．チャネル状態が良好と劣悪との間で変化する移動中のＵＥ
良好なチャネル状態に関しては、ジッタは、おそらく少なく、パケット損失はほとんどない。劣悪なチャネル状態に関しては、複数回の再送信が必要とされ、それが、長い遅延をもたらし、おそらくパケット損失率も高くする。ＵＥがフェージングの落ち込みに入りそして出て行くので、良好と劣悪との間のチャネル状態の遷移はかなり急速であることが予想できる。特性は、おそらく、以下のように変わる。

ａ．ジッタが小さくパケット損失がない期間
ｂ．ジッタが増加しているが、パケット損失がない短い期間
ｃ．ジッタもパケット損失も大きい期間
ｄ．ジッタが減少しておりパケット損失がない短い期間
ｅ．ジッタが小さくパケット損失がない期間
次いで、プロセスは、ａからのプロセスを（多かれ少なかれ、周期的に）繰り返す。

主に、シングルパケット損失（single-packet loss）に直面することを予想することができる。その理由は、スケジューラが、各ＭＡＣ−ｈｓブロックの中で１つのＲＬＣタイプ・パケットデータユニット（ＰＤＵ）（＝１パケット＝１音声フレーム）だけをおそらく送信するからである。

２．高システム負荷であるが良好なチャネル状態
この場合は、スケジューラが、おそらく、いくつかのＲＬＣ ＰＤＵ（＝複数のパケット＝複数の音声フレーム）を各ＭＡＣ−ｈｓ送信ブロックの中にカプセル化しているだろうから、パケット損失が集中的に現れることを予想することができる。パケット損失がバースト的に現れる理由は、各ユーザが比較的まれに（フレームの繰り返し頻度よりはるかに少なく）スケジュールされるからであり、このことは、ユーザがスケジュールされる場合に、キューの中にいくつかの送信ブロックが存在するであろうことを意味する。

第１の事例（１）に関しては、最善のアダプテーション措置は、パケットサイズ、例えば、符号化ビットレートを削減することである。その理由は、こうすることにより、ＭＡＣ−ｈｓ送信ブロックのチャネル符号化により大きな余地を与えるからである。しかしながら、主要な問題は送信ブロックのサイズであるので、フレームアグリゲーションは望ましくない。エラー復元措置は、送信ブロックのサイズを維持するが、役立つことがある。遷移期間、特に、ｂは、期間ｃの問題が検出される前に、アダプテーションのトリガを可能にするように、十分長くすることができる。しかしながら、これは、おそらく、ＵＥの速度に依存することになる。

第２の事例（２）に関しては、ビットレートの削減はかなりうまく働く。フレームアグリゲーションは、おそらく、注目に値する改善をもたらさないであろう。冗長度は、オフセットと組み合わされる場合に、通常は、品質を改善することになる。

ＩＰレイヤでの措置とそれより下位レイヤからの追加の知識、および以前の統計を統合ＵＥデータベースに組み込むことによって、ＵＥに対して、現在のチャネル動作に関して適切な適応措置をリクエストすることが可能になるであろう。

確認応答モードを有するＲＡＢ
ＲＡＢが確認応答モードを使用する場合、ジッタ量に関係なく、パケット損失はほとんど全くないであろう。この場合、復元措置は適用できない。この場合、ＭＡＣ−ｈｓ送信ブロックのチャネル符号化に対してより大きな余地があるので、最善のアダプテーション措置はＰＤＵのサイズを削減することである。

確認応答モード（ＲＬＣ ＡＭ）が使用される場合、ＲＬＣレイヤでの再送信が発生すると、１００ｍｓ〜２００ｍｓ程度の遅延のスパイクが存在することになるであろう。この場合、ジッタの増加はリンクパケット損失が間近に迫っていることを示すと見なすことができないので、エラー復元適応措置はおそらく上手くいかないであろう。他方ビットレートの減少は通常は状況を改善するであろう。その理由は、必要な送信電力量が減少され、下位レイヤでのチャネル符号化により多くの努力を費やし得るからである。

パケット損失の測定値が組み合わされている遅延スパイクの検出値が、ＲＬＣ ＡＭ無線ベアラの分類子としての機能を果たしてもよく、次いで、ＵＥリンク特性データベースに記憶される。

これは、ＱｏＳ属性（無線ベアラタイプを含む）の知識がアダプテーション制御に追加の制御を提供する一例でもある。

本発明のさらなる態様では、性能を向上するために、どのタイプのスケジューラが使用されるかについての情報にも基づき、ジッタプロファイルを分類することが可能である。

ＨＳＰＡ等の多くの無線アクセスタイプに関して、ダウンリンクのスケジューラは独自仕様であり、ＵＥは、現在のシステムのスケジューラがもたらす特性に適応する必要がある場合がある。これらの特性は、特定のチャネルが劣化する場合に見られる特徴と似ていることがあり、それゆえ、チャネルの正常な状態は、異なるスケジューラ実装間でたいてい静的でないことに注目すべきである。様々なスケジューラのジッタ特性およびパケット損失をモニタし、かつ２つの数値指標間の相関関係を推定することによって、正常なチャネル状態をマッピングし得る様々なスケジューラ動作も含むデータベースが構築されてもよい。従って、適応措置をトリガする基準は、時間とともにおよび異なるスケジューラを使用する異なるセル間で変更されても良い。

例えば、ラウンドロビンスケジューラでは、各ユーザは、Ｎミリ秒毎にスケジュールされる。数値Ｎはどのくらい多くのユーザがアクティブであるかに依存する。低負荷に関しては、Ｎはフレーム長以下であり、この場合、スケジューラは主にシングルパケットを送信することになる。負荷が増加すると、Ｎも増加し、スケジューラは、各ＭＡＣ−ｈｓブロックの中に２つ、３つ、またはそれ以上のＲＬＣ ＰＤＵを詰め込むことを開始する。これは、シングルパケットの損失の数を減らし、２連、３連等のパケットの損失を増加する。この場合、例示の適切な適応措置は、符号化ビットレートを削減することである。エラー復元措置はどれも、それが効果的であるためには、好ましくは、損失バースト長（loss burst length）に及ぶほど十分大きなオフセットと組み合わされるべきである。

本発明の一実施形態例では、スケジューリング動作についての知識がＵＥデータベースに記憶され、適切な適応動作をトリガするために使用される。

本発明のまた別の態様では、メディアレイヤアダプテーション動作の結果および／またはコストが評価され、また、データベースの情報を更新するために使用される。典型的には、評価に応じて、データベースの中の、１つ以上の所定のタイプのジッタプロファイルについての情報および／またはメディアレイヤアダプテーション動作についての情報が更新される。この評価は、パケット損失に関してメディアパケットフローの品質の変化を、おそらく通話品質の変化とともに考慮してもよい。例えば、ハイレイテンシー（high latency）（通話の遅延）を回避するために、低レベルから中レベルのパケット損失が受け入れられてもよい。

例えば、アダプテーションの閾値（群）は、特定のジッタ動作に対して従前に検討されている動作を使用して適応されてもよい。適応措置が取られる場合、適応動作がチャネル特性を改善しているかどうかを推定するために、品質評価（およびオプションで、アダプテーションのコスト評価も）が実行され、それぞれの適応動作とともに様々なアクセスコンフィグレーションおよび／またはスケジューラ動作に関して、結果がデータベースに記録される。アダプテーションのコストは、例えば、アダプテーションに費やされているリソース量に関して推定されてもよい。従って、メカニズムの性能は、時間とともに向上してもよい。音声および映像を含むパケット交換伝送を使用する、任意のメディアに関しても、同一の原理が使用されてもよいことが理解されるべきである。

一般に、性能が良い場合（正常なチャネル状態）、アダプテーションは回避される。動作状態が悪化するにつれ、アダプテーションがますます活発になるが、このアダプテーションからの利益を得るのはＵＥに対してだけである。これは、ＵＥ内部のチャネル特性データベースの使用によってさらに強化される。さらに、改善をもたらすアダプテーション措置だけを使用することは有利である。いくつかの異なる手段（ビットレート削減、パケットレート削減および／または復元措置）によってアダプテーションを実行することが可能である場合、少しも改善をもたらさない手段を省くことは有益であり、また、そうすることにより、正常かつ有用な手段に対してより迅速なアダプテーションを与える。

図８は、本発明の一実施形態例に従う、ジッタとパケット損失との関係の推定およびデータベースの更新に関するオプションの概略のフロー図である。この手順は、デフォルト設定に基づき、またはチャネル特性と正常なアダプテーション措置のＵＥデータベースを使用することによって、様々なアクセスコンフィグレーションに対する、アダプテーションのための初期閾値およびジッタとパケット損失との関係の設定から通常開始される（Ｓ１１）。ジッタおよびパケット損失の統計が（場合によっては、他の品質パラメータとともに）測定され（Ｓ１２）、ジッタとパケット損失との関係が、いくつかのアクセスコンフィグレーション、および場合によってはスケジューラ動作のそれぞれに対して計算される（Ｓ１３）。この関係が有効であると見なされる場合（Ｓ１４、ＹＥＳ）、手順は、ジッタおよびパケット損失をモニタすることを継続する。妥当と見なされない場合（Ｓ１４、ＮＯ）、ジッタとパケット損失との新規の関係が使用されることになり（Ｓ１５）、それに応じて、アダプテーション閾値が変更される場合がある（Ｓ１６）。

図９は、本発明の一実施形態例に従うジッタ分類、アダプテーショントリガおよびデータベース処理の全体の概略のフロー図である。この特定の例では、ＲＴＰを使用する無線通信ネットワークを考慮している。好ましくは、ＲＴＰストリームのジッタ振幅がモニタされる（Ｓ２１）。ジッタが分析され、また、無線アクセスタイプおよび／またはＱｏＳ設定を考慮して、ジッタベースのチャネル特性が分類される（Ｓ２２）。次いで、適合するジッタプロファイルを検出するために、データベースが検索される（Ｓ２２／Ｓ２３）。チャネル測定値をデータベースの中に検出することができる場合（Ｓ２４、ＹＥＳ）、適合するアダプテーション動作がデータベースから選択され、送信機に信号で送信される。

オプションで、適応動作後に品質の改善（パケット損失および／または通話品質）が測定され（Ｓ２６）、ＵＥデータベースの適切な更新を可能にする（Ｓ２７）。チャネル測定値をデータベースの中に検出することができない場合（Ｓ２４、ＮＯ）、他の（従来の）手段によるアダプテーションが必要されるかどうかが、通常は評価されなければならない（Ｓ２８）。これは、例えば、簡単な閾値メカニズムに基づく等の、通常は、ある程度大まかで基本的な評価である。アダプテーションが必要とされない場合（ＮＯ）、プロファイルは、「正常」プロファイルとしてデータベースに記憶される。アダプテーションが必要とされる場合（ＹＥＳ）、適切な動作が選択され、送信機に信号で送信されることが好ましい（Ｓ２９）。次いで、適応動作後に、品質の改善（パケット損失および／または通話品質）が測定されて（３０）、再度、ＵＥデータベースの適切な更新を可能にしてもよい（Ｓ２７）。

本発明は、無線アプリケーションおよび無線システムに主に焦点を当てているが、本発明はこれに限定されず、有線システムも含む、ジッタがあり、かつアクセスタイプおよび／またはアクセスパラメータ設定が受信機側で既知または利用可能である、任意のリアルタイム通信システムに適用されてもよい。

上記の実施形態は単に例として与えられており、本発明はこれらに限定されないことが理解されるべきである。本明細書で開示され、および請求されている基本的な根本原理を維持するさらなる修正、変更および改善は、本発明の範囲内にある。

＜引用文献一覧＞
［１］ 「ＲＴＰ：リアルタイムアプリケーション用のトランスポートプロトコル（ＲＴＰ：Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ）」、ＲＦＣ ３５５０、２００３年７月
［２］ 「ジッタフィードバックに基づく音声パケット損失の予測および回避用のアルゴリズム（Ａｌｇｏｒｉｔｈｍ ｆｏｒ ａｕｄｉｏ ｐａｃｋｅｔ ｌｏｓｓ ｐｒｅｄｉｃｔｉｏｎ ａｎｄ ａｖｏｉｄａｎｃｅ ｂａｓｅｄ ｏｎ ｊｉｔｔｅｒ ｆｅｅｄｂａｃｋ）」、Ｒｅｓｅａｒｃｈ Ｄｉｓｃｌｏｓｕｒｅデータベース番号４２９０５６、２０００年１月

Claims (29)

1. 少なくとも１つの送信機と受信機を有するリアルタイム通信システムにおけるメディアレイヤアダプテーションのための方法であって、
   前記受信機で、前記送信機と前記受信機間のメディアパケットフローで送信される複数のパケットにわたって測定されるジッタプロファイルの特性を、判定するステップと、
   前記送信機と前記受信機間の通信に対して使用されるアクセスを表す情報と、判定された前記ジッタプロファイルとの特性に基づいて、前記ジッタプロファイルを分類するステップと、
   分類された前記ジッタプロファイルを、メディアレイヤアダプテーションに対する適切な動作に適合するステップと、
   前記送信機と前記受信機間の前記メディアパケットフローに適応させるために、前記動作を開始するステップと
   を備えることを特徴とする方法。
2. 前記分類するステップは、
   前記アクセスを表す情報に基づいて、第１レベルの分類を行うステップと、
   前記使用されるアクセスに対して固有の異なる所定のタイプのジッタプロファイルのセットとの比較によって、前記ジッタプロファイルの第２レベルの詳細分類を行うステップと
   を備えることを特徴とする請求項１に記載の方法。
3. 前記分類するステップは、アクセスの異なるカテゴリそれぞれに対して、異なる所定のタイプのジッタプロファイルのセットが、対応するメディアレイヤアダプテーションに対する動作についての情報ととも記憶されているデータベースを使用することを含む
   ことを特徴とする請求項２に記載の方法。
4. 前記カテゴリのそれぞれは、少なくとも１つの無線アクセスタイプと、無線アクセスパラメータ設定を含む無線アクセスコンフィグレーションによって定義されている
   ことを特徴とする請求項３に記載の方法。
5. 前記分類するステップは、
   前記アクセスを表す情報に応じて、前記データベース内の異なる所定のタイプのジッタプロファイルのセットを検出するステップと、
   適切な分類を行うために、判定された前記ジッタプロファイルの特性と、前記アクセスに対して固有のタイプのジッタプロファイルの対応する特性とを比較するステップと
   ことを特徴とする請求項３に記載の方法。
6. アクセスの少なくとも１つのカテゴリに対して、前記異なる所定のタイプのジッタプロファイルは、スパイク状のジッタ特性、バースト的なジッタ特性、段階的に変化するジッタ特性の少なくとも１つを含む
   ことを特徴とする請求項５に記載の方法。
7. 前記動作は、ｉ）拡張チャネル符号化と組み合わせられるソース符号化率の変更、ｉｉ）オフセットと組み合わせられるロバスト性の改善のためのエラー復元措置、ｉｉｉ）フレームアグリゲーションの少なくとも１つから選択される
   ことを特徴とする請求項５に記載の方法。
8. 前記メディアレイヤアダプテーションの動作の結果を評価するステップと、
   前記評価に応じて、前記データベースの情報を更新するステップと
   を更に備えることを特徴とする請求項５に記載の方法。
9. 前記更新するステップは、前記異なる所定のタイプのジッタプロファイルの少なくとも１つについての情報、及び前記評価に応じた、前記データベース内の、メディアレイヤアダプテーションに対する動作についての情報の少なくとも一方を更新するステップを含んでいる
   ことを特徴とする請求項８に記載の方法。
10. 前記評価するステップは、パケット損失に関する前記メディアパケットフローの品質の変化を評価することを含んでいる
    ことを特徴とする請求項８に記載の方法。
11. 前記評価するステップは、通話品質の変化とともに、パケット損失に関する品質の変化を評価することを含んでいる
    ことを特徴とする請求項８に記載の方法。
12. 判定された前記ジッタプロファイルの特性は、前記複数のパケットの少なくともサブセットにわたるジッタの時間的進展を表している
    ことを特徴とする請求項１に記載の方法。
13. 判定された前記ジッタプロファイルの特性は、ジッタパラメータ値を少なくとも１つ定義することによって表され、前記異なる所定のタイプのジッタプロファイルは、異なる間隔の前記ジッタパラメータ値によって定義される
    ことを特徴とする請求項１に記載の方法。
14. 前記開始するステップは、前記受信機が、前記送信機から前記動作をリクエストするステップを含んでいる
    ことを特徴とする請求項１に記載の方法。
15. 前記分類するステップは、更に、どのタイプのスケジューラが使用されるかについての情報に基づいている
    ことを特徴とする請求項１に記載の方法。
16. 前記リアルタイプ通信システムは、無線システムであり、
    前記アクセスは、無線アクセスである
    ことを特徴とする請求項１に記載の方法。
17. リアルタイム通信システムにおけるメディアレイヤアダプテーションをサポートするためのデバイスであって、
    送信機と受信機間のメディアパケットフローで送信される複数のパケットにわたって測定されるジッタプロファイルの特性を、判定する手段と、
    前記送信機と前記受信機間の通信に対して使用されるアクセスを表す情報と、判定された前記ジッタプロファイルの特性とに基づいて、前記ジッタプロファイルを分類する手段と、
    分類された前記ジッタプロファイルを、メディアレイヤアダプテーションに対する適切な動作に適合する手段と、
    前記送信機と前記受信機間の前記メディアパケットフローに適応させるために、前記動作を開始する手段と
    を備えることを特徴とするデバイス。
18. 前記分類する手段は、
    前記アクセスを表す情報に基づいて、第１レベルの分類を行う手段と、
    前記使用されるアクセスに対して固有の異なる所定のタイプのジッタプロファイルのセットとの比較によって、前記ジッタプロファイルの第２レベルの詳細分類を行う手段と
    を備えることを特徴とする請求項１７に記載のデバイス。
19. 前記分類する手段は、アクセスの異なるカテゴリそれぞれに対して、異なる所定のタイプのジッタプロファイルのセットが、対応するメディアレイヤアダプテーションに対する動作についての情報ととも記憶されているデータベースと協調動作する
    ことを特徴とする請求項１８に記載のデバイス。
20. 前記カテゴリのそれぞれは、少なくとも１つの無線アクセスタイプと、無線アクセスパラメータ設定を含む無線アクセスコンフィグレーションによって定義されている
    ことを特徴とする請求項１９に記載のデバイス。
21. 前記分類する手段は、
    前記アクセスを表す情報に応じて、前記データベース内の異なる所定のタイプのジッタプロファイルのセットを検出する手段と、
    適切な分類を行うために、判定された前記ジッタプロファイルの特性と、前記アクセスに対して固有のタイプのジッタプロファイルの対応する特性とを比較する手段と
    ことを特徴とする請求項１９に記載のデバイス。
22. 前記メディアレイヤアダプテーションの動作の結果を評価する手段と、
    前記評価に応じて、前記データベースの情報を更新する手段と
    を更に備えることを特徴とする請求項１９に記載のデバイス。
23. 前記更新する手段は、前記異なる所定のタイプのジッタプロファイルの少なくとも１つについての情報、及び前記評価に応じた、前記データベース内の、メディアレイヤアダプテーションに対する動作についての情報の少なくとも一方を更新する手段を含んでいる
    ことを特徴とする請求項２２に記載のデバイス。
24. 前記評価する手段は、パケット損失に関する前記メディアパケットフローの品質の変化を評価する手段を含んでいる
    ことを特徴とする請求項２２に記載のデバイス。
25. 前記評価する手段は、通話品質の変化とともに、パケット損失に関する品質の変化を評価する手段を含んでいる
    ことを特徴とする請求項２２に記載のデバイス。
26. 前記開始する手段は、前記送信機から前記動作をリクエストする手段を含んでいる
    ことを特徴とする請求項１７に記載のデバイス。
27. 当該デバイスは、前記受信機に実装されている
    ことを特徴とする請求項１７に記載のデバイス。
28. 前記リアルタイプ通信システムは、無線システムであり、
    前記アクセスは、無線アクセスである
    ことを特徴とする請求項１７に記載のデバイス。
29. 前記受信機は、移動端末である
    前記リアルタイプ通信システムは、無線システムであり、
    前記アクセスは、無線アクセスである
    ことを特徴とする請求項２８に記載のデバイス。

Images