JP4104011B2 - トラヒック制御システム、及び、トラヒック制御処理実行方法 - Google Patents

Description

本発明は、トラヒック制御処理を行うトラヒック制御システム、及び、トラヒック制御処理実行方法に関する。

オペレーション業務のひとつとして、トラヒック制御業務が存在する。このトラヒック制御業務のシステム化技術として、特許文献１〜６に記載された技術が知られている。
特許文献１には、トラヒック制御機能の変更をより柔軟にする策として、シナリオマネージャというシナリオ処理機能によりシナリオを読み込み、シナリオ定義ファイルに定義される処理の流れに従って、指定されたシナリオフラグメントという一定の機能単位を呼び出し、順に実行してトラヒック制御を行うという方法が記載されている。

特許文献２には、トラヒック制御目標値のより緻密な適正化策として、輻輳発生時に輻輳通信装置から取得したリソース使用率とトラヒック負荷率の相関関係から目標トラヒック量を算出し、当該目標トラヒック量に基づき上記輻輳通信装置に流入するトラヒック量を規制する方法が記載されている。
特許文献３には、通信網を構成するネットワークエレメント（以下「ＮＥ」という）の輻輳予兆状態を迅速に検出可能とする策として、ＮＥ自身が自身のトラヒック情報に基づいて、輻輳予兆状態にあるか否かの判定を行うことにより、輻輳予兆状態を検出することが記述されている。

特許文献４では、主に、より正確なトラヒック制御方法について記述がなされており、解決手段としてＩＰ網上で送受される通話制御信号を抽出し、抽出された通話制御信号を解析し、端末に対する単位時間あたりの呼の接続数及び不完了呼数を測定し、測定された不完了呼数と所定の閾値とを比較し、比較結果に基づいて輻輳若しくは輻輳の兆候が発生しているか否かを判定する。そして、輻輳が発生していると判定された場合、呼の接続数を制御するにあたっての接続制御量を決定し、接続制御量及び端末を特定するための情報を含む輻輳制御情報を生成して解析し、制御量に基づいて端末への呼に対して呼損処理を行うことにより、呼の接続数を制御することが記述されている。

特許文献５には、仕様変更が頻繁に発生する収集すべきトラヒック項目をプログラムと別構成することにより、新規な輻輳モデルの発生に伴う収集すべきトラヒック項目の追加に対して迅速に対応可能なトラヒック収集装置を提供手段として、トラヒック項目を指定して当該トラヒック項目に対応するトラヒックデータの送信を要求する機能を有するトラヒック収集プログラムにより制御されるトラヒック収集装置において、トラヒック収集プログラムの実行において用いる、ＮＥに送信を要求すべきトラヒック項目の集合体である要求項目定義ファイルを、トラヒック収集プログラムとは独立してかつ更新可能に保持することが記述されている。

特許文献６に記載の技術では、新規規制アルゴリズムを規制アルゴリズム起動中に入れ替えても即座にその新規アルゴリズムにて動作できるようにする手段として、従来１つしか存在しなかったシナリオマネージャを、輻輳の検出から最初の規制制御を発動するまでの初期発動処理用と、その後のネットワークの監視を行いながら適切な規制量にて輻輳直前のところでネットワークトラヒックを安定させることを特定の解除条件を満たすまで継続的に行うフィードバック制御処理用と、の２つのシナリオマネージャに分割する。そして、それらをそれぞれ別々の契機にて起動することにより、発動最中にアルゴリズムを変更した場合でも、その変更後のアルゴリズムによって即時に動作させることができる。

特開２００３−２４４３２０号公報 特開２００３−３０９５９９号公報 特開２００４−１７２７５５号公報 特開２００４−３０４６４６号公報 特開２００４−３６３９４７号公報 特開２００５−０２０１９４号公報

現在、複数機器をネットワークに接続して構成する分散システムが提案され、分散システムの開発が盛んに行われている。分散システムにおいては、安価なハードウェアを用いることができることや、たくさんのマシンを用いることによってシステムの大規模故障が発生しないといったメリットがある。
また、大規模装置でシステム構築する場合、負荷分散、機能分散、収容分散等の思想が働きにくく、機能分割を考えた場合大規模な機能を作っていまい、後の機能追加・修正が困難になることがある。こういった面からも小規模装置を複数接続することによるシステム構成は、分散環境適応への工夫のため必然的に小規模機能の集まりとなり、大規模な機能を分離分割するに当たり共通機能も見えやすくなるため、個別機能を絞り込みやすい。よって、後の機能追加・修正が局所的になり開発効率化が期待できる。このように、ハードウェア構成に柔軟性を持つ分散環境において、トラヒック制御システムとしてもその構築が要求されている。

上述した特許文献１〜６のように、トラヒック制御業務の歴史から様々な関連技術が検討されている。しかしながら、これらは大規模装置による集中管理が主であったこれまでの思想として記述されており、特許文献１〜６におけるトラヒック制御システムにおいては、分散環境適応技術としてどうあるべきかの記述は見られない。

トラヒック制御システムは、多数の外部装置からデータを収集し解析する側面と、集中管理下において多数の外部装置を一斉に制御する側面とを有している。分散環境におけるトラヒック制御を実現するには、多数の外部装置からのトラヒック収集解析、メッセージ収集解析、多数の外部装置へのトラヒック制御処理の実行、トラヒック制御管理、及び、履歴管理、に亘って分散環境に適応させることが必要となる。
本発明は以上のような課題に鑑みてなされたものであり、分散環境においてもトラヒック制御を実現することが可能なトラヒック制御システム、及び、トラヒック制御処理実行方法を提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、相互に通信可能な複数のサーバを含むトラヒック制御システムにおいて、トラヒック制御処理の手順を示す単機能プロセスが記述された制御構成データを管理する制御構成データ管理手段と、トラヒック制御処理の実行命令を受け付けるトラヒック制御実行受付手段と、前記トラヒック制御実行受付手段により受け付けられたトラヒック制御処理を行うための制御構成データを、前記制御構成データ管理手段により管理されている制御構成データの中から選択する制御構成データ選択手段と、前記制御構成データ選択手段により選択された制御構成データを解析する制御構成データ解析手段と、前記制御構成データ解析手段による解析結果に基づいてトラヒック制御処理を実行するトラヒック制御処理実行手段と、前記複数のサーバにおけるトラヒック制御処理の分散実行を制御する実行制御手段とを備え、前記実行制御手段は、前記制御構成データ選択手段により選択された制御構成データに記述されている単機能プロセスのうち、少なくとも一部の単機能プロセスの実行命令をあるサーバから別のサーバに送信することを特徴とする。
この構成によれば、単機能プロセスの実行命令を受けたサーバは、自サーバが備えているトラヒック制御処理実行手段を用いて単機能プロセスを実行することができ、トラヒック制御処理の分散制御を容易に行うことができる。

請求項２に記載の発明は請求項１に記載のトラヒック制御システムにおいて、前記制御構成データ管理手段は、前記制御構成データを記憶しているサーバに関する情報をさらに管理し、前記制御構成データ選択手段は、前記制御構成データ管理手段により管理されている情報に基づいて、前記サーバから前記制御構成データを取得することを特徴とする。
この構成によれば、制御構成データを記憶しているサーバについての情報を管理することにより、制御構成データの所在を容易に把握することができ、トラヒック制御処理に必要となる制御構成データを容易に取得して、トラヒック制御処理を実行することができる。このため、分散環境における効率的なトラヒック制御を実現することができる。

請求項３に記載の発明は、請求項１又は２に記載のトラヒック制御システムにおいて、前記実行制御手段は、サーバ間において前記制御構成データを転送することを特徴とする。
この構成によれば、サーバ間においてトラヒック制御を行うために用いられる制御構成データを転送するため、制御構成データの転送を受けたサーバは、当該制御構成データに基づいてトラヒック制御処理を実行することができ、トラヒック制御処理の分散制御を容易に行うことができる。

請求項４に記載の発明は、請求項１から３の何れか１項に記載のトラヒック制御システムにおいて、前記制御構成データには実行時刻が記述されており、前記実行制御手段は、現在時刻が前記実行時刻と一致したことを検知した場合に、前記制御構成データに基づいたトラヒック制御処理の実行を制御することを特徴とする。
この構成によれば、制御構成データに実行時刻を記述することにより、自動的にトラヒック制御処理の実行を制御することが可能となる。

