JP4712558B2 - サービス品質監視アーキテクチャー、関連の方法、ネットワーク及びコンピュータプログラムプロダクト - Google Patents

Description

本発明は電気通信ネットワークにおいてサービス品質を監視する技術に関する。本発明は移動通信ネットワークに適用することに特に注意を払いつつ開発した。しかしながら、適用可能なこの特定分野を参照することは本発明の範囲を限定するものと解釈すべきでない。

携帯電話ネットワークの出現とＧＳＭからＧＰＲＳへの及び最近ではＵＭＴＳへの発展により、この分野に出現し又は利用可能な音声、データ、マルチメディアなどのサービスの多様性及び数は、ユーザーの表明するニーズ又はますます競争の激しいマーケットから来るニーズを満たすべく、機能的な特性及び要求性能の両方の点で増大している。

携帯電話サービスのプロバイダにとっては、そのサービスについての定性的ベンチマークを取得できることが、収入に重要な影響を与える「攪乱」現象のみならず成功や市場浸透についての要因にますますなっている。

サービスプロバイダの基本的なニーズである定性的ベンチマークキングの実行は、本質的に以下の能力に関連している：
− できるだけ主観的な知覚に近くなるようにサービス品質を客観的に評価し管理し、
− 重大な局面又は性能低下の原因に焦点を当てて体系的にＱｏＳを測定し、そして
− 他のオペレータと比較できるようにＱｏＳレベルを評価すること。

これらすべてに更に要求されるのは、安い費用で測定できることである。したがってサービスプロバイダが持っていなければならない利用可能なＱｏＳ及び性能データは以下のようなものである：
− （アプリケーションセッションに関し）提供された品質レベルを監視するために、正確で信頼できるデータを有して体系的であり、
− （ユーザー、関係する通信、及び関連の原因と位置情報に関連し得る）品質低下を強調し、トラブルシューティングと改善活動を容易にして推進可能にし、それらをさらにタイムリーかつ効果的に行うために時間どうりであり、
− 計画のためだけでなく、ネットワーク資源（無線アクセス及びコア）の構成及び管理のリアルタイム最適化のため、かつ他のオペレータと比較して競争に立ち向かうためにも使用できるデータを有して具体的であること。

携帯電話サービスのユーザーの場合、通信中の高い品質レベルを獲得できること、同意した契約（ＳＬＡ）に関して品質及び動作レベルの客観的な文書化を行うことは、単なる要件ではなく、透明性の保証でありサービスプロバイダのイメージ要因であり、ユーザーの満足度を増しよってユーザーのサービスプロバイダへの誠実さを強くする。

携帯無線ネットワーク環境（無線資源の限定的な容量、移動性、固定ネットワークとの統合、端末のスクリーン及びキーボードの限定的な大きさなど）やそこで提供されるサービス（例えばローカリゼーション、ＭＭＳ、ビデオストリーミング、マルチメディア）の複雑さと異質性により、通信中に経験する動的に変わり得る品質レベルを正確かつ時間どうりに測定することは困難である。このこともまた事実である。というのは、ユーザーが同意した基準の契約を参照することに加えて、前記品質レベルは、保証された（リクエストされた）品質及び優先度（ＲＳＶＰ、ＤｉｆｆＳｅｒｖなど）の観点から、動的な制御と差別化され洗練されたストリーム管理（３ＧＰＰ ＴＳ ２３．２０７）を行う差別化されたサービス及びトラヒッククラス（会話、ストリーミング、インタラクティブ、バックグランド、例えば３ＧＰＰ ＴＳ ２３．１０７を参照）に基づいたさらに複雑な管理に依存するからである。

提供されるサービス品質の客観的で体系的で時間どうりの評価であってユーザーが知覚する品質にできるだけ近く、単にサービスプロバイダ／オペレータだけでなくユーザー自身も使用できる評価では、リンクの両端（ユーザー端末とアプリケーションサーバ）でのアクセスポイント中やユーザー-端末アプリケーション相互作用（アプリケーションレベル又は場合によっては最高のプロトコル層）中で測定及び性能監視地点がますます分散させられる。

これまで使用されてきた方法及び技術は基本的には以下の事項に基づいていた：
− ハンドオーバー及び無線資源の最適な管理のためにも用いられる典型的には無線アクセスの品質と動作条件についての端末及びネットワーク測定、例えば送信又は受信パワー、ＢＥＲ、スペクトル、アップリンク及びダウンリンクチャンネル上での干渉の測定など（しばしば誤ってＱｏＳ測定と称される）に基づいたＱｏＳ測定及び管理技術（例えばＷＯ−Ａ−０１／１９１１４及びＵＳ−Ａ−６４４９４６４参照）。これらの測定は提示される品質レベルを間接的に高めるが、ユーザーが知覚する品質に関して定量的かつ定性的な意味で品質レベルを直接的に評価することはできない。
− 実トラヒック条件下で、トランスポートレベルの共有ネットワーク及びリンク資源の性能を監視すること（通常はサンプリング又はカウンタで総計を取ることによる内部又は外部手段を用いて携帯無線オペレータにより実行されるが、ほとんど端末を含まず、よって終端間ではなくアプリケーションレベルでもない）。これは前記手段を実際にユーザーが知覚した通信品質と相関させる能力を明らかに制限しており、また、呼及び／又はサービスセッションに基づいてネットワーク内で協調した測定キャンペーン（測定活動）を実行する困難さに由来している。
− 疑似トラヒック条件下で端末及び／又は専門の設備を用いて行われる測定キャンペーン（その特性はユーザーが利用する商用携帯無線端末と必ずしも等価であるとは限らない）。これは明らかに柔軟性と正確さを欠いており、専門家を連続的に雇用し追加のトラヒックも発生させるのでコスト高となる（例えば米国特許出願ＵＳ２００１／００４１５６６、ＵＳ２００２／００７７７８６、ＵＳ２００２／００１５３９８及びＷＯ−Ａ−０１／７２０５８を参照）。及び／又は
− ネットワーク資源の動的管理により実現されるＱｏＳ制御技術。これは例えば米国特許出願ＵＳ２００２／０１４１４４６、ＵＳ２００３／０１１２７６６及びＵＳ２００２／０１８１３９４に記載のようにリクエストされたサービス要件に適合可能である。

