(57)【要約】【課題】通信網に関するトラヒックデータの管理を行うトラヒック管理システムにおいて、システム構築及び維持管理のコストを軽減する。【解決手段】ネットワークで接続され各々がエレメントとして機能する複数のサーバ（Ｓｅｒｖｅｒ）ｉｊ（ｉ＝１〜ｍ、ｊ＝１〜ｎ、ｍ及びｎは自然数を含み、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、それらエレメント全体を１つのトラヒック管理システムとして動作させる。分散データ駆動型アーキテクチャ（Ｄ３Ａ）を用いることにより、従来システムのようなデータの一元管理が不要であり、大規模なデータベースや大規模なサーバを構築する必要がない。また、複数の機能を組み合わせて利用するシステムであり、新しい機能の追加や、機能拡張などにも、他の機能に影響を与えることなく柔軟に対応できる。【選択図】      図１
2006246009.tif 000002
【特許請求の範囲】
【請求項１】
通信網に関するトラヒックデータの管理を行うトラヒック管理システムであって、ネットワークで接続され各々がエレメントとして機能する複数のコンピュータを含み、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、それらエレメント全体を１つのシステムとして動作させる分散データ駆動型アーキテクチャを利用したことを特徴とするトラヒック管理システム。
【請求項２】
前記複数のコンピュータによって実現されるエレメントの少なくとも１つは前記トラヒックデータを蓄積するデータ蓄積エレメントとして機能し、他のエレメントの少なくとも１つは前記データ蓄積エレメントが蓄積しているトラヒックデータを一時記憶するキャッシュ記憶手段を含み、該キャッシュ記憶手段に対してアクセスしても目的とするトラヒックデータを取得できない場合に限り、前記データ蓄積エレメントに対してアクセスすることを特徴とする請求項１記載のトラヒック管理システム。
【請求項３】
トラヒック収集対象となる対向装置からトラヒックデータを定期的に収集するトラヒックデータ収集エレメント、特定のＩＤや識別子を利用者が認識し易く変換する際に必要な変換テーブルとなるトラヒック補助データを収集するトラヒック補助データ収集エレメント、トラヒックデータとそのトラヒック補助データとを記憶蓄積するデータ蓄積エレメント、トラヒックデータとその蓄積先となるデータ蓄積エレメントとの対応表を管理するデータ管理エレメント、収集が必要なトラヒックデータをシナリオに記述するデータ検索制御エレメント、前記シナリオの検索条件に基づいてトラヒックデータを検索するデータ検索実行エレメント、及び、入力される検索条件を解析し、検索条件をシナリオに化するＷｅｂ画面生成エレメント、が前記複数のコンピュータによって実現され、これらエレメントを組み合わせることによって、トラヒック管理機能を実現することを特徴とする請求項１記載のトラヒック管理システム。
【請求項４】
ネットワークで接続された複数のコンピュータ各々をエレメントとして機能させ、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、通信網に関するトラヒックデータの管理を行うことを特徴とするトラヒック管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はトラヒック管理システム、トラヒック管理方法に関し、特に通信網に存在するネットワークエレメントのオペレーションにおけるトラヒック管理システム、トラヒック管理方法に関する。
【背景技術】
【０００２】
従来、通信網オペレーションではトラヒックデータの蓄積および分析・検索機能を有し、対象装置のトラヒックデータを収集し、保存用データの作成・集約といった加工を自動的に実施、蓄積することにより、短時間でこれらのデータ分析作業を可能とし、この分析作業に費やす人手・時間を削減する目的でトラヒック管理システムが開発された（例えば、非特許文献１参照）。
【非特許文献１】ＮＴＴ  ＤｏＣｏＭｏ  Ｒ＆Ｄ−Ｔｅｃｈｎｉｃａｌ  Ｊｏｕｒｎａｌ−ｖｏｌ．８  Ｎｏ．１、[online]、Ａｐｒ．[２００５年２月２３日検索]、インターネット＜ＵＲＬ：2000http://www.nttdocomo.co.jp/corporate/rd/journal/0008_01.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、トラヒック管理に必要となる機能の分離が不十分で新規トラヒック項目追加等に対してシステム本体の開発が必要となり、コストや期間が増大した。また、大量のトラヒックデータを一元管理するため、高速な検索を実現するために大規模なデータベースを用いる必要があり、構築及び維持管理のコストも増大した。
ところで、Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｄｒｉｖｅｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ（以下、Ｄ３Ａと呼ぶ）を用いたトラヒック管理システムは存在しておらず、その実現が期待されていた。このＤ３Ａについては、庄野他による文献“分散型データ駆動型アーキテクチャによるＮＥ−ＯＳＳ構成方法の提案”（２００３ＩＥＩＣＥ総合大会講演論文集（ＣＤ−ＲＯＭ）、Ｂ−６−１０２、Ｍａｒｃｈ、２００３）や、秋山他による文献“ＩＰサービスを実現するための分散データ駆動型アーキテクチャの提案”（ＴＭ２００３−３、Ｎｏ８）に記載されている。
本発明の目的はＤ３Ａを用いることにより、システム構築及び維持管理のコストを軽減できるトラヒック管理システム、トラヒック管理方法を提供することである。
【課題を解決するための手段】
【０００４】
本発明の請求項１によるトラヒック管理システムは、通信網に関するトラヒックデータの管理を行うトラヒック管理システムであって、ネットワークで接続され各々がエレメントとして機能する複数のコンピュータを含み、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、それらエレメント全体を１つのシステムとして動作させる分散データ駆動型アーキテクチャを利用したことを特徴とする。
このような構成によれば、従来のトラヒック管理システムのようなデータの一元管理が不要であり、大規模なデータベースや大規模なサーバを構築する必要がない。
【０００５】
本発明の請求項２によるトラヒック管理システムは、請求項１において、前記複数のコンピュータによって実現されるエレメントの少なくとも１つは前記トラヒックデータを蓄積するデータ蓄積エレメントとして機能し、他のエレメントの少なくとも１つは前記データ蓄積エレメントが蓄積しているトラヒックデータを一時記憶するキャッシュ記憶手段を含み、該キャッシュ記憶手段に対してアクセスしても目的とするトラヒックデータを取得できない場合に限り、前記データ蓄積エレメントに対してアクセスすることを特徴とする。
このように、一度検索したトラヒックデータをキャッシュしているため、同一トラヒックデータにアクセスが集中せず、検索時間が増加することはない。
【０００６】
本発明の請求項３によるトラヒック管理システムは、請求項１において、トラヒック収集対象となる対向装置からトラヒックデータを定期的に収集するトラヒックデータ収集エレメント、特定のＩＤや識別子を利用者が認識し易く変換する際に必要な変換テーブルとなるトラヒック補助データを収集するトラヒック補助データ収集エレメント、トラヒックデータとそのトラヒック補助データとを記憶蓄積するデータ蓄積エレメント、トラヒックデータとその蓄積先となるデータ蓄積エレメントとの対応表を管理するデータ管理エレメント、収集が必要なトラヒックデータをシナリオに記述するデータ検索制御エレメント、前記シナリオの検索条件に基づいてトラヒックデータを検索するデータ検索実行エレメント、及び、入力される検索条件を解析し、検索条件をシナリオに化するＷｅｂ画面生成エレメント、が前記複数のコンピュータによって実現され、これらエレメントを組み合わせることによって、トラヒック管理機能を実現することを特徴とする。
このような構成によれば、複数の機能を組み合わせて利用できるため、新しい機能の追加や、機能拡張などにも、他の機能に影響を与えることなく柔軟に対応できる。
【０００７】
本発明の請求項４によるトラヒック管理方法は、ネットワークで接続された複数のコンピュータ各々をエレメントとして機能させ、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、通信網に関するトラヒックデータの管理を行うことを特徴とする。
このような構成によれば、従来のトラヒック管理システムのようなデータの一元管理が不要であり、大規模なデータベースや大規模なサーバを構築する必要がない。
【発明の効果】
【０００８】
以上説明したように本発明によれば、従来のトラヒック管理システムのようなデータの一元管理が不要であり、大規模なデータベースや大規模なサーバを構築する必要がない。また、複数の機能を組み合わせて利用するシステムであるため、新しい機能の追加や、機能拡張などにも、他の機能に影響を与えることなく柔軟に対応できる。さらに、一度検索したトラヒックデータをキャッシュしているため、同一トラヒックデータにアクセスが集中せず、検索時間が増加しないという効果がある。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態について、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
（システム全体の構成）
本発明では、分散システム構成方法として考案された分散型データ駆動アーキテクチャ（Ｄ３Ａ）をベースとし、これをトラヒック管理システムに適用することによって上記課題を解決する。一般に、集中型システムでは、単一装置においてメインプログラムを動作させ、そこから単機能プロセスを呼び出して処理を実行していく。これに対し、Ｄ３Ａでは、従来のメインプログラムに変わる部分となるＸＭＬ形式のＤ３Ａシナリオが、単機能プロセス（以下、エレメントと呼ぶ）を経由することで各エレメントを組み合わせて分散処理する。例えば、図１に示されているように、複数のサーバ（Ｓｅｒｖｅｒ）ｉｊ（ｉ＝１〜ｍ、ｊ＝１〜ｎ、ｍ及びｎは自然数）がネットワークによって接続され、Ｄ３Ａシナリオを解析し駆動させる役目を持つエンジン・プログラムであるＤ３Ａ基盤が構成される。そして、ネットワークエレメント（ＮＥ）１〜ｍから収集されるトラヒックデータについて作成されたＤ３Ａシナリオに基づく処理及びその受渡し（図１中の矢印参照）を、各サーバ内のプロセッサによって実現されるエレメントが行う。Ｄ３Ａシナリオに基づく処理の結果は、クライアント（Ｃｌｉｅｎｔ）に出力される。
【００１０】
なお、Ｄ３Ａシナリオとは、システム内部の処理命令の手順が記述され、命令を与える処理部や処理結果として返されたデータ格納箇所をもつデータである。
本システムのベースとなる技術は、システムの処理構造について、分散配備されたコンピュータ（例えば、周知のＩＡサーバ）間をギガビットイーサネット（登録商標）で結び、あたかも１つのシステムとして扱えるように工夫されたものであり、Ｄ３Ａで構築されたシステムを使用する利用者側に見える部分ではない。本システムの利用者がＤ３Ａで構築されたシステムに命令を送ると、その命令をシステム側が受け取り、その命令を解析してＤ３Ａシナリオが生成され、それに基づいて動作が行われる。
【００１１】
（各エレメントの機能）
ここで、本例のトラヒック管理システムは、トラヒックデータ収集機能、トラヒック補助データ収集機能、データ蓄積機能、データ管理機能、データ検索制御機能、データ検索実行機能を有する各エレメントで構成され、各エレメント間でＤ３Ａシナリオを受け渡して各機能を組み合わせることで、システム全体としてトラヒック管理業務を実現する。本システムの機能構成例について、図２を参照して説明する。
【００１２】
同図に示されているように、本システムは、トラヒックデータ収集機能を実現するトラヒックデータ収集エレメント１０１と、トラヒック補助データ収集機能を実現するトラヒック補助データ収集エレメント１０２と、データ蓄積機能を実現するデータ蓄積エレメント１０３と、データ管理機能を実現するデータ管理エレメント１０４と、データ検索制御機能を実現するデータ検索制御エレメント１０５と、データ検索実行機能を実現するデータ検索実行エレメント１０６と、Ｗｅｂ画面生成機能を実現するＷｅｂ画面生成エレメント１０７とを含んで構成されている。以下、各機能について、項を分けて説明する。
【００１３】
（１）トラヒックデータ収集エレメント１０１は、トラヒック収集対象となる対向装置からトラヒックデータを定期的に収集し、必要に応じてデータのソートや集約（１時間単位等）などの加工をし、加工後のデータをデータ蓄積エレメント１０３へ転送する。どの蓄積エレメント１０３がどのトラヒックデータを蓄積しているかについてはデータ管理エレメント１０４がコンフィグファイルで管理する。
【００１４】
（２）トラヒック補助データ収集エレメント１０２は、特定のＩＤや識別子を利用者が認識し易い英数字や日本語に変換する際に必要な変換テーブルとなるトラヒック補助データを収集し、集約する。そして加工後のトラヒック補助データをデータ蓄積エレメント１０３へ渡す。このデータ蓄積エレメントにはトラヒック補助データの履歴が記憶されている。このため、過去のトラヒック補助データも参照することができる。そして、データ検索実行エレメント１０６は、データ蓄積エレメントの検索時に、このトラヒック補助データを参照する。
なお、トラヒック補助データは、コンフィグファイル（周知のＸＭＬ形式や周知のＣＳＶ形式等）で記述され、トラヒックデータと同一のデータ蓄積エレメントに配置される。
【００１５】
（３）データ蓄積エレメント１０３は、トラヒックデータとそのトラヒック補助データとを記憶蓄積する。また、トラヒック補助データの履歴を保持することで過去のトラヒック補助データを参照可能とする機能と、検索時にデータ検索実行エレメントにトラヒック補助データを参照させる機能とを有している。
【００１６】
（４）データ管理エレメント１０４は、各々のトラヒックデータとその蓄積先となるデータ蓄積エレメントとの対応表をコンフィグファイルで記録・管理する。そしてトラヒックデータ収集エレメント１０１やデータ検索実行エレメント１０６からのデータ保存先の問い合わせに対して、対応するデータ蓄積エレメントを示す情報を返信する。また、トラヒックデータ収集エレメント１０１によるトラヒックデータの収集対象である、対向装置の情報もコンフィグファイルで記録・管理する。
なお、データ管理エレメント１０４は、あるトラヒックデータに対してそのトラヒックデータ名をホスト名と、そのトラヒックデータを保持するデータ蓄積エレメントのＩＰアドレスとを対応付けてＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）に登録する。こうすることで、他のエレメントは目的のトラヒックデータ名をＤＮＳに問い合わせれば、そのトラヒックデータを持つデータ蓄積エレメントのＩＰアドレスを取得して接続することもできる。
【００１７】
（５）データ検索制御エレメント１０５は検索条件を記述したＤ３ＡシナリオをＷｅｂ画面生成エレメント１０７から受け取り、収集が必要なトラヒックデータをＤ３Ａシナリオに記述してデータ検索実行エレメント１０６に渡す。この際、特定のデータ検索実行エレメント１０６に負荷が偏らないように複数のデータ検索実行エレメント１０６にラウンドロビンでＤ３Ａシナリオを発行し、負荷分散を図る。
そして、データ検索実行エレメント１０６は検索結果を依頼元のデータ検索制御エレメント１０５へ返信し、データ検索制御エレメント１０５はこの検索結果について集約及びソートした上、検索結果としてＷｅｂ画面生成エレメント１０７へ渡す。
また、データ検索実行エレメント１０６は、利用者が希望するトラヒック検索を予め登録しておき定時刻に検索を実施するバッチ管理機能も具備している。
【００１８】
（６）データ検索実行エレメント１０６は、データ検索制御エレメント１０５より受信するＤ３Ａシナリオの検索条件に基づいて、検索条件に適合するトラヒックデータをデータ蓄積エレメント１０３やＤＮＳから収集する。対象となるトラヒックデータがどのデータ蓄積エレメント１０３にあるかどうかについて把握するには、データ管理エレメント１０４やＤＮＳに問い合わせる。この検索結果は検索の依頼元であるデータ検索制御エレメント１０５へ送信する。
また、データ検索実行エレメント１０６では、データ蓄積エレメント１０３から取得したトラヒックデータを一時的にキャッシュしておくことで、頻繁に参照するトラヒックデータに対するアクセス過多を避ける。つまり、データ検索実行エレメント１０６には、キャッシュ記憶手段として機能するキャッシュ記憶部１０８が設けられている。このキャッシュ記憶部１０８については更に後述する。
【００１９】
（７）Ｗｅｂ画面生成エレメント１０７は、利用者端末１００のＷｅｂ画面上で本システムの利用者によって入力される検索条件を解析し、検索条件を抽出してＤ３Ａシナリオ化し、データ検索制御エレメント１０５に渡す。また、Ｗｅｂ画面生成エレメント１０７は、データ検索制御エレメント１０５の応答結果をＷｅｂ画面化し、本システムの利用者のブラウザ画面に表示する。
【００２０】
（トラヒックデータの検索）
以下、図３を参照して、本システムにおけるトラヒックデータの検索動作について説明する。併せて、同一トラヒックデータ（すなわちそれを記憶しているデータ蓄積エレメント）にアクセスが集中することを防ぐためのキャッシュ機能について説明する。
同図には、本システムについて論理的な階層構造として記載されている。すなわち、システムの利用者に関する利用者層、検索の制御を行う検索制御層、検索を実行する検索実行層、データを記憶しているデータ蓄積層、の４層構造をなしている。
【００２１】
まず、本システムの利用者は、パーソナルコンピュータ（ＰＣ）等の利用者端末１００ａ〜１００ｄを起動し、Ｗｅｂブラウザを利用してＷｅｂ画面生成エレメント１０７ａ、１０７ｂにアクセスする。この際、ＤＮＳを利用したラウンドロビンや、ロードバランサ等を利用し、アクセス負荷の分散を図る。なお、ロードバランサは、負荷が分散するように、アクセス先を適切に振り分ける装置である。
【００２２】
次に、Ｗｅｂ画面生成エレメント１０７ａ、１０７ｂは、利用者がＷｅｂ画面に入力した検索条件を抽出し、データ検索制御エレメント１０５ａ〜１０５ｃに検索条件をＤ３Ａシナリオで発行する。このＤ３Ａシナリオを発行する際、ラウンドロビンにより発行先エレメントを決定することにより、アクセス負荷の分散を図る。
Ｄ３Ａシナリオを受取ったデータ検索制御エレメント１０５ａ〜１０５ｃは、そのＤ３Ａシナリオに記載された検索条件を解析し、目的とするトラヒックデータを収集するように、複数のデータ検索実行エレメント１０６ａ〜１０６ｅへＤ３Ａシナリオを発行する。このＤ３Ａシナリオを発行する際、ラウンドロビンにより発行先エレメントを決定することにより、アクセス負荷の分散を図る。
【００２３】
Ｄ３Ａシナリオを受取ったデータ検索実行エレメント１０６ａ〜１０６ｅは、そのＤ３Ａシナリオを解析し、必要なトラヒックデータをデータ蓄積エレメント１０３ａ〜１０３ｃから収集する。どのトラヒックデータがどのデータ蓄積エレメントに保存されているか把握するには各データ蓄積エレメント１０３ａ〜１０３ｃに問い合わせることによって行われる。ただし、予めデータ蓄積エレメントがＤＮＳに登録していた場合は、ＤＮＳへも問い合わせすることができる。
【００２４】
ところで、上述したＤ３Ａを採用した場合でも、特定のトラヒックデータに一斉にアクセスすると、トラヒックデータが適切に読み出せない。一般に、トラヒックデータ管理システムにおいては、１日前のトラヒックデータに対するアクセスが行われることが特に多く、その読み出し速度が低下する。これを解決するため、本例のシステムでは、データ蓄積エレメントに蓄積されているトラヒックデータについてのキャッシュ機能を設けている。
【００２５】
すなわち、図２に示されているように、データ検索実行エレメント１０６ａ〜１０６ｅは、その内部のキャッシュ記憶部１０８に、一度検索したトラヒックデータを一時的にローカルに記憶しておく。そして、再び同じトラヒックデータに対する検索要求があった場合は、キャッシュ記憶部１０８に記憶したトラヒックデータを再利用することで、データ蓄積エレメントに対するアクセス負荷を軽減する。つまり、データ検索実行エレメント内には、データ蓄積エレメントが蓄積しているトラヒックデータを一時記憶するキャッシュ記憶部１０８が設けられており、このキャッシュ記憶部１０８に対してアクセスしても目的とするトラヒックデータを取得できない場合に限り、データ蓄積エレメントに対するアクセスが行われることになる。一度検索したトラヒックデータをキャッシュしているため、同一トラヒックデータにアクセスが集中せず、検索時間が増加することはない。
なお、トラヒックデータを収集したデータ検索実行エレメント１０６ａ〜１０６ｅは、必要な場合はトラヒック補助データを元に、ＩＤ変換テーブル（図示せず）を用いて、特定のＩＤや識別子を英数字や日本語に変換する等、本システムの利用者に理解できる形式にＩＤを変換する。
【００２６】
図３に戻り、トラヒックデータを収集したデータ検索実行エレメント１０６ａ〜１０６ｅは、対象となるトラヒックデータをデータ蓄積エレメント１０３ａ〜１０３ｃから取得すると、それをデータ検索制御エレメント１０５ａ〜１０５ｃへ返信する。
その後、データ検索制御エレメント１０５ａ〜１０５ｃは、データ検索実行エレメント１０６ａ〜１０６ｅから受取った検索結果について、集約やソート等の加工をし、Ｗｅｂ画面生成エレメント１０７ａ、１０７ｂに返信する。そして、Ｗｅｂ画面生成エレメント１０７ａ、１０７ｂでは、それをＷｅｂ画面化し、利用者端末１００ａ〜１００ｄのＷｅｂブラウザに検索結果として表示する。
【００２７】
（新たなトラヒック項目の追加）
ところで、Ｄ３Ａは、シナリオによって複数の機能を組み合わせて使用するシステムであり、新しい機能追加や、特定の機能に対する機能拡張や変更などに柔軟に対応できる。ここで、新しいトラヒック項目を追加する手順について再び図２を参照して説明する。
まず、新しく追加するトラヒック項目を発行する対向装置に対して、トラヒックデータ収集エレメント１０１が接続するために必要な情報や収集周期等をコンフィグファイル（周知のＸＭＬ形式や周知のＣＳＶ形式等で記載するシステム規定値）で記述し、データ管理エレメント１０４に登録する。
【００２８】
次に、そのトラヒックデータを格納するデータ蓄積エレメント１０３を指定する情報を同じくコンフィグファイルで記述し、データ管理エレメント１０４に登録する。また、必要ならば、データ管理エレメント１０４に登録したトラヒックデータ名と、そのデータを保持するデータ蓄積エレメント１０３のＩＰアドレスとを、ＤＮＳに登録しておく。
次に、Ｗｅｂ画面生成エレメント１０７やデータ検索制御エレメント１０５に対して新しいトラヒック項目を検索対象として登録するため、それぞれコンフィグファイルに新しいトラヒック項目を追記する。
【００２９】
また必要な場合、トラヒックデータ中のＩＤや識別子をシステム利用者が認識し易い英数字や日本語等に変換する際に必要な変換テーブルとなるトラヒック補助データをコンフィグファイルで記述し、トラヒック補助データ収集エレメント１０２に登録する。このトラヒック補助データはデータ蓄積エレメント１０３に渡され、利用者端末による検索要求時にデータ検索実行エレメント１０６がそれを参照する。
以上の手順により、新しいトラヒック項目を追加できる。以上の手順においては、すべてコンフィグファイルの変更のみで対応できプログラム自体を変更する必要はないため、システム全体に対する影響は極めて少ない。
【００３０】
（トラヒック管理方法）
上述したシステムでは、以下のようなトラヒック管理方法が実現されている。すなわち、ネットワークで接続された複数のコンピュータ各々をエレメントとして機能させ、それらエレメント間で受け渡されるシナリオデータを、各エレメントにおいて解析し駆動させるプログラムを実行することにより、通信網に関するトラヒックデータの管理を行うトラヒック管理方法が実現されている。このような構成によれば、従来のトラヒック管理システムのようなデータの一元管理が不要であり、大規模なデータベースや大規模なサーバを構築する必要がない。
【００３１】
（まとめ）
以上のように本システムでは、トラヒックデータの保存や検索に大規模なデータベースを利用せず、トラヒックデータをフラットファイル（ＣＳＶ形式等）として保存し、さらに検索処理を分散することで、従来のトラヒック管理システムと同等レベル以上の性能や信頼性を実現できる。そして安価なＩＡサーバやＰＣを組み合わせてシステム構築することで、構築や維持のコストを削減できる。
【００３２】
また、本システムにおいては、以下の有利な効果が得られる。
（１）従来のトラヒック管理システムのように、データを一元管理する必要がないため、大規模なデータベースや大規模なサーバを構築する必要がない。
（２）複数の機能を組み合わせて利用するシステムであるため、新しい機能の追加や、機能拡張などにも、他の機能に影響を与えることなく柔軟に対応できる。
（３）ある機能（エレメント）の性能改善が必要となった場合、機能（エレメント）単位でハード増設やチューニングが可能であり、冗長な設備投資や他の機能（エレメント）を停止させる必要がない。
（４）トラヒック項目追加等に対してもコンフィグファイルの設定で対応できるため、システム（エレメント）本体に対する開発を必要としない。
（５）データ検索実行エレメントに一度検索したトラヒックデータをキャッシュしているため、同一トラヒックデータ（あるいはデータ蓄積エレメント）にアクセスが集中せず、検索時間が増加しない。
【産業上の利用可能性】
【００３３】
本発明は、通信網に存在するネットワークエレメントのオペレーションにおけるトラヒックの管理に利用することができる。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施の形態に係る、Ｄ３Ａを適用したトラヒック管理システムの構成例を示すブロック図である。
【図２】図１のトラヒック管理システムを実現するための各機能を示す図である。
【図３】図１及び図２のトラヒック管理システムを用いたトラヒックデータについての検索動作例を示す概念図である。
【符号の説明】
【００３５】
１００、１００ａ〜１００ｄ  利用者端末
１０１  トラヒックデータ収集エレメント
１０２  トラヒック補助データ収集エレメント
１０３、１０３ａ〜１０３ｃ  データ蓄積エレメント
１０４  データ管理エレメント
１０５、１０５ａ〜１０５ｃ  データ検索制御エレメント
１０６、１０６ａ〜１０６ｅ  データ検索実行エレメント
１０７、１０７ａ、１０７ｂ  画面生成エレメント
１０８  キャッシュ記憶部
【図１】
2006246009.tif 000003
【図２】
2006246009.tif 000004
【図３】
2006246009.tif 000005