請求項５に記載の発明は、請求項１から４の何れか１項に記載のトラヒック制御システムにおいて、監視対象の外部装置におけるトラヒック状態を示すトラヒックデータを取得するトラヒックデータ取得手段と、前記トラヒックデータ取得手段により取得されたトラヒックデータに対して、該トラヒックデータを一意に識別するための識別情報を付与するトラヒック項目ＩＤ付与手段と、前記トラヒックデータを共通フォーマットに変換するトラヒックデータ変換手段とをさらに備えることを特徴とする。

この構成によれば、取得したトラヒックデータに対して該トラヒックデータを一意に識別するための識別情報を付与し、また、トラヒックデータを共通フォーマットに変換するため、トラヒックデータの処理ロジックを共通化することができる等、トラヒック制御システム内におけるトラヒックデータの扱いを統一することができ、管理や処理が容易となり、効率的にトラヒック制御を行うことができる。

請求項６に記載の発明は、請求項５に記載のトラヒック制御システムにおいて、前記トラヒックデータを共通フォーマットに計算加工するトラヒックデータ加工手段をさらに備え、前記トラヒック項目ＩＤ付与手段は、前記トラヒックデータ加工手段により計算加工されたトラヒックデータに対して、該計算加工されたトラヒックデータを一意に識別するための識別情報を付与することを特徴とする。
この構成によれば、共通フォーマットに計算加工し、計算加工したトラヒックデータに対しても識別情報を付与するため、計算加工されたトラヒックデータについてもトラヒック制御システム内における扱いを統一することができ、管理や処理が容易となり、効率的にトラヒック制御を行うことができる。

請求項７に記載の発明は、請求項５又は６に記載のトラヒック制御システムにおいて、前記トラヒックデータの扱いを定義したトラヒック項目定義データを記憶するトラヒック項目定義データ記憶手段と、前記トラヒックデータ取得手段により取得されたトラヒックデータと前記トラヒック項目定義データ記憶手段に記憶されているトラヒック項目定義データとを比較することにより、実行すべき処理を決定するトラヒックデータ起因処理決定手段と、前記トラヒックデータ起因処理決定手段により決定された処理の実行命令を行う処理命令手段とをさらに備えることを特徴とする。
この構成によれば、トラヒック項目定義データによりトラヒックデータの扱いを定義することによって、トラヒック項目定義データ内のトラヒック項目を増減したり定義を変更するだけでトラヒックデータの扱いを変更することができ、柔軟かつ容易にトラヒック制御を行うことができる。

請求項８に記載の発明は、請求項１から７の何れか１項に記載のトラヒック制御システムにおいて、外部からの要求に応じて、複数のサーバに分散蓄積されたデータを収集し、該収集されたデータを要求元に返信するデータ集約手段をさらに備えることを特徴とする。
この構成によれば、複数のサーバに分散蓄積されたデータを収集し一括して返信することができるため、ネットワークに負荷をかけずに、分散環境において効率的なデータ取得が可能となる。
請求項９に記載の発明は、複数の外部装置を監視するトラヒック制御システムにおいて、監視対象の外部装置におけるトラヒック状態を示すトラヒックデータを取得するトラヒックデータ取得手段と、前記トラヒックデータの扱いを定義したトラヒック項目定義データを記憶するトラヒック項目定義データ記憶手段と、前記トラヒックデータ取得手段により取得されたトラヒックデータと前記トラヒック項目定義データ記憶手段に記憶されているトラヒック項目定義データとを比較することにより、実行すべき処理を決定するトラヒックデータ起因処理決定手段と、前記トラヒックデータ起因処理決定手段により決定された処理の実行命令を行う処理命令手段と、を備えることを特徴とする。
この構成によれば、トラヒック項目定義データによりトラヒックデータの扱いを定義することによって、トラヒック項目定義データ内のトラヒック項目を増減したり定義を変更するだけでトラヒックデータの扱いを変更することができ、柔軟かつ容易にトラヒック制御を行うことができる。

請求項１０に記載の発明は、複数のサーバで構成されたトラヒック制御システムが行うトラヒック制御処理実行方法において、トラヒック制御処理の実行命令を受け付けるトラヒック制御実行受付ステップと、前記トラヒック制御実行受付ステップにおいて受け付けられたトラヒック制御処理を実行するための制御構成データを取得する制御構成データ取得ステップと、前記制御構成データ取得ステップにおいて取得された制御構成データを解析する制御構成データ解析ステップと、前記制御構成データ解析ステップにおける解析結果に基づいて、前記制御構成データに記述されている単機能プロセスを実行するトラヒック制御処理実行ステップとを有し、前記実行制御ステップでは、前記制御構成データ選択ステップにより選択された制御構成データに記述されている単機能プロセスのうち、少なくとも一部の単機能プロセスの実行命令をあるサーバから別のサーバに送信することを特徴とする。
この方法によれば、前記各ステップは複数のサーバで分散して実行されるため、分散環境においても、制御構成データに基づいてトラヒック制御を実現することができる。

以上のように本発明によれば、前記各手段はトラヒック制御システムに含まれる複数のサーバに分散配備されており、制御構成データに基づいて各サーバに配備された各手段が協働してトラヒック制御処理を実行するため、分散環境におけるトラヒック制御を実現することができる。

次に、図面を参照しながら、本発明を実施するための実施の形態について説明する。図１は、本発明の実施の形態に係るトラヒック制御システム１の構成を示す図である。同図に示すように、トラヒック制御システム１は、ユーザ操作用の通信端末であるトラヒック制御システム操作端末（以下「操作端末」という）３０と、ネットワーク設備であるＮＥ等の外部装置２０と、外部装置２０を監視及び制御する図示せぬＮＥ監視制御装置と、に通信ネットワークを介して接続されている。

トラヒック制御システム１は分散型のシステムであり、分散配備された複数のサーバ１０により構成されている。サーバ１０は、例えば、小型ＩＡサーバである。サーバ１０同士は、ギガビットイーサネット（登録商標）等の通信ネットワークで接続されている。トラヒック制御システム１は、通信網オペレーションに関わる各種トラヒック制御業務を管理及び実行する。
サーバ１０は、ハードウェア構成として、図示せぬＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）とＲＡＭ（Random Access Memory）とハードディスク装置とを含む記憶部、及び、通信ネットワークを介してデータの授受を制御する通信インターフェイスを備えている。

サーバ１０の記憶部には各種ソフトウェアが記憶されている。各種ソフトウェアには、ＯＳ（Operating System）と、Ｊａｖａ（登録商標）実行環境を構築するためのソフトウェアと、後述する制御構成データを解析するためのプログラムと、Ｄ３Ａ（Distributed Data Driven Architecture；分散データ駆動型アーキテクチャ）の処理構成データを解析するためのプログラムと、単機能プロセスを実行するためのプログラムとが含まれている。
図２は、サーバ１０の記憶部に記憶されるソフトウェアやＣＰＵの動作により実現されるソフトウェア環境の一例を説明するための図ある。同図に示すように、サーバ１０のソフトウェア環境は、Ｄ３Ａ層１１とＤ３Ａ上位層１２とで構成されている。

［Ｄ３Ａ層］
Ｄ３Ａ層１１は、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作するＤ３Ａ基盤と、処理構成データ１３及び単機能処理を実行するためのプログラム（以下「単機能プロセス」という）とを含んで構成される。Ｄ３Ａ基盤は処理構成データ１３を解析し、解析結果に従った単機能プロセスの実行を制御する。Ｄ３Ａ基盤及び単機能プロセスはＪａｖａ（登録商標）でコーディングされており、処理構成データ１３はＸＭＬ（eXtensible Markup Language）で記述されている。

ここで、処理構成データ１３とは、システム内部の処理命令の手順が記述され、処理命令を与えるための記述と、処理結果として返されたデータ格納場所とをもつデータである。また、Ｄ３Ａ基盤とは、処理手順が記述されたＤ３Ａシナリオを解析し駆動させる役目を持つエンジンプログラムである。
このように、サーバ１０のソフトウェア環境は、分散システム用に開発されたＤ３Ａをベースとする。集中型システムが単一マシンにおいてメインプログラムを動作させ、そこから単機能プロセスを呼び出して処理を実行していくのに対し、Ｄ３Ａでは、図３の概念図に示すように、従来のメインプログラムに変わる部分となる処理構成データ１３が単機能プロセスを経由して処理を実行していく。