このテーマに対する最近のいくつかの貢献を詳細に調べてみると、米国特許ＵＳ-Ａ-６４３４３６４には携帯電話テストソフトウェアエージェント（ＭＴＳＡ）をサポートする通信システムが記載されている。出願人はこのシステムはＧＳＭネットワークにのみ基づいていることに加えて、測定の種類及び測定可能なパラメータに関連したいくつかの制限を有することが分かった。特に、アプリケーションセッションの定性的パラメータ（遅延、ジッター、損失…）、又はセッションの動作条件に関する性能パラメータ（リンクスループット、ＣＰＵ及びメモリの利用レベル、端末バッファ混雑）を得ることができない。システムはアプリケーションセッションの品質測定を行わず、低トランスポート層の無線チャンネルの性能測定のみを行う。監視システムの動作全体はネットワークの機能に統合され、すなわち、携帯無線ネットワークのすべての通常機能を使用する。これにより多重規格環境においてプラットフォームを用いることに問題が生じる。また、このシステムはネットワーク及び端末の負荷条件に適応することができない。

ＳｗｉｓｓＱｕａｌ ＡＧ社（Ｚｕｃｈｗｉｌｌ ＣＨ）の市販製品ＱｕａｌｉＰｏｃに言及することもできる。これは端末構成が手動で行われて監視ソフトウェアがロードされる疑似トラヒック中でのみ動作するシステムであり、実施する測定を設定し又は測定手順を設定することはできない。これは使用中の端末及び／又はネットワーク資源を監視せず、測定値はローカルでダウンロードされ、システムを他の監視プラットフォームと統合する見込みはなく、ＭＭＳサービスでのみ利用可能である。
ＷＯ−Ａ−０１／１９１１４ ＵＳ−Ａ−６４４９４６４ ＵＳ２００１／００４１５６６ ＵＳ２００２／００７７７８６ ＵＳ２００２／００１５３９８ ＷＯ−Ａ−０１／７２０５８ ＵＳ２００２／０１４１４４６ ＵＳ２００３／０１１２７６６ ＵＳ２００２／０１８１３９４

本発明の目的及び概要
本発明の目的は上述した解決策の重要な問題を解決することである。

本発明によると、前記目的は特許請求の範囲に具体的に記載された特徴を有するサービス品質を監視するためのアーキテクチャーのおかげで達成される。本発明はまた関連のネットワーク、対応する方法及びコンピュータプロダクトにも関するものであり、このコンピュータプロダクトは少なくとも電子計算機のメモリにロードすることができ、該プロダクトが電子計算機で実行されるとき本発明によるアーキテクチャー及び／又は方法を実行するソフトウェアコード部分を含む。電子計算機に言及したのは、明らかに、分散化されたレベルにて本発明による解決策を実行する可能性を強調するためである。

よって本発明の現在のところ好ましい態様では、１組の端末を含んだ電気通信ネットワークにおいてサービス品質を監視するためのアーキテクチャーを得ることができる。前記１組の端末は測定エージェントを内蔵し、測定エージェントは、前記ネットワークのアプリケーションセッションを管理するプロセスとネットワーク自体の動作条件を測定するプロセスとから選択されたプロセスとインターフェースするよう構成できる。管理・構成サブシステムもまた設けられ、このサブシステムはサービス品質測定キャンペーンをスケジューリングするためのモジュールを備え、測定キャンペーンを識別する１組の特性に従って端末の夫々のサブセットを関与させることができる。前記測定キャンペーンを実行するために、スケジューリングモジュールは、前記１組の識別特性に基づいた前記関連のサブセットに含まれる端末に内蔵された測定エージェントを構成できる。

有利には、測定データの収集を管理するための別のサブシステムも設けられ、好ましくは、測定データを記憶するためのデータベースとデータ自体を処理するための処理センターとを備える。

現在のところ好ましい態様では、ここに記載の解決策により、特に以下の動作特徴のうちの１つ以上に関して特定された解決策に固有の重大な問題が解消される：
− 実施できる測定の種類（定性的、関連性能）、
− 測定の種類（疑似トラヒック、実トラヒック）、
− 特別のハードウェアを必要とせずソフトウェアエージェントにより測定を実行する可能性、
− 遠隔にて測定を動的に構成する能力、
− 端末を選択し、測定の実行を遠隔にてプログラム可能でかつスケジューリング可能な能力、
− 構成コマンド及びデータをトランスポートするモード（例えば無線チャンネルを直接用いるＳＭＳ、ＴＣＰ／ＩＰ、ＵＤＰなど）、
− 測定可能なパラメータ：品質（セッションレベルでの遅延、ジッター、損失）、関連性能（トランスポートレベルでの遅延、スループット、損失）、端末及びネットワーク動作条件を特徴付けるパラメータ、
− 測定の物理ポイントの位置（端末、ＰＣ、システム、ノード）、
− 測定の論理ポイントの位置（プロトコル層）：例えば低層（物理、リンク）、
− 測定中の端末の位置、
− 測定の深さ（終端間や個々のユーザーに対する個々の呼）、
− ユーザーに最も近い地点にてアプリケーション上で品質測定を行う能力（例えば、オーディオ−ビデオデータのマルチメディアサービスの場合、個々のメディアについてそれらの間の相関、例えばオーディオとビデオとの間の同期の測定などの差別化された品質測定を行うことができる）、
− 測定結果をトランスポート及び収集するモード：“レポート結果メッセージ”（例えば、標準の無線チャンネル上をトランスポートされる）、
− 起動できる端末のサンプルの種類及び数に対する測定の特徴の適応性、
− 端末及びネットワークの動作条件に対する測定値の処理、管理、収集の適応性、
− ネットワークの種類（例えば携帯無線）、サービスの種類、端末の種類及び特定のネットワーク機能（ハンドシェイク、ローミング、位置など）に基づいた動作状況からの独立性、
− 新しいサービス／アプリケーションへの拡張の容易さ、
− 柔軟性（リンクで用いられる種類、資源、技術からの独立性）、
− 安定性（ネットワークの変化／発展の場合）、
− 他の性能測定／監視システムとのインターフェースの容易さ、
− 測定データの安全性／信頼性、
− リンク上での均一な性能／品質測定の分割、及び
− 品質及びトランスポート性能の測定値を相関させる能力。

これらの機能のサブセットは本発明の範囲を逸脱することなく実行できるが、ここに記載したシステムは上記機能を同時に協調して保証するよう構成できる。

一般に、本発明は、統合され詳細かつ正確な品質レベルを見ることを可能にすることに加えて、品質レベルを該品質レベルが到達した動作条件に関係付けることと、品質及び性能パラメータ（例えば無線チャンネル及び低下した通信の品質／パワーのレベル間）を相関させることの両方を可能にできる。

スケーラブルでモジュラー式のシステムは、測定データの安全性及び信頼性、端末及びユーザーに対する機能上及び性能上の透明性（すなわち非侵入的性質）、及び測定されるサービスに対する経済的な透明性の要件を見事に満たしている。
以下単に非限定的な例として添付図面に関して本発明を説明する。

