(57)【要約】【課題】　ネットワーク上の異なるデータソースによる複数の測定値を同時に整合させ、共通ソースに集約するプラットフォームを提供する。【解決手段】　ネットワーク上で行われるべき測定を定義し、測定を実施する為の異種のデータを提供するネットワーク上のデバイスの設定を構成し、デバイスに異種のデータを提供させるようにする為に設定されたデバイスをロックし、ロックされたデバイスから異種の測定値を得る為にテストを実行する。また、ネットワーク上の複数のデバイスに共通するフレームワークが、ネットワーク上の複数のデバイスから得られた異種の測定値を自動的に同期させる。【選択図】図１
2004088779.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の複数のデバイスに共通するフレームワークを含む装置であって、該フレームワークが該ネットワーク上の該複数のデバイスから得られた異種の測定値を自動的に同期化する装置。
【請求項２】
前記フレームワークが、前記異種の測定値を共通のタイムスケールにより自動的に同期化する請求項１に記載の装置。
【請求項３】
前記異種の測定値の前記同期化が、システムタイムチックの相対的時間差をとることにより共通タイムスケールで実施される請求項２に記載の装置。
【請求項４】
前記異種の測定値の共通タイムスケールでの前記同期化が、同軸ケーブルを通じて共通クロック信号を配信することにより実施される請求項２に記載の装置。
【請求項５】
共通プラットフォーム中の異種の測定値群を整合させる方法であって、
　各々が他のデータソースとは異なるタイプのデータを含む複数のデータソースを提供するステップと、
　前記複数のデータソースから前記異なるタイプのデータを測定するステップと、
　測定結果を共通スケールに正規化するステップと、
を含む方法。
【請求項６】
前記異なるタイプのデータを測定するステップが、データソースからデータを測定する以前に、データを測定すべき特定のデータソースへロックするステップを含む請求項５に記載の方法。
【請求項７】
前記異なるタイプのデータを測定するステップが、測定された前記異なるタイプのデータを共通タイムスケールで同期化させるステップを更に含む請求項６に記載の方法。
【請求項８】
前記異なるタイプのデータを同期化させるステップが、システムタイムチックに基づいて測定値の相対的な時間差をとるステップを含む請求項７に記載の方法。
【請求項９】
前記異なるタイプのデータを同期化させるステップが、同軸ケーブルを通じて前記複数のデータソースへと共通クロック信号を配信するステップを含む請求項７に記載の方法。
【請求項１０】
前記異なるタイプのデータを同期化させるステップが、測定されたデータにタイムスタンプを記録するステップを含む請求項７に記載の方法。
【請求項１１】
前記正規化するステップが、以下の式を前記測定されたデータに適用する請求項５に記載の方法。
　　ｙ＝ｆ（ｘ）
　　　ただし、
　　　ｘ＞＝Cmaxの場合、ｙ＝３．０
　　　Cmax＞ｘ≧Tyrの場合、ｙ＝２．０＋（ｘ−Tyr）／（Cmax−Tyr）
　　　Tyr＞ｘ≧Tgyの場合、ｙ＝１．０＋（ｘ−Tgy）／（Tyr−Tgy）
　　　Tgy＞ｘ≧Cminの場合、ｙ＝ｘ／（Tgy−Cmin）
　　　ｘ＜Cminの場合、ｙ＝０．０
【請求項１２】
前記正規化するステップが、
　少なくとも２つの異種のスカラー測定データの各々を同種の数学的変換空間へと変換する数学的変換関数を使用するステップと、
　前記少なくとも２つの変換された異種のスカラー測定データのうち、少なくとも１つを表示するステップと、
を含む請求項５に記載の方法。
【請求項１３】
前記正規化するステップが、変換関数を用いることにより前記測定結果を同種の変換空間へとマッピングするステップを含む請求項５に記載の方法。
【請求項１４】
前記測定結果を前記同種の変換空間へとマッピングするステップが、測定結果を要約形式にするために、しきい値を用いるステップを含む請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は測定値群を整合させることに関するものであり、より具体的には異なるソースからの異種の測定値及び異なるソースからの同種の測定値を整合させることに関する。
【背景技術】
【０００２】
　ソフトウエアプラットフォームは、例えば異なる種類のデータや異なるタイムテーブルでアクセス可能となるデータ等、異なる形式のデータを提供するデータソースから測定値を収集することが出来なければならない。収集すべき、及び／又は整合させるべきデータを提供するデータソース（データをどのようにフォーマットし、系統化するかを説明するスキーマを含むプロトコル）の一部の例としては、ルータ、ボイステスタ、ネットワークアナライザ、又はネットワークプローブ等を挙げることが出来る。データソースにより実現されるプロトコルとしては、ＳＮＭＰ（ＲＭＯＮ、ＭＩＢ２等）、ＲＴＰ、ＸＭＬ、ＳＣＰＩ、ｈｔｔｐ、ＣＭＩＰ、ＬＤＡＰ、ＯＤＢＣ、ＪＤＢＣ等が含まれるが、これらに限られない。これらの測定値は通常、例えばＳＮＭＰエージェントが提供する測定値のように非常に独立的な方法で単一のネットワークにおける特定問題のトラブルシューティングに使用されるものである。このようなトラブルシューティングとしては、期待された結果からのずれを示す個々の測定値を取得及び表示するテストなどが含まれる。特定のドメインにおける様々な測定値（例えばＳＮＭＰエージェントが提供する測定値）をレポートする一般的なシステムの一例としては、Concord Communications社のものが挙げられる。
【０００３】
　しかしながら、より近年においては、ネットワークに生じたトラブルシューティングを必要とする問題の多くが、個々の測定値からピンポイントで判断することが困難なものとなっていることから、分散型テストの必要性が浮上している。従って、ネットワークの異なる箇所にある複数の測定値を同時に整合させる必要性がある。更に、幾つかの製品で得られた測定値の一部を補強するために、全体的なテストにおいて、ネットワーク中のいずれかの地点に存在する異なるネットワーク機器、ネットワークアプリケーション及びネットワークオペレーティングシステムにより取得した他の測定値を含ませる必要がある。従って、異なるタイプのテスト作業を１つに結びつけることができる必要がある。例えば異なる測定を整合させてスケジュール及びトリガすることが出来るように、あるいは異なる測定の実行に関してこれら全ての測定値に適正な設定となるように構成することなどである。更に、このように多岐にわたる異なるタイプのデータの結果を統合化した形でデータベース中に収集しなければならない。最終的に、異なる測定の結果を合わせて集計して提示することはもちろん、最も重要な違反や測定結果の期待値からの偏差を強調することができるのも必要である。よって異なるデータを共通のソースへと集約、及び／又は整合することが出来るソフトウエアプラットフォームが必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
　本発明は、ネットワーク上の異なるデータソースによる複数の測定値を同時に整合させ、共通ソースに集約するプラットフォームを提供するものである。
【課題を解決するための手段】
【０００５】
　本発明の一態様は、ネットワーク上で行われるべき測定を定義し、測定を実施する為の異種のデータを提供するネットワーク上のデバイスの設定を構成し、デバイスに異種のデータを提供させるようにする為に設定されたデバイスをロックし、ロックされたデバイスから異種の測定値を得る為にテストを実行する、プラットフォームを提供するものである。
【０００６】
　本発明の他の態様は、データソースからのデータの異種の測定値群及び／又は同種の測定値群を調整する方法を提供するものである。
【０００７】
　本発明の更に他の態様は、ネットワーク上の複数のデバイスに共通するフレームワークを提供するものであり、このフレームワークがネットワーク上の複数のデバイスから得られた異種の測定値を自動的に同期させるものである。
【０００８】
　本発明の更に他の態様は、ネットワーク上の複数のデバイスに共通するデータコレクタを実装したコンピュータを提供するものであり、データコレクタがネットワーク上の複数のデバイスから異種の測定値を自動的に収集するものである。
【０００９】
　本発明の更に他の態様は、異なるデバイスから得られた測定値の相関をとるための共通のフレームワークを有する装置を提供するものであり、少なくとも２つのデバイスが、異なるデバイスから得られた測定値を同期させることにより、異なるタイプのデータを提供するものである。
【００１０】
　本発明の更に他の態様は、ネットワーク上の複数のデバイスから得られた異種の測定値の相関をとり、相関をとった異種の測定値をディスプレイ画面上でエンドユーザーに提示し、エンドユーザーによる要約（summary）表示から詳細（detail）表示への掘り下げ（drill）を可能とした、コンピュータ実装型提示デバイスを提供するものである。
【００１１】
　本発明の更に他の態様は、共通ネットワーク中の複数のデータソースから受けた異種の測定値を統合化する方法を提供するものであって、その方法は、（ａ）少なくとも１つのデータソースのサービスで行われるべき各測定を定義するステップと、（ｂ）行われるべき測定に関わるデータソース各々の設定を構成するステップと、（ｃ）行われるべき特定の測定の各々に割り当てられたリソースをロックするステップと、（ｄ）データソースから受けたデータで測定を実施するステップと、（ｅ）取得された異種の測定値を同期させるステップと、（ｆ）測定値を合わせて提示するステップと、を含む。
【００１２】
　本発明の更に他の態様は、共通プラットフォーム中の異種の測定値群を整合する方法を提供するものであり、その方法は、各々が他のデータソースとは異なるタイプのデータから成る複数のデータソースを用意するステップと、複数のデータソースからの異なるタイプのデータを測定するステップと、そして測定結果を共通スケールで正規化するステップとを含む。
【００１３】
　本発明の更に他の態様は、ネットワークトラブルシューティングシステムを提供するものであり、そのシステムは、各々が測定すべき他のデータソースとは異なるタイプのデータを提供する、少なくとも２つのデータソースと、異なるタイプのデータをどのように測定するかを管理するデータソースマネージャーと、少なくとも２つのデータソースが提供する異なるタイプのデータを測定するために、ネットワークトラブルシューティングシステムに必要な情報を提供するデータコレクタと、取得した測定値を記憶するデータベースと、少なくとも２つのデータソースが提供する異なるタイプのデータの測定の実行を管理するテストマネージャと、を含む。
【００１４】
　これらは、後に明らかになる他の態様及び利点と共に以下に説明及び請求する構成及び作用の詳細において、その一部を構成する添付図（全体を通じて同様の要素には同様の符号をつけた）を参照して述べる。
【発明を実施するための最良の形態】
【００１５】
　異なる種類のネットワークシステムは通常、例えばＳＮＭＰ（ＲＭＯＮ、ＭＩＯＢ２等）、ＲＴＰ、ＸＭＬ、ＳＣＰＩ、ｈｔｔｐ、ＣＭＩＰ、ＬＤＡＰ、ＯＤＢＣ、ＪＤＢＣ等、広い範囲にわたる異なるプロトコルにより実現されている。従って、これらのプロトコルにより提供されるデータは相互に対して異種であると言える。本発明は、異なるプロトコルの各々から得られる異種のデータを収集し、異種のデータを同期化させることによりテスト全体を調整し、テストの正規化した結果を提示すると同時にこの結果をインタラクティブかつナビゲーション可能な方法で閲覧する能力を提供するオペレーティングシステム及び方法を提供するものである。
【００１６】
　図１は、本発明の一実施例に基づくネットワークトラブルシューティングセンター（ＮＴＣ）１００（「プラットフォーム」とも称する）の構造例を描いたものである。このＮＴＣは、多くの異なるデータソース又はネットワークホスト（「エージェント」とも称する）からデータを収集し、それらのデータに同期テストを実施することが出来るものとして描かれている。
【００１７】
　説明の便宜上、図１には３つのエージェント１０１ａ〜１０１ｃが描かれており、これらが３つの一般的に使用されているプロトコルをホストしているものとした。しかしながら、本発明のＮＴＣへとデータを供給する為には異なるエージェント１０１ａ〜１０１ｎに加えて多くの異なるタイプのプロトコルをホストする多数の追加エージェントを用いることが出来ることは言うまでもない（以下に説明する図２及び図３を参照）。エージェント１０１ａ〜１０１ｎがホストする他のタイプのプロトコルの中には、例えばＳＮＭＰ、ＸＭＬ、ＳＣＰＩ、ＳＮＭＰ（ＲＭＯＮ、ＭＩＢ２等）、ＸＭＬ、ＮＳＴＰ、ＲＴＰ、ｈｔｔｐ、ＣＭＩＰ、ＬＤＡＰ、ＯＤＢＣ、ＪＤＢＣ等が含まれる。本発明のＮＴＣ１００により実現可能なプロトコルの上記拡張リストはこれらに限られたものではなく、これらは本発明のＮＴＣ１００により実現することが出来る多数の標準的、或いは所有権を持たれたプロトコルの中の一部の説明例にしかすぎない。通信レイヤ１０２は、ＮＴＣ１００自体とＮＴＣ１００を支持する異なるプロトコルとの通信用に使用される。例えば、通信レイヤ１０２は異なるエージェント１０１ａ〜１０１ｎから受けた異なる測定データ（相互に対して異種である）を提供するものであり、これらの測定データはデータコレクタ１０３により収集される。
【００１８】
　データコレクタ１０３は、ＮＴＣ１００（「共通プラットフォーム」とも称する）に実現されたエージェント１０１ａ〜１０１ｎの各々から提供される異種の測定値を収集するものである。測定法としては、アクティブ測定、パッシブ測定、絶対測定、較差（differential）測定、離散型（discrete）測定、連続型（continuous）測定及び進行型（progressive）測定が含まれる。便宜上、データコレクタ１０３は１つしか図示していないが、本発明のＮＴＣ１００においては複数のデータコレクタを使用することが出来ることは言うまでもない。
【００１９】
　アクティブテストは、測定設定の一環として生成される何らかの刺激に対する応答を測定することが含まれる。幾つかの例をあげると、これにはＰＳＱＭ音声品質測定、ping and traceroute、及びアクティブアプリケーション応答時間が含まれる。パッシブテストは、被験環境に対する影響を最小とした上でネットワーク（又はシステム）アクティビティを観測することが含まれる。その例としては、パケット取得、ＳＮＭＰ ＲＭＯＮ及びＭＩＢ統計、そしてＲＴＰ品質測定が含まれる。使用中の場合においては測定がアクティブであるかパッシブであるかは重要である。例えばアクティブ測定の場合、通信機器をオフラインにする、或いはその容量を低下させる必要が生じる場合がある。
【００２０】
　絶対測定は、独立した観測から構成される測定が含まれる。一方、他の測定においては独立した結果を得る為に他の観測も計算に入れなければならない。例えば較差測定においては、ある結果を取得する為に１つの観測値を他の値から減算する必要がある。較差測定の一例として、ＳＮＭＰ ＭＩＢの一般的な機能であるカウンタをあげることが出来る。そのようなカウンタの１つはＭＩＢ２インターフェースにあるin-octetsカウンタである。このカウンタの値は、それ自体は決定的な基準を持たない為にあまり有用ではない。この場合の測定とは、時間を隔てた時点におけるカウンタの２つの表示値に基づいたものとなる。
【００２１】
　測定法には、反復性のものと、そうでないものがある。例えば、ＳＮＭＰ統計の測定は周期的な、即ちインターバル型（intervalized）測定に向いている。この場合の測定は、１つ以上のタイムインターバルを含む、インターバル型データ収集となる。他方の測定はボイスコールの持続時間のような、本質的に離散的、即ち単発性である。音声品質及びｐｉｎｇといった測定は、いずれの方式においても用いることが出来る。インターバル型測定については、通常は小さな結果セットを生成することが重要である。インターバル型測定における重要なアプローチは、基底をなす状態についての最良のサマリを提供する生きた統計をとることである。従って、ＰＳＱＭ音声品質測定を繰り返し実行する場合はより概要的な測定結果が記録され、単発で実行する場合はより詳細が記録されることになる。
【００２２】
　進行型測定は完了するまでに一連の中間結果を生成する測定である。これは、各中間結果セットが異なる場合もあるという意味において連続型測定とは異なる。その一例は、トレースルート（trace route）である。この概念は更に、コール設定及び解除を含む音声測定といった段階的測定プロセスにも適用される。この種のテストにおいては、中間結果がどのような頻度で提供可能となるかに応じ、テストの進行と共に部分的な結果をユーザーに対して提供することが有用な場合がある。
【００２３】
　本発明においては、テストエージェント間で状態、進行度の更新及びテスト結果を伝える為の通信が可能となるように様々な機構を採用することが出来る。ある場合においてはエージェントはポーリングされなければならない。他の場合においては、ＳＮＭＰトラップ又は他の機構を通じて非同期通知が提供されるようにすることが出来る。AGILENT Network Analyzerのようなネットワークトラブルシューティングアナライザにおいては、特許登録されたＸＭＬ ＡＰＩを使用することが出来る。
【００２４】
　図２は本発明のＮＴＣ１００（即ち「共通プラットフォーム」）を用いたテスト３００における要素の概略図である。先に述べたように、エージェント１０１ａ〜１０１ｎは、本発明のＮＴＣ１００がサポートする様々なプロトコルをホストするデータソース（「データ提供デバイス」とも称する）である。ＮＴＣ１００は、オペレーション２００ａ〜２００ｃにおいて数々の測定を行う為にＮＴＣが受けるデータの元となる複数のエージェント１０１ａ〜１０１ｎを実装している。図２における測定オペレーションの数は説明の便宜上このように描かれているが、本発明のＮＴＣ１００により実装されたエージェント１０１ａ〜１０１ｎの数と同様、測定オペレーションの数はより多数あっても良い。各エージェント１０１、時にはエージェント群（１０１ｃ〜１０１ｎ）は、測定データを提供することが出来る。各測定においては独立した結果群が提供され、これが他の測定結果と相関させられる場合もある。測定は、生の観測データ、或いはフィルタ又は集計されていることもあり得る下位テストの結果などから構成されることもある。一般に、データが測定されると同期テストを実施することが出来る。しかしながら、以下に説明するように、実際のテスト以前に特定のオペレーションが設定される場合もある。
【００２５】
　図３は、本発明のＮＴＣ１００により実施されるテスト３０１のより詳細な例を示すものであるが、ここでのテスト３０１はオペレーション２００ａ〜２００ｃにおいて異種の測定を行うように構成されたものである。この異種テスト３０１は、ボイスオーバーＩＰ（Voice-over-IP）性能問題のトラブルシューティングに使用することが出来る。音声明瞭度（voice clarity）のエンドツーエンド測定は、オペレーション２００ｃにおいて実施される測定の１つである。更に図示されているのは、ボイスオーバーＩＰコールが通るネットワーク機器のネットワーク統計の２つの測定である。従って図３に描かれたエージェント１０１ａ〜１０１ｎは、ＲＭＯＮ、ＳＮＭＰ及び２つのボイステスタを含むプロトコルをホストするものである。上述したように、これらのプロトコルは説明目的で使用するものであり、本発明のＮＴＣ１００により実現されるプロトコルは他のものであっても良い。問題に対するトラブルシューティングを行う為には、オペレーション２００ａ〜２００ｃにて得られた個々の測定結果をテスト結果表示の一環として相関させることが出来なければならず、これは本発明のＮＴＣ１００により実施される。
【００２６】
　図１に示したように、テストマネージャ１０６はテストがどのように実行されるべきかを管理するものである。換言すると、テストマネージャ１０６は、行われるべき異なる測定間で実行されるテストの調整方法を決定する。例えば、テストマネージャ１０６の一部であるテストオーケストレータ（test orchestrator）（図示せず）が、各エージェントのテストマネージャインタフェース（エージェントマネージャの一部として実現することが出来る特定ドメイン向けテストプラグイン）を呼び出す。テストマネージャインタフェースとは、該当テストの統計に有用な要素を含むように結果ドキュメントをパッケージする方法を認識している、例えばＭＩＢ２、ＲＭＯＮ、ＶＱＴである。これによりテストリポータ及びテストオーケストレータを特定ドメイン向けの認識をもってプログラミングする必要がなくなるのである。
【００２７】
　エージェントマネージャ１０４はどのようにデータを測定するかの管理を提供するものである。エージェントマネージャ１０４及びデータコレクタ１０３は基本的に、測定に対して何を供給する必要があるのかについての特定の認識を持つ２つのユニットである。
【００２８】
　実施すべき測定のテストは定義されなければならない。例えば、テストは１つ以上の測定により構成されている。これらの測定は、同種のものであっても、異種のものであっても良い。実施すべき測定の選択は、ＧＵＩ１０７により決定することが出来る。かわりに、ＡＰＩ１０８を用いた自動処理によって実施すべき測定の選択を決定しても良い。実施すべき測定に関する全てのことは、通常はテストを起動する以前に決定されるものである。かわりに、実施されている１つ又は複数のテスト中に測定パラメータを変更することも出来る。
【００２９】
　テストの種類及びテストの詳細の全てが定義されると、行われるべき各測定の構成設定も用意されなければならない。これらの構成設定は測定に特定的なものであり、通常は何らかのデータ入力により設けられるものである。構成設定を適用する際にＧＵＩ１０７がユーザーをガイドするようにして各測定をユーザーに対して列挙し、ユーザー指定設定を適用することが出来るようになっていても良い。かわりに、構成設定は自動処理によりＡＰＩ１０８を通じて適用することも出来る。必要とされる構成設定が設けられると、テストを起動させることが出来るようになる。設定すべき構成の例としては、例えば何を測定するのか、最終結果はどのようになっているべきか等が含まれる。必要とされる構成設定の他の例としては、ボイスオーバーＩＰ電話呼び出しに関する測定に係わるものがあげられる。この場合においては、特定番号への呼び出し回数の測定が必要とされた場合、その番号そのものが構成設定となり得る。他の可能性のある例として、音声品質の判定が望まれる場合、構成設定はその音声品質を測定する複数の異なる方法のうち、１つの方法を実現するように設定することが出来る。
【００３０】
　構成設定の他の部分は、テストマネージャ１０６が測定実行時にエージェント１０１へと構成設定を送った場合における構成の自律部分である。測定の構成設定を指定するユーザーとそれぞれの測定エージェント１０１ａ〜１０１ｎへの設定情報の送出との間にはデカップリング（decoupling、非干渉化）がある。テストマネージャ１０６はこのデカップリングを実施するものである。
【００３１】
　テスト起動前に取得される構成設定に加え、テスト実施中に提供される新たな構成設定をＧＵＩ１０７又はＡＰＩ１０８を介してＮＴＣ１００へと入力することが出来る。例えば、ＧＵＩ１０７にJavabeanを実現して本発明のＮＴＣ１００（共通プラットフォーム）に新たな構成設定を提供することが出来る。
【００３２】
　実施されるべきいずれの測定も、測定時間の間、排他的にこれに専従させる必要があるリソースを持たせることが出来る。１つ以上のテストを実行することを前提とした場合、リソースの利用を調整する為にいずれかの特定のテストに専従する特定のリソースをそのテストにロックすることが出来、これらを「リソースのロック（locking resources）」とも呼ぶものとする。従って、テストが実行した場合に、テスト又は測定を実施する為に必要とされるリソースに、テストをロックさせることが出来る。テストが完了した場合、或いは実施中のテストがリソースを必要としなくなった場合、そのロックは外される。テストマネージャ１０６は特定のテストに必要とされるリソースロックを実施する為に、これに提供される特定の情報を受信し、利用する。リソースのロックはテストの起動前に実施される。
【００３３】
　テストが開始されると、上述したように異なる種類の測定を実施することが出来る。例えば、離散型測定（トリガ式）、連続型測定、進行型測定等を実施することが出来る。トリガがテストを開始するようになっていても良いし、或いは不連続型テストを実施することも出来る。テストマネージャ１０６が他の測定において必要とされる限りにおいては、このテストマネージャ１０６は連続型測定においては必要とされない。しかしながら、テストマネージャ１０６は異なるタイプの測定を支持することが出来なければならない。例えば、テストマネージャ１０６はテストを開始するべきか、或いは既に実施されている測定をあてにすることが出来る状態なのかを認識している必要がある。従って、この情報（一般にメタ知識（meta-knowledge）と呼ばれる）は、エージェントマネージャ１０４及び／又はデータコレクタ１０３により、シナリオ（実施されるべき異なるタイプのテスト）が支持されるようにテストマネージャ１０６へと提供することが出来る。上述したように、エージェントマネージャ１０４及びデータコレクタ１０３は基本的に、異なる測定を実施する為に供給しなければならないものに関する特定のメタ知識を持つ２つのユニットであり、エージェントマネージャ１０４及びデータコレクタ１０３はテストマネージャ１０６が異なるタイプの測定を支持し得るようにこれに重要なデータを提供するものである。
【００３４】
　本発明の実施例に基づくＮＴＣ１００により取られる測定の時間同期は、テスト管理を調整させる為に必要である。観測される測定の時間同期は、ＮＴＣ１００により様々な方式で行われる。ＳＮＭＰ測定に関しては、例えば通常はデータコレクタ１０３が絶対時間を取得することによりデータにタイムスタンプを記録するが、しかしデータコレクタ１０３はまた、「システムタイムチック（time　ticks）」に基づいて生じた測定の観測に対する相対時間をも保持するものである。システムタイムチックは、通常、何らかの任意の開始時点に相対するものである。管理システムは、現在の時間を現在のシステムタイムチック値と比較し、その後これを絶対時間へとスケーリングすることにより絶対時間スタンプを取得することが出来る。すると、観測に関連する全てのシステムタイムチックは、データ収集システムにおけるデータクロックに相対的なものとなるのである。
【００３５】
　本発明の実施例に基づくＮＴＣ１００は、上述した異なるタイプのプロトコルをホストする多くの異なるタイプのエージェント１０１を実装することが出来るものである。更に、本発明のＮＴＣ１０に実装することが出来る上記に挙げたエージェント１０１の種類、そしてこれらの異なるタイプのエージェント１０１によりホストすることが出来るプロトコルは説明目的で提示したものであり、これらに限られるものではない。
【００３６】
　異なるエージェント１０１はデータの供給に異なる時間同期技術を用いることが知られている。本発明の一実施例に基づくＮＴＣ１００に関して言えば、ＮＴＣ１００と共に利用される異なるエージェント１０１に適用されているこれらの時間同期技術の各々は、ここに実装し、同期させることが出来る。本発明のＮＴＣ１００と共に使用することが出来るエージェントの例を以下に説明するが、これは説明目的に限って提示するものであり、これに限定する意図はない。
【００３７】
　一部のエージェント１０１は、例えばＮＴＰのようなタイムシステムプロトコルを通じて独自の「タイムスタンプ」処理を実施することが出来る。この技術は、分散する測定の同期化を得る為にＮＴＣにより支持されている。エージェントにより提供される他のタイプの時間同期としては、エージェント群に配信される「共通クロック」の所持が含まれ、これは「クロック配信」と呼ばれている。この場合においては、エージェントにおける測定は共通クロックに同期化される。管理ステーションが共通クロックに同期化されることにより、絶対時間が取得される。本発明のＮＴＣシステム１００が支持する他のタイプの時間同期においては、「分散データ収集」が行われる。この場合においては、観測時点が収集されてシステムクロックと比較されることにより、記録が取られる時点で制御が施される。本発明のＮＴＣ１００に実装可能な他のエージェントは、システムクロックに対する相対的な正確性が維持されるように定期的に調整することが出来る独自のシステムクロックを持っている。エージェントがＮＴＰプロトコルのようなアクティブ同期プロトコルを持っている場合、本発明のＮＴＣシステム１００はこの方法を時間同期に用いるものである。本発明のＮＴＣ１００に実装可能な、より一般的な時間同期技術の一部を説明目的で上記にあげたが、本発明のＮＴＣ１００には、例えば絶対時間同期（サーバ間或いはエージェント間のデータ相関に重要）、ＧＰＳ、内部時間ベース（internal time beses）（研究機関レベルの精度を持つ内部時間ベースを必要とする、同期ネットワークにおいて使用されるクロックを使った最も極端な物理レイヤ測定）、管理ステーションポーリングによる同期（ポーリング間隔での測定観測を実施することにより、管理ステーションがデータ同期を提供する）等の他の時間同期技術を実現することも可能である。
【００３８】
　図４〜図６は、テストマネージャ１０６の管理下で行われる上述したタイプの測定のシーケンス図である。図４〜図６に示した本発明のＮＴＣ１００により実施されるこれらのテストは、説明目的に限って提示したものであり、本発明のＮＴＣ１００により実施することが出来る異種間調整型テスト（different orchestrated test）はこれに限られたものではない。
【００３９】
　図４は、単一の離散型測定から構成されたテストを説明するものである。この場合においては、調整型テスト（orchestrated test）は、ユーザー（ＧＵＩ１０７による）、或いは自動処理（ＡＰＩ１０８による）いずれかからの入力が行われるオペレーション５００より開始される。するとオペレーション５０１において、テストマネージャ１０６は、エージェント測定の調整型実施（orchestrated performance）を命令するが、これには所定の時間にどのエージェントが実施されるかが含まれる。その後エージェントマネージャ１０４は、事前構成設定情報５０２及び測定開始の命令５０３を含む測定すべきデータの管理についての具体的な情報（メタ知識）を提供する。エージェントマネージャ１０４によりメタ知識が提供されると、エージェント１０１は測定を実施する。データコレクタ１０３は測定結果を受信し５０４、ＧＵＩ１０７又はＡＰＩ１０８での表示又は保存用にこの結果をテストマネージャへと転送する（５０５）。
【００４０】
　図５は、単一のインターバル型測定から構成されるより複雑なテストを説明するものである。この場合、図４において行われたように、調整型テストは、ユーザー（ＧＵＩ１０７による）、或いは自動処理（ＡＰＩ１０８による）いずれかからの入力が行われるオペレーション５００から開始される。するとオペレーション５０１において、テストマネージャ１０６は、エージェント測定の調整型実施を命令するが、これにはその時点で測定されるべきデータを提供させる為にどのエージェントが実施されるかが含まれる。その後エージェントマネージャ１０４は、事前構成設定情報５０２及び測定開始の命令５０３を含む測定すべきデータの管理についての具体的な情報（メタ知識）を提供する。エージェントマネージャ１０４によりメタ知識が提供されると、エージェント１０１はオペレーション５０４においてデータコレクタへと測定値を提供する。データコレクタ１０３はオペレーション５０４において測定結果を受信し、これを幾つかの時間間隔で繰り返し（例えばオペレーション５０７及び５０８）、そしてオペレーション５０５において集められた結果をテストマネージャ１０６へと転送し、テストマネージャ１０６がオペレーション５０６においてこの結果を表示又は保存用にＧＵＩ１０７又はＡＰＩ１０８へと転送する。
【００４１】
　図６は単一の進行型測定から構成されるテストを説明するものである。この場合、上述したように調整型テストは、ユーザー（ＧＵＩ１０７による）、或いは自動処理（ＡＰＩ１０８による）いずれかからの入力が行われるオペレーション５００から開始される。するとオペレーション５０１において、テストマネージャ１０６は、エージェント測定の調整型実施を命令するが、これにはその時点で測定されるべきデータを提供させる為にどのエージェントが実施されるかが含まれる。その後エージェントマネージャ１０４は、オペレーション５０２における事前構成設定情報及びオペレーション５０３における測定開始の命令を含む測定すべきデータの管理についての具体的な情報（メタ知識）を提供する。エージェントマネージャ１０４によりメタ知識が提供されると、エージェント１０１は測定値を提供する。データコレクタ１０３はオペレーション５０４において測定結果を受信し、これをオペレーション５０５においてテストマネージャ１０６へと転送する。その後エージェント１０１がオペレーション５０８において測定状況を確認し、オペレーション５０９において測定の進行度合いを提供し、そして測定の進行が完了していた場合はオペレーション５１０においてデータコレクタ１０３へと通知する。エージェント１０１が測定の更新（進行）を提供する度にデータコレクタ１０３は更新測定結果をテストマネージャへと送る（例えばオペレーション５１１及び５１２）。テストが完了すると、オペレーション５０６においてＧＵＩ１０７或いはＡＰＩ１０８へと表示用等にその複合測定結果が提供される。
【００４２】
　上述したようにテストが実施されると、結果は１つ以上のデータベース１０５へと記憶される。ＮＴＣ１００に実現することが出来るデータベース１０５の一部としてリレーショナルデータベース及び／又はＸＭＬが含まれる。個々の測定結果は広い範囲で異なることもある為、複数のデータベースが必要となる場合がある。例えば、ホスト名、ネットワークアドレス、プロトコル名、数値データ等を含むリストの結果を記憶する為にリレーショナルデータベースではなくフラットファイル記憶或いはＸＭＬを実現する場合がある。ＸＭＬ又はフラットファイル記憶を使用するケースとしては、パケット取得ダンプ結果を記憶する場合があげられる。
【００４３】
　するとＮＴＣ１００（共通プラットフォーム）は複数の異種の測定を含むテストの結果の集計処理を実施する。結果の集計が終わると、詳細表示を構築して閲覧に供することが出来る。ＮＴＣ１００は更に、以下に図７〜図９に基づいて詳細を説明する表示デバイス４００をも実現するものでもある。
【００４４】
　テスト結果の集計の形式の１つとして、集約（aggregation）が含まれる。本発明の一実施例においては、ＮＴＣ１００はＳＮＭＰデータに適用するＲＹＧ（赤−黄色−緑）変換と呼ばれるメカニズムを使用するものであり、以下の（１）式にこれを示した。
【００４５】
　　ｙ＝ｆ（ｘ）　　　　　　　　　　　　 （１）
　　　ただし、
　　　ｘ＞＝Cmaxの場合、ｙ＝３．０
　　　Cmax＞ｘ≧Tyrの場合、ｙ＝２．０＋（ｘ−Tyr）／（Cmax−Tyr）
　　　Tyr＞ｘ≧Tgyの場合、ｙ＝１．０＋（ｘ−Tgy）／（Tyr−Tgy）
　　　Tgy＞ｘ≧Cminの場合、ｙ＝ｘ／（Tgy−Cmin）
　　　ｘ＜Cminの場合、ｙ＝０．０
注意：正のケースに適用する例をあげたが、この式は負のケース（より高いほうが良いケース）又は入力関数中に複数の正及び負の範囲がある複合ケースに適用するように変更することが出来る。
【００４６】
　ＲＹＧ変換においては、ｘが変換関数への入力、ｙがその出力、Ｃｍｉｎが最小制約数、Ｃｍａｘが最高制約数、Ｔｙｒがｘ値と同じ単位で表された第二のしきい値、Ｔｇｙがｘ値と同じ単位で表された第一のしきい値である。この式は、より高いｘが望ましい負のケース、或いは入力関数に複数の正及び負の範囲がある複合ケース用に変更することが出来る。データを正規化する他の関数を使用することも可能であり、本発明の実施例はＲＹＧ変換に限られたものではない。
【００４７】
　テストアーキテクチャにおいて、ＲＹＧを以下の通りに適用することが出来る。第一に、各観測点における測定結果を最も良好に特性付ける主要メトリクス（key metrics）或いは重要な統計が判別される。その後、適正なしきい値を用いてＲＹＧ変換が適用され、ＲＹＧ連続体におけるいずれかのポイントにマップされる正規化された結果が生成される。例えば、図１０においては２つのしきい値に基づき、ネットワーク装置が使用不可となる時間のパーセンテージを示すグラフが描かれている。第一のしきい値は例えば１．０に正規化されており、第二のしきい値は２．０に正規化されている。緑色部分は通常作動領域であり、黄色部分は警告領域であり、そして赤色部分は危険領域である。この正規化空間においては、主要測定基準はスケールや単位に関係なく併合、比較、及び集計等をすることが出来る。ＲＹＧ変換を用いた正規化データの一例を以下に説明する。０．０から３．０までの連続体における正規化値においては、０．０は最良基準値であり、３．０は劣悪基準値である。第一のしきい値（すなわち正規化値１．０）未満の正規化データについては、緑色を使用することが出来、第一のしきい値（すなわち正規化値１．０）以上かつ第二のしきい値（すなわち正規化値２．０）未満の正規化データについては、黄色を使用することが出来、そして第二のしきい値（すなわち正規化値２．０）以上の正規化データについては赤色を使用することが出来る。使用率測定の場合、ＧＹ（緑・黄）が３３％、ＹＲ（黄・赤）が６６％である。よって３３％が連続体における１．０に正規化され、６６％が連続体における２．０に正規化される。
【００４８】
　本発明の実施例は、赤、黄及び緑の組み合わせに限られたものではない。例えば、他の色又は色をどのように組み合わせたものであっても良い。本発明の実施例は、特定のしきい値範囲に対する特定の色に限られたものではない。例えば、第一のしきい値（すなわち１．０に正規化されたもの）未満の正規化データに赤又は他の色を使用することも可能である。本発明の実施例は、正規化データがしきい値に達した場合に色を変えることだけに限られたものではない。例えば、正規化データは第一のしきい値（すなわち１．０に正規化されたもの）未満の場合に緑色で表示することが出来る。本発明の実施例は、正規化データを縦表示要素毎に複数の色で表示することに限られたものではない。例えば、最も左側の縦表示要素においては、第二のしきい値（すなわち２．０に正規化されたもの）に達していない正規化データを２色ではなく１色で示すように本発明を構成することも可能である。本発明の実施例は、縦表示要素を用いたＸＹ軸グラフに限られたものではない。例えば、カラースプレッドシート又はスキャタプロットを使用することも出来る。本発明の実施例は、一度に１種類及び１セットのみの測定値を表示するものであるとは限らない。例えば、同じ画面上に、各々が異なるタイプの測定値やしきい値等を表す複数のグラフを表示することも可能である。正規化表示はＲＹＧ以外にも、より多くの中間バンドを持つ異なるレベルへと分割することが可能である。ここで重要な概念とは、全ての所望されるポイントが、連続体における１点において定義されるということである。しきい値を用いてあらゆることを正規化スケール上にマッピングすることが出来るのである。
【００４９】
　ＲＹＧ結果を表すために、複数の技術を利用することが出来るが、その幾つかを以下に説明する。
【００５０】
　使用可能な多くの測定結果フォーマットを表すことが出来るのは、ごく一般的なデータモデルだけである点に留意されたい。上述したように、一般的な表現には要約データのみを必要とする為、本発明の他の実施例においては、詳細データ及び特殊な表現を要するデータについてはネイティブユーザーインターフェースを用い、コンテキスト起動を通じてアクセス可能となるものとする。テスト結果の異なるレベルへのゾーンニング・イン（特定レベルへの移動）という形式は「ドリリング（drilling）」と呼ばれ、以下により詳細を説明する。
【００５１】
　要約表現において有用なデータタイプを以下にあげる；
１．１行のテストサマリ
２．一覧チャート及びレーダーチャート等の表現を使用したＲＹＧ集計
３．時間軸相関を含む相関グラフ及びテーブル
４．統合化されたサマリ結果テーブルの一部となり得るサマリ値
５．要約ページからの中間ドリル・ダウンとして表現することが出来る、グラフ及びテーブル用の他の要約データ、及び上記４つの表現からのドリル・ダウンとの関わりを示すコンテキスト起動情報
　この手法は、テストマネージャ１０６からテストリポータ４００（すなわちテスト結果ＧＵＩ画面／表示デバイス）へと送られる可能性のあるシンプルオブジェクトモデル、或いはシンプルＸＭＬドキュメントにより容易に実現することが出来る。以下に説明するＸＭＬ例は説明目的に限って提示するものである。テストリポータ４００（「表示デバイス」とも呼ぶ）は調整型テストの各々からの断片（pieces）を単純に組み合わせ、その説明用表示を要約ページ上に構築する（図７参照）。これにより、今後の用件を実現するような、拡張可能性の非常に高い段階的アプローチが提供される。図７に示されるように、表示デバイス４００に表示された第一の段階においては、テストサマリおよびコンテキスト起動情報１行のみが含まれている。他の断片は、図８に示したように表示デバイス４００上に徐々に追加して行くことが出来る。
【００５２】
　図８においては、「ドリリング」を実施することが出来るアイコンが設けられている。このドリリングにより、ユーザーは、例えば所望される結果の詳細度に応じてテストの１レベルから他のレベルへのテストリポータを起動することが出来る。換言すると、ドリリングによりユーザーはテスト結果の要約表示からテスト結果のより詳細な表示へ、及び逆方向へとインタラクティブにナビゲートすることが出来るのである。更に具体的に説明すると、ナビゲーションリンクはユーザーをより詳細なレベルのテスト結果表示へとナビゲート、即ちドリル・ダウンさせることが出来ると同時に、ネイティブユーザーインターフェースへのナビゲーションを可能とするリンクを起動することによりテスト結果のより上位レベル（要約表示レベル）を閲覧することが出来るのである。
【００５３】
　本発明の一実施例によれば、ＮＴＣ１００の実施したテスト範囲に応じて他のレベルを起動、即ち他のレベルへとドリリングすることにより、テスト結果を説明する追加データフォーマットをテストリポータ４００（表示デバイス）に表示することが出来る。
【００５４】
　図９は、測定結果を集約し、図８の例に基づく個々の結果ドキュメントからテストリポータ４００（表示デバイス）の要約ページを構築した例を示す図である。
【００５５】
　本発明の多くの特徴及び利点が詳細な説明から明らかであり、よって本発明の真の精神及び範囲に入るそれらの特徴及び利点の全ては、本願請求項により網羅することを企図したものである。更に、数々の変更及び改変形態は当業者により容易に想至し得るものである為、本発明は図示及び記載した特定の構造及び作用に限定されるものではなく、よって全ての好適な変更形態及び同等形態は本発明の範囲に入るものである。
【図面の簡単な説明】
【００５６】
【図１】本発明の一態様に基づくネットワークトラブルシューティングセンター（ＮＴＣ）構造を示す図。
【図２】本発明の一態様に基づくＮＴＣを用いたテストの構成部分を示す概要図。
【図３】本発明の一実施例に基づくＮＴＣを用いたテストの一例を示す図。
【図４】本発明の一態様に基づくＮＴＣにより実施される単一の離散型測定から構成されるテストを示す図。
【図５】本発明の一態様に基づくＮＴＣにより実施される単一のインターバル型測定から構成されるテストを示す図。
【図６】本発明の一態様に基づくＮＴＣにより実施される単一の進行型測定から構成されるテストを示す図。
【図７】本発明の一態様に基づく単純なＸＭＬテスト結果ドキュメントの一例を示す図。
【図８】本発明の一態様に基づく複雑な概要ドキュメントの一例を示す図。
【図９】本発明の一態様に基づくテストリポータページにおける集約測定結果の一例を示す図。
【図１０】本発明の一態様に基づくカラー正規化データ表示を示す図。
【符号の説明】
【００５７】
１００　フレームワーク
１０１ａ〜１０１ｎ、１０２　異種の測定
１０３、１０４、１０５、１０６　同期化手段
【図１】
2004088779.tif 000003
【図２】
2004088779.tif 000004
【図３】
2004088779.tif 000005
【図４】
2004088779.tif 000006
【図５】
2004088779.tif 000007
【図６】
2004088779.tif 000008
【図７】
2004088779.tif 000009
【図８】
2004088779.tif 000010
【図９】
2004088779.tif 000011
【図１０】
2004088779.tif 000012