なお、Ｄ３Ａにおいては、処理構成データ１３が処理を実行するのでははく、ＸＭＬで書かれた処理構成データ１３の実行条件をＤ３Ａ基盤が解析し、単機能プロセスに指示を出す。単機能プロセスで処理を行った結果は処理構成データ１３に結果データとして格納され、次の単機能プロセスに処理構成データ１３が駆動される。処理構成データ１３には単機能プロセスを経由する順番が記述されており、ネットワークで接続され分散配備されたマシン間を経由していくことも可能である。指定された単機能プロセスを全て経由し終わると一連の処理が完了したことになる。処理構成データ１３による駆動動作の変更は、単機能プロセスがすでに存在していれば、処理構成データ１３に記述する経路情報を変更すればよいし、単機能プロセスが存在しない、または、既存にある単機能プロセスを変更するような場合には、その単機能プロセスを実現するためのプログラムを適当なマシンに配備し、経路情報を変更することで対応可能である。ユーザの指示により、Ｄ３Ａで構築されたシステムに命令が送られると、システムが命令を受け取り、命令を解析して処理構成データ１３を生成又は取得し動作することになる。

Ｄ３Ａ層１１での役割のひとつとしては、データをシステム１内部で扱いやすい形態に整理整頓する事である。例えば、詳細は後述するが、Ｄ３Ａ層１１では、処理判断に使うためのデータとして定義されたトラヒック項目定義データ１４、及び、メッセージ項目定義データ１５を保持している。また、外部装置２０から取得されるトラヒックデータを扱う場合には、Ｄ３Ａ層１１レベルの単機能として扱われるトラヒックデータ取得変換エンジンとしてのプログラムが用いられる。トラヒックデータ取得変換エンジンは、トラヒック項目定義データ１４を参照し、トラヒックデータを取得し、内部共通フォーマットに変換し、個々のトラヒック項目定義に従った扱いを行う。ここで、トラヒックデータとは、監視対象の外部装置２０におけるトラヒックの状況を示すデータである。また、外部装置２０から取得されるメッセージデータについても、メッセージ取得変換エンジンとしてのプログラムが用いられる。メッセージ取得変換エンジンは、メッセージ項目定義データ１５を参照し、メッセージデータを取得し、内部共通フォーマットに変換し、個々のメッセージ項目定義に従った扱いを行う。何れのエンジンプログラムについても、第一段階としてシステム内部的に流通しやすい形に変えることが第一目的である。第二段階としてその扱い方が定義された定義データ１４，１５を用いて、扱い方を決定し処理する。以上までが、外部装置２０からの取得データに関するＤ３Ａ層１１での処理範囲である。

［Ｄ３Ａ上位層］
Ｄ３Ａ上位層１２は、図２に示すように、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作する制御構成データ解析エンジンと、制御構成データ１６と、単機能プロセスとを含んで構成される。このＤ３Ａ上位層１２を構成するＪａｖａ（登録商標）ＶＭは、Ｄ３Ａ層１１を構成しているものと同一であってもよいし、異なるものであってもよい。制御構成データ解析エンジンは、制御構成データ１６の記述を解析し、解析結果に従って単機能プロセスを実行するためのプログラムである。制御構成データ解析エンジン及び単機能プロセスはＪａｖａ（登録商標）でコーディングされており、制御構成データ１６はＸＭＬで記述されている。

Ｄ３Ａ層１１で行われる処理をシステム内部処理とみなすならば、Ｄ３Ａ上位層１２はＤ３Ａ層１１をベースにしながら、上位層アーキテクチャとして、制御構成データ１６及び処理プログラムからなる個々の単機能プロセスと、Ｄ３Ａ層１１の処理構成データ１３及び個々の単機能プロセスの組み合わせによるＤ３Ａ上位層１２からみた単機能プロセスと、を組み合わせた構造をとる。

ここで、システムの内部処理のために使用される処理構成データ１３と、トラヒック制御システム１における制御構成データ１６との違いを整理する。両者ともＸＭＬで記述されたテキストベースの定義ファイルであり、技術的には共通のものであるが、定義体が異なっている。従って、Ｄ３Ａ基盤は制御構成データ１６を解析することができない。このため、本実施形態に係るトラヒック制御システム１においては、Ｄ３Ａ基盤とは別に、上位アプリケーションとしての制御構成データ解析エンジンを設ける構成とした。なお、このような制御構成データ解析エンジンを設ける構成は一例であり、例えば、Ｄ３Ａ基盤が理解可能な定義体で制御構成データ１６を作成してもよいし、または、Ｄ３Ａ基盤を改造することによりＤ３Ａ基盤が制御構成データ１６を理解できるようにしてもよい。このように、処理構成データ１３と制御構成データ１６とは同一の技術を利用した言語を用いて記述されているため、システム変更、構築上の柔軟性、及び、選択性を確保することができる。なお、本実施形態においては、ソフトウェア環境をＤ３Ａ層１１とＤ３Ａ上位層１２との２段階に構築したが、このような関係の層を複数段階に構築することもできる。段階数は制御構成データと解析エンジンの開発の仕方による。

本実施形態に係るトラヒック制御システム１において、外部装置２０に対する指示展開元はＤ３Ａ上位層１２であり、外部装置２０を制御する手順は主に制御構成データ１６に記述されている。これは、外部装置２０の制御を個々に行うこと自体はＤ３Ａ層１１の処理構成データ１３及び単機能プロセスで実現され、別次元の階層であるＤ３Ａ上位層１２が、それらを道具として多数ある外部装置２０を短時間で制御するためである。このような制御の仕組みは、人的稼動により外部装置２０を一つ一つ選択し、制御していくことを想像すれば理解できる。人的稼動による個々の外部装置２０の制御はＤ３Ａ層１１からの制御を道具として扱う。短時間で多数の制御を実施するためには、多人数の人的稼動を制限された時間内に費やすことが必要であり、かつ、全体を時々刻々と把握しそれぞれの人間にどの外部装置２０に対して何を行わせるかを的確に指示する人的マネージャーが必要である。この組織機能はＤ３Ａ層１１からすれば別次元の指示系統組織である。この指示系統組織は、トラヒック制御システム１におけるＤ３Ａ上位層１２の外部装置２０に対する制御機能に対応する。そして、Ｄ３Ａ上位層１２はＤ３Ａ層１１とは別次元であることや、Ｄ３Ａ上位層１２においても、制御構成データ１６及び単機能プロセス（Ｄ３Ａ層１１における処理構成データ１３及び単機能プロセスの組み合わせにより実現される機能単位は、Ｄ３Ａ上位層１２における単機能プロセスと位置づけられる）の組み合わせによって機能を実現していることからも、外部装置２０制御のために行われるサーバ１０への機能追加・変更の影響を局所化できていると言える。

Ｄ３Ａ上位層１２から指示された後の、実質的な外部装置２０の制御はＤ３Ａ層１１が担うことになる。Ｄ３Ａ層１１はＤ３Ａ上位層１２にとって道具とみなされ、実質的な外部装置２０の制御は道具であるＤ３Ａ層１１が行う処理となっている。例えば、外部装置２０からの情報を取得する処理は、まずＤ３Ａ層１１が行う。外部装置２０から取得される情報としては、主にはトラヒックデータやメッセージデータがあり、これらの情報についてもＤ３Ａ上位層１２からすれば、ひとつの道具として扱うことになる。

先に示したとおり、外部装置２０に対する指示展開元はＤ３Ａ上位層１２により実現される。例えば、外部装置２０への制御指示を行う上での関連トラヒック状況把握及び解析、または、制御指示後の制御状況把握及び解析を行う上で、トラヒックデータを利用する事においても同様である。そのトラヒックデータを収集する手順は、主に制御構成データ１６に記述されている。これらについても、先に述べたように、外部装置２０からのデータ取得を個々に行うこと自体はＤ３Ａ層１１の処理構成データ１３及び単機能プロセスで実現可能であるが、それらを道具とする別次元の階層であるＤ３Ａ上位層１２は、各々のトラヒック制御実行方法に合わせて、多数ある外部装置２０から必要なデータのみを収集及び解析する。

［制御構成データ］
次に、制御構成データ１６について説明する。制御構成データ１６にはトラヒック制御処理の一連の手順が記述されている。トラヒック制御処理の手順は、トラヒック制御処理の手順毎の処理内容である単機能プロセスと、該単機能プロセスの実行順序とで表すことができる。図４には、制御構成データ１６のデータ構成の一例を示す。なお、実際には、この制御構成データ１６はＸＭＬ等の言語で記述される。