発明の態様の詳細な説明
図１はここに記載のシステムの一般的なアーキテクチャーを示し、該アーキテクチャーを構成する機能モジュールと通信及び測定エージェントの位置とを強調している。また、システムのユーザーから又はシステムのユーザーへの外部の相互作用と、結果の収集、分析、報告のための外部システムへの外部の相互作用との両方が示されている。

要するに、携帯端末ＭＴレベルにて任意の規格に従った移動通信ネットワークへの適用を考えると（好ましいが必須ではない）、以下のものが設けられる：
− 測定エージェントＭＥＡ（測定実行エージェント）、
− 測定精密化モジュール（ＭＥＭ）、及び
− 通信エージェントＣＡ１。

測定を監督する管理・構成システム（端末品質測定スケジューラの典型的な役割に関してここではＴＱＭＳとして示される）のレベルでは、以下のものが存在する：
− 測定キャンペーンスケジューラＳ、
− 通信エージェントＣＡ２、及び
− システムのユーザーとインターフェースするインターフェースＡ１。

データ収集を管理する機能を有するサブシステム（端末データ収集マネージャすなわちＴＤＣＭ）レベルでは以下のものが存在する：
− データベースＤＢ、
− 処理センターＥＣ、
− 収集センターＣＣ、
− 通信エージェントＣＡ３、及び
− プラットフォームと任意の外部システムとの間でインターフェースを行うためのインターフェースＡ２。

ここに記載の様々なアーキテクチャーコンポーネント間での対話（携帯端末ＴＭに関して説明した構造は通常は複数携帯端末のレベル、実際的にはネットワークのすべての携帯端末のレベルにて再現されることに留意されたい）は通信エージェントＣＡ１、ＣＡ２及びＣＡ３により保証される。

特に測定データの交換のために携帯端末ＴＭとマネージャモジュールＴＤＣＭとの間（及び場合によっては携帯端末と携帯端末との間）で直接的な通信が行われるけれども、管理・構成サブシステムＴＱＭＳに関連するエージェントＣＡ２は通常は協調ノードの役割を行う。特に、図１ではデータ回線と信号回線はそれぞれ実線と破線で表されている。

ユーザーはＴＱＭＳサブシステムと協調して共同の同時の測定を行うことができる。

図には明示的に示されてはいないが、端末上で実行される測定機能はまたアプリケーションサーバ上でも使用できる。よってＴＱＭＳ及びＴＤＣＭサブシステムはサーバ上に位置するエージェントと相互作用することができる。

ここに記載されたアーキテクチャーは、アプリケーション層での終端間ＱｏＳを監視するシステムを規定及び実現し、その基本的な測定は端末ＴＭ上（及びアプリケーションサーバ上）に直接配置されたエージェントによってユーザーに対してトランスペアレントに実行される。

この説明は無線ネットワーク／サービスを中心に行われているが、そのわけは単に、特に端末レベル（ＣＰＵとメモリの点で）及びチャンネルスループットが無線アクセスにより制限されるリンクレベルでの要求及び資源の利用可能性の観点から最も厳しい環境だからである。本システムは、有線ネットワークを用いるサービス（基本的にはデータ）、又は端末（携帯電話又はＰＣ）が無線と有線の両方でネットワークに接続された無線と有線の混合リンク上でのサービスに容易に拡張できる。

サービスプロバイダとユーザーの両方にとって非常に興味ある多様な使用をカバーするように基本的なシステムを開発できる。

サービスプロバイダは体系的な測定を行うため、焦点の当てられた測定若しくはトラブルシューティングの測定を実行するため又はユーザーと契約したＳＬＡを検証するための測定を実行するために本システムを使用できる。本システムは、とりわけ同じ呼サンプルに対する同時の測定によって、リンクの性能低下の要因のセグメント分析（その原因が例えばアプリケーションサーバよりもむしろ端末にあるとするか又はネットワークに原因があるとするため）、及び異なるプロトコルレベル間（例えばトランスポートレベルとアプリケーションレベルとの間）で測定された同種パラメータ間の相関の分析の両方をサービスプロバイダが実行することを可能にする。

ユーザーが有効にされ許可されると、ユーザーは測定を実行して通信について得られた品質レベルを管理・構成サブシステムＴＱＭＳの端末のスクリーンに直接（ＧＵＩグラフィックインターフェースを介して）表示するか、又は規定レベルとの強調比較によりＳＬＡ検証を行うことができる。

性能低下の要因が端末（又はアプリケーションサーバ）にあれば、システム自体により得ることのできる臨時の測定によってローカルでの診断調査が可能である。これらすべての測定は、無線チャンネル上の他のもの及び端末の位置と共に、特に無線アクセスシステム上での最適化／再構成操作、又は短期／中期のセルの再プラニングを可能にする。

この測定は、ユーザーにより始動された通信上の実トラヒックと、携帯電話がアイドル状態にあるとき又は携帯無線端末が測定を始動すべき同じ種類のサービスを既に実行してはいないときネットワークからドライブされる疑似トラヒックとの両方において実行できる。実トラヒック中の測定は継続中の通信のユーザーによっても始動できる。すべての測定は（可能なもののうち）ネットワークにより（遠隔でスケジューラを介して）又は（端末上で）ユーザーにより構成可能である。

端末ＴＭ上の測定エージェントＭＥＡは使用された携帯無線チャンネルを測定するプロセス、及び端末自体内の動作プロセスと相互作用するだけでなく、サービスを実行するためのアプリケーションプロセスと相互作用する。このように、以下の測定を実行できる：
− アプリケーション層でのサービスの品質レベル（例えば規格３ＧＰＰ ＴＳ ２３．２０７に設定されている情報内容の利用可能性、アクセス可能性、リンクドロップ、遅延、損失、完全性）、
− 使用される無線チャンネルのパワー及び品質（ＢＥＲ、干渉…）、
− 終端間接続の性能特性（スループット）、
− 端末のステータス及び位置、
− 端末（又はサーバ）の同時の動作条件（ＣＰＵ使用量、メモリ使用量、バッファ飽和度など）。

端末上のエージェントは、測定相互作用の実行に加えて、処理及び記憶機能（ＭＥＭエージェント）や通信機能（ＣＡ１エージェント）をも実行する。これらの活動は、ここに記載のプラットフォームの非侵入要件を満たすために、携帯端末とネットワークとの両方の資源への衝撃を最小にして行われる。