ここで、ユーザがシステムに対して単純な命令を行い、ＸＭＬで記述されたＤ３Ａレベルの処理構成データ１３により単機能プロセスとしてのプログラムが次々と処理されて処理が完結するまでをひとつの単業務機能とする。この単業務機能は、ユーザにとってみればひとつの単機能プロセスと捉えることもできる。本実施形態においては、トラヒック制御処理の手順を示す単機能プロセスの集合を制御構成データ１６という形で定義し、制御構成データ１６の記述に沿って動作させることによってトラヒック制御処理を実現する。

制御構成データ１６の記述においては、処理構成データ１３の記述と異なり、実行すべき単機能プロセスを識別するための情報として、プログラム名の代わりに他の制御構成データ名や単業務機能名を記述することが可能である。すなわち、制御構成データ１６には、実施すべき単機能プロセスを表す情報として、実行すべきプログラムと、Ｄ３Ａレベルにおいて解析すべき単業務機能と、解析すべき他の制御構成データ１６と、の少なくとも１を識別するための情報を記述することができる。従って、ある制御構成データ１６が扱う単機能プロセスは、プログラムにより実行される処理と、処理構成データ１３を解析することにより実行される処理と、他の制御構成データ１６を解析することにより実行される処理と、を含むこととなる。

このように、制御構成データ１６によって定義されたトラヒック制御処理の実行手順において、同一の処理については他の制御構成データ１６や処理構成データ１３、プログラムを再利用可能であるという利点が得られる。本実施形態に係る制御構成データ１６を用いることで、同一手順を複数回行うようなトラヒック制御処理において開発効率化を図ることができる。また、ＸＭＬのような簡易な言語を用いて制御構成データ１６を記述していることにより、処理を実行する際の経路、プログラム、単業務機能、他の制御構成データ１６等の選択実行指示等について、変更、追加及び削除を容易に行うことができる。単機能プロセスとしてのプログラムは、あくまでも単機能プロセスとしての最小限プログラムであるため、変更等によるシステム全体としての影響範囲を小さくすることができる。

この制御構成データ１６には、制御構成データ１６に基づいたトラヒック制御処理を実行すべき時刻として実行時刻を記述することもできる。また、発動日時、終了日時、単機能プロセス毎の実行時刻等、複数の実行時刻を制御構成データ１６に記述することもできる。
制御構成データ１６は、あらかじめ生成して各サーバ１０の記憶部に記憶しておく他に、ユーザが操作端末３０を用いて編集することができる。ユーザが制御構成データ１６を編集する場合には、サーバ１０の記憶部に制御構成データ１６のデフォルトフォーマットをあらかじめ記憶させておく。操作端末３０からのユーザ指示により、デフォルトフォーマットが操作端末３０に表示される。ユーザが、表示されたデフォルトフォーマットの中の指定すべき部分を埋めることにより、制御構成データ１６を編集する。ユーザが指定可能な情報の一例としては、発動日時、終了日時等の実行時刻情報や、制御する外部装置２０等である。また、Ｄ３Ａのアーキテクチャに従った制御構成データ編集専用のクライアント端末を用意してもよい。ユーザは、デフォルトで用意されている制御構成データ１６を制御構成データ１６作成の補助として利用することができる。このように、制御構成データ１６に従ったトラヒック制御処理の時刻の指定や、制御構成データ１６に記述されている手順を柔軟に変えることができるようにすることで、一連のトラヒック制御処理についての柔軟性を確保することができる。

［トラヒック項目定義データ、メッセージ項目定義データ］
次に、トラヒック項目定義データ１４について説明する。トラヒック項目定義データ１４には、取得したトラヒックデータについてのトラヒック制御システム１内部での扱い方の定義が示されている。同様に、メッセージデータについては、取得したメッセージデータについてのシステム１内部での扱い方の定義が示されている。

図５には、トラヒック項目定義データ１４の一例を示す。同図に示すように、トラヒック項目定義データ１４には、トラヒック項目毎の名称、取得周期、差分データか累積データか、外部装置２０単位なのか外部装置２０を構成する内部装置単位なのか、通信対地単位なのか、サービス単位なのか、計算されて生成されるものか、呼び出すプログラム名等々、複数の定義が記述されている。例えば、取得して共通フォーマットへ変換されたトラヒックデータを一次トラヒックデータ、計算加工されて生成されるデータを二次トラヒックデータとするならば、二次トラヒックデータとして定義されているトラヒック項目には、生成が「True」と記述され、生成ロジックには該当するプログラム番号が示されている。そのプログラムは、簡素なものであるが、例えば、計算に使用するための１つ又は複数の１次トラヒックデータのトラヒック項目ＩＤを埋め込んだ計算プログラムである。

メッセージ項目定義データ１５についても、メッセージ項目毎の名称や内部で使用されるＩＤ等が記述されており、基本的な考え方はトラヒック項目定義データ１４と同様である。このため、メッセージデータをトラヒックデータの概念に含めて考えることができる。また、メッセージ項目定義データ１５をトラヒック項目定義データ１４の概念に含めて考えることができる。このため、以下では、主にトラヒックデータ及びトラヒック項目定義データ１４について説明することとする。

ただし、トラヒックデータは基本的には周期的に送られてくるものであり、かつ、数値データであり、かつ、数値計算可能データである。それと比較すると、メッセージデータは不定期データであり、かつ、数値や文字の混合データであり、かつ、基本的には数値計算不可能である。メッセージデータにおいては、そのメッセージの緊急度ランクや、内部処理トリガになるものか蓄積だけか、蓄積先の分類はどうか、等の定義が示されている。

これらのトラヒック項目定義データ１４及びメッセージ項目定義データ１５は、プログラムに埋め込みされるものではなく、日常使用している表計算ソフト等に記載されたものを、簡易な変換でシステム内データとして記憶部に記憶する形をとる。トラヒック項目定義データ１４及びメッセージ項目定義データ１５のデータ形式は、例えばＣＳＶデータやＸＭＬデータ等である。よって、定義内容を検討する段階で作成したドキュメントを転記やプログラミングする必要がなく、トラヒック項目定義及びメッセージ項目定義に関わるトラヒック制御システム１への影響を最小限に抑えることができる。

このように、トラヒック項目定義データ１４やメッセージ項目定義データ１５を単なる意味名称のデータとせずに、システム内部の扱いを定義するデータとすることによって、トラヒック項目やメッセージ項目の増減を柔軟に行うことができるだけでなく、監視面においてもネットワークの監視ポリシーに沿うように柔軟に変更対応することが可能となる。

［機能構成］
次に、トラヒック制御システム１の機能構成について説明する。トラヒック制御システム１を構成する各サーバ１０が備える上述したハードウェア及びソフトウェアにより、図６に示す各機能部が実現される。なお、トラヒック制御システム１では分散制御が行われるため、トラヒック制御システム１を構成するサーバ１０全てが図６に示す機能部全てを備えている必要はない。つまり、図６に示す各機能部がトラヒック制御システム１を構成する少なくとも１つのサーバ１０に備わっており、トラヒック制御システム１全体として図６に示す全ての機能部が備わっていればよい。
同図に示すトラヒック制御実行受付部１０１は、通信インターフェイスを含んで構成され、トラヒック制御の実行命令を受け付ける。このとき受け付ける実行命令は、制御構成データ１６による実行命令である場合もあるし、他のデータ形式による実行命令である場合もある。

また、実行命令の送信元は、操作端末３０である場合もあるし、トラヒック制御システム１内の他のサーバ１０である場合もあるし、自サーバ１０である場合もある。例えば、トラヒック制御システム１を構成するサーバ１０がトラヒック状態を判断した場合に、サーバ１０の処理命令部１１４からトラヒック制御の実行命令が送信される場合がある。トラヒック状態の判断方法としては、例えば、トラヒックデータの値による判断やメッセージデータ内容による判断等が考えられる。なお、トラヒック制御実行受付部１０１がトラヒック制御システム１内に分散配備されている場合には、例えば、トラヒック制御実行受付部１０１が配備されているサーバ１０についての情報を管理しておくことで、分散制御可能である。

制御構成データ管理部１０２は、サーバ１０の記憶部に記憶されている制御構成データ１６で構成される。制御構成データ管理部１０２は、自サーバ１０に記憶されている制御構成データ１６を管理する他、様々な用途の複数種類の制御構成データ１６がどのサーバ１０に分散配備されているかを管理する手法をとることも可能である。
制御構成データ管理部１０２における制御構成データ１６の管理手法を具体的に説明すると、複数のサーバ１０に制御構成データ１６が配備されている場合において、制御構成データ管理部１０２が自サーバ１０に記憶されている制御構成データ１６のみを管理する場合、複数のサーバ１０各々で管理されている制御構成データ１６を同一とすることで、サーバ１０の選択を任意に行うことができ、負荷分散可能である。

一方、制御構成データ管理部１０２が自サーバ１０に記憶されている制御構成データ１６に加えて、他の制御構成データ１６がどのサーバ１０に配備されているかを管理する場合、複数のサーバ１０各々で管理されている制御構成データ１６は互いに異なるものとなるが、制御構成データ管理部１０２が管理している情報に基づいてサーバ１０の選択を任意に行うことが可能であり、役割分散可能である。なお、このような他の制御構成データ１６がどのサーバ１０に配備されているかを管理する機能を制御構成データ管理部１０２から切り出し、この機能に基づいて、サーバ１０選択の時点で、必要な制御構成データ１６を配備しているサーバ１０を選択することにより、制御構成データ管理部１０２は自サーバ１０に記憶されている制御構成データ１６のみを管理することが可能である。

制御構成データ選択部１０３は、トラヒック制御実行受付部１０１により受け付けられたトラヒック制御を行うための制御構成データ１６を、制御構成データ管理部１０２により管理されているデータの中から選択する。なお、制御構成データ選択部１０３は、他のサーバ１０に分散配備されている制御構成データ管理部１０２から制御構成データ１６を取得してもよい。この場合、制御構成データ選択部１０３は、ポーリングを行ったり、又は、制御構成データ管理部１０２により管理されている制御構成データ１６の分散配備に関する情報に基づいて、トラヒック制御のために必要となる制御構成データ１６を他のサーバ１０から取得する。

制御構成データ解析部１０４は、制御構成データ解析エンジンを含んで構成され、制御構成データ選択部１０３が選択した制御構成データ１６を解析する。
トラヒック制御処理実行部１０５は単機能プロセスを含んで構成され、制御構成データ解析部１０４による解析結果に基づいて実行命令を受けた場合に、トラヒック制御処理を実行する。
実行制御部１０６は、複数のサーバ１０におけるトラヒック制御処理の分散実行を制御する。
ここで、トラヒック制御処理の実行制御は、制御構成データ１６を制御構成データ解析エンジンで解析させ、実行すべきプログラムを選択し、実行命令を出す、という基本的な処理方式の基に行われるが、このトラヒック制御処理の実行制御方式には、大別すると次の２つの方式がある。

第１の方式では、トラヒック制御システム１において使用する制御構成データ１６が複数あっても、ある１つのサーバ１０の制御構成データ解析部１０４が制御構成データ１６を解析し、順次、実行させるべき単機能プロセスや他の制御構成データ１６を選択及び実行することを繰り返す。このように、第１の方式は、はじめに担当した制御構成データ解析エンジンが、トラヒック制御処理が完了するまで全てを担う方式である。

第２の方式では、分散配置されたサーバ１０の制御構成データ解析エンジンが、他のサーバ１０から受け取った制御構成データ１６を解析し、解析結果に基づいて自サーバ１０内のプログラムを起動して自サーバ１０が担当する処理を行った後、次に処理を行うべきサーバ１０に制御構成データ１６を転送することにより、処理の制御を次のサーバ１０に移すという方式である。

上記何れの実行制御方式においても、実行制御部１０６が複数のサーバ１０におけるトラヒック制御処理の分散実行を制御する。実行制御部１０６が行う分散実行制御には、制御構成データ１６と、トラヒック制御処理の実行命令と、単機能プロセスの実行命令との少なくとも１つを、サーバ１０間において転送することが含まれる。

具体的には、実行制御部１０６は、制御構成データ解析部１０４が制御構成データ１６を解析した結果、制御構成データ１６に基づいたトラヒック制御処理を実行すべき他のサーバ名が制御構成データ１６に記述されている場合には、当該サーバ名で識別されるサーバ１０に対して制御構成データ１６を転送する。また、実行制御部１０６は、制御構成データ１６に経路情報が記述されていて、当該経路情報により所定の単機能プロセスを実行すべきサーバ１０が指定されている場合には、所定の単機能プロセスを実行すべきサーバ１０に対して所定の単機能プロセスの実行命令を送信する。また、所定の単機能プロセスを実行する機能がどのサーバ１０に存在するかが制御構成データ１６に記述されている場合には、所定の単機能プロセスを実行する機能を有しているサーバ１０の中から選択した１又は複数のサーバ１０に対して所定の単機能プロセスの実行命令を送信する。このような実行命令の転送の仕組みにより、単機能プロセス毎にまとめられた共通的な機能をトラヒック制御システム１内に分散配備することも可能となる。

また、実行制御部１０６は、制御構成データ１６に記述されている内容に関わらず、自サーバ１０の処理負荷が高いために制御構成データ１６を解析してトラヒック制御処理を行うのが困難であると判定した場合には、自サーバ１０よりも処理負荷が低い他のサーバ１０又は処理能力が相対的に高いサーバ１０に対して制御構成データ１６を転送する。

また、実行制御部１０６は、自サーバ１０が制御構成データ解析部１０４を備えていない場合にも、制御構成データ解析部１０４を備えているサーバ１０に対して制御構成データ１６を転送する。このように、制御構成データ１６が配備されているサーバ１０に、その制御構成データ１６を解析するための制御構成データ解析部１０４が配備されていないとしても、制御構成データ１６を制御構成データ解析部１０４が配備されている他のサーバ１０に転送することによりその後の処理の駆動が可能となる。

また、トラヒック制御処理を実行すべきサーバ１０に関する情報がサーバ１０の記憶部にあらかじめ記憶されている場合には、実行制御部１０６は、トラヒック制御実行受付部１０１が受信したトラヒック制御処理の実行命令をそのサーバ１０に対して転送する。また、トラヒック制御処理の実行命令を受信した時点で自サーバ１０の処理負荷が基準値よりも高かった場合にも、実行制御部１０６は、受信したトラヒック制御処理の実行命令を、より処理負荷が低い別のサーバ１０に転送する。

以上のように、制御構成データ１６が解析された時点や、制御構成データ１６を解析する前や、トラヒック制御処理の実行命令を受け付けた時点等において、様々な原因要素によりトラヒック制御処理のサーバ１０間移動が可能となる。なお、実行制御部１０６は、どのサーバ１０で処理を継続するのが最も効率的かを判定してから、トラヒック制御処理のサーバ１０間移動を行うようにしてもよい。 図７は、上述した第１の実行制御方式におけるトラヒック制御処理のフローチャートである。同図を参照しながら、あるサーバ１０におけるトラヒック制御処理の実行手順を説明する。

まず、サーバ１０のトラヒック制御実行受付部１０１は、操作端末３０からトラヒック制御処理の実行命令を受け付ける（ステップＳ１０１）。制御構成データ選択部１０３は、受け付けられた実行命令に従い、制御構成データ管理部１０２で管理されているデータの中から該当する制御構成データ１６を選択する（ステップＳ１０２）。制御構成データ解析部１０４は、選択された制御構成データ１６を解析する（ステップＳ１０３）。

実行制御部１０６は、制御構成データ１６に記述された実行順序に従って、単機能プロセスの実行命令を、当該単機能プロセスを実行すべきサーバ１０に対して順次送信する（ステップＳ１０４；Ｎｏ、ステップＳ１０５）。各サーバ１０のトラヒック制御処理実行部１０５は、実行命令に従ってトラヒック制御処理の単機能プロセスを実行し、実行結果を通知するための応答メッセージを返信する。
実行制御部１０６は、制御構成データ１６に記述された単機能プロセス分全て実行命令を送信し終わるまで（ステップＳ１０４；Ｙｅｓ）、単機能プロセスの実行命令の送信を繰り返す。

図８は、第２の実行制御方式におけるトラヒック制御処理のフローチャートである。同図を参照しながら、あるサーバ１０におけるトラヒック制御処理の実行手順を説明する。
まず、サーバ１０のトラヒック制御実行受付部１０１は、操作端末３０からトラヒック制御処理の実行命令を受け付ける（ステップＳ２０１）。実行制御部１０６は、受け付けられたトラヒック制御処理が自サーバ１０で行うべき処理か否かを判定する（ステップＳ２０２）。具体的には、受け付けられたトラヒック制御処理を行うべきサーバ１０があらかじめ指定されているか、また、自サーバ１０の処理負荷が現在高いか、受け付けられたトラヒック制御処理を行うための制御構成データ１６を自サーバ１０が保持しているか否か等、様々な要因を勘案することにより、実行制御部１０６は受け付けられたトラヒック制御処理を自サーバ１０で行うべき処理か否かを判定する。