好ましくは、エージェントにより提供されるサービスの管理／構成及びエージェント間の通信のために、Ｊａｄｅ技術が用いられ（Ｊａｄｅは例えば“Ａ ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｆｏｒ ａｇｅｎｔ ｏｎ ｈａｎｄ ｈｅｌｄ ｄｅｖｉｃｅｓ” ＡＡＭＡＳ ２００２，Ｊｕｌｙ １５−１６ Ｂｏｌｏｇｎａ，Ｉｔａｌｙに記載のＪＡＶＡエージェント開発フレームワークである）、この技術により、ＪＡＶＡで開発されＦＩＰＡ規格に準拠した分散ピアツーピアアプリケーションの開発が可能となる。固定ネットワーク（ＪＡＶＡ Ｊ２ＥＥ及びＪ２ＳＥ）と携帯ネットワーク（Ｐｅｒｓｏｎａｌ Ｊａｖａ及びＪ２ＭＥ）との両方において使用できるこの技術、及び関連の特徴（ホワイトページ、イエローページ）がエージェント管理において用いられる。

この選択はここに記載のプラットフォームの動作に拘束されるものではない。Ｊａｄｅは他のエージェント通信ミドルウェアと置き換えることができるからである。エージェント間の通信では上記動作条件に従って選択可能な異なるトランスポート技術を使用できる（例えばＧＰＲＳ上でＴＣＰ／ＩＰリンクを利用できない故に設定できない場合には、プラットフォームはＳＭＳ上のトランスポートの使用を決定することができる）。好ましくは、エージェント間でのメッセージの交換のため、ＴＣＰ／ＩＰ又はＵＤＰ／ＩＰトランスポートが用いられる。この能力により、たとえ電磁的な有効範囲が存在してユーザーがサービスにアクセスできなくてもプラットフォームのモジュール間の相互作用が可能になる（例えばＵＭＴＳネットワークの場合、ユーザーは高ビットレートビデオストリーミングサービスにアクセスできないかもしれないが、端末上のエージェントは適当なトランスポートを選択してプラットフォームの他のモジュールに及びプラットフォームの他のモジュールからデータを送受信することができる）。

分散Ｊａｄｅエージェントのスケジューリングと全体管理の方針（異常検出及び管理、構成及び再構成、測定スケジューリングなど）は、ワークフローパラダイムに従って開発された中央ユニットにより実行される。ここに記載のプラットフォームの一般的なアーキテクチャーは機能モジュールとそれらの間の相互作用とを強調する。以下、「抽象的な」エンティティと称されるユーザーは人間のオペレータ又はプラットフォームと相互作用できる外部のプログラムとし得る。

上述した機能モジュールの機能を以下詳細に説明する。

スケジューラ（ＴＱＭＳ）
Ｓで示される測定キャンペーンスケジューラの仕事は測定キャンペーンを規定することである。このためにユーザーは（インターフェースＡ１を介して）スケジューラとインターフェースして測定キャンペーンの特徴（基準ユニバース）を定める。

この操作は以下の複数のステップを含む：
− キャンペーンを行う端末を識別できる測定キャンペーンの基本的な特徴（ユーザー、合意した契約内容、サービス、端末、空間要素）を定め、
− 実施する測定と取得するＱｏＳ指標（基本的な特徴と互換性あり）とを定め、
− 実施する測定の特徴（測定周波数、測定値を収集センターに送信するモード）を定め、そして
− ペリフェラルエージェントが測定値と共に送信しなければならない測定関連の状況情報（測定の種類、端末及びネットワークのステータス情報など）を定める。

関係する端末を識別し測定を始動するために、スケジューラは始動の前に定められた測定キャンペーンに含まれる可能性のある端末を識別する。最初のステップの間に、好ましくはメカニズムが介在してＴＤＣＭへの情報の「シングルショット」最終伝送を最適化する。通信を最適化するのに使用できる方法は、ＤＢ共有であり、スケジューラが関連の端末についての情報、端末にロードされたそれらのステータス及び測定概要(profiles)を記憶する。

端末を識別し測定を始動する操作は以下のステップを含む：
− キャンペーン期間中の基本的な特徴に対応した端末の連続的な探索、
− 識別された各端末について、スケジューラＳは：
− 内部データベースに端末を記録し（ユーザーにシグナリングし）、
− ペリフェラルエージェントにより測定を管理し実行し処理し送信するためのすべての情報を用いて測定概要を生成し、
− ペリフェラルエージェントにより生成された測定概要を転送し（ペリフェラルエージェントが前に送信した有効なものを持っていない場合）、
− 端末上でキャンペーンを始動し、
− 基本キャンペーンのパラメータと共に関連の端末についての情報と予想される測定リストとをＴＤＣＭサブシステムに送信し、
− キャンペーンにより要求される基本的な特徴が変化した端末を識別し、それらを不適合とする。これらの端末に対し、スケジューラは：
− 端末上でのキャンペーンを停止させ、
− 端末の測定概要を削除するか否かを決定し、
− ＴＤＣＭサブシステムに知らせる。

測定キャンペーンの終わりを識別するために、スケジューラＳは例えばタイムアウトの終了を識別する。このイベントが起こると、キャンペーンに関係した各端末に対して、スケジューラＳは：
− 端末上でのキャンペーンを停止し、
− 端末の測定概要を削除するか否かを決定し、
− 測定キャンペーンの終了をＴＤＣＭマネージャに知らせる。

Ａｌインターフェースは測定キャンペーンの構成及び同期用の他の外部システムに向かう通信要素を表し、特に外部からの構成コマンドを検出しキャンペーンのステータスについての更新情報を伝達する。

好ましくはインターフェースは以下の機能を利用できる：
− 測定キャンペーンを定め、
− 測定キャンペーンを構成し、
− 測定キャンペーンの始動を命令し、
− 測定キャンペーンのステータスを監視し、そして
− 測定キャンペーンの時間同期を管理する。

端末ＴＭに関連した通信エージェントＣＡ１の主な機能は以下の通りである：
− スケジューラＳによる構成コマンドを検出し、
− スケジューラＳに自分自身のステータス（エージェントの動作環境）を定期的に知らせ、
− 他の端末と相互作用し、
− 測定処理エージェントＭＥＭを始動させ、
− 測定処理エージェントＭＥＭからデータを受信し、
− データを収集センターＣＣＣに送信し、
− 構成ステップ中にＴＱＭＳサブシステムからソフトウェア（例えばＭＥＭ及び／又はＭＥＡエージェントに関するソフトウェア）を受信する。