判定した結果、自サーバ１０で行うべき処理でないと判定された場合に（ステップＳ２０２；Ｎｏ）、実行制御部１０６は、トラヒック制御処理の実行命令を他のサーバ１０に送信する。一方、自サーバ１０で行うべき処理であると判定された場合に（ステップＳ２０２；Ｙｅｓ）、制御構成データ選択部１０３は、受け付けられた実行命令に従い、自サーバ１０又は他サーバ１０に配備された制御構成データ管理部１０２で管理されているデータの中から、該当する制御構成データ１６を選択する（ステップＳ２０４）。

制御構成データ１６を選択した時点で、実行制御部１０６は制御構成データ１６の解析処理を自サーバ１０で行うべきかを判定する（ステップＳ２０５）。具体的には、自サーバ１０が制御構成データ１６を解析するための制御構成データ解析部１０４を備えているか否か、及び、自サーバ１０における現在の処理負荷の状態等に基づいて、実行制御部１０６は、制御構成データ１６の解析処理を自サーバ１０で行うべきか否かを判定する。

解析処理を自サーバ１０で行うべきでないと判定された場合には（ステップＳ２０５；Ｎｏ）、選択した制御構成データ１６を他のサーバ１０に送信する（ステップＳ２０６）。一方、解析処理を自サーバ１０で行うべきであると判定された場合には（ステップＳ２０５；Ｙｅｓ）、制御構成データ解析部１０４は、制御構成データ選択部１０３により選択された制御構成データ１６を解析する（ステップＳ２０７）。

解析した結果、制御構成データ１６に基づくトラヒック制御処理は他のサーバ１０で行うべき処理であることが制御構成データ１６に記述されていたり、当該制御構成データ１６に基づくトラヒック制御処理を自サーバ１０で行うには処理負荷が高すぎると判定された場合、実行制御部１０６は、当該トラヒック制御処理は他サーバ１０で行うべき処理であると判定し（ステップＳ２０８；Ｎｏ）、制御構成データ１６を他のサーバ１０に送信する（ステップＳ２０６）。

一方、自サーバ１０で制御構成データ１６に基づいてトラヒック制御処理を実行すべきであると判定された場合には（ステップＳ２０８；Ｙｅｓ）、実行制御部１０６は、制御構成データ１６に記述されている次に実行すべき単機能プロセスは自サーバ１０で行うべき処理かを判定する（ステップＳ２０９）。
自サーバ１０が当該単機能プロセスの実行機能を保持していなかったり、制御構成データ１６に他サーバ１０での実行指定が記述されていた場合には、実行制御部１０６は、当該単機能プロセスは自サーバ１０で行うべき処理でないと判断し（ステップＳ２０９；Ｎｏ）、当該単機能プロセス以降の実行命令を含んだ制御構成データ１６を他のサーバ１０に送信する（ステップＳ２０６）。

一方、自サーバ１０で単機能プロセスを実行すべきであると判断された場合には（ステップＳ２０９；Ｙｅｓ）、実行制御部１０６はトラヒック制御処理実行部１０５に単機能プロセスの実行を指示する。トラヒック制御処理実行部１０５は指示を受けて単機能プロセスを実行する（ステップＳ２１０）。次に実行すべき単機能プロセスが制御構成データ１６に記述されている場合に（ステップＳ２１１；Ｎｏ）、次の単機能プロセスの実行処理を繰り返す（ステップＳ２０９〜Ｓ２１１）。

また、実行制御部１０６は、制御構成データ１６に実行時刻が記述されており、かつ、タイマー管理機能からの通知により現在時刻が実行時刻と一致したことを検知した時に、制御構成データ１６に基づいたトラヒック制御処理の実行を制御する。例えば、実行制御部１０６は、制御構成データ１６の解析結果に基づいて、トラヒック制御実行受付部１０１に対してトラヒック制御処理の実行命令を行う。また、制御構成データ１６に複数の時刻が記述されている場合には、実行制御部１０６は、記述されている時刻の内容（起動時刻、停止時刻、中断時刻等）に応じて、処理の起動、停止等の制御を行う。

また、トラヒック制御システム１は、実行時刻指定による実行制御のような外部からの指示ではなく、システム１が振る舞いを判断して実行制御する機能も備えている。例えば、トラヒックデータの値による判断、メッセージデータ内容による判断がある。トラヒックデータの値による判断で代表的なものは、監視されているトラヒックデータ値がある値を超えた場合に、あらかじめ決められたトラヒック制御処理を実行するというようなものがある。また、メッセージデータの内容による判断で代表的なものは、ある監視対象のメッセージが受信された場合、あらかじめ決められた制御を実行するというようなものがある。これらの判断には、トラヒック項目定義データ１４やメッセージ項目定義データ１５が用いられ、トラヒック起因処理決定部１１３及び処理命令部１１４により判断、実行される。

また、トラヒック制御システム１は、トラヒック制御処理の実行履歴を管理する機能を有している。制御実行した履歴がどのサーバ１０に存在するかは存在先のルール規定、ポーリング、参照先を管理する機能に問い合わせるなどをして参照可能であるため、実行履歴についても分散配備可能となる。

次に、トラヒックデータに関わる機能部について説明する。
トラヒック項目定義データ記憶部１１０は、サーバ１０の記憶部に記憶されたトラヒック項目定義データ１４で構成される。ここでも、トラヒック項目定義データ記憶部１１０を複数のサーバ１０に分散配備することが可能である。つまり、トラヒック項目定義データ１４の定義を扱うサーバ１０にトラヒック項目定義データ１４を複製しても、特定のサーバ１０にトラヒック項目定義データ記憶部１１０を配備して問合せをするようにしても、他の付随する手段の分散配備に影響を与えない。

トラヒックデータ取得部１１１は、外部装置２０等からトラヒックデータを取得する。トラヒックデータ取得部１１１を複数のサーバ１０に分散配置することで、外部装置２０の数が増加しても負荷分散を行うことができる。
トラヒック項目ＩＤ付与部１１２は、トラヒックデータ取得部１１１により取得されたトラヒックデータに対して、当該トラヒックデータをトラヒック制御システム１において一意に識別するためのトラヒック項目ＩＤを付与する。さらに、トラヒック項目ＩＤ付与部１１２は、トラヒックデータ加工部１１６により加工された２次加工トラヒックデータに対しても、当該２次加工トラヒックデータを一意に識別するための２次トラヒック項目ＩＤを付与する。

このように、トラヒック制御システム１内で一意に識別可能にトラヒック項目ＩＤを付与することで、外部装置２０の種類に閉じない共通のトラヒックデータの扱いが可能となり、多面的なデータの活用が可能となる。例えば、サーバ１０が自サーバ１０に蓄積されたトラヒックデータに対する収集要求に対して応答する場合、要求されたトラヒック項目ＩＤと要求された条件とにしたがってトラヒックデータを応答することができる。トラヒックデータが分散取得され、かつ、分散蓄積されていたとしても、サーバ１０がトラヒック制御をはじめとするトラヒックデータを必要とする業務に関わる機能を有している場合、トラヒックデータ取得場所、蓄積場所、トラヒック項目ＩＤ等を管理することにより、トラヒックデータを収集することが可能である。

トラヒックデータ変換部１１５は、取得したトラヒックデータをあらかじめ定められた共通フォーマットに変換する。トラヒックデータは様々なデータフォーマットで取得される。例えば、Ｄ３Ａレベルの処理構成データ１３によって取得されたものや、単純なファイル転送で取得されたものが存在する。処理構成データ１３で取得されたデータには、データ内容がどういった種類のデータであるかがタグとして記述されているため、タグを認識して別のフォーマットに変換すべきデータかテキストとして読み取ってよいデータかの判断が可能である。単純なファイル転送の場合は、通信相手との約束事に従ってどのようなデータフォーマットのデータが転送されてくるかをあらかじめ認識しておく。

本実施形態においては、トラヒックデータそれぞれの個別フォーマットから共通フォーマットへ変換するためのプログラムは基本機能のみを有している。トラヒックデータ変換部１１５は、当該プログラムをＣＰＵで実行されることによりトラヒックデータを共通フォーマットに変換する。さらに、変換時に付与するトラヒック項目ＩＤ等については、トラヒック項目ＩＤ付与部１１２がトラヒック項目定義データ１４を読み取って判断する。これにより、取得されたトラヒックデータは、システム１内部で共通的に取り扱い可能な、トラヒック項目ＩＤ＋データ（時刻データ等の付加情報を含む）に変換される。