ＭＥＭエージェントを構成するサブシステムの主な機能は以下の通りである：
− スケジューラによる構成コマンドを検出し（通信エージェントを介して）、
− ネットワーク／端末のステータスを認識して測定を行う方法を「適応」させ、
− 以下についての測定を規則的な間隔で行い：
− 端末ＴＭ及び／又はネットワークの負荷状態、
− 始動したサービスのために端末ＴＭが使用する無線資源、
− 位置情報、
− ネットワーク／端末の状態に基づいて測定値の処理、収集及び／又は伝送を適応させることができ、例えば以下のパラメータに作用する：
− 測定時間、
− 測定値収集、
− 測定値処理アルゴリズム、
− 伝送時間及び手順、
− スケジューラＳに（規則的な間隔にて）状態／位置を知らせ、そして
− 異常イベントをシグナリングする。

測定エージェントＭＥＡを構成するサブシステムは測定を実施し、よってそのたびごとにキャンペーンの要件に従って構成されなければならない。柔軟性を最大にするために、このコード部分はスケジューラから端末に完全に又は部分的に転送され得る。

いったん構成された後のこのサブシステムの主な機能は以下の通りである：
− 測定の状況データを検出し記録し、
− 以下のような携帯無線システム測定値（これは端末に依存する）を取得し：
− 端末パワー、無線品質、ハンドオーバーについての無線システム測定値及び／又はイベント；
− 例えば以下のような端末状態測定値を取得し：
− 端末が作動させられたことの検出、
− バッテリーレベル、
− ＣＰＵ使用量レベル、
− メモリ使用量レベル、
等々。

ペリフェラル測定エージェントＭＥＡはサービス測定を行うために対象サービスのイベントを検出しなければならないことに留意されたい（例えばセッションを開き、データをリクエスト及び受信し等々）。

代わりの態様では、ペリフェラルエージェントＭＥＡ及びＭＥＭはまた、様々な種類のサービスのためにアプリケーションサーバ（サービスの提供に関連のサーバ）上に配置させることもできる。

それらはまた、異なる性能特性をもつ一定数の端末上に配置させることもできるし、かつ／又はそれらは互いに直接相互作用して分析すべき機能を実現することもできる（例えば同じセル内の端末は互いに協調して測定値を収集センターに送信して、無線資源の同時使用を避けることができる）。

好ましくは、各ペリフェラルエージェントは以下のものと相互作用する：
− 端末のオペレーティングシステム、
− アプリケーション（それを介してユーザーがサービスにアクセスする）、
− 通信ソフトウェア（アプリケーションレベルとネットワークレベルの両方での）、
− シムカード（ＳｉｍＣａｒｄ）上に場合によってはそれらのオペレーティングシステムと共に記憶されたソフトウェア。

典型的には、プラットフォームのペリフェラルエージェントは、ＡＰＩインターフェース（アプリケーションプログラミングインターフェース）を介して他のプロセスと相互作用し、該ＡＰＩインターフェースは：
− 使用されるプログラミング言語の規格（ここに記載の例ではＪａｖａ）、
− プラットフォームのプロセスを管理しペリフェラルと中央エージェントとの間での通信のために使用されるプラットフォームに固有であり、
− 端末のオペレーティングシステムの仕様（例えばＳｙｍｂｉａｎ）
とし得る。

アプリケーションとインターフェースするための（例えばＪａｖａＰｈｏｎｅ、ＪａｖａＣａｒｄなどのような他の環境とインターフェースするための）ＡＰＩインターフェースは、好ましくは、一般的なＡＰＩを介してペリフェラルエージェントによりアクセス可能とし、動作及び開発環境からペリフェラルエージェントの開発を切り離す。

以下で説明するように、ＴＤＣＭサブシステムの機能はその構成要素の機能から得られる。

特に、収集センターＣＣＣは：
− 異なる端末から到着する測定データを収集し、
− 端末により送信されたレコードを受信し、
− 意味的な正しさ（トランスポートにより導入されたエラー、欠落した測定値、部分的な測定値）を検証し、そして：
− エラーの場合には端末ＴＭに測定値の再送信をリクエストし（エラー管理機能により、場合によっては後で再送信するために、実施した測定値を端末に一定期間記憶する）、
− エラーが見つからない場合には、測定データを処理センターＥＣに送信する。

後者は、測定キャンペーンの開始を準備するとき、構成コマンドをスケジューラＳから受信する。このようにしてマネージャＴＤＣＭは以下のことを知る：
− 測定キャンペーン自体の特徴（限界期間、測定、サービス等の種類）、すなわち基準ユニバースの特徴、
− キャンペーンに関連する可能性のある端末リスト、及び
− 可能性のある端末のステータスの更新。

処理ステップ中、以下の目的のためにセンターＥＣは収集センターから到着した各測定の状況データを読み取る：
− 状況データを測定キャンペーンに関連付け、測定キャンペーン自体により採用された基準ユニバースに関連付けられるそれらの実際の能力を検証するため、
− レコードのシーケンシャル（時間に関係）順番を認識しチェックし、場合によってはそのキャンペーンの最後の基本測定値を認識するため、
− 以下のイベントの一つが起こるとユーザーに通知を送信するため：
− 関連の各端末により送信された測定値の数の更新、
− ペリフェラルエージェントで検出されたエラー（例えばペリフェラルエージェントによるイベントの記録に関するタイムアウトの終了）、
− 測定キャンペーンの終わりを認識するため（スケジューラＳに同期して）。

測定キャンペーンの終結時にＴＤＣＭマネージャサブシステムは、受信した測定値（例えばキャンペーンの論理終結後に受信しかつ終結前に開始したイベントに属するもの、又はまだ不完全なもの等々）を容認又は拒絶する基準を適用し、キャンペーン自体により規定された手順で正しいレコードを処理し、データベースＤＢに記憶する。

また、時間持続性は異なり得るので、マネージャＴＤＣＭは基本測定値を記憶するのに用いたものとは論理的に異なるデータベース上に結果及びレポートを記憶する。

上述したプラットフォームのモジュール間の相互作用の種類は、以下の少なくとも２つの異なる基準に従って分類できる：
− 携帯無線システムの資源の使用：この基準の目的は携帯無線ネットワークの資源の使用に依存したプロセス間の相互作用を区別することである。というのはそれらは異なる性能要求を受けなければならないからである。
− 機能上の基準：この基準の目的はプラットフォームの種々のエンティティとデータを交換するものとの間の「シグナリング」相互関係の差を強調することである。

ここに記載のプラットフォームのプロセスに属する相互作用のために、以下の他の２つの種類の相互作用もまた規定されなければならない：
− プラットフォームのプロセス間のすべての相互作用をグループ化する「水平」型の相互作用。さらにこれらは以下の２つのクラスに分割できる：
− 通信相互作用：データ（測定値、品質指標など）を交換しなければならないときのプラットフォームの２以上のエージェント間の相互作用、
− 管理相互作用：構成データを交換しなければならないとき又は管理手順（始動、取り消し、エージェントダウンローディング）を実行しなければならないときのプラットフォームの２以上のエージェント間の相互作用；
− 端末オペレーティングシステム、アプリケーション、通信プロトコル、データベース管理システム（ＤＢＭＳ）などの、プラットフォームのプロセスと外部のプロセスとの可能なすべての相互作用をグループ化する「垂直」型の相互作用。

この点に関し、図２の機能図では以下の種類の相互作用が強調されている：
− 測定キャンペーンを考慮したプラットフォームの構成：番号１０で示されたこの相互作用は典型的には携帯端末ＴＭに内蔵されたペリフェラルエージェントに対するＴＱＭＳサブシステム（具体的にはスケジューラＳ）の水平シグナリング相互作用である。
− ペリフェラルエージェント（図１中のＭＥＭ）からＭＥＡ型エンティティへの測定データのリクエスト：２０で示すこの相互作用は典型的には、例えば、ウエブブラウザＷＢを用いてＣＨＰで示されたＨＴＴＰクライアントプロセスを含む垂直シグナリング相互作用である。
− 上述した相互作用の結果としてリクエストされる測定データの提供：３０で示すこの相互作用は典型的には、エージェントＭＥＡからエージェントＭＥＭへのデータ伝送の垂直相互作用である。そして
− ペリフェラルエージェントから測定値収集サブシステムＴＤＣＭへの（及びそれと協調する管理・構成サブシステムＴＱＭＳへの）測定データの伝送：４０で示すこの相互作用は典型的には水平測定相互作用である。

ここに記載のプラットフォーム自体を構成する種々の要素の通常機能を含むプラットフォームを使用するために基本的な操作ステップについて以下に詳細に説明する。具体的には出願人による実際的な実装の設計及び開発仕様と称されるプラットフォーム要素間の相互作用の可能な場合すべてについて説明される。

ステップの説明では図３を参照し、ユーザーと称される抽象的なエンティティとの相互作用を介してプラットフォーム自体により実行される測定キャンペーンの状況に当てはまる。ユーザーは人、外部のプロセス、機関エンティティ又は別の要素とし得る。対象が変わるとインターフェースの実装は変わるが、相互関係の意味的な面は変わらないことは明らかである。

ここで再現された例では、プラットフォームは以下の操作に関係することが仮定される：
− ユーザーの申し込みがあると、通信エージェントを組み入れるよう端末が構成され、この動作により、端末が識別子及び相関情報によってプラットフォーム自体に知れることになる。この情報は端末を識別し配置するのに用いられる。
− ユーザーＵはスケジューラＳと相互作用し（図３のステップ１００）、測定キャンペーンの特徴を定める（基準ユニバース-そのステータスはステップ１０２でユーザーに知らされる）。これらの特徴は計画された体系的活動から、具体的な内部の監視要件（例えば特に関心のある顧客ベースのセグメント）から、又はネットワークのトラブルシューティング要件（例えば苦情を受信したとき）から得ることができる。また、協調し同期した測定キャンペーンを均一なセットの品質パラメータについて計画し以下のことを可能にできる：
− 対象ネットワークと同一セットの呼上のサービス測定との間の相関、
− 客観的なサービス測定とサーベイから得られた主観的な尺度との間の相関。
− スケジューラは測定キャンペーンにおいて関連する可能性のある端末を識別する。この操作の結果はユーザーに通知されなければならず、ユーザーはステップ１０４においてプロセスを継続するか否かを決定して同意を表さなければならない。多数の端末を伴う大規模で体系的なキャンペーンの場合、携帯無線ネットワークのデータベースとのインターフェースし、測定に関与する可能性のある端末セットを識別し所在確認する必要が生じる。
− スケジューラは測定キャンペーンに関与する各端末に適する測定概要（個々の測定の手順についての情報、並びに測定の種類及び測定間の相互関係についての情報を含む）を生成する。測定値の伝送のタイミングの基準が測定概要に関連付けられ、ネットワークの過負荷を回避する。
− ステップ１０６では、識別された各端末に夫々の測定概要が転送される（もしアクティブならばステップ１０８でこの手順がペリフェラルエージェントにより記録される）。この操作の結果はステップ１１０でユーザーに知らされる。それからユーザーは実際に測定キャンペーンを実行することを決定できる（継続中の通信の可能な管理により、開始時にアクティブなもののみにキャンペーンを行うか、又は可能性のあるものにも行うかを選択できる）。
− ユーザーによる同意（ステップ１１２で表示）の場合、スケジューラはマルチキャストコマンドを介して構成された端末上で測定キャンペーンを自動的に開始し（可能ならば、ＧＰＳシステムにより提供されるスケジューラ、ペリフェラルエージェント及びＴＤＣＭ間の同期機能が使用できる）、また関与する可能性のある端末のリストとそれらの各々から予想される測定リストとを作成し、図３中で１１４及び１１６で示すステップにおいてこの情報を基本キャンペーンパラメータと共にＴＤＣＭサブシステムに送信する。
− 測定キャンペーン中、スケジューラＳはキャンペーンに関与する可能性のある端末を追跡する。この情報は下記のために使用される：
− キャンペーンの開始から遅れて始動される端末についてキャンペーンを始動及び／又は再始動するため、
− キャンペーン自体のインターバル中にパラメータ及び／又は基本的な特徴が変化した端末についてキャンペーンを一時停止又は停止するため、
− キャンペーンの終了時に測定値を処理するとき、スケジューリングされたデータに対する収集データの矛盾を強調するため（エラーによる端末の利用不可又は過負荷を原因として実行されず、部分的で一時中断した測定；失敗した受信又は収集における完全性の問題）。
− スケジューラＳによる測定キャンペーンの始動の際（ステップ１１８）、ペリフェラルエージェントは端末及びネットワークの利用可能性及び／又は負荷ステータスに対して適合的に所定の測定を開始する。
− ペリフェラルエージェントは端末に対してローカルで測定値を記憶し前処理する。この活動は測定概要と端末及びネットワークの性能とに従ってペリフェラルエージェントにより適応的に設定される。
− ペリフェラルエージェントはＴＤＣＭサブシステムに（ステップ１２０で）基本測定値及び／又は計算されたパラメータに加えて測定に関連した状況及び操作データをも含んだ情報レコードを送信する。
− ＴＤＣＭサブシステムは端末が送信したレコードを受信しその正しさを検証し（トランスポートにより導入されたエラー、欠落した測定値、部分的な測定値を検出し）、ステップ１２２で端末にフィードバックする。受信の確認（ＡＣＫ）に加えて、フィードバックによりエラーの場合にＴＤＣＭサブシステムが端末に測定値の再送信をリクエストすることができる（後に再送信するために、実施した測定値を場合によっては所定の期間端末上に記憶するエラー管理機能を設けなければならない）。
− ＴＤＣＭサブシステムはキャンペーンに関与する可能性のある端末のリスト、及び測定キャンペーン自体の特徴（限界期間、測定の種類、サービスなど）、すなわち基準ユニバースの特徴を知っており、下記の目的のために各測定の状況データを読み取る：
− それらが測定キャンペーンにより採用された基準ユニバースに実際に関連し得るか否かを検証し、もしそうなら、基本測定値と状況データを収集ＤＢに記憶するため、
− レコードのシーケンシャル（時間関係）順番、及びそのキャンペーンの最後の基本測定値を認識しチェックするため、
− 以下のイベントの一つが起こるとユーザーに通知するため：
− 関連の各端末により送信された測定値の数の更新、
− ペリフェラルエージェントでのエラー検出（例えばペリフェラルエージェントによるイベントの記録に関するタイムアウトの終了）、
− 測定キャンペーン。
− 測定キャンペーンの終結時に、ＴＤＣＭはその終結の前に開始したイベントに関するキャンペーンの論理的な終結の後に受信した測定値を容認するか否かを決定する基準を適用する。
− キャンペーンの終結時には、ステップ１２４でＴＤＣＭサブシステム（測定プロセッサ）は測定エージェントを停止させ、キャンペーンにより提示された方法にて訂正されたレコードを処理し、品質指標を計算し、それを時間持続性が異なり得るので基本測定のものとは論理的に異なるＤＢに記憶する。
− プラットフォームの通常のユーザーは生成されたＤＢ上で特定の問い合わせを行い（様々なキャンペーンからのデータセット全体に対し）、ＱｏＳ“ビュー（Views）”をフィルタリングし、種々のレポートタイプを関心のある企業レベルに送信することができる。
− 許可されたアクセス概要を有する他のユーザー（例えばネットワーク領域に属する）は、プラットフォームのＤＢにアクセスでき、特定の問い合わせで相関分析及び／又はトラブルシューティングのためデータをフィルタリングする（この場合もっとタイムリーなアクセスのためには、基本測定の結果を記憶できる収集データベース上に専用領域を設ける必要がある）。