このように、トラヒックデータをシステム１内部で流通可能な形に変換することで、その後の処理ロジックを共通化できる。これにより、処理ロジックの開発規模を最小限に抑えることが可能である。分散構成の観点からも、データ固有の処理をトラヒックデータ取得時に行うことで、データ取得時のデータ固有のデータ変換機能と、全てのトラヒックデータに共通のトラヒックデータ処理機能とに分離することができ、分散構成の分界点が明確になる。

トラヒックデータ加工部１１６は、トラヒックデータを共通フォーマットに計算加工する。また、トラヒックデータ加工部１１６は、トラヒックデータ取得部１１１により取得されたトラヒックデータを元データとし、特定の又は複数のトラヒック項目のデータから計算加工して２次加工トラヒックデータを生成する。さらに、トラヒックデータ加工部１１６は、３次加工トラヒックデータ、４次加工トラヒックデータ、・・・、Ｎ次加工トラヒックデータと、トラヒックデータ同士を組み合わせて計算加工し新たなトラヒックデータを生成することが可能である。

このように、共通のロジックで共通のフォーマットに計算加工してトラヒック項目ＩＤを付与することで、取得したトラヒックデータだけでなく、そこから計算加工されたトラヒックデータについても、その後の処理ロジックを共通化することが可能となり、処理ロジックの開発規模を最小限に抑えることができる。複数のサーバ１０間でのトラヒックデータのやり取りを行う場合、トラヒックデータの流通性を確保することができる。

トラヒック起因処理決定部１１３は、トラヒック項目定義データ記憶部１１０からトラヒック項目定義データ１４を読み込み、トラヒック項目定義データ１４に含まれる判断すべき定義値とトラヒックデータに含まれる値とを比較することにより、実行すべき処理の種類の判定を行う。例えば、そのトラヒックデータに含まれる値の範囲により、実行すべき事後処理が決定される。

分散配備を考えた場合、このように、各種処理手段から分離されたトラヒック項目定義データ１４に基づいて判定を行うことにより、トラヒック起因処理決定部１１３がどのサーバ１０に実装されても、また、サーバ１０にトラヒック項目定義データ１４を複製しても、さらに、特定のサーバ１０にトラヒック項目定義データ１４を配備して問合せをするようにしても、判定を行うことが可能である。トラヒック起因処理決定部１１３により決定される処理としては、異常値判定を行って警報を発出する処理や、輻輳判定を行い特定の外部装置２０に対するトラヒックを抑制する処理や、計算加工を行う処理等が考えられる。また、メッセージデータに関する処理の例としては、メッセージレベルの判定を行い、高い場合警報を発出する処理等が考えられる。

処理命令部１１４は、トラヒック起因処理決定部１１３により決定された処理の実行命令を行う。
外部装置状態管理部１０７は、トラヒックデータやメッセージデータをはじめとする外部からの情報と、外部装置２０からの応答データの解析結果とに基づいて、外部装置２０の状態を管理する。例えば、外部装置状態管理部１０７は、外部装置２０が警報発生状態なのか否か、トラヒック制御状態なのか否かを管理する。このように、外部装置２０の状態を管理することにより、サーバ１０から外部装置２０への頻繁な問い合わせを削減することが可能である。外部装置状態管理部１０７の複数のサーバ１０における分散配置方法としては、状態の種類での分離、外部装置種別での分離、その組み合わせ等が可能である。

制御実行管理補正部１０８は、自サーバ１０が備える制御実行管理機能が管理している外部装置２０の状態と、外部装置状態管理部１０７が管理している外部装置２０の状態との間で差分が生じた場合に、外部装置２０へ補正を加える処理と、制御実行管理自体を外部装置状態管理に合わせる処理との、どちらか一方の処理を行う。
例えば、外部装置２０との間で通信の途絶等が発生したことにより、実際の外部装置状態と状態の差分が発生し、その後状態を合わせる場合、外部装置状態管理部１０７においては外部装置２０の状態がそのまま反映される。しかしながら、外部装置状態が何らかの理由で書き換わった場合、制御実行管理機能が意図した制御実行ができない場合がある。よって、制御実行管理補正部１０８は、このような場合も踏まえ、制御実行の意図により外部装置２０へ補正を加えるか、又は、通常通り制御実行管理自体を外部装置状態管理に合わせるかのどちらかの必要な手段を実行することによって、意図した制御実行を可能とする。

制御実行対象外管理部１０９は、サーバ１０の記憶部に記憶された外部装置２０の識別情報で構成されており、外部装置２０の識別情報によって制御実行対象外の外部装置２０を管理する。トラヒック制御システム１は多数の外部装置２０を短時間で制御実行するためのシステムであり、外部装置２０の数が人的稼動では到底効率が悪い数であるときに必要性が増す。このような短時間で制御実行するというトラヒック制御の業務形態において、意図的に制御実行させない外部装置２０が存在する場合、その存在を明示的にシステム１にて保持しなければ、その都度、人的判断が多数の外部装置２０に対して行われることになり、効率化は図れない。よって、上記のような意図の外部装置２０においては、制御実行対象外として明示的に制御実行対象外管理部１０９により管理することで、制御実行時に多数の外部装置２０の中から即座に制御対象外とする扱いが可能となる。分散配備の観点からすれば、一例として、制御構成データ解析部１０４が制御構成データ１６を解析した際に、制御実行対象外管理部１０９に制御実行対象外の外部装置２０を問い合わせる場合が考えられる。この場合、問合せ先のサーバ１０がわかっていれば良く、他の処理手段の分散配備に影響を与えることはない。

これまで、トラヒック制御システム１において、サーバ１０の機能の主に内部的な処理について触れてきたが、操作端末３０や外部装置２０からの外部要求に対してのインターフェイスも考慮すべき点がある。外部要求とは、外部装置２０や人的操作を伴う操作端末３０からの要求を指す。ユーザが操作端末３０に表示されたＷＥＢ画面に従って操作する場合、サーバ１０側にはＷＥＢサーバが準備されるが、操作端末３０が複数ある場合に、同一要求条件、類似要求条件、要求条件の一部重複等がある状態で、そのまま各サーバ１０へ問い合わせるのは効率が悪い。よって、ＷＥＢサーバからの外部要求は、一旦中間データ処理を行うデータ集約部１１７にゆだねる。データ集約部１１７が、各データが所在しているサーバ１０に対してデータ収集要求を行うが、このとき複数の操作端末３０からの重複された要求は1つの要求として各サーバ１０へ渡される。

各サーバ１０は、データ集約部１１７からのデータ収集要求にしたがって、データ集約参照機能及びデータ集約転送機能により、該当するデータを応答する。データ集約部１１７は、各サーバ１０から応答を受けたデータを集約して外部要求送信元に返信する。
このように、データ集約部１１７が、トラヒック制御システム１内の各サーバ１０が分散管理、分散蓄積しているデータ内容を取りまとめて応答することにより、分散環境においてもネットワーク負荷のかからない効率的なデータ取得が可能となる。

以上説明したように、トラヒック制御に関する各機能を各サーバ１０に分散配備し制御構成データ１６を利用することで、従来において常であったトラヒック制御の集中解析及び集中制御の方式を、分散解析及び分散制御の方式にすることを可能にした。これにより、トラヒック制御システム１を構築する上での余剰設備を削減でき、トラヒック制御システム１を拡張する場合においても大規模装置を導入することなく小規模装置での拡張が可能である。また、分散配備でのデータ流通性を考慮したデータの共通フォーマット化やサーバ１０間のデータ送受信手段の共有化により、データを扱う機能の共通化が図れ、開発効率の向上が図れる。分解点を明確にできることによって、個別機能の絞込みが可能であり、後の機能追加、変更を削減できるため、テスト稼動の削減が期待できる。

また、トラヒック制御システム１は、分散環境において制御構成データ１６に基づいてトラヒック制御そのものやトラヒックの状況把握等、トラヒック制御に関わる処理を順次自動的に実行することができ、複数の手順によるトラヒック制御処理が可能である。また、定期的なトラヒックデータ取得や非定期なメッセージデータ取得における内部流通処理を、トラヒック項目定義データ１４やメッセージ項目定義データ１５によって効率的に開発することができる。このように、分散コンピューティングによるハードウェア構成の柔軟性とプログラム構造の柔軟性とを併せ持つトラヒック制御システム１を構築することができる。また、分散環境適用によるハードウェアコスト削減と、分散環境を適用する上での開発効率化を行うことができる。