図４は上記記載のプラットフォームの使用の可能な場合を例示する。

このように得られたＱｏＳ測定値は内部プロセス及びサポートシステムに関する改善のために、異なる目的の携帯無線オペレータにより使用できる。例えばシステムの使用は負荷下の端末の性能に焦点を当て、その構成を最適化でき、又は通信品質に焦点を当て、又はトラブルシューティング分析を実施でき、またユーザーにはユーザーに関心のあるサービスの機能及び操作プロセスを制御して例えば契約したＳＬＡを検証する能力が付与され得る。

具体的にここに記載したプラットフォームの使用シナリオはまず図４中で２００で示したサービス品質監視に関係する。この機能セットは典型的には以下のものを含む：
− ＳＩＭに記憶されたデータも考慮して端末により実行される測定２０２（例えば無線接続の品質の評価）、
− 終端間性能の評価２０４（端末側又はサーバ側）、オペレータでも実施（２０４ａ）、ユーザーでも実施（２０４ｂ）、
− 端末／サーバの性能の評価２０６、オペレータでも実施（２０６ａ）、ユーザーでも実施（２０６ｂ）、
− 端末及びサービスプロバイダレベルでのＳＬＡ協定の検証２０８、オペレータでも実施（２０８ａ）、ユーザーでも実施（２０８ｂ）。

プラットフォームはまた、トラブルシューティング機能のため、すなわち端末内でのＱｏＳ性能低下の原因を特定するために使用できる。

全体的に２１０で示したこの機能セットは本質的に診断及び異常の通知（端末側、アプリケーションサーバ側）、並びにリアルタイム構成及び資源の管理（これも端末側とアプリケーションサーバ側）を含む。

図４には前記機能がオペレータ（ブロック２１２）とユーザー（ブロック２１４）の両方によって決定し得ることが明白に示されている。

図４では、ブロック２２０及び２３０は、場合によってはプラットフォームを適用して、端末の内部資源及び機能ならびに資源の最適な構成及び管理をサービス品質（ＱｏＳ）の観点から診断（例えばリアルタイムにて）することを示す。

要するに、ここに記載のプラットフォームアーキテクチャーは以下の能力を与える：
− 携帯無線環境内で同時かつ全体的に呼毎に客観的にユーザーの知覚に最も近いサービスへのアクセスポイントでのリンクの品質パラメータと動作条件を測定する（よって端末上でアプリケーションレベルにて）。
− セッションの品質パラメータ（利用可能性、アクセス可能性、リンク保守、遅延、エラー、情報内容の損失）を測定するだけでなく、同時に無線チャンネルの動作条件（パワー、ＢＥＲなど）、リンクの動作条件（スループット）、そこで得た端末の動作条件（ＣＰＵ負荷、バッファ及びメモリ使用量など）を検出する。
− 端末位置データを上記測定値に関連付ける。
− ネットワーク／端末／アプリケーションサーバ間で品質性能低下を分割する。
− トランスペアレントにユーザー端末上で継続中の通信上の実トラヒックにおける測定を行うか、又は疑似トラヒックにおける測定を始動する。
− 測定を行う端末と測定の概要（パラメータ、測定手順）の両方を動的に管理する（これも遠隔にて）。
− サービスプロバイダとユーザーの両方により実施される測定を実行する。
− 端末及び無線チャンネルの処理負荷に基づいて（端末上で）測定値をダウンローディングし、ローカルに記憶するための手順を自動管理する。
− ネットワーク技術からのプラットフォーム独立性を達成する。
− プラットフォームエージェント間での通信のため利用可能なもののうちで最も適したトランスポートモード（ネットワーク負荷への衝撃を最小にするもの）を選択する。

ここに記載のプラットフォームは、マルチモードインテリジェント端末が情報をトランスポートするために複数のアクセスシステムを同時に使用できる最新のマルチスタンダード環境（例えばＵＭＴＳ／Ｗ−ＬＡＮ）（複数の無線システム上の複数の並行リンクにより形成される通信）においてもＱｏＳを監視するのに適する。

携帯無線端末によりサポートされるサービスの終端間ＱｏＳを監視するためにここに記載のプラットフォームはまた、固定ネットワーク（ＬＡＮ、ＭＡＮ及びＷＡＮ）及び無線ネットワーク（Ｗ−ＬＡＮ）に対する動作及び開発環境とインターフェースするＡＰＩ（アプリケーションプログラムインターフェース）の特別な開発によって使用できる。また、プラットフォームはマルチモード端末上でマルチスタンダード環境において動作できる。

現在好ましい態様では、ここに記載の解決策では、すべてのサービス、すべての携帯無線ネットワーク及びすべての携帯無線端末（異なる動作環境、性能及びインターフェースで特徴付けられる）に適用可能なＱｏＳ（実トラヒックと疑似トラヒックの両方において）を監視するプラットフォームが設けられる。アーキテクチャーは携帯端末上に配置された測定エージェントに基づいており、アプリケーションセッションを管理し、無線受信条件、ステータス及び動作条件（負荷、端末位置など）を測定するためのプロセスと適当なＡＰＩでインターフェースでき、かつ他の測定又は管理エージェントと対話できる。これらのエージェントは測定スケジューリングに基づいて端末上で遠隔にてかつ柔軟に管理し得る（これらは携帯無線端末の所定のセット上でロード、始動及び動的に構成され得る）。

それらはまた以下のことが可能である：
− 協調した測定を実行する（構成可能な測定概要により）。
− 動作条件（例えば測定値を送信する無線チャンネルの負荷、収集センターからの再送信リクエスト）の関数としてローカル記憶／前処理操作を実行する。
− 収集センターへの測定結果の転送をブログラマブルに管理する。

このアーキテクチャーにより、たとえば下記のような従来の操作を（ユーザー端末上で）実行できる：
− 無線アクセスの品質及び動作条件の典型的な測定値（送信又は受信したパワー、ＢＥＲなど）を取得する。
− 終端間トランスポート性能を監視する（実トラヒックと疑似トラヒックの両方において）。
− 終端間アプリケーション層でのＱｏＳ指標の生成のための測定及び処理（携帯無線端末上で）。よって、ユーザーにより知覚される品質に非常に近く、これはサービスの種類と関心のあるサービス方法との両方に依存する。例えば、利用可能性、アクセス可能性、遅延、ジッター、損失、ドロップなど。
− 端末及びネットワークの資源の動作条件（スループット、ＣＰＵ負荷及びメモリ、バッファ混雑など）を監視する。

当然のことながら、本発明の原理を変えることなく、構成の詳細や態様を特許請求の範囲に記載の本発明の範囲から逸脱することなく、ここに記載のものから広く変えることができる。

ここに記載のプラットフォームアーキテクチャーを説明する機能ブロック図である。 上記プラットフォームの使用のための相互作用のフローを説明する図である。 ペリフェラルエージェントにて測定を始動し実行し、その後測定値を図１のプラットフォーム内の収集センターにダウンロードする機能ステップを説明する図である。 ここに記載のプラットフォームの可能な使用様式を端末側から見て示す別の機能ブロック図である。

符号の説明

ＴＭ…携帯端末
ＭＥＡ…測定エージェント
ＭＥＭ…測定処理エージェント
ＣＡ１、ＣＡ２、ＣＡ３…通信エージェント
ＴＱＭＳ…管理・構成サブシステム
Ｓ…スケジューラ
Ａ１、Ａ２…インターフェース
ＴＤＣＭ…マネージャモジュール
ＤＢ…データベース
ＥＣ…処理センター
ＣＣＣ…収集センター

Claims (37)

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. 外部のシステムとインターフェースするよう構成された（Ａ３）測定データの収集を管理するための追加のサブシステム（ＴＤＣＭ）を設けるステップを含むことを特徴とする請求項１９に記載の方法。
30. − 測定データの収集を管理するための追加のサブシステム（ＴＤＣＭ）を設けるステップ、及び
    − 測定データの収集を管理するための前記追加のサブシステム（ＴＤＣＭ）に前記測定データを直接転送するように前記１組の端末（ＭＴ）に含まれる前記端末エージェント（ＭＥＡ、ＭＥＭ）を構成するステップ
    を含むことを特徴とする請求項１９に記載の方法。
31. 前記端末エージェント（ＭＥＡ、ＭＥＭ）がＪａｄｅ技術に従って動作することを特徴とする請求項１８に記載の方法。
32. − ＳＭＳ、
    − ＴＣＰ／ＩＰプロトコル、及び
    − ＵＤＰ／ＩＰプロトコル
    からなる群から選択された通信資源により前記同種の通信エージェントと対話するために端末（ＭＴ）に内蔵された前記通信エージェント（ＣＡ１）を構成するステップを含むことを特徴とする請求項２０に記載の方法。
33. 前記測定キャンペーンを実行するステップが、
    − 測定キャンペーンの識別特性を定めるステップ、
    − 前記キャンペーンを行う端末を識別するステップ、
    − 実施する測定と取得するサービス品質指標とを定めるステップ、
    − 実施する測定の特徴を定めるステップ、及び
    − 前記端末エージェント（ＭＥＡ）により実行される測定に関連した状況情報を定めるステップ
    からなる群から選択された少なくとも１ステップを含むことを特徴とする請求項１８に記載の方法。
34. 前記１組の端末の前記夫々のサブセットを識別するために、
    − 測定キャンペーンの識別特性を満たす端末を連続的に探索するステップ、
    − 前記端末を内部データベースに記録するステップ、
    − 夫々の端末エージェント（ＭＥＡ）により前記測定を実行するための情報を用いて測定概要を生成するステップ、
    − 関連の端末上でキャンペーンを始動するステップ、
    − 前記端末（ＭＴ）から収集された測定情報を送信するステップ、
    − 測定のために関連の特徴が変化した端末を識別するステップ、
    − キャンペーンを停止するステップ、
    − 所定の測定キャンペーンのために前記端末（ＭＴ）及び関連の情報から測定概要を削除するステップ
    からなる群から選択されたステップを含むことを特徴とする請求項１８に記載の方法。
35. 電気通信ネットワーク自体に関連した請求項１〜１７のいずれか一項に記載の監視アーキテクチャーを含むことを特徴とする電気通信ネットワーク。
36. 前記監視アーキテクチャーと相互作用することができる少なくとも１端末エージェントを内蔵した少なくとも１アプリケーションサーバを含むことを特徴とする請求項３５に記載の電気通信ネットワーク。
37. 少なくとも１つの電子計算機のメモリにロードすることができるコンピュータプログラムプロダクトであって、請求項１〜１７のいずれか一項に記載のアーキテクチャーを実現するか、又は請求項１８〜３４のいずれか一項に記載の方法を実施するためのソフトウェアコード部分を含む前記コンピュータプログラム。