なお、以上の説明では、制御構成データ１６をＸＭＬで記述し、トラヒック制御システム１を構成する複数のサーバ１０にはＩＡサーバ、サーバ１０間にはギガビットイーサネット（登録商標）を使用する例で説明したが、トラヒック制御システム１に使用するプログラム言語、サーバ、及び、ネットワーク環境は、Ｄ３Ａの思想及び形態をベースにできればよく、その範囲においては同様の効果が得られる。

また、本発明の技術思想を利用可能な分野は通信網オペレーションのトラヒック制御システム１にとどまらない。Ｄ３Ａは多様なシステムに対応できる基盤アーキテクチャであり、その基盤の上でのＤ３Ａ上位層１２として、制御構成データ１６をはじめとする各機能思想と、Ｄ３Ａ層１１でトラヒックデータやメッセージデータを取り扱う各機能思想の組み合わせは、幅広い応用範囲がある。

トラヒック制御システム１は、多数の外部装置２０からデータを収集解析する側面と、集中管理下において多数の外部装置２０を一斉に制御する側面がある。これまで、システム規模に合わせて大規模装置で構築することが常であった上記性格を持つシステムにおいて、並列的・集中的なデータ収集解析と並列的・集中的な装置制御を小規模装置の分散構成で実現することに利用できる。特にデータ形式が様々でも、扱いがパターン化され、かつ、扱う外部装置数によるシステム規模の柔軟な変化が要求されるシステムにおいて、機能部品の組み合わせによる開発効率化、小規模装置の増減設による余剰ハードウェアコスト削減を図れることが期待される。例えば、ネットワークを構成する装置種類や装置数が常に変化するネットワークオペレーション業務における、トラヒック収集、ネットワーク監視、トラヒック制御等の業務サポートを行うシステムなどである。

本発明の実施の形態に係るトラヒック制御システムの構成を示す図である。 同実施の形態に係るサーバが備えるソフトウェア環境の一例を説明するための図である。 同実施の形態に係る分散データ駆動型アーキテクチャを説明するための図である。 同実施の形態に係る制御構成データの一例を示す図である。 同実施の形態に係るトラヒック項目定義データの一例を示す図である。 同実施の形態に係るトラヒック制御システムの機能構成を示す図である。 同実施の形態に係るトラヒック制御処理の実行手順の一例を示すフローチャートである。 同実施の形態に係るトラヒック制御処理の実行手順の一例を示すフローチャートである。

符号の説明

１ トラヒック制御システム
１０ サーバ
１１ Ｄ３Ａ層
１２ Ｄ３Ａ上位層
１３ 処理構成データ
１４ トラヒック項目定義データ
１５ メッセージ項目定義データ
１６ 制御構成データ
２０ 外部装置
３０ トラヒック制御システム操作端末
１０１ トラヒック制御実行受付部
１０２ 制御構成データ管理部
１０３ 制御構成データ選択部
１０４ 制御構成データ解析部
１０５ トラヒック制御処理実行部
１０６ 実行制御部
１０７ 外部装置状態管理部
１０８ 制御実行管理補正部
１０９ 制御実行対象外管理部
１１０ トラヒック項目定義データ記憶部
１１１ トラヒックデータ取得部
１１２ トラヒック項目ＩＤ付与部
１１３ トラヒック起因処理決定部
１１４ 処理命令部
１１５ トラヒックデータ変換部
１１６ トラヒックデータ加工部
１１７ データ集約部

Claims (10)

1. 相互に通信可能な複数のサーバを含むトラヒック制御システムにおいて、
   トラヒック制御処理の手順を示す単機能プロセスが記述された制御構成データを管理する制御構成データ管理手段と、
   トラヒック制御処理の実行命令を受け付けるトラヒック制御実行受付手段と、
   前記トラヒック制御実行受付手段により受け付けられたトラヒック制御処理を行うための制御構成データを、前記制御構成データ管理手段により管理されている制御構成データの中から選択する制御構成データ選択手段と、
   前記制御構成データ選択手段により選択された制御構成データを解析する制御構成データ解析手段と、
   前記制御構成データ解析手段による解析結果に基づいてトラヒック制御処理を実行するトラヒック制御処理実行手段と、
   前記複数のサーバにおけるトラヒック制御処理の分散実行を制御する実行制御手段とを備え、
   前記実行制御手段は、
   前記制御構成データ選択手段により選択された制御構成データに記述されている単機能プロセスのうち、少なくとも一部の単機能プロセスの実行命令をあるサーバから別のサーバに送信することを特徴とするトラヒック制御システム。
2. 前記制御構成データ管理手段は、前記制御構成データを記憶しているサーバに関する情報をさらに管理し、
   前記制御構成データ選択手段は、
   前記制御構成データ管理手段により管理されている情報に基づいて、前記サーバから前記制御構成データを取得することを特徴とする
   請求項１に記載のトラヒック制御システム。
3. 前記実行制御手段は、サーバ間において前記制御構成データを転送することを特徴とする
   請求項１又は２に記載のトラヒック制御システム。
4. 前記制御構成データには実行時刻が記述されており、
   前記実行制御手段は、
   現在時刻が前記実行時刻と一致したことを検知した場合に、前記制御構成データに基づいたトラヒック制御処理の実行を制御することを特徴とする
   請求項１から３の何れか１項に記載のトラヒック制御システム。
5. 監視対象の外部装置におけるトラヒック状態を示すトラヒックデータを取得するトラヒックデータ取得手段と、
   前記トラヒックデータ取得手段により取得されたトラヒックデータに対して、該トラヒックデータを一意に識別するための識別情報を付与するトラヒック項目ＩＤ付与手段と、
   前記トラヒックデータを共通フォーマットに変換するトラヒックデータ変換手段とをさらに備えることを特徴とする
   請求項１から４の何れか１項に記載のトラヒック制御システム。
6. 前記トラヒックデータを共通フォーマットに計算加工するトラヒックデータ加工手段をさらに備え、
   前記トラヒック項目ＩＤ付与手段は、
   前記トラヒックデータ加工手段により計算加工されたトラヒックデータに対して、該計算加工されたトラヒックデータを一意に識別するための識別情報を付与することを特徴とする
   請求項５に記載のトラヒック制御システム。
7. 前記トラヒックデータの扱いを定義したトラヒック項目定義データを記憶するトラヒック項目定義データ記憶手段と、
   前記トラヒックデータ取得手段により取得されたトラヒックデータと前記トラヒック項目定義データ記憶手段に記憶されているトラヒック項目定義データとを比較することにより、実行すべき処理を決定するトラヒックデータ起因処理決定手段と、
   前記トラヒックデータ起因処理決定手段により決定された処理の実行命令を行う処理命令手段とをさらに備えることを特徴とする
   請求項５又は６に記載のトラヒック制御システム。
8. 外部からの要求に応じて、複数のサーバに分散蓄積されたデータを収集し、該収集されたデータを要求元に返信するデータ集約手段をさらに備えることを特徴とする
   請求項１から７の何れか１項に記載のトラヒック制御システム。
9. 複数の外部装置を監視するトラヒック制御システムにおいて、
   監視対象の外部装置におけるトラヒック状態を示すトラヒックデータを取得するトラヒックデータ取得手段と、
   前記トラヒックデータの扱いを定義したトラヒック項目定義データを記憶するトラヒック項目定義データ記憶手段と、
   前記トラヒックデータ取得手段により取得されたトラヒックデータと前記トラヒック項目定義データ記憶手段に記憶されているトラヒック項目定義データとを比較することにより、実行すべき処理を決定するトラヒックデータ起因処理決定手段と、
   前記トラヒックデータ起因処理決定手段により決定された処理の実行命令を行う処理命令手段と、を備えることを特徴とするトラヒック制御システム。
10. 複数のサーバで構成されたトラヒック制御システムが行うトラヒック制御処理実行方法において、
    トラヒック制御処理の実行命令を受け付けるトラヒック制御実行受付ステップと、
    前記トラヒック制御実行受付ステップにおいて受け付けられたトラヒック制御処理を実行するための制御構成データを取得する制御構成データ取得ステップと、
    前記制御構成データ取得ステップにおいて取得された制御構成データを解析する制御構成データ解析ステップと、
    前記制御構成データ解析ステップにおける解析結果に基づいて、前記制御構成データに記述されている単機能プロセスを実行するトラヒック制御処理実行ステップとを有し、
    前記実行制御ステップでは、前記制御構成データ選択ステップにより選択された制御構成データに記述されている単機能プロセスのうち、少なくとも一部の単機能プロセスの実行命令をあるサーバから別のサーバに送信することを特徴とするトラヒック制御処理実行方法。

Images